MCPは Model Context Protocol の略です。AIエージェントが外部ツールやデータに接続するための標準的な仕組みとして、開発者の間で急速に注目されています。
よく「AI版のUSB-C」と説明されます。この比喩は便利ですが、本質はもう少し実務的です。
MCPは、AIアプリケーションが外部システムからコンテキストを読み取り、必要に応じてアクションを依頼するための共通言語です。
Claude、Cursor、社内チャットボット、ワークフローエージェントのために、それぞれ別々の連携を作るのではなく、一つのMCPサーバーとして公開できる。ここに価値があります。
MCPでできること
MCPがAIに渡すものは、大きく三つに分けられます。
| 種類 | AIに渡せるもの | 例 |
|---|---|---|
| Tools | AIが依頼できる操作 | GitHub Issue作成、CRM検索、社内API実行 |
| Resources | AIが読める情報 | ファイル、DBレコード、ドキュメント、ログ |
| Prompts | 再利用できるタスクテンプレート | PRレビュー、顧客情報の要約、調査手順 |
基本構成は次の通りです。
| 要素 | 役割 |
|---|---|
| MCP Host | ユーザーが触るAIアプリ。Claude DesktopやCursorなど |
| MCP Client | Hostの中でMCPサーバーと通信する部分 |
| MCP Server | ツール、リソース、プロンプトを公開するサービス |
MCPサーバーは、ローカルファイル、GitHub、Slack、Notion、Postgres、ブラウザ、社内API、ナレッジベースなどを包むことができます。
なぜMCPが重要になったのか
以前のAIツールは、ほとんどがチャット画面の中で完結していました。モデルの学習済み知識か、ユーザーが貼り付けた文章をもとに回答する形です。
しかし実務でAIを使うと、すぐに限界が来ます。
- プロジェクトのファイルを読む
- 社内ドキュメントを検索する
- チケットを更新する
- データベースの内容を確認する
- 社内APIを呼び出す
- 複数ツールをまたいで作業する
MCPがない場合、各AIアプリがそれぞれ独自に連携機能を作る必要があります。これは開発コストも高く、権限管理もばらつきやすくなります。
MCPは、この接続境界を明確にします。AIクライアントはすべてのツールの細部を知る必要がありません。プロトコルを通じて、使える機能を発見し、必要な範囲で呼び出します。
MCPとFunction Callingの違い
MCPとFunction Callingは似ていますが、同じものではありません。
Function Callingは、多くの場合一つのアプリや一つのモデル利用の中で定義される機能です。開発者が関数を用意し、モデルが必要な関数を選び、アプリ側が実行します。
MCPはより広い接続層です。ツールを再利用可能なサーバーとして公開し、複数のAIクライアントから使えるようにする考え方です。
| 観点 | Function Calling | MCP |
|---|---|---|
| 単位 | アプリ内の関数 | 再利用可能なサーバー |
| 移植性 | 特定の製品やコードに依存しやすい | 対応クライアント間で共有しやすい |
| コンテキスト | アプリ開発者が定義 | Tools、Resources、Promptsとして公開 |
| 向いている用途 | 固定された製品機能 | 開発環境、企業業務、AIエージェント基盤 |
実際には両方を使うケースもあります。製品内部ではFunction Callingを使い、外部ツール連携にはMCPを使う、という構成です。
MCPを使うべきケース
MCPが有効なのは、AIが継続的に外部コンテキストへアクセスする必要がある場合です。
向いている例：
- コーディングエージェントがリポジトリ、Issue、Pull Requestを扱う
- サポートエージェントが顧客データと会話履歴を確認する
- 調査アシスタントが文書検索を行い、根拠を引用する
- 社内オペレーションBotが承認済みワークフローを実行する
逆に、次のような用途ではMCPは必須ではありません。
- 一回限りの文章生成
- 小さな実験
- 一つのアプリ内に隠れた単純なAPI呼び出し
- 再利用する必要がない連携
MCPは魔法のエージェントフレームワークではありません。解決するのは接続の問題です。判断、権限、ログ、評価、人間の確認は別途設計する必要があります。
開発者にとってのメリット
開発者にとって、MCPは連携の形を変えます。
MCPがない場合：
Client A -> GitHub連携
Client B -> GitHub連携
Client C -> GitHub連携MCPがある場合：
Claude / Cursor / 社内エージェント -> GitHub MCP Serverすべての開発が消えるわけではありません。ただし、同じような連携コードを何度も書く必要は減ります。さらに、ツールの挙動を一箇所でテストし、監査しやすくなります。
企業導入で重要になる理由
企業AIで難しいのは、デモではありません。
難しいのは、AIにどのシステムを読ませるか、どの操作を許すか、どの操作を記録するか、誰が承認するかです。
MCPはこの設計を少し明確にします。
- どのツールを使えるのか
- どのリソースを読めるのか
- どのプロンプトが承認済みなのか
- どの操作に確認が必要なのか
- どのMCPサーバーを本番で許可するのか
もちろん、MCPを入れただけで安全になるわけではありません。ただし、AIが触れる能力を見える形にしやすくなります。
よくある誤解
MCPはエージェントを賢くするものではない
MCPはモデルにツールとコンテキストを渡します。しかし、そのタスクを任せてよいかどうかまでは判断しません。
モデルは依然として誤解します。間違ったツールを選ぶこともあります。
MCPはClaude専用ではない
MCPはAnthropicから出てきた流れですが、価値は特定製品に閉じません。複数のクライアントやツール提供者が同じ接続パターンを使うほど、意味が大きくなります。
MCPはAPIの代わりではない
多くの場合、MCPサーバーは既存APIを包みます。AIクライアントが発見しやすく、使いやすくする接続層です。下にあるAPI、認証、権限、レート制限は依然として重要です。
MCPはセキュリティ設計を不要にしない
AIに実ツールを接続すると、すぐにセキュリティ課題が出ます。
- 機密ファイルを読めるのか
- 社外に情報を送れるのか
- 本番環境へ書き込めるのか
- Prompt Injectionで誤ったツール操作を誘導されないか
MCPはこれらの問いを具体化します。自動的に解決するわけではありません。
まずどう始めるか
個人開発者なら、最初は小さく試すのが現実的です。
- Claude DesktopやCursorなど、一つのクライアントを選ぶ。
- ローカルの安全なフォルダなど、低リスクなMCPサーバーを接続する。
- プロジェクトメモの要約や小さなコード確認など、反復しやすいタスクを試す。
- 書き込み操作にはログや確認を入れる。
- その後でGitHub、DB、社内APIなどへ広げる。
チームで使う場合は、技術より先にポリシーを決めるべきです。
| 決めること | 理由 |
|---|---|
| 承認済みサーバー | 無秩序なツール接続を防ぐ |
| 読み取りと書き込み権限 | 誤操作の被害範囲を制限する |
| シークレット管理 | 認証情報をプロンプトに漏らさない |
| ログ | AIの操作を監査可能にする |
| 評価 | ツール利用が正しいか検証する |
まとめ
MCPが重要なのは、AIが単なるチャットボットから、仕事環境に接続されたインターフェースへ変わりつつあるからです。
会話だけで十分なAI用途なら、MCPは不要かもしれません。
しかし、ファイル、データベース、SaaS、社内API、反復ワークフローをAIに扱わせたいなら、MCPは早めに理解しておく価値があります。
MCPはエージェント全体の答えではありません。けれど、エージェントを現実の業務環境につなぐための重要な接続層です。
FAQ
MCPは開発者だけに関係するものですか？
いいえ。最初に恩恵を受けるのは開発者ですが、プロダクト、セキュリティ、業務部門にも関係します。AIが何を読めるか、何を実行できるかを設計するための境界になるからです。
すべてのAI製品がMCPに対応すべきですか？
必ずしもそうではありません。固定された単純な機能だけなら、Function Callingで十分です。複数のAIクライアントが同じツールや文脈を使う場合に、MCPの価値が大きくなります。
MCPは安全ですか？
MCPはプロトコルであり、安全性そのものではありません。安全性は権限設計、サーバー実装、ログ、確認フロー、Prompt Injection対策によって決まります。