OpenAIがHabitatストレージ基盤を公開：毎週10億人超の利用を支える規模と限界

2026年9月11日、OpenAIは公式エンジニアリングブログに「Rapidly scaling online storage to serve over 1 billion ChatGPT users」と題した記事を公開し、社内ストレージ基盤Habitatがこの数年でPythonクライアントライブラリから独立して稼働するサービスへと進化してきた経緯を説明しました。記事はEngineering（エンジニアリング）カテゴリーに分類され、著者として技術スタッフ3名、Jon Lee、Chaomin Yu、Ben Riesの名前が記載され、末尾にはエンジニア職の求人リンクが添えられています。これは新製品や新プランの発表ではなく、技術ブログの記事です。

本稿は2026年9月18日に、OpenAIの公式記事原文、OpenAIの公式ニュースRSSフィード、公式サイトマップのEngineeringカテゴリーページを確認しました。openai.comの記事ページは、それ以前の数日間はアクセス制限ページしか返さないことがありましたが、本稿の確認日には本文を直接読むことができました。以下の数字はすべてOpenAI自身の説明であり、当サイトは独自の検証を行っておらず、購入や利用に関する助言も行いません。本稿では架空の生活場面は使用していません。

この記事は何か：新製品の発表ではなく、エンジニアリングブログの記事

OpenAIはこの記事をEngineering（エンジニアリング）カテゴリーに分類し、Habitatを自社で構築したオンラインストレージ基盤だと説明しています。これにより傘下の製品は必要なデータを素早く確実に取得できるとしており、ユーザーがログインする、Codexの設定を確認する、ChatGPTで新しい会話を始めるといった動作の裏側では、いずれも複数回のデータ照会が発生しうるとしています。OpenAIは、こうした照会が遅くなれば製品自体が遅く感じられ、照会が失敗すれば製品はそのまま動かなくなる、と述べています。

記事冒頭の統計ボックスには、毎秒7000万件超のリクエスト、毎週10億人超の利用者、500PB超のデータ量という3つの数字が並んでいます。OpenAIの説明によると、Habitatはもともと2023年のDevDayでGPTsを支えるために登場し、当初は単一のデータベースに接続するだけのシンプルなPythonクライアントライブラリでしたが、現在では複雑な分散システムへと成長しています。

記事の末尾にはエンジニア職の求人リンクが添えられており（URLにはシアトルの地名が含まれています）、これはストレージをテーマにした2本シリーズの第1弾です。第2弾ではマルチテナントの信頼性、読み取り性能の階層化戦略、Azure Cosmos DBとの協業をどう拡大したかを説明する予定です。公式サイトマップとニュースフィードを2026年9月18日まで確認した限り、第2弾に該当する項目はまだ見当たらず、日付も発表されていません。

OpenAIが語る規模：いくつかの数字をあわせて読む

OpenAIは記事本文で、Habitatは現在毎秒7000万件を超えるリクエストを処理し、傘下の製品は毎週10億人を超える利用者に使われており、対応地域は40地域近くに及ぶと述べています。記事は対応地域の国名や都市名は挙げておらず、「簡略化」したものだと自ら記す模式図の中に、us0、us1、eu0という3つのサンプルのデータベース識別子が登場するのみです。これは図中のラベルであり、公表された地域一覧ではありません。

注意したいのは、OpenAIの公式RSSフィードとページのメタデータには別途「22M requests per second」と記載されている点です。しかし本稿が確認当日に本文全体を読み直したところ、この数字は要約とメタデータにしか登場せず、本文では一度も触れられておらず、7000万や2000万との関係も説明されていません。

OpenAIはまた、過去3年間は前年比で10倍を超える成長を続けてきたとも説明しています。記事本文には、システムエンジニアは通常、現状の10倍の規模を見込んで設計し、それが数年もつことを期待しながら、次の10倍にも備える、という一文があります。

なぜ1件の遅いクエリをユーザーは体感できるのか

OpenAIの説明によると、一般的なユーザーの1回のリクエストの裏側で数百回のデータベース呼び出しが発生する場合、ユーザーが体感するのはその中で最も遅い1回です。記事はこうした「テールレイテンシ（tail latency）」（ごく一部の特に遅いクエリ）を管理することを、この規模でPythonサービスを運用するうえでの主な課題と呼んでいます。

記事は1つの事例を挙げています。Habitatは機能フラグを管理するツールStatsigを使っており、既定では時間差を設けずに1分ごとに更新後の設定をポーリングします。その設定には全サービスの全ての本番環境ルールが含まれています。これに「1つのPodにつきPythonプロセスは最大8つまで」というアーキテクチャ上の決定が重なった結果、毎分、各Podであるひとつの瞬間に、すべてのワーカープロセスが処理中のリクエストを止め、代わりにその巨大な設定ファイルの解析にCPUを使う、という状態になりました。OpenAIによると、CPUプロファイリングで根本原因を特定できれば対処はシンプルで、対象範囲をより狭くした設定を配信し、ポーリング間隔を延ばし、こうしたバックグラウンド処理にランダムな時間差を加えればよいとのことです。

もう1つの事例はコネクションプールに関するものです。OpenAIによると、Pythonのaiohttpライブラリは既定で、直近に解放されたコネクションを優先的に再利用する仕様になっており、これは通常は妥当な既定値です。しかしリクエストが急増すると、遅く既に過負荷になっているサーバーほどコネクションをプールに返すタイミングが遅れるため、かえって後続のリクエストに選ばれやすくなり、トラフィックが徐々にすでに苦しんでいるPodに集中していきました。OpenAIはこれを一種の「準安定故障（metastable failure）」と呼んでいます。過負荷を引き起こしたクライアントが止まった後も、一部のプロセスは悪化し続け、再起動して初めて回復するという現象です。最も早く解放されたコネクションを優先する方式に変更したところ、フィードバックループが解消されただけでなく、定常状態でのリクエスト量のばらつきも小さくなりました。現在、この種のコネクション管理の大部分はIstioとEnvoyが担っています。

OpenAIがこの記事で説明していないこと

本稿が英語の原語で逐語的に照合したところ、記事にはdurability、backup、replicaという単語は登場せず、1件のデータが何個の複製（レプリカ）として保持されるかも書かれていません。OpenAIが説明しているのは、最も重要なデータセットを複数地域に分散したAzure Cosmos DBのアカウントへ移そうとした経緯を1度述べている点だけで、単一地域の障害が及ぶ範囲を縮めるためだとしていますが、それ以上の保存や冗長化の仕組みについては説明していません。記事には可用性の数字やサービス品質保証（SLA）の記載もなく、自社システムで実際に起きたいくつかの状況を説明しているだけです。例えば、あるチームが無関係の理由から問題のあるクライアントを含む旧バージョンへ自分たちのサービスをロールバックしてしまい、かえって回避しようと力を尽くしていたはずの障害を引き起こした、というものですが、日付や継続時間、ユーザーへの実際の影響は示されていません。

地域については、記事は40地域近くとしか書いておらず、いかなる国名や都市名もデータの保存場所として挙げておらず、台湾やアジアにも触れていません。地域情報にもっとも近いのは、模式図にある3つのデータベースコードと、求人リンクのURLに含まれる都市名です。記事はまた、Habitatが実際に何のデータを保存しているかについても明言していません。ログイン、Codexの設定確認、新しい会話の開始はいずれもデータ照会を伴う可能性があるとしていますが、会話の内容そのものがHabitatに保存されているかどうかは明言せず、ここが外部・内部・エージェントによる不正アクセスからユーザーデータを守る重要な場所だ、とだけ述べています。

Rustへの書き直し後の数字についても同様です。OpenAIは自社データによると、新バージョンはCPU効率が6倍、メモリ効率が15倍になり、平均レイテンシとテールレイテンシのいずれも大幅に下がったとしており、現在は本番環境のリクエストの95%を処理し、今後数週間以内にPython版を完全に廃止する計画だとしています。OpenAIはまた、今後さらに詳しい知見を共有する記事を出す予定だとしていますが、この続報についても日付は発表されていません。記事にはテスト方法やテストのシナリオ、第三者による検証は付されておらず、これらの数字は現時点ではOpenAIが自ら公表した社内計測結果とみなすほかありません。

読者はこの記事をどう受け止めればよいか

この記事は新製品、新プラン、新しい対応地域、新しい設定のいずれも発表しておらず、ChatGPTやCodexの利用者がこれを理由に何かを変える必要はありません。OpenAI自身も記事の中で、ユーザーが速さやコストの面で何かを体感できるとは主張しておらず、書き直しの効果は今のところOpenAI社内の説明にとどまっています。

この記事はむしろ、次のことを思い出させてくれるものとして読むのがよいでしょう。どのサービスの裏側にも、それぞれ独自のストレージと可用性の設計があり、運営者自身が公表する規模の数字は、リクエスト数であれ利用者数であれ成長倍率であれ、第三者による検証がない限りは、あくまでその事業者自身の説明にすぎません。読者は、こうした記事が耐久性やサービス品質保証、障害の詳細に触れているかどうかに注目するとよいでしょう。それは往々にして、単一の目を引く数字よりもサービスの安定性をよく表しています。

続報を自分で確認したい読者は、OpenAIのニュースRSSフィードと、Engineeringカテゴリーのサイトマップという2つの無料の公式チャネルを自分で確認できます。本稿もこの2つのチャネルを使って、第2弾がまだ公開されていないことを確認しました。なお、サイトマップに記載されている時刻はページに印字された公開日とは一致しておらず、記事の公開日や更新日とみなすべきではありません。これは本稿の確認当日にわかったことです。

2026年AIニュース総まとめ：1月から9月までの重要動向と実生活への応用

OpenAIとBroadcomがJalapeñoチップを発表：公式が語る段階、役割分担、そしてまだ発表されていないこと

• AIツール
• アプリ・ソフト
• AIニュース