配点2位のドメイン。CLAUDE.md の階層、スキルとコマンド、plan mode、CI統合——毎日 Claude Code を使っている人ほど「いつも見ている光景の言語化」で得点できる。この章は「導入レッスン（設定のしくみを地図として理解する）」→「タスクステートメント3.1〜3.6」→「演習」→「章末ミニクイズ」の順で、この1ページだけで Domain 3 の学習が完結する。
先に第1章を終えておくこと。この章は「エージェントループ」「サブエージェント」「コンテキスト」といった第1章の語彙を前提に書いてある。基礎用語に迷ったら準備章のことば図鑑へ。
第1章で「AIとの通信は手紙のやりとり」だと学んだ。Claude Code はその手紙に、毎回自動で「指示書」を同封してくれる仕組みを持っている。それが CLAUDE.md（クロード・エムディー。プロジェクトの約束事を書いておくテキストファイル）だ。ここで大事なのは、指示書の置き場所が3つあり、置き場所によって「誰に効くか」が変わること。
| 階層 | 場所 | 効く範囲 |
|---|---|---|
| ユーザー階層 | ~/.claude/CLAUDE.md（自分のホームフォルダ） | 自分だけ。gitで共有されない＝チームメイトには届かない |
| プロジェクト階層 | .claude/CLAUDE.md かリポジトリのルート直下 | チーム全員。clone/pull すれば全員の Claude Code が読む |
| ディレクトリ階層 | サブフォルダごとの CLAUDE.md | そのフォルダで作業するときだけ |
たとえて言うなら、ユーザー階層は自分の手帳、プロジェクト階層は職場の掲示板、ディレクトリ階層は部屋ごとの注意書き。試験の定番トラブル「新メンバーの Claude Code にチーム標準が効かない」の原因は、掲示板に貼るべき指示を自分の手帳に書いてしまったこと（＝ユーザー階層は git 共有されない）。答えは常に「プロジェクト階層へ移す」だ。
あわせて覚える3点：
/memory コマンド：セッション内で打つと「いまどのメモリファイルが読み込まれているか」を一覧できる。「設定が効かない」と思ったら、Claudeの不具合を疑う前にどの階層に書いたかをこれで診断する@import 構文：CLAUDE.md から外部ファイルを参照して取り込める。巨大な一枚岩の CLAUDE.md をトピック別に分割整理するための機能。ただし読み込まれた分のトークン（AIが読む文章量の単位）は普通に消費する——圧縮の魔法ではなく、あくまで整理と選択的読み込みの道具.claude/rules/ ディレクトリ：規約をトピック別ファイル（testing.md、api-conventions.md…）に分割して置く場所。さらに各ファイルの先頭に条件を書くと「特定のファイルを編集するときだけ読み込む」ことができる（→ 3.3 で詳しく）自分のマシンで実物を見ておくと記憶が固まる（10分）：
# 自分の環境の3階層を目で見る
ls -la ~/.claude/CLAUDE.md # ① ユーザー階層（自分専用・git共有されない）
ls -la ~/.agent/CLAUDE.md # ② プロジェクト階層（リポジトリ内・共有される）
ls -la ~/.agent/rules/ # ③ ルール分割（.claude/rules/ 方式の実物）
# いま何が読み込まれているか（試験に出るコマンド）
# Claude Code のセッション内で:
/memoryCLAUDE.md が「毎回同封される指示書」だとすると、スキル／カスタムコマンドは「呼んだときだけ届く手順書」。デプロイ手順・レビュー観点のような定型手順を1ファイルにまとめておき、必要な場面で起動する。置き場所のルールはレッスン1と同じ発想で、チーム共有＝プロジェクトの .claude/commands/・.claude/skills/（git で全員に配布される）、個人用＝~/.claude/ 側だ。
スキルの本体は SKILL.md というファイルで、その先頭の frontmatter（フロントマター。ファイル冒頭に書く設定欄）に試験に出る設定が3つある。
| 設定 | 意味 | 典型的な出題シーン |
|---|---|---|
context: fork | スキルを隔離された子コンテキストで実行する（大量の出力が本会話を汚さない） | 「コードベース解析のような冗長な出力を出すスキルはどう設定？」 |
allowed-tools | スキル実行中に使えるツールを制限する | 「破壊的操作をさせたくないスキルには？」 |
argument-hint | 引数なしで起動されたとき、必要なパラメータの入力を促す | 「引数必須のスキルで入力漏れを防ぐには？」 |
もう1つの頻出論点が「スキルに書くか、CLAUDE.md に書くか」の選択。切り分けはシンプルで、オンデマンドで呼ぶタスク特化の手順はスキル、常時適用したい普遍的な標準は CLAUDE.md。「毎回の会話で守ってほしいコーディング規約」をスキルにすると起動し忘れるし、「月1回のリリース手順」を CLAUDE.md に書くと毎回のトークンを無駄に食う。チームのスキルを自分好みに変えたいときは、チームのファイルをいじらず ~/.claude/skills/ に別名の変種を作る（チームに影響させない）。
Claude Code には「いきなり工事を始める」モードと、「先に現地調査をして、見積もりを施主に承認してもらってから工事する」モードがある。後者が plan mode（プランモード）：ファイルの読み取りだけを許して探索・設計させ、計画を人間が承認してから実装に移る。
試験でこのテーマが出るときの急所は1つ：「複雑さが最初から要件に書いてあるのに、直接始めて、複雑になったら plan mode に切り替えよう」という選択肢は誤答。現地調査をせずに基礎を掘り始めてから「配管があった、どうしよう」と言うのでは遅いのと同じで、複雑さが見えているなら最初から調査モードで入る。
CI/CD（継続的インテグレーション／デリバリー。push のたびにテストやレビューを自動実行する仕組み）の中で Claude Code を動かすと、「PR（プルリクエスト）に自動でレビューコメントを付ける」のような無人運用ができる。ここで絶対に外せないのが、無人の場所では「質問して答えを待つ」ことができないという制約だ。
claude -p "…"（--print）：プロンプトを処理し、結果を標準出力に出して終了する非対話モード。これを付けないと、Claude が入力待ちになった瞬間に CI ジョブが永久にハングする。CI 統合の第一歩にして鉄則--output-format json ＋ --json-schema：出力を機械可読な構造化データ（決めた形の JSON）に強制する。後段のスクリプトが結果をパースして「PR へ自動インラインコメント投稿」のような処理につなげられる誤答の作られ方も知っておくと強い。CI 非対話化の問題では「CLAUDE_HEADLESS=true 環境変数」「--batch フラグ」のような実在しない機能がもっともらしく並ぶ。正解は -p 一択。
~/.claude/CLAUDE.md・自分専用）→ プロジェクト（.claude/CLAUDE.md かルート直下・チーム共有）→ ディレクトリ（サブフォルダごと）。「チームに効かせたい指示がユーザー階層に書かれている」が典型トラブル。@import 構文で外部ファイルを参照し、CLAUDE.md をモジュール化する（パッケージごとに関係する規約ファイルだけ読み込む）.claude/rules/ ディレクトリでトピック別ファイル（testing.md, api-conventions.md…）に分割する/memory コマンドで「いまどのメモリファイルが読み込まれているか」を確認し、セッション間の挙動ブレを診断するこの構成そのものを運用中：~/.claude/CLAUDE.md（ユーザー・グローバル設定）＋ ~/.agent/CLAUDE.md（プロジェクト）＋ rules/ 26ファイル（トピック別分割）。⚠️実務メモ: feedback-claude-code-import-misconception「@import はcontext削減効果なし（読み込まれれば消費は同じ）」——@importの利点は整理と選択的読み込みであって魔法の圧縮ではない、という理解が正確。
.claude/commands/（プロジェクト・git共有）、個人用は ~/.claude/commands/。スキル（SKILL.md）には frontmatter で fork実行・ツール制限・引数ヒントを設定できる。.claude/commands/（clone/pullで全員に配布）vs user の ~/.claude/commands/（個人）——サンプル問題Q4はこの一択問題context: fork（隔離された子コンテキストで実行し、冗長な出力が本会話を汚さない）／allowed-tools（スキル実行中のツール制限＝破壊的操作の防止）／argument-hint（引数なし起動時に必要パラメータを促す）~/.claude/skills/ に別名の変種を作る（チームに影響させない）129本のスキル運用と rules/extension-layer-decision.md の6問フローチャート（「毎セッション必要→CLAUDE.md、オンデマンド手順→Skills」）が、まさに最後の選択基準の実装。rules/skill-tier.md（T0/T1/T2品質保証）は試験範囲外だが、スキル濫造を防ぐ運用として上位互換。
.claude/commands/（Q4。config.json方式は存在しない機能）context: fork で隔離が正解.claude/rules/ のYAML frontmatter に paths: ["**/*.test.*"] のようなglobパターンを書くと、該当ファイル編集時だけルールが発動し、無関係なコンテキスト消費を減らせる。まず glob（グロブ）とは、* のようなワイルドカード（何にでも一致する記号）でファイル名の集合を指す記法のこと。**/*.test.* なら「どのフォルダにあっても、名前に .test. を含むファイル全部」。ルールファイルの先頭にこの条件を書いておくと、Claude Code は一致するファイルを編集するときだけそのルールを読み込む。全ルールを毎回同封する必要がなくなり、トークンの節約になる。
「ディレクトリ別 CLAUDE.md」との使い分けはこう考える：ディレクトリ CLAUDE.md は住所で配る回覧板（その町内にいる人にだけ届く）、paths 付きルールは職種で配る社内報（どの支社にいても営業職なら届く）。テストファイルのようにコードベース全体に散らばっている同種ファイルに規約を当てたいなら、住所ベースでは追いきれない——場所ではなくファイルの種類で判定する glob ルールが正解になる。逆に「このフォルダの中だけの約束事」なら、ディレクトリ CLAUDE.md で足りる。
試験が問うことpaths frontmatter による条件付きルール読み込みの仕組みと、コンテキスト（トークン）節約効果paths: ["src/api/**/*"] でAPI規約、paths: ["**/*.test.*"] でテスト規約——場所でなくファイルの種類で規約を当てる2026-05の rules-optimization で path-scoped 化を実施済み（232行削減）。「常時ロードすべきか、パスで絞れるか」の判断を実際にやった経験がそのまま答案になる。ただし全rulesをpath化しても大きく減らなかった（3829→3804行）という限界も体験済み——「pathsは万能の圧縮ではなく、対象が明確なルールにだけ効く」という肌感は試験でも正しい。
判断基準は導入レッスン3の3条件——①大規模（数十ファイル）／②複数の正解がありうる／③アーキテクチャ判断を含む——のどれかに当てはまるかどうか。1つでも当てはまるなら、いきなり書き始めず、まず読み取り専用で構造を調査し、計画を人間に承認してもらってから実装する。どれにも当てはまらない明確な小修正（エラー箇所が特定済みのバグ修正など）は、plan mode を挟むだけ時間の無駄なので直接実行でよい。「迷ったら要件文を読み直す」が実戦のコツで、要件に複雑さが書いてある（45ファイル、複数方式の比較、決済モジュール…）のに直接始める選択肢は誤答と機械的に判定できる。
試験が問うことrules/impact-assessment.md のリスク判定がこの上位互換：LOW→直接実装 / MEDIUM→/plan→/implement / HIGH・CRITICAL→/research→/plan→レビュー→/implement。試験の「complexity assessment」を、依存ファイル数とクリティカルパスで定量化した運用。Explore サブエージェントも日常使用。
このタスクステートメントは「1回で完璧な指示を書く」のをやめ、Claude とのやりとりを設計する技術を問う。4つのテクニックを、それぞれ具体的な場面で理解しておく。
① 具体例駆動。「顧客データの移行スクリプトで、空欄は適切に処理して」と散文で頼むと、実行のたびに解釈が変わる——あるときは空文字を入れ、あるときは行ごと捨てる。こういうとき説明文をさらに書き足すより、入出力の具体例を2〜3個見せる方が効く：「電話番号が空 → "未登録" を入れる」「生年月日が空 → その行はスキップしてログに残す」「メールが空 → エラーで止める」。新人への引き継ぎで、10分の口頭説明より記入済みのサンプル1枚が正確に伝わるのと同じ理屈。散文の仕様が一貫して解釈されないときの第一手は、説明の増量ではなく例示だ。
② テスト駆動の反復。実装を頼む前に、期待する挙動・エッジケース（境界の意地悪な入力）・性能要件をテストコードとして先に書いておき、「このテストが全部通るまで直して」と失敗一覧を共有しながら段階的に改善させる。採点基準を先に配ってから答案を書かせるイメージで、「できました」の自己申告ではなくテストの合否という機械的な物差しで反復が回る（第1章で学んだ「自然言語は信用できない、フラグで判定する」と同じ思想の応用）。
③ インタビューパターン。自分が不慣れな領域（初めてのキャッシュ層導入など）では、そもそも仕様を書き切れない。このときは実装を頼む前に「実装に入る前に、設計上確認すべきことを私に質問して」と Claude 側から質問を出させる。すると「キャッシュの無効化はどのタイミングで？」「キャッシュサーバーが落ちたときは素通しでよい？」のような、自分が想定していなかった論点が先に表面化する。寿司屋で「おまかせ」と言う前に、職人の方から「苦手なネタは？量は？」と聞いてもらう構図。
④ 一括 vs 逐次。複数の問題を直させるとき、出し方は2通りある。問題同士が相互作用する（1つ直すと別の箇所の挙動が変わる）なら、全部の問題と関係性を1つの詳細なメッセージにまとめて渡す——1個ずつ出すと「直すたびに別の場所が壊れる」もぐら叩きになるからだ。逆に問題が互いに独立なら、1件ずつ順番に出して各修正を確認しながら進める方が確実。判断軸は「問題の間に依存関係があるか」の一点。
試験が問うことインタビューパターンは rules/communication.md の「インタビュー形式（曖昧さが多いタスクで一問ずつ、アーキテクチャが変わる質問を優先）」として運用済み。テスト駆動は tdd-workflow スキル。「相互作用する問題は一括で」は、複数バグ修正依頼の日常運用と同じ。
claude -p "…"（--print＝非対話モード）が鉄則。対話待ちでジョブが永久にハングするのを防ぐ。構造化した結果が欲しければ --output-format json ＋ --json-schema。-p/--print：プロンプトを処理して結果をstdoutに出して終了する非対話モード（サンプル問題Q10。CLAUDE_HEADLESS環境変数や--batchフラグは存在しない機能として誤答に配置される）--output-format json ＋ --json-schema：CIでの機械可読な出力の強制→PRへの自動インラインコメント投稿などに使う「生成者と検証者を分ける」は rules/audit-independence.md（盲検・独立コンテキスト・Generator-Evaluator分離）の中核思想と完全一致。週次調査ルーチン（GitHub Actions）は headless 運用の実例。CLAUDE.md の「無人実行時は AskUserQuestion 禁止」ルールも同じ問題意識（対話待ちハング）。
-p（Q10）Anthropic 公式の無料学習サイト Claude Academy（2026-08-20 公開、/ja/ で日本語版）のうち、第2章（ドメイン3: Claude Code の設定）に対応するレッスン。Claude Code 101 → 実践Claude Code → エージェントスキル入門 の3本が、この章の設定3階層・スキル・plan mode・CI をほぼ同じ順番で扱う。使い方は「この章を読み終えてから、同じテーマを公式がどう説明しているかを確かめる」の一方向。先に公式を読む必要はない。レッスン本文の閲覧には無料アカウントでのサインインが必要。
この章で使うコース: Claude Code 101 / 実践Claude Code / エージェントスキル入門
| この章の項目 | 対応する公式レッスン |
|---|---|
| 導入レッスン1 設定ファイルの地図 | Claude Code 101 › Claude Codeの仕組み Claude Code 101 › The CLAUDE.md file |
| 3.1 CLAUDE.md の階層とモジュール化 | Claude Code 101 › The CLAUDE.md file 実践Claude Code › A CLAUDE.md that follows |
| 3.2 カスタムコマンドとスキルの作成 | エージェントスキル入門 › スキルとは エージェントスキル入門 › 最初のスキルを作成する エージェントスキル入門 › スキルと他のClaude Code機能の比較 エージェントスキル入門 › スキルの共有 Claude Code 101 › Skills |
| 3.3 パス限定ルール（paths 指定） | エージェントスキル入門 › 設定と複数ファイルスキル paths 付き rules を直接扱うレッスンは無い。「どの設定がいつ読まれるか」の感覚を補う用途で。 |
| 3.4 plan mode vs 直接実行 | Claude Code 101 › 探索 → 計画 → コード → コミットのワークフロー 実践Claude Code › Permission modes |
| 3.5 反復改善のテクニック | 実践Claude Code › Verification skills 実践Claude Code › Steering long sessions Claude Code 101 › コードレビュー |
| 3.6 CI/CD パイプラインへの統合 | 実践Claude Code › Routines and headless 実践Claude Code › GitHub Actions and Code Review 実践Claude Code › Trust it: Verifying unsupervised runs |
| 深掘り（任意・出題範囲の周辺） | 実践Claude Code › Plugins エージェントスキル入門 › スキルのトラブルシューティング |
対応付けはレッスン題名とコース説明文から行った（2026-08-25 時点）。レッスン本文までは精査していないので、読んでみて「この章の項目とずれている」と感じたら、その節は公式を優先せずこの章の記述で答える（試験ガイドのタスクステートメントに合わせて書いてあるため）。
この章の演習はコードを書かない。設定ファイルを置いて、効き方が変わるのを目で見るのが目的だ。Claudeに「c2演習やる」と言えば伴走してもらえる。新規の練習用リポジトリを1つ作ってやるのが安全（本物の ~/.agent/ は触らない）。
~/.claude/CLAUDE.md（ユーザー）との効き方の違いを1つの指示で確認する。/memory でどちらが読み込まれているかも見る（→3.1の体験）.claude/rules/test-style.md に paths: ["**/*.test.*"] を付け、テストファイル編集時だけ発動する（普通のファイル編集では発動しない）ことを確認する（→3.3の体験）context: fork + allowed-tools 付きのスキルを1本作り、大量の出力を出させても本会話が汚れないことを確認する（→3.2の体験）余裕があれば3.5も体験できる：わざと曖昧な散文（「空欄はいい感じに処理して」）で小さなスクリプトを頼み、解釈がブレるのを見てから、入出力例2〜3個を渡して直る様子を観察する。説明を100回読むより、ブレた出力を1回見る方が記憶に残る。
ユーザー階層（~/.claude/・個人にだけ効く・git共有されない）→ プロジェクト階層（リポジトリ内・チーム共有）→ ディレクトリ階層（サブフォルダ限定）。「誰に効かせたいか」で置き場所を決める。
CLAUDE.md から外部ファイルを参照して取り込む構文。モジュール化・選択的読み込みのための機能で、読み込んだ分のトークンは普通に消費する（圧縮ではない）。
Markdownファイルの冒頭に書く設定欄（YAML形式）。ルールファイルなら paths、SKILL.md なら context / allowed-tools / argument-hint をここに書く。「本文の前に付ける荷札」のイメージ。
*（何でも1区間）や **（何階層でも）のワイルドカードでファイル名の集合を指す記法。**/*.test.*＝「どこにあっても名前に .test. を含むファイル全部」。paths 指定の中身。
トピック別ルールファイルの置き場。YAML frontmatter の paths: ["glob"] を書くと、一致するファイルを編集するときだけルールが読み込まれる（条件付きロード）。
SKILL.md frontmatter の3設定。fork=隔離コンテキストで実行（冗長出力が本会話を汚さない）、allowed-tools=スキル実行中のツール制限、argument-hint=引数なし起動時の入力促し。
実行前に読み取り専用で探索・設計し、計画を承認してから実装に移るモード。大規模・多ファイル・アーキテクチャ判断を含むタスク用。小さな明確な修正には過剰。
冗長なコードベース探索を隔離コンテキストで行い、要約だけを本会話に返す読み取り専用の子エージェント。長時間タスクのコンテキスト枯渇対策。
CI/CD用のCLIフラグ。-p=非対話モードで処理して終了（ハング防止）、--output-format json + --json-schema=構造化された機械可読出力の強制。
実装前にClaudeの側から設計上の質問を出させ、開発者が想定していない考慮点（キャッシュ無効化・障害モード等）を表面化させる手法。
本番形式の4択。4問がこの章（D3）、1問が第1章（D1）の復習。総合模試（quiz.html）が3.1・3.3・3.6を出題済みなので、ここでは3.2・3.4・3.5を重点的に出す。間違えても気にしない——間違えた瞬間が一番記憶に残るタイミング。