はじめに
コミットメッセージ自動生成が動かないとき、まず Git 側の問題を疑いがちです。
しかし実際には、Git の前処理は進んでいても、Copilot 側の生成フェーズで弾かれていることがあります。
今回の調査では、Git の warning から目を逸らさず、どの段階で失敗しているかを切り分けることが重要だと感じました。
この記事では、実際の観測結果をもとに、次の点を順番に整理します。
- Git 側で見える warning の意味
- Copilot 側で見ておくべきログ
- 生成専用のカスタム指示を外して再検証する手順
- 確認できた事実と、まだ断定できない点の分け方
まず確認したいのは、Git 本体が壊れていないこと
最初に確認したのは、Git 実体が使えるかどうかです。
git --version
git rev-parse --is-inside-work-tree
この確認では、Git の実行自体に問題はありませんでした。
また、次のように local user.name と user.email が設定されているかも確認しました。
git config --get --local user.name
git config --get --local user.email
この値が未設定だと、コミットに必要な情報としては不十分です。
ただし今回の本質的な失敗は、ここではありませんでした。
Git の warning は必ずしも障害ではない
VS Code の Git 拡張は、config キーの有無を確認するために何度も読み取りを行います。
そのとき、未定義のキーを参照すると git config --get は終了コード 1 を返します。
たとえば次のような確認です。
git config --get --local core.virtualfilesystem
git config --get --local core.sparsecheckout
git config --get commit.template
この結果は、Git が壊れているというより、未設定のキーを読んでいるだけのことが多いです。
つまり、warning 文字列だけで「Git が原因」と結論づけるのは危険です。
重要なのは、どのフェーズで止まっているかを見ること
今回の事象では、Git の前処理自体は進んでいました。
- repository scan は完了
- diff や log などの前処理は実行された
- Copilot 側で生成用の呼び出しが記録された
その一方で、最終的には次のような状態で失敗しました。
- Server error: 422 Unprocessable Entity
- gitCommitMessageGenerator が promptFiltered
このポイントが本質です。
Git で差分を収集する段階までは進んでいるのに、生成 API 側で弾かれているので、結果としてコミットメッセージが出ません。
Copilot 側で見るべきログ
Git 側の確認だけでは足りません。
Copilot 側で次の情報を確認すると、切り分けがかなり楽になります。
- gitCommitMessageGenerator が呼ばれているか
- 422 / promptFiltered が出ていないか
- 生成専用のカスタム指示が入っていないか
確認場所としては、VS Code の表示メニューから出力パネルを開き、GitHub Copilot や Git 関連の出力を確認するのが基本です。
この操作を通じて、どの段階で処理が止まっているかを確認できます。
次のような見方ができます。
| 観点 | 観測結果 | 判断 |
|---|---|---|
| Git 前処理 | repository scan、diff、log などが実行されていた | Git 側の情報収集は進んでいた |
| Copilot 生成呼び出し | gitCommitMessageGenerator が呼ばれていた | 生成処理自体は開始されていた |
| 最終応答 | 422 / promptFiltered が出ていた | 生成側で失敗していた |
今回の調査では、生成専用のカスタム指示を外したことで改善したため、影響していた可能性はあります。ただし、promptFiltered の詳細な判定理由までは確認できませんでした。
ログを見ることの価値
この事象で一番重要だったのは、ログを見て「どの段階で止まっているか」を確認したことです。
もしログを見なければ、Git の warning を見て「Git が原因だ」と思い込み、無駄な設定変更を続けてしまう可能性があります。
一方で、ログの流れを追えば、次のような見立てができます。
- どのフェーズで処理が進んでいるか
- どこで失敗しているか
- どの設定を減らすと再現しやすいか
トラブルシュートでは、原因を推測する前にログを確認する習慣が重要です。
特に AI 機能のように、前段処理と後段処理が分かれている場合は、ログを見ないと原因の切り分けがかなり難しくなります。
まずは設定を減らして再試行する
切り分けの手順としては、次の順番が実務的です。
- Git の実体と worktree を確認する
- local user.name / user.email を確認する
- staged diff があるか確認する
- Copilot ログに gitCommitMessageGenerator があるか確認する
- 生成専用カスタム指示を一時的に外す
- Reload Window 後に再試行する
この手順を踏むことで、問題の場所をかなり絞り込めます。
まとめ
コミットメッセージ自動生成が効かないときは、まず Git の warning を見て「原因は Git だ」と決めつけないほうがよいです。
今回のポイントは、次の 2 点です。
- Git warning は必ずしも障害ではない
- 今回の事象では、失敗箇所は Git の前処理ではなく、Copilot の生成フェーズでした
また、確認できた事実と、まだ断定できない点を分けておくことも大切です。
- 確認できた事実: Git の前処理は進み、生成リクエストは呼ばれたが、最終的に 422 / promptFiltered で失敗した
- まだ断定できない点: 生成専用のカスタム指示が原因だったかどうか
特に、生成専用のカスタム指示を外して最小構成に戻すと、原因の切り分けがかなり早くなります。
もし再発したら、まずは Git の基本確認、次に Copilot のログ確認、最後に設定を最小化して再試行する、という順番で進めるとよいです。