結論から言えば、MCPとAPIは代替関係ではありません。業務処理を一つのアプリケーションから決め打ちで呼ぶならAPIを直接使い、同じ機能を複数のAIホストへ発見可能な形で配るなら、既存APIの手前にMCPサーバーを置く構成が有力です。この記事を読むと、接続数、変更頻度、権限境界、12カ月総費用を材料に、直接API、MCP併用、見送りのいずれかを決められます。
MCPとAPIは接続規格ではなく再利用範囲で選ぶ
選択を一文にすると、呼び出し元と手順が固定された業務連携は直接API、AIホストが機能を探して使い分ける連携はMCP併用です。例えば、受注確定後に倉庫在庫を一回照会する基幹バッチは、呼び出すエンドポイントも入力も決まっています。ここへMCPを足しても、発見機能を使う場面がなく、障害点だけが一つ増えます。
一方、営業支援AI、社内検索AI、開発支援AIの三つから同じ在庫情報を参照する場面もあります。将来は予約処理も許可したいなら、各ホストへAPI仕様と認証処理を三重実装するより、MCPサーバーが利用可能なToolsやResourcesを提示する方が境界をそろえやすくなります。MCP公式のArchitecture（2026-07-28版）は、ホストが複数クライアントを管理し、各クライアントが一つのサーバーと1対1で通信する構成を定めています[1]。したがって「MCP対応」という看板だけでなく、接続先ごとに許可範囲を分離できるかを確認します。
| 質問 | はい | いいえ |
|---|---|---|
| 半年以内に二つ以上のAIホストから同じ機能を使うか | MCP併用を試作候補へ | 直接APIを第一候補へ |
| モデルが状況に応じて機能を選ぶ必要があるか | Toolsの設計を評価 | 固定ワークフローで十分か確認 |
| 既存APIの責任者とSLAが確定しているか | ラッパー構成を検討可能 | 接続方式より先に所有者を決定 |
選ぶ単位は「会社としてMCPかAPIか」ではなく、「一つの業務能力を、誰が、何個のAIホストから、どの権限で呼ぶか」です。
MCPとAPIは比較する層が違う
APIはアプリケーション同士の契約全般を指す広い語です。HTTP APIなら、URI、メソッド、要求・応答、認証、エラー、レート制限などを設計します。OpenAPI Specification 3.2.0は、HTTP APIを人とコンピューターが理解できる言語非依存の記述として定義し、文書生成、コード生成、試験などへ利用できると説明しています[2]。APIにはREST、RPC、イベント連携などがあり、すべてがOpenAPIで記述されるわけではありません。
MCPは、LLMアプリケーションが外部データや機能へ接続するためのアプリケーションプロトコルです。メッセージ形式にはJSON-RPC 2.0を使います。JSON-RPC 2.0自体は、リクエストの`method`、`params`、`id`と、レスポンスの`result`または`error`を定める軽量RPC仕様です。HTTPにも標準入出力にも依存しません[3]。MCPはその上でTools、Resources、Prompts、発見、能力表明、認可などAI連携に必要な意味を追加します。
この境界を曖昧にすると、「既存APIをMCPへ移行する」という誤った計画になります。実際の変更は、在庫APIを廃止するのではなく、`GET /v1/inventory/{sku}`を呼ぶ`inventory_lookup` ToolをMCPサーバーに登録する形です。APIの利用契約は残り、MCP側にはモデルが誤解しにくい説明、JSON Schema、利用者の同意、ホスト間の互換を追加します。RESTの原典であるFieldingの博士論文は、ネットワークアーキテクチャを制約と品質特性の組み合わせとして評価しています[6]。同じ考え方で、流行語ではなく結合度、可視性、性能、保守性を比べるのが妥当です。
九つの軸で直接APIとMCP併用を比べる
比較条件は「同じ在庫API、同じ読み取り権限、同じ20件のSKU、同じ合格結果」に固定します。MCP案だけに便利なAI機能を足したり、API案だけを古い認証方式のままにしたりすると、接続方式ではなく実装世代の差を測ることになります。次の表で「API」は業務APIをアプリケーションコードから直接呼ぶ案、「MCP」は業務APIをMCPサーバー経由でAIホストへ公開する案です。
| 評価軸 | 直接API | MCP併用 | 確認証跡 |
|---|---|---|---|
| 主な呼び出し主体 | 決め打ちしたアプリケーション処理 | AIホスト内のモデルまたは利用者 | シーケンス図 |
| 機能の発見 | 仕様書や生成クライアントを配布 | `tools/list`などで提示 | 取得した一覧JSON |
| 入力契約 | OpenAPIや個別スキーマ | Toolの`inputSchema` | 境界値試験 |
| 再利用先追加 | 統合先ごとにコードと認証を追加 | 対応ホストなら同一サーバーを候補化 | 二つ目のホストでの工数 |
| モデル依存 | 固定処理ならモデル不要 | Tool選択精度をモデル別に評価 | モデルID別成功率 |
| 認可 | API固有のOAuthやAPIキー | HTTPではMCP認可仕様も適用 | scopeとaudience一覧 |
| 観測点 | API Gatewayとアプリログ | ホスト、MCP、業務APIの三層 | 同一相関ID |
| 障害範囲 | 呼び出しアプリとAPI | MCP変換層の障害が追加 | 切り分け手順 |
| 撤退容易性 | 利用コードの置換が必要 | MCPを外してAPI直結へ戻せる設計が必要 | 切り戻し試験 |
MCPのTools仕様では、サーバーがTool能力を表明し、クライアントが`tools/list`で一覧を取得し、`tools/call`で実行します。Toolの入力はJSON Schemaで記述し、スキーマ指定がなければ2020-12が既定です[4]。これはAPIの業務契約を置き換える規定ではなく、AIホストに見せる操作面の契約です。比較表ではこの二層を分けて採点してください。
直接APIが小さく収まる案件
東都産業の夜間補充バッチを考えます。毎日2時に1,000 SKUを照会し、在庫5個未満だけ購買キューへ送る処理です。呼び出し元は一つ、判定式は固定、利用者との対話はなく、出力も構造化データです。この案件ではモデルが機能を選ぶ余地がないため、MCPの発見と説明は価値を生みません。OpenAPIから型付きクライアントを生成し、API Gatewayで認証と流量を管理する方が、構成要素と障害点を少なくできます。
もう一つの判断基準は決定性です。「同じ入力なら同じ処理を必ず行う」「法定帳票への転記で手順変更を許さない」「1件の誤実行が出荷停止へつながる」といった業務は、AIホストにTool選択を委ねず、明示的なコードで順序を固定します。AIが説明文を作る工程だけ別に置くことはできますが、在庫引当や送金の実行経路までMCP化する必要はありません。
直接API案を採用できる条件
- 本番の呼び出し元が12カ月間に一つで、追加計画が承認されていない。
- 入力項目と分岐が仕様書で完結し、自然言語から操作を選ぶ工程が存在しない。
- 既存のSDK、監視、レート制限、障害当番をそのまま利用できる。
- 利用者へ機能一覧を動的に見せる要件がなく、変更はリリース管理で配布できる。
向かないのは、AIホストごとに同じラッパーを複製し始めた場合です。二つ目の統合で認証、入力変換、エラー変換の70%以上が重複したら、直接APIの前提が崩れています。三つ目を作る前に共通MCP層または共通SDKへ設計を戻します。
MCPを重ねる価値が出る案件
MCPが効くのは、「何を呼ぶか」を会話の文脈で変えたいときです。営業担当が「SKU A-104の大阪倉庫在庫と、欠品なら次回入荷予定を調べて」と依頼する場面では、AIホストは在庫照会、入荷予定、倉庫マスターという複数機能から必要なものを選びます。MCPサーバーが各Toolの説明とスキーマを同じ形式で公開すれば、営業支援AIと社内検索AIの双方へ同じ境界を提示できます。
ただし、MCP対応ホストなら自動的に再利用できるわけではありません。ホストが2026-07-28仕様を扱えるか、必要なTransportを実装しているか、OAuthのscopeを利用者へ表示できるか、Tool結果の構造化データを保持するかを確認します。MCPの正式仕様は、ホストが同意とセキュリティ方針を管理し、サーバーは他サーバーや会話全体を見ないという境界を置いています[1]。ホストが全Toolを無条件にモデルへ渡す設計なら、プロトコル準拠でも社内統制には不十分です。
| 条件 | 合格基準 | 不足時の判断 |
|---|---|---|
| 再利用先 | 異なるAIホストが2系統以上 | 1系統ならAPI直結を継続 |
| 機能選択 | 代表依頼20件で選択理由を説明可能 | 固定順ならワークフロー化 |
| 権限分離 | 読み取りと更新を別scopeに分割 | 一括権限しかないなら更新Toolを公開しない |
| 所有者 | MCP層と元APIの障害担当を特定 | 責任境界が決まるまで本番化しない |
既存APIを残した併用構成
推奨構成は、業務APIを正本として残し、その前に薄いMCPサーバーを置く形です。MCPサーバーは入力スキーマの検証、利用者コンテキストからAPI用資格情報への交換、APIエラーのTool結果への変換を担当します。価格計算、在庫引当、監査番号の発番といった業務規則はAPI側から移しません。二重実装を避けることで、Web画面、バッチ、AIホストが同じ業務規則を利用できます。
AIホスト └─ MCPクライアント └─ inventory-mcp ├─ Tool: inventory_lookup ├─ Tool: arrival_schedule └─ Resource: warehouse://policy/current └─ Inventory API v3.4 └─ 在庫DB（正本）
Tool名をAPIパスの機械的な写しにしないことも重要です。`get_v1_inventory_sku`では、モデルも利用者も目的を判断しにくくなります。`inventory_lookup`に「SKUを完全一致で照会し、倉庫別の販売可能数を返す。予約や更新は行わない」と記述し、入力を`sku`と任意の`warehouse_id`に絞ります。戻り値には`available_units`、`as_of`、`source_system`を含め、自然言語だけで数値を返さない設計にします。
{ "name": "inventory_lookup", "description": "SKUの販売可能在庫を照会する。数量の更新や予約は行わない", "inputSchema": { "type": "object", "properties": { "sku": {"type": "string", "pattern": "^[A-Z]-[0-9]{3}$"}, "warehouse_id": {"type": "string", "enum": ["TOKYO", "OSAKA"]} }, "required": ["sku"], "additionalProperties": false }}
HTTPベースのリモートMCPでは、MCPサーバーはOAuthのResource Serverとして受け取ったトークンの対象を検証します。上流APIへアクセスするときは、その受信トークンを横流しせず、別のトークンを取得する必要があります。2026-07-28版Authorizationは、MCPクライアントが認可要求とトークン要求の両方に`resource`を含め、サーバーが自分向けのトークンだけを受け入れるよう定めています[5]。併用構成の価値は、この境界を省略することではなく、繰り返し実装を一カ所へ集める点にあります。
12カ月総費用を同じ式で試算する
初期開発費だけなら直接APIが安く見えやすく、接続先が増えた後だけを見るとMCPが有利に見えます。そこで、初期構築、接続先追加、月次保守、監視基盤、回帰試験を12カ月でそろえます。以下は架空企業の想定工数であり、実績値ではありません。1人日を8時間、社内原価を1時間8,000円として計算します。
12カ月総費用 = 初期構築時間 +（追加接続数 × 1接続あたり追加時間） +（月次保守時間 × 12） +（仕様変更回数 × 回帰試験時間）直接API案: 80 + (2 × 48) + (10 × 12) + (3 × 16) = 344時間 344 × 8,000円 = 2,752,000円MCP併用案: 152 + (2 × 16) + (14 × 12) + (3 × 24) = 424時間 424 × 8,000円 = 3,392,000円
この条件ではMCP案が640,000円高いため、費用だけなら直接APIを選びます。ただし、四つ目と五つ目のAIホストが確定し、直接APIの追加が各48時間、MCPが各16時間のままなら差は64時間縮みます。損益分岐となる追加接続数は、初期差72時間と月次・回帰差72時間の合計144時間を、接続1件の差32時間で割った4.5件です。つまりこの想定では、既存の一件に加えて五件程度の追加が見込めるまで、MCPの純粋な工数優位は出ません。
ここへモデル評価費を忘れず加えます。MCPではTool説明を変更すると選択精度が変わるため、本番モデルごとの回帰が必要です。直接APIでもAIが呼び出し判断をするなら同じ費用が発生します。モデルを使わない固定連携と、モデルに選択させる連携を同じ「API案」と呼ばないよう、見積書にモデルID、代表依頼件数、再試験頻度を記載します。
失敗例から停止条件を先に決める
失敗例1は、MCPサーバーを万能ゲートウェイにすることです。在庫、顧客、請求、勤怠を一つのサーバーへ集め、すべてのToolを全ホストに見せると、変更時の影響範囲と権限が膨らみます。MCP Architectureが示す「焦点を絞ったサーバー」という設計原則にも反します[1]。業務所有者またはデータ境界が異なるならサーバーを分け、ホスト側で必要な接続だけを許可します。
失敗例2は、APIエラーを自然文へ丸めることです。`429`、`503`、入力不備をすべて「取得できませんでした」にすると、再試行すべきか、入力を直すべきか、人へ渡すべきか決められません。MCPのTool結果には利用者向け説明と構造化されたエラー種別を併記し、元APIの相関IDを残します。資格情報、個人情報、内部スタックはモデルへ返しません。
失敗例3は、AIホストごとの挙動差を無視することです。同じTool一覧でも、モデル、システム指示、確認UIによって自動実行率は変わります。20件中19件成功したホストAの結果を、ホストBの合格証拠にはできません。ホストとモデルの組み合わせごとに、読み取り、更新拒否、曖昧入力、権限不足を再試験します。
| 停止条件 | 理由 | 再開に必要な証拠 |
|---|---|---|
| 更新Toolが確認画面なしで実行される | 誤操作を利用者が止められない | 対象ホストで拒否・承認の両経路を再現 |
| APIとMCPで在庫値が1件でも不一致 | 変換層が業務結果を変えている | 同一時刻・同一SKUで差分ゼロ |
| audience不一致トークンを受理 | 別サービス用権限が流用される | 負例試験で401を確認 |
| 障害の一次担当が10分以内に決まらない | 三層化で復旧が遅れる | 訓練でAPI側かMCP側かを切り分け |
採用に向かないケース：元APIに入力検証、監査ログ、所有者がなく、MCPを置けば欠落を隠せると考えている案件です。先に業務APIの契約と責任を整えない限り、AI向け接続面を増やしてはいけません。
20件のPoCと採点表で採否を決める
PoCはデモの成功ではなく、選択肢を落とす試験です。テストデータは正常10件、境界値4件、権限不足3件、上流障害2件、曖昧依頼1件の計20件とします。SKUと期待結果は固定し、直接API案とMCP案の双方へ同じ入力を与えます。AIを介するMCP案では、Toolを選んだか、引数が正しいか、結果を改変せず表示したかを別々に採点します。
| 項目 | 配点 | 満点条件 | 失格条件 |
|---|---|---|---|
| 業務結果の一致 | 30 | 20件すべてでAPI正本と一致 | 更新結果または数量が1件でも相違 |
| Tool選択と引数 | 20 | 正常・境界14件で誤選択ゼロ | 更新Toolの無断選択 |
| 権限と同意 | 20 | 負例3件を拒否し理由を表示 | 他利用者のデータを返却 |
| 復旧と観測 | 15 | 2障害を10分以内に層別判定 | 相関IDが追跡不能 |
| 追加接続工数 | 10 | 二つ目のホストを16時間以内で接続 | 直接API案より追加工数が大きい |
| 撤退可能性 | 5 | API直結へ4時間以内で切り戻し | 業務データの移行が必要 |
合計85点以上かつ失格条件ゼロを限定本番、70〜84点を再試験、69点以下を見送りとします。この閾値は東都産業の想定ルールであり、業界標準ではありません。読み取り専用の在庫照会だから85点としています。契約締結、送金、医療判断など不可逆性が高い処理は、合計点ではなく必須条件だけで判定し、自動実行を認めない設計も選択肢に含めます。
結果表にはモデル名だけでなく、モデルID、AIホスト版、MCP SDK版、MCP仕様版、Tool定義のハッシュ、元API版、実行日時を残します。モデル更新後に成功率が95%から85%へ落ちても、記録がなければTool説明の変更かモデル変更かを切り分けられません。PoCの目的は高い数字を作ることではなく、再現できる比較条件を確立することです。
移行・乗り換え・撤退の出口を作る
API直結からMCP併用へ移る場合は、いきなり呼び出しを切り替えません。第1段階で読み取りToolだけを作り、APIレスポンスとMCPの構造化結果を並行比較します。第2段階で一つのAIホストへ限定し、更新系は非公開のままにします。第3段階で二つ目のホストを追加し、再利用工数が想定内か確認します。接続先が一つのままなら、MCP化の根拠を再審査します。
MCP製品やSDKを乗り換えるときは、プロトコル準拠だけでなく拡張依存を棚卸しします。独自Tool注釈、独自認証ヘッダー、ホスト固有の確認UI、独自Transportを使っていれば、標準MCPサーバーへ移しても同じ動作にはなりません。移行台帳には標準機能、ベンダー拡張、社内コードを分け、標準機能だけで20件の回帰試験を通せるかを確認します。
撤退時に守る順序
- AIホストから更新Toolを外し、新規実行を停止する。
- 処理中の相関IDを一覧化し、完了、失敗、不明へ分ける。
- 読み取りをAPI直結へ戻し、同じSKUで結果を照合する。
- MCP用scopeとクライアント登録を失効させ、残存トークンを確認する。
- 監査ログの保管期限を維持したまま、サーバーを停止する。
撤退判断は「MCPが悪いから」ではなく、前提が変わったかで行います。追加AIホストが12カ月でゼロ、月次保守が14時間を3カ月連続で超過、重大な権限事故が1件発生、直接APIへの切り戻し試験が4時間を超過、正式仕様への追随が一版以上遅延、のいずれかを再審査トリガーにします。再審査後も再利用価値が費用とリスクを上回らなければ、API直結へ戻します。
MCPとAPIの選択でよくある質問
MCPを導入すれば既存APIは不要になりますか？
不要にはなりません。MCPサーバーが既存APIを呼ぶ構成は一般的で、APIは業務処理とデータ契約、MCPはAIクライアント向けの発見と呼び出し契約を担当します。元APIを正本に残せば、バッチやWeb画面と業務規則を共有できます。
AI機能が一つだけでもMCPを選ぶべきですか？
接続するAIホストが一つで呼び出し手順も固定なら、直接APIの方が小さく保てます。半年以内に複数ホストへ展開する具体計画がある場合はMCPの試作価値があります。「いつか増える」だけでは初期差を回収できません。
MCPとAPIのPoCでは何を同じ条件にしますか？
同じ業務API、同じ権限、同じ20件以上のテストデータ、同じ合格条件を使います。モデルの出力品質と接続層の成否を混ぜず、発見、入力検証、認可、復旧を別々に記録します。
MCP化を中止する代表的な条件は何ですか？
対象AIホストが必要なMCP仕様へ対応しない、権限をTool単位に絞れない、既存APIの障害責任が曖昧になる、12カ月総費用が直接API案を上回るのに再利用先が増えない場合は中止候補です。
MCPとAPIの選定会議へ持ち込む一枚を作る
次の行動：業務責任者は次の会議までに、対象業務を一つに絞ります。そのうえで、呼び出し元の現在数と12カ月後の確定数、元APIの所有者、読み取り・更新の権限、代表データ20件、直接APIとMCP併用の12カ月工数を一枚へ記載します。追加接続が未承認ならゼロとして計算し、期待だけでMCP案を有利にしないでください。会議の結論は「全面採用」ではなく、直接API継続、読み取り限定PoC、前提不足による保留の三択にすると、次の作業が明確になります。
併せて、PoCを止める責任者と判定日を右上へ置きます。例えば、権限外のToolが一度でも表示された場合、上流APIのトークンをMCPサーバーが転送した場合、または20件中19件以上という受入基準を下回った場合は、その場で本番候補から外すと明記します。再開には修正版の権限表、負例の再試験結果、費用差の再計算を必須とし、接続成功だけで採用判断を進めない運用にします。
参考文献・出典
- Model Context Protocol「Architecture」（Protocol Revision 2026-07-28、参照日2026-07-30）
- OpenAPI Initiative「OpenAPI Specification v3.2.0」（Version 3.2.0、2025-09-19、参照日2026-07-30）
- JSON-RPC Working Group「JSON-RPC 2.0 Specification」（2013-01-04更新、参照日2026-07-30）
- Model Context Protocol「Tools」（Protocol Revision 2026-07-28、参照日2026-07-30）
- Model Context Protocol「Authorization」（Protocol Revision 2026-07-28、参照日2026-07-30）
- Roy T. Fielding「Architectural Styles and the Design of Network-based Software Architectures」（博士論文、University of California, Irvine、2000年、参照日2026-07-30）
