小標本でも誤魔化さないプロダクト計測・因果実験・判断

最終確認: 2026-08-02
対象: 顧客数、商談数、購入数、更新数がまだ少ない個人開発者が、価格、onboarding、販売、AI 機能、運用変更を判断する場面

この章は統計、計測、プロダクト判断の実務教材であり、個別の統計・法律・医療・金融助言ではない。高影響な処遇、健康、信用、雇用、教育等の判断は、この章の簡易手順で自動化しない。

本文と付属ファイルの名称、ID、件数、金額、効果、期間は説明用の完全な架空例である。外部 benchmark、推奨成功率、予測、実績ではない。

この章の役割

04 章は marketing experiment、12 章は AI feature の品質・原価・継続、17 章は distribution evidence、18 章は delegation experiment を扱った。本章はそれらに共通する 計測と因果判断の基盤 を作る。

付属物は次の二つである。

• small-data experiment and decision pack: 判断契約、母集団、metric、割当、計測、integrity、分析、risk、decision を複製できる 14 書式。
• SQLite companion: 粒度、version、time zero、assignment、exposure、maturity、欠測、contamination、snapshot freshness、analysis / decision chain を完全架空データと DQ01–DQ102 で検査する参考実装。

先に結論

個人開発では、大企業より標本が小さい一方、一件の顧客、一回の失敗、一週間の創業者時間が重い。したがって「有意差が出るまで traffic を集める」ことを目標にしない。次の順に運用する。

1. 数字より先に判断を固定する。 何を、誰について、いつ、どの損失上限で決めるかを書く。
2. 記述、関連、因果、意思決定を分ける。 dashboard の変化を施策効果へ昇格させない。
3. 一つの主要 outcome を選ぶ。 driver、guardrail、data-quality metric は別の役割にする。
4. eligible、assignment、time zero、maturity を先に固定する。 利用者だけを後から選ばない。
5. randomized rollout は assignment 基準の ITT を主分析にする。 exposure-only 比較は診断に留める。
6. 効果を見る前に計測の健全性を見る。 A/A、sample ratio、coverage、重複、時刻、contamination、欠測を確認する。
7. 小標本は隠さない。 x/n、絶対差、相対差、区間、欠測、最大損害、個票理由を併記する。
8. 固定 horizon か事前に選んだ sequential method を使う。 毎日覗いて都合のよい瞬間に止めない。
9. 実務上の差と事業価値を別に判断する。 小さな p-value も、大きく不確かな uplift も、単独では出荷命令ではない。
10. 安全、法務、privacy、誠実な表示を平均 uplift で相殺しない。 STOP > PAUSE > UNKNOWN > INCONCLUSIVE > CHANGE > MAINTAIN > EXPAND とする。

五つの問いを混ぜない

問い	例	許される主張	典型的な誤り
記述	今週 7/12 account が初回価値へ到達したか	観測した母集団・窓の状態	前週との差を施策効果と呼ぶ
診断	どの step で離脱や error が起きたか	観測範囲の failure location	相関する step を原因と断定する
予測	来週 support が何件になりそうか	前提付き予測と不確実性	予測精度を因果説明へ置換する
因果	onboarding B は A より成熟 outcome を変えたか	設計と仮定が支える範囲の効果	exposure 後に利用者だけ比較する
意思決定	B を拡大、維持、変更、中止するか	効果、損害、費用、可逆性を合わせた action	統計 threshold に責任を委ねる

observed after change は caused by change ではない。caused a change も worth shipping と同じではない。たとえば checkout copy が購入を増やしても、解約条件を隠した結果なら停止する。逆に平均 conversion がまだ不確かでも、重大 error を減らし、費用が小さく、可逆的なら限定維持が合理的な場合がある。

一つの decision unit を作る

experiment の単位は dashboard、ticket、SQL query ではなく、一つの介入について一つの action を決める decision unit である。

decision_id / version:
decision_owner / independent_reviewer:

decision question:
eligible population:
intervention / control versions:
claim sought: DESCRIPTION | ASSOCIATION | CAUSAL
candidate action: STOP | PAUSE | CHANGE | MAINTAIN | EXPAND

primary outcome / maturity:
minimum practically important effect:
maximum acceptable harm / cash / founder time:
decision_due_at:
reversal trigger / rollback owner:

同じ変更でも、新規 account の初回価値 と 既存 account の更新 は母集団、時計、outcome が異なるため別 decision にする。価格と onboarding を同時に変えた場合、どちらの効果か分けられない。複合 package の効果だけを知りたいなら一 intervention と明記し、各部品の効果は主張しない。

target は metric 選定と分ける

指標を選ぶ段階では、判断に必要か、操作可能か、安定して観測できるかを確認する。target は baseline、季節性、容量、損失、期限が揃ってから置く。外部 SaaS benchmark や架空 fixture をそのまま target にしない。

minimum practically important effect は「検出できる最小差」ではなく、顧客価値または事業価値として行動を変える最小差である。たとえば次を含める。

minimum customer benefit:
minimum cash or contribution improvement:
maximum extra support / latency / error:
implementation and migration cost:
expected duration of benefit:

baseline がなければ、偽精密な目標値を作らず TBD_BASELINE とし、最初の観測を target 設定用に使う。その観測を同じまま confirmatory evidence に再利用するなら、探索に使った事実を明示する。

MPE、MDE、precision target を分ける

• MPE / MVI: 事業上、action を変える最小の実務的・経済的差。
• MDE: 指定した baseline、variance、alpha、power、sample 等の設計で検出を狙う差。
• precision target: uncertainty interval をどの幅まで狭めたいか。

MDE が MPE より大きい設計では、事業上価値のある差を見逃し得る。達成可能 sample で harm と value の領域を分けられないなら、勝敗を definitive objective にせず、assignment/telemetry の feasibility、trigger rate、variance、failure mode、次回設計の学習を目的にする。「件数が少ない」だけで後から pilot と呼び替えず、目的と action map を事前に変える。

planning objective: DECISION_PRECISION | POWER_FOR_EFFECT | FEASIBILITY
baseline / variance source and period:
MPE / effect used for planning:
alpha / power or interval-width target:
allocation / cluster / attrition assumptions:
planned units / calendar / maturity delay:
calculation code or method / reviewer:

KPI を四つの役割へ分ける

一つの test で十数個の KPI を同格に見ない。標準形は次である。

役割	推奨数	質問	例
primary outcome	1	この判断を最も直接変えるか	成熟した eligible account の初回価値到達
diagnostic driver	1〜2	outcome の手前で何が動いたか	入力完了、accepted output
guardrail	1〜2	利益と引換えに何を壊していないか	重大 error、解約/返金、founder rescue
data quality	必要分	数字を信じられるか	assignment coverage、重複、欠測、SRM

primary が未成熟でも driver が良ければ仮説は残るが、顧客成果を証明したことにはしない。guardrail 0 件も、安全の証明ではない。観測可能範囲、検出力、最大 exposure を示す。

metric contract

metric_id / version / role:
decision_id:
human-readable question:

unit of analysis:
eligible denominator rule:
numerator rule:
aggregation: COUNT | RATE | SUM | MEAN | MEDIAN | DISTRIBUTION
event/source-of-truth:
deduplication key:
event-time field / timezone:
window start / end:
maturity rule:

missing / late / reopened handling:
exclusions and reason codes:
segment dimensions allowed:
expected direction:
minimum practically important effect:
guardrail limit / veto rule:

owner / reviewer / effective_from:
query hash / code version:

分子だけでなく分母を version 化する。activation rate が、招待済み、登録済み、利用可能、入力有効、assignment 済みのどれを分母にするかで結論は変わる。平均だけを置かず、小標本では x/n と各 exclusion をたどれるようにする。

ratio を改善しても分子を壊せる

conversion rate は対象を狭めれば上げられる。support per customer は support を拒否すれば下げられる。AI success per request は失敗 request を再試行後の成功に吸収すれば上げられる。したがって rate には次を併記する。

• eligible unit の総数と変化。
• outcome の絶対件数。
• exclusion、missing、retry、fallback の件数。
• 顧客価値、cash、創業者時間の guardrail。
• 定義変更の version と effective time。

母集団、unit、identity、time zero

四つの unit を宣言する

unit	役割	例
eligibility unit	test に入れる資格を判定	account
randomization unit	treatment を割り当てる	account
exposure unit	variant を実際に提示・実行	workflow run
analysis unit	効果を集計	account

同一 account の user が互いに影響するなら、user 単位 randomization と account 単位 analysis を気軽に混ぜない。community、marketplace、team、価格表、support operator のように一 unit の treatment が他 unit へ波及する場合は interference がある。個別 randomization が独立という仮定を置けないなら、cluster、time block、地理/組織単位、段階導入を検討し、それでも残る波及を limitation にする。

identity graph は便利さより誤結合を恐れる

subject_id / identity_version:
account_id / workspace_id / user_id / device_id:
relationship valid_from / valid_until:
merge reason / split reason:
source / confidence / reviewer:

cookie、device、email、account、company を同一人物・同一購入者として自動結合しない。shared device、複数 workspace、転職、代理操作、test account がある。匿名化したつもりの ID も、他情報と容易に照合できる状態なら privacy 上の検討が消えるわけではない。

time zero を一つに揃える

次を同じ時点に揃える。

1. eligibility を確定する。
2. treatment を割り当てる。
3. follow-up を開始する。

「後で feature を使った人」を treatment として起点から比較すると、使うまで生存・継続できた期間や自己選択を treatment 効果へ混ぜる。ランダム化 rollout なら assignment 時点で cohort を作り、将来の exposure で cohort membership を書き換えない。

eligible_at <= assigned_at = follow_up_start_at < maturity_at <= snapshot_as_of

遅着 event は occurred_at と recorded_at を分ける。recorded_at は client 入力でなく trusted server が付ける append clock とし、production では単調増加の ingestion sequence も持つ。backdate で cutoff を潜らせず、遅着後は過去 snapshot を静かに改変せず new revision として再計算する。この時計を信頼できなければ freshness は UNKNOWN、live action は PAUSE である。

Assignment、exposure、adoption を分ける

ランダム化したのに、実際に使った人だけを treatment と呼ぶと randomization の利点を失う。主 readout は原則として intention-to-treat（ITT）、つまり割り当てられた群で比較する。

assigned_control: eligible かつ control に割当
assigned_treatment: eligible かつ treatment に割当
offered: treatment を受けられる状態になった
exposed: UI/処理が実際に提示・実行された
adopted: 定義済み利用条件を満たした

• ITT は「treatment を提供する方針」の効果を測る。
• exposure/adoption funnel は、効かなかった理由が到達、利用、品質のどこかを診断する。
• exposed treatment vs unexposed control は assignment 後の選択を含むため、主たる因果推定へ置換しない。
• control が別経路で同じ機能を使ったら contamination として残す。都合よく除外しない。

assignment service が失敗した unit、割当前に既に variant を見た unit、複数 variant を見た unit は reason code を持つ。除外規則は効果を見る前に固定し、除外前後を併記する。

Intervention を exact version にする

「新 onboarding」「AI model B」では再現できない。

intervention_id / version:
UI copy / layout / pricing / entitlement version:
code artifact / feature flag version:
model / prompt / tool / routing / policy versions:
fallback / retry / cache policy:
eligible scope / allocation ratio:
started_at / ended_at:
change freeze or approved exceptions:

test 中の hotfix が outcome に影響し得るなら、intervention revision を作る。すべてを捨てる必要はないが、同じ treatment として黙って結合しない。provider model が alias の裏で変わる場合は、取得可能な model snapshot、request/response metadata、eval version、変更時刻を残し、未知なら UNKNOWN_VERSION とする。

Outcome maturity spine を先に作る

標本が小さいと、未成熟を失敗 0 にするだけで結論が大きく動く。割当時に、各 eligible unit がいつ outcome を観測可能になるかを canonical expected_outcome_spine として作る。

expected_outcome_id:
decision_id / subject_id:
assigned_at:
outcome_due_at:
maturity_rule_version:
status: NOT_DUE | DUE_OPEN | OBSERVED | MISSING | INELIGIBLE_CORRECTION
outcome_event_id: N/A | exact ID
missing_reason:
closed_at / evidence:

この expected outcome spine が分母の正本になる。event table に現れた成功者だけを数えない。

missing は 0 ではない

状態	意味	扱い
NOT_DUE	観測窓が未成熟	主 readout から分ける
OBSERVED=0	成熟し、定義済み outcome が起きなかった	0 として数える
MISSING	観測すべきだが取得不能	欠測として件数・理由を示す
UNKNOWN_LINK	event と subject を結合できない	推測せず integrity issue
N/A	metric contract 上 outcome が存在しない	理由と再確認 trigger

欠測処理には仮定がある。complete-case、0 補完、last observation、model-based imputation のどれも自動的に正しくない。小標本では主 readout に raw 件数を残し、欠測が結論を変え得る範囲を sensitivity として示す。たとえば全欠測が treatment failure / control success だった場合も decision が同じかを見る。

ITT は「missing を 0 にする」という意味ではない。分析対象の原則は original assignment の全 eligible unit のまま保ち、観測可能 outcome の x/n、missing m、仮定を置いた estimate を分ける。outcome が欠けた unit の効果推定には追加仮定が必要であり、available-case estimate だけを完全な ITT 効果と呼ばない。

効果を見る前の integrity gate

1. A/A test

同じ体験を二群へ割り当て、assignment、logging、集計だけを通す。A/A は「差が出なかったから完全」ではなく、次を発見する rehearsal である。

• assignment ratio と hash/key の偏り。
• 同じ unit の二重割当。
• variant 別の event loss、clock、cache、bot/test traffic。
• query の join、dedup、window、timezone の誤り。
• naive continuous monitoring による偽 alarm。

A/A で偶然差が出ること自体はある。差の有無だけで pass/fail にせず、事前に検査する invariant と許容される運用誤差を決める。

2. Sample ratio mismatch（SRM）

予定割当 50/50 なのに assignment receipt が 70/30 なら、勝敗より先に原因を調べる。SRM は単なる統計的 nuisance でなく、assignment、eligibility、logging、filtering、bot、performance、variant-specific failure の症状になり得る。

primary SRM は、宣言した randomization unit の assignment receipt を予定 allocation と比較する。下流の exposure、event coverage、outcome missingness は別の attrition / telemetry integrity check とし、treatment が本当に変えた利用差を assignment SRM と混ぜない。triggered analysis を使う場合も、trigger が treatment 後かを確認し、post-treatment selection を SRM 補正で正当化しない。

expected assignment by arm:
actual assigned by arm:
randomization unit / assignment inclusion rule:
diagnostic method / threshold fixed before outcome read:
status: PASS | PAUSE | UNKNOWN
root cause / corrective action:

downstream event coverage by arm:
outcome missingness by arm:
telemetry/attrition status:

SRM test が pass しても unbiased を証明しない。fail したときは p-value を補正して進めるのではなく、原因を説明できるまで business result を PAUSE にする。

3. 必須 integrity checklist

[ ] eligible spine と assignment 数が照合する
[ ] 一 unit 一 assignment、または cluster rule に一致する
[ ] assignment 前 exposure がない
[ ] event ID と dedup key が安定している
[ ] variant 別 coverage / latency / error を比較した
[ ] outcome due と missing を分けた
[ ] contamination と crossover を記録した
[ ] test/internal/bot traffic の規則を固定した
[ ] clock、timezone、cutoff、late arrival を固定した
[ ] query/code/metric/intervention version を snapshot に固定した

小標本の readout

最低限、arm ごとに次を一画面へ置く。

eligible / assigned / exposed / mature:
outcome due / observed / missing:
observed success x / observed outcome n:
contaminated / excluded:

control rate:
treatment rate:
absolute difference:
relative difference:
uncertainty interval and method:
assignment-based effect estimate under prespecified missingness assumptions:
minimum practically important effect:
guardrail events and maximum harm:

絶対差を先に書く

control 1/20、treatment 2/20 は、成功件数差 1 件、率の絶対差 +5 percentage points、相対 uplift +100% である。三つを混ぜず、相対差だけを headline にしない。control rate が 0 のとき relative effect は N/A とし、無限大や 0 へ強制しない。金額なら平均と合計だけでなく、中央値、範囲、最大損失、refund、創業者時間を示す。母集団が異なる比率を足し合わせない。

confidence interval の意味を誤らない

通常の frequentist confidence interval は、同じ手続きを繰り返したときの coverage に関する性質であり、観測後の固定された真値がその区間にある確率を直接表すものではない。区間が広いなら「効果なし」と断定せず、実務的に有益、有害、無視できる範囲のどれがまだ残っているかを書く。

方法名、仮定、unit、cluster、stopping rule を示す。小標本に normal approximation を機械適用しない。二値 outcome の exact method、randomization inference、permutation、cluster-aware method 等は設計に合わせて選び、重要判断では統計家の review を受ける。Bayesian method も小標本を魔法のように解決せず、prior と model assumption を明示する。

p-value は decision state ではない

p-value は、指定 model と帰無仮説の下で観測値以上に極端な結果を得る確率に関わる。次を意味しない。

• treatment が効く確率。
• 結果が偶然である確率。
• 効果の大きさ、顧客価値、再現性。
• data、metric、randomization が正しい証明。
• 出荷すべきかどうか。

p < 0.05 だけで EXPAND、p >= 0.05 だけで no effect にしない。effect size、uncertainty、実務上の閾値、guardrail、費用、可逆性、設計品質を合わせる。

scarce traffic は正しい variance reduction で使う

assignment 前の同じ metric 等、treatment の影響を受けない covariate が outcome と強く相関する場合、CUPED 等で unbiasedness を保ちながら variance を減らせることがある。しかし効果は自 app の coverage と相関次第で、外部事例の削減率を借りられない。

• covariate は assignment / exposure より前に測る。
• treatment によって記録率や値が変わる post-trigger field は使わない。
• A/A で calibration と実装を検査する。
• adjusted と unadjusted の両方を表示する。
• method と covariate を outcome を見る前に固定する。

sample を水増ししたり event を unit として独立扱いすることは variance reduction ではない。同じ account 内の複数 event が相関するなら、その構造に合う標準誤差・分析 unit が必要である。

Peeking、stopping、複数比較

固定 horizon

事前に次を固定する。

maximum eligible units or assignment end:
minimum calendar coverage:
outcome maturity delay:
analysis time:
early stop allowed only for:
  safety / legal / privacy / severe operational harm

売上が良い日に止め、悪い日に延長すると誤判定が増える。週末、給料日、請求 cycle、campaign、operator 学習を跨ぐ必要は business process から決め、traffic benchmark の日数を借りない。

sequential monitoring

途中判断が事業上必要なら、常時有効な区間、alpha spending、group sequential、Bayesian decision rule 等の 事前に選び検証した方法 を使う。単に dashboard を毎日見て fixed-horizon p-value が threshold を越えたら止めることを sequential method と呼ばない。

安全 guardrail は常時監視してよい。ただし safety stop と「primary outcome が勝ったので early ship」を同じ rule にしない。

多数の metric と segment

20 指標、10 segment、毎日の時点を探せば、偶然よく見える切り口を見つけやすい。

• primary outcome と主要 segment を事前固定する。
• guardrail は veto 用であり、勝ち数を水増ししない。
• exploratory slice は EXPLORATORY と表示する。
• 見つけた segment 仮説は、新 cohort や次期間で確認する。
• family-wise error、false discovery 等の補正が必要な設計は、method と family を事前指定する。
• 悪い segment を平均 uplift で隠さず、顧客 harm と公平性を別 gate にする。

設計を claim に合わせる

設計名に順位を付けるのではなく、干渉、周期、割当可能性、可逆性、outcome delay へ合わせる。

design	向く場面	主な仮定・弱点	default claim cap
individual randomized parallel	unit 間の波及が小さく同時比較できる	crossover、identity、contamination	randomization/estimand、interference・missingness 仮定、analysis、integrity が全て pass した範囲で CAUSAL
cluster randomized	team/account 内で影響し合う	cluster 数が少ない、cluster 差	cluster estimand・analysis と全 gate が pass した範囲で CAUSAL
randomized staged rollout	一度に全顧客へ出せず順序を無作為化できる	calendar trend、待機群への波及	design-specific estimand・仮定・analysis・integrity が pass した範囲で CAUSAL
switchback / time block	marketplace、queue、operator 等で同時併存しにくい	carryover、seasonality、serial dependence	carryover/interference、randomization、analysis、integrity が全て addressed の範囲だけ CAUSAL
randomized encouragement	利用を強制できず案内だけ割当可能	adoption 効果には追加の exclusion 等が難しい	default は encouragement assignment の ITT 効果だけ CAUSAL 候補。adoption 効果ではない
interrupted time series	明確な介入時点と十分な前後系列	同時変化、trend、autocorrelation	ASSOCIATION unless strong design
matched / regression adjustment	randomization 不可の探索	unmeasured confounding、model dependence	ASSOCIATION
before/after	早い診断	季節、学習、構成、同時施策	DESCRIPTION/ASSOCIATION

randomization は allocation の公平さだけでない

randomization unit、allocation ratio、seed/hash、strata、blocking、再割当規則、除外規則を記録する。創業者が「良さそうな顧客」を treatment に選んだ後で random test と呼ばない。小標本で重要な既知要因が偏る可能性があるなら、少数の事前 strata や pair を設計するが、後付け balance hunting は避ける。

switchback は交互にするだけではない

午前 A、午後 B、翌日 A のような交互運用は、carryover、曜日、需要構成、operator 学習、在庫、queue の残留を受ける。最低限、次を固定する。

time block length:
randomized block sequence:
washout / carryover window:
seasonality covered:
serial dependence method:
interference path:
outcome attribution window:

retention、更新、長い sales cycle のように outcome が block を大きく跨ぐ場合、短い switchback は通常適さない。carryover が未知なら decision は UNKNOWN または PAUSE とし、claim cap は ASSOCIATION 以下に下げる。

observational comparison の上限

AI 利用者と非利用者、広告経由と organic、partner sourced と direct、高頻度利用者と低頻度利用者には自己選択がある。covariate adjustment、matching、差分の差分等を使っても、測っていない交絡は残り得る。

analysis_claim_cap: DESCRIPTION | ASSOCIATION | CAUSAL
causal assumptions:
known confounders:
unmeasured-confounding risk:
falsification / negative-control checks:
sensitivity analysis:

CAUSAL は手法名ではなく、設計、仮定、integrity、analysis が揃った snapshot にだけ付ける。観測分析が有用でないという意味ではない。優先順位、異常検知、次の実験仮説には十分使える。

勝者だけを残さない

複数 test のうち良い結果だけを採用すると、その winning point estimate は上振れしている可能性がある。+18% の勝者を三件足して来期売上 +54% としない。

• invalid、harm、negative、trivial、inconclusive、valuable を全て ledger に残す。
• launch forecast は raw winning estimate だけで作らず、uncertainty と実装 coverage を含める。
• post-launch realized impact を同じ decision と結び、長期 guardrail と contribution を再確認する。
• segment や期間を探索して選んだ場合、その選択自体を limitation にする。
• replication、holdout、shrinkage 等を使う場合は、対象 portfolio と仮定に合わせて事前設計する。

実験の economics と value of information

全てを実験しない。標本が成熟するまで半年かかり、変更が可逆的で損害が小さいなら、限定 rollout と監視の方がよい場合がある。逆に価格、解約、外部送信、AI 自動作用のように損害が大きい変更は、少ない traffic を理由に無検証で全開しない。

decision value if correct:
maximum loss if wrong:
implementation / instrumentation cost:
founder review minutes:
time to mature evidence:
opportunity cost while waiting:
reversibility and rollback time:
cheapest evidence that could change action:

最小 sample size は alpha だけで決まらない。baseline、variance、effect of interest、power、allocation、cluster、attrition、stopping rule が必要である。前提を置けない段階では、架空の必要人数を出すより、baseline 観測、instrumentation rehearsal、顧客面談、manual pilot、全件 review を先に行う。

実験しない判断

• 法令・契約・security requirement を満たす変更は、違反状態との A/B にしない。
• 明らかに優越し、低費用で可逆、guardrail が強い bug fix は、全件 QA と staged rollout で足りることがある。
• 一件の重大事故で停止すべき action は、平均差を推定する前に安全設計を直す。
• treatment を見せること自体が欺瞞、不当、不公平になり得るなら実施しない。
• traffic が極端に少なく、長期 outcome しかないなら、定性的証拠と bounded rollout を組み合わせ、因果主張を狭める。

AI 機能固有の設計

AI output は同じ input でも変わり、provider、model、prompt、tool、retrieval、routing、fallback が途中で変わり得る。通常の UI experiment に次を追加する。

model_snapshot / prompt_version / policy_version:
tool and data-source versions:
temperature / seed where meaningful:
request, retry, fallback chain:
first presented output:
accepted/final outcome:
human review and rescue:
safety incident / appeal / recovery:
provider change and monitoring receipt:

offline eval は release 前の能力・regression を速く調べる。live experiment は実 workflow での提供方針の効果を調べる。本番 monitoring は非決定性、入力変化、攻撃、provider 変更、利用者適応、低頻度 harm を追う。三つを互いの代用にしない。

平均 helpfulness が上がっても、policy-compliant success、重大誤作用、個人情報漏えい、tool effect、latency、完全負荷後原価、human rescue、顧客の異議申立てを guardrail にする。0 incident は観測能力と exposure を併記する。

日本の privacy・表示・通信 gate

analytics collection 前の data contract

サービス改善のため だけで目的を無制限にしない。event ごとに次を明確にする。

purpose and customer-facing notice version:
data fields / content risk / identifier class:
data subject and relationship:
collection surface / country / location:
destination legal entity / processor role:
sender purpose / destination purpose:
linkage to personal data expected:
consent or other basis review:
retention / deletion / access path:
vendor return/deletion receipt:

cookie、広告 ID、閲覧履歴等が単独で個人データでなくても 個人関連情報 になり得る。受領者が個人データとして取得すると想定される提供では同意確認等が必要になり得る。委託の例外は委託範囲内の必要な取扱いであり、vendor の独自利用を自動的に含まない。

仮名加工情報も、作成者にとって通常の個人情報規律が消える万能な匿名化ではない。対応表、再識別 risk、第三者提供制限、目的、access を確認する。

実 payload はまず synthetic / staging data で network inspection する。production 確認が不可避なら、明示的 authorization、最小 scope、access control、redaction、短い retention、廃棄 receipt を持たせ、pack や Codex prompt へ複製しない。一方、tag manager の画面上の設定だけで実際の送信内容を確認済みともしない。

電気通信事業法の外部送信規律が適用されるサービスでは、実際に送る情報、送信先、利用目的等を利用者が確認できる機会が必要となる場合がある。cookie の有無だけで判定せず、個人情報保護法上の義務と別に確認する。

price、claim、checkout variant

各 variant について、表示根拠、有効期間、通常価格、比較価格、数量、総額・継続課金、支払・提供時期、解約・返品、申込期限を確認する。平均購入率が上がっても、虚偽・誇大な claim、根拠のない比較、架空の urgency、不明瞭な更新・解約で得た uplift は採用しない。

個別価格や A/B 自体が常に一律禁止という意味ではない。しかし、価格・選別ロジックに使う data の目的と通知、実際の価格表示、競争・消費者・差別的影響、高影響顧客への説明と異議経路を fact-specific に確認する。

2026-07-17 公布の改正個人情報保護法は、2026-08-02 時点で大部分が未施行である。16 歳未満、顔特徴データ、統計作成等に関する将来規律・例外を、現行 experiment へ先取り適用しない。施行日、政令・規則、更新ガイドラインを実装時に再確認する。令和 8 年改正個人情報保護法

email experiment

広告宣伝メールは原則として事前同意、表示、容易な opt-out、拒否後抑止を確認する。同意文面、画面、時刻、取得 source、対象 sender/purpose を保存する。subject/copy experiment を、未承諾送信や suppression bypass の理由にしない。

記録期間は制度を分ける。特定電子メール法の通常ルールでは、当該記録に係る特定電子メールを送信しないこととなった日から 1 か月を経過する日までの同意記録、通信販売の特定商取引法では最後の電子メール広告送信日から 3 年間の承諾・請求記録を確認する。措置命令、例外、他の帳簿・契約記録は別に判定し、analytics の共通 TTL だけで消さない。特定電子メールガイドライン / 通信販売

子ども、要配慮情報、高影響判断

要配慮個人情報、同意結果を判断できない子ども、健康、採用、与信、保険、住宅、教育、安全等へ関わる場合は sector_review_required = true とし、対象分野と同意・代理、説明、人の最終判断、訂正・異議、回復を確認するまで開始しない。属性そのものを取得しなくても、郵便番号、端末、行動等が proxy になり得る。

AI 事業者ガイドラインは非拘束的な soft law だが、不当な操作、automation bias、差別的影響を避け、人が合理的に判断し、説明・問い合わせ経路を持つ実験倫理の基準として使える。平均精度や売上 uplift を理由に、特定集団の重大な悪化を許容しない。PPC 通則編 / 子どもの同意 Q&A / AI 事業者ガイドライン第 1.2 版

STOP trigger

• 目的、主体、関係、国/地域、data class、送信先のいずれかが UNKNOWN。
• 実 payload と destination を検証していない。
• claim の根拠がない、期限切れ、variant と一致しない。
• price、継続課金、解約、返品、最終確認が不明瞭。
• email consent または global suppression が結合できない。
• vulnerable user や高影響判断を、人の review・説明・異議・回復なしで最適化する。
• deletion、access、vendor return/deletion を実行・検証できない。

Decision gate

効果量の表より先に veto を評価する。

STOP

• safety、security、privacy、法務、契約、誠実な表示の重大違反。
• 不可逆または許容上限を超える顧客 harm、cash、data、外部作用。
• suppression bypass、unauthorized disclosure、重大な discriminatory impact。

停止後は exposure を止め、incident / notification / recovery の責任系へ渡す。良い primary outcome で相殺しない。

PAUSE

• SRM、重複割当、variant-specific logging loss、time-zero mismatch。
• intervention、metric、query、model、payload の version が不明。
• 重大 guardrail が未成熟、または investigation 中。

UNKNOWN

必要な data、join、正本、maturity、applicability が不足し、readout 自体を作れない。0 や no effect にしない。

INCONCLUSIVE

integrity は pass したが、uncertainty が大きく、有益・無視・有害の実務範囲が複数残る。失敗ではない。次に安い情報、限定維持、別仮説、停止のどれが合理的か決める。

CHANGE

primary は未達だが、driver、個票、failure mode が次の明確な介入を示し、追加損失上限内である。metric を後付け変更して勝ちにせず、新 decision version を作る。

MAINTAIN

拡大全面化する証拠は弱いが、現状 exposure の顧客価値、guardrail、費用、可逆性が許容範囲であり、維持しながら成熟・監視する価値がある。

EXPAND

• integrity と必要な causal assumption が pass。
• primary outcome の効果と uncertainty が実務閾値に照らして十分。
• guardrail、segment harm、品質、完全負荷後原価、容量が pass。
• rollout、rollback、本番 monitoring、責任 owner が用意済み。

EXPAND は永続承認でない。段階ごとに exposure cap を上げ、NIST が指摘する AI 本番監視のように、変化する入力・system・利用状況を継続観測する。

完全架空例 1 — onboarding の小さな randomized rollout

架空の KairoNote は、月内に setup 可能な新規 24 account を account 単位で A/B に割り当てた。primary は「assignment 後 14 日以内に、顧客が確認した最初の completed workflow」。driver は valid import、guardrail は support rescue 60 分超と重大 data error である。

assigned:              A 12 / B 12
outcome due (mature):  A 10 / B 10
observable at snapshot: A 10 / B 9
observed complete-case primary: A 4/10 / B 6/9
missing after due:     A 0 / B 1
not due:               A 2 / B 2
contaminated:          A 1 / B 0
severe data error:     A 0 / B 1
founder rescue >60m:   A 1 / B 3

この数字は B の勝利を意味しない。B は primary の点推定が高いが、標本は小さく区間が広い。さらに missing により integrity は PAUSE、事前 veto に該当する重大 data error により live decision は STOP である。affected data を回復し、原因を修正し、同じ dataset で除外規則を変えて勝ちにせず、新 intervention version で A/A と限定再開条件からやり直す。

完全架空例 2 — pricing before/after

架空の LedgerLeaf は 6 月に price page を変更し、7 月の paid conversion が 3/18 から 5/17 へ増えた。同時に annual campaign、検索流入構成、sales call script も変わった。これは DESCRIPTION であり、price page の causal uplift ではない。

次の action は、価格を元へ戻すか全開する二択ではない。claim と checkout を法務確認し、新規 eligible visitor を session ではなく account/identity rule で割り当て、同時変更を凍結する。または traffic が少なければ、支払意思面談と quote acceptance を bounded cohort で集め、因果 claim を狭める。

完全架空例 3 — AI model routing

架空の DraftPilot は task 単位 randomization を検討したが、一 account の複数 task が同じ reviewer の学習を受けるため account cluster を選んだ。primary は account の成熟した accepted outcome、driver は first-pass acceptance、guardrail は policy failure、誤った external action、p95 latency、provider + review + rescue の完全負荷後原価である。

cluster は 8 account しかなく、平均 score の小さな差は不安定だった。一方 treatment で policy failure が一件起き、tool effect の recovery receipt が欠けた。decision は STOP。これは「p-value が悪い」ためでなく、事前の safety veto と回復不能のためである。

14 日で最小判断系を作る

1〜2 日目 — decision と claim cap

• 今後 30 日に実際に変える一 action を選ぶ。
• eligible population、primary outcome、maturity、実務閾値、最大損失を一枚にする。
• 現在の evidence で DESCRIPTION / ASSOCIATION / CAUSAL の上限を置く。

3〜4 日目 — metric と outcome spine

• primary 1、driver 1〜2、guardrail 1〜2、integrity metric を version 化する。
• assignment 時に expected outcome row を作る。
• missing、late、reopened、dedup、test traffic を定義する。

5〜6 日目 — instrumentation rehearsal

• synthetic account で assignment から maturity まで通す。
• duplicate、late event、missing outcome、contamination、wrong clock を注入する。
• A/A を行い、effect ではなく pipeline invariant を見る。

7〜8 日目 — design と stopping rule

• interference と carryover を図にする。
• randomization unit、allocation、fixed horizon または sequential method を決める。
• legal/privacy/claim/price/email gate を通す。

9〜12 日目 — bounded live

• exposure、cash、顧客、founder minutes の cap 内で開始する。
• safety と integrity は継続監視する。
• primary outcome の途中値で配分、metric、終了日を都合よく変えない。

13〜14 日目 — snapshot と action

• cutoff 時点の query hash、source watermark、version を凍結する。
• x/n、欠測、contamination、絶対差、区間、guardrail を一枚にする。
• STOP / PAUSE / UNKNOWN / INCONCLUSIVE / CHANGE / MAINTAIN / EXPAND と次の責任を記録する。

outcome が 14 日で成熟しない場合、14 日目の成果は勝敗でなく、正常に追跡できる cohort と事前固定した decision contract である。

Codex に任せる範囲

向く作業

• metric contract から event schema、SQL、test fixture、data-quality assertion を生成する。
• query diff、metric version diff、late/missing/duplicate/contamination の診断候補を出す。
• synthetic/redacted data から x/n、絶対差、区間、sensitivity table を再計算する。
• analysis plan と実行結果の不一致、後付け exclusion、未来情報を使う cohort を review する。
• model/prompt/tool/routing version と release evidence を結合する。
• decision memo の fact、assumption、limitation、unknown を分離する。

人が決める作業

• 顧客にとって重要な outcome と実務上の最小差。
• 許容できる harm、privacy、差別、表示、法的・契約上の境界。
• randomization や holdout を顧客へ行う正当性。
• causal assumption、missingness assumption、prior、model choice の受入れ。
• rollout、rollback、顧客説明、専門家への相談。

Codex に この施策は有意ですか、出荷すべきですか と表だけ渡さない。decision、population、versions、assignment、maturity、integrity、claim cap を一緒に渡す。raw 個人データ、会話全文、credential、決済情報を prompt へ貼らない。

週次 review

Decision and version
- 今週 action を決める decision は一つか
- intervention / metric / query / model の revision は何か

Population and maturity
- eligible / assigned / exposed / mature / missing は arm 別に何件か
- expected outcome spine と event が照合するか

Integrity
- SRM、duplicate、coverage、clock、contamination は PASS か
- new issue は business result を PAUSE すべきか

Outcome and guardrail
- primary の x/n、絶対差、区間、実務閾値は何か
- 最大 harm、cost、rescue、segment impact は何か

Decision
- claim cap は DESCRIPTION / ASSOCIATION / CAUSAL のどれか
- STOP / PAUSE / UNKNOWN / INCONCLUSIVE / CHANGE / MAINTAIN / EXPAND のどれか
- next evidence、owner、due、exposure cap、rollback は何か

最終チェックリスト

Decision と metric

• 数字を見る前に decision、eligible、maturity、損失上限を固定した。
• primary 1、driver 1〜2、guardrail 1〜2、data-quality metric を分けた。
• target は自 baseline と事業制約から置き、外部 benchmark を流用していない。
• metric definition、query、source、dedup、時刻、version を固定した。

Design と data

• eligibility、randomization、exposure、analysis unit を宣言した。
• time zero と expected outcome spine を作った。
• assignment と exposure/adoption を分け、randomized rollout の主分析は ITT である。
• A/A、SRM、coverage、duplicate、missing、contamination を先に確認した。
• fixed horizon または事前指定 sequential method を使った。
• exploratory metric / segment を confirmatory と表示していない。

Readout と decision

• arm 別 x/n、絶対差、相対差、区間、欠測、最大 harm を示した。
• p-value を効果の確率、重要性、出荷命令と解釈していない。
• observational analysis の claim cap を ASSOCIATION 以下にした。
• UNKNOWN と INCONCLUSIVE と 0 を分けた。
• safety・法務・privacy・表示の veto を平均 uplift で相殺していない。
• rollout、rollback、本番 monitoring、owner を decision snapshot に結んだ。

Japan・AI

• analytics の目的、payload、送信先法人、role、保存・削除を確認した。
• cookie/ID 結合、仮名加工、第三者提供、外部送信規律を fact-specific に確認した。
• price、claim、subscription、cancel、email consent/suppression を variant ごとに確認した。
• AI の model/prompt/tool/routing、retry/fallback、human rescue、effect recovery を固定した。
• offline eval、live experiment、本番 monitoring を互いの代用にしていない。

根拠と限界

Microsoft の controlled experimentation 資料は、無作為化、仮説、success/guardrail/data-quality metrics、randomization unit、power、SRM の実務上の重要性を示す。ただし大規模 online platform の組織・traffic を個人 B2B の benchmark にしない。controlled experiments / pre-experiment patterns / SRM / metric pitfalls

NIST は confidence interval と sample size が推定手続き、variability、alpha/beta、必要精度等に依存することを説明する。ASA は p-value を真偽確率、効果の重要性、単独の意思決定規則へ読み替えないよう求める。NIST confidence intervals / NIST sample size / ASA statement

CUPED は treatment 前 covariate による variance reduction を示すが、効果は local correlation と coverage に依存し、post-trigger covariate は推定方向まで歪め得る。winner’s curse の研究は、選ばれた成功 test の点推定をそのまま portfolio forecast に使う危険を示す。CUPED / winner’s curse

fixed-horizon inference を任意の連続監視へ流用すると信頼性が崩れ得る。always-valid inference の研究は事前設計された sequential method の選択肢を示すが、任意停止を自動的に正当化しない。Johari et al.

CONSORT 2025 は randomized study の割当、分析人数、効果量と precision、欠測の透明な報告を重視する。臨床試験 reporting guideline を SaaS の法的要件とはしないが、欠測を隠さず設計と結果を結ぶ原則に使う。CONSORT statement / explanation

BMJ の target-trial guidance は eligibility、assignment、follow-up の time zero を揃える重要性を示す。医療研究の設計をそのまま product experiment へ移植せず、利用者だけを事後選択する bias の警告として使う。time zero guidance

switchback の研究は carryover、serial dependence、randomization が推定へ影響することを示す。単純な日替わり A/B の万能性を示すものではない。switchback experiments / finite-sample randomization with carryover

NIST AI RMF と AI 800-4 は用途・risk に合う指標、go/no-go、human input、回復、本番後 monitoring を求め、非決定性や変化する入力等の課題を整理する。AI RMF は改訂中であり、万能な threshold や安全保証ではない。AI RMF Core / AI 800-4

日本の個人情報、個人関連情報、仮名加工情報、委託・第三者提供、利用目的は個人情報保護委員会の現行資料、外部送信規律は総務省、表示・通信販売・広告メールは消費者庁の現行資料を基点にする。主体、データ、関係、地域、商流、表示ごとに適用を確認し、本章を個別法的結論にしない。PPC 通則編 / 個人関連情報 Q&A / 仮名加工情報 / 総務省 外部送信規律 / 消費者庁 表示規制 / 通信販売の申込段階表示 / 特定電子メール

この章が減らせるのは、定義、時刻、割当、計測、分析、判断の取り違えである。未知の交絡、低頻度 harm、将来の市場変化、実装していない logging、虚偽の入力を自動的に消すことはできない。だからこそ、因果 claim を狭くし、UNKNOWN と INCONCLUSIVE を正規の状態にし、限定 rollout と回復可能性を残す。