MCPとは？ChatGPTやAIエージェントと外部ツールをつなぐ仕組み・できること・危険性を解説

MCPは、ChatGPTなどのAIアプリケーションと、ファイル、データベース、検索サービス、業務システムなどを共通方式で接続するためのオープンな標準です。正式名称はModel Context Protocolです。

MCPを使うと、AIアプリケーションごとに外部サービスとの接続方法を一から作り直す負担を減らせます。一方で、MCPはAIモデルそのものでも、AIエージェントそのものでもありません。AIへ接続手段を与えるプロトコルであり、どの情報を読み、どの操作を許可するかは、アプリケーション側の設計に依存します。

この記事では、2026年7月11日時点のModel Context Protocol公式ドキュメント、OpenAI公式ドキュメント、導入事例、セキュリティ研究を基に、MCPの仕組み、できること、APIやFunction Callingとの違い、導入時の危険性を整理します。

MCPとは

MCPは、AIアプリケーションが外部システムから情報を取得したり、外部の機能を実行したりするための通信規格です。

MCP公式ドキュメントでは、AIアプリケーションを外部システムへ接続するためのオープンソース標準と説明されています。接続対象には、ローカルファイル、データベース、検索エンジン、計算機、業務アプリ、再利用可能なプロンプトなどが含まれます。

MCPはしばしば「AIアプリケーション向けのUSB-C」に例えられます。

USB-Cが、メーカーや機器ごとに異なる接続方法を共通端子へまとめるように、MCPはAIアプリケーションと外部システムの接続方式を共通化します。

ただし、この例えには限界があります。USB-Cへ機器を接続すれば一定の電気的・物理的な動作が期待できますが、MCPでは、接続したツールをAIが正しく選び、適切な引数で呼び出し、安全に結果を利用できるとは限りません。

MCPは接続の規格であり、AIの判断品質や業務ルールまで自動で保証するものではありません。

MCPが解決しようとしている問題

MCPがない場合、AIアプリケーションと各サービスの接続を個別に作る必要があります。

たとえば、3つのAIアプリケーションを、Google Drive、GitHub、社内DB、カレンダーへ接続する場合、それぞれの組み合わせに応じた実装、認証、データ形式、エラー処理が必要になります。

```text AIアプリA ─ Google Drive専用接続 ├ GitHub専用接続 ├ 社内DB専用接続 └ カレンダー専用接続

AIアプリB ─ 同じ接続を別途実装 AIアプリC ─ 同じ接続を別途実装 ```

MCP Serverとして機能を公開すると、MCPに対応した複数のAIアプリケーションから、共通方式で接続しやすくなります。

``text AIアプリA ─┐ AIアプリB ─┼─ MCP ─ Google Drive / GitHub / 社内DB / カレンダー AIアプリC ─┘ ``

実際には、認証、権限、サービス固有の仕様、UI、エラー処理などは残ります。それでも、ツールの発見、入力スキーマ、実行、結果返却といった基本部分を共通化できることがMCPの価値です。

MCP Host・Client・Serverの違い

MCPはクライアント・サーバー型の構成です。中心となるのは、MCP Host、MCP Client、MCP Serverの3つです。

MCP Host

MCP Hostは、ユーザーが操作するAIアプリケーションです。

具体例として、ChatGPT、Claude Desktop、Visual Studio Codeなどが挙げられます。Hostは接続先Serverの管理、利用可能な機能の登録、モデルとの連携、ユーザー承認など、アプリケーション全体を調整します。

MCP Client

MCP Clientは、1つのMCP Serverとの接続を担当するコンポーネントです。

MCP Hostが3つのServerへ接続する場合、通常はServerごとに専用のClient接続を持ちます。Clientは初期化、対応機能の確認、ツール一覧の取得、ツール呼び出し、通知の受信などを担当します。

MCP Clientが単独で業務判断を行うとは限りません。どのツールをモデルへ提示し、いつ呼び出すかは、Host、モデル、ワークフローの設計によって決まります。

MCP Server

MCP Serverは、AIアプリケーションへ利用可能な情報や機能を公開するプログラムです。

たとえば、GitHub用のMCP Serverなら、リポジトリ検索、Issue取得、Pull Request確認などのToolsを公開できます。社内DB用のServerなら、許可されたテーブルの検索や集計を提供できます。

Serverが外部APIを代理で呼び出す構成もあります。

``text AIアプリケーション ↓ MCP MCP Server ↓ REST API / GraphQL / SQL 外部サービス・社内システム ``

このため、MCPとAPIは競合する技術ではありません。MCP Serverの内部で既存APIを利用する構成が一般的です。

MCPのデータ層とトランスポート層

MCP公式アーキテクチャでは、MCPは大きくデータ層とトランスポート層に分けられます。

データ層

データ層は、ClientとServerが何をどの形式で交換するかを定義します。

MCPはJSON-RPC 2.0を基礎に、次のような処理を定めています。

• 接続開始時の初期化
• プロトコルバージョンの確認
• 対応機能の交渉
• Tools・Resources・Promptsの一覧取得
• Toolの実行
• Resourceの取得
• 通知
• エラー応答

MCPは状態を持つプロトコルであり、接続開始時にClientとServerが対応機能を確認します。利用できない機能を誤って呼ばないために、この能力交渉が重要です。

トランスポート層

トランスポート層は、ClientとServerの通信経路を担当します。

公式ドキュメントでは、主に次の2方式が説明されています。

ローカルServerだから安全、リモートServerだから危険という単純な区別はできません。ローカルServerはユーザー端末上でプログラムとして動くため、ファイルやコマンドへ強い権限を持つ場合があります。リモートServerは外部へデータを送信するため、運営者の信頼性やデータ保持方針が重要です。

Tools・Resources・Promptsとは

MCP Serverが公開する中心的な機能は、Tools、Resources、Promptsです。

Tools

Toolsは、AIアプリケーションが呼び出せる実行可能な機能です。

例として、次のような処理があります。

• ファイルを作成する
• データベースを検索する
• メールを送信する
• カレンダーへ予定を登録する
• GitHub Issueを作成する
• 商品在庫を確認する
• 計算を実行する

Toolには、名前、説明、入力スキーマなどが定義されます。AIモデルはこの説明を参考に、どのToolを使うか判断します。

Toolの説明が曖昧だったり、似た機能が大量に公開されていたりすると、モデルが誤ったToolを選ぶ可能性があります。2026年に公開された856ツールを対象とする研究では、分析対象の97.1%に少なくとも1つの説明上の問題があり、56%は目的を明確に説明できていなかったと報告されています。

Resources

Resourcesは、AIアプリケーションが参照するデータです。

• ファイルの内容
• データベースレコード
• APIレスポンス
• 設定情報
• ドキュメント
• スキーマ情報

Toolが「操作」であるのに対し、Resourceは「参照する情報」と考えると分かりやすいでしょう。

ただし、Resourceを読み取るだけでも情報漏えいは起こり得ます。読み取り専用であっても、機密情報や個人情報へのアクセス範囲は制限する必要があります。

Prompts

Promptsは、再利用可能な入力テンプレートです。

たとえば、次のようなテンプレートをServer側から公開できます。

• コードレビュー用の手順
• 障害調査用の質問項目
• 会議要約の出力形式
• データ分析の定型指示
• Few-shot例を含む業務プロンプト

Promptsは、ToolやResourceとは異なり、モデルとの対話を一定の形式へ導くために使われます。

MCPはどのように動く？

MCPを使ったTool実行は、概ね次の流れです。

1. MCP HostがServerへの接続を開始する
2. ClientとServerがバージョンと対応機能を確認する
3. Clientがtools/listなどで利用可能な機能を取得する
4. HostがTool定義をモデルへ提示する
5. モデルがユーザーの依頼に必要なToolを選ぶ
6. HostまたはAPIが実行前承認を確認する
7. Clientがtools/callをServerへ送る
8. Serverが処理を実行して結果を返す
9. 結果がモデルのコンテキストへ追加される
10. モデルが回答するか、次のToolを選ぶ

重要なのは、MCP Serverがモデルへ直接命令するわけではないことです。Host側がServerからTool定義や結果を受け取り、モデルの処理へ組み込みます。

ただし、Toolの説明や返却結果に悪意ある指示が含まれていると、モデルの判断へ影響する可能性があります。そのため、MCP Serverから届く情報も信頼済みの命令ではなく、検証対象の外部データとして扱う必要があります。

ローカルMCP ServerとリモートMCP Server

ローカルMCP Server

ローカルMCP Serverは、ユーザーのPCなど、MCP Hostと同じ端末上で動きます。stdioを使う構成が代表的です。

利点は、外部ネットワークへ公開せずにローカルファイルや開発環境へ接続しやすいことです。

一方で、ローカルServerは通常のプログラムとして端末上で実行されます。悪意あるServerや設定コマンドを実行すると、次の被害が起こり得ます。

• ファイルの読み取りや削除
• SSH鍵や環境変数の窃取
• 任意コマンドの実行
• 外部へのデータ送信
• マルウェアのインストール
• クライアントと同等権限での操作

MCP公式セキュリティガイドは、ローカルServerの導入前に実行コマンドを省略せず表示し、明示的な承認を取り、最小権限のサンドボックスで実行することを推奨しています。

リモートMCP Server

リモートMCP Serverは、インターネットや社内ネットワーク上で動きます。Streamable HTTPを使う構成が代表的です。

複数ユーザーから利用しやすく、サービス提供者が更新や運用を管理できる利点があります。

一方で、AIアプリケーションからServerへデータが送られます。OpenAIは、remote MCP serverはOpenAIが検証したものではなく、接続先ごとの利用規約やデータ保持方針が適用されると説明しています。

• 何のデータを送信するか
• Server運営者は誰か
• データはどこに保存されるか
• 何日保持されるか
• 他用途へ利用されるか
• 削除要求に対応するか
• 認証情報をどう管理するか

これらを確認せずに接続すべきではありません。

MCPとFunction Callingの違い

Function Callingは、モデルが「どの関数を、どの引数で使いたいか」を構造化してアプリケーションへ伝える仕組みです。

MCPは、外部の機能やデータをどのように公開し、発見し、呼び出すかを標準化するプロトコルです。

MCP Serverから取得したTool定義をモデルへ提示し、モデルがFunction Callingと同様にToolを選ぶ構成があります。したがって、両者は排他的ではなく、組み合わせて使われます。

MCPとAPIの違い

APIは、ソフトウェア同士が機能やデータを利用するための接続仕様です。

MCPも広い意味ではソフトウェア間通信ですが、AIアプリケーションがToolやResourceを発見し、モデルへ提示しやすい形で共通化している点が特徴です。

MCPは既存APIを置き換えるものではありません。MCP Serverが、既存APIの機能をAI向けToolとして公開する形が現実的です。

MCPとコネクターの違い

OpenAIのResponses APIでは、remote MCP serverに加えて、OpenAIが管理する一部サービス向けコネクターを利用できます。

コネクターも内部的にはMCP形式で扱われますが、Server URLを指定する代わりに、Google Drive、Gmail、Dropboxなどのconnector_idを指定します。

一方、remote MCP serverは、公開インターネット上でMCPを実装する任意のServerへ接続する仕組みです。

コネクターだから無条件に安全という意味ではありません。第三者サービスのデータをOpenAIへ送る可能性や、モデルが機密情報を読み取る可能性は残ります。

MCPでできること

文書・ファイル検索

Google Drive、Notion、社内ファイル、ローカルディレクトリなどから必要な情報を取得できます。

ソフトウェア開発

GitHub、エラー監視、リポジトリ、CI/CD、データベースへ接続し、調査、Issue作成、テスト、変更確認などを支援できます。

事務作業

カレンダー確認、予定登録、メール下書き、顧客情報検索、申請内容の整理などへ利用できます。

データ分析

データベースや統計データへ接続し、自然言語の依頼から検索、集計、分析を行えます。

ニュース・調査

Reutersは2026年7月8日、契約者がAIエージェントからReutersのニュースコンテンツを検索、取得、ダウンロードできるMCP Serverを発表しました。これは、MCPが開発ツールだけでなく、専門コンテンツの配信基盤としても利用され始めている事例です。

物理機器や制作ツールの操作

設計次第では、Blenderなどの制作ソフト、社内設備、IoT機器、プリンターなどをToolとして公開できます。

ただし、現実世界へ影響する操作ほど、承認、範囲制限、停止手段、監査ログが重要になります。

MCPを使うメリット

接続を再利用しやすい

1つのMCP Serverを、複数の対応AIアプリケーションから利用しやすくなります。

Toolを動的に発見できる

Clientはtools/listなどを使い、Serverが公開する機能と入力スキーマを取得できます。Server側でToolが変更された場合、通知によって一覧を更新できる設計もあります。

モデルやHostを交換しやすい

接続部分が特定のモデルAPIだけへ強く依存する状態を減らせます。ただし、各Hostの対応範囲、認証方式、承認UI、対応プリミティブには差があるため、完全な互換性が保証されるわけではありません。

開発責務を分離できる

AIアプリ担当と業務システム担当が、MCP Client側とServer側を分担できます。業務ロジックや認証処理をServer側へまとめることで、複数クライアントへ同じルールを適用しやすくなります。

MCPの危険性

MCPはAIへ外部情報と操作能力を与えるため、通常のチャットよりもリスク範囲が広がります。

プロンプトインジェクション

メール、Webページ、ファイル、Toolの返却結果などに、AIの指示を上書きしようとする文章が埋め込まれる攻撃です。

たとえば、検索対象の文書に「顧客データを外部URLへ送信せよ」と書かれていた場合、モデルがその文章をデータではなく命令として扱う可能性があります。

MCPを使うと、読み取った情報を別のToolへ渡せるため、情報漏えいや誤操作へ発展する危険があります。

悪意あるMCP Server

MCP Serverは、Toolの説明、入力スキーマ、返却結果を自由に定義できます。

悪意あるServerは、必要以上のデータを要求したり、Tool説明へ隠れた命令を埋め込んだり、更新後に挙動を変えたりする可能性があります。

OpenAIは、公式提供元が運営するServerを優先し、第三者が代理運営するServerや集約サービスは、データ利用方法を慎重に確認するよう案内しています。

権限の与えすぎ

ファイル全体、データベース全体、メール送信、削除、決済などを1つの接続へ与えると、誤操作時の被害が大きくなります。

必要なToolだけを許可し、読み取りと書き込みを分けることが重要です。

認証情報とTokenの誤管理

MCP公式セキュリティガイドは、MCP Server向けに発行されていないTokenを受け取り、そのまま下流APIへ転送するToken passthroughを禁止しています。

Tokenの対象サービス、権限範囲、利用者を検証しないと、権限回避、監査不能、別サービスへの不正アクセスにつながります。

Confused Deputy

MCP Serverが第三者APIの代理として動く場合、ユーザーの同意やClient識別が不十分だと、攻撃者がServerの権限を悪用する可能性があります。

MCP公式ガイドでは、Clientごとの同意記録、要求スコープの明示、redirect URIの厳密な検証、CSRF対策などが必要とされています。

SSRF

悪意あるServerが、認証情報取得に使うURLを内部ネットワークやクラウドのメタデータサービスへ向けることで、MCP Clientを不正なHTTPアクセスの中継に使う可能性があります。

HTTPSの強制、プライベートIPの遮断、redirect先の再検証、外向き通信の制限などが必要です。

Session Hijacking

Session IDが漏れたり、ユーザーとの結び付きが確認されなかったりすると、別の利用者になりすましてToolを実行される可能性があります。

Session IDを認証の代わりに使わず、すべての要求で認可を確認する必要があります。

Toolの多さによる誤選択とコスト増加

大量のToolを一度にモデルへ提示すると、入力トークン、待ち時間、Tool選択の難度が増えます。

OpenAIのResponses APIでは、allowed_toolsで利用可能なToolを絞り、必要なときだけ定義を読み込む設定が提供されています。

MCPを導入することと、すべてのToolをモデルへ公開することは別です。

MCPを安全に使うためのチェックリスト

1. 公式提供元のServerを優先する

対象サービス自身が運営するServerを優先します。非公式Serverを使う場合は、ソースコード、運営者、更新履歴、依存パッケージ、データ保持方針を確認します。

2. 必要なToolだけを公開する

利用しないToolをモデルへ提示しません。OpenAI APIではallowed_toolsを使って接続先ServerのToolを絞れます。

3. 最小権限にする

ファイルは対象ディレクトリだけ、DBは対象テーブルだけ、メールは下書きだけなど、業務に必要な最小範囲へ制限します。

4. 読み取りと書き込みを分ける

検索用Toolと更新用Toolを分離します。読み取り処理が必要なだけのAgentへ、削除や送信権限を与えないようにします。

5. 重要操作には承認を入れる

次の操作は原則として実行前確認を残します。

• メール・メッセージ送信
• ファイルやレコードの削除
• 上書き更新
• 決済・返金・購入
• 外部公開
• 権限変更
• 機密情報の外部送信

OpenAIのremote MCP toolは、初期状態では各Tool呼び出しに承認を求めます。信頼性を確認する前に承認を無効化すべきではありません。

6. 送信データを記録する

どのServerへ、どのデータを送信したかをログへ残します。Tool名だけでなく、引数、対象ID、承認者、返却結果、エラーも追跡できるようにします。

7. URLを検証する

Serverが返すURLを、そのままブラウザで開いたり画像として埋め込んだりしません。許可ドメイン、URL scheme、redirect先、プライベートIPへの解決を検証します。

8. ローカルServerをサンドボックス化する

ローカルServerは、コンテナやOSのサンドボックスを利用し、ファイル、ネットワーク、プロセス実行権限を限定します。インストールコマンドを省略せず表示し、利用者の承認を得ます。

9. 実行上限を設定する

最大Tool呼び出し回数、タイムアウト、再試行回数、トークン、料金へ上限を設定します。

10. 定期的にTool定義を再確認する

Server側の更新によって、Tool説明や挙動が変わる可能性があります。初回接続時だけでなく、更新後も差分と権限を確認します。

MCPは誰に必要？

一般のChatGPT利用者

MCP Serverを自作する必要はありません。重要なのは、接続するサービスの提供元、要求権限、送信される情報、実行前確認を理解することです。

「便利そうだから接続する」のではなく、その接続がメール送信やファイル削除まで可能なのかを確認してください。

エンジニア

複数のAIクライアントから同じ業務機能を利用させたい場合、MCPは有力です。

一方、1つのアプリ内で少数の関数を呼ぶだけなら、独自のFunction Callingの方が構成を単純に保てる場合があります。

企業のIT担当者

社内文書、データベース、SaaSへAIを接続する際、接続の標準化とガバナンスに利用できます。

ただし、Serverごとの認証を増やすだけでは管理できません。利用者、Tool、対象データ、承認、ログを一元的に管理する必要があります。

SaaS・コンテンツ提供者

自社のサービスやデータを、複数のAIアプリケーションから利用できる形で提供したい場合にMCP Serverを検討できます。

Reutersの事例のように、従来の検索画面やAPIに加えて、AIエージェントが必要な情報を発見・取得する入口としてMCPを提供する動きもあります。

MCPを使わない方がよい場合

次のような場合は、MCPを導入しない方が単純です。

• 1つのアプリ内で1〜2個の固定関数しか使わない
• 外部クライアントから再利用する予定がない
• Serverの運用・認証・監査を用意できない
• モデルがToolを選ぶ必要がなく、処理順序が完全に固定されている
• 既存APIだけで目的を十分に達成できる
• 機密性が高く、外部AIへ情報を渡せない

MCPを採用すること自体が目的になってはいけません。接続を複数クライアントで再利用する価値があるか、安全に運用できるかで判断します。

MCP導入の進め方

ステップ1：利用目的を1つに絞る

「社内データを全部使えるようにする」ではなく、「製品マニュアルを検索する」「GitHub Issueを読み取る」など、対象業務を限定します。

ステップ2：Tool・Resource・Promptを分ける

実行する処理、参照するデータ、定型の対話テンプレートを分類します。

ステップ3：権限範囲を決める

誰が、どのデータへ、どのToolでアクセスできるかを定義します。Serverへ接続できることと、すべての利用者が同じ権限を持つことは別です。

ステップ4：読み取り専用で検証する

最初はResource取得や検索Toolだけを提供し、モデルが正しい情報とToolを選べるか評価します。

ステップ5：承認付きで書き込みを追加する

検索精度、Tool選択、引数、情報漏えいを確認したあと、更新や送信を承認付きで追加します。

ステップ6：監査と評価を継続する

成功率だけでなく、誤ったTool選択、不要なデータ送信、承認拒否、失敗理由、コスト、処理時間を確認します。

よくある誤解

MCPを使えばAIが賢くなる？

MCPはモデルの知能を直接向上させません。利用できる情報と機能を増やします。増えた機能を正しく選べるかは、モデル性能、Tool説明、アプリケーション設計に依存します。

MCP Serverへ接続すれば自動でAIエージェントになる？

なりません。MCPは接続プロトコルです。目標管理、実行ループ、状態保持、失敗時の再試行、承認などは別途必要です。

MCPはAPIを置き換える？

置き換えません。MCP Serverが既存APIを呼び、AI向けのToolとして公開する構成が一般的です。

ローカルMCP Serverなら安全？

安全とは限りません。ローカルServerは端末上でコードを実行するため、強い権限を持つ可能性があります。入手元、実行コマンド、ファイルアクセス、ネットワーク通信を確認する必要があります。

読み取り専用なら情報漏えいは起きない？

起こり得ます。読み取った機密情報を、別のToolやリモートServerへ送信する可能性があります。読み取り権限も最小化する必要があります。

まとめ

MCPは、AIアプリケーションと外部のデータ、ツール、プロンプトを共通方式で接続するためのプロトコルです。

MCP Hostがアプリケーション全体を管理し、ServerごとのMCP Clientが接続を維持し、MCP ServerがTools、Resources、Promptsを公開します。通信にはJSON-RPC 2.0が使われ、ローカル接続ではstdio、リモート接続ではStreamable HTTPが代表的です。

MCPの価値は、AIモデルを直接賢くすることではありません。外部システムとの接続を再利用しやすくし、AIが利用できる情報と機能を増やすことです。

一方で、外部へ接続できる範囲が増えるほど、プロンプトインジェクション、悪意あるServer、情報漏えい、認証情報の誤管理、誤操作、コスト増加などの影響も大きくなります。

導入時は、公式Server、最小権限、Toolの絞り込み、実行前承認、URL検証、ログ、サンドボックス、実行上限を組み合わせる必要があります。

MCPを使うかどうかは、流行しているかではなく、複数のAIクライアントから接続を再利用する価値があるか、安全に運用できるかで判断することが重要です。