diagnosing-experiment-results

実験結果の診断

このスキルでは、次の疑問に答えます。PostHog の実験結果がおかしい、偏っている、または空に見えます。何が起きているのでしょうか？

ディスパッチ表でユーザーの訴えに一致する項目を確認し、該当するリファレンスファイルを読んで診断してください。

リファレンスファイル内の各診断には、検証の確度に応じて [HIGH]、[MEDIUM]、[LOW] のタグが付いています。[HIGH] は PostHog のコードで直接検証済み、[MEDIUM] は一部検証済み、またはチームの情報源で確認済み、[LOW] はここでは検証されていない SDK／外部の動作を示します。[LOW] の項目は断定する事実ではなく、検証すべき仮説として扱ってください。

Step 1 — 実験を特定する

ユーザーが実験を名前や説明で示した場合は、まず finding-experiments スキルを読み込み、具体的な ID を特定してください。

experiment-get を呼び出し、次のフィールドを取得してください。これらは、ほぼすべての診断に必要な入力です。

• feature_flag.filters.multivariate.variants[].rollout_percentage — バリアントの割り当て比率
• exposure_criteria.multiple_variant_handling — 指定がない場合のデフォルトは "exclude"
• exposure_criteria.exposure_config.event — 未設定の場合はデフォルトの露出イベントになります。どのイベントかは resolved_exposure_event で確認してください（$feature_flag_called または $experiment_exposure。サーバー側で解決され、どちらもプロパティは同じです）
• exposure_criteria.filterTestAccounts — デフォルトは true
• feature_flag.active、ステータス（draft / running / paused / exposure_frozen / stopped）、start_date、end_date
• feature_flag.filters.groups[] — 各グループについて、variant、properties、rollout_percentage を確認してください（そのグループのロールアウト率。実験に入る、条件に一致するバケッティング単位（人物、または feature_flag.filters.aggregation_group_type_index が設定されている場合はグループ）に対する割合です。各グループに個別の値があるため、フラグに無条件のグループが 1 つある場合を除き、全体として単一のロールアウト率はありません）。variant が null 以外の場合、条件に一致するコホートにバリアントを強制的に割り当てるオーバーライドです（ランダム化ではなく、リリース条件に基づく割り当て）。これは A7 に該当します。重大な設定（A7b）に注意してください。高いロールアウト率で条件が広範囲、または空の properties を持つ、バリアントが固定されたグループがある場合、あるいはランダム化されたグループ（variant: null）が残っていない／一方のアームへのリリース経路がない場合、もう一方のバリアントが枯渇し、分析可能な露出が一方のアームにほぼ 0 件となります。references/bias-and-skew.md を参照してください。
• stats_config — ベイズ法（デフォルト）または頻度論的手法

Step 1.5 — 診断スナップショットを取得する（質問する前に確認）

ユーザーに確認の質問をする前に、references/diagnostic-snapshot.md の診断スナップショットを取得してください。このスキルの診断のほとんどは、聞き取りをせずにこのデータから確認または除外できます。

Step 2 — 症状を診断項目に照合する

ユーザーの発言…	診断グループ
「小さいほうのバリアントに偏りがあるようです」／バナーに偏りと表示される	A — 偏りと不均衡
「バリアントの比率が分割と一致しません」／SRM 警告	A — 偏りと不均衡
「なぜ 50/50 ではないのですか？」／「両方のグループにいるユーザー」	A — 偏りと不均衡
「コントロールとテストの両方にいるユーザー」／$multiple の割合が高い	A — 偏りと不均衡
サーバーサイドレンダリングのアプリで複数のバリアントに接触する	A — 偏りと不均衡
フィーチャーフラグ／実験の状態の不一致に関するバナー	A — 偏りと不均衡
「distinct_id を移行中」／実行途中に「匿名から user_id に切り替え」	A — 偏りと不均衡
指標のカウントが接触数より大幅に少ない（例：10 倍または 100 倍の差）	A — 偏りと不均衡（D より先にこちらへ）
「実験のデータが 0 件／不足しています」／空欄	B — 空の実験
「バリアントが常に undefined／false です」	B — 空の実験
「$feature_flag_called は発生していますが、接触が表示されません」	B — 空の実験
「実験は実行中と表示されますが、数週間／数か月、接触数に変化がありません」	B — 空の実験
「実行期間を延ばすと有意性が何度も変わります」	C — 解釈上の落とし穴
「有意と判定されたのに、後で有意ではなくなりました」	C — 解釈上の落とし穴
「接触数 46 件で 30/16 に分かれています。問題がありますか？」	C — 解釈上の落とし穴
「A/A テストで有意な結果が出ています」	C — 解釈上の落とし穴
「指標が多数あり、有意なものとそうでないものがあります」	C — 解釈上の落とし穴
「ベイズ分析では勝つ確率が 96％です。リリースすべきですか？」	C — 解釈上の落とし穴
「信頼区間が重なっています。つまり有意ではないということですか？」	C — 解釈上の落とし穴
「外部ツール（有意性計算ツールまたは AI エージェント）の結果が PostHog と一致しません」	C — 解釈上の落とし穴
「リリースすべきですか？主要指標は上昇していますが、副次指標は低下しています」	C — 解釈上の落とし穴
「PostHog の数値 ≠ SQL のカウント」	D — 数値と SQL
「ファネルでは X％ですが、生イベント数では Y 件です」	D — 数値と SQL
「収益の合計がおかしい」／「内訳に『none』と表示されます」	D — 数値と SQL
「レコーディングのパネルが統計と一致しません」	D — 数値と SQL
「フィルターを適用しましたが、ユーザー数が変わりません」	D — 数値と SQL
「現在の人物プロパティ（接触時点ではなく現在の値）で結果を分類したい」	D — 数値と SQL
「実行途中に分割／ロールアウト／指標／条件を変更したら、結果がおかしくなりました」	E — 実行途中の変更
「終了／リリース後、フラグが予期せず 0/100 に切り替わりました」	E — 実行途中の変更
「長期指標が主要指標と逆方向に動いています」	E — 実行途中の変更
「リテンション指標に予期しないユーザーが含まれています」	E — 実行途中の変更
「実験終了後、フィーチャーフラグを単純な（ブール値の）フラグに戻せません」	E — 実行途中の変更
「新しいバリアントで実験を再開するにはどうすればよいですか？」	E — 実行途中の変更
指標の行は表示されますが、結果ブロックが空です／勝率または有意性が表示されません	E — 実行途中の変更（E13 の旧方式）
「結果を読み込めません」／多くの指標行に data: null と表示されます（旧方式の実験ではない）	ステップ 1.5 — 診断スナップショット（null 行）
「ユーザーは新しいフローについてどう思っていますか？」／実験に関する定性的なフィードバックを求めている	F — 定性的なフィードバック
「なぜユーザーはコントロールを好んだのですか？」／「テストバリアントの何が気に入らなかったのですか？」	F — 定性的なフィードバック
症状が明確でない場合は、選択する前に確認の質問を1つしてください。診断ごとに対処法は異なります。
推測しないでください。

ステップ 3 — 証拠から導ける診断をすべて提示する

ステップ 2 で症状を照合し、関連するリファレンスファイルを読んだら、アクションを推奨する前に該当する診断をすべて列挙してください。

同時に発生するメカニズムは、それぞれ独立して提示してください。1つがより目立っている場合でも、「待つ」または「修正する」という単一の推奨にまとめないでください。メカニズムごとに対処法は異なります。_系統的な_バイアス（例：不均等な分割と Exclude の組み合わせ）は待っても解消しませんが、_統計的な_パターン（例：サンプル数が少ない場合の分散）は解消します。まとめて助言すると、ユーザーがその助言に従った後もバイアスが残ってしまいます。

プロジェクトの状態を確認する手段があるメカニズムのみ列挙してください。確認手段には、設定（experiment-get から取得）、スナップショットデータ、アクティビティログ、リポジトリのソースがあります。設定から判断できるメカニズムも含めてください。デフォルトの multiple_variant_handling="exclude" を使った80/20の分割は experiment-get で確認できるため、列挙の対象です。根拠となる情報がないメカニズム（例：スナップショットでバリアント比率に問題がないのに SRM を挙げること）は挙げないでください。

診断グループ

A — バイアスと偏り

バリアント間のバランスが取れていないように見える、あるバリアントに偏りがあるように見える、アプリ内の警告バナーが表示された、またはユーザーが複数のバリアントに現れている場合に該当します。不均等な分割と Exclude の組み合わせ、SRM、ID の分断、ブートストラップと /decide の不一致、フラグと実験の状態の不整合を扱います。

→ references/bias-and-skew.md を参照してください

B — 空の実験／露出数0／「データが不足しています」

よくある問題です。SDK の呼び出し（誤った評価方法、identify() のタイミング、重複排除）、露出の記録（カスタムイベントにバリアントのプロパティがない、必須プロパティ、広告ブロッカー）、露出条件との一致（テストアカウントのフィルター、適格性の判定順序、露出前にイベントが発生）を扱います。

→ references/empty-experiment.md を参照してください

C — 有意性／解釈の落とし穴

有意性の反転、A/A テストで有意性が示されること、ベイズ統計と頻度論の混同、多重比較、トラフィック量が少ない場合の分散、途中経過の確認／早期終了を扱います。従来の統計上の問題（新しいベイズモジュール以前は、A/A テストで有意性が過剰に示されていたこと）と、2025年1月に勝率の算出方法がどのように変わったか（コントロール対すべてのバリアントではなく、単一のテスト対コントロール）も含みます。

→ references/interpretation.md を参照してください

D — 数値が一致しない（PostHog とユーザーの SQL／生カウント）

実験ページでは、露出範囲、$multiple の除外、テストアカウントのフィルター、日付範囲が適用されますが、アドホックな SQL ではほとんど再現されません。ファネルのアトリビューション（統計にカウントされるのは最初のステップから最後のステップまでのみ）、ブレークダウン（メトリックイベントではなく露出イベントから読み取る）、ユーザーあたりの平均値と「収益の合計」の混同、レコーディングパネルと統計の差異を扱います。

→ references/numbers-vs-sql.md を参照してください

E — 実験途中の変更後に起こる想定外のこと（ライフサイクルやリテンションの特有の挙動を含む）

ロールアウトの増加は安全ですが、減少には注意が必要です。バリアントの分割を変更するのはアンチパターンであり、実験途中でメトリックを追加するのは p 値の悪用にあたります。ship-variant によってフラグが想定外の形で書き換えられることがあり、リセットで消去されるのは結果であってフラグではありません。また、リテンションメトリックの特有の挙動（最初のイベントが露出後に発生する必要がある設計）、「成熟したユーザー」のフィルタリング、長期メトリックと短期メトリックの差異も扱います。

→ references/mid-run-changes.md を参照してください

F — 定性的なフィードバック：数値がどれだけ動いたかではなく、変更がどう受け止められたか

グループ A〜E では、メカニズムを見つけます。F で扱うのは、そこでは答えられない問いです。実験に参加した人々は、変更をどう受け止めたのでしょうか。実験対象のフローを完了したユーザーに表示する短いアンケートで、評価と任意のコメントという定性的な側面を加え、バリアントごとに確認できます。現在は MCP 経由で利用できます。

適している実験と、そうでない実験があります。判断の基準は、両方のバージョンを見せなくても、ユーザーが変更内容を説明できるかどうかです。フロー、レイアウト、プロセスの見直しは対象になりますが、しきい値やランキングの調整は、測定された効果がどれだけ大きくても対象になりません。機械的な診断がまだ解決していない間は、アンケートを提示しないでください。壊れたフラグのゲートにアンケートを重ねると、対象者の半数に届いていない機能への意見を集めることになります。また、新しいアンケートを提案する前に、既存または最近のアンケートが対象期間をすでにカバーしていないか確認してください。

作成前に、次の 2 点を正しく理解しておく必要があります。単一のバリアントにだけ表示されるアンケート自体が、バリアント間の差になります。また、フラグにリンクされた_実行中_のアンケートは、エクスポージャーイベントを生成する場合があります。

→ references/qualitative-feedback.md を参照してください。

ステップ 4 — 実験の状態に合わせて推奨内容を調整する

まず診断を提示します（ステップ 3）。次に推奨を提示します。ただし、推奨内容は実験の現在の状態で可能な範囲に絞ってください。

• 下書き — 設定変更に制約はありません。推奨し、適用してください。
• 実行中 — あらゆる変更にトレードオフがあります。推奨する前に、実行中の変更がもたらす影響（アンチパターンか、安全か、ユーザーに見えるか）を説明してください。実行中のルールについては、configuring-experiment-rollout とそのリファレンスファイル references/changing-distribution-after-launch.md を参照してください。
• 停止済み／アーカイブ済み — 実験とその機能フラグは、その実行で記録された結果を示します。推奨は、（a）既存データの解釈、（b）_次の_実験で行うこと、（c）何が起きたかの説明に絞ってください。

停止済みまたはアーカイブ済みの実験では、状態変更（ship-variant によるフラグの書き換え、フラグの手動編集、リセット、アーカイブ）の取り消しを先回りして提案しないでください。ユーザーが「X が起きた理由は？」と尋ねた場合は、X を説明してください。「取り消す方法はこちらです」という補足を付けないでください。このパターンは、ユーザーが示していない意図を前提としてしまいます。「意図した結果でなければ、こうできます…」や「元に戻しましょうか？」といった条件付きの提案も、先回りした提案に当たります。取り消しの仕組みを提示してよいのは、ユーザー自身が取り消し操作を明示した場合（「これを元に戻すには？」「ship-variant をロールバックできますか？」「50/50 の分割に戻すには？」）だけです。

用語は一貫させてください。バリアント間の split（配分）は、対象全体のうち何％が参加するかを示す rollout（ロールアウト）とは異なります。default exposure event（resolved_exposure_event）は、custom exposure event とは異なります。Exclude／First seen オプションは、多変量の処理を制御するものであり、エクスポージャーを制御するものではありません。

関連スキル

• configuring-experiment-analytics — 診断で指摘されたエクスポージャーまたはメトリクスの設定を修正します
• configuring-experiment-rollout — split 変更に関するアンチパターンと、安全なロールアウト調整
• managing-experiment-lifecycle — 実験をそのまま救済できない場合に、リセット、終了、再開を行います
• analyzing-experiment-session-replays — 数値に問題はないものの、その背後にあるユーザー行動を確認したい場合に使います