研究公開 2026-09-20· 約10分

OpenAIが「週に10億人超」の裏側のストレージ基盤Habitatを解説──毎秒7,000万リクエスト・500PB・3年連続で年10倍超の成長。Pythonで粘ってから、エンジニア2人＋Codex＋GPT-5.5でRustに書き直し、CPU効率6倍・メモリ15倍

OpenAIは2026年9月11日、エンジニアリングブログで自社のオンラインストレージ基盤「Habitat」を解説した。Habitatは毎秒7,000万リクエスト超を処理し、週に10億人超が使う製品を約40リージョンで支え、500PB超のデータを扱う。2023年のDevDayでGPTs向けの小さなPythonライブラリとして始まり、2025年半ばに独立サービス化、Pythonのまま3年連続で年10倍超の成長をしのいだ（ピークで毎秒2,000万リクエスト）。asyncioの遅延の計測、Statsigの設定ポーリングが毎分全ワーカーを止めていた件、aiohttpのLIFO接続再利用が遅いプロセスに負荷を集めるメタ安定障害、Envoyでの接続集約、意図的に「できることを少なくした」NoSQL API（TAO型）を経て、2026年第2四半期にエンジニア2人とCodex・GPT-5.5でRustに全面書き換え。Rust版は本番の95%を処理し、CPU効率6倍・メモリ効率15倍、数週間でPython版を廃止する。2部構成の第1部で、第2部はAzure Cosmos DBの層を扱う。

執筆・編集：AI時短ラボ

Habitatとは
Pythonで大規模サービスを運用して分かったこと
RustへのCodexによる書き換え
「週に10億人超」の位置づけ
筆者が確かめた点
書かれていないこと
出典はOpenAIのエンジニアリングブログ

2026年9月18日・日本時間時点の情報です。 OpenAIのエンジニアリングブログ（9月11日付、著者はJon Lee・Chaomin Yu・Ben Riesの3氏）を読んだ。製品の発表ではなく、ChatGPT・API・Codexの裏でデータを出し入れしている社内基盤「Habitat」の話で、規模の数字と、Pythonで粘った理由、Rustに書き換えた経緯が具体的に書かれている。当サイトが8月に扱った「ChatGPTアプリが月間10億ユーザー」はSensor Towerの推定値だったが、今回はOpenAI自身が「週に10億人超」と書いた点も含めて整理する。

3行まとめ

規模。 Habitatは毎秒7,000万リクエスト超を処理し、週に10億人超が使う製品を約40の地理リージョンで支え、500PB超のデータを扱う。2023年のDevDayでGPTsを支える小さなPythonライブラリとして始まり、いまは分散システム。「多くのシステムエンジニアは10倍の規模を見込んで作り数年持たせるが、我々は3年連続で年10倍超成長した」。

Pythonで粘った理由と、粘るための技術。 2025年半ばにライブラリから独立サービスへ（数十のサービスにまたがるクライアント更新が数日単位の調整になり、ある回はロールバックした1チームの古いクライアントが避けたかった障害を起こした）。Pythonのまま運用したのは「開発者のブロック解除と安定が最優先。自社のコーディングモデルが進めば、後の移行はCodexとGPTでできると賭けた」から。ピークで毎秒2,000万リクエストをPythonで捌き、asyncioのスケジューリング遅延の計測、Statsigの設定ポーリングの見直し、aiohttpのLIFO接続再利用をFIFOに変える、Envoyで接続を集約する、といった手当てを重ねた。

Rustへ。 2026年第2四半期、エンジニア2人とCodex・GPT-5.5でサービス全体をRustに書き換え。Rust版はすでに本番リクエストの**95%**を処理し、CPU効率6倍・メモリ効率15倍、平均もテールも遅延が下がった。数週間でPython版を完全に廃止する。今回は2部構成の第1部で、第2部はマルチテナントの信頼性・読み取り最適化・Azure Cosmos DBとの協業を扱う。

Habitatとは

製品エンジニアが「データベースの管理を考えなくていい」ようにする層で、スキーマの参照・ルーティング・認可・暗号化・シリアライズ・リクエスト整形・接続プールをHabitatが引き受け、データがAzure Cosmos DBにあるかキャッシュにあるかも意識させない。ブログの図では、クライアント（ChatGPT・API・Codex・社内サービス）とストレージ資源（Azure Cosmos DB・Nanobase・Valkey・Blob・CDC経由のDatabricks／Rockset／Kafka）の間に、キャッシュ・ACL・データ所在地・暗号化・マルチテナント分離・レート制限・ルーティングの機能が並ぶ。中央の1か所にしたことで、アクセス制御・監査ログ・下位ストレージへのアクセス制限を集中して掛けられ、「外部・内部・エージェントの各アクターからの不正アクセスを防ぐ」役割も担うと書かれている。

Pythonで大規模サービスを運用して分かったこと

asyncioは並行だが並列ではない。 I/Oの待ちは重ねられてもCPU処理は1本ずつで、圧縮・暗号化・チェックサム・ヘルスチェック・シャドウイング・ヘッジングなどCPUの重い仕事が多いHabitatでは、イベントループのスケジューリング遅延がテール遅延を支配した。定期的なバックグラウンドタスクで「予定時刻と実際の実行時刻の差」を記録して遅延を実測し、1プロセスあたりの同時リクエストを少なく保ち、Pythonのワーカープロセス数を大量に横に広げる方針に
設定ファイルの取得が全ワーカーを止めていた。 Statsig（機能フラグ）の既定が「毎分・ジッターなし・全サービスの全ルールを含む設定をポーリング」で、ポッドあたり最大8プロセスが毎分同時に巨大なJSONを解析していた。小さな対象設定に分け、間隔を延ばし、ジッターを入れて解決
接続プールが遅いプロセスに負荷を集めた。 aiohttpのTCPConnectorはLIFO（最近返された接続を次に使う）が既定で、バーストのあと遅いサーバーの接続ほど後で返るため次に選ばれやすく、苦しいポッドにさらに仕事が集まる「メタ安定障害」になった。FIFOに変えてフィードバックループを断ち、定常状態のばらつきも減った。現在はIstio／Envoyの負荷を見た振り分けに任せている
下流を溺れさせない。 プロセスが桁違いに多いので、通常のデプロイでも接続の張り直しでCPUが回り、接続リークでNATゲートウェイが飽和する。EnvoyでHTTP/1をHTTP/2に上げて多重化し、接続を集約し、レート制限とサーキットブレーカーも中央で
わざと「できることを少なく」した。 任意のSQLを許さず、TAOに着想を得たオブジェクトとエッジのNoSQL APIだけを出す。「高価で走らせにくいクエリを、安く簡単に書けてしまう」のがSQLの問題で、Postgres時代はホットパスの新しい高価なクエリ1本がデータベースを落とす障害が頻発した。複雑な検索はCDCでRocksetへ流した別ビューで各チームが自分で持つ

RustへのCodexによる書き換え

Pythonの書き換えを1年先送りしたことで、急成長期に「より緊急で影響の大きい課題」に集中できた、というのがブログの整理である。Habitatはコア数でOpenAIで2番目に大きいサービス（Envoyの規模では4番目）になり、2026年第2四半期にエンジニア2人とCodex・GPT-5.5で全面書き換えを実施。「自社モデルの進歩に賭けた」という2025年の判断が「結果として正しかった」と書く。Codexの現在の入口と使い方はCodexの使い方、書き換えに使われたGPT-5.5は10月14日にChatGPT・Codexから廃止される。

「週に10億人超」の位置づけ

当サイトがこれまで扱った利用者数は、Sensor Towerの推定「月間10億ユーザー」（8月）と、HBRの記事にあった「週間9億人」（7月）だった。今回のブログはOpenAIのエンジニアが「supporting products used by over 1 billion people each week」と書いており、週間で10億人超という自社表現になっている。ChatGPTだけでなくAPI・Codexを含む「製品」の合計である点は読み方の注意になる。

筆者が確かめた点

この記事の下調べで、筆者は9月18日にOpenAIのエンジニアリングブログ本文を自分のブラウザで開いて全文を読み、上の数字（7,000万／秒・10億人／週・500PB・約40リージョン・2,000万／秒のピーク・エンジニア2人・95%・6倍・15倍）と引用がその原文にあることを確認した。筆者はHabitatを外から観測する手段を持たず、数字はすべてOpenAIの自己申告である。