AI ROI は Token 単価ではない: 受け入れられたタスク一件のコストで判断する
AI 投資を拡大する前に、受理された成果、review 時間、直接費、失敗理由を同じ scorecard で測る実務的な方法。
更新日
AI の予算会議では、model price、seat 数、message 数が先に出がちです。どれも利用状況ではありますが、 有用な仕事が完了した証拠ではありません。
OpenAI が 2026 年 7 月に出した AI scorecard は、useful work、cost per successful task、 dependability、return on compute を重視します。OpenAI を使っていないチームにも有用な見方です。 大事なのは task ではなく、受け入れられた task を数える点にあります。
100 件の draft が出ても、policy に合わず reviewer が大幅に書き直し、利用されなければ価値は増えません。 明確な基準で承認され、次工程で安全に使われ、従来より低い総投入で済んだ時だけ、ROI を主張できます。
実行前に「受入」を定義する
attempt を数えると数字はよく見えます。最初の run より前に acceptance rule を書くと、判断が使える ようになります。
support reply なら、最新 policy に従い、正しい account facts を参照し、軽微な修正一回以内で、SLA 内に送れること。coding task なら、test が通り、repository rule を守り、review を通り、後続 incident を起こさないこと。営業調査なら、担当者が再調査なしに次の action を決められることです。
「テキストを返した」は acceptance ではありません。「reviewer が基準に従って承認し、修正が三分以内」 なら繰り返し測れます。
一つの scorecard に置く項目
同じ task set を固定します。通常ケース、edge case、正解が拒否や escalation になるケースを入れます。 model を変えるたびに問題を入れ替えないことが重要です。
| 項目 | 見えること | よくある誤り |
|---|---|---|
| task type と risk | 仕事ごとの差 | 簡単な仕事と高 risk を平均する |
| accepted / rejected | 実際の pass rate | review 前の draft を成功にする |
| review minutes | 隠れた人件費 | reviewer の時間を無料とみなす |
| direct cost | model、tool、infrastructure の支出 | token 単価だけを見る |
| failure reason | 次に直す層 | 全てを prompt の弱さにする |
| reuse / downstream result | 継続価値 | 生成時点で計測を止める |
式は単純です。
受理タスク一件のコスト =（AI 直接費 + review 人件費 + 失敗復旧費）/ 受理タスク数
会計基準ではなく、見落としを防ぐための式です。安い token を選んでも、毎回十二分の確認と retry が 必要なら、安い workflow ではありません。
model 比較から workflow 設計へ
A は一回 0.08 ドルで pass が 55%、review 六分。B は 0.24 ドルで pass が 82%、review 一分なら、 token 比較では A が安く見えます。しかし人間の時間と失敗を入れると逆転します。もちろん B が自動的に 正解ではありません。rare case の危険性、地域での利用可能性、batch review のしやすさも評価します。
失敗を四つに分けると改善が早くなります。input failure は最新文書や権限がないこと、execution failure は tool や retrieval の失敗、acceptance failure はもっともらしいが基準外の出力、economic failure は 使えるが review や費用が高すぎる状態です。Context Engineering が 必要なのは、prompt の言い換えでは存在しない業務情報を作れないからです。
20 から 50 件の baseline を作る
実務から代表的な task を 20-50 件選び、必要なら匿名化します。期待される結果、使ってよい source、 人に渡す条件を明記し、manual process と AI-assisted process を同じ set で比べます。elapsed time、 review time、direct spend、acceptance、rejection reason を残します。
日本のチームでは稟議資料、日英文書、個人情報、承認者の確認時間も review cost に入れます。model の ドル価格だけでは、実際の delivery cost になりません。spreadsheet と一定の review ritual でも、成功の 定義がない dashboard より良い baseline になります。
停止条件も先に決めます。低 risk task の pass が決めた水準に届かない、review が manual baseline を 超える、高 severity error が出る、accepted output より cost が早く増える、失敗理由を説明できない。 その時は scale ではなく、task boundary、context、approval rule を直すか止めます。
最初の ROI は、分類、許可済み source からの調査、review 前提の下書き、structured data の確認のような 反復的で半自動の仕事に出やすいです。「成長戦略を全部任せる」のような広い委任では、何が成果を作ったか 測れません。興奮ではなく、accepted work と総コストが増額の根拠です。
