実験 (プレビュー)
実験とは、ユーザー エクスペリエンスやソフトウェア機能を向上させるために仮説や変更を体系的にテストするプロセスです。 この定義は、すべての実験が 4 つの一般的な手順を持つテクノロジを含むほとんどの科学分野にも当てはまります。
- この実験の目的を文書化するために仮説を立てる、
- 何をどのように測定するのか、セットアップを含む実験の実施方法を概説する、
- 前の手順で定義された測定基準によって測定された結果を観察する、
- 仮説が有効であったか無効であったかに関する結論を導き出します。
App Configuration での実験の簡単なデモンストレーションについては、このビデオを確認してください。ビデオでは、ビジネス メトリックを強化するために行うユーザー エクスペリエンスの最適化に関するユース ケースに着目しています。
Azure App Configuration での実験 (プレビュー)
Azure App Configuration で実験機能を使用すると、開発者は機能のさまざまなバリエーションを簡単にテストし、機能レベルで影響を監視できます。 構成した後、ユーザーは新しい機能を分析し、機能のさまざまなバリエーションを比較し、新しい製品の変更に関連するメトリックを迅速に評価できます。 この機能を使用して、開発チームは測定可能な分析情報を得ることができ、製品の迅速かつ安全なデプロイが容易になります。 Microsoft は Split Software と提携して、Azure App Configuration での実験機能を提供します。 Split Experimentation Workspace (プレビュー) は、Microsoft と Split Software を統合するための Azure Native ISV リソースです。
Azure での実験の高度なデータ フロー。
実験を開始するには、まず、実験する機能とそのバリエーションを特定する必要があります。 次に、特徴評価の基礎となるメトリックを示します。 Azure での最初の実験を開始するには、このチュートリアルで説明されている手順に従います。
実験に関連する概念
バリアント機能フラグ: 機能のさまざまなバージョンまたは構成を表します。 実験では、バリアント機能フラグは、関心のあるメトリックと、アプリケーションの対象ユーザーに割り当てられたトラフィックに関連して比較されます。
テレメトリ: テレメトリは、機能のバリエーションのデータと、その機能を評価するための関連メトリックです。 Azure でのセットアップでは、機能フラグの評価/割り当てデータがテレメトリ プロバイダーに送信されます。 Application Insights は、実験のセットアップ用のテレメトリ プロバイダーです。 定義されたメトリックのデータも、同じ Application Insights インスタンスにフローされます。
A/B テスト: A/B テスト (分割テストとも呼ばれる) は、テクノロジ スタック内の潜在的な変更の影響を評価するための業界標準の手法です。
サンプリング サイズ: サンプリング サイズは、実験中のユーザーのサンプルのサイズです。 これは、実験中の機能のバリエーションに対して送信されるイベントの数です。
最小サンプリング サイズ: 統計的に有意な結果を示すために実験の特徴のバリエーションごとに必要なイベントの最小数です。 サンプル サイズが大きいほど、実験の結果の統計的有意性が向上します。
次の例を考えてみましょう。e コマース Web サイトの顧客が、黄色のチェックアウト ボタン (バリアント A) と青色のチェックアウト ボタン (バリアント B) のどちらをクリックする確率が高いかを調べたい場合があります。 この比較を設定するには、機能フラグの 2 つのバリエーション間でトラフィックを分割し、クリック数をメトリックとして使用してパフォーマンスを測定する必要があります。 すべての機能を簡単に測定してすぐに評価できるとは考えにくいので、そこで実験が必要になるのです。 実験を実行するには、関心のあるメトリックに関連する各バリアントのパフォーマンスを比較するこのプロセスのタイムラインを設定する必要があります。 "A/B テスト" と "実験" という用語は、多くの場合、同じ意味で使用されます。実験は基本的に、仮説を体系的にテストする拡張された A/B テストです。
実験を設定する
開始する前に、仮説検出の段階で次の問いを検討してください。実験を実行して、どのような問題に答えようとしていますか? 実験は何で実行する必要がありますか? なぜですか? どこから始めますか? ビジネス ニーズに応じて従う戦略は何ですか? この実験は、アプリケーションのパフォーマンスやビジネスのパフォーマンスをすぐに改善するのに役立ちますか?
完全なリリースの前に実験を実行して、何を達成したいかを特定し、この段階で計画を文書化する必要があります。 実験する機能のバリエーションは何ですか? 関心のあるメトリックの一部は何ですか? データをキャプチャし、測定のためにこれらのメトリックを促すには、ユーザーまたはシステムの対話のどのようなイベントが使用できますか?
実験は、収集するデータと同じくらい適切です。 実験を開始する前に、コントロールとして使用するバリアント (ベースライン バリアント) と、変更を確認するバリアント (比較バリアント) を決定する必要があります。
実験から結論を導く
結論を導き出す (または必要に応じて複数の結論を出す) のは、実験サイクルの最終段階です。 コントロール バリアントに対する比較バリアントの結果と、影響を示す実験の結果を確認できます。 結果には、統計的有意性も示されます。 Statsig 測定は、テレメトリ データとサンプル サイズによって異なります。
結果は、学習と結果を、運用環境にすぐに実装できる実行可能な項目に結び付けるのに役立ちます。 ただし、実験は継続的なプロセスです。 新しい実験を開始して、製品を継続的に改善します。
実験を使用するためのシナリオ
リリース防御
目的: スムーズな移行を確保し、リリースごとに主要なメトリックを維持または改善します。
アプローチ: 実験を実施して、新機能を段階的にロールアウトし、パフォーマンス メトリックを監視し、反復的な改善のためのフィードバックを収集します。
メリット:
- ガードレール メトリックを使用してロールアウトの初期段階で問題を検出し、対処することで、広範囲にわたる問題のリスクを最小限に抑えます。
- リアルタイム データを基にして、情報に基づいて意思決定を行うことで、主要なパフォーマンスとユーザー満足度のメトリックを維持するか向上させるために役立ちます。
仮説をテストする
目的: 製品の機能、ユーザーの行動、またはビジネス戦略について、情報に基づいて意思決定を行うために、仮定と仮説を検証します。
アプローチ: 実験を使用して、さまざまな機能バージョンまたはシナリオを作成して特定の仮説をテストし、ユーザー操作とパフォーマンス メトリックを分析して結果を判断します。
メリット:
- 不確実性を軽減し、戦略的な意思決定を導く、証拠に基づいた分析情報を提供します。
- 実際のユーザー データを使用して仮説を確認または反証することで、より迅速なイテレーションとイノベーションを実現します。
- 機能することが実証されたアイデアに重点を置いて製品開発を強化し、最終的には、より成功したユーザー志向の機能を実現します。
A/B テスト
目的: さまざまな UI バリエーションを比較し、最も効果的な設計を決定することで、ビジネス メトリックを最適化します。
アプローチ: 実験を使用して A/B テストを実施し、UI 要素をテストし、ユーザーの対話を測定し、パフォーマンス メトリックを分析します。
メリット:
- 経験的な証拠に基づいて UI の変更を実装することで、ユーザー エクスペリエンスを向上させます。
- デジタル製品やサービスのコンバージョン率、エンゲージメント レベル、全体的な有効性を高めます。
インテリジェント アプリケーションの場合 (AI ベースの機能など)
目的: 生成 AI (Gen AI) の導入を加速し、迅速な実験を通じて AI モデルとユース ケースを最適化します。
アプローチ: 実験を使用して、AI モデルをすばやく反復処理し、さまざまなシナリオをテストし、効果的なアプローチを決定します。
メリット:
- 進化するユーザー ニーズと市場傾向に AI ソリューションを適応させる機敏性を高めます。
- AI イニシアティブをスケーリングするための最も効果的なアプローチの理解を促進します。
- 実際のデータとフィードバックに基づいて AI モデルの正確性とパフォーマンスを向上させます。
パーソナル化とターゲット設定の実験
目的: ユーザーの好みや行動に合わせてカスタマイズされたコンテンツとエクスペリエンスを提供します。
アプローチ: 実験を利用して、パーソナライズされたコンテンツをテストし、エンゲージメントを測定し、パーソナル化戦略を繰り返します。
メリット:
- 関連するパーソナライズされたエクスペリエンスを介して、ユーザー エンゲージメント、コンバージョン率、顧客ロイヤルティを向上させます。
- カスタマイズされたメッセージとオファーで対象ユーザーをターゲットにすることで、収益の増加と顧客のリテンション期間を促進します。
パフォーマンス最適化の実験
目的: パフォーマンスの最適化実験を通じて、アプリケーションのパフォーマンスとユーザー エクスペリエンスを向上させます。
アプローチ: パフォーマンスの向上をテストし、主要なメトリックを測定し、成功した最適化を実装するための実験を実施します。
メリット:
- プロアクティブなパフォーマンスの向上を介して、アプリケーションのスケーラビリティ、信頼性、応答性を高めます。
- 効率的な最適化を実装することで、リソースの使用率とインフラストラクチャのコストを最適化します。
実験の操作
実験の作成: テレメトリを出力するバリアント機能フラグで実験を作成できます。 実験が作成されると、実験バージョンも実験と共に作成されます。 機能フラグをさらに編集すると、その実験用に新しい実験バージョンが作成されます。
アーカイブ実験: 実験をアーカイブすると、アーカイブされた状態になります。 実験がアーカイブされている間は、実験に対して計算は実行されません。 実験は、後でいつでも復元して計算を再開し、アクティブな状態に戻すことができます。
実験の復旧: 実験を復旧すると、アーカイブされた実験がアクティブな状態になり、実験の計算が再開されます。
実験の削除: 実験を削除すると、Split の実験とそれに関連するすべてのデータが削除されます。 これは元に戻せない操作であるため、削除後は復元できません。
実験の結果を確認する: アクティブな実験の結果を確認すると、実験内の各バリアントがどのように実行されているかを確認できます。
実験操作のアクセス要件
次のセクションでは、Microsoft Entra ID を使用して実験関連の操作を実行するために必要なロールについて詳しく説明します。
実験を設定する
Split Experimentation ワークスペースなどの必要なリソースを使用して実験を設定するには、Azure サブスクリプションの所有者ロールまたはサブスクリプションの共同作成者とユーザー アクセス管理者ロールの組み合わせが必要です。
実験を作成または更新する
実験を作成、更新、アーカイブ、または削除するには、App Configuration ストアの App Configuration データ所有者ロールが必要です。 また、接続された Split Experimentation ワークスペースへのデータ アクセスを管理する Enterprise アプリの ExperimentationDataOwner のロールも必要です。
実験結果の読み取り
実験、そのバージョン、結果を確認するには、App Configuration ストアの App Configuration データ閲覧者ロールが必要です。 また、接続された Split Experimentation ワークスペースへのデータ アクセスを管理する Enterprise アプリの ExperimentationDataReader または ExperimentationDataOwner ロールも必要です。
請求に関する考慮事項と制限
App Configuration は、実験に対して特に課金されません。 実験は、Split Experimentation ワークスペース (プレビュー) との統合を介して提供されます。 Azure App Configuration の Split Experimentation の価格プラン を確認します。
Split Experimentation に必要な最小サンプル サイズは、バリアントあたり 30 です。 実験の結果を取得するには、実験の最小サンプル サイズが必要です。または、結果に "データなし" と表示されます。