2026年9月11日、OpenAIは、同社製品のオンラインデータアクセスを支えるストレージ基盤「Habitat」が、どのように規模を拡大してきたかを解説するエンジニアリング記事を公開しました。
Habitatは、DevDay 2023で小さなPythonクライアントライブラリとして始まり、その後、独立したサービスへ移行しました。さらに現在はRust版への切り替えが進んでいます。
規模の拡大に合わせて、どの部分をいつ作り替えたのかを見ると、単純な言語性能の比較だけでは分からない判断の順序が見えてきます。
Habitatは小さなPythonライブラリから毎秒7000万件超を扱う基盤へ成長した
Habitatは、OpenAI製品が必要な情報へ高速かつ確実にアクセスできるようにするオンラインストレージプラットフォームです。ユーザーがログインしたり、ChatGPTで新しい会話を始めたり、Codexの設定を確認したりするとき、その裏側では複数のデータ取得が発生します。Habitatは、こうした処理を支える共通基盤です。
出発点は大規模な分散システムではありませんでした。DevDay 2023で、GPTを支えるための小さなPythonクライアントライブラリとして導入され、当初は単一のAzure Cosmos DBへ接続していました。製品チームは、スキーマ検索、ルーティング、認証、暗号化、シリアル化、リクエストの調整、接続プーリングなどを細かく意識せずにデータを扱えました。
その後、Habitatは急速に拡大します。OpenAIによると、現在は毎秒7000万件を超えるリクエストを処理し、約40地域で、毎週10億人以上が利用する製品を支えています。扱うデータ量は500PBを超えています。
OpenAIは、過去3年間に毎年10倍以上の成長を経験し、Habitatの構築と運用は「戦術的な決定と順序付け」の連続だったと説明しています。大規模化に合わせ、その時点で大きな制約となっている部分へ順番に手を入れてきたことが、その変遷から分かります。
最初の限界は性能ではなく「変更を全サービスへ届けること」だった
Habitatが最初に直面した大きな限界は、Pythonそのものの処理性能ではありませんでした。
2025年半ばになると、Habitatの機能が複雑になり、利用するOpenAI内部のサービスも増えたことで、クライアント側ライブラリとして互換性を保ちながら変更を配ることが難しくなりました。
OpenAIが挙げた例では、重要なデータを地域分散されたAzure Cosmos DBへ移すため、クライアント側に新しいルーティング処理を追加する必要がありました。変更を数十のサービスへ配り、各チームと調整するだけで数日かかり、確認用の追加機能や修正を入れるたびに、さらに数日を要しました。
最終的には、あるチームが別の理由でサービスを古いクライアントへ戻したことで、避けようとしていた障害が発生しました。
つまり、共有ライブラリのコードを改善できるかどうかよりも、変更を安全に全利用サービスへ行き渡らせられるかどうかが問題になっていたのです。
そこでOpenAIは、Habitatを独立したサービスへ移しました。これにより、デプロイ、可観測性、機能改善を中央で管理できるようになり、アクセス制御や監査ログ、基盤ストレージへのアクセス制限といったセキュリティやプライバシー面の制御も一か所へ集約できました。
OpenAIの事例からは、共有コードの性能そのものより先に、「変更を安全に反映する運用」が限界になる場合があることが分かります。
独立サービスにしても、OpenAIはすぐPythonを捨てなかった
Habitatを独立サービスにすると、別の問題も増えます。
OpenAIは、Pythonを高スループットのサービスとして使うことで、ローカルのライブラリとして動かす場合よりネットワーク遅延が増え、CPUやメモリの負担も大きくなると認識していました。さらに、将来100倍規模まで拡大すれば、Pythonの非効率は許容できなくなるため、いずれ全面的な書き換えが必要になる可能性が高いと考えていました。
それでも、独立サービス化と同時にPython以外の言語へ全面移行することは選びませんでした。
当時の優先課題は、コストや計算資源の最適化ではなく、製品開発者が抱える制約を減らし、Habitatの中核APIを固め、プラットフォームを安定させ、基盤を整えることだったためです。OpenAIは、Pythonサービスの性能上の不利を、短期的に意図して受け入れる技術的負債として説明しています。
ここで重要なのは、「構成を変える判断」と「実装言語を変える判断」が分離されていたことです。
Habitatでは、まず各サービスに散らばっていた変更の制御点を一つに集めました。そのうえで、独立サービスとしてのAPIや運用を安定させながら、計算効率の問題へ段階的に取り組んでいます。
Pythonを延命するため、コードだけでなく「仕事をさせる場所」を変えた
OpenAIはPython版Habitatをそのまま放置したわけではありません。全面的な言語移行を先送りする間、ボトルネックごとに処理方法や責務の置き場所を変えています。
asyncioでは、1プロセスに仕事を詰め込みすぎない
Pythonのasyncioは、データの送受信などを待つ間に別の処理を進められる仕組みですが、CPUで複数の処理を並列実行する仕組みではありません。
Habitatでは、ルーティング、圧縮、暗号化、チェックサム、下流サービスの状態確認などCPUを使う処理も多く、負荷が高まると、処理可能になったリクエストが再開されるまで待たされる問題が起きました。これは、ごく遅い一部のリクエストの待ち時間である「テールレイテンシ」を悪化させます。
OpenAIは、1プロセスが同時に抱えるリクエスト数を小さく抑え、その代わりに多数のPythonワーカープロセスへ水平展開する方法を取りました。
接続管理と負荷分散を基盤側へ寄せる
プロセスを増やすと、今度は接続数や負荷分散が問題になります。
OpenAIは、Pythonの接続プールがLIFO、つまり最後に戻ってきた接続を先に再利用する方式だったことで、遅いサーバーへ通信がさらに集中する現象を確認しました。これをFIFO、先に戻った接続から使う方式へ変更することで、負荷集中の連鎖を断ちました。
現在は、IstioとEnvoyを使った接続管理や負荷分散にも依存しています。またOpenAIはEnvoyを、接続の集約、HTTP/2への変換、レート制限、回路遮断などにも利用していると説明しています。
Envoy Projectの公式資料でも、コネクションプーリング、ロードバランシング、回路遮断、ローカル・グローバルのレート制限といった機能が示されています。
ここでのポイントは、Pythonプロセスの中だけで全問題を解こうとしなかったことです。接続や負荷制御の一部を基盤側へ移すことで、Python版を運用し続ける余地を作りました。
複雑な問い合わせをオンライン経路から分離する
Habitat自体も、できる仕事を意図的に絞っています。
任意のSQLを許可せず、単純で処理量を予測しやすいNoSQL APIを採用し、複雑な検索や分析が必要な場合は、変更データを別系統へ流してRocksetの二次ビューで処理します。
MicrosoftはAzure Cosmos DBについて、低遅延、高い伸縮性、高スループットが必要なオンライン用途に適している一方、OLAPなどの分析処理や、高度にリレーショナルなアプリケーションには適さないと説明しています。
これはOpenAIがCosmos DBを採用した理由そのものを示す資料ではありません。ただ、Habitatがオンライン処理を単純で予測可能な処理へ絞り、複雑な分析を別経路へ分けた設計を理解する補助材料になります。
Habitatの事例では、実装言語を書き換える前にも、同時実行数、負荷分散、接続管理、問い合わせの複雑さといった別の層を調整する余地がありました。
Rustへの移行は「Pythonでは動かなかったから」ではなく、基盤成熟後に行われた
Python版Habitatは、ピーク時に毎秒2000万件を超えるリクエストを処理していました。Pythonでは運用できなくなったため直ちにRustへ移った、という単純な経緯ではありません。
OpenAIはPythonからの書き換えを約1年間延期し、その間に、より緊急で影響の大きい課題へ取り組みました。
その後も成長が続き、HabitatはOpenAIで使用するCPUコア数が2番目に多いサービスになりました。プラットフォーム自体も成熟したため、OpenAIはPythonから移行する時期に来たと説明しています。
2026年第2四半期には、2人のエンジニアがCodexとGPT-5.5を使ってサービス全体をRustへ書き換えました。OpenAIの資料公開時点で、Rust版は本番環境のリクエストの95％を処理しています。
性能面では、Rust版はPython版と比べてCPU効率が6倍、メモリ効率が15倍高く、平均レイテンシとテールレイテンシも大幅に低下したとされています。
ただし、公開時点で移行は完全には終わっていません。OpenAIはPythonを今後数週間以内に完全廃止する予定としており、Rustへの書き換えに要した正確な期間や工数、金額ベースのインフラコスト削減額は示していません。
また、「2人のエンジニア、Codex、GPT-5.5で書き換えた」という事実から、AIだけが移行を可能にしたと断定することもできません。
自社ならどこで切り替える？ Habitatから整理できる3つの判断段階
Habitatの変遷を、他社でもそのまま再現すべき手順として扱うことはできません。一方で、OpenAIが何を問題として次の段階へ進んだのかを分けると、自社の基盤を見直す際の判断材料にはできます。
以下は、OpenAIが説明した変遷を基に、Focus4編集部が3段階の判断材料として整理したものです。
| 段階 | 当時の構成 | 表面化した問題 | OpenAIが選んだ変更 | 次の段階へ進む判断材料 |
|---|---|---|---|---|
| 1 | 共有Pythonライブラリ | 数十サービスへの変更展開、互換性維持、古い実装へのロールバック | Habitatを独立サービス化 | 変更を利用側へ安全に届ける負担が大きくなり、中央制御の必要性が高まった |
| 2 | Pythonの独立サービス | CPU・メモリ負荷、テールレイテンシ、接続数や負荷分散の問題 | Pythonを継続しつつAPI・運用を安定化し、負荷制御の一部を別層へ移した | まずサービス境界と運用基盤を固めることを優先し、言語移行を延期した |
| 3 | 成熟した大規模サービス | 成長継続に伴う計算資源の負担 | Rustへ全面書き換え | プラットフォームが成熟する一方で成長が続き、CPUコア使用量も大きくなった |
第1段階で確認したいのは、共有ライブラリの更新を利用側へ配る負担が、まだ管理可能かどうかです。利用サービスが増え、複数チームとの調整が常態化し、古いバージョンの混在が障害リスクになるなら、OpenAIが直面した問題に近づきます。
第2段階では、独立サービスにした後すぐ全面的な性能最適化へ進む必要があるとは限りません。Habitatでは、APIの確立、プラットフォームの安定化、接続管理や負荷分散の整備が先でした。
第3段階で、実装言語そのものを替える判断が前面に出ます。Habitatでは、プラットフォームが成熟した一方で成長が続き、OpenAI内でCPUコア使用数が2番目に多いサービスとなった段階で、Rustへの移行が行われました。
今回の資料から、「何ユーザーになったらRustへ移る」「毎秒何件を超えたらライブラリをサービス化する」といった固定の閾値は導けません。
Habitatから確認できるのは、変更管理の限界と、実行効率の限界は別々のタイミングで表面化し、それぞれ異なる手段で対処されたということです。大規模化したシステムを見直すときは、「遅いから全部書き換える」と一括りにせず、いま限界になっているのが変更の届け方なのか、サービス運用なのか、実行効率なのかを分けて考えることが、判断の出発点になります。
出典：OpenAI「Scaling online storage for over one billion ChatGPT users」
https://openai.com/index/scaling-storage-one-billion-users-part-one/
出典：Microsoft「Azure Cosmos DBとは何ですか？」
https://learn.microsoft.com/en-us/azure/cosmos-db/introduction
出典：Envoy Project「Architecture overview」
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/arch_overview
