MCPの説明を読むと必ず出てくるのが「MCPサーバー」という言葉です。ここでつまずく方が多いので、独立した記事として整理します。
MCP全体の仕組みは MCPとは？AIが外部のデータやツールとつながる仕組み、電子カルテへの当てはめは 電子カルテでMCPを使うとは？ をご覧ください。
免責：本記事は一般的な情報提供です。仕様は更新され得ます。実装時は最新の公式仕様をご確認ください。
MCPサーバーは「サーバー機」ではない
まず誤解を解きます。MCPサーバーは、ラックに置く機械のことではありません。
MCPサーバーとは、あるデータやシステムに対して、AIが使える窓口を提供するソフトウェア部品です。ノートPCの中で動くこともあれば、院内サーバーで動くことも、クラウド上で動くこともあります。「サーバー」は「窓口を提供する側」という役割名だと捉えてください。
イメージとしては受付カウンターが近いです。カウンターの向こうには業務システムがありますが、来訪者（AI）が触れるのはカウンターに並んだ手続きのメニューだけ。メニューにない手続きは頼めません。
MCPサーバーが提供する3種類のもの
MCPサーバーがAIに差し出すものは、仕様上おおむね3種類に分かれます。医療での対応例と併せて整理します。
| 種類 | 意味 | 医療での例 |
|---|---|---|
| ツール（Tools） | AIが実行できる操作 | 患者検索、検査値取得、予約枠照会、文書テンプレート取得 |
| リソース（Resources） | AIが読み取れるデータ | 院内マニュアル、算定ルール表、公費マスタ、症例ドキュメント |
| プロンプト（Prompts） | 定型の指示テンプレート | 「初診サマリを作る」「紹介状の下書きを作る」の手順 |
実務でいちばん重要なのはツールです。ここに何を並べるかが、そのままAIにできることの上限になります。
そして各ツールには、AIが読める説明文が付きます。「このツールは患者IDを受け取り、直近の検査値を返します」といった説明です。AIはこの説明を読んで、状況に応じてどのツールを使うか判断します。従来のAPIと決定的に違うのはこの点で、人間の開発者が手順を書き込まなくても、AIが自分で選べるようになっています。
APIとの関係は APIとは？クリニックのシステム連携を理解するための基礎知識 と MCPとAPI・FHIRは何が違うのか で扱っています。
誰が用意するのか
医療機関の立場で気になるのは「これは誰が作るものなのか」でしょう。実際には4つのパターンがあります。
① 電子カルテベンダー 自社カルテのデータに対する窓口を、ベンダーが公式に提供する形。医療機関にとっては最も現実的で、責任分界も明確です。動作保証・アップデート追随・セキュリティ対応がベンダー側に乗ります。
② SaaS・外部サービスの提供元 予約システム、Web問診、決済サービスなどが、それぞれ自社サービス用のMCPサーバーを提供する形。カルテ以外の周辺システムはこちらが増えていくと考えられます。
③ 院内の情報システム部門・委託SIer 既存システムにAPIはあるがMCPサーバーはない、という場合に、間に変換の部品を作る形。中〜大規模病院では現実的な選択肢ですが、作った側が保守責任を負う点に注意が必要です。
④ 公的機関・業界団体 診療報酬情報や医薬品情報のような公共性の高いデータについては、共通の窓口が整備される可能性があります。全国医療情報プラットフォーム の方向性とも重なる領域です。
**クリニック規模であれば、実質的に①と②です。**自院でMCPサーバーを開発する必要はほぼありません。「どのベンダーが用意しているか」を選定条件に含める、という関わり方が現実的です。
医療機関で公開しうる窓口の例
参考として、医療機関のシステムでMCPサーバーが提供しうる窓口を、リスクの大きさ順に並べます。
| 窓口の例 | 種別 | 影響 | 妥当な初期設定 |
|---|---|---|---|
| 院内マニュアル・院内規程の検索 | 読み取り | 小 | 早期に開けてよい |
| 算定ルール・公費マスタの参照 | 読み取り | 小 | 早期に開けてよい |
| 予約枠の空き照会 | 読み取り | 小 | 早期に開けてよい |
| 患者の検査値・処方歴の参照 | 読み取り | 中 | 権限内に限定して開ける |
| カルテ本文・所見の参照 | 読み取り | 中〜大 | 権限内・範囲限定。監査ログ必須 |
| 文書（紹介状・診断書）の下書き作成 | 書き込み（下書き） | 中 | 人の確定を必須にする |
| 予約の登録・変更 | 書き込み | 中 | 確認ステップ付きで許可 |
| カルテへの確定書き込み | 書き込み | 大 | 当面は開けない |
| 処方・オーダーの発行 | 書き込み | 大 | 開けない |
原則は明確です。読み取りから開け、書き込みは下書きまで、確定は人が握る。
公開範囲の設計——「最小権限」を窓口の粒度で考える
セキュリティの一般原則である最小権限（必要最小限の権限だけを与える）は、MCPでは窓口の設計そのものとして現れます。
粗い窓口は危険です。 「カルテデータを取得する」という一つの大きな窓口を作ってしまうと、必要なのが検査値だけでも、実装上はカルテ全体にアクセスできる状態になりがちです。
細かい窓口に分ける。 「直近の検査値を取得する」「アレルギー情報を取得する」「処方歴を取得する」と分けておけば、AIに与える窓口を用途ごとに絞れます。監査ログも「何を見たか」が具体的に残ります。
人の権限を超えさせない。 これが医療では決定的です。AIが動くとき、指示した職員の権限を超えて情報にアクセスできてはいけません。受付職員の指示で動いたAIが、その職員が画面上で見られない情報を読める——という状態は、権限管理の破綻です。詳しくは 医療機関でMCPを使うときの権限設計とセキュリティ確認事項 で扱います。
院内に置くか、クラウドに置くか
MCPサーバーの設置場所は、情報がどこまで動くかを決めます。
院内設置（オンプレミス） カルテと同じネットワーク内に置く形。院内で完結する範囲が広く、情報の出口を絞りやすい構成です。一方で、保守・更新・障害対応を自院側で抱えることになります。
クラウド設置 ベンダー側の環境で動かす形。保守負担は軽くなりますが、院内データがどの経路でそこに届くのかの設計が必須です。
AIネイティブ型では、そもそもこの問いが小さくなります。 AIとカルテが同じ基盤上にあるため、院内データを外に出す経路自体が最小限で済みます。外部の専門情報を引くときだけMCPを使う、という構成です（AIネイティブ電子カルテとはどんなものなのか？）。
クラウドとオンプレミスの一般的な比較は クラウド型とオンプレミス型の電子カルテ、医療機関のクラウド利用の前提は 医療機関のクラウドセキュリティ をご覧ください。
自院でMCPサーバーを作るべきか
「作れる」と「作るべき」は別です。判断軸を挙げます。
作らないほうがよい場合（多くのクリニック）
- ベンダーが公式に提供している、または提供予定がある
- 院内に継続的に保守できる技術要員がいない
- 対象データが患者情報を含む
検討の余地がある場合
- 患者情報を含まない院内文書（マニュアル、規程、運用手順）に限定する
- 中〜大規模病院で、情報システム部門が保守体制を持っている
- 既存システムにAPIがあり、変換層だけで済む
作る場合に見落とされやすいのが保守責任です。カルテがバージョンアップしたとき、連携が壊れたとき、脆弱性が見つかったとき——対応するのは作った側です。ここを引き受けられるかが分岐点になります。
確認事項
ベンダーがMCPサーバーを提供している場合、次を確認します。
- どんな窓口（ツール）が用意されていますか。一覧をいただけますか
- 窓口ごとに有効・無効を院内で設定できますか
- 読み取り専用の窓口と、書き込みを伴う窓口は分かれていますか
- AIはログインユーザーの権限の範囲内でしか動けない設計ですか
- どの窓口が呼ばれたかは監査ログに残りますか
- MCPサーバーはどこで動きますか（院内／ベンダー環境／第三者クラウド）
- 障害時、カルテ本体の診療業務は継続できますか
まとめ
- MCPサーバーは機械ではなく、AIから見た「窓口」を提供するソフトウェア部品
- 提供するのは**ツール（実行できる操作）・リソース（読めるデータ）・プロンプト（定型の指示）**の3種類
- 各ツールにはAIが読める説明が付き、AIが自分で選べる。これが従来APIとの決定的な差
- 用意するのは主にカルテベンダーと外部サービス提供元。クリニックが自作する必要はほぼない
- 公開範囲は読み取りから開け、書き込みは下書きまで、確定は人が原則
- 窓口は細かく分けるほど最小権限を実現しやすく、監査ログも具体的になる
- AIが人の権限を超えないことが医療では決定的
- 自作する場合、保守責任を引き受けられるかが判断の分かれ目
AIカルテの詳細やデモをご希望の場合は お問い合わせ からご連絡ください。