LIFF URLの「?」処理変更への対応方法｜画面表示・計測・外部遷移を確認するポイント

2026年9月1日 12:23

LIFF URLのクエリパラメータの値に含まれる「?」の処理変更では、2次リダイレクト先URLの生成結果が変わる場合があります。特に、値の中に別のURLを含めている場合や、LIFF URLの情報をもとに画面表示、計測、外部ページへの遷移を行っている場合は、既存施策への影響確認が必要です。本記事では、影響が起こりやすい実装を具体的に整理し、なぜ確認が必要なのか、どのようなテストを行えばよいのか、今後の設計で何に注意すべきかを解説します。

1. 今回の変更で対応が必要になる理由

LIFF URLのクエリパラメータの値に含まれる「?」の処理が変わると、2次リダイレクト先URLの形が変わる場合があります。

これは、LIFF URLそのものが開けなくなるという意味ではありません。

問題になる可能性があるのは、2次リダイレクト後のURLを、LIFFアプリやサーバーがどのように読み取っているかです。

例えば、次のLIFF URLを使っているとします。

Copyhttps://liff.line.me/{liffId}/?key=foo?bar

変更前は、次のように「?」が「&」へ置き換えられる場合がありました。

Copyhttps://example.com?key=foo&bar

変更後は、次のように「?」が値の一部として保持されます。

Copyhttps://example.com?key=foo?bar

この結果、アプリ側が取得する値や、サーバー側が解釈するパラメータの構造が変わる可能性があります。
例えば、変更前はkey=fooと、別の情報であるbarとして処理していたものが、変更後はkey=foo?barとして処理されます。
この変化が、施策の目的に合っているかどうかが重要です。
変更後の仕様に沿って正しく動く実装であれば、対応は不要な場合もあります。
一方、変更前の変換結果を前提にしている実装では、画面表示、計測、予約や応募の情報、外部サイトへの遷移などに影響が出る可能性があります。
そのため、すべてのLIFF URLを一律に作り直すのではなく、まずは「値の中にさらにURLや記号を含めているか」「その値をどのように利用しているか」を確認することが適切です。

2. 外部URLをパラメータの値として渡している場合

影響を受ける可能性が高いのが、クエリパラメータの値として別のURLを渡しているケースです。
例えば、次のようなLIFF URLです。

Copyhttps://liff.line.me/{liffId}/?return_url=https://example.com/path?campaign=spring

この例では、return_urlの値として、次のURLを渡しています。

Copyhttps://example.com/path?campaign=spring

外側のLIFF URLと、値として渡している内側のURLの両方に「?」があります。
このような構成では、LIFF URLから2次リダイレクト先URLを生成するときに、どの「?」がパラメータの開始位置で、どの「?」が値の一部なのかを正しく扱う必要があります。
変更前の処理では、値の中にある「?」が「&」に置き換えられる場合がありました。
その場合、次のような結果になる可能性があります。

Copyhttps://example.com?return_url=https://example.com/path&campaign=spring

この形になると、campaign=springがreturn_urlの値の一部ではなく、外側のURLにある別のパラメータのように扱われる可能性があります。
変更後は、次のように「?」が値の中に保持されます。

Copyhttps://example.com?return_url=https://example.com/path?campaign=spring

この変更によって、URLの値が本来意図した形に近づく場合があります。
ただし、既存のアプリ側が変更前の形を前提にしている場合、必ずしもそのまま正常に動くとは限りません。
例えば、変更前のURLからcampaignを外側のパラメータとして取り出していた場合、変更後は同じ方法で取得できなくなる可能性があります。
この問題を防ぐには、まず外部URLを値として渡しているLIFF URLを洗い出します。
パラメータ名としては、return_url、redirect_url、callback_url、nextなどが使われることがあります。
ただし、名称はシステムごとに異なるため、名前だけで判断するのは不十分です。
実際の値にhttp://やhttps://が含まれているか、値の中にさらに?や&が含まれているかを確認してください。
次に、外側のURLを解析した後、取得した値を内側のURLとしてどのように処理しているかを確認します。
外側のURLからreturn_urlの値を取得し、その値をもう一度URLとして解析する構成では、2段階の処理が必要になります。
URL全体を文字列として分割するのではなく、URL解析のための標準機能を利用し、外側と内側を分けて処理することが重要です。
また、外部URLをそのままパラメータの値として渡す構成は、URLの構造が複雑になりやすいという課題があります。
可能であれば、次のように遷移先を示すIDだけを渡す設計に変更する方法もあります。

Copyhttps://liff.line.me/{liffId}/?destination_id=campaign_spring

LIFFアプリやサーバー側でcampaign_springに対応する遷移先URLを管理すれば、LIFF URL内に別のURLを含めずに済みます。
この方法であれば、URL内の「?」や「&」の扱いが複雑になりにくく、将来的な仕様変更の影響も抑えやすくなります。

3. キャンペーンや流入元を計測している場合

LIFF URLにキャンペーン名、広告媒体、店舗名、QRコードの識別情報などを付け、流入元や表示内容を管理している場合も確認が必要です。
例えば、次のようなURLです。

Copyhttps://liff.line.me/{liffId}/?campaign=spring2026

このように、値の中に「?」が含まれない単純な構造であれば、今回の変更による直接的な影響は限定的です。
一方、計測用のURLや広告クリック用のURLを、パラメータの値として渡している場合は注意が必要です。
例えば、次のような構成です。

Copyhttps://liff.line.me/{liffId}/?tracking_url=https://example.com/?utm_source=line

変更前と変更後で、utm_source=lineの部分がどのパラメータに属するかが変わる可能性があります。
その結果、次のような事象が起こる可能性があります。
✅キャンペーン別の画面が表示されない
✅広告媒体の情報が記録されない
✅流入元が不明になる
✅想定していないキャンペーンに分類される
といった問題です。
ここで重要なのは、画面が正常に表示されることと、計測が正常に行われることは別だという点です。
ユーザーが正しい画面を見ていても、計測用の値だけが取得できていない場合があります。
そのため、テストでは画面表示だけでなく、計測システムに必要な情報が送られているかを確認する必要があります。
また、LIFFの追加情報は、liff.init()の処理を経て最終的なURLに復元されます。
初期化前に計測タグがURLを読み取ると、まだ最終的なパラメータが復元されておらず、キャンペーン情報を取得できないことがあります。
計測処理は、原則としてliff.init()の完了後に実行します。

Copyawait liff.init({
  liffId: "1234567890-AbcdEfgh"
});

// 初期化完了後に計測やパラメータ取得を行う
const params = new URLSearchParams(location.search);
const campaign = params.get("campaign");

ページビュー計測や広告効果測定を行っている場合は、どのURLを対象に計測しているかも確認してください。
1次リダイレクト先URLを計測しているのか、2次リダイレクト後の最終URLを計測しているのかによって、記録される値が異なります。
LIFFの初期化前にアクセス解析ツールへURLを送信すると、LIFF SDKが一時的に付与する情報が記録される可能性もあります。
そのため、初期化完了後に最終的な画面とパラメータを基準に計測する設計が望まれます。

4. パラメータによって画面を出し分けている場合

LIFF URLの追加情報を利用して、表示する画面を切り替えている場合も確認が必要です。
代表的な例は、店舗別、商品別、イベント別、会員区分別、キャンペーン別の画面表示です。
例えば、次のURLからアクセスした場合に、渋谷店の予約画面を表示するとします。

Copyhttps://liff.line.me/{liffId}/?store=shibuya

このような単純な構造であれば、今回の「?」の処理変更による影響は限定的です。
ただし、値の中に別のURLや複数の情報を含めている場合は、値の取得結果が変わる可能性があります。
例えば、次のような構成です。

Copyhttps://liff.line.me/{liffId}/?target=store_shibuya?campaign=spring

変更前は、target=store_shibuyaとcampaign=springのように処理されていたものが、変更後はtarget=store_shibuya?campaign=springとして扱われる可能性があります。
この違いを考慮していない場合、店舗やキャンペーンの判定が正しく行われないことがあります。
画面の出し分けに失敗すると、ユーザーには別の店舗の情報が表示される、対象外のキャンペーンが表示される、予約対象の商品が誤って表示される、といった問題につながります。
この問題を防ぐには、まず画面の出し分けに使うパラメータを整理します。
一つの値に複数の情報を詰め込むのではなく、できるだけパラメータを分けて渡します。

Copyhttps://liff.line.me/{liffId}/?store=shibuya&campaign=spring2026

この構成であれば、店舗情報とキャンペーン情報を別々に取得できます。
さらに、パラメータが取得できなかった場合の処理も決めておく必要があります。
値が空の場合に、別の店舗や別のキャンペーンを表示する設計は避けたほうが安全です。
情報が取得できない場合は、通常画面を表示する、対象情報を再確認するよう案内する、エラー画面を表示するなど、誤表示を避ける処理を用意します。
特に、予約や購入など金銭や個人情報に関係する画面では、値が不明なまま処理を進めないことが重要です。

5. URLを文字列として独自に処理している場合

LIFFアプリやサーバー側で、URLを文字列として直接分割している場合は、今回の変更による影響を受けやすくなります。
例えば、次のような処理です。

Copyconst parts = location.href.split("&");

または、URL内の「?」の位置を探して、手作業でパラメータを分ける処理です。
この方法では、パラメータの値に含まれる「?」や「&」まで区切り記号として扱う可能性があります。
変更前はたまたま期待した結果になっていても、変更後に値の中の記号が異なる形で保持されると、処理結果が変わる場合があります。
URLを扱う場合は、可能な限り標準のURL解析機能を使います。
JavaScriptであれば、URLやURLSearchParamsを使って、URLの構造に沿ってパラメータを取得します。

Copyconst url = new URL(location.href);
const campaign = url.searchParams.get("campaign");

ただし、パラメータの値の中にさらにURLが入っている場合は、外側の値を取得した後、その値を内側のURLとして処理する必要があります。

Copyconst url = new URL(location.href);
const returnUrl = url.searchParams.get("return_url");

if (returnUrl) {
  const destination = new URL(returnUrl);
  const campaign = destination.searchParams.get("campaign");
}

実際の処理では、入力値が正しいURLかどうか、許可された遷移先かどうかを確認する必要があります。
特に、ユーザーが自由に指定できるURLへ無条件に遷移する処理は、別の安全上の問題につながる可能性があります。
遷移先を限定する、識別IDで管理するなど、システム全体の設計を確認してください。
今回の変更への対応として重要なのは、変更前の文字列形式に合わせて処理を修正することではありません。
変更後の正しいURL構造を前提に、URL解析の方法そのものを見直すことです。

6. liff.init()前にURLを読み取っている場合

LIFF URLに付けた追加情報は、1次リダイレクト先URLでは一時的にliff.stateへ保存され、liff.init()の処理を通じて最終的なURLに復元されます。
そのため、liff.init()の完了前にURLを読み取ると、目的のパラメータが取得できない可能性があります。
例えば、次のようなコードです。

Copyconst params = new URLSearchParams(location.search);
const store = params.get("store");

liff.init({
  liffId: "1234567890-AbcdEfgh"
});

この処理では、liff.init()が完了する前にstoreを取得しています。
その時点では、LIFF URLに付けた情報がまだ復元されていない可能性があります。
基本的には、次のように初期化完了後にURLを読み取ります。

Copyawait liff.init({
  liffId: "1234567890-AbcdEfgh"
});

const params = new URLSearchParams(location.search);
const store = params.get("store");

また、初期化完了前に次のような処理を実行していないか確認してください。
ページを別のURLへ移動させる処理、history.pushState()やhistory.replaceState()によるURL変更、SPAルーターの初期化、計測タグによるURL取得、サーバー側の301や302リダイレクトなどです。
これらの処理が先に動くと、LIFF SDKが利用する情報が失われたり、LIFFアプリが正しい2次リダイレクト先URLへ移動できなくなったりする可能性があります。
今回の仕様変更への対応としては、パラメータ取得処理だけを確認するのではなく、LIFFアプリ起動直後に実行される処理全体を確認することが重要です。
共通レイアウトや共通スクリプトの中で、担当者が意識していないURL変更処理が行われていることもあります。

7. リッチメニューやQRコードなど複数の導線で使っている場合

同じLIFFアプリを、複数のマーケティング施策で利用しているケースは少なくありません。
例えば、LINE公式アカウントのリッチメニュー、メッセージ、QRコード、広告、ウェブサイト上のボタンなどです。
この場合、現在使っているURLを一つ確認しただけでは不十分です。
過去のキャンペーンで作成したQRコードや広告素材が、現在も配布・掲載されている可能性があります。
また、ユーザー属性や期間に応じて表示されるリッチメニューが切り替わる場合、普段の確認対象に含まれていないメニューが存在することもあります。
まず、LIFF URLの一覧を作成します。
一覧には、どの施策で使っているか、どの画面へつながるか、どのパラメータを付けているか、値の中に別のURLが含まれているかを整理します。
次に、各URLを実際の利用環境で確認します。
店舗用、キャンペーン用、広告用など、用途が異なるURLは個別にテストします。
単にLIFFアプリが開くかどうかだけでなく、最終画面で正しい情報が表示されるか、外部ページへ正しく移動できるか、計測情報が残るかを確認します。
特に、同じLIFFアプリでありながら、導線ごとにパラメータの付け方が異なる場合は注意が必要です。
一つの導線では単純な値を使い、別の導線では外部URLを値として渡していることがあります。
なお、リッチメニューの切り替えに使うリッチメニューエイリアスは、今回の変更対象であるLIFF URLのクエリパラメータとは別の仕組みです。
リッチメニューエイリアスを利用していること自体が問題になるわけではありません。
確認すべきなのは、リッチメニューのリンク先として設定されているLIFF URLの構造です。

8. 変更前後のテストを行う意義

変更前後のテストは、単にブラウザのアドレスバーに表示されたURLを見比べるために行うものではありません。

テストの目的

LIFF URLに付けた情報が、ユーザーが最終的に見る画面まで正しく届き、施策に必要な処理が最後まで実行されることを確認することです。
例えば、店舗情報を渡している場合、確認すべきなのはURLの中にstore=shibuyaという文字が残っているかだけではありません。
実際に渋谷店の画面が表示されるか、渋谷店に対応した予約枠が表示されるか、別の店舗情報が混ざっていないかまで確認する必要があります。
キャンペーン情報を渡している場合も同様です。
キャンペーン専用の画面が表示されるか、応募内容が正しく引き継がれるか、計測システムにキャンペーン情報が記録されるかを確認します。
外部URLを渡している場合は、最終的に正しいページへ移動できるか、外部URLの中に含まれるパラメータが失われていないかを確認します。
URLの見た目だけでは、アプリ内部でどのように解釈されているか分かりません。
そのため、実際のユーザー行動に沿って確認することが重要です。
また、今回の変更は、アクセス環境によって挙動が異なる場合があります。
iOS端末とAndroid端末、LINEアプリ内とLINEアプリ外では、同じLIFF URLでも処理結果が異なる可能性があります。
したがって、パソコンのブラウザだけで確認しても、実際のユーザー環境で発生する問題を見つけられないことがあります。

テストでは、次の段階を確認します。
まず、LIFF URLを開いたときに、1次リダイレクトから2次リダイレクトへ正常に進むかを確認します。
次に、liff.init()が完了した後、追加情報を正しく取得できるかを確認します。
その後、取得した情報に応じて正しい画面が表示されるかを確認します。
外部URLへの遷移がある場合は、正しいページへ移動できるか、戻り先のURLに必要な情報が残っているかを確認します。
最後に、キャンペーンや広告の計測結果を確認します。
この一連の確認を行うことで、画面表示だけでは発見できない、計測やデータ連携の問題も見つけやすくなります。

9. 実務で行う確認手順

まず、現在運用しているLIFF URLを洗い出します。
LINE公式アカウントのメッセージ、リッチメニュー、QRコード、広告、ウェブサイト、メール、紙の販促物など、ユーザーがアクセスできる場所を確認します。
次に、URLに付いているパラメータを整理します。
単純な店舗名やキャンペーン名だけなのか、値の中に別のURLが入っているのか、複数の情報を連結しているのかを確認します。
その後、LIFFアプリ側の処理を確認します。
追加情報を取得するタイミングがliff.init()の完了後になっているか、liff.stateなどのLIFF用パラメータを変更していないか、URLを文字列として直接分割していないかを確認します。
続いて、テスト用のURLを作成します。
通常の値だけでなく、値の中に「?」を含むケース、値をパーセントエンコードしたケース、値に別のURLを含めるケースを用意します。
例えば、次のようなURLです。

Copyhttps://liff.line.me/{liffId}/?key=foo?bar

Copyhttps://liff.line.me/{liffId}/?key=foo%3Fbar

Copyhttps://liff.line.me/{liffId}/?return_url=https://example.com/path?campaign=spring

これらを、実際の施策に近い環境で開きます。
確認する環境は、少なくともiOS端末、Android端末、LINEアプリ内、LINEアプリ外を組み合わせます。
テスト結果は、次の内容が分かるように記録します。
使用したLIFF URL、端末、OS、LINEアプリ内外の別、1次リダイレクト後の状態、2次リダイレクト後のURL、パラメータ取得結果、最終画面、外部ページへの遷移結果、計測結果です。
変更前と変更後の結果を同じ形式で残すと、どの段階で差が発生したのかを比較できます。
問題があった場合は、まずURLの生成、LIFFの初期化、パラメータ取得、画面表示、外部遷移、計測のどこで結果が変わったのかを切り分けます。
画面が表示されない場合でも、原因が必ずしもURLの生成にあるとは限りません。
初期化前のURL変更、サーバー側のリダイレクト、ルーターの処理、計測タグの読み込み順など、周辺処理が原因である可能性もあります。

10. リッチメニューエイリアスとの関係

リッチメニューエイリアスとは、リッチメニューを参照するための識別名です。
リッチメニューを切り替える際に、リッチメニューIDを直接指定するのではなく、リッチメニューIDと紐づいたエイリアスを指定して利用します。
このリッチメニューエイリアスと、今回変更されるLIFF URLのクエリパラメータに含まれる「?」は、別の仕組みです。
そのため、リッチメニューエイリアスを使っていること自体が、今回の変更による影響を意味するわけではありません。
確認が必要なのは、リッチメニューのリンク先としてLIFF URLを設定している場合です。
例えば、次のように単純な店舗情報を渡している場合は、比較的確認しやすい構成です。

Copyhttps://liff.line.me/{liffId}/?store=shibuya

一方、次のようにパラメータの値に別のURLを含めている場合は、2次リダイレクト後の処理を確認します。

Copyhttps://liff.line.me/{liffId}/?return_url=https://example.com/?source=menu

複数のリッチメニューを期間やユーザー属性に応じて切り替えている場合は、現在表示されているメニューだけでなく、切り替え先のメニューも確認対象にします。
過去のキャンペーンで使用したリッチメニューが残っている場合は、そのリンク先も棚卸しします。

11. まとめ

今回の変更で確認が必要なのは、LIFF URLそのものが使えなくなるからではありません。
LIFF URLのクエリパラメータの値に含まれる「?」の扱いが変わり、2次リダイレクト先URLの形が変わる可能性があるためです。
特に確認が必要なのは、値の中に別のURLを含めている実装です。
別のURLを値として渡す場合、外側のLIFF URLと内側のURLの両方に「?」が含まれることがあります。
この構造では、変更前と変更後で、どの情報が一つの値として扱われるか、どの情報が別のパラメータとして扱われるかが変わる可能性があります。
その結果、外部ページへ正しく戻れない、キャンペーン情報を取得できない、画面の出し分けに失敗する、計測データが欠落するといった問題につながる可能性があります。
また、URLを文字列として直接分割している実装や、liff.init()の完了前にURLを読み取っている実装も確認が必要です。
対応の基本は、次のとおりです。
✅liff.init()の完了後に追加情報を取得すること
✅liff.stateなどliff.で始まるパラメータを変更しないこと
✅URLを?や&で単純に分割せず、標準のURL解析機能を使うこと
✅外部URLを値として渡す場合は、必要に応じて識別IDを渡す設計へ見直すこと
です。
さらに、テストではLIFFアプリが開くかどうかだけでなく、最終画面、画面の出し分け、外部ページへの遷移、キャンペーンや広告の計測まで確認する必要があります。
これは、今回の変更がURLの途中にある処理だけでなく、最終的にユーザーが見る画面や、企業側が取得するデータに影響する可能性があるためです。
まずは、現在利用しているLIFF URLを一覧化し、値の中に「?」や別のURLが含まれているものを優先的に確認してください。
そのうえで、実際に利用されている端末とアクセス経路を使い、変更後の挙動をテストします。
LIFF URLの数が多い場合や、複数のシステム、広告計測、予約・応募フォームが連携している場合は、URLだけでなく、LIFFアプリ、サーバー、計測ツールを含めて確認する必要があります。
自社のLIFF施策に影響があるか判断しにくい場合は、利用中のLIFF URL、パラメータの用途、現在の遷移結果、想定している動作を整理したうえで、専門家へ相談すると原因の切り分けを進めやすくなります。

今回も最後までお読みいただき、ありがとうございました。記事に関するご質問、お問い合わせは下記のバナーもしくは質問箱（https://note.com/qa/fourglobe_uz）までお気軽にお寄せください。

■LINEマーケティングのご相談ならフォーグローブにおまかせ！

フォーグローブはLINE Technology Partnerコミュニケーション部門およびLINEミニアプリ部門の２部門を取得し、LINEサービスの導入には高度な知見とノウハウを持っています。長年のデジタルマーケティング支援の実績も豊富で、LINEマーケティングの導入には特に高度な知見とノウハウを持っています。マーケティング施策の改善提案や、業務に寄り添った広告やLINEミニアプリをはじめとしたツールの導入についても、お気軽にご相談ください！