なぜ修正の瞬間だけが唯一の絶好の機会なのか
指示ファイルは、エージェントが何を必要とするかを誰かが想像しながら、事前に作成されます。これは合理的なアプローチであり、ビルドコマンド、スタイル、レビュー手順といった安定した要素を捉えることができます。しかし、それ以外のすべてを体系的に見落としてしまいます。なぜなら、エージェントが実際に何につまずくかは、実際につまずくまで分からないからです。
Continueはルールの目的を明確にしています。ルールは「Agentモード、Chat、およびEditリクエストに対して、モデルにシステムメッセージの指示を提供」し、「システムメッセージを形成するために、ルールはツールバーに表示される順序で改行で結合」されます。ルールとは、リクエストごとに再送信されるプロンプトレベルの設定です。この位置づけは正確であり、想像だけでルールを書くと内容が薄くなってしまう理由を説明しています。システムメッセージの内容を推測しているに過ぎないからです。
一方、修正は異なります。優れたルールに必要なものがすべて揃った状態で届きます。間違っていた具体的な挙動、正しい挙動、そして（イライラしているときに口に出しがちな）その「理由」です。「照合にバッチエンドポイントを使用しないでください。1万行を超えるとタイムアウトするためです」。この最後の節こそが、将来の意思決定においてルールを生き残らせる要素です。単なる禁止事項は、最初に不都合が生じた時点で無視されてしまいます。
問題は、人々がこれを知らないことではありません。書き留めるという作業が「2つ目のタスク」になってしまい、最もその気力がない瞬間に実行しなければならないことです。これこそが、ツール呼び出し（tool call）が存在する理由です。
代わりに試みられがちなこと
セッションごとに制約を再入力する。 これがデフォルトであり、コードが正しく出力されるという意味では機能します。しかし、その代償として、制約の半減期はあなたの記憶力と同じになり、チームの他のメンバーからは見えなくなります。この問題の全体像については、AIへのコンテキストの再説明をやめる方法で解説しています。
常にオンになっている1つの巨大なルールファイル。 学んだことすべてを alwaysApply: true に設定した単一のルールに詰め込みます。常に存在するという点では失敗しませんが、それが問題です。数ヶ月も経つと、モデルはリクエストごとに、タスクとは無関係なものも含めて、蓄積された数千語の修正を受け取ることになります。重要なルールとそうでないルールが競合してしまうのです。モデルに提示する情報を少なく保つ方が、通常はより良いトレードオフになります。これについては、エージェントの記憶と情報を少なく保つことで議論しました。
READMEや設計書に書き込む。 直感としては正しいですが、器が違います。Continueは.continue/rulesからルールを読み込みます。READMEは、何らかの方法で組み込まれない限り、システムメッセージには含まれません。知識は人間向けに保存されますが、エージェントには伝わりません。
会話を信頼する。 修正はチャット内にあるため、モデルはそれを把握しているはずです。確かに、そのセッション内では把握しています。しかし、Continueのルールが存在するのは、そこが境界線だからです。指示はリクエストごとに再提供されるものであり、チャットは保存場所ではありません。その理由については、なぜエージェントは指示ファイルを無視するのかで詳しく説明しています。
スキル（Skills）に頼る。 スキルは手順をパッケージ化したものです。修正は手順ではなく、コードベースに関する「事実」であり、この違いは思った以上に重要です。なぜエージェントのスキルは記憶ではないのかを参照してください。
解決策：修正の瞬間にキャプチャし、呼び出し方法を選択する
Step 1: ルール作成を有効にし、修正と同時に実行する
create_rule_blockはエージェントが呼び出すツールであり、Continueのドキュメントには「有効な場合」に動作すると記載されています。そのため、これに頼る前に、Agentモードのツールリストで利用可能であることを確認してください。また、Continueには手動でルールを作成するための「Add Rules」ボタンも用意されており、会話からではなくゼロからルールを書きたい場合のフォールバックとして機能します。
効果的な利用パターンは、修正とキャプチャをワンアクションで行うことです。「いや、ここではストリーミングパーサーを使って」と言ってそのまま進めるのではなく、「いや、ここではストリーミングパーサーを使って。バッチエンドポイントは1万行を超えるとタイムアウトするから。これに関するルールを作成して」と言います。エージェントは直前の会話から派生したルールを.continue/rulesに書き込みます。これには、指示だけでなくその理由も含まれます。
生成されたファイルについて確認すべき点が2つあります。これらはステップ2のすべてを決定づけるものです。Continueのドキュメントによると、ルールは「適切なYAMLフロントマターを持つ.mdファイルである必要があり」、フォルダは.continue/rules/でなければなりません（トラブルシューティングセクションで特に指摘されているタイポである.continue/rule/ではありません）。次に、エージェントが書き込んだフロントマターを確認します。エージェントはあなたに代わってglobs、description、alwaysApplyを選択していますが、その選択はあくまで推測に過ぎません。
この機能を提供しているのはContinueだけではありません。Cursorにも同様の処理を行う/create-ruleコマンドがあります。Continueがより明確にドキュメント化しているのは「取得（retrieval）」側であり、ここに興味深い決定要素があります。
Step 2: 取得動作を意図的に選択する
Continueの3つのフロントマターフィールドは相互に作用し、3つの異なる挙動を生み出します。ドキュメントではそれらが詳しく説明されています。
alwaysApply: true の場合、ルールは「常に含まれます」。これは、触っているファイルに関係なく適用される制約にのみ使用してください。照合エンドポイントに関する修正は、これには該当しません。
alwaysApply: false の場合、ルールは「globsが存在し、かつファイルコンテキストに一致する場合、またはエージェントがその説明（description）に基づいてルールをコンテキストに引き込むと判断した場合に含まれます」。これは、キャプチャされたほとんどの修正が求めるモードであり、2つの独立したトリガーを持っています。制約がどのファイルに適用されるか分かっている場合は、globsを設定します。Continue의ドキュメントでは、globは「ファイルがコンテキストとして提供されたとき」に一致すると説明されています。制約がパスではなく概念に関するものである場合は、descriptionを活用し、要約ではなく「取得クエリ」として記述します。Continueは、「alwaysApplyがfalseの場合、エージェントはこの説明を読み、ルールをコンテキストに引き込むべきかどうかを判断することがある」と明記しています。「照合の制約」という説明では、夜間の決済ジョブを作業しているときには起動しません。「バルクエンドポイント、照合、決済、および大量の行数をページングするものに対する制約」と記述されていれば、起動します。
alwaysApplyを完全に省略すると、デフォルトの挙動になります。「globsが存在しない場合、またはglobsが存在して一致する場合に含まれます」。つまり、globsもalwaysApplyもないルールは常にオンになります。これは合理的なデフォルトであると同時に、意図しない事故の原因にもなります。エージェントがフロントマターのないファイルを生成した場合、意図せず常にオンのルールを作成してしまったことになります。
知っておく価値のある順序の詳細として、「ルールファイルは辞書順（lexicographical order）でロードされるため、名前に数字のプレフィックスを付けて適用順序を制御できる」という点があります。例えば、01-general.md や 02-frontend.md のような名前を使用します。ルールは1つのシステムメッセージに結合されるため、実際には順序が優先順位になります。キャプチャされた修正は、通常、一般的な規約の後に適用されるよう後半に配置すべきです。そうすることで、さらに下にある一般的なルールと矛盾することなく、「洗練されたルール」として解釈されます。
Step 3: フォルダが一杯になる前に、ルールと事実を分離する
数週間キャプチャを続けたら、.continue/rulesフォルダを読み返し、各ファイルについて「これは規約（convention）か、それとも事実（fact）か？」と自問してみてください。
規約とは、ここでの作業方法（命名規則、エラーハンドリングの形式、使用するテストランナーなど）を定義するものです。これは安定しており、広く適用されるため、まさにシステムメッセージが果たすべき役割です。これは残しておきましょう。安定しているものの膨大なドメイン知識は3つ目のケースであり、プロンプトではなくストアに保存すべきです。これについては、Claudeに永続的なドメイン知識を与える方法を参照してください。
事実とは、何が起きたかを説明するものです。「メモリ回帰の後、7月にストリーミングパーサーの使用をやめた」「ベンダーのサンドボックスにはフィクスチャサーバーが必要なため、決済テストでは異なるコマンドを使用する」「不安定な統合テストに対して2つの修正を試みたが、どちらも同じ理由で失敗した」。これらは規約にはない性質を持っています。際限なく蓄積され、編集されるのではなく上書き（代替）され、そのほとんどは四半期に数回程度のタスクにしか関連しません。
ルールとして保存された事実は、気づかないうちに陳腐化します。あるルールが「8月に覆された決定」を説明していることを教えてくれるものは何もありません。覆された決定がシステムメッセージの指示として提示されることは、ルールが全くないことよりも悪影響を及ぼします。これは、レビュー履歴システムを乖離させるのと同じ失敗です。これについては、フィードバックから改善するエージェントで考察しました。
Continueのドキュメント化されたメカニズム（これら3つの取得モードを持つルール）は、規約をうまくカバーしています。しかし、チームが確立した事柄の、蓄積され上書き可能な記録を保持する「ストア」に相当するものは、ドキュメントには存在しません。これはルールシステムの適用範囲（スコープ）に関する話であり、批判ではありません。システムメッセージは、どのようなツールであっても、そのタスクには適していない形状だからです。
MemoryLakeでの設定方法
MemoryLakeは、事実の半分を保存する場所です。リポジトリの外部にあるストアであり、確立された決定を保持し、静かな陳腐化の代わりに上書きをサポートし、実行している任意のエージェントからMCPまたはAPI経由で読み取ることができます。
Step 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。同じキーがContinue、チームメイトのエディタ、およびCIから機能します。
Step 2: 最初の記憶をアップロードする
現在のリトライポリシーの背景にあるインシデント報告書、誰も繰り返したくないデザインレビュー、および先ほど規約ではなく事実として特定したルールファイルなど、プロジェクトの決定事項がすでに含まれているドキュメント、画像、ファイルを投入します。
Step 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントにMCPまたはAPI経由でアクセスを許可します。Continueにおいては、確立された事実がシステムメッセージに永続的に常駐するのではなく、関連性があるときにのみ取得されるようになります。
これによって実際に何が変わるか
ルールフォルダが際限なく肥大化するのを防げます。事実の保存先が別に確保されれば、.continue/rulesは実際の規約のサイズに収まります。ほとんどのリポジトリにおいて、これは小さく、読みやすく、プルリクエストでレビュー可能な規模です。
説明（description）が、整理のためではなく「取得」のために書かれるようになります。descriptionの唯一の役割が、エージェントがルールを取り込むべきか判断するのを助けることである場合、書き方が変わり、保持しているルールが必要なときに正しく起動するようになります。
修正がリポジトリの寿命を超えて生き残ります。ルールは1つのチェックアウト内に存在します。しかし、外部でキャプチャされた事実は、隣のサービスで同じ制約が発生したときにも利用可能です。実際、同じ説明を繰り返す状況のほとんどは、そうした別の場所で発生します。
そして、キャプチャの習慣を維持するコストが十分に低くなります。これこそがcreate_rule_blockの真の価値です。何かを書き留めるコストがわずか数語にまで下がります。それが正しく呼び出されるかどうかは別の決定事項であり、今やそれを意図的にコントロールできるようになります。
Continueでキャプチャされたルールのベストプラクティス
常に理由を含める。 「Xを使用しない」は無視されますが、「Yのため、Xを使用しない」は無視されません。
フロントマターを成り行き任せにしない。 エージェントが生成した内容を確認してください。globsもalwaysApplyもないファイルは、すべてのリクエストでオンになります。
説明はラベルではなくクエリとして書く。 alwaysApplyがfalseの場合、説明は取得のシグナルになります。実際に手動で入力するような言葉を含めてください。
ルールファイルに番号を付ける。 辞書順のロード順序が実際の優先順位になります。規約は前半に、洗練されたルールは後半に配置します。
Markdownファイルを優先する。 Continueは、ルールが元々YAMLで定義されていたものの、現在はMarkdown形式を推奨していると言及しています。1つの形式に統一することで、フォルダのレビューが容易になります。
月に一度フォルダを読み返す。 規約を削減するためではなく、いつの間にか誤りになってしまった事実を捉えるためです。
結論
create_rule_blockは、ほとんどのツールが個人の規律に委ねている本質的な問題を解決します。制約に気づくことと、それを記録することの間の摩擦を取り除くのです。「これに関するルールを作成して」と言うだけで、修正内容が理由付きのファイルになり、これは手動で書かれたほとんどのルールよりも優れた成果をもたらします。
あなたに残された半分の作業は「取得」であり、Continueはそれを適切に行うための要素を提供しています。パス範囲の制約にはglobs、概念範囲の制約にはdescription、無条件の少数の事項にはalwaysApply、そして優先順位のための辞書順ソートです。特にエージェントが生成したファイルに対しては、これらを意図的に使用してください。なぜなら、「一度も起動しないルール」と「起動し続けるルール」は逆の方向で失敗を招き、どちらも結果としてルールフォルダを形骸化させてしまうからです。
そして、全体を健全に保つための整理を行いましょう。規約はシステムメッセージに属します。事実は、蓄積され修正可能な記録を保持し、重要な部分だけを返せる場所に属します。この境界線を正しく設定することこそが、キャプチャの習慣を「誰も読まないディレクトリ」に終わらせないための鍵となります。