WhatsApp 音声メッセージと通話：サポートでの使い分け

顧客が後から聞いて返信できる場合は WhatsApp の音声メッセージを選びます。双方に時間があり、その場で確認が必要な場合はリアルタイムの音声通話を選びます。録音済みのメッセージも会話も音声を伝えますが、サポートアプリではリクエスト、識別子、完了の判断を分ける必要があります。

本記事は、UnifyPort の音声メッセージと、非公式インターフェースを通じてプライベートベータで提供する、人が開始する1対1の音声発信を比較します。Meta WhatsApp Business Calling API の説明ではありません。通話の詳しい導入手順は音声通話の導入チュートリアルを参照してください。

1. 顧客が同時に対応できるかで選ぶ

サポートの状況	推奨する方法	理由
顧客と担当者のタイムゾーンが異なる	音声メッセージ	都合のよい時間に返信できる
短い説明で、すぐに質問する必要がない	音声メッセージとテキストの要約	説明を聞き直し、要点を確認できる
複数の詳細を素早く確認し合いたい	都合を確認してから通話	双方で曖昧な点を解消できる
顧客が周囲に聞かれずに再生できない、または文字を希望する	テキスト	音声が適さない場面もある

例えば受け取り方法は音声で説明し、住所と時刻をテキストで添えられます。認識が食い違う点があれば、顧客の同意と都合を確認して通話を選べます。これは業務フローの提案であり、自動ルーティング機能や返信率の向上を保証するものではありません。

2. リクエストの形を分ける

どちらの場合も API キーはサーバーに保持し、意図した認証済みの WhatsApp メッセージングアカウントを選択して、runtime_status が running であることを確認します。個別の会話には、そのアカウントから返された conversation_id を使います。電話番号の文字列で代用しないでください。

音声メッセージでは、次の本文を POST /v1/messages に送信します。

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "message": {
    "type": "audio",
    "url": "https://cdn.example.com/support/explanation.ogg"
  }
}

例の URL はアクセス可能な音声リソースに置き換えてください。メディアメッセージの契約では、message.url、message.file_url、message.file_key の少なくとも1つに空でないソースが必要です。URL は絶対 HTTP(S) URL を使います。例は既存ファイルの送信であり、API がマイクから録音するものではありません。拡張子だけでは適切なエンコードを証明できず、特定のネイティブ音声メッセージ表示や文字起こしも保証しません。

リアルタイム音声通話は、別の本文を POST /v1/calls に送信します。

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "media_type": "voice"
}

通話作成の契約には、サポートが有効にするワークスペースのベータ利用資格が必要です。is_beta は読み取り専用です。成功レスポンス 201 の state: preparing は、非公開の使い捨て join_url が準備できたことを示します。担当者は expires_at 前に開き、Start call を押します。ページを開くだけでは発信されません。準備期間は作成から既定で2分ですが、サーバーで調整でき、接続後の通話時間は制限しません。マイクの許可は必須、カメラは任意です。

3. 結果の証拠をそれぞれ保存する

観測した結果	保存する情報	まだ証明できないこと
メッセージの応答が status: accepted	返された message_id とアカウント	配信、再生、問題解決
対応する配信・既読イベントを受信	通知の対象範囲とメッセージ識別子	顧客が音声を聞いたこと
通話作成で準備済みリンクを受信	返された call_id と担当タスク	発信や接続
call.answered を受信	data.call.id の接続証拠	問題解決
call.ended を受信	終了理由と duration_seconds	ゼロ秒なら未接続だったこと

配信と既読の文書に従って通知の対象範囲を解釈し、会話の全メッセージを一括で完了扱いにしないでください。既読は音声再生通知ではありません。接続時間は秒単位で切り捨てられるため、ゼロ秒でも接続イベントの証拠を保存します。

必要な購読を設定し、Webhook の配信と署名検証に従って生の本文を検証し、重複排除と遅延・順序逆転への対応を行います。ベータ利用資格と通話イベントの購読は別の条件です。メッセージの音声添付は通話イベントでも、通話 API が自動生成した録音でもありません。

4. 担当者の操作を明確にする

アプリでは音声を送信と音声通話を開始を分けます。送信前に選択ファイルと顧客を表示します。マイク録音、ファイル保存、文字起こしを実装する場合は、別のアプリ機能として扱い、成果物を検証してから API にリソースを渡してください。

通話の入口には対象顧客、担当者、利用可能かどうかを表示します。リンクは今回の操作担当者だけに渡し、全文をログに残さないでください。メッセージと通話を別々に記録し、同じサポートタスクに関連付けます。通話終了だけでチケットを自動的に閉じるべきではありません。

5. 方法を切り替えるには新たな判断が必要

音声メッセージに返信がなくても、聞いていないと判断して自動発信しないでください。まず通話が可能か尋ねます。通話で解決しなかった場合、担当者がテキスト要約や音声でのフォローを明示的に選べます。これは新しいメッセージであり、通話結果の続きではありません。

リクエストがタイムアウトしたら結果不明として保持し、書き込みをすぐに繰り返さないでください。通話結果が不明なら通話のトラブルシューティングを参照し、現在の管理対象通話を確認します。空の結果は過去の結果を復元しません。アカウントを空けるために所属不明の通話を切断しないでください。

6. 明確なサポートタスクを1つ選んで始める

適切なテスト会話を選び、顧客と連絡方法を合意し、アカウント、対象、リクエスト、保存した識別子、後続イベントを確認します。重複イベントと担当者による最後のチケット更新も確認してください。これは推奨する受け入れ確認であり、本記事で実通話テストを実施したという報告ではありません。

現在の通話機能は、着信、グループ通話、録音、文字起こし、SIP/PBX、AI の自動発信を含みません。利用資格や具体的な業務についてはテクニカルサポートに相談し、API キーや非公開通話リンクは共有しないでください。