ClineはVS Codeエコシステムで最も優秀なAIコーディングエージェントの一つだが、設定なしの素の状態では汎用的な出力しか生まれない。.clinerulesはそのギャップを埋めるファイル（またはファイルのディレクトリ）だ。使用しているスタック、コードのフォーマット方法、絶対にやってはいけないこと、コードベースのどの部分にどのルールを適用するかをClineに正確に伝える場所である。
このガイドでは必要なものを全て解説する：ファイル形式、YAMLフロントマター、glob条件付きルール、グローバルとワークスペースの優先順位、v3.13で追加されたトグル可能なUI、そしてReact・Python・Go・TypeScript・モノレポ設定用の5つのコピペ可能テンプレート。
.clinerules ファイルとは何か、なぜ重要か
Clineがワークスペースを開くと、プロジェクトルートの.clinerulesを探し、見つかったものをシステムプロンプトのコンテキストに読み込む。そのセッションでClineが実行する全てのタスク——コードの記述、質問への回答、ターミナルコマンドの実行——がそのルールに影響される。
.clinerulesがなければ、Clineはデフォルトのトレーニングとプロンプトに打ち込む内容に基づいて動作する。単発タスクならそれで機能するが、チーム全体や長期プロジェクトでは崩壊する。同じミスを繰り返し修正する羽目になる：間違ったインポートスタイル、エラーハンドリングパターンの欠如、間違った形式での出力。
.clinerulesはこれを根本から解決する。一度書いたルールは、そのリポジトリでClineを使う全員のセッションに自動的に適用される。
実際の効果：
- Clineは発明した命名規則ではなく実際の命名規則を使う
- 汎用的なtry/catchボイラープレートではなくエラーハンドリングパターンに従う
- ロックされたディレクトリへの変更を提案しない
- 条件付きルールにより、手動でコンテキストを切り替えることなく
src/api/とsrc/ui/に異なる動作を適用できる
単一ファイル vs .clinerules/ ディレクトリ
Clineはルールに2つの形式をサポートしており、どちらを使うかはプロジェクトの複雑さによる。
単一ファイル（.clinerules）
最もシンプルな方法。プロジェクトルートに.clinerulesという名前の単一ファイルを作成し、Markdownでルールを書く：
# プロジェクトルール
## スタック
- Node.js 20 + TypeScript 5
- React 19 + Vite
- Tailwind CSS v4
## コードスタイル
- 関数コンポーネントのみ。クラスコンポーネント禁止。
- named exportを使用。default export禁止。
- 設定オブジェクトには`const`アサーションを優先。
## テスト
- Vitestでユニットテスト、Playwrightでe2e。
- テストファイルはソースファイルの隣に置く：`foo.ts`と`foo.test.ts`。
- ビルド失敗を修正するためにテストをスキップしない。
## やってはいけないこと
- `src/generated/`を変更しない。自動生成ファイル。
- 確認なしにパッケージをインストールしない。先にトレードオフを説明する。単一ファイル形式は約50ルールまでのプロジェクトに適している。それ以上になると保守性が下がり、読み込み時間も増える。
ディレクトリ形式（.clinerules/）
大きなプロジェクトでは、プロジェクトルートに.clinerules/というディレクトリを作成し、その中に複数の.mdファイルを置く。Clineは全てを読み込む：
project-root/
├── .clinerules/
│ ├── coding-standards.md
│ ├── architecture.md
│ ├── testing.md
│ ├── api-patterns.md
│ └── security.md
├── src/
└── package.jsonディレクトリ内の各ファイルは独立したルールドキュメントだ。Clineはコンテキストに注入する前にアルファベット順で連結するため、ルールの順序が重要な場合は名前付けが重要になる——番号でプレフィックスを付けて順序を制御する（01-stack.md、02-patterns.md）。
ディレクトリ形式ではYAMLフロントマターによる条件付きルールも使えるようになる——これが本当のパワーだ。
YAMLフロントマターと条件付きルール
これはほとんどのClineユーザーが見落としている機能だ。.clinerules/内の個々のルールファイルには、そのルールがいつ有効化されるかを制御するYAMLフロントマターを含めることができる。
最も便利なフロントマターフィールドはpaths——コードベースの特定の部分にルールファイルを限定するglobパターン（または配列）だ。
基本的な条件付き構文
---
paths:
- "src/api/**"
- "src/services/**"
---
# APIレイヤールール
このレイヤーの全関数は`Result<T, Error>`型を返す必要があり、直接throwしない。
バリデーションは境界で行う——内部関数はデータが有効であると仮定できる。
JSONリクエスト/レスポンスフィールドにはデータベースカラム名に関係なくcamelCaseを使用する。Clineがsrc/api/**またはsrc/services/**にマッチするファイルで作業している場合、このルールファイルは有効だ。src/components/Button.tsxで作業している場合、これらのAPIルールは読み込まれない——コンテキストを集中させる。
フロントマターフィールド
| フィールド | 型 | 説明 |
|---|---|---|
paths | string or string[] | Globパターン。アクティブファイルがマッチする場合のみルールを適用。 |
description | string | トグル可能なUIに表示される人間が読めるラベル。 |
alwaysApply | boolean | パスマッチに関係なくこのファイルを強制的に読み込む。デフォルトはディレクトリファイルでfalse。 |
完全な注釈付き例：
---
description: "データベースとORMの規約"
paths:
- "src/db/**"
- "src/models/**"
- "migrations/**"
alwaysApply: false
---
# データベースルール
- データベースアクセスには全てPrismaを使用。`src/db/queries/`内の明示的なコメント付きの場合のみrawSQLを許可。
- フィーチャーコードで`prisma.$executeRaw()`を呼び出さない。
- マイグレーションファイルは追記専用。既存のマイグレーションを編集しない。
- モデル名はPascalCase単数形：`User`（`Users`や`user`ではなく）。グローバルとワークスペースのルールの優先順位
Clineには2つのルール保存場所があり、複数のプロジェクトをまたいで作業する場合はその関係を理解することが重要だ。
グローバルルール
マシンの~/.cline/rules/に保存される。Clineで開く全てのワークスペースに適用される。単一プロジェクトを超えた個人的な好みにグローバルルールを使用する：
# ~/.cline/rules/personal.md
## 私の好み
- コードを書く前に変更が何をするかを必ず説明する。
- リファクタリングを依頼された場合、まずコードブロックでbefore/afterの差分を示す。
- 賢いより明示的を優先する。賢いバージョンが欲しければ依頼する。
- コミットメッセージを生成する際はConventional Commitsフォーマットに従う。ワークスペースルール
プロジェクトルートの.clinerulesまたは.clinerules/に保存される。これらはプロジェクト固有であり、チーム全体が恩恵を受けられるようバージョン管理にコミットすべきだ。
ワークスペースルールはコンフリクト時にグローバルルールより優先される。 グローバルルールが「常に2スペースインデントを使用」と言っていても、ワークスペースの.clinerulesが「4スペースインデントを使用」と言っていれば、Clineはワークスペースのルールに従う。
これは理にかなっている：プロジェクトの規約が個人のデフォルトより優先されるべきだ。
推奨される分割
| グローバル（~/.cline/rules/） | ワークスペース（.clinerules/） |
|---|---|
| レスポンス形式の好み | スタックとフレームワークのバージョン |
| 個人的な説明スタイル | 命名規則 |
| コミットメッセージ形式 | ファイルとディレクトリ構造 |
| 出力の冗長性 | テスト要件 |
| 言語の好み | 変更してはいけないもの |
トグル可能なルールUI（v3.13以降）
Cline v3.13でVS CodeのClineサイドバーからアクセスできるルール管理パネルが追加された。グローバルとワークスペース両方の全アクティブなルールファイルがトグルスイッチ付きで一覧表示される。
これは以下の用途に便利だ：
ルールのデバッグ: Clineが予期しない動作をしている場合、ルールを1つずつ無効化して原因を特定できる。
コンテキストの切り替え: セキュリティ監査を行っている？.clinerules/ディレクトリを永続的に再構成せずに、一時的に厳格なセキュリティルールをトグルオンにできる。
オンボーディング: 新しいチームメンバーは、リポジトリ設定を掘り起こすことなく、どのルールがアクティブでその理由を確認できる。
descriptionフロントマターフィールドが各トグルの隣に表示されるラベルになる。なければClineはファイル名を使う——問題ないが、明確な説明を書く価値はある。
UIでオフにトグルされたルールはVS Codeセッション間で保持されない。プロジェクトでルールを永続的に無効化したい場合は、ディレクトリから削除するか、非アクティブであることを示すコメントを追加する。
5つのコピペ可能テンプレート
1. React + TypeScript プロジェクト
---
description: "React + TypeScript規約"
alwaysApply: true
---
# React + TypeScript ルール
## スタック
- React 19、TypeScript 5.5+、Vite 6
- スタイリングにTailwind CSS v4。CSSモジュールもstyled-componentsも不使用。
## コンポーネント
- 関数コンポーネントのみ。クラスコンポーネント禁止。
- Propsインターフェースはクラス名をPascalCase：`ButtonProps`（`IButtonProps`ではなく）。
- named exportのみ。`export function Button()`（`export default Button`ではなく）。
- 1ファイル1コンポーネント。ファイル名はコンポーネント名に一致。
## フック
- カスタムフックは`src/hooks/`に置く。ファイル名：`use-feature-name.ts`。
- 条件付きでフックを呼び出さない。
## ステート
- ローカルステートは`useState`。サーバーステートはReact Query（TanStack Query v5）。
- 要件が明示的に求めない限りReduxを避ける。
## TypeScript
- Strictモード有効。`any`禁止。型が真に不明な場合は`unknown`を使用。
- オブジェクト形状にはinterfaceよりtype aliasを優先。
- 全ての非同期関数は明示的な`Promise<T>`型を返す。
## テスト
- Vitest + React Testing Library。共置テストファイル：`Button.test.tsx`。
- 実装ではなく動作をテスト。スナップショットテスト禁止。2. Python プロジェクト
---
description: "Pythonプロジェクト規約"
alwaysApply: true
---
# Python ルール
## スタック
- Python 3.12以上。前方参照には`from __future__ import annotations`を使用。
- `uv`で依存関係管理。`requirements.txt`は自動生成。
- フォーマット：`ruff format`。リント：`ruff check`。型チェック：`mypy --strict`。
## コードスタイル
- 全関数シグネチャに型ヒント（返り値の型を含む）。
- 構造化データには生dictではなくdataclassかPydanticモデルを優先。
- `pathlib.Path`を全面的に使用。パスを文字列として連結しない。
- f文字列のみ。`.format()`や`%`フォーマット禁止。
## エラーハンドリング
- 具体的な例外をraiseする。`raise Exception("message")`は禁止。
- カスタム例外は`src/exceptions.py`に。
- 全てのリソース取得（ファイル、接続、ロック）にコンテキストマネージャを使用。
## テスト
- `pytest-asyncio`付きpytestで非同期テスト。
- テストファイルは`tests/`ディレクトリに（`src/`構造を反映）。
- フィクスチャは`conftest.py`に。モジュールレベルのセットアップを避ける。3. Go プロジェクト
---
description: "Goプロジェクト規約"
alwaysApply: true
---
# Go ルール
## スタック
- Go 1.22以上。モジュールパスは`go.mod`から。
- 標準ライブラリを優先。サードパーティの依存関係は全て正当化する。
## コードスタイル
- Effective Goに従う: https://go.dev/doc/effective_go
- エラー文字列は小文字で末尾に句読点なし。
- 名前付き返り値はドキュメントを補助する場合のみ。簡潔さのためには使わない。
- I/Oを実行する関数の最初のパラメータとして`context.Context`を使用。
## エラーハンドリング
- エラーは値。全エラーを明示的に処理。`_ = someFunc()`は禁止。
- `fmt.Errorf("doing X: %w", err)`でエラーをラップしてチェーンを維持。
- センチネルエラーはパッケージレベルの`var`に：`var ErrNotFound = errors.New("not found")`。
## テスト
- テーブル駆動テスト。テストファイル：同パッケージ内の`foo_test.go`。
- テストユーティリティ関数内で`t.Helper()`を使用。
- インテグレーションテストは`tests/integration/`内に`//go:build integration`ビルドタグ付きで。4. TypeScript Node.js バックエンド
---
description: "TypeScript Node.jsバックエンド規約"
alwaysApply: true
---
# TypeScript バックエンド ルール
## スタック
- Node.js 20 LTS、TypeScript 5.5+
- Fastify v5でHTTP。PrismaでORM。
- 全APIバウンダリでランタイムバリデーションにZod。
## アーキテクチャ
- レイヤー順序：routes → handlers → services → repositories → database。
- handlersにDBコールを置かない。repositoriesにビジネスロジックを置かない。
- Servicesは可能な限りpure function。依存関係を注入、シングルトンを避ける。
## TypeScript
- tsconfig で`strict: true`。`any`禁止。コメントなしの型アサーション（`as T`）禁止。
- enumを避ける。代わりに`as const`を使った`const`オブジェクトを使用。
- バレルエクスポート（`index.ts`）はレイヤー境界のみ、レイヤー内部では使わない。
## 非同期処理
- 全I/OはAsync/await。コールバック禁止。`.then()`チェーン禁止。
- ループ内で`await`しない。並列作業には`Promise.all()`を使用。5. モノレポ設定
---
description: "モノレポルート — 常に適用"
alwaysApply: true
---
# モノレポルートルール
## 構造
- `apps/` — デプロイ可能なアプリケーション（web、api、worker）
- `packages/` — 共有ライブラリ（ui、utils、types、config）
- `tools/` — ビルドスクリプト、コードゲン、開発ツール
## パッケージマネージャー
- pnpmワークスペース。このリポジトリで`npm install`や`yarn`を使わない。
- 特定のワークスペースに依存関係を追加：`pnpm --filter @acme/web add react`。
- 共有開発依存関係はルートの`package.json`に。
## 共有パッケージ
- `@acme/types` — アプリ間で共有されるTypeScript型。ランタイムコードなし。
- `@acme/ui` — Reactコンポーネントライブラリ。ここからインポートし、コンポーネントを重複させない。
- `packages/*`内で`apps/*`からインポートしない。方向：packages → appsのみ。他のフォーマットからの移行
.cursorrulesから
.cursorrulesファイルがある場合、構造はそのまま移行できる。コンテンツはすでにMarkdown互換のルール文章なので、移行は簡単だ：
- プロジェクトルートに
.clinerulesを作成 .cursorrulesからコンテンツをコピー- Cursor固有の指示（
@-mentionsや特殊Cursorコマンドなど）をプレーンな英語に調整
重要な違い：.cursorrulesはYAMLフロントマターやglobベースの条件付きルールをサポートしない。コメントで区切られたコードベースの異なる部分のセクションがある場合、適切なpathsフロントマター付きの.clinerules/ディレクトリに分割する良い機会だ。
CLAUDE.mdから
CLAUDE.mdはClaude Codeの.clinerules相当のファイルだ。コンテンツのセマンティクスはほぼ同一——どちらもAIコーディングエージェントへの指示セットだ。主な違い：
- CLAUDE.mdはその行以降のコンテンツを無視する
!プレフィックスをサポートする（Clineはサポートしない） - CLAUDE.mdにはスコープ階層（プロジェクト、サブディレクトリ、ホームディレクトリ）が組み込まれている；ClineはPaths frontmatterフィールドを使う
- Claude Code固有のディレクティブ（
STOP_WORDS、パーミッションブロック）にはCline相当がなく削除できる
実際の移行パス：CLAUDE.mdを.clinerulesにコピーし、Claude Code固有のディレクティブを削除し、ファイルが長い場合はオプションでディレクトリ構造に分割する。
よくある間違い
全てを一つの巨大なファイルに詰め込む。 大きなコンテキストブロックはプロンプトの後半部分が注意を奪い合う際にモデルによって優先度が下げられる。ルールが2,000語を超える場合は、ディレクトリに分割して条件付き読み込みを使用する。
曖昧な禁止事項を書く。 「悪いコードを書かない」は何も意味しない。「any型を使わない。コンパイル時に型が不明な場合はunknownを使い、型ガードで絞り込む」は実行可能だ。
ディレクトリモードでalwaysApplyフィールドを省略する。 .clinerules/ディレクトリを使用する場合、pathsフロントマターを持つファイルはアクティブファイルがそれらのパスにマッチする場合のみ読み込まれる。特定のルールを常に読み込みたい（スタック概要、グローバル規約）場合は、alwaysApply: trueを設定するか、フロントマターなしのファイルに入れる。
.clinerules/をバージョン管理にコミットしない。 これらのファイルはプロジェクト設定だ。tsconfig.jsonや.eslintrcと並んでgitに属する。チーム全体が一貫したClineの動作から恩恵を受け、ルールの変更はコードと同じレビュープロセスを経るべきだ。
どちらが優先されるかを知らずにグローバルとワークスペースのルールを重複させる。 ワークスペースが常に優先される。矛盾するルールがあってClineが予期しない動作をしている場合は、~/.cline/rules/とプロジェクトの.clinerules/の両方を確認してコンフリクトを見つける。
デバッグにトグル可能なUIを使わない。 Clineが予期しないことをしている場合、v3.13以降のルールパネルが最初に確認すべき場所だ。全てのルールファイルを読み通してコンフリクトを見つけようとするのではなく、ルールを1つずつトグルオフにして原因を特定する。
.clinerulesは投入した時間に見合う成果をもたらす。よく構成されたルール設定は、修正が少なくなり、より予測可能な出力を生み、汎用的なコードパターンではなく実際にプロジェクトを理解したClineをもたらす。スタックに最も近いテンプレートから始めて、適用されないものを削除し、何を明示的に言う必要があるかを発見するにつれて拡張していく。