「火曜日に面白い発表があるらしい。楽しみだな」と待っていたら、先に長文で出てきたのが利用量の計算変更だった。
しかも要約すると、月200ドルのProを新規受付再開する一方、旧プランと比べてAPI料金換算の利用価値は半分になるという説明である。
祝砲を待っていたら、先に請求書の仕様変更が飛んできた。
そりゃ「おい」となる。
ただし、ここは一個だけ冷静に分けないといけない。これは「全モデルの利用回数が一律50%になる」という告知ではない。同じ週、OpenAIはGPT-6 SolとLunaのAPI価格をGPT-5.6のプロモーション価格比で50%下げた。
つまり運営側の理屈はこうだ。
使えるAPIドル換算は半分にする。だがモデル側も安くする。だから最終的には以前より仕事ができる。
理屈は分かる。
問題は、利用者が買っているのは「APIドル換算値」ではなく、終わった仕事の数だということだ。
1. 「半分」は何が半分なのか
Tiboの2026年9月29日の投稿では、翌9月30日にPro $200の新規受付を再開するとしたうえで、新しい利用量計算では「旧Pro $200と比べ、API spendのドル換算で半分になる」と説明している。
同時に、5時間制限は復活させず、週次枠を好きなタイミングで使える状態を維持すること、モデルの効率化とAPI値下げを利用者へ還元すること、さらに利用量を消費しない追加機能も翌日に発表するとしている。
9月22日に発表されたGPT-6 SolとLunaは、OpenAI公式にGPT-5.6のプロモーション価格比でAPI価格50%減とされている。 9月29日時点の公式料金表でも、SolとLunaの現行価格を確認できる。
ここだけ見ると算数はきれいだ。
旧利用予算をB、1仕事あたりのAPI相当コストをCとすると、旧プランで完了できる仕事はおおむねB/C。
新プランで予算が0.5Bになっても、同じ仕事のコストが0.5Cまで下がれば、
0.5B ÷ 0.5C = B ÷ C
になる。
つまり理論上は仕事量が減らない。
だが、現実のAI仕事はそんなに均一ではない。
2. 利用者が見ている単位は「何ドル分」ではなく「何件終わったか」
軽い質問を100回する人と、巨大なリポジトリを読ませて一回の修理を完走させる人では、同じ「1リクエスト」の意味がまったく違う。
長い文脈、深い推論、ツール呼び出し、複数回の検証、失敗後のやり直し。
重い仕事は一発で大きく枠を食う。
だからヘビーユーザー側の体感は、
「メッセージは送れる」
ではなく、
「これ一個投げたら、もう次の大物いけないんだけど」
になりやすい。
ここで「API価格が半分です」と説明されても、欲しい答えはそこではない。
今週あと何件、最後まで仕事を終わらせられるのか。
この指標を「完了仕事量」と呼ぶなら、定額AIの価値はメッセージ数でもトークン数でもなく、最終的には
完了仕事量 ÷ 月額
で決まる。
3. 「Opusの100分の1しか使えない」はベンチマークではない。でも不満の構造は本物
重いAI作業をしていると、サービス間の利用枠差が極端に感じられることがある。
「片方は何本も長い仕事を回せるのに、もう片方は一件重いのを投げたら終わり。体感100分の1では？」
もちろん、この「100分の1」は測定済みの倍率ではない。タスク、モデル、プラン、文脈長で変わる。
でも、数字が誇張だから問題まで消えるわけではない。
重要なのは仕事の粒度と制限設計が噛み合っているかだ。
毎回5分で終わる仕事なら小さな上限でも細かく使える。
一方、1案件が30分、1時間、あるいは何度も修理を繰り返すエージェント作業なら、「一個始めると途中で燃料切れ」が最悪である。
AIの知能が高くても、完走前に止まれば成果物はゼロに近い。
だから「最高性能」だけでなく、
- 一件を最後まで通せるか
- 失敗しても再開できるか
- 週に何件完了できるか
- モデル変更時に作り直しにならないか
まで含めて価値を見る必要がある。
4. だから今は「AIを消費する時期」ではなく「設備を作る時期」
ここからが本題だ。
今の高性能AIサブスクリプションが将来値上げされるか、枠が減るか、逆に安くなるかは分からない。
分かるのは、利用条件は固定資産ではないということだけだ。
今日の大盤振る舞いは、明日の標準仕様ではない。
だから安い時期に一番もったいない使い方は、AIと大量に会話して、その結果がチャット履歴にしか残らないことだ。
逆に強いのは、安い推論を使って次の推論を減らす仕組みを作ること。
たとえば、
- 毎回手作業で調べていたものを自動収集する
- 毎回AIに説明していた判断基準を契約・ルールとして保存する
- 人が目視していた検査をテストへ変える
- 長い一発勝負を途中再開できる工程へ分ける
- 結果をチャットではなくファイル・DB・Gitへ残す
- 一社のモデル名を直接埋め込まず、交換できる入口を作る
- どのモデルが何の仕事に強いか実績を記録する
こうすると、今月使ったAIが来月消えても、成果は残る。
AIを借りている間に、AIがいなくても動く工場を建てる。
これが設備投資としてのAI利用だ。
5. 残る資産と、消える消費を分ける
同じ10時間AIを使っても、残るものはかなり違う。
| その場で消える使い方 | 後に残る使い方 |
|---|---|
| 毎回同じ説明をチャットへ書く | 入力仕様・判断基準をファイル化する |
| AIに手作業でチェックさせる | 自動テスト・評価器を作る |
| 一発の巨大タスクを投げる | checkpoint付きの小工程へ分割する |
| 回答を読んで終わる | 成果物・根拠・状態を保存する |
| 一番強いモデルを全部に使う | 軽いモデル→必要時だけ強いモデルへ回す |
| 特定サービス専用の魔法プロンプトを育てる | 共通の仕事仕様と薄いprovider adapterを作る |
| 上限が来たら止まる | resume・retry・handoffを持たせる |
研究面でも、複数モデルを仕事ごとに使い分ける発想には根拠がある。
FrugalGPTは、質問ごとに使うモデルを変えるカスケードによって、評価したタスクでは最良単一モデルに近い性能を保ちながらコストを大幅に削減できることを示した。
2026年の別研究でも、まず費用対効果の高いモデルへ振り分け、品質が足りない案件だけ強いモデルへ昇格させる二段階方式で、最強モデルの精度の97〜99%を維持しながら効率を上げたと報告されている。
全仕事へ最強モデルをぶつける必要はない。
強いモデルは、強いモデルが必要な瞬間にだけ使う。
6. 一社にロックされない最小構成はこれ
モデル交換可能な仕組みは、大げさなマルチクラウド計画でなくていい。
最低限、次の六つを分ければかなり強くなる。
仕事の仕様 何を入力し、何を完成とするか。モデル名ではなく仕事そのものを書く。
モデル接続部 OpenAI、Anthropicなどの違いをここだけで吸収する。本文ロジックから切り離す。
状態保存 どこまで終わったかを記録する。長い仕事を最初からやり直さない。
成果物保存 コード、文章、評価結果、根拠をチャット外へ出す。
評価器 「完成しました」を信じるのではなく、テスト、比較、実データで確かめる。
振り分け 安いモデルで足りる仕事は安いモデルへ。失敗した案件だけ上位へ上げる。
MicrosoftのWell-Architected Frameworkも、密結合した依存関係を減らし、ドメインロジックをインフラ固有機能から分離することを推奨している。
AIでも同じである。
「この仕事はOpusでしか動かない」「この処理はSolの返答形式を前提にしている」が増えるほど、価格改定がそのままシステム改修になる。
逆に接続部が薄ければ、
Claudeが高くなった → 別モデルを試す
で済む。
7. 今の高性能モデルに何を作らせるべきか
安い時期に強いモデルへ頼む価値が高いのは、「今日の成果」だけでなく「明日から自動で成果を作るもの」だ。
優先度が高いのは次のような仕事だ。
第一に、繰り返し作業の自動化。 毎週やっている調査、整形、検査、公開、集計を一回ずつ人間が指示しなくてよい形へする。
第二に、失敗から復帰する仕組み。 retry、resume、checkpoint、冪等性、重複防止を入れる。一回の制限到達で全工程が死なないようにする。
第三に、品質基準の外部化。 「なんかいい感じ」をモデルの勘へ預けず、テスト可能な条件へ落とす。
第四に、観測。 タスク種類、使用モデル、成功率、再試行回数、所要時間、利用量を残す。
第五に、モデル切替。 最初から二社三社を常時使う必要はない。ただし交換できる入口だけは作っておく。
こうすると、将来の価格改定は「世界の終わり」ではなく「ルーターの重み変更」になる。
8. 逆に、今やると危ない最適化
安いモデルが大量に使えると、ついその条件へ全設計を寄せたくなる。
これは短期では速い。
長期では危ない。
特に避けたいのは四つ。
「今の上限を全部使い切る」が目的になること。 利用量は成果ではない。余った枠を燃やすための仕事を作り始めたら逆転している。
巨大な一発タスクへ寄せること。 上限変更、通信切断、モデル停止のたびに全損しやすい。
一社専用の暗黙知を増やすこと。 特定モデルだけに通じる長大な呪文が増えるほど乗り換え費用が上がる。
価格改定を予言して設計すること。 「Claudeも絶対値上げする」「OpenAIはずっと削る」と決め打ちする必要はない。将来を当てるより、外れても困らない構造を作る方が強い。
9. 結論――サブスクの大盤振る舞いは天気、仕組みは家
月200ドルの利用枠変更に腹が立つ。
別サービスの方が何倍も使えるように感じる。
その感覚自体は自然だ。
でも、そこで毎回「どっちが今お得か」だけを追うと、運営の料金表が変わるたびに自分の生産性まで揺れる。
もっと強い使い方は、今の異常に安い知能を固定資産へ変換することだ。
コード。
テスト。
評価基準。
データ。
自動化。
再開可能な工程。
モデルを交換できる接続部。
これらは、サブスクの週次枠がリセットされても消えない。
今日の最強モデルを永遠の前提にしない。
今日の安さを永遠の前提にもしない。
安いうちに、安さが終わっても困らない仕組みを作る。
結局これが一番強い。
火曜日の「すごい発表」を待っていたら先に利用枠変更の長文が来る世界では、なおさらである。
