Kiro IDE のサブエージェント（general-task-execution）を使った場合と使わない場合でコンテキスト消費量と処理時間を比較してみた
いわさです。
Kiro IDE にはサブエージェント機能があります。
各サブエージェントは独自のコンテキストウィンドウで処理されるので、メインエージェントのコンテキストをクリーンに保つことができます。
Two built-in subagents are available: a context gatherer for exploring projects and a general-purpose agent for parallelizing tasks. Each subagent has its own context window, keeping the main agent context clean.
実際にどの程度の差が出るのか気になりました。
今回は組み込みサブエージェントの general-task-execution を使って、サブエージェントなしの場合と同じタスクを実行し、メインコンテキストの消費量とその他の情報（処理時間なども）を比較してみました。
コンテキスト消費量はチャットパネルで確認出来ます[1]。
今回こちらを確認してみたので紹介します。
実際に確認してみる
検証タスクの設計
サブエージェントの効果を比較するために、インプットとアウトプットを厳密に定義したタスクを設計しました。
まず指定した Web ページに対して以下の処理を行います。
webFetch（mode: rendered）でページ内容を取得する（コンテキスト消費を増やすために redered に）- 取得したページ内容を分析する
sleep 30を実行して30秒待機する- 固定フォーマットで結果を返す
対象ページは以下の6つです。
- https://classmethod.jp （コーポレートサイト）
- https://dev.classmethod.jp （DevelopersIO）
- https://classmethod.jp/services/ （サービス一覧）
- https://classmethod.jp/company/ （会社概要）
- https://classmethod.jp/news/ （ニュース）
- https://classmethod.jp/partner/ （パートナー）
出力結果もコンテキスト安定化のために以下の固定フォーマットで統一します。
## タスク{番号}：{ページ名}
- URL: {URL}
- ページタイトル: {title要素の内容}
- メインメッセージ: {ページの主要キャッチコピーまたは説明文、1文}
- ナビゲーション項目数: {数値}（{項目名をカンマ区切りで列挙}）
- CTA数: {数値}（{CTA名をカンマ区切りで列挙}）
比較パターンは以下の2つです。
- パターンA（サブエージェントなし）：メインエージェントが6ページを順番に処理（webFetch → 分析 → sleep 30 を6回繰り返し）
- パターンB（サブエージェントあり）：6つのサブエージェントにそれぞれ1ページずつ委任（各サブエージェントが webFetch → 分析 → sleep 30 を実行し、固定フォーマットで結果を返す）
パターンAではメインエージェントが6タスク分をまとめて出力し、パターンBでは各サブエージェントが1タスク分を返してメインがまとめてくれるはず。
ただし最終的なアウトプットは同じフォーマットになるはずです。
クレジット消費量を観察するためにモデルは先日登場した GLM 5 で固定化しました。
なお、サブエージェントの利用には Autopilot モード が必要です。
サブエージェントなし（6ページ順次処理）の検証結果
まずはサブエージェントを使わず、メインエージェントに直接6ページの処理を実行させました。
ここでの検証ポイントは、6ページ分の rendered コンテンツがメインコンテキストに展開されることでコンテキストウィンドウ使用がどこまで上昇するかです。
メインエージェントが以下の流れで処理を実行しました。
webFetchで各ページを順番に取得 → 各ページの処理後にsleep 30- 6ページ分の内容がすべてメインコンテキストに展開される
- 6ページ分の結果を固定フォーマットで出力
メインのツール呼び出しは12回（webFetch×6 + sleep×6）でした。
rendered モードにより各ページ 10KB〜17KB のテキストが取得され、6ページ分の内容がすべてメインコンテキストに展開されています。
クレジット消費は 5.5 で、処理時間は 5m 41s でした。
またコンテキスト使用量は Conversation 26%、Total 28% でした。
サブエージェントあり（6つ並列）の検証結果
次に、6つの general-task-execution サブエージェントにそれぞれ1ページずつ委任してみました。
各サブエージェントには同じ固定フォーマットを指定しています。
ここでの検証ポイントは、rendered で取得した大量テキストがサブエージェントのコンテキスト内に閉じ込められ、メインの context usage が抑えられるかどうかです。
メインエージェントは invokeSubAgent を6回同時に呼び出しました。なるほどね、こういう動きするのか。
6つのサブエージェントがそれぞれ独自のコンテキスト内で webFetch → 分析 → sleep 30 を実行し、メインエージェントには各サブエージェントの固定フォーマット出力のみが返却されました。
メインのツール呼び出しは6回（invokeSubAgent×6）です。
6ページ分の webFetch の結果はいずれもメインコンテキストに展開されず、サブエージェントからの固定フォーマット出力のみがメインに入りました。
クレジット消費は 0.78 で、処理時間は 2m 29s でした。
また、コンテキスト使用量は Conversation 16%、Total 18% でした。
さいごに
本日は Kiro IDE の組み込みサブエージェント general-task-execution を使った場合と使わない場合でコンテキスト消費量と処理時間を比較してみました。
まず、メインコンテキストの消費量に明確な差が出ました。
6ページ分の rendered コンテンツをメインで直接処理すると Conversation が 26% まで上昇しましたが、サブエージェントに委任すると 16% に抑えられています。
コンテキスト消費量が増えていくと一般的にエージェントのレスポンス悪くなりますからね。コンテキストとして不要な一時情報はサブエージェント活用すると効果が出そうです。
また、処理時間も 5m 41s から 2m 29s に短縮されました。
独立したタスクを複数抱えている場合、サブエージェントに分散させることで並列処理の恩恵を受けられますね。
一方で、今回想定してなかったのですがクレジット消費についてはサブエージェント使わない場合が 5.5 で、使った場合がなぜか 0.78 になりました。
検証方法が悪かったのか、メインエージェントの分しか見積もりクレジットが確認出来ないのか、もう少し検証してみようかな。クレジット下がる想定はしていなかった。
サブエージェントの利用には Autopilot モードが必要だったり前述の前提条件もあるのですが、タスクの性質によっては一定の効果がでるのでうまく使い分けしたいですね。
次回はカスタムサブエージェントや前述のクレジット消費についての検証も行ってみたいと思います。
