TL;DR
- LINE Messaging APIには、ユーザーIDを知らなくても、電話番号だけでLINEにメッセージを送れる「LINE通知メッセージ（PNP: Push Notification via Phone number）」という機能がある。
- しかも友だち追加されていないユーザーにも送れる。配送通知・請求案内・障害連絡など、SMSや郵送でやっていたトランザクショナル通知の置き換えに強い。
- ただし誰でもすぐ叩けるAPIではない。法人向けの申請・用途制限があり、広告/営利目的の配信は不可。ここを誤解したまま導入検討を進めるとつまずきやすいので、制約を先に押さえるのが大事。
「LINEって友だち追加してもらわないと何も送れないんでしょ？」と思っている人ほど、この機能は刺さると思います。
本記事は、公式ドキュメント（2026年9月時点）を読み解いて要点を整理したものです。筆者が本番環境で実際に配信して検証したものではないため、実装前に最新のリファレンスをあわせてご確認ください。
LINE通知メッセージとは
企業が保有する顧客の電話番号をもとに送信リクエストを出すと、その番号がLINEに登録されているアカウント宛にメッセージが届く仕組みです。
通常のプッシュメッセージ（/v2/bot/message/push）が「友だち追加済みユーザーのLINE User ID」を宛先にするのに対して、LINE通知メッセージは電話番号（をハッシュ化した値）を宛先にします。友だち関係の有無を問わない点が最大の違いです。
受け取ったユーザーは、そのLINE公式アカウントを友だち追加するかどうかを選べます。追加すればそのまま継続的なコミュニケーションにつなげられるので、「重要通知をきっかけに友だちを増やす」導線としても使われています。
⚠️ 先に知っておくべき制約
隠れた便利機能ではありますが、「便利だからすぐ使おう」とはいかない機能です。ここを飛ばすと後で手戻りになりやすいので最初に書きます。
- 使えるのは「所定の申請等を行った法人ユーザー」だけ。 担当営業またはパートナー経由での申し込みが前提で、チャネルを作れば誰でも叩けるAPIではありません。さらに後述の「フレキシブル」版は、送信するメッセージ内容そのもののUX審査を通過したものだけが送れます。
- 用途は「ユーザーにとって重要性・必要性が高い通知」に限られる。 荷物の配送予定、公共料金の案内、航空機の遅延・欠航通知などが代表例です。
- 広告・営利目的の配信は不可。 公式ドキュメントにも「営利目的および広告目的のものは送信できません」と明記されています。マーケメールの一斉配信の置き換えには使えません。あくまでトランザクショナル通知です。
- 日本・タイ・台湾のLINE公式アカウント限定。 宛先も、日本・タイ・台湾で発行された電話番号に限られます。
つまり位置づけとしては、通常のMessaging APIというより準パートナー機能に近いです。「バウンス対策込みのSMS/郵送の代替チャネル」として捉えると腹落ちします。
2種類ある（2025年6月に分岐）
2025年6月2日のアップデートで「LINE通知メッセージ（テンプレート）」が追加され、従来の「LINE通知メッセージ」は「LINE通知メッセージ（フレキシブル）」に改称されました。使うエンドポイントも異なります。
| 種類 | 特徴 | エンドポイント |
|---|---|---|
| テンプレート | 用意されたテンプレート・アイテム・ボタンを組み合わせて作る。メッセージ内容の事前UX審査は不要 | POST https://api.line.me/v2/bot/message/pnp/templated/push |
| フレキシブル（旧「LINE通知メッセージ」） | Flex Messageなどで柔軟に作れる。事前UX審査必須。画像・動画・音声は含められない | POST https://api.line.me/bot/pnp/push |
フレキシブル版のパスには
/v2/が付きません。テンプレート版（/v2/bot/message/pnp/templated/push）と取り違えやすいポイントです。
まず試すなら、メッセージ内容の審査が挟まらないテンプレート版から入るのが現実的です（申請自体はどちらも必要）。テンプレートは2025年6月のリニューアルで拡充され、約100種類（2026年4月時点）が用意されています。
メッセージが「届く条件」 — 届かないのが前提
ここが運用設計でいちばん重要です。以下をすべて満たしたときだけ届きます。
- 指定した電話番号が、ユーザーのLINE登録番号と一致している
- その番号が有効である（SMSによる電話番号認証を一定期間内に実施済み）
- ユーザーがLINE通知メッセージの受信に同意している
- ユーザーが送信元の公式アカウントをブロックしていない
- 番号が日本・タイ・台湾で発行された、LINEアプリで電話番号認証できる番号である
- ユーザーがLINEのプライバシーポリシー（2022年3月改定以降のもの）に同意している
重要なのは、「電話番号を持っていれば確実に届く」わけではないという点です。条件を満たさない宛先にはサイレントに届かない。
メール配信で例えるなら、明示的なバウンスが返ってくるというより、「構造的に取りこぼしが発生するチャネル」だと考えるのが正しい。送達を100%前提にした業務フロー（これを送ったから必ず見ているはず、という設計）には向きません。
実装1: 宛先電話番号のハッシュ化
宛先 to には、E.164形式に正規化した電話番号をSHA256でハッシュ化した文字列を指定します。先頭の + は含め、ハイフンは含めません。
import hashlib
# E.164形式（先頭に + と国番号・ハイフンなし）
phone = "+818000001234"
to = hashlib.sha256(phone.encode()).hexdigest()
print(to)
# d41e0ad70dddfeb68f149ad6fc61574b9c5780ab7bcb2fba5517771ffbb2409c
正規化をミスってハイフン付きや 0 始まりの国内表記のままハッシュ化すると、当然一致せず届きません。+ の有無だけでもハッシュは変わるので、ハッシュ前の正規化処理は丁寧に組む必要があります。
宛先の形式が不正な場合は、こんな400が返ります。
{
"message": "The request body has 1 error(s)",
"details": [
{ "message": "The value must be a valid SHA-256 digest.", "property": "to" }
]
}
実装2: 送信（テンプレート版のcurl例）
配送完了テンプレートを送る例です（公式リファレンスのサンプルをもとに組み立てています）。
curl -v -X POST https://api.line.me/v2/bot/message/pnp/templated/push \
-H 'Authorization: Bearer {channel_access_token}' \
-H 'Content-Type: application/json' \
-H 'X-Line-Delivery-Tag: order-12345-shipment' \
-d '{
"to": "d41e0ad70dddfeb68f149ad6fc61574b9c5780ab7bcb2fba5517771ffbb2409c",
"templateKey": "shipment_completed_ja",
"body": {
"emphasizedItem": {
"itemKey": "date_002_ja",
"content": "2026年7月20日(月)"
},
"items": [
{ "itemKey": "time_range_001_ja", "content": "14:00～16:00" }
]
},
"customAggregationUnits": ["shipping"]
}'
templateKey / itemKey は自由文字列ではなく、公式が用意したキーから選びます。使えるキーは国（日本・タイ・台湾）と公式アカウントによって決まるので、リファレンスの一覧を確認してください。
customAggregationUnits は集計単位（ユニット名）です。「配送通知」「請求通知」のように用途別で通数を分けて集計したいときに付けます。ただし1リクエストに1ユニットまで、30文字以内、使える文字は半角英数字とアンダースコア（_）のみという制約があり、日本語のユニット名は使えません。
送信に失敗した場合は、こんな422が返ります。
{ "message": "Failed to send messages" }
利用申請が通っていないチャネルで叩くと403です。「このチャネルでそもそもAPIが使えるのか」を切り分けるときの目印になります。
{ "message": "Access to this API is not available for your account" }
実装3: 送信実績（通数）の確認
送った通数は日単位で取得できます。こちらも種類ごとにエンドポイントが分かれています。
| 種類 | エンドポイント |
|---|---|
| テンプレート | GET https://api.line.me/v2/bot/message/delivery/pnp/templated |
| フレキシブル | GET https://api.line.me/v2/bot/message/delivery/pnp |
curl -v -X GET 'https://api.line.me/v2/bot/message/delivery/pnp/templated?date=20260720' \
-H 'Authorization: Bearer {channel_access_token}'
date は yyyyMMdd 形式で、タイムゾーンはUTC+9（日本時間）です。
{
"status": "ready",
"success": 3
}
注意点は status が3値を取ることです。集計が終わるまでは unready が返るので、送信直後の確認には使えません。突合バッチは時間をおいて回す設計にしておきます。
| status | 意味 |
|---|---|
ready |
通数を取得できる |
unready |
集計がまだ完了していない。時間をおいて再実行 |
out_of_service |
指定日が集計システムの稼働開始日（2018年3月31日）より前 |
ハマりどころ5連発
ドキュメントを読み込んでいて「通常のMessaging APIの感覚で実装すると事故りそうだ」と感じたポイントを並べます。ここが本記事の本題かもしれません。
1. IPアドレス制限は「してはいけない」
通常のプッシュではセキュリティ設定でリクエスト元IPを固定するのがベストプラクティスですが、LINE通知メッセージでは逆。リファレンスにも「リクエスト元のIPアドレスを制限した状態でLINE通知メッセージを送ると、送信に失敗することがあります」と書かれています。IP制限をかけている既存チャネルを流用する場合は注意が必要です。
2. リトライキー（X-Line-Retry-Key）が使えない
通常のプッシュでは冪等性担保にリトライキーを使えますが、LINE通知メッセージAPIでは非対応（「リトライキーを使ったAPIリクエストの再試行はできません」と明記）。二重送信の防止は、X-Line-Delivery-Tag と自前の送信履歴管理で担保する必要があります。
3. follow を受けていないユーザーからの unfollow が飛んでくる
通知メッセージを受け取ったユーザーがブロックすると unfollow（フォロー解除）イベントが飛びます。ところが、そのユーザーは一度も follow（友だち追加）していないことがある。
Webhook処理で「フォロー履歴があるユーザーだけがunfollowしてくる」前提の実装をしていると、履歴のないuserIdのunfollowが来て例外を吐きかねません。未フォロー状態からのunfollowを許容する設計にしておきましょう。
4. 送達確認は X-Line-Delivery-Tag を仕込む
送信リクエスト時に X-Line-Delivery-Tag ヘッダに独自の識別子を付けておくと、配信完了イベントの delivery.data プロパティにその文字列が返ってきます。注文IDなどを埋めておけば、Webhook側で送達突合ができます。
{
"type": "delivery",
"delivery": { "data": "order-12345-shipment" }
}
なお文字数は最小16文字・最大100文字。短い注文IDをそのまま入れると下限に引っかかるので、プレフィックスを付けるなどして長さを確保します。
5. 電話番号のSHA256は「匿名化」ではない
宛先をハッシュ化して渡す仕様なので、つい「個人情報そのものは渡していない」と考えたくなります。ですが電話番号は取りうる値の空間が狭く、日本の携帯番号なら 090 / 080 / 070 ＋ 8桁で数億通りのオーダーです。ソルトなしのSHA256であれば、総当たりでハッシュ値から元の番号を復元するのは現実的な計算量に収まります。
つまりハッシュ化しても、電話番号そのものと同等の機微情報として扱うべきです。ハッシュ値をそのままログに吐かない、記事やIssueに実在の番号のハッシュを貼らない（本記事のハッシュは公式ドキュメントのダミー番号のものです）、といった扱いが必要になります。
どういうときに使うべきか
向いているケース:
- 配送予定・配送完了通知
- 請求・支払いの案内
- 予約確認、障害・遅延の緊急連絡
- 「重要通知をフックに公式アカウントの友だちを増やしたい」導線設計
向いていないケース:
- セール・キャンペーンなどの販促（広告目的は不可）
- 確実な到達が業務要件になっている用途（サイレントに届かないため）
- 「とりあえず試したい」個人開発（法人申請が前提）
まとめ
- 電話番号だけでLINEに、しかも友だち未追加でも送れる強力な機能。
- ただし法人申請・用途制限つきの準パートナー機能で、広告目的では使えない。
- 「確実に届く」前提は禁物。取りこぼしありきのトランザクショナル通知チャネルとして設計する。
- 実装時は IP制限NG / リトライキー不可 / 未フォローからのunfollow / 送達確認はDelivery-Tag / ハッシュ≠匿名化 の5点に注意。
「気軽に試せる隠れ技」というより「知っておくと通知設計の選択肢が一段増える」タイプの機能です。SMSや郵送コストに悩んでいる現場なら、検討する価値は十分あります。