Codexの調査と実装を並列化するサブエージェントの使い方とトークン節約

Codex CLIは、ターミナルからローカルのファイルを読み、編集し、コマンドを実行できるCodexの対話版です。導入後は作業したいプロジェクトのフォルダーへ移動してcodexを実行し、初回だけChatGPTなどの利用可能な方法でサインインします。画面が開いたら、専用の起動コマンドを覚えるのではなく、メインスレッドのCodexへ自然文で仕事を頼みます。

たとえば『このブランチをサブエージェントで並列レビューしてください。セキュリティ、試験不足、保守性を一担当ずつに分け、全員を待ってからファイル位置付きで統合してください』と入力します。現在のCodexは、利用者が明示的に頼んだとき、またはプロジェクトのAGENTS.mdやSkillに委任の指示があるときに子を起動します。

最初は実装を任せず、調査、コード探索、試験実行、ログの分類のような読み取り中心の仕事で試すと動きを理解しやすくなります。子は親と同じ作業フォルダーを見られるため、複数の子へ同じファイルの編集を任せると競合しやすく、編集担当は一体に絞る方が安全です。

利用者が話しているメインスレッドのCodexが親エージェントです。親は依頼を独立して進められる単位へ分け、各子へ担当範囲、完了条件、返却形式を渡します。子は別スレッドでファイルを調べ、コマンドや許可された道具を使い、終わると要点を親へ返します。

親は子の途中ログをそのまま連結しません。結果の重複を除き、矛盾を確かめ、必要なら追加確認を頼み、最後に一つの回答へまとめます。メインスレッドには要件、判断、最終成果物を残し、大量の検索結果や試験ログを子のスレッドへ逃がせるため、長い作業でも会話の焦点を保ちやすくなります。

子は親が別のプログラムとして外部起動するのではなく、Codexが管理する別のエージェントスレッドとして動きます。現在のローカル版では、子の起動、追加指示の転送、完了待ち、停止、スレッドの終了をCodexが調整します。

子が動き始めたら、CLIで/agentと入力すると、実行中と完了済みのエージェントスレッドを確認し、表示する担当へ切り替えられます。開いた子スレッドでは、その担当へ渡された仕事、使ったファイルや道具、現在の進行、返却結果を確認できます。

追加の確認が必要ならメインスレッドへ戻り、『試験担当に失敗した二件だけ再現させて』『資料担当に公式文書だけを確認させて』と頼みます。不要になった担当も、『資料担当を停止して』のように親へ伝えます。/agentはスレッドを一覧して切り替える入口であり、子の管理操作そのものはCodexへ自然文で依頼できます。

見えるのは担当、状態、作業記録、結果です。モデル内部の非表示な推論を逐語的に読む機能ではありません。監督では、何を任せたか、何へアクセスしたか、根拠を返したか、どこで止まったかを確認します。

サブエージェントは、親の実行時に選んだサンドボックスと承認設定を引き継ぎます。サンドボックスは、Codexが読める場所、書ける場所、ネットワーク利用などを制限する実行境界です。子だから勝手に権限が広がるわけではありません。

実行中は、いま表示していない子スレッドから承認要求が出ることがあります。CLIの承認画面には要求元のスレッド名が表示され、oキーでその担当を開いて理由を確認してから、許可、拒否、回答を選べます。非対話の実行で新しい承認を表示できない場合、許可が必要な操作は失敗し、その情報が親へ返ります。

複数の子へ書き込みを許す場合も対象を分け、たとえば一体は試験だけ、別の一体は文書だけに限定し、同じファイルへ触れさせません。外部送信、削除、権限変更のような影響の大きい操作は、親の段階で人の承認を求める条件を明示します。

毎回の依頼文で役割を説明しなくても、Codexには汎用のdefault、実装向けのworker、読み取り中心のexplorerという組み込み担当があります。さらに、個人用はホームディレクトリ配下の.codex/agents、プロジェクト用はプロジェクト内の.codex/agentsへ、一担当につき一つのTOMLファイルを置くと独自の担当を定義できます。

各ファイルには、担当名を示すname、使いどころを示すdescription、守る手順を示すdeveloper_instructionsが必要です。必要ならmodel、model_reasoning_effort、sandbox_modeも指定できます。たとえばdocs_researcherをTerra・中程度の推論・読み取り専用に固定し、公式資料だけを確認してURLと留保を返すように書けます。

同時に開く子の上限や既定モデルの管理場所は、config.tomlのagents設定です。人数を増やすほど速くなるとは限らないため、最初は二、三体で始め、担当範囲が重ならないことと返却形式が短いことを先に確かめます。

サブエージェントは、総トークンを自動的に減らす機能ではありません。子はそれぞれ指示を読み、推論し、道具を呼び、結果を出すため、トークン消費は同等の単体実行より増えると公式資料も説明しています。

効果が出るのは、日本語と英語、実装と試験、技術と規制のように、途中結果を待たず独立して進められる仕事です。三担当を並列に動かせば経過時間を短くでき、メインスレッドへ大量の途中経過を入れずに済みます。

トークンを抑えるには、軽いモデルで候補を絞り、強いモデルが読む資料と考える範囲を減らすのが基本です。並列化で直接節約しやすいのは時間と親の文脈であり、総トークンは担当範囲、返却量、停止条件を制限して初めて抑えられます。

Skillは、繰り返す仕事の進め方をSKILL.mdへまとめた手順書です。起動条件、入力、手順、使う道具、出力形式、停止条件、品質基準を一つの束にし、Codexは必要なときに詳しい内容を読みます。

Skillを呼んだだけで、必ず子が生まれるわけではありません。Skillに並列委任が書かれているか、利用者がその場でサブエージェント利用を明示したときに、親が仕事を委任します。Skillは仕事の型、サブエージェントはその一部を別の文脈で実行する担当です。

最初からSkillを書く必要はありません。通常の会話で一度仕事を進め、必要な入力、繰り返した手順、品質確認の箇所を観察した後に、『いまの流れを再利用できるSkillへ変換してください』と頼む方が実際の作業に合います。

モデル名を先に決めるより、品質を落とせない箇所、使える時間、欲しい出力、調査範囲を渡し、仕事の構造をCodexに分析させる方が失敗しにくくなります。

依頼例は『品質を落とさず利用枠を節約する形へ分解し、親に残す判断、LunaまたはTerraへ委任する作業、サブエージェント不要の作業、停止条件、返却形式、Skill化候補を示してください。まだ実行せず構成だけ示してください』です。

構成案を確認してから実行させれば、不要な並列化、同じ資料の重複読解、結論の出ない探索を事前に止められます。

2026年8月時点のCodexでは、GPT-5.6 Solが複雑で曖昧な仕事、Terraが日常的な調査と道具利用、Lunaが明確で反復的な大量処理に位置付けられています。推論の強さもモデルとは別に選べ、高くするほど難しい判断へ対応しやすくなる一方、時間とトークンが増えます。

記事調査では、問い、採用基準、矛盾の整理、最終原稿がSolの担当です。Lunaに向くのはURL候補、発行日、資料種別の抽出で、Terraは候補に残った一次資料の数値、対象期間、調査方法、因果関係、留保の検証に向きます。

モデルを明示しなければ、速度、価格、判断力の均衡はCodexが仕事に合わせて取る設計です。固定したい場合は、依頼文または独自エージェントのTOMLファイルでmodelとmodel_reasoning_effortを指定します。

効率のよい記事調査は、探索、選別、検証、統合を一度に行いません。最初にLunaを二体起動し、日本語の政府・研究機関と、英語の国際機関・論文へ担当を分けます。各担当は最大12資料で止まり、長い要約ではなく資料台帳だけを返します。

親のSolの仕事は、候補から重複、二次記事、対象期間外、主張に使えない資料を落とし、最大15件へ絞ることです。その15件だけをTerraへ渡し、原資料を開いて数値と限界を確認させます。検証前の候補をすべてTerraやSolに読ませないことには、モデル単価以上の効果があります。

最後にSolが証拠台帳を受け取り、確認済みの事実、組織や企業の主張、筆者の見立てを分けて記事へ統合します。各エージェントに記事全文を書かせず、文章を書く担当は最後の一体へ集めます。

子へ親チャットの全履歴を渡すと、過去の雑談、失敗した仮説、既知の資料まで再読させることになります。親はテーマ、担当、期間、優先する情報源、最大件数、返却項目、禁止事項だけを短い依頼へ圧縮します。

探索役に返させるのは最大12件、項目は発行日、発行主体、資料名、URL、使える主張、優先度だけです。検証役には、渡した候補だけを確認し、新しい探索へ広げず、各資料の出力を短くするよう指定します。

OpenAIのGPT-5.6ガイドでは、重複指示と不要な道具説明を減らした内部評価で、総トークンが41〜66％、費用が33〜67％減った例が示されています。個別の仕事で同じ削減率は保証されませんが、目的、制約、根拠、完了条件、出力形式を一度ずつ書く設計が有効です。

資料が三件しかなく、順番に読めば終わる調査なら、単一のTerraかSolへ任せた方が少ないトークンで済みます。前の結果を見ないと次の検索語を決められない仕事も、無理に並列化すると重複が増えます。

複数担当が同じ資料を読む場合、仕事を分けた意味がありません。並列化が向くのは、日本語と英語、実装と試験、技術と規制のように、互いの途中結果を待たず独立して進められる範囲です。

長い調査では証拠台帳をファイルへ残し、次の段階ではその台帳だけを読みます。APIから独自に実行する場合はプロンプトキャッシュと会話の圧縮も使えますが、不要な探索や重複した出力そのものを消す仕組みではありません。

ここからは筆者の見立てです。トークン効率のよい複数エージェント構成では、最も強いモデルが最も多く作業する必要はありません。強いモデルへ残すべきなのは、何を調べるか、どの証拠を採るか、矛盾をどう扱うか、どこで止めるかという判断です。

子エージェントの価値は、親の代わりに長文を書くことではなく、狭い範囲を独立した文脈で処理し、判断可能な形へ圧縮して返すことにあります。親は担当の状態と結果を見ながら、不要な探索を止め、足りない検証だけを追加し、最後に一度だけ成果物を作ります。

Codexを効率よく使う設計は、SolをLunaへ置き換えるだけでは完成しません。親に判断を集中させ、探索と検証を段階化し、子の人数、資料数、出力長、停止条件を制限することで、速度、品質、トークンの三つを管理できます。