ブライダルのLINE公式アカウント：来館前・来館後・成約後でリッチメニューを切り替える設計

この記事の内容のご相談は株式会社bundlyzeへbundlyzeのWEB戦略チーム代行について見てみる

ブライダルの業態で、トーク画面の下のメニューを「来館前」「来館後」「成約後」と替えていく仕組みを、実装する立場から書いていきます。前提にしたのはLINEの公式の仕様（確認日 2026-10-02）で、特定の式場の事例は出てきません（扱うのは仕組みの側の話だけ）。

株式会社bundlyzeでは、顧客管理の側とLINE公式アカウントを結ぶ連携を、自社で開発してきました。この記事の判断は、そうした連携を作るときに考えてきたことが元になっています。

式場とお二人の関係は、来館から挙式後まで続く

フィットネスや飲食のように「何度も来てもらう」業態と違い、式場とお二人の関係は一方向に進みます。フェアに来る前は会場を比べている段階、来館した後は見積もりを持ち帰って検討する段階、成約した後は打ち合わせを重ねて当日に向かう段階。段階ごとに、LINEを開いたときに知りたいことがはっきり変わります。

そのため、全員に同じメニューを出し続けると、成約したお二人にはフェアの案内ばかりが並び、検討中のお二人には打ち合わせの入口が並ぶ、というずれが起きます。業種を問わないメニューの置き方は、会社のコラムLINEリッチメニューの設計にまとめているので、ここでは式場ならではの切り替えの作り方に絞ります。

状態を絞り、きっかけと記録する人を決める

最初に、お二人の状態と、状態が変わるきっかけ、それを誰がシステムに記録するかを表にします。

決めておきたいのは次の点です。

• 「来館前」はユーザー単位のメニューを使わない。 友だち追加した直後の人には、デフォルトのメニューを出せば足ります。ユーザー単位で結びつけるのは、状態が進んだ人だけにします
• 見送りになったお二人は、デフォルトに戻す。 結びつけを解除すると、デフォルトのメニューが代わりに表示されます
• メニューは人ごとではなく、状態ごとに作る。 1つのチャネルで作れるリッチメニューは最大1000件です。お二人ごとに名前入りの画像を作るような設計は、上限にも運用にも合いません

2人で1組：ユーザーIDを組にひも付ける

式場の顧客は、多くの場合「お二人」で1件です。LINEは1人ずつ友だち追加するので、顧客の記録の側で、1つの組に複数のLINEのユーザーIDを持てるようにしておきます。

create table couples (
  id           text primary key,
  stage        text not null,   -- before_visit / visit_booked / visited / contracted / after_wedding / closed
  wedding_date date
);

create table couple_line_users (
  couple_id    text not null references couples(id),
  line_user_id text not null unique,  -- Webhook の source.userId
  added_at     timestamp not null,
  primary key (couple_id, line_user_id)
);

2人目をどう組に入れるかも、先に決めておきます。来館の受付で見せるQRコードから LIFF の画面を開いてもらい、IDトークンをサーバーで検証してから組に加える、という形にすると、他人が勝手に組へ入る心配がありません。画面の側が渡すユーザーIDをそのまま使わないのは、LINEの資料が示しているとおりです。

切り替えは「計算して合わせる」処理を1つだけ持つ

状態が変わるたびに個別にメニューを付け替えるコードを書くと、どこかで付け替え漏れが起きます。そこで、「組の状態から、出すべきメニューを計算し、今のメニューと違えば結びつけ直す」処理を1つだけ作り、いろいろな場面から同じものを呼びます。

const MENU_BY_STAGE: Record<string, string[] | null> = {
  before_visit:  null,                            // デフォルトのメニューに任せる
  visit_booked:  ['richmenu-visit-booked'],
  visited:       ['richmenu-visited'],
  contracted:    ['richmenu-prep', 'richmenu-contact'], // タブで切り替える2枚
  after_wedding: ['richmenu-after'],
  closed:        null,
};

async function syncRichMenu(coupleId: string) {
  const couple = await db.getCouple(coupleId);
  const wanted = MENU_BY_STAGE[couple.stage];
  for (const userId of await db.lineUsersOf(coupleId)) {
    const current = await line.getUserRichMenuId(userId); // GET /v2/bot/user/{userId}/richmenu
    if (wanted === null) {
      if (current) await line.unlinkRichMenu(userId);     // DELETE /v2/bot/user/{userId}/richmenu
      continue;
    }
    // 同じ状態のタブのどれかが出ていれば、合っているとみなす
    if (current && wanted.map(menuIdOf).includes(current)) continue;
    await line.linkRichMenu(userId, menuIdOf(wanted[0])); // POST /v2/bot/user/{userId}/richmenu/{richMenuId}
  }
}

この処理を呼ぶのは、次の3つの場面です。

1. 状態が変わったとき：予約の確定、来館の受付、契約の記録の直後
2. フォローイベントが届いたとき：友だち追加と、ブロック解除の両方
3. 毎晩：挙式日を過ぎた組を「挙式後」に進めたうえで、全組を見直す

ユーザー単位で結びつけたメニューは、その場で表示に反映されます。一方、デフォルト側の変更は、トーク画面に入り直すまで反映されないので、状態ごとのメニューはユーザー単位で結びつけるほうが、切り替わりを確かめやすくなります。

ブロック中の人と、タブの扱いでつまずかない

運用に入ってから崩れやすいのが、次の2つです。

ブロックしている人には、結びつけが効かない。 LINEのリファレンスには、ブロック中や友だちでない人に対して解除を呼ぶと、ステータス200が返っても実際には解除されないと書かれています。複数人に結びつける一括の呼び出しでも、202が返ったうえで、その人たちは対象から外れます。成約の記録を付けたときにお二人の片方がブロックしていた、ということは起こりえます。だからこそ、フォローイベント（follow.isUnblocked が付いて届くブロック解除を含む）で、同じ同期の処理を呼び直します。

タブで切り替えたメニューを、同期で戻してしまう。 成約後のメニューを「準備」と「連絡」の2枚に分け、リッチメニューエイリアスと切り替えのアクションでタブにする場合、タブを押すたびに、その人に結びついたメニューが別のものに替わります。同期の処理が「準備のメニューでなければ結びつけ直す」と書かれていると、連絡のタブを開いた直後に、毎晩の処理が準備のタブへ戻してしまいます。上のコードのように、同じ状態に属するメニューのどれかが出ていれば「合っている」とみなすようにしておきます。

まとめて替える場面では、APIを使い分ける

1組ずつ替える場面と、まとめて替える場面では、使うエンドポイントと注意点が違います。

季節の差し替えは、新しいメニューを作り、画像を付けて、テスト用のアカウントに結びつけて見た目を確かめてから、一括操作で置き換えます。置き換えた後、古いメニューを消すのは、一括操作の進み具合を取得して完了を見てからにします。

メニューの画像には、お二人の情報を入れない

状態ごとのメニューは、同じ状態の全員に同じ画像が出ます。挙式日までの日数や、お二人の名前を画像に入れたくなりますが、それは状態ごとのメニューでは作れませんし、作るべきでもありません。

個別の情報は、メニューのボタンから開く LIFF の画面に出します。画面を開いたときにIDトークンをサーバーで検証し、その人が属する組の情報だけを返します。打ち合わせの日時や見積もりのように、お二人以外に見えてはいけない情報は、この形でしか出さない設計にします。

公開前に確かめること

状態ごとのメニューを本番のアカウントで動かす前に、テスト用のアカウントで次の項目を確かめます。どれも本文の節で扱ったつまずきやすい所です。

• 状態と記録する人：5つ前後の状態ごとに、変わるきっかけと、記録する人（受付・担当のスタッフ・自動の処理）が決まっている
• お二人の2人目：後から友だち追加した2人目が、IDトークンの検証を通って組に加わり、その時点の状態のメニューが出る
• ブロック解除：ブロック中に状態が進んだ人が、ブロックを解除したときのフォローイベントで正しいメニューに替わる
• タブ：成約後のタブを切り替えたあと、毎晩の処理を流しても、開いていたタブが元に戻されない
• 見送り：見送りになった組の結びつけを解除すると、デフォルトのメニューが出る
• まとめての切り替え：複数人への結びつけのあと、1人分ずつ取得して結びついたことを確かめる手順がある
• 画像の中身：メニューの画像に、お二人の名前や日付などの個別の情報が入っていない

自社でやる場合と、任せる場合

自社で進める場合は、Messaging API と LIFF を使った開発と、Webhook を受けるサーバーの運用ができる人が要ります。あわせて、来館の受付や契約の記録を顧客の記録に付けるスタッフの操作を決め、状態が変わったときに確実に記録される流れを作る必要があります。季節ごとのメニューの差し替えでは、画像の制作と、テスト用のアカウントでの確認、一括操作の完了の確認までを、誰がいつやるかも決めておきます。

任せる場合、株式会社bundlyzeでは、外部のWeb責任者として結婚式場のWeb集客の戦略から実行・分析までを受け持っています。大阪・兵庫を中心とした関西のほか、遠方のご相談もオンラインでお受けしています。状態の決め方から、顧客の記録とメニューの切り替えをつなぐ開発までを一緒に進めたい場合は、WEB戦略代行のページで受け持つ範囲を紹介しています。

出典（一次情報）

LINEの公式資料です。記載はすべて 2026-10-02 時点で確かめたものです。

• ユーザー単位で出すメニュー（LINE Developers の解説）（即時の反映、解除するとデフォルトが表示される）
• メニューの表示の優先順位と反映（LINE Developers の解説）（表示の優先順位、反映されるタイミング）
• エイリアスを使ったタブ（LINE Developers の解説）（エイリアスと切り替えのアクション）
• Messaging API の仕様一覧（LINE Developers のリファレンス）（作成の上限1000件、複数人への結びつけは最大500人で非同期、一括操作は1時間に3回・resumeRequestKey は14日、ブロック中の人の扱い、follow.isUnblocked）
• LIFF で利用者を確かめる（LINE Developers の解説）（IDトークンを送り、受け取った側で検証する）
• 管理画面でのメニューの作り方（LINEヤフーの事業者向けマニュアル）（管理画面で作るメニュー）