WhatsAppのチャット消去と削除：Webhookで状態を正しく同期する

WhatsAppでチャットの内容を消去すると、ローカル履歴が消去されてもチャット自体は残ります。チャットの削除は、それとは別の一覧操作です。UnifyPortのconversation.clearedとconversation.deletedは、接続中のメッセージングアカウントにおけるこれらの変更を通知します。どちらも「全員のメッセージが削除された」という意味ではありません。共有受信箱では、履歴の表示とチャットの表示を分け、自社で保存したコピーに明確なポリシーを適用します。

要点

• アカウント側のローカルな変更通知であり、顧客のメッセージを削除する命令ではありません。
• 対象はdata.conversation.idで識別します。最上位のidはイベントの識別子です。
• delete_mediaはローカルメディアの削除を示し、自社ストレージやCRMの削除完了を示しません。
• 過去の内容を再表示しないことと、新しいメッセージを受け付けることは別の判断です。

内容の消去、チャットの削除、メッセージの取り消しを区別する

WhatsAppのチャット消去ガイドでは、消去してもチャット一覧からは消えず、グループからも退出しないと説明しています。チャット削除ガイドでは削除を別の操作として扱い、グループチャットの削除前には退出が必要としています。どちらの操作も、連携先の全業務データを消す命令に読み替えないでください。

受信イベント	文書化された範囲	受信箱での推奨処理
conversation.cleared	接続アカウントのローカル履歴を消去。相手側の会話とグループ所属は不変	会話の枠を残し、対象の履歴表示をポリシーに従って抑制
conversation.deleted	接続アカウントがローカルで会話を削除	通常のミラー一覧から外し、許可された照合用メタデータだけを保持
message.deleted	個別のメッセージが削除または取り消された	会話全体ではなく対象メッセージを特定
conversation.updated	ローカルのチャット設定が変更された	提供された設定を更新し、履歴削除を推測しない

右列はアプリケーション設計の提案であり、UnifyPortの自動処理ではありません。送信済みメッセージを取り消したい場合は、編集・取り消し・ローカル非表示の違いを参照してください。会話削除イベントは、取り消しリクエストの受領証ではありません。

メッセージではなく会話イベントとして解析する

消去イベントのリファレンスと削除イベントのリファレンスには、会話の対象とdelete_mediaがあります。影響を受けたメッセージIDの一覧や、履歴の厳密な境界は提供されていません。

次は文書化されたフィールドと架空の識別子を使った例です。実際に取得した通信ではありません。

{
  "id": "evt_c4d0b7a2e5",
  "type": "conversation.cleared",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-10-29T08:15:00Z",
  "data": {
    "conversation": {
      "id": "8600000000000@s.whatsapp.net",
      "type": "user"
    },
    "delete_media": true,
    "event": { "kind": "conversation_cleared" }
  }
}

検索キーにはワークスペース、プロバイダー、account_id、data.conversation.idを組み合わせます。受信した識別子をそのまま保持し、電話番号から組み立てたり、同じ表示名だけで会話を統合したりしないでください。この分岐は会話イベントなので、data.message.idを必須にしません。

プロバイダー別イベント表では、これらは現在whatsappに対応しています。別プロバイダーのwhatsapp-protocolやLINEを含む全チャネルに対応するわけではありません。LINEとWhatsAppを同じ受信箱で扱う場合も、共通スキーマから機能の同一性を推測しないことが重要です。表はパーサーの対応状況であり、すべての上流アカウントや環境でイベントが発生する保証ではありません。

アプリケーション側の状態を三つに分ける

まず製品としての約束を決めます。ミラー型受信箱はアカウント側の履歴を非表示にできますが、別のルールで管理する案件記録には異なる保存要件があり得ます。ネイティブ操作を黙って無視したり、すべての業務記録の削除と解釈したりせず、担当者に違いを説明してください。

自社のストレージでは、次を独立して管理します。

1. 一覧の表示状態：ミラー一覧に会話を表示するか。
2. 履歴の表示・清掃状態：過去のどの内容を抑制し、どの自社コピーが清掃待ちか。
3. 今後のメッセージの受け入れ：古い履歴を戻さず、どの条件で会話を再表示するか。

これはローカル設計の概念であり、新しいWebhookフィールドではありません。会話の識別情報をすべて消すのではなく、必要最小限のスコープ付きマーカーと清掃判断を残します。そうしないと、遅れて届く履歴バッチが表示内容を再作成しかねません。

Webhook配信仕様に従ってsigning_secretを設定し、X-Device-Timestamp、ピリオド、未加工のリクエスト本文を連結した内容のHMAC-SHA256を検証します。時刻の鮮度も確認してください。通常イベントの重複排除、表示変更、清掃タスクの登録を一つのローカルトランザクションで行い、永続化後に2xxを返します。外部システムすべての完了を待つ必要はありません。

履歴の再読み込みで判断を取り消さない

配信順序は保証されません。occurred_atはイベントの時刻ですが、消去・削除仕様はそれを全対象メッセージの厳密な境界とは定義していません。HTTPの到着時刻も、内容が新しいことの証明にはなりません。

後から届く入力	抑制中の推奨対応
同じ消去・削除イベントの再送	判断を維持し、未完了の清掃を継続
抑制済み内容を含む履歴バッチ	自動で再表示しない
抑制済みメッセージIDのライブイベント	抑制を維持
新しく見えるが消去との関係が不明なメッセージ	自動返信を保留し、範囲を確認
新しい活動だと確認できた入力	明示したルールで再表示し、古い履歴は戻さない

既知のメッセージIDは保存済み内容を守れますが、一度も受信していない古いメッセージは識別できません。信頼できる境界がなければ、明示的な確認か保守的な抑制を選びます。新しいイベントIDだけで内容の新しさを判定しないでください。

WhatsApp履歴のオンデマンド読み込みを提供する場合は、マージ処理にも同じルールを組み込みます。履歴は子メッセージ単位でマージし、最上位イベントIDだけの重複排除で正当なチャンクを捨てないようにします。履歴読み込みは消去判断を暗黙にリセットする操作ではありません。

メディア清掃と受け入れテスト

delete_media=trueはローカルメディアも消去されたことを示します。ダウンロードした添付、検索索引、AIコンテキスト、転送コピーの削除完了は示しません。falseも無期限保存の許可ではありません。開示した保存・アクセス方針を適用し、清掃完了とWebhook応答を別々に追跡します。

管理下のアカウントで次をテストしてください。

• 消去後も会話の枠は残るが、抑制対象は検索されない。
• 削除後は一覧から外れ、連絡先のブロックやグループ退出を自動要求しない。
• 古い履歴や重複イベントで内容が再表示されない。
• 確認済みの新しい活動で再表示しても、旧履歴は戻らない。
• メディア清掃が失敗したら、完全削除ではなく清掃待ちと表示する。

これらは提案するテストであり、実施結果ではありません。UnifyPortは非公式インターフェースであり、再配信の保証やメッセージ履歴を返すREST読み取りAPIはありません。イベントを受信していないことは、ローカル変更がなかった証明にはなりません。

よくある質問

conversation.deletedは相手のメッセージも削除しますか？

いいえ。接続アカウント側のローカル削除であり、全員向けの削除ではありません。

conversation.clearedはグループ退出を意味しますか？

いいえ。イベント仕様では所属は変わりません。

このイベントを使ってチャット消去APIのボタンを作れますか？

イベントは観測結果です。消去・削除を要求するAPIを示すものではないため、イベント名からエンドポイントを作らないでください。

次のステップと出典

conversation.clearedの仕様を読み、表示・保存・再表示ルールを決めてから破壊的な清掃処理につなげてください。

確認日：2026-10-29。

• WhatsApp：チャットの消去
• WhatsApp：チャットの削除
• UnifyPort：conversation.deleted
• UnifyPort：Webhook配信