CCA試験対策 D3完全解説 — Claude Code設定とワークフローで20%を攻略する 例えば、CCA Foundations試験の5ドメインのうち、Domain 3「Claude Code Configuration & Workflows」は配点20%を占める。つまり、6つのタスクステートメント(T3.1〜T3.6)で構成され、CLAUDE.mdの階層設計からCI/CDパイプライン統合まで、Claude Codeの実務的な設定・運用能力が問われる。 したがって、本記事はCCA試験対策シリーズ第5回として、CCA試験 Claude Code 設定 ワークフローに関するDomain 3の全タスクを完全解説する。同様に、前回のDomain 2解説 で学んだMCP統合の知識が、T3.3のMCP設定で直接活かされる。CLAUDE.mdの三層ヒエラルキーとモジュラー構成(T3.1) 一方、CCA試験 Claude Code 設定 ワークフローの最重要トピックが、CLAUDE.mdの階層構造だ。具体的には、CLAUDE.mdは3つのレベルで読み込まれ、下位が上位を上書き・補完する。レベル パス スコープ 用途 ユーザー ~/.claude/CLAUDE.md全プロジェクト共通 個人の開発スタイル・共通ルール プロジェクト プロジェクトルート/CLAUDE.mdリポジトリ全体 プロジェクト固有の規約・構造情報 ディレクトリ 任意ディレクトリ/CLAUDE.mdそのディレクトリ以下 サブパッケージ固有のルール
同様に、読み込み順序は「ユーザー → プロジェクト → ディレクトリ」で、深いほど優先度が高い。例えば、ユーザーレベルでコーディングスタイルを定義し、プロジェクトレベルで異なるスタイルを指定した場合、プロジェクトレベルが優先される。@path構文によるモジュラー構成 さらに、CLAUDE.md内で @ファイル名.md と記述すると、外部ファイルを取り込める。# CLAUDE.md
@FLAGS.md
@RULES.md
@PRINCIPLES.md
とりわけ、この仕組みの利点は3つある。まず、第一に関心の分離(セキュリティルール、コーディング規約、ワークフローを別ファイル管理)。同様に、第二に再利用性(複数プロジェクトで共通ルールを共有)。最終的に、第三にメンテナンス性(変更箇所が局所化される)。.claude/rules/による条件付きルールロード また、.claude/rules/ ディレクトリに配置したルールファイルは、YAML frontmatterの paths フィールドでグロブパターンを指定し、該当ファイル編集時のみロードされる。---
paths:
- "src/components/ 配下の .tsx ファイル"
- "src/components/ 配下の .ts ファイル"
---
# React コンポーネントルール
- 関数コンポーネント + hooks を使用
- default export 必須
結論として、パス一致しないルールはコンテキストに含まれないため、トークンを節約できる。加えて、これは試験で「最も効率的なアプローチは?」という出題パターンで頻出する。ディレクトリCLAUDE.mdと.claude/rules/の使い分け 基準 ディレクトリ CLAUDE.md .claude/rules/ スコープ 特定ディレクトリ配下すべて グロブパターンで柔軟に指定 適用対象 ディレクトリ構造と一致 ディレクトリをまたぐ規約に最適 管理場所 各ディレクトリに分散 .claude/rules/ に集約トークン効率 ディレクトリ進入時に常にロード 該当ファイル編集時のみロード
/memory コマンドで現在ロードされているCLAUDE.mdとルールの状態を確認できる。特に、デバッグや設計検証に有用だ。設計例:モノレポの階層設計 ~/.claude/CLAUDE.md ← 個人共通(エディタ設定、言語設定)
├── @FLAGS.md
└── @PRINCIPLES.md
project/CLAUDE.md ← プロジェクト全体(技術スタック、命名規約)
project/.claude/rules/
├── react-components.md ← paths: ["src/components/**"]
├── api-endpoints.md ← paths: ["src/api/**"]
└── test-conventions.md ← paths: ["tests/**", "**/*.test.ts"]
project/packages/mobile/CLAUDE.md ← モバイル固有ルール
サンプル問題(T3.1) さらに、テストファイルがプロジェクト全体に散在しており、一貫した命名規約を適用したい。同様に、最適なアプローチは? また、A) プロジェクトルートの CLAUDE.md にテスト規約を追加
B) .claude/rules/ にグロブパターン付きルールファイルを作成
C) 各テストディレクトリに CLAUDE.md を配置
D) ユーザーレベル CLAUDE.md に記述 正解: B — グロブパターン "**/*.test.ts" で散在するテストファイルに横断的にルールを適用でき、トークン効率も良い。したがって、試験では「散在するファイル」というキーワードが出たら .claude/rules/ + グロブパターンを選ぶ。カスタムスラッシュコマンドとスキル(T3.2) コマンドの2つのスコープ スコープ パス 共有範囲 バージョン管理 プロジェクト .claude/commands/コマンド名.mdチーム全員 Gitで共有可能 ユーザー ~/.claude/commands/コマンド名.md自分のみ 個人設定
具体的には、コマンドファイルはMarkdownで記述し、$ARGUMENTS プレースホルダーでユーザー入力を受け取る。特に、# .claude/commands/review.md
以下のコードを次の観点でレビューしてください:
- セキュリティ脆弱性
- パフォーマンス問題
- コーディング規約準拠
対象: $ARGUMENTS
使用時は /review src/auth/login.ts のように呼び出す。スキル(.claude/skills/) つまり、スキルはコマンドの拡張版で、SKILL.mdのfrontmatterで実行環境を制御する。つまり、# .claude/skills/deploy-check/SKILL.md
---
context: fork
allowed-tools:
- Bash
- Read
argument-hint: "デプロイ対象の環境名を入力(staging / production)"
---
# デプロイ前チェックスキル
デプロイ前に以下を検証します:
1. テスト全件パス
2. lint エラーなし
3. 環境変数の整合性
対象環境: $ARGUMENTS
frontmatterの主要フィールドは3つだ。フィールド 説明 例 context: forkメイン会話を汚さない隔離実行 探索的タスクに最適 allowed-tools使用可能なツールを制限 [Bash, Read](Writeを禁止)argument-hintユーザーへの入力プロンプト "ファイルパスを入力"
コマンドとスキルの使い分け 基準 コマンド スキル 複雑さ シンプルなプロンプト 実行環境制御が必要 隔離性 メイン会話内で実行 context: fork で隔離可能ツール制限 なし allowed-tools で制限可能典型例 /review, /morningデプロイチェック、セキュリティスキャン
サンプル問題(T3.2) 例えば、チーム全員が使える /review コマンドを作成したい。同様に、どこに配置すべきか? しかし、A) ~/.claude/commands/review.md B) .claude/commands/review.md C) .claude/skills/review/SKILL.md D) CLAUDE.md 内にインライン定義 したがって、正解: B — プロジェクトスコープの .claude/commands/ に配置すればGitで共有され、チーム全員が利用可能。同様に、試験では「チーム共有」というキーワードが出たらプロジェクトスコープ(.claude/commands/)を選ぶ。パス固有ルール — .claude/rules/による条件付きロード(T3.3) 特に、CCA試験のD3で問われるパス固有ルールは、.claude/rules/ディレクトリにYAMLフロントマターとglobパターンを持つルールファイルを配置する仕組みだ。同様に、該当ファイル編集時のみ条件付きでロードされるため、トークン効率が高い。 加えて、YAMLフロントマターのpathsフィールドにglobパターン(例: "src/components/**/*.tsx")を指定し、パスが一致しないルールはコンテキストに含まれない。同様に、ディレクトリCLAUDE.mdとの使い分けも出題される。 具体的には、テストファイル規約をtests/**に、APIエンドポイント規約をsrc/api/**に適用するといった設計が問われる。さらに、/memoryコマンドで現在ロードされているルールの確認方法も出題ポイントだ。 同様に、Domain 2の解説記事 で詳しく扱ったツール記述の設計原則は、MCPサーバーのツール定義にもそのまま適用される。プランモードと直接実行の判断(T3.4) プランモードを使うべき場面 シナリオ 理由 大規模な変更 影響範囲の事前把握が必要 複数の有効なアプローチが存在 選択肢の比較検討が必要 アーキテクチャ決定 不可逆な判断を含む 複数ファイルにまたがる変更 整合性の確認が必要
直接実行が適切な場面 シナリオ 理由 単一ファイルのバグ修正 スコープが明確 タイポ修正 影響範囲が限定的 ドキュメント更新 ロジックへの影響なし
判断マトリクス 結論として、判断に迷ったら安全側(プランモード)を選ぶのが鉄則だ。例えば、影響ファイル数 > 3 → プランモード しかし、複数のアプローチが考えられる → プランモード したがって、アーキテクチャ変更を含む → プランモード 加えて、単一ファイル、スコープ明確 → 直接実行 同様に、不明・判断に迷う → プランモードで安全側に Exploreサブエージェント とりわけ、/plan コマンドでプランモードに入るほか、Exploreサブエージェントを利用して探索的な調査を隔離できる。同様に、冗長な探索出力がメイン会話を汚さず、要約のみがメイン会話に返される。大規模コードベースの調査に最適だ。サンプル問題(T3.4) 具体的には、モノリスアプリケーションをマイクロサービスに分割する際、なぜプランモードが推奨されるか? 一方、A) 実行速度が速いから
B) 複数の分割戦略を比較検討でき、依存関係を事前に分析できるから
C) 自動的にコードを生成するから
D) テストが不要になるから まず、正解: B — 大規模なアーキテクチャ変更では、事前に複数のアプローチを比較し影響範囲を把握することが重要。反復改善テクニック(T3.5) 加えて、Claude Codeの出力を安定させるための3つのテクニックを押さえる。具体的な入出力例の提示 例えば、散文的な指示で出力が安定しない場合、具体的な入出力ペアを示すのが最も効果的だ。# 不安定になりがちな指示
「関数名は分かりやすくしてください」
# 安定する指示(入出力例)
入力: function proc(d) { /* 処理 */ }
期待出力: function processUserData(userData) { /* 処理 */ }
テスト駆動反復 まずテストスイートを書き、テスト失敗結果をClaude Codeに共有し、テストを通すようにコードを改善させる。同様に、「正しさ」の定義がテストとして明文化されるため、改善方向がブレない。 したがって、手順は4ステップだ。同様に、(1) テストスイートを書く(期待する振る舞いを定義)、(2) テスト失敗結果をClaude Codeに共有する、(3) Claude Codeがテストを通すようにコードを改善する、(4) 新たな失敗があれば繰り返す。インタビューパターン 一方、Claude Codeに「質問させる」ことで、自分が見落としている観点を発見する。同様に、「認証システムを改善したい」と伝えると、Claude Codeが「現在のセッション管理方式は?」「マルチデバイス対応は必要ですか?」と質問してくる。メッセージ戦略 同様に、問題の性質によってメッセージの送り方を変える。同様に、相互に関連する問題群は1つのメッセージに全コンテキストをまとめる(一貫性のある回答を得るため)。独立した問題群は順次送信で個別に対処する(各問題に集中した深い回答を得るため)。 とりわけ、試験では「出力が不安定」というキーワードが出たら、「具体的入出力例」を選ぶ。CI/CDパイプライン統合(T3.6) -pフラグ(非対話モード) 最終的に、CI環境では対話的な入力ができない。同様に、-p(--print)フラグで非対話モードを使用する。さらに、claude -p "このPRのセキュリティ問題をレビューしてください"
CIジョブがハングする最も一般的な原因は、-p フラグの付け忘れだ。同様に、フラグなしではClaude Codeが対話入力を待ち続けるため、ジョブがタイムアウトする。試験では「CIジョブがハング」というキーワードが出たら -p フラグを即答する。構造化出力 また、--output-format json と --json-schema で、パース可能な構造化出力を取得できる。claude -p "コードの問題点を分析してください" \
--output-format json \
--json-schema '{"type":"object","properties":{"issues":{"type":"array"}}}'
CLAUDE.mdのCI活用 結論として、CI環境でもCLAUDE.mdは読み込まれる。同様に、プロジェクトの規約・構造情報が自動的にコンテキストに含まれるため、レビュー品質が向上する。セッション分離の重要性 さらに、同一セッション内のセルフレビューは弱い。同様に、コード生成したセッションでの自己レビューでは、先行する推論コンテキストが残り、自分の判断を疑いにくいバイアスが働く。CIでのコードレビューは、コード生成とは独立したインスタンスで実行すべきだ。方式 信頼性 理由 同一セッションでレビュー 低い 自分の出力に対するバイアスが働く 独立インスタンスでレビュー 高い 先入観なしに客観的評価が可能
GitHub Actions統合例 name: Claude Code Review
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: セキュリティレビュー
run: |
claude -p "Review the changes in this PR for security issues" \
--output-format json
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
サンプル問題(T3.6) また、CIパイプラインでClaude Codeを使用したジョブがハングしている。同様に、最も可能性の高い原因は? 具体的には、A) APIキーが無効
B) -p フラグが指定されていない
C) CLAUDE.mdが存在しない
D) ネットワークタイムアウト 特に、正解: B — -p フラグなしでは対話入力を待ち続けるため、CIジョブがハングする。実践演習:CLAUDE.mdの階層設計 つまり、Domain 3の知識を実際のチームプロジェクトに適用する。同様に、ここでは、フルスタックWebアプリケーション(フロントエンド: React + TypeScript、バックエンド: Python FastAPI、インフラ: Terraform)のCLAUDE.md階層を設計する演習を行う。シナリオ設定 特に、チーム構成は5名。同様に、フロントエンド2名、バックエンド2名、インフラ1名。全員がClaude Codeを使用する。以下の課題を解決する設計が求められる。結論として、フロントエンドとバックエンドで異なるコーディング規約がある とりわけ、テストファイルがプロジェクト全体に散在している 一方、CI/CDパイプラインでClaude Codeを使用する まず、個人ごとにエディタ設定が異なる ステップ1:三層ヒエラルキーの設計(T3.1の適用) ~/.claude/CLAUDE.md ← ユーザーレベル(個人設定)
├── @PRINCIPLES.md ← 個人のコーディング原則
project/CLAUDE.md ← プロジェクトレベル(チーム共有)
├── 技術スタック情報
├── Git ブランチ戦略
└── 共通命名規約
project/frontend/CLAUDE.md ← ディレクトリレベル(フロントエンド固有)
├── React コンポーネント規約
├── TypeScript strict mode ルール
└── CSS-in-JS の使用方針
project/backend/CLAUDE.md ← ディレクトリレベル(バックエンド固有)
├── FastAPI ルーター構造
├── Pydantic モデル設計規約
└── 非同期処理の方針
具体的には、ユーザーレベルには個人の好み(エディタ設定、言語設定)を配置する。同様に、プロジェクトレベルにはチーム全体で共有する規約を記述する。ディレクトリレベルにはその技術スタック固有のルールを置く。ステップ2:.claude/rules/による横断ルール(T3.1の適用) 加えて、ディレクトリ構造と一致しないルール(テストファイル、設定ファイル等)には、.claude/rules/のグロブパターンを使う。つまり、project/.claude/rules/
├── test-conventions.md
│ paths: ["**/*.test.ts", "**/*.test.tsx",
│ "tests/配下の 全 .py", "**/*_test.py"]
│ → テスト命名規約、AAA パターン、モック方針
│
├── api-contracts.md
│ paths: ["project/frontend/src/api/**",
│ "project/backend/app/routers/**"]
│ → API 契約ルール(型の一致、エンドポイント命名)
│
├── terraform-safety.md
│ paths: ["infra/配下の 全 .tf"]
│ → Terraform 変更時の安全確認手順
│
└── ci-config.md
paths: [".github/**", "Dockerfile",
"docker-compose*.yml"]
→ CI/CD 設定変更時のルール
test-conventions.mdは"**/*.test.ts"と"**/*_test.py"の両方にマッチする。同様に、テストファイルがフロントエンドとバックエンドの両方に散在していても、1つのルールファイルで横断的にカバーできる。重要なポイント api-contracts.mdはフロントエンドのAPIクライアントとバックエンドのルーター両方にマッチさせている。API契約の一貫性を、ディレクトリをまたいで強制する設計だ。ステップ3:カスタムコマンドとスキルの配置(T3.2の適用) 例えば、チーム共有のコマンドはプロジェクトスコープに、個人用は各自のユーザースコープに配置する。例えば、# チーム共有コマンド
project/.claude/commands/
├── review.md ← /review でコードレビュー
├── api-check.md ← /api-check でAPI契約の整合性確認
└── deploy-checklist.md ← /deploy-checklist でデプロイ前チェック
# チーム共有スキル
project/.claude/skills/
└── security-scan/SKILL.md
context: fork
allowed-tools: [Bash, Read, Grep]
→ 隔離環境でセキュリティスキャン実行
セキュリティスキャンをcontext: forkで隔離する理由は2つある。同様に、第一に、スキャン過程の冗長な出力がメイン会話を汚さない。第二に、allowed-toolsでWriteを除外することで、スキャン中にファイルが変更されるリスクを排除できる。ステップ4:CI/CDパイプライン統合(T3.6の適用) しかし、# GitHub Actions: PRレビュー
name: Claude Code Review
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: セキュリティ・品質レビュー
run: |
claude -p "Review this PR for security and quality" \
--output-format json
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
-pフラグの付け忘れはCIジョブがハングする原因だ。同様に、--output-format jsonで構造化出力を取得し、後続のジョブでパース可能にする。CLAUDE.mdはCI環境でも自動的に読み込まれるため、プロジェクトの規約がレビューに反映される。ステップ5:プランモード vs 直接実行の判断(T3.4の適用) したがって、このプロジェクトで各タスクにどちらを適用するかを判断する。タスク 推奨モード 判断理由 Reactコンポーネントのタイポ修正 直接実行 単一ファイル、スコープ明確 APIエンドポイントの追加 プランモード フロントエンド・バックエンド両方に影響 Terraformの本番環境変更 プランモード 不可逆な変更、影響範囲大 READMEの更新 直接実行 ロジックへの影響なし 認証システムのリファクタリング プランモード 複数ファイル、アーキテクチャ変更
したがって、判断に迷ったらプランモードを選ぶのが鉄則だ。同様に、安全側に倒すことで、不可逆な変更によるリスクを回避できる。よくある設計ミスと回避策 加えて、この演習で陥りやすい設計ミスを3つ挙げる。 同様に、ミス1: 全ルールをプロジェクトルートのCLAUDE.mdに集約する 一方、フロントエンドのReactルールとバックエンドのFastAPIルールを1つのファイルに書くと、バックエンド開発時にも不要なフロントエンドルールがコンテキストに読み込まれる。同様に、ディレクトリレベルのCLAUDE.mdか.claude/rules/のグロブパターンで分離することで、トークン効率が向上する。 結論として、ミス2: 個人設定をプロジェクトスコープに配置する とりわけ、エディタの好みやショートカット設定はユーザーレベル(~/.claude/CLAUDE.md)に配置する。同様に、プロジェクトスコープに書くとチーム全員に強制され、摩擦が生じる。 一方、ミス3: CI/CDでセッション分離を考慮しない 同様に、コード生成と同一フローでレビューを実行すると、先行推論コンテキストによるバイアスが働く。同様に、CI/CDのレビュージョブは必ず独立インスタンスで実行する設計にすべきだ。設計チェックポイント チェック項目 該当タスク 三層ヒエラルキーが適切に設計されているか T3.1 散在するファイルへのルールはグロブパターンで対応しているか T3.1 チーム共有コマンドはプロジェクトスコープに配置されているか T3.2 探索的スキルはcontext: forkで隔離されているか T3.2 CI環境で-pフラグが指定されているか T3.6 大規模変更にはプランモードが選択されているか T3.4
Domain 3の試験パターンと攻略法 とりわけ、CCA試験 Claude Code 設定 ワークフローに関するDomain 3で頻出する出題パターンを整理する。パターン 典型的な問い 着眼点 最適な配置場所 「〜をどこに置くべきか?」 スコープ(チーム共有 vs 個人、条件付き vs 常時) トークン効率 「最も効率的なアプローチは?」 不要なコンテキストを排除する仕組み モード選択 「プラン vs 直接実行」 影響範囲・複雑性・不可逆性 CI統合トラブル 「ジョブがハング/出力がパースできない」 -p フラグ、--output-format json改善テクニック 「出力が安定しない場合の対処」 具体的入出力例 > 散文指示
キーワード → 正解のマッピング まず、試験の選択肢を絞り込むためのキーワードマッピングだ。最終的に、「チーム共有」→ .claude/commands/(プロジェクトスコープ) さらに、「散在するファイル」→ .claude/rules/ + グロブパターン また、「トークン節約」→ パス固有ルール 具体的には、「CIハング」→ -p フラグ 特に、「出力が不安定」→ 具体的入出力例 つまり、「隔離実行」→ context: fork 総合チェックリスト 結論として、Domain 3の学習完了を確認するためのチェックリストだ。例えば、CLAUDE.mdの三層ヒエラルキー(ユーザー/プロジェクト/ディレクトリ)を説明できるか しかし、@path構文によるモジュラー構成の利点を3つ挙げられるか したがって、.claude/rules/ のグロブパターンによる条件付きロードを設計できるか 加えて、コマンド(.claude/commands/)とスキル(.claude/skills/)の違いを説明できるか 同様に、context: fork と allowed-tools の役割を理解しているか 結論として、プランモードと直接実行の判断基準を適用できるか とりわけ、-p フラグの必要性とCIハング問題の原因を即答できるか 一方、--output-format json + --json-schema の使い方を書けるか まず、セッション分離の重要性を説明できるか さらに、次回はDomain 4「Prompt Engineering & Structured Output」を解説する。同様に、Domain 4の記事 では、tool_useによる構造化出力やバッチ処理APIなど、CCA試験 Claude Code 設定 ワークフローと密接に関連するプロンプト設計技術を扱う。重要なポイント さらに深く学ぶために : 本記事はCCA試験の設計判断パターンを概説したものです。同様に、合格に向けた実践的な準備には、Anthropic Academy公式コース でのハンズオン学習と、模擬問題サイト での演習を併せて実施してください。本シリーズの完全ガイド(Day 1) で推奨する「3本柱」の学習戦略も参照してください。さらに詳しい情報はClaude Code公式ドキュメント でご覧いただけます。
ABOUT ME
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。
初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI.
Practical tips that anyone can start using right away.