OpenAIはCodexのMultiAgentV2で、親エージェントから子エージェントへ渡す指示を暗号化した。2026年6月5日に公式リポジトリへ統合され、6月8日公開のCodex CLI 0.138.0に収録された変更である。対象はユーザーが最初に入力したプロンプトやCodexの全内部指示ではなく、親が子を起動し、追加の作業を頼むときのメッセージだ。子は指示を受け取れるが、利用者の端末に残る履歴からは、その指示の平文が見えなくなる。
争点は、暗号化の採否から監査できる範囲へ広がる。Codexはコードを読み、コマンドを実行し、ファイルを書き換える。問題が起きたとき、子エージェントが何を命じられたかを確認できなければ、原因が親の委任、子の解釈、実行環境のどこにあったのかを切り分けにくい。OpenAIが安全運用の柱としてきた「なぜその動作が起きたか」を説明する監査と、新しい配信経路が衝突している。
暗号化されるのは三つの委任メッセージ
変更されたのは、MultiAgentV2のspawn_agent、send_message、followup_taskにあるmessage引数だ。spawn_agentは子エージェントを起動して最初の仕事を渡す。残る二つは、稼働中または待機中の子へメッセージや追加作業を送るために使う。
親モデルがツールを呼ぶ際、OpenAIのResponsesがmessageを暗号化する。ローカルで動くCodexが受け取るのは暗号文であり、子へのリクエストにも同じ暗号文をagent_messageとして載せる。Responsesは受信側のモデルへ渡す段階で内部復号する。つまり、親モデルが生成した指示はローカルのCodexを通過する間は暗号文となり、受信側モデルの前で復号される。
保存形式も同じ考え方で変わった。エージェント間通信を表すInterAgentCommunicationでは、平文用のcontentを空文字列にし、encrypted_contentへ暗号文を入れる。公式の変更説明によると、この形式は履歴とrolloutに保存され、圧縮処理をまたいでも維持される。テレメトリーとapp-serverのスキーマも暗号文を扱う。親側のコンテキストにも、ツール引数から取り出せる平文は残らない。
一方、子が返した完了通知や状態通知はCodexが生成するため、引き続き平文である。MultiAgentV1の通信経路も変更されていない。暗号化されたのはMultiAgentV2の委任内容であり、エージェント間のやり取りがすべて不可視になったわけではない。
平文の削減と、失われる原因追跡
この設計には、ローカルに保存される平文を減らす効果がある。委任内容には、未公開コードの説明や障害の詳細、調査対象のファイル名が入ることがある。rolloutをバックアップしたり、デバッグ用に共有したりしても、暗号文から指示内容を直接読まれにくい。
ただし、OpenAIは暗号化の目的を公表していない。PRの「Why」欄は、以前は平文が通常のツール引数やエージェント間コンテキストを通っていたことと、新しい暗号文の流れを説明するが、守ろうとする相手や想定する攻撃を示していない。暗号方式、鍵を管理する主体、保持期間も公開されていない。Responsesが内部で復号する以上、OpenAIからも読めないエンドツーエンド暗号化とは呼べない。
代わりに失われるのが、利用者側での原因追跡である。子の出力と実行結果が残っても、入力となった委任文がなければ、「親が範囲を広げすぎたのか」「子が条件を落としたのか」を後から確かめられない。再現試験でも、同じ指示を与え直すことができない。複数の子が並行して同じリポジトリを扱うほど、この欠落は重くなる。
OpenAIは5月8日に公開した自社のCodex運用方針で、従来のセキュリティログは「何が起きたか」を示しても、利用者やエージェントの意図までは説明しにくいと述べた。同社はユーザープロンプト、承認判断、ツール実行結果などを含む「エージェント向けテレメトリー」によって、その空白を埋めるとしている。ところがMultiAgentV2では、子が動いた直接の理由に当たる委任文がローカルの履歴とトレースで暗号文になる。企業向けCompliance Platformがこの平文を保持するかどうかも、公開資料からは分からない。
0.138.0で製品経路へ、SolとTerraはV2
暗号化変更は2026年6月5日にマージされ、6月8日に公開されたCodex CLI 0.138.0の変更一覧へ入った。ひとつ前の0.137.0は6月4日公開なので、暗号化が最初に安定版へ入ったのは0.138.0である。6月6日、OpenAIの担当者は関連する不具合報告に対し、MultiAgentV2は開発中で利用を勧めず、当時はバグ報告を受け付けないと回答していた。
しかし、7月14日公開の0.144.4に同梱された公式モデルカタログを見ると、GPT-5.6-SolとGPT-5.6-Terraにはmulti_agent_version: v2が指定されている。GPT-5.6-LunaはV1だ。モデルを選んだ結果としてV2へ入る構成が配布版に含まれており、利用者が実験用フラグを手動で有効にした場合に限られる問題ではない。
この違いは、同じCodexでも監査できる内容がモデル経路によって変わり得ることを意味する。V1では委任文が平文で残る一方、V2では暗号文になる。エージェントの性能や速度を比べるとき、利用者はモデルの出力品質に加え、失敗時に入力まで遡れるかを確認する必要がある。
監査コピーを分離する案と、未リリースの追加変更
監査可能性を巡るIssue #28058は6月13日に開かれ、7月15日時点でも未解決である。提案は暗号化を撤回するものではない。受信側モデルへ渡すmessageは暗号文のまま保ち、親側の履歴とトレースには別の平文フィールドを監査用として保存する。配信用と検証用を分ける設計だ。
この案なら、子モデルには従来通り暗号文の経路で届けながら、利用者は何を委任したかを後から読める。ただし、平文をローカルへ残せば、暗号化で減らした情報漏洩の面は後退する。実装するなら、監査コピーを有効にする条件と保存期間を定め、機密情報をどこまで伏せるかも決めなければならない。
さらにOpenAIは7月14日、list_agentsの出力から最新のタスク内容を削除し、エージェント名と状態だけを返すPR #33030をmainブランチへ統合した。理由は説明されていない。この変更は0.144.4の公開から約5時間後にマージされたため、同版には含まれない。それでも今後の配布版へ入れば、稼働中のエージェント一覧から委任内容を確認する経路もなくなる。
暗号化の是非を決めるには、OpenAIが想定する脅威と復号できる主体を明らかにする必要がある。そのうえで、ローカル監査コピーを選べるのか、再開や履歴圧縮をまたいで検証可能な記録が残るのかを仕様に落とすべきだ。次の判断材料は、Issue #28058への公式回答と、平文の監査コピーを実装する変更がリリースへ入るかどうかである。
