AIエージェントの可観測性：業務失敗を調査

AIエージェントの可観測性は、業務タスクに何が起きたかを運用者が説明するためのものです。モデルの遅延やトークン使用量のグラフでは、どの顧客記録が変わったか、要求がなぜ拒否されたか、不確かな操作を誰が担当するかには答えられません。

エージェント、ツール、送付先のシステムを通じてタスク全体を観察します。機密内容を無制限に収集せず、範囲を限定した識別子、有意味な状態遷移、独立した結果の証拠を保持します。介入が必要な仕事を警告し、各警告に明確な調査責任者を付けます。

注文を確認した後にCRMのフォローアップを作るエージェントを考えます。ユーザーには完了と伝えますが、営業部門は記録を見つけられません。調査には元の要求、選んだアカウント、ツール呼出し、送付先の参照、観測した結果を結ぶ必要があります。モデルの応答ログだけでは不十分です。

このガイドは実際の運用を扱います。当社のAIエージェント評価ガイド は公開前の受入れを扱います。両者は結果の定義を共有し、それぞれの目的を保つべきです。

タスクを中心にAIエージェントの可観測性を定義する

同僚が認識できる仕事の単位を特定します。問い合わせ、注文の質問、下書きの承認などです。安定した参照を与え、待機、拒否、完了、未解決を含む受入れ可能な状態を定義します。

実行の成功と業務の成功を分けます。ツールは技術上受け入れられる応答を返しても、送付先では確認待ちのキューに入る場合があります。可観測性の設計は、エラーでない結果をすべて完了にせず、この違いを見せるべきです。

画面、計測、サポート手順でこの定義を一貫して使います。ユーザーが完了を見て運用画面がキュー待ちを示す場合、違いを説明すべきです。そうしないと、見かけの可観測性が同じタスクについて矛盾した説明を生みます。

要求、ツール、送付先を関連付ける

OpenTelemetryのトレース概念 は、操作を関連付けるスパンと伝播する文脈を説明します。これらはサービス間の技術活動を結べます。しかし業務の完了ルールは定義しません。アプリケーションが適切な結果の証拠を追加する必要があります。

タスク、実行の試行、外部操作の関係を保持します。一つのタスクには複数のモデル呼出しや再試行があり得ます。一回の実行が、後で非同期に続く仕事を作る場合もあります。モデル要求の件数を、完了した業務タスクの件数と同一視しないでください。

適切な場合はキューや人への引継ぎにも文脈を渡します。運用者は無関係な画面の時刻を手動照合することなく、タスク参照から関連ツールと送付先の結果へ移動できるべきです。

動作に影響した版を記録します。アプリケーションの導入、関連ツールの定義、指示設定です。機密性の高い指示内容は管理します。目的は何が実行されたかの特定であり、すべての内部設定値をすべての画面利用者へ公開することではありません。

すべてを記録せず有用な証拠を取得する

調査の質問から始めます。どのアカウントを選んだか。どの操作を要求したか。何の権限を適用したか。何の応答を観測したか。多くは無制限のメッセージや文書内容でなく、参照、状態、理由コードで答えられます。

OWASPのログガイダンス は、除外または慎重に扱うべき機密データを説明します。指示、応答、ツール引数を計測の供給者へ送る前に適用します。デバッグの便利さは、顧客記録を無期限に保存する目的にはなりません。

目的と影響で保存期間を定義します。短期の診断データと長期の商取引の承認記録は扱いが違うかもしれません。すべてを一つの汎用ログ保存先に入れず、誰が内容を取得できるか、アクセスをどう確認するか記録します。

モデルの問題と連携の問題を区別する

タスクの失敗は誤解釈、権限の欠落、古い元データ、利用不能な送付先、どの構成要素も実装していない業務ルールから生じ得ます。モデルや指示を変える前に、経路を区別するだけの文脈を保持します。

例えば正しいツール選択も、送付先の資格情報が期限切れなら失敗します。逆に正常なAPI応答に、誤った顧客照合が伴う場合もあります。技術の可用性指標と結果の確認は異なる質問に答え、両方とも有用です。

不確かな結果を見える状態に保つ

書込みがタイムアウトしたときは不確実さと検査の参照を記録します。応答が届かなかっただけで、試行を確実な失敗として記録しないでください。次の運用者は、再実行が別の業務影響を生むか知る必要があります。

当社のMCPサーバー開発ガイドは、プロトコル連携でのこの境界を説明します。直接APIや別のツールを使う場合にも、書込みを断定する前に送付先を確認するという同じ原則が適用されます。

行動可能な運用条件を警告する

警告は人の行動が必要な仕事を示すべきです。責任者のいない不確かな書込み、合意した時間を超えた確認キュー、送付先の確認に届かない受け入れ済みタスクの増加などです。業務の運用上の必要からしきい値を選びます。

日常的な拒否を毎回警告するのは避けます。正しく拒否した要求には介入が不要かもしれません。予想する方針の動作と、権限の不具合、敵対的入力、新たな非対応顧客事例を示すパターンを区別します。

最初の調査手順と上位対応の責任者を指定します。タスク参照や送付先の文脈のない「エージェントエラー」という警告は、繰り返す推測を招きます。責任者のいる手順書は、再試行できること、確認すべきこと、承認が必要な操作を説明すべきです。

管理した障害で警告経路をテストします。意図したキューや運用者の受信を検証し、参照が使える証拠へつながることを確認します。監視画面にルールが見えるだけでは、当番の同僚が失敗を解決できる証拠にはなりません。

受け入れた結果を画面に反映する

対応するタスクの種類を分けて報告します。日常的な照会が集計の大半を占めると、少数だが重要な書込み操作の低い成果を隠します。完了と拒否とともに、待機中と不確かな仕事を示します。

関連する業務境界から時間を測ります。モデルの応答時間には、確認キューや遅れた送付先処理の時間が含まれないかもしれません。最初の受付、承認済みの下書き、完了した外部操作のどれを利用者が重視するか決め、その指標名を付けます。

訂正作業と再開したタスクを観測します。速く完了しても担当者が直す記録を作るエージェントは、要求画面では効率的に見えます。可能なら修復を元のタスクに結び付け、運用の見え方に影響を含めます。

計測の範囲制約を明確にします。サンプリング、提供元の境界、過去の記録欠落は調査を制限します。重要な操作に何の証拠を保持するか示し、データがないのに過去のすべてを再構成できると示唆しないでください。

規約と供給者を意図的に選ぶ

元の実装者しか理解しない画面より、文書化したデータ仕様と書出し経路を優先します。採用前にエージェント用の計測規約の現在の状態を確認します。このガイドは、変わり続ける意味の規約が永続的な安定スキーマだとは仮定しません。

OpenTelemetryの生成AI規約のお知らせ は、現在保守するリポジトリに読者を案内します。実装ではその保守先に従います。ライブラリの属性名が変わっても、アプリケーションのタスクと結果の意味を文書に残します。

調査能力、データ取扱い、保存、アクセス制御、運用費用で供給者を比較します。見栄えのよいトレース表示も、業務に必要な証拠を受け取り、権限を持つ運用者が解釈できて初めて有用です。

計測の失敗も設計に含めます。監視の送付先が使えないときも保持すべき業務記録を決めます。診断トレースの喪失が、承認された外部操作の唯一の記録を黙って消してはいけません。

費用と有用な最初の成果物を定める

タスク状態設計、計測の追加、送付先との関連付け、警告、運用引継ぎを分けたGBPの提案を求めます。継続する保存、取込み、確認費用を含めます。すべてのトークンやツールデータの記録は、相応の調査価値を伴わず費用を生む場合があります。

当社のAI連携の限定範囲の試行 は、現在チームが説明しづらいタスクから始められます。欠けた結果と現在ある証拠をお送りください 。具体的な運用判断を支える計測をご相談いただけます。

よくある質問

AIエージェントの可観測性とは何ですか？ 関連する技術と運用の証拠から、エージェントの動作と業務結果を調査する能力です。有用な範囲にはタスク状態、ツール活動、権限、送付先への影響、人への引継ぎが含まれます。

指示のログだけで十分ですか？ いいえ。モデルの入力と出力は分かりますが、外部操作の完了や影響したアカウントを確認できない場合があります。送付先の証拠と安定した参照を保持します。

すべてのツール引数と応答を取得すべきですか？ 標準でそうするべきではありません。調査の質問から始め、回答できる最も機密性の低い証拠を集めます。保持する内容には明確な目的、アクセス方針、保存の取決めが必要です。

評価とどう違いますか？ 評価は合意した事例を確認して公開の判断を支えます。可観測性は実際の仕事の調査を支えます。結果の定義を共有すべきですが、テストの合格は運用証拠に代わりません。

何が警告を発生させるべきですか？ 責任者のいない不確かな書込みや、合意した待機時間を超えるタスクなど、介入が必要な条件です。予想される拒否すべてで呼び出す必要はありません。行動可能な参照と調査経路が警告にあることをテストします。

すべての過去のタスクを診断できますか？ 必要な証拠を保持し関連付けられる範囲に限ります。サンプリング、保存期間、外部提供元の可視性には制約があります。それを文書化し、重要な業務操作に必要な記録を意図的に保管します。

有用な最初のプロジェクトは何ですか？ 繰り返す調査の問題を一つ選びます。タスク状態を図にし、欠けた参照を追加し、送付先の証拠を検証し、警告やサポート経路を試します。チームが証拠を使えるようになってから拡大します。