ハクソク

世界を動かす技術を、日本語で。

Codexがサブエージェントのプロンプトを暗号化し始める

2026年7月14日原文(github.com)

概要

  • Codex CLI の MultiAgentV2 で暗号化メッセージ実装後の監査性・デバッグ性の問題点
  • #26210 （2026-06-05 マージ）適用以降、タスク/メッセージ内容が暗号化され人間が読めなくなる
  • 期待動作 ：暗号化配信と同時に監査用平文コピーもローカル保存
  • 課題 ：rollout/history/trace などで平文内容が見えず、後からの監査・調査が困難
  • 解決策案 ：暗号化メッセージ＋監査用平文フィールドの両方を保持・保存

Codex CLI MultiAgentV2 暗号化メッセージの監査性問題

  • #26210 （Encrypt multi-agent v2 message payloads）適用以降、MultiAgentV2 の spawn_agent, send_message, followup_task でタスク・メッセージ内容が暗号化
  • InterAgentCommunication 構造体の content フィールドが空文字、encrypted_content のみ保存
  • rollout/history/trace では人間が読めるタスク・メッセージ内容が消失
  • 監査・デバッグ時 に「どんなタスクを子エージェントに委譲したか」「なぜ子スレッドが生まれたか」などが不明瞭化
  • #26753 とは別件（こちらは暗号化ツールスキーマのリクエストバリデーション失敗報告）

現状の実装挙動

  • spawn_agent, send_message, followup_task すべてで暗号化メッセージのみを保存し、平文は保持しない
  • to_model_input_item() も encrypted_content のみをモデルに渡し、content は空
  • record_inter_agent_communication() や構造化ログでも content が空なら encrypted_content を記録
  • 監査・デバッグ用の平文情報 が一切ローカルに残らない

期待される動作

  • 暗号化メッセージ配信 は維持しつつ、 監査用平文コピー を rollout/history/trace 等に保存
  • spawn_agent では task_message フィールド、 send_message/followup_task でも同様の audit フィールドを導入
  • 平文フィールドは必須、空の場合はハンドラで reject
  • InterAgentCommunication には encrypted_content と content の両方をセット
  • to_model_input_item() ではモデルには暗号化ペイロードのみ渡す
  • ローカル履歴/監査/デバッグ用には平文フィールドを参照
  • 平文フィールド には暗号化メッセージと同じサイズ制限を適用し、無制限な成長を防止

実装例・進捗

  • spawn_agent については ignatremizov@df9a7c4 で task_message 必須化・平文監査フィールド導入済み
  • send_message/followup_task についても同様に平文フィールドを追加し、全ての履歴・監査面で平文内容を参照する必要
  • trace reduction でも、マッチングには暗号化値やIDを使い、監査表示には平文を利用
  • resume/replay 時も監査用平文コピーを保持し、再暗号化などは不要

受け入れ基準

  • 親側の rollout/history/trace で spawn_agent, send_message, followup_task すべてのタスク・メッセージ内容が平文で見える
  • 子モデルへの配信は暗号化ペイロードのみ （監査用平文は渡さない）
  • 構造化トレース/履歴/通信ログ で平文監査フィールドを参照し、暗号文は監査用テキストとして使わない
  • 再実行・リプレイ でも監査用平文コピーが保持される

MultiAgentV2 監査性向上のための実装仕様案

  • 既存の encrypted_content をモデル配信用ペイロードとして維持
  • 各ツール（spawn_agent, send_message, followup_task） に監査用平文フィールド（例: task_message, message_text）を必須追加
  • ハンドラで空の平文フィールドを拒否
  • InterAgentCommunication 生成時に encrypted_content と content の両方をセット
  • to_model_input_item() はモデルには暗号化ペイロードのみ渡す
  • ローカルの rollout/history/trace には平文フィールドを保存
  • 平文フィールドにはサイズ上限を設ける
  • 監査用平文は暗号化配信のアイデンティティとは別扱い （紐付けはIDや暗号文で行う）

まとめ

  • 暗号化配信 と ローカル監査性 の両立が重要
  • spawn_agent では既に平文監査フィールドの導入実装例あり
  • send_message/followup_task でも同様の対応が必要
  • 全ての履歴・監査面 で平文内容が見えることが必須条件
  • 今後の課題 は全通信経路・履歴での一貫した監査用平文保持とUI/ツール側の対応

Hackerたちの意見

代替のハーネスでGPTサブスクリプションを使うのを止めるつもりなのかな？もしそうじゃなかったら、あんまり関係ないけど、Codex CLIは特に特徴がないハーネスだよね。

└

代替のハーネスでGPTサブスクリプションを使うのを止めるつもりなのかな？ 多分無理だと思うよ。アプリサーバーの仕組みがそれをサポートするためにあるから、Codexからそれを取り除くのは大変だし。これが私がCodexを一番使う理由だね。統合が一番簡単で、アプリサーバーのRPC APIが本当に楽だから。今のところ、私のCodexの使い方はほとんど、Codexのアプリサーバーを使って作ったカスタム統合を通してなんだ。彼らが公開してるCodex TUIじゃなくてね。私だけじゃないと思うけど。でも、もし突然ディスク上のコンテンツを暗号化して、彼らのバックエンドだけが見れるようにしたら、統合が簡単でも関係ないよね。何が起こってるのか全然分からなくなるし、チームがこれを良いアイデアだと思ったのが理解できない…

└

Anthropicがビジネスの採用でリードしてる限り、そんなことはしないと思うよ。もし彼らがトップになってリードを取ったら、全ての賭けは無効になるね。オープンモデルがGPT-5.6よりも良くなる頃には、期待したいな。

└

AnthropicとGoogleは、自分のハーネスを使うのに追加料金を取ってるから、それがOpenAIを使ってる100%の理由だよ。もしその道に進んだら、昔の友達Claudeに戻るか、もしくはもう一台Sparkを買ってローカルで使うかな。

└

「特に特徴がないハーネス」っていうのが、私がそれを好きな理由なんだよね。

└

Codex自体がサブスクリプションをラップするプロキシを出荷していることを考えると、あまり可能性は高くないね。 https://github.com/openai/codex/blob/main/codex-rs/responses...

└

Codex CLIに巻き戻し機能がないと、私には全然役に立たないな。

└

最近、Tibo @ OpenAIが誰かにClaude CodeでGPTを動かす方法をシェアしてくれってツイートしてたから、彼らはそれに反対してるわけじゃないみたい。

ああ、昨日中国の闇市場の転売屋が働かなくなった理由が分かった。これが原因か。

└

これが私が思う理由だよ。この闇市場はサブスクリプションをプールして再販するだけでなく、データを保存して誰にでも売ってる。暗号化は少なくとも後者を止めるのに役立つ。結局、以前に暴露されたaのトリックと同じ目的だけど、実装がずっと良い感じ。

└

面白いね。これに関するリンクある？

これは主に、大量のユーザーリクエストとレスポンスをプロキシして、競合モデルのトレーニングに使うのを妨げるためだと思うよ。

Hacker Newsで議論の続きを見る