エージェント型企業の信頼性

自律エージェントでは、従来の Salesforce の自動化とは根本的に異なる非確定的な実行パターンが導入されます。SalesforceフローとApexは、制御された条件下で繰り返し結果を生成する予測可能なパスに従いますが、エージェントは問題を動的に判断します。たとえば、同じ質問を 2 回行うと、実行パスや消費するリソースが異なり、結果が異なる可能性があります。この不確定性により、従来のテストおよび監視方法では対処できない信頼性の課題が発生します。

エージェントの信頼性障害モードは、Salesforce フロー障害や Apex 障害とはカテゴリ的に異なります。大規模言語モデル (LLM) 推測サービスは、Salesforce Platform とは異なる可用性特性を持つ外部連動関係を表します。エージェントは、プロンプトの指示にもかかわらず、予期される構造に違反する応答を生成することがあります。エージェントコンテキストの準備でガバナ制限が予測外に消費される。確定的クエリの範囲は明示的に制御できるが、エージェントは自由回答のコンテキストを要求できるため、無制限のデータ取得はエージェントにより深刻な影響を与える。

信頼性の高いエージェントアーキテクチャには、洗練されたエージェントから、コンテキストが削減されたシンプルなエージェント、確定的ルールエンジン、そして最終的にオムニチャネルを介した手動の引き継ぎまで、適切に機能縮退する多層フォールバックチェーンが必要です。プラットフォームイベントはチェックポイントパターンを使用して耐久性のある再試行キューを強化し、失敗したワークフローを前回成功したステップから再開できるようにします。Circuit Breaker は、プラットフォームキャッシュで LLM サービスの健全性をリアルタイムで追跡します。しきい値と設定のカスタムメタデータ型によってサポートされ、連続する障害の後にフォールバックパターンにルーティングされます。監視には、会話の成功率、平均障害間隔 (MTBF)、平均復旧時間 (MTTR)、グラウンディング精度を追跡する必要があります。Agentforce Observability では、セッショントレース、正常性と遅延の指標、およびエスカレーションとデフレクションのレートが提供されますが、MTBF、MTTR、グラウンディングの精度などの信頼性の指標は自分で測定する必要があります。

このドキュメントでは、エージェントが表示されるときの変更について説明します。すべてのSalesforceソリューション(サービスレベルオブジェクト(SLO)の設計、フォールトトレランス、拡張性、監視)に適用される基本的な信頼性パターンについては、「信頼性の柱」を参照してください。

Agentforce エージェントは、Salesforce フローや Apex とは異なる方法で失敗します。これらの障害モードを理解することが、信頼性アーキテクチャを形成する要素です。

LLM service unavailability: LLM 推測エンドポイントで遅延の急増や可用性の問題が発生することがあります。Agentforce は、Trust.salesforce.com で Analytics や他の Salesforce サービスと共に監視対象製品としてリストされています。ただし、詳細な LLM 推測遅延と要求ごとのパフォーマンス総計値は公開されません。しきい値と設定のカスタムメタデータ型に裏付けられた低レイテンシのリアルタイム状態用のプラットフォームキャッシュを使用して回路ブレーカーを実装し、LLM サービスの健全性を追跡します。プラットフォームキャッシュはベストエフォート型です。エントリは存続可能時間 (TTL) より前に消去できるため、キャッシュのみではなくカスタムオブジェクトなどの耐久性のあるストアでオープン/ストリップ状態を保持します。エンドポイントへの移動条件を調整します。連続する失敗の数 (5 など) や、ローリングウィンドウでしきい値を超えるエラー率などです。回線が停止したら、テスト要求が成功すると回復が示されるまで、回線を開いて、単純なプロンプト、キャッシュされた応答、手動のハンドオフなどのフォールバックパターンに転送します。
応答検証失敗: エージェントは、プロンプトの指示にもかかわらず、予期される構造に違反する応答を生成することがあります。エージェントが不正な形式の JSON を返したり、必須項目を省略したり、予期しないデータ型を含めたりすることがあります。プラットフォームキャッシュには検証済みの応答スキーマを保存できるため、迅速な検証が可能です。検証に失敗した場合は、検証エラーと正しい構造の例を含めて、絞り込まれたプロンプトで再試行します。再試行の最大回数 (3 ～ 5) を設定して、無限の再試行ループを回避します。
幻覚検出: グラウンディングデータが不完全な場合、エージェントは妥当だが誤った情報を生成します。「見つからない」を返す確定的クエリとは異なり、エージェントは推測でギャップを埋めます。Einstein Trust Layer Audit Trail では、すべてのプロンプト、マスクされたプロンプト、応答、有害性検出結果、ユーザーフィードバックが事後ガバナンス確認のために記録されます。ただし、ステップごとの推論トレースは取得されません。段階的な推論キャプチャでは、推論エンジンの実行を記録する Agentforce セッション追跡を使用します。エージェントに Data 360 (旧 Data Cloud) 取得拡張生成 (RAG) 取得ソースの引用を要求します。アクションを実行する前に、取得したソースに対してエージェントの請求を相互参照し、事実の偏差を把握します。インラインチェックは、すでにコンテキスト内にあるソースに対して実行されるため、遅延はほとんど発生しません。2 番目のモデルコールや外部サービスなど、個別の往復が必要な小切手は、コストがかかります。これらのチェックは、財務や注文の更新など、影響の大きい書き込み用に予約し、リアルタイムの会話中に非同期で実行します。
ガバナ制限の急増: エージェントコンテキストの準備で、会話フローに基づいて Salesforce オブジェクトクエリ言語 (SOQL) クエリ、CPU 時間、およびヒープメモリが予測外に消費されます。Proactive Monitoring は、Salesforce Success Plan の Signature Success (旧称 Signature Support) エンタイトルメントサービスです。Salesforce は、顧客の取引先を積極的に監視します。Proactive Monitoringは、すべてのお客様がセルフサービスで設定できるアラートではありません。セルフサービスガバナ制限の監視では、スケールセンターを使用して、制限に近づいているリソースを大量に消費するエージェントの操作を特定します。大きなレコードコレクションを取得するエージェントアクションにページネーションを実装します。頻繁にアクセスされる参照データには、プラットフォームキャッシュを使用します。
エージェントコンテキストのデータスキュー: 10,000件を超える商談がある取引先や、比較的大規模な活動履歴があるケースのコンテキストを取得するエージェントは、バッチApexと同じデータスキューの課題に直面します。範囲を制御する確定的クエリとは異なり、エージェントの推論では「すべての履歴」が予測不能に要求されることがあります。これを回避するには、適切なハードリミット (たとえば、親 1 人につき 200 子程度の上限) を使用してエージェントアクションを設計し、制限を超えた場合にサンプリング戦略を実装します。この上限は、エージェントのコンテキストに入力されるデータの量を制限します。選択的なインデックス付き検索条件と組み合わせると、制限が適用される前に親の歪んだ検索条件または集計で子セット全体がスキャンされるため、クエリ自体が安価に保たれます。

多層フォールバックチェーンを設計して、エージェントが完全に失敗するのではなく、機能を減らして機能を継続できるようにします。

フルコンテキストの主エージェント: Data 360 の完全なグラウンディング、広範な会話履歴、複雑な推論を備えた高度なエージェント。最高品質だがリソースを大量に消費し、障害リスクが最も高い。
コンテキストが縮小されたセカンダリエージェント: コンテキストが集約されたシンプルなエージェント (たとえば、過去 30 日間とすべての履歴、上位 5 件のベクトル検索結果と上位 20 件)。コンテキストが小さいほど、トークン数が少なく、推測が速くなり、失敗する可能性が低くなりますが、削減されたコンテキストでタスクに必要なデータがカバーされている場合に限ります。
確定的ルールエンジン: エージェントの推論に失敗したときに一般的なシナリオを処理する従来の Salesforce フローまたは Apex ロジック。ルールは新しい状況に適応できませんが、既知のパターンを確実に処理します。注文検証エージェントは標準入力規則に戻り、リードスコアリングエージェントはルールベースのスコア計算に戻ります。
オムニチャネルによる手動ハンドオフ: 自動オプションを使い切ったときに手動キューに転送します。スキルベースのルーティングを設定して、エスカレーションが適切な専門知識に到達するようにします。試行された戦略、エージェント用に計算した信頼性スコア、失敗の理由など、会話のコンテキストをすべて渡して、効率的な人間の介入を可能にします。

プラットフォームイベントによってトリガーされるSalesforceフローまたはApexでフォールバックロジックを実装します。各階層で成功した戦略が記録され、失敗パターンと代替の有効性が可視化されます。

このセクションのすべてのプラットフォームイベントパターンは、72 時間のリプレイ保持期間を提供する大規模なプラットフォームイベント種別を想定しています。標準ボリュームのプラットフォームイベントは 24 時間のみ保持されます。リプレイの耐久性が信頼性の要件となるすべてのエージェントの耐障害性、再試行キュー、チェックポイントパターンで大規模イベント種別を使用します。プラットフォームイベントでは、エージェントワークフローが障害を生き延びて自動的に復旧できるようにする耐久性のあるメッセージングが提供されます。

Checkpoint agent progress: 複数ステップのエージェントワークフローは、成功した各ステップの後にチェックポイントイベントを公開します。契約処理エージェントがドキュメントの抽出を完了し、抽出されたデータを使用して ContractParsed イベントを公開してから、条項分析に進みます。句の分析に失敗した場合、ContractParsed イベントを再生して、再解析せずに抽出されたデータから再開します。これは、チェックポイントペイロードでそのデータが伝送され、登録者が緊急の場合に機能します。これは、リプレイがワークフローをステップの途中で再開するのではなくイベントを再配信するためです。イベントペイロードにチェックポイントの状態 (相関関係 ID、完了したステップ、継続に必要な状態など) を保存します。
Retry queue with exponential backoff: Failed agent requests publish to AgentRetryRequested event with retry count in payload. (指数バックオフのある再試行キュー:失敗したエージェント要求がペイロードの再試行回数と共に AgentRetryRequested イベントに公開されます。)イベント登録者は、指数関数的なバックオフ遅延がある再試行 (30 秒、2 分、8 分、30 分など) を処理します。最大再試行回数 (通常は 5 回) の後、デッドレターキューとアラート操作に転送します。大規模プラットフォームイベントでは、72 時間のリプレイ期間が保持されます。エージェント再試行キューに大規模イベント種別を使用して、登録者が組織のメンテナンス期間やリリースのダウンタイム後に対応できるようにします。標準ボリュームのプラットフォームイベントは 24 時間のみ保持されます。
イベント駆動型オーケストレーション: エージェントワークフローを疎結合のイベントチェーンとして設計します。リード作成で LeadCreated が公開されます。リードスコアリングエージェントは、LeadScored を登録し、スコアリングして公開します。リードルーティングエージェントが LeadScored に登録し、適切なキューに割り当てます。各エージェントは失敗して個別に再試行できます。エージェントが 1 人でも失敗してもワークフロー全体がブロックされるわけではありません。下流のエージェントは連動関係が回復したときに処理します。
相関関係 ID 追跡: すべての関連イベントペイロードにカスタムフィールドとして相関関係 ID を含めます。Pub/Sub API by replayId (連続していない不透明な識別子) を使用してイベントをリプレイし、72 時間の保持期間内にワークフロー履歴を再構築します。相関関係 ID ベースのデバッグを有効にするには、受信イベントを replayId と相関関係 ID と共にカスタムオブジェクトに記録し、イベント間のトレーサビリティを有効にする登録者側のパターンを実装します。このロギングパターンは、ネイティブプラットフォームクエリ機能ではなく、自分で構築するカスタム実装です。

同期制限を超えるエージェント操作を非同期コンテキストに移行すると、ガバナ制限が高くなり、タイムアウトが長くなります。

Batch Apex for bulk agent operations: 1,000 件以上のレコードを分析するエージェントは、バッチ Apex を使用して、実行方法ごとに 200 件の SOQL クエリ、150 件の DML ステートメント (最大 10,000 DML 行)、60,000 ミリ秒 (60 秒) の CPU 時間を利用できます。リードスコアリングエージェントが夜間のリードインポートを処理している。過去のケース全体のケースセンチメント分析。完了したパイプラインを分析する商談販売予測。
複数ステップのワークフローのキュー可能チェーン: 複数の外部 API コール、大規模なデータセット分析、処理時間の長時間を要する複雑なエージェントワークフローでは、キュー可能 Apex チェーンを使用します。各 Queueable ジョブは 60 CPU 時間と 12 MB ヒープを取得します。1 つのジョブの制限を超えるワークフローでは、次のキューにチェーニングできます。カスタムオブジェクトの進行状況を追跡して、失敗したジョブを最後の完了したステップから再開できるようにします。
@future による単純な非同期ハンドオフ: 通知の送信、外部システムへのロギング、緊急ではない更新などの軽量なエージェント操作では、@future メソッドを使用します。Fire-and-Forget パターンは、ワークフローで結果を返す必要がなく、失敗を許容できる場合に適しています。

[Apex ジョブ] ページ ([設定] → [Apex ジョブ]) および Apex Flex キューを使用して、非同期処理能力を監視します。最大 5 個の同時一括処理ジョブでは、エージェントの並列処理が制限されます。その他のジョブは、状況が [保留中] の最大 100 個のジョブが保持される Apex Flex キューに追加されます。すべての非同期 Apex 種別 (バッチ、将来、キュー可能、スケジュール済み Apex) で、非同期 Apex 実行に対する組織の 1 日あたりの制限 (DailyAsyncApexExecutions) は同じです。この制限は、25 万または 200 倍のユーザライセンス数の大きい方です。頻度の高いエージェントポーリングを実行したり、登録者キューを再試行したりすると、キュー可能数によってこの割り当てがすぐに使い果たされる可能性があります。これを回避するには、これらのエンキューをバッチ処理または調整して制限内に収めます。これは、キュー可能のみの個別の割り当てとしてではなく、すべての非同期Apex種別に組織全体に適用されます。チームが業務量をプロアクティブに管理できるように、消費がこれらの制限に近づいているときにアラートを表示します。

非確定的動作に対処するテスト戦略を使用して、本番稼働前にエージェントのレジリエンスを検証します。

Full Copy Sandbox の負荷テスト: 完全なデータ量を使用して、本番規模の負荷でエージェントのパフォーマンスをテストします。ピーク需要に一致する同時会話をシミュレーションします。p95 および p99 の遅延を測定し、ストレスによるパフォーマンスの低下を特定します。ガバナ制限消費量がピーク負荷時にしきい値未満に抑えられていることを確認します。データ量がエージェントのパフォーマンスに直接影響するため、データ量を減らした Partial Copy Sandbox で負荷テストを行うと、信頼性が損なわれます。これらのテストを実行する前に、Salesforce から承認を受けます (パフォーマンステスト要求の場合は 1 週間前以上)。未承認のテストは調整またはブロックできます。
障害インジェクション: リカバリメカニズムを検証するための失敗を意図的に導入します。Circuit Breaker が監視するサービスレイヤーで LLM 推測障害をシミュレーションし、Breaker が有効化されることを確認します。SOQL 例外を挿入してエラー処理をテストします。テスト検証ロジックに対するエージェントの応答を破損する。ページネーションロジックをテストするためにデータスキュー (10,000 人以上の子を持つアカウント) を導入します。積極的なタイムアウトを設定して、タイムアウト処理と再試行戦略をテストします。
カオスエンジニアリング: プラットフォームイベント登録者をランダムに無効化してリプレイの回復をテストします。チェックポイントの再開をテストするには、実行中に非同期ジョブを終了します。外部システムに可変遅延を導入して、順次タイムアウト戦略をテストします。カオス実験では、現実的な障害の組み合わせでレジリエンスを検証します。ステージング環境で定期的な混乱の日をスケジュールし、エージェントが進化しても回復力を維持します。
長時間安定テスト: エージェントのワークロードを 72 時間以上継続的に実行し、時間ベースの障害を監視します。エラーが蓄積され、パフォーマンスが徐々に低下するのは、運転が継続されている場合のみです。CPU 時間のトレンドを追跡して、実行中の段階的な低下を特定します。

客観的な信頼性の測定を可能にするサービスレベルインジケーター (SLI) を定義します。SLO は、本番の失敗後ではなく、エージェントを作成する前に設定します。

会話成功率: エラーまたはタイムアウトなしで完了したエージェントの会話の割合。人間への適切な引き継ぎは、失敗ではなく成功として数えます。エスカレーションは、設計上の最終代替階層です。失敗したエスカレーションや意図しないエスカレーションを評価指標に含めます。丁寧なサインオフによって未解決の問題がマスキングされる可能性があるため、これは便利な信頼性シグナルですが、ユーザーエクスペリエンスにとって不完全なプロキシです。リードスコアリングの成功基準は契約レビューとは異なるため、エージェント種別と使用事例別に追跡します。成功率が SLO (通常は 95 ～ 99%) を下回ったときにアラートを表示します。
Mean time between failures (MTBF): エージェント障害間の平均動作時間。MTBF が高いほど、障害が少なく信頼性が高いことを示します。合計エージェント業務時間を失敗数で除算して計算します。エージェント種別ごとに追跡し、最適化投資を必要とする最も信頼性の低いエージェントを特定します。
平均復旧時間 (MTTR): 障害検出からサービス復元までの平均時間。プラットフォームイベントのリプレイとサーキットブレーカーを使用した自動復旧では、手動による介入よりも大幅に迅速かつ少ないエラーでサービスが復元されます。MTTR が低いほど、インシデントあたりのビジネスへの影響が小さくなります。
グラウンディング精度: ソースデータ検証に基づいて実際に正しいエージェント応答の割合。ランダムなエージェント応答をサンプリングして、Data 360 ソースに対して請求を検証します。グラウンディング精度が 95% を下回ると、幻覚の問題が発生し、迅速な絞り込みやコンテキスト検索の改善が必要になります。
Platform Event replay gaps: 見逃されたイベントまたは配信されなかったイベントの数。たとえば、保持期間を超えて登録者がオフラインになっているなど。ギャップゼロは、健全なイベント駆動型アーキテクチャの肯定的なシグナルです。ギャップは、登録者の問題、イベント公開の失敗、または業務量の制約を示します。上記の登録者側のログパターンを使用してこれらのギャップを追跡し、各イベントの replayId と相関関係 ID をカスタムオブジェクトに記録します。

信頼できるエージェントは、SLI/SLO、ガバナ制限対応コンテキスト処理、多層フォールバックチェーンを構築前に定義し、後から組み込むのではなく、障害に備えて事前に設計します。サーキットブレーカーとプラットフォームイベントベースの再試行およびチェックポイントロジックを階層化することで、ワークフローが自動的に回復し、最後の手段として手動による引き継ぎが実行されます。計画的な負荷テスト、障害注入テスト、カオステストで設計を検証し、本番の同じ SLI を監視して、設計が長期にわたって維持されることを確認します。

信頼性の主要な柱の信頼性ガイダンスは、ここで説明するプラットフォーム固有の考慮事項があるエージェントに適用されます。成功するエージェントアーキテクチャでは、自律機能と適切な監視のバランスが保たれるため、一時的な障害から自己復旧しながら、信頼性が低下したりエッジケースが発生したりしたときにエスカレーションできます。

適切に構築されたフレームワークに関するフィードバックを共有する。