roblox-studio

Roblox Studio

roblox-studio MCP ツールを使用して、Studio で現在開いているプレースを操作します。新しい作業は Workspace/MapDrafts 内に作成してください。

事前確認

1. MCP ツールが利用可能であることを確認します。ツールが見つからない場合や studio_ping がオフラインを報告する場合は、setup.md を読んでください。
2. 作業セッションのたびに studio_ping を実行します。
3. studio_get_tree で関連する階層を調べ、対象を絞った読み取りには studio_find_instances と studio_get_properties を使用します。
4. 変更を加える前に、プレースと対象ルートを明示します。ブリッジがオフラインのときに、Studio が変更されたかのように示してはいけません。

ワークフローを選ぶ

• 新しいマップまたは大規模な再構築： scene-spec.md を読み、SceneSpec を 1 つ作成してから、map_apply_scene_spec を使用します。
• 高速なグレーボックス作成：map_create_blockout を使用し、ビジュアルを仕上げる前にルートを検証します。
• 既存の生成済みマップの修復：まず調査し、関連する編集をまとめて studio_patch_instances で適用します。
• 大規模な修復の前に、studio_export_model を使用して非公開のローカルモデルバックアップを作成します。
• 対象を絞ったプロパティ編集：studio_set_properties を使用します。studio_create_instance は管理対象ルート内でのみ使用します。
• Terrain のみのタスク：明示的に範囲を指定して terrain_generate を使用します。
• Luau と Rojo の出力：codegen.target を both に設定し、適用前にすべてのスクリプトを確認します。
• ツールの選択や引数に不明点がある場合：tools.md を読んでください。

作成ループ

1. リクエストを、名前付きエリア、プレイヤーのルート、規模、スタイル、インタラクション、受け入れ条件に落とし込みます。
2. ユーザーが置き換えや編集を明示的に依頼していない限り、既存のコンテンツを保持します。
3. SceneSpec では、dryRun=true を指定して map_apply_scene_spec を実行します。
4. 対象ルート、オブジェクト数、変更対象のサービス、ファイルシステムへの書き込み、スクリプト、Terrain、報告されたリスクを確認します。
5. ユーザーが作成を依頼した場合、またはドライランを明示的に承認した場合は、dryRun=false で適用します。
6. 正確に返されたマップルートに対して、strictGeometry=true を指定して map_validate を実行します。
7. プレイ可能なマップでは map_readiness_check を実行します。profile="house" は、名前付きの house 契約にのみ使用します。
8. studio_focus_instance、studio_set_camera、studio_visual_probe を使用して、見やすい角度から確認します。
9. 動作が重要な場合は、function(args) を返す管理対象の Test ModuleScript を確認します。失敗時にはエラーを発生させ、成功時には JSON にシリアライズ可能な値を返します。confirmToken="RUN_STUDIO_TEST"、任意の mode（run または play）、および timeoutSeconds（整数 1～120、デフォルト 30）を指定して studio_run_test を呼び出します。テストはサンドボックスではなく、通常のプロジェクトコードを実行します。作業用コピーを使い、永続的な書き込みや外部への書き込みは無効にするか、モック化してください。
10. 具体的な失敗を修正し、検証を繰り返します。問題のないマップを再構築するよりも、対象を絞ったパッチを優先してください。

品質基準

• プレイ可能なマップには、SpawnLocation、分かりやすいルート、安全な着地点、明確な目的地を含めます。
• レベル、建物、ルート、システムには、一意で意味の分かる名前とモデルまたはフォルダーを使用します。
• 通常のマップは layout.grounding.mode="raycast" で地面に設置します。標高が既知の場合は manual を使用し、意図的な空中または空白のマップに限って none を使用します。
• ドア、ボタン、エレベーター、テレポーター、チェックポイントは functionalObjects に配置します。可能であれば、target を使って既存の目に見えるジオメトリに動作をバインドします。
• Terrain との交差、ドアの閉塞、階段の頭上空間、到達不能な着地点、ソリッド同士の重なりに関する検証警告は、修正対象として扱います。
• オブジェクト数や map_validate の結果だけで、マップがビジュアル面で完成したと判断してはいけません。
• ネイティブ権限が付与された後、実際のビューポートの証拠には studio_capture_viewport を使用します。デスクトップのキャプチャで代用したり、フレームを捏造したり、バックグラウンドのみのタスク中に権限ダイアログを表示したりしてはいけません。画像を共有する前に、ゲーム内テキストを確認します。

ガードレール

• Roblox の認証情報、Cookie、.ROBLOSECURITY を要求しないでください。
• ブリッジトークンは、ローカルの Studio プラグイン以外には送信しないでください。
• ユーザーが提示した許可リストにない外部アセット ID は使用しないでください。
• 直接編集と削除は、管理対象ルート内で行ってください。削除には、設定済みの確認トークンとユーザーの明示的な意図が必要です。
• 宣言型ツールを迂回するために studio_execute_luau を有効にしないでください。本当に必要な場合は、まずコードの内容とリスクを正確に説明してください。
• 生成する Luau では、リモートコード、HTTP、require(assetId)、loadstring、隠しローダーを避けてください。

引き継ぎ

正確なマップルート、マニフェストのパス、Rojo ファイル、検証／準備状況の結果、プレイテストの結果、残っている警告、次に Studio で手動確認する項目を報告してください。検証済みの結果と視覚的な判断を分けてください。