Claude Codeは最後のコミットを“amend（修正）”することは決してない理由

AIとバージョン管理の問題点

AIエージェントをコードベースに放つとき、最初に気になるのはそのAIがコードを書けるかどうかではありません。問題は、仕事を壊してしまわないかどうかです。

git push --force。git reset --hard。git checkout .。これらのどれもが、何時間もの作業を吹き飛ばす可能性があります。そして「ただ手助けしようとしている」AIは、詰まったときにそれらに手を伸ばしてしまうかもしれません。

Claude Codeのソースを逆解析したあと、面白いことが分かりました。破壊的なgitコマンドを避けるだけではないのです。システムプロンプトには、バージョン管理との関わり方を決める明示的な7つのルールが組み込まれています。これは提案ではありません。モデルがあらゆるやり取りで従わなければならない、強制力のある制約です。

以下がその内容で、AIを使った開発ツールを作る人にとってなぜ重要なのかを説明します。

ルール1：修正（amend）は決してしない — 常に新しいコミットを作る

これが最も意外なものです。プリコミットフックが失敗した場合、自然な本能（人間もAIも）は問題を直して git commit --amend を実行することです。しかしClaude Codeには明示的にこう指示されています：

ユーザーが明確にgit amendを要求しない限り、常に変更するのではなく新しいコミットを作成せよ。

なぜでしょう？フックが失敗したとき、そのコミットはそもそも作成されていないからです。--amendをフック失敗後に実行すると、失敗したコミットをamendしているのではなく、直前のコミットをamendしています。すでに問題なく作られていたはずのコミットです。

これは経験豊富な開発者でも、しょっちゅうやってしまうバグです。そしてAIは「できるだけ早く状況を修正しよう」とするため、まさにそういうミスをより頻繁に起こし得ます。

解決策は簡単です：フック失敗後に問題を修正し、再ステージして、新しいコミットを作成します。Claude Codeはこの動作をデフォルトにしています。

ルール2：Git設定の更新は決してしない

これは絶対です。例外もありません。「ユーザーが求めた場合を除き」といった抜け道もありません。

git configを決して更新しないこと。

Git設定の変更は見えず、永続し、リポジトリ内のあらゆる将来の操作に影響し得ます。AIが黙ってcore.autocrlfやpush.defaultを変更してしまえば、まったく別の文脈で、数週間後に表面化するバグを生む可能性があります。

攻撃対象となり得る領域が広すぎます。触らないのが最善です。

ルール3：破壊的コマンドは明示的な許可が必要

Claude Codeは、危険だと見なすgitコマンドの内部リストを管理しています：

• git push --force
• git reset --hard
• git checkout --（変更を破棄する形式）
• git clean -f
• git branch -D

これらはいずれも、ユーザーがその特定の操作を明確に要求した場合にのみ実行されます。非破壊的な方法が失敗したとしても、AIは破壊的コマンドにエスカレーションしません。

これは重要です。AIエージェントは問題を解決するのが大好きだからです。もしgit mergeでコンフリクトが起きたら、「速い」解決策はgit checkout --theirs .です。これは、あなたの変更をすべて黙って破棄してしまいます。制約のないAIなら、まさにそれをやりかねません。

ルール4：フックをスキップしてはならない

--no-verifyは使わない。--no-gpg-signも使わない。プロジェクトが設定した安全確認を回避してはならない。

プリコミットフックが失敗した場合、Claude Codeはなぜ失敗したのかを調べ、根本の問題を修正します。チェックを飛ばすショートカットは取りません。

これは一見明らかですが、--no-verifyがコードベースのgit履歴にどれだけ登場するか考えてみてください。次に、「都合が悪いときはフックをスキップするのがデフォルト」のようなAIを想像してみてください。

ルール5：mainへのフォースプッシュは遵守ではなく警告になる

仮に、あなたがClaude Codeに明示的にmainまたはmasterへフォースプッシュするよう依頼したとしても、単に従うことはありません。まず警告します。

これは意図的な非対称性です。多くの破壊的操作は、明確に要求されれば実行されます。しかしデフォルトブランチへのフォースプッシュは、チーム全体が影響を受けるため、追加の摩擦がかかります。

ルール6：すべてではなく、特定のファイルだけをステージする

ファイルをステージするときは、git add -A や git add . を使ってまとめて追加するのではなく、名前を指定して特定のファイルを追加することを優先せよ。

なぜでしょう？git add -Aは次のようなものを一緒に拾ってしまうかもしれないからです：

• .env ファイル（秘密情報）
• 認証情報やプライベートキー
• 大きなバイナリファイル
• ビルド成果物

Claude Codeはファイルを個別にステージします。つまり、コミットに実際に含めるべきものをきちんと考える必要があります。これは遅くなる一方で安全です — ステージされた各ファイルは、意図した選択になります。

ルール7：求められていない限りコミットしてはならない

ユーザーが明確にコミットを求めていない限り、変更を決してコミットしてはならない。

変更のたびに自動でコミットしてしまうAIは、「思いついたことをそのまま記録する」ようなgit履歴を作ります。実際の作業を見えにくくする、意味のない小さなコミットが大量に並ぶことになるでしょう。

コミットには明示的な許可を必要とすることで、Claude Codeはコミットが意図されたものであり、範囲が適切で、意味のあるメッセージを持つことを担保します。

パターン：安全性は「期待」ではなく「制約」に符号化する

これらのルールで面白いのは、どれか1つではありません。ほとんどの経験豊富な開発者は、これらのすべてに同意するでしょう。面白いのは、これらが創発的な挙動ではなく明示的な制約として定義されている点です。

AIモデルに「gitを慎重に扱え」と言って、その意味を理解してくれることを期待することもできます。あるいは、git操作が失敗する7つの具体的なパターンを列挙し、それぞれを厳格なルールにしてしまうこともできます。

これは、ガードレールを作るのか、道がまっすぐであることを期待するのか、という違いです。

もしあなたが、AIエージェントにバージョン管理へのアクセスを与えるツールを作っているなら、このアプローチを盗んでください：

1. ツールが実行し得る破壊的操作をすべて列挙する
2. それぞれに、明示的なユーザー意思を要求する
3. 核となるオプション（mainへのフォースプッシュ）には、明示的な意思があっても追加の摩擦を入れる
4. 安全な道をデフォルトにする（amendではなく新しいコミット；すべてではなく特定のファイル）

これは、私の「Claude Code Architecture Deep Dives」シリーズの第7回です。私は本のためにClaude Codeのソースを17,000行以上逆解析している過程で、これらのパターンを見つけました。

さらに深掘りしたいですか？ 第1章を無料で読む — メール不要。この本の全文では、権限システム、コンテキスト管理、ツール基盤などを扱います。

AIエージェント向けに、あなたならどんなgitの安全ルールを追加しますか？見落としている点があればコメントしてください。