手書きのAmazon Qルールを自動生成されるMemory Bankから隔離する方法（2026年版ガイド）

Amazon Qのプロジェクトルールは、プロジェクトの .amazonq/rules フォルダ内にあるMarkdownファイルです。ドキュメントにはその目的が明確に記載されています。ルールは「チーム全体のコーディング標準とベストプラクティスを記述」するものであり、プロジェクト内に保存することで「経験レベルに関係なく、開発者間の一貫性を確保」できます。

Memory Bankは、これとは別の目的を持つ独立した機能です。Amazon Qは、主要なファイルを分析することで「プロジェクトの構造、技術スタック、製品情報のクイックインデックスを提供するMemory Bankファイルを自動的に生成」し、「質問するたびにプロジェクト全体を分析することなく」コードベースを理解できるようにします。

これら2つの機能は、同じ場所を共有しています。生成を実行すると、「Amazon Qは .amazonq/rules の下に memory-bank サブフォルダを作成」し、4つのファイルを格納します。プロジェクトの概要と機能を示す product.md、アーキテクチャとフォルダ構成を示す structure.md、技術スタックと依存関係を示す tech.md、および開発標準とパターンを示す guidelines.md です。

この最後のファイル名が、興味深い問題を引き起こします。guidelines.md は「プロジェクトの開発標準とパターン」を記述する自動生成コンテンツです。これは、まさに手書きのルールが果たしていた役割そのものです。現在、両者は同じツリー内に存在し、どちらも「Amazon Qとチャットする際にコンテキストとして自動的に使用」されます。

これは不具合ではありません。手動で作成されたコンテンツと、自動生成されたコンテンツが同じ名前空間を占有する設計になっており、その設計の代償として、最も重要となる瞬間に「誰が書いたのか」が見えなくなってしまうのです。これは、どのdiffツールでも表示されない、競合する指示レイヤーの問題と同類の課題ですが、ここではそのレイヤーの1つが自ら書き換わってしまうという点が異なります。

Memory Bankがルールを置き換えると思い込む。 そうではありません。両方がコンテキストとして使用されます。Memory Bankを生成するとファイルが追加されますが、作成したルールが不要になるわけではありません。

「Regenerate」は生成されたファイルのみを変更すると思い込む。 これは、鵜呑みにするのではなく検証すべき仮定です。ドキュメント化されているアクションは「Regenerate Memory Bank」であり、再生成されるのはMemory Bankファイルです。仮定するのではなく検証すべき理由は、境界線が自分自身も書き込みを行うフォルダ内のサブフォルダであり、ファイルが自分のものであることを示す唯一の目印が「どこに置いたか」だけだからです。

名前が合っているからという理由で、チーム標準を guidelines.md に記述する。 名前は適切に見えますが、このファイルは自動生成されます。そこに書かれたものはすべて、再生成のプロセスで上書きされる運命にあります。

安全のためにMemory Bankをオフにする。 これは、整理整頓の問題を解決するために、本質的なメリットを犠牲にしています。インデックスが存在するのは、Amazon Qが質問のたびにプロジェクト全体を再読み込みするのを防ぐためであり、これには十分な価値があります。

パネルでファイルをオフにして解決したことにする。 「Rules」ボタンには利用可能なルールがリストされ、クリックして現在のチャットセッションでの有効/無効を切り替えることができます。チェックマークが付いているファイルは「アクティブであり、会話に適用されます」。チェックマークがないファイルは「現在のセッションでは非アクティブ」になります。これはセッションごとのスイッチであり、ファイルの整理方法の決定ではなく、フォルダ内の内容を変更するものではありません。

パネルが「誰が何を書いたか」を示してくれると期待する。 パネルに表示されるのは名前とチェックマークだけです。生成されたファイルはMemory Bankサブフォルダの下に配置されるため、パスだけが唯一のシグナルとなります。

この仕組みが提供する境界線は1つだけです。それは memory-bank サブフォルダです。それ以外はすべて、あなたが課す規律（コンベンション）であり、規律は誰かがチェックしなければ維持されません。

ステップ 1: ファイル名から作成者が判別できるように、手書きのルールファイルに名前を付ける

.amazonq/rules を確認し、チームが作成したファイルの名前を変更して、ファイル名自体が作成者を示すようにします。プレフィックスを使用するのが効果的です。例えば、team-api-conventions.md、team-testing-policy.md、team-security-baseline.md などです。具体的な命名規則の内容よりも、それが1単語であり、例外なく適用されていることの方が重要です。

目的は装飾ではありません。同じツリーに4つの自動生成ファイルが表示されたとき、「これは自分たちのものか」という疑問に、フォルダがセットアップされたときにその場にいなかった人でも、ファイル一覧を見るだけで答えられる必要があります。プレフィックスがあれば解決しますが、単に「考え抜かれたファイル名」にするだけでは解決しません。なぜなら、自動生成されたファイル名も同様に考え抜かれているからです。

その作業を行う際、自動生成ファイルに含めるべき内容を手書きのファイルから移動させておきます。もし手書きのルールがフォルダ構成を説明しているなら、それは structure.md の役割です。重複して記述すると、二重管理になり、最終的に矛盾が生じる原因になります。

ステップ 2: ジェネレーターの出力を制御するルールを1つ作成する

これは多くのチームが見落としがちですが、ドキュメントに記載されています。「カスタムプロジェクトルールを作成することで、Memory Bankファイルの生成方法をカスタマイズ」できます。ドキュメントの例では、生成されるファイルの言語やフォーマットを指定するルールが挙げられています。

つまり、ジェネレーターは制御可能であり、その制御ルールは他のすべてのファイルと同じフォルダに配置されます。プレフィックスを付けた team-memory-bank-policy.md というファイルを1つ作成し、生成されるファイルに含めるべき内容と含めるべきでない内容を記述します。特に価値のある指示は次の2点です。生成されるファイルは規範的（prescriptive）ではなく記述的（descriptive）に保つこと、そしてプレフィックス付きのファイルにすでに存在するチーム標準を再記述しないことです。

この2番目の指示が「隔離壁（フェンス）」となります。これはファイルシステムレベルで何かを強制するものではありません。ジェネレーターに対して、特定のコンテンツはすでに別の場所で管理されていることを伝えるものであり、この設計においてそれを表現できる唯一の場所です。

ステップ 3: コミット、再生成、そしてdiffの確認

まず、名前を変更したファイルとポリシーのルールをコミットし、クリーンなベースラインを作成します。次に、Rulesボタンから「Regenerate Memory Bank」を実行し、変更を受け入れる前に結果のdiff（差分）を確認します。

チェックするポイントは3つです。プレフィックス付きのファイルが変更されていないこと。4つのMemory Bankファイルが memory-bank サブフォルダ内でのみ変更されていること。そして、ポリシーのルールで除外するように指示したチーム標準のバージョンが、guidelines.md に再び生成されていないことです。

比較対象となるコミットを用意してこれを一度意図的に実行すれば、仮定ではなく実際の観察によって境界線を理解できます。大規模なリファクタリングの後には、再度これを実行してください。なぜなら、そのときこそジェネレーターが最も多くの新しい材料を持ち、内容を再記述する可能性が最も高くなるからです。

ベースラインのコミットはいつでも参照できるようにしておいてください。生成されたファイルは再生成されることを前提としています。再生成によって何が変更されたかを確認できることこそが、その安全性を担保します。

ステップ1で作成したプレフィックス付きのファイルは、このプロセスの「永続的な半分」です。これは、ジェネレーターが生成したものではなく、再生成によって変更されるべきではない、チーム自身の言葉で合意された決定事項です。MemoryLake は、特定のツールのフォルダ内にあるという理由だけで定義されるのではなく、その重要な半分を安全に保管するための場所です。

エントリーはあなた自身の言葉で記述します。.amazonq/rules、Amazon QのMemory Bank、またはその他のベンダーのストレージから読み取られたり、書き込まれたり、削除されたりすることはありません。

ステップ 1: APIキーの作成

サインインし、ダッシュボードからキーを生成します。このキーを使用することで、使用しているエディタやリポジトリに関係なく、エージェントが作成したエントリーを読み取ることができるようになります。

ステップ 2: 最初のメモリのアップロード

プレフィックス付きのファイルから合意事項を追加します。1つの決定につき1つのエントリーを作成し、その理由を添えてください。理由は、ルールが書き換えられても生き残る部分です。なぜなら、そのルールが現在も適用されるかどうかを次の人に伝えるものだからです。

ステップ 3: AIとエージェントの接続

エージェントの参照先をワークスペースに設定します。これにより、チームの決定事項は .amazonq フォルダが一切存在しないツールでも利用可能になり、単なるAmazon Qの設定ではなく、真の「チームの合意事項」となります。

最初の変化は、ファイル一覧を見るだけで作成者の疑問が解決することです。プレフィックスを導入する前は、「これは自分たちが書いたものか」を判断するためにフォルダの履歴を知る必要がありました。導入後は、一覧がそのまま答えになり、新しいチームメンバーでも一目で正しく理解できます。

2つ目の変化は、ジェネレーターが「予期せぬ挙動をするもの」から「設定可能なもの」に変わることです。ポリシーのルールは小さなファイルですが、絶大な効果を発揮します。なぜなら、生成されるファイルの目的を定義するためのドキュメント化された方法だからです。これが存在することで、Memory Bankが標準ルールを勝手に再記述し始めるのを防ぐことができます。

3つ目の変化は、再生成が日常的な作業になることです。多くのチームは、再生成が何に影響を与えるか分からないため、実行を避けています。ベースラインのコミットとプレフィックスのルールがあれば、diffによって数秒で答えが得られます。リファクタリング後に更新されるMemory Bankは、一度生成されたまま放置されて古くなったものよりも、はるかに価値があります。

また、セッションごとの切り替えトグルの役割も明確になります。ルールをオフにすることは、プロジェクト全体ではなく「この会話」に関する決定であり、セッションが終了すれば消えてしまいます。パネルがプロジェクトのポリシーを表現していると期待するチームは、結果として「1回のチャットの間だけ有効なポリシー」を運用することになります。この違いは明確にしておく価値があり、どのガイドラインが実際に有効であるかを知ることは、ガイドラインを書くこととは別の作業である理由でもあります。

他のツールでMemory Bankパターンを使用したことがある場合、ファイルの整理に関する問題は同じです。Clineは独自のディレクトリにバンクを保持するため、そこでのセットアップは主に各ファイルに何を含めるかに関するものであり、誰がフォルダを所有しているかという問題ではありません。そして、単一のバンクでは対応できなくなったときに人々が比較する代替案も、まさにこの点で異なっています。

1つのプレフィックスを使用し、例外は一切作らない。 この規律の価値は、プレフィックスのないファイルは定義上「自分たちのものではない」と言える点にあります。1つでも例外を作ると、その前提が崩れてしまいます。

ポリシーのルールは短く保ち、内容ではなく形式に焦点を当てる。 生成されるファイルにどのような情報が含まれるべきかを記述します。ポリシー自体に標準ルールを書き込み始めると、標準ルールがジェネレーターの入力に混入してしまいます。

常にコミットに対して再生成を行う。 diffこそが唯一の観察手段です。ベースラインがなければ、それを確認することはできません。

生成されたファイルには「記述（describe）」させ、手書きのファイルには「規定（prescribe）」させる。 「APIレイヤーは src/api にある」と記述された自動生成ファイルは有用であり、簡単に更新できます。しかし、「すべてのエンドポイントは入力を検証しなければならない」と記述された自動生成ファイルは、誰もその文言で合意していない標準になってしまいます。

すべての手書きルールに理由を書き添える。 理由のないルールは後から評価できないため、永遠に盲従されるか、不満から削除されるかのどちらかになります。これは、無視されるルールは、通常、誰も正当化できないルールであるのと同じ理由です。

このフォルダが他のプラットフォームにも引き継がれることを忘れない。 同じ .amazonq/rules フォルダは、GitLabやGitHubのAmazon Qで使用されるプロジェクトルールのドキュメント化された場所でもあり、そこではルールが「自動的に」プロジェクトのコンテキストになります。コミットした内容が、そこで実行されることになります。

誰かが離職したときはフォルダを見直す。 手書きのルールは個人の判断の産物です。その人がいなくなったとき、ルールには新しい所有者が必要になるか、削除されるべきです。これは、ツールが記憶している内容の監査が、それが「考古学的な遺物」になる前に明らかにするような事柄です。

Amazon QのMemory Bankは便利な機能ですが、配置場所が不適切です。チームの合意事項を保持するフォルダに4つのファイルを書き込み、そのうちの1つは合意事項と同じ役割を果たす名前が付けられており、両者を管理するパネルはそれらを区別なく扱います。

解決策は、この機能を避けることではありません。ファイル名から作成者を判別できるようにし、ドキュメント化された方法でジェネレーターにファイルの目的を伝え、コミットに対して一度再生成を行うことで、仮定ではなく実際の観察によって境界線を把握することです。

そして、合意事項自体は、特定のツールの設定フォルダよりも広い場所に保管してください。ルールは、特定のエディタで決定事項を強制するための手段にすぎません。本当に保持する価値があるのは「決定事項」そのものであり、それはフォルダよりも長生きします。だからこそ、ツール間を移行するチームは、ルールを移行するのは簡単だが、その背後にある理由を移行することこそが本当の仕事であることに気づくのです。