IT連携マップシステムどうしのデータ連携・接続仕様のまとめ

調査記事 › 決める

目次
  1. 3 分で読む
    1. 問い1：MCP と API は何が違うのか
    2. 問い2：MCP と API、どちらが重要か
    3. 問い7：自社システムに MCP は必要か
    4. まとめ：AIエージェントの波に乗るために
  2. 調査の詳細
    1. 問い3：AI は MCP をどうやって発見し、接続するのか
    2. 問い4：日本と国際主流システム、いま何件が出しているのか
    3. 問い5：MCP 対応で注意すべきセキュリティ問題
    4. 問い6：API と同じ機能をすべて提供すべきか
    5. 問い8：MCP を「目次」として提供し、API と併用する構成でよいか
    6. 調べた範囲と、調べていないこと

自社システムに MCP は要るか — 8 つの問い

導入前 — この製品を入れてよいか・いまの契約で使えるか最終更新 2026-09-14約 1,700 字（＋調査の詳細 約 4,200 字）Qiita 版（編集部メンバーの記事・図解の要約）

3 分で読む

「うちのシステムも MCP に対応すべきか」 「これからは API ではなく MCP なのか」

——こうした声を聞くことが増えました。しかし、流行しているからといって安易に飛びつくのは危険です。

ここが答える8つの問いと、それぞれの一行結論を左右に並べた一覧図。誰が呼ぶか、どちらが重要か、どう発見されるか、対応件数、安全上の必須要件、ツールの粒度、自社に必要かの判断、目次としての併用構成の8項目。
ここが答える8つの問いと、それぞれの一行結論を左右に並べた一覧図。誰が呼ぶか、どちらが重要か、どう発見されるか、対応件数、安全上の必須要件、ツールの粒度、自社に必要かの判断、目次としての併用構成の8項目。

そこで編集部では、両側の一次仕様書の突き合わせと、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 は何が違うのか

APIとMCPの最大の違いである「誰が呼ぶか」を対比した図。APIは人間が書いたプログラムが決定論的に呼び、MCPはAIが実行時に機能を動的発見（tools/list）して非決定論的に呼ぶことを示す。
APIとMCPの最大の違いである「誰が呼ぶか」を対比した図。APIは人間が書いたプログラムが決定論的に呼び、MCPはAIが実行時に機能を動的発見（tools/list）して非決定論的に呼ぶことを示す。

RESTやGraphQLといったAPIと、MCPの最大の違いは 「誰が呼ぶか」 です。

  • 結論：APIは「人間」が仕様書を読み、決定論的なプログラムを書いて呼び出します。一方、MCPは「AIエージェント」が呼びます。
  • MCPにしかできないこと：プロトコルレベルでの 「実行時の動的自己紹介（tools/list）」 と「機能変更通知」です。AIは実行時にサーバーへ「今何ができる？」と問いかけ、その場でツール一覧を受け取って行動を選択します。これは静的な仕様書（OpenAPI等）にはない、MCP特有の機能です。
  • API 側の形式（REST / SOAP / GraphQL / gRPC）の違いそのものは、APIの種類と選び方 で整理しています。

問い2：MCP と API、どちらが重要か

業務システムとAPI基盤の上にMCPが薄いアダプター層として乗っている構造を示した図。MCPサーバーを構築するには下層のOAuthやレート制限といったAPIインフラが必須になることを示す。
業務システムとAPI基盤の上にMCPが薄いアダプター層として乗っている構造を示した図。MCPサーバーを構築するには下層のOAuthやレート制限といったAPIインフラが必須になることを示す。

「これからはMCPの時代だからAPIは不要になるのでは？」という誤解があります。

  • 結論：圧倒的に APIの方が重要 です。
  • 規格書において、MCPサーバーは「OAuth 2.1 資源サーバー」として振る舞うことが定められています。また、入力スキーマ検証、アクセス制御、レート制限の実装が MUST（必須要件） とされています。つまり、MCPサーバーを構築するには、セキュアな Web API を作るのと同等以上のインフラ基盤が要求されます。
  • 図の矢印は下から上へ向いています。 土台があるから上に載せられる、という順序がそのまま投資の順序です。認証と流量制限については OAuth・APIキー・データの保管場所を 56 件で調べた記事 が詳しいです。

問い7：自社システムに MCP は必要か

自社システムにMCPは必要かを判断する3つの状態（APIが存在しない、APIはあるが認証が貧弱、堅牢なAPIがある）を示した図。
自社システムにMCPは必要かを判断する3つの状態（APIが存在しない、APIはあるが認証が貧弱、堅牢なAPIがある）を示した図。

「APIが無いから、代わりにMCPを作って一気にAI対応しよう」という近道は存在しません。MCPを採用すべきかは、自社の足元にあるAPI基盤の整備状況 によって3つの状態に分かれます。

  • 結論：MCPは「既存の堅牢なAPI」の上に乗る薄いラッパーです。APIが存在しない場合は、まず汎用的なWeb API（REST等）を作るのが先決です。APIがあっても認証が「APIキーのみ」だったり、呼び出し回数の上限（レート制限）が未実装であれば、自律的にループを回すAIに開放するのは危険です。
  • 「薄いラッパー」の実物として、編集部の実装を挙げておきます。既存のサイトが使っている読み込み口と判定をそのまま呼び、MCP 側に足したのは JSON-RPC の受け口とツールの説明文だけです。土台が無い状態からこの層だけを作ることはできません。

まとめ：AIエージェントの波に乗るために

投資の順番を3行の表にした図。APIが無いなら先にWeb APIを作りMCPはまだ早い、APIはあるが全権限キーのみなら先に認証の粒度と上限を入れる、堅牢なAPIがあるなら読み取り中心10〜20個に絞って薄く載せてよい。
投資の順番を3行の表にした図。APIが無いなら先にWeb APIを作りMCPはまだ早い、APIはあるが全権限キーのみなら先に認証の粒度と上限を入れる、堅牢なAPIがあるなら読み取り中心10〜20個に絞って薄く載せてよい。

AIエージェントの時代が到来しても、基盤となるインフラの原則は変わりません。「MCPを作ればAPIは不要になる」のではなく、「セキュアで機械可読な API があるからこそ、MCP を載せることができる」 のです。

編集部の MCP サーバーは renkeimap.jp/mcp で公開しています。日本の業務システムの接続仕様を、出典と調査日つきで返します。

ここから先は調査の詳細です（約 8 分）。上のカードだけで決められます。調べた 1 件ずつの記録は IT連携マップ に、出典 URL と調査日つきで公開しています。

調査の詳細

MCP の仕様は一次規格を原文のまま読み、そのうえで編集部自身が MCP サーバーを 1 つ実装して確かめました（POST https://renkeimap.jp/mcp・読み取り専用）。対応状況の集計は、公開している 56 システムを対象にしています。以下に、読んだ一次資料と、調べた範囲・調べていないことを並べます。

問い3：AI は MCP をどうやって発見し、接続するのか

MCPの2つの接続形態（ローカル型stdioとリモート型Streamable HTTP）を並べ、AIが自律的にインターネットを探すのではなく、人がサーバーの在り処を与えることが先行すると示した図。設定ファイルを書く作業は人かAIかクライアント次第である点も併記。
MCPの2つの接続形態（ローカル型stdioとリモート型Streamable HTTP）を並べ、AIが自律的にインターネットを探すのではなく、人がサーバーの在り処を与えることが先行すると示した図。設定ファイルを書く作業は人かAIかクライアント次第である点も併記。

「MCP対応すれば、世界中のAIが勝手に自社システムを見つけてくれる」というのは幻想です。

  • 結論：現状のエコシステムにおいて、AIがインターネット上のMCPサーバーを自律探索することはありません。

  • 発見の第一歩は、「人がそのサーバーの在り処（起動コマンドか URL）を与える」 ことです。AI クライアント（Cursor や Claude など）は、与えられて初めてそこへ繋ぎます。

  • ただし「設定ファイルに書く」作業まで人がやるとは限りません。 ここはクライアントで分かれます。同じ 1 文（「この URL の MCP サーバに繋いでもらえますか？」）を投げて試したところ、開発者向けの Antigravity は mcp_config.json を自分で更新して接続まで済ませ、消費者向けの Claude アプリは「私の側から MCP サーバーを追加することはできない仕様です」と答えて設定画面での操作を案内しました（2026-09-08 に試した）。 開発者向けツールAntigravityの実際の画面。利用者が「https://renkeimap.jp/mcp のMCPサーバに繋いでもらえますか？」と頼むと、AIがmcp_config.jsonを自分で更新して「MCPサーバ（renkeimap）を追加しました」と答え、差分1 file changed +3 -0を示している。続けて「kintoneとfreee会計の連携方法」を尋ねると、API連携とCSVでの受け渡しは編集部が一次確認済み、画面の入力項目は自動入力の可否が未確認と答え、一致する項目名は48項目、出典としてIT連携マップの調査日2026-07-29とURLを提示している。

  • つまり発見（誰が在り処を知るか）と設定（誰がファイルを書くか）は別の段で、人に固定されているのは前者だけです。「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件のAPI対応状況（MCP対応は14件）と、グローバルな主流SaaSのOpenAPI/GraphQL完全公開の状況を対比し、土台のオープン性の差を示した図。
日本の業務システム56件のAPI対応状況（MCP対応は14件）と、グローバルな主流SaaSのOpenAPI/GraphQL完全公開の状況を対比し、土台のオープン性の差を示した図。

実際の業務システムの対応状況はどうなっているのでしょうか。

  • 結論：日本の業務システム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 対応で注意すべきセキュリティ問題

MCP対応時の3大リスク（間接プロンプトインジェクション、DDoS化、破壊的変更）に対する仕様書上の必須要件（MUST）の防御策を盾のアイコンで示した図。
MCP対応時の3大リスク（間接プロンプトインジェクション、DDoS化、破壊的変更）に対する仕様書上の必須要件（MUST）の防御策を盾のアイコンで示した図。

AIエージェントの自律性ゆえに、人間の利用を前提とした従来のAPIよりも厳格な防御が求められます。

  • 結論：MCP仕様書は、以下の対策をサーバー側に MUST（義務） として課しています。
    1. 間接プロンプトインジェクション対策：外部から取得したデータをそのままAIに返さず、無害化（Sanitize tool outputs）する。
    2. DDoS化の防止：AIの超高速な試行錯誤による負荷を防ぐため、HTTP 429等の厳格な流量制限（Rate limit tool invocations）を課す。
    3. 破壊的変更の防止：AIには「読み取りのみ」の最小権限を与え、書き込みツールには人間による承認（HITL）を必須化する。
  • 編集部の実装では、この 3 つを「全ツール読み取り専用」「IP ごとの日次上限」「一覧系は 10 件で打ち切り」という形で満たしています。

問い6：API と同じ機能をすべて提供すべきか

既存のAPIの細粒度CRUDをそのまま公開するアンチパターンと、AI向けに粗粒度の目的別タスクとして束ねるベストプラクティスを対比した図。
既存のAPIの細粒度CRUDをそのまま公開するアンチパターンと、AI向けに粗粒度の目的別タスクとして束ねるベストプラクティスを対比した図。

既存のAPIが100個のエンドポイントを持っているからといって、それをすべて直訳してMCPで公開すると、AIは破綻します。

  • 結論：APIの「細粒度（Fine-grained）」な設計をそのままMCPに持ち込むのはアンチパターンです。
  • 全エンドポイントのスキーマを渡すと、LLMのコンテキストを大量に消費し、コストが跳ね上がります。また、似たようなツール名が増えることでAIが取り違えやすくなります。
  • MCPで公開するツールは、AIが迷わず扱える 「10〜20個程度の、読み取り中心の粗粒度（Coarse-grained）な目的別タスク」 に絞り込むのがベストプラクティスです。
  • 編集部の MCP サーバーは 5 つです（システムを探す／1 つのシステムの事実を返す／2 つのシステムが繋がるかを返す／稼働状況を返す／エラー文の対処を返す）。サイトの HTML と同じデータ経路・同じ判定を通しており、MCP 用に第二のデータ経路は作っていません。

問い8：MCP を「目次」として提供し、API と併用する構成でよいか

MCPを目次、APIを本体として左右に対比した図。MCP側はtools/listで今できることを返し数を絞り読み取りから始める、API側は業務の全機能と認証・レート制限・書き込みを持つことを示し、MCPを出す14件が全件APIも出している調査結果を添えている。
MCPを目次、APIを本体として左右に対比した図。MCP側はtools/listで今できることを返し数を絞り読み取りから始める、API側は業務の全機能と認証・レート制限・書き込みを持つことを示し、MCPを出す14件が全件APIも出している調査結果を添えている。
  • 結論：よい。それが規格の形そのものです。 MCP が持つ tools/list / resources/list / prompts/list は、いずれも「今ここに何があるか」を返す一覧であり、目次にあたります。本体（業務の全機能・書き込み・確定処理）は API 側に残ります。
  • 調査の数もこの形を裏づけています。MCP を出している 14 件は全件が API も出しており、MCP だけの提供は 0 件でした。
  • 設計の指針としては、目次を厚くするのではなく、本体を機械可読に整えるほうが先です。目次に載せるのは、読み取り中心の粗い単位（問い6）に絞ります。

調べた範囲と、調べていないこと

  • 一次規格と公開資料を読み、そのうえで編集部自身が MCP サーバーを 1 つ実装して確かめました（POST https://renkeimap.jp/mcp・読み取り専用）。ただし性能（応答速度・スループット）は測っていません。
  • 仕様書の引用はすべて公式ドキュメントからの原文の引用です（取得日: 2026-09-02〜2026-09-08）。MCP の仕様は現行の 2026-07-28 リビジョンに基づいています。
  • 調査記録の集計値（56 システム）は、編集部が一次調査を完了して公開している業務システムを対象としています。公開資料から仕様が読み取れなかった 16 システムが存在するため、日本全体の比率として単純に一般化することはできません。

読んだ一次資料

区分 規格 一次出典
MCP Specification（2026-07-28 リビジョン） https://modelcontextprotocol.io/specification/2026-07-28
MCP Transports（stdio / Streamable HTTP） https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
MCP Authorization（OAuth 2.1） https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
MCP Server Features（Tools / Resources / Prompts） https://modelcontextprotocol.io/specification/2026-07-28/server/tools
REST HTTP Semantics（RFC 9110） https://www.rfc-editor.org/rfc/rfc9110.html
REST OpenAPI Specification https://spec.openapis.org/oas/latest.html
SOAP SOAP 1.2 Part 1 https://www.w3.org/TR/soap12-part1/
GraphQL GraphQL Specification（October 2021） https://spec.graphql.org/October2021/
gRPC Protocol Buffers（proto3） https://protobuf.dev/
Auth OAuth 2.1（draft-ietf-oauth-v2-1-13） https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13
HTTP 429 Too Many Requests（RFC 6585） https://www.rfc-editor.org/rfc/rfc6585.html
JSON JSON-RPC 2.0 https://www.jsonrpc.org/specification

この記事に登場するシステム（4）

Shopifyfreee会計kintoneマネーフォワード クラウド会計

← 調査記事の一覧へ　比較する

編集部はベンダーからの掲載料・送客料・成果報酬を一切受け取りません。判定は編集部の調査記録にある一次資料から、機械で組み立てています。 相談内容はその場で回答に使うだけで、保存しません。
一覧: システム一覧　連携ツール（連携サービス）一覧　AI・自動化ツール一覧　稼働状況・障害情報
記載の誤り・掲載についてのご連絡 → 訂正・掲載のご依頼（無料・無条件・全社同一）　運営者情報