エージェントの信頼性パターン

適切に設計された信頼性 → Agentic Enterprise Reliability の詳細

パターン

参照すべき場所外観
プラットフォーム | プラットフォームキャッシュ✅ プラットフォームキャッシュで LLM サービスの健全性状態を追跡する回路ブレーカーを実装して、低レイテンシのリアルタイム読み取りを実現します。しきい値と設定にはカスタムメタデータ型が使用されます。プラットフォームキャッシュはベストエフォート型であるため、キャッシュのみではなく耐久性のあるストア (カスタムオブジェクトなど) でオープン/トリップ状態を保持します。調整された障害しきい値 (たとえば、5 回連続して推測障害が発生した場合) で回線を開き、フォールバックパターンに転送
プラットフォーム | プラットフォームキャッシュ✅ 検証済みの応答スキーマをプラットフォームキャッシュに保存することで、エージェントの応答を期待される構造に対して迅速に検証できます。
Agentforce | プロンプトテンプレート✅ 応答の検証に失敗した場合、検証エラーと正しい構造の例を含む絞り込まれたプロンプトで再試行します (最大 3 ～ 5 回)。
Agentforce | セッション追跡✅ Agentforceセッショントレーシングの推論トレースを使用してエージェントの推論パスを調べ、その出力で幻覚を検出します。
Data 360 | ベクトル検索✅ アクションの実行前に取得したソースに対して請求を相互参照できるように、Data 360 ベクトル検索ソースの引用をエージェントに要求する
プラットフォーム | Proactive Monitoring✅ Signature Successエンタイトルメントを持つアカウントの場合は、Proactive Monitoringをご利用ください。Proactive Monitoringでは、Salesforceスタッフが組織で新しい問題を監視します。セルフ サービスで設定可能なアラートではありません。
プラットフォーム | スケールセンター✅ スケールセンターを使用して、ガバナ制限に近づいている特定のエージェント業務を特定する
Agentforce | アクション✅ 大量のレコードコレクションを取得するエージェントアクションでのページネーションの実装
Agentforce | アクション✅ ハードリミット (親あたり最大 200 個の子) を使用してエージェントアクションを設計し、制限を超えた場合にサンプリング戦略を実行する

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | カスタムメタデータ型⚠️ Circuit Breaker なしで無制限の推測再試行を許可し、LLM サービスが低下したときに無限の再試行ループを作成
Agentforce | プロンプトテンプレート⚠️ 再試行プロンプトに検証エラーと予期される構造を含めずに失敗したエージェント応答を再試行する
Agentforce | アクション⚠️ エージェントが親レコードごとに子レコードにハード制限なしで無制限のコンテキスト (「すべての履歴」など) を要求できるようにする
Agentforce | アクション⚠️ ページネーションなしで大量のレコードコレクションを取得するエージェントアクションの設計により、ガバナ制限が急増する
Einstein | Trustレイヤー⚠️ グラウンディングデータソースに対して請求を相互参照することなくエージェントの応答を信頼し、幻覚がアクションの実行に達するようにする
プラットフォーム | 組織⚠️ LLM サービスの可用性を個別の連動関係として監視するのではなく、Salesforce プラットフォームの可用性と同一として処理する

パターン

参照すべき場所外観
Agentforce | エージェント設定✅ 多層フォールバックチェーンの設計: フルコンテキストエージェント → 削減コンテキストエージェント → 確定的ルールエンジン → オムニチャネルを介した人間のハンドオフ
Agentforce | エージェント設定✅ 詳細なコンテキスト (過去 30 日間とすべての履歴、上位 5 件のベクトル検索結果と上位 20 件) を使用してセカンダリエージェントを設定し、失敗の可能性を低減する
プラットフォーム | フロー✅ プラットフォーム イベントによってトリガーされるオーケストレーション フローまたはApexにフォールバック ロジックを実装し、成功した階層を記録して障害パターンを可視化
プラットフォーム | フロー✅ エージェントの推論に失敗した場合のフォールバックとして一般的なシナリオを処理する確定的フローまたはApexロジックを構築(標準の入力規則、ルールベースのスコア計算など)
Agentforce | オムニチャネル✅ 人的引き継ぎのスキルベースのルーティングを設定し、エスカレーションが適切な専門知識に到達するようにする
Agentforce | オムニチャネル✅ 試行された戦略、エージェントの信頼性スコア、失敗の理由を含む完全な会話コンテキストをヒューマンキューに渡す

アンチパターン

参照すべき場所どんな悪い感じか
Agentforce | エージェント設定⚠️ コンポーネントが劣化すると完全に失敗する 1 つの実行パスを使用するエージェントの設計
Agentforce | エージェント設定⚠️ フォールバック試行でコンテキストを段階的に簡略化するのではなく、同じフルコンテキストエージェント設定を使用する
Agentforce | オムニチャネル⚠️ 会話コンテキスト、試行された戦略、失敗の理由を渡すことなく、エージェントをゼロから開始するように強制する、人間のハンドオフへの転送
プラットフォーム | フロー⚠️ どの代替階層が成功したかを記録せず、失敗パターンと代替の有効性が認識されない

パターン

参照すべき場所外観
プラットフォーム | プラットフォームイベント✅ 複数ステップのエージェントワークフローで成功した各ステップの後にチェックポイントイベントを公開し、イベントペイロードに相関関係 ID、完了したステップ、継続に必要な状態を保存します。
プラットフォーム | プラットフォームイベント✅ エージェントワークフロー全体をブロックすることなく、各エージェントが失敗して個別に再試行できる疎結合イベントチェーンとしてエージェントワークフローを設計する
プラットフォーム | プラットフォームイベント✅ ペイロードに再試行回数が含まれるプラットフォームイベントを使用して、指数関数的なバックオフ遅延 (30 秒、2 分、8 分、30 分) の再試行キューを実装する
プラットフォーム | プラットフォームイベント✅ 最大再試行回数 (通常 5 回) に達したら、デッドレターキューに転送してアラート操作を実行する
プラットフォーム | プラットフォームイベント✅ すべての関連イベントに相関関係 ID を含めます。プラットフォームイベントリプレイ API を使用して、デバッグ用に完全なワークフロー履歴を再構築します。
プラットフォーム | プラットフォームイベント✅ 大規模プラットフォームイベントで使用できる 72 時間のリプレイ保持期間 (標準量イベントは 24 時間保持) を活用して、組織のメンテナンス期間やリリースダウンタイム中に再試行キューを保持します。

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | プラットフォームイベント⚠️ チェックポイントなしで複数ステップのエージェントワークフローを作成し、中間ステップが失敗したときに完全な再実行を要求する
プラットフォーム | プラットフォームイベント⚠️ 指数関数的なバックオフなしで失敗したエージェント要求を再試行し、サービスの回復に驚異的な群れの影響を生じる
プラットフォーム | プラットフォームイベント⚠️ 1 人のエージェントが失敗するとすべての下流処理がブロックされる密結合された順次ワークフローの設計
プラットフォーム | プラットフォームイベント⚠️ イベントから相関関係 ID が省略され、ワークフローの完了を追跡およびデバッグできない
プラットフォーム | プラットフォームイベント⚠️ 最大再試行回数またはデッドレターキューなしで無期限に再試行し、完全に失敗した操作でプラットフォームリソースを消費する

パターン

参照すべき場所外観
プラットフォーム | Apex✅ 非同期ガバナ制限を活用して1,000件以上のレコードを分析するエージェント操作でApex一括処理を使用(200 SOQLクエリ、150 DML操作、実行あたり60秒のCPU)
プラットフォーム | Apex✅ 複数の外部APIコールや長時間の処理を必要とする複数ステップのエージェント ワークフローにキュー可能なApexチェーンを使用。カスタム オブジェクトの進行状況を追跡して、失敗時に再開できるようにする
プラットフォーム | Apex✅ 失敗が許容される軽量な Fire & Forget Agent 操作 (通知、外部ログ、緊急ではない更新) には @future メソッドを使用します。
プラットフォーム | Apex ジョブ✅ Apexジョブページ([設定] → [Apexジョブ])とApex Flexキューを使用して非同期処理能力を監視します。最大5つの同時一括処理ジョブ(Flexキュー内の追加ジョブのキューは[保持]状況で最大100)と、組織の非同期Apex実行の1日あたりの制限(DailyAsyncApexExecutions)。24時間あたりのユーザーライセンス数が25万または200 x 大きい方。バッチ、キュー可能、将来、スケジュール済みApexで共有
プラットフォーム | 組織✅ 非同期消費が制限に近づいている場合にアラートを表示して、エージェントの処理がブロックされる前にプロアクティブな業務量管理を有効化

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | Apex⚠️ バッチApexに移行するのではなく、同期エージェント トランザクションで1,000件以上のレコードを処理し、わずか数件のレコードの後に100 SOQLクエリの制限に達する
プラットフォーム | Apex⚠️ カスタムオブジェクトの進行状況を追跡せずにキュー可能チェーンを使用し、障害発生時に再開する機能を防止
プラットフォーム | 組織⚠️ 同時バッチ・ジョブの5つの制限または共有の1日あたりの非同期Apex実行制限（DailyAsyncApexExecutions：バッチ、キュー可能、将来、スケジュール済みApex全体で24時間あたり25万件または200 x ユーザー・ライセンスのいずれか多い方）を監視していないため、エージェント処理が通知なしでキューに入れられるか失敗する

パターン

参照すべき場所外観
プラットフォーム | 組織✅ 本番規模のデータ量を使用して Full Copy Sandbox でテストエージェントのパフォーマンスを読み込み、ピーク需要に一致する同時会話をシミュレーション
プラットフォーム | 組織✅ 負荷時の p95 および p99 のレイテンシを測定して、ストレス時のパフォーマンスの低下を特定。ピーク負荷時のガバナ制限消費量がしきい値未満であることを検証
Agentforce | エージェント設定✅ 障害注入の実行: Circuit Breaker が監視するサービスレイヤーでの LLM 推測障害のシミュレーション、エラー処理のテスト、検証ロジックのテストのための SOQL 例外の注入
Agentforce | エージェント設定✅ テスト中にデータスキュー (10,000 人以上の子を持つアカウント) を導入して、ページネーションロジックが最悪のシナリオを処理することを検証
プラットフォーム | プラットフォームイベント✅ カオスエンジニアリングを実施: リプレイリカバリーをテストするプラットフォームイベント登録者をランダムに無効化し、実行テストチェックポイントの再開中に非同期ジョブを終了します。
プラットフォーム | 組織✅ エージェントの進化に合わせてレジリエンスを維持するステージング環境で定期的なカオスデイをスケジュールする
プラットフォーム | 組織✅ 長期間 (72 時間以上) の安定性テストを実行し、時間ベースの障害を監視します。エラーの累積とパフォーマンスの徐々に低下
プラットフォーム | 組織✅ コンテキスト管理の段階的な劣化を検出して、CPU 時間のトレンドと長期間にわたるヒープ消費量を追跡する

アンチパターン

参照すべき場所どんな悪い感じか
プラットフォーム | 組織⚠️ データ量を削減した Partial Copy Sandbox での負荷テスト。データ量がエージェントのパフォーマンスに直接影響するため、誤解を招くような信頼性が得られます。
Agentforce | エージェント設定⚠️ 回路ブレーカー、再試行ロジック、タイムアウト処理を検証するために意図的に失敗を導入しないで、ハッピーパスのみをテスト
プラットフォーム | 組織⚠️ 短時間のテストのみを実行し、72 時間以上の継続的な運転でのみ現れる時間ベースの障害 (累積エラー、段階的な劣化) を見逃している
プラットフォーム | プラットフォームイベント⚠️ プラットフォームイベントのリプレイリカバリーやチェックポイントの再開をテストせず、レジリエンスメカニズムを未検証のままにする

パターン

参照すべき場所外観
ビジネス | ドキュメント✅ 本番での失敗の後ではなく、エージェントを構築する前に SLO を設定し、エージェント種別ごとに会話の成功率目標 (通常は 95 ～ 99%) を定義する
プラットフォーム | 組織✅ 主エージェントの信頼性指標として会話の成功率を追跡します。エラーやタイムアウトなしで完了した会話の割合です。エスカレーションは設計された最終代替階層であるため、人間への適切な引き継ぎを成功として数えます。失敗したエスカレーションまたは意図しないエスカレーションのみを評価指標に数えます。
プラットフォーム | 組織✅ エージェントの目的によって成功条件が異なるため、エージェント種別と使用事例別に成功率を追跡する
プラットフォーム | 組織✅ エージェント種別ごとに平均障害間隔 (MTBF) を計算して、最適化投資が必要な最も信頼性の低いエージェントを特定する
プラットフォーム | 組織✅ 平均復旧時間 (MTTR) の測定。プラットフォームイベントのリプレイとサーキットブレーカーを使用して復旧を自動化し、手動による介入よりも大幅に迅速でミスが発生しにくい復旧を実現します。
Einstein | Trustレイヤー✅ Data 360 ソースに対して請求を検証するランダムなエージェント応答のサンプルでグラウンディング精度を測定し、精度が 95% を下回った場合を調査する
プラットフォーム | プラットフォームイベント✅ 各イベントの replayId と相関関係 ID をカスタムオブジェクトに記録する登録者側のログパターンを使用して、プラットフォームイベントのリプレイギャップ (見逃されたイベントまたは配信されなかったイベント) を監視する
プラットフォーム | 組織✅ SLI が定義済みの SLO しきい値を下回ったときにアラート操作

アンチパターン

参照すべき場所どんな悪い感じか
ビジネス | ドキュメント⚠️ SLO を最初に定義せずにエージェントを構築し、本番で障害が発生した後にのみ信頼性目標を設定する
プラットフォーム | 組織⚠️ エージェント種別や使用事例別に追跡するのではなく、すべてのエージェント種別で 1 つの集計成功率を使用
プラットフォーム | 組織⚠️ 会話の成功率、MTBF、MTTR、グラウンディング精度などのエージェント固有のSLIを追跡せずに、従来のSalesforce監視(Trust.salesforce.com)のみを使用
プラットフォーム | 組織⚠️ プラットフォームイベントのリプレイとサーキットブレーカーを使用して回復を自動化するのではなく、すべてのエージェントの失敗に対して手動操作が必要
Einstein | Trustレイヤー⚠️ グラウンディング精度検証のためにエージェント応答をサンプリングしないことで、本番で幻覚が検出されないようにします。

パターン

参照すべき場所外観
Agentforce | エージェント設定✅ 再試行パターン、フォールバックチェーン、エスカレーションしきい値を事後ではなく初期設計からエージェントワークフローに設計する
Agentforce | アクション✅ エージェントアクションでコンテキストの準備を一括処理し、大きなレコードコレクションをページ分割する
プラットフォーム | プラットフォームキャッシュ✅ 頻繁にアクセスする参照データをプラットフォームキャッシュにキャッシュし、エージェントコンテキストの準備中の冗長なクエリを削減
プラットフォーム | スケールセンター✅ スケールセンターを使用して、最適化が必要なリソースを大量に消費するエージェント業務を特定する
プラットフォーム | プラットフォームイベント✅ 外部連動関係を保護する回路ブレーカーを備えた耐久性のある再試行キューとしてプラットフォームイベントを使用して、自動復旧ワークフローを設計する
Agentforce | エージェント設定✅ すべてのエージェントのデグラデーションチェーンに最終フォールバックとして必ず人のハンドオフを含める
プラットフォーム | 組織✅ 総計値が SLO を下回ったときにエージェントの SLI を継続的にアラート監視
Agentforce | エージェント設定✅ 自律機能と適切な監視のバランスを取る: 信頼性の低下やエッジケースの発生時にエスカレーションしながら、一時的な障害からの自己復旧を可能にします。

アンチパターン

参照すべき場所どんな悪い感じか
Agentforce | エージェント設定⚠️ 信頼性メカニズム (再試行、フォールバック、エスカレーション) を最初から設計するのではなく、後付けで追加
Agentforce | アクション⚠️ コンテキストの準備を一括処理しないため、実際のクエリパターンでガバナ制限に失敗する
プラットフォーム | 組織⚠️ API 消費とプラットフォームイベント割り当てを積極的に監視せず、エージェントが失敗した場合にのみ制限を検出する
Agentforce | エージェント設定⚠️ 最終フォールバックとして人のハンドオフを使用しないエージェントチェーンの設計により、すべての自動化オプションが使い尽くされたときにリカバリーパスが残らない
Agentforce | エージェント設定⚠️ 信頼できない状況またはエッジケースのエスカレーションしきい値のない完全な自律運用をエージェントに許可