なぜkilo.jsoncが完全なリストではないのか
Kiloの現在のルールモデルは明示的であり、それ自体は適切に動作します。プロジェクトルールは「プロジェクトのkilo.jsoncファイル内のinstructionsキーを介して設定」され、「各エントリはファイルパスまたはglobパターンを指し」ます。グローバルルールは、グローバル設定（通常は~/.config/kilo/kilo.jsonc）の同じキーを使用します。
読み込み順序は配列に従います。「ルールはkilo.jsoncのinstructions配列に表示される順序で読み込まれ」ます。最初にグローバル設定、次にプロジェクトの設定です。優先順位は逆になり、「競合するディレクティブについては、プロジェクトレベルの指示がグローバルな指示よりも優先され」ます。「JSONCは//コメントをサポートしている」ため、ルールを削除せずに一時的に無効化することも可能です。
これはマニフェストであり、優れた設計です。以下に挙げるのは、このマニフェストの枠外にあるものです。
Globエントリは順序を放棄します。 ドキュメントには「globパターンに一致するファイルはファイルシステムの順序で読み込まれる」と明記されています。配列内の位置が唯一の優先順位制御手段であるため、.kilo/rules/*.mdのような単一のエントリを使用すると、一致するすべてのファイルについて、順序付きリストが順序なしリストに変わってしまいます。ドキュメントのサンプル設定では、特定のファイルと同じディレクトリをカバーするglobがペアになっていますが、これは一見便利に見えて、どのルールが優先されるかを制御する能力を密かに奪っています。
レガシーディレクトリはリストに記載されていなくても読み込まれます。 これが、開発者が何日も無駄にする原因となるものです。
「プロジェクト内に.kilocode/rules/ディレクトリが存在する場合、後方互換性のためにその内容が自動的にインクルードされます。完全に移行するには、ルールファイルを移動し、kilo.jsoncでそれらを参照してください。」
これは単なる注記ではなく、現在も有効な挙動として理解してください。Kiloはディレクトリ名を.kilocode/から.kilo/に変更しましたが、古いディレクトリも依然として自動的に読み込まれます。配列へのエントリも、優先順位テーブルでの位置もありません。以前のバージョンを通過したリポジトリには、並行して動作する第2のルールツリーが存在することになりますが、あなたが読んでいるkilo.jsoncにはそれが一切記載されていません。
ディレクトリごとのAGENTS.mdファイルは、ファイルアクセス時に注入されます。 Kiloはサブディレクトリ内のAGENTS.mdをサポートしており、その仕組みを正確に説明しています。「ディレクトリごとのAGENTS.mdファイルは、エージェントがそのディレクトリ内のファイルを読み取るときに動的に読み込まれます。セッション開始時に事前ロードされるわけではありません。エージェントがsrc/backend/内のファイルを読み取ると、対応するAGENTS.mdが検出され、その内容が<system-reminder>タグとして会話に注入されます。」
これは優れた機能です。しかし同時に、エージェントがたまたま開いたファイルに応じて、会話の途中で有効な指示セットが変化することを意味します。また、ルートファイルのみをカバーする優先順位テーブルでは、これらの注入された指示がどの順位に位置づけられるかが説明されていません。
ルートのAGENTS.mdは無効化できません。 「AGENTS.md自体を個別に無効にすることはできません。存在する場合は常に読み込まれます。その指示を上書きするには、instructions設定キーやエージェント固有のプロンプトなど、より優先順位の高いソースを使用してください。」また、AGENTS.mdとAGENT.mdはどちらも「Kilo Codeにおける書き込み保護ファイル」であるため、「AIエージェントはユーザーの明示的な承認なしにこれらのファイルを変更することはできません。」安全面では優れており、エージェントに整理を依頼する前に知っておく価値があります。
ファイル名は大文字・小文字が区別され、多くの人を驚かせます。 Kiloは「ファイル名は小文字（agents.md）ではなく、大文字（AGENTS.md）でなければならない」と警告しています。優先順位の高い順にサポートされている名前は、AGENTS.md、次にAGENT.mdです。他のエージェントではこの扱いが異なり、両者を等価として扱うものもあるため、共有リポジトリでは大文字に統一すべきです。
古いメモリバンクはまだ生きています。 Kiloの非推奨通知には「Kilo Codeのメモリバンク機能はAGENTS.mdを優先して非推奨になりました」とあり、すぐに「既存のメモリバンクルールは引き続き機能します」と付け加えられています。注意すべきはステータスインジケータの部分です。「[Memory Bank: Active]や[Memory Bank: Missing]などのレガシーなメモリバンクステータスインジケータは引き続き表示される可能性がありますが、すべてのクライアントやモードで保証されているわけではありません。」この警告は重要です。バッジはサポートされているクライアントやモードに限定されているため、確実な答えではなくヒントとして扱い、実際の挙動で検証してください。
これらを合わせると、配列以外に5つのソースが存在することになります。これこそが、「ルールが適用されない」という報告のほとんどの実際の原因であり、モデルの問題ではなく設定の問題です。この違いについては、エージェントが指示ファイルを無視する理由で詳しく説明しました。
よくある誤ったアプローチ
kilo.jsoncを読んでそれを信用する。 最も一般的なアプローチですが、構造的に誤っています。配列は複数の入力の1つに過ぎず、2つのサイレントな入力（レガシーディレクトリとディレクトリごとの注入）は、設定ファイルには決して表示されません。
すべてをキャッチするために広範なglobを追加する。 ".kilo/rules/**/*.md"を指定すれば漏れはなくなりますが、globの一致は「ファイルシステムの順序」で読み込まれるため、セット全体の順序が失われます。不完全なリストを、順序のないリストと交換しただけになってしまいます。
すぐに.kilocode/を削除する。 最終的なゴールとしては正しいですが、最初のステップとしては危険です。それらのファイルは、おそらく数ヶ月にわたって有効に機能しており、あなたが依存している挙動の一部はそこから来ている可能性があります。読み込みパスから外してレビュー用の場所に移動し、それから判断してください。
すべてをAGENTS.mdに記述する。 優先順位は3位で、無効化できず、他のツールも読み取れるフォーマットです。しかし、フロントマターや条件付き読み込みに対応していないため、単一のルートファイルがすべてのタスクにおいて「常にオン」のコンテキストになってしまいます。この「常時オン」のバジェットに関する問題は、コーディングエージェントが実際に読んでいるもので検証した内容と同じです。
ルールをスキルに変換する。 スキルはオンデマンドで読み込まれるため、一見すると自由な条件分岐のように思えます。Kiloは、その選択プロセスについて非常に率静に説明しています。「エージェント（LLM）は、スキルのdescriptionフィールドに基づいてスキルを使用するかどうかを決定します。キーワードマッチングやセマンティック検索はありません。エージェントは、利用可能なすべてのスキルの説明に対してリクエストを評価し、いずれかが『明確かつ曖昧さなく適用される』かどうかを判断します。」常に維持されるべき規約は、このような関連性の判断を生き残ることはできません。そのため、スキルはルールの代わりにはならず、メモリの代わりにもなりません。これについてはエージェントのスキルがメモリではない理由で論じました。
解決策：1つの順序付きリストを作成し、それが完全であることを証明する
3つのステップがあります。3番目のステップは多くの人が見落としがちですが、サイレントなソースを検出できる唯一の方法です。
ステップ1：Kiloが読み込み可能なすべてのパスを棚卸しする
何かを変更する前に、リポジトリを走査し、以下の各場所に何が存在するかを書き留めます。
まずは宣言されたセットから始めます。プロジェクトのkilo.jsoncにあるinstructions配列と、~/.config/kilo/kilo.jsoncにある同じキーです。すべてのglobを手動で展開し、ファイルシステムの順序で一致する実際のファイル名を書き出します。これにより、Kiloが使用する順序を確認できます。
次に、宣言されていないセットです。プロジェクト内の任意の場所で.kilocode/rules/を探します。通知には「directories（複数形）」とあるため、サブディレクトリも確認してください。.kilo/rules/memory-bank/およびレガシーな.kilocode/rules/memory-bank/を確認します。ルートだけでなく、ツリー内のすべてのAGENTS.mdおよびAGENT.mdを見つけ、それぞれがどのディレクトリを制御しているかを記録します。CLIを使用している場合は、他のツールとの互換性のために読み込まれる.claude/および.agents/も確認してください。外部スキルディレクトリを対象外にしたい場合は、環境変数KILO_DISABLE_EXTERNAL_SKILLSを使用してオフにすることができます。
これでリストが完成しました。これはkilo.jsoncよりも長くなっているはずであり、その差分こそが、あなたが動作していると知らなかったものです。
ステップ2：リストを1つの宣言された順序付き配列に集約する
各アイテムの移行先を決定し、配列を現実に合わせます。
常に適用されるべきリポジトリ全体の規約は、ルートのAGENTS.mdに配置します。これは無効化できず、他のツールからも読み取られ、エージェントによる誤った編集から書き込み保護されています。常にオンになるため、簡潔に保ちましょう。
明示的な順序付けが必要なルールは、個別のファイルとして.kilo/rules/に配置し、プロジェクトのinstructions配列にフルパスで記載します。希望する順序で1行に1つずつリストします。ここではglobを使用しないでください。globはまさに順序を破棄する原因となります。
ディレクトリ固有のガイダンスは、ディレクトリごとのAGENTS.mdファイルに配置します。これは、エージェントが作業している場所に基づいてコンテンツを読み込むためにKiloがドキュメント化している唯一の仕組みです。
個人の好みはグローバルのkilo.jsonc配列に配置します。ただし、グローバルは優先順位4であり、プロジェクト配列とルートのAGENTS.mdよりも下にあることを忘れないでください。
その後、レガシーパスを空にします。.kilocode/rules/の内容を読み込みパス以外の場所（docs/サブディレクトリなど）に移動し、本当に必要なものだけを配列内の明示的なパスで再追加します。メモリバンクについても同様です。Kilo自身の移行手順では、「.kilo/rules/memory-bank/（またはレガシーな.kilocode/rules/memory-bank/）の内容を確認し」、「その内容をプロジェクトのAGENTS.mdファイルに移動する」ことが推奨されています。現在も正確な部分のみを移動し、古いバージョンのコードベースを記述している部分は削除してください。
ステップ3：目視ではなく、矛盾検証によってリストを証明する
設定ファイルは、自身に記載されていないファイルに対して自己検証することはできません。そのため、境界を直接テストします。
意図した最も優先順位の低いソースの最下部に、意図的に珍しく無害な指示（他では絶対に使わないような特徴的な変数命名規則など）を配置します。エージェントに小さな関数を書くよう依頼します。その命名規則が適用されれば、そのソースが読み込まれており、それより上のソースで矛盾する指示がないことが証明されます。
次に、テストを反転させます。読み込まれていないはずのソース（空にする前のレガシーな.kilocode/rules/パスなど）に、直接矛盾する指示を配置します。再度依頼します。矛盾するバージョンが優先された場合、そのパスは有効であり、あなたが信頼できると考えていたソースよりも上位に位置していることになります。Kiloは指示ソース間の競合を表示しないため、矛盾テストが解決策を確認する唯一の方法です。一般的なパターンについては、メモリ競合の検出で説明しています。
独自のAGENTS.mdを持つサブディレクトリから、このテストをもう一度繰り返します。ディレクトリごとのファイルは、エージェントがその場所のファイルを読み取ったときにのみ注入されるためです。リポジトリのルートからのテスト実行では、これらは検証されません。
MemoryLakeでの設定方法
統合によって順序付きリストは手に入りますが、なぜその行がそこにあるのかという理由はわかりません。記録された理由のないルールは、次回のクリーンアップ時に真っ先に削除されてしまいます。
MemoryLakeはその理由を保持します。どのルールがどのインシデントによって存在するのか、何を試して却下されたのか、どの制約がコードではなく人間から課されたものなのか。これはinstructions配列の外に存在するため、順序の変更、名前の変更、ディレクトリの移行によって失われることはありません。ここから始めましょう。
ステップ1：APIキーを作成する
リポジトリ用のワークスペースを作成し、APIキーを生成します。次のツールへの移行が書き換えではなく設定変更だけで済むよう、Kiloではなくリポジトリにスコープを設定します。
ステップ2：最初のメモリをアップロードする
これは、統合のステップ1の最中、読み込まれているとは知らなかったファイルを読んでいるときに行います。.kilocode/rules/で見つかった各ルールについて、残すかどうかを決定する前に、それがなぜ書かれたのかを記録します。後からその判断を下すのははるかに困難です。現在も正確なメモリバンクの内容を追加し、どの部分をなぜ削除したかを書き留めます。
ステップ3：AIとエージェントを接続する
使用しているすべての環境でKilo Codeを接続します。VS Code拡張機能とCLIは優先順位テーブルを共有していますが、外部ディレクトリの扱いが異なるため、両者が同じ決定セットを読み取るようにする必要があります。同じリポジトリでまだClineを実行している場合は、それも接続してください。この2つはルールファイルの遺産を共有しており、共有レイヤーによって両者の乖離を防ぐことができます。
実践における変化
「ルールが適用されない」という問題は、半日かかる作業から5分のチェックへと変わります。棚卸しが済んでいるため、問題は「既知のソースのどれが優先されているか」であり、「未知のファイルが存在するかどうか」ではありません。
順序付けが現実のものになります。globを明示的なパスに置き換えることで、配列内の位置が実際に優先順位を決定するようになり、競合が発生しても予測可能な答えを指し示すことができます。
レガシーディレクトリが第2の真実のソースになることはなくなります。.kilocode/rules/が空になれば、優先順位テーブルとディレクトリごとのAGENTS.mdマップが全体像のすべてになります。
そして、クリーンアップを行っても理由は残ります。統合は設計上、ファイルを削除することを伴います。ルールを削除することは問題ありませんが、それが存在した理由の唯一の記録を削除してしまうと、6ヶ月後に再び同じ議論を繰り返すことになります。
Kilo Codeルールファイルのベストプラクティス
globではなく、パスを明示的にリストします。instructions配列に1ファイルにつき1行記述するのは冗長ですが、順序を制御する唯一の方法です。globは、順序が本当に重要ではないディレクトリに限定して使用してください。
削除するのではなく、コメントアウトします。JSONCのコメントを使用すれば、ルールを一時的に無効化しつつ、その理由をメモとして残すことができます。これは、行を完全に削除してしまうよりもはるかに有益です。
ルートのAGENTS.mdは簡潔に保ちます。無効化できず、常に読み込まれるため、すべての行が永続的なコンテキストコストになります。特定の領域に限定される内容は、ディレクトリごとのファイルに移動してください。
大文字のAGENTS.mdに統一します。Kiloはこれを必須としており、ツールによって大文字・小文字の区別に関する扱いが異なるため、共有リポジトリでは大文字を選択するのが最も確実です。
メモリバンクのステータスインジケータを信用しないでください。Kiloは、これらが「引き続き表示される可能性はありますが、すべてのクライアントやモードで保証されているわけではありません」と述べています。代わりに矛盾検証で確認してください。
依存関係やバージョンのアップグレード後は、矛盾テストを再実行してください。後方互換性のパスは、リリース間で変更されやすい典型的な要素であり、ここでのサイレントな変更はモデルの性能低下のように見えてしまいます。これは、Kiloのフォーク元であるツールについてClineがプロジェクトのコンテキストを忘れる問題で取り上げた多くの誤診の背景にあるものです。移行を計画している場合は、ClineからKilo Codeへの移行でファイルのマッピングをカバーしています。本ガイドは、移行が完了した後にすべきことについて説明しています。
結論
Kilo Codeのinstructions配列は本物のマニフェストであり、マニフェストという考え方は正しいアプローチです。落とし穴は、Kiloの3つの読み込み挙動がその枠外にあることです。レガシーな.kilocode/rules/ディレクトリは自動的に読み込まれ、ディレクトリごとのAGENTS.mdファイルはエージェントがその近くのファイルを読み取ったときに注入され、CLIは他のツールからの互換性ディレクトリを読み込みます。
統合とは、すべてのパスを明示的に指定し、指定しなかったパスを空にし、矛盾テストを行うことを意味します。設定ファイルは、自身が言及していないソースを監査することはできないからです。これを一度行えば、優先順位テーブルは不完全なものではなく、プロジェクトの正確な記述書になります。