CodexのWebSocketログ修正、AIエージェントのプライバシーを「保存される観測」まで広げた
OpenAIは2026年7月1日、Codex CLI 0.142.5を公開し、Responses WebSocketのリクエスト本文全体がtraceログへ書き込まれないようにしたと説明しました。関連するGitHub PRでは、既存のリクエストログフィルタリングでは覆えていなかったtrace文を削除したと明記されています。これは派手な新機能ではありません。しかし、CodexのようなAIエージェントでは、ユーザーが入力した依頼、コード片、ファイル内容、承認前の作業文脈が、モデルだけでなくログやデバッグ基盤にも流れます。今回の修正は、AIエージェントのプライバシー境界が「何を送るか」だけでなく、「何を観測し、どこに残すか」まで広がっていることを示しています。
修正対象は、Responses WebSocketの全文traceログだった
GitHubのCodex 0.142.5リリースノートは、bug fixとして「Responses WebSocket request payloads」の全文がtrace logsへ書き込まれるのを防いだと説明しています。対応するPR #30771は、release/0.142ブランチへのバックポートで、全文のResponses WebSocket request textを出力していたtrace-level logを削除した、とまとめています。
PRの説明では、この全文payloadは既存のrequest-log filteringでは覆えていなかったとされています。つまり、通常のリクエストログでは抑えられているつもりの内容が、別の観測経路で残る可能性があったということです。修正はリクエスト挙動やapp-server APIを変えない一方、traceへ全文を書かないようにするものです。
読者にとって重要なのは、これは「OpenAIが新しいデータ収集を始めた」という話ではない点です。むしろ逆で、デバッグや障害調査に必要な観測性と、ユーザー入力を全文のまま残さない最小化のあいだで、実装上の漏れを塞いだ更新と見るべきです。
エージェントのログは、通常のチャットログより重い文脈を持つ
Codexの入力は、単なる質問文にとどまりません。修正依頼、リポジトリ名、ファイルパス、差分、テスト結果、失敗ログ、外部サービス名、承認前の操作意図が一つの作業文脈として流れます。WebSocketは長い作業中の状態や応答を扱いやすい一方、そのpayloadには、ユーザーが「チャット欄へ入れたテキスト」以上の作業情報が含まれ得ます。
OpenAIのAPIデータ管理ドキュメントでは、API利用時にabuse monitoring logsやapplication stateとしてデータが保存され得ると説明し、abuse monitoring logsにはプロンプトやレスポンスなどのcustomer contentが含まれる場合があるとしています。Codexの今回の修正は、その公式な保持ポリシーとは別に、製品実装のtraceログというさらに低い層にも注意が必要だと示しています。
AIエージェントは、ユーザーの作業を進めるほど内部状態を多く持ちます。長時間の実行、再試行、サブタスク、ブラウザ操作、ローカルファイル参照が増えるほど、観測したくなる情報も増えます。だから、エージェントのプライバシーは、会話履歴を消せるかどうかだけでは足りません。ログの粒度、保存先、フィルタリング、traceを有効にしたときの扱いが同じくらい重要になります。
プライバシーUIは、権限だけでなく観測の既定値を説明する必要がある
AIエージェントのUIは、ファイルアクセス、ネットワーク、ブラウザ、承認モードのような「何をしてよいか」を見せる方向へ進んでいます。Codexでも、権限や承認はユーザーが理解しやすい表の顔です。しかし今回のようなtraceログの問題は、ユーザーが直接見る権限UIの外側にあります。許可した操作の内容が、どの程度デバッグ用の観測に残るのかは、別の設計面です。
この差は、開発者向けツールほど大きくなります。開発者は失敗の原因を知りたいので、詳しいログを求めます。一方で、そのログには秘密鍵そのものではなくても、社内API名、未公開機能名、顧客名、ファイル構造、バグの再現手順のような機密に近い情報が入ります。全文payloadを安易にtraceへ出す実装は、便利な障害調査と引き換えに、後から検索可能な作業記録を増やしてしまいます。
| 層 | ユーザーが意識しやすいもの | 今回の更新が示す注意点 |
|---|---|---|
| 入力 | Codexへ送る依頼、コード、ファイル名 | payloadには作業文脈がまとまって含まれ得る |
| 実行 | WebSocket経由の応答、承認、進行状態 | 長い作業ほど観測したい状態が増える |
| 観測 | 通常ログ、traceログ、テスト時の出力 | 通常フィルタ外の経路に全文が残らない設計が必要 |
| 説明 | 権限設定、データ管理、保持ポリシー | 何を許可するかだけでなく何が残るかを示す必要がある |
Codex 0.142.5の修正は小さいですが、方向性ははっきりしています。エージェントの信頼は、モデルが賢いか、承認ダイアログがあるかだけで決まりません。観測性の既定値がどれだけ控えめで、例外的に詳しいログを取るときに何が残るのかを、製品と運用の両方で説明できるか。AIエージェントが実務の作業面へ入るほど、その説明責任は重くなります。
今回の更新は、読者がすぐに新機能として触る類の話ではありません。それでもInterface Wireで扱う価値があるのは、AIエージェントの境界がUIの見える場所だけにないからです。ユーザーはエージェントに作業を任せ、ツールはそれを観測し、運用側は問題を追うためにログを持ちます。そのどこか一つで全文が残れば、プライバシー設計は弱くなります。Codexの小さなログ修正は、エージェント時代の「安全な既定値」が、権限設定だけでなく観測設定にも必要だと教えています。