なぜ規約ファイルは自動で読み込まれないのか
Aider の規約に関するドキュメントには、その仕組みが明快に説明されています。小さな Markdown ファイルを作成し、次のように実行します。
"規約ファイルは/read CONVENTIONS.mdまたはaider --read CONVENTIONS.mdで読み込むのが最善です。これにより、ファイルは読み取り専用としてマークされ、プロンプトキャッシュが有効な場合はキャッシュされます。"
この一文には 2 つの重要な特性が込められており、どちらも意図的なものです。ファイルを読み取り専用にマークすることは、エージェントがそれを編集しようとしないことを意味します。規約ファイルはインプットであり、成果物ではありません。キャッシュすることは、プロンプトキャッシュが利用可能な場合に、毎回のやり取りでトークン費用を繰り返し支払わずに済むことを意味します。
落とし穴は動詞にあります。あなたが「読み込む（load）」のです。Aider のドキュメントに記載されている規約の仕組みは、明示的に読み込むファイルであり、ツールが自動的に探すファイル名ではありません。ファイルがたまたま存在しているからといって、CONVENTIONS.md を自動検出するステップが実行されるわけではないのです。
これは正確に理解しておく価値があります。なぜなら、勘違いしやすく、また「ツールがファイルを見つけたのに無視する」という失敗とは異なるからです。なぜエージェントは指示ファイルを無視するのかではそのケースを扱っていますが、今回のケースはより単純です。無視する以前に、何も読み込まれていないのですから。
Aider はあなたのコードベースに無関心なわけではありません。リクエストのたびに、リポジトリマップを自動的に構築して送信します。
"Aider は、最も重要なクラスや関数、およびそれらの型やコールシグネチャを含む、Git リポジトリ全体の簡潔なマップを使用します。"
"Aider は、ユーザーからの各変更リクエストとともに、リポジトリマップを LLM に送信します。"
そのため、モデルはコード構造の正確な全体像を把握した状態で処理を開始します。しかし、そこにあなたの「規約」は含まれていません。その理由は、見落としではなく構造的なものです。リポジトリマップはコードから生成されます。モジュールが存在することや、そのコールシグネチャを示すことはできますが、8ヶ月前に代替ライブラリを不採用にしたという事実は示せません。不採用になったライブラリは、マップされるリポジトリ内には存在しないからです。この違いこそが、規約ファイルが存在する最大の理由です。
ドキュメントには、その効果を具体的に示す比較例が掲載されています。規約ファイルを読み込んだ場合、生成された関数は推奨される HTTP クライアントを使用し、型ヒントを含んでいました。一方、読み込まなかった場合、同じリクエストでも別のライブラリを使用し、型のないコードが生成されました。ドキュメントではこれを「小さな Python スクリプトではより一般的かもしれない」と表現しています。同じモデル、同じプロンプトであっても、たった 1 つのファイルの有無で結果が完全に変わるのです。
代わりに試されがちなアプローチ
すべてのセッションの開始時に /read CONVENTIONS.md と入力する。 これは機能しますし、最初のステップとしては正しいアプローチです。しかし、これは習慣に依存します。急いでいる日ほど習慣は抜け落ちがちであり、まさにそういう日に規約違反のコードがマージされてしまうものです。
プロンプトに規約を貼り付ける。 1 回のやり取り（ターン）なら機能します。しかし、読み取り専用ではないためエージェントによって編集される可能性があり、キャッシュもされないため、毎回トークン費用を支払うことになります。さらに、来週には貼り付ける内容が変わってしまっているかもしれません。
/read ではなく /add で規約ファイルを追加する。 見た目以上に厄介な問題を引き起こします。/add はファイルを編集可能な状態でチャットに追加します。ドキュメントでは読み取り専用パス（/read）を使うよう明確に推奨されており、これに関連して心に留めておくべきヒントがあります。それは「起動時に追加された読み取り専用ファイルを /drop しないこと」です。エージェントが編集できる規約ファイルは、遅かれ早かれ編集されてしまう運命にあります。
メインのソースファイルの先頭にコメントブロックとして規約を記述する。 これでは、ルールが適用対象のコードの内部に閉じ込められてしまいます。そのファイルを持ち運ぶときしか機能せず、リポジトリマップはそのコメントを喜んで取り込みますが、他の 12 個のモジュールにはその規約が一切伝わりません。
すべてを規約ファイルに詰め込む。 これは逆の失敗であり、数ヶ月運用した後に非常によく見られるケースです。すべてのアーキテクチャ決定、すべてのインシデントの振り返り、すべての不採用オプションを保持するまでに肥大化した規約ファイルは、毎セッション丸ごと読み込まれます。読み取り専用でキャッシュされるためコストは抑えられますが、リクエストのほんの一部にしか適用されない情報のために、常に大量の固定コンテキストを消費することになります。
解決策：ファイルを自動で読み込ませ、サイズを小さく保つ
ステップは 3 つあります。最初のステップは 2 行の変更で済み、残りの 2 つは、この作業を二度と繰り返さなくて済むようにするためのものです。
ステップ 1: プロジェクトの構成ファイルに read を追加する
Aider のドキュメントには、これを自動化する方法が記載されています。
"また、.aider.conf.yml 構成ファイルで、常に規約ファイルを読み込むように Aider を設定することもできます。"設定するフィールドは read で、単一のファイル名またはそのリストを指定できます。規約ファイルが 1 つだけなら 1 つのエントリ、規約ファイルに加えて常に利用可能にしたいスキーマ参照などがある場合はリストを指定します。
構成ファイルをどこに置くかが重要です。Aider は以下の 3 つの場所を検索するからです。
"Aider は、ホームディレクトリ、Git リポジトリのルート、カレントディレクトリの順にこのファイルを検索します。上記のファイルが存在する場合、その順序で読み込まれ、最後に読み込まれたファイルが優先されます。"
read エントリーは、ホームディレクトリではなく、Git リポジトリのルートにある構成ファイルに追加してください。理由は 2 つあります。第一に、プロジェクトと一緒に移動する唯一の場所であるため、チームメンバーや CI も特別な設定なしで同じ挙動を得られます。第二に、ホームディレクトリの構成ファイルに read を記述すると、開くすべてのリポジトリにそのファイルが存在するとは限らないため、プロジェクト固有のファイルをグローバル設定で参照することになり、次にリポジトリをクローンしたときにエラーを引き起こす罠になります。
最後に読み込まれたファイルが優先されるため、リポジトリルートの構成ファイルはグローバル設定をきれいに上書きします。通常、これが望ましい挙動です。
ステップ 2: ファイルに含めるべきものを決め、それ以外を移動する
ファイルがすべてのセッションで無条件に読み込まれるようになったため、そのサイズは恒常的なコストになります。これにより、ファイルに何を含めるべきかが変わってきます。
すべてのリクエストに共通して適用され、ルールとして簡潔に記述できるものだけを残します。優先すべきライブラリ、型ヒントの要件、命名規則、テストコマンドなどです。これらは指示（コマンド）であり、規約ファイルは指示を格納するのに適した場所です。
歴史的な経緯はすべて別の場所に移動します。そのライブラリを選択するに至ったインシデントを説明する段落は貴重であり、ルールがレビューを通過し続ける理由でもありますが、毎回のやり取りでプロンプトに含める必要はありません。データモデルの長い説明、リリースチェックリスト、3 つのモジュールがなぜ奇妙な構造になっているのかに関するメモなども同様です。
基準はシンプルです。その一文が「何をすべきか」に答えているなら、規約ファイルに含めます。「なぜか」に答えているなら、エージェントが必要に応じて検索できる場所に置きます。コーディングエージェントが実際に読んでいるものは、ここで役立つ参考資料になります。なぜなら、常に読み込まれる指示ファイルを持つすべてのツールに、同じ切り分けが適用されるからです。
Aider のドキュメントが指し示すコミュニティの規約から得られるアドバイスも、同じ精神に基づいています。すなわち、好みに関する短く具体的な記述です。
ステップ 3: 「なぜ」をエージェントが照会できる場所に置く
これは、規約ファイルが再び肥大化するのを防ぐためのステップです。理由が記録されていないルールは、誰も削除できず、誰も擁護できないため、ファイルは長くなる一方です。
その理由は、常に読み込まれるのではなく、必要に応じて検索可能である必要があり、また、次のツールに移行しても維持される必要があります。Aider は独自の仕組みを持つターミナルネイティブなツールですが、多くのチームはそれを IDE アシスタントと併用しています。もし理由が Aider だけが読み込む CONVENTIONS.md に書かれているなら、ツールチェーンのもう半分はそれを決して目にすることはありません。そして、来年あなたが別のツールを使っているときにも、それは見えなくなります。プロジェクトドキュメントを AI の記憶に変換するでは、既存のドキュメントをゼロから書き直すことなく、そのような形に変換する方法を解説しています。
MemoryLake でのセットアップ
MemoryLake は、特定のツールに依存せずに規約の背景にある理由を保持し、MCP や API を介して、要求したエージェントに提供します。CONVENTIONS.md はそのままの場所に残り、Aider はドキュメントに記載されている通りにそれを読み込み続けます。共有レイヤーは、規約ファイルを肥大化させる原因となる情報のみを保持します。
ステップ 1: API キーを作成する
キーを生成し、約 30 秒で最初のリクエストを実行できます。ファイルを整理する際に各理由を保存する場所を確保するため、上記のステップ 2 の前にこれを行ってください。
ステップ 2: 最初の記憶をアップロードする
規約ファイルを 1 行ずつ確認していきます。各ルールについて、それが存在する理由（不採用にした代替案、背景にあるインシデント、それを強制した制約など）を書き留めます。それらの段落を規約ファイルから取り出し、ここに保存します。サポートドキュメントやファイルも同じ場所に保存します。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに MCP または API 経由でアクセスを許可します。誰かが規約の理由を尋ねたとき、単にルールを繰り返すのではなく、その理由が添付された回答が返されます。
実践における変化
最初の変化は、月曜朝の失敗がなくなることです。リポジトリを持つすべてのマシンのすべてのセッションで、誰かが意識することなく、最初のメッセージの前に規約ファイルが自動的に読み込まれます。
第二に、読み取り専用とキャッシュが、正しく入力しなければならないものではなく、デフォルトになります。どちらの特性もドキュメントに記載されている read パスから得られるものであり、ファイルが毎回読み込まれるようになると、その重要性はさらに増します。
第三の変化は、規約ファイルが肥大化する代わりに、より小さくできることです。根拠を検索可能なストアに移動したルールは、すべて 1 行で記述できます。常に読み込まれる短いファイルと検索可能な理由ストアの組み合わせは、常に読み込まれる長いファイルよりも明らかに優れており、保持される情報の総量は同じです。
第四の変化は、チームの誰かが Aider を使っていない場合に現れます。ルールはリポジトリに残り、Aider はそれを読み込みます。理由はすべてのエージェントがアクセスできる場所にあります。どちらの情報も、特定のツールのフォーマットに閉じ込められることはありません。
Aider における規約のベストプラクティス
add ではなく read を使用する。 インプットファイルに対しては読み取り専用が正しい姿勢であり、ドキュメントでも推奨されています。これにより、エージェントがルールを勝手に書き換えるのを防ぐこともできます。
構成ファイルは Git のルートに置く。 プロジェクトと一緒に移動し、最後に読み込まれたファイルが優先されるため、ホームディレクトリの構成ファイルよりも優先されます。
常に有効にしたいインプットが複数ある場合はリストを使用する。 read フィールドはリストを受け入れるため、規約ファイルとスキーマ参照をマージして巨大なファイルにする必要はなく、それぞれを個別のエントリとして指定できます。
起動時に追加された読み取り専用ファイルを /drop しない。 Aider のヒントでも直接指摘されていますが、長いセッションの途中でチャットからファイルを整理する際についやってしまいがちなミスです。
指示（コマンド）はファイルに残し、理由（理由）は除外する。 ファイルはすべてのリクエストで読み込まれます。「なぜ」に答える内容は、誰も尋ねていないやり取りでもトークン費用を支払うことになります。
リポジトリマップが規約を伝えてくれると期待しない。 リポジトリマップはコードから構築され、すべてのリクエストで送信されるため非常に便利ですが、リポジトリに含まれているものしか反映できません。不採用になったライブラリはマップに痕跡を残しません。
規約ファイルを Git にコミットする。 当然のことですが、あえて言う価値があります。1 台のノート PC にしか存在しない規約ファイルは、チームのルールを装った個人の好みにすぎません。
他のすべてのツールでも同じことを行う必要があると想定する。 仕組みは異なります。エージェントにコーディングスタイルを守らせる方法では別のツールの方法を解説しており、自律型コーディングエージェントのための最適な記憶ソリューションではそれらすべての基盤となるレイヤーを扱っています。
結論
Aider の規約の仕組みは、慣例的に検出されるファイル名ではなく、明示的に読み込まれる読み取り専用ファイルです。このたった一つの違いこそが、テスト時には機能していたファイルが日常業務で機能しなくなる理由です。解決策はドキュメントに記載されている通りシンプルです。Git リポジトリのルートにある .aider.conf.yml に read エントリを追加するだけで、リポジトリを持つすべての人が、毎セッション自動的に読み取り専用かつキャッシュされた状態でファイルを読み込めるようになります。
判断が必要なのは、そこに何を含めるかです。ファイルが無条件に読み込まれるようになったため、すべての行が恒常的なコストになります。これは、ファイルを恒久的な指示のみに留め、理由はエージェントが必要に応じて照会できる場所に移動させるための、良い意味での制約となります。Aider のリポジトリマップは、コードに何が含まれているかをモデルに伝え続けます。しかし、コードに意図的に含めていないものを伝えられるのは、あなただけです。