MCPとAPI 56業務システム調査で判明した連携の実態

日本の業務システムにおける外部連携の実態を、公開資料のみで横断的に調べた調査が公開された。Qiita の songchong の報道では、国内で利用される業務システム56件を対象に、MCPとAPI（REST・SOAP・GraphQL・gRPC）の提供状況が整理されている。2026年9月2日に公開された同記事は、実装や性能測定を伴わず、一次資料の記述に基づく比較に徹している点が特徴だ。

結論は明確だ。検討の順序は自社が使いたい技術からではなく、相手システムが何を公開しているかから決めるべきだという指摘である。MCPはAPIの代替ではない。MCPを提供する14件はすべてAPIも併存していた。REST・SOAP・GraphQL・gRPCは同一のAPIという括りで理解すべきではなく、それぞれが別の規格である。

MCP は API の代わりではありません。MCP を出している 14 件は、14 件とも API も出していました

Qiita の songchong の報道では、この事実を起点に、IT担当者が最初に手を付ける順序を誤らないための整理が試みられている。

56件調査が示した結論と全体像

調査対象は日本の業務システム56件である。CRMやクラウド会計を含む業務領域を横断し、各製品の公式ドキュメントで公開されている連携手段が確認された。手法は公開資料の読解に限定され、実際の呼び出しや速度、安定性の測定は行われていない。

著者は中小企業における典型的な相談を起点に据えている。経理部門からの取引先連携の要望、経営層からのAIエージェント活用の打診、総務からのクラウドやAIへのデータ流通に関する安全性の懸念だ。これらが同時に寄せられた際、MCP、REST、SOAP、GraphQL、gRPCといった用語が混在し、調査の起点を見失いやすいという課題が示されている。

そこで提示されたのが、相手が何を出しているかを起点とする順序である。自社の利用技術を先に決めるのではなく、連携先が提供する窓口の有無と種別を確認し、その後に自社の選択を決めるという考え方だ。急ぎ確認したい読者向けに、APIとMCPを併存する14システムの一覧が5章に集約されている点も、実務的な配慮として位置付けられている。

混乱を防ぐ16用語の定義と一次情報

用語の多さが混乱の要因であるとして、記事は16項目を一行で定義し、一次情報へのリンクを併記している。いずれも公式仕様やRFCに根拠を持つ整理である。

APIはApplication Programming Interfaceの略で、プログラムから他システムを呼び出すための受付窓口を指す。RESTはREpresentational State Transferの略で、/customers/123のようにURLで対象を指し示し、HTTPの規約に従う呼び方である。規格書は存在せず、Fieldingの論文（2000年）とHTTP自体のRFC 9110が参照される。SOAPはバージョン1.2以降は略語を展開せず、XMLで包んだメッセージを単一の入口へ送る方式で、W3C SOAP 1.2が根拠とされる。

GraphQLは固有名で、呼び出し側が欲しい項目を指定して送る問い合わせ言語であり、GraphQL仕様が参照される。gRPCはgRPC Remote Procedure Callsの略で、定義ファイルからコードを生成して呼び出す方式であり、社内システム間で用いられることが多い。MCPはModel Context Protocolの略で、AIに何ができるかを伝えるための共通の記述方式であり、この記事では2026年7月28日版のMCP仕様が参照されている。

OpenAPIは旧称Swaggerで、REST APIの設計図を機械可読な形で記述する書式であり、OpenAPI 3.2.0が参照される。WSDLはWeb Services Description Languageの略で、SOAP版の設計図に相当し、WSDL 2.0が参照される。JSON-RPCはJSON Remote Procedure Callの略で、関数呼び出しをJSONで記述する規約であり、MCPの土台としてJSON-RPC 2.0が位置付けられている。

OAuthはOpen Authorizationの略で、パスワードを渡さずに特定範囲の操作を許可する仕組みであり、RFC 6749（2.0）とOAuth 2.1草案が参照される。APIキーは1本の文字列で認証する方式で、発行時に決めた範囲に限定される点がOAuthとの違いとして整理されている。kintoneのようにアプリごとや操作ごとに絞り込める例もあるが、多くは1本で全権限に近い形になる。

ステートレスは前の呼び出しを記憶しない性質で、毎回すべての情報を送る必要がある。JSON Schemaはデータの形を記述する書式で、MCPでは機能の入出力を記述するために用いられる。Protocol BuffersはgRPCが用いるデータの形と呼び方の定義書式である。429は429 Too Many Requestsのことで、一定時間内の送信超過を示すHTTP応答であり、RFC 6585が根拠とされる。AIエージェントは目的を渡すと何を呼ぶかを自ら決めて動くAIを指す。

MCPとAPIを結ぶ4つの接続経路

記事はMCPとAPIの関係を、4つの接続経路で整理している。実線はそのために用意された道、点線は接続可能だが回り道となる道として示される。

第一に、プログラムからMCPサーバーへの接続は可能だ。MCPは通信の規約であるため、人が書いたプログラムから呼び出すこともできる。ただしMCPサーバーが公開する一覧はAI向けに絞られたものであるため、通常の業務連携で求められる広範な操作を網羅するには、APIの方が適する場合が多い。

第二に、AIエージェントからAPIサーバーへの接続も可能だ。従来のAI連携の多くはこの形で構築されてきた。ただし、どのAPIをどのような引数で呼ぶかを人が事前に教える必要がある。

第三に、AIエージェントからMCPサーバーへの接続が、MCP本来の想定経路である。MCPサーバーは入口で機能一覧を公開するため、AIが自ら何ができるかを発見して利用できる。事前に個別の呼び出し方法を教える手間が不要になる点が、API経由との違いとして強調されている。

第四に、プログラムからAPIサーバーへの接続は、業務システム連携の基本経路である。いずれの経路を通っても、窓口の下にある業務システム自体は同一であり、書き込み可否や回数上限、認証、利用規約といった制約は変わらず適用される。MCPを経由したからといって制限が緩和されるわけではない。

この整理は、AIはMCPしか使えない、プログラムはAPIしか使えないといった誤解を正す意図を持つ。両者は相互に呼び出し可能であり、用途と公開範囲に応じて使い分ける対象であることが示されている。

5方式を同列で比べる規格の違い

記事はAPIを一括りにせず、REST・SOAP・GraphQL・gRPCにMCPを加えた5方式を同じ物差しで並べている。比較の軸として、機能一覧を実行時に公開するかどうかが挙げられている。

MCPはtools/listのような形で、入口自体が「どのような操作を提供しているか」を名乗る。呼び出し側は事前知識なしに一覧を取得できる。これに対し、RESTやSOAPにも記述の仕組みは存在するが、OpenAPIやWSDLは設計時に人や道具が読むためのものであり、実行時に相手が自ら名乗る仕組みとは異なる。GraphQLには型の内省（introspection）があり、どのような型があるかを問い合わせることはできるが、MCPのような操作一覧の自己記述とは目的が異なる。

この違いは、AIエージェントが自律的に操作を発見できるかどうかに直結する。MCPは実行時の自己記述を前提とするため、エージェントが動的に選択肢を把握できる。一方、REST等の記述は事前に共有された設計書を前提とするため、エージェントに教える工程が別途必要になる。

また、通信や記述の基盤も異なる。RESTはHTTPとURL設計、SOAPはXMLメッセージとWSDL、GraphQLは問い合わせ言語とスキーマ、gRPCはProtocol Buffersとコード生成、MCPはJSON-RPC 2.0とJSON Schemaを土台とする。認証ではOAuth 2.0や2.1、APIキーといった方式が共通して関わるが、権限の粒度や運用は製品ごとに差異がある。429による回数制限の扱いも、業務システム側のポリシーに依存する。

両対応14件が示すAPI併存の実態

調査でMCPを提供していた14件は、例外なくAPIも提供していた。この事実は、MCPがAPIを置き換えるものではなく、APIの上にAI向けの窓口を追加する形で提供されていることを示す。

記事によれば、MCPサーバーが公開する操作は、APIが持つ全機能の部分集合である場合が多い。業務システムが本来持つ一括更新や管理系の操作、詳細な条件指定を伴う検索などは、API側でのみ提供されることがある。AI向けに絞られたMCPでは、利用頻度が高い参照や登録、更新に限定される傾向がある。

このため、通常のシステム間連携やバッチ処理、既存の業務フローをそのまま自動化する用途では、APIが引き続き中心となる。AIエージェントに自然言語で指示して操作させる用途では、MCPが適する。両者は競合ではなく、用途に応じた併存関係にあると整理されている。

IT担当者の観点では、まず連携先がAPIのみか、MCPも併存するかを公開資料で確認し、次に認証方式や回数上限、書き込み可否を確認する順序が提案されている。特にセキュリティに関しては、クラウドやAIへのデータ流通を懸念する声に対し、認証方式の違いや権限範囲、規約上の制約を正確に把握することが求められる。OAuthによる範囲限定とAPIキーによる一括認証の違い、ステートレスな呼び出しの特性、429応答への対応は、運用設計に直接影響する。

現場が取るべき検討と実装の順序

記事は実装を行わず、公開資料の記述に基づく判断材料の提供に徹している。そのため、性能や安定性に関する評価は含まれていない。現場が取るべき順序として示されているのは、公開資料を読む段階での優先順位である。

第一に、相手システムがREST、SOAP、GraphQL、gRPCのいずれでAPIを公開しているかを確認する。OpenAPIやWSDLの有無、GraphQLのスキーマ公開、gRPCの定義ファイル提供といった手がかりが、連携の工数や必要な技術要素を左右する。

第二に、MCPの有無を確認する。MCPが提供されている場合でも、APIが併存していることを前提に、MCPでできる操作の範囲をAPIと比較する。AIエージェントに任せたい操作がMCPで網羅されているか、不足する操作はAPIで補う必要があるかを切り分ける。

第三に、認証と制限を確認する。OAuth 2.0や2.1への対応、APIキーの発行単位、スコープの粒度、429の閾値や再試行ポリシーは、運用時の障害や情報漏えいリスクに直結する。総務部門からの懸念に応えるためにも、どのデータがどの経路で外部に流れるかを、規約と技術仕様の両面から確認する必要がある。

AIエージェントの自律性が高まる中での連携設計は、単なる技術選定にとどまらない。エージェントが自ら操作を発見して実行する特性は、権限委譲の在り方や監査の在り方にも影響する。この点では、Anthropic Mythos輸出規制、PGPの轍を踏むリスクで論じられた自律性と統制の緊張関係や、Sim2Realに代わるReal2Sim、NVIDIAと李飛飛が新システムで示された実環境とモデルの相互作用の議論とも、設計思想の面で重なる部分があると見ることができる。基盤の実装技術としては、Mesa Rusticl、Mali Panfrostを標準で有効化のように、オープンな実装が標準化され広がっていく過程も、連携規格の普及を考える上で参考になると評価できる。

編集部の見解

短期的には、業務システム選定時の確認項目にMCPの有無が加わる動きが広がると見る。56件中14件という併存の実態は、MCPが独立した新規格としてではなく、既存APIのAI向け拡張として普及しつつある段階を示す。3〜6か月のスパンでは、RFPや比較表にMCP対応欄が追加され、AIエージェント連携を前提とするPoCで、APIとMCPの使い分けが要件定義の初期から議論される場面が増えると評価する。 長期的には、連携の主導権が事前の設計書共有から実行時の自己記述へ移る可能性がある。MCPのように入口で機能一覧を公開する方式が広がれば、エージェントが自ら操作を発見し、業務フローを動的に組み替える運用が現実味を帯びる。一方で、操作範囲の限定や監査、権限管理の在り方が問われる。APIが持つ広範な操作をどこまでMCPに開放するかは、利便性と統制の均衡として1〜3年かけて業界内で合意形成が進むと見る。 編集部からの問いは、公開範囲の設計を誰が担うべきかという点にある。MCPの自己記述性はAIの自律性を高めるが、同時に誤操作や過剰な権限委譲のリスクも高める。

参考

• 「MCP vs. API（REST・SOAP・GraphQL・gRPC）どれが使える？ 日本の業務システム 56 件を調べてみた」, by songchong — Qiita, 2026-09-02T19:42:43.000Z (ARR)
• 元記事URL: https://qiita.com/songchong/items/64a8710cffb39963c2b3?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items