App Pricing アップデート プラン上限が倍増、課金テストは「無課金」で、App Events は負値・小数に対応

図解 ： App Pricing アップデート（プラン上限拡大・無課金テスト・App Events の負値/小数対応） App Store / 開発者向けアップデート App Pricing アップデート プラン上限が倍増、課金テストは「無課金」で、App Events は負値・小数に対応 アプリの料金プランは公開 8 個・非公開 15 個まで作成可能に。審査・開発ストアでの課金フローは実課金なしでテストでき、App Events API は使用量の「訂正（マイナス）」と「小数値（1.5 など）」を受け付けるようになった。 このページの構成 そもそも何が変わるのか（30秒で理解） プラン上限の拡大 ： 4→8 ／ 10→15 無課金テストの 3 つの経路（図解） App Events API ： 負の値と小数値 従来 vs 今回の比較 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか（30秒で理解） App Pricing（アプリ課金）まわりの 3 点セットのアップデート。 ① プラン数の上限が拡大、② 課金フローを実課金なしでテスト可能に、③ App Events API が負値・小数値を受け付ける ようになった。 プラン上限が拡大 1 アプリあたり公開プラン 8 個（従来 4）、非公開プラン 15 個（従来 10）まで作成できる。 無課金プランテスト 審査・開発ストア・他パートナーの開発ストアで、実課金を発生させずに課金フローを試せる。 App Events 拡張 負の値（過去計上分の調整・クレジット）と小数値（1.5 など）を API が受け付ける。従来は 0 より大きい整数のみ。 2 プラン上限の拡大 ： 4→8 ／ 10→15 公開プラン は App Store 上で誰でも選べる料金表、 非公開プラン は特定マーチャント向けの個別条件。上限拡大により、ティア細分化（Free / Starter / Pro / Plus…）やエンタープライズ個別契約の同時運用がやりやすくなる。 3 無課金テストの 3 つの経路（図解） 「実課金を発生させずに課金フローをテストする」手段が、立場別に 3 つ用意された。 A アプリ審査中 ： レビュアー レビュアーが既存プランをそのまま選択してテストできる。 審査用のテスト専用プランを作る必要がなくなった。 B 開発ストア ： 自分のアプリ 自分の開発ストアに自アプリをインストールし、 どのプランでも無料でサブスクライブ して課金フローを確認できる。 C 他のパートナー ： free 指定プラン プランを「free」としてマークすると、 他のパートナー・開発者が自分の開発ストアにインストールしてそのプランをテスト できる。 4 App Events API ： 負の値と小数値 従来の App Events API は「 0 より大きい整数 」しか受け付けなかった。今回から 負の値 （報告済み使用量の調整・クレジット）と 小数値 （1.5 など）を送信できる。 負の値 過去計上分の「訂正」がAPIで完結 すでに報告したイベント使用量を調整（adjust）またはクレジット（credit）する用途と記事に明記。誤計上・返金対応をマイナスのイベント送信で表現できる。 小数値 「1.5 回分」のような従量計上が可能 整数への切り上げ・切り捨てが不要になり、実際の使用量に沿った課金単位を設計できる。記事の例示は「1.5」。 5 従来 vs 今回の比較 項目 従来 今回から 公開プラン上限 4 個 ／アプリ 8 個 ／アプリ 非公開プラン上限 10 個 ／アプリ 15 個 ／アプリ 審査時の課金テスト テスト専用プランを別途作成 不要 レビュアーが既存プランを選択 開発ストアでの自アプリ —（記事内に従来仕様の記載なし） 無料 どのプランでもサブスク可 他パートナーによるテスト —（記事内に従来仕様の記載なし） 可能 free 指定プランを各自の開発ストアで App Events の値 0 より大きい整数のみ 負値・小数もOK （調整／クレジット、1.5 等） 6 技術者が押さえるべき5つのポイント 1. 上限は「1 アプリあたり」公開 8・非公開 15 プラン設計の自由度がほぼ倍増。ただしプラン乱立は選択のノイズにもなるので、増やす前に価格ティアの設計方針を決めること。 2. 「審査用テストプラン」は作らなくてよい レビュアーが既存プランを直接選べるようになったため、審査提出前に専用プランを用意する慣習は不要に。既存のテスト専用プランは整理対象。 3. 「free マーク」は外部テスターへの配布経路 プランを free として公開すると、他のパートナー・開発者が自分の開発ストアでそのプランを試せる。ベータ配布や代理店向けデモの経路として使える。 4. 負値イベントの用途は「調整・クレジット」 記事上の位置づけは、報告済み使用量の adjust / credit。返金や誤計上訂正のワークフローを、独自 DB での補正ではなく App Events 自体で表現できる。 5. スキーマ・バリデーションの詳細は本文に記載なし → リファレンス必読 負値・小数の許容範囲、丸め処理、既存イベントとの相殺計算の仕様は changelog 本文には記載なし。記事が案内する App pricing ドキュメントと App Events API リファレンス で確認してから実装すること。整数前提で値を丸めている既存の送信コードは見直し候補。 7 業務に活かせる3つのユースケース USE CASE 1 価格ティアの細分化 ： 「4 枠に収まらない」料金再設計 課題 公開プラン 4 個の制約で、月額/年額の併売やセグメント別ティア（SMB／Plus 向け等）を諦め、1 プランに機能を詰め込んでいた。 打ち手 公開 8 枠を使って料金表を再設計（例 ： 月額 4 ティア＋年額系）。エンタープライズや代理店経由の個別条件は非公開 15 枠に切り出す。 効果 アップセル導線の明確化と、個別見積もり案件を非公開プランで正規に管理できることによる契約運用の簡素化。 技術メモ プラン数を増やす前に、既存サブスクリプションからの移行パス（どのプランに誰を寄せるか）を設計しておく。移行仕様自体は記事に記載なし。 USE CASE 2 課金フローの E2E テストを CI 的に「無課金」で回す 課題 サブスク開始〜プラン変更の billing フローを検証するたびに実課金の発生を気にし、審査用のダミープラン管理も煩雑だった。 打ち手 開発ストアに自アプリをインストールし、本番と同じプランを無料でサブスクして検証。QA 委託先や協業パートナーには free 指定プランを配布して各自の開発ストアで試してもらう。 効果 テスト専用プランの作成・削除運用が消え、審査前の billing 検証コストがゼロ課金で完結。リリース前の billing リグレッション確認が習慣化できる。 技術メモ 審査（A）・自分の開発ストア（B）・他パートナー（C）で使える経路が異なる（セクション3参照）。free マークの公開範囲の細かい制御は記事に記載なし。 USE CASE 3 従量課金の「訂正・返金」フローを App Events で正規化 課題 従量課金アプリで誤計上・キャンセル分の返金調整が API で表現できず、翌月分から手動で差し引く等の運用でしのいでいた。また整数制約のため、実使用量を切り上げて課金していた。 打ち手 調整・クレジットは負値の App Event として送信し、計上単位は 1.5 のような小数値で実使用量どおりに報告するよう送信ロジックを改修。 効果 マーチャントへの請求が実態と一致し、返金クレームの一次対応が「マイナスイベント送信」で完結。切り上げ課金による過請求も解消。 技術メモ 負値・小数の精度上限や相殺の計算仕様は本文に記載なし。実装前に App Events API リファレンスで制約を確認し、送信側の整数丸め処理を撤去する。 8 提案で使える1行サマリ 「アプリ課金の三段強化 ： プラン枠が公開 8・非公開 15 に倍増、 審査も開発ストアも実課金ゼロでテスト可能、App Events は負値（返金調整）と小数（実使用量）に対応。 従量課金アプリの価格再設計と請求訂正フローを見直す好機。」 source ： shopify.dev/changelog / app-pricing-more-plans-no-charge-plan-testing-and-negative-and-fractional-app-events generated 2026-07-12