既存LIFFをLINEミニアプリへ展開する手順。会員・URL・運用を引き継ぐ

既存のLIFFアプリをミニアプリとして提供するときは、画面の再利用、利用者の引き継ぎ、公開する入口の変更を分けて計画します。URLの差し替えだけで済むと見積もると、既存会員が別人として登録されたり、過去の予約リンクが開けなくなったりする問題を見落とします。

2026年9月8日確認時点の公式FAQでは、LINEログインチャネルで作成したLIFFアプリをLINEミニアプリチャネルへ直接移行することはできないと案内されています。一方、既存Webアプリを新しいミニアプリから利用する構成は検討できます。本記事の「移行」は、この再利用と切り替えを含む開発計画を指します。

移行の目的を、必要な機能で説明する

新規作成ではミニアプリが推奨されていますが、既存サービスの切り替え時期は、自社の改修予定と必要機能から決めます。「新しい名称だから」だけでは、利用者に再操作を求める理由になりません。LIFFとミニアプリの比較を使い、追加したい価値と現在の依存を並べてください。

検討理由	移行前に確認すること	判断に使う成果物
予約通知をサービスメッセージにしたい	認証審査、テンプレート、対象操作との対応	通知一覧と申請計画
既存Web画面をLINEで使いたい	LINE認証、画面サイズ、戻る操作	実機の画面遷移表
複数LIFFの構成を整理したい	1ミニアプリチャネルにまとめられる範囲	チャネルと機能の対応表
開発会社から引き継ぎたい	ソース、アカウント、サーバーの管理権限	引き継ぎ対象一覧

現行サービスが安定している場合も、改修対象と障害時の連絡先は把握します。移行を実施するかの判断と、保守の担当を決めることは別の仕事です。

最初に棚卸しするのは、画面より会員と入口

開発者には、利用中のLIFF ID、プロバイダー、チャネル、エンドポイント、SDK、利用APIを一覧にしてもらいます。さらに、リッチメニュー、Webサイト、紙のQR、過去の配信、メール、ブックマークなど、旧URLが残る場所を洗い出します。更新できない紙や過去メッセージの存在が、旧環境を残す期間に影響します。

ミニアプリは同一チャネルに複数Webアプリを追加できず、画面サイズはFullです。モジュールモードによるアクションボタン非表示も使えません。これらは公式の構成差として確認できるため、現在の画面がそのまま成立するか、実装前に試作で確認します。

ユーザーIDはプロバイダー単位で考える

同じLINEアカウントでも、プロバイダーが異なるとユーザーIDは異なります。同じプロバイダー内では、チャネル種別が違っても同じユーザーIDが割り当てられます。「チャネルを作り直したから必ずIDが変わる」とも、「LINEだからすべて同じID」とも判断しません。公式のユーザーID説明と、実際の管理構成を照合します。

自社会員との対応付けはサーバー側で検証した認証情報を使います。表示名やプロフィール画像の一致で、旧会員を新アカウントへ結び付けてはいけません。プロバイダーをまたぐ場合は、既存の自社ログインなどで本人が会員を確認して連携する手順を設けます。ポイントや予約を持つ会員は、連携前後の件数と所有者まで確認します。

並行環境で確認してから、入口を順に切り替える

Webアプリをミニアプリ化する公式手順を土台に、新チャネルのLIFF IDで初期化し、必要な認証と機能を組み込みます。既存サーバーを共有する場合も、開発環境の操作が本番予約や本番通知に混ざらないよう、接続先を明示します。

段階	実施する作業	次へ進む条件
調査	会員連携、API、URL、管理権限を確認	不明な所有者や接続先を特定できた
試作	新チャネルと既存画面を接続	主要操作と認証の差分を説明できた
並行確認	新旧から同じテスト会員を操作	予約・残高・権限の整合が保てた
公開準備	必要な審査、通知、問い合わせ案内を準備	本番条件で受入確認が終わった
切り替え	更新可能な入口から新URLへ変更	新旧どちらの入口でも業務を継続できる
旧環境の整理	残るアクセスと未完了取引を確認	過去URLへの案内と保管対象が決まった

旧URLから新URLへ案内するときは、予約詳細のパラメータやログイン前後の戻り先も設計します。単純な転送が、他会員の情報を開く入口にならないよう、遷移先で権限を再確認します。

同意と友だち追加は、新旧で同じとは限らない

日本の新規ミニアプリチャネルではチャネル同意の簡略化が有効に設定されますが、実際の動作には認証状態やSDK、起動経路の条件があります。未認証では開発用・審査用でのみ動作するため、その環境の結果を本番へそのまま当てはめないでください。

簡略化が動く場面では、最初からプロフィール取得権限があると決めつけず、必要な時点で確認します。同意画面頼みだった友だち追加も見直します。認可フローの公式条件と友だち追加の設計を照合し、ログイン、会員連携、友だち状態を別々に検証します。

架空例：会員予約LIFFを、受付を止めずに切り替える

会員番号と次回予約を持つサロンを想定します。新ミニアプリも既存予約DBを参照し、切り替え中に予約データを二重に作らない構成にします。初期確認ではスタッフのテスト会員だけを使い、旧入口で作った予約が新入口から確認・変更できるかを確認します。

問題がなければ店頭QRとリッチメニューを更新し、過去の配信にある旧URLは一定期間案内用に残します。切り戻し条件には、会員の取り違え、予約更新の失敗、主要端末でのログイン不可などを設定します。切り戻す場合も新環境で作った予約を失わないことが条件です。これは設計例であり、実際の移行日数や成果を示すものではありません。

発注前に合意する受入条件

確認対象	確認方法
会員の引き継ぎ	新旧で同じ会員に対応し、他会員へ切り替わらない
履歴と残高	過去の予約・利用履歴・ポイントが欠落しない
起動経路	QR、過去の配信、外部ブラウザから主要操作を完了できる
通知	新旧の処理が同じ予約へ二重通知しない
切り戻し	入口を戻しても、切り替え期間中の更新を保持できる
運用移管	新チャネルの権限、監視、更新手順を自社で確認できる

これらを要件定義テンプレートの受入条件へ追加すると、画面の作成範囲だけで見積もることを避けられます。

よくある質問

LIFF IDを変えれば移行は完了しますか？

完了とはいえません。会員の対応付け、権限、通知、旧URL、外部ブラウザの動作まで確認します。新しいチャネルで既存Web実装を再利用する場合も、切り替え前後の業務データの整合を受入条件にします。

チャネルが変わるとユーザーIDも必ず変わりますか？

必ず変わるわけではありません。ユーザーIDはプロバイダー単位で発行されます。同じプロバイダー内かどうかを確認し、異なる場合は既存会員を本人が確認して連携する手順を設計します。

旧LIFFのURLはすぐ削除できますか？

過去の配信、紙のQR、未完了予約などに残っている可能性があります。残存する入口と業務への影響を調べ、案内期間、保存するデータ、旧環境を終了する条件を決めてから整理します。

認証審査が終わる前に確認できますか？

未認証ミニアプリとして開発・動作確認を進められます。ただし、開発用環境で使えた認証済み向け機能が、未認証の本番で使えるとは限りません。認証状態と環境を分けた試験が必要です。

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

TodoONadaでは、既存LIFFの構成調査から、会員連携・旧URL・運用を引き継ぐミニアプリ開発まで支援しています。現在の管理状況と、移行で実現したい機能から相談できます。

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