AIエージェントは、最終回答だけ見ても不具合の原因が分かりません。そこで役立つのが、モデル呼び出しやツール実行を追跡する「トレース」です。
ただし、観測できる情報が増えるほど、顧客情報や社内データまで記録する危険も増えます。トレースはデバッグ機能であると同時に、もう一つのデータ保管経路です。
OpenAI Agents SDKは何を記録するのか
OpenAI Agents SDKの公式ドキュメントによると、トレースは既定で有効です。主な対象は次の通りです。
- LLMへの入力と出力
- 関数ツールの入力と出力
- エージェント間の引き継ぎ
- ガードレールの実行
- 音声の入出力
ここで重要なのは、生成処理と関数ツールのスパンが、機密情報を含み得る入出力を保存することです。しかも trace_include_sensitive_data の既定値は True と明記されています。音声トレースも、入力・出力のPCMデータを既定で含みます。
「全部残す」と「何も残さない」の間を設計する
運用では、トレースを一律にオン・オフするより、目的別に記録範囲を決める方が現実的です。
- 開発環境：再現に必要な情報を残す。ただし実データではなくテストデータを使う
- 本番の通常処理：入力・出力本文を外し、処理時間、成功・失敗、ツール名などを中心に残す
- 障害調査：対象と期間を限定して詳細記録を有効にし、調査後に戻す
設計の要点は「デバッグに便利か」ではなく、「この項目がなくても原因を特定できるか」と逆向きに考えることです。顧客名やメール本文そのものではなく、匿名化したケースID、エラー種別、処理段階で足りる場合は多いでしょう。
APIのデータ設定とトレースを混同しない
OpenAIのData controls公式文書では、APIデータは明示的にオプトインしない限りモデル改善に使われず、標準の不正利用監視ログは原則として最大30日保持されると説明されています。一方、Agents SDKの公式文書は、Zero Data Retention（ZDR）を利用する組織ではトレースを使えないとしています。
つまり「API側で保存を抑えたから、トレースも同じ扱い」とは限りません。モデルAPI、エージェントのトレース、自社ログ、外部監視基盤を別々のデータ経路として棚卸しする必要があります。
考察：ログは“観測装置”ではなく“複製装置”でもある
エージェントは複数のツールをまたぐため、1件の依頼が何度もログへ複製されます。観測性を上げるほど、情報のコピー先も増える構造です。
だから本番導入の完了条件には、精度や応答速度だけでなく、次の3点を入れるべきです。
- 記録する項目と記録しない項目
- 閲覧できる役割と監査方法
- 保存期間と削除手順
AIエージェントのトレースは、後から足す便利機能ではありません。最初からデータ設計の一部として扱うことで、「原因は追えるが、秘密は残しすぎない」運用に近づきます。
まとめ
- Agents SDKのトレースは標準で有効です
- モデルと関数ツールの入出力は、既定で機密情報を含み得ます
- 本番では本文を減らし、識別子・結果・時間など必要最小限を残します
- API、トレース、自社ログ、外部基盤は別々に管理します
「たくさん記録するほど安心」ではありません。良いトレースは、情報量ではなく、必要な原因へ最短でたどり着ける設計です。