MCP（Model Context Protocol）って、結局何がすごいの？

ミドリ： タツヤさん、最近「MCP」って言葉をよく見かけるんですけど、正直ピンと来てないんですよね。

タツヤ： いいところに来たね。MCPを理解すると、AIエージェントの「できること」が一気に広がるよ。まず前提として、AIエージェントってどれだけ性能が高くても、外部のデータやツールにアクセスできなかったらどうなると思う？

ミドリ(confused)： えーと……ただ文章を生成するだけ、ですか？

タツヤ(nodding)： その通り。社内のドキュメントを参照する、データベースを検索する、Slackにメッセージを送る――こういう「外の世界との接続」がないと、AIエージェントは閉じた空間で動くだけの存在なんだ。

ミドリ(thinking)： じゃあ従来はどうやって外部ツールと接続してたんですか？

タツヤ： ツールごとに個別のインテグレーションコードを開発してた。10個のツールと接続するなら10種類の統合コード、100個なら100種類。この開発・保守コストが膨大だったんだよ。

ミドリ： 100種類……それは辛い。

タツヤ： そこで登場したのがMCP（Model Context Protocol）。Anthropic（アンソロピック、Claude AIの開発企業）が2024年11月に提唱したオープンな標準プロトコルで、AIモデルと外部ツール・データソースの間の通信方式を統一するものだ。

ミドリ： たとえるとどういう感じですか？

タツヤ： USB-Cだね。昔はデバイスごとに違う端子が必要だったのが、USB-Cで統一された。MCPはそれのAI版。しかも公開からわずか数ヶ月で、GitHub、Slack、PostgreSQL、Google Driveなど300以上のMCPサーバーがコミュニティから公開されてる。

ミドリ(smiling)： エコシステムの広がりがすごいですね。

タツヤ： エンタープライズ領域では、MCPを採用したAIシステムの開発工数が従来比で平均40%削減されたという報告もあるよ。

MCPの3つの柱

ミドリ(thinking)： 具体的にMCPの中身ってどうなってるんですか？

タツヤ： 3つの要素で構成されてる。

1. Resources（リソース）

タツヤ(nodding)： まずリソース。AIがアクセスできるデータソースを定義する仕組みだ。ファイル、データベースレコード、APIレスポンスなどを、URIで一意に識別できる形で提供する。

ミドリ(thinking)： 具体的にはどんなURIですか？

タツヤ： こんな感じ。

リソースは「読み取り」に特化していて、動的なもの（データベースクエリの結果）と静的なもの（設定ファイル）の両方をサポートしてるよ。

2. Tools（ツール）

タツヤ： 次にツール。AIが実行できるアクションを定義する仕組み。「何かを行う」操作を記述する。

ミドリ： リソースが「見る」でツールが「やる」ってことですね。

タツヤ： 鋭いね。各ツールにはJSON Schemaで入力パラメータが定義されて、AIモデルはツールの説明文（description）を読んで適切なツールを選択する。だから明確で具体的な説明を書くことが精度向上の鍵だ。

3. Prompts（プロンプト）

タツヤ： 最後にプロンプト。再利用可能なプロンプトテンプレートを定義する仕組み。特定のタスクに最適化されたプロンプトをサーバー側で管理して、クライアントから呼び出せる。

ミドリ： プロンプトまでサーバーで管理できるんですか！

タツヤ： そう。これで組織全体で最適化されたプロンプトを共有できるから、個人のプロンプト品質のばらつきを解消できるんだ。

アーキテクチャの全体像

ミドリ： 全体的な仕組みはどうなってるんですか？

タツヤ： MCPはクライアント・サーバーモデルを採用してて、登場するコンポーネントは3つ。

タツヤ(nodding)： まずMCPホスト。Claude DesktopやVS Codeの拡張機能みたいなAIアプリケーションがこれにあたる。ユーザーとの対話を管理する最上位のコンポーネントだ。

タツヤ： 次にMCPクライアント。ホスト内で動く接続管理コンポーネントで、各MCPサーバーとの1対1の接続を維持する。1つのホストが複数のクライアントを持てるから、それぞれが異なるMCPサーバーに接続できるんだ。

タツヤ： そしてMCPサーバー。外部ツールやデータソースへのアクセスを提供するサーバーで、特定のドメインに特化して構築される。

ミドリ(thinking)： 具体的にどんなサーバーがあるんですか？

タツヤ： たとえばこんな感じ。

通信フローを追ってみよう

ミドリ： 実際にどういう流れで動くのか知りたいです。

タツヤ： じゃあ具体例で説明するね。ユーザーが「先月の売上データを分析して、レポートをSlackに投稿して」って依頼したとする。

  1. MCPホスト（AIアプリケーション）がリクエストを受信
  2. AIモデルが、利用可能なツール一覧からデータベースクエリツールとSlack投稿ツールを選択
  3. MCPクライアントがPostgreSQL MCPサーバーに売上データのクエリを送信
  4. PostgreSQL MCPサーバーが結果を返却
  5. AIモデルがデータを分析し、レポートを生成
  6. MCPクライアントがSlack MCPサーバーにレポート投稿リクエストを送信
  7. Slack MCPサーバーが投稿を実行し、結果を返却
  8. ユーザーに完了報告

ミドリ： これが全部MCPっていう統一プロトコルで動くんですね。シームレスだ。

MCPサーバーの構築

ミドリ： 自分でMCPサーバーを作ることもできるんですか？

タツヤ： もちろん。MCPの公式TypeScript SDK（@modelcontextprotocol/sdk）を使えば、少ないコードで構築できるよ。

基本の構成要素

タツヤ： サーバーの基本構成要素は4つ。

  1. サーバーインスタンスの作成：サーバー名、バージョン、対応するCapabilities（機能）を定義
  2. ツールの登録：名前、説明、入力スキーマ、実行ハンドラーを定義
  3. リソースの登録：URI、説明、データ取得ロジックを定義
  4. トランスポートの設定：標準入出力（stdio）またはHTTP/SSEを選択

ミドリ(thinking)： トランスポートって何ですか？

タツヤ： 通信方式のこと。2種類あって、使い分けが大事だよ。

トランスポート適しているケース特徴
stdioローカル実行、デスクトップアプリとの連携設定が簡単、セキュリティが高い
HTTP/SSEリモートサーバーでの運用、Webアプリとの連携ネットワーク越しのアクセスが可能

ツール定義のコツ

ミドリ： ツールの定義で気をつけることってありますか？

タツヤ(smiling)： AIモデルはツールの説明文を読んでどのツールを使うか判断するから、定義の書き方がめちゃくちゃ重要なんだ。良いツール定義の条件はこれ。

ミドリ： 要は「AIに対するUX設計」みたいなものですね。

タツヤ： いい表現だね、まさにそれだよ。

実践的なユースケース

ミドリ： 企業で実際にどう使われてるんですか？

ユースケース1：社内ナレッジベース連携

タツヤ(nodding)： まず一番多いのがこれ。社内のドキュメントがConfluence、Notion、SharePoint、Google Driveに分散してて、必要な情報を探すのに平均20分かかるって課題があるよね。

ミドリ： あるあるですね……。

タツヤ： 各ドキュメント管理システムに対応するMCPサーバーを構築して、AIアシスタントが横断的に検索・参照できるようにする。導入した企業では情報検索時間が平均20分→2分に短縮（90%削減）。新入社員のオンボーディング期間も3週間から1.5週間に短縮されたケースがあるよ。

ユースケース2：データベースクエリ実行と分析

ミドリ(confused)： 非エンジニアがデータ分析するたびにエンジニアに依頼するの、どこでもありますよね。

タツヤ(nodding)： その通り。MCPでデータベースに接続するサーバーを構築すれば、AIが自然言語の質問をSQLに変換して実行できるようになる。マーケティング部門がキャンペーン分析を自分でできるようになって、分析サイクルが2営業日→15分に短縮された例がある。

ミドリ(confused)： でも、AIがデータベースを直接触るのは怖くないですか？

タツヤ： いい指摘。セキュリティ上の重要ポイントがある。

ユースケース3：外部SaaSツールとの統合ワークフロー

タツヤ： Slack、GitHub、Jira、Salesforce、Google CalendarをMCPで接続して、AIが横断的に操作できる環境を作る。

ミドリ： たとえばどんなことができるんですか？

タツヤ： 「今週のスプリントで未完了のJiraチケットを一覧にして、各担当者にSlackでリマインドを送り、明日の朝会のGoogleカレンダーのアジェンダにも追加して」――こういう複数ツールにまたがる指示を、AIが自動で実行する。従来30分かかってた作業が、数十秒で完了する。

ユースケース4：CI/CDパイプライン統合

タツヤ： 開発環境にMCPサーバーを導入して、AIがビルド、テスト、デプロイのパイプラインを管理・実行する。テスト結果の分析、失敗原因の推定、ロールバックの自動判断なんかもできるようになる。

セキュリティとガバナンス

ミドリ： AIが外部システムを操作できるって、便利だけどリスクもありますよね？

タツヤ： まさに。企業環境でMCPを導入する際は、セキュリティ設計が最重要事項だ。4つのポイントを押さえよう。

最小権限の原則

タツヤ： 各MCPサーバーには必要最小限の権限のみを付与する。メール送信ツールは社内アドレスのみ送信可能とか、顧客データベースは特定のテーブルのみ参照可能とか、きめ細かく制御する。

監査ログ

タツヤ： すべてのツール実行とリソースアクセスを記録する。実行日時、実行ユーザー、使用したツール、入力パラメータ、実行結果、処理時間。ログの保持期間は業界規制に応じて1年〜7年程度が一般的だね。

入力バリデーション

タツヤ： AIから渡されるパラメータに対して厳密なバリデーションを実施する。AIモデルはツールの使い方を誤ることがあるから、不正なパラメータが来る可能性を常に想定する。JSON Schemaによる型チェック、SQLインジェクション対策、ファイルパスのトラバーサル対策、レート制限の実装が必要だ。

人間の承認フロー（Human-in-the-Loop）

ミドリ： 全部AIに任せちゃって大丈夫なんですか？

タツヤ： 大丈夫じゃない。だからHuman-in-the-Loopが重要なんだ。本番データベースへの書き込み、メールの大量送信、外部公開APIの変更――こういう機密性の高い操作は、AIの判断だけで実行せず、人間の承認を必須にするフローを組み込むことを強く推奨する。

MCPエコシステムの現状と将来

ミドリ： 今のMCPエコシステムってどのくらい広がってるんですか？

タツヤ： 主要なMCPクライアント対応状況はこんな感じ。

人気のMCPサーバーは、filesystem、postgresql、github、slack、google-driveあたりだね。

ミドリ： 今後はどう発展していくんですか？

タツヤ： ロードマップでは、エージェント間通信への適用、マルチモーダル対応の拡張、エンタープライズ向けガバナンス機能、リモートMCPサーバーの標準化が予定・期待されてるよ。

まとめ：MCPはAIの「能力拡張基盤」

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： MCPは、AIエージェントの能力を飛躍的に拡張するための基盤技術だ。標準化されたプロトコルで得られるメリットは5つ。

ミドリ： USB-Cのたとえがすごくしっくり来ました。AIの「つなぐ力」を標準化するものなんですね。

タツヤ(nodding)： その通り。これからのAIエージェント開発では、MCPを前提としたアーキテクチャ設計がスタンダードになっていくはずだよ。

次のアクション

ミドリ： MCPを試してみたいんですけど、どこから始めればいいですか？

タツヤ： 3ステップで進めよう。

  1. 体験する：Claude DesktopにfilesystemのMCPサーバーを設定し、AIがローカルファイルを読み書きできる環境を体験する（所要時間：30分）
  2. ユースケースを特定する：自社の業務で「AIがこのツールにアクセスできたら便利」と思う場面を3つ以上リストアップする
  3. 既存サーバーを調査する：MCPサーバーの公式リポジトリで、特定したユースケースに対応するサーバーが既に存在しないか確認する