OpenAI、Codexの修正により利用可能量が最大50%拡大すると説明

OpenAIによると、エンジニアが利用量を消費する複数のバグを修正したことで、Codexユーザーは従来より10%から50%多く利用できるようになるはずだという。Google Newsを通じて広まったこの更新には、有料のCodexおよびChatGPT Workユーザー向けのリセットも含まれていた。この組み合わせは一見すると単純な利用可能量の増加に見えるが、見出しの数値は複数の異なる修正と大きく変動するワークロードを対象としている。

この区別は重要だ。OpenAIは、一律で50%のクォータ増加を発表したわけではない。改善幅は各ユーザーのCodexの使い方に左右されるとしている。画像を多用するセッションを実行する人と、暴走したゴールの影響を受けたユーザーとでは、まったく異なる結果になる可能性がある。

この更新は、利用可能量が予想より速く減るという数か月にわたる不満を受けたものだ。一部の報告は個別アカウントへの制限に関するものだったが、不要なモデルループ、繰り返されるツール呼び出し、過度に頻繁に実行される自動化スケジュールを指摘するものもあった。OpenAIは現在、利用量を無駄にし得る複数のメカニズムを認めているが、全体的な改善を再現可能な形で示すベンチマークは公表していない。

したがって主な対立軸は、OpenAIと別のコーディング支援ツールの比較ではない。OpenAIの効率化に関する約束と、ユーザーがCodexの利用量計測をどこまで可視化できるかという限界の間にある。同社は具体的な問題を修正したとしているものの、顧客は依然として、クォータの変動すべてをモデル応答、ツール呼び出し、バックグラウンドワーカー、または失敗した自動化に個別に結び付けることはできない。

OpenAIがCodexで修正したと説明する内容

今回の更新は、単純な請求ミスやアカウント上限の一律拡大ではなく、無駄なエージェント活動を対象としている。

OpenAIのエンジニアリング責任者であるThibault Sottiaux氏は、同社が数千件の報告を確認し、一連の修正をリリースしたと述べた。同氏の利用量に関する更新の公開転載には、コンテキスト圧縮、メモリワーカー、ゴール、自動化、サブエージェントに関する問題が挙げられている。

コンテキスト圧縮とは、エージェントが利用可能なコンテキストウィンドウ内で処理を続けられるよう、長い会話を短縮するプロセスだ。Sottiaux氏によると、このプロセスでCodexが古い画像を保持してしまうことがあった。そうした画像によりコンテキストが大きくなり、再び圧縮サイクルが発生する可能性があった。

OpenAIは、この挙動を修正したことで、画像を頻繁に扱うユーザーの利用量が約10%減少したと見積もっている。この層には、スクリーンショット、ブラウザーの状態、デザイン参照、視覚的なテスト失敗をCodexに調査させる開発者が含まれ得る。

メモリの問題は影響範囲がより狭い一方、長期的な影響はより深刻だった。バックグラウンドのメモリワーカーが停止フックを継承することがあり、これはエージェントが完了しようとした際に実行されるルールである。完了を妨げるフックがあると、ワーカーは停止を許可されているかどうかを繰り返し確認し続ける可能性があった。

OpenAIによると、影響を受けたユーザーは1%未満だった。ただし同社は、停止可能かどうかを15,000回確認したスレッドを1件発見したと報じられている。この例は、表面的にはまれなオーケストレーションのバグであっても、相当量の利用可能量を消費し得る理由を示している。

ゴールも別の失敗モードを生んでいた。設定されたゴールが完了しても、エージェントが意図した停止点を越えて処理を続ける場合があった。Codexは、処理がもはや有益でないことを認識せず、壊れたツールの再試行を続けることもあった。

OpenAIによると、確認された例では週間利用可能量の15%から70%が消費されていた。この範囲は平均値ではなく、そのように読むべきでもない。これは、システムが適切に作業を停止できなかった問題のある裾野で見られた事例を示している。

カスタム自動化も、設定されたスケジュールより頻繁に実行される可能性があった。監視されていないタスクが過度に発火すると、消費が発生した時点でユーザーが確認していない可能性があるため、診断は特に難しい。

サブエージェントの修正はモデル選択に関するものだ。サブエージェントとは、より大きなタスクの委任された部分を処理する補助エージェントである。OpenAIによると、Lunaを含む小規模モデルが、ユーザーが要求していないにもかかわらず、より高性能なヘルパーを選択する場合があった。

より高性能なヘルパーは、ユーザーが実行を想定していたモデルとは異なる形で利用可能量を消費する可能性がある。この挙動を修正すればタスク実行の予測可能性は高まるはずだが、OpenAIはサブエージェントの変更について個別の削減見積もりを公表していない。

これらは技術的には別個のバグだ。あるものはコンテキストを肥大化させ、別のものはワーカーの終了を妨げ、また別のものはゴールの境界を無視し、さらに別のものは自動化の実行頻度を高めた。これらを10%から50%という見出しにまとめると発表は理解しやすくなるが、その下にある大きなばらつきは隠れてしまう。

付随するリセットも解釈をさらに複雑にする。リセットは利用可能量を更新する一方、効率化の修正は今後の作業がそれをどれだけ速く消費するかを変える。両方の変更を同時に受けたユーザーは、更新前と直後のダッシュボードを比較しても、エンジニアリング上の改善を評価できない。

Google Newsの見出しを慎重に読むべき理由

「最大50%多く利用可能」という表現は、すべての有料Codexアカウントに保証された増加ではなく、好条件のワークロードで得られる結果を示している。

Google Newsを通じて流通している報道は、OpenAIの公開声明における上限値を正確に反映している。ただし、「最大」という表現には常に分母が必要だ。読者は、どの利用指標が改善したのか、どのモデルがテストされたのか、どのタスクパターンで最大の効果が得られたのかを知る必要がある。

OpenAIは、すべてのアカウントが週間利用可能量を50%多く受け取ったとは述べていない。また、従来の利用可能量が1.5倍になったことを示す単純な一覧も公表していない。この主張はむしろ、複数の無駄の原因を取り除いた後に、既存の利用可能量でどこまで作業を進められるかに関するものだ。

この違いは仮想的な例で明確になる。あるワークロードが以前は不要な圧縮サイクルを引き起こしていた場合、それを修正すれば、同じ利用可能量でより多くの有益な作業を支えられる。名目上の上限は変わらなくても、実効的な容量は改善する。

別のユーザーは、そのバグに一度も遭遇していないかもしれない。その場合、同じ修正による改善はほぼゼロに近い。そのユーザーもゴール、ツール、サブエージェント、待機動作の変更から恩恵を受ける可能性はあるが、それはワークフローがそうした経路に到達した場合に限られる。

OpenAI自身のCodexガイダンスでは、消費量はモデル、タスクの複雑さ、コンテキスト、推論、速度、ツールに左右されるとしている。Codex、ChatGPT Work、その他の対象となるエージェント機能は、共有の利用可能量およびクレジットプールから消費する場合もある。

この共有システムにより、気軽な比較は信頼できないものになる。別のエージェント機能が寄与していたにもかかわらず、ユーザーはダッシュボードの変化をCodexのコーディングセッションに帰属させるかもしれない。同様に、文面が似た2つのプロンプトでも、一方が多数のツール操作を引き起こせば消費量は異なり得る。

したがって、10%から50%という範囲は運用上の見積もりとして理解すべきだ。これは、OpenAIが複数のワークロード種別にわたって無駄が減ると見込んでいることを示す。プロンプト、トークン、完了タスク、サブスクリプションのクォータ間の安定した換算関係を示すものではない。

Google Newsはここでは主張の発信元ではなく、発見のためのチャネルとして関係する。根本となる声明はOpenAIのエンジニアリング責任者によるものであり、独立系の記事がそれをより幅広い読者向けに整理した。GoogleはCodexをテストしたわけでも、報告された改善を検証したわけでもない。

この帰属は重要だ。集約される過程で不確実性は圧縮され得る。短い見出しには、自動リセット、修正されたバックグラウンドワーカー、効率化の見積もりを区別する余地がほとんどない。読者は3つすべてを恒久的なクォータ増加と容易に解釈してしまう。

この発表には分布に関する結果も欠けている。OpenAIは、中央値の改善、高パーセンタイルの改善、または提示された範囲のいずれかの端に近づくと予想されるユーザーの割合を公表していない。

その情報がなければ、50%という数値は一部のワークロードが経験すべきことを示すにとどまり、その結果がどれほど一般的かは示さない。下限の10%はあるグループにとってより関係が深い可能性があり、以前に影響を受けた外れ値では、実質的にはるかに大きな回復が見られることもある。

このため、この更新を単なるマーケティング文言として退けるべきではない。開示されたバグは具体的であり、無駄な作業の原因としてもっともらしい。それでも公開されている証拠が裏付けるのは、効率が改善するはずだという主張であって、すべてのCodexユーザーが今や50%多い容量を持つという結論ではない。

Codexの利用上限は製品の信頼性問題になった

クォータの消費はエージェントがタスクを完了できるかどうかに影響するため、計測の挙動は製品の信頼性の一部になっている。

従来のチャットボットは、ほとんどのやり取りを1つの応答内で完了する。エージェント型システムは、ファイルの確認、リポジトリの検索、ツールの呼び出し、プロセスの待機、作業の委任、以前の判断の見直しを行える。したがって、1つのユーザー要求から多数の基盤となるモデルサイクルが生じ得る。

不要なサイクルはすべて重要だ。ツールの再試行が繰り返されると、回答が遅れるだけではない。共有の利用可能量を消費し、アクティブなコンテキストを肥大化させ、さらなる再試行が発生する機会も増える。

そのため、停止に関するバグは使いにくいインターフェースの欠陥より深刻だ。ゴールがすでに完了しているなら、その後のすべてのアクションはユーザーが要求していない作業を意味する。システムは稼働しているように見える一方で、後続タスクに使える容量を静かに減らしていく可能性がある。

同じ問題はコンテキスト圧縮にも当てはまる。エージェントは新たなモデル要求のたびに無制限の履歴を保持できないため、長いセッションでは圧縮が必要になる。しかし、圧縮戦略に失敗すると、本来破棄すべき情報を繰り返し処理する可能性がある。

画像は大きなコンテキストを占有し得るため、特に重要だ。インターフェースのデバッグにスクリーンショットを使う開発者は、小規模なテキストのみのリポジトリを扱う人よりも急激なコンテキスト増大を経験する可能性がある。

自動化はさらに別のリスク層を加える。ユーザーは通常、すべての実行を監督したくないからこそスケジュールされた作業を作成する。スケジュールが過度に頻繁に実行される場合、最も影響を受けるワークフローほど、即時の人間による介入を受けにくい。

OpenAIはすでに2026年6月、より限定的なCodexの障害を記録していた。同社のステータス報告では、一部のアカウントが不正利用・詐欺防止システムによって誤ってレート制限を受けていたとしている。同社は影響を限定的と説明し、より広範な劣化は確認していないと述べた。

この障害と最新の修正を、単一の原因としてまとめるべきではない。6月の問題は、特定アカウントに対する誤ったレート制限に関するものだった。今回新たに開示された内容は、Codexが不要な内部作業を実行し得た複数の経路を説明している。

ただし両者を合わせると、ユーザー報告の解釈が難しかった理由を説明できる。利用可能量が急速に減る原因は、長時間のタスク、高コストなモデル選択、共有エージェント利用、過剰なコンテキスト、暴走したゴール、またはアカウントレベルの制限である可能性がある。

ユーザーは単一のパーセンテージ表示だけで、これらの可能性を確実に切り分けることはできない。リセット時刻や大まかな利用可能量のカテゴリは確認できるが、すべての内部操作をクォータ消費に対応付ける完全なターン単位の台帳は提供されていない。

Codexがソフトウェア開発の枠を超えるにつれ、この問題は大きくなる。OpenAIは6月、Codexの週間アクティブユーザー数が500万人を超え、デスクトップアプリの2月のローンチ後には利用者数が6倍超になったと述べた。同社はまた、導入レポートで、ナレッジワーカーがユーザーの約20%を占めるとしている。

こうしたユーザーは、Codexにレポート作成、データ分析、プレゼンテーション準備、ワークフロー自動化を依頼する機会が増えています。プロセスログを日常的に確認する開発者に比べ、エージェントループの問題を診断する経験は少ないかもしれません。

失敗したターミナルコマンドは目に見えます。一方、停止条件を何千回も確認するバックグラウンドのメモリワーカーは見えません。そのため、導入が広がるほど、深いシステム知識がない人にも通じる利用状況の説明が重要になります。

チームには、さらに計画上の課題があります。消費量がコンテキストの形状、モデルの選択、ツールの挙動、隠れたオーケストレーションに左右される以上、プロジェクトマネージャーが週次の利用枠で何件の委任タスクをこなせるかを簡単に見積もることはできません。

今回の修正は、既知の変動要因をいくつか減らします。ただし、予測可能な計測の必要性をなくすものではありません。Codexが信頼できるインフラになるには、ユーザーは完了する作業だけでなく、その作業に付随する利用量の計上も信頼できなければなりません。

真の相手は検証ギャップ

OpenAIは改善のための信頼できる仕組みを示したものの、ユーザーにはその見出しの数値を再現するために必要なデータが依然として不足しています。

Codexリポジトリで公開されているissueは、この隔たりをよく示しています。投稿者はOpenAIに対し、「利用可能時間が長くなる」が何を測定しているのかを定義し、こうした主張の根拠となるワークロード、モデル、推論レベル、観測期間を開示するよう求めています。

このissueは、エージェントの反復ステップが消費量をどのように増幅し得るかも説明しています。ツールがモデルに制御を戻すと、Codexは次に何をするか決める前に会話コンテキストを再処理する可能性があります。余分なサイクルにより、キャッシュ済み入力、推論、その他のクォータ加重対象の活動が追加されることがあります。

利用状況の分析で引用されたコミュニティテストでは、明示的なバッチ処理によって推定消費量が下がる場合があることが分かりました。こうした実験は有用なエンジニアリング上のシグナルですが、OpenAIの非公開のサブスクリプション利用台帳を明らかにするものではありません。

その限界は重要です。サンプル数は少なく、タスクは読み取り中心の調査に偏っており、一部の比較ではコンテキストや推論条件が異なっていました。推定API相当コストも、実際のCodexクォータの変動と同じではありません。

このissueは、中心的な未解決の疑問を挙げています。OpenAIは、この改善が生トークン、重み付けされた内部利用量、完了した作業、経過時間、あるいは別の代理指標のどれを測るものなのかを公に定義していません。

パーセンタイル結果も提供されていません。単一の平均値では、発表で説明されたロングテールの失敗をなお隠してしまいます。ユーザーは、典型的なワークロードが、以前に繰り返しのコンパクションや暴走した停止挙動に見舞われたワークロードとどう異なるのかを知る必要があります。

展開範囲も依然として不明確です。一部の修正はOpenAIのサーバー上だけで実施できますが、他の修正はCodexアプリやコマンドラインの更新に依存する可能性があります。公開声明では、各変更に必要な最低クライアントバージョンは示されませんでした。

この不確実性は、改善が虚偽であることを示すものではありません。公開データからその主張を独立して検証できないことを示しています。開示された仕組みはユーザーが報告してきた挙動と整合しており、各修正は論理的に見て無駄な作業を減らすはずです。

しかし、有効容量は完了タスクの品質と同じではありません。モデルのサイクルを削減する最適化が効率的に見えるのは、Codexが依然として正確で完全な結果を出す場合に限られます。有用なベンチマークは、消費量と成果の両方を測定する必要があります。

タスクの多様性も重要です。リポジトリ調査、インターフェースのデバッグ、コード生成、長時間のテスト、ブラウザ自動化、マルチエージェント作業は、それぞれシステムの異なる部分に負荷をかけます。単一の混合指標では、各カテゴリがどのように変化したかをユーザーに伝えられません。

リセットは、一時的な測定上の問題も生みます。たとえば、ユーザーがOpenAIによる更新の直前と直後で週次利用率を比較したとします。それで分かるのはリセットであって、修正されたエージェント挙動によってどれだけ節約できたかではありません。

より適切なテストは、リセット後に開始し、制御されたタスクを繰り返すものです。同じリポジトリ状態、プロンプト、モデル、推論レベル、権限、ツール、クライアントバージョンを使用します。そのうえで、完了した作業と実際の利用枠の変動を比較します。

その方法にも、モデル出力が確率的であるため限界があります。複数回の実行が必要であり、環境によるバイアスを減らすため実行順序も交互にすべきです。一般のユーザーには、そのような調査を行うための時間もクォータも不足しています。

この証拠を公開するうえで、OpenAIはより有利な立場にあります。内部処理を観測し、影響を受けたコホートを特定し、モデルトークンとオーケストレーションのオーバーヘッドを区別できます。また、顧客コンテンツを公開せずに、数千件の本番ワークロードにわたる結果を比較できます。

それまでは、最も妥当な解釈は限定的なものです。OpenAIは、ときに大きな利用枠を無駄にしていた複数の具体的な挙動を修正しました。同社はユーザーごとに有効利用量が10%から50%向上すると見込んでいますが、公開情報だけではその範囲をまだ再現できません。

修正が開発者とチームにもたらす意味

実用上の利点は、目に見えない失敗が減ることですが、チームは利用状況ダッシュボードを依然として限定的な診断ツールとして扱うべきです。

長時間のリポジトリ作業でCodexに依存する開発者には、最も明確な関心理由があります。完了後も継続するゴールは、テスト、レビュー、または後続の修正に必要な残りの予算を無駄にする可能性があります。

名目上の上限が固定されたままでも、この変更はワークフローの継続性を改善できます。利用枠のより多くが、繰り返しの停止確認、古い画像、壊れたツール、予期しない補助モデルではなく、依頼された作業に充てられるはずです。

画像を多用する開発では、コンパクション修正による直接的な効果が見込まれます。一般的な例には、インターフェースのスクリーンショットのレビュー、レンダリングされたページの比較、図の確認、ブラウザベースの受け入れテストのデバッグなどがあります。

すべてのビジュアルタスクが10%安くなると想定すべきではありません。OpenAIはこの推定を画像を多用する人々に結び付けており、サンプルの定義は公開していません。コンテキスト長やタスク構造によって、結果は依然として変わり得ます。

自動化の運用担当者は、スケジュール済みジョブを慎重に見直すべきです。OpenAIは、過度に頻繁に実行される可能性があったカスタムスケジュールを修正したとしていますが、過去の利用状況だけでは、どの実行が意図しないものだったかは自動的に分かりません。

チームは自動化のタイムスタンプを想定スケジュールと比較できます。予期しない過去の実行は異常な消費を説明するかもしれませんが、新たに開示されたバグがすべての差異を引き起こしたと証明することはできません。

ゴール駆動型のワークフローにも、同様の注意が必要です。チームは観測可能な完了条件を定義し、最終出力がそれに一致するかを確認すべきです。修正によって継続実行は減るはずですが、明確な受け入れ基準は依然として有用です。

壊れたツールも別の警告サインです。外部サービスが利用できない、またはコマンドが成功しない場合、繰り返しのリトライは高コストになり得ます。適切に設計されたワークフローは、リトライの境界を設定し、後の試行に必要な情報を十分に保持すべきです。

サブエージェントを利用するユーザーは、情報が利用できる場合、委任作業にどのモデルが参加しているかも確認すべきです。OpenAIの修正により、小規模モデルが依頼なしにより高性能な補助モデルを選択することを防ぎ、ユーザー意図と実行コストの整合性が改善されるはずです。

組織にとって、これらの変更は、プロンプト、判断、ログ、最終出力を検索可能な形で記録する必要性をあらためて示しています。ローカルのエンジニアリングナレッジベースは、予期しない結果を、その周囲にあるファイルや指示と結び付けるのに役立ちます。

その記録はOpenAIの利用状況テレメトリーの代わりにはなりません。しかし、タスクの範囲、ツールの失敗、完了状況に関するチーム独自の証拠を提供します。利用枠が予期せず減ったとき、こうした詳細はサポート報告をより実行可能なものにします。

チームは単純なプロンプト数を比較すべきではありません。あるCodexリクエストは既存コンテキストから回答するだけかもしれませんが、別のリクエストではテスト実行、ファイル検索、プロセス待機、作業の委任が行われる場合があります。完了タスク単位のほうが、より有用な運用指標になります。

実用的な社内指標としては、利用枠の期間ごとに受け入れられた変更、レビュー済み文書、完了した分析を追跡する方法があります。失敗した実行も記録すべきです。消費量が減っても使えない成果物しか出さないエージェントは、生産性を改善していません。

開発者は、一時的なリセットと継続的な効率性を分けて考えるべきです。更新されたダッシュボードは即時の余裕を生みますが、持続的な価値は、その後に同等のタスクがその余裕をどれだけ速く消費するかにあります。

同じ注意はGoogle Newsの要約やソーシャル投稿にも当てはまります。これらは有用な発見ツールですが、運用上の判断は基となる声明と直接的なプロダクト証拠に基づくべきです。見出しだけでは、特定のワークフローが修正済みコードパスに触れたかどうかは分かりません。

OpenAIが公開しているヘルプ資料は、アカウント情報について利用状況ダッシュボードと/statusコマンドを案内しています。これらのツールは大まかな利用可能状況を示しますが、操作ごとの完全な内訳は提供しません。

利用状況に依然として一貫性がないように見える場合は、モデル、推論レベル、クライアントバージョン、タスク開始時刻、ツール、コンテキスト特性、観測されたクォータ変動を記録すべきです。この一式があれば、OpenAIは想定どおりの消費と別の不具合をより明確に区別できます。

Google Newsでの急増後に注目すべきこと

次の試金石は、OpenAIが一度限りの修正アップデートを、継続して測定可能なCodexの効率性へと変えられるかどうかです。

最初のシグナルは、リセット効果が消えた後の利用状況の安定性です。複数の利用枠期間にわたり、比較可能なタスクの消費量が減るか、少なくともより予測可能になるべきです。理由の説明できない減少の報告が続くなら、今回の修正は問題の一部にしか対処していないことになります。

この観察では、ワークロードの変化を考慮しなければなりません。モデルを切り替え、より多くの推論を有効にし、ツールを追加し、リポジトリのコンテキストを拡大するユーザーは、明確な修正前後比較を行えません。

第二のシグナルは、より良い帰属情報です。OpenAIはすでに大まかな利用状況情報を公開していますが、ユーザーにはクォータ変動とモデルターン、ツールループ、自動化、サブエージェント、バックグラウンド作業との、より明確なつながりが必要です。

タスクごとのレポートがあれば、将来の回帰をより容易に特定できるようになります。また、目に見える割合がユーザーの想定より速く変化したときの憶測も減らせます。

第三のシグナルは、10%から50%という範囲に関する方法論の公開です。OpenAIは指標を定義し、テストしたワークロードを説明し、どのクライアントバージョンが重要かを示し、中央値とロングテールの結果を提示できます。

一部のカテゴリで見出しの最大値ほど改善しなかったとしても、その開示は同社の主張を強めるでしょう。定義されたワークロードでの透明性ある10%の改善は、ユーザーが自らの作業に対応付けられない、より大きな数値より有用です。

競合他社の動向も補足的な文脈を提供します。他のエージェント提供者も、長時間の自律実行と予測可能な利用枠との間で同じ基本的な緊張関係に直面しています。コーディングエージェントがより大きなプロジェクトを扱うようになるにつれ、より明確な利用量の計上は製品上の優位性になり得ます。

現時点では、開発者はこの更新を、未解決の測定問題を抱えた意味のある保守対応として扱うべきです。OpenAIは複数の具体的な不具合を挙げ、深刻な外れ値の挙動を説明し、有料ユーザーをリセットし、既存の利用枠でより多くの作業を支えられると見込んでいます。

残る不確実性は、その規模、分布、持続性に関するものです。Google Newsは50%という上限値を広く知らしめましたが、典型的なユーザーが実際にどこに着地するかを示せるのは、リセット後の結果を繰り返し確認することだけです。

次の数件の比較可能なタスクを観察し、Codexの動作を記録し、完了した作業とダッシュボードの変動を分けて考えてください。同じ利用枠でより多くの受け入れ可能な成果が得られるなら、修正は重要な場所で機能しています。説明のつかない消費が続くなら、OpenAIにはさらなるエンジニアリングと、はるかに明確な証拠が必要になります。