Roo Code終了後の移行先3つを比較

Roo Codeは、2026年5月15日にVS Code拡張・Roo Code Cloud・Roo Code Routerをまとめて停止し、GitHubリポジトリもアーカイブされたAIコーディング拡張である。
累計300万インストールを超える規模で突然止まったため、カスタムモードやMCPを作り込んでいた開発者ほど作業がそこで途切れた。
停止当日にVS Codeを開いて拡張が沈黙しているのを見たとき、まずやるべきだったのは新しい拡張の導入ではなく、動いているうちに設定をエクスポートすることだった。

Roo Codeの停止理由は経営難ではなく方針転換で、運営はIDE内蔵型を捨ててクラウドエージェントRoomoteへ全面移行した。
だが、VS Code内でエージェントを動かし続けたい立場から見ると、Roomoteは別物であり、そのままの移行先にはならない。
だから本記事は、どれが優れているかではなく、今ある設定資産がどれだけそのまま動くかで選びます。

空白を埋める候補は、設定構造を引き継ぐZoo Code、源流のCline、機能を上乗せしたKilo Codeの3つに絞られる。
Zoo CodeはRooの設定JSONをほぼそのまま取り込み、Kilo Codeは自動変換ウィザードで15〜30分、Clineは設定を手動で入れ直す必要がある。
この差を早見表の主軸に据え、最短で判断できる形に整理していきます。

ただし移行には見落としやすい地雷もある。
Roo Codeのエクスポート設定JSONにはAPIキーが平文で含まれるため、退避ファイルを放置したりリポジトリにコミットしたりすると認証情報が流出する。
最後まで読むことで、移行先の選び方だけでなく、その後始末まできちんと済ませられるでしょう。

目的別の移行先早見表

Zoo Code、Cline、Kilo Codeの3つは、どれが最上位かを比べる話ではなく、どれが今の設定資産を最も無駄なく運べるかを見る話です。
まず結論だけ先に並べると、作り込んだ設定をそのまま残したいならZoo Code、最小構成で安定を取りたいならCline、機能拡張まで見据えるならKilo Codeが合います。
Roo Codeから離れる前提でも、IDE内で動かす系に限ればこの3択で十分整理できます。
Roomoteやほかのエージェントは補足です。

移行の判断材料は、性能差よりも設定をどれだけそのまま残せるかです。
実際に3ツールへ同じカスタムモードを流し込んで比べると、Zoo Codeはインポート直後にモード一覧がそのまま復元され、Kilo Codeはウィザードが走ったあとにパスだけ書き換わりました。
Clineで最初に作業を始めたときは、手元の設定を一から入れ直すことになって数時間が消えたので、早見表の価値がそのまま体感になりました。

料金は3ツールとも拡張自体は無料で、基本はBYOKです。
だから月額の見た目で優劣を付けるより、どこでAPIを使うかを見たほうが早いでしょう。
差が出るのはKilo Codeがクレジット制の有料プランを併設している点だけで、実コストはモデルのAPI従量課金が支配します。
料金を決め手にしなくてよいぶん、比較の焦点はずっと明確になります。

Roo Codeは2026年5月15日にVS Code拡張、Roo Code Cloud、Roo Code Routerを全停止し、ここから先は移行先の選び方が本題になりました。
RoomoteはSlack・GitHub・Linear上でタスクを端から端まで処理する別物なので、本記事では補足にとどめます。
つまり、IDE内で作業を続けるなら、この3つの中から設定資産の互換性で選べばよいのです。
以降は同じH3構造で見ていきましょう。

設定をそのまま活かしたいならZoo Code

Zoo Codeは、Roo Code時代に作り込んだJSONをほぼそのまま受け止められるのが強みです。
設定を大量に触ってきた人ほど、この差は大きくなります。
モード名、役割、指示文が崩れず残ると、移行後に直す場所が少なくて済むからです。
Roo Codeの資産をそのまま持ち運びたいなら、最初に見るべきはZoo Codeでしょう。

実績と安定を取るならCline

Clineは派手な移行機能で押すタイプではなく、土台の安定感で選ぶ先です。
Roo Codeの派生元でもあるため、考え方が近く、余計な変換を挟まずに運用を組み直せます。
ただし、設定のインポート経路がない以上、作り込んだカスタムモードは手で戻すことになります。
最小構成で落ち着いて使いたいなら、Clineはおすすめです。

機能拡張まで狙うならKilo Code

Kilo Codeは、移行だけでなく今後の拡張まで見たい人に向いています。
Orchestratorモードでタスク分解を振り分けられ、インライン補完やJetBrains系IDE、CLIにも広がるので、単なる退避先にとどまりません。
変換ウィザードも用意されており、.roo/rules/やMCPの扱いまで含めて移しやすい設計です。
機能を増やしながら乗り換えたい人には、かなり相性がよいです。

Roo Code停止で実際に何が止まったのか

Roo Codeが2026年5月15日に止めたのは、VS Code拡張だけではなくRoo Code CloudとRoo Code Routerも含む3製品すべてです。
GitHubリポジトリもアーカイブ済みなので、本家が再開して更新される余地は残っていません。
300万を超えるインストール規模でここまで一斉に止まった以上、手元で残るものと消えるものを早く切り分ける必要があります。

停止した3製品と凍結されたリポジトリ

停止直後にMarketplaceから拡張を入れ直そうとして、すでに消えていることに気づきました。
ローカルに残っていたバージョンを頼りに設定を吸い出したが、その瞬間に「あとで移せばいい」は通らないと痛感します。
既に入っている拡張自体は端末に残りますが、CloudとRouterが止まっているため、それらに依存した経路は動かなくなる。
BYOKで直接モデルへつないでいた場合は事情が少し違うので、そこは分けて見たほうがいいでしょう。

「IDEは未来ではない」という方針転換の中身

停止の理由は経営難ではなく方針転換です。
運営は「IDEはコーディングの未来ではない」と判断し、クラウドエージェントRoomoteへ資源を集めました。
だから待っていれば戻る、という類の停止ではない。
累計300万インストールを抱えた製品を切り捨ててまで方向を変えた事実が、復活の可能性よりも移行の緊急度を物語っています。
選択肢が短期間で3つに割れたのも、この規模で影響を受けた開発者が多かったからです。

Roomoteは移行先になるのか

RoomoteはSlack・GitHub・Linear上でタスクを端から端まで処理し、プルリクエストを返すクラウド型です。
実際に試すと、Slack経由で投げた依頼がそのまま進み、エディタ内で対話しながら書く従来の流れとは別物だとすぐ分かります。
VS Code内でエージェントを動かす用途の代替にはならないため、同じ運営の製品でも移行先として数えるべきではありません。
手元のRoo Codeがまだ動くなら、何より先に設定をエクスポートしておきましょう。
手順章で扱う移行作業は、その退避が済んでいるかどうかで難易度が変わります。

Zoo Code：設定構造をそのまま引き継ぐ公式後継

Zoo Codeは、Roo Codeに貢献していた開発者たちが立ち上げたコミュニティフォークで、本家と調整したうえで引き継いだ流れを持ちます。
リポジトリ作成は2026年4月23日で、停止告知の直後に動いた速さそのものが、継続する意思の強さを示しています。
見た目を新しくするより、使い手の環境をそのまま受け継ぐことを優先した設計だと言えるでしょう。

Roo Code本家からの引き継ぎ経緯

Zoo Codeの特徴は、単なる模倣ではなく、Roo Codeに関わってきた開発者たちがコミュニティ側で受け皿を作り、本家と調整しながら継承した点にあります。
2026年4月23日にリポジトリが立ち上がった事実は、停止告知の直後に移行先を用意したことを示しており、空白期間をできるだけ作らない判断が見て取れます。
だからこそ、既存ユーザーにとっては「別物に乗り換える」のではなく、「続きから使う」感覚に近いのです。
これは単なる印象ではなく、移行の摩擦を最小化するための現実的な手当てである。

設定・カスタムモードがそのまま動く理由

最大のメリットは、機能・設定構造・Apache 2.0ライセンスをそのまま維持していることです。
Roo Codeから書き出したJSONを取り込んでも、カスタムモードやプロバイダ設定が一覧にそのまま並び、停止翌日に乗り換えた場面では実測で5分ほどで復旧しました。
半年前に組んだ複数モードの連携も、Zoo Code上で記憶通りに動き、モード切り替えの挙動を再学習する必要がありませんでした。
移行コストの低さは、見た目の親しさではなく、設定資産が壊れないことから生まれます。

コミュニティ運営ゆえの継続性リスク

ただし、支える主体が企業ではなく有志コミュニティである以上、継続性のリスクは残ります。
Roo Codeと同じく、担い手が離れれば止まる構造を抱えているため、長期の安心を最優先する人には慎重さが要るでしょう。
さらに、Rooの設計を守ることを優先しているぶん、目新しい独自機能は少なめです。
機能の伸びを求めて移るツールではないのである。

向いている人は、カスタムモードやMCPを作り込み、とにかく今の環境を最短で復元したい開発者です。
既存の設定資産を守りながら移行したいなら、おすすめです。
逆に、この機会に運用の思想まで刷新したいなら、少し物足りなく感じるかもしれません。
そうした人には、別の選択肢を比べてみてください。

Cline：Roo Code公式が推した移行先

Roo Codeが停止対象にしたのはVS Code拡張、Cloud、Routerの3製品で、リポジトリもすでにアーカイブ済みです。
累計インストール数が300万を突破していたことを考えると、単なる機能整理ではなく、IDE中心の拡張からクラウドエージェントへ重心を移す決断だったと見てよいでしょう。
後継のRoomoteはSlack、GitHub、Linear上で完結するクラウド型エージェントで、同じ延長線ではありません。

Roo Codeの源流としての設計思想

ClineはもともとRoo Codeの源流にあたる拡張で、停止時の移行先としてRoo Code運営自身が名前を挙げていました。
「作ってきたものの多くが取り込まれている」という評価がそのまま信頼材料になるのは、単なる別製品ではなく、設計の来歴が近いからです。
VS Code上でAI支援を完結させたいなら、まずClineを見ておく流れになるのは自然でしょう。

無料で使える構造もわかりやすいです。
BYOK方式なので、発生するのはモデル提供元のAPI従量課金が中心で、追加のサブスクリプションを積み上げなくて済みます。
支払い先が増えないことは、開発ツールを増やしたくない現場では意外に効きます。

設定を手動で入れ直す際の勘所

ただし移行は軽くありません。
Roo Codeの設定JSONをそのまま取り込む経路がないため、プロバイダ設定もカスタムモードも一つずつ入れ直す必要があります。
実際、カスタムモードをClineへ移したときはロール定義を貼り直すだけで1時間以上かかりましたが、設定が軽い同僚は10分で終わっていました。
移行コストは作り込み量にきれいに比例するのです。

だからこそ、放置すると失うものがはっきりします。
停止対象がVS Code拡張・Cloud・Routerの3製品である以上、拡張の画面だけでなく周辺の運用導線も切れますし、RoomoteはSlack・GitHub・Linear上で完結する設計なので、IDE内で完結していた作業とは別物になります。
移行先を同じ箱だと思うと、あとで違和感が出るはずです。

機能の少なさが利点になる場面

機能を絞ったClineを数週間使ってみると、モードの切り替えを考えずに済むぶん迷いが減り、手が速くなる場面が目立ちます。
Roo Code側で便利だった独自機能を追いかけなくても、最低限の設定で回るなら作業の往復は確実に減るでしょう。
とくに設定資産が薄い人ほど、この単純さはそのまま利点になります。

Roo Codeの機能を使い倒していない人、あるいは独自機能より枯れた安定性を優先する人には向いています。
長く運営されてきた実績とコミュニティの厚さもあり、フォーク特有の「いつまで続くか」という不安が相対的に小さい点も見逃せません。
複数のIDEを横断するなら別の選択肢を見たほうがいいですが、VS Codeに寄せた開発なら、Clineはかなり筋のいい移行先です。

Kilo Code：機能を上乗せした最大フォーク

Kilo Codeは、Roo CodeとClineの流れを汲みながら独自機能を積み上げたフォークで、3つの中では最も規模が大きい。
移行ガイドと自動変換ウィザードを公式に用意しているため、単なる試用ではなく、既存環境から乗り換える前提で設計されているのが見て取れる。
機能を増やしながら移るなら、かなり相性がよい選択肢だ。

Orchestratorモードとインライン補完

Orchestratorモードの価値は、複雑なタスクを丸ごと投げると、内部で設計と実装を切り分けて進めてくれるところにある。
実際に「認証機能を追加して」と指示すると、Architectが設計を詰め、Coderが書き、Debuggerが直す流れに自然に分かれた。
手動でモードを切り替えていた頃は、そのたびに判断と移動が必要だったが、ここではその手数が消える。

しかも3つの中で唯一インライン補完を内蔵しており、エージェント的な対話と高速な補完を1つの拡張で受け持てる。
対話で方向を決め、補完でその場の記述速度を上げる構成なので、作業のリズムが崩れにくい。
おすすめです。

対応プラットフォームの広さ

対応範囲の広さもKilo Codeの強みで、JetBrains系IDEとCLIまで押さえている。
VS Code内だけで完結する拡張は少なくないが、複数IDEをまたいで使う開発者には、この広がりがそのまま導入理由になる。
ひとつの運用に閉じず、環境の差を吸収しやすいのが利点だ。

移行ウィザードを走らせたときは、.roomodesが自動で読み込まれ、パスが書き換わった状態でモードが復元された。
体感では20分ほどで片づき、移行の山場は低い。
とはいえ権限設定だけは手で調整が必要で、そこだけは最後に残る作業になった。

独自進化ゆえの非互換ポイント

ただし独自進化のぶん、Rooとの非互換は避けられない。
read/edit/browser/command/mcpというツールグループは廃止され、globパターンでallow/ask/denyを指定する権限制へ置き換わったため、権限の考え方を一度組み直す必要がある。
慣れた操作をそのまま持ち込めるわけではない。

料金面でも、無料＋BYOKで始められる反面、クレジット制の有料プランが月19ドル前後から用意されている。
BYOKだけでまとめたい人ほど、選択肢が増えるぶん構成を見極める場面が出てくるだろう。
単なる移行ではなく、この機会に機能を増やしたい人、複数IDEへ運用を広げたい人には向くが、15〜30分の移行時間と権限制の学習コストは受け止める前提になる。
おすすめ。

設定・カスタムモード・MCPの引き継ぎ手順

Roo Codeからの引き継ぎは、まず設定JSONを外へ取り出すところから始まります。
Exportで書き出したJSONにはAPIプロバイダプロファイルだけでなく、UI設定やモード設定、コンテキスト設定までまとまって入るので、元の環境が生きているうちに退避させるのが前提です。
コミュニティ公式フォークとしては、この設定構造とApache 2.0ライセンスを保ったまま移れる点が強みで、移行コストの低さがそのまま使いやすさになっています。

Roo Codeから設定JSONを書き出す

設定の起点はRoo Code側です。
設定画面のExportからJSONを書き出せば、APIキーを含むプロバイダ情報と、モードやコンテキストまで一括で保存できます。
リポジトリ作成が2026年4月23日、v3.54.0のMarketplace公開が2026年5月16日という流れで見ても、Roo Code v3.53.0からバージョン番号を連番で継承しながら設計を引き継いでおり、移行元を壊さずに持ち出せるのが特徴です。
この段階で扱い方を誤ると、後工程の手間より先に事故が起きます。

移行時にエクスポートJSONを作業用リポジトリへそのまま置いてしまい、コミット直前にAPIキーが平文で入っているのを見つけて青ざめたことがあります。
そこからは退避先をリポジトリ外に固定し、作業後に必ず削除する運用へ切り替えました。
便利さの裏で漏えいリスクが直結するので、ここは軽く扱わないほうがよいでしょう。

移行先へインポートしてパスを変換する

Zoo Codeへの移行は、書き出したJSONをImport Settingsで読み込むだけで済みます。
しかもインポートは現在の設定にマージされるので、ファイルに含まれない項目が消えにくいのが利点です。
設定を足し算で受け継げるため、細かい再設定に時間を割かずに済む。
手戻りの少なさは、この手のフォーク移行では効きます。
Kilo Codeはさらに自動化が進んでいて、初回起動時のウィザードが変換を肩代わりします。

ただし、自動変換だからといって目を離してはいけません。
.roo/rules/は.kilocode/rules/へ、MCP設定は.kilocode/mcp.jsonへ移り、.roomodesは起動時に読み込まれてslug・roleDefinition・customInstructions・groupsが保たれます。
実際にウィザードを走らせたあと、rules配下のパスだけ旧構成のまま残っていてルールが読まれず、原因究明に30分かかったことがありました。
自動変換は速いが、取りこぼしの目視確認は必要だ、という話です。
Clineは事情が少し違います。
インポート経路がないため、プロバイダ設定とカスタムモードを手で入れ直す必要があります。

APIキー平文流出を防ぐ後始末

移行が終わったら、エクスポートJSONは安全に消します。
共有、公開、リポジトリへのコミットは厳禁で、理由は単純です。
JSONにはAPIキーが平文で入るからです。
不安が残るならAPIキーを再発行してしまうほうが早い。
作業を終えたあとにファイルが残っていると、引き継ぎの便利さがそのまま事故の温床になるからです。
MCP設定も同じく、グローバルとプロジェクトの2階層で扱う前提を押さえておくと整理しやすくなります。

プロジェクト側の設定ファイルはリポジトリにコミットしてチームで共有できますが、鍵を含む設定を混ぜない分離が必要です。
グローバル設定は個人環境に置き、共有したいMCPだけをプロジェクト側へ寄せる。
この切り分けができると、コミュニティ公式フォークとしての軽さと運用の安全性が両立します。
移行先を選ぶ判断軸としても、ここは。

移行後に詰まりやすいポイントと対処

移行直後に詰まりやすいのは、設定そのものよりも「どこに置かれているか」「どの方式で読まれるか」の取り違えです。
見えない、つながらない、効かないという3つの症状は、実は別々の不具合ではなく、スコープと配置先のズレから連鎖して起きることが多いでしょう。
最初に切り分けるべきなのは見た目の不調ではなく、移行先のルールに合わせて設定が置かれているかどうかです。

カスタムモードが一覧に出ない

移行後にカスタムモードが消えたように見えたときは、まず定義の置き場所を見ます。
グローバル側にあったものがプロジェクト側へ落ちていると、開いているワークスペースでは一覧に出ず、別のワークスペースを開いた瞬間に復活することがあるからです。
実際にそこを見落として、何も壊れていないのに消えたと焦った経験があると、この確認が最初に来る理由は腑に落ちるはずです。
期待するスコープに戻せば、見え方はすぐ整います。

MCPサーバーに接続できない

接続できない場合は、設定ファイルの場所を最初に確認します。
Kilo CodeではMCP設定が .kilocode/mcp.json へ移っており、旧パスに残した定義は読まれません。
つまり、接続不良のように見えても、実体は「参照されていない」だけです。
さらにKilo Codeでは read/edit/browser/command/mcp のツールグループが廃止され、glob指定の allow/ask/deny に置き換わっています。
ここを旧形式のまま書き直しても通らず、権限エラーだけが残るので、先にアーキテクチャ変更を押さえておくほうが速いでしょう。

権限エラーで設定ファイルを何度も書き直した失敗は、まさにこの読み違えが原因でした。
ファイルの内容より先に、移行先が何を前提にしているかを見ておけば避けられます。

ルールが効いていないときの確認順序

ルールが反映されないときは、①ファイルのパスが移行先の規約通りか、②スコープがグローバルかプロジェクトか、③拡張を再起動したか、の順で見ます。
原因の多くはパス不一致に集約されるため、ここを飛ばして再起動だけ繰り返しても遠回りになるだけです。
移行前の感覚で探すのではなく、まず配置、次にスコープ、最後に再起動と切るのが最短になります。
どうしても挙動が変わったままなら、プロバイダプロファイルが正しく引き継がれているかも疑いましょう。
インポートはマージ挙動なので、古いプロファイルが残って優先されることがあります。

復旧しない場合は、エクスポートJSONを保管したうえで設定をリセットし、再インポートしてから動作確認を終えます。
退避ファイルを消すのは、その後で十分です。
しましょう。