Built for Shopifyの2026年12月1日要件：返品・交換アプリに求められるCustomer Account APIへの移行

この期限が重要なのは、セルフサービスの返品・交換では、どの手続きも認証から始まるためです。 移行に失敗してもアプリ自体が停止するとは限りません。しかし、返品が集中する時期に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の認定を失うおそれがあるということです。対象アプリがすべて動作を停止する、Shopify App Storeから消える、または日付が変わった時点でマーチャントの業務フローが無効になるとは述べていません。

12月1日はベンダー管理上の期限として扱ってください。ストアフロントが自動的に停止する日ではありません。 それでも代理店は今から対応を進めるべきです。認定の変更や急いで公開した認証機能が、年末の返品業務に不要なリスクを生む可能性があるためです。

Built for Shopify要件の対象となるアプリ#

対象となるのは、返品・交換・サブスクリプションのいずれかのカテゴリに属し、購入者向けのセルフサービスを提供し、2026年12月1日以降もBuilt for Shopifyの認定を維持する意向があるアプリです。 マーチャントが利用するすべてのアプリが自動的に対象になるわけではありません。

購入後に使う各アプリについて、次の項目を確認してください。

• アプリのカテゴリを確認する。 機能名から推測せず、Shopifyとベンダーがそのアプリをどう分類しているか確認します。
• 購入者向けの操作を洗い出す。 返品の開始、交換状況の確認、サブスクリプションの変更、およびそれらを行える顧客用ポータルを含めます。
• 現在の認証方法を特定する。 本番環境ですでにShopifyのCustomer Account APIが主な認証方法になっているか確認します。
• ベンダーのBuilt for Shopify認定に関する方針を確認する。 認定を受けていないアプリには失う認定がありません。ただし、顧客アカウントとの互換性は運用上重要な場合があります。
• フルフィルメント前と配送後の操作を分ける。 未発送の注文を変更するのは注文の編集です。配送済みの商品を送り返すのは返品です。顧客が似た言葉を使っていても、業務フローは異なります。

最後の区別は、監査で最もよくある間違いを防ぎます。購入者はサイズの修正を「交換」と呼ぶかもしれません。しかし、フルフィルメント前にバリエーションを変更すれば、返品に伴う物流は発生しません。配送後の交換には、返品手続き、商品の受領や検品に関する処理、代替品の発送が必要です。

当社のデータでは、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が最新バージョンとして表示されています。また、ディスカバリーエンドポイントも文書化されています。これにより、アプリは単一のドメインをコードに固定せず、各ショップに適した認証エンドポイントとGraphQLエンドポイントを取得できます。

認証と、画面をどこに表示するかは別の話です。 Customer Account UI extensionは、顧客アカウント内のどこに機能を表示するかを制御します。Customer Account APIは、認証された状態で顧客データにアクセスする仕組みです。アカウントページに整った画面が表示されていても、必要なAPIが主な認証方法になっているか、ベンダーに確認する必要があります。

代理店は、次の4つの技術的な質問に書面で回答してもらってください。

1. 本番環境の購入者向け操作では、Customer Account APIを通じて認証していますか？
2. アカウントページ、注文メール、ディープリンク、外部ポータルなど、どの入口で使用していますか？
3. 移行はすべてのマーチャント向けに公開されていますか？ それともテスト対象の一部のみですか？
4. 移行の評価後、ベンダーのPartner Dashboardにはどのような証拠が表示されますか？

注意： 「新しい顧客アカウントに対応」という回答だけで、要件を満たした証拠と判断しないでください。画面への対応と認証要件への準拠は関連していますが、同じことを意味しません。

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

Revizeが担うのは、フルフィルメント前に顧客が自分で操作できる領域です。一方、12月1日の要件は、配送後の返品・交換に特化したアプリを対象としています。 Shopifyでは現在、この注文編集アプリをBuilt for Shopify認定済み、顧客アカウント対応、返品・交換ではなく注文の編集カテゴリのアプリとして掲載しています。

顧客は注文を自分で編集できるポータルを使い、フルフィルメント前に住所、バリエーション、数量、または対象となる注文を変更できます。この操作はShopifyの注文状況ページに表示され、マーチャントが編集可能な期間を設定します。

このカテゴリの区別には実務上の利点があります。発送前に注文を修正すれば、避けられるはずの返品が返品物流の仕組みに入るのを防げます。配送後の返品は別の業務です。注文編集アプリと専用の返品プラットフォームを併用すれば、注文数の多いストアでも、それぞれのシステムに適切な役割を任せられます。

Plus、Advanced、Growのストアを監査する代理店は、この区別を維持することが実務上重要です。フルフィルメント前の修正は注文編集の領域で扱い、返品ベンダーには別途、要件を満たしている証拠を求めてください。Square Enix、Venchi、Shelly、Nude Project、AYBL、TheGameCollectionなどのブランドは、異なる商品カテゴリで顧客によるセルフサービスの仕組みを利用しています。

現在も住所、バリエーション、キャンセルの変更依頼をサポートチームで受け付けている場合は、返品ベンダーが12月に向けた移行を進める間に、フルフィルメント前のセルフサービスを導入してください。

代理店が実施すべきCustomer Account API要件の監査#

セルフサービスの返品、交換、サブスクリプションを提供しているすべてのクライアントについて、2026年12月1日までに次の7ステップの監査を実施してください。 成果物には、ベンダーの移行予定だけでなく、購入者が利用する各入口での本番環境の動作を示す必要があります。

1. 対象アプリの一覧を作る。 各アプリのShopifyカテゴリ、Built for Shopify認定状況、顧客向け機能、業務責任者、技術責任者、契約更新日を記録します。注文の編集、追跡、返品、交換、サブスクリプション、ヘルプデスク、倉庫の各機能を分けて整理します。
2. 日付入りのベンダー回答を求める。 アプリがShopifyの発表したカテゴリ要件の対象か、また本番環境でCustomer Account APIが主な認証方法になっているか確認します。まだ対応していない場合は、公開予定日を示してもらいます。
3. 顧客が利用するすべての入口を確認する。 顧客アカウント内のナビゲーション、注文状況ページ、確認メール、返品リンク、交換状況の確認、QRコードのリンク先、モバイルブラウザー、ヘッドレスストアフロントのリンクをテストします。メインのアカウントメニューでは認証が完成しているように見えても、古いディープリンクからは別のポータルが開く場合があります。
4. 認証状態の切り替わりを調べる。 購入者がログイン済みの場合、ログアウトしている場合、古いブックマークから戻ってきた場合の動作を確認します。リダイレクト、繰り返されるログイン要求、注文情報が引き継がれないケース、別のポータル用認証情報を求める経路を記録します。

1. 返品・交換の全手順をテストする。 管理されたテスト注文を使い、返品対象の商品、対象外の商品、一部返品、交換、キャンセル、途中で離脱してから再開する顧客を検証します。Shopifyと、後続の各業務システムで最終状態を確認します。
2. 双方から証拠を集める。 購入者側の操作記録、Shopifyの注文タイムライン、ベンダーのリリースノート、サポートからの回答、各テストの日付を保存します。入手できる場合は、アプリ開発者にもBuilt for Shopifyの評価に関する証拠の提供を依頼します。
3. ロールバックと問題発生時の対応計画を作る。 クライアント側の責任者、代理店側の責任者、ベンダーの連絡先、代替のサポート手順、十分な証拠を示せないアプリを置き換えるか判断する日付を記録します。その判断日は、繁忙期の変更停止期間より前に設定してください。

認定バッジが変わるまでテストを先延ばしにしないでください。 最も大きな損失につながるのは、バッジそのものとは限りません。顧客が自分の注文を特定できない、交換手続きを再開できない、または使い慣れたアカウントの操作が変わった理由を理解できないことです。

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

Shopifyが12月1日の影響として明示しているのは、要件を満たさない対象アプリがBuilt for Shopifyの認定を失うおそれがあることだけです。 Shopify App Storeからの自動削除や返品ポータルの即時停止など、それ以上の断定は公開された通知の範囲を超えます。

それでもマーチャントは、次の3つの実務上のリスクを評価してください。

• 信頼に関するリスク： アプリ選定や利用中のアプリ構成を見直す際にマーチャントが参考にする、品質の目印を失う可能性があります。
• リリースに関するリスク： 期限間際の認証移行によって、ログインのループ、機能しないリダイレクト、引き継がれない注文情報が生じる可能性があります。発生すると決めつけず、テスト注文で確認してください。
• サポートに関するリスク： セルフサービスの経路が不安定になると、返品が最も多い時期に顧客がメールやチャットでの問い合わせに戻る可能性があります。

認定バッジは、Shopifyが示した要件適用の対象です。マーチャントが業務上テストすべきなのは、購入者の一連の操作です。

ヒント： ベンダーの説明と自社のテスト結果を同じ監査記録に残してください。ロードマップ上の日付は対応の意思を示し、購入者が手続きを最後まで完了できた記録は準備が整ったことを示します。

Plus運営担当者が取るべき対応#

8月29日時点で残り94日です。代理店は9月中に現状把握を終え、10月に本番環境でテストし、11月の変更停止期間に入る前に是正対応を判断してください。 12月1日の期限は明確で、確認も可能です。購入後に使うアプリ群をすべて入れ替えなくても、対象を絞って監査できます。

今週、次の対応を進めてください。

1. 購入者向けの返品・交換・サブスクリプションアプリをすべて洗い出す。
2. 各ベンダーに、本番環境でCustomer Account APIが主な認証方法になっているか確認する。
3. 管理されたテスト注文を使い、購入者が利用するすべての入口をテストする。
4. フルフィルメント前の注文の編集と、配送後の返品を分ける。
5. 証拠、責任者、期限、代替手段を記録する。

目的は、移行したように見せることではありません。購入後の一連の手続きで一貫して使える顧客認証を実現し、代理店がその動作を証拠で説明できるようにすることです。

よくある質問#

代理店とPlus運営担当者が2026年12月1日までに確認すべき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 Adminの設定でサードパーティーアプリの認証構成を修正することはできません。

Customer Account APIとは何ですか？#

Customer Account APIは、認証された購入者がアカウントデータにアクセスするためのShopifyのインターフェースです。 アプリは、ログイン中の顧客本人に属する注文、プロフィールの詳細、住所などの情報を扱えます。Shopifyは、顧客アカウント、ストアフロント、連携アプリに共通する認証の仕組みとして位置づけています。

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

いいえ、認証と画面の表示場所は別のものです。 Customer Account APIは、認証された状態でのデータアクセスを管理します。Customer Account UI extensionは、Shopifyの顧客アカウント内にアプリの機能を表示します。アプリによっては両方が必要ですが、その場合もAPIが主な認証方法であることを示す必要があります。

返品ポータル全体を移す必要がありますか？#

公開された12月の要件で具体的に求められているのは、Customer Account APIを主な認証方法として使用することです。 すべての画面をShopifyの1つのインターフェース内に作り直すとは書かれていません。代理店は、画面とバックエンドのどの部分が変わるかベンダーに確認し、全手順をテストしてください。認証は後続のすべての操作に影響するためです。

ゲスト注文はどのようにテストすべきですか？#

ベンダーが対応する実際のリンクと認証状態を使って、ゲスト注文をテストしてください。 確認メールからのアクセス、ログアウトしたブラウザー、期限切れのセッション、別の端末からの再アクセスを含めます。ログイン済みの顧客アカウントでテストに成功しても、すべてのゲスト向け経路や認証前の経路で準備が整っているとは判断しないでください。

現在の返品アプリを使い続けられますか？#

はい。ベンダーが要件を満たすための信頼できる対応を示し、本番環境の業務フローがテストに合格すれば、使い続けられます。 この期限自体がアプリの交換を義務づけるものではありません。ベンダーが証拠を提示できない、合意した節目に間に合わない、または管理された購入者向けテストに失敗した場合、交換するかどうかが運用上の判断になります。

代理店は要件への対応を示す証拠として何を残すべきですか？#

ベンダーの回答、テスト日、購入者側の操作記録、対象注文のID、Shopify上の最終状態、問題発生時の対応責任者を残してください。 アプリの現在のBuilt for Shopify認定状況のスクリーンショットと、ベンダーが共有できる場合は関連するPartner Dashboardの証拠も追加します。記録には、計画だけでなく実際に確認した動作を示してください。

---

今のうちに証拠をそろえ、各システムに適切な業務段階を任せてください。推測ではなく、テスト済みの顧客体験を確認したうえで12月1日を迎えましょう。