サブエージェント、公式ドキュメントも読んだ。でも「結局、コードレビューや並列開発の機能でしょう？」——そう思ってタブを閉じたなら、1つの記事を”5人で”書かせている実例を見てから閉じてください。
結論からお伝えすると、サブエージェントは記事執筆のようなコンテンツ制作の分業にもそのまま使えます。1本の記事を書く作業を5つの役割に分け、それぞれ別のサブエージェントに任せている運用を、ハンドオフの書式まで含めて全文公開します。分業ですべて解決するわけではないので、コストの側面も正直に書きます。
なぜ「1つの会話で全部」がうまくいかないのか
context rot（コンテキスト汚染）の仕組みを1行で
Chroma社の研究チームは、GPT-4.1・Claude 4・Gemini 2.5・Qwen3を含む18の最新モデルを評価し、入力トークン数が増えるほど、単純な検索やテキスト複製のようなタスクでもモデルの信頼性が有意に低下することを示しています。関連情報がコンテキストの中間に埋もれている場合、精度が30%以上低下するケースも報告されています（出典：Chroma「Context Rot: How Increasing Input Tokens Impacts LLM Performance」）。
一般に「context rot（コンテキスト汚染）」と呼ばれるこの現象は、文脈窓がまだ埋まっていない状態でも、トークンを積み増すだけで性能が落ちうるという傾向を指します。「Claude Codeで記事を書くと必ず起きる」と個別に証明されたものではありませんが、手触りのズレは起きやすくなります。
記事執筆で実際に起きうる劣化の具体例
Claude Code公式のコンテキストウィンドウの解説ページには、次のような具体例が示されています。
サブエージェントは独自の別のコンテキストウィンドウで処理するため、大きなファイル読み込みはメインのコンテキストウィンドウから外れます。サブエージェントは6,100トークンのファイルを読み込みましたが、返ってきたのは420トークンの結果だけでした。それがコンテキストの節約です。 出典：Claude Code公式ドキュメント（context-window）
企画・調査・下書き・編集・配信を1つの会話で通すと、調査で読み込んだ大量の資料がそのままメインの会話に積み上がり、会話が長くなるほど「さっき決めた前提を忘れている」「今どの決定に基づいて書いているか」がぼやけやすくなります。役割ごとに別のコンテキストウィンドウに分ければ、各工程は前工程の要約だけを受け取り、必要な情報だけを保持したまま進められます。
5工程に分けるという発想
5体それぞれの役割
コンテンツ制作を、次の5つの役割に分解します。
- Strategist：テーマと読者像から、刺さる角度・フック・構成・書かないことを決める
- Researcher：Strategistのブリーフを受け取り、一次情報・主要事実・反証データを集める
- Writer：ブリーフとリサーチパックを入力に、フルドラフトを書く（編集はしない）
- Editor：ドラフトを受け取り、削る・フックを磨く・締めを整える
- Publisher：編集済みドラフトを受け取り、プラットフォーム最適化と最終出力をする
Claude Code公式のsub-agentsドキュメントでは、サブエージェントについて次のように説明されています。
サブエージェントは、特定の種類のタスクを処理する特化したAIアシスタントです。サイドタスクがメイン会話に検索結果、ログ、または再度参照しないファイルコンテンツで溢れかえる場合に使用します。サブエージェントはそのタスクを独自のコンテキストで実行し、概要のみを返します。 出典：Claude Code公式ドキュメント（sub-agents）
各サブエージェントは、カスタムシステムプロンプト・特定のツールアクセス・独立した権限を備えた独自のコンテキストウィンドウで実行される、とも明記されています。役割ごとに設定ファイル（.claude/agents/または~/.claude/agents/にYAML＋Markdownで定義）を分けることで、この独立性が実現します。
大事な原則が1つあります。各担当は「前工程の出力だけ」を見るという設計です。Writerは、Strategistがどんな試行錯誤を経てその角度にたどり着いたかを知りません。見えているのは前工程の成果物だけ。この「知らないからこそ客観的になれる」構造が、分業の効き目の中心です。
なぜ5体である必要があるのか
5つに分ける根拠は「多いほうが良さそう」ではありません。実運用のガイドラインでは、分業が効くのは5工程に分解できる中〜長タスク（記事・提案書・週次レポート・意思決定メモなど）であり、1通のメールや3行のチャット返信のような短タスクにはオーバーヘッドが過多になる、という線引きが明記されています。
役割を分けることはタダではありません。Anthropic公式のマルチエージェント研究システムの解説では、エージェントの利用はチャット比で約4倍、マルチエージェントシステムでは約15倍のトークンを消費すると述べられています(出典：Anthropic公式「How we built our multi-agent research system」)。同記事は、コーディングのように密結合したタスクには現行のマルチエージェントシステムは適していないとも明言しています（詳細は後述）。
実践方法｜ハンドオフ・プロトコルの書き方
5つの役割を分けただけでは不十分です。前工程の出力をどう受け取るか、ハンドオフの書き方まで決めておかないと「なんとなく前の会話を見て察する」に戻り、コンテキストが混ざります。
最初に、テーマ・想定読者・掲載媒体をまとめた入力を1つ用意します。Strategistはこれだけを受け取ってスタート。「この1ファイルを読めば着手できる」状態にしておくのがポイントです。
役割ごとに設定ファイルを用意し、/agents content-strategistのように名前を指定して順番に呼び出します。Claude Code公式では、自然言語での指定や、@でタイプアヘッドから選択する呼び出し方が案内されています。後者は「特定のサブエージェントが実行されることが保証される」明示的な方法です。
各工程の完了時、次の担当には次の5項目を構造化して渡します。
“`
ハンドオフ
- シーケンス上の位置：（例：Researcher → Writer への引き継ぎ）
- 前工程が完了したこと：（例：一次情報の実取得・主要事実の整理が完了）
- 主要決定事項：（例：この角度で書く、この数値を採用する）
- 未決の問い：（例：ここはまだ確認が取れていない）
- 次工程への申し送り：（例：この反証は必ず本文で開示すること） “`
次の担当は、この5項目とその成果物ファイルだけを見て着手します。前工程がどんな試行錯誤をしたかを知る必要はありません。
一度作った役割定義は、運用しながら育てます。同じ指摘を繰り返し受けた気づきを、その都度該当の設定ファイルに書き足す。最初から完璧を狙わず、運用してから直す順番のほうが現実的です。
実際にやってみて分かったこと（事実のみ）
この5工程の分業は、実際に1本の記事（CLAUDE.mdの書き方をテーマにした別記事）で最初から最後まで通しています。Researcherの一次情報調査とSERP空白確認から始まり、Strategistのブリーフ作成、Writerの全文化(5,486字)、Editorの圧縮(-23.5%・4,332字)、Publisherの下書き作成という順で進みました。この1本での実績であり、「毎回この圧縮率になる」という一般化はできません。複数本の平均値の統計はまだなく、あくまで1件のサンプルです。
よくある失敗
ハンドオフを省略し「前の会話を見ればわかるだろう」で済ませると、結局コンテキストが混ざります。5項目を構造化して渡す手間を惜しむと、分業の意味そのものが薄れます。
もう1つ正直に開示したい反証があります。マルチエージェントのオーケストレーションに関する実務解説では、エージェント間の要約による引き継ぎはトークン数を70〜90%削減する一方、情報損失と1回あたり500ミリ秒〜1.5秒程度の要約遅延を追加するという指摘があります(出典：Augment Code「Multi-Agent Orchestration: A Practical Architecture Without the Buzzwords」）。5つに分ける設計自体が、1人でまとめてやる場合には発生しない「引き継ぎのコスト」を新たに生んでいます。
これらを踏まえると、5工程の分業が向くのは「工程が一方向に流れる中〜長タスク」で、かつ「タスクの価値が増えるコストに見合う」場合に絞られます。短い返信メールや、密結合で細かい文脈を随時すり合わせる作業には向きません。
あなたの仕事も、5つに分ければ引き継げる
発信業務なら、企画(Strategist)・リサーチ(Researcher)・下書き(Writer)・推敲(Editor)・投稿(Publisher)がそのまま使えます。営業業務なら、ヒアリング整理・顧客リサーチ・提案書本文・磨き込み・提出の分業に。サポート業務なら、問い合わせ分類・ナレッジ検索・返信下書き・トーン調整・送信という形になるでしょう。
大事なのは、5つすべてを一度に完璧に作ろうとしないことです。今1つの会話でまとめてやっている作業から、「どこで前提を積み上げ直しているか」を1つ見つけてみる。役割を1つ切り出すだけで、会話は「覚えていてほしいこと」だけを覚えていられるようになります。
切り出した役割に、毎回同じ前提を持たせておく方法は Claude Codeの「Skills」と「CLAUDE.md」とは？ にまとめています。会話のたびに説明し直す手間がなくなります。
気になったことは、お気軽に
この記事のとおりに進めてみて、うまくいかないところがあれば遠慮なく聞いてください。
制作や設定のご相談も、同じ窓口で受けています。
