実験モニター＆レポート生成ツール
アクティブおよび最近完了した実験をスキャンし、注意が必要なものを特定し、重要な実験についてレポートします。
これはモニタリングスキルです。非専門家でも理解できるように出力してください。統計用語（p値、検出力分析など）は避けてください。特定の実験の詳細分析には、analyze-experimentsスキルを使用してください。
重要：レスポンスサイズの管理
get_experiments: 1回の呼び出しで最大3～5件のID。事前にsearch結果でフィルタリングしてから取得してください。query_experimentのレスポンスは大きい。summaryオブジェクトと有効性フラグのみ抽出してください。timeseries、xValues、大きな配列は無視してください。- メトリック名の解決: 通常の
searchではqueries内のメトリックIDは一致しません。entityTypes: ["METRIC"]、空のqueries、limitPerQuery: 50、プロジェクトスコープで検索してください。結果からIDと名前をマッピングしてください。
レポート構成
レポートは2つの部分で構成されます。
- サマリーとアクション（上部） — 1つのテーブル＋アクションアイテム。これだけ読めば全体像がわかるようにします。
- 詳細（下部） — 注意が必要な実験の詳細分析、最近決定された実験の概要、モニタリング中の実験の一言メモ、セットアップが必要なリスト。
サマリーテーブルと詳細の間で情報を重複させないでください。サマリーテーブルはポートフォリオ状態の単一の信頼できる情報源です。詳細は特定の実験について補足します。
指示
ステップ1：コンテキストと発見
Amplitude:get_contextを呼び出します。複数のプロジェクトがある場合は、どのプロジェクトをモニタリングするか尋ねます。- 実験を検索します。
Amplitude:search({
entityTypes: ["EXPERIMENT"],
appIds: [projectId],
queries: [],
sortOrder: "lastModified",
sortDirection: "DESC",
limitPerQuery: 50
})
- フィルタリングルール — 以下の実験を含めます
- 実行中で最新のもの（スケールではない）: 実行中であり、スケールとマークされていない実験。スケール実験はアイドル状態であり、除外する必要があります。
- 最近決定されたもの: 完了し、決定が記録されており、過去14日以内に変更された実験。これらのレビューは、決定を確認したり、学びを共有したりする価値があります。
- 除外: ドラフト、無効な実験、スケール実験。
ステップ2：メタデータ、メトリック名、主要結果の取得
Amplitude:get_experimentsを3～5件のIDのバッチで呼び出します（ステップ1でフィルタリングされたセットのみ）。- 状態、日付/期間、バリアント、メトリックID（推奨=trueのプライマリ）、決定、所有者を抽出します。
- 詳細なメタデータを使用して、ステップ1のフィルタリングルールを再度適用します（一部のフィールド（スケールステータスや決定など）はここでのみ利用可能な場合があります）。
Amplitude:search({ entityTypes: ["METRIC"], appIds: [projectId], queries: [], limitPerQuery: 50 })を使用してメトリック名を解決します。{ id: name }のマッピングを作成します。- メトリックが設定されている実験については、
Amplitude:query_experiment({ id: "<id>" })（metricIdsなし）を呼び出して、プライマリメトリック結果とデータ品質フラグを取得します。このデータはサマリーテーブルと詳細分析の両方に使用されます。
重要: メトリックの生のIDをユーザーに表示しないでください。 メトリック名が解決できない場合は、その役割（例：「プライマリメトリック」「ガードレールメトリック」）で説明してください。「rrgtky08」や「Metric gvgb5efj」のような文字列は表示しないでください。メトリックIDは人間にとって意味のない内部識別子です。
ステップ3：サマリーとアクション
これはレポートの上部です。自己完結している必要があります — このセクションのみを読む人が全体像を把握できるようにします。
サマリーテーブル
## 実験モニター: [プロジェクト名]
日付: [今日] | プロジェクト: [名前] ([ID])
| 実験 | 状態 | 期間 | リフト | 判定 |
|------------|-------|----------|------|---------|
列の定義:
- 実験 — 人間が読める名前（URLやIDではない）
- 状態 — 実行中または完了
- 期間 — 実験開始からの日数
- リフト — 利用可能な場合はプライマリメトリックの相対リフト、データがない場合は「—」。マルチバリアントの場合は範囲を表示（例：「-17%から-20%」）
- 判定 — 実行すべきアクション（以下の語彙を参照）
判定語彙:
| 判定 | 使用タイミング |
|---|---|
| Ship | 有意な正のプライマリ、ガードレールクリア、データ品質良好 |
| Iterate | 正のシグナルだがガードレールに問題あり、または品質懸念 |
| Monitor | 実行中、まだ有意でない、アクション不要 |
| Abandon | 有意な負のプライマリ、または重大なデータ品質問題 |
| Decided: Ship | 最近完了し、チームがShipを決定 |
| Decided: Don't ship | 最近完了し、チームがShipしないことを決定 |
| Fix config | クエリエラー、エクスポージャーイベントの破損、または深刻なトラフィック不均衡 |
| Needs metrics | メトリックなしで実行中 — 評価できない |
| N/A | サーベイ/ナッジのデプロイ、機能実験ではない |
アクションアイテム（テーブルの直後）
**今すぐ対応:**
- [実験] — [所有者名を含む具体的なアクション]
**ウォッチ継続:**
- [実験] — [簡単なステータス＋次回確認するタイミング]
**セットアップが必要:**
- [実験] — [不足しているもの＋所有者名]
テーブル内のすべての実験は、ちょうど1つのアクションカテゴリに表示される必要があります。該当する実験がないカテゴリは省略してください。
ステップ4：詳細
サマリーの下に、セクションごとに整理された追加の詳細を提供します。各実験は1つのセクションにのみ表示されます — 重複は禁止です。
4a: 詳細分析（注意が必要な実験）
Ship、Iterate、Abandonの判定が下された実験（最大3件）の詳細分析を行います。これらは調査する価値のある有意な結果を持つものです。
各実験について、以下の完全なレポートを一度に出力します。
---
## [実験名]
[状態] | [期間]d | コントロール: [N] / トリートメント: [N] | [実験へのリンク]
データ品質（最初に — 結果の前に）:
メトリック結果を報告する前にデータ品質を確認してください。重大な問題がある場合、読者は結果を解釈する前にそのコンテキストを必要とします。
すべて合格の場合、1行で「データ品質チェック：すべて合格。」と表示し、プライマリメトリックに進みます。
問題が見つかった場合は、プライマリメトリックの前に報告します。
### データ品質: [N件の問題を検出]
SRM（サンプル比率ミスマッチ）:
- APIレスポンスの
srmDetectedフィールドを使用 srmDetected: trueの場合: 常に最初に、目立つように報告- 実際の分割と期待される分割を特定のパーセンテージで報告
トラフィック割り当ての変更:
- 現在のバリアントウェイトを累積エクスポージャー分布と比較
- 一致しない場合（例：現在のウェイトが100/0/0だが累積が15/70/15）、実験途中で割り当てが変更されたことを意味する
- これを目立つようにフラグする — 一部のバリアントが新しいトラフィックを受信しなくなっている可能性がある
サンプルサイズ:
- 各バリアント100未満: 不十分としてフラグ — 結論を出すには早すぎる
- 各バリアント100～1,000: 方向性のあるシグナルのみ、確信を持って判断するには不十分
- 1,000以上: 分析に十分
有効性フラグ — 失敗のみ報告:
| フラグ | 失敗時の意味 | 重大度 |
|---|---|---|
isVariancePositive = false | メトリックデータが無効 — 統計テストを実行できない | 重大 |
isConfidenceIntervalNotFlipped = false | 結果の計算エラー — 数値を信頼しないでください | 重大 |
isMeanValid = false | メトリック値が壊れている（NaN/無限大） — 分析不可 | 重大 |
statsAssumptionsMetForWholeExperiment = false | 統計的前提が満たされていない — 結果が信頼できない可能性がある | 高 |
hasSuspiciousUplift = true | 異常に大きな効果 — 測定誤差の可能性があり、実際の変化ではない可能性がある | 高 |
isPointEstimateInsideConfidenceInterval = false | 内部計算の不整合 — 結果が間違っている可能性がある | 高 |
isStandardErrorLargeEnough = false | 信頼できる推定値を得るにはノイズが多すぎる | 中 |
SRMが検出された場合、または重大なフラグが失敗した場合:
⚠️ 以下の結果は、[問題]のため注意して解釈する必要があります。
プライマリメトリック:
### [メトリック名]: [平易な言葉での判定]
| バリアント | 値 | リフト | 95%信頼区間 |
|---------|-------|------|--------|
| コントロール | [X] | — | — |
| トリートメント | [Y] | [+Z%] | [A%からB%] |
[平易な言葉での解釈を一文。]
フレーミングルール:
- p値を含めないでください。 非専門家はその意味を理解していません。
- 「効果なし」ではなく「有意ではない」を使用してください。効果がある可能性があります — 実験がこのサンプルサイズでそれを検出できないだけです。
- 何が起こったかを平易な言葉で説明してください。
判定の言葉:
- 有意な正 — 信頼区間が完全にゼロより上、正のリフト
- 有意な負 — 信頼区間が完全にゼロより下、負のリフト
- 有意ではない — 信頼区間にゼロが含まれる; まだ確信を持って真の差があるとは言えない
- 正/負の傾向 — 方向性のあるシグナルだが信頼区間にゼロが含まれる; ウォッチに値する
リフトが非常に小さい（<2%）または非常に大きい（>20%）場合にのみ、実務上の有意性について一文追加します。
ガードレールとセカンダリメトリック:
Amplitude:query_experiment({ id: "<id>", metricIds: [...] }) を呼び出します。
すべてのメトリックを説明するのではなく、回帰の検出に焦点を当てます。
有意な回帰がない場合:「すべてのガードレールとセカンダリメトリックはクリーンです — 検出された有意な回帰はありません。」
有意な回帰が見つかった場合:
- **[メトリック名]:** 有意な回帰（[−X%]、CI: [A%からB%]） — [影響について一文]
まだ有意ではないが、大きな方向性のある回帰（相対リフト>20%）がある場合:
- **[メトリック名]:** 有意ではないが、方向性としては負（[−X%]） — ウォッチに値する
有意ではない小さな方向性の変化は省略してください。5つ以上のメトリックがある場合は、多重比較により偽陽性の確率が高まることに注意してください。
フィードバック（プライマリが有意な場合のみ）:
Amplitude:get_feedback_insights を実験関連のキーワードで呼び出します。2〜3のテーマをそれぞれ一行で報告します。関連するフィードバックがない場合は、このセクションをスキップします。
判定:
### 判定: [SHIP / ITERATE / MONITOR / ABANDON]
1. [プライマリメトリックの所見 — 一文]
2. [品質 / ガードレールステータス — 一文]
3. [次に何をすべきか — 一文]
判定マトリックス（内部参照用、出力しない）:
| シグナル | Ship | Iterate | Monitor | Abandon |
|---|---|---|---|---|
| プライマリ | 有意な正＋実務的 | 有意な正だがガードレールに回帰 | まだ有意でない、実行中 | 有意な負 |
| 品質 | すべて合格 | 軽微なフラグ | すべて合格またはデータ不足 | SRMまたは重大なフラグ |
| ガードレール | クリーン | 1つの回帰、修正が必要 | クリーンまたはデータ不足 | 重要なメトリックの有意な回帰 |
| 実験状態 | 完了 | 完了 | 実行中 | 完了または実行中 |
4b: 実行中の実験（モニタリング、アクション不要）
Monitor判定の実験については、それぞれ1行のステータスを提供します。
---
### 実行中の実験
**[名前]** — 実行中[X]d、コントロール: [N] / トリートメント: [N]。 [プライマリメトリックステータス — 例：「正の傾向（+3.3%）だがまだ有意ではない」]。データ品質クリーン。[リンク]
**[名前]** — 実行中[X]d、コントロール: [N] / トリートメント: [N]。結論を出すには早すぎる — [理由、例：「サンプルサイズが100-1,000の範囲」]。[リンク]
簡潔に — 実験ごとに1行。Amplitudeで確認したい人のために、最後にリンクを含めます。
4c: 最近決定されたもの（簡単な概要）
Decided: ShipまたはDecided: Don't shipの判定の実験の場合:
---
### 最近決定されたもの
- **[名前]** — [日付]に[出荷/ロールバック]、[X]日後。[結果または根拠について一文]。[リンク]
メトリックなし、または統計的有意性なしで出荷された場合は、そのことを簡単に記します。
4d: セットアップが必要
Fix config、Needs metrics、またはN/Aの判定の実験の場合:
---
### セットアップが必要
- **[名前]** — [問題の説明]。所有者: [所有者名]。
- **[名前]** — サーベイ/ナッジのデプロイ、機能実験ではありません。分析は不要です。
各実験は、ちょうど1つの詳細セクションに表示されます。サマリーテーブルのアクションと詳細セクションの両方に同じ情報で実験をリストしないでください。詳細セクションはアクションアイテムを補足するものであり、繰り返すものではありません。
エッジケース
- 実験がない場合: 明確に報告し、他のプロジェクトを確認することを提案する
- データがない（<24時間）: 実験が開始されたばかりであることを記し、7日後に再確認するよう提案する
- SRMが検出された場合: データ品質でこれを最初に挙げる — 他のすべてを無効にする可能性がある
- 10以上の実験がある場合: すべてのサマリーテーブルを作成し、上位3件を詳細分析し、さらに分析することを提案する
- レスポンスが大きすぎる/ディスクに保存された場合:
summary＋有効性フラグのみ抽出する - メトリックが設定されていない場合: 「セットアップが必要」セクションにリストし、詳細分析は行わない
- すべての実験がスケールの場合: モニタリングするアクティブな実験がないことを報告する
query_experimentからのクエリエラー: 実験所有者の名前とともにエラーを明確に報告する。サマリーで「Fix config」としてフラグする。一般的な原因: エクスポージャーイベントプロパティの破損、実験キーの設定ミス。- 実験途中でトラフィック割り当てが変更された場合: データ品質でフラグする。現在のウェイトを累積エクスポージャー分布と比較する。どのバリアントがトラフィックを受信しなくなったかを記す。
- サーベイ/ナッジ実験（NPSなど）: サマリーでN/Aとして記す。分析は不要 — 詳細分析はスキップ。
- 深刻に不均衡なトラフィック（例：5%/95%または0%/100%）: 「Fix config」としてフラグする — 意味のあるコントロールグループなしでは有効な実験を実行できない。所有者とともにセットアップが必要セクションに記す。