AI エージェントは、自律的な問題解決、適応型ワークフロー、スケーラビリティを通じて企業の運営を変革する準備が整っています。しかし、真の課題はより良いモデルを構築することではありません。
エージェントはデータ、ツールへのアクセス、システム間で情報を共有する能力が必要であり、その出力は他のサービス（他のエージェントを含む）によって使用可能でなければなりません。これは AI の問題ではなく、インフラストラクチャとデータの相互運用性の問題です。コマンドのチェーンをつなぎ合わせる以上のものが必要であり、データのストリームによって駆動されるイベント駆動型アーキテクチャ（EDA）が求められます。
HubSpot の CTO Dharmesh Shah が言ったように、「エージェントは新しいアプリです。」この可能性を実現するには、最初から適切なデザインパターンに投資する必要があります。この記事では、EDA がエージェントをスケールさせ、現代の企業システムにおけるその完全な潜在能力を解放する鍵である理由を探ります。
EDA が次の波の AI にとって不可欠である理由を完全に理解するためには、まず AI がこの時点までどのように進化してきたかを見てみる必要があります。
AI の進化#
AI は二つの異なる波を経て進化し、現在は第三の波に入っています。最初の二つの波は新しい可能性を開きましたが、同時に重要な制限も抱えていました。
AI の第一波：予測モデル#
AI の第一波は、伝統的な機械学習を中心に展開され、狭く定義されたタスクのための予測能力に焦点を当てていました。
これらのモデルを構築するには、特定のユースケースのために特別に作成されたため、かなりの専門知識が必要でした。これらはドメイン特有であり、そのドメイン特異性はトレーニングデータに埋め込まれていたため、堅牢で再利用が難しいものでした。モデルを新しいドメインに適応させることは、しばしばゼロからのスタートを意味しました。このアプローチはスケーラビリティに欠け、採用を遅らせました。
AI の第二波：生成モデル#
深層学習によって駆動される生成 AI は、転換点を迎えました。
これらの生成モデルは、単一のドメインに制限されることなく、広範で多様なデータセットでトレーニングされ、さまざまな文脈で一般化する能力を持つようになりました。テキスト、画像、さらには動画を生成することができ、刺激的な新しいアプリケーションを開きました。しかし、この波には独自の課題も伴いました。
生成モデルは時間に固定されており、新しいまたは動的な情報を取り入れることができず、適応が難しいです。ファインチューニングはドメイン特有のニーズに対応できますが、高コストでエラーが発生しやすいです。ファインチューニングには膨大なデータ、かなりの計算リソース、そして ML の専門知識が必要であり、多くの状況では実用的ではありません。さらに、LLM は公開データでトレーニングされているため、ドメイン特有の情報にアクセスできず、文脈を必要とする質問に正確に応答する能力が制限されます。
例えば、生成モデルにユーザーの個人健康履歴、場所、財務目標に基づいて保険ポリシーを推奨するように依頼したとします。
このシナリオでは、LLM にプロンプトを与え、それが応答を生成します。明らかに、モデルは関連するユーザーデータへのアクセスがないため、正確な推奨を提供できません。それがなければ、応答は一般的であるか、完全に間違っているでしょう。
複合 AI がギャップを埋める#
これらの制限を克服するために、複合 AIシステムは、生成モデルをプログラム的ロジック、データ取得メカニズム、検証レイヤーなどの他のコンポーネントと統合します。このモジュラー設計により、AI はツールを組み合わせ、関連データを取得し、静的モデルでは実現できない方法で出力を調整することができます。
例えば、保険推奨の例では：
- 検索メカニズムが安全なデータベースからユーザーの健康と財務データを引き出します。
- このデータは、プロンプトの組み立て中に LLM に提供されるコンテキストに追加されます。
- LLM は組み立てられたプロンプトを使用して正確な応答を生成します。
このプロセスは ** 検索強化生成（RAG）** として知られ、静的 AI と現実のニーズの間のギャップを埋めるために、モデルのワークフローに関連データを動的に組み込むことを可能にします。
RAG はこのようなタスクを効果的に処理しますが、固定ワークフローに依存しており、すべてのインタラクションと実行パスは事前に定義される必要があります。この硬直性は、ワークフローを徹底的にコーディングできない、より複雑または動的なタスクを処理するのが実用的でなくなります。すべての可能な実行パスを手動でコーディングすることは労力がかかり、最終的には制限をもたらします。
固定フローアーキテクチャの制限は、第三の波の AI、すなわちエージェントシステムの台頭を促しました。
エージェント型 AI の台頭#
AI は長足の進歩を遂げてきましたが、固定システムや LLM の限界に達しています。
Google の Gemini は、より大きなデータセットでトレーニングされているにもかかわらず、内部の期待に応えられないと報告されています。OpenAI や次世代の Orion モデルでも同様の結果が報告されています。
Salesforce の CEO マーク・ベニオフは最近、The Wall Street Journal の「万物の未来」ポッドキャストで、私たちは LLM の限界に達したと述べました。彼は、未来は GPT-4 のようなモデルではなく、自律エージェントにあると信じています。
エージェントは新しいものを提供します：動的で文脈駆動のワークフロー。固定パスとは異なり、エージェントシステムはその場の状況に応じて次のステップを即座に決定します。これにより、今日のビジネスが直面する予測不可能で相互に関連する問題に取り組むのに理想的です。
エージェントは従来の制御ロジックを覆します。
厳格なプログラムがすべての動きを指示するのではなく、エージェントは LLM を使用して意思決定を行います。彼らは推論し、ツールを使用し、メモリにアクセスすることができます — すべて動的に。この柔軟性により、リアルタイムで進化するワークフローが可能になり、エージェントは固定ロジックに基づいて構築されたものよりもはるかに強力になります。
どのようにデザインパターンがよりスマートなエージェントを形作るか#
AI エージェントは、そのコア能力だけでなく、ワークフローとインタラクションを構造化するデザインパターンからも力を引き出します。これらのパターンにより、エージェントは複雑な問題に取り組み、変化する環境に適応し、効果的に協力することができます。
効果的なエージェントを可能にする一般的なデザインパターンのいくつかを見てみましょう。
反省：自己評価を通じた改善#
反省は、エージェントが自分の決定を評価し、行動を起こす前に出力を改善することを可能にします。この能力により、エージェントは間違いを見つけて修正し、推論を洗練し、より高品質な結果を保証することができます。
ツールの使用がエージェントの能力を拡張#
外部ツールとのインターフェースは、エージェントの機能を拡張し、データの取得、プロセスの自動化、または決定論的ワークフローの実行などのタスクを実行できるようにします。これは、数学的計算やデータベースクエリなど、厳密な精度が求められる操作にとって特に価値があります。ツールの使用は、柔軟な意思決定と予測可能で信頼性のある実行の間のギャップを埋めます。
目標を行動に変える計画#
計画能力を持つエージェントは、高レベルの目標を実行可能なステップに分解し、タスクを論理的な順序で整理できます。このデザインパターンは、複数のステップの問題を解決したり、依存関係のあるワークフローを管理したりするために重要です。
マルチエージェントコラボレーション：モジュール思考#
マルチエージェントシステムは、特定のタスクを専門のエージェントに割り当てることで問題解決にモジュールアプローチを取ります。このアプローチは柔軟性を提供します：タスク特化型エージェントに小型言語モデル（SLM）を使用して効率を向上させ、メモリ管理を簡素化できます。モジュール設計は、各エージェントのコンテキストを特定のタスクに集中させることで、個々のエージェントの複雑さを軽減します。
関連技術には、Mixture-of-Experts (MoE)があり、これは単一のフレームワーク内で専門のサブモデル、または「専門家」を使用します。マルチエージェントコラボレーションのように、MoE はタスクを最も関連性の高い専門家に動的にルーティングし、計算リソースを最適化し、パフォーマンスを向上させます。両方のアプローチは、独立して働く複数のエージェントを通じて、または統一モデル内でのタスク特定のルーティングを通じて、モジュール性と専門性を強調します。
問題をモジュール化されたコンポーネントに分解することは、メンテナンス、スケーリング、適応を容易にします。これらの専門化されたエージェントは、情報を共有し、責任を分担し、複雑な課題により効果的に取り組むために行動を調整します。
要するに、エージェントは単にワークフローを実行するのではなく、それについての考え方を再形成します。彼らは、スケーラブルで適応可能な AI システムを構築するための次のステップであり、従来のアーキテクチャの制約や LLM の現在の限界を超えています。
エージェント型 RAG：適応型および文脈認識型の検索#
エージェント型 RAG は、RAG をより動的で文脈駆動型に進化させます。固定ワークフローに依存するのではなく、エージェントはリアルタイムで必要なデータ、データの取得先、そしてタスクに基づいてクエリを洗練する方法を決定できます。この柔軟性により、エージェント型 RAG は、応答性と適応性が求められる複雑で多段階のワークフローを処理するのに適しています。
例えば、マーケティング戦略を作成するエージェントは、CRM から顧客データを引き出し、市場動向を収集するために API を使用し、新しい情報が出てくるにつれてアプローチを洗練させるかもしれません。メモリを通じてコンテキストを保持し、クエリを反復することで、エージェントはより正確で関連性のある出力を生成します。エージェント型 RAG は、検索、推論、行動を統合します。
スケーリングインテリジェントエージェントの課題#
エージェントをスケールすることは、単一のエージェントであれ、協力システムであれ、データにアクセスし、共有する能力に依存しています。エージェントは、意思決定を行い、行動を起こすために、他のエージェント、ツール、外部システムを含む複数のソースから情報を収集する必要があります。
エージェントを必要なツールやデータに接続することは、本質的に分散システムの問題です。この複雑さは、コンポーネントがボトルネックや硬直した依存関係を生み出さずに効率的に通信しなければならないマイクロサービスの設計で直面する課題に似ています。
マイクロサービスのように、エージェントは効率的に通信し、その出力が広範なシステム全体で有用であることを保証しなければなりません。そして、どのサービスでも、出力は単に AI アプリケーションに戻るべきではなく、データウェアハウス、CRM、CDP、顧客成功プラットフォームなどの他の重要なシステムに流れ込むべきです。
確かに、RPC や API を通じてエージェントとツールを接続することはできますが、それは密結合システムのレシピです。密結合は、スケール、適応、または同じデータの複数の消費者をサポートすることを難しくします。エージェントには柔軟性が必要です。彼らの出力は、すべてを硬直した依存関係にロックすることなく、他のエージェント、サービス、プラットフォームにシームレスにフィードされる必要があります。
解決策は何でしょうか？
イベント駆動型アーキテクチャを通じた緩やかな結合です。これは、エージェントが情報を共有し、リアルタイムで行動し、より広範なエコシステムと統合することを可能にする基盤です — 密結合の頭痛なしに。
イベント駆動型アーキテクチャ：入門#
初期の頃、ソフトウェアシステムはモノリスでした。すべてが単一の、緊密に統合されたコードベースに存在していました。構築は簡単でしたが、モノリスは成長するにつれて悪夢になりました。
スケーリングは鈍い道具でした：全体のアプリケーションをスケールしなければならず、たとえ一部だけが必要でも。これにより、膨れ上がったシステムと成長に対応できない脆弱なアーキテクチャが生まれました。
マイクロサービスはこれを変えました。
アプリケーションを小さく、独立してデプロイ可能なコンポーネントに分割することで、チームは全体のシステムに触れることなく特定の部分をスケールおよび更新できるようになりました。しかし、これにより新たな課題が生まれました：これらの小さなサービスが効果的に通信する方法は？
サービスを直接 RPC や API 呼び出しで接続すると、相互依存の巨大な混乱が生まれます。1 つのサービスがダウンすると、接続されたパスに沿ったすべてのノードに影響を与えます。
EDA はこの問題を解決しました。EDA は、緊密に結合された同期通信の代わりに、コンポーネントがイベントを介して非同期に通信できるようにします。サービスは互いに待つことなく、リアルタイムで起こっていることに反応します。
このアプローチにより、システムはより回復力があり、適応性が高くなり、現代のワークフローの複雑さを処理できるようになりました。それは単なる技術的な突破口ではなく、プレッシャーの下にあるシステムの生存戦略でした。
早期のソーシャルジャイアンツの興隆と衰退#
Friendster のような早期のソーシャルネットワークの興隆と衰退は、スケーラブルなアーキテクチャの重要性を強調しています。Friendster は早期に膨大なユーザーベースを獲得しましたが、彼らのシステムは需要に対応できませんでした。パフォーマンスの問題がユーザーを遠ざけ、プラットフォームは最終的に失敗しました。
逆に、Facebook はその機能だけでなく、スケーラブルなインフラストラクチャに投資したために繁栄しました。成功の重圧の下で崩壊することはなく、支配的な地位を確立しました。
今日、私たちは AI エージェントで同様の物語が展開されるリスクを抱えています。
早期のソーシャルネットワークのように、エージェントは急速な成長と採用を経験します。エージェントを構築するだけでは不十分です。真の問題は、あなたのアーキテクチャが分散データ、ツール統合、マルチエージェントコラボレーションの複雑さに対応できるかどうかです。適切な基盤がなければ、あなたのエージェントスタックは早期のソーシャルメディアの犠牲者のように崩壊する可能性があります。
未来はイベント駆動型エージェントにある#
AI の未来は、よりスマートなエージェントを構築することだけではなく、技術が進化するにつれて進化し、スケールできるシステムを作成することです。AI スタックと基盤となるモデルが急速に変化しているため、硬直したデザインはすぐに革新の障害となります。時代に遅れないためには、柔軟性、適応性、シームレスな統合を優先するアーキテクチャが必要です。EDA は、この未来の基盤であり、エージェントが動的な環境で繁栄しながら、回復力とスケーラビリティを維持できるようにします。
情報依存性を持つマイクロサービスとしてのエージェント#
エージェントはマイクロサービスに似ています：それらは自律的で、デカップルされ、独立してタスクを処理する能力があります。しかし、エージェントはさらに進んでいます。
マイクロサービスは通常、離散的な操作を処理しますが、エージェントは共有された文脈豊かな情報に依存して推論し、意思決定し、協力します。これにより、依存関係を管理し、リアルタイムデータフローを確保するための独自の要求が生まれます。
例えば、エージェントは CRM から顧客データを引き出し、ライブ分析を分析し、外部ツールを使用するかもしれません — すべての間に他のエージェントと更新を共有しながら。これらのインタラクションには、エージェントが独立して作業できるが、依然として重要な情報を流動的に交換できるシステムが必要です。
EDA は、この課題を「中枢神経系」としてデータの役割を果たすことで解決します。エージェントが非同期にイベントをブロードキャストできるようにし、情報が硬直した依存関係を生み出すことなく動的に流れることを保証します。このデカップリングにより、エージェントは自律的に機能しながら、より広範なワークフローやシステムにシームレスに統合できます。
文脈を保持しながらのデカップリング#
柔軟なシステムを構築することは、文脈を犠牲にすることを意味しません。従来の緊密に結合された設計は、ワークフローを特定のパイプラインや技術に結びつけることが多く、チームはボトルネックや依存関係を乗り越えなければなりません。スタックの一部の変更はシステム全体に波及し、革新やスケーリングの努力を遅らせます。
EDA はこれらの制約を排除します。ワークフローをデカップリングし、非同期通信を可能にすることで、EDA はスタックの異なる部分（エージェント、データソース、ツール、アプリケーションレイヤー）が独立して機能できるようにします。
今日の AI スタックを例に取ると、MLOps チームは RAG のようなパイプラインを管理し、データサイエンティストはモデルを選択し、アプリケーション開発者はインターフェースとバックエンドを構築します。緊密に結合された設計は、これらすべてのチームを不必要な相互依存に強制し、納品を遅らせ、新しいツールや技術が出現したときに適応を難しくします。
対照的に、イベント駆動型システムは、ワークフローが緩やかに結合されたままにし、各チームが独立して革新できることを保証します。
アプリケーションレイヤーは AI の内部を理解する必要はありません — 必要なときに結果を消費するだけです。このデカップリングは、AI の洞察が孤立しないことを保証します。エージェントの出力は、CRM、CDP、分析ツールなどにシームレスに統合され、統一された適応可能なエコシステムを作り出します。
イベント駆動型アーキテクチャを利用したエージェントのスケーリング#
EDA は、エージェントシステムへの移行の基盤です。
ワークフローをデカップリングしながらリアルタイム通信を可能にするその能力は、エージェントが効率的にスケールできることを保証します。ここで議論されているように、ここのプラットフォームのような Kafka は、エージェント駆動システムにおける EDA の利点を示しています：
- 水平スケーラビリティ：Kafka の分散設計は、新しいエージェントや消費者をボトルネックなしに追加できるため、システムが楽に成長します。
- 低遅延：リアルタイムのイベント処理により、エージェントは変化に即座に反応でき、迅速で信頼性の高いワークフローを保証します。
- 緩やかな結合：直接の依存関係ではなく Kafka トピックを介して通信することで、エージェントは独立してスケーラブルなままです。
- イベントの永続性：耐久性のあるメッセージストレージは、データが移動中に失われないことを保証し、高い信頼性のワークフローにとって重要です。
データストリーミングは、ビジネス全体でのデータの継続的な流れを可能にします。中枢神経系は、リアルタイムデータフローの統一された骨格として機能し、異なるシステム、アプリケーション、データソースをシームレスに接続して、エージェントの通信と意思決定を効率的に行えるようにします。
このアーキテクチャは、Anthropic のモデルコンテキストプロトコル（MCP）などのフレームワークに自然に適合します。
MCP は、AI システムを外部ツール、データソース、アプリケーションと統合するための普遍的な標準を提供し、最新の情報への安全でシームレスなアクセスを保証します。これらの接続を簡素化することで、MCP は開発の手間を減らし、文脈に基づいた意思決定を可能にします。
EDA は、MCP が解決しようとする多くの課題に対処します。MCP は、多様なデータソースへのシームレスなアクセス、リアルタイムの応答性、複雑なマルチエージェントワークフローをサポートするためのスケーラビリティを必要とします。システムをデカップリングし、非同期通信を可能にすることで、EDA は統合を簡素化し、エージェントが硬直した依存関係なしにイベントを消費し、生成できることを保証します。
イベント駆動型エージェントが AI の未来を定義する#
AI の風景は急速に進化しており、アーキテクチャもそれに合わせて進化する必要があります。
そして、企業は準備が整っています。Forum Ventures の調査によると、48% の上級 IT リーダーが AI エージェントを運用に統合する準備ができており、33% は非常に準備ができていると述べています。これは、スケールし、複雑さを処理できるシステムに対する明確な需要を示しています。
EDA は、柔軟で回復力があり、スケーラブルなエージェントシステムを構築するための鍵です。コンポーネントをデカップリングし、リアルタイムのワークフローを可能にし、エージェントがより広範なエコシステムにシームレスに統合できるようにします。
EDA を採用する者は、単に生き残るだけでなく、この新しい AI 革新の波で競争優位を得るでしょう。残りの者は？彼らはスケールできない自らの能力の犠牲者となり、取り残されるリスクを抱えています。
原文リンク：https://seanfalconer.medium.com/the-future-of-ai-agents-is-event-driven-9e25124060d6