AI コーディング支援ツールの進化は目覚ましく、特に「エージェント」と呼ばれる機能は、より広範なタスクを自律的にこなしてくれる可能性を秘めており、大きな期待が寄せられています。
しかし、私自身、これまでこれらのツールを「エージェント」として一括りに捉えがちで、それぞれの明確な違いや、特に Roo Code のようなツールの具体的な使い所について、いまひとつ掴みきれていませんでした。それまであまり込み入った作業をしていなかったため、Copilot のエージェント機能で事足りていたためです。
そんな中、あるコード移行作業を通じて、GitHub Copilot のエージェント機能と Roo Code の間にある明確な違い、そして Roo Code ならではの価値を実感する機会がありました。今回はその経験を共有し、それぞれのツールの特性と使い分けについて考察してみたいと思います。
本記事で取り上げるのは、いわゆる Vibe Coding と呼ばれるエージェントに任せるスタイルではなく、慎重に 1 つずつ確認して進めていくスタイルです。
課題：Gemini API の新旧移行
対象プロジェクト：
今回取り組んだのは、Google の生成 AI モデルを利用するための API を、旧型の google-generativeai から新型の google-genai へと移行する作業でした。この移行は、単なるライブラリ名の置換では済まない、いくつかの難しさを含んでいました。
- API 非互換性：新旧 API間には互換性がなく、根本的な使い方が異なりました。
- 広範囲な修正：インスタンスの生成・管理方法、API 呼び出しの形式など、コードベースの広範囲にわたる修正が必要でした。
- 依存関係：API の粒度が異なるため、インスタンスをどのように持ち回るかなど、関数間の依存関係を考慮しながら段階的に修正を進める必要がありました。
この作業には、性能確認も兼ねて GPT-4.1 を利用しました。しかし、google-genai は比較的新しい API で LLM が十分な知識を持っていないため、公式リファレンスから関連する項目を抽出して、gemini.md というファイルにまとめました。
Web ページから Obsidian を経由してコピー＆ペーストすると、見出しやコードブロックなどの構造をある程度保ったまま Markdown に変換できるので便利です。
GitHub Copilot エージェント
まずは、GitHub Copilot のエージェント機能で試してみることにしました。src ディレクトリ全体と、先ほど作成した gemini.md をコンテキストとして追加し、次のようなプロンプトを与えました。
現在、srcはgoogle-generativeaiを使用している。google-genaiに移行する。使い方はgemini.mdを参照。
エージェントは、指示通り複数の関連ファイルを横断的に分析し、修正案を提示し始めました。しかし、出力されたコードは不完全で、そのままでは到底動作するものではありませんでした。
問題は、エージェントが一連の変更を「一括」で適用しようとした点にありました。API の粒度の違いから生じるインスタンスの受け渡し方法の変更など、本来であれば依存関係を確認しながら段階的に進めるべき修正が、同時に複数のファイルに対して行われた結果、コード全体の整合性が崩れてしまったのです。どこから手をつければ良いのか分からなくなってしまいました。
作業内容があまり複雑ではない場合、一括で適用しても特に問題ないことも多いです。今までそのようなケースが大半だったため、GitHub Copilot のエージェントで十分だと感じていました。
Roo Code
GitHub Copilot エージェントでの失敗を受け、次に Roo Code を試してみることにしました。
まず気づいたのは、コンテキストの扱いの違いです。Roo Code ではプロンプトの文面の中にコンテキストを埋め込めるため、自然に記述できると感じました。これは地味ながら便利な点です。
@/src/以下のPythonファイルについて、@/gemini.mdを参考にしてgoogle.generativeaiからgoogle.genaiに移行する。
そして、作業を開始すると、Roo Code は Copilot エージェントとは異なるアプローチを取りました。
- 作業の分割：移行作業全体を、より小さなステップに分割して進めました。
- 対話的な提案: 自動承認をオフにしていると、1 つずつ確認しながら段階的に進められます。作業内容を提示した後、「Rooはこのファイルを編集したい:」として具体的な変更箇所を提示します。
- ユーザーによる承認：各ステップの提案に対して、ユーザーが内容を確認し、必要に応じて修正を加えた上で承認することで、次のステップに進みます。
このステップバイステップのアプローチは、驚くほど効果的でした。まるで自分が手動でリファクタリングを行う際の思考プロセスをなぞるように、1 つ 1 つの変更内容とその影響範囲を確認しながら、着実に作業を進めることができました。依存関係が複雑な箇所でも、Roo Code の提案を確認し、必要であればその場で微修正を加えることで、コードの整合性を保ったまま移行を完了させることができました。👉コミット
簡単な作業では細かく承認を求められると煩雑に感じますが、先ほど GitHub Copilot エージェントで一括で進めて混乱に陥ったばかりだったため、慎重に進めようという意識にマッチしました。作業内容を流さずに追いかけていれば、「Rooは～したい」と求めてくる内容の合理性が理解できるため、思わず親近感を覚えてしまったほどです。
補足すると、今回はそれほど大規模な修正ではなかったため、時間を掛ければ GitHub Copilot エージェントの内容を擦り合わせて動く状態に持ち込むことは可能だったでしょう。比較のために Roo Code を試したところ、予想以上にうまくマッチしたということです。
GitHub Copilot エージェントと Roo Code の使い所
今回の経験を通じて、GitHub Copilot のエージェント機能と Roo Code の使い所が実感できました。
GitHub Copilot エージェント
- 定型的なコード生成、小規模な修正、全体像を一気に書き換えたい場合など、比較的単純で見通しの良いタスク。
複雑な依存関係を持つ大規模なリファクタリングや、段階的な確認が不可欠なタスクでは、意図しない結果を招き、かえって手戻りが増える可能性がある。
Roo Code
- 自動承認をオンにすれば、GitHub Copilot エージェントと同様に一気に進めることは可能。
- 複雑なリファクタリング、API 移行、仕様変更への追従など、慎重さと段階的な確認・修正が求められるタスクでは、自動承認をオフにすることで AI と人間が協調しながら、安全かつ着実に作業を進められる。制御しやすく、安全性が高い。
自動承認をオフにするとステップごとに承認が必要なため、単純なタスクでは手間が増える可能性がある。
まとめ
これまで「エージェント」と一括りにしていた機能群の中に、これほど明確な思想と挙動の違いがあることに驚きました。特に Roo Code の「人間が確認・修正しながら AI と協調して進める」というワークフローは、AI がまだ完璧ではない現状において、非常に現実的で有効なアプローチだと感じます。
関連記事
続く作業では、旧 API に依存したエラーハンドリングを修正しました。👉コミット
具体的には、以下の記事に含まれる実装を提示して、必要な改変を施した上で取り込むように指示しました。
今回の API 移行作業は、新 API が必須とされる画像生成の利用を通じて、ある程度慣れてから行いました。