Codexのサブエージェントのモデルはどう決まるのか — 「メインと同じ」と「自動で選ぶ」が両方正しい理由

なぜ説明が2通りあるように見えるのか

サブエージェントの定義ファイルには、その担当が使うモデルを決める model と、どこまで深く考えさせるかを決める model_reasoning_effort を書けます。どちらも任意項目で、書かなくてもエージェントは動きます。問題は「書かなかったとき何が起きるか」の説明が、資料によって次の2通りに見えることです。

• 書かなければメインと同じ設定で動く — 定義ファイルは呼び出し元の設定に重ねて読み込まれるので、書かなかった項目は引き継がれる
• どちらも指定しなければ、Codexが仕事に合った組み合わせを自動で選ぶ — 賢さ・速さ・費用のバランスを取って構成が決まる

この2つは矛盾していません。指定が見つからなかったときにCodexが順番にたどる段が違うだけです。順番を知らないまま設定すると、「1つ下のモデルに固定したつもりが上位モデルで動いていた」「レビュー担当だけ深く考えさせたかったのに浅いままだった」といったズレが起きます。しかも実行結果の見た目は変わらないため、費用や品質の差になって初めて気づくのが厄介なところです。

モデルと推論レベルが決まる4段の優先順位

2026年8月時点の公式ドキュメントによると、Codexは model と model_reasoning_effort をそれぞれ独立に、上から順に確認して決めます。上の段で値が見つかった時点で確定し、見つからなければ次の段へ下りていきます。

そして、①〜④のどこにも指定がなければ、Codexが仕事の内容に合わせて構成を選ぶことがあります。公式ドキュメントでも、モデルと推論レベルを固定しない場合、Codexが賢さ・速さ・費用のバランスを取った組み合わせを選べる、と説明されています。冒頭の2つの説明は、こう並べると位置づけがはっきりします。「メインと同じ」は④の話、「自動で選ぶ」は①〜④がすべて空のときの話です。

① 担当の .toml に書いてある？ ─ Yes → その値で確定
              │ No
② 呼び出すときに指定した？   ─ Yes → その値で確定
              │ No
③ config.toml の [agents] に既定がある？ ─ Yes → その値で確定
              │ No
④ メイン（親）の値を引き継ぐ
              │ どこにも無い
   Codexが仕事に合わせて選ぶことがある

落とし穴① モデルと推論レベルは別々に決まる

見落としやすいのは、この4段が model と model_reasoning_effort で別々に処理される点です。片方だけ指定すると、もう片方は独自に段を下って決まります。「モデルだけ軽いものに切り替えたら、思考の深さまで想定と違っていた」という食い違いは、ここから生まれます。

さらに、呼び出し時に別のモデルが選ばれ、推論レベルの指定がどこにもない場合は、そのモデルの既定の推論レベルが使われます。メインの推論レベルが自動的に引き継がれるとは限らない、ということです。担当ごとに動きを固定したいなら、モデルと推論レベルは片方だけでなくセットで書くのが安全です。

# .codex/agents/pre-check.toml
name = "pre-check"
description = "社外へ出す文書の最終チェック担当。表記ゆれと出してはいけない情報を洗い出す"
model = "gpt-5.6"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
あなたは社外提出前のチェック担当です。
渡された文書を1文ずつ確認し、次の3点を一覧で報告してください。
1. 社名・製品名・敬称の表記ゆれ
2. 社外に出すべきでない情報（顧客名・未公開の数値）
3. 事実確認が取れていない断定表現
文書そのものは編集しません（指摘のみ）。
"""

落とし穴② 権限や外部ツールは「自動で選ばれない」

もう1つ、混同しやすい違いがあります。定義ファイルに書かなかった sandbox_mode（どこまで書き込みを許すか）・mcp_servers（持たせる外部ツール）・skills.config（使わせるスキル）は、親から引き継がれます。モデルのような「指定がなければCodexが選ぶ」という挙動ではありません。

実務ではここが効きます。チェックやレビューの担当を作るとき、sandbox_mode を書き忘れると、メイン側が書き込み可の設定で動いていればその担当も書き込める状態のままになります。「指摘だけさせるつもりが、原稿を直してしまった」を避けるには、読むだけでよい担当に read-only を明示的に書いておきます。

権限設計の全体像はCodexのセキュリティ設定で解説しています。

どこに書くか — 3つの置き場の使い分け

順番がわかれば、置き場の判断はシンプルになります。その設定を「いつも同じにしたいのか、状況で変えたいのか」で書く場所が決まります。

# ~/.codex/config.toml
[agents]
# サブエージェントの既定の推論レベル
default_subagent_reasoning_effort = "medium"
# サブエージェントの既定モデル（軽めのモデルIDを指定する）
# default_subagent_model = "..."
# 同時に走らせるサブエージェントの上限（メインは含まない）
max_concurrent_threads_per_session = 4

この3つを混ぜないことが、そのまま運用の安定につながります。よくある失敗は、本当は「今回だけ」の設定を担当の定義ファイルに書いてしまうことです。①がいちばん強い段なので、あとから依頼文で「今回は軽いモデルで」と伝えても効きません。

担当ごとの配分をどう決めるか（読む担当は下げ、確かめる担当は下げない）という考え方はCodexのサブエージェントと並列実行で、モデル自体の選び方はCodexのモデルで解説しています。

法人で使うときに効いてくること

個人で試している段階なら、指定なしでCodexに選ばせる運用でまったく問題ありません。むしろ最初は余計な設定をせず、頼み方の型を身につけるほうが先です。ただしチームで同じ仕組みを共有し始めると、この優先順位を押さえているかどうかで差が出ます。

• 利用量の予測が立つ — サブを5体並べれば単純に5回分の利用量がかかります。全体設定に既定を1行置いておけば、誰が回しても読み込み工程は軽いモデルで走ります
• 品質のばらつきが減る — 「指定なしで自動」に任せると、同じ依頼でも構成が変わりえます。チェックやレビューのように見落としが致命傷になる担当は、定義ファイル側で固定して揺らさないほうが安全です
• 属人化を防げる — 設定が個人の依頼文の中だけにあると、その人以外は再現できません。既定を設定ファイルに、固定したい担当を定義ファイルに置けば、仕組みとして引き継げます

当社が支援先で仕組み化を設計するときも、「既定は全体設定に、例外は担当ごとに、その場の判断は依頼文に」という3階層で整理しています。

担当の定義ファイルがマークダウンではなくTOML形式である理由（＝設定値の集まりだから）はCodexのSubagentだけTOMLなのはなぜかで解説しており、この記事の話とあわせて読むと、設定の置き場所が腹落ちしやすくなります。

迷ったときの3つの問い

サブエージェントの設定で迷ったら、次の順に自問すると判断できます。

1. 1この設定は毎回同じか？ — 毎回同じなら担当の定義ファイル、状況で変えるなら書かない
2. 2モデルと推論レベルをセットで書いたか？ — 片方だけ書くと、もう片方は別に決まる
3. 3書き込みを許す必要があるか？ — 不要なら read-only を明示する（書かないと親のまま引き継がれる）

当社自身、40以上の業務をAIエージェントに任せる中で、こうした設定の置き場所を1つずつ決めてきました。どの業務を担当として切り出し、どこまでを既定に寄せるか——当社のCodex研修・導入伴走支援では、貴社の実業務を題材に、担当設計から運用の定着までを一体でご支援しています。