Claude Code Configuration & Workflows

ドメインの位置付け

Claude Code Configuration & Workflows は CCAF 5ドメイン中で20% を占めるドメインです。 公式ページに記載された範囲としては、「CLAUDE.md 階層の構成」「カスタムスラッシュコマンド」 「path-specific rules」「Plan mode と direct execution の使い分け」が中心トピックです。

Claude Code を日常的に業務で使っている人にとっては、最も馴染みのある領域。 ただし「公式が想定する用語と構造」を正確に押さえる必要があります。 Fyveでも日々使ってきた領域ですが、改めて公式用語の整理が試験対策には不可欠です。

このドメインで扱う技術概念

CLAUDE.md の階層構造

Claude Code は CLAUDE.md ファイルを3階層で読み込みます:

• User-level: ~/.claude/CLAUDE.md — そのユーザー全体に適用
• Project-level: .claude/CLAUDE.md または CLAUDE.md — プロジェクト全体
• Directory-level: サブディレクトリ内の CLAUDE.md — そのディレクトリ配下のみ

User-level は version control 対象外なので、チームには共有されません。 Project-level に書いたものだけがチーム共有設定として機能します。 この区別が問われやすいポイントです。

@import 構文

CLAUDE.md は @import 構文で他のmdファイルを参照可能。 巨大な単一CLAUDE.mdを避けて、トピック別にファイルを分けるモジュラー設計ができます。

.claude/rules/ と path-specific rules

.claude/rules/ 配下に置く md ファイルは YAML frontmatter のpaths フィールドで glob パターンを指定可能。 該当パスのファイルを編集している時だけそのルールが読み込まれる仕組みです。

例: paths: ["**/*.test.tsx"] と書けば、テストファイル編集時のみそのルールが有効化。 ディレクトリ別の CLAUDE.md と違って、ファイルの type に応じた条件適用ができます。

カスタムスラッシュコマンド

Claude Code のスラッシュコマンドは markdown ファイルで定義:

• Project-scoped: .claude/commands/{name}.md — チーム共有・version control 対象
• User-scoped: ~/.claude/commands/{name}.md — 個人用

ファイル内で $ARGUMENTS プレースホルダーを使えば、コマンド実行時の引数を受け取れます。

Skills（.claude/skills/）

Skills は SKILL.md ファイルで定義するタスク特化型のスキル機構。 frontmatter で次が指定可能:

• context: fork — 独立した sub-agent コンテキストで実行（メイン会話を汚さない）
• allowed-tools — スキル実行中に許可するツール制限
• argument-hint — 引数なしで起動された時に表示するヒント

Plan mode vs Direct execution

Plan mode は「コードベース探索 + 設計検討」を実装着手前に行うモード。 複数ファイル変更・アーキテクチャ判断・複数の正解がある場合に適しています。 Direct execution は「明確に範囲が決まった単純変更」に適しています。

Claude Code CLI（非対話モード）

CI/CD パイプラインでは -p (または --print) フラグで非対話実行できます。 対話プロンプトを待たずに結果を stdout に出して終了する挙動です。--output-format json と --json-schema で構造化出力も指定可能。

このドメインの主題的な問い（Fyveの解釈）

1. 規約を「どこに置くか」が常に問われる
   User vs Project vs Directory、CLAUDE.md vs .claude/rules vs .claude/skills、 それぞれ scope と用途が異なる。問題文の「チーム全員に適用したい」「特定ファイルだけに適用したい」 などの条件から正しい配置場所を選ぶ判断力が問われる。
2. Plan mode は判断力で使う
   Plan mode を機械的に常用するのではなく、「複数選択肢がある」「アーキテクチャ判断が必要」 な場面で選ぶ。単純なバグ修正に Plan mode を使うと過剰。
3. 反復改善のパターンを使い分ける
   Claude にテスト失敗を見せてイテレートする / I/O 例で挙動を示す / Claude に質問させて 要件を引き出す（interview pattern）の使い分けが問われる。

このドメインが関わるシナリオ

• Code Generation with Claude Code — D3 が主要トピック
• Developer Productivity with Claude — D3 + D2 の組み合わせ
• Claude Code for Continuous Integration — D3 + D4（プロンプト設計）

学習リソース（公式）

• docs.anthropic.com — Claude Code 公式リファレンス全般
• Anthropic Academy: Claude Code in Action — Claude Code 実践コース（21レッスン）。本ドメイン直撃
• Anthropic Academy: Claude Code 101 — 入門レベル
• Fyveの Claude Code 導入ガイド — 日本語による解説（公式情報の整理）

Fyveの実戦から見た D3

Claude Code を主軸に AI 業務効率化システムを構築してきた経験から:

「CLAUDE.md は modular に分ける」。 単一の巨大 CLAUDE.md は読みづらく、変更時の影響範囲が見えづらい。 Fyveでは .claude/rules/ 配下に topic別 md（coding.md, design.md, deploy.md 等）を分け、 親 CLAUDE.md は @import で読み込む構造を標準にしています。

「Plan mode は "選択肢が複数ある時" の合図」。 単一ファイル修正の小さな変更には Plan mode を使わない。 逆に「データ構造を変えるか / API を変えるか」のような判断が含まれる時は必ず Plan mode で入る。

「Custom slash command は "個人の癖" を共有資産化できる」。 個人の ~/.claude/commands/ に置いていたコマンドを project-scoped にすると、 チーム全員のワークフローが揃います。