Claude Codeカスタムコマンド完全ガイド｜スラッシュコマンドで反復タスクを1コマンドに集約する実践パターン

——Claude Codeを使い始めると、毎回同じような指示を繰り返している自分に気づきます。「このファイルを読んで、こういう形式で出力して」「レビューする前に必ずこのチェックリストを確認して」——こうした反復作業を毎回手入力するのは、AIを使っているのに非効率です。AI活用完全ガイドで、AI活用の全体像を把握できます。

Claude Codeのカスタムコマンド機能を使えば、こうした反復的な指示を /コマンド名 のスラッシュコマンドとして定義し、ワンアクションで実行できます。開発ワークフローだけでなく、ブログ記事制作、データ分析、レポート生成といった非開発業務まで、あらゆる反復タスクの自動化に応用可能です。詳しくは「Claude Codeでチーム開発を効率化する方法」で解説しています。

本記事では、カスタムコマンドの基本構造から、実務で使える設計パターン、チームでの共有・運用まで、体系的に解説します。

関連する記事の一覧はClaude Code実践ガイドをご覧ください。

この記事でわかること

• Claude Codeのカスタムコマンド（スラッシュコマンド）の仕組みと、プロジェクト用・ユーザー用の使い分け
• SKILL.md設計を含む、業務自動化のためのコマンド設計パターンとプロンプトテンプレート化の手法
• チームでコマンドを共有・バージョン管理する方法と、運用で陥りがちな落とし穴

カスタムコマンドの基本構造

Claude Codeのカスタムコマンドは、Markdownファイルとして定義します。ファイルの置き場所によって、適用範囲が異なります。詳しくは「Claude Codeの企業導入セキュリティガイド」で解説しています。

コマンドの種類と配置先

プロジェクトコマンドはGitリポジトリに含まれるため、チームメンバーと共有できます。ユーザーコマンドは個人の環境にのみ存在し、どのプロジェクトでも利用できるグローバルなコマンドです。詳しくは「Claude Code × CI/CD」で解説しています。

コマンドファイルの書き方

カスタムコマンドのファイルは、Markdown形式で記述します。ファイル名がそのままコマンド名になります。

例: .claude/commands/review.md

このプロジェクトのコーディング規約に基づいて、直近の変更をレビューしてください。

## レビュー基準

1. TypeScriptの型定義が適切か
2. エラーハンドリングが漏れていないか
3. テストカバレッジに影響する変更がないか
4. パフォーマンスに影響する変更がないか

## 出力形式

- 問題の重大度（Critical / Warning / Info）
- 該当ファイルと行番号
- 修正提案

git diff HEAD~1 の内容を対象としてください。

このファイルを配置すると、Claude Codeのセッション中に /review と入力するだけで、上記の指示が自動的に実行されます。

引数の受け渡し

カスタムコマンドでは $ARGUMENTS プレースホルダーを使って、実行時に引数を渡せます。

例: .claude/commands/analyze.md

$ARGUMENTS で指定されたファイルを読み込み、以下の観点で分析してください。

1. コードの複雑度（循環的複雑度）
2. 依存関係の数
3. テスタビリティ
4. リファクタリングの推奨事項

実行時: /analyze src/components/Dashboard.tsx

ここが結構ミソなのですが、$ARGUMENTS は単一の文字列として展開されるため、複数の引数をスペース区切りで渡した場合も、1つの文字列として処理されます。複雑な引数パースが必要な場合は、コマンド内で明示的にフォーマットを指定するのがコツです。

出典: Anthropic公式ドキュメント: Claude Code Custom Slash Commands

実務で使える設計パターン7選

パターン1: コードレビューコマンド

最も使用頻度が高いパターンです。プロジェクト固有のコーディング規約やアーキテクチャルールを含めることで、一貫したレビュー品質を維持できます。

# Code Review Command

## 事前確認
以下のファイルを読み込んで、プロジェクトの規約を把握してください。
- .eslintrc.js（リント設定）
- tsconfig.json（TypeScript設定）
- CONTRIBUTING.md（コーディング規約）

## レビュー対象
git diff --staged の内容をレビューしてください。

## チェックリスト
- 型安全性: any型の使用がないか
- エラー処理: try-catchが適切に配置されているか
- 命名規約: camelCase / PascalCase の統一
- コメント: 複雑なロジックにJSDocコメントがあるか
- セキュリティ: ハードコードされたシークレットがないか

パターン2: ブログ記事制作コマンド

開発以外の用途でも、カスタムコマンドは威力を発揮します。

# Blog Article Generator

$ARGUMENTS で指定されたキーワードに基づいて、SEO最適化されたブログ記事を生成してください。

## 記事要件
- 文字数: 3,000〜5,000文字
- 構造: H1 → リード文 → H2×4〜6セクション → まとめ → FAQ
- テーブル: 2つ以上
- FAQ: 5つ以上（JSON-LD構造化データ付き）

## SEOルール
- メタディスクリプション: 120文字以内
- H2にキーワードを自然に含める
- 内部リンクを3つ以上含める

## 禁止事項
- 匿名の「A社」「B社」の使用
- チェックボックス記法（[ ] [x]）
- TL;DRラベル

パターン3: テスト生成コマンド

# Test Generator

$ARGUMENTS で指定されたファイルのテストを作成してください。

## テスト方針
- テストフレームワーク: Vitest
- カバレッジ目標: 80%以上
- テスト構造: describe → it で階層化
- 正常系・異常系・エッジケースを網羅
- モック: 外部APIコールはすべてモック化

パターン4: データベースマイグレーション生成

# DB Migration Generator

$ARGUMENTS の内容に基づいて、Supabaseのマイグレーションファイルを生成してください。

## ルール
- ファイル名: supabase/migrations/YYYYMMDDHHMMSS_{description}.sql
- RLS（Row Level Security）ポリシーを必ず含める
- DOWN マイグレーション（ロールバック）もコメントで記載
- 既存テーブルの確認: supabase/migrations/ 内の既存マイグレーションを確認

パターン5: コミットメッセージ生成

# Smart Commit

ステージングされた変更（git diff --staged）を分析し、
Conventional Commits形式でコミットメッセージを生成してください。

## フォーマット
{type}({scope}): {description}

{body}

## typeの選択基準
- feat: 新機能
- fix: バグ修正
- refactor: リファクタリング
- docs: ドキュメント
- test: テスト
- chore: 雑務

日本語で記述してください。

パターン6: API連携レポート生成

# Report Generator

以下のデータソースから情報を取得し、週次レポートを生成してください。

## データソース
1. git log --since="1 week ago" --oneline（開発進捗）
2. package.json の変更差分（依存関係の更新）

## レポート構造
- 今週の成果（箇条書き3〜5項目）
- 主要な変更点（技術的な説明）
- 来週の予定（TODOから推定）
- リスク・課題

パターン7: ドキュメント更新コマンド

# Sync Docs

コードの変更に基づいて、関連するドキュメントを更新してください。

## 対象
- README.md のセットアップ手順
- docs/ 配下のAPIドキュメント
- CHANGELOG.md

## ルール
- コードとドキュメントの整合性を確認
- 新しいAPIエンドポイントがあればドキュメントに追加
- 破壊的変更がある場合は明示的に記載

SKILL.md設計: コマンドの設計思想を体系化する

カスタムコマンドが増えてくると、個別のコマンドファイルだけでは管理が難しくなります。そこで有効なのが、SKILL.mdを使ったスキル設計です。

SKILL.mdは、コマンドの背景にある設計思想・ルール・制約を記述するドキュメントです。コマンドファイルが「何をやるか」を定義するのに対し、SKILL.mdは「なぜそうするのか」「どういうルールに従うのか」を定義します。

SKILL.mdの構成例

# ブログ記事制作スキル

## 概要
SEO最適化されたブログ記事を生成するスキル。

## 前提知識
このスキルを使う前に、以下のファイルを読み込むこと:
- blog_production_workflow.md（制作パイプライン）
- master_keyword_map.md（既存記事のキーワード一覧）

## 実行ステップ
1. キーワード調査
2. 構成案作成
3. 本文執筆
4. 品質レビュー（90点以上必須）
5. 公開

## 禁止事項
- 匿名事例の使用
- 内部情報の開示
- 500文字未満の記事公開

## 品質基準
- 文字数: 3,000〜5,000文字
- テーブル: 2つ以上
- FAQ: 5つ以上

SKILL.mdをCLAUDE.mdから参照する構成にしておけば、Claude Codeが自動的にスキルの設計思想を理解した上でコマンドを実行してくれます。

この仕組みは、Claude Codeのメモリ・コンテキスト管理で解説するプロジェクト知識の永続化とも密接に関連しています。

チームでの共有と運用

Gitリポジトリでの管理

プロジェクトコマンドは .claude/commands/ に配置するため、Gitで自然にバージョン管理されます。

.claude/
├── commands/
│   ├── review.md          # コードレビュー
│   ├── test.md            # テスト生成
│   ├── commit.md          # コミットメッセージ
│   ├── deploy-check.md    # デプロイ前チェック
│   └── report.md          # 週次レポート
├── settings.json          # Claude Code設定
└── CLAUDE.md              # プロジェクト知識ベース

コマンドの命名規則

チームで運用する場合、命名規則を統一しておくことが重要です。

チーム導入のステップ

1. 個人で試す: まず自分の反復タスクを3〜5個コマンド化する
2. チームに共有: 効果の高いコマンドをプロジェクトリポジトリに追加
3. フィードバック収集: メンバーからの改善要望を反映
4. 定期的な棚卸し: 使われていないコマンドの削除、新規コマンドの追加

出典: Anthropic公式ブログ: Best practices for using Claude Code

コマンド設計のアンチパターン

アンチパターン1: 1つのコマンドに詰め込みすぎる

# ❌ BAD: すべてを1つのコマンドに
コードレビューして、テスト書いて、ドキュメント更新して、コミットして、
PRも作成してください。

1つのコマンドが多くの責務を持つと、途中で失敗した場合のリカバリーが困難です。1コマンド = 1責務が原則です。

アンチパターン2: コンテキスト依存の暗黙知

# ❌ BAD: 暗黙知に依存
いつものフォーマットでレビューして。

「いつもの」はClaude Codeには伝わりません。レビュー基準、出力フォーマット、チェック項目を明示的に記述する必要があります。

アンチパターン3: 巨大なプロンプト

コマンドファイルが数百行に膨れ上がると、Claude Codeのコンテキストウィンドウを圧迫し、パフォーマンスが低下します。大きなコマンドは分割するか、参照先ファイル（SKILL.md等）に分離してください。

Hooksとの連携で自動化をさらに強化する

カスタムコマンドは「手動でトリガーする自動化」ですが、Claude Code Hooksと組み合わせることで「イベント駆動の自動化」も実現できます。

例えば:

• ファイル保存時に自動的にlintを実行（Hooks）
• コミット前にレビューコマンドを実行（Hooks + Command）
• PR作成時に自動テスト生成（Hooks + Command）

この組み合わせにより、開発ワークフロー全体を自動化できます。

正直な限界と注意点

コマンドが万能ではない理由

• コンテキスト依存の判断: 「この変更は本当にリリースして大丈夫か」のような高度な判断は、コマンドだけでは対応できません。人間の最終判断が必要です
• 動的なワークフロー: 条件分岐が多い複雑なワークフローは、単一のコマンドファイルでは表現しきれないことがあります
• 外部サービスとの連携: コマンド内からAPI呼び出しを行う場合、認証情報の管理に注意が必要です

メンテナンスコスト

コマンドは「作って終わり」ではなく、プロジェクトの変化に合わせて更新し続ける必要があります。使われなくなったコマンドは定期的に削除し、コマンド一覧の棚卸しを月1回程度行うことを推奨します。

StartLinkのAI業務自動化支援

StartLinkでは、CRM特化型コンサルティングの一環として、Claude Codeのカスタムコマンド設計を含むAI業務自動化の支援を提供しています。

「HubSpot × Claude Code」の組み合わせにより、CRMデータの分析レポート自動生成、営業活動の記録自動化、マーケティングコンテンツの品質チェック自動化など、CRM運用に特化した自動化ワークフローを構築できます。

AI活用に興味のある企業の方は、お気軽にお問い合わせください。

よくある質問（FAQ）

Q1. カスタムコマンドとCLAUDE.mdの違いは何ですか？

CLAUDE.mdはプロジェクト全体の知識ベースで、セッション開始時に自動的に読み込まれます。カスタムコマンドは特定のタスクを実行するためのプロンプトテンプレートで、/コマンド名 で明示的に呼び出します。CLAUDE.mdが「常に参照されるルールブック」、カスタムコマンドが「必要時に呼び出す作業手順書」というイメージです。

Q2. カスタムコマンドの数に上限はありますか？

ファイル数としての上限はありませんが、実用上は20〜30個程度に収めるのが望ましいです。コマンドが多すぎると、どのコマンドを使うべきか迷う「コマンド選択のオーバーヘッド」が発生します。カテゴリごとにプレフィックスを付けて整理してください。

Q3. プロジェクトコマンドとユーザーコマンドはどう使い分けますか？

プロジェクト固有のルール（コーディング規約、テスト方針、ドキュメント形式など）に基づくコマンドはプロジェクトコマンドとして .claude/commands/ に配置します。個人的な作業パターン（メール文面生成、メモ整理など）はユーザーコマンドとして ~/.claude/commands/ に配置します。チームで共有すべきものはプロジェクトコマンド、個人の生産性向上が目的のものはユーザーコマンドと覚えてください。

Q4. コマンド内でファイルの読み込みを指示できますか？

はい、可能です。コマンド内で「以下のファイルを読み込んでください」と記述すれば、Claude Codeが自動的にファイルを読み取ります。例えば「CONTRIBUTING.md を読んで、そのルールに基づいてレビューしてください」のように指示できます。ただし、読み込むファイルが大きすぎるとコンテキストウィンドウを圧迫するため、参照先のファイルは簡潔にまとめておくことが重要です。

Q5. カスタムコマンドはClaude Code以外のツールでも使えますか？

カスタムコマンドはClaude Code固有の機能であり、ChatGPTやCursorでは直接使えません。ただし、コマンドの中身（プロンプトテンプレート）はMarkdownファイルなので、他のAIツールにコピペして流用することは可能です。プロンプトテンプレートとしての価値は、ツールに依存しません。