ニーリーアドベントカレンダー 15日目を担当する増田(ますた)です。
実は昨日誕生日を迎えました！
お祝いとしてぜひ先週に書いた記事も読んでいただけると嬉しいです！
今年からClaude Codeを利用するようになって、あまりの便利さにMaxプランから離れられなくなりました。 この記事では個人的に今年作っておいたお陰で助かったなっていうスラッシュコマンドをいくつか紹介します。
スラッシュコマンドとは
Claude Codeには、プロジェクト固有のプロンプトをコマンドとして登録できる機能があります。
作成したコマンドはClaude Codeに限らずCursorでも利用することが可能です。
.claude/commands/ ディレクトリにMarkdownファイルを置くと、Claude Code上で /ファイル名 として呼び出せるようになります。
your-project/ ├── .claude/ │ └── commands/ │ ├── smart-commit.md │ ├── deep-design.md │ └── create-pr.md └── ...
たとえば smart-commit.md を作成すると、Claude Codeで /smart-commit と入力するだけでそのプロンプトが実行されます。
チームで共有したい場合はリポジトリにコミットすればOKです。毎回同じ指示を手打ちする必要がなくなるので、かなり便利です。
1. smart-commit：コミットを自動で分割してくれるコマンド
開発に集中していると、気づいたら複数の変更がごちゃ混ぜになっていることがあります。「あ、これコミット分けなきゃ…」と思いつつ、適切な粒度を考えるのが地味にめんどくさいですよね。。
このコマンドは、変更内容を分析して適切なコミット粒度とメッセージを提案してくれます。
コマンドの内容（.claude/commands/smart-commit.md）:
# Smart Commit 変更内容を分析して適切なコミット粒度とメッセージでGitコミットを実行します。 ## 引数 $ARGUMENTS ## オプション - `-c`, `--check`: コミット前に内容を確認する（デフォルトは確認なしで即座にコミット） ## Instructions 以下の手順で進めてください： 1. **オプションの解析** - 引数に `-c` または `--check` が含まれている場合、確認モードとする - それ以外はデフォルトで即座にコミット実行 2. **現在の変更状況を確認** - `git status --porcelain` でファイル変更一覧を取得 - `git diff --staged` でステージされた変更を確認 - `git diff` でステージされていない変更を確認 3. **変更内容を分析** - 変更されたファイルの種類と内容を評価 - 変更の種類を以下から分類： - `feat`: 新機能追加 - `fix`: バグ修正 - `docs`: ドキュメント更新 - `style`: コードフォーマット変更 - `refactor`: リファクタリング - `test`: テスト追加・修正 - `chore`: その他の変更 - 複数の異なる種類の変更が混在している場合は分割を提案 4. **コミット戦略を決定** - 論理的なまとまりごとにコミット分割 - 各コミットに適切なメッセージを生成 - コミットメッセージは以下の形式: `<type>: <日本語での説明>` - 日本語でシンプルで明確なメッセージを心がける 5. **コミット実行** - **確認モード（`-c`/`--check`）の場合**: 提案した戦略をユーザーに確認してから実行 - **デフォルトの場合**: 確認なしで即座に `git add` と `git commit` を実行 - 複数コミットの場合は順次実行 ## Notes - プロジェクトのコーディング規約に従ったメッセージを生成 - CLAUDE.mdの情報を参照してプロジェクト固有の命名規則を適用 - 変更がない場合は適切にメッセージを表示 - **コミットメッセージは日本語で記述** - コミットメッセージはシンプルで実用的に - 不要な署名やメタ情報は含めない
使い方:
Claude Codeで /smart-commit と入力するだけ。変更内容を見て「この3ファイルは機能追加、この2ファイルはリファクタリングだから分けましょう」といった提案とコミットをしてくれます。
あまりにも内容が多く、自分でレビューをしたい場合には"-c"をつけることで勝手にコミットをせずにレビューをしてからコミットをしてくれるようにしています。
適切なコミット粒度の分割とコミットメッセージの作成作業からの解放は想像以上に楽になりました！
2. deep-design：AIとの対話でシステム設計を進めるコマンド
次に紹介するコマンドはdeep-designコマンドです
設計をする際に、頭の中で描いている設計はあるけどそれをいきなり形にするのが難しい、全てを出し切れた気がしない。。
そんな課題を解決するために作成したコマンドです。
このコマンドでは、作りたいものに対して懸念点がなくなるまでAIが質問を繰り返ししてくれるコマンドです。その質問を全て回答すると最終的に設計を作成してくれるコマンドになっています。
これによって設計に対する気軽さと網羅性を手に入れることができます。 もちろん全ての質問に回答したからといって100%の設計が毎回出てくるわけではないですが、ある程度の完成度のものが出来上がってくるのでこれをベースに微修正をかけて設計をしています。
コマンドの内容（.claude/commands/deep-design.md）:
# Deep Design あなたは経験豊富なシステム設計者です。ユーザーから設計したいシステムやプロダクトについて聞き、**すべての疑問点が完全に解消されるまで、しつこく質問を続けてください**。 ## 初期インプットの確認 ユーザーは以下のような情報を提供する場合があります： - 設計したいシステム/機能の概要 - 既存のドキュメント（設計書、仕様書、要件定義書など） - 関連するコードファイル - 参考資料やリンク **最初に行うこと：** 1. ユーザーから提供された情報をすべて確認する 2. 既存のドキュメントがある場合は、その内容を理解する 3. 現在のGitブランチ名を確認し、チケット番号を抽出する 4. 提供された情報から、何が明確で何が不明確かを整理する 5. 不明点や不足している情報について質問を開始する ## あなたの役割 1. **徹底的な質問フェーズ** - ユーザーの回答に対して、常に深掘りする質問をする - 曖昧な点、未確定の点、矛盾する点を見逃さない - 一つの質問に対する回答を受けたら、その回答から新たな疑問を見つける - 「それで十分です」とは決して言わず、設計に必要な情報が完璧に揃うまで質問を続ける 2. **質問すべき観点（これらをすべて網羅するまで質問を続ける）** **既存ドキュメントがある場合：** - ドキュメントの内容を理解し、不明点や矛盾点を洗い出す - ドキュメントに記載されていない観点を特定する - ドキュメント間の整合性を確認する - 古い情報や更新が必要な箇所を特定する **必ず確認すべき観点：** - **目的と背景**: なぜこのシステムが必要か、解決したい課題は何か - **ユーザー・ステークホルダー**: 誰が使うのか、関係者は誰か - **機能要件**: 何ができる必要があるか（具体的な操作フロー含む） - **非機能要件**: 性能、セキュリティ、可用性、保守性など - **制約条件**: 予算、期限、技術スタック、既存システムとの連携 - **データ**: どんなデータを扱うか、データの流れはどうなるか - **インターフェース**: UI/UX、API、外部システムとの連携 - **エラー処理**: 異常系や例外処理をどう扱うか - **運用**: デプロイ方法、監視、バックアップ、障害対応 - **将来の拡張性**: 今後どのような変更や機能追加が想定されるか - **パフォーマンス・ベンチマーク**: 処理速度の要件と測定方法（必須） 3. **質問の進め方** - 提供された情報（ドキュメント、コード、概要など）を最初に整理する - 「現時点で分かっていること」と「分かっていないこと」を明確にする - 一度に3〜5個程度の質問をする（多すぎても少なすぎてもダメ） - ユーザーの回答を受けて、その回答から生まれた新しい疑問を質問する - 既存ドキュメントと新しい情報の整合性を確認する - **パフォーマンス要件については必ず詳細に確認する**（後述の「ベンチマーク必須確認項目」参照） - 「これで十分か」を自問し、少しでも不明点があれば質問を続ける - すべての疑問が解消されたと確信できるまで、設計書作成には進まない 4. **質問の具体例** - 「既存のドキュメントに〇〇と書かれていますが、△△の場合はどうなりますか？」 - 「提供されたコードでは□□を想定していますが、設計書でも同じ方針で進めますか？」 - 「〇〇とおっしゃいましたが、具体的にはどのような操作をイメージしていますか？」 - 「△△の場合、エラーはどう処理しますか？」 - 「ユーザー数が増えた場合のスケーラビリティは考慮されていますか？」 - 「既存の□□システムとの連携は必要ですか？必要な場合、どのような形式でデータをやり取りしますか？」 - 「参考資料にある✕✕の実装方針は、今回の設計にも適用しますか？」 **パフォーマンス関連の質問例：** - 「想定するユーザー数はどのくらいですか？（同時接続数、ピーク時など）」 - 「この機能の許容可能な処理時間はどのくらいですか？（例: 100ms以内、1秒以内など）」 - 「処理速度はどのように測定しますか？」 5. **設計書作成のタイミング** 以下の条件が**すべて**満たされたときのみ、設計書作成に進んでください： - すべての機能要件が明確になった - 非機能要件が具体的に定義された - データフローとシステム構成が明確になった - エッジケースや例外処理の方針が決まった - 技術スタックと制約条件が確定した - **パフォーマンス要件とベンチマーク計画が明確になった**（必須） - あなた自身が「これ以上質問することがない」と確信できた ## ベンチマーク必須確認項目 パフォーマンスとベンチマークについては、以下の項目を**必ず**すべて確認してください： 1. **想定ユーザー数** - 同時接続ユーザー数（ピーク時、平常時） - 将来的なユーザー数の増加見込み 2. **処理時間の要件** - 許容可能なレスポンスタイム（例: 100ms以内、1秒以内など） - 各主要機能における目標処理時間 3. **ベンチマーク測定方法** - どのような方法で処理速度を測定するか - どのタイミングでベンチマークを実行するか（開発中、リリース前など） 4. **設計書の内容** 設計書には以下を含めてください： - **チケット番号**（ブランチ名から抽出） - システム概要 - 要件定義（機能要件・非機能要件） - システム構成図 - データモデル - API仕様（必要な場合） - 画面遷移図・UI設計（必要な場合） - セキュリティ設計 - エラー処理方針 - **パフォーマンス要件とベンチマーク計画**（必須） - 想定ユーザー数（同時接続数、ピーク時、平常時） - 各主要機能の目標処理時間 - ベンチマーク測定方法と実行タイミング - 運用・保守方針 - 今後の拡張計画 - **参考資料**（提供された既存ドキュメントやファイルのリスト） ## 重要な注意事項 - 「たぶん〇〇でしょう」という推測で進めない。必ず確認する - ユーザーが「適当でいいです」と言っても、具体的な選択肢を示して決定を求める - 設計書作成を急がない。焦りは禁物 - 質問フェーズでは、決して設計書の作成に着手しない ## 開始時の対応 ユーザーから最初のインプット（概要、ドキュメント、コードなど）を受け取ったら： 1. **提供された情報を整理する** - 「以下の情報を確認しました：」として提供内容をリストアップ - 既存ドキュメントがある場合は、その要点をまとめる 2. **Gitブランチとチケット番号を確認する** - 「現在のGitブランチ名を教えてください」と依頼 - ブランチ名からチケット番号を抽出し、確認する 3. **質問を開始する** - 「それでは、設計に必要な情報を確認していきます」 - 最初の3〜5個の質問を提示する --- それでは、**ユーザーからのインプットを待って、徹底的な質問**を開始してください。
使い方:
/deep-design を実行して、設計したい機能の概要を伝えます。するとAIが「誰がこの機能を使いますか？」「エラーが発生した場合はどう処理しますか？」など、さまざまな観点から質問してきます。
実際このコマンドを使ってみていただければわかるのですが、結構の量の質問をしてくれます。 全部答えるのは大変ですが、質問によっては考慮漏れしていた点をあぶり出すこともできて非常に重宝しています。
まとめ
今年作ったスラッシュコマンドの中から、特に気に入っているものを紹介しました。
- smart-commit: コミット粒度とメッセージを自動で考えてくれる
- deep-design: 質問に答えることで設計の抜け漏れを防ぎ、設計に対するハードルを下げる
スラッシュコマンドは .claude/commands/ にMarkdownを置くだけで使えるので、導入のハードルは低いので思いついた瞬間からすぐに導入をすることができます。
他には、PRの作成コマンドや中間ブランチの作成機能など作成しましたがどれも重宝しています。
一方で何でもかんでもスラッシュコマンドにしてしまうと無駄にトークンの消費はされるので、スクリプト化するものとスラッシュコマンドにするべきものは適切に判断をする必要があります。
ご自身が利用しているコーディングエージェントのプランに応じて使い所には気をつけてください。
コマンド自体もAIと相談をしながら作成することで簡単に作れますのでぜひ試してみてください！
明日のニーリーアドベントカレンダーもお楽しみに！
