Themes / Theme Store 要件変更

shopify-account コンポーネントが
Theme Store の「必須要件」になった

2026年7月30日より、Theme Store に提出する新規テーマ+既存テーマの更新は、ヘッダーに shopify-account コンポーネントを含み、デスクトップ/モバイル両方で表示されている必要がある。あわせてレガシー顧客アカウントは非推奨となり、そのテンプレートファイルの同梱義務は無くなった。

このページの構成
  1. 何が変わったのか(30秒で理解)
  2. shopify-account コンポーネントとは
  3. 図解 : サインインから account メニューまでの流れ
  4. 必須になった条件(3つ)
  5. Before / After 比較
  6. レガシー顧客アカウントの非推奨化
  7. テーマ提出前チェック(3ステップ)
  8. 技術者が押さえるべき5つのポイント
  9. 業務に活かせる3つのユースケース
  10. 提案で使える1行サマリ

1何が変わったのか

2026年2月に登場した shopify-account コンポーネントが、Theme Store 提出テーマの必須要件に昇格した。
対象は 新規テーマ既存テーマのアップデート の両方。ヘッダーに入れ、デスクトップとモバイルの両方で見える状態にする必要がある。

置き場所は「ヘッダー」

テーマのヘッダーに shopify-account を含めること。設置場所が明示的に指定されている。

両デバイスで「表示」

desktop / mobile どちらでも visible であること。片方だけ、あるいはハンバーガー内に隠すだけでは要件を満たさない。

レガシーテンプレは義務解除

レガシー顧客アカウントが非推奨となり、そのテンプレートファイルをテーマに含める要件は無くなった。

この変更が効くのは Theme Store に提出するテーマの審査要件。すでに公開中のテーマに対する猶予期限・移行デッドライン・未対応時の扱いは、記載なし。ただし「既存テーマのアップデート」も対象なので、次にアップデートを出すタイミングで実質的に必須になる。

2shopify-account コンポーネントとは

2026年2月に導入された、ストアフロント上で顧客がサインインし、自分のアカウントを操作できるコンポーネント。記事に明記されている機能は次の3つ+1。

パスワードレス
passwordless sign-in に対応
Sign in with Shop
自動認識(automatic recognition)
ソーシャルログイン
social sign-in providers 対応
アカウントメニュー
サインイン後、各アカウントページへ
コンポーネントの属性・Liquid での記述方法・カスタマイズ可能な範囲は、この告知には 記載なし。実装詳細は developer docs(フッターのリンク参照)で確認すること。

3図解 : サインインから account メニューまでの流れ

顧客 ストアフロント上 header shopify-account ヘッダーに常設 desktop / mobile 両方 クリックでサインイン サインイン手段 パスワードレス Sign in with Shop(自動認識) ソーシャルサインイン 記事に明記された3方式 アカウントメニュー 各アカウントページへ遷移

※ 図は記事の記述(ストアフロント上でサインイン → サインイン後は account メニューからアカウントページへ到達)を可視化したもの。内部の認証シーケンスやトークンの扱いについては記載なし。

4必須になった条件(3つ)

#要件判定ポイント
1 shopify-account コンポーネントを含む 必須 独自実装のログインリンクでの代替は要件として挙げられていない
2 設置場所は header 必須 フッターやアカウントページ内だけ、は不可
3 デスクトップとモバイル両方で visible 必須 レスポンシブで片方が消える実装は要注意

対象になるテーマ提出

対象

新規テーマの提出

これから Theme Store に出す新作テーマ。最初から header に組み込んでおく。

対象

既存テーマのアップデート提出

公開中テーマでも、アップデートを提出する時点で要件を満たす必要がある。「新規のみ」ではない点が重要。

5Before / After 比較

項目これまで2026年7月30日以降
shopify-account 任意 2026年2月導入、使うかは自由 必須 header に含めること
表示デバイス 制約なし desktop + mobile 両方 で visible
レガシー顧客アカウント テンプレートファイルの同梱が要件 非推奨 同梱要件は撤廃
サインイン体験 テーマごとにバラバラ どのテーマでも一貫した体験(記事の狙い)
猶予期間・移行期限 記載なし

6レガシー顧客アカウントの非推奨化

テンプレートの同梱義務が消えた

レガシー顧客アカウント用テンプレートファイルをテーマに含める必要は無くなった。テーマのファイル構成をその分スリムにできる。

削除の可否は自己判断が必要

「含める要件が無くなった」=「即削除して安全」とは書かれていない。既存ストアがレガシーアカウントで運用中の場合の影響については 記載なし。削除前に実ストアでの利用状況を確認すること。

方向性はシンプル : 顧客アカウントは「新(customer accounts + shopify-account)」に一本化。テーマ側は独自のログイン UI を持たず、Shopify 提供コンポーネントに寄せる流れ。

7テーマ提出前チェック(3ステップ)

1

header に組み込む

テーマのヘッダーに shopify-account コンポーネントを配置する。

2

両ブレークポイントで確認

デスクトップ幅とモバイル幅の両方で実際に見えるか目視する。

3

レガシーテンプレを棚卸し

レガシー顧客アカウント用テンプレの要否を判断してから提出。

審査での具体的なチェック方法・自動 lint の有無・リジェクト時のメッセージ内容は 記載なし。Theme Store requirements のページ(フッターのリンク)を提出前に必ず読み直すこと。

8技術者が押さえるべき5つのポイント

1. 「含める」だけでなく「見える」まで要件

requirement の文言は include ... in their header, visible on both desktop and mobile。DOM に存在していても CSS で片方非表示なら趣旨に反する。レスポンシブ時にヘッダーアイコンを間引く設計は要見直し

UPDATE

2. 既存テーマも「更新提出」で捕まる

新規テーマだけの話ではない。updates to existing themes も対象なので、バグ修正1件のアップデートを出すつもりでも、先に shopify-account 対応が必要になる。改修計画の順序に影響する。

3. 認証方式は自前実装しない

パスワードレス・Sign in with Shop の自動認識・ソーシャルサインインは、いずれもコンポーネント側の提供機能。テーマ側で独自ログインフォームを作り込むと、要件充足と二重管理の両方で損をする。

4. レガシーテンプレの整理タイミング

同梱義務が消えたので、テーマのファイル数・保守対象を減らせる。ただし削除は要件ではない。「消してよい」ではなく「持たなくてよい」と読むのが安全。

5. 「テーマの差別化」から「共通体験」へ、境界が動いた

記事の目的は customers get a consistent experience on any device。つまり Shopify はアカウント周りの UI をテーマの自由裁量から外し、プラットフォーム側の共通部品に寄せている。今後のカスタムテーマ設計では「どこまでが自由にいじれる領域か」を都度 Theme Store requirements で確認する前提になる。なお、コンポーネントのスタイリング自由度・カスタマイズ可能範囲は本記事には 記載なし

9業務に活かせる3つのユースケース

USE CASE 1

Theme Store 出品テーマの「アップデート前 棚卸し」

課題
公開中テーマに小さな改修を入れて提出しようとしたら、shopify-account 未対応でリジェクトされる。改修のリードタイムが読めなくなる。
打ち手
次のアップデート提出より前に、① header への shopify-account 組み込み、② desktop/mobile 両方での表示確認、③ レガシー顧客アカウントテンプレの要否判断、をまとめて1本のリリースにする。
効果
以降のアップデートを要件ブロックなしで出せる。細かい修正を出すたびに審査で止まる事故を防げる。
技術メモ
「updates to existing themes」も対象。ヘッダーのアイコン群をモバイルで間引いている実装は特に要確認。
USE CASE 2

カスタムテーマ案件で「独自ログイン UI」を捨てる判断材料に

課題
クライアント案件で作り込んだ独自のログイン/会員メニューがあり、パスワードレスやソーシャルログインの追加要望が来るたびに実装コストが積み上がる。
打ち手
shopify-account コンポーネントへの置き換えを提案。パスワードレス・Sign in with Shop 自動認識・ソーシャルサインインは標準で載っていることを根拠に、自前実装の廃止を合意する。
効果
認証まわりの保守対象が減り、Shopify 側の機能追加を自動で享受できる。Theme Store 要件化=プラットフォームの標準路線という説得材料も使える。
技術メモ
ただしデザイン改変の自由度は本記事に記載なし。ブランド要件が厳しい案件では、docs でカスタマイズ範囲を先に確認してから合意すること。
legacy new ファイル数が減る
USE CASE 3

レガシー顧客アカウント残存ストアの移行アセスメント

課題
運用中の複数ストアが、いまだレガシー顧客アカウントのテンプレートを抱えたまま。非推奨化のアナウンスが出たが、どこから手を付けるか判断がつかない。
打ち手
① 各ストアのテーマでレガシーアカウントテンプレの有無と実利用を洗い出す → ② shopify-account 導入済みかを確認 → ③ 未導入ストアを優先度付けして移行計画に載せる。
効果
非推奨機能への依存を可視化し、突然のリジェクトや将来の廃止に備えられる。テーマの保守ファイル数も削減できる。
技術メモ
レガシー顧客アカウントの完全停止時期・移行手順の詳細は本記事に記載なし。「Legacy customer accounts are deprecated」の公式ドキュメントを一次情報として当たること。

10提案で使える1行サマリ

「Theme Store に出すテーマは、ヘッダーに shopify-account コンポーネントを入れ、PC・スマホ両方で見えることが必須になった。
新規テーマだけでなく既存テーマのアップデート提出も対象
同時にレガシー顧客アカウントは非推奨となり、そのテンプレート同梱義務は撤廃された。」