OpenAI Codex、エージェント間指示を暗号化――開発者の監査アクセス権が喪失、EU AI法への影響も懸念

OpenAIのCodexにおいて、最上位モデルである「GPT-5.6-Sol」および「GPT-5.6-Terra」を利用する開発者は、親エージェントがサブエージェントに下した指示内容を閲覧できなくなった。この変更は、2026年7月14日にリリースされた「Codex CLI 0.144.4」によって強制適用されたと報じられている。マルチエージェント構成のワークフローで不具合が生じた際、開発者が原因を特定することが極めて困難になるとして、コミュニティからは懸念と不満の声が上がっている。

■Codex CLI 0.144.4で何が変わったのか

今回の変更の中心にあるのは、Codexの「MultiAgentV2」プロトコルだ。これは、ユーザーが定義した設定ではなく、ランタイム側が動的にサブエージェントへの業務割り当てを決定する新しいオーケストレーション層である。MultiAgentV2は、「spawn_agent（サブエージェントの起動と初期タスク割り当て）」「send_message（稼働中のサブエージェントへの指示送信）」「followup_task（待機中のサブエージェントへの追加タスク割り当て）」という3つの特定の委譲メッセージを制御している。

従来の設計では、親モデルがこれらのツールを呼び出すと、指示テキストは読み取り可能な引数としてそのまま渡され、ローカルのセッション履歴にプレーンテキスト（平文）で保存されていた。しかし新しい設計では、OpenAIの「Responses API」が、ローカルで実行されているCodex CLIに届く前にメッセージ引数を暗号化する。Codexは暗号化されたシークレットテキスト（暗号文）のみを転送し、受信側のサブエージェントモデルに到達した瞬間に、Responses APIが内部でこれを復号する仕組みだ。

GitHubのIssue #28058に報告されている通り、ローカルの保存フォーマットも変更された。エージェント間通信を表す「InterAgentCommunication」オブジェクト内では、平文を格納していた「content」フィールドが空の文字列になり、暗号文が「encrypted_content」に格納されるようになった。この仕様は、履歴、ロールアウト、トレース削減、そしてOpenTelemetryを介して出力されるテレメトリエクスポートにまで一貫して適用されている。つまり、開発者がローカルで平文を復元する裏道は存在しない。

極めて重要な点は、これが「エンドツーエンドの暗号化」ではないということだ。復号を行うのはOpenAIのサーバーであり、閲覧権限を奪われたのは開発者であって、OpenAIではない。

なお、より小規模なモデルである「GPT-5.6-Luna」は、引き続き従来の「MultiAgentV1」パスを使用しており、委譲テキストは平文のまま閲覧可能だ。また、一時期は無効化していても強制的に暗号化が適用されていた「GPT-5.5」については、現在は読み取り可能なパスに戻されているとみられる。

■MultiAgentV2における暗号化の仕組み

親エージェントからサブエージェントへのデータフローを追うと、監査におけるギャップが浮き彫りになる。親モデルがサブエージェントの起動や追加指示の送信を決定すると、3つの委譲ツールのいずれかを呼び出す。MultiAgentV2では、Responses APIがOpenAIのインフラ上でこのメッセージ引数を傍受し、暗号化されたバージョンをローカルのCodexプロセスに返す。

Codexは暗号文を受け取り、それを「InterAgentCommunication.encrypted_content」に配置し、「InterAgentCommunication.content」は空のままにする。その後、受信側のサブエージェントへのリクエスト内で、その暗号文を「agent_message」として転送する。この時点でもまだ暗号文のままだ。Responses APIが受信側モデルにメッセージを配信するときに初めて復号が行われるが、このステップは開発者のマシンではなく、OpenAIのサーバー上で実行される。技術分析メディアのXenoSpectrumによるテクニカル分析も、この挙動を確認している。

ローカルの記録で引き続き読み取れるのは、Codex自体が生成するサブエージェントからの完了通知やステータス更新、ユーザーの元のプロンプト、そしてすべてのMultiAgentV1の通信ログのみだ。一方で、親エージェントがサブエージェントに指示した内容は、MultiAgentV2の3つの委譲メッセージタイプすべてにおいて完全にブラックボックス化する。

さらに、モデルの選択によってこの挙動が自動的に決まるため、開発者に混乱をもたらしている。開発者がLuna（V1を使用）からSolやTerra（V2が必須）に切り替える際、暗号化の設定を明示的に行うわけではない。単にモデルを選択するだけで、監査可能性の挙動が勝手に変更されてしまうのだ。

■障害発生時に開発者が見失うもの

Codexは単に質問に答えるだけの存在ではない。コードを読み、シェルコマンドを実行し、ファイルを書き換える自律性を持つ。マルチエージェントのパイプラインが誤った出力を生成したり、削除すべきでないデータを削除したり、途中でクラッシュしたりした場合、最初の診断ステップは通常「サブエージェントに実際にどのような指示が下されたか」を確認することだ。

委譲テキストが読めなくなると、障害の切り分けは極めて困難になる。親エージェントがタスクの組み立てを誤ったのか、それともサブエージェントが正しい指示を誤解したのか、あるいは予期しない環境で実行されたのか。これらはそれぞれ対策が異なるが、指示内容自体が暗号化されていると、外からはすべて同じエラーに見えてしまう。

また、不具合の再現も難しくなる。ローカルの履歴から元の委譲テキストを復元できないため、失敗したシナリオを正確に再実行するには、サブエージェントの挙動から逆算して推論するしかなく、原因となった指示をそのまま再投入することができない。

決済サービス「Zolvat」のCTOを務めるIgnat Remizov氏は、6月13日にGitHub Issue #28058を立ち上げ、この問題を報告するとともに解決策を提案した。彼の提案は、OpenAIに対して配信チャネルの暗号化を撤回するよう求めるものではない。そうではなく、「関心の分離」を提案している。受信モデルに配信されるメッセージは暗号化したままとし、それとは別に、事後検証用の平文の監査コピーをローカルの履歴やトレースに書き出すというアプローチだ。これにより、サブエージェントは暗号化チャネルを通じて指示を受け取りつつ、開発者は実行完了後に委譲内容を確認できるようになる。

しかし、このIssueは2026年7月16日時点で、解決策がマージされないままオープンの状態が続いている。

■OpenAIの沈黙と過去のコミットメントとの矛盾

この暗号化を導入したプルリクエスト「PR #26210」には「Why（理由）」というセクションが設けられていたものの、具体的な根拠は一切説明されていなかった。6月6日には、OpenAIのコントリビューターが別の関連バグ報告に対し、「MultiAgentV2はまだ開発中であり、現時点ではバグ報告を受け付けていない」と回答するにとどまっていた。

しかし、7月14日にリリースされたCodex CLI 0.144.4において、配布されたモデルカタログ内でSolとTerraがMultiAgentV2のユーザーとして指定されたことで、その言い訳は通用しなくなった。この指定は開発者が手動で有効にするフラグではなく、リリース自体に組み込まれたものだ。SolやTerraを選択した開発者は、実験的機能を有効にしたわけではなく、単にモデルを選んだだけで暗号化パスに強制的に入れられることになる。

OpenAIは、この暗号化の根拠や、同社自身が保持している平文データの範囲、さらにはエンタープライズ向けのコンプライアンスプラットフォームがローカルログにはない読み取り可能な委譲指示のコピーを保存しているかどうかについて、公に説明していない。

この沈黙は、同社が過去に行った2つの公約と矛盾する。2026年5月、OpenAIはCodexの運用ポリシーを公開し、従来のセキュリティログは「何が起きたか」は記録できるものの「エージェントの意図」を説明するには不十分であると認め、ユーザープロンプト、承認決定、ツール実行結果をカバーするエージェント向けテレメトリでそのギャップを埋めると確約していた。MultiAgentV2の委譲テキストこそ、まさにその確約がカバーすべき対象だったはずだが、現在はローカル履歴やテレメトリトレース内で暗号文と化している。また、2026年のGartner Magic Quadrant（エンタープライズAIコーディングエージェント部門）において、Codexは「リーダー」に選出され、評価基準として企業のガバナンスと監査可能性が挙げられていた。この評価は、今回の強制暗号化が導入される前のものだ。

■なぜCodexはこれを暗号化するのか？ 2つの有力な仮説

OpenAIが沈黙を守る中、開発者コミュニティではいくつかの仮説が議論されている。その中で特に有力視されているのが以下の2つの説だ。

1つ目は「プライバシーの強化」である。OpenAIのAPIはすでに、中間的な推論状態（思考プロセスのアウトプット）を暗号化し、APIコール間で転送する際に機密内容が漏洩したり共有ログに残ったりするのを防いでいる。同じ論理が委譲メッセージにも適用されているという考え方だ。委譲メッセージには、未公開のコード、システム障害の詳細、調査中のファイル名などが含まれる可能性がある。デバッグやセキュリティレビューのためにセッションログを共有する場合でも、委譲指示が暗号化されていれば情報漏洩のリスクを低減できる。

2つ目の説は「独自の推論パターンの競争保護」だ。SolやTerraのような最先端モデルが複雑なタスクを並列の委譲指示に分解する際、その指示内容には、モデルがどのように問題を分解し組み立てているかという「独自のノウハウ（シグナル）」が現れる。競合他社が自社モデルをトレーニングする際に、この情報を模倣（蒸留）されるのを防ぐための措置ではないかという見方だ。

モデルの「蒸留（ディスティレーション）」（大規模モデルの出力を使って、より小さなモデルを訓練する手法）は、2026年のAI業界における最大の論争テーマとなっている。OpenAIはDeepSeekが同社のモデルを蒸留したと非難し、Anthropicなどは利用規約に抗蒸留条項を追加した。6月中旬にリリースされたZhipu AIの「GLM-5.2」も、挙動のフィンガープリント分析から、GPT-5.5などの最先端モデルの出力を用いて訓練されたのではないかと疑われている。さらに7月13日には、MicrosoftのCEOであるサティア・ナデラ氏が、AI研究所が自らは公開データで学習し顧客データへの権利を留保しながら、他社による蒸留を禁止していることを「逆情報パラドックス」と批判し、学習インフラを支配する者に経済的価値が集中していると指摘したばかりだ。

もしエージェント間の委譲プロンプトに、最先端モデルが複雑なコーディングタスクを分解するプロセスが露呈しているとすれば、読み取り可能なセッションログは競合にトレーニングシグナルを無償で提供しているようなものだ。コミュニティフォーラムでは、セッションアクセスを利用してCodexの出力を集約していた未認可のAPIプーリングサービスが、この暗号化の導入とほぼ同時期に機能しなくなったと報告されており、アクセス制御目的であるという説の信憑性を高めている。

現時点ではどちらの説も公式に確認されたわけではないが、いずれも十分に説得力のある内容だ。

■EU AI法の期限まであと17日、Codexのログ欠如がもたらすリスク

この監査ギャップがもたらす最も差し迫った影響は、デバッグの不便さではなく、法規制の遵守（コンプライアンス）である。EU AI法における「高リスクAIシステム」に対する本格的な義務化の期限は、17日後の2026年8月2日に迫っている。同法の第12条は、高リスクAIシステムに対し、事後的にシステムが何を行い、なぜそれを行ったのかを再構成できる詳細なログの保持を義務付けている。

Codexのマルチエージェントパイプラインが同法の下で「高リスク」に分類されるかどうかは、その導入コンテキストに依存する。重要インフラ、金融、採用決定など、指定されたカテゴリーで利用されるコードをAIエージェントが生成する場合、この分類に該当する可能性がある。自社のCodexワークフローが該当すると判断した開発者、あるいは念のために準拠を進めている開発者にとって、今回の暗号化は致命的なギャップとなる。高リスクAIシステムが各ステップで何を指示されたかを証明するために必要な委譲テキストが、ローカル記録上ではすべて暗号文になってしまっているからだ。

強制暗号化が適用される前に公開された、EU AI法準拠に関するAIコーディングツールの評価レポートでは、テストされたツールの中でCodexのOpenTelemetryエクスポート機能が最も第12条の要件に近いと評価されていた。当時の評価では、Codexのテレメトリはユーザープロンプト、ツールの承認、ツールの実行結果、Model Context Protocol（MCP）サーバーの利用、ネットワークプロキシの決定までカバーしているとされていた。しかし、この評価はSolとTerraが強制的にMultiAgentV2パスに移行される前に行われたものであり、現在そのテレメトリトレースの委譲指示の部分は暗号文に置き換わっている。

OpenAIのエンタープライズ向けコンプライアンスプラットフォームが、ローカルログには残らない平文の委譲指示コピーを保持しているかどうかについては、公開ドキュメントには一切記載がない。

■開発者が求めている解決策

GitHub Issue #28058で提案されている修正案は、技術的にはシンプルだ。「配信チャネル」と「監査チャネル」を分離することである。受信モデルに配信されるメッセージ引数は暗号化したままとし、それとは別に、親エージェント側のローカルロールアウト、履歴、トレースメタデータに平文の監査用フィールドを追加する。これにより、サブエージェントは暗号化されたチャネル経由で指示を受け取り続け、開発者は事後に何が委譲されたかを読み取ることができる。

しかし、この設計を実装するには、OpenAIが公に議論していないトレードオフが伴う。ローカルに平文の監査コピーを保存すれば、暗号化による情報漏洩防止効果の一部が失われることになる。監査コピーをいつ有効にするか、どのくらいの期間保持するか、また機密性の高いコンテンツ（独自のコード、障害の詳細、ファイル内容など）をどのように処理するかといった、コードの変更にとどまらないポリシー上の決定が必要となる。

また、この機能がすべてのCodexユーザーに提供されるのか、それとも上位のエンタープライズプラン限定となるのかも重要な論点だ。もし監査アクセスに有料アップグレードが必要となれば、暗号化によってサブスクリプションの階層ごとに可観測性（オブザーバビリティ）に格差が生じることになり、低価格帯のプランでは監査が困難になる一方で、大企業顧客だけが監査アクセスを維持できるという状況が生まれることになる。

SolやTerraを使用してコンプライアンスが重視されるワークフローを構築している開発者にとって、現在の状況は未解決のままだ。Codexは自律的にコードを読み、コマンドを実行し、ファイルを書き換える。読み取り可能な委譲テキストがなければ、「このエージェントが何を決定し、なぜそれを行ったのか」という問いに対する答えをローカルで得ることはできない。平文の鍵を握っているのはOpenAIだけであり、開発者は今のところ、暗闇の中に置かれている。

■注目ポイントQ&A

●SolやTerraを使用している場合でも、Codexのサブエージェントの挙動を監査することはできますか？

部分的にしかできません。委譲が発生したという事実（InterAgentCommunicationオブジェクトへの記録）は確認できますが、委譲された指示の内容は「encrypted_content」に暗号文として保存され、「content」フィールドは空になります。サブエージェントが生成した成果物や実行したコマンドは検査できますが、親エージェントがどのような指示を与えたかをローカルで読み取ることはできません。

●CodexのMultiAgentV1とMultiAgentV2の違いは何ですか？

MultiAgentV1は従来のオーケストレーションパスであり、ユーザーや設定ファイルがエージェント間の業務割り当てを定義し、委譲テキストはローカル履歴に平文で保存されます。一方、MultiAgentV2はランタイムが動的に割り当てを決定する新しいレイヤーであり、委譲メッセージが暗号化されます。Codex CLI 0.144.4以降、GPT-5.6-SolとGPT-5.6-TerraはデフォルトでMultiAgentV2を使用し、GPT-5.6-Lunaは引き続きMultiAgentV1を使用します。

●EU AI法は、Codexに対してエージェントの委譲指示のログ記録を義務付けていますか？

同法の第12条は、「高リスクAIシステム」に対して、システムの挙動や意思決定プロセスを事後的に再構成できる詳細なログの保持を義務付けています。Codexを用いたワークフローが高リスクに該当するかどうかは、重要インフラや金融などでの利用といった導入コンテキストに依存します。該当する場合、MultiAgentV2における委譲メッセージの暗号化は、第12条が求めるトレーサビリティの要件を満たせなくなるリスク（ログの欠如）を生じさせます。なお、高リスクシステムに対する同法の義務化は2026年8月2日に開始されます。

●なぜOpenAIはエージェント間の指示を暗号化したのですか？

OpenAIは公式な理由を明らかにしていません。開発者やアナリストの間では、機密コードやシステム障害情報の漏洩を防ぐ「プライバシーの強化」という説と、最先端モデルが複雑なタスクを分解するプロセスの模倣（蒸留）を防ぐ「競争保護」という説の2つが有力視されています。特に後者は、競合他社によるモデルの無断蒸留が業界の大きな問題となっている時期と重なっています。

元記事: OpenAI Codex Encrypts Agent Instructions, Stripping Developers of Audit Access