OPENAI SEARCH INSIGHT

2026.08.26 / OpenAI最新情報

OpenAI、ChatGPTを支えるPostgreSQLを800万人規模へ拡張

この記事で分かること: OpenAIがChatGPTの安定運用に向けてデータベースをどのように拡張し、利用者に何が関係するのかを知りたい。

OpenAIは2026年1月22日、ChatGPTとOpenAI APIを支えるデータベース基盤について、PostgreSQLを毎秒数百万件の問い合わせに対応できる規模へ拡張したと公表しました。読み取り中心の処理を分散し、障害時の連鎖的な負荷増加を抑える設計を重ねることで、世界規模の利用を支えていると説明しています。

一般のChatGPT利用者にとって、今回の発表は新しい操作や料金、利用条件の告知ではありません。一方で、質問への応答や履歴に関係するサービス基盤について、混雑時にも応答性と可用性を維持するための改善が進められていることを示す内容です。OpenAIは約8億人の利用者を支える規模で運用しているとしています。

OpenAIが公表したPostgreSQL拡張の概要

PostgreSQLは、データを整理して保存し、必要に応じて取り出すためのオープンソースのデータベースです。OpenAIによると、ChatGPTやOpenAI APIの中核製品を長年にわたり裏側で支える重要なデータシステムの一つです。過去1年間で、同社のPostgreSQLにかかる負荷は10倍超に増加したといいます。

OpenAIは、単一の主要書き込みサーバーと、世界の複数地域に配置した約50台の読み取りレプリカで構成する方式を採用しています。レプリカは、主サーバーのデータを複製し、主に読み取り要求を分担するサーバーです。この構成により、読み取り中心の大規模な処理を支えていると説明しました。

同社は、この基盤がChatGPTとAPIプラットフォームにおける読み取り中心の処理で、毎秒数百万件のクエリに対応していると公表しました。クエリとは、アプリケーションがデータベースに対して行う検索や更新などの要求を指します。今回の記事は製品機能の発表というより、サービスを支える運用技術の解説です。

利用者に関係する変化と、今日の使い方

利用者側でアプリを更新したり、設定を切り替えたりする必要があるとOpenAIは案内していません。今回の内容は、ChatGPTの回答品質を直接変更するものでも、新たなプランや提供地域を発表するものでもありません。通常どおりChatGPTを利用し、混雑や一時的な不調が起きた際には時間を置いて再試行することが基本になります。

OpenAIが重視したのは、急激なアクセス増加や内部処理の不具合が、サービス全体の遅延へ広がる事態を防ぐことです。データベースの処理が遅くなると、要求のタイムアウト後に再試行が増え、さらに負荷が高まる悪循環が起こり得ます。同社は、こうした連鎖を抑える仕組みを複数層で導入したとしています。

ただし、インフラが拡張されたことは、常に一切の遅延や障害が起きないことを意味しません。OpenAI自身も、過去にPostgreSQLの過負荷に起因する重大インシデントがあったと明かしています。利用中に応答が遅い場合、短い間隔で繰り返し送信すると混雑を増やす可能性があるため、過度な再試行は避けるのが実用的です。

読み取りを分散し、書き込み負荷を抑える設計

単一の主サーバーは全ての書き込みを受け持つため、急な更新処理の増加が弱点になり得ます。OpenAIは、可能な限り読み取りをレプリカへ逃がし、主サーバーに書き込み処理の余力を残す方針を採っています。書き込み処理の一部には、必要になるまで実行を遅らせる「遅延書き込み」も用いると説明しました。

特に書き込みが多く、横方向に分割できる処理については、Azure Cosmos DBなどの分散型システムへ移行を進めています。横方向の分割、すなわちシャーディングは、データや処理を複数の基盤に分けて負荷を分散する方法です。OpenAIは既存のPostgreSQL環境には新しいテーブルを追加しない方針も示しました。

既存の処理をPostgreSQLから分割構成へ移すには、多数のアプリケーション画面や処理経路の変更が必要になり、数カ月から数年かかる可能性があるとOpenAIは説明しています。そのため当面は、読み取り中心の現行構成を最適化しつつ、書き込み負荷の大きい処理を段階的に別システムへ移す考えです。

キャッシュ、接続管理、制限で急増を防ぐ

OpenAIは、頻繁に参照されるデータを一時保存するキャッシュを活用し、データベースへの読み取りを減らしています。キャッシュにデータがない「キャッシュミス」が突然増えると、多数の要求が一斉にデータベースへ届き、CPUを圧迫する恐れがあります。そのため、同じデータの取得は原則として一つの要求だけが行う仕組みを導入しています。

接続数の制御にも、PgBouncerという接続プール用ソフトウェアを使っています。接続プールは、データベースとの通信路を使い回す仕組みです。OpenAIのベンチマークでは、平均接続時間が50ミリ秒から5ミリ秒へ短縮したとしています。各地域で利用者に近い場所へ構成要素を置き、通信コストも抑えています。

さらにアプリケーション、接続プール、プロキシ、クエリの各段階でレート制限を実装しました。レート制限は、短時間に集中する要求量を制御する仕組みです。特定の処理が高負荷になった場合には、その処理を制限または遮断して、重要な処理への影響を広げない「負荷遮断」を可能にしたと説明しています。

障害時にも読み取りを維持するための対策

主サーバーが停止すると書き込みは失敗しますが、OpenAIは重要な要求の多くをレプリカで処理できるようにしているとしています。これにより、主サーバーに問題があっても、読み取りを含む一部の要求は継続でき、影響を小さくする狙いがあります。

主サーバーは高可用性モードで稼働し、常に同期した待機系サーバーを用意しています。障害や保守の際には待機系を主系へ切り替え、停止時間を抑えます。また、各地域に複数のレプリカと余力を置き、レプリカ1台の故障が地域全体の停止につながらない構成を目指していると説明しました。

OpenAIは、低優先度と高優先度の要求を別々のインスタンスへ振り分ける「ワークロード分離」も実施しています。新機能の処理などが想定以上のCPUを使っても、重要度の高い要求まで遅くならないようにする対策です。製品やサービスの間でも同様に分離し、あるサービスの急増が別サービスへ波及しないようにしています。

性能指標と今後の技術課題

OpenAIは、約50台の読み取りレプリカを追加しながら、複製の遅れをほぼゼロに保ち、地域分散環境でも低遅延の読み取りを維持したとしています。運用上の実績として、クライアント側の99パーセンタイル遅延は一貫して十数ミリ秒台、可用性は「ファイブナイン」としており、後者は年間の稼働率がおおむね99.999%水準であることを表す指標です。

一方、レプリカを増やすほど、主サーバーから各レプリカへ更新ログを送る負担も増えます。OpenAIはAzure PostgreSQLチームと、途中のレプリカが下流のレプリカへ更新を中継する「カスケード複製」を検証中です。100台を超えるレプリカへの拡張可能性を見込む一方、これはまだテスト段階で、本番導入は明言されていません。

過去12カ月のPostgreSQL関連の最重大インシデントは1件だったとOpenAIは説明しています。この事案はChatGPT ImageGenの急速な立ち上がりで書き込み量が急増した時期に発生し、1週間で1億人超の新規利用者が登録したことに伴い、書き込みトラフィックが10倍超へ増えたとしています。

Agent Memories編集部の考察

今回の公式発表から読み取れるのは、ChatGPTの規模では、単にサーバーを大きくするだけでなく、処理を「読む」「書く」「優先度が高い」「負荷が高い」といった単位で分ける運用が重要になるという点です。これはOpenAIの説明に基づく編集部の整理であり、将来のChatGPT機能や提供条件を予測するものではありません。

一般利用者が意識すべき実務上のポイントは、サービスの遅延時に連続送信や短時間の再試行を重ねないことです。OpenAIも再試行の集中が負荷を増幅し得ると説明しています。重要な入力内容は送信前に控えを残し、応答に失敗した場合は少し間隔を空けてやり直すと、作業内容を守りやすくなります。

また、今回の発表はOpenAIが大規模基盤を継続的に見直していることを示しますが、個々の利用者が常に同一の応答速度を得られる保証ではありません。ネットワーク状況、アクセス集中、機能ごとの処理特性などによって体感は変わり得ます。公式に案内されていない新機能の提供時期や対象範囲を、この技術発表から補うことはできません。

よくある質問

今回、ChatGPTに新しい機能は追加されますか？

OpenAIが公表した内容は、ChatGPTとAPIを支えるデータベース基盤の拡張・最適化です。公式発表の範囲では、利用者向けの新機能、価格改定、プラン変更、提供地域の変更は示されていません。

利用者は設定変更やアプリ更新を行う必要がありますか？

必要な操作は案内されていません。今回の取り組みはOpenAI側のインフラ運用に関するものです。通常どおりChatGPTを使えますが、障害や混雑が発生した際には、再送を連打せず時間を置くことが望ましいでしょう。

PostgreSQLを使えば、どのサービスでも同じ規模に拡張できますか？

OpenAIは、読み取り中心の大規模処理においてPostgreSQLを拡張できたと説明しています。ただし、その背景には多数のレプリカ、キャッシュ、接続管理、レート制限、処理分離、専用の運用設計があります。単一の技術だけで同じ結果が得られるという発表ではありません。

書き込みが多い処理は、今後すべてPostgreSQLから移行しますか？

OpenAIは、分割可能で書き込み負荷の高い処理をAzure Cosmos DBなどへ移行済み、または移行中としています。残る処理の移行も進める方針ですが、全ての移行完了時期やPostgreSQLの将来的なシャーディングについて、確定した計画は公表されていません。

まとめ

OpenAIは、ChatGPTとAPIを支えるPostgreSQL基盤について、レプリカ、キャッシュ、接続プール、レート制限、優先度別の処理分離を組み合わせ、毎秒数百万件の要求に対応していると公表しました。利用者に新たな操作は求められませんが、安定性を支えるための継続的な基盤改善が進んでいることが今回の要点です。

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