システム連携の話をしていると、API・FHIR・MCPという3つの言葉が同時に出てきます。「結局どれを選べばいいのか」と聞かれることがありますが、この3つは選択肢ではありません。層が違うため、同時に成立します。
本記事では、3つの関係を整理し、電子カルテの選定や商談でどう効いてくるかまで扱います。
免責：本記事は一般的な情報提供です。規格の仕様や普及状況は変わり得ます。導入検討時は最新情報をご確認ください。
結論——3つは層が違う
先に結論を置きます。
| 何を決めるもの | ひとことで言うと | 例え | |
|---|---|---|---|
| FHIR | 医療データの表し方 | データの形 | 書類の書式 |
| API | データの受け渡し方 | 窓口の仕様 | 書類の提出窓口 |
| MCP | AIから見た窓口の並べ方 | AIが選べる形の窓口 | 窓口の案内板をAIが読める形にしたもの |
FHIRで整えたデータを、APIで受け渡し、その窓口をMCPの形でAIに見せる——これが同時に成立している状態です。どれか一つを選ぶ話ではありません。
FHIR——データの「形」を決める
FHIR（Fast Healthcare Interoperability Resources） は、医療データを表現するための国際的な規格です。HL7という団体が策定しています。
たとえば「血液検査の結果」を記録するとき、施設ごと・システムごとに項目名も単位も並び順もバラバラだと、受け取った側は解釈できません。FHIRは「検査結果はこういう項目の組で表す」という共通の書式を定めます。
FHIRが決めるのはデータの中身と構造であって、それをどう届けるかではありません。同じFHIR形式のデータを、ファイルで渡すこともAPIで渡すこともできます。
日本では、国の標準化の中でFHIRの採用が進んでいます。標準型電子カルテとは、電子カルテ情報共有サービス をご覧ください。旧来から使われている SS-MIX2 も同じ「データの形」の層にある規格です。
API——データの「受け渡し方」を決める
API は、あるシステムが外部に提供する窓口の仕様です。「この形式で問い合わせれば、この形式で返す」という約束事を指します。
APIが決めるのはやりとりの手順であって、中身の形式ではありません。だからこそ「FHIR形式のデータを返すAPI」という組み合わせが成立します（FHIR自体もAPIの作法を定義していますが、層としては別に考えると整理しやすくなります）。
APIの基礎は APIとは？クリニックのシステム連携を理解するための基礎知識 で扱っています。レセコンとの連携という具体例は 電子カルテとORCAの連携 をご覧ください。
MCP——AIから見た「窓口の並べ方」を決める
MCP（Model Context Protocol） は、AIが使うことを前提に、窓口を統一した形で並べるための規格です。
従来のAPIとの決定的な違いは、AIが自分でどの窓口を使うか判断できる点にあります。APIは人間の開発者が「この場面ではこのAPIを呼ぶ」と書き込む必要がありました。MCPでは、使える窓口の一覧と、AIが読める説明文がAIに提示され、AIが状況に応じて選びます。
MCP自体の詳細は MCPとは？AIが外部のデータやツールとつながる仕組み、窓口を提供する側の部品については MCPサーバーとは？ をご覧ください。
具体例で追う——「直近のHbA1cを取る」
抽象論だとわかりにくいので、一つの操作を3層で追いかけます。
FHIRの層（データの形）
検査結果は Observation という単位で表され、「何の検査か（LOINCコード）」「値」「単位」「いつ測ったか」「誰の」がそれぞれ決まった項目に入ります。HbA1cであれば、施設が違っても同じコードで表されます。
APIの層（受け渡し方） 「患者IDと検査コードを指定して問い合わせると、該当する検査結果を返す」という窓口が用意されます。呼び出し方、認証の仕方、返ってくる形式が決まっています。
MCPの層（AIから見た窓口）
get_lab_results（仮称）というツールが、「患者IDと検査項目を受け取り、直近の検査結果を返します」という説明付きでAIに提示されます。AIは「直近のHbA1cは？」と聞かれたとき、この説明を読んで自分でこのツールを選び、必要な引数を組み立てて呼び出します。
3層の役割の違いが見えるはずです。
- FHIRがなければ → 値は返ってくるが、施設ごとに項目名が違い、解釈にコストがかかる
- APIがなければ → そもそもシステムの外から取れない
- MCPがなければ → 取れるが、「どのAPIをいつ呼ぶか」を人間が事前に書き込む必要がある
比較表
| 観点 | FHIR | API | MCP |
|---|---|---|---|
| 決めること | データの構造・意味 | やりとりの手順 | AIが選べる窓口の並べ方 |
| 主な利用者 | システム同士 | 人間の開発者 | AI |
| 説明の与え方 | 仕様書を人が読む | ドキュメントを人が読む | AIが読める形で提示 |
| 医療専用か | 医療専用 | 汎用 | 汎用 |
| 標準化の担い手 | HL7（国際）／国の施策 | サービスごと | Anthropic発のオープン仕様 |
| これがないと困ること | 施設間でデータが噛み合わない | 外部から取得できない | AIが自律的に使えない |
医療専用なのはFHIRだけという点は、押さえておく価値があります。APIとMCPは業界を問わない汎用の仕組みで、医療のデータ構造には踏み込みません。
「FHIRがあればMCPは不要」ではない
よく出る誤解を2つ潰しておきます。
誤解①「FHIRで標準化されていればAIは使える」 FHIRはデータの形を揃えますが、AIがどの窓口をいつ使うかは決めません。AIに自律的に扱わせるには、AI向けに窓口を提示する層が別途必要です。
誤解②「MCPがあればFHIRは不要」 逆も成り立ちません。MCP経由で取れたデータが施設ごとにバラバラの形式なら、AIは解釈に苦労し、精度も安定しません。きちんと標準化されたデータほど、MCP経由でAIが扱いやすくなります。
つまり両者は補完関係です。標準化されたデータの価値は、AI時代に下がるどころか上がります。
医療機関の実務での意味
3層のどこが弱いかで、起きる問題が変わります。
FHIRの層が弱いと → データ移行のたびに変換作業が発生し、施設間の情報共有が進まない。電子カルテのデータ移行、ベンダーロックイン で扱った問題です。
APIの層が弱いと → 周辺システムとの連携がすべて手作業になる。予約、Web問診、検査機器、決済——それぞれが孤立します。
MCPの層が弱いと → AIを入れても「一般論しか答えられないAI」にとどまる。院内データを見られないAIは、カルテ業務では使いものになりません。
電子カルテ選定でどう効くか
商談で聞くべき質問を、層ごとに整理します。
FHIRの層
- 標準規格（HL7 FHIR／SS-MIX2）でのデータ出力に対応していますか
- 解約時、患者データを標準形式で受け取れますか
APIの層
- 外部システム連携用のAPIは公開されていますか。追加費用は
- 連携できる周辺システムの実績を教えてください
MCPの層
- AI連携用の窓口（MCPサーバー等）の提供予定はありますか
- AIが参照できる範囲は院内で設定できますか
- AIは職員の権限を超えてアクセスできない設計ですか
この3つを分けて聞けるかどうかで、商談の解像度が変わります。「AI対応していますか」と一括で聞くと、どの層の話をされているのかわからない回答が返ってきがちです。
電子カルテ選定の全体像は 電子カルテ比較2026、AIカルテの比較観点は AI電子カルテ比較2026 をご覧ください。
まとめ
- FHIR・API・MCPは競合しない。層が違う
- FHIR＝データの形（医療専用・国際規格）、API＝受け渡し方（汎用）、MCP＝AIが選べる窓口の形（汎用）
- 同じ操作でも、FHIRが値の意味を、APIが取得手段を、MCPがAIによる選択を担う
- 「FHIRがあればMCPは不要」も「MCPがあればFHIRは不要」も誤り。標準化されたデータほどAIで活きる
- 層ごとに弱点の症状が違う：FHIR弱→移行と共有が詰まる、API弱→周辺連携が手作業、MCP弱→AIが一般論しか答えない
- 商談では3層を分けて質問すると回答の精度が上がる
AIカルテの詳細やデモをご希望の場合は お問い合わせ からご連絡ください。