Claude Code サブエージェントで5ロール体制を組む実践ガイド
「もう一人いれば」と思う瞬間が、ひとりでメディアを運営していると何度もある。記事を書きながら校正もしたい。SEOも考えたい。でも同じ頭で同時にやると、どれも中途半端になる。
Claude Code のサブエージェント機能は、そのジレンマに対してひとつの答えを出している。単一のAIとして会話するのではなく、役割を明確に分けた複数のエージェントがタスクを受け渡しながら動く仕組みだ。
この記事では、Worply Media（本メディア）の実際の構成をもとに、planner / writer / editor / developer / designer の5ロール体制をゼロから組む手順を解説する。ディレクトリ構成、ロール定義ファイルの書き方、委譲プロンプトのテンプレートまで、コピーして使える形で示していく。
前提
必要な環境は以下のとおりだ。
- Claude Code（claude.ai Pro または Max プランが必要）
- ターミナル操作の基礎知識
- Markdown / YAML フロントマターの読み書きができること
サブエージェントとは何かを簡単に補足しておく。Claude Code には「Agent ツール」が組み込まれており、別のClaude インスタンスをサブプロセスとして呼び出せる。呼び出し元（planner）が指示を出し、呼び出し先（writer など）がタスクを実行して結果を返す、という構造だ。モデルを個別に指定できるため、複雑な判断が必要なロールには高性能モデルを、定型作業には軽量モデルを割り当てることでコストも制御できる。
想定読者は「AIツールの基礎は使えるが、複数エージェントの連携はまだ試していない」という個人開発者やひとりメディア運営者だ。
ゴール: 5ロール体制で何が変わるか
Worply Media では現在、以下の5ロールがサブエージェントとして動いている。
| ロール | 主な責務 |
|---|---|
| planner | 全体統括・タスク委譲・公開判断 |
| writer | 記事執筆・ドラフト生成 |
| editor | 校正・品質チェック・差し戻し判断 |
| developer | Next.js サイト実装・バグ修正 |
| designer | アイキャッチ・グラレコ画像生成 |
実感として変わったのは「切り替えコスト」だ。writer が執筆に集中している間、designer は並列でアイキャッチを生成できる。editor の校正が終わったら planner が最終確認して automator にデプロイを委譲する。人間ひとりで全部やると「あ、画像つくるの忘れてた」という漏れが頻発するが、ロールごとに責任範囲が明確だとその種のミスが激減した。
ロール分担を入れる前は、1記事あたり「リサーチ→執筆→画像生成→校正→デプロイ→SNS告知」を一本の長いプロンプトで回していた。途中で文脈が崩れたり、画像スタイルが指示から外れたりすることが多かった。分業後は各ロールが自分の判断基準だけを参照するため、成果物の品質が安定している。
手順
Step 1: ディレクトリ構成を決める
まず、ロール定義ファイルとワークフロー定義を置くディレクトリを用意する。
プロジェクトルート/
├── .claude/
│ └── rules/
│ ├── role-planner.md
│ ├── role-writer.md
│ ├── role-editor.md
│ ├── role-developer.md
│ └── role-designer.md
└── org/
├── planner/
│ └── CLAUDE.md
├── workflows/
│ ├── news-article.md
│ └── tutorial-article.md
└── README.md
.claude/rules/ は各ロールの「行動規範」を置く場所だ。Claude Code がプロジェクトを開くと自動的に読み込む仕様になっている。org/ はもう少し上位の概念で、planner のミッション定義や、複数ロールが連携するワークフローの手順書を格納する。
.claude/rules/ が「このロールは何をすべきか」を定義するのに対し、org/workflows/ は「このタスクで誰がどの順番で動くか」を定義する、という切り分けが機能している。
本メディアの実際の構成もほぼ同じだ。articles/（記事Markdown）、site/（Next.js ソース）と並んで org/ が置かれている。
Step 2: ロール定義ファイル（role-*.md）を作る
.claude/rules/role-writer.md を例に、ロール定義ファイルの構造を見ていく。
---
paths:
- "articles/**"
---
# ライター 運用ルール
## このロールの責務
リサーチ結果と企画方針をもとに、自然な文章で読者に価値を届ける記事を執筆する。
## 操作対象
- articles/ 配下の記事ファイル（作成・編集）
- site/public/ 配下の画像（Gemini MCPで生成したアイキャッチ等）
## 判断基準
- ニュース・解説記事は「だ・である」調、実践ガイドは「です・ます」調
- 同じ文末パターンが3回以上連続しないようにする
- Sourcesセクションは3〜6件必須。## Sources H2見出し形式で記述すること
## 禁止事項
- site/src/ 配下のソースコードを操作すること
- marketerからのSEOキーワード指示なしにSEO最適化を行うこと
- editorの校正前に記事を公開すること
フロントマターの paths: フィールドが重要だ。ここで操作可能なファイルパスを制限することで、writer が誤って site/src/ のソースコードを触れないように制御できる。Claude Code はこの paths: を参照してファイルアクセスを制限する。
セクション構成は「責務 / 操作対象 / 判断基準 / 使用ツール / 禁止事項」の5つで統一すると管理しやすい。ロールが増えてもパターンが一定なので、新しいメンバー（人間でも AI でも）がすぐに把握できる。
Step 3: planner エージェント定義を作る
org/planner/CLAUDE.md は planner の「本拠地」だ。サブエージェントを呼び出す際にここを起点として動く。
# プランナー（リーダー）
## ミッション
メディア全体の戦略立案と統括を行い、コンテンツ・プロダクト・グロースを横断的に調整する。
## ロール別推奨モデル
| ロール | モデル | 理由 |
|--------|--------|------|
| researcher | sonnet | 情報収集・調査レポート生成 |
| writer | sonnet | 記事執筆・ドラフト生成 |
| editor | sonnet | 校正・品質チェック |
| designer | sonnet | ビジュアル制作・デザイン指示 |
| developer | opus | 複雑な実装・アーキテクチャ判断が必要 |
| social-media | haiku | 投稿文作成・定型告知 |
モデルの使い分けが地味にコスト影響を大きく変える。developer は設計判断が伴うため opus にしているが、SNS告知のような定型タスクは haiku で十分だ。最初は全部 sonnet で始め、コストを見ながら調整するのが現実的だ。
委譲プロンプトのテンプレートも CLAUDE.md に含めておくと、planner が毎回フォーマットを考えずに済む。
Step 4: ワークフロー定義（org/workflows/）
org/workflows/news-article.md はニュース記事の作成フローを定義したものだ。「誰が何の順番で動くか」が一覧できる。
# ニュース記事作成
## 実行パターン
SubAgent 逐次 → 一部並列
## 参加ロール
| ロール | 役割 | モデル |
|--------|------|--------|
| planner | オーケストレーター | opus |
| researcher | 調査 | sonnet |
| writer | 執筆 | sonnet |
| editor | 校正 | sonnet |
| designer | 画像生成 | sonnet |
| automator | デプロイ | sonnet |
## 実行フロー
1. planner → researcher（調査）
2. researcher → planner（調査結果返却）
3. planner → writer（執筆委譲）
4. writer → planner（ドラフト返却）
5. planner → editor と designer を並列委譲
6. editor・designer → planner（それぞれ結果返却）
7. planner → automator（デプロイ委譲）
editor と designer は並列で動かせるので、この並列ステップで作業時間が短縮される。
Step 5: planner からサブエージェントへの委譲
Claude Code の Agent ツールを使うと、以下のパラメータでサブエージェントを呼び出せる。
subagent_type: 呼び出す Claude Code インスタンスの種別（通常はclaude-code）model: 使用するモデル（claude-opus-4-5、claude-sonnet-4-5、claude-haiku-3-5など）prompt: サブエージェントへの指示内容
実際の委譲プロンプト例を示す。analyst への委譲を例にとる。
あなたは「アナリスト」です。以下のタスクを実行してください。
## ロール
- .claude/rules/role-analyst.md に従う
## タスク
2026年4月の月次アクセス解析レポートを作成してください。
対象期間: 2026-04-01 〜 2026-04-30
取得指標:
- セッション数・ページビュー数の推移
- トップ10記事
- 流入チャネル比率（オーガニック / SNS / ダイレクト）
- 検索クエリ上位20件（Search Console）
## 完了条件
- GA4 と Search Console のデータが取得できている
- 前月比較が含まれている
- 数値ベースの改善提案が2件以上含まれている
## 完了報告フォーマット
- 実施内容の概要
- 完了項目 / 未完了項目
- 申し送り事項
ポイントは「完了条件」を具体的に書くことだ。「レポートを作成してください」だけでは何をもって完了とするかが曖昧になる。前月比較の有無、数値ベースの提案件数など、チェックリスト的に書いておくと成果物の品質が安定する。
検証: 実際の作業ログ
月次レポート作成タスクの実際の流れを簡略化して示す。
① planner 起動
ユーザーが「4月の月次レポートを作って」と指示。planner が org/workflows/performance-analysis.md を参照し、実行順序を決定する。
② analyst 委譲
planner が上記の委譲プロンプトで analyst を呼び出す。analyst は worply-analytics MCP（GA4/Search Console）を使ってデータを取得し、レポートをテキストで返す。
③ Notion 保存
analyst のレポートを受け取った planner が、今度は automator（または analyst 自身）に Notion への保存を委譲する。mcp__notion__API-post-page を使って指定のデータベースに格納する。
④ marketer 委譲 レポートデータをもとに SEO 改善提案を marketer に委譲。marketer が Search Console のデータから低 CTR のページを特定し、タイトル改善案を出す。
⑤ Linear 起票
改善提案を planner が受け取り、優先度を判断して mcp__linear-server__save_issue で Linear に Issue を作成する。
この一連のフローで、planner は実装作業を一切やらない。各ロールに委譲して結果を受け取り、次の委譲先を判断する、という調整役に徹している。実際に動かしてみると「planner がタスクを直接こなしたくなる誘惑」があるが、そこを我慢するのがポイントだ。
トラブルシューティング
git add 巻き込み問題
記事生成ループが走っている間に手動編集したファイルが git add -A に巻き込まれ、意図しないコミットが発生する現象。対策は git add -A / git add . を automator に禁止し、必ず対象ファイルを明示的に指定させること（本メディアでは MED-14 でこの対処を入れた）。
# NG: ワーキングディレクトリ全体を add
git add -A
# OK: 記事・アイキャッチ・グラレコだけを明示 add
git add articles/2026-04-12-hoge.md
git add site/public/images/blog/2026-04-12-hoge.png
コミットメッセージに MED-N を含め忘れ
Linear と GitHub の連携は、コミットメッセージに MED-N の形式が含まれていないと Issue に自動でリンクされない。writer への委譲プロンプトで「コミット時は MED-24 を含めること」と明記しておくか、automator の役割定義に必須要件として書いておく。
サブエージェントへの指示が曖昧
「レポートを作って」のような指示だと、成果物の粒度がバラバラになる。「完了条件」セクションで具体的な数値や形式を指定する習慣をつけると解決できる。委譲テンプレートを CLAUDE.md に固定しておくのが一番効果的だ。
次のステップ
5ロール体制が動き出したら、以下への発展を検討するとよい。
Notion MCP でナレッジベースを自動化する: analyst が毎月のレポートを Notion に自動保存するワークフローを組むと、月次レビューが定例化しやすくなる。
月次レビューワークフローへの発展: org/workflows/monthly-review.md を作り、analyst → marketer → planner の承認フローを定義する。週次・月次のリズムが生まれると、メディア運営が「単発作業」から「継続的なプロセス」に変わる。
Linear MCP でタスク管理を統合する: コンテンツ企画から実装タスクまで Linear で一元管理し、planner が Issue を起票して各ロールに委譲するフローを組む。MCP 経由で Issue のステータス更新まで自動化できる。
関連記事
- AIエージェントをゼロから運用できる時代が来た——Anthropic「Claude Managed Agents」公開ベータの全貌
- AIエージェント × マルチエージェントシステムが変える業務自動化――2026年の最前線
- MicrosoftがAutoGenとSemantic Kernelを一本化した理由