MCP vs. API（REST・SOAP・GraphQL・gRPC）どれが使える？日本の業務システム 56 件を調べてみた

Last updated at 2026-09-02Posted at 2026-09-02

＜空想の中小企業の話＞

経理から：「CRM とクラウド会計の取引先、連携できないの？」 → IT担当：「調べてみます。」
社長から：「AI エージェントにデータ分析してもらえないかい？」 → IT担当：「調べてみます。」
総務から：「クラウドや AI にデータが流れて、セキュリティ大丈夫？」 → IT担当：「調べてみます。」
…
IT担当：「Google で検索 → MCP、REST、SOAP、GraphQL、gRPC… → ？？？」
IT担当：「結局、どこから調べれば良いか分からなくなってしまいました。」

この記事は、その IT担当の人が 最初に手を付ける順番 を決められるように書きました。

実装していません。公開資料を読んだだけです。 「速い／安定している」は測っていないので書きません。

急ぐ方へ: 【API と MCP の両方を出している 14 システムの一覧】は 5 章にあります。 システム名で先に確かめたい方は、そこまで飛ばしてください。

先に結論です。

調べる順番は「相手が何を出しているか」から。 自社が何を使うかは、その後で決まります
MCP は API の代わりではありません。 MCP を出している 14 件は、14 件とも API も出していました
「API」は 1 つではありません。 REST・SOAP・GraphQL・gRPC は別の規格です

0. 先に、出てくる言葉を 1 行ずつ

検索して迷子になる原因の半分は、言葉が説明なしに出てくることです。この記事に出る言葉を先に並べます。すべて公式の一次資料へのリンク付きです。

用語 16 個の一覧（クリックで開く） — 正式名称・一行の説明・公式リンク

言葉	正式名称	一行の説明	公式
API	Application Programming Interface	プログラムから他のシステムを呼ぶための受付窓口	—
REST	REpresentational State Transfer	`/customers/123` のように住所（URL）で対象を指す呼び方。HTTP の決まりに従う	規格書は無い（Fielding の論文, 2000）。HTTP 自体は RFC 9110
SOAP	（SOAP 1.2 では略語を展開しない）	XML で包んだメッセージを1 つの入口へ送る方式	W3C SOAP 1.2
GraphQL	（固有名。略語ではない）	呼ぶ側が「欲しい項目」を書いて送る問い合わせ言語	GraphQL 仕様
gRPC	gRPC Remote Procedure Calls	定義ファイルからコードを生成して呼ぶ方式。社内システム間で使われることが多い	gRPC 公式
MCP	Model Context Protocol	AI に「何ができるか」を伝えるための共通の書き方	MCP 仕様 2026-07-28（この記事は現行版のこの版を読みました）
OpenAPI	（旧称 Swagger）	REST API の設計図を機械が読める形で書く書式	OpenAPI 3.2.0
WSDL	Web Services Description Language	SOAP 版の設計図	W3C WSDL 2.0
JSON-RPC	JSON Remote Procedure Call	「この関数をこの引数で呼べ」を JSON で書く決まり。MCP の土台	JSON-RPC 2.0
OAuth	Open Authorization	パスワードを渡さずに「この範囲だけ触ってよい」と許可を出す仕組み。2.1 は 2.0 の整理版	RFC 6749（2.0）／OAuth 2.1（草案）
API キー	—	1 本の文字列で認証する方式。発行時に決めた範囲しか絞れない（kintone のようにアプリごと・操作ごとに絞れるものもあるが、多くは 1 本で全部）のが OAuth との違い	—
ステートレス	—	前の呼び出しを覚えていないという性質。毎回すべての情報を送る	—
JSON Schema	—	「この項目は文字列、これは整数」のようにデータの形を書く書式。MCP はこれで機能の入出力を書く	json-schema.org
Protocol Buffers	—	gRPC が使う、データの形と呼び方の定義書式	protobuf.dev
429	429 Too Many Requests	「一定時間に送りすぎ」を表す HTTP の返事	RFC 6585
AI エージェント	—	目的を渡すと、何を呼ぶか自分で決めて動く AI	—

全部覚える必要はありません。 出てきたらここに戻ってください。

1. 用途からみた MCP と API の違い

まず、何がどこに繋がるのか を 1 枚にします。

下の図で、実線はそのために用意されている道、点線は繋がるけれど回り道になる道です。

4 通りとも繋がります。 よくある誤解は「AI は MCP しか使えない」「プログラムは API しか使えない」ですが、どちらも違います。

点線① プログラム → MCP サーバー

繋がります。MCP は通信の決まりごとなので、人が書いたプログラムからも呼べます。ただし MCP サーバーは AI 向けに絞った一覧です。普通の連携をするなら API のほうができることの範囲が広い（詳しくは 5 章）。

点線② AI エージェント → API サーバー

これも繋がります。実際、今までの AI 連携はこの形で作られてきました。ただし 「この API をこう呼べ」と人が教える必要があります。

実線 AI エージェント → MCP サーバー

MCP サーバーは 入口で「機能一覧」を公開しています。 だから AI が自分で「何ができるか」を見つけて使えます。教える手間が要りません（詳しくは 2 章）。

そして、どの道を通っても窓口の下は同じ業務システムです。 MCP を通しても、書き込みができるか・回数の上限・認証・規約は、そのまま効きます。

2. 規格からみた MCP と API の違い

ここで 「API」が 1 つではないことを揃えます。REST・SOAP・GraphQL・gRPC は、それぞれ別の規格です。MCP を足して 5 つを同じ物差しで並べます。

一番上の行が、MCP だけが持っているものです。

A 機能一覧を実行時に出すか

MCP は入口で tools/list のような形で 「うちにはこういう操作があります」と自分で名乗ります。 呼ぶ側は事前知識なしに一覧を取れます。

REST や SOAP にも記述の仕組みはありますが（OpenAPI・WSDL）、それは設計時に人や道具が読むもので、実行時に相手が名乗るのとは別です。GraphQL には型の内省（introspection＝相手に「どんな型があるか」を尋ねる機能）があるので、この行では中間になります。

B 入口の数（URL 設計が要るか）

REST だけが URL の設計を持ちます。 /customers/123 のように、住所そのものが意味を持ちます。SOAP・GraphQL・MCP は「1 つの入口へメッセージを送る」形です。MCP は HTTP POST を 1 エンドポイントに送ります。

C 型の書き方（フォーマット）

どの方式も型を決める道具を持っています。REST は OpenAPI（3.1 以降は JSON Schema）、SOAP は XML Schema、GraphQL は独自の型システム、gRPC は Protocol Buffers、MCP は機能の入出力を JSON Schema で書きます。

D エラーの決まり

REST は HTTP のステータスコード、SOAP は SOAP Fault、MCP は JSON-RPC 2.0 のエラーコードです。API と MCP を両方出す会社は、エラーの体系が 2 つになります。

E 認証を規格が定めるか

ここが分かれます。REST も GraphQL も、認証は規格の外です（OAuth などを別途組み合わせる）。MCP は、リモート型（HTTP で繋ぐ形）について、OAuth 2.1 に基づく認可の決まりを仕様の中に持っています。 ただし仕様上は「任意（OPTIONAL）」で、ローカル型（自分の PC で動かす形）はこの決まりの対象外です。ローカル型は環境から資格情報を読みます（5-1 節）。

つまり MCP は認証を肩代わりするのではなく、OAuth を前提にします。 既に OAuth で API を出していれば土台は共通、無ければ MCP のために OAuth を用意することになります。

F 状態を持たない

MCP の仕様（現行 2026-07-28 版）は 「MCP はステートレスなプロトコル」 と明記し、サーバーは 前の呼び出しに頼って文脈を作ってはいけない、と書いています。「プロトコル上のセッションは無い」 とも書かれています。複数回にまたがる処理を作るなら、その状態管理は自分で設計します。

（1 つ前の 2025-06-18 版では、リモート型のサーバーが Mcp-Session-Id という印でセッションを持てました。現行版でこの記述は外れています。仕様は動いている、の実例です。）

上限（回数の制限）

規格の表には入れていませんが、重要なので触れます。MCP の仕様は、サーバーがやるべきこととして「呼び出しに上限を掛けること」を義務づけています。 「MCP なら上限の設計が要らない」は仕様に反します。

AI は人より速く呼び出します。 上限の設計は、どちらのルートでも避けられません。

3. システム 56 件の対応状況

ここからは数えた結果です。編集部が一次調査を終えて公開している 56 システムを数えました。

API を何らかの形で出しているのは 47 件（第三者がそのまま使えるのは 28 件）、MCP サーバーを出しているのは 14 件でした。

そして一番下の行が、この記事の答えです。

MCP だけで API が無いシステムは、0 件でした。

MCP を出している 14 件は、14 件とも API も出しています。 ゼロから AI 用の口だけを作った例は、調べた範囲にはありませんでした。

API はあっても形式まで読めなかったものが 16 件あります。だから「日本の業務システムは REST が主流」とは書けません。 書けるのは「形式まで読めた範囲での内訳はこう」までです。

4. 各方式はどこまで読めるか

IT担当が実際に困るのは、**「調べても分からない」**ところです。方式ごとに、公開資料からどこまで読めるかを並べます。

G 何ができるかの一覧

GraphQL・gRPC・MCP は、定義そのものが機械が読める形なので全体が見えます。REST は OpenAPI（設計図）が公開されていれば見えますが、公開していない会社もあります。

H 項目の形（スキーマ）

「日付は何形式か」「金額は整数か小数か」まで分かるか、という話です。SOAP・GraphQL・gRPC・MCP は型を書く仕組みが規格に入っています。REST は OpenAPI 次第です。

I 認証の方式

比較的読めます（56 件中 48 件）。OAuth か API キーかは、AI に渡す権限を絞れるかどうかに直結するので、ここは必ず確認してください。

J 仕様変更への追随 — 告知があるか、そして使う側は何を直すか

告知が読めるのは 56 件中 38 件でした。壊れる前に気づけるかという、運用に効く項目です。

ここは MCP と API で「使う側がやること」が違います。 API は、呼び方が変われば人がコードを直します。MCP は、AI が入口の一覧（tools/list）を実行時に読み直すので、操作の名前や引数が変わっても、AI は新しい一覧を見て呼び直せます。仕様も「一覧は時間とともに変わり得る」と書き、変わったことを知らせる通知（notifications/tools/list_changed）を持っています。

上の表の J はこの「使う側の手間」を記号にしています。△＝人がコードを直す（REST）、○＝定義ファイルから作り直せる（SOAP・GraphQL・gRPC）、◎＝AI が一覧を読み直す（MCP）。

ただし、追えるのは「呼び方」の変化までです。 同じ名前で結果の意味が変わる・権限や料金が変わる、といった変化は一覧には現れないので、告知を読むしかありません。また ローカル型の MCP サーバーは、自社で更新しない限り古いままです（5-1 節）。

K 回数の上限 — ここは記号で比べられません

方式の問題ではなく、公開するかどうかの方針の問題だからです。 REST だから読める、MCP だから読めない、ではありません。

実際、56 件のうち上限に触れているのは 28 件、数値まで書いているのは 25 件でした。同じ会社でも分かれます。**freee は人事労務が「1 時間で 10,000 回」と明記しているのに、会計は「数値は非公開」**です（429 の定義だけがあります）。

上限の書き方もばらばらです。 kintone は 1 日あたりの回数、HubSpot は 10 秒あたり、Shopify は回数ではなく「クエリの重さ」、Zoho CRM はクレジット制です。単純に数字を比べられません。

L 台帳での実数 — これも記号ではなく件数で

REST 系（HTTP で資源を呼ぶ形）31 件／SOAP 3 件／GraphQL 1 件／gRPC 0 件／MCP 14 件（SOAP・GraphQL は REST 系と併存）。API はあるが形式まで読めなかったものが 16 件、ファイル入出力の仕様を公開しているものが 8 件あります。

5. API と MCP の両方を出している 14 システム

図に載っていない残りのシステムも、API の種類を並べておきます。（MCP サーバーは出していない系統）

REST だけ（17 件）

_{board（REST）／ e-Gov電子申請（REST）／ e-Tax（REST 系（HTTP + JSON。REST とは明記なし））／ Google Classroom（REST）／ Google フォーム（REST）／ invox（REST）／ jGrants（REST）／ KING OF TIME（REST 系（HTTP + JSON。REST とは明記なし））／ Misoca（REST 系（HTTP + JSON。REST とは明記なし））／ MOVO Berth（REST 系（HTTP + JSON。REST とは明記なし））／ SmartHR（REST）／ Yahoo!ショッピングストアクリエイターPro（REST 系（HTTP + JSON。REST とは明記なし））／ジョブカン会計（REST＋ファイル入出力）／ジンジャー（REST）／マネーフォワードクラウド給与（REST 系（HTTP + JSON。REST とは明記なし））／マネーフォワードクラウド経費（REST）／マネーフォワードクラウド請求書（REST）}

_{SOAP・GraphQL を出している系統は、上の図の 14 件にすべて含まれています（SOAP は Garoon と Salesforce 2 種、GraphQL は Shopify）。gRPC は 1 件もありませんでした。}

API は在るが、形式まで読めない（16 件）

_{ANDPAD ／ CLIUS ／ Comiru ／ e-TUMO ／ eLTAX / PCdesk（ファイル入出力）／ formrun ／ GビズID ／ Microsoft Forms ／ケア樹／ジョブカン給与計算／ジョブカン勤怠管理／ジョブカン労務HR（ファイル入出力）／ダンドリワーク／どっと原価（ファイル入出力）／マネーフォワードクラウド社会保険／楽楽精算（ファイル入出力）}

公開 API が確認できない（9 件）

_{Airワーク採用管理（公開情報の範囲では見つからない）／ e内容証明（公開情報の範囲では見つからない）／ freee申告（公開情報の範囲では見つからない）／ Grafferスマート申請（公開情報の範囲では見つからない）／ LoGoForm（公開情報の範囲では見つからない）／いえらぶBB（robots.txt で判定できない）／いえらぶCLOUD（公開情報の範囲では見つからない）／サイボウズ Office（外部利用を明示的に不許可）／弥生（会計/青色申告オンライン/Next）（公開情報の範囲では見つからない）}

_{「形式まで読めない」は「API が無い」ではありません。公開資料に書いていないだけで、問い合わせれば分かることがあります。ファイル入出力は形式とは別の軸なので、括弧の中に添えています。}

ここが、経理・社長・総務の 3 つの質問に対する 実際の材料です。

表の見方

形式の列は、公開資料から読めたものです。読めなかったものは載せていません
上限は、各行の補足に数値をそのまま書きました。14 件のうち 数値まで読めたのは 10 件です
- 3 件は数値が非公開（freee会計・MF クラウド会計・Garoon）。freee会計と MF クラウド会計は「429 が返る」ことだけを書いていて、数値は書いていません
- 1 件は「数値はあるが確かめられない」（Jotform）。料金ページに埋め込まれたデータには 1 日あたりの回数が入っていますが、画面の表は JavaScript で描かれるため、保存した資料からは表示値と一致するか確かめられませんでした
右端の補足に、MCP サーバーがどういう形か（ローカルかリモートか）を書いています

MCP の機能範囲は、API より狭いのが共通していました。

各社とも「MCP サーバーでできる操作」の一覧が先に決まっています。kintone ならレコードの取得・追加・更新・削除など、Garoon なら予定の登録・空き予定の検索など、Shopify なら Storefront（カタログ・カート）と顧客アカウントの 2 つです。

MCP の一覧に無い操作をしたければ、結局 API を呼ぶことになります。

5-1. ローカルとリモートの違い — ここが総務の質問への答えです

MCP サーバーには 2 つの置き場所があります。 名前だけ見ても分からないので、何が違うのかを書きます。

リモート型（相手の会社のサーバーに繋ぐ）

用意するもの: 接続設定だけ。自社にサーバーは要りません
認証: OAuth 2.1 に基づく決まりを MCP の仕様が定めています。「この AI に、この範囲だけ許可する」という画面が出ます
資格情報がどこに置かれるか: 相手の会社（アクセストークンが発行され、相手が管理します）
データの通り道: 自社 → 相手の MCP サーバー → 相手の業務システム
例: MF クラウド会計、Google 系、Salesforce、Slack、Jotform

ローカル型（自社の PC やサーバーで動かす）

用意するもの: 動かす場所（PC やサーバー）と、その運用
認証: 環境から資格情報を読みます。 MCP の仕様がそう定めています（リモートの OAuth の決まりは適用されません）。中身は系統ごとに違い、kintone の MCP サーバーは API トークン（アプリごとに発行し、許可する操作を選ぶ）またはパスワード、freee の MCP サーバーは OAuth 2.0 を使います
資格情報がどこに置かれるか: 自社の中
データの通り道: 自社の中の MCP サーバー → 相手の API
例: freee、Garoon（kintone と HubSpot は両方あります）

認証の方式と合わせて見ると、こうなります。

	リモート型	ローカル型
認証	OAuth 2.1 の決まり	環境から資格情報を読む（中身は系統ごと：API トークン型／OAuth 型）
権限を範囲で絞れるか	絞れる（許可画面で選ぶ）	発行したものの範囲まで（kintone のトークンはアプリ・操作単位、OAuth 型なら許可画面で選ぶ）
資格情報の置き場所	相手の会社	自社の中
立てる手間	要らない	要る

どちらが安全、という単純な話ではありません。

リモート型は、資格情報が相手に渡る代わりに、OAuth で「どこまで触ってよいか」を範囲で絞れます
ローカル型は、資格情報が自社から出ない代わりに、資格情報の種類が系統ごとです。API トークン型（kintone）は発行時にアプリと操作を選び、OAuth 型（freee）は許可画面で選びます。どちらも「AI に渡す前に、渡す範囲を決めておく」ことが要ります

どちらの型でも、AI モデルの提供者にデータが渡る点は同じです。 ここは MCP か API かで変わりません。

総務の「セキュリティ大丈夫？」に答えるなら、この 2 つを分けて説明することになります。 「クラウドに出すか出さないか」だけでは足りません。

6. 調べても分からなかったとき、どうするか

ここまでの手順で調べても、読めない項目は必ず出ます。 56 件を調べた実感として、詰まりやすいのは次の 3 つです。

回数の上限が書いていない

一番多いパターンです（56 件中 28 件が上限に触れていませんでした）。

そのときは「無い」ではなく「分からない」として扱ってください。 上限が無い API はほとんどありません。書いていないだけです。

実務では、まず小さく試して、429（送りすぎ）が返るかを見ることになります。返ってきたヘッダに残り回数が入っていることもあります（freee人事労務は X-RateLimit- 系のヘッダを返すと明記しています）。

「API はあります」としか書いていない

「何ができるか」まで書いていないケースです。読み取りだけなのか、書き込みもできるのかが分かりません。

設計図（OpenAPI）が公開されていれば、そこに全部書いてあります。 公開されていなければ、開発者向けの問い合わせ窓口に聞くことになります。56 件すべてに問い合わせ窓口はありました。

AI 経由で使ってよいか書いていない

規約に AI の記述が無いことは珍しくありません。無い＝許可、ではありません。

判断が必要なら、問い合わせて記録を残すのが確実です。後で「聞いていない」と言われない形にしておきます。

6-1. 読めないこと自体が、判断材料です

上限が公開されていないシステムに、AI から毎分何百回も投げる設計は立てられません。 「分からないから慎重に」ではなく、**「分からないなら、その設計は選べない」**と考えるほうが実務的です。

読めない項目が多い相手なら、まず人が手で動かす範囲から始めて、様子を見ながら広げる——という選択肢もあります。

7. だから、調べる順番はこうなります

自社が何を導入するかより先に、相手が何を出しているかを見ます。 順番を逆にすると、決めた後で「相手が対応していない」と分かります。

相手のシステムに API があるか — 無ければ MCP もありません（調べた範囲で 0 件）
書き込みができるか — 読み取り専用なら、MCP を通しても AI は読み取りだけです
回数の上限 — 一番読めない項目です。読めなければ、それ自体が判断材料になります
認証が OAuth か API キーか — 権限を範囲で絞れるかどうか
規約に AI 経由の記述があるか
（ここで初めて）MCP があるか — あれば AI から使うのが早くなります。無くても API で繋がります

MCP は 6 番目です。 1〜5 が決まらないうちに MCP から調べても、答えは出ません。冒頭の IT担当が迷子になったのは、6 番目から調べ始めたからです。

8. まとめ — 冒頭の 3 つに答えます

この記事は、経理・社長・総務の 3 つの依頼から始まりました。答えを先に書きます。

経理「CRM とクラウド会計の取引先、連携できないの？」

→ できます。ただし MCP の話ではありません。 システム同士を繋ぐので、両方の API を見ます。CRM 側（HubSpot・Salesforce・Zoho CRM）も会計側（freee会計・MF クラウド会計）も API を出しています。

確認するのは「書き込みができるか」です。 取引先を登録するなら、読み取りだけでは足りません。

社長「AI エージェントにデータ分析してもらえないかい？」

→ 分析だけなら読み取りで足ります。 読み取りだけなら、MCP があると早いです。相手が機能一覧を出しているので、AI が自分で見つけられます。

相手が MCP を出していなくても、API を AI に教える形で動きます。 MCP が無いから諦める、ではありません。

総務「クラウドや AI にデータが流れて、セキュリティ大丈夫？」

→ 見るところは 3 つです。

認証が OAuth か API キーか — OAuth なら、AI に渡す権限を許可画面で絞れます。API キーは発行時に決めた範囲まで（1 本で全部、の系統が多い）
MCP がローカル型かリモート型か — ローカル型なら資格情報が自社から出ません。ただし資格情報の種類は系統ごとで、渡す範囲は発行時に決めておきます
規約 — AI 経由の利用も API 利用規約の対象です

「クラウドに出すか出さないか」の 1 軸では答えられません。 資格情報の置き場所と、権限を絞れるかは別の話だからです。

8-1. 調べて分かったこと（数字）

API を何らかの形で出しているのは 47 件、MCP サーバーは 14 件（調べた 56 システム中）
MCP だけで API が無いシステムは 0 件
「API」は 1 つではない — REST 系 31 件／SOAP 3 件／GraphQL 1 件／gRPC 0 件（併存あり・形式まで読めない 16 件）
一番読めないのは回数の上限（触れているのは 28 件、数値まで書くのは 25 件）。方式ではなく、公開するかどうかの方針の問題
MCP の範囲は API より狭い — 14 件すべてで「できる操作の一覧」が先に決まっている

「AI に触らせるために何が要るか」の答えは、AI 側にはありません。
相手側の受け口（API・書き込み可否・回数の上限・認証・規約）に全部あります。

この記事の調査範囲について

実装していません。 公開資料と、編集部の台帳を読んだだけです。動かした結果は書いていません
対象は、編集部が一次調査を終えて公開している 56 システムです。日本の業務システム全体ではありません。「56 件中 14 件」を「日本の 25%」と読み替えることはできません
数えたのは「公開資料から読めたか」です。 書いていないことと、無いことは違います
API はあっても形式まで読めなかったものが 16 件あります。形式の内訳を割合として一般化することはできません
MCP の提供状況も、MCP の仕様自体も動いています。 この記事は調査時点のものです

調査対象の56システム（全件・公式ページ）

※ 一次調査を終えて公開している 56 件です。判断の元にした記述・出典URL・調査日は RenkeiMap に1件ずつ載せています。

【転載OK】本記事の転載について

本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。文中の「編集部」は、筆者が所属する IT連携マップ編集部のことです。誤りを見つけられましたら訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

MCP vs. API（REST・SOAP・GraphQL・gRPC）どれが使える？ 日本の業務システム 56 件を調べてみた