エージェント型ソフトウェアファクトリーに向けてGitをスケールさせる

AIエージェントの登場で、ソフトウェア開発の経済性が根本から変わり始めています。コードを生み出すコストが下がるほど、ソフトウェアファクトリーを流れる変更の量は増えていく一方。人間のデベロッパーを前提に設計されたインフラストラクチャが想定していた水準を、すでに超えつつあります。

GitLabはこの変化を早くから見据え、次世代のソースコード管理（SCM）の開発に着手しました。大規模なリポジトリに数千のエージェントが同時に向かう状況を、正面から支えるための基盤づくりです。6月のGitLab Transcendでは、Anthropicのソースコントロールチームに所属するNick G.氏を壇上に迎えて次世代SCMを発表。その後もエージェント規模の開発が抱える技術的な課題について協業を重ね、8月にはアーキテクチャと初期の性能測定結果を詳しくお伝えしました。

この取り組みがなぜ重要なのか。今週Anthropicが公開した内容が、その答えを説得力をもって示しています。同社のモノレポへの1日あたりのマージは、5月の約2,500件から9月には30,000件超へ。この伸びに対応するため、エンジニアが自社の環境に合わせた専用のソースコントロールシステム、Scionを開発しました。

Anthropicの経験は、GitLabが追求してきたアーキテクチャの方向性を裏づけるものです。ただしScionが想定しているのは、クライアントのほぼすべてが常時オンラインのエージェントであるような巨大なモノレポ。その環境に向けた専用設計です。Anthropic自身も、このアプローチがGitの汎用的な代替ではないこと、そしてコードレビューや検索、CIのインフラストラクチャを独自にそろえる必要があることを認めています。

GitLabが見据えているのは、より広いエンタープライズ市場です。Gitとの互換性も、インフラストラクチャを選べることも、ソフトウェア開発ライフサイクルとのつながりも手放さずに、エージェント規模の性能を実現すること。そこを目指しています。

「モノレポをエージェント型開発に耐えるようスケールさせる過程で、Gitサーバーのアーキテクチャに対する私たちの考え方は変わりました。Gitのモデルそのものから離れなくても、こうしたワークロードに向けてGitサーバーができることには、まだ広げる余地があると見ています」

— Nick G.氏、Source Control、Anthropic

土台はGit、設計はエージェントのために

従来のGitのワークフローが前提としているのは、エージェントが必要としているのがごく一部のファイルであっても、クライアントが大量のリポジトリデータを丸ごとダウンロードすること。1つの問いに答えるためだけに、1回のエージェント呼び出しで5GB〜10GBの転送と30秒以上のセットアップが発生することも珍しくありません。これが数千のエージェント分だけ積み重なれば、ソースコード管理そのものがボトルネックに変わります。

スケールのためだけにソースコード管理を新しいインフラストラクチャへ移すという選択は、多くの企業にとって現実的ではありません。 次世代SCMが取るのは、Gitプロトコルはそのままに、その下のアーキテクチャだけを刷新するアプローチ。ステートレスなコンピュートが共有オブジェクトストレージに対して水平にスケールし、エージェント向けに設計されたインターフェイスを通じて、エージェントはリポジトリ全体を何度もクローンすることなく、必要なファイルと履歴だけを取り寄せられます。

社内での初期テストでは、従来のワークフローと比べてワークロードの完了が最大50倍速くなり、トークン消費は最大2分の1、ネットワークトラフィックは最大1,000分の1まで減りました。いずれも特定のテスト条件下で測定した上限値であり、持続的な並行負荷のもとでの検証は現在も続けています。

このアーキテクチャは、GitLab.comでも、お客様が管理するS3互換ストレージでも、そしてエアギャップ環境のデータセンターでも同じように動作するよう設計されています。リポジトリデータがお客様のインフラストラクチャの外に出ることはないため、データ主権と既存の投資を守りながら、エージェント型開発が求めるスケーラビリティを手にできます。

アーキテクチャと開発中の内容をもう少し詳しく知りたい方は、MarkとKranthiによる次世代SCMの最新アップデートをご覧ください。

ソースコード管理は最初のボトルネックにすぎない

ソースコード管理だけを速くしても、ボトルネックは下流へ移るだけです。数秒でコードを書き上げるエージェントがいても、その変更が検証やセキュリティレビュー、デプロイを何時間も待たされるのであれば、生まれる価値はごくわずかにとどまります。

検証が追いつかない速度でエージェントが変更を生み出すようになれば、従来のマージキューとCIのワークフローには圧力がかかり続けます。同じ傾向はGitLab.com全体にも表れており、この1年でお客様が作成したCI/CDパイプラインは40%増加、コードプッシュは50%増加しました。エージェント規模のCIに求められるのは、1件あたりの計算資源を抑えながらより多くの変更を検証し、何をテストして何を確かめたのかという証跡を残すこと。

だからこそ次世代SCMは、統制されたソフトウェアファクトリーというGitLabの大きな構想の一部に位置づけられています。エージェントがソフトウェアの生産を加速させるなかでは、ソースコード管理、コンテキスト、オーケストレーション、CI、セキュリティ、ガバナンスが足並みをそろえて進化しなければなりません。

次世代SCMでは、数千のエージェントが隔離されたセッションの中で並行して作業できる設計を進めています。うまくいかなかった実験は、共有コードに影響を与えることなく捨てられる仕組み。そして成功した変更は、GitLabの既存のマージリクエスト、パイプライン、セキュリティチェック、ガバナンス制御を順に通りながら、本番環境へ向かいます。

GitLab Orbitは、ソフトウェアライフサイクル全体のコンテキストグラフを届ける仕組みとして開発が進行中。GitLab Duo Agent Platformは、各ステージをまたいでエージェントの作業をオーケストレーションします。あわせて、エージェントに自らの仕事への説明責任を持たせる機能の開発も進めています。エージェントの動作の帰属と認可、コード変更の背後にある指示と判断の保存、そしてレビュアーが人間ならではの判断を本当に必要な箇所へ集中できるようにするためのコンテキスト提供。こうした要素がそこに含まれます。

目指しているのは、エージェントと変更の数が劇的に増えていくなかでも、構想から本番環境へソフトウェアを届けるまでの時間と総コストを抑えることです。

エージェント型開発にとって最も優れた経済性をもたらすのは、統制されたソフトウェアファクトリーだとGitLabは考えています。1件あたりのコストを抑えながらより多くのソフトウェアを提供し、同時に企業が求めるセキュリティと統制も満たす形です。

オープンな協働でGitを前へ進める

Gitのオープンなエコシステムは、現代のソフトウェア開発を支えてきた土台そのもの。エージェントの時代になっても、その重要性が揺らぐことはないと考えています。GitLabは長年にわたりGitへコントリビューションを続けてきた立場から、数百万のデベロッパーとツールが頼りにしているこの標準を前へ進めるため、これからもコミュニティとともに歩んでいきます。

次世代SCMのアーキテクチャも、この土台の上に築かれています。Gitとの互換性は保ったまま、新しいワークロードが求める性能とスケーラビリティに応えられるよう、バックエンドとエージェント向けインターフェイスを設計し直しました。

このアプローチなら、お客様がGitに積み上げてきた投資を守りながら、GitLabはソフトウェアライフサイクル全体で素早くイノベーションを進められます。GitLabならではの強みは、統制されたソフトウェアファクトリー。ソースコード管理、コンテキスト、オーケストレーション、セキュリティ、ガバナンスを1つのプラットフォームにまとめている点にあります。

今後の展開

次世代SCMは現在プライベートベータとして提供中です。お客様とともに、実際のリポジトリとワークロードで性能を検証しているところです。

エージェントがソフトウェアの生産量を劇的に押し上げるなか、ソフトウェアファクトリー全体が機械のスケールで動かなければなりません。GitLabは、その基盤を築いています。

次世代SCMの早期アクセスをお申し込みのうえ、ご自身のリポジトリで実力をお確かめください。

このブログ投稿には、改正された1933年証券法のセクション27Aおよび1934年証券取引法のセクション21Eの意味における「将来見通しに関する記述」が含まれています。これらの記述に反映された期待は合理的であると考えていますが、実際の結果または成果が大きく異なる可能性のある既知および未知のリスク、不確実性、仮定、およびその他の要因の影響を受けます。これらのリスクおよびその他の要因の詳細については、SECへの提出書類の「リスク要因」というキャプションの下に記載されています。このブログ投稿の日付以降、法律で義務付けられている場合を除き、これらの記述を更新または修正する義務を負いません。