LINEログインと友だち追加の設計。bot_prompt・ミニアプリ同意・計測を整理

LINEログインを付けるだけで、利用者が全員公式アカウントの友だちになるわけではありません。ログイン成功、自社会員との連携、友だち追加、通知の受信は別の状態です。どこまで確認できたかを分けることで、登録のしやすさと通知を受け取る理由を両立できます。

本記事は2026年9月8日の公式仕様を基に、WebサービスとLINEミニアプリでの追加導線を整理します。友だち数の増加や売上改善を保証するものではなく、実装と計測の判断に使う設計案です。

最初に4つの状態を分ける

状態	確認したいこと	それだけでは分からないこと
LINEログイン済み	LINEの認証に成功したか	自社の既存会員と同じ人物か
会員連携済み	自社会員IDとの対応が確認できたか	公式アカウントと友だちか
友だち追加済み	対象公式アカウントとの友だち状態	次回の通知を読んでもらえるか
業務完了	予約確認や注文など目的を終えたか	その後も通知を希望するか

ログイン導入の成果を「ログイン数＝獲得友だち数」で集計すると、既存友だちの再ログインまで新規獲得に含まれます。また、会員が別のLINEアカウントへ切り替えた際は、自社会員との連携先を安全に更新する手順も必要です。LINE APIの条件整理と合わせて確認してください。

WebのLINEログインでは、友だち追加オプションを設定する

LINEログインの公式手順では、チャネルへ公式アカウントをリンクし、認可URLのbot_promptで表示方法を指定します。同じプロバイダー配下であることと、管理者権限を満たすことを先に確認します。

指定	表示する場所	設計時の確認
normal	ログインの同意画面内	追加の理由がログイン前に伝わるか
aggressive	同意画面の後の確認画面	追加操作が増えても登録を完了できるか

どちらでも利用者の選択を正しく扱います。認証プロバイダー配下のチャネルでは、normalのオプションが初期状態で有効になる例外があります。「常にチェックが外れている」という前提で画面や計測を実装せず、実際のプロバイダーと未追加・追加済み・ブロック状態で確認します。

ログイン前の説明は具体的にします。会員証なら「ポイント残高の確認」、予約なら「予約内容の確認と変更への入口」のように利用者が使う機能を示します。配信する内容と頻度の目安を実際の運用に合わせて伝え、追加しない場合のサービス利用も分かるようにします。

ミニアプリでは、同意画面に依存しない入口を用意する

日本の新規ミニアプリチャネルでは、チャネル同意の簡略化が常に有効に設定されます。ただし実際の動作には認証済みであることなどの条件があり、未認証では開発用・審査用に限られます。動作時に同意画面が省略されると、その画面にあった友だち追加の案内も期待できません。公式の認可フローを確認し、環境ごとの違いを試験します。

追加の案内は、予約を完了した後や会員証を登録した後など、理由を説明できる場所に置けます。最初の画面で何度も案内するより、利用者が必要とする操作の流れに組み込み、既に友だちなら重ねて案内しない設計を検討します。

requestFriendshipの完了を、追加成功とみなさない

liff.requestFriendship()は、友だち追加やブロック解除を促す画面を表示するAPIです。呼び出しが完了しても、利用者が追加したかどうかは戻り値では分かりません。呼び出し後にliff.getFriendship()で関係を確認します。Fullサイズなどの利用条件はLIFFリファレンスで確認できます。

非対応の環境や設定不備で表示できないときも、予約完了画面や会員証まで失敗させないようにします。友だち追加の案内と、ユーザーが既に完了した業務処理を分離することが大切です。

計測は「表示・選択・状態・利用」を別々に残す

LINEログインのfriendship_status_changedがtrueでも、新規追加とブロック解除の両方が含まれます。falseには以前からの友だちと、今回追加しなかった人の両方が含まれます。また画面が出ない場合は、このパラメータ自体がないことがあります。値だけで新規獲得数を確定させません。

計測イベントの設計例	目的	集計の注意
追加案内を表示	どの入口が利用されたかを見る	同じ利用者の再表示を区別する
追加案内のボタンを押す	文言や位置の反応を見る	友だち追加成功とは分ける
友だち状態を再確認	操作後の状態を確認する	確認前から友だちだった人を分ける
会員連携を完了	会員に対応した通知の準備を把握する	誤連携や連携解除も運用で追う
予約・購入を完了	利用者の目的を達成できたかを見る	追加数だけで施策を評価しない

分析ツールへLINEユーザーID、会員番号、電話番号をそのまま送らない設計にします。計測に必要な区分と、認証・通知のための個人別データは用途を分け、保存先と閲覧権限を決めます。

架空例：EC会員登録後に配送通知を案内する

会員登録後の画面で、配送状況への入口と受け取りたい通知を説明するECを考えます。未追加の人には追加の案内を出し、追加後に関係を再確認します。すでに友だちの人には案内を繰り返さず、会員とLINEの対応が完了したことを表示します。

このとき、友だち追加を断った人の注文まで取り消す設計にはしません。注文履歴や別の連絡手段で確認できるようにします。またPush送信の受付が成功しても、ブロックなどで届かない場合があるため、発送通知の送信結果だけで配送状況の確認済みとは扱いません。EC側の設計はECとLINEの連携で詳しく説明します。

公開前にテストする利用者の組み合わせ

未ログイン、既存会員、新規会員、友だち未追加、友だち追加済み、ブロック済みを組み合わせて確認します。特に「既存会員が別のLINEでログイン」「追加を断って戻る」「外部ブラウザで開く」「同意を取り消した後に再利用」の経路を含めます。

受入条件は、案内が出ることだけでなく、不要な案内が出ないこと、追加しなくても処理済みの予約や注文が残ること、別人への通知が起きないことまで定義してください。

よくある質問

LINEログインに成功したら友だち追加も完了していますか？

ログイン成功と友だち追加は別です。友だち追加オプションやアプリ内の案内を設定し、対象の公式アカウントとの関係を確認します。会員連携も別に確認してください。

bot_promptは常に未選択で表示されますか？

一律ではありません。認証プロバイダー配下のチャネルでは、normalのオプションが初期状態で有効になる場合があります。実際のチャネル構成と利用者の友だち状態で表示を確認します。

requestFriendshipが完了したら追加成功としてよいですか？

できません。戻り値では利用者が追加やブロック解除をしたか分かりません。呼び出した後の友だち関係をgetFriendshipで確認し、案内の表示やクリックとは別に集計します。

友だち追加をしない人にはサービスを使わせない設計が必要ですか？

本記事の設計では、友だち追加と予約・会員証などの業務を分けます。通知を受けない場合も、処理済みの予約や注文を確認できる画面や別の案内経路を用意します。

この記事に関連するサービス

TodoONadaでは、LINEログインと会員基盤の連携、友だち追加の案内、状態に応じた表示・計測を支援しています。現在の登録画面と、届けたい通知から設計を整理できます。

LINEアプリ開発のサービス・相談窓口を見る