Claude Codeのスラッシュコマンドは、対話の途中でClaude Code本体を操作する入口です。先に結論を言うと、組み込みコマンドを全部覚える必要はありません。まず /clear・/context・/permissions の3つで日常は回ります。そしてカスタムコマンドはMarkdownファイル1枚で作れます。ただし、作り始める前に決めておきたいことが1つあります。そのコマンドを起動するのは人間か、モデルか。この記事を書くために自分の運用リポジトリを見返したら、カスタムコマンドは0個でした。その理由も含めて、作り方から使い分けの境界線まで整理します。
対象読者は、Claude Codeで / を押したら候補が多すぎて閉じた人と、毎回コピペしている定型プロンプトをそろそろコマンド化したい人です。素材は公式ドキュメントと、自分の運用（スキル13個をリポジトリに置いた無人Routine）でコマンドを使わなかった判断です。
スラッシュコマンドとは——プロンプトではなく「運転操作」
Claude Codeへの入力には2種類あります。普通に文章を打てばモデルへのプロンプトになり、/ で始めればClaude Codeそのものへの操作になります。会話の相手を変える、履歴を消す、権限を確認する。車で言えばハンドルではなくウインカーやワイパーの側です。
組み込みコマンドは数が多いので、用途別に主なものだけ並べます。
| 用途 | コマンド | 何をするか |
|---|---|---|
| コンテキスト | /clear | 会話履歴をリセットして仕切り直す |
/compact | 履歴を要約して圧縮する（残す観点も指示できる） | |
/context | コンテキストの使用状況を可視化する | |
| セッション | /resume | 過去のセッションを選んで再開する |
/rewind | チェックポイントへ巻き戻す | |
| 設定・権限 | /permissions | 許可・拒否ルールを確認、編集する |
/model | 使うモデルを切り替える | |
/config | 設定を確認、変更する | |
| 拡張の管理 | /mcp | MCPサーバーの接続状態を確認する |
/agents | サブエージェントを管理する | |
/hooks | フック設定を管理する | |
| 観測 | /cost | トークン使用状況を確認する |
/doctor | インストール状態を診断する |
全一覧は上の公式ドキュメントにあります。最初に手に馴染ませるなら /clear と /context です。タスクの区切りで /clear、詰まってきたら /context で残量を見る。この2つの背景にあるコンテキスト管理の考え方は別記事にまとめてあります。/permissions は許可ルールを触るときの入口で、権限設計そのものは4層ガイドに書きました。
カスタムコマンドの作り方——Markdown 1枚
本題のカスタムコマンドです。仕組みは拍子抜けするほど単純で、Markdownファイルを置くとファイル名がコマンド名になります。
- プロジェクト用:
.claude/commands/に置く。/helpの一覧に「project」と表示され、リポジトリごとにgitで共有できます - 個人用:
~/.claude/commands/に置く。どのプロジェクトでも使えます
たとえば .claude/commands/commit-message.md を作ると、/commit-message が生えます。
---
description: 変更差分から日本語のコミットメッセージ案を作る
argument-hint: [補足したい意図]
allowed-tools: Bash(git diff:*), Bash(git log:*)
---
## 現在の差分
!`git diff HEAD`
## 直近のコミット
!`git log --oneline -5`
上の差分から、このリポジトリの慣習に合わせた
コミットメッセージ案を3つ提案してください。
補足の意図: $ARGUMENTS
短いファイルですが、カスタムコマンドの主要素はほぼ入っています。
$ARGUMENTS:/commit-message リリース準備と打てば、$ARGUMENTSの位置に「リリース準備」が入ります。個別に受けたい場合は$1$2の位置引数も使えます!プレフィックス:!`コマンド`の行は実行前にbashで走り、出力がコンテキストへ入ります。使うには frontmatter のallowed-toolsでBashの許可を宣言しておく必要があります@参照:@src/utils/helpers.jsのように書けば、ファイルの中身を含められます- frontmatter:
description（一覧に出る説明）、argument-hint（補完時のヒント）、allowed-tools、model（このコマンドだけ別モデルで実行）などを指定できます
引数を2つ以上受けたいときは、位置引数のほうが収まりがよいです。たとえばIssue対応のコマンドなら /fix-issue 123 high と打ち、本文側で「Issue番号: $1、優先度: $2」と受けます。$ARGUMENTS は全部まとめて1か所に流し込む用、$1 $2 は入る場所を分けたい用、という使い分けです。
また frontmatter の model を指定すると、そのコマンドだけ別のモデルで実行できます。コミットメッセージ案や整形のような単純作業を軽いモデルへ寄せておくと、応答が速くなりコストも抑えられます。コマンド単位でモデルを固定できる場所は意外と貴重です。
サブディレクトリで整理もできます。.claude/commands/frontend/component.md のように置いても呼び出しは /component のままで、一覧の説明側に置き場所が表示されます。名前そのものは変わらないので、同名の衝突だけ避けてください。
もう1つ、自分では作っていなくても増える経路があります。接続したMCPサーバーがプロンプトを公開している場合、/mcp__サーバー名__プロンプト名 という形のコマンドとして自動的に現れます。/ の候補に見覚えのない名前が並んだら、だいたいこれです。
コマンドは「人間専用」ではなくなっている
ここまでは手元のショートカットの話でした。ただ、公式ドキュメントを読み込むと、この前提を崩す仕組みが1つあります。SlashCommandツールです。
これはClaude自身が対話の途中でカスタムコマンドを実行するためのツールで、たとえばCLAUDE.mdに「タスクの最初に /setup-env を実行すること」と書いておくと、人間が打たなくてもモデルがコマンドを呼びます。対象になるのは frontmatter に description があるコマンドで、モデルに見せる一覧には文字数の上限（公式ドキュメント記載の既定値で15,000文字）があります。コマンドが増えるほど、この予算を消費していくわけです。
つまりカスタムコマンドは、人間のためのショートカットであると同時に、モデルに渡す道具箱の一部でもあります。モデルから呼ばせたくないコマンドには disable-model-invocation: true を付ける。逆に呼ばせたいなら description を書く。モデル起動そのものを止めたければ、権限ルールで SlashCommand ツールを拒否すれば一括で無効化できます。個別は frontmatter、全体は権限ルール、の2段構えです。
この構造は description の書き方にも跳ね返ります。一覧から選ぶ人間だけでなく、「呼ぶかどうか」を判断するモデルも読むからです。「便利なやつ」のような説明では誤発動のもとになるので、何を入力し何が起きるかを1行で言い切る。コマンドを作るときに「起動するのは誰か」を意識せざるを得ない構造になっています。
入門を書くために自分のリポジトリを見たら、0個だった
この記事を書くにあたって、自分が一番コマンドを使っていそうなリポジトリを確認しました。SNS運用を無人のRoutineで回しているリポジトリで、.claude/skills/ にスキルが13個、審査用のサブエージェント、hooksのガードが常時入っています。Claude Codeの拡張はひととおり使っている構成です。
ところが .claude/commands/ は、ディレクトリごと存在しませんでした。カスタムコマンド0個。意図して避けたというより、必要になる場面が一度もなかったのが実態です。
理由を言葉にすると単純でした。スラッシュコマンドは「人がその場で打つ」道具だからです。私の運用は定時に無人で走るので、/ を打つ人がそもそも画面の前にいません。定型手順はすべてスキル（SKILL.md）に置き、モデルが文脈から読み込んで実行します。破らせたくない操作はプロンプトではなくhooksで機械的に止めます。人間の出番が設計上ゼロなら、人間用の入口も要らなかった、という話です。
整理すると、似た顔をした3つの置き場はこう分かれます。
| 置き場 | 起動するのは | 向いているもの |
|---|---|---|
| カスタムコマンド | 人間（＋明示すればモデル） | その場で結果を見て次を決める定型操作 |
| スキル | モデル（文脈で自動発動） | 無人でも走らせたい手順、判断込みの作業 |
| hooks | システム（強制） | 破らせたくない禁止事項、必ず挟む検査 |
逆に言うと、毎日画面の前でClaude Codeと対話しながら開発しているなら、最初に作るべきはスキルではなくコマンドです。起動が明示的なぶん挙動が読みやすく、Markdown 1枚で即日動きます。私の場合は運用が無人側に寄っていたのでスキルから入りましたが、これは順序の話であって優劣ではありません。
なお、コマンド・スキル・サブエージェント・hooksを複数リポジトリやチームへ配りたくなったら、その段階で梱包の仕組みであるプラグインが効いてきます。
Claude Codeのプラグイン入門｜スキルやMCP設定をまとめて配る仕組みClaude Codeのプラグインを公式ドキュメントベースで整理します。スラッシュコマンド・スキル・hooks・MCP設定を1つにまとめる構造、マーケットプレイスからの導入手順、チームへ配る設定、リポジトリ直置きで足りる場合の判断軸までまとめます。www.tentspace.net
まず組み込み3つ、次に1枚だけ作る
スラッシュコマンドの入門として、進み方をまとめます。
- 組み込みは
/clear・/context・/permissionsの3つから。区切りでリセット、詰まったら残量確認、権限を触るときは入口へ - 週に何度もコピペしているプロンプトが1つでもあるなら、
.claude/commands/にMarkdown 1枚で置いてみる。$ARGUMENTSとdescriptionだけで十分実用になります - 増えてきたら「起動するのは誰か」で棚卸しする。人間がその場で打つものはコマンドのまま、モデルに任せたい手順はスキルへ、禁止はhooksへ
- プロジェクト用コマンドはgitに乗るので、プロンプトの変更もコードレビューの対象にする。「秘伝のコピペ」をリポジトリの資産に変えられるのが、この仕組みの一番地味で一番効く利点です
コマンドは一番軽い拡張です。軽いからこそ増やしすぎると / の候補とモデル側の文字数予算を圧迫するので、道具箱は時々数える。それだけ意識しておけば、最初の1枚を今日作って困ることはないはずです。