ae-experiment-design

AE 実験の設計と統合

ビジネス目標を、根拠に基づく実験設計、実装契約、そして依頼があり、かつ対応可能な場合は AE 実験ドラフトへと変換します。

厳守事項

• AE プラットフォームとのすべてのやり取りには ae-cli を使用してください。生の HTTP、ブラウザー自動化、データベースへの直接クエリ、アプリケーション SDK で代用しないでください。
• 実験に実装が必要だからといって、SDK リクエストを推測しないでください。A/B 実験 SDK またはクライアント SDK の統合についてユーザーから明示的に依頼された場合に限り、SDK リファレンスを読み込んでください。
• 一般的なトラッキング SDK のドキュメントをこの Skill にコピーしないでください。この Skill が利用可能な場合、一般的な初期化、イベント報告、track、ユーザー ID、ユーザープロパティ、データアップロード、LogBus、REST に関する質問は ae-data-integration-helper に案内してください。
• metric-readiness.md で定義されたイベント指標の計算契約のみを使用してください。確認済みの主要イベント指標を1つ設定し、未対応の指標ロールを追加しないでください。
• ae-cli から成功応答がない限り、プラットフォームアセットが存在する、作成された、チェックに合格した、またはプロジェクトコードが生成されたと主張しないでください。
• プラットフォーム ID、スキーマ、SDK API、バージョン、デフォルト、動作を捏造しないでください。

段階的開示ルーター

現在の依頼に必要なリファレンスのみを読み込んでください。

依頼	必須リファレンス
AE プラットフォームの読み取りまたは書き込み全般	references/platform-operations.md
実験ドラフトの作成または再利用	references/experiment-creation.md と references/platform-operations.md
指標の選択、実現可能性、または作成	references/metric-readiness.md
A/B 実験 SDK またはクライアント SDK の統合についての明示的な依頼	references/sdk-integration.md
SDK の正確なバージョン、依存関係、クラス、ソースの検索	references/sdk-index.md
プラットフォーム間での Feature、デフォルト、フェッチ、キャッシュ、または割り当ての動作	references/experiment-sdk-contract.md
Android、iOS、または JavaScript の実験 SDK	references/client-experiment-sdk.md
サーバーサイドの割り当てまたは評価	references/server-experiment-sdk.md
クライアント側のレンダリングを伴うサーバー割り当て	references/hybrid-experiment-sdk.md
曝露設計、重複排除、または指標の結合	references/exposure-contract.md
SDK の取得、デフォルト、ID、曝露、またはデバッグの問題	references/sdk-troubleshooting.md

リファレンスは厳選された近道であり、ドキュメント一式のすべてではありません。

ワークフロー

1. 意思決定の枠組みを定める

以下を抽出します。

• ビジネス目標と望ましい方向性
• 実験変数とユーザーから見える変更
• 対象ユーザーと除外条件
• 結果によって裏付ける必要がある意思決定
• 成功のしきい値

これらを反証可能な仮説に変換します。設計に実質的な影響を与える不足情報のみを確認してください。コンバージョン目標の場合は、対象ユーザー、分母または曝露の動作、分子の動作、アトリビューション期間、分析単位を確定してください。

対象ユーザー、コンバージョンの定義、技術プラットフォームを暗黙に捏造しないでください。

2. プロジェクトとエビデンスを確認する

platform-operations.md のプロジェクトゲートを通過してください。ae-cli を使用して、候補となる曝露イベントと成果イベント、割り当て ID と結合経路、タイムスタンプ、保存済み指標の正確な定義、そして利用可能な場合はベースラインと対象トラフィックを確認します。

プロジェクトを利用できない場合は、ユーザー提供のスキーマまたは定義を受け入れ、プラットフォームに依存する結論には未検証のラベルを付けてください。

3. 指標の準備状況を評価する

metric-readiness.md を適用します。候補を recommended、available、 blocked、unverified に分類し、主要イベント指標を1つ推奨して、サンプルサイズや期間を計画する前にその計算コードを確認します。

4. Feature、割り当て、グループを設計する

Feature キー、型、型付きデフォルト値、オーナーシップ、安定した割り当て単位、1つのコントロールグループ、処理グループ、グループ値、トラフィック、割り当て率、レイヤー、ターゲティング、除外を定義します。

割り当て率の合計が 1.0 であること、実験トラフィックが (0, 1] であること、値が型に適合していること、露出と成果の間で安定した ID 結合が可能であること、主要指標が少なくとも1つあることを必須とします。再利用または作成する前に、ae-cli で実際の Feature とレイヤーを確認します。

5. サンプルサイズと期間を計算する

次の順序に従います。主要指標と計算コードを確認する → ベースライン、MDE、必要な分散を取得する → scripts/calculate_experiment_plan.py でサンプル目標を計算する → サンプル目標と、実際に対象となる1日あたりのユニット数から期間を算出する。 metric-readiness.md に定められた事前登録済みの計画ポリシーを適用します。alpha=0.05 と両側検定を固定で使用し、power=0.80 をポリシーのデフォルトとし、複数の処理群がある場合は Bonferroni 法で計画します。MDE の種類と方向を必須とし、MDE を 5% にデフォルト設定したり、連続指標の分散を仮定したりしてはいけません。

実験トラフィックがすでに確認されている場合は、そのトラフィックでの期間を計算します。未確認の場合は、検証済みのレイヤー容量を取得し、最大実行期間内に目標を達成できる最小の絶対トラフィック候補をスクリプトで推奨します。デフォルトでは7日間以上とし、週単位に合わせます。実行不可能な場合は、期間を切り詰めずに実際の期間を返します。ベースライン、MDE、検出力の根拠、割り当て率、多重性のルール、トラフィックの根拠、サンプル目標、期間の調整、およびネイティブレポートとの不一致があればその内容を説明します。必要な根拠が得られない場合は、確定的な計画を返してはいけません。

6. 設計を具体化する

明示的な下書き作成の依頼がある場合は、experiment-creation.md と platform-operations.md に従います。許可された下書きアセットのみを作成し、保存した結果を読み戻して検証し、対応している準備状況と競合のチェックを実行して、そこで定義された簡潔なレシートと実験リンクを返します。

送信、開始、稼働中のトラフィック変更、一時停止、終了、削除には、個別の明示的な確認が必要です。下書きの作成をローンチに変えてはいけません。

出力要件

• ユーザーが明示的に指定した言語を使用します。指定がない場合は、ユーザーの直近の実質的なメッセージの言語を使用します。
• 見出し、表のヘッダー、フィールドラベル、ステータス名、推奨事項、警告、前提、次のアクションなど、ユーザーに表示される文章をすべてローカライズします。
• コード、コマンド、生の ID、イベント／プロパティ／メトリクス名、Feature キー、SDK／API 名、公式の列挙値は、翻訳によって技術的な意味が変わる場合は変更しません。
• この Skill 内のセクション名は意味上の指針として扱い、出力にそのまま使う見出しではありません。英語の見出しを英語以外の回答にコピーしないでください。
• デザインの依頼では、実験の推奨案を最初に示します。作成、検証、競合チェックの依頼では、処理結果を最初に示します。
• 関連する最小限のセクションのみを含めます。ワークフローの全段階を再掲しないでください。
• 観測されたプラットフォームのエビデンス、検証済みのドキュメント、確定的な計算、デザイン上の判断、未解決の前提を区別します。
• 回答の前に、すべての見出し、表のヘッダー、ラベル、ステータスを確認し、意図しない言語の混在がないことを確かめます。

プロジェクトの解決、メタデータの検出、候補イベントの検索、メトリクスの比較、Feature とレイヤーの一覧確認、機能の検出、スキーマの検査、コマンドの実行は、内部の作業コンテキストとして扱います。

• 最終回答で処理の実行手順を説明しないでください。「最初にリファレンスを読み込む」「次に並行してクエリを実行する」「ae-cli で検証した」「エビデンスの収集が完了した」などの表現は省略してください。
• ユーザーがエビデンス、監査証跡、またはデバッグの詳細を明示的に求めない限り、生のコマンド、機能 ID、リクエストスキーマ、候補の全リスト、プラットフォームのエビデンスをそのまま羅列したものは開示しないでください。
• プラットフォームのエビデンスは、デザインを左右する場合、処理を妨げる場合、重要な意味の不一致を明らかにする場合、またはユーザーの確認が必要な場合にのみ提示します。通常は、簡潔な箇条書き 3 点以内で要約してください。
• 作成依頼の後に実験デザイン全体を再掲しないでください。ただし、ユーザーが全体のデザインを明示的に求めた場合を除きます。
• 非公開の推論は開示しないでください。結論、ユーザーに関係する根拠、処理結果を伝えてください。

失敗時の動作

• プロジェクトが見つからない場合、またはホストが曖昧な場合：候補を提示して確認し、推測しないでください。
• メタデータが不足している場合：必須のイベント、プロパティ、ID、タイムスタンプのチェックリストを返してください。
• 実験プロダクトを利用できない場合：
  • 明示的なプラットフォームの権限付与結果によって事実が確認できた場合に限り、プロジェクトで実験プロダクトが有効になっていないと伝えてください。機能が利用できないだけの場合は、実験機能が利用できないことを意味するにすぎず、プロダクトが購入されていないことを意味するわけではありません。
  • デザインの依頼では、実験の設計は続行できますが、Feature、レイヤー、指標、トラフィックの詳細はプラットフォーム上で検証できないと伝えてください。オフラインで設計を続け、サンプルサイズや期間の計画に必要な場合は、ベースライン、MDE、適格な1日あたりのユニット数を尋ねてください。
  • ドラフト作成の依頼では、実験ドラフトが作成されなかったという結果を最初に伝えてください。Feature、レイヤー、ドラフトの作成がブロックされていることを説明し、提案した設計を保持したうえで、プロダクトが有効になるか必要なアクセス権が付与された後に、プラットフォーム上での作成と準備状況の確認を続行できると伝えてください。
• HTTP 403、または同等の権限拒否の場合：現在のアカウントに必要な実験権限がないと伝え、依存する書き込み処理を停止してください。また、この結果からプロジェクトが実験プロダクトを購入しているかどうかは判断できないと説明してください。プロジェクト管理者に、プロダクトの利用可否とユーザーのプロジェクト権限の両方を確認するよう依頼してください。
• 明示的な権限付与または権限の結果がない状態で機能が不足している場合：現在の環境では必要な実験機能を利用できないと報告し、有用な場合はオフラインでの設計を続け、ae-cli を迂回しないでください。
• SDK の不足や競合については、sdk-integration.md に従い、正確なコードを捏造しないでください。
• 検証に失敗した場合：文書化された入力を修正するか、不足している値を尋ねてください。変更していない入力で再試行しないでください。
• 一部のみ成功した場合：作成されたアセットと失敗したアセットを分けて報告し、すべてが一括で成功したかのように伝えないでください。