AIエージェントの新アーキテクチャ：A2A, MCP, Kafka, Flink

デジタル環境は、人間中心のウェブブラウジングから、多様なシステム間でシームレスに連携する自律型エージェントの領域へと進化しています。この変化は、新しいインフラストラクチャを必要とし、4つの主要なオープンソースコンポーネントで構成される魅力的なソリューションが形作られています。

• GoogleのAgent2Agent (A2A): エージェントの検出と相互作用を容易にするように設計されたプロトコル。
• AnthropicのModel Context Protocol (MCP): エージェントがツールと外部コンテキストデータを利用する方法を定義する標準。
• Apache Kafka: 信頼性が高く分離された連携を可能にする、堅牢なイベント駆動型通信バックボーン。
• Apache Flink: エージェントアクティビティのストリームを強化、監視、および操作するために不可欠な、リアルタイム処理エンジン。

この記事では、これらのテクノロジー間の相乗効果を探り、プロトコルのみに依存することの限界を強調し、このアーキテクチャが、孤立したボットから動的なインテリジェントエージェントエコシステムへの移行の基礎をどのように築くかを示します。

組織内でのAIエージェントの予想される普及は、ほとんどの企業が、単一の包括的なエージェントではなく、多数の特殊なエージェントを導入することを示唆しています。これらのエージェントは、コード生成、サポートチケット管理、顧客データ分析、従業員のオンボーディング、インフラストラクチャの監視などのタスクを自動化します。

ただし、現在のツールは、そのような将来をサポートするには不十分です。

課題は、エージェントがサイロ内で機能し、通信機能が欠如している’エージェントの島’の問題を超えています。それは、より広範なエコシステムの断片化を包含しています。

• エージェント間のコミュニケーションの欠如: エージェントは通常、隔離された環境内で動作します。顧客関係管理（CRM）エージェントは、データウェアハウスエージェントによって導き出された洞察を知りません。サポートエージェントは、監視エージェントによって検出された異常に対応できません。
• 脆弱でカスタマイズされたツールの使用: ツールまたは外部アプリケーションプログラミングインターフェイス（API）にアクセスするための標準化された方法がないため、エージェントはハードコードされた統合と再利用できないロジックに依存します。
• 一貫性のないフレームワーク: さまざまなエージェントランタイムは、多様なモデルを採用し、エージェントをチャットボット、有向非巡回グラフ（DAG）、または再帰的プランナーとして扱います。これにより、ポータブルな実行レイヤーまたは共有状態が存在しません。
• ノートブック環境に焦点を当てた設計: 多くのエージェントは、1回限りのプロトタイプとして開発され、線形、同期、および一時的な操作が特徴です。ただし、現実世界のシステムでは、再試行、障害、調整、ロギング、およびスケーリングの堅牢な処理が必要であり、これをサポートするインフラストラクチャが必要です。
• 共同バックボーンの不在: エージェントのアクティビティと根拠のイベントバス、共有メモリ、または追跡可能な履歴はありません。情報は、直接HTTP呼び出しに限定されるか、ログ内に埋もれています。

12-Factor Agentsプロジェクトで強調されているように、エージェントは、可観測性、疎結合、再現性、およびインフラストラクチャの認識を示す、クラウドネイティブの原則を遵守する必要があります。残念ながら、ほとんどは、手動で組み立てられ、独立して動作することを前提とした、脆弱なスクリプトとして構築されています。

これにより、非効率、努力の重複、および脆弱性が生じます。

Agent2Agentは、エージェントに検出と通信のための標準化されたプロトコルを提供することにより、この問題に部分的に対処します。ただし、表面的なデモンストレーションを超えて、本番システムが要求するスケーラビリティと信頼性に移行するには、プロトコルだけでは不十分です。包括的なインフラストラクチャが必要です。

現在のエージェントエコシステムは、強力でありながら孤立して互換性のないシステムを特徴とする、ウェブの初期段階を反映しています。標準プロトコルなしでサーバーと通信するブラウザが直面した初期の課題と同様に、今日のAIエージェントは、互いを効果的に発見、通信、および連携するのに苦労しています。

GoogleのAgent2Agent（A2A）：エージェント通信のためのユニバーサルプロトコル

GoogleのA2Aプロトコルは、この問題に対処するための重要な試みです。別のエージェントフレームワークではなく、その起源や展開環境に関係なく、あらゆるエージェントを接続するように設計されたユニバーサルプロトコルである点が異なります。

HTTPがウェブサイトの通信を標準化した方法と同様に、A2Aはエージェントの共通言語を定義し、次のことを可能にします。

• 機能の通知: AgentCardを介して、エージェントの機能と相互作用方法の概要を示すJSON記述子。
• タスクの送受信: JSON-RPCを利用した構造化された相互作用を通じて、1つのエージェントが支援を要求し、別のエージェントが結果または’成果物’で応答します。
• Server-Sent Events（SSE）によるアップデートのストリーム: 時間のかかるタスクまたは共同タスク中のリアルタイムフィードバックを容易にします。
• リッチコンテンツの交換: 単純なテキストを超えて、ファイル、構造化データ、およびフォームの交換をサポートします。
• デフォルトでのセキュリティの維持: HTTPS、認証、および権限の組み込みサポートを組み込みます。

A2Aの強みは、確立されたソリューションを再発明しないことにあります。HTTPやSMTPと同様に、確立されたウェブ標準を活用することで、採用が容易になり、統合が迅速化されます。

ただし、A2Aは、全体的なソリューションの1つの側面のみを表しています。

AnthropicのModel Context Protocol（MCP）：ツールの使用とコンテキストアクセスを標準化

AnthropicのMCPは、エージェントがツールを利用し、コンテキスト情報にアクセスする方法という重要な側面に対処します。MCPは、エージェントがAPIを呼び出し、関数を呼び出し、外部システムと統合するプロセスを標準化し、基本的に、それらが環境内でどのように動作するかを定義します。A2Aがエージェント間の通信を管理する一方で、MCPはエージェントの外部世界との相互作用に焦点を当てています。

要するに：

• MCPは、個々のエージェントのインテリジェンスを強化します。
• A2Aは、集合的なインテリジェンスを可能にします。

HTTPやSMTPが広範な成功を収めるために広範な採用、インフラストラクチャ、および開発者ツールを必要としたのと同様に、A2AとMCPは、その可能性を完全に実現するために、堅牢なエコシステムを必要とします。

A2AやMCPのような標準化の取り組みがあったとしても、重要な問題が残ります。エージェントの通信を、複雑で動的なエンタープライズ環境全体で効果的にスケーリングするにはどうすればよいでしょうか。これらのプロトコルによって定義された直接のポイントツーポイント接続のみに依存すると、スケーラビリティ、回復力、および可観測性に関連する課題が発生します。これは、堅牢な基盤となる通信インフラストラクチャの必要性を強調しています。

従業員が直接の1対1のメッセージでのみ通信できる会社を考えてみましょう。アップデートを共有するには、各個人に個別にメッセージを送信する必要があります。複数のチームにわたるプロジェクトを調整するには、各グループ間で手動で情報を中継する必要があります。

このようなシステムを数百人の従業員に拡張すると、混乱が生じます。

このシナリオは、直接接続に基づいて構築されたエージェントエコシステムで直面する課題を反映しています。各エージェントは、どのアージェントに連絡するか、その連絡方法、およびその可用性を知っている必要があります。エージェントの数が増加するにつれて、必要な接続の数が指数関数的に増加し、その結果、脆弱で管理が困難で、スケーラブルでないシステムになります。

A2AとMCPは、エージェントに通信と行動のための言語と構造を提供します。ただし、言語だけでは不十分です。企業全体で多数のエージェントを調整するには、メッセージフローとエージェントの応答を管理するためのインフラストラクチャが必要です。

KafkaとFlink：スケーラブルなエージェントコラボレーションのバックボーン

Apache KafkaとApache Flinkは、この重要なインフラストラクチャを提供します。

KafkaとFlinkの説明

Apache Kafkaは、もともとLinkedInで開発され、現在はApache Software Foundationプロジェクトであり、分散型イベントストリーミングプラットフォームです。これは、耐久性のある高スループットメッセージバスとして機能し、システムがリアルタイムイベントストリームを公開およびサブスクライブできるようにします。Kafkaは、プロデューサーをコンシューマーから分離し、データの耐久性、再生可能性、およびスケーラビリティを保証できるため、金融システム、不正検出、テレメトリパイプラインなどのさまざまなアプリケーションで広く使用されています。

Flinkも別のアパッチプロジェクトであり、ステートフル、高スループット、低レイテンシのイベント処理用に設計されたリアルタイムストリーム処理エンジンです。Kafkaがデータの移動を管理する一方で、Flinkは、システムを流れるデータの変換、強化、監視、およびオーケストレーションを処理します。

KafkaとFlinkを組み合わせることで、強力な組み合わせが実現します。Kafkaは血流として機能し、Flinkは反射システムとして機能します。

A2AがエージェントワールドのHTTPとしての役割を果たすのと同様に、KafkaとFlinkは、スケーラブルなエージェント通信と計算のためのイベント駆動型の基盤を提供し、直接のポイントツーポイント通信では対応できない課題に対処します。

• 分離: Kafkaを使用すると、エージェントは出力のコンシューマーを知る必要がありません。イベント（たとえば、'TaskCompleted'、'InsightGenerated'）をトピックに公開し、関心のあるエージェントまたはシステムがサブスクライブできるようにします。
• 可観測性と再生可能性: Kafkaは、すべてのイベントの耐久性のある時間順のログを保持し、エージェントの動作が完全に追跡可能、監査可能、および再生可能であることを保証します。
• リアルタイム意思決定: Flinkを使用すると、エージェントはイベントストリームにリアルタイムで反応し、動的な条件に基づいてアクションをフィルタリング、強化、結合、またはトリガーできます。
• 回復力とスケーリング: Flinkジョブは独立してスケーリングし、障害から回復し、複雑なマルチステップタスクを実行するエージェントにとって不可欠な、長期間実行されるワークフロー全体で状態を維持できます。
• ストリームネイティブな連携: 同期応答を待つ代わりに、エージェントはイベントストリームを介して連携し、アップデートを公開し、ワークフローをサブスクライブし、共同で状態を進めることができます。

要するに：

• A2Aは、エージェントがどのように通信するかを定義します。
• MCPは、外部ツールとの相互作用方法を定義します。
• Kafkaは、メッセージがどのように流れるかを定義します。
• Flinkは、これらのフローがどのように処理、変換され、意思決定に使用されるかを定義します。

A2AやMCPなどのプロトコルは、エージェントの動作と通信を標準化するために重要です。ただし、Kafkaのようなイベント駆動型の基盤とFlinkのようなストリームネイティブなランタイムがなければ、エージェントは孤立したままであり、効果的に連携したり、効率的にスケーリングしたり、時間をかけて推論したりすることはできません。

エンタープライズグレードのAIエージェントのための4層アーキテクチャ

エンタープライズグレードの相互運用可能なAIエージェントのビジョンを完全に実現するには、4層アーキテクチャが必要です。

• プロトコル: A2A、MCP – _何_を定義します。
• フレームワーク: LangGraph、CrewAI、ADK – _どのように_を定義します。
• メッセージングインフラストラクチャ: Apache Kafka – _フロー_をサポートします。
• リアルタイム計算: Apache Flink – _思考_をサポートします。

これらのレイヤーを組み合わせることで、インテリジェントであるだけでなく、協調的で、可観測性があり、本番環境に対応できるシステムを構築するための基盤を提供する、AIエージェント用の新しいインターネットスタックが形成されます。

私たちは現在、ソフトウェアの進化における重要な段階にいます。

HTTPやSMTPなどのプロトコルとTCP/IPなどのインフラストラクチャで構成される元のインターネットスタックが、グローバルな接続性の時代を先導したように、AIエージェント用の新しいスタックが登場しています。ただし、人間がウェブページをナビゲートしたり、メールを送信したりする代わりに、このスタックは、自律システムが連携して推論、決定、および行動するように設計されています。

A2AとMCPは、エージェントの通信とツールの使用のためのプロトコルを提供し、KafkaとFlinkは、リアルタイムの連携、可観測性、および回復力のためのインフラストラクチャを提供します。これらを組み合わせることで、切断されたエージェントのデモンストレーションから、スケーラブルでインテリジェントな本番環境グレードのエコシステムへの移行が可能になります。

この進化は、エンジニアリングの課題に対処することだけではありません。境界を越えて連携し、リアルタイムで洞察を提供し、行動を促進し、それによってインテリジェンスが分散システムになることを可能にする、ソフトウェアの新しいパラダイムを可能にすることです。

ただし、このビジョンには、積極的な開発が必要であり、オープン性、相互運用性、および以前のインターネット革命から学んだ教訓を強調する必要があります。

したがって、エージェントを開発するときは、より広範なシステム内での統合を検討することが重要です。効果的にコミュニケーションできますか？他のエージェントと連携できますか？変化する条件に適応し、進化できますか？

未来は、エージェントが搭載されているだけでなく、エージェントが接続されています。