人間のために作られたGitを、エージェント時代に合わせて作り直す

エージェント向けにソースコード管理を作り直す動きが、業界全体で一気に加速しています。GitLabの答えはGitLab Transcendですでにお見せしました。ただし、Gitのバックエンドを作り直すだけでは問題の半分しか解けません。その理由をあらためて整理します。

エージェントがGitサーバーの主役になると、3つの部分が壊れます。数百のエージェントを動かすデベロッパーは、使っているツールに関係なく同じ壁に突き当たります。

• クローンのコスト。 エージェントはたった1つのファイルを読むためにリポジトリ全体をクローンし、次のエージェントも、リトライのたびにも同じことを繰り返します。タスクに必要な量をはるかに超えるデータが転送され、本来なら不要だったローカルのgrepやblameにコンテキストを消費してしまいます。今日では、1つの問いに答えるためのエージェント呼び出し1回で、5GB〜10GBの転送と30秒以上のセットアップが発生することもあります。
• 並行処理の破綻。 数千のセッションが、もともと人間のスケールを前提に設計されたバックエンドに押し寄せ、ボトルネックと予測不能な可用性を生み出します。
• 分離の欠如。 エージェントはアカウントとブランチ空間を共有するため、リポジトリを圧迫し、放棄された作業をきれいに捨てる手段もなく、どのエージェントが何をしたかの記録も残りません。

当社のプラットフォームデータは、この圧力がどれほどの速さで高まっているかを示しています。この1年でお客様が作成したCI/CDパイプラインは40%増加し、GitLab.comへのコードプッシュは50%増加しました。セキュアなリポジトリが60%増加する一方で、コードベースの規模は最大500%も拡大しています。

6月のGitLab Transcendで次世代ソースコード管理（次世代SCM）を発表した際、運用モデルとしてのGitがエージェントのかける負荷を想定して設計されていない点を詳しく説明しました。それから数週間のうちに、エージェント規模の並行処理に特化したGitホストをはじめとする新規参入企業が現れ、この主張を独立した立場から裏づけています。この一致は、Gitのバックエンドを作り直す必要性をより鮮明にするもの。ただし、それだけではまだ十分ではありません。

エージェント規模に向けて構築しているもの

次世代SCMは後方互換性のためにGitプロトコル上で動作し、バックエンドとインターフェイスはエージェント向けに再設計されています。エージェントはワークツリー全体をクローンする代わりに、タスクに必要なものだけをサーバーサイドでリポジトリに問い合わせます。各エージェントに与えられる可視範囲も、そのタスクに必要な最小限に限定。Gitとの互換性と可監査性はそのままに、内側のエンジンだけを載せ替えた形です。

アーキテクチャは、インテリジェンス層（ルーティング、キャッシュ、バックグラウンド処理）と、オンデマンドでスケールするエラスティックなコンピュート、そしてエラスティックなオブジェクトストレージを分離しています。専用の読み取りAPIと書き込みAPIが用意されており、リポジトリ全体を取得せずにファイル、blame、履歴のデータを参照し、変更をコミット可能。デベロッパーはどのリポジトリでもエージェントを動かし、数千規模にファンアウトさせ、安全に試行錯誤させられます。具体的には、フルクローンの代わりに1回のバッチ読み取り、クローンしてからdiffを取る代わりにdiff-statのリクエスト、クローンしてからblameする代わりにパス単位の最終コミット参照、という形になります。

これはクラウド専用の設計ではありません。コンピュート層とストレージ層は標準のS3 APIで通信するため、GitLab.comで動くものと同じアーキテクチャが、お客様自身のインフラストラクチャでも動作します。大手クラウドプロバイダーのオブジェクトストレージでも、お客様のデータセンターで稼働するS3互換のセルフホスト環境でも同様。エアギャップ環境、規制産業、データ主権の制約がある環境であれば、リポジトリデータがお客様の管理下にあるインフラストラクチャから一切出ることなく、同じ水平スケーリングと整合性の保証が得られます。

社内での初期テストでは、次世代SCM上で動作するエージェントについて次の結果が得られました。

• 実行時間（wall-clock time）が最大50倍高速
• トークン消費が最大2分の1
• ネットワークトラフィックが最大1,000分の1

これらは当社のテスト条件下で測定した上限値であり、保証された数値ではありません。エージェント規模でGitバックエンドに実際に負荷をかけるワークロードとは、多数の独立したエージェントが同じリポジトリに対して並行して読み書きを続け、その状態が負荷のもとで持続するというもの。したがって、ある数値に意味があるといえるのは、テストがその状態に近い条件で実行され、負荷生成側がボトルネックになっておらず、単一の最良値ではなくレイテンシーの分布全体が報告されている場合に限られます。

当社は自社の結果にもこの基準を課しています。この分野を評価される方には、当社の数値を含め、提示されたあらゆる数値に対して同じ3つの問いを投げかけることをおすすめします。そしてこの基準は、テスト条件だけの話ではなく、アーキテクチャそのものに組み込まれたもの。ストレージのメンテナンスでは、小さなアーティファクトを等比的なスケジュールでより大きな凍結済みアーティファクトへと圧縮（コンパクション）します。その結果、あるノードが最新のスナップショットに追いつくために取得しなければならないデータ量には、明確な上限がかかる仕組み。フリーズしきい値が1GB、コンパクション比が2倍であれば、リポジトリがどれだけ大きくなってもその上限は2GBです。

次世代ソースコード管理は現在プライベートベータとして提供中です。実際の動作は以下の動画でご覧ください。

バックエンドの作り直しは問題の半分にすぎない

新規参入企業が作っているのはGitホストです。単体で完結する移行先か、既存ホストの前段に置いて読み取りトラフィックを吸収する高速ミラーか、そのどちらか。これは並行処理の問題を解決しますし、並行処理は確かに現実の課題です。しかし、2つの問いは未解決のまま残ります。そのどちらも、GitLabがエージェント型インフラストラクチャをどう捉えるかの中心にある論点。

1つ目は来歴（プロベナンス）です。 エージェントが数百単位でコードをプッシュし、依存関係に触れ、デプロイをトリガーするようになると、問うべきことは「スキャンしたか」ではなく「どのエージェントが、どのポリシーのもとで何をしたのか、そしてそれを証明できるのか」へと変わります。当社のエージェントAPIは、すべてのエージェント動作を特定のワークフロー、モデル、トークンに紐づけて記録します。エージェントの操作はすべて、人間のコントリビューターをすでに統制しているのと同じプロジェクト認証と、ロール単位のヒューマンインザループ制御を経由する仕組みです。帰属とポリシーはリポジトリの機能ではなくプラットフォームの性質であり、単体のGitホストがこれをネイティブに答えられるようには作られていません。

2つ目は、うまくいった作業がその後どうなるかです。 エージェントによる実験が成功しても、単体のホスト上ではそこで完結してしまいます。GitLabの場合、次世代SCMはCI、ポリシー管理、ガバナンス制御、そして生成されたコードの監査をすでに備えたプラットフォームの内側にあるGitバックエンドです。エージェントの一時的な実験がうまくいけば、別のプラットフォームや別の移行先を用意しなくても、そのまま統制と可観測性の効いた本番パイプラインへと昇格します。

次世代SCMが担うのは、エージェント規模での実行です。GitLab Orbitは、ソフトウェアライフサイクル全体のコンテキストをナレッジグラフとして、すべてのエージェントと人間に届ける仕組み。そしてGitLab Duo Agent Platformが、エージェントのあらゆる動作の周囲でガバナンスとセキュリティをオーケストレーションします。これにより、エージェントはGit操作だけにとどまらず、ライフサイクル全体にまたがる作業を計画し、遂行できるようになります。高速なGitバックエンドは、エージェントが生成したコードを預かる場所にすぎません。そこにGitLabのガバナンス、ライフサイクルのコンテキスト、オーケストレーションが組み合わさることで、そのコードはプラットフォーム上の他のすべてと同じCI、ポリシー、監査の経路を通って出荷されます。

この壁には、すべての企業が突き当たる

すべてのお客様がコーディングにエージェントを使うようになります。そして大規模に運用するお客様は、標準として採用するモデルやツールに関係なく、ここまで述べた同じ限界に直面するはずです。だからこそ、これはインフラストラクチャ層の内側で起きる進化。エージェント時代に最も速く動けるのは、エージェントの出力をホストし、統制し、信頼できるソフトウェアを届けるためにすでに作られていたライフサイクルへ取り込める組織です。

はじめましょう

次世代ソースコード管理はプライベートベータとして提供中です。今すぐ早期アクセスをお申し込みください