LINE Bot本番運用の実務。監視・重複処理・再試行と復旧判断
LINE Botの本番運用では、受信できたか、業務処理が完了したか、通知を送れたかを別々に確認します。WebhookのURLが応答していても、予約DBへの登録が止まったり、送信待ちが積み上がったりすることがあるためです。
発注時に決めたいのは、監視ツールの名前だけではありません。どの状態で通知し、誰が対応し、何を確認したら再開するかまでを開発・保守の範囲へ入れます。本記事では、この判断に使える構成、運用表、受入確認表を整理します。
LINEの仕様は2026年9月8日に公式資料で確認しました。キューやDBの構成、通知のしきい値、障害シナリオは設計案です。ここに書いた構成での実配信や障害試験の結果を示すものではありません。
受信・業務処理・送信を分けて、途中から再開できるようにする
問い合わせや予約のBotでは、次の流れを設計の出発点にできます。すべてを大きなシステムとして作る必要はありませんが、処理がどこまで進んだかを記録できることが大切です。
- Webhookを受け、署名を確認する。
- 受信イベントと処理待ちの仕事を、障害後も取り出せる場所へ保存する。
- 保存できたことを確認して、Webhookへ成功応答を返す。
- ワーカーが予約DBや顧客DBの処理を実行し、結果を記録する。
- 必要な通知を送信し、受理・失敗・要確認などの状態を記録する。
LINEもWebhookイベントの非同期処理を推奨しています。Webhook受信の公式ガイド
受信しただけで成功応答を返し、その後のメモリ上の処理が消える構成では、再起動時に仕事を失います。一方、外部DBや長時間の処理をすべて終えるまでWebhookの応答を待たせると、受信自体が不安定になります。受信記録とキューへの投入が別システムになる場合は、片方だけ保存された状態から回復できる仕組みも設計します。
即時の応答メッセージが必要な処理は、長い待ち行列に入れない経路を用意します。受付の応答、業務の完了、後日の結果通知を分けることで、返信期限と長時間処理を扱いやすくなります。
受信時は未加工の本文で署名を確認する
Webhookの署名は、受信したリクエスト本文とチャネルシークレットを使って確認します。署名の検証が済む前にJSONを整形したり、別の文字列へ変換したりすると、検証に使う内容が変わってしまいます。公式のWebhook署名検証手順
実装・受入時には、アプリ本体だけでなく、手前のプロキシやフレームワークによる本文変換も確認します。署名不一致のときに予約作成や返信などの業務処理へ進まないこと、シークレットの切り替えを担当者が把握できることを確認項目に入れます。
チャネルシークレットやアクセストークンは、本文・エラー画面・通知先へ出力しない設計にします。調査ログにはイベントID、処理ID、時刻、エラー分類などを残し、問い合わせの全文や個人情報は、必要な範囲と保存期間を決めて扱います。
重複排除は、受信イベントと業務操作の2段階で行う
Webhookは同じイベントが複数回届いたり、発生順と受信順が変わったりすることがあります。webhookEventIdは重複検出に使えます。再送は設定で有効にしますが、すべての再送が保証されるわけではありません。公式のWebhook再送仕様
設計では、次の識別子の役割を分けます。
| 識別子・記録 | 何を区別するか | 使用例 |
|---|---|---|
| WebhookイベントID | 同じイベントの再受信 | 同じ予約希望イベントを2回処理しない |
| 業務の依頼ID・予約ID | 利用者が実行した一つの依頼 | ボタンの連打や再接続でも同じ予約を増やさない |
| 送信ジョブID・リトライキー | 一つの通知送信の試行 | 通信切断後も同じ通知として再試行する |
| APIのリクエストID | 個々のAPI呼び出し | 時刻・結果と合わせて問い合わせや調査に使う |
受信IDを記録した直後にプロセスが停止する場面にも注意します。「IDが存在するから処理済み」と判定すると、保存は済んだが業務処理は未完了、という仕事を捨ててしまいます。受信済み・処理中・完了・要確認などの状態を保存し、未完了の仕事を再開できるようにします。
また、イベントIDが違っていても、同じ利用者が同じ予約操作を繰り返している可能性があります。予約DBへの登録には依頼IDを持たせ、状態変更を重複適用しない設計にします。順序が逆転した変更・取消は、現在の予約状態や版を確認して処理します。具体例はLINE予約システムの構成と設計を参照してください。
reply tokenは即時応答に使い、期限切れの扱いを決める
応答トークンは1回だけ使用でき、Webhook受信後1分以内の使用が求められます。再送Webhookのトークンも再受信後1分以内に使用しますが、すでに使用済み、またはイベント発生から20分経過した場合は使えません。利用できる期間はネットワーク状況等で変わるため、境界の時刻まで待つ実装は避けます。公式の応答トークン仕様
外部システムの集計やスタッフの確認が必要なら、受付時には受付状態を応答し、結果は別の方法で通知する設計を検討します。返信期限を過ぎた仕事について、同じトークンで送信を繰り返すことはしません。
Pushへ切り替える場合も、宛先の条件、通知の必要性、送信費用を確認します。Push対象には友だちや参加中のグループ等のほか、直近7日以内に1対1でメッセージを送ってきたユーザーが含まれます。ブロック等では200応答でも届かないため、Pushの成功応答を利用者への到達確認として扱えません。公式のPush送信条件
たとえば問い合わせ受付なら、返信できなかった案件を担当の対応一覧へ残します。予約なら確認画面を案内し、重要な連絡が必要な案件は有人対応へ回します。Pushへの切り替えを一律の救済策にしないことが、運用上の判断になります。
エラーを分類して、再試行・停止・有人確認を選ぶ
送信の失敗には、通信の一時的な問題、認証情報、リクエスト内容、利用上限など複数の原因があります。次の表は運用判断の例です。個別APIの応答本文も確認して、原因を分類します。Messaging APIのステータスコードとエラー
| 観測した状態 | 自動処理の方針例 | 人が確認すること |
|---|---|---|
| 400などの入力エラー | 同じ内容の無条件再送を止め、対象を要確認へ | メッセージ形式、パラメータ、返信トークン |
| 401・403 | 該当する送信を止め、担当へ通知 | トークン、権限、契約・設定 |
| 429 | 送信を抑制し、原因確認まで対象を保留 | レート制限、同時処理、通数上限等のどれか |
| 500番台・通信タイムアウト | 対応APIでは同じリトライキーで、間隔を空けて再試行 | 長期化、送信期限、利用者への影響 |
| 200番台 | 受理として記録し、同じ送信を繰り返さない | 業務上の確認が必要か。到達済みとは断定しない |
| リトライキー重複による409 | 受理済みとして扱い、再試行を終了 | 元の送信ジョブとの対応 |
429であっても、月の通数を使い切った状況と、短時間の送信集中とでは解決方法が違います。待てば再開できる制限か、プラン・上限・送信対象の変更が必要かを分けます。原因が解消したことを確認してから、保留中の仕事を再開します。
リトライキーは最初の送信から固定する
Push等の対応APIでは、最初の送信からX-Line-Retry-Keyを付け、再試行でも同じ宛先・内容・キーを使います。キーの有効期間は最初のリクエストから24時間です。応答メッセージを含む未対応APIへ一律に付けるものではなく、確実な配信を保証する機能でもありません。公式のAPI再試行ガイド
送信するたびに新しいキーを作ると、通信切断の前に受理された通知と、再試行した通知が別物になります。送信ジョブを作る時点でキーを決め、試行履歴と一緒に保存する設計にします。
再試行は、間隔を徐々に広げ、回数と終了時刻に上限を設けます。たとえば「本日の予約開始前までに必要な通知」は、技術上の再試行可能時間が残っていても、予約開始後に送るべきかを業務側で判断します。期限を過ぎた仕事は、再送停止・別文面・有人確認のどれにするか決めます。
監視は、利用者への影響と担当をセットにする
監視対象は受信URLの死活だけでなく、処理待ち、業務失敗、送信、利用量まで広げます。下表は運用表の記入例です。しきい値は取扱件数や業務時間に合わせて決め、公式の推奨値やサービス保証値とは区別します。
| 見るもの | 通知条件の決め方 | 通知先の担当 | 最初に行うこと |
|---|---|---|---|
| Webhook到達・エラー | 外形確認の連続失敗、受信エラー増加 | 保守の一次担当・不在時の代替担当 | 自社受信基盤と外部の障害状況を確認 |
| 処理待ちの最長時間 | 業務上許容する受付・回答時間へ近づいた | 保守担当と受付責任者 | 処理停止か件数増加かを切り分ける |
| 予約・顧客DBの処理失敗 | 未完了が残る、同じ失敗が続く | 連携担当・業務責任者 | 自動確定の継続可否を判断 |
| 送信のエラー分類 | 認証エラー、原因別の失敗増加 | 保守担当 | 対象の送信を止め、設定を確認 |
| 送信通数と月末予測 | 契約枠・予算・業務用の確保量へ近づく | アカウント管理者・予算担当 | 販促停止やプラン変更等を判断 |
| 要確認の仕事 | 対応期限超過、担当未設定 | 業務責任者 | 有人対応を割り当てる |
通知経路も運用対象です。通知先が退職者の個人アカウントのままにならないようにし、担当と代替担当が受け取れることを確認します。LINE Bot自体の障害を知らせる連絡は、同じBotだけに依存しない経路を用意します。
また、HTTPの外形確認だけでは、顧客DBへの書き込みまで正常かは分かりません。業務を代表する試験操作を検証環境で定期確認し、本番では顧客への誤配信を起こさない監視方法と対象を別に定めます。
送信通数と費用を、業務通知・販促に分けて管理する
Messaging APIの送信方法には、料金プランの通数へ数えられるものと数えられないものがあります。Push等と応答メッセージを分け、通数の上限と当月利用量を確認します。Messaging APIの料金・利用状況
運用上は、予約確定・変更通知・リマインド・販促など、用途別の送信予定を持つと判断しやすくなります。販促を送った後に予約通知の予定分が足りなくなるなら、先に販促対象や配信日を見直します。
月末予測は、経過日数からの単純な割り戻しだけでなく、今後予定している一斉配信や予約通知を加えます。未確定の予約件数は仮定として明示し、管理画面の利用量と自社の送信予定を照合します。APIの試行回数をそのまま課金通数と見なさないようにします。
レート制限はチャネルとAPI機能ごとの条件を確認します。同じチャネルを複数のバッチやサービスが使っている場合は、その合計で送信を制御する必要があります。公式のレート制限
架空の障害例：予約DBが10分間使えなくなった場合
以下は復旧手順を考えるための架空のシナリオです。LINEから受けた予約希望は保存できていますが、予約DBへの登録だけが10分間停止したとします。
まず保守担当は、受付イベントの保存範囲と未完了件数を確認します。業務責任者は、新規の自動確定を止めるか、未確定の受付として受けるかを判断します。DBへ登録できていない段階で、利用者へ確定したと案内しません。
DBが復旧したら、全件をそのまま流し直す前に、登録結果が不明な依頼を照合します。障害直前に登録済みだった予約を再作成せず、未登録の依頼だけを現在の空き枠に対して処理します。障害中に電話で埋まった枠については、別候補の案内や有人調整へ回します。
返信期限を過ぎたもの、日時変更や取消が後から入ったものは、現在の業務状態を見て扱いを決めます。古い応答トークンや通知内容を、復旧したという理由だけで再利用しません。
最後に、未完了・重複・要確認の件数、利用者への案内、通常処理の再開結果を照合して復旧を判断します。「サーバーが起動した」は技術的な回復の一部であり、受付済みの仕事を確認するところまでが業務復旧です。
発注・引き継ぎで決める運用範囲
保守契約や社内分担では、次の項目を記入します。対応時間外も利用者が操作できる場合は、時間外に自動で行うことと、翌営業日に対応することを分けます。
| 項目 | 記入する内容 |
|---|---|
| 管理者と資産 | 公式アカウント、チャネル、サーバー、DB、ソースコードの所有者と権限管理者 |
| 通知と初動 | 一次担当、代替担当、通知経路、対応時間、引き継ぐ条件 |
| 再開の権限 | 誰が送信停止・自動確定停止・再開を判断できるか |
| 連携先の責任 | 外部DBや予約サービスの担当、問い合わせ方法、復旧確認方法 |
| データとログ | 保存対象、期間、閲覧権限、調査時の取得方法 |
| 定期作業 | 依存ライブラリ、認証情報、バックアップ、通知先の点検担当 |
| 仕様変更 | 公式更新の確認頻度、影響調査、改修の保守内外、適用期限の管理 |
| 成果物 | 構成図、復旧手順、設定一覧、試験記録、未解決事項 |
仕様変更の確認を年1回行えば十分とは限りません。利用機能に関連するLINE Developersの更新情報を確認する担当を置き、変更内容と適用日を自社の保守予定へ反映します。
契約前の相談ではLINE開発の発注ガイド、条件の記入には要件定義テンプレートを使えます。APIの基本的な実装手順はPythonでMessaging APIを使う記事で確認し、本番固有の運用条件を本記事と合わせて検討してください。
本番前の受入確認表
試験用のチャネル・利用者・業務データを用意し、受入条件を先に合意します。下表は試験項目の案であり、試験済みの結果ではありません。
| 試験場面 | 確認する結果 |
|---|---|
| 署名不一致、本文が変わったWebhook | 業務処理を実行せず、原因を調査できる |
| 同じWebhookを複数回受信 | 業務への反映は重複しない |
| 受信保存の直後に処理を停止 | 再開後に未完了の仕事を処理できる |
| キューや保存先へ書き込めない | 成功応答だけで受信済みと扱わず、障害を検知できる |
| 順序の逆転、同時の変更・取消 | 古いイベントで現在の業務状態を上書きしない |
| 応答トークンが使用済み・期限外 | 同じトークンの再試行を続けず、定めた代替対応へ進む |
| 送信直後に接続が切れる | 同じジョブのリトライキーを維持し、重複送信を抑える |
| 429や認証エラー | 原因に応じて抑制・停止し、担当へ必要な情報が届く |
| ブロック等でPushが届かない | 200を到達済みと表示せず、業務上の確認経路がある |
| 予約・送信の期限が過ぎる | 古い処理を無条件に実行せず、停止または有人確認する |
| 一次担当が不在 | 代替担当へ通知され、必要な権限で初動できる |
| 障害から復旧する | 未完了と重複を照合し、業務責任者が再開を判断できる |
よくある質問
Webhookの再送を有効にすれば、受信漏れはなくなりますか？
再送はすべてのイベントの到達を保証するものではありません。受信内容と処理状態を保存し、重複や順序の逆転を扱えるようにします。未完了の仕事を監視し、障害後に業務データと照合する手順も必要です。
reply tokenの期限を過ぎたら、すべてPushで送り直せますか？
一律には切り替えられません。Pushの送信対象条件、通知の必要性、費用を確認します。ブロック等で届かない場合もあるため、予約確認画面や有人対応など、業務に合う代替経路を決めます。
APIが200を返したら、利用者に届いたと判断できますか？
Pushでは、ブロック等により200応答でも利用者に届かない場合があります。APIの受理と利用者への到達を分けて扱い、重要な業務では確認画面や利用者の確認操作などを用意します。
小規模なBotでも監視や保守担当は必要ですか？
予約や問い合わせを業務で受け付けるなら、失敗や未対応に気づく方法と対応担当が必要です。件数に応じて構成を小さくすることはできますが、通知先、代替担当、復旧判断、送信量の確認は先に決めておきます。
この記事に関連するサービス
TodoONadaでは、Botの機能と合わせて、既存システムとの連携や運用条件を整理します。既存Botの見直しでは、現在の構成、対応時間、停止すると困る業務、保守の分担をもとにご相談いただけます。
出典・参照
- LINE Developers — Webhookの署名を検証する （2026年9月8日確認）
- LINE Developers — メッセージ（Webhook）を受信する （2026年9月8日確認）
- LINE Developers — 応答メッセージを送る・応答トークン （2026年9月8日確認）
- LINE Developers — プッシュメッセージを送る （2026年9月8日確認）
- LINE Developers — 失敗したAPIリクエストを再試行する （2026年9月8日確認）
- LINE Developers — Messaging APIの共通仕様 （2026年9月8日確認）
- LINE Developers — Messaging APIの料金 （2026年9月8日確認）
- LINE Developers — 更新情報 （2026年9月8日確認）
