小編精選 - 技術文章翻譯 · 09月03日

MCP vs. API（REST・SOAP・GraphQL・gRPC）哪個能用？我調查了日本的 56 個業務系統

＜空想的中小企業的故事＞

會計部門：「CRM 和雲端會計的往來客戶，不能串接嗎？」 → IT 負責人：「我查查看。」
社長：「能不能讓 AI 代理人幫忙做資料分析？」 → IT 負責人：「我查查看。」
總務：「資料流到雲端或 AI，資安沒問題嗎？」 → IT 負責人：「我查查看。」
…
IT 負責人：「Google 搜尋 → MCP、REST、SOAP、GraphQL、gRPC… → ？？？」
IT 負責人：「結果，不知道該從哪裡開始查才好。」

這篇文章，是為了讓那位 IT 負責人能夠決定 應該先從哪個順序著手 而寫的。

我沒有實作。只讀了公開資料。 「快／穩定」沒有測量，所以不會寫。

趕時間的人請看：第 5 章有【同時提供 API 與 MCP 的 14 套系統列表】。 想先確認系統名稱的人，可以直接跳到那裡。

先講結論。

查詢順序要從「對方提供了什麼」開始。 自己公司要用什麼，是之後才決定
MCP 不是 API 的替代品。 有提供 MCP 的 14 件，14 件全都有 API
「API」不是只有一種。 REST、SOAP、GraphQL、gRPC 都是不同規格

0. 先把會出現的詞一行一行列出來

搜尋時迷路的一半原因，是詞彙沒有先說明就直接出現。這裡先把文章裡會出現的詞列出來。全部都有官方一手資料連結。

16 個術語一覽（點擊展開） — 正式名稱・一句說明・官方連結詞彙正式名稱一句說明官方APIApplication Programming Interface讓程式呼叫其他系統的入口—RESTREpresentational State Transfer以網址（URL）直接指向資源的呼叫方式，例如 /customers/123。遵循 HTTP 規則，但沒有單獨的規格書（Fielding 論文, 2000）。HTTP 本身見 RFC 9110SOAP（SOAP 1.2 不展開縮寫）把 XML 包成訊息，送到單一入口的方式W3C SOAP 1.2GraphQL（專有名詞，不是縮寫）由呼叫方自行寫出「想要哪些欄位」的查詢語言GraphQL 規格gRPCgRPC Remote Procedure Calls從定義檔產生程式碼後呼叫的方式，常用於內部系統之間gRPC 官方MCPModel Context Protocol讓 AI 知道「能做什麼」的通用寫法MCP 規格 2026-07-28（本文閱讀的是目前這一版）OpenAPI（舊稱 Swagger）把 REST API 的設計圖寫成機器可讀格式的規範OpenAPI 3.2.0WSDLWeb Services Description LanguageSOAP 版的設計圖W3C WSDL 2.0JSON-RPCJSON Remote Procedure Call用 JSON 寫「請用這個參數呼叫這個函式」的規則。MCP 的基礎JSON-RPC 2.0OAuthOpen Authorization不傳密碼也能授權「只允許這個範圍」的機制。2.1 是 2.0 的整理版RFC 6749（2.0）／OAuth 2.1（草案）API 金鑰—用一串字串做認證。只能限制在發行時決定的範圍（像 kintone 那樣可按應用程式、操作來限制的也有，但多數是拿一把就全都能用）——無狀態（stateless）—不記得前一次呼叫的性質。每次都要送出全部資訊——JSON Schema—像「這個欄位是字串、那個欄位是整數」一樣，用來描述資料格式的規範。MCP 用它來寫功能的輸入輸出json-schema.orgProtocol Buffers—gRPC 使用的資料格式與介面定義規範protobuf.dev429429 Too Many Requests表示「在一定時間內送太多」的 HTTP 回應RFC 6585AI 代理人—把目標交給它後，會自行決定要呼叫什麼來執行的 AI—不需要全部記起來。 看到時再回來查即可。

1. 從用途看 MCP 和 API 的差異

四層圖。最上層是業務系統，中層左邊是 API 伺服器、右邊是 MCP 伺服器，下層左邊是程式、右邊是 AI 代理人。所有箭頭都從呼叫方指向被呼叫方，實線表示預設路徑，虛線表示也能連，但會繞路

先把什麼和什麼是怎麼連起來的畫成一張圖。

在下圖中，實線是為此準備好的路徑，虛線是能連，但屬於繞路。

四種組合都能連。 常見誤解是「AI 只能用 MCP」「程式只能用 API」，其實都不對。

虛線① 程式 → MCP 伺服器

可以連。MCP 是通訊規範，所以人寫的程式也能呼叫。不過 MCP 伺服器是偏向 AI 的功能清單。如果是一般整合，API 能做的範圍更廣（詳見第 5 章）。

虛線② AI 代理人 → API 伺服器

也可以連。事實上，過去的 AI 串接多半就是這樣做的。不過 需要人先教它「這個 API 要這樣呼叫」。

實線 AI 代理人 → MCP 伺服器

MCP 伺服器會在入口處公開功能清單。所以 AI 可以自己找到「能做什麼」並拿來用，不需要逐一教學（詳見第 2 章）。

而且，不管走哪條路，底下的業務系統都還是同一套。 就算透過 MCP，是否可寫入、呼叫次數上限、認證、條款，這些都還是照樣生效。

2. 從規格看 MCP 和 API 的差異

REST、SOAP、GraphQL、gRPC、MCP 五種方式以六個軸向比較的表格。只有第一行「是否在執行時公開功能清單」是 MCP 為◎，其他為—或△

這裡先統一 「API 不是只有一種」 這件事。REST、SOAP、GraphQL、gRPC 各自都是不同規格。再加上 MCP，一共五種放在同一把尺上比較。

最上面那一列，是只有 MCP 才有的東西。

A 是否在執行時公開功能清單

MCP 會在入口用像 tools/list 這樣的形式，自己宣告「我這裡有這些操作」。呼叫方可以在沒有先驗知識的情況下直接取得清單。

REST 和 SOAP 也有描述機制（OpenAPI、WSDL），但那是設計階段給人或工具讀的，和執行時由對方自己宣告是不同的。GraphQL 有型別內省（introspection＝向對方詢問「有哪些型別」的功能），所以這一列屬於中間值。

B 入口數量（是否需要 URL 設計）

只有 REST 需要 URL 設計。 像 /customers/123 這樣，網址本身就有意義。SOAP、GraphQL、MCP 都是「把訊息送到單一入口」的形式。MCP 是把 HTTP POST 送到單一端點。

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 的公司，錯誤系統會變成兩套。

E 規格是否定義認證

這裡分開。REST 和 GraphQL 都是認證在規格外（通常另外搭配 OAuth 等）。MCP 對遠端型（透過 HTTP 連線的形式）在規格內定義了基於 OAuth 2.1 的授權規則。 但在規格上是「可選（OPTIONAL）」，本機型（在自己電腦上執行的形式）不在這個規則適用範圍內。本機型是從環境中讀取憑證（見 5-1 節）。

也就是說，MCP 不是代替認證，而是以 OAuth 為前提。 如果你原本就用 OAuth 提供 API，基礎是共通的；如果沒有，就要為 MCP 準備 OAuth。

F 是否無狀態

MCP 規格（目前 2026-07-28 版）明確寫著 「MCP 是無狀態協定」，伺服器不能依賴前一次呼叫來建立上下文。也寫了 「協定上沒有 session」。如果要做跨多次呼叫的流程，狀態管理要自己設計。

（上一版 2025-06-18 版中，遠端型伺服器還能透過 Mcp-Session-Id 保有 session。現行版已經移除這段。規格本身也會變，這就是例子。）

上限（呼叫次數限制）

雖然沒有放在規格比較表裡，但很重要所以提一下。MCP 規格要求伺服器必須實作呼叫上限。 不能說「因為是 MCP，所以不用設計上限」。

AI 的呼叫速度比人快。 不管走哪條路，做上限設計都避不掉。

3. 系統 56 件的對應狀況

調查的56個系統對應狀況長條圖。以某種形式提供 API 的有47件，REST 系31件，雖然看不出形式但有16件，MCP有14件，只有MCP沒有API的是0件

從這裡開始是實際統計結果。這是根據編輯部完成一手調查後公開的 56 套系統所做的統計。

以某種形式提供 API 的有 47 件（第三方可直接使用的有 28 件），提供 MCP 伺服器的有 14 件。

而最底下那一列，就是本文的答案。

只有 MCP、沒有 API 的系統，0 件。

提供 MCP 的 14 件，14 件全部也提供 API。 在我們調查範圍內，沒有看到從零開始只做 AI 入口的例子。

有 API 但連形式都讀不出來的有 16 件。所以不能寫成「日本業務系統以 REST 為主流」。 能寫的只有「在能讀到形式的範圍內，內部分布是這樣」。

4. 各種方式可以讀到哪裡

比較五種方式從公開資料能讀到哪裡的表。G〜J 是符號，K 是文字，L 是數量。J 的規格變更追蹤，只有 MCP 是◎

IT 負責人實際上最困擾的，是「查了還是不知道」的地方。以下按方式整理，看看從公開資料能讀到哪裡。

G 能做什麼的清單

GraphQL、gRPC、MCP 因為定義本身就是機器可讀格式，所以整體可見。REST 如果有公開 OpenAPI（設計圖）也能看見，但有些公司沒有公開。

H 欄位格式（Schema）

就是「日期是什麼格式」「金額是整數還是小數」這種資訊。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 人事勞務寫明每小時 10,000 次，但會計是「數值不公開」（只有 429 的定義）。

上限的寫法也不一致。 kintone 是每天的次數、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 的14個系統列表表格。以符號顯示 REST、SOAP、GraphQL 的有無與 MCP 可做範圍，並在各列補充本機/遠端差異與呼叫次數上限數值

圖表沒有列出的其他系統，我也把 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）／ Money Forward Cloud 薪資（REST 系（HTTP + JSON，未明確寫 REST））／ Money Forward Cloud 費用（REST）／ Money Forward Cloud 請款書（REST）

提供 SOAP・GraphQL 的系統，都包含在上圖的 14 件裡（SOAP 是 Garoon 和 Salesforce 兩種，GraphQL 是 Shopify）。gRPC 為 0 件。

有 API 但無法讀出形式的（16 件）ANDPAD ／ CLIUS ／ Comiru ／ e-TUMO ／ eLTAX / PCdesk（檔案進出）／ formrun ／ G Biz ID ／ Microsoft Forms ／ケア樹／ジョブカン給与計算／ジョブカン勤怠管理／ジョブカン労務HR（檔案進出）／ダンドリワーク／どっと原価（檔案進出）／ Money Forward Cloud 社會保險／樂樂結帳（檔案進出）

確認不到公開 API 的（9 件）Airワーク採用管理（在公開資訊範圍內找不到）／ e內容證明（在公開資訊範圍內找不到）／ freee 申告（在公開資訊範圍內找不到）／ Graffer 智慧申請（在公開資訊範圍內找不到）／ LoGoForm（在公開資訊範圍內找不到）／いえらぶBB（無法透過 robots.txt 判定）／いえらぶCLOUD（在公開資訊範圍內找不到）／ Cybozu Office（明確不允許外部使用）／弥生（會計／藍色申告線上／Next）（在公開資訊範圍內找不到）

「形式讀不出來」不等於「沒有 API」。有時只是公開資料沒寫，實際上詢問就會知道。檔案進出是和格式不同的另一個軸，所以我放在括號裡。

這就是對會計、社長、總務那三個問題的實際材料。

表格的看法

形式欄是根據公開資料讀到的內容。讀不到的就沒有列
上限在各列備註中直接寫出數值。14 件裡 能讀出數值的有 10 件
- 3 件是數值不公開（freee會計・MF Cloud 會計・Garoon）。freee會計和 MF Cloud 會計只寫了會回 429，沒寫數值
- 1 件是「有數值但無法確認」（Jotform）。費用頁面的嵌入資料有每日次數，但畫面表格是用 JavaScript 繪製，從保存下來的資料無法確認是否和顯示值一致
最右側備註寫的是 MCP 伺服器的型態（本機或遠端）

MCP 的功能範圍一律比 API 窄。

各家公司都是先決定「MCP 伺服器可以做哪些操作」。像 kintone 是記錄的取得、新增、更新、刪除；Garoon 是排程建立、空閒時段搜尋；Shopify 則是 Storefront（型錄、購物車）和顧客帳號兩類。

如果要做 MCP 清單裡沒有的操作，最後還是得呼叫 API。

5-1. 本機型與遠端型的差異 —— 這就是總務問題的答案

上下排列的 MCP 伺服器遠端型與本機型比較圖。逐項比較要準備什麼、認證、憑證放哪裡、資料經過的路徑

MCP 伺服器有兩種放置方式。 光看名字看不出來，所以這裡說明差在哪裡。

遠端型（連到對方公司的伺服器）

要準備的東西：只有連線設定。自家公司不需要架伺服器
認證：MCP 規格對基於 OAuth 2.1 的授權有定義。會出現「允許這個 AI 只使用這些範圍」的畫面
憑證放在哪裡：對方公司（會發放 access token，由對方管理）
資料路徑：自家公司 → 對方的 MCP 伺服器 → 對方的業務系統
例：MF Cloud 會計、Google 系列、Salesforce、Slack、Jotform

本機型（在自家電腦或伺服器上執行）

要準備的東西：執行環境（電腦或伺服器）與其維運
認證：從環境讀取憑證。 MCP 規格就是這樣定義的（不適用遠端型的 OAuth 規則）。各家實作不同，kintone 的 MCP 伺服器使用 API Token（可按應用程式發行，並選擇允許的操作）或密碼，freee 的 MCP 伺服器使用 OAuth 2.0
憑證放在哪裡：自家內部
資料路徑：自家內部的 MCP 伺服器 → 對方的 API
例：freee、Garoon（kintone 和 HubSpot 兩者都有）

把認證方式一起看，會變成這樣。

遠端型本機型認證OAuth 2.1 的規則從環境讀取憑證（內容依系統而異：API Token 型／OAuth 型）權限是否能按範圍限制可以（在授權畫面選）依發行時決定的範圍（kintone 的 token 可到應用程式／操作層級，OAuth 型則在授權畫面選）憑證放置位置對方公司自家內部是否需要架設不需要**需要**不能簡單說哪一種比較安全。

遠端型是憑證會交給對方，但可以透過 OAuth 以範圍方式限制「可以碰到哪裡」
本機型是憑證不離開自家公司，但憑證類型依系統而異。API Token 型（kintone）在發行時就選定應用程式與操作，OAuth 型（freee）則在授權畫面選。兩者都需要先決定好要交給 AI 的範圍

不論哪一種型態，資料都還是會送到 AI 模型提供者那邊。 這一點不會因為是 MCP 或 API 而改變。

若要回答總務的「資安沒問題嗎？」這個問題，就要把這兩件事分開說明。 不是只有「有沒有上雲」這一軸而已。

6. 調查後還是看不懂時該怎麼辦

確認API是否存在、是否可寫入、呼叫次數上限、認證、條款這5項的檢查清單圖

照著前面的步驟查，一定還是會有讀不懂的項目。 以查過 56 件系統的感受來說，最容易卡住的是下面 3 件事。

呼叫次數上限沒有寫

這是最常見的情況（56 件中有 28 件沒有提到上限）。

此時請把它當成「不知道」，不要當成「沒有」。 幾乎沒有不設上限的 API，只是沒寫而已。

實務上，先小量測試，看會不會回 429（too many requests）。有些回應標頭也會帶剩餘次數（freee 人事勞務明確寫有 X-RateLimit- 系列標頭）。

只寫了「有 API」

這種情況是沒有寫到「能做什麼」。看不出來是只有讀取，還是也能寫入。

如果公開了設計圖（OpenAPI），裡面會全部寫清楚。 如果沒公開，就只能去問開發者支援窗口。56 件全部都有對外詢問窗口。

沒有寫能不能透過 AI 使用

規約裡沒有提到 AI 並不少見。沒有寫，不等於可以。

如果需要判斷，最好是詢問並留下紀錄，以免之後被說「你沒有先問」。

6-1. 看不出來本身，就是判斷依據

如果某系統沒有公開上限，就不能設計成讓 AI 每分鐘打幾百次。 與其說「因為不知道所以先保守」，不如說「不知道就代表不能選這個設計」，這樣更符合實務。

如果讀不出來的項目太多，也可以先從人手動操作的範圍開始，邊觀察邊擴大——這也是一個選項。

7. 所以調查順序會變成這樣

用六個步驟表示使用方的調查順序的圖。先看有沒有API、能不能寫入、呼叫次數上限、認證、條款，最後第6才看有沒有MCP

要先看對方提供什麼，再決定自己公司要導入什麼。 如果順序反過來，決定好之後才發現「對方不支援」，就來不及了。

對方系統有沒有 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 Cloud 會計）都有提供 API。

要確認的是「能不能寫入」。 如果要建立往來客戶，只有讀取是不夠的。

社長：「能不能讓 AI 代理人幫忙分析資料？」

→ 如果只是分析，讀取就夠了。 只有讀取時，有 MCP 會比較快。因為對方會公開功能清單，AI 可以自己找。

就算對方沒有 MCP，也可以把 API 教給 AI 來運作。 不是因為沒有 MCP 就沒辦法。

總務：「資料流到雲端或 AI，資安沒問題嗎？」

→ 要看 3 件事。

認證是 OAuth 還是 API 金鑰 — 如果是 OAuth，可以在授權畫面限制 AI 可碰的範圍。API 金鑰則多半是發行時決定範圍後就固定（多為一把可用全部）
MCP 是本機型還是遠端型 — 本機型的話，憑證不會離開自家公司。不過憑證種類會依系統而異，而且可授權的範圍要在發行時先決定
條款 — 透過 AI 使用也屬於 API 使用條款的範圍

不能只用「有沒有上雲」這一個維度回答。 因為憑證放哪裡、能不能限制權限，是兩回事。