Unity uGUIの基本設定7項目｜文字・配置・画像・描画負荷

uGUIで作ったUIの文字・画像・配置が意図どおりにならないときに、確認する設定を7項目に分けました。Canvasの描画方式と基本的な画面サイズ対応はCanvasの使い方で説明し、このページでは個々の部品の調整と負荷の調べ方を扱います。

説明の根拠は2026年10月3日に確認したuGUI 2.0の公式資料です。掲載画像は既存記事の旧画面で、今回のUnity実行結果ではありません。画像の正確なEditor・パッケージ版は確認できていません。UI Toolkitの設定や、すべての環境に共通する性能値としては扱いません。

症状から確認する場所を選ぶ

困っていること	確認する設定
UIが隠れる・ボタンが押せない	Canvas内の順序、入力、Raycast
文字だけがぼやける	Gameビューの倍率、文字方式、フォント
部品のサイズ変更で位置がずれる	アンカー、ピボット、サイズ制御
枠や背景を繰り返したい	Image TypeとSpriteのBorder
画面比率を変えると切れる	Canvas Scaler、親と子のアンカー
部品を指定座標へ置きたい	Rect Transformの数値と基準点
UIの描画が重い	Profiler、バッチ、マスク、更新頻度

1. Canvasの描画順とボタン入力を確認する

同じCanvas内では、Hierarchyで後にある兄弟要素が手前に描画されます。別Canvasを比べる場合はRender Mode、Sorting Layer、Sort Order／Order in Layer、子CanvasのOverride Sortingなどを確認します。順序の数値だけを変える前に、どのCanvasが描画しているかを特定してください。Canvasの公式資料

• 表示の確認：対象と親が有効か、Canvasに含まれるか、画像や文字が別の要素の後ろに隠れていないかを確認する。
• 入力の確認：通常のuGUIイベントにはEventSystemと入力方式に対応したInput Module、Canvas側のGraphic Raycasterが必要。
• ボタンが反応しない場合：ButtonのInteractable、CanvasGroupのInteractable／Blocks Raycasts、前面の画像のRaycast Target、On Clickの割り当てを確認する。

Input Systemを使うuGUIではInputSystemUIInputModule、旧Input ManagerではStandaloneInputModuleという違いがあります。旧記事の画面と現在の入力方式が合うかを確認し、表示できることと押せることを分けて試します。Input System 1.17のUI入力資料

2. 文字のぼやけを切り分ける

旧作例はUnityEngine.UI.Textを使う文字表示の資料です。Gameビューが基準より小さいときの表示と、設定を合わせた表示を比較しています。ただし、文字がぼやける原因をReference ResolutionとGameビューの不一致だけに限定することはできません。

1. Gameビューの解像度と表示倍率を記録する。ビュー内の縮小表示と、出力画像そのものの文字品質を区別する。
2. Canvas Scalerの設定、文字と親のScale、フォントサイズ、World Spaceの場合の描画密度を確認する。
3. 使用しているのが旧TextかTextMeshProUGUIかを確認する。TextMeshProの場合はFont Asset、アトラス、描画方式を確認する。
4. 同じ文字と配置を保ち、設定を一つずつ変えて比較する。対象の画面サイズでもう一度確認する。

GameビューとReference Resolutionを合わせる操作は切り分けの一つです。小さな端末に合わせた拡大縮小をなくす解決策ではありません。TextMeshProのSDFフォントも、アトラスや拡大率を問わず常に鮮明になるとは限りません。TextMeshProのFont Asset資料。フォントの設定と文字表示の関連情報はフォントの記事を確認してください。

3. アンカーとサイズ制御を分けて設定する

ボタンに合わせて子の文字領域を広げる

子のTextのアンカーを上下左右のStretchへ設定すると、親ボタンのサイズに合わせてRect Transformの領域を広げられます。Left／Right／Top／Bottomの余白と、Text側の中央揃えを別々に確認してください。Stretchだけで文字の中央揃えまで自動設定されるわけではありません。

文字の量に合わせて幅を変える

旧作例は右寄せの文字にContent Size Fitterを付け、文字の幅と子画像の位置を連動させた資料です。Horizontal FitをPreferred Sizeにし、幅が増える方向を決めるピボットと、子画像のアンカーを確認します。文字が増えた状態と減った状態を比べ、隣の要素に重ならないかを確認してください。

Layout Groupが子のサイズを制御しているところへ、同じ子のContent Size Fitterで同じサイズを制御させると競合する場合があります。誰が幅・高さを決めるかを整理し、親のLayout Group、子のLayout Element、Content Size Fitterを使い分けます。公式・内容に合わせたサイズ調整

親パネルに合わせて左右の部品を配置する

1. 親PanelのRect Transformを基準にする。左側の画像は左端、右側のボタンは右端へアンカーを置く。
2. 中央の線や背景は横方向をStretchにし、左右の余白を決める。
3. 親の横幅を変えて、左端・右端・中央がそれぞれ意図どおりに追従するか確認する。

アンカーは親のRect Transformに対する割合、ピボットは回転やサイズ変更の基準点です。値が変わると同じPos X／Pos Yでも配置の意味が変わります。Rect Transform・アンカーの資料

4. ImageのTiledで背景や枠を繰り返す

Image TypeのTiledは、画像を伸ばす代わりに繰り返して領域を埋める方式です。SpriteのBorderがある場合は枠と中央の扱いも確認します。旧作例の「3マス」「中心から1個半」という素材・Borderの指定は、その画像の例で、Tiled共通の必須条件ではありません。

1. 確認用の画像をSprite (2D and UI)として取り込む。
2. 枠を保持するデザインならSprite EditorでBorderを指定する。単純な背景を敷き詰める場合はその素材に合わせて判断する。
3. ImageのSource ImageへSpriteを指定し、Image TypeをTiledへ変更する。
4. Rect Transformの幅・高さを変えて、繰り返し部分、枠、端の見え方を確認する。

伸縮させたい場合はSliced、繰り返したい場合はTiledなど、見せ方で選びます。タイル数や生成されるメッシュは素材・Border・設定で変わるため、常に一定のポリゴン数として計算しません。Image Typeの公式資料

5. Canvas Scalerで画面比率を比較する

Scale With Screen Sizeは、Reference Resolutionを基準にUI全体を拡大縮小する方式です。以下の旧画面と端末比較は既存作例の記録です。特定の端末なら必ず見切れる、縦画面なら必ずMatch=0といった共通仕様にはしません。

1. Reference Resolutionへ設計時の基準サイズを入力する。1280×720等は設計例であり、全案件の推奨値ではない。
2. Screen Match ModeをMatch Width Or Heightにした場合、Match=0は幅、1は高さ、途中の値は両者を組み合わせた基準になる。
3. 基準と同じ比率、横に広い比率、縦に長い比率のGameビューを用意する。
4. 全体の大きさを確認した後、端のボタン、文字、中央の内容が見切れないかを確認する。

Matchの値は縦持ち・横持ちだけで固定せず、残したい領域とレイアウトから選びます。スケールはCanvas Scaler、個々の端からの距離はアンカーや余白で確認します。セーフエリアなど端末固有の条件は実機で別途確認してください。Canvas Scalerの公式資料

6. Rect Transformの基準を決めて座標を入力する

座標を入力する前に、親、アンカー、ピボットを決めます。たとえば左上を基準に部品を置く場合は、左上のアンカーとピボットを選び、その状態のPos X／Pos Yを入力します。Stretchの場合は位置・幅の代わりに左右の余白が表示されるなど、Inspectorの項目が変わります。

Anchor PresetsのShiftはピボットも変更し、Altは位置も変更する操作です。変更後にRect Transformの値と画面の位置を確認してください。親の基準を変えた後で、以前と同じ座標を入力しても同じ場所になるとは限りません。

次の画像は旧版のEdit → Snap Settingsや移動操作の資料です。現在のUnityではグリッドとスナップの設定UIが異なります。グリッドの刻みがそのままUIの画面上のピクセル数になるとも限らないため、UIの配置はまずRect Transformの数値で照合してください。Unity 6.3のスナップ資料

7. ポリゴン数・バッチ・SetPassを測る

描画負荷はUIの素材、文字数、Image Type、マスク、マテリアル、更新頻度、Editorと端末の条件で変わります。旧記事のポリゴン数・Batches・SetPass表は条件を追跡できないため、現在の固定値や性能保証として使いません。以下の画像は旧計測資料として残し、今回測定した結果と区別します。

同じ画面で変更前後を比較する

1. 使用Editor、uGUI、描画方式、解像度、対象機種を記録する。静止状態とUIを操作する状態を分ける。
2. Window → Analysis → Profilerを開き、UI (Canvas)／UI Details (Canvas)のLayout、Render、Vertices、Batches、Batch Breaking Reasonを確認する。
3. 影、輪郭、マスク、画像素材などを一つずつ変え、表示を同じ目的に保ったまま結果を比較する。
4. Editorでの解析と実機でのCPU/GPU・フレーム時間を別の結果として保存する。

uGUI 2.0の公式資料では、UI (Canvas)／UI Details (Canvas)モジュールはEditorのみで情報を収集し、Development Buildでは動作しないと説明されています。実機で同じモジュールが使えると想定せず、対象版で利用できるCPU/GPU解析などを確認してください。UI Profilerの公式資料

影・輪郭・マスクの判断

• Shadow／Outline：頂点を追加する描画効果。画像の形状や文字の量が変われば元の頂点数も変わる。一定のCPU時間の倍率として扱わない。
• Mask：ステンシルを使うマスク。形状が必要かを確認する。
• RectMask2D：長方形で、同一平面上のUIを対象とする制約がある。形状や配置が条件に合う場合に比較する。
• バッチ：同じアトラスやマテリアルだけで必ず1バッチになるとは限らない。描画順、クリッピング等で分割される理由を確認する。

MaskとRectMask2Dの条件を確認し、見た目と操作を保って比較します。「Maskを1個使えばSetPassが必ず2増える」「文字1つは画像1つと同じポリゴン数」といった固定式では判断しません。

調整後に確認する結果

• 基準解像度と別の画面比率で、文字と画像が見切れず配置を保つ。
• 文字量を変えても、サイズ制御が競合せず隣の部品に重ならない。
• ボタンが入力に反応し、装飾画像が操作を妨げない。
• 変更前後の設定と結果を保存する。旧画像と新しく実行した結果を混ぜない。

このページの新しいUnity実行・描画負荷測定は未実施です。最小の作例で設定を一つずつ比較する方法を示しています。Canvasの全体設定は専用記事、フォントの関連情報はフォントの記事へ分け、同じ内容の新規記事を増やしていません。

関連するUnityの記事