Domain 3: Claude Code Configuration & Workflows
配点 20% — Task 3.1〜3.6
3.1 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.mdpaths: と globs: の関係
公式ドキュメントは paths: を使う例を示していますが、コミュニティでは globs: の方が確実に動作するケースが報告されています。試験では paths: が正解 として扱われる可能性が高いですが、実装で動作しない場合は globs: を試してください。
3.2 カスタムコマンドと Skills
| Skill フロントマター | 正しい効果 | 使いどころ |
|---|---|---|
context: fork | 独立したサブエージェントで実行。メインのコンテキストを汚染しない | 大量出力を生成する Skill・コードベース探索 |
allowed-tools | 指定したツールに対する事前承認(プロンプト省略のための pre-approval)。他ツールをブロックする機能ではない。実際にツールをブロックしたい場合はプロジェクトの permissions.deny を使う | Skill が特定ツールを頻繁に使うとき、毎回承認プロンプトを出さないようにする |
argument-hint | / オートコンプリートメニューに表示される表示専用のヒント文字列。パース動作には影響しない。入力を強制する機能でもない | argument-hint: "[issue-number]" のように、引数の意味をユーザーに示す |
disable-model-invocation | Claude が自動的にこの Skill を呼ぶことを防ぐ。ユーザーが /skill-name で明示的に呼んだときだけ実行 | デプロイ・コミットなど副作用のある Skill |
user-invocable: false | / メニューから隠す(Claude は自動ロード可能) | 背景知識として使うリファレンス系 Skill |
model | Skill 実行中に使うモデル(haiku / sonnet / opus / inherit) | 軽量タスクを Haiku に振ってコスト削減 |
agent | context: fork と組み合わせて、特定のサブエージェントタイプ(例: Explore)で実行 | 探索系タスクを Explore agent に委譲 |
allowed-tools の誤解
「allowed-tools は Skill 実行中のツールを制限する」というのは誤りです。allowed-tools は「これらのツールについて事前承認を与える」機能であり、ブロック機能ではありません。allowed-tools: [Read, Grep] と書いても、Skill は Bash や Write を使えてしまいます。実際にブロックしたい場合は、プロジェクトの .claude/settings.json で permissions.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 | セッション終了時 / サブエージェント終了時 | クリーンアップ・通知 |
Notification | Claude 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" }
]
}
]
}
}試験頻出:「フォーマッター実行」をどこに書くか
「保存後に自動で 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 点
-pフラグ:必須。なければパイプラインがハング- 独立インスタンス:生成したコードを同じセッションでレビューさせない(認知バイアス)
- CLAUDE.md:テスト基準・レビュー基準・利用可能な fixture を文書化して CI 品質を向上