MENU
3DCG・ゲーム開発の知見をゆるく深く
  1. ホーム
  2. AIエージェント解説
  3. Codex
  4. Codex Subagents入門｜複数エージェントで並列作業する方法

Codex Subagents入門｜複数エージェントで並列作業する方法

Codex
Codex Subagents入門｜複数エージェントで並列作業する方法

Codexを実務で使っていると、1つの作業の中に複数の観点が混ざる場面があります。たとえば、大きなコードベースを調査しながら、テスト不足を探し、実装方針を考え、レビュー観点も整理したい場合です。

このようなときに役立つのが Subagents です。Subagentsを使うと、Codexが複数のエージェントを並列に動かし、それぞれに調査、レビュー、テスト確認などの役割を分担させられます。本記事では、Subagentsの役割、向いている作業、依頼の切り方、衝突回避、結果統合、やりすぎ注意を初心者向けに解説します。

夕宮たいだ

ふぁ……みんな〜、今日はSubagentsだよぉ。複数のCodexに役割分担してもらう話だけど、まずは安全な切り方から見ていこ〜。

目次

1. Subagentsとは何か

ひとことで：Subagentsは、Codexが複数のエージェントを並列に動かす仕組みです。

Codexのメインエージェントが複数のSubagentsに調査、レビュー、テスト確認を分担する図
図1：Subagentsは複数の観点を並列に調査して結果を統合する

Subagentsは、1つのCodexセッションの中で、別のエージェントに作業を分担させるための仕組みです。メインのCodexが全体の目的や判断を持ち、subagentが個別の調査や作業を担当します。

OpenAI公式のSubagentsページでは、Codexは専門化したエージェントを並列に起動し、結果を1つの回答に集約できると説明されています。複雑なタスク、特にコードベース調査や複数段階の機能計画のように並列化しやすい作業で役立ちます。

イメージは次のとおりです。

メインCodex
  ├─ 調査agent
  ├─ レビューagent
  └─ テスト確認agent
        ↓
  結果を統合して人間が判断

ただし、Subagentsは自動で勝手に使われるものではありません。公式Docsでも、Codexは明示的に依頼されたときにSubagentsを使うと説明されています。また、各subagentは独自にモデルやツールを使うため、単一エージェントで進めるよりトークン消費が増えます。

夕宮たいだ

Subagentsは、作業を勝手に増やす機能じゃないよぉ。「ここは分担して」って人間が頼むときに使うんだぁ。

2. なぜSubagentsが役立つのか

ひとことで：メインの会話を散らかさず、重い調査を横で進められます。

複雑な作業では、ログ、検索結果、ファイル調査、試行錯誤のメモが大量に出ます。それらをすべてメインの会話に流すと、重要な要件や判断が埋もれやすくなります。

公式のSubagent conceptsページでは、こうした問題を context pollution や context rot として説明しています。つまり、メインの文脈にノイズが増えすぎると、会話全体の信頼性が落ちやすくなるという考え方です。

Subagentsを使うと、次のようなメリットがあります。

  • 調査ログをメイン会話から分離できる
  • 複数の観点を同時に確認できる
  • 読み取り中心の調査を並列に進められる
  • メインCodexは要件、判断、統合に集中できる
  • subagentからは要約だけを受け取れる

ただし、すべての作業を並列化すればよいわけではありません。むしろ、分担の切り方が悪いと、重複調査、矛盾した結論、編集衝突が増えます。

3. Subagentsが向いている作業

ひとことで：読み取り中心で、独立して進められる作業に向いています。

Codex Subagentsが向いている読み取り中心作業と慎重に扱う書き込み作業の比較図
図2：初心者は読み取り中心の並列作業から始める

初心者が最初に使うなら、Subagentsは読み取り中心の作業から始めるのがおすすめです。公式のSubagent conceptsページでも、探索、テスト、トリアージ、要約のようなread-heavyタスクから始める考え方が示されています。

向いている作業です。

作業分担例
コードベース調査agent AはUI、agent BはAPI、agent Cはテストを見る
レビューsecurity、test gaps、maintainability に分ける
エラー調査ログ、最近の差分、関連Issueを別々に調べる
ドキュメント要約長い仕様書を章ごとに分担する
移行調査影響範囲、依存関係、テスト方針を分ける

反対に、次の作業は慎重に扱います。

  • 同じファイルを複数agentが同時に編集する作業
  • 要件がまだ曖昧な作業
  • 強い設計判断が必要な作業
  • 本番環境や秘密情報に関わる作業
  • すぐ人間の判断が必要な作業

最初は「調査だけ」「レビューだけ」「要約だけ」のように、ファイル変更を伴わない分担から試します。

夕宮たいだ

最初は「読むだけ」の分担が安心だねぇ。調査やレビューなら、並列にしても衝突しにくいよぉ。

4. 依頼の切り方

ひとことで：役割、範囲、出力形式、待ち方を指定します。

Subagentsを使うときは、ただ「並列でやって」と書くだけでは不十分です。どの観点を誰に任せるのか、どの範囲を見るのか、どんな形式で返してほしいのかを指定します。

基本テンプレートです。

Goal:
（全体として達成したいこと）

Subagents:
1. 調査agent: 見る範囲と観点
2. レビューagent: 見る範囲と観点
3. テストagent: 見る範囲と観点

Constraints:
ファイル変更の可否、触ってよい範囲、禁止事項

Done when:
各agentの要約を統合し、結論、根拠、未確認事項をまとめる

公式Docsでも、よいSubagentプロンプトには、作業の分割方法、すべてのagentを待つかどうか、返してほしい要約や出力を含める考え方が示されています。

5. 調査を分担する例

ひとことで：コードベース調査はSubagentsの最初の練習に向いています。

調査は読み取り中心なので、Subagentsと相性がよい作業です。大きな機能の全体像を知りたいとき、複数のディレクトリを別々に見たいときに使えます。

依頼文例です。

Goal:
ユーザー設定機能の処理の流れを理解したいです。

Subagents:
1. UI調査agent:
   `src/pages/settings` と `src/components/settings` を読み、画面構成と主要コンポーネントを整理してください。
2. API調査agent:
   `src/api/settings` と関連する型定義を読み、保存・取得処理を整理してください。
3. テスト調査agent:
   設定機能に関係するテストを探し、カバーされている範囲と不足している範囲を整理してください。

Constraints:
ファイルは変更しないでください。
推測とコード上の根拠を分けてください。

Done when:
3つの結果を統合し、処理の流れ、主要ファイル、注意点、未確認事項をまとめてください。

確認ポイントは、各agentの調査範囲が重なりすぎていないかです。重なりが多いと、並列化しても効率が上がりにくくなります。

6. レビューを分担する例

ひとことで：レビューは観点ごとに分けると使いやすくなります。

レビューでは、複数の観点を同時に見たいことがあります。セキュリティ、テスト不足、保守性、仕様漏れを1人のagentに全部見せるより、観点ごとに分けると整理しやすくなります。

依頼文例です。

Goal:
現在の差分をSubagentsでレビューしてください。

Subagents:
1. Security reviewer:
   認可、入力検証、秘密情報、外部通信のリスクを見てください。
2. Test reviewer:
   追加・変更された挙動に対してテスト不足がないか見てください。
3. Maintainability reviewer:
   変更範囲、命名、既存パターンとの一貫性を見てください。

Constraints:
コードは変更しないでください。
好みの指摘より、バグリスクと確認漏れを優先してください。

Done when:
重要度順に findings を統合し、重複指摘はまとめてください。
ファイルや関数名など、根拠を示してください。

レビューで大切なのは、最後に統合することです。Subagentsの指摘をそのまま全部採用すると、重複や優先度のズレが残ります。メインCodexに統合させ、人間が最終判断します。

夕宮たいだ

ほえ〜、レビューは観点ごとに分けると見やすいねぇ。でも最後にまとめる人が必要なんだぁ。

7. 実装を分担するときの注意

ひとことで：同じファイルを触らせないよう、担当範囲を分けます。

実装作業もSubagentsで分担できますが、読み取り中心の調査より難しくなります。複数agentが同じファイルを編集すると、変更が衝突したり、方針がずれたりするためです。

実装を分担するときは、次の条件を満たす場合だけにします。

  • 担当ファイルや担当モジュールが明確に分かれている
  • 共通APIや型定義の変更が少ない
  • 先に実装方針が決まっている
  • 各agentの完了条件が明確である
  • 最後に統合レビューを行う

依頼文例です。

Goal:
設定画面の小さな改善を、ファイル範囲を分けて進めてください。

Subagents:
1. UI agent:
   `src/pages/Settings.tsx` の表示文言と空状態だけを調整してください。
2. Test agent:
   `src/pages/Settings.test.tsx` に、空状態と保存成功時のテストを追加してください。

Constraints:
同じファイルを複数agentで編集しないでください。
API、型定義、依存パッケージは変更しないでください。
各agentは変更ファイルと実行コマンドを報告してください。

Done when:
メインCodexが差分を統合し、テスト結果と残リスクをまとめてください。

実装の並列化は、速くなることもありますが、調整コストも増えます。初めて使う場合は、小さく、担当範囲を分けやすい作業に限定します。

8. 待ち方と結果統合

ひとことで：どのagentを待つか、結果をどうまとめるかを先に決めます。

Codex Subagentsの結果を重複整理、優先度付け、未確認事項に分けて統合するフロー
図3：Subagentsの価値は結果を統合して判断しやすくすること

Subagentsを使うと、複数の結果が返ってきます。そのため、最後にどう統合するかが重要です。

依頼時に指定したいことです。

  • 全agentの完了を待つか
  • 先に終わったagentの結果だけで進めてよいか
  • 結果をカテゴリ別にまとめるか
  • 重複指摘を統合するか
  • 未確認事項を別枠にするか
  • 採用する変更と見送る変更を分けるか

結果統合の出力形式例です。

最終出力は次の形式にしてください。

## 結論
## 各subagentの要約
## 統合したfindings
## 追加で確認すべきこと
## 採用する変更 / 見送る変更

Subagentsの価値は、たくさんの途中ログを見ることではありません。必要な調査を裏で進め、メインの会話には判断しやすい要約を持ち帰ることです。

9. AGENTS.md・MCP・Skillsとの関係

ひとことで：Subagentsは分担、AGENTS.mdはルール、MCPは接続、Skillsは手順です。

第2期で扱った仕組みを整理すると、次のようになります。

仕組み役割
AGENTS.mdプロジェクトの作業ルールを伝える
MCP外部ツールやデータへ接続する
Skills繰り返す作業手順を再利用する
Subagents複数のagentで作業を分担する

たとえば、レビュー作業では次のように組み合わせられます。

  • AGENTS.md：レビューではバグ、テスト不足、安全リスクを優先する
  • MCP：GitHubやSentryの情報を参照する
  • Skill：コードレビューの出力形式を定義する
  • Subagents：security、test gaps、maintainabilityを並列で見る

それぞれの役割を混ぜないことが大切です。Subagentsは分担の仕組みであり、プロジェクトルールそのものではありません。外部ツール接続でもなく、作業手順の保存場所でもありません。

夕宮たいだ

ここまで来ると、Codexの道具箱がだいぶ揃ってきたねぇ。ルール、接続、手順、分担。役割を分けるのがコツだよぉ。

10. やりすぎ注意のポイント

ひとことで：Subagentsは、分担コストとトークン消費も増えます。

Subagentsは便利ですが、使うほどよいわけではありません。公式Docsでも、subagent workflowは各subagentが独自にモデルやツールを使うため、単一agentよりトークンを消費すると説明されています。

やりすぎの例です。

  • 小さな修正に3つ以上のagentを使う
  • 役割が重なっている
  • 同じファイルを複数agentに編集させる
  • 結果統合の指示がない
  • subagentの指摘を人間が確認せず採用する
  • 失敗時の戻し方を決めていない

初心者は、まず2〜3agentまでに留めるのがおすすめです。最初から大きな並列実装を任せるより、調査とレビューの分担で感覚をつかみます。

11. 導入前チェックリスト

ひとことで：独立性、範囲、統合方法を確認してから使います。

Subagentsを使う前に、次のチェックリストを確認してください。

  • 作業を独立した観点に分けられる
  • 各agentの担当範囲が重なりすぎていない
  • ファイル変更の可否を指定している
  • 書き込み作業なら担当ファイルが分かれている
  • どのagentを待つか決めている
  • 結果の統合形式を指定している
  • トークン消費が増えても見合う作業である
  • 最後に人間レビューを行う

迷った場合は、Subagentsを使わず、まず単一のCodexに「この作業を分担可能な小タスクに分けてください」と頼むのも有効です。分け方がはっきりしてからSubagentsを使う方が、安全に進められます。

夕宮たいだ

分け方があやふやなまま並列にすると、かえって大変だよぉ。まずは「分けられる作業か」を見ようねぇ。

12. 次に読む記事

ひとことで：並列作業の次は、非同期・継続作業の運用設計へ進みます。

本記事では、Codex Subagentsについて、役割、メリット、向いている作業、調査・レビュー・実装の分担例、結果統合、AGENTS.md・MCP・Skillsとの関係、やりすぎ注意を解説しました。

次に読む記事は、CX-11「Codex Cloud・Automations入門｜作業を任せる運用設計」です。Subagentsが同じ作業の中で分担する仕組みだとすると、CloudやAutomationsは、時間をまたいだ作業や継続的な確認をどう任せるかの話になります。

公式情報としては、Subagents、Subagent concepts、Codex Workflows を確認しておくと、並列作業の使いどころを整理しやすくなります。

夕宮たいだ

ふぁ……これで並列作業の考え方も見えてきたねぇ。次は、時間をまたいで作業を任せる運用に進もう〜。

この記事とあわせて読みたいCodex記事

ひとことで：この記事の理解を深めるための関連回です。

Codexシリーズ記事一覧

ひとことで：Codex編は、導入から専門機能まで順番に読めるシリーズです。

Codex
AIエージェントワークフロー 中級者向け
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

怠惰のアバター 怠惰

関連記事

目次