AIとデータ・外部ツールをつなぐ「MCP」　医療導入で残る三つの境界

モデル・コンテキスト・プロトコル（Model Context Protocol、MCP）は、AIアプリが外部データや実行ツールへ接続するときのメッセージ形式をそろえるオープン標準だ。大規模言語モデル（Large Language Model、LLM）は、MCPサーバーが公開したデータを参照し、検索、計算、記録といった外部処理を要求する。MCPへの適合だけで、データの中身、モデルの回答、医療上の判断まで正しくなるわけではない。

利用者から見れば、ファイルを読むAI、社内データを調べるAI、予定を登録するAIの背後にMCPが入る。医療機関では接続先が診療情報や院内業務へ広がりうるため、「何につながるか」に加え、「誰の権限で何を動かすか」「結果を誰が確定するか」を分けて検収する必要がある。

三つの入口──プロンプト、リソース、ツール

MCPの現行サーバー仕様は、外部の文脈や機能を渡す基本要素をprompts、resources、toolsの三つに分け、promptsは利用者、resourcesはアプリ、toolsはモデルが主に制御すると整理している。日本語では、プロンプト（Prompt）は定型の指示、リソース（Resource）は参照するデータ、ツール（Tool）は外部で処理を実行する関数に当たる。

要素	役割	主な制御者	医療システムでの抽象例
prompts	定型の指示や作業手順を提示する	利用者	「今週の検査結果を時系列で整理する」という定型指示
resources	モデルへ渡す構造化データや文書を示す	アプリ	診療情報提供書、院内手順書、医療コード表
tools	検索、計算、更新などの外部処理を呼び出す	モデル	許可された患者と期間の検査結果を照会する関数

「モデルが制御する」は、モデルへ最終権限を渡すという意味ではない。モデルは文脈からツールの候補と引数を選ぶが、ホスト側は公開するツールを絞り、利用者の権限を確認し、呼び出しを拒否する経路を持つ。MCP仕様はこの役割分担を示すが、院内の職務権限や承認者までは決めない。

接続の流れ──現行版はリクエスト単位

MCPはホスト（Host）、クライアント（Client）、サーバー（Server）で構成する。ホストはAIアプリと利用者の同意を管理し、複数のクライアントを持つ。各クライアントは一つのサーバーと通信し、サーバーは担当するデータやツールを公開する。2026年7月28日版の公式アーキテクチャは、JSON-RPCを使うステートレスな構成を採り、プロトコル版とクライアント能力を各リクエストに含めると定めている。

ここは旧版と区別が要る。公式の版管理資料は現行プロトコル版を2026-07-28とし、2025-11-25以前の接続で使ったinitialize方式から、リクエストごとに版を示す方式へ移ったと説明している。サーバーは対応版と能力を返すserver/discoverを備える。クライアントによるserver/discoverの事前呼び出しは任意で、呼び出した場合は対応版、toolsやresourcesなどの能力、自己申告のサーバー情報を一度に取得する。「MCP対応」という表示だけでは、どの版で通信するかまでは分からない。

「一定期間の検査結果を探す」という抽象的な処理は、次の順序になる。

1. 利用者がAIアプリへ依頼し、ホストが利用者と接続先を識別する。
2. クライアントがサーバーから利用可能なツール一覧を取得する。
3. モデルが照会用ツールを選び、患者、期間、項目などの引数を入力スキーマに合わせる。
4. ホストが利用権限を照合し、必要な操作では利用者または担当者へ確認を求める。
5. クライアントがツール呼び出しを送り、サーバーが認可済みの上流サービスへ照会する。
6. 結果またはエラーがAIアプリへ戻る。導入側は回答と操作記録を残す。

現行のツール仕様は、一覧取得にtools/list、実行にtools/callを使い、各ツールへ名前、説明、入力JSON Schemaを持たせる。人が呼び出しを拒否できる状態と確認画面を推奨し、信頼済みサーバー由来でないツール注釈は信用しないようクライアントへ求めている。ツールが呼べたという事実と、その処理を許可してよいという判断は別である。

API、RAGとの違い──同じ構成で併用も

アプリケーション・プログラミング・インターフェース（Application Programming Interface、API）は、ソフトウェア同士が機能や情報をやり取りするための接点である。MDNはAPIを、あるソフトウェアが別のソフトウェアや機器と相互作用するために備える機能と規則の集合と説明している。MCPサーバーは既存APIをツールとして包めるが、元のAPIを置き換えるとは限らない。

検索拡張生成（Retrieval-Augmented Generation、RAG）は、検索した外部情報を生成モデルの回答へ組み込む方法だ。ルイスらが2020年に公表した原論文は、事前学習済みモデルが持つパラメータ内の記憶と、検索器が参照する外部の非パラメトリック記憶を組み合わせる構成をRAGとして示した。MCPのresourceやtoolから得た文書をRAGへ渡す構成も成り立つ。

仕組み	主にそろえるもの	導入時の検証対象
API	システム間の機能、データ形式、呼び出し規則	接続先、認証、項目、エラー、変更管理
RAG	検索した情報と生成モデルの組み合わせ	検索漏れ、文書の版、出典との一致、回答への反映
MCP	AIアプリがデータやツールを発見し、呼び出す共通手順	プロトコル版、サーバーの信頼性、ツール権限、人の確認、記録

一つの医療システムでも三者は重なる。FHIR対応APIが検査結果を返し、MCPサーバーがその照会をtoolとして公開し、返った文書をRAGが検索対象にする構成である。どの層で誤りが生じたかを追うには、APIの応答、MCPの呼び出し、検索結果、モデルの回答を別々に記録する必要がある。

日本の位置づけ──行政文書に登場、医療採用は未確認

MCPは日本の行政文書にも登場している。デジタル庁は2025年10月、文書レビュー支援AIエージェントの情報提供依頼で、RAGやMCPを使ったガイドライン参照方式と、人とAIの作業境界について技術提案を求めた。同資料は情報収集のためのRFIで、将来の契約を意味しないと明記する。政府がMCPを技術候補として調べた事例であり、運用実績や医療分野での採用を示す資料ではない。

医療情報の交換では別の標準が先にある。厚生労働省は電子カルテ情報共有サービスを全国医療情報プラットフォームの一部とし、診療情報提供書の電子共有、健診結果の閲覧、臨床情報の閲覧、本人向け患者サマリーの閲覧という四つのサービスを掲げている。システム事業者向けページには2026年6月版の技術解説書、FHIR記述データの手本、日本向け臨床情報共有実装ガイドJP-CLINSが並ぶ。

医療情報交換規格FHIR（Fast Healthcare Interoperability Resources）は、患者、検査、処方などをリソースという共通単位で表す。HL7のFHIR R4仕様は、交換する内容をResourceとして定義し、参照で組み合わせ、用途別のプロファイルで必須項目や用語を絞る構造を示している。FHIRが扱うのは医療データの意味と交換形式で、MCPが扱うのはAIアプリが外部データや処理へ接続する手順である。

この二つの仕様から、権限管理済みのFHIR照会をMCPのtoolとして公開する構成は技術上想定できる。ただし、これはアーキテクチャ上の推論である。厚生労働省が電子カルテ情報共有サービスの医療情報交換標準にMCPを位置づけた資料は、本稿の執筆時点で確認できていない。FHIR接続後に残る項目対応や検証は、電子カルテを医療AIにつなぐ四つの関門で整理した。

接続対象が診療情報なら、個人情報保護の責任も消えない。個人情報保護委員会と厚生労働省のガイダンスは、診療記録にある病歴、診療・調剤情報、健診結果などを要配慮個人情報に含め、取得と個人データの第三者提供には原則として本人同意が要ると示している。MCPは同意の取得、利用目的の適法性、委託か第三者提供かという法的判断を代行しない。

導入前に分ける五つの検収項目

医療機関の検収は、MCPだけを切り出して終えられない。厚生労働省の医療情報システム安全管理ガイドライン第7.0版は、API連携で利用する利用者、アプリ、機器の範囲と責任分界、アクセスポリシー、ログ管理を明確にし、参照、更新、実行、追加などの権限を必要最小限に分け、アクセスログを記録して定期確認するよう求めている。MCPのtoolが医療情報システムのAPIを呼ぶ構成なら、その処理もこの管理対象から外れない。

検収項目	確認する記録	失敗試験
目的とデータ経路	接続元、送信先、患者範囲、項目、保存、再利用	対象外の患者・期間・項目を要求した場合の拒否
ツール権限	閲覧、下書き、更新、送信、削除を分けた権限表	読み取り専用の利用者が更新を要求した場合の拒否
認可と人の確認	利用者、トークンの対象と期限、確認者、取消手順	期限切れ、権限不足、確認拒否時の停止
追跡と版管理	モデル、MCPクライアント、サーバー、プロトコル版、tool、引数、結果、時刻	接続先や入力スキーマを変更した後の再現
停止と復旧	タイムアウト、重複実行、上流エラー、停止権限、代替手順	通信断、同じ要求の再送、権限撤回、誤結果からの復旧

通信方式によって認可の前提も異なる。現行MCPの認可仕様は実装上任意で、HTTPで認可を使う場合はOAuth 2.1を基礎とする方式への準拠を推奨し、STDIOでは環境から資格情報を得るよう定める。HTTPでは必要なscopeだけを要求し、アクセストークンが対象のMCPサーバー向けに発行されたかを検証する。このトークンが正しくても、上流の電子カルテや予約システムで許可された操作範囲まで自動的に正しくなるわけではない。

サーバーそのものの出所も検収対象になる。MCPの公式セキュリティ資料は、ローカルサーバーがクライアントと同じ権限で動きうると警告し、実行前の明示的な同意、サンドボックス、ファイルシステムやネットワークへの最小権限を挙げている。ツール名が「検索」でも、実体のプログラムが読めるファイルや送信できる通信先は別に調べる必要がある。医療AIエージェント全体の権限、人の承認、停止・復旧は、医療AIエージェント導入の三つの安全策と重なる。

使う条件──接続の共通化と検証負担を比べる

複数のAIアプリから複数のデータサービスや業務ツールを使い、公開方法と呼び出し方を共通化したい組織では、MCPを置く意味が明確になる。一つの固定された照会先だけを使うなら、仕様のはっきりしたAPIへ直接つなぐ構成のほうが、版管理と障害点を減らせる場合がある。

医療分野では、接続方式の採用と臨床導入の判断を分ける必要がある。MCPで検査結果を取得できても、患者の対応付け、単位、時刻、欠損、コード変換、モデル性能、画面表示、人の確定は残る。用途定義から導入後監視までの全体像は、医療AIを現場へつなぐ四段階で扱っている。

MCP接続を含む医療AIについて、国内の導入施設、読み取り・書き込み権限、人による拒否件数、ツール失敗率、臨床上の性能を共通定義で結び付けた公的資料は、本稿の執筆時点で確認できていない。導入例が存在しないという意味ではない。公開情報だけでは、接続の試行と本番運用、事務支援と診療判断を横並びに評価できないという情報上の限界である。

よくある質問

MCPとは何か
MCPは、AIアプリと外部データ、定型プロンプト、実行ツールの間で使うメッセージと呼び出し方をそろえるオープン標準である。モデル、データベース、上流APIそのものではない。

MCPとAPIは同じものか
役割が異なる。APIはソフトウェア同士が機能や情報を交換する接点で、MCPはAIアプリが外部のデータやツールを発見し、共通の手順で呼び出す層である。MCPサーバーが既存APIをtoolとして公開する構成もある。

MCPを入れれば日本の電子カルテ情報共有サービスを直接読めるのか
MCPは医療情報への通行証ではない。接続先が正式に提供するインターフェース、参加条件、本人同意を含む法的根拠、利用者の認証、対象データと操作範囲が別に要る。本稿で確認した厚生労働省の公開資料はFHIR記述データとJP-CLINSを実装資料に掲げるが、MCP接続口を示していない。