ChatGPTで会話を続けながら、別の作業画面に移って調査やコーディングを任せる。この使い分けが、12月以降は一つの利用枠として管理される見通しです。OpenAIが更新したサポート情報によると、Plus、Pro、Businessの各プランでは、ChatGPTとCodexを横断する共通のトークン予算が導入されます。Codexは、コードの作成や修正などを自律的に進めるOpenAIのコーディング支援エージェントです。



今回の変更は、単に二つの画面を一つにまとめる話ではありません。従来のChatと、複数工程を進めるエージェント型のWorkが同じインターフェースに収まり、そこで使った処理量が共通の予算から差し引かれます。利用者にとっては操作場所が分かりやすくなる反面、会話、調査、コーディングといった異なる仕事が一つの枠を取り合う形になります。

OpenAIは以前からChatとWorkを統合する方針を示していました。今回明らかになった要点は、その統合に合わせて利用制限の考え方も変わることです。これまでのように「何回質問できるか」だけを気にするのではなく、どのモデルに、どれほど複雑な処理を任せたかが実質的な利用可能量を左右します。

企業利用で注目すべき中心点もここにあります。同じ人数、同じ契約プランであっても、短い文章の確認を中心に使う組織と、大規模なコード解析や長い資料の処理を繰り返す組織では、予算の減り方が異なるでしょう。AIの利用枠は、固定的な回数制限から、仕事内容によって消費量が変わる計算資源へ近づいていきます。

トークンは、AIモデルが入力を読み取り、回答を生成するときに扱う情報量の単位です。文字数と完全に一致するわけではなく、長い指示、添付情報の多い依頼、長文の回答などは、それだけ多くの処理を必要とします。高性能なモデルや複雑なタスクほど共通予算を速く消費するため、質問回数が同じでも利用状況に差が生じます。



たとえば、短いメールの表現を整える依頼と、複数ファイルを調べて修正案まで作る依頼では、後者の負荷が大きくなりやすいでしょう。業務上はどちらも一回の依頼ですが、トークン予算の観点では同じ一回として扱えません。回数を数えるだけの管理では、月の途中で利用余力が不足する理由を説明しにくくなります。

利用者はChatGPTの設定画面から残高とリセット時刻を確認できるとされています。上限に達した場合は、枠がリセットされるまで待つ、上位プランへ変更する、追加クレジットを購入するという選択肢があります。つまり、利用制限に達した時点で業務を止めるだけでなく、時間、契約、追加費用のいずれかで対応する設計です。

企業では、AI利用を水道や電気のような単純な従量課金として捉えるだけでも不十分でしょう。消費量は作業時間ではなく、選んだモデルと依頼内容にも左右されるからです。部署別の利用目的、優先業務、求める回答品質を整理しなければ、枠を節約するために必要な仕事まで軽量モデルへ移す事態も起こり得ます。トークン予算は技術部門だけの指標ではなく、業務の優先順位を反映する管理項目になります。

新しい仕組みでも、Instantモデルとの会話は共通トークン予算の対象外になるとされています。このため、予算を使い切った後もChatGPTそのものが直ちに使えなくなるわけではありません。表面上は定額サービスの形を保ちながら、より処理能力を必要とするモデルやエージェント機能には共通の上限を設ける構造です。



| 利用場面 | 共通予算への影響 | 上限到達後の考え方 |
| --- | --- | --- |
| Instantモデルとの会話 | 予算の対象外 | 軽量な会話を継続できる見込み |
| 高度なモデルによる複雑な処理 | タスクに応じて消費 | リセット待ちや追加クレジットを検討 |
| Codexを使った作業 | ChatGPTと同じ予算を共有 | 他の重要業務との配分が必要 |

THE DECODERは、価格の低いプランで利用量が多いユーザーほど、高度なモデルを継続的に使いにくくなり、結果として得られる回答品質に差が出る可能性を指摘しています。「使い放題」という説明が直ちに消えるわけではなくても、どの品質の処理を、どの程度まで使えるかが契約価値を左右するわけです。

OpenAIは今回の統合に先立ち、上位プランの利用上限を従来の2倍に引き上げました。ただし、その変更が統合準備を目的としたものかどうかは明示されていません。THE DECODERは、共通予算への移行を見据えた措置ではないかとみています。事実として確認できる上限拡大と、背景に関する見方は分けて受け取る必要があります。

B2Bの契約判断では、「利用できるか」だけでなく「必要な品質を維持できるか」を確認したいところです。定型的な要約や文章修正はInstantモデルで足りても、設計レビューや大規模なコード解析では高度な処理が求められるかもしれません。定額料金だけを比較するより、重要業務に割り当てられる実質的な予算を見るほうが、運用実態に合った評価になります。

ChatとWorkの統合には、利用枠をまとめるだけでなく、ChatGPTの操作を整理する狙いもあると考えられます。確認された時点のChatGPTには二つの動作モードと11種類のモデル設定があり、経験のある利用者でも違いを把握しにくい状況だとTHE DECODERは評しています。選択肢を増やして機能差を示す方法が、かえって利用開始時の負担を大きくしていたという見方です。



利用者が本当に行いたいのは、モデル名を比較することではなく、資料をまとめる、情報を探す、コードを直すといった仕事です。ChatとWorkが分かれていると、依頼の途中で適切な画面や動作モードを選ぶ必要があります。エージェント型の作業機能が会話画面へ組み込まれれば、利用者は目的を伝え、必要に応じてAIに複数工程を進めさせる流れへ移りやすくなるでしょう。

競合するAnthropicも、対話型AIのClaudeでChatと作業機能のCoworkを組み合わせています。個別機能を別製品として並べるより、会話を入口にして調査や実行へつなげる設計が、生成AIサービスの一つの方向になりつつあります。ただし、画面が一つになることと、仕組みが単純になることは同じではありません。裏側ではモデルごとの処理負荷や予算消費が残ります。

管理者にとっては、使いやすさの向上が利用量の増加につながる可能性にも注意が必要です。入口が統合されれば、従業員はエージェント機能を意識せずに高度な処理を頼めるようになるかもしれません。その結果、共通予算がどの業務で消費されたのかを把握できなければ、上限到達の原因を追いにくくなります。画面の簡素化と管理の簡素化を混同せず、利用目的を記録できる運用が求められます。

共通トークン予算は、企業のAI運用を個人単位の利用許可から、限られた処理能力の配分へ変える可能性があります。特にBusinessプランでは、ChatGPTでの一般業務とCodexによる開発作業が同じ枠を使います。文章作成を行う営業部門と、コード解析を行う開発部門を単純に利用回数だけで比べても、負荷や成果を適切に評価できません。



第一の変化は、予算超過の原因が人数だけでは決まらなくなることです。少人数でも複雑なタスクを連続して実行すれば消費は速くなり、大人数でも軽量な会話が中心なら共通予算への影響を抑えられる可能性があります。ライセンス数に単価を掛けるだけの見積もりから、利用パターンを含めた需要予測へ移る必要があるでしょう。

第二の変化は、AIモデルの選択が費用管理と結び付くことです。高度なモデルを常用すれば安心とは限りません。社内FAQの下書きや表現の調整まで重い処理へ寄せると、設計レビューや複雑な分析に使う余力が減ります。軽量モデルで十分な業務と、高度な処理を優先すべき業務を分ける判断基準が必要になります。

第三の変化は、上限到達時の対応を事前に決める必要が生じることです。リセットまで待てる業務もあれば、追加クレジットを購入して継続すべき業務もあります。誰が購入を承認し、どの条件なら上位プランを検討するのかが曖昧だと、担当者ごとに判断が分かれかねません。

なお、組織内で利用枠を部署別に割り当てられるか、詳細な消費内訳を管理者が取得できるかといった仕様は、今回確認できた情報だけでは明らかになっていません。OpenAIが示しているのは、利用者が設定画面で残高とリセット時刻を確認できる点です。企業は製品側にない管理機能を想定せず、必要なら申請記録や定期確認などの社内手順で補うべきでしょう。

共通予算への移行に備えるなら、最初に細かなトークン数を予測するより、どの仕事に高度な処理を使っているかを洗い出すほうが実務的です。モデルやタスクによって消費量が変わるため、厳密な数字を事前に固定しても実際の利用とはずれる可能性があります。業務を重要度と複雑さで分類すれば、上限に近づいた際の優先順位を決めやすくなります。



分類の軸には、期限、機密性、必要な精度、代替手段の有無を使えます。期限が迫ったコード修正と、社内向け文章の言い換えを同じ優先度で扱う必要はありません。Instantモデルで対応できる業務はそちらへ移し、深い推論やエージェント作業が必要な案件に共通予算を残す運用が考えられます。ただし、品質確認を省いて節約だけを目的にするのは適切ではありません。

残高とリセット時刻を確認する担当も決めておきたいところです。個々の利用者が確認できても、部門全体の状況が自動的に共有されるとは限りません。週次で残高を記録する、重要プロジェクトの開始前に確認する、一定水準を下回ったら管理者へ連絡するといった簡単なルールでも、突然の上限到達を避ける手掛かりになります。

追加クレジットについては、通常の経費精算と分けて考える必要があるでしょう。購入を認める条件、承認者、上限額をあらかじめ決めなければ、緊急対応のたびに判断が止まります。反対に、無条件で購入できるようにすると、モデル選択や依頼内容を見直す機会を失いかねません。業務継続と費用統制の両方を保てる承認経路が必要です。

運用ルールは固定せず、統合後の実績を見て調整する前提が現実的です。利用した業務、選んだモデル、上限に近づいた時期、成果物の品質を記録すれば、次の契約更新で上位プランや追加クレジットが必要かを判断できます。単なる消費監視ではなく、どの処理が事業上の成果につながったかを確認する材料として扱うことが大切です。

制度変更を待ってから全社ルールを作るより、現在の利用状況を小規模に観察しておくほうが判断材料を得やすくなります。対象部署を一つ選び、二週間程度の業務を「軽量な会話」「高度なモデルを使う分析」「Codexによる作業」に分けて記録する方法が考えられます。ここで必要なのは精密なトークン計測ではなく、共通予算を多く使いそうな業務の分布を知ることです。



検証では、同じ仕事を異なる方法で試すと差が見えやすくなります。短い文面修正をInstantモデルで処理した場合と、高度なモデルで処理した場合を比べ、品質差が業務上必要かを確認します。開発作業では、Codexへ一度に大きな依頼を渡す場合と、範囲を絞って依頼する場合を比較できます。ただし、品質や安全性を損なうほど指示を削るべきではありません。

記録する項目は、業務名、利用した機能、期待した成果、担当者による品質評価、やり直しの有無で十分でしょう。設定画面で確認できる残高やリセット時刻も同じタイミングで控えれば、どの種類の仕事が利用余力へ影響しやすいかを推測できます。製品側で詳細な内訳が提供されるかは明らかになっていないため、観察結果は概算として扱う必要があります。

検証後は、すべてのAI利用を制限するのではなく、高度な処理を優先する業務を三つ程度に絞ると運用へ落とし込みやすくなります。上限に近づいたときに止められる仕事、Instantモデルへ切り替えられる仕事、追加クレジットを使ってでも続ける仕事を決めてください。共有トークン予算への移行は、AIを何回使うかではなく、どの仕事に計算資源を配分するかを見直す機会になります。