観光DXの現場でも起きている「推薦の停滞」と探索の必要性
デジタル活用支援コンサルタントとして、データ分析やデジタルマーケティングの最適化に向き合う中で、レコメンドシステムの「推薦の停滞」は非常に悩ましい課題です。例えば観光アプリにおいて「京都の観光スポット」を推薦しようとすると、どうしても清水寺や金閣寺といった「超有名どころ」ばかりが上位に表示されてしまう現象が起こります。これは協調フィルタリングの宿命でもあり、データが豊富な人気アイテムほど有利になる「マタイ効果（富める者はますます富む）」の一種です。
これでは、ユーザーは既知の情報ばかり受け取り、飽きてしまいます。一方で、まだ知られていない隠れた名刹（めいさつ）は永遠に推薦されず、機会損失が生まれ続けます。これを打破するのが、強化学習における「探索（Exploration）」の概念です。
しかし、いきなり本番環境で「あえてマイナーなスポットを推薦する」実験を行うのは、CVR（コンバージョン率）低下のリスクがあり、ビジネス的に許容されにくいのが現実です。そこで今回は、エンジニアの皆さんが手元のPCで安全にアルゴリズムを検証できる「オフライン検証環境（シミュレーター）」を、Pythonを使ってゼロから構築する方法を解説します。
ブラックボックスなライブラリに頼らず、自分でコードを書くことで、探索アルゴリズムがどのように「未知」に挑むのか、そのメカニズムを肌で感じていただけるはずです。
1. 探索型レコメンド環境構築の全体像とゴール
まず、今回構築するシステムの全体像を定義しましょう。強化学習の文脈では、「エージェント（推薦システム）」と「環境（ユーザー）」の相互作用としてモデル化します。
なぜ「探索（Exploration）」の実装環境が必要なのか
通常の機械学習モデル（教師あり学習）は、過去のログデータ（＝過去の正解）に基づいて最適化を行います。これは「活用（Exploitation）」に特化したアプローチです。しかし、過去に推薦していないアイテムの反応率はデータが存在しないため、永遠に学習されません。
「探索」とは、不確実性を伴いながらも、あえて情報の少ないアイテムを提示し、フィードバックを得る行為です。この「探索と活用」のバランスを調整するために、以下のコンポーネントを自作します。
- Environment (User Simulator): ユーザーの行動を模倣するクラス。アイテムごとに「真のクリック率（未知）」を持ち、推薦に対して確率的に反応を返します。
- Agent (Bandit Algorithm): 推薦を行う主体。Epsilon-Greedy法やThompson Samplingなどを実装し、過去の観測データから次に推薦すべきアイテムを決定します。
- Evaluator: シミュレーションを実行し、累積報酬やリグレット（理想的な推薦との差）を計測して可視化します。
所要時間と期待されるアウトプット
本記事のコードを順に実装していけば、約1時間程度で以下のグラフが出力できる状態になります。
- 各アルゴリズムが時間の経過とともに、どのように「正解（最もクリック率が高いアイテム）」を見つけ出していくかの推移
- 探索パラメータ（εなど）の違いによる収束速度の比較
これにより、「自社のデータ特性なら、どの程度の探索強度が適切か」を、本番投入前に当たりをつけることが可能になります。
2. 事前準備：Python分析環境とライブラリ選定
今回はアルゴリズムの内部挙動を「肌で」理解することが目的なので、高度なフレームワーク（TensorFlow Agentsなど）はあえて使用せず、基本的な数値計算ライブラリのみでスクラッチ実装します。ブラックボックス化されたライブラリを使うと、バンディットアルゴリズムが「なぜ」その選択をしたのかが見えにくくなるためです。
推奨されるPython環境と依存ライブラリ
再現性を保ち、他のプロジェクトとの競合を防ぐため、仮想環境（venvやconda、Dockerなど）の使用を強く推奨します。特にチーム開発や将来的な本番運用を見据える場合、Dockerを使用することでOSレベルでの環境差異を吸収でき、高い再現性を確保できるため有効な選択肢となります。
ただし、最新のDocker Engineでは一部のレガシー機能が廃止されているケースが報告されています。これに依存する既存のワークフロー（CI/CDパイプラインなど）をそのまま使用するとエラーの原因となるため、環境の構築やアップデートを行う際は、事前に公式ドキュメントで最新の仕様と互換性を確認し、必要に応じて新しい設定へ移行する手順を踏むことをお勧めします。
Pythonのバージョンについては、最新版（3.12系以降など）では一部の科学計算ライブラリや機械学習フレームワークの対応が追いついていない場合があります。学習や実験の段階では、エコシステムが成熟し安定して動作するPython 3.10系や3.11系の環境を用意するのが無難です。
以下のコマンドで、シミュレーションに必要なライブラリをインストールしてください。
pip install numpy pandas matplotlib scipy
- NumPy: 行列演算、乱数生成の中核として使用します。
- Pandas: シミュレーションログデータの管理・集計に使用します。
- Matplotlib: シミュレーション結果（リグレットの推移など）の可視化に使用します。
- SciPy: Thompson Samplingで使用する確率分布（ベータ分布）の生成に使用します。
専門家からのアドバイス：将来的な拡張と環境構築の注意点
今回は使用しませんが、EC支援やデジタルマーケティングの領域など、実運用レベルで大規模な強化学習を行う場合、TensorFlowやPyTorchなどのフレームワークへの移行を検討することになります。その際、開発環境の選定には注意が必要です。例えば、TensorFlowはバージョン2.10を最後に、Windowsネイティブ環境でのGPUサポートを終了しています。現在、WindowsユーザーがGPUアクセラレーションを利用する場合は、WSL2（Windows Subsystem for Linux 2）上での実行、またはDocker（NVIDIA Container Toolkitを利用したコンテナ環境）の使用が公式に推奨されています。
また、モバイル・エッジ向けのTensorFlow Liteが「LiteRT」へ名称変更されるなど、エコシステムの変化は非常に速いです。Docker環境を運用する際も、最新バージョンにおける機能の統廃合やセキュリティ更新が頻繁に行われるため、本格導入時は、書籍や古いブログ記事の情報だけでなく、必ず公式ドキュメントや公式のリリースノートで推奨環境と最新の変更点を確認する習慣をつけることが重要です。
可視化ツールのセットアップ
Jupyter NotebookやGoogle Colabでの実行を想定し、グラフのスタイルを整えておきましょう。視認性の高いグラフは、シミュレーション結果の分析において非常に重要です。
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import scipy.stats as stats
# グラフのスタイル設定（視認性の良いggplotスタイルを採用）
plt.style.use('ggplot')
# 再現性確保のためシードを固定
# 実務でのシミュレーションでは、複数のシード値で試行して平均を取ることが一般的です
np.random.seed(42)
3. Step 1：擬似ユーザー行動シミュレーターの実装
それでは実装に入ります。まずは「環境」を作ります。ここでは簡単のため、ベルヌーイ・バンディット（Bernoulli Bandit）問題を想定します。つまり、ユーザーの反応は「クリックした（1）」か「しなかった（0）」の2値であり、各アイテムには固有の「クリック確率（$\theta$）」が存在するという設定です。
報酬確率（CTR）の生成ロジック作成
例えば、観光スポットが5つあるとします。それぞれの「真の人気度（CTR）」を定義しますが、レコメンドシステム側はこの値を知りません。
class BernoulliEnvironment:
def __init__(self, n_arms, true_probs=None):
self.n_arms = n_arms # アーム数（アイテム数）
# 真の確率が指定されていなければランダムに生成
if true_probs is None:
self.true_probs = np.random.rand(n_arms)
else:
self.true_probs = np.array(true_probs)
# 最適なアームの確率（リグレット計算用）
self.optimal_prob = np.max(self.true_probs)
def step(self, arm_index):
"""
選択されたアームに対して、確率的に報酬（クリック:1, スルー:0）を返す
"""
prob = self.true_probs[arm_index]
# ベルヌーイ試行：確率pで1が出る
reward = 1 if np.random.rand() < prob else 0
return reward
シミュレーション用クラスの動作確認
この環境クラスを使って、観光スポットの例を作ってみましょう。
# 5つの観光スポットの真の人気度（ユーザーには見えない設定）
# 0: 清水寺(0.8), 1: 隠れ寺A(0.1), 2: 隠れ寺B(0.5), 3: 博物館(0.2), 4: カフェ(0.3)
true_probs = [0.8, 0.1, 0.5, 0.2, 0.3]
env = BernoulliEnvironment(n_arms=5, true_probs=true_probs)
# テスト：アーム0（清水寺）を引いてみる
print(f"Arm 0 reaction: {env.step(0)}")
これで、ユーザーが確率的に反応する「世界」が構築できました。
4. Step 2：探索アルゴリズムの実装と接続
次に、この環境に対して推薦を行う「エージェント」を実装します。ここでは代表的な2つのアルゴリズムを比較します。
Epsilon-Greedy法の実装クラス作成
最もシンプルかつ強力な手法です。確率 $\epsilon$ でランダムに探索し、それ以外（$1-\epsilon$）は現時点で最も成績の良いアイテムを選びます。
class EpsilonGreedyAgent:
def __init__(self, n_arms, epsilon=0.1):
self.n_arms = n_arms
self.epsilon = epsilon
self.counts = np.zeros(n_arms) # 各アームの選択回数
self.values = np.zeros(n_arms) # 各アームの平均報酬（推定CTR）
def select_arm(self):
# 探索：確率epsilonでランダム選択
if np.random.rand() < self.epsilon:
return np.random.randint(self.n_arms)
# 活用：推定値が最大のアームを選択
else:
# 初期状態で値が同じ場合はランダムに選ぶ工夫
return np.random.choice(np.flatnonzero(self.values == self.values.max()))
def update(self, arm_index, reward):
# 逐次平均の更新式
self.counts[arm_index] += 1
n = self.counts[arm_index]
value = self.values[arm_index]
# 新しい平均 = (古い平均 * (n-1) + 新しい報酬) / n
new_value = ((n - 1) / n) * value + (1 / n) * reward
self.values[arm_index] = new_value
トンプソンサンプリング（Thompson Sampling）の実装
近年、実務で非常に人気が高い手法です。各アイテムのCTRを確率分布（ベータ分布）として扱い、その分布からサンプリングした値に基づいて選択します。データが少ないうちは分布が広がるため自然と探索が行われ、データが増えると分布が尖り、活用へと移行します。
class ThompsonSamplingAgent:
def __init__(self, n_arms):
self.n_arms = n_arms
# ベータ分布のパラメータ alpha（成功回数+1）, beta（失敗回数+1）
self.alpha = np.ones(n_arms)
self.beta = np.ones(n_arms)
def select_arm(self):
# 各アームのベータ分布からサンプルを抽出
samples = [np.random.beta(self.alpha[i], self.beta[i]) for i in range(self.n_arms)]
return np.argmax(samples)
def update(self, arm_index, reward):
if reward == 1:
self.alpha[arm_index] += 1
else:
self.beta[arm_index] += 1
このコードの美しさは、パラメータ調整（$\epsilon$のようなハイパーパラメータ）が不要で、確率論的に探索と活用のバランスが自動調整される点にあります。
5. Step 3：オフライン評価パイプラインの稼働
役者は揃いました。実際にシミュレーションを回して、アルゴリズムの性能を評価します。評価指標には「累積リグレット（Cumulative Regret）」を用います。これは「もし最初から正解を知っていた場合に得られたはずの報酬」と「実際の報酬」の差の積み上げです。
シミュレーションループの実行スクリプト
def run_simulation(agent, env, n_steps):
rewards = []
regrets = []
for step in range(n_steps):
# 1. アームを選択
arm = agent.select_arm()
# 2. 環境から反応を得る
reward = env.step(arm)
# 3. エージェントを学習させる
agent.update(arm, reward)
# ログ記録
rewards.append(reward)
# リグレット = (最適なアームの真の確率 - 選んだアームの真の確率)
regret = env.optimal_prob - env.true_probs[arm]
regrets.append(regret)
return np.cumsum(regrets)
# 設定
n_steps = 1000
# Epsilon-Greedy (epsilon=0.1)
agent_eg = EpsilonGreedyAgent(n_arms=5, epsilon=0.1)
regret_eg = run_simulation(agent_eg, env, n_steps)
# Thompson Sampling
agent_ts = ThompsonSamplingAgent(n_arms=5)
regret_ts = run_simulation(agent_ts, env, n_steps)
アルゴリズム間の性能比較プロット作成
この結果を可視化することで、どちらのアルゴリズムが優秀かが一目瞭然になります。
plt.figure(figsize=(10, 6))
plt.plot(regret_eg, label='Epsilon-Greedy (eps=0.1)')
plt.plot(regret_ts, label='Thompson Sampling')
plt.xlabel('Steps')
plt.ylabel('Cumulative Regret')
plt.title('Exploration Strategy Comparison')
plt.legend()
plt.show()
一般的に、Thompson Samplingの方がリグレットの増加が緩やか（＝早期に正解を見つけ、損失を抑えている）になる傾向があります。このグラフをチーム内で共有すれば、「なぜ探索アルゴリズムが必要か」「どのアルゴリズムを採用すべきか」の説得材料になります。
6. よくある実装トラブルとパラメータチューニング
シミュレーター上ではうまくいっても、実務データに適用しようとするといくつかの壁にぶつかります。データ分析や業務プロセス改善の専門家である私の視点から、実運用に向けて乗り越えるべき技術的課題と具体的な対策を解説します。
探索不足による局所解への収束対策
Epsilon-Greedy法でよくあるのが、初期の数回のラッキーなクリックにより、たまたま成績が良かっただけの劣ったアイテムに収束してしまう現象です。
対策としては、「初期値の楽観的設定（Optimistic Initialization）」が有効です。valuesの初期値を0ではなく、例えば1.0や5.0といった高い値にしておくことで、すべてのアイテムが一度は「試される」ようになります。
非定常性（ユーザー好みの変化）への対応設定
ユーザーの興味は時間とともに変化します。夏にはプールが人気でも、冬には温泉が人気になります。しかし、上記の単純な実装では、過去の全データを平等に扱って平均化するため、変化への追従が遅れます。
これに対応するには、「スライディングウィンドウ法」や「割引率（Discount Factor）」を導入します。
# 割引率を用いた更新例
def update_with_decay(self, arm_index, reward, gamma=0.99):
# 既存の値を少し忘れる（減衰させる）
self.counts *= gamma
self.values *= gamma
# ...（以下通常の更新）
このように過去の記憶を徐々に薄れさせることで、直近のトレンドに敏感なレコメンドが可能になります。
7. 次のステップ：実サービス連携に向けて
オフラインでの検証が済んだら、いよいよ実サービスへの組み込みを検討します。
APIサーバー化への拡張手順
Pythonで実装したロジックは、FlaskやFastAPIを使って簡単にマイクロサービス化できます。リクエストとしてuser_idを受け取り、アルゴリズムがitem_idを返すAPIを作成します。重要なのは、「推論（select_arm）」と「学習（update）」を非同期にすることです。
- 推論API: リアルタイム性が求められるため、現在のパラメータを使って即座にレスポンスを返す。
- 学習ワーカー: ユーザーの行動ログ（クリック/コンバージョン）をキューに貯め、定期的に（例えば10分ごとや1時間ごとに）ベータ分布のパラメータや平均値を更新する。
ログ基盤との連携設計
強化学習において最も重要な資産は「探索ログ」です。通常のアクセスログに加え、以下の情報を必ず記録してください。
- Action: どのアイテムを推薦したか
- Probability: そのアイテムを選んだ時の確率はいくらだったか（Off-policy評価で必須になります）
- Reward: 結果はどうだったか
これらが揃っていれば、後から別のアルゴリズムをシミュレーションする「Counterfactual Evaluation（反実仮想評価）」が可能になり、改善のサイクルが高速化します。
まとめ
「探索」を取り入れることは、システムに「好奇心」を持たせるようなものです。それにより、今まで埋もれていた観光スポットや商品が日の目を見ることになります。
今回ご紹介したコードは最小構成ですが、ここからコンテキスト（ユーザー属性）を考慮した「Contextual Bandit」へと拡張していくのが王道です。まずはこのシミュレーターで、パラメータを調整しながら挙動を確認してみてください。
コメント