LINEミニアプリとLIFFの違い。新規開発・既存アプリの選び方【2026年】

LINEミニアプリとLIFFの違い。新規開発・既存アプリの選び方【2026年】

LINEの中で予約画面や会員証を提供する新規開発では、LINEミニアプリを基本候補にして、必要な機能と運用条件を確認する進め方が適切です。LINE Developersも、新たなLIFFアプリはLINEミニアプリとして作成することを推奨しています。新規作成についての公式案内

一方、既存のLIFFアプリがある場合は、チャネルの設定だけでミニアプリに変えられるわけではありません。本記事では、新規の方式選定と既存サービスの見直しを分け、発注前に決めることを整理します。日本向けサービスを想定し、公式仕様は2026年9月8日に確認しています。

LIFFは実装の仕組み、ミニアプリは提供の枠組み

LIFFはLINE Front-end Frameworkの略称で、LINEと連携するWebアプリを作る仕組みです。LINEミニアプリもLIFF上で動作します。そのため、「ミニアプリにするならHTMLやJavaScriptを捨てて作り直す」という関係ではありません。

比較するときは、LINEログインチャネルに登録するLIFFアプリと、LINEミニアプリチャネルで提供するサービスを分けます。さらにミニアプリには、認証審査に通過していない未認証ミニアプリと、通過した認証済ミニアプリがあります。ミニアプリの構造と認証区分

比較項目LINEログインチャネルのLIFFアプリ未認証ミニアプリ認証済ミニアプリ
登録するチャネルLINEログインLINEミニアプリLINEミニアプリ
Web画面の実装LIFF SDKとWeb技術LIFF SDKとWeb技術LIFF SDKとWeb技術
ミニアプリの認証審査対象外通過前でも未認証として公開可能通過が必要
認証バッジミニアプリのバッジは付かない付かない付く
サービスメッセージミニアプリの機能としては使えない公開環境では使えない用途・テンプレート等の条件を満たして利用
LINE内の検索からのアクセスミニアプリの検索対象とは別認証済限定の検索機能は使えない対象機能を利用可能。掲載や集客成果の保証ではない
LIFFブラウザの画面サイズCompact・Tall・Fullから選択FullFull
1チャネルのアプリ登録複数LIFFアプリを登録可能1つのWebアプリ1つのWebアプリ

画面サイズとチャネル構成の違いはLIFFの登録仕様、ミニアプリ側の制限はミニアプリの公式説明に基づきます。認証済であればあらゆる機能を無条件に利用できる、という区分ではありません。機能ごとの提供地域や利用条件も確認します。

また、公式アカウントの認証とミニアプリの認証は別の対象です。会社の公式アカウントに認証バッジがあっても、それだけでミニアプリの認証済機能が使えるとは判断しません。

新規開発では、必要な機能から認証の要否を決める

未認証で始めるかどうかは、公開時点で使う機能から決めます。「まず簡単に出したい」という希望だけで決めると、予約確認の通知まで含めたサービスを完成できないことがあります。

検討している用途・条件方式を選ぶ際の判断発注時に残す確認項目
既存の友だちへ予約画面や会員証を提供したい未認証ミニアプリを含めて検討ログイン、会員連携、通知に必要な機能が公開環境で使えるか
ミニアプリのサービスメッセージを使いたい認証済ミニアプリの条件を確認通知用途、使用するテンプレート、審査に必要な準備
LINE内での検索導線などを利用したい認証済の機能を確認公開後の入口の用意と計測。自然に利用者が増える前提にしない
既存のLINEログインチャネルに複数LIFFをまとめている現状の管理単位と新規構成を比較利用者・URL・権限・保守を分ける必要があるか
小さな高さのLIFF画面が必須LIFF側の画面サイズとミニアプリのFullを比較画面の大きさを変えて同じ業務を実現できるか
LINEを使わない顧客にも同じ受付を提供したい外部ブラウザ向けの動作を合わせて設計LINEログイン不要の受付、利用できない機能の代替

たとえば、店舗の予約画面を未認証ミニアプリとして公開し、別途、公式アカウントからMessaging APIで確認通知を送る構成は検討できます。ただし、その場合はMessaging APIの送信条件を満たす必要があります。認証済ミニアプリのサービスメッセージをそのまま代用できる、という意味ではありません。

通知がサービスの必須要件なら、画面の方式と同時にLINE APIの送信条件を確認します。受付全体の構成はLINE予約システムの作り方でも比較できます。

予約通知と販促配信を同じ機能にまとめない

認証済ミニアプリのサービスメッセージは、ユーザーの操作に対する確認や応答を通知する機能です。公開環境での利用には認証が必要で、広告や販促を含む通知には使えません。テンプレートの利用にも審査条件があります。サービスメッセージの公式仕様

発注資料では、通知ごとに目的を一行ずつ書くと、適切な方式を選びやすくなります。

通知の例業務上の目的設計時に決めること
予約を受け付けた直後の案内受付状態を知らせる仮受付か予約確定か。画面にも同じ状態を表示するか
予約前日の案内予約した内容を思い出してもらう変更・取消済みを除外する時点、通知手段の利用条件
店舗側による急な予約変更顧客に変更の確認を依頼する送信記録と顧客の確認を分け、未確認時に誰が対応するか
新メニューや割引のお知らせ販促サービスメッセージに混ぜず、配信手段と対象条件を確認する

いずれの構成でも、通知の送信結果だけで予約や同意が完了したことにしない設計が必要です。自社システム側に確定した記録を置き、顧客が画面から確認できる状態を用意すると、問い合わせ時の説明が揃います。

既存LIFFは「チャネルの直接移行」と「実装の再利用」を分ける

2026年9月8日に確認した公式FAQでは、LINEログインチャネルで作成したLIFFアプリを、LINEミニアプリチャネルへ移して未認証・認証済ミニアプリにすることはできないと説明されています。

一方、既存Webアプリの画面やサーバーを材料に、新しくミニアプリとして提供することは可能です。公式にも、チャネル作成、LIFF SDKの組み込み、認証や必要機能の実装、エンドポイント設定などの手順があります。既存Webアプリのミニアプリ化

したがって、移行の見積もりは「LIFFをミニアプリに変更」という一式ではなく、次の単位で確認します。

調査するもの再利用を検討できる部分改修・確認が必要になる部分
顧客向け画面HTML・CSS・画面部品・入力検証ヘッダー、画面サイズ、LIFF ID、ブラウザごとの操作
業務サーバー予約・会員・注文などの処理認証トークンの検証先、公開用設定、必要なAPI変更
会員データ既存の会員番号と業務履歴LINEユーザーIDの対応、既存連携の維持・再連携
利用者の入口自社サイトや管理できるリンクリッチメニュー、配布済みQR、ブックマーク、通知内URL
通知業務イベントの判定や予約日時の記録Messaging APIとサービスメッセージの選択、送信先との対応
運用問い合わせ窓口、障害対応の知識新旧の切り替え手順、監視、旧環境を終了する条件

LINEユーザーIDはプロバイダーごとに発行され、同じプロバイダー内ではチャネルの種類が異なっても同じユーザーIDになります。ユーザーIDの公式仕様を踏まえ、既存と新規のチャネルがどのプロバイダーに属するかを先に確認します。画面を再利用できることと、会員連携を無条件に引き継げることは別です。

既存LIFFを継続するかどうかも、この棚卸しで判断します。必要な機能が現行構成で足り、保守できる状態なら、ブランド統合の方針だけを理由に直ちに全面改修する必要があるとは読み取れません。一方、認証済ミニアプリの機能が必要なら、新しいチャネルと切り替えを含めて計画します。

同意画面と外部ブラウザは、見た目以外の変更点になる

起動できても、必要なプロフィール情報が揃うとは限らない

日本では2026年1月8日以降に作成したミニアプリチャネルで、チャネル同意の簡略化が常に有効になります。ただし、公開環境での動作には認証済であることなどの条件があり、未認証では開発用・審査用での動作になります。プロフィール取得などの追加権限は、ユーザーID取得の権限と分けて扱います。認可フローと動作条件

発注者が確認するのは、初回起動、追加権限の拒否、既存会員へのログインという各場面で、何が表示されるかです。たとえば、表示名の取得を前提に会員レコードを作る仕組みでは、その情報が得られない場合の動作も決めておきます。

簡略化が動作し、要求する権限がopenidだけの場合は、同意画面を使った友だち追加への案内が表示されません。友だち追加が必要な業務では、画面内の案内や専用の方法を含めて導線を確認します。画面を省略できたことを、友だち追加が完了したこととして扱わないようにします。

外部ブラウザ向けの動作も必要になる

ミニアプリは2025年10月1日から外部ブラウザでも利用できるようになっています。ただし、LINE内と使える機能が同じではなく、ログインが必要な場合の処理や、利用できない機能に対する案内が必要です。外部ブラウザでの公式実装条件

「QRコードから画面が開いた」だけを完了条件にせず、次のように業務の完了まで確認します。

確認する環境・状態受入時に見ること
LINE内・初回利用同意する情報が分かり、目的の手続きに進める
LINE内・既存会員別会員を作らず、正しい履歴を表示できる
外部ブラウザ・未ログイン必要な場面でログインでき、途中の入力が失われない
LINEを利用していない顧客提供する範囲と、別の受付方法が分かる
友だち追加や追加権限を拒否使えない機能が分かり、画面が停止しない
旧URLからのアクセス切り替え後の案内ができ、同じ操作を二重登録しない

この表は受入条件の例です。実機で動作確認を済ませたコードを示すものではありません。対象端末・ブラウザ・LINEバージョンを決めたうえで、発注する試験範囲に含めます。

方式の名前より、見積もりに含む作業を比較する

ミニアプリの認証区分だけで開発費は決まりません。既存会員の引き継ぎ、外部システムの接続、スタッフ用管理画面、取消処理、試験、審査準備などが作業範囲を変えます。また、WebサーバーやDB、通知、保守などの運用費も確認が必要です。

新規開発なら、公開初日に必須の操作と、後から追加する機能を分けます。既存LIFFの見直しなら、調査、再利用、改修、切り替えの4項目を分けて依頼します。LINE開発の発注ガイドと見積もり比較を使うと、各社の提案を同じ条件で比べられます。

よくある質問

新規開発はLIFFとLINEミニアプリのどちらを選べばよいですか?

LINE Developersは、新規のLIFFアプリをLINEミニアプリとして作成することを推奨しています。ミニアプリを基本候補に、必要な通知機能、認証の要否、画面サイズ、チャネル構成を確認して決めます。

未認証ミニアプリは公開できますか?

未認証ミニアプリとして公開できます。ただし、サービスメッセージなど公開環境で使えない機能があります。審査の有無だけでなく、提供したい業務が未認証で利用できる機能に収まるかを確認します。

既存LIFFを設定変更だけでミニアプリに移せますか?

LINEログインチャネルのLIFFアプリを、そのままLINEミニアプリチャネルへ移すことはできません。既存のWeb画面や業務サーバーを再利用し、新しいミニアプリとして提供する方法はあります。URL、認証、会員連携、通知、切り替えの確認が必要です。

ミニアプリにすれば友だち追加も自動で完了しますか?

ミニアプリの利用と公式アカウントの友だち追加は別です。チャネル同意の簡略化が動作する条件では、同意画面を使った友だち追加の案内が表示されない場合もあります。業務に必要な友だち追加と通知の導線を別に設計します。

既存のWebサイトがあれば追加開発は不要ですか?

画面やサーバーを再利用できる可能性はありますが、追加開発が不要とは限りません。LIFF SDK、認証、会員との対応付け、外部ブラウザ、通知、公開設定などを確認して改修範囲を決めます。

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

TodoONadaでは、ミニアプリの新規構築や既存LIFFを含む構成の見直しを支援しています。現在のURL、実現したい機能、利用中の会員・予約システムを整理する段階からご相談いただけます。

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

出典・参照

技術ブログ一覧へ戻る