CodexをはじめとするAIエージェントがソフトウェア開発に深く組み込まれるなか、OpenAIでは従来のソースコード管理基盤が処理能力の限界に直面していた。問題となったのはGitのデータモデルそのものではなく、大量の並列操作を処理するサーバー側の仕組みだった。OpenAIは2026年11月2日、こうした課題を解決するために開発した新しいGitリポジトリ向けバックエンド「Pando」の技術的な詳細を公式エンジニアリングブログで公開した。
OpenAIによると、Pandoは既存のGitプロトコルやクライアントとの互換性を維持しながら、同社の大規模モノレポにおけるすべての開発作業を支えている。導入後は、以前のシステムと比べてプッシュ処理の所要時間の中央値が約80%減少し、ほぼ5分の1に短縮されたという。ただし、移行前後の所要時間の絶対値は公表されていない。これは処理速度が80%向上したという意味ではなく、プッシュの完了までにかかる時間が約80%削減されたという結果だ。
背景にあるのは、AIエージェントの普及による開発作業の急増だ。現在のOpenAIでは、1人のエンジニアがCodexを使って複数の変更を並行して進め、それぞれのブランチでコミットやプッシュを繰り返している。さらに、継続的インテグレーション（CI）や研究用ジョブが、同じコミットを取得するために大量のクローンやフェッチを同時に実行する。こうした要求が重なった結果、従来のGitバックエンドではプッシュやフェッチの遅延が常態化していたという。OpenAIはGit自体を置き換えるのではなく、そのプロトコルを処理するサーバーの内部構造を再設計することで、既存の開発環境を維持したまま問題の解決を図った。
データを表で見る
| プッシュ所要時間 (相対遅延（旧システム=100）) | |
|---|---|
| 移行前（旧システム） | 100 |
| Pando導入後 | 20 |
移行前のプッシュ遅延中央値を100とすると、Pando導入後は約20まで減少したことになる。この改善を支えているのは、Gitの基本的なデータ構造を変更することなく、サーバー側の同期処理とデータ配信の仕組みを根本から見直した設計だ。
AIエージェントの並列作業が浮き彫りにしたGitサーバーの限界
OpenAIによると、同社のモノレポを支えていた従来のソースコード管理基盤は、2025年末ごろから急増する負荷に対応できなくなっていた。フェッチやプッシュの処理速度が低下しただけでなく、ブランチのマージ失敗も頻発し、システムの信頼性を示す指標が一時的に90%を下回ったという。Codexを活用するエンジニアが複数の変更を同時にCIへ投入すると、各プッシュをきっかけに複数のテストジョブが起動し、同じコミットの取得要求がサーバーへ集中する。人間の開発者が中心だった時代には問題になりにくかった負荷が、AIエージェントの並列作業によって顕在化したのである。
Gitリポジトリを分散環境で運用するには、ソースコードや履歴を格納するオブジェクトと、ブランチの先端などを示す参照（ref）の両方を管理する必要がある。複数のサーバーで同じリポジトリを扱う場合、参照を更新する前に、その参照からたどれるGitオブジェクトが利用可能でなければならない。また、複数のクライアントが同じブランチを同時に更新しようとした場合には、競合を適切に処理する必要がある。従来の分散Gitシステムでは、こうした整合性を確保するため、リポジトリ全体の更新順序を調整する方式が採用されてきた。
OpenAIはPandoの設計にあたり、従来の代表的な構成として、3相コミット（3PC）方式と共有ログ方式の二つを比較した。
3相コミット方式では、複数のレプリカがリポジトリの完全なコピーを保持し、参照の更新を各レプリカ間で調整する。OpenAIがモデル化した構成では、プッシュを受け付けたサーバーがパックファイルを各レプリカへ送信し、過半数のレプリカが更新を受け入れることを確認してから処理を確定する。この方式では、レプリカ間の複数回の通信やディスクへの書き込みが必要になり、プッシュの完了までに時間がかかる。特に書き込み要求が増加すると、レプリカのディスク性能やネットワーク遅延がボトルネックとなる。
もう一つの共有ログ方式では、オブジェクトストレージ上の書き込み先行ログ（WAL：Write-Ahead Log）を使って更新順序を管理する。プッシュされたパックファイルをストレージに保存した後、その所在と参照の更新内容を共有マニフェストに記録する仕組みだ。マニフェストの更新には比較交換（Compare-And-Swap）操作を使い、ほかの書き込みと競合しないことを確認する。しかし、互いに無関係なブランチへのプッシュであっても、同じマニフェストを更新する必要があるため、書き込みが集中すると競合が発生する。ストレージ自体の処理能力を増やしても、単一のマニフェストを更新する仕組みが性能上の制約として残る。
両方式に共通する課題は、リポジトリ全体の更新を調整する仕組みが、独立したブランチの並列処理まで制限してしまうことだ。そこでOpenAIは、無関係なブランチへの書き込みを独立して処理することと、多数のクライアントに同じデータを効率よく配信することをPandoの設計目標に据えた。
Pandoでは、クライアントから受け取ったパックファイルを、サーバーのローカルリポジトリに展開することなく、不変のデータとしてオブジェクトストレージへ直接保存する。パックファイルとは、Gitの複数のオブジェクトをまとめて圧縮したファイル形式だ。Pandoは受信データをストリーミングしながら検証し、同時にメタデータストアへ参照の新しい状態を記録する。各参照のバージョン（ref version）には、ブランチの新しい先端、対応するパックファイル、過去の参照バージョンとの依存関係が含まれる。
プッシュが確定する際には、メタデータストアで新しい参照バージョンを記録し、その参照を指すポインタをアトミックに更新する。これにより、複数のクライアントが同じ参照を更新しようとした場合には競合を検出しながら、無関係なブランチへのプッシュを並行して処理できる。OpenAIによると、この同期的な更新に必要なメタデータの読み書き回数は、プッシュの規模に依存しない定数回、すなわち計算量でO(1)に抑えられている。ただし、これはメタデータ操作の回数を指すものであり、パックファイルの転送や検証を含むプッシュ全体がデータ量に関係なく一定時間で終わるという意味ではない。
読み取り処理も従来のGitサーバーとは大きく異なる。一般的なGitサーバーは、クライアントが持っているコミットと取得したいコミットを比較し、不足するオブジェクトだけを集めた専用のパックファイルを生成する。これに対し、Pandoは過去のプッシュで保存したパックファイルを再利用する。クライアントが必要とするデータを含むパックファイルの組み合わせを選択し、packfile-uriというGitプロトコルの機能を使って、そのダウンロード先を返す仕組みだ。
実際のデータ転送には、地域ごとに配置されたキャッシュサービス「Express」を利用する。クライアントはPandoサーバーから受け取ったURIを使い、Express経由で保存済みのパックファイルを取得する。サーバー側でクライアントごとにパックファイルを生成する必要がないため、同じデータを多数のクライアントへ配信してもCPUやディスクI/Oの負担を抑えられる。OpenAIによると、必要なパックを選択する際のメタデータ参照回数はO(log Δ)であり、Δはクライアントが保持する状態と取得したい状態の間にある参照バージョンの最短距離を表す。
さらにPandoは、時間の経過とともに増えるパックファイルを整理するため、ログ構造化マージツリー（LSMツリー）のコンパクションに似た仕組みを採用している。各プッシュで生成された最小単位のパックファイルをL0とし、バックグラウンド処理によって、複数の参照バージョンを覆う大きなまとまり（cover）へ段階的に統合していく。OpenAIのモノレポでは現在、L4までのカバーを利用しているという。この階層構造は、パックファイルの再圧縮によって転送効率を改善するだけでなく、スキップリストのように参照履歴を探索する役割も担う。必要なパックを対数時間で絞り込めるため、大量のコミットが蓄積された環境でも効率的にフェッチを処理できる。
リポジトリ全体の厳密な一貫性を緩和する設計上の判断
Pandoの高い並列処理能力は、従来のGitホスティング環境で重視されてきた一部の保証を緩和することで成り立っている。特に重要なのが、リポジトリ全体のスナップショット一貫性を保証する代わりに、「因果一貫性（Causal Consistency）」を採用したことだ。Pandoは個々の参照に対する更新の直列化可能性を維持し、クライアントが自分の書き込んだ変更をすぐに読み取れる「Read-your-own-write」も保証する。一方、リポジトリ内のすべての参照が、同じ時点の状態として観測されることまでは保証しない。
例えば、fooとbarという二つのブランチが同時に更新されている状況を考える。あるクライアントがリポジトリをクローンしたとき、fooはバージョン1、barはバージョン2として観測される一方、別のクライアントにはfooがバージョン2、barがバージョン1として見える可能性がある。Pandoでは、異なるブランチの更新をリポジトリ全体で一つの時系列にそろえることを保証していないためだ。ただし、特定のブランチを取得する場合には、その状態を作成した側の履歴と依存関係を再現できるようにしている。
OpenAIは、通常の開発作業では、リポジトリ内のすべてのブランチについて厳密な更新順序を把握する必要はないと判断した。人間の開発者もAIエージェントも、主に自分が扱うブランチの更新履歴と依存関係を追跡できれば作業を進められるためだ。リポジトリ全体の一貫性を維持するためにすべての書き込みを調整するよりも、ブランチ単位の整合性を守りながら並列処理を優先する方が、同社の開発環境には適していたことになる。
もう一つの重要な変更が、プッシュ時にサーバーがクライアントへ通知する参照情報（ref advertisement）の削減だ。従来のGitサーバーは、保有するブランチの参照情報をクライアントへ提示し、クライアントはその情報を使って、サーバーにすでに存在するオブジェクトを除外したパックファイルを生成する。この仕組みは転送データを小さくできる一方、ブランチ数が数百万に達するモノレポでは、参照情報の通知だけで100MiBを超える場合があるという。大量の参照情報を管理・送信する処理そのものが、サーバーの負担になる。
そこでPandoは、新しい機能ブランチへのプッシュに対して、原則として基準となるトランクブランチの先端だけを通知する方式を採用した。これにより、ブランチ数が増えても通知する参照情報の量を抑えられる。また、クライアントがどの履歴を前提にパックファイルを生成したかを限定できるため、そのパックを別のクライアントへのフェッチでも再利用しやすくなる。トランクの履歴をすでに持っているクライアントなら、機能ブランチの内容を単一のパックファイルから取得できる場合がある。
ただし、この方式では重複するデータの転送が増える可能性がある。同じ機能ブランチに何度もプッシュしたり、別の機能ブランチを土台にして変更を積み重ねるスタック型の開発を行ったりすると、トランクに含まれないオブジェクトを繰り返し送信することになるからだ。OpenAIのモノレポでは、この方式で生成されたプッシュ用パックファイルのサイズ中央値は20KiB未満、99パーセンタイルでも3MiB未満に収まっていたという。ただし、これらは同社の開発環境で得られた実測値であり、ほかのリポジトリでも同じサイズに収まるとは限らない。
フェッチやクローンでも、同様のトレードオフが存在する。Pandoはクライアントごとに不足するオブジェクトだけを抽出するのではなく、保存済みのパックファイルを再利用するため、クライアントがすでに持っているデータを重複してダウンロードする場合がある。つまり、ネットワーク転送量を最小化することよりも、サーバー側の計算負荷とディスクI/Oを削減し、キャッシュから高速に配信することを優先している。OpenAIは、自社の環境ではこの設計の方が全体の処理効率を高められると判断した。
OpenAIの技術発表で比較されている各方式の特徴を整理すると、次のようになる。これは同社がモデル化したアーキテクチャの比較であり、実在する異なるGitホスティング製品を同条件で測定したベンチマークではない。
| 方式 | 書き込みの調整方法 | 読み取りの仕組み | 主な性能上の制約 | 設計上の特徴 |
|---|---|---|---|---|
| 3相コミット（3PC） | レプリカ間の合意形成によって参照を更新 | 各レプリカのローカルリポジトリから配信 | レプリカ間の通信遅延とディスク負荷 | レプリカ間で整合した参照状態を維持する代わりに、更新時の調整負荷が大きい |
| 共有ログ（WAL） | 共有マニフェストに対する比較交換操作で更新順序を確定 | レプリカがログを読み込み、データを反映して配信 | マニフェストの更新競合とレプリカの追従遅延 | パックの保存は並列化できるが、参照更新の調整点が集中する |
| Pando（因果一貫性） | 参照ごとの独立したアトミック更新 | 保存済みパックの選択とExpressによるキャッシュ配信 | クライアントの帯域、ネットワーク、ストレージの処理能力 | リポジトリ全体の一貫性を緩和し、重複転送を許容して並列性を高める |
Pandoの特徴は、Gitの処理を単純に高速化したことではなく、何を保証し、何を緩和するかを見直した点にある。すべてのブランチの更新順序を厳密にそろえることを諦め、クライアントとサーバー間で多少の重複データが転送されることを受け入れる。その代わり、無関係なブランチの更新を独立して処理し、多数のクライアントに同じ履歴を効率よく配信できるようにしたのである。
1日約1PBを配信、10週間で本番環境へ投入
OpenAIはPandoの実運用について、いくつかの具体的な数値を公表している。同社のモノレポでは現在、1日あたり約1ペタバイト（PB）のGitデータを配信しているという。ピーク時には1時間で57テラバイト（TB）を超えるGitパックファイルを配信し、その転送量の99%以上がローカルのディスクキャッシュから供給された。頻繁に取得されるパックファイルをキャッシュすることで、大量のフェッチ要求が発生しても、元のオブジェクトストレージへのアクセスを抑えている。
また、一般的なパブリッククラウドの仮想マシンを利用した検証では、クローンとフェッチの処理で10Gbpsのネットワーク帯域を使い切ることを確認したという。Pandoサーバーは主にGitプロトコルのネゴシエーションとパックファイルの選択を担当するため、データ配信に必要なCPU資源も少なくて済む。OpenAIは、少数のCPUコアで1日約1PBのデータ配信を支えられるとしている。ただし、これらは同社が公表した自社環境での結果であり、第三者による独立した性能比較ではない。
OpenAIの公式発表では、Pandoと3相コミット方式、共有ログ方式の性能を比較するシミュレーションも紹介されている。1,000のクライアントがそれぞれ異なるブランチを選び、独立したコミットを繰り返しプッシュする条件で、処理全体の所要時間と、プッシュされた変更を別のクライアントがフェッチできるようになるまでの遅延を評価したものだ。仮想マシンやストレージの性能を変えながら各方式の挙動を比較しており、3相コミット方式についても比較条件としてリポジトリ全体の一貫性要件を緩和している。
シミュレーションでは、3相コミット方式は負荷が増えるにつれてレプリカのディスク性能が制約となり、書き込み遅延が大きくなった。一方、共有ログ方式では、サーバーがログからデータを読み込んで反映する処理に追いつけず、読み取り遅延が増大した。Pandoは、ブランチごとの独立した更新とキャッシュを利用した配信によって、高い並列処理能力を維持したという。ただし、これはアーキテクチャの特性を検証するためのモデルであり、実際の開発で発生するビルドや自動テストの所要時間を含むものではない。
Pandoの開発期間も特徴的だ。OpenAIによると、プロジェクト開始から本番環境への投入までに要した期間はわずか10週間だった。中心となるアーキテクチャは1人のエンジニアが設計し、実装作業の大部分をAIエージェントのチームが担当した。少数のエンジニアが配備を進め、2026年4月には本番環境でのトラフィック処理を開始している。AIエージェントによる開発作業の増加に対応するインフラを、AIエージェント自身の支援を受けて構築したことになる。
実装言語にはRustが採用された。OpenAIは既存システムの古い依存関係を引き継がず、新しいコードベースとしてPandoを開発したという。検証では、標準的なGitの動作に適合しているかを調べるテストスイートを作成したほか、決定論的なシミュレーションテストを使い、通信手順の交渉やパックファイルの選択処理に潜む競合状態を調査した。こうした検証によって、並列処理に伴う微妙な不具合や性能上の問題を発見し、修正を重ねたとしている。
開発には複数のAIモデルが使われ、後の段階では「GPT-6 Astra」も活用された。OpenAIによると、AIエージェントはLeanやTLA+を使ってPandoの動作を形式的に記述し、システムの性質を検証することで、実装上のバグを発見・修正したという。数百時間に及ぶ連続したエージェントの作業も行われ、境界条件に潜む問題の検出が続けられた。また、Daybreak対応モデルを利用したGitとPandoへの継続的なレッドチームテストも実施している。ただし、形式検証の対象となった性質や、システム全体についてどこまで正しさが証明されたかは、公開情報だけでは判断できない。
本番環境への移行も段階的に進められた。当初はPandoを既存のソースコード管理システムの前段に置き、読み書きの要求を中継するプロキシとして運用した。Pandoと従来システムの状態を同期させながら、サービス停止を伴わずにトラフィックを移行する方式だ。さらに、同じデータへの要求をまとめる機能を活用し、移行中も既存システムに過剰な負荷がかからないようにしたという。
この移行にはGitサーバーだけでなく、コードレビュー、変更要求、Webhook、自動化API、リポジトリのダウンロード機能など、多数の関連システムも含まれていた。OpenAIは数百の連携機能を新しい基盤へ移行し、開発者の端末やChatGPTデスクトップアプリにも、独自の改善を加えたGitクライアントを配布した。開発者がCodexに環境移行を依頼できるよう、既存のチェックアウトを準備するためのスキルも整備したという。こうした作業を経て、Pandoは現在、同社のモノレポ全体を支えている。
移行後はマージの信頼性が改善し、プッシュ遅延の中央値も約80%削減された。ただし、以前は90%を下回ることもあった信頼性指標が、移行後に具体的に何%まで回復したのかは公表されていない。遅延については定量的な改善が確認できる一方、運用の安定性についてはOpenAIによる定性的な説明にとどまっている。
Pandoは非公開、外部ユーザーへの恩恵はGit本体への改善が鍵
Pandoが示したのは、AIエージェントの普及によってソースコード管理に求められる性能が変わりつつあるということだ。複数のエージェントが並行してブランチを作成し、コミットやプッシュを繰り返す環境では、人間の開発者を中心に想定された従来の運用よりも、はるかに多くの読み書き要求が発生する。その結果、Gitのデータ構造そのものより先に、サーバー側の参照更新の調整やパックファイルの生成処理が性能上の制約になる場合がある。Pandoは、こうした負荷に対応するための新しい設計例といえる。
ただし、外部の開発チームが現時点でPandoを自社のインフラに導入できるわけではない。OpenAIはPandoのサーバー実装をオープンソースとして公開しておらず、マネージドサービスとしての提供時期や料金、自社ホスティング向けパッケージの配布計画も発表していない。同社はPandoを支える技術をユーザーと共有する方法を検討していると説明するにとどまっている。多数のAIエージェントが単一のリポジトリで協調作業する用途についても、社内で可能性を探っている段階だ。
一方、Pandoの開発で得られたGitクライアント側の改善は、すでに一部が公開されている。OpenAIは独自のGitリポジトリを公開し、標準のGitに対して複数の改善を提案している。特に重点を置いているのが、packfile-uriを使ったデータ取得の高速化と信頼性の改善だ。パックファイルの並列ダウンロードやインデックス作成、転送が中断された場合の後処理、再開時の状態確認など、Pandoを運用する過程で見つかった課題への対応が進められている。
OpenAIのGitクライアントでは、複数の独立したパックファイルを並行してダウンロードし、インデックスを作成できる。また、プッシュ時にサーバーが通知するブランチの先端情報と、クライアントがパックファイルを生成する際に前提としてよい履歴を区別する「explicit haves」の仕組みも導入された。これにより、--force-with-leaseで機能ブランチの更新競合を検出しながら、転送するパックファイルの依存関係をトランクの履歴に限定できる。ほかのクライアントが同じトランクの履歴を持っていれば、そのパックファイルを再利用してブランチの内容を取得できる。
さらに、パックファイルのダウンロード時間や生成時の転送量を追跡する機能も改善された。これにより、フェッチが遅い原因がサーバー側のパックファイル生成にあるのか、それともネットワーク転送にあるのかを切り分けやすくなる。こうした改善は、Pando以外のGitホスティング環境でも役立つ可能性がある。
ただし、OpenAIが公開している改善のすべてが標準のGitに取り込まれたわけではない。例えば、複数のpackfile-uriからパックファイルを並列取得する機能については、Git本体へのプルリクエスト（PR #2262）が提出されている。このPRは2026年9月30日にマージされないままクローズされており、OpenAI側は再作業後に再開する意向をコメントしている。現時点では、この提案を標準のGitで利用できる機能として扱うことはできない。
一方で、OpenAIが開発した修正の一部はすでにGit本体に取り込まれている。同社は公開パッチトラッカーを通じて、上流へ取り込まれた変更と独自ビルドに残る改善を区別して公開している。2026年7月には、packfile-uriを使った並列ダウンロード時の競合や、転送中断後のファイル管理に関する修正が標準のGitに反映された。一方、独立したパックファイルの並列インデックス作成やexplicit havesなどは、引き続きOpenAI独自ビルド側の機能として示されている。これらが広く利用できるようになるには、Gitコミュニティでのレビューや検証、正式な取り込みが必要だ。
Pandoの設計があらゆる開発環境に適しているわけでもない。複数のブランチについて厳密に同一時点の状態を把握する必要があるシステムでは、リポジトリ全体のスナップショット一貫性を緩和する設計が問題になる可能性がある。また、ネットワーク帯域が厳しく制限された環境では、重複するオブジェクトの転送を許容する方式がかえって不利になることも考えられる。Pandoの成果は、OpenAIのモノレポで発生している負荷と、その運用条件に合わせて設計された結果として評価する必要がある。
外部の開発チームにとって重要なのは、Pandoの性能値をそのまま自社環境の目標にすることではない。AIエージェントの導入によってGitサーバーのどの処理がボトルネックになるのかを把握し、必要に応じて読み書きの並列性やキャッシュの活用を見直すことが先決だ。OpenAIが示したプッシュ遅延約80%削減という成果は、大規模なAIエージェント開発に対応するための有力な設計例となる。今後はPandoの技術が外部に公開されるかに加え、同社が進めるGitクライアントの改善が標準のGitにどこまで取り込まれるかが、より広い開発者コミュニティへの影響を左右することになる。