Claude Codeのサブエージェントを25個作った結果｜自動で走らせるのをやめた

七月に、AIひとりに全部やらせるのをやめた話を書いた。

役割ごとに「係」を分けて、それぞれ別の仕事をさせる、という話だった（1体のAIに全部やらせるのをやめた話）。
あれから四十日ほど回して、結論がひとつ変わった。

係は、増やせば増やすほど効くわけではなかった。
むしろ、増やしたせいで働かなくなった係のほうが多い。

いま、係は25個ある

数えてみたら、ちょうど25個だった。

内訳はこうなっている。
コーディングの検品が4つ（社内規約の照合、レスポンシブの実測、W3CとCore Web Vitals、カンプとのずれ）。
自作CMSまわりが12（バグ探し、セキュリティ監査、投稿・デザイン・権限・API・プラグインといった機能ごとの相談役）。
資料作成の検品が4つ（体裁、中身、ファイルが壊れていないかの実ロード、事実の裏取り）。
Webデザインが4つ。
それに提案書の専用が1つ。

使うモデルもばらばらにしてある。
20個は軽いモデル、3個は文章の判断が要るので別系統のモデル、残り2個だけ重いモデルにしている。
判断の重さと料金は比例するので、全部を重いモデルにすると一回の検品で驚くような金額になる。

25個作って、何が起きたか

正直に書くと、三つ困った。

ひとつ目は、単純に高いこと。
作業が終わるたびに係が全員動くと、その作業本体より検品のほうが高くつく日が出てくる。
一日に何度も区切りが来る仕事だと、これがそのまま効いてくる。

ふたつ目は、同じ指摘が三人から出ること。
画像に width と height が無い、という一点を、規約の係とW3Cの係とレスポンシブの係が三方向から報告してくる。
読む側からすると同じ話を三回読まされているだけで、直す手は一回しか動かない。

三つ目がいちばん困った。
数が多いと、本当に危ない指摘が量に埋もれる。
二十件並んだ報告の十七番目に「ここ、SQLの組み立てが危ない」が入っていても、目が滑る。
指摘の数が増えるほど一件あたりの重さが下がるというのは、人間相手のレビューでも起きることだった。

やめたのは「自動で走らせること」だった

係を減らすほうへは行かなかった。
減らすと、必要になった日にその係がいない。

やめたのは、作業が終わるたびに勝手に走らせることのほうだ。

いまは二段にしてある。
段階1は毎回やる自己点検で、これは僕（を動かしている本体のAI）が自分でチェックリストを見て確認するだけ。係は起動しないので、追加のお金はかからない。
段階2が係の出動で、これは僕が「回して」と言った時だけ動く。作業が終わったときに「係を回しますか」と一言聞いてくるので、必要な日だけ頼む。

どの係を呼ぶかの目安も先に決めてある。
フォームや公共系ならアクセシビリティ、集客ページならSEO、JavaScriptが多いならコードレビュー、自作CMS側ならバグ探しとセキュリティ監査、というように。
全部を毎回呼ぶのをやめただけで、一日の消費がはっきり減った。

呼ばれる係と、呼ばれない係の差はどこにあったか

作ってみて意外だったのは、出来のいい係が呼ばれるわけではない、ということだった。

呼ばれるかどうかを決めているのは、係の説明文のほうだった。

係のファイルの冒頭には、その係が何をするかを一行で書く欄がある。
ここに「HTMLをレビューする」とだけ書いた係は、ほとんど呼ばれなかった。
代わりに呼ばれたのは、「LP・コーポレートサイトのフロント実装に対して、余白・色・フォントをカンプと突き合わせる。ドキュメント作成や調査には使わない」というふうに、使う場面と使わない場面の両方が書いてある係だった。

呼ぶ側は、二十五個の中身を全部読んでから選んでいるわけではない。
一行の説明を見て選んでいる。
だから説明文は係の紹介ではなく、選ぶ人のための道しるべとして書いたほうがいい。

「〜には使わない」の一行が、いちばん効いた。

いちばん効いたのは、係に台帳を一枚持たせたこと

これが四十日で見つけた中では、いちばん大きい。

係ごとに「学び台帳」というテキストを一枚用意して、起動したら最初にそれを読ませるようにした。
中身は一行ずつのメモで、こういう書き方をしている。

症状はこうだった、対策はこうする、どこで見つけたか、いまどういう状態か。
それだけ。

チェックリストに載っていない新しい欠陥が出たとき、あるいは僕の直したところをkawabeが直し返したとき、その一行を足す。
同じことが三回出たら、それはもう例外ではないので、台帳から消して恒久ルールのほうへ移す。

この仕組みを入れる前は、同じ種類の事故を三回踏んでいた。
たとえば、SQLに書いた改行の記号を二重に書いてしまって、記事のリード文に記号がそのまま表示された事故。
これは台帳に一行残して、いまは恒久ルールになっている。

AIに毎回同じ説明をしていたのがつらくて一枚のファイルにまとめた話を前に書いたけれど（AIに読ませておく1枚を作った話）、台帳はその発展版だと思っている。
違うのは、こちらは係が自分で書き足していくところ。

作り方そのものは、拍子抜けするほど簡単

ここまで書いておいてなんだけれど、係を作る作業自体は五分で終わる。

設定用のフォルダの中に agents というフォルダを作って、そこに .md ファイルを一枚置く。
ファイルの冒頭に、係の名前、いつ呼ぶかの説明、使うモデル、使わせる道具（ファイルを読むだけなのか、コマンドも打てるのか）を書く。
そのあとに、その係にやってほしい手順を普通の文章で書く。

読むだけの係にしたいなら、道具からファイル書き込みを外しておく。
検品の係が勝手にコードを直しはじめると、何を直したのか追えなくなるので、うちは検品系は全部読み取り専用にしてある。

難しいのは作ることではなくて、呼ばれる条件を決めることと、増えすぎた係をどう黙らせるかのほうだった。

四十日回して、僕が言えること

三つある。

ひとつ、係は「作る」より「呼ばない」を設計するほうが難しい。
作るのは五分、運用の設計は四十日かかった。

ふたつ、説明文に「使わない場面」を書く。
これを書いていない係は、存在していないのと同じだった。

みっつ、台帳を持たせる。
係が経験で太っていく仕組みが無いと、二か月前に決めたチェックリストを永遠に読み続けることになる。

AIに手順を渡すのをやめて、終わったと分かる形のほうを先に書くようにした話（終わったと分かる形）と、根っこは同じだと思う。
こちらが決めるのは、やり方ではなくて、どこで呼ぶかと、どうなったら終わりか。
その二つを決めておけば、あとは向こうが働いてくれる。

納品前のレビューに専属のセキュリティ担当を入れた話（Claude Codeに専属のセキュリティ担当を入れてみた）も、いまは自動では走らせていない。
それでも、いちばん残しておいてよかった係はこれだ。
呼ぶ回数は減ったけれど、呼んだ日の当たりが太い。

係の数を自慢する話ではなくて、二十五個作って十個くらいしか常用していない、という話でした。
それでも、作らなければ「呼ばない」を決めることもできなかったので、遠回りではなかったと思っている。