比較 October 12, 2026

送信ミスは編集・送信取消・ローカル非表示のどれで直す？

接続済みアカウントから誤送信した場合、まず変更する範囲を決めます。編集は送信済みテキストの置換、送信取消は会話の全参加者を対象とした取り消し要求、ローカル非表示は自分のアプリの表示変更です。UnifyPortのドキュメントではWhatsAppのテキスト編集と、Telegram・WhatsApp・LINEの送信取消に対応しています。いずれもアカウント自身が送ったメッセージが対象です。編集・削除イベントを受信できても、同じ操作を実行できるとは限りません。

要点

文面の訂正、自己送信メッセージの取消、業務画面の表示整理を区別します。
アカウント・会話・メッセージの組を固定し、確認後に「最新メッセージ」を選び直さないでください。
操作の対応状況とイベントの受信対応は別に確認します。
APIの結果、webhookでの観測、下流コピーの削除は、それぞれ別の証拠です。

編集・送信取消・非表示の比較

サポート担当が予約時刻を誤って送った、という仮の例で考えます。本文の訂正と、担当者の画面から消すことは同じではありません。

目的	適切な操作	それだけでは確認できないこと
送信済みの文字を訂正	メッセージ編集	受信者が原文を見ていないこと
自分の送信を取り消す	メッセージ取消	保存・転送された全コピーの消去
自分の受信箱の行を隠す	アプリ側の表示制御	相手のチャットへの反映
取り消しを観測して反映	`message.deleted` の処理	新たな取消要求の実行

WhatsAppの公式削除ガイドは、削除前に相手がメッセージを見る可能性や、iOSの「写真」に保存したメディアが残る可能性を説明しています。「どこからも完全消去」と表示したり、取消を機密情報が露出していない証明にしたりしないでください。

ここでいうローカル非表示はアプリ設計であり、公開済みのUnifyPort単一メッセージ削除エンドポイントではありません。conversation.deleted と conversation.cleared もローカルな会話の変化を示すイベントで、全員に対する単一メッセージの取消とは異なります。

イベントではなく操作の対応表を確認する

現在のプロバイダー別操作対応表は次のように定義されています。

プロバイダー	送信済みテキストの編集	自己送信メッセージの取消
`whatsapp`	対応	対応
`telegram`	非対応	対応
`line`	非対応	対応
`twitter`、`zalo`、`tiktok`、`whatsapp-protocol`	非対応	非対応

これはアダプターの対応状況であり、すべての要求が上流サービスやアカウントの条件を満たす保証ではありません。未実装の組み合わせは 501 unsupported_by_provider を返します。

特にLINE連携では、編集イベントの処理ガイドが扱う message.updated の受信と、送信済みメッセージの編集要求を混同しないでください。イベントを解析できるだけで「編集」ボタンを有効にしてはいけません。

また、UnifyPortの取消契約は一部のネイティブな管理機能より限定的で、接続アカウント自身の送信だけが対象です。担当者がグループ管理者でも、他のメンバーのメッセージを取り消せるとは解釈しないでください。

訂正前に対象を固定する

保存済みの message.received から account_id、data.conversation.id、data.message.id を取得します。このイベントは受信・送信の両方を表すため、data.message.direction と所有関係を確認してください。最上位のイベント id はメッセージIDではありません。

推奨するアプリ側の確認は次のとおりです。

担当者に対象メッセージングアカウントと会話への操作権限があるか確認する。
確認画面に対象ID、現在の内容、操作範囲を固定して表示する。
プロバイダー対応と自己送信を確認し、編集はテキストに限定する。
同じ対象への訂正を直列化し、担当者同士の上書きを防ぐ。
操作と結果の記録を、表示中のメッセージ本文から分離する。

以下は架空の識別子を使ったJSONリクエスト本文の例です。実際の顧客データではありません。サーバーから X-Api-Key で認証し、ブラウザーコードにはキーを含めないでください。

POST /v1/messages/edit の content は差分ではなく、置換後の全文です。

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C",
  "content": "訂正：予約時刻は15:00です。"
}

POST /v1/messages/revoke では、同じ対象を指定し、置換本文は送りません。

{
  "account_id": "acc_example",
  "conversation_id": "8600000000000@s.whatsapp.net",
  "message_id": "3EB0A185AAC596E2BB602C"
}

取消リファレンスでは sender_id の既定値はアカウント自身で、通常は省略できます。別の送信者を指定しても権限は広がりません。全チャネル共通の訂正期限を推測したり、別APIの権限を当てはめたりしないでください。

要求結果とコピーの削除を分離する

両エンドポイントの成功例は data.ok: true を含みます。実際の結果を保存しますが、全受信者や下流システムから古い内容が消えたという意味に拡張しないでください。

観測	推奨する対応
`501 unsupported_by_provider`	その操作を無効にし、同じ要求を繰り返さない
`edit_message_failed` / `revoke_message_failed`	エラーと対象の状況を調査する
HTTPタイムアウト・応答消失	結果不明を維持し、再要求前に調査する
対応する `message.updated` / `message.deleted`	対象メッセージに冪等に反映する
対応イベントが来ない	不在だけで成功・失敗を断定しない

リクエスト追跡ガイドに従って request_id を保存します。これは冪等トークンでも、webhookとの関連付けを保証するキーでもありません。

イベント受信は配信契約に従います。signing_secret を設定し、タイムスタンプと生の本文に対するHMAC-SHA256、時刻の鮮度を検証し、永続化後に応答します。順序は保証されません。検索・CRM・AI内の自社コピーは別途清掃が必要です。取消内容の削除ガイドでその境界を確認できます。

FAQ

編集エンドポイントで添付ファイルも変更できますか？

ドキュメント上はテキストメッセージに限定されています。content をメディア置換フィールドとして使わないでください。

受信箱で隠すと相手からも消えますか？

いいえ。ローカル表示とサービス側の取消は別操作です。画面で範囲を明示してください。

message.deleted対応なら毎回コールバックが来ますか？

いいえ。イベント対応表は、すべてのアカウントや環境から毎回イベントが発生する保証ではありません。HTTP結果と観測状態を分けて保持します。

次のステップと出典

メッセージ取消リファレンスを確認し、許可されたテスト会話で選択・確認フローを検証してください。UnifyPortは非公式インターフェースであり、ネイティブのルールを置き換えたり、外部コピーの消去を保証したりするものではありません。

確認日：2026-10-12。

UnifyPort API

メッセージ連携を安定したプロダクトパイプラインへ。

まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。

API Key を取得 API リファレンスを見る