MCP か API か — 用途と規格で選び、業務システム 56 件で確かめる

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

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

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

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

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

「API」も 1 つではありません。REST・SOAP・GraphQL・gRPC に MCP を足して、同じ物差しで並べたのが次のものです。

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

システム 56 件の対応状況

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

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

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

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

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

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

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

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 件あります。

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

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

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

_{「形式まで読めない」は「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 を呼ぶことになります。

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

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

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

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

調査記録から: 経理・会計／人事・労務の「API と MCP」を横に並べる

下の表は RenkeiMap の調査記録 から機械で描いています（記号や札をクリックすると総結と原文・出典）。

経理・会計

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

人事・労務

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここでの調査範囲について

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