Shopify App Store / 課金基盤刷新

Shopify App Pricing
「定額」「使った分」「両方」が選べる新しい標準課金

Managed Pricing が「Shopify App Pricing」にリネーム＆機能拡張。サブスクに加えて App Events API による使用量課金が解禁。Billing API は legacy 扱いに。

このページの構成
  1. 30秒サマリ ： 何が変わったのか
  2. 課金モデルの三択（図解）
  3. 使用量課金の仕組み ： App Events API の流れ
  4. 3つの料金構造 ： fixed / graduated / volume
  5. 新 API ： Active Subscription / Historical
  6. 既存アプリへの影響（パターン別）
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

130秒サマリ ： 何が変わったのか

Shopify App Store の標準課金が「Shopify App Pricing」に統一された。
従来の サブスク（Managed Pricing） に加え、App Events API による使用量課金、両方を組み合わせた ハイブリッド が公式サポートされる。
旧 Billing API は legacy 扱い ＝ 新規アプリは Shopify App Pricing 必須。
RENAME

Managed Pricing → Shopify App Pricing に改名

既存設定はそのまま、表示名だけ切替。Partner Dashboard 上で「Shopify App Pricing」として見える。

使用量課金が公式解禁

App Events API でイベント送信 → Partner Dashboard で meter 定義 → Shopify が集計・請求まで自動で処理。

LEGACY

Billing API は legacy 化

既存稼働は止めないが「これから書くものは Shopify App Pricing で」が明確に。

2課金モデルの三択（図解）

A. サブスクのみ $29 / 月 毎月一定額 予測しやすい売上 B. 使用量のみ 使った分だけ請求 API call / メッセージ送信数 等 C. ハイブリッド $29 基本 + 基本料金＋使用量 SaaS 王道パターン
「subscriptions, usage-based charges, or combined models」を Shopify App Pricing が直接サポート。これまで使用量課金は実質サポート外だったので、SaaS 的な従量モデルがネイティブで組めるのが今回の最大の変化。

3使用量課金の仕組み ： App Events API の流れ

あなたのアプリ 事象が発生 （送信・処理・呼び出し） App Events API Shopify（受信） event ： sent_email event ： api_call イベント蓄積 meter 定義で集計 Shopify（集計・計算） aggregation calculation invoicing 3工程まで自動 マーチャント請求 admin に料金カード表示 プラン・使用量を可視化
アプリ側の責任

イベントを送るだけ

「何回処理した」「何件送った」など、料金の根拠となる単発イベントを App Events API で送る。これだけ。

Shopify が担当

aggregation / calculation / invoicing

受け取ったイベントの集計、金額計算、請求書発行までやってくれる。自前で課金パイプラインを作る必要なし。

Negative reporting に対応 ： マイナスのイベントを送れば自動で課金を補正できる。返金処理や誤計上のリカバリを自前で書かなくてよい。

43つの料金構造 ： 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 を全部ログとして取れる。経理突合や紛争対応のエビデンスを自前で蓄える必要が減る。

legacy App Pricing

5. Billing API は legacy ＝ 新規実装の選択肢から外す

「continues to function but is now legacy. All apps should use Shopify App Pricing going forward.」と明記。新規開発ではもう Billing API を選ばないのが正解。既存資産は移行ツールが出るまで待ち。

8業務に活かせる3つのユースケース

events / month
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（機能制限の見せ方）を事前に決めておく。
install charge usage uninstall
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 一択。」