はじめに

「Roo Code」 (ルーコード) は、「Cline」 (クライン) を基に開発された、Visual Studio Code (VSCode) で利用可能な、AIによるコーディングまたは周辺作業のアシスタントを行う拡張機能です。
以前はRoo-Cline (ルークライン) と呼ばれていましたが、v3.2以降でRoo Codeに名称変更されました。

VSCodeにインストールして、プラグインが持つチャットフォームから指示を出すだけで、コードを1から作成したり、既存コードを修正したりできます。
単に開発者と会話しながらコードを作成するだけではなく、プロジェクト (ディレクトリ) 構成を1から作成したり、ターミナルコマンドを実行してサービスの再起動やコンテナイメージの作成、さらにデプロイまで、開発者が行う一連の作業を自動的に実行することができます。

X (旧Twitter) などのSNSでは、まるで 「ClineやRoo Codeに指示を出して任せればコーヒーを飲みながら待っているだけでアプリケーションが開発できる」 と言ったような、かなりの驚き屋的な表現でこの技術を歓迎する声があります。
ただ、そのような声を聞くと、本当にそんなにうまく行くのかと疑問に思う方が多くいらっしゃるのではないかと思います。

そこで、本記事では、実際にRoo Codeを使ってみて、うまく行かなかったこと (行かないなと思ったことも含む)、工夫してうまく行ったことなどを解説し、この技術を活用しようと迷っている方や、ちょっと触って諦めてしまった方に向けた解説をしてみたいと思います。

なぜRoo Code (旧Roo-Cline) なのか

Roo Code (旧Roo-Cline) では何かを開発する指示を出す前に、指示を出す先のAIのモデルを選択します。
現状、Roo Codeは利用できるモデルの幅がClineよりも広く、例えばAmazon Bedrockと接続する場合、Clineでは選べないAmazon Nova Proが選べるなど、選択肢が多くなっています。

以下が、Roo Codeを利用している場合に選べるモデルの選択肢です。
Amazon Bedrockで選べるモデルがずらりと並び、Claude以外の選択肢があると分かります。

一方で、Clineの場合は、記事執筆時点ではAnthropicのClaudeしか選べません。

また、Priceの欄を見ていただくと分かりますが、Amazon Nova ProとClaude 3.5 Sonnetでは、コストに大きな差があります。
Amazon Nova ProでClaude 3.5 Sonnetと同じ体験が得られるかどうかは今後要検証ですが、コストを節約したい方にとっては、Roo CodeとAmazon Nova系の組み合わせが選択肢に入るでしょう。

この他、Roo Codeには、Clineにはない機能が搭載されています。
詳しくは、Roo Codeについて現在最も詳しく解説されている、以下の記事を読むことをお勧めします。

触ってみて感じたプラクティス

ここからは主観に基づく、Roo Codeを使う時のコツと思われるプラクティスをまとめてみたいと思います。
なお、記事執筆 (または更新) 時点の機能に基づく情報であり、お読みになったタイミング次第では、より良いプラクティスが出来ている可能性があることにご留意ください。

1. 曖昧な指示は避けた方が良い

これはRoo Codeを使う時の教訓というよりは、日頃何らかの生成AIを使う時や、ベンダーサポート問い合わせる際にも共通して言える話ですが、例えば「1からアプリケーションを開発したい」と思っている時に 「こんなアプリを作ってください」 と、曖昧 (ざっくり) な指示を出したいケースがあると思います。

例えば、以下の画像のような指示が挙げられます。

この画像を見ると、簡単な指示を出すだけでアプリケーションのコードができていく様が良く分かると思いますが、ここで、この結果を見ると、例えば以下のことが分かります。

AIが開発言語を決めている点
AIが採用するライブラリを決めている点
AIが要件を決めている点
その他

このまま「Save」ボタンを押し続けていくと、AIが提案する要件やコードに沿った成果物が出来上がっていきます。
この内容を全て理解してボタンを押している限りはトラブルになりませんが、もし訳も分からずボタンを押している場合、出来上がってからのトラブルシューティングが非常に難しくなりそうです。

経験のない言語やライブラリのトラブルシューティングを全てAIに任せてしまうと、動作不良が起きた時に、修正指示を適切に出すことが難しくなり、結果、動かないアプリケーションが出来てしまいます。

このようなトラブルを回避するには、以下のことを考慮した方が良いでしょう。

指示に条件を付けるなど、具体的な指示を心がける

例えば、自分のスキル見合いや得意とする環境を意識して「Pythonで開発したい」「コンテナで動かしたい」など、少しでも指示が具体的になるだけで、手に負えないアプリケーションが出来上がる可能性は小さくなります。

指示を早めに細かくやり直す

例えば、先ほどの画面において、PythonではなくRubyで開発したいと思った時には、指示をやり直すことが可能です。
「Save」ボタンを押すのではなく、チャットで指示を出し直せば、コードを書き直すことが出来ます。

このように、AIからの結果を盲目的に鵜呑みにするのではなく、ある程度ポリシーを持って、自分が期待する結果が出るまでの間、AIからの提案を拒否し続けて、指示を出し続けることも大事です。

アプリケーション全体を作ってから指示をやり直そうとすると、前述のようによく分からない状況となった時、そもそもどういう指示を出して良いのかも分からなくなります。
直せなくなれば1からやり直すことになり、これまでの指示で使ったコストが無駄になってしまいます。
コストについては後述しますが、何か1つのアプリケーションを開発しようとする場合に、指示ごとのコストの積み重ねによって、非常に高額となる可能性があります。
コストのことを考えると、モデルの選び方だけでなく、指示の出し方や、やり直し方が重要となります。

2. 小さなアプリケーションを作って改修し続けた方が良い

先ほどの画面を見ても分かるように、曖昧な指示を出して、構成が複雑なアプリケーションを作り出してしまうと、何がどうなっているのか分からなくなり、結局1から作り直すことを繰り返したり、トラブルシューティングができなくなったりするケースがあると考えられます。

一方で、これまで人間が何かのコードを開発するときの行動としては、少しずつ書いては保存して動かしてみて、都度足した動作を確かめていくような作業を繰り返すことが多いのではないでしょうか。

この人間が行ってきた開発体験と、AIが一瞬でアプリケーション全体を開発してしまう体験との間のギャップが大きいと考えられ、このことが 「自動的に全て出来上がるのは確かに凄いけど、危ないし怖い」 のように感じる方を増やしているのではないかと思われます。

そこで、Roo Codeを使いながら、トライアンドエラーを積み重ねていく (小さく開発することを繰り返す) にはどうすれば良いかということを考えてみます。

一つの案として、非常に簡素なモック的アプリケーションをまず作り、そこに「こんな機能を増やしたい」という要望を細かく出し、機能を足していくことを考えてみます。

実際に見ていくとイメージが掴めますが、以下は既に開発が進んでいるコードに対して、特定の関数という限定されたスコープに対して、改修の指示を出すケースです。

このようにスコープを限定して指示を出すと、その指示による変更箇所は限定されやすく、AIによる変更で何がどのように変わっているかを比較的理解しやすいと考えられます。

Roo Codeでこのような小さな変更指示を繰り返せば、開発者の理解の範疇から大きく逸脱することなく、半自動的に少しずつアプリケーションを作り上げていくことができ、確かに生産性を上げることが可能です。

また、気に入らないポイントがあれば「Save」ボタンを押す前に指示をやり直したり、コードを直接変更してから「Save」を押すこともできます。
以下は、AIに提案されたS3バケット名が気に入らなかったため、指示の途中でコードを直接変更した時の様子ですが、Roo Codeは自動的にその変更を読み取り、次の指示を受ける前に反映するようです。
AIによる自動作業の間に、人手の作業を介入させても問題なく動作することが分かります。

なお、Roo Codeの全ての機能を使えば、最初の指示から全自動でタスクを完了させることも可能で、これらが使えれば、主に生産性のメリットが最大になりますが、以下の画像にもあるように、ハイリスクな機能としてマークされており、影響を理解した上で使う必要があります。

3. 必要に応じて外部から情報を与える

Roo Codeでは、チャットで@を先頭につけてURLを与えることで、URLを内部ブラウザで開いて情報を引用することが可能です。
この機能で本当にURLが開けるかどうかを、開発の文脈と全く関係ない、かつ名詞から記事内容を推測することもできないURLを与えて確認してみたところ、確かに与えたURLを開いて情報を得ていることが確認できました。

この機能を使えば、例えばAIが直接学習していない最新のAPIのドキュメントを読み込んで、ドキュメントに書かれたAPIの仕様に基づくコードを書かせるといったことが可能です。

ただし、情報を与える際に注意した方が良いポイントもあります。

pdfは意図通りに読み込めない可能性が高い

URLを介してpdfを読ませようとすると、まず、内部ブラウザ機能でpdfが開かれます。
ここで、1ページ目や2ページ目など、開いた直後の画面でコントロールできる範囲については高精度で読み込むことが可能でしたが、3ページ目以降など、スクロールやページ指定を伴わないと読めない箇所の情報は、試行を繰り返した挙句に、読み込めないケースがありました。

必要に応じて手動でURLを開き、読み込ませたい情報をプロンプトを介して与えることも、時には必要そうです。

内部ブラウザ機能を多用しすぎない

Amazon Bedrock経由でClaudeに接続する場合、同じタスクの中で内部ブラウザを使いすぎると、添付する画像が20枚を超えることはできないというエラーが発生し、その後エラーから戻れなくなるという事象が発生します。

これは、Roo CodeからBedrockに対してAPIをコールする時に、同じタスク内で取得されたブラウザの画面キャプチャを全て送っているためと考えられます。

Claudeに関わらず、添付ファイルの制限があるモデルについては、同様のエラーが発生すると考えられます。

一度エラーが出るとタスクを作り直す必要がありますので、内部ブラウザを使い始めたら適度にRejectして指示を調整するなど、工夫しながら開発を進めましょう。

4. 3つのモードを切り替えながら使う

Roo Codeでは3つのチャットモードがあります。
各モードは特定の目的に最適化されており、適切に使い分けることで開発効率の向上に繋がる可能性があります。

Codeモード

このモードがデフォルトの設定で、コードの作成やタスクの実行を支援するものとなります。
コードの生成、ファイルの編集、ターミナルコマンドの実行など、実際のコーディング作業をサポートするのに最適なモードです。
また、開発中の具体的な実装やデバッグ作業にも優れた能力を発揮します。

Architectモード

このモードに切り替えると、Roo Codeはソフトウェアアーキテクチャの専門家として振る舞うようになります。
例えば、要件をブレークダウンして詳細な技術設計を実行したり、システムアーキテクチャを検討したりすることに適しています。
また、システムの構造や設計パターンを分析し、技術的な意思決定に関するアドバイスを提供することもできます。
多くの場合、出力は.mdファイルにMarkdown形式で記述され、保存されます。
ただし、このモードではコードの生成やコマンドの実行は行えないため、これらを実行したい場合はモードを切り替える (戻す) 必要があります。

Askモード

このモードに切り替えると、Roo Codeは技術アシスタントとして機能するようになります。
例えば、既に構築されたコードベースに関する質問や、現在のコードが何をどのように果たしているのかなどの技術的な概念の深掘りに適しています。
コードの動作や技術的な質問に対する回答も提供されます。
Architectモードと同様に、コードの生成やコマンドの実行は行いません。

モードの使い分けの指針

これらのモードを適切に使い分けることができれば、Roo Codeを活用して、開発プロセスの各フェーズで必要な最適な支援を受けることができます。
例えば、実際のコーディングやデバッグ作業ではCodeモードを、システム全体の設計やアーキテクチャの検討時にはArchitectモードを、コードに関する質問や技術的な概念の確認時にはAskモードを選択するのが効果的でしょう。

カスタムモードを作る

さらに、Roo Codeはカスタムモードの作成もサポートしており、ユーザーの特定のニーズに合わせてエージェントの役割や指示をカスタマイズすることができます。
使い方はチャットで「Create a new mode for ... 」と指示するだけで、指示内容に合わせた定義ファイルが出力されてカスタムモードを使えるようになります。

5. コストを気にしながら利用する

非常に便利なRoo Codeですが、一回あたりの推論にかかるコストは安くても、指示の積み重ねによって開発を進めていく中で、コストは高額になっていきます。

上の図では、このタスクにかかったトータルのコストが$5.8258で、タスク内の指示1つにかかったコストが$0.3791であると分かります。
ドルだと感覚が麻痺しそうですが、関数1つのアップデートのためのタスクで、日本円で¥1,000近く払っている計算です。
一つのタスクを完了するまでの間に、指示を何度か出すことになりますので、開発に没頭したのち、気づくと大きなコストを払っているケースも出てきそうです。

このコストはオンデマンド推論では青天井になりますので、コストの表示を気にしつつ、指示の出し方を調整したり、人手でコードを修正する作業を挟みながら使っていくのが良いでしょう。

このコストについては、人件費との比較という議論もありそうですが、青天井である以上は、トータルコストを気にして使う必要があります。

まとめ

Roo Codeをうまく使いこなせば、アプリケーション開発の生産性が爆上がりすることは間違いありません。
ただ、個人や企業で利用する場合に、ツールの凄さは何となく分かっていても「どう始めるのが良いのだろうか」「大丈夫だろうか」と、漠然とした不安を抱えている方が少なくないのではないかと思います。
また、このRoo CodeなどのAIアシスタント系ツールについては、話題になっているからと使ってみて、あまりの凄さに驚くも、これまでの経験とのギャップでうまく使えなくて諦めてしまったケースもあるかもしれません。

この記事では、自ら触ってみて経験したことをベースに、出来るだけ浮世離れや現実離れしないように考慮して説明をしたつもりですが、内容がこれから利用されようと考えている方の一助になれば幸いです。