WhatsAppのミュートとブロック：共有受信箱での使い分け
WhatsAppの通知を減らしたいなら会話をミュートし、特定の相手からアカウントへのメッセージを止めたいなら連絡先のブロックを検討します。どちらも、アプリ内部の「自動返信を一時停止」や「問い合わせを解決済みにする」とは別の操作です。共有受信箱では、通知を減らすつもりで顧客との連絡を切ったり、ミュート後もAIが返信し続けたりしないよう、操作を分けて設計しましょう。
3つの操作が変えるもの
WhatsAppの通知ガイドは、ミュートをチャット通知の設定として扱っています。ブロックのガイドでは、ブロックした相手からの通話やメッセージを受け取れなくなると説明しています。また、解除してもブロック中に送られたメッセージは届きません。ブロックは、後で取り出せるメッセージの保留機能ではありません。
| 目的 | 適した操作 | 意味しないこと |
|---|---|---|
| チャット通知を減らす | 会話をミュート | 問い合わせの解決、webhook受信の停止 |
| 特定の相手からの連絡を止める | 権限のある担当者が判断してブロック | 保存済み内容の削除、解除後の未受信メッセージの復元 |
| AIの返信を止める | アプリ側の自動化一時停止 | プロバイダーの設定によるローカルジョブの取り消し |
| 後で対応する案件を残す | ローカルの案件状態、必要に応じて未読設定 | 未読とミュートが同じ状態であること |
後半の2行はアプリ設計の提案であり、WhatsApp APIの追加機能ではありません。既読状態についてはWhatsAppの既読・未読同期ガイドを参照してください。通知設定、開封確認、担当者の割り当ては別々の判断です。
UnifyPortで利用する操作
UnifyPortの非公式インターフェースでは、会話操作と連絡先操作を分けています。以下はUnifyPortのAPI仕様であり、Meta Cloud APIのルートではありません。
| 操作 | 入力と仕様上の境界 | リファレンス |
|---|---|---|
| ミュート | conversation_idと、秒単位のdurationまたは未来のRFC3339時刻mute_until。両方は指定不可 | 会話のミュート |
| ミュート解除 | conversation_id | ミュート解除 |
| ブロック・解除 | contact_idにdigits@lid形式の正規のWhatsApp LID | ブロック・ブロック解除 |
| ブロック一覧の確認 | 応答はdata.blocklistと一覧のフィンガープリントdata.dhash | ブロックリスト取得 |
duration: 0は無期限ミュートです。「ミュートをオフにする」という意味ではありません。解除には専用の操作を使います。
UIに操作を表示する前に、プロバイダー別対応表を確認してください。現在の仕様では、ブロック、解除、ブロックリスト取得はWhatsAppに対応しています。ミュートはWhatsAppが対応、LINEは部分対応で、ミュート解除もLINEに対応しています。LINEとWhatsAppを同じ受信箱で扱う場合も、共通ルートだから同一の動作になるとは限りません。未対応の組み合わせは501 unsupported_by_providerを返します。
ブロック用の識別子を作らない
WhatsAppのブロックと解除では、電話番号や@s.whatsapp.netのJIDを正規LIDの代わりには使えません。文書化された連絡先フローで実際の識別子を取得してください。電話番号に@lidを付けても、同じ人を指すことにはなりません。
連絡先の応答には、それぞれ異なるid、provider_user_id、conversation_idが含まれる場合があります。意味を混同せず保持しましょう。連絡先APIとvCardのガイドでは、アドレス帳の変更と連絡先情報の送信も別操作であることを説明しています。本記事は、ブロックの前提として相手を連絡先に追加するよう勧めるものではありません。
APIを呼ぶ前に受信箱の判断を設計する
仮にサポートキューへ同じ内容が繰り返し届いているとします。内容を引き続き確認する必要があるなら、ミュートで通知を減らし、ローカルの一時停止で不適切なAI返信を防ぐ設計が考えられます。権限のある担当者がブロックを決めた場合は、別の明示的な変更として扱います。
推奨するアプリ側の手順は次のとおりです。
- 操作名を分ける。 「通知をミュート」「連絡先をブロック」「自動返信を一時停止」を別々に表示し、選択したメッセージングアカウントと対象に限定します。
- 対象を確認する。 ブロックには、そのアカウントと関連付いた確認済みの正規LIDを使います。特定できなければ推測せず、人による確認に回します。
- 意図をローカルに記録する。 操作者、理由、対象、要求した操作を保存します。これらはアプリの監査記録であり、APIリクエストへ追加するフィールドではありません。
- 結果を確認する。 文書化された変更応答には
data.okがあります。ボタンを押しただけで成功表示にせず、機密情報を除いたエラーとrequest_idを保持します。 - 不明な結果を照合する。 ブロックや解除がタイムアウトしたら、次の変更を送る前にブロックリストを取得します。
dhashは一覧の変化を検出できますが、誰がなぜ変更したかは示しません。 - 待機中の自動化を別に扱う。 判断前のジョブはデータベースに残っている可能性があります。送信ワーカーがローカルの停止方針を確認するようにし、プロバイダー設定を自分のキューの取り消し機構にしないでください。
ミュートの変更については、イベントリファレンスにconversation.updatedとmuted、mute_untilなどの設定が記載されています。届いたイベントは状態の観測として使い、すべての操作に確認イベントが届くとは約束しないでください。公開カタログに連絡先ブロックのイベントは記載されていないため、架空のイベントを前提にせず、ブロックリストを利用します。
受け入れ確認と制約
自分で管理するアカウントでテストします。失敗と適用済みをUIが区別すること、ミュート解除がブロック解除を呼ばないこと、ブロック解除だけで古い返信ジョブを再開しないことを確認してください。識別子の拒否と、タイムアウトで結果が不明な場合も対象です。これは推奨テストであり、実施結果ではありません。
ミュートをwebhookの流量制御には使わないでください。ミュート操作は会話状態を変更するもので、イベント配信を停止する仕様ではありません。また、ブロックによる保存済み内容の削除、共通グループの管理、CRM内の処理取り消しも本記事では保証しません。別々に定義する必要があります。
ネイティブアプリ内での手動操作で足りる場合は、その操作を直接使えます。公式のビジネス連携が必要なら、その仕様を別途評価し、UnifyPortのルートをWhatsApp公式エンドポイントと混同しないでください。
FAQ
ミュートすると自動返信も止まりますか？
そうとは限りません。返信ワーカーが確認する明示的なローカル停止状態を実装してください。ミュートはジョブ取り消し操作として文書化されていません。
電話番号のJIDでブロックできますか？
UnifyPortのWhatsAppブロック操作ではできません。電話番号や@s.whatsapp.netではなく、正規のdigits@lidを使います。
解除するとブロック中のメッセージが届きますか？
届きません。WhatsApp公式ヘルプの説明どおり、ブロックを復元可能なメッセージ保留機能として提供しないでください。
dhashが変われば操作成功ですか？
それだけでは判断できません。一覧全体のフィンガープリントなので、対象の連絡先が存在するかを確認し、操作結果も別に保存します。
次のステップと出典
連絡先ブロックのリファレンスを読み、識別子の対応を確認してから共有受信箱の操作を有効にしましょう。
確認日：2026-09-25。
メッセージ連携を安定したプロダクトパイプラインへ。
まずは 1 つの API で送信を始め、標準イベントですべての inbound メッセージを業務システムへ戻しましょう。