はじめに

2026年5月13日ごろから、Shopifyの開発ストアで有料アプリの課金画面が詰むという問題がおきています。

これまでは開発ストアでプランを選ぶと自動的にテストサブスクが作成されていたのですが、ある日突然「決済方法が登録されていません」というエラーで先に進めなくなりました。

  • 開発ストアでアプリの動作確認ができなくなった
  • 制作会社で複数の dev store を使い分けているが、すべてで課金画面が止まる
  • アプリレビュー再提出を控えていて、テスト方法に不安がある
  • $0 private test plan を案内されたけど、現実的に運用できる気がしない

このような方のための記事です。

この記事では、2026年4月28日に行われた Shopify App Pricing の仕様変更によって発生している開発ストアの課金問題と、無料公開プランを追加することで構造的に回避する方法を、実装上の落とし穴まで含めて解説します。

実際に自分が運用している Shopify アプリでこの問題に直面した経験から、公式ドキュメントとコミュニティの議論を整理した上での結論をまとめています。

何が起きたのか

開発ストアで自社の有料アプリを開くと、課金ページに進んで承認ボタンを押そうとした瞬間に「決済方法が登録されていません」と表示され、それ以上進めなくなります。

課金方法のエラー画面
課金方法のエラー画面

これまでは、開発ストアがプランを選ぶと Shopify が自動で「Test」ラベル付きのサブスクを作成してくれていたため、誰でも無設定で無料テストができました。新仕様では、この自動作成が廃止されました。

特定のアプリで起きているのではなく、Shopify プラットフォーム全体で起きている挙動変更です。

Wishlist 系・パスワード保護系・カスタマイズ系など、有料プランを持つあらゆるアプリで同じ症状が確認されています。

公式ドキュメントには「Every subscription now requires a billing contract, and Shopify doesn't support 'test' subscriptions with the new billing system」と明記されています。

すべてのサブスクに billing contract が必須になったため、クレジットカードの登録されていない開発ストアでは契約自体が成立しなくなりました。

外部記事Offer free trialsOffer free trials

公式上の変更日は2026年4月28日と記載されていますが、実際の挙動変更が広範に観測されたのは5月13日前後です。

Shopify サポートに問い合わせた開発者に対しても「intentional platform change（バグではなく仕様）」と回答されています。

外部記事[Feature Request] Add Partner[Feature Request] Add Partner

原因と背景：Managed Pricing から Shopify App Pricing への移行

この変更は、5月12日に Shopify が発表した「Shopify App Pricing」へのリブランドと密接に関わっています。

これまで「Managed Pricing」と呼ばれていた仕組みが「Shopify App Pricing」に改名され、従量課金（usage-based billing）への対応や App Events API との統合など、大幅な機能拡張が行われました。

同時に、これまで legacy として残っていた Billing API も「legacy」と公式に宣言され、新規開発は Shopify App Pricing を使うのがデフォルトになっています。

外部記事Shopify App Pricing: The next generation of app billingShopify App Pricing: The next generation of app billing

この移行に伴って、開発ストアの扱いも変わりました。

旧仕様では、Shopify が「これは開発ストアだから自動でテストサブスクを発行しよう」という判定を裏側で行っていました。

新仕様では、すべてのサブスクが正式な billing contract に紐づく必要があるため、クレジットカードのない開発ストアは契約を完了できなくなります。

開発者コミュニティでは、Shopify スタッフの Alan_G がこの問題について以下のように回答しています。

「I don't have a product change or timeline to share right now, but I'll loop back if I get more concrete guidance.」

つまり、ロードマップは示されていないものの、内部に懸念を共有するという姿勢です。

元の仕様に戻すと明言されたわけではないため、開発者側で自衛策を取る必要があります。

外部記事Managed billing not showing test charges for dev stores anymoreManaged billing not showing test charges for dev stores anymore

公式が示す回避策（$0 private test plan）の限界

Shopify が公式に案内している回避策は、Partner Dashboard で $0 private test plan を作成し、ストアアクセス一覧に開発ストアのドメインを手動で登録するという方式です。

Stores with plan accessの登録画面
Stores with plan accessの登録画面

実際にやってみると、以下の制約に突き当たります。

  • 1つの private plan に登録できるのは最大20ストアまで
  • private plan 自体は最大10個まで作れるので、理論上は最大200ストア
  • 開発ストアごとに毎回 Partner Dashboard で手動登録が必要
  • 制作会社でクライアントの dev store にインストールしてもらう運用には不向き
  • アプリレビュー時、レビュアーの dev store ドメインは毎回変わるので事前登録できない

特に最後の問題は深刻で、コミュニティでも「アプリレビューでブロックされた」という報告が上がっています。

レビュアーが使うストアが毎セッション変わるため、$0 private test plan を案内する運用そのものが成立しません。

実務で考えると、アプリのリスティング掲載中は新規 dev store の流入が継続的に発生します。それを毎回手動登録で捌くのは現実的ではありません。

無料公開プランによる構造的解決

ここがポイントです。Shopify App Pricing の free プランタイプを公開プランとして追加すると、この問題を構造的に回避できます。

仕組みは単純で、free プランは無料なので billing contract が発生しません。billing contract が発生しないということは、クレジットカードの登録も不要です。開発ストアからでも、本番ストアからでも、誰でも選択できるプランになります。

実際に試したところ、問題無く通れることが確認できました。

無料プランの画面
無料プランの画面

外部記事Public and private plansPublic and private plans

bonjour_ken 氏（Feature Request の起案者）もこの方式を実装して動作確認に成功しており、「クレカ登録なしで通れた」と報告しています。

メリットを整理すると以下のようになります。

  • 開発ストアのテスト問題が構造的に解決する（whitelist 不要）
  • 制作会社が任意のクライアント dev store にインストールして検証できる
  • 実 merchant に対する freemium の入口になる
  • アプリレビュー時、レビュアーが何のドメインから来ても Free プランで動作確認できる
  • 「クレカ登録なしで使える」というマーケ訴求が新たに成立する

実装上の論点：ダウングレードと機能ゲーティング

無料公開プランを追加するだけなら半日で終わりますが、本格運用するには「機能ゲーティング」と「ダウングレード時の挙動」を詰める必要があります。

Free と Paid の線引き

たとえばパスワード保護系アプリなら、以下のような線引きが考えられます。

  • Free: ロック1個まで / パスワードのみ / カスタマイズ不可 / 認証期間24h固定
  • Paid: 全機能解放

Free を緩くしすぎると Paid からの流出が起きますし、厳しすぎると評価フェーズで離脱されます。

実務で一番使うのが、最初は緩めに設定して、利用データを見ながら絞っていくアプローチです。後から緩める方が炎上しません。

ダウングレード時の挙動

Paid から Free へのダウングレードは、Shopify App Pricing では deferred 仕様になっています。

merchant が「Free に変える」ボタンを押した瞬間ではなく、現在の billing cycle 終了時に切り替わります。

外部記事Shopify App PricingShopify App Pricing

このため「いきなり機能が消えて merchant が混乱する」事態は起きにくい設計です。

一方で、cycle 終了時の挙動は自前で実装する必要があります。

たとえば Paid で5個のロックを作っていた状態で Free に落ちた場合、Free の上限は1個なので残り4個をどうするかを決めなければなりません。

実装パターンとしては以下があります。

  • 全部非表示にする（データは残し、再 upgrade で復活可能）
  • 1個だけ有効化、残りは無効化（どれが残るかが不透明になる）
  • merchant に選ばせる（透明だが UI 工数が増える）
  • 全部 read-only、新規作成不可（既存ユーザーを守れる）

実装コストとユーザー体験のバランスで言うと、最初は「全部非表示 + アップグレード導線で復活訴求」の方式が最も安全かと思います。

なお、4月28日以降は subscription 関連の Webhook（APP_SUBSCRIPTIONS_UPDATE）が廃止され、Partner API ベースの activeSubscription クエリへの移行が推奨されています。billing.check は当面動きますが、段階的に Partner API に切り替えるのが今後の方向性です。

外部記事Migrating to Shopify App PricingMigrating to Shopify App Pricing

さいごに

2026年4月28日の Shopify App Pricing 仕様変更によって、開発ストアでアプリの課金画面が詰む問題は、Shopify エコシステム全体で同時多発しています。

公式が案内する $0 private test plan の whitelist 運用は、ある程度のスケールを持つアプリでは現実的に機能しません。

無料公開プランを追加する方式は、Shopify が公式にサポートしている free プランタイプを使うため、Shopify 側の今後の方針変更に左右されにくく、構造的に最も安定した解決策です。

競合アプリが軒並みこの方式に移行している状況も含めて、これからの Shopify アプリ開発における事実上の標準パターンになっていきます。

実装としては Free プランの追加自体は短時間で済みますが、機能ゲーティングの設計とダウングレード時の挙動を詰めると本格的な工数になります。

最初の段階で dev store 復旧と新規流入受け入れを優先し、ダウングレード対応は実 merchant が発生する前にリリースする2段階構成が現実的です。

ご希望に合わせた実装については、お問い合わせからお気軽にご相談ください。