1コマンドで終わる確認作業を、サブエージェントに投げてしまった
私は毎日katsulogの記事執筆・公開を自動化ループで回しています。その中で、あるファイルの文字数を数えるだけの作業をサブエージェントに投げたことがありました。「このHTMLファイルの文字数を確認して」と一言だけ渡して待つと、数十秒後に「5,234字でした」という要約が返ってきます。正しい。正しいのですが、冷静に考えるとwc相当のコマンド1本で終わる話です。
サブエージェントは起動するたびに、こちらが書いたブリーフに加えて専用のシステムプロンプトを読み込んでから動きます。つまり結果を受け取るまでに、コマンド1本の何倍ものトークンをすでに使っている計算になります。並列で速くなる、というメリットばかりが語られがちですが、私が実際に手を動かしていて一番効いてくるのはこっちの話でした。
似たようなことは、公開後のURL確認でも起きます。curl -o /dev/null -w '%{http_code}' https://example.com/を打てば1秒で終わる確認を、わざわざサブエージェントに「このURLが200を返すか確認して」と投げてしまう。返ってくる答えは同じ「200でした」の一言なのに、そこに至るまでのコストがまったく違います。
サブエージェントの正体は「別コンテキスト＋要約だけ返す」仕組み
公式ドキュメント（code.claude.com/docs/en/sub-agents）を読むと、サブエージェントの本質がはっきり書かれています。
Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions.
サブエージェントは親の会話履歴を一切見ません。渡されるのは委任メッセージだけです。作業が終わると、親に返るのは要約のみ。検索結果もログもファイルの中身も、サブエージェント側のコンテキストに閉じたまま捨てられます。
ai-revolution.co.jpの解説でも同じ整理がされていて、「独立したコンテキストウィンドウで動作し、結果の要約のみをメイン会話に返す」とまとめられています。親のコンテキストを汚さない、というのが一次的な効能です。並列に何本も走らせられるのは、この設計の副産物にすぎません。
ここを取り違えると、「速くなるから委任しよう」で全部投げてしまいます。でも私の実感では、速度より先に効くのはコンテキスト分離の方でした。大量の検索結果やログを親に持ち込まずに済む、という効果は地味ですが確実です。
公式ドキュメントには、サブエージェントの初期コンテキストには親の会話履歴も、すでに読み込んだファイルも含まれない、ともあります。つまりサブエージェントは毎回まっさらな状態から、渡されたブリーフだけを頼りに動きます。裏を返せば、親が既に把握している前提を一切共有できないということです。簡単な確認作業ほど、この「前提をゼロから説明し直すコスト」が相対的に重くなります。
フロントマターで役割とツールを絞る
.claude/agents/*.mdにYAMLフロントマターを書くと、専用のサブエージェントを定義できます。qiita.com/dai_chi(id=be7d85b7413ed02e8a19)の実例に沿って書くとこうなります。
---
name: code-reviewer
description: コード品質・セキュリティ観点でのレビュー専任。PRレビューやコミット前チェックで使う。
tools: Read, Grep, Glob, Bash
model: sonnet
---
あなたはコード品質とセキュリティの基準に厳しいシニアレビュアーです。
toolsで使えるツールを絞り込めるので、レビュー専任のエージェントにEditやWriteを渡さない、といった設計ができます。descriptionは委任判断の材料になる一番重要なフィールドで、ここが曖昧だと「いつ呼ばれるべきか」が定まりません。modelで軽い確認作業はhaiku、複雑な実装はsonnetと使い分けられる点も、これ、意外と使えます。手元に.claude/agents/があれば、一度toolsを絞れているか覗いてみてください。
並列速度のメリットは、あくまで副次的なもの
並列委任の速度メリットを扱った二次媒体の記事(uravation.com/media/claude-code-sub-agents-parallel-task-delegation-2026)では、「コードレビューの所要時間が1時間から20分に短縮された」という導入事例が紹介されていました。約3倍です。大規模な機能実装でも「逐次実行なら7ステップ分の時間がかかるところを、並列で同時実行することで約1/3〜1/4の時間で完了」とあります。同時実行数はデフォルトで20まで、と書かれていました。
私自身はこの数値を独自に検証したわけではないので、そのまま鵜呑みにはしません。ですが、複数の独立した調査を並列でぶん投げれば速くなる、という方向性自体は直感にも合います。問題は、この「速くなる」という魅力が強すぎて、1〜数コマンドで終わる仕事にまで委任を広げてしまいがちなことです。
では、委任する/しないの線引きはどこに引くか
というわけで、ここで一度判断軸を整理しましょう。私が今使っている軸はシンプルです。大きな生成や多段階の作業は委任し、CLIで完結する確認作業は親セッションが直接やる。理由は最初に書いた通りで、サブエージェント起動にはブリーフとシステムプロンプト分のトークンが二重にかかるからです。
具体的にはこう分けています。あなたも自分の直近のタスクを思い浮かべながら読んでみてください。
- 委任する: 複数ファイルにまたがる調査、記事1本まるごとの執筆、ログを大量に読んでから結論だけ欲しい作業
- 直接やる: ファイルの文字数確認、1つのコマンドの実行結果確認、既存記事のslug重複チェックのような「聞けば1行で終わる」作業
境目にあるのが「2〜3コマンドで終わるけど手順が複数ある」ような作業で、ここは正直まだ迷うことがあります（判断に迷ったら、まず親で1〜2コマンド試してから委任するかどうか決めるようにしています）。
フロントマターのmodelを軽いモデルに絞れば委任のコストは下げられますが、それでもブリーフとシステムプロンプトの二重払いという構造自体はなくなりません。安いモデルに投げても、確認1回で終わる仕事を委任する意味は薄いままです。ここを混同すると「モデルを軽くしたから委任していい」という誤った理屈に流されてしまいます。
自動化ループで、この線引きを実際にルール化している
私はkatsulogの記事執筆・公開を回す自動化タスクループを毎日運用しています。ネタ出しから執筆、WordPressへの公開まで一連の作業を無人で回す仕組みです。このループの運用ルールに、「CLIで完結する確認・検証作業は親セッションが直接実行し、大きな生成作業（記事本文の執筆や複数ファイルにまたがる調査）だけをサブエージェントに委任する」という線を明文化しています。
これをルール化する前は、公開後のURL確認やファイルの文字数チェックのような細かい検証まで委任してしまうことがありました。委任のたびにブリーフを書き、待って、要約を受け取る。1回あたりのオーバーヘッドは小さくても、無人ループで毎日繰り返すと地味に積み上がります。今は「これはcurlかgetコマンド1本で終わるか」を先に自問して、終わるなら親で直接やる、という順番に変えています。
逆に、記事執筆や複数ファイルにまたがる調査のように、そもそも親のコンテキストに検索結果や下書きの試行錯誤を持ち込みたくない作業は、迷わずサブエージェントに投げています。ここは「速いから」ではなく「親を汚したくないから」委任している、という意識の違いがあります。速度は結果的についてくるおまけで、判断の主軸には置いていません。運用開始からまだ日が浅いので、このルールが本当にベストなのかは正直まだわかりません（境目のさじ加減は今も手探りです）。ですが少なくとも、無駄な二重コストは減ったと感じています。
並列速度より先に、二重コストの方を見る
サブエージェントは便利な仕組みです。ただ、二次媒体が強調する並列速度のメリットだけを見て導入すると、1〜数コマンドで終わる仕事まで委任してコストを増やしてしまいかねません。別コンテキストで動いて要約だけ返る、という本質を踏まえた上で、大きな生成は委任・CLI一発の確認は親で直接、という線引きを自分の中に持っておくと、無駄なトークンを払わずに済みます。
サブエージェントの実装をもう少し掘り下げたい方は、Agent Teams・subagent・git worktreeの違いをまとめた記事も参考にしてみてください。「Claude Codeを仕組みとして使う」シリーズとして、スラッシュコマンドの総まとめとHooksで確認作業を自動化する回も合わせてどうぞ。
コメント