実際に引き継がれるもの
すべての CLAUDE.md ファイル（変更なし）。 Augmentのルールに関するドキュメントでは、Auggieがロードするファイルを「以下の優先順位」でリストアップしています。
1. カスタムルールファイル（--rulesフラグ経由）、2.CLAUDE.md、3.AGENTS.md、4. ワークスペースガイドライン（.augment-guidelines）、5. ワークスペースルールフォルダ（<workspace_root>/.augment/rules/）、6. ユーザールールフォルダ（~/.augment/rules/）
ここで2つの点が際立っています。CLAUDE.mdがAGENTS.mdよりも上位にランクされていることです。これは他のいくつかのエージェントが使用している順序とは逆です。そして、どちらの外部ファイル名もAugmentのネイティブなルールディレクトリより上位にあり、ユーザーレベルのディレクトリが最後になっています。
ネストされた CLAUDE.md ファイルは引き継がれ、そのスコープも維持されます。 Claude Codeはツリーの下層にある CLAUDE.md ファイルを検出し、「検出されたすべてのファイルは、互いに上書きされるのではなく、コンテキストに連結される」とし、その順序は「ファイルシステムのルートからワーキングディレクトリに向かって」行われるため、「Claudeを起動した場所に近い指示が最後に読み込まれる」と述べています。
Augmentも構造的には似たようなことを行いますが、トリガーが異なります。そのドキュメントでは、階層的なルールについて次のように説明されています。「ファイルで作業するとき、Augmentはそのファイルのディレクトリ内で AGENTS.md と CLAUDE.md を探します。」そして「ディレクトリツリーを上にたどり、各親ディレクトリでこれらのファイルを確認します。」および「検出されたすべてのルールが、その作業セッションのコンテキストに含まれます。」この探索は「ワークスペースのルートで停止」します。また、ルールは「重複して含まれるのを避けるため、会話セッションごとにキャッシュ」されます。
そのため、src/frontend/CLAUDE.md と src/backend/CLAUDE.md を持つモノレポは、ほぼ期待通りに動作します。src/frontend/ で作業が行われると、そのファイルと親ディレクトリのファイルがロードされ、バックエンドのファイルはロードされません。
インポートは引き継がれません。 Claude Codeは CLAUDE.md 内での @path インポートをサポートしており、ドキュメントには「インポートの解析はMarkdownのコードスパンやフェンス付きコードブロックをスキップする」という細かな仕様が記載されています。そのため、バッククォートで囲まれた @README はリテラルのままになります。一方、Augmentのルールに関するドキュメントでは、オプションのYAMLフロントマターを持つプレーンなMarkdownファイルについて説明されており、インポート構文については記載されていません。移行された CLAUDE.md 内の @path 行はテキストとして扱われるべきです。依存する前に、インポートされたコンテンツをファイル内にフラットに展開（インライン化）してください。
1つのルールタイプにはCLIの移行先がありません。 Augmentのワークスペースルールは、ドキュメント化されている2つの値 always_apply と agent_requested を持つ type フィールドを受け取り、IDE拡張機能は3つ目の値を公開しています。CLIのページでは、このギャップについて明記されています。
「手動（Manual）ルールはCLIではサポートされていません。<workspace_root>/.augment/rules/内のtype: manualを持つルールはCLIによってスキップされます。オンデマンドで添付するための@-メンションメカニズムが存在しないためです。」
IDE側のページでもこれが繰り返されています。Manual は「IDE専用 — @-メンションを介してオンデマンドで添付、CLIではスキップ」となっています。チームが両方のインターフェースを使用している場合、手動ルールはエディタ内では有効ですが、ターミナルでは存在しないことになります。
ユーザーレベルのルールはフロントマターを失います。 Augmentのドキュメントには、「~/.augment/rules/ 内のユーザールールは常に always_apply として扱われ、他のフロントマタータイプはサポートされない」と記載されています。ホームディレクトリに配置したものは、フロントマターの記述に関係なく、すべてのプロジェクトのすべてのセッションで有効になります。
自動メモリは引き継がれません。 Claude Codeには2つの永続化システムがあり、ドキュメントではそれらを補完的なものとして説明しています。あなたが記述する CLAUDE.md ファイルと、自動メモリ（「あなたの修正や好みに基づいてClaude自身が書き留めるメモ」）です。自動メモリはプロジェクトごとに ~/.claude/projects/<project>/memory/ に保存され、「毎セッション（最初の200行または25KB）」注入されます。Augmentにもメモリシステムがありますが、異なるものです。Cosmos Expertsは「共有仮想ファイルシステム（VFS）にスコープされた知識」を保存し、Expertのメモリは「そのチームに属し」、ドキュメント化されている2つのモデル（シンプルとノイジー）があります。どちらも他方のファイルを読み取ることはありません。Cosmos側については、steering what Augment's Experts remember（AugmentのExpertが記憶する内容をコントロールする）で別途取り上げました。このガイドは、異なるライフサイクルを持つ異なるメカニズムである指示レイヤーに関するものです。
手動移行
Step 1: CLAUDE.md を信頼できる唯一の情報源（オーソリティ）として残すかどうかを決め、その決定に従う
一貫性のある選択肢は2つあります。失敗するパターンは、どちらも選ばないことです。
オプションA: CLAUDE.md を維持する。 優先順位は2位であり、動作します。また、まだ移行していない人のために、Claude Codeがリポジトリを読み取れる状態を維持できます。デメリットは、単一の CLAUDE.md にはフロントマターやファイルの境界がないため、Augmentのネイティブ機能（ルールごとの type フロントマター、個別にレビューできるルールごとのファイル）が利用できないままになることです。
オプションB: .augment/rules/ に変換する。 ルールごとに1つのファイルを作成し、それぞれに独自の type を設定できます。これは、どちらのツールにとっても条件付きロードに最も近い機能です。しかし、これには誰も予想していない代償があり、それについては次の段落で詳しく説明します。
Augmentの階層的な検出がカバーするのは、正確に2つのファイル名だけです。ドキュメントには「AGENTS.md および CLAUDE.md ファイルのみが階層的に検出されます」とあり、その直後に「.augment/rules/ 内のファイルはワークスペースのルートからのみロードされ、サブディレクトリからはロードされません」と記載されています。
つまり、Augment独自のフォーマットに変換すると、ディレクトリのスコープ制限が失われます。src/frontend/CLAUDE.md は、フロントエンドで作業が行われているときのみロードされていました。同じコンテンツを .augment/rules/frontend.md に移動すると、すべての作業においてワークスペースのルートからロードされるようになります。ベンダーのネイティブフォーマットは、この1つの軸において、サポートされている3つのフォーマットの中で最もスコープ制限が効かないものになります。
ほとんどのチームにとって実用的な解決策は、役割を分けることです。ディレクトリのスコープ制限が実際に機能している場所ではネストされた CLAUDE.md ファイルを維持し、常時オン以外の type を必要とするリポジトリ全体のルールにのみ .augment/rules/ を使用します。ツリーを整理するためだけに、ネストされたファイルを変換しないでください。
どちらを選ぶにしても、想定するのではなく検証してください。Claude Code自身の整合性に関する注意書きは、検証すべき良い理由になります。「2つのルールが互いに矛盾している場合、Claudeは一方を任意に選択することがあります。」2つのルールツリーが同時にロードされることは、あなたが書いていない矛盾が生じる原因そのものであり、その解決メカニズムを検査することはできません。Claude Code側でその状況を監査する方法については、reconciling conflicting CLAUDE.md layers（競合するCLAUDE.mdレイヤーの調整）で詳しく解説しています。
Step 2: 条件付きルールを再宣言し、文字数の上限を確認する
Claude Codeの条件付きロードのメカニズムは、paths フロントマターを持つ .claude/rules/ であり、さらに paths のないルールは「起動時に .claude/CLAUDE.md と同じ優先順位でロードされる」という注意書きがあります。一方、Augmentのメカニズムは type フィールドです。
これらを意図的にマッピングしてください。パススコープされた Claude Code ルールは、それが適用されるディレクトリ内のネストされた CLAUDE.md（スコープを維持する）にするか、適用されるタイミングを description に記述した agent_requested ルールにするかのいずれかになります。適切な説明を書ける場合、Augmentのガイダンスは後者を推奨しています。「コンテキストの使用量を最適化したい場合は、always_apply よりも agent_requested を使用してください。これらのルールについては、エージェントが現在のタスクに関連しているかどうかを判断します。」agent_requested には description が必須であり、これが選択のすべての役割を果たすことに注意してください。
次に、上限（バジェット）を確認してください。Augmentは厳格な制限を公開しており、Claude Codeは推奨事項を公開しているためです。Claude Codeは「CLAUDE.md ファイルあたり200行未満を目指す」ことを推奨しています。これはガイドラインであり、上限ではありません。Augmentの制限セクションは上限であり、オーバーフロー時の動作がドキュメント化されています。
「ユーザーガイドラインは現在、最大24,576文字に制限されています。ワークスペースガイドライン＋ルールは、合計で最大49,512文字に制限されています。これらの制限を超えた場合、ユーザーはアプリ内で通知され、（手動ルール、常時適用＋自動ルール、.augment-guidelines）の順に適用されます。」最後の文の順序をよく読んでください。上限を超えた場合、手動ルールが最初に適用され、.augment-guidelines が最後に適用されます。.augment-guidelines を信頼できる唯一のファイルとして扱ってきたチームは、制限がかかった状況において最も優先順位の低いアイテムを信頼できるものとして扱っていることになります。
チームの一部がCLIではなく拡張機能を使用している場合の、もう1つのIDE固有の詳細です。「VSCodeで定義されたガイドラインはJetBrains IDEに伝播せず、その逆も同様です。」ユーザーガイドラインはローカルのIDEストレージに保存されるため、共有もバージョン管理もされません。複数人にとって重要なものはすべて、リポジトリに含めるべきです。
より良い方法：どちらの優先順位リストでも並べ替えられない推論レイヤー
どちらのツールもファイルをランク付けしますが、ルールが存在する「理由」は保存しません。
これこそが、ファイルの移動とは異なる意味で、この移行を危険なものにするギャップです。ネストされた CLAUDE.md を agent_requested ルールにすることを決定するとき、その description に何を書くかも決定することになります。そして、その説明が、そのルールが再びロードされるかどうかを決定します。元の制約が「決済モジュールは、特定の障害パスで二重課金が発生するため、共有のリトライヘルパーを使用してはならない」であった場合、ルールは移動を生き延びますが、その理由は生き延びません。そして、理由の書かれていない簡素なルールを読んだ次の人が、それを削除してしまうのです。
MemoryLakeは、決定事項、試されたこと、却下された理由、そしてその時期といった「正当な理由」を保持します。これは両方の指示システムの外側に位置するため、優先順位の変更やフォーマットの変換によって並べ替えられることはありません。ここから始めましょう。
Step 1: APIキーを作成する
リポジトリ用のワークスペースを作成し、APIキーを生成します。重要なのは、このキーが両方のツールよりも長生きすることであるため、Claude CodeやAugmentではなく、リポジトリにスコープを設定します。
Step 2: 最初のメモリをアップロードする
何かを変換する前に CLAUDE.md ツリーをたどり、一見して分かりにくい各ルールがなぜそこにあるのかを記録します。Claude Codeに繰り返し与えてきた修正を追加してください。これらは、Claude Codeの自動メモリがローカルに蓄積してきたものと同じ修正であり、自動的には移行されません。次に、移行自体の中で行われた決定（どのファイルを残し、どのファイルを変換し、何を意図的に残さなかったか）を追加します。
Step 3: AIとエージェントを接続する
Auggieを接続し、移行期間中はClaude Codeも接続したままにします。両方が同じセットを読み取るため、まだ移植していないルールであっても、誰かがたまたま使用しているエージェントに対してその根拠を利用可能な状態に保つことができます。
実務における変化
「すでに動いている」という罠によって1ヶ月を無駄にすることがなくなります。初日から CLAUDE.md が2位にランクされていることを知っているため、忘れていたファイルの下に新しい .augment/rules/ ファイルが埋もれていたことを後から発見するのではなく、残すか変換するかの決定を意図的に行うことができます。
変換によって誤ってスコープ制限を失うことがなくなります。AGENTS.md と CLAUDE.md のみが階層的に検出されることを知れば、「すべてをネイティブフォーマットに移動する」ことが、明らかなクリーンアップ作業のようには見えなくなります。
オーバーフローが目に見えないものではなくなります。Augmentの上限にはドキュメント化された適用順序があるため、49,512文字に近いチームは、ルールが適用されなくなった理由を推測するのではなく、どのカテゴリが最初に機能低下するかを知ることができます。
そして、インターフェースの分裂問題に名前が付きます。VS Codeでは動作し、CLIではスキップされる manual ルールは、ルールファイルを読んでも見つからないバグではありません。これは、あらかじめ考慮して設計するか、あるいは不意打ちを食らうことになる、ドキュメント化された挙動です。
Augment Code導入初月のベストプラクティス
変換する前にインベントリ（目録）を作成してください。リポジトリ内のすべての CLAUDE.md、AGENTS.md、.augment-guidelines、および .augment/rules/ ファイルをリストアップし、どれがロードされると期待しているかを書き留めます。次に、それぞれから意図的に奇妙なルールを1つテストし、どれが実際に適用されるかを確認します。これは、why agents ignore your instruction files（エージェントが指示ファイルを無視する理由）で説明したケースをキャッチする最も早い方法です。
ネストされたファイルはネストされたままにしてください。ディレクトリのスコープ制限は、2つの外部フォーマットでは追加コストなしで利用できますが、ネイティブフォーマットでは利用できません。これは珍しいインセンティブであり、ツリーをそのままにしておくことを後押しします。
description フィールドはトリガー条件として記述してください。agent_requested ルールの場合、説明がアクティベーションメカニズムのすべてになります。Augment自身の例である「Reactコンポーネントの開発パターンとベストプラクティス」は、ルールの内容の要約よりも優れています。
~/.augment/rules/ は常時オンとしてのみ扱ってください。そこではフロントマターが無視されるため、ホームディレクトリに配置したものは、開くすべてのプロジェクトに適用されます。これは、純粋な個人の好みのために予約しておいてください。
すべてを見つけるためにAugmentの自動インポートに依存しないでください。それは「*.md や *.mdx で終わるファイルなどのMarkdownファイルを探します」となっており、便利ではありますが、マニフェスト（目録）と同じではありません。重要なルールがある場合は、優先順位リストに名前がある場所に配置してください。
どちらのツールも強制力を持たないことを忘れないでください。Claude Codeははっきりと「Claudeはこれらをコンテキストとして扱い、強制された設定としては扱わない」と述べており、Claudeの決定に関係なくアクションをブロックするために PreToolUse フックを推奨しています。ルールは意図を記述するものです。強制は別のレイヤーであり、これはこの移行の両側に当てはまります。この問題の社内規約バージョンは、making Claude stick to your conventions（Claudeに社内規約を守らせる方法）でカバーされています。
結論
この移行における驚きは、何かが壊れることではありません。しばらくの間、何も壊れないことです。CLAUDE.md はAugmentの優先順位リストの2位にあるため、指示レイヤーは動作し続け、ツールのネイティブフォーマットはその下で未使用のまま眠っています。
意図的に行う価値のある2つの決定は、CLAUDE.md を信頼できる唯一の情報源として残すかどうか、およびネストされたファイルを .augment/rules/ にフラット化（インライン化）するかどうかです。なぜなら、そのディレクトリはワークスペースのルートからしかロードされないからです。これらを正しく行えば、これは最も低コストなエージェント移行の1つになります。間違えれば、古いファイルをずっと読み込んでいたツールの中で、実際には一度もロードされていなかったルールのデバッグに何週間も費やすことになります。