OpenAI、ChatGPTの保存基盤Habitat（ハビタット）の後編を公開読み出し中央値を約120msから約10msへ、Azure Cosmos DBの運用とキャッシュ・Rust化を説明

OpenAIは2026年10月23日（米国時間）、ChatGPTなどの裏側にある保存基盤「Habitat（ハビタット）」の技術解説の後編を、エンジニアリング記事として公式サイトに公開した。記事はAzure Cosmos DB（コスモスDB）の運用の見直しと、読み出しの高速化の2本柱だ。OpenAIの説明では、重要なデータの近隣地域への複製、リージョン内キャッシュ、Rust（ラスト）への書き直しを組み合わせた結果、世界の読み出し中央値（p50）は約120msから約10msになった。同社はこれを「12倍の改善」と書いている。

3行まとめ

1. OpenAIがHabitat後編を2026年10月23日に公開。世界の読み出しp50は約120msから約10msへ（12倍、OpenAI発表）
2. Azure Cosmos DBは共有コンテナに戻し、Azureチームが作った新サーバーレスモードで容量計画の手間を大きく減らしたとOpenAIは説明。最大のアカウントは数十PB・2,000万QPS超と説明
3. 無効化はCosmos DBのchange feedで世界に数秒で伝える方式。Valkeyキャッシュ、Rust書き直し、データ複製の寄与の内訳は公式ページに記載なし

本記事の内容は、日本時間10月24日1時台に公式ページで確認したものです。

何が公開されたのか

後編は、OpenAIのMembers of Technical StaffであるJon Lee、Hrachya Hakobyan、Chaomin Yuの3人の署名記事だ。9月11日公開の前編（公式ページ）は、Habitatが小さなPythonライブラリから独立したサービスになるまでと、Pythonで大規模トラフィックをさばく工夫が中心だった。前編の冒頭近くには、次回の記事で扱うこととして「マルチテナンシーの信頼性」「読み出し性能を上げる層状の戦略」「Azure Cosmos DBとの協業」が予告されており、後編はその3つにあたる。

OpenAIは後編の冒頭で、Habitatは「40の地理的リージョンにいる10億人超のユーザー」にミリ秒で応答する必要があると書いている。前編の同じ箇所は「ほぼ40リージョン」という表現だった。データ量は500PB超と、前編と同じ数字が使われている。

読み出しはなぜ速くなったのか

OpenAIは、読み出しが全リクエストの90%超を占めると書いている。そのうえで、読み出し性能を上げる戦略を3段で説明している。

1. データを利用者の近くに置く。 データ所在地の要件があるユーザー向けには地域ごとのアカウントがある。ただし、それ以外では置き場所がクラウドの物理的な容量に縛られ、多くのリージョンは割り当て分のストレージを置けないと説明している。電力や冷却に余裕のない地域では、近くにストレージを置くか、計算資源を増やして遠くに問い合わせるかの二者択一になることがあるという。
2. 小さく遅延に敏感なデータだけ広く複製する。 リクエストごとに必要な認証メタデータなどは、Cosmos DBのアカウントを多数のリージョンに複製している。40リージョンすべてに複製するアカウントもあれば、各大陸に少なくとも1つのリージョンを置くアカウントもある。ただし容量の制約があるため、対象は手で選んだ少数のデータセットに限るという。
3. それ以外は統合キャッシュに任せる。 Habitatの負荷は読み出しが中心で、頻繁に使われる小さなデータの集まりにトラフィックが偏る。OpenAIはこの性質がキャッシュに向いているとし、リクエストを処理する場所の近くに置いたValkey（バルキー）サーバーに、最近アクセスしたオブジェクトとエッジの写しを持たせている。

これに加えて、サービス自体をPythonからRustに書き直し、プロキシのオーバーヘッドを削ったとしている。図では、p50を下げた大きな設計変更として「重要なデータを近隣の地域に複製」「リージョン内キャッシュの開始」「Rust書き直しの開始」の3つが並ぶ。それぞれが何msぶん効いたかは、今回取得した2ページには書かれていない。

キャッシュの古さは「数秒」で抑えるという説明

キャッシュで難しいのは、古いデータを返さないことだ。OpenAIはTTL（有効期限）だけでは、短くするとキャッシュが効かず、長くすると古いデータを返し続けるというトレードオフがあると書いている。書き込み時に明示的に無効化する方法は新鮮さを保てる一方、部分的な失敗や、地域をまたぐ複製との競合で古いデータが残りうるという。

そこでHabitatは、MetaのTAOのような仕組みにならい、Azure Cosmos DBのchange feed（変更履歴）を使ったCDC（変更データキャプチャ）で無効化を世界中に数秒で伝えている。インフラ内のサービスがchange feedを読み、データが更新されたら各地のローカルキャッシュを無効化する。次の読み出しでミスが起き、最新版がキャッシュに入る流れだ。OpenAIはこれで「高いヒット率を保ちながら古さを小さくできる」と説明している。

CDCはキャッシュ以外にも使われている。1秒あたり数百万件の変更が、数千のコンテナと数百万のパーティションから、100を超えるKafkaのトピックを通って、二次インデックスやデータ移動、オフライン分析などに流れるとしている。

Azure Cosmos DBの運用で何が変わったのか

信頼性の側では、OpenAIは「共有コンテナ → 用途ごとの専用コンテナ → 共有コンテナ（既定）」という円を描くような経緯を説明している。

• 第1段階（共有コンテナ1つ）。 クライアントがパーティションキーを直接選べたため、user_id や workspace_id のような一般的なキーが製品間でぶつかった。物理パーティションを共有する「うるさい隣人」が、ログインやサインアップのような中核の流れを巻き込む問題も出た。データが増えて物理パーティションが分割されると、プロビジョニング済みの総スループットが同じまま1パーティションあたりの上限が下がる「弱いパーティション」も起きた。
• 第2段階（専用コンテナ）。 重要な新用途に専用コンテナを使い、サイト全体の障害を機能・サービス単位の障害にとどめられた。一方で、製品チームが事前にスループットを確保し忘れて、公開当日に障害対応の部屋（SEV room）で急いで増やす事態が繰り返されたという。容量計画に事実上すべての製品チームが関わる形になり、組織として回らなくなったと書いている。
• 第3段階（既定は共有、データ移動も可能）。 共有型に戻すにあたり、Azureチームと次の機能を作り込んだ。アクセスが集中するキー（ホットキー）から先に制限をかけるスロットリング、バルク挿入などオフライン処理の優先度を下げるQoS（リクエストの階層化）、そして新しいサーバーレスモードだ。

サーバーレスモードについてOpenAIは、既存のものは「ストレージ使用量だけで伸び、物理パーティションあたり5K RU/sに制限される」ため、RUを多く使う用途を伸ばせなかったと書いている。Azure Cosmos DBチームがOpenAIのために作った改良版は、物理パーティションごとに最大10K RU/sまで伸び、ストレージだけでなくRU使用量でも分割する。これでコンテナを手動で監視・増強する必要がなくなったという。OpenAIは、共有コンテナに戻したあとの数か月、プロビジョニング起因や「うるさい隣人」による障害は起きていないと述べている。

2024年末の停電と、その約1か月後の障害

OpenAIは協業の背景として、2つの障害を挙げている。ひとつは2024年末の主要リージョンでの停電で、最大級のアカウントのフェイルオーバーに数時間かかると分かった。もうひとつは、その約1か月後にリージョンへ戻す作業中に起きた。ゲートウェイモードのクライアントがフェイルオーバーを処理する際の癖で、一部のパーティションしか戻っていないのに全クライアントが元のリージョンへ接続を張り、ゲートウェイが過負荷になった。

OpenAIは、この教訓として、マネージドサービスは規模が大きくなると「マネージド度が下がる」と書く。現在は、共有のテスト、共有のダッシュボード、エンジニア同士の直接の連絡経路を持ち、サポート階層を介さずに互いを呼び出す手段まで用意しているという。本番と同じ大きさの非本番アカウントで変更を試すとも述べている。「我々の知る限り、この規模でAzure Cosmos DBを運用している企業は他にない」という主張も、OpenAI自身のものだ。

前編からの続き：Rust化と次の保存システム

前編には、Rustについての具体的な数字がある。OpenAIは、2026年第2四半期に2人のエンジニアとCodexとGPT‑5.5で、サービス全体をRustに書き直したと書いた。新しいRustサービスは本番リクエストの95%を処理していて、数週間でPythonを完全に廃止する予定だという。CPU効率は6倍、メモリ効率は15倍で、平均もテールも遅延が大きく下がったと説明している。後編が挙げる「Rust書き直し」は、この作業にあたると読めるが、後編のページ自体にはCPUやメモリの数字はない。

後編の最後には、次の10億人に向けた準備が書かれている。社内で開発中の、エクサバイト規模のオンライン保存システムだ。RocksDB Cloud（Rocksetの技術）とRaftベースの複製を組み合わせ、Cosmos DBと同じドキュメントモデルを実装する。ストレージを分離し物理複製を使うことでフラッシュ容量を減らす代わりに、ピークQPSは下がるとOpenAIは説明している。開発中の段階で、稼働の時期は書かれていない。

OpenAIが最近公開した別のエンジニアリング記事として、ChatGPTの広告配信の仕組みもある。

日本時間1時台に公式ページを読んで気づいたこと

日本時間10月24日1時12分台に後編のページを取得し、続けて前編も取得した。前編の冒頭の数字は「毎秒7,000万リクエスト超、週10億人超、500PB超」で、後編の「最大アカウントで2,000万QPS超」とは対象が違う。この2つを同じ指標と読むと、7,000万と2,000万で食い違うように見える。前編はHabitat全体、後編は最大のCosmos DBアカウント1つの数字だ。

また、前編の取得ページの「Keep reading」には後編が10月23日付で並んでいた。後編の「Keep reading」は前編を9月11日付で載せている。

今回の公式ページから分からないこと

今回取得した公式ページ2つ（後編と前編）で確認できなかった点を、本文を最後まで確かめたうえで書く。

• 新サーバーレスモードの提供範囲。 「OpenAIのために作った」とあり、一般提供や料金、日本リージョンでの利用に関する記載は見当たらない。
• 12倍の測定条件。 p50は「世界の読み出し」の値で、測定期間、リージョン別の内訳、データの種類ごとの差は書かれていない。p99などテール側の数字もなく、OpenAI自身が、最も遅いリクエストは「キャッシュにないデータをストレージから、しばしば遠い地域から取る必要がある」と書いている。
• 3つの施策の寄与の内訳。 図に3つの変更が並ぶだけで、どれが何msを縮めたかは書かれていない。
• 第三者による検証。 数字はすべてOpenAIの自己申告で、独立した測定ではない。

日本の利用者の体感がどう変わるかについても、今回の記事は何も言っていない。数字はHabitatの読み出しの遅延についてのもので、ChatGPTの画面の応答速度が12倍になったとは書かれていない。

確認した公式ページ（後編・前編）

• Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II) — OpenAI（2026年10月23日付）
• Rapidly scaling online storage to serve over 1 billion ChatGPT users — OpenAI（2026年9月11日付・前編）

2つとも日本時間2026年10月24日1時12〜13分に取得して確認しました。本記事は続報があり次第更新します。