「うちのシステムも MCP に対応すべきか」
「これからは API ではなく MCP なのか」
——こうした声を聞くことが増えました。しかし、流行しているからといって安易に飛びつくのは危険です。
そこで編集部では、両側の一次仕様書の突き合わせと、IT連携マップ で公開している MCP サーバー（POST https://renkeimap.jp/mcp・読み取り専用）の実装経験に基づいて、8 つの問いを調べました。
性能は測っていません。「速い／遅い」「安定している」といった主観は書きません。書けるのは「仕様書が何を義務づけているか」「公開資料から確かめられた実態」、そして「自分で 1 つ実装して分かったこと」だけです。
先に結論の数字を出します。母数は、編集部が一次調査を終えて公開している日本の業務システム 56 件です。
- 56 システム中、API を提供しているのは 47 件、MCP サーバーを出しているのは 14 件（25.0%）。
- MCP だけで API が無いシステムは 0 件（14 件すべてが API も提供）。
- API 形式まで読めた範囲では REST 系 31 件、SOAP 3 件、GraphQL 1 件、gRPC 0 件。16 件は形式が非公開。
以降は 1 問 1 図で、それぞれの根拠を示します。
問い1：MCP と API は何が違うのか
RESTやGraphQLといったAPIと、MCPの最大の違いは 「誰が呼ぶか」 です。
- 結論：APIは「人間」が仕様書を読み、決定論的なプログラムを書いて呼び出します。一方、MCPは「AIエージェント」が呼びます。
-
MCPにしかできないこと：プロトコルレベルでの 「実行時の動的自己紹介（
tools/list）」 と「機能変更通知」です。AIは実行時にサーバーへ「今何ができる？」と問いかけ、その場でツール一覧を受け取って行動を選択します。これは静的な仕様書（OpenAPI等）にはない、MCP特有の機能です。 - API 側の形式（REST / SOAP / GraphQL / gRPC）の違いそのものは、APIの種類と選び方 で整理しています。
問い2：MCP と API、どちらが重要か
「これからはMCPの時代だからAPIは不要になるのでは？」という誤解があります。
- 結論：圧倒的に APIの方が重要 です。
- 規格書において、MCPサーバーは「OAuth 2.1 資源サーバー」として振る舞うことが定められています。また、入力スキーマ検証、アクセス制御、レート制限の実装が MUST（必須要件） とされています。つまり、MCPサーバーを構築するには、セキュアな Web API を作るのと同等以上のインフラ基盤が要求されます。
- 図の矢印は下から上へ向いています。 土台があるから上に載せられる、という順序がそのまま投資の順序です。認証と流量制限については OAuth・APIキー・データの保管場所を 56 件で調べた記事 が詳しいです。
問い3：AI は MCP をどうやって発見し、接続するのか
「MCP対応すれば、世界中のAIが勝手に自社システムを見つけてくれる」というのは幻想です。
-
結論：現状のエコシステムにおいて、AIがインターネット上のMCPサーバーを自律探索することはありません。
-
発見の第一歩は、「人がそのサーバーの在り処（起動コマンドか URL）を与える」 ことです。AI クライアント（Cursor や Claude など）は、与えられて初めてそこへ繋ぎます。
-
ただし「設定ファイルに書く」作業まで人がやるとは限りません。 ここはクライアントで分かれます。同じ 1 文（「この URL の MCP サーバに繋いでもらえますか？」）を投げた実測では、開発者向けの Antigravity は
mcp_config.jsonを自分で更新して接続まで済ませ、消費者向けの Claude アプリは「私の側から MCP サーバーを追加することはできない仕様です」と答えて設定画面での操作を案内しました（2026-09-08 実測）。
-
つまり発見（誰が在り処を知るか）と設定（誰がファイルを書くか）は別の段で、人に固定されているのは前者だけです。「MCP 対応すれば AI が勝手に見つけてくる」は今も幻想ですが、「人が全部手で設定する」も正確ではありません。
-
接続形態には、手元PCで標準入出力を使う「ローカル型（stdio）」と、HTTP通信する「リモート型（Streamable HTTP）」の2種類があります。いずれも設定が入った後に、AIが接続して
tools/listを要求することで、初めて機能を発見します。 -
編集部の MCP サーバーもリモート型です。
https://renkeimap.jp/mcpを AI クライアントに登録すると、initializeの応答はprotocolVersion: 2025-06-18/serverInfo: renkeimap-info 0.1.0/capabilities: toolsを返します。 -
バージョンの決め方は 2026-07-28 リビジョンで変わりました。 それ以前（規格が Legacy と呼ぶ 2025-11-25 以前）は
initializeで版を握手し、サーバーは要求された版に対応していれば同じ版を、対応していなければ自分が対応している別の版を返します（いずれも MUST・Lifecycle）。2026-07-28 では握手そのものを廃し、版は毎リクエストが_metaで名乗り、サーバーは未対応ならUnsupportedProtocolVersionError（-32022）で対応版の一覧を返します（Versioning）。既存クライアントを受けるサーバーは、当面どちらの方式も想定しておく必要があります。
問い4：日本と国際主流システム、いま何件が出しているのか
実際の業務システムの対応状況はどうなっているのでしょうか。
- 結論：日本の業務システム56件の調査では、MCP提供は14件（25.0%）です。そして、MCPを提供している14システムは全件がAPIも提供しています（MCPのみ提供は0件）。
- 国際的な主流SaaS（Salesforce、Shopify、GitHub など）は、機械可読なOpenAPI 3.xやGraphQLスキーマの公開が標準化しており、OAuthインフラも成熟しています。この「API層の成熟」があるからこそ、MCP対応が進んでいます。
- 日本でMCP対応が進まない本質的理由は、MCPという新規格のせいではなく、「APIはあっても仕様書はNDA締結後」「機械可読な仕様書が配られていない」といった 土台となるWeb APIのオープン性の欠如 にあります（API はあるのに繋がらない）。
- 個別の系統がいま何を公開しているかは、IT連携マップ の各システムのページで、出典と調査日つきで見られます（例：freee会計 / kintone / マネーフォワード クラウド会計）。
問い5：MCP 対応で注意すべきセキュリティ問題
AIエージェントの自律性ゆえに、人間の利用を前提とした従来のAPIよりも厳格な防御が求められます。
-
結論：MCP仕様書は、以下の対策をサーバー側に MUST（義務） として課しています。
- 間接プロンプトインジェクション対策：外部から取得したデータをそのままAIに返さず、無害化（Sanitize tool outputs）する。
- DDoS化の防止：AIの超高速な試行錯誤による負荷を防ぐため、HTTP 429等の厳格な流量制限（Rate limit tool invocations）を課す。
- 破壊的変更の防止：AIには「読み取りのみ」の最小権限を与え、書き込みツールには人間による承認（HITL）を必須化する。
- 編集部の実装では、この 3 つを「全ツール読み取り専用」「IP ごとの日次上限」「一覧系は 10 件で打ち切り」という形で満たしています。
問い6：API と同じ機能をすべて提供すべきか
既存のAPIが100個のエンドポイントを持っているからといって、それをすべて直訳してMCPで公開すると、AIは破綻します。
- 結論：APIの「細粒度（Fine-grained）」な設計をそのままMCPに持ち込むのはアンチパターンです。
- 全エンドポイントのスキーマを渡すと、LLMのコンテキストを大量に消費し、コストが跳ね上がります。また、似たようなツール名が増えることでAIが取り違えやすくなります。
- MCPで公開するツールは、AIが迷わず扱える 「10〜20個程度の、読み取り中心の粗粒度（Coarse-grained）な目的別タスク」 に絞り込むのがベストプラクティスです。
- 編集部の MCP サーバーは 5 つです（システムを探す／1 系統の事実を返す／2 系統が繋がるかを返す／稼働状況を返す／エラー文の対処を返す）。サイトの HTML と同じデータ経路・同じ判定を通しており、MCP 用に第二のデータ経路は作っていません。
問い7：自社システムに MCP は必要か
「APIが無いから、代わりにMCPを作って一気にAI対応しよう」という近道は存在しません。MCPを採用すべきかは、自社の足元にあるAPI基盤の整備状況 によって3つの状態に分かれます。
- 結論：MCPは「既存の堅牢なAPI」の上に乗る薄いラッパーです。APIが存在しない場合は、まず汎用的なWeb API（REST等）を作るのが先決です。APIがあっても認証が「APIキーのみ」だったり、呼び出し回数の上限（レート制限）が未実装であれば、自律的にループを回すAIに開放するのは危険です。
- 「薄いラッパー」の実物として、編集部の実装を挙げておきます。既存のサイトが使っている読み込み口と判定をそのまま呼び、MCP 側に足したのは JSON-RPC の受け口とツールの説明文だけです。土台が無い状態からこの層だけを作ることはできません。
問い8：MCP を「目次」として提供し、API と併用する構成でよいか
-
結論：よい。それが規格の形そのものです。 MCP が持つ
tools/list/resources/list/prompts/listは、いずれも「今ここに何があるか」を返す一覧であり、目次にあたります。本体（業務の全機能・書き込み・確定処理）は API 側に残ります。 - 実測もこの形を裏づけています。MCP を出している 14 件は全件が API も出しており、MCP だけの提供は 0 件でした。
- 設計の指針としては、目次を厚くするのではなく、本体を機械可読に整えるほうが先です。目次に載せるのは、読み取り中心の粗い単位（問い6）に絞ります。
まとめ：AIエージェントの波に乗るために
AIエージェントの時代が到来しても、基盤となるインフラの原則は変わりません。「MCPを作ればAPIは不要になる」のではなく、「セキュアで機械可読な API があるからこそ、MCP を載せることができる」 のです。
編集部の MCP サーバーは renkeimap.jp/mcp で公開しています。日本の業務システムの接続仕様を、出典と調査日つきで返します。
この記事の調査範囲について
-
一次規格と公開資料を読み、そのうえで編集部自身が MCP サーバーを 1 つ実装して確かめました（
POST https://renkeimap.jp/mcp・読み取り専用）。ただし性能（応答速度・スループット）は測っていません。 - 仕様書の引用はすべて公式ドキュメントからの逐語引用です（取得日: 2026-09-02〜2026-09-08）。MCP の仕様は現行の 2026-07-28 リビジョンに基づいています。
- 台帳の集計値（56 システム）は、編集部が一次調査を完了して公開している業務システムを対象としています。公開資料から仕様が読み取れなかった 16 システムが存在するため、日本全体の比率として単純に一般化することはできません。
読んだ一次資料
読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。
【転載OK】本記事の転載について
本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。
※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。 文中の「編集部」は、筆者が所属する IT連携マップ編集部 のことです。誤りを見つけられましたら 訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。