%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
MCPとREST APIは競合ではなく役割分担です。MCPは既存のREST APIの上に載る「AIオーケストレーション層」であり、動的ディスカバリーとコンテキスト保持という2点が、使い分けの判断を決めます。
MCPとREST APIは競合ではなく役割分担です。MCPは既存のREST APIの上に載る「AIオーケストレーション層」であり、動的ディスカバリーとコンテキスト保持という2点が、使い分けの判断を決めます。
「AI連携のためにMCPを入れるなら、今あるAPI連携は作り直しですか」「社内でMCPサーバーを立てる話が出ているが、REST APIとの違いが正直わからない」「エンジニアに聞くと技術の話になり、経営としてどう判断していいかわからない」——このあたりが、私たちがご相談をいただくときによく出てくる言葉です。
MCP（Model Context Protocol）とは、AIエージェントが外部のツールやデータを自律的に発見し、選択・実行するための通信プロトコルです。REST APIが「人間の開発者がドキュメントを読んでコードを書く」ことを前提に設計されているのに対し、MCPは「AIがランタイムで使えるツールを見つけて選ぶ」ことを前提に設計されています。つまり両者は敵対関係ではなく、接続する相手が人間かAIかで棲み分けるものです。
本記事は、MCP連携シリーズの一部です。AI活用完全ガイドで、AI活用の全体像を把握できます。MCPの基本概念からおさらいしたい方はMCPとは何かを、構築の実務は「MCPサーバーの構築ガイド」をあわせてご覧ください。
この記事でわかること
この記事では、MCPとREST APIの違いを技術論で終わらせず、自社のどの連携から手をつけるべきかという判断に落とし込めるように整理します。読み終える頃には、自社がどちらを軸にすべきかの見通しが立つはずです。
- MCPとREST APIの設計思想の違い — 通信方式・ツール発見・コンテキスト・認証という4つの軸で、何がどう違うのかを表で整理します。
- どちらを選ぶかの判断基準 — 接続元がWebアプリなのかAIエージェントなのかという「接続元起点」の判断軸をお伝えします。
- MCPが向かないケース — 万能ではありません。REST APIのままにしておいたほうがよい領域を率直に書きます。
- 既存API資産を活かす共存設計 — APIラッピングパターンで、作り直しをせずにAIエージェント対応する考え方を解説します。
- CRMを軸にしたスモールスタートの順番 — いきなり全社ではなく、どこから試すかの現実的な進め方を示します。
システム連携の方針を決める立場の方、情シス・DX推進部門の方、そしてHubSpotなどのCRMをAIから操作させたいと考えている事業責任者の方に向けて書いています。最後まで読むと、「うちはMCPを入れるべきか、まだREST APIで十分か」を自社の状況に当てはめて判断できるようになります。
MCPとREST APIの設計思想はどこが違うのか
MCPとREST APIの違いを理解する近道は、「誰のために設計されたプロトコルか」という一点に絞って考えることです。ここが違うと、通信方式もスキーマの扱いも認証も、すべて連動して変わってきます。まずは根っこの思想から整理します。
REST APIは「人間の開発者」を読み手に想定している
REST APIは、ステートレスなHTTPリクエスト/レスポンスモデルに基づき、リソースをURL（エンドポイント）で表現し、HTTPメソッド（GET/POST/PUT/DELETE）で操作を定義する設計思想です。開発者はAPIドキュメントを読み、エンドポイントのURL、リクエストパラメータ、レスポンス形式を事前に理解したうえでコードを書きます。
ここで重要なのは、「理解する主体が人間である」という前提です。ドキュメントの日本語が多少曖昧でも、サンプルコードが少し古くても、人間なら文脈で補完して実装できます。この「人間の補完能力」に暗黙的に依存しているのが、REST APIの設計の特徴です。エンタープライズ環境での展開の考え方は「MCPのエンタープライズ導入ガイド」で解説しています。
MCPは「AIエージェント」を読み手に想定している
MCPは、AIモデルが自律的に利用可能なツールを発見し、適切に選択・実行することを前提に設計されています。JSON-RPC 2.0をベースとし、ツール定義にはスキーマ（入出力の型）と説明文（AIが判断に使用）が含まれます。開発者が事前にエンドポイントを把握する必要がなく、AIがランタイムで動的にツールを発見して利用します。
つまりMCPでは、ツールの「説明文」が実装の一部になります。人間向けドキュメントなら注釈で済んだ情報が、MCPではAIの選択精度を直接左右する設計資産になる、という点が要点になるところです。HubSpotでの具体的な使い方は「HubSpot MCP Serverの活用ガイド」で解説しています。
7つの観点で並べた本質的な違い
| 観点 | 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ではオプション扱いだったスキーマ記述が、MCPでは必須になります。裏を返すと、スキーマ定義がいい加減なまま作られたAPIは、そのままMCP化してもAIがうまく使えません。ここはのちほど「向かないケース」で改めて触れます。
動的ディスカバリーが変える連携の運用
MCPとREST APIの違いのなかで、日々の運用に最も効いてくるのが動的ディスカバリーです。「機能を足したときに、誰がどこを直すのか」という話に直結するためです。ここでは仕組みと、CRM操作を例にした具体的な違いを見ていきます。
REST APIでは「追加したら、使う側も直す」
REST APIでは、開発者がSwagger UIやAPIドキュメントを読み、利用可能なエンドポイント、リクエストパラメータ、ページネーション方式を理解したうえでコードを記述します。APIが更新されればドキュメントを再確認し、クライアントコードを修正する必要があります。
この「提供側の変更が、利用側の改修を呼ぶ」構造が、連携が増えるほど運用負荷になっていきます。連携先が5本、10本と増えていくと、どのシステムのどのバージョンに追従しているかを人が把握し続けることになり、結局は担当者の頭の中にしか全体像がない状態になりがちです。Excelで連携一覧を管理している、という話も現場ではよく伺います。
MCPではtools/listで使える道具が自己申告される
MCPでは、クライアントがサーバーにtools/listリクエストを送信するだけで、利用可能な全ツールの名前、説明文、入力スキーマを取得できます。AIエージェントはこの情報を基に、ユーザーの指示に最も適したツールを自動選択します。サーバー側にツールが追加されれば、クライアント側のコード変更なしに新機能が利用可能になります。
これは、人の運用でいえば「道具箱の中身を、使う人が毎回自分で確認してから作業する」状態に近いです。担当者が一覧表をメンテナンスし続ける仕組みではなく、プロトコル自体が一覧を返してくれる仕組みになっているため、属人化しにくい構造になっています。人ではなくシステムで解決する、という点で相性のよい設計です。
HubSpot CRMのコンタクト検索で比べてみる
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 | MCP |
|---|---|---|
| 事前準備 | API Referenceの読解 | 不要（tools/listで取得） |
| 検索条件の指定 | filterGroupsのJSONを手で組む |
自然言語の指示から構成 |
| ページネーション | afterパラメータを自前実装 |
ツール定義に内包 |
| 検索対象の追加 | クライアント側を改修 | サーバー側のツール追加のみ |
ただし、この手軽さはそのまま「AIが意図と違うツールを選ぶ可能性」と裏表です。読み取り系から始めて挙動を確認し、書き込み系は後から解禁する、という段階の踏み方が現実的です。
コンテキスト管理の差が「連鎖する業務」で効く
CRMやSFAの実務は、単発のデータ取得で完結することがほとんどありません。会社を調べ、取引を確認し、担当者に連絡する、という連鎖で成り立っています。この連鎖をどちらが支えられるかが、MCPとREST APIの実務上の分かれ目になります。
REST APIは一回ごとに記憶が切れる
REST APIはステートレスが原則であり、各リクエストは独立しています。複数のAPIを連鎖的に呼び出す場合、前のレスポンスから必要なデータを抽出して次のリクエストに渡す処理を開発者が明示的にコーディングする必要があります。
これ自体は悪いことではなく、スケールしやすさや障害時の切り分けやすさという明確なメリットがあります。ただ、「業務の手順が変わるたびにコードを直す」というコストが乗り続ける点は、運用を設計するうえで見込んでおく必要があります。
MCPはセッション内で文脈を引き継ぐ
MCPセッション内では、AIエージェントが複数のツール呼び出しの結果を自動的にコンテキストとして保持します。「この会社の直近の取引を表示して」→「その中で金額が最大のものの詳細を見せて」→「その取引の担当者にSlackでメッセージを送って」といった連鎖的な指示が、セッションのコンテキストを引き継ぎながらシームレスに実行されます。
上の画面は、Slackの#hubspot-demoチャンネルにHubSpotのヘルプデスクからの通知が届いている様子です。CRMの動きが日常のコミュニケーションツール側に流れてくる状態をつくっておくと、AIエージェントに連鎖操作を任せたときも、結果を人が確認しやすくなります。
以下の画面は、Slackの#hubspot-demoチャンネルとHubSpot Help Desk連携通知です。
全体フローのどこにMCPを置くかを先に決める
ここで一度、HubSpotの全体フローに当てはめて考えてみます。私たちがCRM設計をご支援するときは、コンタクト獲得 → ライフサイクルステージによる検討段階の可視化 → 取引パイプラインでの商談管理 → 受注・請求、という一気通貫の流れで捉えます。MCPはこのフローのどこか一箇所を置き換えるものではなく、各段階のデータに対してAIから問い合わせ・操作をするための入り口として横に刺さるイメージです。
| 全体フローの段階 | 人が主に使うもの | MCPで任せやすいこと |
|---|---|---|
| コンタクト獲得 | フォーム・リスト | 重複や表記ゆれの洗い出し |
| 検討段階の可視化 | ライフサイクルステージ | レコードの要約・分類の下書き |
| 商談管理 | 取引パイプライン | 特定条件の取引の抽出・進捗の確認 |
| 受注・請求 | 取引・見積 | 数値の突合と差分の報告 |
ただし、パイプラインのステージ設計そのものや、ライフサイクルステージの定義をどうするかは、AIではなく人が決める領域です。ここはビジネス理解が必要な部分であり、MCPで接続したからといって自動的に良い設計になるわけではありません。
セキュリティモデルの比較と、AI固有のリスク
連携方式を選ぶとき、機能面と同じくらい重要なのがセキュリティの考え方です。MCPはAIエージェントを前提にしているぶん、従来のAPI連携には存在しなかったリスクも抱えています。良い面と危うい面の両方を整理します。
| 観点 | REST API | MCP |
|---|---|---|
| 認証方式 | API Key、OAuth 2.0、JWT、mTLSなど多様な方式が混在 | OAuth 2.1を標準認証方式として採用 |
| 実装・管理の負担 | APIごとに認証仕様を個別に実装し、鍵の管理が複雑になりやすい | PKCEの必須化など、AIエージェント固有の要件に対応 |
REST APIは認証方式が分散している
REST APIのセキュリティは、API Key、OAuth 2.0、JWT、mTLSなど多様な方式が混在しています。API提供者ごとに認証方式が異なり、開発者は各APIの認証仕様を個別に実装する必要があります。実装の自由度が高い一方、連携先が増えるほど「どこにどの鍵があるか」の管理が複雑になっていきます。
MCPはOAuth 2.1に標準化されている
MCPはOAuth 2.1を標準認証方式として採用し、PKCEの必須化、ツールアノテーションによる操作分類（readOnly/destructive）、エリシテーションによるサーバー主導の情報要求など、AIエージェント固有のセキュリティ要件に対応しています。
特に実務で効いてくるのがツールアノテーションです。「これは読み取りだけのツール」「これは破壊的な操作を含むツール」がメタデータとして宣言されるため、権限設計を人の注意力に頼らず、仕組みとして分離できます。HubSpotで「プロパティ設定は管理者のみ変更可能にする」といった権限設計をするのと同じ発想を、AI連携の側にも持ち込めるということです。
正直に書くと、MCP特有の攻撃面はまだ新しい
MCPにはプロンプトインジェクションやツールポイズニングといったAI固有の攻撃ベクトルが存在し、OWASP MCP Top 10として体系化されています。詳細はMCPのセキュリティリスクと対策をご確認ください。
私たちがお客様にお伝えしているのは、「自律実行モードはまだ避けたほうがよい」という点です。
- AIに任せる範囲 ── 下書きを作るところまで
- 人が確認してから実行する範囲 ── 外部への送信やデータの削除・更新といった取り返しのつかない操作
この線引きを最初に決めておくことが、AI連携を安全に広げる前提になります。
MCPが向かないケースを先に押さえる
MCPは便利ですが、すべてのシステム連携をMCPにすべきという話ではありません。むしろ、向かない領域にまで広げてしまうと、かえって運用が複雑になります。ここは率直に書いておきます。
処理の手順が完全に決まっている定型連携
夜間バッチで固定の条件のデータを転送する、といった手順が確定している処理では、AIに選択させる余地がありません。決まった順序で決まったAPIを呼べばよい処理に、ツール選択の不確実性を持ち込む理由は薄いです。こうした領域はREST APIやgRPCのままにしておくほうが、挙動が読みやすく保守もしやすいと考えています。
スキーマ定義が曖昧なまま運用されているAPI
MCPではJSON Schemaが必須で、AIがそれを解釈して使い方を判断します。逆に言えば、フィールド名が略語だらけで何のデータか読み取れない、説明文がないといったAPIは、MCP化しても期待どおりに動かない可能性が高いです。この場合はMCP導入より先に、スキーマと説明文の整備という地味な作業が必要になります。
金額・件数の影響が大きい操作
取引の受注登録や、大量レコードの一括更新のように、間違えたときの影響が大きい操作をAIの自動判断に載せるのは、現時点では慎重であるべきだと考えています。AIに任せるのは候補の抽出や下書きまでで、確定操作は人が担う。この役割分担を表に落としておくと、社内での合意も取りやすくなります。
| 領域 | AIに任せやすい | 人が判断すべき |
|---|---|---|
| データ参照 | 検索・要約・集計の下書き | どの指標を見るかの定義 |
| データ入力 | 表記ゆれの検出・分類案 | 必須プロパティの設計 |
| 商談管理 | 条件に合う取引の抽出 | ステージ設計と受注確度の設定 |
| 外部連絡 | メール文面の下書き | 送信可否の最終判断 |
共存パターン｜既存API資産を捨てずにAI対応する
ここまでの整理を踏まえると、現実的な選択肢は「どちらか」ではなく「両方をどう重ねるか」になります。既存のシステム連携を作り直さずに、AIエージェント対応を足していく設計パターンを見ていきます。
MCPはREST APIを置き換えない
MCPは既存のREST APIを置き換えるのではなく、REST APIの上にAIオーケストレーション層を追加するものです。REST APIはWebアプリケーション、モバイルアプリ、サーバー間通信など、人間が設計・実装する統合に引き続き最適です。MCPは、AIエージェントが自律的にツールを操作するシナリオに特化しています。経営データの可視化やコンテンツマーケティングを含め、Claude Codeの業務活用に関心のある方はぜひ参考にしてください。
APIラッピングパターン
既存のREST APIをMCPサーバーでラップすることで、APIの再開発なしにAIエージェント対応を実現できます。MCPサーバーは、REST APIのエンドポイントをMCPツールとしてマッピングし、入出力のスキーマ変換とエラーハンドリングを提供します。
この形が現実的なのは、今ある連携を止めずに済むからです。既存の連携はそのまま動かしながら、AIからの入り口だけを別レイヤーとして足す。段階的に拡張していくうえで、リスクの小さい進め方です。CRM API開発の視点からはCRM API開発もご参照ください。
接続元で選ぶ推奨アーキテクチャ
| 接続元 | 推奨プロトコル | 理由 |
|---|---|---|
| Webアプリケーション | REST API | 確立されたエコシステム、フロントエンドとの親和性 |
| モバイルアプリ | REST API / GraphQL | 帯域制限、オフライン対応 |
| サーバー間連携 | REST API / gRPC | パフォーマンス、型安全性 |
| AIエージェント | MCP | 動的ディスカバリー、コンテキスト管理 |
| AIコーディングアシスタント | MCP | ツール自動選択、自然言語インターフェース |
この表の使い方としては、「接続元を先に書き出す」ことをおすすめしています。技術から入るとどうしても比較検討が長引きますが、接続元の一覧から入ると、MCPが必要な範囲は意外と限定的であることが見えてきます。企業様によって最適な形は異なりますので、自社のシステム構成図の上でこの表を当てはめて判断いただくのがよいかと思います。
自社に最適な連携設計を決める4つの問い
MCPとREST APIの使い分けは、一般論では決まりません。自社の状況に当てはめるために、私たちがご相談の場で実際に確認している問いを整理します。この4つに答えられれば、方針はかなり絞り込めます。
問い1｜AIから操作させたい業務は具体的に何か
「AI活用」という粒度のままでは設計に落ちません。CRMのどのオブジェクト（コンタクト・会社・取引・チケット）に対して、誰が、どんな指示を出すのかまで具体化します。ここが曖昧なまま接続だけ先に作ると、使われないツールが増えていきます。HubSpotで「使っていない項目が大量にあるSFA」になってしまうのと同じ構図です。
問い2｜その操作は読み取りか、書き込みか
読み取り中心であれば、MCPの導入ハードルは下がります。書き込みや削除を含むなら、権限設計とレビュー体制をセットで用意する必要があります。ツールアノテーションのreadOnly/destructiveの区分を、自社の業務に当てはめて整理しておくと判断が速くなります。
問い3｜対象データのスキーマは整っているか
プロパティ名がわかりやすく整理され、何を意味するかが定義されているか。ここが整っていない場合、MCP導入の前にデータ整備が必要です。逆に言えば、CRMのプロパティを最小限に絞り、定義を明文化しておく運用は、そのままAI連携の下準備になります。
問い4｜誰が運用を引き継げるか
個人の力量に依存した連携は、その人がいなくなった瞬間に止まります。ツール定義と説明文をドキュメントではなくサーバー側の実装として持てるMCPは、この点で引き継ぎやすい構造です。新任担当者がtools/listを叩けば使える機能が一覧で出てくる状態を目指すと、仕組みとして回るようになります。
判断の目安
| 自社の状況 | 取るべき方針 |
|---|---|
| 接続元がWebアプリ・バッチのみ | 当面はREST APIで十分 |
| AIから読み取り操作をさせたい | 読み取り専用ツールからMCPを試す |
| AIから書き込みもさせたい | 権限設計とレビュー体制を先に整備 |
| スキーマ・プロパティが未整理 | まずCRM側のデータ整備から着手 |
スモールスタートで始めるMCP連携の順番
方針が決まったら、次は進め方です。いきなり全社の全システムをMCP対応させるのは現実的ではありません。効果が出そうなところを見極めて、優先順位をつけて試すのが結局は近道です。
ステップ1｜既存の公式MCPサーバーを読み取り専用で試す
自社でMCPサーバーを構築する前に、まずは提供されているMCPサーバーを読み取り用途で触ってみることをおすすめします。HubSpotは公式MCP Serverを提供しており、AIエージェントからCRMを操作できます。上の画面は、HubSpot公式アプリ「HubSpot Agent for Copilot」のマーケットプレイス掲載ページです。こうした既製のアプリから触り始めると、自社で作るべき範囲の見極めがしやすくなります。
以下の画面は、HubSpot Agent for Copilot のマーケットプレイス掲載ページです。
ステップ2｜一つの業務シナリオに絞って検証する
「取引の進捗確認」「特定条件のコンタクト抽出」など、一つのシナリオに絞って検証します。このとき、AIが選んだツールと実行結果を記録し、意図どおりだったかを人が確認するプロセスを組み込むことをおすすめします。試行の記録があると、範囲を広げるときの判断材料になります。
ステップ3｜必要な範囲だけ自社のAPIをラップする
既製のMCPサーバーでは足りない業務が見えてきたら、そこで初めて自社のREST APIをラップします。最初から網羅的に作らず、検証で必要性が確認できたツールから順に追加する。この順番だと、使われないツールを作り込む無駄が減ります。
ステップ4｜運用ルールを明文化して横展開する
どの操作をAIに任せ、どこから人が確認するか。このルールを文書として残し、利用部門に共有します。ルールが人の頭の中にある状態では横展開できません。運用ルールまで含めて設計したところが、実際に広がっていく分岐点になります。
| ステップ | やること | 判断ポイント |
|---|---|---|
| 1 | 既存MCPサーバーを読み取りで試す | AIの選択精度は業務に耐えるか |
| 2 | 1シナリオで検証 | 人の確認込みで工数が減るか |
| 3 | 必要分だけ自社APIをラップ | 既製では足りない業務があるか |
| 4 | 運用ルールを明文化 | 担当者が変わっても回るか |
MCPの標準化がAPI設計に与える影響
最後に、中長期の視点を整理します。プロトコルの選択は一度決めると数年単位で影響するため、今どの方向に業界が動いているかを押さえておく意味はあります。ただし、トレンドそのものより、その裏にある普遍的な原則のほうが判断には役立ちます。
業界標準化の動き
Agentic AI Foundationの設立により、MCPはAIエージェント連携の業界標準としての位置づけを得ています。OpenAI、Google、MicrosoftがMCPをサポートしたことで、API提供者にとってMCP対応は今後の競争力要因となっていくと考えられます。この流れの詳細はAgentic AI FoundationとMCPの標準化で解説しています。
APIファーストからMCPファーストへ
新規のSaaS製品では、REST APIの設計と同時にMCPサーバーの提供を検討する「MCP-first」のアプローチが広がる見込みです。HubSpotが公式MCP Serverを提供している点は、この流れの先駆けと言えます。
普遍的な原則に引き戻して考える
プロトコルが何に変わっても、変わらない原則が一つあります。
それは「接続の先にあるデータが整っていなければ、どんなプロトコルでも成果は出ない」ということです。
Excelやスプレッドシートに情報が分散し、同じ顧客の情報が複数の場所で食い違っている状態では、MCPで接続しても矛盾した答えが返ってくるだけです。
だからこそ私たちは、AI連携のご相談をいただいたときも、まずCRM側の一元管理・自動化・可視化の状態を確認します。HubSpotであれば、コンタクト・会社・取引・チケットがリレーションデータベースとして紐づいている状態をつくる。この土台があって初めて、MCPという新しい入り口が意味を持ちます。これはHubSpotに限らず、リレーションデータベースを持つCRM全般に当てはまる話です。
よくある質問
ここでは、MCPとREST APIの違いについて、よく挙がる疑問に答えます。
- 前提知識 ── MCPを学ぶためにREST APIの知識は必要か
- 既存SaaSの利用 ── REST APIしか公開していないSaaSでもMCPで使えるか
- 他の仕組みとの違い ── GraphQLとMCPの違い、OpenAPI仕様からのツール定義の自動生成
- 開発者の需要 ── MCPの普及でREST API開発者の需要は減るか
Q. MCPを学ぶためにREST APIの知識は必要ですか？
はい、MCPはREST APIの上に構築されるレイヤーであるため、HTTP、JSON、OAuth 2.0などREST APIの基礎知識は前提となります。MCPサーバーの構築では、バックエンドのREST API呼び出しをMCPツールとしてラップする設計が一般的であり、API開発の経験が直接活きます。新しく学び直すというより、既存の知識の上に「AIが読むための説明とスキーマ」を足す感覚に近いです。
Q. REST APIしか公開していないSaaSでも、MCPで利用できますか？
はい、REST APIを持つサービスであれば、MCPサーバーでラップすることでAIエージェントから利用可能にできます。公開されているMCPサーバーの多くは、既存のREST APIをMCPツールとして再パッケージしたものです。ただし、元のAPIのスキーマや説明が整理されていないと、ラップしてもAIが適切に選択できないケースがあります。
Q. GraphQLとMCPの違いは何ですか？
GraphQLはクライアントが必要なデータの構造を指定してクエリする仕組みであり、人間の開発者がスキーマを理解したうえで最適なクエリを記述する前提です。MCPはAIがツールの説明文を解釈して自律的に操作を選択する設計であり、利用者の前提が異なります。技術的には、GraphQL APIをMCPツールとしてラップすることも可能です。
Q. 既存のOpenAPI仕様からMCPツール定義を自動生成できますか？
はい、OpenAPI（Swagger）仕様からMCPツール定義を自動生成するツールが複数のコミュニティから提供されています。Speakeasyなどの企業が、OpenAPI仕様をインポートしてMCPサーバーコードを自動生成するサービスを展開しており、既存APIのMCP対応を効率化できます。ただし自動生成された説明文がAIにとって十分かは別問題で、ツール説明の手直しは必要になるケースがあります。
Q. MCPの普及により、REST API開発者の需要は減りますか？
REST APIの需要が減ることはなく、むしろMCP対応のためにAPI設計の重要性が増します。MCPサーバーのバックエンドは依然としてREST APIであり、良質なAPI設計がMCPツールの品質を左右します。REST API開発者がMCPの知識を追加することで、AI時代のシステム連携を担えるポジションになると考えています。
まとめ
本記事では、MCPとREST APIの違いを設計思想・動的ディスカバリー・コンテキスト管理・セキュリティの4つの軸で比較し、接続元を起点にした使い分けの判断基準を整理しました。このテーマの全記事はMCP連携ガイドでご覧いただけます。
ポイントを振り返ります。
- MCPはREST APIを置き換えるものではなく、既存APIの上に載るAIオーケストレーション層です
- 動的ディスカバリー（
tools/list）とセッション内コンテキストの持続が、AI向け設計としての最大の違いです - Webアプリ・モバイル・サーバー間連携はREST API、AIエージェントからの操作はMCP、という接続元起点の使い分けが現実的です
- 手順が固定の定型連携や、スキーマが未整理なAPIはMCP化に向きません
- 既存APIをラップするパターンなら、作り直しをせずAIエージェント対応を足せます
最初の一歩としておすすめしたいのは、自社のシステム連携の「接続元」を書き出してみることです。技術比較から入ると結論が出にくいのですが、接続元の一覧から入ると、MCPが必要な範囲は限定的だと見えてくることが多いです。
次の行動は3ステップで進めていただけます。
- 現在動いている連携を洗い出し、接続元（Webアプリ／バッチ／人／AI）ごとに分類する
- AIから操作させたい業務を1つだけ選び、読み取り専用の範囲でMCPを試す
- 試した結果をもとに、AIに任せる範囲と人が確認する範囲のルールを文書化する
企業様によって最適な形は異なりますので、まずは読み取り専用の1シナリオから始めて、効果が確認できた範囲から段階的に広げていただくのがよいかと思います。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
