Google Playの変更とEpicとの和解：サードパーティ・モバイル・ビリングのアーキテクチャ設計
モバイルゲーム開発者なら誰しも、毎月の収益ダッシュボードを見て、30%のプラットフォーム手数料によって利益が瞬時に消えていくのを目の当たりにし、顔をしかめたことがあるでしょう。長年、Android開発者は硬直したエコシステムに閉じ込められてきました。世界最大のモバイルストアにゲームを掲載したければ、独自のビリングシステムを使用し、マイクロトランザクションの大部分を明け渡し、特定のAPIを中心にエンタイトルメント（権利）アーキテクチャ全体を構築しなければなりませんでした。
その時代は正式に終わりを迎えようとしています。google play changes epic settlement（Google Playの変更とEpicとの和解）によって導入された条件を最大限に活用するために、開発者はバックエンドインフラを根本から再考する必要があります。
Epic Games対Googleの法廷闘争の終結により、裁判所が命じた変更によってAndroidエコシステムが大きく開放されました。開発者はプレイヤーを外部のPayment Gatewayに誘導し、義務的な30%の税を回避し、Google Play内で直接ホストされる代替アプリストアを通じて配信することさえ可能になりました。
しかし、この新たな経済的自由には、厳しい技術的コストが伴います。Google Play Billingを放棄すれば、それが提供していた自動のReceipt Validation（レシート検証）、オフラインキャッシュ、一元化されたエンタイトルメント追跡を失うことになります。複数のPayment Gatewayにわたるプレイヤーの購入を安全に管理する責任は、すべてあなたにあります。
ここでは、これらの変更が技術的にどのような影響を与えるか、そして不正を防ぎ、ワールドの状態を同期させる、ストアに依存しない安全なビリングバックエンドをどのように設計すべきかを深く掘り下げます。
Epic対Google和解の技術的影響
コードに入る前に、裁判所の差し止め命令（2024年11月から2027年11月まで有効）がゲームのアーキテクチャに具体的に何をもたらすかを理解する必要があります。
1. 外部決済ルーティングの合法化
Googleは、購入を完了させるためにプレイヤーをウェブブラウザに誘導するリンクを含んでいることを理由に、ゲームを禁止することができなくなりました。つまり、Stripe、Xsolla、PayPalなどの決済プロバイダーを統合できるということです。これらは通常、1トランザクションあたり約2.9%〜5%プラス少額の固定手数料しかかかりません。マイクロトランザクションで月に50,000ドルを売り上げるミッドコアのインディーゲームの場合、30%のプラットフォーム手数料から脱却することで、毎月約12,500ドルを節約できます。
2. サイドローディングとサードパーティストア
代替アプリストアをGoogle Playストアを通じて直接配布できるようになり、GoogleがデバイスメーカーにGoogle Playのみをプリインストールさせるために報酬を支払うことが禁止されました。プレイヤーは、Epic Games Store、Amazon Appstore、またはパブリッシャー独自のランチャーからゲームをダウンロードし、同じAndroidデバイスでプレイすることになります。
3. 単一ソース・エンタイトルメントの終焉
従来、ゲームクライアントはGoogle Play Billing Libraryに対して「このユーザーはプレミアムバトルパスを所有しているか？」と問い合わせるだけで済みました。答えが「はい」であれば、コンテンツをアンロックしていました。
今後は、プレイヤーがPC上のStripe決済リンクでバトルパスを購入し、代替Androidストアからダウンロードしたゲームにログインして、コンテンツがそこにあることを期待するかもしれません。クライアントサイドの検証（Client-side validation）は正式に死にました。バックエンドをすべてのプレイヤーインベントリの唯一の真実のソース（Single Source of Truth）とする、Server-authoritativeなアーキテクチャに移行する必要があります。
ストアに依存しないエンタイトルメント・バックエンドの設計
複数のPayment Gatewayをサポートするには、「金銭的取引」と「ゲーム内の権利（Entitlement）」を切り離した堅牢なデータベーススキーマがバックエンドに必要です。
プレイヤーのインベントリを特定のストアのレシートIDに直接紐付けてはいけません。代わりに、中間のトランザクションテーブルを使用します。
推奨されるデータベーススキーマ
これを手動で構築する場合、リレーショナルデータベース（PostgreSQLなど）に3つのコアテーブルが必要になります。
Users: コアとなるプレイヤープロファイル。Transactions: 金銭的なイベントを記録。GatewayProvider（例: "Stripe", "Google", "Xsolla"）、GatewayTransactionId、Amount、Currency、Status（Pending, Completed, Refunded）を含みます。Entitlements: ユーザーが所有する実際のゲーム内アイテム。UserId、ItemId、AcquiredViaTransactionId、RevokedAtを含みます。
購入が発生すると、Payment GatewayはWebhookを使用してサーバーに通知します。サーバーはWebhookを検証し、TransactionsテーブルにCompletedレコードを作成し、対応するアイテムをEntitlementsテーブルに挿入します。
安全なサーバーサイドWebhook検証の実装
この新しいアーキテクチャで最も重要な部分は、Webhookハンドラーです。プレイヤーをサードパーティの決済ページに誘導する場合、決済が成功するとその外部プロバイダーからバックエンドにHTTP POSTリクエストが送信されます。
攻撃者は保護されていないWebhookエンドポイントを積極的にスキャンしています。エンドポイントが暗号署名を検証せずにJSONペイロードを盲目的に受け入れると、攻撃者は「決済成功」メッセージを偽造し、無限のプレミアム通貨を自分に付与してしまいます。
以下は、Express.jsを使用した本番環境対応のTypeScriptの例です。このスニペットは、StripeのWebhook署名を安全に検証し、べき等性（Idempotency）を確保し（Webhookが2回実行されてもプレイヤーに二重に課金されないようにする）、プレイヤーのデータベースを更新する方法を示しています。
import express from 'express';
import crypto from 'crypto';
import { PrismaClient } from '@prisma/client';
const app = express();
const prisma = new PrismaClient();
const WEBHOOK_SECRET = process.env.PAYMENT_WEBHOOK_SECRET || '';
// We need the raw body to verify the cryptographic signature
app.post('/api/webhooks/billing', express.raw({ type: 'application/json' }), async (req, res) => {
const signature = req.headers['x-payment-signature'] as string;
const rawBody = req.body;
// 1. Cryptographic Signature Verification
const expectedSignature = crypto
.createHmac('sha256', WEBHOOK_SECRET)
.update(rawBody)
.digest('hex');
if (signature !== expectedSignature) {
console.error("Security Alert: Invalid webhook signature detected.");
return res.status(401).send('Invalid signature');
}
const event = JSON.parse(rawBody.toString());
// 2. Process only successful payments
if (event.type === 'payment.success') {
const { transactionId, playerId, itemId } = event.data;
try {
// 3. Database Transaction with Idempotency Check
await prisma.$transaction(async (tx) => {
// Check if we already processed this transaction (Idempotency)
const existingTx = await tx.transaction.findUnique({
where: { gatewayTransactionId: transactionId }
});
if (existingTx) {
console.log(`Transaction ${transactionId} already processed. Skipping.`);
return;
}
// Log the financial transaction
const newTx = await tx.transaction.create({
data: {
gatewayTransactionId: transactionId,
provider: 'CustomStripeGateway',
status: 'COMPLETED',
playerId: playerId
}
});
// Grant the in-game entitlement
await tx.entitlement.create({
data: {
playerId: playerId,
itemId: itemId,
acquiredViaTransactionId: newTx.id
}
});
console.log(`Successfully granted item ${itemId} to player ${playerId}`);
});
return res.status(200).send('Webhook processed');
} catch (error) {
console.error("Database error during webhook processing:", error);
return res.status(500).send('Internal Server Error');
}
}
// Acknowledge other event types without crashing
return res.status(200).send('Event ignored');
});
ペイロード・ハーデニングの重要性
上記のコードが、JSONにパースする前にリクエストの正確なバイトストリームをキャプチャするためにexpress.raw()を使用していることに注目してください。JSONペイロード内のスペースが1つずれているだけでも、HMACハッシュの不一致につながります。
これらのエンドポイントのセキュリティ保護は必須です。業界の重大なインシデントで見られるように、偽装されたHTTPリクエストに対してバックエンドを強化（Hardening）しないことは、ゲーム経済を破綻させる確実な道です。公開されたAPIがいかに壊滅的なエクスプロイトを招くかについての詳細は、こちらの分析をご覧ください：The Star Citizen Data Breach Explained Architecting Game Backends To Survive Compromises。
リアルタイム同期問題の解決
バックエンドのエンタイトルメント・ロジックは解決しましたが、今度はUXの問題に直面します。
プレイヤーのフローを想像してください：
- プレイヤーがAndroidゲーム内で「1000コイン購入」をタップする。
- ゲームがデバイスのウェブブラウザを開き、カスタム決済ページを表示する。
- プレイヤーがクレジットカードで決済を完了する。
- Payment GatewayがサーバーにWebhookを送信する。
- プレイヤーがゲームアプリに戻る。
ゲームクライアントはどうやって購入が成功したことを知るのでしょうか？HTTP Polling（クライアントがサーバーに「もう買った？」と3秒ごとに問い合わせる）に頼ると、デバイスのバッテリーを消耗させ、無意味なリクエストでバックエンドを圧迫することになります。
代わりに、データベースのトランザクションがコミットされた瞬間に、バックエンドからクライアントへ更新されたインベントリ状態をプッシュする必要があります。これには、永続的な双方向接続が必要です。このインフラをゼロから構築する場合、データベースイベントをリッスンし、アクティブなクライアントセッションにブロードキャストするWebSocketレイヤーを実装する必要があります。
このアーキテクチャの構築に苦労している場合は、こちらのガイドでリアルタイム・プッシュ通知の実装方法を学ぶことができます：Ditch Http Polling An Unreal Engine Websockets Tutorial For Real Time Backends。
サードパーティ・モバイル・ビリングの5つのベストプラクティス
エコシステムの新しい変更を活用するために、標準のGoogle Play Billingライブラリから移行する場合は、以下の5つのアーキテクチャ上のベストプラクティスを遵守してください。
- 厳格なべき等性（Idempotency）の適用: モバイルデバイスではネットワークタイムアウトが頻繁に発生します。サーバーの応答が遅すぎると、Payment Gatewayが同じ「成功」Webhookを3回送信してくる可能性があります。アイテムを付与する前に必ずデータベースで
TransactionIdを確認し、プレイヤーにアイテムが誤って重複付与されないようにしてください。 - チャージバック取り消しの自動化: サードパーティ・ビリングを使用するということは、チャージバックや返金の処理に責任を持つということです。Webhookハンドラーは
payment.refundedイベントをリッスンし、Entitlementsテーブルの対応する行に自動的にRevoked（取り消し）フラグを立てる必要があります。これを怠ると、プレイヤーはクレジットカードの返金を受けながらプレミアム通貨を保持し続けられることに気づくでしょう。 - クライアントとゲートウェイの分離: ゲームクライアントがPayment GatewayのAPIと直接通信してはいけません。クライアントはバックエンドに決済セッショントークンを要求し、そのトークンでウェブビューを開き、実際のトランザクション検証はバックエンドに任せるべきです。
- 疎性（Graceful Degradation）の実装: データベースがダウンしても、ゲームはプレイ可能であるべきです。暗号化されたセーブファイルを使用してデバイスローカルにエンタイトルメントをキャッシュしますが、プレイヤーがプレミアム通貨を消費したりマルチプレイヤーマッチに参加したりする際には、必ずサーバーサイドの真実と照らし合わせて検証してください。
- 仮想通貨パイプラインの統一: データベース内に「Googleコイン」と「Stripeコイン」を個別に作成しないでください。バックエンドですべての法定通貨取引を単一の統一された仮想通貨IDにマッピングし、ゲームのUIロジックで大きな混乱が生じないようにしてください。
インフラの自作 vs 購入の現実的な判断
Epic対Googleの和解は開発者の収益にとって大きな勝利ですが、インフラの負担が直接あなたの肩にかかってくることを意味します。
可用性の高い、ストアに依存しないビリングバックエンドを構築するには、PostgreSQLデータベースのセットアップ、べき等性キャッシュのためのRedisの設定、安全なWebhookのためのSSL証明書の管理、リアルタイム更新のためのWebSocketサーバーの維持が必要です。小規模なインディーチームにとって、これは優に4〜6週間の専任バックエンドエンジニアリングの時間を要します。その時間は、本来ゲームを面白くするために費やされるべきものです。
これこそが、私たちが解消するアーキテクチャ上の摩擦です。horizOnを使用すれば、これらの複雑なバックエンドサービスは事前に構成された状態で提供されます。当社のプラットフォームは、サーバー間Webhook検証を安全に処理し、重複トランザクションを防止し、プレイヤーのインベントリをリアルタイムで自動同期する、ストアに依存しないエンタイトルメントシステムをすぐに利用可能な形で提供します。DevOpsエンジニアになることなく、サードパーティ・ビリングの経済的メリットを享受できます。
今後の展望
モバイルゲームのエコシステムは、ここ10年で最も重要な構造的変化を遂げています。「囲い込まれた庭」はついに崩れ去り、バックエンドアーキテクチャをプラットフォームに依存しない形に適応させた開発者は、従来の30%のプラットフォーム税を回避することで、莫大な経済的報酬を得ることになるでしょう。
しかし、この自由には技術的な責任が伴います。クライアントサイドの権限（Client-side authority）はもはや通用しません。マルチストア、マルチゲートウェイの世界で生き残るためには、バックエンドを絶対的な真実のソースとして扱う必要があります。
数千行のボイラープレートなインフラコードを書くことなく、マルチプレイヤーバックエンドをスケールさせ、安全なクロスプラットフォーム・エンタイトルメントを実装する準備はできていますか？horizOnを無料でお試しください。サーバーアーキテクチャは私たちに任せて、あなたはゲームのリリースに集中してください。