今回やったこと
Cursorにはカスタムコマンドの仕組みがあります。
※2026年1月現在、この機能はまだベータ版らしいので色々と変更になる可能性あり
.cursorのcommandsディレクトリに、自分が作ったプロンプトをマークダウンファイル形式で置くと、カスタムコマンドでそのプロンプトを呼び出すことができます。
.cursor
└── commands
└── create-commit-message.md
今回はこのカスタムコマンドの仕組みを使って
コミットメッセージを特定の形式と複数のルールで作成してくれるコマンドを作りました。
コミットまでの流れ
以下コミットメッセージができるまでの流れとなります。
① 作成したカスタムコマンド/create-commit-messageをチャットに打つ
※commandsディレクトリにcreate-commit-message.mdというマークダウンファイルを置いた場合
② 修正した内容をAIが解析して「変更内容の概要」と「コミットメッセージ案」が返信される
Summary:
- 認証フォームの入力検証とエラー表示を見直し、想定外の入力でもログイン処理が落ちずユーザーに適切なメッセージが出るようにしました。
- トークン発行ロジックの例外処理を整理し、失敗時もセッションが破棄されるようにしました。
- ローカルでログインフロー（正常・異常系）の動作確認を実施済みです。
Commit Message Proposal:
[認証] エラーハンドリングを改善するためログイン画面の検証とトークン処理を実装 #1
Need Approval:
このコミットメッセージでコミットしてもよろしいでしょうか？
③ 内容を確認してよければ「OK。それでコミットして」でコミットまで完了
④ あとは手動でpushしたりrevertしたり（pushまでは何か不備があると怖いのでAIにやらせません）
前提
- Cursorのバージョンを1.5以上にすること
- GitHub CLIをインストールしておくこと
これがないとAIがコミットなどのGitHub操作を実行できません
create-commit-message.mdの中身
# github-commit-message
## 目的
- 現在の変更内容に対するコミットメッセージ案を生成し、ユーザー承認を得てからコミットする。
- コミットメッセージは「[機能名] XXXXXX #{ticket_no}」の形式に従い、なぜその実装/修正が必要だったかを明確に伝える。
## 前提
- `ticket_no` はブランチ名や会話から得られる最新のチケット番号を使用する。
- ブランチ名のパターン例:
- `feature/123-login-improvement` → #123
- `bugfix/456-validation-error` → #456
- `refactor/789-code-cleanup` → #789
- チケット番号がブランチ名に含まれない場合、または取得できない場合は、ユーザーに確認する。
- `[機能名]` には変更の分類または画面名を日本語で記述する。
- 例: `[認証]`, `[プロジェクト管理]`, `[ダッシュボード]`, `[バグ修正]`, `[リファクタリング]`, `[バックエンド]`, `[テスト]`, `[パフォーマンス]` など
- 画面に関する変更の場合は、具体的な画面名（例: `[ログイン画面]`, `[ホーム画面]`）を使用する
- `XXXXXX` には実装の概要を「〜のため〜を実装」の構成で簡潔に記述する（日本語）。
- 理由（〜のため）と実装内容（〜を実装/〜を修正）を1行でまとめる。
- 「なぜそのような実装/修正をしたのか」は、これまでの会話や仕様から推測し、コードから読み取れない背景を補足する。
## 要件
1. 変更内容を要約
- 影響ファイル/機能、実装理由、テスト状況を箇条書きで整理する。
- 理由はこれまでの会話から推測し、背景を簡潔にまとめる。
2. コミットメッセージ案の構成
- フォーマット: `[機能名] XXXXXX #{ticket_no}`
- コミットメッセージは日本語で記述する。
- `XXXXXX` 部分は必ず「〜のため〜を実装」の構成で、理由（〜のため）と実装内容（〜を実装/〜を修正）を1行でまとめる。
**コミットメッセージ例:**
- `[認証] ログイン時のセッション管理を強化するためJWT検証ロジックを実装 #123`
- `[バグ修正] 日付バリデーションエラーを解消するため入力チェックロジックを修正 #456`
- `[プロジェクト管理] ダッシュボードの視認性を向上させるためレイアウトを改善 #789`
- `[リファクタリング] コードの保守性を高めるためバリデーションロジックを共通化 #101`
3. 承認プロセス
- 生成したコミットメッセージ案と背景要約をユーザーに提示し、「このコミットメッセージでよいか」を必ず確認する。
- ユーザーの承認が無い限り `git commit` を実行してはならない。
- ユーザーから修正指示があった場合は、指示内容を反映して再提案し、再度承認を得る。
- 承認されたら、提示したメッセージをそのまま使用してコミットし、結果を報告する。
- コミット実行後であっても、ユーザー指示があるまで `git push` は絶対に行わない。
4. 出力
- コマンド実行時には以下を1セットで提示する。
- `Summary`: 影響範囲と実装内容
- `Commit Message Proposal`: 上記フォーマットのメッセージ
- `Need Approval`: 「このメッセージでコミットしてよいか」を明示的に質問
- ユーザーから承認または修正指示があるまでコミットを行わない。
5. エラー対応
- `git commit` が失敗した場合は、エラー内容をユーザーに報告し、対応方法を提案する。
- ステージングされていないファイルがある場合は、ステージング状況を確認・報告する。
- コンフリクトやその他の問題がある場合は、問題の詳細と解決方法を提示する。
プロンプト作成時のポイント
プロンプトを作りながら改善サイクルを回す中で、いくつか大事そうだなと思ったポイントがあるので共有します。
モデルはGPT系ではなくClaude系を使うこと
今回のプロンプトはClaude Sonnet 4.5くんに作ってもらいました。
日本語の使い方や言葉の表現が圧倒的にGPTよりもClaudeが優秀だし親切と感じました。
個人的にドキュメント系の作成はClaude一択です。
しつこいくらい具体例を入れること
「〜してください」みたいな文章の下には必ず具体例を入れること。
- フォーマット: `[機能名] XXXXXX #{ticket_no}`
- コミットメッセージは日本語で記述する。
- `XXXXXX` 部分は必ず「〜のため〜を実装」の構成で、理由（〜のため）と実装内容（〜を実装/〜を修正）を1行でまとめる。
**コミットメッセージ例:**
- `[認証] ログイン時のセッション管理を強化するためJWT検証ロジックを実装 #123`
- `[バグ修正] 日付バリデーションエラーを解消するため入力チェックロジックを修正 #456`
- `[プロジェクト管理] ダッシュボードの視認性を向上させるためレイアウトを改善 #789`
- `[リファクタリング] コードの保守性を高めるためバリデーションロジックを共通化 #101`
ユーザーへの「確認」と「承認」は定期的に入れること
AIを信用してはならない。人間は監督役となること。
- 生成したコミットメッセージ案と背景要約をユーザーに提示し、「このコミットメッセージでよいか」を必ず確認する。
児童に教えるかの如く親切なプロセスを記載する
ここが一番プロンプトを作るにあたって気を遣いました。
少しでもやって欲しいことのプロセスに記載漏れがあると途端に変なことをし始めます。
僕らにとっての当たり前はAIにとっては当たり前ではないという前提で記述することが大事ですね。
1. 玄関のドアをドアノブを捻って開けてください
2. 玄関のたたきで靴を脱いでください
3. 靴を脱いだら家の中に入り、靴をつま先が玄関方向になるように揃えてください
最後に
今回は「コミットメッセージを作る」という小さなタスクのためのプロンプトを作りました。
今後もっと大きなタスクをカスタムコマンドとプロンプトを通じてAIに任せられれば、より良いエンジニアライフに繋がるのではないかと考えています。
例えばエンジニアとしての知識や経験、はたまた企業として蓄積したスキルなどもプロンプトとしてうまく表現できれば、新たな企業価値やエンジニアとしての価値に直結してきそうだなと思いました。