Codexへ長い仕事を頼んだものの、途中から条件が混ざり、完成物のどこを確認すればよいか分からなくなった経験はありませんか?
記事制作でいえば、ネタ探し、SEO調査、構成、執筆、画像、内部リンク、投稿までを一度に指示すると、作業量だけでなく判断の種類も増えます。一つのAIにすべてを背負わせるほど、見落としの原因を特定しにくくなります。
僕も最初は、Codexに大きな仕事をまとめて頼めば効率がよいと考えていました。しかし、noteやWordPressの自動化を試す中で、万能な一人を作るより、専門担当へ仕事を分けたほうが管理しやすいと分かりました。
サブエージェントの本質はAIを増やすことではなく、仕事の境界と受け渡し条件を明確にすることです。
この記事では、Codexのサブエージェントとは何か、どんな仕事を分けるべきか、親エージェントと担当者の役割、成果物の受け渡し方を初心者向けに解説します。僕が作ったnote8担当とWordPress10担当の実例も紹介します。
- Codexのサブエージェントが果たす役割
- 一人のAIへ任せる場合との違い
- 並列化できる仕事と順番に進める仕事
- 親担当・専門担当・品質確認担当の設計方法
- note8担当、WordPress10担当の構築実例
Codexのサブエージェントとは?

サブエージェントとは、メインとなる親エージェントから、限定された仕事を任される専門担当です。親担当が全体の依頼を理解し、必要に応じて調査、検品、分析などを別の担当へ渡し、最後に結果をまとめます。
OpenAI公式ドキュメントでは、Codexは専門化したエージェントを並列で動かし、その結果を一つの応答へ集約できると説明されています。各担当の作業は別のエージェントスレッドで進み、親担当は要約された成果を受け取ります。
会社に例えるなら、親エージェントはプロジェクト管理者、サブエージェントは調査担当やレビュー担当です。社長がすべての資料を自分で作るのではなく、専門部署へ依頼し、判断に必要な報告だけを受け取る形に近いでしょう。
フォルダで分けた担当と実行中のサブエージェントは別物
僕のプロジェクトには「本文作成」「画像生成」などの担当フォルダがあります。これは、仕事の責任範囲やルールを保存した組織設計です。
一方、公式機能としてのサブエージェントは、実行時に親エージェントから仕事を委任される別の作業者です。フォルダは部署のマニュアル、サブエージェントは実際に仕事をする担当者と考えると区別しやすくなります。
↓担当ごとの仕事ルールを保存するAGENTS.mdはこちら↓
CodexのAGENTS.mdとは何かを初心者向けに解説。配置場所、読み込み範囲、目的・入力・手順・完了条件・禁止事項の…
なぜ一人のAIより分業が管理しやすいのか

一つの依頼が大きくなるほど、AIは多くの情報を同じ会話で扱います。調査メモ、候補、エラー、画像の指示、投稿画面の状態などが混ざると、重要な条件が埋もれやすくなります。
公式ドキュメントでは、不要な中間出力がメインチャットへ蓄積すると、必要な情報が埋もれる「コンテキスト汚染」や、時間とともに性能が下がる「コンテキストロット」につながる可能性が説明されています。
サブエージェントへ調査やログ分析を任せれば、親担当へ返すのは結論と根拠だけです。メインの会話は、要件、判断、最終成果物に集中できます。
原因を特定しやすくなる
画像が間違っていたとき、本文担当まで疑う必要がなければ修正範囲を限定できます。SEOキーワードの選定が弱ければ、調査工程の採点基準を見直せます。
僕のnote投稿テストでは、CTA画像の二重挿入やH2画像の誤配置が起きました。投稿担当の手順へ原因と正しい位置を戻すことで、他の担当を作り直さず改善できました。
分業のメリットは速さだけではなく、失敗した工程を見つけ、局所的に直せることです。
親担当のコンテキストを守れる
親担当が、すべての検索結果やエラーログを直接読み続けると、読者像や完成条件などの大切な情報と、中間作業のノイズが同じ場所へ蓄積します。
調査担当が「確認できた事実」「使える具体例」「注意点」「参照URL」だけを返せば、親担当は意思決定に集中できます。本文担当へ渡す根拠パックも短くなり、未確認情報が混ざる可能性を下げられます。
長い仕事ほど、担当を増やす前に「親へ戻す情報」と「担当内で完結させる作業ログ」を分けることが効果的です。
サブエージェントへ分ける基準

すべての作業を細かく分割すればよいわけではありません。担当を増やすほど、指示、受け渡し、統合の手間も増えます。
次の条件に当てはまる仕事は、分離を検討しやすいでしょう。
- 専門知識や確認基準が他工程と異なる
- 入力と出力を明確なファイルで渡せる
- 他の仕事と独立して調査・検品できる
- 失敗したときに、その工程だけ再実行したい
- 同じ仕事を今後も繰り返す
並列化に向く仕事
複数資料の調査、別々の観点によるレビュー、既存記事候補の収集、画像案の比較などは、互いの作業結果を待たずに進めやすい仕事です。
公式ドキュメントでも、探索、テスト、トリアージ、要約といった読み取り中心の仕事から並列化を始めることが推奨されています。
順番に進めるべき仕事
タイトルが決まってから本文を書く、本文のH2が決まってから画像を作る、品質確認に合格してから投稿するといった工程は、前の成果物へ依存します。
同じファイルを複数の担当が同時に編集する仕事も注意が必要です。競合や上書きが起きやすいため、編集担当を一つに絞るか、ファイルを分けて最後に統合します。
分けないほうがよい仕事
一つの短い文章を少し直す、画像一枚の色を変える、決まったファイル名を修正するといった小さな作業は、委任の説明や結果確認のほうが重くなることがあります。
また、文章全体の一貫した語り口が重要な場面で、段落ごとに別担当へ書かせると、表現や結論がばらつきます。この場合は、一人の本文担当が全体を書き、別のレビュー担当が確認するほうが安定します。
「並列にできるか」だけでなく、「分けた後の統合が簡単か」まで考えて判断しましょう。
親エージェントと専門担当の役割を決める

分業を成功させるには、親担当と専門担当の責任を分けます。
| 役割 | 主な仕事 | 避けること |
|---|---|---|
| 親エージェント | 目的の理解、担当の選択、順序管理、結果統合 | 細かな専門作業をすべて抱える |
| 専門担当 | 限定された調査・制作・検品 | 依頼範囲を超えて公開や削除まで進める |
| 品質確認担当 | 完成条件との照合、修正指示、再確認 | 根拠なしに内容を追加する |
親担当には「誰へ何を任せるか」「すべての結果を待つか」「どの形式で統合するか」を伝えます。専門担当には「目的」「入力」「実行範囲」「返す成果物」「完了条件」を渡します。
担当名より境界が大切
「ライター」「マーケター」のような肩書だけでは、どこまで進めるか分かりません。「確認済み構成を基にHTML本文を作り、投稿は行わない」のように、開始点と停止点を書きます。
また、外部サービスへ書き込む担当には、下書き保存、公開、送信、削除などの境界を明確にします。僕のWordPress担当は下書き保存までで、公開は僕が行います。
専門担当へ渡す指示の基本形
実際に委任するときは、「何を調べるか」だけでなく、独立して進められる範囲、待つべき条件、返却形式まで書きます。
「公式資料からサブエージェントの利点と注意点を調査してください。製品仕様と一般的な運用提案を分け、重要点を5項目、出典URL付きで親担当へ返してください。本文の執筆やファイル編集は行わないでください。」
このように書けば、調査担当が勝手に原稿を書き換えることを防ぎ、親担当も受け取った結果を比較しやすくなります。
成果物の受け渡しは候補IDと完了条件で管理

複数担当の仕組みで最も重要なのが、成果物の受け渡しです。口頭で「前の担当が作ったものを使って」と伝えるだけでは、別テーマのファイルや古い原稿を拾う可能性があります。
僕の仕組みでは、テーマ候補ごとに候補IDを付け、各工程で同じIDを引き継ぎます。タイトル、本文、画像、品質レポート、投稿状態を同じ仕事として照合できるようにしています。
受け渡しファイルに含める項目
- 候補IDまたは記事ID
- 採用テーマと読者の悩み
- 前工程で確認済みの根拠
- 成果物ファイルの保存場所
- 未確認事項と使用禁止情報
- 次工程が行うこと・行わないこと
完了条件も数値や状態で書きます。「よい記事にする」ではなく、「6,000〜10,000文字」「H2直下に画像1枚」「ブログカード2〜3件」「下書き状態」とします。
受け渡しを人の記憶ではなく、ファイル名・ID・チェック項目で確認できる形にすることが重要です。
途中から再開できる状態を残す
外部サービスへの投稿中に接続が切れた場合、最初のテーマ選定からやり直す必要はありません。本文、画像、メタ情報まで完了しているなら、投稿工程だけ再開できる状態を保存します。
僕の運用では、投稿ID、編集URL、完了済み画像、未完了工程などをチェックポイントへ残します。再開時は候補IDと記事タイトルを照合し、同じ下書きの続きを処理します。
この仕組みがないと、担当を再実行した際に新しい下書きが作られ、重複投稿の原因になります。分業では「完成物」だけでなく「現在地」も成果物です。
須賀の実例1:note記事を8担当へ分業

note部門では、次の8担当を順番に動かしています。
- noteネタ探し
- noteネタ選定
- 記事タイトル作成
- 本文作成
- 画像生成
- ハッシュタグ作成
- 構成の確認
- note投稿
ネタ探し担当は登録したYouTubeチャンネルの最新動画を軽く確認し、全動画の文字起こしは行いません。ネタ選定担当が本命と予備を採点し、本命だけを詳しく確認します。内容が弱ければ、人の承認を待たず予備候補へ切り替えます。
本文、画像、ハッシュタグが揃ったら、構成確認担当が人の代わりに検品し、修正後の合格版だけを投稿担当へ渡します。投稿担当はnoteへ入力しますが、公開せず下書き保存で止まります。
この設計により、僕が確認するのは最後に上がってきた下書きです。途中で毎回「OK」と返す必要はありません。
本命が弱い場合に予備へ切り替える
YouTube動画を情報源にする場合、タイトルは魅力的でも、記事にできるほど具体的な内容がないことがあります。そのため、選定担当は本命1件と予備候補を持ち、本命だけを詳しく確認します。
内容が薄い、公式情報で裏付けられない、読者に合わない場合は、本人の確認を待たず予備へ切り替えます。無人進行で大切なのは、何が起きても止まらないことではなく、安全な代替案を先に用意することです。
部署数を増やしたことより、「誰が最終候補を決めるか」「誰が品質を保証するか」「誰が外部へ書き込むか」を分けたことが重要でした。
須賀の実例2:WordPress記事を10担当へ分業

WordPressはSEO、HTML装飾、内部リンク、メタ情報など確認項目が多いため、noteより細かく10担当へ分けました。
- 記事テーマ選定
- SEOキーワード調査
- 記事タイトル作成
- 見出し構成作成
- 本文作成
- 画像生成
- 内部リンク選定
- メタ情報作成
- 構成確認
- WordPress投稿
本文担当は6,000〜10,000文字のHTMLを作り、画像スロットと内部リンク候補を残します。画像担当はアイキャッチと各H2画像を600×400pxで用意します。内部リンク担当は過去記事を調べ、本文の流れを壊さない位置へブログカードを配置します。
最後の投稿担当は、内蔵ブラウザでクラシックエディターへHTMLを入力し、アイキャッチ、カテゴリー、メタディスクリプションを設定します。保存後にプレビューを開き、H2数、画像、ブログカード、下書き状態を検品します。
品質確認担当を投稿担当の前に置く理由
本文を書いた担当が自分の文章を確認すると、思い込みによって不足を見逃すことがあります。そこで、構成確認担当は文字数、検索意図、根拠、画像スロット、内部リンク、禁止表現を別の視点で確認します。
不合格ならその場で修正し、再確認した合格版だけを投稿担当へ渡します。投稿担当は文章の中身を再設計せず、決められた入力と保存後検品へ集中できます。
↓Skills・MCP・プラグインの使い分けはこちら↓
CodexのSkills・MCP・プラグインの違いを初心者向けに解説。仕事のレシピ・外部への橋・道具箱という比喩で、役割…
並列化しすぎると起きる失敗と注意点

サブエージェントは便利ですが、担当を増やせば必ず速くなるわけではありません。各担当が個別にモデルやツールを使うため、単一エージェントよりトークン消費が増えることも公式に明記されています。
同じ成果物を同時に編集しない
複数担当が同じHTMLや設定ファイルを同時に書き換えると、後から保存した内容で上書きされる可能性があります。並列で進めるなら、別ファイルへ結果を出し、親担当が統合します。
小さすぎる仕事へ分けない
見出し一つ、文章一文ごとに担当を分けると、受け渡しの説明が成果物より長くなります。「専門性が違う」「独立して進められる」「再利用する」のいずれかを満たす単位にします。
親担当を単なる伝言係にしない
親担当は、返ってきた結果をそのまま連結するだけではありません。矛盾、重複、根拠、完了条件を照合し、採用する成果を判断します。
権限と停止条件は親子で共有する
サブエージェントは親の権限やサンドボックス方針を引き継ぐ場合があります。公開、送信、削除などの重要操作は、担当任せにせずプロジェクト全体の禁止事項として定義します。
初心者向けサブエージェント設計の3ステップ

最初から大規模なAI組織を作る必要はありません。次の3ステップで始めましょう。
ステップ1:今の仕事を開始・作業・確認に分ける
たとえば記事制作なら、「テーマを決める」「本文を作る」「完成条件を確認する」の3つに分けます。最初は本文と確認の2担当でも構いません。
ステップ2:各担当の入力と出力を1行で書く
「確定構成を受け取り、HTML本文を返す」「完成HTMLを受け取り、検品レポートを返す」のようにします。説明できない担当は、まだ分ける単位が曖昧です。
ステップ3:親担当の統合条件を決める
すべての担当を待つのか、予備候補へ切り替えるのか、失敗時にどこから再開するのかを決めます。成果物には同じIDを付け、別テーマのファイルが混ざらないようにします。
サブエージェントは、AIへ丸投げするための仕組みではありません。仕事を観察し、役割、入力、出力、確認、停止点を明確にするための仕組みです。
まずは「制作担当」と「確認担当」を分け、品質確認で見つかった失敗をそれぞれのルールへ戻す。この小さな分業から始めれば、日々の仕事に合ったAI組織へ育てていけます。
↓非エンジニア向けCodex活用法はこちら↓
非エンジニア向けのCodex活用法7選を実例で解説。ブログ、note、メルマガ、SNS、画像、PowerPoint、定期…
参考:OpenAI公式「Subagents」。提供機能、画面、モデル設定などは変更される可能性があるため、利用時は公式の最新情報をご確認ください。


