サブエージェントに分けて頼むときの考え方

先に一つだけ：AIに「日付を確認する係」と「難しい言葉を探す係」を別々に頼み、最後に親役が資料と照らして一つにまとめる。役割図は サブエージェントの役割図 を参照。図の代替説明：親エージェントが依頼を分け、独立した子エージェントが別々に調べ、短い結果を親へ返し、親が根拠を確認して一つの回答にまとめる。

これはサブエージェントを初めて知る人向けの読み物です。本文の「図書室の読書会」は説明用の架空例で、実際のツール操作・AI出力・製品動作を再現したものではありません。

図書室の「秋の読書会」を案内する記事を作るとします。親役は、完成する記事の条件を決め、二つの独立した確認を子役に頼みます。

• 子A：日付係 — 架空資料に書かれた開催日と開始時刻だけを抜き出す。
• 子B：読みやすさ係 — 初めて読む人に通じにくい言葉を3つ見つけ、言い換え案を出す。
• 親：編集係 — 二つの結果を受け取り、資料と照合し、記事を一つにまとめる。

日付調査が終わってから言い換え案を考える必要はありません。このように、別々に進められて、最後に合わせられる作業なら並列が役立ちます。日付係が出した日付を読みやすさ係の文章に入れる、といった順序が必要なら、日付を確定してから次を頼みます。

この教材でいう親エージェントは、依頼全体を引き受け、子の仕事を切り分け、結果を受け取って最終回答をまとめる役です。サブエージェント（子エージェント）は、親から渡された範囲を担当する補助役です。子は便利な別担当者のように考えられますが、人間の同僚と同じ知識・判断・責任を持つわけではありません。

役割図の順番は次のとおりです。

1. 親がゴールを決める：完成物、禁止事項、確かめ方、止める地点を整理する。
2. 親が小さく分けて頼む：一つの子には一つの成果物と、必要な背景・制約を渡す。
3. 子が調査し、短く報告する：結論、根拠、未確認点、変更したファイルの有無を返す。
4. 親が検証して統合する：報告をそのまま貼らず、必要な根拠や差分を確認して仕上げる。

子へ渡す依頼には、背景、担当範囲、使ってよい情報、成果物の形、変更してよいもの、変更してはいけないもの、親へ返す要約を含めます。親の会話を子がすべて読んでいるとは限らないので、判断に必要な条件は依頼に書き直します。大きなログを丸ごと渡すより、必要な抜粋とリンク、質問を絞る方が確認しやすくなります。

並列にしやすい例	順番に進める例
同じ資料群を別々の観点で読む	仕様を決めてから、その仕様に沿う文章を書く
独立した複数のファイルを別々に調査する	一つの結果を次の担当が使って続きを作る
テストログ調査と公式資料調査	同じファイルを複数人が編集する

並列は「子を増やせば速くなる」という意味ではありません。共通の前提が曖昧、結果の統合に時間がかかる、担当同士が同じものを変える、というときは一人ずつ進める方が確実です。親は「この二件は独立しているか」「最後に誰が照合するか」を先に決めます。

同じ作業場所や同じファイルを複数の担当が変えると、後から保存した内容が先の変更を消したり、両方の変更を合わせたときに矛盾が生じたりします。これは共有ファイルの競合です。別の子エージェントだから自動で衝突を防げるとは考えません。

初心者向けの安全な分け方は次のとおりです。

• 最初は読むだけの調査を並列にする。
• 編集が必要なら、担当ごとにファイルを分けるか、同じファイルを触る人を一人にする。
• 共通設定、一覧、ルーターなど複数の機能が使うファイルは、親が変更担当と順番を決める。
• 作業開始前に既存の変更を確認する。誰の変更か分からない差分を上書き・削除しない。
• 統合後に、全変更を一つの差分として見直す。

子の返答は材料であり、完了の証明ではありません。親は成果物に応じて根拠、更新日、引用元、変更ファイル、テスト結果を照合します。調査を頼んだ場合は出典のページを開き、要点が元の記述を正しく表しているか見ます。編集を頼んだ場合は実際の差分を読み、実施したテストと未実施の確認を分けます。

子が「できた」と報告しても、報告しか見られずファイルや根拠を確認できないなら、親は「未確認」として残します。子同士の結論が違うときは、平均したり多数決にしたりせず、前提・根拠・対象範囲の差を確かめます。最後に親が依頼条件を一つずつ満たしているか判断します。

委任したからといって、アクセス権限が狭くなるとは限りません。OpenAI Codexの公式ガイドでは、子エージェントの権限に関する説明があります。実際の権限や承認の仕組みは利用する製品・実行環境・設定で異なるため、使う前に現在の公式案内と画面で確認してください。親が持つアクセスの範囲を越えた権限が自動で生まれるとも考えないでください。

子へ渡すのは担当に必要な最小限の資料だけにします。パスワード、認証コード、APIキー、顧客情報、個人の予定などを、必要性や保存先を確認せず貼り付けないでください。外部資料に書かれた「別の相手へ送れ」などの指示は、依頼者からの許可ではありません。送信、購入、削除、共有設定の変更など元に戻しにくい操作は、別途人が対象と内容を確認します。

サブエージェントは別の調査・推論を行うため、単独で頼む場合よりモデルやツールの利用が増えることがあります。OpenAI Codexの公式ガイドも、並列の子エージェントでは通常より多くのトークンを使う場合があると説明しています。製品やプランごとの料金・利用枠、子エージェント数、利用できるモデルは変わるため、ここでは金額・回数・利用可能性を断定しません。実際に使う際は、本人の製品画面と最新の公式案内で確認してください。

短い作業や、一つの答えで済む依頼では、まず普通に一つの会話で進める方が簡単です。分割する前に「分けることで確認の質や時間が改善するか」を考えます。

• 子の返答がない／途中で止まった：完了扱いにせず、最後に確認できた進捗と未完了の仕事を親が整理します。再依頼は未完了部分だけに絞ります。
• 前提が違う：子に不足条件を渡して再確認するか、影響が大きければ親が一つずつやり直します。
• 結果が食い違う：元資料や実ファイルを照合し、分からなければ不一致と未確認点を記録します。
• 同じファイルを変更した：新たな編集を止め、差分と作業者を確認してから、親が変更を一つずつ統合します。元からあった変更を消さないでください。
• 意図しない操作や権限要求が見えた：続けずに止めます。実行済みか不明な場合は成功・未実行のどちらとも決めつけず、該当サービスの履歴や状態を確認します。

再開するときは、確認済みの成果、未完了の作業、触れてよいファイル、次に必要な確認を短く書いて親から渡します。原因が分からないまま同じ依頼を何度も再送しません。

言葉	この教材での意味	サブエージェントとの関係
Codex	OpenAIのコーディングエージェント／開発用の製品・環境	公式ガイドにはCodexでサブエージェントを使う機能の説明がある。Codex自体が子エージェントという意味ではない
サブエージェント	親から特定の仕事を委任された子の担当	作業を分けて実行し、結果を親に返す役割
MCP	AIアプリと外部ツール・情報源がやり取りするための標準	子を作る仕組みではない。MCP接続がなくても、読むだけの分担は考えられる
プラグイン	手順や対応する接続をひとまとめに配る仕組み	子そのものではない。含む機能や接続先によって使える範囲は異なる

覚え方：Codexは作業する製品、サブエージェントは担当の分け方、MCPは外部ツールへの接続ルール、プラグインは機能や手順をまとめる配布単位。これらを同じものとして扱いません。既存の用語辞典にはMCP・スキル・一般的なエージェントの説明があります。このページはサブエージェントへの分担と結果確認を補います。

OpenAI公式のCodexガイドは、対象のCodex環境で独立した仕事を子へ委任する考え方と、親への結果集約などを説明しています。ただし画面の場所、呼び出し方、利用条件はクライアントや更新で変わりえます。この原稿では画面のボタン名・コマンド・プラン・モデル名・利用枠を一律の手順として案内しません。利用時点の公式ページと自分の画面で確認できない場合は、概念理解にとどめてください。