翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

エージェントはマルチテナンシーを満たす

エージェントは、特定のドメインやビジネス上の問題のニーズをサポートするためにアセンブルされた一連の自律コンポーネントと見なされる構成要素と考えるのは簡単です。興味深いのは、これらのエージェントがプロバイダーによってどのようにパッケージ化および消費されるかについて考え始めるときです。多くの点で、エージェントはビジネスのコストと収益の源になります。エージェントプロバイダーは、サービスを利用するさまざまなペルソナ、ペルソナの消費プロファイル、およびエージェントプロバイダーがコンシューマーに合わせた料金モデルと階層化モデルを作成できるようにする収益化戦略を考慮する必要があります。

エージェントプロバイダーは、顧客のニーズを満たすためにエージェントをデプロイするための複数のモデルをサポートできます。次の図は、2 つの主要なエージェントデプロイモデルの概念図を示しています。

図の左側は、顧客専用エージェントモデルを示しています。エージェントプロバイダーは、オンボーディングされた顧客ごとに個別のエージェントインスタンスをデプロイしてエージェントを構築します。このアプローチでは、エージェントの能力と知識を取得する能力は、特定の顧客の環境の範囲に限定されます。これにより、専用カスタマー環境をサポートする複雑さと利点の一部を継承するカスタマーエクスペリエンスが表されます。

対照的に、図の右側にある図には、プロバイダーの環境にデプロイされた単一のエージェントがあります。エージェントは複数の顧客からのリクエストを処理し、すべての顧客の集合的なエクスペリエンスに基づいて進化し、学習します。追加される新しい顧客はそれぞれ、単にエージェントの別の有効なクライアントを表します。エージェントは、クライアントのニーズをサポートするために共有コンストラクトを使用して、サービスとしてのエージェント (AaaS) モデルのように実行されます。どちらの場合も、エージェントコンシューマーはアプリケーション、システム、またはその他のエージェントである可能性があります。

AaaS モデルを見るには、2 つの方法があります。上記のモデルは、すべてのお客様に同じエクスペリエンスを提供します。つまり、エージェントの内部には、リクエスト元のクライアントのコンテキストを考慮する専門分野のレベルは含まれません。一般的に、このモードでは、エージェントの範囲、目標、価値の性質が、すべてのクライアントに共通に適用されるリソース、知識、結果の共有セットを中心にしていることを前提としています。 

AaaS の代替アプローチは、クライアントのコンテキストがエージェントのエクスペリエンスと実装に影響を与えることです。次の図は、このコンテキストでの AaaS エージェントフットプリントの概念図を示しています。

この AaaS ビューでは、受信リクエストのオリジンとコンテキストがエージェントのフットプリントに大きく影響します。エージェントの基礎となる実装の一部であるリソース、アクション、ツールは、受信テナントリクエストごとに異なる場合があります。エージェントの価値は、テナントコンテキストを使用して、テナントの状態、知識、その他の要因の影響を受けるアクションや結果に到達する能力に関連しています。リクエストによってはテナントごとに独自の結果が得られる場合もあれば、テナントごとによりカスタマイズされた結果になる場合もあります。これにより、エージェントの学習能力に新しいディメンションが追加されます。これには、よりコンテキスト的になり、ターゲットを絞った成果を高める知識を取得して適用することが含まれます。

プロバイダーにとって、AaaS モデルには多くの利点があります。複数の顧客が 1 つのエージェントを消費しているため、プロバイダーはスケールメリットを実現し、運用効率を高め、コストを制御し、統一された管理エクスペリエンスを創出するより良い機会が得られます。これにより、エージェントビジネスの俊敏性、イノベーション、成長の可能性が高まります。

これらの品質は、Software as a Service (SaaS) モデルの採用を推進するのと同じ原則と重複しています。基本的に、AaaS モデルは、SaaS 環境で見られるのと同じスケール、耐障害性、分離、オンボーディング、運用属性の多くを継承するマルチテナントサービスとして構築されています。多くの点で、AaaS エクスペリエンスは SaaS プロバイダーが使用する戦略とプラクティスから大きく借用しますが、これらの用語を分離するのが合理的です。当社では、主にマルチテナントサポートを必要とするエージェントの構築と運用に伴う影響に重点を置いています。

すべてのユーザーを均等に扱うことができ、永続データ、機密データ、または顧客固有のデータを管理する必要がないシステムでは、テナンシーの概念はエージェントに最小限影響します。データの分離、カスタマイズ、コンテキスト認識を維持しながら複数の顧客にサービスを提供することが予想されるシステムでは、複数のテナントをサポートすることがエージェントの設計、戦略、目標の重要な要素になる可能性があります。次の図は、エージェント環境でマルチテナンシーを使用する方法を示しています。

この図の左側には、従来のマルチテナントアーキテクチャがあります。これには、ウェブアプリケーションと、ビジネスロジックを実装する一連のマイクロサービスが含まれます。複数のテナントがこの環境の共有インフラストラクチャを消費し、進化するテナント人口の変化するワークロードに合わせてスケーリングします。環境は、すべてのテナントに対して 1 つのウィンドウを通じて運用および管理されます。

このメンタルモデルがこの図の右側にあるエージェントにどのようにマッピングされるかを想像してみてください。1 つのエージェントは、1 つ以上のテナントによって消費される AaaS モデルを実行します。エージェントは、1 つのエージェントの 1 つのインスタンスが複数のテナントからのリクエストを処理する必要があるため、テナントコンテキストがそれらの間を流れる複数のプロバイダーからのものである可能性があります。

この図の真ん中の例は、エージェントが SaaS エクスペリエンス全体の一部であるハイブリッドモデルです。システムの一部の部分はより従来のモデルで実装されており、システムの他の部分はエージェントに依存しています。このパターンは、多くの SaaS サービス、特にエージェントエクスペリエンスに移行している組織で一般的である可能性があります。すべてのシステムが純粋な AaaS として配信されるわけではないため、このモデルが存続することは一般的です。また、マルチテナンシーは引き続きモデルのエージェントに適用されることに注意してください。エージェントはシステム内に埋め込まれていても、複数のテナントからのリクエストを処理する場合があります。

マルチテナンシーが本当に重要であるかどうかを尋ねるのは当然です。エージェントがリクエストを処理するため、テナンシーのサポートはほとんど効果がないと主張できます。ただし、マルチテナントエージェントの影響をより深く掘り下げると、テナントは、個々のテナントをサポートするようにツール、メモリ、データ、その他のエージェントパートへのアクセス、デプロイ、設定にエージェントがどのように影響するかに直接影響する可能性があります。テナンシーは、スケーリング、スロットリング、料金設定、階層化、その他のビジネス側面がエージェントのアーキテクチャにどのように適用されるかにも影響します。

もう 1 つの重要な点は、マルチテナンシーサポートを必要とするエージェントユースケースがあることです。課題は、マルチテナンシーがエージェントエクスペリエンスの全体的な設計とアーキテクチャをどのように形成するかを判断することです。一部のエージェントでは、マルチテナントサポートは差別化機能を表し、エージェントはターゲットを絞った結果をもたらすエージェントにテナント固有のコンテキストを適用できます。

以降のセクションでは、マルチテナント SaaS アーキテクチャを説明するために作成する用語と設計パターンがどのように役立つかを説明します。これらの概念は、有用な側面を借りることで AaaS モデルで採用できます。これにより、必要に応じてエージェント固有の新しい概念が導入されます。

ID、テナントコンテキスト、エージェントシステム

テナントコンテキストを個々のエージェントに追加するのは特に難しくありません。多くの場合、チームはユーザーとシステムをテナントにバインドし、テナント対応トークンをエージェントに渡す一般的なメカニズムに頼ることができます。これは、テナントコンテキストとアイデンティティが複数のエージェントをどのようにサポートしているかを考慮する場合に当てはまります。このモデルでは、テナントはすべてのコラボレーションエージェントにまたがる ID にバインドされている必要があります。

一般に、エージェントドメインには、エージェントシステムの現在および新たなニーズに沿った、よりクロスカットのアイデンティティモデルが必要です。エージェントプロバイダーには、オペレーティングシステムに付属する一意のセキュリティ、コンプライアンス、認可モデルをサポートする ID メカニズムが必要です。これは、システムが顧客または他のエージェントによって構成されている環境では特に困難です。オンボーディングされた各エージェントは、アイデンティティとテナントコンテキストをエージェントのインタラクションに接続する必要があります。次の図は、agent-to-agent (a2a) インタラクションの一部である潜在的なアイデンティティとテナントコンテキストの課題を示しています。

この図は、ここで説明したエージェントシステムの一部としてやり取りするプロバイダー構築のエージェントを示しています。ID とテナントコンテキストが改良されました。このシナリオは、複数のエントリポイントをサポートするエージェントシステムの例です。このシステムの各エージェントは、システムまたはユーザーを特定のテナントに解決するために独自の認証メカニズムが必要であることを前提としています。これらのエージェントがやり取りすると、テナントコンテキストは JSON ウェブトークン (JWT) に渡されます。JWT は、アクセスを許可し、テナントコンテキストをエージェントに挿入するために使用されます。

概念的には、このシナリオの主な違いは、エージェントが個別にデプロイして運用することです。つまり、各エージェントはアイデンティティを解決し、アクセスを許可できる必要があります。重要なのは、そのアイデンティティには、より広範なエージェントシステムのニーズを処理するための分散機能が必要であることです。また、エージェントがテナントコンテキストを共有する方法についても調整する必要があります。

SaaS ビジネス価値を AaaS に適用する

一般的に、as-a-service モデルでシステムを実行する場合、エクスペリエンスの性質と、その技術的および運用上のフットプリントがビジネス成果にどのように影響するかを考慮します。例えば、SaaS を採用する場合、組織は規模、運用効率、コストプロファイル、俊敏性の経済を活用して、成長、マージン、イノベーションを推進します。

AaaS として配信されるエージェントは、同様のビジネス成果を目標とする可能性があります。複数のテナントをサポートすることで、エージェントはリソースの消費をテナントアクティビティに合わせることができます。これにより、従来の SaaS 環境に伴うスケールメリットが得られます。AaaS を使用すると、組織はエージェントを頻繁にリリースし、エージェントプロバイダーの俊敏性を高める方法でエージェントを管理、運用、デプロイすることもできます。重要なのは、AaaS モデルがテクノロジーに依存しないことです。成長を促進し、導入を合理化し、運用を簡素化するビジネス戦略を作成および推進します。