エンタープライズ向けエージェント型は何をするのか？
Webアプリケーションの導入、機械学習の活用、ビジネスインテリジェンスの活用などを原動力として、長年にわたって多くのアーキテクチャ・パターン（レイヤー型、イベント駆動型、サービス指向型など）が登場してきました。今、私たちは、ビジネス・アプリケーションのための「エージェント型ワークフロー」を活用したアプリケーションの新しい時代を目の当たりにしています。しかし、どのようなエージェント型アーキテクチャが最適なのかについては、まだ結論が出ていません。
エンタープライズアーキテクチャの例
アーキテクチャのパターンが出現しつつある一方で、企業組織にとっての主要な要件を理解することは重要です。企業に共通するのは、多数のアプリケーションとサービスに対応する必要があるということです。通常、エンタープライズアプリケーションは、さまざまな様式（リレーショナル、グラフ、キーバリュー、ドキュメントなど）の多数のデータソースから、オンラインおよびオフラインのパイプラインを通じて、データとモデルを用いた複数のサービスからなるワークフローで、複雑なタスクを実行します。
私たちは、エンタープライズソリューションに「エージェント」要素が導入されることで、アプリケーションの性質は大きく変化すると予想されます。具体的には、アプリケーションに入力される入力の種類、データの処理方法、トランスフォーマー、通信方法、計算の分解方法、そして最終的にはアウトプットがどのように生成され、ユーザーに提示されるか、などです。例えば、チャットベースのアプリケーションだけでなく、私たちは、LLMが解釈するために使用される自然言語でのユーザー入力がますます多くなると予測しています。また、私たちは、データ処理パイプラインがLLMベースの演算子を使ってデータを抽出、処理、要約、視覚化することを予測しています。LLMは、ユーザーの意図を特定し、それに対応する計画を作成し、実行するために利用されるでしょう。
簡単に言えば、私たちは、データの取得方法や計算の実行方法に関して、「あらかじめデザインされたもの」から「その場でデザインされたもの」へ、そしてアプリケーションの「直接的な操作」から「協力的な」モデルへの移行を目の当たりにしているのです。
そのため、私たちはアプリケーション開発においてこのような進化を予測しています：
- 「非決定論的」と「決定論的」コンポーネントの間を計算処理が移動
- 「構造化」データと「記号的」知識が「高次元」データと「パラメトリック」知識と組み合わされる
- 独自の企業データ、サービス、モデルを「エージェント」が利用できる
- LLM、エージェント、サービスに関して、外部プロバイダーの活用が増加
以上のことはすべて、エンタープライズアーキテクチャやエージェントアーキテクチャにとって重要な意味を持ちます。
エージェントアーキテクチャの目的とは？
アーキテクチャ設計の目的は、アプリケーション間で共有されるデータとサービスを最適化することにより、全体のパフォーマンス、実用性、説明可能性を向上させること にあります。一方で、各アプリケーションは、それぞれのユースケースに特化した成果を得るために、データやサービスを調整・制御する必要があります。 そのために、アプリケーションは固有のビジネスロジックを持っています。
企業におけるアーキテクチャデザインの主な関心事は以下の通りです：
- 制御性（Controllability）：各アプリケーションやサービスの出力に対して、十分なガバナンス（管理・統制）を持つことができる能力。
- 設定可能性（Configurability）：既存のサービスをカスタマイズによって再利用できる能力。
- 可観測性（Observability）：主要なアプリケーションデータを取得・検査しテスト、デバッグ、説明できる能力。
- 測定可能性（Measurability）：主要なパフォーマンスデータを収集し、コストを含むシステムの性能指標を計算・把握できる能力。
- スケーラビリティ（Scalability）：データ、サービス、アプリケーションの規模や複雑さに応じて、期待されるパフォーマンスと品質要件に見合う拡張性を持つこと。
エージェント指向のアプリケーションにおいては、これらの懸念はそのまま エージェント指向アーキテクチャに引き継がれ、実行や統合の責任を負うことになりますが、同時に新たな課題も引き起こします。
企業をエージェント型に対応させるために
エンタープライズ向けのエージェント指向フレームワークにおける重要な要件は、既存のエンタープライズリソースを統合し、それらを「エージェント指向ワークロード」に対応できるように準備することです。 これは、新たな「エージェント指向アプリケーション」の基盤となるものであり、既存の独自データ、モデル、サービスの統合を含みます。
「エージェント型に対応させる」とはどういう意味でしょうか？それは、最低限、次の能力を備えていることを意味します：
- 企業内で利用可能なリソースを見つける
- 新しいリソースを随時発見する
- リソースをアプリケーションのニーズに合わせる
- リソースを統合し、ワークフローに活用する：
- それらのリソースを どのように活用するか
- データや作業リソースをどのようにやり取りするか
さらに、企業の文脈では、次の能力も意味します：
- 観察可能性と説明責任のために、リソースの使用（パーフデータを含む）を記録し、ログに残す
- 複数の目的（コスト、正確性、応答時間）に対してオプティマイザーでリソースの利用を最適化する
- 利用データから学び、上記のすべての側面を改善する（例：発見、マッチング、統合、オプティマイザー）
Blueのコンセプト
Blue の中心にあるのは、エンタープライズシステムがますます複雑で知的かつ動的なワークフローとどのように連携するかに対する、根本的な変化です。従来のエンタープライズアーキテクチャは、静的な構成、硬直したインターフェイス、あらかじめ定義されたロジックに大きく依存していました。対照的に、Blueは複合AIシステムのデザイン原則を導入しています。そこでは、モジュール化された相互運用可能なコンポーネント（エージェント、プランナー、レジストリなど）が、実世界の複雑さにリアルタイムで対応できるインテリジェントなワークフローとして構成されています。この設計は、決定論的システムとLLMベースの推論エージェントが、が協調しながら動作し、共通のインフラストラクチャと抽象化によって統合されます。これらの抽象化（レジストリなど）は、エンタープライズリソース（データ、モデル、サービスなど）を発見可能、再利用可能、エージェントシステムで制御可能にする鍵となります。次のセクションでは、これらの重要な抽象化の1つであるレジストリーに焦点を当てます。
レジストリ
レジストリは基本的に、リソースに関するレコードを保存するリポジトリです。例えば、データレジストリは、企業内のデータソースに関するメタデータを格納します。モデルレジストリは、企業内で利用可能な独自のモデルに関するメタデータを格納します。このように、レジストリは、既存のデータインフラへの重要なタッチポイントであり、それらを検索、発見、照合し、エージェントのワークフローに統合します。
リソースの種類に応じて、レジストリはさまざまな種類のデータ、メタデータ、プロパティ、ログを格納することができます。例えば、データレジストリは、テーブル、カラム、サンプル値、データベース接続情報、過去のクエリの名前と説明を持つことができます。エージェントレジストリも同様で、利用可能なエージェントの名前、その説明、設定を構成するプロパティ、入出力データのフォーマットと仕様、その他を格納することができます。
レジストリの重要な機能は、リソースの調査、発見、マッチングをサポートすることです。例えば、プランナーのようなコンポーネントは、プラン内の特定のタスクにリソースを見つけ、マッチングできる必要があります。そのために、レジストリを検索して、マッチするエージェントやサービスを見つけることができます。さらに、ログ（クエリログなど）と一緒にメタデータを利用することで、検索品質を向上させるために、リソースの表現を学習するモデルを構築することができます。
エージェントやサービスなどの計算リソースの場合、レジストリは、他のプロパティとともに、入出力パラメータ、包含/除外ルール、Dockerイメージなどの展開情報、展開設定も含むことができます。このような情報は、リソースの使用方法や通信方法を決定する際に使用することができます。例えば、レジストリには、パラメータの名前と説明、データタイプだけでなく、関連するサービスの接続情報（IPアドレスなど）も含めることができます。
データレジストリは通常、名前、説明、および、データスキーマとデータベース接続の詳細を含む、様々な粒度レベル（データベース内のテーブルなど）のデータに関する詳細を含みます。レジストリはまた、メタデータ（例えば、スキーマの詳細）、データコンテンツ（例えば、値）、構造要素（例えば、スキーマの関係）、およびログ（例えば、クエリの履歴）の学習された表現から得られる埋め込みをキャプチャするベクトルメタデータを組み込みます。さらに、データレジストリは、利用可能なインデックスなどの情報が格納される集中リポジトリの役割を果たします。この統一されたインターフェースにより、どのエージェントやコンポーネントも一貫性をもってシームレスに情報にアクセスし、利用することができます。
レジストリ内のロギング機能は、観測可能性やアカウンティングを向上させるだけでなく、最適化においても非常に重要です。このようなデータには、モデルレジストリのパフォーマンスメトリクスが含まれることがあり、オプティマイザーがデータやタスクに適したモデルを選択する際に非常に役立ちます。
開発者（およびエージェント）は、APIやウェブアプリケーションのような様々なインタフェースを介して、レジストリとインタラクションすることができます。新しいエージェントを登録したり、メタデータを更新したり、既存のエージェントから新しいエージェントを派生させたり、レジストリを閲覧したり検索したりすることができます。このインタフェースは、エコシステム内のエージェントを管理するための包括的な機能を提供します。
まとめ
レジストリは、企業をエージェント化する上で重要な役割を果たします。さまざまなレジストリを通じて、専有データ、サービス、モデルなどの企業リソースを発見し、エージェント型ワークフローに統合することができます。各レジストリは、プランナーのような高度なコンポーネントを含め、どのエージェントも利用することができます。
私たちは、「エージェント型ワークフロー」が真に企業に受け入れられるためには、多くの企業独自の要因を考慮する必要があると強く信じています。簡単に言えば、すでに存在するものを捨て去り、長年の投資と文脈を捨てて、完全に新しく始めることは現実的ではありません。
これらの設計目標を念頭に置き、私たちはこれらの懸念に対処する最初の試みを行い、Blue v0.9をリリースしました。しかし、これは始まりに過ぎません。私たちは、将来のバージョンを形作るためにコミュニティと関わっていきたいと考えています。
次回の記事
次回は、Blue のオーケストレーションの重要なコンセプトであるストリームについて紹介します。私たちは、ストリームがどのようにエージェント間の通信や調整を可能にし、データやサービスへのインタフェースを容易にするかを解説します。ストリームは、企業のリソースを統合するという重要な課題に対する私たちの答えになるでしょう。さらに、ストリームは、企業における再利用性と拡張性を促進するのに役立ちます。今後の投稿では、プランナーやオペレーターなど、Blueの他の重要なコンポーネントを取り上げ、最終的には私たちの青写真となるアーキテクチャ全体にまとめる予定です。
面白そうでしょう？今すぐ試してみたいですか？
レポジトリにアクセスし、インストール手順に従ってください：Blue v0.9
執筆者：Eser Kandogan、Megagon Labs
