ガイド
AI エージェントの観察能力: 追跡,メトリック,レビューに関する実用的なガイド
AI エージェントの観察可能性実行コストはどれか,最終結果は受け入れられるかどうか, どのツールやデータを使用したかを再構築する能力です. 遅延とエラーのみを表示するダッシュボードは十分ではありません 代理人の行動は変化するので チームは 敏感なコンテンツの追跡や評価や ビジネス結果や レビュー経路も必要です
調査と透明性: このガイドにはOpenTelemetryのエージェント観察性作業 OpenTelemetry 语義のコンベンション NIST AI リスク管理枠組み2026年9月4日 レビューされました 下記のオペレーティングモデルは オートマインドのパフォーマンス基準ではなく,オリジナルの編集枠組みです.
観察可能な物質は
有用なシステムは,関係のないログから実行を再構築するようにエンジニアに要求せずに,6つの質問に答えなければなりません.
- 実行を開始した目標,指示,モデル,インプットとは?
- どれだけのモデル電話,検索,ツール,承認が行われたのか?
- 歩みごとに 何を得て 何に戻ったのか?
- ランニングはどこで再び試みたのか 停滞したのか 支線したのか それとも失敗したのか
- 成果は,課題に特定する質の限界を満たしたのでしょうか?
- 審査員が 制限されたデータを公開せずに証拠を再現できるのか?
伝統的なアプリケーションモニタリングは依然として重要だ. サービスが機能しているか否かを示すのは 利用可能性,遅延性,エラー率です サービスが正しい仕事をしたか判断するために必要なタスクレベルのコンテキストを添加します
4層の観測可能モデル
| 層 | 捕獲 | 回答された質問 |
|---|---|---|
| 走る | 目標,バージョン,モデル,ユーザー,環境,最終状態 | 全体的に何が起こったのか? |
| 痕跡 | モデル通話 ツール通話 送付 再試 承認 | 捜査官はどうやってそこに来たの? |
| 評価 | 根拠性,完全性,政策,形式,人数 | 結果は十分だったのか? |
| 結果 | 受け入れ,修正時間,完了,事業影響 | 仕事が役に立ったのか? |
単一のスコアに 層を崩してはいけません 速く走れば悪い報告が出せる. 報告は遅すぎるかもしれません 受け入れられた納品品は,決して追跡すべきでないデータを暴露することができる.
最低イベントスケーマ
代理や道具が発信できる小さなイベント契約から始めましょう
{
"run_id": "run_123",
"step_id": "step_07",
"parent_step_id": "step_03",
"operation": "tool.call",
"tool": "document_search",
"started_at": "2026-09-04T09:00:00Z",
"duration_ms": 842,
"status": "ok",
"input_classification": "confidential",
"content_recorded": false,
"tokens": 0,
"cost_usd": 0,
"evaluation_refs": ["eval_19"]
}安定した実行と親識別子は,シーケンスを再構築できる. 提示,モデル,ツール,ポリシーのためのバージョンを記録し, 逆転が変化に結びつけられるようにします. 初期提示と出力をオプションに設定する:メタデータは通常運用分析に十分だが,コンテンツのキャプチャはプライバシーと保存義務を伴う.
4つの識別子を区別する
workflow_id耐久性のある製品または事業プロセスの名称workflow_version提示,ツール,モデル,ルールのテストされた構成を識別する.run_id実行中の全てのステップを繋げますthread_id関連リンクは会話や長い作業を介して実行されます
ユーザー ID を 糸または実行 ID として再利用しないでください. 識別を別々に制御されたフィールドで保持し,分析が直接識別を必要としない場合,偽名参照を使用する. 製造元または事業記録のIDをポリシーが許可する場合にのみ添付します.
展開,環境,実験,ソースセットのバージョンを追加する. これらの次元は,リリース後に失敗が始まって,一つの集団に影響を与え,または古い知識の収集に依存するかどうか,答えます.
代理人の行動を示すメトリック
数十のチャートを追加する前にコンパクトセットを追跡する
- 作業タイプによる完成と放棄の割合
- 実行および各ツールにおける中位および尾間遅延
- ツール失敗,再試し,反発率
- ステップ,トークン,および受付された結果ごとに費用
- 証拠が重要である場合,根拠性または引用の覆い;
- 人間に修正された時間と拒否理由
- 政策のブロック,承認の要請,許可拒否.
ワークフローバージョンと代表的なタスクによってメトリックをセグメントする. 総平均は,一つの文書タイプまたは一つのツール統合が繰り返し失敗することを隠すことができます.
目標から結果まで 走る
審査員を対象とした調査機関を 検討してみてください 最終文書には1人の競合他社に対する誤った価格が含まれています 役に立たない痕跡は,審査員を走行中に後退させなければならない.
- 成果記録は,簡報が拒否されたことを示し,価格設定の誤りを標識する.
- 最終合成期間では,どの抽出された価格行が文を提供したかを特定します.
- 復元期間では,現在の価格表表の上にあるアーカイブされた支援記事が表示されています.
- ソースメタデータは有効日付のフィールドや現在の公式ページを好むルールを示していません.
- 作業流のバージョンでは,最近の検索変更により日付フィルタが削除されたことを示しています.
修正法は"より良いモデルを使用する"というだけでは不十分です. ソース優先順位ルールを復元し, 評価セットに 拒否された実行を追加し, 時間敏感な他の請求をテストし, アーカイブされたページから取得を監視します. 観測可能性は,目に見える欠陥をテスト可能な変化に結びつけることで価値を生み出します.
リンクされた追跡がない場合,チームは単一の価格を編集したり,課題を再試したり,その裏にある回収失敗が残っているかどうかを知らないうちにプロンプトを変更することができます.
デザインは意思決定を中心に広がる
追跡は,すべての補助機能がスパンで,全ランが1スパンで,不完全であるときに読み取れないものになります. 楽器の意味のある作業単位:
- 目標の摂取と政策分類
- 計画作成またはルート選択
- モデル呼び出しごとに
- 検索クエリと返信ソースセット
- すべての外部ツール呼び出しと結果
- 状態や記憶は読み書きする
- 再び試み,後退し,決定を停止する
- 人からの承認の要請と応答
- 遺体作成と検証
- 最終的な配達とユーザー結果
原因を共有する,直線通話スタックではなく,同期的なタスクで 結束するリンクを使用します. 安定した操作名付け ツール名,ワークフローバージョン,ドキュメントクラスなどの変数値を属性に挿入して,何千ものメトリック名を作成せずにフィルタすることができます.
隠れた推論ではなく,十分な文脈を記録する
目的は観察可能な入力,出力,決定,および状態移行を捕捉することです. 個人的な思考の鎖や 言語的な内なる推論に頼らないでください 経路フィールドのようなselected_tool=document_search制限のない推論の書き換えよりも有用で管理可能です
失敗した決定については,その決定を規制すべき政策や評価者,その時点で入手可能な証拠,および結果となる行動を記入してください. 細かい物語に 変えてしまうことなく デバッグをサポートします
リアルな故障モードから評価を作成する
流暢性や有用性といった 一般的な指標は 十分ではない. ワークフロー契約から評価の次元を定義する.
研究要約では,有用な次元は以下を含むことができる.
| サイズ | 決定的なチェック | 人力またはモデルによるチェック |
|---|---|---|
| ソースカバー | 必要なソースIDが表示されます | ソースは適切な文脈で使用されます |
| 引用の有効性 | リンクとドキュメントの位置を解決する | 通過は近付近の主張を支持する |
| 鮮やかさ | 現在の請求は,受け入れられる日付がある | 古い文脈は適正に資格がある |
| 完全性 | 必要な部門と競合他社が存在します | 決定関連のギャップが浮上 |
| 強制的な遵守 | 文字制限,フォーマット,禁止されたアクション | 聴衆 に 適した 音色 と 優先順位 |
| 結果 | 納品が完了し,アーティファクトが開かれます | 審査員は,修正が限られたままに受け入れます |
3つの評価段階を使用します
- **リリース前回帰:**作業流のバージョンが発送される前に実行される固定ケース.
- **生産サンプル:**リアルランの定義された割合は自動化または人間によるレビューを受けます.
- **失敗の促進:**拒絶された,修正された,または異常な実行は,レグレーションケースと標識される.
評価提示,評価モデル, rubrics,およびデータセットをバージョンアップしておく. 判事が変わると 判事が変わると 判事が変わると 判事のスコアを 基準値と比べてみないで
ワークフローのサービス目標を定義する
応用作業時間では,エージェントが有用な作業を完了するか否かを記述しません. 任務レベルサービス指標を追加する
- 芸術品を生産する対象となる走行の割合
- 重要な修正なしに受け入れられた割合
- 要求から審査準備の準備の結果までの時間
- 適切な所有者に増加した割合
- 受け入れられた結果に対する最大コスト
- ソースの裏付けのある作品の引用または証拠のカバー
- 政策に準拠する完成率
ワークフロークラスによって目標を作成する. 5分間の研究メモと 10秒間のサポート応答は 遅延目標を共有すべきではありません. 文書化されたルールによってのみ無効な入力を排除するか,またはチームは難しい失敗を再分類することによって信頼性を良くすることができます.
症状について警告
評価が低い点に 誰かを呼び出すのを避ける 警告は,制限された運用応答を特定すべきである.
| 信号 | 可能な限界 | 最初の反応 |
|---|---|---|
| ツールエラー率 | 10分間の出頭線を超え | 依存性と反発行動をチェック |
| 深度試行 | 許可されたステップを超えた繰り返しループ | 影響を受けた走行を停止し,ルート論理を検査する |
| 受け入れられた任務の費用 | ワークフローバージョンで予算が超え | モデル,文脈,再試の変更を比較する |
| 引用の失敗 | 重要な主張またはサンプル率上昇 | 公開を継続し,回収を検査する |
| 許可拒否 | ツールやユーザの役割によって突然増加 | 識別と展開設定を確認 |
| 安全やプライバシーイベント | 影響が高い事件が確認されました | 事件のプロセスを直ちに起動する |
流行情報や欠陥のチケット,緊急事態に関するページを チェックする 操作者が目覚めるたびに 警戒疲労は 実際に介入を必要とするイベントを隠す.
サンプル採取戦略を選択する
完全なメタデータキャプチャは,各実行で十分安価である一方,完全なコンテンツ保持とモデルベースの評価は,それほど安価ではない. 採樣規則を組み合わせる
- ランダムな採取劇的な失敗のみを選択せずに正常な品質を推定する.
- リスクサンプル影響的なワークフローからより多くの実行をレビューする
- 事件サンプル誤り,ポリシーブロック,高価なループ,ユーザー拒否を保持する
- 変化サンプルモデル,プロンプト,リクエスト,またはツールリリース後にカバーを増加させる.
- 段落サンプル希少言語,文書タイプ,ユーザー役割,エッジケースが表示されます.
- 追跡一貫した採樣接続を断つよりも,完全な多段階走行を維持します.
名前記号を記録する ダーッシュボードが 95% の合格率を表示している場合,成功した実行のみで,放棄されたおよびブロックされた作業は測定から消えた.
盲点検定のサンプルをチェック 遅いまたは失敗した走行のみを保持する規則は,日常的な品質を評価することはできません. 純粋なランダムサンプル採取は,まれな高影響事件を逃す可能性があります. 関連記録政策の下で,例行採取から独立して確認された事件を保存する.
遠隔測定をユーザーフィードバックと調和させる
実行に明示的な拒否,修正,再試,エスカレーション,サポートチケット,および受け入れられたアーティファクト信号を接続します 会話を終了したユーザーから満足を推測しないでください.
間違ったソース,欠けている要求,時代遅れの情報,安全性の低い行動,格式が悪い,遅すぎ,高価すぎなどの 構造的なフィードバック理由を作成します 文脈に合わせて 選択可能な文本を保存する. しかし,分析を手動で読むことに頼りにしないようにする.
自動評価者に反響が矛盾する場合は ケースを検査してください ユーザが間違っているか,評価者が不具合なかもしれないし,ワークフローは実際の結果に一致しない技術的な rubric を最適化しているかもしれない. これらの意見の不一致は価値ある評価事例です
事件の調査を
事件のレビューは無垢で追跡可能であるべきです
ユーザー影響と影響を受けた走行:
検出時間と信号:
ワークフロー,プロンプト,モデル,ツール,ポリシーバージョン:
予想される行動:
観測された順序:
ソース,状態,または許可に関与する:
なぜ既存の評価がそれを捉えなかったのか:
すぐ封鎖:
修正・変更と所有者:
逆転事件は
変化の監視:
追跡日:誘発エラーとシステム貢献者との分離 モデルが無効な議論を発信するかもしれないが,ツール契約もそれを受け入れ,リトライループはそれを繰り返し,評価はツール結果を無視する可能性がある. システムに脆弱性を与えるのは 最初の目に見える故障のみです
4つの段階で観察可能性を展開する
ステージ1: 単行走を再構築する
ツール 1 制限されたワークフロー 端から端まで エンジニアとドメインレビューが 失敗したランを 追跡から独立して説明できることを確認します
ステージ2: 品質を接続する
決定的な検証,審査員ラベル,および受け入れられたまたは拒否された結果を添付する. 観測された失敗から小さな回帰セットを作る
段階3:生産量で稼働する
サンプル採取,保存,編集,ダッシュボード,および実行可能なアラートを定義する. 遠隔測定コストを測定し,追跡が制限されたデータを暴露しないことを確認する.
段階 4: 体系的に改善する
変更を優先するため,固定データセットのバージョンを比較し,生産における効果を確認するため,故障クラスタを使用します. 古いメトリックを検証し,もはや意思決定を促さないテレメトリを取り除きます.
週間のレビューテンプレート
ワークフローとバージョン:
ユーザー予想結果:
代表の成功ランキング:
代表の失敗または修正された実行:
最大の故障モード:
前回のレビュー以降の変更:
遅延とコスト変動:
評価シフト:
プライバシーまたは許可の事件:
来週の実験です
オーナーと審査日:平均値だけでなく サンプル失敗です 清潔なラン,高価なラン,拒否された結果,人間による介入を必要とするランを少なくとも1回見直してください. 緑のステータスパネルが欠けている行動を 明らかにします
プライバシーとセキュリティの境界線
観測可能データには提示,ファイル名,取得した段落,ツール・アルグメント,認証,個人データ,ビジネス決定が含まれます. 生産データとして分類する 輸出前に秘密を書き直し,メタデータからコンテンツを分離し,アクセス制限し,保存を定義し,敏感な痕跡を検査した記録を記録する.
少なくとも3つのキャプチャモードを作成する メタデータのみモードは,タイミング,状態,バージョン,分類,ハッシュを記録します. 編集されたモードは自動フィルタリング後に制限されたコンテンツを保持します. 制限診断モードでは,指定アクセスで短い期間で承認されたコンテンツを記録します. 作業流は,個々の開発者ではなく,データ分類からモードを選択する必要があります.
テストの編集は テレメトリが処理を終了する前に 裏端設定は すでに送信された秘密を守ることはできません 導出されたデータも確認します. ドキュメントのタイトル,ツール・アルグメント,埋め込み,エラーメッセージ,評価者説明は,メインプロンプトが削除された場合でも敏感なコンテンツを明らかにできます.
期限チェックリスト
[ ] 各生産ランには安定したワークフローとバージョン識別子が備わっています.
[ ] モデル,回収,ツール,状態,承認,およびアーテファクトのステップは接続されています.
[ ] 敏感なコンテンツのキャプチャは,文書化された分類規則に従います.
[ ] 受け入れられた,修正された,拒絶された,そして放棄された結果が痕跡に結びつきます.
[ ] 評価は任務契約を反映し,バージョン化されています.
[ ] 失敗した生産ランは,レグレーションデータセットに推進することができる.
[ ] アラートには主人がいて 定義された最初の反応があります
[ ] 保存,アクセス,輸出,削除がテストされた.
[ ] 代償には,モデルトークンだけでなく,テレメトリの保存と評価が含まれます.
[ ] 域を検証する人は 技術的な助けなしに結果を再構築することができます.脅威モデルをより広く見ることができる場合,AI エージェントのセキュリティチェックリスト。 構成要素の境界とオーケストラ契約については,AI エージェントの建築ガイド。
常識
AIエージェントの監視と観察性の違いは何ですか?
監視は故障,遅延,コストなどの知られた信号を報告する. 観測可能性は 予測しなかった行動を調査するための 十分な証拠を 提供します ツール選択,再試,文脈,評価,および人間の修正を含む.
提示と応答を 保存すべきか?
違うわ 運用および監査目的のために必要な最小限のデータを保存する. 可能な限りメタデータとハッシュを好む 秘密を編集する 作業分類によるコンテンツのキャプチャを制限し,保存期間を設定する
新しいチームがどんなメトリックから始めればいいのか?
制限されたワークフローの完了率と修正時間から始めましょう 費用,遅延,失敗モードのメトリックをその結果に追加します
観察能力はオフライン評価を 置き換えますか?
違うわ 公開前に知られている症例をオフライン評価テスト 生産観察性は,実際の入力,ツール,ユーザーがリリース後にどのように振る舞うかを示しています. 信頼性の高いチームは 両方を使っています
生産トラフィックのサンプルをどれぐらい採取すべきか.
普遍的な割合はありません. 低リスクメタデータを広く把握し,その後に容量,リスク,コスト,故障頻度に基づいてコンテンツと評価サンプルを選択します. 承認された政策の下で確認された事件を常に保持します.
痕跡はどれくらい保持すべきか?
誤差処理,評価,監査,または契約目的が要求する限りのみ保存する. 材料の原料については,より短い期間,累積されたメトリックについては,より長い期間,確認された事件については,文書化された保存を用いること.
捜査官の痕跡を誰が調べるべきか?
エンジニアは実行や統合障害を検証する ドメイン所有者はタスクの質を検証する 安全とプライバシーチームは関連事故を検証する 役割に基づくアクセスには,敏感なコンテンツの広範な閲覧が妨げられるべきである.
観察能力は 提示を自分で改善できるのか?
証拠を提示する 自動修正ではない 失敗クラスタを使用して変更を提案し,バージョン化されたケースでテストし,利益が他の場所での回帰を生じないことを確認します.
最初のダッシュボードは?
1 つのワークフローでは,有効な実行,受け入れられた完了,拒否理由,修正時間,遅延,コスト,エスカレーション,および現在のワークフローバージョンを表示します. 検査可能な走行にすべての agregate をリンクする.
品質を測定するために ユーザーフィードバックは十分ですか?
違うわ 意見は価値あるが 完全でないし 自分で選択するものです 作業検証,代表的なサンプリング,ドメインレビュー,および観察された結果と組み合わせます
失敗した走りは常に維持されるべきか?
調査およびポリシーを満たすために必要な証拠を保持し,データ最小化,アクセス,保存規則を適用する. 障害は,敏感なコンテンツを無期限に保存することを自動的に正当化するものではありません.
Ottermind で範囲を限定したソースベースのワークフローを実行し、成果物をレビューして、最初の評価セットとなる修正内容を記録してください。
