ストア手数料は率ではなく構造で下げる — Apple SBP と 2026年6月 Google Play 新料金の実務

Google Play 2026年6月30日の新料金 — サービス料とビリング料の分離

Google Play は2026年6月30日から、サービス料とビリング料を分離しました。まず米国・欧州経済領域（EEA）・英国で始まり、他市場へ順次拡大します。この分離が、個人開発者にとって実は好都合な余地を生みます。

要点は、サービス料が課金方式に関わらず年間最初の100万ドルまで10%から始まること、そして Google Play の課金システムを使う場合のみ、追加のビリング料5%（米・英・EEA）が乗ることです。外部の課金システムや自社サイトへのリンクで決済する場合、この5%は発生しません。

サブスクリプションは規模に関係なくサービス料が一律10%で、100万ドルの崖がありません。これは個人開発のサブスクアプリにとって素直に有利です。一方、非サブスクの課金は100万ドルを超えると、そのユーザーが「新規インストール」か「既存インストール」かで率が変わります。ここでの新規・既存は、その市場で新料金が始まった日を基準に、初回インストールまたは初回更新がその日以降かどうかで決まります。

「その他課金」で外部課金や自社サイトリンクを選べばビリング料5%が消えるため、実効はサービス料だけになります。ただし決済体験・返金対応・税処理を自前で背負う覚悟が要ります。私自身は、少額サブスク中心のアプリでは Google Play 課金の15%を払って運用負荷を下げる方を選んでいますが、単価の高い一括課金なら外部課金を検討する価値があると考えています。

実効手数料を自分の数字で計算する

率を暗記する代わりに、条件を入れれば実効手数料が出る関数を用意しておくと、値付けのたびに迷わなくなります。次の TypeScript は、Apple と Google それぞれの実効手数料率を返します。Rork のバックエンド（Cloudflare Workers など）にそのまま置けます。

type Store = "apple" | "google";
type ChargeKind = "subscription" | "other";
type InstallType = "new" | "existing";
 
interface FeeInput {
  store: Store;
  kind: ChargeKind;
  // 当年の累計 proceeds（USD）。100万ドル閾値の判定に使う
  ytdProceedsUsd: number;
  // Apple: SBP 登録済みか / Google: Play 課金を使うか
  enrolledOrPlayBilling: boolean;
  installType?: InstallType; // Google の「その他課金」で必要
}
 
const ONE_MILLION = 1_000_000;
 
// 実効手数料率（%）を返す。Play 課金を使わない場合はビリング料5%を除く
function effectiveFeeRate(i: FeeInput): number {
  if (i.store === "apple") {
    // SBP 登録かつ当年 proceeds が100万ドル以下なら15%、それ以外は30%
    const eligible = i.enrolledOrPlayBilling && i.ytdProceedsUsd <= ONE_MILLION;
    return eligible ? 15 : 30;
  }
 
  // Google Play（2026-06-30 以降の対象市場）
  const billingFee = i.enrolledOrPlayBilling ? 5 : 0;
 
  if (i.kind === "subscription") {
    // サブスクはサービス料一律10%（100万ドルの崖なし）
    return 10 + billingFee;
  }
 
  // その他課金: 100万ドル以下は10%、超過後は新規20%/既存25%
  let serviceFee = 10;
  if (i.ytdProceedsUsd > ONE_MILLION) {
    serviceFee = i.installType === "existing" ? 25 : 20;
  }
  return serviceFee + billingFee;
}
 
// 使用例: 少額サブスクを Play 課金で提供する個人開発アプリ
console.log(
  effectiveFeeRate({
    store: "google",
    kind: "subscription",
    ytdProceedsUsd: 40_000,
    enrolledOrPlayBilling: true,
  })
); // => 15
 
// Apple SBP 登録済み・当年 proceeds 4万ドル
console.log(
  effectiveFeeRate({
    store: "apple",
    kind: "subscription",
    ytdProceedsUsd: 40_000,
    enrolledOrPlayBilling: true,
  })
); // => 15

このコードのねらいは、率を条件から導出することで「うろ覚えの15%」を排除する点にあります。とくに Google の非サブスク課金は installType と ytdProceedsUsd の組み合わせで4通りに分岐するため、暗算より関数に任せた方が確実です。年間累計を引数に取っているので、月次の売上集計から ytdProceedsUsd を渡せば、閾値を跨ぐ月の実効率も自動で切り替わります。

手取りと損益分岐に手数料を織り込む

実効率が出たら、価格から手取りを逆算します。月額サブスクを例に、実効15%で運用する場合の手取りを見てみます。

ここに、決済に伴う為替・税、そして Rork 有料プランやバックエンド（Cloudflare Workers、RevenueCat など）の固定費を重ねて初めて、事業としての損益分岐が見えます。私が複数のアプリを運営していて痛感したのは、手数料を「あとで効いてくる控除」として曖昧にしたまま単価を決めると、想定 MRR に届いていても手取りが目標に届かない、という取り違えが起きることです。

値付けの現場では、手数料込みの手取りを先に決めてから表示価格を逆算する方が安定します。サブスクの価格設計そのものはサブスクリプションの価格設計原則で、通貨・地域ごとの表示はStoreKit 2 の通貨・ロケール別価格設計で詳しく扱っています。

申請と移行の実務チェックリスト

最後に、取りこぼしを防ぐための手順を整理します。

Apple 側では、まず App Store Connect の売上・財務レポートから前暦年の proceeds を USD 換算で概算し、100万ドル以下であることを確認します。関連アカウントがあれば合算します。次に最新の有料アプリ契約に同意し、SBP へ登録します。適用は承認会計月末＋15日後からなので、この日付を値上げや新規サブスク開始のタイミングと揃えると初月から15%で回せます。

Google 側では、新料金が自分の配信市場で始まっているかを Play Console で確認します（米・英・EEA が先行、他市場は順次）。サブスクは一律10%（Play 課金なら+5%）である一方、非サブスク課金は100万ドル超で新規・既存の別が効くため、非サブスク比率が高いアプリは自分の売上構成で試算しておきます。外部課金や自社サイトリンクでビリング料5%を外す選択肢もありますが、決済・返金・税を自前で負う負担と天秤にかけて判断します。

複数ストア・複数アプリの手取りを突き合わせて把握する運用は、AdMob・App Store・Play・Stripe の売上を6アプリで突合するで扱っています。手数料の構造を理解したうえで、実際の入金と照合する仕組みまで作っておくと、閾値跨ぎのような変化にも早く気づけます。

まとめ

まずは今日、自分のアプリ1本について実効手数料を出してみてください。ストア・課金の種類・当年の累計 proceeds・課金方式を上の関数に入れれば、暗記していた率とのずれが見えるはずです。そのずれこそが、これまで値付けから漏れていた分です。手数料は避けられない控除ですが、構造を理解すれば設計できる変数になります。私自身もまだ市場ごとのロールアウトを追いかけている途中ですが、分かったことは記事として共有していけたらと思います。お読みいただきありがとうございました。