なぜクリエイティブチームを Claude Code サブエージェント で組むのか
制作の現場で生成AIを使うと、詰まる場所はいつも同じです。コピーの初稿は数分で出ます。ただ、そのあとに続く工程が手作業のまま残ります。続くのはトーンの直しです。ビジュアルの意図とのすり合わせが要ります。表記と事実の校正も残ります。ブランド基準への照合も人が抱えます。工程が一本のチャットに積み上がるので指示が長くなります。途中で前提も崩れます。
サブエージェントは、この工程ごとに別のコンテキストと権限を持たせる仕組みです。公式ドキュメントは「特定の種類の作業を担う専門のアシスタント」と定義しています。各サブエージェントは独自のシステムプロンプトと道具立てを持ちます。結果だけを主の対話に返します。制作の現場に当てはめると、コピー・AD・校正・QA の4役を分けて置く形になります。
人のチームで起きる引き継ぎのロスと、生成AIで起きるコンテキストの肥大化は同じ問題です。片方は担当が分かれすぎて手戻りが増えます。もう片方は担当が一人に集まりすぎて指示が破綻します。サブエージェントは、その中間に「役ごとの独立と要約での連結」を置く設計です。
Claude Code サブエージェント 使い方の基本｜ファイル定義
サブエージェントは Markdown のファイルで定義します。ファイルの先頭に YAML の設定を書き、その下にシステムプロンプトを書くだけです。置き場所は 2 つあります。プロジェクトごとなら .claude/agents/ に置きます。自分の全案件で使うなら ~/.claude/agents/ です。
YAML で指定するのは 4 項目です。name は識別名を書きます。description は呼び出し判定に使う説明文です。tools は使わせる道具、model はモデルを指定します。description は Claude が呼び出し判定に使う材料です。担当する仕事の輪郭を短く書きます。
一度作れば、Claude Code は説明を読んで必要な場面で自分から呼び出します。@code-reviewer のように名前で明示指名することもできます。claude --agent copywriter を使えば、セッション全体を特定の役として立ち上げられます。
役割設計｜クリエイティブチームの4人を分ける
制作の現場を一つのチームに見立てると、担当は大きく4つに分かれます。案件の初稿を書くコピーライター。ビジュアルの方向を決めるアートディレクター。日本語と事実を整える校正者。ブランド基準に照らして最終確認する QA。この4役を、それぞれ独立したサブエージェントとして置きます。
役割を分ける利点は二つあります。一つは、各担当のシステムプロンプトを役の目的に絞れることです。コピーライターにはトーンの規約と過去の当たり案件を持たせます。AD には色と書体と参考ビジュアルの規約を。校正者には禁止語彙と表記統一のルールを。QA にはブランドの承認基準を。役ごとに読み込む前提資料も、別々に切り分けられます。
もう一つは、コンテキストの独立です。サブエージェントはメインの対話から会話履歴を引き継ぎません。校正者が禁止語彙の一覧を全部読み込んでも、メインには残らず結果の判定だけが返ります。長い規約や参考資料を、必要なタイミングだけ全開で使える設計になります。
実装1｜コピーライター サブエージェント
コピーライターは案件の初稿を書く役です。ファイルは .claude/agents/copywriter.md に置きます。
---
name: copywriter
description: 案件のコピー初稿を書く。ブランドのトーン規約と過去当たり案件を必ず先に読む
tools: Read, Grep, Glob
model: sonnet
---
あなたは化粧品と食品のブランドを主に担当するコピーライターです。
案件フォルダにある brief.md、tone-of-voice.md、past-hits/ を先に読み、
訴求角度を3つ提案してから、それぞれに初稿を書きます。
語尾は「です・ます」、一文は45字以内、読点は0〜1個に収めます。
tools に書き込み系を入れていないのは、初稿をメインの対話に返させるためです。確定後は人の判断でファイル化します。呼び出しは「今週の新製品のコピーを copywriter に3案書いてもらう」の一言で通ります。
実装2｜アートディレクター サブエージェント
AD は、書かれたコピーに合うビジュアルの方向を決める役です。写真の切り取り・色・書体・参考ビジュアルの選び方を、案件の規約に沿って提案します。
---
name: art-director
description: コピー案に対して、写真の方向・色・書体・参考ビジュアルを設計する
tools: Read, Grep, Glob
model: sonnet
---
あなたはビジュアル設計を担うアートディレクターです。
案件フォルダの brand-visual.md、reference-boards/、既存の広告素材を読み、
コピー案ごとに、写真の主題・切り取り・光の方向・色の3点・書体を書き出します。
生成モデルに渡すプロンプトの雛形も、日本語と英語の両方で用意します。
コピーライターの初稿が上がったら、続けて art-director に渡します。AD は独立したコンテキストで規約を読み直します。コピーの中身に引きずられず、視覚の設計に集中できます。
実装3｜校正者 サブエージェント
校正者は、日本語の正しさと事実の整合を担う役です。ここは制作の現場で一番落としやすい工程で、担当者の疲労で精度が下がる部分でもあります。
---
name: proofreader
description: 日本語の校正・表記統一・事実整合・禁止語彙のチェックを担う
tools: Read, Grep, Glob, Bash
model: sonnet
---
あなたは編集歴の長い校正者です。
案件フォルダの style-guide.md、ng-words.txt、product-facts.md を全部読み、
提出された原稿に対して、次の観点で修正案を返します。
主語述語のねじれ、翻訳調、一文の長さ、読点の多さ、表記揺れ、
禁止語彙の混入、製品の事実と食い違う記述。
修正はしないでください。指摘の一覧だけを返します。
修正まで自動で当てないのが要点です。校正者の判定は一覧で受け取り、採否は人が決めます。Bash を許可しているのは、grep で禁止語彙を機械的に潰す下拵えを内部でしてもらうためです。
実装4｜品質QA サブエージェント
QA は、最終の一段前で全体を見る役です。コピー・ビジュアル・校正の三つが揃った時点で判定します。出せる状態かどうかをブランド基準に照らします。
---
name: brand-qa
description: ブランドの最終基準に照らして、出稿可否と修正の必要箇所を判定する
tools: Read, Grep, Glob
model: opus
---
あなたはブランドの品質基準を守る QA 担当です。
案件フォルダの brand-approval-criteria.md、legal-checklist.md、
過去の差し戻し記録を読み、提出された一式（コピー・ビジュアル案・校正結果）
に対して、次を判定します。
（1）出せる状態か、（2）差し戻し理由の要点、（3）修正の優先順位。
判定は5段階（承認／軽微修正／中修正／要再制作／不可）で示します。
model を opus にしているのは、判定の妥当性を最優先する役だからです。他の3役は sonnet で速く回します。最後の判定だけを重いモデルに寄せる構成にすると、費用と精度のバランスが取れます。
4人を連続で呼び出す実装
サブエージェントは、続けて呼び出す形で連結できます。指示の書き方は次のような一文で通ります。
「今週の新製品コピーを copywriter で3案出して、それぞれに art-director を当てて、proofreader で日本語を整えて、brand-qa で最終判定して」
Claude Code はこの一文を読み、4人を順に呼び出します。各サブエージェントは独立したコンテキストで動き、要約だけを主の対話に返します。最後は人が QA の判定を見て、進めるか止めるかを決めます。必要なら差し戻し理由もそこで確認します。
並列で走らせることもできます。3案のコピーに art-director と proofreader を同時に当てます。揃った時点で QA に渡す設計です。既定の同時実行上限は20本、入れ子の深さは3階層です。通常の制作規模なら余裕があります。
Skills と Hooks との組み合わせ
サブエージェントは Skills と Hooks と組み合わせると、さらに固い運用になります。Skills は、繰り返し使う手順を Claude が呼び出せる形に束ねた資産です。案件横断で使う「命名規則」や「書き出し設定」は Skill にします。必要なサブエージェントに読ませる形です。
Hooks は、Claude Code が何かをする前後にコマンドを差し込む仕組みです。QA が判定を返した直後に、ファイルを規定のフォルダへ移す Hook を仕込みます。判定と後処理が地続きになります。差し戻しになった案件を、自動で別フォルダに退避する運用も組めます。
整理するとこうです。サブエージェントは「担当者」。Skills は「道具箱」。Hooks は「工程の前後に差し込む定型作業」です。この三層に分けると役割が重なりません。追加や変更もしやすくなります。校正者に新しい NG リストを足すときも、他の役に影響しません。AD の参考ボードを差し替えるときも同じです。「一箇所を直したら別の場所が壊れる」状態を、設計の段階で切り離せます。
運用の注意点｜権限・並列数・独立コンテキスト
サブエージェントを制作の現場に入れるとき、外してはいけない点が三つあります。
一つは、権限を絞ることです。tools の指定は許可制です。書き込み系や外部発信系は必要な役だけに与えます。校正者が原稿を書き換える権限を持たない設計にしておくと、事故が起きません。
二つは、並列の設計です。既定で20本まで同時に走らせられます。ただし外部の生成モデルを呼び出す構成では、API のレート上限に先にぶつかります。案件の規模と外部モデルの上限から、同時実行数を逆算して決めます。
三つは、コンテキストの独立です。サブエージェントはメインの会話履歴を引き継ぎません。案件の前提は毎回、案件フォルダのファイルに書いて渡します。ここを口頭で済ますと、指示のたびに前提が抜けます。案件フォルダを整えることが、そのままサブエージェントの精度に返ります。
案件フォルダに何を置くかは、役ごとに逆算します。コピーライターには brief と過去当たり。AD には参考ボードとブランドの視覚規約。校正者には表記統一と禁止語彙。QA には承認基準と差し戻し履歴。この4つのファイル群を最初に整えれば安定します。あとから役を増やしても、同じフォルダをそのまま参照できます。ファイルの粒度がそろっていることが、連結を安定させる土台です。
クリエイティブチームで運用するときの入口
最初から4役を全部立ち上げず、まず1役から始めるのが順当です。校正者は、案件の規約と禁止語彙が既にあれば一日で組めます。効果が見えやすく、書き換えないのでリスクも低い役です。ここで社内に「サブエージェントは使える」という感触が生まれます。そこから次に QA、その次に AD とコピーライターへと広げていけます。
hub 記事の Claude Code をクリエイティブに使う実装ガイド に、Skills・MCP・Hooks・サブエージェントの四つの拡張の全体像をまとめています。個別の実装は、姉妹記事の Claude Agent SDK でクリエイティブブリーフを構造化する、Claude Code でブランドコンテンツを大量制作する、Claude Code の Hooks でブランド QA を自動化する、Claude Code でブランドトーンを Lint する を参照してください。
FAQ
Q1. サブエージェント と Skills はどう違いますか
A. サブエージェントは独立したコンテキストと権限を持つ「担当者」です。Skills はその担当者が呼び出す「手順書」に当たります。役割の分割はサブエージェント、手順の再利用は Skills で使い分けます。両方を組み合わせると、担当者と道具箱が揃った状態になります。
Q2. どこにファイルを置けば認識されますか
A. プロジェクトごとなら .claude/agents/<name>.md に置きます。自分の全案件で使うなら ~/.claude/agents/<name>.md です。ファイルは Markdown 形式です。先頭に name と description を含む YAML を書き、その下にシステムプロンプトを書きます。
Q3. どのモデルを指定するのが妥当ですか
A. 下拵えの役（コピー初稿・校正）は sonnet が扱いやすいです。最終判定や重い推論の役（QA・意思決定）は opus が向きます。model: inherit を指定すると、呼び出し元のモデルを引き継ぎます。
Q4. コンテキストが独立するのは制作にどう効きますか
A. 長い規約や過去事例を読み込ませても、メインの対話にはその中身が残りません。返るのは結果の要約だけです。メインの対話は指示と判断に集中でき、担当者側は必要な資料を全開で使える設計になります。
Q5. 並列で走らせるとき、上限はありますか
A. 既定で同時20本、入れ子は3階層までです。制作の現場では、外部の生成モデルのレート上限に先に当たることが多いです。案件の規模と外部モデルの上限から、同時実行数を逆算して決めるのが実務的です。