Claude CodeからOpenAI Codex CLIを呼ぶ最短ルート：agent経由で詰まる前に

Claude Codeで作業していると、たまに「この判断、別のLLMにも意見を聞きたい」と思う瞬間があります。設計判断や法令解釈、複雑なSQL最適化のように「Claudeが正しいと言っているけど、本当か？」と確かめたい場面です。

こういうときに使うのが、OpenAIの Codex CLI（＝OpenAIのコーディングAIをターミナルから使う道具）によるセカンドオピニオンです。Claudeとは別の学習をしたモデルにぶつけることで、同じ穴を見落とすリスクを下げられます。

ところが、Claude CodeからCodexを呼ぶルートは複数あって、間違ったルートを選ぶと毎回権限エラーで止まる。私自身が同じ詰まり方を何度かやって、選定ルールを整理しました。本記事はその手順と、ハマりどころの共有です。

結論：最短ルートは「Codex CLIをBashで直接叩く」

優先順位はこの3段です。

• 第一選択：codex CLIをBash経由で直接呼ぶ。最も確実で、認証も明示的に書ける
• 第二選択：codex-rescue agent経由。環境によってはBash権限拒否で失敗する
• やってはいけない：「Codexを呼ぶ手段がない」と思い込んで諦める

理由は構造的なものです。Claude Codeのagent機能は内部でBashスクリプトを起動しますが、Bash実行権限が制限された環境ではagentの一段奥でBashが拒否されることがある。CLI直接呼びなら、その層をスキップできます。詰まりの原因は「ルート選びのミス」であって、Codexが使えないわけではない。

第一選択：Codex CLIをBashで直接呼ぶ手順

ステップ1：CLIの存在確認

which codex
# /Users/you/.nvm/versions/node/v23.10.0/bin/codex のように出ればOK

存在しない場合は npm install -g @openai/codex-cli 等でインストールします（バージョンは公式リポジトリで確認）。

ステップ2：API keyの取得

OpenAI API keyは平文で .env に置かず、1Password等のシークレットマネージャから取り出すのが安全です。1Passwordの場合はこうなります。

export OPENAI_API_KEY=$(op item get "OpenAI API Key - Codex CLI" \
  --vault Development \
  --fields credential \
  --reveal)

ステップ3：プロンプトをファイル化して渡す

長いプロンプトをコマンドラインに直接書くと、改行・引用符でハマりがちです。ファイル経由にしておくと事故が減ります。

cat > /tmp/prompt.txt <<'EOF'
以下の設計案について、独立した立場から指摘してください。
特に「データ整合性」「障害時の挙動」「PII保護」の観点でレビューしてください。

[設計案を貼る]
EOF

codex exec \
  --model gpt-5.5 \
  -c model_reasoning_effort=xhigh \
  "$(cat /tmp/prompt.txt)"

ステップ4：長時間タスクはバックグラウンド実行

Codexの xhigh reasoning effort（＝推論にどれだけ計算を割くかの強度設定）は、案件によって10〜20分かかることがあります。Claude Codeのバックグラウンド実行機能（run_in_background: true）に逃がせば、待っている間も別作業を進められます。

注意点：reasoning effortは -c で指定する

Codex CLIで一番ハマるのが、reasoning effortのflag指定です。専用flagがありそうに見えて、実は存在しない。

動かない書き方:

codex exec --model gpt-5.5 --effort xhigh "..."          # NG
codex exec --model gpt-5.5 --reasoning-effort xhigh "..."  # NG

正しい書き方:

codex exec --model gpt-5.5 -c model_reasoning_effort=xhigh "..."

-c key=value で ~/.codex/config.toml の値をオーバーライドする方式です。codex exec --help | grep effort を実行して何も出てこなければ、専用flagは無いと判断していい。

恒久的に設定したいなら ~/.codex/config.toml に書けます。

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

ただし複数PC間でconfig.tomlが同期されていない可能性があるので、スクリプト内では明示指定するほうが事故が少ない。

第二選択：agent経由を試す場面

Claude Codeのagent機能には codex-rescue（＝Codex連携を定型化した補助エージェント）のような名前のCodex連携agentが提供されることがあります。

これが使えるときのメリットはこのあたりです。

• Codex呼び出しのプロンプト設計が定型化されている
• 結果のフォーマットが安定している
• Claude側からの呼び出しが1ステップで済む

ただし内部実装は codex-companion.mjs をBash経由で起動するケースが多く、Bash実行が拒否される環境では失敗します。失敗したらユーザーに権限承認を求めるのではなく、第一選択のCLI直叩きにフォールバックするのが正解。

Claude Code以外のAI CLIも織り交ぜて使い分けたい人は、複数AI CLIを併用するセットアップ手順を先に整えておくと、呼び出しルートの全体像が掴みやすくなります。

アンチパターン3つ

アンチパターン1：いきなりagentを起動する

「agent経由のほうが楽そう」と毎回agentから入ると、Bash拒否で詰まる。第一選択はCLI直叩き、これを習慣化するだけで詰まりが消えます。

アンチパターン2：「Codexを呼ぶ手段がない」と思い込む

API keyが1Passwordに入っていることを忘れて、「Codex用のkeyがない」と諦めるパターン。1Passwordの検索は op item list | grep -i codex で一発で出ます。手段がないのではなく、探していないだけ。

アンチパターン3：Bash拒否されてからユーザーに権限承認を頼む

「Bashが拒否されたので承認してください」をルーチン化すると、ユーザーの作業を毎回中断させてしまう。最初からCLI直叩きを試せば、承認プロセスを挟まずに済みます。

持ち帰り：呼び出しルート選定チェックリスト

セカンドオピニオンを取る前に、この順で上から試すと詰まりません。

• which codex でCLIの存在を確認した
• API keyは1Passwordから op item get で取り出している（平文 .env に置いていない）
• reasoning effortは -c model_reasoning_effort=xhigh で指定している（--effort 系ではない）
• 長いプロンプトは /tmp/prompt.txt 等にファイル化して "$(cat ...)" で渡している
• 10分超のタスクはバックグラウンド実行に逃がした
• agentで失敗したら、権限承認を頼む前にCLI直叩きへフォールバックした

まとめ：直接呼べるなら直接呼ぶ

Claude Codeから外部LLMを呼ぶときの原則は「呼び出し層は薄ければ薄いほど壊れにくい」です。

セカンドオピニオン取得のように確実性が求められるタスクほど、層を薄く保つ。これがClaude Code × 外部LLM併用の基本です。

AIエージェント運用設計でお困りなら

「Claudeに任せた判断を別のAIでクロスチェックしたいが、毎回呼び出しで詰まる」「複数LLMを使い分ける運用を社内で標準化したいが、認証やフォールバックの設計が固まらない」。そんな状況なら、運用設計の細部こそが止まらない仕組みの肝です。

f2t.jpでは、複数LLM併用前提のエージェント設計から、認証・権限・失敗時フォールバックを含めた運用体制まで支援しています。お問い合わせフォームからお気軽にどうぞ。