i-Willink
|実践|✍️ i-Willink

subagentの使いどころと避けどころ—一人会社が引いた線

AIにサブエージェントを起動させると賢く見えるが、単一Readや1〜2回の検索に使うのはただのコスト。実際に自分の運用で「使う/使わない」をどう分けているかを正直に書きます。

サブエージェントは、いつ立てて、いつ立てないのか。

答えを先に言います。

「開いた探索」「独立した並列」「メイン文脈の保護」――この3つに当てはまるときだけ立てる。単一ファイルの読み書きや、1〜2回の検索には立てない。迷ったら「自分でできるか?」を先に問う。

これが、社長1名とAI COO(Claude Code)でまわす当社――合同会社i-Willink――が、実際に引いた線です。以下、なぜそう決めたのかを、運用者の立場から正直に書いていきます。

🤔サブエージェントは「賢く見える」から危ない

サブエージェントは並べるほど賢そうに見えます。でも、その見た目こそが判断を誤らせます。

そもそもサブエージェントとは何か。メインで作業しているAIが、独立した子タスクを別のAIに切り出して任せる仕組みです。

調査や探索を丸ごと投げられる。うまくハマれば、たしかに強力です。

問題は、この「丸投げ」が見た目に立派なことです。子エージェントを何体も並べると、いかにも高度なことをしているように見える。

でも実際は、たった1つのファイルを読むだけ、あるいは1〜2回の検索で終わる作業にまで立ててしまう。正直、当社も最初はこれをやりました。※過去の自分です。

返ってくる情報量は変わらないのに、応答は遅く、費用だけがかさむ。効率化の道具のはずが、逆に足を引っぱっていたわけです。

📏当社が引いた線—「使う」3条件

使うのは3つだけ。開いた探索・独立した並列・メイン文脈の保護。観測できる条件で線を引きます。

そこで当社は、社内ガイドライン(subagent-guidelines)に「使う場面」を3つだけ明文化しました。運用してみて、ここまで絞って正解でした。

1つ目は、オープンエンドな探索。10ファイル以上を横断する調査や、3つ以上の独立した切り口が必要な調べものです。

2つ目は、独立した並列タスク。互いに依存せず、同時に走らせても安全な作業群です。

3つ目は、メイン文脈の保護。大量のツール結果がメインの思考を汚してしまう、重いリサーチを隔離したいときです。

逆に言えば、この3つに当てはまらなければ立てない。基準を「重要そうか」ではなく「探索が開いているか・並列か・文脈を守る必要があるか」という観測できる条件に置いた。ここが、当社にとっての分かれ目でした。

🚫避けどころ—単一操作と重複リサーチ

単一のRead・1〜2回の検索・足りている調査。ここに投げたら、遅くて高いだけになります。

避ける場面も、同じくらいはっきり決めています。

単一ファイルの読み書きは、直接Read/Edit/Writeを使う。1〜2回の検索は、直接GrepやGlobを使う。自分で実装できる小さな孤立変更は、自分でやる。

そして、すでに十分な情報がある場面での委譲。これはただの無駄なので、封じます。

当社の運用ルールでは、これを「サブエージェントの過剰起動禁止」という禁則にしています。

なぜ禁則にまで格上げしたのか。放っておくと、AIは「丁寧に見えるほう」へ収束しがちだからです。だからこそ「頼まれたことだけやる」という原則とセットで縛っています。

💸禁則にした理由は、費用と応答時間

立てるたびにAPI費と待ち時間が乗ります。一人会社では、それが時間と請求書に直結します。

なぜ、ここまで厳しくするのか。理由はシンプルです。

「賢さ」ではなく、コストと速度。サブエージェントを1回立てるたびに、コンテキストを分離するためのAPI費と、子タスクが返ってくるまでの応答時間が上乗せされます。

一人会社にとって、この2つはそのまま自分の時間と請求書に跳ね返ります。

だから当社は、判断の順番を固定しました。まず「自分でできるか?」を先に問う。Noならサブエージェント、Yesなら直接実行。

並列化するのも、本当に独立しているタスクだけ。結果が互いに依存するなら、素直に逐次でやります。

🧭なぜこの線引きが効くのか

価値は「重い調査を隔離して要約だけ戻す」こと。隔離するほどの重さがなければ利点は消えます。

この考え方は、当社の思いつきではありません。AIに自分のコンテキストを管理させる、という設計思想を下敷きにしています。

サブエージェントの本当の価値は、重い調査結果をメインの会話から切り離し、メインには要約だけを戻すこと。そうやってコンテキストを綺麗に保てる点にあります。

裏を返せば――切り離すほどの重さがない作業に使えば、その利点はまるごと消えて、コストだけが残る。

この設計思想については、開発元が公開しているコンテキスト管理の解説記事が観測材料として参考になります(Anthropic: Harnessing Claude's Intelligence)。

当社はこれを鵜呑みにはしません。自分の運用で「立てた回/立てなかった回」の手応えを見ながら、3条件と禁則という形に落とし込みました。

🔑まとめ—線を引けば道具になる

高度に見えるかではなく、時間と費用を本当に減らすか。その一点で選べば使い方は素直になります。

サブエージェントは、使いどころを外すと「賢く見えるだけの浪費」になります。当てはめると「メイン文脈を守る強い道具」になります。

当社の線引きはシンプルです。開いた探索・独立した並列・文脈保護の3つだけ使い、単一操作と重複リサーチには使わない。迷ったら「自分でできるか?」を先に問う。

大事なのは、道具が高度に見えるかどうかではありません。自分の時間と費用を、本当に減らしているかどうかです。

あなたのAIも、いま「賢く見えるだけ」で動いていませんか? 一度、自分の線を引き直してみてください。使い方は、きっと素直になります。

開発パートナーを探していますか?

AIでプロダクトを最速で形にしませんか?

最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。

無料で相談する

最新記事をメールで受け取る