私たちは先日、Shopifyの新しい顧客アカウント（Customer Accounts）を使った、OIDC（OpenID Connect）ベースのSSO連携のプロジェクトをクライアントワークとして行った。まだ日本語でまとまった実装情報がほとんどない領域であったため、手探りでの実装となった部分が多かったが、なんとか無事完了することが出来た。

自社ID基盤を活用した顧客アカウントベースでのデータ統合やその戦略設計などについては、近年その重要性が高まっていることは周知の事実である一方、実際にグローバルという文脈でそれを実施・運用するというのは相当先進的でかつ大規模なビジネスを行っている企業のみが行っているという印象があり、何から手を付けていいか、実際にどのように運用するのかなどは相談先も少ないというのが現状と思われる。

本記事では、こういった顧客を中心に据えた体験基盤OSのような設計における重要な要素という位置付けで、ShopifyでのSSO連携の実装について備忘録の意味を込めて書いていこうと思う。なお、この記事は概要編となり、仕様の細部や実装コードまでは踏み込まない。

---

結論から —「認証の置き換え」というより「会員基盤活用の再設計」

まず、この記事にたどり着くような、いわゆるリテラシーの高い方々は既にご存知かもしれないが、Shopifyでは元々Multipass APIというものが存在し、SSOを実現するためにはカスタムアプリを構築してその実装を行うという方式がとられていたが、その使うAPIが変わったという話ですか？という疑問があるかと思う。これは正確にはそういう話ではなく、Shopifyがメールアドレスとパスワードを用いた旧来のログイン方式（旧方式）から、現在のメールアドレスを入力後にメール認証からの6桁のパスコードを入力するという新しいログイン方式（新方式、または新しい顧客アカウントと呼ばれている）に移行されたことに伴った認証方式の仕様変更である。

旧方式では、Shopify独自形式のトークンでカスタムアプリを経由し認証のやり取りをしてSSOを実現していたのに対し、新方式では、業界標準のOpenID Connectを利用し、ShopifyをOIDCのログイン対象として、外部ID基盤に認証を委任する。この仕様変更により、単にログイン手段を置き換えるだけではなく、顧客の識別方法、顧客情報の同期、セッション維持、ログアウト連携なども含めて再設計する必要がある。とはいえ、技術的な側面を除けば提供できるUXはさほど変わらない。むしろ初めてこの変更の話を聞いた際には、SSO単体で見た場合はカスタムアプリなしでSSOを実現できるということだったので、プロジェクトの相談を受けた際は、開発期間などについても少し楽観的に考えていた。

が、実際にはただ単にOIDC準拠のID基盤ならサクッと繋げて検証すれば終わり、という話ではなく、むしろその実装に至る前の要件定義というか、ビジネス面を含めた設計が非常に重要だった。

---

本題に入る前にまず、いつまでに動くべきか? 一旦ここまでで公開されている時系列を整理してみよう。

これまでのSSO方式であるMultipass APIは、新しい顧客アカウントでは使えない。つまり、もし現在Multipass APIを活用したID連携を行っているなら、移行は「そのうちやること」ではなく「そろそろ計画を立て始めること」のフェーズに入っている。

Shopifyではこれまでにもチェックアウトの仕様変更など大規模なチェンジに関してはかなりの余裕を持ってアナウンスを行ってくれていたが、その時もチェックアウトのリプレイスはボタンをポチっで切り替えられるんだが、実際には既にカスタマイズされている各種挙動を新しい方式でどこからどこまで実装できるか、またそれに伴う影響は、これまで取れていたデータは正しく反映されるのか、などなど検討することや検証してみたら上手くいかないなどの理由から、想定していた期間の何倍も移行に時間がかかったという話は枚挙にいとまがない。そのため、まだ検討を始められていない場合は早めに動いた方が良い、というのが私たちの率直な感覚だ。

---

新方式のSSOで何ができるのか

ここから本題で、新方式のSSOで何ができるのかを整理する。Shopifyの新しい顧客アカウントでは、OIDCに対応した外部ID基盤を接続できる。ShopifyをOIDCのログイン対象として動かし、自社のID基盤や外部認証基盤をOpenID Provider（OP）としてつなぐ構成だ。なお、この外部ID基盤とのOIDC連携は、2026年5月時点ではShopify Plusプランでなければ機能が開放されないため、自社ID基盤でSSOを実装するために必要な要件という点においては、以前までと変わりないようだ。

基本仕様でできること

① SSOログイン

顧客は、自社ID基盤のアカウントでShopifyにログインできる。認証処理そのものはID基盤側で行われ、Shopifyは結果を受け取る。会員サイト・アプリ・ECなどで、共通の認証基盤を使える状態になる。

② 顧客アカウントの自動作成

Shopifyのログイン機能を自社基盤で代替する、というのが基本仕様になるため、自社ID基盤を通してShopifyにログインを行うと、そのままShopify側に顧客アカウントが自動で作られる。事前に全会員をShopifyへ移行しておく必要はない。

③ 既存顧客との紐付け

Shopify側にすでに顧客が存在する場合は、既存顧客との紐付けが行われる。内部的にどのように紐付けされているかは後述する。

④ ログアウト連動

Shopifyからログアウトした際には、ID基盤側のログアウトエンドポイントにリダイレクトできる。ただしFront-Channel LogoutとBack-Channel Logoutには対応していないので、ID基盤側をログアウトしてもShopify側を自動的にログアウトさせることはできない。

基本仕様に関しては、Shopifyでカスタムアプリを作ることなく、仕様に従って粛々と実装すれば、ちゃんと動く。Plusプラン、またはPlusプランが試せる開発ストアには、既に設定項目の「お客様アカウント」の中にある「認証」のところから試せる。注意点があるとするならば、実装時にエラーが出る際、基盤側のログは基盤側で確認することができるが、Shopify側のエラーに関してはそれを見る場所が無い。そのため、基盤側では正しく振る舞ってOKを出してるのにShopifyの画面上ではエラーだ、というような場合に、基盤側のどこに問題があるのかをピンポイントで特定しにくい。そのため、Shopifyのエンジニアチームと連携しながら進める体制を事前に用意する必要がある、というくらいだろうか。

ただし、SSOさせることが目的であればログイン出来ました、チャンチャンで良いかもしれないが、実際には基盤側にEC周りの各種データを寄せて色々と施策を打ったり、サービス横断的なより良いUXを提供しようという話のはずだ。そうするとやはりなんだかんだかなり細かく実装時の挙動や影響範囲について整理したり、カスタムアプリを作って足りない部分を補ったり、ビジネス面での要件を整理していく必要がある。

---

続いては必須要件を整理していく

Multipass時代と大きく違うのは、ShopifyがOIDCのログイン対象として動くため、ID基盤側にもOpenID Connect準拠の実装が求められる点だ。

Shopify側で確認すること

• 「新しい顧客アカウント」の利用：OIDC連携は新しい顧客アカウントが前提となる。2026年2月26日以降に新規で構築しているShopifyのアカウントであれば強制的に新しい顧客アカウントとなっているため特に何かする必要はないが、旧方式を利用している既存ストアは移行の検討が必要となる。
• IDプロバイダー設定：Shopify管理画面からDiscovery URL・Client ID・Client Secretを設定する。複数のIDプロバイダーを登録できるが、オンラインストアで有効化できるのは1つだけになる。
• Shop Payとの関係整理：自社ID基盤を有効化すると、標準の顧客ログイン画面は自社ID基盤側へ置き換わる。これまでShop Payを利用していたユーザーに対してどうするかを検討する必要がある。日本国内のみで事業を展開しているマーチャント様は、Shop PayはおまけくらいでShopify Paymentと何が違うんだ、くらいな感じかもしれないが、これが越境、特に欧米が主要マーケットとなっている場合は利用率が非常に高いため、やはり検討が必要となる。

ID基盤側で満たすべきOIDC要件

ヘルプページにも要件については記載があるため、同時に参考にしていただきたい。
（Shopify公式：Identity provider requirements）

書いていて思うが、この要件も時間の経過とともに変わっていく可能性が極めて高いため、あくまで2026年5月時点の情報で、都度ヘルプページなどから最新の要件を確認していただきたい。

---

ログインの流れ

ユーザーから見える動きは至ってシンプルだ。「ログインボタンを押す → ID基盤へ飛ぶ → 認証 → Shopifyへ戻る → 完了」。これだけだ。ところが裏側では、OIDCの認証フローが両サイドを行き来している。

ID基盤からShopifyに送るIDトークンには、こんな情報を入れる。

このうち重要なのは3つ。subはユーザーの一意識別子で、内部顧客IDなど将来変わらない値を使う。メールアドレスは変わりうるので、emailは属性情報として扱う。email_verifiedは必ずtrueで返す。falseだとログインできないことがある。

---

顧客との紐付け

Shopifyに顧客登録が無い場合は、基盤側で新規登録される際にShopifyにも顧客登録がなされる。その際に紐付けが行われる。Shopify側にすでに顧客が存在する場合は、ID基盤から返ってきた情報をもとに、既存顧客との紐付けが行われる。

具体的には、顧客が自社ID基盤でログインすると、ID基盤はShopifyへ「この人はこのメールアドレスのユーザーです」という情報を返す。Shopifyはそのメールアドレスを見て、管理画面の顧客一覧に同じメールアドレスの顧客がすでに存在するかを確認する。

同じメールアドレスの顧客が存在する場合は、その既存顧客としてログインさせる。存在しない場合は、新しい顧客アカウントを作成する。また、Shopifyはメールアドレスだけでなく、ID基盤から返される sub も利用して顧客を識別する。subはログイン時に「同じID基盤上の同じユーザーか」を判断するために使われる。

そのため、既存ストアでSSOを導入する場合は、Shopify側に登録されているメールアドレスと、ID基盤側のメールアドレスがどれだけ一致しているかを事前に確認しておくことが重要になる。同一人物だがメールアドレスが異なるというケースについては、Shopify側で新規に顧客アカウントが作られてしまう。

---

設計時に検討するべきことのスコープ

まず、新規に構築したShopifyストアにこの機能を実装しようという話と、既に運用中のストア、また既に自社ID基盤でのSSOが実装されているストアでは、かなり検討する内容も異なる。今回弊社で行ったプロジェクトは、実際に運用されてはいるが、自社ID基盤との連携は行われていないというケースだった。そのため、検討事項としては以下のようなものがある。

• 既存顧客の自社基盤及びShopifyでの登録状況を踏まえてどう設計するか
• 基盤側またはShopifyでのメールアドレス変更をどう扱うのか
• 独自UID（会員番号・統合顧客ID）をどう管理するのか
• ログイン導線：どこからどこへ飛んで、ログイン後どこへ戻すか。ゲスト購入は許可するか
• マイページの役割分担：注文履歴はShopify、会員情報はID基盤、といった切り分け。企業の会員戦略に合わせて決める
• 顧客管理ルール：重複顧客・UID・メールアドレス変更・顧客統合・退会後の再登録をどう扱うか
• セッション管理：ID基盤側で退会したのにShopify側のセッションが残っている、といった状況をどうするか
• 利用者アナウンス：ログイン方法・マイページ・パスワード管理が変わることを事前告知する。認証まわりの変更は、問い合わせがふくらみやすい
• 法務：個人情報の管理主体、顧客情報連携に伴う利用規約・プライバシーポリシーの見直し、再同意の要否

運用トラブルの多くは、認証の失敗ではなく、顧客管理ルールの未整理から生まれる。先にここを決めておきたいところだが、中々ここまでのアドバイスを無償で提供してくれるベンダーはいないだろう。地味だが高度な内容だ。この記事が一助になれば嬉しい話だ。

これらはあくまで例だが、1つ1つ案件ごとに考えて決めるしかない。もちろん先行する他社がどうしたかというのは貴重な情報だが、そうそう手に入るものでもない。公式ドキュメントにはシステム面での仕様はかなり細かく正確に書かれてはいるものの、ケースバイケースへの対処法は載っていない。AIに質問してもなんとなく不安が残ってしまうだろう。

---

UID連携 、つまり統合的な顧客IDはどのように管理する（される）のかの話

カスタムアプリを構築することなくSSOが実現できるのが素晴らしいと思ったものの、実際に運用ベースにのせるためには、結局カスタムアプリを作らないと顧客情報が同期できないためダメだ、というのが設計序盤で判明した。

多くの認証基盤では、会員番号や統合顧客IDといった独自の識別子（UID）を運用している。この独自のUIDをShopify側にも持たせたい、という要件が出てきたので、カスタムアプリを作ってUIDをShopifyのメタフィールドへ保存する構成を採った。

今回のプロジェクトは既にShopifyを複数年運用しているECサイトに、既存の自社ID基盤でSSOする機能の実装であったため、顧客の情報は以下のようになっていた。

いきなりUID連携の話をしてしまったが、SSOする際にIDの紐付けはどうなるという話と、UIDをメタフィールドに保存するという話は別の話になる。既存顧客がどのように紐付けされるのかは先ほど書いた通りだが、subに格納されたUIDが自動的にShopifyに用意したメタフィールドに入るということは無い。

どのタイミングでUIDを同期するかが課題になった。Shopifyで顧客作成時に発行されるcustomers/createのWebhookだけでは、パターン①や③の既存顧客のUIDをメタフィールドに焼きに行くという行為ができない。厳密には、基盤側にログインした際にその情報をカスタムアプリなどにリアルタイムに通知してもらうことが出来れば可能ではあるが、自社基盤側の改修は避けたいところだろう。Shopify側では、顧客がログインしたという情報をタイムリーに、かつセキュアに取得できる方法がないため、何をトリガーに基盤側から該当顧客のUIDを取得しようかという話になったわけだ。

そこで私たちは、顧客作成時のcustomers/createと、注文決済のorders/paidのWebhook 両方を使い、新規顧客・既存顧客の双方に対してUID同期を行う構成にした。もっとシンプルには、そもそも基盤側のデータとShopifyの既存顧客のデータを突合し、①と③のパターンについては事前にUIDをShopifyに入れておくということが出来れば話は早かったかもしれないが、大人の事情でそれが出来なかった。

---

2026年3月17日のアップデートで、同期が一部楽になった

従来はカスタムアプリで自前実装する必要があった同期処理の一部が、Shopify標準機能でまかなえるようになった。Shopify Plusでは、IDプロバイダー連携時に「顧客データの同期」を有効化することで、顧客がログインするたびに、ID基盤側の対応情報をShopifyの顧客情報へ取り込むことができる。別途顧客情報を更新しなくても、氏名・電話番号・住所・タグなど一部の情報を標準機能で同期できるようになっている。

標準で同期できる項目と、できない項目は以下のものだ。

実案件では、この「標準で同期する項目」と「自前で同期する項目」を切り分けて設計するのが肝になる。なお住所を同期する場合、国・州はISOコード形式で渡す必要がある。電話番号や住所の値が不正でも、ログイン自体は続行され、その項目だけが同期から外れる。ログインまで巻き込んで落ちないのは、優しい設計だと思う。

ここで最低限、同期するかどうかのディスカッションを自社のCSチームなど含めてしておいてほしいのが、メールアドレスを同期するかどうかだ。上述した標準同期できる項目は強制的に同期されるわけではなく、明示的に実装を行って同期させることになる。つまり、それを実装しなければ、1度顧客の紐付けが行われた後で、ID基盤側なりShopify側のメールアドレスが変更になり異なる状態になったとしても、同一人物として既存アカウントにログインさせることは出来る。

しかしながらここで少々ややこしいのは、メールアドレスが異なっていても、ID基盤側でログインできればShopifyにもログインできる仕様にはなっているものの、Shopifyからの通知メールなどは全てShopifyに登録されているメールアドレスに飛ぶということだ。これは実際の一般的な顧客の想定挙動とは異なる可能性がある。つまり顧客としては、例えばもう使わなくなったからという理由でメールアドレスを基盤側で変更したにも関わらず、注文通知や発送完了通知などが全て旧メールアドレス側に飛んでしまうことになる。かと言って強制的に同期してしまうと何かの理由で別のメールアドレスを使いたいという場合にユーザーにとっては不都合だ。例えば私も、会社のメールアドレスと個人のメールアドレスを用途によって使い分けている。それに対応するために細かく色々とシステムで実装するならコストが跳ねる。こういったケースは現状、ShopifyのAdmin管理画面側からお店側で変更していただくのが安全そうではある。

---

保守に関して

ビジネスサイドの方々には実装後のことも多少ご理解いただきたい部分として、いくつか検討するべきことを挙げておきたい。

• ログ監視：OIDC認証ログ、Token取得ログ、Webhookログ、顧客同期ログを定期的に確認する
• Shopify仕様変更への追従：Customer Accountsは今もアップデートが続いている。Changelogなどを眺める習慣、またはRSSを自動で受信できるような状態にしておいて損はない
• 顧客問い合わせ対応：ECのCS担当だけでなく、基盤担当も含めた体制を用意しておき、顧客へのスムーズな対応ができるよう準備しておきたい

機能が動くことと、運用が回ることは、似ているようで別物だ。これはSSOに限らず、SaaSのアプリでポチポチで実装完了するはずなのに、実際の運用開始まで2ヶ月かかりましたのような話と同じだ。というか普通にそれくらいかかったりするものだという前提の認識を持っても良いかもしれない。私個人は気合いでやろうと言って部下などからよく反感を食うのだが真似しないでほしい。

---

終わりに

さて、プロジェクトとしては多少の紆余曲折がありはしたものの、期日内にUATまでしっかりと完了でき、運用まで行けた。多少詳細は省いてしまったが、代わりにここからは多少の補足事項を書こうと思う。

まだ自社ID基盤を持っていない企業様

Auth0・Okta・Microsoft Entra ID・Amazon Cognito といったSaaS型の認証基盤サービスはどれもOIDCに標準対応しているので、これらを使うことでわりとライトに基盤構築及びShopifyでのSSOを実現できる。

これらの基盤にGoogle・Apple・LINEログインを集約し、その認証結果をShopifyへ渡す構成も一般的だ。Shopifyで有効化できるIDプロバイダーは1つだけなので、いろんな認証方式はID基盤側へまとめておくのが定石になる（とエンジニアが言っている）。

ただし、ここは念押ししておきたい。認証がつながることと、会員基盤としてちゃんと運用できることは、別の話だ。顧客情報管理・UID管理・顧客同期・セッション管理まで含めて設計しておかないと、運用フェーズで想定外の問題が発生し混乱がおきる可能性が高い。

「ShopifyのIDで他サービスにログイン」は、今はできない

これはよく聞かれる。「Shopifyを認証基盤にして、他のサービスにログインさせられますか」。答えは、現状できない。LLMに聞くと、出来ると答えられることがたまにあるそうで、パートナーの立場としてはめんどくさい。

今回の構成は「ID基盤 → Shopify」、つまりShopifyがログイン対象として動く形だ。逆に「Shopify → 他サービス」をやるには、ShopifyがOpenIDの提供側になる必要があるのだが、現状のShopifyは外部サービス向けのOpenIDの提供側としては使えない。お客さんは迎え入れるが、自分が身分証を発行する側には回らない、というイメージだ。

なので、EC・アプリ・会員サイトをまとめて統合したいなら、自社ID基盤を真ん中に据えて、Shopifyは接続先の一つとして扱う構成が現実的になる。

---

ID基盤連携を検討する企業様へ — 3つの選択肢

自社のID基盤とShopifyの連携を考えているなら、ここから先の進め方は、ざっくり3つに分かれる。会社の体制に合わせて選んでほしい。

もし弊社と一緒にこのような取り組みを検討されたいと思っていただけるようであれば、個人的にはOIDC連携単体の話ではなく、CDP含めた顧客基盤統合及び顧客セントリックな成長戦略の策定と運用あたりまで含めたプロジェクトを是非ご検討いただきたいと思う。

本記事は飛躍が実際に構築したShopify Customer Accounts × OIDCベースSSO連携の実装記録を、クライアント固有情報を伏せたうえで概要として整理したものである。仕様の細部や実装の続編、最新の支援事例は飛躍公式サイトに掲載していく。