Boomerang Modeは、VS Code拡張のAIコーディングエージェント「Roo Code」に組み込まれていたOrchestratorモードの旧称です。親タスクがnew_taskツールで作業を子タスクへ渡し、子タスクは終わるとattempt_completionの要約だけを持って親へ戻ります。投げた仕事が結果を持って帰ってくる動きから「ブーメラン」と呼ばれました。
Roo Code本体は2026年5月15日に提供を終了し、GitHubのリポジトリはアーカイブされています。この記事では、最終版v3.54.0のソースで仕組みを確かめたうえで、後継のZoo Codeや、Kilo Code・Claude Codeで同じ運用を続ける方法を整理します。
まとめ：Boomerang Modeの仕組みと2026年10月時点の扱い
- Boomerang ModeはOrchestratorモードの別名です。v3.14.3（2025年4月25日）で組み込みモードになり、v3.21.2（2025年6月20日）で機能名が「Boomerang Tasks」から「Task Orchestration」に改められました。
- 親から子へは
new_taskのmessageと、指定した場合はtodosが、子から親へはattempt_completionのresultだけが渡ります。それ以外の会話履歴は共有されません。 - Orchestratorモードはツールグループが空（
groups: []）で、ファイルの読み書き・コマンド実行・MCPを使えません。委任に専念させるための意図的な制限です。 - Roo Codeは2026年5月15日に提供終了し、最終版はv3.54.0です。コミュニティ版のZoo Code（v3.84.0、2026年9月26日）がOrchestratorモードと
.roomodesをそのまま引き継いでいます。 - Kilo Codeは現行版でOrchestratorモードを非推奨にし、CodeやDebugなどのエージェントが
taskツールで直接サブエージェントを起動する方式に移りました。
Boomerang ModeとOrchestratorモードの名称と版の変遷
最初のBoomerang Modeは組み込み機能ではなく、公式ドキュメントが配布したカスタムモード定義（slugはboomerang-mode）でした。利用者がこれをグローバル設定に貼り付けて使っていたものが、v3.14.3でslugorchestratorの組み込みモードになります。公式ドキュメントは現在も「Orchestrator Mode (aka Boomerang Mode)」と併記しています。
| 版 | 日付 | 変更内容 |
|---|---|---|
| 3.3.6 | 2025-01-30 | new_taskツールを追加 |
| 3.8.0 | 2025-03-07 | 子の完了結果を親へ返す |
| 3.8.2 | 2025-03-08 | サブタスクの自動承認トグル |
| 3.14.3 | 2025-04-25 | Orchestratorを組み込みモード化 |
| 3.15.2 | 2025-05-02 | Orchestratorのツールグループを削除 |
| 3.21.2 | 2025-06-20 | Boomerang TasksをTask Orchestrationへ改称 |
| 3.25.21 | 2025-08-21 | 子タスクへTODOリストを渡せる |
| 3.35.0 | 2025-12-01 | メタデータ方式の親子管理と親の自動再開 |
| 3.41.1 | 2026-01-16 | 子タスクの費用を親に合算表示 |
| 3.54.0 | 2026-05-15 | 最終版（同日に提供終了） |
日付はCHANGELOG.mdの見出しに従っています。3.3.6だけは見出しに日付が無いため、GitHubのv3.3.6タグが指すコミットの日付を載せました。出典はRoo Code公式のCHANGELOGです。
サブタスクが親タスクへ戻る仕組み
new_taskに渡す3つの引数
v3.54.0のツール定義では、new_taskの引数はmode・message・todosの3つです。modeはcodeやdebugなどのモードのslugで、存在しないslugを渡すと「Invalid mode」で失敗します。todosはMarkdownのチェックリスト形式です。ツール説明には「このツールは単独で呼ぶこと」と書かれており、ファイル読み取りなどと同じターンに並べられません。
{
"mode": "code",
"message": "src/auth/login.ts にパスワード再設定APIを追加する。仕様は docs/reset.md のとおり。この指示の範囲だけを実装し、終わったら attempt_completion の result に変更したファイルと未解決の課題を書くこと。",
"todos": "[ ] ルート定義を追加\n[ ] トークン検証を実装\n[ ] 単体テストを追加"
}親タスクを閉じて子タスクだけを開く実装
公式ドキュメントは「親タスクは一時停止する」と説明していますが、v3.35.0以降の実装はもう少し踏み込んでいます。delegateParentAndOpenChildは親タスクをいったん閉じ、履歴にstatus: "delegated"と待ち受け中の子のIDを記録してから、子タスクだけを開きます。同時に開いているタスクは常に1つです。
子がattempt_completionを呼ぶと、reopenParentFromDelegationが親を履歴から読み込み直し、new_task呼び出しへの応答（tool_result）を次の文字列に差し替えて親を再開します。
Subtask <子タスクID> completed.
Result:
<子が attempt_completion の result に書いた要約>親へ返されるのは、完了通知と子が作成した要約です。要約の長さは固定されておらず、子が読んだファイルの中身や差分も、要約に含めれば親へ渡ります。子の途中の会話履歴そのものは自動転送されません。
子タスクに渡る情報と戻る情報
公式ドキュメントは、子タスクは親の文脈を自動では引き継がないと明記しています。親の会話から必要な文脈を渡す入口はmessageで、別途todosも指定できます。子から戻る作業報告はresultです。組み込みのOrchestratorの指示文も、messageには前のサブタスクまでの必要な文脈・範囲・逸脱禁止・attempt_completionで要約を返すことを必ず書くよう求めています。
このため、resultに「完了しました」とだけ書かれると、親は次の子に渡す材料を失います。変更したファイルのパス、採用した設計判断、残った課題の3点をresultに書かせる一文をmessageに入れておくと、親の判断が安定します。
Orchestratorモードの権限とカスタムモードでの上書き
組み込みのOrchestratorモードはgroups: []で定義されています。使えるのは全モード共通のask_followup_question・attempt_completion・switch_mode・new_task・update_todo_list・run_slash_command・skillの7ツールだけです。公式FAQは、ファイルを読めるようにすると親の文脈が読み取り結果で埋まり、委任に集中できなくなる（context poisoning）ことを理由に挙げています。
それでも読み取りだけは許したい場合は、同じslugorchestratorのモードを定義して上書きします。設定の優先順位は、プロジェクトの.roomodes、グローバルのcustom_modes.yaml、組み込み定義の順です。同じslugが両方にあると、.roomodes側が全項目を丸ごと置き換えます。
customModes:
- slug: orchestrator
name: Orchestrator
roleDefinition: >-
You are Roo, a strategic workflow orchestrator who coordinates
complex tasks by delegating them to appropriate specialized modes.
customInstructions: >-
Delegate each subtask with new_task. Ask every subtask to return
changed files, decisions and open issues in attempt_completion.
groups:
- read全項目が置き換わるため、customInstructionsを省くと組み込みの委任手順も消えます。上の例は短縮版なので、実際には公式ドキュメントの定義文を写してからgroupsだけを変えるのが安全です。公式も、権限を足すと委任への集中が崩れると注意しています。
サブタスクの承認・TODO・費用に関わる設定
既定では、子タスクの作成時と完了時の両方でユーザーの承認を求められます。自動承認の設定にある「Always approve creation & completion of subtasks」（内部名alwaysAllowSubtasks）をオンにし、自動承認全体の「Enabled」もオンにすると、どちらも確認なしで進みます。公式はこの項目のリスクを「Low」と分類していますが、子タスクのモードでファイル書き込みやコマンド実行が自動承認されていれば、その権限は子の中でそのまま使われます。
VS Codeの設定roo-cline.newTaskRequireTodos（既定false）をtrueにすると、todosを省いたnew_taskはエラーになります。ただし、実装上は空文字列も受理されるため、TODO項目が必ず作成されるわけではありません。Zoo Codeでは名前空間がzoo-code.newTaskRequireTodosに変わっています。
費用はv3.41.1から子タスクの分が親タスクに合算表示されます。モードごとに最後に使ったモデルを覚える仕様があるため、Orchestratorには推論の強いモデル、Codeには安いモデルを割り当てる使い分けもできます。
Orchestratorに任せる作業と任せない作業
向いているのは、設計・実装・デバッグ・文書化のように段階ごとにモードが変わり、途中の詳細が大きい作業です。Architectモードの設計判断を要約してCodeモードへ渡すと、途中の詳細な会話履歴を親へ持ち込まずに済みます。ただし、親の文脈には委任時の指示や完了要約が残るため、増加量はそれらの長さに左右されます。
次の3つの場面では、委任の手間や逐次実行の制約を避けるため、Orchestrator以外の進め方を推奨します。
- 1ファイルで完結する修正。承認が作成と完了の2回入り、
messageを書く手間が作業そのものより大きくなります。 - 前の段階の細部を何度も参照し直す作業。子に渡るのは
messageだけなので、文脈を毎回書き直すことになります。 - 並列に進めたい調査。Roo Codeは開いているタスクを常に1つに保つ実装なので、子タスクは1本ずつ順番に動きます。
防ぎたい失敗は、子が指示の範囲を越えて関係のないファイルまで直すことと、resultの情報が不足して親が次の作業を判断できなくなることです。組み込み指示文が「この指示の範囲だけを実行する」「この指示がモードの一般指示より優先する」と書かせているのは、この2つへの対策です。
Roo Codeの提供終了後にBoomerang Modeを使い続ける方法
Roo CodeのREADMEは「The Roo Code Extension was shut down on May 15th.」と告知し、代替としてZoo CodeとClineを挙げています。Roo Codeのチームは自社サービスのRoomoteに注力しています。移行先ごとの違いは次のとおりです。
| 移行先 | 委任の起点 | 子の会話履歴 | 並列実行 |
|---|---|---|---|
| Zoo Code 3.84.0 | Orchestratorモード | 分離 | 不可（1本ずつ） |
| Kilo Code 7.x | Code・Plan・Debug | 分離 | 可 |
| Claude Code | メインの会話 | 別履歴（forkは親の履歴を継承） | 可 |
Zoo Code：Orchestratorと.roomodesをそのまま引き継いだ後継
Zoo CodeはRoo Codeの開発に関わったメンバーが2026年4月に始めたフォークで、ライセンスはApache-2.0です。組み込みモードの定義はRoo Codeと同じで、Orchestratorもgroups: []のまま残っています。プロジェクト設定のファイル名も.roomodesから変わっていないため、Boomerang Mode用に作ったカスタムモードはそのまま読み込まれます。移行手順は公式のRoo to Zoo migrationにまとまっています。
Kilo Code：Orchestratorモードは非推奨でtaskツールに置き換え
Kilo Codeの公式ドキュメントは、Orchestratorモードを非推奨とし、将来のリリースで削除すると告知しています。現行版ではCode・Plan・Debugなど全ツールを持つエージェントが、必要と判断したときにtaskツールでサブエージェントを起動します。子は会話履歴を分けますが、作業ディレクトリは親と共有するため、ファイル編集は隔離されません。前景で動かすと結果が返るまで親が待ち、背景で動かすと親は先へ進みます。モードを切り替える手順が無くなる一方、Kilo Codeの拡張機能にはRoo Codeのタスク履歴を検出して取り込む処理がありますが、カスタムモードの自動移行が対象にするのは旧Kilo Codeの.kilocodemodesとcustom_modes.yamlです。しかも移行時は、orchestratorなど既定モードと同じslugの定義がスキップされます。Boomerang Mode用に上書きしたOrchestratorの定義は、そのままでは引き継がれません。
Claude Code：サブエージェントによる分業
Claude Codeのサブエージェントは、それぞれ独自のコンテキストウィンドウ・システムプロンプト・ツール権限を持ち、仕事を終えると結果をメインの会話へ返します。完了結果を親へ返す点はOrchestratorと共通します。ただし、Claude Codeには親の会話履歴・システムプロンプト・ツールを継承するfork型もあり、子の開始時の文脈まで同じ設計とは限りません。違いは、委任の判断がモードの切り替えではなくメインの会話に任される点です。複数のエージェントが互いにやり取りする構成まで必要なら、Agent Teamsも選択肢になります。
Roo Codeの移行先全体の比較はClineのフォーク比較｜Roo Codeの提供終了後の移行先とKilo Code・CoolClineの現状で扱っています。
よくある質問
Roo Codeにサブエージェント機能はありますか？
Roo Codeでは、サブエージェントにあたる仕組みをサブタスク（Boomerang Tasks）と呼びます。Orchestratorモードがnew_taskで子タスクを作り、子は独立した会話履歴で作業して要約だけを親へ返します。ただし、Roo Code本体は2026年5月15日に提供を終了しています。
Boomerangという名前にはどんな意味がありますか？
親が投げた作業が、完了後に要約を持って親の手元へ戻ってくる動きをブーメランにたとえた名前です。機能名はv3.21.2でTask Orchestrationに改められましたが、モード名のアイコンにはブーメランが残っています。
Orchestratorモードにはどうやって切り替えますか？
チャット入力欄の左にあるモード選択から選ぶか、メッセージの先頭に/orchestratorと入力します。macOSでは⌘ + .、WindowsとLinuxではCtrl + .でモードを順番に切り替えられます。
Roo Codeは今も使えますか？
2026年5月15日のv3.54.0を最後に更新は止まり、リポジトリもアーカイブされています。READMEは代替としてZoo CodeとClineを案内しています。新しいモデルへの対応や不具合修正を受けるなら、.roomodesをそのまま読めるZoo Codeへの移行が手間の少ない選択です。
Roomoteとは何ですか？
Roo Codeの開発チームが、Roo Codeの開発を縮小した後に注力しているサービスです。Zoo CodeのREADMEは、Rooのチームが拡張機能の開発を止めてRoomoteに集中したと説明しています。VS Code拡張としてのRoo Codeの後継ではありません。
