WhatsApp マーケティング同意を API から読み書きできるようになった

図解 ： WhatsApp マーケティング同意が Admin API / Customer Account API で管理可能に Admin / Customer Account API ・ Action Required WhatsApp マーケティング同意を API から読み書きできるようになった これまで API では扱えなかった「WhatsApp でのマーケ配信に同意したか」を、Admin API と Customer Account API の両方から更新・取得できるように。専用ミューテーションと専用フィールドが追加された。 このページの構成 そもそも何が変わるのか（30秒で理解） 追加された API 要素 仕組み図解 ： 読み取りと書き込み どの API から触れるか 記事に明記されている点／されていない点 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 顧客の WhatsApp マーケティング同意（marketing consent） を、Customer Account API と Admin API の両方から 更新・取得できる ようになった。 更新は customerWhatsAppMarketingConsentUpdate ミューテーション、取得は CustomerPhoneNumber の whatsAppMarketingConsent フィールドから。対象は顧客の デフォルト電話番号 。 これまで ： API で扱えなかった WhatsApp のマーケティング同意ステータスを API 経由でプログラム的に読み書きする手段が無かった。 これから ： API で読み書き可能 専用ミューテーションで更新、 CustomerPhoneNumber の専用フィールドで現在値を取得できる。Admin・Customer Account の両系統に対応。 2 追加された API 要素 Mutation customerWhatsAppMarketingConsentUpdate 顧客の デフォルト電話番号 に対する WhatsApp マーケティング同意ステータスを更新するためのミューテーション。Admin API・Customer Account API の双方から呼べる。 Field CustomerPhoneNumber.whatsAppMarketingConsent CustomerPhoneNumber オブジェクトに追加された読み取りフィールド。現在の WhatsApp マーケティング同意値をここから取得する。 ポイントは 「書き込み = ミューテーション」「読み取り = フィールド」 がペアで揃ったこと。 同意の取得・更新の両方向が API でカバーされたので、外部 CRM やマーケツールとの双方向同期が組める。 3 仕組み図解 ： 読み取りと書き込み 更新対象は顧客の デフォルト電話番号 に対する同意。複数番号を持つ顧客の挙動や、デフォルト以外の番号の扱いについては記事に記載なし。 4 どの API から触れるか 操作 使う要素 Admin API Customer Account API 同意を更新する customerWhatsAppMarketingConsentUpdate 対応 対応 同意を読み取る CustomerPhoneNumber.whatsAppMarketingConsent 対応 対応 対象 顧客のデフォルト電話番号 両 API 共通 ※ 記事は Admin API・Customer Account API の両方のリファレンスを参照先として案内している。タグには Webhook / Action Required / 2026-07 も付与されている。 5 記事に明記されている点／されていない点 明記あり 記事に書いてあること ・両 API で WhatsApp マーケ同意を管理可能 ・更新は customerWhatsAppMarketingConsentUpdate ・読み取りは CustomerPhoneNumber.whatsAppMarketingConsent ・対象はデフォルト電話番号 ・タグ ： Action Required / Admin GraphQL API / Customer Account API / Webhook / 2026-07 記載なし 記事に書いていないこと ・同意値の具体的な enum / データ型 ・どの Webhook トピックが発火するか（タグに Webhook はあるが本文に詳細なし） ・「Action Required」で具体的に何を対応すべきか ・対応 API バージョン・地域・必要スコープ ・複数電話番号やデフォルト以外の番号の扱い これらは リファレンスで要確認 。 6 技術者が押さえるべき5つのポイント 1. Read / Write がペアで揃った 更新ミューテーションと読み取りフィールドが同時に提供されたので、同意状態の 双方向同期 がそのまま実装できる。片側だけのときの差分検知の苦労が消える。 2. Admin と Customer Account の両系統 バックオフィス側（Admin）からの一括管理と、顧客自身がアカウント画面で同意を切り替える（Customer Account）導線の 両方 を同じ概念で扱える。 3. 対象は「デフォルト電話番号」 同意は顧客のデフォルト電話番号に紐づく。実装前に「対象顧客がデフォルト番号を持っているか」「番号変更時にどう扱うか」を設計で固めておく。 4. 「Action Required」タグに注意 変更が Action Required として告知されている。既存の連絡先同意管理を実装しているアプリは、WhatsApp チャネルへの対応要否をリファレンスで確認すること。 5. Webhook タグの中身は本文未記載 — 要検証 記事タグに Webhook があるが、本文では具体的なトピック名や payload に触れていない。同意変更をイベント駆動で拾いたい場合は、対応 Webhook トピックの有無・名称・スコープを リファレンスとサンドボックスで先に確認 すること（本文だけを根拠に実装しない）。 7 業務に活かせる3つのユースケース USE CASE 1 外部 CRM / MA ツールと WhatsApp 同意を双方向同期 課題 WhatsApp 配信の同意状態が外部 CRM と Shopify でバラバラ。手動つき合わせで配信ミスや法令リスクが残る。 打ち手 更新ミューテーションで CRM 側の変更を Shopify に反映し、 whatsAppMarketingConsent フィールドで Shopify 側の値を CRM に取り込み、双方向同期を組む。 効果 同意状態の単一の真実が保たれ、未同意者への誤配信を防止。配信対象の自動絞り込みも可能に。 技術メモ 対象はデフォルト電話番号。同意値の型と enum はリファレンスで確認してからマッピングを実装する。 USE CASE 2 顧客アカウント画面に WhatsApp 配信のオプトイン UI を設置 課題 顧客が自分で WhatsApp 配信の受け取り可否を切り替える導線がなく、問い合わせ対応や手動更新が発生。 打ち手 Customer Account API の更新ミューテーションを使い、顧客アカウント画面に「WhatsApp で受け取る」トグルを実装。現在値は読み取りフィールドで表示。 効果 セルフサービス化で運用負荷を削減しつつ、本人の明示的な同意取得で配信の正当性を担保。 技術メモ Customer Account API 側のスコープ・認証フローを確認。同意取得時刻などの監査情報をどこまで取れるかも要チェック。 USE CASE 3 配信前バッチで「同意済みだけ」を機械的に抽出 課題 WhatsApp キャンペーン配信のたびに、同意済み顧客リストを手作業で精査していて時間がかかる。 打ち手 Admin API で CustomerPhoneNumber.whatsAppMarketingConsent を読み、同意済みの顧客だけを配信ジョブの対象として自動抽出するバッチを組む。 効果 未同意者への配信を構造的に排除し、コンプライアンスを担保しつつリスト作成工数を削減。 技術メモ 大量顧客はページネーション設計が必須。同意変更を即時反映したい場合は Webhook 対応の有無をリファレンスで確認。 8 提案で使える1行サマリ 「WhatsApp マーケティング同意を、Admin API と Customer Account API の両方から 読み書き できるように。 更新は customerWhatsAppMarketingConsentUpdate 、取得は CustomerPhoneNumber.whatsAppMarketingConsent 。 CRM 双方向同期・顧客セルフ同意 UI・配信前の同意フィルタ がコードで組めるようになった（対象はデフォルト電話番号）。」 source ： shopify.dev / changelog / whatsapp-marketing-consent-now-available