本記事は 2026年7月18日 時点における個人の見解を含みます。AIエージェントツールの仕様は急速に変化するため、最新の公式ドキュメントも合わせてご確認ください。
はじめに
Bobなどのエージェント型AIツールを使っていると、SubTask（サブタスク） と SubAgent（サブエージェント） という2つの仕組みに出会います。どちらも「親エージェントがサブの処理単位に作業を委任する」という点では同じに見えますが、細かい部分に違いがあります。
本記事では、両者の特徴・ユースケース・使い分けの方針・そして注意点をまとめます。
利用可能バージョンについて（出典: IBM Bob IDE Changelog）
IBM Bob IDE のサブエージェントとサブタスクは、どちらも バージョン 2.0.0（2026年6月） から利用可能です。
-
サブエージェント：
spawn_subagentで起動 -
サブタスク：
start_subtaskで起動。独立した会話としてUIに表示され、ユーザーが途中から対話できます
また、ドキュメントに記載の 『大規模プロジェクトでの作業』 の 「コンテキスト管理の戦略」 にも登場する機能ですので、積極的に使いたいですね。
SubAgentの仕組み
(ドキュメントからの抜粋です)
サブエージェントはメインの会話から独立して実行されます。独自のコンテキスト・ウィンドウを持ち、割り当てられたタスクを実行し、結果の要約をBobに返します。これにより、サブエージェントは、メインの会話に大量の無関係なコンテンツを追加する作業に役立ちます。
SubTaskの仕組み
(ドキュメントからの抜粋です)
サブタスクは完全に独立したタスクで、UIに独自のブレッドクラムと会話履歴で表示されます。サブエージェント（バックグラウンドで静かに実行され、要約のみを返す）とは異なり、サブタスクは可視的でインタラクティブです。進行状況を追跡し、出力を確認し、その中で会話を続けることができます。
SubTask と SubAgent の特徴比較
| 特性 | SubAgent | SubTask |
|---|---|---|
| 実行コンテキスト | 独立 | 独立 |
| 親への返却物 | サマリーのみ | サマリーのみ |
| 並列実行 | ✅ 複数同時可 | ❌ 逐次のみ |
| 親コンテキスト継承 |
fork_context=true で可 |
❌ 独立 |
| 主な用途 | 情報収集・調査の並列化による時短 | 可視的でインタラクティブ、進行状況の追跡、出力の確認 |
SubAgent は 並列実行 、SubTask は 逐次実行、という点が最大の違いです。
コンテキストへの影響
両者とも 実行コンテキストが独立 しているため、親エージェントのコンテキストが膨らみにくいという重要なメリットがあります。
SubAgent / SubAgent 共に、内部で大量のファイルを読み込んだり、何度も試行錯誤しても、その中間過程は親コンテキストに持ち越されません。渡す指示文と返ってくるサマリーだけが親に乗るため、コンテキスト残量を温存する効果があります。
どんなユースケースで有用か
SubAgent が有用なケース
- 親コンテキストが長くなってきており、コンテキストを節約 したい場合
- 複数のファイルやディレクトリを 並列に調査 したい場合
- 結果を急いでいて、並列処理でスピードを優先 したい場合
SubTask が有用なケース
- 親コンテキストが長くなってきており、コンテキストを節約 したい場合
- 手順が多く、途中で判断が必要な 複雑なタスク
- 複数のタスクを逐次実行し、シンプルさと可視性を優先 したい場合
個人的な利用方針：まずはSubTaskを選ぶ
どちらを選択するのかは、ケース・バイ・ケースだと思いますが、私は現時点では SubTask を優先して使う 方針にしています。その理由は以下の通りです。
-
実行中の可視性がある
SubTask 実行中は何をしているかリアルタイムで確認できるため、途中で問題があれば気づきやすいです。 -
結果を急がない場合、逐次実行のシンプルさで十分
並列処理が必要になる場面（大量ファイルの一括調査など）が出てきたときに初めて SubAgent を検討するくらいで良いと判断しています。
あくまでも個人の見解です。SubAgentの方が便利だと感じる人も多いと思います。
SubTask を使う際の注意点
SubTaskは可視的でインタラクティブ、進行状況の追跡、出力の確認 が可能という特徴がありますが、以下の注意点を意識しておく必要があります。
⚠️ 終了後に詳細な実行ログを遡れない
SubTask が完了すると、結果（サマリー）しか親に返ってきません。SubTask 内部で何をしたか、どういう判断をしたか、どのファイルを触ったかといった詳細は 後から確認できません。
これが具体的に困るのは以下のようなケースです。
| ケース | 問題 |
|---|---|
| ファイルを間違って編集した | どのファイルをどう変えたか、後から追えない |
| 前提を誤って処理した | どこで判断がずれたか、後から追えない |
| エラーが出たが続行した | どんなエラーを無視したか、後から追えない |
| 意図と違う実装をした | なぜその実装を選んだか、後から追えない |
対処法
事前の対策
- SubTask への指示に 「実施した操作の一覧をサマリーに含めること」 と明示する
- コードの変更を伴う場合は事前に
git commitしておき、差分で変更内容を確認できるようにする
事後の確認
-
git diffやgit logで実際の変更内容を確認する - 疑問があればエージェントに「直前の SubTask のサマリーを詳しく説明して」と聞く
根本的な使い分け
- リスクの高い変更 や 取り消しが難しい操作 は SubTask に丸投げせず、親エージェントが直接実行 する
まとめ
(再掲)
| 特性 | SubAgent | SubTask |
|---|---|---|
| 実行コンテキスト | 独立 | 独立 |
| 親への返却物 | サマリーのみ | サマリーのみ |
| 並列実行 | ✅ 複数同時可 | ❌ 逐次のみ |
| 親コンテキスト継承 |
fork_context=true で可 |
❌ 独立 |
| 主な用途 | 情報収集・調査の並列化による時短 | 可視的でインタラクティブ、進行状況の追跡、出力の確認 |
「処理の進行状況を確認しながら進めたい」「逐次処理に安心感を覚える
」「並列実行は不要」という条件であれば、SubTask が現実的な第一選択 です。ただし、実行後の振り返りができない点は共通の制約として理解した上で、事前のgitコミットやサマリー指示の工夫 で補うのが実用的なアプローチです。
参考