← 全記事
ガイド

LINE MINI App の手数料が7月1日に開始：決済フローと受信サポートを分ける

LINE を顧客対応に使っているチームにとって、7 月 1 日の更新は誤解しやすい内容です。発表の中心は LINE MINI App のアプリ内課金です。2026 年 7 月以降の利用分からサービス手数料が適用され、手数料計算、精算、支払い方法を明確にするために利用規約も改定されました。

これは LINE 内でデジタルコンテンツやサービスを販売するチームには重要です。ただし、すべての LINE サポート業務を MINI App 化すべき、という意味ではありません。顧客からのメッセージを決済スタックに通すべき、という意味でもありません。LINE メッセージを受け取り、サポートに振り分け、正しいアカウントから返信するだけなら、その経路はアプリ内課金から分離した方が安全です。

小規模チームが決めるべきことは、「LINE のどの機能がどの仕事を担当するか」です。決済、デジタル商品、分析、受信サポートは、それぞれ審査フロー、運用コスト、障害時の影響が違います。ひとつの統合にまとめると、必要以上に複雑になります。

7 月 1 日に何が変わったか

LINE は、LINE MINI App のアプリ内課金機能について、2026 年 7 月以降の利用分からサービス手数料を課すと発表しました。適用される料率は、申請時に指定された料率です。

この機能の用途は明確です。LINE のドキュメントでは、アプリ内課金は認証済み MINI App 内でユーザーがデジタルコンテンツを購入するための仕組みと説明されています。支払いは App Store と Google Play の仕組みを使い、LINE Platform が決済検証と通知機能を提供し、クライアントは LIFF SDK で実装し、サーバー側は webhook で連携します。

開始フローも単純な webhook 設定ではありません。LINE Developers Console から申請し、承認後に webhook URL とテスト決済ユーザーを登録し、Developing channel で購入機能を実装してテスト決済を行い、検証レビューに出し、最後にアプリ内課金を有効化した認証済み MINI App として公開します。

利用条件も限定的です。MINI App のサービス提供地域と会社または所有者の国・地域は、どちらも日本に設定されている必要があります。本番利用では認証済み LINE MINI App であること、LIFF ブラウザ内で開かれること、LIFF SDK 2.26.0 以上を使うこと、ユーザーが日本の電話番号を登録しており LINE 15.6.0 以上を使っていることも求められます。

これは日本向け MINI App 内で承認済みデジタルコンテンツを販売するための正しい製品面です。しかし、サポート inbox を作る最短経路ではありません。

決済 Webhook はサポート Webhook ではない

両方の世界で「webhook」という言葉が出てくるため、チームは混同しがちです。

LINE MINI App のアプリ内課金では、webhook は決済システムの一部です。MINI App サーバーは購入を予約し、購入関連の webhook を受け取り、購入完了を確認し、デジタルアイテムを付与します。この経路は売上認識、権利付与、返金処理、コンプライアンスのためにあります。

顧客サポートは別の形をしています。重要なのは「購入が完了した」というイベントではなく、「顧客がメッセージを送った」というイベントです。必要なのは、受信したアカウント、送信者、会話、メッセージ種別、テキストまたはメディア、時刻です。このイベントは、決済ジョブ、分析ジョブ、MINI App 審査が遅れていても、すぐにサポートキューへ届くべきです。

LINE の受信サポートだけが必要なチームにとって、決済 webhook は抽象として重すぎます。サポート経路が、コマースチャネル、日本向け MINI App 審査、アプリストア決済ルール、手数料精算ロジックに依存してしまいます。

UnifyPort の受信経路

UnifyPort は顧客メッセージの経路を分離します。LINE メッセージは標準の message.received webhook イベントとして、登録したエンドポイントに HTTP POST で届きます。対応チャネルでは共通のエンベロープを使います：id、type、provider、account_id、occurred_at、data です。

LINE の受信テキストイベントは次のようになります。

{
  "id": "evt_7c41a2f90b",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-07T02:30:00Z",
  "data": {
    "conversation": { "id": "U9d3f51a2", "type": "user" },
    "sender": { "id": "U9d3f51a2", "type": "user", "name": "Mika Tanaka" },
    "message": {
      "id": "msg_20260707_001",
      "type": "text",
      "text": "I paid in the app but still need help changing my delivery time.",
      "direction": "inbound",
      "sent_at": "2026-07-07T02:29:59Z"
    },
    "event": { "kind": "message_received" }
  }
}

webhook エンドポイントは message.received を購読できますし、["*"] で標準イベント全体を購読することもできます。署名を有効にすると、各配信には X-Device-Timestamp と X-Device-Signature が付きます。署名は、タイムスタンプ、ピリオド、raw request body をエンドポイントの signing_secret で HMAC-SHA256 した 16 進文字列です。

返信も明示的です。サポート backend は、対象の account_id、宛先、メッセージ本文を指定して POST /v1/messages を呼び出します。受信サポートのループは、顧客が MINI App、rich menu、QR code、通常の LINE chat のどこから来たかを知る必要はありません。

小規模チーム向けの分け方

日本向けにデジタルコンテンツを販売する LINE MINI App を作っているなら、公式のアプリ内課金フローを使うべきです。そこでは決済審査、アプリストア取引、購入検証、精算レポートを扱います。このスタックは慎重で監査可能、かつ財務と結びついているべきです。

顧客対応を作っているなら、イベント駆動の受信レイヤーを使います。そこではメッセージ受信、ルーティング、重複排除、Slack や CRM への連携、返信処理を扱います。このスタックは速く、安定し、他チャネルにも再利用できるべきです。

分け方はシンプルです。

仕事担当する面タイミング
デジタルコンテンツ購入LINE MINI App アプリ内課金checkout 中
購入検証MINI App サーバーと LINE 決済 webhook決済ライフサイクル
ライブ顧客メッセージUnifyPort message.received webhook即時イベント
サポート返信POST /v1/messages担当者または workflow
クロスチャネル routingUnifyPort 標準イベントエンベロープ各 provider で同じ handler

このモデルは海外展開にも向いています。LINE MINI App のアプリ内課金は現在、日本条件に強く結びついています。一方、サポートキューはひとつの市場に閉じません。日本とタイでは LINE、ベトナムでは Zalo、香港やシンガポールでは WhatsApp、開発者向けには Telegram が必要になるかもしれません。ひとつの受信 schema があれば、市場ごとに統合を作り直さずに済みます。

いま作るべきもの

まず、あなたのプロジェクトがコマース面なのか、メッセージ運用面なのかを決めます。

コマース面なら、LINE MINI App のアプリ内課金ドキュメントを読み、日本条件を確認し、LINE Developers Console から申請し、サービス手数料を予算化し、決済 webhook を財務クリティカルな経路として作ります。サポート routing code と混ぜないでください。

メッセージ運用面なら、signing_secret 付きの UnifyPort webhook エンドポイントを登録し、message.received を購読し、X-Device-Signature を検証し、イベントを保存し、provider、account_id、data.conversation.id、data.sender.id、data.message.type でルーティングします。決済 ID や注文 ID は自社システム内の metadata として扱い、transport layer にはしない方がよいです。

顧客が「アプリ内で支払ったが配送時間を変えたい」と送ってきたとき、サポートシステムは決済フローの成功確認を待ってから記録するべきではありません。まず受信し、ルーティングし、その後に担当者や自動化が注文を参照すれば十分です。

LINE の 7 月 1 日の手数料更新は、プラットフォーム決済面には独自のコストと制御があることを思い出させます。LINE 内でデジタルコンテンツを売るなら使う。入站の顧客会話を扱うなら、イベント駆動、署名検証、決済スタックから独立した経路にする。それが小規模チームには一番扱いやすい設計です。