Claude Codeにサブエージェント機能が追加されてすぐ、使い始めました。
それから数ヶ月が経ちます。
最初は「何でも任せれば楽になる」と思っていました。
結果として、うまくいったものと派手に失敗したものが半々くらいです。
この記事では、実際にサブエージェントを運用してきた中で見えてきた「任せていいこと」と「任せてはいけないこと」の境界線を共有します。
私の使い方：記事制作パイプライン
まず前提として、私がサブエージェントをどう使っているかを説明します。
記事の構想から叩きの作成までを、5つのサブエージェントに分担しています。
出来上がったものをバンバンリライトやプロンプトを修正しながら何度か生成して、その上でリサーチして付け足して・・・公開までいく感じです。
※たぶん生成されたものをそのまま使っているのは多くて3-4割くらいです。（1回の出力でというのはほぼないです）
- インタビュアー — 記事のテーマについてヒアリング
- SEOストラテジスト — キーワード選定と構成提案
- ゴーストライター — 記事本文の執筆
- エディター — 文体・構成・事実関係の最終チェック
- ビジュアルプランナー — アイキャッチ画像の企画
メインのClaudeが司令塔として、各エージェントの結果を次のエージェントに受け渡していく流れです。
この仕組みの全体像は4機能の使い分けガイドで解説しています。
任せてうまくいったもの
インタビュー（ヒアリング）
これは最も成功した委託先です。
「この記事で伝えたいことは何ですか？」「読者は誰ですか？」とClaudeに聞かれながら、自分の考えを整理していく。
毎回質問の角度が変わるし、こちらの回答に応じて深掘りの方向も変わります。
これはまさに「考えさせたい」仕事です。
定型処理では絶対にできない、対話を通じた思考の引き出し。
サブエージェントの独立したコンテキストが活きる場面でした。
編集・校正
書き上がった記事を別の視点で見直してもらう。
これも毎回判断が変わる仕事です。
面白いのは、サブエージェントが自分（ゴーストライター）の出力を客観的に見られること。
メインのClaudeが書いた文章をメインのClaude自身がレビューするより、コンテキストが分離されたサブエージェントの方が「他人の目」に近いレビューができている気がします。
SEO戦略
キーワードの選定、競合分析、構成の提案。
これも文脈によって判断が変わる仕事です。
同じテーマでも、既存記事の状況やターゲット読者によって最適な戦略は異なります。
ただし、ここには一つ注意点があります。SEO戦略は入力情報の質に大きく依存するということです。
インタビューの結果が浅ければ、SEO戦略も表面的になります。
サブエージェントは与えられた情報の範囲でしか考えられません。
ツールを使ったりして自分で実際に調べたり選定したものをベースに渡す感じです。
任せて失敗したもの
失敗1：定型チェックをサブエージェントに任せた
最初、記事のフォーマットチェック（見出しの階層、リンクの形式、front-matterの必須項目）をサブエージェントに任せていました。
結果は「無駄に重い処理」でした。
Task toolでコンテキストを分離して、エージェントを起動して、結果を受け取って……。
やっていることは「決まったルールに沿ったチェック」なのに、サブエージェント経由にすることでオーバーヘッドだけが増えました。
これはスキルにすべき仕事でした。
※最初はスキルはなかったのですが。
手順が決まっていて、毎回同じ結果を期待する処理。
「明日もう一回やったとき、同じ結果を期待する？」と自問すれば、答えはYESです。
失敗2：エージェントを細かく分けすぎた
「役割分担すれば効率的」と考えて、リサーチ専門、ファクトチェック専門、メタデータ生成専門……と細かくエージェントを増やした時期がありました。
管理が大変になりました。
各エージェントの定義ファイルを更新して、情報の受け渡しを設計して、どのエージェントをどの順番で呼ぶか考えて。
エージェントの管理という「新しい仕事」が増えてしまい、本末転倒です。
今は5つに落ち着いています。
最初から多く作るのではなく、「本当に分離する意味があるか？」を問い直して減らしていきました。
結局最終的なファクトチェックは自分でもやるので、2度手間というか、トークンの無駄使いのようにも思えてしまって。。。
失敗3：すべてを1回で完璧にやらせようとした
サブエージェントに渡すプロンプトを詰め込みすぎた時期もあります。
「SEO最適化して、読者の検索意図を分析して、競合記事を調べて、タイトル案を5つ出して、メタディスクリプションも書いて……」
1回のタスクに詰め込みすぎると、どれも中途半端になります。
サブエージェントにもコンテキストの限界があります。
subagentのトークン爆発を防ぐ方法でも触れていますが、1回のタスクは1つの明確なゴールに絞った方が結果の質が上がりました。
見えてきた境界線
数ヶ月の運用から、こんな判断基準が見えてきました。
サブエージェントに向いている仕事
- 毎回違う判断が求められる（レビュー、戦略、インタビュー）
- 「他人の目」が欲しい（編集、批評）
- 対話の中で答えが変わる（相談、ブレスト）
サブエージェントに向いていない仕事
- 毎回同じ手順で同じ結果を期待する（→ スキルにする）
- チェックリスト的な確認（→ スキルにする）
- 細かすぎて独立させる意味がない（→ メインのClaudeに直接やらせる）
判断の軸をひと言でまとめるなら、「考えさせたいか、考えさせたくないか」です。
「これ、明日もう一回やるとしたら、同じ結果を期待する？」
YESならスキル。NOならサブエージェント。この問いだけで、大体の場合は振り分けられます。
運用してわかったコツ
エージェントの数は少なく保つ
最初から完璧な体制を作ろうとしない。1〜2個から始めて、「これは分けた方がいいな」と感じてから増やす。
CLAUDE.mdが肥大化する前に知りたかった3つのことと同じ原則で、「少なく保つ」が基本です。
1タスク1ゴール
サブエージェントに渡すタスクは、1回に1つのゴールだけ。
「これをやって、ついでにあれもやって」は避ける。タスクが大きすぎると結果が散漫になります。
中間結果は必ず保存する
サブエージェントの出力は、次のエージェントに渡す前にファイルとして保存しておく。
コンテキストが切れたときに途中から再開できるようにするためです。
これがないと、全部やり直しになります。
まとめ
サブエージェントは「何でも任せれば楽になる」魔法の道具ではありません。
任せてうまくいくのは「考えさせたい仕事」。
失敗するのは「考えなくていい仕事」を無理に任せたとき。
この境界線が見えてくるまでに何ヶ月もかかりました。
今はこの5つのエージェント体制で安定して運用できています。
最初は試行錯誤でしたが、失敗から学んだ判断基準があれば、これからサブエージェントを始める方はもう少しショートカットできるかもしれません。
サブエージェントの次の進化形として、Agent Teamsとsubagentの決定的な違いも書いています。
サブエージェント運用で感じていた課題への構造的な回答が見えてきた、という話です。
参考になれば幸いです。
