/note/tech

Cheap AI tokens are running out

要約:

■ 1. AI普及の次に来るコスト管理の段階

  • 現在の局面:
    • 全員にAIを使わせるよう説得する段階は成功裏に終わりつつある
    • 今後はコストを抑えるための本格的な取り組みが必要な段階に入る
    • エンジニアは開発速度の向上と新たな期待値を実感しており、組織はトークン代を払い続ける必要がある
  • 個人プランへの流出:
    • 企業がガードレールや上限を設けると、不満を持ったエンジニアが密かに個人プランに戻るケースがある
    • 大企業はエンタープライズプランでトークン単位の従量課金を払っている
    • 個人プランはAIラボが補助する定額制で、利用上限が手厚くトークンコストを気にせずに済む
    • その結果、会社のコードやデータが会社の管理外のアカウントを通過する
    • 実際の需要が計画担当者から見える場所に現れなくなる
  • Nordhealthの現状:
    • 規模が小さいためClaude Teamプランを利用している
    • Premiumシートごとにエンジニア1人あたり十分すぎるトークンが付与される
    • 現時点ではAIは予算上予測可能な支出になっている

■ 2. 定額プランの補助と従量課金への移行

  • 従量課金のコスト:
    • 多くの企業が使う従量制エンタープライズプランなら、同じ利用量で現行価格の約10倍のコストになる
    • Simon Willisonの試算では、1か月分のClaude CodeとCodexの利用は従量料金で2,180ドルになる
    • 実際に支払ったサブスクリプション料金は200ドルだった
  • フロンティアラボの方針転換:
    • この1年で大口顧客をトークン課金プランへ積極的に移行させている
    • Anthropicは2025年11月にEnterpriseプランを20ドルのシート料金と従量課金の組み合わせに変更した
    • OpenAIは2026年4月にChatGPT EnterpriseのCodexをトークン課金に移行した
  • 補助付き定額プラン利用者の懸念:
    • 一定のシート数を超えるとエンタープライズ課金が始まるため、組織が大きくなりすぎないことを願う状況にある
    • フロンティアラボが定額プラン自体の提供をやめる可能性もある
    • これは来年に向けた大きな懸念事項の1つ
  • トークン価格の動向:
    • トークン価格は下がり続けている
    • RampのAI Indexでは100万トークンあたりの実効価格が3月から41%下落した
    • 一方でAnthropicとOpenAIはともに上場準備中と報じられている
    • 安価で管理しやすいフロンティアAIの時代は間もなく終わる恐れがある
  • 先行する大企業:
    • 多くの大企業はすでにこの段階を越えている
    • Gergely Oroszの記事はStripeやUberがどう対処したかを示している
    • 好条件を享受している組織も、変化を迫られた場合の準備を始めるべき時期にある

■ 3. 消費量を理解する文化づくり

  • エンジニアに期待すべきこと:
    • 自分の消費量の確認方法(Claude Codeでは/usage)と上限を理解する
    • 利用可能なモデルの種類と、どのモデルがどのタスクに適するかを把握する
    • 自社のコードベースやワークフローに合わせたベストプラクティスの事例を見つけられるようにする
    • AIと効果的に協働するスキルを磨き、1トークンあたりの成果を最大化する工夫をする
  • Slackチャンネルの活用:
    • 専用チャンネルで議論を作り導くことで、上記の大半を実現できる
    • 上手な人に頻繁に投稿するよう促すとよい
  • マネージャーへの情報提供:
    • 管理ダッシュボードの利用データを使い、部門全体の傾向を算出する
    • 傾向には最大、最小、中央値のトークン使用量や、上限到達の有無と時期を含める
    • 各マネージャーにチームの使用量を渡し、部下が全体傾向のどこに位置するかを確認できるようにする
  • トークン量でのランク付けの禁止:
    • 人をトークン量で順位付けすると、使用量自体を目的化するtokenmaxxingを招く
    • これは本来望む状態の正反対になる
  • コード貢献との併用分析:
    • コードベースへの貢献とトークン消費を並べて分析する試みも行った
    • エンジニアリングの成果測定に関する周知の注意点は伴う
    • それでもトークン効率を改善できる人や、AIをもっと活用できる人との有益な対話のきっかけになる
  • 匿名データの共有:
    • 部門全体の匿名化した使用データを示すと、エンジニアは自分の位置を把握でき反応も良い
    • 個人名は各自のマネージャーにのみ見えるようにする
    • 請求が来るまで待つと、数字を初めて見る場がコストの話し合いになり、監査のように感じられる
    • 今のうちに始めればそれが当たり前になる

■ 4. タスクに合ったモデルの選択

  • 前提となる考え方:
    • 文化が確立したら、次はタスクに合ったモデルと推論努力量(effort)の選び方を全員に理解させる
    • 昨年の記事では、全エンジニアに十分な予算を与え、その範囲内で最適化させるべきだと書いた
  • 最新モデル一択という思い込み:
    • 最新の最高性能モデルが出るたびにそれだけを使う価値があるという前提は崩すべき
    • アプリケーションや言語、コードベースはこの半年で指数関数的に複雑化してはいない
    • 大半のタスクはOpus 5.5でなくOpus 5や旧世代の小型モデルで十分に対応できる
  • 高価なモデルの使いどころ:
    • 小型モデルが実装できる計画を生み出す、大規模な探索的タスクに使う
    • 小型モデルでは解けない特に厄介なバグに直面した時に使う
  • モデル選択の2つの軸:
    • モデルのサイズと推論努力量の2軸が常に存在する
    • Artificial Analysisの2026年10月の数値では、GPT-6 Luna(max effort)はIntelligence Index 38で1タスク約0.07ドル
    • Claude Opus 5.5(low effort)は42で0.55ドルとなり、約690%高価になる
    • effortがコストに与える影響は自明ではないため、こうしたベンチマークサイトを組織内で共有する価値がある
  • 同一ラボ内での比較:
    • Opus 5.5のlow effortとSonnet 5.5のmedium effortは、スコアが1ポイント以内で1タスクあたりのコストもほぼ同じ
    • 小さいモデルが必ずしも安く、大きいモデルが必ずしも高いわけではない
  • Uberの事例:
    • 多くのタスクでコストと品質のバランスが良いとして、推論努力量のデフォルトをmediumにした
    • 最適値は組織により異なるため、チームにeffortレベルの実験をさせて自社のコードベースに合う点を探すべき
  • トレードオフに慣れる意義:
    • これらのレバーを理解すると、手厚い定額プランが永続しない可能性を受け入れやすくなる
    • 今のうちにトレードオフを判断する習慣をつければ、全トークンが課金される時にさらに役立つ
    • AIの利用を減らすのではなく、仕事に合ったモデルを使うことが要点

■ 5. 安価なトークンが消えた後の対応

  • 10倍のコストへの備え:
    • 会社が大きく成長するか、ラボが全員に従量課金を課すと決めれば、工夫が必要になる
    • 同じトークン量を消費し続けるために10倍の料金を払う余裕は簡単には作れない
  • ルーターとオープンウェイトモデル:
    • OpenRouterやRampのRouterといったルーターへの切り替えが必要になる可能性がある
    • オープンウェイトモデルはこの半年で実用的な能力を備え、多くの場合わずかなコストで使える
    • その場合、タスクごとに適切なモデルを選び、ルーティングロジックを自作するかを判断する作業が生じる
  • AT&Tの事例:
    • 最も複雑なコード問題にはフロンティアモデルを残し、軽い作業をルーター経由でオープンモデルに移した
    • コーディングを含む一部の高度なタスクで最大56%のコスト削減を実現し、測定上の品質低下は2%にとどまった
    • この数値は比較基準となる社内の品質指標があることを前提としており、その構築も自前の作業になる
  • ハーネスの問題:
    • Claude CodeやCodexなどは、エージェントループ、ツール、コンテキスト管理、キャッシュ、モデル向けに調整したプロンプトでモデルを包んでいる
    • ルーターの世界に移ると、その多くが自分たちの課題になる
    • 今年初めにCan Bölükがエージェントハーネスの改善に時間をかける効果を示しており、これも考慮すべき事項になる
  • 支出暴走の防止:
    • 全トークンが課金されるようになれば、支出が制御不能になるのを防ぐ必要がある
    • 10年前には多くの人がAWSで請求額の不意打ちを経験した
    • Simon Willisonは、エージェントにより課金リソースを簡単に立ち上げられるため、従量課金サービスにはデフォルトで厳格な支出上限が必要だと論じた
    • その上限は、警告だけ出して後で請求するのではなく、即座に利用を止めるものであるべき
  • 習慣が生きる場面:
    • 意図的にモデルを選び消費量を把握しているチームは、ルーター中心の世界へはるかに容易に移行できる
    • トークン利用を慎重に判断する文化とスキルをすでに備えているため

■ 6. いずれにせよ習慣を築く

  • 事前にできる支援:
    • エンジニアがセッション上限への到達しか気にしていなくても、利用の実験、理解、最適化を事前に支援できる
    • すでに従量課金の組織にとっても、費用対効果を高める良い習慣になる
  • 将来への備え:
    • 従量課金になるのが明日か、来年か、10年後かは誰にも分からない
    • 消費量を可視化し、モデルサイズとeffortのコストベンチマークをエンジニアに理解させる
    • 割り当てを最大限活用する文化を築けば、何が来ても十分に備えられる
    • 機械がコインを要求し始めても、チームは何にいくら使っているか、その理由もすでに把握している