はじめに：A/Bテストには「学習中の損失」がある
A/Bテストは新しい施策の効果を確かめるための定番の手法です。ですが、検証期間中は劣ったパターンにも均等にトラフィックを流し続けるため、そこには機会損失が生まれます。
この「学習している間の損失」をできるだけ減らそうとする発想から生まれたのが、本記事で扱うマルチアームドバンディット(多腕バンディット)というアルゴリズムです。
名前は、複数のスロットマシン(一本腕の賭博機、英語でbandit)が並んでいるとき、どれを引けば一番稼げるかを試行錯誤しながら決める、という古典的な数学の問題に由来します。
プロダクト改善やLPの出し分けに携わる人なら、A/Bテストの検証期間が長くて焦れた経験があるはずです。せっかく良い案が見えているのに、統計的な決着がつくまで劣った案にもトラフィックを流し続けるのはもどかしいものです。
この記事では、その次の一手として使われるマルチアームドバンディットの考え方と、A/Bテストとの正しい使い分けを整理します。
結論を先に言うと、マルチアームドバンディットはA/Bテストの上位互換ではありません。厳密な検証を犠牲にして早い刈り取りを優先する、性質の異なる道具だと理解しておくと、あとの使い分けの話が飲み込みやすくなります。
マルチアームドバンディットとは何か
探索と活用のトレードオフ
マルチアームドバンディットは、複数の選択肢(施策・広告クリエイティブ・レコメンド候補など)の中からどれが一番良い成果を出すかを試しながら学習し、その学習結果をリアルタイムでトラフィック配分に反映していくアルゴリズムの総称です。
この仕組みの核心は、探索(exploration)と活用(exploitation)のトレードオフです。探索とは、まだ成果がよくわからない選択肢にもトラフィックを流して情報を集めることを指します。
活用とは、これまでの結果から一番良いとわかっている選択肢に多くのトラフィックを寄せて、目先の成果を最大化することです。この二つを同時に完全には満たせないため、バランスの取り方がアルゴリズムごとの違いになります。
探索ばかりでは成果の良い案がわかっても活かせず、活用ばかりでは局所的に良く見えた案に固執して本当に優れた案を見逃すおそれがあります。どちらかに極端に振れないように調整することが、バンディット設計の本質だといえます。
この探索と活用のバランス調整をどう自動化するかが、次の章で見るアルゴリズムごとの違いになります。同じ目的を達成するにも、単純な確率設定で済ませる方法もあれば、統計的な裏付けを重視する方法もあります。
リグレットという損失の考え方
バンディットの世界では、最初から一番良い選択肢だけを選び続けていたら得られたはずの成果と、実際に得られた成果との差をリグレット(regret、後悔)と呼びます。
従来型のA/Bテストは、検証期間中はA案とB案に固定比率でトラフィックを割り振り続けるため、劣っている案にも最後まで同じ量のトラフィックが流れます。これは統計的に正しい判定をするために必要な設計ですが、リグレットの観点では大きな損失になります。
マルチアームドバンディットは、成果が良いとわかってきた選択肢に徐々にトラフィックを寄せていくことで、このリグレットを小さく抑えようとする仕組みです。優れたアルゴリズムほど、試行回数が増えるにつれてリグレットの増加ペースが緩やかになることが理論的に示されています。
代表的なアルゴリズム
具体的にどうやって探索と活用のバランスを取るのか、代表的なアルゴリズムを見てみましょう。
イプシロン・グリーディ法
最もシンプルな方法がイプシロン・グリーディ法です。あらかじめ小さな確率イプシロン(例えば10%)を決めておき、その確率でランダムに選択肢を選んで探索し、残りの確率では今のところ一番成果が良い選択肢を選んで活用します。
仕組みが単純で実装しやすい一方、イプシロンの値を固定すると、十分に学習が進んだ後も同じ割合で無駄な探索を続けてしまう弱点があります。
UCB(上側信頼限界)法
UCB法(Upper Confidence Bound)は、各選択肢の「これまでの平均成果」に加えて、「まだ試行回数が少なく不確実性が高い」選択肢にボーナスを与えて選ばれやすくする方法です。
試行回数が増えるほどこのボーナスは小さくなるため、データが十分に集まった選択肢は徐々に純粋な成果の比較に近づいていきます。数学的な裏付けがしっかりしている一方、計算はイプシロン・グリーディ法よりやや複雑です。
トンプソンサンプリング
トンプソンサンプリングは、各選択肢の成果を確率分布として表現し、その分布から毎回ランダムに値を1つずつ引いて、一番大きい値が出た選択肢を選ぶという方法です。
データが少ない選択肢は分布の幅が広く、たまたま高い値を引いて選ばれることがある一方、データが十分にある選択肢は分布が狭くなり安定して選ばれるようになります。ベイズ統計にもとづくこの方法は、実務でも広く採用されているアルゴリズムのひとつです。
コンテキストバンディットへの発展
ここまでの3つは「どの選択肢が一番良いか」を全ユーザー共通で1つだけ決める仕組みでした。実際には、同じ選択肢でも訪問者の属性やアクセス経路によって最適な答えが変わることが少なくありません。
新規訪問者には定番の訴求が刺さり、リピーターには別の訴求が刺さる、という状況は珍しくないはずです。
これに対応するのがコンテキストバンディットです。訪問者の状況(コンテキスト)を入力に加え、状況ごとに最適な選択肢を学習していきます。
動画配信サービスが視聴者ごとに表示するサムネイル画像を出し分ける仕組みなど、大規模なパーソナライズにコンテキストバンディットが使われている例が知られています。実装や運用の難易度は上がるため、まずは全体共通の配分で仕組みに慣れてから検討するのが現実的です。
なお、どのアルゴリズムを使っても共通の悩みになるのがコールドスタート問題です。データがまったくない立ち上げ直後は、どの選択肢についても確信を持てないため、しばらくはほぼ均等に近い配分で様子を見るしかありません。
焦って早期に配分を偏らせると、たまたま出た初期の結果に引きずられてしまうリスクがあります。
A/Bテストとバンディットの使い分け
では、A/Bテストをすべてバンディットに置き換えればよいかというと、そうではありません。目的によって向き不向きがはっきり分かれます。
| 観点 | A/Bテスト | マルチアームドバンディット |
|---|---|---|
| トラフィック配分 | 検証期間中は固定比率を維持する | 成果に応じてリアルタイムに変動する |
| 得意なこと | 厳密な統計的判定、意思決定の根拠づくり | 早い成果の刈り取り、リグレットの最小化 |
| 向いている場面 | 料金改定や導線設計など後戻りしにくい判断 | 見出しやクリエイティブなど選択肢が多く回転が速い場面 |
| 結果の説明しやすさ | 「B案がX%優れている」と明確に言える | 配分の推移から傾向は読めるが厳密な検定には不向き |
A/Bテストが向く場面
A/Bテストは、施策の効果を統計的に厳密な形で確かめ、その結論を根拠に大きな意思決定をしたい場面に向いています。例えば、料金プランの改定や、主要な導線設計の変更のような、後戻りしにくい判断です。
A/Bテストの結果は「B案がA案よりX%優れている」という明確で再現性のある形で残るため、社内外への説明責任を果たしやすいという利点もあります。経営会議や投資判断の材料として使うなら、迷わずA/Bテストを選ぶべきです。
バンディットが向く場面
一方でバンディットは、選択肢の数が多く、かつ成果を早く刈り取りたい場面に向いています。ニュースサイトの見出しの出し分けや、ECサイトのおすすめ商品の並び替え、広告クリエイティブの自動最適化などが典型例です。
選択肢が2〜3個しかない小規模な検証では、バンディットのメリットはそれほど大きくありません。選択肢の数が多いほど、また入れ替わりが速いほど、この手法の効果が出やすい傾向があります。
計算例で見る動き方(仮定の数値です)
感覚をつかむために、簡単な仮の数値でイプシロン・グリーディ法の動きを追ってみましょう。以下の数値はすべて説明用の仮定です。
仮のシナリオ設定
3つのLPパターンA・B・Cがあり、それぞれの本当のコンバージョン率はA=2%、B=3%、C=5%だったとします。もちろん運用側はこの真の値を最初は知りません。
イプシロン・グリーディ法でイプシロン=10%と設定し、1000セッションを1ラウンドとしてトラフィック配分を更新していくケースを考えます。
配分がどう変化するか
最初のラウンドは情報がないため、A・B・Cへほぼ均等にトラフィックを振ります。1ラウンド終了時点でCの実測コンバージョン率が最も高く出れば、次のラウンドからは90%のトラフィックをCに、残り10%を3パターンにランダムに振り分けるようになります。
ラウンドを重ねるごとにCへの配分はさらに強化されていきますが、AやBが劣っていたことがわかっている状態でも、10%の探索分だけは配分され続けます。この「わかっていてもゼロにはしない」探索の継続が、A/Bテストのような固定比率の検証と最も違う点です。
探索を止めるとどうなるか
もし途中でイプシロンを0%にしてしまうと、その時点で一番良く見えていた案に配分が固定されます。仮のシナリオでたまたま初期のばらつきでBが良く見えていた場合、本来もっと良いはずのCに切り替わる機会を永久に失ってしまいます。
これを避けるため、実務ではラウンドを重ねるごとにイプシロンを少しずつ小さくしていく「減衰型」の設計や、UCB法・トンプソンサンプリングのように試行回数に応じて自動的に探索の量を調整する方法が好まれます。
導入するときの注意点
便利に見えるバンディットですが、導入にはいくつか気をつけたい点があります。
統計的検出力とサンプルサイズの犠牲
バンディットは早い段階から成果の良い方に配分を寄せるため、劣っている案のサンプルサイズが小さいまま推移します。そのため、「B案とC案の差は統計的に有意か」を厳密に検定したい場面には不向きです。
サンプルサイズと検出力の設計そのものについては、A/Bテストのサンプルサイズ設計で詳しく扱っています。厳密な検定が必要な意思決定には、素直にA/Bテストを選ぶほうが安全です。
「バンディットで回していたら、いつの間にか一番良い案がわかった」という状態は、裏を返せば「どれだけの差があったのかを胸を張って説明できる形では残らなかった」ということでもあります。この特性を理解せずに導入すると、後から根拠を求められたときに困る場面が出てきます。
ガードレール指標とノベルティ効果
配分をリアルタイムで動かす仕組みは、コンバージョン率のような主要指標だけを見ていると、副作用に気づきにくいという弱点もあります。表示速度や解約率など、悪化していないかを確認するガードレール指標を必ず並行して監視しましょう。
また、新しいパターンが一時的に良く見えるノベルティ効果(目新しさによる一時的な反応の良さ)にも注意が必要です。短期の配分の動きだけで判断せず、一定期間の推移を見ながら運用するのが安全です。
非定常な環境への対応
バンディットの多くのアルゴリズムは、各選択肢の本当の成果が時間とともに変わらないことを前提にしています。ところが実際のサイトでは、季節性やキャンペーンの影響で「本当に良い案」が入れ替わることがあります。
この非定常性(成果が時間とともに変化すること)を無視すると、過去に良かった案への配分が固定化し、環境の変化に気づけなくなります。定期的に探索の量を引き上げ直す、あるいは一定期間ごとに学習をリセットするといった運用上の工夫が必要です。
たとえばセール期間中だけ強く反応する訴求文があった場合、セールが終わっても配分がそちらに偏ったまま戻らないことがあります。固定期間比較であるA/Bテストにはこの種の落とし穴がない代わりに、リアルタイムでの追随はできません。
バンディットのリアルタイム最適化という利点は、そのまま環境変化への追随のしすぎというリスクと表裏一体だと捉えておくとよいでしょう。
実装の現実的な選択肢
バンディットをゼロから実装するのはハードルが高く感じられるかもしれませんが、実務ではA/Bテストツールやレコメンドエンジンに組み込まれた機能を使うケースがほとんどです。
まずはA/Bテストの始め方で紹介した検証サイクルに慣れてから、選択肢が多く回転の早い場面だけバンディットを試すという段階的な導入が現実的です。MonaLensのA/Bテストは、固定期間で比較して結果を確定させる従来型の設計であり、バンディットのようなリアルタイム自動配分そのものは持ちません。
ただし検証したい仮説をまず小さく区切って試すという考え方は、仮説検証型のプロダクト開発で触れた進め方と地続きです。
まとめ：目的で選ぶ、対立させない
マルチアームドバンディットは、A/Bテストを置き換える新しい万能薬ではなく、目的に応じて使い分ける道具のひとつです。重要な意思決定の根拠が欲しいときはA/Bテスト、選択肢が多く早く刈り取りたいときはバンディット、という整理をまず持っておくと判断に迷いません。
どちらの手法を選ぶにしても、CVRを上げる7つの視点で挙げたような、そもそも何を改善しようとしているのかという仮説の質が、最終的な成果を左右することに変わりはありません。アルゴリズムの選び方に迷う前に、まず何を検証したいのかを言葉にしておくことが、どちらの手法を使う場合でも最初の一歩になります。