ChatGPTの速さは、Habitatという見えない倉庫で決まる

1. ChatGPTの裏にある「見えない倉庫」の話

今回の発表は新機能ではなく、ChatGPTを支える土台の話です。OpenAIは、製品が必要なデータを素早く確実に取り出すための保存基盤「Habitat」が、毎秒7,000万件を超えるリクエストをさばき、40近い地域で動いていると明かしました。使う側が感じる「速い」「止まらない」は、この見えない倉庫の出来しだいです。

01 ログインひとつに、たくさんの問い合わせ

ChatGPTにログインする、Codexの設定を開く、新しい会話を始める。どれも一瞬の操作ですが、裏では何度もデータを探しに行っています。平均的なひとつのリクエストが、数百回のデータベース呼び出しにつながることもあるそうです。問い合わせが遅ければ製品は遅く感じ、失敗すれば製品そのものが止まります。

Habitatは、その問い合わせを一手に引き受ける仕組みです。データの種類を見分け、どこから取り出すかを決め、その要求が許されているかを確かめ、暗号化やキャッシュまで面倒を見ます。製品を作るエンジニアは、データベースの細かい事情を知らなくても、しまって、取り出せる。倉庫番がいるから、店員は接客に集中できる。

02 2年で、小さな部品が巨大な仕組みに

Habitatは2024年半ば、ChatGPTのメインサーバーとやりとりする小さなPythonのライブラリとして生まれました。ひとつのデータベースにつながるだけの、素朴な道具です。それがいまでは500ペタバイトを超えるデータを扱う分散システムになり、ChatGPTやAPI、Codex、社内サービスを支えています。

驚くのは規模より、伸びる速さです。システムの設計者はふつう10倍の成長に耐える形を作り、それが数年もつことを願うといいます。OpenAIは3年続けて前年比10倍を超える伸びを経験しました。家を建てている最中に、住む人が毎年10倍に増えていく。Habitatの歩みは、その中での判断の連続でした。

2. 速さは、いちばん遅い一回で決まる

使う人にとって大事なのは「平均の速さ」より「たまに待たされる一回」です。OpenAIは、数百回の呼び出しのうち最も遅いひとつを利用者が体感すると書いています。遅いと分かっているPythonのまま、その一回をどう抑えたかが記事の中心です。速さとは、待たせないという気づかいのことだ。

01 店員ひとりの店で、行列をつくらない工夫

Pythonの非同期処理（asyncio）は、たくさんの注文を同時に受け付けられても、実際に手を動かす店員はひとりです。Habitatは経路の判断や圧縮、暗号化など、手間のかかる仕事を多く抱えています。倉庫から品物がすぐ届いても、店員の手が空くまで待たされる場面が、遅いリクエストの記録に何度も現れていました。

OpenAIは、小さな作業を予約し、実際に始まった時刻とのずれを測って、この待ち時間を常に見えるようにしました。忙しいときは数百ミリ秒、まれに数秒のずれもあったといいます。そこで1つのプロセスが同時に抱える仕事を少なく保ち、代わりにPythonのプロセスそのものを大量に増やす道を選びました。

02 混んでいる窓口に、さらに人が集まる罠

もうひとつの発見は、接続の使い回し方です。PythonのaiohttpのTCPConnectorは、最後に戻ってきた接続を次に使う「後入れ先出し（LIFO）」が初期設定でした。ふだんは合理的ですが、処理の遅いサーバーほど接続を返すのが遅れるため、次の仕事がまたそこへ回り、弱ったサーバーに負荷が集まり続けていました。

一度崩れると自力で戻らないこの状態を、OpenAIは「メタステーブル障害」と呼んでいます。古い接続から順に使う「先入れ先出し（FIFO）」に改めると悪循環は断ち切られ、ふだんのばらつきも小さくなったそうです。いまはIstioとEnvoyが、負荷を見て振り分けています。混んだ窓口に人を吸い寄せない。それが止まらないサービスの条件でした。

3. できることを絞り、AIと書き直す

Habitatの設計には、暮らしにも通じる知恵が二つあります。ひとつは、できることをわざと少なくして、重たい依頼が紛れ込まないようにしたこと。もうひとつは、遅いと分かっていたPythonを「計算ずくの借金」として抱え、その返済をAIに託したことです。2026年第2四半期、その借金は返されました。

01 できないことが、止まらないことを守る

Habitatは、自由に組み立てられるSQLの検索を受け付けず、シンプルなNoSQLの窓口だけを用意しています。以前、OpenAIのデータの多くはPostgresにあり、チームが大きくなるにつれ、重い問い合わせひとつがデータベースを落とす障害がたびたび起きたといいます。書くのは簡単で、動かすのは高くつく。そのずれを断ったわけです。

複雑な検索が必要なチームには、変更データキャプチャ（CDC）でほぼリアルタイムに写し取ったRocksetという別の窓口を用意し、規模は各チームが自分で管理します。手間は増えますが、日々の読み書きと重い分析を切り離せます。何でもできる箱より、できることが決まった箱のほうが、壊れにくい。

02 借金と知っていて借り、AIで返した

サービス化した時点で、Pythonのままでは100倍の規模に耐えられず、いずれ書き直しになると分かっていました。それでもOpenAIは、コストより、製品開発を止めないことと安定を選び、戦略的な技術的負債として受け入れます。同時に、書き直しが必要になるころには、自社のCodexとGPTがそれを可能にしているはずだ、という賭けもしていました。

賭けは当たりました。2026年第2四半期、わずか2人のエンジニアがCodexとGPT-5.5を使い、サービス全体をRustで書き直しています。Python版は最盛期に毎秒2,000万件超を支え、社内でコア数が2番目に大きいサービスでした。いまは本番リクエストの95%をRust版が処理しています。AIの進歩を、工程表に組み込む。その発想が新しい。

4. 毎日のAIを選ぶ、新しい物差し

使う側がやることは、何もありません。Habitatはサーバー側の仕組みで、発表の中に利用者が操作する項目は出てきません。ただ、AIを選ぶときの見方はひとつ増やせます。賢さの比較だけでなく、止まらず、待たせず、データを守る土台にどれだけ手をかけているか。今回の発表は、その手のかけ方を具体的に見せてくれました。

01 改良が、全部の製品に一度に届く形

サービス化のきっかけは、ライブラリのままでは変更のたびに数十のサービスと足並みをそろえ、何日もかかっていたことです。調整の途中で、あるチームが無関係な理由で古い版に戻し、防ぎたかった障害が起きたこともありました。一か所にまとめたいまは、改良を入れればOpenAIのすべての製品にすぐ行き渡る設計です。

もうひとつ見逃せないのが守りです。Habitatは、アクセス権のルールを一か所で徹底し、操作の記録を残し、Azure Cosmos DBなど元の保管場所への出入りを絞る関所の役目も担います。外部からも、内部からも、そしてAIエージェントからも、許可のない読み出しを防ぐ。会話を預ける側には、ここがいちばん効く話です。

02 作る人は、明日の仕事に三つ持ち帰れる

サービスを作る側の読者には、そのまま持ち帰れる教えが三つあります。CPUやメモリだけでなく、非同期処理の待ち行列がどれだけ詰まっているかを測ること。接続の使い回し方を疑うこと。そして、便利すぎる窓口を最初から開けないこと。どれも派手さはないのに、10億人規模の現場で使われてきた考え方です。

台所に置き換えるなら、火力より段取り、道具の数より片付けやすさ。いい仕組みほど、目立たないところで働いています。次にChatGPTの返事がすっと返ってきたら、その裏にいる倉庫番の仕事を思い出してみてください。KPEは、読み出しの工夫を描く続編も追いかけます。

5. よくある質問

6. まとめ