返品・交換アプリ／サブスクアプリは 「Customer Account API 認証」が必須に

図解 ： Built for Shopify 要件更新 ― 返品・交換アプリ／サブスクアプリは Customer Account API 認証が必須に（2026年12月1日施行） Built for Shopify Action Required 返品・交換アプリ／サブスクアプリは 「Customer Account API 認証」が必須に 2026年12月1日施行。購入者向けのセルフサービス機能を持つ返品・交換アプリとサブスクリプションアプリは、顧客認証に Customer Account API を使う必要がある。期限までに対応しないと Built for Shopify ステータスを失うリスクがある。 このページの構成 30秒で理解 ： 何が変わるのか 対象になるアプリ 図解 ： 統一サインインの考え方 やるべきこと 期限と未対応リスク 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が変わるのか 2026年12月1日 から、購入者向けのセルフサービス機能を提供する 返品・交換アプリ と サブスクリプションアプリ は、顧客認証に Customer Account API を使わなければならなくなる。 これにより、ストアフロント・アプリ・カスタマーアカウントをまたいで、買い手と マーチャントが「単一の安全なサインイン」を共有できる。 これまで ： 認証方式は各アプリ任せ アプリ独自のログインや個別の認証方式で、購入者がアプリごとにサインインを求められることもあった。 これから ： Customer Account API に統一 購入者は、ストアフロント／アプリ／カスタマーアカウントを横断して、ひとつの安全なサインインで利用できる。 2 対象になるアプリ 次の いずれかのカテゴリに該当 し、かつ 購入者にセルフサービス機能を提供している アプリが対象。 対象カテゴリ A 返品・交換アプリ 例 ： 返品の管理、交換の追跡といった購入者向けのセルフサービス機能を提供しているアプリ。 対象カテゴリ B サブスクリプションアプリ 例 ： 購入者がサブスクリプションを更新・変更できるセルフサービス機能を提供しているアプリ。 判定基準は「購入者向けセルフサービス」かどうか 。記事に挙げられている具体例は 「返品の管理」「交換の追跡」「サブスクリプションの更新」。これらのように、購入者自身が 操作する画面を持つアプリが該当する。 3 図解 ： 統一サインインの考え方 Customer Account API を顧客認証の入口にすることで、買い手は ストアフロント・アプリ・カスタマーアカウントをまたいで一度のサインインで済む 。マーチャント側も認証が一本化される。 4 やるべきこと 1 対象判定 自社アプリが「返品・交換」または「サブスク」かつ購入者向けセルフサービスに該当するか確認する。 2 Customer Account API を統合 購入者向けフローの顧客認証を Customer Account API で行うように実装する。 3 更新版の要件を確認 更新された Built for Shopify 要件で詳細を確認し、抜け漏れがないかチェックする。 5 期限と未対応リスク 項目 内容 施行日／期限 2026年12月1日 この日から要件が有効になる 要件 購入者向けセルフサービスの顧客認証に Customer Account API を使用すること 未対応の場合 リスク 期限までに要件を満たさないアプリは Built for Shopify ステータスを失うリスク がある 具体的な「ステータス剥奪の判定プロセス」や「猶予・例外措置」については記事に 記載なし 。詳細は更新版の Built for Shopify 要件で確認すること。 6 技術者が押さえるべき5つのポイント 1. 認証は Customer Account API へ寄せる 対象アプリの購入者向けフローでは、顧客認証の方式を Customer Account API に置き換える必要がある。独自ログインのみの構成は要件未達になる。 2. 対象は2カテゴリ × セルフサービス 「返品・交換」または「サブスク」のいずれかに該当し、かつ購入者向けセルフサービスを持つアプリが対象。両方の AND 条件で判定する。 3. 統一サインインが目的 狙いは、ストアフロント・アプリ・カスタマーアカウントをまたいだ「単一の安全なサインイン」。認証 UX の一貫性が要件の背景にある。 4. 未達は BFS ステータス喪失リスク 期限までに満たさないと Built for Shopify ステータスを失うリスクがある。BFS バッジに依存した露出・信頼への影響を見込んで計画する。 5. 期限は2026年12月1日。逆算でスケジュールを引く 施行日が確定しているので、実装・検証・審査の余裕を見て逆算する。なお Customer Account API の具体的な実装手順・スコープ・移行ガイドの詳細はこの記事には 記載なし のため、更新版の Built for Shopify 要件と公式ドキュメントで別途確認すること。 7 業務に活かせる3つのユースケース USE CASE 1 既存アプリの認証を棚卸しして「BFS 維持」を確実にする 課題 返品・交換／サブスクアプリを提供中だが、購入者向けセルフサービスの認証が独自方式のままで、要件を満たしているか不明。 打ち手 対象判定 → 認証フローを Customer Account API に統合 → 更新版 Built for Shopify 要件と照合して差分を潰す。 効果 2026年12月1日以降も Built for Shopify ステータスを維持でき、剥奪リスクを回避できる。 技術メモ 対象は「2カテゴリ該当 × 購入者向けセルフサービス」の AND 条件。該当しない管理者向け画面と切り分けて見極める。 USE CASE 2 購入者の「アプリごとの再ログイン」を解消して離脱を減らす 課題 購入者がストアフロントとアプリで別々にサインインを求められ、返品申請やサブスク変更の途中で離脱が起きる。 打ち手 Customer Account API を採用し、ストアフロント・アプリ・カスタマーアカウントで単一の安全なサインインに統一する。 効果 セルフサービス操作のログイン摩擦が減り、返品・交換・サブスク管理の完了率向上が期待できる。 技術メモ 記事が示す価値は「横断する単一サインイン」。UX 改善と BFS 要件対応を同じ実装で同時に達成できる。 USE CASE 3 施行日から逆算した「対応プロジェクト計画」を作る 課題 複数の対象アプリを抱えており、2026年12月1日の期限に対して実装・検証・審査の段取りが見えていない。 打ち手 対象アプリの洗い出し → Customer Account API 統合の実装 → 更新版要件との照合 → 期限前の検証・審査を逆算配置。 効果 駆け込み対応や要件未達による BFS 喪失リスクを避け、計画的にステータスを維持できる。 技術メモ 具体的な実装手順・移行ガイドはこの記事に記載なし。更新版 Built for Shopify 要件と公式ドキュメントを一次情報として参照する。 8 提案で使える1行サマリ 「購入者向けセルフサービスを持つ 返品・交換アプリ／サブスクアプリ は、 2026年12月1日 までに顧客認証を Customer Account API に統合しないと Built for Shopify ステータスを失うリスク 。統一サインインで UX 改善も同時に取りに行ける。」 source ： shopify.dev / changelog / built-for-shopify-requirements-for-returns-and-exchanges-and-subscription-apps Developer Changelog ／ 2026-06-17