2つのルールフォルダの整合性が取れなくなる理由
ドキュメントに記載されている優先順位は、見つけてしまえば明確です。Devin Desktopのルール検出セクションには、以下のように直接記述されています。
"Devin Desktopは、柔軟な整理を可能にするため、複数の場所からルールを自動的に検出します。.devin/ディレクトリが推奨される場所であり、優先されます。.windsurf/は後方互換性のためのフォールバックとして維持されます。"
これはわずか1文であり、冒頭の疑問を解決してくれます。問題は、その周囲にあるすべての要素です。
検出は1つのフォルダにとどまりません。「現在のワークスペースとそのサブディレクトリ内にあるすべての .devin/rules（およびレガシーな .windsurf/rules）ディレクトリ」を対象とし、gitリポジトリの場合は「親ディレクトリ内のルールを見つけるために、gitのルートディレクトリまで遡って検索」も行います。複数のフォルダが同時に開かれている場合、「ルールは重複排除され、最も短い相対パスで表示」されます。
ワークスペースのスコープには、ほとんどのチームが完全に忘れている3つ目のファイルが存在します。
"ワークスペースのルートにあるレガシーな単一ファイル .windsurfrules も、引き続き読み込まれます。"ワークスペースの上位には、独自のルールを持つグローバルファイル ~/.codeium/windsurf/memories/global_rules.md が存在します。これは「すべてのワークスペースに適用される単一のファイル。常にオン。上限は6,000文字」と説明されています。ワークスペースのルールファイルには、それぞれ12,000文字という独自の上限があります。
そして、まったく別のシステムではない AGENTS.md があります。そのドキュメントでは、関係性が明示されています。
"AGENTS.mdファイル（またはagents.md）を作成すると、Devin Desktopはそれを自動的に検出し、.devin/rules/（およびレガシーな.windsurf/rules/）を動かすのと同じルールエンジンに投入します。ただし、アクティベーションモードはフロントマターからではなく、ファイルの場所から推測されます。"
ルートレベルにある場合は「常にオン（always-on）」を意味します。サブディレクトリにある場合は「<directory>/** という自動生成されたパターンを持つ glob ルール」を意味します。
さらに、エンタープライズ向けには、IT部門によってデプロイされ、ユーザーからは読み取り専用となるシステムレイヤーが存在します。これにも同様の新旧のペアがあります。macOSでは /Library/Application Support/Devin/rules/（レガシーなフォールバックとして Windsurf）、Linuxでは /etc/devin/rules/（フォールバックとして /etc/windsurf/rules/）、そしてWindowsでも同様のペアが存在します。システムルールは「ワークスペースおよびグローバルルールとマージされ、ユーザー定義のルールを上書きすることなく、Cascadeに追加のコンテキストを提供」します。
サーフェスを数えてみましょう。.devin/rules、.windsurf/rules、.windsurfrules、任意の数の AGENTS.md ファイル、global_rules.md、および2つのシステムディレクトリです。これらすべてが有効に機能しています。このうち2つのペアは、リネームが発生し、何も壊してはならなかったという理由だけで存在しています。
乖離（ドリフト）を招きやすくする詳細がもう1つあります。新しいルールは、あなたが想定する場所に保存されるとは限りません。
"新しいルールを作成すると、それは現在のワークスペースの .devin/rules ディレクトリに保存され、必ずしもgitのルートに保存されるとは限りません。"つまり、モノレポにおいて、たまたま特定のパッケージの内部にいるときに作成されたルールは、最上位ではなく、そのパッケージ内に保存されてしまうのです。
代わりに試されがちな誤ったアプローチ
すぐにレガシーフォルダを削除する。 魅力的ですが、通常は時期尚早です。古いフォルダはまだ読み込まれているため、古いクライアントを使っている人や、まだプルしていないチームメイトがそれに依存している可能性があります。削除するのは、コンテンツが新しい場所に確実に反映されていることを確認した後にしてください。
最新のファイルが優先されると思い込む。 そうではありません。優先順位は場所によって決まり、更新日時では決まりません。今朝 .windsurf/rules に書いたルールは、.devin/rules にある古いルールに負けてしまいます。
フォルダの問題を避けるために、すべてを global_rules.md に詰め込む。 これは、1つの問題をより悪い問題と交換するようなものです。グローバルファイルは常にオンで、すべてのワークスペースに適用され、6,000文字に制限されています。プロジェクト固有の規約を入れる器としては不適切であり、真っ先に上限に達することになります。
AGENTS.md はこの議論の対象外であると思い込む。 対象外ではありません。これも同じルールエンジンを通り、ルートレベルのものは常にオンになります。そのため、宣言されるのではなく、置かれている場所からアクティベーションが推測され、常にオンのルールファイルと同じコンテキスト予算を奪い合うことになります。
自動生成されたメモリを永続的なレイヤーとして扱う。 ドキュメントはこの点について異例なほど率直に述べており、ベンダー自身がその機能の目的を説明しているため、引用する価値があります。
"Cascadeに確実に再利用させたい知識については、自動生成されたメモリに頼るのではなく、ルールとして記述するか、リポジトリ内の AGENTS.md に追加してください。ルールはバージョン管理可能で、チームと共有でき、アクティベーションを明示的に制御できます。"自動生成されたメモリはローカルでもあります。それらは ~/.codeium/windsurf/memories/ の下に保存され、「あるワークスペースで生成されたメモリは別のワークスペースでは利用できず、リポジトリにコミットされることもありません」。セッション間でコンテキストが失われることが、あなたがこの記事にたどり着いた原因であるなら、Cascadeがコンテキストを失う理由でその側面を直接解説しています。
解決策：.devin/rules に集約し、すべてのアクティベーションを明示的にする
3つのステップがあります。順序通りに行ってください。棚卸し（インベントリ）を行うことで、2番目のステップを安全に進めることができます。
ステップ1：何かを移動する前に、すべてのサーフェスを棚卸しする
7つのサーフェスすべてを確認し、それぞれに何が含まれているかを書き留めます。具体的には、ワークスペース内およびgitルートまでの親ディレクトリにあるすべての .devin/rules ディレクトリ、同じ場所にあるすべての .windsurf/rules ディレクトリ、ワークスペースのルートに存在するなら .windsurfrules ファイル、あらゆるレベルのすべての AGENTS.md または agents.md、global_rules.md、そして（組織でデプロイされている場合は）現在およびレガシーのシステムディレクトリです。
各ルールについて記録すべきことは2つあります。アクティベーションモードと、同等のルールがすでに他の場所に存在するかどうかです。アクティベーションモードが重要なのは、それがフロントマターの trigger フィールドで宣言され、4つの値によってコストが大きく異なるためです。ドキュメントではそのトレードオフが説明されています。always_on は、すべてのメッセージのシステムプロンプトにルール全体を投入します。model_decision は、プロンプトに description のみを投入し、Cascadeがその説明に関連性があると判断したときにファイル全体を読み込みます。glob は、Cascadeがパターンに一致するファイルを読み込みまたは編集するときにルールを適用します。manual は、あなたが @rule-name と入力するまで、プロンプトから完全に除外します。
棚卸しの際、2つの例外に注意してください。「グローバルルールファイル（global_rules.md）とルートレベルの AGENTS.md ファイルはフロントマターを使用しません。これらは常にオン（always-on）です。」これら2つはスコープを制限できません。そこに含まれるものは、すべてのメッセージに含まれることになります。
ステップ2：各ルールを .devin/rules に移動し、重複を手動で解決する
各レガシールールを、実際に属すべきレベルの .devin/rules ディレクトリにコピーします。ほとんどの規約において、これは作成時にたまたま開いていたパッケージではなく、gitのルートになります。
両方のフォルダに同じルールが見つかった場合は、どちらか一方を選ぶ前に両方のバージョンを読み比べてください。このステップで乖離（ドリフト）が浮き彫りになります。多くの場合、それは単純な重複ではありません。レガシーバージョンには新しいバージョンで失われた詳細が含まれていたり、新しいバージョンにはレガシーバージョンに反映されなかった修正が含まれていたりします。慎重にマージした上で、レガシーなコピーを削除してください。
.windsurfrules には独自の判断が必要です。これはフロントマターのない単一のファイルであるため、中のすべてが区別のない1つのブロックとして動作します。移動する際に、トリガーを宣言した個別のルールファイルに分割してください。これこそが、新しいフォーマットの最大のメリットです。
AGENTS.md ファイルについては、それぞれが本当に「常にオン」にすべき内容であるかを判断してください。ルートレベルの AGENTS.md はスコープを制限できないため、ツリーの一部にしか適用されない内容が含まれている場合は、サブディレクトリの AGENTS.md（そのディレクトリに対する自動globが適用されます）にするか、明示的な glob トリガーを持つルールファイルにする必要があります。
⚠️ これらのファイルを触る際、ツールをまたぐ上での警告が1つあります。Devin Desktopは名前に対して寛容です。「大文字と小文字を区別しません。AGENTS.md と agents.md の両方が認識されます。」しかし、他のツールはそうではありません。Kilo Codeのドキュメントには、「ファイル名は小文字（agents.md）ではなく、大文字（AGENTS.md）でなければなりません」と明確に記載されています。もしリポジトリを他のエージェントを使用している人と共有している場合は、大文字を使用してください。こちらで大文字にしてもデメリットはなく、他方でファイルが読み込まれるか、静かに無視されるかの違いを生みます。この種の不一致は、ベンダー間でルールを移行する際にも現れます。CursorのルールをWindsurfに移行するで、フロントマター側の対応について解説しています。
ステップ3：設定可能なすべてのルールにアクティベーションモードを宣言する
統合が完了したら、.devin/rules を確認し、すべてのファイルの trigger がデフォルトのままではなく、意図的に選択されたものであるかチェックします。
確実なテスト方法は、ルールごとに「これはすべてのメッセージのプロンプトに含める必要があるか？」と自問することです。ほとんどのルールは必要ありません。テストファイルに関する規約は glob ルールにします。リリースの手順書は manual です。データモデルに関する長い説明は model_decision にし、説明文（description）のみを常に存在させ、本文は必要に応じて読み込ませるようにします。
このステップこそが、7つの重複するサーフェスが静かに消費していたコンテキスト予算を取り戻す方法です。そして、これは重複が排除されて初めて可能になります。同じルールが3つも存在している状態では、アクティベーションコストについて論理的に考えることはできません。
MemoryLakeでの設定
統合によってフォルダは整理されます。しかし、重複を素早く解決できなかった根本的な原因は解決されません。同じルールが異なる文言で2つの場所に存在していたとき、どちらのバージョンが最新であるか、あるいはそれらの間で何が変更されたかを記録するものは何もありませんでした。
MemoryLake は、その記録をルールレイヤーの完全に外側に保持し、MCPまたはAPIを介して、要求してきたあらゆるエージェントに提供します。あなたの .devin/rules ファイルはそのままの場所に残り、ドキュメント通りに動作し続けます。MemoryLakeは、ルールエンジンが保存するようには設計されていない部分、つまり「各ルールが何のためのものか、何に取って代わったのか、そしてそれはいつなのか」を保持します。
ステップ1：APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行します。重複を解決する際の決定事項を記録できるよう、統合のステップ2を行う前にこれを行ってください。
ステップ2：最初のメモリをアップロードする
重複するペアをマージするたびに、何を残し、何を捨て、なぜそうしたのかを記録します。特定のインシデントから生まれたルールを追加してください。これらは、誰も理由を覚えていないために、誰も文言を変更する勇気がないルールです。ドキュメントやその他のファイルも同じ場所に保存されます。
ステップ3：AIとエージェントを接続する
Claude、Codex、OpenClaw、および Devin Desktop のセッションに、MCPまたはAPI経由でアクセス権を付与します。接続されると、ルールの背後にある理由が必要に応じて取得可能になります。これにより、ルールファイル自体を十分に短く保つことができ、always_on トリガーを設定する正当な理由が生まれます。
実践においてこれがもたらす変化
即座に現れる変化は、「実際にどのルールが有効なのか」という問いに1箇所で答えられるようになることです。1つのフォルダ、ルールごとに1つのファイル、そしてそれぞれに宣言されたアクティベーションモード。
2つ目の変化は、コンテキスト予算です。数が不明な「常にオン」のファイルを含む7つの重複するサーフェスは、作業のごく一部にしか適用されないガイダンスのために、大量のプロンプトを消費してしまいます。重複を排除し、トリガーを宣言することだけが、この消費を抑える唯一の方法であり、通常は予想以上のスペースを回復できます。
3つ目の変化は、次のリネーム作業が退屈なものになることです。これは再び起こるでしょう。ベンダーが合併し、製品名が変更され、パスが移動します。そして、ベンダーが取るべき責任ある対応は、古いパスを読み込み続けることです。ルールが統合され、その背後にある理由がフォルダの外にあれば、次のパス変更は、新たな考古学プロジェクトではなく、単なるコピー操作になります。
単一のルールサーフェスにおけるベストプラクティス
ドキュメントで推奨され、優先される場所として明記されている .devin/rules に集約する。 優先順位に抗うのではなく、優先される側に移行しましょう。
プロジェクト全体のルールはgitのルートに配置する。 新しいルールは現在のワークスペースディレクトリに保存され、「必ずしもgitのルートに保存されるとは限りません」。これが、モノレポにおいて規約が1つのパッケージ内に埋もれてしまう原因です。
.windsurfrules はそのまま移植するのではなく、分割する。 区別のない単一のファイルではアクティベーションモードを表現できません。それこそが、新しいフォーマットが提供する最大の利点です。
大文字の AGENTS.md を使用する。 Devin Desktopはどちらの大文字小文字も受け入れますが、共有リポジトリ内の他のエージェントは大文字を要求する場合があります。
global_rules.md は、純粋に個人的な、プロジェクト横断の好みの設定のみに留める。 これは常にオンで、どこにでも適用され、6,000文字に制限されています。
コンテンツの移動を確認した後にのみ、レガシーなコピーを削除する。 古いパスはまだ読み込まれているため、中途半端な統合は、統合前よりも悪い状態を招きます。
自動生成されたメモリをチームの記録として使用しない。 ドキュメントでは、永続的で共有可能な知識にはルールまたは AGENTS.md を推奨しており、自動生成されたメモリはワークスペースローカルでありコミットされないと指摘しています。この切り分けの後半部分、つまりルールファイルではなくエージェントがクエリするストアに属するものについては、Windsurfユーザー向けのメモリツールで選択肢を解説しています。
結論
Devin Desktopは7つのルールサーフェスを読み込みます。そのうち2つのペアは、リネームが発生し、後方互換性が維持されたためにのみ存在しています。.devin/ は .windsurf/ より優先され、両方が読み込まれ、さらにその上で .windsurfrules も読み込まれます。そして AGENTS.md ファイルは、場所から推測されたアクティベーションを伴って、同じエンジンに投入されます。
そのどれも壊れてはいません。しかし、特に新しいルールがたまたま開いているワークスペースディレクトリに保存されることを考えると、そのすべてが乖離（ドリフト）を引き起こす原因になり得ます。
7つのサーフェスすべてを棚卸しし、適切なレベルの .devin/rules に集約し、レガシーな単一ファイルを分割し、設定可能なすべてのルールにアクティベーションモードを宣言し、各ルールの背後にある理由をルールエンジンが所有しない場所に保管してください。そうすれば、「どちらが優先されるか」という問いに対する答えはシンプルになります。存在するルールは1つだけです。