数年に一度、ソフトウェアコンポーネント間の通信方法を変えるプロトコルが登場する。HTTPがWebで、OAuthが認証で、GraphQLがAPIでそれを成し遂げた。2025年、Model Context Protocol——MCP——がAIエージェントツールでそれを成し遂げようとしている。
MCPが解決する問題は一見シンプルだ。AIエージェントはツールを使う必要がある——Web検索、ファイル読み取り、データベースクエリ、API呼び出し。標準プロトコルがなければ、すべてのツール統合はカスタム実装になる。エージェントフレームワークが独自のツールフォーマットを定義し、ツールプロバイダーがそのフォーマットを実装し、統合はその特定のフレームワークとその特定のツールでのみ動作する。同じツールを別のフレームワークで使いたい？統合を書き直す。エージェントに新しいツールを追加したい？カスタムアダプターを書く。
MCPはフレームワークごと、ツールごとの統合コストを排除する。MCPを話すツールは、MCPを話すあらゆるエージェントで動作する。一度書けば、どこでも使える。USB-Cとの類似は的確だ——USB-C以前は、デバイスごとに独自の充電器があった。USB-C以後は、1本のケーブルですべてが動く。MCPはAIエージェントツールで同じことをしている。
MCPの実体
MCPはJSON-RPCベースのプロトコルで、AIエージェントが外部ツールを発見し、呼び出し、結果を受け取る方法を定義する。MCPサーバーは型付きスキーマを持つツールセットを公開する——各ツールが何をするか、どのパラメータを受け付けるか、何を返すかの記述だ。MCPクライアント（エージェント）がサーバーに接続し、利用可能なツールを発見し、会話中に必要に応じて呼び出す。
プロトコルは、すべてのカスタム統合が再発明しなければならないメカニクスを処理する：ツール発見（どのツールが利用可能か？）、スキーマ検証（パラメータは正しいか？）、呼び出し（ツールを実行して結果を返す）、エラーハンドリング（ツールが失敗したらどうなるか？）。これらは解決済みの問題であり、統合のたびに再度解決する必要はない。
AnthropicがMCPを開発しオープンソース化したが、Anthropic固有のプロトコルではない。どのAIプロバイダーもMCPクライアントサポートを実装でき、どの開発者もMCPサーバーを構築できる。エコシステムは急速に成長しており、GitHub、Slack、データベース、ファイルシステム、Webブラウザ、その他数十のサービス向けのMCPサーバーがすでに存在する。
NanoClawでのMCPの使い方
NanoClawはMCP SDK経由でMCPを統合している。MCP SDKはClaude Agent SDKを含む同じAnthropicツールチェーンの一部だ。エージェントがNanoClawコンテナ内で実行されるとき、ホストが設定したMCPサーバーに接続でき、NanoClaw自体にカスタム統合コードなしでツールにアクセスできる。
これは微妙だが重要なアーキテクチャ上のポイントだ。NanoClawはGitHub統合、Slack統合、データベース統合を実装する必要がない。MCPをサポートするだけでよく、あとはどのMCPサーバーでもそれらの機能を提供する。統合面は数十のカスタムアダプターではなく、1つのプロトコルだ。
実際には、エージェントにGitHubとやり取りさせたいNanoClawユーザーは、GitHub MCPサーバー（別プロセス）をインストールし、NanoClawがそれに接続するよう設定すれば、エージェントはすぐにissueの作成、プルリクエストの読み取り、リポジトリの検索ができる。NanoClawのコード変更なし。Claude Code skillも不要。フォークも不要。
コンテナ隔離モデルはMCPと自然に連携する。MCPサーバーはホスト上、コンテナの外で実行される。コンテナ内のエージェントは制御されたチャンネルを通じてそれに接続する。MCPサーバーは独自のアクセス制御を強制できる——リポジトリへの読み取り専用アクセス、特定のSlackチャンネルのみ、特定のデータベーステーブル——エージェントが何をリクエストするかとは独立して。これは多層防御だ：プロンプトインジェクションがエージェントを騙してリクエストすべきでないものをリクエストさせたとしても、MCPサーバーは独自のポリシーに基づいてリクエストを拒否できる。
MCPがエコシステムにとって重要な理由
MCPのより広い意義は、ツール開発とエージェント開発を分離することだ。MCP以前は、有用なAIエージェントツールを構築するにはフレームワークを選び、そのフレームワークのツールインターフェースを実装する必要があった。GitHubツールはLangChainでは動くがCrewAIでは動かない。データベースツールはAutoGenでは動くがNanoClawでは動かない。フレームワークごとに独自のツールフォーマットがあり、ツール開発者はどのフレームワークをサポートするか選ばなければならなかった。
MCPはその結合を断ち切る。ツール開発者は1つのMCPサーバーを構築すれば、すべてのMCP互換エージェントで動作する。エージェント開発者はMCPを一度サポートすれば、すべてのMCPサーバーがユーザーに利用可能になる。エコシステムは線形ではなく乗算的に成長する——新しいMCPサーバーはすべてのMCP互換エージェントに恩恵をもたらし、新しいMCP互換エージェントはすべての既存MCPサーバーから恩恵を受ける。
NanoClawにとって具体的には、MCPはユーザーが望むかもしれないすべてのサービスの統合を構築・保守する必要がないことを意味する。Claude Code skillsモデルがチャンネル統合（Telegram、Discord、Slack）を処理し、MCPがツール統合（GitHub、データベース、API）を処理する。この2つの間で、NanoClawは大規模な統合コードベースのメンテナンス負担なしに幅広いユースケースをカバーする。
実践的なセットアップ
NanoClawでのMCP設定は簡単だ。MCPサーバーを実行し——自分で構築したものか、成長するオープンソースサーバーのエコシステムからのもの——NanoClawをそれに向ける。エージェントは利用可能なツールを自動的に発見し、会話中に使用できる。
ユーザーの視点からの体験はシームレスだ。WhatsAppアシスタントに「昨日話したログインバグのGitHub issueを作って」と頼めば、エージェントはGitHub MCPサーバーを使ってissueを作成し、会話メモリからコンテキストを引き出して詳細を埋める。MCPが関与していることを知る必要はない。頼むだけで、エージェントにはそれを実行するツールがある。
プロトコルはまだ若い——2025年初頭に採用が加速し始めた——が、軌道は明確だ。MCPはAIエージェントが外部サービスとやり取りする標準的な方法になりつつあり、早期に採用したプロジェクトは、自分では何も構築せずに成長するツールエコシステムにアクセスできる。NanoClawのMCPへの賭けは、エコシステムがどんなカスタム統合のセットよりも価値があるという賭けだ。