「出し分け」と「タブ切り替え」は何が違うのか
ユーザーが押して変えるのがタブ切り替え、システムが自動で変えるのが出し分け
この2つは言葉が似ていますが、指しているものは違います。分かれ目は「誰が切り替えるか」です。
| タブ切り替え | 出し分け | |
|---|---|---|
| 切り替える主体 | ユーザー | システム |
| きっかけ | ユーザーがメニュー上のタブを押す | 属性・行動・状態などの条件に合致する |
| 見え方 | 同じ人に複数の面があり、行き来できる | 人によって最初から違う面が出ている |
| 読者の目的 | 導線が入りきらないので面を増やしたい | 相手によって出す内容を変えたい |
言い換えると、タブ切り替えは1人に複数の面を渡す話で、出し分けは人ごとに違う面を渡す話です。会員と未会員でメニューを変えたい、というのは後者です。メニューに載せたい導線が1つの面に収まらなくなった、というのは前者です。
この区別自体は、目的を書き出すときに役立ちます。「タブが欲しい」と言われたときに、本当に必要なのが面の追加なのか、相手による出し分けなのかで、決めるべきことが変わるからです。
ただしどちらも「ユーザー単位のリッチメニュー」の上で動く
ここからがこの記事の出発点です。定義は別ですが、実装で使う仕組みは同じです。
公式のタブ切り替えの解説ページは、冒頭で「ユーザー単位のリッチメニューを活用して、タブ切り替えが可能なリッチメニューをユーザーに提供できます」と述べています。つまり公式が案内しているタブ切り替えの実装は、ユーザー単位のリッチメニューの上に組み立てられています。タブAを押した人にはメニューBがリンクされる、という形で切り替えが起きるからです。
この一文が意味することは2つあります。
1つ目は、タブ切り替えだけをやりたい場合でも、ユーザー単位のリッチメニューを扱うことになるということです。「出し分けまではいらない、タブだけでいい」と考えていても、必要な仕組みは同じ側に来ます。
2つ目は、この記事の後半で扱う制約が、どちらの目的でも同じように効くということです。管理画面から編集できなくなること、画像を差し替えられないこと、統計が引き継がれないこと。これらはユーザー単位のリッチメニューを使う時点で共通して発生します。タブ切り替えを「軽い機能追加」として見積もると、ここでずれます。
標準機能でどこまでできるのか
公式が示す「適用範囲と設定できるツール」の対応表
限界点の一次根拠はここにあります。公式ドキュメントは、リッチメニューの適用範囲を2つに分け、それぞれを設定できるツールを対応表の形で示しています。
| リッチメニューの適用範囲 | 管理画面（LINE Official Account Manager） | Messaging API |
|---|---|---|
| LINE公式アカウントとのトーク画面を開いたすべてのユーザー（デフォルトのリッチメニュー） | 設定できる | 設定できる |
| ユーザー単位（ユーザー単位のリッチメニュー） | — | 設定できる |
この表が答えです。 「出し分け」とは、ユーザーごとに違うメニューを出すことであり、それは公式の言葉では「ユーザー単位のリッチメニュー」です。そして対応表は、それをMessaging APIのみと定めています。
ここから導ける実務的な結論は1つです。管理画面のどこかに出し分けの設定があるはずだ、という前提で探すのをやめてよいということです。設定項目が見当たらないのは、画面の奥にあるからでも、プランが足りないからでもありません。管理画面が担当する適用範囲の外にあるからです。
この確定は、社内で説明するときにも効きます。「探したけれど見つからなかった」ではなく「公式の対応表がユーザー単位はAPIのみと定めている」と言えると、次の議論（開発するかどうか）に進めます。
API側にタブ切り替えがあり、管理画面側に表示期間がある
公式は同じページで、2つのツールの利点も対照の形で挙げています。片側にしか挙がっていない項目が、そのまま「移すと手に入るもの」と「移すと手放すもの」になります。 挙げられている項目をそのまま並べます。
| 管理画面（LINE Official Account Manager） | Messaging API | |
|---|---|---|
| 公式が利点として挙げている項目 | 開発期間が短く済む／操作が簡単なGUIで開発できる／表示期間を設定できる／表示された回数やクリック率などの統計情報が確認できる | 高度なカスタマイズが可能／ポストバックアクションや日時選択アクションなどのアクションオブジェクトを利用できる／リッチメニューでタブ切り替えを行うことができる／表示された回数やクリック数などの統計情報（合計、日別）が取得できる |
読み方の要点を2つ挙げます。
1つ目は、タブ切り替えがMessaging API側の利点として名指しされていることです。前節の対応表と合わせると、タブ切り替えと出し分けがどちら側の担当かは、同じ公式ページ（リッチメニューの概要）内の対応表と利点対照という2箇所の記述で一致します。限界点の根拠が1箇所だけの記述にとどまっているわけではありません。
2つ目は、こちらのほうが見落とされます。表示期間の設定は、管理画面側の利点として挙げられています。 そしてMessaging API側に、これに対応する項目は現れません。「セール期間だけこのメニューを出す」「月初に自動で切り替える」といった、期間で自動的に入れ替わる運用を設定として持てるのは管理画面側です。APIへ移すと、その仕組みは自前で用意することになります。 これは移行の判断に直接効く事実なので、後半の「移したあとに何が変わるか」でもう一度扱います。
なお、この2点はいずれも「公式が利点として挙げている項目」の読み合わせです。公式が「管理画面ではタブ切り替えができない」と書いているわけではありません。 できないことの根拠は、前節の適用範囲の対応表のほうにあります。利点の対照は、それを補強する2つ目の記述という位置づけで読んでください。
標準機能のままで足りるのはどんな場合か
標準機能の側で何ができるのかも、あわせて確認しておきます。管理画面で作れるのは、全員に同じものを出す「デフォルトのリッチメニュー」です。表示期間を指定して、その期間だけ出すことはできます。管理画面に用意されたレイアウトの型（公式マニュアルの言葉では「テンプレート」）を選んで、押せる領域（同じく「リンク領域」）を分割し、分割したエリアごとにアクションを設定することもできます。〈2026年8月3日に公式マニュアルで確認〉ここでの「テンプレート」は、管理画面が用意している領域の区切り方のことで、配布されているデザイン素材のことではありません。 素材やデザインの入手先はリッチメニューのデザインの決め方で扱います。
できないのは、次の2つです。
- 友だちごとに違うメニューを出すこと（ユーザー単位のリッチメニュー）
- ユーザーが押して面を切り替えること（タブ切り替え）
裏を返すと、「全員に同じ1枚でよく、期間で入れ替えたいだけ」なら、標準機能で完結します。 この場合、この記事の後半で扱う移行コストは一切発生しません。判定が「標準機能のままで足りる」になることは、後退ではなく1つの結論です。ここで「足りる」と判定した方は、以降の章（構成・実装・戻し方）へ進まなくて構いません。 この先は、標準機能では足りないと判定した場合に必要になる内容です。
費用についても、判定に必要な範囲をここで書いておきます。この記事が確定できているのは、実装と運用の工数までです。 LINE側の料金体系は公式のLINE公式アカウント 料金プラン〈2026年8月3日に確認〉で自社の契約プランを確認してください。同ページの本文にリッチメニューの利用料についての記述は確認できませんでしたが、記載が無いことは料金が発生しないことの根拠にはなりません。 金額やプランの比較にはこの記事では踏み込みません。これを判定の設問として扱っているのは、記事末の判定シート第2部のI-7です。
なお、画像の実寸・対応形式・容量の上限・テンプレートごとのセルの寸法といった仕様値は、この記事では扱いません。タブの面を増やすと画像も面の数だけ必要になるので、その段になったらリッチメニューの画像サイズと分割の決め方で確認してください。この記事で扱うのは、何面に分けるかという構成の判断までです。
何タブに分けるか
ここは開発に依頼する前に、社内で決めておく内容です。公式のタブ切り替えの解説は実装の手順を示していますが、何タブに分けるかという構成の判断は、そこには書かれていません。 ここが決まらないうちは、依頼内容そのものが確定しません。
先にこの章の射程を書いておきます。この章が渡すのは、分ける軸の候補・面をいくつに分けるか・どれを初期表示に設定するか・面のあいだを往復できるかの4点までです。 次の3つは渡しません——(a) 各タブに何を置くか（導線の割り当て）、(b) 分ける軸をどれにするかの基準、(c) どの面を初期表示にするかの基準。 いずれも、公式の一次仕様を読んで確定できる範囲の外にあるためです。この記事が持っている材料は、タップ領域の上限・エイリアスの上限・実装手順といった容量と機構の制約までで、そこから「何をどこに置くべきか」「どの軸を選ぶべきか」は導けません。 一般論で埋めることもしません。この3点は、自社の運用文脈で決める必要があります。
分ける軸を1つに決める
最初にやることは、分けたい軸を1つに絞ることです。軸としてよく挙がるものを3つ並べます。どれを選ぶべきかの基準は、上に書いたとおりこの記事では渡しません。候補の列挙までです。
| 軸 | 分け方の例 |
|---|---|
| 属性 | 会員／未会員、購入者／未購入者、法人／個人 |
| 行動段階 | 初回訪問／検討中／リピーター |
| 時期 | 通常／セール期間／季節企画 |
この3つを1つの画面に同時に持ち込むと、タブの数は足し算ではなく掛け算で増えます。 属性2種類×行動段階3段階で6面、そこに時期を2つ重ねると12面です。これは組み合わせの数についてのこの記事の推論であって、公式仕様に書かれていることではありません。 面が増えるということは、画像もその数だけ必要になり、差し替えのたびに全部を作り直すということでもあります。
軸を1つに決められない場合は、そもそも面を分けずに1枚で足りないかを再検討してください。
なお、時期の軸だけを分けたいのであれば、管理画面の表示期間の設定で完結する可能性があります。 前章のとおり、表示期間を設定として持てるのは管理画面側です。時期だけが理由でAPIへ移そうとしている場合は、ここで一度立ち止まってください。
切り替えのアクションはタップ領域に載る（公式例は2枚構成）
構成を決めるうえで効いてくるのが、タップ領域の使われ方です。公式の記述から確定できるのは、次の3点です。
- リッチメニューのタップ領域（公式のリッチメニューオブジェクトでは areas と呼ばれる部分）は、最大20個です。
- タブを押して別の面へ切り替えるアクションは、このタップ領域のアクションとして設定されます。 公式は切り替え用のアクションについて「タップ領域オブジェクトのアクションに、以下を指定しています」と述べています。つまり切り替え先を指すアクションは、導線と同じタップ領域の上に載ります。
- ただし、公式がこれを示している実装例はリッチメニュー2枚の構成です。 同じページに、タブの最大数についての記述も、面が3つ以上のときに1つの面で切り替えに何個のタップ領域を使うことになるかについての記述もありません。
したがってこの記事は、「面がN個のとき1面あたり切り替えに何個消費するか」を一般化した数え方を示しません。 公式が示していない数え方を、上限の数字から逆算して書くことになるためです。この節が渡せるのは、上に挙げた3つの箇条書きまでです。
タブの上限は公式に示されていない
「タブは何個まで作れるのか」は検索でよく出てくる問いなので、先に答えておきます。上限は公式に明示されていません。
公式のタブ切り替えの解説が示している実装例は、2つの面を行き来する構成です。上限についての記述はありません。関連しそうな数字として、リッチメニューエイリアスの作成上限やタップ領域の上限は確認できますが、それらがそのまま「タブの最大数」を意味するわけではありません。 ここから逆算した数値を書くことはしません。
実務上は、上限の数字より先に前節の内容が効いてきます。切り替えのアクションもタップ領域に載るので、1つの面に置ける導線の数はその分の影響を受けます（ただし前節のとおり、面が3つ以上のときの消費数は公式に記述が無いため、この記事では数えません）。画像も面の数だけ必要になります。 上限が判断を左右するような規模を検討している場合は、LINEのサポート窓口に確認してください。
初期表示をどれにするか
タブが複数あるということは、最初に見えている面がどれかを決める必要があります。
公式の実装の骨格では、まず1枚をデフォルトのリッチメニューとして設定します。ここで設定した面が、友だちがトーク画面を開いたときに最初に見えるものになります。
この記事が渡せるのは、ここまでの機構だけです。どの面を初期表示に選ぶべきかの基準は渡しません。 公式の一次仕様に、その基準を支える記述が無いためです。世の中には「こう選ぶとよい」という言い方がいくつかありますが、この記事はそれを紹介も例示もしません——公式仕様の裏づけを持たない以上、書けば根拠を持たない助言を渡すことになるからです。
押さえておく事実は1つです。タブは押されなければ切り替わりません。押されなかった場合に見えているのが初期表示の面なので、ここが実質的な既定値になります。 どの面をその既定値に置くかは、自社の運用文脈で決めてください。
タブ間を行き来できるか
最後の確認です。AからBへ行けて、BからAへ戻れるか。
公式が示している実装例は、2つの面が相互に行き来できる構成になっています。片道だけの構成にすると、切り替えた先から元の面へ戻る手段が無くなります。戻る手段が無い面に入ったユーザーは、そこから出られません。
面が3つ以上になる場合は、次の2点を確認してください。
- どの面からでも、他のすべての面へ行けるか（各面にすべてのタブを置くか）
- あるいは、行き先を絞るならその経路が一方通行になっていないか
各面にすべてのタブを置く構成は分かりやすい代わりに、その面のタップ領域を切り替えのアクションにも使うことになります。ただし前節のとおり、面が3つ以上のときに1つの面で何個使うことになるかは公式に記述が無いため、この記事では数えません。 タップ領域の上限が20個であることを踏まえて、導線に使える領域が残るかは自社の構成で確認してください。
ここまでの4点は、記事末の判定シート第1部（何タブに分けるか）にそのまま設問として並べてあります。読みながら埋めていきたい場合は、先にそちらへ目を通してから戻ってきてください。
※タブやセルの見え方と伝わり方の判断、およびテンプレートやデザイン素材の選び方と入手先は、この記事では扱いません。構成が決まったらリッチメニューのデザインの決め方で判断してください。この記事が決めるのは、何面に分けるかという構成までです。
Messaging APIでの実装の骨格
ここからは実装側の話です。コードは載せません。 この記事の目的は、自分で書くことではなく、何を誰に依頼すればよいかが分かる状態になることです。
9つの手順と、どこで人の判断が要るか
公式のタブ切り替えの解説は、実装を9つの手順で示しています。以下は手順の骨格を自社の言葉で整理し、それぞれ「開発側の作業か、事業側の判断が要るか」を添えたものです。
| # | 手順の骨格 | 事業側で先に決めておくこと |
|---|---|---|
| 1 | 面ごとの画像を用意する | 何面に分けるか（前章の構成の判断）。各面に何を置くかは前章では扱っていないため、自社の運用文脈で決める |
| 2 | 1つ目のリッチメニュー（面A）を作成する | 各領域の行き先。タブの領域を含めて設計する |
| 3 | 面Aの画像をアップロードする | — |
| 4 | 2つ目のリッチメニュー（面B）を作成する | 同上 |
| 5 | 面Bの画像をアップロードする | — |
| 6 | 面Aをデフォルトのリッチメニューに設定する | どの面を初期表示にするか |
| 7 | 面Aに対応するリッチメニューエイリアスを作成する | エイリアスの命名規則（後述） |
| 8 | 面Bに対応するリッチメニューエイリアスを作成する | 同上 |
| 9 | （運用終了時）表示を終了する | 終了の判断と手順。この記事の「戻し方」で扱います |
切り替えそのものは、タブの領域にリッチメニュー切り替えのアクション（公式の呼び方は richmenuswitch）を割り当て、そこに切り替え先のエイリアスのID（richMenuAliasId）を指定することで動きます。押されたタブに対応する面へ、その人のリッチメニューが差し替わる、という動き方です。
依頼するときに渡すものは、この表の右列です。具体的には次の4点がそろっていれば、開発側は手を動かせます。
- 面の数と、各面に置く導線の一覧（タブを含む）
- 各領域の行き先（URL、クーポン、テキストなど）
- どの面を初期表示にするか
- どの条件でどの人にどの面をリンクするか（出し分けを行う場合）
このうち「各面に置く導線の一覧」と「どの面を初期表示にするか」は、決め方をこの記事では渡していません。 前章で書いたとおり、その判断を支える材料をこの記事は持っていないためです。自社の運用文脈で決めたうえで、決まったものを依頼材料として渡してください。
最後の1点は、タブ切り替えだけが目的なら不要です。出し分けも行う場合は、「誰に」を決める条件が事業側の判断になります。
エイリアスを挟むと、切り替えの設定を変えずに中身を入れ替えられる
実装の骨格の中で、運用に最も効くのがリッチメニューエイリアスです。ここは概念を押さえておく価値があります。
エイリアスは、リッチメニューに付ける別名です。切り替えのアクションは、リッチメニューそのもののIDではなく、このエイリアスのIDを指します。そして公式は、エイリアスと紐づくリッチメニューを「リッチメニューエイリアスを更新する」エンドポイントでいつでも変更できるとしています。
この性質が効くのは、中身を入れ替えるときです。
| やりたいこと | エイリアスがない場合 | エイリアスがある場合 |
|---|---|---|
| 面Bのデザインを新しくする | 切り替え先の指定をすべて直す必要がある | 新しいリッチメニューを作り、エイリアスの紐づけ先を差し替えるだけで済む |
つまりエイリアスは、切り替えアクション側のIDを変えずに、中身だけを入れ替えるための参照として使えます。次章で扱う「画像は差し替えられない」という制約に対する、実務上の回避策がここにあります。
補足として、エイリアスには次の条件があります。1つのLINE公式アカウントに対してMessaging APIで作成できるエイリアスは最大1000件、エイリアスのID（richMenuAliasId）は最大32文字で、使える文字は半角英数字（a〜z、0〜9）とアンダースコア、ハイフンです。命名規則を先に決めておくと、面が増えたときに管理しやすくなります。
なお、この1000件という上限は「タブを1000個作れる」という意味ではありません。 前章で書いたとおり、タブの最大数は公式に示されていません。
実装可否を左右する2つの制限
見落とされやすい割に、設計を左右するのがレート制限です。公式はエンドポイントごとに制限を示しています。この記事に関係するのは次の2つです（2026年8月2日時点の記述）。
| 対象 | 制限 |
|---|---|
| リッチメニューを作成する／削除する／リッチメニューエイリアスを削除する／リッチメニューの一括操作の進行状況を取得する | 100リクエスト／時 |
| リンク済みのリッチメニューを一括で置き換える・解除する | 3リクエスト／時 |
そして公式は、「LINE Official Account Managerを使ってリッチメニューを作成・削除する場合は制限の対象外です」と注記しています。 管理画面での作業には、この制限は関係しません。
この2つが効いてくるのは、セグメントを細かく作り分ける設計です。属性ごとに専用のリッチメニューを用意するような設計は、面の数が増えるほど作成・削除の回数が増えます。とくに下段の3リクエスト／時は、一括での切り替えを運用の中心に据える設計だと早い段階でぶつかります。
設計を決める前に、「1時間あたり何回、作成・削除・一括操作が走るか」を概算しておいてください。 面の数×更新頻度で見積もれます。
なお、これらの数値は公式が改定しうるものです。実際に呼び出して確認したものではない旨は冒頭で述べたとおりです。 設計の前に、必ずMessaging APIリファレンスの現行値を確認してください。
成功レスポンスは、適用の証拠にならない
実装時にいちばん踏みやすい落とし穴がここです。
公式は、リッチメニューをリンクできる相手を「LINE公式アカウントを友だち追加しているユーザー」としたうえで、次の4つの場合はステータスコード200が返るが、実際にはリンクされないと明記しています。
| 200が返るがリンクされない状態 |
|---|
| LINEアカウントを削除したユーザー |
| LINE公式アカウントをブロックしているユーザー |
| LINE公式アカウントを友だち追加していないユーザー |
| 他のプロバイダー配下のチャネルで取得したユーザーIDなど、チャネルにユーザーIDが存在しないユーザー |
つまり、「成功レスポンスが返ったから適用された」とは言えません。 実装を依頼するときは、送って終わりにせず、リンクの状態を読み戻して突き合わせるところまでを仕様に含めてください。これを入れておかないと、「一部の人にだけメニューが出ない」という状態が、原因不明のまま残ります。
なお、すでにリッチメニューがリンクされているユーザーに対して新しくリンクした場合は、新しく指定したものに置き換わります。この点は明記されています。
これも公式リファレンスの記述であり、実際に4つの状態を再現して確かめた結果ではない点は冒頭で述べたとおりです。 それでも、依頼時の仕様に「レスポンスだけを成功判定に使わない」と1行入れておく価値はあります。
移したあとに何が変わるか
ここがこの記事の中心です。移行の話は「不可逆かどうか」でまとめられがちですが、実際に起きることは4つあり、それぞれ性質が違います。 作り直せるものと、失われるものを分けて書きます。
| 変わること | 性質 | 回避策・代替 |
|---|---|---|
| 管理画面から編集できなくなる | 編集経路が固定される | 無し（ツールをまたいだ編集は仕様上できない） |
| 画像を差し替えられない | 更新は作り直しになる | エイリアスの紐づけ先の更新で、切り替え側のIDは維持できる |
| 統計が引き継がれない | 管理画面側の系列が切れる | 無し（API側で取得し直す） |
| 表示期間の設定が無くなる | 期間による自動切り替えを自前で持つ | 自前の仕組みで代替する |
管理画面から編集できなくなる
「APIへ移したら、運用が自分の手を離れるのではないか」。この問いに、公式の記述で正面から答えます。
そのとおりです。そのメニューについては、管理画面から編集できなくなります。
公式ドキュメントは、こう明記しています。「1つのリッチメニューの取得や編集に、2つのツールを使うことはできません。LINE Official Account Managerで作成したリッチメニューは、LINE Official Account Managerでのみ取得と編集ができます。また、Messaging APIで作成したリッチメニューについては、LINE Official Account Managerは使用できません」。
つまり最初に選んだツールが、その1枚の編集経路を固定します。 Messaging APIで作ったリッチメニューは、以後の差し替えもリンク先の変更もAPI経由になります。
実務上の含意は、機能の話ではなく体制の話です。これまで運用担当者が管理画面から自分で差し替えていたなら、その作業は開発側へ移ります。「メニューの文言を1つ直したい」がリリース作業になる、ということです。
これは避けられない代わりに、事前に決めておくことはできます。 日々の差し替えを誰がどの経路で行うのか、依頼から反映までにどれくらいかかるのか。これを決めずに移すと、移行後に「変えたいが変えられない」状態が発生します。
なお、これはアカウント全体が管理画面から触れなくなるという意味ではありません。 固定されるのは、そのリッチメニュー1つの編集経路です。
画像は差し替えられない
2つ目です。Messaging APIリファレンスは、こう明記しています。「リッチメニューに設定された画像を置き換えることはできません。リッチメニューの画像を更新するには、新しいリッチメニューオブジェクトを作成して、新しい画像をアップロードします」。
つまり、季節ごとにバナーを差し替えるような運用は、そのたびにリッチメニューを作り直すことを意味します。
ここで前章のエイリアスが効きます。作り直すのはリッチメニュー本体だけで、切り替えアクション側の指定は変えずに済みます。 手順としてはこうなります。
- 新しい画像で、新しいリッチメニューを作成する
- 既存のエイリアスの紐づけ先を、新しいリッチメニューへ更新する
- 必要に応じて、古いリッチメニューを削除する
切り替えのアクションはエイリアスのIDを指しているので、2の時点で切り替え先が入れ替わります。 各面のタブに設定した指定をすべて直して回る必要はありません。
線を引くとこうなります。
| 差し替えのたびに作り直すもの | 作り直さなくてよいもの |
|---|---|
| リッチメニュー本体（画像を含む） | エイリアスのID、それを指している切り替えアクションの設定 |
つまりこの制約の実体は、「更新のたびに作成の作業が発生する」ということです。頻度が高いほど負担も増えるので、判定シートでは差し替えの頻度と担当を確認します。
統計が引き継がれない
3つ目です。公式は、Messaging APIとLINE Official Account Managerで作成したリッチメニューについて、それぞれ作成したツールでのみ統計情報を参照できると表で示しています。APIで作成したものを管理画面の分析で見ることも、管理画面で作成したものをAPIで取得することもできません。
これが「失われるもの」です。 管理画面の分析で見ていた表示回数やクリック率の系列は、APIへ移した時点で続きません。移行の前後で数字を並べて比較する、ということができなくなります。
対応としては2つあります。
- 移行前の期間の数値を、管理画面から手元に控えておく。 移行後に作るメニューの統計はAPI側でしか取得できないため、管理画面側で見ていた系列は移行の時点で止まります。
- 移行後にAPI側で何をどう取得するかを、移行と同時に決める。 公式は、Messaging API側の利点として「表示された回数やクリック数などの統計情報（合計、日別）が取得できます」と挙げています。取得はできますが、それは取得する仕組みを作るという意味です。管理画面のように開けば見える状態にはなりません。
移行の作業計画に「統計をどこで見るか」の行が無い場合、移したあと、数値をどこで見るのかが決まらないまま運用が始まります。
表示期間による自動切り替えを、自前で持つことになる
4つ目です。前節で見た利点の対照から導かれるもので、運用への影響は小さくありません。
前章で確認したとおり、公式の利点対照では表示期間の設定は管理画面側にのみ挙げられており、Messaging API側に対応する項目は現れません。 「この期間だけこのメニューを出す」を設定として持てるのは管理画面側です。
したがって、APIへ移した後に期間で自動的に切り替えたい場合は、その仕組みを自前で用意することになります。 具体的には、指定した日時に切り替えの処理を実行する仕組みと、それを動かし続ける場所が必要です。
ここは公式が「APIではできない」と書いているわけではありません。 対応表と利点の対照に該当する項目が現れないことからの帰結です。断定として読まないでください。ただし、期間による切り替えを設定項目として持てる根拠も確認できていないので、「自前で持つ前提で見積もる」ほうが安全だと判断しています。
前章で書いたとおり、分けたい軸が「時期」だけなら、標準機能の表示期間で完結する可能性があります。 APIへ移す理由が期間の切り替えだけになっていないかは、判定の前に確認してください。
ここまでの4つは、記事末の判定シート第2部（実装可否の判定）で、それぞれ設問として確認できるようにしてあります。
戻し方
移す判断をする前に、戻す手順も知っておいたほうが決めやすくなります。公式は表示を終了する手順を定義しています。
表示を終了する3つの手順
公式が示す手順は次のとおりです。
- デフォルトのリッチメニューを解除する
- リッチメニューエイリアスを削除する
- リッチメニューを削除する
公式が書いているのは、この3つと順番までです。 なぜこの順番なのかの説明は添えられていません。切り替えアクションがエイリアスを指しているという構造から考えると、参照される側を先に整理する順番になっている、とは読めます。ただしこれはこの記事の読み取りであって、公式の説明ではありません。
リンク解除が先である理由
ここが実務的にいちばん重要です。ユーザーとのリンクを解除してから削除するかどうかで、消えるタイミングが変わります。
公式は次の2つを書いています。
- リンクを解除せずにリッチメニューを削除した場合、削除は即時には反映されず、ユーザーがトーク画面に再入室したときに反映される
- リンクを解除した場合は、即時に表示されなくなる
そしてもう1つ、公式は「デフォルトのリッチメニューを解除してもリッチメニューが表示され続けてしまう」という状態を名指しで説明しています。原因は、切り替えアクションで面が切り替わった時点で、そのユーザーに表示されているのが、表示の優先順位が最も高いユーザー単位のリッチメニューになっているためです。
リッチメニューの表示の優先順位は、公式が高い順に次のように定めています。
- Messaging APIで設定するユーザー単位のリッチメニュー
- Messaging APIで設定するデフォルトのリッチメニュー
- LINE Official Account Managerで設定するデフォルトのリッチメニュー
この3つを重ねると、結論が出ます。 タブ切り替えを一度でも使ったユーザーには、1番目（ユーザー単位）のリッチメニューがリンクされています。デフォルトの解除が効くのは2番目に対してなので、デフォルトを解除しただけでは、そのユーザーの画面からは消えません。 確実に止めるには、ユーザーとのリンクを解除するのが先になります。
手順に落とすとこうなります。
| 目的 | 先にやること |
|---|---|
| すぐに表示を止めたい | ユーザーとのリンクを解除する（その後にデフォルト解除・エイリアス削除・リッチメニュー削除） |
| 順次消えていくのでよい | 公式の3手順どおりに進める（削除は再入室時に反映される） |
「戻せない」のではなく、「戻す順番がある」というのがこの節の結論です。
解除の順番を間違えたときに起きること
上に書いた「デフォルトを解除しても消えない」は、公式が原因まで説明している状態です。戻す作業の途中でこれに遭遇したら、追加で何かを消すのではなく、ユーザーとのリンクが解除されているかを先に確認してください。 解除が済んでいないうちにリッチメニューを削除しても、その人の画面から消えるのは再入室のタイミングです。
なお、表示されない・意図した面が出ないという症状そのものの切り分けは、この記事では扱いません。 原因は今回扱った表示の優先順位だけとは限らず、端末やアカウント側の条件も絡みます。症状から入る場合はリッチメニューが表示されないときの確認手順を見てください。この記事は、実装と戻し方の側からのみ扱っています。
何タブに分けるか／実装可否の判定シート
ここまでの内容を、社内で判定できる形にまとめます。第1部で構成が決まり、第2部で実装するかどうかが決まります。 そのままコピーして回覧できる形にしています。
第1部が埋まらないうちは、第2部に進んでも判定できません。 第1部の4問——分ける軸・面の数・初期表示・往復の成立——が決まっていないと、第2部で見積もる作業量も更新頻度も出せないためです。なお各面の中身（どの導線をどこに置くか）は、このシートの記入対象ではありません。 シートを埋めたあとに、自社の運用文脈で決める作業です。
第1部：何タブに分けるか（4問）
このシートの第1部が渡すのは、分ける軸の候補・面をいくつに分けるか・どれを初期表示に設定するか・往復が成立するかの4点までです（本文の「何タブに分けるか」冒頭の射程宣言と同じです。渡さない3点——各タブに何を置くか／分ける軸の基準／初期表示の基準——の詳細もそちらを参照してください）。以下のT-1〜T-4とその判定の目安は、この非提供の宣言を前提に読んでください（同じ断りを各設問では繰り返しません）。
| # | 設問 | 記入欄 |
|---|---|---|
| T-1 | 分ける軸を1つに書けるか（属性／行動段階／時期のうち1つ） | |
| T-2 | 面はいくつか。各面に置くタップ領域はいくつか（切り替え用のアクションもタップ領域に載る。合計20個が上限。公式が消費数を示しているのは2枚構成の例に限る） | |
| T-3 | 初期表示にするのはどの面か（デフォルトのリッチメニューに設定するもの） | |
| T-4 | すべての面のあいだで往復できるか（AからB、BからAへ戻れるか） |
判定の目安です。
- T-1に2つ以上の軸を書いてしまう場合：面の数が掛け算で増えます（これは組み合わせの数についてのこの記事の推論で、公式仕様の記述ではありません）。軸を1つに絞りきれない場合は、面を分けない構成で足りないかを先に再検討してください。
- T-1が「時期」だけの場合：管理画面の表示期間の設定で完結する可能性があります。第2部に進む前に確認してください。
- T-2で導線を置く領域が足りない場合：面の数を減らすか、1面あたりの導線を絞ります。なお、面が3つ以上のときに1つの面で切り替えに何個のタップ領域を使うことになるかは、公式に記述が無いためこの記事では数えていません。
- T-3が決まらない場合：デフォルトのリッチメニューを1つ設定する必要があること自体は、公式の実装手順のとおりです。どの面をそこに置くかを、自社の運用文脈で決めてから記入してください（決まるまで第2部の作業量は見積もれません）。
- T-4に戻れない経路がある場合：その面に入ったユーザーが元へ戻れません。設計を直してから依頼してください。
※各面の見え方と伝わり方の判断は、ここでは扱いません。リッチメニューのデザインの決め方で判断してください。
第2部：実装可否の判定（7問）
この第2部は、Messaging APIでの実装を社内または外部に依頼できる前提で書いています。相談先が無い場合、この記事が渡せるのは第1部と「標準機能で足りるか」の判定までです。
| # | 設問 | はい／いいえ |
|---|---|---|
| I-1 | 対象ユーザーのユーザーIDを継続的に把握できる仕組みがあるか | |
| I-2 | 作成・削除が100リクエスト／時、一括の置き換え・解除が3リクエスト／時に収まる規模か（面の数×更新頻度で概算する） | |
| I-3 | 画像の差し替えがどの頻度で発生し、その都度リッチメニューを作り直す作業を誰が担うか決まっているか | |
| I-4 | そのメニューを管理画面から編集できなくなることを、運用チームが受け入れられるか | |
| I-5 | 管理画面側の統計の系列が切れることを許容できるか（移行前の数値の控えを取るか） | |
| I-6 | 期間による自動切り替えを自前で持てるか（必要な場合のみ） | |
| I-7 | この経路で発生する費用を見込めているか（この記事が確定できている費用は、実装と運用の工数までです。 LINE側の料金体系は公式のLINE公式アカウント 料金プラン〈2026年8月3日に確認〉で確認してください。同ページにリッチメニューの利用料についての記述は確認できませんでしたが、記載が無いことは料金が発生しないことの根拠にはなりません。 金額やプランの比較にはこの記事では踏み込みません） |
判定の目安です。
- I-1からI-7がすべて「はい」：Messaging APIでの実装に進めます。第1部の4項目（分ける軸・面の数・初期表示・往復の成立）と、第1部では扱わない導線の割り当て（各面に置く導線と各領域の行き先）をあわせると、依頼内容になります。 導線の割り当ては自社で決める部分です（次項）。
- I-1が「いいえ」：実装の前に、その受け皿をどう用意するかを先に確認する項目です。
- I-2が「いいえ」：設計そのものを見直します。セグメントを細かく作り分けるほど、この制限に先にぶつかります。
- I-3からI-5のいずれかが「いいえ」：見送るという判定が妥当です。 実装はできても、運用が続きません。とくにI-4が「いいえ」の場合、移行後に「変えたいが変えられない」状態が常態化します。
- I-6が「いいえ」で、必要としている：期間の切り替えが目的なら、標準機能のままのほうが合っています。
- I-7が「いいえ」：この記事が確定できているのは実装と運用の工数までです。LINE側の料金体系については、上記の公式の料金プランページで自社の契約プランを確認してください。
「いいえ」があるからといって、実装できないという意味ではありません。 ただしこの記事は、実装を勧める立場では書いていません。標準機能のままで足りるという判定も、Messaging APIへ進むという判定と同じ重みで支持します。 判定シートの目的は、開発に出す前に自社で結論を出せるようにすることであって、実装へ誘導することではありません。
実装へ進むと決めたら、何を持って相談するか
「実装へ進む」となった場合、開発を担当する人に渡す内容は次の4点です。どこまでが第1部で埋まり、どこからが自社で足す部分かを、各項目に添えます。
- 面の数（第1部 T-2 で埋まる）と、各面に置く導線の一覧（タブを含む。第1部の記入対象ではないので自社で決める）
- 各領域の行き先（第1部の記入対象ではないので自社で決める）
- 初期表示にする面（第1部 T-3 で埋まる。どの面を選ぶかは自社の判断で、設定の機構だけをこの記事が渡しています）
- 出し分けを行う場合、どの条件でどの人にどの面をリンクするか（第1部の記入対象ではないので自社で決める）
第1部で埋まるのは、分ける軸・面の数・初期表示にする面（T-3）・往復の成立の4点です。 これに対し、各面に置く導線の割り当てと各領域の行き先は第1部の設問に無く、どの軸を選ぶべきか・どの面を初期表示に選ぶべきかの基準も、この記事では渡していません。 いずれも自社の運用文脈で決める必要があります。
あわせて、仕様として先に伝えておくとよい点が2つあります。1つは、リンクの結果をレスポンスだけで判定せず読み戻して突き合わせること。 もう1つは、画像の更新はエイリアスの紐づけ先の差し替えで行う設計にしておくことです。どちらも後から直すと影響範囲が広がります。
この記事が扱わないこと
拡張ツールでノーコードに実現する経路を扱わない理由
拡張ツールを導入してノーコードで実現する経路は、この記事では扱いません。
この語で検索したときに上位に出てくる記事には、LINE運用ツールを提供している各社の自社メディアが含まれています（この記事が参照した2026年8月2日の観測記録では、上位10件のうち3件）。ツールを使う経路そのものは妥当な選択肢です。ただしこの記事は、「標準機能とMessaging APIで何がどこまでできるか」を公式の一次仕様から確定させることを目的にしており、各ツールの機能・料金・プラン別の可否を検証できる材料を持っていません。持っていない材料で優劣を書くことはしないので、扱わないことを先にお伝えしておきます。 ツールでの実現方法を探している場合は、この記事は目的に合いません。
ツールを検討するなら、先に確認する3つのこと
とはいえ、行き止まりにはしません。 この記事が公式の一次仕様から確定させた3つの事実は、どのツールを検討する場合でも同じ形で効きます。 機能表や料金表を見比べる前に、次の3点を確認してください。いずれも「そのツールが良いか悪いか」ではなく、導入したあとに誰が何をやることになるかを先に確定させるための質問です。
1. 編集経路が固定されること。 そのツールで作ったリッチメニューを、LINE公式アカウントの管理画面から編集できるかを確認してください。公式の制約は「1つのリッチメニューの取得や編集に、2つのツールを使うことはできない」です。ツール側がMessaging APIでリッチメニューを作る以上、そのメニューは管理画面から触れなくなります。確認すべきことは「日々の差し替えを、誰がどの画面で行うのか」です。ツール側の画面で完結するのか、依頼が必要なのか。ここが曖昧なまま導入すると、この記事の「移したあとに何が変わるか」で書いたのと同じ状態になります。
2. 統計の継続性。 表示回数やクリック率をどこで見ることになるかを確認してください。統計は作成したツールでのみ参照できるため、管理画面側で見ていた数値の系列は切れます。 ツール側がどの粒度で（面ごとか、領域ごとか、日別か）統計を返すのか、そしてそれが今見ている数字の代わりになるのかを、導入前に確かめてください。
3. 解約したときにどうなるか。 契約を終えたときに、そのリッチメニューがどうなるかを確認してください。残るのか、消えるのか、管理画面側へ戻せるのか。公式仕様からの帰結としては、管理画面側へ戻すには削除と再作成が必要になります。 その手順と担当を、導入前に決めておいてください。ここは契約時に聞かないと、終わるときまで分からないままになります。
この3点は、特定のツールを勧めるものでも、優劣を判定するものでもありません。 この記事が扱わない領域に進む読者へ渡す、確認の観点です。
判定シートのI-1：ユーザーIDの受け皿があるか
最後に1点だけ、判定シートのI-1について補足します。
I-1が問うているのは、対象になる人のユーザーIDを継続的に把握できる仕組み（受け皿）が自社にあるかどうかです。この記事は、ユーザーIDをどう取得するか、リンクの実行時に何をどう指定するかについて、公式の一次記述を確認できていません。したがって、その受け皿がどうあるべきかをこの記事は書きません。I-1は確認の観点として置いています。
この受け皿をどう用意するかは、リッチメニュー単体の話ではなく、LINE公式アカウントの運用基盤の話になります。受信の仕組みの構成や公開前の確認項目を具体的に見たい場合は、AIでLINE運用するには？公式アカウントの運用基盤を作る手順で扱っています。この記事はツールや基盤を推奨する立場では書いていないので、構成の実例として参照してください。
まとめ：判定と、次に読むもの
この記事の要点3つ
- 標準機能の限界点は、公式の適用範囲の対応表で確定します。 全員共通の「デフォルトのリッチメニュー」は管理画面とMessaging APIの両方で設定できますが、「ユーザー単位のリッチメニュー」はMessaging APIのみです。出し分けはこれそのもので、タブ切り替えも公式の解説上はこの上に乗ります。管理画面を探し続ける必要はありません。
- 移したあとに変わるのは4つです。 そのメニューが管理画面から編集できなくなること、画像の更新がリッチメニューの作り直しになること、管理画面側の統計の系列が切れること、表示期間による自動切り替えを自前で持つことになること。ただし取り消せなくなるわけではなく、エイリアスの紐づけ先は更新できますし、表示を終了する手順も公式に定義されています。確実に止めるには、ユーザーとのリンクの解除が先です。
- 判定が「標準機能のままで足りる」でも構いません。 分けたい軸が時期だけなら管理画面の表示期間で完結しますし、日々の差し替えを運用担当者の手元に残したいなら、それは移さない理由になります。判定シートは、開発に出す前に自社で結論を出すためのものです。
決まらなかったことは、どの記事で決めるか
| 決めたいこと | 読む記事 |
|---|---|
| まず1枚を公開できる状態にする | LINEリッチメニューとは？作り方と、作る前に決める3つのこと |
| 各面の画像の実寸・形式・容量・分割を決める | リッチメニューの画像サイズと分割の決め方 |
| タブやセルの見え方・伝わり方を判断する／テンプレートやデザイン素材の選び方と入手先を知る | リッチメニューのデザインの決め方 |
| 意図した面が表示されないときに切り分ける | リッチメニューが表示されないときの確認手順 |
判断の材料がどこまでのものだったかを、最後に確認しておきます。ここに書いたのは、LINEの公式ドキュメント・Messaging APIリファレンス・公式マニュアルを2026年8月2日時点で読み解いて確認が取れた範囲と、そこから導いた結論です（切り替えアクションの設置場所、LINE公式アカウントの料金プランページ、管理画面のリッチメニュー作成マニュアルで設定できる項目、の3点のみ2026年8月3日に追加で確認しています）。Messaging APIを実際に呼び出して確かめた記録ではありません。 9つの手順も、レスポンスの挙動も、レート制限も、いずれも記述として確認したものです。LINE Developers の各ドキュメントには更新日の表記が無く、改定の追跡ができません。とくにレート制限の数値は、設計を確定させる前に必ず現行のリファレンスで確認してください。