Anthropic が Git を置き換えた理由：コード量が人間のレビューを追い越すとき

人間のペースのために作られたツールが、機械のペースと出会うとき

Simon Willison がこの変化を書き記したことに端を発する報道によれば、Anthropic は Git の代替を自社で作り上げた。引き金は不具合でもセキュリティ事故でもなかった。量だった。同社のコードベースに流れ込む変更の速度は急激に上がり、2026年5月までには1期間あたり平均およそ2,500件のリクエストに達していた。従来のバージョン管理が担うようには設計されていなかった負荷だ。

これを社内ツールの話として片付けて先に進むのはたやすい。だがそれは誤りだ。Git はこれまで書かれたソフトウェアの中でも最も影響力の大きいものの一つであり、コードがどう変わるかについてのある前提の上に成り立っている。その前提は今、実際の場面で破られている。

Git が前提としてきたもの

Git の設計には、人間の行動についてのある信念が織り込まれている。変更は人が目で追えるペースで届く。ブランチは、名前を付けるのに十分なほど長く続く意図を表す。履歴は貴重なので、何も捨てない。メンテナーは diff を読み、マージする前に判断を固められる。

エージェントがコードを書くとき、それらの前提はどれもやわらぐ。

エージェントは疲れないので、一日分の単位ではなく、絶え間なく変更を生み出す。何日も意図を保つことはないので、ブランチは名前を付けること自体が手間になるほど短命になる。人間のレビュアーが意味のある形で読み切れる量をはるかに超える diff を生み出すので、Git のワークフロー全体がその周りに組み立てられているレビューの工程は、安全装置からボトルネックへと変わる。

結果として、設計の想定範囲をはるかに超えて動くシステムが出来上がる。それでいて誰もが何も変わっていないと言い張る。リポジトリは相変わらず動く。だがそれを取り巻くプロセスは、かつての意味を持たなくなる。

実際に最初に壊れるのは何か

素朴な懸念はストレージだ。だが蓋を開けてみれば、それは最も小さな問題にすぎない。ディスクは安く、Git の圧縮はよく効く。

最初の本当の犠牲者はレビューだ。エージェントが生成した4,000行の diff を持つプルリクエストは、理屈の上ではレビュー可能で、実際にはできない。レビュアーは人間が過負荷のとき常にそうすることをする。流し読みし、要約を信じ、承認する。レビューは儀式として生き残り、機能を失う。これはレビューを廃止するより悪い。儀式が偽りの自信を生むからだ。

二つ目の犠牲者はアイデンティティだ。Git の履歴は、誰がいつ何を決めたかの記録だ。ほとんどのコミットがプロンプトに反応するモデルによって作られているとき、履歴には依然として名前が並ぶが、その名前はもはや、履歴が存在する理由である問いに答えてくれない。6週間前にエージェントがある方針をなぜ選んだのかを尋ねることはできない。エージェントは覚えていないし、コミットメッセージはその選択をしたのと同じシステムが生成したものだからだ。

三つ目の犠牲者はブランチそのものだ。ブランチを切ることは Git では安いが、人間の注意力の上では高くつく。誰も目を配れない速さでブランチが増えれば、誰も保持していない意図の滞留が生まれる。これはマージコンフリクトとは別種の失敗であり、より見えにくい。

なぜ代替は「速い Git」以上のものなのか

問題がスループットなら、解決策はより速いサーバーのはずだ。Anthropic が新たに何かを作ったという事実は、問題が構造的なものだと示している。

機械のペースの変更に最適化されたバージョン管理システムは、いくつかの具体的な点で見た目が違うはずだ。ほとんどの変更は一時的で、作るのは安く、捨てるのも安いべきだと前提する。diff を成果物ではなく要約として扱い、各変更に機械可読な意図を添えて、エージェントが後からコードを読まずに見つけられるようにする。考古学のためではなく、検索のために作られる。

さらに、Git が答える必要のなかった問いにも答える必要がある。Git は、価値ある成果物はコードの最終状態だと前提する。エージェント主導のワークフローでは、価値ある成果物はしばしば、ある変更を生み出した推論と、それを検証したチェックだ。それらがバージョン管理の外にあるなら、バージョン管理は履歴の半分しか記録していないことになる。

誰も気に留めないが、必要になったときに効いてくる記録

バージョン管理は単なるファイリングシステムではない。課金、コンプライアンス、インシデント対応の土台だ。監査人は誰がいつ何を変えたかを知りたがる。規制産業はレビューを経ても揺るがない記録を求める。セキュリティチームはコミットからタイムラインを再構成する。

それらの問いへの正直な答えが「エージェントが、もう存在しないブランチ上でやったことで、その推論はその後捨てられたコンテキストウィンドウの中にあった」になるなら、記録には穴が開いている。記録の穴こそが監査の見つけ出すために作られているものだし、誰にも気づかれずに穴を生むツールは、スキャンダルになるずっと前に深刻な問題である。

より広いシグナル

この圧力は Anthropic だけが感じているものではない。同じ話の縮小版はすでに他所でも見えている。GitHub は最近、リポジトリの star 履歴 API を作り直し、トレンドデータが約2,500件ではなく24リクエストで返るようにした。無限に広がるデータベース作業も、個々の star したユーザーの公開も必要としない。GitHub はさらに、文脈を考慮するシークレット検出の分類器を出荷し、本物の検出の受理率を11.5パーセント引き上げつつ、スキャン時間の中央値を86パーセント削減した。

どちらも同じ根本的な状況への対応だ。世界のコード量は増えており、人間が唯一の書き手だった時代に作られたツールは老いを見せ始めている。シークレット検出は良い例だ。認証情報の漏洩リスクは書かれるコードの量に比例して大きくなるので、人間の産出量では十分だった仕組みが、エージェントの産出量では不十分になる。設計が何も変わっていなくても。

誰も声に出したがらない部分

この話には、AI がソフトウェアチームの生産性を劇的に高め、ツールが追いつき、誰も困らないという版がある。

もう一つの版では、生成されるコードの量が人間が理解する能力を超え、業界は誰一人として全体を把握できないリポジトリを抱え込む。それを支えるのは誰も書いていないテストと誰も実施していないレビューだ。その版の兆候はクラッシュではない。ゆっくりとした漂流だ。コードベースは動き続け、なぜ動くのかを理解する人の数が減り続ける。

そう見ると、Git を置き換えることは注目に値する症状だ。業界で最も慎重な会社の一つが、標準的なツールがまさに正確性を追跡する層で負債になったと判断したことを意味する。これは小さな告白ではない。ソフトウェアのインフラが、その前提の追いつく速さを超えて変わることを求められているというシグナルだ。

他のすべての人にとっての実務的な対応は、ロマンチックなものではない。コードのどれだけが機械によって書かれたかを測る。レビューの工程がまだ何かを変えているかを見る。履歴がまだなぜに答えられるかに目を配る。これらは安く済む問いであり、答えは、あなたに必要なのが新しいツールなのか、それとも新しい習慣だけなのかを教えてくれる。