Gitの大規模な制限をCursorがどのように回避したか

Cursorは、AIコードエディタが大規模なコードベースで正常に動作するために、Gitの真のスケーラビリティ問題を解決しなければなりませんでした。彼らが行ったことと、その理由について、シニア開発者にとってなぜ重要なのかを紹介します。

具体的な事例

数百万行に及ぶコードベースを想像してみてください。これは大手テック企業、成熟したオープンソースプロジェクト、または急成長したスタートアップのモノレポで見られるような規模です。Gitの動作が遅くなり始めます。git statusが数秒かかり、日常的な操作がストレスになります。そこにリアルタイムでリポジトリの状態を理解して提案をコンテキスト化する必要のあるAIツール（Cursor）が加わると、問題は深刻になります。

Cursorはまさにこの問題に直面し、The RegisterがGitのスケーラビリティの限界をどのように回避したかを詳しく説明しています。

本質的な問題：GitはAI向けに設計されていない

Gitは2005年にLinus TorvaldsによってLinuxカーネルを管理するために設計されました。これは人間のモデルに基づく大規模なコードベースでした。開発者がコミット、ブランチ、マージを行うというものです。Gitはリポジトリの状態を毎分数十回、数百回読み取り、リアルタイムで提案を生成する必要のあるAIツール向けに設計されていません。

既知のボトルネックは以下の通りです：

• Gitインデックス：.git/indexファイルは、たとえ1つのファイルが変更された場合でも、ステータス操作のたびに完全に再読み込みされます。
• オブジェクトストア：ハッシュによるオブジェクトの取得は、大量かつ繰り返しの読み取りに最適化されていません。
• ファイルシステムフック：WindowsやmacOSでは、ファイルシステムウォッチャーがレイテンシを増加させます。

Cursorが行ったこと：真実のソースとしてのS3、レイテンシ向けのローカルNVMe

The Registerが明らかにしたCursorのアプローチは、2層アーキテクチャに基づいています。クラウドオブジェクトストレージのS3をリポジトリの真実のソースとし、高速NVMe（高性能SSD）上のローカルリポジトリをレイテンシに敏感な操作用として使用します。

具体的には、Cursorはスケーラビリティの限界を抱えるローカルGitリポジトリ上で直接AIを動作させるのではなく、S3に正規のコピーを維持し、高速なレスポンスが求められる操作にはローカルNVMeキャッシュを使用します。2つの層間の同期は、Gitインデックスの完全読み込みを最小限に抑えるように最適化されています。

これはシニア開発者にとっておなじみの問題です。標準的な抽象化はある程度機能しますが、その先に進むと、下層のレベルに降りる必要があります。この場合、Gitの呼び出しを最適化するのではなく、ストレージモデルを完全に再考することです。

なぜこれは誰にとっても重要か

Cursorのソリューションは彼らのツールを超えて影響を与えます：

• モノレポ：規模の大きなモノレポで作業するあらゆるチームがこの問題に直面します。S3 + ローカルNVMeのアーキテクチャは転用可能です。
• Git LFS：大きなバイナリファイルの問題は解決しますが、インデックスのスケーラビリティの問題は解決しません。これはCursorが別の方法で回避したオープンな問題です。
• コードベース上のAIツール：静的解析、AI支援コードレビュー、コード生成などのツールは、成長するにつれてこの問題に直面します。