Buda vs Roo Code：拡張終了後、元のAgentワークフローを何へ移すべきか
Roo Code利用者向けに、直接後継、workflow棚卸し、失敗テスト、Budaが必要な条件を整理します。
Buda vs Roo Code：拡張終了後、元のAgentワークフローを何へ移すべきか
Roo Codeは、通常の現役製品比較の対象ではなくなりました。公式ドキュメントとVisual Studio Marketplaceは、Roo Code Extensionが2026年5月15日に終了したと明記しています。同じ案内は代替を探すユーザーに、RooコミュニティによるforkのZooCodeと、Roo Codeの起点になったClineを示しています。
この状態では記事の目的も変わります。元のVS Code Agent体験に最も近い継続を求めるなら、まず公式に示された直接的な後継を評価すべきです。BudaはRoo Codeの互換forkではなく、そのように見せるべきでもありません。
Budaが関係するのは、移行の問いがより大きい場合だけです。従来のIDE中心Agentを別のコーディング拡張で再現するのか、それとも再利用できる部分を、技術・非技術Agent、成果物、Owner、レビュー担当が共有するクラウドワークスペースへ作り直すのかという選択です。
古い機能一覧より先に公式ステータスを見る
保存されたRooドキュメントには、有力なオープンソースVS Code Coding Agentの姿が残っています。プロジェクトファイルの読み書き、ターミナルコマンド、対応環境でのWeb閲覧、MCP Server、多数のモデルプロバイダー、Code、Architect、Ask、Debug、Custom Modes、承認設定、プロジェクトルール、コンテキスト参照、複数ステップの作業です。
これらはチームが何を維持すべきかを示すため重要です。しかし過去機能の文書は、拡張が現在も保守・支援されている証拠ではありません。すべての購入・移行判断は終了告知から始めます。
最初の質問は「RooかBudaか」ではなく、「チームはRooのどの部分に依存していたか」です。その答えにより、後継が別のEditor Agentなのか、Coding Agent基盤なのか、広い運用workspaceなのかが決まります。
後継を選ぶ前にワークフローを棚卸しする
最低限、次を記録します。
- Rooがアクセスしたリポジトリとプロジェクトフォルダ
- 利用したModes、カスタム指示、ロール
.roorules、規約、Prompt、Slash Command- MCP Server、外部ツール、モデルプロバイダー、ローカルモデル設定
- ファイル書き込み、ターミナル、ネットワークの承認方法
- 反復タスク、受け入れ条件、テスト、期待成果物
- 人のレビュー担当と完了条件
資格情報を移行文書へ入れてはいけません。統合名とOwnerだけを記録し、移行先の正規手順でSecretを再接続・更新します。
この棚卸しで、移植可能な手順と製品固有状態を分けます。Promptや規約は移しやすくても、非公開Session、拡張Checkpoint、Provider Token、ローカルindexは移せない場合があります。
移行経路は一つではなく三つ
| 維持したいもの | 直接的な経路 | Budaの位置 |
|---|---|---|
| 同じVS Codeコーディングループ | 公式告知が示すZooCodeとClineを先に評価 | 通常は直接代替ではない |
| ローカル・クラウドをまたぐAgentコーディング | リポジトリ、モデル、レビュー、デプロイ要件で現役のCoding Agent基盤を評価 | Coding System周囲のIssue文脈と部門横断リリース成果物を保持できる |
| コード、調査、文書、運用、レビューをまたぐ反復業務 | 出典、ロール、成果物、承認でプロセスを再構成 | 広いプロセスの運用workspaceになり得る |
製品名にAgentが含まれるだけで、異なる仕事単位を管理するツールを選ばないための分類です。
直接的なRoo後継が正しい場合
中心がVS Code内の自律Coding Agentのままなら、Budaより先に直接後継を評価します。Roo公式告知はZooCodeとClineを明示しています。必要なモデル、プロジェクト指示、ターミナル操作、MCP、diffレビュー、承認方式、ローカル環境を再現できるか確認します。
すべての旧設定を複製する必要はありません。実際の規則とツールを使う代表的なBug修正かリファクタリングを選び、diff、テスト、権限、モデル費用、失敗復旧、開発者介入を比較します。
成功し、後続作業も開発者とリポジトリ内で完結するなら、広いAgent workspaceを増やす理由はありません。
Budaが意味のある移行になる場合
Rooがコーディング外の仕事への非公式な入口になっていた場合、Budaが関係します。Web証拠の収集、リリースノート、実装計画、文書更新、運用・製品チームへの引き継ぎが一人のEditorに閉じ込められていたなら、拡張だけを置き換えてもボトルネックは残ります。
Budaでは責任ごとに分けられます。Engineering AgentがIssueとGit文脈を保ち、Research Agentが証拠を集め、Documentation Agentが更新を作り、Operations Agentが公開チェックリストをまとめます。結果はOwnerと次の行動を持つレビュー成果物になります。
移行すべき中心は会話履歴ではなく運用契約です。情報源、許可ツール、期待成果物、レビュー担当、承認点、失敗経路を共有workspaceへ再構成すると、個人のVS Code環境への依存を下げられます。
主張してはいけないこと
BudaはRooのSession、Checkpoint、Mode、.roorules、Provider設定、MCPを自動importしません。互換性保証はありません。有用な指示を翻訳し、ツールを明示的に再接続します。
Budaが自動的に優れたCoding Environmentになるわけでもありません。仕事が編集、diff、テスト、commitで終わるなら、現役Coding Agentの方が近い後継です。仕事がEditorを離れ、人と部門をまたいで責任を保持するときにBudaが関係します。
証拠を保つ移行計画
1. 凍結と記録
Rooバージョン、リポジトリ、Provider、Modes、ルール、MCP、権限、コマンド、受け入れテスト、成果物を記録します。非機密の指示と例だけをexportします。
2. 分類
コードループ、再利用指示、外部統合、業務文脈、成果物、人の判断に分けます。コードループは後継Coding Toolへ。業務文脈とレビューはBudaなどの運用システムへ置けます。
3. 最小経路の再構築
直接後継で一つの実タスクを動かします。部門横断なら、BudaにはIssue文脈、diff・テスト証拠、文書状態、Owner、承認、次の行動だけを作ります。
4. 失敗を試す
権限を拒否し、テストを失敗させ、必要な情報源を外し、途中停止します。誰が失敗を見られるか、何が残るか、どう再開・中止するか確認します。
5. 意図的に退役
新経路の確認後、古い資格情報を削除し、新しいsource of truthを文書化し、Roo指示をarchiveします。競合する二つの現役フローを残しません。
公平な移行パイロット
- ZooCodeやClineなどの直接後継で同じコードタスクを再現する。
- 設定、互換性、diff、テスト、承認、修正を測る。
- 部門横断の引き継ぎだけをBudaで表現し、コードSessionを複製しない。
- 別の人が保存証拠から結果をレビューする。
- 実際の手順と人の責任を保つ最小システムを選ぶ。
FAQ
Roo Codeはまだ現役のVS Code拡張ですか？
公式ドキュメントとMarketplaceは、2026年5月15日に終了したと記載しています。公開資料とソースは歴史的参考になりますが、継続サポートの証拠ではありません。
公式が示す代替は何ですか？
コミュニティforkのZooCodeと、Roo Codeの起点となったClineです。近いEditor代替を求めるチームはここから始めます。
BudaはRoo設定をimportできますか？
自動互換性は確認されていません。Modes、ルール、Prompt、MCP、Provider設定、権限、資格情報を棚卸しし、指示を翻訳して統合を再接続します。
いつBudaを移行に含めますか？
実際の業務がリポジトリから調査、文書、運用、顧客作業、成果物、Owner、人のレビューへ広がるときです。Coding Loop内なら直接の後継を使います。
出典
確認日：2026年9月22日。