本記事の数値について 海外側は、マイクロソフトの実験チームがまとめた報告「Online Experimentation at Microsoft」（Ron Kohaviほか、2009年）を、2026年10月時点で公開されている本文で確認して引用しています。大規模なアクセスがあるサービスでの、2009年時点の社内の経験値です。中小企業のサイトにそのまま当てはまる数字ではありませんが、「改善案はどれくらい当たるのか」を考える材料として紹介します。
サイトを直したあとに、問い合わせが少し増えた。だから今回の改修は成功だった。
サイト改善の現場では、この判断がとてもよく行われます。けれども、この「変えたら良くなった気がする」には見落としやすい点があります。世界で最も多く比較実験を行ってきた会社のひとつが、自社の実績をまとめた数字があります。
改善できた案
なかった案
悪化させた案
成功した割合
Kohaviほか「Online Experimentation at Microsoft」（2009年）より。マイクロソフト社内の比較実験の経験値
何をまとめた報告か
マイクロソフトには、Webサービスの改善案を比較実験（いわゆるA/Bテスト）で確かめるための専門チームがありました。2006年3月に少人数で立ち上がり、社内のさまざまなサービスに実験の仕組みを広げていったチームです。報告によれば、このチームの基盤を使った実験は、会計年度2007年の2件から、2008年に8件、2009年には44件まで増えています。
比較実験とは、利用者をランダムに2つに分け、片方には今のページ、もう片方には改善案のページを見せて、成果の差を測る方法です。2つのグループは同じ時期に同じように季節や広告の影響を受けるので、差を比べれば「その変更が効いたのか」を取り出せます。
この報告の中で、チームは自分たちの経験をこうまとめています。狙った指標を改善できた案は約3分の1。約3分の1は変化がなく、約3分の1はむしろ指標を悪化させた。
優秀な人たちが考えた案でも、当たるのは3分の1
ここで大事なのは、これが思いつきの案の成績ではないという点です。報告は、最善を尽くし、案を絞り込んだうえでも、ほとんどの案は比較実験で価値を示せなかったと書いています。「良いはずだ」と判断して試した案が、この成績だったということです。
報告は、この傾向がマイクロソフトに限らないことにも触れています。ソフトウェア業界の報告を見ても、比較実験で確かめた案の成功率は50%を下回るものが多い。Amazonでは新しい機能をすべて実験で評価する習慣があるが、それでも成功率は50%未満だった、としています。
図① 改善案を比較実験で確かめた結果の内訳（報告が示す経験値。厳密な比率ではなく「おおむね3等分」）
「出してみれば分かる」は、極端な場合にしか通用しない
比較実験をしなくても、公開したあとの数字を見れば良し悪しは分かる。そう考える人は多いと思います。報告はこれに対して、それが通用するのは極端に良いか、極端に悪い変更だけだと述べています。
報告によれば、たいていの案は指標の変化が小さすぎて、時間の推移を見ているだけでは見分けられません。さらに、公開前と公開後を比べるやり方も勧められないとしています。外部の要因による変動の方が、改善案の効果よりずっと大きくなりやすいからです。
問い合わせの数は、季節、曜日、広告の出し方、競合の動きで大きく揺れます。今月は問い合わせが増えた。けれどもそれが改修のおかげなのか、たまたまなのかは、同じ期間に比べる相手がいなければ分かりません。
確かめずに10個出すと、どうなるか
報告には、分かりやすいたとえがあります。改善案を10個、効果を測らずにすべて公開したとします。3分の1は良く、3分の1は効果なし、3分の1は悪い。良い案の効果と悪い案の害が打ち消し合い、全体ではほとんど何も良くならない。
一方、10個を確かめてから、効いた3〜4個だけを残し、残りをやめれば、全体の効果は大きくなる。
✕ 確かめずに全部出す
- 良い案・効果なし・悪い案がそのまま残る
- 良い効果と悪い影響が打ち消し合う
- 「いろいろやったが成果が出ない」状態になる
○ 確かめてから残す
- 効いた案だけを残し、悪い案は元に戻す
- 効果が積み上がっていく
- 次の案を考える材料も残る
図② 報告の「10個の改善案」のたとえを図にしたもの
サイト改善が「いろいろ手を入れたのに、成果が出ない」状態になる理由の一つが、ここにあります。効いた変更と、むしろ悪くした変更が、同じサイトの中に混ざっているのです。
この数字の限界
① 2009年の、マイクロソフト社内の経験値です。厳密な統計ではなく「おおむね3分の1ずつ」という表現で示されています。
② 偏りがあることを著者自身が認めています。実験は、担当者が効果に確信を持てない案ほど行われやすいので、成功率が低めに出る可能性があります。ただし著者は、全機能を評価しているAmazonでも成功率は50%未満であることから、この偏りは思われているほど大きくないとしています。
③ アクセスが大きいサービスの話です。比較実験で小さな差を見分けるには、相当な数の訪問者が必要です。月に数千人程度のサイトで、同じやり方がそのまま使えるわけではありません。
③は中小企業にとって特に大事なところです。アクセスが少ないサイトでA/Bテストを回しても、差が誤差に埋もれて結論が出ないことがよくあります。だからといって、確かめることを諦める必要はありません。
中小企業のサイトでどう確かめるか
確実なのは、比較実験です。まずはアクセスが最も集まるページ（広告の着地ページ、トップページなど）から始めるのが現実的です。
それでも比較実験ができない規模なら、公開前後の比較に頼るしかありません。ただし前述のとおり、報告はこのやり方を勧めていません。前後の比較で分かるのは「大きく効いたか、大きく悪化したか」くらいで、小さな差は外部要因に埋もれると心得たうえで、次の点を守ると判断を誤りにくくなります。
- アクセスが最も多いページから、比較実験（A/Bテスト）を試す
- 前後の比較に頼るときは、変更を一度に1か所にする（どれが効いたか分からなくなるため）
- 変更した日を記録し、同じ曜日・同じ長さの期間で比べる。広告や季節の変化があった期間は判断を保留する
- 問い合わせ数だけでなく、フォームの開始数や完了率など、変更に近い数字を見る
- 悪化した変更は元に戻す（「せっかく作ったから」で残さない）
比較実験が基本。できない規模での前後比較は、大きな差を見分ける目安にとどめる
最後の「元に戻す」が、実は一番難しいところです。手間をかけて作った変更を、数字が悪かったからと取り下げるのは勇気が要ります。けれども報告が示すとおり、3分の1の案はそもそも悪化させるものです。戻すことは失敗ではなく、改善の一部です。
まとめ
- マイクロソフトの実験チームの経験では、狙った指標を改善できた案は約3分の1。約3分の1は変化なし、約3分の1は悪化だった
- Amazonでも、すべての新機能を実験で評価して成功率は50%未満
- 公開後の数字だけで良し悪しが分かるのは、極端に良いか悪い変更に限られる。報告は公開前後の比較も勧めていない
- 確かめずに出し続けると、良い変更と悪い変更が打ち消し合い、全体ではほとんど良くならない
- まずはアクセスの多いページで比較実験を。できない規模なら、1か所ずつ変える・記録する・悪ければ戻す
では、国内のサイトはどれくらい「確かめる仕組み」を持っているのか。次の記事で、20業種603サイトに入っているA/Bテスト・パーソナライズ（利用者ごとの出し分け）系のツールを実測した結果をお見せします。
コンバージョン偏差値スキャナーでは、改善の優先順位を50項目の採点から示しています。URLを入れるだけで、最短60秒・登録不要で結果が表示されます。
出典：Ron Kohavi ほか「Online Experimentation at Microsoft」（2009年）
