Claude Codeのスラッシュコマンド一覧｜目的別の使い方と安全な運用
Claude Codeを使い始めると、最初に戸惑いやすいのがスラッシュコマンドです。/help や /clear は見つけやすい一方で、コマンド数が増えるほど「今この場面で何を使うべきか」「設定を変えてしまわないか」が分かりにくくなります。とくに、会話を長く続ける人、複数のリポジトリを扱う人、AIに実装を任せつつ最後の判断は自分で行いたい人ほど、コマンドを暗記するよりも役割ごとに使い分ける基準を持つ方が実用的です。
この記事では、Claude Codeの公式コマンド一覧を土台に、日々の開発で遭遇する場面から逆算して整理します。すべてのコマンドを機械的に覚えるのではなく、まず安全に始めるための最小セット、長い会話を整えるセット、作業品質を上げるセット、設定や外部連携に関わる慎重に扱うセットに分けます。画面に表示されるコマンドはプラン、OS、組織の設定、バージョンによって異なるため、この記事は「必ず全員が使える一覧」とは主張しません。実際に使える候補は、Claude Code内で / または /help を入力して確認してください。
結論：迷ったときは、作業開始に
/status、会話が長いときに/compact、変更前後の確認に/diff、品質確認に/reviewを使うところから始めれば十分です。権限、外部連携、スケジュール、クラウド実行に触れるコマンドは、効果が大きい分だけ対象と副作用を読んでから使います。
まず押さえたい：コマンドは「会話への命令」ではなく「作業環境の操作」
通常のプロンプトは、Claudeに「何を考え、何を作るか」を伝えます。一方でスラッシュコマンドは、セッション、コンテキスト、権限、モデル、差分表示、外部接続など、作業の枠組みを調整するための入口です。たとえば/compactは会話内容を要約してコンテキストを空け、/diffは編集差分を確認する画面を開きます。どちらもアプリのソースコードそのものを変える指示ではありませんが、以後の作業の安全性と見通しを左右します。
この区別を意識すると、コマンドを次の4群で捉えられます。
- 現在地を知る：
/status、/help、/context、/tasks - 会話を整える：
/compact、/clear、/resume、/rename - 実装を確かめる：
/diff、/review、/verify、/debug - 環境や接続を変える：
/permissions、/mcp、/plugin、/schedule
まずは上の順で使えるようになれば、一覧を眺めて迷う時間が減ります。4群目は権限や認証、外部サービスへの接続に関係する場合があるので、初見のコマンドを試す前に画面の説明を読みます。
最初の5つ：毎日使うならこの順番
/help：表示されるコマンドを起点にする
公式ドキュメントにもある通り、利用可能なコマンドは環境によって異なります。ネット上の古い一覧をコピーしても、モデル名の変更や機能の廃止・追加でそのまま使えないことがあります。まず/helpで自分の画面に出るコマンドを確認し、気になるものを一つずつ試すのが安全です。
コマンド名の後に文字を続けると候補が絞られるため、名称を正確に覚えていなくても問題ありません。ここで大切なのは、「表示されないコマンドが壊れている」と決めつけないことです。OS、契約、組織ポリシー、実行環境により非表示になる機能があります。
/status：作業開始前の30秒チェック
/statusは、現在のセッションの状態、接続、モデルなどを確認する入口として便利です。作業を再開した日、いつもと違う環境から接続した日、応答が想定と違うと感じた日は、最初に一度見ておくと切り分けが速くなります。
「前回と同じ設定のはず」という思い込みは、AI支援開発では小さな事故の原因になります。モデルや作業ディレクトリ、認証状態が変わっていれば、出力の傾向や使えるツールも変わり得ます。/statusは変更するためでなく、現在地を確認するためのコマンドです。
/compact：長い会話を続けるための整理
会話が長くなると、古い前提や試行錯誤が文脈を占めます。/compactは会話の要点を要約し、次の作業に必要な余白を作るためのコマンドです。単に「会話を短くする」機能ではなく、引き継ぐべき制約を明示するタイミングでもあります。
たとえば、次のように焦点を添えると整理後の会話が安定します。
/compact 仕様、未解決の不具合、変更してはいけない公開APIを残して要約してただし、ログの細部や過去の検証結果を逐語的に残す用途には向きません。あとで必要になるコマンド出力、URL、手順、判断理由は、Gitのコミット、Issue、README、作業メモなど外部の記録にも残してください。
/diff：AIに任せた変更を人が読むための場所
/diffは未コミット差分を読みやすく確認するための入口です。AIに実装を任せると、最終的な品質を決めるのは「何を変えたか」を読めるかどうかになります。動いたからOK、テストが通ったからOK、ではなく、意図しない設定ファイルや依存関係、公開APIの変更が混ざっていないかを確認します。
確認の順番は、次の3点がおすすめです。
- 変更ファイルの数が想定と合っているか
- 目的と関係ない削除や設定変更がないか
- 例外処理、入力検証、ログに機密情報が混ざっていないか
特に、依頼したのが小さな修正なのに多数のファイルが変わっている場合は、そのまま続けず理由を聞きます。/diffはレビュー専門家の代わりではありませんが、AIの作業を人の判断へ戻すための重要な境界です。
/review：レビュー観点を増やす
/reviewは差分を対象に問題点や改善点を確認するためのコマンドです。/code-reviewの別名として扱われる環境もあります。レビューはテストと役割が違います。テストは想定した振る舞いが保たれているかを確かめ、レビューは想定していなかった問題、責務の混在、読みづらさ、境界の弱さを見つけるためのものです。
まずは修正を終えた後に、次のような小さな依頼と合わせると実用的です。
/review
この変更で壊れやすい境界、入力処理、エラー処理だけを優先して確認して見つかった指摘をすべて自動修正に回す必要はありません。影響範囲、期限、既存設計との整合を見て、採用するかを自分で決めます。
場面別の使い分け
新しい作業を始める：/status → /help → 通常のプロンプト
新規タスクでは、最初に状態を見てから、目的と制約を通常の言葉で伝えます。スラッシュコマンドだけで作業を始めようとすると、何を完成とするかが曖昧になりがちです。良い依頼は「対象」「変えてよい範囲」「完了条件」「確認方法」の4点を含みます。
たとえば「ログイン画面のエラー表示を直して」よりも、「ログイン失敗時の文言だけを修正し、API仕様と成功時の導線は変えない。既存テストを通し、変更ファイルを最後に列挙して」と伝える方が、/diffで確認しやすい変更になります。
会話が長くなった：/context → /compact
話題が増えたり、大量のログを貼ったりした後は、/contextで文脈の使用状況を見ます。そのうえで、今後不要な試行を切り、残すべき制約を指定して/compactを使います。コンパクト化の前に、未解決事項を箇条書きにしておくと、要約漏れを減らせます。
ここでよくある失敗は、要約後に「前に言ったはずの細かい条件」が消えたと感じることです。会話だけに依存せず、仕様はリポジトリの文書、Issue、タスク管理に残すのが本筋です。AIとの会話は作業台であり、唯一の正本ではありません。
方向を変える：/clear と /resume を使い分ける
/clearは新しい話題へ切り替えるときに便利です。古い前提が新しい作業へ混ざるのを避けられます。ただし、未完了の作業を忘れるためのボタンではありません。切り替える前に、現在の変更をコミットする、メモを残す、次の一手を明文化する、のいずれかを行います。
反対に、途中の作業へ戻るなら/resumeが向きます。セッション名を/renameで分かりやすくしておくと、数日後の再開が楽になります。例として、api-auth-timeout-investigationのように、目的と対象を含めた名前にすると見分けやすくなります。
実装を確かめる：/diff → /review → /verify
変更を確認する順番は、差分を読む、設計・実装上の問題を点検する、実際に起動・動作を観察する、が自然です。/verifyはテストだけでなく、アプリを起動して振る舞いを確認するための支援として提供される場合があります。実行方法が複雑なプロジェクトでは、環境変数、DB、外部API、ブラウザ操作など前提があるため、実行前に対象環境を限定してください。
本番環境へ影響する操作、課金を伴うAPI、外部への送信、データ削除を含むテストは、通常のローカル確認と分けます。「確認のためだから安全」とは限りません。テストデータ、dry-run、読み取り専用の資格情報を用意できないかを先に考えましょう。
不調を調べる：/debug と /doctor
アプリの不具合と、Claude Codeの環境・設定の不具合は分けて扱います。前者ならプロジェクトのログ、再現条件、テストを中心に見ます。後者なら/debugや/doctorが候補になります。/doctorは診断だけでなく修復提案を含む場合があるため、表示内容を読んでから進めます。
特に複数のインストール、PATH、設定ファイル、プラグインが関わる場合、いきなり削除や再インストールを選ばないことが重要です。現状を記録し、変更対象を一つに絞り、再現が消えたか確認する方が、あとで原因を説明できます。
便利だが慎重に使うコマンド
/permissions：許可は作業単位で設計する
/permissionsはツール実行の許可ルールを扱います。入力待ちを減らしたくなる場面はありますが、広い許可は誤操作の影響範囲も広げます。読み取り、テスト、特定ディレクトリへの書き込み、外部通信、削除を同じ強さで許可しないようにします。
おすすめは、まず読み取り専用と頻出の安全な検証だけを限定して許可し、書き込み・外部送信・本番操作は毎回確認を残す運用です。コマンド列全体ではなく、対象パスやサブコマンドまで狭められるなら狭めます。
/mcp と /plugin：接続先は能力ではなく権限で見る
MCPサーバーやプラグインは、AIが扱える情報源や操作先を増やします。しかし「便利な連携」には、ファイル、チケット、クラウド、チャット、顧客データなどへのアクセスが含まれることがあります。導入前に、接続先、読み取り・書き込みの別、利用者、保存されるログ、切断方法を確認します。
新しい連携を入れたら、最初の実行は小さな読み取り操作に限定し、期待どおりのデータだけが見えるか確認します。ツールが一覧に表示されたことは、正しい権限設計の証明ではありません。
/schedule：定期実行は「誰が最終確認するか」まで決める
スケジュール実行は、毎週の確認や定型レポートに便利です。一方で、実行環境、認証期限、重複起動、費用、通知先、失敗時の扱いを決めないまま自動化すると、手作業より把握しづらくなります。
定期化する前に、次の5点を決めてください。
- 実行してよい対象と、絶対に触らない対象
- 成功の判定と、失敗時に残す記録
- 通知先と、確認する人
- 一時停止・削除の手順
- 同じジョブを別PCや別サービスで二重に動かさない責任者
コマンド一覧を「自分用の最小セット」にする
公式一覧には、多くのコマンドがあります。そこで、自分の作業に不要なものまで覚えようとする必要はありません。まず次のテンプレートを自分用に埋めてください。
| 目的 | 最初に使う候補 | 人が確認すること |
|---|---|---|
| 今日の作業を再開 | /status、/resume |
ディレクトリ・モデル・未完了事項 |
| 長い会話を整理 | /context、/compact |
残す制約と未解決事項 |
| 変更を確認 | /diff、/review |
対象外ファイルや危険な変更 |
| 実際の動作を確認 | /verify |
実行環境と外部影響 |
| 接続を追加・変更 | /mcp、/plugin |
読み書き権限、データ、撤回方法 |
| 定期化 | /schedule |
重複、費用、通知、停止方法 |
この表は、コマンド名が変わったり新機能が追加されたりしても機能します。目的から公式の最新画面を確認する運用にしておけば、特定の古い記事に依存しません。
よくある疑問
「ネットのコマンド一覧と自分の画面が違う」
珍しいことではありません。公式資料でも、コマンドの可否はプラットフォーム、プラン、環境に依存すると説明されています。まず手元の/helpを優先し、公式ドキュメントで目的を確認してください。見つからないコマンドを設定ファイルへ無理に追加するのは避けましょう。
「/compactをすれば仕様書は不要？」
不要にはなりません。要約は会話を続けるための補助で、仕様の正式な置き場ではありません。第三者が読んでも分かる決定、公開API、運用ルール、実行手順は、リポジトリやチームの文書へ残します。
「レビューをAIに任せれば人は読まなくてよい？」
人のレビューを省く根拠にはなりません。AIレビューは観点を増やす助けになりますが、プロダクトの目的、顧客への影響、リリース判断、セキュリティ責任は人が持ちます。とくに認証、決済、削除、権限、個人情報、外部送信に関わる差分は、必ず人が確認してください。
「コマンドを実行する順番は決まっている？」
厳密な正解はありません。ただし、変更に進む前に状態を確認し、変更後は差分を読み、実行が必要なら対象環境を限定して確かめる、という順番は多くの作業で再利用できます。/status、通常の依頼、/diff、/review、必要に応じて/verifyという流れです。会話が長い場合だけ、この間に/compactを挟みます。
重要なのは、コマンドが作業の目的を代わりに決めてくれるわけではない点です。「どのファイルを変えるか」「いつ公開するか」「どこまで自動化するか」は、依頼文とレビュー基準で明示します。コマンドを増やす前に、作業の完了条件を短い一文にできるかを確認すると、かえって操作が減ります。
「他の人や別の端末でも同じ設定を使える？」
設定を共有する場合は、便利さと再現性を分けて考えます。プロジェクトに必要なルール、テスト方法、扱ってよいディレクトリは、リポジトリで管理する文書へ置くとレビューできます。一方、個人用の表示設定や端末固有の認証は、無理に共有しない方が安全です。複数端末で定期実行や自動化をするなら、同一ジョブが二重に走らないよう、実行の所有者を一つに決めてから移行してください。
実運用前のチェックリスト
- □
/helpで手元の環境に表示されるコマンドを確認した - □ まずは
/status、/compact、/diff、/reviewの4つから使い始めた - □ 長い会話で残すべき仕様・未解決事項を外部の文書にも記録した
- □ 権限ルールを読み取り、書き込み、外部送信で分けた
- □ MCP・プラグインの接続先と読み書き権限を確認した
- □ 自動実行の成功条件、通知先、停止方法、重複起動の責任者を決めた
- □ 本番・課金・削除・公開に関わる操作は人の確認を残す方針にした
まとめ
Claude Codeのスラッシュコマンドは、数を覚えるための機能ではありません。今いる場所を知る、会話を整える、差分を確認する、接続と権限を安全に扱うための道具です。まずは/status、/compact、/diff、/reviewという小さなセットを使い、必要なときだけ/permissions、/mcp、/plugin、/scheduleへ広げていきましょう。
新しいコマンドが追加されても、目的・影響範囲・戻し方の3点で判断すれば、流行に振り回されずに使えます。
運用を始めた後は、月に一度だけでも/helpと公式のCommandsページを見比べ、不要になった許可や使わなくなった連携を見直すとよいでしょう。新機能を増やすより、現在の運用を小さく安全に保つ方が、長い目では開発速度を支えます。
コメント