.clinerulesとは？書き方・配置場所とCline v4.1での読み込み仕様

.clinerulesは、AIコーディングエージェント「Cline」に毎回守らせたい指示をMarkdownで置いておく場所です。命名規則やテストの書き方、触ってはいけないディレクトリをここに書くと、タスクのたびに同じ説明を繰り返す必要がなくなります。

この記事では、2026年9月24日公開の最新版v4.1.21を前提に、ファイルの置き場所と書き方を整理します。あわせて、ソースコードと公開SDK（@cline/core 0.0.86）を実際に動かして確かめた読み込み順・同名ルールの扱い・paths条件の現状も載せます。公式Rulesドキュメントの説明と実装が食い違っている箇所があるためです。

まとめ：.clinerulesの要点（v4.1.21時点）

• ワークスペースのルールはプロジェクト直下の.clinerules/か.cline/rules/に、1ファイル1テーマのMarkdownで置く。両方あれば両方読まれる
• 読み込まれる拡張子は.md・.markdown・.txtの3種類。サブフォルダの中身はルールとして読まれない
• 全ルールはシステムプロンプトの「# Rules」節に、ルール名の順に並べ替えて連結される。ワークスペースとグローバルで食い違う指示を自動で解決する処理はない
• 拡張子を除いたファイル名が同じルール（大文字・小文字は区別しない）がワークスペースとグローバルの両方にあると、グローバル側だけが残る
• ドキュメントにあるpathsの条件付きルールは、v4.1.21では評価されず常に読み込まれる。止めるならfrontmatterにenabled: falseと書く
• .cursorrulesと.windsurfrulesはv4.1.21では読み込まれない。共通の指示はAGENTS.mdか.clinerules/に移す
• 「.clinerulesから.mdcへ移行」という解説は誤り。.mdcはCursorのルール形式で、Clineの仕様ではない

以下、配置場所、書き方、実測した読み込みの挙動、効かないときの確認手順の順に説明します。

.clinerulesの役割とシステムプロンプトへの入り方

.clinerulesは設定ファイルというより「毎回プロンプトに貼り付けられる指示書」です。Clineはタスク開始時にルールファイルを読み、システムプロンプトの末尾に次の形で差し込みます（v4.1.21のプロンプト生成処理のformatRulesForSystemPrompt）。

# Rules
## 01-coding
- 変数はcamelCase、定数はUPPER_SNAKE_CASE
- 例外はsrc/utils/errors.tsのAppErrorで包む

## testing
- ビジネスロジックには単体テストを必ず書く

「## 」の後ろには通常、拡張子を除いたファイル名が入ります。frontmatterにnameがあればその値が使われ、プロジェクト直下のAGENTS.mdは「Workspace AGENTS.md」という名前になります。モデルはこの見出しを手がかりに指示の範囲を読み取るため、ファイル名はそのまま見出しとして通じる名前にしておきます。

ルールは入力トークンを毎リクエスト消費します。公式ドキュメントも、スタイルガイドを丸ごと貼らず、詳細は外部資料へのリンクに逃がすよう注意書きを入れています。

「.mdcへ移行した」という解説の誤り

国内の解説記事には「.clinerulesは非推奨になり.mdcファイルへ移行した」と書くものがありますが、これはCursorの話と混同しています。.mdcはCursorのProject Rules（.cursor/rules/）で使う形式で、Clineのリリースノートに.mdcへ移る変更は一度もありません。Clineで起きた変化は、単一ファイルからフォルダ形式への移行と、新しい配置先.cline/rules/の追加です。Cursor側の形式は.cursorrulesと.cursor/rulesの違いで扱っています。

.clinerulesの配置場所と読み込まれるファイル

v4.1.21でClineがルールを探す場所は次のとおりです（v4.1.21のルール探索処理）。表は探索する順番で、プロンプト内の並び順は後述のとおりルール名で決まります。

WindowsでOneDriveにドキュメントフォルダをリダイレクトしている場合は、環境変数OneDriveなどが指す先のDocuments\Cline\Rulesも探索します。v4.1.20より前はこのケースでグローバルルールが見つからず、.cline/rules/のルールも適用はされるのにRulesパネルに表示されない不具合がありました（v4.1.20のCHANGELOGで修正）。パネルに出ないルールがあるなら、まず拡張機能の版を確認してください。

ソース上、.clinerulesにはDEPRECATED_CONFIG_DIRという定数名が付いています。ただしドキュメントは両方をサポート対象としており、Rulesパネルも新規ファイルを.clinerules/に作ります。既存の.clinerules/をいま移す必要はありません。

読み込まれる拡張子とサブフォルダの扱い

ルールとして読まれるのは.md・.markdown・.txtの3種類です（MARKDOWN_EXTENSIONS）。実測では、同じフォルダに置いたextra.yamlは無視されました。フォルダは1階層しか見ないため、.clinerules/frontend/react.mdのようにサブフォルダへ分けたファイルは読まれません。

この仕様があるので、.clinerules/workflows/（ワークフロー）や.clinerules/hooks/（Hooks）を同じフォルダの中に同居させられます。サブフォルダ内のMarkdownがルールとして毎回プロンプトに入ることはありません。

単一ファイル形式とフォルダ形式

.clinerulesは、v3.0.0（2024年12月）ではプロジェクト直下の単一ファイルでした。v3.7.0（2025年3月）で.clinerules/フォルダに複数ファイルを置けるようになっています。v4.1.21でも単一ファイルは読み込まれ、プロンプト上は「## .clinerules」という名前の1ルールになります。

同じ場所に同名のファイルとフォルダは作れないので、単一ファイルからフォルダへ移るときは、中身を退避してからファイルを削除し、フォルダを作って分割し直します。ルールが3つ以上のテーマにまたがるなら、オンオフや差分レビューがしやすいフォルダ形式を選んでください。

.clinerulesの書き方とテンプレート

公式ドキュメントが勧める書き方は、1ファイル1テーマ、曖昧な表現より具体的な指定、理由の併記、既存コードへの参照の4点です。例えば「わかりやすい変数名を使う」では判断基準になりません。「変数はcamelCase、クラスはPascalCase、定数はUPPER_SNAKE_CASE」まで書きます。

your-project/
├── .clinerules/
│   ├── 01-coding.md        # 命名規則・エラー処理
│   ├── 02-testing.md       # テストの粒度と置き場所
│   ├── 03-architecture.md  # 層の分け方・依存の向き
│   └── workflows/          # ルールではなくワークフロー
│       └── release.md
└── src/

# コーディング規約

## 命名
- 変数と関数はcamelCase、クラスはPascalCase、定数はUPPER_SNAKE_CASE
- Reactコンポーネントのファイル名はPascalCase.tsx

## エラー処理
- 例外はsrc/utils/errors.tsのAppErrorで包んで投げる
- 理由：APIレスポンスのエラー形式を1か所で揃えるため

## 触らない場所
- src/legacy/は変更しない（2026年度中に削除予定のため）

先頭の数字（01-）は必須ではありません。探索段階（discoverRulesLikeFiles）ではOSが返す順にファイルを拾いますが、プロンプトを組み立てる段階でルール名の順に並べ替えられます。数字で始まる名前は英字より前に来るので、前提になる規約ほど小さい番号を振ると並びを揃えられます。

ルールに書くべきでない内容

APIキーやパスワードは書かないでください。.clinerules/はGitでチームと共有する前提のフォルダで、中身はそのままモデルプロバイダーへ送られます。頻繁に変わる進捗メモやタスク一覧もルールには向きません。毎回のプロンプトに古い情報が混ざるため、後述のMemory Bankのように別ファイルへ分けて、読む手順だけをルールに書きます。

プロンプト内の並び順と同名ルールの実挙動

ここからは、v4.1.21のソースと、同じSDKランタイムを公開したnpmパッケージ@cline/core 0.0.86のローダーを実行して確かめた結果です。テスト用のワークスペースとホームディレクトリにルールを置き、ローダーが返す一覧と、ルールをシステムプロンプト用の文字列に組み立てる拡張（createExtension）の出力を確認しました（2026年9月26日）。VS Code拡張が実際に送信したリクエストを取得したものではありません。

ワークスペースとグローバルの競合処理

公式ドキュメントには「ワークスペースとグローバルのルールが食い違えばワークスペースが優先」とあります。実装では、IDが異なるルールはすべて連結され、食い違う指示を機械的に打ち消す処理はありません。並び順もルール名の順で、実測では01-style、frontend、global、Global AGENTS.md、team、Workspace AGENTS.mdの順（抜粋）になりました。ワークスペース側が前に来るとは限らず、どちらに従うかはモデルの判断になります。グローバルに「コメントは英語」、プロジェクトに「コメントは日本語」と書くような正面衝突は避け、グローバルには全プロジェクトで変わらない好みだけを置いてください。

同一IDのルールとグローバル側による上書き

ルールは、拡張子を除いたファイル名（frontmatterにnameがあればその値）を小文字化したIDで管理され、同じIDが見つかると後から読んだ方で置き換えられます（unified-config-file-watcher.tsのrecords.set）。探索順はワークスペースが先、グローバルが後です。

実測では、.clinerules/01-style.mdと~/Documents/Cline/Rules/01-style.mdを同時に置くと、プロンプトに残ったのはグローバル側の1本だけでした。.clinerules/style.mdとグローバルのStyle.txtのように、拡張子や大文字・小文字が違っても同じ結果です。ドキュメントの説明とは逆に、プロジェクトのルールが丸ごと消えます。coding.mdやstyle.mdのような一般的な名前はぶつかりやすいので、グローバルルールにはglobal-などの接頭辞を付けると防げます。

条件付きルール（paths）とオンオフの現状

ドキュメントでは、ルールファイルの先頭にYAML frontmatterでpathsを書くと、開いているファイルや編集中のファイルが一致したときだけルールが有効になると説明されています。

---
paths:
  - "src/components/**"
---
# フロントエンドのルール
- スタイルはTailwind CSSで書く

v4.1.21ではこの条件が評価されていません。実測でも、上のファイルは対象ファイルを一切開いていない状態で常にプロンプトへ入り、frontmatterだけが取り除かれました。ソースを見ると、条件を判定する旧コード（rule-conditionals.ts）はv4.0.0でSDKランタイムへ移行した後、どこからも呼ばれていません。チャット欄に「Conditional rules applied」と出す表示部品は残っていますが、その通知を発行する処理がありません。pathsで絞ってトークンを節約しているつもりでも、実際には全ルールが毎回読まれています。

ルールを確実に止める書き方

frontmatterにenabled: false（またはdisabled: true）と書いたルールは、SDKのローダーで無効フラグが付き、プロンプトを組み立てる段階で除外されることを実測で確認しました。Rulesパネルのオンオフは、v4.1.21のソースではVS Code拡張の状態として保存され、SDK側のルールローダーがその状態を参照する処理は見当たりません。パネルでオフにしたはずのルールが効いているように見えたら、frontmatterで止めるか、ファイルを探索範囲の外（サブフォルダなど）へ移してください。

不正なYAMLによるルールの読み込み失敗

ドキュメントには「frontmatterを解析できないときはフェイルオープンで、ルールは生の内容のまま有効になる」とあります。実測は逆で、paths: [unclosedのように閉じ括弧を落としたファイルはルール一覧から消え、プロンプトにも入りませんでした。frontmatterだけで本文が空のファイルも同じく読まれません。ルールを追加しても効かないときは、まずfrontmatterの---の対応と括弧・クォートを確認します。

.cursorrules・.windsurfrules・AGENTS.mdとの互換

v3.14.0（2025年5月）で.cursorrulesと.windsurfrules、v3.37.1（2025年11月）でAGENTS.mdに対応し、ドキュメントの表にも4種類が並んでいます。しかしv4.1.21のSDKランタイムで読み込まれるのはAGENTS.mdだけです。プロジェクト直下に.cursorrulesと.windsurfrulesを置いてローダーを実行しても、どちらも一覧に現れませんでした。ソース上も、この2つを検出するコードは旧実装側（Rulesパネルのトグル管理）にしか残っていません。

複数のエージェントを併用するチームなら、共通の指示をAGENTS.mdに書き、Cline固有の指示だけを.clinerules/に置く分担が扱いやすくなります。AGENTS.mdはGitHub CopilotやCodexも読む共通形式で、使い分けはcopilot-instructions.mdとAGENTS.mdの違いで詳しく比べています。

Memory Bank・ワークフロー・.clineignoreとの住み分け

.clinerulesの周辺には、名前の似た仕組みがいくつかあります。役割が違うので、置き場所を混ぜないようにします。

Memory Bankは組み込み機能ではなく、ドキュメントのベストプラクティスに載っている運用手法です。プロジェクトの概要や進捗をmemory-bank/配下のMarkdownに書き、「タスク開始時にそれを読む」という指示だけを.clinerules/memory-bank.mdなどのルールに置きます。.clineignoreは自動で読み込むファイルを減らす仕組みで、@メンションやシェルコマンドからは除外したファイルも読めます。ドキュメントはセキュリティ境界ではないと明記したうえで見出しに「deprecate soon」と書いており、新規に頼る設計は避けたほうが安全です。

ルールを対話で作る/newruleはドキュメントのコマンド一覧に残っていますが、v4.1.21では「プロンプトの移植が済むまで非表示」とソースにあり、入力しても使えません（apps/vscode/src/shared/slashCommands.ts）。今はRulesパネル（モデル選択の左にある天秤アイコン）の「New rule file…」から作ります。ワークフローとHooksの設定ファイルはClineの設定ファイルとインストール手順、Plan/Actや/deep-planningとの組み合わせはClineの/deep-planningの解説にまとめています。

.clinerulesが効かないときの確認手順

ルールを書いたのに従わないときは、ファイルが読まれていないのか、読まれたうえでモデルが従っていないのかを先に切り分けます。読まれていない原因は次の順に確認すると早く見つかります。

1. 拡張子が.md・.markdown・.txtのいずれかか
2. .clinerules/直下にあるか（サブフォルダは対象外）
3. frontmatterのYAMLが正しく閉じているか、本文が空でないか
4. enabled: falseやdisabled: trueが残っていないか
5. 同じファイル名のグローバルルールに上書きされていないか
6. VS Codeで開いているフォルダが、.clinerulesのあるプロジェクトルートか

6番目は見落としやすい原因です。ワークスペースのルールは開いたフォルダを起点に探すため、モノレポの親フォルダを開いて子パッケージ内に.clinerules/を置いても読まれません。読まれているのに従わない場合は、指示が抽象的でないか、ルール同士が矛盾していないかを確認してください。ルールの総量を減らし、具体的な値と理由を書き足してください。

よくある質問

.clinerulesとは何ですか？

Clineに毎回渡す指示を書いたMarkdownファイル、またはそれを入れるフォルダです。プロジェクト直下の.clinerules/に置いたファイルは、タスクのたびにシステムプロンプトの「# Rules」節へ自動で差し込まれます。

.clinerulesはファイルとフォルダのどちらで作るべきですか？

v4.1.21ではどちらも読み込まれますが、テーマごとにファイルを分けられるフォルダ形式を勧めます。ファイル名がそのままプロンプト上のルール名になり、差分レビューやfrontmatterでの無効化もファイル単位でできます。

グローバルな.clinerulesはどこに置けばよいですか？

macOSとLinuxは~/Documents/Cline/Rules/、WindowsはDocuments\Cline\Rulesが既定です。ほかに~/.cline/rules/と~/Cline/Rules/も探索されます。ワークスペースのルールと同じ名前（拡張子と大文字・小文字の違いは無視されます）を付けると、ワークスペース側が消える点に注意してください。

.clinerulesから.mdcファイルへ移行する必要はありますか？

ありません。.mdcはCursorのProject Rulesの形式で、Clineは読み込みません。Clineで新しく加わった配置先は.cline/rules/ですが、.clinerules/も引き続きサポートされています。

.clinerulesとAGENTS.mdはどう使い分けますか？

複数のAIエージェントで共有したい指示はAGENTS.mdに、Clineにだけ伝えたい指示は.clinerules/に書きます。v4.1.21のClineは両方を読みます。プロンプト内はルール名の順に並ぶため、AGENTS.mdが必ず先に来るわけではありません。

関連記事

• Clineとは？VS Code拡張とCLIの使い方・料金・自動承認設定を実装目線で解説
• Clineの設定ファイルとインストール完全ガイド｜MCP設定・OS別パス・Hooksを整理
• Clineの/deep-planningとは？Plan/Actとの違いとFocus Chain廃止後の使い方
• .cursorrulesとは？非推奨の旧形式と新Project Rules（.cursor/rules）の違い・書き方
• copilot-instructions.mdとは？書き方・配置場所とAGENTS.md・.instructions.mdの違いを解説