← 全記事
ガイド · 更新日

LINEミニアプリの認証審査を通す方法:提出チェックリストとよくある却下理由

LINEミニアプリの認証審査(verification review)を通すには、プロバイダー名、サービス事業主名、プライバシーポリシーに記載の企業名が同一の法人であるチャンネルを提出し、公開アクセス可能なプライバシーポリシーと利用規約のURLを添え、審査員が完了すべき予約・決済・注文の各フローに対してテストシナリオとテストアカウントを用意し、サービスがLINEミニアプリポリシーに定める禁止業種や禁止コンテンツに該当しないことを確認する必要があります。LY Corporationは通常1〜2週間で審査を完了しますが、却下された場合は修正のうえ再提出が必要で、完了予定日は指定できません。

ポイントまとめ

  • 認証は、本番環境のサービスメッセージ、カスタムパス、ホーム画面ショートカット、共通プロフィールクイック入力、同意簡易化、認証バッジ付きブランドヘッダーを使用するための唯一の手段です。
  • プロバイダー名、サービス提供者、プライバシーポリシーでユーザー情報を取得する会社の整合性を確認してください。
  • 禁止業種(ギャンブル、貸金、タバコ、婚活、寄付募集など)と禁止コンテンツ(権利侵害、誇大比較、スパム)はポリシー上の明確な門番であり、デザインの問題ではありません。
  • 審査には約1〜2週間かかり、特急枠はありません。提出後に本番Endpoint URLを変更すると再審査が発生することがあるため、事前に固定してください。
  • 本当の目的が一般のLINE顧客メッセージを受信することであれば、それは認証ステップではなく、受信アーキテクチャの独立した判断です。

認証審査で実際に見ていること

LINEミニアプリのチャンネルは、初期状態では未認証です。内部のDevelopingチャネルでは機能のテストと改善ができます。Publishedチャネルを未認証から認証済みに変更するには、チャネルをLY Corporationに提出して審査を受けます。審査で評価されるのは、識別情報の一致性、ポリシー準拠、そして審査員が実際に主要フローを完了できるかであり、アプリが起動するかどうかだけではありません。

認証は、隣接する2つの判断と混同しないでください。第一に、Verified LINE Official Account(認証済LINE公式アカウント)とは別物です。それは別の製品であり、独自の審査経路があります。公式アカウントの認証をお探しの場合は、まずLINEを利用する国と公式アカウントの選択肢ガイドをお読みください。第二に、認証が答えるのは「このミニアプリは認証済み限定機能を使えるか」であり、未認証の制限ガイドが答えるのは「審査前に何を公開できるか」です。これは別の問いです。

提出チェックリスト:必要な情報と資料

LINE Developersコンソールの[審査申請]タブを開く前に、以下を整えてください。公式の日本語版審査依頼ガイドで、現在の確認事項と申請操作を確認できます。

項目用意すべき内容審査で重視される理由
プロバイダー名[サービス提供者]と同じ名称プライバシーポリシーでユーザー情報を取得する会社と照合
サービス提供者実際にサービスを提供する組織プロバイダー名と一致していることを確認
チャネル説明ミニアプリが何をするかの明確な記述審査員がテスト範囲を定めるために使用
プライバシーポリシーURL公開アクセス可能で、情報を取得する会社がプロバイダーと一致利用者と審査担当者が情報の取扱主体を確認できること
利用規約URL公開アクセス可能な利用規約ページポリシー準拠要件
Callback / Endpoint URL本番endpoint。提出前に固定済み審査後の変更が再審査を引き起こす場合がある
本番用・審査用のLIFF URLPublishedとReviewが同じサービス内容を表示することURLやLIFF IDの文字列ではなく、遷移先のサービス内容を照合
参考資料テストアカウント、サンプル商品、店舗や予約のシナリオ、Basic Auth有効時の認証情報審査員が推測なしに全フローを完了できるようにするため
APIスコープサービスが実際に使用する権限のみ過剰なスコープは用途と不一致と指摘される
公式アカウント連携ミニアプリが依存する場合のみ連携ミニアプリフローとの整合性審査

サービスメッセージの場合、さらに審査を通過したテンプレートが必要で、テンプレートはユーザーがミニアプリ内で行った操作に対して確認または応答するものでなければなりません。提出前にサービスメッセージテンプレート審査チェックリストで準備してください。本番のサービスメッセージには、認証済みチャネルと審査通過テンプレートの両方が必要です。

LINE Developersコンソールで初回審査を申請する手順

  1. 対象チャネルと提供地域を確認する。 [チャネル基本設定]でプロバイダー名、サービス提供者、チャネル説明、プライバシーポリシーURLを照合します。チャネル説明は「予約サービス」だけでなく、利用者が予約・決済・受け取りのどこまで行えるかを記載します。
  2. 審査用と本番用のサービス内容をそろえる。 チャネルとLIFFの設定は審査用チャネルにコピーされます。参照する環境やテストデータを確認し、審査用LIFF URLにアクセスできる段階で本番用と同じサービス内容かを照合してください。内部チャネルごとのLIFF IDやURLを同一の値に書き換えるという意味ではありません。
  3. [審査のための補足資料]を用意する。 予約・支払・注文を含むサービスでは、テストアカウント、対象の商品や店舗、操作順序を記載します。ベーシック認証がある場合は審査用のユーザー名とパスワードも申請資料に添えます。公開ブログや公開リポジトリには記載しません。
  4. [審査申請]タブから依頼する。 必要情報と資料を確認して送信します。審査開始後は申請のキャンセルや入力情報の変更ができません。ステータスが[審査中]になると審査用チャネルのLIFF URLにアクセスできます。
  5. コンソールと登録メールで結果を確認する。 却下された場合は指摘と提出内容を照合し、修正して再申請します。承認後の公開・検索の操作も担当者と確認してください。

テストシナリオに何を書くか

次は補足資料を組み立てるための例です。LINEの必須書式ではありません。実際のサービスで提供している操作だけを記載し、審査担当者が同じ結果を再現できるようにします。

対象フロー操作手順の例確認してほしい結果添える情報
予約対象店舗を選び、日時と人数を指定して確定する予約番号と予約内容が完了画面に表示されるテストアカウント、店舗名、予約可能な日時
注文対象商品を選び、数量と受け取り方法を指定する注文内容・金額・受け取り情報を確認できるテスト商品、店舗、注文条件
支払申請対象の決済方法で注文を完了する支払結果と注文状態が整合する審査で利用できる決済条件と確認手順

ログイン前提、利用可能な日時、既存予約の要否など、開始条件も明記してください。審査担当者がアクセスできない場合は、画面の説明だけでなく、利用権限やテストデータも確認します。

よくある却下理由

却下された場合は、コンソールと通知メールの内容を優先し、次の観点から申請資料と実際のサービスを見直してください。

1. 識別情報の不一致。 プロバイダー名、サービス提供者、プライバシーポリシーで情報を取得する会社を照合します。たとえば、ポリシーには親会社やブランド名、コンソールには子会社や通称を記載していないか確認してください。

2. 禁止業種。 LINEミニアプリポリシーは特定のカテゴリを完全に禁止しています。宗教団体、ナイトクラブ、ギャンブル、婚活・見合い、貸金、寄付募集、マルチ商法、タバコ・電子タバコ、武器・毒物、臨床試験などです。これらのカテゴリに該当するサービスは、品質にかかわらず審査を通過できません。

3. 禁止コンテンツ。 許可された業種であっても、コンテンツが却下を引き起こすことがあります。知的財産権の侵害、誇大または攻撃的なマーケティング、スパム、暴力や性的表現、他社製品との不当な比較やランキングです。サービスメッセージの文面が販促に寄るときも同様で、クーポン、新商品のお知らせ、報酬、一般的なイベント通知は却下されます。サービスメッセージはユーザーの操作に対する確認または応答でなければならないためです。

4. 技術およびドキュメントの不備。 審査対象と異なるサービスが開く、画面遷移が説明と一致しない、ベーシック認証のテスト情報が不足している、といった問題がないか確認します。公開済み設定を変更する場合の再審査要否は、再審査と公開手順で確認してください。

審査の所要時間とステータス

LINEは、審査に通常約1〜2週間かかると示しています。特急枠はなく、完了予定日は指定できません。審査ステータスはLINE Developers Consoleで確認でき、却下された場合は指摘事項を修正して再度申請する必要があり、さらにもう1サイクルが加わります。

季節のキャンペーンやリリースが認証済み限定機能に依存する場合、修正と再審査の時間も見込んで提出してください。初回提出前に対象サービス、Endpoint URL、プライバシーポリシーと利用規約を照合し、申請資料との食い違いを減らします。

初回審査の承認後は[承認済み]から[反映済み]へ進みますが、LINE内で検索可能にする操作は別です。[審査申請]タブの[検索可能にする]を公開計画に合わせて操作します。公開済みアプリの再審査では[変更内容を公開する]という別の操作になるため、初回申請と再審査の違いを確認してください。

本当に認証が必要ですか

認証限定の機能がクリティカルパスにある場合にのみ、認証を申請する価値があります。公式の機能一覧には、未認証のPublishedチャネルでも利用可能なものが記載されています。カスタムアクションボタン、公式アカウントの友だち追加、地域対応の決済連携などは認証理由単独では不十分です。

以下のいずれかに該当する場合に認証を検討してください。

  • 予約、注文、その他アプリ内の操作に紐づく本番環境のサービスメッセージ。
  • https://miniapp.line.me/cony_coffee のような識別しやすいカスタムパス。
  • ホーム画面ショートカット、共通プロフィールクイック入力、同意簡易化。
  • ミニアプリ名と認証バッジを表示するブランドヘッダー、またはLINE Homeと検索経由での発見。

いずれも該当しない場合、まず未認証のPublishedチャネルとして主要フローを公開し、認証は後で再検討するのは妥当な段取りであり、失敗ではありません。

UnifyPortの位置づけ

UnifyPortはLINEミニアプリを認証したり、審査に代わって提出したり、サービスメッセージテンプレートを承認したり、LINEのプラットフォーム特権を付与したりすることはありません。認証が必要な場合は、上記の公式審査経路を利用してください。

通常のLINEアカウントから顧客メッセージを受信し、サポートシステムへ連携する要件には、別途UnifyPortを利用できます。接続手順はLINE認証ガイド、受信時の検証はwebhook配信と署名ガイドで確認してください。この連携はミニアプリの審査やサービスメッセージの利用資格を代替しません。

制限とトレードオフ

ミニアプリ自体が予約、注文、会員、その他承認が必要な取引通知の操作を担う場合、またはLINE経由の発見とブランドヘッダーが導入率に重要な場合は、公式の認証経路が適しています。

非公式インターフェースはLINEプラットフォームのいかなる特権も付与できません。一般のアカウントメッセージをミニアプリのサービスメッセージに変えることも、テンプレート審査、カスタムパスの資格、認証バッジに影響を与えることもありません。その役割はより限定的で、アカウントの接続、検証可能な署名による対応する受信メッセージの配信、標準API経由での対応する返信の提供です。アプリが共有の顧客識別子や注文識別子で意図的に両者を結合しない限り、ミニアプリ製品と顧客メッセージのパイプラインは別々のシステムとして維持してください。

FAQ

LINEミニアプリの認証審査にはどのくらいかかりますか?

LINEは審査に通常約1〜2週間かかると示しています。特急枠はなく、完了予定日は指定できません。却下された場合は修正と再提出が必要で、審査サイクルがもう1回分加算されます。

LINEミニアプリはなぜ却下されるのですか?

個別の理由はコンソールと通知メールで確認してください。プロバイダー名・サービス提供者・プライバシーポリシーの整合性、ポリシーへの準拠、審査用サービスへのアクセス、テスト資料と実際の画面遷移を点検します。

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

対応する市場では、許可された顧客が未認証ミニアプリを公開し、認証前に主要フローを検証できます。本番環境のサービスメッセージ、カスタムパス、ホーム画面ショートカットなどの機能には認証が依然必要です。完全な機能比較は未認証の制限ガイドにあります。

LINE顧客メッセージの受信に認証は必要ですか?

いいえ。一般のLINE顧客メッセージの受信は、ミニアプリ認証とは独立した受信アーキテクチャの判断です。受信webhookは接続したアカウントから対応するメッセージを配信しますが、ミニアプリ機能は解放しません。

認証でサービスメッセージテンプレートも審査されますか?

認証により、チャネルは本番のサービスメッセージ送信資格を得ますが、各テンプレートは個別に審査されます。2つの審査を提出する前に、操作に紐づくユースケース、有効な変数、恒久リンクでテンプレートを整えてください。

次のステップ

要件がミニアプリ認証ではなく一般のLINE顧客メッセージの受信にある場合は、まずLINE認証ガイドでQRログインフローを理解し、その後プロバイダー機能対応表で送受信の境界を確認してからサポートワークフローを設計してください。

出典

初版の資料確認日は2026-08-03です。審査申請の手順とCustom Pathの形式は、2026-10-13に日本語の公式資料で再確認しました。

UnifyPort API

メッセージ連携を安定したプロダクトパイプラインへ。

まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。