REST APIは過去20年にわたりシステム連携の標準として機能してきました。しかし、AIエージェントが自律的にツールを選択・実行する時代において、「人間の開発者向けに設計されたAPI」は最適な選択肢なのでしょうか。
MCP（Model Context Protocol）は、REST APIを「置き換える」のではなく、AIエージェント向けの「オーケストレーション層」として機能します。本記事では、MCPとREST APIの設計思想の違い、それぞれの強みと弱み、そして実務における使い分けの基準を解説します。
REST APIは、ステートレスなHTTPリクエスト/レスポンスモデルに基づき、リソースをURL（エンドポイント）で表現し、HTTPメソッド（GET/POST/PUT/DELETE）で操作を定義する設計思想です。開発者はAPIドキュメントを読み、エンドポイントのURL、リクエストパラメータ、レスポンス形式を事前に理解した上でコードを書きます。
MCPは、AIモデルが「自律的に」利用可能なツールを発見し、適切に選択・実行することを前提に設計されています。JSON-RPC 2.0をベースとし、ツール定義にはスキーマ（入出力の型）と説明文（AIが判断に使用）が含まれます。開発者が事前にエンドポイントを把握する必要がなく、AIがランタイムで動的にツールを発見して利用します。
| 観点 | REST API | MCP |
|---|---|---|
| 設計対象 | 人間の開発者 | AIエージェント |
| 通信方式 | ステートレスHTTP（リクエスト/レスポンス） | Streamable HTTP（双方向、ストリーミング対応） |
| ツール発見 | 事前にドキュメントを読む（静的） | tools/listで動的に発見 |
| コンテキスト | 各呼び出しが独立（手動でコンテキスト管理） | セッション内でコンテキストが持続 |
| スキーマ | OpenAPI/Swagger（オプション） | JSON Schema（必須、AIが解釈） |
| 認証 | 多様（API Key、OAuth、JWT等） | OAuth 2.1（標準化） |
| メタデータ | なし | ツールアノテーション（readOnly/destructive等） |
REST APIでは、開発者がSwagger UIやAPIドキュメントを読み、利用可能なエンドポイント、リクエストパラメータ、ページネーション方式を理解した上でコードを記述します。APIが更新されればドキュメントを再確認し、クライアントコードを修正する必要があります。
MCPでは、クライアントがサーバーにtools/listリクエストを送信するだけで、利用可能な全ツールの名前、説明文、入力スキーマを取得できます。AIエージェントはこの情報を基に、ユーザーの指示に最も適したツールを自動選択します。サーバー側にツールが追加されれば、クライアント側のコード変更なしに新機能が利用可能になります。
HubSpot CRMからコンタクトを検索する場合を例にとります。
REST APIの場合: 開発者がHubSpotのAPI Referenceで/crm/v3/objects/contacts/searchエンドポイントを確認し、filterGroupsのJSON構造を理解し、ページネーションのafterパラメータを実装する必要があります。
MCPの場合: AIエージェントがtools/listでHubSpot MCPサーバーのツールを取得し、「東京の企業のコンタクトを検索して」という自然言語の指示に対して、search_contactsツールを自動選択してフィルタ条件を構成します。
REST APIはステートレスが原則であり、各リクエストは独立しています。複数のAPIを連鎖的に呼び出す場合、前のレスポンスから必要なデータを抽出して次のリクエストに渡す処理を開発者が明示的にコーディングする必要があります。
MCPセッション内では、AIエージェントが複数のツール呼び出しの結果を自動的にコンテキストとして保持します。「この会社の直近の取引を表示して」→「その中で金額が最大のものの詳細を見せて」→「その取引の担当者にSlackでメッセージを送って」といった連鎖的な指示が、セッションのコンテキストを引き継ぎながらシームレスに実行されます。
REST APIのセキュリティは、API Key、OAuth 2.0、JWT、mTLSなど多様な方式が混在しています。API提供者ごとに認証方式が異なり、開発者は各APIの認証仕様を個別に実装する必要があります。
MCPはOAuth 2.1を標準認証方式として採用し、PKCEの必須化、ツールアノテーションによる操作分類（readOnly/destructive）、エリシテーションによるサーバー主導の情報要求など、AIエージェント固有のセキュリティ要件に対応しています。
ただし、MCPにはプロンプトインジェクションやツールポイズニングといったAI固有の攻撃ベクトルが存在し、OWASP MCP Top 10として体系化されています。詳細はMCPのセキュリティリスクと対策をご確認ください。
MCPは既存のREST APIを「置き換える」のではなく、REST APIの上に「AIオーケストレーション層」を追加するものです。REST APIはWebアプリケーション、モバイルアプリ、サーバー間通信など、人間が設計・実装する統合に引き続き最適です。MCPは、AIエージェントが自律的にツールを操作するシナリオに特化しています。
既存のREST APIをMCPサーバーでラップすることで、APIの再開発なしにAIエージェント対応を実現できます。MCPサーバーは、REST APIのエンドポイントをMCPツールとしてマッピングし、入出力のスキーマ変換とエラーハンドリングを提供します。
| 接続元 | 推奨プロトコル | 理由 |
|---|---|---|
| Webアプリケーション | REST API | 確立されたエコシステム、フロントエンドとの親和性 |
| モバイルアプリ | REST API / GraphQL | 帯域制限、オフライン対応 |
| サーバー間連携 | REST API / gRPC | パフォーマンス、型安全性 |
| AIエージェント | MCP | 動的ディスカバリー、コンテキスト管理 |
| AIコーディングアシスタント | MCP | ツール自動選択、自然言語インターフェース |
2025年12月のAgentic AI Foundation設立により、MCPはAIエージェント連携の正式な業界標準となりました。OpenAI、Google、MicrosoftがMCPをサポートしたことで、API提供者にとって「MCP対応」は今後の競争力要因となります。
新規のSaaS製品では、REST APIの設計と同時にMCPサーバーの提供を検討する「MCP-first」のアプローチが2026年以降広まる見込みです。HubSpotが公式MCP Serverを提供し、20,000以上の顧客がAIエージェント経由でCRMを操作している事実は、この流れの先駆けです。
MCPの基本についてはMCPとは何かを、CRM API開発の視点からはCRM API開発もご参照ください。
本記事では、MCPとREST APIの違いについて、設計思想・通信方式・セキュリティモデルの比較と、実務における使い分けの基準を解説しました。
ポイントを振り返ります。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
はい、MCPはREST APIの上に構築されるレイヤーであるため、HTTP、JSON、OAuth 2.0などREST APIの基礎知識は前提となります。MCPサーバーの構築では、バックエンドのREST API呼び出しをMCPツールとしてラップする設計が一般的であり、API開発の経験が直接活きます。
はい、REST APIを持つサービスであれば、MCPサーバーでラップすることでAIエージェントから利用可能にできます。多くの公開MCPサーバー（10,000以上）は、既存のREST APIをMCPツールとして再パッケージしたものです。
GraphQLはクライアントが必要なデータの構造を指定してクエリする仕組みであり、「人間の開発者がスキーマを理解した上で最適なクエリを記述する」前提です。MCPはAIがツールの説明文を解釈して自律的に操作を選択する設計であり、利用者の前提が異なります。技術的には、GraphQL APIをMCPツールとしてラップすることも可能です。
はい、OpenAPI（Swagger）仕様からMCPツール定義を自動生成するツールが複数のコミュニティから提供されています。Speakeasyなどの企業が、OpenAPI仕様をインポートしてMCPサーバーコードを自動生成するサービスを展開しており、既存APIのMCP対応を大幅に効率化できます。
REST APIの需要が減ることはなく、むしろMCP対応のためにAPI設計の重要性が増します。MCPサーバーのバックエンドは依然としてREST APIであり、良質なAPI設計がMCPツールの品質を左右します。REST API開発者がMCPの知識を追加することで、AI時代のシステム連携をリードできるポジションに立てます。