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

カスタムスラッシュコマンドとスキルは、CCA-F ドメイン 3（Claude Code の設定とワークフロー、試験配点 20 ％）の中のタスクステートメント 3.2「カスタムスラッシュコマンドとスキルを作成・設定する」に位置するトピックだ。CLAUDE.md 階層（3.1）やパス固有のルール（3.3）と並んで、カスタムスラッシュコマンドとスキルは Claude Code のインストールが規律ある団体ツールとして振る舞うか場当たり的な遊び場として振る舞うかを決める三本柱の一つだ。Kishor Kukreja・Rick Hightower・Tutorials Dojo CCA-F 学習ガイドのコミュニティ合格報告はいずれも、ドメイン 1 のエージェントアーキテクチャに過剰準備してドメイン 3 の Claude Code 設定メカニクスの準備が不足したことを意外なドメインとして指摘している。

本学習ノートは、CCA-F 受験者が認識できるようになるべきカスタムスラッシュコマンドとスキルの全体像を説明する：.claude/commands/ のプロジェクトスコープコマンドと ~/.claude/commands/ のユーザースコープコマンドのディレクトリレイアウト；context: fork・allowed-tools・argument-hint のフロントマターフィールドを持つ .claude/skills/ のスキル定義形式；スキル出力がメイン会話を汚染することを防ぐ context: fork の隔離セマンティクス；スキル実行中に許可されるアクションを制限する allowed-tools のセキュリティポスチャー；開発者に必要なパラメータを促す argument-hint の UX；~/.claude/skills/ を通じたチームメイトに影響を与えない個人的なスキルカスタマイズパターン；そしてオンデマンドスキルと常時ロードの CLAUDE.md ユニバーサルスタンダードを選ぶための判断ヒューリスティック。すべては「Claude Code を使ったコード生成」シナリオに固定されており、これは試験が 1 回の受験で 4 つを出題する 6 つのシナリオの一つだ。

CCA-F ドメイン 3.2 でカスタムスラッシュコマンドとスキルが重要な理由

カスタムスラッシュコマンドとスキルなしの Claude Code はチャットボックスとツールベルトだ。カスタムスラッシュコマンドとスキルを持つ Claude Code は共有チームハーネスになる：開発者は /review・/release-notes・/migration-plan と入力して、適切なコンテキストを取り込み・適切なツールを呼び出し・適切なガードレールを適用するキュレートされたプロンプトを起動できる。定義がリポジトリにあってバージョン管理されているため、チームメンバー全員が同じ動作を得られる。

認定の観点から、タスク 3.2 はドメイン 3 で最も一貫してテストされる項目の一つだ。試験は、チームがワークフロー（セキュリティレビュー・リントと修正・変更ログ生成・コードスキャフォールディング）をパッケージ化したい場面を提示し、正しいディレクトリ・正しいスコーピング・正しいフロントマターフィールドを選ぶよう求める。.claude/commands/ と ~/.claude/commands/ を混同する CCA-F 受験者は、「Claude Code を使ったコード生成」で受験するたびに少なくとも 1 つの採点問題を落とす。context: fork を認識できない受験者は、スキルの中間ステップがメイントランスクリプトを汚染するかどうかを誤読する。allowed-tools を知らない受験者は、意図したことのない破壊的な操作を実行できるスキルを設計する。

カスタムスラッシュコマンドとスキルのトピックは暗記できる程度に狭く、本当の理解を報いる程度に深い。CCA-F では珍しい組み合わせだ。適切に行えば、これは自由点数のドメインだ。おざなりに行えば、罠だらけのドメインだ。

組み込みスラッシュコマンド vs カスタムスラッシュコマンド

カスタム定義に掘り下げる前に、CCA-F 受験者は Claude Code が組み込みのスラッシュコマンド（/clear・/compact・/cost・/help・/model・/review・/init・/exit など）を備えて出荷されることを明確にしておくべきだ。これらは設定なしで存在し、あらゆる Claude Code インストールで同一に動作する。

カスタムスラッシュコマンドは、ユーザーまたはチームが作成したコマンドで、ディスク上の Markdown ファイルとして存在する。Claude Code セッション内で /my-command と入力すると、Claude Code はその名前を既知のディレクトリセットに対して解決し、見つかった場合はファイルの内容をプロンプトとして展開する。展開にはテンプレート化された引数・ファイル参照・構造化された指示を含めることができる。よく書かれたカスタムコマンドは、チームのすべての開発者が一貫して呼び出せる繰り返し可能でパラメータ化されたプロンプトになる。

この区別が重要なのは、試験シナリオがしばしば「全員が異なる方法で実行するワークフローを正式化したいチーム」を説明するからだ。正しい回答は常に、口頭または書面による慣習ではなくカスタムスラッシュコマンドまたはスキルを作成することだ。

カスタムスラッシュコマンドとスキルがプロンプトのコピー＆ペーストに勝る理由

カスタムコマンドが存在する以前は、チームは Slack・Notion・README ファイルでプロンプトを共有していた。開発者はそれらを Claude Code に貼り付け、しばしば古いコンテキストや欠けた引数を持っていた。カスタムコマンドはプロンプトを実行可能・バージョン管理・発見可能にすることでこれを解決する。同じ論理がカスタムスラッシュコマンドとスキル全体に適用される：この機能は、オンボーディング・オフボーディング・プロンプトドリフトを乗り越えて組織の知識が生き残れるように存在する。

プロジェクトスコープ vs ユーザースコープ：二つのディレクトリ

カスタムスラッシュコマンドとスキルにおいて試験に最も関連する単一の区別は、定義ファイルがどこに存在するかだ。Claude Code は 2 つのディレクトリを検索し、それぞれ異なる対象と異なるバージョン管理の事情を持つ。

プロジェクトスコープ：.claude/commands/

プロジェクトスコープのコマンドはリポジトリのルートの .claude/commands/ ディレクトリに存在する。それらが操作するコードと並んでバージョン管理にチェックインされる。リポジトリをクローンするすべての開発者が同じコマンドセットを受け取る。リードエンジニアが .claude/commands/ に新しい /security-review.md ファイルを追加すると、すべてのチームメートが次の git pull で受け取る。

プロジェクトスコープが正しい選択の場面：

• コマンドがチームの慣習をエンコードする（リリースノートの形式・PR レビューチェックリスト・マイグレーションプランナー）。
• コマンドがリポジトリ固有のパス・ツール・CI 設定に依存する。
• チームが現在および将来のすべての開発者が同じワークフローを実行することを望む。

ユーザースコープ：~/.claude/commands/

ユーザースコープのコマンドは開発者のホームディレクトリの ~/.claude/commands/ に存在する。それらは個人的であり、決して開発者のマシンを離れない。Git はそれらを見ない。チームメートも見ない。

ユーザースコープが正しい選択の場面：

• コマンドが個人的なもの（例：開発者自身のチケットテンプレートを注入する /my-todo）。
• コマンドがチームが標準化していない個人的なスタイルを反映する。
• 開発者がチームの慣習として提案する前にワークフローを試したい。

解決順序

開発者が /review と入力すると、Claude Code はプロジェクトディレクトリを最初に確認し、次にユーザーディレクトリにフォールバックすることで名前を解決する。同じ名前のコマンドが両方に存在する場合、プロジェクトスコープの定義がそのリポジトリで優先される。これはチームが自分たちのコードベース内で開発者の個人的な設定を正規のプロジェクトバージョンでオーバーライドできるようにしながら、開発者の個人バージョンが他のすべてのリポジトリでアクティブに残ることを許す。

この解決順序は、開発者が「新しいプロジェクトに参加してから個人の /review コマンドが期待通りに動かなくなった」と報告するときの試験問題に登場する。正しい診断は .claude/commands/ のプロジェクトスコープの /review がユーザースコープのバージョンをシャドーイングしているということだ。Claude Code が誤動作しているのではない。

/review コマンドの置き場所

標準的な CCA-F 試験ガイドのサンプル問題（シナリオクラスターの Q4）は尋ねる：チームはコードレビュー中にすべての開発者が同じ /review コマンドを実行することを望む。定義はどこに置くべきか？回答は .claude/commands/（プロジェクトスコープのディレクトリ、リポジトリとバージョン管理される）であり、~/.claude/commands/（個人のみ）でも CLAUDE.md（スラッシュコマンドのメカニズムではない）でもない。このまったく同じパターンが異なるコマンド名（/release-notes・/security-audit・/migration）で繰り返し出題され、常にプロジェクトディレクトリを指している。

カスタムスラッシュコマンドファイルの解剖学

カスタムスラッシュコマンドはコマンドにちなんで名前を付けた Markdown ファイルだ。/review は review.md に存在する。/release-notes は release-notes.md に存在する。ファイルの本文は Claude Code がコマンド実行時に注入するプロンプトだ。

.claude/commands/review.md の最小限のプロジェクトスコープの /review コマンドは次のようなものだ：

---
description: Run a structured code review on the staged diff.
argument-hint: <optional focus area, e.g. "security" or "performance">
---

You are performing a code review on the currently staged changes.

Focus area: $ARGUMENTS

Steps:
1. Read the diff with the `git diff --cached` Bash tool.
2. For each changed file, identify correctness, security, and performance issues.
3. Produce a Markdown checklist of findings grouped by severity.

先頭のフロントマターブロックはオプションだが推奨される。一般的なフロントマターフィールドには次が含まれる：

• description — /help 出力に表示される一行の要約。
• argument-hint — コマンドが期待する引数を開発者に伝えるプレースホルダーテキスト。
• allowed-tools — コマンドが実行中に使用を許可されているツールのサブセット。

本文は 1 つの特別なテンプレート変数 $ARGUMENTS を持つ通常のプロンプトで、コマンド名の後に開発者が入力したものに展開される。

引数処理と argument-hint

開発者が /review security と入力すると、文字列 security が $ARGUMENTS として取り込まれプロンプト本文に代入される。開発者が引数なしで /review と入力すると、$ARGUMENTS は空になる。ここで argument-hint が機能する。これは Claude Code に、欠けたパラメータをヒントテキストをガイダンスとして使い開発者に促すよう指示し、引数なしで静かに実行する代わりに使われる。

スキル：再利用可能なプロンプト＋ツールパッケージ

スラッシュコマンドはオンデマンドのプロンプトだ。スキルはさらに一歩進んだ構造化された再利用可能なワークフローで、プロンプトをツール制限・コンテキスト隔離セマンティクス・オプションのサブエージェント実行とバンドルする。スキルは .claude/skills/（プロジェクト）または ~/.claude/skills/（ユーザー）に存在し、各スキルが独自のディレクトリを持ち SKILL.md ファイルが定義として機能する。

ディレクトリレイアウト

典型的なプロジェクトスコープのスキルディレクトリは次のようなものかもしれない：

.claude/
  skills/
    migration-planner/
      SKILL.md
      templates/
        migration-template.md
    release-notes/
      SKILL.md
    security-audit/
      SKILL.md
      checklists/
        owasp-top-10.md

各スキルは自己完結したフォルダだ。SKILL.md ファイルがエントリポイント；サポートファイル（テンプレート・チェックリスト・参照ドキュメント）はその隣に置き、プロンプトから参照できる。

SKILL.md の構造

SKILL.md ファイルは YAML フロントマターとプロンプト本文の 2 つのパートを持つ：

---
name: migration-planner
description: Plan a multi-step database migration with rollback checkpoints.
context: fork
allowed-tools:
  - Read
  - Write
  - Grep
  - Glob
argument-hint: <source version and target version, e.g. "v3 -> v4">
---

You are planning a database migration from $ARGUMENTS.

Steps:
1. Use Read and Grep to inventory affected tables.
2. Produce a migration plan with ordered steps and rollback checkpoints.
3. Write the plan to `docs/migrations/plan.md` using the Write tool.

CCA-F で最も重要なフロントマターフィールドは context: fork・allowed-tools・argument-hint だ。これら 3 つのフィールドは試験問題の回答ステム・誤答選択肢・シナリオキューとして登場する。

context: fork — スキルを隔離されたサブエージェントコンテキストで実行する

context: fork フロントマターフィールドは、スキルを単純なスラッシュコマンドから分離する定義的なメカニズムだ。設定されると、Claude Code はスキルを実行するために隔離された会話コンテキストを持つサブエージェントをスポーンし、スキルの最終的な出力のみをメイン会話に返す。

隔離が実際に何を意味するか

context: fork なしでは、スキルのプロンプトと中間ステップはメイン会話に追加される。すべてのファイル読み込み・すべての Grep 出力・すべてのツール呼び出し・すべての Claude の返答がメイントランスクリプトの一部になる。長いワークフローではこれはコンテキスト window を汚染し・トークンを消費し・開発者が意図しなかったノイズを導入する。

context: fork では、スキルはコンテキストが別のサブエージェント内で実行される。サブエージェントはその入力を読み・ステップを実行し・最終的な要約を生成する。その最終的な要約だけがメイン会話に追加される。中間の作業は破棄され、メイン会話のフォーカスとコンテキスト予算が保存される。

いつフォークするか

フォークするとき：

• スキルがメイン会話が直接見る必要のない多数の中間ファイル読み込みを実行する。
• スキルが最終的な出力が簡潔なレポートである長時間の探索または分析を実行する。
• スキルがフォローアップのプロンプトを混乱させる冗長または雑然とした中間出力を生成する可能性がある。

フォークしないとき：

• スキルが短い一発のプロンプトで、その出力全体がメイントランスクリプトに表示されるべき場合。
• 開発者がメイン会話内で対話的に作業を洗練させ続ける必要がある場合。

ドメイン 1 のサブエージェントとの接続

ドメイン 1（エージェントアーキテクチャとオーケストレーション、配点 27 ％）を準備している CCA-F 受験者は、context: fork がエージェントチームドキュメントのサブエージェントコンテキスト隔離と同じ隔離セマンティクスであることを認識するだろう。サブエージェントはコーディネーターの会話履歴を継承せず、フォークされたスキルはその内部をメイン会話に漏らさない。二つのメカニズムは従兄弟だ：一方はエージェントオーケストレーションレベルに、他方は Claude Code スキル実行レベルにある。

allowed-tools — スキル実行中のツールアクセスの制限

allowed-tools フロントマターフィールドは、スキルが実行中に使用を許可されているツールのサブセットを指定する。これはパフォーマンスの最適化ではなく、セキュリティと安全性の境界だ。

なぜツールを制限するか

Claude Code のデフォルトのツールサーフェスには Read・Write・Edit・Bash・Grep・Glob・および MCP が提供するツールが含まれる。ファイルを読み込んでレポートを生成するだけのはずのスキルは、任意の Bash コマンドを実行できるべきではない。間違いやプロンプトインジェクションが損害を引き起こす可能性があるからだ。Markdown ファイルを生成するはずのスキルは、ソースコードに対して Edit ツールを呼び出せるべきではない。

allowed-tools はスキルの能力サーフェスを必要最小限に絞り込む。スキルが Read と Write のみを必要とする場合、Read と Write だけをリストする。後でプロンプトインジェクションがスキルをだまして rm -rf を実行させようとしても、Bash ツールは許可リストになく、試みは失敗する。

例：安全なレポートジェネレーター

---
name: release-notes
description: Generate release notes from the last N commits.
context: fork
allowed-tools:
  - Read
  - Write
argument-hint: <number of commits, e.g. 20>
---

このスキルはファイルを読み込み、リリースノートをディスクに書き込むことができる。Bash を実行できず、ソースファイルを編集できず、ウェブ検索を呼び出せない。開発者が後でプロンプトに Bash の指示を含めても、そのツールは許可されておらず、スキルは拒否する。

サブエージェントツール許可リストとの関係

ドメイン 1 を読んだ読者は、allowed-tools が「カスタムサブエージェントの作成」ドキュメントに記述されているサブエージェントツール許可リストの SKILL.md アナログであることを認識するだろう。同じ原則：ツールサーフェスを必要最小限に絞り込み、リスト外のあらゆるものに対してフェイルクローズする。

argument-hint — 必要なパラメータの UX

argument-hint フロントマターフィールドは何も強制しない。それは純粋に UX の配慮だ。開発者が期待される引数なしでスキル（またはスラッシュコマンド）を呼び出すと、Claude Code はヒントテキストを表示して入力を促す。これは作者が使い方を説明するために存在しない共有プロジェクトスコープのスキルで重要だ。

一般的なパターン：

argument-hint: <ticket ID, e.g. PROJ-123>
argument-hint: <source version and target version, e.g. "v3 -> v4">
argument-hint: <comma-separated list of file globs to audit>

ヒントはスキル名の隣の /help リストに表示され、開発者が引数なしでコマンドを入力すると inline で表示される。ヒントがなければ、開発者は SKILL.md ファイルを読むか推測するかしかなく、どちらも共有ツールが排除すべき摩擦だ。

三つのフロントマターフィールドの一つのメンタルモデル

CCA-F でテストされる三つのフロントマターフィールドを覚えるコンパクトな方法：

• context: fork — 隔離：サブエージェントで実行し、メインコンテキストをきれいに保つ。
• allowed-tools — 安全性：能力サーフェスを絞り込み、リスト外のツールに対してフェイルクローズする。
• argument-hint — 使いやすさ：開発者に供給すべきパラメータを伝える。

三つの軸：隔離・安全性・使いやすさ。すべてのスキル定義はこれら三つのトレードオフを行う。試験問題は通常、1 問につき 1 つの軸をターゲットにする。

~/.claude/skills/ を通じた個人スキルカスタマイズ

スラッシュコマンドに適用されるプロジェクト対ユーザーの二重性はスキルにも等しく適用される。プロジェクトスキルは .claude/skills/ に存在し git で共有される。個人スキルは ~/.claude/skills/ に存在し開発者のマシンに留まる。

チームメイトを壊さないチームスキルのカスタマイズ

一般的なシナリオ：開発者は自分の好みのトーンと構造を持つチームの release-notes スキルの修正版が欲しい。間違ったアプローチは、プロジェクトスコープの release-notes SKILL.md を編集することで、チームメイト全員のワークフローを壊してしまう。正しいアプローチは、スキルを別の名前（例：release-notes-personal）で ~/.claude/skills/ にコピーし、そこでカスタマイズすることだ。

二つのディレクトリは独立して検索されスキル名でインデックス化されているため、個人バージョンはプロジェクトバージョンと共存する。開発者はチームバージョンに /release-notes、カスタマイズ版に /release-notes-personal で呼び出せる。

なぜ異なる名前が重要か

個人スキルがプロジェクトスキルと同じ名前を使うと、解決順序が機能する。プロジェクトバージョンが通常そのリポジトリで優先され、個人バージョンは事実上デッドコードになる。異なる名前を使うとシャドーイングの問題を完全に回避し、両方のスキルが発見可能に保たれる。

三層のメンタルモデル

すべてをまとめると、Claude Code のカスタムスラッシュコマンドとスキルシステムは三層で動作する：

1. 組み込みコマンド（/clear・/compact・/help・/review など）— Claude Code に付属し、設定不要。
2. プロジェクトスコープのコマンドとスキル（.claude/commands/・.claude/skills/）— バージョン管理を通じてチームメイトと共有。
3. ユーザースコープのコマンドとスキル（~/.claude/commands/・~/.claude/skills/）— 個人的で、決して開発者のマシンを離れない。

解決は特異性グラジエントに従う：開発者がいるリポジトリに対して最も適用範囲が狭い定義が優先される。

スキル vs CLAUDE.md：オンデマンドと常時ロードの区別

タスク 3.2（カスタムスラッシュコマンドとスキル）とタスク 3.1（CLAUDE.md の設定）は隣接しており、試験は受験者がそれらを区別できるかどうかをテストする。それらを明確にするメンタルモデルはオンデマンド呼び出し vs 常時ロードのユニバーサルスタンダードだ。

CLAUDE.md：常時ロードのユニバーサルスタンダード

CLAUDE.md ファイルは、関連するディレクトリのすべての Claude Code セッションの開始時に自動的に読み込まれる。それらはリポジトリで Claude が行うすべてのことに適用されるルール（コーディングスタイル・命名規則・テスト要件・アーキテクチャの原則・セキュリティガイドライン）をエンコードする。開発者はオプトインしない；ルールは常に存在する。

CLAUDE.md が正しい選択の場面：

• ユニバーサルコーディング規則（「4 スペースインデントを使う」「すべての編集後に npm test を実行する」）。
• アーキテクチャ上の制約（「legacy/ から core/ への import は禁止」）。
• セキュリティルール（「シークレットをコミットするな、環境変数を使え」）。
• プロジェクト全体のスタイル（「PR タイトルには Conventional Commits を使う」）。

スキル：オンデマンドのワークフロー

スキルは開発者が /skill-name と入力することで明示的に呼び出される。それらは特定の状況に適用されるワークフロー（コードレビュー・マイグレーション・リリース・監査）をエンコードする。常時オンではなく、オプトインだ。

スキルが正しい選択の場面：

• 開発者が特定の瞬間にトリガーするマルチステップのワークフロー（「今週のリリースノートを下書きする」）。
• 開発者が呼び出しごとに提供するパラメータを持つワークフロー（「v3 から v4 にマイグレートする」）。
• メイン会話を保護するために隔離されたサブエージェントコンテキストで実行されるべきワークフロー（context: fork）。
• メイン会話が継承すべきでないツール制限が必要なワークフロー（allowed-tools）。

決定の問い

シナリオ問題が「これはスキルか CLAUDE.md エントリであるべきか？」と問う場合、決定の問いは：このルールはこのリポジトリのすべての Claude の返答に適用されるべきか、それとも開発者によって明示的に呼び出されたときのみか？

• 常に適用 → CLAUDE.md。
• 呼び出された時のみ → スキル（またはスラッシュコマンド）。

一回限りのワークフローを CLAUDE.md に置けば、リポジトリのすべての Claude の返答がプロンプトを継承し、コンテキストを膨らませ、無関係なインタラクションを混在させる。ユニバーサルスタンダードをスキルに置けば、開発者は呼び出すのを忘れてスタンダードが静かに違反される。

白話文解釋（平易な言葉での解説）

抽象的な設定分類は物理的な日常システムに固定されると直感的になる。三つの非常に異なる比喩がカスタムスラッシュコマンドとスキルの全体像をカバーする。

比喩 1：板前の調理場 — 組み込みの道具・チームのレシピ帳・個人のノート

共有の本格的な調理場を想像してほしい。Claude Code の組み込みスラッシュコマンドは、どんな厨房にもある標準的な道具（包丁・スプーン・おたま）だ。厨房と一緒に来る；インストールしない。.claude/commands/と.claude/skills/ の**プロジェクトスコープのコマンドとスキル**は、厨房の棚に置かれているチームのレシピ帳だ。そのシフトで働くすべての板前が同じレシピ帳を引き出し、同じレシピに従い、同じ料理を作る。新入りは初日にレシピ帳を読める。/.claude/commands/と/.claude/skills/` のユーザースコープのコマンドとスキル**は、板前がエプロンのポケットに入れて持ち運ぶ個人のノート（微調整・近道・誰も見ない工夫）だ。板前がチームのレシピ帳を編集すれば、すべてのチームメイトに影響する。板前が個人のノートを更新しても、気づくのはその板前だけだ。

context: fork フラグは、複雑な料理のために別の仕込み台に送られてそこで野菜を切り、切り終わったら仕上がった仕込みだけをメインの調理台に持ってくる補助板前だ。散らかった切り仕事・皮・玉ねぎの涙、これらはメインの調理台に触れない。きれいな仕込みだけが届く。allowed-tools リストは「この見習いは柳刃包丁とスライサーは使ってよいがバーナーは使ってはいけない」というルールだ。argument-hint はレシピカードに貼られたメモ（「この料理にはタンパク質が必要 — 始める前に鶏か魚かを選んでください」）だ。

この比喩はすべての中核的なカスタムスラッシュコマンドとスキルの概念をマッピングする：組み込み vs チーム vs 個人；共有 vs プライベート；隔離されたサブコンテキスト；絞り込まれた能力；引数の促し。

比喩 2：大学図書館 — カタログ化された手順 vs 閲覧室のルール

大学の図書館には 2 種類の指示がある。すべての壁・すべての閲覧室に掲示されているのは常時存在するルール：静寂・飲食禁止・本は正しい棚に返す。これらのルールは誰も呼び出さずにすべての来館者にすべての瞬間に適用される。それが CLAUDE.md だ。

参考カウンターのカードファイルには手順のレシピがある：図書館間貸し出しのリクエスト方法・グループ学習室の予約方法・文書スキャンの依頼方法。これらの手順は来館者がカウンターに来て具体的にリクエストした時のみ適用される。司書は正しいカードを引き出し・ステップを読み・実行する。異なる来館者が異なる手順を呼び出す；ほとんどの来館者は何も呼び出さない。それがカスタムスラッシュコマンドとスキルシステムだ。

図書館がすべての手順レシピをすべての閲覧室の壁に貼ろうとしたら、壁は読めなくなり来館者は圧倒される。図書館が「飲食禁止」ルールをカードファイルに入れようとしたら（呼び出された時のみ適用）、来館者は貴重書室でサンドイッチを食べるだろう。ルールと手順は呼び出しパターンが異なるため、異なるコンテナに属する。

この比喩は、ワークフローを CLAUDE.md に詰め込む（「常に適用されるから！」）受験者と、ユニバーサルスタンダードをスキルに押し込む（「開発者は実行を覚えているはずだ！」）受験者が試験で落点する理由を明確にする。コンテナは互換ではない。

比喩 3：電子工作のワークショップ — チームの引き出し・個人の引き出し・安全ケージ

共有の電子工作ワークショップを想像してほしい。各作業台にはチームの引き出しがボルトで固定されている：そのベンチで作業するすべての人が同じハンダごて・フラックス・回路図を受け取る。それが .claude/commands/ と .claude/skills/ だ。各技術者はまたベンチからベンチへと個人の引き出しを運ぶ（好みのピンセット・自分のルーペ・工夫のノート）。それが ~/.claude/commands/ と ~/.claude/skills/ だ。

いくつかの手順（高電圧回路の作業）は安全ケージで行われる：独自の電源・独自の換気・独自のツールラックを持つ別の密閉エリア。技術者はケージに入り・作業を行い・出て・メインのクリップボードに要約を書く。ケージはベンチの残りの部分からヒュームと火花を遠ざける。それが context: fork だ。隔離によってメインコンテキストをスキルの内部から保護する。

安全ケージはまた allowed-tools の実施が行われる場所でもある。ケージのツールラックには手順に安全なツールだけが収められている。ケージに入る技術者はワークショップのツールベルト全体を持ち込まない。ケージが提供するものを使うか、作業を完了できないかだ。それが allowed-tools の能力を絞り込む安全ポスチャーだ。argument-hint はケージの外の看板（「入る前に電圧とコンポーネントの種類を述べてください」）で、手順が必要とするパラメータを促す。

試験当日にどの比喩を使うか

• プロジェクト vs ユーザースコープに関する問題 → 調理場の比喩（チームのレシピ帳 vs 個人のノート）。
• スキル vs CLAUDE.md に関する問題 → 図書館の比喩（カードファイル vs 壁のポスター）。
• context: fork と allowed-tools に関する問題 → ワークショップの比喩（独自のツールラックを持つ安全ケージ）。

スコーピングの優先順位と CLAUDE.md との相互作用

Claude Code の設定システムは階層的だ。単一の Claude Code セッションは、組み込みコマンド・プロジェクトスコープのコマンドとスキル・ユーザースコープのコマンドとスキル・関連する CLAUDE.md ファイルを見ることができる。優先順位を理解することは、デバッグと特定の動作が観察される理由についての試験問題に合格するために重要だ。

スラッシュコマンドとスキルの優先順位

入力されたコマンド名の解決順序は：

1. 現在のリポジトリのプロジェクトスコープ（.claude/commands/・.claude/skills/）。
2. ユーザースコープ（~/.claude/commands/・~/.claude/skills/）。
3. 組み込み（Claude Code に付属するコマンド）。

コマンド名が複数の場所に存在する場合、プロジェクトスコープのバージョンがそのリポジトリで優先される。これはチームがチームのコードベース内で開発者の個人的な好みをオーバーライドしながら、個人バージョンを他のどこでも使用できるようにすることを可能にする。

CLAUDE.md との相互作用

CLAUDE.md は自動的に読み込まれ；スキルとスラッシュコマンドは呼び出し時に読み込まれる。スキルが実行されると、スキルが context: fork を使う場合を除いて CLAUDE.md ルールがまだ有効だ。その場合、サブエージェントは CLAUDE.md を新しく読み込み（CLAUDE.md 階層に従って）、それらのルールを持ちながらメイン会話の蓄積されたコンテキストなしでスキルを実行する。

CCA-F に関連する微妙な点：フォークされたスキルがサブエージェントで実行されるとき、メイン会話の途中の判断・明確化・訂正を継承しない。メイン会話が「常に YAML を使い、JSON は使わない」を確立していても、CLAUDE.md とスキルプロンプトのみを読むフォークされたスキルはその途中の指示を見ない。これはドメイン 1 のサブエージェント問題が活用するのと同種のコンテキスト隔離の落とし穴だ。

典型的な試験の罠：スコープの混同とフロントマターの間違い

CCA-F はカスタムスラッシュコマンドとスキルに関連する 5 つの繰り返しパターンを積極的に活用する。

罠 1：.claude/commands/ vs ~/.claude/commands/ の入れ替え

回答選択肢がディレクトリパスを逆にする。試験ガイドのサンプル Q4「チームは共有の /review コマンドをどこに置くべきか」は .claude/commands/ が正解で、~/.claude/commands/ が最高品質の誤答選択肢だ。オプションをざっと見る受験者はチルダを見逃して間違ったディレクトリを選ぶ。パス文字を注意深く読むこと：先頭の . vs ~/. がプロジェクト vs ユーザースコープを決定する。

罠 2：スラッシュコマンドのホストとしての CLAUDE.md

誤答選択肢は「/review の指示を CLAUDE.md に置く」を提案する。CLAUDE.md はスラッシュコマンドのメカニズムではなく、常時ロードのルールファイルだ。ワークフローがオンデマンドで呼び出される必要がある場合（/review）、スラッシュコマンドまたはスキルとして存在しなければならず、CLAUDE.md のセクションとしてではない。

罠 3：並列実行として誤解された context: fork

「fork」と読んで並列実行を想定する受験者がいる。context: fork はコンテキスト隔離についてであり、並列実行についてではない。スキルはメイン会話と同時ではないが、独自の会話を持つ別のサブエージェントで実行される。ポイントはメインコンテキストを保持することであり、速く実行することではない。

罠 4：パフォーマンス設定として扱われた allowed-tools

誤答選択肢は allowed-tools をパフォーマンスの最適化（「ツール数を制限してレイテンシを削減する」）としてフレーミングする。それは誤りだ。allowed-tools は能力と安全性の境界だ。スキル（プロンプトインジェクションやずさんなテンプレートによって影響を受ける可能性がある）が破壊的なツールを呼び出すことを防ぐために存在する。レイテンシへの観察可能な効果は安全効果と比べると無視できる。

罠 5：プロジェクトスキルを編集して個人カスタマイズを行う

シナリオ：開発者がチームスキルの修正版を望む。間違った回答は「プロジェクトスコープの SKILL.md を編集する」だ。そのコミットはバージョン管理に変更をコミットし、すべてのチームメイトに影響を与え、おそらくチームの慣習に違反する。正しい回答は、スキルを別の名前で ~/.claude/skills/ にコピーしてそこでカスタマイズすることだ。

実践アンカー：Claude Code を使ったコード生成シナリオ

「Claude Code を使ったコード生成」シナリオは 6 つの CCA-F シナリオクラスターの一つで、任意の受験では 6 つのうち 4 つが登場する。カスタムスラッシュコマンドとスキルの問題はこのシナリオ内の 5 つのパターンに分類される。

テンプレート A：ディレクトリの選択

チームはプッシュ前にすべての開発者が標準化されたプルリクエストレビューを実行することを望む。/review コマンドの定義はどこに存在すべきか？正解：リポジトリルートの .claude/commands/review.md、バージョン管理にコミットされる。誤答選択肢は ~/.claude/commands/（個人のみ）または CLAUDE.md（常時ロード、呼び出しではない）を主張する。

テンプレート B：フロントマターの目的

スキル定義がフロントマターに context: fork を含む。その効果は何か？正解：スキルは隔離されたサブエージェントコンテキストで実行され、最終的な出力だけがメイン会話に返される。誤答選択肢は並列実行またはツールの優先順位付けを主張する。どちらも誤りだ。

テンプレート C：ツール制限の理由

セキュリティに焦点を当てたスキルがフロントマターに allowed-tools: [Read, Grep] を含む。なぜか？正解：スキルはファイルを読み込みパターンを検索できるが、ファイルを変更したり任意の Bash を実行したりできない。リスト外のツールの使用試みにフェイルクローズする安全境界だ。誤答選択肢はパフォーマンスチューニングまたは context window の削減を主張する。

テンプレート D：引数の UX

共有の /migration-planner スキルがフロントマターに argument-hint: <source version and target version, e.g. "v3 -> v4"> を含む。これは何をするか？正解：開発者が引数なしでコマンドを呼び出すと、Claude Code は期待されるパラメータ形式を示すヒントテキストで促す。誤答選択肢は引数の検証またはデフォルト値の割り当てを主張する。どちらも argument-hint がすることではない。

テンプレート E：スキル vs CLAUDE.md の配置

チームはリポジトリのすべてのインタラクションで特定のコミットメッセージ形式を使うことを望む。これはスキルに入れるべきか CLAUDE.md に入れるべきか？正解：CLAUDE.md。ルールは常に適用されるべきで、呼び出された時のみではない。誤答選択肢は「スキルは context: fork を使えるので」という理由でスキルが優れていると主張する。これはルールが常時ロードである必要があるため無関係だ。

暗記すべき主要な用語と数字

カスタムスラッシュコマンドとスキルは、小さく暗記可能な用語集を導入する。これらを繰り返すことは試験当日に直接報われる。

区別のメモ：CCA-F の認識 vs 本番ビルドの深度

CCA-F は 6 ヶ月以上の Claude 経験を持つソリューションアーキテクト向けの基礎認定として位置付けられている。カスタムスラッシュコマンドとスキルに関して認識と判断をテストする。正しいディレクトリを特定・フロントマターフィールドを挙げる・その目的を説明する・シナリオを正しいコンテナに対応付けることができるか？より高いレベルの認定、または実際の本番デプロイでは、SKILL.md ファイルをゼロから作成する・allowed-tools 内の MCP ツール統合を調整する・スキル実行トレースをデバッグする・チーム全体のスキルライブラリを設計することも追加で期待される。

CCA-F が期待すること

• .claude/commands/（プロジェクト）vs ~/.claude/commands/（ユーザー）とスキルの同じ二重性を認識する。
• 三つの SKILL.md フロントマターフィールド（context: fork・allowed-tools・argument-hint）を挙げ、それぞれが何をするかを説明する。
• 常時ロード vs オンデマンドのヒューリスティックを使ってシナリオをスキル vs CLAUDE.md コンテナに対応付ける。
• 試験ガイドサンプルの /review ディレクトリの罠を見つける。
• 異なる名前を持つ ~/.claude/skills/ を通じた個人スキルカスタマイズを説明する。

CCA-F が期待しないこと

• 完全なプロンプト本文とツールオーケストレーションを持つ本番の SKILL.md ファイルを作成する。
• スキルをライブの MCP サーバーと統合する。
• スキル実行トレースや fork-context 隔離の障害をプロトコルレベルでデバッグする。
• スキル間の依存グラフを持つチームスキルライブラリを設計する。

本番でスキルを実装しているなら、認識から構築の深度に移行した。これは価値があるが、CCA-F の問題が測定するものを超えている。

カスタムスラッシュコマンドとスキル よくある質問

CCA-F で .claude/commands/ と ~/.claude/commands/ の違いは何か？

.claude/commands/ はリポジトリのルートにあるプロジェクトスコープのディレクトリで、コードと並んでバージョン管理される。リポジトリをクローンするすべての開発者が同じスラッシュコマンドセットを受け取る。チーム共有コンテナだ。~/.claude/commands/ は開発者のホームディレクトリにあるユーザースコープのディレクトリで、決して git にコミットされない。個人的で、その開発者だけがそれらのコマンドを見る。CCA-F 試験ガイドのサンプル Q4 はこの正確な区別をテストする：チーム全体の /review コマンドは .claude/commands/（プロジェクト）に属し、~/.claude/commands/（個人）ではない。同じプロジェクト対ユーザーの二重性がスキルに適用される（.claude/skills/ vs ~/.claude/skills/）。

SKILL.md フロントマターの context: fork は何をするか？

context: fork は Claude Code にスキルを隔離されたサブエージェントコンテキストで実行するよう指示する。サブエージェントはスキルのステップ（ファイル読み込み・ツール呼び出し・中間の推論）を自身の会話で実行し、最終的な出力のみがメイン会話に返される。これはスキルの内部がメイン context window を汚染することを防ぎ、開発者のトークン予算を保持する。一般的なユースケース：数十のファイルを読む長時間の分析スキルはフォークするべきで、中間の Read 出力がメイントランスクリプトに蓄積されないようにする。開発者が対話的な改善のために中間の作業を inline で見ることを期待する場合はフォークしない。

スキル定義で allowed-tools を使う理由は何か？

allowed-tools はスキルが実行中に使用を許可されているツールサーフェスを絞り込む。パフォーマンス設定ではなく安全性と能力の境界だ。レポート生成スキルは allowed-tools: [Read, Write] を宣言することで、ソースファイルを読み込んでレポートを書くことはできても、Bash を実行したりソースコードを Edit したりできない。プロンプトインジェクションやずさんなテンプレートがスキルをだまして破壊的なコマンドを実行させようとしても、そのツールは許可リストになく試みはフェイルクローズする。同じ論理が CCA-F シラバス全体に適用される。サブエージェントも同様の安全上の理由でツール許可リストを使う。

スキルを使うのか CLAUDE.md エントリを使うのかをどう判断するか？

リポジトリのすべての Claude Code インタラクションに適用されるべき常時ロードのユニバーサルスタンダードには CLAUDE.md を使う（コーディングスタイル・命名規則・テスト要件・セキュリティルール・アーキテクチャ上の制約）。開発者が特定の瞬間にトリガーするオンデマンドのワークフローにはスキル（またはスラッシュコマンド）を使う（コードレビュー・マイグレーション・リリースノート・監査）。決定の問いは：このルールはこのリポジトリのすべての Claude の返答に適用されるべきか、それとも明示的に呼び出された時のみか？「常に適用」→ CLAUDE.md。「呼び出された時のみ」→ スキル。CLAUDE.md にオンデマンドのワークフローを置くとすべてのセッションでコンテキストが膨らむ；ユニバーサルスタンダードをスキルに置くと開発者は呼び出しを忘れる。

チームメイトに影響を与えずにチームスキルをカスタマイズするにはどうすればよいか？

スキルをユーザースコープのディレクトリ ~/.claude/skills/ に別の名前でコピーする（たとえば -personal またはイニシャルを追加する）。その個人的なコピーをカスタマイズする。オリジナルのチームスキルは .claude/skills/ に残り、すべてのチームメートに対して引き続き機能する；個人バージョンは個人名を呼び出したときに実行される。プロジェクトスコープの SKILL.md を直接編集しないこと。そのコミットはすべてのチームメートに影響しチームの慣習に違反する可能性が高い。ユーザーディレクトリでプロジェクトスキルと同じ名前を使わないこと。プロジェクトバージョンがリポジトリごとにシャドーイングし、個人バージョンは静かに非アクティブになる。

argument-hint は正確に何をするか？

argument-hint は UX の配慮だ。開発者が期待される引数を指定せずにコマンドまたはスキルを呼び出すと、Claude Code はヒントテキストを表示して期待されるパラメータを示す。たとえば argument-hint: <ticket ID, e.g. PROJ-123> は開発者にコマンドがその形式のチケット識別子を期待していることを伝える。ヒントはコマンド名の隣の /help リストにも表示される。argument-hint は引数を検証しない・スキーマを強制しない・デフォルト値を提供しない。純粋に開発者への入力の促しだ。共有プロジェクトスコープのコマンドでは、良い argument-hint が文書化されていないコマンドに共通する「呼び出したのに何も起きなかった」という混乱を防ぐ。

スキルとスラッシュコマンドは CLAUDE.md のルールを継承するか？

非フォークのスキルとスラッシュコマンドはメイン会話のコンテキストで実行されるため、CLAUDE.md ルールを自然に継承する。CLAUDE.md はセッションの開始時にすでに読み込まれていた。フォークされたスキル（context: fork）はサブエージェントで実行される；そのサブエージェントは CLAUDE.md 階層に従って CLAUDE.md を新しく読み込むが、メイン会話の途中の指示を継承しない。メイン会話が「YAML のみを使う」をやり取りの中で確立していても、フォークされたスキルはその指示を見ない。これはドメイン 1 のサブエージェントが公開するのと同じ隔離セマンティクスだ。

この落とし穴に備えるため、永続的なチームスタンダードを CLAUDE.md に置く（フォークされたサブエージェントがそれらを見る場所）。サブエージェントが継承できない途中の会話での明確化に頼らない。

さらなる学習リソース

• Claude Certified Architect Foundations 試験ガイド: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Custom slash commands and skills — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/slash-commands
• CLAUDE.md configuration — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Claude Code settings reference: https://docs.anthropic.com/en/docs/claude-code/settings
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents

関連 ExamLab トピック: CLAUDE.md 階層とスコーピング、パス固有のルールと条件付き読み込み、プランモード vs 直接実行、Claude Code CI/CD 統合、サブエージェントとエージェントチーム。