サブエージェントを最初に作ったのは、2025年の秋頃のことでした。当時、4つの技術ブログと2つの読み物系サイト、合計6サイトを並行で運営し始めたばかりで、「全部のリポジトリを毎日のように行き来する自分」を、どうにかして肩代わりしてもらえないかと考えていました。
それから半年。.claude/agents/ の中に並んでいたカスタムサブエージェントは、5つから2つに減りました。「増やしていく」のではなく「絞り込んでいく」という方向に進んだのは、自分でも少し意外でした。今日はその記録を残しておきます。
アーティスト・クリエイターの廣川政樹（Dolice）です。2014年から個人開発者としてアプリを作り続けながら、最近は記事も書く生活をしています。
サブエージェントを「増やせばよい」と思っていた最初の3ヶ月
最初の3ヶ月は、思いついたものを片端から作っていました。
- 記事のSEO監査をしてくれる subagent
- リポジトリの差分から release notes を書く subagent
- 4サイトのスケジュールタスク設定を比較して不整合を見つける subagent
- 古い記事を読んで、リライト候補を出す subagent
- AdMob の eCPM レポートを読んで、メディエーション順位を提案する subagent
.claude/agents/ を開くと、自分でも何を作ったのか覚えていないファイルが5つ並んでいる、という状態になっていました。
「専門家の小チームを抱えている気分」と書けば聞こえはよいのですが、実際の運用ではそんなにきれいに動きませんでした。呼び出した subagent が、思っていたほどの結果を返してこありません。あるいは、自分が直接やったほうが速い。その違和感が、最初の3ヶ月で少しずつ蓄積していきました。
残した1つ目：Explore 相当の「ひたすら読みに行く」エージェント
半年経って残った1つ目は、「ひたすら読みに行く」専門のエージェントです。Cowork に最初から入っている Explore 相当の役割を、自分用に少しチューニングしたものです。
このエージェントが機能した理由は、はっきりしていました。読む対象が広いほど、メインのコンテキストを汚さずに済むという恩恵が、相対的に大きくなるからです。
私のワークスペースには、6サイトのリポジトリ・運営ドキュメント・SEOデータ・スケジュールタスク用の SKILL.md が散らばっています。「この記事はどの subagent でどう書かれているのか」「AdMobのプライオリティ設定はどのドキュメントが正なのか」を辿るとき、メイン側で全部読むとあっという間にコンテキストを使い切ってしまう。専用に切り出した Explore 用 subagent に「広く、浅く、報告だけ持って帰ってきて」と頼むと、メイン側は要約だけを受け取って次に進めます。
半年で気づいたのは、このエージェントを呼ぶときの prompt の書き方を、極端にシンプルに固定したことが効いたという点です。「以下の質問に答えるために必要なら、どこを読んでもよい。ただし、報告は300字以内」。それだけ。役割を絞り、出口を絞ったぶん、機能してくれるようになりました。
残した2つ目：Plan 相当の「設計レビュー専用」エージェント
2つ目は、設計フェーズで「他人の目」を借りるためのエージェントです。
個人開発の難しさのひとつは、設計を他人に見せる機会が圧倒的に少ないことだと思います。アプリの累計5,000万ダウンロードを支えてきた経験は確かにあるのですが、その経験はそのまま、「自分のクセに気づきにくい」という弱点でもあります。
このエージェントには、「私の設計案に対して、私が見落としていそうな観点を3つだけ挙げてほしい」という役割を与えています。提案ではなく、観点。何かを書いてもらうのではなく、自分が見落としているところを照らしてもらう。
実装上のコツは、メインの会話と切り離すことでした。設計案をそのまま会話に流すと、自分の前提が伝わりすぎて、subagent も同じ視点で見てしまいます。subagent には、設計の文書を「初めて読んだ人」として受け取ってもらうために、背景情報をあえて剝がして渡しています。
少し遠回りに見えますが、半年運用するとこちらのほうが自分には合いました。
捨てた3つ：なぜ機能しなかったのか
ここからは正直に、残らなかった3つの話を書きます。
ひとつ目は、SEO監査専用 subagent。これは、メインの作業の最中に subagent から戻ってくる「監査レポート」が、結局はメインで自分が読み込まなければ意味がない、という構造的な問題に気づいて捨てました。subagent が出してきた結論を、メインがそのまま信じて次のアクションに進めない仕事は、subagent に切り出すと二度手間になる、というのが半年での気づきです。
ふたつ目は、release notes 自動生成 subagent。これは、release notes そのものは書けるけれど、「どこまでを今回のリリースに含めるか」の判断はサイト全体の文脈を持っている自分にしかできず、結局メインで書き直していました。範囲決定の判断が分離できない仕事は、subagent ではなく Plan Mode の中で済ませたほうが速かったです。
みっつ目は、AdMob のメディエーション順位提案 subagent。これは別の理由で捨てました。AdMob の管理画面と Claude in Chrome を組み合わせて動かしたほうが、サブエージェント1つで完結させるよりも、私の運用の現実に合っていたからです。「subagent を作る前に、Chrome 連携で済まないかを先に試す」というルールを、ここから自分の中で固めました。
半年で見えた、subagent description の書き方
捨てた3つと残った2つを並べて気づいたのは、description フィールドの書き方が、機能の境目を分けていたということです。
残ったほうの description は、いずれも「何をやらせるか」ではなく「どんなときに呼ぶべきか」を書いていました。逆に、捨てた3つは「○○の専門家」「○○のレポートを作る」のように、役割の説明にとどまっていました。Claude Code のメイン側からすると、「呼ぶべきタイミングが書かれていない subagent」は、結局呼ばれません。
具体例で示すと、残った Explore 用 subagent の description は、こんな形にしてあります。
複数のリポジトリ・ドキュメント・SKILL.md にまたがる事実関係を、
メインのコンテキストを使わずに調べたいときに使う。
報告は300字以内の要約のみで、全文取り込みはしない。
「ときに使う」「ない」というネガティブ条件まで書いておくと、メイン側が呼ぶか呼ばないかの判断を、迷わずできるようになります。
一つの道具を使い切るという感覚
宮大工をしていた両祖父のことを、最近ふと思い出します。手元の道具をいくつも増やすのではなく、一つの道具をていねいに使い続ける人たちでした。鉋（かんな）の刃を毎日研いで、その鉋でしか出せない肌触りで木を仕上げていく。
カスタムサブエージェントについて半年運用してみて、自分が向かっていたのも、たぶん同じ方向でした。新しいエージェントを増やすよりも、残った2つを少しずつ磨き続けるほうが、6サイトの運営という現実に対しては効いています。
これから取り組むこと
直近では、残った2つの subagent それぞれに、「呼ばれなかった日」を記録する小さなログ機構を仕込もうとしています。呼ばれない日が続く subagent は、もう一度 description を見直すサインだ、という運用に変えていく予定です。
カスタムサブエージェントを使い始めたばかりの方には、まず1つだけ作って、3週間ほど運用してみることをお勧めします。3週間経った時点で「これは呼んでよかった」と思える瞬間が3回以上あれば、その subagent は残る側です。なかったら、description を一行書き直すところから始めるとよいかもしれません。
私自身もまだ運用の途中ですが、誰かの参考になれば幸いです。お読みいただきありがとうございました。