Shopifyの2026年12月1日ルールに準拠：セルフサービス返品・交換アプリはCustomer Account APIへの移行が必須

結論： RevizeはすでにBuilt for Shopify認定を受けており、フルフィルメント前のセルフサービス機能でCustomer accounts（顧客アカウント）と連携して機能します。Shopifyが2026年12月1日に設定した要件は、これとは別に、購入者向けのセルフサービス機能を提供する返品・交換アプリに対し、Built for Shopifyステータスを維持するために認証方法としてCustomer Account APIを使用することを義務付けるものです。注文後の変更の92.2%は、サポート担当者を介さず、顧客自身によってセルフサービスで完了されています（Revize、2026年調査）。

この期限が極めて重要なのは、認証プロセスがすべてのセルフサービス返品・交換フローの入口に位置しているためです。 移行に失敗したからといって、すぐにアプリ自体の稼働が停止するわけではありませんが、返品のピークシーズン中にBuilt for Shopifyステータスや購入者の体験が損なわれるリスクがあります。

本ガイドでは、今回の要件の詳細、影響を受けるアプリ、返品管理とフルフィルメント前の注文編集との違いについて解説し、さらに12月1日までにパートナーや制作会社が実施すべき7ステップの監査方法を紹介します。

Built for ShopifyのCustomer Account API要件による変更点

2026年12月1日以降、購入者向けのセルフサービス機能を備えた返品・交換アプリは、Built for Shopifyステータスを維持するために、プライマリ認証方法としてCustomer Account APIを使用する必要があります。 Shopifyは2026年6月17日にこの変更を発表し、該当するアプリデベロッパーに対して約5か月半の移行猶予期間を設けました。

Shopify公式のデベロッパー向けチェンジログによると、この要件はサブスクリプションアプリにも適用されます。返品管理における重要なポイントは購入者向けのセルフサービス機能、つまりストアスタッフを介さずに、顧客自身が返品の申請や管理、交換状況の追跡などの操作を行える機能です。

一部の要約情報から受ける印象に比べると、実際のペナルティは限定的です。Shopifyは非準拠のアプリについて、Built for Shopifyステータスを失うリスクがあると述べています。12月1日になった瞬間に該当するすべてのアプリが動作を停止したり、App Storeから削除されたり、マーチャントの管理画面が機能しなくなったりするわけではありません。

12月1日の期限は、ストアフロントの強制停止日ではなく、アプリベンダーのコンプライアンス期限として捉えてください。 とはいえ、ステータス変更や不十分な認証リリースは、ホリデーシーズンの返品ピーク期に不要なトラブルを引き起こす可能性があるため、パートナーや制作会社は今すぐ対応を進めるべきです。

今回のBuilt for Shopify要件の対象者

対象となるのは、以下の3つの条件すべてを満たすアプリです。「返品」「交換」または「サブスクリプション」カテゴリに属していること、購入者向けのセルフサービス機能を提供していること、そして2026年12月1日以降もBuilt for Shopifyステータスを維持する予定があること。 ストアに導入されているすべてのアプリが対象となるわけではありません。

各購入後アプリについて、以下のチェックリストを用いて判定してください：

• アプリカテゴリの確認： 機能名から判断するのではなく、Shopifyおよびベンダーがそのアプリをどのカテゴリに分類しているかを確認します。

• 購入者向けワークフローの特定： 返品申請、交換追跡、サブスクリプション更新、およびそれらを行う顧客ポータルサイトが含まれます。

• 現在の認証方法の確認： 本番環境において、ShopifyのCustomer Account APIがすでにプライマリ認証方法として使用されているか確認します。

• ベンダーのBuilt for Shopify維持意向の確認： もともとバッジを取得していないアプリの場合、失うバッジはありませんが、運用上、顧客アカウントとの互換性が重要になる場合があります。

• 発送前と発送後のアクションの分類： 未発送の注文を変更することは「注文編集（order editing）」です。発送済みの商品を戻すことは「返品（return）」です。顧客が同様の言葉を使っていても、これらは全く異なるワークフローです。

最後の分類を明確にすることが、監査におけるミスの防止につながります。購入者がサイズ変更を「交換」と呼ぶことがありますが、発送前にバリエーションを変更する場合は、逆ロジスティクス（返品物流）は発生しません。発送後の交換には、返品ライフサイクル、検品処理、そして代替品の再発送プロセスが必要になります。

当社のデータ（1,000万件以上のShopify注文に基づく）によると、チェックアウト後に変更（編集）される注文は約19件に1件（5.2%）です（Revize、2026年）。したがって、制作会社は両方のレイヤーを監査しつつ、12月の新要件についてはShopifyが明示したカテゴリにのみ適用する必要があります。

Customer Account APIの実際の役割

Customer Account APIは、購入者を認証し、該当する購入者のShopifyアカウントデータへの安全なアクセス権限をアプリに付与します。 API（アプリケーション・プログラミング・インターフェース）とは、システム間の通信を制御する窓口です。アプリが認証されたリクエストを送信すると、Shopifyはアクセスを許可されたデータのみを返します。

これは、アプリが基本的にマーチャントに代わって操作を行うAdmin APIとは異なります。ShopifyのCustomer Account APIリファレンスによると、顧客向けのAPIは、注文情報、プロフィール、住所を含む購入者自身の情報を読み取り、更新します。

2026年8月29日現在、Shopifyのリファレンスでは最新バージョンとして2026-07が提示されています。また、検出（discovery）エンドポイントについても記載されており、アプリが特定のドメインをハードコーディングすることなく、ショップごとに正しい認証エンドポイントとGraphQLエンドポイントを取得できるようになっています。

認証とインターフェースの配置は別物です。 Customer Account UI extension（UI拡張機能）は、顧客アカウント内のどこに機能を表示するかを制御します。一方、Customer Account APIは、顧客データへの認証されたアクセスを制御します。アカウントページのデザインが最適化されていても、必要なAPIがプライマリ認証方法として使用されているかどうかをベンダーに確認する必要があります。

制作会社は、開発ベンダーに対して以下の4つの技術的な質問を行い、書面で回答を得てください：

1. 本番環境の購入者フローは、Customer Account APIを通じて認証されていますか？

2. アカウントページ、注文完了メール、ディープリンク、外部ポータルなど、どのエントリポイントでこのAPIが使用されていますか？

3. 移行はすべてのマーチャントに対して適用されていますか、それとも一部のテストグループのみですか？

4. 移行完了の判定後、パートナーダッシュボードにどのような証明が表示されますか？

注意： 「新しい顧客アカウント（new customer accounts）に対応している」という回答だけで安心しないでください。新アカウントのUI表示に対応していることと、今回の認証要件を満たしていることは、関連していますが同じではありません。

12月の監査におけるRevizeの位置づけ

Revizeは「発送前」の顧客セルフサービス領域をカバーするのに対し、12月1日の要件は「発送後」の返品・交換専用アプリを対象としています。 Revizeは現在、ShopifyによってBuilt for Shopifyに認定され、Customer accountsに対応しており、「返品・交換」ではなく「注文編集（order editing）」カテゴリに分類されています。

購入者はRevizeのセルフサービス注文編集ポータルを使用して、発送前であれば、住所、バリエーション、数量の変更、または条件を満たす注文のキャンセルを行うことができます。このフローはShopifyの注文状況ページに表示され、マーチャントが編集可能期間を制御できます。

このカテゴリ分類の違いは、運用上の大きな強みとなります。発送前に注文を修正できれば、不要な返品が逆ロジスティクスに乗るのを防ぐことができます。発送後の返品は別処理となるため、注文編集アプリと返品専用プラットフォームを併用することで、それぞれのシステムを独立して最適に稼働させることができます。

Shopify PlusやAdvanced、Growプランを利用するストアを監査する際、制作会社が取るべき実務的な対応は、この境界線を明確に維持することです。発送前の修正は注文編集レイヤーで処理し、発送後の返品については返品アプリベンダーに個別の準拠証明を求めます。Square Enix、Venchi、Shelly、Nude Project、AYBL、TheGameCollectionなどのブランドが、さまざまな商品カテゴリでこの顧客セルフサービスモデルを採用しています。

もし現在、住所変更やバリエーション変更、キャンセルリクエストをすべて手動のサポート窓口で処理している場合は、返品アプリの移行を待つ間に、発送前のセルフサービスレイヤーを追加することを推奨します。

パートナー・制作会社が実施すべきCustomer Account API要件の監査方法

2026年12月1日までに、セルフサービス返品、交換、またはサブスクリプション機能を導入しているすべてのクライアントを対象に、以下の7ステップの監査を実行してください。 目的はベンダーの移行約束を記録することではなく、すべての購入者エントリポイントにおいて本番環境の動作を確認することです。

1. 対象アプリのリスト化： 導入済みアプリのShopifyカテゴリ、Built for Shopifyステータス、購入者向け機能、ビジネス担当者、技術担当者、更新日を記録します。注文編集、追跡、返品、交換、サブスクリプション、サポートヘルプデスク、倉庫管理の各機能を分類します。

2. ベンダーへの確認書要求： アプリがShopifyの発表したカテゴリ要件に該当するか、またCustomer Account APIが本番環境のプライマリ認証方法になっているかを問い合わせます。未対応の場合は、対応完了予定日を要求します。

3. 顧客の動線（エントリポイント）の確認： アカウントのナビゲーション、注文状況ページ、確認メール、返品リンク、交換追跡、QRコードのリンク先、モバイルブラウザ、ヘッドレスフロントエンドのリンクなどを検証します。メインのアカウントメニューからは認証が完了しているように見えても、古いディープリンクからは別のポータルが開くケースがあります。

4. ログイン切り替え時の挙動確認： 購入者がすでにログインしている状態、ログアウト状態、または古いブックマークからアクセスした場合の挙動を確認します。リダイレクトの有無、繰り返しのログイン要求、注文情報の欠落、個別のポータル用ログイン情報を求められる挙動がないかを記録します。

5. 返品・交換テストの実施： テスト用注文を使用して、返品可能なケース、返品不可の商品、一部返品、交換、キャンセル、および処理の途中離脱・再開のフローをテストします。Shopify管理画面および連携する外部システムでの最終ステータスを確認します。

6. エビデンス（証跡）の保存： 購入者フローの録画、Shopifyの注文タイムライン、ベンダーのリリースノート、サポートの回答、テスト実施日を記録・保存します。可能であれば、アプリデベロッパー側のBuilt for Shopify評価証跡の提供を求めます。

7. ロールバックおよびエスカレーションプランの策定： クライアントの担当者、制作会社の担当者、ベンダーの連絡先、代替のサポートフロー、および要件を満たせない場合の代替アプリ選定期限を明記します。この選定期限は、繁忙期のシステム変更凍結期間（コードフリーズ）より前に設定してください。

バッジの表示が変わるまでテストを後回しにしないでください。 最も深刻な問題は、バッジの消失ではなく、顧客が注文情報を確認できなくなったり、交換手続きを進められなくなったり、慣れ親しんだ導線が変わって混乱したりすることです。

12月1日以降、実際に何が起こるのか？

Shopifyが公式に示している12月1日以降のペナルティは、非準拠の対象アプリがBuilt for Shopifyステータスを失うリスクがあるという点のみです。 App Storeからの強制削除や、返品ポータルの即時停止といった解釈は、公式発表の範囲を超えた憶測です。

しかし、マーチャントは以下の3つの実質的なリスクを評価する必要があります：

• 信頼性の低下： アプリ選定や構成見直しの指標となる品質シグナル（バッジ）をアプリが失う可能性があります。

• リリース初期の不具合： 急ぎで実施された認証移行により、ログインループ、リダイレクトエラー、注文データの不整合などが発生する可能性があります。これらは想定で判断せず、必ずテスト注文で確認してください。

• サポート負担の増加： セルフサービスの導線が不安定になると、最も返品が増える時期に、顧客からの問い合わせがメールやチャットに集中します。

バッジはShopify側が適用する基準ですが、実際の購入者の購買体験は、マーチャント自身がテストして守るべきビジネス上の仕組みです。

アドバイス： ベンダー側のロードマップと、実際のテスト証跡を同じ監査記録に保管してください。予定日は計画を示すものに過ぎず、実際にテストを完了したプロセスだけが本番への備えを証明します。

Plusオペレーターが取るべきアクション

8月29日の時点で残り94日です。パートナーや制作会社は、9月中に現状把握、10月に本番環境テスト、そして11月のコードフリーズ前に代替対応の判断を完了する必要があります。 12月1日の期限は明確で検証可能なため、購入後アプリのスタックすべてを入れ替えることなく対応可能です。

今週行うべきアクション：

1. 顧客向けの返品、交換、サブスクリプションアプリをすべて洗い出す。

2. 各ベンダーに対し、Customer Account APIが本番環境のプライマリ認証になっているか確認する。

3. テスト用注文を使い、すべての顧客エントリポイントを検証する。

4. 発送前の「注文編集」と発送後の「返品」を明確に区別して整理する。

5. テスト証跡、担当者、期限、および不具合時の代替案を記録する。

目的は形だけの移行作業ではありません。購入後体験における顧客のID連携を確実に検証し、証跡に基づいて安定したストア運営を維持することです。

よくある質問（FAQ）

ここでは、2026年12月1日までに制作会社やPlusオペレーターが解決しておくべき10の質問に回答します。 公開されているルールはシンプルなため、Shopifyの正確な要件と、ベンダーへの確認やテスト注文が必要な実務上の判断を分けて考えることが重要です。

2026年12月1日に何が変わりますか？

対象となる返品、交換、サブスクリプションアプリは、Built for Shopifyステータスを維持するために、プライマリ認証方法としてCustomer Account APIを使用する必要があります。 このルールは、アプリが購入者向けのセルフサービス機能を提供している場合に適用されます。Shopifyはこの期限を2026年6月17日に発表しました。

12月1日になると、返品アプリは動かなくなりますか？

Shopifyは、対象アプリが12月1日に自動的に停止するとは述べていません。 公開されている影響は、要件を満たさないアプリがBuilt for Shopifyステータスを失うリスクがあるという点です。マーチャントはベンダーに今後の運用方針を確認し、動作停止を懸念するよりも、テスト注文で実際の顧客フローを検証することをお勧めします。

この要件はすべてのShopifyアプリに適用されますか？

いいえ、すべてのShopifyアプリに適用されるわけではありません。 Shopifyは、購入者向けのセルフサービス機能を備えた返品・交換アプリ、およびサブスクリプションアプリを指定しています。配送追跡、ヘルプデスク、注文編集、倉庫管理などの他のカテゴリについては、Shopifyやベンダーから明確な指示がない限り、対象外と判断して差し支えありません。

マーチャント側でAPI移行作業を行う必要がありますか？

APIの移行作業はアプリデベロッパーが行います。マーチャントは、導入ベンダーの選定や運用上のリスク管理に責任を持ちます。 制作会社は、ベンダーの対応状況を確認し、影響を受けるフローをテストし、対応計画を文書化する必要があります。マーチャントがShopify管理画面の設定だけで、他社製アプリの認証構造を直接修正することはできません。

Customer Account APIとは何ですか？

Customer Account APIは、認証された購入者が自身のアカウントデータに安全にアクセスするためのShopifyのインターフェースです。 これにより、アプリはログイン中の顧客に属する注文情報、プロフィール、配送先住所などの情報を処理できます。Shopifyはこれを、顧客アカウント、ストアフロント、および連携アプリ全体を繋ぐ標準的な認証レイヤーとして位置づけています。

このAPIはCustomer Account UI extensionと同じですか？

いいえ、認証機能とUIの表示場所は別々で管理されています。 Customer Account APIは、認証されたデータへのアクセスを制御します。Customer Account UI extensionsは、Shopifyのアカウントページ内にアプリの機能を埋め込んで表示します。アプリは両方に対応しつつ、APIがプライマリの認証方法として使用されていることを示す必要があります。

返品ポータル画面のすべてをShopify内に移行する必要がありますか？

12月の新要件が求めているのは、あくまで「プライマリ認証方法としてCustomer Account APIを使用すること」です。 アプリのすべての画面をShopifyのインターフェース内に再構築することを義務付けるものではありません。認証はすべての後続プロセスに影響するため、制作会社はベンダーに対し、どの画面やバックエンドコンポーネントが変更されるのかを確認し、全体の挙動を検証する必要があります。

ゲスト購入（ログインなし）の注文はどのようにテストすべきですか？

ベンダーがサポートしている実際のエントリポイントや認証ステートに従ってテストを行います。 注文完了メールからのアクセス、未ログイン状態のブラウザ、セッション期限切れ、別端末からのアクセスなどを確認します。ログイン済みの状態でのテストが成功したからといって、ゲスト購入や事前認証ルートがすべて正常に動作するとは限りません。

現在使用している返品アプリをそのまま使い続けることはできますか？

はい。ベンダーが要件に準拠したロードマップを提示し、実際のテストでも動作に問題がない場合は、そのまま利用可能です。 今回の要件自体がアプリの乗り換えを強制するものではありません。移行準備の証跡が得られない場合や、予定されたスケジュールを大幅に超過し、テストで不具合が多発する場合にのみ、アプリの代替を検討してください。

制作会社はどのような証跡を監査記録として残すべきですか？

ベンダーの回答、テスト実施日、検証時の録画、テストに使用した注文ID、Shopify側の最終ステータス、緊急時の連絡先などを記録します。 ベンダーが共有可能な場合は、アプリの現在のBuilt for Shopifyステータスや、パートナーダッシュボードの判定結果のスクリーンショットも追加します。将来的な計画だけでなく、「実際にテストして確認した動作」を記録に残すことが重要です。

関連情報

Built for ShopifyのCustomer Account API要件に関連する、顧客アカウント、チェックアウト、注文管理の変更に関する3つのガイドです。

• Shopifyクラシック顧客アカウントからの移行方法

• 2026年に向けたShopify Checkout Extensibilityの準備

• Shopify注文管理ワークフローの監査方法

今すぐ必要な検証と証跡確認を完了させ、各システムをそれぞれの役割に集中させることで、予測ではなく確実なテストデータに基づいて12月1日を迎えましょう。