タスクを開始する前にアクティブなClineルールをマッピングする方法（2026年ガイド）

まず、何がルールとしてカウントされるかから始めましょう。Clineのドキュメントには、「他のツールの既存のルールファイルを使用できるように」認識する4つのタイプがリストされています。「サポートされているワークスペースルールディレクトリ」として説明されている .clinerules/、.cline/rules/ 内の Cline Rules、「自動検出」とマークされた .cursorrules 内の Cursor Rules、同じく「自動検出」される .windsurfrules 内の Windsurf Rules、そして「ツール間の互換性のための標準フォーマット」として説明されている AGENTS.md（AGENTS.md、~/.agents/AGENTS.md）です。

これは、ほとんどの人が想像するよりも広い範囲であり、以前のツールから残された .cursorrules が機能していないわけではないことを意味します。4つすべてが同じ場所に集約されます。「検出されたすべてのルールタイプはルールパネルに表示され、個別に切り替えることができます。」

最初のゲートはそのパネルです。「すべてのルールには、有効または無効にするためのトグルがあります。これにより、ルールファイルを削除することなく、現在のタスクに適用するルールをきめ細かく制御できます。」この機能は便利です。ドキュメントでは、「プロトタイピング時に無効にしたい厳格なテストルールや、特定のクライアントの機能を処理するときだけ必要なクライアント固有のルール」という例が挙げられています。その代償として、3週間前にオフにしたルールが、ディスク上ではアクティブなルールとまったく同じに見えてしまうことです。

2番目のゲートは、YAMLフロントマターによる条件付きアクティベーションです。「Clineがリクエストを処理するとき、現在の作業（開いているファイル、表示されているタブ、言及されたパス、編集されたファイル）からコンテキストを収集し、各ルールの条件を評価して、一致するルールをアクティブにします。」サポートされている条件は1つだけであるとドキュメントに記載されています。「現在、サポートされている条件は paths です。」これはglobパターンの配列を受け取ります。

この条件に関する3つの挙動が、ほとんどの実際のケースを決定づけます。これら3つはすべてドキュメントに記載されています。「フロントマターなし：フロントマターのないルールは常にアクティブです。」「空のpaths配列：paths: [] はルールがアクティブにならないことを意味します。ルールを一時的に無効にするためにこれを使用します。」そして「無効なYAML：フロントマターを解析できない場合、Clineはフェイルオープン（制限を解除して動作）します。デバッグを支援するために、生のコンテンツが表示された状態でルールがアクティブになります。」

最後の挙動が手がかりになります。ルールの生のフロントマターがClineの出力に表示されている場合、読み込みに失敗したのではなく、YAMLが解析できなかったためにデバッグ用の形状で読み込まれたことを意味します。

ルールをより強力に書き直す。 モデルに届いていない指示を強調しても何も変わりません。また、実際に適用されるようになったときに、ファイルが使いにくくなってしまいます。

サポートされている両方のディレクトリにルールをコピーする。 不要です。ドキュメントにもそう書かれています。「両方のディレクトリが存在する場合は両方が検索されるため、両方の場所にルールをコピーする必要はありません。」また、新しいファイルがどこに作成されるかも記載されています。「VS Codeのルールパネルは、依然として .clinerules/ に新しいワークスペースルールを作成します。」

フロントマターを削除して「常に適用されるようにする」。 これは確かに機能し、ドキュメントに記載されている挙動ですが、広く適用すると、条件分岐が存在する理由である問題を再発させてしまいます。ドキュメントではそのコストについて率直に述べています。「ルールライブラリが大きくなるにつれて、すべてのリクエストに対してすべてのルールを読み込むと、コンテキストトークンが無駄になり、Clineの集中力が削がれる可能性があります。」

ファイル名を指定する代わりに、散文でファイルを説明する。 ドキュメントには、人々がこれをやっているのを見た後に書かれたようなヒントが含まれています。「プロンプトではファイルパスを明示してください。『src/services/user.ts を更新して』はパスベースのルールを確実にトリガーしますが、『ユーザーサービスを更新して』ではトリガーされない可能性があります。」

メモリの問題だと仮定する。 そうである場合もあります。正しく適用されているにもかかわらず、Clineがプロジェクトの事実を再導出してしまうルールは別の失敗であり、Clineメモリバンクの設定方法の領域に近いです。しかし、まったく起動しないルールはアクティベーションの問題であり、修正はパネルとフロントマターにあります。

他のエディタと同じ失敗だと仮定する。 症状は一致しますが、メカニズムが異なります。別のツールがセッションの途中でプロジェクトルールをドロップする場合、問題は通常、2ゲートのアクティベーションモデルではなく、スコープやセッション状態に関するものです。これについては、Cursorがプロジェクトルールを忘れる理由で説明されています。

ステップ 1: 自分が書いていないものも含め、Clineがルールとしてカウントするすべてのファイルをリストアップする

ルールパネルを開き、設定画面としてではなく、インベントリ（目録）として読み取ります。検出されたすべてのタイプがそこに表示されるため、古い .cursorrules や .windsurfrules がまだモデルに提供されていることに気づくのはこのパネルです。

次に、ディスク上の両方のワークスペースの場所（.clinerules/ と .cline/rules/）を確認します。「両方のレイアウトが VS Code、デスクトップ、および CLI でサポートされている」ため、同僚があなたが普段開かない方を使用している可能性があるからです。さらにグローバル層を追加します。グローバルルールはシステムの Cline Rules ディレクトリにあり、ドキュメントには「Clineは ~/.agents/AGENTS.md からツール共通のグローバルな AGENTS 指示も読み取ります」と記載されています。

リスト内の各ファイルについて、トグルがオンになっているかどうか、およびフロントマターがあるかどうかの2つの事項を記録します。このペアがマップになります。トグルがオンでフロントマターがないファイルは、常にアクティブです。トグルがオフのファイルは、フロントマターの内容に関係なく不活性です。なぜなら、「条件付きルールを完全に無効にするにはトグルをオフにします（パスが一致してもアクティブになりません）」からです。

ここにいる間に、構造に関するアドバイスを適用してください。マップの保守が容易になります。「1ファイルにつき1つの関心事。ルールをトピックごとに分割します。スタイルの場合は coding.md、テスト要件の場合は testing.md、構造の決定の場合は architecture.md。これにより、特定のルールを簡単にオンまたはオフに切り替えることができます。」1つの大きなルールファイルがあると、6つの無関係な関心事に対して1つのトグルしか持てなくなります。

ステップ 2: Clineが実際に評価するコンテキストに対してglobを読み取る

パターンは問題の半分にすぎません。もう半分は、Clineがそれを何と比較しているかです。ドキュメント化されたコンテキストには5つの入力があります。「あなたのメッセージ：プロンプトで言及されたファイルパス」、「開いているタブ：エディタで現在開いているファイル」、「表示されているファイル：アクティブなエディタペインに表示されているファイル」、「編集されたファイル：タスク中にClineが作成、変更、または削除したファイル」、および「保留中の操作：Clineが編集しようとしているファイル」です。

これには2つの結果が伴います。第一に、タイミングは固定されていません。「条件付きルールは、最初のメッセージ時、関連するファイルが開いているとき、またはClineが一致するファイルの処理を開始するタスクの途中でアクティブになる可能性があります。」開始時には存在しないように見えたルールが、後から適用された可能性は十分にあります。第二に、別のペインで無関係なファイルがたまたま開いていたために、意図しない理由でルールが起動することがあります。

次に、ドキュメントに記載されている構文を手元に置いて、glob自体を読み取ります。* は「/ を除く任意の文字に一致」、** は「/ を含む任意の文字に一致（再帰的）」、? は「単一の文字に一致」、[abc] は「括弧内の任意の文字に一致」、{a,b} は「いずれかのパターンに一致」します。例を頭に入れておく価値があります。src/**/*.ts は「src/ 以下のすべての TypeScript ファイル」、*.md は「ルートの Markdown ファイルのみ」、**/*.test.ts は「プロジェクト内の任意の場所にあるテストファイル」、src/components/*.tsx は「components の直下にある TSX ファイル（ネストされていない）」をカバーします。

組み合わせのルールは寛容です。「コンテキスト内のいずれかのファイルにいずれかのパターンが一致した場合、ルールがアクティブになります。」そのため、狭いパターンが外れるよりも、広すぎるパターンが誤って起動することの方が多くなります。これはまさに、同じドキュメントのトラブルシューティングノートで指摘されているトレードオフであり、「ルールが予期せずアクティブになる」原因として「** は再帰的であり、意図したよりも多く一致する可能性がある」ことや、パターンに一致する開いているファイルが挙げられています。

ステップ 3: 使い捨てのテストルールで証明し、通知を確認する

これが機能すると、Clineは1つのシグナルを発します。それを知ることで、推測が確実な確認へと変わります。条件付きルールがアクティブになると、ドキュメントには「'Conditional rules applied: workspace:frontend-rules.md' という通知が表示されます」と記載されています。

ドキュメントで推奨されている使用方法は、使い捨てのルールです。.clinerules/ に、確信が持てない paths パターンのみをフロントマターに持ち、本文が1行の明らかな指示（ドキュメントでは「TEST: This rule should activate for your/pattern/here files.」のようなものを推奨しています）である小さなファイルを作成します。そして、「そのパスにあるファイルを操作し、アクティベーション通知が表示されるかどうかを確認します。」

何も表示されない場合、トラブルシューティングのリストは短く、順序立てられています。「コンテキスト内のファイルパスがglobパターンと一致していることを確認する」、「ルールパネルでルールがオンになっていることを確認する」、「YAMLフロントマターに適切な --- デリミタがあることを確認する」です。この順序で実行してください。最初のものが最も一般的であり、3番目のものは最も奇妙な症状（解析できないフロントマターは、生のコンテンツが表示された状態でフェイルオープンすることを思い出してください）を引き起こすからです。

ドキュメントでは、パターンを推測するのではなく構築するためのアプローチも提案されています。「広く始めて、徐々に狭める」。まずは src/** のようなものから始め、何が一致するかを確認した上で src/features/auth/** のように絞り込んでいきます。ファイルを自分で手書きしたくない場合は、/newrule スラッシュコマンドを使用して「Clineに対話形式でルールを作成させる」こともできます。

ルールとは指示です。ここでのコードの書き方、避けるべきこと、どの規約が適用されるかなどです。しかし、ルールは、そのルールが暗示するもう1つの側面、つまりその背後にある決定や理由を格納するコンテナとしては不向きです。それらの理由は、すべてのタスクに読み込むのではなく、ルールがまだ適用されるかどうかを判断するときに取り出せるようにしたいものです。MemoryLake に意図的にエントリを書き込むストアを用意すれば、その半分を切り離して管理できるため、globを厳しくしてもルールの背後にある理由が失われることはありません。エントリはあなた自身の言葉で自分で書き込みます。ルールファイルや Cline の設定から何かが読み取られたり、書き込まれたり、削除されたりすることはありません。

ステップ 1: APIキーを作成する

サインインし、ワークスペースの設定からAPIキーを生成します。これはエージェントや統合機能が使用する認証情報であるため、何かを移行し始める前に作成してください。

ステップ 2: 最初のメモリをアップロードする

ルールファイルが省略している「なぜ」から始めましょう。なぜレガシーディレクトリが立ち入り禁止なのか、どの規約がいつ何に置き換わったのか、制約が何から保護しているのか。それぞれを短い独立したメモとして書き、単体で検索できるようにします。

ステップ 3: AIとエージェントを接続する

使用しているアシスタントやエージェントを接続します。これにより、特定のエディタがどのルールディレクトリを読み込むかに関係なく、推論プロセスがツールを越えてあなたに追従します。

デバッグに明確な手順が生まれます。ルールを書き直す代わりに、トグルを確認し、フロントマターを確認し、5つのコンテキスト入力に対してglobを確認し、テストルールを実行して通知を待ちます。4つのチェックすべてに、ドキュメント化された答えがあります。

古いツールのファイルは、偶然残されたものではなく、明確な意思決定の対象になります。残された .cursorrules が検出されて提示されるため、意図的にルールセットに含めるか、削除するかのどちらかになります。これにより、CursorルールをClaude Codeに移行する方法で説明されているように、ツール間でルールを移動する際の移行方向も明確になります。

プロンプトの表現がセットアップの一部になります。メッセージ内で言及されたパスがコンテキストとしてカウントされるため、変更しようとしているファイル名を指定することは、単なるこだわりではなく、ドキュメント自体のヒントにあるように、利用可能な最も信頼性の高いトリガーとなります。

ルールライブラリがデフォルトで肥大化するのを防げます。どのルールが「常にオン」であるかが分かれば、常にオンの層は、受け継いだだけの雑多な山ではなく、管理すべき予算になります。これは、Kilo Codeルールファイルを統合する方法で説明されているように、そもそも人々が散らばったルールファイルを統合しようとする動機と同じです。

アンド、繰り返される不満が再診断されます。「またスタイルを忘れた」というのは、メモリの問題ではなく、既知の原因によるアクティベーションの問題である場合があります。何かを変更する前にこの区別をすることは価値があり、Clineがコーディングスタイルを忘れる理由における修正方法を決定づけます。

常にオンのファイルを1つ用意し、それと分かる名前を付けます。ドキュメント自体のサンプルレイアウトは、universal.md（「フロントマターなし = 常にアクティブ」という注釈付き）で終わっています。その挙動にちなんで命名されたファイルは、次の作業者にそれが何であるかを明確に伝えます。

意図したトリガーをルール本文に記載します。上部に「src/components に対してアクティブになることを想定」と1行書いておくだけで、将来の誤動作を調査ではなく2秒の比較作業に変えることができます。

1つの広範なファイルよりも、いくつかの狭い範囲のファイルを優先し、トグルを精密な器具として機能させます。これが「1ファイルにつき1つの関心事」の実用的なメリットです。

リファクタリング後にテストルールを再実行します。ディレクトリを移動するとglobが一致する対象が変わりますが、ツールチェーンのどこからも、パターンが一致しなくなったことは教えてくれません。

クロスツールファイルを常にオンとして扱います。ルートにある AGENTS.md や ~/.agents/AGENTS.md はルールソースとして検出され、共有ファイルはツールごとに制限されないからこそ共有されます。どのようなセットアップに落ち着くにせよ、そもそもルールに何を含めるべきかというより広い問いは、定期的に見直す価値があります。これについては、Clineに最適なメモリセットアップで詳しく説明されています。

Clineのルールは、トグルがオンであり、かつ条件が一致した場合にのみモデルに届きます。どちらのゲートも閉じているときは何も通知されず、4つの異なるファイルタイプが同じパネルに供給されるため、無視されているルールが、あなたが今見ているルールとは限りません。

一度マップを構築しましょう。引き継いだものを含むすべてのルールソース、それぞれのトグル状態、それぞれのフロントマター、そしてドキュメントに記載されている5つのコンテキスト入力に対して読み取られるglobです。そして、使い捨てのテストルールを手元に置いておいてください。アクティベーション通知はシステムにおける唯一の確実なシグナルだからです。再実行できるチェックは、書き直して祈るだけのルールに勝ります。