AI 機能の原価・品質・顧客価値・継続を一つの運用系にする

最終確認: 2026-08-01
対象: LLM、RAG、画像・音声、agent、AI 補助を Web アプリへ組み込み、個人または小規模で販売・運用する開発者

この章は管理会計、プロダクト分析、AI 品質運用を接続する設計である。会計上の原価区分、売上認識、税務、個人情報、安全性、契約上の責任を一律に決めるものではない。価格、モデル仕様、請求 SKU、規約は変わるため、実装・販売・月次照合時に公式情報と実請求を再確認する。

この章の役割

AI 機能には、技術的に正しい eval、顧客が実際に得た価値、provider へ払う現金、人が修正した時間、顧客が次周期にも戻った事実を同じ判断へ接続する必要がある。既存章の正本境界は次のとおり。

一般の価格、粗利、MRR、GRR/NRR、LTV: 02
価値イベント、TTFV、画面内 onboarding、継続設計: 03
AI の実装、offline eval、release gate、SLO、agent 権限: 05
repo 内の task、threat、eval artifact、exact SHA、PR、engineering release/rollback 証拠: 13
12 週間の最小経営 dashboard と実験ログ: 07
創業者時間、完全負荷後貢献、容量、13 週現金: 09
platform 費、agent 委任、取引後貢献: 10
paid pilot、first/repeat/independent value、本契約・更新: 11
有償サービス工程、標準範囲、例外、productization candidate と delivery mode: 14
AI 機能の job、attempt、provider usage、quality、人手、value、account cycle の結合と判断: 本章
コピーして使う書式: AI 機能 operating review

本章は「どのモデルが一番賢いか」を決める章ではない。次を、一つの feature / workflow / customer job について判断する章である。

顧客に使う機会があったか
→ 実際の業務 job を開始したか
→ 何回の attempt / provider call / tool action を要したか
→ 最初と最終の品質はどうだったか
→ 誰が何分確認・修正したか
→ 顧客の業務価値になったか
→ 現金と創業者時間を引いて貢献が残ったか
→ 自然な次周期に、創業者なしでも価値が再現したか

先に結論

AI 事業で危険なのは、モデル呼出しの成功を顧客成功と呼び、平均 token 費を原価と呼び、機能を一度使った人の継続を機能効果と呼ぶことである。

HTTP 200 ≠ 有効な出力
schema valid ≠ 内容が正しい
良い出力 ≠ 顧客 job の完了
job 完了 ≠ 顧客価値の確認
一度の価値 ≠ 反復価値
機能利用者の高い継続 ≠ 機能による継続改善
catalog price × token ≠ 実請求原価
平均原価が低い ≠ 上位利用・loop・事故でも採算が守られる
人が直せる ≠ 人手込みで事業が成立する

最小の運用原則は次の七つである。

主分母を provider call でなく、顧客成果を一回求める job にする。
job、attempt、provider call、tool action、human work、account cycle を別 event にする。
品質を first-pass、最終結果、重大失敗、顧客価値に分ける。
原価を estimated と invoiced、現金と内部時間、平均と tail に分ける。
継続は login でなく自然な次周期の価値で測り、早期解約・停止を分母から落とさない。
安全・権利・不可逆操作の Red は、平均品質、売上、標本数で相殺しない。
欠損、未成熟、分母 0、小標本は Unknown と表示し、Green に丸めない。

先に「何を決める指標か」を固定する

一つの dashboard へ数字を増やす前に、意思決定を固定する。

決定	必要な証拠	典型的な行動
AI を使うか、決定的処理へ戻すか	顧客価値、誤りの検出可能性、完全負荷原価、安全	限定補助、rule/code 化、停止
route / model / prompt / retrieval を出荷するか	層別 offline eval、shadow/canary、本番 quality、cost、latency	promote、hold、rollback
値付け・利用枠を変えるか	account-cycle revenue、cash COGS、human work、tail usage	値上げ、allowance、超過、範囲縮小
自動化を一段上げるか	independent value、重大失敗、tool authorization、取消し、監査	draft→approve→限定 execute
機能を拡張するか	repeat value、正の貢献、容量、継続の比較可能な証拠	expand、segment 限定、停止

一つの指標で五つを決めない。たとえば first-pass acceptance は出力品質の診断には使えるが、値上げ、継続改善、自動実行の許可を単独では決められない。

粒度を七つに分ける

1. Eligible opportunity

顧客に、その機能を使える自然な業務機会が発生した単位。機能を見なかった、使わなかった、開始前に離脱した事実を失わない。

例:

月次レポートを作るべき 1 社 × 1 月
受信した審査対象文書 1 件
顧客へ返信すべき問い合わせ 1 件

分析上は、eligible opportunity の発生時に job_id を一つ作り、開始しなくても残す。標準関係は eligible_opportunity_id 1 : 1 job_id とする。

eligible job
├── started_at = null              # 使わなかった
└── started_at != null
    └── attempt 1..n

一つの商談や月次業務から複数成果を作る場合は、介入前に別々の eligible opportunity へ分ける。逆に複数画面・prompt が一つの成果なら一 job にまとめる。1:N のまま率を作らない。自然な job 機会を列挙できない製品では account-cycle の exposed accounts を代替分母とし、eligible-job adoption と呼ばない。

2. Job

顧客が一つの業務成果を求める分析単位。eligible opportunity 発生時に作り、再生成、fallback、provider timeout を新しい job にしない。

job_id = 一つの eligible な顧客成果要求

処理、受入、価値、incident 観測を一つの terminal enum に混ぜない。それぞれ独立した状態と期限を持つ。

軸	状態例	成熟時計
execution	`not_started / completed / no_output / abandoned / stopped_for_safety / expired`	job の処理期限
acceptance	`not_assessable / accepted_first_pass / accepted_after_correction / rejected / unknown`	顧客・review の受入期限
value	`not_due / confirmed / not_confirmed / unknown / reopened`	事前定義した価値観測期限
incident	`none_observed / open / confirmed / closed / reopened`	risk tier ごとの固定観測期限。後日の発見で再開可能

quality_mature_at、value_mature_at、incident_mature_at を分ける。出力が当日受け入れられても、月末短縮を確認する価値や incident 観測は未成熟であり得る。期限後の苦情・事故・訂正は上書きせず reopened event を追加して再集計する。unknown や expired を削除すると、時間のかかる失敗だけが分母から落ちる。

3. Attempt

同じ job を完了するための一回の処理方針。retry、prompt 変更、model fallback、人手からの再投入を別 attempt にする。

job 1 件
└── attempt 1..n
    └── provider call 0..n

attempt-level 成功率は障害診断には使えるが、顧客 job success の代用にしない。失敗するたび attempt を追加すれば、成功した最後の attempt だけを見て品質を良く見せられるからである。

4. Provider usage

provider が課金または利用量計測する最小単位。model call、cached input、output、reasoning、image/audio、search、storage、session、container、batch 等を provider の SKU に合わせて記録する。

provider_call_id は必ず attempt_id → job_id へたどれるようにする。provider が request 単位でない請求を行う場合も、合理的な配賦規則と未配賦額を残す。

5. Tool action

検索と、外部状態を変える action を同じ「tool call」にしない。

read/search
draft/propose
write/update
send/publish
delete/revoke
purchase/pay

提案、承認、実行、取消し、失敗を別時刻で持つ。副作用の品質は文章品質とは別で、対象、引数、権限、結果、重複実行、取消し可能性で評価する。

6. Human work

レビュー、修正、顧客確認、support、incident、例外処理を分けて時間記録する。

human_work_cost
= minutes / 60 × role_internal_hourly_cost

actor_side = provider/founder/customer、work_class = planned_review/correction/support/incident/founder_rescue/customer_review を持つ。provider/founder の時間は原価・容量へ、customer の時間は価値摩擦へ入れ、同じ金額へ足さない。契約上予定した human approval は independent value を妨げないが、顧客固有の非標準 founder rescue は妨げる。境界を workflow ごとに介入前に固定する。

創業者の時間は現金支出でなくても、完全負荷後貢献と容量には入る。09 章と同じ内部時間価値を使い、二重計上しない。

7. Workflow value cycle と commercial cycle

価値の反復周期と、売上・請求・契約の周期を分ける。

workflow_value_cycle_id
= account_id + natural_cycle_start + workflow_id

account_commercial_cycle_id
= account_id + billing_or_contract_period_start + contract_id

月額課金でも、業務が四半期なら週次 login を retention としない。一つの account に複数 workflow がある場合、各 value cycle を commercial cycle へ多対一で map する。同じ月額売上を workflow ごとに複製しない。明示的 add-on 売上または事前定義した配賦規則がなければ、feature revenue は unallocated とし、account-commercial-cycle の貢献だけを出す。

一つの metric contract を使う

指標名だけでは再現できない。各指標に次を固定する。

項目	固定する内容
Decision	悪化・改善時に何を決めるか
Grain	job、attempt、call、account-cycle 等
Numerator	数える event と重複排除 key
Denominator	eligible population と key
Window	event time / processing time、開始・終了時刻
Maturity	結果が確定したと数える条件
Segment	feature、workflow、risk、customer、route、version
Exclusion	test、fraud、顧客明示取消し等の事前規則
Missingness	欠損、late event、分母 0 の表示
Source	正本 table/event、請求照合元
Owner	定義、データ品質、行動の責任者
Trigger	Stop / Pause / Change / Expand の条件
Version	定義変更日、旧定義との接続

rate だけでなく 17 / 23 jobs のように分子・分母を表示する。小標本では p90/p99 や小数点以下の差を精密に解釈せず、全 job の状態、最大原価、重大失敗の原文を見る。

品質を四段に分ける

1. First-pass quality

最初に顧客へ提示・commit された有効出力が、提示後の再生成や重大な修正なしで受け入れ可能かを見る。transport retry、provider fallback、内部 validation が顧客提示前に完了したなら、first-pass content の回数は増やさない。ただし全 request を cost、latency、reliability へ入れる。

job activation rate
= started jobs / execution-mature eligible jobs

first-pass acceptance among started jobs
= accepted_first_pass の quality-mature jobs
  / quality-mature started jobs

end-to-end first-pass value
= first presented output が material correction なしで value-confirmed の jobs
  / value-mature eligible jobs

前者は生成品質、後者は採用を含む顧客成果を診断する。両者の名前を同じ first-pass rate にしない。出力が生成された jobs だけを分母にすると timeout、no output、開始後離脱を隠すため、started jobs を使う。

2. Final task quality

final acceptance rate
= final accepted quality-mature jobs / quality-mature started jobs

human-touch rate
= review、correction、support のいずれかを要した jobs
  / quality-mature started jobs

final acceptance が高くても human-touch が高い場合、製品でなく人手サービスが品質を作っている可能性がある。これは悪いとは限らないが、価格、SLA、容量へ正直に反映する。

3. Critical failure

次を平均点に混ぜず、一件でも独立表示する。

機密・個人データの不適切な開示
権限外・対象違い・金額違いの write/send/pay/delete
根拠のない高損害判断を確定事項として出す
tenant 越境、provenance 消失、監査不能
取消不能な重複実行
契約・法令・権利上使えない入出力

critical-failure job rate
= 固定した incident 観測窓を閉じた relevant started jobs のうち、
  重大失敗を 1 件以上含む jobs
  / 同じ観測窓を閉じた relevant started jobs

率の成熟を待って Stop を遅らせない。as_of までに疑義化・確認された critical incident は、観測窓に関係なく件数、affected account/action、severity で全件表示し、Stop-now を判定する。率は比較用で、effect-capable job なら started job、high-risk commit なら committed action のように relevant population を metric contract で固定する。一つの job 内で error を多数数えて率を膨らませず、種類別件数も残す。

4. Customer value

出力受入と価値確認を分ける。

output accepted: 形式・内容が利用可能
workflow completed: 顧客の業務が終了
value confirmed: 時間、品質、売上、損失回避等の事前定義した成果を確認
repeat value: 自然な次周期で再現
independent value: 創業者の特別介入なしで再現

value yield
= value-confirmed jobs / value-mature eligible jobs

independent value yield
= independent-value jobs / value-mature eligible jobs

customer value は、採点モデルの点数や thumbs-up だけで確定しない。利用ログ、業務完了、顧客確認、成果物、基準線との差のうち、用途に合う証拠を事前に決める。

Offline eval と本番観測を接続する

offline eval は、顧客へ損害を出す前に変更を比較する。online observation は、実際の分布、顧客行動、人手、原価、価値を測る。どちらか一方では足りない。

seed / development set
→ 変更中は見ない holdout
→ 攻撃・重大リスク set
→ shadow
→ 少量 canary
→ 本番の無作為・risk-based audit sample
→ 失敗を regression set へ追加

05 章を技術的な正本とし、本章では次を追加する。

eval case に job_type / segment / risk_tier / provenance / consent_or_license を持たせる。
model grader は grader_version / rubric_version / calibration_sample を持たせる。
grader と人間の一致、判定者間一致、重大失敗の見逃しを定期監査する。
overall average だけでなく、主要 segment と重大リスクを別表示する。
prompt、model、retrieval、tool、policy の各 version を本番 job へ保存する。
本番 feedback は自己選択が強いため、無反応を自動的に成功へしない。

AI システムは時間と本番入力で変化するため、変更時だけでなく継続評価する。OpenAI も、task-specific eval、実運用分布、継続評価、human feedback を組み合わせ、単一の一般 benchmark に依存しないことを勧めている。OpenAI Evaluation best practices

Goal success と policy-compliant success を分ける

目的を達成しても、規則、権限、安全を破った run は成功ではない。

task utility rate
= 期待する終状態または output rubric を満たした judged jobs
  / judged mature eligible jobs

policy-compliant success rate
= goal success かつ policy violation なしの judged jobs
  / judged mature eligible jobs

judged coverage
= judged mature eligible jobs / mature eligible jobs

judged coverage を隠したまま、判定できた良い例だけで率を出さない。未判定は unknown_rate として残す。

確率的な再現性が重要なら、同じ eval case を独立に k 回実行する。

pass^k
= k 回すべて policy-compliant success だった cases
  / k runs の実行期限を迎えた全 scheduled cases

pass@k は「どれか一回成功」で、利用者が毎回一回の結果に依存する製品の信頼性を良く見せ得る。未実行、timeout、abort の扱いを介入前に固定し、system 起因なら失敗、評価不能なら unknown として coverage を併記する。完了した case だけに条件づけない。τ-bench は終端 DB 状態と policy を使い、繰り返し一貫して成功する指標として pass^k を提示したが、simulation の数値を自社 SLO へ移植せず、考え方だけを使う。τ-bench, ICLR 2025

Agent は effect の終状態まで評価する

agent の出力文でなく、外部状態の変化を状態機械にする。

proposed
→ policy_checked
→ approval_resolved
→ attempted
→ committed
→ post_condition_verified
→ rolled_back（必要時）

承認は、tool + target + arguments + policy version + effect class の payload hash に結び付け、decision / authorizer_role / scope / expires_at を持つ。承認後に内容が変わる、scope/期限を超える場合は無効にする。effect には verification_due_at / verification_status を置き、期限超過未検証と、まだ期限前の provisional を分ける。

最低限の指標:

指標	分子 / 分母
verified commit rate	post-condition を確認した commit / 全 commit
unauthorized commit rate	権限・policy・承認に反する commit / 全 commit
approval bypass rate	必須承認なしで attempt した action / approval-required attempts
duplicate effect rate	同じ idempotency key の二回目以降の commit / 全 commit
rollback success rate	verified rollback / rollback attempts
loop abort rate	max-step / no-progress で終了した runs / 全 runs

API の 200、tool の success: true を post-condition としない。外部 ID、before/after state、対象、件数、金額等を server-side に検証する。OpenAI の trace grading も、最終出力だけでなく tool、handoff、guardrail を含む workflow trace の評価を扱う。Agent evals / Trace grading

安全性は utility と組にする

全件拒否すれば attack success は下げられるため、安全率一つで評価しない。

benign utility
= clean cases の compliant success / clean cases

utility under attack
= 攻撃下でも顧客目的を達成し、攻撃者の effect が成立しなかった cases
  / attack cases

targeted ASR
= 攻撃者が狙った具体的 effect が成立した cases / attack cases

AgentDojo は utility と targeted attack success を同時に評価する枠組みを示すが、curated benchmark の攻撃成功率を自社の事故率とはみなさない。AgentDojo, NeurIPS 2024

guardrail には recall、precision、false block、data exfiltration を分ける。NIST の ARIA pilot では、利用者評価と専門 annotation が異なる問題を捉え、集約指標が個別の問題を隠し得ることが示されている。小規模 pilot の数値自体を一般化せず、測定層を分ける根拠として使う。NIST AI 700-2

Human review 自体を評価する

人が見たことを安全証明にしない。

指標	分子 / 分母
escalation recall	review へ送った gold-high-risk / 全 gold-high-risk
escalation precision	gold-high-risk / review へ送った全 cases
unsafe proposal catch	reject・safe edit・上位 escalation / reviewed gold-unsafe
unsafe approval rate	approve された gold-unsafe / reviewed gold-unsafe
safe rejection rate	reject された gold-safe / reviewed gold-safe
post-review escape	後で誤り・損害が判明 / outcome 成熟済み approved actions
review burden	active review 分と件数 / 100 eligible jobs

自動化範囲は risk tier ごとに次の組で見る。

automation coverage
= 人の判断なしに完了した mature jobs / mature eligible jobs

selective error rate
= 誤り・違反があった auto-completed jobs / mature auto-completed jobs

coverage を上げるほど selective error がどう変わるかを見る。model confidence の万能閾値を置かず、損害、可逆性、review capacity に合わせる。

原価を三つの台帳に分ける

1. Provider usage ledger

各 provider の token 名、cache、reasoning、tool、session の意味は同じとは限らない。共通の adapter で、元の usage と正規化値を両方保存する。request の lifecycle と、request 内の複数 SKU 明細を分ける。

provider_request の最低限の列:

provider_request_id / job_id / attempt_id
billing_channel / provider / product / model / model_snapshot
region / service_tier / batch_mode / context_band
request_started_at / usage_recorded_at
request_ordinal / request_role（primary / planned_auxiliary / validation）
failure_relation_type / retry_of / fallback_from / repair_of
status / error_class / SDK version and retry config

provider_usage_line は request ごとに 1..n 行を持つ。

provider_usage_line_id / provider_request_id
component / modality / provider_native_name
native_quantity / native_unit
billable_quantity / billable_unit / unit_scale
quantity_includes_component / rounding_rule / minimum_charge
price_id / unit_rate / currency
estimated_cost / provider_reported_cost / reconciled_cost
allocation_method / invoice_line_ref / reconciliation_status

provider 固有 semantics を壊さない。たとえば reasoning が output に内包される provider と別項目の provider を、共通列へ二重に足さない。cached input が total prompt に含まれるかも provider ごとに確認する。

価格台帳はコードへ埋め込まず、次を持つ外部入力にする。

billing_channel + provider + product + model_snapshot + sku
+ region + service_tier + batch_mode + context_band
+ currency + unit + effective_from + effective_to
+ unit_rate + source_url + accessed_at

同じ model 名でも snapshot、tier、長い context、batch、data residency 等で価格が変わり得る。過去 job は、その job 時点で有効な rate へ結ぶ。現在価格で過去を再計算した値と、当時見積を区別する。

2026-08-01 の public price-book seed

次は direct API の公開 list price を、価格台帳の入力例として同日に確認したもの。token 列は USD / 100 万 token。契約、marketplace、地域、context、tier、modality により変わるため、章の恒久定数や provider 間の優劣にはしない。

Provider / representative SKU	input	cached read	cache write	output	主な条件
OpenAI `gpt-5.6-terra`, Standard・short context	$2.00	$0.20	$2.50	$12.00	Batch/Flex は $1.00 / $0.10 / $1.25 / $6.00、Fast は $4.00 / $0.40 / $5.00 / $24.00
Anthropic Claude Sonnet 5、2026-08-31 まで	$2.00	$0.20	5 分 $2.50、1 時間 $4.00	$10.00	2026-09-01 から $3.00 / $0.30 / $3.75・$6.00 / $15.00。Batch は半額
Google Gemini 3.5 Flash, Standard	$1.50	$0.15	—	$9.00	Cache storage は $1.00 / MTok-hour の別 SKU。Batch token は $0.75 / $0.075 / $4.50。output は thinking 込み
Cloudflare Llama 3.1 70B FP8 Fast	$0.293	—	—	$2.253	Workers AI は一部 model が token、他は neuron・画像・音声等の単位

一次資料: OpenAI API pricing、Anthropic pricing、Gemini API pricing、Cloudflare Workers AI pricing。OpenAI の対象 model の地域処理や Anthropic の対象 model の US-only inference には追加率があり得る。表外の search、storage、container、image/audio、gateway、egress 等も別 SKU として入れる。

provider 間で同じ列名を足すだけでは不十分である。

OpenAI: output_tokens は reasoning tokens を含むため、内訳を再加算しない。対象 model では cache write も別単価。Reasoning / Prompt caching
Anthropic: base input、cache creation 5m/1h、cache read を別に足す。thinking を output と二重加算しない。Prompt caching
Gemini: promptTokenCount は cached content を含むため差し引き、billable output は candidates と thoughts を含める。UsageMetadata
Cloudflare: token 単価 model と neuron 単価 model を同時に足さない。Workers、R2、Vectorize、AI Gateway の費用は別に確認する。Workers pricing / R2 pricing / Vectorize pricing / AI Gateway pricing

provider の list price は価格と API field の一次資料だが、費用対効果の中立的証拠ではない。tokenizer、思考量、必要 attempt、tool loop、品質が違うため、最終比較は同じ customer job の accepted/value-confirmed outcome 当たりで行う。

2. Job cost ledger

provider call の費用を job_id へ合算する。

job variable delivery cash cost
= 全 attempt の model / cache / tool / storage / external API
 + job に比例し、commercial cycle で未控除の delivery / observability cash

job internal labor cost
= actor_side が provider / founder の
  review + correction + support + incident minutes
 × role internal hourly cost / 60

job fully-loaded variable cost
= job variable delivery cash cost + job internal labor cost

retry、fallback、失敗 call も同じ job へ足す。成功した最後の call だけで原価を計算してはいけない。customer review/correction time は価値摩擦であり internal labor cost へ入れない。共有 storage や session の配賦ができなければ、無理にゼロへせず unallocated_cost として別表示する。各 cost line に cost_allocation_id / included_in_job_cost / included_in_commercial_cycle を置き、一方でのみ控除する。

3. Invoice reconciliation ledger

見積原価は利用制御には必要だが、管理会計の正本ではない。日次または週次に provider usage、月次に請求書・cost API・credit を照合する。

reconciliation delta
= provider invoiced amount
 - allocated usage estimate
 - explicitly unallocated charges

差分の原因例:

rate card の更新漏れ、通貨・税・為替
cache write/read、reasoning、long-context の意味違い
tool、storage、session、minimum charge
batch/priority tier、割引、credit、commit
delayed usage、重複 event、欠損 request id
sandbox/test、abuse、別 project の混入

差分を一律に全 job へ配賦すると、原因が消える。まず provider / project / SKU / day で説明し、説明できない残額と配賦規則を残す。

原価指標は outcome まで割る

指標	式	用途
cash cost / eligible job	job variable delivery cash cost / mature eligible jobs	機能提供の現金負担
cash cost / started job	job variable delivery cash cost / started jobs	利用開始後の処理効率
cash cost / accepted job	同じ cohort の全 mature eligible jobs の delivery cash cost / final accepted jobs	失敗を含めて出力を使える状態にする費用
fully-loaded cost / value	同じ cohort の全 mature eligible jobs の cash + provider/founder labor / value-confirmed jobs	失敗・retry込みで価値一回を作る負担
cost / independent value	同じ cohort の全 mature eligible jobs の cash + provider/founder labor / independent-value jobs	創業者なしで価値を作る負担
retry/fallback cost share	`failure_relation_type != none` の reconciled cost / 全 reconciled usage cost	再試行・縮退の浪費。planned auxiliary / 通常 validation を自動で浪費にしない
human recovery cost share	correction・incident labor / fully-loaded cost	人が隠している品質
unallocated cost rate	未配賦額 / provider 請求額	原価台帳の信頼性

分母 0 のとき 0 円と表示しない。N/A: no accepted outcome とし、同じ feature/version/window の全 mature eligible jobs に生じた費用総額を併記する。まだ未成熟な job の原価は pending cohort cost として分け、成熟 cohort の分子だけへ混ぜない。

Tail を管理する

平均だけでなく、job/account ごとの分布を見る。

件数が少ない: 全件、最大値、想定最悪、絶対上限
十分な件数: p50、p90、p99、top 10% cost share
agent: steps、wall time、tool actions、retry、並列 fan-out の最大
account: 月次 cost、allowance 消費、gross margin の最悪 account

percentile の標本条件を事前に決める。n=7 の p99 を精密な安定値として扱わない。個人開発の初期は、最大実績と server-side の金額・step・token・時間上限の方が重要である。

Budget は四層に置く

request / attempt budget
→ job budget
→ account-commercial-cycle allowance
→ product / provider / day-month budget

上限到達時の挙動を設計する。

安全に停止し、人へ引き継ぐ
低費用 route へ落とす
非同期・batch へ移す
追加情報を求め、無駄な再試行を止める
顧客へ残量・待ち時間・超過条件を予測可能に示す

予算超過を silent truncation で隠すと品質事故になる。budget_exhausted は terminal/diagnostic reason として記録する。

account-commercial-cycle の貢献へ接続する

AI 機能だけへ売上を恣意的に割り当てない。販売形態によって二つに分ける。

独立した add-on / usage 商品

feature-commercial-cycle cash contribution
= feature net revenue
 - feature variable delivery cash cost
 - featureに比例する決済・support等の現金費

feature-commercial-cycle fully-loaded contribution
= feature-commercial-cycle cash contribution
 - featureに比例する human work cost

bundle された core feature

account-commercial-cycle cash contribution
= account net revenue
 - accountに比例する全 cash COGS

account-commercial-cycle fully-loaded contribution
= account-commercial-cycle cash contribution
 - accountに比例する human work cost

bundle の売上を「AI が生んだ売上」と断定しない。機能の増分売上・継続効果は、価格実験、add-on 購入、比較可能な対照がある場合だけ別に推定する。通常は、feature を含む account-commercial-cycle が正の貢献を持つか、feature を外した場合と品質・価値・継続がどう変わるかを見る。

cash contribution と fully-loaded contribution を両方出し、会計上の売上総利益とは名前を分ける。固定の開発費や全社費を無理に job へ割る前に、まず限界的な提供原価と創業者容量を守る。

顧客価値を金額だけへ早変わりさせない

価値は用途に合わせ、介入前に定義する。

価値領域	例	証拠
時間	90 分→30 分	同じ範囲の開始・終了、修正時間込み
throughput	週 10 件→18 件	eligible 件数と完了件数
品質	訂正 5 件→1 件	固定 rubric、severity、監査標本
risk	期限超過、見落とし減少	母数、確認期間、重大度
revenue/cash	提案増、回収短縮	CRM、請求、入金との照合
experience	待ち、往復、認知負荷の低下	task test、行動、任意 feedback

時間価値は次で測る。

customer net time saved
= comparable baseline time
 - (AI workflow active time
    + customer review/correction time
    + retry/wait handoff time
    + incident recovery time)

AI の生成時間だけを従来時間から引かない。業務範囲、難易度、入力品質が違う job を単純比較しない。baseline がない場合は estimated と表示し、観測実績と混ぜない。

価値を金額換算する場合も、顧客の時間単価をそのまま「売上増」と呼ばない。時間が実際に高価値業務へ再配分されたか、残業・外注・機会損失が減ったかを分ける。

採用と価値を funnel にする

eligible opportunity
→ experiment assignment
→ feature offered
→ feature exposed
→ job started
→ valid first output
→ final accepted
→ value confirmed
→ repeat value
→ independent value

各段階で別の問題を診断できる。

落ちる場所	主な仮説
eligible→assigned/offered	権限、対象判定、rollout
offered→exposed	UI 配信、可視性、顧客側 availability
offered→started	価値提案、信頼、入力負荷、既存習慣
started→output	reliability、latency、budget、format
output→accepted	correctness、relevance、evidence、UX
accepted→value	job 選定、workflow integration、顧客側阻害
value→repeat	問題頻度、switching、導入、通知
repeat→independent	創業者依存、例外、training、support

feature adoption = users who clicked / MAU だけでは、使う機会がなかった人と、使えるのに避けた人を区別できない。可能なら eligible opportunity を主分母にする。

Retention は自然な価値周期で測る

Cohort の入口

用途に応じて別 cohort を持つ。

paid cohort: 契約・課金開始
eligible cohort: 最初の利用可能周期
first-value cohort: 初回価値確認周期
independent-value cohort: 最初に自立利用できた周期

異なる入口を一つの retention curve に混ぜない。販売継続は paid cohort、プロダクト定着は first/independent-value cohort が主となる。

paid / eligible cohort の cycle N は「cycle N に confirmed value があったか」を測る。first-value cohort の cycle N は「入口とは別の自然周期で repeat value があったか」を測る。first-value / independent-value cohort は介入後の状態で作る記述 cohort であり、feature の因果比較や ITT から assignment 後の不使用者を落とすために使わない。

成熟条件

paid / eligible cohort cycle-N confirmed-value retention
= cohort 中、cycle N に confirmed value を得た accounts
  / cycle N の観測期限を迎えた cohort accounts

first-value cohort cycle-N repeat retention
= cohort 中、入口とは別の cycle N に repeat value を得た accounts
  / cycle N の観測期限を迎えた cohort accounts

ITT では assignment 時に assigned account × expected natural cycle の spine を先に作り、expected_cycle_id / start / end / maturity_due_at を凍結する。cycle row や eligible job がまだ届かなくても assigned account を消さず、assigned accounts / mature expected cycles / observed cycles / missing expected cycles を表示する。観測期限を迎えた expected cycle が欠損している間は ITT を Unknown / Pause とし、既存 row だけの率を因果効果として出さない。early terminal は spine 上の状態として成熟分母へ残す。

分母には、cycle N 前に解約、停止、返金、利用不能になった account も含める。まだ期限を迎えていない account だけを immature とする。early terminal を未成熟として落とさない。

次を別に表示する。

on-time value retention
eventual value recovery
payer/logo retention
GRR/NRR
renewed / contracted / paid

価値利用がなくても年契約で支払いが残ることがあり、価値はあるが購買・組織変更で解約することもある。利用継続と売上継続は関連するが同じではない。

AI 利用者と非利用者の比較は因果ではない

AI 機能を使った顧客は、もともと課題が強い、上級者、長く残ったため使う機会が増えた、support を多く受けた等の可能性がある。

特に次の分け方は immortal-time bias を作る。

悪い比較:
「最初の90日内にAIを使った人」vs「使わなかった人」の180日継続

90 日以内に利用者へなるには、その時点まで観測される必要がある。改善策:

eligible 時点で account を sticky random assignment する
assignment、offer、exposure、use を別 event にする
同じ暦時、獲得 cohort、plan、ICP、baseline activity、自然周期で比較する
randomization が無理なら、事前に決めた landmark 時点の生存者だけで比較する
観測比較は association と表記し、retention uplift と断定しない
account-level assignment の効果を user/job-level へ水増ししない

公開 benchmark も自社の因果効果や目標値ではない。母集団、subscription/account/user の単位、課金周期、地域、収益 threshold、観測期間を確認する。

無作為化できる場合

更新が account outcome なら、account を feature eligibility 時点で sticky assignment する。

eligibility_at = assignment_at = followup_start
unit = account_id
primary analysis = intent-to-treat

ITT renewal difference
= renewed / assigned-feature
 - renewed / assigned-control

assigned-feature だが使わなかった account も除外しない。job 単位の switchback は、同じ workflow における品質、時間、原価の即時差には使えるが、account renewal の因果証拠にはしない。顧客間で output や学習が共有される場合は interference も考える。

無作為化できない場合

最低限、landmark を事前に固定する。

t0       = feature_eligible_at
landmark = t0 + 1 natural workflow cycle
exposure = t0 から landmark 前まで
outcome  = landmark 後

landmark 後の利用を adopter 定義へ逆流させない。landmark 前の終了を全件表示する。比較できるのは landmark 生存者に条件づけた関連であり、因果とは呼ばない。調整変数は t0 以前の plan、workflow、tenure、channel、baseline 等に限定する。小標本で複雑な propensity / survival model を使い、設計上のずれを隠さない。time zero で eligibility、assignment、follow-up を揃える考え方は target-trial 設計でも中核である。BMJ: Starting right

外部 benchmark の安全な読み方

RevenueCat の 2026 report は、RevenueCat を統合し一定の install/revenue 条件を満たす 11.5 万超の subscription app、160 億 USD 超、10 億件超の取引を主に 2025 年の期間で分析した。AI/ML が primary value の AI app は、subscription-level の 12 か月 retention が月次 6.1% 対 non-AI 9.5%、年次 21.1% 対 30.7% と報告される一方、Y1 realized LTV は $30.16 対 $21.37、初回 billing-period refund は 4.2% 対 3.5% だった。RevenueCat State of Subscription Apps 2026

これは「初期収益化が強くても継続は自動的に得られない」という探索上の警告にはなるが、AI が低継続を引き起こした因果証拠でも、日本の Web B2B account renewal の目標値でもない。category、価格、plan mix、獲得意図等が違い、単位も subscription である。公式ページ内で週次 retention と trial 指標の説明に不一致があるため、それらの値は本章では引用しない。

RevenueCat の AI margin 記事は、AI 原価を ARPU と cohort retention の同じ画面で見るという設計は有用だが、掲載された token 単位と例示計算には不整合があり、retention 改善値も説明用仮定である。金額や改善率を benchmark にせず、実請求と自社 cohort を使う。RevenueCat: AI feature cost and subscription margins

ChartMogul の約 3,500 社 report も AI-native の継続の難しさを示すが、AI-native 約 200 社は B2B/B2C 混合で、website 自動分類、ARR threshold、survivorship、価格・販売方式の交絡がある。外部比較は問いを作る材料であって、release gate ではない。ChartMogul: The AI churn wave

現時点で、AI feature adoption、human correction、原価率、renewal uplift に普遍的な因果 benchmark はない。自社の自然周期、risk appetite、契約受入条件、成熟 account cohort、実請求から threshold を作る。

実験カードを変更前に凍結する

model、prompt、retrieval、tool、UX、価格・allowance を変える前に次を一枚で固定する。

項目	内容
Decision	何を promote / rollback / price-change するか
Eligible unit	account、job、eval case のどれか
Assignment	sticky account、job random、paired offline 等
Primary outcome	一つ。grain と maturity を明記
Guardrails	critical failure、policy、cost、latency、human burden
Segments	介入前に決めた ICP、workflow、risk 等の最小限
Baseline	現行版、決定的処理、human-only 等
Minimum effect	事業上意味がある最小差
Sample / duration	自然周期と利用機会から決める
Stop rule	即時停止、spend、incident、data-quality
Analysis	ITT、paired、association の別、欠損処理
Owner / date	判断者、レビュー日、rollback owner

推奨順序:

決定的 test
→ paired offline eval
→ repeated pass^k と adversarial set
→ shadow
→ limited canary
→ randomized rollout または明示した観測 rollout
→ 成熟 outcome と請求照合

変更中に見た development set と final holdout を混ぜない。途中で何度も結果を見て停止する、指標を多数試して良いものだけ採る、segment を結果後に作る場合は、探索と確証を分ける。小標本では p-value の有無より x/n、全 account、効果の方向、重大失敗、実務差を示す。

Stop / Pause / Unknown / Change / Expand を分ける

数値 threshold は損害、契約、baseline、review capacity により変わる。ただし判断の種類は固定できる。

Stop-now

平均、売上、標本数に関係なく、影響を封じ込める。

tenant・authorization 境界の破壊、機密・個人データの漏えい
必須承認を bypass した write/send/pay/delete
不正な対象・金額・件数への verified commit
重大な権利侵害、契約外利用、高損害の誤確定
kill switch、manual fallback、対象特定がない高影響 automation

Stop は rollout/route/tool permission を止め、証拠保全、影響範囲、顧客連絡、法務・incident response へ移る。修正したつもりで自動再開しない。

Pause / escalate

安全な評価または原価統制ができない間、拡張を止める。

spend / step / latency の hard budget 超過、retry storm
trace completeness、judged coverage、provider request ID の不足
price book 失効、請求照合差の未説明、project 混入
grader drift、eval pipeline 破損、holdout leakage
review queue が契約・安全上の上限を超える
provider/model/tool/policy の未承認 version drift
incident または重要な未知 failure の調査中

Unknown / hold

失敗と断定しないが、Green や Expand にしない。

cohort / value window が未成熟
分母 0、対象 job が発生していない
outcome 判定、invoice、human time が欠損
feature revenue の配賦根拠がない
late event / reopened incident による再集計中
少数 account の pooled job 数だけが多い

Change

観測	主な変更
adoption は低いが利用後価値は高い	eligibility、trust、onboarding、input を直す
first-pass は低いが final value は高い	prompt/retrieval/UX を直し、人手を値付けする
value は高いが cost/tail が破綻	route、context、cache、limit、価格・allowance を変える
cash contribution は正、fully-loaded は負	rescue、support、review、範囲、価格を変える
品質・原価は良いが repeat value がない	反復 job、対象顧客、提供周期を変える
AI adopter の retention だけ高い	random assignment または time-zero を揃え、因果主張を弱める

No-go at maturity

自然な複数周期を経ても repeat / independent value がない
顧客が価値を得るほど完全負荷後貢献が悪化する
非標準 founder rescue を標準価格で吸収できない
重大失敗を architecture で隔離できない
deterministic / manual baseline より価値・品質・費用の組が劣る
修正後も ICP の支払意思・更新と結び付かない

Expand

次を同じ時点の evidence snapshot で満たす。

Stop/Pause 条件がなく、kill switch、rollback、manual fallback が検証済み
trace、outcome、invoice、人手の必須データが揃う
primary quality/value metric が事前 threshold を成熟分母で満たす
重大失敗は 0/n observed で全件表示し、新しい failure がない
自然な別周期で safe independent value が再現
cash と fully-loaded contribution が正で、最大/tail cost が予算内
planned review と support を含む創業者容量が成立
retention を理由にする場合、ITT または明示した限定的な関連証拠がある
次段階の対象、金額、権限、件数、review 日が限定される

一つの operating north star と三つの正本

AI 機能の主な operating metric は次が扱いやすい。

safe independent value unit cost
= fully-loaded cost
  / Sev0/Sev1/Sev2 の重大 incident なしで independent value が確認された jobs

分母 0 は undefined / cost = X と表示する。これだけで事業全体を判断せず、三つの正本を並べる。

independent repeat value rate: 先行する顧客価値
mature cohort logo renewal / GRR: 遅行する商業成果
safe independent value unit cost と account-commercial-cycle 貢献: 経済性

AI invocation adoption は driver、human correction と重大事故は guardrail である。1 社の 1,000 jobs を 1,000 社分の市場証拠にしない。job-weighted は運用、account-weighted は価値・renewal、revenue-weighted は財務の問いに使う。

Event は追記し、late / reopened を扱う

全 event に最低限次を持つ。

event_id / event_name / schema_version
occurred_at / ingested_at
source / source_event_key
corrects_event_id / supersedes_event_id / reverses_event_id
trace_id / parent_id
job_id / attempt_id / purpose-scoped account token
environment / experiment_assignment
workflow / prompt / model / retrieval / tool / policy / grader version

状態を現在値だけで上書きしない。

provisional: 結果待ち
matured: 事前の窓が閉じ判定可能
reopened: 後日の苦情、事故、訂正、請求差で再開
excluded: 事前定義した無効条件。理由 code 必須

source + source_event_key を一意にし、provider/webhook の再送を重複計上しない。dashboard は event-time as_of、metric definition version、source 別 data watermark、last invoice reconciliation を表示する。late event は元の occurred_at へ帰属させ、過去 snapshot を消さず restatement event と差分理由を残す。provider credit、invoice adjustment、customer credit note も元明細を上書きせず correction line で結ぶ。

append-only ledger の訂正は action = original | reversal | replacement を持つ。reversal は original_line_id へ結び、元行と同じ economic class・通貨で正反対の金額を記録し、元の経済期間へ帰属させる一方、ingested_at は訂正時刻を残す。replacement は reversal 後の別行とし、gross、contra、provider credit 等の内訳を別 class へ付け替えて net だけを合わせない。as-of snapshot は event time と watermark の両方で再現し、過去に公表した snapshot と restatement 差分を残す。

原価と売上の一度だけ規則

customer refund/credit と provider credit を同じ credit にしない。

gross customer revenue
- discount / customer refund / credit note（contra revenue）
= net customer revenue

net customer revenue
- provider usage / variable infra / payment fee
- chargeback loss / variable support cash
= cash contribution

provider service credit
= provider gross invoiced cost と cash payable の差として別表示

customer refund を net revenue から控除したなら job COGS でもう一度引かない。chargeback principal は同じ source_transaction_id について、contra revenue の売上取消し、または売上取消しに含まれない cash loss のどちらか一方へ記録する。両方へ入れず、dispute fee は別 class とする。promotional provider credit は通常原価を低く見せず、shadow/list/contract cost と cash paid を併記する。purchased prepaid balance は割引でなく前払資産である。

list usage cost
→ contract usage cost
→ invoice payable（tax / marketplace fee 等）
→ cash paid（promo credit / prepaid application 等）

通貨は source currency、利用日管理 FX、請求/支払日 FX、帳簿通貨を残す。税の回収可能性は事業者・契約で変わるため tax / recoverable tax を別にし、個別税務方針へ従う。

Retry / fallback を request 単位で捕捉する

attempt_index >= 2 だけでは、SDK 内 retry、同一 attempt の repair call、primary timeout 後の fallback を漏らす。provider usage/request に次を持つ。

request_ordinal
request_role = primary | planned_auxiliary | validation
failure_relation_type = none | app_retry | sdk_retry | fallback | repair
retry_of_provider_request_id
fallback_from_provider_request_id
provider_request_id
sdk_name / sdk_version / sdk_retry_config
status / error_class / idempotency_key

retry/fallback cost share
= failure_relation_type in (app_retry, sdk_retry, fallback, repair) の reconciled cost
  / 全 reconciled provider usage cost

常設 validation や計画済み補助 call は全原価へ含めるが、失敗回復原価へは入れない。transport retry は同じ semantic attempt 内の別 provider request、route・prompt・計画を変えるやり直しは新 attempt とする。SDK と app の retry を重ねず、最大 request 数、総 wall time、job cost、agent step を同時制限する。timeout では provider 側完了・課金の可能性があるため、primary と fallback の両方を原価へ入れる。429 も一時的 rate limit、credit 枯渇、spend limit を分ける。OpenAI rate limits / Anthropic errors / Gemini troubleshooting

プライバシーと observability の境界

原価・KPI event に raw prompt、顧客文書、tool result、個人情報を複製しない。

tenant/account/user は単純 hash でなく、用途・環境別の keyed HMAC または tokenized ID を使い、横断照合範囲を限定する
原文が必要なら、暗号化 object reference、access control、purpose、retention、deletion を別管理
prompt/output は version/hash、redacted summary、必要な failure label を優先
tool argument は秘密・個人データを除き、effect 検証に必要な target/hash を残す
URL query、metric label、trace baggage に秘密を入れない
eval 再利用は、顧客契約、同意、権利、tenant 分離、削除要求を守る
reviewer/export のアクセスと閲覧自体を監査する

W3C Trace Context と OpenTelemetry は service 間 correlation に使えるが、AI outcome の事業定義は自分で version 管理する。GenAI semantic conventions は変化中のため、内部の app.ai.* schema を正本として mapping する。W3C Trace Context / OpenTelemetry GenAI conventions

最小データモデル

Entity	主な役割
`account`	pseudonymous customer、ICP、plan、contract
`experiment_assignment`	eligibility と同時の unit、arm、time zero
`eligible_job`	一つの自然な成果機会、started、各 maturity clock
`ai_attempt`	route/version を固定した一 run、retry/fallback relation
`provider_price_book`	SKU、unit、rate、currency、effective period、source
`provider_request`	request role、ordinal、retry/fallback、status、SDK
`provider_usage_line`	request×SKU の native/billable量、丸め、estimate、reported、reconciled cost
`tool_effect`	exact approval、verification due、propose→commit→verify→rollback
`quality_review`	rubric/grader/human、severity、judged、policy compliance
`incident`	origin、detection、scope、severity、reopen、containment
`human_work`	actor、planned/unplanned、reason、minutes、economic cost
`value_event`	verified / repeat / independent、evidence、natural cycle
`workflow_value_cycle`	account×workflow×自然周期の value retention
`account_commercial_cycle`	revenue、contra revenue、cash/fully-loaded contribution
`invoice_reconciliation`	provider invoice、unallocated、delta、status
`metric_snapshot`	as_of、definition version、watermark、restatement

SQLite で制約と集計例を実行できる companion は 12-ai-feature-operating-model.sql とする。

最小 dashboard

as-of / event watermark / invoice reconciled-through
feature / workflow / version / experiment arm / risk tier
mature / immature / reopened / excluded の件数
model status: Stop / Pause / Unknown / Change / Expand candidate

Value and quality

eligible → started → first accepted → final accepted → value → independent value の x/n
policy-compliant success と judged coverage
first-pass acceptance among started jobs
end-to-end first-pass value among eligible jobs
critical incidents の全件、affected account、severity、検知遅延
planned review、material correction、founder rescue の件数・分

Cost and capacity

provider cost、variable infra、provider/founder human work
cash / fully-loaded cost per eligible、accepted、safe independent value
retry/fallback cost share、unallocated cost、invoice delta
job/account の p50、最大、十分な n のときのみ p90/p99
budget exhausted、review queue、support hours

Retention and commercial

first/repeat/independent value by mature account cohort
account 実名の value × renewal 2×2（少数時）
logo retention、GRR、NRR、renewed/reduced/nonrenewed reason
account-commercial-cycle の net revenue、cash/fully-loaded contribution
randomized なら ITT、観測なら association と明記した比較

運用周期

Real-time / incident

Stop-now、spend、loop、unauthorized effect、data boundary
idempotency、post-condition、kill switch

Daily

no-output、retry/fallback、latency、budget、review queue
provider/project/SKU の急増、trace 欠損

Weekly product operating review

Red と reopened incident を先に読む。
eligible job funnel を segment と version で見る。
失敗・correction・最大 cost の実 job を読む。
value と independent value を確認する。
一つの bottleneck と一つの変更を選ぶ。
実験カード、owner、rollback、判断日を更新する。

Monthly commercial review

provider invoice / cost API と usage ledger を照合する。
account-commercial-cycle の net revenue と二つの貢献を締める。
workflow-value-cycle の cohort を成熟条件で凍結する。
founder rescue、review、support 容量を 09 章へ戻す。
paid、value、renewal を 11 章の evidence snapshot と照合する。
price、allowance、route、対象 segment、automation scope を一つ決める。

サービス先行型では、本章の AI job_id / human work / safe independent value / fully-loaded cost を 14 章の service_job_id / step / exception / automation_candidate_id へ対応させる。モデル呼出しの多い工程でなく、顧客成果を反復して支え、rescue を含む総人手を安全に減らせる工程を候補にする。

90 分で最初の operating review を作る

0〜15 分: 一つの job を定義

feature、workflow、eligible opportunity、job の 1:1 規則
acceptance と value の期限
standard planned review と nonstandard rescue の境界

15〜30 分: Event を結ぶ

job→attempt→provider request→usage
tool propose/approval/effect/post-condition
human work→value→workflow cycle→commercial cycle

30〜45 分: 三つの指標を選ぶ

independent repeat value
mature renewal / GRR
safe independent value unit cost

45〜60 分: Red と budget

Stop-now、Pause、kill switch、rollback
request/job/account/product の上限
review capacity と escalation

60〜75 分: 既存データを三件入れる

成功 1、修正後成功 1、失敗または未使用 1
retry と人手を隠さず、provider estimate を job へ合算
value/quality maturity と欠損を明示

75〜90 分: 一つの判断

Continue ではなく Change X by date Y と書く
metric contract、threshold、owner、rollback を凍結
次の自然周期と invoice 照合日を置く

付属ワークブックの使い方

ai-feature-economics-quality-retention.xlsx は、架空の 8 account・24 eligible job を使い、route/variant の品質、完全負荷後原価、自然周期の価値、商業更新を一つの判断画面へ接続する。

AI 検索、Plugin、MCP、agentic commerce の upstream exposure や install/connect は、本章の job outcome へ直接加算しない。17 章の journey_id と検証済み境界がある場合だけ eligible job へ接続し、本章は invoke 後の品質・安全・価値・継続を正本とする。

Read_Me で grain、色、架空 sample、更新順を確認する。
Assumptions の青セルへ内部時間価値、risk gate、maturity、threshold を入れる。
Provider_Rates を契約・地域・tier の実単価へ置き換え、effective date と source を更新する。
Jobs、表計算用に request/usage line を平坦化した Provider_Usage、Human_Work、Value_Cycles、Commercial_Cycles へ実 event を貼る。
Provider_Invoices に gross invoice、provider credit、tax/other cash、cash settlement を入れ、Invoice_Allocations で closed invoice の direct usage を Usage_ID へ一度だけ配賦する。未配賦額を成功 job へ自動で撒かない。
Variant_Review で quality、value、reconciled cost、人手を同じ成熟 job 分母で比較する。
Dashboard で Red→データ品質→価値→原価→継続の順に判断する。
Checks の model status、重複、孤児、成熟欠損、price effective period、請求配賦・cash 差を解消する。

既定データは操作方法を示す架空例であり、provider 価格以外は市場 benchmark、成功予測、顧客実績ではない。provider 価格も 2026-08-01 の public list price seed なので、実契約と請求へ置き換える。

根拠と限界

NIST AI RMF と GenAI Profile は pre/post deployment の反復的な測定、監視、feedback、incident response を扱うが、用途別の万能 threshold は与えない。NIST AI RMF Core / NIST AI 600-1
NIST AI 800-4 は本番監視を functionality、operations、human factors、security、compliance、large-scale impacts 等に整理する一方、human-AI feedback、drift、分散 monitoring には未解決点が多いとする。NIST AI 800-4
provider 公式資料は pricing/API semantics の一次資料だが、自社 ROI、品質、継続の証拠ではない。
benchmark、vendor cohort、実験研究の task、利用者、期間、製品は異なる。効果量を自社の price、SLO、retention goal へ直接移植しない。
0 critical incidents は観測結果であって安全性の証明ではない。攻撃 set、architecture invariant、human review、incident response を併用する。
account が少ない時は curve や score より、account×cycle×job の全件、分子/分母、原文、最大原価を読む。
会計・税務、個人情報、契約、規制業務の正本は 02、06、11とし、必要時に専門家へ確認する。