医療DXにおけるMCPとは|FHIR連携の公開例と安全な始め方
MCP(Model Context Protocol)は、AIアプリケーションが許可されたデータや機能を共通の方法で利用するための接続規格です。AWS、Google、Microsoftの公開例と、医療機関で読み取り専用から始める設計条件を整理します。
Target Reader / 対象読者
医療AIと電子カルテ・FHIR・院内システムの連携を検討する医療機関の経営者、医療情報担当者、事務長、開発・連携担当者
結論:MCPは、AIと医療システムの接続方法をそろえる規格
MCP(Model Context Protocol)は、AIそのものでも、電子カルテのデータ規格でもありません。AIアプリケーションが、許可されたデータや機能を共通の方法で発見し、利用するための接続規格です。
医療での価値は、AIに何でも操作させることではありません。どの利用者が、どの情報を読み、どの機能を実行できるかを接続単位で分け、ログと人による確認を残しやすくする点にあります。MCPを採用しただけで安全性、正確性、法令対応が保証されるわけではありません。
MCP、FHIR、RAGは役割が違う
MCPは、AI側のホスト、接続を管理するクライアント、データや機能を提供するサーバーで構成されます。サーバーは、参照できる情報や実行できるツールを定義し、AIは許可された範囲から必要なものを選びます。
医療連携では、MCPの内側で既存APIやFHIRを呼び出すことがあります。MCPがFHIRを置き換えるのではなく、既存の接続手段をAIから利用する入口として整理する関係です。
| 用語 | 医療DXでの役割 |
|---|---|
| MCP | AIが許可された情報・機能へ接続する方法をそろえる |
| FHIR | 医療情報のデータ形式やAPI交換方法を標準化する |
| RAG | 質問に関連する文書を検索し、回答時の根拠として生成AIへ渡す |
| LLM | 受け取った質問・文脈・検索結果をもとに文章や候補を生成する |
公開実装・研究例から分かること
2026年7月時点で、医療分野のMCPは、クラウド事業者の公式実装や研究開発の形で具体例が公開されています。以下は導入効果を示す医療機関の実績ではなく、実装可能な範囲と安全設計を確認するための公開例です。
| 公開例 | 確認できる内容 | 読み取り方 |
|---|---|---|
| AWS HealthLake MCP Server | FHIRリソースの検索・取得・登録・更新、Patient $everything相当、読み取り専用モードを公開 | オープンソースの実装例。画面例や処理例を医療機関の導入実績とは扱わない |
| Google Cloud Healthcare API | FHIR患者情報の検索と、DICOM検査・画像をMCPから取得する公式チュートリアルを公開 | FHIR ReaderやDICOM Viewerなど、読み取り中心の権限設計を確認できる |
| Microsoftのがん診療支援研究 | EHR、画像、病理、ゲノム、診療ガイドライン等を専門エージェントが整理する研究構成でMCP接続に対応 | 研究開発中の公開例。診断・治療への本番導入や効果を示すものではない |
設計例:患者情報の要約案を、原本確認までつなぐ
次は公開仕様をもとにした架空の設計例であり、NEURONLABまたは特定医療機関の導入実績ではありません。MCPを診断の自動化ではなく、確認対象の整理に限定した場合の流れです。
| 段階 | 処理 | 人に残す確認 |
|---|---|---|
| 1 | 医師が対象患者と確認期間を指定する | 対象患者・利用目的が正しいか確認する |
| 2 | 利用者権限を引き継いだ読み取り専用ツールでFHIR情報を取得する | 取得範囲が診療上必要な最小範囲か確認する |
| 3 | AIが服薬、検査、既往歴などの要約案を作る | 診断や治療方針を確定させない |
| 4 | 各要約に元データ、記録日時、参照先を付ける | 原本と要約が一致するか確認できるようにする |
| 5 | 医師が原本と患者本人の情報を確認する | 確認済みの内容だけを診療へ利用する |
| 6 | 記録が必要な場合は、別権限・別操作で確定する | AIの要約を自動で診療録へ確定しない |
医療機関で外せない安全境界
MCPは接続規格であり、接続先の正しさやサーバー運営者の信頼性まで保証しません。公式仕様が示す認可、ツール入力の検証、人による確認に加え、日本の医療情報管理に合わせた運用設計が必要です。
| 論点 | 最低限決めること |
|---|---|
| 接続先 | 承認したMCPサーバーとツールだけを許可し、提供者・更新責任・停止方法を把握する |
| 権限 | 利用者の職種・施設・患者範囲を引き継ぎ、参照・更新・実行を分離する |
| 認証・認可 | トークンの利用先を検証し、別サービスへの使い回しや無制限の代理実行を防ぐ |
| 実行前確認 | 診療録更新、予約確定、外部送信などは対象・入力内容・影響を人へ表示して承認を得る |
| 監査 | 誰が、いつ、どの患者・情報・ツールへアクセスし、何を実行したかを残す |
| 障害時 | MCPやAIが停止・誤動作しても、既存システムと代替運用へ戻せるようにする |
| 責任分界 | 医療機関、AI提供者、MCP提供者、既存ベンダーの確認先と責任を文書化する |
最初は、個人情報なし・読み取り専用・1業務から
初期検証では、院内公開済みの手順書、施設案内、予約ルールなど、患者個人情報を含まない情報から始める方法があります。患者情報を扱う場合も、模擬データと読み取り専用の単一ツールから権限・ログ・誤操作時の戻り方を確認します。
使える機能の数より、許可されていない質問では取得しない、根拠がなければ回答しない、更新操作の前に人へ戻す、という失敗時の挙動を先に試すことが重要です。
- 対象業務と利用者を一つに限定する
- 匿名・模擬データまたは承認済みの公開情報で検証する
- 読み取りと更新を別ツール・別権限にする
- 正常系だけでなく、権限外患者、誤った患者ID、接続停止、タイムアウトも試す
- AIの回答と、実際に呼び出したツール・入力・結果を照合する
MCPとRAGは、競合ではなく役割分担
MCPはAIが外部のデータや機能へ接続する境界、RAGは文書から根拠を探して回答へ渡す仕組みです。例えば、MCPで院内文書検索ツールを呼び出し、その検索結果をRAGの根拠として回答案へ使う構成も考えられます。
接続できることと、検索結果が正しいことは別問題です。MCP側の権限・実行ログと、RAG側の資料版・検索精度・引用一致を分けて評価します。
参考資料・一次資料
Model Context Protocol『Architecture』 https://modelcontextprotocol.io/specification/2025-11-25/architecture
Model Context Protocol『Tools』 https://modelcontextprotocol.io/specification/2025-11-25/server/tools
Model Context Protocol『Authorization』 https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
Model Context Protocol『Security Best Practices』 https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
AWS『Building healthcare AI agents with open-source AWS HealthLake MCP server』 https://aws.amazon.com/blogs/industries/building-healthcare-ai-agents-with-open-source-aws-healthlake-mcp-server/
AWS Labs『HealthLake MCP Server』 https://github.com/awslabs/mcp/tree/main/src/healthlake-mcp-server
Google Cloud『Use MCP Toolbox with the Cloud Healthcare API』 https://docs.cloud.google.com/healthcare-api/docs/tutorials/pre-built-tools-with-mcp-toolbox
Microsoft『Developing next-generation cancer care management with multi-agent orchestration』 https://www.microsoft.com/en-us/industry/blog/healthcare/2025/05/19/developing-next-generation-cancer-care-management-with-multi-agent-orchestration/
厚生労働省『医療情報システムの安全管理に関するガイドライン 第7.0版』 https://www.mhlw.go.jp/stf/shingi/0000516275_00006.html
個人情報保護委員会『生成AIサービスの利用に関する注意喚起等』 https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf
FAQ
MCPを導入すると電子カルテを置き換えられますか。
いいえ。MCPはAIがデータや機能へ接続する方法をそろえる規格です。電子カルテ、FHIR、既存API、院内の認証・権限設計は別に必要です。
MCPなら医療データを安全に扱えますか。
MCPを使うだけでは安全になりません。接続先の審査、最小権限、認証・認可、実行前確認、監査ログ、責任分界を設計する必要があります。
MCPでFHIRへ接続できますか。
FHIR APIを呼び出すMCPサーバーの公開例はあります。ただし、対象システムが対応するAPIを持ち、医療機関とベンダーが接続・権限・責任分界を合意できることが前提です。
医療機関では何から試すべきですか。
患者個人情報を含まない承認済み資料、または模擬データを使い、読み取り専用・一業務・少人数から権限とログを確認する方法があります。
Consultation
個別相談が必要な論点は、現場の状況に合わせて整理できます。
現場ごとの導入相談、既存システムを活かした設計相談、配送やラストワンマイルを含む相談まで、 実運用を前提に整理します。
