LINE Botでプッシュ通知を送る方法｜GASでの実装とエラー対処

「明日までに予約リマインドのプロトタイプを見せてほしい」と急に依頼され、LINE Botのプッシュ通知をすぐに動かす必要がある方へ向けた実装ガイドです。

結論からいうと、最短で疎通確認するには、チャネルアクセストークン、送信先のuserId、/v2/bot/message/pushのJSON構造を正しくそろえる必要があります。この記事では、GASでスマホにテスト通知を送る手順と、400/401/403エラーの切り分け方を整理します。

なお、本文は2026年5月時点で確認できるLINE Developers公式情報をもとに整理しています。画面名、料金プラン、無料通数、API仕様は変更される可能性があるため、本番実装前には必ず公式情報も確認してください。

---

[著者プロフィール]
佐藤 健（Messaging API開発エキスパート、導入実績50社超）。API開発の現場で起こりうるエラー、特に認証・権限系のトラブルシューティングに定評があります。技術的な理想だけでなく、「納期までに確実に疎通させる」ための最短ルートを提示する現場主義のエンジニアです。

---

LINE Bot運用の最大の落とし穴：プッシュ通知の「コスト」と「種類」

LINE Bot開発で最初に押さえるべきポイントは、「リプライメッセージ」と「プッシュ通知」の違いです。どちらもMessaging APIで送信できますが、送信できるタイミングと通数カウントの扱いが異なります。

機能	特徴	通数カウント	役割
リプライメッセージ	ユーザーのイベントに対する返信	対象外	ユーザーからのメッセージや操作への応答
プッシュ通知	任意のタイミングで送信	対象	予約リマインドや購入後通知などの能動的通知

予約システムと連動したリマインド通知は、ユーザーからの直近のメッセージに返信する処理ではありません。そのため、通常はプッシュ通知として設計します。

注意したいのは、プッシュ通知が料金プランの無料通数や追加通数の管理対象になる点です。LINE Developers公式では、プッシュ、マルチキャスト、ブロードキャスト、ナローキャストは通数カウント対象で、リプライメッセージは対象外と説明されています。無料で無制限に送れる前提で一斉送信システムを作ると、後から運用コストの説明で困る可能性があります。

✍️ 専門家の経験からの一言アドバイス
【結論】: プロトタイプ段階でも、プッシュ通知の通数カウントを前提に設計してください。
なぜなら、この点は多くの人が見落としがちで、後からクライアントへのコスト説明で苦労する原因になるからです。エンジニアとして、設計段階から通数管理を提示できることは、強い信頼シグナルになります。

---

400/401エラーを秒速回避！開発環境の初期設定術

LINE Botのプッシュ通知で詰まりやすいのは、コード本体よりも初期設定です。まずは、送信に必要な3項目をそろえましょう。Messaging APIの有効化やチャネル確認がまだ不安な場合は、先にMessaging API設定の基本手順を確認しておくと、アクセストークンやチャネルの見間違いを減らせます。

設定の3大重要項目

1. チャネルアクセストークンの発行: LINE DevelopersコンソールのMessaging API設定から、送信用のチャネルアクセストークンを発行します。外部に漏れると不正送信のリスクがあるため、公開リポジトリや記事内に実値を貼らないでください。
2. システム内部の「userId」の確認: LINEアプリ上で検索に使う「LINE ID」とは別物です。LINE Developersコンソールの「あなたのユーザーID」やWebhookイベントで取得できる、Uから始まる文字列を送信先に使います。
3. Webhook URLの設定: ユーザーの友だち追加やメッセージ送信を起点にuserIdを取得したい場合は、Webhook URLの設定が必要です。URL検証やHTTPS条件で詰まる場合は、Webhook設定の確認ポイントもあわせて確認してください。

💡 失敗回避の重要チェックポイント
403 Forbiddenや送信失敗の原因として多いのは、送信先のtoに一般のLINE IDや表示名を入れてしまうケースです。プッシュ通知の送信先には、Messaging APIで扱うuserIdを指定してください。

---

疎通確認用コード（GAS）：コピペでスマホを鳴らす実装

ここでは、最短で動作を検証するためのGASコードを紹介します。まずは自分のテスト用userId宛てに1通だけ送信し、成功後に予約システムやCRMとの連携へ広げる流れが安全です。

Google Apps Script (GAS) での送信例

function sendLinePush() {
  const url = "https://api.line.me/v2/bot/message/push";
  const token = "ここにチャネルアクセストークンを貼り付け";

  const payload = {
    "to": "ここにuserIdを貼り付け",
    "messages": [{ "type": "text", "text": "テスト通知：疎通確認成功！" }]
  };

  const response = UrlFetchApp.fetch(url, {
    "method": "post",
    "contentType": "application/json",
    "headers": { "Authorization": "Bearer " + token },
    "payload": JSON.stringify(payload),
    "muteHttpExceptions": true
  });

  Logger.log(response.getResponseCode());
  Logger.log(response.getContentText());
}

muteHttpExceptions: trueを入れておくと、エラー時にもレスポンス本文をログで確認しやすくなります。400系エラーが出た場合は、まずステータスコードとレスポンス本文を見て、JSON、認証、送信先のどこで止まっているかを切り分けましょう。

テキストだけでなく画像やカード型メッセージを送りたい場合は、messages配列の中身を変更します。リッチなカード表示まで試したい方は、Flex Messageの作成方法も参考にしてください。

⚠️ 緊急チェックリスト（エラーが出た場合）

• アクセストークンのBearer指定: Authorization: Bearer {トークン} の形式で、Bearer とトークンの間に半角スペースが入っていますか？
• トークンのコピー: 前後に不要なスペースや改行が混入していませんか？
• JSON構造: {"messages": [{"type": "text", "text": "..."}]} と、正しいネスト構造になっていますか？
• 送信先: to に一般のLINE IDではなく、Uから始まるuserIdを入れていますか？

---

よくあるエラー（400/401/403）逆引きトリアージ

開発中に発生するエラーは、ステータスコードごとに原因の層が異なります。闇雲にアクセストークンを再発行する前に、次の表で切り分けてください。

エラーコード	主な原因	解決手順
400 Bad Request	JSON構造の誤り、メッセージ形式の不備	JSON.stringifyの結果とレスポンス本文をログ出力し、公式スキーマと照合する
401 Unauthorized	アクセストークンの指定ミス、ヘッダー形式の誤り	Bearer とトークンの間に半角スペースがあるか、トークンが対象チャネルのものか確認する
403 Forbidden	送信先userIdの誤り、権限やアカウント状態の問題	LINE IDではなくuserIdを使っているか、対象ユーザーが友だち追加済みか確認する

前述の通り、プッシュ通知の失敗は「コードのミス」だけでなく、「チャネル違い」「userId違い」「通数上限」でも起こります。本番環境で急に止まった場合は、ログ、環境変数、LINE Developersコンソールの設定を順番に確認しましょう。より広い範囲の障害切り分けは、Messaging APIエラーの緊急対処でも整理しています。

---

まとめ：自信を持って「実装完了」を報告するために

LINE Bot プッシュ通知を最短で疎通させるには、アクセストークン、userId、JSON構造の3点を正しくそろえることが重要です。特に、LINE IDとuserIdの違い、リプライメッセージとプッシュ通知の通数カウントの違いは、初期段階で必ず確認してください。

今回のプロトタイプがスマホに届いたら、それはLINEのインフラと自分のBotサーバーが正しく接続できた証拠です。次の段階では、通数上限、送信対象、ログ保存、個人情報の扱いまで含めて、本番運用に耐える設計へ進めましょう。

LINE Bot プッシュ通知に関するよくある質問 (FAQ)

LINE Botのプッシュ通知でつまずきやすいポイントを、Q&A形式でまとめました。疎通確認前のチェックや、エラー発生時の切り分けに役立ててください。