生成AIの導入を進めると、利用回数、アクティブユーザー数、削減した工数、そしてAPI料金がダッシュボードに並ぶ。しかし、トークンを多く使ったチームが事業価値を多く生んだとは限らない。大量の再試行、長すぎるコンテキスト、レビューされない出力でも、トークンだけは増えるからだ。
BCGのレポート「トークンベース競争の時代が到来」は、希少だった「知性」がAIによって利用可能になるほど、競争優位はAIを保有することではなく、業務の中で生産的に活用することへ移ると論じる。本稿では、同レポートの事実関係を整理したうえで、IT技術者がこの考え方を評価、予算、権限、監査まで落とし込む方法を考える。
先に確認しておきたい：16.5%対5.1%は何を意味するのか
BCGは、年商5億ドル超の上場テクノロジー企業107社を分析し、トークン消費量が上位20%の企業群の前年比売上高成長率中央値を16.5%、下位20%を5.1%と報告している。ここで観測しやすい対象として挙げられているのは、CursorのようなAIコーディング環境を使うソフトウェアエンジニアリングである。BCG原文の分析範囲を越えて、「トークンを増やせば売上が3倍になる」と読むことはできない。
この数値は、成長企業ほどAIを多く使うという逆向きの関係、企業規模や投資余力、開発領域の違いを切り分けた因果推論ではない。したがって実務上の問いは「何トークン使ったか」ではなく、次の二つである。
- どの業務フローで、どの品質・速度・売上機会を改善したか
- その改善を維持するために、人、モデル、データ、レビューにいくら払ったか
トークンベース競争とは「AI利用量の競争」ではない
トークンは、LLMがテキストやコードを処理する単位であり、API利用料や処理量の基礎になる。BCGがいう「トークンベース競争」は、トークンを買い込む競争ではない。AIを業務の中核に組み込み、人間の判断と組み合わせて、より速く・高品質に・継続的に価値をつくる組織能力の競争である。
たとえば障害対応で考える。チャットボットに「障害報告を書いて」と依頼するだけなら、局所的な時短で終わる。一方で、監視アラートから関連する変更履歴・Runbook・過去事例を検索し、影響範囲と復旧候補を根拠付きで提示し、当番が承認して実行し、結果を次の評価データへ戻すなら、改善対象は業務フロー全体になる。
この循環を設計して初めて、AIの性能向上や単価低下を事業の改善へ取り込める。逆に、入力と出力だけを残す仕組みでは、誤答、権限逸脱、コスト増大が見えないまま利用量だけが増える。
4つの提言を、運用可能な設計へ翻訳する
1. ROIntは「価値 ÷ 人件費とトークン費」の比較軸
BCGはROInt（Return on Intelligence、知的資本利益率）を、次の式で提案している。
ROInt = アウトプットの価値 ÷（人間の労働コスト + トークンコスト）
ここで難しいのは分母ではなく「アウトプットの価値」だ。開発支援なら、生成コードの行数ではなく、リードタイム、障害流出率、レビュー手戻り、顧客へ届いた機能、保守コストで定義する。問い合わせ対応なら、単なる自己解決率ではなく、解決品質、再問い合わせ率、顧客満足、有人引き継ぎの適切さまで見る。
| 用途 | 価値の候補 | 同時に置くべきガードレール |
|---|---|---|
| コード生成 | リードタイム、変更失敗率、修正回数 | テスト通過率、脆弱性、レビュー率 |
| 問い合わせ対応 | 解決率、初回応答、CSAT | 誤案内率、再問い合わせ率、有人転送率 |
| 社内調査 | 意思決定までの時間、再利用率 | 根拠リンク率、更新切れ情報、機密漏えい |
ROIntはベンダー横断の絶対的な正解ではない。異なるユースケースを比べ、投資を再配分するための経営・運用上の仮説である。価値の定義、対象期間、品質条件をユースケースごとに記録しなければ、分子だけを都合よく大きく見せるKPIになる。
2. トークン予算はITだけで抱えず、事業責任と結びつける
BCGはトークン支出の説明責任を、コストセンター化しがちなIT部門だけでなく、経営企画、AI推進、財務、事業部門に接続するよう提言する。これはITが請求を放棄するという話ではない。利用を決める事業側が、価値・上限・継続判断に責任を持つという分担である。
最低限、ユースケースごとに以下を台帳化するとよい。
use_case_id / 事業オーナー / 利用モデル・リージョン / 月額上限
価値KPI / 品質しきい値 / 利用可能データ区分 / 承認者
フォールバック手順 / 停止条件 / 監査ログの保管期間
財務には予算アラートと原価配賦、プラットフォームチームにはモデルルーティング、レート制限、キャッシュ、利用ログの責任がある。事業オーナーには「上限を超えても続ける理由」と「品質が下がったら止める判断」を持ってもらう。この三者を分けないと、事業部門は無制限に使い、ITは一律に止めるという対立になりやすい。
3. 人を減らす前に、人が担う判断と復帰経路を設計する
レポートは、AIを労働の代替だけでなく人材の能力拡張として扱うべきだとする。顧客対応の人員をAIで削減した企業は20%にとどまったという数字も引用されている。これはGartnerが2025年10月に実施したカスタマーサービス／サポート責任者321人への調査の結果であり、Gartnerの発表でも確認できる。全職種・全業界にそのまま広げられる数値ではない。
技術設計では、AIの前後にある人間の役割を消さないことが重要だ。
- 問題の優先順位と、AIへ渡してよいデータの判断
- 出力根拠、例外、顧客影響のレビュー
- 送信、発注、権限変更など不可逆な操作の承認
- 失敗時の有人引き継ぎ、ロールバック、顧客説明
人間を「最後に承認ボタンを押す人」にしない。レビュー可能な根拠、却下理由、再実行条件を残し、担当者が修正から学べるようにする。これがないと、AIが扱えない例外だけが人に集まり、品質も定着率も下がる。
4. 文化変容は研修回数ではなく、業務フローの変更として測る
BCGは、AIを自律的に使っている従業員が10%未満だという調査結果を紹介している。ここでいう自律的な利用は、単発の回答支援ではなく、複数段階の業務をエージェントへ委任する利用を指す。すべての仕事を自律化すべきという意味ではないが、導入アカウント数や受講者数だけでは定着を測れないことは確かだ。
定着を確認するなら、次を四半期ごとに追う。
- 対象業務のうち、AIを組み込んだ標準手順を通った割合
- 根拠付き出力の採用率、差戻し理由、有人へのエスカレーション率
- 失敗・停止・復帰の演習を完了したチームの割合
- 品質しきい値を満たした状態でのROIntと、顧客・従業員への影響
研修の目的も「プロンプトが書けること」ではなく、いつAIを使うか、どこで検証するか、どこから先は人が責任を持つかをチームで合意することに置くべきだ。
IT部門が最初の90日で確認するチェックリスト
- 業務を一つ選ぶ：高頻度で、価値KPIと品質の基準を置け、例外時に人が復帰できる業務から始める。
- 評価セットをつくる：正常例だけでなく、古い情報、権限外データ、曖昧な依頼、失敗時の引き継ぎを含める。
- 権限を最小化する：閲覧・下書き・提案・実行を分離し、実行権限には目的、金額、回数、期限、承認をモデル出力の外側で強制する。
-
費用と価値を同じIDで結ぶ：モデル、トークン、ツール実行、担当者のレビュー、成果KPIを
use_case_idと実行IDで相関できるようにする。 - 止められることを試す：コスト上限、品質低下、異常なツール実行、データ持ち出しの兆候で止まり、手作業へ戻れることを演習する。
勝つのは「多く使う企業」ではなく、価値へ戻せる企業
トークンベース競争という言葉は、AI予算を増やせという号令に見えやすい。しかし、BCGの提言を運用へ翻訳すると、要点は反対に近い。トークン消費を目的化せず、価値、品質、権限、監査、停止を一つの業務フローとして設計し、改善を回せる組織をつくることである。
AIは導入した時点では、まだコストと可能性の集合にすぎない。どの成果に使い、どの失敗を許容せず、誰が根拠を確認して責任を持つか。その設計を継続的に更新できることが、利用量を競争優位へ変える条件になる。
作成日: 2026年8月13日