Gitの履歴は、選んだ道しか記録しない

seekseep氏は、Simon Willisonのガイドを紹介しながら、コーディングエージェントとGitを組み合わせるパターンを整理している。新しいセッションを始めるとき、「直近のコミットを見て」とエージェントに頼めばgit logでコンテキストを読み込ませ、前回までの進捗を出発点にできる。氏はこの気づきを「読みやすい履歴は人間だけでなくエージェントにとっても価値がある」とまとめている(出典)。

コンフリクト解消やコード復元、git bisectでの調査といった、人間が詰まりやすい場面ほどエージェントに任せる価値がある、という判断軸も紹介されている。ただし氏自身、「エージェントに任せる範囲と、自分で確認する範囲の線引きは、これから使いながら見つけていきたい」と結んでおり、実践はまだ途上にあることを隠していない。

良い履歴を書けば済む、と考えかけた

「エージェントが読む前提でGit履歴を書く」という発想を素直に受け取ると、コミットメッセージを丁寧に書くことさえ徹底すれば、PRレビューツールParryが担っているWhy(なぜこの変更か)の役割は、git logの中にすでに書き込めるはずだという考えに行き着く。わざわざ別のフォームに同じ情報を書かせる必要はないのではないか、という仮説だ。

自社のコミット履歴に、答えがすでにあった

このリポジトリのコミット履歴を遡ると、「CI失敗したので再度チャレンジ」という一行だけのメッセージが残っている(132167c)。差分を見ると、1つの記事ファイルの見出しをわずかに書き換えただけの小さな変更だ。だが、このメッセージからは、CIの何が失敗したのか、修正のためにどんな選択肢を検討し、なぜこの一行の書き換えで直ると判断したのかは、何一つ読み取れない。再挑戦したという事実だけが記録され、最初の試みで何を避けたのかは記録されていない。

これは書き手の怠慢というより、コミットという仕組みそのものの性質だ。コミットは選んだ結果の状態を記録する。選ばなかった状態は、どこにも差分として残らない。よほど意識して書かない限り、「なぜXではなくYにしたか」という情報は、メッセージという自由記述の余白にしか居場所がなく、その余白は大抵、結果を一言で説明するためだけに使われて終わる。

良い履歴を書く、では解決しない理由

この非対称性を「もっと丁寧にコミットメッセージを書く」という運用でカバーしようとすると、以前別の記事で指摘した「散文で交わした約束は、壊れてもエラーにならない」という問題を、そのまま輸入することになる。書式をルールとして決めても、忙しいときには誰も守らず、守られていないことに気づく仕組みもない。git logを読むエージェントにとって、ある日突然理由が書かれなくなったコミットは、エラーにはならず、ただ静かに情報量が減るだけだ。

Parryが却下理由(rejectedAlternatives)を四軸の中に独立した項目として持たせているのは、この非対称性への対処だと言える。選ばなかった道を書く場所を、選んだ結果を書く場所とは別に、必須項目として用意しておけば、その欄が空欄のまま提出されたことは目に見える。散文の余白に埋もれて消えるのと、必須欄が空いたまま残るのとでは、気づけるかどうかが違う。

エージェント自身がその欄を読みに行けるかは、まだ分からない

seekseep氏が紹介するパターンは、エージェントがgit logを通じてコンテキストを読み込むという、Git標準の経路だけを前提にしている。Parryの却下理由がPRデータとして蓄積されているとして、新しいセッションを始めたコーディングエージェントが、git logを読むのと同じ手軽さでその履歴にもアクセスできるのかどうかは、この記事の材料だけでは確認できない。選ばなかった道を記録する場所を作ったことと、その記録を次にコードを書くエージェント自身が実際に読みに行けることの間には、まだ埋まっていない距離があるかもしれない。