LIFF URLのパラメータが取れないとき｜初期化と店舗別リンクの確認順

LIFF URLに付けた店舗コードや流入元が取得できない場合は、まずURLを読むタイミングを確認します。追加した情報は、初期化の途中で一時的に別の形で保持されるため、liff.init()の完了前に読むと、値が空になることがあります。

2026年7月16日のLINE公式Tipsでも、パラメータは初期化を待ってから読むよう説明されています。店舗別のQRコードや、キャンペーン別の入口を作る場合は、リンクの文字列だけでなく、開いてから表示・記録されるまでの順序を確認してください。

リンクに付けた情報と、開いた直後のURLは同じ形とは限らない

LIFF URLには、パスやクエリパラメータなどの追加情報を付けられます。たとえば、店舗を表すコードを付け、同じフォームで店舗名を出し分ける設計が考えられます。

ただし、LINEからアプリが開くまでにはリダイレクトがあります。途中のURLで追加情報がliff.stateに保持され、初期化後に復元されることがあるため、開いた瞬間に普段のクエリパラメータとして探す実装は適切ではありません。

遷移の仕組みはLIFFアプリを開く公式資料を参照してください。追加情報を読みたいからといって、SDKが使うliff.で始まるパラメータを独自に削除・変更することは避けます。

処理の順序は、LIFFの初期化が完了してからURLの追加情報を読み、値が使えるかを検証し、表示や計測へ渡す形にします。初期化に失敗した場合は、成功したものとして後続処理を進めないでください。

LIFFの追加情報を使う順序。初期化の完了を待ち、復元されたパラメータを読む。店舗コードを許可した値と照合し、確認できた値だけで画面や計測を準備する。初期化失敗時は後続へ進まない。

図：追加情報を使う設計例です。初期化の失敗や不正な値を、既定の店舗へ黙って置き換えないようにします。

コードを書く場合も、初期化のPromiseが完了した後にURLを読むことが分かる構成にします。初期化前にルーターや計測タグがURLを書き換えていないかも確認してください。公式Tipsでは、これらの初期化をLIFFの初期化完了後に行う注意が示されています。

URLの値は利用者が書き換えられます。店舗コードは、画面の初期表示や流入元を示す情報には使えても、店舗の管理情報を見せる権限や、予約した本人を証明するものにはなりません。

表示する店舗は、許可したコードと照合します。存在しない値や欠けた値なら、確認できないことを示すか、店舗を選び直せる画面を用意します。何も表示せず止まることと、誤った店舗を確定することの両方を避けます。

予約や注文を送る場合は、確認画面で実際の対象店舗を表示してください。お客さんが別の店舗を希望したときは、初期値に縛られず変更できる設計にします。入力を減らすための出し分けが、間違った受付を増やさないことが条件です。

店舗別QRを使うときは、入口のコードと、お客さんが最終的に選んだ店舗を分けます。入口がA店でも、B店を選んで予約することはあり得ます。最初の値だけで予約店舗まで決めたとみなすと、効果の集計もずれます。

計測へ送る項目は、許可した店舗コードや入口の種類など、必要なものに絞ります。初期化途中のURL全体、認証用の情報、個人情報を、そのままアクセス解析の項目へ入れないでください。入口の計測自体の考え方は友だち追加経路の測定も参考になりますが、友だち追加の結果とLIFFの表示結果は別の指標です。

確認するのは、値のあるリンク、値のないリンク、存在しない値のリンクです。加えて、LINE内から開く場合と外部ブラウザーから開く場合、新しいページへ移動する場合を比べます。LIFF URLが常に同じブラウザーで開くとは保証されていないためです。

どのケースも、初期化に成功したか、表示した店舗、利用者が変更した店舗、記録した入口が説明できる状態にします。初期化できるURLの範囲は、設定したエンドポイントURLとLIFF開発手順を照合してください。

まず一つの店舗別リンクで、初期化前と後の処理順を確認します。お客さんに店舗を何度も選ばせないことと、誤った店舗を黙って決めないことを両立できれば、出し分けを増やす前の基礎になります。

仕様確認：2026年10月7日。店舗の出し分け・検証・計測の判断は設計例であり、特定サービスの完成機能を示すものではありません。