実験を意思決定と文化に ― 単発で終わらせないために
個々の実験を、再現性のある基盤と意思決定プロセスに組み込む方法を扱います。「実験の記録・再現性」「ガードレールの常設」「結果を、案ごとの配信比率の自動調整（バンディット）や次の施策へ繋ぐ運用」を整理し、Kaggle連載のオンライン最適化・因果連載・活性化連載へと接続します。
by Shin
良い実験を1回やった後、それを組織の力にするには何が要るのか。答えは、記録・再現性・常設ガードレール・結果を次へ繋ぐ運用で、その場しのぎの単発実験を、資産を生む文化に変えることです。この最終回では、個々の実験を意思決定プロセスに組み込む形を、架空のD2C企業の例を用いて具体化します。
本連載は「介入を自分で設計して因果を測る」側で、観測データから因果に迫る因果編とは役割が逆でした。第1回から第6回までで、設計（検出力・MDE）→ 何を成功とするか（メトリクス）→ 実務の罠（SRM・多重比較）→ いつ止めるか（逐次・peeking）→ 少ないサンプルで効かせる（CUPED）→ 分けられないとき（geo・switchback）までを順に積み上げてきました。最後に残るのは、これらを1回の打ち上げ花火で終わらせず、回り続ける仕組みにすることです。
実験の記録と再現性
実験を文化にできない組織には、共通の症状があります。半年前に同じ実験をやっていたことに気づかず二度回す。「あの施策、結局効いたんだっけ」に誰も答えられない。誰がいつ何を根拠に採用を決めたのか追えない。これらはすべて、記録が無いことから来ます。
解決は地味です。1実験=1レコードの実験レジストリを持ち、走らせる前にそこへ書き込む。書く項目は本連載で積み上げてきたものとほぼ一致します。「仮説」「主要指標とその事前固定（第2回）」「MDEと必要サンプル数（第1回）」「割付方式」「開始・終了」「停止規則（第4回）」、そして「実験後に追記する結果・意思決定・発動条件」です。
ここで効いてくるのが**事前登録（pre-registration）**です。指標・停止規則・分析計画を走らせる前に固定してしまえば、後付けのセグメント分析（第3回）と、有意になった瞬間に止めるpeeking（第4回）に対する構造的な防御になります。「分析計画を後から変えられない」状態を仕組みで作るのが要点で、本人の自制心に頼らないところがポイントです。
SOLNAでは、配信実験は messages、サイト内実験は sessions を起点にしますが、どちらにも experiment_id を持たせ、レジストリ（experiments）から1対多で辿れるようにします。
-- 実験レジストリ（dbt Mart に1テーブル追加する想定。名称は読み替え可）
create table experiments (
experiment_id text primary key,
hypothesis text, -- 仮説（何がなぜ効くと考えたか）
primary_metric text, -- 北極星指標（第2回・事前固定）
guardrail_metrics text[], -- ガードレール指標（第2回）
mde numeric, -- 最小検出効果（第1回）
planned_n int, -- 必要サンプル数（第1回で逆算）
alloc_method text, -- 'user_hash' | 'geo' | 'switchback'（第6回）
stopping_rule text, -- 'fixed_horizon' | 'sequential'（第4回）
started_at timestamp,
ended_at timestamp,
-- 走らせる前はここまで（事前登録）。以下は終了後に追記 --
result_effect numeric, -- 推定効果量と区間
result_ci_low numeric,
result_ci_high numeric,
decision text, -- 'ship' | 'iterate' | 'kill' | 'bandit'
trigger_condition text, -- killの場合の再評価トリガー（発動条件）
data_snapshot text, -- 再現性: スナップショットID
code_version text, -- 再現性: 分析コードのgit sha
rng_seed int
);
-- 実験面のレコードは experiment_id で紐づく
-- messages.experiment_id / sessions.experiment_id を外部キーとして付与過去レコードが貯まると、レジストリ自体が一次データになります。たとえばSOLNAの直近四半期を眺めると、走らせた実験は20〜30本、主要指標が事前固定の基準で有意に改善したのは全体の2〜3割、ガードレール抵触で巻き戻したのは1〜2本、という分布が見えてきます（数値はレンジで丸めた例）。この「勝率は2〜3割が普通」という事実を組織が共有していること自体が、立場が上の人の意見で結果が覆る現象への対策になります。
常設ガードレールと安全な高速化
ガードレールは、1回ずつ手で確認していると遅かれ早かれ形骸化します。実験のたびに担当者がSRMをチェックし、解約率やページ速度を目視で見る——最初の数本は回りますが、本数が増えると抜けます。だから**常設化（standing guardrails）**します。全実験に対して同じ検査を自動で常時かける、という発想です。
常設すべき検査は主に2つです。1つはSRM（標本比率ミスマッチ、第3回）の自動検知。割付比率が設計と食い違っていたら、その実験の結果は無効なので、まず全実験に常時カイ二乗検定をかけます。もう1つはガードレール指標の閾値監視（第2回）。北極星が上がっても、解約・問い合わせ・表示速度といった「壊してはいけない指標」が悪化したら、アラートを出し、必要なら自動で巻き戻します。
# 全実験を回す常設ガードレール・バッチ（毎時実行する想定）
import numpy as np
from scipy import stats
def check_srm(counts, ratio=(0.5, 0.5)):
"""割付比率のミスマッチをカイ二乗検定で検知（第3回）"""
expected = np.array(ratio) * counts.sum()
chi2, p = stats.chisquare(counts, f_exp=expected)
# p が小さいほど割付が壊れている。閾値は厳しめに。
return {"chi2": chi2, "p_value": p, "srm_flag": p < 0.001}
def check_guardrails(metrics, thresholds):
"""ガードレール指標の劣化を検知（第2回）。悪化が許容外ならフラグ。"""
breaches = []
for name, delta in metrics.items(): # delta = 対照比の変化
limit = thresholds[name] # 例: 解約は +0.5pt まで、速度は +50ms まで
if delta > limit: # 悪化方向に閾値超過
breaches.append(name)
return breaches
def nightly_guard(experiments):
"""レジストリ上の running 実験すべてに同じ検査をかける"""
alerts = []
for exp in experiments: # messages/sessions から集計済みの形で渡す
srm = check_srm(exp["arm_counts"])
breaches = check_guardrails(exp["guardrail_deltas"], exp["thresholds"])
if srm["srm_flag"]:
alerts.append((exp["experiment_id"], "SRM", "結果無効・要調査"))
if breaches:
# 自動巻き戻し or 即時停止。誰の承認も待たない。
alerts.append((exp["experiment_id"], "GUARDRAIL", breaches))
return alertsここで強調したいのは、ガードレールの常設は安全な高速化の前提条件だということです。逐次検定（第4回）やCUPED（第5回）は「速く回す」ための道具でしたが、速さは雑さと紙一重です。常設ガードレールがあって初めて、速く回しても事故が自動で止まる。速さと安全はトレードオフではなく、ガードレールが両立させる関係にあります。守りを自動化したぶんだけ、攻めを速くできると考えてください。
結果を次へ繋ぐ（配分・施策・再学習）
実験は終点ではなく分岐点です。結果が出たら、レジストリの decision に応じて機械的に次のアクションへ流します。採用なら施策の本実装へ、勝ち負けが拮抗しているなら配分の動的最適化へ、観測でしか測れない残りは因果手法へ——という三方向です。
# 実験結果 → 次のアクションへのルーティング
def route_next_action(exp):
eff, lo, hi = exp["result_effect"], exp["result_ci_low"], exp["result_ci_high"]
if lo > 0: # 区間が完全に正。効果が明確
return "ship" # → 本実装。実行は活性化の連載へ
elif hi < 0: # 区間が完全に負。明確に悪い
return "kill" # → 発動条件を添えて記録（再評価のトリガー）
else: # 区間が0をまたぐ。決め切れない
# 固定A/Bの先＝逐次に学びながら配信比率を寄せる（バンディット）
return "bandit"bandit へ送られたものは、勝者を決め打ちせず、配分を動かしながら学習します。固定A/Bが「2択の優劣を一度だけ判定する」のに対し、バンディットは「報酬を見ながら良い方へ配分を寄せ続ける」発想です。最小の要点だけ示します（深掘りは実務に載せる ― 解釈・運用（MLOps-lite）とオンライン最適化への接続）。
# Thompson sampling の最小構成（バンディット移行の入口）
def thompson_choice(success, trials):
"""各armの成功/試行からベータ分布をサンプリングし、最大のarmを選ぶ"""
import numpy as np
samples = [np.random.beta(s + 1, (n - s) + 1) for s, n in zip(success, trials)]
return int(np.argmax(samples))
# SOLNA: messages の配信クリエイティブを arm に、converted を報酬にして配分3つ目の流れが再学習ループです。実験で得た因果効果は、予測やCATE（誰に効くか）のモデルを更新する一次データになります。SOLNAなら、messages.holdout_flag でランダム化した配信ログ（活性化の連載で仕込んだ holdout＝配信を止めて残した対照群）が、次のuplift推定の入力になり、その出力が次の配信ターゲティングを決める——という循環です。実験が「効いたか」を測るだけでなく、「次に誰へ打つか」を更新し続ける装置になります。
なお、ユーザー単位で分けられない部分（ブランド広告・供給面）は、この三方向では拾い切れません。そこは地域や時間で分けるgeo・switchback（第6回）か、観測データから因果に迫る手法（因果編）へ橋渡しします。介入で測れるものは介入で、分けられないものは観測で——という棲み分けが、ここでもう一度効いてきます。
実験文化の落とし穴（HiPPO・実験衛生）
仕組みを整えても、文化が伴わないと崩れます。落とし穴を2系統に分けて押さえます。
1つ目はHiPPO（Highest Paid Person's Opinion）——立場が上の人の意見で実験結果が覆る現象です。これは私が発信全体で守っている線、「主張は『誰が言ったか』ではなく中身で評価される」という原則と正面からぶつかります。対策は精神論ではなく仕組みです。事前登録で指標と停止規則を固定し、結果と意思決定をレジストリに残す。誰が決めたかではなく、何を根拠に決めたかが記録に残る状態を作れば、権威で結論を上書きする余地が構造的に狭まります。
2つ目は**実験衛生（experiment hygiene）**です。代表的なものを挙げます。
- 実験同士の干渉: 同じユーザーに複数の実験が当たり、効果が混ざる。割付の独立性を常設で点検する。
- 新奇性効果・初期効果: 変更直後だけ数字が動き、慣れると消える。十分な観測期間を取る。
- 短期と長期の乖離: 短期の北極星が上がっても、長期の解約で食われる。ガードレールに長期指標を含める。
- 勝率インフレ: 「効いた実験」だけを語ると、組織が実験を過大評価する。
文化の健全さを測るときも、速度（velocity）だけを追うのは危険です。月あたりの実験本数だけをKPIにすると、衛生を犠牲にして本数を稼ぐ動機が働きます。速度・品質（事前登録率・SRM抵触率）・意思決定への反映率の3つで見るのが、現実的なバランスです。
対応書籍と読みどころ
- Kohavi ほか『A/Bテスト実践ガイド』（Trustworthy Online Controlled Experiments 邦訳）。実験基盤・組織・実験文化・OEC（総合評価基準）・過去実験の記憶化（institutional memory）といった、まさに本回のテーマを扱う章があり、連載の締めの土台になります。
- 効果検証入門（ホクソエム）。結果を「観測からの因果」へ送り出す側の土台。分けられない施策を因果手法へ橋渡しする判断の根拠になります。
- 統計学入門（東京大学出版会・赤本）。SRMのカイ二乗検定や、勝率・分布を読む素養の足場。常設ガードレールの統計的根拠として参照します。
章末チェックリスト
- 実験を再現できる形で記録しているか（仮説・指標・停止規則・結果・意思決定・スナップショット）
- 事前登録で、走らせる前に指標と停止規則を固定しているか
- SRMとガードレールを常設で自動監視し、抵触時に自動で止まるか
- 結果を次のアクション（採用・配分・再学習）へ機械的に繋げているか
- HiPPOで結論が覆らない構造（記録・事前登録）になっているか
- 勝率・実験衛生（干渉・新奇性・短期長期乖離）を点検しているか
逐次に学びながら配信比率を寄せる先は実務に載せる ― 解釈・運用（MLOps-lite）とオンライン最適化への接続、観測データから因果に迫る側は因果編、採用した施策の実行はなぜ「分析して終わり」になるのか ― ループの不在へ。本連載で設計した一つひとつの実験が、これらに接続されることで、設計→実行→効率化→分けられないとき→組織、という一連の流れに組み込まれます。自社のデータで「どの手法が成立し、何をやらないか」を見極める判断は、対になる因果編へ。