Codex CLI で選択できるモデル一覧を見ると、gpt-5.4、gpt-5.3-codex、gpt-5.2 など表示されます。ここでは単一のモデルを選択することになります。
しかし、実際はマルチエージェントで実行されます。親エージェント、実装役、高速修正役、長時間無人実行、技術書執筆・レビューでは必要な性質が異なるため、全部を1種類のモデルにすると品質・速度・コストのバランスが崩れます。
そこで本稿では、Codex CLI をマルチエージェント構成で運用し、役割ごとにモデルを割り当てる設計を整理します。あわせて、OpenAI 公式 docs に加えて codex exec で runtime support を検証しました。実際に使えるモデルを profile に反映する手順も示します。ベースにした公開リポジトリは https://github.com/itdojp/codex-cli-model-playbook です。なお当方Pro x20プランです。
最初にまとめ
- Codex CLI は単一モデルを選ぶより、親・実装・高速修正・長時間無人実行・技術書執筆/レビューで役割分担した方が安定します。
- 現在の運用では、親は
gpt-5.4、深い実装はgpt-5.3-codex、高速小修正はgpt-5.3-codex-spark、長時間無人実行はgpt-5.2を使っています。 - picker に表示されるモデルと、実際にアカウントで実行できるモデルは一致しないことがあります。
- そのため、OpenAI docs の確認だけでなく、
codex execによる runtime check を profile 採用前に行うべきです。
この記事で分かること
- Codex CLI のモデルを「親」「実装」「高速修正」「長時間無人実行」「技術書執筆」でどう分けるか
- picker に表示されるモデルと、実際に使うべきモデルをどう切り分けるか
- その判断を再利用可能なドキュメントや設定サンプルに落とす方法
対象読者
- Codex CLI を継続的に使っている開発者
- 複数モデルの使い分けに迷っている人
- ソフトウェア開発と技術書執筆の両方で AI エージェントを使いたい人
- picker に出るモデルをそのまま採用してよいのか判断したい人
前提
本稿の前提は次の通りです。
- ChatGPT Pro X20プラン契約
- Codex CLI:
0.121.0 - 確認日:
2026-04-18 JST - OpenAI 公式 docs を参照している
- 実際の採用可否は
codex execによる runtime check を優先している
なぜ単一モデル選択の話ではないのか
本稿の主張は、Codex CLI は 1 つのモデルを選ぶ話ではなく、マルチエージェント構成の中で役割ごとにモデルを割り当てる話だ、という点です。
具体的には、次の役割を分けて考えます。
- 親にどのモデルを置くか
- 実装役にどのモデルを置くか
- 高速修正役にどのモデルを置くか
- 長時間無人実行にどのモデルを置くか
- 技術書執筆やレビューにどのモデルを置くか
Codex CLI の model picker は、これらを同じレイヤーの選択肢に見せます。しかし実際に設計すると、見るべきポイントは次の 3 点です。
- それぞれが何に向くのか
- 親エージェントと子エージェントをどう分けるか
- 自分のアカウントで本当に実行できるか
結論
現時点の推奨は次の通りです。
ソフトウェア開発
- 親エージェント:
gpt-5.4 - 深い実装:
gpt-5.3-codex - 高速な小修正:
gpt-5.3-codex-spark - 長時間無人実行:
gpt-5.2
技術書執筆
- 主担当:
gpt-5.4 - 大量の整合性確認・用語揃え:
gpt-5.4-mini - コード例の修正:
gpt-5.3-codex
役割とモデルの対応
| 役割 | 採用モデル | 主な理由 |
|---|---|---|
| 親エージェント / 司令塔 | gpt-5.4 |
全体計画、文脈保持、subagent 統合、最終判断を安定して扱いやすい |
| 深い実装 | gpt-5.3-codex |
コード差分生成、テスト修正、CLI 往復の反復に向く |
| 高速小修正 | gpt-5.3-codex-spark |
lint 修正や局所 CI 修正を短時間で回しやすい |
| 長時間無人実行 | gpt-5.2 |
unattended run を分離して運用しやすい |
| 技術書主担当 | gpt-5.4 |
構成整理、説明品質、文脈統合を担わせやすい |
| 整合性確認 / 用語揃え | gpt-5.4-mini |
高ボリューム確認を軽量に並列化しやすい |
この設計で得られた運用上のメリット
- 親が全体計画と統合判断を担い、子が局所タスクに集中するため、レビュー観点と修正方針がぶれにくくなりました。
- 高速修正専用の profile を分けたことで、lint 修正や軽量 CI 修正を重いモデルに流さずに済むようになりました。
- 長時間無人実行を通常セッションから分離したことで、対話作業と unattended run の責務が整理しやすくなりました。
- 技術書側も、主担当と整合性確認役を分けることで、説明品質と処理量の両立がしやすくなりました。
再設計前に起きていた問題
モデル一覧だけを見ると、すべてが同じレイヤーの選択肢に見えます。しかし実際には、必要な役割は異なります。
- 親として全体計画を扱う役割
- 実装を継続的に進める役割
- lint や局所 CI のような高速修正役
- 長時間の unattended run を回す役割
- 技術書の説明構造を組み立てる役割
この役割分離をしないと、重いモデルを雑務に使ったり、逆に軽いモデルに設計判断をさせたりして、運用品質が不安定になります。
なぜ gpt-5.4 を親にするのか
OpenAI の公式 docs では、gpt-5.4 は agentic / coding / professional workflows 向けの frontier model とされています。
実務上も、親エージェントには以下の役割が必要です。
- 全体計画
- 文脈保持
- 複数 subagent の結果統合
- 難所での最終判断
この役割は、実装専任のモデルより gpt-5.4 の方が安定します。
なぜ実装役を Codex 系に分けるのか
一方で、実装や test-fix loop は別の性質を持ちます。
- コード差分の生成
- CLI ツールとの往復
- テスト修正の反復
- ローカルな変更の収束
この層では、Codex 最適化モデルの方が自然です。
そのため、親は gpt-5.4、実装役は gpt-5.3-codex という分離が実務上扱いやすくなりました。
picker に出ても使えないモデルがある
ここが今回の重要点でした。
OpenAI 公式 docs 上では gpt-5.2-codex や gpt-5.1-codex-max も確認できます。しかし、実際に codex exec で試すと、アカウントによっては実行できません。
例えば、以下のように実確認します。
codex exec -m gpt-5.4 --skip-git-repo-check "Reply with OK only."
codex exec -m gpt-5.3-codex --skip-git-repo-check "Reply with OK only."
codex exec -m gpt-5.2-codex --skip-git-repo-check "Reply with OK only."
つまり、判断手順は次の順番にすべきです。
- OpenAI docs でモデル特性を確認する
-
codex execで runtime support を確認する - 実行できるモデルだけを profile に割り当てる
検証で確認したモデル状況
| モデル | picker 表示 | runtime check | 採用状況 | 主な用途 |
|---|---|---|---|---|
gpt-5.4 |
Yes | Supported | 採用 | 親エージェント / 技術書主担当 |
gpt-5.4-mini |
Yes | Supported | 採用 | 高ボリューム整合性確認 |
gpt-5.3-codex |
Yes | Supported | 採用 | 深い実装 |
gpt-5.3-codex-spark |
Yes | Supported | 採用 | 高速小修正 |
gpt-5.2 |
Yes | Supported | 採用 | 長時間無人実行 |
gpt-5.2-codex |
Yes | Unsupported | 不採用 | docs 上は有力だが runtime 不可 |
gpt-5.1-codex-max |
Yes | Unsupported | 不採用 | runtime 不可 |
gpt-5.1-codex-mini |
Yes | Unsupported | 不採用 | runtime 不可 |
なぜ gpt-5.2-codex を採用しなかったか
公式 docs の位置づけだけを見ると、gpt-5.2-codex は長い実装タスク向けの有力候補です。
ただし、今回の環境では codex exec -m gpt-5.2-codex ... が失敗しました。したがって、profile に割り当てる判断は採りませんでした。
ここで重要なのは、docs 上の推奨順位 と 自分のアカウントで実行できるか は別問題だという点です。
実際に使っている profile 構成
| 用途 | profile | model |
|---|---|---|
| 通常のソフトウェア開発 | software_dev |
gpt-5.4 |
| 深い実装 | software_dev_deep_impl |
gpt-5.3-codex |
| 高速修正 | software_dev_fastfix |
gpt-5.3-codex-spark |
| 長時間無人実行 | autonomous_unattended |
gpt-5.2 |
| 技術書執筆 | tech_book |
gpt-5.4 |
| 大量の整合性確認 | tech_book_bulk |
gpt-5.4-mini |
| 技術書レビュー | tech_book_review |
gpt-5.4 |
起動コマンドの実例
ソフトウェア開発
codex -p software_dev
codex -p software_dev_deep_impl
codex -p software_dev_fastfix
codex exec -p autonomous_unattended "<task>"
技術書執筆
codex -p tech_book
codex -p tech_book_bulk
codex -p tech_book_review
最短導入手順
-
scripts/check_codex_model_support.pyで、現在のアカウントで実行できるモデルを確認する -
examples/config.sample.tomlをベースに profile を作る -
docs/profile-catalog.mdとdocs/quick-commands.mdを見て、用途別に起動コマンドを決める - 必要なら
examples/instructions/とexamples/agents/を自分の環境へ持っていく
リポジトリを見る順番
初めて見る場合は、次の順番を推奨します。
README.mddocs/model-matrix.mddocs/profile-design.mddocs/profile-catalog.mddocs/model-usage-status.mddocs/quick-commands.mdexamples/config.sample.toml
公開リポジトリに入れたもの
- モデル特性の整理表
- プロファイル設計ドキュメント
- 用途別 profile カタログ
- picker 表示モデルと実運用モデルの差分整理
- アカウント互換性チェック手順
config.sample.toml-
deep_coder,fast_workerのサンプル subagent 定義 - ソフトウェア開発用・技術書執筆用・技術書レビュー用の instruction examples
scripts/check_codex_model_support.py
単なる説明記事ではなく、再利用できる運用キットとして公開する方針です。
今後の運用ルール
- モデルは「表示されるか」ではなく「実行できるか」で採用する
- 親と子で役割を分ける
- 高速小修正専用の profile を分ける
- 新しいモデルが出たら、まず
codex execで動作確認する - profile と instruction file はセットで管理する
まずはこの最小セットで始める
最初からすべてを使い分ける必要はありません。最初の運用は次の 3 本で十分です。
software_devsoftware_dev_deep_impltech_book
そこから必要に応じて、
software_dev_fastfixautonomous_unattendedtech_book_bulk
を追加すると、運用を破綻させずに広げやすくなります。
まとめ
Codex CLI のモデル設計では、モデル名そのものよりも次の切り分けが重要です。
- 司令塔か
- 実装役か
- 高速雑務役か
- 長時間無人運転か
- 執筆主担当か
重要なのは、単一モデルの優劣比較よりも、どの役割にどのモデルを置くかを明示的に設計することです。そのうえで、OpenAI docs の情報に加えて、自分のアカウントで本当に走るか を検証してから profile に反映するのが、安全な運用だと考えています。
公開リポジトリ:
公式 docs: