フラグメント化されたエージェントエコシステムの課題
現在、AIエージェントの開発は、フラグメント化と相互運用性の欠如という重大な課題に直面しています。これらの課題は、堅牢でスケーラブルなAIシステムの構築を妨げています。
- 孤立したエージェント: エージェントはしばしばサイロ化された状態で動作し、コミュニケーションや情報の共有ができません。たとえば、CRMエージェントは、データウェアハウスエージェントによって発見された洞察に気づいていない可能性があり、機会損失や非効率につながります。
- 脆弱なツール利用: ツールやAPIを呼び出すための標準化されたプロトコルがないため、エージェントはメンテナンスと再利用が難しいハードコードされた統合に依存しています。これにより、変化する環境に適応し、新しいシステムと統合する能力が制限されます。
- 一貫性のないフレームワーク: さまざまなエージェントランタイムは、さまざまなモデルを採用し、エージェントをチャットボット、有向非巡回グラフ（DAG）、または再帰的プランナーとして扱います。この一貫性の欠如により、移植可能で相互運用可能なエージェントの作成が困難になります。
- プロトタイプ中心の開発: 多くのエージェントは、1回限りのプロトタイプとして設計されており、現実世界の展開に必要な堅牢性とスケーラビリティがありません。多くの場合、再試行、障害、調整、ロギング、スケーリングなどの重要な問題に対処できません。
- コラボレーションバックボーンの欠如: 中央イベントバス、共有メモリ、またはエージェントアクションの追跡可能な履歴がないため、コラボレーションと調整が妨げられます。情報はしばしば直接HTTP呼び出しに閉じ込められたり、ログに埋もれたりするため、エージェントの動作を理解してデバッグすることが困難になります。
解決策は、すべてのエージェントをモノリシックなプラットフォームに統合することではなく、オープンプロトコル、イベント駆動型アーキテクチャ、およびリアルタイム処理に基づいて共有スタックを構築することにあります。このアプローチは、相互運用性、スケーラビリティ、および回復力を促進します。
Agent2Agent：エージェントコミュニケーションの標準化
GoogleのA2Aプロトコルは、エージェントの相互運用性の問題を解決するための重要なステップです。これは、エージェントの出身地やランタイム環境に関係なく、エージェントを接続するための普遍的なプロトコルを提供します。A2Aは、エージェントの共有言語を定義することにより、次のことを可能にします。
- 能力の宣伝: エージェントは、
AgentCardを介してその能力をアナウンスできます。これは、エージェントが何ができるか、およびその操作方法を指定するJSON記述子です。これにより、他のエージェントがそのサービスを発見して利用できるようになります。 - タスクの交換: A2Aは、JSON-RPCを介したエージェント間の構造化された相互作用を促進します。ここでは、あるエージェントが別のエージェントに支援を要求し、その結果または成果物を受け取ります。これにより、エージェントは複雑なタスクで共同作業できます。
- 更新のストリーミング: エージェントは、サーバー送信イベント（SSE）を使用して、長時間実行または共同作業タスク中にリアルタイムフィードバックをストリーミングできます。これにより、透明性が確保され、エージェントは進捗状況を監視し、変更に対応できます。
- リッチコンテンツの交換: A2Aは、プレーンテキストだけでなく、ファイル、構造化データ、およびフォームの交換をサポートします。これにより、エージェントは複雑な情報を共有し、より広範なタスクで共同作業できます。
- セキュリティの確保: A2Aには、HTTPS、認証、およびアクセス許可に対する組み込みサポートが組み込まれており、エージェント間の安全な通信を保証します。これは、機密データを保護し、不正アクセスを防ぐために重要です。
Model Context Protocol：ツール利用とコンテキスト認識の実現
AnthropicのMCPは、エージェントがツールを使用し、外部コンテキストにアクセスする方法を標準化することにより、A2Aを補完します。これは、エージェントがAPIを呼び出し、関数を呼び出し、外部システムと統合する方法を定義し、現実世界と対話できるようにします。
A2Aがエージェント間の通信方法に焦点を当てているのに対し、MCPはエージェントが環境と対話する方法に焦点を当てています。これらの2つのプロトコルを組み合わせることで、接続されたエージェントエコシステムの包括的な設計図が得られます。
- MCPは、ツールと情報へのアクセスを提供することにより、個々のエージェントのインテリジェンスを強化します。
- A2Aは、エージェント間のコミュニケーションとコラボレーションを促進することにより、集合的なインテリジェンスを可能にします。
堅牢な通信インフラストラクチャの必要性
従業員が直接的な1対1のメッセージでのみコミュニケーションできる会社を想像してみてください。更新を共有するには、各人に個別にメッセージを送信する必要があり、複数のチームにわたるプロジェクトを調整するには、グループ間で手動で情報を中継する必要があります。会社が成長するにつれて、このアプローチはますます混沌として持続不可能になります。
同様に、直接接続に基づいて構築されたエージェントエコシステムは、脆弱になり、スケーリングが困難になります。各エージェントは、誰と話すか、その連絡方法、および利用可能な時期を知っている必要があります。エージェントの数が増えるにつれて、必要な接続の数が指数関数的に増加し、システムが管理不能になります。
A2AとMCPは、エージェントに通信して行動するための言語と構造を提供しますが、言語だけでは十分ではありません。エンタープライズ全体で多数のエージェントを調整するには、メッセージフローとエージェントの反応を管理するための堅牢なインフラストラクチャが必要です。
Apache KafkaとApache Flink：エージェント連携のバックボーン
Apache KafkaとApache Flinkは、スケーラブルなエージェント通信と計算をサポートするために必要なインフラストラクチャを提供します。Kafkaは分散イベントストリーミングプラットフォームとして機能し、Flinkはリアルタイムストリーム処理エンジンです。
LinkedInで最初に開発されたKafkaは、永続的で高スループットのメッセージバスとして機能し、システムがイベントストリームをリアルタイムで公開およびサブスクライブできるようにします。プロデューサーをコンシューマーから分離し、データが永続的、再生可能、およびスケーラブルであることを保証します。Kafkaは、金融システムから不正検出、テレメトリーパイプラインまで、さまざまなアプリケーションで広く使用されています。
同じくApacheプロジェクトであるFlinkは、ステートフルで高スループット、低レイテンシのイベント処理用に設計されています。Kafkaはデータの移動を処理しますが、Flinkはシステムを流れるデータの変換、エンリッチメント、監視、およびオーケストレーションを処理します。
KafkaとFlinkを組み合わせることで、強力な組み合わせが実現します。Kafkaは血流であり、Flinkは反射システムです。これらは、スケーラブルで回復力のあるエージェントエコシステムを構築するための基盤を提供します。
A2Aがエージェント世界のHTTPとして登場しているように、KafkaとFlinkは、スケーラブルなエージェント通信と計算をサポートできるイベント駆動型基盤を形成します。これらは、直接的なポイントツーポイント通信では解決できない問題を解決します。
- 分離: Kafkaを使用すると、エージェントは誰が出力を消費するかを知る必要はありません。イベント（たとえば、
"TaskCompleted"、"InsightGenerated"）をトピックに公開すると、関心のあるエージェントまたはシステムがサブスクライブできます。 - 可観測性と再生可能性: Kafkaは、すべてのイベントの永続的で時系列順のログを保持し、エージェントの動作を完全に追跡可能、監査可能、および再生可能にします。
- リアルタイムの意思決定: Flinkを使用すると、エージェントはイベントストリームにリアルタイムで反応し、動的な条件に基づいてアクションをフィルタリング、エンリッチ、結合、またはトリガーできます。
- 回復力とスケーリング: Flinkジョブは、個別にスケーリングし、障害から回復し、長時間のワークフロー全体で状態を維持できます。これは、複雑なマルチステップタスクを実行するエージェントにとって不可欠です。
- ストリームネイティブな調整: 同期応答を待つ代わりに、エージェントはイベントストリームを介して調整し、更新を公開し、ワークフローをサブスクライブし、状態を共同で進めることができます。
要約すると：
- A2Aは、エージェントがどのように話すかを定義します。
- MCPは、エージェントが外部ツールでどのように行動するかを定義します。
- Kafkaは、エージェントのメッセージがどのように流れるかを定義します。
- Flinkは、これらのフローがどのように処理、変換され、意思決定に変わるかを定義します。
エンタープライズグレードのAIエージェント向けの4層スタック
A2AやMCPのようなプロトコルは、エージェントの動作と通信を標準化するために不可欠です。ただし、Kafkaのようなイベント駆動型サブストレートとFlinkのようなストリームネイティブランタイムがなければ、これらのエージェントは孤立したままになり、柔軟に連携したり、正常にスケーリングしたり、時間経過とともに推論したりすることはできません。
エンタープライズグレードの相互運用可能なAIエージェントのビジョンを完全に実現するには、4層スタックが必要です。
- プロトコル: A2AとMCPは、エージェントのコミュニケーションとツールの使用のwhatを定義します。
- フレームワーク: LangGraph、CrewAI、およびADKは、エージェントの実装とワークフロー管理のhowを定義します。
- メッセージングインフラストラクチャ: Apache Kafkaは、エージェント間のメッセージとイベントのflowをサポートします。
- リアルタイム計算: Apache Flinkは、リアルタイムでデータストリームを処理および変換することにより、thinkingをサポートします。
この4層スタックは、AIエージェント向けの新しいインターネットスタックを表しており、インテリジェントであるだけでなく、共同的で、観測可能で、本番環境に対応できるシステムを構築するための基盤を提供します。
接続されたエージェントエコシステムに向けて
私たちは、ソフトウェアの進化における極めて重要な瞬間にいます。オリジナルのインターネットスタックがグローバルな接続性の新しい時代を切り開いたように、AIエージェント向けの新しいスタックが登場しています。このスタックは、推論、決定、および行動を行うために連携する自律システム向けに構築されています。
A2AとMCPは、エージェントの通信とツールの使用のためのプロトコルを提供し、KafkaとFlinkは、リアルタイムの調整、可観測性、および回復力のインフラストラクチャを提供します。これらを組み合わせることで、切断されたエージェントデモからスケーラブルでインテリジェントな本番環境グレードのエコシステムへの移行が可能になります。
これは単にエンジニアリング上の課題を解決することだけではありません。境界を越えて連携し、洞察とアクションフローをリアルタイムで提供し、インテリジェンスが分散システムになることを可能にする、新しい種類のソフトウェアを可能にすることです。
このビジョンを実現するには、オープンに、相互運用可能に、そして前回のインターネット革命の教訓を念頭に置いて構築する必要があります。次にエージェントを構築するときは、エージェントが何ができるかを尋ねるだけではありません。それがより大きなシステムにどのように適合するかを尋ねてください。
- 他のエージェントと通信できますか？
- 他のエージェントとのアクションを調整できますか？
- 変化する状況に進化し、適応できますか？
未来は単にエージェント駆動型ではありません。それはエージェント接続型です。