1 つのビルドが 1 億回のコーディングに勝ち、MCP がシリコンバレーで流行中!アントロピック・プロトコルはインテリジェントエージェントの「ユニバーサルハンド」を解き放つ

先週は AI にとって画期的な週でした。

Manusとそのオープンソース複製、Operaのブラウザ操作AIエージェント、AIワークパートナーArcher、さまざまな個人プロジェクトまで、Agentは話題になっています。

多くの場合 10 分以上、場合によっては数十分もかかる複雑なタスクを処理する場合、次の 3 つのコア機能が関係します。

1. 計画
2. ツールの使用
3. メモリ

このうち、2 番目の部分は、インテリジェント ボディを「動かし」、現実世界と実際に相互作用させるための鍵となります。

たとえば、現在最も強力なオープンソース再生技術である OWL が今日ロンドンで上映される映画を検索する場合、AI エージェントは Chrome 検索ツールを積極的に呼び出し、映画館のリアルタイム情報を正確に返します。

最も人気のあるオープンソース プロジェクトである OpenMauns も、Karpathy の個人ホームページ情報を検索する際に、その強力なツール使用機能を活用しました。

これらの事例は、ツールの使用により、インテリジェントエージェントが空想の限界を打ち破り、物事を実行する能力を進化させることができることを鮮明に示しています。

最も強力な標準化されたインターフェース プロトコルとして、MCP はシリコン バレーで一夜にして人気となり、誰もが知るようになりました。

サークル外の人にとっては、これは馴染みのない話かもしれません。そしてその本質は一種のインテリジェントシステムです。

1億通りの構成の代わりに1つのビルド

昨年 11 月、Anthropic は初めて「モデル コンテキスト プロトコル」、つまり MCP を提案しました。これにより、Claude モデルにスーパーパワーが与えられ、1 つのビルドで AI をワークフローに深く統合できるようになりました。

主な利点は次のとおりです。

• 開発の簡素化:一度記述すれば、新しい統合ごとにカスタムコードを書き直すことなく、何度も統合できます。
• 柔軟性: AIモデルやツールを切り替える際に複雑な再構成は不要
• リアルタイム応答: MCP接続はアクティブなままで、リアルタイムのコンテキスト更新とインタラクションをサポートします。
• セキュリティとコンプライアンス:組み込みのアクセス制御メカニズムと標準化されたセキュリティプラクティス
• スケーラビリティ: AIエコシステムが拡大しても、新しいMCPサーバーを接続するだけで簡単に新しい機能を追加できます。

簡単に言えば、MCP は日常生活で使用されている USB-C と同様に、AI アプリケーション専用に設計されたユニバーサル インターフェースのようなものです。

USB-C がさまざまなデバイスをコンピューターに接続する方法を簡素化するのと同様に、MCP は AI モデルがデータ、ツール、サービスと対話する方法を簡素化します。

MCP を通じて、AI アシスタントはコードを「読み取る」だけでなく、チームの議論や関連ドキュメントなどの外部情報を「理解」し、より正確な回答を提供できるようになります。

MCP は、AI エージェントをさまざまな外部ツールやデータ ソースに接続するための標準化されたプロトコルです。

対照的に、MCP 以前は、AI アシスタントは外部ツールとやり取りするためにコードを記述し、API を呼び出す必要がありました。つまり、特定の接続ごとに事前に手動でプログラムする必要があり、非効率的で時間がかかりました。

さらに困難なことに、各 AI アシスタントと各外部ツールを個別に構成する必要があります。 AIアシスタントが1,000個、外部ツールが1,000個ある場合、理論的には1,000×1,000=100万個の独立した接続コードを記述する必要があり、これは天文学的な作業量になります。

例え話で言えば、API はそれぞれ独自のキーと使用ルールを持つさまざまなドアのようなものです。

従来のAPIでは、開発者はサービスやデータソースごとにカスタム統合コードを記述する必要があります。

MCPの登場は、AIアシスタントと外部システムに共通の「標準言語」を生み出すようなものであり、インテリジェントエコシステムにおける「標準化革命」とも言えるでしょう。

AI アシスタントが MCP プロトコルを実装すると、接続ごとに個別のコードを記述することなく、このプロトコルを介して何千もの外部ツールにシームレスに接続できるようになります。

同様に、外部ツール（電子メール、天気アプリなど）では、MCP サーバーを 1 回構築するだけで、MCP をサポートするすべての AI アシスタントが直接対話できるようになります。

AI アシスタントが 10,000 個、外部ツールが 10,000 個あるとします。 MCP モードでは、各当事者はプロトコルを 1 回だけ実装すればよく、必要な構成は合計で 20,000 個だけです。

従来のコーディング方法によれば、各 AI アシスタントを各外部ツールに個別に接続する必要があるため、構成は 10,000 x 10,000 = 1 億通りになります。

これにより、複数の側面で構成効率が直接向上します。

MCP の柔軟性も非常に優れています。クラウドで実行することも、ローカルデバイスに展開することもでき、適応性が非常に高いです。

MCP は、技術者が手動で橋を一つずつ構築する必要があった非効率的なモデルに代わる、AI アシスタントと外部システムの間に高速道路を構築するようなものであると言えます。

MCPとは何ですか?

前述したように、MCP (モデル コンテキスト プロトコル) は、コンテキスト情報を送信するための標準化された方法を LLM に提供し、AI エージェントと外部データおよびツールの統合を可能にすることを目的とした新しいオープン プロトコルです。

従来の API と比較した場合、MCP の違いは次のとおりです。

• 単一プロトコル: MCP は標準化された「ユニバーサル インターフェイス」です。MCP を統合すると、単一のサービスだけでなく、複数のツールやサービスにアクセスできるようになります。
• 動的検出: MCP を使用すると、統合ごとに固定コードを事前に構成する必要なく、AI モデルが利用可能なツールを動的に検出して対話できるようになります。
• 双方向通信: MCP は、WebSocket と同様に、永続的でリアルタイムの双方向通信をサポートします。 AI モデルは、リアルタイムで情報を取得し、アクションをトリガーできます。

このうち、リアルタイム双方向通信の仕組みは以下のとおりです。

• データのプル: LLM はサーバーにコンテキスト情報を照会します。たとえば、カレンダーを確認してください。
• トリガーアクション: LLM はサーバーに特定のアクションを実行するように指示します。たとえば、会議のスケジュール変更、電子メールの送信などです。

ただし、アプリケーション シナリオで厳密な制約を伴う正確で予測可能なインタラクション パターンが必要な場合は、従来の API の方が適している可能性があります。

MCP は、柔軟性とコンテキスト認識を必要とするシナリオに適した幅広い動的機能を提供しますが、高度に制御された決定論的なアプリケーションには最適な選択肢ではない可能性があります。

次のような状況では、従来の API が推奨されます。

• きめ細かな制御と非常に限定された機能を必要とするシナリオ
• パフォーマンスの最適化を追求するには、密に結合されたシステムが必要
• 最大限の予測可能性と最小限のコンテキスト自律性を必要とするアプリケーション

建築

MCP はシンプルなクライアント サーバー アーキテクチャ モデルを採用しています。

• MCP ホスト:外部データやツールにアクセスする必要があるアプリケーション (Claude Desktop や AI 駆動型統合開発環境など)
• MCPクライアント: MCPサーバーとの専用の1対1接続を維持します
• MCP サーバー: MCP プロトコルを通じて特定の機能を提供し、ローカルまたはリモートのデータ ソースに接続する軽量サーバー
• ローカル データ ソース: MCP サーバーによって安全にアクセスされるファイル、データベース、またはサービス
• リモートサービス: MCP サーバーがアクセスするインターネットベースの外部 API またはサービス

MCP は、ブリッジと比較するとより明確に理解できます。MCP 自体は複雑なロジックを処理せず、AI モデルとさまざまなツール間のデータと命令のフローを調整するだけです。

具体的には、サーバーが API と対話します。リモート サーバー (クラウドなど) またはローカル システム上に配置できます。

Slack メッセージの送信、ファイルの作成などのアクションを実行するためにシステム上で対話するために必要なすべてのコードが含まれています。

下の図に示すように、MCP サービスを使用して GitHub API を呼び出し、リポジトリにコード ファイルを作成できます。

MCP クライアントはサーバーとの通信を担当します。クライアントの本当に素晴らしい機能は、複数のサーバーと同時に対話できることです。

したがって、GitHub のやり取りと Slack のやり取りを処理するための専用サーバーを設定し、それらを同じクライアントに接続することができます。

最も重要なのは、プロトコルがすべてを機能させるということです。決して変更されることなく、MCP サーバーと MCP クライアントの両方で使用できるユビキタス言語と考えてください。

これは USB インターフェイスのように機能し、MCP クライアントを MCP サーバーに接続するために使用されます。

USB インターフェイスを使用すると、携帯電話をラップトップに接続でき、MCP プロトコルを使用すると、サードパーティの API をデスクトップ アプリケーションに接続できます。

Total TypeScript の作者である Matt Pocock 氏も、さまざまな種類の MCP クライアントの比較を実施しました。

ご覧のとおり、Claude Desktop と Continue はリソース、ヒント、ツールをサポートしており、非常に包括的です。 5ire と BeeAI Framework はより制限されています。ツールのサポートは問題ありませんが、他の面は基本的に良くありません。 Cline はリソースとツールもサポートしますが、プロンプトはサポートしません。カーソルとEmacs Mcpは主にツールをサポートしており、他の機能は利用できません。単純なツール操作に適しています。

アプリケーションシナリオ

実際には、MCP クライアント (client.py の Python スクリプトなど) は、Gmail、Slack、カレンダー アプリなどのさまざまな特定のツールとのやり取りを管理する MCP サーバーと通信します。

この標準化により複雑さが大幅に軽減され、開発者は複雑なインタラクティブ機能を迅速に実装できるようになります。

1. 旅行計画アシスタント

• 従来の API を使用する場合、Google カレンダー、メール、航空券予約 API ごとに個別のコードを記述する必要があり、それぞれに個別の認証、コンテキストの受け渡し、エラー処理ロジックが必要です。
• MCP の使用ははるかに簡単で、AI アシスタントはカレンダーの空き状況の確認、フライトの予約、確認メールの送信をシームレスに実行できます。これらはすべて、ツールごとに個別の統合コードを開発することなく、MCP サーバーを介して実行されます。

2. 高度な IDE (インテリジェント コード エディター)

• 従来の API を使用するには、開発環境をファイル システム、バージョン管理、パッケージ マネージャー、ドキュメント システムと手動で統合する必要があります。
• MCP を使用すると、開発環境は単一の MCP プロトコルを介してこれらのサービスを接続し、より豊富なコンテキスト認識機能とよりスマートなコード提案が可能になります。

3. 複雑なデータ分析

• 従来の API を使用する場合、個々のデータベースやデータ視覚化ツールへの接続を手動で管理する必要があります。
• MCP AI 分析プラットフォームは、統合された MCP レイヤーを通じて、複数のデータベース、視覚化ツール、シミュレーション システムを自動的に検出し、対話することができます。

クイックスタート

MCP 統合プロセス:

• 機能の定義: MCP サーバーが提供する機能を明確に計画する
• MCPレイヤーを実装する:開発のための標準化されたMCPプロトコル仕様に従う
• トランスポートを選択します:ローカル トランスポート (stdio) またはリモート トランスポート (Server Sent Events/WebSocket) を選択します
• リソース/ツールの作成: MCP がやり取りする特定のデータ ソースとサービスを開発または接続します。
• クライアントのセットアップ: MCPサーバーとクライアント間の安全で安定した接続チャネルを確立します。

MCP ユースケースの爆発的増加

大型モデルが普及した後、エンジニアは新しい職業になりました。現在、一部の有力者は、開発者は商用 MCP サーバーを早急に構築すべきだと提案しています。

Total TypeScript の作者である Matt Pocock 氏は、わずか 28 行のコードで MCP サーバーを開発しました。

Cursor+MCP の夢の連携により、プロセス全体を通じて人間の介入なしに、顧客が必要とする機能を迅速に構築できます。

プログラマーにとって、これは効率性のさらなる大幅な向上です。 AIはコードの作成を支援するだけでなく、需要分析から機能の起動までの全プロセスを自動的に完了します。

顧客がSlackを通じて機能リクエストを送信すると、Cursorが自動的にメッセージを読み取り、機能を構築し、プルリクエストを作成します。

元 Meta 研究者であり CopilotKit の創設者でもある Atai Barkai 氏が、Open MCP Client プロジェクトをオープンソース化しました。

これにより、あらゆるアプリケーションが MCP サーバーと直接通信できるようになり、よりインテリジェントな機能を実現できます。

開発者は、ゼロから開発する必要なく、Composio から URL を取得するだけで、MCP 機能を独自のアプリケーションに統合できます。

プロジェクトアドレス: https://open-mcp-client.vercel.app/

Agno の開発者 Ashpreet Bedi は、複数の MCP サーバーを簡単に接続して管理できる「ユニバーサル MCP エージェント」UAgl を作成しました。

開発者の Will Brown 氏は、開発中に MCP サーバーをテストするときに、サーバー (Claude 用) とクライアント (テスト対象のサーバー用) の両方として機能できる MCP テスト クライアントをオープンソース化しました。