MCPはAPIを「エージェントが読める形」に包む規格。アプリ間接続の4つの疑問を深掘りする
MCPはAPIを「エージェントが読める形」に包む規格。アプリ間接続の4つの疑問を深掘りする
前の記事で、機能単位のアプリをストアから選び、エージェントが組み合わせる世界を描いた。そこで「アプリ間の接続はMCPが担う」とさらっと書いたのだが、ここは自分の業務の将来に関わる核心部分なので、Claude Codeとの議論をもとに1本の記事として深掘りしておく。
出発点は自分のこの理解で合っているかの確認だった。
MCPって、いわゆるAPIをコーディングエージェント用にラップしたもの、という理解をしている。ソースコードやAPI仕様を直接読み込ませて理解するんじゃなくて、ラップしたMCPでエージェントとアプリが通信できれば、接続の問題もパクリの問題もないということか？
結論から言うと、この理解でほぼ正確だった。この記事では、その「ほぼ」の部分を正確にした上で、前の記事の最後にまとめた4つの論点——①規格統一はなぜ不要になるのか、②何が公開され何が隠されるのか、③会計はなぜこの世界と相性がいいのか、④解釈ミスをどう受け止めるのか——を順に掘り下げる。
まず理解の確認: MCPは「ラップの標準的な作法」
MCP（Model Context Protocol）は、外部のシステム——API、データベース、ファイル——をAIエージェントから使えるようにするための通信規格で、2024年11月にAnthropicが公開し、その後OpenAIやGoogleも採用して事実上の業界標準になった。ChatGPTのアプリの仕組み（Apps SDK）もこの上に作られている。
「APIをエージェント用にラップしたもの」という理解との対応はこうなる。MCP自体はラップの作法を定めたプロトコルで、その作法に従ってAPIを包んだ結果できるものがMCPサーバーだ。ベンダーは自社の機能をMCPサーバーとして立て、その表面に「ツール宣言」を書く。ツール宣言は3点セットになっている。
- ツール名（例:
get_payroll_records） - 自然言語の説明（例: 「指定した従業員と期間の給与支給記録を返す。金額は課税支給額と非課税支給額に分かれる」）
- 入出力のスキーマ（データの型定義。何を渡すと、どんな構造のデータが返るか）
エージェント側は、接続したMCPサーバーに「何ができるか」を問い合わせると、このツール宣言の一覧が返ってくる。エージェントが読むのはこれだけだ。ソースコードも、人間向けのAPIドキュメントも、実装の中身も読まない。包みの表面に書かれた宣言だけを実行時に読んで、呼び方を理解する。
一点だけ補正しておくと、「エージェント間が通信」という言い方は厳密には少しずれる。MCPが定めるのはエージェントとアプリ（ツール）の間の接続で、エージェント同士が対話する通信は、A2A（Agent2Agent）のような別の規格が生まれつつある領域だ。前の記事の「事業者のエージェントがハブになってアプリを組み合わせる」世界の主役は、エージェント⇔アプリの接続、つまりMCPの側になる。
「エージェントが読める形」という言い方には副産物もある。エージェント（LLM）が読める形式とは自然言語ベースの形式なので、ツール宣言は人間が読んでも意味が取れる。従来は機械向けの仕様書と人間向けのドキュメントを別々に書き、たいてい後者が古びてズレていった。MCPでは説明文の質がエージェントの動作精度に直結するため、ベンダーは人間に説明するつもりの丁寧な文章を書くことになり、結果として仕様書とドキュメントが一体化する。ストアに並ぶ税務アプリに何を任せられるかを、税理士自身がツール宣言を読んで確かめられる——そういう透明性も、この形式から自然に出てくる。
先回りの疑問: 生のAPIドキュメントを読ませれば済むのではないか
ラップの話をすると、当然の疑問が湧く。エージェントがそれほど賢いなら、ラップなどしなくても、既存のAPIドキュメントを直接読ませればいいのではないか。
具体例で考えると分かりやすい。freeeは以前からAPIリファレンスを公開していて、人間の開発者はあれを読んでfreee連携アプリを作ってきた。エージェントに同じものを読ませれば、MCPなしでも仕様を解析して呼び出せるのではないか——答えを先に言うと、できる。LLMには人間向けドキュメントやAPI仕様書を読んで生のAPIを叩く能力が元からあり、MCP化されていないシステムに対しては、現実にこの方法が代替手段として使われている。
この直感には技術的な裏付けもある。FastAPIのようなフレームワークが自動生成するAPIドキュメントページの裏には、OpenAPIという機械可読の仕様データがあり、エンドポイントの一覧・パラメータの型・説明文が構造化されて入っている。情報としては、MCPのツール宣言とほぼ等価だ。実際、既存のOpenAPI仕様を読み込んでMCPサーバーを自動生成する変換ツールが多数あって、世のMCPサーバーのかなりの部分は「OpenAPIの上に被せた薄い包み紙」として作られている。
ではなぜ規格が要るのか。MCPは「エージェントにできないことを可能にする」規格ではなく、「エージェントが毎回やらなくて済むようにする」規格だからだ。差は能力ではなく、経済と統制にある。
- コスト: 膨大なAPIリファレンスを毎回読んで解析するのは時間と推論コストを食い、たまに読み違える。ツール宣言は解析済みの結果を構造化して差し出す。家電を使うたびに取扱説明書を通読するか、ボタンにラベルが貼ってあるかの差だ
- 配管: 仕様を理解できることと、安全に呼び出し続けられることは別問題だ。認証トークンの管理、レート制限、エラー時の再試行——この配管を毎回その場で組ませると事故る。MCPはここを標準化した
- 契約: 人間向けドキュメントは実装とズレたまま放置されがちで、それを推測で読んだエージェントが失敗したときの責任も曖昧になる。ツール宣言はベンダーが実装とセットで保守する「実行可能な契約」で、宣言通りに動かなければベンダーの責任だと切り分けられる
- 統制: ツールという単位があるから「読み取り系は自動許可、書き込み系は毎回確認」という権限制御ができ、ストアの審査も、疑問④で述べる監査証跡も、この単位の上に成立する
つまりMCPのツール宣言は、freeeのAPIリファレンスのエージェント最適化版と言っていい。読者が人間の開発者からエージェントに変わり、「読んでから連携アプリを開発してデプロイする」という中間工程が、「読んだその場で呼ぶ」に短縮される。
そしてfreeeの例は、後述するパクリの心配への現実の回答にもなっている。freeeは何年もAPIを公開してきたが、それで会計エンジンの実装や内部データが盗まれただろうか。公開されているのは「何ができるか」であって「どうやっているか」ではないから、起きていない。MCPの公開の露出度は、これと同じだ。
疑問①: なぜ「規格統一」が要らなくなるのか
前の記事で一番引っかかっていたのはここだった。年末調整アプリは労務アプリから給与データを取らないと動けない。ベンダー同士が互いのデータ仕様を知らないと接続できないはずで、業界全体のデータ規格統一は歴史的に見ても難航する。なぜMCPだとつながるのか。
鍵は、接続作業の担い手が変わることにある。
従来のAPI連携では、接続コード（グルーコード）を書くのは人間の開発者だった。人間は労務アプリの仕様書と年末調整アプリの仕様書を両方読み、「このフィールドはこれに対応する」というマッピングを事前にコードとして書き、デプロイする。人間の作業コストが高いから、業界でデータ項目の意味を統一して（全銀フォーマットや電子インボイスのPeppolのように）、書くコードを減らそうとする。規格統一が必要だったのは、接続が「事前の人間の作業」だったからだ。
MCPとエージェントの世界では、この工程が消える。各アプリはツール宣言（スキーマ＋説明）を公開するだけでよく、それを読んで「労務アプリの出力のこのフィールドは、年末調整アプリの入力のこれに対応する」と解釈し、データを変換して受け渡すのは、実行時のエージェントの仕事になる。接続コードは事前に書かれない。仕様書を突き合わせる作業は、人間の設計工程からエージェントの実行時の読解に移る。
ただし「統一が全部不要になる」わけではない。統一の対象が変わる。データの意味（語彙）の統一は不要になるが、通信の作法（プロトコル）の統一は必要で、その作法こそがMCPだ。ツール宣言をどう書くか、どう問い合わせるか、認証をどう通すか——この土台が揃っているから、エージェントは初めて見るアプリでも読み方が分かる。そしてストアの世界では、この作法はOpenAIのようなプラットフォーマーが審査で強制する。AppleがApp Storeの審査ガイドラインで作法を強制したのと同じ構図だ。
副産物として、接続の壊れ方も変わる。従来はAPIの仕様変更のたびに接続コードが壊れ、人間が書き直していた。エージェントが実行時に宣言を読み直す方式では、アプリ側が宣言を更新すれば、次の実行時に新しい宣言が読まれて吸収される。
疑問②: 何が公開され、何が隠されるのか
「ソースコードをオープンにしたらパクるアプリが出てくるのでは」という心配は、公開の境界線を確認すると解消する。
MCPサーバーが公開するのはツール宣言（インターフェース）だけだ。実装はベンダーのサーバー側で動く。ストアに並ぶ税務アプリの実体は、ベンダーが運用するリモートのMCPサーバーで、エージェントはネットワーク越しに「このツールをこの入力で実行して」と依頼し、結果だけを受け取る。エージェントから見えるのは「何を入れると何が返るか」であって、どうやって計算しているかは一切見えない。
- 公開されるもの: ツール名、説明文、入出力の型
- 隠されるもの: ソースコード、計算ロジック、内部データ、ノウハウ
だから「パクれるもの」はインターフェースの設計だけで、これは今のSaaSがAPI仕様を公開しているのと同じ露出度だ。freeeが何年もAPIリファレンスを公開しながら、会計エンジンの中身を盗まれていないのと同じ構造で、税額計算エンジンや判定精度を支えるデータは、宣言をいくら読んでも手に入らない。守りの構造は従来のAPI公開と変わらない。
ただし、競争の質は変わると思っている。従来のSaaSは人間の乗り換えコスト（画面の学習、データ移行、社内の慣れ）に守られていた。エージェントにはこの粘性がない。同じ宣言形式で並んだ複数のアプリを実際に使い比べ、結果の悪いものをためらいなく乗り換える。インターフェースが標準化された世界では、差別化はインターフェースではなく**実行品質——精度、速度、そして結果の検証可能性——**に移る。インターフェースを真似ただけの「パクリアプリ」は、出せても品質勝負で淘汰されやすい世界とも言える。
乗り換えの摩擦が消えた後: アプリは乱立し、「出口」だけが残る
この「粘性がない」という一点は、掘るとSaaSビジネスの土台に届くので、独立して図にしておく。従来のベンダーロックインの正体は、製品の優秀さというより人間側の摩擦だった。画面の操作を覚え直すのが面倒で、データを手作業で移すのが怖くて、現場を教育し直すのが重い。だから多少の不満があっても使い続ける。SaaSの解約率の低さは、この摩擦に支えられてきた。
乗り換えの主体がエージェントに変わると、この3つの摩擦はすべて消える。画面の学習は宣言を読むだけになり、データ移行は変換作業そのものがエージェントの仕事になり、「慣れ」という概念自体がない。つまり、その時々で最良のアプリに乗り換え続けることが、コストなしでできてしまう。プラットフォーム側から見れば、エージェントが常に使い比べているのだから、「今はこちらのアプリの方が精度が高い」という乗り換え先の提示すら仕組みとして提供できる。
供給側も同じ力を受ける。アプリの開発自体がAIエージェントで安くなるので、機能単位のアプリは乱立に向かうはずだ。初期に作られた良いアプリがそのまま使われ続ける保証はない。乗り換えが楽になりすぎるからだ。さらに言えば、既存アプリの隙間——どのアプリもカバーしていない細かい工程——は、エージェントにその場で埋めさせればいいし、繰り返し使うならエージェントに実装させてアプリとしてデプロイすればいい。「アプリを使う」と「アプリを作る」の境界も溶けていく。
ではすべてが流動化するのかというと、一点だけ残るものがある。**信頼性が本当に要求される「出口」**だ。税務で言えばe-Tax接続——申告として国に提出する最後の一歩——は、精度勝負の乗り換え合戦とは別の論理で動く。ここだけは実績と信頼のあるアプリが押さえ続けるだろう。逆に言うと、信頼できる出口と、前の記事で書いた帳簿データ基盤（台帳と証跡）さえ確保されていれば、途中の工程は税理士事務所が自前のエージェントでだいたい組めてしまう。流動化する中間と、動かない両端（台帳と出口）。この地形が、事務所の打ち手を考えるときの前提になると思っている。
疑問③: 会計はなぜこの世界と相性がいいのか
疑問①で「データの意味の統一は不要になる」と書いたが、会計にはさらに有利な事情がある。データの意味の側にも、複式簿記という500年ものの標準が既にあることだ。
エージェントが橋渡しするといっても、n個のアプリが互いにデータを受け渡す組み合わせは膨大で、すべてをその場の解釈でつなぐのは事故の温床になる。だが会計業務には自然な「合流点」がある。経費精算アプリの出力も、労務アプリの給与計算も、請求書アプリの売上も、最終的にはすべて仕訳という統一形式に変換されて帳簿に載る。借方と貸方、勘定科目、金額、日付、摘要——この形式は、どのベンダーのアプリだろうと変わらない。
つまりアプリ同士が網の目のように直接つながる必要はなく、どのアプリも「仕訳にして帳簿データ基盤に書き込む」ことをゴールにすればいい。帳簿がハブになり、上流のアプリがどれだけ多様でも、下流は複式簿記という一つの言語に収束する。前の記事で「SaaSに残るのは複式簿記の記録と監査証跡の台帳だ」と書いたのは、接続の観点から見ても同じ結論になる。台帳は、エージェント時代のアプリたちの共通着地点として機能する。
もちろん揺れは残る。勘定科目の選び方、消費税区分の判定、発生主義の計上時期——仕訳という形式は統一されていても、形式に落とすまでの解釈には幅がある。そしてそこが、次の疑問につながる。
疑問④: エージェントの解釈ミスは、何が受け止めるのか
この仕組みの弱点は明確で、接続の正しさがエージェントの読解力に依存することだ。
事前に書かれた接続コードは、間違っていれば毎回同じように間違う代わりに、一度正しくすれば毎回正しい。エージェントの実行時解釈は逆で、柔軟な代わりに確率的だ。「課税支給額」と「総支給額」の取り違えのような——人間の経理担当者でも間違える——意味の揺れは、エージェントも間違えうる。ツール宣言の説明文が雑なアプリでは、この危険は上がる（逆に言うと、エージェント時代のベンダーの品質は、説明文とスキーマの書き込みの丁寧さに出る）。
では何が品質を担保するのか。接続コードがない世界では、コードレビューやテストコードに相当するものがない。代わりに担保になるのが監査証跡だと思っている。どのアプリのどのツールを、どんな入力で呼び、何が返り、それをどう解釈して、どの仕訳に落としたか——この連鎖を、後から人間が検証できる形で帳簿に残す。
会計監査の言葉で言えば、これは監査証跡（audit trail）そのものだ。仕訳の背後に証憑があり、証憑から仕訳までの過程を追跡できることが帳簿の信頼性の土台になる——という会計の伝統的な要請が、エージェント時代には「解釈の過程まで含めて記録せよ」という形に拡張される。前の記事で帳簿データ基盤の要件として「複式簿記＋監査証跡」を挙げたのは、この意味でだ。証跡のない自動化は、間違いに気づけない自動化になる。
そして、この証跡を読んで検証する目が、税理士・会計士の仕事の中心になっていく。エージェントが増えるほど、「正しく処理したか」を確かめられる人間の価値は、処理そのものの価値より高くなる。
まとめ
- MCPは「APIをエージェント用にラップする作法」を定めたプロトコルで、その作法で包んだ実体がMCPサーバー。エージェントは包みの表面のツール宣言（名前・説明・入出力スキーマ）だけを実行時に読む。なおMCPはエージェント⇔アプリの規格で、エージェント同士の通信は別規格（A2A等）の領域
- ツール宣言は自然言語ベースなので人間も読める。仕様書と人間向けドキュメントが一体化し、税理士自身が「このアプリに何を任せられるか」を宣言から確かめられる
- 生のAPIドキュメント（freeeのAPIリファレンス等）をエージェントに読ませて解析することも可能で、実際に代替手段として使われている。MCPの価値は能力ではなく経済と統制——毎回の解析コストの削減、認証等の配管の標準化、実行可能な契約、ツール単位の権限制御——にある。freeeがAPIを公開しても実装を盗まれていない現実が、公開範囲の安全性の実例になる
- 規格統一が不要になるのは、接続の担い手が「事前にコードを書く人間」から「実行時に宣言を読むエージェント」に変わるから。統一の対象はデータの意味から通信の作法（MCP）に移り、作法はストアの審査が強制する
- 公開されるのはインターフェースだけで、実装・データ・ノウハウはベンダーのサーバーから出ない。パクれるのは宣言の形だけで、露出度は今のAPI公開と同じ。ただし競争は人間の乗り換えコストに守られない実行品質勝負に変わる
- 会計は複式簿記という既存のデータ標準を持つため、アプリ同士を網の目につなぐ必要がなく、仕訳を共通言語として帳簿ハブに合流できる
- 弱点は解釈ミス。接続コードの代わりに「呼び出し→取得→解釈→仕訳」の連鎖を監査証跡として帳簿に残すことが品質担保になり、その証跡を検証する目が税理士の仕事の中心になる
- ベンダーロックインの正体は人間側の摩擦（操作の習得・データ移行・組織の慣れ）で、乗り換えの主体がエージェントに変わるとすべて消える。アプリは乱立と流動化に向かい、残るのは信頼性が要求される両端——帳簿データ基盤とe-Taxのような出口——で、途中の工程は事務所が自前のエージェントで組めるようになる