はじめに
個人開発でCodexを実装担当、Claude Codeを検証担当として使っています。以前は成果物とレビュー結果を人間がコピペで受け渡していました。
今回、Codexに**「Claudeにレビューを頼んで」と指示したところ、CodexがClaude Codeを直接起動し、依頼・回答保存・回答の評価まで実行しました。この記事はCodexの保存ログを調査した裏取り結果**を反映した技術実験レポートです。対象アプリの固有情報は一般化しています。
実証範囲：今回確認できたのは「Codex → Claude Code」の一方向の直接起動です。双方向の完全自動運用やOSレベルの完全隔離は実証していません。
全体像
- 人間がCodexにレビューを指示
- Codexが対象ソースのコピーと依頼文を準備
- CodexがPythonからClaude Codeを非対話で起動
- Claude CodeのJSON回答をファイルに保存
- Codexが回答を採用・保留・却下に分けて評価し報告
人間による途中のコピペなしで「依頼 → レビュー → 評価」が一周しました。ただし最初の指示は人間が出しており、Codex側に外部コマンド実行権限が必要です。
前提条件
実行時のClaude Codeは2.1.301でした。同じPCでCodexが外部プロセスを実行でき、Claude Code CLIが利用可能な認証状態にあり、レビュー対象ソースがローカルにあることが前提です。認証方式や実際の請求先はログから断定できません。再現する際はバージョン差に注意し、公式CLIリファレンスを確認してください。
実際の手順
1. レビュー専用フォルダーを用意する
本体リポジトリを直接対象にせず、選別した123ファイルのコピーを渡しました。
review-run/
├── REQUEST.txt # 依頼文
├── MEASUREMENTS.json # 判断材料の計測値
├── SOURCE_HASHES.json # 依頼前のSHA-256
├── source/ # レビュー対象コピー
├── CLAUDE_RESPONSE.json # CLIのJSON出力
├── CLAUDE_REVIEW.txt # 抽出した回答本文
├── CLAUDE_STDERR.txt # 標準エラー
├── CODEX_ASSESSMENT.txt # Codexによる評価
└── run.json # 実行記録
依頼・回答・評価を後から追える構成です。ただし、コピーの分離だけでOSレベルの隔離が成立するわけではありません。
2. 依頼文に前提と禁止事項を書く
Claude CodeにCodexの元の会話がすべて自動転送されたわけではありません。経緯、計測条件、過去に見送った案を依頼文に明記しました。
【Codex（実装担当）→ Claude（検証担当）：依頼】
実行ID: example-review-r001
対象: source/ 以下、MEASUREMENTS.json
目的: 技術レビュー。実装は依頼しない。
対象を読み、技術レビューを日本語で返してください。
ファイル編集・作成、コード実行、Git操作、外部送信、
サブエージェント起動はしないでください。
回答は標準出力へ返してください。
背景: （経緯と採用しなかった案）
計測: （数値、測定条件と限界）
制約: （品質や互換性など）
未実施の検証を「確認済み」と書かないでください。
※掲載用に一般化した抜粋です。依頼文の禁止事項だけでは技術的な権限制御にはなりません。
3. CodexがClaude Codeを起動する
Claudeの初稿では推定コマンドでしたが、Codexのログで実際の引数が確認できました。パスのみ匿名化しています。
args = [
"<ユーザーホーム>/.local/bin/claude.exe",
"-p",
"--safe-mode",
"--restricted",
"--tools", "Read,Glob,Grep",
"--allowedTools", "Read,Glob,Grep",
"--strict-mcp-config",
"--permission-mode", "plan",
"--no-session-persistence",
"--output-format", "json",
]
-p は非対話で処理して終了する指定で、内部が1ターンという意味ではありません。今回は33ターンでした。--tools は利用可能な組み込みツールを絞り、--allowedTools は指定ツールの権限を許可します。--restricted なども併用しており、--allowedTools 単独で読み取り専用が保証されるわけではありません。
起動はシェルのリダイレクトではなく、Pythonの subprocess.Popen を使いました。
import subprocess
from pathlib import Path
p = Path("<レビュー専用フォルダー>")
# args は上記の配列
process = subprocess.Popen(
args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
cwd=p,
)
out, err = process.communicate((p / "REQUEST.txt").read_bytes())
(p / "CLAUDE_RESPONSE.json").write_bytes(out)
(p / "CLAUDE_STDERR.txt").write_bytes(err)
# 終了コードは run.json に記録
※実行ログからの説明用抜粋であり、単体で完結する配布スクリプトではありません。実運用ではタイムアウト・例外処理・実行前承認なども検討してください。
4. 実行結果とハッシュ照合
JSONの result を回答本文として保存しました。改行コードを正規化すると保存本文と一致しています。
| 項目 | ログの値 |
|---|---|
| CLI報告の所要時間 | 約8分5秒（484,962 ms） |
| ターン数 | 33 |
| 終了コード | 0 |
| 結果種別 | success |
| 権限拒否の記録 | 0件 |
| 標準エラー | 0バイト |
| 出力JSON | 25,034バイト |
| 回答本文 | 23,196バイト |
| SHA-256照合対象 | 123ファイル |
| 対象ファイルの不一致 | 0件 |
所要時間はClaude Codeが報告した値です。ハッシュ一致は対象コピー123ファイルが照合時点で一致したことを示し、PC全体の無変更や途中の一時的な変更がなかったことまでは証明しません。permission_denials: [] は記録された拒否がなかったという意味で、禁止操作を一切試みなかったとは断定しません。
Codexはレビュー結果を鵜呑みにしなかった
Claudeの提案をCodexが評価した例を一般化すると、次のようになります。
| Claudeの提案 | Codexの判断 | 理由 |
|---|---|---|
| 処理時間を工程別に測定 | 採用 | ボトルネック特定のため |
| 内側のループを整理 | 保留 | 品質・状態一致の検証が必要 |
| ソースから生成命令を断定 | 断定を採用せず | 生成コードと計測が必要 |
| 重複する描画を省く | 比較案として実装 | 時間方向の品質も評価するため |
| 到達性能の見積もり | 実測値としては不採用 | ビルド・実行で未検証 |
| 前提の異なる数え方による実装不可の主張 | 却下 | 配置数と画像パターン数は別 |
その後、Codexは描画回数の比較版と処理別の計測版を実装しました。保存された検証記録では内部状態・画像の一致や全画素比較のPASSが確認されています。ただし、性能改善そのものが実証されたわけではありません。最適化案の一部は着手段階です。
安全性：できたことと限界
[安全対策の層と限界]
今回の対策は、選別コピー、CLIのツール制限、依頼文の禁止事項、実行後のハッシュ照合の組み合わせです。
確認できたこと：制限付きの引数で起動したこと、対象123ファイルのハッシュ一致、正常終了、権限拒否の記録0件。
保証できないこと：OSレベルでの完全隔離、PC全体の無変更、途中の一時的な書き換えがなかったこと、全通信の遮断。
Claude Codeは推論サービスと通信するため、「ソースがPC外へ一切送られない」構成ではありません。機密コードを扱う場合は契約や社内ポリシーも確認してください。公式の権限設定説明も参考になります。
また、今回はCodexの報告までClaude Codeの起動に気づきませんでした。便利な一方、実行前承認・利用量上限・ログ監査は継続運用で検討すべき点です。
費用について
出力JSONには total_cost_usd: 1.9224216 と記録されていました。これはCLIが報告した費用相当の数値であり、実際の請求額を証明するものではありません。プランや認証方式によって意味が変わるため、実請求額とは区別します。
従来のAI間Handoffとの使い分け
| 今回の直接起動 | ファイル経由の受け渡し | |
|---|---|---|
| 呼び出し | CodexがClaude Codeを起動 | 各AIが依頼・回答を受け渡す |
| 人間の関与 | 開始指示と事後確認 | 運用に応じて途中承認・仲介 |
| 方向 | 今回確認したのは一方向 | 設計上は双方向も可能 |
| 用途 | 定型レビュー・独立検証 | 方針相談・長期タスク・複数AIの議論 |
今回はGitHubや独自オーケストレーターを必須としない方式です。ただし相手AIを直接起動できる環境と権限が必要です。
まとめ
AIが別のAIを呼ぶだけでなく、その回答を評価して後続の検証へつなげるところまで確認できました。
一方で、権限、ソースの送信先、実行前承認、費用管理は欠かせません。複数AIを使うほど、誰が何を実行し、どこまで確認したのかを記録する重要性が増すと感じました。