スケールでのAIの隠れたコスト

2026年6月1日に 2026年6月1日, GitHubはCopilot向けの定額制「プレミアムリクエスト」を永久に廃止し、使用量ベースのAIクレジットに置き換えました。新モデルでの最初の請求書が1か月後に届いたとき、一部のエージェント型ユーザーは予想外の請求額を目にしました： ある開発者が報告したところ 最も負荷の高いエージェント型ワークフローで、月額コストが29ドルから750ドルへと急増しました。

これは2026年を通じてAIツール市場全体で起きた広範な変化の一つの顕著な例であり、現在も定額制で支払っている組織が直面する可能性があります。

組織は節約した時間を計算しますが、多くは定額制が見えなくしているコスト、すなわちコンテキスト消費や失敗後のリトライをカウントしません。ベンダーの請求書に全く現れない他のコストとして、出力のレビューやプロンプトの保守に費やす時間があります。課金が実際の消費量に移行すると、コスト管理が不十分な組織は、Copilotの新モデルが一部ユーザーを驚かせたのと同様に、予想外の請求書に直面するリスクがあります。

価格に含められないコンテキスト

AIにはコンテキストが必要なのは明らかで、議論の余地はありません。問題は送信されるコンテキストが本当に関連性があるか、単に都合よく利用できるだけかということです。全文書を送ることはモデルに情報を提供する最速の方法ですが、必ずしも最も安価あるいは最適な方法とは限りません。

2026年5月、スタンフォード大学デジタルエコノミーラボは8つの最先端モデルにわたるエージェント型コーディングタスクの分析を発表し、これらのタスクが単純なコードチャットより最大で千倍以上のトークンを消費することを明らかにしました。主な要因はモデルの出力ではなく、繰り返し再送される入力コンテキストです。エージェントは各ステップで履歴全体を再読します。同じタスクを複数回実行すると、トークン消費は最大で30倍まで変動します。

精度はコンテキスト量に比例して向上するわけでもありません。適度な量でピークに達し、その後は価値を増やさずにコストだけが増加します。

したがってトークン盲点は、AIがコンテキストを必要としないということではなく、測定がないためにそのコンテキストが本当に必要かどうかを誰も問わないという事実に起因します。定額制ではこの問題は無視しやすいですが、使用量ベースの課金ではコストの一部となります。

失敗に二度支払うとき

エージェント型ワークフローは、ROI計算にほとんど現れない別のコストを伴います。10ステップからなる単純化されたチェーンを想像してください。各ステップは単独で95％の成功率があります。十分に信頼できそうに思えますが、連結するとそのチェーンが全工程をエラーなしで完了できる確率は約60％にすぎません。

各呼び出しで蓄積されたコンテキストを再送するワークフローでは、失敗とそれに続くリトライは、単に繰り返しのステップに対するコストだけでなく、それ以前に送信されたすべての分にも再度費用がかかります。

これはほとんど全員が最初のエージェントパイプラインを構築する際に経験する共通の課題です。私自身も経験しました。初期はエージェントが数個だけだったため大きな問題ではありませんでした。しかしパイプラインが拡大するにつれ、失敗した実行ごとにコストが増大し、実行が通るかどうかだけでなく、各エージェントがどのコンテキストを必要とし、どのようにキャッシュすべきかを考えるようになりました。

同じ分析によれば、各ステップの信頼性が95％の10ステップエージェントは、完全に信頼できるシステムに比べてリトライ時に約40％多くトークンを消費します。これは請求書に現れるコストですが、ROIのスプレッドシートにはほとんど記載されないでしょう。

監視はバグではない。予算に組み込むべきだ

この点は正確に述べる必要があります。誤解しやすいからです。AIの出力をレビューすることはシステムの失敗ではなく、AIと協働する上で当然の正当な作業であり、開発者と協働する際のコードレビューと同様です。問題は出力がレビューされることではなく、この作業がAIが実際に節約した量の計算にほとんど組み込まれないことです。

GleanのWork AI Instituteは6,000人の労働者を対象に調査し、オートメーションが週平均約11時間の時間を節約すると報告しましたが、そのうちほぼ6.5時間がメンテナンス作業に費やされています：AIシステムにコンテキストを提供し、作業をチェックし、誤りを修正することです。したがって実質的な節約は約4.5時間となり、見出しの数字の半分以下です。AIは依然として時間を節約しますが、最初の数字が示すほどではありません。

プロンプトはメンテナンスが必要であり、単なる作成者だけではない

現在、プロンプトは本番コードに近い挙動を示します。モデルの更新やコンテキストの変更、些細な編集でもパフォーマンスに影響を与える可能性があります。バージョン管理やテストが行われない場合、これらの変更は静かに問題を引き起こすことがあります。コードに対して標準的に行われる回帰テストは、プロンプトの検証においてもしばしば省略されがちです。単一文の些細な編集に見える変更が本番環境に届き、誰も気付かないうちに精度を低下させ、問題が目に見える形になるまで蓄積されます。

適切な評価フレームワーク（テストセットとすべての変更に対する自動回帰テストを含む）を構築することは、ほとんど「AIが時間を節約する」計算に現れない余分な作業です。

トークンは安くなるが、請求額は増える

GitHub Copilotも例外ではなかった。CFO Diveが引用した調査によると、過去1年で米国企業の約7割が少なくとも部分的なAI予算超過を報告した、主に従量課金への完全な移行前であり、移行後ではない。

Bain & Companyは、6月のトークン経済分析で、状況全体を最も的確に捉えるパラドックスを付け加えている。トークンあたりの価格は1年で半減したが、同期間の消費は4.5倍に増加した。

モデルは安くなったが、請求額は頑固に高いままだ。企業は新しいモデルに移行し、エージェントにより複雑なタスクを与え、さらに多くのワークフローを見つけた。トークンが安くなったからといって支出が減るわけではなく、消費する理由が増えたということだ。

請求が来る前に備える方法

以下の枠組みは、AIの使用量を減らすことを目的としたものではない。AIのコストを把握した上で、さらにスケールさせるかどうかを判断するためのものだ。

1. まず可視化する

チーム、ワークフロー、アプリケーション、完了したタスクごとに消費を分解するまで、すべての拡張は盲目的な賭けになる。その可視化は無料ではない。特にエージェント型ワークフローでは、各ステップを追跡し、何が起きたか・なぜ起きたかを記録し、暴走ループを監視するためのエンジニアリング時間とツールが必要になる。これらはAI運用コストの一部として予算化し、後付けの追加費用としてではなく扱うべきだ。

2. 純利益ベースでROIを再計算する

報告された削減時間から、レビュー、修正、プロンプト保守に費やした時間を差し引く。もし時間削減がユースケースの目的であり、純結果がマイナスまたは検証できない場合、スケールする準備はできていない。品質、容量、リスク低減、収益などが目的であれば、その成果を直接測定する。

3. コスト規律は適用するが、一律にしない

失敗コストが低い内部ツール、実験的エージェント、開発環境などではハードな支出上限が有効だ。顧客向けの重要機能—たとえばカスタマーサービスアシスタント—ではハード上限は機能停止リスクを招くため実用的でない。その場合、より安価なモデルへの段階的フォールバックや早期警告アラートが必要で、ゼロでのシャットオフは避けるべきだ。

4. プロンプトと評価をエンジニアリング資産として扱う

バージョン管理し、テストし、デプロイ前に変更をレビューする—まさに本番コードを管理するのと同様に。

自社データで更新交渉に臨む

ベンダーの価格は自社の使用データがなければ評価が難しい。更新やモデル変更の前に、提案された条件下で既存のワークフローがどれだけコストになるかを算出する。目的は単に価格交渉だけでなく、実際の消費レベルでその価格がどのように変動するかを把握し、請求書で後から知るのを防ぐことにある。

今週できることは3つ：AI消費をチームとワークフロー別に分解できるか確認すること；1つのユースケースを選び、レビューに費やした時間を報告された削減時間と比較すること；ハードな支出上限がコスト制御ではなく障害を引き起こす可能性があるかを調べること。

AIコストは管理できる。ただし、請求書で初めてその実態を知るときは除く。