---
title: "LINE Notify終了後の移行実装｜Messaging APIへの置き換え手順と通知コスト試算"
url: "https://www.issoh.co.jp/tech/details/17533/"
published: 2026-09-10
updated: 2026-09-27
categories: ["API"]
publisher: "株式会社一創"
---

# LINE Notify終了後の移行実装｜Messaging APIへの置き換え手順と通知コスト試算

LINE Notifyは2025年3月31日に提供を終えました。トークン1本をヘッダーに載せてPOSTするだけで通知が飛ぶ手軽さは、後継として案内されているMessaging APIには引き継がれていません。この記事では、公式の終了告知と公式SDKの実コードで確認した値をもとに、pushエンドポイントへの書き換え、ユーザーIDの取得、無料200通の数え方、2026年10月1日に予定されている追加メッセージ料金の改定までを順に追います。移行作業そのものより先に決めるべき「通知先をLINEに残すか」の判断基準も、条件付きで示します。

## まとめ｜LINE Notifyの置き換え先は通知の宛先で決まる

先に結論を置きます。通知の宛先が社内の開発者や運用担当だけなら、Messaging APIへ移すのは遠回りです。SlackやDiscordのWebhook、あるいはメールに寄せたほうが、公式アカウントの開設と友だち追加という手順を丸ごと省けます。LINEに残す価値があるのは、宛先が社外の一般ユーザーで、その人たちが日常的にLINEを開いている場合だけです。

移行を決めたなら、書き換えの中心は3か所です。エンドポイントを `notify-api.line.me/api/notify` から `api.line.me/v2/bot/message/push` へ。認証はNotifyの個人トークンからチャネルアクセストークンへ。宛先はグループ招待からユーザーIDの指定へ。この3点を押さえれば、送信部分の移植は半日で終わります。

詰まるのは費用の設計です。Notifyは無料でしたが、Messaging APIは公式アカウントの料金プランに紐づき、通数は「送った回数×友だちの数」で数えます。無料枠は月200通しかありません。しかも2026年10月1日には追加メッセージの単価が改定されます。通知の頻度と宛先数を先に見積もらないまま移すと、翌月の請求で驚くことになります。

## LINE Notify提供終了で失われた前提とトークンの扱い

移行作業を設計する前に、何が使えなくなったのかを正確に押さえます。ここを曖昧にしたまま置き換えると、動くコードは書けても運用が回りません。

### 2025年3月31日の終了日と現在も設定に残っているトークンの状態

[LINE Notifyの提供終了告知](https://notify-bot.line.me/closing-announce)には「2025年3月31日にサービスを終了させていただくことになりました」と記載されています。2016年9月から続いたサービスで、告知ページには後継として「より多彩な機能を備えたMessaging APIを提供しております」とだけ書かれています。

手元に残っている `LINE_NOTIFY_TOKEN` は、もう認証に通りません。終了後のトークンは無効な文字列であって、失効手続きの対象でもありません。環境変数やCIのシークレットに残っている場合は、移行のついでに削除しておくのが筋です。放置しても通知は飛びませんが、秘密情報の棚卸しが甘くなります。

### 置き換えで消える機能｜グループ招待・3吹き出し無料・スタンプ送信

Notifyとの機能差は、単なるAPIの違いにとどまりません。設計に影響するのは次の3点です。

- 宛先の指定方法：Notifyは「通知用ボットをグループに招待する」だけで済みました。Messaging APIでは、通知を受ける人が公式アカウントを友だち追加し、そのユーザーIDをアプリ側が保持する必要があります。
- 費用：Notifyの送信は無料でした。Messaging APIのプッシュメッセージは公式アカウントの通数に加算されます。
- 受信側の見え方：Notifyの通知は専用のLINE Notifyアカウントから届きました。移行後は自社の公式アカウントから届くため、宛先の人には「知らないアカウントを友だち追加してもらう」説明が必要になります。

3つのうち運用を止めるのは2番目と3番目です。技術的な書き換えは終わっても、社外の人に友だち追加を依頼する工程が新しく発生します。この依頼が通らない相手には、そもそも通知が届きません。

## Messaging APIへの移行手順｜チャネル作成からユーザーID取得まで

作業の順番を間違えると、コードを書いた後に送り先が無くて止まります。宛先の確保を先に片付けます。

### 公式アカウントとチャネルの作成手順と送信用アクセストークンの発行

[Messaging APIを始めようの公式手順](https://developers.line.biz/ja/docs/messaging-api/getting-started/)では、LINE公式アカウントを作り、LINE Developersコンソールでプロバイダーとチャネルを用意し、チャネルアクセストークンを発行する流れが示されています。実作業は次の順です。

1. LINE公式アカウントを開設する（開設時は無料のコミュニケーションプランが自動で設定されます）。
2. LINE Developersコンソールでプロバイダーを作り、Messaging APIのチャネルを追加する。
3. チャネル基本設定からチャネルシークレットを、Messaging API設定からチャネルアクセストークンを発行する。
4. 応答設定で「あいさつメッセージ」と「応答メッセージ」を切り、Webhookを有効にする。

4番目を飛ばすと、通知を送るたびに自動応答が混ざります。発行したチャネルアクセストークンは長期有効のものを選べますが、それは漏れた場合に自社アカウントから任意のメッセージを送れる鍵になるということです。保管とローテーションの決め方は[APIキー管理の発行・保管・失効を整理した記事](https://www.issoh.co.jp/tech/details/16300/)の考え方をそのまま当てられます。

### 通知先となる宛先ユーザーIDの取得方法とWebhook受信の最小構成

プッシュメッセージの `to` に入れるのはユーザーIDです。これはLINEアプリの画面に出るIDとは別物で、チャネルごとに発行される `U` から始まる文字列です。取得経路は実質2つに絞られます。

1つはWebhookです。友だち追加時の `follow` イベント、あるいはメッセージ受信時の `message` イベントに含まれる `source.userId` を保存します。通知専用の用途なら、Webhookは受け取ってDBに書くだけの最小実装で十分です。もう1つはLINEアプリ内で動くWebアプリから取る方法で、こちらは[LIFFの仕組みと開発手順をまとめた記事](https://www.issoh.co.jp/tech/details/3396/)で扱っているログイン経路を使います。

社内の数人へ通知するだけなら、Webhookサーバーを常設せず、一度だけ受信して得たIDを設定ファイルに固定してしまう手もあります。ただしその人が友だち追加を外すと、送信は失敗する点に注意が必要です。宛先が増減する運用なら、Webhookは常設したほうが後で楽になります。

## 通知送信コードの書き換え｜pushエンドポイントとリトライキー

ここからは実際に打てる形で示します。旧コードと新コードを並べると、変わる箇所は限られています。

### LINE Notifyの旧実装とMessaging APIのcurl比較

終了前のNotifyは、フォーム形式でメッセージ本文を送るだけでした。

```
# 2025年3月31日まで動いていたLINE Notifyの送信
curl -X POST https://notify-api.line.me/api/notify \
  -H "Authorization: Bearer $LINE_NOTIFY_TOKEN" \
  -F "message=deploy finished"
```

置き換え後の送信形式はJSONで、宛先の指定も必須の項目です。エンドポイントは公式SDKの実コードで確認できます。[line-bot-sdk-pythonのリポジトリ](https://github.com/line/line-bot-sdk-python)にある api.py では、ホストが `api.line.me`、プッシュ送信のパスが `/v2/bot/message/push` と定義されており、docstringには messages が「Max: 5」と明記されています。

```
# 置き換え後（Messaging API のプッシュメッセージ）
curl -X POST https://api.line.me/v2/bot/message/push \
  -H "Authorization: Bearer $LINE_CHANNEL_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Line-Retry-Key: $(uuidgen)" \
  -d '{ "to": "U4af4980629...",
        "messages": [ { "type": "text", "text": "deploy finished" } ] }'
```

同じ内容を複数人へ配るなら、宛先ごとにpushを呼ぶのではなくmulticastを使います。同SDKのdocstringでは multicast の宛先が「Max: 500 users」と書かれており、1リクエストで500人までまとめられます。1人ずつ回すとリクエスト数が宛先数に比例して増えるため、宛先が数十を超えたらまとめる実装に変えてください。

### X-Line-Retry-Keyによる二重送信の防止と429の扱い

Notifyには無かったヘッダーが `X-Line-Retry-Key` です。同じUUIDを付けて再送すれば、LINE側が同一リクエストと判断して二重配信を防ぎます。公式SDKの push\_message にも `retry_key` 引数が用意されています。これは要求と結果を1対1に保つための仕組みで、考え方は[冪等性をAPIとIaCで担保する方法を解説した記事](https://www.issoh.co.jp/tech/details/13382/)で扱っているものと同じです。

タイムアウトで再送する場合、キーを毎回振り直すと通知が2通届きます。UUIDは「送りたい通知1件」に対して1個だけ生成し、リトライの間は使い回してください。

```
import os
import uuid
import requests

ENDPOINT = "https://api.line.me/v2/bot/message/push"

def notify(text, to):
    headers = {
        "Authorization": "Bearer " + os.environ["LINE_CHANNEL_ACCESS_TOKEN"],
        "Content-Type": "application/json",
        "X-Line-Retry-Key": str(uuid.uuid4()),
    }
    payload = {"to": to, "messages": [{"type": "text", "text": text}]}
    res = requests.post(ENDPOINT, headers=headers, json=payload, timeout=10)
    if res.status_code == 429:
        raise RuntimeError("rate limited: retry later with the same key")
    res.raise_for_status()
```

レート制限を超えた場合の挙動は、[Messaging API開発ガイドライン](https://developers.line.biz/ja/docs/messaging-api/development-guidelines/)に「レート制限を超えて送信を行った場合、429 Too Many Requestsエラーとなります」と書かれています。具体的な上限値は[Messaging APIリファレンス](https://developers.line.biz/ja/reference/messaging-api/)の共通仕様に置かれているため、実装前にそちらで確認してください。429を受けたときの待ち方は[指数バックオフとジッターの実装判断をまとめた記事](https://www.issoh.co.jp/tech/details/16185/)、上限側の設計は[429設計とアルゴリズム5方式の解説](https://www.issoh.co.jp/tech/details/16179/)が対応します。監視アラートの再送を素朴なループで書くと、障害時に通知が自分でレート制限を踏み抜きます。

## 通知コストの試算｜無料200通の数え方と2026年10月の料金改定

Notifyが無料だったぶん、ここが移行で一番狂いやすい箇所です。プラン表の数字より先に、通数の定義を押さえます。

### 「送った回数×友だちの数」で数える通知の通数と課金対象外の機能

[LINE公式アカウントの料金プランのページ](https://www.lycbiz.com/jp/service/line-official-account/plan/)には「1回に配信できるメッセージは最大3吹き出しまで、『メッセージを送った回数』×『送った友だちの数』を『通数』としてカウントします」と記載されています。ここが誤解の温床です。10人へ1回通知すれば、消費は1通ではなく10通です。

同ページでは、課金対象にならない機能も明示されています。LINEチャットの送受信と自動応答メッセージは通数に加算されません。つまり「相手からのメッセージに返す」形なら費用は発生せず、「サーバーから一方的に送る」プッシュだけが課金対象になります。監視アラートやバッチ完了通知はすべて後者です。

| プラン       | 月額（税別）  | 無料メッセージ | 追加配信   |
| --------- | ------- | ------- | ------ |
| コミュニケーション | 0円      | 200通    | 不可     |
| ライト       | 5,000円  | 5,000通  | 不可     |
| スタンダード    | 15,000円 | 30,000通 | 従量課金で可 |

無料プランの200通は、宛先5人の運用なら月40回の通知で尽きます。日次バッチの結果を5人へ流すだけで、月末には枠が無くなる計算です。追加配信ができるのはスタンダードプランだけなので、通知を止めたくないなら月15,000円が実質の下限になります。

### 2026年10月1日の追加メッセージ改定と2段階単価への影響

費用を見積もるなら、改定後の単価で計算してください。[追加メッセージ料金改定のお知らせ](https://www.lycbiz.com/jp/news/line-official-account/20260216/)によれば、2026年10月1日から追加メッセージは20万通/月までが1通3円、20万通を超えた分が1通2.5円になります（いずれも税別）。同ページには「今回の追加メッセージ料金改定適用のサービス対象国・地域は、日本のみとなります」とあり、2026年9月10日時点の表示更新日は2026年9月1日でした。改定の内容は随時更新される旨も告知に明記されています。

改定前の単価は段階制でした。料金プランのページに載っている計算例が「（50,000通×3円）＋（50,000通×2.8円）＋（100,000通×2.6円）=550,000円」となっており、5万通を超えたぶんから単価が下がる構造だったことが読み取れます。改定後は20万通までが一律3円なので、月5万通から20万通の帯を配信しているアカウントは実質の値上げです。逆に20万通を大きく超える規模では、改定前よりも低い単価になります。

移行時に見落としやすいのが上限の設定です。料金プランのページには「追加メッセージを送るためには、追加メッセージ数の上限目安の設定が必要です。上限数を超えてメッセージを配信しようとすると、メッセージの配信が停止されます」と記載されています。上限目安を0のまま放置すれば、送りたい通知が配信停止で落ちます。既存の公式アカウントへ通知を相乗りさせる場合はマーケティング配信と通数を共有するため、現在の消費通数と上限設定を先に確認してください。改定の告知では、上限引き上げの申請が承認された場合の最大値を359万通と案内しています。

## LINE以外の通知先との比較｜Slack・Discord・メールの選定軸

ここが競合の移行記事で抜けている論点です。Notifyの代わりは、Messaging APIだけではありません。

### 宛先が社内か社外かで分かれる通知先の準備・費用・用途の比較と判断表

判断軸は「宛先が誰か」の一点です。開発者・運用担当・社内の管理者しか見ない通知に、公式アカウントの開設と友だち追加、通数課金を引き受ける理由はありません。SlackとDiscordはWebhook URLを1本発行すればPOSTできて、宛先の同意取得もユーザーID管理も不要です。Notifyの手軽さに最も近いのはこちらです。

| 通知先           | 宛先の準備       | 送信費用    | 向く用途      |
| ------------- | ----------- | ------- | --------- |
| Messaging API | 友だち追加とID保持  | 通数課金    | 社外の一般ユーザー |
| Slack・Discord | Webhook発行のみ | 実質無料    | 社内の運用通知   |
| メール           | アドレス保有のみ    | 送信基盤の費用 | 記録が必要な通知  |

メールは即時性で劣りますが、監査や証跡が求められる通知では今も第一候補です。3つを排他的に選ぶ必要もありません。障害通知はSlack、顧客への確定通知はLINE、請求関連はメールという分け方が実務では収まりが良くなります。

### 通知先が複数ある場合に通知処理をアプリ本体から切り離す非同期化の判断

通知先が複数になった時点で、送信処理を業務ロジックから切り離してください。プッシュメッセージのHTTP呼び出しをリクエスト処理の中に直列で置くと、LINE側が遅れたぶんだけ自社の応答が遅れます。キューに積んでワーカーから送る構成にすれば、429で待つ時間もユーザーへの応答から切り離すことが可能です。方式の選び方は[同期処理との違いから実装方式までを整理した記事](https://www.issoh.co.jp/tech/details/13590/)にまとめてあります。

切り離すもう1つの理由は差し替えのしやすさです。通知先を1か所のインターフェースに集めておけば、料金改定や仕様変更で送信先を変えるときに、業務ロジックへ手を入れずに済みます。Notifyの終了で改修が必要になったコードは、たいていこの分離ができていませんでした。

## LINEへの移行を見送る条件と業務通知の設計をやり直す判断の基準

最後に判断を言い切ります。移行作業に入る前に、この章の条件で振り分けてください。

### Messaging APIへ移さないほうが安いと言い切れる3条件

次のいずれかに当てはまるなら、Messaging APIへの移行はしないほうがよいと考えます。

- 通知の宛先が社内メンバーだけで、全員がSlackかMicrosoft Teamsを業務で開いている。公式アカウント開設と友だち追加の手順に見合う利得がありません。
- 通知が機械向けで、人が読むのは障害時だけ。この場合はログ基盤とアラートマネージャーに寄せたほうが、検索性と再送制御の両方で勝ちます。
- 宛先が10人以上で、通知が日次以上の頻度。無料枠200通を即座に超え、スタンダードプランの月15,000円が固定費として乗ります。同じ費用をメール送信基盤に払ったほうが通数の制約から自由になります。

逆にLINEへ移す判断が正しいのは、宛先が自社の顧客やエンドユーザーで、その人たちにメールを送っても開封されていない場合です。到達率のためにLINEを選ぶ、という理由なら通数課金は投資として説明できます。社内向け通知を惰性でLINEに残すのは、費用と手間の両方を無駄にします。

### 通知だけで終わらせず返信や操作も双方向にする場合の設計と発注の判断

Messaging APIへ移す作業をしていると、「通知を受けた人がその場で返信や操作をできないか」という要望が出てきます。ここまで来ると通知の移植ではなく、LINE上のアプリケーション開発に当たる作業です。リッチメニューやLIFFで画面を持たせる構成は、[LINEミニアプリの仕組みと導入判断を解説した記事](https://www.issoh.co.jp/column/details/15161/)で費用感まで整理しています。

移行の見積もりで判断が付かない場合は、通知の宛先数・頻度・双方向の要否の3点を持って相談してください。[LINEミニアプリ開発](https://www.issoh.co.jp/service/apps/line/)では、Messaging APIでの通知実装から友だち情報と業務データの紐付けまでを含めて設計しています。単純な置き換えで済むのか、通知の設計自体をやり直すべきなのかは、この3点が揃えば判断できます。

## よくある質問

LINE Notifyの終了と移行について、検索されている質問に答えます。

### LINE Notifyはもう完全に使えないのですか？

使えません。公式の提供終了告知に「2025年3月31日にサービスを終了させていただくことになりました」と記載されており、それ以降はトークンを付けても送信できません。2016年9月から続いたサービスで、後継としてMessaging APIが案内されています。手元のスクリプトが無言で失敗している場合、原因はトークンの期限切れではなくサービス自体の終了です。

### LINE Notifyのトークンをそのまま使い回せますか？

使い回せません。Notifyの個人アクセストークンとMessaging APIのチャネルアクセストークンは、発行元も認証の対象も別です。移行では、LINE Developersコンソールでチャネルを作り、そこからチャネルアクセストークンを新たに発行します。旧トークンは無効な文字列なので、環境変数やCIのシークレットから削除しておいてください。

### Messaging APIへの移行は無料でできますか？

開発と検証は無料枠で可能です。公式アカウントの開設時は月200通まで無料のコミュニケーションプランが設定されるため、動作確認はここで済みます。ただし本番運用では、通数が「送った回数×友だちの数」で数えられる点に注意してください。宛先5人へ月40回通知すれば200通に達します。追加配信をしたい場合は、月15,000円（税別）のスタンダードプランが必要になります。

### 通知先のユーザーIDはどこで確認できますか？

LINEアプリの画面には表示されません。取得できるのはWebhook経由で、友だち追加時の follow イベントかメッセージ受信時の message イベントに含まれる source.userId を保存します。LIFFのログインもユーザーIDを取得するための経路です。いずれもチャネルごとに発行される値なので、チャネルを作り直すと同じ人でも別のIDになります。

### 2026年10月の料金改定で通知コストはどう変わりますか？

2026年10月1日から、追加メッセージは20万通/月までが1通3円、超過分が1通2.5円（税別）になります。改定前は5万通を境に段階的に単価が下がる体系だったため、月5万通から20万通の帯では実質的な値上げです。システム通知単体でこの帯に入ることは稀ですが、既存のマーケティング配信と同じ公式アカウントに相乗りさせる場合は、現在の消費通数を先に確認してください。

## 関連記事

- [冪等性とは？読み方・意味からAPI・IaCでの担保方法まで実装者向けに解説](https://www.issoh.co.jp/tech/details/13382/)：X-Line-Retry-Keyが何を保証しているかを、API全般の話として押さえ直せます。
- [リトライパターンとは？指数バックオフ・ジッター・リトライ予算の実装判断を解説](https://www.issoh.co.jp/tech/details/16185/)：429を受けたあとの待ち方と再送回数の決め方を扱っています。
- [APIキー管理とは？発行・保管・失効とローテーションの実装を解説](https://www.issoh.co.jp/tech/details/16300/)：チャネルアクセストークンの保管とローテーションを設計するときの参照先です。
- [LIFFとは？LINEアプリ内で動くWebアプリの仕組みと開発手順を実装目線で解説](https://www.issoh.co.jp/tech/details/3396/)：ユーザーIDをフロント側から取る経路と、画面を持たせる実装をまとめています。
- [LINEミニアプリとは？仕組み・LIFFとの違い・開発費用から導入判断まで解説](https://www.issoh.co.jp/column/details/15161/)：通知の移植から双方向のアプリ開発へ進む場合の費用感を確認できます。

---

出典: [LINE Notify終了後の移行実装｜Messaging APIへの置き換え手順と通知コスト試算](<https://www.issoh.co.jp/tech/details/17533/>)（株式会社一創）