MCPとは？APIとの違いと、導入・併用を判断するポイント

MCPとは、サービス上のツールをAIクライアントが検出し、呼び出すための標準的な仕組みです。APIを置き換えるものではありません。アプリとAIアシスタントの両方に対応するプロダクトでは、MCPとAPIを比較するときも、共通のビジネスルールを2つのインターフェースで利用する構成がよく当てはまります。アプリ連携にはAPIを維持し、既存のAIクライアントからのアクセスが顧客の具体的な業務に役立つなら、MCPを追加します。

MCPとは？APIとの違いを整理する

比較しているのは、ソフトウェアの汎用的なインターフェースと、AI連携のための特定のプロトコルです。 API（Application Programming Interface）は、ソフトウェアがデータや処理を要求する方法を定めます。REST（Representational State Transfer）は、HTTP APIで広く使われるアーキテクチャスタイルです。MCP（Model Context Protocol）は、対応するAIアプリケーションが外部の機能にアクセスする方法を標準化します。

プロダクトを作業場に例えると、APIは利用手順が明記された業務用の入り口です。MCPサーバーはそこに受付を設け、依頼できる作業をAIクライアントが理解できる形式で案内します。ただし、受付の奥で実際に作業する人や、作業を進めるためのルールが不要になるわけではありません。

開発者にとっては、既存の機能を包むアダプターです。プロダクト責任者にとっては、顧客がプロダクトを利用できる場所が増えることを意味します。運用担当者にとっては、アクセス管理や障害対応の責任者が必要なインターフェースが増えることになります。

MCPは、HTTP APIを呼ばずにローカルの機能を公開することもできます。既存APIをラップする構成は便利ですが、必須ではありません。MCPのアーキテクチャドキュメントでは、AIアプリケーションと、機能を提供するサーバーを分けて説明しています。プロトコル全体の概要は、MCPの基礎解説をご覧ください。

MCPとREST APIを比較する

RESTはアプリケーション同士の直接連携に適しています。MCPは、対応するAIクライアントが利用できる共通のツールインターフェースを追加します。 どちらを選んでも、認可やビジネスロジックの正しさを担保する責任は残ります。

この比較は、REST APIの設計ガイダンス、MCPのトランスポート仕様、MCPの認可仕様に基づいています。ビジネスルールの共通化に関する行は、アーキテクチャ上の推奨事項です。

APIにも、機械が読めるスキーマを用意できます。 OpenAPI Specificationは、人とコンピューターの双方に向けてHTTPインターフェースを記述します。MCPの特徴は、AI連携に共通の実行時インターフェースを提供する点です。パラメーターを記述できること自体は、MCPだけの特性ではありません。

既存のAPIにMCPを追加すると何が変わるか

MCPを使うと、対応する複数のホストでツールインターフェースを再利用できます。 ホストとは、モデルと外部接続を取りまとめるAIアプリケーションです。サービス提供側がサーバーの機能を実装し、ホスト側がMCPクライアントを用意します。

具体的には、次の仕組みが加わります。

• ツールの検出： tools/listで、接続したクライアントに利用可能な操作を伝えます。
• 標準形式のツール定義： 名前、説明、入力用のJSON Schemaを用意します。JSON Schemaは、入力に必要なフィールドとその型を記述します。出力スキーマを宣言することもできます。
• 共通の呼び出し方法： tools/callでツール名と引数を送り、MCPのメッセージ形式で結果を返します。

これらの操作は、ツール仕様で定義されています。たとえば、チケット管理サービスはcreate_ticketを公開し、利用する場面と必要なフィールドを説明できます。ホスト自体にそのチケット管理サービス専用のプラグインを実装しなくても、クライアントは定義を利用できます。

メリットの大きさは、誰が利用するかによって変わります。呼び出し元が自社のバックエンドだけなら、連携の両側をすでに管理できているかもしれません。一方、顧客が複数の対応AIアプリから同じ作業を行いたい場合は、共通プロトコルの価値が高まります。

MCPサーバーはAPIと別にデプロイする必要があるか

MCPを追加しても、必ずしも別のサービスをデプロイする必要はありません。 APIと同じ環境にMCPハンドラーを配置しても、APIを呼ぶ独立したアダプターをデプロイしても、既存のサービス層を直接公開しても構いません。分離の必要性、管理責任、リリース要件に応じて選びます。

stdioでは、クライアントがプロセスを起動し、その標準入力と標準出力を通じてメッセージをやり取りします。Streamable HTTPでは、HTTP経由でMCPエンドポイントに接続します。これらが標準のトランスポート方式です。ネットワーク経由で接続する場合は、実際に利用するクライアントから到達できる必要があります。

図は、APIをラップする構成を示しています。MCP経由でも同じ認可と入力検証を維持できるなら、共通の内部サービスを直接呼び出す設計も有効です。

APIとMCPで、同じチケット作成処理を比べる

どちらのインターフェースから要求しても、作成されるチケットは同じであるべきです。 架空の課題管理サービスで、顧客がプロジェクトEXAMPLEに「Login button fails」というタイトルのチケットを作成したいとします。以下の名前やフィールドは説明用のアプリケーション仕様であり、実在する外部APIの仕様ではありません。

REST API経由で作成する場合

アプリケーションは、認証済みのリクエストとしてPOST /ticketsを送り、JSON本文に{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}を指定します。

APIは呼び出し元を特定し、プロジェクトへのアクセス権を確認し、タイトルを検証してから、チケット作成サービスを呼び出します。そのサービスは、作成したチケットの識別子とステータスを返します。

ここでのrequest_keyは、アプリケーションが定義する冪等性キーです。同じ論理リクエストを同じキーで再試行した場合は、別のチケットを作成せず、最初の結果を返す設計にします。これはこの例で採用した設計方針であり、RESTが自動的に提供する機能ではありません。

MCPサーバー経由で作成する場合

サーバーはcreate_ticketというツールを公開し、たとえば「現在のユーザーがアクセスできるプロジェクトにチケットを作成します」と説明します。inputSchemaでは、文字列型のproject_key、title、request_keyを必須フィールドにします。

ツールの検出後、クライアントはtools/callリクエストを送り、パラメーターに{"name":"create_ticket","arguments":{"project_key":"EXAMPLE","title":"Login button fails","request_key":"demo-ticket"}}を指定します。これは呼び出しのパラメーター部分であり、プロトコルメッセージ全体ではありません。

アダプターは引数を同じチケット作成サービスに渡す形式へ変換するか、既存のPOST /ticketsエンドポイントを呼び出します。そして、ツールの結果としてチケットの識別子とステータスを返します。MCPが標準化するのは検出と呼び出しです。チケット作成という処理の意味は、アプリケーションが定めます。

両方の経路で共通に守るべき権限の境界

アダプターが、プロジェクトの権限チェックを迂回する抜け道になってはいけません。 呼び出し元のユーザーと所属組織は、信頼できる認証コンテキストから特定し、そのうえでプロジェクトへのアクセス権を確認します。モデルが渡したという理由だけで、組織の識別子を信用してはいけません。

同じ意図の操作を再試行するときは、冪等性キーを変えないようにします。モデルが異なるキーで繰り返し送った要求は、自動的に重複と判定されるわけではありません。繰り返される書き込みをどう検出し、確認するかは、アプリケーション側で定める必要があります。

MCPへの対応を明記しているAIクライアントは？

Claude、ChatGPT、Cursor、GitHub Copilotは、いずれもMCPへの対応をドキュメントで明記しています。ただし、接続方法はそれぞれ異なります。 以下は、2026年10月17日時点で各社の公開ドキュメントを確認した内容です。ドキュメント上の対応状況を示すものであり、すべてのサーバー、機能、プロトコルのリビジョンについて、実機で相互運用性を検証した結果ではありません。

Claude

AnthropicのAIアシスタントであるClaudeは、独自のリモートMCPコネクターに対応しています。 コネクターのドキュメントによると、この接続はAnthropicのクラウド基盤から行われます。そのため、自分のノートパソコンからしか到達できないエンドポイントでは、この接続方法を利用できません。誰がコネクターを追加できるかは、組織の管理設定にも左右されます。

ホスト型のプロダクトでは、連携できると約束する前に、サーバーへの到達性と顧客の認証フローを確認してください。デスクトップでローカルサーバーを設定する方法とは、別の仕組みです。

ChatGPT

OpenAIのAIアプリケーションであるChatGPTには、Pluginsを使って独自のMCPサーバーを接続する手順が記載されています。 OpenAIのクイックスタートでは、HTTPSのMCP URLを追加し、認証を設定し、プラグインを作成・インストールしてから、チャット内で呼び出します。独自のビジュアルインターフェースは任意です。

この手順では、ChatGPTからサーバーに到達できる必要があります。開発用の手順でも、サーバーをパブリックインターネットに公開しています。別のクライアントの設定で使うローカル起動コマンドを、そのまま代用することはできません。

Cursor

AIコードエディターのCursorは、stdio、Server-Sent Events（SSE）、Streamable HTTPによる接続をドキュメントに記載しています。 MCPのドキュメントでは、ツールへの対応、mcp.jsonによる設定、必要なサーバーでのOAuth利用を説明しています。SSEは、サーバーからイベントをストリーミングする仕組みです。

そのため、ローカルの開発ツールとホスト型サービスでは、異なる接続経路を選べます。「Cursorで動く」という説明だけで互換性を定義したつもりにならず、対応するトランスポートと認証設定に合わせてデプロイ方法を選んでください。

GitHub Copilot

GitHubのAIコーディングアシスタントであるGitHub Copilotは、複数の利用環境でのMCP対応をドキュメントに記載しています。 対応環境のドキュメントは、統合開発環境（IDE）、コマンドラインインターフェース、Copilotアプリ、クラウドエージェントとコードレビュー向けのリポジトリ設定を扱っています。CLIはローカルとリモートのサーバーに対応しています。個々のエディターでの対応状況は異なり、アクセスが組織のポリシーで管理されることもあります。

特定のエディター上のCopilotなど、サポート対象の利用環境を明示してください。CLIで接続に成功しても、顧客のリポジトリ設定や組織ポリシーが、別の環境で同じサーバーの利用を許可しているとは限りません。

すでに利用できる連携の例は、おすすめのMCPサーバーガイドをご覧ください。ここで判断するのは、自社のプロダクトでもMCPサーバーを公開する必要があるかどうかです。

MCPとAPIはどう使い分けるべきか

顧客がすでに使っているAIクライアントから、具体的な業務を行えるようになるなら、MCPを提供する意味があります。 プロトコルへの期待だけでは、サポート対象のインターフェースを増やす理由として不十分です。

MCPの提供が適している場合：

• 顧客が、既存のMCP対応AIアプリからプロダクト内のレコードを検索したり、範囲を限定した操作を実行したりしたいと求めています。
• 同じ有用な機能を、複数の対応ホストに公開する必要があります。
• 会話の文脈をもとに、アシスタントが説明の明確な操作の中から適切なものを選ぶことが、その業務に役立ちます。
• 対象クライアントのトランスポート、認証、インストール手順に対応でき、障害や変更に責任を持つ担当者を決められます。

APIだけで十分な場合：

• 呼び出し元がアプリケーション、定期実行ジョブ、パートナー連携で、処理の流れがすでに決まっています。
• AIアプリとAPIアダプターを自社で管理しており、外部ホストとの互換性が必要ありません。
• 別のクライアントにツールを公開することで、どの顧客業務が改善するのか、具体的に挙げられません。
• 認可やサービスの挙動がまだ安定していません。新たなインターフェース仕様を追加する前に、既存の動作を安定させます。

両方を提供する場合： 従来のシステム連携が引き続き重要で、顧客が会話形式での利用も求めている場合です。たとえばチケット管理プロダクトなら、Webアプリや自動化向けのAPIを維持しつつ、アシスタントがチケットを検索・作成するためのMCPツールを選んで提供できます。

開発者はサービス層を再利用します。プロダクト責任者は、サポートする業務とクライアントを定めます。運用担当者は、どのユーザーが各操作を行ったかを把握し、アクセスを取り消す方法を確立します。同じ人がすべてを担当する場合でも、これらは別々の責任です。

MCP・API・CLIはそれぞれ何が違うか

同じサービスでも、呼び出し元に応じて異なるインターフェースを提供できます。 コマンドラインインターフェース（CLI）は、人やスクリプトが実行するコマンドを提供します。APIは、アプリケーションコードがプログラムから利用するための仕様を定めます。MCPは、対応するAIホストに共通のツールインターフェースを提供します。

デプロイスクリプトがすでに信頼できるCLIやAPIを使っているなら、MCPを追加しても改善につながるとは限りません。一方、顧客がアシスタント内でチケット操作を使いたい場合は、MCPによってホスト専用の連携を作る必要がなくなる可能性があります。呼び出し元に合うインターフェースを維持してください。略称をそろえるためだけに、正常に動いている自動化を移行する必要はありません。

増えたインターフェースの安全性と保守をどう担保するか

主なトレードオフは、MCPのコードをAPIと同じ環境にデプロイする場合でも、サポートすべき境界が増えることです。 ツールの説明、スキーマ、依存関係、認証の連携、クライアントとの互換性を維持する担当者が必要になります。

認証情報と操作権限を分けて扱う

MCPの認可仕様は、HTTP実装向けにOAuth 2.1ベースの枠組みを定めています。OAuthは、アプリケーションにサービスへの限定的なアクセス権を付与するための枠組みです。プロトコル上、認可への対応は任意ですが、それは非公開のプロダクトデータを無防備にしてよいという推奨ではありません。stdioでの認証情報の扱いは、このHTTP向けの枠組みとは異なります。

アダプターは、MCPサーバーへの受信リクエスト用の認証情報と、背後のサービスへの送信リクエスト用の認証情報の両方を扱う場合があります。トークンがどのサービス向けに発行されたかを示すaudienceを検証し、ユーザーに許可されたスコープを維持してください。セキュリティガイダンスは、別のリソース向けのトークンを無条件に受け入れ、そのまま下流へ渡すことを禁じています。

チケットの例では、広い権限を持つサービス用の認証情報を使うからといって、接続したすべてのユーザーを暗黙にプロジェクト管理者として扱ってはいけません。アダプターが認証情報をどう扱うかにかかわらず、アクセス権の確認は共通の業務処理に残します。

サポートできる業務を単位にツールを設計する

用途と範囲が明確で、役に立つ操作を公開します。 最初はcreate_ticketや範囲を限定した検索から始めてください。任意のURL、メソッド、リクエスト本文を受け付ける、無制限のツールを入り口にするべきではありません。

これはプロダクト設計上の推奨事項であり、プロトコルの制約ではありません。インターフェースを小さく保つほど、説明、認可、障害調査がしやすくなります。ジェネレーターで定義を作れるからといって、内部のエンドポイントをすべてツール一覧へコピーするのは避けてください。

説明には、操作の目的と副作用を明記します。結果を特定できるだけの情報を返しつつ、無関係な機密フィールドは含めません。スキーマが定めるのはデータの形です。要求された操作が許可されているか、適切かを保証するものではありません。

どちらのインターフェースでも障害を追跡できるようにする

ツールの呼び出しから、その背後の処理までを追跡します。 認可を受けたユーザーなどの主体、ツール名、関連するリクエスト識別子、処理結果を記録します。ただし、認証情報や不要な機密データはログに残しません。

入力検証の失敗、権限不足による拒否、レート制限、上流サービスの利用不能を区別してください。書き込みを送信した後でタイムアウトした場合は、共通の処理に定めた再試行ルールに従い、すでに完了していないかを確認してから再試行します。MCPがその業務上の保証を自動的に作ってくれるわけではありません。

ローカルサーバーには、依存関係や実行権限を管理する作業が伴います。ホスト型サーバーには、デプロイや可用性を管理する作業が伴います。どちらを選んでも、保守は必要です。

バージョン管理と制限：プロトコルとツールの互換性を保つ

プロトコルの互換性と、ツールの互換性は別々に管理します。 2026年10月17日の確認時点で、MCPのドキュメントは2026-07-28を現行のプロトコルリビジョンとしています。バージョン管理のドキュメントでは、リクエストごとのバージョン宣言と、ハンドシェイクを使う以前のリビジョンとの互換性を説明しています。

ただし、先に挙げたすべてのクライアントが、このリビジョンを実装していることを意味するわけではありません。サポートされているソフトウェア開発キット（SDK）を選び、対象クライアントが使うリビジョンと機能をテストしてください。

ツールの業務上の仕様は、別の問題です。create_ticketがプロジェクトキーを受け取る仕様から、別の識別子を必須にする仕様へ変わった場合、MCPのリビジョンが同じでも互換性は保たれません。移行期間中は従来の仕様を維持するか、明確に区別できる代替ツールを用意し、ドキュメントと廃止方針を示します。

同様に、結果のサイズ、アクセス可能なデータの範囲、リクエストの実行時間、上流サービスのレート制限は、実際にサポートするサービスとホストに合わせて定めます。プロトコル上の接続に成功しても、巨大なレスポンスがモデルにとって有用だとは限りません。長時間かかる書き込みを安全に再試行できる保証にもなりません。

MCPへの期待で、行き過ぎているのはどこか

MCPは連携方法のばらつきを減らしますが、連携のための作業をなくすわけではありません。 次のような主張は、意味を絞って捉える必要があります。

• 「AIがAPIを呼ぶにはMCPが必要だ」： AIアプリケーションは独自にツールを実装できます。OpenAIの関数呼び出しのドキュメントでも、モデルがツールを要求した後にアプリケーションがコードを実行する仕組みを明示しています。MCPが役立つのは、クライアントとサーバーの共通インターフェースを用意したい場合です。
• 「スキーマがあるから安全に実行できる」： 形式が正しいリクエストでも、アクセスを許可されていないプロジェクトを対象にしたり、意図しない書き込みを実行したりする可能性があります。権限管理と操作の確認は、引き続きアプリケーションの責任です。
• 「MCPがバックエンドを置き換える」： プロトコルは機能を利用するための経路を提供します。チケットの業務ルール、データベース、サービスの信頼性まで提供するわけではありません。
• 「MCPは常にステートフルだ」： RESTとの違いを一律にそう説明すると、現行仕様のリクエスト単位のモデルや、以前の接続単位のセッションの扱いを見落とします。実装するトランスポート仕様のリビジョンを確認してください。

確かなメリットは、もっと控えめで実用的なものです。サービス提供側が背後のサービスを管理し続けながら、顧客は対応ホストから、サポートされたツールインターフェースを再利用できます。

MCPを提供するために、次に何をするか

MCPのツール一覧を作る前に、顧客の業務と対象クライアントを決めてください。 チケット作成への対応を検討するプロダクト責任者なら、まず既存APIの担当開発者と、簡潔な受け入れ確認リストを作るところから始めます。

1. 1

   共通の処理を定義する

   入力、結果、権限の境界、リクエストが重複した場合の挙動を定めます。そのルールは既存のサービスで管理します。

2. 2

   用途を絞ったツールを公開する

   MCPの定義とハンドラーを追加し、クライアントのドキュメントに記載された接続方法を選びます。既存APIは、従来の呼び出し元が引き続き利用できるようにします。

3. 3

   重要な挙動を検証する

   許可されたリクエスト、プロジェクトへのアクセス拒否、繰り返される書き込み、上流へのリクエスト失敗を確認します。どちらのインターフェースでも、業務上の結果が同じになることを確かめます。

実装の詳細は、PythonでMCPサーバーを構築するガイドをご覧ください。最初の業務フローに継続してサポートする価値が認められてから、ツールを増やします。

よくある質問

APIに加えてMCPを使うメリットは何ですか？

標準化され、利用可能なツールを検出できるインターフェースによって、顧客が対応AIアプリケーションからサービスを使えるようになる場合に、MCPが役立ちます。多くの場合、MCPはAPIをラップします。背後のサービスを置き換えるというより、アクセス経路を追加する判断です。

APIとエンドポイントは同じものですか？

違います。APIはインターフェースの仕様であり、エンドポイントはその一部を公開するアドレスです。チケットの例では、APIには操作とデータのルールが含まれ、/ticketsはある操作で使うリソースパスに当たります。IBMのAPI解説も、インターフェースの仕様とリクエスト先のアドレスを区別しています。

APIにはどのような例がありますか？

チケットの作成、注文状況の照会、アカウント情報の検索などが、APIで提供する機能の例です。MCPサーバーは、実装を背後のアプリケーションに残したまま、その中から選んだ機能をツールとして公開できます。

APIとプロキシはどう違いますか？

APIは、ソフトウェアがサービスとやり取りする方法を定めます。プロキシは、リクエストを転送する仲介役です。MCPアダプターはクライアントに代わってAPIを呼び出せますが、それに加えてMCPのツールインターフェースも提供します。HTTPを転送するだけでは、ツールの検出機能は得られません。

APIの4つの種類とは何ですか？

普遍的に定まった4分類があるわけではありません。パブリック、プライベート、パートナーという分類はアクセスする対象者を表し、コンポジットは背後の複数の操作を組み合わせることを表します。IBMのAPIの概要でも、これらを異なる分類軸として扱っています。この分類だけで、HTTP APIにMCPを追加すべきかが決まるわけではありません。

AIを使った開発で実践的な判断をするための情報は、ニュースレターでお届けしています。