過去 1 年間で、Codex と Sora はどちらも急速に採用され、その利用は当初の予想を超える勢いで急増しました。そこには一貫したパターンが見られました。ユーザーはすぐに使い始め、実際の価値を見出し、その後でレート制限に直面します。
レート制限は需要を平準化し、公平なアクセスを確保するのに役立ちますが、ユーザーが価値を得ているときに制限に達すると、フラストレーションを感じることがあります。私たちは、システムのパフォーマンスと当社のアプローチに対するユーザーの信頼を守りながら、ユーザーが継続して利用できる方法を模索しました。
この問題を解決するために、使用状況をリアルタイムでカウントするアクセスエンジンを構築しました。そのエンジンのレイヤーの一つは、クレジットを購入する機能です。ユーザーがレート制限を超過した場合でも、クレジットを使用して残高を消費することで、当社の製品を引き続き利用できます。
この下には、上限、リアルタイムの使用状況の追跡、クレジット残高を単一のアクセスモデルに統合した複雑なシステムが存在します。この投稿では、Codex と Sora のスケーリングにおいてアクセス制御を再考する必要があった理由、正確さが証明されたリアルタイムシステムがリクエストごとにレート制限とクレジットをどのように組み合わせるか、そしてその基盤が現在、両製品に対して追加のアクセスをどのように可能にしているかを説明します。
全体的に見ると、従来のアクセスモデルでは選択を強制する傾向があります。
- レート制限は最初は役立つこともありますが、上限に達するとユーザーに悪い体験を残します。「後で戻ってきてください」
- 使用量ベースの課金は柔軟性がありますが、ユーザーは最初のトークンから支払いを始めることになり、初期の調査を支援するには理想的ではありません
Codex と Sora のどちらも、単独では十分ではありませんでした。単にレート制限を引き上げると、需要の平準化や公平性を保つための重要な制御が失われ、全員にサービスを提供するための容量が不足する可能性があります。非同期の使用量課金に全面的に依存すると、遅延や超過料金、照合の問題が発生します。これらは、ユーザーが最も熱心に利用しているときに特に気づく種類の問題です。
代わりに私たちが必要としていたのは、リアルタイムの制限と従量課金アクセスを組み合わせた単一のハイブリッドシステムでした。
このシステムは次のことを行う必要がありました。
- 制限に達するまでレート制限を適用する
- 同じリクエスト内でシームレスにクレジットに移行する
- リアルタイムでその決定を下す
- クレジット消費を追跡する際は、厳密に正確で監査可能であることを心がけてください
私たちが行った重要な概念的転換の1つは、アクセスを意思決定のウォーターフォールとしてモデル化することでした。「これが許可されているか？」と尋ねるのではなく、私たちは「どの程度まで許可されていて、どこから始まるのか？」と尋ねます。使用量を計算する際、システムは次の順序で処理を実行します。
このモデルは、ユーザーが製品を実際にどのように体験しているかを反映しています。レート制限、無料利用枠、クレジット、プロモーション、エンタープライズの権利は、すべて同じ意思決定スタックのレイヤー（層）にすぎません。ユーザーの視点から見ると、彼らは「システムを切り替える」のではなく、単に Codex と Sora を使い続けます。クレジットが目に見えないように感じられるのはそのためです。それはウォーターフォールの中の単なる一要素にすぎません。
私たちはクレジット消費を管理するために、サードパーティの使用量課金および計測プラットフォームを評価しました。これらは請求書発行とレポート作成には適していましたが、以下の2つの重要な要件を満たしていませんでした。
ユーザーが制限に達し、クレジットが利用可能な場合、システムは即座にそれを認識する必要があります。ベストエフォートまたは遅延カウントは、予期しないブロック、一貫性のない残高、不正確な請求として現れます。Codex や Sora のようなインタラクティブな製品では、そうした失敗が目に見え、苛立たしさを感じさせます。
また、すべての結果に対して透明性を確保する必要がありました。
- リクエストが許可された理由またはブロックされた理由
- どのくらい使用されたか
- どの制限または残高が適用されたか
この機能は、起きていることの一部しか見えていない別の利用量課金プラットフォームで個別に解決するのではなく、当社の意思決定のウォーターフォールにしっかりと統合する必要がありました。ユーザーが信頼を損なうことなく当社の製品にアクセスできるようにするためには、正確性、タイミング、可観測性を完全に管理する必要がありました。それが、私たちを社内ソリューションの導入へと向かわせました。
これを実現するために、同期アクセスの決定に特化した分散型の使用状況および残高管理システムを構築しました。
大まかに言うと、システムは次のようになります。
- ユーザーごと、機能ごとの使用状況を追跡する
- レート制限ウィンドウを維持する
- リアルタイムでクレジット残高を維持する
- ストリーミング非同期プロセッサーを使用して残高を冪等的に引き落とす
すべてのリクエストは単一の評価パスを通過します。この評価パスでは、レート制限を同期的に消費し、必要に応じて十分なクレジットを確認することで、許可される使用量をリアルタイムで判断します。その後、クレジットの差し引きを非同期で確定し、最終的に1つの確定した結果を返します。これにより、製品全体で一貫した動作が保証され、チーム間で重複するロジックが排除されます。
このシステムの設計原則の一つは、請求が正しいことを証明できなければならないということです。これは、法人のお客様から始まった当社の信用サポートのルーツを反映しています。上記のシステム図には、以下のような互いに関連する3つの独立したデータセットがあります。
- 製品使用イベント： ユーザーが実際に行ったこと
- 収益化イベント： ユーザーの利用に対して課金する内容
- 残高更新： ユーザーのクレジット残高をいくら調整したか、またその理由
これらのデータセットは単なる副産物ではなく、システムを実際に駆動し、各データセットが次のデータセットを引き起こします。発生した事象、関連する請求、および当社が引き落とした内容を分けることで、各レイヤーを独立して監査、再実行、照合することができます。これは意図的なトレードオフであり、クレジット残高の更新がわずかに遅れるという代償を払いつつ、証明可能な正確性を優先しています。どのようにこれを達成したのでしょうか。
- 製品の使用イベントは、クレジット消費を促すかどうかに関係なく、すべてのユーザー活動に対して公開されます。これによりユーザーアクティビティの監査証跡が提供され、当社がクレジットを請求した理由や請求しなかった理由を説明することができます。
- すべてのイベントには安定した冪等性キーが付与されているため、リ再試行、リプレイ、またはワーカーの再起動によって残高が二重に引き落とされることがなく、二重請求を防止できます。これによりバッチ照合を実行して、作業をオフラインで検証することもできます。
- 当社は監査証跡を作成するために、同期更新ではなく、非同期（ただし、ほぼリアルタイム）の残高更新を行っています。当社は、システムが正常に機能していることを証明し、ユーザーに誤請求していないことを保証するために、ユーザーの残高更新に若干の遅延が生じることを許容しています。その短い遅延によってユーザーのクレジット残高を超過してしまった場合、当社は自動的に返金します。当社は厳格な執行よりも、証明可能な正確さとユーザーの信頼を重視しています。
- 単一のアトミックデータベーストランザクションで、クレジット残高を減らし、残高更新レコードを挿入します。残高の更新はアカウントごとにシリアライズされているため、同時に送信されたリクエストが同じクレジットを消費する競合が生じることはありません。残高更新レコードには、借方金額と、更新をトリガーした収益化イベントへの帰属の両方が含まれます。これを単一のデータベーストランザクションにラッピングすることで、クレジット残高に対するすべての調整の監査証跡が確保されます。
この厳格さはすべて、1 つの目的を支えています。アクセスをシンプルかつ安全にすることです。人々が何かを作成またはコーディングしている際に、リクエストが通るかどうか、過剰請求されないか、残高が正確かどうかを心配する必要はありません。使用状況、請求、残高を証明可能な形で正確にすることで、ユーザーの体験を妨げないシステムを提供します。これにより、私たちは硬直した停止を継続的なアクセスに置き換えることができ、クレジットは請求書上だけでなく、実際の作業中にも利用可能になります。
当社のアプローチの基本方針は、ユーザーの流れを維持することです。すべてのアーキテクチャ上の決定は、ユーザーに見える結果へと結びつきます。リアルタイムの残高は不要な中断を防ぎ、アトミックな消費は二重請求を防ぎ、統一されたアクセスロジックは予測可能な動作を保証します。その結果、人々は強制的な中断や早期の計画変更に直面することなく、より長く働き、より深く探求し、プロジェクトをさらに進めることができます。
ユーザーがシステムに関与しているときは、システムはユーザーがそのまま続けられるように支援し、邪魔をしないようにすべきです。制限とクレジットは背景に消えます。
その体験を構築するには、アクセス、利用、請求を一つのシステムとして見直し、正確さを最優先の製品機能として扱うインフラを構築する必要がありました。それと同じ基盤は、時間の経過とともにさらに多くの製品に拡張される可能性があります。Codex と Sora はその始まりに過ぎません。
