9月11日、n8nが「MCP vs. API: Key Differences and When To Use Each」と題した記事を公開した。AIエージェント開発が普及するにつれ「MCPはAPIを置き換えるのか」という議論が増えているが、この記事が示す結論は明快だ。MCPはAPIの代替ではなく、両者は解決する問題が根本的に異なる。問うべきは「どちらか」ではなく「どう組み合わせるか」である。
MCPとAPIは「競合」ではなく「役割分担」
- API：ソフトウェア同士がデータをやり取りするための固定インターフェース。GET・POSTといったHTTPメソッドで特定のエンドポイントを叩き、JSONが返ってくる。認証はAPIキーやOAuth、Bearerトークンで行う。利用可能な機能はOpenAPI仕様などの静的ドキュメントで事前に定義される。
- MCP：AIエージェントが外部のツールを動的に発見して呼び出すためのクライアント・サーバープロトコル。Anthropicが2024年に策定したオープン標準で、「AI向けのUSB-C」とも呼ばれる（異なるデバイス／ソフトウェアを単一規格でつなぐ、という意味での比喩）。メッセージはJSON-RPC形式で転送され、エージェントはサーバーから利用可能なツール一覧を実行時に動的に取得する。
| 観点 | API | MCP |
|---|---|---|
| 主な目的 | ソフトウェア間のデータ移送 | エージェントへのツール提供 |
| 利用者 | 開発者が書いたアプリケーションコード | LLMが動かすAIエージェント |
| 機能の発見 | 静的（ドキュメントやOpenAPI仕様） | 動的（実行時にサーバーが列挙） |
| 状態管理 | 基本的にステートレス | セッションベースでコンテキストが持続 |
| 統合モデル | ペアごとに1実装 | 各サイドに1実装 |
MCPの最大のメリットは「統合コードの爆発的増加を防ぐ」こと
記事が強調するアーキテクチャ上の優位性は、統合コードの削減だ。
共通プロトコルがない場合、M個のモデルをN個のサービスに接続するには最大M×N個のカスタムコードが必要になる。MCPのような共通プロトコルを挟むと、M+N個の実装で済む。AIエージェントが扱うツールの数が増えるほど、この差は大きくなる。
どちらを使うべきか？判断基準は「呼び出し順序が予測できるか」
APIを直接使うべきケース
「前日の注文データを夜間バッチで倉庫システムに同期する」のような処理がその例だ。実行順序が決まっており、全エンドポイントが事前に分かっている。APIを直接呼べばミリ秒単位で処理でき、トークンコストもゼロで、ログから障害箇所も特定しやすい。
MCPを使うべきケース
呼び出し順序が事前に予測できない場合にMCPが力を発揮する。例えば、カスタマーサポートエージェントがユーザーの問い合わせに対応するケース。顧客が何を言うかによって、注文レコードを参照するか、配送状況を確認するか、返金エンドポイントを呼ぶかが変わる。この分岐をハードコードすると、全パターンを永続的にメンテナンスするコストが発生する。MCPサーバーを使えば、エージェントがプロンプトに応じて動的に対応できる。
両方を組み合わせるケース
実際のプロダクションシステムでは、MCPとAPIを重ねて使うのが一般的だ。ほぼすべてのHTTP MCPサーバーの内部にはAPIがある。MCPはエージェントのリクエスト方式を標準化し、実際の処理とレートリミット管理はAPIが担う。
記事が挙げる具体例は返金ワークフローだ。
- 固定のAPIコールで注文を検証
- エージェントが返金の適否を判断
- 固定のAPIコールで結果をコミット
決定論的な処理とエージェント的な処理を組み合わせることで、AIエージェントの信頼性を高めつつ、実行できるアクションを制限できる。
n8nでのMCP×API実装
記事後半では、ワークフロー自動化プラットフォームのn8nを使った具体的な実装例が紹介されている。
n8nでは以下の3ノードでMCPとAPIを組み合わせて使える。
- **HTTP Requestノード**：任意のRESTエンドポイントを呼び出す。curlコマンドをペーストすると自動でフィールドが補完される。既存APIとの連携はこのノード単体で完結するケースが多く、MCPを導入しない処理フローにも広く使われる。
- **MCP Client Toolノード**：外部MCPサーバーに接続し、ツール一覧を取得してエージェントから使えるようにする。n8n上のAIエージェントが「何のツールが使えるか」を実行時に把握するための入口となる。
- **MCP Server Triggerノード**：n8nのワークフロー自体をMCPサーバーとして外部に公開する。社内システムへのAPIアクセスをラップして外部AIツールに提供する、といったユースケースで特に有効だ。
これら3ノードを組み合わせることで、例えば「外部MCPサーバーから取得したツール一覧を使いながら、特定の確定処理はHTTP Requestで直接APIを叩く」という返金ワークフローのような構成が、コードを書かずに組み立てられる。n8nはプロバイダー非依存で、OpenAIからAnthropicや自己ホスト型モデルへの切り替えが可能で、その際にMCPの設定は変更不要だ。
詳細はMCP vs. API: Key Differences and When To Use Eachを参照していただきたい。
