Claude Codeカスタムスラッシュコマンド作成ガイド【2026】

Claude Code を使い込んでいくと、「コミット前にこのチェックリストを実行して」「この diff をレビューして」「Conventional Commits 形式で PR を作って」みたいな指示を、毎回ほぼ同じ文面で打ち込んでいることに気づきます。私も最初の数週間はそうでした。プロンプトをメモアプリにコピペしておいて、必要なときに貼り付ける――正直、これはこれで動くんですが、チームに展開できないし、引数を変えるたびに手で書き換えるのが地味にだるい。

そこで使うのがカスタムスラッシュコマンドです。.claude/commands/ に Markdown を置くと、その指示文がそのまま /コマンド名 として登録され、ワンコマンドで呼び出せるようになります。しかもファイルはリポジトリにコミットできるので、チーム全員が同じコマンドを共有できる。この記事では、現行版（2026 年 6 月時点）の仕様を公式ドキュメントで裏取りしながら、実際に動くコマンド定義を例ベースで解説していきます。

カスタムスラッシュコマンドとは何か（2026 年の現行仕様）

まず前提を整理します。Claude Code のスラッシュコマンドには大きく 3 種類あります。

• 組み込みコマンド：/help /clear /compact /init /agents /model など、Claude Code 本体に固定ロジックとして組み込まれているもの
• バンドルスキル：/debug /code-review /review /run /verify など、プロンプトベースで配布されている公式スキル
• カスタムコマンド（自作）：あなたが .claude/commands/ や ~/.claude/skills/ に置く独自コマンド ← 本記事の主題

ここで 2026 年版の重要な変更点を 1 つ。公式ドキュメントには次のように明記されています。

Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Your existing .claude/commands/ files keep working.
（出典：Claude Code 公式ドキュメント「Extend Claude with skills」）

つまり、カスタムコマンドは Skills という仕組みに統合されましたが、従来の .claude/commands/*.md 方式は引き続き有効で、同じ frontmatter をサポートします。「これまで commands で書いてきたものを今すぐ書き直す必要はない」というのが結論です。スキル方式（SKILL.md + 専用ディレクトリ）は補助ファイルを同梱できるなどの追加機能があるため、複雑なものを作るならスキル、1 枚で完結する定型コマンドなら .claude/commands/ が手軽、という使い分けになります。本記事ではまず手軽な .claude/commands/ 方式を軸に解説します。

コマンドの置き場所と名前空間（commands ディレクトリの仕組み）

コマンドファイルをどこに置くかで「誰が使えるか」が決まります。基本は 2 か所です。

置き場所	パス	スコープ
プロジェクト共有	.claude/commands/	そのリポジトリのみ。コミットすればチーム全員が使える
個人	~/.claude/commands/	自分の全プロジェクトで使える

コマンド名は拡張子を除いたファイル名がそのまま使われます。.claude/commands/review.md なら /review、.claude/commands/pr-create.md なら /pr-create です。

サブディレクトリを切ると名前空間（namespace）として整理できます。たとえば次のような構成にすると、機能ごとにフォルダ分けしつつ / メニューで探しやすくなります。

.claude/
└── commands/
    ├── review.md          # /review
    ├── test/
    │   └── gen.md         # /test:gen 相当のグルーピング
    └── git/
        ├── commit.md      # コミット用
        └── pr.md          # PR作成用

なお、同名のスキルとコマンドが衝突した場合はスキルが優先されます。また Skills 方式（.claude/skills/<name>/SKILL.md）ではディレクトリ名がコマンド名になり、エンタープライズ > 個人 > プロジェクトの順で上書きされます。チームで配布したいコマンドはプロジェクトの .claude/commands/ に置いてコミットする、というのが基本運用です。

最小のレビューコマンドを作る（手順）

まずは「変更内容をレビューする」コマンドを 1 つ作ってみます。ここではカスタムコマンドの基本要素――frontmatter・本文の指示・引数・bash 実行――を一通り使います。

1. リポジトリのルートで mkdir -p .claude/commands を実行してディレクトリを作る
2. .claude/commands/review.md を新規作成する
3. ファイルの先頭に --- で囲んだ YAML frontmatter を書き、description に「いつ使うか」を記述する
4. 本文に、Claude に実行してほしいレビュー手順を Markdown で書く
5. ファイルを保存する（Claude Code はコマンドディレクトリの変更を検知し、セッション再起動なしで反映される）
6. セッションで / を入力し、/review が一覧に出ることを確認する
7. /review を実行し、想定どおりレビューが走るか確認する

実際の review.md はこんな感じです。frontmatter で説明と引数ヒントを与え、本文では !`git diff` で現在の差分をプロンプトに流し込んでいます。

---
description: 現在の変更をレビューし、バグ・抜け漏れ・テスト不足を指摘する。diffをレビューしたいときに使う。
argument-hint: [対象ファイルや観点（任意）]
allowed-tools: Bash(git diff *)
---

## レビュー対象の差分

!`git diff`

## 指示

上の差分をレビューしてください。観点の指定があれば「$ARGUMENTS」を最優先で見ます。
次の順でコメントしてください。

1. 動作上のバグ・エラーハンドリング漏れ
2. 命名・可読性の問題
3. テストが必要そうな箇所
4. セキュリティ上の懸念（ハードコードされた秘密情報など）

各指摘には該当ファイル名と理由を添えてください。差分が空なら「変更なし」と返します。

ポイントは !`git diff` の行です。これは動的コンテキスト注入と呼ばれる仕組みで、Claude が本文を読む前に Claude Code 側でコマンドを実行し、その出力でプレースホルダを置き換えます。つまり Claude は「git diff を実行して」という指示ではなく、実際の差分テキストそのものを受け取ります。これにより、開いているファイルから推測するのではなく、実際の作業ツリーに基づいたレビューになります。

frontmatter で挙動を制御する（description / allowed-tools / model）

frontmatter は --- で囲んだ YAML ブロックで、コマンドの挙動を細かく制御します。現行版で使える主なキーは次のとおりです（すべて任意。description のみ推奨）。

キー	役割
description	何をするコマンドか・いつ使うか。Claude が自動起動の判断に使う
argument-hint	オートコンプリート時に表示される引数のヒント。例：[issue-number]
allowed-tools	このコマンド実行中、承認なしで使えるツール。!`...` の bash 実行に必須
model	このコマンド実行中だけ使うモデル。/model と同じ値か inherit
disable-model-invocation	true で Claude による自動起動を禁止し、手動 /name のみにする
arguments	名前付き位置引数を宣言し、本文で $name として展開できる

たとえば「本番デプロイ」のように副作用が大きく、Claude に勝手に走られたくないコマンドは disable-model-invocation: true を付けて手動専用にします。

---
description: アプリケーションを本番環境にデプロイする
disable-model-invocation: true
allowed-tools: Bash(npm run *) Bash(git push *)
---

$ARGUMENTS を本番にデプロイします。

1. テストスイートを実行する
2. アプリケーションをビルドする
3. デプロイ先へ push する
4. デプロイ成功を確認する

allowed-tools は「このコマンド中は承認プロンプトを出さずにこのツールを使ってよい」という許可です。利用可能なツールを制限するものではない点に注意してください。プロジェクトの .claude/commands/ にチェックインしたコマンドの場合、ワークスペースの信頼ダイアログを承認して初めて allowed-tools が効きます。リポジトリを信頼する前に、コマンドが自分自身に過剰なツール権限を与えていないかを必ずレビューしてください。

引数を受け取る：$ARGUMENTS と位置引数

コマンドに引数を渡したいときは、本文に $ARGUMENTS を埋め込みます。/コマンド名 の後ろに入力した文字列がそこに展開されます。

---
description: GitHubのIssueを修正する
disable-model-invocation: true
---

GitHub Issue $ARGUMENTS を社内のコーディング規約に従って修正してください。

1. Issueの説明を読む
2. 要件を理解する
3. 修正を実装する
4. テストを書く
5. コミットを作成する

これで /fix-issue 123 と打つと、本文の $ARGUMENTS が 123 に置き換わります。なお、$ARGUMENTS を本文に書かずに引数付きで呼び出した場合は、Claude Code が末尾に ARGUMENTS: <入力> を自動で付け足すので、入力が無視されることはありません。

引数を位置ごとに分けて使いたいときは $ARGUMENTS[N]、または短縮形の $N を使います。インデックスは 0 始まり（$0 が 1 番目）である点に注意してください。これは以前のバージョンの $1 始まりとは異なります。

---
description: コンポーネントを別フレームワークへ移植する
---

$0 コンポーネントを $1 から $2 へ移植してください。
既存の挙動とテストはすべて維持すること。

/migrate-component SearchBar React Vue と実行すると、$0 が SearchBar、$1 が React、$2 が Vue に展開されます。複数語をまとめて 1 引数として渡したいときは /my-cmd "hello world" second のようにクオートで囲みます。さらに frontmatter で arguments: [issue, branch] のように名前を宣言すれば、本文で $issue $branch という名前付きプレースホルダとして展開できます。

bash 実行と allowed-tools の安全な使い方

動的コンテキスト注入（!`コマンド`）は強力ですが、任意のシェルコマンドが Claude に渡る前に実行されるため、扱いには注意が要ります。現行版の仕様で押さえておくべき点を整理します。

• ! は行頭か空白の直後にあるときだけインライン実行として認識される。KEY=!`cmd` のように他の文字の直後だと、ただのテキストとして残り実行されない
• 複数行のコマンドを実行したいときは、インライン形式ではなく ```! で開くフェンスドコードブロックを使う
• bash 実行には allowed-tools での許可が必要。信頼できるコマンドだけを許可し、ワイルドカードを広げすぎない

複数行版の例です。frontmatter で Bash(gh *) を許可し、PR の情報をまとめて取得してからレビューさせています。

---
description: プルリクエストの変更を要約する
allowed-tools: Bash(gh *)
---

## PRコンテキスト
- 差分: !`gh pr diff`
- コメント: !`gh pr view --comments`
- 変更ファイル: !`gh pr diff --name-only`

## あなたのタスク
上のPR情報をもとに、変更点を3〜5行で要約してください...

安全面の鉄則は 2 つ。第 1 に、allowed-tools は Bash(git diff *) や Bash(gh *) のように必要最小限のコマンドだけを許可すること。Bash(*) のような全許可は、コマンドファイルを共有した相手の環境で何でも実行できてしまうので避けます。第 2 に、組織として bash 実行そのものを止めたい場合は、設定で "disableSkillShellExecution": true を有効にすると、各コマンドが実行される代わりに [shell command execution disabled by policy] に置き換えられます。これは管理者が一括で禁止したいケースで特に有効です。

組み込みコマンドとの違い・使い分け

カスタムコマンドを作る前に、「それ、もう公式にあるよ」というパターンを潰しておくと無駄な車輪の再発明を避けられます。現行版で押さえておくべき主な組み込み系コマンドは次のとおりです。

• セットアップ系：/init（CLAUDE.md 生成）、/memory、/mcp、/agents、/permissions
• セッション制御系：/clear、/compact、/context、/model、/effort、/plan
• バンドルスキル：/code-review、/review、/debug、/run、/verify、/batch

たとえば「コードレビューをコマンド化したい」なら、まず公式の /code-review や /review で足りないかを試すのが先です。プロジェクト固有の観点（社内規約・特定ライブラリの罠など）を足したいときに、はじめてカスタムコマンドを作る――この順序が無駄を生みません。逆に、組み込みにない完全に独自のワークフロー（社内デプロイ手順、定型 Slack 通知、独自テンプレからのコード生成など）は、最初からカスタムコマンドにする価値があります。

よくある失敗パターンと対策

実際にチームへ展開する中でハマった失敗を、❌／⭕形式で残しておきます。

❌ allowed-tools を付けずに !`git diff` を書いて「コマンドが動かない」と悩む
⭕ bash 実行には allowed-tools が必須。allowed-tools: Bash(git diff *) を frontmatter に足す。許可がないと差分が注入されず、Claude が空のコンテキストでレビューしてしまう。

❌ $1 が 2 番目の引数に展開されて混乱する
⭕ 現行版の $N は 0 始まり。1 番目は $0、2 番目が $1。旧バージョンの感覚で $1 を「1 番目」だと思い込むとズレる。位置引数は $ARGUMENTS[0] のように明示インデックスで書くと事故りにくい。

❌ デプロイ系コマンドを自動起動可能なまま置き、Claude が「準備できたな」と判断して勝手に走る
⭕ 副作用のあるコマンドは disable-model-invocation: true で手動専用にする。デプロイ・コミット・外部送信系はタイミングを人間が握るべき。

❌ Bash(*) で全ツールを許可したコマンドをそのままリポジトリにコミットして共有する
⭕ allowed-tools は最小権限で。共有前に「このコマンドは自分自身にどこまでの権限を与えているか」をレビューする。プロジェクトの .claude/commands/ は信頼ダイアログ承認後に権限が効くので、レビューせず信頼するのは危険。

まとめと次のアクション

カスタムスラッシュコマンドは、「毎回貼り付けていた定型プロンプト」を /command 一発に畳み込み、しかもチームで共有できる仕組みです。2026 年版ではコマンドが Skills に統合されましたが、.claude/commands/*.md 方式は引き続き有効なので、まずはここから始めるのが最短です。

今日からできる 3 アクション

1. 1 つ作る：手元のリポジトリに .claude/commands/review.md を置き、/review を呼び出せる状態にする
2. 引数を足す：$ARGUMENTS と !`git diff` を組み合わせ、実差分ベースのレビューコマンドに育てる
3. チームに配る：コマンドファイルをコミットし、allowed-tools を最小権限にレビューしてから共有する

関連して、コマンドから一歩進んで複数エージェントで並列作業させたい場合は Claude Code サブエージェント並列開発入門 が参考になります。外部ツール連携を組み込みたいなら Claude Code MCP 実践ガイド、チームへの本格導入を考えているなら Claude Code 業務導入完全ガイド をあわせてどうぞ。Codex との使い分けで迷っている方は Codex と Claude Code の使い分けも読んでおくと、どのワークフローをコマンド化すべきかの判断がしやすくなります。

出典

• Claude Code 公式ドキュメント｜Extend Claude with skills（slash-commands）
• Claude Code 公式ドキュメント｜Commands（組み込みコマンド・バンドルスキル一覧）
• Claude Code 公式ドキュメント｜Subagents
• Claude Code 公式ドキュメント｜Settings（disableSkillShellExecution 等）

関連記事（Claude Code 実践ガイド）

• まとめ：Claude Code 実践テクニック完全ガイド（12スキル）
• CLAUDE.md設計・運用ガイド｜効くプロジェクトメモリ
• Plan Mode実践ガイド｜安全に大きな変更を進める
• Skills作成ガイド｜SKILL.md入門
• プラグイン活用ガイド｜マーケットプレイス

あわせて読みたい：【2026】Claude Code settings.json設定完全ガイド

関連記事（自動）

• ▸ Claude Codeでライブラリ選定・技術調査を効率化する【2026】
• ▸ Claude Codeで技術的負債を返済する実践ガイド【2026】
• ▸ Claude Codeでプロトタイプ・MVPを高速に作る実践ガイド【2026】
• ▸ Claude Codeの拡張思考活用ガイド｜難問で深く考えさせる【2026】
• ▸ Claude Code IDE統合｜VSCode・JetBrains【2026】