Roo CodeのBoomerang Modeとは？Orchestratorのサブタスク委任と提供終了後の移行先【2026年11月】

Boomerang Modeは、VS Code拡張のAIコーディングエージェント「Roo Code」に組み込まれていたOrchestratorモードの旧称です。親タスクがnew_taskツールで作業を子タスクへ渡し、子タスクは終わるとattempt_completionの要約を持って親へ戻ります。投げた仕事が結果を持って帰ってくる動きから「ブーメラン」と呼ばれました。

Roo Code本体は2026年5月15日に提供を終了し、GitHubのリポジトリはアーカイブされています。この記事では最終版v3.54.0のソースで仕組みを確かめ、後継のZoo Code 3.94.0、Kilo Code、Claude Codeで同じ分業を続ける方法まで整理します。

まとめ：Boomerang Modeの仕組みと2026年11月時点の扱い

• 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を使えません。委任先のモードは、各モードのwhenToUseを手がかりに選ばれます。
• Roo Codeは2026年5月15日のv3.54.0が最終版です。いま同じ運用を続けるなら、Orchestratorモードと.roomodesをそのまま引き継いだZoo Code（v3.94.0、2026年10月31日）への移行が最短です。Zoo Codeでは、中断した子タスクの扱いなど委任まわりの修正が続いています。
• Kilo CodeはOrchestratorモードを非推奨にし、Code・Plan・Debugがtaskツールでサブエージェントを起動する方式へ移りました。子どうしが共有ボードで情報を交換するKilo Swarmが既定でオンです。

Boomerang ModeとOrchestratorモードの名称と版の変遷

最初のBoomerang Modeは組み込み機能ではなく、公式ドキュメントが配布したカスタムモード定義（slugはboomerang-mode）でした。利用者がこれをグローバル設定に貼り付けて使っていたものが、v3.14.3でslugorchestratorの組み込みモードになります。

日付はRoo Code公式のCHANGELOGの見出しに従っています。3.3.6だけは見出しに日付が無いため、v3.3.6タグが指すコミットの日付（2025-01-30）を載せました。公式ドキュメントのリリースノートには1日ずれた日付を載せる版があるため、この表はCHANGELOGの見出しを基準にしています。

公式ドキュメントのURLも変わっています。旧来のdocs.roocode.comは、2026年11月4日時点でHTTP 301を返し、roocodeinc.github.io/Roo-Code/へ転送されます。リポジトリでは2026年5月15日のコミットで、ドキュメントのURL設定がこのアドレスに変わっています。移転先のページは「Orchestrator Mode (aka Boomerang Mode)」の併記を残していますが、提供終了の告知はありません。VS Code Marketplaceの掲載も3.54.0のまま残っているため、新しく入れられてしまう点に注意が要ります。

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

new_taskに渡す3つの引数

v3.54.0のツール定義では、new_taskの引数はmode・message・todosの3つです。modeはcodeやdebugなどのモードのslugで、存在しないslugを渡すと「Invalid mode」で失敗します。todosはMarkdownのチェックリスト形式で、形式が崩れていると「Invalid todos format」で拒否されます。ツール説明には「このツールは単独で呼ぶこと」と書かれており、ファイル読み取りなどと同じターンに並べられません。

{
  "mode": "code",
  "message": "src/auth/login.ts にパスワード再設定APIを追加する。仕様は docs/reset.md のとおり。この指示の範囲だけを実装し、終わったら attempt_completion の result に変更したファイルと未解決の課題を書くこと。",
  "todos": "[ ] ルート定義を追加\n[ ] トークン検証を実装\n[ ] 単体テストを追加"
}

親タスクを閉じて子タスクだけを開く実装

公式ドキュメントは「The parent task (in Orchestrator mode) pauses」と説明していますが、v3.35.0以降の実装はもう少し踏み込んでいます。delegateParentAndOpenChildは親タスクをいったん閉じ、履歴にstatus: "delegated"と待ち受け中の子のIDを記録してから、子タスクだけを開きます。同時に開いているタスクは常に1つです（v3.54.0の親子タスク処理）。

子がattempt_completionを呼ぶと、reopenParentFromDelegationが親を履歴から読み込み直し、new_task呼び出しへの応答（tool_result）を次の文字列に差し替えて親を再開します。Zoo Code 3.94.0も同じ文字列を使っています。

Subtask <子タスクID> completed.

Result:
<子が attempt_completion の result に書いた要約>

親へ返されるのは、完了通知と子が作成した要約です。要約の長さは固定されておらず、子が読んだファイルの中身や差分も、要約に含めれば親へ渡ります。子の途中の会話履歴そのものは自動転送されません。

子タスクに渡る情報と戻る情報

公式ドキュメントは「It does not automatically inherit the parent’s context.」と明記しています。親の会話から必要な文脈を渡す入口はmessageだけです。組み込みのOrchestratorの指示文も、messageには前のサブタスクまでの必要な文脈・範囲・逸脱禁止・attempt_completionで要約を返すこと・この指示がモードの一般指示より優先することを必ず書くよう求めています。指示文は、子の要約を「プロジェクトで何が完了したかを追う唯一の記録（source of truth）」として扱うとも書いています。

このため、resultに「完了しました」とだけ書かれると、親は次の子に渡す材料を失います。変更したファイルのパス、採用した設計判断、残った課題をresultに書かせる一文をmessageに入れておくと、親の判断が安定します。

Orchestratorモードの権限と委任先の選ばれ方

groups: [] で使える7つのツール

組み込みのOrchestratorモードはgroups: []で定義されています。使えるのは全モード共通のask_followup_question・attempt_completion・switch_mode・new_task・update_todo_list・run_slash_command・skillの7ツールだけです（v3.54.0の共通ツール定義）。公式FAQは、ファイルを読めるようにすると親の文脈が読み取り結果で埋まり、委任に集中できなくなる（context poisoning）ことを理由に挙げています。new_taskは全モード共通なので、Codeモードの子がさらに子を作ることもできます。

whenToUseによる委任先モードの選択

Orchestratorがnew_taskのmodeを決めるとき、手がかりになるのはシステムプロンプトに並ぶモード一覧です。v3.54.0のmodes.tsは、各モードのwhenToUseが空でなければそれを説明文に使い、空ならroleDefinitionの最初の1文で代用します（v3.54.0のモード一覧の生成処理）。自作のカスタムモードに仕事が回ってこないときは、まずwhenToUseに「どんな依頼のときに使うか」を書きます。

customModes:
  - slug: db-migration
    name: DB Migration
    roleDefinition: You write and review database migration files.
    whenToUse: >-
      Use this mode when a subtask adds, changes or rolls back
      a database schema migration.
    groups:
      - read
      - edit

この仕組みはZoo Code 3.94.0でも同じです。roleDefinitionの1文目が「You are …」のような自己紹介だけだと、Orchestratorには用途が伝わりません。

.roomodesによるOrchestratorの権限の上書き

Orchestratorに読み取りだけは許したい場合は、同じ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」と分類しています。ただし、子タスクのモードでファイル書き込みやコマンド実行が自動承認されていれば、その権限は子の中でそのまま使われます。

TODOによる子タスクの完了条件の制御

子が作業を途中で切り上げてattempt_completionを呼ぶのを防ぐには、VS Codeの設定2つを組み合わせます。どちらも既定はfalseです。

2つ目をオンにすると、TODOに未完了の項目が残っている子がattempt_completionを呼んだ時点で「Cannot complete task while there are incomplete todos.」が返ります。1つ目はtodosが省略されたかだけを見ており、空文字列は受理されるため、TODO項目が必ず作られるわけではありません（v3.54.0のTODO検証処理）。Zoo Codeでは名前空間がzoo-code.newTaskRequireTodos・zoo-code.preventCompletionWithOpenTodosに変わっています。

モードごとのモデルと費用の合算

費用はv3.41.1から子タスクの分が親タスクに合算表示されます。モードごとに最後に使ったモデルを覚える仕様があるため、Orchestratorには推論の強いモデル、Codeには安いモデルを割り当てる使い分けもできます。

Orchestratorに任せる作業と任せない作業

向いているのは、設計・実装・デバッグ・文書化のように段階ごとにモードが変わり、途中の詳細が大きい作業です。Architectモードの設計判断を要約してCodeモードへ渡すと、途中の会話履歴を親へ持ち込まずに済みます。ただし、親の文脈には委任時の指示と完了要約が残るので、増える量はそれらの長さで決まります。

次の場面では、委任や要約の受け渡しを増やさないために、Orchestratorを使わず1つのモードで進めることを勧めます。

• 1ファイルで完結する修正。既定設定では子タスクの作成時と完了時に承認が入り、messageを書く手間が作業そのものより大きくなります。
• 前の段階の細部を何度も参照し直す作業。子に渡るのはmessageだけなので、文脈を毎回書き直すことになります。
• 並列に進めたい調査。Roo CodeとZoo Codeは開いているタスクを常に1つに保つ実装なので、子タスクは1本ずつ順番に動きます。並列が要るならKilo CodeかClaude Codeを選びます。

防ぎたい失敗は、子が指示の範囲を越えて関係のないファイルまで直すことと、resultの情報が足りず親が次の作業を判断できなくなることです。組み込み指示文が「この指示の範囲だけを実行する」「この指示がモードの一般指示より優先する」と書かせているのは、この2つへの対策です。

Zoo CodeでOrchestratorを使い続ける手順

Roo CodeのREADMEは「The Roo Code Extension was shut down on May 15th.」と告知し、代替としてZoo CodeとClineを挙げています。Zoo CodeはRoo Codeの開発に関わったメンバーが2026年4月に始めたフォークで、ライセンスはApache-2.0です。GitHubのリリースはほぼ毎週出ており、2026年11月4日時点の最新は3.94.0（10月31日）です。

Roo CodeからZoo Codeへの設定移行

1. VS Code MarketplaceでZoo Code（拡張IDZooCodeOrganization.zoo-code）を入れます。
2. Roo Codeの設定画面で「Export」を押し、設定ファイルを保存します。このファイルにはAPIキーが含まれることがあるため、共有フォルダに置かないでください。
3. Zoo Codeで「Import Settings」を押し、保存したファイルを選びます。Zoo Codeは現在の設定に取り込んだ内容を統合します。
4. プロジェクトの.roomodesはファイル名を変えずにそのまま読み込まれます。グローバルのカスタムモードもcustom_modes.yamlのままです。
5. VS Codeのsettings.jsonにroo-cline.で始まる項目を書いていた場合は、zoo-code.に書き換えます。

手順は公式のRoo to Zoo migrationにまとまっています。組み込みのOrchestratorは名前が「🪃 Orchestrator」、groups: []のままで、指示文の「You are Roo」が「You are Zoo」に変わった程度です。

Roo Code 3.54.0に留まらない理由：委任まわりの修正

Zoo Codeは、Roo Codeの最終版に残っていた親子タスクの不具合を順に直しています。タスク履歴の状態は、Roo Code v3.54.0ではactive・completed・delegatedの3つでした（v3.54.0の履歴の型定義）。Zoo Code 3.94.0はinterruptedを加え（3.94.0の履歴の型定義）、子が中断されても親はdelegatedのまま子のIDを保持します。ユーザーは後から子を再開するか放棄するかを選べます。

出典はZoo CodeのCHANGELOGとGitHubのリリース日です。Orchestratorで長い作業を流し、途中でVS Codeを閉じたり新しいタスクを開いたりする運用なら、Roo Code 3.54.0では親子のつながりが切れたまま残るおそれがあります。

Kilo Code・Claude Codeで同じ分業を組む方法

モードを切り替えて委任する方式にこだわらなければ、並列実行できる移行先もあります。違いは次のとおりです。

Kilo Code：taskツールとSwarmの共有ボード

Kilo Codeの公式ドキュメントは、Orchestratorモードを「Deprecated — scheduled for removal」としています。現行版ではCode・Plan・Debugなど全ツールを持つエージェントが、必要と判断したときにtaskツールでサブエージェントを起動します。Askのような読み取り専用のエージェントは委任できません。子は会話履歴を分けますが、作業ディレクトリは親と共有するため、ファイル編集は隔離されません。前景で動かすと結果が返るまで親が待ち、背景で動かすと親は先へ進みます。

Roo Codeに無かった仕組みがKilo Swarmです。親セッションとその子孫が共有ボードに発見を書き込み（board_post）、互いに読み合えます（board_read）。7.5.11（2026年9月4日）で試験機能として入り、7.7.0（9月15日）で既定オンになりました（Kilo CodeのCHANGELOG）。止めるには設定のAgent Behaviourでオフにするか、kilo.jsoncで"shared_agent_board": falseとします。7.8.13（10月16日）からは、カスタムの委任エージェント（親）に付けたeditの拒否ルールがその親だけに効き、親が起動した子には及ばなくなりました（PR #14866）。子の書き込みも縛りたいときは、セッション単位の編集制限を使います。子のエージェント自身に付けた拒否ルールと承認要件は従来どおり残ります。

移行には注意点があります。Kilo Codeの拡張機能はRoo Codeのタスク履歴を取り込めますが、カスタムモードの自動移行が対象にするのは旧Kilo Codeの.kilocodemodesとcustom_modes.yamlで、orchestratorなど既定モードと同じslugの定義はスキップされます。Boomerang Mode用に上書きしたOrchestratorの定義は引き継がれません。Kilo Codeの中核はOpenCodeのフォークになっており、設定の考え方はOpenCodeとは？2.0の変更点・インストール・設定・無料モデルを解説【2026年10月】が近くなります。

Claude Code：サブエージェントとAgent Teams

Claude Codeのサブエージェントは、それぞれ独自のコンテキストウィンドウ・システムプロンプト・ツール権限を持ち、仕事を終えると結果をメインの会話へ返します。完了結果を親へ返す点はOrchestratorと同じです。メインの会話から起動したサブエージェントは既定で背景で動き、子がさらに子を作れる深さは、既定ではメインの会話から3階層下までです。環境変数CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHで変更できます。

Roo Codeと大きく違うのはfork型です。forkは親の会話履歴・システムプロンプト・ツールをそのまま受け継いで始まるため、messageに文脈を書き直す手間がありません。agent viewが有効な場合は、/subtaskに続けて作業を書くと、自分でforkを起動できます。agent viewが無効な場合は、代わりに/forkを使います。サブエージェントの定義ファイルの書き方はClaude Codeのサブエージェントとは？作り方・設定項目・使い方【v2.1.287対応】で扱っています。

複数のセッションが互いにメッセージをやり取りするAgent Teamsは、2026年11月時点でも試験機能で既定は無効です。使うには環境変数CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSに1を設定します。Roo Codeの移行先全体の比較はClineのフォーク比較｜Roo Codeの提供終了後の移行先とKilo Code・CoolClineの現状にまとめています。

よくある質問

Roo Codeは終了したのですか？

はい。2026年5月15日のv3.54.0を最後に提供を終了し、GitHubのリポジトリもアーカイブされています。READMEは代替としてZoo CodeとClineを案内しています。新しいモデルへの対応や不具合修正を受けるなら、.roomodesをそのまま読めるZoo Codeへの移行が手間の少ない選択です。

Roo Codeにサブエージェント機能はありますか？

Roo Codeでは、サブエージェントにあたる仕組みをサブタスク（Boomerang Tasks）と呼びます。Orchestratorモードがnew_taskで子タスクを作り、子は独立した会話履歴で作業してattempt_completionの要約を親へ返します。子どうしを同時に動かすことはできません。

attempt_completionは何をするツールですか？

タスクの完了を宣言し、resultに成果の要約を書くツールです。子タスクで呼ばれると、そのresultが「Subtask <ID> completed.」に続けて親タスクへ渡り、親が再開します。preventCompletionWithOpenTodosをオンにしていると、未完了のTODOが残る間は拒否されます。

Orchestratorモードにはどうやって切り替えますか？

チャット入力欄の左にあるモード選択から選ぶか、メッセージの先頭に/orchestratorと入力します。macOSでは⌘ + .、WindowsとLinuxではCtrl + .でモードを順番に切り替えられます。

Roomoteとは何ですか？

Roo Codeの開発チームが、拡張機能の開発を止めた後に注力しているサービスです。Zoo CodeのREADMEは、Rooのチームが拡張機能の開発を止めてRoomoteに集中したと説明しています。VS Code拡張としてのRoo Codeの後継ではありません。

関連記事

• Clineのフォーク比較｜Roo Codeの提供終了後の移行先とKilo Code・CoolClineの現状
• Claude Codeのサブエージェントとは？作り方・設定項目・使い方【v2.1.287対応】
• Claude Code Agent Teamsとは？使い方・設定・料金とサブエージェントとの違い
• Orchestrator-Subagentとは｜Anthropic公式マルチエージェント協調5パターンの選び方【2026年版】
• マルチエージェントオーケストレーションとは？LLMエージェントを束ねる5パターンと実装コード【2026年10月】