agent-observability-online-experiment

LLM アプリケーションでオンライン実験を設定する

オンライン実験では、実際のトラフィックをコントロール版とトリートメント版のLLMアプリケーションに振り分けます。Datadogのフィーチャーフラグによって各対象ユーザーにバリアントが割り当てられ、Agent Observabilityの評価スコア（およびコストとトークン使用量）によって結果を測定します。このスキルでは、フラグの設定から実験の開始まで、セットアップ全体を順を追って説明します。

Agent Observabilityのオンライン実験を利用するには、ユーザーの組織でこの機能を有効にする必要がある場合があります。どの手順であっても機能が利用できないというメッセージが表示された場合は、再試行せず、Datadogの担当者に連絡するようユーザーに伝えてください。

このスキルを使用する場合

• ユーザーが、固定データセットではなく実際のトラフィックで変更（プロンプト、モデル、検索戦略、ツールセット）をテストしたい場合。
• ユーザーがブランチ上で変更を行っており、本番環境でそれがより良いか、より安価か、またはその両方かを知りたい場合。
• ユーザーが、Agent Observabilityの評価、トークン数、またはコストからメトリクスを取得する実験を希望する場合。

データセットを使ったオフライン実験には使用しないでください（LLM Observabilityの実験ツールを使用してください）。すでに実行済みの実験の分析には使用しないでください（agent-observability-experiment-analyzerまたはDatadogの実験ツールを使用してください）。既存のオフライン実験を昇格させる場合にも使用しないでください。

基本ルール

• セットアップの承認確認は1回だけ行います。 書き込みを行う前に、Phase 0で読み取り専用の調査をすべて完了し、妥当な提案を作成したうえで、提案するセットアップ全体を1回の確認依頼で提示してください。フラグ、バリアント、メトリクスの定義または再利用するメトリクスID、望ましい変化の方向、環境、対象ユーザー、トラフィックの分割、コード変更、実行予定の組織への書き込みをすべて含めてください。ユーザーがその提案を承認した後は、明確に記載済みのフラグ、ドラフト、リンク、メトリクス、有効化、割り当ての各書き込みを行う前に、再度確認を求めないでください。
• 同じ確認時に、本番環境へのリスクを明示します。 提案によって本番環境のフラグが有効になる場合、または本番環境の割り当てが置き換わる場合は、変更が直ちに反映されることを伝えてください。本番環境への変更を含む提案への明確な承認があれば十分です。同じ情報を繰り返す2回目の確認を追加しないでください。読み戻しによって、承認済みの提案に含まれていない重大な相違または破壊的な置き換えが判明した場合に限り、再度確認を求めてください。
• 開始は、明示されていない限り別の手順です。 ユーザーが実験の開始を明示的に依頼した場合に限り、開始してください。元の依頼に開始が含まれている場合は、1回のセットアップ提案に開始も含めてください。そうでない場合は、ドラフトを作成して終了し、ユーザーから依頼があるまで開始について質問しないでください。
• 一度に1つずつ進め、読み戻して確認します。 書き込みのたびに対象オブジェクトを読み戻し、送信した内容ではなく、サーバーに実際に保存された内容を報告してください。
• メトリクスのアタッチは、他のメトリクス編集と並行して、または同時に行わないでください。 アタッチ操作は実験のメトリクスセット全体をサーバーに送信するため、並行する編集が互いの変更を上書きする可能性があります。
• 失敗は明確に報告します。 手順が拒否された場合（権限、本番環境の制限など）は、その旨を伝え、ユーザーに手動で行う方法を示してください。回避策を探してはいけません。
• 識別子を推測しないでください。 環境ID、フラグID、メトリクスID、バリアントキーはすべてサーバーから取得してください。

フェーズ 0 — 調査し、提案して、一度だけ確認する

入力を一つずつ尋ねて調査を中断しないでください。まず、利用可能な読み取り専用の調査をすべて実施します。

• アクティブなツール一覧を確認し、このワークフローに必要な llmobs、experiments、feature-flags の各機能がセッションで利用できることを確認します。必要な機能は、環境の検出、フラグの検索・作成・有効化・割り当て管理、実験の検索・作成・リンク・開始、実験指標の検索・作成・アタッチです。スキルのツールセット設定では OR セマンティクスによって表示が制御されますが、3 つすべてのツールセットが有効になるとは限りません。機能が不足している場合は、不足しているグループと有効にすべきツールセットをすべて報告し、個別の操作を何度も再試行せず、書き込みを行う前に停止します。
• アプリケーションとそのデプロイ設定を調べます。Agent Observability にレポートしていることを確認し、評価を送信する箇所（送信する場合）を特定し、トリートメントによって変わるコードパスを見つけて、ml_app、DD_ENV、安定した被験者識別子を推定します。
• 環境を一覧表示し、提案された変更に対する既存のフラグと実験を確認します。また、新しいオブジェクトを提案する前に、既存の実験指標を検索します。

次に、提案内容を確定します。コンテキストから推定し、妥当な場合は以下のデフォルトを使用します。

入力	補足
アプリケーションとその ML アプリ名	アプリケーションが Agent Observability に報告する ml_app です。
コントロールとトリートメント	両者の違いです。通常、コントロールは現在のコードパスで、トリートメントはテスト対象の変更です。
仮説	品質、トークン数、またはコストに対する予想される仕組みと効果を、1〜2 文で記述します。
スコア指標	関連性が最も高い既存の数値評価スコアと、その望ましい変化の方向を提案します。フェーズ 4 を参照してください。
環境	デプロイ設定と、ユーザーのライブトラフィックに関する目標から推定します。実験がリンクできる環境は 1 つだけです。
トラフィックの分割	デフォルトはコントロール／トリートメントを 50/50 にします。
フラグ名	デフォルトでは、短くわかりやすいケバブケースの名前を使用します。
被験者	何を 1 つの被験者とみなすかです。フェーズ 2 を参照してください。

指標名の検索が必要な場合、指標が存在しないと結論づける前に、スペース、ハイフン、アンダースコア、意味のある部分文字列など、名前のバリエーションを試します。名前だけで選ばず、重複する定義を調べます。ソース、列、フィルター、集計、望ましい変化の方向が提案内容と一致する場合に限り、アクティブな実験ですでに使用されている定義を優先します。指標名から ML アプリのスコープを推定してはいけません。ユーザーが希望する既存の指標に ML アプリのフィルターがない場合、または推奨する定義と異なる場合は、その点を提案で明示し、再利用するか置き換えるかを推奨します。

以下を含む、簡潔な確認依頼を 1 つ提示します。

• アプリケーションと ml_app。
• コントロール、トリートメント、仮説。
• 提案するフラグキーと Boolean バリアント。
• 被験者識別子と、フラグを評価するコードの場所。
• 対象環境と 50/50 または提案する分割比率。
• 主評価指標、保存済みまたは提案する定義、望ましい変化の方向。
• トークン数とコストの副次指標。
• 既存のオブジェクトを再利用するか、新規作成するか。
• 本番環境での有効化／割り当てが該当する場合は、それを含む書き込みの完全な一覧。
• 開始処理が含まれるかどうか（ユーザーがすでに開始を依頼している場合のみ）。

最後は、次の質問で締めくくります。この設定全体を確認しますか。それとも、変更点をお知らせください。 コード、サーバーの状態、安全なデフォルトから解決できない、本当に作業を妨げる曖昧さがある場合に限り、追加の質問をしてください。

フェーズ 1 — フィーチャーフラグを作成する

2 つのバリアントを持つ Boolean フラグを作成します。control = false、treatment = true とし、デフォルトのバリアントは control にします。

• フラグを作成する際に、割り当て、ターゲティングルール、またはパーセンテージロールアウトを追加しないでください。実験にリンクしても、それだけでは割り当ては作成されません。リンク後、フェーズ 5 で実験にリンクされた FEATURE_GATE 割り当てを 1 つ作成するか更新してください。余分なルールは分割に影響します。
• まず、そのキーのフラグがすでに存在するかどうかを確認し、ユーザーが再利用するよう指示した場合は再利用してください。
• 組織にフィーチャーフラグが 1 つもない場合、サーバーが初回セットアップ向けのガイド付きオンボーディングフローを案内することがあります。ユーザーが特定のフラグを指定している場合は、ここでは直接作成して問題ありません。ユーザーが Datadog Feature Flags を初めて使うようであれば、その場合に限りオンボーディングフローについて説明してください。
• フラグの ID と 2 つのバリアントの ID を記録してください。

環境を一覧表示すると、利用可能な環境（通常は Production、Staging、Development）がわかります。どれが本番環境かを確認してください。本番環境での一部の操作はサーバーから実行できず、Datadog の UI で行う必要があります。

フェーズ 2 — アプリケーションを接続する

アプリケーションでは、すべての対象について次の 3 つを行う必要があります。フラグを評価し、一致する動作を実行し、同じ対象識別子の下でスコアとスパンを報告します。

対象識別子を選びます。 測定対象となるやり取り全体を通じて、安定した値である必要があります。

• サインイン済みユーザーがいるアプリケーション：安定したユーザー ID。
• ユーザーはいないがセッションがある場合：セッション ID。
• 自律型ワークフロー：実行の開始時に UUID を 1 つ生成し、実行全体で再利用します。

次の 3 か所で同じ値を使用します。フィーチャーフラグ評価コンテキストの targetingKey、評価スコアの subject_identifier タグ（Datadog のオンライン実験ガイドで必要とされる結合キー）、および各トレースのルートスパンの subject_identifier タグ（コストとトークンのメトリクスが読み取るタグ）です。これらの値が異なると、Datadog はフラグへの露出と結果を結合できず、実験のメトリクスデータが欠落します。

フラグを評価します。 アプリケーションの言語に対応した Feature Flags SDK に従ってください。Python の場合は、最近の ddtrace と OpenFeature SDK を使用し、Datadog プロバイダーを 1 回登録して、targeting_key に対象識別子を設定した Boolean フラグを評価します。SDK には Datadog API キー、サイト、および DD_ENV を設定する必要があります。評価のデフォルト値は false（コントロール）にし、エラーを捕捉して、フラグが停止した場合もアプリケーションを中断せずコントロールにフォールバックするようにします。

フィーチャーフラグの管理ガイダンスでは、アプリケーションの言語に関係なく React 統合リソースが案内されることがあります。これは汎用的なツールのガイダンスとして扱い、React コードを追加する指示とは見なさないでください。アプリケーションの実際の言語に対応した SDK に従い、リポジトリ内に既存の動作するプロバイダー／評価パターンがあれば、そちらを優先してください。

バリアントを適用する場所を選びます。 会話オブジェクトに保存されたシステムプロンプトなど、状態に動作が組み込まれて、その状態が永続化される場合は、呼び出しごとではなく、その状態の作成時にフラグを 1 回評価します。これにより、対象がやり取りの途中でバリアントを切り替えることを防げます。可能であれば、コード内でコントロールからトリートメントを導出し、両者の不一致を防いでください。

スコアを報告します。 Agent Observability SDK でスコア評価を送信し、そのタグに subject_identifier を追加します。実験メトリクスにできるのは、数値の score メトリクスタイプを持つ評価のみです。Boolean、カテゴリ型など、その他のタイプは使用できません。

スパンと評価にタグを付けます。 アプリケーション独自のコードで、Agent Observability のスパンと評価スコアに subject_identifier タグ（例：subject_identifier:73b2efe1-03e3-40c1-ab6a-bd2a6cfbc865）を追加します。Datadog は取り込み時にこのタグをイベントの @usr.id フィールドに変換します。実験では、このフィールドを使ってフラグへの露出と結果を結合します。@usr.id ではなくタグを設定してください。SDK はこのフィールドを直接設定せず、変換は Datadog のバックエンドで行われます。

コストとトークンのメトリクスは、完了した各ルートトレースの集計値を読み取るため、タグはトレースのルートスパン、つまり最外層のワークフローまたはエージェントのスパンに付ける必要があります。SDK のスパン注釈呼び出しを使用して、このスパンに注釈を付けてください。スパン単位のマネージド評価器では、結果の対象識別子が評価対象のスパン自身のタグから決まるため、その評価器がスコアを付けるすべてのスパンにも同じタグを追加します。トレース単位のマネージド評価器では、ルートスパンの対象識別子を結果に引き継げます。評価対象の子スパンにタグを付けても、コストやトークンが二重計上されることはありません。これらのメトリクスは引き続きルートトレースのみを測定するためです。

実験でデータを収集するには、コードをデプロイする必要があります。デプロイ前でもフラグ、割り当て、実験を作成できますが、アプリケーションがリンク先の環境でフラグを評価するまでは何も記録されないこと、およびアプリケーションの DD_ENV がその環境と一致している必要があることを、ユーザーにはっきり伝えてください。

フェーズ 3 — 実験を作成してフラグをリンクする

1. 明確な名前と仮説を設定して、実験の下書きを作成します。主指標は後から追加できるため、指標が存在する前に下書きを作成しても問題ありません。
2. フェーズ 1 のフラグを実験にリンクします。
3. 実験の情報を読み戻します。下書きは開始されるまでセットアップが未完了の状態を示すことがありますが、それだけではエラーではありません。開始手順で、問題があれば具体的なブロッカーが報告されます。
4. 下書きの対象タイプを確認し、その Product Analytics 属性が @usr.id であることを検証します。これはフェーズ 2 の subject_identifier タグから生成されたフィールドと一致する必要があります。開始には対象タイプが必要ですが、サーバーが任意に選んだデフォルトをそのまま受け入れないでください。別のフィールドにマッピングされた対象タイプでは、これらの Agent Observability の結果を利用できません。続行する前に、@usr.id と互換性のある対象タイプを明示的に選択してください。利用可能な機能でマッピングを確認または設定できない場合は、ユーザーに Datadog UI を使うよう案内し、確認が取れるまで停止してください。

先にフラグを作成する代わりに、実験にリンクされた割り当てとともにフラグを作成する単一の操作（create-experiment-feature-flag ツール）を使う方法もあります。この方法では、実験と環境があらかじめ存在している必要があります。上記の手順に沿った方法では、各書き込みを小さく保ち、簡単に読み戻せます。そのため、このスキルではこの方法を使用します。

実験の名前と ID を報告します。サーバーから返された ID と、組織の Datadog サイトのアプリケーションホストを使って、Product Analytics の直接 URL を次の形式で作成します。 https://<app-host>/product-analytics/experiments/<experiment-id>。US1 では app.datadoghq.com、EU では app.datadoghq.eu を使用します。us5.datadoghq.com などのリージョンサイトでは、そのホストを直接使用します。datad0g.com では dd.datad0g.com を使用します。実験が下書きのままか開始済みかにかかわらず、セットアップ手順を完了した後の最終的な引き継ぎにこのリンクを含めます。

フェーズ 4 — 指標を作成して追加する

作成する前に再利用する

まず、既存の実験指標を一覧表示します。ML アプリのユーザーのスコアをすでに測定している指標があれば、それを再利用します。既存の指標が Agent Observability のデータに基づいている場合は、その保存済みの定義を読み取り、列名を推測せずにそのままコピーします。コスト指標とトークン指標についても同様です。

主指標：スコア評価

主指標はフェーズ 0 で承認されたスコアです。ユーザーが指定していない場合は、ML アプリに存在する評価を一覧表示し、最も関連性の高い数値スコアを単一のセットアップ提案で推奨します。読み戻した内容が承認済みの定義と矛盾しない限り、ここで別の選択を求めて処理を中断しないでください。

• ソース： ML アプリと評価ラベルで絞り込んだ Agent Observability の評価指標。
• 集計： スコア値の平均。
• 望ましい変化： 改善とみなす方向。METRIC_INCREASES または METRIC_DECREASES のいずれかです。このフィールドは必須であり、誤った値を設定するとすべての結果の解釈が逆になるため、フェーズ 0 の提案に明示的に含めてください。

定義の例（列は標準的な評価イベントフィールドであるラベル、スコア値、ML アプリです）：

data source:        DATADOG
source type/subtype: LLMOBS / LLMOBS_EVAL_METRICS
aggregation:        average of @score_value
source filter:      @ml_app = <ml_app> AND @label = <evaluation label>
desired change:     METRIC_INCREASES (for a score where higher is better)

セカンダリメトリクス：トークン数とコスト

変更にかかるコストをユーザーが確認できるように、2つのセカンダリメトリクスを追加します。どちらも完了した LLM Observability のルートトレースを対象とし、トレースごとの平均を算出します。

• 平均トレーストークン数： @trace.total_tokens の平均。望ましい変化：METRIC_DECREASES。
• 平均トレースコスト： @trace.estimated_total_cost の平均。望ましい変化：METRIC_DECREASES。

Agent Observability のスパンソース（LLMOBS / LLMOBS_SPANS）を使用し、average 演算と列タイプ int を指定します。通常のイベントフィルターで @ml_app = <ml_app> に絞り込み、同じ対象が使用する他のアプリケーションのトレースが結果に含まれないようにします。トレースの完了状況やルートスパンのステータスに関するフィルターは追加しないでください。これらの適格性ルールはプラットフォーム側で適用され、メトリクス定義では上書きできません。すべてのスパンを合計しないでください。子スパンや未完了のトレースまでカウントされます。組織に LLM Observability のスパンメトリクスがすでにある場合は、ここに記載された名前に頼らず、保存済みの定義から列名とタイプをコピーしてください。ただし、保存済みのフィルターですでにこの @ml_app に絞り込まれている場合に限り、再利用してください。トレースの集計値は整数であることが想定されます。メトリクスにデータが表示されない場合は、まず列タイプを確認してください。保存されているタイプは、プラットフォームが公開するタイプと一致している必要があります。

メトリクスをアタッチする

一度に1つずつアタッチし、決して同時にアタッチしないでください。

1. スコアメトリクスをプライマリとしてアタッチします。
2. トークン数をセカンダリメトリクスとしてアタッチします。
3. コストをセカンダリメトリクスとしてアタッチします。

実験を読み直し、プライマリメトリクスが設定されていることを確認します。実験の読み取り結果にセカンダリメトリクスが含まれない場合は、アタッチ成功時のレスポンスに含まれるメトリクス一式を確認に使用し、通常の実験読み取りではそれらを取得できないことを明確に伝えます。

フェーズ 5 — 環境とトラフィック分割

実験は、1つの割り当てを通じてちょうど1つの環境にリンクします。

1. ユーザーが指定した環境でフラグを有効にします。サーバーを通じた本番環境でのフラグ有効化は拒否され、ユーザーを UI に案内する場合があります。その場合は、フラグの UI リンクをユーザーに伝え、そこで有効にするよう依頼してください。割り当ての変更（ステップ 3）は別の操作であり、本番環境でも引き続き利用できる場合があります。

2. 対象環境と、この実験にすでにリンクされているその他の環境で、フラグの割り当て一式をすべて一覧表示します。割り当ての設定は全件置換であるため、各置換リクエストでは、無関係な割り当てとそのすべての設定を保持してください。

3. 実験にリンクされたフィーチャーゲートの割り当てを、無関係な割り当てを全件置換リストに残したまま、ちょうど1つ追加または更新します。バリアントのウェイトはパーセンテージで、合計がちょうど 100 になるようにします（例：コントロール 50、トリートメント 50）。同じ呼び出しでエクスポージャースケジュールを含めてください。そうしないと、実験は開始されません（次の段落を参照）。 割り当てには、以下のフィールドをすべて含むエクスポージャースケジュールが必要です。含まれていない場合、開始ステップで準備未完了と報告されます。一般的な割り当てスキーマではフィーチャーゲートのスケジュールを省略するよう記載されていますが、これは実験にリンクされていないゲート向けの説明であるため、この場合にも当てはまります。

   • selection_interval_ms（この戦略で必須）を指定した、一様間隔のロールアウト戦略。
   • none の開始値。スケジュールが自動的に始まらず、実験自体の開始がタイミングを制御するようにします。
   • exposure_ratio が 1.0（0～1 の比率であり、100 ではありません）、is_pause_record が false、grouped_step_index が 0 のロールアウトステップを1つ。これにより、バリアントのウェイトで指定した割合がすべてのトラフィックに適用されます。
   • コントロールバリアントを指定する、スケジュールの control_variant_key（これがなくても割り当ては保存できますが、その場合、開始ステップで割り当てウェイトが無効と報告されます）。

   ここでは段階的なロールアウトを使用しないでください。50/50 の分割はウェイトですでに表現されています。

4. 実験が別の環境の割り当てにすでにリンクされている場合は、その環境の割り当て一式を読み取り、実験にリンクされた割り当てだけを削除してから、新しい割り当てを作成します。それ以外のすべての割り当てとその設定は保持してください。承認済みの設定で全割り当ての削除が明示されている場合を除き、環境を空のリストで置き換えないでください。割り当てキーがすでに存在する場合は、競合する割り当てを特定してください。承認済みの設定に属する場合に限り再利用し、それ以外の場合は新しい一意のキーを選んでください。この復旧方法が承認済みの提案と実質的に異なる場合は、改めて確認してください。

5. 割り当てを読み戻し、環境、ウェイト、実験とのリンクを確認します。

本番環境での割り当て変更は即時に反映されます。環境でフラグ変更の承認が必要な場合、変更は適用されずにその承認を待つことがあります。承認済みのフェーズ 0 の提案で、環境と本番環境であることは確認済みです。既存の割り当て一式が、その提案で置き換えると記載された内容と実質的に異なる場合を除き、再度確認を求めないでください。

フェーズ 6 — 実験を開始する

ユーザーから明示的に依頼された場合にのみ開始してください。開始する直前に、開始操作の準備状況チェックだけに頼らず、以下を個別に確認してください。

• リンクされた環境でフラグが有効になっていること。
• 50/50（または選択した比率）の割り当てが設定され、リンクされていること。
• プライマリメトリクスが設定されていること。
• アプリケーションの変更がデプロイ済みであるか、ユーザーがデプロイ前に計測を開始することに明示的に同意していること。

リンクされた環境でフラグが無効だと分かっている場合は、開始を呼び出さないでください。開始時の準備状況チェックでは、割り当ての構造を検証しても、フラグの有効化やデプロイを確認しないことがあります。そのため、開始に成功してもトラフィックが流れるとは限りません。

その後、実験を開始してください（start-experiment ツール）。このツールは独自の準備状況チェックを実行し、検出可能な構造上のブロッカーと、それぞれの対応策を返します。すべての対応策を適用してから、1 回だけ再試行してください。複数回の対応が必要になる場合があります。現時点で検出できるブロッカーが報告されるため、1 つを修正すると次の問題が明らかになることがあります（たとえば、最初に露出スケジュールの不足が報告され、そのスケジュールのコントロールバリアントが無効だと後から判明する場合など）。割り当てを修復すると、フラグの割り当てセット全体が置き換わるため、まず割り当てを読み取ってください。必要な置き換え内容がフェーズ 0 で承認されたものと異なる場合にのみ、ユーザーに再確認してください。権限エラーが返された場合は、アカウントに実験を開始する権限がないことを伝え、そこで停止して、UI のプレビューおよび開始フローを提案してください。再試行を繰り返さないでください。

開始後、実験を読み取り直し、そのステータスを報告してください。

フェーズ 7 — トラフィックが流れたら検証する

アプリケーションがデプロイされ、トラフィックを受信したら、次の操作を行ってください。

• 実験の診断を実行します。露出のバランスに加え、フラグのデータがゼロのメトリクス、信頼性の低いメトリクス、サンプル比率の不一致をチェックします。
• メトリクスにデータがない場合は、次の順序で確認してください。対象に対してフラグが評価されていること（実験のコード位置検索で、ソース内のフラグの使用箇所を確認できます）、評価値に数値のスコアがあること、subject_identifier が targetingKey と完全に一致すること、ルートスパンにタグが付いていること、トレースが完全であること、メトリクスの列名と型が正しいこと。
• メトリクス定義が間違っている場合は、重複を作成せず、メトリクスを更新して修正してください。

データが十分に集まった後に結果を読み取るには、agent-observability-experiment-analyzer、またはアクティブな MCP サーバーで利用可能な Datadog の実験ツールを使用してください。

注意事項チェックリスト

• フラグ、評価、スパン間で対象 ID が一致していない。
• ルートスパンに対象タグがないため、コストおよびトークンのメトリクスを露出に結合できない。
• 対象の種類が @usr.id 以外の属性にマッピングされている。
• スパン単位のマネージド評価で、スコア対象のスパンに対象タグがない。
• コストまたはトークンのメトリクスが全スパンの合計として定義されている、またはトレースのロールアップ以外のスパン属性を参照している。
• コストまたはトークンのメトリクスに @ml_app フィルターがない。
• フラグがある環境では有効になっているが、アプリケーションは別の環境で実行されている。
• 実験が別の環境の割り当てにリンクされている（リンクできるのは 1 つだけです）。
• 割り当てを置き換えた際に、関係のない割り当てや露出スケジュールが削除される。
• 割り当ての重みの合計が 100 になっていない。
• 露出スケジュールのない割り当てセット、または control_variant_key のないスケジュールがあるため、開始手順がブロックされる。
• 評価値がスコアではなく、ブール値またはカテゴリ値になっている。
• メトリクスの desired change の設定が逆になっている。
• メトリクスを並行して設定している。
• ユーザーから依頼される前、またはアプリケーションが実行される環境でフラグが有効になる前に開始している。