CLAUDE.md 階層構造

CLAUDE.md 階層構造は、Claude Certified Architect — Foundations（CCA-F）試験のドメイン3.1の中心トピックであり、60問・120分の試験全体を通じてシナリオが最も豊富なトピックの一つだ。タスクステートメント 3.1――「適切な階層、スコーピング、モジュラー構成を持つ CLAUDE.md ファイルを設定する」――は、「Claude Code によるコード生成」シナリオクラスターと「継続的インテグレーションへの Claude Code 活用」クラスターの両方に登場するため、この試験を受けるすべての受験者は、CLAUDE.md ファイルがどこに存在し、誰がそれを参照し、異なるレベルの指示がどのようにマージされるかを理解することにかかった問題に少なくとも1〜2問は遭遇する。

本学習ノートでは、基礎段階のアーキテクトが習得すべき CLAUDE.md 階層構造の全体を解説する。3つのスコーピングレベル（ユーザー・プロジェクト・ディレクトリ）、それらの間の優先度とマージのルール、モジュラーなファイル構成のための @import 構文、モノリシックな CLAUDE.md の代替としての .claude/rules/ ディレクトリパターン、読み込まれたメモリファイルを確認するための /memory コマンド、新しいチームメンバーが期待される指示を受け取れない場合の診断パターン、そして720点の合格と893点の最上位スコアを分ける具体的な試験トラップを取り上げる。また、CCA-F が期待するもの（アーキテクチャレベルの判断とスコープの落とし穴の認識）と、基礎段階の対象外となる実装の深みに属するものとの明確な区別も示す。

CLAUDE.md とは何か、なぜ階層構造が重要か

CLAUDE.md は、Claude Code がセッション開始時に読み込む主要な設定ファイルで、会話をまたいで適用すべき永続的な行動指示、コーディング規約、プロジェクトコンテキスト、メモリを確立するために使われる。一度限りのユーザープロンプトが単一のターンにしか影響しないのに対し、CLAUDE.md の指示は、関連するディレクトリでセッションが開始されるたびに Claude の作業メモリに注入される。そのためこのファイルは「プロジェクトメモリ」または「リポジトリメモリ」ファイルとも呼ばれる。

CLAUDE.md 階層構造が存在するのは、Claude Code が少なくとも3つの異なるコンテキストで同時に使用されるからだ。個人的な習慣を持つ個々のエンジニア（「常に pnpm を使い npm は使わない」）、集合的な規約を持つリポジトリを共有するチーム（「すべての React コンポーネントはフックを使った関数型スタイルで書く」）、そしてローカルなオーバーライドが必要なリポジトリ内のサブシステム（TypeScript ルールではなく Markdown ルールに従うべき /docs ディレクトリ）だ。単一のフラットな設定ファイルでは、絶え間ない衝突なしに3つの対象を満たすことができない。そのため Anthropic は3つのマージするスコープを持つ CLAUDE.md 階層構造を設計した。

CLAUDE.md 階層構造を理解することは単なる語彙テストではない。CCA-F 試験が壊れた設定の診断、チームメンバーの正しいオンボーディング、個人の好みが共有リポジトリに漏れるのを防ぐという問いを問う際のアーキテクチャ的レンズだ。

3つのスコーピングレベル — ユーザー・プロジェクト・ディレクトリ

各レベルは特定のオーディエンスを対象とし、特定のファイルシステムの場所に存在する。ファイルを1レベル間違えることが、ドメイン3.1で最も一般的なトラップだ。

ユーザーレベル — ~/.claude/CLAUDE.md

OS アカウントに個人的なもので、コミットされず、プロジェクトに関係なくすべてのセッションで読み込まれる。個人の好み・環境のためのもの：「私を Jaric と呼ぶ」「pnpm を優先する」「返答は正体中文で」。

境界線：チームメンバーがリポジトリをクローンした場合にその指示が必要かどうか。必要なら、プロジェクトレベル。個人の好みや環境を反映するだけなら、ユーザーレベルに留める。

プロジェクトレベル — CLAUDE.md または .claude/CLAUDE.md

バージョン管理にコミットされた共有リポジトリメモリ。2つの標準的な場所が機能する。ベアルートはより発見しやすく、.claude/ ディレクトリは関連する設定（コマンド、スキル、ルール）をグループ化する場合に好まれる。技術スタックの宣言、コーディング規約、アーキテクチャの制約、禁止パターン、ツールコマンドにこのレベルを使用する。

ディレクトリレベル — ネストされた CLAUDE.md

サブディレクトリに存在し、Claude の作業コンテキストがそのサブツリー内にある場合にのみ適用される。モノリポでは、各 packages/*/CLAUDE.md がモジュール固有のルールを持つ。パス上で最も近いディレクトリレベルのファイルのみが読み込まれる ― この詳細は頻繁に試験で問われる。

階層の優先度とマージのセマンティクス

階層は勝者総取りではない。Claude Code は有効な指示セットを、具体性の順に（最も具体的なものを最後に）ファイルを連結してアセンブルする。そのため Claude が衝突を推論する際、具体的なものが自然に優先される。

読み込み順序

<repo>/packages/web/src/routes/login/ でセッションが開始された場合：

1. ~/.claude/CLAUDE.md（ユーザー）
2. <repo>/CLAUDE.md または <repo>/.claude/CLAUDE.md（プロジェクト）
3. CWD からリポジトリルートに向かってツリーをたどるすべての CLAUDE.md（すべてのディレクトリレベルのファイルが結合される）

マージは加算的であり置き換えではない

繰り返す試験トラップ：受験者はディレクトリレベルのファイルがプロジェクトレベルを置き換えると思い込む。置き換えない。プロジェクトが「Vitest を使う」と言い、docs/CLAUDE.md がテストについて何も言わない場合、Vitest のルールは docs/ の中でも有効だ。ディレクトリファイルは指示を追加するだけで、削除しない。

@import 構文によるモジュラー構成

リポジトリが成長するにつれて、モノリシックな CLAUDE.md はメンテナンスが困難になる。Anthropic の解決策：@import を使うと CLAUDE.md が他の Markdown ファイルを参照でき、各トピックが集中した内容を維持できる。

構文とパス解決

ルートの CLAUDE.md は次のようなものになるかもしれない。

# リポジトリメモリ

このリポジトリは Cloudflare Pages を使った Astro 4 モノリポです。

@import ./.claude/rules/typescript.md
@import ./.claude/rules/testing.md
@import ./.claude/rules/api-conventions.md

起動時、Claude Code はルートを読み、各 @import に遭遇し、ターゲットを読み込み、そのコンテンツをメインファイルの最初からずっとそこにあったかのようにインライン展開する。

相対パスのルール

@import のパスは、現在の作業ディレクトリやリポジトリルートではなく、ディレクティブを含むファイルに対して常に相対的だ。packages/web/CLAUDE.md に @import ./rules/components.md が含まれている場合、リゾルバーは <repo-root>/rules/components.md ではなく packages/web/rules/components.md を探す。

@import を使う理由

• 可読性 ― 各ルールファイルが1つのトピックに集中した50〜200行になれる。2,000行のメガファイルの代わりに。
• レビューしやすさ ― テストルールのみを変更するプルリクエストは testing.md のみを変更でき、差分が読みやすい。
• 再利用性 ― ルールファイルは複数の CLAUDE.md エントリ（例えばプロジェクトルートと特定のパッケージ）からインポートでき、重複がない。
• チームの所有権 ― 異なるチームが異なるインポートされたファイルを所有できる（プラットフォームチームが database.md を所有し、デザインシステムチームが components.md を所有する）。

.claude/rules/ — モジュラールールのディレクトリパターン

.claude/rules/ ディレクトリは、ルートの CLAUDE.md がインポートする個々のルールファイルの慣用的な置き場所だ。これは「自動的に読み込まれる魔法のパス」という意味での Claude Code のビルトイン機能ではない。チームが複数のリポジトリにわたって一貫してルールファイルを見つけられるよう、コミュニティと Anthropic 自身のドキュメントが推奨する命名規則だ。

典型的なレイアウト

<repo-root>/
├── CLAUDE.md                           # @import ディレクティブを持つオーケストレーター
└── .claude/
    ├── CLAUDE.md                        # （オプションの代替プロジェクトレベルファイル）
    ├── rules/
    │   ├── typescript.md
    │   ├── testing.md
    │   ├── api-conventions.md
    │   ├── database.md
    │   ├── deployment.md
    │   └── security.md
    ├── commands/                        # カスタムスラッシュコマンド（3.2 参照）
    └── skills/                          # カスタムスキル（3.2 参照）

オーケストレーターの CLAUDE.md はリポジトリの高レベルのコンテキストを維持し、詳細をルールファイルに委任する。

# ExamLab リポジトリメモリ

これは資格試験対策プラットフォームの Cloudflare ファーストのモノリポです。
フェーズ1 MVP は12言語で6つの認定試験を対象としています。

## コアルール

@import ./.claude/rules/typescript.md
@import ./.claude/rules/testing.md
@import ./.claude/rules/api-conventions.md
@import ./.claude/rules/database.md
@import ./.claude/rules/deployment.md
@import ./.claude/rules/security.md

## プロジェクト固有の規約

- 作者には正体中文で返答すること。
- GitHub のイシューリンクなしに `TODO` を含むファイルをコミットしないこと。

モノリシック vs モジュラー — アーキテクトの選択

小さなリポジトリ（単一アプリケーション、1〜2名のエンジニア）は、インポートなしの100行の単一 CLAUDE.md で問題ない。大きなリポジトリ（多くのパッケージとチームを持つモノリポ）は、モノリシックなものがほぼ即座にレビューできなく、ナビゲートできなくなるため、モジュラーパターンをすぐに必要とする。CCA-F はこの判断を日常的に試験する。シナリオが成長するチーム、重複する規約、チーム間の衝突を説明している場合、期待される答えはモノリシックなものを .claude/rules/ ファイルに分割し、@import で接続することだ。

/memory コマンド — 読み込まれたメモリファイルの確認

Claude Code はスラッシュコマンド /memory を公開しており、現在のセッションのメモリに読み込まれている CLAUDE.md ファイルのリスト、それらのパス、および各ファイルがどのスコープに属するかを示す情報を表示する。これは、答えや動作がリポジトリの CLAUDE.md ファイルが示唆するものと一致しない場合にアーキテクトが使う主要な診断ツールだ。

/memory が表示するもの

アクティブな Claude Code セッションで /memory を実行すると、次のような出力が生成される。

Loaded memory files:
  [user]      /Users/jaric/.claude/CLAUDE.md
  [project]   /Users/jaric/work/examlab/CLAUDE.md
  [project]   /Users/jaric/work/examlab/.claude/rules/typescript.md  (imported)
  [project]   /Users/jaric/work/examlab/.claude/rules/testing.md     (imported)
  [directory] /Users/jaric/work/examlab/packages/web/CLAUDE.md

アーキテクトはすぐに以下を確認できる。

• 期待されるユーザーレベルのファイルが読み込まれているかどうか（見つからないか、パスが違う可能性がある）。
• プロジェクトレベルのファイルが読み込まれているかどうか（リポジトリ外で Claude Code を起動した場合は読み込まれない）。
• どの @import ターゲットが解決されたか（存在しないファイルはリストに表示されない）。
• 現在の作業ディレクトリに対してディレクトリレベルのファイルがアクティブかどうか。

一次診断ツールとしての /memory

シナリオ問題が予期しない Claude の動作を説明する場合――「テストに記録した規約に Claude が従っていない」――アーキテクトの最初の動作は /memory を実行してテストルールファイルが実際に読み込まれているかどうかを確認することだ。修正が「指示を追加する」ことではなく「既存の指示をスコープに入れる」ことである場合が多い。

やさしい解説: CLAUDE.md 階層構造

抽象的なスコーピングのルールは、すでに知っている日常的なシステムに固定すると直感的になる。4つの異なる比喩が CLAUDE.md 階層構造の全体像を網羅する。

Analogy 1：厨房 — 個人の好み・店のレシピ・持ち場のルール

3つの層の指示が衝突なく共存する大きなレストランの厨房を想像してほしい。

各シェフがエプロンのポケットに入れて持ち歩く個人ノートは、ユーザーレベルの CLAUDE.md だ。「ソースを少し多めに煮詰める」「出刃包丁より三徳包丁を好む」という個人的な好みや習慣が記されている。誰もこのノートを見ない。シェフは転職しても個人ノートを持っていく。新しい店に入っても、個人ノートが本能を形成する。

パスに固定された店のレシピ本は、プロジェクトレベルの CLAUDE.md だ。店の規約を定義する。「牛肉は客の希望がない限りミディアムレアで調理する」「すべての皿はパスを出る前に亜麻布で拭く」「日替わりスープは週単位でローテーションする」。店のすべてのコックがこの本に従う。新入りは初日に一部を受け取る。

各持ち場の上に貼られたラミネートカードは、ディレクトリレベルの CLAUDE.md だ。魚の持ち場のカードには「すべての魚はフライパンに触れる前に水気を拭き取る」と書かれている。製菓の持ち場のカードには「チョコレートのテンパリングは金属ではなく大理石で行う」と書かれている。これらのカードは店のレシピの上に持ち場固有のルールを追加し、置き換えない。魚担当のコックがグリルに引っ張り出された場合でも、店のミディアムレアのルールに従う。

マッピング：CLAUDE.md 階層構造は、コック（Claude Code）が持ち場（ディレクトリ）で作業を開始するたびに3つの層すべてをマージする。個人ノート（ユーザー）、店の本（プロジェクト）、持ち場のカード（ディレクトリ）がすべて同時に開かれている。

Analogy 2：ドレスコード — 個人のワードローブ・会社の規程・建物の案内

ある日の朝、オフィスビルに到着する場面を想像してほしい。

自宅のクローゼットで今日着るものを決める ― 青いシャツ、チノパン、茶色の靴。これはユーザーレベルの層で、他人からは見えず、どのオフィスでも適用される。

会社の就業規則が層を加える。「午前9時から午後6時の間はビジネスカジュアル」「生産フロアではオープントゥの靴は禁止」「クライアントとの打ち合わせでは会社ブランドのジャケット着用」。これは全従業員に適用され、社員ハンドブックに記載される ― プロジェクトレベルの CLAUDE.md の同等物だ。

特定の部屋のドアの案内板が最後の層を加える。「クリーンルーム ― この先は上履き必着」。就業規則のブランドジャケットはまだ着ており、家で選んだ青いシャツも着ていて、さらに上履きを履く。クリーンルームの案内板はドレスコードを置き換えない。その上に1つの特定のルールを追加する。これがディレクトリレベルの CLAUDE.md だ。

CCA-F でよく見られる間違いは、クリーンルームの案内板が就業規則を置き換えると思い込むことだ。置き換えない。マージは加算的だ。

Analogy 3：参照可能な試験 — 持ち込む参考資料

試験会場に3つの資料の山を机に置いて着席する場面を想像してほしい。

• 個人の学習ノート（ユーザーレベルの CLAUDE.md）は受けるすべての試験に持参する。自分の学習スタイルを反映している ― カラーのマーカー、余白の落書き、記憶術の表。
• このコースに指定された教科書（プロジェクトレベルの CLAUDE.md）はクラスの全員が使う標準的な参考資料だ。共通の語彙を定義する。
• この特定の問題セクション用の補足資料（ディレクトリレベルの CLAUDE.md）はローカルなルールを与える ― 「このセクションでは Runge-Kutta ではなく簡略化したオイラー法を使う」。

問題に答えるとき、3つの山すべてから同時に引用する。各山は次の上に重ねられており、最も具体的なもの（補足資料）が直接の衝突がある場合に上書きする。これが CLAUDE.md 階層構造がセッション開始時にマージする方法そのものだ。

Analogy 4：工具箱 — 個人の工具・工場の規程・作業現場の注意書き

整備士の個人工具箱はどこでも持ち歩く ― ユーザーレベルだ。工場の標準作業手順書がすべての作業ベイの壁に貼られている ― プロジェクトレベルだ。今日の顧客の車のボンネットに貼られた作業現場の注意書き――「この車のエアバッグは作動中。バッテリーを外す前に技術情報 24-A の手順を必ず確認すること」――がディレクトリレベルだ。

整備士は3つすべてを同時に使って作業する。CLAUDE.md 階層構造は Claude Code に対して同じことをする。

CLAUDE.md に入れるもの — 入れないもの

コンテンツを正しいスコープに置くことが半分の戦いだ。

含めるもの

• Claude がすべてのセッションをまたいで知るべき永続的なコンテキスト ― 技術スタック、アーキテクチャの制約、コーディング規約、禁止パターン。
• アーキテクチャの決定のペースで変化する安定したルール（個々のタスクではなく）。
• 多くのファイルにまたがって適用される横断的な規約 ― セキュリティ、ログ、エラーハンドリング。
• 発見の手がかり ― 主要ファイル（src/router.ts）と主要コマンド（pnpm test）へのポインタ。

含めないもの

• シークレット・認証情報・API キー ― CLAUDE.md はプロンプトコンテキストとして読み込まれ、ログに記録される可能性がある。
• タスクごとの指示 ― 「チェックアウトをリファクタリング」はルールではなくプロンプトに属する。
• 揮発性のデータ ― リリースノート、スプリントの TODO；すぐに古くなってコンテキストを汚染する。
• 長文のチュートリアル ― 代わりにドキュメントにリンクを貼る。CLAUDE.md はコンパクトであるべきだ。

チームメンバーのオンボーディング — 典型的な診断パターン

ドメイン3.1 の CCA-F 試験における典型的なパターンの一つが、チームメンバーが指示を受け取れないシナリオだ。問題文で新しいエンジニアがチームに加わり、Claude Code から「期待される動作が見られない」と報告する場合は注意深く読むこと。

シナリオのテンプレート

シナリオは通常次のように書かれている。

あるアーキテクトが Claude Code をチームの React 規約に従うように設定した。アーキテクト自身のセッションは規約に正しく従っている。新しいエンジニアがチームに加わり、リポジトリをクローンして claude を実行した。新しいエンジニアは Claude が規約を無視していると報告した。リポジトリで他に何も変更していない。最も可能性の高い原因は何か？

誤答選択肢には通常以下が含まれる。

• （A）新しいエンジニアは Claude Code クライアントをアップグレードする必要がある。
• （B）規約は Claude が解析できない方法で書かれている。
• （C）規約はオリジナルのアーキテクトのマシンのユーザーレベル（~/.claude/CLAUDE.md）で設定されており、バージョン管理で共有されていない。
• （D）新しいエンジニアはルールを再読み込みするために /memory を実行する必要がある。

正解は（C）だ。診断の連鎖は以下のとおりだ。アーキテクトのマシンで正しい動作が表示され、新しいエンジニアのマシンでは表示されず、他に何も変わっていない場合、指示はアーキテクトとともに移動するがリポジトリとは一緒に移動しない場所に存在しなければならない。その唯一の場所がユーザーレベルの CLAUDE.md だ。

アーキテクトの対処法

修正は指示をユーザーレベルからプロジェクトレベルに移動することだ。

1. ~/.claude/CLAUDE.md から関連するセクションをコピー（または切り取り）する。
2. <repo-root>/CLAUDE.md（またはルートからインポートされた .claude/rules/ 下の専用ファイル）に貼り付ける。
3. バージョン管理にコミットする。
4. 新しいエンジニアに git pull して Claude Code を再起動するよう依頼する。

修正後、両方のエンジニアの /memory 出力でプロジェクトスコープから読み込まれた規約ファイルが表示されるはずだ。

CI/CD 環境での CLAUDE.md — 非インタラクティブなコンテキスト

CCA-F 試験の「継続的インテグレーションへの Claude Code 活用」シナリオクラスターは、ドメイン3.1（CLAUDE.md 階層構造）とドメイン3.6（CI/CD 統合）を定期的に組み合わせる。CI コンテキストでは、Claude Code は非インタラクティブに実行される ― 通常は -p フラグを経由して ― インタラクティブセッションと同じように CLAUDE.md ファイルを読み込む。

CI 環境で変わること

• CI ジョブを実行する OS ユーザーは通常 github-actions のようなボットアカウントなので、~/.claude/CLAUDE.md のユーザーレベルの CLAUDE.md はアーキテクトの個人ファイルではない ― CI ランナーのホームディレクトリに存在するもの（ほとんどの場合は何もない）だ。
• プロジェクトレベルの CLAUDE.md は、CI ランナーがリポジトリをチェックアウトして Claude Code をその中で実行するため、ローカル開発と全く同じように読み込まれる。
• ディレクトリレベルのファイルは同一に機能し、CI ステップの作業ディレクトリにスコープされる。

変わらないこと

• 階層の優先度とマージのルールは、インタラクティブと非インタラクティブのセッション間で変化しない。
• @import の解決は同じように機能する。
• /memory は同じように機能するが、CI は非インタラクティブなため、CI 実行を診断する必要がある場合はスクリプトでメモリ状態をダンプしなければならない。

試験における重要性

CCA-F 問題が「CI 環境の Claude Code がアーキテクトのローカルセッションと同じ規約に従っていない」と説明する場合がある。診断はチームメンバーのオンボーディングパターンを反映する。ローカルのルールはおそらくアーキテクトのマシンのユーザーレベルにある。それをプロジェクトレベルに移動することで、チームメンバーのオンボーディング問題と CI の不一致を1つの変更で修正できる。

よくある試験トラップ — ドメイン3.1 CLAUDE.md 階層構造

CCA-F 試験は CLAUDE.md 階層構造に関連する4つの繰り返すトラップパターンを利用する。それぞれと対応する対策を習得すること。

トラップ1：ディレクトリレベルがプロジェクトレベルを置き換える

最も一般的なトラップだ。選択肢がディレクトリレベルの CLAUDE.md がプロジェクトレベルのファイルを置き換えることを示唆している。そうではない。マージは常に加算的だ。ディレクトリレベルのファイルは上位レベルを補足するだけで、それを無音化できない。

トラップ2：ユーザーレベルのファイルがチームメンバーと共有される

「チームの全員が Claude Code を使っているから、ユーザーレベルの CLAUDE.md に規約を書くだけで十分だ」というディストラクターの主張は誤りだ。ユーザーレベルのファイルは各 OS ユーザーのホームディレクトリに存在し、git 経由で送信されることはない。チームメンバーはそれを見ない。チームメンバーに届く必要がある指示はプロジェクトレベルに属する。

トラップ3：@import パスが絶対またはリポジトリルート基準

@import がリポジトリルートに相対的なパスを解決すると主張するディストラクター。そうではない ― @import はディレクティブを含むファイルに相対的に解決される。ルールファイルを移動した場合、それを指すすべての @import を見直す必要がある。

トラップ4：.claude/rules/ が自動的に読み込まれる

.claude/rules/ 下のファイルが Claude Code によって自動的に読み込まれると主張するディストラクター。そうではない。.claude/rules/ はどこにルールファイルを置くかの規則だ。ファイルは有効な CLAUDE.md チェーンの何かが @import でそれらをインポートする場合にのみ有効になる。チームが @import を接続せずにファイルを .claude/rules/ にドロップすると、/memory でファイルが読み込まれていないことがわかる。

試験当日前に暗記すること

CLAUDE.md 階層構造トピックは暗記すべき小さな事実セットで高い点数が期待できる。

練習アンカー — タスク3.1 シナリオ問題

CLAUDE.md 階層構造に関連する練習問題は、4つの認識しやすい形状にまとまる。各形状は CCA-F がアーキテクトに習得を期待する特定の診断パターンにマップされる。詳細な説明付きの完全バージョンは ExamLab の CCA-F 問題バンクにある。

形状A — チームメンバーのオンボーディング失敗

新しいエンジニアがチームに加わり、リポジトリをクローンして Claude Code を実行し、アーキテクトが書いた規約がアーキテクトのマシンでは正しい動作が見られるにもかかわらず従われていないと報告する。期待される答え：規約は ~/.claude/CLAUDE.md（ユーザーレベル）にあり、バージョン管理で配布するためにプロジェクトレベルのファイルに再配置する必要がある。これが「Claude Code によるコード生成」シナリオの典型的なトラップだ。

形状B — モノリシックな CLAUDE.md がレビューできなくなる

成長するチームが2,500行の単一 CLAUDE.md がプルリクエストでレビューするのが苦痛であり、1つのチームからの変更が別のチームのものと定期的に衝突すると報告する。期待される答え：.claude/rules/*.md ファイルにリファクタリングし、オーケストレーターの CLAUDE.md から @import ディレクティブで接続し、ルールファイルごとに CODEOWNERS を割り当てる。「ルールを削除してファイルを短くする」という誤答選択肢は誤りだ。ルール自体は正しい ― 整理が壊れているからだ。

形状C — CI パイプラインがローカルの規約に従わない

-p フラグを使って Claude Code を実行する CI パイプラインが、アーキテクトがローカルで適用した規約を無視した出力を生成する。期待される答え：規約がアーキテクトのマシンのユーザーレベルにあり、CI ランナーには存在しない。プロジェクトレベルに移動することで、CI とチームメンバーのオンボーディングの両方を1つの変更で修正できる。

形状D — @import ターゲットが読み込まれない

開発者がプロジェクトレベルの CLAUDE.md の先頭に @import ./rules/testing.md を追加したが、/memory でファイルが読み込まれていると表示されず、テストの規約が無視されている。期待される答え：パスはディレクティブを含むファイルに相対的。ファイルが <repo>/rules/testing.md に存在しないか、アーキテクトが ./.claude/rules/testing.md を意図していた可能性がある。/memory を実行することで、どのファイルが読み込まれているかを確認し、壊れたパスを特定できる。

CCA-F の認識深度と上位段階の構築深度

CCA-F は基礎的なアーキテクチャレベルの認定として位置づけられている。ルールの正しいスコーピングを認識し、シナリオの説明から置き違えたファイルを診断し、特定の状況がユーザー・プロジェクト・ディレクトリのどのレベルを呼ぶかを判断できるかどうかを試験する。

上位の Claude Certified Professional と Claude Certified Practitioner プログラムが開始されたとき、構築レベルの深さを試験するだろう ― @import チェーンを含む複雑な .claude/rules/ 階層の作成、カスタムスキルやスラッシュコマンドとの CLAUDE.md マージの統合、メモリファイルの正確性に対する CI バリデーションの記述だ。

CCA-F では、認識と判断のレイヤーに留まること。

• 3つのパスを正確に知る。
• マージが加算的であることを知る。
• ユーザー vs プロジェクトの診断パターンを完全に把握する。
• /memory、@import、.claude/rules/ が何をして何をしないかを知る。

カスタムバリデーションスクリプトを書いたり、10個のファイルにわたって @import の解決を手でトレースしたりしていたら、CCA-F が求めない実装の深みにはまり込んでいる。

CLAUDE.md 階層構造 よくある質問（FAQ）

ユーザーレベル・プロジェクトレベル・ディレクトリレベルの CLAUDE.md の違いは？

ユーザーレベルの CLAUDE.md は ~/.claude/CLAUDE.md に存在し、その OS ユーザーが実行するすべてのセッションに適用され、バージョン管理で共有されない ― マシンに個人的なものだ。プロジェクトレベルの CLAUDE.md はリポジトリルート（または .claude/ 内）に存在し、git にコミットされ、すべてのチームメンバーのリポジトリ内で開かれるすべてのセッションに適用される。ディレクトリレベルの CLAUDE.md はサブディレクトリ内に存在し、git にコミットされ、Claude Code がそのサブツリー内で作業しているときにのみ適用される。CCA-F は特定のルールがどのレベルに属するかの反射的な認識を期待する。

設定した Claude Code の指示が新しいチームメンバーに届かない場合は？

ほぼ確実に、指示が自分の個人マシンの ~/.claude/CLAUDE.md のユーザーレベルの CLAUDE.md にあり、git リポジトリを経由して送信されないためだ。修正は、指示をリポジトリルートのプロジェクトレベルの CLAUDE.md（またはルートからインポートされた .claude/rules/ 下のファイル）に移動し、変更をコミットし、チームメンバーに git pull するよう依頼することだ。これは最も頻繁に試験で問われるドメイン3.1のパターン ― CCA-F のシナリオが「自分のマシンでは動く」と「チームメンバーのマシンでは動かない」を対比させている場合、答えはスコープの不一致だ。

ディレクトリレベルの CLAUDE.md はプロジェクトレベルを置き換えるか？

いいえ。CLAUDE.md 階層構造をまたいだマージは加算的であり、置き換えではない。ディレクトリレベルのファイルはプロジェクトレベルのファイルを補足する。両方がセッション開始時に読み込まれてマージされる。プロジェクトレベルのファイルに「テストには Vitest を使う」と書かれており、サブディレクトリファイルにテストについて何も書かれていない場合でも、そのサブディレクトリ内で Vitest のルールは有効だ。この加算的マージのセマンティクスは最も頻繁に試験で問われるトラップの一つだ。「低レベルが高レベルを置き換える」と説明する選択肢は誤りだ。

@import は CLAUDE.md でどのようにパスを解決するか？

@import <path> はリポジトリルートや現在の作業ディレクトリではなく、ディレクティブを含むファイルに相対的なパスを解決する。packages/web/CLAUDE.md に @import ./rules/components.md が含まれている場合、Claude Code は packages/web/rules/components.md を探す。このルールは忘れやすい ― CCA-F には @import がリポジトリルートから解決すると主張する誤答選択肢が含まれることが多い。「それをインポートするファイルに相対的」を暗記すること。

.claude/rules/ ディレクトリとは何か、Claude Code はそこのファイルを自動的に読み込むか？

.claude/rules/ はルートの CLAUDE.md が @import でインポートする集中した Markdown ルールファイルのコミュニティ規則ホームだ。Claude Code は .claude/rules/ 内のファイルを自動的に読み込まない ― 有効な CLAUDE.md チェーンの何かがそれらをインポートする場合にのみ有効になる。.claude/rules/ にファイルをドロップして対応する @import を追加しない場合、ファイルは何もしない。これは CCA-F のトラップパターンだ。.claude/rules/ が「自動読み込み」と説明する誤答選択肢は誤りだ。

/memory コマンドは何をするもので、いつ使うべきか？

/memory は Claude Code のスラッシュコマンドで、現在セッションに読み込まれているすべての CLAUDE.md ファイルをスコープ（ユーザー・プロジェクト・ディレクトリ）および @import でプルされたファイルとともにリストアップする。Claude の動作が CLAUDE.md ファイルに書かれていることと一致しない場合の一次診断ツールとして使用すること。根本原因はファイルがまったく読み込まれていないこと（パスが違う、@import ターゲットが欠落、またはリポジトリ外から Claude Code が起動された）であることが多く、規約の書き方の問題ではない。CCA-F で「ルールが無視されている」と書かれているシナリオに遭遇したら、まずルールが読み込まれているかどうかを考えること。

CLAUDE.md に含めるべきもの、含めないものは？

永続的なコンテキストを含める ― すべてのセッションにまたがって適用されるもの：技術スタックの宣言、コーディング規約、アーキテクチャの制約、禁止パターン、主要ファイルとコマンドへのポインタ。シークレットと認証情報は含めない（ファイルはプロンプトコンテキストとして扱われ、git にコミットされることが多い）。タスクごとの指示は含めない ― 会話プロンプトまたはカスタムスラッシュコマンドに属する。揮発性のデータは含めない ― リリースノート、スプリントの目標、チケットの説明はすぐに古くなる。CCA-F はこの判断を頻繁に試験する。シナリオが短期的なタスクメモについて言及している場合、正しいスコープはプロンプトであり CLAUDE.md ではない。

参考文献

• CLAUDE.md 設定 ― Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Claude Code 機能概要: https://docs.anthropic.com/en/docs/claude-code/overview
• Claude Code 設定リファレンス: https://docs.anthropic.com/en/docs/claude-code/settings
• Claude Code を CI/CD パイプラインに統合する: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• カスタムスラッシュコマンドとスキル: https://docs.anthropic.com/en/docs/claude-code/slash-commands
• Claude Certified Architect Foundations ― ローンチ発表: https://www.anthropic.com/news/claude-certified-architect
• CCA-F 試験ガイド PDF: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf

関連 ExamLab トピック：カスタムスラッシュコマンドとスキル、パス固有のルールと条件付き規約の読み込み、Plan Mode vs 直接実行、Claude Code への MCP サーバー統合、ビルトインツールの選択と適用。