実際に移行できるもの
プレーンな指示内容は完全に移行できます。 セットアップコマンド、コードスタイル、テスト手順、PR の規約、アーキテクチャの制約など、これらはほとんどの CLAUDE.md ファイルの大部分を占めており、AGENTS.md も同様に、必須のフロントマターを持たない指示用の Markdown ファイルです。
常時有効なスコープは移行できますが、ツールごとに注意点があります。 ルートレベルの AGENTS.md は、それを読み込むツールによって常時有効として扱われます。Codex は「作業を開始する前に AGENTS.md ファイルを読み込みます」。Zed は「個人およびプロジェクトレベルのエージェントガイダンス用の主要な指示ファイルとして AGENTS.md をサポートしています」。Cursor は、ネストされたサブディレクトリのサポートを伴う「.cursor/rules のシンプルな代替手段」として AGENTS.md をリストしています。Devin は「CLAUDE.md や AGENTS.md を含む、コードベース内の専用ファイルに基づいてナレッジを自動的に取得および更新します」。
ディレクトリごとのスコープ指定は移行できますが、その仕組みは異なります。 どちらのフォーマットもディレクトリごとのファイルをサポートしています。Claude Code はワーキングディレクトリからツリーを遡り、見つかったものを「ファイルシステムのルートからワーキングディレクトリへ」の順に結合します。Codex も同じ方向にチェーンを構築します。「Codex はルートから順にファイルを結合し、空行で連結します。現在のディレクトリに近いファイルほど、結合されたプロンプトの後方に表示されるため、以前のガイダンスを上書きします」。Cursor のネストされた AGENTS.md ファイルは、「親ディレクトリと結合され、より具体的な指示が優先されます」。
同じ形状ですが、3 つの異なるローダーが存在します。ネストされた指示は機能しますが、優先順位のセマンティクスが同一であるとは仮定しないでください。
1つのファイル、4つの異なるローダー
統合する前に知っておくべきこととして、「AGENTS.md を読み込む」という意味はツールごとにわずかに異なり、その違いによってファイルの構成方法が決まります。
Codex は、実行ごとに 1 回指示チェーンを構築します。Codex のホームディレクトリにあるグローバルファイルから開始し、プロジェクトのルートからワーキングディレクトリへと下っていき、各ディレクトリから最大 1 つのファイルを取得して、ルートから順に結合します。また、チェーン全体に上限を設けています。「結合されたサイズが project_doc_max_bytes（デフォルトは 32 KiB）で定義された制限に達すると、ファイルの追加を停止します」。
Cursor は、ルートの AGENTS.md を .cursor/rules のゼロ構成の代替手段として扱い、ネストされたファイルは「親ディレクトリと結合され、より具体的な指示が優先されます」。
Zed は、個人スコープとプロジェクトスコープの両方で主要な指示ファイルとして使用します。個人用には ~/.config/zed/AGENTS.md、プロジェクト用には「競合が発生したときに個人の AGENTS.md を上書きする」プロジェクトファイルを使用します。そのプロジェクトローダーは、リストから最初に一致したファイルを取得するため、古いルールファイルが残っていると問題になります。
Devin はこれを指示として直接読み込むのではなく、「CLAUDE.md や AGENTS.md を含む、コードベース内の専用ファイルに基づいてナレッジを自動的に取得および更新」します。そのナレッジがセッションに届くかどうかは、ピン留めやトリガーの説明に依存します。
4 つすべてに共通する実用的な教訓は同じです。ルートファイルを短く保ち、具体的な内容はディレクトリレベルのファイルに押し出すことです。これにより、Codex の上限、Cursor の優先順位、Zed の上書き動作を同時に満たすことができます。
これを連携させる際、少し安心できる点があります。@AGENTS.md のインポートは、Claude Code の外部インポート承認ダイアログをトリガーしません。このダイアログは、インポートが「ワーキングディレクトリの外側で解決される」場合に表示されます。リポジトリルートの AGENTS.md は内側にあるため、プロンプトを表示せずにインポートが読み込まれます。
移行できないもの — 以下の 3 つがあり、これらが CLAUDE.md を削除せずに残しておく理由です。
@path インポート。Claude Code のインポート構文には、AGENTS.md に相当するものがありません。
CLAUDE.local.md。各ディレクトリの CLAUDE.md の後に追加される、コミットされない個人用のメモ。対応するものがありません。
Claude Code 自体が書き込んだもの。自動生成されたメモリは、定義上 Claude 固有のものです。
手動移行の手順
ドキュメント化されている 2 つのパスがあります。Claude 固有のコンテンツが必要かどうかに基づいて選択してください。
ステップ 1: 共有コンテンツを AGENTS.md に移動する
リポジトリのルートに AGENTS.md を作成し、セットアップ、テスト、スタイル、規約など、ツールに依存しないすべての内容をそこに移動します。次に、CLAUDE.md に残っている内容を読み、整理します。本当に Claude 固有の指示だけを残し、それ以外はすべて削除します。
この機会に、すでに真実ではなくなった部分は移行するのではなく削除してください。統合は、廃止したサービスについて説明している段落を削除する絶好の機会です。
リポジトリに .cursorrules、.windsurfrules、または .clinerules もある場合は、それらも今すぐ統合してください。いくつかのツールは AGENTS.md をネイティブに読み込みます。また、Zed のプロジェクト指示ローダーは、.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md を含むリストから最初に一致したファイルを取得するため、古い .cursorrules を残しておくと、新しい AGENTS.md が完全に隠されてしまう可能性があります。
ステップ 2: Claude Code を同じファイルに連携させる
Anthropic は 2 つの方法をドキュメント化しています。Claude 固有の追加内容を保持できるインポートバージョンは以下の通りです。
@AGENTS.md
## Claude Code
`src/billing/` 以下の変更には plan モードを使用してください。ドキュメントによると、「Claude はセッション開始時にインポートされたファイルを読み込み、その後に残りの部分を追加します」。または、「Claude 固有のコンテンツを追加する必要がない場合」はシンボリックリンクを使用します。
ln -s AGENTS.md CLAUDE.mdドキュメントから直接引用した 2 つの検証時の注意点です。「コマンドが成功しても出力は表示されません。次のセッションで /context を実行し、CLAUDE.md が Memory files の下に表示されていることを確認してください」。また、Windows の場合、「シンボリックリンクの作成には管理者権限または開発者モードが必要なため、代わりに @AGENTS.md インポートを使用してください」。
手動で整理したくない場合に知っておくと便利なショートカットがあります。/init は「.cursor/rules/ または .cursorrules にある Cursor のルール、および .github/copilot-instructions.md にある Copilot のルールを読み込み、関連する部分を生成された CLAUDE.md に組み込みます。CLAUDE_CODE_NEW_INIT=1 が設定されている場合、/init は AGENTS.md、.devin/rules/、.windsurf/rules/ または .windsurfrules、および .clinerules も読み込みます」。方向性に注意してください。これは他のファイルから CLAUDE.md を生成するため、ここで行いたいこととは逆ですが、整理する前にこれまでに蓄積されたすべてを 1 か所で確認する最も早い方法です。
次に、サイズ予算を確認します。Codex は「結合されたサイズが project_doc_max_bytes（デフォルトは 32 KiB）で定義された制限に達すると、ファイルの追加を停止」し、制限に達した場合は制限を引き上げるか、ネストされたディレクトリに分割することを推奨しています。Claude Code のガイダンスでは、ファイルが長くなるとより多くのコンテキストを消費し、指示への追従性が低下するとされています。統合された 1 つのファイルが目標ですが、巨大な 統合ファイルを作ることは目標ではありません。
より良い方法：ファイルを小さく保ち、知識を検索可能にする
統合することで、3 つではなく 1 つのファイルになります。しかし、ファイルが得意とすることは変わりません。指示ファイルが得意なのは方向付けであり、プロジェクトの論理的根拠（推論）を保持することではありません。
上記のすべてのローダーは、実行ごとに常時有効なコンテンツをコンテキストに結合します。これこそが、サイズ制限が存在する理由です。したがって、エージェントに最も知っておいてほしい部分（なぜそのようなアーキテクチャになっているのか、すでに試して断念したアプローチは何か、奇妙な決定を正しくしている制約は何かなど）は、まさにリクエストごとに送信されるファイルに含めるべきではない部分です。
それを保持するのが MemoryLake です。ツールが読み取るレイヤーに永続的なプロジェクト知識を保持するため、AGENTS.md は短く保たれ、論理的根拠はいつでも利用可能な状態になります。セットアップは 3 つのステップです。
ステップ 1: API キーを作成する
MemoryLake にサインインし、API キーを作成します。接続するすべてのツールで 1 つの認証情報を使用します。
ステップ 2: 最初のメモリをアップロードする
CLAUDE.md を整理していくと、どちらのファイルにも属さない 3 つ目の山が見つかるはずです。それらを、1 つの主張につき 1 つの短いエントリとして書き出します。
決定事項と、それを生み出した制約。 「決済プロバイダーが冪等性キーなしで再試行するため、書き込みは outbox テーブルを経由します」。ルールには前半部分のみが記載されますが、このバージョンだけが、代替案が再び提案されるのを防ぎます。
すでに除外されたアプローチ。 最も価値の高いカテゴリであり、リポジトリのどこにも存在しないものです。
リポジトリをまたぐ知識。 所有するすべてのプロジェクトに適用されるドメイン用語や標準。AGENTS.md は設計上リポジトリごとですが、これはそうではありません。
これまでに複数回行った修正。 2 回言及したことがあるなら、それは不足しているエントリであり、その理由を隣に記載すべきです。
ステップ 3: AI とエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセスできるため、Claude Code、Codex、OpenClaw などの MCP ネイティブエージェントは MCP サーバーを指定して接続し、他のアシスタントは API を介して同じメモリを読み取ります。
3 つの率直な制限事項があります。MemoryLake は AGENTS.md の代替品ではありません。 引き続きそのファイルは必要であり、上記の統合はそれ自体で行う価値があります。また、あなたやエージェントが書き込んだ内容のみを保持するため、ステップ 2 は手動で行う必要があります。そして、指示ファイルは強制的な設定ではなくコンテキストであり、メモリレイヤーを導入してもその事実は変わりません。
実践においてこれがもたらす変化
1 つのファイルになり、正確性が保たれます。 乖離していた 3 つのコピーが 1 つになり、AGENTS.md をネイティブに読み込むツールは、ツールごとの連携設定なしでそれを取得します。
Claude Code が動作し続けます。 @AGENTS.md のインポートはドキュメント化されており、1 行で記述でき、元に戻すことも可能です。標準規格と既存のセットアップのどちらか一方を選択する必要はありません。
サイズ制限が問題にならなくなります。 32 KiB は方向付けには十分ですが、ナレッジベースとしては不十分です。これらの役割を分割することで、制限内に収めることができます。
古いルールファイルが新しいファイルを隠してしまうことがなくなります。 Zed がリストから最初に一致したファイルを取得することを知っていれば、.cursorrules の削除は、3 週間後に発生する謎の不具合ではなく、移行作業の一部になります。
新しいツールの導入コストがゼロになります。 リストのほとんどはすでに AGENTS.md を読み込みます。そうでないものは、MCP 経由でメモリレイヤーを読み込みます。この構成については、Cursor と Claude Code の間で 1 つのメモリを共有する で解説しています。
統合された指示ファイルのベストプラクティス
共有コンテンツは AGENTS.md に配置し、Claude 固有のコンテンツはインポートの下に配置します。 これがドキュメント化されているパターンであり、差分（diff）を読みやすく保つことができます。
統合が完了したら、.cursorrules と .windsurfrules を削除します。 そうしないと、最初に一致したファイルを読み込むローダーが古い方を読み込んでしまう可能性があります。
Claude 固有の指示がある場合は、シンボリックリンクではなくインポートを使用します。 また、Windows では状況に関わらずインポートを使用してください。
/context で検証します。 思い込みに頼るのではなく、次のセッションで CLAUDE.md が Memory files の下に表示されていることを確認してください。
上限以下に保ち、肥大化したらディレクトリごとに分割します。 Codex のデフォルトはチェーン全体で 32 KiB です。ネストされたファイルは、この制限内に収めるためのドキュメント化された方法です。
ドキュメントをそのまま貼り付けないでください。 参照するようにします。コードの変更に伴ってコピーは古くなります。これが、エージェントが作成した指示ファイルを無視する理由 の背景にあるポイントです。
Git にコミットします。 これにより、統合されたファイルが個人の資産ではなく、チームの資産になります。
理由はファイルに含めず、検索可能なレイヤーに保持します。 AGENTS.md には方向性を、メモリには議論（論理的根拠）を。この分割こそが、ファイルを実際に従うことができる程度に小さく保つ秘訣です。
結論
AGENTS.md が勝利したのは、退屈（シンプル）だったからです。予測可能な名前を持つオープンな Markdown ファイルであり、すでに 6万以上のリポジトリと主要なエージェントの大部分が読み込んでいます。これに統合することで、3 つのファイルが乖離していく問題が解消されます。また、AGENTS.md ではなく CLAUDE.md を読み込む注目すべきツールである Claude Code には、@AGENTS.md インポートというドキュメント化された 1 行のブリッジ方法があり、Claude 固有の追加内容がない場合はシンボリックリンクを使用できます。
統合で解決できないのは、指示ファイルが本来想定していなかった部分です。すべてのローダーはリクエストごとに常時有効なコンテンツを送信するため、いずれもサイズ制限を設けています。そのため、共有の指示は AGENTS.md に移動し、Claude 固有の行はインポートの下に配置し、古いルールファイルは削除して、決定事項、制約、却下されたアプローチはエージェントがクエリできるレイヤーに配置してください。実際に従われる 1 つの短いファイルは、途中で切り捨てられる 1 つの長いファイルに勝ります。