LINE通知メッセージとは?友だち以外に届く仕組みと、導入前に判断すべきこと

この記事をシェア:
目次 クリックで開く

LINE通知メッセージは、ユーザーが友だち追加していなくても、電話番号を宛先にしてLINE公式アカウントから通知を送れる仕組みです。発送通知や料金の案内のように「確実に届けたい連絡」に向いています。ただ、便利さの手前で見極めておきたいことが二つあります。送れるのは“重要な通知”だけで、広告や販促は一切送れないこと。そして認定パートナーを通した申請と審査が前提で、企業が直接使い始められるものではないこと。加えて2025年6月には料金体系が大きく刷新されました。この記事では、仕組みから通常のLINE配信(Messaging API)との役割分担、料金、そして「自社で何を準備すべきか」までを、順を追って整理します。

仕組み——電話番号を「照合」して届ける

通常のLINE配信が「友だち」に届くのに対し、通知メッセージは電話番号を宛先にします。ここで多くの人が気にするのがプライバシーですが、設計はかなり慎重です。企業が渡す電話番号は、まず E.164形式(国番号付き)に正規化され、SHA256でハッシュ化されたうえで照合に使われます。生の番号がそのままやり取りされるわけではなく、照合が済んだハッシュは速やかに破棄され、照合という目的の外には残りません。企業側とLINE側が突き合わせるのは、電話番号そのものではなく、同じ規則で作ったハッシュ同士です。つまり「電話帳を丸ごとLINEに預ける」という構図にはならない、と理解しておくと実態に近くなります。

そして、届くのは「電話番号が一致すれば誰でも」ではありません。ユーザー側がいくつもの条件を満たしたときだけ配信されます。具体的には、登録電話番号が一致し、その番号がSMS認証済みで有効であり、ユーザーが受信に同意していて、公式アカウントをブロックしておらず、日本・タイ・台湾で発行された番号であること。つまり通知メッセージは、「送りたい相手」ではなく「受け取ることに同意している相手」にだけ届く仕組みだと理解しておくのが正確です。

処理の順を追うと、企業はハッシュ化した電話番号と本文を配信リクエストとして送り、LINEのサーバがハッシュを照合して上の条件を満たすユーザーだけに絞り込み、該当するユーザーのLINEに通知として届けます。ここで大事なのは、企業側は「誰に届いたか」を個人単位で名指しできるわけではないことです。宛先はあくまで電話番号(のハッシュ)で、LINE内部のユーザーIDはこの段階では企業に渡りません。ユーザーがその通知をきっかけに友だち追加をして、はじめてその先の一対一のやり取りが可能になります。

受信可否はユーザーが握っています。LINE側の設定で通知メッセージの受け取りを拒否(オプトアウト)でき、企業が無理に届かせる余地はありません。そのため“到達数”は自社の努力だけで決まるものではなく、後述する電話番号データの品質と、ユーザー側の同意・ブロック状態に左右されます。

Messaging APIとの関係——「友だち化の前」と「後」で役割が分かれる

通知メッセージを、普段のLINE配信(Messaging API)と同じものと考えると設計を誤ります。Messaging APIは友だち関係が前提で、送信方法は用途ごとに分かれます。ユーザーの発言に応答するリプライReply Tokenを使う)、特定のユーザーへ任意のタイミングで送るプッシュ(ユーザーID指定)、複数のユーザーへまとめて送るマルチキャスト、友だち全員へ一斉に送るブロードキャスト、属性やオーディエンスで絞り込むナローキャスト。いずれにも共通するのは、宛先がLINE内部のユーザーID=すでに友だちである相手だという点です。

通知メッセージは、この手前にあります。まだ友だちでない相手に、電話番号を頼りに“事実の通知”を届けるのが役割です。言い換えると、通知メッセージは「友だち化の前のトランザクション通知」、Messaging APIは「友だちになった後の継続的なコミュニケーション」。同じLINEでも守備範囲がはっきり違います。

だから実務では、両者を切り離さずにつなぎます。まず通知メッセージで必要な連絡を届け、そこから友だち追加へ促し、追加後はMessaging APIのプッシュやリプライで関係を続ける——という流れです。通知メッセージを単体で完結させるより、Messaging APIへの入口として位置づけると、その後の接客まで一本につながります。

観点 Messaging API(通常の配信) LINE通知メッセージ
友だち関係 必須 不要
宛先 ユーザーID(友だち) 電話番号(ハッシュ照合)
送れる内容 販促・広告もOK 重要な通知のみ・広告不可
事前の審査 不要 認定パートナー経由・カテゴリ/(フレキシブル型は)UX審査
主な役割 友だち化“後”の継続的な連絡 友だち化“前”のトランザクション通知

送れるもの・送れないもの——ここが判断の中心

通知メッセージを検討するとき、最初に確かめるべきは料金でも仕組みでもなく、「自社が送りたい内容が、そもそも送れるのか」です。基準は明快で、LINEヤフーが「ユーザーにとって有用かつ適切」と判断した用途に限られます。配送予定や配達完了、予約のリマインド、料金の確定や支払期限の案内、決済の完了通知、申し込みや会員登録の完了——こうした“事実の通知”がこれにあたります。

一方で、営利・広告を目的としたものは一切送れません。新商品のお知らせ、セールやキャンペーンの告知、割引クーポンの配布といった販促は対象外です。さらに見落とされがちですが、氏名・住所・メール・電話番号といった個人を識別する情報を本文に含む通知も認められていません。「同じポイントまわりでも、保有ポイントの“お知らせ”は通り、ポイントを使った“セール告知”は通らない」——このように、同じテーマでも「通知か、販促か」で扱いが分かれます。迷う内容は、申請の段階で確認するのが確実です。

この線引きは、単なる利用ガイドではなく審査の中心そのものです。通知メッセージは用途のカテゴリごとに審査があり、送る文面(テンプレート)も審査を受けます。つまり「この業種のこの通知が対象に当たるか」が、導入できるかどうかの最初の関門になります。自社が送りたい連絡を洗い出し、それを“事実の通知”として説明できる形に整理できるかどうかを、企画の段階で見極めておく必要があります。

対象か対象外か迷ったら、「その通知は、ユーザーが取った行動(購入・予約・契約)の結果を知らせるものか、それとも企業が売りたいものを知らせるものか」で切り分けると見当がつきます。前者は通知、後者は販促、という向きです。

2つの型——テンプレート型とフレキシブル型

作り方には2種類あり、審査の重さと費用が変わります。テンプレート型は、用意された多数のテンプレート(配送・予約・料金など幅広い用途)を組み合わせて作る方式で、UX審査は原則不要です。ヘッダーやタイトルは固定で、アイテムやボタンの組み合わせで作ります。まず定型の完了通知から早く始めたい場合に向いています。

対してフレキシブル型は、テキストや色、あいさつ文まで作り込める自由度の高い方式です。ただし1つのUX(メッセージ体験)ごとに事前審査が必要で、その審査費用は20万円(税抜)、期間は目安で10〜15営業日かかります。独自のレイアウトやブランド体験を作り込みたい場合の選択肢です。

選び分けは、まず対象かどうかを確かめたうえで、定型で足りるならテンプレート型で速く立ち上げ、独自の体験が要るならフレキシブル型、という順で考えると迷いません。フレキシブル型はUXごとに審査費と審査期間がかかるため、通知の種類が増えるほどコストと立ち上げ時間が積み上がる点も、設計時に見込んでおくと後で慌てずに済みます。

料金——2025年6月に「月額固定+従量」へ刷新

ここは近年で最も変わった部分です。かつての純粋な従量課金から、2025年6月に月額固定+従量のハイブリッド3プランへと刷新されました。送信規模に応じて次のように分かれます(第三者報道・公式発表にもとづく、執筆時点)。

プラン 月額固定 含まれる通数 超過単価
エッセンシャル 50万円 10万通/月 3.0円/通
パフォーマンス 200万円 100万通/月 1.2円/通
アンリミテッド 1,000万円 1,000万通/月 0.6円/通

月50万円という固定費は、中小規模には重く感じられるかもしれません。その受け皿として、2026年6月に「ストアビジネス&ECプラン」が新設され、月額固定なし・1通あたり5円の従量課金で、店舗・EC向けに導入しやすくなりました。加えて、実際に配信された分のみが課金対象で、APIが受理しても未配信なら課金されない点も、コスト設計上おさえておきたいところです。

プラン選びは、突き詰めれば「月あたりの想定通数」で決まります。固定費のあるプランは、含まれる通数を使い切るほど1通あたりの実効的な負担が下がり、使い切れないほど固定費が重く効きます。逆に固定費なしの従量プランは、通数が少ないうちは無駄がありませんが、量が増えるほど単価がそのまま効いてきます。ですから判断の出発点は、業務データから月あたりの想定通知数を見積もり、固定費プランと従量プランのどちらが自社の通数帯に合うかを当てはめることです。通数は季節やキャンペーンで動くため、ピーク月とそうでない月の両方で当てておくと、見込みを外しにくくなります。

SMSと、どう使い分けるか

「確実に届ける」手段としてSMSと比較されます。単価はLINE通知メッセージが優位で、一般にSMSが1通あたり十数円〜数十円とされるのに対し、通知メッセージはプランによって0.6〜5円程度です。一方でSMSは、電話番号さえあればほぼ全員に届く到達の広さがあります。

構造の違いを押さえておくと選びやすくなります。通知メッセージの到達は、LINEへの登録・受信同意・未ブロックといった条件に左右されるため、電話番号を持っていても届かない層が必ず出ます。SMSはその条件がほぼ不要で、番号が生きていれば届きます。つまり「単価とリッチさ」と「到達の広さ」はトレードオフの関係にあります。到達率や開封率について高い数字が語られることもありますが、その多くは出所の明確でない主張のため、ここでは断定を避けます。

実務的な結論はシンプルで、単価とリッチさで通知メッセージを主に使い、通知メッセージが届かない層をSMS(やメール)で補完する——この併用が、コストと到達を両立させる定石です。運用上は、まず通知メッセージで配信を試み、未達だった相手をSMSにフォールバックさせる二段構えを配信ロジックに組み込んでおくと、無駄な送信を抑えながら取りこぼしを防げます。

通知メッセージは「安く・リッチに」、SMSは「広く確実に」。片方に寄せるより、未達をSMSで拾う二段構えが現実的です。

導入の条件——企業が直接は使えません

通知メッセージは、思い立ってすぐ使える機能ではありません。三つの条件をすべて満たす必要があります。第一に、青いバッジの付いた認証済みLINE公式アカウント(プレミアムアカウントを含む、審査を通過した公式アカウント)であること。第二に、認証プロバイダーとして登録されていること。そして第三に、認定パートナー(Sales Partner/Technology Partner)を通して発注することです。

通知メッセージAPIの技術仕様は、そもそもTechnology Partnerにしか公開されていません。企業はSales Partnerに利用を申請し、Technology Partnerに開発を依頼する——という建て付けになっています。加えて、利用開始までには認証プロバイダーの審査、用途カテゴリの審査、テンプレート(またはUX)の審査が挟まり、ユーザーがいつでも受信を止められるオプトアウトの仕組みも前提として組み込まれています。準備を始める前に、この審査の段取りをスケジュールへ織り込んでおくと、立ち上げが読みやすくなります。

配信そのものは、必ず認定パートナーを経由します。ここは仕組み上の制約として、最初にスケジュールへ組み込んでおくべき前提です。

実装の流れ——「申請」と並行して、社内側で組むもの

申請と配信は認定パートナーが担いますが、社内システム側で組む部分は別にあります。まずLINE側の土台として、プロバイダーを作り、Messaging APIのチャネルを用意します。ここでチャネルアクセストークンとチャネルシークレットを取得し、Webhookの受信URLを設定します。友だち追加やメッセージ受信といったイベントがWebhookに届くので、それを起点に友だちのユーザーIDを取得し、プッシュやリプライで応答できる状態にしておきます。

通知メッセージ自体は、このMessaging APIのプッシュとは別立てで、認定パートナー経由の仕組みで配信されます。宛先は電話番号(のハッシュ)で、友だちのユーザーIDではありません。ですから社内では、通知メッセージと通常配信を「電話番号を鍵にする配信」と「ユーザーIDを鍵にする配信」の二系統として設計しておくと、処理が混ざらずに済みます。

この二系統をつなぐのが名寄せです。通知メッセージは電話番号を鍵にする一方、友だち追加後のやり取りはLINEのユーザーID(UID)を鍵にします。この二つを、自社の会員IDで結びつけておきます。具体的には、会員データベースの電話番号をE.164に正規化して配信対象に使い、友だち追加で得たUIDを同じ会員レコードにひも付けます。ここが整うと、「通知で接点を作り、友だち化してからは会員として一対一で扱う」という流れが、一本の線でつながります。

通数課金である以上、送る相手の管理がそのままコストに直結します。無効番号や重複、退会者を配信対象に残すと、届かないうえに手間だけが増えます。配信対象リストは会員データベースを正として、定期的に洗い替える運用にしておくのが安全です。

いちばんの要は、「いつ・誰に・何を送るか」を自社で作ること

ここが、多くの解説記事が触れないところです。通知メッセージの申請と配信は認定パートナーが担いますが、「いつ・誰に・何を送るか」を作り出すのは、自社側のシステムです。ここが整っていないと、審査を通しても通知は自動では飛びません。押さえどころは三つあります。

一つ目は、イベントの検知と配信トリガー化です。購入・発送・予約完了といった業務上のできごとを、基幹システムやECのWebhookから捉え、配信の起点につなぐ設計が要ります。これができて初めて、「発送したら自動で通知が飛ぶ」状態になります。逆に、担当者が手作業でリストを作っているうちは、通知の速さも正確さも安定しません。

二つ目は、意外に見落とされる電話番号のデータ品質です。配信の条件に「SMS認証済みの有効な番号」が入る以上、照合できる番号がどれだけあるか=到達数そのものを左右します。E.164への正規化、重複の名寄せ、無効番号の除去といった会員データの整備が、地味ですが成果に直結します。

三つ目は、会員基盤との連携です。LINEのユーザーIDと自社の会員IDを結びつけ、通知をきっかけに友だち追加へ誘導し、その後の一対一のコミュニケーションにつなげる。通知メッセージを“単発のお知らせ”で終わらせず、継続的な接点の入口にする設計です。小規模で定期的ならCSVアップロード運用、大規模でリアルタイムならAPI常時連携、と要件に応じて連携方式を選ぶ判断も、ここに含まれます。

導入前に、三つを見極める

ここまでを踏まえると、導入前に確かめるべきことは三つに集約できます。第一に、自社の連絡が使える用途・業種か。“事実の通知”として説明でき、広告・販促や個人識別情報を本文に含まない形に整理できるかどうかです。第二に、審査に通る通知設計になっているか。定型で足りればテンプレート型、独自体験ならフレキシブル型と、型の選択まで含めて設計できているかです。第三に、SMSやメールまで含めた費用対効果。想定通数からプランを当てはめ、届かない層をどの手段で補うかまで見通せているかです。この三つが揃えば、通知メッセージは「確実に届けたい連絡」の主軸として無理なく機能します。

「申請」の前後にある“実装”まで含めて

通知メッセージの利用申請と配信は認定パートナーが担いますが、その前後にあるイベント検知・電話番号データの整備・会員基盤やMA/CRMとの連携——つまり社内システム側の実装は、別途設計が必要です。ここがかみ合ってはじめて、通知は自動で、正しい相手に届きます。この実装・連携・運用を含めて相談したい場合は、LINE活用の実装支援で対応しています。「自社の通知を、どこから拾って、どう飛ばすか」の整理からで大丈夫です。全体像は 「LINEログインとは?」 にまとめています。

▶ 全体像は 「LINEログインとは?仕組み・できること・導入の判断」 にまとめています。

参考にした情報:LINE Developers 公式ドキュメントおよびLINEヤフー for Business(LINE通知メッセージの概要・技術仕様〈E.164正規化/SHA256/配信条件〉、Messaging APIの送信方法)、LINEヤフー for Business の料金刷新告知(2025年6月)。料金プランの数値は公式発表および報道にもとづく執筆時点のもので、テンプレート用途数やプランは改定されます。SMSとの到達率・開封率の比較は出所の明確な統計が乏しいため断定を避けています。導入時は最新の公式情報および認定パートナーの案内をご確認ください。

LINE公式アカウント支援

LINE公式アカウントの配信設計からCRM連携、LINEミニアプリ開発まで。顧客接点のデータを統合し、LTVと売上を上げるLINE活用を実現します。

AT
aurant technologies 編集

上場企業からスタートアップまで、数多くのデータ分析基盤構築・AI導入プロジェクトを主導。単なる技術提供にとどまらず、MA/CRM(Salesforce, Hubspot, kintone, LINE)導入によるマーケティング最適化やバックオフィス業務の自動化など、常に「事業数値(売上・利益)」に直結する改善実績多数。

この記事が役に立ったらシェア: