概要
数十年もの間、アプリケーション・プログラミング・インターフェース（API）は、ソフトウェア同士が通信するための「ゴールドスタンダード」とされてきました。
これまでに利用したすべてのオンライン決済 天気を確認するたびに エンタープライズアプリケーションにログインしたときはいつでも
これらすべて、そして他にも多くの機能が、APIによって支えられています。 これらのツールは、他のアプリケーションとの間で情報を送受信するために使用されます。
API ソフトウェア同士が通信する仕組みです。 開発者は統合作業を行い、エンドポイントを把握し、コードの保守を行います。 長きにわたって標準として定着してきました。
MPI（モデルコンテキストプロトコル） は、AIがソフトウェアと通信するための仕組みです。 AIエージェントは、実行時に利用可能なツールを自動的に検出し、統合ごとに独自のコードを記述することなく、標準化されたプロトコルを通じてそれらを利用します。 2024年にAnthropicによって導入されたMCPは、既存のAPIの上に構築されており、それらに取って代わるのではなく、AIがそれらを利用できるようにするものです。
のAPIは、開発者向けに構築されています。 MCPはAIエージェント向けに構築されています。
たとえば医療業界では、30以上のAPIが技術インフラを支えているケースも珍しくありません。 そこで、AIエージェントが登場した際、それに伴って興味深い課題も浮上しました。
「これらのツールはそれぞれ、呼び出し方法も、パラメータも、引数も、プロトコルも異なっていた」と インターシステムズ社長であるドン・ウッドロックが、自身の「Code to Care」シリーズで述べています。 「そのため、エージェント型システムを構築するという作業は複雑なものとなった」
モデルコンテキストプロトコルは、その複雑さを解消するために設計されました。 これは、システムがすでに使用しているインターフェースに取って代わるものではありません。 MCPは、これらの上に標準化されたレイヤーを構築することで、AIエージェントが個々のツールごとにカスタムコードを書くことなく、ツールを発見・利用できるようにします。
初めてAIワークフローを構築する場合でも、医療IT業界でなぜ皆がMCPについて話題にしているのかを理解したい場合でも、この記事では、MCPとは何か、従来のAPIとの違い、そしてそれぞれがどのような場面で重要になるのかについて、実践的な解説を行っています。
APIとは何ですか？
API（アプリケーション・プログラミング・インターフェース）とは、あるソフトウェアが別のソフトウェアとどのように通信するかを定義する一連の規則のことです。 APIは、ソフトウェア間の通信の基盤です。あるシステムが構造化されたリクエストを送信すると、別のシステムが構造化されたレスポンスを返します。
POST https://hospital.example.com/api/appointments
// Headers
Authorization: Bearer eyJhbGciOi ...
Content-Type: application/json
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
} Response:
200 OK
{
"appointment_id": "APT-78291",
"status": "confirmed",
"patient": "MRN-00482916",
"provider": "Dr. Ramirez",
"location": "Building C, Room 204"
} 医療分野において、APIは保険の適用可否確認から検査結果のやり取りに至るまで、あらゆる業務を支えています。 スケジュール管理アプリケーションは、病院システムのREST APIを呼び出して、予約を行います。 このAPIでは、エンドポイント、必要なパラメータ、認証方法、およびレスポンス形式が定義されています。 呼び出し側は、これらすべてを事前に把握しておく必要があります。
この要件（APIを使用する前にその仕組みを理解しておく必要があること）は、強みであると同時に限界でもあります。 APIは予測可能で高速であり、ソフトウェア間の通信が固定されたパターンに従う安定した統合に最適です。
ただし、APIを利用するのは、ドキュメントを読み、統合コードを記述し、あらゆるエッジケースに対するエラー処理を実装した開発者であることを前提としています。
MCP（モデル・コンテキスト・プロトコル）とは何か？
モデルコンテキストプロトコル（MCP）は、 2024年後半にAnthropic社が導入した標準規格であり、大規模言語モデルやAIエージェントが外部ツール、データソース、外部サービスとどのように連携するかを定義するものです。
APIがソフトウェア間の通信を目的として設計されているのに対し、MCPはAIネイティブであり、ツールを動的に検出して使用する必要があるAIシステムやAIアプリケーションのために、一から構築されています。
APIでは、呼び出し元がシークレットを保存し、ネットワークリクエストを行い、障害に対処できることが前提となっています。 AIモデルでは、これらのことをどれも安全に行うことはできません。 テキストを解析し、次のトークンを予測します。
APIキーや認証トークンを用いてAPIエンドポイントへの直接アクセスを許可することは、危険であるだけでなく非効率的でもあります。
MCPは、AIエージェントと外部世界との間に制御された層を構築します。 AIは機密性の高いURLや認証情報を一切閲覧することはありません。 これは標準化されたインターフェースを通じてツールを呼び出し、MCPサーバーがその背後にあるすべての処理を処理します。
tools/list
// No URL, no auth token, no docs required[
{
"name": "schedule_appointment",
"description": "Book a patient appointment",
"inputs": { "patient_id", "provider", "department", "date" }
},
{
"name": "get_lab_results",
"description": "Retrieve lab results for a patient",
"inputs": { "patient_id", "test_type" }
},
{
"name": "check_insurance_eligibility",
"description": "Verify patient insurance coverage",
"inputs": { "patient_id", "procedure_code" }
}
]tools/call "schedule_appointment"
{
"patient_id": "MRN-00482916",
"provider": "Dr. Ramirez",
"department": "Cardiology",
"date": "2026-04-15T10:30:00Z"
}{
"appointment_id": "APT-78291",
"status": "confirmed",
"location": "Building C, Room 204"
}USB-Cの例え
MCPはAIツールにとって、USB-Cが周辺機器にとっての役割を果たすものです。 USB-Cが登場する前は、どのデバイスにもそれぞれ専用の充電器、ケーブル、コネクタが必要でした。 USB-Cはインターフェースを標準化したため、あらゆる周辺機器が同じポートを介してどのノートパソコンにも接続できるようになりました。
のMCPは、AI統合においても同様の役割を果たします。 MCPホストとは、接続を管理するAIシステムのことです。 MCPクライアントがプロトコルを処理します。 MCPサーバーは、データベース、スケジューリングツール、臨床システム、インターネットリソースといった外部サービスです。 1つのプロトコル、あらゆるツール。
2つの主要な手法
MCPサーバーは、多くの人が想像しているよりもシンプルです。 このクラスは、主に2つのメソッドを実装しています：
- 利用可能なツールの一覧- AIエージェントが「どのようなツールが利用可能ですか？」と尋ねます。
- Callツール- AIエージェントは、「このツールにこれらの引数を指定して呼び出してください」と伝えます。
通信は、永続的な双方向接続を用
いたJSON-RPCを介して行われ、これはREST APIのステートレスなリクエスト/レスポンスパターンとは異なります。MCPサーバーは、各ツールに関する機械可読な説明（ツール名、機能、受け付ける入力、返す出力など）をレスポンスとして返します。 このAIエージェントは、誰かがカスタム統合コードを記述することなく、新しい機能に適応することができます。
MCPサーバーを支えるツールは、どの言語でも構築可能です。 「そのツールはNodeアプリでもIRISアプリでもJavaアプリでもあり得るし、クライアントはそれとはまったく別のものかもしれない」とドン氏は指摘します。. この技術に依存しない設計により、今日構築されたMCPサーバーは、基盤となる技術が進化しても引き続き機能し続けることになります。
MCP と API — 主な違い
一見すると、MCPとAPIは似ているように見えます。 どちらもシステム間でデータをやり取りします。 どちらも構造化されたリクエストとレスポンスを使用しています。 それぞれの呼び出し元についてどのような前提を置いているかを検討してみると、その違いが明らかになります。
特集 | 従来のAPI | MCP |
アーキテクチャーと通信
REST APIはステートレスなパターンに従います。 各APIリクエストは独立しています。 サーバーは、前回の呼び出しで何が起きたかを記憶していません。 コンテキストは、リクエストごとに手動で渡す必要があります。
モデルコンテキストプロトコルは、会話履歴や過去のツール結果など、やり取り全体にわたって状態を維持します。 臨床ワークフローのデバッグを行うAIエージェントは、各ステップ間の文脈を損なうことなく、患者記録を照会し、検査結果を確認し、スケジュールの重複を点検することができます。
動的検出と静的エンドポイント
これが最も重要な違いです。 従来のAPIでは、呼び出し元がすべてのエンドポイントを事前に把握しておく必要があります。 誰かがドキュメントを読み、コードを書き、統合処理をハードコーディングする。 APIが変更されると、誰かが更新するまでコードは動作しなくなります。
MCPサーバーは実行時に自身の情報を記述します。 AIエージェントはディスカバリーリクエストを送信し、利用可能なすべてのツールの構造化されたリスト（名称、説明、入力スキーマ、出力形式）を受け取ります。 事前の知識は必要ありません。 ツールごとに独自のコードはありません。
ドンはこれを長期的な利点として位置づけている：
「初めてのプロジェクトでは、あまり意味がわからないかもしれません。」 初めての「エージェントループ」を構築しています。 3つの工具を取り付け、配線を行っています。 そして、それは実際にあなたの生活を複雑にしてしまうことになるでしょう。 しかし、この状況を数年先まで想定してみると -25、75、あるいは100もの異なるツールが存在することになるかもしれません。 「そして、新しいエージェント型ワークフローを構築する必要が生じた際、これらのツールはすべて同じ方法で記述されているため、それらをすべて活用できるようになります。」
ダイナミック・ディスカバリーこそが、そのようなスケールを実現する鍵なのです。 50番目のツールも、5番目のツールと同じくらいAIにとって使いやすくなっています。
対象ユーザー
APIは、ネットワーク呼び出しを安全に行い、機密情報を保存し、エラーを適切に処理できる開発者やソフトウェアシステム向けに構築されています。 呼び出し元は、処理の流れを完全に制御できます。
MCPは、AIモデルや大規模言語モデル向けに構築されています。 これらは、自然言語を用いて推論を行うが、APIキーを保持したり、任意のコードを実行したり、独自にネットワークリクエストを行ったりすることはできない、インテリジェントではあるが信頼できないシステムです。 モデル・コンテキスト・プロトコルは、これらのモデルに対し、世界に対して構造化され、管理された方法で作用する手段を提供します。
セキュリティとガバナンス
APIでは、認証トークン、APIキー、OAuthフロー、レート制限を通じて、エンドポイントレベルでセキュリティが確保されます。 各統合機能は、それぞれ独自の認証情報を管理します。
MCPは、個々のAPIの上にガバナンス層を追加します。 MCPサーバーは、AIシステムに対してどの機能を公開するか、どのような入力が許容されるか、およびどのようなログ記録が適用されるかを制御します。 AIエージェントは、生の認証情報を一切扱いません。
規制の厳しい環境において、この分離は重要です。 これにより、認証情報の乱立を抑制し、監査を簡素化し、AIシステムを明確な運用範囲内に収めることができます。
FHIRの例え――医療チームがMCPを即座に理解できる理由
医療ITチームは、すでにこうした標準化の転換を経験してきました。
ドン氏は、この2つの事象を直接的に結びつけています：「私たちの業界では、これをFHIRサーバーのようなものだと考えてもよいでしょう」r FHIRサーバーは単なるRESTサーバーですが、患者情報の取得や更新を行う際には、特定の方法に従う必要があります。 返ってきた回答には一定の形式があり、その内容をどう解釈すべきかは分かっているはずです。 つまり、これは医療情報について議論するための標準化された方法なのです。 「MCPも同様で、ツールを参照し、結果を得ることができる標準化された方法なのです。」
この例えは的確です：
- FHIR 医療システムの システム 臨床データ交換を標準化。 FHIRが登場する前は、各EHRが独自のデータ形式、独自のAPI規約、独自の統合要件を持っていました。 FHIRはRESTの上に標準化されたレイヤーを追加したため、どのシステムでも一貫した形式で患者データを交換できるようになりました。
MCPは、AIエージェントがツールを発見し、活用する方法を標準化します。 MCP導入前は、AIを統合するたびに、外部サービスごとにカスタムコードが必要でした。 MCPは、既存のAPIの上に標準化されたレイヤーを追加することで、あらゆるAIエージェントが一貫したプロトコルを通じて、あらゆるツールと連携できるようにします。
FHIRもMCPも、既存のインフラストラクチャの上に構築されています。 どちらも、それ以前のものに取って代わるものではありません。 どちらも、時間の経過とともにその効果が相乗的に高まる形で、基盤となるシステムの相互運用性を実現します。InterSystems HealthShar e などのプラットフォームを通じて、すでにFHIR ベースの相互運用性を実現している組織にとっては
、MCP パターンは馴染み深いものとなるでしょう。 どちらにも同じ設計上の原則が当てはまります。つまり、インターフェースを標準化し、その下での実装は柔軟に変化させられるようにするということです。
MCPはAPIに取って代わるのでしょうか？
いいえ。MCPサーバーの多くは、既存のAPIをラップしたものです。
「schedule_appointment」ツールを公開しているMCPサーバーは、その裏側で病院のREST APIを呼び出している可能性があります。 課題追跡用のMCPサーバーは、ツールからの呼び出しをJiraのAPIリクエストに変換する可能性があります。 臨床データ用のMCPサーバーは、バックグラウンドでFHIRエンドポイントにクエリを送信する場合があります。
のAPIは、依然として実行層、つまり操作を実行する実際のメカニズムとしての役割を果たしています。 MCPはAIのインターフェース層となります。つまり、エージェントがこれらの操作を検出して呼び出すための標準化された仕組みです。
ドン氏は、MCPサーバーを支えるツールについて、 「『予約を入れる』といった単なるAPIに過ぎない」と説明しています。 それらは、読み書きを行う必要があるデータベースかもしれません。 インターネット上の情報源やウェブサイトかもしれません。 「社内文書やPDFなどの情報源から、何らかの情報を得られるかもしれません。」
MCPとAPIは、AIスタックにおいて互いに補完し合うレイヤーであり、競合する技術ではありません。
MCPとAPI、それぞれをいつ使うべきか
その選択は、誰が（あるいは何が）呼び出しを行うか、およびワークフローにどの程度の動的性が求められるかによって異なります。
次のような場合は、APIを直接使用してください：
- ワークフローはあらかじめ定義されており、安定しており、変更される可能性は低い
- パフォーマンスは極めて重要です（レイヤーが1つ増えるごとに、ある程度の遅延が生じます）
- AIエージェントは一切関与しておらず、これはシステム間の通信です
- データウェアハウスなどの、あらかじめ保存されているデータソースからデータを取得しています
次のような場合にはMCPを使用してください：
- AIエージェントやAIアプリケーションは、複数の外部サービスにわたるアクションを調整する必要がある
- 規制、社内プロセス、あるいは技術の更新により、ワークフローは頻繁に変更される
- 動的な検出機能が必要です。つまり、AIはカスタムコードを記述することなく、新しいツールに適応できる必要がある
- ラピッドプロトタイピングは重要です。 MCP を使えば、チームは AI エージェントを新しいデータソースやツールに、それぞれに対して個別の統合機能を構築することなく、迅速に接続することができます。
- セキュリティガバナンスは重要です。 生のAPIエンドポイントを公開することなく、AIがアクセスできる範囲を制御したい
両方を組み合わせて使用します（最も一般的なパターン）：
成熟したアーキテクチャの多くは、安定したバックエンド統合のための直接APIと、AI向けワークフローのためのMCPサーバーを組み合わせています。 APIがその役割を果たします。 MCPサーバーは、AIエージェントが制御された標準化された方法でその機能を利用できるようにします。
この階層的なアプローチこそが、 医療分野の相互運用性プラットフォームの真価を発揮する部分です。 異なるシステム間のデータを統合するインフラストラクチャは、AIエージェントが依存するMCPサーバーの稼働を支えることもできます。 これにより、既存の連携機能を、一から作り直すことなく、 AI対応の機能へと変えることができます。
エンタープライズ・ヘルスケアにおいてMCPが重要な理由
最初のプロジェクトでは、MCPの価値はすぐにはわかりません。 規模が大きくなれば、それは否定できない事実となります。
「長期戦略」――3つのツールから100へ
最初のエージェント型ワークフローでは、EHRクエリ、スケジュール確認、通知システムの3つのツールを連携させることができるでしょう。 3つのツール向けのカスタム統合コードを書くのは簡単です。
しかし、医療機関ではツールが急速に増えていくでしょう。 請求確認、保険適格性確認、薬局システム、検査依頼、臨床意思決定支援、画像診断、患者とのコミュニケーション、収益サイクル管理などを追加できます。
MCP標準に準拠した新しいツールは、すべて同じプロトコルを採用しているため、以前のツールと同様に簡単に接続できます。
「これらのツールはすべて同じ方式で構築されているため、すべてを活用できるようになります。」 「みんな同じように話す」とドンは説明する。
ベンダー・エコシステムの勢い
MCPの導入は、アーリーアダプターの枠を超えて加速しています。 " SalesforceをCRMとしてご利用の場合 、あるいは Jiraを課題管理システムとして使用している場合、これらはMCPサーバーに同梱されています, とドンは説明します。 「現在ご利用中のベンダー提供のシステムには、今後MCPサーバーが同梱されるようになります。これにより、それらのシステムを御社のエージェント型ワークフローに組み込むことが可能になります。」
医療関連ベンダーも同様の軌道をたどることになるでしょう。 EHRプラットフォーム、人口健康管理システム、収益サイクル管理ツール、および臨床分析サービスには、MCPサーバーが搭載されます。 これにより、それぞれに対して個別の統合コードを記述することなく、これらをエージェント型ワークフローに簡単に組み込むことができま す。 例えば、In
terSystems IRISは、開発チームが希望する任意の言語で臨床ワークフロー、患者情報の照会、または分析機能を提供するMCPサーバーのバックエンドとして機能することができます。 MCPクライアントと基盤となるテクノロジーとの間には独立した関係があるため、今日構築されたツールは、スタックが進化しても引き続き機能し続けます。
このパターンは、社内システムにとどまらず、さらに広い範囲に適用されます。 ドンは 「Context7」を例に挙げています。これは、各種技術に関するLLM向けのドキュメントを提供するMCPサーバーであり、インターネット規模のMCPリソースの一例です。
医療分野における同等のものとしては、薬剤相互作用データベース、臨床実践ガイドライン、あるいは処方集データなどが挙げられ、これらはMCP互換のツールとして公開されており、あらゆるAIエージェントが発見して利用できるようになっています。 このプロトコルにより、統合ごとにカスタムコードを記述することなく、大規模言語モデルを実際の臨床データソースに接続するAIネイティブなワークフローの迅速なプロトタイピングが可能になります。
よくあるご質問
結論
APIは実行層です。 MCPは、AIネイティブなインターフェース層です。 これらは連携して機能します。
医療チームにとって、これに最も近い例は、独自データ形式からFHIRへの移行です。 FHIRを早期に導入した組織は、単に相互運用性の問題を解決しただけではありませんでした。 彼らは基盤を築き、システムが次々と稼働するにつれて、その価値は相乗的に高まっていきました。 MCPは、AI統合に適用された同じパターンです。
その価値は、3つのツールを使った最初のエージェント型プロジェクトにあるわけではありません。 その答えは、100個のツールがあり、それらがすべて同じプロトコルで通信している場合に何が起こるかにあるのです。 今、AIエージェントと外部システムとの連携方法を標準化しておく組織は、ツールを追加するたびにその優位性を高めていくことになるでしょう。
