Argus Wake Insights
生成AIのトークンコストは、なぜ日本企業の予算サイクルと噛み合わないのか
要旨
- 結論
- AIのトークンコスト最適化とは実装テクニックの問題ではなく、年間固定枠のAI予算を四半期単位の見直し対象へ設計し直す稟議・予算プロセスの問題である。
- 根拠
- SemiAnalysisの試算ではMicrosoftの同じ計算資源でも用途によって1MWあたりの年間収益に約7倍の差があり、米メディアEveryではAIコストが230%跳ね上がり、新モデルのテスト時には12時間足らずでクレジット残高が尽きた。
- 決めること
- 9〜10月の下期予算編成で、AI予算に「四半期見直し条項」と支出の妥当性を判定する問い(何にかかったか・何を得たか・何を学んだか)を明記するかを決める。
なぜ「◯選」記事ではトークンコストの予算問題に答えられないのか
AIコスト最適化 トークンで検索すると、上位に並ぶのはプロンプトキャッシュ・バッチ処理・モデル使い分けといった実装テクニックを列挙する「7つの方法」型の記事ばかりだ。中小のSIerや受託開発会社のオウンドメディアが多くを占め、エンジニアが明日から使えるHowToとしては有用でも、経営層や情シス責任者が本当に知りたい問い、すなわち「このコストをいつ・どう予算に織り込むか」には一切答えていない。
トークンコストの最適化は、突き詰めればエンジニアリングの実装課題ではなく、稟議と予算サイクルの設計課題である。海外の元記事を起点に、この論点を経営の意思決定として捉え直したい。
海外の値下げ発表・決算開示は何を意味するか
コンピュート容量の経済性を考えるうえで示唆的なのが、Microsoft と OpenAI の契約再編をめぐる事実だ。AI の計算資源はどの事業に配分すべきか — SpaceX 10GW 計画と Microsoft の容量配分のねじれに学ぶで取り上げたとおり、SemiAnalysisの試算では、Microsoft の計算資源の多くはOpenAI向けに約1400万ドル/MW/年で使われている一方、Foundryや Copilot などのAPI・アプリケーション事業で自社運用すれば約1億ドル/MW/年の機会があり、その差は約7倍になる。2025年10月に結んだ2500億ドル規模のインフラ契約(SemiAnalysisは約7GWと推計)で容量の多くがOpenAI向けとなった結果、Microsoft は他の用途で容量不足に陥り、OpenAIモデルをFoundryやCopilotで十分に活用できていないという。2026年4月に見直された契約では、従来の20%の収益シェアが外れている。
これは単なるインフラ企業の話ではない。SemiAnalysisは推論トークンの提供を極めて高利益率のビジネスと見ており、同じ「AI予算」という括りの中でも、どの用途に割り当てるかで得られるリターンが大きく変わりうることを、この試算は示している。ただし数字は同社の推計であり、実績の開示ではない。
もう一つの元記事が示すのは、モデル選定そのものがコスト構造を左右するという事実だ。Claude Opus 5 は業務導入に値するか——プロンプト資産を積み上げた環境ほど性能が落ちる評価結果が報告しているのは、Everyでは、旧モデル向けに作ったスキルやプラグインとOpus 5がぶつかり、それらの指示を削除すると、Opus 5が時に劇的に良くなったという観察だ。なお、この元記事は冒頭の要約部分のみに基づく。そこから言えるのは、旧モデル向けの仕組みを見直さないと新モデルの力を引き出せない場合があるという点までで、トークン消費量への影響は書かれていない。本稿は、既存のプロンプト設計やツール連携が最適化されていない組織は同じ成果に余分なコストをかけている可能性がある、と読む。トークン単価だけを見て「安いモデルに切り替えれば最適化できた」と判断するのは早計であり、モデル更新のたびにワークフロー側の複雑度を見直さない限り、コストは静かに膨らみ続ける。
この構造を裏付ける実録が2026年8月に出てきた。AI 利用コストの予算管理はどうすべきか ― 支出230%増でもトークン予算を設けない Every の判断基準で取り上げた米メディア Every の事例では、GPT-5.6 Sol の公開後、日次のOpenAIクレジット消費が直前週の約2.5倍に膨らみ、新モデルのテスト時には12時間足らずでクレジット残高が尽きた。それでも同社は支出上限による統制を選ばず、決済カードの利用枠という止血点と全社員が見られる利用ダッシュボードだけを固定し、月間3万ドル超の支出を容認している。象徴的なのは、ほぼ同額(約480ドル)の支出でも、プロダクトの権限基盤を構築した1件は是とされ、SlackとメールをTend(Dan Shipper 氏のオープンソース生産性ツール)に15分おきに確認させた1件は当日中に頻度を見直した点だ。判定基準は金額ではなく「何を得たか・何を学んだか」であり、事前の予算枠という静的な統制では捉えられない。さらにAIエージェントでエンジニアチームを何人分置き換えられるか ― Codex カスタムエージェントによる「1人企業」の実例が報告するとおり、Monologueの唯一の人間エンジニアはCodex のカスタムエージェント群をチームのように動かして開発を進めている。同じ記事では、Everyのデザインチームがカンファレンス Thesis のビジュアルアイデンティティ・サイト・ローンチ素材を約3週間で作り、リードデザイナーはAI以前なら4か月以上かかったと見積もっている。トークン消費は増える一方で、その増分が人件費換算で何を代替したかを測れる組織だけが「高い支出」と「無駄な支出」を区別できる。
稟議・予算サイクルにいつ・何を反映すべきか
これらの事実から日本企業の予算判断に持ち帰るべき論点は1つに絞れる。AI予算を年度初めに一括で確保し、年間固定の枠として運用する稟議の組み方そのものが、コンピュート経済性の実態と噛み合っていないということだ。
Microsoft の事例から本稿が引き出す教訓は、AI関連の計算資源・トークン予算は用途別の収益性で並べ替え、四半期ごとに再配分を決める会議体を持つべきだということだ。日本企業の多くは年度予算の枠内でAI関連コストを一括管理し、部署ごとの既得権や契約の古さで予算を固定してしまいがちだが、これでは高収益な用途への機動的な再配分ができない。加えて Opus 5 の事例が示唆するように、モデルを切り替えるたびに既存のプロンプト・スキル資産のパフォーマンスを検証しなければ、料金表上の値下げが実際のコスト削減に直結しない可能性がある。特に社内で稼働を広げるAIエージェントはループ処理や自律的なタスク実行によってトークン消費量が読みにくく急増しやすいため、エージェント単位でのコスト管理を切り分けて予算プロセスに組み込まなければ、四半期ごとの再配分の議論自体が土台を欠いたものになる。
したがって稟議・予算サイクルに反映すべきは、(1) AI関連予算を年間固定枠ではなく四半期単位の見直し対象として設計し直すこと、(2) モデル更新のタイミングを予算申請プロセスに組み込み、更新前後でワークフローの再検証を必須項目にすること、の2点だ。どちらも「実装で解決する」問題ではなく、予算プロセスの設計変更として経営が意思決定すべき事項である。
折しも3月期決算企業の多くは、9〜10月に下期予算の編成期を迎える。Every の実録が示すように、AIコストは新モデルの登場を境に2倍超のスケールで動く。下期のAI予算を上期実績の延長線で置くのではなく、この編成タイミングで「四半期見直し条項」と「支出の妥当性を判定する問い(何にかかったか・何を得たか・何を学んだか)」を予算文書に明記できるかが、来期の機動力を分ける。
まとめ:コスト最適化は実装ではなく予算判断の問題
日本語トークンのコスト構造は英語圏とは異なる特性を持つが、それ以上に重要なのは、コンピュート容量の収益性もモデルの実効コストも、四半期単位で変動し続けるという事実だ。「◯選」記事が提示する実装テクニックは、この変動を吸収する仕組みが予算プロセス側にあって初めて効いてくる。稟議のタイミングと単位そのものを見直すことが、AIコスト最適化の出発点になる。
この論考への質問
AIのトークンコストを最適化するにはどうすればいいのか?
プロンプトキャッシュやモデル使い分けといった実装テクニックは、変動を吸収する仕組みが予算プロセス側にあって初めて効いてくる。AI予算を年間固定枠ではなく四半期単位の見直し対象として設計し直し、モデル更新のたびにワークフロー側の複雑度を再検証することが出発点になる。
AIエージェントのコストはなぜ急増しやすいのか?
ループ処理や自律的なタスク実行によってトークン消費量が読みにくく、急増しやすいためだ。エージェント単位でのコスト管理を切り分けて予算プロセスに組み込まなければ、四半期ごとの再配分の議論自体が土台を欠く。
AI予算には支出上限を設けるべきか?
米メディアEveryは月間3万ドル超の支出でも上限による統制を選ばず、決済カードの利用枠と全社員が見られる利用ダッシュボードだけを固定した。判定基準は金額ではなく「何を得たか・何を学んだか」であり、静的な予算枠より支出の妥当性を判定する問いの設計が重要になる。
この記事の調査と下書きにはAIを使っています。数値や事実は出典と照合し、公開するかどうかは運営者が判断しています。(制作方針)