メインコンテンツまでスキップ

Shopify

Overview​

Shopifyは、ECサイト（オンラインストア）を構築・運用するためのSaaSプラットフォーム。
ホスティング、決済、在庫管理、注文管理などを一体的に提供し、開発者・事業者ともに迅速なEC構築が可能。

  • フルマネージドSaaS（インフラ管理不要）
  • テンプレート + カスタム開発（Liquid）
  • 豊富なアプリエコシステム
  • グローバル対応（多通貨・多言語）
  • 決済（Shopify Payments）統合

アーキテクチャ概要​

フロントエンド​

  • テーマベース（Liquid）
  • Hydrogen（ReactベースのHeadlessフレームワーク）
  • Storefront API（GraphQL）

バックエンド​

  • Shopify Admin API（REST / GraphQL）
  • Webhookベースのイベント連携
  • App（外部サーバー）での拡張

Shopify Partner​

Shopify Partnerは、Shopifyのエコシステムに参加するためのプログラム。

主な役割​

  • アプリ開発者
  • テーマ開発者
  • 制作会社（Agency）
  • フリーランス開発者

提供機能​

  • 開発ストア（Development Store）
  • アプリ公開（Shopify App Store）
  • テーマ公開（Theme Store）
  • 売上シェアモデル（Revenue Share）

収益モデル​

  • アプリ課金（サブスク / 従量課金）
  • テーマ販売
  • クライアントワーク（構築・運用）

開発パターン​

1. テーマカスタマイズ​

  • Liquid + HTML + CSS + JS
  • 既存テーマを拡張
  • 小規模〜中規模向け

2. Shopify App開発​

  • Node.js / Ruby / Python などで構築
  • Admin API / Webhookを利用
  • 外部DBと連携

3. Headless Commerce​

  • フロント：Next.js / React
  • バックエンド：Shopify（API利用）
  • 高度なUI/UXが必要な場合に採用

API一覧​

API名用途
Admin API商品・注文・顧客管理
Storefront APIフロント用データ取得
Webhookイベント通知
GraphQL API高効率なデータ取得

Shopify CLI​

ローカル開発を効率化するツール。

  • テーマ開発
  • アプリ開発
  • ローカルプレビュー
  • デプロイ

セキュリティ・認証​

  • OAuth 2.0（アプリ認証）
  • APIキー / アクセストークン
  • Webhook署名検証（HMAC）

外部認証（ブランド共通ID）連携​

Shopifyの標準認証を、企業側が提供するブランド共通ID（外部認証基盤）に統合したいケースは多い。
ただし、Shopifyは認証基盤を完全に置き換えることはできず、「SSO連携」または「Headless構成による制御」が前提となる。

備考

Shopifyはセッションが切れた場合に、自動的に企業独自の認証システムにリダイレクトする機能を提供していない。
そのためセッションが切れた時にユーザーを企業独自の認証システムにリダイレクトさせるためには Liquid などを使用してリダイレクトの設定を行う。
リダイレクトの設定を行うには、ユーザーがどのページに遷移する際に、企業側の認証システムを経由させるか設計を行うことが重要

前提制約​

  • Shopifyのネイティブ認証（メール / パスワード）は完全には無効化できない
  • OAuth / OpenID Connect を直接差し替える仕組みは標準では提供されていない
  • Checkout周りは特に制約が強い

実現パターン​

1. Multipass（Shopify Plus限定）​

外部で認証済みのユーザーをShopifyへシームレスにログインさせる仕組み。

フロー

  1. 自社認証基盤でログイン
  2. Multipassトークンを生成（暗号化）
  3. Shopifyへリダイレクト
  4. 自動ログイン

特徴

  • テーマ構成でも利用可能
  • 実装コストが比較的低い

制約

  • Shopify Plusプランが必須

2. Customer Account API + 外部認証（推奨）​

Headless構成で、認証を完全に外部に寄せる方法。

構成

  • フロントエンド：Next.jsなど
  • 認証：OIDC / OAuth2（自社ID基盤）
  • Shopify：Customer Account API / Storefront API

フロー

  1. 外部IDでログイン
  2. トークン取得（id_token / access_token）
  3. Shopify Customerと紐付け
  4. Storefront API経由でセッション生成

特徴

  • 認証UXを完全に統一可能
  • 拡張性が高い

制約

  • Headless構成が前提
  • 実装コストが高い

2026年時点のShopify SSO事情​

Multipass APIの現状​

  • ステータス: 非推奨 (Deprecated)

  • 利用期限: 2026年後半に完全廃止予定（Shopify公式よりアナウンス済み）

  • 制限: 2026年2月以降、新規ストアでの利用は不可。既存のShopify Plus利用ストアのみ、廃止日まで維持モードで動作

次世代のSSO：OIDC連携 (推奨)​

Multipassの直接的な後継として、Shopifyは「外部Identity Provider (IdP) とのOIDC連携」を標準機能として提供開始した。

  • 仕組み: Auth0, AWS Cognito, Azure AD, または独自の会員基盤（OIDC準拠）をShopifyと直接連携させる
  • メリット: 独自トークンの生成（Multipassの手法）が不要
    • 業界標準の OIDC / OAuth 2.0 をそのまま利用可能
    • セキュリティが強化され、Shop PayやB2B機能との相性が良い
  • 要件: 引き続き Shopify Plusプラン が必要

SSO実装の比較（旧 vs 新）​

項目旧：Multipass (〜2026)新：OIDC連携 (2026〜)
ベース技術独自トークン（AES/HMAC）OIDC (OpenID Connect)
実装の難易度暗号化の実装が必要でやや高い標準プロトコルなのでライブラリが豊富
拡張性Shopify内に限定されるモバイルアプリ等、他プラットフォームと共有しやすい
将来性廃止予定Shopifyの推奨規格

IdP × Shopify 連携フロー（OIDC）​

IdP（Identity Provider）、ShopifyをRP（Relying Party）とした標準的な認可コードフローの実装。

1. 登場人物と役割​

  • IdP: ユーザー認証（Google/X/Apple連携含む）を行い、認可コードとJWTを発行する。
  • RP (Shopify Plus): 新規サービス。サイトを信頼し、受け取ったJWTで顧客をログインさせる。

2. 認証シーケンス（認可コードフロー + State検証）​

  1. 認可リクエスト: ユーザーがShopify上の「ログイン」をクリック。Shopifyが一意の state を生成し、IdPの認可エンドポイントへリダイレクト。
  2. 認証・認可: ユーザーがSNS経由でログイン。サイトがShopifyの redirect_uri に対し、code (Grant Code) と送信された state を付けて戻す。
  3. State検証: Shopify側で戻ってきた state が発行したものと一致するか検証（CSRF対策）
  4. トークン交換: Shopify（バックエンド）が code を使い、IdPのトークンエンドポイントから JWT (IDトークン/アクセストークン) を取得。
  5. ログイン完了: ShopifyがJWT内の sub (ユーザー一意識別子) や email を確認し、Shopify内の顧客データと紐付けてログイン状態にする。

3. Shopify Plusにおける実装の勘所​

  • New Customer Accounts: 2026年現在の推奨。管理画面の「Settings > Customer accounts」から、自社OIDCを外部Identity Providerとして登録する。
  • API連携: 取得したJWT（アクセストークン）をフロントエンドで保持すれば、Shopifyで買い物中も、裏側で同じAPIからユーザーリソース（推しマークやポイント等）を取得可能。

OIDCにおける「同意の連鎖」とプライバシー​

なぜSNSログイン（Google等）の同意だけでは不十分なのか？​

ユーザー視点では「一度同意した」と感じるが、システム（OIDC）の裏側では「情報の受け渡し先」が異なるため、ステップごとの同意が必要になる。

1. 信頼のピラミッド（情報の流れ）​

  1. 第一段階 (Google ➔ IDP):
    • ユーザーはGoogleに対し「IDPというサービスに私のメアドを教えていいよ」と許可する。
    • 結果: IDP内に会員データが作成される。
  2. 第二段階 (IDP ➔ Shopify):
    • ユーザーはIDPに対し「Shopifyという新しいサービスに、私の会員データを渡していいよ」と許可する。
    • 結果: Shopify内に顧客データ（Customer/CompanyContact）が作成される。

ポイント: GoogleはShopifyの存在を知らないため、IDPが「家主」として、新しく来たShopifyに対して情報を渡す許可を住人（ユーザー）に取る義務がある。

2. 同意画面（Consent UI）の実装意義​

実装者が「LINEのようなUIが必要」と言っているのは、以下の3点を保証するため。

  • 透明性: ユーザーが「今、自分のデータがどこに流れているか」を自覚できる。
  • 拒否権: 特定のサービス（例：Shopify）にだけは情報を渡したくない、という選択を可能にする。
  • 責任の所在: もしShopify側で問題が起きた際、IDPは「ユーザーの明示的な同意に基づいてデータを渡した」というログ（エビデンス）を保持できる。

3. ユーザー体験（UX）への配慮​

  • 初回のみ: OIDC Provider（oidc-providerライブラリ等）は、一度同意した事実をデータベース（今回のPRではDynamoDB）に保存する。
  • 二回目以降: すでに同意済みであれば、同意画面をスキップして即座にShopifyへリダイレクトさせる（これこそが真のSSO体験）。

コーチのまとめメモ​

「SNSの同意」はIDPのためのもの。「今回の同意」はShopifyとの絆を作るための儀式。 一度結んでしまえば、次からは意識せずにスイスイ通れるようになる！

Resource​