エージェントの基礎

アーキテクチャの詳細について説明する前に、「エージェント」は多くのユースケースに適用できるオーバーロード用語であるため、エージェントが果たすさまざまな役割について概説する必要があります。分類に役立つ幅広い用語から始めましょう。

最外部レベルでは、まずエージェントのロールと性質を分類する必要があります。これは、エージェントがさまざまな問題に適用できる幅広いシナリオがあるため、困難です。ただし、この説明では、エージェントをアプリケーションまたはシステムに導入することの意味に焦点を当てます。このモデルでは、エージェントがシステムのエクスペリエンスを最も充実させる方法と場所を強調しています。選択したオプションは、エージェントのビルド、統合、さまざまなドメインやユースケースへの適用方法に影響します。次の図は、ビルダーが使用する 2 つのエージェントパターンを示しています。

図の左側には、インタラクションベースのエージェントがあります。このモードでは、エージェントは既存のシステムへのビューを作成し、基盤となるサービスとのインタラクションを調整して、目標または成果を達成します。重要なのは、システムの特徴と機能を推進するための代替アプローチとして、エージェントがシステムに追加されることです。たとえば、独立系ソフトウェアベンダー (ISV) に、オペレーションの実行に使用される UX を備えた会計システムがあるとします。インタラクションベースのエージェントは、これらの既存の機能とのやり取りを簡素化します。大まかに定義された目標を達成する方法を学ぶことではなく、既知の経路をオーケストレーションする方法を提供することです。

対照的に、図の右側にあるタスクベースのシステムは、異なるアプローチを表しています。そのシステムのエージェントは、知識と能力を使用して、タスクを完了し、ビジネス成果を促進する方法を学習します。両方のモデルがビジネス成果を達成すると主張できますが、タスクベースのモデルはエージェント自身に依存して成果を達成する方法を決定します。このようなエージェントは決定論的ではなく、学習して進化する能力に依存しています。対照的に、インタラクションベースのエージェントは、主に一連の既知の機能をオーケストレーションするように設計されています。これらの違いは、ビジネスをサポートするためにエージェントを構築、範囲指定、統合する方法に影響します。

また、エージェントのデプロイ方法とデプロイ場所を特徴付ける用語も必要です。エージェントがシステムのフットプリント内に存在する場所は、エージェントの構築、スコープ設定、保護方法に影響を与える可能性があります。次の図は、エージェントに適用できる 2 つの異なるモデルの概要を示しています。

図の左側には、3 つの異なるエージェントを持つデプロイシステムがあります。エージェントは、他のエージェントまたはアプリケーションである可能性のある外部クライアントに公開されます。このモデルでは、エージェントはパブリックエージェントと呼ばれます。 

対照的に、右側の図は、ソリューションの実装内のエージェントを示しています。この場合、ユーザーまたはシステムによって消費される一連のアプリケーションサービスがあります。これらのユーザーは、エージェントがエクスペリエンスの一部であることを認識せずにアプリケーションとやり取りします。その後、エージェントは基盤となるシステムのサービスによって呼び出され、オーケストレーションされます。この方法でデプロイされたエージェントは、プライベートエージェントと呼ばれます。

エージェントの価値の多くは、プロバイダーが他のサードパーティーエージェントと統合することを意図してエージェントを公開するパブリックモデルに焦点を当てています。その後、エージェントは相互接続されたサービスのメッシュまたはウェブの一部となり、まとめて多くのユースケースに対処できます。これらのエージェントは多くのドメインで使用できますが、business-to-businessユースケースは自然に適しています。次の図は、特定の問題を解決するコレクションエージェントをアセンブルするとどうなるかを概念的に示しています。

この図は、一連の目標を達成するために協力する 4 人のビジネスエージェントを示しています。エージェントをこのように構成すると、エージェントシステムを表し、そのようなシステムのさまざまな種類があります。これらは、一般的に 1 つのユニットとして消費されるコラボレーションエージェントのパッケージ化されたセットである可能性があります。または、ニーズに最適なエージェントの組み合わせを選択して選択するお客様が、システムを動的に組み立てることもできます。

どちらのアプローチも、エージェント統合のための実行可能なパスを提供します。一部のエージェントは、価値、到達範囲、影響を最大化できる特定のシステムに統合されることを期待して構築されています。このエージェントシステムの概念は、エージェントの取得方法についても疑問を投げかけます。これに対処する方法は多数あります。次の図は、トランザクションエクスペリエンスを通じてこれらのエージェントとシステムを作成する方法の例を示しています。

マーケットプレイスエクスペリエンスの 2 つの例を示します。左側では、マーケットプレイスを使用して事前にパッケージ化されたシステムを取得します。このシナリオでは、マーケットプレイスは、複数のエージェントの統合とオーケストレーションを必要とするより広範な目標に対応するシステムを検出してオンボードします。

右側の例は、エージェントが発見され、エージェントシステムに構成されるマーケットプレイスを示しています。このシナリオでは、お客様はニーズに合わせて互換性のある統合エージェントの任意のシステムを構築できます。この方法でエージェントをアセンブルできるかどうかは、個々のエージェントの互換性モデルと統合要件によって異なります。