前回のDay 18では、世界標準のブランチ命名規則とチケット連携フォーマットをマスターしましたね。
さて、本日のテーマは、チーム開発の信頼性を決定づける最も重要な作法、「プロのコミットメッセージ・プッシュ作法（Conventional Commits）」です！
ITエンジニア歴30年以上の皆さん、Subversion (SVN) や Visual SourceSafe (VSS) で開発していた当時、コミットログに「修正」「更新」「完了」「20261017作業」といった一言だけを書いて終わらせていませんでしたか？
集中型SVNではコミットログが多少雑でも、フォルダ単位の最新状態さえ動いていれば何とかなっていたかもしれません。
しかし、GitとGitHubを基盤とする現代のチーム開発では、コミットメッセージは「未来の自分や仲間へ送る設計意図の手紙」であり、「CI/CDによるリリースノート自動生成の入力データ」そのものです。
もし「修正」としか書かれていないコミットにバグが混入していたら、
git blame や git bisect で調査しても「なぜこのコードを追加したのか（Why）」が全く分からず、誰も修正できなくなってしまいます。本日は、世界共通の規約である『Conventional Commits』の基本型から、プロが実践する『黄金3段構成（要約・空行・Why本文）』、C#現場でのバグ修正Before/After、そしてCopilotやClaudeを使ったAI自動生成テクニックまで余すところなく解説します！
① 導入・本日の達成目標
「コミットメッセージなんて、自分が後でなんとなく思い出せればいい」——もしそう思っているなら、今すぐその意識を変える必要があります。
コードの差分（git diff）を見れば、「どこを変更したか（What）」は誰でも分かります。
しかし、「なぜその変更が必要だったのか」「なぜ他の手段ではなくこの実装を選んだのか」（Why）は、コミットメッセージにしか残すことができません。
- 「修正」「バグ直した」がもたらす技術的負債と、メッセージ品質の重要性を理解する
- 世界標準規約「Conventional Commits」の主要プレフィックス（feat, fix, refactor等）を完全習得する
- 1行目要約・2行目空行・3行目Why本文からなる「黄金3段構成」をマスターする
- C#現場での実例を学び、GitHub CopilotやClaude等のAIに規約コミットを自動生成させる
② 【図解】ダメなコミット履歴 vs プロのコミット履歴
まずは、中身のない一言コミットが並ぶ「無法地帯」と、Conventional Commitsで構造化された「プロのコミット履歴」の違いを図解で対比してみましょう。
一言コミットが現場にもたらす「3大悲劇」
- アンタッチャブルコードの誕生:
git blameで問題のコード行を調べたとき、コミットログが「修正」だと、なぜその条件分岐が追加されたのか（仕様なのか、暫定回避なのか）が分からず、誰も怖くて触れなくなります。 - プルリクエスト（PR）レビューの長期化: コミット単位の意図が伝わらないため、レビュアーは膨大なコード差分を頭から全て読み解く必要があり、レビュー待ち時間が何日も発生します。
- 自動リリースノート生成の破綻: 現代のGitHub Actionsでは、コミットログから「v1.2.0 新機能一覧」「バグ修正一覧」を自動生成するツール（semantic-release等）が標準です。メッセージが適当だと、リリースノートを手作業で書く羽目になります。
③ 【現場のデファクト】Conventional Commits 主要プレフィックス
世界中のOSSプロジェクトや有力IT企業で広く採用されているコミット規約が「Conventional Commits」です。
基本構文は非常にシンプルで、以下のフォーマットに従って記述します：
絶対に覚えるべき主要プレフィックス型一覧
| プレフィックス (Type) | 変更内容・用途 | SemVer連動 | 具体例 |
|---|---|---|---|
| feat: | 新しい機能やAPI・画面の追加 | MINOR (0.X.0) | feat(auth): JWT自動更新APIを追加 |
| fix: | 不具合・バグの修正 | PATCH (0.0.X) | fix(user): ページング境界値例外を修正 |
| refactor: | 振る舞いを変えないコード整理・構造改善 | なし | refactor(db): DbContextをDI注入に移行 |
| perf: | パフォーマンス向上（実行速度・省メモリ） | PATCH (0.0.X) | perf(linq): 非同期ストリーミング化 |
| chore: | ビルド設定、パッケージ更新、雑務 | なし | chore(deps): EF Core 8.0.3に更新 |
| docs: | ドキュメントのみの追加・修正 | なし | docs(api): Swaggerの説明文を更新 |
| test: | 単体テスト・統合テストの追加や修正 | なし | test(auth): トークン失効テスト追加 |
| style: | 空白、フォーマット、セミコロン等の修正 | なし | style: dotnet format による整形 |
④ 【黄金3段構成】要約・空行・本文（Why）とC#開発の実践例
型プレフィックスが決まったら、次はメッセージ全体の「構造」です。
Gitの設計思想に基づいた世界標準の書き方が、以下の「黄金3段構成」です：
← 2行目: 【超重要】必ず空行を入れる！
リフレッシュトークンがAPIからnullで返却された場合に、
UserService.cs 内の HandleCallback メソッドで NullReferenceException が
発生し、Webアプリが異常終了する不具合を修正しました。
null安全演算子(?.)の導入と、安全な再認証フローを追加しています。
Closes #102 ← フッター: チケット連携（PRマージで自動クローズ）
なぜ「2行目の空行」が絶対に外せないのか？
Gitでは、ターミナルで git log --oneline を実行した際や、GitHubのコミット一覧画面で、「1行目の文字列だけを要約タイトルとして抽出して表示する」という仕様になっています。
もし2行目に空行を空けずに本文を続けて書いてしまうと、Gitは「どこまでがタイトルか」を判別できず、本文全体が1行に押し込められて画面表示が著しく崩壊してしまいます。
「1行目と3行目の間には必ず空行を挟む」——これはGitを扱うすべてのエンジニアが守るべき鉄則です。
⑤ 【AI時代の開発作法】AIを活用したプロ仕様コミット自動生成
「毎回Conventional Commitsを考えて書くのは面倒くさい…」——そう感じる方も多いでしょう。
現代の開発現場では、「コード差分（git diff）をAIに読み込ませて、規約に沿ったコミットメッセージを自動生成させる」のが標準的なワークフローになっています。
コピペで使える！AI指示プロンプトテンプレート
以下の git diff （変更差分）を分析し、Conventional Commits 規約に従った
プロ仕様のコミットメッセージを日本語で作成してください。
# 満たすべき要件
1. 1行目:
<type>(<scope>): <50字以内の要約タイトル>2. 2行目: 必ず空行
3. 3行目以降: なぜこの変更を行ったのか（Why・背景）、影響範囲を箇条書きで記述
4. チケット連携: Closes #102
# 差分データ (git diff)
(ここに git diff の出力を貼り付け)
Claude Code、GitHub Copilot CLI、Google AntigravityなどのAIエージェントにこのプロンプトを投げるだけで、人間が考えるよりも正確で美しいコミットメッセージが数秒で完成します！
⑥ 📌 本日のまとめ・理解したい最重要ポイント
第19回の講義、お疲れ様でした！ プロのコミットメッセージ・プッシュ作法の最重要ポイントを総復習しましょう。
- 「修正」「バグ直した」だけの一言コメントは絶対撲滅！: コード差分でWhat（何をしたか）は見えても、Why（なぜそうしたか）はメッセージにしか残せない。
- Conventional Commitsの主要プレフィックス型を活用:
feat:(新機能)、fix:(バグ修正)、refactor:(構造改善)、chore:(雑務)、docs:(文書)、test:(テスト)。 - 黄金3段構成の徹底: 1行目要約タイトル（50字以内）、2行目空行（git log --oneline対策）、3行目Why本文、末尾チケット連携（Closes #Issue）。
- AIによる自動生成で時短と品質を両立: git diff をAIに渡して規約コミットを出力させ、人間が最終確認してスマートにコミットする。
コメント
コメントを投稿