Roblox Studioでゲーム公開する方法と設定

この記事では、初回公開の手順だけでなく、Creator Hubでのサムネイル、説明文、分析、収益化、コラボ権限の整え方までをまとめて追えます。
未成年の制作者や保護者が押さえたい安全設定、公開できることとDevExで換金できることは別だという整理まで含めて、公開前に迷いやすいポイントをひとつずつほどいていきます。

Robloxゲーム公開の全体像

Roblox Studioでの公開は、Studioで作品データをサーバーへ保存する段階と、公開ページとして見せ方や公開範囲を整える段階に分かれます。
ここを分けて考えると、「Publishしたのに誰も入れない」「説明文やサムネイルはどこで直すのか」といった初学者の混乱がほどけます。
初回のPublish直後に外部から見えない状態だったときは、まず事故が起きないことに安心でき、そのあとPermissionsを切り替えた瞬間に友人が参加できたので、この二段階構造を体感として理解できました。

Studio側の流れ

最初に押さえたいのは、Studioで行うのは「公開ページを完成させること」ではなく、「ExperienceまたはPlaceとして保存先に反映すること」だという点です。
画面操作としてはHomeタブから公開系の操作に進み、Publish to Robloxを選びます。
環境やUIの見え方によってはPublish asに近い意味で、既存の公開先へ保存し直す流れとして認識しておくと迷いません。
スクリーンショットを入れるなら、この段階ではHomeタブ上の公開ボタン付近と、公開ダイアログの全体画面を載せると読者が追いやすくなります。

最初に押さえたいのは、Studioで行うのは「公開ページを完成させること」ではなく、「ExperienceまたはPlaceとして保存先に反映すること」だという点です。
Studio の UI はバージョンやローカライズによって表示が変わるため、公開操作は上部ツールバーや File メニューのいずれかから行う場合があります。
一般的には「Publish to Roblox」を選び、保存先（新規 Experience または既存 Experience 内の Place）を指定して保存します。
操作の詳細や最新の表記は公式ドキュメントを参照してください: https://create.roblox.com/docs/publishing/publish-to-roblox （スクリーンショットを入れる場合は、キャプションで使用中の Studio バージョンや、ツールバー表示か File メニュー表示かを明記すると、UI差異による混乱を減らせます。
）

公開前の準備

公開前に詰め込むべきことは多く見えますが、実際は「アカウントと制作環境を整える」「PCでテストする」「公開ページの見た目は仮で進める」の3本に分けると迷いません。
制作と公開で必要になるサムネイルやアイコンのサイズはコミュニティで 512×512（アイコン）や 1920×1080（スクリーンショット）がよく使われますが、公式の最新仕様や上限は Creator Hub のヘルプで必ず確認してください: https://create.roblox.com/docs/creator-hub。
Roblox Studioでの制作はPC前提で考えたほうが安定し、公開前は見た目よりもプレイできる状態を固めるほうが手戻りを減らせます。

Robloxアカウント作成とログイン（メール/2段階認証の推奨）

出発点になるのはRobloxアカウントです。
ゲームを作るだけでなく、Roblox Studioで保存したり、Publish to RobloxでExperienceとして反映したり、Creator Hubで説明文やサムネイルを整えたりする流れまで、すべて同じアカウントを軸に進みます。
メール登録を済ませておくと、ログインまわりのトラブル時に復旧しやすくなりますし、2段階認証も有効にしておくと制作アカウントの保全に直結します。

制作を始めた直後は、まずスマホだけで何とか進めたくなりますが、実務ではここで詰まりやすいです。
スマホではRoblox Playerで遊ぶことはできても、Roblox Studio自体は使えません。
実際にスマホ中心で進めようとしたときは、編集、保存、動作確認の流れが分断されてしまい、PCへ切り替えた途端にビルドとテストの往復が安定しました。
テンプレートを開いて修正し、その場でPlayやPlay Hereを回せるのはPC環境ならではの強みです。

公開前のテストも、この段階から始めておくべき作業です。
Studio内ではPlayやPlay Hereを使って、スポーン位置、移動、UI、当たり判定、リスポーンの流れを確認します。
さらに、使っていないモデル、画像、サウンド、古いスクリプトが残っていれば、この時点で整理しておくと公開後の管理が軽くなります。
制作途中の試行錯誤で不要なアセットは増えやすく、放置すると後から「どれが本番用かわからない」状態になりやすいからです。

対応OSメモ

Roblox StudioはWindowsとmacOSで使えるPC向けの制作ツールです。
スマホではStudioを動かせないため、制作と公開準備を完結させる前提はPCになります。
遊ぶ側のRoblox PlayerもPCとモバイルで触れられますが、制作環境として見たときはWindowsかmacOSのどちらかを基準にしたほうが流れが止まりません。

OSまわりでの注意点として、Roblox Playerは2025年1月15日にWindows 7、Windows 8、Windows 8.1のサポートが終了しています。
公開前に古いWindows機で確認するとプレイヤー側の前提とずれてしまうため、現行のWindowsまたはmacOSで動作を確認するほうが実態に沿います。
StudioもPC専用なので、制作機は最初からその条件に合わせておくと混乱を防げます。

テスト方法も、ローカル確認だけで終えないほうが精度が上がります。
Play Hereでは問題なく見えていたのに、Private公開してオンライン接続した瞬間にデータ保存の挙動が違って見えたことがあります。
ローカル再生では拾えない保存タイミングや接続まわりの確認があり、公開前はStudio内テストとPrivate状態での実機接続を分けて考えると、詰めの甘さが減ります。

公開前に見ておく項目は、次のように整理できます。

• 端末ごとに基本操作が破綻していないか確認してください。
• Spawn位置が意図した場所になっているか確認してください。
• リスポーン後に進行不能にならないか確認してください。
• データ保存が想定通りに動くか確認してください。
• 外部APIやデータストアまわりの使用箇所を把握できているか確認してください。
• コンテンツ内容が不適切な表現を含んでいないか確認してください。
• プレイヤー名、画像、テキスト内に個人情報の露出がないか

ゲーム名や説明文、サムネイルは公開後も更新できるため、まずは仮でOK

公開前に悩みすぎなくていいのが、ゲーム名、説明文、サムネイルまわりです。
初回のPublish to Robloxでは名前と説明を入れて保存し、その後にCreator Hub側で説明文やサムネイル、各種ページ情報を調整していく流れになります。
つまり、最初から宣伝素材を完璧に仕上げなくても、遊べる状態を先に固めておけば公開作業自体は進められます。

この考え方を持っておくと、準備の優先順位がぶれません。
最初の1本では、タイトル案に時間を使うよりも、スポーン直後に落ちないこと、UIが押せること、セーブが壊れないことのほうが先です。
サムネイル素材は後から差し替えられますし、説明文も公開後に調整できます。
見た目の完成度は運用しながら育てられますが、最初のプレイ体験が壊れていると離脱はその場で起きます。

Roblox Studioでゲームを公開する手順

Roblox Studioでの公開作業は、まずStudioからサーバー側に体験を保存し、そのあとで公開範囲やページ情報を整える流れで考えると迷いません。
ここで押さえたいのは、Publish to Robloxで保存した時点では本公開が完了したわけではないことと、更新時には公開先のExperienceを意識して操作することです。

新規体験をPublishする

新しく作ったゲームを初めて公開するときは、'Publish to Roblox'（Studio の File メニューや上部ツールバーに配置される場合があります）を選んでください。
公式の公開手順は公式ドキュメントにも詳しく記載されています: https://create.roblox.com/docs/publishing/publish-to-roblox （図: 'Home'タブと 'Publish to Roblox' の位置を示すスクリーンショット）

クリックすると公開用のダイアログが開くので、Experience名と説明を入力して保存します。
ここでは名前を完璧に作り込むより、あとで見返して区別できる内容にしておくほうが進行が止まりません。
説明文もこの段階では仮で構いませんが、空欄のままにせず、どんなゲームなのかが自分でわかる一文を入れておくと、Creator Hub側で後から整えるときに修正しやすくなります。
入力欄の見た目や配置も人によって迷いやすいので、ダイアログ内の名前欄と説明欄が見える画面もあると理解が一気に進みます。
（図: Publish ダイアログの Name/Description 入力欄の例）

このとき意識したいのが、保存と一般公開は別工程だという点です。
初回の保存時点では非公開のまま進む前提で考えると安全です。
公開直後に検索からすぐ見つかる状態を期待しないほうがよく、まずは保存してオンライン上の体験として持ち上げ、その後でGame SettingsのPermissionsや体験ページの整備に進む、という順番で捉えると作業が整理できます。
Publish to Robloxを押した瞬間に全員へ見えるわけではないので、ここでは「サーバーに置く」工程だと考えるとつまずきません。

公開先の指定が入る画面では、どのExperienceとして保存するのかを意識します。
初回は新しいExperienceを作る流れになりますが、名称だけで決め打ちすると、似た名前の体験を複数持つようになったときに後で混乱します。
最初の1本は特に、テスト用と本番候補が増えて一覧が見づらくなりがちです。
名前、説明、公開先の3点をセットで確認してから保存すると、別の場所に誤って置いてしまう事故を避けられます。

既存体験にPublish asで更新する

すでに公開先のExperienceがある場合は、Homeから更新先を選んで上書きする流れになります。
画面上ではPublish asという案内で説明されることがありますが、実務では「既存のExperienceへ更新を反映する操作」と捉えておくと理解しやすくなります。
新規作成ではなく、既存の公開先を選んで保存することで、今ある体験に対して最新版の内容を載せるイメージです。

この操作で大事なのは、新しい体験を増やすのではなく、同じ公開先に更新することです。
たとえばバグ修正やマップ調整をしたときに新規公開を繰り返すと、体験ページが分散し、どれが本番かわからなくなります。
既存のExperienceを選んで更新すれば、同じ体験の中身だけを差し替える形になるので、運用が安定します。

実際に運用していると、この上書き更新の安心感は大きいです。
Publish asで同じリンクを保ったまま内容だけを更新できる形にしておくと、プレイヤーのブックマークが切れません。
せっかく遊びに来てくれた人が、更新のたびに別ページへ飛ばされる状態は避けたいので、既存のExperienceへ反映する運用は早い段階で身につけておく価値があります。

更新作業でも、保存しただけでは公開範囲やページ表示が整ったことにはなりません。
とくに公開後の修正版は、制作者側では直したつもりでも、プレイヤー視点では説明文やサムネイルが古いまま残っていることがあります。
Studio内の更新と、Creator Hub側のページ整備は別の仕事として切り分けておくと、見落としが減ります。

ExperienceとPlaceの考え方

公開作業で初心者が引っかかりやすいのが、ExperienceとPlaceを同じものだと思ってしまう点です。
Experienceは大きな入れ物で、その中に1つ以上のPlaceが入ります。
ロビー、本編マップ、別ステージといった複数の場所を持つゲームでも、ひとつのExperienceとしてまとめて運用できます。

感覚としては、体験ページ全体がExperience、その中で実際に入る個々の場所がPlaceです。
最初の1本ではスタート地点になるPlaceがひとつだけということも多いですが、後からロビーや別ワールドを足したくなったときに、この構造を知っていると設計が崩れません。
公開先を選ぶときに見ている単位はExperienceであり、内部には複数のPlaceがぶら下がる、と整理すると理解しやすくなります。
（図: Explorer 上における 'Experience' と 'Place' の構造図の例）

図にすると、次のようなイメージです。

この考え方を知っておくと、新規公開と更新公開の違いも整理しやすくなります。
新規公開では新しいExperienceを作るイメージになり、既存への更新では、そのExperienceの中の内容を育てていく感覚になります。
公開先の選択で迷ったときは、「今増やしたいのは新しい体験そのものか、それとも同じ体験の最新版か」を基準にすると判断しやすくなります。

公開直後の作業としては、Experienceを保存したあとにPermissionsの設定とページ整備が続きます。
ここを飛ばすと、体験自体は存在しているのに遊べる人が限られたままだったり、ページ情報が未整理のままだったりします。
Studioでの公開はスタート地点で、その後に体験ページを整えて初めてプレイヤーが迷わず入れる状態になります。

公開範囲の設定方法

公開範囲はStudioのHomeからGame Settingsを開き、Permissionsで切り替えます。
ここで選ぶPrivateFriendsPublicは、参加できる相手だけでなく、確認したい内容や未完成の状態をどこまで見せるかまで変わる設定です。
最初の1本では、公開したらすぐPublicにするのではなく、まずPrivateかFriendsで挙動を整え、体験ページの見せ方まで仕上がってから一般公開へ進める流れが失敗を減らします。

3つの違いを先に並べると、判断がぶれません。

Privateで内々に検証する

Privateは、まずオンラインで壊れていないかを確かめるための設定です。
ローカルでは動いて見えても、実際に公開先へ出すとリスポーン、データ保存、スポーン位置、GUIの初期表示といった部分でズレが出ることがあります。
開発の初期段階では、このズレを外に見せずに潰せるのがPrivateの価値です。

とくに最初の公開直後は、見た目よりも「サーバー上で意図通りに動くか」を優先したほうが運用が安定します。
建築やスクリプトの完成度に目が向きがちですが、プレイヤー体験として致命傷になりやすいのは、入った瞬間に復帰できない、UIが表示されない、ラウンドが始まらないといった基本挙動です。
Privateなら、こうした不具合を自分の手元で確認しながら修正できます。

実務では、最初にPrivateへ置いてオンライン挙動を1周確認してから次へ進めると、後のテスト募集が整います。
まだ説明文やサムネイルが仮の状態でも問題になりにくく、触ってほしい部分を絞ったまま検証できるからです。
公開範囲の設定は単なる入場制限ではなく、開発の段階を切り分けるためのスイッチだと捉えると迷いません。

Friendsで初期フィードバックを得る

Friendsは、制作者だけでは見落とす違和感を拾う段階に向いています。
Privateで基本動作を確認したあと、フレンドだけが入れる状態にすると、見知らぬ不特定多数に見せる前に、反応や戸惑いを集められます。
難易度、導線、チュートリアル不足、説明不足のように、作った本人ほど気づきにくい要素はこの段階で見えやすくなります。

実際にFriends限定でテスターを募ったとき、制作者側では再現できていなかったリスポーン不具合に早い段階で気づけたことがあります。
通常プレイでは問題なく見えていたのに、複数人が連続で倒された場面で一部のプレイヤーだけ復帰地点がおかしくなり、プレイテンポが崩れていました。
こういう不具合は、身内テストだからこそ遠慮なく報告してもらえます。

Friendsの価値は、単に人数を増やすことではありません。
自分の操作パターンとは違う遊び方が入ることで、導線の穴や想定外の進行順が見えてきます。
2025年1月13日にはフレンド上限が1000まで拡大され、以前よりFriendsテストの母数を確保しやすくなりました。
小規模な身内確認から、もう少し幅のある初期フィードバックまで取りやすくなったぶん、PrivateとPublicの間に置く段階としての意味が増しています。

Publicで一般公開する

Publicは、一般プレイヤーが参加できる本公開の状態です。
ここまで来ると、ゲーム内容だけでなく、体験ページの見え方もプレイ継続に直結します。
未完成の説明文、伝わらないサムネイル、入口で何をするゲームかわからない導線のまま公開すると、遊ぶ前に離脱されることが増えます。

公開直前にサムネイル、説明、最初の導線をまとめて整えるだけで、初日の定着率は目に見えて変わります。
実際にも、Publicへ切り替える前にページ画像と説明文を見直し、ゲーム開始直後の案内を短く整理したところ、入ってすぐ抜けるプレイヤーが減りました。
内容そのものを大改修したわけではなく、何を楽しむゲームかが入口で伝わる状態にしたことが効きました。

Publicへ切り替える前提条件にも目を向けたいところです。
一般公開には追加要件が設定されることがあり、執筆時点でもアカウント条件や公開時に入力すべき項目が関わります。
ここは通常の保存操作とは別物で、既存の公開フローを終えただけでは足りません。
Publicは最終スイッチではありますが、ページ整備と要件充足が揃って初めて意味を持つ設定です。

また、Publicは未完成のものを広く見せる場ではなく、集客と運用を始める段階です。
Privateで壊れていないことを確認し、Friendsで初期反応を受け取り、見せ方まで整えたうえで開くと、公開初日から体験の印象を崩しにくくなります。
Permissionsの3択は単純に見えて、開発の順番そのものを整える役割を持っています。

公開後にやるべき設定

公開はスタート地点であって、運用の本番はその直後から始まります。
Roblox StudioでPublish to Robloxまで終えても、実際にプレイヤーが目にするのはCreator Hub側で整えた体験ページであり、流入、第一印象、継続率、共同運用のしやすさまでここで差がつきます。
作って終わりではなく、公開ページを育て、数値を見て、更新のたびに改善していく流れまで含めて1本の公開作業です。

Creator Hubでの作業場所を案内（Experienceページ）

公開後に触る中心はCreator HubのExperienceページです（管理やヘルプの公式情報: https://create.roblox.com/docs/creator-hub）。
ここでサムネイル、説明文、コラボレーター、分析、収益化項目などを整えます。

まず手を入れたいのは、サムネイル、アイコン、動画です。
アイコンは一覧や検索結果で最初に見られる顔になり、サムネイルは詳細ページで期待値を決めます。
画像サイズは実務上、アイコンを 512 × 512、スクリーンショットを 1920 × 1080 前提で作っておくと崩れにくく、縮小表示でも主題が残ります。
アイコンに細い文字を詰め込みすぎると小さい表示で潰れやすいので、タイトルを読ませるより、色、シルエット、主役オブジェクトの3点で印象を作るほうが結果につながります。

サムネイルは1枚で決め打ちにせず、複数パターンを試す発想が効きます。
バトル中心の体験なら戦闘中の1枚、育成中心なら報酬や成長が伝わる1枚というように、何が魅力かで切り口を変えると反応が変わります。
実際にサムネイルを差し替えた週にページCTRが上がり、初回起動数が増えたことがありました。
ゲーム本編を触らずに入口だけを変えても数字が動くので、公開ページの素材は飾りではなく集客導線そのものです。

説明文やページ情報の整備も同じくらい効きます。
説明文では、何をするゲームか、最初に何を楽しめるか、誰に向いているかを短く伝えると、入場前の離脱を減らせます。
あわせてジャンルや年齢ガイドライン関連の項目、ゲームページ上の各種情報も整えておくと、体験の位置づけが伝わりやすくなります。
ここを空欄や仮文のままにすると、内容以前に未整備な印象を与えやすく、せっかくの流入が無駄になりがちです。

共同制作をしているなら、Collaboratorsも公開後の早い段階で整えておきたい項目です。
アーティスト、スクリプター、テスター、収益管理担当が同じ体験に関わる場合、権限をまとめて管理できる状態にしておくと運用事故が減ります。
EditPlaytestMonetizationのような役割単位で分けておくと、編集してよい人、テスト参加だけに留める人、収益設定まで触れる人を切り分けられます。
人数が増えるほど口頭共有だけでは破綻しやすく、誰がどこまで触れるのかが曖昧なまま進めると、更新作業や設定変更で食い違いが出やすくなります。

公開後は数字を見る場所もCreator Hubに移ります。
Creator Analyticsでは、どれだけ新規プレイヤーを獲得できているか、どのくらい滞在しているか、収益がどう動いているかを追えます。
更新を出したら、その前後で獲得、滞在、収益のどこが動いたかを見る癖をつけると、感覚ではなく実績で改善点を拾えます。
サムネイル変更で入口が伸びたのか、チュートリアル改修で滞在が伸びたのか、課金導線の調整で収益が変わったのかは、更新単位で見比べると因果がつかみやすくなります。

ソーシャル要素の見直しも見落とせません。
ゲームページ上のソーシャルリンク、プレイヤーからの通報導線、プレイヤー向けコミュニケーションの方針が噛み合っていないと、公開後の印象が荒れやすくなります。
体験内チャットにはフィルタが入りますが、それだけで運営姿勢までは伝わりません。
説明文やページ内の文言で、どういう遊び方を歓迎するか、迷惑行為や不適切なコミュニケーションをどう扱うかが読み取れる状態にしておくと、初期コミュニティの空気が整いやすくなります。
あわせてReport Abuseへたどれる導線が機能している前提で、問題が起きたときにプレイヤーが行き場を失わないページにしておくことが、公開後運用では効いてきます。

素材づくりには思った以上に時間がかかります。
アイコン1枚、スクリーンショット数枚、短い動画まで揃えると、それだけでまとまった作業量になります。
だからこそ、公開後にまとめて慌てて作るより、体験の魅力を言語化しながらページ素材を揃え、更新のたびに差し替えていく運用のほうが現実的です。
公開ページを触る時間は開発外の雑務ではなく、プレイヤーに見つけてもらうための制作時間として扱ったほうが、結果に結びつきます。

（図: Creator Hub の Experience 概要／サムネイル設定画面／Collaborators 権限画面／Analytics ダッシュボードの例）

収益化を始める前に知っておきたいこと

公開した体験に課金導線を載せるときは、何を1回だけ売るのか、何を繰り返し買ってもらうのかを最初に切り分けると設計が安定します。
あわせて、価格は一度決めて終わりではなく、地域差や自動最適化の考え方を踏まえて調整していく前提で見ると、数字の伸び方を理解しやすくなります。
なお、DevExは収益化機能そのものではなく、条件を満たしたEarned Robuxを換金する制度なので、ゲームを公開できるか、ゲーム内で販売できるかとは別の話です。

Game PassとDeveloper Productsの使い分け

Game Passは恒久特典向け、Developer Productsは繰り返し購入向けという整理で始めると迷いません。
たとえば、限定エリアの解放、恒久的な所持枠追加、常時有効な能力アップはGame Passに向いています。
一方で、ゲーム内通貨、復活、一定時間だけのブースト、消耗品はDeveloper Productsに置くと、遊びの流れと販売の形が一致します。

初心者の最初の設計としては、Game Passを1つか2つ、Developer Productsを低価格帯で少数置く形が収まりやすいです。
恒久特典だけで固めると最初の一度しか売れず、逆に繰り返し購入だけだと押し売り感が出ます。
序盤から終盤まで触れる効果をGame Passに、プレイ中の気持ちが高まった瞬間に買うものをDeveloper Productsに置くと、プレイヤー側も納得しやすくなります。

実務では、最初から高額商品を作り込むより、低価格のDeveloper Productで需要を探ったほうが読みやすい場面が多いです。
実際、通貨補充の小さな商品を先に置いて反応を見たところ、購入率が動く価格帯と、買われるタイミングが見えました。
その後、内容量と価格のつり合いを少しずつ調整しただけで、売れない商品を抱え込まずに済みました。
最初の収益化は、完璧な商品を当てる作業というより、どの場面で何に価値を感じてもらえるかを探る作業です。

販売設定そのものはCreator Hub側で行いますが、設定しただけでは売れません。
購入UIがどこで出るか、プレイヤーが欲しくなる瞬間に出ているかが結果を分けます。
敗北直後に復活商品を出すのか、ショップ画面でまとめて見せるのか、報酬受け取り前にブーストを提案するのかで、同じ商品でも反応は変わります。
公開前のテスト段階ではPrivateやFriendsで、購入導線の見え方まで確認しておくと、公開後に「商品はあるのに誰も気づかない」という失敗を減らせます。

未成年プレイヤーを強く意識することも欠かせません。
連打で意図せず買ってしまう位置にボタンを置く、敗北を過度に不快にして購入を迫る、何が手に入るか曖昧なまま決済を促す、といった作りは避けるべきです。
何を買うのか、買うと何が起きるのかが一目でわかるUIにしておくと、課金導線の印象が安定します。

Regional PricingとPrice Optimizationの基礎

価格設定は、同じ数字を全員に見せるだけが正解ではありません。
Regional Pricingは地域ごとの購買感覚に合わせて価格を調整する考え方で、価格の壁を下げて参加しやすい課金導線を作るための仕組みです。
初期テストでは、メキシコで約17%、ブラジルで約26%、フィリピンで約52%、課金率の増加が出ています。
地域によって伸び幅が違うのは、同じ商品でも受け取られ方が同じではないことを示しています。

この数字が示しているのは、単に安くすればよいという話ではありません。
プレイヤーが「この内容なら払える」と感じる価格帯に届くかどうかが分かれ目です。
特にDeveloper Productsのような回転型商品は、少額でも繰り返し買われる設計なので、入口価格が合っているかどうかが全体の回転に直結します。
序盤の通貨補充や短時間ブーストを扱うときほど、地域差の影響が表に出やすくなります。

もうひとつ押さえておきたいのがPrice Optimizationです。
これは価格調整をテストしながら、より収益が伸びる地点を探る考え方で、対象クリエイターの中央値では収益が約4%増えています。
伸び幅だけを見ると派手ではありませんが、体験の中身を変えず、価格設計だけで数字が動くのは見逃せません。
サムネイル改善が入口を変えるのに対して、こちらは入場後の収益効率を変える施策です。

実際の運用では、Creator Hubで商品を作って終わりにせず、どの商品がどの場面で買われているかを見ながら微調整していく流れになります。
最初に通貨商品を低めの価格で出し、購入されるなら内容量を調整する、逆に見向きもされないなら効果や見せ方を変える、という順番のほうが無駄が少なくなります。
価格だけを触るのではなく、販売導線、商品説明、購入タイミングを一緒に見ないと、何が効いたのか判別できません。

DevExの基本条件と注意点

DevExは、体験内で得たEarned Robuxを換金する制度です。
ここで混同しやすいのが、ゲームの公開、ゲーム内販売、換金申請の3つは別条件で動いているという点です。
Game PassやDeveloper Productsを置いて収益化できる状態になっていても、そのまま自動的にDevExの対象になるわけではありません。

公開に関しては、前述の通りPublic化にも別の条件がありますが、DevExはそれとも切り離して考える必要があります。
つまり、体験を公開できることと、売上を現金化できることは同義ではありません。
収益化の入口を整える段階では、「まず売る仕組みを作る」「売上の質を整える」「換金条件は別枠で理解する」と分けて捉えるほうが混乱しません。

注意したいのは、DevExで対象になるのはEarned Robuxだということです。
どのRobuxが対象になるかという制度理解が抜けたまま設計を進めると、売上感覚と換金感覚がずれます。
とくに共同制作では、誰が収益設定を触れるのか、誰が管理画面を見るのかをCollaboratorsの権限で整理しておかないと、運用と分配の話が噛み合わなくなります。

収益化を始める段階で意識したいのは、売れる商品を1つ置くことだけではありません。
Creator Hubでの価格設定、体験内の購入UI、テスト公開での見え方、未成年プレイヤーへの配慮、そしてDevExの制度理解までつながってはじめて、無理のない運用になります。
収益化はスイッチを入れる作業ではなく、体験設計と運営設計をそろえる作業です。

安全設定と未成年クリエイターの注意点

未成年のクリエイターがRobloxで作品を公開するときは、公開設定そのものより先に、アカウント側の安全設定を年齢に合わせて整えておくことが土台になります。
子ども用アカウントには保護者アカウントを連携でき、保護者権限のもとでチャット、コンテンツ成熟度、課金、スクリーンタイムなどを管理できます。
設定変更を勝手に触られないようにPINを使う考え方もここに含まれます。
制作を始める段階では自由度ばかり見がちですが、公開後は知らない人との接点が一気に増えるので、先に守りを固めておくほうが運営が安定します。

実際、最初のFriendsテストに入る前に、保護者と一緒にPermissionsとチャット設定を見直したことがあります。
公開範囲だけをFriendsに変えても、アカウント側の会話設定や見知らぬ相手との接触条件が曖昧なままだと、不安が残ったままになります。
そこで保護者同席で一つずつ整理すると、「誰が入れるか」と「誰とどう会話できるか」が切り分けられ、身内テストを落ち着いて始められました。
最初は誰でも公開そのものに目が向きますが、安心感を作るのは周辺設定のほうです。

年齢に応じた安全設定と保護者連携

保護者連携を使う場合は、子どものアカウントに保護者アカウントをひも付けたうえで、保護者側から管理できる状態にしておく流れになります。
ここでは公開の可否だけでなく、年齢に応じたコンテンツ範囲、チャットの許可範囲、課金の扱いまで一つの線でつながります。
未成年クリエイターは制作意欲が先に立ちますが、体験を作る側であるほど、自分の作品ページやゲーム内メッセージが他人の目に触れる機会も増えます。
だからこそ、プレイする側としての安全設定と、公開する側としての運営設定を分けずに考える必要があります。

Publicへの切り替えは、保護者が横にいる状態で進めると判断がぶれません。
特に、タイトル、説明文、画像、収益導線は、作っている本人には見慣れた情報でも、外から見ると年齢不相応に見えたり、不要な誤解を招いたりすることがあります。
保護者が第三者の目線に近い役割を持つので、身内テストから一般公開へ進む節目で同席してもらう意味は大きいです。

チャット・プライバシー・通報まわりの見直しポイント

アプリ側ではSettingsの中に、チャットやプライバシー、安全性に関わる項目があります。
会話相手の範囲、連絡の受け取り方、各種安全機能の状態は、公開前にまとめて見直す対象です。
Robloxには年齢に応じたテキストフィルタがあり、不適切な語句は伏せ字化されますが、それだけで運営上の不安が消えるわけではありません。
自分の体験内で流れる案内文やサーバーメッセージまで含めて、会話の空気を荒らす表現がないかを見る必要があります。

通報導線も知識として持っておくべきです。
ゲーム内やアプリ内にはReport Abuseの導線があり、プレイヤー、チャット、体験、画像などを報告できます。
制作者側がこの導線を理解していないと、トラブルが起きたときに「どこで対処するのか」が曖昧になります。
未成年クリエイターほど、チャットを開けるかどうかだけでなく、問題が起きたときに報告できる前提まで把握しているかで安心感が変わります。

公開前に見るべき内容はゲーム本体だけではない

未成年クリエイターの公開前チェックで見落とされやすいのが、作品ページ周辺とゲーム内表示の文言です。
マップやスクリプトに問題がなくても、説明文に個人の連絡先を連想させる表現が入っていたり、画像に個人情報が映り込んでいたり、プロフィール誘導のつもりで外部サイトへの案内を書いていたりすると、それだけで安全面の評価は崩れます。
確認対象はサムネイル、アイコン、説明文、ゲーム内の看板、チュートリアル文、チャット欄に流す定型メッセージまで含みます。

とくに避けたいのは、外部サービスへの直接誘導です。
SNS、通話アプリ、個人サイト、連絡先交換につながる表現は、本人にその意図が薄くても危険を増やします。
「感想はここで送って」「続きは別サイトで」などの軽い案内でも、公開ページ上では重く見えます。
年齢不適切な冗談や内輪ネタも同様で、友だち相手には通じても、一般公開では別の意味に受け取られます。

画像と説明文の確認では、制作者本人の名前、学校、地域、SNS IDを連想させる文字列が入っていないかまで視野に入ります。
ゲーム内のサーバーメッセージも同じです。
たとえば自動メッセージに「作者に直接連絡して」などの一文が混ざっていると、運営上の窓口を個人に寄せる形になります。
未成年の公開では、体験の魅力を伝える導線と、個人へ接触させる導線を混ぜないことが基本です。

収益化導線は家庭内ルールまで含めて整える

収益化を入れる場合は、ゲーム内商品の配置だけでなく、その課金を家庭でどう扱うかまで含めて設計する必要があります。
Game PassやDeveloper Productsの導線を置ける状態でも、未成年本人と保護者の間で「どこまで許可するか」が決まっていないと、公開後にトラブルの火種になります。
自分のゲームに課金導線を置く立場になると、プレイヤーとしての課金ルールも切り離せなくなるからです。

ここで話し合う内容はシンプルです。
自分のアカウントで何を販売するのか、購入画面はどこで出るのか、自分自身が課金するときは保護者確認を挟むのか、売上やRobuxをどう理解するのか。
この整理ができていると、収益化を「お金が入る仕組み」として曖昧に見るのではなく、「どんな価値に対して、どんな見せ方で対価をもらうのか」という運営の話に変わります。
未成年クリエイターにとっては、公開設定、安全設定、課金ルールの3つが別々ではなく、ひとつの運営設計としてつながっている状態がいちばんぶれません。

よくある質問

公開まわりはPublish to Robloxの操作自体より、その先にある公開条件と更新の考え方でつまずくことが多いです。
保存や上書き公開は制作フローの一部として進められますが、Public化にはアカウント側の条件や作品側の状態が関わるため、ボタンを押せるかどうかと、一般公開できるかどうかは同じ話ではありません。

公開に審査はある？

まず切り分けたいのは、体験の保存や更新と一般公開への切り替えは別だという点です。
Studioから公開内容を保存したり、既存の体験に対して更新を反映したりする流れは制作作業として進みます。
一方でPublicにする段階では、アカウントが公開条件を満たしていることが前提になります。

ここで誤解されやすいのが、「公開ボタンを押したのに見えないから審査待ちなのでは」という受け止め方です。
実際には、待機列に入って時間経過を待つというより、公開条件を満たしているかどうかで先に進めるかが決まる場面が多いです。
新規体験を一般公開するときも、すでに公開済みの体験を更新するときも、同じようにアカウント条件が絡みます。

Public化に必要な条件としては、本人確認を通していることなど、追加要件が求められることがあります。
体験ページ側の説明文や画像を整えていても、アカウント条件が未充足だと公開の入口で止まります。
公開できるかどうかはゲームの出来だけでは決まらない、というのがこの段階の実務感です。

Publicにできない/ボタンが出ない

Publicに切り替えられないときは、不具合を疑う前にアカウント条件と体験の状態を順番に見ると整理できます。
詰まりやすいのは、アカウント年齢、本人確認、メールまたは電話の確認状況、そしてコミュニティ基準に触れていないかという点です。
公開ページの文言や画像に問題がある場合も、制作側では気づきにくい形でブレーキになります。

実際、公開ボタンが出ずに止まったとき、メール認証が未完了だったのを直しただけで先に進めたことがあります。
こういうケースは派手なエラー表示にならないので、設定画面の基本項目を一つずつ潰したほうが早いです。

体験そのものに原因があることもあります。
説明文、タイトル、画像、動画、ゲーム内表示のどこかが基準に触れていると、作品ページまわりで引っかかります。
前のセクションで触れた安全面の整理ともつながりますが、ゲーム本体だけ問題なければ通るわけではありません。
Game SettingsのPermissionsを見てもPublicが選べない、あるいは想定したボタンが見当たらないときは、UIの場所探しより先にアカウント条件を疑ったほうが筋が通ります。

公開後の更新

公開後の更新は、新しい作品を毎回作り直す必要はありません。
既存の体験に対してPublish to Robloxで上書きする流れを使えば、同じExperienceに更新を入れて運用できます。
作り直すたびに別体験へ分裂させないので、公開後の改善サイクルを保ちやすくなります。

この運用の利点は、既存プレイヤーがたどっていた公開ページや導線を維持したまま中身を更新できることです。
新しい体験を別で作ってしまうと、アクセス先が散り、分析や告知の基準も分かれます。
既存のExperience IDに対して再公開していく形なら、改善の履歴が一本の線でつながります。

実務では、不具合修正、チュートリアル調整、バランス変更を細かく重ねる時期ほど、この上書き更新の考え方が効きます。
友だちテストで見つかった問題を直して、そのまま同じ体験へ反映できるので、リンクの張り替えや新ページの説明文修正に追われません。
公開後の運営は一回きりのリリースではなく、同じ器を育てていく作業として捉えると噛み合います。

DevExと公開は別

Publicにできたからといって、そのまま換金の話にはつながりません。
公開はあくまで一般プレイヤーに遊んでもらえる状態にすることです。
DevExはその先の仕組みで、得たRobuxの性質や、換金に必要な条件を満たしているかが別に問われます。

ここを混同すると、「公開したのに収益化できない」「遊ばれているのに換金できない」というズレが起きます。
体験内にGame PassやDeveloper Productsを置けることと、受け取ったRobuxがそのままDevEx対象になることも同義ではありません。
公開＝換金可ではなく、公開は運営の入口、DevExは報酬制度の入口です。

非公開テストやFriendsテストの意味もここで見えてきます。
テスト段階は収益化の前準備というより、オンライン特有の不具合を見つける場です。
データ保存、権限まわり、サーバー遷移の崩れ方は、ひとりでStudio内だけを見ていても抜けます。
一般公開の前にその層を洗っておくと、公開後にプレイヤーの導線と収益導線を同時に壊す事故を減らせます。

まとめと次のステップ

公開の流れは、ボタン操作そのものよりも、段階を分けて育てる発想で捉えるとうまく回ります。
Studioで反映し、Permissionsで範囲を切り替え、Creator Hubで見せ方を整え、Analyticsで次の改善点を拾う。
この順番が崩れなければ、公開は一度きりのイベントではなく運営の入口になります。

要点の再掲

軸になるのは、StudioでPublish to Robloxを行い、Permissionsで公開範囲を調整し、Creator Hubでページ情報を整え、その後はAnalyticsで学ぶという流れです。
収益化はその延長線上に見えても、実務では別軸として考えたほうが整理できます。
Friends段階で拾った小さな改善が、Public移行後の定着にそのまま効いた場面は多く、身内テストの一言を軽く見ないほうが運営は安定します。

次のアクション（サイト内の学習導線）

まずはBaseplateから1本公開して、Privateでオンライン動作を確認してください。
次にFriendsへ切り替えて2〜3人に遊んでもらい、説明不足な導線や詰まる地点を直します。
Public化の前には、サムネイル、説明文、導線をまとめて整え、必要になった段階でGame PassやDeveloper Productsを追加し、Creator Analyticsで反応を計測すると流れがきれいにつながります。

2026年時点でもRobloxは現行の運用が続いていますが、UIや公開要件は更新され続けます。
公開直前は、いま見えている画面の文言と条件をあらためて確認してから進めると、余計なつまずきを避けられます。