blog
AIブログ
Claude Code スラッシュコマンド一覧|活用例【2026年版】

Claude Code スラッシュコマンドは、頻出操作をワンライナーで呼び出すための機能で、`/help`・`/init`・`/clear`・`/review` などの標準コマンドと、ユーザー定義のカスタムコマンドの2系統があります。使いこなすと、毎回長い指示を書く必要がなくなり、対話の体感速度が大きく変わります。
この記事では、標準コマンドの主なものと用途、カスタムコマンドの作り方、チーム展開時の運用ポイントを整理します。全体像については Claude Codeの使い方完全ガイド もあわせてどうぞ。
スラッシュコマンドとは何か?
スラッシュコマンドは、Claude Codeの対話プロンプトで「/コマンド名」と入力するだけで、あらかじめ定義された処理を呼び出す機能です。毎回の長い指示を短縮し、定型作業を一発で呼び出せます。
標準で用意されているコマンドに加えて、自分やチーム用にカスタムコマンドを定義することも可能。プロジェクト固有のワークフロー(特定のテンプレ生成、レビューフォーマット、デプロイ前チェックなど)をコマンド化しておくと、属人化を防ぎつつ品質を保てます。
標準コマンドの主要なものは?
標準コマンドは「操作系」「初期化系」「解析系」「セキュリティ系」の4カテゴリに大別できます。用途別に整理しておくと、必要なタイミングで思い出しやすくなります。
| コマンド | カテゴリ | 用途 |
|---|---|---|
| /help | 操作系 | 使えるコマンドの一覧と説明を表示 |
| /clear | 操作系 | 会話履歴をリセットして新しいセッションに |
| /init | 初期化系 | プロジェクトにCLAUDE.mdを生成・初期セットアップ |
| /review | 解析系 | プルリクエストのレビューを実施 |
| /security-review | セキュリティ系 | 変更内容のセキュリティ観点でのレビュー |
これ以外にも環境やバージョンによってコマンドは増減します。`/help` で常に最新の一覧を確認できるので、迷ったらまずヘルプ、を癖にすると安全。
/clear と /init の使い分けは?
`/clear` は「会話だけリセット」、`/init` は「プロジェクト全体の初期化(CLAUDE.md生成など)」と役割が明確に分かれています。状況に応じて使い分けるのがコツ。
- /clear:話題が大きく変わるとき、長い会話で文脈が膨らみすぎたときに使う
- /init:新しいプロジェクトでClaude Codeを使い始めるとき、最初に1回だけ実行
`/init` を実行すると、プロジェクトのコードベースを解析した上でCLAUDE.mdの雛形が生成されます。これを基にプロジェクト固有のルール(テスト実行コマンド、コーディング規約、避けるべき変更など)を追記していくのが標準的な使い方です。
/review と /security-review は何を見てくれる?
`/review` はプルリクエスト全体のコード品質を、`/security-review` はセキュリティ観点での問題点を、それぞれClaudeが解析してレビューコメントを返してくれるコマンドです。人間レビューの代替ではなく、レビュー前の一次チェックとして使うのが現実的な位置付け。
`/review` で見てくれる主な観点:
- コードの意図と変更の整合性
- リファクタリング余地
- テストカバレッジ
- 命名やスタイルの一貫性
`/security-review` は、入力検証の不備・認証関連の懸念・依存ライブラリのリスクなど、セキュリティ視点に絞ったチェックを実施します。デプロイ前のセルフレビューとして組み込むと、ヒューマンエラーの防止に役立ちます。
カスタムスラッシュコマンドはどう作る?
カスタムコマンドは、ユーザーごとまたはプロジェクトごとに定義ファイルを置くことで、`/コマンド名` で呼び出せるようになります。定型的な指示プロンプトをコマンドとして登録しておく、というのが基本的な発想です。
活用例:
- /release-notes:直近のコミットからリリースノートを自動生成
- /explain-pr:プルリクの差分を日本語で平易に要約
- /add-test:選択ファイルに対してテストケースを追加
- /i18n-check:i18nの抜けをチェック
定義ファイルの正確な置き場所とフォーマットは、利用バージョンで異なる場合があるため、Anthropic公式ドキュメントを参照しながら作成するのが安全です。
チームでの活用と運用ポイントは?
チーム展開では「全員が使う共通カスタムコマンドをリポジトリ管理する」のが最も効果的なパターンです。属人的だったレビュー観点や、各自バラバラだったコミット前チェックを、コマンド1発に統一できます。
運用のポイント:
- カスタムコマンドの定義をgit管理対象にする
- 命名規則を統一する(例:チーム共通は `/team-XXX`、個人用は `/my-XXX`)
- 定期的に棚卸しして、使われていないコマンドは削除
- 新メンバーのオンボーディングに `/help` で見える状態に保つ
使い方の全体的な整理は Claude Codeの使い方完全ガイド をご覧ください。
カスタムスラッシュコマンドの実装例
カスタムスラッシュコマンドは「実装ファイルを所定の場所に置く → 中身に処理内容を書く → `/コマンド名` で呼び出す」というシンプルな手順で作れます。個人用なら30分で1つ作れる手軽さで、繰り返し作業の時短に直結します。
実装の基本構造:
- 保存先:プロジェクトルート配下の所定ディレクトリ、またはユーザーホーム配下の設定ディレクトリ(バージョンにより異なる)
- ファイル名:`{コマンド名}.md` の形式が標準
- 中身:Markdownでコマンドの説明と、実行時に渡すプロンプトを記述
- 引数:`$ARGUMENTS` のような形式でユーザー入力を受け取る仕様(バージョン依存)
実用例として整備するなら、以下のようなコマンドが「個人運用で効くトップ3」です:
- /explain-pr:現在のブランチの差分を日本語で要約する。レビュー前のセルフチェックに便利
- /add-readme:プロジェクトのREADMEを生成・更新する。雛形を統一できる
- /translate-comments:英語コメントを日本語に翻訳する。海外OSSの解読に有効
チーム共有を想定するなら、命名規則を統一しておくと運用がしやすくなります。「チーム共通は `/team-XXX`」「プロジェクト固有は `/proj-XXX`」「個人用は `/my-XXX`」のような接頭辞ルールを決めておくと、`/help` で一覧表示したときに分類が明確になります。実装ファイル自体はgit管理対象にしておくのが定石です。
スラッシュコマンドの運用ベストプラクティス
スラッシュコマンドを長期運用するコツは「定期棚卸し」「使われていないコマンドの削除」「効果測定の習慣化」の3つです。作りっぱなしで放置すると、コマンド一覧が肥大化して逆に使いづらくなります。
運用ベストプラクティス:
- 四半期に1回の棚卸し:直近3ヶ月で使われていないコマンドは削除候補
- 使用頻度の可視化:チーム内でログを取り、人気コマンド・死蔵コマンドを把握
- ドキュメント化:各コマンドの使い方・想定シーンをチーム共通ドキュメントに整理
- オンボーディング配布:新メンバー入社時に「最低限覚えるべきコマンド5選」を紹介
- 類似コマンドの統合:似た用途のコマンドが2つできたら、より良い方に統合
失敗パターンとして多いのは、「便利そうだから作ったけど、誰も使わない」というコマンドが累積するケース。これを防ぐには、新規コマンドを作る前に「これ、他のメンバーも使いそう?」「使用頻度はどれくらい想定?」を一瞬考えるだけでも違います。個人用と判明したものは `/my-XXX` の接頭辞で個人領域に置いておけば、チーム空間を汚さずに済みます。
長期的には、スラッシュコマンドが「チームのコーディング文化を表現するツール」になっていきます。「うちのチームのレビュー観点は `/team-review` を見ればわかる」「うちのコードスタイルは `/team-lint` で揃う」というように、暗黙知をコマンドとして明文化するプロセス自体が、チームの成熟度を上げる効果があります。
よくある質問(FAQ)
Q1. 使えるコマンドの完全リストはどこで見られる?
対話セッション中に `/help` と入力すると、その環境で使える全コマンドが一覧表示されます。バージョンや設定によって増減するため、ドキュメントよりも `/help` のほうが正確な情報源になります。
Q2. カスタムコマンドを作るメリットは?
頻出する定型指示を毎回タイピングする手間が省け、チームでフォーマットを統一できる点が大きな利点です。「あの人のレビュー指示プロンプトをコピペで使う」みたいな運用を、`/コマンド名` 一発に集約できます。
Q3. スラッシュコマンドとふつうの依頼、どっちが優先される?
スラッシュコマンドは定義済みの動作を起動するもので、ふつうの自然言語の依頼とは別系統です。コマンド実行中でも、その前後に自然言語の指示を追加する形で使い分けることができます。
Q4. コマンドを忘れたときは?
`/help` で一覧を確認すれば思い出せます。チーム共通コマンドを設計する際は、「直感的に思い出せる短い名前」を意識すると、忘れにくくなります。
執筆:河合 圭(Kei Kawai)(クリスタルメソッド株式会社 代表取締役 / AI開発エンジニア)
AIアバター「瀧本クリスタル」開発者。対話AI・カスタムLLMの企業導入でフロントランナーとして活動。X / LinkedIn
編集責任者:河合 圭(クリスタルメソッド株式会社 代表取締役) / 編集ポリシー
公開日:2026-05-19 / 最終更新:2026-05-19
関連リンク
Study about AI
AIについて学ぶ
-
Claude Mythosとは|現状とOpusとの違い【2026年版】
Claude Mythos とは、Anthropicが2026年4月7日に正式発表したフロンティアモデルです。ただし現時点では一般公開されておらず、Projec...
-
Claude Code スラッシュコマンド一覧|活用例【2026年版】
Claude Code スラッシュコマンドは、頻出操作をワンライナーで呼び出すための機能で、`/help`・`/init`・`/clear`・`/review`...
-
Claude Codeの始め方|初心者が最初にやること【2026年版】
Claude Code 始め方の最短ルートは「環境準備 → 小さなタスクで体験 → 日常運用に習慣化」の3ステップです。いきなり大きなプロジェクトに投入するより...