AI機能の費用を比べるとき、つい「入力・出力トークンが安いモデル」を探してしまいます。けれど実務では、安いモデルを何度もやり直したり、人が長く修正したりすると、結局高くつきます。
OpenAIが2026年7月17日に公開した Useful Intelligence per Dollar は、このズレを正面から扱う考え方でした。要点は単純です。AIの価値は、トークンではなく品質基準を満たして完了した仕事で測る。
この記事では、Web開発チームがすぐ始められる最小の計測設計に落とします。
結論
- 比較単位を「API呼び出し」から「完了した仕事」に変える
- コストにはAPI料金だけでなく、人の確認・修正・再試行の時間を入れる
- 結果を「そのまま完了 / 修正して完了 / 人へ引き継ぎ」の3状態で残す
- まずは一つの定型業務を一週間測る。全社ROIを先に作らない
なぜトークン単価だけでは足りないのか
たとえばAIに問い合わせ回答を作らせる場合、モデルAは安いけれど3回に1回は根拠が不足し、担当者が10分直すとします。モデルBは1回のAPI料金が高くても、ほぼそのまま使えるなら、回答1件を完了するまでの総コストはBのほうが低いかもしれません。
コーディング支援でも同じです。出力トークンが少なくても、テストが通らずレビューで戻るなら、チーム全体では安くありません。
先に「完了」を決める
モデル比較の前に、対象業務の完了条件を一文で決めます。
| 業務 | 完了条件の例 |
|---|---|
| 問い合わせ対応 | 根拠付きの回答を担当者が承認した |
| コード修正 | テストと静的解析を通り、レビューで採用された |
| 社内調査 | 出典つきの要約を依頼者が利用可能と判断した |
「AIが文章を出した」は完了条件にしません。利用者または次工程が受け取れる状態までを1件にします。
成功タスク単価を計算する
最初は概算で十分です。
成功タスク単価 =
(API・インフラ費 + 人のレビュー時間 + 修正・再試行時間) / 完了件数
人件費まで厳密に会計処理する必要はありません。まずはレビューや修正にかかった分を記録し、モデルや設定を変えたときに総作業量がどう動いたかを見るための式です。
3状態だけ記録する
複雑な評価表より、次の3状態を残すほうが先です。
- そのまま完了: 追加修正なしで品質基準を満たした
- 修正して完了: 再プロンプトまたは人の軽い修正で完了した
- 人へ引き継ぎ: AIだけでは完了できず、人が主に処理した
この分類があると、成功率の低さを一括りにせず、原因を探れます。たとえば「情報が足りない」のか、「外部ツールの権限がない」のか、「モデルの出力品質が届かない」のかは、打ち手が違います。
スプレッドシートの最小列
一つの業務に対して、次の列だけ作ります。
task_id, completed_definition, model_config, api_cost,
human_review_minutes, retry_minutes, outcome, failure_reason
outcome は3状態から選択、failure_reason は context / tool / permission / quality などに固定すると集計しやすくなります。
一週間後に見るもの
見る順番は、単価より先に品質です。
- 「そのまま完了」の割合は上がったか
- 人への引き継ぎはどの理由で起きたか
- 成功タスク1件あたりの人の時間は減ったか
- そのうえで、成功タスク単価は下がったか
AIの利用量やトークン量が増えていても、完了件数や品質が動いていなければ、投資効果とは言いにくいです。
注意点
この枠組みはOpenAIによる提案で、共通の会計標準ではありません。また、高リスクな業務で人の承認を外す根拠にもなりません。モデルを比較するなら、入力、完了条件、確認工程を揃えて測る必要があります。
まとめ
AIの費用を下げる最短経路は、必ずしも安いトークンを選ぶことではありません。やり直しと人の修正を含めて、仕事が一度で終わる構成を増やすことです。
まずは一つの定型業務だけ、成功した1件を測るところから始めると、モデル選定・プロンプト・ツール連携の改善が同じ数字で話せるようになります。
公開前チェック
- 実際の問い合わせ対応またはコードレビューで1週間分の測定例を追加する
- 人の時間を金額換算する際の前提を明記する
- モデル比較を載せる場合は、同一入力・同一品質基準の実測に限定する