Columns2026/09/14

Multipassから独自IdP接続へ。自社会員基盤とShopifyのSSO移行で押さえること

この記事でわかること

→ なぜMultipassが使えなくなるのか。「廃止」ではなく「土台が終わる」とはどういうことか
→ 何に変わるのか。トークンを渡す方式と、認証を任せる方式は何が違うのか
→ いまの会員基盤をそのまま使えるか、どう見極めるのか
→ 会員基盤がIdPになっていない場合に、どんな選択肢があるのか
→ 既存のお客様のログイン体験がどう変わるのか
→ 何から手をつけ、どの順番で進めるのか。いつまでに動くべきなのか

「うちは自社サイトでログインさせて、そのままShopifyにも入れるようにしているのですが、これはどうなりますか」。ここ最近、いちばん多くいただく質問です。

外部サイトから Shopify へログイン状態を引き渡す仕組みは、これまで Multipass が担ってきました。これは「従来のお客様アカウント」専用の機能です。そして従来のお客様アカウントは、2026年2月26日に非推奨（deprecated）になりました。いま動いているストアは当面そのまま使えますが、土台がなくなれば、その上に乗っている機能も一緒になくなります。

この記事では、何がいつ変わるのか、代わりに何を使うのか、自社が何をいつ決めるのかを整理します。扱うのは認証とSSO（一度のログインで複数のサイトを行き来できる仕組み）です。

いま何が起きているのか

結論から言うと、「Multipassが廃止される」という発表はまだありません。発表されているのは、その土台である従来のお客様アカウントの非推奨です。

Shopifyは2026年2月26日付で、従来のお客様アカウントを非推奨としました。新規ストアでは利用できず、それまで使っていなかった既存ストアもアクセスできません。すでに使っているストアは当面動きますが、機能改善と技術サポートの提供が止まります。終了日は2026年内に発表される予定で、2026年9月時点では未公表です。

Multipass は従来のお客様アカウントでしか使えません。公式ドキュメントにも「Multipass login is only available with legacy Customer accounts」と明記されています。Multipass 単体の終了日を待つ必要はなく、見るべき期日は従来のお客様アカウント側にあります。

図① 発表されていること、されていないこと、事業者側で動くこと　期日は Multipass ではなく、従来のお客様アカウント側に置かれています。

仕組みは何がどう変わるのか

代わりは、新しいお客様アカウントの「独自IdP接続」です。IdP（アイデンティティプロバイダー。ログインを担当する認証サーバー）を OIDC（OpenID Connect）でShopifyにつなぐ機能で、2024年12月11日に提供が始まりました。

いちばん大きな違いは、主導権と矢印の向きが逆になることです。Multipass では、外部サイトがパスワードを照合し、顧客情報をJSONにまとめ、暗号化して署名したトークンを作り、Shopifyへ送ります。Shopifyはそのトークンを信じてログインさせます（アカウントがなければ作ります）。お客様に問いかけるのは外部サイトだけでした。

独自IdP接続では、お客様はまずShopifyに来ます。Shopifyが外部のIdPへ「この人を認証してください」と依頼し、IdPが認証を済ませてIDトークンを返します。渡すのは「認証済みという主張」ではなく「認証してくださいという依頼」で、答えを返すのがIdP側になります。

Shopifyの機能比較ページも、従来のお客様アカウントは「Multipass which doesn't support SSO」、新しいお客様アカウントは「any OAuth2.0 + OIDC-compliant identity provider」と対比して説明しています。サイト・アプリ・ストアフロント・チェックアウトを横断してログイン状態を共有できる、という位置づけです。

図② Multipass と独自IdP接続の違い　登場人物は同じで、矢印の向きが逆になります。

図③ Multipass でのログインの流れ（従来）　パスワードを照合するのは外部サイトです。Shopifyはお客様に何も問いかけません。

図④ 独自IdP接続でのログインの流れ　ログイン画面はIdP側が出します。Shopifyはパスワードを受け取りません。

前提はどう変わるのか

Shopify Plus が必要な点は変わりません。変わるのは、外部サイト側に求められるものです。

項目	Multipass	独自IdP接続（OIDC）
対象プラン	Shopify Plus	Shopify Plus
対象アカウント	従来のお客様アカウント	新しいお客様アカウント
外部サイトに必要なもの	署名トークンを作れること	OIDC準拠のIdPであること
顧客の突合	メールアドレス	`email` と `sub`
顧客情報の受け渡し	トークンに載せる	クレームインポート

「OIDC準拠であること」は、思ったより具体的な要求です。項目の全体は要件ページにあり、そのまま会員基盤の開発元へ送れる形にしてFAQの最後に並べました。非エンジニアの方が押さえておく価値があるのは、そのうち2つです。

ひとつは、ログアウトの規格（RP-Initiated Logout 1.0）への対応が必須であること。自社で作り込んだ会員基盤は、ログイン側は実装していてもログアウト側は持っていないことがあります。もうひとつは、3つの窓口が1秒以内に応答する必要があること。超えるとログインが失敗します。古い会員基盤には現実的な壁になります。

会員基盤がIdPになっていない場合

多くの場合、外部サイトの会員基盤は「ログイン画面とパスワード照合を自前で持っているだけ」で、IdPとしては振る舞えません。選択肢は2つです。会員基盤そのものをIdPに作り替えるか、認証だけを担うサービス（IDaaS。ログインの部分だけを預かるクラウドサービス）を会員基盤の前に置き、会員データは自社に置いたまま入り口だけを差し替えるか。後者は工期が短い代わりに、月額費用が会員数に比例します。

具体的にどの製品が候補になるかは、よくある質問の「どのIdPが使えますか」に挙げました。

`email` と `sub` で突合される、ということ

Shopifyは、IDトークンの email と sub で顧客を特定します。sub（subject）とは、IdPがその人に発行する変わらないIDのことです。メールアドレスは変わりうるので、それとは別に「同じ人である」ことを示す番号を持っておく、という考え方です。

ここから2つのことが言えます。ひとつめは、会員基盤の中でメールアドレスが重複していると、そこで詰まることです。同じメールアドレスの会員が2件あるとShopifyはどちらの顧客か決められません。数万件規模の名寄せはそれ自体が数か月の仕事になるので、移行計画のいちばん長い工程として先に見積もってください。

ふたつめは、IdPを作り直すと sub も変わることです。会員は「The sign-in method you used doesn't match this account.」というエラーで入れなくなります。復旧はできますが、管理画面で顧客を開いて Unlink を押す手作業で、まとめて紐付け直す手段は公式にありません（顧客の情報や注文は消えません）。作り直さない前提で設計してください。

顧客情報はクレームで渡せる。ただし毎回上書きされうる

IDトークンには顧客の属性も載せられます。これをクレームと呼び、Shopifyは受け取った値を顧客項目に書き込みます。公式の対応表は次のとおりです。

クレーム	Shopifyの顧客項目
`given_name` / `family_name`	名 / 姓
`phone_number`	電話番号（E.164形式）
`address`	住所
`urn:shopify:customer:addresses`	住所（複数）
`urn:shopify:customer:tags`	タグ

ただし、渡せるかどうかは製品にもよります。Shopify公式の Amazon Cognito 連携ガイドには、標準の address スコープには対応しないと明記されています。住所を渡すには独自クレーム urn:shopify:customer:addresses を組み立てる作りが必要で、「クレームインポートがあるから住所も自動で入る」とは限りません。

もうひとつ注意したいのは、取り込みが初回だけではないことです。

項目	挙動
同期そのもの	管理画面のトグルで、まとめて切れる
同期のタイミング	有効にしていると、お客様がログインするたび
上書きルール	「既存の顧客データを上書きしない（空のフィールドのみ更新）」か「既存の顧客データを上書きする」の2択
メールアドレス	突合のキーなので、アカウント作成時にしか同期されない

設定は Settings > Customer accounts > Authentication > Manage > Identity provider > Manage providers にあります。「上書きする」にしたままだと、Shopifyの管理画面で顧客情報を直しても、次のログインでIdP側の値に戻ります。

とくに注意が要るのはタグです。上書きすると、その顧客のタグは1件ずつではなく全件まとめて置き換わります。セグメント配信や優良顧客の出し分けをタグで運用している場合、IdPから送っていないタグは消えます。氏名や住所も、項目ごとではなく「氏名なら姓と名」「住所なら1件分」のまとまりで置き換わります。IdPとShopifyのどちらを正とするかを、接続する前に決めてください。

図⑤ 管理画面「顧客データの同期」の設定

お客様のログイン体験はどう変わるのか

まず、ログイン画面がIdP側のものになります。デザインも文言もIdPの画面です。お客様から見れば「ログインを押したら別の画面に飛ばされた」という体験で、見た目が変わればそこで離脱します。ロゴ・配色・ドメインをどこまで揃えられるかは製品によって差があるので、IdPを選ぶ段階で確かめておく項目です。

次に、パスワードです。選択肢は2つあります。ひとつは、切り替えのタイミングで全員に再設定をお願いする方法。確実ですが、一斉メールに反応しなかったお客様はログインできないまま離脱します。

もうひとつは、初回のログインだけ旧会員基盤に問い合わせて照合し、成功したらそのパスワードを新しいIdPに引き継ぐ方法です。お客様はいつもどおりのIDとパスワードで入れて、2回目からは新しいIdPだけで完結します。Amazon Cognito には初回ログインで自前の処理を挟むためのフックが用意されており、他のIdPでも同等の仕掛けを持つものがあります。ただし旧基盤に問い合わせて照合する処理そのものは自分で作ります。「一斉再設定は避けられない」と思い込む前に確認してみてください。

ここで誤解されやすいのが、パスワード方針との関係です。移行を機に「最低8文字・記号必須」へ上げたくなりますが、引き継ぎのときに新しい方針は適用されません。Amazon Cognito の公式ドキュメントには、移行では方針を強制せず、方針を満たさないパスワードもそのまま受け入れると明記されています。つまり方針を上げても引き継ぎは止まりませんが、既存のお客様は弱いパスワードのまま入れます。弾いて再設定させたいなら、その判定を自分で実装することになります。いつ誰に再設定をお願いするかは、移行とは別に決める話です。

図⑥ 既存のパスワードを引き継ぐときの流れ　移行はお客様がログインした順に進みます。ログインしないお客様は移りません。

実際に組んでみて分かったこと

接続そのものは、難しくありません。Shopifyには手順書があり、Test connection で試せます。世の中で「IdPを繋ぐだけ」と言われるのは、この部分だけを見た話です。

難しいのは、繋いだあとです。何を正とし、誰がどのデータを持ち、既存のお客様がどう入り直すかを、ひとつずつ決めることになります。当社が Amazon Cognito で検証して分かった、事前に決めておかないと後戻りする点を挙げます。製品の欠点ではなく、IDを預かる基盤として安全側に倒した結果と考えられるものが多く、他のIdPにも似た制約があります。自社の候補製品ではどうかを確認する手がかりとして読んでください。

画面と文言でつまずくこと

ログイン画面の文言は変えられないことがあります。 Cognito の新しいログイン画面は既定が英語で、URLに ?lang=ja を付ければ日本語になります。ただし文言そのものは編集できません。そもそもこの画面と日本語化を使うには上位のプランが必要で、下位のプランでは旧来の画面しか選べません。AWSはこの制約の理由を公表していませんが、認証画面の文言を自由に書き換えられれば偽の警告文を出すような細工の余地が生まれるため、安全側に倒しているのだと考えています。

エラーの文言が英語のまま出ることがあります。 当社の検証では、ログインの失敗は日本語になるのに、新規登録の入力チェックだけ英語のままでした（?lang=ja を付けても変わりません）。会員が入力を間違えたときに英語のメッセージが出るのは、そのまま出すには厳しい体験です。日本語で伝えたいなら、登録を受け付ける前に自分で判定して弾く必要があります。ここは自社で作る部分が増えます。

データでつまずくこと

IdP接続は、データを移す仕組みではありません。ここがいちばん誤解されます。Shopifyは会員の一覧を受け取りません。お客様が初めてログインした瞬間に、1人ずつ、IDトークンの email で突合され、居なければその場で作られます。つまりログインしないお客様は、いつまでもShopifyに現れません。切り替え前にShopifyへ顧客を揃えておきたいなら、IdPとは別に、Admin APIで投入する工程を設計することになります。認証の配線とデータの移行は、別の仕事です。

クレームインポートは万能ではありません。 IDトークンに載ったクレームは顧客項目へ取り込まれますが、載せるのはIdP側の仕事です。とくに Cognito の場合、Shopifyの公式ガイドに標準の address スコープには対応しないと明記されています。住所を渡すには独自クレーム urn:shopify:customer:addresses を組み立てる作りが必要で、しかもそれはログインのたびに1秒以内で動く処理になります。

メールアドレスは、アカウントを作るときにしか同期されません。突合のキーだからです（Shopify公式）。つまりIdP側でお客様がメールアドレスを変更しても、Shopifyの顧客には反映されません。メールアドレスの変更画面と、その変更をShopifyへ流す経路を、どちらも自分で用意することになります。氏名や住所とは扱いが違う点に注意してください。

移行の進み方でつまずくこと

IdP側の必須項目は、あとから変えられないことがあります。 Cognito では、登録時に必須にする項目をあとから増やせず、変更にはユーザープールごとの作り直しが要ります。作り直せば sub も変わるので、実質的に一度きりの決定です。本番の基盤を作る前に、登録時に何を必須で聞くかを決めてください。

会員IDでログインさせている場合は、別の入り口の設計が要ります。 「会員番号でログイン」という運用は珍しくありませんが、Shopifyへ渡せる会員の見分け方はメールアドレスだけです（内部的には sub も使われますが、これはIdPが振る番号で会員は入力しません）。会員IDとメールアドレスのどちらを入力されても同じ人にたどり着けるよう、IdP側で設計しておく必要があります。

既存のお客様が「新規登録」に進む経路は、ふさぐ必要があります。 ログイン画面には、たいてい新規登録への導線があります。まだ移行していないお客様がそこから登録すると、旧会員とは別のアカウントができ、本人は気づかないまま購入履歴もポイントも見えない状態になります。「ログインできない」「履歴が消えた」という問い合わせが最も出やすいのがここです。登録時に既存会員かどうかを照合して止める処理を、切り替えと同時に入れてください。

移行の速さは、お客様のログイン頻度で決まります。パスワードを引き継ぐ方式では、旧会員基盤への問い合わせは初回ログインのときだけ起きます。裏を返すと、年に一度しか買わないお客様は、一年経つまで移りません。旧基盤をいつ止められるかは自社では決められず、移行率を見ながら判断することになります。さらに切り替えた直後は初回ログインが集中するため、旧基盤側の処理数の上限を先に確認しておく必要があります。

進め方の目安

いちばん大事なのは、アカウントの切り替えとIdPの稼働を同じ瞬間に揃えることです。Multipass は新しいお客様アカウントでは使えません。ですから移行だけ先に済ませてしまうと、IdPを繋ぐまでの期間、外部サイトからのSSOが切れます。お客様は自社サイトでログインしたのに、Shopify側ではまたログインを求められる状態になります。

順番はこう組めます。Shopifyのアップグレード手順は9段階あり、8段階目までは準備とテストで、オンラインストアとチェックアウトは従来のお客様アカウントに繋がったままです。IdPの接続には Test connection が用意されていて、この期間に繋いで試せます。切り替えは9段階目の1回だけで、そこで Multipass が止まり、IdPに替わります。

決めることは実質1つです。いまの会員基盤を、そのままIdPとして使えるか。使えるならOIDCの窓口を足すだけで済みます。使えないなら、会員基盤をIdPに作り替えるか、IDaaSを前に置く工程が先に入ります。ここは自社では答えにくい問いなので、会員基盤を作った相手に聞くことになります。何を聞けばよいかは、よくある質問の最後に一覧にしました。

図⑦ 切り替えの瞬間に、IdPの稼働を揃える　③までは従来のお客様アカウントが動いたままです。切り替わるのは④の1回だけです。

なお、移行後30日以内であれば従来のお客様アカウントに戻せます。ただし公式に書かれているのは「You can revert within 30 days.」の一文だけで、戻したときに何が保たれるかまでは記載がありません。戻せることを前提に走らず、戻さずに済む段取りを組んでください。

マイページの画面そのものをどう移すかは、別の記事で扱っています。あわせてご覧ください。

よくある質問

既存のお客様はどうなりますか

メールアドレスで突合されるので、同じメールアドレスであれば同じ顧客として扱われます。逆に言えば、会員基盤側でメールアドレスが重複していたり、Shopify側と違うメールアドレスが登録されていたりすると、そこで別人として扱われます。切り替え前に、両者のメールアドレスを突き合わせておくことをおすすめします。

ログイン体験はどう変わりますか

ログイン画面がIdP側の画面になります。パスワードの引き継ぎ方によっては、お客様はこれまでどおりのIDとパスワードで入れます。引き継がない場合は、切り替えのタイミングで再設定をお願いすることになります。

いつまでに動くべきですか

従来のお客様アカウントの終了日は、2026年9月時点でまだ発表されていません。2026年内に発表される予定です。ただし、非推奨になった時点で機能改善と技術サポートの提供は止まっているため、終了日の発表を待つ理由はありません。会員数が多いほど、メールアドレスの重複解消やテストに時間がかかります。

Multipassの代替となる新しいAPIを待つべきですか

2026年9月時点で、代替APIの提供予定は発表されていません。発表されていないものを待つ計画は立てられないため、独自IdP接続を前提に検討することをおすすめします。

Shopify Plus ではない場合はどうすればいいですか

独自IdP接続は Shopify Plus 限定です。Plus以外のプランでは、外部サイトとのSSOという形は取れません。新しいお客様アカウントの標準のログイン（ワンタイムコード）を使いつつ、マイページの中身をどう見せるかで工夫することになります。この点は、マイページ移行の記事のほうで詳しく扱っています。

新しいお客様アカウントへの移行と、IdP接続は同時にやるべきですか

Multipass をお使いなら、同時にすべきです。Multipass は新しいお客様アカウントでは使えないため、移行だけ先に済ませると、IdPを繋ぐまでの期間は外部サイトからのSSOが切れます。

幸い、Shopifyのアップグレード手順は準備とテストが8段階目まで続き、その間オンラインストアとチェックアウトは従来のお客様アカウントに繋がったままです。IdPの接続にも Test connection があります。準備段階で繋いで試しておき、9段階目のアップグレードで一度に切り替えるのが、SSOの途切れない進め方です。

どのIdPが使えますか

Shopifyが公式に接続手順を公開しているのは次の4つです（2026年9月時点）。手順書があるぶん、立ち上がりが早くなります。

製品	提供元
Amazon Cognito	Amazon Web Services
Auth0	Okta
Okta	Okta
Microsoft Entra ID	Microsoft（一般消費者向けは Entra External ID）

それ以外の製品や自社構築のIdPでも、要件ページの条件を満たせば接続できます。参考として、OpenID Foundation の認定を OpenID Provider として受けている製品の例を挙げます。

製品	位置づけ
Keycloak	オープンソース。自前で立てて運用する
Authlete	日本の製品。いまの会員基盤をIdPに仕立てる部品として使う
IBM Security Verify	大規模向けの認証基盤
Ping Identity	同じく大規模向け。2023年に ForgeRock を統合

認定は特定のバージョンに対して与えられるもので、最新版が認定済みという意味ではありません。そしてこの認定はOIDCに準拠していることの証明で、Shopifyの要件を満たすことの証明ではありません。ログアウトの規格や1秒以内の応答は別に確かめる必要があり、Shopifyの公式手順書がないぶん、検証の手間はこちら側で持つことになります。候補があるなら、まず要件ページと突き合わせてみてください。

会員基盤を作った相手に、何を聞けばいいですか

そのまま送れる形にしました。3つめの問い（会員基盤はIdPになれるか）に答えるための一覧です。

OpenID Connect の認可コードフローに対応していますか（implicit と hybrid では接続できません）
RP-Initiated Logout 1.0 に対応していますか（Back-Channel / Front-Channel では接続できません）
ディスカバリー（設定一覧を返すURL）を公開できますか
トークン・ディスカバリー・ユーザー情報の各エンドポイントは、1秒以内に応答しますか
リフレッシュトークンを発行できますか
IDトークンに sub・email・email_verified を載せられますか
会員のメールアドレスは必ず1件で、重複していないことを保証できますか
氏名・電話番号・住所・タグをクレームとして載せられますか（電話番号は E.164 形式、都道府県と国は ISO コード）

「できない」が返ってきた項目が、会員基盤を作り替えるか、認証だけを別のサービスに任せるかの判断材料になります。

自社の会員基盤がそのままIdPになれる場合、どれくらい楽になりますか

認証の側は、かなり楽になります。パスワードが動かないので、引き継ぎの実装も一斉再設定も要りません。お客様が初回ログインのときに1人ずつ移っていく構造そのものが無くなり、切り替えた初日から全員がログインできます。旧会員基盤を止める判断も要りません。ログイン画面も登録時の必須項目も自社のものなので、この記事で挙げたマネージドなIdP特有の制約も当てはまりません。

一方で、データの側は何も楽になりません。Shopifyは会員の一覧を受け取らないため、切り替え前に顧客を揃えたいなら Admin API で投入する工程は残ります。メールアドレスの重複は突合のキーそのものの問題なので、名寄せも残ります。クレームの設計、氏名や住所をどちらの正とするか、メールアドレスの変更をShopifyへ反映する経路、既存のお客様が新規登録に進む経路をふさぐ処理も、そのままです。

難しさは「認証を繋ぐこと」ではなく「データの持ち主を決めること」に寄っている、と捉えていただくのが実態に近いと思います。

IdPの費用はどれくらいかかりますか

多くの製品が MAU（月間アクティブユーザー。その月にログインした人数）での従量課金です。会員数がそのまま毎月のコストになる、という構造を押さえておいてください。2026年9月時点の公開単価から単純計算した、会員5万人規模の月額の桁は次のとおりです。無料枠・割引・為替は含みません。

製品	課金の考え方	5万MAU/月の目安
Amazon Cognito（Essentials）	$0.015 / MAU	$750
Microsoft Entra External ID	5万MAUまで無料、以降は従量	$0（日本国内に保存する場合は追加費用）
Auth0（B2C Essentials）	MAUの段階別の月額	$3,500

同じ会員数でも製品によって数倍の差が出ます。最新の金額は各社の価格ページでご確認ください。

まとめ

Multipass が廃止されるのではなく、土台である従来のお客様アカウントが終わります。見るべき期日は従来のお客様アカウント側です
主導権がShopifyからIdPへ渡ります。自社の会員基盤がOIDCのIdPとして振る舞えるかが、いちばん大きな分かれ目です
あとから変えられない決めごと（必須項目、ログインの識別子、突合のキー）が作業の前に来ます。動き出す前に決めてください。メールアドレスの名寄せは、いちばん早く着手すべき工程です

移行の進め方や、自社の会員基盤が要件を満たすかの判断でお困りでしたら、お問い合わせよりご相談ください。

参考資料

本記事の情報は2026年9月時点のものです。Shopifyの仕様および各サービスの料金は変更される場合があります。最新の情報はShopifyの公式ドキュメントおよび各サービスの公式ページをご確認ください。