診療記録の下書きから、外部機能につなぐ基盤へ
Microsoft Dragon Copilotは、診療時の会話などから臨床文書の下書きを作り、医療者の確認を支援するAIアシスタントだ。その上で別の企業のアプリやエージェントを動かす仕組みが、Microsoft Marketplaceの販売・導入手順とともに整備されている。焦点は、文章生成機能の追加だけでなく、患者に関する文脈をどの相手へ渡し、どの契約と管理の下で使うかにある。
2026年3月のMicrosoftのHIMSS向け発表で示された拡張の構想を、提供地域や購入条件を定める公式文書と合わせて読む必要がある。今回確認した拡張機能の説明には、米国市場に限定し、米国の顧客へ販売するパートナーを対象とすることが明記されている。日本の医療機関が同じ条件で利用できるという発表ではない。
拡張機能へ渡るのは、生成済みの文章だけではない
公式文書によると、拡張機能は患者の情報、診療時の音声とその文字起こし、作成中の臨床ノート、診療全体の文字起こしなどを受け取れる。電子カルテから渡す患者情報には、基本属性、今回の診療、診断、問題リスト、過去の状態などが含まれ、FHIRの仕様に対応する項目が示されている。
ただし、すべてのアプリへ一律にすべての情報を渡すという説明ではない。開発者は技術設定のパッケージで必要な情報と任意の情報を指定し、顧客側がDragon admin centerでアクセスを明示的に有効にする。ここに、どのデータを誰が受け取るかを確認する管理上の接点が設けられている。
機能が増えるほど、生成AIの回答精度だけでなく、データを渡す目的と範囲が重要になる。たとえば文書の形式を整える機能に、過去の診療全体が必要かどうかは別途判断できる。利用者が便利と感じることと、組織が必要な範囲として認めることを分け、設定内容と承認者を残す運用が考えられる。
結果を表示するカードと、人による採用判断
拡張機能は処理結果を構造化したデータとして返し、Dragon Copilotの画面に追加のカードなどで表示する。アクションボタンを通じてノートを補う情報を扱えるという設計だ。外部の機能を、医療者が普段使う流れの中へ置くことで、別の画面へ情報を転記する負担を減らす狙いがある。
ここから、AIが独立して診断し、そのまま正式な記録へ確定する仕組みだと推論してはいけない。Microsoftの製品説明は、臨床出力を医療者が確認するための下書きとして位置付ける。候補の表示、内容の確認、文書への反映、最終確定を、それぞれ誰が行うのかが運用の要点になる。
編集部の考察として、検証時には、AIの提案が正しかった回数だけでなく、根拠が不足した提案を医療者が見分けられるかも確認したい。原会話、電子カルテ上の情報、AIの推論が一つの文章に混ざると、どこまでが実際の記録だったのか判断しにくくなる。出力の出所を辿れる表示や履歴は、確認の負担を左右する。
Marketplaceで買う前に、基盤の契約と環境を整える
パートナー向けの公開要件では、Dragon Copilot Physician Apps and Agentsを販売するために、Microsoftの担当チームとの構築・統合を完了する必要がある。一般のアプリと同じ感覚で、任意の機能を直ちに流通させられるわけではない。掲載情報に加え、拡張マニフェストを含む技術設定のパッケージも必要となる。
購入者側にも前提がある。購入手順と公開要件には、Dragon Copilotのライセンス、Microsoft Customer Agreementへの同意、利用環境の準備などが示される。Marketplaceで追加機能の契約を行っただけで、基盤製品の利用権や必要な環境がそろうわけではない。購入後には、対象アカウントや環境との関連付け、管理画面での有効化を進める。
手順には、購入後の設定が30日以内に行われないとサブスクリプションが自動削除される条件もある。調達担当者だけで契約を進めると、現場へ渡す前に手続きが止まる可能性がある。情報システム担当、運用担当、契約担当が、購入から利用開始までの責任を合わせることが必要だ。
追加料金と、解約条件も機能ごとに違う
公開要件には、定額やユーザー単位といった価格モデルが示される。ユーザー単位の場合、購入した追加機能の利用権と、有効なDragon Copilotライセンスが確認される。基本製品を使っていればすべての拡張が無料になる、あるいは一つの契約で全員が使えるという意味ではない。
また、複数年契約で未払いの支払いが残る場合など、顧客自身による解約に制約があることも明記される。価格表だけを比較せず、課金対象、更新、解約、利用停止時のデータの扱いを合わせて確認したい。Microsoftとの基盤契約と、拡張を提供する相手に関する条件の両方を見る必要がある。
このようにMarketplaceは、発見や購入、権限管理をまとめる窓口にはなるが、医療機関ごとの適合性を代わりに判断するものではない。特定の拡張が診療時間や記録品質をどれだけ改善するかは、対象業務と利用条件に沿った評価が必要だ。発表中の期待効果を、日本の現場での実測値として扱うことはできない。
日本で考えるべきことは、導入可否の手前にもある
現在の米国向け拡張の条件を、日本での提供条件へ読み替えることは避ける。その上で、データの受け渡しを明示して追加機能を使う設計は、国内の業務システムにも参考になる。どの記録を、どの処理に、どの期間使うか。返された提案を誰が確認し、取り消しや問い合わせをどこへ行うか。この一連の責任を整理しておくことに意味がある。
AI導入に伴う業務や連携範囲の整理については、運営会社のRO合同会社にも相談できる。医療分野での利用については、提供者の正式な地域・契約条件と、組織側の審査を確認した上で判断する必要がある。本稿は製品の構造と運用上の論点を解説するもので、診療判断や国内での利用承認を示すものではない。
参考報道：イノベトピア。機能・販売・購入要件はMicrosoftの一次資料を確認し、管理上の評価項目は編集部の考察として記載した。
ポッドキャスト燎RYOU課 ポッドキャスト
ポッドキャストを聴く →
