Messaging API｜プッシュ通知をGASで安全に試す方法

LINEのAPIドキュメントを開いて、そっと閉じた経験はありませんか。安心してください。原因はエンジニアリング能力ではなく、公式ドキュメントの情報量が多く、最初に何をすればよいか見えにくいことです。この記事では、Web担当者が社内で説明しやすいように、最初のテスト通知を自分のスマホへ届ける最短手順と、無料通数枠を無駄にしないコスト設計の要点を整理します。

上司から「通常のメッセージ一斉配信はコストがかかるから、Messaging APIを使ってユーザーへ個別のプッシュ通知を自動化する仕組みを調査して、テスト配信まで検証しておいて」と急に頼まれて、何から手をつければいいか焦っていませんか。公式リファレンスは専門用語が多く、ネットの解説記事はコードだけが貼られていて管理画面の操作が分からないこともあります。

本ガイドの手順通りに進めれば、サーバーを構築せずに、cURLまたはGoogle Apps Script（GAS）で最初のテスト通知を送れます。さらに、本番運用が始まった後に「会社の無料通数枠を想定より早く使い切ってしまった」というコストトラブルを避けるための設計知識も、この1ページで確認できます。

情報時点：本記事は2026年5月時点のLINE Developers公式情報をもとに作成しています。料金プラン、無料通数、API仕様は変更される可能性があるため、本番導入前には必ず公式ドキュメントとLINE Official Account Managerの表示を確認してください。

---

執筆者プロフィール：伴 慎一郎（ばん しんいちろう）
システムインテグレーター / LINE公式アカウント運用効率化コンサルタント。
中小企業を中心に過去5年間で100社以上のLINE API連携システムの構築・監修を担当。手動の一斉配信からシステム連動型のAPI配信への移行により、クライアントのメッセージコスト削減を支援している。最新の仕様変更に準拠した、現場で動かしやすいシステム設計を提案している。

---

なぜ今、Messaging APIなのか？通常配信との違いと導入するビジネスメリット

LINE公式アカウントを実務で運用するにあたり、まず理解すべきは管理画面から手動で送る「通常メッセージ配信」と、プログラムから命令を送る「Messaging API」の違いです。上司への報告書や社内稟議の場でも説明しやすいように、API導入のビジネスメリットを整理します。

結論からお伝えすると、Messaging APIを導入する最大の強みは 「ユーザーごとの動的なリアルタイム出し分け（個別最適化）」 が可能になる点です。通常のメッセージ配信は、登録者全員、または事前に設定した属性によるセグメント配信が中心です。内容が合わない人にも通知が届くと、ブロック率の上昇につながる可能性があります。

一方で、Messaging APIを活用したプッシュメッセージ配信であれば、自社のECシステムや顧客データベースとLINEを裏側で連携できます。「自社ECで商品Aを購入した佐藤さん」という特定の個人をユーザーIDで識別し、購入直後のお礼や、予約日前日のリマインド通知を自動で届けることが可能です。不要な無差別配信を減らしながら、ユーザー体験とコスト効率を同時に改善しやすくなります。

通常配信とMessaging APIの違いは、次の表で整理できます。

📊 通常の一斉配信とMessaging APIの機能・用途比較表

比較項目	通常メッセージ配信（管理画面）	Messaging API（プッシュメッセージ）
配信対象	友だち登録者全員、または属性セグメント	特定のユーザーIDを指定して送信
配信契機	運用者の手動操作、または日時指定	自社システムやGAS等と連動したリアルタイム自動送信
主な用途	全体向けのメルマガ、一斉クーポン配布、告知	購入のお礼、予約リマインド、発送完了通知、会員連携通知
ユーザー体験	情報が多くなりやすく、内容によってはブロックの原因になる	自分に関係する情報が届きやすく、エンゲージメント改善につながる

---

迷子ゼロ！LINE Developersでの初期設定と3つの必須情報を取得するステップ

APIを使ったプログラムの実装に入る前に、LINE側の管理画面である「LINE Developers」で認証情報を取得する必要があります。画面が多層構造になっているため迷子になりやすいですが、手元に控えるべき情報は 「チャネルID」「チャネルアクセストークン」「ユーザーID」 の3つです。初期設定の全体像を先に整理したい場合は、Messaging API設定の始め方もあわせて確認してください。

まずは、ビジネス用アカウント等で LINE Developers にログインします。初期設定のロードマップは以下の通りです。

1. プロバイダーの作成: サービスを提供する「開発元（会社名や組織名）」となる箱を作成します。
2. チャネルの新規作成: プロバイダーの中で「Messaging API」を選択し、アカウント名やアイコン、メールアドレス等の必要事項を入力してチャネルを作成します。既存のLINE公式アカウントと連携する場合は、対象アカウントを間違えないように確認してください。
3. 友だち登録: LINE公式アカウントのQRコードをスマートフォンで読み込み、あなた自身の個人アカウントを友だち追加しておきます。

設定が完了したら、プログラムに組み込むための 「①チャネルID」、「②チャネルアクセストークン」、そして送信先となる 「③ユーザーID（userId）」 を画面から回収します。チャネルIDは「チャネル基本設定」で確認できます。チャネルアクセストークンは「Messaging API設定」タブで発行します。自分自身のユーザーIDは、LINE Developersコンソールのチャネル基本設定内にある「あなたのユーザーID」で確認できます。

⚠️ 初心者が陥りやすい罠：宛先「ID」の指定間違い
【結論】: プッシュメッセージの送信先（to）として、個人のLINEアプリ内で設定している「友だち検索用のLINE ID」や、公式アカウントの「ベーシックID（@から始まるもの）」を記述してはいけません。これらを指定すると、400 Bad Request などのエラーにつながる可能性があります。
なぜなら、LINEのシステムがAPI連携で送信先として扱うのは、LINE Developers上で確認できるユーザーID、またはWebhookイベントで取得できるuserIdだからです。WebhookでuserIdを取得する流れまで確認したい場合は、Messaging API Webhookの設定方法も参考にしてください。

---

コピー＆ペーストで検証！プッシュ通知を自分のスマホへ届けるテスト手順

3つの認証情報が揃ったら、目の前のスマートフォンに最初のプッシュ通知を届けるテストを行います。開発環境やサーバーの構築は必須ではありません。手元で検証しやすい2つのアプローチを用意しました。コマンド操作に慣れている方はcURL、スプレッドシート連携や業務自動化を見据える方はGASから始めるとよいでしょう。

方法①：黒い画面に貼るだけ！「cURLコマンド」で届かせる最短ルート

Macの「ターミナル」やWindowsの「コマンドプロンプト」を開き、以下のコードブロックをコピーしてテキストエディタに貼り付けてください。大文字になっている {CHANNEL_ACCESS_TOKEN} と {USER_ID} の部分を、先ほどメモした実際の文字列に書き換えます。波括弧 { } 自体も削除してください。書き換えたコマンドをターミナルに貼り付けてEnterキーを押します。

curl -X POST https://api.line.me/v2/bot/message/push \
-H "Content-Type: application/json" \
-H "Authorization: Bearer {CHANNEL_ACCESS_TOKEN}" \
-d '{
    "to": "{USER_ID}",
    "messages":[
        {
            "type":"text",
            "text":"APIからのテスト通知が成功しました！"
        }
    ]
}'

リクエストのヘッダー情報（-H）で「JSON形式でデータを送ること」と「正規の認証トークン（Bearer）」であることを示し、ボディ情報（-d）の to にあなたのユーザーIDを指定します。送信が成功すると、ターミナル画面には正常終了を示すレスポンスが返り、スマホにメッセージが届きます。もし届かない場合は、後述のQ&AでユーザーID、友だち登録、ブロック状態を確認してください。

方法②：サーバー不要！「Google Apps Script（GAS）」で自動化する王道ルート

実務の現場でシステムやGoogleスプレッドシートのデータと連携させたい場合に使いやすいのが、Googleが提供する「Google Apps Script（GAS）」です。Googleドライブから新規にスクリプトを作成し、以下のコードを貼り付けてください。Node.jsやTypeScriptで本格的に実装したい場合は、次の段階としてLINE BotのTypeScript実装も確認しておくと、Webhookサーバー側の構成を理解しやすくなります。

function sendLinePush() {
  // 1. LINE Developersで取得した認証情報をここに設定
  const CHANNEL_ACCESS_TOKEN = 'あなたのチャネルアクセストークンをここに貼り付け';
  const TARGET_USER_ID = 'あなたのユーザーIDをここに貼り付け';

  // 2. 送信するAPIの宛先URL（プッシュメッセージ用エンドポイント）
  const url = 'https://api.line.me/v2/bot/message/push';

  // 3. 送信するメッセージ内容（JSON構造の組み立て）
  const payload = {
    'to': TARGET_USER_ID,
    'messages': [
      {
        'type': 'text',
        'text': 'GASからのプッシュ通知テストです。実務連携の土台が完成しました！'
      }
    ]
  };

  // 4. APIリクエストに付与するヘッダーやメソッドの設定
  const options = {
    'method': 'post',
    'headers': {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer ' + CHANNEL_ACCESS_TOKEN
    },
    'payload': JSON.stringify(payload),
    'muteHttpExceptions': true
  };

  // 5. LINE APIサーバーへリクエストを送信
  try {
    const response = UrlFetchApp.fetch(url, options);
    Logger.log('ステータスコード: ' + response.getResponseCode());
    Logger.log('レスポンス: ' + response.getContentText());
  } catch (error) {
    Logger.log('送信失敗: ' + error.toString());
  }
}

設定したトークンとユーザーIDに間違いがないことを確認し、GAS画面の「実行」ボタンをクリックします。初回実行時のみ、Googleからアクセスの承認を求められることがあります。画面の指示に従って許可すると、スクリプトが動作してスマホにメッセージが届きます。なお、アクセストークンは外部に公開してはいけない機密情報です。社内共有ドキュメントや公開リポジトリへ貼り付けないようにしてください。

---

無料枠を使い切らない！実務導入前に必ず知っておくべき「通数カウント」とコスト最適化の罠

手元でのテスト配信に成功したら、次は本番運用を見据えた「コスト設計」を理解する必要があります。ここを知らずにプログラムを組むと、運用開始後に無料通数枠を想定より早く使い切り、会社に予期せぬ従量課金の負担を強いる可能性があります。上司へコスト面の稟議を通すためにも、通数カウントの考え方を先に押さえておきましょう。

LINE公式アカウントの料金プランにおいて、月間に無料で送信できるメッセージ通数はプランによって異なります。開発者が特に知っておくべき仕様は、メッセージオブジェクト（吹き出し）の数ではなく、送信先の人数で通数がカウントされるという点です。

LINE Messaging APIでは、1回のAPIリクエスト内にテキスト、画像、スタンプなど最大5つまでのメッセージオブジェクトを含めることができます。たとえば1人のユーザーに対して、1回のpushリクエストでテキストを3つまとめて送った場合、通数は通常1通として扱われます。反対に、同じ1人へ3回に分けてpushリクエストを送ると、3通分として扱われる可能性があります。

たとえば、システムから「お礼の挨拶（テキスト）」「購入明細（テキスト）」「操作ガイド（画像）」の3つを送りたい場合、3回に分けて個別にプッシュメッセージAPIを叩くよりも、1回のリクエストに3つのオブジェクトを配列としてまとめる方が効率的です。送信内容を無理に増やす必要はありませんが、関連する通知は1回にまとめる設計を検討しましょう。

また、同じ内容の通知を複数のユーザー（例：特定のイベント予約者50人）に対して送信したい場合、プログラムのfor文で個別プッシュ通知（/push）を50回連続で実行する設計は避けたいところです。APIリクエスト数が増え、処理速度やエラー管理が複雑になりやすいためです。

このようなユースケースでは、宛先を配列形式で指定できる 「マルチキャストAPI（/v2/bot/message/multicast）」 を検討します。消費される通数自体は宛先人数分で変わりませんが、APIリクエストを集約できるため、安定した運用につながります。

APIの送信方式は、目的に応じて次のように使い分けます。

📊 API送信エンドポイント（push / multicast / broadcast）の仕様・用途比較表

送信形式（APIエンドポイント）	宛先の指定方法	通数のカウント方法	最適な実務ユースケース
プッシュメッセージ (/v2/bot/message/push)	特定のユーザーIDを指定	送信先人数分	購入のお礼、予約リマインド、個別のアカウント連携通知。
マルチキャスト (/v2/bot/message/multicast)	複数のユーザーIDを配列で指定	送信先人数分	特定セミナーの予約者、特定商品を購入したユーザー層への一括リマインド。
ブロードキャスト (/v2/bot/message/broadcast)	宛先を個別指定せず、友だち全体へ送信	送信対象人数分	全体向けのシステムメンテナンス告知や、重要なお知らせ。
リプライメッセージ (/v2/bot/message/reply)	Webhookイベントで受け取ったreplyTokenを指定	通数カウント対象外	ユーザーのメッセージ送信やボタン操作に対する即時返信。

✍️ 専門家の経験からの一言アドバイス

【結論】: 本番環境のコードを書く前に、必ず「ユーザーからのアクションに対する返信」と「システム起点の通知」を切り分けて要件定義を行ってください。
なぜなら、ユーザーがLINE上でボタンを押した直後に返すメッセージであれば、通数カウント対象外のリプライメッセージAPI（/reply）で実現できる場合があるからです。何でもプッシュメッセージ（/push）で実装すると、無料枠の消費が早くなります。Webhook受信後に返信する処理では、LINE Botの署名検証まで含めて安全に設計しましょう。

---

まとめ

Messaging API プッシュ通知は、最初に必要な情報を正しくそろえれば、サーバーを構築しなくてもcURLやGASで検証できます。重要なのは、チャネルアクセストークンとユーザーIDを取り違えないこと、そして本番運用前に通数カウントの仕組みを理解しておくことです。

今回の手順で、LINE Developersの初期設定、cURLでの最小テスト、GASによる自動送信、無料通数枠を守るための「最大5つのメッセージオブジェクト」と「送信先人数でのカウント」という考え方まで整理できました。

上司へ報告する場合は、次のようにまとめると伝わりやすくなります。

「Messaging APIによる自動通知の実装検証は完了しました。サーバー不要のルートでテスト通知を送信でき、配信エンドポイントと通数カウントの設計を最適化すれば、メッセージコストを抑えながら本番運用へ移行できます」

まずはテスト用アカウントで小さく検証し、ユーザーIDの取得方法、友だち登録状態、通数管理、アクセストークンの保管ルールを確認してから、本番アカウントへ展開してください。

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

Messaging API プッシュ通知の実装時につまずきやすいポイントを、Q&A形式でまとめました。