※本記事にはプロモーション（アフィリエイト広告）が含まれます。
最近「Claude Codeにサブエージェントを作ってみた」って言うと、「それって結局何が変わったの？」ってよく聞かれるの。今日はその実践記録を残しておこうと思う。作り方の手順はもちろん、「これって本当にサブエージェント化したって言えるの？」って自分なりに悩んだ線引きの話も一緒にね。これを読むと、ツールを1個作った段階と、ちゃんと運用が回り出した段階の違いが見えてくるはずだよ。
ふむふむ。くりまろも「サブエージェント」って言葉、なんとなく強そうな響きだけど中身がよくわかってないぞ。
サブエージェントって何？
そもそもサブエージェントって何なのだ？
ざっくり言うと、Claude Codeの中に「専門の助っ人」を1人増やせる機能なの。普段私たちが話しかけているのは「メインのClaude Code」なんだけど、そこに「文章チェックだけやる人」「事実確認だけやる人」みたいに、役割を絞った助っ人を横に置いておけるイメージ。
助っ人には自分専用の作業スペースが与えられていて、そこでどれだけ資料を読み込んでも、私に返ってくるのは「結果まとめ」だけ。だから私とメインのClaude Codeとのやり取りが、細かい調査の跡でごちゃごちゃにならないの。
会話がごちゃごちゃしない…それは地味だけど助かりそうだな。
うん。実は今回私が最初に作ったのは、記事の内容をチェックする「fact-checker」っていう助っ人。くりまろブログの記事化ワークフローの最後の砦にしたくてね。
「エージェントチーム」とは別物です
ここ、実は私も最初こんがらがったんだけど。「AIを何体も動かして自動化してる」って話を聞くと、たいてい思い浮かぶのは「エージェントチーム」っていう別の機能のことなの。サブエージェントとは似た名前だけど、仕組みが違うから先に整理しておくね。
- サブエージェント（今回の話）：助っ人1人に「これやっておいて」と頼んで、結果だけ受け取る。一方通行のお使い。比較的コストが軽い
- エージェントチーム：複数のAIが「チーム」を組んで、お互いに直接相談し合いながら進める。人数が増えるほど消費量も増える、まだ実験段階の機能
似てるようで、全然違う仕組みなんだな。
そうなの。実はうちの塾長(夫)がエージェントチームを試したときの話を別の記事に書いたんだけど、開始から15分足らずでProプランの使用量の上限に達してしまって、その日のうちに解散になったんだって。今回私が作ったのは、そこまで重くない「サブエージェント」の方だから、その点は安心してね。
なぜ「設定ファイル一式」をGitHubで預けることにしたのか
ところで、みかは2台のパソコンで作業してるって前に言ってたな。
そうなの。「自宅と塾用PC、2台を行ったり来たりしてるんだけど、さっき作った助っ人の中身は、ただの文字ファイルなの。だから自分のPCの中に保存して満足してると、塾用PCの方にはそのファイルが存在しないままなのよね。
それで、「作業用のロッカー一式（kurimaro-ai-blog）」をGitHub上に作って、助っ人のファイルをまとめて預けておくことにしたの。
- 作業を始める前に必ず
git pull - サブエージェントを編集したら
git add→git commit→git push
この2つを徹底するだけで、「あれ、こっちのPCには昨日作ったエージェントがない…」っていう事故がなくなった。
なるほど、道具そのものも「持ち運べる」ようにしたわけだな。
実際にfact-checkerサブエージェントを作った手順
手順はそんなに難しくなかったよ。私がやったのはこんな流れ。
- Claude Codeに向かって、自然言葉で「こんなチェックをやる専門の助っ人を作ってほしい」と依頼する
- 「実体験ベースかどうか」「事実に矛盾がないか」「世代的な偏りがないか」「誤字脱字」「既存記事との重複」という、記事のチェックリストを具体的に伝える
- Claude Codeがその場で、名前・説明文・使えるツール・チェック項目の文面をまとめたファイルをすぐに作ってくれる（中身はすべて自動生成されるので、自分でキーボードを打つ場面はほとんどない）
- 中身を一応確認して、言い回しが気になる部分だけ自分の言葉に直す（中身はただのテキストファイル）
- GitHubにpush（保存場所をクラウド上に揃えておく作業。仕組みの詳細は別記事で解説予定）
思ったよりシンプルだな。プログラミングの知識、あんまり要らなそうだ。
助っ人を作るところまでは、そうなの。チェックリストさえ言葉にできれば、あとはClaude Codeが自動でファイルの形にしてくれる。ただ、さっき話したGitでの管理は少しだけ技術寄りの操作が絡むから、そこだけは「新しく覚える一手間」だと思っておいてね。もっと体系的に学びたいという人は、Udemyの関連コースをのぞいてみるのもおすすめ。
「サブエージェント化している」と言えるのはどこから？
ここで私、ちょっと立ち止まって考えたのね。「fact-checkerを1個作った」＝「サブエージェント化した」って言っていいのかなって。
違うのか？
道具を1つ作った段階と、その道具が実際のワークフローに組み込まれて、毎回自然に呼ばれるようになった段階は、やっぱり別だと思うの。私の場合は、記事のHTML変換前に必ずfact-checkerを通す、という手順を自分の中で固定化して、初めて「サブエージェント化した」と言えるかなと感じた。
道具箱に工具を増やしただけなのか、実際の作業フローの一部として組み込まれたのか。ここの線引きは、意外と見落としがちだなと思った。
なるほど…「作った」と「使い続けている」の間には、案外距離があるんだな。
使ってみて感じたメリット・デメリット
実際に使ってみて感じたことも正直に書いておくね。
良かった点：
- 記事チェックのたびに同じチェックリストを手打ちしなくてよくなった
- メインの会話に細かいチェックの途中経過が混ざらないので、記事本文の推敲に集中できる
気になった点：
- 助っ人を呼ぶたびに使用量（トークンと呼ばれるもの）が消費される。使いすぎるとコストがじわじわ効いてくる
- Claude Codeが自動で判断して助っ人に仕事を振る挙動が、思ったタイミングで動かないことがある（「この件はこの助っ人に頼む」と名前を直接指定した方が確実）
- 助っ人はメインの会話内容を引き継がないから、「さっき話してたこと」を前提にした指示は伝わらない。毎回必要な情報をいちから伝え直す必要がある
いいことばかりじゃないんだな。
うん。「専門担当を作れば全部解決」ってわけじゃなくて、コストと手間のバランスを見ながら使うものだなと感じた。
シーバストレースサイトとの比較
もう一つ気づいたのが、サブエージェント化が向いているサイトとそうでないサイトがあるってこと。くりまろブログみたいに記事を継続的に量産していくサイトは、チェックの手順が毎回同じだからサブエージェントとの相性がいい。
一方で、私が別で運営しているシーバストレースサイトは、ロゴや構成を1回作ったら大きくは変わらないタイプ。今回はそっちへのサブエージェント導入は見送ることにしたの。
「繰り返す作業」かどうかが、使いどころの分かれ目なんだな。
まとめ
今回のポイントをまとめると、こんな感じ。
- サブエージェントは、Claude Codeの中に作れる「専門担当」
- 中身はただの文字ファイル。GitHubで管理すれば複数PCでも迷わない
- 「作った」と「ワークフローに組み込まれた」は別物。私は後者になって初めてサブエージェント化したと感じた
- メリットだけでなくコストや振り分けの不安定さも実感として付いてくる
- 繰り返し作業があるサイトほど相性がいい
個人でどこまでできるかの気づきや苦労話は、個人規模でClaude Codeのサブエージェントを使ってみた実践記でも書いているので、あわせてどうぞ。
Claude Codeのサブエージェント、もっと体系的に学びたいという人は、Udemyの関連コースをのぞいてみるのもおすすめです。
※本記事はUdemyのプロモーションを含みます。
コメント