Shopify App Pricing 「定額」「使った分」「両方」が選べる新しい標準課金
原題: Shopify App Pricing: charge for usage, recurring subscriptions, or both
- Shopify App Pricing
- App Events API
- Apps
- 課金
- 使用量課金
- Managed Pricing
- Billing API
- 新機能
図解 : Shopify App Pricing(使用量・定額・ハイブリッド課金) Shopify App Store / 課金基盤刷新 Shopify App Pricing 「定額」「使った分」「両方」が選べる新しい標準課金 Managed Pricing が「Shopify App Pricing」にリネーム&機能拡張。サブスクに加えて App Events API による使用量課金が解禁。Billing API は legacy 扱いに。 このページの構成 30秒サマリ : 何が変わったのか 課金モデルの三択(図解) 使用量課金の仕組み : App Events API の流れ 3つの料金構造 : fixed / graduated / volume 新 API : Active Subscription / Historical 既存アプリへの影響(パターン別) 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒サマリ : 何が変わったのか Shopify App Store の標準課金が「 Shopify App Pricing 」に統一された。 従来の サブスク(Managed Pricing) に加え、 App Events API による使用量課金 、両方を組み合わせた ハイブリッド が公式サポートされる。 旧 Billing API は legacy 扱い = 新規アプリは Shopify App Pricing 必須 。 Managed Pricing → Shopify App Pricing に改名 既存設定はそのまま、表示名だけ切替。Partner Dashboard 上で「Shopify App Pricing」として見える。 使用量課金が公式解禁 App Events API でイベント送信 → Partner Dashboard で meter 定義 → Shopify が集計・請求まで自動で処理。 Billing API は legacy 化 既存稼働は止めないが「これから書くものは Shopify App Pricing で」が明確に。 2 課金モデルの三択(図解) 「subscriptions, usage-based charges, or combined models」を Shopify App Pricing が直接サポート。これまで使用量課金は実質サポート外だったので、 SaaS 的な従量モデルがネイティブで組める のが今回の最大の変化。 3 使用量課金の仕組み : App Events API の流れ アプリ側の責任 イベントを送るだけ 「何回処理した」「何件送った」など、料金の根拠となる単発イベントを App Events API で送る。これだけ。 Shopify が担当 aggregation / calculation / invoicing 受け取ったイベントの集計、金額計算、請求書発行までやってくれる。自前で課金パイプラインを作る必要なし。 Negative reporting に対応 : マイナスのイベントを送れば自動で課金を補正できる。返金処理や誤計上のリカバリを自前で書かなくてよい。 4 3つの料金構造 : fixed / graduated / volume fixed(定額単価) 1イベントあたり一定額。10件でも10万件でも単価は同じ。シンプルで読みやすい料金設計。 graduated(階段式) 区間ごとに単価が変わる。0〜100件は $0.10、101〜500件は $0.08… のように 各区間で別単価 を積み上げて計算。 volume(ボリューム式) 合計使用量が入った区間の単価を 全件に一括適用 。300件なら「300件は全部 $0.08」のような計算。大口割引向き。 記事では「Three pricing structures supported: fixed, graduated, and volume」とだけ明記。具体的な料金例・上限値・最小単位の記載は無いため、実装時は Partner Dashboard の meter 設定画面で確認すること。 5 新 API : Active Subscription / Historical Active Subscription API サブスクの 現時点の状態 をリアルタイム取得。状態は active / pending / cancelled / frozen 。アンインストール後も状態が残るのが従来との大きな差。 active pending cancelled frozen Historical API 全イベントログ を取得 : install / uninstall / subscription 変更 / charges / credits / usage まで一気通貫で取れる。経理突合や障害調査の根拠データになる。 マーチャントの admin に表示される「料金カード(plan / status / usage / 今後の変更)」は Active Subscription API と同じデータソース 。アプリ側のダッシュボードと管理画面で表記が割れないのがポイント。 6 既存アプリへの影響(パターン別) 状態 影響 やること 新規アプリ(課金なし) 必須化 Shopify App Pricing が既定 申請時に Partner Dashboard で価格を設定 Managed Pricing で稼働中 表記のみ変更 課金は継続 そのまま運用可。「Shopify App Pricing」と表示されるだけ Billing API で稼働中 legacy 扱い 動作は維持 移行ツールが 後日提供予定 。リリース時期は記載なし 新たに使用量課金したい 利用可 App Events API は全アプリ即使える dev docs を参照、meter を定義しイベント送信を実装 「Migration tooling will be available soon」とだけ記載。 具体的なリリース日・自動移行の有無・コード変更量は記載なし 。Billing API 利用中のアプリは、提供開始までは現状維持で問題ない。 7 技術者が押さえるべき5つのポイント 1. 課金パイプラインは作らない App Events API でイベントを送ると、Shopify が集計・計算・請求書発行までやる。自前で「使用量を貯める DB」「月次バッチ」「請求書送付」を作る必要がない。 2. Negative reporting で補正 過剰課金や返品が発生したら、負のイベントを送るだけで請求補正できる。冪等性とイベント ID 管理が肝になる。 3. アンインストール後も状態が残る Active Subscription API は「persists beyond uninstall」と明記。 再インストール時に過去のサブスク状態を引き継げる =再課金フローの設計が変わる。 4. Historical API が監査用の一次データ installs / uninstalls / 変更 / charges / credits / usage を全部ログとして取れる。 経理突合や紛争対応のエビデンスを自前で蓄える必要が減る 。 5. Billing API は legacy = 新規実装の選択肢から外す 「continues to function but is now legacy. All apps should use Shopify App Pricing going forward.」と明記。 新規開発ではもう Billing API を選ばない のが正解。既存資産は移行ツールが出るまで待ち。 8 業務に活かせる3つのユースケース USE CASE 1 メール/SMS/レコメンド配信系アプリの「送信数課金」化 課題 定額プランだと大口マーチャントへの提供が赤字になりやすく、かといって自前で従量課金を作るのは請求・与信を含めて重い。 打ち手 「送信完了」イベントを App Events API で送信 → graduated / volume の meter を定義 → 基本料金+使用量のハイブリッド構成に。 効果 小規模マーチャントは安価で始められ、大口は使った分だけ = 導入ハードルと収益性を同時に成立 。 技術メモ イベント送信は冪等にする(同一 event_id は二重カウントしない設計)。返品・キャンセル時は negative reporting で補正。 USE CASE 2 マーチャント問い合わせ「請求が合わない」の根絶 課題 サブスク変更・凍結・解約・再インストール時に「アプリ側の表示」と「Shopify 側の請求」がずれてサポート工数を食う。 打ち手 アプリ内の課金画面を Active Subscription API のレスポンスで描画。admin の料金カードと完全に同じ情報源に揃える。 効果 「アプリは active と言ってるのに admin では cancelled」みたいな乖離が原理的に消える。 サポートチケットの大幅削減 が見込める。 技術メモ 状態は active / pending / cancelled / frozen の4種を網羅し、frozen 時の UX(機能制限の見せ方)を事前に決めておく。 USE CASE 3 経理/監査向け : Historical API で月次レポートを自動生成 課題 アプリ収益のレポートを Partner Dashboard のスクショで運用しており、経理が再集計しないと使えない。 打ち手 Historical API を日次バッチで叩き、自社 BI / Sheet に installs / charges / credits / usage を流し込んで月次クローズを自動化。 効果 請求書差異の調査が「ログを SQL で引く」レベルになる。 監査対応や売上計上の根拠が一次データで揃う 。 技術メモ 取得粒度・レート制限・保持期間は記載なし。本番投入前に小規模アプリで一日分を取って構造とサイズを確認すること。 9 提案で使える1行サマリ 「Shopify アプリの課金が、サブスク・使用量・ハイブリッドを公式に組める Shopify App Pricing に統一。 App Events API でイベントを送れば 集計・計算・請求まで Shopify がやる 。 Active Subscription / Historical API でアプリと admin の表示も突合可能に。 新規アプリは必須、Billing API は legacy = これからは Shopify App Pricing 一択。 」 source : shopify.dev / changelog / shopify-app-pricing generated 2026-05-23