AI Codingの費用はOutcome単位で測る

TL;DR

• トークン単価や月額の請求額は入力の価格で、成果の原価ではありません。「1 PR あたりいくらか」に答えるには、分母を受け入れられた成果（マージされ、後で差し戻されなかった PR や task）に置き、分子に捨てた試行と手戻りの費用を含めます。
• この置き方をしないと、単価を下げたのに成果あたり原価が上がった状態を検出できません。公式単価から組んだ例示計算では、単価が半分のモデルに切り替えても、受け入れまでの試行が 2.5 倍に増えると原価は 25% 上がります（例示。試行回数は仮定で、特定モデルの品質を示すものではありません）。
• 手戻りの定義は数字を大きく動かします。このリポジトリで 2026-09-04〜09-16 に追加した 24 記事を数えると、「追加後に 1 回でも変更されたら手戻り」なら 24 / 24（100%）、「変更した記事が 3 本以下の狭い変更だけを手戻り」とすると 7 / 24（29%） でした（社内データ）。同じ履歴で 3 倍以上違います。
• 分母の決め方そのものは親記事 tokenmaxxingを避けるAI開発KPI が主題です。本記事は、そこで決めた「検証済み成果」を費用の分母として使う応用です。

はじめに：請求書は「いくら使ったか」しか教えてくれない

👉 この記事は tokenmaxxingを避けるAI開発KPI の子記事です。親記事では、トークン量や生成行数のような累積カウンタ型の指標は悪化を表現できず、検証済み成果に分母を与える必要がある、と整理しました。

予算の説明を求められたとき、手元にあるのはたいてい 2 つです。API の単価表と、月ごとの請求額です。どちらも「いくら使ったか」は正確に教えてくれますが、「成果 1 件にいくらかかったか」は教えてくれません。

この記事で扱うのは、その間を埋める原価計算です。単価を下げる方法（cache / batch / モデル選択）は LLM API料金の構造を分解して最適化する や Codex コスト最適化2026 が扱っています。トークン消費を減らす工夫と機能別 ROI は Vibe Codingのトークン経済学 にあります。ここではそれらの手を打ったあと、原価が本当に下がったかを確かめる側を書きます。

想定読者は、AI コーディングの費用を説明する立場の EM / CTO / FinOps 担当です。

1. 原価の式：分母は「受け入れられた成果」

使う式は 1 本です。

受け入れ 1 件あたり原価 =
  （期間中の AI 費用の総額 ＋ 手戻りに使った AI 費用）
  ÷ 期間中に受け入れられた成果の件数

ポイントは 3 つあります。

分子は請求データの合計なので、試行を 1 件ずつ成果へ紐づける必要はありません。期間で締めて総額を分母で割るだけです。紐づけが要るのは、次節のようにモデル別・チーム別に分けたいときだけです。

分母については、親記事の第 4 節で「分母を先に固定しないと桁が変わる」ことを確かめました。費用でも同じことが起きます。第 3 節でこのリポジトリの履歴を使って確かめます。

2. 単価が下がっても原価が上がる組み合わせ（例示）

以下は例示です。単価は Anthropic の公式価格ページ（2026-09-25 取得）の値で、トークン量と試行回数は説明のための仮定です。特定モデルの品質や、実際に必要な試行回数を示すものではありません。

• 単価（USD / 100 万トークン、公式値）: Claude Sonnet 5 は input $2 / output $10、Claude Haiku 4.5 は input $1 / output $5。cache read は base input の 0.1 倍、5 分 cache の書き込みは 1.25 倍（Pricing / Prompt caching）
• 仮定: 1 回の試行で input 200 万トークン、output 10 万トークン。受け入れられる成果は 7 件

C の内訳は、cache されない input 30 万トークン × $2（$0.60）、cache read 160 万 × $0.20（$0.32）、5 分 cache の書き込み 10 万 × $2.50（$0.25）、output 10 万 × $10（$1.00）です。

B は「1 試行の費用」だけを見ると A の半分です。トークン単位の管理では改善として報告されます。しかし受け入れまでの試行が 2.5 倍になると、成果あたりでは 25% 高くなります。逆に C は、試行回数を変えずに 1 試行の費用を下げているので、成果あたりでもそのまま下がります。

表から言えるのは「どちらの手が効いたかは、分母を成果に置かないと区別できない」ことだけです。B のような事態が実際に起きるかどうかは、自分のデータで測るしかありません。

請求の単位はベンダーで違います（OpenAI はトークン単価、GitHub Copilot の個人向けは AI credit。premium request 単位の課金は Copilot Pro / Pro+ の既存の年額契約で 2026-06-01 以降も旧課金に残った利用者だけが対象。いずれも References 参照）。単位が違っても、期間の請求総額を分子に置く限り式は変わりません。

3. 手戻りの定義で数字が 3 倍以上変わる（実測）

分母の「受け入れ」と分子の「手戻り」は、定義の置き方しだいで簡単に動きます。このリポジトリ（記事を Markdown で管理する Git リポジトリ）の main の履歴で確かめました。

• 測定日: 2026-09-25、基準コミット 434fb628
• 対象: 2026-09-04〜09-16 に追加された記事 24 本（content/posts/<slug>/index.md）
• 数えたもの: 追加コミットより後に、その index.md を変更したコミット

#!/usr/bin/env bash
# 追加日が [SINCE, ADDED_UNTIL] のファイルごとに、追加後の変更コミットを
# 「狭い変更（1 コミットで変更した対象ファイルが NARROW 件以下）」と
# 「一括変更」に分けて数える。追加後の変更は ADDED_UNTIL 以降も数える。
# 引数: SINCE ADDED_UNTIL 対象ファイル名の末尾 パス（pathspec）
set -euo pipefail
since="${1:?since date (YYYY-MM-DD)}"
added_until="${2:?added-until date (YYYY-MM-DD)}"
suffix="${3:?file name suffix, e.g. /index.md}"
pathspec="${4:?pathspec, e.g. content/posts}"
narrow="${NARROW:-3}"

git log --format='tformat:C %ad' --date=short --name-status \
  --since="$since" -- "$pathspec" |
awk -F'\t' -v suf="$suffix" -v U="$added_until" -v N="$narrow" '
/^C / { c++; day = substr($0, 3); next }
{ p = ($1 ~ /^[RC]/) ? $3 : $2 }
length(p) >= length(suf) && substr(p, length(p) - length(suf) + 1) == suf {
  n[c]++; path[c, n[c]] = p; status[c, n[c]] = $1
  if ($1 == "A" && day <= U) added[p] = 1
}
END {
  for (i = 1; i <= c; i++)
    for (j = 1; j <= n[i]; j++) {
      p = path[i, j]
      if (!(p in added) || status[i, j] == "A") continue
      if (n[i] <= N) narrowed[p]++; else bulk[p]++
    }
  for (p in added) printf "%s\tnarrow=%d\tbulk=%d\n", p, narrowed[p], bulk[p]
}'

このリポジトリでは 基準コミット 434fb628 をチェックアウトした状態で NARROW=3 ./rework.sh 2026-09-01 2026-09-16 /index.md content/posts を実行しました（開始日は 09-01 ですが、期間内の最初の追加は 09-04 なので対象は同じ 24 本です。追加後の変更は基準コミットまで全部数えます。基準コミットより後に記事が変わると、同じコマンドでも数字がずれます）。結果は次のとおりです（社内データ）。

記事ごとに数えた追加後の変更は延べ 65 件で、そのうち 57 件は 4 記事以上をまとめて変更した一括変更によるものでした。重複を除いたコミット数では 18 件で、うち 11 件が一括変更、7 件が狭い変更です。FAQ の書式移行や表記の一括修正のような、記事の欠陥とは関係ない変更がここに入ります。これを手戻りに数えると全記事が「手戻りあり」になり、指標として何も区別しません。

一方で「3 件以下」という閾値に根拠はありません。2 記事を同時に直した欠陥修正もあれば、1 記事だけの表記変更もあります。狭い変更のすべてが手戻りとは限らず、この 29% も上限寄りの概算です。

ここから言えるのは、手戻りの定義を決める前に比率を報告すると、同じ履歴から 29% とも 100% とも言えてしまうことです。費用の分子に手戻りを入れるなら、何を手戻りと数えるか（revert だけか、fix を名乗るコミットか、特定のラベルが付いた PR か）を先に文書に固定します。

4. 導入の手順

自チームで始めるときは、次の順で決めます。

1. 分母を 1 つに固定する。「マージされ、30 日以内に revert されなかった PR」のように、観測期間と除外条件まで書く。PR / task / 開発者のどれを単位にするかもここで決める
2. 手戻りの定義を固定する。revert、fix ラベル付き PR、同じ issue への再オープンなど、機械的に数えられるものを選ぶ。第 3 節のように、一括変更を除く条件も書く
3. 分子は請求の期間総額から始める。モデル別・チーム別に割り振るのは、総額で傾向が見えてからでよい
4. 月次で 3 つを並べて記録する。請求総額、受け入れ件数、手戻り件数。原価はこの 3 つから計算できるので、原価だけを記録しない
5. 単価を下げる施策の前後で比べる。cache やモデル切り替えの効果は、1 試行の費用ではなく受け入れ 1 件あたりの原価で判定する

人のレビュー時間も成果の原価ですが、AI 費用と同じ表に足すと単位（時間と金額）の換算が議論の中心になりがちです。最初は別の列で持ち、合算するかは後で決めるほうが扱いやすいと考えています（経験則）。

5. この測り方で解けないこと

• 成果の価値は測りません。受け入れた PR が小さな修正でも大きな機能でも 1 件です。価値で重み付けしたくなったら、それは原価ではなく ROI の話で、Vibe Codingのトークン経済学 のような効果の見込みが必要になります
• 分母が少ないと揺れます。月に数件しか受け入れがないチームでは、1 件の大きな試行錯誤が原価を何倍にも動かします。四半期でまとめるなど、期間を広げて見ます
• 受け入れが遅れて確定する。revert は後から起きるので、直近の月の分母は暫定値です。観測期間を過ぎてから確定値として扱います
• 第 3 節の実測は記事リポジトリ 1 つ、24 本の結果です。コードのリポジトリでも同じ比率になるとは限りません

FAQ

トークン単価で管理するのは間違いですか

間違いではありません。単価は請求を予測するのに必要です。ただし単価は入力の価格で、成果の原価ではありません。単価を下げる施策の効果を判定するときだけ、受け入れ 1 件あたりの原価に切り替えます。

分母は PR と task のどちらがよいですか

チームが「完了」を記録している単位に合わせます。PR は Git の履歴から機械的に数えられるのが利点で、task は PR を複数に分割する運用でも件数が安定します。途中で単位を変えると過去と比べられなくなるので、最初に 1 つ選んで固定してください。

cache を入れれば原価は必ず下がりますか

試行回数が変わらなければ下がります。第 2 節の例示では cache の書き込みは base input の 1.25 倍かかるので、再利用されない前提で書き込むと逆に高くなります。効果は成果あたりの原価で確かめます。

まとめ

• 請求額と単価は「いくら使ったか」で、原価は「受け入れ 1 件にいくらかかったか」です
• 分母を受け入れられた成果に置き、捨てた試行と手戻りを分子に入れると、単価を下げても原価が上がる状態を検出できます
• 手戻りの定義しだいで比率は 29% にも 100% にもなります。数える前に定義を文書に固定します

全体像に戻る: tokenmaxxingを避けるAI開発KPI

References

• Anthropic, Pricing（2026-09-25 取得）
• Anthropic, Prompt caching（2026-09-25 取得）
• OpenAI, API Pricing（2026-09-25 取得）
• GitHub Docs, Billing for individuals（2026-09-25 取得）
• GitHub Docs, Copilot requests（2026-09-25 取得）