Codexのサブエージェントとは|使い方・TOML設定・活用例を解説

Codexのサブエージェントとは|使い方・TOML設定・活用例を解説
目次

Codex でコーディングを任せていると、調査から実装、レビューまでを一つのエージェントに詰め込むうちに、やり取りが長くなって精度や速度が落ちてくる場面に出会います。サブエージェント機能はこの課題に答える仕組みですが、設定方法や使いどころがわからず、手を出しあぐねている方も多いのではないでしょうか。

本記事では、Codexのサブエージェントの基本的な仕組みから、CLIでの呼び出し方、TOMLによるカスタムエージェントの定義、レビューや探索を分業させる具体的な使い方までを、これから試す方に向けて順を追って整理します。

朝山 高至
AIエキスパート

GiftXにてマーケティング・PdM・AI推進を担当。自社事業GIFTFULにて、AIエージェントを活用したマーケティング・営業業務の自動化を主導。

Codexのサブエージェントとは|並列で動く補助エージェントの仕組み

Codexのサブエージェントが、親エージェントからタスクを委任され、独立した文脈で並列に動く仕組みを概念図で示す。親エージェント(司令塔)と複数のサブエージェントの役割分担、そしてコンテキスト分離(親の文脈が汚れない)が一目で伝わる図にする。

Codexのサブエージェントとは、親エージェントから特定のタスクを任され、独立した文脈で並列に作業する補助的なエージェントのことです。OpenAI のコーディング支援ツール「Codex」に正式導入された機能で、1 つの大きな作業を複数の小さなタスクに分解し、それぞれを別のエージェントに割り振って同時に進められます。

従来の Codex は、調査も実装もレビューもすべて 1 つのエージェントが順番にこなしていました。サブエージェントを使うと、この流れを「司令塔となる親エージェント」と「実作業を担うサブエージェント」に分けられます。司令塔がタスクを切り出して指示を出し、各サブエージェントが結果を返すと、親がそれをまとめて次の判断につなげる、という分業が成り立ちます。

タスク委任とコンテキスト分離の仕組み

サブエージェントの価値は、タスクの委任と「コンテキスト分離」にあります。コンテキストとは、エージェントが参照している会話履歴やコードの情報のことです。1 つのエージェントに作業を積み重ねると、この履歴がどんどん膨らみ、本来の指示が埋もれて回答の精度が落ちていきます。これは「コンテキスト汚染」「コンテキストの肥大化」と呼ばれる、AIエージェント共通の課題です。

サブエージェントは、委任されたタスクを自分専用のきれいな文脈で処理します。調査担当のサブエージェントが大量のファイルを読み込んでも、その履歴は親エージェントには流れ込みません。親は調査結果の要約だけを受け取れるため、司令塔としての文脈を軽く保てます。結果として、長く複雑な作業でも精度を維持しやすくなります。

なぜ使い方を押さえると開発が変わるのか

サブエージェントを使いこなすと、「待ち時間の短縮」と「文脈の節約」という 2 つの効果が得られます。複数の調査や実装を並列で走らせれば、直列でこなすより全体の所要時間を縮められます。さらに各タスクが独立した文脈で動くため、親エージェントは細部に埋もれず、全体の段取りに集中できます。

一方で、何でもサブエージェントに任せれば速くなるわけではありません。タスクの切り出し方や設定を誤ると、かえって手間やコストが増えることもあります。だからこそ、基本的な使い方と向き不向きを押さえることが、機能を活かす出発点になります。

Codexサブエージェントの基本的な使い方(呼び出しと並列実行)

Codexサブエージェントの基本的な使い方は、「どのサブエージェントに」「どんなタスクを」任せるかを親エージェントに伝えることから始まります。あらかじめ用意された組み込みのエージェントを呼び出す方法と、自分で定義したカスタムエージェントを使う方法の 2 通りがあり、まずは組み込みのものから試すのが入り口になります。

関連記事:Codexの使い方を初心者向けに解説|4つの始め方・料金・プロンプトのコツ

ビルトインエージェント(default・worker・explorer)の役割

Codex には、設定なしで使える組み込みのサブエージェント(ビルトインエージェント)が用意されています。代表的なものが defaultworkerexplorer の 3 種類です。それぞれ想定する役割が異なり、任せたいタスクの性質で使い分けます。下の表に、3 つの基本的な役割の違いを整理しました。

エージェント主な役割向いているタスク
default汎用的な作業全般指示を選ばず幅広く対応させたいとき
worker指示された実作業の遂行実装や修正など、手を動かす作業
explorerコードベースの調査・把握既存コードの仕様や影響範囲の調べもの

役割を厳密に覚える必要はありません。まずは「調べものは explorer、作業は worker」という大まかな振り分けから始め、慣れてきたら自分の作業に合わせて細かく使い分けていくと無理がありません。

CLIから呼び出す基本フロー

サブエージェントは、Codex の CLI(コマンドライン上で操作するツール)から利用します。基本の流れは、親エージェントに対して「このタスクを explorer に調べさせて」「実装を worker に任せて」と自然な言葉で依頼するだけです。親が依頼を受け取ると、適切なサブエージェントにタスクを切り出し、結果が返ってきたらまとめて報告します。

最初は、1 つのタスクを 1 つのサブエージェントに任せる単純な使い方から始めると、挙動を把握しやすくなります。たとえば「この機能の影響範囲を調べて」と explorer に依頼し、返ってきた調査結果を見てから次の実装に進む、といった具合です。サブエージェントが何を受け取り、何を返すのかを目で確認しながら進めると、設定や指示の勘所がつかめてきます。

関連記事:Codex CLI とは?できること・料金・Claude Code との違いを整理

複数のサブエージェントを並列実行する

サブエージェントの真価は、複数を並列で動かしたときに現れます。たとえば、大きな機能追加で「フロント側の調査」「バックエンド側の調査」「既存テストの確認」を同時に走らせれば、1 つずつ順番に進めるより全体の待ち時間を縮められます。親エージェントは各サブエージェントの結果が出そろうのを待ち、それらを統合して次の段取りを決めます。

ただし、並列で動かすサブエージェントの数を増やすほど、消費するトークン(AIが処理する文章の最小単位で、利用量の目安になる)も増えます。最初から多くを同時に走らせるのではなく、2〜3 個の並列から試し、効果と負荷のバランスを見ながら数を調整していくのが現実的な進め方です。

TOMLでカスタムサブエージェントを定義する方法

組み込みのエージェントに慣れたら、TOMLでカスタムサブエージェントを定義してみましょう。TOML(Tom’s Obvious Minimal Language、設定を人間が読み書きしやすい形式で記述するためのファイル形式)を使うと、自分の開発スタイルに合わせた専用のサブエージェントを作れます。「レビュー専任」「テスト作成専任」のように役割を固定したエージェントを用意しておくと、毎回同じ指示を書かずに済みます。

設定ファイルの置き場所

カスタムエージェントの設定は、TOML 形式のファイルに記述します。設定には、全体の動作にかかわる共通設定ファイル(config.toml)と、エージェントごとに分けて置く個別の設定ファイル(プロジェクト内の .codex/agents/ 配下などに置く .toml ファイル)があります。共通設定にまとめる方法と、エージェント単位でファイルを分ける方法のどちらも取れます。

プロジェクト固有のエージェントは、そのプロジェクトのディレクトリ内に置いておくと、チームで設定を共有しやすくなります。まずは 1 つのファイルに 1 つのエージェントを定義する形から始めると、設定の見通しが良く、動かなかったときの切り分けも簡単です。

定義で指定する基本項目

カスタムエージェントの定義では、主に次の項目を指定します。どれも「このエージェントに何をどう任せるか」を決めるための設定です。

  • 名前:エージェントを呼び出すときの識別名
  • 説明:どんな役割のエージェントかを示す概要
  • 指示:エージェントに守らせたい方針や作業手順
  • モデル:そのエージェントが使う AI モデルの指定

このうち特に効くのが「指示」の部分です。たとえばレビュー専任のエージェントなら、「セキュリティ観点の指摘を優先する」「指摘は重要度順に並べる」といった方針を書いておくと、毎回同じ品質でレビューが返ってきます。役割を絞り込むほど、指示も具体的に書きやすくなります。

定義の例とモデルの使い分け

たとえばコードレビュー専任のサブエージェントを定義する場合、名前を reviewer、説明を「変更内容をレビューする担当」、指示に「バグとセキュリティ上の懸念を優先して指摘する」と書く、といった構成になります。タスクが軽い調査中心のエージェントには軽量なモデルを、込み入った実装やレビューには上位のモデルを割り当てると、精度とコストのバランスを取りやすくなります。

すべてのエージェントに最上位モデルを割り当てる必要はありません。「探索は軽量モデル、レビューは上位モデル」のように役割ごとにモデルを選び分けることで、品質を保ちつつ無駄なコストを抑えられます。最初は 1〜2 個のカスタムエージェントから作り、実際の作業で役立った設定を少しずつ増やしていくのがおすすめです。

サブエージェントの活用シーン|レビュー・実装・探索の分業

サブエージェントを開発ワークフローに当てはめる3つの分業パターン(コードレビュー/実装とレビューの分業/コード探索)を、親エージェントとサブエージェントの流れが分かるプロセス図で示す。それぞれ別の文脈で並列に進み、精度と速度を両立させることを伝える。

サブエージェントの使い方は、実際の開発ワークフローに当てはめると具体的に見えてきます。ここでは、多くの開発現場で当てはまりやすい「レビュー」「実装」「探索」の 3 つの分業パターンを取り上げます。いずれも、1 人のエージェントに全部任せていた作業を切り分けることで、精度と速度の両方を底上げする使い方です。

コードレビューを専任エージェントに任せる

実装したコードのレビューを、専任のサブエージェントに任せるパターンです。実装を担当したエージェントとは別の文脈でレビューさせることで、「書いた本人が見落とす視点」を補えます。レビュー専任エージェントに「バグとセキュリティ観点を優先」と指示しておけば、変更のたびに同じ基準でチェックが入る体制を作れます。

人間のレビュー前に AI による一次チェックを挟む形にすると、明らかな抜け漏れを早い段階でつぶせます。最終判断は人が下すとしても、指摘の叩き台があるかないかで、レビューにかかる負担は変わってきます。

実装とレビューを分業する

実装担当と確認担当を分けると、一連の流れをそのまま自動化に近づけられます。司令塔の親エージェントが worker に実装を任せ、その結果をレビュー専任エージェントに渡して指摘を受け、必要なら修正を戻す、という分業の形です。それぞれが独立した文脈で動くため、実装の細部に引きずられずにレビューできます。

たとえば、AIコーディングエージェントを開発フローに組み込んだあるチームのケースでは、機能追加 1 件あたり平均 2 日かかっていた工程が半日程度まで縮み、工数を 7 割ほど削減できたという例もあります。仕様の読み込みから実装、テスト作成までを AI と分担し、人はレビューと微調整に集中する形に切り替えた結果です。サブエージェントによる分業は、こうした「人と AI の役割分担」をさらに細かく設計できる手段だと言えます。

コード探索で前提調査を高速化する

実装の前に必要な「既存コードの調査」を、explorer に任せるパターンです。新しい機能を足すときは、まず関連する既存コードの仕様や影響範囲を把握する必要があります。この前提調査を探索担当のサブエージェントに任せると、親エージェントはきれいな文脈のまま、調査結果の要約だけを受け取れます。

大量のファイルを読み込む調査は、文脈を最も圧迫しやすい作業です。これを別のサブエージェントに切り出すことで、親の文脈を守りながら、必要な情報だけを手元に集められます。調査と実装を分けるだけでも、サブエージェントの効果を実感しやすい使い方です。

うまく動かないときの対処とコストの抑え方

サブエージェントを使い始めると、「思ったように動かない」「コストが想定より増えた」といった場面にも出会います。マルチエージェントの構成は便利な反面、どこで何が起きているかが見えにくくなりがちです。つまずきやすいポイントと、その対処の考え方を押さえておきましょう。

デバッグ・トラブルシューティングの考え方

サブエージェントが期待どおりに動かないときは、まず「どのエージェントの段階で問題が起きたか」を切り分けます。親の指示の出し方が悪いのか、サブエージェント側の設定や指示が曖昧なのかで、対処は変わります。各サブエージェントが何を受け取り、何を返したかを 1 つずつ確認すると、原因の所在が見えてきます。

複数を並列で動かしているときほど、問題の切り分けは難しくなります。動きが怪しいと感じたら、いったん並列数を減らし、1 つのサブエージェントだけで動かして挙動を確かめるのが近道です。設定はシンプルな状態から少しずつ足していくほうが、不具合の原因を特定しやすくなります。

トークン消費とコストを抑えるコツ

サブエージェントを並列で多く動かすほど、トークンの消費量は増え、利用コストもふくらみます。コストを抑える基本は、「タスクに見合ったモデルを選ぶ」ことと「並列数を欲張らない」ことの 2 点です。軽い調査に上位モデルを使ったり、必要以上の数を同時に走らせたりすると、効果に見合わない消費につながります。

役割ごとにモデルを割り当て、まずは少ない並列数から始めて効果を見ながら増やす、という進め方が無駄を防ぎます。サブエージェントは「速くするための機能」であると同時に「コストがかかる機能」でもあると意識しておくと、使いどころを冷静に判断できます。

すぐ使えるサブエージェント設定チェックリスト

サブエージェントを使い始めるときに、最低限おさえておきたい項目をチェックリストにまとめました。設定でつまずく原因の多くは、役割やモデルの決め方が曖昧なまま走り出してしまう点にあります。試す前に一度、次の項目を確認しておくと立ち上がりがスムーズになります。

  • 任せたいタスクを、まず 1 つに絞り込んだか
  • そのタスクに合うのは default・worker・explorer のどれかを決めたか
  • カスタム定義する場合、名前・説明・指示・モデルの 4 項目を埋めたか
  • 指示には、守らせたい方針を具体的に書いたか
  • タスクの重さに対して、過剰なモデルを割り当てていないか
  • 最初は 2〜3 個の少ない並列数から試す設定にしたか
  • うまく動かないときに切り分けられるよう、設定をシンプルに保ったか

すべてを一度に完璧にする必要はありません。まずは 1 タスク 1 エージェントの最小構成で動かし、このリストを見返しながら少しずつ設定を広げていくと、無理なく自分の開発フローに馴染ませられます。

サブエージェントの向き不向きとClaude Codeとの使い分け

サブエージェントは強力な機能ですが、すべての作業に向いているわけではありません。向き不向きを理解しておくと、「ここはサブエージェントに任せる」「ここは単一のエージェントで十分」という判断ができるようになります。あわせて、似た機能を持つ Claude Code との使い分けも押さえておきましょう。

サブエージェントを使わない方がよいケース

サブエージェントが効くのは、調査・実装・レビューのように「切り分けられて、並列で進められる」タスクです。逆に、短く完結する小さな修正や、前後の文脈が密接につながっていて分割しにくい作業では、分業の手間のほうが上回ることがあります。タスクを無理に分けると、親とサブエージェント間のやり取りが増え、かえって遅くなったりコストがかさんだりします。

判断の目安は、「そのタスクは独立して切り出せるか」「並列にする価値があるほど重いか」の 2 点です。どちらも当てはまらない軽い作業なら、単一のエージェントで素直に進めたほうが速く済みます。サブエージェントは万能の高速化装置ではなく、適したタスクに当てて初めて効果が出る機能だと捉えておくと、過剰な分割を避けられます。

Claude Codeのサブエージェントとの違い

サブエージェントによるマルチエージェントの分業は、Anthropic のコーディング支援ツール「Claude Code」にも同様の機能があります。どちらも「親エージェントがサブエージェントにタスクを委任し、文脈を分離して並列で進める」という発想は共通しています。普段使っているツールに同等の機能があるなら、まずはそちらで分業の感覚をつかむのも一つの入り口です。

使い分けの基本は、すでに使い慣れているツールや、対象のプロジェクトで標準にしている環境に合わせることです。どちらか一方が絶対的に優れているというより、自分の開発環境とワークフローに馴染むほうを選ぶのが現実的です。機能の細部は更新が速いため、実際に使うときは最新の公式ドキュメントで仕様を確認しておくと安心です。

関連記事:Claude Code と Codex の違い|5 つの観点で整理し用途別に選び分ける

AIエージェントを使い始めるときに陥りがちな3つの落とし穴

サブエージェントに限らず、AIエージェントを業務に取り入れようとすると、つまずきやすいパターンがあります。ここでは、これから本格的に使い始める方が陥りがちな 3 つの落とし穴を整理します。便利な機能を前にしたときほど、足元を固めておくと回り道を避けられます。

落とし穴1:いきなり全てをやろうとする

最初から複数のサブエージェントを組み合わせ、複雑な分業フローを一気に組もうとすると、どこで何が起きているかを把握できなくなります。全体を一度に自動化しようとするほど、不具合の切り分けも難しくなります。

落とし穴2:壮大な活用構想から考えて手が止まる

「開発全体を AI に任せる体制を作る」といった大きな構想から入ると、設計に時間がかかり、最初の一歩が踏み出せなくなりがちです。理想像を描くより先に、目の前の 1 タスクを動かしてみるほうが学びは早く積み上がります。

落とし穴3:既製のツールのまま業務に組み込もうとする

既製のチャット型 AI をそのまま使うだけでは、自社の業務フローに合った精度や手順までは届きにくいものです。役割を絞った指示や設定を施さないと、実務で使えるレベルに調整しきれず、形だけの導入で止まってしまいます。

スモールスタートで1業務をAIエージェントに任せる

これらの落とし穴を避ける近道は、スモールスタートです。まずは「コードレビューだけ」「前提調査だけ」のように 1 つの業務に絞ってサブエージェントを試し、効果を確かめてから対象を広げていきます。小さく始めて成功体験を積むほうが、壮大な構想から入るより着実に前に進めます。

自社業務でAIエージェント活用を進めたい方へ

ここまで紹介した「スモールスタートで 1 業務から自動化する」という進め方を、自社の業務でも実践したいとお考えの方もいらっしゃるかもしれません。

GiftXでは、業務に合わせた AIエージェントの構築支援サービス「GiftX AIエージェント構築支援」を提供しています。1 業務単位のスモールスタートから、業務フローに組み込めるレベルの AIエージェント構築までを伴走します。

詳細はGiftX AIエージェント構築支援のサービスサイトでご覧いただけます。

まとめ|Codexサブエージェントの使い方は小さく試すのが近道

Codexのサブエージェントは、親エージェントがタスクを委任し、文脈を分離して並列で進めることで、長く複雑な作業でも精度と速度を保ちやすくする機能です。組み込みの default・worker・explorer から始め、慣れてきたら TOML でレビューや探索の専任エージェントを定義していくと、自分の開発フローに馴染ませられます。

大切なのは、最初から壮大な分業フローを組もうとせず、1 タスク 1 エージェントの最小構成から試すことです。レビューや前提調査など、切り出しやすい 1 業務をスモールスタートで任せ、効果を確かめながら対象を広げていく。この進め方は、Codexのサブエージェントに限らず、AIエージェントを業務に取り入れるとき全般に通じる考え方です。

AI活用の伴走支援をご検討の方へ

本記事で紹介した AIエージェントの活用を、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。

GiftX AIエージェント構築支援では、貴社の業務に合わせて 1 業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。

AI活用にご関心のある方は、ぜひ一度ご相談ください。

GiftX AIエージェント構築支援の詳細・お問い合わせはこちら

関連記事

SHARE
eBook
マーケティング・営業のAIエージェント構築事例を無料配布

マーケティング・営業におけるAIエージェント構築の事例・支援メニュー・料金体系をまとめた資料を、即時ダウンロードできます。

資料請求フォームへ →