Operational Excellence for the Agentic Enterprise (エージェント型企業のオペレーショナルエクセレンス)

エージェントシステムのオペレーショナルエクセレンスは、従来の DevOps プラクティスを拡張して、AI エージェント固有の特性 (非確定的動作、コンテキスト依存の推論とメモリ、目標の複雑さ、変数の推測コスト) に対処します。従来のアプリケーションは予測可能なコードパスに従いますが、エージェントはコンテキストに基づいて新しい応答を生成します。従来の監視では既知の総計値を追跡しますが、エージェントの可観測性では言語モデルの推論と決定パターンを理解する必要があります。標準テストでは確定的出力が検証されますが、エージェント検証では精度、関連性、安全性、公正性など、複数のディメンションで応答品質が評価されます。

製品とシステムは時間と共に変化するため、運用の卓越性を運用方法に組み込むために、オブザーバビリティによる進化、運用手順の標準化、DevOps 文化の醸成、効率化のための自動化、すべての運用イベントからの学習の 5 つの設計原則を適用します。エージェントの行動は確定的なコード実行ではなく、プロンプト、取得されたコンテキスト、モデルの動作、会話履歴間の複雑なやりとりから生じるため、オペレーショナルエクセレンスのコア原則である「オブザーバビリティで進化」はエージェントシステムにとって不可欠です。応答はモデル、プロンプト、ライブコンテキストによって形成されるため、アーキテクトは設計時にすべてのエージェント応答を予測できないため、オブザーバビリティとガードレールを考慮して設計します。包括的な観測可能性により、実際の条件下でのエージェントの実際の行動を明らかにします。この表示により、エージェントが予期しない出力を生成したときに、データ主導の改善と迅速な問題診断が可能になります。

「コードとしての操作」では、エージェントのディメンションが変わります。従来のコードとしてのインフラストラクチャは、プロンプトバージョン管理、モデル設定管理、エージェントリリースの自動化にまで拡張されています。エージェントの操作手順は、モデルのバージョン変更、プロンプトの進化、Knowledge Baseの更新、従来のリリースおよびロールバック操作に対応します。

「すべての業務イベントから学ぶ」は、エージェントシステムでさらに価値が高まります。エージェントインシデントでは、プロンプトエンジニアリングの微妙な問題、スクリプトとオーケストレーションのエラー、Knowledgeベースのギャップ、予期しないユーザー操作パターンがしばしば明らかになります。死後にエージェントのテレメトリの体系的な分析と組み合わせることで、業務経験が経時的に複合する組織能力に変換されます。

完全な会話ログは、エージェントの可観測性の基盤を形成します。ユーザー入力、エージェント応答、推論ステップ、呼び出されたアクション、取得されたデータ、最終結果など、すべての会話をキャプチャします。このテレメトリは、特定のインシデントのデバッグ、多数のインタラクションの品質分析、コンプライアンス監査、モデルの改善、使用パターンの分析など、複数の目的に使用されます。

カスタム作成ログよりもネイティブのセッショントレーシングモデルを使用します。Agentforce セッショントレーシングでは、並列テレメトリーシステムを構築するのではなく、Data 360 の統合データモデルでエージェントの操作データが取得されます。セッショントレーシングデータモデル (STDM) では、会話をトレース階層として記録します。各セッションにはインタラクション (ターン)、各インタラクションにはステップ (UserInputStep、LLMExecutionStep、FunctionStep)、ステップにはメッセージ (ユーザーとエージェントのコミュニケーション) が含まれます。STDM では、AIAgentSession、AIAgentSessionParticipant、AIAgentInteraction、AIAgentInteractionStep、AIAgentInteractionMessage などの標準 Data 360 オブジェクトが使用されます。インタラクションは分散追跡識別子 (TelemetryTraceId と TelemetryTraceSpanId) を伝送し、ステップは OpenTelemetry スタイルのスパンモデルを反映するスパン識別子 (TelemetryTraceSpanId) を伝送します。

エージェントの会話をトレースおよびスパンとしてモデル化することは、エージェントの可観測性に対する業界標準のアプローチであり、ネイティブモデルを再利用することで、複数ターンの会話の保存、大きな JSON ペイロード、データの急増など、手作業で作成されたオブジェクトで発生する拡張性の問題を回避できます。会話を記録するためのカスタムトランザクションオブジェクトの作成は意図的に行う例外です。たとえば、エージェントの動作をビジネス結果に関連付ける軽量のカスタムオブジェクトは、主ログ基盤ではありません。

セッションおよび会話メタデータは、セッションおよびインタラクション識別子、ユーザー ID、エージェント ID、開始時刻、終了時刻などの重要なコンテキストを取得します。また、STDM は各インタラクションステップを大規模言語モデル (LLM) 通話レコードにリンクします (GenerationId および GenAiGatewayRequest/Response 参照を使用)。トークンの利用状況、モデル、プロンプトの詳細は、セッション項目として保存するのではなく、これらの結合を介して使用できます。メタデータにより、パターン分析のための会話の絞り込みと集計が可能になります。

インタラクションとステップレベルの詳細は、ユーザーの入力、エージェントの応答、理由の説明 (使用可能な場合)、信頼性スコア、取得したコンテキスト、試行されたアクション、発生したエラーなど、各ターンを取得します。ステップレベルの追跡により、詳細なインシデント調査が可能になり、推論チェーンの各時点で何が起きたかを正確に再現できます。

アクションステップには、API コール、データ変更、外部システム操作、呼び出されたインテグレーションなど、エージェントが実行するすべてのアクションが記録されます。アクションレコードは、「このエージェントは何を変更したか?」などの質問に回答します。「このエージェントはどのシステムにアクセスしたか?」が表示されます。これらの回答は、セキュリティ調査とコンプライアンス要件をサポートします。STDM はアクションをインタラクションステップとしてネイティブに取得します。

Atlas Reasoning Engine からの推論トレースにより、エージェントの決定プロセスが明らかになり、エージェントが特定のアクションを選択した理由や特定の応答を生成した理由を診断できます。セッショントレーシングでは、各インタラクションの一部としてプランナーのステップが記録されます。公開された推論の深さはモデルとプランナーによって異なりますが、これらのトレースが使用可能な場合、デバッグ可能性が劇的に向上します。

Einstein Trust Layerの生成AI監査証跡では、各生成AIインタラクション、プロンプトと応答テキスト(PII(個人識別情報)をマスクしたバージョンを含む)、取得されたグラウンディング データ、応答の安全性と有害性スコア、LLMモデルの詳細がすべてData 360にストリーミングされて保存されます。監査とフィードバックのデータがData 360に取得されるように、Einstein生成AIとフィードバック データの収集と保存を有効にします。これにより、監査とフィードバックのデータはData 360のレポートで照会および分析され、長期保存が可能になります。

例:

Good: ユーザー入力、エージェント応答、実行されたアクション、トークン消費、会話結果の項目を含むカスタム Salesforce オブジェクトに保存されている会話ログ。ダッシュボードには、エージェントと使用事例別の会話成功率が表示されます。Better: 包括的なログには、エージェントの決定プロセスを示す推論トレース、グラウンディングされた応答を示す取得済みコンテキスト、不確実性を示す信頼性スコアが含まれます。最善: 会話分析では、エージェントの行動とビジネス結果を関連付け、パターン分析で改善の機会を特定し、品質表示ラベルが付けられた例を使用して継続的な学習パイプラインにフィードします。

エージェントがサービスレベルを満たし、期待されるパラメーターの範囲内で業務を行っていることを確認する運用パフォーマンスを監視します。

応答遅延は、ユーザー入力からエージェント応答までのエンドツーエンドの時間を追跡します。遅延はユーザーエクスペリエンスに直接影響します。レイテンシをパーセントで測定し (p50、p95、p99)、典型的なパフォーマンスと最悪のエクスペリエンスを明らかにします。p95 遅延がパフォーマンスの低下を示すしきい値を超えた場合にアラートを表示します。

エージェントの遅延要素には、モデルの推測時間、データとコンテキストの取得期間、外部ツールとアクションの実行、ネットワーク遅延が含まれます。全体的な遅延が目標を超えた場合に、各フェーズを個別に測定して目標の最適化を有効にします。

トークン消費では、会話ごと、エージェントごと、使用事例ごとに使用されるトークンを測定します。トークンの消費によって推測コストが上がり、応答時間に影響します (トークンが多いほど、より多くの推測計算が必要になります)。トークンの配布を追跡して、実際の使用量が予測と一致するかどうかを明らかにします。プロンプトの問題や誤用を示唆する過剰なトークンを使用している異常値会話を検出します。

トークン総計値には、プロンプトトークン (モデルへの入力)、完了トークン (モデル出力)、合計トークン (プロンプトと完了の合計) が含まれます。プロンプトトークンは、完了トークンよりも制御が容易です。プロンプトと取得されたコンテキストを最適化し、品質を維持しながらプロンプトトークンの消費を減らします。

スループット監視は、同時会話数、1 秒あたりの要求数、会話量のトレンドを追跡し、プロジェクトの業務量と拡張性の要件に役立ちます。しきい値に近づいている場合に、現在のスループットを既知のレート制限または業務量ベースラインアラートと比較します。

エラー率追跡では、モデル固有のエラー、タイムアウトの失敗、権限が拒否されたエラー、外部インテグレーションの失敗など、種別ごとに失敗を監視します。エラーパターンにより、修復が必要な体系的な問題が明らかになります。エラー率を要求全体に対する割合として計算し、エージェントや期間全体で比較できるようにします。

異なる応答が必要なエラーカテゴリを区別します。モデル固有のエラーの場合、迅速な調整や、より適切なモデルへの切り替えが必要になることがあります。権限エラーの場合は、セキュリティ設定を変更する必要があります。インテグレーションエラーの場合、外部システム調査または回路ブレーカーの有効化が必要です。

対応可能状況モニタリングでは、エージェントのアップタイムと成功した操作期間が測定されます。対応可能状況をエージェントが要求に正常に応答した時間の割合として計算します。サービスレベル目標 (SLO) に対して対応可能状況を追跡し、対応可能状況が目標を下回った場合にプロアクティブな対応を可能にします。

Proactive Monitoring は、エージェントインフラストラクチャの健全性に影響する可能性があるプラットフォームの異常とリソース使用率の問題について組織を評価します。ユーザーに表示される問題にエスカレーションする前にシグナルを表示します。これを使用して、エージェントのパフォーマンスを低下させる可能性があるインフラストラクチャレベルの状況 (異常な API 活動や、プラットフォーム制限に向かうリソースの消費トレンドなど) を把握します。エージェントの通常の業務ベースラインに対してシグナルを確認し、アクション可能な異常と予測される変動を区別できるようにします。

応答品質を継続的に監視し、ビジネスの結果に影響する前に低下を検出します。プラットフォームで組み込みの評価ツールが提供されている場合は、カスタムプロセスや手動プロセスの代わりに使用します。まず、ネイティブのテストと評価ツールを使用します。Agentforce テストセンターでは、再利用可能なテストケースセットを管理し、それらに対してエージェントを一括で実行できます。エージェントは、独自のテストハーネスを作成して実行する代わりに、予想されるトピックとアクションを選択し、受け入れられる応答を生成したかどうかを確認できます。また、標準の品質ディメンションや会話品質をスコアリングする LLM-as-Judge アプローチなどのネイティブ評価者もサポートし、組織固有の条件でカスタム評価者を作成できます。実際の使用状況が評価に反映されるように、テストセットで代表的な会話を使用します。

応答精度は、エージェントの応答に正しい情報が含まれているかどうかを測定します。正確な評価には、既知の回答アサーションまたは人間によるレビューが必要です。既知の回答がある実際の質問の場合、自動評価ではエージェントの回答が正しい回答と比較されます。テストセンターでテストケースとして保持することで、繰り返し評価できます。自由回答形式の質問では、人間の評価者がサンプル会話の精度を評価します。精度の経時的なトレンドを追跡し、プロンプトの変更、モデルの更新、またはKnowledgeベースの変更によってパフォーマンスが改善されるか低下するかを明らかにします。

回答の関連性は、エージェントの回答がユーザーの質問に適切に対処しているかどうかを測定します。完全に正確ではない場合でも、関連する回答はユーザーのインテントを理解し、完全な回答が不可能な場合でも役立つ情報を提供します。可能な場合はネイティブ評価者、サンプル会話の人間によるレビュー、ユーザーシグナルを使用して関連性を評価します。Knowledge Baseにグラウンディングされたエージェントの場合、取得品質のネイティブ分析により、コンテキストの関連性、回答の忠実度（グラウンディング）を評価できます。

**ガードレールは、**バイアス、攻撃的なコンテンツ、危険なアドバイス、範囲外の応答など、安全でない応答、不適切または有害な応答を検出します。Einstein Trust Layer は、実行時に毒性検出を LLM インタラクションに適用します。これは防御の最前線です。コンテンツの絞り込み、手動レビューサンプリング、ユーザーレポートメカニズム、人口統計グループ全体の結果の分布を評価する公平性監査を通じて、安全性の監視を強化します。

ユーザー満足度総計値は、主観的な環境品質を取得します。Agentforceフィードバックは、Einsteinの生成AI監査およびフィードバック データ モデル(Data 360のGenAIFeedback/GenAIFeedbackDetail)に転送されます。これらのモデルでは、ゲートウェイの要求および生成データと共に、ユーザーまたはシステムソースからの明示的なシグナル (サムアップ/ダウン、承諾/却下、編集、逐語的なコメント) を取得します。明示的なフィードバック (エスカレーション前、会話の終了後、フォローアップアンケートで尋ねること) を必要な場所で取得し、明示的なシグナルと暗黙的なシグナルを組み合わせて包括的な品質の観点を実現します。

Salesforce には、さまざまなモデルサーフェスが用意されています。生成層では、エージェントが実行する対話形式の推論が提供されます。Agentforce でホストされるモデルは、Salesforce Trust 境界内で標準の推論を実行し、独自の LLM（BYOLLM）リンクを外部 LLM またはプロバイダーに提供します。予測層は、エージェントが意思決定の基礎となる構造化されたスコアを提供します。BYOMは、外部でホストされるプラットフォームからゼロ コピーの予測スコアを取得し、ネイティブEinsteinモデルでCRMオブジェクトのスコアリングと分類を自動化します。これらのサーフェスを組み合わせることで、自律エージェントは構造化された統計データでワークフローをグラウンディングしながら、自然言語で推論できます。

モデルドリフトを監視します。これは、経時的なパフォーマンスの低下や、適応が必要な条件の変化を示します。各メジャーリリースを本番に移行する前に、リリースノートを確認し、重要な使用事例を Sandbox でテストします。リリースマトリックスと Sandbox プレビューウィンドウを使用して、互換性の問題を早期に把握します。

パフォーマンスのドリフトは、エージェントの精度、関連性、または安全性が時間の経過とともに低下した場合に発生します。統計的に有意な低下を検出して、経時的な品質評価指標を追跡します。パフォーマンスのドリフトは、モデルの低下、Knowledgeベースの古さ、変化する使用パターンとの不一致、入力と目的の出力間のリレーションが進展する概念のドリフトによって発生する可能性があります。

代表的なテストケース全体の精度、関連性、安全性、満足度を測定し、エージェントの初期リリース直後にベースラインパフォーマンスを確立します。同じテストケースに対して定期的に再評価し、使用パターンのシフトに関係なくパフォーマンスの変化を明らかにします。

品質指標が許容しきい値を超えた場合にアラートを表示します。ビジネスへの影響の許容度に基づいてしきい値を定義します。品質の低下を許容する使用事例もあれば、低下にすぐに対応する必要がある使用事例もあります。

配信ドリフトは、ユーザー入力パターンがトレーニングやデータ配信の調整から大幅に変更されると発生します。エージェントが処理するように設計されていない入力種別に遭遇すると、分布ドリフトによってパフォーマンスが低下します。質問の長さ、トピックの分布、言語の複雑さ、ドメインの用語など、入力の特性を監視して重要なシフトを検出します。

現在の入力分布を過去のベースラインと比較します。大きな配分シフトは、新しい使用事例、ユーザー行動の変化、ビジネスプロセスの進化を示す可能性があります。配布シフトでは、迅速な更新、Knowledgeベースの拡張、エージェント機能の強化が必要になる場合があります。

動作ドリフトは、エージェントの応答パターンが予期せずに変更されると発生します。平均応答時間、アクション呼び出し率、エスカレーション頻度、エラーパターンなどの応答特性を監視します。重大な動作の変更は、プロンプトの問題、モデルの問題、または基盤となるシステムの変更を示している可能性があります。

本番の早い段階で行動ベースラインを確立し、通常のパフォーマンスパターン、ツールの使用状況、決定パスなどの通常の業務特性を取得します。これらのベースラインは、後の異常検知の基準となるベンチマークです。進行中の行動をベースラインと比較して、偏差が予想される変動を超えた場合にアラートを表示します。

自動アラートにより、プロアクティブなドリフト応答が可能になります。ドリフト総計値がしきい値を超えた場合にアラートがトリガーされ、調査や改善の可能性 (プロンプトの調整、Knowledgeベースの更新、テストセットの拡張、BYOM モデルの再トレーニングなど) が示されるように設定します。

調査が必要な異常なエージェントの行動を自動的に検出します。

トークン消費の急増、推測レートの増加、合計コストの加速などのコスト異常。コストの急増は、プロンプトの問題によってトークンが過剰に生成されることや、予期しない使用を引き起こす悪用や誤用、インフラストラクチャの問題によってコールが冗長になることを示します。

異常値の会話を検出するトークン消費分布を監視します。通常のトークン数の 10 倍を消費する会話を調査し、会話が正当なエッジケースや修正が必要な問題を表しているかどうかを把握します。

エラー率の急増には、障害率の急増、ベースラインに存在しなかった新しいエラーの種類の出現、特定のユーザー、エージェント、使用事例に影響する局所的なエラーの集中などがあります。多くの場合、エラーの急増は、顧客に表示される品質低下の問題よりも前に発生します。プロアクティブな検出により、広範な影響が発生する前に修復できます。

応答時間の急激な変化、アクション呼び出し頻度、またはエスカレーションレートの変更などの応答パターンの変更。パターンの変更は、プロンプトの問題、モデルの動作の変更、または進化する使用パターンを示している可能性があります。

会話放棄が増加します。会話放棄率が高くなると、品質の低下、遅延の増加、または機能のギャップが示唆されます。会話フェーズ別に放棄を追跡し、ユーザーが最初のインタラクション中、会話中、または試行された ToDo の完了後に放棄したかどうかを特定します。放棄パターンにより、具体的な改善機会が明らかになります。

アラートの疲労に対する迅速な通知のバランスを取るアラートアーキテクチャを設計する。エージェントの重要な障害をオンコールエンジニアにすぐに転送します。営業時間中に品質低下警告を商品チームに転送して調査します。軽微な異常を毎日のダイジェストに集計してトレンド分析します。

ロールバック、A/B テスト、監査履歴のメンテナンスを可能にするバージョン管理プロンプト、設定、モデルメタデータ。

プロンプト テンプレートは、エージェントの目標、制約、ブランド ガイドラインを定義するプロンプトビルダーで作成された再利用可能なプロンプトと、顧客や商品の詳細などの動的なグラウンディング データのプレースホルダーです。プロンプトテンプレートをアプリケーションコードと共に Git に保存することで、プロンプトをコードと同じ厳格さに値する重要なアプリケーションロジックとして扱います。迅速な変更は、コードレビュー、テスト、管理されたリリースを経て行われます。

プロンプトビルダーを使用して、バージョン履歴とテスト機能を備えた反復的なプロンプト開発を行います。プロンプトテンプレートをエージェントアクションとして使用する場合は、プロンプトビルダーでテンプレートをプレビューして、差し込み項目が正しく解決されることを確認します。次に、テストセンターを使用してエンドツーエンドのテストを実行し、エージェントがアクションを選択して正しい出力を生成することを確認します。

本番対応のプロンプトをバージョン管理にエクスポートして、プロンプトビルダー開発とソースで制御されるリリースパイプライン間で同期します。

構成管理では、モデルの選択、温度設定、取得設定、機能フラグを追跡します。設定をコードとして保存することで、環境固有の値を使用したり、リリースを自動化したり、設定ドリフトを検出したりできます。

セマンティックバージョン管理はエージェントリリースに適用されます。メジャーバージョンは、入出力契約の変更や動作の大幅な変更など、変更の中断を示します。マイナーバージョンは、互換性を維持する機能の追加または改善を示します。パッチバージョンはバグ修正を示します。バージョン番号により、変更の影響が運用チームとユーザーに伝達されます。

プロンプト・テンプレート、エージェント構成、Knowledge Baseなどのエージェント・コンポーネントにセマンティック・バージョン管理を実装します。ログのバージョン番号により、特定のリリースとのインシデントの相関が可能になります。

変更ドキュメントには、迅速な変更、設定の変更、モデルの更新の根拠が記載されます。何が変更されたか、変更された理由、変更を検証したテスト、および存在するロールバック手順を文書化します。変更ドキュメントにより、インシデントの調査とKnowledge Transferが迅速化されます。

モデルバージョン、プロンプト、設定、リリース履歴の包括的なレジストリを管理します。

モデルレジストリには、モデルファミリー、特定のバージョン、微調整の状態、導入環境 (本番、ステージング、開発)、導入日、担当チームなど、どのモデルバージョンがどこに導入されたかが記録されます。レジストリでは、エージェントインフラストラクチャの状態に関する一元化された情報源が提供されます。

リリース追跡では、リリースされたバージョン、環境、リリースタイムスタンプ、リリースユーザー、取得された承認、リリース結果など、すべてのエージェントリリースが記録されます。リリース履歴を使用して、問題が発生したときの影響を評価し (「インシデントの開始前にリリースされたエージェントは?」など)、コンプライアンスレポートをサポートします。

連動関係管理は、エージェント、プロンプト、知識ベース、アクション、インテグレーション間のリレーションを対応付けます。共有Knowledgeベースが更新されると、連動関係追跡によって影響を受けるエージェントが明らかになります。外部インテグレーションが変更されると、連動関係追跡によって影響を受けるエージェントが特定されます。

インシデント中に連動関係を検出するのではなく、明示的に文書化します。開発およびリリースプロセスで維持される連動関係マップを作成します。

非推奨ポリシーでは、サポート期間、非推奨タイムライン、移行要件など、モデルバージョンのライフサイクルを定義します。明確な廃止ポリシーにより、技術的な負債を管理し、古いモデルバージョンの無期限のサポートを防ぎます。強制的な廃止への緊急対応ではなく、計画的な移行を可能にするために、事前に十分なタイムラインを伝える廃止スケジュールを設定します。適切に伝達され、ポリシーに裏付けされた最小通知期間により、重要な変更に対して適切な移行時間が確保されます。

ロールバック手順により、チームは問題のあるリリースから迅速に復旧できます。各エージェントのロールバック手順を文書化し、次の内容を含めます。

• ロールバックをトリガーする条件
• どのバージョンに戻すか
• ロールバックの実行方法
• ロールバックを承認および実行するユーザー
• ロールバックが成功したことを確認するテストと、通知するチーム。

本番以外の環境で定期的にロールバック手順をテストし、本番インシデント中にロールバック手順を使用する前に正常に機能することを確認します。チームが何をすべきかを正確に把握できるように、模擬リリースを使用してリハーサルを行います。テストされていないロールバック手順は、多くの場合、最も必要なときに失敗します。

継続的なトレーニング、微調整、調整ワークフローを通じてエージェントの品質を維持します。

フィードバック収集では、ユーザーからのフィードバック、ユーザーによるレビューの修正、品質評価、結果の測定を体系的に収集します。フィードバックは改善の原料となります。体系的な収集がなければ、改善は推測作業になります。エスカレーション前、会話終了後、またはフォローアップアンケートで質問して、明示的なフィードバックを収集します。完了率、エスカレーション頻度、再試行パターンを通じて暗黙的なフィードバックを収集します。明示的なシグナルと暗黙的なシグナルを組み合わせて、包括的な品質の視点を提供します。

データ キュレーションでは、キュレーション、品質レビュー、バイアス チェックによって高品質のトレーニング データセットが維持されます。トレーニングデータの品質がモデルの品質を直接決定します。データの質が低いと、信頼性の低いモデルが生成されます。優れたデータを使用すると、卓越したパフォーマンスを実現できます。

次の方法で会話ログをトレーニングデータセットに選定します。

• 品質の絞り込み - 評価の高い会話や成功した結果を含む
• 問題のある例の削除 (安全違反やエラーを含む)
• 多様なシナリオやエッジケースを含む代表性の確保
• 重複排除 - ほぼ同一の例の削除

ドメイン(特殊な語彙、独自のビジネス プロセス、組織固有のKnowledge)にエージェントを適応させるには、主にData 360でグラウンディングされたRAG(Retrive-augmented Generation)と、Salesforceネイティブ パスであるプロンプトの調整を使用します。

Salesforce内で微調整された生成モデルは存在せず、AIモデルとプロンプトビルダーを使用してモデルを選択して設定します。グラウンディングが不十分な場合は、外部で微調整してから BYOLLM で接続します。

プロンプトの絞り込みは、プロンプトビルダーを使用してパフォーマンスデータに基づいて繰り返し実行されます。プロンプトエンジニアリングは、1 回限りの練習ではなく継続的な練習です。使用パターンの進化、ビジネスプロセスの変化、ユーザーの期待の変化に伴い、プロンプトでは最適なパフォーマンスを維持するための調整が必要になります。

最近の会話、品質評価指標、改善の機会を特定するユーザーフィードバックを調査する定期的なプロンプトレビューケイデンスを設定します。完全なロールアウトの前に改善を検証する A/B テストを使用して、プロンプトの変更を段階的に実装します。

評価の自動化により、保留中のテストセットで品質評価が実行され、改善候補をすばやく評価できます。自動評価では、主観的な人間の評価を補完する客観的な測定が提供されます。

ハッピーパス、エッジケース、敵対的な入力、過去の問題シナリオをカバーするテストセットを管理します。テストの自動化を設定して、テストシナリオを定期的に実行します。自動結果監視、しきい値、異常に関するシステム管理者への通知を含めます。この自動テストは、モデルドリフトなどの外部要因による悪影響を検出するために重要です。

新しいエッジケースが本番で出現するたびにテストセットを継続的に拡張します。テストの自動化は重要ですが、定期的な手動スポットチェック、1 回限りのテスト、Gorilla テストも実行して、エージェントによるリリースがエッジケースに対応できるようにします。

エージェントの変更を徐々にリリースし、完全なロールアウトの前に品質を監視して、問題の半径を制限します。変更が複数の領域 (プロンプト、モデル設定、アクション、グラウンディング、インテグレーション) にまたがる場合、テストで検出されなかった動作が低下する可能性があります。その場合、品質の後退で 1 つの明白な根本原因が指摘されることはほとんどありません。回帰をそのソースまで追跡できるように小さな変更を 1 つずつ配送し、診断中に影響を抑制するために、まず制限されたトラフィックのスライスに各変更をリリースします。

機能フラグは、設定の背後で機能が無効化されているエージェントをリリースすることで、リリースからリリースを切り離します。ロジック、カスタムメタデータ型、またはカスタム設定を使用して機能フラグを実装します。機能フラグを使用すると、ユーザーに機能を公開せずに本番環境でテストしたり、特定のユーザーセグメントに段階的にロールアウトしたり、実装を比較する A/B テストを行ったり、再リリースせずにフラグを無効にして即座にロールバックしたりできます。

重要なエージェントの変更 (ビジネスクリティカルなエージェントに影響する変更、本番動作が不確実な新しい推論パターン、インタラクションパターンがテストとは異なる可能性のある外部システムとのインテグレーションなど) の場合、重大なエージェントの変更には機能フラグを使用します。

Canary リリースでは、エージェントの変更を小さなユーザーサブセットにリリースし、まずエラー率、品質評価指標、およびパフォーマンスを監視してから、より広範なロールアウトを行います。権限セットを使用して、カナリアのリリースを制御したり、エージェントのアクセスを一部のユーザーに制限したり、ユーザー属性に基づいてオーケストレーションロジック内で絞り込んだりします。

成功率、応答品質、ユーザーフィードバックを監視して測定します。以前のエージェントバージョンを使用して、カナリア評価指標を対照グループと比較します。Canary が同等以上のパフォーマンスを示した場合にのみ、ロールアウトを拡張します。

AB テストでは、品質、コスト、およびユーザー満足度を測定するエージェントのバリエーションを比較します。A/B テストでは、改善に関する意思決定の経験的証拠が提供されます。ランダムに選択したユーザーサブセットにバリエーションをリリースして、統計的な妥当性を確保します。複数のディメンション (精度、満足度、コスト、遅延) で結果を測定して、包括的な比較を提供します。

A/B テストを開始する前に、成功条件と仮説を定義します。明確な条件により、一部の指標が改善され、他の指標が低下するあいまいな結果を回避できます。成功条件はビジネス目標と一致する必要があります (「バリエーション B はバリエーション A の精度を 2% 以内に一致させ、コストを 15% 削減する」など)。

チャンピオンチャレンジテストでは、現在のチャンピオンバージョンと比較して改善されたエージェントバージョンがトラフィックのサブセットにリリースされます。チャンピオンとチャレンジャーのパターンでは、フォールバックとして実績のあるバージョンを維持することで改善リスクを管理します。敗者がパフォーマンスが低い場合、ユーザーへの影響なしでチャンピオンに戻します。優勝者が上回る場合は、新しいチャンピオンに昇格します。

統計的な妥当性を得るための最小サンプルサイズ、品質しきい値を超える必要があること、プロモーションを決定する前の評価期間など、客観的なプロモーション条件を設定します。エージェントバージョンが変更された理由の監査履歴を作成する昇格の決定を文書化します。

包括的な監視により、エージェントの業務上の問題を特定するインシデント検出をすばやく確立します。

エージェント障害モードは、従来のアプリケーション障害とは異なります。一般的な障害モードは次のとおりです。

• 幻覚 - もっともらしいが不正確な情報を生成する
• トピック外の応答 - 誤解されたユーザーインテント
• 過剰なコスト消費 - 暴走したトークンの生成
• タイムアウトの失敗 - 推測に時間がかかりすぎます
• 権限エラー - 未承認アクションの試行
• インテグレーションの失敗 - 外部システムが使用不可
• 安全違反 - 不適切なコンテンツの生成

エラー率、品質指標の低下、コストの異常、遅延の増加、ユーザーのエスカレーションに関する自動監視アラートで障害を検出します。報告された自動化のギャップを修正できるように、フィードバック要求やフィードバックの方法と場所に関する明確なガイダンスなどのユーザーの自己報告メカニズムで補足します。

重要度分類では、インシデントが適切な緊急度で適切な対応者に転送されます。重大なインシデントは、多くのユーザーに影響する本番環境の可用性、エージェントのアクションによるデータ破損のリスク、セキュリティ侵害、または迅速な対応が必要な安全違反を示します。重大度が高い場合は、ビジネスクリティカルなエージェントに影響する品質の低下や、大幅なコスト超過を示します。重要度が [Medium (中)] は、営業時間中に調査が必要な問題またはしきい値に近づいていることを示します。重大度が低い場合は、インシデント管理プロセス外で追跡される軽微な問題を示します。

ユーザーへの影響、爆発半径、データ整合性リスク、復旧の緊急度に基づいて、重要度条件を客観的に定義します。目的基準により、実際の問題が過小にエスカレーションされ、軽微な問題が過度にエスカレーションされるのを防ぐことができます。インシデント解決の結果に関するドキュメントを管理して、プロセスを継続的に改善します。

初期対応手順では、状況を安定させる即時のアクションがガイドされます。手順は次のとおりです。

• 失敗したエージェントの無効化 - サーキットブレーカーの有効化
• ユーザーを代替オプション (手動のハンドオフ、シンプルなエージェント、静的応答) に転送する
• 診断情報の収集 - 最近の会話、エラーログ、リソース評価指標
• 関係者 (オンコールエンジニア、製品所有者、影響を受けるユーザー) に通知する
• インシデントコミュニケーションの開始 - 状況ページの更新、内部調整チャネル
• インシデント固有の調査を必要とせずに迅速に実行できるように、初期対応手順をランブックとして文書化します。
• Runbook は、エージェントの深い専門知識がなくてもオンコールエンジニアが実行可能である必要があります。

カスケード障害を回避し、エージェントインシデント中に部分的な機能を維持します。

Circuit Breakerパターンでは、障害が発生したエージェントが自動的に無効化されるため、問題が解決されるまで、繰り返しの障害やユーザーへの影響を回避できます。エラー率を監視し、エラー率が継続期間のしきい値を超えた場合にエージェントをオープンする回路ブレーカーを実装します。

エラーしきい値、期間、回復テストを使用して回路ブレーカーを設定します。たとえば、エラー率が 50% で、対象期間が 5 分の場合や、エージェントが回復したかどうかをテストするように要求する定期的なトライアルなどです。回線が開いたら、要求を代替オプションに転送します。タイムアウト期間が経過すると、回線はハーフオープン状態に移行し、トライアル要求を通過できます。トライアル要求が一貫して成功したら、回路を閉じて通常の動作を再開します。

フォールバック階層により、プライマリ エージェントが失敗したときに正常な機能低下が提供されます。許容される応答が達成されるまで、よりシンプルなオプションを試みるフォールバックシーケンスを設計する。フォールバック階層の例: 高度なプライマリエージェント → シンプルなバックアップエージェント → 静的な FAQ 応答 → 人のハンドオフ。

エージェント内ではなくオーケストレーションレイヤーで代替ロジックを実装し、エージェントエコシステム全体で一貫した動作を実現します。フォールバックパスを定期的にテストし、必要に応じて機能することを確認します。

AIエージェントが要求を処理できない場合、手動のハンドオフは手動エージェントにエスカレーションされます。会話のコンテキストを維持し、引き渡し理由を伝え、関連する専門知識を持つ適切な人間のエージェントに転送し、改善の機会を明らかにする引き渡し頻度を追跡する引き渡しワークフローを設計します。

トピック、エージェント、失敗の理由別にエスカレーション率を監視します。割合が高いほど、エージェントの業務量にギャップがあり、迅速な改善、Knowledgeベースの拡大、使用事例の改善が必要であることを示します。

グレースフル デグラデーションでは、デグラデーション動作中も部分的な機能が維持されます。高度な推論が失敗した場合は、より単純なロジックに戻します。リアルタイムデータが使用できない場合は、キャッシュされたデータで操作します。外部インテグレーションが失敗した場合は、参照のみモードで操作します。グレースフル デグラデーションにより、システムが完全に機能しなくなるのではなく、容量が削減された状態で動作し続けることができます。

個々の障害ではなく、システムの改善に重点を置いた責任のないインシデント後レビューを実施して、正直な評価のために心理的安全性を確保します。

タイムラインの再構築では、初期条件から最初のシグナル、検出、確認、調査、対応アクション、リカバリ、検証までの詳細な順序が作成されます。各イベントにタイムスタンプを付けることで、インシデント対応が遅れたフェーズを分析できます。

タイムラインに以下を含めます。

• 最近リリースされたもの (プロンプト、設定、モデル、インテグレーション)
• どのような使用パターンの変化 (トラフィックの急増、新しい会話種別) が見られましたか?
• どのような外部要因 (サードパーティサービスの低下、プラットフォームの更新) が寄与したか?
• 検出が理想的よりも遅くなった原因は?

根本原因の特定によって、技術的な直接の原因が決定されます。直接的な原因 (モデルタイムアウト) と寄与要因 (特定の会話パターンでトークン制限を超えるプロンプト設計) を区別します。根本原因分析では、効果的な改善につながる特定の結果を優先する単純な結論 (「エージェントにバグがあった」) が導き出されません。

症状から根本原因までドリルダウンする「5 つの理由」手法を使用します。

表面の例: 「エージェントが誤った情報を生成しました」 → 「なぜですか?取得したコンテキストに古いデータが含まれていました” → “Why?Knowledge base was not updated with recent product changes” (最近の製品の変更で知識ベースが更新されなかった) → “Why?No process exists for the product team to trigger Knowledge base updates (製品チームが知識ベースの更新をトリガーするプロセスが存在しない)」 → 根本原因: 製品リリースをKnowledgeベースのメンテナンスに接続するワークフローがありません。

要因により、インシデントの影響を有効化または増幅する組織、プロセス、またはアーキテクチャの状況が明らかになります。一般的な要因として、問題が検知された期間より長く続く監視ギャップ、障害シナリオを明らかにしないままにするテストギャップ、迅速な診断を遅らせるドキュメントギャップ、手動リカバリ手順を強制する自動化ギャップ、単一障害点や冗長性の欠如などのアーキテクチャギャップなどがあります。

寄与要因分析により、根本原因の即時修正以外の改善の機会が明らかになります。ほとんどのインシデントには複数の要因があり、それぞれが影響を増幅しています。

検出分析では、インシデントがどのように検出されたか、および検出がより迅速であったかどうかを調べます。多くのエージェントインシデントは、自動監視ではなくユーザーによって最初に報告されるため、監視のギャップが示されます。Determine (判断): 問題を早期に検出すべきシグナルは?検出を高速化できる監視は?適切に起動されるアラート条件は?

検知分析の改善点として、欠落している監視対象範囲の追加、アラートしきい値のチューニングによる偽陰性の排除、アラートコンテキストの強化による迅速なトリアージ、問題を積極的に特定するためのダッシュボードの改善などがあります。

回答評価では、うまくいった点と、必要以上に遅かった点または難しかった点が評価されます。回答評価の質問: Runbook は役立ち、正確でしたか?エスカレーションパスが明確で効果的でしたか?ロールバック手順はテスト済みですか?ツールによって必要な診断情報は提供されましたか?コミュニケーションはタイムリーで効果的でしたか?

対応評価の改善点として、学習した内容でランブックを更新、エスカレーション条件を明確に、ロールバック手順を定期的にテスト、診断ツールの追加、インシデントコミュニケーションテンプレートの改善などがあります。

アクション項目では、再発の防止や将来の対応の改善のための具体的で割り当てられた期限付きの改善を指定します。「10 分間でエージェントのエラー率が 5% を超えた場合にアラートを追加、割り当て済み: アレックス、期日: 2 週間」など、特定の ToDo を優先するために、「監視の改善」などのあいまいなアクション項目は避けてください。

後続のレビューでアクション項目の完了を追跡し、実際に継続的な改善が行われるようにします。各インシデント後レビューで、以前のインシデントのオープンアクション項目を確認します。完了率が低い場合は、注意が必要な継続的な改善プロセスの失敗を示します。

Knowledge共有では、複数のインシデントにまたがるパターン分析を可能にするタグ付けを使用して、共有Wiki、知識ベース、コラボレーション・スペースでインシデント後のレビューをドキュメント化します。インシデントの遡及は、将来の対応者が過去のインシデントから学習できるように、障害モード、影響を受けるコンポーネント、期間で検索できる必要があります。

インシデント発生後のレビューをインシデント対応担当者以外にも広く共有します。組織の学習には、情報の伝達が必要です。重大インシデントの学習内容をチーム ミーティングやランチ アンド ラーニング セッションで発表してKnowledgeを広め、総合的な能力を構築することを検討してください。

本番エージェントをリリースする前に承認を要求して、レビュー、リスク評価、関係者の調整を行います。

リリース前チェックリストでは、次のような準備状況を検証します。

• 包括的なテストを完了 - 機能、品質、安全性、パフォーマンス
• セキュリティレビューの承認 - 権限境界、データアクセス、アクション承認
• コンプライアンスの検証 - 規制要件、ポリシーの遵守
• 完了ドキュメント - ランブック、ロールバック手順、エスカレーションパス
• 監視の設定 - 品質評価指標、エラー率、コスト追跡
• 関係者の承認を取得 - 商品所有者、セキュリティ、コンプライアンス

チェックリストでは、エージェント間で一貫した評価条件が提供されます。エージェントの重要度、データの機密性、自律性レベルに基づいて、エージェントのリスクプロファイルの深さを調整します。

リスク評価では、エージェントの失敗の潜在的な影響を評価します。これには次のものが含まれます。

• ブラスト半径 - 障害の影響を受けたユーザー数
• データの機密性 - データエージェントがアクセスする内容
• アクション権限 - エージェントが実行できる変更
• インテグレーション連動関係 - どのシステムエージェントが影響するか
• リカバリの複雑さ - ロールバックの難易度
• コンプライアンスへの影響 - 適用される規制

リスク評価によって承認要件が決まります。高リスクのエージェントには役員の承認、セキュリティレビュー、段階的なロールアウトが必要であり、低リスクのエージェントにはピアレビューと標準テストが必要な場合があります。

承認ワークフローは、適切なレビュー担当者を介してリリース申請を転送します。Salesforce 承認プロセスまたは外部リリースツールを使用して承認ワークフローを実装します。承認ワークフローを自動化、追跡、監査して、コンプライアンスレポートとインシデント調査を有効にします。

承認の決定を文書化し、誰がリリースを承認したか、どのような情報に基づいた承認が行われたか、どのような条件または制限が適用されたか、どのような監視コミットメントが実行されたかに関する監査履歴を作成します。

緊急バイパス手順を使用すると、通常の承認プロセスでは重要な修正が遅延する本番インシデント中に迅速にリリースできます。緊急時の手順では、エグゼクティブの承認が必要であり、根拠ドキュメントを含めて、緊急の変更を検証する迅速なリリース後レビューをトリガーする必要があります。

標準リリースとは別に緊急リリースを追跡します。緊急リリース頻度が高い場合は、調査が必要なプロセスの問題を示します。

本番リリース前にエージェントが通過する必要がある品質ゲートを定義して、問題のあるエージェントがユーザーに到達しないようにします。

機能テストでは、エージェントが一般的なシナリオで意図したタスクを正しく実行することを確認します。典型的なインタラクションをカバーするハッピーパス、頻繁ではないが有効なシナリオをカバーするエッジケース、エージェントが無効な入力を適切に処理するかどうかをテストするエラーパス、エージェントがガバナ制限、トークン制限、データ量制限の範囲内にあるかどうかをチェックする境界条件をテストします。

エージェントの機能テストは、非確定的な出力によって完全一致が回避されるため、従来のテストとは異なります。正確なテキストではなく、出力の特性 (必要な情報が含まれていること、適切な語調を維持していること、必要な引用が含まれていること) をテストする。

応答品質テストでは、テストシナリオ全体で応答の精度と関連性が評価されます。品質テストでは、期待される出力を含む人間による評価または根拠に基づくデータセットが必要です。エージェントが満たす必要がある最小品質しきい値を設定します (「保持されたテストセットで 95% の精度、安全違反ゼロ、公正性監査で 5% を超える人口統計学的格差がないことを示す」など)。新しいエッジケースが見つかったら、テストセットを継続的に維持および拡張します。

安全性テストでは、エージェントが危険な要求、非倫理的な要求、または範囲外の要求を拒否することを検証します。安全性テストでは、次のような敵対的な入力が試行されます。

• プロンプトインジェクション試行 - 命令の上書きを試行
• 脱獄試行 - 安全上の制約を迂回しようとする
• エスカレーションの要求 - 機密度の高いアクションの要求
• 範囲外の要求 - 未承認の ToDo の試行

エージェントの作成に関与しなかった独立したチームメンバーに安全テストを割り当てます。高リスクのエージェントの場合は、レッドチームのスペシャリストを招集します。

パフォーマンス テストでは、レイテンシ、スループット、コストが予想どおりであることを確認します。同時会話数、一般的な会話時間、予測される使用量など、現実的な負荷でテストします。パフォーマンステストでは、シングルユーザーテストでは見えなかったガバナ制限の問題、リソース制約、拡張性のボトルネックを明らかにします。

パフォーマンステスト中のテスト環境の消費量を測定し、生産能力のニーズを予測するために使用します。

セキュリティテストでは、権限境界、データアクセス制御、およびアクション承認を検証します。セキュリティテストで確認したところ、エージェントは未承認のデータにアクセスできず、未承認のアクションを実行できず、プロンプトインジェクションで権限をエスカレーションできず、監査ログですべてのエージェント活動が取得されます。

Salesforce Code Analyzerを使用して静的コード セキュリティ スキャンをリリース パイプラインに統合します。Salesforce Code Analyzerは、Apex、フロー、Lightning、Visualforceのセキュリティ脆弱性をスキャンし、CLI(コマンドライン インターフェイス)またはGitHubアクションを使用してCI/CD(継続的インテグレーション/リリース)で実行できます。プロンプトインジェクションの脆弱性と機密データ漏洩のリスクは静的コード分析の範囲外であるランタイム LLM 入力の脅威であるため、特殊な AI/エージェントセキュリティテストを使用して検出します。

変更管理の規律をエージェントのリリースに適用して、変更の文書化、確認、伝達を行います。

変更ドキュメントのキャプチャ：

• 変更内容 - プロンプトの変更、設定の更新、モデルの変更
• その変更が行われた理由 - 品質向上、コストの最適化、バグ修正
• テスト結果、品質スコア、セキュリティスキャンなど、どのようなテストでその変更が検証されたか
• 存在するロールバック手順

変更ドキュメントにより、インシデント調査、コンプライアンス レポート、Knowledge Transferが可能になります。変更を文書化すると、教訓を再発見するのではなく、以前の経験に基づいた学習組織が作成されます。

コミュニケーション計画は、影響を受けるユーザー、運用チーム、サポートチーム、ビジネス関係者など、エージェントの変更について関係者に通知します。コミュニケーションでは、何が変化しているか、いつ変更がリリースされるか、ユーザーにどのようなメリットがあるか、どのようなリスクがあるか、問題が発生した場合に誰に連絡するかを説明します。

メッセージを標準化し、リリース準備のオーバーヘッドを軽減するさまざまな変更種別のコミュニケーションテンプレートを設定します。

リリーススケジュールは、実際の使用パターンを示すイベント監視データによって通知される、使用頻度の低い期間にエージェントのリリースをスケジュールします。ピーク時の使用量、月末の完了、四半期末の完了、または主要なビジネスイベント中のリリースは避けてください。予想される所要時間やロールバック決定タイムラインなど、リリース期間について連絡します。

十分なリソースで問題に対処できるように、週前半から中旬に大幅な変更をスケジュールすることを検討し、週後半のリリースは避けてください。迅速なロールバックと強力なリリース後の監視を固定カレンダールールよりも優先します。

変更期間と凍結により、重要なビジネス期間を保護します。重要なビジネスイベント (年度末、製品発売、主要なマーケティングキャンペーン) の前に変更凍結期間を設定し、重要な期間中にリリースによって問題が発生するのを防ぎます。

ドキュメント変更の凍結カレンダーでは、制限された期間を十分に事前に伝え、それに応じてチームが計画できるようにします。過度に凍結すると速度が遅くなり、凍結が不十分だとビジネスリスクが生じます。

業務テレメトリをエージェントの改善に結び付けるフィードバックループを確立します。

ユーザーフィードバック収集では、質問またはフォローアップアンケートを通じて明示的なフィードバックを収集します。完了率、人間のエージェントへのエスカレーション、再試行パターン、不満を示すフォローアップの質問を通じて、暗黙的なフィードバックを収集します。明示的なシグナルと暗黙的なシグナルを組み合わせて、包括的な品質の視点を提供します。

フィードバックは、後で収集するのではなく、発生時にインラインで収集します。フィードバック収集が遅れると、回答率が低下し、リコールバイアスが発生します。

利用状況分析では、繰り返されるトピック、質問、トレンドなどの実際の会話パターンが公開されます。エージェントの複雑さが維持できているかどうか、検出可能性が低いために機能が使用されていないかどうか、実際の使用状況で元の設計の前提条件が検証されているかどうかをテストします。

質問種別、会話の長さ、トピック別の成功率、会話の特性別のユーザー満足度を分析する会話ログを照会します。使用パターン分析のガイドに従って、迅速な調整、Knowledgeベースの拡張、機能の優先順位付けを行います。

エラーパターン分析では、修復が必要な体系的な品質問題を特定します。エラー種別、影響を受けたユーザー、会話パターン、一時的な分布別にエラーログのグルーピングを分析します。エラーパターンにより、プロンプトの問題、Knowledgeベースのギャップ、インテグレーションの問題、処理が必要なエッジケースが明らかになります。

エラーの修正を頻度と影響で優先度付けします。多くのユーザーに影響する高頻度のエラーには、すぐに対応する必要があります。低頻度のエラーは、ビジネスへの影響と修正コストに応じて、許容されるエッジケースを表す可能性があります。

品質トレンド監視は、精度、関連性、安全性、満足度を経時的に追跡し、劣化が酷くなる前に検出します。エージェントの初期リリース後に品質ベースラインを確立します。トレンドが許容しきい値を超えて低下した場合のベースラインアラートに対して進行中の品質を監視します。

品質監視により、迅速な変更、モデルの更新、またはKnowledgeベースの変更によってパフォーマンスが改善されるか低下するかが明らかになり、データ主導の改善の意思決定が可能になります。

経験的証拠を使用して、改善の意思決定に役立つ実験を体系的に追跡します。

実験フレームワークでは、次のようなテスト改善のための一貫した構造が提供されます。

• 仮説 - どのような改善が期待されるか
• 実験計画 - バリエーションのリリース方法
• 総計値 - 測定される結果
• サンプルサイズ - 統計的妥当性に必要なインタラクションの数
• 成功条件 - プロモーションを正当化する結果

実行前に実験を文書化して、結果があいまいに解釈されないようにします。定義済みの成功条件により、結果が「十分」かどうかについて長時間議論することなく、明確なプロモーション決定を行うことができます。

バリエーション追跡では、結果の相関関係を有効にするために、どのユーザーがどのバリエーションを受信したかがログに記録されます。会話メタデータでバリエーションの割り当てを追跡し、バリエーション別に品質、コスト、満足度を分析できるようにします。

統計的妥当性により、信頼できる結論を得るのに十分なサンプルサイズで実験を十分に実行できます。期待される効果サイズ、統計的検出力要件、許容誤差率に基づいて、実験前に必要なサンプルサイズを計算します。サンプルが不十分な場合、ノイズの多い結果になり、判断が甘くなります。

Multi-Armed Bandit Optimization では、実験中にパフォーマンスの高いバリエーションにより多くのトラフィックが動的に割り当てられます。多腕バンディットアプローチでは、統計的分析に十分なデータを収集しながら、下位のバリエーションにさらされるリスクを減らすことで、実験の機会コストを削減します。

実験カタログには、すべての実験のバリエーション、結果、決定が記録されます。これにより、チームは失敗したアプローチを再テストする必要がなくなり、学習が組織全体に広がり、実際に機能するものの共有レコードが作成されます。

エージェントシステムの優れた運用性を実現するには、従来の DevOps プラクティスを拡張して独自の AI 特性に対応する必要があります。包括的な観測性により、エージェントの行動を把握できます。体系的なライフサイクル管理により、品質、安全性、コスト管理が確保されます。インシデント対応手順は、エージェント固有の失敗モードに対応します。継続的な改善により、業務環境が組織の能力に変換されます。

エージェントシステムで優れた運用を行うための主要なプラクティス:

• 入力、出力、推論の追跡、アクション、結果を含む完全な会話を記録します。
• 精度、関連性、安全性、満足度の総計値を使用して、応答品質を継続的に監視します。
• ベースラインの比較と異常検出により、モデルのドリフトと行動の変化を検出します。
• ロールバックと A/B テストを可能にするバージョン管理のプロンプト、設定、モデル。
• 特徴フラグとカナリアリリースを使用して、ブラスト半径を制限する段階的なロールアウトを実装します。
• カスケードエージェント障害を防止する回路ブレーカーとフォールバック階層を設計します。
• 体系的な改善に焦点を絞って、責任のないインシデント後レビューを実施します。
• 品質ゲートと承認プロセスを確立して、問題のあるエージェントが本番に到達するのを防ぎます。
• 業務テレメトリをエージェントの改善に結び付けるフィードバックループを構築します。
• 経験的証拠を使用して実験を系統的に追跡し、機能強化の意思決定を導きます。

エージェントの運用性に投資している組織は、ビジネスニーズに応じて継続的に進化する信頼性の高い高品質の AI 機能を通じて、持続的な競争優位性を獲得できます。

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