◉CLAUDE LABEN
●2.1.296 — サブエージェントごとに autoCompactWindow を指定でき、ワークフロー用のモデルも環境変数で固定できます●HAIKU 5.5 — 2.1.293(10/07)から claude-haiku-5-5 が Anthropic API の既定の Haiku モデルになりました●SONNET 4.5 — Claude API での提供終了は 11/30、残り47日。移行先は Sonnet 5.5●Q&A — Mod が「エラーなしで何も描かれない」ときに見る3か所が共有されています●AGENTS.MD — Codex と Claude Code を同じフォルダで使うとき、AGENTS.md と CLAUDE.md の入口をどう分けるかの整理が出ています●NEW — 「cd して git add して commit」の承認が毎回出るのは、設定の抜けではなく仕様でした●2.1.296 — サブエージェントごとに autoCompactWindow を指定でき、ワークフロー用のモデルも環境変数で固定できます●HAIKU 5.5 — 2.1.293(10/07)から claude-haiku-5-5 が Anthropic API の既定の Haiku モデルになりました●SONNET 4.5 — Claude API での提供終了は 11/30、残り47日。移行先は Sonnet 5.5●Q&A — Mod が「エラーなしで何も描かれない」ときに見る3か所が共有されています●AGENTS.MD — Codex と Claude Code を同じフォルダで使うとき、AGENTS.md と CLAUDE.md の入口をどう分けるかの整理が出ています●NEW — 「cd して git add して commit」の承認が毎回出るのは、設定の抜けではなく仕様でした
記事一覧/Claude Code
⟐ Claude Code/2026-03-22初級

Claude Code カスタムスラッシュコマンド — チーム開発を加速する自作コマンドの作り方

Claude Codeで自分だけのスラッシュコマンドを作る方法を解説します。.claude/commandsディレクトリを使った作成の仕組み、最初のコマンドの作り方、実践的なコマンド例、スキルとの違いの整理、チーム開発でコマンドを共有する活用パターンまでを一通り扱います。

Claude Code262スラッシュコマンドカスタムコマンド開発効率化8チーム開発4

Claude Code カスタムスラッシュコマンドとは

Claude Codeには /help や /compact といった組み込みコマンドが多数用意されていますが、実は自分だけのオリジナルコマンドを作成することもできます。カスタムスラッシュコマンドを使えば、繰り返し行う作業をワンコマンドで実行でき、チームメンバーとも簡単に共有できます。

たとえば「コードレビューの手順を毎回プロンプトで書くのが面倒」「テスト実行前のチェックリストを自動化したい」といった悩みを、カスタムコマンドが解決してくれます。

カスタムコマンドの仕組み

カスタムスラッシュコマンドは、Markdownファイルとして保存するだけで利用可能になります。配置場所は2種類あります。

プロジェクト単位のコマンド

プロジェクトのルートディレクトリに .claude/commands/ フォルダを作成し、その中にMarkdownファイルを置きます。

my-project/
├── .claude/
│   └── commands/
│       ├── review.md        → /review で呼び出し
│       ├── test-check.md    → /test-check で呼び出し
│       └── deploy-prep.md   → /deploy-prep で呼び出し
├── src/
└── package.json

このフォルダをGitリポジトリにコミットすれば、チーム全員が同じカスタムコマンドを使えるようになります。

グローバルコマンド

ホームディレクトリの ~/.claude/commands/ に置いたコマンドは、すべてのプロジェクトで利用できます。

# グローバルコマンドの配置先
~/.claude/commands/
├── explain.md       → /explain で呼び出し
└── summarize.md     → /summarize で呼び出し

個人の作業スタイルに合わせた汎用コマンドはグローバルに、プロジェクト固有のコマンドはプロジェクト内に置くのがおすすめです。

最初のカスタムコマンドを作ってみよう

実際にカスタムコマンドを作成してみましょう。ここでは、コードレビュー用のコマンドを作ります。

ステップ1: ディレクトリの作成

# プロジェクトのルートで実行
mkdir -p .claude/commands

ステップ2: コマンドファイルの作成

.claude/commands/review.md を作成します。

以下の観点でコードレビューを行ってください:
 
1. **バグの可能性**: null参照、境界値エラー、型の不一致
2. **セキュリティ**: SQLインジェクション、XSS、認証漏れ
3. **パフォーマンス**: 不要なループ、N+1クエリ、メモリリーク
4. **可読性**: 命名規則、関数の長さ、コメントの適切さ
5. **テスト**: テストカバレッジ、エッジケースの考慮
 
レビュー結果は以下の形式で報告してください:
- 🔴 Critical: 必ず修正すべき問題
- 🟡 Warning: 修正を推奨する問題
- 🟢 Suggestion: あると良い改善点
 
対象: $ARGUMENTS

$ARGUMENTS は、コマンド実行時に渡す引数に自動で置換されるプレースホルダーです。

ステップ3: コマンドの実行

Claude Code上で以下のように使います。

# ファイルを指定してレビュー
> /review src/auth/login.ts
 
# ディレクトリを指定してレビュー
> /review src/api/

たったこれだけで、毎回同じ観点を手入力する必要がなくなります。

実践的なカスタムコマンド例

ここからは、現場で役立つカスタムコマンドの例をいくつか紹介します。

テスト作成コマンド

.claude/commands/gen-test.md:

指定されたファイルの単体テストを作成してください。
 
要件:
- テストフレームワーク: このプロジェクトの既存テストに合わせる
- 正常系テスト: 主要なユースケースをカバー
- 異常系テスト: エラーハンドリング、境界値、null/undefined
- モック: 外部依存は適切にモック化
- テストの命名: 「何をテストしているか」が明確にわかる名前
 
テストファイルは対象ファイルと同じディレクトリ構造で __tests__/ に配置してください。
 
対象: $ARGUMENTS

実行例:

> /gen-test src/services/userService.ts
# → src/services/__tests__/userService.test.ts が生成される

コミットメッセージ生成コマンド

.claude/commands/commit-msg.md:

現在のステージされた変更を分析し、Conventional Commits形式の
コミットメッセージを生成してください。
 
ルール:
- 型: feat / fix / refactor / docs / test / chore のいずれか
- スコープ: 変更対象のモジュール名
- 件名: 50文字以内、命令形で記述
- 本文: 変更の理由と影響を簡潔に記述
 
まず `git diff --staged` で変更内容を確認してから、
メッセージを3パターン提案してください。

リファクタリング提案コマンド

.claude/commands/refactor.md:

指定されたコードのリファクタリング提案をしてください。
 
分析する観点:
- DRY原則: 重複コードの抽出
- 単一責任の原則: 関数・クラスの責任範囲
- 依存性の注入: テスタビリティの向上
- 型安全性: any型の排除、型ガードの追加
- エラーハンドリング: Result型パターンの導入
 
提案は「変更前 → 変更後」のコード例付きで示してください。
変更の優先度(高/中/低)も明記してください。
 
対象: $ARGUMENTS

コマンドとスキルの違い

2026年現在、Claude Codeには「カスタムコマンド」と「スキル」の2つの拡張方法があります。

項目カスタムコマンドスキル
配置先.claude/commands/.claude/skills/
ファイル形式MarkdownMarkdownファイル(SKILL.md)
呼び出し方/コマンド名/スキル名 または自動
自動起動なしフロントマターで条件指定可能
ファイル操作なし対応

シンプルなプロンプトの再利用にはカスタムコマンド、より複雑な自動化にはスキルが適しています。なお、.claude/commands/ に置いたファイルは引き続き動作するので、既存のコマンドをすぐに移行する必要はありません。

チーム開発での活用パターン

カスタムコマンドの真価は、チームで共有したときに発揮されます。

Gitリポジトリでの共有

# .claude/commands/ をコミット
git add .claude/commands/
git commit -m "feat(dx): add team custom slash commands for Claude Code"
git push origin main

チームメンバーが git pull するだけで、全員が同じコマンドを使えるようになります。

推奨されるチームコマンド構成

.claude/commands/
├── review.md          # コードレビュー
├── pr-description.md  # PR説明文の自動生成
├── gen-test.md        # テスト自動生成
├── migration.md       # DB マイグレーション作成
├── api-doc.md         # API ドキュメント生成
└── onboarding.md      # 新メンバー向けコードベース案内

オンボーディングコマンドの例

新しいチームメンバーがプロジェクト構成を素早く理解するためのコマンドです。

.claude/commands/onboarding.md:

このプロジェクトの構成を新メンバー向けに解説してください。
 
以下の情報を含めること:
1. ディレクトリ構造の概要と各フォルダの役割
2. 主要な技術スタック(package.json / requirements.txt 等を参照)
3. 開発サーバーの起動方法
4. テストの実行方法
5. 環境変数の設定(.env.example を参照)
6. 重要なアーキテクチャパターン
7. コーディング規約(linter設定を参照)
 
CLAUDE.md がある場合はそちらも参照してください。

全体を振り返って

Claude Codeのカスタムスラッシュコマンドは、Markdownファイルを1つ作るだけで使い始められる手軽な機能です。個人の作業効率化はもちろん、チームの .claude/commands/ をGitで共有すれば、開発プロセスの標準化にも役立ちます。

まずは日常的に繰り返しているプロンプトを1つ選んで、カスタムコマンド化するところから始めてみてください。Claude Codeでの作業がもう一段階快適になるはずです。

カスタムコマンドの基本を押さえたら、次は Claude Codeのスキル開発ガイド や Claude Code Hooksによるワークフロー自動化 にも挑戦してみましょう。

シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ(¥150)で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

⟐ Claude Code2026-10-13
「cd して git add して commit」の承認が毎回出る — 設定の抜けではなく、仕様だと分かるまでにたどった道
cd /path && git add && git commit のような複合コマンドで、許可ルールを入れても承認が繰り返し出る。公式の権限ドキュメントと GitHub の報告を突き合わせると、cd と git の組み合わせは設計上プロンプトが出ると分かりました。原因の切り分け順と、手数を減らす4つの直し方を並べます。
⟐ Claude Code2026-10-12
SPM に移したら、起動した瞬間にアプリが落ちるようになりました — dyld の一行を Claude Code と読み解いた記録
CocoaPods から Swift Package Manager へ移した直後、ビルドは通るのに起動した瞬間に落ちました。dyld の一行から原因を切り分け、直し方と確認コマンドまでをまとめます。
⟐ Claude Code2026-10-05
「コミットは私がします」と書いたのに git log に一行増えていた朝、指示を強めるのをやめました
Claude Code に「コミットしないで」と頼んだのにコミットされたとき、まず git reset --soft で戻し、permissions.deny と PreToolUse hook の二層で物理的に止める手順です。deny ルールが素通しする git -c の形と、hook の試し方を書き残します。