LINE データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ
目次 クリックで開く
LINE専用ツールは不要。データ基盤から直接駆動する「動的リッチメニューとキャンペーンモジュール」のアーキテクチャ
こんにちは。Aurant Technologiesの近藤義仁です。
LINE公式アカウントの運用フェーズが進むと、企業は「デジタル会員証」「スタンプカード」「アンケート機能」「ガチャ等のエンタメコンテンツ」といった、ユーザーのエンゲージメントを高めるための施策を企画します。また、リッチメニューから遷移させる「専用のランディングページ（LP）」を用意することもあります。
この際、多くの企業が「会員証アプリ作成SaaS」や「LINEキャンペーン構築ツール」といった外部のパッケージを個別に導入しようとします。しかし、ツールごとにデータが分断されることで、「実店舗で会員証を提示してくれた優良顧客が、自社のWebサイトで何を見ているか」がシステム上で繋がらず、結果的にデータのサイロ化と運用保守コストの増加を招きます。
本日は、パッケージツールに依存するのではなく、自社のDWH（BigQuery）とLIFF（LINE Front-end Framework）を組み合わせ、会員証やスタンプカード、リッチメニューの動的切り替えから各種キャンペーンまでを「モジュール（部品）」として自社基盤上で構築・制御するアーキテクチャについて解説します。
1. LINE拡張ツールが引き起こす「データのサイロ化」
「LINEで会員証やスタンプカードを実施したい」という要件に対し、単一機能のSaaS（あるいはLINE拡張パッケージ）を導入するアプローチには、データアーキテクチャの観点から明確な課題が存在します。
① トラッキングとCRMの分断
外部ツール内で実行された会員バーコードの表示やアンケート回答、スタンプ付与履歴は、そのツールのデータベース内に保存されます。これをSalesforce（CRM）や自社のWeb行動ログ（BigQuery）と紐付けようとすると、別途CSVでのバッチ連携や複雑なAPI開発が必要になり、行動をトリガーにしたリアルタイムな施策への活用が困難になります。
② UI/UXの柔軟性の欠如
パッケージツールの提供する定型フォーマットに従わざるを得ないため、自社のブランドガイドラインに沿ったUIの構築や、自社の基幹システム（POSレジや在庫システム）と連動したリアルタイムな情報表示といった拡張性が大きく制限されます。
2. 顧客の「状態」に基づくリッチメニューの動的制御
キャンペーンやシナリオの起点となるのが、LINEのトーク画面下部に表示される「リッチメニュー」です。これを全ユーザー一律のメニューにするのではなく、顧客のステータス（会員ランク、未購入、特定キャンペーン参加中など）に応じて動的に切り替える仕組みを構築します。アーキテクチャの構造
リッチメニューの切り替え判定は、外部ツールではなく自社のDWH（BigQuery）で行います。
| システムコンポーネント | 役割とデータフロー |
|---|---|
| 1. BigQuery + dbt （判定エンジン） |
「CRM上の購買データ」と「Webの行動ログ」をSQLで結合し、各LINE UIDが「どのステータスに属するか（例：初回購入前、VIP顧客）」を定期的に計算してデータマートを生成する。 |
| 2. リバースETL （データ抽出・連携） |
Hightouch等のツールがBigQuery内のステータス変更（差分）を検知し、LINE Messaging APIへリクエストを送信する。 |
| 3. LINE Messaging API （実行エンジン） |
Rich Menu APIのエンドポイントを叩き、対象のLINE UIDに対して事前に作成済みの「該当ステータス用のリッチメニューID」を紐付ける（リンクする）。 |
LINE Developers公式：ユーザーごとのリッチメニューの指定
Messaging APIを使用すると、デフォルトのリッチメニューとは別に、特定のユーザー（LINE UID）に対して個別のリッチメニューを紐付けることができます。これにより、ユーザーの属性やアクションに応じたパーソナライズされたメニュー表示が可能になります。
（出典：LINE Developers – リッチメニューを使用する）
3. コンポーザブルに構築する「機能モジュール」
専用ツールを使わず、自社のフロントエンド（LIFF）とバックエンドAPI、そしてBigQueryを組み合わせることで、拡張性の高い施策モジュールを実現します。① デジタル会員証（オン/オフラインの購買データ統合）
実店舗での顧客接点となる「会員証（バーコード/QRコード）」をLIFFアプリとして構築します。
ユーザーがリッチメニューから会員証を開くと、サイレントログインにより即座にLINE UIDが自社APIへ送られ、バーコードが生成・描画されます。店舗のPOSレジでこのバーコードを読み取ることで、**「どのLINEアカウントのユーザーが、いつ、どの店舗で何を買ったか」**というオフラインの購買データが直接自社データベースに連携されます。現在の保有ポイント数や会員ランクも、基幹システムから自社API経由でLIFF上にリアルタイムで表示可能です。
② クロスチャネル・スタンプカード（来店・オンライン行動の統合）
会員証機能と連携し、特定のアクションに対するリワードとして機能するスタンプカードもLIFFで構築します。
自社基盤で構築する最大の利点は「オンラインとオフラインのアクションを横断してスタンプを付与（データ統合）できる点」です。店舗のPOSレジを通じた購入だけでなく、特定のLP閲覧やウェビナー参加といったオンラインのイベントログも、BigQuery上で同一のLINE UIDに紐付けられ、スタンプとして還元されます。さらに、「スタンプが残り1つで満了する顧客」をdbtで抽出し、来店促進のPushメッセージを自動配信するといったデータ連動型のリテンション施策が可能になります。
③ LIFFベースのパーソナライズドLP（ランディングページ）
リッチメニューから遷移させるLPを、外部ブラウザではなくLIFFアプリとして構築します。
外部ブラウザに飛ばすとCookie規制（ITP）やログインの壁（摩擦）が生じますが、LIFFであれば開いた瞬間にLINE UIDを確実かつセキュアに取得できます。このUIDをキーとして自社API経由でBigQueryやSalesforceのデータを即座に参照し、「そのユーザーの過去の購入履歴に基づくおすすめ商品」や「会員ランクに応じた限定バナー」などをLP上にリアルタイムに描画（パーソナライズ）することが可能になります。また、LP内での詳細な行動ログも欠損なくBigQueryに格納されます。
④ アンケート配信（ゼロパーティデータの取得）
ユーザーの趣味嗜好などを直接聞くアンケートも、LIFF上にWebフォームとして構築します。
送信された回答データ（ゼロパーティデータ）は自社API経由で直接BigQueryへ格納され、CRMデータと統合されます。統合されたデータに基づき、「アンケート回答者」というフラグが立ち、前述のアーキテクチャによってリッチメニューが「回答完了者向け」へ自動的に切り替わります。
⑤ ガチャ・アドベントカレンダー（エンターテインメント・継続アクセス）
ゲーム性を持たせたキャンペーンや、特定の期間中毎日LINEを開かせるアドベントカレンダーも、LIFFアプリとして自社開発します。
- フロントエンド（LIFF）： 演出アニメーションや結果画面を描画します。
- バックエンド（自社API）： 「誰に何のインセンティブを付与するか」の抽選・判定ロジックを処理します。不正な連続参加を防ぐため、LINE UIDをキーに厳密な判定を行います。
- データ蓄積： 日々のアクセスログや抽選結果はBigQueryへ格納され、dbtを用いた「連続〇日アクセス達成」の判定や、その後のシナリオ配信のトリガーとして再利用されます。
4. 状態（ステータス）駆動型のステップ・シナリオ配信
会員証の提示履歴、スタンプ付与履歴、アンケート回答、LIFF製LPでの行動ログがすべてBigQueryに集約されることで、従来の「友だち登録から〇日後」という単純な時間ベースのステップ配信から脱却できます。ステータス移行をトリガーとする設計
DWHを中心としたアーキテクチャでは、「顧客の状態（ステータス）」が変化した瞬間をトリガーとしてLINE Messaging APIを駆動させます。
- 実店舗で会員証を提示し、初めて特定ブランドの商品を購入した翌日に、そのブランドのメンテナンス方法をPush配信。
- アンケートで「Aカテゴリに興味あり」と回答した直後に、関連する詳細情報をPush配信。
- スタンプカードが満了した瞬間に、VIP向けのリッチメニューへ切り替え、専任の案内メッセージを配信。
こうしたクロスチャネルの集計を要する複雑な判定も、BigQuery内のSQLであれば柔軟にモデル化でき、データの分断を防ぐことができます。
5. キャンペーンとCRM統合のデータフロー（全体図）
LIFFを活用した各モジュールの実行から、DWHでの判定、そしてリッチメニューの切り替えやPush配信に至るシステム全体のデータフローを俯瞰します。
ユーザーがLINE上のリッチメニュー等から「会員証」「スタンプカード」「アンケート」等のLIFFアプリを起動。
BigQuery内でdbt（データモデリング）が稼働。
連携ツールがSTEP 2のステータス変更（差分）を検知します。
リバースETLからAPIが実行されます。
まとめ：キャンペーンは「データを集積・活用するための部品」
「新しいLINE施策をやりたいから、専用のパッケージツールを導入しよう」というアプローチを繰り返すと、システムは複雑化し、データは各ツールにサイロ化してしまいます。 重要なのは、**「自社のDWH（BigQuery）を中心に据え、LIFFアプリ（フロントエンド）やリバースETLを『モジュール（部品）』として自由に組み合わせる」**というコンポーザブルな設計思想です。このアーキテクチャを採用することで、一度構築したデータ基盤の上で、会員証、スタンプカード、パーソナライズされたLP、アンケート、ガチャ、シナリオ配信といったあらゆる施策を、データの分断なくスケーラブルに展開・追加していくことが可能になります。
- 「複数のLINEツールを導入しており、データの統合やコスト管理に限界を感じている」
- 「POSの購買データやWebの行動ログを組み合わせて、柔軟にリッチメニューを出し分けたい」
- 「DWH（BigQuery）を中心とした、コンポーザブルなCRMアーキテクチャを構築したい」
【無料相談】貴社の会員データは、CRMに統合されていますか？
施策の実行からデータ基盤の設計まで、全体のアーキテクチャを診断する「CX to Backoffice 構造診断」を実施中です。お問い合わせはこちら
