LINEが止まった時間、予約のリマインドや問い合わせはどうなるか｜2026年の障害告知から

LINE が止まった時間に送ったリマインドは、送られなかったことが分かる場合と、送れたかどうか分からないまま残る場合があります。どちらになるかは、仕組みが受け取ったステータスコードで分かれます。500番台やタイムアウトなら、最初のリクエストにリトライキーを付けていれば、同じリクエストを再試行して、重ならずに拾い直せます。お客さんの問い合わせは、Webhook の再送を有効にしていれば、自社のサーバーが受け損ねた分は LINE から送り直されます（確実な再送の保証は無いと書かれています）。ただし、LINE 側で送信が遅れた、または行われなかった分を後から送り直すとは、2026年の障害の告知には書かれていません。どちらも、拾い直せるかどうかは、障害の前に自社の仕組みで何を記録し、どの設定にしていたかで決まります。

LINE とつないだ仕組みは、LINE の側が止まったときの影響も一緒に受けます。当社は、LINE公式アカウントの運用と、そうした LINE とほかのシステムの連携を支援しています。この記事を書くのは、2026年の LINE Developers のニュースに、Messaging API や LINEログイン、LIFF などの障害の告知が10月14日までに10件出ていて、止まったものが告知ごとに違うからです。コンテンツの取得だけ、リッチメニューだけ、Messaging API のすべてのエンドポイント、特定のバージョンの Android 版 LINE での LIFF だけ、と範囲が違えば、予約のリマインドと問い合わせに起きることも違います。なお、題では「止まった」と書きましたが、告知の多くは、すべてが止まったのではなく、一部のリクエストが正常に処理されなかった、という書き方です。

対象は、予約のリマインドや注文の通知、問い合わせの受け付けを、Messaging API を使う自社の仕組みや外部のツールで LINE に載せている会社の担当者です。数えたのは LINE Developers のニュースに出た開発者向けの製品の告知で、LINE アプリや LINE公式アカウントの管理画面（LINE Official Account Manager）の不具合は数えていません。管理画面の使い方や困りごとは、LINEヤフーのLINE公式アカウントのヘルプセンターが窓口です。Webhook の受け口の作り方は「LINE × Slack連携」と「Salesforce×LINE連携の費用比較」に書いています。通数に数えない送り方は「LINEの通知を通数に数えない送り方はあるか」、電話番号宛ての通知メッセージは「LINE通知メッセージとは」に譲ります。

例は2つの連絡に固定します。店が前日18時に送る予約のリマインド1通と、お客さんが LINE で送ってくる問い合わせ1件です。どちらも、記事の途中に置いた当社のデモ（架空の店舗・会社・データ）で、送る・受ける動きを確かめられます。

2026年1月〜10月14日の告知は10件で、止まったものは告知ごとに違う

LINE Developers のニュースに2026年1月〜10月14日に出た障害の告知は、次の10件です（数え方は末尾）。10件とも「復旧済み」で、時刻は告知の原文どおりです。

出典：各行の告知（LINE Developers のニュース、「障害報告」のタグ）。日付は告知の掲載日で、発生日時と違う行があります。長さは告知の「頃」の時刻から当社が計算しました。

このうち Messaging API に影響したのは7件です。長さを並べると、1分前後で終わったものと、4時間を超えたものの差が大きいことが分かります。

予約のリマインドと問い合わせに関わる書き方は、3つに分かれます。1つ目は「一部のリクエストを正常に処理できず、ステータスコード500番台のエラー」で、3月19日・4月17日・7月28日・8月4日・9月15日〜16日・10月6日の6件にあります。送る側の仕組みが受け取るのは、この500番台です。2つ目は、Webhook イベントの送信が遅れた（3月19日）、または遅れたか正常に行われなかった（7月28日・10月6日）という書き方で、問い合わせの受け取りに関わります。3つ目は2月3日のコンテンツの取得で、返ってきたのは400でした。お客さんが送った画像や動画などを取り出す API なので、問い合わせの添付が取り出せない、という形で出たと考えられます。400番台は、送信の API の再試行の決まりでは「再試行しても結果は変わらない」側のコードですが、この日は LINE 側の障害でした。返ってきたコードだけで自社の不具合と決めず、告知の時間帯と照らし合わせる理由がここにあります。

7月28日の告知は、16:46頃〜21:11頃の約4時間25分で、前日18時のリマインドを送る時刻を含みます。Messaging API では Webhook の遅延・未送信と500番台、LIFF/LINEミニアプリではサービスメッセージの送信の遅延・未送信が挙がっていて、7月28日・29日、8月3日・5日の4回、追記で更新されています。電話番号宛ての通知メッセージを使っている場合は、7月28日と9月15日〜16日の告知が当たります。届いたかの見分け方は「LINE通知メッセージとは」に書いています。

LINE 側か自社の不具合かは、速報・告知・自社の記録で見分ける

送信のエラーが続いたり、問い合わせが途切れたりしたとき、最初に分けたいのは、LINE 側の障害か、自社の仕組みの不具合かです。LINEヤフーは、LINE プラットフォームの稼働状況と障害を英語で速報する LINE API Status を出していて、原因や影響範囲などの詳細は LINE Developers のニュースで知らせるとしています。対象は Messaging API（API と Webhook）、LINE Developers のサイトとコンソール、LIFF、LINEログインです（「LINEプラットフォームの稼働状況を確認する（LINE API Status）」）。ATOM と RSS のフィードがあるので、担当者が見るチャットやメールに届くようにしておけます。

問い合わせが途切れた時間帯に告知が無いときは、速報の履歴も見ます。2026年10月13日15時台には、LINE API Status に一部のボットサーバーへの Webhook イベントの遅延・未送信の記録があり、ニュースの告知はありません。この記録には、影響が限られたためニュースには載せない、と書かれています。自社の記録に、送信で返ったコードと Webhook を受け取った時刻が残っていれば、速報や告知の時間帯と突き合わせて、どちら側かを判断できます。

前日18時のリマインドは、返ってきたステータスコードで次の手が決まる

前日のリマインドは、お客さんが何もしていない時刻に店の仕組みが送る連絡で、送り方はプッシュメッセージか、LINEミニアプリで予約した人へのサービスメッセージです（送り方ごとの通数は「LINEの通知を通数に数えない送り方はあるか」）。拾い直す材料になるのは、仕組みが送ったときに受け取った返事です。プッシュメッセージなど送信の API で、再試行するかどうかは、LINE Developers の「失敗したAPIリクエストを再試行する」にステータスコードごとに決められています。

500番台とタイムアウトを「送れなかった」と決めないのは、エラーが返ってもメッセージが送られている可能性があるからです。同じリクエストをそのまま送り直すと、お客さんに同じリマインドが2通届くことがあります。そこで、リクエストのヘッダーにリトライキー（X-Line-Retry-Key、任意の方法で作った16進数の UUID）を付けておくと、何度送っても一度しか実行されず、すでに受理されていれば409が返ります。リトライキーは最初のリクエストで付けておかないと再試行に使えず、有効なのは最初のリクエストから24時間です。再試行するリクエストは元と同じ内容・同じ宛先にし、間隔は指数バックオフにするよう勧められています。プッシュ・マルチキャスト・ナローキャスト・ブロードキャスト以外の API のヘッダーに付けると、400で拒否されます（「失敗したAPIリクエストを再試行する」）。3月19日・9月16日・10月6日の告知も、リトライキーを使って再試行する作りにしておけば、同じ処理の重複を防ぎながら安全に再試行できる、と案内しています。

例のリマインドに当てはめます。7月28日の告知の時間帯（16:46頃〜21:11頃）に18時のリマインドを送っていた仕組みは、一部のリクエストで500番台を受け取っていた可能性があります。リトライキーを付けていれば、同じリクエストを指数バックオフで再試行でき、復旧した21:11頃は最初の送信（18時）から約3時間後なので、リトライキーの24時間の中に収まります。付けていなければ、その分は再試行ではなく新しい送信になり、実は届いていた人には2通目のリマインドになります。

200番台が返っても、届いたとは限りません。プッシュメッセージは、もともと、LINE のアカウントを削除した人やブロックしている人、友だちでない人（7日以内にメッセージを送ってきた人を除く）に送ったときも200を返し、実際には送らない決まりです（「プッシュメッセージを送る」）。加えて、3月19日と10月6日の告知には、障害の影響で API のリクエストは成功したのに実際には送られなかったメッセージは、LINE公式アカウントの利用料金にも、「送信済みのプッシュメッセージの数を取得する」などで分かる送信済みの数にも数えない、と書かれています。200は再試行しない側のコードで、同じリトライキーで送っても409が返るだけです。

告知の時間帯に200で送った分をどう扱うかは、連絡の中身で決めます。2通届いても支障が小さいと自社で判断できる連絡なら、新しいリクエストとして送り直せます。2通届くと困る連絡なら、送り直さずに予約の記録に印を付け、電話やメールなど別の手段で確かめる、という分け方です。送信済みのプッシュメッセージの数は日ごとの合計で、集計は通常は翌日中に終わり、管理画面から送った分は含みません。翌日にその日の数を自社の記録と並べれば、届いていない分があったかの手がかりにはなりますが、どのお客さんの分かまでは分かりません（リファレンス）。

サービスメッセージで送っている場合、7月28日の告知はサービスメッセージの送信の遅延・未送信を、10月6日の告知は正常に送信されない場合があったことを挙げています。リトライキーを付けられる API の一覧に、サービスメッセージの送信は入っていないので、送り直すときの重複の防ぎ方は自社の仕組みで持つことになります。サービスメッセージは1つの操作に最大5回までで、送り直して受理された分も、その5回のうちの1回になります（「サービスメッセージを送信する」）。

前日18時のリマインドが、お客さんが何もしていない時刻に店の仕組みから送られる連絡であることは、架空の店舗・データで作った当社のデモで確かめられます。デモに障害やエラーを起こす操作はありません。実際の仕組みでは、デモで時刻を進めて送られる時点に送信の API を呼び、返ってきたステータスコードを記録することになります。

問い合わせの再送は、自社の受け口が200番台を返さなかった分

お客さんの問い合わせは、LINE プラットフォームから自社の受け口（LINE Developers コンソールの「Webhook URL」に指定したサーバー）へ、HTTP POST で届きます。止まった時間に受け取れない理由は2つに分かれ、拾い直せるかどうかが違います。

自社の受け口が受け損ねた分は、再送を有効にしていれば送り直される

Webhook の再送は、すべての Messaging API のチャネルで使えますが、初期設定では無効です。有効にするには、LINE Developers コンソールでチャネルの設定画面を開き、［Messaging API設定］タブで［Webhookの利用］を有効にしたうえで、［Webhookの再送］を有効にします。有効にするときに再送の注意事項が表示されるので、確かめてから有効にします。再送されるのは、再送を有効にしていて、Webhook に対してボットサーバーがステータスコード200番台を返さなかったときで、一定の期間内に、一定の時間を空けて送られます。回数と間隔は開示されておらず、予告なく変わることがあります。確実な再送を保証するものではなく、再送の件数が急に増えて LINE プラットフォームの動作に影響すると判断された場合は、再送の設定が強制的に無効になることもあります（「メッセージ（Webhook）を受信する」）。

再送を有効にすると、ネットワークの経路の問題などで、同じイベントが重複して届くことがあります。再送されたイベントは deliveryContext.isRedelivery の値のほかは元と同じで、webhookEventId（ULID 形式のイベントID）も応答トークンも変わりません。重複は webhookEventId で見分けて捨て、届く順序が発生順と変わったときは timestamp で並べ直します。timestamp は再送でも、再送された時刻ではなくイベントの発生時刻です（同ページ・Webhookイベントオブジェクト）。

再送で届いた問い合わせの応答トークンは、再送を受信してから1分以内なら使えますが、元のトークンをすでに使っていた場合と、イベントの発生から20分が過ぎた場合は使えません（「応答トークン」）。受け口が長く止まっていた後に届いた問い合わせには、応答メッセージではなくプッシュメッセージで返すことになり、プッシュメッセージは通数に数えます。

受け口が受け損ねたことは、［エラーの統計情報］で確かめられます。これも初期設定では無効で、［Messaging API設定］タブでオンにすると、［Webhookエラー］タブにエラーの日付・最初と最後に検知した時刻・原因・同じステータスコードが60秒間に起きた件数が出ます。オンにしていた期間しか集計されず、時刻は UTC+9 で、TSV で書き出せます。原因は could_not_connect（接続できない）、request_timeout（2秒以内にレスポンスが返らない）、error_status_code（200番台以外を返した）、unclassified の4つです。request_timeout の場合は、受け口の側では受け取れている可能性もあると書かれています（「Webhookのエラーの原因と統計情報を確認する」）。

再送と重複の扱いは、架空の会社・データで作った当社のデモで確かめられます。LINE の問い合わせを社内のチャンネルに転送するデモで、LINE が同じ Webhook を再送したときに、イベントIDで捨てる場合と捨てない場合を切り替えられます。デモの会社は例の整体院とは別の架空の会社ですが、受け口で重複を捨てる動きは同じです。

LINE 側の送信が遅れた・行われなかった分は、遅れた分だけが見分けられる

2つ目の場合は、自社の受け口が200を返していても起きます。再送の条件は、ボットサーバーが200番台を返さなかったとき、と書かれていて、LINE 側から送られなかった Webhook イベントについては書かれていません。3月19日・7月28日・10月6日の告知の本文にも、送られなかったイベントを後から送り直すとは見当たりません。さらに、［エラーの統計情報］に出るのは LINE プラットフォームが実際に送信を試みた Webhook だけで、ユーザーが送ったテキストを Webhook の後にあらためて取得する API もありません（「Webhookのエラーの原因と統計情報を確認する」・「メッセージ（Webhook）を受信する」）。止まっていた時間に届かなかった問い合わせを Messaging API で取り戻す方法は、公式の資料には見当たりません。

遅れて届いた分は見分けられます。timestamp はイベントの発生時刻なので、受け取った時刻と大きく離れていれば、遅れて届いたイベントです。お客さんから後で「LINE で送ったのに返事が無い」と言われたときは、受け口の記録と［Webhookエラー］タブを合わせて見ます。受け口の記録にその時間帯のイベントが無く、［Webhookエラー］タブにもその時間帯のエラーが無ければ（統計情報をオンにしていた場合）、LINE 側で送られなかった可能性があります。エラーがあれば、まず自社の受け口の側を疑い、原因（could_not_connect など）と詳細の値で確かめます。request_timeout には送信が途中で失敗した場合も含まれ、受け口で受け取れている可能性もあると書かれていて、unclassified は分類できない不明なエラーです（「Webhookのエラーの原因と統計情報を確認する」）。

LINE 側で送られなかったと見られる問い合わせには、2つのことができます。1つは LINEヤフーへの報告です。LINE Developers のよくある質問は、LINE プラットフォームで起きた問題の報告を、ヘルプセンターの「問題報告フォーム」から受け付けると案内しています（すべてに返答できない場合があるとも書かれています）。報告には、発生した日時と、受け口の記録・［Webhookエラー］タブで分かったことを添えます。もう1つはお客さんへの案内です。届かなかった問い合わせは送った人が分からないので、案内は「〇月〇日〇時ごろに LINE でお送りいただいたお問い合わせが、届いていない場合があります。お手数ですが、もう一度お送りください」のように、時間帯を示して送り直しを頼む形になります（文面は作例です）。友だち全体に配信すれば通数に数えるので、配信で知らせるか、ウェブサイトなどに載せるかは、通数の残りと合わせて決めます（「LINEの通知を通数に数えない送り方はあるか」）。

問い合わせを Slack に転送して返す作りで、LINE と Slack の両方の再送が重なったときの二重の投稿・二重の返信の防ぎ方は「LINE × Slack連携」に書いています。

告知が出たら、自社の記録をこの順で見る

告知や速報で障害を知ったら、自社の記録を次の順に見ます。再試行は告知を待たずに仕組みの中で行い、告知が出た後は結果を確かめるだけにします。告知は発生の翌日に載ることもあり（2月3日の障害の告知は2月4日）、リトライキーの24時間は最初のリクエストから数えるためです。5の送信済みの数は翌日以降にしか出ないので、最後に見ます。

この順で見るには、障害の前から次の項目を記録しておく必要があります。どれも公式の API の返事や Webhook の項目にあるものです。

• 送る側：送った時刻、宛先のユーザーID、リトライキー、ステータスコード、リクエストID（X-Line-Request-Id）、プッシュメッセージの返事の sentMessages.id
• 受ける側：webhookEventId、timestamp、受け取った時刻、deliveryContext.isRedelivery、ユーザーID

外部のツールで送っている・受けている場合は、同じ項目をツールの画面や書き出しで見られるかを、ツールの提供元に確かめておきます。2月3日の告知のように、特定の API だけが止まった日もあるので、どの API で何を送り、何を取り出しているかの一覧もあると、1の照らし合わせが早く済みます。

次の障害の前に、［Messaging API設定］タブを開く

まず、自分のチャネルの LINE Developers コンソールで［Messaging API設定］タブを開き、［Webhookの再送］と［エラーの統計情報］がどうなっているかを見てください。どちらも初期設定では無効で、エラーの統計情報はオンにしていた期間しか集計されません。再送を有効にするなら、その前に、受け口が webhookEventId で重複を捨てられるかを確かめます。送る側は、プッシュメッセージのリクエストに最初からリトライキーを付けているかを、仕組みを作った人に確かめます。LINE API Status のフィードが担当者の目に入るようにしておくと、告知が出る前に気づける場合があります。

LINE の仕組みを今の予約や顧客の記録とどうつなぐかと、その費用が決まる所は「LINEと今の顧客管理をつなぐ3つの作り方」に書いています。送信の記録の残し方や受け口の作りを、今の予約や顧客の仕組みと合わせて見直したいときは、当社のLINE運用・伴走支援でご相談いただけます。

数え方：LINE Developers のニュースの一覧（1〜7ページ）を2026年10月14日に開き、2026年1月1日〜10月14日に掲載された告知55件のうち、題に「障害」を含む10件を数えました。「障害報告」のタグの一覧でも、2026年の告知は同じ10件でした。メンテナンスの告知（1月5日）と、機能の一部の一時停止の告知（9月15日、LINEミニアプリの友だち追加オプション）は数えていません。告知は後から追記されることがあり、件数は今後変わります。LINE API Status は同じ日に履歴の RSS を取得して、10月13日の記録を確かめました。長さは告知の「頃」の時刻から当社が計算したものです。再試行・Webhook の再送・エラーの統計情報・API の仕様と画面の名前は、同じ日に LINE Developers のドキュメントとリファレンスで確かめました。