LINEの送信取消を処理する：削除済みメッセージを受信トレイに復活させない設計

LINEユーザーがメッセージの送信を取り消したら、サポート画面から内容を除去し、後続処理での利用も停止します。LINEの公式Webhookガイドは、表示の取り消しと保存済み内容の削除を推奨しています。UnifyPortでは、正規化された message.deleted を受けて削除マーカーを永続化し、再試行可能なクリーンアップを実行します。受信トレイの行を消すだけでは、遅延イベントによる復活や検索・AI内のコピーを防げません。

要点

• 送信取消の通知を受け取ることと、APIで取消を要求することは別です。
• イベントIDで重複を排除し、対象メッセージは data.message.id とアカウントのスコープで特定します。
• 最小限の削除マーカーで、遅れて届く受信・編集からの復活を防ぎます。
• Webhookの受領確認と、下流システムの削除完了を分けて管理します。

LINEの送信取消と保存済みデータ

LINEのメッセージ受信ガイドでは、ユーザーが送信を取り消すとunsendイベントがサーバーへ送られると説明されています。ユーザーの意図を尊重し、対象メッセージが今後閲覧・利用されないよう、管理画面からの除去やストレージからの削除を推奨しています。

これは公式の推奨事項です。以下の削除マーカー、トランザクショナルoutbox、受け入れテストはアプリケーション設計の提案であり、LINEの組み込み機能や法定保存期間の判断ではありません。

編集は内容の置換、送信取消は内容の利用停止です。LINE message.updatedの反映手順を併用する場合も、新しいテキストを書き込む前に削除状態を確認してください。改訂履歴が、担当者や検索処理から読める隠れたコピーになってはいけません。

イベント契約を混同しない

LINE公式Messaging APIの受信エンドポイントとUnifyPortの受信エンドポイントでは、ペイロードと検証方式が異なります。独立した変換処理なしに、LINEのネイティブペイロードを正規化イベント用ハンドラーへ渡さないでください。

UnifyPortの標準イベントリファレンスでは、message.deleted はメッセージの削除または取消を表します。messageオブジェクト内で保証されるのは data.message.id のみで、テキストとメディアは除去されます。プロバイダー別イベント表はLINE、Telegram、WhatsAppでのマッピングを示していますが、すべてのアカウントや環境で各イベントが発生する保証ではありません。

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

{
  "id": "evt_6d91a2c8",
  "type": "message.deleted",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-09-23T08:15:00Z",
  "data": {
    "conversation": { "id": "c8f2a4d91e", "type": "group" },
    "message": { "id": "551842037194" },
    "event": { "kind": "message_deleted" }
  }
}

最上位の id はイベント、data.message.id は削除されたメッセージを識別します。前者でメッセージを検索したり、テキストの欠落を「空文字への編集」と解釈したりしないでください。

クリーンアップの前に削除を確定する

subscribed_events に message.deleted を追加し、必要な受信・編集イベントも維持します。signing_secret を設定し、配信契約に従って、タイムスタンプ、ドット、元のリクエストボディに対するHMAC-SHA256を検証してください。受け入れ前にはタイムスタンプの鮮度も確認します。リプレイ対策の解説で、署名検証と永続的な重複排除の役割の違いを確認できます。

認証とペイロード検証の後は、次の順で処理します。

1. 正しいワークスペース、プロバイダー、メッセージングアカウント内で対象を特定します。会話IDがあればメッセージIDと併用します。会話情報がなければ、既存の曖昧さのないアカウント内マッピングだけを使い、会話をまたいで推測しません。未解決の対象は隔離して確認します。
2. 同じトランザクションで、イベントの重複排除、最小限の削除マーカーの作成・維持、稼働中データの除去、クリーンアップジョブの登録を行います。同一対象への受信・編集書き込みと直列化します。
3. 永続的な受け入れ後に2xxを返します。下流の削除はワーカーが独立して再試行します。
4. すべての受信・編集書き込みでマーカーを確認し、遅延イベントによる内容の再登録やAIジョブの起動を止めます。

以下はアプリケーション側の推奨状態ルールで、APIフィールドではありません。

保存状態	到着イベント	処理
元のメッセージなし	削除	内容なしのマーカーを保存し、元データを待たない
有効な内容あり	削除	内容を非表示にし、クリーンアップを登録
削除マーカーあり	受信・編集	内容を復活させない
削除マーカーあり	削除の再通知	状態を維持し、未完了の削除を継続

到着順や「最新タイムスタンプ優先」だけに依存しないでください。UnifyPortは配信順を保証しません。同じメッセージIDについて削除を有効なまま保つことが、この設計の明示的なルールです。

受信トレイ以外のコピーを追跡する

元のメッセージと派生データの対応をアプリケーション内に保持します。以下は点検すべき対象であり、UnifyPortが自動削除する範囲ではありません。

コピー・ジョブ	推奨処理
本文・プレビュー	内容の除去とキャッシュ無効化
ダウンロード済み添付ファイル	管理下のコピーとサムネイルを削除
検索・ベクトル索引	エントリーを除去し、未完了の間は検索利用を禁止
AIコンテキスト・要約・返信待ちジョブ	元データを除外し、要約を無効化、依存ジョブを中止または確認
CRM・チームチャットへの転送	対応可能なら削除・マスキングし、未解決のコピーを追跡
生イベントログ・デッドレターキュー・バックアップ	アクセスと保存ポリシーを適用し、稼働画面への復元を防止

ワーカーは検索前、生成テキストの公開前、索引の再構築時に削除状態を再確認します。可能なら公開処理も同じメッセージ単位の制御と協調させます。すでに外部システムへ渡した処理は取り消せない場合があります。完全消去を約束せず、その境界を記録してください。

マーカーには、スコープ付き識別子と清理状態だけを残し、取り消された本文を保持しない設計にできます。保存期間はリプレイ、復元、プライバシー要件と合わせて決めます。古いイベントを再処理できるうちにマーカーを消すと、復活の問題が再発します。

受け入れテストと制約

顧客データではなく管理されたテストメッセージを使ってください。以下は提案するテストで、実施結果ではありません。

• 元のメッセージより先に削除が到着しても、後続の受信で内容が表示されない。
• 編集や索引処理の最中に削除しても、内容が再公開されない。
• 削除が再配信されても副作用は重複せず、未完了の清掃は再試行される。
• 下流の削除に失敗しても、受信トレイでは非表示となり、未完了状態が明示される。
• バックアップ復元時は、検索や受信トレイを公開する前に削除マーカーを適用する。

UnifyPortは非公式インターフェースと正規化イベントを提供しますが、CRMやAIの保存内容を自動削除しません。RESTのメッセージ履歴取得APIや、取り逃したイベントの再配信保証もありません。削除イベントを受信していないことは、送信取消がなかった証明にはなりません。LINE公式アカウントのネイティブ契約が必要な製品では、公式経路を優先してください。

FAQ

message.deletedは他人のメッセージを取り消す要求ですか？

いいえ。観測された削除・取消の通知です。自分の保存コピーを清理することと、プラットフォームへの操作要求は別です。

削除ペイロードから元の本文を復元できますか？

できません。文書化された保証は対象IDであり、削除された文字やメディアではありません。取消処理を復元機能として設計しないでください。

HTTP 200はすべてのコピーの削除完了を意味しますか？

いいえ。配信の受領確認です。下流の完了と失敗はアプリケーションで別途管理します。

次のステップと出典

プロバイダー別Webhookイベント表を確認し、AI処理を有効にする前に「元メッセージより先に削除」のテストを追加してください。

確認日：2026-09-23。

• LINE：メッセージ受信と送信取消イベント
• LINE：Messaging APIリファレンス
• UnifyPort：標準イベント
• UnifyPort：配信と署名検証