Cline vs Roo Code: ルールファイルシステムの徹底比較（2026年版）

ClineとRoo Codeは、どちらもVS Code上で動くAIコーディングエージェントです。どちらも同じオープンソースコアをベースにしており、プロジェクトレベルのルールファイルをサポートしています。「このディレクトリは触るな」「実装前に必ずテストを書け」といった指示を両者に渡せます。

ただし、ルールの解釈と適用方法には、本番規模のプロジェクトでは無視できない差があります。

ファイル構造: ルールの置き場所

Cline はシングルファイルまたはフラットなディレクトリを使います。

.clinerules           # シングルファイルモード
.clinerules/          # ディレクトリモード
  base.md
  testing.md
  frontend.md

ディレクトリモードでは、Clineはすべてのファイルをアルファベット順に読み込み、単一のルールブロックとして連結します。階層はなく、常にすべてのファイルが読み込まれます。

Roo Code はより構造化されたレイアウトを使います。

.roo/
  rules/              # 全モード共通のルール
    base.md
    security.md
  rules-code/         # Code モード専用
    typescript.md
  rules-architect/    # Architect モード専用
    decisions.md
  rules-debug/        # Debug モード専用
    diagnostics.md

ディレクトリ名は rules-{モード名} というパターンで、rules/ はすべてのモードで読み込まれ、rules-{モード}/ はそのモードがアクティブな時だけ読み込まれます。これが最も重要な構造的違いです。

モード別ルール: Roo Codeの優位性

Clineはシングルモードのエージェントです。一度に一つの動作プロファイルしか持てません。プリセットを切り替えることはできますが、ルールファイルレベルでの「アーキテクトモード vs コードモード」という概念はネイティブにはありません。

Roo Codeには5つの組み込みモードがあります: Code、Architect、Ask、Debug、Orchestrator。各モードは異なるシステムプロンプト、異なるツール権限を持ち、異なるルールファイルを持てます。

実際には、ArchitectモードはすべてのADR参照を必須にできる一方、Codeモードはアーキテクチャガバナンスルールでコンテキストを肥大化させることなく実装の詳細に集中できます。

# .roo/rules-architect/decisions.md

重要な技術的決定には必ず以下を含めること:
1. 関連するADR（docs/adr/XXX.md）への参照
2. 検討した代替案とそれらを採用しなかった理由
3. 既存アーキテクチャへの影響の見積もり

この決定に対するADRが存在しない場合は、先にADRを作成すること。

# .roo/rules-code/typescript.md

- 型アサーションには `as` ではなく `satisfies` を使う
- `any` より `unknown` を優先する。やむを得ず `any` を使う場合は理由とともに eslint-disable コメントを付ける
- 関数コンポーネントのみ。クラスコンポーネント禁止。
- テストはソースファイルと同ディレクトリに置く（`foo.ts` → `foo.test.ts`）

この2つのファイルは決して衝突しません。なぜなら、同じコンテキストに同時に現れることがないからです。

グロブベースの条件付きルール: Clineのアプローチ

Clineにはモードがありませんが、YAMLフロントマターによるファイル単位のルールがあります。

---
globs:
  - "src/**/*.test.ts"
  - "tests/**/*.spec.ts"
---

これはテストファイルです。以下の制約に従うこと:

- `../src/internal` からのインポート禁止 — 公開エクスポートのみ使う
- 各テストファイルにはモジュール名のdescribeブロックが必要
- セットアップには `before` ではなく `beforeEach` を使う（Jest互換性）
- 外部HTTPコールはjest.mockではなくMSWでモックする

Clineがこれらのグロブにマッチするファイルを開くと、このルールセットを読み込みます。テスト以外のファイルに切り替えると、これらのルールを破棄して別のルールを読み込みます。

異なるパッケージで異なる基準を持つモノレポでは特に強力です。Roo Codeで同等のことをやるには、手動でモードを切り替えるかモード検出ロジックを追加する必要があります。

コンテキストバジェットとトークンオーバーヘッド

ルールファイルのすべての行はトークンコストになります。これは両ツールに共通ですが、読み込み戦略が異なります。

Cline はグロブフィルタリングされたファイルを除き、すべての .clinerules コンテンツを無条件に読み込みます。1,000行のルールディレクトリは、あらゆるツール呼び出しで1,000行のコンテキストオーバーヘッドになります。

Roo Code は rules/ を無条件に読み込みますが、rules-{モード}/ はアクティブなモードでのみ読み込みます。グローバルルールが500行、モード別ルールが300行の場合、最大800行のコストで済みます。

実際的な意味: 特殊なコンテキストが多いプロジェクトでは、Roo Codeのモードシステムによってコンテキストウィンドウを肥大化させずにより豊富なルールを書けます。シングルモードワークフロー（大半の個人プロジェクト）では差は軽微です。

Roo Codeのカスタムモード

Roo Codeでは、5つのデフォルト以外に完全にカスタムのモードを定義できます。.roomodes で設定します。

{
  "customModes": [
    {
      "slug": "review",
      "name": "Code Review",
      "roleDefinition": "あなたはコードを正確性・セキュリティ・保守性の観点でレビューするシニアエンジニアです。新しいコードは書かず、コメントと提案のみを行います。",
      "groups": ["read"],
      "customInstructions": "フィードバックは番号付きリストで。Critical / Warning / Suggestion でグループ化すること。"
    }
  ]
}

次にルールを追加します。

.roo/rules-review/
  review-checklist.md
  security-patterns.md

Clineに同等の機能はありません。複数の .clinerules ファイルを手動で切り替えることで似たことはできますが、それはシステムではなく手動ワークフローです。

MCPサーバーのパーミッション

両ツールともMCPサーバーをサポートしています。違いはパーミッションのスコープにあります。

Clineは cline_mcp_settings.json でグローバルまたはプロジェクト単位でMCPアクセスを付与します。モードごとのMCPスコープはありません。

Roo Codeのカスタムモード設定には groups キーがあり、そのモードで利用可能なツールグループ（ひいてはMCPサーバー）を制御します。groups: ["read"] の review モードは、ファイルを書いたりシェルコマンドを実行したり書き込み可能なMCPツールを呼んだりできません — 指示で止めているのではなく、構造的に能力が存在しません。

チームでレビューモード中にAIがコードを変更できないことを保証したい場合、「しないよう指示する」ではなく「できない構造にする」というアプローチは大きく異なります。

どちらを選ぶか

Cline が向いている場合:

• シングルモード、ファイル中心のワークフロー
• グロブベースの条件付きルールが必要（Roo Codeに直接の同等機能なし）
• よりシンプルな設定面を好む

Roo Code が向いている場合:

• 設計・実装・デバッグのコンテキストを頻繁に切り替える
• モードスコープのMCPパーミッションが必要（指示ではなく構造的な安全性）
• 異なるメンバーが異なるモードで作業するチームワークフローを構築している
• 同一プロジェクト内に特化したカスタムエージェント（レビュアー、ドキュメンター、テスター）を作りたい

同じプロジェクトでClaude Codeも使っている場合、両ツールはCLAUDE.mdも読みます。ルールシステムは加算的なので、.clinerules・.roo/rules/・CLAUDE.md を同時にアクティブにできますが、その場合は競合がないか確認が必要です。

実践的な推奨

個人開発者なら、差はほとんどありません。慣れた方を選んでルールを書けばいい。

チームなら、Roo Codeのモードシステムはその複雑さに値します。「このモードはコードを書けない、読むだけ」という特性は、.clinerules の指示だけでは再現できない意味のある安全性です。

ファイルタイプが大きく異なるモノレポなら、ClineのグロブマッチングがRoo Codeのモードシステムでは直接提供できない精度をもたらします。

大規模チームの理想的な構成: モードスコープのワークフローにRoo Codeを使い、普遍的な基準は共有の rules/ ディレクトリに置き、役割固有の動作はモード別ディレクトリに。各ルールファイルは200行以下に。コンテキストオーバーヘッドは四半期ごとに見直す。