LINE Webhookのstandbyモード：replyTokenがない理由

LINEのWebhookイベントが mode: standby の場合、イベントを受信しても、そのチャネルが返信すべきとは限りません。LINEのモジュールチャネル向けドキュメントでは、待機中のチャネルはメッセージ送信を控えること、届くイベントには replyToken が含まれないことが説明されています。これはChat Controlの主導権の問題であり、トークンの期限切れやWebhook配信失敗の証拠ではありません。まずイベントのモードと連携方式を確認してください。

要点

• Webhookを正常に受信していても、返信を担当するチャネルとは限りません。
• replyToken がないという理由だけでプッシュメッセージに切り替えないでください。
• モジュールチャネルは特定の法人向け機能で、すべてのボットに共通する設定ではありません。
• イベントの受信、返信担当、送信結果を別々に管理します。

activeとstandbyの意味

公式のモジュールチャネルからMessaging APIを利用するガイドでは、応答前に mode を確認するよう案内しています。ドキュメントに記載されたモジュール構成では、アタッチされているチャネルのうちactiveは1つだけで、ほかはstandbyです。

イベントのモード	ドキュメント上の意味	アプリケーション側の判断
active	受信チャネルに主導権があり、返信やプッシュを送信できる	イベント種別と通常の送信条件を確認する
standby	受信チャネルは待機中で、イベントに replyToken がない	許可された内部処理は行い、顧客向け送信は抑止する
欠落・未知の値	想定する連携仕様を確認できていない	原本とパーサーを調べ、activeと決めつけない

最後の行は推奨する防御的な方針であり、LINEが追加したモードではありません。また、active であっても、すべてのイベントに返信トークンがあるわけではなく、返信が必要とも限りません。Messaging APIリファレンスで対象イベントの定義を確認してください。

これは、通常の複数ツールで1つのMessaging APIチャネルを共有する話とは別です。複数ツール連携のチェックリストは認証情報、Webhookの管理主体、共有上限を扱います。モジュール構成では、さらに「どのチャネルが現在の返信主導権を持つか」を確認します。

Moduleのドキュメントが適用されるか確認する

LINEは、Module機能を所定の申請を行った法人向けに提供すると説明しています。通常のボットがモジュールをアタッチしたり、Chat Control操作を呼び出したりできると想定して設計しないでください。

Chat Controlガイドには、現在提供されるモジュールチャネルはアタッチ時に自動で主導権を取得するDefault Activeであり、通常は手動制御が不要という注意書きもあります。このドキュメントを見つけたからといって、すべてのWebhookハンドラーに主導権の取得・解放を追加する必要はありません。

まず実際の連携構成を調べます。

1. リクエストに対応するLINE公式アカウント、受信チャネル、連携ベンダーを特定する。
2. モジュールがアタッチされているかを連携担当者に確認する。
3. 変換後のキューレコードだけでなく、安全に保管したイベント原本を確認する。
4. パース前後で mode と replyToken の有無を比較する。
5. 想定外の主導権は担当のモジュール提供者に調査を依頼し、根拠なくトークンやWebhook URLを変更しない。

通常のログにチャネルの認証情報や返信トークンを残さないでください。診断にはトークンの値ではなく、有無だけを記録できます。

期限切れを疑う前に、欠落の原因を分ける

トークンがない場合、期限切れの場合、送信結果が分からない場合では、対応が異なります。

観測した状態	調査対象	避ける対応
原本が standby でトークンなし	主導権と想定する返信担当	トークンの自作や自動プッシュ送信
原本にはトークンがあるがワーカーにはない	パース、シリアライズ、キューのマッピング	データ変換の不具合を主導権変更で直そうとする
activeイベントにトークンがない	イベント定義と連携の前提	すべてのWebhookは返信可能だと考える
トークンはあるが返信に失敗	実際のAPIレスポンス、使用履歴、処理遅延	すべてをstandbyの問題と判断する
送信リクエストがタイムアウト	受付結果が不明かどうか	別の操作で同じ回答を即座に送る

受信したトークンを遅れて使用した、または複数回使用した場合は、LINE返信トークンのトラブルシューティングを参照してください。もともとトークンが付与されなかったイベントとは、別の復旧経路です。

イベントの観測と返信の権限を分ける

受信処理では、通常どおり署名を検証し、必要なイベントを永続化する設計を推奨します。受信と再送についてはLINEのWebhook受信ガイドを確認してください。再送で主導権を得ようとして、有効なstandby配信を意図的に失敗させないでください。

受信後は、送信タスクを作成する前に分類します。

• **Standby：**許可された内部処理に必要なデータだけを保持し、顧客向け送信を抑止したことを記録する。
• **Activeかつ返信可能：**1つの業務処理が返信の必要性を判断し、重複防止と送信結果を管理する。
• **仕様を確認できない：**自動送信を保留し、調査を依頼する。暗黙にactiveへ変換しない。

これらはアプリケーションの判断であり、LINEの追加フィールドやAPIステータスではありません。イベントで観測したmodeを保持してください。後続イベントがactiveでも、古いstandbyイベントをactiveに書き換えたり、過去のメッセージへの新たな返信許可と見なしたりしてはいけません。

遅延処理を送信する前には、連携側の現在の返信担当方針と整合させます。担当が不明なら確認まで保留し、別の送信方法を選ばないでください。イベントの重複排除だけでは、どのツールが答えるべきかは決まりません。

受け入れテストには、standbyで送信しないこと、activeで返信可能なイベント、パーサーによるトークン欠落、重複配信、待機中に返信担当が不明になるケースを含めてください。これは提案するテスト項目であり、本番での実測結果ではありません。

UnifyPortの役割と対象外の範囲

UnifyPortの非公式インターフェースは、別のアカウント接続経路です。LINE認証リファレンスにはQRコードログインと、QR URL・PINの非同期通知が記載されています。モジュールのアタッチ処理ではなく、LINE公式アカウントの主導権を取得するものでもありません。

この独立した経路では、文書化された正規化イベント message.received を使用します。Webhook配信仕様は、signing_secret 設定時の署名検証を定義しています。LINEネイティブの mode や replyToken の前提をこのスキーマに持ち込まないでください。UnifyPortからの送信は、公式アカウントで欠落したトークンの復旧ではありません。

送信元がLINE公式アカウントである必要がある場合は、公式Messaging APIと担当のモジュール提供者による対応を続けてください。別の接続アカウントへの切り替えは、standby時の自動代替策ではありません。

よくある質問

standbyはWebhookがオフラインという意味ですか？

いいえ。イベントは正常に届いている可能性があります。standbyは受信チャネルの主導権を示し、サーバーの接続状態を示すものではありません。

replyTokenがなければプッシュで送れますか？

standbyの代替策としては使わないでください。LINEは待機中の受信側に送信を控えるよう求めています。問題は送信メソッドだけでなく、返信担当です。

activeなら必ずreplyTokenがありますか？

いいえ。対象のイベント種別が返信に対応しているかを確認してください。activeだけですべてのイベントが返信可能になるわけではありません。

すべてのLINEボットにChat Control呼び出しが必要ですか？

いいえ。Moduleには所定の申請が必要で、現在のガイドはDefault Activeの動作も説明しています。実際の構成を確認してから制御を追加してください。

次のステップと出典

安全に保管したイベントを公式モジュールチャネルガイドと比較し、返信を担当するコンポーネントを明文化してください。独立したアカウント接続を検討する場合は、UnifyPortのLINE認証仕様を確認できます。

公式資料の確認日：2026-10-27。

• LINE：モジュールチャネルからMessaging APIを利用する
• LINE：Chat Control
• LINE：Messaging APIリファレンス
• LINE：メッセージを受信する