Claude Code カスタムスラッシュコマンドで退屈な作業を関数化する

ご存知の様に、いま巷では Claude Code や Gemini Cli といった、CLIで働くエージェントツールが話題の中心となっています。特に Claude Code はその牽引役として開発現場に大きな変化をもたらしています。

AIの流行は変化が激しすぎるので、この流れがずっと続くかどうかはわかりません。今最前線を走っている Claude Code も明日には新しい何かにとって代わられるかもしれません。怖くもありますが、とても楽しい時期ですね。

Gaji-Labo でも Claude Code の活用を強く推進していて、そのなかで得られた新しい知見などは積極的に発信して参ります。この記事では Claude Code のスラッシュコマンドの活用について紹介していきます。

Claude Code のスラッシュコマンド

• Slash Commands – Anthropic

スラッシュコマンドは Claude Code を効率的に活用するための制御インターフェースといったところで、スラッシュ文字からコマンド名を続けて打つことで様々な機能を呼び出すことができます。

Claude Code を起動して /help を実行すると（この /help 自体がスラッシュコマンドです）組み込みのスラッシュコマンドの一覧が表示されます。2025年7月現在の一覧は次のようになっています。将来的にはさらに増えるかもしれません。

Interactive Mode Commands:
  /add-dir - Add a new working directory
  /bug - Submit feedback about Claude Code
  /clear - Clear conversation history and free up context
  /compact - Clear conversation history but keep a summary in context. Optional: /compact
  [instructions for summarization]
  /config - Open config panel
  /cost - Show the total cost and duration of the current session
  /doctor - Checks the health of your Claude Code installation
  /exit - Exit the REPL
  /export - Export the current conversation to a file or clipboard
  /help - Show help and available commands
  /hooks - Manage hook configurations for tool events
  /ide - Manage IDE integrations and show status
  /init - Initialize a new CLAUDE.md file with codebase documentation
  /install-github-app - Set up Claude GitHub Actions for a repository
  /login - Sign in with your Anthropic account
  /logout - Sign out from your Anthropic account
  /mcp - Manage MCP servers
  /memory - Edit Claude memory files
  /migrate-installer - Migrate from global npm installation to local installation
  /model - Set the AI model for Claude Code
  /permissions - Manage allow & deny tool permission rules
  /pr-comments - Get comments from a GitHub pull request
  /release-notes - View release notes
  /resume - Resume a conversation
  /review - Review a pull request
  /status - Show Claude Code status including version, model, account, API connectivity, and tool
  statuses
  /upgrade - Upgrade to Max for higher rate limits and more Opus
  /vim - Toggle between Vim and Normal editing modes

公式ドキュメントの一覧 では一部を抜粋しているうえ /help の結果と得られる情報量は変わらないので、実際の挙動は使ってみないとわかりません。さらに 日本語のドキュメント では英語版と説明内容が大きく異なっていたりするので、Claude Code の変化にドキュメントのローカライズが追いついていないであろうことは想像に難くありません。情報を確認するときは必ず英語版ドキュメントを参照して、気になったコマンドは自分で試してみましょう。

よく使いそうなものは、例えばこのようなものがあります：

• /init : プロジェクトの初期化（CLAUDE.mdの作成）
• /clear : 会話履歴をクリアする
• /config : 設定を表示・変更する
• /review : コードレビューを依頼する
• /compact : 会話履歴を要約して圧縮する（Context Budgetの節約）

ためしてみよう : /review

早速試しに /review コマンドを使ってみましょう。

/review コマンドはエージェントにコードレビューを依頼するためのコマンドです。使い方は簡単で、 /review のあとにプルリクエストのURLを添えるだけでOKです。このように、いくつかのコマンドは「引数」を受け取ることが出来ることを覚えておきましょう。
（実際はこれを実行するために gh コマンドや GitHub MCP のセットアップをしなければなりませんが、ここではそれらが完了しているものとして割愛します）

/review https://github.com/[owner_id]/[repository_id]/pull/0000

このコマンドが実行されると、Claude Code は次のように働きます。

1. GitHub のプルリクエストの情報を取得する
2. ファイル差分やコメントなどを読み込む
3. このプルリクエストの内容からタスクの目的・方針を推論する
4. コードレビューを行い、レポートを提出する

つまり、 以前記事に書いたようなこと が、特になんの工夫も必要とせずコマンドを実行するだけで実現できてしまうのです。なんて便利なのでしょう！

このように、スラッシュコマンドはユーザーがClaude Codeで効率的に作業をするための手助けをしてくれるツール群として提供されています。

カスタムスラッシュコマンドについて

Claude Code には「カスタムスラッシュコマンド」という機能があります。これはその名の通り、先にあげたスラッシュコマンドをユーザーが独自に定義できる仕組みです。

定義は Markdown 記法で行い、ユーザーディレクトリまたはプロジェクトディレクトリ配下の .claude/commands ディレクトリに .md ファイルを保存します。CLAUDE.md のスコープと同様に、ユーザーディレクトリに置いたコマンドはそのユーザーが起動する全ての claude で使えますし（パーソナルコマンド）、プロジェクトディレクトリに置けばそのプロジェクトだけで使えるコマンドになります（プロジェクトコマンド）。

パーソナルコマンド :

• ユーザーに紐づく
• 保存場所 : ~/.claude/commands

プロジェクトコマンド :

• プロジェクト内で使える
• 保存場所 : [プロジェクトルート]/.claude/commands

.claude/commands/hello.md を作れば /hello として呼び出すことができます。

名前の重複

既に定義されている組み込みのスラッシュコマンドと同名のコマンドを作ってしまうと上書きできてしまうので注意が必要です。例えば help.md を作ればそれが有効となり、組み込みの /help コマンドは使えなくなってしまいます。

また、パーソナルコマンドとプロジェクトコマンドに同名のコマンドを定義した場合は、プロジェクトの方が活かされます。

名前空間

.claude/commands の中にディレクトリを作成すると、それは名前空間として機能します。例えば .claude/commands/fe/test.md のようなコマンドを作ると /fe:test として呼び出すことができます。これを活用することで名前の重複を回避したり、コマンドをカテゴライズしてまとめたり、パーソナルコマンドのなかでプロジェクトごとに仕分けするなど、扱いやすい様に整理・管理ができるようになります。

とてもシンプルな例

とても簡単な実例として、ランダムな言語で挨拶をしてくれるコマンドを作ってみましょう。

.claude/commands/hello.md :

---
description: ランダムな言語で挨拶をする
---

# Hello Command

このコマンドは、ランダムな言語で元気よく挨拶をする。
あいさつのあとには使用された言語を英語で出力する。

例：
こんにちは！
(Japanese)

このコマンドは hello.md という名前で作成したので /hello と打ち込めば呼び出せます。早速試してみましょう。

> /hello is running…

● Namaste!
  (Hindi)

こんな結果が返されれば成功です。

どんなコマンドを作るべきか迷ったら

カスタムスラッシュコマンドの可能性は広すぎて、どう活用するか迷ってしまいます。そんな時は、自分の普段のワークフローの中の煩雑で面倒な定型作業の手助けをしてくれるコマンドを作ってみると良いかもしれません。

この使い方はあまり「創造的」ではないし、Claude Code の可能性はそこにとどまるものではありませんが、まずはじめにカスタムスラッシュコマンドと触れ合う取っ掛かりとしてはちょうど良いものだと思います。

定型作業は多くの人にとって退屈で面白くはないものです。その一部をコマンドにしてチーム内で共有すれば、チームメンバーは楽しくて創造的なアクティビティに集中することができます。

さらにカスタムスラッシュコマンドの良いところは、自然言語で書かれているところです。コマンドファイルを共有すれば、それが何をしてくれるコマンドなのか誰にとっても一目瞭然で、使い方を説明する必要がありません。つまり「属人性の排除」にも一役買うのです。

定型的な作業を関数化する

ではさっそく、地味で面倒な作業を関数化してみましょう。定常のワークフローの中から小さなストーリーを切り取ってコマンド化します。

変更をコミットしてもらう

まずはとても小さなコマンドから試してみましょう。実装作業のキリの良いところでコミットをしますが、都度コミットメッセージを考えたり、定められたルールに従ったメッセージを準備するのがいささか面倒なので、それを /commit-staged というコマンドに切り出してみます。

想定するストーリー :

• 現在ステージされている変更から、日本語でコミットメッセージを作成する
• 運用上、コミットメッセージにはチケット番号を付与する（チケット番号はブランチ名にも付与されている）
• Conventional Commits に則って、 feat: fix: のような接頭辞を付与する
• コミット前にユーザーの承認を得る

.claude/commands/commit-staged.md :

---
description: ステージされた変更をコミットする
---

# Commit Staged Command

このコマンドは、現在ステージされている変更からコミットメッセージを作成してコミットを行う。
次のプロセスを順番にスキップせずに実行する。

1. 現在作業中のタスクのチケット番号をブランチ名から取得する
   !git branch --show-current
   チケット番号のパターン : `/[A-Z]+-\d+/`
   例 : ABC-0000
2. 現在ステージされている変更を取得する
   !git diff HEAD
3. 取得した変更に基づいて、明瞭で簡潔な日本語で適切なコミットメッセージを作成する
4. メッセージには Conventional Commits に則った接頭辞と、チケット番号を付与する  
   例: `ABC-0000 feat: 検索機能の実装`
5. メッセージをユーザーに提示して承認を得る
6. 承認を得たら `git commit` を実行する

使い方 :

/commit-staged

定型作業の関数化においては創造性よりも再現性が重要となります。何回実行しても同じような結果が得られることを期待したいです。その場合、普段のプロンプトよりも少し具体的に指示を書くと効果的と考えられます。

特に、毎回同じコマンドを使用する場合はそのままコマンドを記載してしまった方がAIに余計な思考をさせずにすみます。そして ! は通常のプロンプトフィールドでも使える「Bashモード」と呼ばれる機能で、 !git diff HEAD のように後ろにシェルコマンドを続けることで直接シェルコマンドを実行させることができます。

また、 ABC-0000 feat: 検索機能の実装 のように出力形式を具体的に例示するのはなかなか有効なプラクティスです。どのような形式で出力してほしいのか言葉を尽くして説明するより、ずっと効率的に確実にAIに伝えることができるはずです。

チケット情報から実装計画をたててもらう

issueチケットの情報を読み込んで具体的な実装計画をたててくれる /plan コマンドを考えてみましょう。

想定するストーリー :

• Github issue からチケットの情報を取得して理解する
• チケット上で明らかにされていない情報や、確認が必要な事項を列挙する
• 情報をもとに具体的な実装計画をたてる（すぐにアクションに移せるレベルの具体性をもたせる）
• 実装計画をファイルに出力する

.claude/commands/plan.md :

---
description: チケットURLからタスクの情報を取得して実装計画をレポートにして提出する
---

# Plan Command

このコマンドは、 $ARGUMENTS のチケットURLからタスクの情報を取得し、実装計画をレポートにまとめて出力する。
次のプロセスを順番にスキップせずに実行する。

## 1. チケット情報の取得

- $ARGUMENTS のチケットURLを参考にして、issueの情報をコメントも含めて取得する
  - このチケットに対する理解度を数値化し、レポートに記載する（最大100%）
  - 不明なポイントや確認が必要な事項があればレポートに記載する

## 2. 実装計画をたてる

- 取得した issue 情報をもとに実装計画をたてる
  - できる限り具体的な実装計画をたてる
  - 実際にコードベースのどのファイルの何行目をどのように編集するのかを明記する
  - 複数の方法が提案できる場合はメリット・デメリットをあわせて提示する

## 3. レポートを出力する

- レポートを Markdown で作成し、 @documents/reports/plan-{チケット番号}.md に保存する

使い方 :

/review https://github.com/[owner_id]/[repository_id]/issues/0000

AIに実装計画を練ってもらう場合、ニンゲンがその内容をレビューする必要があります。そのため計画は出来るだけ具体性をもっていて欲しいので、そのように指示を出しています。

$ARGUMENTS はコマンドに渡された引数を受け取るための変数です。ここでは GitHub issue のURLが格納されています。また、参照ファイルや出力先のファイルを明示的に指示したい場合は @ を使います。

ファイルに出力しておけばニンゲンもレビューしやすく、別のセッションでAI自身にレビューさせたり、そのまま実装させたりすることもできます。プロセスごとにファイルに出力しておけばレジュームやリトライも容易になるので、是非活用していきましょう。

毎朝、今日やるべきタスクを教えてもらう

Claude Code を秘書とみたてて、Github プロジェクトのタスクリストから今日進めるべきタスクを教えてくれるコマンドを考えてみましょう。タスクの管理方法はプロジェクトによって異なるものですが、例えばこんなストーリーが考えられます

- GitHub プロジェクトにあるタスクリストを取得し、次の条件でフィルタリングする
  - 自分がアサインされているもの
  - ステータスが  `To Do` または `In Progress` のもの
  - マイルストーンの期日が２週間以内のもの

これを朝実行してリスト出力してもらえば、今日優先的に着手しなければならないタスクが分かります。また例えば、ちょっとアレンジしてこのようなストーリーもあるかもしれません。

- GitHub プロジェクトにあるタスクリストを取得し、次の条件でフィルタリングする
  - ステータスが `In Review` にあるもの
  - 自分が Pull Request の reviewer に設定されているもの
  - マイルストーンの期日が２週間以内のもの

このリストは今日自分がレビューをしなければいけないチケットはどれかを教えてくれます。

ここでひとつ注意点ですが、どうやら Claude Code はほかのエージェントと比較しても、大きく複雑な構造データを扱うことが得意ではないようです。タスクリストに含まれる情報が膨大だった場合、それを読み込み理解するまでにとても長い時間を要することがあるのです。

この問題を解消するために、取得するフィールドを限定したり、取得する件数を制限するなどのチューニングが必要になるかもしれません。データ構造次第では、まとめて取得するよりも１件ずつ取得した方がはやい可能性すらあります。API や MCP ツールの仕様と相談して、工夫してみましょう。

おわりに

ここであげたストーリーは、普段ニンゲンが目視や手作業で行っている行動そのものです。そういった定型作業の一部をコマンドに任せることで、ニンゲンはニンゲンがやらなければならない仕事に集中できるのではないでしょうか。

カスタムスラッシュコマンドの可能性はこのような小さな作業にはとどまりません。まずは身近なところで活用を進めつつ、さらに大きな価値を生み出せるクリエイティブなコマンドのために研究をしていきたいですね。

Gaji-Labo Culture Deck