「認証コードを送信したのに、Safariで再びログイン画面へ戻る」という症状なら、先にネットワークを変更したりコードを何度も再送したりしてはいけません。Shopify 顧客アカウントのログイン失敗は、顧客アカウント方式、ログイン用ドメイン、メール到達、Safariのセッション、外部認証設定の順に分けて確認し、Safariだけで再現するときに限って実機のMacを比較環境に加えるのが最短です。
この記事の対象
Shopifyの顧客アカウントを有効にした後、購入者から「ログインできない」「注文履歴が見えない」と連絡を受けた運用担当者向けです。顧客アカウント用ドメインの変更、ソーシャルログインの導入、旧方式からの移行を担当する責任者にも適しています。
また、実際のSafariや米国の購入者側の表示を確認しながら、独立ストアの会員機能を受け入れ確認したいテスト担当者にも役立ちます。
最初に症状を五つへ分類する
画面の印象だけで「IPが悪い」と判断すると、メール配信の問題とブラウザーのセッション問題を混同します。Shopifyの顧客アカウントは、旧方式と新方式でログインの導線や設定項目が異なるため、最初に購入者用ログインと管理画面のスタッフログインを分離してください。
| 購入者から見える症状 | 最初に確認する場所 | まだ断定できない原因 |
|---|---|---|
| ログイン入口が消えた | テーマのアカウントリンク、リンク先URL | 旧方式・新方式の不一致、テーマ変更 |
| 認証コードが届かない | 入力メール、迷惑メール、受信規則 | メール配信、入力間違い、再送の重複 |
| 認証後にログイン画面へ戻る | 顧客アカウント用ドメインと戻り先 | ドメイン設定、外部認証、セッション |
| Safariだけ状態を保持しない | サイトデータ、拡張機能、ウインドウ種別 | 特定コンポーネント、遷移依存 |
| ログイン後に注文が違う | 顧客メール、マーケット、注文の所属 | 顧客情報、地域入口、表示条件 |
Shopifyの公式説明では、顧客アカウントのログイン方式やパスワードなしの認証コード方式が案内されています。現在の設定と画面が一致するかは、Shopifyの顧客アカウントのログイン方式で確認してください。
第一段階：入口とアカウント方式を確認する
テーマ上の人型アイコンを押したとき、購入者向けの顧客アカウントへ移動するのか、Shop Payへ進むのか、管理画面のログインへ進むのかを記録します。クリック前後の完全なURLを保存し、個人情報や注文番号は画像から隠します。
確認手順は次のとおりです。
- ショップをログアウト状態で開きます。
- テーマのアカウントアイコンとフッターのログインリンクを個別に押します。
- それぞれの遷移先URLとページタイトルを保存します。
- 管理画面のスタッフ用ログインと、購入者の顧客アカウントを別のテストとして扱います。
- 旧方式から移行した直後なら、Shopifyの顧客アカウント移行案内と現在の設定を照合します。
Shop Payは購入時の支払い体験に関係しますが、顧客アカウントの認証状態と同一とは限りません。購入者が「Shop Payには入れるのに注文ページが見えない」と報告した場合も、メールアドレスと顧客プロフィールを別に確認します。
第二段階：認証メールと再送操作を切り分ける
認証コードが届かない場合は、まず入力されたメールアドレスが顧客情報と一致しているかを調べます。次に迷惑メールフォルダー、受信拒否、転送設定、社内メールのフィルターを確認し、送信時刻と受信時刻を記録します。
再送を続けると、どのコードが最新なのか分からなくなります。管理されたテスト用メールで送信、受信、コード入力を一度の流れとして記録し、到達しない状態が続く場合はメール配信担当またはShopifyサポートへ引き継いでください。
第三段階：ドメインと外部認証の遷移を追う
認証後に同じログイン画面へ戻るときは、アドレスバーだけでなく、認証前後のドメインを並べて確認します。顧客アカウント用サブドメイン、ショップの主ドメイン、認証後の戻り先が混在していないかが焦点です。
ソーシャルログインや外部IDプロバイダーを使う場合は、コールバックURLとログアウト後のURLが現在のドメインに合っているか確認します。外部IDプロバイダーの接続条件は、Shopify公式のIDプロバイダー接続手順で確認できます。
| 記録する項目 | 成功時 | 失敗時 |
|---|---|---|
| ログイン入口 | 購入者向けURL | テーマ内の古いURL、別の入口 |
| 認証前ドメイン | 想定した顧客アカウント用ドメイン | 主ドメインや別サブドメイン |
| 認証後URL | 注文またはアカウントページ | ログイン画面への反復遷移 |
| 外部認証の戻り先 | 登録済みの現在URL | 変更前のコールバックURL |
| 画面状態 | 顧客名と注文情報が一致 | 別顧客、空のアカウント、未認証表示 |
ドメインを変更した直後は、設定を何度も上書きする前に、変更前後のURL、変更時刻、テスト顧客の結果を保存します。復旧では、ドメイン設定、テーマリンク、外部認証設定を一度に変えず、どの変更で状態が戻ったかを追えるようにします。
Safariだけ失敗する場合の対照手順
Chromeなど別のブラウザーでは正常で、Safariだけログイン状態が消える場合は、同じURL、同じテストメール、同じ顧客情報で比較します。Safariのプライベートブラウズ、通常ウインドウ、拡張機能の有無を順に変え、条件を一つずつ固定してください。
AppleはSafariのサイトデータやプロファイル、プライバシー関連の動作を説明しています。具体的な設定項目は、Safariのプロファイルとサイトデータの案内およびプライベートブラウズとサイトデータの説明を参照します。ただし、追跡防止機能があることだけを根拠に、ログイン失敗の原因と断定してはいけません。
- [ ] macOSとSafariのバージョンを記録する
- [ ] 通常ウインドウで同じURLを開く
- [ ] プライベートブラウズで同じ操作を再現する
- [ ] 拡張機能を一時的に無効にして比較する
- [ ] 対象サイトの保存データを確認し、必要なら対象範囲だけ消去する
- [ ] Safariと別ブラウザーで同じメール、同じ入口を使う
- [ ] ログイン、ログアウト、再ログイン、注文ページ表示を記録する
- [ ] スクリーンショットからメールアドレス、注文番号、個人情報を隠す
Safariの一般的な不具合確認については、AppleのSafariトラブルシューティングも参照できます。設定を常時緩めることは回避策ではなく、問題の対象コンポーネントを特定するための一時的な比較に限定します。
注文や顧客情報が違う場合の確認
ログイン自体が成功していても、注文、住所、表示言語が期待と異なることがあります。この場合は認証失敗として扱わず、ログインしたメールアドレスと顧客プロフィール、マーケットの入口、注文の所属を照合します。
米国IPで表示したからといって、顧客アカウントの注文状態が米国顧客のものになるわけではありません。ログイン前後のメールアドレス、マーケット、ページ言語、表示された注文を記録し、顧客ごとのデータを混同しないようにします。
修正後の最小受け入れ確認
実際のSafariや米国購入者側の経路だけで再現する場合は、最初から海外環境へ移すのではなく、まずテスト用顧客、入口URL、期待結果を固定します。そのうえで、Safari、別ブラウザー、ログイン用ドメイン、マーケット入口を組み合わせた最小の確認表を作成します。
| 確認条件 | ログイン | ログアウト | 再ログイン | 注文ページ |
|---|---|---|---|---|
| Safari・通常ウインドウ | □ | □ | □ | □ |
| Safari・プライベートブラウズ | □ | □ | □ | □ |
| 別ブラウザー・通常状態 | □ | □ | □ | □ |
| 米国購入者側の経路 | □ | □ | □ | □ |
失敗時には、エラー文、発生時刻、完全なURL、直前の設定変更、再現手順を一つの資料にまとめます。Safariと別ブラウザーの差だけでなく、ログイン後にどのドメインへ移ったかを添えると、テーマ、ドメイン、メール、外部認証の担当者へ渡しやすくなります。
自社環境で米国側のページを確認する必要がある場合は、米国ノードのMac環境を比較候補にできます。料金や契約条件を確認する場合は、RUVCLOUDの料金案内を参照してください。ただし、海外ノードは地域側の表示を確認するための補助環境であり、Shopifyの認証規則、顧客情報、アカウント制限を回避したり、ログイン成功を保証したりするものではありません。
よくある確認事項
Shopifyの顧客アカウントとスタッフ用ログインは同じですか？
同じではありません。スタッフ用ログインはショップ管理画面へ入るためのもの、顧客アカウントは購入者が注文や住所を確認するためのものです。サポート依頼では、どちらのログインか、どのURLから開始したかを最初に分けて記録してください。
Shop Payに入れるのに顧客アカウントへ入れないのはなぜですか？
Shop Payの利用状態だけでは、対象ショップの顧客プロフィールや注文表示が正しいとは判断できません。購入者のメールアドレス、ショップの顧客情報、顧客アカウント用URLを別々に照合し、支払い機能の認証とショップ会員ページの認証を混同しないことが重要です。
Safariの設定を変更すれば解決しますか？
設定変更で改善する場合はありますが、追跡防止やサイトデータの仕組みだけで原因を断定することはできません。通常ウインドウ、プライベートブラウズ、拡張機能の有無を比較し、再現条件を特定してから、必要な対象サイトだけを調整します。
現実のSafari環境を継続確認する選択肢
ローカルのSafariでは正常なのに、米国購入者側の経路や特定の実機環境でだけ顧客アカウントが失敗する場合、ネットワークを変え続けるより、テスト用顧客、対象URL、確認表を固定して継続的に再現できる環境を用意する方が管理しやすくなります。
自社Macを購入して常時運用する方法は、初期費用、保守、設置場所、担当者交代時の引き継ぎが負担になります。一般的なクラウド画面だけではSafari固有の挙動や実機に近いページ確認ができず、VPNやプロキシだけではブラウザーのサイトデータ問題を切り分けられません。短期のリリース確認や米国側表示の再現が目的なら、RUVCLOUDのレンタルMacを比較環境として使う判断には合理性がありますが、長期の常時運用や物理機器が必要な作業には自社Macの方が適しています。最初に受け入れ条件を整理し、必要な期間だけ実機のSafari環境を借りる形が現実的です。