RFM 分析は、注文データの3列（顧客ID・注文日・金額）から RFM（R=最終購入日の近さ、F=購入回数、M=購入金額）を出し、「最後にいつ買ったか」「何回買ったか」「いくら買ったか」で顧客を分ける方法です。R と F を3段階のスコアにすると顧客は9つのマスに分かれ、マスごとの人数と売上を並べると、全員配信がどこに通数を使っているかが見えます。1,000人のサンプルでは、91日以上買っていない1回購入者が人数の40%を占める一方、売上では17%でした。計算は AI に任せるか、スプレッドシートの関数で行い、結果をセグメントごとのユーザーID の一覧にして LINE のオーディエンスに渡します。
この記事で明らかにすること
- 計算に必要な3列と、R・F・M を3段階に区切る閾値
- AI にそのまま貼れる計算プロンプト（渡すデータの例・結果の例つき）と、AI を使わずにスプレッドシートで計算する手順
- 9マスの人数と売上の並べ方（サンプル 1,000人での計算結果）
- 9マスを配信セグメントにまとめ、LINE のオーディエンスに渡す手順と、運用で気をつけること
数値例は、乱数で生成した 1,000人・3,113件のサンプルデータで実際に計算した結果です。
必要なデータは「顧客ID・注文日・金額」の3列
「全員配信をやめてセグメントで送ろう」と決めたものの、誰をどう分ければよいかの基準がない。注文データはカートシステムから出せる。そうした状況で最初に使える分け方が RFM 分析です。
RFM は次の3つの指標で顧客を見る方法です。
| 指標 | 意味 | 計算に使う列 |
|---|---|---|
| R（Recency） | 最後に買ってから何日経ったか | 顧客ID、注文日 |
| F（Frequency） | 期間内に何回買ったか | 顧客ID、注文日 |
| M（Monetary） | 期間内にいくら買ったか | 顧客ID、金額 |
注文明細（1行 = 1注文）に顧客ID・注文日・金額があれば計算できます。商品名や配送先は不要です。集計の期間は「直近365日」にします。期間を区切らないと、数年前の大口購入が M を押し上げたままになるためです。
R（最終購入日の近さ）・F（購入回数）・M（購入金額）をどう区切るか
区切り方は2通りあります。
| 方式 | やり方 | 向く場面 |
|---|---|---|
| 閾値 | 「30日以内」「5回以上」のように固定の値で区切る | 運用担当が基準を説明しやすい。月をまたいでも同じ基準で比較できる |
| 分位 | 上位20%・次の20%…のように人数で等分する | 顧客数が多く、分布が変わりやすい場合 |
この記事は閾値で進めます。基準を3段階にし、次の値を使います。
| スコア | R（最終購入からの日数） | F（365日の購入回数） | M（365日の購入金額） |
|---|---|---|---|
| 3 | 30日以内 | 5回以上 | 30,000円以上 |
| 2 | 31〜90日 | 2〜4回 | 10,000〜29,999円 |
| 1 | 91日以上 | 1回 | 10,000円未満 |
値は商材の購入サイクルに合わせて変えます。定期購入が月1回なら R の「30日」は妥当ですが、季節商材なら「90日」「180日」に広げます。最初は仮の値で計算し、各マスの人数を見てから調整する方が早く進みます。
AIに計算させるプロンプト
計算は、注文データの CSV を AI に渡して任せられます。CSV ファイルを読み込んで集計を実行できる AI サービス（ChatGPT や Claude のファイル分析機能など）を使います。
渡すのは、カートシステムから書き出した注文データのうち次の3列だけです。列名は違っていてもかまいません。
| 顧客ID | 注文日 | 金額 |
|---|---|---|
| 1 | 2026-03-19 | 2980 |
| 1 | 2025-12-06 | 7980 |
| 2 | 2026-01-21 | 2980 |
次のプロンプトをそのまま貼り、基準日 の日付だけ実行日に書き換えます。閾値を変えた場合は「スコア」の行も書き換えます。
添付した注文データ（CSV）で RFM 分析をしてください。
## 入力データ
- 1行 = 1注文。列は「顧客ID」「注文日」「金額」の3つ
- 列名が違う場合は、どの列をどれとして扱うかを最初に示してから計算する
- 注文日は日付、金額は円の数値
## 計算のルール
- 基準日: 2026-10-07（この日を「今日」として扱う）
- 集計期間: 基準日の365日前の日付以降の注文だけを使う。期間内に注文がない顧客は対象外
- R（Recency＝最終購入からの日数）: 基準日 − 期間内の最後の注文日（日数）
- F（Frequency＝購入回数）: 期間内の注文件数
- M（Monetary＝購入金額）: 期間内の金額の合計
- スコア（3段階）
- R: 30日以内=3、31〜90日=2、91日以上=1
- F: 5回以上=3、2〜4回=2、1回=1
- M: 30,000円以上=3、10,000〜29,999円=2、10,000円未満=1
- セグメント
- ロイヤル: R=3 かつ F=3
- 安定: R が2以上 かつ F が2以上（ロイヤルを除く）
- 新規: R=3 かつ F=1
- その他: R=2 かつ F=1
- 休眠予備: R=1 かつ F が2以上
- 離脱: R=1 かつ F=1
## 出力してほしいもの
1. 顧客ごとの表（CSV でダウンロードできる形）: 顧客ID、R（日数）、F（回数）、M（円）、Rスコア、Fスコア、Mスコア、セグメント
2. Rスコア × Fスコアの9マスの集計表: R、F、人数、人数の割合、購入金額の合計、金額の割合（R・F とも 3 → 1 の順）
3. セグメントごとの人数と購入金額の合計
## 守ってほしいこと
- 数値は推測せず、データを実際に集計して出す
- 日付として読めない行や金額が空の行は集計から除き、その件数を報告する
- 最後に検算として、9マスの人数の合計が期間内に注文のある顧客数と、金額の合計が期間内の注文金額の合計と一致するかを報告するAI に渡す前に、氏名・メールアドレス・住所などの列は削除し、顧客ID・注文日・金額の3列だけにします。顧客ID も社内の管理番号であれば、それ以上の個人情報は不要です。入力したデータが AI サービス側でどう扱われるか（学習に使われるかどうか）はサービスとプランによって異なるため、社内の利用ルールと合わせて確認します。
サンプルデータ（1,000人・注文 3,113件）で実行すると、セグメントごとの集計は次のように返ってきます。9マスの集計表は、後の節「9マスに分けて、人数と売上を並べる」に載せています。
| セグメント | 人数 | 365日の購入金額合計 |
|---|---|---|
| ロイヤル | 61人 | 2,273,080円 |
| 安定 | 175人 | 4,484,380円 |
| 新規 | 29人 | 162,520円 |
| その他 | 64人 | 408,840円 |
| 休眠予備 | 180人 | 2,827,920円 |
| 離脱 | 336人 | 2,041,760円 |
検算: 期間内に注文のある顧客 845人、期間内の注文金額合計 12,198,500円で、いずれも上の合計と一致。読めない行は 0件。
出典: 自社検証（2026-10-27、サンプルデータ 1,000人・3,113件）。Claude Opus 5.5（Claude Code 上）でこのプロンプトとサンプルデータを使って集計し、9マスの値が SQLite での集計（2026-10-07）と一致することを確認しました。ChatGPT や他のモデルでは確認していません。
AI の集計手順は実行のたびに変わることがあるため、プロンプトに検算の行を入れています。初回は数人分を元データと突き合わせると、ルールの読み違いに気づけます。
AIを使わずにスプレッドシートで計算する手順
AI にデータを渡せない環境では、スプレッドシートの関数で同じ計算ができます。Google スプレッドシートを前提に書きます。Excel でも同じ関数（MAXIFS / COUNTIFS / SUMIFS）が使えます。
- 注文データを「orders」シートに貼る: A列 顧客ID、B列 注文日（日付型）、C列 金額。1行目は見出し
- 「rfm」シートに顧客IDの一覧を作る: A2 に
=UNIQUE(orders!A2:A)を入れる - R を出す: B2 に
=TODAY()-MAXIFS(orders!B:B, orders!A:A, A2)。最終購入からの日数が出る - F を出す: C2 に
=COUNTIFS(orders!A:A, A2, orders!B:B, ">="&(TODAY()-365))。365日以内の注文回数 - M を出す: D2 に
=SUMIFS(orders!C:C, orders!A:A, A2, orders!B:B, ">="&(TODAY()-365)) - スコアに変換する: E2 に
=IFS(B2<=30,3, B2<=90,2, TRUE,1)、F2 に=IFS(C2>=5,3, C2>=2,2, TRUE,1)、G2 に=IFS(D2>=30000,3, D2>=10000,2, TRUE,1) - B2〜G2 を最終行までコピーする
この手順の関数は Google スプレッドシートの仕様に基づいて記載しています。本記事の数値例はスプレッドシートではなく、同じ閾値を SQLite で計算した自社検証の結果です。スプレッドシートで実行した場合の動作は確認していません。結果が一致しない場合は、基準日と集計期間（基準日から365日）が揃っているかを確かめます。
F が 0 の顧客（365日以内に購入がない）は、この記事では対象外にします。休眠の掘り起こしは別の記事で扱います。
9マスに分けて、人数と売上を並べる
R と F をそれぞれ 3 段階にすると 9 マスになります。サンプルデータ（1,000人、365日以内の購入者 845人、注文 3,113件）を基準日 2026-10-07 で計算した結果が次の表です。
| R | F | 人数 | 人数の割合 | 365日の購入金額合計 | 金額の割合 |
|---|---|---|---|---|---|
| 3 | 3 | 61 | 7% | 2,273,080円 | 19% |
| 3 | 2 | 35 | 4% | 626,400円 | 5% |
| 3 | 1 | 29 | 3% | 162,520円 | 1% |
| 2 | 3 | 76 | 9% | 2,716,180円 | 22% |
| 2 | 2 | 64 | 8% | 1,141,800円 | 9% |
| 2 | 1 | 64 | 8% | 408,840円 | 3% |
| 1 | 3 | 5 | 1% | 150,600円 | 1% |
| 1 | 2 | 175 | 21% | 2,677,320円 | 22% |
| 1 | 1 | 336 | 40% | 2,041,760円 | 17% |
出典: 自社検証（2026-10-07、サンプルデータ 1,000人・3,113件）。実在の顧客データではなく、分布は事業によって異なります。サンプルは乱数で生成し、この記事の閾値で SQLite により集計しました。
この表で見るのは「人数が多いマス」と「売上が多いマス」が一致しない点です。R=1・F=1（91日以上買っていない1回購入者）は人数の 40% を占めますが、売上では 17% です。一方で R=2・F=3（31〜90日以内に買っていて、年5回以上買う人）は人数の 9% で売上の 22% を占めます。全員配信は、人数の 4 割を占める前者に同じ通数を使っている状態だと分かります。
配信セグメントに落とす
9 マスのままでは運用しにくいので、マスに名前を付けてまとめます。
| セグメント | 条件 | サンプルでの人数 | 配信の考え方 |
|---|---|---|---|
| ロイヤル | R=3, F=3 | 61人 | 新商品・先行案内。頻度は抑える |
| 安定 | R≧2, F≧2（ロイヤル除く） | 175人 | 定期的な案内。クロスセル |
| 新規 | R=3, F=1 | 29人 | 2回目購入（F2転換）の案内 |
| 休眠予備 | R=1, F≧2 | 180人 | 再購入のきっかけ。配信は月1回程度 |
| 離脱 | R=1, F=1 | 336人 | 配信対象から外すか、別の施策で |
| その他 | R=2, F=1 | 64人 | 新規に準じる |
セグメントが決まったら、配信対象のユーザーID の一覧にします。
- スプレッドシートなら
rfmシートで FILTER（例:=FILTER(A2:A, E2:E=3, F2:F=3)）を使う。AI に計算させた場合は、続けて「ロイヤルの顧客IDだけを1列の CSV で出してください」と頼み、顧客ID を取り出す - 顧客ID を LINE のユーザーID に変換する。ID 連携済みの顧客だけが対象になる
- ユーザーID の一覧を LINE のオーディエンスとして登録する。Messaging API のユーザーIDアップロード用オーディエンスは、JSON で最大 10,000 件、ファイルで最大 1,500,000 件まで登録でき、保存期間は最大 180 日です
- そのオーディエンスを対象にナローキャストで配信する
出典: オーディエンスを使用する（LINE Developers）（2026-10-07 取得）
購買データとLINEをつなぎ、対象別の配信を設計する手順は、購買データから始めるLTV改善ガイドで扱っています。
運用で気をつけること
- 同じ閾値で毎月回す: 閾値を月ごとに変えると、セグメントの人数の増減が施策の結果なのか基準の変更なのか分からなくなります
- M は補助に使う: R×F の 9 マスに M を掛けると 27 マスになり、人数が少なすぎて施策に落とせません。M は「ロイヤルの中で金額が大きい人」のような絞り込みに使います
- 配信対象から外す判断を先に決める: 離脱セグメントに送り続けるとブロックが増え、通数も使います。「何日以上買っていない人には送らない」を基準に含めます
- オーディエンスの有効期限: 180 日で消えるので、毎月の再計算のたびに登録し直す運用にします
まとめ
- RFM（R=最終購入日の近さ、F=購入回数、M=購入金額）は注文データの3列（顧客ID・注文日・金額）だけで計算できる。期間は直近365日に区切る
- 計算は記事中のプロンプトで AI に任せるか、スプレッドシートの関数で行う。AI には3列だけを渡し、検算の結果も報告させる
- 区切りは「閾値」で始める。30日・90日、1回・2回・5回、1万円・3万円を仮の値にして人数を見てから調整する
- R×F の 9 マスで「人数の割合」と「売上の割合」を並べると、全員配信がどこに通数を使っているかが見える
- セグメントは 5〜6 個に名前を付けてまとめ、ユーザーID の一覧にして LINE のオーディエンスに渡す
分けた顧客に「何を・いつ送るか」の決め方は、購買データから始めるLTV改善ガイドで解説しています。