Agentic Enterprise のリソースとコストの最適化
自律エージェントは、確定的自動化とは異なる方法で Salesforce リソースを消費します。エージェントのワークロードは、固定されたトランザクションバインド型ではなく、予測不能で継続的です。リソースとコストの最適化の柱のコストあたりの価値テーゼは、エージェント型エンタープライズに直接継承されます。リソースの効率化とは、すでに支払った業務量を使用することであり、コストの最適化とは、収益を得られる自律的な業務量に意図的に支出を向けることです。エージェントは両方の形状を変更します。効率的なエージェント設計により、消費が抑制され、価格設定モデルの選択、総所有コスト (TCO) モデリング、財務ガバナンスにより、コストと価値の整合性が維持されます。このドキュメントでは、リソースの効率性とコストの最適化を 1 つの決定として扱います。これは、エージェントにとって、これらは同じ目標の 2 つのビューであるためです。
エージェントは消費の予測可能性を変更します。従来のApexプロセスは、既知のリソース コストを持つ既知のレコード セットに対して実行されます。エージェントは会話形式で操作し、エージェントが ToDo を通じて行った理由に応じて 1 つの会話で多数のアクションを実行できます。各アクションでは、会話全体でガバナ制限が累積されるのではなく、独自のトランザクション内でガバナ制限が消費されます。1 ターンのコンテキスト準備では、ユーザーの質問に応じて 200 件のレコードまたは 20,000 件のレコードを照会できます。エージェントは自律的に行動でき、プロアクティブなエージェント、送信エージェント、スケジュール済みエージェントはユーザートランザクション中のみではなく継続的に行動できるため、API 消費が加速します。この予測不能性により、エージェントリソース管理は、消費の急増後に調整するのではなく、設計によって防御する必要があります。
コスト面も同じくらい変わります。自律エージェントでは、従来のシート単位のライセンスとは異なる動作の消費ベースの価格設定が導入されます。Agentforce には、Flex Credits と Per-Conversation の 2 つの消費ベースの価格設定モデルが用意されています。各エージェントリリースで次のいずれかのモデルが選択されます。組織では一度に 1 つの消費モデルを使用しますが、使用量が測定されていない場合にユーザーごとに 1 か月ごとに提供される [ユーザー単位] アドオンを消費モデルと組み合わせることで、顧客対応エージェントは Flex Credits または会話単位で実行し、従業員は測定されていないライセンスを使用できます。Data 360 はベクトル検索と取得でエージェントのグラウンディングを強化し、データ処理能力を消費します。MuleSoft は API 容量を使用するエージェントインテグレーションを可能にします。これらの変動コストはエージェントの使用量に応じて増加するため、固定の年間サブスクリプションではなく、変動に合わせて構築された財務ガバナンスを必要とする投資パターンが作成されます。
Agentic Enterprise でコストを最適化してビジネス価値を実現するように設計されたソリューションでは、レコードを一括処理するアクション、統制のとれたコンテキストウィンドウ、キャッシュにより、エージェントの消費効率が維持されます。また、適切な価格設定モデル、完全な TCO モデリング、およびビジネス結果に対する継続的なコスト監視を通じて、意図的に支出を調整します。このアライメントがないと、エージェントリリースで比例値を示さずにコストが蓄積され、無制限のループ内で理由付けを行うエージェントは、人間の監視が介入するよりも早くクレジットを消費する可能性があります。エージェントをガバナ制限内に収める同じ効率化作業によって、エージェントの用語で表された柱となるテーゼであるクレジット予算内に抑えることができます。
このドキュメントでは、エージェントが表示されるときの変更について説明します。パフォーマンスの最適化、ガバナ制限、TCO分析、ライセンスの規律など、すべてのSalesforceソリューションに適用される基本的なリソースとコストの最適化パターンについては、「リソースとコストの最適化」の柱を参照してください。エージェント ガバナンスと人的監視は、自律動作の安全と説明責任を維持するプログラム コンポーネントをカバーするTrustとFairnessの柱に接続します。
エージェントのリソース消費は、フローや Apex と同じプラットフォームの仕組みに従いますが、予測できない会話主導の呼び出しにより、消費の予測が難しくなり、防御パターンが必要になります。最適化の責任は、アクションチェーン全体のガバナ制限予算、API 消費、応答遅延、Data 360 グラウンディングの効率、コンテキストウィンドウ管理、およびエージェントが重複なしで拡張できる構成可能な設計に及びます。各責任は、技術的な責任を負う前にコストあたりの価値で決定されます。エージェントはすべての会話で非効率性を繰り返すためです。
エージェントは、Apex、フロー、およびインテグレーションをトリガーするアクションを呼び出します。1 つの会話で、エージェントが複雑な ToDo で判断した多数のアクションを実行できます。基本的な規律は Salesforce ソリューションと同じですが、予測不能な呼び出しパターンによってリスクが高まります。50 件のケースを更新するエージェントが 50 件の個別のコールではなく 1 件のアクションを呼び出すように、コレクションを受け入れるアクションを設計します。レコードコレクションを操作する 1 つのアクションでは、同じ作業で消費する Salesforce Object Query Language (SOQL) クエリとデータ操作言語 (DML) 操作が大幅に減ります。アクションチェーン全体で SOQL 予算を意図的に管理します。10 ～ 15 個のアクションを呼び出すワークフローでは、各アクションで複数のクエリが実行される場合に 100 個のクエリの同期制限に達するか超える可能性があるためです。リレーションクエリを使用して、1 つのステートメントで親データと子データを取得し、同じ会話内のアクション間でプラットフォームキャッシュにキャッシュされたデータを参照します。この 2 つのプラクティスにより、マルチアクションチェーンが予算内に収まります。
同期制限を超えるエージェント操作をキュー可能またはバッチ Apex に移行します。この場合、非同期コンテキストにより、作業で使用できる SOQL と CPU のヘッドルームが約 2 倍になります。1,000 件のリードのスコアリングや過去のケース全体のセンチメントの分析などの大規模な分析操作は、会話をブロックするのではなく非同期処理に属します。大規模言語モデルの推測自体は Salesforce の外部で実行され、Apex CPU 時間ではなく Flex Credit を消費するため、プロファイルする CPU バジェットは、アクション ロジック、データ変換、エージェントがトリガーするインテグレーションによって消費されます。親レコードが何千もの子レコードに関連付けられているデータスキューシナリオでは、エージェントに特に注意が必要です。この脆弱性は、確定的クエリでは決して要求されない方法で、エージェントが数万件の関連レコードを含む取引先の「すべての履歴」を要求する可能性があるために発生します。ハードな子レコード制限とページネーションを使用してアクションを設計し、データ量がデータスキューしきい値を超えた場合にサンプリングを適用します。これらの制限により、予測できない要求が無制限のクエリになるのを防ぎます。Agentforceセッション トレーシングは、セッション レベルでクエリを過度に消費するアクションを特定し、Scale CenterはApexトランザクション全体のパフォーマンスと組織の健全性を監視します。
エージェントアーキテクチャでは、エージェントが自律的に動作し、プロアクティブなエージェントやスケジュール済みエージェントの場合は継続的に動作するため、ユーザー駆動型ワークフローよりも API の消費時間が短くなります。エージェントの表示方法によって、API 業務量の削減方法が決まります。REST API を介して呼び出されたエージェントは、会話のターンごとに 1 つのコールを消費します。標準コンポーネントを介してLightningページに埋め込まれたエージェントは、インタラクションごとにAPIコールを消費しませんが、コストは選択した価格設定モデルのクレジットまたは会話で測定されます。直接RESTコールを実行するカスタムLightning Webコンポーネントは、API容量を消費します。Lightning Data Service ワイヤ アダプタ上に構築されたコンポーネントは、API コールを発行するのではなく、共有クライアント側キャッシュからサービスを提供するため、Lightning Data Service ワイヤ アダプタ上に構築されません。パイロット中のイベントモニタリングで使用量を監視して、完全なロールアウトの前に実際の使用量を把握します。
イベント駆動型パターンは、無駄なエージェント API 消費に対する最大のテコです。条件にエージェントの介入が必要な場合にプラットフォームイベントを公開すると、実行する作業があるかどうかに関係なく API コールを消費するスケジュール済みポーリングを回避できます。また、変更データキャプチャチャイベントに登録しているエージェントは、外部オーケストレーターが毎日行うポーリングコールを使用せずに現在のコンテキストを維持します。コストあたりの値ロジックは直接的です。作業がないアンケートは、無駄に費やされた業務量であり、実際の変更に対してのみ発生するイベントは、実際の作業に対してのみ費やされた業務量です。取得増強生成では、Data 360 に対するベクトル検索ごとに計算が消費されるため、エージェントが実際に使用した結果のみを返すように取得制限を設定します。
エージェントターンの遅延は、LLM 推測時間、アクション実行時間、Data 360 クエリ時間、インテグレーション時間の合計です。そうでない場合は、最も長い並列ブランチと連続するステップになります。遅延は、コストだけでなくエクスペリエンスの懸念事項でもあります。これは、対応に時間がかかると、リソースが長時間開いたままになり、ストレスを感じたユーザーが解決済みの会話よりも多くの会話を開始するためです。プロンプトが短いほど応答が高速になるため、冗長な指示、冗長な例、不要なコンテキストを削除します。コンテキストを選択すると、遅延と回答品質の両方が改善されます。一方、徹底的なコンテキストダンプではノイズのみが追加されます。インデックス付けされた項目、一括処理、およびキャッシュされた参照データに対する選択的な SOQL によってアクションを迅速化します。3 秒のアクションは、推測がどれほど高速であってもボトルネックになるためです。クエリプランツールを使用してアクションクエリを検証し、アクションの遅延を増大するテーブル全体のスキャンを特定します。
エージェントビルダーオーケストレーションは、連動関係が存在しない場合にアクションを並列で実行できます。たとえば、取引先の詳細と関連商談を同時に取得するには、両方を合計するよりも、どちらか遅いほうの時間が必要になります。複数のダウンストリーム システムにファン接続するコールの場合、Agentforce を MuleSoft などのインテグレーション プラットフォームと組み合わせます。エージェントは 1 つのアクションを呼び出し、MuleSoft が要求を受信してバックエンド システムに並列コールを発行し、1 つの集約された応答を返します。プラットフォームキャッシュにより、繰り返される要求の推測とクエリの遅延が解消されます。また、長いドキュメント分析などの緊急でない作業を非同期で処理することで、エージェントは会話を開いたままではなく、要求をすぐに確認し、準備が整ったら結果を返すことができます。
Data 360 では、モデルのトレーニングデータのみではなく、現在のデータでエージェントの応答をグラウンディングするベクトル検索が提供されます。この効率は、グラウンディング品質と、グラウンディング品質を達成するために使用するコンピューティングの両方に影響します。チャンク、埋め込み選択、メタデータの絞り込み、結果の制限は、最も価値のある決定です。Knowledgeを意味的に意味のあるセグメントにチャンクします。チャンクが小さすぎると、1つの質問に対して多数の取得が強制され、大きすぎるチャンクでは、関連性のないコンテキストが薄れ、推測に消費されるトークン・バジェットが増加します。質問-回答の類似性はドキュメント分類とは異なる動作をするため、エージェントが実際に照会する方法に一致する埋め込みモデルを選択し、代表的なクエリに対してその選択を検証します。セマンティックな類似性をメタデータ検索条件と組み合わせることで、どんなに一致が近くてもおすすめから販売終了商品を除外するなど、類似性に関係なくビジネス上の制約が保持されます。エージェントが使用する結果のみを返すように top-k 制限を設定します。たとえば、5 件の結果が回答を示している場合、50 件を取得すると、45 件の未使用の結果がグラウンディングペイロードとトークンバジェットに追加されます。
統合プロファイルは、1 つの Data 360 統合プロファイルを照会するエージェントが、すべてのターンで取引先、取引先責任者、商談、ケース、キャンペーンに対して個別のクエリをオーケストレーションするのではなく、1 回の操作で完全な顧客コンテキストを取得するため、リソース効率に優れています。規制要件が要求する地域で Data 360 インスタンスを設定し、特定の管轄区域のデータを処理するエージェントが個人データを保持するインスタンスを照会できるようにします。
大規模言語モデルのコンテキストウィンドウには有限数のトークンが保持され、その予算を管理することで、業務量を使い果たしたり、推測コールのコストを水増ししたりすることなく、長い会話の一貫性を保つことができます。恣意的に切り捨てるのではなく、意図的に優先順位を付けます。最近の会話履歴が最も優先され、現在のレコードの状態や権限などの重要なビジネスデータが 2 番目に優先され、古い履歴はスペースが許す場合にのみ含まれます。最初の数ターン後に、最初の会話を簡潔な概要にまとめ、完全な逐語的な履歴を保持せずに重要な事実を保持します。この概要では、 トークン予算 を増やすことなく継続性が維持されます。ToDo で 8 個が必要な場合にレコードの 50 個すべての項目を運ぶ応答では、会話またはグラウンディングに適切に割り当てられるコンテキスト予算が使用されるため、拡張コンテキストは、すべてのコールで完全な履歴を再生するのではなく、オンデマンドで照会される外部メモリとして Data 360 またはカスタムオブジェクトに保存され、各アクションから不可欠な項目のみが返されます。
再利用可能なコンポーネントからエージェントを構築することで、開発コストとメンテナンスコストを削減できます。一度作成して再利用する機能は、同じ機能をすべてのエージェントに再実装して個別に管理するよりも、その存続期間にわたってはるかに安価です。レコードの操作、承認、通知、検証をカバーする一元化されたアクションライブラリにより、プラットフォームチームは、すべての消費エージェントで一貫した動作、セキュリティ、パフォーマンスを維持できます。また、数週間かけてカスタムアクションから構築するのではなく、数日で新しいエージェントを構築できます。明確なドメイン境界を持つフォーカスされたスペシャリストエージェントは、1 人のユニバーサルエージェントがすべてのシナリオを試みるよりもコンテキストが狭く、動作が明確になります。また、エージェントビルダーのオーケストレーションは、ToDo がドメインをまたがるとスペシャリストを調整します。プロンプトビルダーの検証済みプロンプトテンプレートでは、グラウンディング、推論、応答の形式に関する実証済みのパターンが取得されるため、開発が加速しても品質の一貫性が維持されます。また、Data 360 の共有Knowledgeベースでは、多くのエージェントが 1 つのソースからグラウンディングされるため、各エージェントを変更することなく、すべてのコンシューマーに更新が一度に届きます。
エンタープライズチームは、1 つの単一エージェントを構築するのではなく、複数のエージェントを組み合わせて構成することが多くなっています。オーケストレーターエージェントが要求を分解してスペシャリストサブエージェントに委任したり、会話がドメイン間を移動したときにスペシャリストエージェントが相互に引き継ぎます。この構成では、1 つのアクションに封じ込められるのではなく、オーケストレーションのオーバーヘッド、エージェント間のTrust、および状態ハンドオフがチェーン全体ですべての化合物を引き渡すため、1 人のエージェントが直面する以上のリソースとコストの問題が発生します。オーケストレーションプロンプトは、オーケストレーターに基礎となる ToDo についても理由を尋ねるのではなく、インテントとルーティングの分類に限定して狭くします。これは、オーケストレーターが関連するコンテキストを持つサブエージェントにその理由が属するためです。また、使用事例でオーケストレーターからサブエージェントへのネストよりも深いネストが明らかに必要でない限り、チェーン深度を制限します。各サブエージェント応答は、外部 API 応答と同様に信頼できない入力として処理します。アクションを実行する前に、想定される形状とビジネスルールへの準拠を検証します。項目レベルセキュリティと共有をエージェントアクションごとに個別に適用します。
未加工の会話履歴を転送するのではなく、レコード ID、ToDo の概要、関連項目の構造化されたハンドオフペイロードを使用して、受け取り側のエージェントが必要とする状態のみを渡します。これにより、チェーン全体のトークン予算が制御され、個別のトランザクションでハンドオフを存続させる必要がある場合は、Data 360 またはカスタムオブジェクトでエージェント間セッション状態が保持されます。ガバナ制限は会話ごとに 1 回ではなくエージェントごとに適用されるため、チェーン内のすべてのエージェントが独自の SOQL、DML、CPU 予算を使用します。オーケストレーターと 3 人のサブエージェントのチェーンでは、これらの制限がそれぞれ 4 回消費され、チェーンが深いほど消費がさらに増えます。同じ乗算でコストが上昇するため、非境界チェーン深度はガバナ制限よりもコストリスクが大きくなります。
1 つのサブエージェントのタイムアウトがチェーン全体の失敗に連鎖しないように、サブエージェントが失敗した場合、タイムアウトした場合、または信頼性の低い結果が返された場合にオーケストレーターが実行するアクションを定義します。チェーン内のどのエージェントが原因で遅延やコストの急増が発生したかの診断には、別々のエージェントセッション間でログを手動で関連付ける必要があるため、接触するすべてのエージェントの要求を、ハンドオフペイロードを介して伝播された共有追跡 ID と関連付けます。
失敗したアクションと失敗した子エージェントコールは信頼性に影響するだけではありません。再試行するたびに、失敗した試行にすでに費やされた SOQL、DML、CPU 作業が再実行され、マルチエージェントでは、失敗したダウンストリームエージェントの数とこのコスト化合物がチェーニングされるためです。消費ベースの価格設定では、同じ失敗化合物が計算と同様に使用されます。再試行されたアクションでは、Flex Credits のクレジットが再利用されます。信頼性とコストの両方を考慮して再試行ロジックを設計します。コールアウトタイムアウトやロックの競合などの一時的な失敗と検証エラーや不正な形式の入力などの論理的な失敗を区別してから、対応方法を決定します。一時的な失敗は 1 回限りの再試行で済む場合がありますが、論理的な失敗は繰り返しでまったく同じ失敗をし、代わりにすぐにエスカレーションする必要がある保証された繰り返し失敗の予算のみが消費されます。
アクションあたりの再試行回数を 2 回または 3 回に制限し、即座の再呼び出しではなく、それらのアクション間に指数関数的なバックオフを適用します。これは、SOQL または DML 負荷の高いアクションで無制限またはタイトループの再試行を行うと、1 つのトランザクション内の同期制限を使い果たしたり、マルチエージェントの会話全体で累積チェーンバジェットおよび累積クレジット支出で燃え尽きたりする可能性があるためです。insert ではなく更新/挿入ロジックを使用する要求 ID や外部 ID などの緊急キーを使用して、再試行で 1 回成功したコールと同じ終了状態になるようにアクションを設計します。これにより、重複レコードを作成するのではなく同じレコードを更新します。緊急性のないアクションでは、重複する下流レコードによってリソース消費を 2 倍にするか、請求済みアクションまたは 1 回しか実行されていない作業の会話を 2 倍にします。
チェーン内のエージェントごとの完了状態を追跡します。1 人のエージェントのアクションは、下流のエージェントが失敗する前に DML を正常にコミットできます。また、すでに成功したことを把握している失敗ハンドラーは、チェーン全体を再起動して再請求するのではなく、失敗ポイントを補償または再開できます。制限された再試行の実行中にエンドユーザーに再試行または処理中の状況が表示される。これは、ユーザーが無音を確認して要求を繰り返すと、まったく新しい会話と新しいアクションセットがトリガーされ、元の試行のリソースと請求コストが重複するためです。
このドキュメントで説明されているリソース最適化パターンは、エージェントが本番で実行しているときに、エージェントが実際に SOQL クエリ、CPU 時間、DML 行、トークンをどこで消費しているかをアーキテクトが確認できる場合にのみ役立ちます。アクションごとおよびセッションごとの表示がない場合、制限違反または遅延の回帰は、原因となったチェーンのアクションまたはエージェントまで追跡する方法のない症状として表示されます。この懸念事項は、コスト監視と財務ガバナンスの下でDigital Walletが提供する支出の可視化とは異なります。Digital Walletでは、エージェントが消費したクレジットまたは会話の数が表示され、ツールでは、それらが消費された理由が個々のクエリ、DML行、またはアクションのレベルで示されます。適切なツールは、理論上最適なツールではなく、特定の顧客の組織とサポート契約で実際に付与される内容によって決まります。そのため、デフォルトで使用可能な最も機能的なツールを使用するのではなく、ライセンスとアクセス階層に合わせて推奨を選択してください。
すべてのアーキテクトは、各アクションとサブエージェントの呼び出しの開始時と終了時に起動するカスタムプラットフォームイベントを作成できます。これらのイベントは、標準プラットフォーム機能のみを使用して会話全体の実行を追跡し、カスタムオブジェクトへのアクションレベルのログ記録と組み合わせて、各アクションの実行時の SOQL クエリ数、CPU 時間、DML 行数、ヒープ使用量を取得します。どちらのイベントもレポートまたは SOQL で照会でき、エディションやアドオンライセンスに関係なく、すべての組織にベースライン診断機能を提供します。パイロット中の API 消費を追跡するために以前に導入されたイベント監視では、組織にそのアドオンが含まれる顧客のエージェントセッション全体のリソース使用状況パターンの集計も表示されるため、アーキテクトは一度に 1 つずつ診断するのではなく、多くの会話でどのワークフローがガバナ制限に向かっているかを特定できます。スケールセンターでは、ガバナ制限に近づいているトランザクションを詳細に追跡できます。通常、この制限はサポート契約を介してアクセスするか、サポート契約を付与する取引先層で直接利用できます。
エージェントのバージョン管理は、独立して制御されたロールアウト、ロールバック、比較を可能にし、有効なエージェントへの投資を保護しながら改善します。カスタムメタデータ型とプロンプトビルダーを使用して可能な限り設定を行い、管理者が開発サイクルなしでプロンプトテンプレートとアクションの選択を調整できるようにします。パイロット A/B テスト機能を使用して、一部のユーザーを実験バージョンに転送します。フルロールアウト前に品質、満足度、ToDo 完了を比較します。この比較では、実際の使用状況で改善を検証し、露出が制限されている間に回帰を検出します。コンポーネント間の明確なインターフェース契約を定義して、入力、出力、エラー、パフォーマンスの期待を指定して、実装をその実装に依存するエージェントを変更せずに置き換えることができます。
エージェントの経済性はビジネス価値に対して測定される総所有コストから始まりますが、自律エージェントの消費ベースの価格設定により、コスト側では従来のライセンスとは異なる動作が行われます。選択する価格設定モデルは、エージェントのライフサイクル全体で何を最適化するかを決定するため、アーキテクチャに関する基本的な決定事項です。このセクションでは、価格設定モデル、エージェント実装の全体像、エージェント機能の構築と購入の決定を確立します。
Agentforce には 2 つの消費ベースの価格設定モデルがあり、組織は特定のエージェントの導入に対してこの 2 つのうちのいずれかを選択します。Flex Credits のエージェントアクションあたりの価格。これにより、アクションの効率がコスト管理の基準になります。会話あたりの価格設定では、会話の長さや複雑さに関係なく、会話ごとに定額料金が請求されるため、会話の封じ込めに役立ちます。ユーザーごとのサブスクリプションでは、3 つ目の消費モデルではなく従業員向けのアドオンとしてエージェントの使用量が測定されません。また、各インタラクションを最小限に抑えるのではなく、ライセンスを持つユーザーがエージェントを積極的にエンゲージすることで価値が得られるため、最適化の重点が消費効率から採用に移行します。同じ組織で 2 つの消費モデルは混在していませんが、使用量が測定されていない場合にユーザーごとに 1 か月ごとに提供される [ユーザー単位] アドオンを消費モデルと並べて、顧客対応エージェントが Flex Credits または会話単位で実行し、従業員が測定されていないライセンスを使用できるようにします。
Flex Credits では、アクションコストは定義されたトークンの上限までアクションごとに固定されます。トークンベースの推測価格設定とは異なり、クレジットコストはプロンプトの長さやモデルの複雑さによって変動しないため、1 文の回答と複数段落の回答のコストは同じです。マルチアクションインタラクションでは各アクションのクレジットが消費されるため、データの取得、理由、レコードの更新を行うインタラクションでは 3 つのアクションのクレジットが消費され、取得拡張生成では、推論の前にベクトル検索とドキュメント取得でさらにアクションが追加されます。したがって、Flex Credits でのコストモデリングの前提条件は、ビジネストランザクションあたりの平均アクション数を理解することです。
会話あたりの価格設定では、会話ごとに定額料金が適用され、1 つのセッション内の複数のターンは 1 つの会話とみなされます。そのため、コスト管理は、個々のアクションを切り取るのではなく、1 つの会話内の問題を解決し、明確なセッション境界を定義することで行われます。Data 360 グラウンディングと MuleSoft インテグレーションでは、選択したモデルと共に独自の容量が消費されます。これは、埋め込み生成と類似性検索ではグラウンディングされたすべてのクエリのデータ処理能力が削減され、各外部アクションではソースシステムと対象システムの両方で API 容量が消費されるためです。
エージェントの実装の総所有コスト (TCO) は 6 つのカテゴリにまたがっており、6 つすべてをモデル化すると、信用見積が情報に基づいた投資判断に変換されます。開発コストには、エージェントの設計、プロンプトエンジニアリング、インテグレーション開発、テストが含まれ、単純な単一目的のエージェントから複雑なオーケストレーションを備えたマルチエージェントシステムまで多岐にわたります。推測コストは、選択した価格設定モデルに応じて異なり、Flex Credits の期待アクション量、[会話あたりの会話数]、または [ユーザーあたりのライセンスユーザー数] のモデル化が必要です。大規模なKnowledgeベースにグラウンディングされているエージェントの場合、グラウンディングを強化する Data 360 インフラストラクチャは、推測コストと同等かそれ以上のコストになる可能性があります。インフラストラクチャ コストには、Data 360とMuleSoftのライセンス、追加のSandbox、監視インフラストラクチャが含まれ、主に容量階層に基づく固定または段階的な機能が使用されます。運用コストには、監視操作、迅速な調整、インシデント対応、ユーザー サポートが含まれ、成熟したエージェント プログラムの場合、通常は年間開発コストの有意な割合に相当し、Salesforce固有の数値ではなくAIエージェントの一般的な業界ベンチマークと一致します。ガバナンス コストには、エージェントの自律性とリスクに応じて増大する安全審査、人の監視、監査ログ、コンプライアンス検証が含まれ、公正性の柱には不可欠なプログラム コンポーネントが含まれます。変更コストには、ユーザートレーニング、ビジネスプロセスの適応、組織の変更管理が含まれ、最も過小評価されているカテゴリチームです。
3 ～ 5 年間のコストを予測するスプレッドシートの TCO モデルを作成します。インタラクション量、アクション数、増加に関する前提条件を文書化します。感度分析を実行して合計に最も影響する仮定を特定し、それらの仮定に焦点を絞って検証します。Flex Credits、会話ごと、ユーザーごとの 3 つのコスト構造はすべて、確定する前に予測使用量に対してモデル化します。最適な構造は使用パターンによって異なり、誤った選択はエージェントが本番に移行すると時間がかかるためです。
エージェントの構築と購入の決定は、Salesforce の機能と同じロジックに従い、既成のソリューションの即時価値と、3 ～ 5 年間の TCO 対象期間でのカスタムビルドの正確な適合を比較します。コモディティワークフローは購入を推奨し、独自の差別化を促進するコア機能は構築を正当化します。Agentic Enterprise には、バイナリ選択肢ではなく、さまざまなオプションが用意されています。サービスエージェントやセールスデベロップメント担当などの事前作成済みのAgentforceエージェントは、迅速な導入とプラットフォームで管理される更新により、実証済みの機能を提供します。選択した価格設定モデルでクレジットを消費します。Salesforce 独立系ソフトウェアベンダー (ISV) コミュニティの市販のエージェントは AgentExchange を介して提供されます。ここでは、要件を満たすソリューションを構築するのではなく、すでに見つけることができます。エージェントビルダーで構築されたカスタムエージェントは、先行開発コストと継続的な迅速な調整およびメンテナンスで、適合率と競争力の差別化を実現します。プロンプトビルダーとアクション設定を使用して事前作成済みエージェントをカスタマイズすることで、エージェントを組織に適応させながら、完全なカスタム開発よりもコストを低く抑えることができます。コストだけでなく、タイム トゥ バリュー要件、内部開発能力、戦略的差別化、ベンダー連動性の許容度を加重し、要件の変更時に再評価できるようにアーキテクチャ決定レコードに決定を記録します。
基盤となるコスト構造を明確に理解したエージェントを実装することで、予算プールを枯渇させることなく自律的な機能を持続的に拡張できます。コストを制御するために調整するものは、アクションごとの支払、会話ごとの支払、ユーザーごとの支払で異なるため、最適化レバーは価格設定モデルによって異なります。この原則は 3 つとも一貫しています。つまり、有能なエージェントがビジネスの結果を返すよりも早く予算を静かに消費しないように、実際に提供された値に対して消費を調整します。
Flex Credits での最適化とは、品質を維持しながらビジネス結果あたりのアクションを最小限に抑えることです。FAQ への回答や通常のルックアップの実行で 3 つのアクションチェーンのクレジットが消費されないように、複数ステップのワークフローではなく 1 つのアクションで単純な要求を解決します。操作を 1 つのアクションに統合し、取得、分析、応答を組み合わせます。1 つのアクションが役立つ場合にそれぞれに料金を支払う必要はありません。同じクエリごとに新しいアクションを消費するのではなく、頻繁に尋ねられる質問がキャッシュから処理されるように、繰り返し要求の応答をキャッシュします。これは、クエリの有意義な共有が繰り返される場合に、このモデルで最も大きな効率性を発揮します。
会話あたりの価格設定では、最適化とは、複数の会話にまたがるのではなく、1 つの会話内で問題を解決することを意味します。セッションの境界とタイムアウトを設計して、会話が途中で終了し、新しい請求可能な会話を強制することなく適切に維持されるようにします。ToDo がフォローアップを必要とするのではなく最初の会話内で完了するように、エージェントの機能を最初の会話の解決に集中させます。最初の会話の解決率をコスト効率評価指標として追跡し、既存の会話コンテキストで処理できる可能性のある関連問題についてユーザーが個別の会話を開く範囲の拡大を回避します。
[ユーザーごとのサブスクリプション] では、使用量は測定されず、コストはシートごとに固定されるため、最適化はライセンスを持つ各ユーザーが返す価値を最大化することを意味します。ライセンスを持つユーザーが積極的にエージェントにエンゲージできるように採用に焦点を絞り、使用状況を追跡して対象を絞ったトレーニングやライセンスの再割り当てで使用頻度の低いユーザーを特定し、ユーザー母集団別にエージェントのやりとりをビジネス成果に関連付けて、価値の高い使用事例が投資を正当化し、価値の低い使用事例が最適化や異なる価格設定モデルの必要性を示すようにします。ライセンスが実際の使用量と一致するように、ケイデンスでユーザー母集団を確認します。
価格設定モデルに関係なく、アーキテクチャはコストに影響します。単純なロジックで初期ルーティングを処理するトリアージエージェントを実装し、複雑な処理が必要な場合にのみユーザーを専門エージェントに転送して、コストのかかる複雑な呼び出しが保証された場合にのみ実行されるようにします。ルールベースのロジックで十分な確定的シナリオでは従来の自動化に戻り、フローでより低コストで確定的パスを処理し、エージェントが本当に推論が必要なあいまいな状況を処理できるようにします。グラウンディングデータを選択的に取得し、エージェントの推論で必要な場合にのみベクトル検索とドキュメント取得を呼び出すことで、Data 360 で実際のニーズを追跡します。これらのパターンにより、作業の難易度に比例したアーキテクチャの推論コストと消費コストが保持されます。
エージェントが予測可能な要求-応答パターンに従わないため、自律エージェントのコスト監視は従来のワークロードよりも困難です。エージェントは複数ステップの推論を繰り返し、実行時の条件に基づいて適応的にツールを呼び出し、他のエージェントを調整できるため、予測が難しい変動性の高いクレジット消費が発生します。監視を行わない場合、エージェントが深い反復作業を実行すると、誰かが介入する前に大量のクレジットを消費し、非効率的なプロンプト設計や冗長な推論ループによってエージェント全体の予算が静かに使い果たされる可能性があります。そのため、ガバナンスを効果的に行うには、エージェントおよび業務ごとの消費量のリアルタイム表示、自動化されたアラート、エージェントが役立つ自律性を維持しながらコストの暴走を防ぐ制御が必要です。また、エージェントの財務ガバナンスには、静的なコンピューティングコストではなく、変動的な消費のために構築された明確な所有権と段階的な承認が必要です。
Salesforce Digital Walletは、Agentforce Flex Creditsなどの消費ベースの製品を監視するための組み込みツールです。Flex Creditsを使用している組織は、カスタム ダッシュボードを作成して提供内容を複製するのではなく、これを主要なコスト監視メカニズムとして確立する必要があります。Digital Walletは、アクション レベルの利用状況インサイト、エージェントごとの内訳(最も消費したエージェントを示す)、プロアクティブな消費アラート、パターン分析と予測の履歴トレンドを備えたほぼリアルタイムの消費データを提供します。監視を価格設定モデルと照合します。[Flex Credits]で、エージェント、ユーザー母集団、期間、アクション タイプ別に消費を追跡し、クレジット消費をビジネス トランザクションに接続するカスタム ダッシュボードでDigital Walletを補完します。[会話あたりの価格設定] で、会話量、平均長、完了率を監視します。[ユーザーごとのサブスクリプション] で、消費ではなく利用率を監視し、有効なユーザーとユーザーごとのビジネス価値を追跡して、ライセンス投資が比例した価値をもたらすことを示します。
インタラクションごとのコスト属性は、消費をビジネストランザクションに関連付け、解決済みケースごと、評価済みリードごと、または処理済み注文ごとのコストを明らかにします。これにより、ROI の計算と使用事例間の比較が可能になります。予算アラートは、予算の 70% や 85% などのしきい値で、消費が定義されたしきい値に近づいているときに通知をトリガーするため、最適化は制限に達する前に実行されます。組織全体ではなくエージェントごと、および使用事例ごとにアラートを設定して、問題を発生源にローカライズします。異常検知では、予期しない使用パターンや調査が必要な推論ループを示す、突然の消費急増が表面化します。コストダッシュボードをビジネスの関係者や技術チームと共有し、透明性によってエージェントのコスト意識を高めます。
エージェントアーキテクチャに支出をコミットする前に財務ガバナンスを適用します。選択した価格設定モデルでの 3 ～ 5 年間の予測 TCO、測定方法による期待されるビジネス成果、手動プロセスや従来の自動化などの代替方法との比較、品質、安全性、オペレーショナルリスクを対象とするリスク評価を対象とするエージェント投資のビジネスケースが必要です。部門が承認できる投資と役員の承認が必要な投資を分ける承認しきい値を定義して、高投資または高リスクのエージェントが適切な精査を受けられるようにします。パイロットでは、本番環境の投資判断と価格設定モデルの選択の両方に役立つ実際の消費、品質、採用が明らかになるため、本番環境に移行する前に前提条件を検証するパイロットリリースを義務付けます。
単一エージェントのレビューで見逃される最適化商談がポートフォリオビューに表示されるため、エージェントの資産はエージェントごとにではなくポートフォリオとして管理します。すべてのエージェントをまとめて確認し、コスト、利用状況、ビジネス価値、戦略的連携を比較して、導入率が低いエージェント、ROI が低いエージェント、機能が代替されているエージェント、またはコストが高すぎるエージェントを廃止する条件を定義し、価値の低いエージェントが予算を無期限に蓄積して消費しないようにします。1 回限りのクリーンアップではなく、進化する優先度に合わせて支出を調整する継続的なプラクティスとして、パフォーマンスの低いエージェントから価値の高い商談に投資を再割り当てします。
コスト割り当てによってエージェントの消費に対する説明責任が作成され、組織はプラットフォームの他の部分に適用される同じ 2 つのモデルを使用してコスト割り当てを実装します。Showback では、内部課金なしでビジネスユニット別にエージェントのコストがレポートされるため、コスト意識が高まり、内部請求の競合なしで最適化に関するディスカッションが行われます。チャージバックでは、実際のエージェントコストを消費するビジネスユニットに割り当てます。このコストは部門の予算に直接影響するため、最適化の動作が強化されますが、紛争を回避するための正確な割り当て方法が必要になります。ハイブリッドアプローチでは、大規模生産エージェントにチャージバックを適用し、試験的または小規模のエージェントにはショーバックを使用します。これにより、大規模な投資に対する説明責任とイノベーションに対する柔軟性のバランスがとれます。
エージェントアーキテクチャでは、大規模な言語モデルの推測は計算集約的であり、一部のエージェントは個別のユーザートリガートランザクションだけでなく継続的に実行されるため、独自の持続可能性に関する考慮事項が導入されています。プロアクティブエージェント、アウトバウンドエージェント、スケジュール済みエージェントはユーザーがいなくても機能し、会話型エージェントは多くのターンで消費を蓄積し、ベクトル検索、コンテキストの準備、アクションの実行はすべてインフラストラクチャの負荷を高めます。持続可能なエージェント設計により、応答性の高い環境を維持しながら、計算の無駄を最小限に抑えます。[Resource and Cost Optimization (リソースとコストの最適化)] の柱と同様に、1 つのソリューションとデータセンター排出量の関係は間接的です。1 つのテナントの効率によって排出量が直接削減されるわけではありません。ただし、すべてのテナントで効率が向上したことで、Salesforce はインフラストラクチャを高い稼働率で実行し、容量の拡張を延期できます。および [Resource and Cost Optimization (リソースとコストの最適化)] の柱にある基本的な Sustainability の実践と、それに続く効率戦略は、どちらも大規模言語モデルを利用した会話型システムに固有の内容に対応しています。また、コストも削減されるため、持続可能性とコストあたりの価値は異なる結果に対して測定される同じ規律になります。
推測はエージェントアーキテクチャの最もリソースを消費するコンポーネントであるため、プロンプトの長さ、コンテキストの使用状況、キャッシュによって効率が向上します。プロンプトを短くすると、応答の生成の計算は変更されませんが、事前入力の計算が比例して減少するため、冗長な命令と冗長な例を削除して、より少ないトークンでインテントを伝えるようにプロンプトを最適化します。最初の数ターン後に会話履歴を集計し、各アクションから重要な項目のみを返すことでコンテキストウィンドウを管理します。これにより、すべての推測に実行されるトークン予算は、会話に応じて増加するのではなく、常に制限されます。
ベクトル検索と統合プロファイルクエリでは計算リソースが消費されるため、グラウンディングコストを制御する同じ結果制限と絞り込みルールによって、グラウンディングのインフラストラクチャ負荷も軽減されます。エージェントが使用する結果のみを返すように top-k 制限を設定します。5 件の回答で 50 件を取得すると、グラウンディングトークンの予算を消費する未使用の結果が 45 件になり、メリットがないためです。また、類似度ランキングの前にメタデータ検索条件を使用して検索を絞り込みます。統合プロファイルを照会して、ターンごとに複数のオブジェクトに対して個別のクエリを発行するのではなく、1 回の操作で完全なコンテキストをアセンブルします。また、コンテキストのアセンブルが繰り返されてクエリが繰り返されないように、ユーザー親和性の高いエージェント (営業エージェントなど) のプロファイルをキャッシュします。
エージェントアクションは SOQL クエリ、DML 操作、CPU 時間を消費するため、[リソースとコストの最適化] の柱の一括処理、キャッシュ、非同期の規律がエージェントアクションに直接適用されます。コレクションを受け入れて、多数のレコードの更新が多数の操作ではなく 1 つの操作になるように設計し、リレーションクエリを使用して 1 つのステートメントで親データと子データを取得し、参照データをプラットフォームキャッシュにキャッシュし、レコードごとではなくコレクション全体で DML を一括処理します。同期制限を超える操作をキュー可能または一括処理 Apex に移行し、一括スコアリングや履歴強化などの緊急でない作業を非同期で処理し、可能な場合はエージェントがトリガーする一括処理をピーク時間外にスケジュールして、業務時間中に負荷が集中しないようにします。非同期実行を監視して、キューのバックログが障害になる前に業務量計画の必要性を示すようにします。
エージェントの消費パターンは使用量の増加に伴って変化するため、持続可能性のためには 1 回限りの通過ではなく継続的な監視が必要です。使用可能な利用状況テレメトリを使用して推測あたりの平均トークンを追跡し、プロンプトサイズの増加によって最適化の機会が出現するようにしたり、会話の長さの分布を監視して会話の境界が限定されないようにしたり、イベント監視でアクション実行頻度を分析して頻度の高いアクションを最適化の優先事項にしたりします。Data 360 クエリパターンを確認して、キャッシュまたは事前計算する価値のある一般的なクエリを見つけ、低いレートでしきい値のチューニングがトリガーされるようにセマンティックキャッシュヒット率を追跡し、テールレイテンシーでボトルネックが露呈するようにレイテンシーパーセントを測定します。エージェントの使用状況を定期的に確認し、スコープドリフトがないか確認します。たとえば、平均会話時間が数ターンから数か月にわたって長くなるエージェントを調査します。消費を計画に戻すようにエージェントの境界を調整します。これらの監視画面の中には、個別の推測ログとしてではなく、集計ダッシュボードで使用状況が公開されるものもあります。監視を設計するときに、設定で使用できる正確なテレメトリを確認してください。
リソースの最適化では、母集団の増加や使用事例の拡大に応じてエージェントアーキテクチャを拡張するかどうかを決定し、コストの最適化では、その拡張性が比例するビジネス価値を返すかどうかを決定します。次の 2 つの決定が 1 つの義務を形成します。
- アーキテクチャの効率性: 一括処理によるアクションの設計、アクションチェーン全体の SOQL の予算化、重い処理の非同期への移行、複合パターンとイベント駆動型パターンによる API 消費の最適化、優先度付けと集計によるコンテキストウィンドウの管理、再利用可能なコンポーネントからの合成可能なアーキテクチャの構築を行います。
- 財務ガイダンス: 価格設定モデルを意図的に選択し、確定する前に完全な TCO をモデル化し、ビジネス結果に対する消費を監視し、段階的な承認とポートフォリオレビューを通じて投資を管理します。
これらのパターンを習得している組織は、エージェントが返す価値に合わせて支出を維持しながら、プラットフォームの制約内で応答性の高いエージェント環境を提供します。
パフォーマンスの最適化、ガバナ制限、TCO 分析、ライセンス規律、コストガバナンスなど、すべての Salesforce ソリューションの基本的なリソースとコストの最適化ガイダンスは、[リソースとコストの最適化] の柱にあります。エージェント ガバナンス、人的監視、安全プログラム コンポーネントは、TrustとFairnessの柱に接続します。このドキュメントの詳細なエージェント実装ガイダンス (リソースの効率性、経済性、アクションの最適化、ガバナンス、持続可能性など) は、エージェントパターンライブラリで収集されます。