Roo Codeルール完全ガイド: .roo/rules/、カスタムモード、モード別指示（2026年版）

Roo CodeはClineのフォークですが、単なるコピーではありません。最大の差別化機能は「モードシステム」です。コーディング、設計、デバッグ、ドキュメント作成といった異なる作業に対して、ツールアクセス権限・ファイル制限・指示セットが異なるAIペルソナを切り替えて使えます。

この記事では .roo/rules/ のディレクトリ構造から、カスタムモードの作成方法、モード別ルールの書き方、4モードを使った実際のプロジェクト設定例まで、Roo Codeのルールシステム全体を解説します。

Roo CodeとClineの違い

Roo CodeはClineをベースにしていますが、ルール設計の観点で重要な違いがいくつかあります。

ルール作成者にとって重要な主な差異:

• カスタムモード: ツール権限とファイルアクセス制限をモード単位で設定できる
• モード別ルールディレクトリ: .roo/rules-{modeSlug}/ にモード固有のルールを配置できる
• オーケストレーターモード: 複雑なタスクをモードをまたいだサブタスクに分解できる
• AGENTS.mdサポート: .roorules に加えてAGENTS.mdも読み込まれる
• スティッキーモデル: モードごとに最後に使ったモデルが記憶される

Clineの .clinerules は全セッションに均一に適用されます。Roo Codeはモードの概念を導入し、「今何をやっているか」に応じて異なるルールセットを自動的に適用します。

ルールファイルの配置場所

Roo Codeはグローバル（全プロジェクト共通）とワークスペース（プロジェクト固有）の2つのスコープをサポートします。

グローバルルール

全プロジェクトに適用されるルールです。

個人的なスタイル（言語設定、出力フォーマット等）をグローバルルールに書いておくと、全プロジェクトで一貫した挙動になります。

ワークスペースルール（プロジェクト固有）

リポジトリ内に配置し、バージョン管理します。推奨ディレクトリ構造:

.roo/
├── rules/                    # 全モード共通ルール
│   ├── 01-project-context.md
│   ├── 02-coding-style.md
│   └── 03-constraints.md
├── rules-architect/          # Architectモード時のみ読み込まれる
│   ├── 01-design-principles.md
│   └── 02-adr-format.md
├── rules-code/               # Codeモード時のみ読み込まれる
│   ├── 01-implementation-rules.md
│   └── 02-test-requirements.md
└── rules-debug/              # Debugモード時のみ読み込まれる
    └── 01-investigation-protocol.md

フォールバック（単一ファイル形式）:

• .roorules — ワークスペース共通のフォールバック
• .roorules-{modeSlug} — モード別フォールバック

ファイルはアルファベット順（ファイル名のみで比較、大文字小文字無視）で再帰的に読み込まれます。シンボリックリンクは最大5階層まで対応しています。

自動スキップされるファイル

.DS_Store、*.bak、*.cache、*.log、*.tmp、Thumbs.db は自動的にスキップされます。手動で除外する必要はありません。

ルールの優先順位

Roo Codeがセッションのコンテキストを構築する際、以下の順序でルールを適用します（後のエントリが前のエントリより優先されます）。

1. グローバル指示（Promptsタブ — “Custom Instructions for All Modes”）
2. モード別指示（Promptsタブ — モード別フィールド）
3. モード別ルールディレクトリ: ~/.roo/rules-{modeSlug}/ → .roo/rules-{modeSlug}/
4. 汎用ルールディレクトリ: ~/.roo/rules/ → .roo/rules/
5. AGENTS.md（roo-cline.useAgentRules が有効な場合）

重要なポイント:

• ワークスペースルールはグローバルルールより優先されます（競合がある場合）
• モード別ルールはグローバルルールを上書きせず、追加されます

.roo/rules/ に書いたルールは全モードで適用されます。.roo/rules-code/ に書いたルールはCodeモード時のみ適用され、.roo/rules/ の内容に追加される形になります。

組み込みモード一覧

Roo Codeには5つのデフォルトモードが含まれています。

同じスラッグで独自のカスタムモードを定義することで、組み込みモードをグローバルまたはプロジェクト単位で上書きできます。

カスタムモードの仕組み

カスタムモードはAIペルソナを定義し、特定のツールアクセスと動作ルールを持たせます。各モードの構成要素:

• スラッグ — URLセーフな識別子（/^[a-zA-Z0-9-]+$/）。ルールディレクトリ名にも使用: .roo/rules-{slug}/
• 名前 — モードセレクターに表示される名前
• ロール定義 — コアペルソナのプロンプト。専門性・スコープ・性格を定義する
• 使用タイミング — オーケストレーターモードがサブタスクを割り当てる際の判断材料
• カスタム指示 — ロール定義とは別の、このモード固有の動作ルール
• グループ — 使用できるツールカテゴリとファイルアクセス制限

ツールグループ

edit にファイル制限をかける場合はタプル形式で記述します:

groups:
  - read
  - - edit
    - fileRegex: \.(md|mdx)$
      description: Markdownファイルのみ
  - command

カスタムモードの設定ファイル

カスタムモードはYAMLまたはJSON形式で定義します。正規表現のエスケープが不要なYAMLが推奨です。

設定ファイルの場所

プロジェクトの .roomodes はグローバル設定の同名スラッグを上書きします。

YAML形式の例

customModes:
  - slug: docs-writer
    name: 📝 Docs Writer
    description: テクニカルドキュメント専門ライター
    roleDefinition: |
      あなたはテクニカルドキュメントライターです。コードベースを読み込んで理解し、
      開発者向けに明確なドキュメントを作成します。ソースコードは変更しません。
    whenToUse: READMEファイル、APIリファレンス、ガイドの作成・更新に使用。
    customInstructions: |
      各概念にコード例を必ず含めること。現在形で記述。25語以内の文を心がける。
    groups:
      - read
      - - edit
        - fileRegex: \.(md|mdx|txt|rst)$
          description: ドキュメントファイルのみ

JSON形式の例

{
  "customModes": [
    {
      "slug": "docs-writer",
      "name": "Docs Writer",
      "roleDefinition": "テクニカルドキュメントライターです...",
      "groups": [
        "read",
        ["edit", { "fileRegex": "\\.(md|mdx|txt|rst)$" }]
      ]
    }
  ]
}

JSONでは正規表現のバックスラッシュを二重エスケープ（\\.）する必要があります。YAMLでは一重（\.）で大丈夫です。

.clinerules からの移行

ClineからRoo Codeに移行する場合、.clinerules は自動的に移行されません。対応表:

移行手順:

# Roo Codeのディレクトリ構造を作成
mkdir -p .roo/rules

# 既存のClineルールを移行
# 単一ファイルの場合:
cp .clinerules .roo/rules/01-project-rules.md

# ディレクトリ形式の場合:
cp .clinerules/* .roo/rules/

移行後は、Clineでは全セッションに均一に適用していたルールを、モード別に分割することを検討してください。実装固有のルールを .roo/rules-code/ に移動し、本当に全モード共通のルールだけを .roo/rules/ に残すと、Roo Codeのモードシステムを最大限に活用できます。

実践例: 4カスタムモードを使ったプロジェクト設定

TypeScript製Webアプリケーションを想定した、4つのカスタムモードを使った完全な設定例です。

ディレクトリ構造

my-project/
├── .roo/
│   ├── rules/
│   │   ├── 01-project-context.md
│   │   └── 02-constraints.md
│   ├── rules-architect/
│   │   └── 01-design-rules.md
│   ├── rules-code/
│   │   ├── 01-typescript-style.md
│   │   └── 02-test-requirements.md
│   ├── rules-debug/
│   │   └── 01-investigation-protocol.md
│   └── rules-docs/
│       └── 01-documentation-style.md
├── .roomodes
└── src/

.roo/rules/01-project-context.md（全モード共通）

# プロジェクトコンテキスト

## 技術スタック
- ランタイム: Node.js 22 + TypeScript 5.5
- フレームワーク: Next.js 15（App Router）
- データベース: PostgreSQL 16 via Prisma ORM
- テスト: Vitest + Playwright

## リポジトリ構造
- `src/app/` — Next.js App RouterのページとレイアウトUIを配置
- `src/lib/` — 共有ユーティリティとビジネスロジック
- `src/components/` — Reactコンポーネント
- `prisma/` — スキーマとマイグレーション（明示的な指示なく変更しない）

## 禁止事項
- npmパッケージは代替案を提示して確認を取ってからインストールする
- `src/generated/` は自動生成ファイルのため変更しない
- mainブランチへの直接プッシュ禁止

.roo/rules-code/01-typescript-style.md

# TypeScript実装ルール

## 型
- `any` は使用禁止。型が不明な場合は `unknown` + 型ガードを使う
- オブジェクト形状にはtypeエイリアスよりinterfaceを優先
- 設定オブジェクトには `satisfies` 演算子を使う

## 関数
- 名前付きエクスポートのみ。ページコンポーネント以外でdefaultエクスポート禁止
- 1関数は40行以内。積極的にヘルパーに切り出す
- 失敗しうる処理には `Result<T, E>` パターンを使う

## React
- デフォルトはServer Components。必要な場合のみ `'use client'` を追加する
- コンポーネント固有のhooksは同ディレクトリに配置する

## インポート
- `@/` プレフィックスによる絶対パスインポートを使用
- バレルエクスポート（`index.ts` での再エクスポート）は禁止

.roo/rules-debug/01-investigation-protocol.md

# デバッグ調査プロトコル

## 修正を提案する前に
1. 最小ケースで問題を再現する
2. 予期しない値が発生している正確な行を特定する
3. テストスイートに同じ問題が既に存在しないか確認する
4. git blameで動作が変わった時点を調べる

## 出力フォーマット
調査結果は必ず以下の構造で出力する:
- **観測された事象**: 現在起きていること
- **期待される動作**: 本来あるべき挙動
- **根本原因**: 症状ではなく実際のバグ
- **修正方法**: 説明付きの具体的なコード変更

## 禁止事項
- 「エラーをcatchしてnullを返す」式の回避策を提案しない — 根本原因を修正する
- デバッグセッション中に関係のないコードを書き直さない
- 最新のコードにバグがあると決めつけない — 実際の呼び出しパスをトレースする

.roomodes

customModes:
  - slug: docs
    name: 📖 Docs
    description: ドキュメントライター — Markdownファイルのみ編集可能
    roleDefinition: |
      あなたはこのプロジェクトのテクニカルドキュメントライターです。
      ソースコードを読んで理解し、開発者向けの明確なドキュメントを書きます。
      全ファイルの読み取り権限がありますが、ドキュメントファイルのみ編集できます。
    whenToUse: READMEファイル、APIリファレンス、ガイド、JSDocコメントの作成・更新に使用。
    customInstructions: |
      このコードベースを知らない開発者が読むことを前提に書く。
      各概念にコード例を必ず含める。現在形で記述する。
    groups:
      - read
      - - edit
        - fileRegex: \.(md|mdx)$
          description: Markdownドキュメントファイル

  - slug: architect
    name: 🏗️ Architect
    description: システム設計とアーキテクチャ決定
    roleDefinition: |
      あなたはソフトウェアアーキテクトです。ファイルではなくシステムで考えます。
      実装前にAPIを設計し、スケーラビリティの制約を早期に特定し、
      重要なトレードオフがある場合はArchitecture Decision Recordを書きます。
    whenToUse: 新機能の設計、アーキテクチャ選択肢の評価、ADR作成に使用。
    customInstructions: |
      推奨する前に必ず3つの代替案を検討する。
      ADRは `.roo/decisions/{date}-{title}.md` 形式で書く。
      観測性・デプロイ性・ロールバック可能性を必ず考慮する。
    groups:
      - read
      - - edit
        - fileRegex: \.(md|yaml|json)$
          description: 設計ドキュメントと設定ファイル

  - slug: debug
    name: 🪲 Debug
    description: 根本原因分析とバグ調査
    roleDefinition: |
      あなたはデバッグの専門家です。症状を抑えるのではなく根本原因を特定します。
      ログを読み、コールスタックをトレースし、問題を解決する最小限の変更を見つけます。
    whenToUse: 何かが壊れていて、修正前に原因を理解する必要がある時に使用。
    groups:
      - read
      - edit
      - command

Roo Code vs Cline ルール比較

根本的な差異はアーキテクチャにあります。Clineは1つのフラットな指示セットを全セッションに適用します。Roo Codeはアクティブなモードに応じて、どの指示セットを組み合わせるかを決定するレイヤードシステムです。

小規模プロジェクトや個人作業では差が出にくいかもしれません。しかし、設計・実装・ドキュメント・デバッグといった異なる作業タイプをまたいで作業するチームにとっては、モードを切り替えるだけで適切なルールが自動的に読み込まれる仕組みは実際の生産性向上につながります。

実践的なヒント

ルールファイルには番号プレフィックスをつける。 ファイルはアルファベット順で読み込まれるので、01-project-context.md が 02-style.md より先に読み込まれます。ルールが互いに参照する場合に読み込み順序を制御できます。

グローバルルールは最小限に保つ。 ~/.roo/rules/ のグローバルルールは全プロジェクトに適用されます。プロジェクト固有のルールは .roo/rules/ に書きましょう。グローバルルールは言語設定や出力フォーマットなど、本当に全プロジェクト共通のものだけに限定します。

Promptsタブで実験する。 Promptsタブを使えばファイルを編集せずに指示を追加できます。うまく機能するものが決まったら、.roo/rules/ の適切なファイルに移して永続化しましょう。

正規表現はRooに書かせる。 公式ドキュメントも明示的に推奨している方法です。^(?!.*(test|spec))\.(js|ts)$ のようなパターンは手書きでミスしやすいため、Roo Codeに生成させるのが確実です。

.roo/ と .roomodes をコミットする。 これらのファイルはプロジェクト内でのAIの動作を定義します。バージョン管理しておけば、チーム全員が一貫した挙動を得られ、ルールの変更をコードと同じようにPRでレビューできます。

FAQ

Roo Codeとは？Clineとどう違う？

Roo CodeはClineのフォークで、カスタムモードを追加した派生実装。Architect / Code / Debug / Ask の専門化AIペルソナを各々独自のツール権限・ファイル制約・指示セットで持つ。Clineが「フラットな1命令セット」だったのに対し、Roo Codeは「アクティブモードがどの命令セットを合成するか決める層別システム」。VS Code拡張という枠組みは同じだが、上に乗ってる権限・挙動モデルがより細かい。

Roo Codeのルールはどこに置く？

3箇所：(1) Global rules ~/.roo/rules/ — マシン全プロジェクト共通。(2) Workspace rules .roo/rules/ — そのプロジェクト限定、git管理OK。(3) Mode-specific rules .roo/rules-{mode}/ — そのモードがアクティブな時だけ。Roo Code は全部 runtime でマージ、衝突時は workspace > global の優先順。

.clinerules と .roo/rules/ の違いは？

.clinerules は プロジェクトルートの単一ファイル（Clineフォーマット）。.roo/rules/ は 複数 markdown ファイルのディレクトリでアルファベット順に load。ディレクトリ方式の方が大規模ルールセットでスケールする — トピック別に分割（01-context.md, 02-style.md, 03-testing.md）すると保守しやすい。Roo Code は後方互換のため .clinerules も読むので段階的移行可能。

Roo Code のビルトインモード（Architect / Code / Debug / Ask）はどう動く？

各ビルトインモードはツール権限と挙動フレーミングが違うプリセット。Code: 実装フル read/write/execute。Architect: 設計議論中心、しばしば read-only か制限付き write。Debug: 診断ステップ重視、テスト能動実行。Ask: read-only、会話的 Q&A。チャットUI のモードセレクタで切り替え、.roo/rules-architect/ などのルールが自動 load。

自分のカスタムモードを作れる？

作れる。.roomodes（プロジェクト）または Prompts タブ UI で定義。各モードに slug（ユニークID）、name（表示名）、roleDefinition（systemプロンプト前置）、groups（ツールグループ：read / edit / browser / command / mcp）、customInstructions（インライン規則）、optional fileRegex（ファイル制約）を指定。例：docs モードを \\.(md|mdx)$ 限定にして edit + read のみ。

Roo Code は AGENTS.md や CLAUDE.md を読む？

直接は読まない。Roo Code が見るのは .roo/rules/、.roorules（legacy）、.clinerules（後方互換）。AGENTS.md や CLAUDE.md がある場合は .roo/rules/00-agents.md に内容コピー or symlink が clean な移行。マルチツール互換性を取るなら AGENTS.md を真実の源にして .roo/rules/ から参照。

Roo Code に特定ファイルを読ませない方法は？

2つ：(1) .rooignore（gitignore形式）でコンテキストから除外。(2) fileRegex をカスタムモード定義で指定して edit を制限（read は ignore がない限り許可）。組み合わせると厳密に制御：secrets/大きなファイルは ignore でグローバル除外、モード別に「触らせたくないパス」を fileRegex で制限。

Roo Code は shell コマンド実行できる？

できる、アクティブモードが command グループ有効なら。各コマンド実行はデフォルトで承認プロンプト。承認不要にするなら Settings → Commands で許可リスト指定。モード別制御：Architect モードは通常 command 無効、Code モードは有効。広範な command 権限は最もリスキーなので絞り込む。

複数のルールファイルが該当する時の優先順位は？

Roo Code は該当する全ルールを context にマージ、ディレクトリ内はアルファベット順 load。スコープ間：workspace .roo/rules/ > global ~/.roo/rules/（衝突時 workspace 勝ち）。モード固有ルール .roo/rules-{mode}/ は一般ルールに 追加で load される（置換ではない）。ディレクトリ内順序を制御するには数字プレフィックス（01-、02-）を使う。

The Prompt Shelfでは、一般的なプロジェクトタイプ向けのRoo Codeルールテンプレートを公開しています。TypeScript、Python、Goなどのスタック向けのテンプレートはギャラリーからご覧ください。