MCPとは?AIと外部ツールをつなぐ「共通規格」をわかりやすく解説
AIに「このリポジトリのIssueを確認して」「社内ドキュメントを探して」と頼んだとき、AIが自分で情報を取りに行けたら仕事は変わると思いませんか? MCPは、AIと外部のデータ・ツールをつなぐための共通規格です。
ただしMCPは、AIを賢くする技術ではなく、AIが外部機能を「使う仕組み」を標準化したものです。便利な反面、ファイル更新やSaaS操作まで実行可能になるため、事前に権限と費用の設計が必要です。
本記事では、MCPの仕組み、API・RAGとの違い、実務での使いどころ、安全に始める手順を整理します。自分の業務で使う意味があるか判断できるようになります。
> 本記事は2026年8月29日時点で確認した情報をもとにしています。MCPは仕様・対応ホストとも更新が速いため、実装や接続設定は利用時点の公式ドキュメントを確認してください。
MCPとは?AIが外部の道具を使うための共通規格
MCP(Model Context Protocol)は、AIアプリケーションが外部のデータやツールを扱うためのオープンプロトコルです。AIごと・サービスごとに連携方式を作り込む代わりに、共通の形式で機能を公開・接続できます。
たとえばAIに、次のような仕事をさせる場面を考えてみます。
- ローカルのファイルやソースコードを読む
- 社内ドキュメント、データベース、GitHubを検索する
- Issueやタスクを作成する
- 承認を得たうえでファイルや業務データを更新する
こうした情報や操作は、通常はAIの外にあります。MCPは、外部システム側が提供する機能をAIが見つけて使うための共通の窓口です。
「AI用のUSB規格」と考えるとイメージしやすいかもしれません。USBが共通だから周辺機器をPCごとに専用接続しなくてよいように、MCPは対応ホストと対応サーバーの組み合わせを増やしやすくします。ただしUSBと同じく、差し込めることと安全に使えることは別の話です。
MCPはJSON-RPC 2.0を使うプロトコルで、AIアプリと外部の機能を標準化して接続します。公式仕様では、文脈情報の共有、ツール機能の公開、再利用可能な連携ワークフローを主な目的として示しています。 MCP Specification
MCPの仕組み:ホスト・クライアント・サーバーの役割
MCPは、AIを動かすホスト、接続を担当するクライアント、機能を提供するサーバーに分かれます。使う側は「AIアプリがホスト、つなぐ機能がサーバー」と押さえれば十分です。
クライアントはサーバーごとに分かれる(1対1)
MCPホスト:AIを使うアプリケーション
ホストは、AIとの対話画面やコーディングエージェントなど、利用者が直接使うアプリケーションです。サーバーへの接続、権限、利用者の承認、AIへ渡す文脈を管理します。
MCPクライアント:サーバーごとの接続担当
クライアントはホストの内部で動き、1つのMCPサーバーとの接続を維持します。接続を分ける設計のため、あるサーバーが会話全体や別サーバーの情報を自由に見られるわけではありません。 MCP Architecture
MCPサーバー:AIに渡す機能の提供者
MCPサーバーは、外部のデータや操作をMCP形式で公開します。サーバーはローカルで起動することも、ネットワーク越しに接続することもあります。
ここは混同しやすいところです。MCPは規格、MCPサーバーはその規格で機能を公開する実装です。GitHubやデータベースのAPIそのものがMCPになるわけではなく、既存APIを内部で呼ぶMCPサーバーを作ることもあります。
Tools・Resources・PromptsでAIに何を渡せるのか
MCPサーバーは、主に「実行する」「参照する」「定型作業を呼び出す」という3種類の機能を公開できます。どこまでをAI任せにするかは、この違いから決めるとぶれません。
| 種類 | 役割 | 例 | 主なコントロール主体 |
|---|---|---|---|
| Tools | AIが実行する関数 | Issue作成、検索、ファイル更新 | モデル |
| Resources | AIが参照する文脈・データ | ファイル本文、Git履歴、DBのレコード | アプリケーション |
| Prompts | 再利用する指示テンプレート | レビュー用の定型指示、調査の手順 | 利用者 |
Toolsだけが「実際の操作」で、AIが文脈に応じて発見し、呼び出す設計ができます。 MCP Server Features
この違いは導入設計で効きます。たとえば社内規程を参照させるだけなら、最初はResourcesや読み取り専用の検索Toolで足ります。いきなり「申請を送信するTool」まで公開する必要はありません。
MCP・API・RAG・AIエージェントの違い
MCP、API、RAG、AIエージェントは競合する言葉ではなく、担当する層が違います。
| 用語 | 主な役割 | 具体例 |
|---|---|---|
| API | システム同士がデータや機能をやり取りする窓口 | GitHub APIでIssueを作る |
| MCP | AIが外部の機能・文脈を扱う接続規約 | GitHub APIを呼ぶToolをAIへ公開する |
| RAG | 関連情報を検索してモデルに渡す手法 | 規程を検索して回答の根拠にする |
| AIエージェント | 目的に応じて情報収集・判断・実行を進める仕組み | Issueを読み、修正し、テスト結果を報告する |
APIはMCPの代わりではない
APIを1本呼ぶだけの処理なら、MCPを追加しない方が単純です。むしろMCPサーバーが、内部で既存APIを使う構成はよくあります。
複数のAIアプリで同じ機能を使いたい、AIにツールの選択も任せたい、といった要件が出たときにMCPの価値が出ます。
RAGはMCPの一部ではない
MCPはRAGそのものではありませんが、検索や文書取得の機能をMCPのToolやResourceとしてつなぐことはできます。
「正しい社内情報を答えに使わせたい」が主目的なら、先に検索品質、アクセス範囲、更新方法を設計するのが先です。MCPを入れただけで情報の鮮度や回答精度が上がるわけではありません。
AIエージェントはMCPそのものではない
MCPはエージェントに手足を渡す接続方法、と捉えると分かりやすいです。MCPだけでは、計画・再試行・完了判定まで自動で設計されるわけではありません。
MCPでできること:読む仕事から、承認付きの操作まで
MCPの価値は、チャットの回答に外部の現実をつなげられることです。最初は読み取り中心で始め、確認方法を固めてから書き込み操作へ広げるのが現実的です。
1. AIが知らない情報を読ませる
ローカルのプロジェクト、社内ドキュメント、データベース、SaaSの記録など、モデルがあらかじめ持っていない情報を参照させます。
たとえば「この障害の過去事例を調べて、対応案を箇条書きにして」と依頼したとき、AIがナレッジベースを検索し、該当する内容を踏まえて回答する使い方です。ここでは、AIの文章力よりも、どのデータを見せるかが品質を左右します。
2. AIに外部サービスを操作させる
Toolとして公開すれば、AIはIssue作成、データ取得、ファイル更新、社内システムへの登録といった操作を実行できます。ツールはモデルが自動的に選んで呼び出せますが、公式仕様でも利用者が拒否できる人間の介在を推奨しています。 MCP Tools
「メールを送る」「本番データを更新する」のような取り消しにくい操作は、AIの提案と実行を分けるのが無難です。提案内容、対象、差分を確認してから人が承認する形にしておくと、事故が起きても原因を追えます。
3. 複数のツールをまたぐ作業を進める
たとえば、バグ報告から修正候補を作る流れなら、AIは次のように複数の機能を使えます。
1. Issueを検索して再現条件を確認する
2. リポジトリから関連コードとテストを探す
3. 修正案を作り、テストを実行する
4. 結果を人に提示し、承認後にPRやIssueへ反映する
MCPがあっても、この流れが必ず正しく動くわけではありません。どのToolを使えるようにするか、どの段階で止めるか、失敗時に何を報告させるかはホスト・アプリ側の設計です。
MCPを使うべきケース・使わなくてもよいケース
MCPは「AI連携の標準化」が必要なときに効きます。
| 判断 | MCPが向く | MCPを急がなくてよい |
|---|---|---|
| 接続先 | 複数のSaaS・データソースを扱う | APIを1本呼べば足りる |
| 利用者 | 複数のAIアプリ・チームで再利用したい | 1つの専用アプリだけで閉じる |
| 操作 | AIが状況に応じて検索・実行を選ぶ | 実行手順が固定されている |
| 実装 | 既存の信頼できるMCPサーバーを使える | MCP化の運用負担が大きい |
| 権限 | 最小権限・承認・監査を設計できる | 権限の分離やログが用意できない |
本命は、普段の仕事で何度も発生する「探す」「照合する」「下書きを作る」をつなぐ用途です。そこから始めると、便利さとリスクの両方を小さく検証できます。
安全に始めるための5つのルール
MCPの危険性はプロトコル名そのものではなく、AIに渡すデータと操作権限にあります。提供元、最小権限、承認、利用上限、ログの5点を決めてから接続すれば、便利さだけを追って事故る確率を下げられます。
1. 信頼できる提供元か確認する
見つけたMCPサーバーをそのまま実行しないでください。誰が保守しているか、ソースコードや配布元は妥当か、何へ接続するかを確認します。特にローカル実行型のサーバーは、ファイルや環境変数に触れられる場合があります。
2. 最初は読み取り専用にする
導入初期は、検索、ファイル閲覧、データ取得に限定します。書き込み、削除、外部送信、本番環境操作は、用途と影響範囲が見えてから追加する方が安全です。
3. 実行前に人が止められるようにする
Toolの内容、対象、引数、実行結果を利用者が確認できるUI・ログを用意します。MCPの仕様も、データアクセスとツール実行には明示的な利用者の同意と制御が必要だとしています。 MCP Specification: Security and Trust & Safety
4. 従量課金の上限を決める
外部APIやSaaSの利用量は、Tool呼び出しに応じて増えます。MCPの仕様が料金を管理してくれるわけではありません。回数・予算・実行時間の上限をアプリ側やサービス側で設定し、処理後に呼び出し回数と概算費用を確認できるようにします。
5. 認証情報とログを分けて管理する
リモートMCPサーバーでは、認可フローやトークンの扱いも重要です。HTTPベースの認可ではOAuth 2.1などの安全な運用が求められ、トークンを別サービスへそのまま渡すことは禁じられています。秘密情報をプロンプトやソースコードに直書きせず、接続先ごとに権限を分け、実行履歴を残しましょう。 MCP Authorization
MCPを試すなら、最初のテーマは小さくする
最初のMCP導入は、読み取り専用の情報源を一つつなぎ、AIがどの情報を見たか確認できる状態にするのが近道です。いきなり自作サーバーや書き込み自動化から始めるより、失敗の原因を切り分けやすくなります。
- AIアプリのMCP対応を確認公式ドキュメントで確認する
- つなぐ情報を一つ選ぶ毎回探している情報が候補
- 信頼できるMCPサーバーを選ぶ読み取り専用で公開されるもの
- 接続先・要求権限を確認外部送信されるデータも見る
- 少数のタスクで試す実行ログと費用を見ながら
- 限定的な書き込みを追加承認ステップとセットで
OpenAIのResponses APIでも、カスタムMCPサーバーや事前定義コネクタをMCP Toolsとして扱えます。とはいえ、使える機能や認証方法はホストによって異なります。導入時は利用する製品の最新ドキュメントを基準にしてください。 OpenAI API Reference: MCP Tools
まとめ:MCPは「AIに道具を持たせる」ための接続規約
MCPは、AIアプリと外部ツール・データをつなぐ共通規格です。APIの代替でもRAGそのものでもなく、AIが必要な情報を読み、必要な操作を行うための接続層に当たります。
導入判断で見るべきなのは、流行ではなく次の3点です。
- 複数のAIアプリやツールで連携を再利用したいか
- AIに「読む」以外の操作まで任せる必要があるか
- 最小権限、承認、費用上限、ログを用意できるか
まずは、毎回探している情報を一つだけ、読み取り専用でAIにつなぐところから始めるのが無難です。そこで効果とリスクの両方を把握してから、書き込み操作や複数ツールの連携へ広げていきましょう。