なぜクリエイティブチームを Claude Code サブエージェント で組むのか
制作の現場で生成AIを使うと、詰まる場所はいつも同じです。コピーの初稿は数分で出ます。ただ、そのあとに続く工程が手作業のまま残ります。トーンの直し、ビジュアルの意図とのすり合わせ、表記や事実の校正、ブランド基準への照合。これを同じ画面の中で人が進めることになります。工程が一本のチャットに積み上がるので、指示が長くなり、途中で前提が崩れます。
サブエージェント は、この工程ごとに別のコンテキストと権限を持たせる仕組みです。公式ドキュメントは「特定の種類の作業を担う専門のアシスタント」と定義しています。各サブエージェント は独自のシステムプロンプトと道具立てを持ちます。結果だけを主の対話に返します。制作の現場に当てはめると、コピー担当、AD 担当、校正担当、QA 担当を分けて置く形になります。
人のチームで起きている引き継ぎのロスと、生成AIで起きているコンテキストの肥大化は、じつは同じ問題です。片方は担当が分かれすぎて手戻りが増える、もう片方は担当が一人にまとまりすぎて指示が破綻する。サブエージェント の設計は、この両側の中間に「役ごとの独立と、要約での連結」を置く発想で組まれています。
サブエージェント の基本仕組み
サブエージェント は Markdown のファイルで定義します。ファイルの先頭に YAML の設定を書き、その下にシステムプロンプトを書くだけです。置き場所は、プロジェクトごとに使うなら .claude/agents/、自分の全案件で使うなら ~/.claude/agents/ です。
YAML では、識別名（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階層までです。制作の現場では、外部の生成モデルのレート上限に先に当たることが多いです。案件の規模と外部モデルの上限から、同時実行数を逆算して決めるのが実務的です。