Aspen：Git が想定していなかった規模でエージェントのコミットを捌く

何百ものエージェントが同時に push するリポジトリのための、オープンソースの Git サーバー。OpenAI が Pando で示した設計にならっています。クライアントは普通の Git のまま、pack はオブジェクトストレージに、ブランチは Postgres に。

著者: Reason

2026年11月5日

Git は人のために作られました。人が push するのは 1 日に数回です。エージェントは数分ごとに push し、数百のエージェントを動かすチームでは 1 つのリポジトリが消火ホースのようになります。何百ものブランチが同時に動き、push のたびに CI が fetch します。

従来の Git サーバーはこれに追いつけません。リポジトリへのすべての push を 1 つのキューに通すので、あなたのブランチへの push は他の全員の push を待ちます。さらに clone や fetch のたびに新しい pack を作り、同じ履歴をクライアントごとに圧縮し直します。pack とは、オブジェクト（ファイル、ディレクトリ、コミット）をまとめて送るための Git のファイル形式です。サーバーの仕事量は新しいコードの量ではなく、クライアントの数に比例して増えます。

1,000 の書き手、2 つのサーバー

1 つの四角は 10 個のコミットを push するエージェントです。読み手が 10 個すべてを fetch すると青になります。説明用の図で、時間は圧縮しています。

書き手 2501000再生速度 10×20×40×

従来の Git サーバー準備完了

0 秒シミュレーション–push → fetch0完了した書き手

Aspen準備完了

0 秒シミュレーション–push → fetch0完了した書き手

未開始サーバーのキューで待機中push 中10 個すべて fetch 済み

ベンチマークではなく、おもちゃのモデルです。従来のサーバーはすべての push を 1 つのリポジトリで順番に処理し、同じマシンで fetch ごとに pack を作るので、到着がその処理速度を超えた途端にキューが伸びます。Aspen は各ブランチを独自の compare-and-swap で動かし、fetch を保存済みの pack から返すので、書き手は push したペースのまま終わります。

OpenAI はモノレポでこの壁にぶつかり、それをどう乗り越えたかを「Scaling Git at OpenAI」に書きました。答えは社内の Git バックエンド、Pando です。1私たちはその設計を気に入り、オープンに作ることにしました。本日リリースするのは Aspen。誰でも動かせる、独立したオープンソースの実装で、Apache License 2.0 で公開しています。2

Aspen は HTTPS と SSH で普通の Git を話すので、クライアント側は何も変わりません。git push と git clone はこれまでどおり動きます。違いはすべてサーバー側にあります。

手放した 2 つのこと

Git サーバーは 2 つの方向にスケールしなければなりません。別々のブランチに push する多数の書き手と、同じ履歴を fetch する多数の読み手です。Pando にならい、Aspen は多くの Git サーバーが神聖視する 2 つの保証を手放します。

全ブランチの一貫したスナップショット各ブランチは Postgres の中のバージョンの連なりで、それぞれ独立して動きます。push はまず pack をアップロードし、1 行に対する 1 回の compare-and-swap でブランチを動かします。「このブランチがまだ A を指していれば、A から B へ動かす」というものです。別々のブランチへの push が互いを待つことはありません。同じブランチへの 2 つの push はその行で競い、片方がきれいに勝ちます。もう片方は Git でおなじみの「fetch first」を受け取り、rebase します。代償として、複数のブランチを見る読み手には、それぞれが少しずつ違う時点のものに見えることがあります。エージェントは気にしません。

クライアントごとの専用 packAspen は push を展開しません。pack を検証し、サーバーがすでに持っていたため Git が省いたオブジェクトを補い、届いたままの形でオブジェクトストレージ（S3、GCS、Azure Blob、または普通のディレクトリ）に保存します。fetch が来ると、Aspen は足りないものを含む保存済み pack を割り出してそれを流し、何も再圧縮しません。署名付き URL を渡して、クライアントが CDN から直接 pack をダウンロードすることもできます。

push、そして fetch

標準の Git と 2 つのストアの間にある、状態を持たない 1 台のサーバー。どちらの経路でも pack は作られません。

pushfetchブランチの行pack

Postgres はブランチごとに 1 行を持ち、オブジェクトストレージは push されたままの pack を持ちます。push は pack を 1 つ書いて行を 1 つ入れ替え、fetch は行を 1 つ読んで既存の pack を送ります。ステップをクリックすると再生できます。

誰でも push できるキャンバス

負荷生成ツールではなく人に Aspen を見せるため、私たちはこれを place.reasonmachines.com の裏に置きました。サインイン不要の 64 × 64 ピクセルの共有キャンバスです。各ピクセルは Git リポジトリ内のファイルで、タイルをクリックすると Aspen へのコミット 1 つと push 1 つになります。ボットが全員のブランチを main にマージし、main は GitHub にミラーされていて、その README にはキャンバスがライブで表示されます。

ターミナルからも描けます。clone してタイルのファイルを変え、git push するだけです。または、ページの Copy prompt を押して、そのプロンプトを Claude Code、Codex などのコーディングエージェントに渡してください。何をどこに描きたいかを尋ね、プレビューを見せ、あなたが OK を出したら push します。

キャンバス 一時停止

各ピクセルはファイルで、クリック 1 回が Aspen へのコミット 1 つの push です。人でもエージェントでも同じです。この画像は 2 秒ごとに更新されます。

git clone --depth=1 https://place.reasonmachines.com/canvas.git cd canvas && printf '#3690ea\n' > tiles/10_20.txt git add tiles && git commit -m paint && git push origin HEAD:paint/you

push は paint/ ブランチに入り、ボットが main にマージします。ルールとパレットはキャンバスの TILES.md にあり、main は次にミラーされています：GitHub.

push はトランクしか見ない

push するとき、普通のサーバーはまず持っているブランチをすべて列挙し、クライアントがサーバーにすでにあるオブジェクトを省けるようにします。ブランチが 100 万あれば、その一覧だけで巨大になります。しかもクライアントが作る pack はたまたま列挙されたブランチに依存するので、他の誰も再利用できません。

Aspen はトランクのブランチだけを列挙します。すると push にはトランク以降のすべてが含まれ、トランクを持っている人なら誰でもその 1 つの pack であなたのブランチを fetch できます。push は少し大きくなりますが、やり取りの大きさはブランチがいくつあっても変わりません。目に見える違いは 1 つだけです：git push --force と --delete には追加で -o force.

コンパクション

push のたびに小さな pack が 1 つ保存されるなら、1 日遅れのクライアントは何万もの pack が必要になります。そこで Aspen はバックグラウンドで pack を 16 個ずつ、段階的にマージします。LSM ツリーがファイルをコンパクションするのと同じやり方です。新しい clone は少数の大きな pack を受け取り、ほぼ最新のクライアントは少数の小さな pack を受け取ります。

浅い clone には専用の高速経路があります。CI はデフォルトで --depth=1 で fetch するからです。Aspen はブランチの先端の depth-1 pack を一度だけ作り、それを求めるすべての CI ジョブに返します。

スキップリストとしての段

1 本のバーが 1 つの pack です。コンパクションは pack を 4 つのサイズに保ち、fetch はクライアントとトランクの間の各ステップで、収まる最大の pack を取ります。

クライアントの位置v0

計画内の pack0

push ごとに 1 pack なら0

クライアントが既に保持送信中送信済み保存済み・不要

何千バージョンも遅れたクライアントでも、受け取る pack は何千ではなく数十個です。長い中間部分は大きな pack、端だけ小さな pack です。履歴に沿ってドラッグするとクライアントを動かせます。

どれくらい速いか

エージェントにとって重要な数字は、1 つのリポジトリへの 1 秒あたりの push 数です。それぞれの push が安全に保存されて初めて数えます。Cursor は自社の Git サーバー Origin について数字を公開しています。S3 Standard で毎秒最大 120 push、より高速な S3 Express One Zone で 300 超で、リポジトリへのすべての push が 1 つのログを通ります。3Aspen が順序づけるのは同じブランチへの push だけなので、そうしたリポジトリ単位の上限はありません。²

8 コアのサーバー 1 台、S3 Standard、4 コアの Postgres で、Aspen のブランチ URL 経由で git.git に push したところ、Aspen は毎秒 567 push を 5 分間、エラーなしで維持しました。Git が「ok」と表示する前に、各 push は S3 と Postgres に入っていました。push の中央値は 208 ms、99 パーセンタイルは 314 ms です。別のクライアントには、各 push が確認応答の 30 ms 後（中央値）に見えました。

OpenAI は Pando の push レートを公開していません。報告しているのは自社の以前のシステムとの比較です。push レイテンシの中央値がほぼ 80% 減り、少数のコアで 1 日 1 ペタバイトの Git データを配信し、clone が 10 Gbps の回線を使い切ります。1Aspen は Pando の設計にならっているので、そちらとの正直な比較は数字の形です。互いを待たない push と、作り直すのではなく保存済みの pack から返す fetch です。

main への取り込みは別の種類の数字です。取り込みはそれぞれ直前の取り込みの上に積み重なるので、個別の取り込みは 1 つずつ進みます。その方法で Aspen は毎秒約 4 件を処理し、上限を決めているのは負荷ではなく往復時間です。Aspen にはサーバー側のマージキューもあり、多数の PR をそれぞれ独立したコミットのまま main の 1 回の更新で取り込みます。その数字は計測でき次第公開します。これらの数字にはいずれも CI は含まれていません。

1 つのリポジトリへの毎秒の push 数

各 push は確認応答の前に永続化されています。Cursor の数字は公開値、Aspen の数字は私たちの計測です。

Cursor Origin、S3 Standard

120

Cursor Origin、S3 Express

300+

Aspen、S3 Standard

567¹

Aspen：8 コアのサーバー 1 台、S3 Standard、4 コアの Postgres で、Aspen のブランチ URL 経由で git.git に push し、5 分間維持。Cursor：自社モノレポ上のレプリケーションされたクラスター。そのモノレポの規模は記事に書かれていません。 ¹ 毎秒 567 は git.git（約 4,500 ファイル、7.5 万コミット）を Aspen のブランチ単位の URL 経由で push した値です。 ² push 1 回あたりのコストはリポジトリが大きくなるほど増えるため、非常に大きなモノレポでは現時点で数字が下がります。いま取り組んでいるのはそこです。

オープンソース、そしてまだ初期段階

コードは GitHub.aspen dev で、SQLite とローカルディレクトリを使ってノートパソコン上でサーバーが動きます。チーム向けには Docker Compose スタック、Helm チャート、そして AWS、Google Cloud、Azure、Hetzner 用の Terraform があります。

私たちが Aspen を信頼するのは、標準の Git と結果が一致するところだけです。差分テストスイートはランダムな push、削除、競合を Aspen と Git 自身のサーバーの両方に再生し、同一の結果を求めます。毎晩、Git 2.30 から最新版まで、そして JGit が Aspen に対して動き、ファザーと、push の途中でサーバーを落とすカオススイートも並行して走ります。Pando と同じく、Aspen もほぼエージェントによって作られました。1 つの Reason が、最初のコミットから公開までを 4 日間、151 件のマージ済みプルリクエストでやり遂げました。1

まだプレアルファです。Aspen は Git の部分だけで、Web UI はなく、部分 clone、SHA-256 リポジトリ、RSA の SSH 鍵にもまだ対応していません。1 つのリポジトリでエージェントを動かしているなら、ぜひ試して、壊して、GitHub で教えてください。

参考文献

<a id="ref-1"></a> [1] OpenAI. Scaling Git at OpenAI, 2026. OpenAI の Git バックエンド Pando について説明しています。ブランチごとの ref バージョン、トランクのみの push アドバタイズ、packfile URI による pack の再利用、LSM 風のコンパクションです。Aspen はその設計の独立した実装で、OpenAI とは関係ありません。投稿.

<a id="ref-2"></a> [2] Reason Machines. Aspen：エージェント規模のリポジトリのためのオープンソース Git サーバー、Apache License 2.0。リポジトリ、ライブデモは place.reasonmachines.com.

<a id="ref-3"></a> [3] Cursor. Git at any scale, 2026年8月. Origin は S3 Standard で「最大 120 push/秒」、S3 Express One Zone で「300 push/秒超」を維持し、push を先行書き込みログに入れて初めて確認応答します。投稿.