実際に移行されるもの
ルールの内容はきれいに移行できます。 Amazon Q のプロジェクトルールは、フロントマターのないプレーンな Markdown です。そのドキュメントには、ルールファイルは「Markdown ファイルである必要がある」と記載されており、本文は単なる文章として示されています。Amp の AGENTS.md もプレーンな Markdown です。リポジトリのルートにある AGENTS.md に .amazonq/rules/*.md の本文を結合するだけで、内容はそのまま保持されます。
ディレクトリの配置は移行されますが、デフォルトの範囲が広がります。 Amp の包含ルールは、2回読み返す価値があります：
「現在の作業ディレクトリ（またはエディタのワークスペースのルート）および親ディレクトリ（$HOMEまで）にあるAGENTS.mdファイルは常に含まれます。」
「サブツリーの AGENTS.md ファイルは、エージェントがそのサブツリー内のファイルを読み取るときに含まれます。」サブツリー側は、あなたが望む挙動です。エリアごとに1つの指示ファイルを用意し、エージェントがそのエリアに触れたときにロードされます。確認が必要なのは、親ディレクトリ側です。もしリポジトリを共通の親ディレクトリの下で管理しており、ホームディレクトリまでのパスのどこかに AGENTS.md が存在する場合、それらすべてのリポジトリでロードされてしまいます。Amazon Q のドキュメントに記載されているルールの場所は {{project-root}}/.amazonq/rules であり、親ディレクトリへの遡上については説明されていません。そのため、この到達範囲の広さは移行後に新しく直面する要素となります。
ファイル名のフォールバックは有利に働きます。 Amp のドキュメントには次のように記載されています。「ディレクトリに AGENTS.md が存在しない場合でも、AGENT.md（末尾の S なし）または CLAUDE.md という名前のファイルが存在すれば、そのファイルが含まれます。」そのため、他のツールからすでに CLAUDE.md を持っているリポジトリは、ディレクトリごとに自動的に検出されます。優先順位（AGENTS.md が最優先、他の2つはフォールバック）に注意してください。これは、一部のエージェントが公開している順序とは逆になっています。
セッションごとのルール選択の移行先はありません。 これが最大の変更点です。Amazon Q での習慣は、「Rules」ボタンを開いて、目の前のタスクに必要なサブセットを選択することでした。Amp には、常にオンのレイヤーと、1つの条件付きメカニズムがあり、その条件付きメカニズムは異なる仕組みで動作します。AGENTS.md からファイルを @ メンションし、そのメンションされたファイルに globs フロントマターフィールドを持たせることができます。Amp のドキュメントには、「globs が指定されたメンションファイルは、Amp がその glob のいずれかに一致するファイルを読み取った場合にのみ含まれる」および「globs が指定されていない場合、ファイルは @ メンションされたときに常に含まれる」とあります。
これは、AGENTS.md でのメンションと、メンション先ファイルでの glob という2段階の間接参照であり、開始前に選択した内容ではなく、エージェントがどのファイルを読み取るかによってトリガーされます。このメカニズムの詳細については、Amp の指示を適用対象のファイルにスコープする で解説していますが、ここでのポイントはより限定的です。Amazon Q のチェックボックスは「このタスク」に関する宣言でした。Amp の glob は「これらのパス」に関する宣言です。この2つは互換性がなく、タスクごとに選択していたルールは、ファイルパスに関するルールとして再表現するか、常にオンとして受け入れる必要があります。
メモリバンクは静的ファイルとして移行されます。 Amazon Q は、.amazonq/rules の下の memory-bank サブフォルダに、product.md、structure.md、tech.md、guidelines.md の4つのファイルからなるメモリバンクを生成できます。そのドキュメントでは、このメカニズムが明確に説明されています。この機能は「プロジェクト内の主要なファイルを分析してサマリーファイルを生成し、質問するたびにプロジェクト全体を分析することなく、Amazon Q がコードベースを理解できるように支援する」ものです。これらを更新するには、Regenerate Memory Bank を選択します。
Amp のドキュメントに記載されている指示サーフェスは、AGENTS.md ファイル、スキル、およびプラグインであり、これらのページには生成や再生成のステップは記載されていません。したがって、これら4つのファイルは手動で維持する通常の Markdown になり、そのうち3つはコードがすでに示している内容を説明するものになります。この違いは非常に重要であるため、逆の視点から Cursor から Amazon Q Developer への移行 というガイドを丸ごと作成しました。要約すると、ツールがリポジトリから再生成できるものは、すでにリポジトリ内に存在していたものです。手動で引き継ぐべきなのは、パーサーでは生成できない決定事項が含まれている可能性がある4番目のファイル guidelines.md です。
コンパクションの挙動は異なり、どちらのバージョンも永続的ではありません。 Amazon Q は、コンテキストウィンドウ内の詳細な会話履歴を置き換えるサマリーである /compact についてドキュメント化しており、覚えておくべき2つの行を付け加えています。「完全な会話履歴は、現在のセッションが終了するまでチャットインターフェースに表示されたままになります」「IDEを再起動すると、詳細なチャット履歴はリセットされます」。Amp のドキュメントでは、コンパクションコマンドではなくスレッドについて説明されています。いずれにせよ、会話は来週必要なものを残しておく場所ではありません。
移植すべきセッションメモリの保存先はありません。 Amazon Q のメモリバンクは生成されたリポジトリのサマリーのセットであり、あなたについて学習した内容の記録ではありません。Amp のドキュメントインデックスでは、カスタマイズサーフェスとして AGENTS.md、スキル、プラグインが挙げられており、セッションごとのメモリ保存先については説明されていません。そのため、どちらの側にも保存先同士の移行は存在しません。これは一見、作業が減るように思えますが、実際には意識的に行わないと、この移行によって知識が失われる原因になります。
手動移行の手順
ステップ 1: ルールを「タスクに関するもの」か「パスに関するもの」かで分類する
Amazon Q の「Rules」ボタンを開き、各ルールファイルについて、実際にチェックを入れているセッションを書き留めます。移行するのはファイルそのものではなく、そのリストです。
すべてのセッションでチェックするルールは、ルートの AGENTS.md に直接記述します。これらは、ハウスルール、ビルドコマンド、レビューチェックリストなど、簡単なものです。
特定のエリアで作業するときにチェックするルールは、サブツリーの AGENTS.md ファイルになります。フロントエンドのルールはフロントエンドのディレクトリに配置します。Amp は「エージェントがサブツリー内のファイルを読み取るとき」にそれをロードするため、これが提供されている機能の中で最もチェックボックスの挙動に近くなります。
ファイルタイプごとにチェックするルールは、globs を持つ @ メンションされたファイルになります。AGENTS.md にメンション行を追加し、メンションされたファイルに globs リストを指定します。ここで、2つの仕様上の詳細に注意する必要があります。Amp のドキュメントによると、「glob は、../ または ./ で始まらない限り、暗黙的に **/ がプレフィックスとして付加され、その場合はメンションされたファイルに対する相対パスを指す」とされています。そのため、単なる *.ts はファイル内だけでなく、あらゆる場所でマッチします。また、「誤検知を避けるため、コードブロック内の @ メンションは無視される」ため、コード例の中に記述されたメンションは機能しません。
「このタスクには厳格なレビューチェックリストを使用する」といった、タスクごとにチェックするルールには、明確な移行先がありません。ルールごとに、常にオンにするか、それとも破棄するかを決定し、破棄したものを記録しておきます。このカテゴリは、ルールファイル自体は存在しているものの単に適用されない状態になるため、移行時にいつの間にか挙動が失われがちな部分です。
その後、検証します。Amp には結果を確認する方法が用意されています。「Amp が使用しているエージェントファイルを確認するには、コマンドパレットから agents-md list を選択します。」リポジトリのルートではなく、実際に作業するディレクトリからこれを実行し、想定していたリスト（特に、存在を知らなかった親ディレクトリのファイル）と一致しているか確認してください。
ステップ 2: メモリバンクとホームディレクトリへの到達への対処
2つのクリーンアップを行います。どちらも、3ヶ月後に行うより今行う方が簡単です。
1つ目は、メモリバンクです。生成された4つのファイルをすべて読み、パーサーがリポジトリから生成できなかったであろうすべての文にマークを付けます。product.md、structure.md、tech.md では、コードのサマリーでありコード自体がそこにあるため、マークされるものはほとんどないはずです。guidelines.md では、Amazon Q がプロジェクトルールを使用して生成を制御できるため、チームが説明ではなく標準を注入するためにそれを使用していることが多く、かなりの量になる可能性があります。パーサーで生成できない文を AGENTS.md に移動し、残りは削除します。再生成されたリポジトリの説明ファイルを3つも常にオンのコンテキストレイヤーに持ち込むと、リクエストごとに対価（トークン）が発生するだけで、エージェントが読み取れない情報は何も提供されません。
2つ目は、作業ディレクトリから $HOME までのパスをたどり、その上にあるすべての AGENTS.md、AGENT.md、CLAUDE.md をリストアップすることです。Amp の親ディレクトリ包含は最上位まで遡り、2つの $HOME/.config の場所（$HOME/.config/amp/AGENTS.md と $HOME/.config/AGENTS.md）は「存在する場合は常に含まれます」。また、プラットフォームに応じて、/etc/ampcode/AGENTS.md、/Library/Application Support/ampcode/AGENTS.md、または %ProgramData%\ampcode\AGENTS.md にあるシステム全体のファイルも同様です。
組織がこれらのシステムファイルのいずれかをデプロイしている場合、実際の指示セットはリポジトリよりも大きくなりますが、リポジトリ内にはそれが記録されません。原因がわからない挙動のデバッグを始める前に、何が存在しているかを把握しておきましょう。この作業の一般的な形式については、AIが実際に何を記憶しているかを監査する で解説しています。
より良い方法：タスクレベルの理由をパスの glob が届かない場所に保管する
タスクごとに選択していたルールは、この移行では持ち運ぶことができないものであり、同時に最も価値のあるルールでもあります。すべてのファイルに適用するルールは通常、規約です。この変更に適用するルールは通常、判断であり、判断には理由があります。
MemoryLake はそれらを保持します。決定事項、それが何に適用されるか、何を除外するか、そしてその理由です。パススコープでもセッションスコープでもないため、コンテキストにおいてのみ意味を持っていたルールが、そのコンテキストを維持し続けます。ここから始めましょう。
ステップ 1: API キーを作成する
リポジトリ用のワークスペースを作成し、API キーを生成します。スコープをリポジトリレベルに維持することで、レイヤーがいずれのツールの設定ディレクトリにも縛られないようにします。
ステップ 2: 最初の記憶をアップロードする
ステップ 1 で配置できなかったタスクレベルのルール（選択的にチェックしていたもの）から始めます。それぞれについて、何に適用されるか、なぜ存在するのかを記録します。次に、パーサーテストをクリアした guidelines.md の内容と、この移行中に行った決定（どのルールを常にオンにし、どれを glob にし、どれを破棄したか）を追加します。
ステップ 3: AI とエージェントを接続する
Amp を接続し、両方を使用している間は Amazon Q も接続したままにします。どちらも同じ決定セットを読み取るため、まだ glob として再表現していないルールであっても、その背後にある理由を利用することができます。
実務における変化
選択的なルールを失うことがなくなります。状況に応じてチェックしていたルールは、常にオンのモデルに移行する際に真っ先に失われる犠牲者です。なぜなら、それらが適用されなくなってもエラーは発生せず、単に誰にも読まれないファイルになるだけだからです。
常にオンのレイヤーを小さく保つことができます。再生成されたリポジトリの説明ファイル3つを含むすべてを結合する代わりに、パーサーで生成できない文だけを保持し、残りは除外します。
デバッグの出発点が得られます。Amp がリポジトリの説明がつかない挙動を示した場合、パス上にある親ディレクトリやシステムファイルのリストを手元に用意し、agents-md list でそれを確認できます。
そして、再説明の手間が減ります。失われたルールによる継続的なコストは、人間がプロンプトでそれを再説明することです。これは AIへのコンテキストの再説明をやめる方法 で説明されているパターンです。常にオン、または glob でトリガーされるルールは再説明の必要がありません。静かに適用されなくなったルールは、永遠に再説明し続ける必要があります。
Amp 導入初月のベストプラクティス
最初の1週間は、3つの異なるディレクトリから agents-md list を実行してください。結果は作業ディレクトリによって変化します。これこそがサブツリーメカニズムの真髄です。
境界がディレクトリである場合は、glob よりもサブツリーファイルを優先してください。可動パーツが少なくなり、暗黙の **/ プレフィックスについて考える必要がなく、そのコードを編集する人が見つけやすい場所にファイルが配置されます。
glob スコープの各ファイルには、1つの役割だけを与えてください。Amp はいずれかの glob が一致したときにメンションされたファイルを含めるため、4つの無関係なパターンをカバーするファイルは、必要以上に4倍多くロードされることになります。
個人の好みを共有パスから排除してください。$HOME/.config/amp/AGENTS.md は、開くすべてのプロジェクトに常に含まれます。これはデバイス固有のコマンドには適した場所ですが、同僚の合意を得ていない意見を置く場所としては不適切です。Amp 自身の表でも、この場所を「個人の好み、デバイス固有のコマンド、およびリポジトリにコミットする前にローカルでテストしているガイダンス」用としてリストしています。
大規模なサブプロジェクトは意図的に分割してください。Amp の推奨事項は、「トップレベルの AGENTS.md は一般的な内容に留め」、各サブプロジェクトのサブツリーに「より具体的な AGENTS.md ファイル」を作成することです。これは、かつて「Rules」ボタンが提供していた機能を最も低コストで再現する方法でもあります。
将来的に再び移行することになった場合、ここで構築したインベントリ（目録）が移行コストを抑える鍵となります。このインベントリがあるからこそ、Amp から Codex への移行 は考古学的な発掘作業ではなく、単なるファイル操作で済むようになり、Claude Code から Amp への移行 も同様にスムーズになります。
結論
Amazon Q はチェックボックスを提供し、あなたにキュレーションを求めます。Amp は作業ディレクトリから $HOME まで到達する包含ルールを提供し、そのパスに何を置くか注意することを求めます。どちらも合理的な設計です。どちらかがもう一方の完全な上位互換というわけではありません。
成功する移行は、ファイルが移動する前、答えがまだ頭の中にあるうちに、どのルールを選択していたのか、そしてその理由を書き留めることから始まります。失敗する移行は、4つのファイルをコピーし、チェックボックスを削除し、6週間後に決済モジュールに関するルールが切り替え以降一度も適用されていなかったことに気づく、というものです。