Codex を使い始めると、最初は「一番強いモデルを常に選べばよい」と考えがちです。けれど実務では、モデルを強くしただけでは安全にも速くもなりません。調査、実装、PRレビュー、CIの要約、定期 automation を同じモデルと同じ reasoning effort で回すと、軽い仕事が重くなり、重い仕事はレビュー不能になり、失敗したときに原因も追えません。
この記事では、Codex の model selection を作業 lane ごとに固定する設計を扱います。GPT-6 Astraへ上げる前後のprompt・tool・検証の再審査は Codex GPT-6 Astra 移行設計ガイド、sandbox や approval の切り替えは Codex config / profile 設定ガイド、CIで codex exec を回す契約は Codex CI / non-interactive 設計ガイド、定期実行の仕事選定は Codex Automations 実践ガイド、token や tool call の上限設計は AIエージェント予算ガードレール設計ガイド に分けています。
今回の論点は、権限や予算の前に、どの種類の仕事へどのモデル、どの reasoning effort、どの escalation path を割り当てるかです。
先に結論: モデルは「強さ」ではなく lane で選ぶ
私なら、Codex のモデル選択を次のように始めます。
| 作業 lane | 最初の選択 | 上げる条件 | 人間の確認 |
|---|---|---|---|
| 日常実装 | Terra + medium | 仕様が曖昧、影響範囲が広い、設計判断を含む | diff review |
| 深い設計・移行調査 | Sol + medium / high | 複数repo、未確定仕様、セキュリティ判断を含む | plan review |
| 定型の要約・分類 | Luna + low / medium | 失敗が続く、抽出漏れがある | spot check |
| PRレビュー | Terra + medium | 認可、secret、データ削除、外部副作用を含む | finding triage |
| セキュリティ調査 | Sol + high | threat model が未整理、攻撃面が複数ある | security owner review |
| scheduled task | Luna / Terra + low / medium | inbox で再調査が必要になった | inbox review |
大事なのは、Sol / Terra / Luna を「賢い順に常用する」ことではありません。OpenAI の Codex docs では、Sol は複雑で open-ended な coding や調査、Terra は日常的な coding、Luna は明確で反復的な仕事に向く、と整理されています。この差を、作業 lane とレビュー方法へ落とします。
Sol を使う仕事
Sol は、最初の入力だけでは正解の形が決まらない仕事に使います。
- 大きな設計変更の調査
- 既存仕様と実装の差分確認
- セキュリティ観点を含むコードレビュー
- 複数の公式ドキュメントを突き合わせる移行判断
- 失敗した automation の原因分析
たとえば、認可まわりの修正を任せるときは、単に fix auth bug と投げるのではなく、Sol に plan を作らせます。
Use Sol with high reasoning.
Goal:
- Investigate the authorization regression.
- Do not edit files yet.
- Return affected routes, suspected policy gap, required tests, and rollback risk.
Stop:
- If the change touches billing, tenant isolation, or deletion paths, stop with a review packet.ここで Sol に期待するのは「一発で直すこと」ではありません。影響範囲、未確定点、止めるべき条件を早めに出させることです。実装に入る前の plan review を挟めば、強いモデルを広い権限で暴走させる使い方になりません。
Terra を既定にする仕事
Terra は、普段の実装や修正の既定値にしやすいモデルです。公式 docs でも、日常的な coding work では Terra が速度、性能、コストのバランスを取りやすい選択として説明されています。
私なら、次のような仕事は Terra から始めます。
- 1つのコンポーネントのバグ修正
- テスト追加を伴う小さな API 変更
- 既存パターンに沿ったページ追加
- CI失敗ログからの原因切り分け
- PRコメントへの限定対応
ただし、Terra を既定にしても、差分の種類で止めます。次のどれかが出たら Sol に上げるか、人間へ戻します。
- DB migration やデータ削除が必要になった
- auth、billing、secret、tenant isolation に触れる
- 既存設計の変更が必要になった
- 3ファイル程度の局所修正を超え始めた
- Codex が同じ原因で2回失敗した
「普段は Terra」で十分ですが、「危ない領域も Terra で押し切る」は違います。model selection はコスト削減ではなく、レビュー境界を揃えるための設計です。
Luna を使う仕事
Luna は、入力と出力の形がはっきりしている仕事に向きます。
- CIログの要約
- changelog から該当項目だけ抜き出す
- GSC query をカテゴリ分けする
- PR差分から release note 草案を作る
- inbox に戻す短い判定メモを作る
Luna に任せるときは、自由作文にしない方が安定します。
Use Luna with low reasoning.
Input:
- CI log
- Changed file list
Return:
- failed_command
- likely_cause
- owner
- next_action
- confidence: high | medium | low
Do not propose code changes.このように output contract を狭くすると、軽いモデルでも十分に仕事になります。逆に、Luna に曖昧な調査や大きな設計判断を任せると、速いが浅い出力を人間が補うことになり、結局高くつきます。
reasoning effort は「低い順」から上げる
reasoning effort は、モデル名とは別の設計変数です。OpenAI の config reference では minimal、low、medium、high、xhigh のような段階が説明されています。私は、最初から高くするのではなく、失敗条件に応じて上げます。
| 状況 | effort | 理由 |
|---|---|---|
| 決まった形式の要約 | low | 深い推論より形式遵守が重要 |
| 既存パターンに沿う実装 | medium | 速度と検討量のバランスを取る |
| 設計変更や移行判断 | high | 代替案、影響範囲、rollback を見たい |
| 複数repoや攻撃面の調査 | high / xhigh | 見落としコストが高い |
xhigh を常用しない方がよいです。重い reasoning は、判断材料が多い仕事では有効ですが、入力が曖昧なままだと長く考えた曖昧な答えになります。先に task packet、対象ファイル、禁止事項、検証コマンドを狭める方が効果的です。
Max と Ultra はモデル選択の代替ではない
Codex docs では、Max は選んだモデルにより長く取り組ませる選択、Ultra は大きな仕事を subagent に分けて並列化する選択として説明されています。これは「強いモデルをさらに強くする魔法」ではありません。
Max が向くのは、1つの難しい仕事です。
- 複雑な migration plan を1本にまとめる
- flaky test の原因を深く掘る
- 大きな設計差分の review packet を作る
Ultra が向くのは、分割できる仕事です。
- 複数moduleの影響調査
- 競合PRの役割分担チェック
- article cluster の重複チェック
- 大きな codebase の責務境界調査
Ultra を使うときは、subagent の数ではなく、統合レビューを先に決めます。並列で調べた結果を誰が統合し、どの finding を採用し、どれを捨てるのかが曖昧なら、速くなる代わりに判断材料が散らかります。
profile へ落とす単位
モデル選択は、その場の気分で /model を叩くだけだと再現性がありません。Codex CLI では /model でモデルと reasoning effort を選べますが、実務では profile と runbook に落とした方が安全です。
例として、私は次の3つに分けます。
# ~/.codex/research-deep.config.toml
model_reasoning_effort = "high"
sandbox_mode = "read-only"
approval_policy = "on-request"# ~/.codex/implementation.config.toml
model_reasoning_effort = "medium"
sandbox_mode = "workspace-write"
approval_policy = "on-request"# ~/.codex/automation-summary.config.toml
model_reasoning_effort = "low"
sandbox_mode = "read-only"
approval_policy = "never"起動時に model を明示するなら、次のように runbook 側へ書きます。
codex --profile research-deep -m gpt-5.6-sol
codex --profile implementation -m gpt-5.6-terra
codex exec --profile automation-summary -m gpt-5.6-luna "summarize new CI failures"この分け方なら、model、reasoning、sandbox、approval が同じ作業名で追えます。あとから「なぜこの automation だけ高コストだったのか」を見直すときも、会話ログだけに依存しません。
saved config と scheduled task の移行
OpenAI の docs では、Codex の saved configurations、custom agents、scheduled tasks で古いモデル名を使っている場合の移行にも触れています。gpt-5.4 系から gpt-5.6-terra、mini 系から gpt-5.6-luna へ置き換える、という考え方です。
ここでやってはいけないのは、全タスクを一括で最新の強いモデルへ置き換えることです。scheduled task は、人間が見ていない時間に走ることがあります。だから、移行時は次を確認します。
- task の目的は調査、実装、要約、通知のどれか
- output は inbox でレビューできる粒度か
- write action や外部送信を含まないか
- 失敗時に再実行せず停止する条件があるか
- モデル変更後の初回結果を人間が読む予定があるか
モデル移行はアップグレード作業ではなく、運用契約の再確認です。
よくある失敗
1. 強いモデルを default にして運用を隠す
Sol を default にすると、短期的には出力が良く見えます。ただ、軽い仕事まで重くなり、どの仕事が本当に深い reasoning を必要としていたのか分かりにくくなります。default は Terra、深い調査は Sol、定型要約は Luna のように分けた方が振り返りやすいです。
2. reasoning effort で要件の曖昧さを埋める
high にすれば曖昧な依頼を補ってくれる、という期待は危険です。曖昧な要件には確認、狭い change budget、検証コマンドが必要です。reasoning effort は、良い入力に対する検討量を増やすものとして扱います。
3. Max / Ultra をレビュー不足の穴埋めにする
大きな仕事を Max や Ultra に投げるほど、出力を読む側の責任は増えます。人間の review owner、採用基準、停止条件がないなら、先にそこを決めます。強い実行モードはレビューの代わりにはなりません。
4. model selection と approval policy を混ぜる
モデルを強くしても、書き込み権限を広げてよい理由にはなりません。逆に、Luna だから安全ということもありません。model selection は能力とコストの設計、approval policy は外部副作用の設計です。別々に決めます。
導入チェックリスト
- default model を Terra 相当に置く
- deep research / security lane だけ Sol に上げる
- summary / classification / inbox triage は Luna から始める
- reasoning effort は
low/mediumから始め、失敗条件で上げる - Max は単一の難問、Ultra は分割できる調査だけに使う
- saved config と scheduled task の古いモデル名を棚卸しする
- 初回移行後の結果は必ず人間が読む
- model、reasoning、sandbox、approval を同じ lane 名で記録する
Codex の model selection は、モデル一覧を暗記する作業ではありません。仕事の種類、失敗したときの被害、レビューできる粒度、予算を合わせて決める運用設計です。
私なら、まず Terra + medium を普段の実装に置き、Sol は設計・移行・セキュリティ、Luna は要約・分類・定期レポートへ切ります。その上で、Max / Ultra は「本当に長く考える価値があるか」「本当に分割できるか」を確認してから使います。
この設計にしておくと、Codex は「今日はどのモデルが賢いか」ではなく、この仕事はどの lane で、安全に完了させるべきかで選べるようになります。