チェックアウトの「顧客情報設定」に 推奨変更が提案されるようになった

図解 ： Shopify チェックアウトの「顧客情報設定」推奨変更（Recommended changes to checkout field settings） Improvement / Admin チェックアウトの「顧客情報設定」に 推奨変更が提案されるようになった 対象ストアの管理画面「チェックアウト設定」に、顧客情報の設定に関するパーソナライズされた推奨が表示される。適用すればチェックアウトでより完全な顧客情報が集まり、過去の購入者への再アプローチやマーケティングのパーソナライズがしやすくなる。適用しない限り既存設定は変わらない。 このページの構成 30秒で理解 ： 何が追加されたのか 流れの図解 ： 推奨が出てから適用されるまで 推奨に含まれうる 3 つの設定 既存ストア vs 新規ストア 確認・適用の手順 記事に「記載が無い」こと（推測しない） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が追加されたのか 対象となるストアは、Shopify 管理画面の チェックアウト設定ページ から、 顧客情報（customer information）設定についてのパーソナライズされた推奨 を受け取れるようになった。 推奨を確認し、そのまま適用できる。 適用しない限り、既存ストアの設定は変わらない。 どこに出る Shopify 管理画面の「チェックアウト設定」ページ。別アプリや別画面ではない。 何が出る 顧客情報設定に関する、ストアごとにパーソナライズされた推奨内容。 何のため チェックアウトでより完全な顧客情報を集め、過去の購入者への再アプローチとマーケティングのパーソナライズを効かせるため。 2 流れの図解 ： 推奨が出てから適用されるまで 勝手に変わらないのが最大の安心材料。 推奨はあくまで提案で、マーチャントが適用する操作をしない限り既存ストアの設定は変更されない。 3 推奨に含まれうる 3 つの設定 記事に例として挙げられているのは以下の 3 つ（“may include” ＝ 含まれる場合がある、という書き方）。 推奨例 1 顧客の連絡方法を「メールのみ」に customer contact method を email-only に設定する、という推奨。 推奨例 2 姓・名を必須にする first name / last name の入力を required にする、という推奨。 推奨例 3 配送先住所の電話番号を任意で収集 shipping address phone number を optional（任意）で集める、という推奨。 推奨は ストアごとにパーソナライズされる と書かれている。つまり上記 3 つが全ストアに同じように出るとは限らない。どれが出るかは実際に管理画面で確認する必要がある。 4 既存ストア vs 新規ストア 項目 既存ストア 新規ストア 推奨設定の適用状態 未適用 現在の設定のまま 既定で適用済み 推奨設定がデフォルト やるべきこと チェックアウト設定で推奨をレビューし、適用するか判断する 特になし（すでに推奨設定で動いている） 操作しなかったら 設定は一切変わらない — 対象範囲 「Eligible stores（対象となるストア）」とだけ記載。対象条件の詳細は 記載なし 5 確認・適用の手順 1 チェックアウト設定を開く Shopify 管理画面の Checkout settings（チェックアウト設定）ページへ。 2 推奨をレビューする 顧客情報設定について提示された推奨内容を確認する。 3 同じ画面から適用 チェックアウト設定から直接、変更を適用できる。適用しなければ何も変わらない。 6 記事に「記載が無い」こと（推測しない） 記載なし 対象ストア（eligible）の条件 プラン・国・ストア規模など、どのストアが対象になるかの条件は書かれていない。管理画面に出るかどうかで確認するしかない。 記載なし 推奨が生成されるロジック 「パーソナライズされた」とあるだけで、何を根拠に推奨が算出されるかの説明は無い。 記載なし API / Webhook での扱い 推奨の取得や適用を API 経由で行えるかどうかへの言及は無い。管理画面での操作としてのみ説明されている。 記載なし 効果の数値・ロールバック手順 CVR や情報取得率がどれだけ改善するかの数値、および適用後に元へ戻す手順についての記述は無い。 「メールのみ」「氏名必須」といった変更は 入力項目の増減＝チェックアウト体験の変更 にあたる。効果を語る前に、自ストアで適用前後を計測する前提で扱うのが安全。 7 技術者が押さえるべき5つのポイント 1. 既存と新規で初期状態が違う 新規ストアは推奨設定がすでにデフォルト、既存ストアは未適用。 複数ストアを扱う案件では、ストアごとに顧客情報設定の実態がズレる 前提で棚卸しが必要。 2. 適用は明示操作（opt-in） 既存設定は自動では書き換わらない。 意図せぬチェックアウト変更が入らない ので、レビュー～適用のタイミングを自分たちで設計できる。 3. 顧客レコードの品質に効く変更 氏名必須・メールのみといった設定は、そのまま 顧客レコードの必須項目定義 になる。CRM／MA 連携側の必須フィールド前提と合わせて見直す。 4. API での扱いは言及なし 推奨の取得・適用を自動化できるかは記事に書かれていない。 多店舗を一括で揃えたい場合、現時点では管理画面での手作業前提 で工数を積む。 5. 「情報の完全性」と「入力の手間」はトレードオフ 記事が語っているのは より完全な顧客情報を集める という便益であり、CVR が上がるとは書かれていない。氏名必須化などは入力項目を増やす方向の変更なので、 適用は計測とセットで 。適用前の設定を記録し、注文数・完了率・顧客情報の充足率を前後比較できる状態にしてから踏む。 8 業務に活かせる3つのユースケース USE CASE 1 複数ストア運用の「顧客情報設定バラつき」棚卸し 課題 ブランド別・国別に複数ストアを持っており、いつ誰が触ったか分からない顧客情報設定が店舗ごとにバラバラ。新しく作ったストアと古いストアで集まる項目が違う。 打ち手 各ストアのチェックアウト設定を開き、推奨が出ているストア＝推奨設定と乖離しているストアとして洗い出す。適用するか据え置くかをストア単位で判断し、判断結果を一覧に残す。 効果 設定の現状把握コストが下がる。新規ストアは既定で推奨設定なので、既存ストア側を寄せれば横串の顧客データ基準が揃う。 技術メモ API での一括取得・一括適用の可否は記事に記載なし。現時点では管理画面での確認作業として工数を見積もる。 USE CASE 2 「氏名が空の顧客レコード」で止まっていた MA 施策を動かす 課題 メール配信で名前差し込みをしたいのに、チェックアウトで氏名を必須にしていなかったため空欄の顧客が多く、パーソナライズしたセグメント配信が組めない。 打ち手 チェックアウト設定の推奨に「姓・名を必須にする」が出ていれば、それを適用してからの取得データで差し込み対象セグメントを作る。連絡方法をメールのみに寄せる推奨も併せて検討する。 効果 チェックアウトで集まる顧客情報がより完全になり、過去購入者への再アプローチとマーケティングのパーソナライズがやりやすくなる（記事が挙げている便益そのもの）。 技術メモ 適用日を記録し、適用前後で顧客レコードの氏名充足率を分けて集計する。既存レコードが遡って埋まるわけではない点に注意。 USE CASE 3 チェックアウト変更の「適用前後比較」を最小工数で回す 課題 チェックアウトの入力項目を触る提案は「CVR が落ちるのでは」と社内で止まりがちで、根拠データが無いまま議論が終わる。 打ち手 適用は明示操作なので、適用日を決めて実施し、その前後で注文完了数・顧客情報の充足率を比較する。合わなければ設定を戻す判断材料にする。実装は不要でチェックアウト設定の操作のみ。 効果 コードを書かずに「顧客情報の完全性 vs 入力の手間」の実データが取れ、以後の提案の根拠に転用できる。 技術メモ 適用前の設定値を必ずスクリーンショット等で控える（ロールバック手順は記事に記載なし）。計測期間は季節要因を吸収できる長さを確保する。 9 提案で使える1行サマリ 「チェックアウト設定の画面に、顧客情報設定のパーソナライズ推奨（メールのみ／氏名必須／配送先電話の任意収集など）が出るようになった。 新規ストアは既定で適用済み、既存ストアは適用操作をしない限り何も変わらない。 まずは推奨が出ているか確認 ＝ 現状設定の健康診断として使える。」 source ： changelog.shopify.com / recommended-changes-to-checkout-field-settings-are-now-available published 2026-08-13