Claude Codeのスラッシュコマンド完全解説 — 一覧・使い方・自作の手順【2026年最新】

スラッシュコマンドとは — 定型作業を1行で呼び出す仕組み

「/」から始まる1行で、決まった操作や手順を実行する

スラッシュコマンドは、Claude Codeの入力欄で「/」に続けて名前を打つと実行できる命令です。たとえば/clearと打てば会話履歴がリセットされ、/modelと打てば使うAIモデルを切り替えられます。入力欄に「/」を打つだけで候補が一覧表示されるので、うろ覚えでも問題ありません。

チャットで自然文の指示を打つのとの違いは、結果が毎回ブレないことです。自然文は言い回し次第でAIの動きが変わりますが、コマンドは決まった操作・決まった手順書を呼び出すので、誰がいつ打っても同じように動きます。業務でいえば、口頭で毎回説明するのをやめて手順書を1枚作り、それをボタン化するイメージです。

スラッシュコマンドは3種類ある

ひとくちにスラッシュコマンドと言っても、中身は3種類に分かれます。この区別を最初に押さえておくと、公式ドキュメントやネットの情報を読むときに混乱しません。

ビルトインは「アプリの操作ボタン」、バンドルスキルとカスタムコマンドは「AIに渡す指示書のショートカット」と考えると分かりやすいです。この記事では前半でビルトインを、後半でカスタムコマンドの作り方を扱います。

2026年の重要な変更 — カスタムコマンドは「スキル」に統合された

以前のClaude Codeでは、自作コマンドは.claude/commands/フォルダにMarkdownファイルを置いて作るのが標準でした。現在は公式ドキュメントで「カスタムコマンドはスキル（Skills）に統合された」と明言されており、.claude/skills/フォルダにSKILL.mdを置く方式が推奨になっています。

重要なのは、昔ながらの書き方も引き続き動くという点です。.claude/commands/deploy.mdと.claude/skills/deploy/SKILL.mdは、どちらも/deployというコマンドを作り、同じように機能します。ネット上の解説記事は旧方式のものが多いですが、「どちらで書いても動く。これから作るならスキル方式」と覚えておけば大丈夫です。この違いは後半の作り方のところで詳しく説明します。

まず覚えるべきビルトインコマンド15選

15コマンドの一覧表

80個近いコマンドを最初から全部覚える必要はありません。僕自身の日々の使用頻度と、ShiftBの受講生がつまずいたときに「これを知っていれば解決した」という場面から逆算して、最初に覚えるべき15個に絞りました。

15個は4つのグループで覚える

バラバラに暗記するのではなく、役割で4グループに分けて覚えるのがおすすめです。

• 会話の管理：/clear・/compact・/resume・/rewind。会話を「切る・畳む・戻る・巻き戻す」の4操作です。
• お金とリソース：/model・/usage・/context。モデルの使い分けと使用量の見える化です。
• 環境設定：/config・/permissions・/mcp・/doctor・/status。最初に整えて、不調のときに見直す系です。
• プロジェクトの記憶：/init・/memory・/help。AIに前提を覚えさせて、指示を短くするための土台です。

余裕が出てきたら覚えたいコマンド

15個に慣れたら、次の段階として押さえておくと便利なものを挙げます。/code-review（/reviewでも可）は変更内容のレビューをAIに依頼するバンドルスキルで、コードを書いた後の品質チェックに使えます。/security-reviewは変更差分のセキュリティ観点でのチェック、/exportは会話内容のテキスト書き出し、/add-dirは作業対象フォルダの追加です。/planで実行前に計画を立てさせるプランモードに入れるのも、大きめの依頼をするときに重宝します。

Claude Code自体の導入がまだの人は、先にClaude Codeの使い方完全ガイドでインストールと初期設定を済ませておくと、この記事の内容をすぐ試せます。

場面別の使いこなし — セッション管理・コンテキスト・やり直し

作業の始め方 — /init と /memory で前提を仕込む

Claude Codeを新しいプロジェクトで使い始めたら、最初にやるべきは/initです。プロジェクトの中身をAIが分析して、CLAUDE.mdという「常設の指示書」を自動生成してくれます。CLAUDE.mdに書かれた内容は毎回の会話で自動的に読み込まれるので、「毎回同じ前提を打ち直す」手間がここで消えます。

運用しながらルールを足したくなったら/memoryで編集します。「ファイル名は日本語にしない」「報告書はですます調で」のような細かい約束事を書き溜めていくと、指示がどんどん短くなっていきます。CLAUDE.mdの書き方はCLAUDE.mdの書き方ガイドで詳しく解説しているので、あわせて読んでみてください。

長い作業の途中 — /context で見て、/compact で畳む

AIには「コンテキスト」と呼ばれる作業記憶の上限があり、長く作業を続けると記憶が埋まって動きが鈍くなったり、前半の指示を忘れたりします。そこで使うのが/contextと/compactのペアです。

/contextを打つと、いま何がどれだけ記憶を占有しているかが色付きのグリッドで表示されます。埋まってきたなと思ったら/compactで会話を要約させて空きを作ります。このとき/compact 実装方針の決定事項は残してのように、要約時に残してほしいものを指示できるのがポイントです。何も考えずに/clearで全部消すのではなく、「大事な決定は残して畳む」を覚えると、長時間の作業が安定します。

なお、記憶が上限に近づくと自動で要約が走る仕組み（オートコンパクト）もあるので、放置しても作業が完全に止まるわけではありません。ただ、自動要約は何を残すかを選べません。大事な局面では自分のタイミングで/compactを打ち、残すものを指定する方が、その後の出力の質が安定します。

失敗したとき — /rewind で巻き戻す

AIに任せていると、「指示を誤解されて、ファイルを思っていない方向に書き換えられた」という事態が必ず起きます。ここで慌てて「元に戻して」とチャットで頼むと、戻し方までAI任せになってさらにズレることがあります。確実なのは/rewindです。Claude Codeは作業の節目ごとにチェックポイントを自動で取っており、コードと会話をセットで特定時点まで巻き戻せます。「AIの変更はいつでも巻き戻せる」と分かっていると、思い切って任せられるようになるので、心理的な効果も大きいコマンドです。

大きめの依頼は /plan で計画から、脇道の質問は /btw で

「ファイルをまとめて整理して」「このデータから月次レポートを作って」のような大きめの依頼をいきなり投げると、AIが想定と違う方向に走り出すことがあります。そこで使えるのが/planです。プランモードと呼ばれる状態に入り、AIは実行前にまず計画を提示して、承認してから作業を始めるようになります。部下に仕事を頼むときに「まず段取りを聞いてから任せる」のと同じ運用が、コマンド1つでできるわけです。

もう1つ地味に便利なのが/btwです。作業の途中で「ところでこの用語ってどういう意味？」と聞きたくなったとき、普通に質問すると会話の流れに混ざってAIの作業記憶を消費します。/btwに続けて質問すると、本筋の会話に影響を与えずに脇道の質問だけができます。専門用語を確認しながら進めたい初学者ほど恩恵が大きいコマンドです。

コストの管理 — /usage と /model の使い分け

/usage（/costでも同じ）でトークン使用量を確認し、/modelでモデルを切り替える。この2つはセットで運用します。難しい設計判断や長い文書の作成は上位モデル、単純な修正や質問は軽いモデル、という使い分けができるようになると、同じプランでも体感の「使える量」が変わってきます。AIツールの料金プラン全体の考え方はAIツール月額コスト比較の記事でも整理しています。

ここまでがビルトインコマンドの世界です。正直なところ、この辺までは調べれば出てくる情報でもあります。差がつくのはここから先、自分の業務に合わせてコマンドを「作る」側に回れるかです。ShiftBの受講生を見ていても、ツールの操作を覚えることより、「自分の仕事のどこを切り出してAIに任せるか」の設計で手が止まる人が圧倒的に多い。そしてそこは、独学だと正解が分からないまま時間だけが過ぎやすい部分でもあります。

カスタムスラッシュコマンドの作り方 — 最初の1個を5分で

最小構成 — Markdownファイルを1つ置くだけ

カスタムコマンドの実体は、ただのMarkdownファイルです。プログラミングの知識は必要ありません。プロジェクトのフォルダに.claude/skills/というフォルダを作り、その中にコマンド名のフォルダとSKILL.mdを置きます。

.claude/
└── skills/
    └── weekly-report/
        └── SKILL.md

SKILL.mdの中身は、次のような構成です。

---
description: 今週の作業ログから週報のたたき台を作る
---

以下の手順で週報を作成してください。

1. work-log.md から今週の日付の行を抜き出す
2. 「完了したこと」「進行中」「来週の予定」の3項目に分類する
3. 上司向けのですます調で、A4半分程度にまとめる

冒頭の---で囲まれた部分は「フロントマター」と呼ばれる設定欄で、descriptionにはこのコマンドが何をするかを書きます。その下の本文が、コマンドを打ったときにAIへ渡される指示書です。これだけで/weekly-reportというコマンドが使えるようになります。ファイルを保存すれば、再起動なしで同じセッションからすぐ認識されます。

置き場所は2つ — プロジェクト用と個人用

コマンドの置き場所によって、使える範囲が変わります。プロジェクトのフォルダ内（.claude/skills/）に置けばそのプロジェクト専用になり、Gitで共有すればチームメンバー全員が同じコマンドを使えます。ホームフォルダ（~/.claude/skills/）に置けば、自分のすべてのプロジェクトで使える個人用コマンドになります。仕事の手順書はプロジェクト用、自分の文体設定のような私物は個人用、と分けるのが基本です。なお同じ名前のコマンドが両方にある場合は、個人用が優先されます。

冒頭で触れたとおり、旧方式の.claude/commands/にMarkdownファイルを置く書き方も引き続き動きます。ただしスキル方式には、テンプレートや参考資料などの補助ファイルを同じフォルダに同梱できるという利点があるため、これから作るならスキル方式をおすすめします。公式ドキュメントではSKILL.md本体は500行以内に収め、長い資料は別ファイルに分けることが推奨されています。

引数で汎用化する — $ARGUMENTSの使い方

コマンドに続けて入力した文字列は、$ARGUMENTSという書き方で指示書に埋め込めます。たとえば議事録整形コマンドなら、次のように書きます。

---
description: 会議メモを議事録の形式に整形する
argument-hint: [会議名]
---

$ARGUMENTS の会議メモを、次の形式の議事録に整形してください。

- 決定事項（箇条書き）
- 宿題と担当者（表形式）
- 次回までの期限

これで/minutes 営業定例と打てば、「営業定例」の部分が$ARGUMENTSに差し込まれて実行されます。複数の引数を順番に使いたい場合は、1つ目を$0、2つ目を$1のように位置で指定することもできます。argument-hintは入力時に「何を入れればいいか」のヒントを表示してくれる設定です。

一歩進んだ設定 — 実データの自動読み込みと安全装置

覚えておくと世界が変わる機能を2つだけ紹介します。1つ目は動的コンテキスト注入です。指示書の中に !`コマンド` の形でシェルコマンドを書いておくと、実行時にその出力結果が指示書に自動で差し込まれます。たとえば !`git diff HEAD` と書けば、AIは「いま実際に変更されている内容」を見た上で作業を始められます。推測ではなく実データに基づかせる仕組みで、各コマンドの実行には2分のタイムアウトが設定されています。

2つ目は安全装置系のフロントマターです。disable-model-invocation: trueを書くと、そのコマンドは自分が打ったときだけ動き、AIが気を利かせて勝手に実行することがなくなります。デプロイ（公開作業）やメール送信のような、取り返しのつかない操作をコマンド化するときの必須設定です。ほかにも、許可なしで使えるツールを絞るallowed-tools、そのコマンド実行時だけモデルを変えるmodelなど、フロントマターだけでかなり細かく挙動を制御できます。設計パターンやチーム運用の深掘りはカスタムコマンド活用術の記事に詳しくまとめています。

非エンジニアの業務で使えるコマンドレシピ集

レシピの考え方 — 「毎週やっている作業」から探す

コマンド化する対象の探し方はシンプルで、「毎回ほぼ同じ手順で、毎回ほぼ同じ形式の成果物を作っている作業」を書き出すことです。週報、議事録、定例レポート、問い合わせ返信、チェック作業。この条件に当てはまる作業は、手順を1回だけ丁寧に言語化すれば、2回目以降はコマンド1行になります。

言語化のコツは、「新入社員に引き継ぐつもりで書く」ことです。「いい感じにまとめて」ではなく、「どのファイルのどの部分を読み、何と何に分類し、誰向けの文体で、どのくらいの分量にするか」まで指定します。曖昧な指示はAIの出力もブレますが、これは人間相手でも同じです。逆に言えば、業務の引き継ぎ資料を書いた経験がある人なら、その書き方がほぼそのまま通用します。

僕がiDM Replyのカスタマーサポートを1日3時間から30分以下まで圧縮できたのも、根っこは同じ考え方です。よくある問い合わせパターンへの対応手順を仕組みに落とし、自分は例外だけを見る。「作業をこなす」から「作業の仕組みを作る」への切り替えが、スラッシュコマンドという形で誰にでも再現できるようになった、というのがいまの状況です。

そのまま使える業務レシピ4つ

職種を問わず使いやすいレシピを4つ挙げます。いずれも前セクションの手順でSKILL.mdを作り、本文を差し替えるだけで動きます。

• /weekly-report（週報のたたき台）：作業ログのファイルから今週分を抜き出し、完了・進行中・来週予定の3分類でまとめさせる。前セクションの例がそのまま使えます。
• /minutes（議事録整形）：走り書きの会議メモを、決定事項・宿題と担当者・期限の定型フォーマットに整形させる。
• /csv-summary（データ集計レポート）：フォルダに置いたCSVファイル（Excelから書き出した表データ）を読み込み、前月比の変化と気になる点を3つ挙げた上で、報告用の文章にまとめさせる。
• /reply-draft（問い合わせ返信の下書き）：問い合わせ文を引数で渡すと、社内の回答ポリシーに沿った返信の下書きを敬語レベル別に2案作らせる。

ポイントは、どのレシピも「最終判断は人間がする」設計にしておくことです。AIの出力をそのまま送るのではなく、たたき台を量産させて人間が仕上げる。この分担にしておくと、精度が完璧でなくても業務時間は確実に減ります。

もう1つ、運用のコツとして「手順書は育てるもの」だと考えてください。1回目の出力が期待と違ったら、チャットで修正指示を出して終わりにするのではなく、その修正内容をSKILL.mdに書き足します。「分量が多すぎた→文字数の上限を手順書に明記」「表現が硬すぎた→文体の見本を追記」。この積み重ねで、コマンドは使うたびに賢くなっていきます。

ShiftBの実例 — 記事作成の全工程を1コマンドにした/write-article

実際にどこまでできるのかの例として、ShiftBで運用している/write-articleを紹介します。これはオウンドメディア記事の作成工程をまるごと1つのスキルにしたもので、指示書には次の内容が含まれています。

• 過去記事一覧と照合したテーマの重複チェック
• 検索上位記事のリサーチと差別化ポイントの特定
• 文体ルール（AIっぽい表現の禁止リスト）に沿った執筆
• 図解画像・サムネイル画像の生成手順
• 数字や引用の捏造を洗い出すファクトチェックの手順

指示書を一度作り込んでおけば、「/write-article テーマ名」と打つだけでこの工程全体が走ります。冒頭で書いたとおり、この記事自体もこのコマンドから生まれています。大事なのは、これが特別なプログラミング技術ではなく、ここまで解説してきたSKILL.mdの仕組みを煮詰めただけだという点です。書かれているのは日本語の手順書であって、コードではありません。

ただ、正直に付け加えると、レシピをコピーして動かすことと、自分の業務に合わせて改造し続けることの間には壁があります。手順書の粒度をどこまで細かくするか、AIの出力をどう検証するか、どこから先を人間に残すか。この設計判断は、AIの出力の「中身」がある程度読めるようになると一気に精度が上がります。ShiftBの受講生データでも、基礎を学んでから作った人のサービスリリース率は84%、基礎なしでは28%と、3倍の差がついています。ツールの習熟よりも、土台の理解が結果を分けるというのが、150名以上を見てきた実感です。

スラッシュコマンドのつまずきポイントと対処法

作ったコマンドが候補に出てこない

いちばん多いつまずきです。原因はだいたい、以下のどれかに当てはまります。

• 置き場所の間違い：.claude/skills/の直下にSKILL.mdを置いている（正しくはコマンド名のフォルダを挟んで.claude/skills/コマンド名/SKILL.md）。
• 起動フォルダの違い：プロジェクト用コマンドは、そのプロジェクトのフォルダでClaude Codeを起動したときに読み込まれます。別のフォルダから起動していると出てきません。
• フォルダ自体が新規：セッション起動後に.claude/skills/フォルダそのものを新しく作った場合は、一度Claude Codeを再起動すると認識されます。既存フォルダ内のファイル追加・編集は再起動なしで反映されます。

同じ名前のコマンドがぶつかった

コマンド名が重複した場合の優先順位は決まっています。個人用（~/.claude/skills/）がプロジェクト用（.claude/skills/）に優先し、自作コマンドは同名のバンドルスキルを上書きします。また、旧方式の.claude/commands/と新方式のスキルが同名の場合は、スキル側が動きます。「チームの共有コマンドと同じ名前で自分用を作ったら、自分のばかり動く」という現象はこの優先順位が原因です。名前を変えるのが手っ取り早い解決策です。

コマンドの指示が途中から効かなくなった気がする

コマンドで読み込んだ指示書の内容は、セッションの間はAIの記憶に残り続けます。ただし長い作業で/compactなどの要約が挟まると、古い指示の一部が圧縮されて優先度が下がることがあります。挙動が怪しくなったら、同じコマンドをもう一度打って指示を読み込み直すのが確実です。毎回必ず守らせたいルールなら、コマンドではなくCLAUDE.mdに書く方が向いています。

実行が許可のところで止まる

コマンドを打ったのに、ファイル操作やシェル実行のたびに確認ダイアログが出て流れが止まる、という相談もよく受けます。これはトラブルではなく、Claude Codeの権限管理が正しく働いている状態です。毎回許可するのが面倒な操作は、/permissionsで恒久的な許可ルールを設定するか、コマンド側のフロントマターにallowed-toolsで「このコマンドの実行中だけ許可する操作」を書いておくと、確認なしで流れるようになります。

1つ注意があるとすれば、指示書内の!`コマンド`（動的コンテキスト注入）は確認ダイアログを出さない設計になっており、許可されていない操作が含まれているとコマンドの実行自体が中断されます。「打った瞬間にエラーで止まる」場合は、注入コマンドが許可ルールと衝突していないかを疑ってください。

安全に使うための注意 — 共有コマンドの中身は読む

注意点も1つ。フロントマターのallowed-toolsは「確認なしで実行できる操作」を広げる設定なので、他人が作ったコマンドを使うときは、実行前に中身を一読する習慣をつけてください。社内共有やネット上の配布物をそのまま使う場合も同じです。中身はただのMarkdownなので、開けば日本語（や英語）で何をするかが書いてあります。読んで分からない操作が入っていたら、使う前に作者に確認するのが安全です。

よくある質問（FAQ）

Q1. プログラミング未経験でもカスタムコマンドは作れますか？

作れます。カスタムコマンドの実体は日本語で書いたMarkdownの手順書で、コードは1行も必要ありません。必要なのはフォルダを作ってテキストファイルを置くことと、自分の業務手順を言語化することの2つです。むしろ後者、「自分の仕事の手順を明文化するスキル」の方が本質で、これは職種を問わず鍛えられます。

Q2. カスタムコマンドとCLAUDE.mdはどう使い分けますか？

「毎回必ず守ってほしい前提」はCLAUDE.md、「特定のときだけ実行する手順」はコマンド、が使い分けの基準です。CLAUDE.mdは全会話で自動読み込みされるため、書きすぎるとAIの作業記憶を圧迫します。一方コマンドの本文は呼び出したときだけ読み込まれるので、長い手順書はコマンド側に置くのが効率的です。

Q3. チームでコマンドを共有するにはどうすればいいですか？

プロジェクトのフォルダ内.claude/skills/にコマンドを置き、Git（ファイルの変更履歴を共有する仕組み）でプロジェクトごと共有するだけです。メンバーがそのプロジェクトでClaude Codeを開けば、同じコマンドが全員の候補に表示されます。手順書の属人化を防げるので、チームでのAI活用を標準化する第一歩としても有効です。

Q4. 昔作った.claude/commands/のコマンドは作り直すべきですか？

急いで作り直す必要はありません。公式に「既存の.claude/commands/のファイルは引き続き動作する」と明言されています。ただし補助ファイルの同梱など新機能はスキル方式が前提なので、新しく作るものからスキル方式（.claude/skills/コマンド名/SKILL.md）に寄せていくのがおすすめです。

Q5. スラッシュコマンドとMCPは何が違いますか？

スラッシュコマンドは「AIへの指示や操作のショートカット」、MCPは「AIと外部サービス（SlackやNotionなど）をつなぐ接続規格」です。役割が違うので対立するものではなく、組み合わせて使います。たとえば「Slackから今日のメンションを集めて返信案を作る」というコマンドは、MCPでSlackにつないだ上で、その手順をコマンド化する形になります。MCPの詳細はMCPサーバーの解説記事を参照してください。

Q6. コマンドを増やしすぎると逆に混乱しませんか？

なります。だからこそ、最初は「週1回以上使う作業」だけに絞るのがおすすめです。僕の経験則では、思いつきで作ったコマンドの多くは1回しか使われません。まず1個作って1週間運用し、実際に打った回数を見てから次を作る。この順番だと、生きたコマンドだけが残ります。

まとめ — コマンド化は「AIで作る側」への第一歩

この記事の要点を整理します。

• スラッシュコマンドは「/」で呼び出す命令で、ビルトイン・バンドルスキル・カスタムの3種類がある
• ビルトインは15個だけ覚えれば十分。「会話の管理」「お金とリソース」「環境設定」「プロジェクトの記憶」の4グループで押さえる
• カスタムコマンドはMarkdownの手順書1枚で作れる。2026年からはスキル方式（.claude/skills/）が推奨で、旧方式も動く
• コマンド化の対象は「毎回同じ手順・同じ形式の作業」。週報・議事録・集計・返信下書きは職種を問わず効く
• 取り返しのつかない操作にはdisable-model-invocation、他人のコマンドは中身を読んでから使う

スラッシュコマンドの本質は、ツールの小技ではなく「自分の仕事を手順書に分解して、仕組みに変える」訓練だと僕は考えています。1個目のコマンドを作った人は、必ず2個目の対象を探し始めます。仕事を分解する目ができてくると、コマンド化できる作業が次々に見つかるからです。その繰り返しの先に、繰り返し作業を仕組みごと消して、社内で「AIで作れる人」として頼られるポジションがあります。まずは今週の週報から、コマンド1行にしてみてください。