LINE公式アカウントのリッチメニュー活用法｜切り替え・自動応答・連携の仕組み

LINE公式アカウントのトーク画面を開くと、下部に「予約する」「料金を見る」「お問い合わせ」などのボタンが表示されることがあります。このメニューを、問い合わせ対応やWebサイトへの案内に活用できるのが「リッチメニュー」です。

ただし、リッチメニューを設置することと、返信や予約処理を自動化することは、それぞれ別の設定です。「押すと何が起きるのか」「誰にどのメニューを見せるのか」を整理すると、必要な機能を選びやすくなります。

基本的なリンク案内や定型文の返信は、LINE公式アカウントの管理画面から設定できます。タブの切り替えや利用者ごとの出し分け、外部システムと連動する処理には、Messaging APIなどを使った仕組みを検討します。この記事では、その違いと導入手順を具体例で解説します。

１．リッチメニュー・応答メッセージ・Messaging APIの違い

リッチメニューは、LINE公式アカウントのトーク画面下部に表示される操作メニューです。画像の中にタップできる領域を設定し、それぞれにリンクを開く、テキストを送信するといった動作を割り当てます。

応答メッセージは、受信したメッセージに対して事前に用意した内容を返信する機能です。一方、Messaging APIは、開発したシステムからメッセージ送信やリッチメニューの設定などを行うための仕組みです。

例えば「予約する」ボタンから予約フォームを開くだけなら、リッチメニューにリンクを設定する方法があります。予約の空き状況を取得してトークに返信したい場合は、外部の予約システムとの連携が必要です。

２．リッチメニューの「切り替え」は３種類に分けて考える

リッチメニューの切り替えは、何をきっかけに変えるかで設計が変わります。期間、利用者の操作、会員登録などの状態変化を分けて考えましょう。

表示期間を設定する切り替え

LINE Official Account Managerでは、リッチメニューの表示期間を設定できます。キャンペーンの開始前に次のメニューを準備するなど、日程が決まった運用に向いています。

ただし、APIでユーザー単位のメニューなどを設定している場合、そちらが優先されることがあります。「管理画面で切り替えたから全員に同じものが出る」と考えず、既存の設定も確認してください。

タブを押して切り替える

タブ切り替えでは、複数のリッチメニューを用意し、利用者の操作で表示を切り替えます。「サービス案内」「利用者向け」と分ければ、一つの画像にボタンを詰め込みすぎずに済みます。

Messaging APIでは、リッチメニューエイリアスという切り替え先の別名と、リッチメニュー切替アクションを使います。画像にタブらしい見た目を描くだけでは動作せず、タップ領域と切り替え先の設定が必要です。

利用者ごとに出し分ける

ユーザー単位のリッチメニューを使うと、利用者ごとに異なるメニューを表示できます。例えば、会員登録が完了した人には「予約確認」、未登録の人には「新規登録」を案内する設計です。

この場合は、LINEのユーザーと自社サービスの会員情報を適切に結び付ける処理が必要です。会員向けメニューが表示されていることだけを、本人確認や利用権限の判定に使わないようにしましょう。リンク先でもログイン状態と権限を確認します。

３．まずは管理画面で「ボタンを押すと返信する」を作る

自動化の最初の一歩として取り組みやすいのが、リッチメニューとキーワード応答の組み合わせです。例えば「営業時間」ボタンを押したときに、営業時間と休業日の案内を返す仕組みを作れます。

設定手順

1. 返信内容を決める：営業時間、所在地、持ち物など、固定した内容で答えられる案内を選びます。
2. 応答メッセージを作成する：「キーワード応答」を選び、「営業時間」などのキーワードと返信文を登録します。
3. 利用中にする：保存だけで終わらず、応答メッセージの利用状態と「応答設定」を確認します。
4. リッチメニューを作成する：テンプレートと画像を選び、該当する領域にテキスト送信のアクションを設定します。
5. 送信する文字をそろえる：ボタンから送信するテキストを、登録したキーワードと同じ「営業時間」にします。
6. スマートフォンで確認する：タップ後に文字が送信され、想定した案内が返信されるかを確認します。

キーワード応答は、設定したキーワードと完全一致するメッセージに反応します。「営業時間」と登録しても、「営業時間を教えてください」という文章まで同じ条件で認識する仕組みではありません。

ボタンから決まった文字を送れば、利用者に入力してもらう手間と表記の揺れを減らせます。自由入力の問い合わせにも対応する場合は、一致しないメッセージを受けたときの案内や、担当者への引き継ぎ方法も用意しましょう。

リンクを開く動作と、メッセージを送る動作を分ける

「料金ページを開く」ならリンク、「料金についてトークで返信する」ならテキスト送信とキーワード応答というように使い分けます。リンクを開いたことだけで、キーワード応答が自動的に実行されるわけではありません。

また、APIで設定するポストバックは、サーバーへ操作内容を知らせるためのアクションです。通常のテキストメッセージとはイベントの種類が異なるため、開発時はどちらを受け取る設計なのかを明確にします。

４．Messaging APIでタブ切り替えを実装する仕組み

例えば「案内」と「サポート」の２つのタブを作る場合、それぞれの状態に対応するメニュー画像とタップ領域を用意します。「案内」側にはサポートへ移る操作を、「サポート」側には案内へ戻る操作を設定します。

開発時の大まかな手順は、次のとおりです。作成や設定にはMessaging APIを使い、利用者がタップした際の切り替えは、設定されたリッチメニュー切替アクションによって行われます。

1. メニューA・Bの画像と、各ボタンの役割を決める。
2. APIでメニューA・Bを作成し、それぞれの画像をアップロードする。
3. 各メニューに対応するエイリアスを作成する。
4. タブのタップ領域から、相手のエイリアスを指定する。
5. 最初に表示するデフォルトメニューを設定する。
6. 往復の切り替えと、他のボタンの動作を確認する。

切替アクションの種類は「richmenuswitch」、切り替え先の指定は「richMenuAliasId」です。画像上のタブ位置と、APIで設定したタップ領域がずれていないかも確認します。

切り替えた後の更新方法も決めておく

タブ切り替えによって表示されたメニューは、ユーザー単位のリッチメニューとして扱われます。そのため、後からデフォルトメニューだけを変更しても、切り替え済みの利用者には古いメニューが残ることがあります。

運用時は、どの利用者にどのメニューを割り当てているかを把握し、必要に応じて割り当ての変更やリンク解除を行います。更新時にメニューを一括削除する前に、利用中の切り替え先と影響範囲を確認しましょう。

５．予約や会員情報と連動させる自動化の設計

固定した案内だけでは対応できない場合は、外部システムとの連携を検討します。例えば、利用者が「予約確認」を押したら、登録済みの予約を調べ、その人に必要な情報だけを返信する仕組みです。

このような処理では、ボタン操作をWebhookで受け取り、サーバーで利用者と予約情報を照合してから、Messaging APIで結果を返します。リッチメニューは処理の入口であり、予約情報の取得や更新は連携先のシステムが担当します。

学習教室を例にしたメニュー設計

次の表は、学習教室のLINE公式アカウントを想定した設計例です。最初はリンク案内と定型返信から始め、運用上の必要が生まれた部分を個別に連携させます。

会員情報や予約内容を扱う場合は、Webhookの署名検証に加え、その利用者が対象の情報を閲覧・変更できるかを確認します。ボタンの連打や通知の再送によって、同じ予約を重複登録しない仕組みも必要です。

また、標準の応答メッセージとAPIからの返信を併用すると、一つの操作に複数の返信が届く構成になり得ます。どの問い合わせをどちらが担当するかを決め、時間帯ごとの応答設定も含めて確認してください。

６．リッチメニューが切り替わらない・返信されないときの確認方法

うまく動かないときは、「メニューが表示されない」「タップ後の動作が違う」「返信が届かない」を分けて調べます。画像の問題と応答設定の問題を一度に変更すると、原因が分かりにくくなります。

表示の優先順位は、基本的にユーザー単位のメニュー、APIのデフォルトメニュー、管理画面のデフォルトメニューの順です。また、設定方法によって反映のタイミングも異なるため、トーク画面への再入室も試してください。

７．使いやすいメニューにするための確認項目

機能を増やす前に、利用者が迷わず目的を達成できるかを確認しましょう。ボタンの数よりも、「押した後に期待した案内が出ること」が大切です。

• ラベルを具体的にする：「こちら」より「予約する」「料金を見る」など、動作が分かる言葉を使う。
• 文字の読みやすさを確認する：スマートフォンの実際の表示サイズで、文字と背景のコントラストを見る。
• 見た目と操作範囲を合わせる：ボタンの境界付近を押しても、意図した動作になるか試す。
• 戻る操作を用意する：タブを切り替えた後、元の案内へ戻れるようにする。
• 自動化できない相談の出口を作る：担当者への相談方法と対応時間を案内する。
• 成果まで確認する：クリック数に加え、申込完了や問い合わせ解決につながったかを確認する。

管理画面とMessaging APIでは、作成したリッチメニューを管理する場所が異なります。担当者が交代しても更新できるよう、作成方法、画像、リンク先、返信文、変更履歴をまとめておくと運用しやすくなります。

８．よくある質問

リッチメニューの自動応答にはプログラミングが必要ですか？

固定した文章を返すキーワード応答と、リッチメニューのテキスト送信を組み合わせる方法なら、管理画面から設定できます。予約状況などの外部データを使った返信には、追加の開発や対応サービスの利用を検討します。

タブ切り替えには有料の外部ツールが必須ですか？

必須ではありません。Messaging APIを使って自分で実装する方法があります。ただし、開発・保守の負担は発生するため、外部ツールを使う場合も、対応機能や料金、引き継ぎ方法を比較してください。

メニューを出し分ければ、会員情報を安全に表示できますか？

メニューの出し分けだけでは不十分です。会員情報を返すAPIやリンク先の画面で、本人確認とアクセス権限の確認を行います。LINEの表示名だけで会員を特定する設計も避けましょう。

自動応答には生成AIを使う必要がありますか？

必要ありません。営業時間や持ち物のように回答が決まっている案内は、キーワード応答で対応できます。自由な文章の質問を扱いたい場合は、回答範囲や誤回答時の対応を決めたうえで、AIの利用を検討します。

９．まずは一つのボタンから運用を始める

最初に作るなら、問い合わせが多い内容を一つ選び、リッチメニューから案内できるようにしてみましょう。「営業時間を返す」「申込フォームを開く」といった小さな機能でも、利用者と担当者の手間を減らすきっかけになります。

その後、情報が増えて探しにくくなったらタブ切り替えを、利用者ごとの情報が必要になったら外部連携を追加します。案内する内容、押した後の動作、困ったときの相談先をそろえながら、使われるリッチメニューに育てていきましょう。

参考資料

• LINEヤフー for Business：リッチメニューを作成する
• LINEヤフー for Business：応答メッセージ
• LINEヤフー for Business：応答設定
• LINE Developers：リッチメニューの概要
• LINE Developers：リッチメニューでタブ切り替えを行う
• LINE Developers：ユーザー単位のリッチメニューを使う
• LINE Developers：アクション