整理整頓がルールフォルダの喪失につながる理由
まずは、ガイドラインの目的から始めましょう。JetBrainsはこれを常設の指示書（standing brief）として説明しています。「ガイドラインを使用すると、永続的で再利用可能なコンテキストをエージェントに提供できます。Junie CLIはAGENTS.mdファイルからガイドラインを読み込み、実行するすべてのタスクにこのコンテキストを追加します。」
次に、ドキュメントから引用した検出順序です。「Junie CLIがタスクを開始すると、次の順序でガイドラインを探します。」第1に「プロジェクトルートの.junie/AGENTS.mdファイル」。第2に「プロジェクトルートのAGENTS.mdファイル（存在する場合は、.junie/playbook.mdおよびすべての.junie/rules/*.mdファイルと組み合わされます）」。第3に「.junie/guidelines.mdファイルまたは.junie/guidelines/フォルダ – Junieのレガシーなガイドライン形式（引き続きサポートされています）」。
これら3つの行を文章ではなく表として読むと、非対称性が浮き彫りになります。.junie/playbook.mdおよび.junie/rules/*.mdとの組み合わせは、2番目のルートにのみ記載されています。最初のルートは単一のファイルのみを指定しています。3番目はレガシーな場所を指定しています。ルールフォルダとプレイブックがある場合、それらを読み込むルートは、メインのガイドラインがプロジェクトルートにAGENTS.mdとして存在するルートであり、.junie/内のルートではありません。
これが重要なのは、多くの人がこの状況に陥る経緯があるからです。初回起動時のインポートについてもドキュメントに記載されています。「Junie CLIは、プロジェクトを初めて開くときに、他のAIエージェントからのガイドラインや記憶ファイルがないか確認します。そのようなファイルが検出された場合、指示を.junie/AGENTS.mdにインポートすることを提案します。」この提案は、他に何もないプロジェクトにとっては合理的です。しかし、すでに.junie/rules/フォルダが存在するプロジェクトの場合、ドキュメントでそれらのファイルが組み合わされると説明されていないルートへと、知らず知らずのうちに移行させられてしまうのです。
これによってエラーが発生することはありません。Junieは依然としてガイドラインを持ち、それに従い、優れた成果を上げます。構造上の理由で分割したルールが、単に指示書の一部として扱われなくなっているだけであり、それに気づく唯一の方法は、この優先順位リストを読み解くことだけです。
代わりに試されがちなアプローチ
同じコンテンツを2つの場所に置く。 ルールフォルダの内容を.junie/AGENTS.mdにコピーすることは、内容が伝わるという意味では機能します。しかし、これは将来の編集が2箇所で必要になり、いずれ一方が乖離していくことを意味します。
すべてをレガシーな場所に移動する。 .junie/guidelines.mdや.junie/guidelines/は「Junieのレガシーなガイドライン形式（引き続きサポートされています）」と説明されていますが、サポートされていることと、ドキュメントが推奨するルートであることは別です。これは優先順位の3番目であり、「junie guidelines」と検索して古い資料を見つけた人が偶然たどり着く場所です。
グローバルファイルがギャップを埋めると仮定する。 グローバルファイルには独自の役割があります。「Junie CLIは、~/.junie/AGENTS.mdからのグローバルガイドラインもサポートしています」（Windowsの場合、「グローバルガイドラインのパスは%USERPROFILE%\.junie\AGENTS.md」です）。ドキュメントはその用途を明確に規定しています。「このファイルを使用すると、すべてのプロジェクトに適用される個人の好みや組織全体のルールを、すべてのリポジトリで重複させることなく定義できます。」個人の好みは、プロジェクト固有のルールフォルダの代わりにはなりません。
念のためプロジェクトのルールをグローバルファイルに複製する。 Junieは無害なケースをスマートに処理します。「グローバルガイドラインとプロジェクトガイドラインの内容が同一である場合、Junieは自動的に重複を排除し、コンテンツを1回だけ使用します。」しかし、本当に危険なのは「ほぼ重複している」ケースであり、これらはマージされるのではなく、優先順位によって解決されます。
問題は記憶（memory）であると判断する。 再利用可能なスキルや指示ファイルは「どのように機能すべきか」に答えるものであり、それとプロジェクトの記録とのギャップはまったく別の問題です。これについては、エージェントのスキルが記憶ではない理由で詳しく解説しています。
解決策：ルートを意図的に選択し、プレイブックとルールをドキュメント通りに紐づける
ステップ 1: 3つのルートを棚卸しし、プロジェクトが現在どのルートにあるかを確認する
確認すべきものは4つあります。.junie/AGENTS.md、プロジェクトルートのAGENTS.md、.junie/playbook.md、そしてMarkdownファイルが含まれる.junie/rules/フォルダです。さらに、レガシーなペアである.junie/guidelines.mdまたは.junie/guidelines/フォルダも確認してください。
見つかったものを優先順位リストと照らし合わせます。.junie/AGENTS.mdがある場合、あなたはルート1にいます。ルートにAGENTS.mdがあり、.junie/AGENTS.mdがない場合、あなたはルート2にいます。ドキュメントでは、このルートはプレイブックとすべての.junie/rules/*.mdファイルを「存在する場合」に組み合わせると説明されています。レガシーファイルのみがある場合は、ルート3にいます。
最も注意深く見るべきなのは、これらが複数同時に存在しているケースです。典型的には、初回起動時のインポートによって作成された.junie/AGENTS.md、それ以前から存在する.junie/rules/フォルダ、そしておそらく数ヶ月間誰も開いていないレガシーなguidelines.mdが混在している状態です。これはプロジェクトが壊れているわけではありません。検出順序を再確認するよりも早く、ファイルが蓄積されてしまっただけです。
ステップ 2: メインの指示書を、残りの設定を読み込むルートに配置する
棚卸しさえ済めば、決定は簡単です。
すべてのタスクに適用したい.junie/rules/フォルダや.junie/playbook.mdがある場合は、メインのガイドラインをプロジェクトルートのAGENTS.mdに配置します。これが、ドキュメントでそれらを組み合わせると説明されているルートです。これには特筆すべき副次的なメリットもあります。ルートのAGENTS.mdは、他のエージェントも探すクロスツール対応のファイル名であるため、このフォーマット自体の説明である「コーディングエージェントをガイドするためのオープンなファイルフォーマット」という精神に則り、1つのファイルでJunieとそれ以外のすべてのツールに対応できます。
ルールフォルダもプレイブックもない場合は、.junie/AGENTS.mdで問題なく、ルートをすっきりと保つことができます。ただし、その選択はどこかに記録しておいてください。誰かがルールフォルダを追加した瞬間に、そのルートは設定と一致しなくなるからです。
レガシーファイルを使用している場合は、コンテンツを上記の2つのルートのいずれか適切な方に移動し、ガイドラインの現在の場所を示す短いメモをリポジトリに残しておきます。説明なしに空にされた.junie/guidelines.mdは、次に見た人には誤って削除されたファイルのように見えてしまいます。
ガイドライン自体は、JetBrainsが例示しているカテゴリに沿って記述してください。これらはエージェントが実際に間違えやすい問題に対応しているからです。具体的には、「エージェントが何かを行う前に従わなければならない最も重要なルール」である「クイックスタートチェックリスト」、インストール、lint、テスト、ビルド、開発サーバーの項目をまとめた表としての「ローカル開発コマンド」、「機能開発と意思決定」、「UIとアーキテクチャ」、「セキュリティとデータ処理」、「テストとコントリビューション」、そして「エージェントがやってはならない明示的な禁止事項」と説明されている「エージェントの非目標（Non-goals）」セクションです。この最後のカテゴリは、多くの人が省略して後悔するものです。その目的は明確に述べられています。この情報を提供することで、「Junieが環境をよりよく理解し、互換性のないライブラリを回避し、プロジェクト固有のアーキテクチャパターンに従うのに役立ちます。」
ステップ 3: グローバル層を個人スコープに設定し、あとは優先順位に任せる
次に、グローバルファイルを意図的に配置します。~/.junie/AGENTS.mdには、プロジェクトではなく自分自身に当てはまる内容を記述すべきです。コミットメッセージの表現方法、すべての場所で適用したいレビューの習慣、リポジトリをまたいで適用される組織全体の規約などです。
各層の相互作用については、3つのケースがドキュメント化されており、安心するほどシンプルです。「グローバルガイドラインまたはプロジェクトガイドラインのいずれか一方のみが存在する場合、Junieは利用可能な方を使用します（追加の注釈は追加されません）。」「グローバルとプロジェクトの両方のガイドラインが存在する場合、Junieは両方を含め、明確にマークします。競合する場合、プロジェクトレベルのガイドラインが常にグローバルガイドラインよりも優先されます。」そして「グローバルガイドラインとプロジェクトガイドラインの内容が同一である場合、Junieは自動的に重複を排除し、コンテンツを1回だけ使用します。」
ここから2つの実用的な結論が導き出されます。第1に、防御的な重複は不要です。同一のコンテンツは重複排除され、競合するコンテンツはプロジェクト側が優先されます。第2に、「ほぼ重複している」状態にこそ予期せぬ挙動が潜んでいます。グローバルに「常に統合テストを追加する」、プロジェクトに「機能開発にはユニットテストのみ」とある場合、これらは同一ではないため両方が含まれ、プロジェクト側が勝ちます。これは正しい挙動ですが、意識して探さない限り見えません。2つの層のスコープを明確に分けておくことこそが、優先順位を混乱の元ではなく便利な機能にする鍵です。この規律は、Copilotが指示ファイルを順序付ける方法で説明されているように、階層化された指示ファイルが関与するあらゆる場面で役立ちます。
MemoryLakeでの設定方法
ガイドラインはすべてのタスクに渡される指示書であるため、短く保つ必要があります。つまり、その背景にある「理由」は別の場所に保管しなければなりません。なぜレガシーパッケージが禁止なのか、どのライブラリをどのような理由で却下したのか、命名規則が何を保護しているのか。これらはエージェントが実行ごとに読み込むファイルに含めるべきではありませんが、ガイドラインが依然として有効かどうかを判断する際には不可欠な情報です。MemoryLakeに意図的にエントリーを書き込んでおくことで、指示書を肥大化させることなく、これらの記録を検索可能な状態に保つことができます。エントリーはあなた自身の言葉で書き込みます。.junieディレクトリや他のツールのファイルから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。
ステップ 1: APIキーを作成する
サインインし、ワークスペースの設定からAPIキーを生成します。これはエージェントや統合機能が使用する認証情報であるため、移行を開始する前に作成してください。
ステップ 2: 最初の記憶をアップロードする
ガイドラインが前提としている決定事項から始めましょう。なぜこのスタックなのか、どの手法が不採用になりその理由は何か、「非目標」セクションが実際に何を保護しているのかなどです。それぞれを短い独立したメモとして記述し、個別に取得できるようにします。
ステップ 3: AIとエージェントを接続する
使用しているアシスタントやエージェントを接続します。これにより、特定のツールが指示ファイルを見つけるためにどのルートを使用しているかに関係なく、その背景にある理由が常にあなたに同行します。
実務における変化
初回起動時のインポートが、デフォルトの動作ではなく「選択」になります。他のエージェントのファイルを.junie/AGENTS.mdに統合するというJunieの提案は、新規プロジェクトでは非常に役立ちます。しかし、ルールフォルダがあるプロジェクトでは、立ち止まってどのルートを選択すべきかを確認するタイミングとなります。
ルールフォルダが、単なる整理の習慣ではなく、実際の構造として機能するようになります。ガイダンスを.junie/rules/*.mdに分割することが効果を発揮するのは、それらを組み合わせるとドキュメントに記載されているルートを使用している場合のみです。そうでない場合、分割は機能的ではなく組織的なものにとどまります。これが、WindsurfとDevinのルールフォルダをマージする方法で説明されているように、分散したルールディレクトリのマージを意図的に行うべき理由と同じです。
ツール間での共有に具体的な答えが出ます。ルートのAGENTS.mdを選択することで、Junieが読み込み、他のエージェントも認識する1つのファイルが得られます。これは、Junie専用のファイルと他のツール用のコピーを別々に維持するよりもはるかに優れた状態です。
「エージェントが実際に何に従っているか」の確認作業が短縮されます。ルートが明確になっていれば、答えは調査ではなく、パスと優先順位リストを確認するだけで済みます。これは、どのTabnineガイドラインが有効かで別のツールについて説明した変化と同様です。
見失わないガイドラインのためのベストプラクティス
ガイドライン自体にルートを記述する。上部付近に「ガイドラインはプロジェクトルートのAGENTS.mdにあり、.junie/rules内のルールと組み合わされます」と1行書いておくだけで、次の人が検出順序を再確認する手間を省けます。
グローバルファイルは個人用に留める。もし~/.junie/AGENTS.mdの一行が、他人のリポジトリで見られたら恥ずかしい内容であるなら、それはプロジェクトファイルに記述すべきです。
階層間での「ほぼ重複」を意図的に避ける。同一のコンテンツは重複排除されますが、ほぼ同一のコンテンツは2回含まれ、優先順位によって解決されます。これは、どちらか一方に極振りするよりも挙動の推測が難しくなります。
禁止事項を明文化する。「エージェントの非目標（Non-goals）」カテゴリが存在するのは、エージェントによる最もコストのかかる失敗は「不完全に実行したこと」ではなく、「そもそも行うべきではなかったこと」だからです。
再構成の後は必ず検出順序を再確認する。ファイルを.junie/とプロジェクトルートの間で移動すると、使用しているルートが変化しますが、この変化は通知されません。
手書きではなく自動生成されたガイドラインを再検討する。インポートされたルールや抽出されたルールは、出発点としては有用ですが、最終形としては不十分です。これについては、Qodoから抽出されたルールをエージェントに適用する方法で議論されています。
結論
Junieは3つのルートでガイドラインを探しますが、ドキュメントにおいて.junie/playbook.mdとすべての.junie/rules/*.mdが紐づけられるのは、そのうちの1つ、プロジェクトルートのAGENTS.mdのみです。.junie/内のルートは単一のファイルを指定しており、レガシーなペアは中心的な存在ではなく、あくまでサポートされているに過ぎません。
したがって、配置の決定は非常にシンプルです。プレイブックやルールフォルダを管理している場合は、メインの指示書をルートのAGENTS.mdに配置し、ドキュメントに記載されている組み合わせ機能を活用してください。そうでない場合は、.junie/AGENTS.mdに配置し、その選択を記録しておきます。そして、グローバルファイルを個人スコープに設定し、優先順位の仕組みを信頼し、ガイドラインの背景にある理由は、エージェントがタスクごとに読み込むファイルに収める必要のない別の場所に保管しておきましょう。