LINEリッチメニューをタブで切り替える方法｜お客さまごとの出し分けと条件設計の考え方
LINEリッチメニューをタブで切り替える方法｜お客さまごとの出し分けと条件設計の考え方
LINE公式アカウントのリッチメニューは、通常「1枚の画像を全員に同じ内容で」表示するものです。ところが実際の運用では、「メニューの中にタブを置いて、タップで画面を切り替えたい」「会員とそれ以外で違うメニューを出したい」という要望がすぐに出てきます。予約・メニュー・アクセスだけなら1枚で足りますが、お客さまの状態によって見せたい情報が変わる業態——美容室、サロン、スクール、会員制サービス——では、1枚のメニューはすぐに手狭になるからです。
先に結論をまとめます。
- タブ切り替えの正体は「リッチメニューを複数作り、タブ部分のボタンに『リッチメニューを変更する』アクションを割り当てる」ことです。1枚の画像の中で表示が切り替わっているのではなく、タップのたびに別のリッチメニューへ差し替わっています
- LINE公式アカウントの標準管理画面には、タップで別のメニューへ切り替えるアクションがありません。実現するには、Messaging APIでの開発か、Lステップ・エルメなどの拡張ツールが必要です
- お客さまごとの出し分けの成否を分けるのは、画像のデザインではなく条件設計です。鉄則は「いまどの状態か」を単一の項目で持って排他的に分岐させること。ここを外すと、メニューが意図しない切り替わり方をしたり、タップしても何も起きないボタンが生まれます
この記事では、graciautoが多店舗展開する美容サロン企業のLINE運用環境（有効友だち約51万人・Lステップ）で、タブ付きリッチメニュー15枚を実際に構築した経験をもとに、タブ切り替えの作り方と条件設計の考え方をまとめます。
タブ切り替えの正体は「複数メニュー＋変更アクション」
まず仕組みの理解からです。リッチメニューのタブ切り替えは、次の2つの部品でできています。
- タブごとに1枚ずつ、別のリッチメニューを作る。「メイン」タブと「会員向け」タブの2タブ構成なら、リッチメニューは最低2枚
- 画像の上部にタブの帯をデザインで描き、その領域にボタンを配置して「リッチメニューを変更する」アクションを割り当てる。「会員向け」タブをタップするとメニューBに差し替わり、メニューB側の「メイン」タブをタップするとメニューAに戻る
つまりタブに見えているのは画像上の描き分けで、実体は「メニューまるごとの差し替え」です。この理解が重要なのは、タブを1つ増やすとリッチメニューが1枚増えるからです。後述しますが、出し分けのパターンを増やすほど、作る画像と管理するメニューの枚数は掛け算で増えていきます。
標準機能でできること・できないこと
LINE公式アカウントの標準管理画面（LINE Official Account Manager)でも、リッチメニューを複数作って期間で切り替えることはできます。月替わりキャンペーンのような時間軸の切り替えは標準で足ります。
できないのは次の2つです。
- タップをきっかけに別のリッチメニューへ切り替える（タブ切り替え）
- 友だち一人ひとりの状態に応じて、違うメニューを出し分ける（セグメント別リッチメニュー）
この2つをやりたくなった時点で、Messaging APIを使った開発か、Lステップ・エルメといった拡張ツールの導入が選択肢になります。ツールを使う場合もプラン条件があり、たとえばLステップでは友だちごとの出し分け（セグメントリッチメニュー）はスタンダードプラン以上です。
実例：51万人アカウントでタブ付きメニュー15枚を構築した
graciautoで実際に構築したのは、メインメニュー1枚＋会員向けの状態別メニュー14枚、合計15枚のタブ切り替え構成です。多店舗展開する美容サロン企業のLステップ本番環境で、お客さまが持つデジタル回数券の券種と残回数の組み合わせ（3券種×残回数）ごとに、別のメニューを表示します。
タブの配置はこうしました。
- 画像サイズは全メニュー共通で2500×1686ピクセル・1MB以下（LINEの仕様上、大きすぎる画像はアップロードできないため、元データが大きい場合は事前に変換します）
- 画像の上部220ピクセル分をタブ帯としてデザインし、メイン側は右上に幅1100×高さ220ピクセルのボタン領域を置いて「会員向けメニューへ変更」を割り当て
- 会員向けメニュー14枚の側にも、同じく上部に幅1100×高さ220ピクセルの「メインに戻る」ボタンを全枚に配置
ここでの実務上のポイントは、往復の動線を必ず両側に作ることです。行きのタブだけ作って戻りを忘れると、お客さまは切り替わった先のメニューから戻れなくなります。14枚それぞれに戻りボタンを置くのは単純作業ですが、1枚でも漏れるとその状態のお客さまだけが行き止まりになるため、構築後に全枚数分のボタン設定を一覧で監査する工程まで含めて「構築」と考えるべきです。
もうひとつ、本番アカウントで作業する場合の安全策として、適用者0人のテスト用メニューを複製して作り込み、実機確認が終わるまで全顧客に適用中の本番メニューには一切手を触れない手順を取りました。51万人に表示されているメニューを直接編集すると、作業途中の中途半端な状態がそのまま全員に見えてしまいます。テスト用メニューをテスト友だち1人に割り当て、タブの往復・条件分岐・表示崩れを実機で確認してから本番へ反映する。この二段構えは、友だち数の多いアカウントほど必須になります。
なお、この実例の「残回数に応じた自動切り替え」の実装詳細はリッチメニューを残回数で自動切替する実装の記事に書いています。本記事では、どんな出し分けにも共通する条件設計の考え方に絞ります。
出し分けは「条件設計」が9割
タブ切り替えと出し分けの構築で、画像づくりよりはるかに重要なのが条件設計です。「どの友だちに、どのメニューを出すか」の分岐条件を誤ると、見た目は完成しているのに挙動がおかしいメニューになります。実際の構築で確認できた、設計段階で潰しておくべき落とし穴を3つ挙げます。
落とし穴1：数値項目の「初期値0」は、未設定の人にも成立する
残回数・ポイント数・来店回数のような数値項目で分岐を組むとき、注意すべきは「値が0の人」と「まだ何も設定されていない人」が区別できないことです。
たとえば「残回数=0なら使い切りメニューを表示」という条件は、一度も購入していない友だちにも成立してしまいます。さらに複数の商品・券種を扱っている場合、未購入の券種の初期値0がそれぞれの条件に引っかかり、複数のメニュー変更アクションが順番に実行されて、最後に実行された1件で上書きされるという挙動になります。お客さまから見ると「関係ないメニューが表示される」「タップするたびに違うメニューが出る」という不可解な動作です。
設計段階で「この条件は、何も持っていない新規の友だちにも成立しないか」を必ず確認してください。
落とし穴2：履歴データは「いまの状態」の判定に使えない
初期値0の問題を避けようとして、「累計購入数が1以上なら購入者」のような履歴系の項目を判定条件に足す設計も、実は不十分です。履歴は積み上がる一方で消えないため、過去に商品Aを買い、いまは商品Bを使っているお客さまは両方の条件に成立し続けます。時間が経って顧客の状態が変わるほど、複数条件の同時成立が再発します。
履歴データ（累計購入数・過去の来店記録など)は集計やレポートには有効ですが、「いまどのメニューを見せるべきか」の判定には向きません。
正解：「現在の状態」を1つの項目で持ち、排他的に分岐する
確実に動く設計はシンプルです。「現在の状態」を表す単一の項目（友だち情報欄）を1つ用意し、状態が変わるタイミングで必ず上書きする。分岐条件はすべて「現在の状態=X」を軸に組み、必要なら詳細条件をANDで足します。
実例の構成では「現在の券種」という項目を1つ設け、購入時に必ずこの項目を上書きする設計に落ち着きました。分岐は「現在の券種=A かつ 残回数=n」の形に統一。この形なら、過去にどんな履歴があっても、同時に成立する条件は常に1つだけです。状態項目が1つであること自体が、複数メニューの同時発火を構造的に防ぎます。
フォールバック：「どの条件にも当てはまらない人」を必ず受ける
もうひとつ見落としやすいのが、どの分岐条件にも一致しない友だちの受け皿です。条件分岐だけを作り込むと、状態項目がまだ空の新規友だちがボタンをタップしたとき、どのアクションも実行されず「押しても何も起きないボタン」になります。お客さまには不具合にしか見えません。
対策は、「状態項目が登録なし」を条件にした案内アクションを分岐の最後に必ず用意することです。実例では「未購入の方向けのご案内メッセージを送る」を15件目の分岐として追加しました。動作確認の際も、正常系（状態を持つ人）だけでなく、まっさらな状態のテスト友だちでタップして案内が返るかまで確認しておくと、公開後の「反応しない」問い合わせを未然に防げます。タップしても反応しない場合の切り分け手順はリッチメニューが反応しないときの確認順の記事にまとめています。
構築手順：5つのステップ
ここまでの内容を、実際の構築手順に整理します。
- 出し分けの軸と状態数を決める。会員/非会員なら2状態、券種×残回数なら掛け算で増えます。リッチメニューの枚数＝画像の枚数＝状態数＋メイン。まずこの数を確定させます
- 「現在の状態」項目を設計する。単一項目・排他で持つこと。状態が変わるすべてのタイミング（購入、登録、来店など）で、この項目を上書きするアクションを仕込みます
- 画像を状態数分つくる。2500×1686ピクセル・1MB以下で統一。タブ帯の位置とデザインは全枚共通にすると、切り替え時に「タブだけ固定で中身が変わる」自然な見え方になります
- タブ領域のボタンと戻り動線を配置する。行きと戻りを必ずセットで。全枚数分のボタン設定を一覧で監査するまでが構築です
- テスト用メニューとテスト友だちで実機確認してから、本番に適用する。運用中のメニューは直接編集しない。正常系と「状態が空の友だち」の両方でタップ確認をします
標準機能で足りるか、ツールを入れるかの判断基準
最後に、そもそもタブ切り替え・出し分けをやるべきかの判断です。
- 全員に同じメニューでよく、切り替えは月替わり程度→標準機能で十分です。ツール費用をかける理由はありません
- タブで情報を整理したい、お客さまの状態で出し分けたい→拡張ツールかAPI開発が必要です。ツールの場合はプラン条件（Lステップならセグメントリッチメニューはスタンダード以上）と月額を確認してください
- 注意点は運用負荷です。状態数が増えるほど画像枚数と管理対象が増えます。デザインを変更するとき、実例の構成では15枚すべての画像を差し替えることになりました。出し分けの粒度は「本当にその分け方でお客さまの行動が変わるか」で絞り、最小の状態数から始めるのが現実的です
まとめ
リッチメニューのタブ切り替えは、複数のリッチメニューを「変更アクション」でつなぐことで実現できます。標準管理画面にはこのアクションがないため、拡張ツールかAPI開発が前提です。そして構築の成否を分けるのは画像ではなく条件設計。「現在の状態」を単一項目で排他的に持つこと、どの条件にも当てはまらない人の受け皿を用意すること、テスト用メニューで実機確認してから本番に適用すること。この3つを押さえれば、友だち数の多い本番アカウントでも安全に出し分けを導入できます。
graciautoでは、LINE公式アカウントの構築・リッチメニュー設計から、Lステップ等を使った出し分け・自動化の実装までを一括で請け負っています。「うちの業態だとどんな出し分けが効くのか」という設計段階からの相談もお受けしています。