配信中にチャットボットが2回応答する場合の対処法

まず重複の種類を特定する

同じ応答が2回続くのは、1つの不具合ではなく少なくとも2つの異なる問題です。1つ目は、ボットが1つのイベントを2回受け取ったケース。2つ目は、イベントは1つしか来ていないのに、ボットが2回送信したケース。対処法が異なるため、コードの修正から始めず、まずログから確認してください。

ボットのログを開き、重複が発生した時点を探します。次に2つのフィールドに注目します：イベントIDと受信時刻です。

• 同じevent_id（またはmessage_id、notification_id — 名称はプラットフォームによって異なります）を持つ2つのリクエストがミリ秒差で届いている場合、それは同じイベントの再配信です。重複排除を探してください。
• 異なるIDを持つ2つのリクエストの場合、チャンネルには実際に2つのハンドラが購読されています。2つ目の購読を探してください。

ログがまったくない場合は、プラットフォームのパネルから始めてください。そこにはチャンネルのイベントを購読しているものが表示されます。

パネルでの二重購読の見え方

プラットフォームは「ボットが2回接続されている」と1行で表示してくれません。兆候はさまざまなセクションに散らばっています。

Twitch

アカウント設定のConnectionsセクションを確認してください。接続済みアプリの一覧があります。同じボットがチャンネルのアプリとしても、あなたの個人アカウントのアプリとしても認証されている可能性があります。さらにEventSub購読は別に存在します：パネルで連携を解除した後も、アプリがchannel.chat.messageの有効な購読を保持していることがあります。ローカルで起動した2つ目のボットインスタンスも、稼働中のものと同様にイベントを受信します。

YouTube

ここではボット自体よりもチャットへのアクセスが原因であることが多いです：ボットが配信にモデレーターとしても、別の参加アカウントとしても接続されています。モデレーター一覧とチャンネルの認証済みアプリ一覧を確認してください。別途、ボットが複数のGoogle Cloudプロジェクトを通じて動作している場合、キーが2つの異なる経路を通る可能性があります。

Discord

最も分かりやすいケース：同じトークンを持つ2つのアプリが1つのサーバーに存在する場合です。どちらもチャンネルのメッセージを認識し、どちらも応答します。サーバー上のボット一覧を確認し、同じ名前の2つ目のWebhookがチャンネルに接続されていないことを確かめてください。

この方法の欠点は、ボットだけでなくチャンネルのパネルへのアクセスも必要になることです。チャンネルを複数人で運営している場合、2つ目のインスタンスを誰かが立ち上げていて、あなたがそれを知らない可能性があります。

Webhookの再送：イベントが2回届く理由

外部サービスはWebhookを配信し、確認応答を待ちます。所定の時間内に応答がなければ、もう一度送信します。2回目のリクエストは同じイベントを含みますが、ボットはそれを新しいものとして認識し、再び応答します。これはサーバーが多少なりとも遅延するたびに発生します：負荷が高いほど頻繁に起こります。

対処法はボット側での重複排除です。同じイベントのすべてのコピーで同一であり、異なるイベントでは一意になるキーが必要です。キーはリクエストボディまたはヘッダーから取得します — APIによって異なりますが、仕組みは同じです。

重複排除キーの例

新しいドネーションに関するWebhookを想像してください。ボディにはidフィールドを持つオブジェクトが含まれます — 再配信時にも変わらない一意のトランザクション番号です。ロジックは次のとおりです：

1. リクエストを受信したら、ボディからidを取り出します。
2. ストレージ（Redis、データベースのテーブル）で、過去例えば24時間以内にそれが出現したか確認します。
3. 出現していた場合 — サービスに「受信済み」と応答し、チャットには何も送信しません。
4. 出現していない場合 — 記録して通常どおり処理します。

キーは自分で生成したものではなく、イベントから取得したものでなければなりません：自分で生成すると、同じイベントの2回の配信で異なるキーになり、重複排除が機能しません。一部のプラットフォームは配信IDを含むヘッダーを提供しています — その場合はそれを使用する方が信頼性が高いです。このアプローチの欠点は、ストレージとクリーンアップポリシーが必要なことです。そうでなければキーのデータベースが際限なく増え続けます。

重複が2つの異なるソースから来た場合

別のケースは、イベントが繰り返されるのではなく、実際に2つの場所から届く場合です。典型的な例：ボットがチャット内と、ブリッジ経由のプラットフォーム間転送の両方でコマンドに応答する。または、自動応答が同じフレーズに反応する2つのトリガーに設定されている。

このような重複はログでWebhookの再送と区別できます：リクエストのソースが異なり（異なるプラットフォーム、異なるハンドラ）、意味的には1つのイベントです。トリガーの重複を探し、1つを無効にしてください。ブリッジの場合は、ボット自身のメッセージを転送し直さないでください。

配信前のチェック

1. テストコマンドを送信し、応答がいくつ返ってくるか確認します。
2. 1つを除いてすべての連携を無効にし、繰り返します。
3. 重複が再発するまで1つずつ有効にしていきます — これで原因を特定できます。
4. ログで両方の応答のイベントIDを照合します：同じなら再配信、異なれば2つ目の購読です。

原因が見つからない場合は、問題のあるイベントの自動応答を無効にし、ログと再発時刻を添えてサービスのサポートに連絡してください。待っている間は手動でチャットを運営しましょう：一晩自動化を失う方が、配信を同じフレーズで埋め尽くすよりましです。