【Claude Code】サブエージェント6人で記事作成を自動化した実例

Claude Codeで作った記事製作チームの全体像

Claude Codeで記事作成を自動化するには、メインセッションをPM（司令塔）役にして、リサーチ・執筆・図解・レビュー・校正をサブエージェントに分担させるチーム構成にする方法があります。PMは「スキル（Skills）」で役割を定義し、各担当は「サブエージェント」として用意します。

今回のチームは、司令塔のPMと、その下で働くAI社員6人という構成です。全体像は次のとおりです。

動かし方はシンプルです。/pm と打ってPMを起動し、「このテーマで記事を書いて」と依頼します。PMが制作計画を出してくるので、そこだけ承認すれば、あとは各社員を順番に呼び出して納品まで自走します。

なお、これとは別にClaude Code本体が、コマンド実行やファイル編集のたびに確認（ツールの許可）を求めてくることがあります。よく使う操作を設定の許可ルール（permissions）に登録しておけば、この確認はほとんど省けます。すべての確認をスキップするモードもありますが、公式ドキュメントでは、コンテナなど隔離された環境でのみ使うよう注意されています。

この記事の内容は Claude Code 2.1.215（2026年7月時点） をもとにしています。Claude Codeは更新が速く、サブエージェントやスキルの仕様も変わることがあるため、実際に試すときは公式ドキュメントもあわせて確認してください。

チーム設計の考え方｜skillsとサブエージェントの組み合わせ方

なぜPMは「スキル」で、社員は「サブエージェント」なのか。まずはこの理由から説明します。

PMはスキル、社員はサブエージェントにした理由

スキルとサブエージェントは、どちらもClaude Codeに役割を持たせる仕組みですが、動く場所が違います。

つまりスキルはメイン会話に指示を載せて指揮を執り続ける役で、サブエージェントは重い作業を別の場所に逃がして結果だけ返す役です。この違いに合わせて、PMはスキルとして、6人の社員はサブエージェントとして定義しました。社員が長い出力を返してもメイン会話は重くならず、PMが最後まで見通しよく指揮できます。

スキルとサブエージェントの違いそのものは、別記事で詳しく比較しています。

指揮はPM（メインセッション）に集約する

次に決めたのが「誰が誰を呼べるか」です。このチームでは、社員を呼び出せるのはPM（メインセッション）だけにしました。社員同士が勝手に別の社員を呼ぶことはできない構成です。

これは仕様上の制約ではなく、意図的な設計判断です。Claude Codeでは、サブエージェントの定義に「Agent」というツールを持たせれば、サブエージェントからさらに別のサブエージェントを呼び出せます（v2.1.172以降で可能・最大深さ5まで）。今回はあえてこの機能を使っていません。6人全員の設定ファイルで使えるツールを明示的に列挙し、そのどれにも「Agent」ツールを含めないことで、社員は他の社員を呼べないようにしています。

理由は次の3つです。

指揮はPMに集約し、社員は自分の担当作業に専念する。この形なら指揮系統が崩れません。

規約は1つのファイル（CLAUDE.md）に集約する

もうひとつ大事にしたのが「ルールの置き場所」です。記事の書き方（HTMLの骨格・使う部品・文章のスタイルなど）は、すべて CLAUDE.md という1つのファイルにまとめました。各社員の設定ファイルには役割だけを書き、細かい書き方の規約は重複させず、CLAUDE.mdを参照する形にしています。

何をどこに置くかの目安はシンプルです。変わらない事実やリファレンスはCLAUDE.mdに、作業の進め方（手順）はスキルに置きます。

ルールが複数のファイルに散らばると、直したときに片方だけ古いまま残り、食い違いが発生します。大元のファイルを1つに決めておくと、更新は1か所で済み、全員が同じルールで動けます。

AI社員6人の役割分担

次の表に、6人それぞれの担当工程・主な入力・成果物をまとめました。

担当ごとに、使うモデルや権限も変えています。たとえば図解を作るillustratorは軽めのモデル（sonnet）を割り当て、ほかの担当は精度重視のモデルを使うといった具合です。

また、後述するreviewerとproofreaderはファイルを読む権限しか持たせていません。チェック担当が本文を勝手に書き換えないようにするためです。

役割を1人1ファイルで分けておくと、あとからその担当だけをカスタマイズできるのもメリットです。たとえば校正のチェック観点を増やしたいときは、proofreaderの定義ファイルに追記するだけで済み、ほかの担当には影響しません。

レビュー担当と校正担当を分けた理由

チェックを「reviewer（技術・規約・SEO）」と「proofreader（日本語の読みやすさ）」の2人に分けたのは、見る観点がまったく違うからです。技術の正しさと文章の自然さを1人に同時に見させると、どちらかのチェックが甘くなりがちです。

もうひとつ意識したのが「別の目」で見ることです。ポイントは2つあります。

記事ができるまでの流れ

実際にどう進むかを順に見てみましょう。企画から公開後の効果測定まで、工程ごとに担当が替わりながら制作が進みます。

この流れで、人が承認するのは②設計で出てくる制作計画の1回だけです。工程ごとに「これでいいですか？」と確認をはさんでいたら、自動化の意味がありません。

計画さえ合意できていれば、あとの実作業はPMがそのまま進めます。方針が変わるような発見があったときだけ、立ち止まって社長に報告する運用になっています。

記事製作チームの作り方【設定ファイルつき】

ここからは、このチームを動かす設定ファイルの中身を見ていきます。プロジェクト内のファイル配置は次のとおりです。

プロジェクトフォルダ/
├─ CLAUDE.md …… 記事の書き方の規約（全員が参照する大元のファイル）
├─ .claude/
│  ├─ agents/ …… サブエージェントの定義（1人1ファイル）
│  │  ├─ data-analyst.md
│  │  ├─ researcher.md
│  │  ├─ writer.md
│  │  ├─ illustrator.md
│  │  ├─ reviewer.md
│  │  └─ proofreader.md
│  └─ skills/
│     └─ pm/
│        └─ SKILL.md …… PMの定義（/pm で起動）
└─ articles/ …… 記事データ（設計書・リサーチメモ・記事本体）

この構成さえ作れば、あとは各ファイルに役割を書いていくだけです。まずはサブエージェントの定義ファイルから見ていきます。

サブエージェントの定義ファイル

サブエージェントは、.claude/agents/ の中に1人1ファイルのMarkdownで作ります。ファイル先頭の --- で囲んだ部分（フロントマター）に設定を書き、その下に役割の指示を書きます。執筆担当 writer の定義ファイルから、設定部分を抜き出したのがこちらです。

---
name: writer
description: 記事の執筆担当。brief.mdとCLAUDE.md規約に従って、新規記事の執筆または既存記事のリライトを行い index.html を完成させる。レビュー指摘の反映も担当する。
tools: Read, Write, Edit, Glob, Grep, WebSearch, WebFetch, Bash
model: opus
---

あなたは webdesign-programming.com の記事執筆担当（ライター）です。
（この下に、担当する工程・執筆前に読むファイル・守るルールを書く）

設定項目の意味は次のとおりです。

name

サブエージェントの識別名。小文字とハイフンで一意にする（ファイル名と一致しなくてもよい）

description

「どんなときにこの担当へ任せるか」を書く。ここを明確にしておくほど、狙った担当に仕事が渡りやすくなる

tools

使えるツールを列挙する。省略すると全ツールを引き継ぐ。ここに Agent を書かないことで、この担当は別のサブエージェントを呼べなくなる

model

使うモデル。省略するとメイン会話と同じモデルを引き継ぐ。担当の重さに応じて変えてよい

PMスキルの定義ファイル

PMは .claude/skills/pm/SKILL.md というファイルで定義します。スキルはディレクトリ名がそのままコマンド名になるので、pm フォルダに置けば /pm で呼び出せます。

フロントマターには name と description だけを書き、本体に体制図と進行手順をまとめています。このSKILL.mdから、フロントマターと体制図の部分を抜き出したのがこちらです。

---
name: pm
description: 記事製作チームのプロジェクトマネージャー。社長の指示から制作計画（構成案）を立てて承認を取り、
  data-analyst / researcher / writer / illustrator / reviewer / proofreader を工程ごとに呼び出して
  新規記事・リライトを納品まで進行する。
---

# 記事製作チーム PMハーネス

## 体制図

社長 …… 指示を出す／制作計画を承認する／WordPress操作・画像配置をする
 └─ PM（このメインセッション）…… 計画立案・設計・社員への発注・検収・報告
     ├─ data-analyst …… ネタ選定・SERP分析・効果測定（GSC/GA4）
     ├─ researcher …… リサーチ（一次情報で事実を集め research.md に）
     ├─ writer ………… 執筆（新規・リライト・指摘の反映）
     ├─ illustrator …… 図解（SVG自作→PNG化）
     ├─ reviewer ……… レビュー（技術・規約・SEOを別コンテキストの「新しい目」で）
     └─ proofreader … 校正（日本語だけを文単位で走査。技術は見ない）

この体制図の下に、モード判定（新規かリライトか）・承認のタイミング・工程の回し方・発注ルールを手順として書いています。PMはこのスキルを読み込んだ状態で、手順どおりに社員を呼び出していきます。

見出しにある「ハーネス」とは、AIを決まった役割と手順で動かすための枠組みのことです。進め方をその都度AIの判断に任せるのではなく、体制・工程・運用ルールをこうしてファイルに固定しておくことで、いつ実行しても記事制作が同じ流れで回ります。

起動方法

準備ができたら、Claude Codeで /pm と打ち、続けて依頼を書くだけです。たとえば新規記事なら、次のように投げます。

これでPMが起動し、まず制作計画（対象キーワード・記事の骨子・図解の要否・担当の割り振り）を提示してきます。内容を確認してOKを出すと、あとは各社員を順に呼び出して記事を仕上げていきます。

サブエージェントとスキル、それぞれの作り方は個別の記事で手順を追って解説しています。ファイルの書き方でつまずいたら、こちらの記事で手順を確認してみてください。

運用して分かったコツと注意点

実際にこのチームで記事を作るなかで見えてきた、運用のポイントを紹介します。

発注文は自己完結で書く

サブエージェントは、PMと社長との会話を見ていません。別の作業場でまっさらな状態から始まるため、「さっき話したあの記事」と書いても伝わりません。

そのため、PMが社員に作業を頼むときの指示文（発注文）は、それだけ読めば作業できる自己完結の形で書きます。具体的には、対象ファイルのパス・モード（新規かリライトか）・期待する成果物・参照してほしいファイルまで、すべて発注文に含めます。前提を省くと、的外れな成果物が返ってきます。

たとえば、執筆担当のwriterへの発注文は次のような形です。

記事の新規執筆をお願いします。

- 成果物: articles/記事スラッグ/index.html
- モード: 新規執筆
- 設計書: articles/記事スラッグ/brief.md（構成・タイトルはこの通りに）
- リサーチメモ: articles/記事スラッグ/research.md（本文の事実はここに基づく）
- 規約: CLAUDE.md を必ず読むこと
- 完了報告に含めるもの: 作成ファイルのパス／裏取りできず「要検証」とした箇所

対象・参照ファイル・完了報告の形まで書いてあるので、writerはこの文だけで作業を始められます。実際の発注文では、これをベースに記事ごとの注意点（守ってほしい表現・画像の配置指示など）を書き足しています。

レビューの往復に上限を決める

reviewerの指摘をwriterが直し、また見て…を無制限に繰り返すと、細かい指摘で永遠に終わらなくなります。そこでレビューの往復は最大2回、校正は1回と上限を決めました。それでも残った指摘は、PMだけで処理せず、判断材料を添えて社長に報告します。

成果物は必ずPMが検収する

社員の「できました」を鵜呑みにせず、PMが実際にファイルを開いて中身を確認してから次に進みます。とくに社員が「ここは要検証」と報告してきた箇所は、必ずPM自身で確認します。

仕様は記憶で書かず公式ドキュメントで裏取りする

これは実際にこの記事を作る過程で起きた話です。チームを組んだ当初は「サブエージェントは別のサブエージェントを呼べない」という認識で設計していました。ところがリサーチで公式ドキュメントを裏取りすると、v2.1.172で仕様が変わり、条件を満たせば呼べるようになっていたことが分かり、設定ファイルの古い記述を修正しました。

AIツールの機能は短い間隔で更新されるため、仕様は記憶で書かず、その都度公式ドキュメントで確認するのが確実です。事実確認を専任のresearcherに任せているのも、こうした取りこぼしを防ぐためです。

すべては自動化せず、人の判断を残す

この仕組みは、全部が自動で終わるわけではありません。次の作業は人（社長）が行います。

このうちWordPressへの投稿などは、仕組みを作れば自動化そのものは可能です。それでも人の手に残しているのは、公開する直前の確認だけは人が行うと決めているためです。どこまで自動化するかは、技術的にできるかどうかではなく「どこに人の判断を置くか」で決めるのがおすすめです。

また、サブエージェントは工程ごとに別の作業場を立ち上げて動きます。メイン会話のコンテキストは圧迫しない一方、作業場が増えるぶん全体のトークン消費は多くなります。

1つのセッションで全部やる場合に比べて処理が増える点は、理解しておく必要があります（具体的にどれくらい増えるかは環境や記事によって変わります）。

作ってみた感想と今後の課題

率直な感想として、求めている品質の文章が1回で出てくることはありませんでした。この記事も、納品後に通して読んで、気になった表現の修正指示を何十回と出しています。

ただ、この往復は無駄になりません。指摘した内容は書き方のルールとしてCLAUDE.mdやチェック担当の定義ファイルに追記していくため、フィードバックを反映するほどチームの精度が上がっていきます。1回で完璧な記事を求めるのではなく、記事を重ねながらAI社員を育てていく仕組みだと考えています。

今後の課題は図解です。今のillustratorはSVGで図を自作する構成のため、体制図やフロー図のような整理された図は作れますが、イラストを使った表現力のある図解は苦手です。ここは画像生成AI（OpenAIのGPT Image 2など）との連携を検討しています。

公式のAgent Teams機能との違い

Claude Codeには「Agent Teams（エージェントチーム）」という公式機能もあり、名前が似ているので混同されがちです。結論から言うと、この記事で紹介したチーム（カスタムサブエージェント＋PMスキル）と、公式のAgent Teamsは別物です。

Agent Teamsとは、複数のClaude Codeを同時に動かし、1つのチームとして協調させる仕組みです。そのうちの1つがリーダー役になり、残りはメンバー役として動きます。メンバー同士は直接メッセージをやり取りでき、共有のタスクリストをもとに自分たちで作業を調整しながら進めます。

Agent Teamsは実験的機能で、デフォルトでは無効です。使うには環境変数 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS を 1 に設定して有効化します。実験段階のため仕様の変更が続いており、ここで書いた内容も2026年7月時点のものです（今後変わる可能性があります）。

今回のチームとの違いを整理すると次のようになります。

どちらを選ぶかの目安はシンプルです。司令塔が工程を管理する定型作業なら、この記事のようなサブエージェント＋スキルの構成が扱いやすいです。逆に、メンバーが自律的に相談しながら進める動き方を試したいなら、Agent Teamsが向いています。

記事制作のように工程と担当がはっきり決まっている仕事では、司令塔を1か所に固定するハブ型のほうが崩れにくいと感じています。

よくある質問

Q. サブエージェントからさらにサブエージェントを呼べますか？

A. 呼べます。Claude Code v2.1.172以降は、サブエージェントの設定に Agent ツールを持たせれば、そこからさらに別のサブエージェントを呼び出せます（最大で深さ5まで）。ただし今回のチームは、あえて6人全員に Agent ツールを渡さず、社員が別の社員を呼べないようにしています。指揮をPM（メインセッション）に集約したほうが、誰が何をしているかを把握しやすく、指揮系統も乱れにくいためです。

Q. トークン消費（料金）は増えませんか？

A. 使い方しだいです。サブエージェントは別の作業場で動き、結果の概要だけをメイン会話に返すので、メイン会話のコンテキスト自体は圧迫しません。一方で、作業場を立ち上げるたびにトークンを使うため、全体の消費量は増えます。1つのセッションで全部やるより手数が増えるとイメージしておくとよいでしょう。具体的にどれくらい増えるかは環境や記事によって変わります。

Q. 記事作成以外の業務にも使えますか？

A. 応用できる場面は多いです。サブエージェントは調査・レビュー・実装などを分担させる用途に向いているので、工程と担当がはっきり分かれる定型作業なら、同じように「PM＋担当チーム」の形に置き換えられます。ただし、扱う内容によって最適な役割分担は変わるため、この構成をそのまま当てはめてもうまくいくとは限りません。まずは自分の作業を工程に分けてみるところから始めるのがおすすめです。

まとめ

今回は、1つのAIに全部やらせず、PM（スキル）＋担当ごとのサブエージェントというチームに分ける構成で、記事作成を自動化しました。ポイントを振り返ります。

まずは /pm のような司令塔スキルを1つ作り、担当のサブエージェントを1〜2人から試してみてください。仕組みが回るようになれば、この記事を作った6人体制のように、担当は少しずつ増やしていけます。

スキルとサブエージェントの違いをあらためて整理したい方は、こちらの記事もどうぞ。

本文で紹介した仕様の出典は、次の公式ドキュメントです。

サブエージェント（Claude Code公式ドキュメント）

スキル（Claude Code公式ドキュメント）