Roblox Studio UIデザイン入門 基本と手順

授業やワークショップで初心者と一緒にRoblox Studioの“上部ステータスバー”を作ると、左上基準のまま置いたUIがスマホ表示でずれ、AnchorPointを整えてScale中心に組み直した瞬間に配置が安定する場面によく出会います。
UI入門でつまずく原因は見た目の装飾より、最初の置き場所と座標の考え方にあることがここではっきり見えてきます。

この記事は、Roblox Studioで初めてGUIを作る人に向けて、StarterGuiにScreenGuiを追加し、Frame・TextLabel・TextButtonだけで最小構成の画面を作る流れから整理します。
ScaleとOffset、AnchorPointの役割を切り分けて、PC・タブレット・スマホで崩れにくいレイアウトを組み、Studio内のエミュレーションで見え方を確かめながら1つのレスポンシブUIまで仕上げます。

あわせて、GUIをクライアント側のLocalScriptで扱う理由と基本の置き場所も押さえます。
なお、2026年の新しいFlexible Studio UIでは画面表示やメニュー位置が異なることがあるため、その点も迷わない形で進めます。

Roblox StudioのUIデザインとは？まず押さえたい基本

ここでいうUIは、プレイヤーに情報を見せたり、ボタンやメニューで操作を受け取ったりする見た目の部分を指します。
UXは、そのUIを通してプレイヤーがどう感じるか、迷わず使えるか、気持ちよく進めるかまで含んだ体験全体です。
RobloxのUIづくりでは、派手な装飾よりも、必要な情報がすぐ読めて、押したい場所をすぐ触れることが先に来ます。
同じ内容のUIでも、余白の取り方や文字サイズを少し整えるだけで、情報が頭に入る速さが驚くほど変わります。
実際に画面を組んでいると、デザインが同じでも「読めるUI」と「読むのがつらいUI」の差は、色より先に文字の密度と間隔で出ます。

Roblox Studioでよく出てくる「GUI」は、ゲーム画面の上に表示するUI要素の総称です。
体力バー、メニュー、所持金表示、通知、ショップ画面といったものがここに含まれます。
基本の流れはStarterGuiの中にScreenGuiを置き、その子としてFrameTextLabelTextButtonなどを追加して画面を組み立てる形です。
GUIはプレイヤーごとに表示されるクライアント側の見た目を担うので、ワールドに置くパーツとは考え方が少し違います。
見えている画面を誰にどう出すのか、どの操作を受け取るのかを意識すると整理しやすくなります。

作業に入る前提も揃えておきます。
Roblox Studioは無料で使える制作ツールですが、利用はPC向けです。
スマホやiPadではStudio自体を動かせません。
スクリプトにはLuauを使いますが、このセクションではコードより先に、UIを置く場所と画面の見方を合わせます。
ここが曖昧なまま進むと、オブジェクトは作れたのに「どこに入れたのかわからない」「位置を変える欄が見つからない」という止まり方になりがちです。

この記事のゴールも、ここで改めて揃えておきます。
単に見た目の箱を置くだけではなく、ScreenGuiの基本構造を理解し、サイズと位置を決めるScaleとOffsetを使い分け、AnchorPointで基準点を揃え、PC・タブレット・スマホの複数端末で崩れにくい形に持っていきます。
さらに、プレイヤー画面の更新に使うLocalScriptをどこに置くのかまで含めて、実装に直結する形で進めます。
UIの学習はデザイン論だけで終えると手が止まり、逆に配置と構造だけで進めると読みにくい画面になります。
このセクションでは、その両方が同時に必要だという前提を揃える段階です。

事前準備：Roblox StudioでUIを作る前に必要なもの

Roblox StudioでUIを作り始める前に、まず揃えておきたいのは作業環境と画面の見方です。
ここが曖昧なまま進むと、オブジェクトは追加できても「どこに入ったのか分からない」「設定を変える場所が見つからない」という止まり方になり、最初の一歩で手が止まります。
特に今回はStarterGui配下にScreenGuiを置いて組み立てる流れに入るので、WindowsまたはMacでStudioを起動し、基本ウィンドウを見渡せる状態にしておくことが前提になります。

Roblox Studioは無料で使える制作ツールですが、動かせるのはPCだけです。
作業端末はWindowsかMacを前提にし、スマホやiPadではStudio自体を実行できません。
UIづくりでは後からLuauで動きを足す場面も出てきますが、この段階ではコードを書く前に、3Dビュー、階層、プロパティ編集の3つを迷わず追える状態を整えるほうが先です。

Explorer と Properties を表示する

Studioを開いたら、最初に確認したいのがExplorerとPropertiesです。
上部メニューのViewからExplorerとPropertiesを表示すると、どのオブジェクトをどこへ追加したか、選択した要素のSizePositionAnchorPointなどをどこで変えるかが一気に見えるようになります。
UI制作ではこの2つが作業の中心になり、StarterGuiの中にScreenGuiを入れる流れもExplorerが見えていないと追えません。

授業で初心者と一緒に触っていると、最初のつまずきでいちばん多かったのが「Explorerが見当たらない」という場面でした。
オブジェクトを追加したはずなのに画面上で見失い、そのまま何を触っているのか分からなくなる流れです。
そこで作業開始直後にViewタブからExplorerとPropertiesを必ず表示させる確認を入れるようにしたところ、その後の進行が止まりにくくなりました。
UIはレイアウト以前に、階層と設定欄を見失わないことが土台になります。

Explorerはオブジェクトの階層を確認する場所で、Propertiesは選択中の要素の設定を編集する場所です。
たとえばFrameやTextLabelを追加したあと、名前の整理はExplorer、文字色やサイズ変更はPropertiesというように役割が分かれています。
3Dビューだけ見て作業すると、見た目は変わっても構造が把握できず、どの要素を直しているのか追えなくなります。

この先の手順では、PC表示だけでなくスマホやタブレット相当の見え方も順番に確認していきます。
そのときに使うのがデバイス表示の切り替え機能で、後の工程でTestタブ側のプレビューを使って表示差を見ます。
今の段階では、複数端末で見え方が変わる前提だけ頭に置いておけば十分です。

TextLabel ｜ Roblox API Reference

Reference for the TextLabel class.

robloxapi.github.io

はじめてのUIを作る手順：画面上部にステータス表示を作る

このパートでは、StarterGuiの中にScreenGuiとTextLabelを置き、画面上部中央に「Coins: 0」と表示するところまでを一気に形にします。
装飾を増やす前に、まずは配置の基準をScaleとAnchorPointで固めると、PCでもスマホでも位置が暴れにくくなります。
とくに上部中央のような「真ん中基準」で置きたいUIは、左上基準のまま触るよりも、AnchorPointを先に整えたほうが手戻りが減ります。

完成イメージと設計方針

目標は、プレイ画面の上部中央に細長いステータス表示を置き、その中に「Coins: 0」という文字を見やすく表示することです。
今回は複雑なフレーム構成にせず、StarterGui配下のScreenGuiに直接TextLabelを置く最小構成で進めます。
まず1つ完成させる段階では、この形がいちばん迷いません。

レイアウトの考え方は、横幅と高さをScaleで決め、位置もScale中心で置きます。
Scaleは親要素に対する比率なので、0〜1の相対値で画面サイズに追従します。
たとえば横幅を広めに取りたいときは X 側を 0.9 にすると、画面幅の9割を使うバーとして扱えます。

中央寄せではAnchorPointが効きます。
今回はAnchorPointを Vector2.new(0.5, 0) にして、要素の上辺中央を基準点にします。
そのうえでPositionを UDim2.new(0.5, 0, 0.02, 0) にすると、画面の横方向は中央、縦方向は上から少し下げた位置に揃います。
左上基準のまま数値を追いかけるより、この設定に変えた瞬間に微調整の感覚が揃い、中央寄せの修正が一段ラクになります。

番号付きステップ

1. Roblox Studioを起動し、［New］からBaseplateを選びます。

UIだけを試す段階では、余計な仕掛けが入っていないテンプレートのほうが画面を確認しやすく、追加した要素も追いやすくなります。

1. ExplorerでStarterGuiを右クリックし、［Insert Object］からScreenGuiを追加します。

追加したScreenGuiは、名前を「MainUI」に変更しておくと後から見失いません。
GUIはプレイヤーごとの画面に表示する要素なので、ここを起点にして組み立てる形になります。

1. 「MainUI」を右クリックし、［Insert Object］からTextLabelを追加します。

追加したらTextLabelを選択した状態でPropertiesを開き、サイズや位置をここで編集できるようにします。
画面上でドラッグしても置けますが、最初は数値で揃えたほうが配置の意味を覚えやすくなります。

1. TextLabelのレイアウトを設定します。

まずSizeを UDim2.new(0.9, 0, 0.08, 0) にして、横幅を広め、縦幅を薄めのバーにします。
続けてAnchorPointは Vector2.new(0.5, 0) に設定します。
Positionを UDim2.new(0.5, 0, 0.02, 0) にすると、画面上部中央に揃います。
上方向の余白をもう少し詰めたいときだけ、Y の scale か offset を少しだけ触る形にすると迷いません。
必要なら padding 相当の余白は offset 側で小さく足します。

1. 見た目を読みやすい形に整えます。

Textは "Coins: 0" に変更し、TextScaledを有効にします。
これでラベルの大きさに応じて文字サイズが自動調整されます。
あわせてBackgroundTransparencyを上げて背景を薄くしたり、FontやTextColor3を見やすい配色に変えたりすると、情報表示としてまとまりが出ます。
ここでは派手さより、ぱっと見て読めることを優先します。

1. 表示を動かしたい場合は、TextLabel の子として LocalScript を追加します。TextLabel を右クリックして［Insert Object］から LocalScript を入れれば、プレイヤーの画面側でテキストを書き換えられます。LocalScript はプレイヤーのクライアント環境（ScreenGui 配下や PlayerScripts など）で実行されるため、Studio の編集モード（Edit）やサーバー側の Script では動作しません。必ず Play / Play Solo で動作確認してください。

この段階まで終わると、上部中央に固定されたステータスバーの土台ができています。
以降のUIを増やすときも、同じ考え方でTextButtonや別のラベルを足していけます。

Luau（LocalScript）での最小更新例

静的な「Coins: 0」だけでもUIとして成立しますが、数字が変わるとTextLabelの役割がはっきり見えてきます。
ここでは練習用として、1秒ごとにコイン数が増える最小例を載せます。
LocalScriptは、さきほど作成したTextLabelの子に入れてください。

local label = script.Parent
local coins = 0

label.Text = "Coins: " .. coins

while true do
	task.wait(1)
	coins += 1
	label.Text = "Coins: " .. coins
end

まずこれを書いてみてください。
プレイを開始すると、画面上部中央の表示が「Coins: 0」から1秒ごとに増えていきます。
文字列の更新先が script.Parent なので、このLocalScriptがTextLabelの中に入っていれば、そのラベル自身のTextを書き換える形になります。

このコードの目的は、ゲーム内通貨の本実装ではなく「UIの更新場所」をつかむことです。
サーバー側の本物の所持金管理とは切り分けて、まず表示が変わる感覚を掴むと、次に値の受け渡しを学ぶときも整理しやすくなります。

スクリーンショットの目安

このセクションでは、作業の区切りごとに3枚あると流れが追いやすくなります。
1枚目はExplorerに「MainUI」とTextLabelが見えている状態です。
StarterGuiの中に何を作ったのかが一目で伝わきます。

2枚目はPropertiesでSizeAnchorPointPositionを設定している画面です。
数値入力の場所が見えると、読者はドラッグではなく設定欄から直す手順をそのままたどれます。
とくに Size = 0.9, 0.08 相当、AnchorPoint = (0.5, 0)、Position = (0.5, 0, 0.02, 0) の並びが画面に入っていると、中央寄せの考え方が伝わります。

3枚目はプレイ画面で、「Coins: 0」が上部中央に表示されている状態です。
LocalScriptを入れた場合は、数字が増え始めたタイミングでも構いませんが、まずは初期表示の「Coins: 0」が見えているカットのほうが完成形としてわかりやすくなります。
加えて、後のデバイス確認ではTestタブのエミュレーションでPhoneTabletPCを切り替え、同じバーが中央から外れていないかを見る流れにつながります。

UIの基本パーツを理解する：ScreenGui・Frame・TextLabel・TextButton

ここで覚えるUIパーツは多くありませんが、それぞれの役割を最初に切り分けておくと、後からレイアウトもスクリプトも崩れにくくなります。
ScreenGuiを画面単位の入れ物として置き、その中にFrameTextLabelTextButtonを必要に応じて入れる、という形を基準にすると、Explorer上の親子関係と画面の見え方がきれいに対応します。

StarterGuiとScreenGuiの関係

RobloxのGUIは、まずStarterGui配下にScreenGuiを置くところから始まります。
ScreenGuiは1画面分のUIをまとめるコンテナで、たとえばメインHUD用、設定画面用、ショップ用というように、機能ごとに分けて持たせる土台になります。

Explorerで見ると、基本形はStarterGuiの子にScreenGuiがあり、その下にFrameやTextLabelTextButtonが並ぶ構造です。
この親子関係は見た目の整理だけでなく、SizeやPositionのscale成分が「どの親を基準に計算されるか」に直結します。
ScreenGuiの中に置いたFrameを親にしてラベルやボタンを配置すると、子要素はそのFrameの大きさを基準に相対指定されるので、画面全体に直接ばらまくより構造が読み取りやすくなります。

前のセクションで作ったステータス表示も、この考え方の延長にあります。
まずScreenGuiを作り、その中に上部バー用のFrameや表示用のTextLabelを入れるだけで、どの要素がどこに属しているのかがExplorer上ではっきりします。
UIが増えてきたときほど、この階層の素直さが効いてきます。

主要UIオブジェクトの役割

最初に押さえたいのは、Frameは土台、TextLabelは表示、TextButtonは操作、という役割分担です。
名前どおりではありますが、この切り分けを意識して作るだけで、Propertiesで触る項目が整理され、どのオブジェクトに何を設定すべきか迷いにくくなります。

Frameは2Dの矩形を描画するオブジェクトで、UIのパネルや背景、区切りの土台として使います。
たとえば上部のステータスバー全体をひとつのFrameにして、その中へ通貨表示のTextLabelやメニューを開くTextButtonを入れると、バー全体の位置やサイズを親側でまとめて動かせます。
細いFrameを線のように使って区切りを作ることもできます。

TextLabelはテキスト表示専用です。
所持金、HP、説明文、タイトルなど、「押せない文字」はまずTextLabelで考えると整理が進みます。
Text、Font、TextColor3、TextScaledといった表示寄りのプロパティに集中できるので、文字を見せるという目的がぶれません。
前のセクションの「Coins: 0」のような表示は、この役割がもっともわかりやすい例です。

TextButtonはテキスト付きのボタンです。
見た目はラベルに近くても、クリックやタップで反応させたいならTextButtonを使います。
TextButtonは操作を受け取る前提のオブジェクトなので、見た目だけをTextLabelで再現して後から無理に入力処理を足すより、構造がまっすぐになります。
押したときの処理はActivatedで受ける形にしておくと、クリックとタップの両方を同じ流れで扱えます。
押したときの処理は Activated イベントで受けると、クリックとタップの両方に対応できます。
最初のうちは、四角いものは全部Frameで作って、その上に何とか文字や機能を載せたくなるものです。
実際、その作り方でも一応は形になります。
ただ、表示したい文字までFrame中心で組み始めると、背景用の設定と文字用の設定が頭の中で混ざり、Propertiesの確認箇所が一気に増えます。
土台はFrame、文字はTextLabel、押す場所はTextButtonと分けた途端、どのオブジェクトに何を持たせるかが明確になり、あとで見返したときも修正点をすぐ拾えるようになります。
最初はFrameで土台を作り、その上に文字や機能を載せる流れが多いです。
ただし、背景用と文字用の設定が混ざると修正箇所が増えるので、土台はFrame、文字はTextLabel、押す場所はTextButtonと役割を分けるのが効率的です。
親子関係もここで意識しておきたいところです。
ScreenGui > Frame > TextLabelのように入れていけば、ラベルのPositionやSizeはFrameを親として考えられます。
画面全体に対して直接座標を置くより、まず土台を作ってからその中に部品を並べるほうが、UIのまとまりが崩れません。
中央配置でも端寄せでも、親がはっきりしているだけで計算対象が定まり、配置のミスを追いかける時間が減ります。

画像系UI（ImageLabel/ImageButton）に軽く触れる

文字と四角だけでもUIは作れますが、アイコンや装飾を入れたくなったら画像系オブジェクトが出番になります。
表示専用ならImageLabel、押せる画像ボタンならImageButtonです。
考え方はTextLabelとTextButtonの画像版だと思うとつかみやすくなります。

ImageLabelは、コインのアイコン、背景の装飾、メニューの記号などを置くときに向いています。
Frameでも色面は作れますが、絵柄やピクトグラムまでは表現できません。
そこを画像で補うことで、情報の意味が一目で伝わるUIになります。
ImageButtonは歯車アイコンの設定ボタンや、ショップを開く小さなボタンのように、見た目そのものを操作対象にしたいときに使います。

ここでも適材適所の考え方が効きます。
最初は全部Frameで囲ってから何とか形に寄せがちですが、アイコンはImageLabel、押すアイコンはImageButtonと分けるだけで、BackgroundTransparencyやImageTransparencyなど見るべき設定が自然に絞られます。
UIが少し凝った見た目になってきた段階ほど、テキスト系・画像系・土台系を分けておく恩恵が大きく出ます。

構造としては、ScreenGuiの下にFrameを置き、その中へTextLabelTextButtonImageLabelImageButtonを並べる形が基本です。
どの親の中に入っているかで、見た目のまとまりも相対配置の基準も決まります。
UIパーツの名前だけを覚えるより、「その部品は何を表示し、何を操作し、何を親にして置かれているか」をセットで見ると、Studio上の画面とExplorerの階層がひとつにつながって見えてきます。

ImageLabel ｜ Roblox API Reference

Reference for the ImageLabel class.

robloxapi.github.io

レイアウトの基本：Scale・Offset・Position・AnchorPoint

レイアウトでつまずく原因の多くは、部品そのものよりもUDim2の考え方を曖昧なまま使ってしまうことにあります。
画面サイズが変わっても形を保ちたいなら、Scaleで骨組みを作り、必要なところだけOffsetで詰め、AnchorPointで基準点を固定するという順番で考えると、配置の再調整が一気に減ります。

ScaleとOffsetの違い

SizeやPositionに入れるUDim2は、UDim2.new(xScale, xOffset, yScale, yOffset) の4つで構成されます。
このうち Scale は親要素に対する相対値、Offset はピクセル指定の固定値です。
Scale の基本は 0〜1 の範囲で扱い、親の幅や高さに対して何割使うかを決めます。
Offset はその上に「あと数ピクセルだけ右へ」「高さを固定でそろえる」といった調整を足す役目です。

たとえば、画面幅の半分にしたいなら X 側は Scale を 0.5 にします。
反対に、幅を 200px に固定したいなら Offset 側で指定します。
ここを逆に考えると、PCでは見栄えがよくても、スマホにした瞬間に窮屈なUIになります。
実際、最初の頃は Offset 中心でバーやボタンを並べて作り、Studio 上では整って見えたのに、スマホ表示へ切り替えた途端に横幅が足りず、文字が押し合って作り直しになりました。
そこから Scale を先に決めて、AnchorPoint で位置の基準をそろえる組み方へ変えたところ、後から触るのは余白の数ピクセル調整くらいで済む場面が増えました。

使い分けを短く整理すると、次の形になります。

• Scale指定の利点: 親の大きさに追従するので、複数端末でもレイアウトの比率が保たれます
• Offset指定の注意: 固定ピクセルなので、画面が狭くなると詰まりやすく、広い画面では余白が不自然に見えます
• 基本方針: まず Scale で全体の骨組みを決め、必要な余白や微調整だけ Offset を足します

この考え方はFrameを親にした構造でも同じです。
前のセクションで触れたように、親子関係がはっきりしているほど、Scale が何に対する比率なのかが明確になります。
画面全体に対して直接置くより、ScreenGuiの下に土台のFrameを作り、その中で相対配置するほうが、各パーツの意味が揃います。

PositionとAnchorPointの基礎

Positionは「どこに置くか」、AnchorPointは「その要素のどの点を基準に置くか」を決めるものです。
ここを分けて考えないと、数値は合っているのに見た目がずれる、という状態になります。

AnchorPointのデフォルトは (0, 0) で、左上が基準です。
つまり Position = UDim2.new(0.5, 0, 0, 0) のように書いても、要素の左上が親の中央付近に来るだけで、要素全体が中央にそろうわけではありません。
中央寄せしたいなら、基準点を要素の真ん中へ移してから配置します。
典型例は AnchorPoint を Vector2.new(0.5, 0.5) にし、Position を UDim2.new(0.5, 0, 0.5, 0) にする組み合わせです。
これで要素の中心が親の中心に一致します。

上端中央へ置きたい場面では AnchorPoint = Vector2.new(0.5, 0) がよく合います。
X 方向だけ中央基準にして、Y 方向は上端を基準にする形です。
たとえばステータスバーや通知帯を画面上部に置くとき、左上基準のまま数値だけで合わせるより、AnchorPoint を先に決めたほうが Position の意味がぶれません。
下部固定なら AnchorPoint = Vector2.new(0.5, 1) のようにして、Position の Y を下端寄りに置くと、画面下に吸い付くような配置になります。

比較すると差が見えます。

Position は画面の何割地点に置くかを示し、AnchorPoint はその地点へ要素のどの部分を合わせるかを示します。
数値をこう分解して考えると、要素を追加しても配置の意味が明確になります。

体力ゲージで学ぶ Size と Position の指定

実際のUIで見ると、Scale と AnchorPoint の効き方がつかみやすくなります。
たとえば体力ゲージの土台になるFrameを作るなら、サイズを Size = UDim2.new(0.75, 0, 0.1, 0) とすると、画面幅の75%・高さ10% のバーになります。
横長のゲージをどの端末でも同じ比率で見せたいときに、この形は扱いやすい骨組みになります。

上部中央に置くなら、次の組み合わせがわかりやすいです。

local gaugeFrame = Instance.new("Frame")
gaugeFrame.Size = UDim2.new(0.75, 0, 0.1, 0)
gaugeFrame.AnchorPoint = Vector2.new(0.5, 0)
gaugeFrame.Position = UDim2.new(0.5, 0, 0.02, 0)

この指定では、横方向は中央基準、縦方向は上端基準です。
Position の X を 0.5 にしているので親の中央へ置かれ、Y を少し下げることで画面上端に張り付きすぎない位置になります。
AnchorPoint を左上のままにすると、ゲージの左端が中央へ来てしまい、幅が広いほど見た目のバランスが崩れます。

下部固定にしたいなら、基準点を下側へ移します。

local gaugeFrame = Instance.new("Frame")
gaugeFrame.Size = UDim2.new(0.75, 0, 0.1, 0)
gaugeFrame.AnchorPoint = Vector2.new(0.5, 1)
gaugeFrame.Position = UDim2.new(0.5, 0, 0.98, 0)

この形なら、バーの下端が画面下寄りの位置にそろいます。
高さをあとから調整しても、下側を基準に保ったまま伸び縮みするので、フッター型のUIで扱いやすい配置になります。

ゲージ本体を減らす部分も、親子構造で考えると整理できます。
外枠のFrameを親にして、その子に中身用のFrameを置き、満タン時は横幅を親いっぱいに設定します。
体力が半分なら、中身のサイズを横方向だけ半分へ縮める、という流れです。
こうしておくと、外枠の位置やサイズを変えても、中身のバーは親基準で追従します。

この体力ゲージの作り方は、経験値バー、スタミナバー、読み込みバーにもそのまま応用できます。
バーの役割が変わっても、相対サイズで骨組みを作り、AnchorPoint で基準をそろえ、Offset を仕上げに使うという順序は変わりません。
ここが固まると、UI全体のレイアウトが場当たり的な数値合わせから抜け出します。

複数端末で見やすくするコツ

PCで形になったUIでも、そのまま公開するとタブレットやスマホで印象が変わります。
画面サイズだけでなく横長・縦長の比率も違うので、PCでちょうどよかった余白やボタン幅が別端末では不足し、情報を詰め込んだ部分ほど崩れが目立ちます。
PCだけで完成と思い込まないために、レイアウトの考え方とRoblox Studio内での確認ポイントを整理します。

デバイス別の解像度差を理解する

PC・タブレット・スマホは、見えている画面の広さも形もそろっていません。
PCでは横方向に余裕があるため1行に収まっていた情報も、スマホでは縦に伸びて視線移動が増えます。
タブレットはその中間に見えても、縦向きと横向きで必要な余白の感覚が変わるので、1つの見た目を全端末へそのまま当てはめる発想だと破綻します。

こういう差を吸収する土台になるのが、前述のScale中心のレイアウトです。
UDim2 の scale 成分は親に対する比率で動くので、位置とサイズのベースは相対座標・相対サイズで決め、細かな余白だけを offset で整える形にすると、端末が変わっても骨組みが保たれます。
scale は 0 から 1 の相対値として扱えるため、まず比率で全体を組み、そのあとに微調整を足す順番が安定します。

実際に、PCではちょうどよく見えていたTextButtonが、スマホに切り替えた瞬間に押しづらく見える場面はよくあります。
横幅と高さを offset 寄りで作っていたときは、表示はできても指で狙うには窮屈でした。
そこで Size は scale を使って少し大きめに取り、内側の詰めだけを padding の offset で調整すると、見た目のバランスを保ったままタップの余裕が生まれました。
こういう調整は、最初から情報密度を落とし、要素の間隔を広めに取っておくと手戻りが減ります。

画面端ぎりぎりへ重要なUIを置かない意識も欠かせません。
通知、通貨表示、メインボタンのような要素は、安全領域を見込んで少し内側へ寄せたほうが、視認性も操作性も安定します。
端にぴったり合わせる配置はPCでは整って見えても、別の画面では圧迫感が出やすく、読み取りに必要な視線移動も増えます。

Studioのデバイス表示確認

レイアウトは頭の中で想像するより、Roblox Studioで端末表示を切り替えて見たほうが早く問題が見つかります。
上部メニューのTestからEmulationを開くと、Device、Orientation、Resolution を切り替えながら表示を確認できます。
新しいStudioのUIでは配置が少し違って見えることがありますが、デバイス表示を切り替えて確認する流れ自体は変わりません。

ここで見たいのは、単に「映っているか」ではありません。
テキストが途中で切れていないか、フレーム同士が近すぎないか、画面上端や下端に寄せた要素が窮屈に見えないか、横向きにしたとき余白が不自然に空いていないか、といった読み心地まで含めて見ます。
とくにステータス表示や固定ボタンは、PCでは余裕があってもスマホの縦画面で密集しやすいので、見えた瞬間の圧迫感まで拾うと調整の質が上がります。

Emulationは実機確認の前段としても便利で、レイアウト崩れの初期発見に向いています。
作業の区切りごとに PC、タブレット、スマホの表示を往復しておくと、「完成してからまとめて直す」状態を避けやすくなります。
UIを1つ追加するたびに軽く切り替える習慣があるだけで、後半の修正量が膨らみにくくなります。

複数端末対応で見落とされがちな点は、情報量そのものです。
表示領域が狭いスマホに PC と同じ密度でラベルやアイコン、数値、説明文を載せると、読めても疲れる UI になります。
要素を減らせない場合は、優先度の低い情報を補助へ回し、主役の操作だけを目立たせると理解速度が落ちません。

文字の可読性とタップ領域は常にセットで確認してください。
TextScaled を使っていても、ボタン自体の高さが足りなければ文字は縮み、読めても押しにくい状態になります。
ここで挙げる最小サイズやタップ領域の数値はあくまでコミュニティや一般的な UX ガイドラインで使われる実務上の目安です（例: タップ領域の目安は高さ 44–48px 程度）。
端末の DPI やユーザー側のフォント設定、プラットフォーム差で見え方が変わるため、最終的には実機での確認とユーザーテストを必ず行ってください。

UIづくりで初心者が止まりやすいのは、見た目の調整よりも「なぜ反映されないのか」が分からなくなる場面です。
位置ずれ、文字の読みにくさ、表示されない、クリックしても動かないといった症状は一見ばらばらに見えますが、レイアウト基準とスクリプトの役割分担を整理すると原因が明確になり、修正が速くなります。

AnchorPoint未使用/Offset過多のリスク

PCでは整って見えたのに、スマホへ切り替えた瞬間にUIが端へ寄ったり、中央に置いたつもりのFrameやTextLabelが少しずれて見えたりする原因は、ほとんどがAnchorPointとOffsetの扱いにあります。
基準点を左上のままにして Position だけ中央付近へ置くと、要素の左上がその座標に合うため、見た目の中心とは一致しません。
そこへ固定ピクセルの offset を多く混ぜると、画面サイズが変わったときにずれ方まで大きくなります。

中央寄せを安定させたいなら、要素の基準点を中央へ移してから、位置とサイズのベースを scale 中心で組み直すのが素直です。
AnchorPointを Vector2.new(0.5, 0.5) にして、Position を UDim2.new(0.5, 0, 0.5, 0) に置くと、要素の中心が親の中央へ揃います。
この形にしておくと、画面が広くなっても狭くなっても、座標の意味がぶれません。
offset は余白の微調整にとどめ、骨組みそのものを固定ピクセルに頼らないほうが、複数端末での再配置が減ります。

とくに上部バー、通知パネル、中央ダイアログのように「どの端末でも同じ意図で見せたいUI」は、最初から scale を土台にしたほうが崩れ方が予測できます。
offset で無理に合わせたレイアウトは、その場では整っても、別の画面サイズへ持っていくと再調整が連鎖します。
UI位置がずれるときは、見た目を少しずつ動かす前に、基準点がどこにあるかを見るほうが早く解決できます。

可読性

文字が小さすぎて読みにくい問題は、UI全体のサイズではなく、テキスト要素の中で何が起きているかを見ると原因が見えます。
TextLabelやTextButtonに TextScaled を入れていても、親の高さが足りなければ文字は自動で縮みます。
つまり、TextScaled を有効にするだけでは十分ではなく、文字が収まる箱の大きさまでセットで考える必要があります。

スマホで詰まりやすいのは、PC基準で作った細いボタンや短いラベルをそのまま持ち込んだときです。
表示自体はできても、文字が小さくなり、読めるけれど一瞬で意味が入ってこない状態になります。
こういうときは、TextScaled を有効にしたうえでスマホプレビューを見ながら最小サイズ感を確認し、必要ならボタンやラベルの高さを増やしたほうが改善が速いです。
テキストの太さや背景とのコントラストも効きます。
文字色と背景色の差が弱いと、サイズ不足以上に読みにくく見えます。

見出し、数値、補足ラベルを全部同じ強さで並べると、画面が窮屈に見えます。
主役にしたい情報を少し太くし、補助情報は色や位置で整理すると、同じ面積でも読み取りの負荷が下がります。
可読性はフォントサイズだけの問題ではなく、UI全体の優先順位が見えているかどうかで決まります。

表示されない/動かない時のチェックリスト

GUIが反映されないときは、見た目の問題とスクリプトの問題を一度分けて考えると詰まりません。
まず表示されないケースでは、ScreenGuiそのものが無効になっているか、配置場所がずれていることが多いです。
ScreenGui.Enabledがオフのままだと子要素をいくら調整しても画面に出ませんし、StarterGuiではない場所へ置いていると、プレイヤー画面に期待通り出てこないまま止まります。
Explorer で階層を見たときに、ScreenGuiの下へFrameやTextLabelが入っているかまで追うと、表示階層の見落としを潰せます。

動かないケースでは、スクリプトの種類と置き場所のミスが定番です。
GUIの更新はクライアント側で動かすのが基本なので、通常のScriptでUIを直接変えようとしても、そのままでは意図通りになりません。
相談でも「ScriptでUIを更新しようとして動かない」という内容が毎回のように出ますが、実際にはLocalScriptの置き場所を見直すだけで片づくことが多いです。
ScreenGui配下にLocalScriptが入っているスクリーンショットを見せると、その場で原因に気づいて解決する場面が多く、初心者ほどここを構造で覚えたほうが混乱が減ります。

サーバーとクライアントの混同も見逃せません。
ゲームの状態そのものはサーバー側で持ち、プレイヤーごとの表示更新はクライアント側で受け持つ、という分担にすると整理できます。
文章で図にすると、サーバーがスコアや体力の値を用意し、その値をReplicatedStorageのような共有しやすい場所で橋渡しし、各プレイヤーのLocalScriptが受け取ってTextLabelやFrameの表示を変える流れです。
この順番を逆にして、サーバーのScriptだけで画面表示まで完結させようとすると、どこで止まっているのか見えなくなります。

切り分ける順番は、次の3点でほぼ足ります。

• ScreenGuiが有効で、配置先がStarterGuiになっているか確認する
• GUI更新用のスクリプトがLocalScriptで、しかもScreenGui配下にあるか確認する
• ゲーム状態の管理と画面表示の更新を同じ場所で処理しようとしていないか

この3つを順番に見るだけで、GUIが表示されない、ボタンを押しても動かない、値を変えたのに画面が更新されないといった典型的な詰まり方はほぼ説明できます。
症状だけを見ると別々のトラブルに見えても、実際には「どこに置いたか」と「どこで動かすべきか」が整理されていないだけ、というケースが大半です。

次のステップ：見た目を良くする方法と公式学習先

基本の配置と可読性がつかめたら、次は「どう作るか」を整える段階です。
合わせて読みたい: Roblox Studio 入門（基礎）、UI ベストプラクティス（配色・余白）

Studio内だけで設計 vs 外部ツール併用

最初の一歩としては、Studio内でScreenGuiFrameTextLabelを置きながら考えるやり方で十分です。
置いた瞬間に画面で確認できるので、動くものを早く作れます。
UIの基礎を覚える段階では、この即時性が強く効きます。
一方で、見た目にこだわり始めると、Studioだけでは比較検討の幅が狭くなります。
どの情報を大きく見せるか、余白をどれだけ取るか、カードを何枚並べるかといった判断は、先にワイヤーフレームを作ってから入ったほうが整理しやすくなります。
合わせて読みたい: Roblox Studio 入門（slug: studio-basics）、UI ベストプラクティス（slug: ui-best-practices） 一方で、見た目にこだわり始めると、Studioだけでは比較検討の幅が狭くなります。
どの情報を大きく見せるか、余白をどれだけ取るか、カードを何枚並べるかといった判断は、先にワイヤーフレームを作ってから入ったほうが整理しやすくなります。
紙に描く方法でも十分ですが、外部デザインツールを使うと複数案を並べて見比べやすく、配色や文字組みまで先に詰められます。

実際、外部で作ったワイヤーフレームを横に置いてStudioへ落とし込むようにしてから、余白と行間の質が一段上がりました。
Studio内だけで調整していたときは、要素そのものの位置ばかり見ていましたが、外で設計してから移すと「どこを空けるか」が先に決まり、結果として画面の密度が落ち着きます。

外部ツール併用には、もちろん再現の工程が入ります。
作った見た目をそのまま自動で完成させるのではなく、Studio側でFrameやTextLabelに分解して組み直す設計が必要です。
だからこそ、最初から凝った画面を目指すより、ワイヤーフレームで情報の優先順位を決め、StudioでScaleとAnchorPointを使って骨組みを作り、細部だけ外部案に寄せる流れが安定します。

おすすめの公式学習ルート

次に学ぶ順番としては、UIの公式カリキュラムから進めるのが遠回りに見えて最短です。
基礎の画面配置を作れた段階で、UIカリキュラムに沿ってパーツの組み合わせ方やレイアウトの考え方をなぞると、「作れた」で止まらず「直せる」に進めます。

合わせて読みたいのが、UI/UXまわりのベストプラクティスや、外部アプリ連携の考え方を扱うドキュメントです。
ここでは見た目の派手さより、情報の順番、視線の流れ、タップしやすい配置、外部で作った素材や設計案をどうStudioに持ち込むかが学べます。
学習のコツは、読むだけで終わらせず、小さな画面を1つ作って試すことです。

新しいStudioのUIは2025年から2026年にかけて更新が進み、2026年1月5日には新しい柔軟なStudio UIの恒久ロールアウトも始まりました。
画面の配置やパネルの見え方に多少の違いがあっても、学ぶべき中身は変わりません。
Explorerで階層を確認し、Propertiesで値を調整し、TestのEmulationで表示を確かめる、この軸を持って進めれば迷いにくくなります。

（参考）Studioウィジェットとゲーム内UIの違い

ここで混同しやすいのが、ゲーム内UIとStudio内のウィジェットUIです。
プレイヤーに見せるUIはStarterGuiから始まるScreenGui中心の世界ですが、プラグインの操作画面はDockWidgetPluginGuiから作る別分野です。
見た目はどちらもパネルに見えても、用途も置き場所も違います。

この違いを早めに知っておくと、「プラグインの解説を見たのにゲーム画面に出ない」という混乱を避けられます。
今の段階で優先すべきなのは、ゲーム内で動くUIです。
プラグインや拡張ツールは、制作フローを整えたい段階で触れると役割が理解しやすくなります。

必要に応じてプラグインや外部アプリを使う、という発想自体は持っておく価値があります。
たとえば、作業を速める補助や、見た目の設計を外で詰める流れは有効です。
ただし学習の主軸は、まずScreenGuiで1画面を完成させることに置いたほうが、道具に振り回されません。

Next Actionsチェックリスト

次に手を動かす内容は、次の5つで十分です。

1. Baseplateで新規プロジェクトを作成する
2. StarterGuiにScreenGuiを追加する
3. FrameとTextLabelで1つの情報表示UIを作成する
4. ScaleとAnchorPointを使ってスマホ表示でも崩れないよう調整する
5. 公式UIカリキュラムの次のレッスンへ進む

ここまで進めると、UIを「置く」段階から「設計する」段階へ移れます。
まずは小さな1画面を作り、紙でも外部ツールでもよいのでワイヤーフレームを添えて作り直してみてください。
同じ内容でも、設計してから組んだUIは読み順と余白に差が出ます。