Roo Code：ローカルコードエージェントは、 エディタ

#概要

入力中に次の行を予測するコード補完と、継続的な監督なしにコンテナ内で単独で作業する自律エージェントとの間には、中間的なカテゴリーがあります。それが、エディタ内のエージェントです。開いているプロジェクトを参照し、ファイルの階層構造と依存関係を理解して、変更案を提示します。変更がディスクに反映される前に利用者が承認し、ターミナルでコマンドを実行する際も、毎回利用者の明示的な許可を得ます。Roo Codeはこのカテゴリーに属し、基本的な考え方を広く共有するClineなどのプロジェクトと並ぶ存在です。

会話型アシスタントと比べた利点は、コピー＆ペーストが不要になることです。変更は対象ファイルの差分（diff）として提示されます。自律型エージェントと比べた利点は、各ステップに自分が関与し続けられることで、モデルが小さいほど、その重要性は高まります。Apache 2.0ライセンスで公開されたこのプロジェクトは、2024年末の立ち上げ以来、GitHubのスター数が20,000を超えていました。競争が非常に激しくなった分野で急速に普及していたのです。ただし、これは以下で詳述する終了発表より前のことです。

#拡張機能は2026年5月から停止中：その影響

これはこのガイドで最も重要な情報ですが、今もオンラインで公開されている多くのチュートリアルでは触れられていません。創業者のMatt Rubensは2026年4月21日、Roo Codeの終了を発表しました。最終リリースは2026年5月15日で、その後GitHubリポジトリはアーカイブされ、読み取り専用となり、セキュリティ修正を含め、今後は一切の修正が行われません。リポジトリを直接確認しても、アーカイブ済みで、最終コミットの日付が2026年5月15日であることが確認できます。チームは、Slackから操作するクラウドエージェントのRoomoteに全面的に活動を移しました。チーム自身の見解では、コードエディタはもはやAIエージェントと作業する際の未来の形ではないと判断したためです。

#モードの種類と、それが良い理由

Roo Codeの特徴は、ペルソナを分離している点にあります。デフォルトで5つのモードが組み込まれています。Codeは、ツールへの完全なアクセス権を持ち、コードの作成と修正を行うモードです。Askは、詳細な回答を提供する技術アシスタントですが、何も変更しません（読み取りとMCPのみ）。Architectは、行動する前に設計することを目的とした、書き込み権限がMarkdownファイルに限定されたプランナーです。Debugは、完全なアクセス権を持ち、体系的な診断を行うモードです。Orchestratorは、「Boomerang Mode」とも呼ばれ、複雑なタスクを分割して他のモードに委任します。独自の指示と権限を持つ別のモードを定義することも可能です。

ローカルモデルでは、これは単なる使いやすさ以上の意味を持ちます。書き込み権限のないAskモードは、小さすぎるモデルが余計なことまでしようとしてファイルを変更してしまう、という種類の事故をなくします。モードごとに権限を制限することは、小型モデルをリスクなく使えるようにするための主要な手段です。また、それによってRoo Codeは、エージェント全般における望ましいセキュリティ対策に最も近づきます。その原則は、各役割に必要な権限だけを与え、それ以上は決して与えないことです。

#ローカルモデルに接続する

1. 01
   モデルを提供する

   Ollama、またはOpenAI互換の任意のエンドポイント。個人利用ならOllamaで十分です。
2. 02
   拡張機能で Ollama を提供元として選択する

   モデル名またはタグを入力する。デフォルトのベースアドレスはhttp://localhost:11434です。APIキーが必要なのは、お使いのOllamaサーバーが要求する場合だけです。
3. 03
   適切な設定箇所でコンテキストウィンドウを調整する

   これは、最もよく文書化されている落とし穴です。デフォルトでは、Roo Codeは拡張機能固有の値ではなく、OllamaモデルのModelfileで定義された num_ctx 設定に従います。そのため、コンテキストを増やすには、Roo Codeの設定ではなく、Ollama側のModelfileまたは環境変数で設定します。
4. 04
   Ask モードで開始する

   どのような変更も許可する前に、読み取り権限しかないモードでプロジェクトについて3つ質問すると、モデルがコードを実際にどこまで理解しているかを率直に評価できます。

#実際、どのモデルを選ぶべきか

この課題では、中規模のコード特化モデルが、より大きな汎用モデルをほぼ常に上回ります。学習時に一般的な文章よりも、厳密な形式やdiffに多く触れているためです。差が特に表れるのは、コンテキストや行番号のエラーなしに、一度で適用できるdiffを生成する能力です。実際には、この技術的な細部が、モデルの回答全般の品質よりも重要です。

• Cline：もう一つの編集エージェントとの比較
• Aider：同じ考え方をターミナルで
• ローカルモデルにコードをレビューしてもらう

#Orchestrator：複雑なタスクを分割する

Orchestratorモード（公式ドキュメントではBoomerang Modeとも呼ばれます）は、一度の処理では大きすぎるタスクへのアプローチ方法を変更します。「私のアプリケーションに認証を追加して」と直接依頼するのではなく、Orchestratorに目標を説明します。Orchestratorはそれをサブタスクに分割し、専門モードに委任します。Architectが計画を立て、Codeが実装を行い、途中でテストが失敗した場合はDebugが対応します。

1. 01
   手順ではなく、目的を説明する

   変更するファイルの一覧ではなく、期待する結果をOrchestratorに伝える。作業を具体的に分解するのは、このモードが担う役割だからです。
2. 02
   各サブタスクの結果が返ってくるのを待ってから、次に進む

   このモードでは、委任した作業の結果を待ってから、次の作業を委任します。そのため、直前に行われた内容を見直すための自然な区切りができます。
3. 03
   各ステップで現在のモードを確認してください

   インターフェースには、その時点で動作しているモードが表示されます。読み取りだけにとどまるはずのタスクで、予期せずCodeモードに切り替わることが、最優先で注意すべき兆候です。

ローカルモデルでは、この分割に直接測定できるコストが伴います。委任したサブタスクごとにモデルを新たに呼び出すため、その都度、一連の生成処理が行われ、コンテキストの読み込みにも時間がかかります。複数のファイルと複数の異なる検討事項を含む、本当に複合的なタスクならOrchestratorを使う価値があります。単純な変更では、具体的な利点がないままやり取りが増えるだけで、Codeモードを直接使う方が、まったく同じ最終結果にはるかに速く到達できます。

#適切に活用する

範囲を絞ったタスク

「このモジュールを改善してください」ではなく、「このパラメータを追加し、呼び出し元の3つの関数にも渡すようにしてください」と依頼します。依頼が具体的であるほど、モデルが独自に解釈する余地は小さくなります。そして、期待外れの差分の大半を生み出すのは、まさにその解釈の余地です。

変更のないクリーンなリポジトリ

クリーンな作業ツリーを持つ専用ブランチで作業することで、各 diff が一目で読みやすく、各エラーは revert された 1 つのコミットで取り消すことができ、エージェントの変更と自分の進行中の変更を解きほぐす必要がなくなります。

差分を一つずつ見直す

ローカルモデルは、もっともらしく、コンパイルが通り、ざっと見直しても問題なさそうに見える変更をしばしば生成します。しかし、その変更が実際には意図した動作をしないことがあります。コンパイルが通ることは、正しさの証明にはなりません。構文エラーがないことを示すだけです。

外部コンテンツを警戒する

チケット、依存ライブラリのドキュメントファイル、コード内にすでにあるコメントには、利用者ではなくエージェントに向けた指示が含まれている可能性があります。それが具体的にどのような影響を及ぼすかは、以下のセキュリティの節を参照してください。

#トラブルシューティング：よくある問題

ローカルモデルで処理がうまく進まない場合、その大半は、見分けやすく互いに区別しやすい3つの原因によるものです。モデル自体の品質を疑う前に、必ずこれらを確認してください。

3つのケースのいずれでも、最初に考えるべきなのは「どのモデルを選べば最もよいか」ではなく、「モデルが回答した時点で、実際にどのようなコンテキストと権限が与えられていたか」です。コンテキストが途中で切り詰められていると、能力不足のモデルと見かけ上まったく同じ症状が現れますが、真の原因が特定されれば、診断にかかるコストも解決策も大きく異なります。

#自分のプロジェクトを読み取るエージェントに固有のリスク

編集エージェントは、その性質上、自分で書いたものではないコンテンツを参照します。サードパーティ製の依存パッケージのREADME、会話に貼り付けられたチケット、外部からクローンしたリポジトリにすでにあるコメントなどです。こうしたコンテンツに、あなたではなくモデルに向けた指示が含まれていても、それを防ぐものはありません。これこそがプロンプトインジェクションの仕組みであり、下記の専用ガイドで詳しく説明しています。ターミナルと書き込み権限を持つエージェントは、ツールを持たない単なるチャットボットよりも、この種の攻撃にとってはるかに魅力的な標的です。

まさにここで、Roo Codeのモードは、単に作業を整理しやすくする機能から、具体的なセキュリティ対策へと変わります。読み取りだけに限定されたAskモードは、チケットに隠された指示を読んでいても、基盤となるモデルがその指示に影響されていても、その指示を実行することはできません。この保護は、より賢いモデルが罠を見抜くことによるものではありません。モデルが何をしようと決めたかにかかわらず、指示の実行を技術的に不可能にする権限の範囲によるものです。

• プロンプトインジェクション：ローカル実行は対策になりません
• 出典：Roo Code モードの公式ドキュメント
• 出典：Ollamaプロバイダーの公式設定ガイド
• 出典：GitHub上のRoo Code公式リポジトリ（アーカイブ済み）
• 出典：Roo Codeの終了と代替案に関する報道（専門メディア）

#FAQ