subagent はどれくらい token を余計に使うのか？multi-agent のコストと使い分け

Sun, 31 May 2026 14:17:42 +0800

subagent や multi-agent ワークフローを使うと、通常は token 使用量が増えます。問題は「増えるかどうか」ではなく、どれくらい増えるのか、そして並列化による速度や安定性がその追加コストに見合うかどうかです。

小さなタスクなら、メイン agent がそのまま処理するほうがたいてい安く済みます。subagent が価値を発揮しやすいのは、タスクを明確に分割できる場合や、独立したレビューが必要な場合です。

subagent は安い並列スレッドではない

subagent を初めて見ると、「並列スレッド」のように考えがちです。メイン agent が一部を処理し、subagent が別の一部を処理すれば速くなるので、効率も良いはずだ、という見方です。

しかし実際には違います。subagent も独立したモデル呼び出しです。タスク説明を読み、コンテキストを理解し、ファイルを読み、問題を分析し、結果を出力します。つまり、メイン agent の無料コピーではなく、追加の推論経路です。

そのため、subagent を使うかどうかの判断軸は「並列化できるか」ではありません。「並列化による時間短縮や品質向上が、追加 token コストに見合うか」です。

なぜ token が増えるのか

subagent の呼び出しでは、通常次の部分で token が追加で使われます。

メイン agent が subagent に渡すタスク説明；
subagent に渡されるコンテキスト；
subagent 自身が読むファイルや分析内容；
subagent の推論と出力；
メイン agent による結果の確認、統合、検証。

複数の agent が同じ大きなファイルを読むと、重複コストはさらに目立ちます。コードベース分析、長文ドキュメント翻訳、バッチでのコンテンツ整理では特にそうです。分割の仕方が悪いと、同じコンテキストを何度も理解するために token が使われます。

コンテキストの重複読み込みが最大の token 浪費

subagent の本当の無駄は、「agent を 1 つ増やしたこと」そのものではなく、複数の agent が同じ資料を何度も読むことです。

たとえば 6 本の記事を処理するタスクがあるとします。4 つの agent がそれぞれ最初にサイト構造全体、スキル文書全体、記事一覧全体を読んでから小さな部分だけを処理するなら、その並列化は高くつきます。より良い方法は、メイン agent が先に境界を決め、各 subagent には担当する記事ディレクトリだけを読ませることです。

token を節約しやすい分割は、だいたい次の形です。

各 agent が 1 つの明確なディレクトリだけを担当する；
subagent に渡すコンテキストをできるだけ短くする；
複数の agent に同じ探索を繰り返させない；
各 agent に全量レビューをさせるのではなく、メイン agent が最後に一括で確認する；
スクリプトで一括チェックできる部分は、複数 agent に繰り返し確認させない。

つまり、subagent のコスト管理で重要なのは数ではなく境界です。

どれくらい増えるのか

以下はおおよその目安です。実際の消費量は、コンテキスト長、ファイルサイズ、タスクの複雑さ、agent 数によって変わります。

シナリオ	token 増加
1 つの subagent が小さなタスクを処理する	約 `1.2x - 2x`
2-4 個の agent が分割しやすいタスクを並列処理する	約 `2x - 5x`
複数 agent が大量のファイルを読み、長い分析をする	`5x+` になる可能性
メイン agent と subagent が同じ大きなファイルを繰り返し読む	最も分かりやすい無駄

これは厳密な課金式ではなく、経験的な目安です。実際には、各 agent が全文を読む必要があるか、長い推論が必要か、追加コンテキストを何度も待つかによって変わります。

token を節約しやすい subagent タスクの書き方

タスク説明が広すぎると、subagent は自分で探索し始めやすくなり、token 使用量も増えます。より安く済ませるには、境界を明確に書きます。

良い subagent タスクには、次の情報を含めるべきです。

処理してよいファイルやディレクトリ；
読み取り専用のファイルと、書き込み可能なファイル；
既存ファイルを上書きしてよいか；
date、slug、aliases など保持すべきフィールド；
最終報告に含める内容；
フルビルドを実行しない、無関係なファイルを編集しない、など不要な作業。

翻訳タスクなら、「記事を多言語に翻訳して」とだけ書くのはよくありません。より省 token な指示は、「content/post/2026/05/240 だけを処理し、index.zh-cn.md を読み、欠けている index.en.md、index.zh-tw.md、index.ja.md、index.es.md だけを作成し、既存ファイルはスキップし、date と slug を保持する」です。

この指示は少し長くなりますが、subagent の推測や重複探索を減らせるため、全体では安くなることが多いです。

言語や手順ではなく、ファイル/ディレクトリで分けるほうが安い

記事の一括翻訳では、「記事ディレクトリ」単位で分けるほうが、「言語」単位で分けるよりたいてい良いです。

たとえば 6 本の記事それぞれに英語、繁体字中国語、日本語、スペイン語版を作る場合、1 つの agent に 1 本の記事ディレクトリ内の全言語を任せるほうが、1 つの agent に全英語、別の agent に全日本語を任せるよりおすすめです。

理由は単純です。1 本の記事の front matter、コードブロック、リンク、表、意味的な文脈は一度読めば済みます。言語単位で分けると、複数の agent が同じ原文を繰り返し読むため、token が増えます。

同じ考え方はコード作業にも当てはまります。「まず分析、次に実装、最後にテスト」のような手順単位ではなく、モジュール、ディレクトリ、コンポーネント単位で分けるほうがよいです。手順単位の分割では、各 agent が同じコンテキストを読み直しがちです。

どんな場合に使う価値があるか

subagent の価値は主に 2 つです。並列化と独立した視点です。

向いている場面は次のようなものです。

複数記事の一括翻訳；
独立して編集できる複数ディレクトリ；
フロントエンド、バックエンド、テストを明確に分担できる作業；
1 つの agent が実装し、別の agent がリスクレビューをする場合；
高リスクな変更で第二の視点が必要な場合。

このようなタスクでは token は増えますが、全体の所要時間が大きく短くなることがあります。また、各 agent が自分の担当範囲に集中できます。

レビュー用 agent を 1 つ使う価値がある場合

レビュー用 agent は常に必要なわけではありません。リスクが高い、影響範囲が広い、メイン agent が細部を見落としやすいタスクに向いています。

レビュー agent を検討する価値があるのは、たとえば次の場合です。

ログイン、決済、権限、データ削除に関わる変更；
多言語コンテンツがカテゴリ、URL、内部リンクに影響する場合；
大きなリファクタリング後に独立した回帰リスク確認が必要な場合；
ユーザーが code review やリスクレビューを明示的に求めている場合；
メイン agent が実装済みで、境界条件を第二の視点で確認したい場合。

逆に、単一ファイルの小さな修正、タイトル調整、簡単な front matter 修正、コマンド 1 つの実行では、レビュー agent を追加する価値はあまりありません。メイン agent の自己確認で十分です。

使う価値が低い場合

subagent が向いていない場面もよくあります。

単一ファイルの小さな修正；
簡単な Q&A；
コマンドを 1 つ実行するだけ；
変更範囲がとても小さい；
タスクを明確に分割できない；
subagent がメイン agent からの追加コンテキストを何度も待つ必要がある。

このようなタスクで subagent を使うと、たいていはオーバーヘッドが増えるだけです。メイン agent が直接処理するほうが速く、token も節約できます。

私のデフォルト戦略：token 節約を優先し、リスクがあるときだけレビューを追加する

token をできるだけ節約したいなら、次のような保守的な戦略が使いやすいです。

小さなタスク：subagent は使わない。
中程度のタスク：subagent は使わない。
大量タスク：ユーザーが明示的に並列化を求めない限り、デフォルトでは subagent を使わない。
高リスクなタスク：安定性のために、レビュー用 agent を 1 つ追加することを検討する。

この戦略は並列速度の一部を諦めますが、コンテキストの重複読み込みと重複推論による token 消費を減らせます。

タスクが大きくても高リスクでなければ、まずはスクリプト、バッチチェック、ローカルの構造化処理を優先します。複数 agent を入れるのは、分割が非常に明確な場合や、ユーザーが並列化による高速化を明示的に望む場合に向いています。

よりバランスの取れた戦略

コストを抑えつつ並列化も完全には捨てたくない場合は、次の折衷案が使えます。

デフォルトではメイン agent が直接処理する；
ファイルまたはディレクトリ単位で明確に分割できる場合だけ subagent を検討する；
subagent は自分の担当ファイルだけを読む；
複数 agent に同じ大きなファイルを同時に読ませない；
メイン agent が最後に key fields、テスト結果、Git diff をまとめて確認する；
高リスクなタスクだけ独立したレビュー agent を追加する。

これにより、「並列化のための並列化」を避けられます。subagent は明確な速度または品質の目的に使うべきで、デフォルト動作にするべきではありません。

まとめ

subagent と multi-agent ワークフローは必ず token 使用量を増やします。1 つの subagent なら少し増えるだけのこともありますが、複数 agent を並列で動かすとコストは何倍にもなり得ます。

使う価値があるかどうかはタスク次第です。作業を明確に分割できる場合や、リスクが高く独立レビューが必要な場合は、追加 token に価値があります。一方、単一ファイルの小さな修正、簡単な Q&A、通常のチェックなら、メイン agent が直接処理するほうが安く済みます。

一言で言えば、小さなタスクでは token を節約し、大きなタスクでは分割境界を見極め、高リスクなときだけ安定性のために追加 agent を使う、ということです。

コスト最適化 on KnightLiブログ