LINE Notify終了後の移行。Messaging APIで通知を続ける設計と確認表

LINE Notifyは2025年3月31日に終了しました。以前のトークンや送信先を残したままでは、現在の通知手段として使えません。移行では送信URLの変更に加え、誰へ、何を、どの条件で、何回知らせるかを作り直します。公式のサービス終了案内

この記事では2026年9月8日時点の公式資料を確認し、Messaging APIを中心に移行の判断と受入条件をまとめます。実行用の完成コードではなく、既存通知を移す際の設計ガイドです。実際の送信、認証情報の変更、ジョブ停止は実施していません。

最初に「動いていた通知」を棚卸しする

担当者が覚えている通知だけでは、月次処理や障害時だけ動くジョブが漏れます。コード、スケジュール設定、運用資料から、Notifyへ送る処理とその実行元を確認します。

棚卸し項目	記録例
通知を起こす出来事	日次集計完了、在庫下限、処理エラー
実行元	バッチ、外部サービス、クラウドの定期実行
旧宛先	自分、担当者複数、グループ
実行頻度	定期、業務イベント、障害時の最大発生数
必要な対応	見るだけ、確認操作、即時の復旧対応
管理者	実行設定を変更できる人と代行者
情報の機密性	個人情報や詳細ログを含むか

受信できた記憶だけで存続を判断しません。終了後に誰も見ていなかった通知は、移行する価値や代替の監視方法も含めて見直します。

移行先は、受信者の環境で選ぶ

移行先の候補	検討しやすい場面	追加で決めるもの
LINE公式アカウント＋Messaging API	個人向けLINEを使う受信者へ通知したい	友だち等の送信条件、宛先ID、配信通数
LINE WORKSのBot	組織内のLINE WORKS利用者へ知らせたい	組織の権限、Botの参加範囲、運用担当
既存の社内チャット・監視製品	既に担当者や当番を管理している	連携仕様、通知ルール、契約条件
メールや業務画面	記録の共有や後日の確認が中心	宛先更新、確認手順、重要通知の扱い

LINE WORKSのBotは、LINEユーザーや外部LINE WORKSユーザーを含むトークルームでは利用できません。「LINEとつながるから従来のグループへ同じように通知できる」とは考えず、受信者の所属を確認します。LINE WORKS Botの公式制限

どの媒体も、送信できることと担当者が確認したことは別です。緊急通知なら、確認されない場合の連絡先と、同じ障害の通知が増え続けない仕組みも必要です。

Messaging APIへの移行は、四つの対応を作り直す

Notifyで使ったアクセストークンや宛先を、そのままMessaging APIへ持ち込むことはできません。現在の開始手順では、LINE公式アカウント側でMessaging APIを有効にしてチャネルを利用します。古い記事の「DevelopersからMessaging APIチャネルを新規作成」という画面操作を、そのまま踏襲しないようにします。公式の開始手順

旧設定から確認するもの	移行後に用意するもの
Notifyの認証情報	対象チャネルの認証情報と安全な保管先
Notifyの送信先	新たに確認したユーザーID・グループID等
短いテキスト本文	Messaging APIで扱うメッセージ形式
実行後の成否判定	API受付、処理失敗、確認待ちを分ける記録

宛先IDの取得や双方向のやり取りにWebhookを使う場合は、署名検証等を含めて実装します。一方、既に正しく確認した宛先へ送るだけの処理で、必ず受信サーバーが必要になるとは限りません。送信と受信を混ぜず、必要な構成を選びます。

送信条件と通数を移行前に計算する

Pushは友だちや参加中のグループ等の条件に従います。ブロック等ではAPIがHTTP 200を返しても届かない場合があるため、成功コードだけで「担当者へ連絡済み」としないことが大切です。Pushの送信条件

通数はリクエスト回数や吹き出し数だけで決まりません。架空の例として、5人へ個別に1日2回、30日間通知する計画なら、5×2×30＝300人分の送信です。この通常分に、障害時の増加や確認の追加通知を見込んでプランを確認します。公式の料金・カウント方法

「エラーを検知するたびに送る」実装は、障害時ほど通数が増えます。同一原因を一定期間まとめる、重大度を分ける、回復通知を一回だけ出すといった運用案を検討します。何を省略したかが分からなくならないよう、詳細は監視画面やログで確認できるようにします。

再試行と切り替えの手順を用意する

通信のタイムアウトでは、送信が受理されたか不明になる場合があります。対応APIでは最初のリクエストから X-Line-Retry-Key を指定して、同じ内容の再試行を管理できます。成功や既に受理済みの応答に対して、新しいキーで再送し続けない設計が必要です。公式のAPI再試行ガイド

移行計画は、設定の準備、限定した受信先での検証、通知元ごとの切り替え、旧ジョブの整理の順にします。旧Notifyは終了済みなので、不具合時にそこへ戻す計画は成立しません。切り替えに失敗した場合の確認先は、業務画面や別途用意した通知先にします。

移行期間中に新旧のコードが残る場合は、どちらが有効かを一覧にします。「古いから不要」とだけ判断して定期処理全体を消すと、通知以外の集計まで止める可能性があるためです。

実務例：在庫通知を一人から当番へ引き継ぐ

架空の部品販売店で、在庫下限を下回ったとき、旧担当者一人へNotifyで通知していたとします。移行先は担当チームが確認するLINEの通知先とし、宛先の利用条件を確認して設定します。

通知本文には商品を確認する業務画面への入口を載せ、在庫の詳細は権限のある担当者が画面で確認します。同じ商品が下限以下のままなら毎回新しい警告にせず、未対応の一件として扱います。入荷して回復した場合はその状態を記録します。

この移行で変えるのは通信先だけではありません。誰が見るか、誰が対応を引き受けたか、担当者が休みならどうするかまで決めることで、旧担当者の個人端末への依存を減らします。

移行完了の受入確認表

確認する場面	合格の判断
通知元の一覧	定期・月次・障害時のジョブを把握している
認証情報の管理	コードや通知文に秘密情報を埋め込まない
宛先が変わる	新担当者の宛先確認と旧宛先の整理ができる
同じイベントが再処理される	重複通知を制御できる
タイムアウト・上限到達	再試行と停止の判断を分けられる
通知が読まれない	確認先と代行担当が明確になっている
切り替えに失敗する	終了済みNotify以外で業務を確認できる
旧処理を整理する	通知以外の処理へ影響しないことを確認する

通知の移行後も、宛先と担当者の一覧は更新が必要です。資料の作り方はLINE運用の引き継ぎにまとめています。

よくある質問

LINE Notifyは現在も使えますか？

2025年3月31日にサービスを終了しています。現在の通知手段として旧トークンや旧送信先を使うことはできず、別の通知方式への移行が必要です。

送信URLだけ変えればMessaging APIへ移行できますか？

認証情報、宛先ID、メッセージ形式、送信条件、通数、成否判定も確認する必要があります。Notifyのトークンと宛先をそのまま利用する前提にはできません。

LINE WORKSなら従来のLINEグループへBot通知できますか？

LINE WORKSのBotは、LINEユーザーや外部LINE WORKSユーザーを含むトークルームでは利用できません。組織内の受信者向けか、個人向けLINEの受信者向けかを確認して方式を選びます。

移行後に不具合があればNotifyへ戻せますか？

Notifyは終了済みなので復旧先にはできません。限定した受信先での検証と段階的な切り替えを計画し、不具合時には業務画面や別途用意した通知先で状況を確認できるようにします。

この記事に関連するサービス

旧Notifyの棚卸しから宛先・通数・障害対応を含む通知の移行を検討する方は、LINEアプリ開発のサービスをご覧ください。

LINEアプリ開発のサービス・相談窓口を見る