関連付けられた実行トレース (Correlated Run Trace)
単一の識別子が、エージェントの実行全体（入力、モデルとバージョン、引数と結果を伴うすべてのツール呼び出し、最終的なアクション）をスレッド化し、数ヶ月後でも再現可能な記録としてまとめます。難しいのはキャプチャすること自体ではありません。実行を再構成できるほど完全でありながら、トレースストアが記述対象データの単なる二重コピーにならないよう抑制を効かせることです。
定義
関連付けられた実行トレースとは、エージェントの実行におけるすべての決定と行動を記録した、単一の識別子を持つ不変のレコードです。これは、実行を生成したシステムにアクセスすることなく、後からエンドツーエンドで実行を再構成できるほどの忠実度でキャプチャされ、かつトレース自体が元のソースよりも脆弱な標的にならないよう墨消し（編集）が施されています。これはリクエストログではなく、エージェントの意思決定の記録です。
課題
エージェントは非決定論的かつマルチステップであるため、出力から「何が起こったか」を推測することはできません。ほとんどの開発チームはログを記録していますが、それでも特定の実行がなぜそのような動作をしたのかを説明できません。各ステップが共有識別子のない異なるシステムに存在していたり、プロンプトがその後変更されたテンプレート参照として記録されていたり、モデルのバージョンがキャプチャされていなかったりするため、動作が変化したのか、それともモデル自体が変化したのかを誰も判断できないのです。
適用対象
後から誰かにその行動の結果について問われる可能性のある、あらゆるエージェントが対象となります。例えば、トレースが監査証跡となり、トレーサビリティが単なる好みではなく義務である規制プロセス、根本原因の特定が必要なインシデント、結果に異議を唱える顧客、あるいは学習のために実際の失敗事例を必要とする評価ループなどがこれに該当します。
解決策
エントリーポイントで実行識別子を1つ生成し、すべてのステップ、サービス、リトライに伝播させます。相関関係こそが価値のすべてです。同じ実行のリンクされていないレコードは、トレースではなく、単なる3つのログにすぎません。
テンプレートへの参照ではなく、レンダリングされたプロンプトそのものを記録します。テンプレートIDが解決するのは「今日のテンプレートの内容」であり、モデルが実際に目にしたものではありません。
すべての呼び出しにおいて、モデルとそのバージョンを併せてキャプチャします。これがないと、事後的に挙動の変化とモデルの変化を区別することができなくなります。
ツール呼び出しは、引数と結果（失敗やリトライを含む）をログに記録します。成功した呼び出しのみを示すトレースは、実際には起こらなかった実行を記述していることになります。
読み取り時ではなく、キャプチャ時にマスキングを行います。レコードが書き込まれる前に、機密情報や個人データを削除またはハッシュ化するフィールドレベルのルールを適用します。クエリ実行時にマスキングを適用しても、ストレージには生の値が残ったままになるためです。
ヘッド（開始時）ではなく、テール（終了時）でサンプリングを行います。実行が終了した後に何を保持するかを決定することで、エラー、エスカレーション、異常値は保持し、日常的な成功例を間引くことができます。
ストアを追記専用（append-only）にし、ロギングバックエンドにデフォルトで付属しているものではなく、そのストアが記述している最も機密性の高いシステムと同等のアクセス制御を設定します。
コンポーネント
メリット
- 非決定論的な失敗の診断を可能にします。再現するまで何度も実行を繰り返す代わりに、「なぜこの実行がこのような挙動を示したのか」に答えることができます。
- 記録保持の義務を、単なる約束事ではなく「成果物」へと変えます。過去のランダムな実行に対する再構築が機能するか、機能しないかのどちらかです。
- 作り出された失敗ではなく、実際の失敗を評価にフィードバックします。これは、ベンチマークと回帰テストスイートの違いに相当します。
- ドリフト（傾向の変化）とデプロイを分離します。レコードにモデルバージョンが含まれていれば、「悪化した」という問題に対して明確な答えを出すことができます。
リスク
- 最も脆弱な標的としてのトレースストア：記述対象のシステムと同じデータを保持しているにもかかわらず、通常はアクセス制御がより脆弱で、保存期間がより長く設定されています。
- トラフィックとともに増大するキャプチャコスト。コスト削減のために誰かがヘッド（開始時）でサンプリングを行うようになると、保持する価値のある実行が密かに、かつ確実に削除されてしまいます。
- 再構築に必要な情報まで削除してしまうマスキング。過剰なマスキングは、ある日誰かが実行をリプレイしようとして失敗するまで、表面化することはありません。
- ボリューム（データ量）をカバレッジと誤認すること。共有識別子のないテラバイト規模のスパンがあっても、特定の1つの実行に関する疑問には何一つ答えることができません。
非推奨のケース
- 入力と出力がすべてである、単一ステップの決定論的な呼び出し。これらはリクエストログだけで十分に再構築可能です。
- ユーザーもおらず義務もないプロトタイプであり、トレースパイプラインのコストが、そこから得られる知見を上回る場合。
- 適用される規則によってコンテンツの保持が一切禁止されている場合。その場合、トレースには決定が行われたこととそのメタデータのみを記録し、コンテンツ自体は除外します。これは別の成果物であり、そうでないふりをすることは、その規則が回避するために作られた法的責任（ライアビリティ）を生み出すことになります。
テクノロジー
事例
- エージェントが誤った顧客にメールを送信したインシデント。実行識別子によって、誤ったレコードを返したリトリーバル、それを使用したツール呼び出し、および送信されたメッセージがリンクされるため、1週間の再現テストを繰り返すことなく、1つのクエリが根本原因であることを特定できます。
- 規制当局から、6ヶ月前にどのように決定が下されたかについての問い合わせがあった場合。リプレイパスにより、その日に有効だったモデルバージョンを含め、トレースのみから実行を再構築します。
- モデルのアップグレード後に品質が低下した場合。すべてのスパンにモデルバージョンが含まれているため、主観的な印象ではなく、実際の実行における2つの母集団を比較することができます。
KPI
- 再構築成功率
- トレースのみからエンドツーエンドで再構築できる、ランダムに選択された過去の実行の割合。これはコントロール自体のテストであり、単にキャプチャ量を増やすだけでは改善できない、ここでの唯一の数値です。
- 相関関係の完全性
- 実行識別子を持つ、実行内のスパンの割合。100%未満であることは、一部のステップが不可視であることを意味し、欠落しているステップが退屈なものであることは滅多にありません。
- 機密フィールドの漏洩率
- マスキングルールによって削除されるべき値が含まれている、サンプリングされたレコードの割合。目標値はゼロです。それ以外の数値は、トレースストアに法的責任（ライアビリティ）が蓄積されていることを意味します。
- 異常な実行の保持率
- サンプリング後に保持される、エラーまたはエスカレーションが発生した実行の割合。ヘッドベースのサンプリングでは、この数値がサンプリング率に近づいてしまいます。この指標は、まさにその失敗を検知するために存在します。
観察された失敗パターン
- 何も証明できないトレース：すべてのステップがログに記録されているものの、どのステップも識別子を共有しておらず、1つの実行を再構築するためにタイムスタンプを手動で関連付ける必要があります。
- 参照によって記録されたプロンプト。テンプレートが変更されたため、ログにはモデルが実際には見ていないプロンプトが記述されるようになり、再構築結果が出力と矛盾するまで誰もそのことに気づきません。
- 平凡な実行を保持するヘッドベースのサンプリング。必要となる実行は、それが興味深いものになると判明する前に、エントリーポイントで破棄されてしまいます。
- 情報漏洩の原因となるログ：ツールの生の引数によって個人データがストアに持ち込まれ、そのデータが元々あったデータベースよりも広いアクセス権限と長い保存期間で保管されてしまいます。
- モデルバージョンの欠落。挙動の変化とサイレントなモデルアップデートがレコード上で同一に見えてしまい、トレースが答えるべきであった疑問のところで調査が頓挫します。
得られた教訓
- 相関関係こそが成果物であり、キャプチャは原材料にすぎません。トレースバックエンドを購入しながら識別子の付与を省くチームは、答えではなく、単なるストレージを手に入れることになります。
- パイプラインではなく、再構築をテストします。過去のランダムな実行を選択して再構築してみてください。ギャップは常に誰もインスツルメンテーションを行わなかった場所にあり、実際に試してみることでしか見つけることができません。
- 書き込み時にマスキングを行います。読み取り時までマスキングを延期することは、生の実データを保持することを決定したのと同じであり、ストレージは意図よりも長く存続します。
- テールでサンプリングを行います。ヘッドベースのサンプリングは、どの実行が興味深いものになるか判明する前に、それらを破棄することを決定してしまいます。
- すべての場所でモデルバージョンを記録します。必要なコストはフィールド1つ分であり、これによってドリフトを診断できるか、それとも不毛な議論に終始するかの違いが生まれます。
FAQ
- すでにトレースバックエンドを使用しています。これで解決しているのではないでしょうか？
- バックエンドが提供するのはキャプチャとストレージです。このパターンが扱うのは、バックエンドが決定してくれない3つの事項です。すなわち、1つの識別子が実行全体を貫いているか、ソースシステムなしで再構築できるほどの十分な忠実度（fidelity）があるか、そして記録した内容を安全に保持できるか、です。優れたツールを導入しているチームであっても、再構築テストに日常的に失敗しています。
- 完全なキャプチャはデータの最小化原則と矛盾しませんか？
- キャプチャが生のデータですべてを保持することを意味するのであれば、矛盾するでしょう。このコントロールは意図的に両面を規定しています。つまり、再構築には十分でありながら、ログが情報漏洩の原因にならないようにすることです。この両立を実現する方法は、キャプチャ時のフィールドレベルのマスキングと、記録を正当化する義務に紐づいた保存期間の設定です。やってはならないのは、すべてを保持した上でそれをコンプライアンスと呼び、この対立から目を背けることです。
- どの程度の忠実度（fidelity）があれば十分ですか？
- ランダムに選ばれた実行に対する再構築テストに合格するのに必要十分なレベルであり、それ以上は不要です。そのしきい値は実際に試してみることで発見できるため、このテストは監査時ではなく日常のルーティンに組み込むべきです。それを超えてキャプチャされたものはすべて、何の疑問にも答えないまま、コストと法的責任（ライアビリティ）を増大させるだけです。