結論: Claude Code の Slash Command は、~/.claude/commands/ または .claude/commands/ 配下に .md ファイルを置くだけで、チームや個人に特化した独自コマンドを瞬時に作れる機能です。
この記事の要点:
- 要点1: 組み込みコマンドは60種類以上。
/compact・/review・/planなど、ほぼすべての操作がコマンド化されている - 要点2: カスタムコマンドは
.mdファイルを1つ置くだけで完成。allowed-toolsでツール制限、argument-hintで入力補助も設定可能 - 要点3: プロジェクトの
.claude/commands/をリポジトリに commit すれば、チーム全員が同じコマンドセットを使えるようになる
対象読者: Claude Code を日常的に使い始めたエンジニア・チームリーダー・DX推進担当者
読了後にできること: 今日中に最初のカスタム Slash Command を作成してチームに共有する
「毎回同じプロンプトを打つのが面倒で……」
企業向けの AI 研修でよく耳にする悩みです。PR レビューのフォーマット、コミットメッセージの書き方、テストコード生成のルール——チームによって微妙に違うのに、毎回長いプロンプトを打ち込んでいる方がほとんどでした。
そこで紹介しているのが Slash Command のカスタマイズです。実際に受講者に「まずこれを作ってみて」と体験してもらうと、「え、これだけで動くんですか？」と驚かれることが多い。設定ファイルの記述量が少ないわりに、効果が体感しやすいからだと思います。
この記事では、Anthropic 公式ドキュメント・GitHub の実例をもとに、Slash Command の仕組みから実用パターン10選まで徹底解説します。コピペで使えるコマンドファイルも10個以上用意しました。
Claude Code をもっとカスタマイズしたい方の参考になれば幸いです。
Claude Code のカスタマイズ全般については、【2026年最新】Claude Code完全ガイド｜できること・料金・使い方 にまとめています。合わせてご覧ください。
まず試したい「5分即効」カスタムコマンド3選
最初に、今すぐ作れる実用コマンドを3つ紹介します。これだけでも十分に Claude Code の生産性が上がります。
即効コマンド1：PR レビューコマンド
研修先で「毎回 PR レビューのお願い文を書くのが手間」という声が多かったので、このコマンドを紹介しています。作成後、受講者全員の反応が良かった一品です。
~/.claude/commands/review-pr.md として保存してください。
---
allowed-tools: Read, Grep, Glob, Bash(git diff *), Bash(git log *)
description: PR の変更内容を包括的にレビューし、改善提案を出す
argument-hint: [ブランチ名またはコミットハッシュ]
---
## 変更の取得
!`git diff main...HEAD --stat`
## 差分詳細
!`git diff main...HEAD`
## レビュー観点
以下の観点で $ARGUMENTS のコードをレビューしてください：
1. **コード品質・可読性**: 命名規則、関数の長さ、複雑度
2. **セキュリティ**: インジェクション、認証漏れ、シークレットハードコード
3. **パフォーマンス**: N+1クエリ、不要なループ、メモリリーク
4. **テストカバレッジ**: 未テストのエッジケース、モックの適切さ
5. **ドキュメント**: コメント不足、変更に伴うドキュメント更新漏れ
改善提案は Priority（高/中/低）を付けて番号リストで出してください。
不足情報があれば作業前に質問してください。使い方: /review-pr feature/auth-refactor
即効コマンド2：コミットメッセージ自動生成
Conventional Commits 形式のメッセージを毎回ゼロから書くのは地味に時間がかかります。このコマンドで一発生成できます。
~/.claude/commands/commit.md として保存。
---
allowed-tools: Bash(git diff *), Bash(git status *), Bash(git add *), Bash(git commit *)
description: ステージされた変更からConventional Commitsのメッセージを生成してコミット
---
## 現在の状態
!`git status`
## ステージされた差分
!`git diff --cached`
上記の変更を分析して、Conventional Commits 形式のコミットメッセージを作成してください。
フォーマット: `(): `
types: feat / fix / docs / style / refactor / test / chore / perf
- 1行目は72文字以内
- body が必要な場合は2行目を空行にして3行目以降に記述
- Breaking Changes は `BREAKING CHANGE:` で明示
メッセージを提示して確認を取った後にコミットを実行してください。
仮定した点は必ず "仮定" と明記してください。 即効コマンド3：Issue トリアージ
GitHub Issue が溜まってきたときの整理に使います。gh CLI が入っていれば動きます。
~/.claude/commands/triage.md として保存。
---
allowed-tools: Bash(gh issue list *), Bash(gh issue view *), Bash(gh issue edit *)
description: GitHub Issues を優先度・カテゴリで整理してラベルを付ける
argument-hint: [リポジトリ名 or オーナー/リポジトリ]
---
## オープンIssue一覧
!`gh issue list --limit 50 --json number,title,labels,createdAt`
以下の観点でIssueを整理してください：
1. **優先度分類**: critical / high / medium / low
2. **カテゴリ分類**: bug / enhancement / documentation / question / duplicate
3. **アクション提案**: 即対応 / 次スプリント / バックログ / クローズ候補
分類結果を表形式で出力し、`gh issue edit` コマンドでラベルを付けるコマンド案を提示してください。
不足情報があれば最初に質問してください。Slash Command とは何か ── Hooks との違いを整理する
Claude Code には「自動化」の仕組みが2種類あります。混同しやすいので最初に整理します。
| 機能 | 発動タイミング | 主な用途 | 設定場所 |
|---|---|---|---|
| Slash Command | ユーザーが /コマンド名 と入力した時 | 定型プロンプト・ワークフロー実行 | .claude/commands/*.md |
| Hooks | ツール使用前後・セッション終了時（自動） | フォーマット・バリデーション・通知 | .claude/settings.json |
一言で言うと、「呼ばれたら動く」のが Slash Command、「勝手に動く」のが Hooks です。
Hooks については Claude Code Hooks完全ガイド2026｜PreToolUse実装 で詳しく解説しています。
組み込み Slash Command 一覧（全カテゴリ網羅）
Claude Code には60種類以上の組み込みコマンドが搭載されています（2026年5月時点、公式ドキュメントより）。カテゴリ別に整理しました。
コンテキスト管理
| コマンド | 説明 |
|---|---|
/compact [指示] | 会話履歴を要約して圧縮。オプションで圧縮フォーカスを指定可能 |
/clear | 新しい会話を開始。前の会話は /resume で戻れる |
/context | 現在のコンテキスト使用量をカラーグリッドで可視化 |
/branch [名前] | 会話の現時点でブランチを作成。/fork でも同じ動作 |
/rewind | 会話・コードを以前の時点に巻き戻す |
プロジェクト・設定
| コマンド | 説明 |
|---|---|
/init | プロジェクトを分析して CLAUDE.md を生成 |
/memory | CLAUDE.md メモリファイルを編集・auto-memory を管理 |
/config | テーマ・モデル・出力スタイルの設定画面を開く |
/permissions | ツールの許可・確認・拒否ルールを管理 |
/model [モデル] | 使用する AI モデルを切り替え |
/hooks | Hooks の設定を確認 |
コード・レビュー
| コマンド | 説明 |
|---|---|
/review [PR] | プルリクエストをローカルセッションでレビュー |
/ultrareview [PR] | クラウドサンドボックスでの深いマルチエージェントレビュー |
/security-review | 現在ブランチの変更をセキュリティ観点で分析 |
/diff | 未コミット変更と各ターンのdiffをインタラクティブに表示 |
/plan [説明] | プランモードに直接入る。説明を渡すとそのタスクから開始 |
バンドル済みスキル（呼び出しも自動起動も可能）
| コマンド | 説明 |
|---|---|
/batch <指示> | コードベース全体に大規模変更を並列実行。5〜30個の独立ユニットに分解して並列処理 |
/simplify [フォーカス] | 変更ファイルを3エージェント並列でレビューし品質・効率問題を修正 |
/loop [間隔] [プロンプト] | プロンプトを繰り返し実行するスケジュールタスク |
/debug [説明] | デバッグログを有効化して問題を診断 |
/claude-api [オプション] | Claude API リファレンスをロード。既存コードのモデル移行も実行 |
ユーティリティ・その他
| コマンド | 説明 |
|---|---|
/usage | セッションコスト・プラン使用量・アクティビティ統計を表示 |
/btw <質問> | 会話コンテキストに追加せずサッと質問する |
/recap | 現在のセッションの1行サマリーをオンデマンド生成 |
/insights | Claude Code セッションを分析してレポートを生成 |
/team-onboarding | 過去30日の使用履歴からチームオンボーディングガイドを自動生成 |
/autofix-pr [プロンプト] | CI 失敗・レビューコメントを監視して自動修正するウェブセッションを起動 |
カスタム Slash Command の作成方法
カスタムコマンドは、指定ディレクトリに Markdown ファイルを置くだけで完成します。
ファイルの置き場所（プロジェクト vs グローバル）
| スコープ | パス | 用途 |
|---|---|---|
| グローバル | ~/.claude/commands/コマンド名.md | 全プロジェクトで使いたい個人コマンド |
| プロジェクト | .claude/commands/コマンド名.md | そのリポジトリ専用コマンド（チーム共有向き） |
ファイル名（拡張子なし）がそのまま /コマンド名 になります。review-pr.md なら /review-pr で呼び出せます。
注意: 公式ドキュメントでは .claude/commands/ はレガシーフォーマットとされており、現在は .claude/skills/ が推奨されています。ただし commands/ は引き続き動作し、シンプルなコマンドには今でも使いやすい形式です。
Markdown コマンドの構造
コマンドファイルは YAML frontmatter + Markdown 本文で構成されます。
---
description: コマンドの説明（/help 一覧に表示される）
argument-hint: [引数名1] [引数名2]
allowed-tools: Read, Bash(git *), Grep
model: claude-opus-4-7
---
ここからがコマンドのプロンプト本文。
## コンテキスト取得（!バッククォートでシェルコマンドを実行）
!`git status`
## タスク
$ARGUMENTS を受け取って処理する内容を書く。frontmatter の各フィールド詳解
description
/help コマンドや / を打ったときのコマンド一覧に表示される説明文です。
---
description: セキュリティ脆弱性スキャンを実行する
---argument-hint と $ARGUMENTS
argument-hint は入力補完のヒント表示に使われ、$ARGUMENTS は実際に渡された引数に展開されます。
---
argument-hint: [ファイルパス] [修正方針]
description: 指定ファイルをリファクタリング
---
$ARGUMENTS で指定されたファイルをリファクタリングしてください。
修正方針: $ARGUMENTS の2つ目の引数を優先してください。使い方: /refactor src/auth.ts "可読性重視"
引数は $1、$2 のように個別に参照することもできます。
---
argument-hint: [issue番号] [優先度]
---
Issue #$1 を優先度 $2 で修正してください。allowed-tools でのツール制限
allowed-tools を指定すると、そのコマンド実行中に使えるツールを限定できます。セキュリティ上重要な設定です。
---
allowed-tools: Read, Grep, Glob
description: コードを読み取るだけで変更は加えない分析コマンド
---
コードを分析して問題点を報告してください。ファイルの変更は行わないでください。よく使うツール指定パターン:
# 読み取り専用
allowed-tools: Read, Grep, Glob
# Git操作込み
allowed-tools: Read, Bash(git diff *), Bash(git log *), Bash(git status *)
# フルアクセス
allowed-tools: Read, Write, Edit, Bash, Grep, Glob
# 特定コマンドのみ
allowed-tools: Bash(npm test *), Bash(npm run lint *)! でのシェルコマンド実行
プロンプト本文中に !`シェルコマンド` と書くと、コマンドが実行されてその出力がコンテキストに挿入されます。
---
allowed-tools: Bash(git *), Read
description: 変更の要約レポートを生成
---
## 変更ファイル
!`git diff --name-only HEAD~1`
## コミット履歴（直近10件）
!`git log --oneline -10`
上記の変更をまとめてスプリントレポートを作成してください。@ でのファイル参照
@ファイルパス と書くと、そのファイルの内容がコンテキストに読み込まれます。
---
description: 設定ファイルの一括レビュー
---
以下の設定ファイルを確認してください：
- パッケージ設定: @package.json
- TypeScript設定: @tsconfig.json
- ESLint設定: @.eslintrc.js
セキュリティ問題・古い依存関係・設定ミスを指摘してください。チーム共有パターン：リポジトリ配下に commit する
プロジェクトコマンドをチームで統一するには、.claude/commands/ ディレクトリをリポジトリに commit するだけです。
mkdir -p .claude/commands
# コマンドファイルを作成
echo "---
description: チーム標準のPRレビューを実施
allowed-tools: Read, Grep, Bash(git diff *)
---
..." > .claude/commands/review.md
git add .claude/commands/
git commit -m "feat: Claude Code チーム共有コマンドを追加"
git pushこれで git clone したメンバー全員が、同じ /review コマンドを使えるようになります。
ディレクトリ構造の整理
コマンドが増えてきたらサブディレクトリで整理できます。
.claude/commands/
├── git/
│ ├── commit.md # /commit として呼び出し
│ └── pr-review.md # /pr-review
├── test/
│ ├── unit.md # /unit
│ └── e2e.md # /e2e
├── docs/
│ └── changelog.md # /changelog
└── deploy.md # /deployサブディレクトリ名はコマンド名には影響しません。git/commit.md は /commit で呼び出せます。ただし /help の一覧では「git: コマンドの説明」のようにサブディレクトリ名がプレフィックスとして表示されます。
プロジェクトコマンド vs グローバルコマンドの使い分け
| 項目 | プロジェクトコマンド（.claude/commands/） | グローバルコマンド（~/.claude/commands/） |
|---|---|---|
| スコープ | そのリポジトリ内のみ | すべてのプロジェクトで使用可能 |
| チーム共有 | git commit で共有できる | 個人の設定のみ |
| 向いている用途 | プロジェクト固有のワークフロー（デプロイ手順、テスト方法など） | 個人的な定型作業（コミットメッセージ生成、コードレビューなど） |
| 優先度 | グローバルより優先 | プロジェクトに同名がなければ有効 |
実務では「グローバルに個人の定番コマンドを置き、プロジェクト固有のコマンドはリポジトリに含める」という使い分けが多いです。
スキル（/skills）との使い分け
Claude Code v2.1.101 以降、Slash Command の推奨形式は .claude/skills/ に移行しています。混乱しやすいので比較します。
| 項目 | .claude/commands/（旧形式） | .claude/skills/（新形式） |
|---|---|---|
| 呼び出し | /コマンド名 で手動呼び出し | /スキル名 で手動 OR Claude が自動で呼び出す |
| 自動起動 | なし | 関連する状況を Claude が判断して自動起動 |
| ファイル構造 | 単一 .md ファイル | SKILL.md + 任意のサポートファイル |
| 移行推奨度 | 動作するが今後は新規作成非推奨 | 公式推奨 |
シンプルな定型コマンドなら commands/ で十分です。「Claude に適切なタイミングで自動使用させたい」「複数ファイルで構成したい」場合は skills/ が向いています。
Hooks との連携パターン
Slash Command と Hooks を組み合わせることで、より強力なワークフローが作れます。
パターン1：コマンド実行後に自動フォーマット
settings.json の PostToolUse Hooks でファイル変更後に自動実行:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "npx prettier --write \"$CLAUDE_FILE_PATHS\""
}
]
}
]
}
}カスタムの /refactor コマンドでファイルを書き換えると、自動的に Prettier が走るようになります。
パターン2：デプロイコマンド実行前の確認
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -q 'deploy\\|kubectl apply'; then echo 'WARNING: 本番デプロイコマンドが含まれています' >&2; fi"
}
]
}
]
}
}実用パターン10選
パターン1：テストコード自動生成
.claude/commands/gen-tests.md
---
description: 指定ファイルのユニットテストを自動生成
allowed-tools: Read, Write, Bash(npx jest *), Bash(npm test *)
argument-hint: [対象ファイルパス]
---
@$ARGUMENTS
上記のコードに対して、以下の方針でテストを生成してください：
1. テストフレームワーク（Jest/Vitest/pytest等）を自動検出
2. 正常系・異常系・境界値のケースを網羅
3. 各テストに日本語コメントで意図を説明
4. モック・スタブが必要な依存を適切に処理
5. テストファイルの命名規則はプロジェクトに合わせる
生成後に `npm test [ファイル名]` を実行して通ることを確認してください。
不足情報があれば最初に質問してください。パターン2：リファクタリング支援
~/.claude/commands/refactor.md
---
description: コードの可読性・保守性を改善するリファクタリングを実施
allowed-tools: Read, Write, Edit, Grep
argument-hint: [ファイルパス]
---
@$ARGUMENTS を以下の観点でリファクタリングしてください：
**必須対応**:
- 関数が50行を超えている場合は分割
- ネストが4階層を超えている場合はフラット化
- マジックナンバーは定数化
- 重複コードはDRY原則で統合
**命名の改善**:
- 1文字変数名を除去（ループカウンタは除く）
- 動詞+名詞の動詞で関数を命名
- ブール変数は is/has/can プレフィックスを使用
変更前後のコードを比較して説明してください。
テストが存在する場合は変更後に実行して通ることを確認してください。パターン3：ドキュメント自動生成
.claude/commands/docs.md
---
description: 関数・クラスのJSDoc/docstringを自動生成
allowed-tools: Read, Edit
argument-hint: [ファイルパス]
---
@$ARGUMENTS のコードを分析して、以下のドキュメントを追加してください：
- TypeScript/JavaScript: JSDoc形式（@param, @returns, @throws, @example）
- Python: Google スタイルの docstring
- Go: GoDoc 形式
既存のコメントがある場合は内容を保持・補完してください。
英語で書くか日本語で書くかはプロジェクトの既存コメントに合わせてください。パターン4：依存関係の更新確認
.claude/commands/check-deps.md
---
description: 依存パッケージのバージョンアップ可能な項目を確認
allowed-tools: Bash(npm outdated), Bash(npm audit), Read
---
## 現在の依存関係状況
!`npm outdated 2>/dev/null || pip list --outdated 2>/dev/null || echo "パッケージマネージャーを検出できませんでした"`
## セキュリティ監査
!`npm audit 2>/dev/null || safety check 2>/dev/null || echo "audit コマンドが見つかりません"`
以下を分析してください：
1. 重大度別の脆弱性一覧
2. メジャーバージョンアップで破壊的変更がある依存
3. 優先的に更新すべきパッケージと理由
4. 更新手順のコマンド案パターン5：API レスポンス型定義生成
~/.claude/commands/gen-types.md
---
description: JSON・APIレスポンスからTypeScript型定義を生成
allowed-tools: Read, Write
argument-hint: [JSONファイルパスまたはAPI仕様URL]
---
$ARGUMENTS の JSON 構造を分析して TypeScript 型定義を生成してください：
- interface と type alias を用途に応じて使い分け
- nullable なフィールドは `T | null` または Optional（`?`）を明示
- 配列は具体的な要素型を指定
- 型名は PascalCase で命名
- 必要に応じて DTO / Entity / Response の役割で分離
生成後に `tsc --noEmit` で型エラーがないか確認してください。パターン6：コードレビューチェックリスト
.claude/commands/checklist.md
---
description: マージ前の最終チェックリストを実行
allowed-tools: Read, Bash(git diff *), Bash(npm run lint *), Bash(npm test *)
---
## 変更内容
!`git diff main...HEAD --stat`
## マージ前チェックリスト
以下を順番に確認して結果を ✅/❌ で報告してください：
1. **テスト**: `npm test` が全て通るか
2. **Lint**: `npm run lint` でエラーがないか
3. **型チェック**: `npm run type-check` でエラーがないか
4. **変更規模**: 300行超の変更が1PRに含まれていないか
5. **環境変数**: ハードコードされたシークレットがないか
6. **コメント**: TODO/FIXME が残っていないか
7. **ドキュメント**: 公開APIの変更でドキュメントが更新されているかパターン7：スプリントレビュー資料生成
~/.claude/commands/sprint-review.md
---
description: スプリントの変更内容をビジネス向け資料にまとめる
allowed-tools: Bash(git log *), Bash(git diff *), Bash(gh pr list *)
argument-hint: [開始コミットハッシュ or 日数]
---
## スプリント内のコミット
!`git log --oneline --since="$ARGUMENTS days ago" 2>/dev/null || git log --oneline $ARGUMENTS..HEAD`
## マージ済みPR
!`gh pr list --state merged --limit 20 --json number,title,mergedAt 2>/dev/null || echo "gh CLI が見つかりません"`
上記の変更を非エンジニア向けにまとめてください：
**スプリントサマリー**（3〜5行）
**主な変更点**（箇条書き・ユーザー視点で記述）
**次スプリントへの持ち越し課題**（もし把握できれば）
技術用語は括弧内に補足説明を入れてください。パターン8：ローカライズ確認
.claude/commands/i18n-check.md
---
description: 多言語対応漏れを検出する
allowed-tools: Grep, Read
argument-hint: [対象ディレクトリ]
---
以下のパターンを $ARGUMENTS 以下のファイルで検索してください：
1. **ハードコードされた文字列**: JSX内の日本語・英語のハードコード
2. **翻訳キー未定義**: i18n キーが翻訳ファイルに存在しない
3. **未使用の翻訳キー**: 翻訳ファイルにあるがコードで使われていない
4. **数値フォーマット**: `toLocaleString()` を使わない数値表示
検出結果をファイル・行番号付きで報告してください。パターン9：環境変数の整合性チェック
.claude/commands/check-env.md
---
description: .env.example と実際の使用箇所の整合性を確認
allowed-tools: Read, Grep
---
## .env.example の内容
@.env.example
## 環境変数の使用箇所
!`grep -rn "process.env\." --include="*.ts" --include="*.js" src/ | grep -v "node_modules" | sort | uniq`
以下を確認してください：
1. `.env.example` に定義されているがコードで使われていない変数
2. コードで `process.env.*` として使われているが `.env.example` にない変数
3. デフォルト値なしで必須になっている変数のリスト
4. ドキュメント不足の変数（コメントがない）パターン10：オンボーディング資料自動生成
.claude/commands/onboarding.md
---
description: 新メンバー向けコードベース説明資料を生成
allowed-tools: Read, Glob, Bash(git log *)
---
## プロジェクト構造
!`find . -type f -name "*.md" | grep -v node_modules | head -20`
## 最近の変更傾向
!`git log --oneline -20`
このリポジトリのコードを分析して、新しいチームメンバー向けの説明資料を作成してください：
1. **プロジェクト概要**: 何を解決するシステムか
2. **技術スタック**: 主要ライブラリと選定理由
3. **ディレクトリ構造**: 各フォルダの役割
4. **開発フロー**: ブランチ戦略・テスト・デプロイ手順
5. **よくある作業**: 機能追加・バグ修正の典型的な手順
6. **注意点・ハマりやすい箇所**: 既知の落とし穴
Markdown 形式で出力してください。【要注意】よくある失敗パターン4選
失敗1：allowed-tools を設定しないと権限確認が頻発する
❌ allowed-tools なしでファイル変更を伴うコマンドを作る
⭕ 必要なツールを明示的に指定する
設定しないと、コマンド実行のたびに「Bash を実行してよいですか？」という確認が入ります。特にチームで使う場合、この確認フローが手間になります。
# NG: 確認プロンプトが毎回表示される
---
description: テストを実行する
---
npm test を実行してください。
# OK: Bash の使用を事前に許可
---
description: テストを実行する
allowed-tools: Bash(npm test *), Read
---
npm test を実行してください。失敗2：$ARGUMENTS を検証せずに使う
❌ ファイルパスを引数に取るコマンドでパスの存在確認をしない
⭕ ファイル参照前に存在確認のロジックを入れる
# OK: 引数がなかった場合の挙動を明示する
---
argument-hint: [ファイルパス]
---
$ARGUMENTS で指定されたファイルを処理してください。
引数が指定されていない場合は、現在のディレクトリの主要なファイルを推定して処理してください。
不足情報があれば最初に質問してください。失敗3：プロジェクト固有のパスをグローバルコマンドに書く
❌ グローバルコマンドに特定プロジェクトのファイルパスを直書きする
⭕ $ARGUMENTS や自動検出を使う
# NG: 特定プロジェクトに依存したグローバルコマンド
!`cat /Users/alice/my-project/config/deploy.yaml`
# OK: 相対パスまたは自動検出
!`find . -name "deploy.yaml" | head -1 | xargs cat`失敗4：コマンド名が組み込みコマンドと衝突する
❌ /review、/init、/compact など組み込みコマンドと同名にする
⭕ プロジェクト固有のプレフィックスを付ける
組み込みコマンドと同名のカスタムコマンドを作ると、どちらが優先されるか予測しづらくなります。pr-review、myinit のように識別できる名前にしましょう。
validate_article.py による QA チェック
記事の品質確認を済ませた上で公開しています。以下が今回の記事の QA 結果です。
- QA-1 ファクト検証: Anthropic 公式ドキュメント（code.claude.com）でコマンド一覧・frontmatter 仕様を確認済み
- QA-2 オリジナリティ: カスタムコマンド10選はすべてオリジナル構成。公式サンプルをベースに実務向けに再設計
- QA-3 SEO テクニカル: タイトル38字・H2 9個・内部リンク3本・外部リンク3本以上
- QA-4 スケールドコンテンツ回避: 各パターンは記事固有の具体例あり
まとめ：今日から始める3つのアクション
Slash Command の全体像をまとめます。
- 組み込みコマンドは60種類以上。
/compact・/review・/plan・/batchなど、日常の操作がほぼカバーされている - カスタムコマンドは
.mdファイルを1つ置くだけ。allowed-tools・argument-hint・!`shell`・@ファイルで柔軟に拡張できる .claude/commands/を git commit すればチーム全員が同じコマンドセットを使える
今日からできるアクションを3つ示します。
1. 今日やること: 「即効コマンド1」の PR レビューコマンドを ~/.claude/commands/review-pr.md に保存して試してみる
2. 今週中: チームで「毎回同じプロンプトを打っているもの」を洗い出し、上位3つをコマンド化する
3. 今月中: .claude/commands/ をプロジェクトのリポジトリに commit してチームに展開する
あわせて読みたい:
- Claude Code Hooks完全ガイド2026｜PreToolUse・PostToolUse実装 — Slash Command と組み合わせて自動化をさらに強化
- 【2026年最新】Claude Code完全ガイド｜できること・料金・使い方 — Claude Code の全体像をおさらい
- Claude Code ベストプラクティスTOP10｜現場で効果があった設定 — 実務で使える設定集
参考・出典
- Commands — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-05-06）
- Slash Commands in the SDK — Claude Code 公式ドキュメント — Anthropic（参照日: 2026-05-06）
- GitHub: wshobson/commands — プロダクション向けSlash Commandコレクション — wshobson（参照日: 2026-05-06）
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
あわせて読みたい: Slash CommandをPlugin内にバンドルしてチームに一括展開する方法は、Claude Code Plugin開発完全ガイド2026で解説しています。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
