TL;DR：config.toml と AGENTS.md で，既定の挙動を設計する
Codexを使っていて，毎回
「サブエージェントを使って構いません」
と明示するのが少し面倒だと感じたことはないでしょうか．
私も，Codex App や VSCode拡張を使った普段の開発で，同じことを感じていました．
単発の修正なら問題ないのですが，少し大きめの作業になると，実際には次のような流れが自然に発生します．
まず関連ファイルを探す
既存実装の意図を読む
必要な変更を入れる
副作用や不足テストを確認する
このとき，毎回明示的に「調査役」「実装役」「レビュー役」を呼ぶよりも，最初からCodexがそのように振る舞ってくれた方が扱いやすいはずです．
そこで今回は，Codexを“デフォルトでマルチエージェント寄り”に動かすための設定構成をまとめます．
対象は主に，Codex App / VSCode拡張メインで開発している人です．
なお，この記事で扱うのは
「常に強制的にマルチエージェント化する」設定ではありません．
必要な場面では自然にマルチエージェントを第一候補として選びやすくする設計です．
こういう人に向いています
Codexを使っているが，毎回指示を足すのが面倒
少し大きめの修正で，探索・実装・レビューを分けたい
VSCode拡張やCodex Appで，より実務向けの挙動に寄せたい
単発のコード補助ではなく，役割分担を前提とした作業相手として使いたい
結論
Codexを毎回マルチエージェント寄りにしたいなら，次の2つを整えるのが本筋です．
~/.codex/config.toml に subagent の全体設定と，各役割の agent 定義を書く
~/.codex/AGENTS.md に「どんな場面で分解し，どう委譲するか」をグローバル指示として書く
この2層を持っておくと，Codexは初手から
単独で抱え込むべきか
調査役を先に出すべきか
実装とレビューを分けるべきか
を判断しやすくなります．
つまり，ポイントはスイッチを探すことではなく，既定の行動様式を設計することです．
なぜ config.toml と AGENTS.md を分けるのか
ここはかなり重要です．
config.toml は，機構側の設定です．
たとえば，
どのモデルを使うか
approval policy をどうするか
sandbox をどうするか
agent を何体定義するか
どこまで subagent をネストさせるか
といった，Codexの土台を決めます．
一方で AGENTS.md は，振る舞い側の設定です．
たとえば，
中規模以上ならまず分解する
調査と実装を同じ agent に抱え込ませない
実装後は reviewer を通す
小さな単発修正なら単一 agent でよい
といった，判断原則を書きます．
この2つを分けておくと，構成がかなり安定します．
単に agent を定義するだけでは不十分で，どういう時にそいつを使うのかまで書いておく必要があります．
おすすめの完成形
ファイル構成は次のようにしておくと扱いやすいです．
~/.codex/
├─ config.toml
├─ AGENTS.md
└─ agents/
├─ planner.toml
├─ explorer.toml
├─ implementer.toml
└─ reviewer.toml
この4役構成はかなりバランスが良いです．
最初から役割を増やしすぎると重くなりやすいので，まずはこの4つから始めるのが無難です．
ここまでは，Codexをマルチエージェント寄りに動かすための考え方を整理しました．
ここから先は，実際にそのまま使える config.toml，AGENTS.md，各 agent 設定の完成版と，運用時の調整ポイントをまとめます．
追伸
現在，Coda Intelligence Lab として，AIを活用した講習，開発，自動化，運用設計などの取り組みも進めています．
「AIを試しているが，実務で機能する形に落とし込みたい」「開発や運用をもう少し整理したい」といった相談があれば，内容に応じて対応可能です．
活用方針の整理から，実際の導入設計・開発まで含めて相談可能ですので，関心のある方はご連絡ください．
TL;DR：
config.tomlとAGENTS.mdで，既定の挙動を設計するCodexを使っていて，毎回
「サブエージェントを使って構いません」
と明示するのが少し面倒だと感じたことはないでしょうか．
私も，Codex App や VSCode拡張を使った普段の開発で，同じことを感じていました．
単発の修正なら問題ないのですが，少し大きめの作業になると，実際には次のような流れが自然に発生します．
まず関連ファイルを探す
既存実装の意図を読む
必要な変更を入れる
副作用や不足テストを確認する
このとき，毎回明示的に「調査役」「実装役」「レビュー役」を呼ぶよりも，最初からCodexがそのように振る舞ってくれた方が扱いやすいはずです．
そこで今回は，Codexを“デフォルトでマルチエージェント寄り”に動かすための設定構成をまとめます．
対象は主に，Codex App / VSCode拡張メインで開発している人です．
なお，この記事で扱うのは
「常に強制的にマルチエージェント化する」設定ではありません．
必要な場面では自然にマルチエージェントを第一候補として選びやすくする設計です．
こういう人に向いています
Codexを使っているが，毎回指示を足すのが面倒
少し大きめの修正で，探索・実装・レビューを分けたい
VSCode拡張やCodex Appで，より実務向けの挙動に寄せたい
単発のコード補助ではなく，役割分担を前提とした作業相手として使いたい
結論
Codexを毎回マルチエージェント寄りにしたいなら，次の2つを整えるのが本筋です．
~/.codex/config.tomlに subagent の全体設定と，各役割の agent 定義を書く~/.codex/AGENTS.mdに「どんな場面で分解し，どう委譲するか」をグローバル指示として書くこの2層を持っておくと，Codexは初手から
単独で抱え込むべきか
調査役を先に出すべきか
実装とレビューを分けるべきか
を判断しやすくなります．
つまり，ポイントはスイッチを探すことではなく，既定の行動様式を設計することです．
なぜ
config.tomlとAGENTS.mdを分けるのかここはかなり重要です．
config.tomlは，機構側の設定です．たとえば，
どのモデルを使うか
approval policy をどうするか
sandbox をどうするか
agent を何体定義するか
どこまで subagent をネストさせるか
といった，Codexの土台を決めます．
一方で
AGENTS.mdは，振る舞い側の設定です．たとえば，
中規模以上ならまず分解する
調査と実装を同じ agent に抱え込ませない
実装後は reviewer を通す
小さな単発修正なら単一 agent でよい
といった，判断原則を書きます．
この2つを分けておくと，構成がかなり安定します．
単に agent を定義するだけでは不十分で，どういう時にそいつを使うのかまで書いておく必要があります．
おすすめの完成形
ファイル構成は次のようにしておくと扱いやすいです．
この4役構成はかなりバランスが良いです．
planner：要件整理，分解，委譲方針決定explorer：コード探索，依存関係確認，影響範囲調査implementer：最小差分で実装変更reviewer：副作用，不足テスト，仕様逸脱の確認最初から役割を増やしすぎると重くなりやすいので，まずはこの4つから始めるのが無難です．
ここまでは，Codexをマルチエージェント寄りに動かすための考え方を整理しました．
ここから先は，実際にそのまま使える
config.toml，AGENTS.md，各 agent 設定の完成版と，運用時の調整ポイントをまとめます．追伸
現在，Coda Intelligence Lab として，AIを活用した講習，開発，自動化，運用設計などの取り組みも進めています．
「AIを試しているが，実務で機能する形に落とし込みたい」「開発や運用をもう少し整理したい」といった相談があれば，内容に応じて対応可能です．
活用方針の整理から，実際の導入設計・開発まで含めて相談可能ですので，関心のある方はご連絡ください．