Roo CodeとClaude Code比較してみた

1. 2025.6.12 #studyco Roo CodeとClaude Code比較してみた
2. （C）PharmaX Inc. 2025 All Rights Reserve 2 自己紹介 上野彰大 PharmaX共同創業者・CTO/AX事業部長 好きな料理はオムライスと白湯とコーラ マイブームはLLMとRust X：@ueeeeniki
3. （C）PharmaX Inc. 2025 All Rights Reserve 3 自社としては LLMを中心に勉強会を月 1回程度開催
4. 4 （C）PharmaX Inc. 2025 All Rights Reserve Roo CodeとClaude Code
5. （C）PharmaX Inc. 2025 All Rights Reserve 5 • Roo Code（Clineのフォーク） ◦ 弊社で最も使われているツール ◦ Cursorよりも”グイグイ感”が強く、より開発スピードは速いように感じるが一方で、その分暴走する & 不安定になる確率も少し高いように感じる • Cursor ◦ スコープが絞られており、与えるファイルも自分で指定できる場合は、 Cursorが最も安定性は高い ◦ エンジニアの”補助ツール”な的側面が最も強い（） • Devin ◦ ”人間味”を最も感じる ◦ 独立した1まとまりのまるっとタスクを任せるのには向いている気がする Claude Code登場以前のコーディング AIの使い分け Claude Code登場以前は以下のようにコーディング AIを使い分けていた
6. （C）PharmaX Inc. 2025 All Rights Reserve 6 コーディング AIエージェントの Cline / Roo Code 弊社もRoo Code（Clineのフォーク）に最も賭けていると言っても過言ではない https://zenn.dev/mizchi/articles/all-in-on-cline
7. （C）PharmaX Inc. 2025 All Rights Reserve 7 • 使用実績は ◦ Roo Code：数百時間 ◦ Cluade Code：100時間弱 • 使い分けのルールというのは正直まったくない ◦ Roo CodeでつまったらClaude Codeに変えて、Claude CodeでつまったらRoo Codeに変えるという のを繰り返しているだけで明確なルールというのはまったくない ◦ 使い分けはただの気分だが、どっちかで詰まったときにもう一方なら解決できるということはある気が する • 同じClaude 4系を使った際には性能のトータルの違いというのも正直まったく感じない ◦ Claude Code Actionは比較のスコープ外とするという前提での話 ◦ Claude Codeの盛り上がりに違和感を感じる＝思ったよりもみんな Clineに賭けてなかった？笑 ◦ Maxプランにした際の値段は確かに圧倒的に Claude Codeが優位 上野のRoo CodeとClaude Codeの使い分け 最近はRoo CodeとClaude Codeを交互に使っている
8. （C）PharmaX Inc. 2025 All Rights Reserve 8 • 両方VSCode（Cursorのような主要なフォークも含む）の拡張機能として実行可能 ◦ Claude CodeはTerminalやClaude Code ActionなどIDE以外からも呼べるのが大きな特徴であり 一番の違い ◦ IDEと統合することでファイルの編集の diffなどを見ながら作業することができる • 設定すれば、ファイルの読み書きやその他コマンドの実行なども自動化できるのも共通 • ClaudeはMaxプランのような（ほぼ）定額プランがあるが、 Roo CodeはAPI従量課金一択 ◦ 弊社の1事業部（エンジニア4名）の試算では差額は最大月 20万円程度にもなる可能性あり • 並列実行はClaude Codeの方が本質的にやりやすい ◦ Roo Codeも複数IDEを立ち上げれば並列実行が不可能ではない • 当然ながらベンダーフリーなのは Roo Code Roo CodeとClaude Codeの大きな共通点と違い Roo CodeとClaude Codeは根本的な思想は大きく異なる
9. （C）PharmaX Inc. 2025 All Rights Reserve 9 IDE統合で使用した場合の UIの差① Claude Code
 Roo Code
 メインの実行画面は そこまで違わない
10. （C）PharmaX Inc. 2025 All Rights Reserve 10 • 思考過程や今何をしてるのかは圧倒的に Roo Codeの方が見やすい • 設定もRoo Codeの方が圧倒的に自由かつ変更しやすい ◦ さまざまな設定がGUI上でできるかつリッチ • チェックポイントに戻る機能や特定の会話以降の会話履歴が消せると言っ た便利な機能もRoo Codeは備えている IDE統合で使用した場合の UIの差② 実際Roo Codeの方がUIは見やすいかつ扱いやすいのは事実
11. （C）PharmaX Inc. 2025 All Rights Reserve 11 Roo Codeのmode Roo Codeにはモードが存在し、弊社ではモードごとのルールを細かく設定して与えるという設計思想 各モードで何をするのかを定義
12. （C）PharmaX Inc. 2025 All Rights Reserve 12 Roo Codeのmodeのワークフロー Roo Codeはワークフローを定義すれば、モードを自動で切り替えるようになっている ワークフローに従って 勝手にモードが切り替わる
13. （C）PharmaX Inc. 2025 All Rights Reserve 13 • 各々の良さのまとめ ◦ Roo Code ▪ UIが見やすいかつ扱いやすい ▪ カスタマイズ性が高く、チームの運用ルールに適用させやすい • モードを切り替えたり、思ったようなフローで仕事をさせやすい ◦ Claude Code ▪ 定額プランにすると安い ▪ モデルを自動で切り替える機能やコンテキスト圧縮の上手さが性能に対しても効いているか も？ ▪ 拡張性も高いので今後の発展にも期待できる • 結局どっちをメインで使っていくか？と言われたら、 Claude Codeにベットする気がしてきた ◦ 今時点で使いやすいのはあくまで Roo Code ◦ 性能差に対して金額差が大きいのと、使用場面の拡張性や今後の発展にベットする意図 Roo CodeとClaude Codeの比較まとめ 現時点ではRoo Codeの方が使いやすいが、 Claude Codeに緩やかに移行していく方向性
14. 14 （C）PharmaX Inc. 2025 All Rights Reserve AIコーディングのルール整備
15. （C）PharmaX Inc. 2025 All Rights Reserve 15 難しいゲームではあるが、独自のコンテキストは不 要
 ＝必要な情報がすべて揃っていれば複雑なアプリ ケーションも作ることができる 
 なぜテトリスはうまく作れるのか？を考える 参考：『Roo Clineで「一行プロンプト+@」しただけで、約15分でKubernetes上で動くテトリスゲームが無からできました』 テトリスはすでによく知られたゲームであり、 • ゲームのルール・目的
 • ブロックの形状のパターン
 • 操作方法
 • 落下速度
 など必要な情報はすべて事前に揃っている
 テトリスはAIが開発する上で必要な情報はすべて揃っている
16. （C）PharmaX Inc. 2025 All Rights Reserve 16 なぜコーディングエージェントを使った開発はうまくいかないのか？ • 「開発に必要な情報にたどり着けない」は本当か？ ◦ 必要な情報をドキュメント化しアクセス可能な範囲内に配置し、ドキュメントのツリー構造を与えればかなりの精度で取 得できる → そもそもなぜドキュメントが必要なのか？という問いに立ち返る必要がある • コーディング規約やチームのルールなどを”理解してから”開発を始めるには、コンテキストサイズが足りない ◦ そもそもコーディング規約やルールというのはあくまで要約であって、原理的には会議を全部聞いて、コードを全部見れ ばほぼほぼ理解可能なもの • “バグを出さない”というのは原理的に不可能なので、ある程度のバグを潰してくれれば嬉しい。仕様確認してテスト書いて、実 装して、テスト落として改善という反復を繰り返して欲しいが、それにはマルチターンの性能が低い ◦ もっとマルチターンの性能・速度が上がれば、人のところに成果物がくる頃にはかなりのクオリティのものができている はず →現時点では、上記 2つが難しいので、ルールやワークフローを抽象化し適宜立ち戻れるドキュメントが必要かつ、 必要なタイミングで必要な情報を過不足なく与える必要がある 「必要な情報が揃っていることが重要」というと情報検索にばかり議論が偏るがそれだけではない
17. （C）PharmaX Inc. 2025 All Rights Reserve 17 Roo Codeのmode Roo Codeにはモードが存在し、弊社ではモードごとのルールを細かく設定して与えるという設計思想 各モードで何をするのかを定義
18. （C）PharmaX Inc. 2025 All Rights Reserve 18 Roo Codeのmodeのワークフロー Roo Codeはワークフローを定義すれば、モードを自動で切り替えるようになっている ワークフローに従って 勝手にモードが切り替わる
19. （C）PharmaX Inc. 2025 All Rights Reserve 19 Roo Codeのmodeごとのrules .roo/rules-{mode名}に 各モードの細かいルールを配置 ・ドキュメント作成のワークフロー など modeごとにそのモードで守るべきルールを細かく指定することができる
20. （C）PharmaX Inc. 2025 All Rights Reserve 20 Roo Codeのmodeごとのrules 例えば、ドキュメントを整備するモードでは、かなり丁寧にルールを記述することで標準化 ドキュメントの書き方（内容）まで 細かく指定してる
21. （C）PharmaX Inc. 2025 All Rights Reserve 21 リポジトリごとのルールはローカルルールとして記述 各言語やフレームワークごとのルールなどはローカルルールとして記述している 開発ドキュメントではなく常に読み 込まれるルールとして記載 .roo/rules配下
22. （C）PharmaX Inc. 2025 All Rights Reserve 22 • 要件定義書、仕様書、機能一覧、 ER図、アーキテクチャ図 etcなどの開発ドキュメントを常に最新に保つこ とで、開発に必要な知識を保っている ◦ 当然ながらモノレポの場合は、各プロジェクトごとにドキュメントを準備 ◦ プロジェクトに途中からコーディング AIエージェントを導入する場合でも、最初にドキュメントを作成し てから取り組むようにしている • 会話履歴やADRのような”履歴管理”系のドキュメントは今のコンテキストサイズでは読み込めないので管 理するのをやめてしまった ◦ コンテキストサイズが大きくなったら、意思決定の履歴も読み込んでより精緻な判断ができるように なってくはずなので、作成しておいても損はないかも？ • どのようなドキュメントを整備すべきかは随時議論・更新していく メモリーの持ち方に関する工夫 弊社ではメモリーバンクなどを使うのではなく、仕様書などを整備することでメモリーの役割を担う
23. （C）PharmaX Inc. 2025 All Rights Reserve 23 コーディング AIエージェントによる開発フロー・体験の変化 • ドキュメントを更新してから開発という流れを徹底するようになった ◦ AIに参照させるためのドキュメントが間違っていると、その後の AIによる開発も必ず間違うため、最 初にドキュメントを更新するスタイルが厳格化 ◦ プロジェクトに途中から AIコーディングを導入する場合でも、ドキュメントを作成してから取り組むよう にしている • AIコーディングのルールの振り返り（最低週一）を行うなど、開発前には AIコーディングのルール作りに時 間を使うようになった • ルールが共通化していくことで、少なくとも弊社ではチームや事業ごとの差分は減っていく方向性 ◦ プロジェクトごとのルールを整備する余地はあるが、面倒なので共通化したい コーディングAIエージェントによってこれまでの開発フローや体験とは大きく変わり、この流れは戻らない
24. （C）PharmaX Inc. 2025 All Rights Reserve 24 その他のRoo Codeの仕組みと問題点 • 対話型コンテキストによる問題 ◦ ツールを使用した結果はユーザーの発言（ AIのアクションへの反応）として扱われる ◦ 会話が積み重なったようになっていき、過去の指示を忘れ、最新の指示にも従ってくれなくなっていく ◦ 問題となっている過去の会話を取り消すこともできない • ファイル更新形式の失敗が頻発する ◦ ファイル更新はdiffを作るモードがあるが、 Sonnet以外は苦手っぽい ◦ diffを作るモードはオプショナルになっている • エディタが占有されるのでユーザーが作業できない ◦ 人間がIDEを使いたいなら別ウィンドウを起動する必要あり ◦ その割に「リファクタリングや型解決など IDE のビルトイン機能を呼び出すわけではない」など IDE型 のメリットが案外ない Roo Codeはうまくいかないことも多い 参考：『コーディングAIエージェントを作っているけどうまくいかなかった話〜あるいは二ヶ月本気でコーディングAIエージェントと向き合った話』
25. （C）PharmaX Inc. 2025 All Rights Reserve 25 コーディング AIエージェント課題まとめ 弊社でもかなり試行錯誤中 • 複数リポジトリへの展開の仕方はまだ固まっていない ◦ ナレッジ・ルール管理用の専用リポジトリを作成 ◦ GitHub Actionを通じて配布 ◦ モノレポ形式でローカル環境を構築する方法も検討中 • 複数のコーディングAIエージェント間のナレッジ共有 ◦ ロックインされないように複数エージェントで共有したいナレッジはディレクトリを参照させる形式で運 用しはじめている • コーディングAIエージェント時代に適合したプロダクト開発サイクルの構築 ◦ エージェントを育てていくことが生産性の向上につながるため、プロダクト開発サイクルに組み込んで PDCAを回していきたい