Skip to Content
本サイトは Anthropic, PBC と関係のない非公式の学習ガイドです。
D3: Claude Code (20%)

Domain 3: Claude Code Configuration & Workflows

配点 20% — Task 3.1〜3.6

3.1 CLAUDE.md 設定階層

図3-1: CLAUDE.md の 4 層階層とスコープ
① ユーザーレベル(グローバル)~/.claude/CLAUDE.mdバージョン管理外・全プロジェクト適用② プロジェクトレベル(チーム共有).claude/CLAUDE.md または ルート CLAUDE.mdgit管理・チーム共有③ プロジェクトローカル(個人 override).claude/CLAUDE.local.md または ルート CLAUDE.local.md.gitignore対象・個人設定④ ディレクトリレベル(サブツリー適用)subdirectory/CLAUDE.mdそのディレクトリ以下に適用
⚠️

頻出の罠:新メンバーが設定を受け取れない

~/.claude/CLAUDE.md(ユーザーレベル)はバージョン管理に含まれないため、新しいチームメンバーが clone しても適用されません。チーム全員に適用したい設定は .claude/CLAUDE.md(プロジェクトレベル)に置く必要があります。

一方、CLAUDE.local.mdプロジェクト固有だが個人にだけ必要な設定(自分のローカル環境のパス・個人 MCP サーバー・実験中の指示など)を入れる場所です。.gitignore に自動追加されるためチームを汚染しません。

CLAUDE.md のモジュール化オプション

方法構文/場所用途・利点
@ パス参照@./standards/api.md または @README.md外部ファイルを参照してモジュール化。読み込み時にインライン展開(最大 5 階層の再帰)。「@import」というキーワードは不要、シンプルに @ で始める
.claude/rules/YAML フロントマター paths:globs: も使用可)glob パターンで条件付きロード。該当ファイル読み込み時に rule 内容が会話に注入される(“first-match-wins” attach pattern)
# .claude/rules/testing.md — テストファイルにのみ適用されるルール --- paths: - "**/*.test.tsx" - "**/*.spec.ts" --- テストはAAA(Arrange-Act-Assert)パターンで書くこと 既存のテストと重複するシナリオは追加しないこと # プロジェクトルートの CLAUDE.md から外部ファイルを参照する例 # (@import ではなく @ だけで参照する) @README.md @./docs/architecture.md @./standards/api-conventions.md
📌

paths:globs: の関係

公式ドキュメントは paths: を使う例を示していますが、コミュニティでは globs: の方が確実に動作するケースが報告されています。試験では paths: が正解 として扱われる可能性が高いですが、実装で動作しない場合は globs: を試してください。

3.2 カスタムコマンドと Skills

図3-2: コマンド・Skills のスコープとフロントマターオプション
プロジェクトスコープ(チーム共有).claude/commands/スラッシュコマンド(バージョン管理).claude/skills/SKILL.md + frontmattercontext: fork / allowed-tools / argument-hintユーザースコープ(個人)~/.claude/commands/個人コマンド(非共有)~/.claude/skills/個人 Skill カスタマイズチームに影響を与えず個人設定可能
Skill フロントマター正しい効果使いどころ
context: fork独立したサブエージェントで実行。メインのコンテキストを汚染しない大量出力を生成する Skill・コードベース探索
allowed-tools指定したツールに対する事前承認(プロンプト省略のための pre-approval)。他ツールをブロックする機能ではない。実際にツールをブロックしたい場合はプロジェクトの permissions.deny を使うSkill が特定ツールを頻繁に使うとき、毎回承認プロンプトを出さないようにする
argument-hint/ オートコンプリートメニューに表示される表示専用のヒント文字列。パース動作には影響しない。入力を強制する機能でもないargument-hint: "[issue-number]" のように、引数の意味をユーザーに示す
disable-model-invocationClaude が自動的にこの Skill を呼ぶことを防ぐ。ユーザーが /skill-name で明示的に呼んだときだけ実行デプロイ・コミットなど副作用のある Skill
user-invocable: false/ メニューから隠す(Claude は自動ロード可能)背景知識として使うリファレンス系 Skill
modelSkill 実行中に使うモデル(haiku / sonnet / opus / inherit軽量タスクを Haiku に振ってコスト削減
agentcontext: fork と組み合わせて、特定のサブエージェントタイプ(例: Explore)で実行探索系タスクを Explore agent に委譲
🔴

allowed-tools の誤解

allowed-tools は Skill 実行中のツールを制限する」というのは誤りです。allowed-tools は「これらのツールについて事前承認を与える」機能であり、ブロック機能ではありませんallowed-tools: [Read, Grep] と書いても、Skill は BashWrite を使えてしまいます。実際にブロックしたい場合は、プロジェクトの .claude/settings.jsonpermissions.deny を設定してください。試験で「allowed-tools で危険な操作をブロック」という選択肢が出たら 誤答 です。

💡

CLAUDE.md vs Skills の使い分け

  • CLAUDE.md: 常時ロードされる普遍的な標準・コーディング規約(always-loaded)
  • Skills: 特定タスクのオンデマンド実行(/skill-name で呼び出す)
  • .claude/rules/: ファイルパス別の条件付きロード(該当ファイル編集時のみ)

3.3 Claude Code フック(lifecycle hooks)

Claude Code の hooks はライフサイクルイベントで決定論的にコマンドを実行する仕組みです。これは Agent SDK の PostToolUse フック(D1.5)とは別物。Claude Code の hooks は .claude/settings.json または .claude/hooks/ ディレクトリで定義します。

イベント発火タイミング典型的な用途
PreToolUseツール実行 。コマンドが 0 以外で終了するとツール実行をブロック危険コマンド検査・lint チェック・git status の確認
PostToolUseツール実行 。結果を変換・追加処理編集後の自動 format・テスト実行・結果ログ
UserPromptSubmitユーザープロンプト送信時追加コンテキストの注入・プロンプトの監査
Stop / SubagentStopセッション終了時 / サブエージェント終了時クリーンアップ・通知
NotificationClaude Code が通知を発する時外部システム連携(Slack 通知など)
// .claude/settings.json — PostToolUse フックで Edit 後に自動 format { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx prettier --write $CLAUDE_FILE_PATHS" } ] } ], "PreToolUse": [ { "matcher": "Bash", "hooks": [ { "type": "command", "command": "./scripts/security-check.sh" } ] } ] } }
🔑

Claude Code Hooks vs Agent SDK Hooks の混同に注意

試験では両方が出てくるが、それぞれ用途が違う:

  • Agent SDK HooksD1.5): API 経由でエージェンティックループを構築する際に使う。messages.create の前後でのデータ変換・ポリシー強制
  • Claude Code Hooks(D3.3): Claude Code CLI のライフサイクルに介入。エディタ操作の自動化・チーム開発フローの強制

どちらも「決定論的な保証が必要なときに使う」という 3 原則 #1 と整合する点は共通。

⚠️

試験頻出:「フォーマッター実行」をどこに書くか

「保存後に自動で prettier を走らせたい」→ CLAUDE.md に「フォーマットして」と書くのは誤答(プロンプト指示は非ゼロ失敗率)。正解は PostToolUse hook でマッチャー Edit|Write を設定し、コマンドで実行すること。

3.4 Plan mode vs Direct execution

Plan mode を選ぶ場面(試験頻出)Direct execution を選ぶ場面
複数ファイルにまたがる大規模変更単一ファイルのバグ修正(明確なスタックトレースあり)
複数の有効なアプローチが存在1 関数への条件追加
アーキテクチャ上の決定が必要スコープが明確な変更
マイクロサービス分割・45+ ファイルのライブラリ移行
→ 変更前にコードベースを安全に探索・設計→ オーバーキルになるので Plan mode は不要

3.5 反復改善テクニック(Academy コンテンツ)

テクニック説明使いどころ
具体的な I/O 例2〜3 個の入力 → 出力例を提示自然言語説明が一貫性のない結果を生む場合
テスト駆動反復先にテストスイートを書いて、テスト失敗を共有しながら改善実装の品質を客観的に測定したい場合
インタビューパターン実装前に Claude に質問を促して設計考慮事項を表出させる未知のドメインでキャッシュ無効化・失敗モードを発見
並行 vs 順次フィードバック相互作用する問題 → まとめて報告。独立した問題 → 順次修正複数の問題が存在する場合の最適な報告方法

3.6 CI/CD パイプライン統合

# ① 非インタラクティブモード(-p フラグ必須) claude -p "Analyze this PR for security issues" # ② 構造化JSON出力でPRコメント自動投稿 claude -p "Review this code" \ --output-format json \ --json-schema review-schema.json # ③ 独立したインスタンスでコードをレビュー(同じセッションは使わない) claude -p "Review: $(git diff HEAD~1)" # ❌ 存在しないフラグ(試験の誤答選択肢): # CLAUDE_HEADLESS=true, --batch フラグ → どちらも存在しない
🔑

CI/CD で重要な 3 点

  1. -p フラグ:必須。なければパイプラインがハング
  2. 独立インスタンス:生成したコードを同じセッションでレビューさせない(認知バイアス)
  3. CLAUDE.md:テスト基準・レビュー基準・利用可能な fixture を文書化して CI 品質を向上
Last updated on