OPENAI SEARCH INSIGHT

2026.10.24 / OpenAI最新情報

ChatGPTを支えるOpenAIのHabitat、読取遅延を12分の1に

この記事で分かること: OpenAIがChatGPT向けオンラインストレージをどのように大規模化し、信頼性とグローバルな読取性能を改善したのかを知りたい。

OpenAIは2026年10月23日、ChatGPTを含む同社製品向けオンラインストレージ基盤「Habitat」の拡張に関する技術記事の第2弾を公開した。Azure Cosmos DBのマルチテナント設計、グローバルキャッシュ、Rustへの書き換えを組み合わせ、グローバル読取のp50レイテンシーを約120ミリ秒から約10ミリ秒へ改善したという。

今回の核心は、単にデータベースの性能を上げる話ではない。OpenAIは、単一テナントによる分離と、共有基盤による運用効率の間を往復したうえで、Azureチームとの共同運用を前提にした共有コンテナ方式へ移行した。信頼性、速度、運用効率をこの順に最適化するという基盤設計上の判断が、急成長するChatGPTのデータアクセスを支えている。

OpenAIが公開したHabitat拡張の概要

Habitatは、OpenAI製品が必要な情報へ高速かつ信頼性高くアクセスするために構築したオンラインストレージプラットフォームである。OpenAIによれば、この基盤は40の地理的リージョンにまたがる10億人超のユーザーに対し、ミリ秒単位で応答する必要がある。

2部構成のシリーズでは、Pythonクライアントとデータベースから、グローバル分散ストレージ基盤へHabitatを発展させた経緯を説明する。第1部はPythonベースのサービス化が中心で、第2部では基盤データストアであるAzure Cosmos DBを大規模化した手法を扱った。

OpenAIはHabitatが500ペタバイト超のデータを扱うグローバル分散基盤になったと説明する。最大のAzure Cosmos DBアカウントは数十ペタバイトを保存し、毎秒2000万超のクエリを処理している。これらはOpenAIが公表した運用規模であり、一般的なクラウド利用時の設計前提を超える水準だ。

マルチテナント化で直面した3つの問題

OpenAIは当初、各アカウントに既定のAzure Cosmos DBコンテナを1つ置き、クライアントの負荷を受け入れる設計を採った。しかし、利用者が論理パーティションキーを選べる初期APIにより、user_idやworkspace_idのような汎用キーが異なる用途間で衝突した。

Azure Cosmos DBでは、論理パーティションキーごとの上限だけでなく、複数の論理パーティションを収容する物理パーティション側にも実質的な制約がある。このため、負荷の高い「ホットキー」が同居する他のワークロードへ影響する、いわゆるノイジーネイバー問題が発生し得る。

さらに、データ増加に伴う物理パーティション分割も課題となった。コンテナ全体の割り当てスループットが変わらないままパーティション数が増えると、各パーティションで使えるスループットは下がる。OpenAIは、保存量の増加だけで稼働中ワークロードの処理余力が低下する障害モードを指摘している。

• 論理パーティションキーの衝突による特定テナントへのスループット制約
• 物理パーティションを共有する負荷集中によるノイジーネイバー
• データ容量の増加に伴う分割で、パーティション当たりの余力が弱まる問題

単一テナントへの分離から共有へ戻した理由

OpenAIは次に、重要な用途を個別コンテナへ分離した。コンテナを分ければ、物理パーティションとスループットを独立して割り当てられ、障害の影響範囲を機能やサービス単位に抑えやすい。既定コンテナを保護するため、新規サービスや大規模機能にも専用コンテナを設ける運用を進めた。

一方、専用コンテナは各チームに容量計画を要求する。社内テスト段階の低負荷から、本番リリース時に大幅に負荷が跳ね上がる場合、事前のスケール設定を忘れれば、リリース当日に増強対応が必要になる。個別分離は安定した集約負荷というマルチテナントの利点を失わせた。

そこでOpenAIは共有コンテナを既定に戻し、Azureチームと改善を進めた。高負荷キーを優先的に抑制するホットキー・スロットリング、対話型処理を優先するQoS、RU使用量に応じた分割も行う改良版サーバーレスモードを組み合わせた。共有基盤を標準にしながらワークロードの隔離を維持することが狙いである。

OpenAIによると、この変更後の数カ月間、開発速度が加速するなかでも、プロビジョニングやノイジーネイバーに起因するインシデントは発生していない。これは公式記事で示された同社の運用結果であり、すべてのAzure Cosmos DB環境で同じ結果を保証するものではない。

共同管理サービスとしてのAzure Cosmos DB

OpenAIは、大規模利用者にとってマネージドサービスは完全に「任せきり」にはできないと説明する。2024年後半には、主要Azureリージョンでの停電に伴うフェイルオーバーで、大規模アカウントの切り替えに数時間かかることが判明した。その後のフェイルバック時には、接続集中がゲートウェイを圧迫する重大障害も起きた。

これを受け、HabitatチームとAzureのエンジニアリングチームは、共有テスト、共有ダッシュボード、直接の技術連絡経路、障害モードの共同所有を進めた。現在は本番規模ながら非本番のアカウントで変更を検証し、SDKの改善やアカウントの規模設計も共同で扱うとしている。

実施内容には、制御プレーンとゲートウェイの拡張性改善、メタデータのキャッシュ、Pythonプロセスでの接続プールと接続再利用、ワークロードの配置最適化、重要処理とオフライン処理のVPC分離が含まれる。クラウド事業者との運用境界を越えた共同設計が、超大規模基盤では信頼性要件の一部になるという位置付けだ。

グローバル読取を12倍高速化した構成

OpenAIは、2025年に基盤の安定化が進み、グローバル展開に伴って遅延が主要な制約になったとしている。計算資源とストレージ資源が別リージョンに配置される場合があり、リージョン間通信を完全には避けられない。データ所在地とリクエスト処理地点の組み合わせにより、遅延が大きく変動する状況だった。

対策は3層で構成される。第1に、データ所在地要件がある利用者向けを中心に、可能な範囲でデータを利用者の近くへ置く。第2に、認証メタデータのような極めて遅延に敏感な小規模データは、多数リージョンへ複製する。ただし、容量制約があるため広範な複製は一部データセットに限定される。

第3に、大半の読取処理には分散キャッシュを統合した。Habitatは読み取り中心であり、設定や状態など頻繁に参照されるデータの作業セットは比較的小さい。OpenAIはリクエスト処理地点の近くにValkeyサーバーを置き、ルックアサイドキャッシュとして最近アクセスされたオブジェクトとエッジのコピーを保存する。

キャッシュの鮮度維持には、Azure Cosmos DBのchange feedを使う変更データキャプチャ（CDC）を採用した。データ更新を検知すると各地のローカルキャッシュを数秒以内に無効化し、次回読取時に最新版を取り込む。TTLだけに依存する方式より、高いヒット率と低い古さの両立を目指す構成である。

加えてHabitatサービス自体をPythonからRustへ書き換え、プロキシ処理のオーバーヘッドを下げた。これらの施策により、OpenAIはグローバル読取p50を約120ミリ秒から約10ミリ秒へ、約12倍改善したとしている。なお、未キャッシュのデータを遠隔リージョンのストレージから取得する遅いリクエストは、なお課題として残る。

CDCをプロダクト開発者から隠蔽する設計

CDCはキャッシュ無効化だけでなく、結果整合性のあるセカンダリーインデックス、データ移動、オフライン分析、リアルタイム機能にも使われる。OpenAIは、毎秒数百万件の変更を、数千のコンテナと数百万のコンテナパーティションから100超のKafkaトピックへ流していると説明する。

こうした環境では、各プロダクトチームが対象データのコンテナ、監視リージョン、ワーカー数、Kafka、コンシューマーを個別に理解して設定する方式は複雑になる。HabitatのCDCプラットフォームは、変更時に呼び出したい関数を登録するだけで、捕捉、リージョン選択、配分、スケールを内部で扱う抽象化を目指す。

OpenAIは、ワーカー障害、リースストアのエラー、設定不備、配送先障害を前提に、ストリーム間の障害分離、デッドレターキュー、代替リージョンへの切り替えを実装した。AzureのCDC SDKについても、チェックポイントをメモリー内でまとめ、定期的に書き出す変更を加えたとしている。

Agent Memories編集部の考察

日本企業がこの事例から評価すべきなのは、「共有か分離か」を固定的に決めないことだ。OpenAIの事例では、専用コンテナ化は障害範囲を狭めた一方、容量計画の責任を多数チームへ分散させ、組織としての運用負債を増やした。テナント分離の粒度は、技術的な隔離だけでなく、誰が予測・増強・障害対応を担うかで決める必要がある。

実務ではまず、ホットキー、物理パーティション偏在、リリース時の負荷急増を可観測性の対象に含めたい。特にユーザーID、組織ID、顧客IDをパーティションキーにする設計では、特定顧客の急増が共有リソースに及ぼす影響を、論理キー単位と物理配置単位の双方で検証することが重要になる。

また、キャッシュはTTLを長くするだけでは十分ではない。更新イベントを使った無効化、失敗時の再試行、リージョン間伝播の遅れ、古いデータを返してよい業務範囲を明文化する必要がある。OpenAIのCDC統合は、キャッシュ整合性をアプリケーション任せにしないという設計判断として参考になる。

ただし、OpenAIの規模、Azureとの共同開発体制、データ配置の制約は多くの組織と異なる。直ちに同じ構成を採るより、重要なオンライン処理とバッチ処理の優先度分離、変更データの配信保証、障害訓練を段階的に強化する方が現実的だろう。

よくある質問

HabitatはChatGPTだけのための基盤ですか

いいえ。OpenAIはHabitatを、同社製品が必要な情報へ高速かつ信頼性高くアクセスするためのオンラインストレージプラットフォームと説明している。ChatGPTは今回の主題に含まれる製品だが、公式記事はHabitatを複数のOpenAI製品向けの基盤として位置付けている。

12倍高速化はすべてのリクエストに当てはまりますか

OpenAIが示した数値は、全体的なグローバル読取p50を約120ミリ秒から約10ミリ秒へ改善したというものだ。キャッシュされていないデータの遠隔取得など、遅いリクエストが残ることも公式記事で明記されている。したがって、全リクエストが一律に12倍速くなったという意味ではない。

今後、OpenAIはAzure Cosmos DBを置き換えるのですか

OpenAIは、次の10億人規模に向けて、容量の大きいHabitatデータ型向けの独自オンラインストレージシステムを開発中だと述べた。このシステムはRockset由来のRocksDB CloudコアとRaftベースの複製を組み合わせる構想である。ただし、公式記事は既存基盤の全面移行時期や提供条件を示していない。

まとめ

OpenAIのHabitatは、Azure Cosmos DBの共有コンテナを中心に、ホットキー制御、QoS、改良サーバーレス、CDC連動キャッシュ、Rust化を組み合わせ、ChatGPTを含む製品群の大規模データアクセスを改善した。高速化の前提は、まずミッションクリティカルな信頼性を確立することだった点が重要である。

開発者とAI基盤担当者は、データベース選定そのものだけでなく、マルチテナントの負荷隔離、容量計画の責任分担、変更通知を使うキャッシュ無効化、クラウド事業者との共同障害対応までを設計対象として見直すべきだ。大規模化では、アーキテクチャと運用組織を切り離せないことを示す一次情報といえる。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。