なぜ文言よりもモードが重要なのか
Windsurf はその仕組みを1文で説明しています。「各ワークスペースルールは、フロントマターの trigger フィールドを介して有効化モードを宣言します。これにより、ルールのコンテンツがいつ Cascade に提供されるかと、それが消費するコンテキストウィンドウの量が制御されます。」
1つのフィールドで2つのことを制御しています。ルールがエージェントに届くかどうか、そしてそのコストです。ドキュメント化されているオプションは以下の通りです。
always_on — 「すべてのメッセージのシステムプロンプトに、ルールの全コンテンツが含まれます。」 コスト：すべてのメッセージ。
model_decision — 「システムプロンプトには説明（description）のみが表示されます。Cascade は、説明が関連していると判断したときに、ルールの完全なファイルを読み込みます。」 コスト：説明は常に、全コンテンツはオンデマンド。
glob — 「Cascade が globs パターンに一致するファイルを読み取りまたは編集するときにルールが適用されます。」 コスト：一致するファイルが操作されたときのみ。
manual — 「ルールはシステムプロンプトに含まれません。Cascade の入力ボックスで @rule-name と入力することで有効化します。」 コスト：@メンションされたときのみ。
これらのコストを段階（ラダー）として捉えてください。always_on から model_decision に移行すると、メッセージごとの固定コストが説明サイズに変換され、本文はオンデマンドでロードされるようになります。glob に移行すると、コストは操作するファイルに依存するようになります。manual に移行すると、コストはあなたが明示的に要求したときのみ発生するようになります。
ここで、この取り組み全体の前提を覆す部分を紹介します。
「グローバルルールファイル（global_rules.md）およびルートレベルの AGENTS.md ファイルはフロントマターを使用しません。これらは常にオンです。」これら2つの領域にはモードがありません。構造上、常にオンになっています。そのため、最適化を始める前に、すでに予算の一部がコミットされています。そして、その制限がどれだけの予算が使われているかを教えてくれます。グローバルファイルは ~/.codeium/windsurf/memories/global_rules.md にあり、すべてのワークスペースに適用され、「6,000文字に制限」されています。ワークスペースルールは .devin/rules/（推奨）または .windsurf/rules/（フォールバック）に1ファイルにつき1つ配置され、「1ファイルあたり12,000文字に制限」されています。
そして、人々が忘れがちな3つ目の「常にオン」の領域があります。「ワークスペースルートにあるレガシーな単一ファイル .windsurfrules も引き続き読み込まれます。」 数年前にルールディレクトリに移行したものの、そのファイルを削除していなかった場合、それは今でもロードされ続けています。
AGENTS.md は、フロントマターではなく配置場所によってモードが割り当てられます。「ルートレベル = 常にオン、サブディレクトリ = そのディレクトリに対する自動 glob。」 これは非常にエレガントなデフォルト設定ですが、ファイルを1つ上のディレクトリに移動するだけで、そのコストが条件付きから恒久的なものへと静かに変化することを意味します。
この問題の一般的なパターン（ルールは存在するが期待通りに動作しない）については、why agents ignore your instruction files で詳しく解説しています。
人々が代わりに試してしまうこと
すべてを always_on に設定する。 ルールが確実に適用されるため、これが最も安全に感じられます。しかし、フロントエンドの開発から一歩も出ないセッション中に、Terraform の規約に対してメッセージごとの予算を消費することになり、長い会話の中でコストが累積していきます。その症状は、when Windsurf's agent loses context で説明されているコンテキストの逸脱として現れます。
モードを変更する代わりに、より短いルールを書く。 有益ではありますが、解決する変数を間違えています。すべてのメッセージでロードされる400文字のルールは、2回しかロードされない3,000文字のルールよりも、セッション全体で多くのコストがかかります。簡潔さと有効化は独立したレバーであり、後者の方が強力です。簡潔さだけに頼るアプローチの限界については、why shorter prompts aren't enough のテーマとなっています。
代わりに自動生成されたメモリ（Memories）に依存する。 Windsurf 自体もこれに対して警告しています。「Cascade に確実に再利用させたい知識については、自動生成されたメモリに依存するのではなく、ルールとして記述するか、リポジトリの AGENTS.md に追加してください。ルールはバージョン管理可能で、チームと共有でき、有効化を明示的に制御できます。」 比較表でもメモリの位置づけを明確にしています。「一回限りの事実は Cascade に記憶させ、永続的な知識にはルールまたは AGENTS.md を優先してください。」 また、ドキュメントに記載されているスコープの警告にも注意してください。メモリはレガシーな Cascade エージェントにのみ適用されると文書化されており、新しいタブのデフォルトである Devin Local エージェントはそれらを永続化しません。
簡素化のためにすべてを1つのファイルに統合する。 これは、管理可能なモード決定のセットを、区別のない1つの巨大な「常にオン」のブロックと引き換えることになり、ファイルごとの文字数制限に達してしまいます。このフォルダレベルの決定プロセスについては、merging Windsurf and Devin rule folders で詳しく説明しています。
エンタープライズルールがこの混乱を上書きしてくれると仮定する。 上書きはされません。ドキュメントには明確に記載されています。システムレベルのルールは「ワークスペースルールおよびグローバルルールとマージされ、ユーザー定義のルールを上書きすることなく、Cascade に追加のコンテキストを提供します。」 管理者が設定したベースラインは、予算を置き換えるのではなく、予算に追加されます。
解決策：各ルールのコストを見積もり、コストに合ったモードを割り当てる
決定すべきことは「どのモードが最適か」ではありません。「このルールは実際にどのくらいの頻度で関連するか」であり、モードは4つの率直な回答に対応しています。
ステップ 1：モードのない領域を含め、すべての領域を棚卸しする
何かを変更する前に、すべてをリストアップしてください。ルールが適用される場所は5つあり、そのうち trigger フィールドを持つのは1つだけです。
~/.codeium/windsurf/memories/global_rules.md にあるグローバルファイル — 常にオン、6,000文字。
ルートレベルの AGENTS.md — 常にオン、フロントマターなし。
サブディレクトリの AGENTS.md ファイル — そのディレクトリに対する自動 glob。
ワークスペースルートにあるレガシーな .windsurfrules（存在する場合） — これを確認してください。これは、自分が消費しているとは知らなかった予算の最も一般的な原因です。
.devin/rules/ または .windsurf/rules/ にあるワークスペースルールファイル — 1ルールにつき1ファイル、各12,000文字。モードを選択できる唯一の領域です。
まず「常にオン」の合計を計算してください。その数値があなたの最低ライン（フロア）であり、条件付きルールがロードされる前に、すべてのメッセージが支払うコストになります。
ステップ 2：各ワークスペースルールを4つの回答のいずれかに分類する
ルールを1つずつ確認し、それが本当に必要になる頻度を問いかけてください。回答は直接マッピングされます。
すべてのメッセージに関連する。 「イギリス英語で応答する」や「main に直接コミットしない」など。これらには always_on を割り当てます。これらは極めて少数であるべきであり、その合計サイズが注意すべき数値です。
時々、予測不可能なタイミングで関連する。 特定のトピックが発生したときにエージェントが参照すべきドメイン知識（決済の制約、コンプライアンスルールなど）。これらは model_decision に該当します。デフォルトでロードされるのはこの部分だけであるため、ここでは説明（description）が重要な役割を果たします。タイトルではなく、「どのようなときにこれを使用するか」を説明する文として記述してください。
特定のファイルが関与するときに関連する。 テスト規約、マイグレーションの安全性、生成されたコードなど、ファイルに関連するすべてのもの。これらは glob に該当し、通常これが最大の効果をもたらします。なぜなら、ほとんどの規約はファイルに関連するものであり、多くの人がそれらを always_on に設定していたからです。
あなたが指示したときに関連する。 リリースチェックリスト、インシデント手順など、意図的に呼び出すもの。これらは manual に該当し、@rule-name で有効化します。
ルールがこれら4つのいずれにも当てはまらない場合、それは問題の兆候です。通常、そのファイルは「常に真であるルール」と「状況に応じたルール」の2つが結合されていることを意味します。分割することで、それぞれの半分に適合するモードを割り当てることができます。
ステップ 3：ファイルの確認ではなく、矛盾検証によって確認する
フロントマターを見るだけでは、モードが正しく機能しているか確認できません。重要なのは、エージェントが実際にそのコンテンツを受け取ったかどうかだからです。
glob ルールの場合、一致しないはずのファイルを開き、そのルールが変更を加えるような要求をしてみてください。それでもルールの動作が適用される場合、パターンが想定よりも広すぎます。次に、一致すべきファイルを開き、動作が適用されることを確認します。
model_decision ルールの場合、ルール名を指定せずにそのトピックについて質問してください。エージェントがそれを参照しない場合、本文ではなく説明（description）に問題があります。
manual ルールの場合、@rule-name による呼び出しが解決されることを確認し、言及していないときにはルールが適用されないことを確認します。これがこのモードの本質です。
モード変更後は、ルールごとにこの検証を1回行ってください。設定されたモードと、実際に機能しているモードを区別する唯一の方法であり、when Windsurf forgets your project rules で発生する問題を捉えるのと同じアプローチです。
MemoryLake での設定方法
この作業を経て残るものは2つありますが、ルールディレクトリに収まるのはそのうちの1つだけです。指示（どのように振る舞うか、何を優先するか）は、まさに Windsurf が指定する場所に置くべきです。しかし、その背後にある理由（「1日単位の請求を使用する」はルールであり、「財務システムが端数の日数を拒否するため」は、エージェントがそのルールの適用外となる状況を判断するための情報です）は、そこに置くべきではありません。
MemoryLake は、文字数制限や特定のエディタの枠を超えて、この2つ目のレイヤーを保持します。ルールはより短くなり、「常にオン」の最低ラインは下がり、その根拠は使用するすべてのツールから引き続き利用可能になります。
ステップ 1：API キーを作成する
サインインし、ワークスペースの設定を開き、API キーを生成します。これは、エディタやエージェントが同じレイヤーを読み取るために使用する認証情報です。一度作成すれば、各マシンからアクセスできるようにしておくだけです。
ステップ 2：最初のメモリをアップロードする
ルールの本文から根拠を切り離します。なぜその規約が存在するのか、どの手法を不採用にしたのか、どのような制約によって明白な答えが誤りとなるのか。ルールファイルには指示を残し、レイヤーにはその正当な理由を保持します。
ステップ 3：AI とエージェントを接続する
Windsurf や、その他に使用しているツールを接続します。同じ根拠がそれぞれに届きます。ルールディレクトリは次のツールには引き継がれませんが、そこにある決定事項は引き継がれるべきであるため、これは非常に重要です。
実践においてこれがもたらす変化
最初の違いは、1回のセッション内ですぐに測定できます。ファイルに関連する規約を always_on から glob に移行することで、それらがすべてのメッセージから除外され、2時間を超えるような長い会話でもパフォーマンスが低下しなくなります。
2つ目は、model_decision が実用的になることです。これは最も興味深いモードでありながら、最も無駄にされがちです。なぜなら、ラベルのように書かれた説明（description）では、エージェントが判断を下す材料にならないからです。条件として記述することで、機能的なオンデマンドの領域になります。
3つ目は、「常にオン」の最低ラインが把握可能な数値になることです。6,000文字のグローバルファイル、ルートの AGENTS.md、そして忘れ去られた .windsurfrules の間で、その最低ラインは、人々が管理していると思っている予算の大部分を占めていることがよくあります。
4つ目は、ルールが根拠を抱え込まなくなることです。短いファイルは12,000文字の制限に余裕で収まり、正当な理由は人間が読め、別のツールがロードできる場所に保管されます。これを行わない場合のコストは、when Windsurf forgets Cascade context で見られるようなコンテキストの喪失として現れます。
ルール有効化のベストプラクティス
always_on ではなく glob をデフォルトにする。 ほとんどの規約はファイルに関するものです。エージェントに公開する範囲をそれに合わせましょう。
model_decision の説明（description）は条件として記述する。 「決済フローや返金ロジックを処理するときに使用する」は、「決済ルール」よりも優れています。デフォルトでロードされるのは説明部分だけです。
確認が終わったら、レガシーファイルを削除する。 ワークスペースルートにある .windsurfrules は引き続き読み込まれます。それが信頼できる唯一の情報源（Source of Truth）であるか、あるいは存在すべきではありません。
ファイルを移動したときの影響に注意する。 サブディレクトリの AGENTS.md はそのディレクトリに対する自動 glob になりますが、ルートにある同じファイルは「常にオン」になります。ディレクトリの移動はコストの変化を意味します。
他を最適化する前に、「常にオン」の合計をカウントする。 6,000文字のグローバルファイルがすべてのメッセージでロードされている状態で、条件付きルールを最適化するのは順序が間違っています。
自動生成されたメモリは、一回限りの事実として扱う。 これは Windsurf 自身の位置づけであり、永続的な知識は代わりにルールまたは AGENTS.md に記述することが推奨されています。
モード変更後は必ず再検証する。 フロントマターの編集は証拠になりません。矛盾検証こそが証拠です。
結論
Windsurf はすでに難しい部分をクリアしています。各有効化モードのコストと、それぞれがいつロードされるかを公開したことです。4つのモードは、ルールがどれだけの頻度で関連するかという4つの率早な回答にきれいにマッピングされます。ほとんどのルールディレクトリが誤って設定されているのは、ファイルごとにその質問に向き合って答えを出した人がいなかったからにすぎません。
ですから、答えを出しましょう。モードのない領域を棚卸しし、それらが課す最低ラインのコストを合算し、残りを4つのバケツに分類し、フロントマターを読むのではなく矛盾検証によって確認してください。そして、ルールの本文から根拠を取り除いてください。文字数制限は、規約が存在する理由の説明を保管するには不適切な場所だからです。また、次に使用するツールには独自の制限や独自のモードがあり、このディレクトリを読み取る方法が全くないかもしれないからです。