---
title: "Roo CodeのBoomerang Modeとは？Orchestratorのサブタスク委任と提供終了後の移行先"
url: "https://www.issoh.co.jp/tech/details/6211/"
published: 2025-04-09
updated: 2026-10-01
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# Roo CodeのBoomerang Modeとは？Orchestratorのサブタスク委任と提供終了後の移行先

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でslug`orchestrator`の組み込みモードになります。公式ドキュメントは現在も「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](https://github.com/RooCodeInc/Roo-Code/blob/main/CHANGELOG.md)です。

## サブタスクが親タスクへ戻る仕組み

### 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）ことを理由に挙げています。

それでも読み取りだけは許したい場合は、同じslug`orchestrator`のモードを定義して上書きします。設定の優先順位は、プロジェクトの`.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](https://docs.zoocode.dev/roo-to-zoo-migration)にまとまっています。

### Kilo Code：Orchestratorモードは非推奨でtaskツールに置き換え

Kilo Codeの[公式ドキュメント](https://kilo.ai/docs/code-with-ai/agents/orchestrator-mode)は、Orchestratorモードを非推奨とし、将来のリリースで削除すると告知しています。現行版ではCode・Plan・Debugなど全ツールを持つエージェントが、必要と判断したときに`task`ツールでサブエージェントを起動します。子は会話履歴を分けますが、作業ディレクトリは親と共有するため、ファイル編集は隔離されません。前景で動かすと結果が返るまで親が待ち、背景で動かすと親は先へ進みます。モードを切り替える手順が無くなる一方、Kilo Codeの拡張機能にはRoo Codeのタスク履歴を検出して取り込む処理がありますが、カスタムモードの自動移行が対象にするのは旧Kilo Codeの`.kilocodemodes`と`custom_modes.yaml`です。しかも移行時は、`orchestrator`など既定モードと同じslugの定義がスキップされます。Boomerang Mode用に上書きしたOrchestratorの定義は、そのままでは引き継がれません。

### Claude Code：サブエージェントによる分業

[Claude Codeのサブエージェント](https://code.claude.com/docs/en/sub-agents)は、それぞれ独自のコンテキストウィンドウ・システムプロンプト・ツール権限を持ち、仕事を終えると結果をメインの会話へ返します。完了結果を親へ返す点はOrchestratorと共通します。ただし、Claude Codeには親の会話履歴・システムプロンプト・ツールを継承するfork型もあり、子の開始時の文脈まで同じ設計とは限りません。違いは、委任の判断がモードの切り替えではなくメインの会話に任される点です。複数のエージェントが互いにやり取りする構成まで必要なら、Agent Teamsも選択肢になります。

Roo Codeの移行先全体の比較は[Clineのフォーク比較｜Roo Codeの提供終了後の移行先とKilo Code・CoolClineの現状](/tech/details/5720/)で扱っています。

## よくある質問

### 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の後継ではありません。

## 関連記事

- [Clineのフォーク比較｜Roo Codeの提供終了後の移行先とKilo Code・CoolClineの現状](/tech/details/5720/)
- [Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】](/tech/details/12108/)
- [タスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証を実装目線で解説](/tech/details/16330/)
- [マルチエージェントオーケストレーションとは？仕組み・主要パターン・フレームワーク選定と採用判断を実装者視点で解説【2026年版】](/tech/details/13600/)
- [Claude Code Agent Teamsの全体像と従来のサブエージェントでは不可能だった協調開発の仕組み](/tech/details/10960/)

---

出典: [Roo CodeのBoomerang Modeとは？Orchestratorのサブタスク委任と提供終了後の移行先](<https://www.issoh.co.jp/tech/details/6211/>)（株式会社一創）