Model Context Protocol完全ガイド - Anthropic Tokyo Summit 2025参加レポート

はじめに

2025年10月28日、Anthropicが東京で開催した「Anthropic Builder Summit Tokyo 2025」に参加してきました。これはAnthropicが日本市場へのコミットメントを示す初の開発者向けイベントで、CEOのダリオ・アモデイ氏、共同創設者のベン・マン氏、そして日本支社長の東條英俊氏が登壇しました。

Anthropic日本支社長 東條英俊氏とCEO ダリオ・アモデイ氏のファイアサイドチャット

Anthropic共同創設者 ベン・マン氏による基調講演

イベントでは複数のセッションが行われましたが、その中でも特に印象的だったのが「MCP Deep Dive」セッションです。Model Context Protocol（MCP）は、AIエージェントと外部サービスを標準的に接続するためのプロトコルとして、2024年末に発表されて以来、大きな注目を集めています。本記事では、Anthropicのエンジニアが直接語ったMCPの設計思想、技術的な詳細、そして未来の展望についてレポートします。

MCP Deep Diveセッションの様子

セッション概要

発表者：

• Jerome：ニュージーランド出身のAnthropicエンジニア。MCPを構築した最初の3人のエンジニアの1人
• Alex：Anthropicのエンジニア。claude.aiのMCPクライアント実装を担当

このセッションでは、MCPが生まれた背景から、技術的な詳細、安全性への配慮、そして今後の展望まで、約45分にわたって詳しく解説されました。

MCPが必要とされる背景

LLMアプリケーションの進化

LLMアプリケーションは、これまで3つの段階を経て進化してきました：

1. 初期：単純なLLMコール

   • LLMに入力を渡して出力を得るだけのシンプルな形式

2. 第2段階：ワークフロー

   • プログラム的に定義されたマルチステップの処理
   • 例：ドキュメントを受け取り→分類→集約→要約

3. 現在：エージェントモデル

   • LLM自身がタスク完了のためのステップを決定
   • ツールの呼び出し、環境との対話、外部サービスへのアクセス

カスタムコネクタの限界

現在のエージェントは、AsanaやGoogleカレンダーなどの外部サービスと通信するために、サービスごとにカスタムコネクタを構築する必要があります。しかし、この方法には大きな問題があります：

スケーラビリティの欠如

• 今日のAIエージェンシーは、何十、何百もの外部サービスと通信したい
• 新しいサービスごとにコネクタを作り続けるのは非現実的

なぜAIエージェントは直接APIと通信できないのか？

Alexは、エージェントが直接APIと通信することの困難さを4つの理由で説明しました：

1. APIの標準規格がない

• GRPC、REST、SOAP、その他無数の実装が存在
• 統一された通信方法がない

2. ドキュメンテーションの問題

• 多くのAPIはドキュメントが不十分、または全くない
• 十分に文書化されているものでさえ、ドキュメントが膨大
• 例： Asanaのドキュメンテーションは約60万LLMトークン（ほとんどのモデルのコンテキストウィンドウよりも大きい）

3. エンドポイントが多すぎる

• 例： Asana APIには300以上のエンドポイントが存在
• モデルがタスク完了のためにどのAPIを呼び出すべきか判断が困難

4. 認証の複雑さ

• 特に何十、何百もの外部サービスを扱う場合、認証管理が非常に複雑

MCPの解決策

MCPは複数のモデルのAPIを標準化 - AsanaとGoogleの例

MCPの基本構成

MCPは、AIエージェントと外部サービスの間に位置する「適応レイヤー」として機能します。

MCPサーバー

• 外部サービスのAPIを共通のMCPインターフェースに変換するアダプタ
• サービス提供者が実装

MCPクライアント

• AIエージェント側に実装
• 任意のMCPサーバーと通信可能

実装の容易さ

Jeromeは実装の容易さを強調しました：

「実装するのは実はとても簡単です。ほぼすべての主要なプログラミング言語に対応したMCP SDKがあります。」

重要な特性：

• 一度サーバーが実装されれば、変更なしで任意のMCPクライアントで使用可能
• 再利用性が非常に高い

既存のエコシステム

すでに多くのアプリケーションがMCPクライアントとして実装されています：

主要なMCPクライアント：

• claude.ai
• Claude Code
• Visual Studio Code
• Cursor
• その他多数

サーバーの状況：

• Asanaなど多くのサービスがファーストパーティのMCPサーバーを提供
• コミュニティによる多数のサードパーティサーバー

事前構築済みMCPの広範なエコシステム - 様々なサービスカテゴリ

技術的プリミティブの詳細

Jeromeは、MCPがサポートする主要なプリミティブについて詳しく解説しました。MCPは非対称プロトコルであり、サーバー側とクライアント側でそれぞれ異なるプリミティブを提供します。

サーバー側プリミティブ

1. Tools（ツール）

最も人気のあるプリミティブで、エージェントが外部世界と対話するための主要なメカニズムです。

例：

• GitHub検索
• Slackチャンネルの閲覧
• ファイルの編集
• その他、エージェントに実行させたい操作全般

追加機能：

• 長時間実行されるツールの進捗状況を通知・更新できる
• ユーザーは処理中も進捗を把握可能

2. Resources（リソース）

サーバーからクライアントに追加したい任意のコンテキストを提供するための汎用メカニズムです。

Jeromeの説明：

「リソースについては、MCPクライアントにどのように追加すべきか、またはどのように表現すべきかについて、強い意見や規定はありません。claude.aiでは、ファイル添付と同様のものとして表現しています。」

主な用途：

• RAG（Retrieval-Augmented Generation）パイプラインへの入力に最適
• ファイルシステム上のファイル
• データベーススキーマ
• Slackチャンネル

サブスクリプション機能：

• リソースが更新されたことを通知可能
• RAGパイプラインがいつリソースを再取得すべきかを判断できる

3. Prompts（プロンプト）

ユーザー中心のプリミティブで、エンドユーザーが会話に特定のコンテキストを追加できるようにします。

Jeromeの見解：

「世界がよりエージェント的になるにつれて、これらはほとんどのユーザーにとってあまり役立たなくなると考えています。しかし、スーパーユーザーにとっては依然として非常に便利です。」

使用例：

• 特定のGitHubプルリクエストの説明を会話に追加
• オートコンプリート機能を提供

クライアント側プリミティブ

1. Sampling（サンプリング）

MCPサーバーがクライアント側のLLMに推論をリクエストできる機能です。

メリット：

• ユーザーは各MCPサーバーに支払い詳細を追加する必要がない
• データを別の推論プロバイダーに送信する必要がない
• MCPサーバーの設定オーバーヘッドが削減される

使用例：

• ドキュメントの要約
• エージェントの実行

2. Roots（ルート）

主にローカルMCPサーバーで使用されるプリミティブです。

Jeromeの開発背景：

「私たちが最初にMCPを作っていたとき、それはすべてローカルでした。Git MCPサーバーにどのフォルダで作業しているかを伝えられなかったので、これを追加しました。」

現在の使用：

• VS Codeや他のコード編集MCPクライアントで使用
• リモートMCPではあまり使われていない

3. Elicitation（誘導）

最近仕様に追加されたプリミティブで、MCPサーバーがエンドユーザーから直接情報を要求できます。

使用シーン：

• MCPサーバーが潜在的に破壊的な操作を行おうとするとき

例：

「モデルがユーザーのアプリの本番データベースを削除しようとしています。MCPサーバーは親切にも、それが本当に彼らが望んだことなのかを尋ねています。」

MCPの活用シーンとユースケース

Jeromeは、MCPが特に有効となる4つの主要なシーンを紹介しました。

1. 外部ユーザー向け製品

シーン：
ソフトウェア製品を持っており、外部ユーザーに彼らのエージェントから製品と対話してほしい場合

実装：

• MCPサーバーを構築
• ユーザーはどのMCPクライアントからも接続可能

実例：

• Asanaは独自のMCPサーバーをホスト
• 誰でも簡単にAsanaに接続するLLMアプリケーションを作成可能

2. チャットアプリの開発

シーン：
チャットアプリやMCPクライアントを構築している場合

メリット：

• MCPサーバーのエコシステムを活用できる
• エンドユーザーが持っているどのMCPサーバーも利用可能

3. 社内エージェント

シーン：
企業内部でエージェントを使用する場合

メリット：

• 外部にアクセスしていなくても有用
• すべてを統合するために必要な作業量を最小化

4. 内部サービス

シーン：
エージェントに対話させたい内部サービスがある場合

実装：

• サービスの前にMCPサーバーインターフェースを構築

ローカルMCPの可能性

Jeromeは、リモートMCPだけでなく、ローカルMCPの興味深いユースケースについても語りました。

ウェブAPIに限定せず - 物理デバイス、クライアントアプリ、コンピュータとブラウザの使用

物理デバイスの制御

Jeromeの個人的な例：

「これまでに書かれた最初のMCPサーバーの1つは、私のアパートの玄関のドアを開けるためのモーターを備えた小さなコンピュータです。鍵がうまく合わなかったからです。そして、私はこれが鍵を直してもらうよりもどういうわけか簡単だと思いました。」

クライアントアプリケーションの制御

例：

• iMessage
• Puppeteer
• Blender
• Ableton Live

コンピュータ/ブラウザの直接制御

Jeromeの推奨：

「これは私たちのモデルの新たな能力です。モデルがリリースされるたびに、ますます良くなっています。今どれくらい優れているかを見たい場合は、デモステーションでClaude for Chromeのデモを試してみることをお勧めします。」

安全性とセキュリティへの取り組み

Alexは、エージェントに強力な機能を追加することで増大するリスクについて、Anthropicの多層防御アプローチを説明しました。

MCPに隣接する主な安全リスク - 4つのカテゴリ

4つのリスクカテゴリ

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

悪意のある攻撃者がモデルのコンテキストに指示を挿入し、ユーザーが望まないことを実行させる

例：
機密性の高いユーザーデータを外部に流出させる

2. 標準的なセキュリティリスク

MCPサーバー、MCPクライアントは通常のアプリケーションなので、他のアプリケーションと同様のセキュリティリスクが存在

3. モデルのミス

悪意のある攻撃者によってプロンプトされなくても、モデルは間違いを犯す可能性がある

例：
本番データベースを削除しようとする

4. システミックリスク

AIエージェントが増え、より強力になり、人間や互いに相互作用し始めると、予期しない振る舞いが発生する可能性が高まる

プロンプトインジェクションへの多層防御

Anthropicは「Defense-in-Depth（多層防御）」アプローチを採用しています。攻撃者が攻撃を成功させるまでに突破しなければならない複数の防御層があります。

リスクに対する取り組み：プロンプトインジェクション - モデル、API、アプリケーションの3層防御

第1層：モデルトレーニング

アプローチ：
モデルに、ユーザーの意図に反するように見える指示を無視するように教える

効果：
トレーニングだけで攻撃の約90%をブロックすることに成功

Alexのコメント：

「しかし、90%では十分ではありません。」

第2層：分類器

アプローチ：
会話を常にスキャンし、不審なものを探し出す分類器モデルを追加

効果：
モデルが危険な行動をとるのを防ぐ

第3層：アプリケーション層

claude.aiでの実装：

• 呼び出されたすべてのツールのログを保持
• ユーザーがツールの呼び出しを受け入れるか拒否するかを選択可能
• モデルが行っていることすべてをユーザーが把握できる

リスクに対する取り組み（続き） - 各リスクカテゴリへの具体的な対策

その他のリスクへの対策

標準的なセキュリティ

• コードサイニング
• サンドボックス化
• その他のベストプラクティス

モデルのミス

• より良く、より賢いモデルの開発
• Elicitation APIによる確認機能

システミックリスク

• Anthropicの大きな研究分野
• 実例：Claudeにオフィス内の小さなお店を管理させ、従業員に商品を販売させる実験

MCPの未来

セッションの最後に、Jeromeは今後のMCPの展望について語りました。

1. エージェント間通信

背景：
世界により多くのエージェントが存在するようになると、エージェント間の通信が重要になる

初期アプローチ：
プロトコルを対称的にし、ツールをクライアント側とサーバー側の両方に配置

現在のアプローチ：
2つのエージェントが共有MCPサーバーと通信するよりシンプルなモデル

実装例：

• Slackサーバーを使ってエージェント間通信を実装
• 人間もエージェントとの通信に参加可能

2. MCPレジストリ（プレビュー版リリース済み）

目的：
MCPサーバーのエコシステム全体のための公開レジストリ

背景：

「歴史的に、これらは操作が難しく、インストールも困難でした。」

公式MCPレジストリ - 発見、一元化、統一されたインストールを実現

レジストリの内容：

• ローカルMCP用のコードをインストールできる場所を指すメタデータ
• リモートMCP用のURL

メリット：

• 新しいMCPサーバーを簡単に発見
• 信頼のための一元化された場所
• 統一されたインストール方法

MCPサーバーからレジストリ、サブレジストリを経由してクライアントへ

サブレジストリ：
企業や信頼できる組織が、検証済みサーバーの短いリストを作成できる

3. ツールの過多問題

課題：
ツールが多すぎると、エージェントはそれらすべてに対応できず、パフォーマンスが低下

解決策：
エージェントに利用可能なツールを検索するツールを提供

メリット：

• ツールの使い方を学ぶのを実際に必要になるまで遅延
• エージェントのコンテキストウィンドウを保持
• レジストリから動的にツールを発見可能

4. MCPとコード（最も重要なトピック）

Jeromeが最も興奮している領域です。

業界のトレンド：
「エージェントがその場でソフトウェアを書き、使用しようとしているサービスと直接対話できるなら、なぜMCPが役立つのか」

Jeromeの考え：

「私たちは、これら両方を持つことができると考えています。エージェントにMCP機能を呼び出すコードを書く能力を与えることは、多くの興味深いユースケースを解き放つ、ちょうど良い中間地点だと考えています。」

ツールの発見

アプローチ：
モデルが利用可能なすべてのツールを検索し、キーワードで絞り込むコードを書く

ツールの合成（コンポジション）

メリット：

• あるツールの出力を変数として受け取り、それを別のツールに渡す
• トークンを節約
• コンテキストを節約
• より速く、より表現力豊か

制御フロー

可能になること：

• whileループでツールを呼び出す
• 少ないトークンで100個のツールを呼び出す
• 非同期のツール呼び出し
• forループ
• 条件付きロジック

状態の永続化

可能になること：

• モデル自体によってメモリが構築される
• モデルが以前に書いたコードを保存
• モデルが独自のツールを構築し共有

相乗効果：
スキル（Skills）のようなものと相乗効果があり、MCPとスキルがうまく連携する

参加して感じたこと

実際にMCPの開発者から直接話を聞いて、いくつかの重要な気づきがありました。

設計思想の明確さ

MCPは「完璧な統合」を目指すのではなく、「適応レイヤー」として機能することに焦点を当てている点が印象的でした。これにより、実装の複雑さと実用性のバランスが取れています。

安全性への真摯な取り組み

単なる技術的な機能だけでなく、プロンプトインジェクションやシステミックリスクなど、AIエージェントがもたらす新しいセキュリティ課題に対して、多層的なアプローチで取り組んでいる姿勢が印象的でした。

未来志向の設計

「MCPとコード」のセクションでJeromeが語った内容は、単なるAPI統合を超えて、エージェントがより自律的かつ効率的に動作できる未来を見据えたものでした。この分野の進化が非常に楽しみです。

まとめ

Anthropic Builder Summit Tokyo 2025のMCP Deep Diveセッションは、MCPの技術的な詳細だけでなく、その設計思想や未来の展望まで包括的に理解できる貴重な機会でした。

主要なポイント：

1. MCPは必然的な解決策 - AIエージェントと外部サービスの統合における課題を、標準化されたアプローチで解決
2. 実装が容易 - SDKの提供により、開発者は容易にMCPサーバー/クライアントを構築可能
3. 安全性を重視 - 多層防御アプローチにより、様々なリスクに対応
4. エコシステムの成長 - 主要なアプリケーションが既にMCPクライアントとして実装済み
5. 進化し続ける - エージェント間通信、レジストリ、コードとの統合など、さらなる発展が予定されている

MCPは、AIエージェントの時代における重要なインフラストラクチャとなりつつあります。今後の発展に大いに期待したいと思います。

参考リンク

関連記事

同じイベントの別セッションのレポートもぜひご覧ください：

MCP関連リソース