mcpField
S
scenario-roblox-monetization

scenario-roblox-monetization

github.com/scenario-labs開発1.2k54 回インストール1 日前に更新
リポジトリ

scenario-roblox-monetization について

Roblox 開発者向けの収益化とライブ運用のスキルです。購入、特典、広告、分析、実験を扱い、保存済みレシートに基づく付与と、測定可能な基準に沿った設定変更を重視します。

主な機能

  1. 01一元管理の商品カタログ
  2. 02レシートに基づく購入付与
  3. 03サーバーで確認する特典
  4. 04プレイヤー別価格の表示
  5. 05有料ランダムアイテムの確率開示
  6. 06テレメトリーとライブ設定

活用シーン

  1. 01Developer Product 購入の実装
  2. 02プレイヤーごとの価格表示
  3. 03有料ランダムアイテムの確率開示
  4. 04ライブ機能実験の評価

MCP 対応

Roblox ツールキットを介して Studio MCP で収益化テストを実行し、Edit や Playtest セッションで結果を確認する方法を説明します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/scenario-labs/skills --skill scenario-roblox-monetization

インストール後、Claude Code で/scenario-roblox-monetizationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
critique.md
expert-notes.md
gui-paths.md
launch-liveops.md
procedures.md
sources.md
scripts/
rbx_monetization.py
scripts/agentkit/monetization/
Catalog.luau
Entitlements.luau
LiveConfig.luau
lune_mon_audit.luau
MonAudit.luau
Odds.luau
PriceText.luau
Purchases.luau
ShopRank.luau
Telemetry.luau

詳細

Robloxの収益化とライブ運営

対象:macOS上のRoblox Studio(2026年10月ビルド)。scenario-roblox-expertツールキットを通じて操作します。

ここでいうエキスパートレベルとは、すべてのRobuxの購入経路が、保存済みプロフィールで確認できたものだけを付与する単一のサーバー受領ハンドラーにつながっていること、価格と確率がエンジンまたは設定が管理する単一の情報源に基づいていること、そしてすべてのライブ変更が、その成否を判断する指標を伴って設定の背後からリリースされることを意味します。エージェントは未公開のプレイスでコードを作成・テストしますが、プロダクトの作成、ダッシュボード、ストア用アートのアップロードはオーナーが行います。

ここで名前を挙げた関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください (npx skills add scenario-labs/skills --skill <name>)。ユーザーの操作を待てない場合は、ツールのスキーマに基づいて進め、不足している点を明示してください。

必須の背景知識: scenario-roblox-expert(チャンネル、レビューの反復、ツールキット、現在のRobloxで注意すべき点)。

方針(エキスパートとして特に重視する点)

  1. 付与するのは受領ハンドラー内だけとし、保存完了後に限ります。 PurchaseGrantedは、保存済みプロフィールにPurchaseIdがあることを意味します。それ以外の場合はNotProcessedYetを返します。プロンプト完了イベントは支払いの証明にはなりません(Creator Docs、developer products;Stewiepfing)。ドキュメントのサンプルは、ハンドラーがnilを返すと付与済みとして応答します。レシートテストスイートは、このバグを再現します。
  2. サーバーごとにハンドラーは1つだけです。 新しいコードではBindReceiptHandlerを使います。レガシーコードでは、1つのScript内で一度だけProcessReceiptを割り当てます(MarketplaceServiceの参照)。本番環境では、2つ目の包括的なバインドはエラーになりますが、2つ目のProcessReceiptの割り当ては警告なしで受け入れられます。
  3. 価格はクライアント側でエンジンから取得します。 価格を固定すると、価格最適化が妨げられ、Plus加入者に実際には支払わない価格が表示されます(Creator Docs、managed pricing、Roblox Plus)。付与のためにサーバーが価格を知る必要はありません。
  4. 抽選と確率の開示には、プレイヤーごとの制限を適用した単一の確率テーブルを使います。 支出前に、すべての結果とその数値による確率を表示し、プレイヤーごとにArePaidRandomItemsRestrictedを確認します(Creator Docs、paid random items)。この確認後、サーバーからランダムアイテムのプロンプトを表示します[追加]。
  5. リリース時点で、収益化対象のすべての仕組みを手頃な価格で提供します。 スターターバンドルは25~99 Robuxを目安にします。高額商品を1つ売るより、少額を使うプレイヤーを多く獲得する方が効果的です。移動のような基本機能を決して制限してはいけません(Robloxの収益化責任者とスタジオ責任者、RDC 2025)。後から課金要素を追加すると、Pay to Winと受け取られます。
  6. リスクのある変更はすべて設定の背後からリリースし、データで判断します。 プレイヤーが機能に出会う時点のプレイヤースナップショットから実験値を読み取り、まず最小検出可能効果を確認します。切断率などのガードレールは、わずかな改善より優先します(Creator Docs、experiments;Robloxの実験チームとスタジオ、RDC 2025)。
  7. 発見されるかどうかはクリックに左右されます。 QPTRに代わり、プレイスルー率と初回プレイ時の離脱率が重視されます。ランキングが学習するのはオーガニックなHomeトラフィックのみです。サムネイルには実際のゲームを表示する必要があります(Robloxのディスカバリー責任者、RDC 2026およびRFY Q&A;スタジオ、RDC 2025)。
  8. リワード動画の報酬は固定の開発者プロダクトです。 ユーザーが自発的に開始し、報酬を明示します。Robuxを報酬にせず、ランダム要素も設けず、進行の条件にもしてはいけません(Creator Docs)。広告が課金ユーザーの支出を奪わないよう、すでに販売を終了した課金アイテムを報酬にします(RDC 2025)。

まず確認すること

  • 公開済みかどうか:分析、設定、広告、商品検索には公開済みの環境が必要です。 未公開の場合は、合成レシートを使ってテストし、Studio の動作を記録してください。
  • 商品インベントリ:名前、種類(通貨、バンドル、パス、サブスクリプション)、各商品で付与されるもの、ID の有無。ID を作成できるのはオーナーのみです。Creator Hub (gui-paths.md) を使用してください。
  • データレイヤー:使用するプロフィールストアと、scenario-roblox-data Receipts 用の getProfile および isPresent 関数。
  • 対象ユーザー層:年齢層、有料ランダムアイテムに関する制限がある地域、モバイルユーザーの割合、DAU(DAU が約 1,000 未満の実験では、有意な結果が得られないことがよくあります)。
  • 広告:オーナーが年齢確認済みの 13 歳以上で、2FA を有効にし、ゲームを公開していること。そうでなければ、リワード動画は利用できません。
  • 回答がない場合のデフォルト:カタログモジュールは 1 つ、Purchases を通じて BindReceiptHandler を使用、価格は PriceText を使用、通貨パックとスターターバンドルを用意、有料ランダムアイテムはなし、初日からテレメトリーとライブ設定を有効化。

手順

完全なコードとテスト結果は procedures.md にあります。サーバーモジュール (Catalog、Purchases、Entitlements、Telemetry)は、データレイヤーの Receipts の隣にある ServerScriptService.MonKit に配置します。共有モジュール(Odds、PriceText、LiveConfig、ShopRank)は ReplicatedStorage.MonKit に配置します。ステータス:未公開のプレースで、Studio 0.743 のライブテスト 16 件中 16 件に合格(2026-10-19)。Lune のスイートテスト 61 件も合格し、Studio でも変更なしで合格します。公開済みのゲームが必要で、以下は未実施です:実際の RankProductsAsync によるランキング(未公開では HTTP 400 となり、カタログの順序を維持)と、自分の商品での no-description。

  1. 監査。 目標:すべての購入経路、価格のリテラル、クライアント側の分析または設定の呼び出しを検出します。方法:オフライン(Lune)で rbx_monetization.audit_place(place) を実行し、その後、編集モードで rbx_monetization.run を通じて MonAudit.run(game) を実行します。GATE:エラーがゼロで、実際の集計値がオフラインの集計値と一致すること。
  2. カタログ。 目標:商品、パス、サブスクリプションを1つのサーバーテーブルにまとめ、付与内容はデータとして定義し、価格は含めません。方法:Catalog.new(def)、catalog:validate() を実行します。公開済みのテストサーバーで、catalog:verify(fetch, game.CreatorId) を実行します。GATE:duplicate-id、bad-grant、unknown-id、foreign-id の検出がないこと。パス ID の誤りはエラーではありません。実環境では、パス ID 1 が別のクリエイターのパスに解決されました。
  3. レシート。 目標:各 PurchaseId に対して付与が厳密に1回だけ行われること。方法:scenario-roblox-data の Receipts.new{getProfile, isPresent, handlers = catalog:handlers()} を使い、その後 Purchases.new{receipts, catalog, telemetry} を作成して purchases:bind(MarketplaceService) を実行します。合成レシートテーブルでテストし、実際の購入プロンプトは使用しないでください。GATE:重複購入でも付与は1回だけで、プレイヤーが不在の場合と保存に失敗した場合は NotProcessedYet を返し、再試行時に1回だけ付与されること。
  4. 特典。 目標:パス、サブスクリプション、Plus をサーバー側で確認する特典として扱います。方法:Entitlements.new{passes, subscriptions, owns, subStatus, onChanged} を作成し、ent:connect(MarketplaceService, Players) を実行します。Entitlements.giveTool は Backpack と StarterGear に書き込みます。GATE:チェックでエラーが発生しても購入済み状態が維持されること。ツールがリスポーン後も残ること。クライアントでは perk_ 属性を使って「Owned」と表示されること。
  5. 価格。 目標:表示するすべての価格がプレイヤーの価格であること。方法:ショップを開くときに LocalScript で PriceText.fetch と PriceText.view を使います。GATE:price-literal の検出がないこと。価格が読み込まれるまでは行に「...」と表示され、購入できない状態が維持されること。
  6. 有料ランダムアイテム。 目標:確率を開示し、制限対象のプレイヤー向けの代替手段を用意すること。方法:サーバーの抽選とクライアントパネルの両方で、1つの Odds.fromWeights モジュールを読み込みます。免責事項を添えて、「Details」ボタンの背後に Odds.display を表示します。制限対象のプレイヤーには Odds.directPrice を提示するか、オファーを表示しません。GATE:表示される確率の合計が100%であるか、免責事項が表示されること。制限対象のプレイヤーが購入プロンプトに進めないこと。
  7. リワード動画。 目標:固定の商品を報酬として提供することを明示した、任意の広告を用意します。方法:メニューを開くときにクライアントで GetAdAvailabilityNowAsync を実行します。サーバーでは pcall 内で CreateAdRewardFromDevProductId を実行し、その後 ShowRewardedVideoAdAsync を実行します。報酬はチャネル AdReward のレシートとして届きます。GATE:広告が利用できない場合は広告行を非表示にすること。報酬の付与にレシート経路を使うこと。
  8. 分析。 目標:不正利用者や制限の影響を受けない、オンボーディング、ショップファネル、ゲーム内経済のイベントを記録します。方法:サーバーのみで Telemetry を使用します。クライアントはステップ番号を送信し、サーバーは前に進むステップのみ受け入れます。ゲーム内経済イベントは保存後に記録します。GATE:無効なステップを破棄して件数を記録すること。イベント名、通貨、フィールドが制限テーブルの範囲内であること。
  9. ライブ設定と実験。 目標:リリースなしで値を変更できるようにします。方法:UpdateAvailable と Refresh を使って LiveConfig.new{defaults} を作成し、cfg_ プレイヤー属性と cfgReady マーカーにミラーリングします。実験キーには forPlayer を使います。GATE:ConfigService が失敗した場合はデフォルト値が適用されること(実環境では、未公開の状態で約30秒後に失敗します)。クライアントは cfgReady の後にのみ値を読み取ること。
  10. ストア用アート。 目標:サイズのルールに適合し、実際のゲームを見せるサムネイル、アイコン、アイテムアイコンを用意します。方法:ステージング環境のプレイテスト画面をキャプチャし、thumb_from_capture を実行してから Scenario のアートを作成します(Handoffs を参照)。check_art(path, kind) を実行します。GATE:check_art のエラーがゼロであること。コンタクトシートをレビューすること。オーナーがアップロードすること。
  11. ローンチとライブ運用。 目標:各段階の判断に使う指標を定めた計画を作成します。方法:各テストで rbx_monetization.mde(enrolled, baseline) を実行します。ロールアウトは10%、50%、100%の順に行います。ベースラインを取るため、広告キャンペーンはターゲティングなしで1~2週間実施します。GATE:各実験に主指標、ガードレール、想定効果より小さいMDE、停止日が設定されていること。ローンチチェックリストとコンテンツの進行計画:launch-liveops.md。

数値

値対象出典
25~99 Robuxスターターバンドルの価格RDC 2025
100 個の PurchaseIdプロフィールに保持される購入レシートログscenario-roblox-data default [added]
30 日間で 60,000 件の取引価格最適化の適格条件。98/2 の配分で約 3 週間分ドキュメント
最初のゼロ以外の数字の下 4 桁注意書きを添えた確率の丸めドキュメント
1 分あたり 120 + 20 x CCUサーバーあたりの分析リクエスト数ドキュメント
3 フィールド、10 通貨、20 種類、100 SKU「その他」にまとめられる前の分析のカーディナリティドキュメント
10 ファネル、100 ステップ、100 イベント名体験ごとの分析ドキュメント
14~60 日、最大 2 バリアント実験期間と群ドキュメント
プレイ時間 -10%、ARPU または課金者転換率 -20%早期の悪影響による停止。最初の 24 時間、登録者 10,000 人以上ドキュメント
約 1,000 DAUこれを下回ると、有用な MDE の達成が困難ドキュメント
10%、50%、100%リスクの高い機能のロールアウト段階RDC 2025 studios
1 日の収益の最大 4%広告への再投資。30 日間の ROAS で評価RDC 2026
1920x1080、16:9、3 MB 未満サムネイル。下部の帯はプレイヤー数で隠れるドキュメント
512x512、150x150 でも判読可能体験アイコンドキュメント
最大 512x512、円形にトリミングパスと製品のアイコンドキュメント
アクティブな消費者 1 人あたり 1 日 5 RobuxCreator Rewards。その日の最初の 3 ゲームで、10 分以上ドキュメント

品質ゲート

測定可能な項目:

  • 監査:オフラインとライブの両方でエラーがゼロであること。警告は修正するか、理由を明示します。
  • テストスイート:catalog、receipts、entitlements、pricetext、odds、telemetry、liveconfig、monaudit が Lune で合格し、変更せずに同じ件数で Studio でも合格すること。
  • プレイテスト中の購入レシート:重複した PurchaseId による付与は 1 回のみであること。保存に失敗した場合は NotProcessedYet を返し、再試行で 1 回付与されること。
  • コンソール:サーバー分析の行に「AnalyticsService: event fired.」と表示されること。「can only be executed on the game server」という行がないこと。
  • テレメトリートレース:ファネルのステップが順方向にのみ進むこと。経済イベントは、付与の保存後にのみ発生すること。

視覚的な項目:

  • 価格、確率パネル、制限付きビューが表示されたショップのクライアントキャプチャを、rbx_review.image_checks で確認します。
  • ストア用アートを 1,600 px 以下のコンタクトシートで開き、内容を確認します。

完了とする前に、critique.md を使って結果を評価します。

よくある間違い

間違い症状修正
付与してから保存し、その後に PurchaseGranted を返すクラッシュ後に支払い済みなのに何も付与されていない先に保存し、LastSavedData の場合にのみ付与する
PromptProductPurchaseFinished で付与する発火したリモート経由でアイテムが無料になるレシートハンドラー内でのみ付与する
pcall(handler) の成功を付与とみなすハンドラーが nil を返したのに付与される保存後にのみ true を返す。nil は付与済みではない
2 つのスクリプトで ProcessReceipt を設定するある商品が一度も付与されないサーバーごとに Purchases:bind を 1 つだけ使う
UI コードに価格を直接入力するPlus と地域別の価格が誤り、最適化も妨げられるGetProductInfoAsync から取得した PriceText を使う
オッズを 2 つのテーブルに分ける公開されたオッズと抽選結果が異なる両方で 1 つのオッズモジュールを使う
クライアントから有料の卵購入を促す制限対象のプレイヤーも購入できてしまうポリシーチェック後にサーバーから購入を促す
クライアントで Analytics や ConfigService を使う何も起きず、「ゲームサーバーでのみ利用可能」と表示されるサーバーから呼び出し、クライアントでは属性を読み取る
クライアント送信のファネルステップを信頼する不正利用者によってファネルが水増しされるサーバーで検証し、前進方向のみ許可する
全員を対象に参加時点で実験を読み取る実験を目にしないプレイヤーによって登録率が薄まる機能が表示される場所で forPlayer を使う
早期の確認結果をもとにテストを停止する維持できない勝者を選んでしまうMDE に基づいて期間を固定する
サムネイルの文字やプレゼント企画の主張動画が却下されるか、発見性が低下する実際のゲームプレイと簡潔なタイトルを使う

引き継ぎ

  • scenario-roblox-data との間では、商品 ID と付与数を渡し、永続化(PurchaseIds ログ、LastSavedData 確認)を担う Receipts ハンドラーテーブルを受け取ります。このスキルはレシートの契約とカタログを担当します。
  • scenario-roblox-networking からは、purchase-signal の調査結果と、ショップステップおよび卵のリクエスト用に検証されたリモートを受け取ります。
  • scenario-roblox-ui には、価格とオッズのテキスト、perk_ および cfg_ 属性、「Details」パネルの内容を渡します。レイアウトとスケーリングは UI 側で担当します。
  • scenario-roblox-performance と scenario-roblox-tooling には、テレメトリーの送信頻度と、オフライン監査およびテストスイート用の CI を渡します。
  • シナリオのアート:サムネイルはステージング済みのゲームプレイ映像から作成し、scenario-formats で 16:9、1920x1080 に再構成するか、scenario-image で編集します。エクスペリエンスアイコン(512x512 の正方形)とパスまたは商品アイコン(透明な PNG、被写体を円の内側に配置)は scenario-game-assets から取得し、scenario-quality-gate で評価します。ファイルをプロジェクトに配置して check_art を実行し、アップロードはオーナーだけが行います。すべてのアートで、テキスト、価格、「無料」という主張は避けてください。モデレーションはアップロードすべてに適用されます。

Roblox の最新メモ

  • Enum.ReceiptDecision と省略可能なフィルターを使う BindReceiptHandler が現在のレシート API です。ProcessReceipt も引き続き動作します。
  • ゲーム間の製品とパスの販売は 2026-05-30 に終了しました。Robux の送金には独自のレシート タイプを使用します。
  • 新規加入者向けに Premium が Roblox Plus に置き換わりました:HasRobloxSubscription、 PromptRobloxSubscriptionPurchase。
  • 2025-07-24 に、エンゲージメントベースの支払いが Creator Rewards に置き換わりました。
  • Yield を伴う呼び出しには Async が付いています:GetProductInfoAsync、UserOwnsGamePassAsync。Enum.InfoType.GamePass を使用してください。価格最適化のページにある GamePasses は存在しません。
  • プレイスルー率と初回プレイ時の離脱率が QPTR に置き換わりました。サムネイルのページには、引き続き「qualified play through rate」と記載されています。
  • Open Cloud には Configs、Experimentation、Analytics Query、Ads の各 API があり、すべてオーナー発行のキーを使用します。
  • パスの無料トライアルは RDC 2026 で 2026 年 10 月開始と発表されましたが、まだドキュメントには記載されていません: 使用する前に確認してください。

参考資料

  • references/expert-notes.md:タイムスタンプと最新の調査結果を含む、ソース別の原則。
  • references/procedures.md:各テストと最新の結果を含む、ステージ P1 から P11 までの全コード。
  • references/critique.md:各項目の測定方法を含む、ブロッキング項目と品質の評価基準。
  • references/launch-liveops.md:アイテムのメタデータ、報酬付き動画の適格性、ショップの順序、コンテンツのペース配分とパワーインフレ、有料アイテムの取引。
  • references/gui-paths.md:エージェントが操作できない項目の Creator Hub と Studio の手順、および Open Cloud のルート。
  • references/sources.md:認証情報とタイムスタンプを含む、すべてのドキュメントと動画。
  • scripts/rbx_monetization.py:監査、キットローダー、Studio プローブ、アートチェック、サムネイルの切り抜き、MDE。
  • scripts/agentkit/monetization/:Catalog、Purchases、 Entitlements、PriceText、ShopRank、Odds、Telemetry、LiveConfig、MonAudit、 lune_mon_audit.luau。

コメント