PlayFabとは？料金プラン・無料枠・Unity SDKの導入手順【2026年10月時点】

PlayFab（Azure PlayFab）は、Microsoftが提供するゲーム向けのバックエンドサービスです。プレイヤーのログイン、セーブデータ、ランキング、ゲーム内通貨、マッチメイキング、専用サーバーといった、オンラインゲームの運営に必要なサーバー側の機能をAPIとして提供します。自前でサーバーやデータベースを立てずに、Unity・Unreal Engine・独自エンジンから呼び出して使えます。

この記事では、2026年10月23日時点の公式ドキュメントと料金ページをもとに、PlayFabでできること、プランごとの料金とメーター単価、無料で使える範囲、UnityでのSDK導入、ランキングの読み出し、APIの呼び出し方を整理しました。2026年3月に始まったXbox向けの無料枠「Foundation Mode」、新規タイトルでクライアントの匿名ログインによるプレイヤー作成が既定で無効になった仕様、11月1日から新規タイトルでv1のランキングAPIが使えなくなる変更など、古いサンプルのままでは動かない点も扱います。

まとめ：PlayFabの料金・無料枠・導入の要点

• PlayFabは、認証・プレイヤーデータ・エコノミー・マルチプレイヤー・ランキング・分析をまとめて提供するゲーム用バックエンドです。必要な機能だけを選んで使えます。
• 料金は、月額0ドルの従量課金（Pay-as-you-go）、月額99ドルのStandard、月額1,999ドルのPremiumの3プランです。StandardとPremiumには、メーターごとに定められた月間利用量が含まれます。
• 開発中のタイトルはDevelopment Modeで無料です。ただし1タイトルあたり累計1,000プレイヤーまでで、超えると新しいプレイヤーを作れません。
• Xboxで発売する新規タイトルは、2026年3月11日にプレビューが始まったFoundation Modeで、中核サービスを追加費用なしで使えます。専用サーバーやクラシックCloudScriptは対象外です。
• 2025年6月30日以降に作ったタイトルでは、クライアントの匿名ログイン（Custom ID・端末ID）で新しいプレイヤーを作れません。プレイヤーの作成はサーバー側のAPIで行います。
• Unityの新しいSDK（v2）はWindowsとXbox専用です。スマートフォン向けのゲームは、従来のSDK（v1）で組みます。
• 2026年11月1日以降に作るタイトルは、v1のEconomy・Statistics・Leaderboardsを呼べません。新規開発はv2のAPIで組みます。

以下、機能・料金・無料枠・導入手順・APIの順に説明します。

PlayFabでできること：7つのサービス領域

公式ドキュメントのPlayFab とは?は、PlayFabの機能を次の7つの領域に分けて説明しています（ほかにGDPR・COPPAへの対応をコンプライアンスとして挙げています）。どれか1つだけを使うことも、複数を組み合わせることもでき、自社サーバーと併用する構成も想定されています。

運営作業の窓口になるのが、ブラウザで使う管理画面「Game Manager」（developer.playfab.com）です。タイトルの作成、アイテムやランキングの定義、プレイヤーの検索やBAN、イベントの監視をここで行います。

Azure PlayFabとPlayFabの関係

同じサービスです。PlayFabはもともと独立した企業が開発したサービスで、Microsoftが2018年1月29日に買収を発表し、以降はAzureのサービス群の1つ「Azure PlayFab」として提供されています。現在の公式ドキュメントはMicrosoft LearnのXbox配下（learn.microsoft.com/xbox/playfab）に移っています。

名前にAzureが付いていますが、PlayFab本体の利用にAzureのサブスクリプションは要りません。支払いはクレジットカード、PlayFabの請求書、Azure・Microsoftのエンタープライズ契約の3通りから選べます。Azure側の契約と課金が発生するのは、サーバー側の処理をAzure Functionsで書く場合（CloudScript using Azure Functions）や、Data Connectionsでイベントの転送先に自分のAzureストレージなどを使う場合です。

対応プラットフォームとSDKの種類

対象はPC・コンソール・モバイル・ストリーミング端末で、Xbox、Steam、PlayStation 5・4、Nintendo Switch、App Store、Google Playと連携できます。SDKは、ほぼ全機能を扱う「Services SDK」、通信とチャットの「Party SDK」、専用サーバー用の「Game Server SDK（GSDK）」、「Lobby and Matchmaking SDK」の4系統に分かれ、Unity・Unreal Engine・独自エンジン向けが用意されています。APIはHTTPSのRESTなので、SDKが無い言語からも呼び出せます。

PlayFabの料金プランと従量課金の単価

PlayFabの料金は、タイトルを本番公開（Live）した後の利用量に応じて決まります。Development Modeの中核サービス利用量は課金対象外です（次章参照）。専用サーバーやAzure Functionsの計算費用は、それぞれの無料枠・料金条件を確認します。

3つの料金プランの違い

どのプランもLiveタイトル数とプレイヤー数に上限はありません。月額基本料と含まれる利用量はアカウント単位で、同じアカウントに紐づくLiveタイトルの利用量を合算します。メーターごとの含み量を超えた分は、プランごとの従量単価で請求されます。これより大きな規模向けに、PlayFabへの問い合わせが必要なEnterpriseプランもあります。

主なメーターの単価

従量課金は機能ごとの「メーター」で計量されます。料金ページに載っている主なメーターの単価は次のとおりです（2026年10月23日時点）。

イベントとプロフィールの読み書きは、1KB単位で数えられます。平均2KBのイベント10件は20件分として請求されるため、イベントに載せるデータを小さく保つことが、そのまま請求額の削減になります。プレイヤーデータの書き込みはキーと値の組ごとに最低1KBとして数えられ、100バイトのキーを10個書くと10回分、同じ10個を読むと合計1KBなので1回分です。プロフィール書き込みの単価は読み取りの約22倍なので、キーを細かく分けて頻繁に書く設計は避け、ステージ終了時などにまとめて書き込みます。

単価の出典：PlayFab公式の料金ページ（2026年10月23日確認）

月額の試算：Pay-as-you-goとStandardの分岐点

料金ページの単価で、1か月の計量値がPlayStreamイベント1,000万件、プロフィール読み取り3,000万回、プロフィール書き込み500万回、ランキング読み取り1,000万回になるタイトルを試算しました。ここでの数字はAPIの呼び出し回数ではなく、1KB単位・キー単位で数えた後のメーターの値です。

表の4メーターと月額基本料だけを比較すると、Standardの方が13.65ドル安くなります。保存容量など、表に含めていないメーターの料金や税金は別途加算します。Pay-as-you-goでの月額が99ドルを超え、かつ利用量がStandardの含み量に収まっている間は、Standardに上げた方が得です。逆に月額が数十ドルのうちはPay-as-you-goのままで構いません。見積もりはGame Managerの「Billing Summary」で日次に確認できますが、一部のメーターは48時間以上遅れて反映されるため、月末の数字だけで判断しないようにします。

Multiplayer Servers（専用サーバー）の課金

専用サーバーのホスティング（Multiplayer Servers）は、上の3プランとは別に、仮想マシンの稼働時間とインターネット向けの送信量で課金されます。有効化すると評価用の無料枠が付き、米国東部と北ヨーロッパのリージョンでそれぞれ月750コア時間（Dasv4）、同時24コアまで使えます。送信量の無料枠はリージョンではなくネットワークのゾーン単位で、Zone 1（米州・EMEA）、Zone 2（アジアなど）、Zone 3（ブラジルなど）にそれぞれ10GBです。無料枠を超えた送信量の単価は、Zone 1が1GBあたり0.05ドル、東日本・西日本リージョンを含むZone 2が0.08ドル、Zone 3が0.16ドルで、日本のプレイヤー向けに国内リージョンでサーバーを動かすと、送信量の単価はZone 1の1.6倍です。公式ドキュメントの請求例では、D2v2（米国東部）が1VM時間あたり0.252ドルです。

VMの時間単価は2026年11月1日に改定され、公開価格で請求されるタイトルは平均で約6%上がります。10月31日までは現行の単価です。リージョン別・日付別の単価は料金ページの「VM Hourly Rates」で、改定前と改定後を切り替えて確認できます。

無料枠はコア時間で数えるため、2コアのVMを使うと稼働できるのは375時間になります。公式ドキュメント自身が「ライブゲームを始めるには通常足りない」と書いている量なので、評価用と割り切ります。

無料で使える範囲：Development ModeとFoundation Mode

「PlayFabは無料で使えるか」の答えは、タイトルの状態によって変わります。新しく作ったタイトルは開発用の無料枠から始まり、Xboxで発売するタイトルにはもう1つ別の無料枠があります。

Development Mode：累計1,000プレイヤーまで無料

作成したタイトルは、既定でDevelopment Modeになります。この間の利用量は請求の対象外で、月額もかかりません。1スタジオあたり10タイトルまで作れます。1タイトルあたりの主な上限は次のとおりです。

1,000人は月間アクティブではなく、これまでに作成したプレイヤーの累計です。テストでプレイヤーを作っては消す運用でも枠は減っていくため、自動テストは同じCustom IDを使い回すようにします。上限に達すると新規プレイヤーを作れなくなります（ログインAPIのエラーコード一覧にあるEvaluationModePlayerCountExceeded（1490）がこの状態です）。公開するときはGame Managerの「Launch」でLiveに切り替えると、これらの制限が外れて課金が始まります。

Foundation Mode：Xboxで発売するタイトル向けの無料枠

Foundation Modeは、Xboxで発売する（または発売を予定している）タイトルに、PlayFabの中核サービスを追加費用なしで提供する枠です。2026年3月11日（GDC 2026）にパブリックプレビューが始まりました。支払い手段の登録もAzureのサブスクリプションも不要で、月間の利用量の上限もありません（API単位のレート制限はあります）。Xbox版だけでなく、同じタイトルのPlayStation・Switch・Steam・スマートフォン版のプレイヤーにも使えます。

対象になる条件は、Game Managerにスタジオを登録し、XboxのPartner Centerのスタジオと製品にPlayFabアカウントを紐づけることです。プレビュー中は新規タイトルのみが対象です。Microsoft Entra IDでGame Managerにサインインし、スタジオ設定の「Preview Features」から利用を申請して、承認後にFoundation Modeのタイトルを作成します。既存タイトルの移行は2026年後半に予定されています。公式ドキュメントには、Development ModeをFoundation Modeへ置き換えていく方針も書かれています。

含まれるのは、認証、タイトルデータ、Azure Functionsの呼び出し、ロビー、マッチメイキング、Party、フレンド、グループ、ランキング、統計、クラウドセーブ、カタログ、インベントリなどです。一方、専用サーバー（Multiplayer Servers）、クラシックCloudScript、UGC、セグメントとA/Bテスト、独自のTelemetryイベント、v1のEconomy・Statistics・Leaderboardsは含まれず、呼ぶと権限エラーになります。Azure Functionsの計算コストは、自分のAzureサブスクリプションに別途請求されます。

出典：PlayFab Modes（Microsoft Learn）

UnityでPlayFabを使う手順

UnityからPlayFabを使うSDKは、2026年10月時点で2系統あります。最初にどちらを使うかを決めます。

SDKの選び方：v1（従来版）とv2（Unified）

公式ドキュメントは「新規プロジェクトはすべてv2を使う」と案内していますが、v2はネイティブライブラリをC#から呼ぶ構造で、現時点で動くのはWindowsとXboxだけです。スマートフォン向け、またはスマートフォン版も出す予定のゲームはv1を選びます。v1とv2は同じプロジェクトに同居できません。v2を入れるときは、Unityの「Window > Package Manager」で「Install package from git URL」を選び、https://github.com/PlayFab/PlayFabSDK_Unity.gitを指定します（v2のインストールガイド）。なお、ここでのv1・v2はSDKの世代で、後述するサービスAPIのv1・v2（Statistics・Leaderboardsなど）とは別物です。v1 SDKにも、v2のStatistics・Leaderboardsを呼ぶPlayFabProgressionAPI（UpdateStatistics・GetLeaderboard）が含まれています。SDKの対応環境の出典はPlayFab for Unity (v2 Unified)、v1の版番号と公開日はUnitySDKのリリース一覧（GitHub）です。Unity 6系の環境についてはUnity 6.3 LTSの新機能と変更点を参照してください。

Game Managerでのアカウント登録とタイトル作成

SDKを入れる前に、管理画面でTitle IDを発行します。手順は公式のPlayFabアカウントの作成ガイドに沿っています。

1. developer.playfab.comのサインアップ画面で「Sign up with Microsoft」を選び、Microsoftアカウントで登録します。
2. Game Managerにサインインし、連絡先とスタジオの情報を入力します。スタジオを作ると「My Game」という仮のタイトルが1つできます。
3. 別のタイトルを作るときは、スタジオの「…」メニューから「New title」を選びます。
4. 「My Studios and Titles」のページで、ゲーム名の下に表示される英数字の文字列がTitle IDです。APIの呼び出しにはこの値を使います。

作ったタイトルはDevelopment Modeから始まるので、ここまでは費用がかかりません。今から作るタイトルは2025年6月30日より後の作成になるため、後述する匿名ログインの制限が最初から適用されます。

Editor ExtensionsでのSDK導入とTitle ID設定

v1の導入手順です。公式のクイックスタートは、Editor Extensions経由と、GitHubで配布されているSDKのunitypackageを直接インポートする方法の2通りを案内しています。ここではTitle IDの設定まで画面から済ませられるEditor Extensionsを使います。

1. 公式の「PlayFab Unity Editor Extensions」のunitypackage（クイックスタートの配布リンクはUnitySDKのGitHubリポジトリのPackagesフォルダにあるPlayFabEditorExtensions.unitypackageを指します）をダウンロードし、Unityプロジェクトを開いた状態でダブルクリックしてインポートします。
2. 開いたEditor Extensionsパネルで「Install PlayFab SDK」を選びます。パネルが閉じた場合は、メニューのWindow > PlayFab > Editor Extensionsで開き直せます。
3. メニューのPlayFab > MakePlayFabSharedSettingsで設定ファイル（PlayFabSharedSettings.asset）を作り、インスペクターにTitle IDを入れます。

設定ファイルにはDeveloper Secret Keyの欄もありますが、クライアント向けのビルドでは空のままにします。秘密鍵はサーバー用APIをすべて呼べる鍵なので、アプリに含めると解析で抜き取られます。HTTPの送信方式は既定のUnity Web Requestのままで構いません（仕組みはUnityWebRequestの使い方で解説しています）。

LoginWithCustomIDでの接続確認と新規タイトルの制限

2025年6月30日以降に作成したタイトルでは、クライアント側の匿名ログインAPI（LoginWithCustomID・LoginWithAndroidDeviceID・LoginWithIOSDeviceIDなど）は、CreateAccount = trueを付けても新しいプレイヤーを作りません。作ろうとするとPlayerCreationDisabledエラーが返り、ログインできるのは既存のプレイヤーだけです。不正なクライアントから大量にアカウントを作られるのを防ぐための仕様です。

動作確認のときだけは、Game Managerのタイトル設定の「API Features」タブで、匿名ログインでのプレイヤー作成を禁止するチェックを外すと作成できるようになります。公式は開発・テスト中だけに限り、本番前に必ず戻すよう求めています。その状態で次のスクリプト（PlayFabLogin.cs）を空のGameObjectに付けて再生し、コンソールに成功のログが出れば接続できています。

using PlayFab;
using PlayFab.ClientModels;
using UnityEngine;

public class PlayFabLogin : MonoBehaviour
{
    void Start()
    {
        var request = new LoginWithCustomIDRequest
        {
            CustomId = "GettingStartedGuide",
            CreateAccount = true  // 未登録なら新しいプレイヤーを作る
        };
        PlayFabClientAPI.LoginWithCustomID(request, OnSuccess, OnFailure);
    }

    void OnSuccess(LoginResult result)
    {
        Debug.Log($"ログイン成功: PlayFabId={result.PlayFabId} 新規={result.NewlyCreated}");
    }

    void OnFailure(PlayFabError error)
    {
        Debug.LogError(error.GenerateErrorReport());
    }
}

Title IDは設定ファイルから読まれるので、コードに書く必要はありません。再生のたびに同じCustom IDでログインするため、Development Modeの1,000人枠も減りません。本番では、プレイヤーの新規作成を自社サーバーやAzure Functionsから秘密鍵付きのServer/LoginWithCustomIDで行い、クライアントのClient/LoginWithCustomIDは既存プレイヤーのログインに使います。

スマートフォン向けのログイン方法

公式クイックスタートは、固定のCustom IDを使う上のサンプルをモバイルのタイトルにそのまま使わないよう注意しています。スマートフォンでは端末IDでログインするLoginWithAndroidDeviceID・LoginWithIOSDeviceIDか、Apple・Google Play Games・Facebookなどのアカウントでログインします。端末IDのログインも匿名ログインの一種なので、新規タイトルではプレイヤーの作成をサーバー側で行う点は同じです。匿名ログインだけだと機種変更でデータを引き継げないため、後からメールアドレスやプラットフォームのアカウントを紐づける導線を用意しておきます。

Unityからのv2ランキング取得（PlayFabProgressionAPI）

2026年11月1日以降に作るタイトルでは、v1のGetLeaderboard（Client API）が使えません（後述）。v1 SDKのままでも、同梱のPlayFabProgressionAPIを使えばv2のランキングを読めます。次の例は、ログイン済みのプレイヤーとして上位10件と自分の前後2件ずつを取得します。LeaderboardReaderをGameObjectに付け、ログイン成功後にそのコンポーネントのShowRankingを呼び出します。引数にはLoginResult.EntityToken.EntityのIdとTypeを渡します。前提として、Game Managerの「Progression」で、エンティティ型がtitle_player_account、列が1つの統計HighScoreを作成し、その統計の列にリンクしたランキングHighScoreを定義しておきます。後述のREST例で統計を更新してから、ランキングを読み出します。

using PlayFab;
using PlayFab.ProgressionModels;
using UnityEngine;

public class LeaderboardReader : MonoBehaviour
{
    // ログイン成功時の LoginResult.EntityToken.Entity の Id と Type を渡す
    public void ShowRanking(string entityId, string entityType)
    {
        // 上位10件（StartingPosition は1始まり、PageSize は1〜100）
        PlayFabProgressionAPI.GetLeaderboard(new GetEntityLeaderboardRequest
        {
            LeaderboardName = "HighScore",
            StartingPosition = 1,
            PageSize = 10
        }, OnLeaderboard, OnError);

        // 自分の前後：4を指定すると上下2件ずつ（端では偏る）
        PlayFabProgressionAPI.GetLeaderboardAroundEntity(new GetLeaderboardAroundEntityRequest
        {
            LeaderboardName = "HighScore",
            Entity = new EntityKey { Id = entityId, Type = entityType },
            MaxSurroundingEntries = 4
        }, OnLeaderboard, OnError);
    }

    void OnLeaderboard(GetEntityLeaderboardResponse result)
    {
        foreach (var entry in result.Rankings)
        {
            Debug.Log($"{entry.Rank}位 {entry.DisplayName} {string.Join(",", entry.Scores)}");
        }
    }

    void OnError(PlayFabError error)
    {
        Debug.LogError(error.GenerateErrorReport());
    }
}

リクエストとレスポンスの型名（GetEntityLeaderboardRequest・GetLeaderboardAroundEntityRequest・Rankings）は、UnitySDK 2.244.260922のソースで確認したものです。GetLeaderboardのRESTリファレンスが許可するトークンはtitle・title_player_account・game_serverの3種類で、プレイヤーとしてログインしたときに得るトークンのまま呼べます。v1のGetLeaderboardとメソッド名は同じですが、名前空間がPlayFab.ProgressionModelsで、スコアは文字列の配列（Scores）で返ります。DisplayNameはProfiles APIのSetDisplayNameで表示名を設定したプレイヤーだけに入ります。

スコアの書き込み（UpdateStatistics）もクライアントから呼べますが、統計のクイックスタートは、書き込みをゲームサーバーからタイトルのエンティティで行い、プレイヤーとしてのログインは読み取りに使う構成を推奨しています。クライアントが任意のスコアを送れる構成は、改造したクライアントからの不正なスコアを防げません。書き込みの呼び出し例は次章のRESTで示します。

PlayFab APIの呼び出し方（REST）

SDKの中身はHTTPSのREST APIです。エンドポイントはhttps://{TitleId}.playfabapi.com/{サービス名}/{API名}の形で、すべてPOSTでJSONを送ります。クライアント用のClient/LoginWithCustomIDは認証ヘッダーが要りません（サーバー用のServer/LoginWithCustomIDは秘密鍵が必要です）。前章の制限により、新規タイトルでは次の例でログインできるのは作成済みのプレイヤーだけです。

curl -X POST "https://{TitleId}.playfabapi.com/Client/LoginWithCustomID" \
  -H "Content-Type: application/json" \
  -d '{"TitleId": "{TitleId}", "CustomId": "test-user-001"}'

応答のSessionTicketがClient API用の認証情報になります。一方、v2のStatistics・Leaderboards・Economyは、プレイヤーやタイトルを「エンティティ」として扱うAPIで、X-EntityTokenヘッダーでエンティティトークンを渡します。前章のとおり書き込みはゲームサーバー側から行う構成が推奨なので、次の例ではサーバーでタイトルの秘密鍵からトークンを取ってから統計を更新します。

# 1. 秘密鍵でタイトルのエンティティトークンを取得（サーバー側だけで実行）
curl -X POST "https://{TitleId}.playfabapi.com/Authentication/GetEntityToken" \
  -H "Content-Type: application/json" \
  -H "X-SecretKey: ${PLAYFAB_SECRET_KEY}" \
  -d '{}'

#    応答のdata.EntityTokenを環境変数ENTITY_TOKENに入れて次へ渡す

# 2. 取得したトークンでプレイヤーのスコアを更新（v2 Statistics）
#    前提：Game Managerで列が1つの統計HighScoreを定義済み。Idはプレイヤーのtitle_player_account ID
curl -X POST "https://{TitleId}.playfabapi.com/Statistic/UpdateStatistics" \
  -H "Content-Type: application/json" \
  -H "X-EntityToken: ${ENTITY_TOKEN}" \
  -d '{"Entity": {"Id": "{プレイヤーのtitle_player_account ID}", "Type": "title_player_account"},
       "Statistics": [{"Name": "HighScore", "Scores": ["1200"]}]}'

スコアが文字列の配列になっているのは、64ビット整数を扱えないクライアントとの互換性のためです。v2のランキングはGame Managerの「Progression」で統計とランキングを定義してから使い、読み取りはLeaderboard/GetLeaderboardで行います。

2026年のPlayFab APIと機能の終了・変更予定

古い解説記事やサンプルコードのまま作ると動かない変更が、2026年に続いています。

影響が大きいのは11月1日の変更です（出典：Microsoft Game Devの告知、2026年9月21日）。この日以降に作ったタイトルでは、v1のUpdatePlayerStatisticsやGetLeaderboard（Client API）が受け付けられません。Unity向けのランキング実装例にはv1のこれらのAPIを使うものが多く、そのまま写すと新規タイトルでは動きません。既存タイトルはv1を使い続けられ、対応は不要です。

他のゲームバックエンドとの比較

PlayFabを検討するときに比べられることが多いサービスとの違いです。

PlayFabの強みは、コンソールを含む各プラットフォームのアカウント連携と、エコノミー・ランキング・マッチメイキングをゲーム用の機能として最初から持っている点です。Firebaseは認証やデータベースが汎用の部品なので、ランキングや仮想通貨は自分で組み立てます（Firebaseのデータ同期の仕組みはFirebase Realtime Databaseの解説を参照）。PlayFabのPartyは暗号化された低遅延のデータ通信とボイス・テキストチャットを提供しますが（Vivox・Photon Voiceとの比較はボイスチャットの実装方法で扱っています）、ゲーム状態をいつ・何を送って同期するかはゲーム側で実装します。キャラクターの位置やオブジェクトの同期まで任せたい場合は、Photon Fusionのような同期の仕組みを持つネットワークエンジンが候補になります。

なお、AmazonのGameSparksは2022年10月1日にコンソールへのアクセスが終了しました。マネージドのゲームバックエンドは提供元の方針で終わることがあるため、データを外部へ書き出せるかも選定時に確認します。PlayFabでは、プレイヤーごとの保存データはExportMasterPlayerData（Admin API）で、イベントはData Connectionsで外部に出せます。

PlayFabを採用すべき場面・避けるべき場面

PlayFabが最も効くのは、Xbox・PC・PlayStation・Switch・スマートフォンをまたいでアカウントと進行状況を共有するゲームです。Xboxで発売し、使う機能がFoundation Modeの対象範囲に収まるなら、中核サービスの利用料がかからない点で有利です（専用サーバーやAzure Functionsの計算費用は別にかかります）。ゲーム内通貨やシーズン制ランキングを運営したいモバイルゲームでは、既存APIで要件を満たせる部分のバックエンド実装を省けます。抽選処理やゲーム固有の報酬ルールは別途設計します。抽選の設計と排出率の考え方はソシャゲのガチャの仕組みにまとめています。

避けた方がよいのは、次の3つの場合です。1つ目は、WindowsとスマートフォンにUnityで出すゲームで、v2 SDKの利点（async/await、Party・ロビーの一体化）を前提に設計したい場合です。Windows側をv2にするとスマートフォン側はv1になり、2系統のSDKを抱えます。両方をv1で統一すれば避けられますが、その場合v2の利点は得られません。2つ目は、プレイヤーデータをリレーショナルに集計・検索したい業務寄りのアプリです。プレイヤーデータはキーと値の組で保存され、SQLのような結合や集計はできません。分析はData Connectionsで外部のデータ基盤へ出してから行う前提です。3つ目は、請求額の上限を厳密に固定したい場合です。従量課金のため、イベントの送りすぎやプロフィールの書き込みすぎがそのまま請求に跳ね返ります。

PlayFabを使ったゲームの設計・開発を外部に依頼したい場合は、弊社のゲームアプリ開発の支援内容をご覧ください。

PlayFabに関するよくある質問

PlayFabは無料で使えますか？

開発中はDevelopment Modeで無料です（1タイトルあたり累計1,000プレイヤーまで）。公開後はPay-as-you-goプランなら月額0ドルで、使った分だけ課金されます。Xboxで発売する新規タイトルはFoundation Modeで中核サービスを無料で使えます。

PlayFabの料金はいくらですか？

Pay-as-you-goは月額0ドル、Standardは月額99ドル、Premiumは月額1,999ドルで、超過分は従量単価で請求されます。例えばPlayStreamイベントは100万件あたり6.60ドル（Pay-as-you-go）です。

PlayFabのランキングとは何ですか？

プレイヤーのスコアなどの統計値を集計して順位を返す機能です。無期限のランキングのほか、一定期間でリセットする期間限定のランキングも作れます。2026年11月1日以降に作るタイトルではv2（Statistics・Leaderboards）を使います。

Unity以外のゲームエンジンでも使えますか？

使えます。Unreal Engine向けのSDKがあり、独自エンジンには独自エンジン向けのSDKかREST APIで組み込めます。Unityと同じく、新規タイトルで匿名ログインを使う場合は、プレイヤー作成をサーバー側で行います。2026年11月1日以降に作成するタイトルでは、Economy・Statistics・Leaderboardsにv2 APIを使います。

PlayFabを使うのにAzureの契約は必要ですか？

PlayFab本体はPlayFabアカウントだけで使え、Azureの契約は要りません。サーバー側の処理をAzure Functionsで書く場合や、Data Connectionsの転送先に自分のAzureストレージなどを使う場合は、Azure側の契約と課金が必要です。

関連記事

• Photon Fusionとは？Fusion 2.1の3モードの違い・料金・PUN2からの移行
• Unity 6.3 LTS（6000.3）の新機能と変更点｜最新パッチ・サポート期限・6.0からの移行
• UnityWebRequestの使い方｜GET・POST(JSON)・timeout・エラー処理とawait【Unity 6対応】
• Firebase Realtime Databaseとは｜JSONツリー同期の仕組みと転送量課金【2026年8月時点】
• ボイスチャットの実装方法｜WebRTC自作とVivox・Photon Voice等SDKの選び方【2026年10月】