Codexのサブエージェント入門

大きな作業を一度に頼むと、調査の途中経過が増えて判断しにくいことがあります。サブエージェントは、独立した小さな仕事を別の担当へ渡し、結果を集めるための仕組みです。この記事では、二つの読み取り調査を分担する依頼例から始めます。

先に独立している仕事かを考える

並行して進めやすいのは、「導入説明を読む」と「テスト一覧を読む」のように、お互いの結果を待たずに着手できる仕事です。先に設計を決めないと書けないコードを、設計担当と同時に別担当へ実装させるとやり直しが増えます。

公式資料では、現在のローカルCodexは明示的な依頼や適用される指示に従って分担します。CLIでは /agent で担当のタスクを確認できます。複数の担当がモデルやツールを使うため、単独の処理よりトークン消費が増えます。サブエージェントの公式説明

各段階で確認してから、次の操作へ進みます。

1. 1範囲を分ける別々に調べられる問いを担当へ渡します。
2. 2結果を待つ完了・失敗・未確認を区別して集めます。
3. 3根拠でまとめる矛盾や重複を整理し、次の変更を決めます。

具体的な依頼と、結果の確かめ方は本文にあります。

担当を増やすだけで品質が上がるわけではありません。最後に根拠をまとめる工程を残します。

二人の読み取り担当を頼む例

READMEとテストがある練習用のプロジェクトで使います。実際に存在しないファイルは作らず、ないと報告してもらいます。

このプロジェクトを変更せずに確認してください。
独立した調査を2人のサブエージェントへ分担してください。
A：READMEを読み、導入に必要な準備・実行場所・成功確認の不足を挙げる。
B：テスト関連ファイルを読み、何を検査するかと未確認の範囲を整理する。
両者ともファイルの作成・変更・削除、依存関係のインストールはしない。
両方の完了を待ち、根拠のファイル名と該当箇所を付けてまとめてください。
テストは実行していなければ未実行と書き、成功したと扱わないでください。

ここではあえて読み取りだけにしています。初回から複数人に同じファイルを編集させず、役割・禁止する変更・報告の形を確認する練習です。

返ってきた結果を確認する

期待する報告の形は次です。これは説明用の例で、特定のプロジェクトを実測した結果ではありません。

「見当たらない」は、実際に調べた範囲での結果です。別のフォルダーや外部CIにある可能性まで否定していないか確認します。根拠の場所を開けない指摘は、実装前に再確認します。

片方が失敗した場合

片方が完了していても、もう片方がアクセス不能なら全体を確認済みにしません。「どこまで読めたか」「何が足りないか」を分けて受け取ります。失敗した担当へ同じ大きな依頼を繰り返す前に、対象ファイルを狭めて調べます。

利用枠が厳しいときや小さな一か所の修正では、一人で順番に進める方が判断しやすい場合もあります。分担に向く仕事だけに絞りましょう。

編集へ進むときは担当範囲を決め直す

読み取りで得た指摘を見て、必要な変更だけを選びます。同じファイルを複数人が同時に編集しないよう担当を分け、統合後は差分とテストを確認します。ファイルを分離する必要がある場合はワークツリーの役割も確認してください。

このページは公式仕様と照合した依頼の設計例です。掲載の二人への分担を実行した性能比較や、実機成功の報告ではありません。