OpenAI、週10億人超のChatGPT基盤を支えるストレージ「Habitat」のアーキテクチャ刷新を公開

要点

• OpenAIは、ChatGPTやAPIなど主要製品を支えるオンラインストレージ基盤「Habitat」の進化とスケーリング手法に関する技術ブログを公開した。

• Habitatは現在、世界約40リージョンにわたり、毎秒7,000万回以上のリクエストと500ペタバイトを超えるデータを処理している。

• 2023年の登場当初は単一データベースに接続するPythonライブラリだったが、社内サービスの急増に伴いクライアント配布方式の運用限界に直面した。

• 課題を克服するためストレージロジックを独立したサービスへ移行し、デプロイの一元化とセキュリティ統制を大幅に強化した。

• OpenAIは2026年9月11日、同社の公式エンジニアリングブログにおいて、各種AIサービスを支えるオンラインストレージプラットフォーム「Habitat（ハビタット）」のスケーリングに関する技術情報を公開した。同社の技術スタッフであるJon Lee氏、Chaomin Yu氏、Ben Ries氏が執筆したもので、急激なトラフィック拡大に対応してきたデータ基盤の変遷が解説されている。週10億人以上の利用者を抱える巨大システムにおいて、当初は簡素なPythonライブラリとして開発された基盤が、どのように大規模な分散サービスへと再設計されたのか、その経緯が明らかになった。

毎秒7,000万リクエストと500PB超のデータを処理する基盤

OpenAIが提供するChatGPT、API、Codexなどの製品群では、ユーザーのログインや設定確認、新規会話の開始といったあらゆる操作の裏で、多数のデータ検索が並行して実行されている。これらの処理が遅延または停止した場合、サービス全体の応答性や稼働に直結するため、高速かつ安定したデータアクセス基盤の存在が不可欠となる。

この重要な役割を担っているのが、同社が独自に構築したオンラインストレージプラットフォーム「Habitat」だ。公開された情報によると、Habitatは現在、世界各地の約40の地理的リージョンにおいて、毎週10億人以上のユーザーに対応している。処理規模は毎秒7,000万回以上のリクエストに達し、500ペタバイト（PB: ギガバイトの約100万倍に相当するデータ容量の単位）を超えるデータを管理しているという。

OpenAIのインフラ需要は過去3年間にわたり前年比10倍以上のペースで成長を続けており、一般的な「数年先の10倍を見越して設計する」アプローチでは追いつかない状況だった。そのため、既存スタックの限界まで効率を引き出しつつ、計算資源やストレージ容量の枯渇を防ぎながら基盤投資を進めるという、極めて迅速な判断と実装が求められたと説明されている。

データベース管理を抽象化するPythonライブラリとして誕生

Habitatはもともと、「製品開発を行うエンジニアがデータベース管理を意識する必要をなくす」という発想から開発がスタートした。初公開は2023年の開発者会議「DevDay」であり、当時はカスタムAIを作成・利用できる「GPTs」を支援するための小さなPythonクライアントライブラリとして実装されていた。

このライブラリは、ChatGPTのメインサーバーと連携し、内部的にMicrosoftの分散型データベース「Azure Cosmos DB」へアクセスする限定的な操作をサポートしていた。製品側のエンジニアは、スキーマ検索やデータのルーティング、認証認可、暗号化、シリアライズ（データの変換処理）、リクエスト制御、コネクションプーリング（データベース接続の再利用管理）といった複雑な仕組みを意識することなく、容易にデータの保存や取得が行えるようになった。

また、データがAzure Cosmos DB、キャッシュ、その他のストレージのどこに配置されているかを意識する必要もなく、OpenAI社内では中央からの強制なしに製品チームへ急速に普及していった。製品の要件に応じて、クライアント側でのキャッシュやデータ圧縮、暗号化などの機能を共有ライブラリへ追加することも容易に行われていたという。

ライブラリ配布方式の限界と運用上のトラブル

しかし、2025年半ばを迎える頃には、クライアントサイドのライブラリとして運用することに限界が生じ始めた。OpenAI社内のマイクロサービス数が増加し、Habitat自体のロジックも複雑化したことで、後方互換性を維持しながらプロトコルを変更することが極めて困難になったためである。

記事では具体的な事例として、単一リージョンの障害による影響範囲を抑えるため、重要なデータセットを複数リージョンのAzure Cosmos DBアカウントへ分散移行した際のエピソードが紹介されている。この変更を行うには、ライブラリ側に新たなルーティングロジックをフィーチャーフラグ（機能の有効・無効をコード変更なしに切り替える仕組み）付きで組み込み、全クライアントサービスへ配布した上でフラグを有効にする必要があった。

数十に及ぶサービスチームとの調整やデプロイには数日を要し、さらにシャーディング（データ分割）の正確性を確認するためのシャドーイング（本番トラフィックを複製してテストする手法）やバグ修正のたびに数日単位の作業が発生した。最終的にフラグを有効化できる段階に達したものの、あるチームが無関係な理由で旧バージョンのライブラリを含む環境へロールバックした結果、回避しようとしていたはずのサービス障害が発生してしまったという。こうした経験から、多数のサービスに散らばるクライアントライブラリを個別更新する方式は脆く、運用リスクが高いと判断された。

独立サービスへの移行による一元管理とセキュリティ統制

運用の分散によるリスクを削減するため、OpenAIはストレージロジックをクライアントから切り離し、独立した「Habitatサービス」として再構築することを決定した。

スタンドアロンのサービスとして中央集約したことで、デプロイ、オブザーバビリティ（システムの稼働状況を監視・把握する可観測性）、機能強化を一元的に制御できるポイントが確立された。これにより、個別サービスごとの煩雑なアップデート調整を行うことなく、中央での機能改善がOpenAIの全製品へ即座に反映される環境が整った。

さらに中央サービス化は、セキュリティとデータプライバシーの面でも大きな利点をもたらしている。Habitatサービスが単一のアクセス制御ポイント（チョークポイント）として機能することで、アクセス制御ポリシーの適用や監査ログの記録、Azure Cosmos DBなどのストレージリソースに対するアクセス制限を一元管理できるようになった。これにより、外部からの攻撃だけでなく、社内関係者や自律型AIエージェントによる不正アクセスからもユーザーデータを保護する重要な役割を果たしているという。

OpenAIは、一般的な配信基盤では珍しいPythonで書かれたサービスを、高い信頼性を持つストレージプラットフォーム層へと拡張したとしている。なお、今回の発表は全2回シリーズの第1部であり、今後はマルチテナント環境下での信頼性確保、読み取り性能向上のための多層最適化戦略、Azure Cosmos DBとのパートナーシップによる需要対応の詳細について公開する予定であるとしている。