AIエージェントの継続的な下落は、最近話題になったMCPプロトコルによるものですか？

著者：Haotian

友人が言うには、#ai16zや$arcなどのweb3 AIエージェントの持続的な下落は、最近急成長しているMCPプロトコルによるものだと？初めて聞いたときは、ちょっと混乱しましたが、WTF、関係あるの？しかし、よく考えてみると、確かに一定の論理があることに気づきました：既存のweb3 AIエージェントの評価価格の論理が変わり、物語の方向性と製品の実現ルートを調整する必要があるのです！以下、個人的な見解を述べます：

1）MCP（Model Context Protocol）は、さまざまなAI LLM/エージェントがさまざまなデータソースやツールにシームレスに接続できるようにすることを目的としたオープンソースの標準化プロトコルであり、まるで即插即拔のUSB「汎用」インターフェースのようなもので、過去のエンドツーエンドの「特定」なパッケージ方式を置き換えます。

簡単に言えば、元々AIアプリケーション間には明確なデータ孤島が存在し、エージェント/LLM間で相互に情報をやり取りするためには、それぞれが対応するAPIインターフェースを開発する必要があり、操作プロセスは複雑であるだけでなく、双方向の相互作用機能も欠けており、通常は比較的限られたモデルアクセスと権限制限があります。

MCPの登場は、AIアプリケーションが過去のデータ孤島状態から脱却し、外部のデータやツールに「動的」にアクセスできる可能性を提供する統一されたフレームワークを提供し、特に自動化タスクの実行、リアルタイムデータのクエリ、クロスプラットフォームの協力などの面で明らかな推進効果を持つことができます。

ここまで来ると、多くの人がすぐに思い浮かぶのは、複数のエージェントが協力して革新を行うManusが、このMCPオープンソースフレームワークを統合することで、複数のエージェントの協力を促進するのではないかということです。これは無敵になるのでは？

その通りです。Manus + MCPこそがweb3 AIエージェントが今回の影響を受けた鍵です。

2）しかし、驚くべきことに、ManusもMCPもweb2 LLM/エージェント向けのフレームワークとプロトコル標準であり、解決しているのは中央集権的なサーバー間のデータのやり取りと協力の問題です。その権限とアクセス制御は、各サーバーノードの「能動的」なオープンに依存しています。言い換えれば、それは単なるオープンソースツールの属性に過ぎません。

理論的には、それはweb3 AIエージェントが追求する「分散型サーバー、分散型協力、分散型インセンティブ」といった中心思想とは完全に対立しており、中央集権的なイタリア砲がどのようにして非中央集権的な砦を攻撃できるのでしょうか？

その理由は、第一段階のweb3 AIエージェントがあまりにも「web2化」していることにあります。一方では、多くのチームがweb2の背景を持っており、web3ネイティブの本質的なニーズを十分に理解していません。例えば、ElizaOSフレームワークは、開発者がAIエージェントアプリケーションを迅速に展開するためのパッケージフレームワークであり、Twitter、DiscordなどのプラットフォームやOpenAI、Claude、DeepSeekなどの「APIインターフェース」を統合し、いくつかのMemory、Characterの汎用フレームワークを適切にパッケージ化して、開発者がAIエージェントアプリケーションを迅速に開発できるようにしています。しかし、厳密に言えば、このサービスフレームワークとweb2のオープンソースツールには何の違いがあるのでしょうか？また、どのような差別化された優位性があるのでしょうか？

ええ、優位性は一つのトークノミクスのインセンティブ方式があることですか？そして、web2で完全に置き換えられるフレームワークを使って、新しいコインを発行するために存在するAIエージェントをさらに多くインセンティブするのですか？恐ろしい。。この論理に従って考えると、なぜManus + MCPがweb3 AIエージェントに影響を与えることができるのかがわかります。

多くのweb3 AIエージェントフレームワークとサービスは、web2 AIエージェントの迅速な開発とアプリケーションニーズを解決するだけであり、技術サービスや標準、差別化された優位性においてweb2の革新速度に追いついていないため、市場/資本は前のweb3 AIエージェントの再評価と再価格設定を行いました。

3）ここまで来ると、問題の本質が見えてきたと思いますが、どうやって打破するのでしょうか？唯一の道は、web3ネイティブのソリューションに集中することです。なぜなら、分散型システムの運用とインセンティブアーキテクチャこそがweb3の絶対的な差別化された優位性だからです。

分散型クラウドコンピューティング、データ、アルゴリズムなどのサービスプラットフォームを例に挙げると、一見すると、こうした遊休資源を理由に集まったコンピューティングパワーとデータは、短期的には工学的な実現革新のニーズを満たすことができないように見えますが、大量のAI LLMが集中型コンピューティングパフォーマンスの突破を目指しているときに、「遊休資源、低コスト」を売りにしたサービスモデルは、web2の開発者やVCチームから軽視されることになります。

しかし、web2 AIエージェントがパフォーマンス革新の段階を過ぎると、必然的に垂直アプリケーションシーンの拡張や細分化されたモデルの最適化などの方向を追求することになります。その時こそ、web3 AIリソースサービスの優位性が真に現れるでしょう。

実際、リソースを独占する形で巨頭の地位に上り詰めたweb2 AIが一定の段階に達すると、再び「農村が都市を包囲する」という考え方に戻ることは難しく、個々の細分化されたシーンを打破することになります。その時こそ、過剰なweb2 AI開発者とweb3 AIリソースが団結して力を発揮する時です。

実際、web3 AIエージェントは、web2の迅速な展開 + 複数エージェントの協力通信フレームワーク + トークノミクスの発行物語に加えて、探求すべき多くのweb3ネイティブの革新方向があります：

例えば、分散型コンセンサス協力フレームワークを備え、LLM大モデルのオフチェーン計算 + オンチェーン状態ストレージの特性を考慮し、多くの適応性のあるコンポーネントが必要です。

1、エージェントが検証可能なオンチェーンアイデンティティを持つことができる去中心化のDID認証システム。これは、スマートコントラクトのために実行される仮想マシンによって生成されるユニークなアドレスのようなもので、主にその後の状態の持続的な追跡と記録のためです。

2、去中心化のオラクルシステム。主にオフチェーンデータの信頼できる取得と検証を担当し、従来のオラクルとは異なり、このAIエージェントに適応したオラクルは、データ収集層、意思決定コンセンサス層、実行フィードバック層など、複数のエージェントの組み合わせアーキテクチャを構築する必要があります。これにより、エージェントのオンチェーンに必要なデータとオフチェーンの計算および意思決定がリアルタイムで届くことができます。

3、去中心化のストレージDAシステム。AIエージェントの実行時の知識ベースの状態には不確実性があり、推論プロセスも一時的であるため、LLMの背後にある重要な状態ベースと推論経路を記録して分散ストレージシステムに保存し、コストを制御可能なデータ証明メカニズムを提供して、公的なブロックチェーンの検証時にデータの可用性を確保する必要があります。

4、ゼロ知識証明ZKPプライバシー計算層。TEEやFHEなどのプライバシー計算ソリューションを含む連携が可能で、リアルタイムのプライバシー計算 + データ証明検証を実現し、エージェントがより広範な垂直データソース（医療、金融）を持つことができ、その上により専門的なカスタマイズサービスエージェントが登場することになります。

5、クロスチェーン相互運用性プロトコル。これはMCPオープンソースプロトコルが定義したフレームワークに似ていますが、この相互運用性ソリューションは、エージェントの実行、伝達、検証に適応するリレーと通信スケジューリングメカニズムを必要とし、エージェントが異なるチェーン間で資産移転と状態同期の問題を解決できるようにします。特に、エージェントのコンテキストやプロンプト、知識ベース、メモリなどの複雑な状態を含む場合です。

……

私の見解では、真のweb3 AIエージェントの攻克の重点は、AIエージェントの「複雑なワークフロー」とブロックチェーンの「信頼検証フロー」をできるだけ適合させる方法にあるべきです。これらの増分ソリューションが、既存の古い物語プロジェクトからのアップグレードによって生まれるのか、新たに構成されたAIエージェントの物語トラック上のプロジェクトによって再構築されるのか、どちらも可能性があります。

これこそがweb3 AIエージェントが努力して構築すべき方向であり、AI + Cryptoという大きなマクロ物語の下での革新エコシステムの基本的な面です。関連する革新の開拓や差別化競争の壁が築かれなければ、web2 AIトラックの一挙一動がweb3 AIを揺るがす可能性があるのです。