MemoryLake
すべての記事に戻る
Tutorial2026年9月3日·10 分で読了

Ampの指示を適用対象のファイルのみにスコープ制限する方法(2026年ガイド)

ほとんどのコーディングエージェントでは、指示ファイルの設定は「オン」か「オン」の2つしかありません。セッションごとに毎回ロードされ、Reactコンポーネントを編集しているときも、データベースのマイグレーションを編集しているときも同じトークンコストがかかります。コストを抑える唯一の方法は、必要になるかもしれない何かを削除することだけです。

Ampには第3の選択肢がありますが、これを使っている人はほとんどいません。AGENTS.mdから参照するファイルのフロントマターにglobsフィールドを持たせることができ、エージェントが実際にそのパターンに一致するファイルを読み込んだ後にのみ、そのファイルがロードされます。TypeScriptの規約はTypeScriptが使われているときにのみ適用され、マイグレーションのルールは誰かがマイグレーションに触れるまで邪魔になりません。

この仕組みはドキュメント化されており、わずか数行のYAMLで記述できます。そして、指示ファイルの存在意義そのものを変えてしまいます。このガイドでは、Ampが何をインクルードするかを決定する方法、条件付きガイダンスの設定方法、およびその境界線がどこにあるのかを解説します。

まず、1つ境界線を引いておきましょう。これは、エージェントが書かれた指示を無視するという一般的な問題(あらゆるツールで発生し、why agents ignore your instruction filesで解説されています)についてではありません。今回はその逆の状況です。Ampはファイルを確実に読み込みますが、問題は「常にすべてのファイルを読み込ませないようにするにはどうすればよいか」ということです。

なぜAmpは要求以上のものをロードするのか

3つのインクルードルール、うち2つは無条件

Ampの検出プロセスは正確であり、一度理解すれば挙動を予測するのは簡単です:

"現在の作業ディレクトリ(またはエディタのワークスペースのルート)および親ディレクトリ($HOMEまで)にあるAGENTS.mdファイルは、常にインクルードされます。"
"サブツリーのAGENTS.mdファイルは、エージェントがそのサブツリー内のファイルを読み込んだときにインクルードされます。"
"システム全体のガイダンスファイル、および$HOME/.config/amp/AGENTS.md$HOME/.config/AGENTS.mdの両方は、存在する場合、常にインクルードされます。"

つまり、3つのうち2つは「常に」です。サブツリーのルールのみが条件付きであり、これは設定によるものではなく、エージェントがそのサブツリー内のファイルを読み込んだときにトリガーされます。

これは、ガイダンスを追加するデフォルトの方法(ルートのAGENTS.mdに記述する)が、最もコストのかかる方法でもあることを意味します。リポジトリ内のすべてのタスクで常にメモリ上に常駐することになります。

個人用ファイルとシステム用ファイルがその上に重なる

ロケーションテーブルには、Ampが探索するいくつかの場所がリストされています。リポジトリファイル、「コミット前にローカルでテストしている個人設定、デバイス固有のコマンド、およびガイダンス」用の$HOME/.config/amp/AGENTS.mdおよび$HOME/.config/AGENTS.md、そして「すべてのAmpセッションに対するシステム全体または組織管理のガイダンス」用の/etc/ampcode/AGENTS.md/Library/Application Support/ampcode/AGENTS.md、または%ProgramData%\ampcode\AGENTS.mdです。

これらはすべて、存在する場合は常にインクルードされます。組織管理のファイルが設定され、個人用のファイルがあり、さらにリポジトリにルートファイルがあるマシンでは、エージェントがコードを見る前にすでに3つのファイルが常駐していることになります。

意図しないフォールバック

"ディレクトリにAGENTS.mdが存在しない場合でも、AGENT.md(末尾のSなし)またはCLAUDE.mdという名前のファイルが存在すれば、そのファイルがインクルードされます。"

これは便利です。他のツール用にセットアップされたリポジトリが、変更なしでAmpでも動作することを意味します。しかし同時に、忘れていた古いCLAUDE.mdが有効なガイダンスとして機能してしまったり、指示を削除したつもりのディレクトリにまだ指示が残っていたりする可能性もあります。古い規約がなぜか適用され続ける原因を探す前に、知っておく価値のある仕様です。

Amp自体も分割を推奨している

ドキュメントでは、1つの巨大なルートファイルを想定された設計とはしていません:

"複数のサブプロジェクトを持つ大規模なリポジトリでは、トップレベルのAGENTS.mdは一般的な内容にとどめ、各サブプロジェクトのサブツリーに、より具体的なAGENTS.mdファイルを作成することをお勧めします。"

これが解決策の前半です。後半はglobsメカニズムであり、サブツリーでは対応できないケース、つまりディレクトリではなく「ファイルタイプ」に適用されるガイダンスを処理します。

よく試されるアプローチ

すべてをルートのAGENTS.mdに記述する。 デフォルトの方法であり、ファイルが大きくなりすぎてエージェントがすべての指示を確実に追いきれなくなるまでは機能します。すべてのタスクにおいて、あらゆる規約が他のすべての規約と注意力を奪い合うことになります。

コンテキストを節約するためにガイダンスを削除する。 効果的ですが、情報が失われます。削除したルールは、かつて誰かが間違えたからこそ存在していたはずです。

すべてに対してサブツリーファイルを作成する。 ガイダンスがディレクトリ構造に依存している場合は非常に有効であり、だからこそAmpも推奨しています。しかし、ファイルがどこにあっても適用される「any型は絶対に使用しない」といったルールに対しては効果がありません。

文章で条件を書いて、うまくいくことを祈る。 常駐ファイルに「APIエンドポイントを作業するときは、以下のルールに従ってください」と追記する方法です。テキストのコストは変わらず、パターンとして表現できたはずのフィルタリングをモデルの判断に依存することになります。

フロントマターなしでファイルを@メンションする。 惜しいアプローチです。Ampは他のファイルを取り込むための@メンションをサポートしていますが、ドキュメントにはデフォルトの挙動が明記されています。「globsが指定されていない場合、ファイルは@メンションされたときに常にインクルードされます。」したがって、メンションするだけではファイルを整理することはできても、ロードされる量を減らすことはできません。

1つの長いスレッドですべてを行う。 関連する問題であり、同じ症状を引き起こします。Amp自身の推奨事項は次のとおりです。「タスクごとに1つのスレッドを使用してください。スレッドは長く続けることができますが、無関係な作業が混在するスレッドは、エージェントの推論コンテキストを悪化させます。」スレッドが長くなった場合のドキュメントに記載されている対処法は、ハンドオフです。「エージェントに『Handoff and ...(ハンドオフして...)』と依頼すると、重要なコンテキストを引き継いで新しいスレッドを開始します。」

解決策:AGENTS.mdからファイルを参照し、Globsで制限する

ステップ1:トリガーごとにルートファイルを分割する

ルートのAGENTS.mdを読み、すべてのブロックを3つのグループに分類します。

ユニバーサル(共通)。 ビルドおよびテストコマンド、リポジトリのレイアウト、レビューおよびリリースの手順など、どこでも適用される規約です。これはルートファイルに残します。Ampのロケーションテーブルでも、ルートファイルにはまさにこの内容(「アーキテクチャ、ビルド/テストコマンド、内部APIの概要、レビューおよびリリースの手順」)を記述することが説明されています。

ディレクトリ依存。 特定のサブプロジェクト内でのみ重要なガイダンスです。これはそのサブツリーのAGENTS.mdになり、エージェントがその中のファイルを読み込んだときにAmpによってインクルードされます。

ファイルタイプ依存。 言語の規約、テストパターン、フレームワークのルールなどです。これこそがglobの出番であり、成熟したリポジトリでは通常、これが最大のグループになります。

ステップ2:glob制限付きファイルを連携する

ドキュメントに記載されている通り、3つの手順で行います。

まず、AGENTS.mdにメンションを追加します。ファイル内のどこに記述してもかまいません(例:See @docs/*.md)。メンション自体でglobパターンがサポートされているため、1行で規約ファイルのディレクトリ全体を指定できます。

次に、参照される各ファイルを、YAMLフロントマターにglobsリストを含めて作成します。ドキュメントの例では、docs/typescript-conventions.mdを作成し、globs'**/*.ts''**/*.tsx'を指定したフロントマターブロックで開始し、その後に規約(例:「any型は絶対に使用しない」)を記述しています。

3つ目に、言語や関心事ごとにこれを繰り返します。ドキュメントには、コピーして使える3つのパターンが示されています。フロントエンドのガイダンス用のglobs: ["src/components/**", "**/*.tsx"]、バックエンド用のglobs: ["server/**", "api/**"]、そしてテストのガイダンス用のglobs: ["*.test.ts", "__tests__/*"]です。

得られる挙動は明快です。「globsが指定されたメンション先ファイルは、Ampがそのglobのいずれかに一致するファイルを読み込んだ場合にのみインクルードされます。」トリガーは、あなたがファイルを開いたことではなく、Ampが一致するファイルを読み込んだことである点に注意してください。

混乱を避けるための2つの重要な詳細があります。メンションのパス解決は、作業ディレクトリではなく、メンションを含んでいるファイルからの相対パスになります。「相対パスは、メンションを含むエージェントファイルからの相対パスとして解釈されます。」絶対パスや@~/some/pathも動作します。また、globの解決には独自のルールがあります。「globは、../または./で始まらない限り、暗黙的に**/がプレフィックスとして付加されます。../または./で始まる場合は、言及されたファイルからの相対パスを指します。」したがって、*.test.tsはどこにあるテストファイルにも一致しますが、./fixtures/*.jsonはそれを宣言したファイルの隣にあるファイルを指します。

もう1点、文章中でパスを説明する際に重要な点があります。「誤検知を避けるため、コードブロック内の@メンションは無視されます。」バッククォート内にパスを記述しても、インポートされることはありません。

ステップ3:ロードされた内容を確認し、事実を切り離す

Ampには、作業結果を確認する直接的な方法が用意されています。「Ampが使用しているエージェントファイルを確認するには、コマンドパレットからagents-md listを選択します。」いくつかの異なるディレクトリから、またエージェントが異なるファイルタイプに触れた後にこれを実行してみてください。これが、globが意図通りに機能しているかを確認する最も早い方法です。

次に、常駐セットを実際に縮小する作業を行います。ルートファイルに残っている内容を見直し、各行について「指示(instruction)」なのか「事実(fact)」なのかを問いかけます。「コミット前にpnpm testを実行する」は指示です。短く、行動を規定するものであり、AGENTS.mdに属します。「2つのモバイルクライアントが古いビルドを固定しているため、APIはパスでバージョン管理されている」は事実です。これはファイルタイプに関するものではないため、適合するglobはありません。プロジェクトに関する情報であり、エージェントはパターンが一致したときではなく、その話題が出たときにいつでも必要とします。

「事実」は指示ファイルを肥大化させ、最終的にエージェントが指示に従わなくなる原因になります。ゲートの形状が常に合わないため、どのような制限メカズムでもこれを解決することはできません。解決策は、エージェントが必要に応じて読み込める場所にそれらを保管しておくことです。MemoryLakeは、3つのステップでセットアップできます。

ステップ1:APIキーを作成する

サインインし、ダッシュボードからAPIキーを生成します。これはAGENTS.mdのチェーンとは完全に切り離されているため、保持されている情報がすべてのセッションで常駐したり、適合しないパターンによって制限されたりすることはありません。

事実がAmpの常にインクルードされる指示ファイルの外に置かれるように、MemoryLakeのAPIキーを作成する
事実がAmpの常にインクルードされる指示ファイルの外に置かれるように、MemoryLakeのAPIキーを作成する

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

事実を入力します。アーキテクチャの決定とその背後にある理由、ドメイン用語、サービスの所有権、ワークアラウンドが存在する理由、コードレビューで繰り返し回答している内容などです。ファイルタイプではなく、プロジェクト自体について真実であるすべての情報が対象です。

ルートのAGENTS.mdを肥大化させる代わりに、プロジェクトの事実をMemoryLakeにアップロードする
ルートのAGENTS.mdを肥大化させる代わりに、プロジェクトの事実をMemoryLakeにアップロードする

行動に関する指示はAGENTS.mdに残し、パターンが真に適用される場所ではglobで制限します。これら2つのレイヤーは異なる役割を担います。

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

Ampをストアに向けます。これにより、ルートファイルは確実に従えるほど十分に短くなり、glob制限付きファイルは限定的かつ行動に特化した状態を維持し、プロジェクトの知識は質問が必要としたときにのみ提供されます。これは、reducing token usage with a memory layer(メモリレイヤーによるトークン使用量の削減)の背後にある考え方と同じです。

ガイダンスのスコープを限定した状態に保つために、MCP経由でAmpをMemoryLakeに接続する
ガイダンスのスコープを限定した状態に保つために、MCP経由でAmpをMemoryLakeに接続する

実践においてこれがもたらす変化

最初の変化は、ガイダンスの追加がトレードオフではなくなることです。現状では、新しい規約を常駐ファイルに追加してすべてのタスクに負荷をかけるか、あるいは追加を諦めるかの二者択一です。制限付きファイルは、ファイルタイプの形状を持つすべてのものに対して、この選択を不要にします。

2つ目は、より優れた文章を書かなくても、指示への準拠率が向上することです。常駐する指示セットが短い方が、長いものよりも一貫して遵守されます。コンテキストの予算に余裕がある場合でも、分割を行う価値があるのはそのためです。

3つ目は、ツールの切り替えコストが下がることです。AmpはすでにフォールバックとしてAGENT.mdCLAUDE.mdを読み込むため、指示レイヤーはポータブルに近い状態にあります。これはmigrating CLAUDE.md to AGENTS.mdで説明されている形状です。一方で、事実レイヤーは、ツールの外部に保持して初めてポータブルになります。

Ampの指示をスコープ制限するためのベストプラクティス

  • ルートファイルは一般的な内容にとどめる。 アーキテクチャ、ビルドおよびテストコマンド、レビューおよびリリースの手順など。大規模リポジトリに対するAmp自身の推奨事項です。
  • ディレクトリ依存のガイダンスにはサブツリーファイルを使用する。 エージェントがそのサブツリー内のファイルを読み込んだときにロードされます。
  • ファイルタイプ依存のガイダンスにはglobsを使用する。 言語の規約、テストパターン、フレームワークのルールなど。
  • 単純な@メンションは無条件であることを忘れない。 globsがない場合、メンションされたファイルは常にインクルードされます。
  • 2つの解決ルールに注意する。 メンションのパスはメンション元のファイルからの相対パスとして解決され、globは./または../で始まらない限り、暗黙的に**/がプレフィックスとして付加されます。
  • 古いフォールバックを確認する。 AGENTS.mdがないディレクトリに残されたAGENT.mdCLAUDE.mdは、有効なガイダンスとして機能してしまいます。
  • agents-md listで確認する。 異なるディレクトリから、また異なるファイルタイプに触れた後に実行してください。
  • タスクごとに1つのスレッドを使用し、肥大化したらハンドオフする。 Ampのガイダンスであり、これは整理整頓のためではなく、コンテキストの品質を保つためのものです。

結論

Ampの指示システムは、各ファイルがいつロードされるかについて非常に明示的です。そのモードの1つである、AGENTS.mdから参照されるglob制限付きファイルは、指示を固定コストから条件付きコストへと変化させます。必要なのはわずか数行のフロントマターであり、ルートファイルが肥大化したリポジトリにおいて、最もレバレッジの高い単一の変更となります。

解決できないのは、パターンのないコンテンツです。プロジェクトの事実はファイルタイプに依存しないため、制限(ゲート)は適切なツールではありません。指示と知識を切り離し、指示を制限し、知識はセッションごとにコストを支払うことなくエージェントがアクセスできる場所に配置しましょう。

よくある質問

@で参照されたファイルは毎回ロードされますか?」

globsが指定されていない場合のみ毎回ロードされます。ドキュメントには明記されています。『globsが指定されていない場合、ファイルは@メンションされたときに常にインクルードされます。』globsリストを追加することで、インクルードを条件付きにすることができます。」

「glob制限付きファイルは、具体的に何がトリガーとなってロードされますか?」

「Ampが一致するファイルを読み込んだときです。ドキュメントの表現は『globsが指定されたメンション先ファイルは、Ampがそのglobのいずれかに一致するファイルを読み込んだ場合にのみインクルードされます』となっており、エディタの状態ではなく、タスク実行中のエージェントの実際の読み込み動作に従います。」

「globパターンはどこを基準に解決されますか?」

「globは『../または./で始まらない限り』暗黙的に**/プレフィックスが付加され、『その場合は言及されたファイルからの相対パスを指します。』メンションのパス自体は、作業ディレクトリではなく、メンションを含むエージェントファイルからの相対パスとして解決されます。絶対パスや@~/some/pathもサポートされています。」

「Ampが常にインクルードするファイルはどれですか?」

「作業ディレクトリおよび$HOMEまでの親ディレクトリにあるAGENTS.md、さらにシステム全体のガイダンス、および存在する場合は$HOME/.config/amp/AGENTS.md$HOME/.config/AGENTS.mdの両方です。サブツリーファイルは条件付きのケースであり、エージェントがそのサブツリー内のファイルを読み込んだときにインクルードされます。」

「残してしまったCLAUDE.mdをAmpは読み込みますか?」

「はい、AGENTS.mdが存在しないディレクトリでは読み込まれます。『ディレクトリにAGENTS.mdが存在しない場合でも、AGENT.md(末尾のSなし)またはCLAUDE.mdという名前のファイルが存在すれば、そのファイルがインクルードされます。』移行には便利ですが、古い規約が適用され続ける場合は監査する価値があります。」

「Ampが実際に何をロードしたかを確認するにはどうすればよいですか?」

「コマンドパレットからagents-md listを選択します。使用中のエージェントファイルが表示されます。これは、挙動から推測するのではなく、globが意図通りに制限を行っているかを確認するための確実な方法です。この一般的な習慣については、what coding agents actually readで説明されています。」