Dify アプリで WhatsApp メッセージに自動応答する

Meta は WhatsApp メッセージを Dify に直接送れますか？

Meta のハンドシェイクを完了できる形では送れません。Meta はメッセージを配信する前に、送信先へ GET リクエストを送り、hub.challenge の値を生のレスポンス本文としてそのまま返すことを求めます。Dify の Webhook Trigger は 1 つのトリガーにつき HTTP メソッドを 1 つしか受け付けず、ドキュメントによると JSON 以外のレスポンス本文は自動的に JSON に変換されるため、OK はメッセージオブジェクトとして返ります。チャレンジを正確にそのまま返すことはできず、Meta は配信を開始しません。

そのため、手前に小さな受信側を置きます。n8n の Webhook ノード、Python や Node のルート、サーバーレス関数のいずれかで GET に応答し、POST を受け取り、テキストを Dify に渡します。Webhook URL に含めた長いランダムな秘密文字列を確認するのもこの受信側です。X-Hub-Signature-256 ヘッダーは Tech Provider のアプリシークレットで署名されており、顧客側では検証できないためです。

受信側は Dify アプリとどのようにやり取りしますか？

Dify の Service API を 1 回呼び出します。POST /chat-messages を、アプリの API キーで認証して送ります。本文には、顧客のテキストである query と、自分で定めた識別子である user を含めます。user には送信者の WhatsApp 番号を使い、Dify が返す conversation_id を保持しておくと、同じ相手の次のメッセージが同じ会話として続きます。

response_mode には注意が必要です。blocking は回答の完成後に返りますが、Dify のドキュメントは、Dify Cloud では長い生成がエッジプロキシによって打ち切られることがあると警告しています。エージェントアプリはストリーミングのみに対応しており、blocking のリクエストは 400 で失敗します。ストリームを読み取り、最後に WhatsApp メッセージを 1 通送る受信側が堅実な構成です。

返信は Cloud API のテキストメッセージとして同じ番号へ送ります。顧客のメッセージで開いた 24 時間のウィンドウ内であれば無料です。

Dify の中で MCP サーバーは何を可能にしますか？

呼び出しごとの配線なしで、Dify のエージェントが番号を操作できるようになります。Dify は HTTP で MCP サーバーに接続し、デフォルトでは OAuth の動的クライアント登録でサーバーに自身を登録します。EasyCoexistence MCP サーバーはこれに対応しています。「ツール」から追加して一度サインインすると、エージェントは次のツールを使えます。番号の一覧、番号の接続状態の確認、メッセージ送信、承認済みテンプレートの送信、テンプレートのステータス確認です。

これは能動的な処理に適した使い方です。翌日にフォローアップする Dify のワークフローでは send_template を使う必要があります。ウィンドウ外のフリーテキストはエラー 131047 を返し、ツールの説明がモデルにそう伝えているためです。

MCP にできないのは、顧客が書き込んだときに Dify を起動することです。このプロトコルはリクエストとレスポンスの形式なので、受信メッセージは引き続き Webhook と手前の受信側を通って届きます。

よくある間違い

• Dify の Webhook Trigger の URL を Webhook の送信先にすること。チャレンジが JSON で包まれて返り、Meta はエンドポイントを確認できません。
• Dify のエージェントアプリに blocking のリクエストを送ること。エージェントアプリはストリーミングのみ対応で、呼び出しは 400 で失敗します。
• メッセージごとに新しい user の値を使うこと。Dify は会話を user 単位で管理するため、毎回新しい会話になり、記憶が引き継がれません。

よくある質問

続きを読む