Pando：OpenAI、自社エージェントの爆発的な作業ペースに対応すべくモノレポ用Gitサーバーを再構築

OpenAIは2026年11月2日、自社のモノレポ全体を運用する新しいGitリポジトリ向けバックエンドPandoの詳細を公表した。開発の契機はコーディングエージェントの直接的な影響にある。Codexの導入により、各エンジニアが複数のブランチを並列でプッシュし、各プッシュが同じコミットを取得する複数の継続的インテグレーション（CI）タスクをトリガーするようになった結果、従来のシステムは負荷に耐えられなくなった。ブログ記事によると、2025年末以降、システムの信頼性は一時的に90%未満に落ち込み、fetchの遅延やマージの失敗が多発していたという。

Gitサーバーにおける2つの前提の撤廃

開発チームはGitを破棄するのではなく、プロトコルとクライアントの互換性を維持しつつ、一般的なGitサーバーが当然視してきた2つの前提を見直した。

• リポジトリ全体の一貫したスナップショットを要求しない。 Pandoはブランチごとに個別に調停を行う。異なるブランチへの2つのプッシュは互いを待つ必要がなく、競合するのは同一ブランチへの同時書き込みのみとなる。このトレードオフとして、複数ブランチを読み出すクライアントには、ブランチごとにわずかに異なる時点の状態が見える可能性がある。しかしOpenAIは、人間もエージェントも実際には同一ブランチの更新順序にしか依存していないと判断した。
• クライアントごとのカスタムパックファイルを生成しない。 fetchのたびにオブジェクト群のパックを再計算する代わりに、Pandoはpush時に受け取ったパックファイルをそのまま保存し、Gitプロトコルのあまり知られていない機能であるpackfile-uriを利用して他のクライアントへ再配信する。これらのパックの再利用性を高めるため、プッシュを行うクライアントに対しては、デフォルトで単一の参照ブランチ（トランク）のみを通知する仕組みを採用した。

パックはオブジェクトストレージに、メタデータは分散データベースに保存され、Expressと呼ばれるリージョンキャッシュサービスがこれらを配信する。LSMツリーに着想を得たバックグラウンドでのコンパクション処理により、小さなパックは段階的なレベル（現在は最大L4まで）に統合される。

公表された実績データ

OpenAI発表の数値、第三者による測定ではない。

エージェントの手で10週間で構築

この取り組みで最も示唆に富むのは、その構築手法である。Pandoは1名のエンジニアが設計し、エージェントチームが実装し、一握りのメンバーがデプロイを担当した。着手から本番運用までわずか10週間で到達し、2026年4月から本番トラフィックを処理している。Rustで記述されたPandoは、エージェントが変更内容を検証するためのGit適合性テストスイート、決定論的シミュレーションテスト、およびバグ検出のためにGPT-6 Astraを用いるエージェントが作成したLeanとTLA+の仕様書を活用している。移行自体はプロキシを経由してダウンタイムなしで実施され、Codexは各チームの開発環境の切り替えも支援した。

OpenAIは、Gitプロジェクト本体にも複数の修正（並列パックダウンロード、packfile-uriのトレース機能、「explicit haves」の概念など）をコントリビューションしたと述べている。また、Pandoの技術を自社ユーザーに提供する方法を模索中としているが、具体的な製品発表には至っていない。