アソシエーション分析で
クロスセルに変える
「この商品を買った人は、こんな商品も買っています」——EC サイトでよく見るこの一文の裏側にあるのがアソシエーション分析（バスケット分析、連関分析、マーケットバスケット分析とも呼ばれます）です。購買データやページ閲覧ログから「一緒に発生しやすい組み合わせ」を見つけ出し、クロスセル・レコメンド・商品陳列に使える形で数値化します。
機械学習の分類・回帰と違い、アソシエーション分析には正解ラベルが要りません。購買履歴やセッションログをそのまま投入するだけで、「Aと一緒にBが買われる割合」のようなルールを自動で洗い出せる、教師なし学習の一種です。データ分析の手法全体の中でどこに位置づく手法かは、別記事で整理しています。あわせてご覧ください。
データ分析アルゴリズム全体図
アソシエーション分析を含む代表的な分析手法の全体像です。
アソシエーション分析の実務価値は、「よく一緒に出てくる」を「偶然でない、意味のある組み合わせ」まで絞り込めることです。単に同時購入回数を数えるだけでは、そもそも人気商品同士がたまたま一緒に出てくるだけのケースと区別できません。support（出現頻度）・confidence（条件付き確率）・lift（偶然からのズレ）の3指標を組み合わせて読むことで、クロスセルに使える組み合わせだけを抽出できます。
- アイテムセット：「パンとバター」のような商品（アイテム）の組み合わせ。
- support（支持度）：全取引のうち、そのアイテムセットを含む取引の割合。
- confidence（確信度）：「A→B」というルールで、Aを含む取引のうちBも含む割合（条件付き確率）。
- lift（リフト値）：confidence が「Bの単独出現率」と比べて何倍高いか。1より大きいほど、AとBが偶然以上に一緒に出現している。
- Apriori アルゴリズム：頻出アイテムセットを効率よく探索する代表的なアルゴリズム。
- マーケットバスケット分析：アソシエーション分析を小売・EC の購買データに適用したときの呼び方。指すものはほぼ同じ。
01.結論：『一緒に買われるもの』を数値化してクロスセルに使う
アソシエーション分析がマーケティングで使われる理由はシンプルです。「何が売れるか」ではなく「何と何が一緒に売れるか」を数字にできるため、レコメンド表示・セット販売・商品陳列・クーポン設計に直接転用できます。
| 指標 | 答える問い | 実務での使い方 |
|---|---|---|
| support（支持度） | その組み合わせはどれくらいの頻度で起きるか | 在庫・陳列スペースを割く価値があるか（頻度が低すぎる組み合わせは対象外） |
| confidence（確信度） | Aを買った人のうち、何%がBも買うか | 「Aの購入画面でBをレコメンドする」ときの的中率の目安 |
| lift（リフト値） | その組み合わせは『偶然』よりどれだけ起きやすいか | 単に人気商品同士なだけの組み合わせを除外し、本当に相性の良い組み合わせだけ残す |
02.3つの指標｜support・confidence・liftの読み方
3指標はそれぞれ役割が違い、どれか1つだけでは判断を誤ります。具体的な取引データで計算しながら確認します。
図：5件の取引から support・confidence を数える
「パン」を含む取引は3件（取引1・2・4）、「パンとバター」を両方含む取引は3件。「パンを買った人がバターも買う」確率（confidence）は 3/3 = 100%。
オレンジ塗り = パン／オレンジ枠 = バター。support(パン) = 3/5 = 60%、support(パン∩バター) = 3/5 = 60%、confidence(パン→バター) = 60% / 60% = 100%。
support・confidence・lift は、それぞれ次の式で計算します（A, B はアイテムセット、N は全取引数）。
| 指標 | 計算式 | 先の例での値 |
|---|---|---|
| support(A) | Aを含む取引数 ÷ 全取引数 N | support(パン) = 3 ÷ 5 = 60% |
| support(A∩B) | AとBを両方含む取引数 ÷ N | support(パン∩バター) = 3 ÷ 5 = 60% |
| confidence(A→B) | support(A∩B) ÷ support(A) | confidence(パン→バター) = 60% ÷ 60% = 100% |
| lift(A→B) | confidence(A→B) ÷ support(B) | support(バター)=60%なので lift = 100% ÷ 60% ≒ 1.67 |
confidence(A→B) が高くても、B がそもそも全体でよく売れる人気商品なら、A と関係なく高い数字が出ます。lift はこの「Bの単独人気」の影響を取り除いた指標で、1を上回るほど「AとBが偶然以上に一緒に出現している」、1を下回るなら「むしろ一緒には出にくい」ことを意味します。lift が1に近い、または1未満の組み合わせは、いくら confidence が高くてもクロスセル施策の根拠にしないのが安全です。
全取引数とA・Bの件数を入れ替えながら、support・confidence・liftがどう変わるかをその場で確認できます。
全取引数とA・B・A∩Bの件数を入れると、support・confidence・liftをその場で計算します（ブラウザ内で計算、サーバー送信なし）。
円の重なりはパンとバターを両方含む取引の相対的な多さ（confidenceの高さ）を模式的に示したもので、面積を厳密に一致させたものではありません。
同じ傾向の取引が100件あったとすると、パンだけを含む取引が0件、バターだけを含む取引が0件、パンとバター両方を含む取引が60件、どちらも含まない取引が40件という内訳になります。
03.Apriori アルゴリズム｜組み合わせ爆発を防ぐ仕組み
商品点数が100種類あれば、2つの組み合わせだけで4,950通り、3つの組み合わせも含めると数十万通りに膨れ上がります。すべてを総当たりで計算するのは現実的でないため、Apriori アルゴリズムという絞り込みの仕組みが使われます。
Apriori の中心にあるのは「頻出でないアイテムセットの上位集合は、必ず頻出でない」という性質（アプリオリ性質）です。たとえば「パン単体」の support が最低ラインを下回るなら、「パンとバター」「パンとバターと牛乳」のような、パンを含むどの組み合わせも最低ラインを超えることはありません。この性質を使って、1個の組み合わせから順に support の低いものを枝刈りしながら、2個、3個と候補を絞り込んでいきます。
| 手順 | やること | 備考 |
|---|---|---|
| 01. 最低support（min_support）を決める | 「全取引の1%以上で出現」のように足切りラインを設定 | 低すぎると計算量が爆発、高すぎると重要な組み合わせを見逃す |
| 02. 1個のアイテムセットを絞り込む | 単体で min_support を超えるアイテムだけ残す | 残った候補だけが次のステップに進む |
| 03. 2個の組み合わせを絞り込む | 01で残ったアイテム同士の組み合わせだけを候補にし、min_supportで再度足切り | 全組み合わせを計算しないため高速 |
| 04. 3個以上も同様に繰り返す | 候補が尽きるまで組み合わせのサイズを増やす | 実務では2〜3個の組み合わせまでで十分なことが多い |
| 05. confidence・lift でルールを絞る | 頻出アイテムセットから、min_confidence・min_liftを満たすルールだけ抽出 | この段階で初めて「A→B」という方向を持ったルールになる |
Apriori は候補生成と検証を繰り返すため、データ量やアイテム種類が多いと計算量が増えます。FP-Growth というアルゴリズムは、木構造（FPツリー）にデータを一度圧縮してから頻出パターンを探すため、候補の総当たりを避けられ、大規模データでは Apriori より高速に動作することが多いとされています。mlxtend ライブラリはどちらも同じインターフェースで使えるため、データ量が大きい場合は fpgrowth 関数に切り替えるだけで対応できます。
ロジスティック回帰（BigQuery MLのLOGISTIC_REG）や協調フィルタリング（同MATRIX_FACTORIZATION）と違い、GoogleのBigQuery MLが提供するモデルタイプにも、AWSのSageMaker Canvasのようなノーコードサービスにも、Apriori・FP-Growthに相当するアソシエーションルール抽出の機能は用意されていません。実務では、本記事のmlxtend（Python）のようなライブラリでコードを書くか、KNIME・Orange・RapidMinerのようなノーコード/ローコードの分析ツールを使うのが現実的な選択肢になります。
04.実務ユースケース｜クロスセル・商品陳列・レコメンド
アソシエーション分析は EC・小売の購買データが典型ですが、Web サイトのページ閲覧ログや、SaaS の機能利用ログにも同じ考え方をそのまま適用できます。
| 業種・領域 | アイテムセットの中身 | 活用例 |
|---|---|---|
| EC・小売 | 1回の注文に含まれる商品 | 商品詳細ページの「よく一緒に購入されている商品」表示、セット割引の設計 |
| 実店舗 | 1回のレジ通過（POSデータ）に含まれる商品 | 併売率の高い商品を近くに陳列、レジ横の関連商品配置 |
| コンテンツ・オウンドメディア | 1セッションで閲覧されたページ | 「一緒に読まれている記事」表示、内部リンク設計、回遊導線の見直し |
| SaaS プロダクト | 1顧客が利用している機能 | オンボーディング時に組み合わせで使われやすい機能を先に案内、アップセル提案 |
| メール・LINE配信 | 1配信で反応（クリック）したコンテンツ | 反応が連動しやすいコンテンツ同士を同じ配信にまとめる、配信セグメントの設計 |
lift が高いルールをそのまま並べても、粒度が細かすぎたり在庫・表示枠の制約で実装できないことがあります。実務では次の3段階で施策に落とし込みます。
- lift 上位でルールを抽出する
- confidence が一定以上（レコメンドとして提示しても外れにくい水準）に絞る
- 商品カテゴリ単位でグルーピングして実装可能な粒度に調整する
表の「商品同士の組み合わせ」は全体傾向の抽出にとどまり、個人ごとのパーソナライズはできません。個人単位でレコメンドを出したい場合や、購買データから顧客をグループ分けしたい場合は、それぞれ別記事で扱っています。
協調フィルタリング
購買・閲覧履歴から個人向けにレコメンドを出す、もう1つの代表的な手法です。
クラスタリング・顧客セグメンテーション
顧客をグループ分けする教師なし学習のもう1つの代表例です。
05.実装例（Python: mlxtend）
Python では mlxtend ライブラリの apriori と association_rules で、取引データからルール抽出まで数行で完結します。
# mlxtend でアソシエーション分析
import pandas as pd
from mlxtend.frequent_patterns import apriori, association_rules
from mlxtend.preprocessing import TransactionEncoder
# transactions: 取引ごとの購入商品リスト
transactions = [
["パン", "バター", "牛乳"],
["パン", "バター"],
["卵", "牛乳"],
["パン", "バター", "卵"],
["牛乳", "卵"],
]
# One-Hotエンコーディング（取引 x 商品 のブール行列に変換）
te = TransactionEncoder()
te_array = te.fit(transactions).transform(transactions)
df = pd.DataFrame(te_array, columns=te.columns_)
# 頻出アイテムセットの抽出（support >= 20%）
frequent_itemsets = apriori(df, min_support=0.2, use_colnames=True)
# アソシエーションルールの抽出（confidence >= 50%）
rules = association_rules(frequent_itemsets, metric="confidence", min_threshold=0.5)
rules = rules.sort_values("lift", ascending=False)
print(rules[["antecedents", "consequents", "support", "confidence", "lift"]])
# antecedents consequents support confidence lift
# (パン) (バター) 0.6 1.00 1.67 ← liftが最も高い＝偶然以上に相性が良い大規模データで計算が重い場合は、apriori を fpgrowth に差し替えるだけで同じ結果をより高速に得られます（from mlxtend.frequent_patterns import fpgrowth）。
06.落とし穴｜相関と因果の混同、レア商品の見落とし
アソシエーション分析は手軽に導入できる分、誤った使い方も起きやすい手法です。代表的な2つの落とし穴を押さえておきます。
「AとBが一緒に売れる」という結果は、Aを買うとBが欲しくなる（真の因果関係）だけでなく、季節性・同時期のキャンペーン・同じ棚に並んでいるといった共通の原因で説明できる場合があります。夏場に「アイス」と「かき氷シロップ」が一緒に売れるのは、片方が原因というより両方とも気温という共通要因で動いているだけかもしれません。因果関係を確かめたい場合は、因果推論の実務で扱うような手法や、実際にレコメンドを出し分けたA/Bテストでの検証が必要です。
因果推論の実務
『一緒に売れている』が因果関係かどうかを確かめる手法を整理しています。
min_support を全カテゴリで一律に高く設定すると、購入頻度は低いが利益率の高い高単価商品の組み合わせがすべて足切りされてしまいます。カテゴリ別に閾値を分ける、あるいは support ではなく lift の高さを優先して候補を残す運用にすると、ニッチだが相性の良い組み合わせを取りこぼしにくくなります。
07.よくある質問（FAQ）
アソシエーション分析とバスケット分析は同じものですか？
指しているものはほぼ同じです。アソシエーション分析（連関分析）が手法そのものの名称で、それを小売・ECの購買データに適用したときに「マーケットバスケット分析」「バスケット分析」と呼ぶのが一般的です。Webサイトの閲覧ログや機能利用ログなど、購買以外のデータに使う場合は「アソシエーション分析」と呼ぶことが多くなります。
support・confidence・liftのうち、最も重視すべき指標はどれですか？
目的によりますが、クロスセル施策の根拠にするなら lift を優先するのが安全です。confidence だけで判断すると、そもそも人気な商品に引っ張られて「実は特別な相性ではない組み合わせ」を拾ってしまいます。support は足切りライン（計算対象に含めるかどうか）として使い、最終的な優先順位づけは lift で行うのが実務的な組み合わせです。
min_supportやmin_confidenceの閾値はどう決めればよいですか？
決まった正解値はなく、データ量と目的から逆算します。まずは低めの閾値（support 1〜5%程度）で試し、抽出されたルールの数が多すぎれば閾値を上げる、少なすぎれば下げるという調整を繰り返すのが定番です。カテゴリによって取引頻度が大きく異なる場合は、カテゴリ別に閾値を分けることも検討します。
アソシエーション分析と協調フィルタリングはどう違いますか？
アソシエーション分析は「商品同士の組み合わせ」を全体傾向として抽出する手法で、個人ごとのパーソナライズは行いません。一方、協調フィルタリングは「似た行動を取るユーザー」を手がかりに、個人単位でレコメンドを出す手法です。商品陳列やセット販売の設計にはアソシエーション分析、個人向けのレコメンド表示には協調フィルタリングが向きます。
08.まとめ
アソシエーション分析（マーケットバスケット分析）は、購買データやページ閲覧ログから「一緒に発生しやすい組み合わせ」を、support・confidence・lift の3指標で数値化する教師なし学習の手法です。Apriori（または FP-Growth）で組み合わせ爆発を抑えながら候補を絞り込み、lift を優先して偶然でない相性の良い組み合わせだけをクロスセル・レコメンド・商品陳列に落とし込みます。相関と因果を混同しないこと、レア商品の見落としに注意することが、実務で使いこなす鍵になります。
アソシエーション分析を使ったクロスセル・レコメンド設計の伴走支援を行っています
弊社ではAIフル活用のデータ分析支援を提供しています。購買・閲覧ログからのルール抽出、クロスセル施策への落とし込み、A/Bテストでの効果検証まで、実データで伴走しながら整えています。お気軽にお問い合わせください。
