反証可能な仮説から停止判断までを事前に設計する

到達目標

1. 利用者の問題、介入、期待する変化、反証条件を含む仮説を記述できる

   • 反証可能な仮説、成功指標、停止条件を持つ実験計画
   • 探索と検証、success metricとguardrail、always-validとp-hackingを区別する5分説明

2. success metric、guardrail、stop condition、解析方法を観測前に固定できる

   • 反証可能な仮説、成功指標、停止条件を持つ実験計画
   • 固定したsimulated観測から効果量とguardrail差分を計算し、継続または停止を導く回答

3. 同じ観測値に対してguardrail閾値だけを変え、継続と停止の因果を説明できる

   • 固定したsimulated観測から効果量とguardrail差分を計算し、継続または停止を導く回答
   • 観測値を変えずguardrail上限だけを厳しくして停止判断を再評価した記録

能力の進行

1. recognize

   問題、仮説、primary metric、guardrail、stop conditionを区別できる

   証拠: 反証可能な仮説、成功指標、停止条件を持つ実験計画

2. explain

   有意差の探索や途中結果による指標変更がp-hackingになる理由を説明できる

   証拠: 探索と検証、success metricとguardrail、always-validとp-hackingを区別する5分説明

3. apply

   訪問者、完了、苦情からcompletion-rateとcomplaint-rateを再計算できる

   証拠: 反証可能な仮説、成功指標、停止条件を持つ実験計画

4. diagnose

   primary metricが改善してもguardrail違反なら停止すべき条件を証拠で特定できる

   証拠: 固定したsimulated観測から効果量とguardrail差分を計算し、継続または停止を導く回答

5. lead

   観測前の解析計画と停止権限を関係者と合意し、反証結果を意思決定へ反映できる

   証拠: 観測値を変えずguardrail上限だけを厳しくして停止判断を再評価した記録

なぜ重要か

product discoveryの目的は、思いついたsolutionを早く承認することではない。利用者の問題と不確実性を明らかにし、反証可能な仮説へ変え、安価な証拠で次の投資判断を改善することである。success metricだけを見ると、完了率を上げながら苦情や待ち時間を増やす局所最適を採用しうる。

信頼できる実験計画は、primary metric、guardrail、stop condition、解析方法を観測前に固定する。途中結果を見て都合のよい指標、母集団、終了時点を選ぶp-hackingを避け、改善と害を同じdecisionへ結ぶ。

メンタルモデル

discoveryでは「誰の、どの行動が、何に阻まれているか」を先に調べる。仮説は「対象」「介入」「期待する観測」「反証条件」を持つ。実験はその仮説を守る儀式ではなく、反証された時にも価値ある学習を残す測定契約である。

success metricは狙った価値の変化、guardrailは許容しない害の境界である。primary metricが改善してもguardrailを越えれば成功ではない。stop conditionは「失敗の烙印」ではなく、追加被害と無駄な投資を止める事前契約である。

動く例で考える

完了率改善案を同じ観測値のまま再評価する

前提

checkoutの説明を簡潔にするとcompletion-rateが5 percentage points以上改善し、complaint-rate差分が2 points以下、p95-latency-msが300以下なら継続する、という教材用仮説を使う。実測production dataではなくsimulated集計である。

入力

controlは200 visitors、100 completions、2 complaints、p95 240 ms、treatmentは200 visitors、124 completions、5 complaints、p95 260 msとする。

操作

各variantのcompletion-rateとcomplaint-rateを生のcountから導出し、primary effectとcomplaint deltaを計算する。baselineのcomplaint-rate上限を0.02、transferの上限を0.01として、入力を変えずにdecisionだけを再評価する。

観測

completion-rateは0.50から0.62へ0.12改善し、complaint-rate差分は0.015である。baselineではcontinueだが、厳しいguardrailではstopになる。

結論

結果の意味はsuccess metric単独では決まらない。同じ証拠でも、事前に合意した害の許容境界が変われば決定は変わる。ただし観測後に採用したい案へ合わせて境界を緩めてはならない。

python3.13 - <<'PY'
import json

HARNESS = "product_experiment_lab_v1"
TRANSFER_TASK = (
    "guardrail上限だけを厳しくし、同じ実験結果の継続・停止判断を"
    "再評価する"
)
VARIANTS = {
    "control": {
        "visitors": 200,
        "completions": 100,
        "complaints": 2,
        "p95_latency_ms": 240,
    },
    "treatment": {
        "visitors": 200,
        "completions": 124,
        "complaints": 5,
        "p95_latency_ms": 260,
    },
}
PRIMARY_EFFECT_FLOOR = 0.05
BASELINE_COMPLAINT_LIMIT = 0.02
TRANSFERRED_COMPLAINT_LIMIT = 0.01
P95_LATENCY_LIMIT_MS = 300

def derive_metrics(variant):
    # raw countから毎回導出し、都合のよいrateの手入力を防ぐ。
    visitors = variant["visitors"]
    assert visitors > 0, "experiment-visitors-invariant"
    return {
        "completion_rate": variant["completions"] / visitors,
        "complaint_rate": variant["complaints"] / visitors,
        "p95_latency_ms": variant["p95_latency_ms"],
    }

def evaluate_decision(
    primary_effect,
    complaint_delta,
    treatment_latency_ms,
    guardrail_limit,
):
    primary_passed = primary_effect >= PRIMARY_EFFECT_FLOOR
    guardrail_passed = complaint_delta <= guardrail_limit
    assert guardrail_passed == (
        complaint_delta <= guardrail_limit
    ), "experiment-causal-invariant"
    latency_passed = treatment_latency_ms <= P95_LATENCY_LIMIT_MS
    decision = (
        "continue"
        if primary_passed and guardrail_passed and latency_passed
        else "stop"
    )
    return {
        "decision": decision,
        "primary_passed": primary_passed,
        "complaint_guardrail_passed": guardrail_passed,
        "latency_guardrail_passed": latency_passed,
        "complaint_rate_limit": guardrail_limit,
    }

derived_metrics = {
    variant_id: derive_metrics(variant)
    for variant_id, variant in VARIANTS.items()
}
primary_effect = (
    derived_metrics["treatment"]["completion_rate"]
    - derived_metrics["control"]["completion_rate"]
)
complaint_delta = (
    derived_metrics["treatment"]["complaint_rate"]
    - derived_metrics["control"]["complaint_rate"]
)
baseline = evaluate_decision(
    primary_effect,
    complaint_delta,
    derived_metrics["treatment"]["p95_latency_ms"],
    BASELINE_COMPLAINT_LIMIT,
)
transferred = evaluate_decision(
    primary_effect,
    complaint_delta,
    derived_metrics["treatment"]["p95_latency_ms"],
    TRANSFERRED_COMPLAINT_LIMIT,
)
assert baseline["decision"] == "continue", "experiment-baseline-invariant"
assert transferred["decision"] == "stop", "experiment-transfer-invariant"

fixed_inputs = {
    variant_id: dict(variant)
    for variant_id, variant in VARIANTS.items()
}
report = {
    "harness": HARNESS,
    "fixture_metadata": {
        "kind": "simulated",
        "provenance": (
            "lesson-defined aggregate counts; no production observations"
        ),
        "limitations": (
            "does not estimate sampling error, allocation bias, novelty, "
            "or external validity"
        ),
    },
    "hypothesis": {
        "statement": (
            "簡潔な説明はcompletion-rateを0.05以上改善し、"
            "事前guardrail内に保つ"
        ),
        "falsifiable": True,
    },
    "analysis_plan": {
        "locked_before_exposure": True,
        "primary_metric": "completion-rate",
        "guardrail_metrics": [
            "complaint-rate",
            "p95-latency-ms",
        ],
        "stop_conditions": [
            "primary-effect-below-floor",
            "complaint-rate-above-limit",
            "p95-latency-above-limit",
        ],
        "sequential_method": "always-valid",
        "p_hacking_prohibited": True,
    },
    "experiment": {
        "variants": VARIANTS,
        "derived_metrics": derived_metrics,
        "primary_effect": primary_effect,
        "complaint_delta": complaint_delta,
        "baseline_evaluation": baseline,
    },
    "guardrail_threshold_transfer": {
        "changed_assumption": "guardrail-threshold",
        "changed_fields": ["complaint_rate_limit"],
        "baseline_inputs": fixed_inputs,
        "transferred_inputs": {
            variant_id: dict(variant)
            for variant_id, variant in VARIANTS.items()
        },
        "baseline_decision": baseline["decision"],
        "transferred_decision": transferred["decision"],
        "baseline_limit": BASELINE_COMPLAINT_LIMIT,
        "transferred_limit": TRANSFERRED_COMPLAINT_LIMIT,
    },
    "mastery_evidence": {
        "lab_steps": [
            {"step": 1, "evidence": "反証可能な仮説を固定した"},
            {"step": 2, "evidence": "解析計画と停止条件を固定した"},
            {"step": 3, "evidence": "countからvariant rateを導出した"},
            {"step": 4, "evidence": "baseline decisionを再現した"},
            {"step": 5, "evidence": "guardrailだけを変えて再評価した"},
        ],
        "assessments": [
            {"assessment": 1, "evidence": "successと害を同時評価した"},
            {"assessment": 2, "evidence": "optional stoppingを分離した"},
        ],
        "rubric_dimensions": [
            "technical-correctness",
            "judgment",
            "evidence",
            "communication",
        ],
        "transfer": {
            "task": TRANSFER_TASK,
            "changed_assumption": "guardrail-threshold",
            "evidence": "同一入力でcontinueからstopへ変化した",
        },
    },
    "runtime_bound": {
        "records": sum(
            variant["visitors"]
            for variant in VARIANTS.values()
        ),
        "subprocesses": 0,
    },
    "external_network_used": False,
}
print(json.dumps(report, ensure_ascii=False, sort_keys=True))
PY

トレードオフと失敗モード

• 誤診: treatmentのcompletion-rateが高いので採用する。 反証: complaint-rateとlatencyのguardrailを同時に評価し、害の上限を越えた場合はstopする。
• 誤診: always-validなら好きな時点とsegmentで有意な結果を探してよい。 反証: sequential method、primary metric、停止規則を観測前に固定し、探索結果は新しい仮説として別の検証へ送る。
• 誤診: 反証された仮説は失敗なので報告しない。 反証: 期待したmechanismが働かない証拠を意思決定記録へ残し、次の投資を止めた価値を評価する。

知識チェック

1. 「新しい画面は好まれる」を、対象、介入、観測、反証条件を持つ一文へ書き換えよ。
2. completion-rateが12 points改善し、complaint-rateが1.5 points悪化した。事前上限が1 pointならどのdecisionを選び、なぜか。
3. 観測後にprimary metricを変更する行為と、探索から新しい仮説を作る行為をどう分離するか。
4. guardrail上限以外の入力が同じであることを、再実行可能な証拠としてどう示すか。

出典と次の学習

出典は2026-07-30に版と公開状態を確認した。GOV.UKのdiscovery guidanceはproblem spaceの学習とsolution決定を分ける実務境界として用いた。Kohavi、Tang、Xuによる2020年の実験書とMicrosoftの実験報告は、controlled experiment、metric設計、organizational practiceの一次資料として扱った。

Always Valid InferenceはOperations Research掲載版のcontinuous monitoring手法として参照した。ただし本lessonのsimulated集計は統計的検定を実施せず、always-validの語を任意の途中終了やp-hackingの免罪符にはしていない。次は実際の標本設計、検出力、割付単位、SRM、長期効果を学び、探索とconfirmatory experimentを分離する。

実践ラボ

完了率改善案のsimulated実験計画と停止判断を作る

提出成果物: 反証可能な仮説、成功指標、停止条件を持つ実験計画

1. 利用者の離脱問題から介入、期待するcompletion-rate改善、反証条件を一文の仮説へ固定する
2. primary metric、complaint-rateとp95-latency-msのguardrail、stop condition、always-valid解析を観測前に記録する
3. 固定simulated集計の訪問者、完了、苦情からvariant別rateとtreatment effectを導出する
4. success metricとguardrailを同時評価し、baseline上限でcontinueとなる根拠を説明する
5. 同じ実験入力のままcomplaint-rate上限だけを厳しくし、stopへ変わる判断と変更した仮定を記録する

説明して理解を確かめる

5分で、discoveryがsolution承認ではない理由、反証可能な仮説の条件、success metricとguardrailの役割、always-validでもp-hackingを正当化できない理由を説明する。

アセスメント

1. 問い: completion-rateは改善したがcomplaint-rateも上昇した。どの事前契約を使って継続または停止を判断するか。

   期待する証拠: 仮説、primary effect、guardrail差分、事前上限、stop condition、観測後に閾値を変えない原則

2. 問い: 途中結果を毎日見て、有利になった時だけ終了したいという提案をどう再設計するか。

   期待する証拠: optional stopping、always-valid、解析計画の事前固定、検定回数、p-hacking、意思決定権限

別問題へ転用する

guardrail上限だけを厳しくし、同じ実験結果の継続・停止判断を再評価する

復習スケジュール

1. 1日後

   反証可能な仮説に最低限必要な四要素は何か

2. 7日後

   success metricが改善してもguardrailで停止するのはなぜか

3. 30日後

   always-validとp-hackingの違いを一例で説明する

4. 90日後

   反証可能な仮説に最低限必要な四要素は何か

評価ルーブリック

出典

以下の外部資料は利用者が選択したときだけ開きます。

• How the discovery phase works (primary)
• Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing (primary)
• Online Experimentation at Microsoft (primary)
• Always Valid Inference: Continuous Monitoring of A/B Tests (peer-reviewed)