はじめに
ども！龍ちゃんです。以前「Claude Code Skills 実装ガイド：ローカルツールをスムーズに統合する方法」という記事を書きました。おかげさまで「Claude Code Skills」というキーワードでの検索流入も増えてきています。
前回の記事では、CLAUDE.md にツール説明を書いても無視される問題 を Skills で解決する方法を紹介しました。Skills の「自動認識」機能により、トリガーワードで自動的にツールが使われるようになる、という話でしたね。
しかし、しばらく使っているうちに 新たな課題 が見えてきました。
「Skills でも発火しないことがある」
そうなんです。Skills は確かに CLAUDE.md よりも認識されやすいのですが、100% 確実に発火するわけではないんですよね。特に複雑なワークフローや、必ず特定の手順を踏んでほしい処理では、「発火しない」問題が致命的になることがあります。
この記事では、その解決策として Slash Commands を紹介します。結論から言うと、確実に発火させたい処理は Slash Commands に移行するのがベストです。
記事の位置づけ
この記事は、前回の「Claude Code Skills 実装ガイド」の 続編・発展編 です。
| 前回記事 | 今回の記事 |
|---|---|
| CLAUDE.md → Skills への移行 | Skills/CLAUDE.md → Slash Commands への移行 |
| 「自動認識」のメリット推し | 「確実な発火」のメリット推し |
| Progressive Loading の説明 | 読み込み順序・確実性の観点 |
前回記事を読んでいなくても理解できる内容ですが、併せて読むとより理解が深まります。
この記事で学べること
主要なポイント
- Skills/CLAUDE.md の限界: なぜ「発火しない」ことがあるのか
- Slash Commands の特徴: なぜ「確実に発火する」のか
- 移行事例: 実際の
/review、/researchコマンドの実装 - 各要素の住み分け: Hooks / Skills / Commands / CLAUDE.md の使い分け
実践的なテクニック
- Slash Commands のファイル構造と書き方
- YAML Frontmatter の活用（allowed-tools, description）
- AskUserQuestion を使ったインタラクティブなワークフロー
- 複数エージェントの連携
前提条件
必要な知識
- Claude Code の基本的な使用経験
- CLAUDE.md の基本的な理解
- Skills の概念（前回記事参照）
あると理解が深まる知識
- サブエージェント（Subagents）の概念
- Hooks の基本
問題提起: 「発火しない」問題
Skills の自動認識が機能しないケース
前回記事で紹介した Skills は、description に基づいてモデルが自動的に判断して適用します。しかし、この「自動判断」が裏目に出るケースがあります。
ケース1: 似たようなトリガーワードが複数ある
ユーザー: 「この記事をチェックして」
期待: technical-accuracy-reviewer が発火
実際: 単純にファイルを読んで「問題なさそうです」で終了
ケース2: コンテキストが長くなると判断が曖昧に
長い会話の後...
ユーザー: 「調べて」
期待: research Skill が発火してスコープ確認
実際: WebSearch で簡易検索して終了
ケース3: 複雑なワークフローの一部だけ実行
ユーザー: 「レビューして」
期待: 技術チェック → コンテンツ改善 → SEO評価 の順で実行
実際: 簡単なフィードバックだけで終了
CLAUDE.md が無視されるケース
CLAUDE.md に詳細なワークフローを書いても、同様の問題が起きます。
# CLAUDE.md
## レビューワークフロー
記事のレビューを依頼された場合は、以下の順序で実行してください：
1. technical-accuracy-reviewer でセキュリティチェック
2. content-reviewer でコンテンツ品質評価
3. blog-reviewer でSEO評価とタイトル生成
問題点:
- CLAUDE.md は常時読み込まれるが、長くなると相対的に優先度が下がる
- 「レビューして」という曖昧な指示では、このワークフローが適用されない
- モデルの判断に依存するため、確実性がない
技術的な背景: 読み込みタイミングの違い
なぜこのような問題が起きるのか、読み込みタイミングの観点から説明します。
| 機能 | 読み込みタイミング | 確実性 |
|---|---|---|
| CLAUDE.md | セッション開始時に全文 | △ 埋もれる可能性 |
| Skills | メタデータのみ → マッチ時に本文 | △ マッチ判断はモデル依存 |
| Slash Commands | ユーザーが /command 入力時 | ◎ 100%確実 |
Slash Commands はユーザーが明示的に呼び出すため、読み込みタイミングに曖昧さがありません。/review と入力すれば、必ず review.md の内容が読み込まれます。
解決策: Slash Commands
Slash Commands とは
Slash Commands は、.claude/commands/ ディレクトリに配置した Markdown ファイルを、/コマンド名 で呼び出す機能です。
.claude/commands/
├── review.md → /review で呼び出し
├── research.md → /research で呼び出し
└── plan.md → /plan で呼び出し
なぜ「確実に発火する」のか
Slash Commands が確実な理由は単純です：
- ユーザーが明示的に入力:
/reviewと入力 = 意図が明確 - 即座に読み込み: コマンドファイルの内容が即座にプロンプトに追加
- モデル判断なし: Skills のような「使うかどうか」の判断がない
Skills の場合:
ユーザー入力 → モデルが判断 → Skill を使う/使わない
Slash Commands の場合:
ユーザー入力 /review → review.md を読み込み → 実行
Slash Commands のファイル構造
---
description: コマンドの説明（/help で表示される）
allowed-tools: Read, Task, AskUserQuestion
argument-hint: [ファイルパス]
---
# コマンドの指示内容
ここに Claude への指示を記述します。
$ARGUMENTS で引数を受け取れます。
YAML Frontmatter のフィールド:
| フィールド | 必須 | 説明 |
|---|---|---|
| description | 任意 | /help で表示される説明 |
| allowed-tools | 任意 | 使用を許可するツール |
| argument-hint | 任意 | 引数のヒント |
| model | 任意 | 使用するモデル（haiku, sonnet など） |
移行事例
実際に僕が Skills/CLAUDE.md から Slash Commands に移行した事例を紹介します。
事例1: CLAUDE.md → /review
Before: CLAUDE.md にワークフロー記載
# CLAUDE.md
## レビューワークフロー
記事のレビューを依頼された場合は、以下のエージェントを使い分けてください：
1. technical-accuracy-reviewer: 技術的正確性とセキュリティ
2. content-reviewer: コンテンツ品質の反復改善
3. blog-reviewer: 公開前の包括的評価
4. seo-title-generator: タイトルとメタディスクリプション
### 推奨フロー
1. まず technical-accuracy-reviewer で技術チェック
2. content-reviewer で品質改善（必要に応じて複数回）
3. blog-reviewer で最終確認
問題点:
- 「レビューして」と言っても、このフローが適用されない
- エージェント名を明示しないと使われない
- 複数エージェントの連携が実行されない
After: /review コマンド
---
description: ブログ記事のレビューを実施。技術的正確性チェック、コンテンツ品質改善、SEO最適化、タイトル生成を支援します。
allowed-tools: Read, Task, AskUserQuestion
---
# Article Review Command
ブログ記事のレビューを実施します。ユーザーの目的や状況に応じて、最適なエージェントを選択・実行します。
## Usage
/review [ファイルパス]
## Available Review Agents
### 1. technical-accuracy-reviewer
**特化領域**: 技術的正確性 + セキュリティ
**こんな時に使う**:
- 初稿が完成した時
- 技術的な内容が正しいか心配
- セキュリティリスクがないか確認したい
### 2. content-reviewer
**特化領域**: コンテンツ品質（反復改善用）
**こんな時に使う**:
- 執筆中で何度も改善したい
- 可読性を向上させたい
### 3. blog-reviewer
**特化領域**: 包括的評価（最終確認用）
**こんな時に使う**:
- 公開前の最終確認
- コンテンツとSEOの両方を評価したい
## Execution Flow
### Step 1: 記事ファイルの確認
ユーザーがファイルパスを提供している場合、Read ツールで記事内容を確認。
### Step 2: ユーザーの意図判断
AskUserQuestion ツールを使用して、ユーザーに選択肢を提示。
### Step 3: エージェントの実行
選択に基づいて、適切なエージェントを Task ツールで実行。
改善点:
/reviewと入力すれば 確実に このワークフローが開始- AskUserQuestion でユーザーの意図を確認
- 複数エージェントの連携が保証される
事例2: Skills → /research
Before: Skills として登録
# .claude/skills/research.md
---
name: research
description: Web調査を実施し、技術トピックについて調査します。
---
## When to Use
- ユーザーが「調べて」「調査して」と依頼した場合
- 技術トピックについて情報収集が必要な場合
## Commands
WebSearch と WebFetch を使用して調査を実施します。
問題点:
- 「調べて」と言っても、簡易検索で終わることがある
- 調査深度の確認なしに実行される
- 調査結果の保存形式が統一されない
After: /research コマンド
---
description: Web調査を実施し、結果を docs/research に保存。技術トピック、公式ドキュメント、最新動向などを調査します。
argument-hint: [調査トピック]
allowed-tools: WebSearch, WebFetch, Read, Write, AskUserQuestion
---
# Research Command
## Workflow
### Step 1: Clarify Research Scope
Before starting research, use AskUserQuestion to clarify:
- 調査の深さ（クイック概要 / 標準調査 / ディープダイブ）
- 情報源の信頼性要件（高：公式のみ / 中：推奨 / 低：幅広く）
### Step 2: Conduct Research
Use WebSearch and WebFetch to gather information.
### Step 3: Save Results
Save the research document to docs/research/ with format:
YYYY-MM-DD-{topic-slug}.md
改善点:
/research トピックと入力すれば 確実に スコープ確認から開始- 調査深度をユーザーが選択できる
- 結果が統一されたフォーマットで保存される
各要素の住み分け
ここまでの内容を踏まえて、Claude Code の各拡張機能の住み分けを整理します。
呼び出し方式による分類
| 呼び出し方式 | 機能 | 確実性 | 適したユースケース |
|---|---|---|---|
| イベント駆動 | Hooks | ◎ 100% | 決定的処理（フォーマット、権限制御） |
| ユーザー明示的 | Slash Commands | ◎ 100% | 確実に発火させたいワークフロー |
| モデル自動判定 | Skills, Agents | △ 不確実 | 自動適用してほしい知識・処理 |
| 常時読み込み | CLAUDE.md | △ 埋もれる | プロジェクト全体の指針 |
選択フローチャート
タスクを自動化したい
│
├── LLMに依存しない決定的処理？
│ └── Yes → Hooks
│ ├── ツール実行前後 → PreToolUse / PostToolUse
│ └── 権限制御 → PermissionRequest
│
├── 確実に発火させたい？
│ └── Yes → Slash Commands
│ └── /review, /research など
│
├── 自動で判断して適用してほしい？
│ └── Yes → Skills / Agents
│ └── トリガーワードで自動認識
│
└── プロジェクト全体に適用？
└── Yes → CLAUDE.md
└── 開発ガイドライン、アーキテクチャ情報
具体的な使い分け例
| ユースケース | 推奨機能 | 理由 |
|---|---|---|
| 記事レビュー | /review | 複雑なワークフロー、確実に実行したい |
| Web調査 | /research | スコープ確認が必須、結果を統一フォーマットで保存 |
| ブログスクレイピング | Skills | URL を渡せば自動で判断してほしい |
| 自動フォーマット | Hooks (PostToolUse) | ファイル編集後に必ず実行 |
| コーディング規約 | CLAUDE.md | 常に意識してほしい全体ルール |
ベストプラクティス
1. 「確実性」が必要かで判断する
Slash Commands を選ぶべきケース:
- 複数ステップのワークフロー
- ユーザーへの確認が必須のプロセス
- 結果のフォーマットを統一したい処理
- 「毎回同じように実行してほしい」処理
Skills のままでよいケース:
- 単純なツール呼び出し
- トリガーワードが明確で誤認識がない
- 「自動で判断してくれればOK」な処理
2. AskUserQuestion を活用する
Slash Commands では、AskUserQuestion ツールを使ってユーザーの意図を確認できます。
## Step 1: ユーザーの意図確認
AskUserQuestion を使用して、以下を確認してください：
- 記事の現在の状態（初稿/執筆中/公開前）
- 実行したいレビュー項目（技術チェック/コンテンツ/SEO）
これにより、曖昧な指示でも適切な処理を実行できます。
3. allowed-tools で安全性を確保
---
allowed-tools: Read, Task, AskUserQuestion
---
コマンドで使用するツールを制限することで、意図しない操作を防げます。
4. 段階的に移行する
一度にすべてを移行する必要はありません：
- まず 問題が起きているワークフロー を Slash Commands に移行
- 効果を確認してから、他のワークフローも検討
- Skills で問題なく動いているものは、そのまま
まとめ
この記事では、Claude Code Skills の「発火しない」問題と、その解決策としての Slash Commands を紹介しました。
結論: 確実性で選ぶ
| 確実性 | 機能 | 使いどころ |
|---|---|---|
| ◎ 100% | Hooks | 決定的処理（フォーマット等） |
| ◎ 100% | Slash Commands | 確実に発火させたいワークフロー |
| △ 不確実 | Skills / Agents | 自動判断でOKな処理 |
| △ 埋もれる | CLAUDE.md | プロジェクト全体の指針 |
前回記事との関係
- 前回: CLAUDE.md → Skills への移行で「自動認識」を実現
- 今回: Skills → Slash Commands への移行で「確実な発火」を実現
どちらが優れているという話ではなく、適材適所で使い分けることが重要です。
次のステップ
- 「発火しない」問題が起きているワークフローを特定
- そのワークフローを Slash Commands に移行
- 効果を確認し、必要に応じて他も移行
参考リンク
公式ドキュメント
関連記事
ここまで読んでいただき、ありがとうございました！
Skills と Slash Commands、それぞれの特性を理解して使い分けることで、Claude Code との協業がさらにスムーズになります。ぜひ、この記事を参考に、あなたのプロジェクトでも実践してみてください。
