LINEとスプレッドシートをつなぐ3つの向き｜記録する・シートから送る・配信リストを管理する、シートで足りなくなる境目

LINE とスプレッドシートをつなぐ、という相談は、向きで3つに分かれます。LINE に来たメッセージや友だち追加を、シートに1行ずつ残す（LINE→シート）。シートの行が増えたり変わったりしたのをきっかけに、LINE で知らせる（シート→LINE）。シートに「誰に送るか」を持ち、そこから LINE で配信する。どれを作るかで、必要なものも、気をつける点も違います。

シートから LINE へ通知する方法として長く使われた LINE Notify は、2025年3月31日にサービスを終了しました（LINE Notify 提供終了のお知らせ、LINE Developers ニュース）。公式は、通知の代わりに、LINE 公式アカウントから送る Messaging API を案内しています。今から作る「シートから LINE へ」は、LINE 公式アカウントがあることが前提です。

最初に決めること：記録したいのか、知らせたいのか、配信先を管理したいのか

作るものは、次の3つのどれかに分かれます。いちばん近いものを選ぶと、読む節が決まります。

①と②は、同じ「友だち台帳」のシートで結ぶと一続きになります。①で受けたユーザーIDを台帳に残し、②と③は、その台帳で状態が「ブロック」になっていない人を宛先にします。

つなぎ方は3通り：自作（GAS）、連携ツール、拡張ツールのCSV

向きが決まったら、つなぎ方を選びます。選ぶ軸は、誰が保守するか、同じ人を結ぶユーザーIDをどう扱うか、止まったときにどう直すか、です。

連携ツールのテンプレートが LINE 公式アカウントのイベントを受けてシートに書き込むものは、ツール各社の紹介ページで確かめられます。ただし、署名を検証するのか、webhookEventId が同じイベントを2回受けたら2行になるのかは、ツールの画面の説明だけでは分からないことが多いので、ツールの仕様で確かめます。受け口の順番（署名の検証、保存、200を返す、重複を除く）と再送の詳しい説明は「LINE × Slack連携｜問い合わせの転送と、Slackから返信するときの設計」にあります。

① LINE に来たものを、シートに残す

ユーザーが友だち追加したり、メッセージを送ったり、ブロックしたりすると、LINE のプラットフォームは Webhook URL に HTTP POST を送ります。1回の POST に複数のイベントが入ることもあるので、シートの1行は、POST ごとではなく、イベントごとに作ります（Webhook の受信）。

どのシートの、どの列に、何を書くか

友だち台帳は、follow イベント（友だち追加またはブロック解除）で行を足し、unfollow イベント（ブロックされた）で状態を「ブロック」にします。この更新ができるのは、署名を検証する受け口か人だけです。署名を検証できない GAS の受け口が受けたイベントは、受信ログに残し、台帳は書き換えません。偽の unfollow で「ブロック」にされると、その人への通知が止まるからです。ブロック中のユーザーにプッシュメッセージを送っても、API は200を返します。実際には届きません（Messaging APIリファレンス）。「ブロック」の状態を台帳に持っておくと、②と③で送る前に除けます。

取りこぼすと、取り直せない

ユーザーが送ったテキストは、Webhook のテキストメッセージオブジェクトでしか受け取れません。受信したあとで、あらためてテキストを取得する API はありません（Webhook の受信）。再送が無効のままなら、受け口が止まっていた間のメッセージは、シートに残りません。

Webhook の再送は、既定では無効です。有効にしても、再送されるのは、受け口が200番台を返さなかったときだけで、再送の回数と間隔は公開されておらず、確実な再送は保証されません。再送に頼る設計にはできないので、受け口は、受けたイベントをまず保存して200を返す形にします。

画像・動画・音声・ファイルは、Webhook で受け取るのはメッセージIDで、中身は別の API で取得します。取得できるのは一定期間だけで、期間が過ぎると自動で削除されます（同）。シートにメッセージIDだけを書いても、あとから中身は取れなくなります。

受け口を GAS にするときの制約

LINE は、Webhook を処理する前に、リクエストヘッダーの署名（x-line-signature）を検証するよう求めています（署名を検証する）。一方、Google の公式ドキュメントが、Web アプリの doPost(e) に渡されるイベントオブジェクトの項目として挙げているのは、クエリ文字列（queryString）、パラメータ（parameter・parameters）、パス（pathInfo）、本文の長さと中身（postData）です。リクエストヘッダーの項目はありません（Web Apps）。公式の項目表に従うかぎり、GAS の Web アプリは x-line-signature を読めず、署名の検証ができません。

署名を検証したいときの選び方は2つです。ヘッダーを読める場所（自社のサーバーや関数、署名を検証する連携ツール）に受け口を置き、シートへの書き込みだけを Google 側の API で行う。または、GAS の受け口で受けると決めて、届いた内容を信用しない設計にする。後者は、届いたものを記録するだけにとどめます。偽のリクエストでも行は入るので、その行を、②のプッシュ（通数がかかる送信）や他のシステムを動かすきっかけにしません。台帳の状態を書き換えるのも、署名を検証する受け口か人だけです。台帳の「配信OK」は人が入れる列なので、偽の行が入っても、③の配信先にはなりません。

グループ・複数人トークで、ユーザーIDが入らない人

Webhook の送信元がグループトークや複数人トークのとき、userId が入るのは、iOS 版・Android 版の LINE を使っているユーザーだけです（Messaging APIリファレンス（Webhookイベントオブジェクト））。プロフィール情報の取得に同意できない、PC 版の LINE だけを使い続けているユーザーが、これに当たります。公式は、2020年4月から PC 版では新しいアカウントを作れなくなったと注記しています（ユーザーのプロフィール情報取得の同意）。ユーザーIDが無いイベントは、台帳に入れず、受信ログにだけ残します。

ユーザーIDは、同じ人でも、プロバイダーが違えば別の値になります（ユーザーIDを取得する）。複数のアカウントのシートを1つに寄せる前に、プロバイダーが同じかを確かめます。会員IDとの結び付けを含めた詳しい説明は「Salesforce と LINE をつなぐ：何を・どの向きで・誰のIDで流すか」に譲ります。

② シートの内容を、LINE で知らせる

LINE Notify の代わりに使う Messaging API は、LINE 公式アカウントから、友だちになっているユーザーに送る仕組みです。通知を受ける人（お客様でも、社内の担当者でも）が、そのアカウントを友だち追加している必要があります。1対1のトークでは、7日以内にそのアカウントへメッセージを送った人にも送れます（プッシュメッセージを送る）。社内の担当者に送る通知の設計は「LINE社内通知・ワークフロー自動化ガイド」にもあります。

きっかけは、編集トリガーより時間トリガー

「シートが編集されたら送る」は、そのままでは作れません。onEdit(e) のような単純トリガーは、認可が要るサービスにアクセスできません。インストール型の編集トリガーなら、認可が要るサービスも呼べます（Simple Triggers・Installable Triggers）。もう1つの落とし穴は、スクリプトや API がセルを書き換えたときは、トリガーが動かないことです。公式の例は、Range.setValue() で編集しても、そのシートの onEdit が動かない、というものです。受け口がスクリプトで追記した行は、編集トリガーでは拾えません。

そのため、人が入力する行は、「送信待ち」の列に集めて、時間トリガーで読む形にします。署名を検証できない GAS の受け口が書いた行は、送信のきっかけにしません。偽のリクエストがシートに行を足しても、そこからお客様へのプッシュが動かないようにするためです。署名を検証する受け口が追記する行は、送信待ちにしてかまいません。時間トリガーは、最短で毎分動かせます。毎分だと1日に1,440回動くので、1回に3秒かかれば合計72分です。個人のアカウントの「トリガーの合計実行時間は1日90分」に近づきます（Workspace は6時間。出典：Quotas）。送るものが無い回は、すぐ終わるようにします。

二重送信を防ぐ：リトライキーを、送る前に書く

メッセージの送信は、500番台のエラーやタイムアウトで失敗したときも、実際には送られていることがあります。同じ内容をそのまま送り直すと、お客様に2回届きます。これを防ぐのが、リクエストヘッダーのリトライキー（X-Line-Retry-Key）です。キーは、自分で作った16進表記の UUID で、一度受理されると、同じキーの再送は409で断られます。キーが有効なのは、最初のリクエストから24時間です（失敗したAPIリクエストを再試行する）。

シートで使うときのコツは、キーを送る前に、行の列に書いておくことです。次の回で同じ行を読んだら、同じキーで送り直せます。送信済みの判定は、200と409のどちらも「済み」として扱います。ただし、LINE がリトライキーを管理するのは24時間で、同じキーを24時間を超えて使うと、すでに成功していても新しいリクエストとして成功し、重複して届きます（Messaging APIリファレンス）。キーを書いた時刻も列に残し、24時間の手前で止めて「要確認」にします。台帳で状態が「ブロック」の人も、送る前に除きます。コードの形は、次のとおりです。

// 「通知キュー」シート  A:ユーザーID  B:本文  C:状態  D:結果  E:リトライキー  F:キーを書いた時刻
// 「友だち台帳」シート  A:ユーザーID  C:状態（友だち／ブロック）
// 行を足すのは人（または署名を検証する受け口）。状態が「送信待ち」の行だけを送る。時間トリガー（毎分など）で動かす。
const KEY_LIMIT_MS = 23 * 60 * 60 * 1000;   // リトライキーの管理期間は24時間。手前で止める
function sendQueued() {
  const lock = LockService.getScriptLock();
  if (!lock.tryLock(10000)) return;
  try {
    const ss = SpreadsheetApp.getActive();
    const sh = ss.getSheetByName('通知キュー');
    const token = PropertiesService.getScriptProperties().getProperty('LINE_TOKEN');
    const blocked = new Set(ss.getSheetByName('友だち台帳').getDataRange().getValues()
      .filter(r => r[2] === 'ブロック').map(r => r[0]));
    const rows = sh.getDataRange().getValues();
    for (let i = 1; i < rows.length; i++) {
      const row = i + 1;
      const uid = rows[i][0], text = rows[i][1], status = rows[i][2];
      let key = rows[i][4];
      if (status !== '送信待ち' || !uid || !text) continue;
      if (blocked.has(uid)) {
        sh.getRange(row, 3, 1, 2).setValues([['要確認', 'ブロック中']]);
        continue;
      }
      if (key && Date.now() - new Date(rows[i][5]).getTime() > KEY_LIMIT_MS) {
        sh.getRange(row, 3, 1, 2).setValues([['要確認', 'キーが24時間に近い：届いたか確認してから、新しい行で送り直す']]);
        continue;
      }
      if (!key) {
        key = Utilities.getUuid();            // 送る前に列へ書いておく。再試行は同じキーで
        sh.getRange(row, 5, 1, 2).setValues([[key, new Date()]]);
        SpreadsheetApp.flush();
      }
      let code;
      try {
        code = UrlFetchApp.fetch('https://api.line.me/v2/bot/message/push', {
          method: 'post',
          contentType: 'application/json',
          headers: { Authorization: 'Bearer ' + token, 'X-Line-Retry-Key': key },
          payload: JSON.stringify({ to: uid, messages: [{ type: 'text', text: text }] }),
          muteHttpExceptions: true,
        }).getResponseCode();
      } catch (e) {
        sh.getRange(row, 4).setValue('通信エラー：次の回で再試行');
        continue;
      }
      if (code === 200 || code === 409) {
        sh.getRange(row, 3, 1, 2).setValues([['送信済み', code]]);   // 200 は受理。届いたとは限らない
      } else if (code >= 500) {
        sh.getRange(row, 4).setValue(code + '：次の回で再試行');
      } else {
        sh.getRange(row, 3, 1, 2).setValues([['要確認', code]]);
      }
    }
  } finally {
    lock.releaseLock();
  }
}
// 一度だけ実行して、毎分のトリガーを作る
function installTrigger() {
  ScriptApp.newTrigger('sendQueued').timeBased().everyMinutes(1).create();
}

200が返っても、届いたとは限らない

プッシュメッセージを、アカウントをブロックしているユーザーや、友だちでないユーザーに送ると、API は200を返しますが、実際には送られません（プッシュメッセージを送る）。シートの「送信済み」は、LINE が受理したという意味で、お客様に届いたという意味ではありません。大事な通知は、シートの別の手段（メールや電話）も残しておきます。

通数：送ると数える。応答メッセージは数えない

LINE 公式アカウントの通数は、「メッセージを送った回数」×「送った友だちの数」で数えます。1回のリクエストに入れるメッセージの件数は、通数に影響しません。プッシュ・マルチキャスト・ブロードキャスト・ナローキャストは数え、応答メッセージ（Reply API）は数えません（Messaging APIの料金・料金プラン）。届いたイベントへの返事は応答メッセージで、通数はかかりません。②のようにシートの変化をきっかけに送るものは、プッシュです。

追加メッセージの単価は、2026年10月1日の改定で、20万通/月までが1通3円、20万通を超えた分が1通2.5円になりました。追加メッセージを送れるのはスタンダードプランだけです（追加メッセージ料金改定のお知らせ・料金プラン）。ブロック中の人など、実際には届かない宛先は通数に数えません。そのため、上の表は上限の目安です。改定の全体は「LINE公式アカウントの料金改定（2026年10月）」に書いています。予約の確認やリマインドを、応答とプッシュのどちらで送るかの違いは、当社のデモ（架空の店舗・データ）「LINEで予約と、前日のリマインド」で見比べられます。

③ シートで配信リストを管理して、LINE で配信する

配信リストは、友だち台帳の「配信OK」の列で絞った、ユーザーIDの一覧です。ここに、配信の予定（日時・対象・本文・状態）を持つ「配信予定」のシートを足すと、手作業の配信の台帳になります。タグは、台帳の「区分・タグ」の列に、1人1行で持ちます。列を増やすたびに、誰が入力して、誰が見直すかを決めておきます。

台帳の人に送る方法は、2つです。

API で送る側を GAS で組むときの制限は、配信の人数より前に、実行の仕組みで決まります。1回の実行は6分まで、トリガーの合計は1日90分（個人）または6時間（Workspace）、外部への HTTP リクエスト（URL Fetch）は1日2万回（個人）または10万回（Workspace）です（Quotas）。10,000人への配信は20リクエストなので、回数の上限には届きません。1回の実行時間の6分に収まるかは、配信を何件に分けるかと、1リクエストの待ち時間で決まります。収まらない見込みのときは、未送信の行から再開するように、状態の列を持たせて複数回に分けます。

友だち全員のユーザーIDを一括で取れる API は、認証済アカウントまたはプレミアムアカウントでしか使えません（ユーザーIDを取得する）。それ以外のアカウントで、Webhook の受け口を作ったあとに台帳を作り始めると、台帳に載るのは、その後に友だち追加やメッセージの送信があった人だけです。それまでの友だちは、送ってきたときに初めてIDが分かります。台帳の人数と、LINE の管理画面の友だち数は、一致しないことを前提にします。

シートで足りなくなる境目：個人データの扱いと、会員データとの照合

Google スプレッドシートの上限は、1つのスプレッドシートで2,000万セルまたは100MBです（Google スプレッドシートの上限）。受信ログは本文を書くので、セルの数だけでなく、容量も見ておきます。上限のほかに、次の3つを見ます。

1 個人データとして扱う

ユーザーIDは、それだけで特定の個人を識別できるとは限りません。ただし、自社が持つ他の情報と、通常の業務における一般的な方法で容易に照合できるなら、個人情報に当たります。照合できるかどうかは、シートの単位ではなく、事業者の実態に即して判断されます。別のシートに分けても、自社の会員台帳と照合できるなら同じです（個人情報保護委員会「ガイドライン（通則編）」 2-1）。通則編には、ユーザーIDで整理したサービスのログを、ユーザーIDと個人情報を容易に照合できる場合は個人情報データベース等に当たるとする事例があります（2-4）。委員会は、オンラインゲームのニックネーム・IDについても、自ら保有する他の情報と容易に照合できれば個人情報に当たり得ると答えています（ガイドラインに関するQ&A Q1-9）。LINE のユーザーIDも同じ考え方で見ます。個人情報データベース等を構成する個人情報は、個人データです（通則編 2-6）。

LINE のユーザーデータポリシーでは、LINE 公式アカウントが受け取ったメッセージ、表示名、アイコン画像は「LINEユーザ情報」に入ります（1.1・1.2）。ユーザー識別のための内部識別子（ユーザーID）以外を24時間以上保存するなら、保存することをユーザーに明示する必要があります（3.2.3）。メッセージ本文を受信ログに残す設計は、ここに当たります。本人から開示・訂正・削除・利用停止を求められたら、対応しなければなりません（3.5.3）。受信ログから、そのお客様の行を探して消せる形にしておきます（LINEユーザーデータポリシー）。

2 見られる人の範囲を決める

シートを共有している人は、ユーザーIDと本文を見られる人です。受け口が書き込むシートは、書き込む人（アカウント）と、見る必要のある担当者に絞ります。ファイルを渡す委託先がいるときは、ポリシーの3.4.2（業務委託に必要な範囲で委託先に開示できる。委託先にも義務を守らせる）の範囲かを確かめます。

3 会員データと結ぶ

お客様の「会員」のデータと、LINE のユーザーIDを結ぶ段階になったら、シートの列で持つより、会員の台帳（CRM や業務データベース）の項目として持つほうが、直す人も権限も決めやすくなります。結ぶ費用の考え方は「LINEと今の顧客管理をつなぐ3つの作り方と、費用が決まる所」に、kintone を台帳にする場合は「BtoB kintone×LINE連携ガイド」にまとめています。

向きの見分けと、会員IDとLINEのユーザーIDを結ぶ設計、今の LINE の設定の見直しは、当社のLINE運用・伴走支援のページで、30分のオンライン相談として受け付けています。