ドット絵UIの作り方｜サイズ・色数・5状態（default/hover/active/disabled/focus）

タイトル画面の32×16ボタンは、上に1pxのハイライト、下に1pxの影を入れた瞬間に、ただの長方形が「今すぐ押せる部品」に変わります。
16×16の虫眼鏡アイコンも、1pxアウトラインと中抜き1pxを整えるだけで、検索の記号として一気に読み取れるようになります。
この記事は、ドット絵でゲームUIを作りたい人、とくにAseprite（公式: 軸になるのは16×16、24×24、32×32の最小単位と、8〜24色の小さなパレット、そして UI の設計ルールとして default・hover・active・disabled に加えキーボード／ゲームパッド操作向けの focus を含めた5状態を基本に1px差分で組み立てる考え方です。
実装環境により hover が不要な場合は省略してよいですが、focus 相当の可視化は必ず設けてください。
ボタン・アイコン・パネルを9-sliceやタイル化前提で作っておくと、ゲーム画面に合わせて伸ばしても雰囲気が崩れず、UI全体の統一感も保てます。

ドット絵UI素材とは何か｜メニュー・ボタン・アイコンの役割を整理する

UI（User Interface）

UIは、ユーザーが見て、読んで、押して、状態を理解するための見た目全体です。
ゲーム画面では装飾の一部として語られがちですが、本質は演出ではありません。
どこを押せるのか、何が選ばれているのか、今は操作できるのかを一瞬で伝えるための設計です。
ドット絵UIでも優先順位は同じで、世界観より先に可読性と操作性を揃える必要があります。

この前提で整理すると、メニュー・ボタン・アイコンは役割がはっきり分かれます。
メニューは画面遷移やカテゴリ選択を担当する枠組みです。
たとえば「アイテム」「装備」「設定」のように、移動先や選択肢のまとまりを示します。
ボタンはその場でアクションを実行する部品で、「決定」「購入」「閉じる」のように、押した瞬間に結果が返るものです。
アイコンは機能や状態の記号化を担い、文字を読まなくても「検索」「戻る」「音量オフ」だと分かるようにします。
図にすると、メニューは導線、ボタンは実行、アイコンは記号という関係で捉えると迷いません。

ドット絵UIでこの差が曖昧になると、見た目は揃っていても操作の意味が伝わらなくなります。
メニュー項目をボタンのように立体的にしすぎると、一覧なのか即時実行なのかがぼやけます。
逆に、実行ボタンがただのラベルに見えると押せる部品として認識されません。
私は同じレイアウトで検証するとき、背景のタイル模様の上に文字だけ置いた版と、外周1pxのアウトラインを付けた版を並べて見ます。
すると後者は背景のドットと干渉せず、境界がきれいに分かれるので、同じ配置でも読める速度が一段上がります。
ドット絵ではこの1pxが装飾ではなく、情報を切り分ける線として効きます。

ボタン設計では、見た目を1枚作って終わりにしないことが肝心です。
最低でも default / hover / active / disabled / focus の5状態を前提に組み立てると、操作の意味が破綻しません。
defaultは基準状態で、何もしていないときの姿です。
ここで外周1pxの輪郭を入れ、上1pxにハイライト、下1pxに影を置くと、背景から分離しつつ「押せる面」に見えてきます。
hoverはマウスが乗った状態なので、明度を少し上げるか、輪郭を一段明るくして反応を返します。
activeは押下中で、内側の面やラベルを1px下げ、下影を減らして沈んだ感触を出します。
いわゆる1px沈み表現で、ピクセルUIと相性がいい定番です。

disabledは押せない状態です。
ここで彩度を落とす、コントラストを下げる、影を薄くする、といった処理を入れて「存在はしているが反応しない」ことを示します。
ただし消えたように見えるほど薄くすると、そこに機能がある事実まで失われます。
ラベルは読める、でも押下可能には見えない、その中間に置くのが正解です。
focusも見落とせません。
キーボード操作やゲームパッド操作では、今どこにフォーカスがあるかが操作そのものになります。
ドット絵なら外周1pxの明色枠、点滅する1pxライン、あるいは角だけ色を変える方法で十分伝わります。
hoverがない入力系でもfocusは必要です。

アイコンにも同じ考え方が流用できます。
defaultでは最小情報で形を見せ、focusや選択状態では外周1pxの強調や背景プレートの追加で状態を返します。
16x16や24x24のような小サイズでは、線を増やすより、輪郭と抜きの整理を優先したほうが認識率が落ちません。
通常テキストはコントラスト比4.5:1以上、大きい文字は3:1以上を基準にしておくと、ドット絵特有の少色数でも読み取りの土台を保てます。

操作性の面では、モバイル向けUIならタップ領域を44px以上に取る設計が欠かせません。
見た目のボタンが24px角でも、透明な余白や当たり判定を広げて44px以上を確保すれば、指で押したときの取りこぼしが減ります。
ドット絵UIは小さく作るほど魅力が出ますが、操作面積まで小さくしてしまうと世界観の勝ちで実用が負けます。
見た目の粒度と、実際に触る面積は分けて考えるべきです。

ドット絵UIが向くケース

ドット絵UIが力を発揮するのは、少ない色数で画面全体に統一感を出したいときです。
8〜16色のUIは管理するルールが明快で、ボタン、パネル、カーソル、アイコンを同じパレットで増やしても雰囲気が散りません。
色数を絞ると状態差が不足しやすい反面、1pxの輪郭、明暗差、押下時の沈み表現といった構造の差がそのまま効いてきます。
装飾で押し切るのではなく、限られた手数で情報を通す設計と相性がいい形式です。

レトロゲーム風やインディーゲームらしい世界観とも噛み合います。
古いゲーム機由来の少色数やグリッド感は、単なる懐古趣味ではなく、UI全体を同じ密度で見せるための規律として働きます。
キャラクター、背景、フォント、UIのすべてが同じピクセル感で揃うと、画面の中でUIだけが浮きません。
Asepriteのようなツールで小さなキャンバスから組み立てると、この一体感を保ったままボタンやメニューを量産できます。

もうひとつ向いているのが、2x、3x、4xの拡大表示を前提にする画面です。
ドット絵は高精細ディスプレイ上で等倍表示すると粒立ちが埋もれやすいため、拡大して輪郭を見せる前提で設計したほうがピクセルの気持ちよさが出ます。
32×32のボタンを3xで扱えば見た目は96×96相当になり、1pxのハイライトや影も視認できる密度になります。
拡大表示を前提にしておくと、1px差分で作ったhoverやactiveの変化も埋もれません。

このとき効いてくるのが、やはり1px単位の設計です。
外周1pxの輪郭は、背景から要素を分離するための最小コストの線です。
上1pxのハイライトと下1pxの影は、少色数のまま立体感を作る最短距離です。
押下時に面を1px沈めると、アニメーションを入れなくても触感が伝わります。
私はタイル背景の上にボタンを置く場面で、アウトラインを省いた版も何度か試しましたが、背景の模様とボタンの端が溶け合って、ラベルの周囲だけが落ち着かなくなりました。
外周1pxを入れた瞬間に部品として独立し、画面のノイズが減った感覚があります。
ドット絵UIでは、この小さな差が読みやすさと押し間違いの少なさに直結します。

反対に、写真調のUIやグラデーション主体のリッチな質感、極小表示のまま高密度な情報を詰め込む画面では、ドット絵の利点が薄れます。
ドット絵UIは、限られた色と形で意味を伝えることに強い形式です。
メニュー、ボタン、アイコンの役割を分けたうえで、状態変化を1px単位で設計すると、見た目の可愛さだけでなく、触って迷わないUIに仕上がります。

最初に決める設計ルール｜グリッド・基本サイズ・色数

制作に入る前に決めておきたいのは、描き方のテクニックより先に、どの単位で部品を増やしていくかという設計ルールです。
ピクセルUIは1個だけ作ると整って見えても、ボタン、アイコン、ラベル付きボタン、パネル見出しと横展開した瞬間に、サイズ感や余白の基準が揃っていない粗さが露出します。
先にグリッド、基本サイズ、色数を固定しておくと、後から追加した素材も同じ文法で接続できます。

最小単位を先に固定する

基準サイズは、まず16×16、24×24、32×32の3段階で整理すると運用が安定します。
16×16は検索、設定、戻るのような単機能アイコン向きです。
情報量を絞り、輪郭で読ませる部品に向きます。
24×24は最も汎用性が高く、現代的なUI密度とも接続しやすいサイズです。
線の太さ、抜き、内側の記号を無理なく収められるので、メニュー用の一般アイコンはここを軸にすると破綻が少なくなります。
32×32は装飾つきアイコン、小さなラベルを添えるボタン、RPG風の意匠を入れたい部品に向きます。
陰影やプレート感を乗せる余地があり、世界観の演出にも使えます。

私自身、途中までは16と32が混在したまま作っていた時期がありますが、汎用アイコンを24×24に統一してから一覧の見え方が一気に整いました。
さらに4pxグリッドで並べると、アセットシート上でどこが不足していて、どの部品だけ密度が浮いているかがすぐ分かります。
制作中の判断が視覚的にそろうので、量産フェーズの迷いが減ります。

グリッドと余白は4px倍数で揃える

UI素材は、キャンバス内の描画ルールと、素材同士を並べる間隔ルールを分けて決めると崩れません。
基本は外周1pxアウトライン、その内側に最小2pxのパディングを確保する形です。
輪郭のすぐ内側まで情報を詰め込むと、等倍では読めても実装後の縮小や背景干渉で潰れます。
外周1pxで境界を確定し、その内側に呼吸する余白を残すと、文字や記号の輪郭が落ち着きます。

要素同士の間隔は4px倍数で揃えるのが扱いやすく、4px、8px、12pxを基本単位にすると配置判断が速くなります。
アイコンとラベルの間、ボタン同士の間、パネル内の上下余白が同じ倍数でそろっているだけで、画面全体に規則が生まれます。
さらに4×4のサブグリッドを用意しておくと、量産時のブレが目に見えて減ります。
とくに同じ24×24アイコン群でも、モチーフの中心位置や余白の偏りが揃い、セットものとしての完成度が上がります。

24×24アイコンなら、具体的には外周を1pxで囲い、その内側に等幅1pxの線でモチーフを組みます。
たとえば歯車や封筒のような記号でも、まずは外枠と主要線だけで成立させ、細部は後から足す考え方のほうがまとまります。
曲線はドット絵らしく45°の階段を維持し、中間色のアンチエイリアスは必要最小限に留めます。
小さなUIでAAを増やすと、輪郭が柔らかくなる代わりに記号性が落ち、読ませたい形より灰色のにじみが前に出ます。

表示は等倍ではなく拡大前提で確認する

いまの高精細ディスプレイでは、画素の識別限界に近い密度まで細かく表示されるため、ドット絵を等倍で見ると意図した1px差分が埋もれます。
ピクセルUIは2xまたは3xでの拡大表示を前提にプレビューする運用が合っています。
制作中に等倍だけ見ていると、線を足しすぎたり、逆に必要な差分を削ってしまったりしがちです。
拡大前提で見ると、1pxのハイライト、アウトライン、押下時の沈み表現が意図通りに伝わるかを判断できます。

Asepriteのように2x、3xで書き出しや確認ができる環境では、アイコン単体ではなく、実際のボタン列やメニュー行に載せた状態で倍率確認すると差が分かります。
単品では読めた24×24アイコンが、ラベルや背景パターンと組み合わさった瞬間に埋もれることは珍しくありません。
拡大前提の表示を先に決めておくと、制作時点で「どの1pxが効いているか」を判断できます。

色数は小さなパレットから始める

色は最初から増やしすぎないほうが管理できます。
出発点は8〜24色程度の小パレットで十分です。
少色数にすると、部品ごとの差分を色相の派手さではなく、明度差、面の切り替え、1pxの輪郭で作る発想になります。
その結果、UI全体の統一感が保ちやすくなります。
装飾を厚くしたい場合でも、いきなり多色に行かず、まずは小パレットで成立させてから必要箇所だけ拡張したほうが破綻しません。

運用面では、色を役割でトークン化しておくと後から強いです。
たとえば bg / base / border / text / accent / state-hover / state-active / state-disabled のように名前を与えておけば、色を差し替えても部品全体の関係は崩れません。
プロジェクトが大きくなって状態差や属性色が増えた段階で、32〜64色へ拡張すると整理しやすくなります。
先に役割名があると、青を何色使ったかではなく、その青が何のために存在するかで管理できます。

小さいUIでは、1コンポーネントに明るいアクセント色をひとつ置く構成が効きます。
ベース、輪郭、文字、状態差の色が整理されていれば、アクセントは「押せる」「選択中」「注目してほしい」を示すための一点に使えます。
反対に、狭い面積へ複数の強い色を並べると、ボタンなのか装飾なのかがぼやけます。

文字は背景から切り離して読む

ラベル付きUIでは、文字の可読性をドット絵の雰囲気より優先して設計します。
通常テキストは背景とのコントラスト比4.5:1以上、大きい文字は3:1以上を基準にすると、少色数でも読み取りの土台が保てます。
ドットフォントや自作ピクセル文字は、形が見えていてもコントラスト不足で読みにくくなることが多いので、色数を増やす前に背景との明暗関係を見直すほうが効きます。

そのうえで、背景がタイル模様だったり、パネルの中に複数の色面があったりする場合は、文字の周囲に1pxアウトラインか1px相当の影を入れると読ませる力が安定します。
これは装飾というより、文字と背景を切り分けるための層です。
とくに32×32のラベル併用ボタンでは、面の明暗だけで文字を支えようとすると、hoverやactiveで背景色が変わった瞬間に読み味が落ちます。
文字用の輪郭を独立させておくと、状態変化の中でも可読性が残ります。

この段階でルールを固めておくと、後からボタンを増やしても、アイコンを差し替えても、見た目の密度と読み取りの基準が揺れません。
ピクセルUIは描き込み量より、最初に決めた単位をどれだけ守れるかで完成度が決まります。

サイズとスタイルの選び分け

サイズ選びは、UI全体の密度と役割分担を決める作業です。
16×16、24×24、32×32はどれも定番ですが、同じモチーフを入れても読まれ方が変わります。
最初に「この画面で何を最優先に伝えるか」を決めておくと、後から線を足したり削ったりする回数が減ります。

16×16は、検索、戻る、設定のように意味がすでに共有されている単機能アイコンと相性が良いです。
入れられる情報量が少ないぶん、形の記号性が前に出ます。
反面、斜線や穴あきの表現が増えるとすぐ潰れるので、説明的なモチーフには向きません。
ひと目で分かる記号だけを置く、という割り切りが必要です。

24×24は、可読性と省スペースの折り合いが取りやすいサイズです。
メニュー用の一般アイコンを一式そろえるなら、このサイズを基準にすると管理が安定します。
16×16より余白を設計しやすく、32×32ほど面積を食わないので、一覧画面でも扱いやすいのが利点です。
中途半端に見える場面があるのは事実ですが、それはサイズ自体の問題というより、情報量の置き方が曖昧なケースが多いです。
輪郭、主線、アクセントの役割を分ければ、24×24はもっとも汎用性の高い土台になります。

32×32は、陰影、内側の段差、装飾フレームまで入れたいときに強いです。
小ボタンでも「ただ押せる」だけでなく、材質感や世界観を持たせられます。
RPG風UIや選択ボタンではこの差が効きます。
ただし面積が増えるぶん、状態差の管理も重くなります。
通常、ホバー、押下の3状態を並べたときに、全部が別物に見えるほど描き込むと運用が苦しくなるので、差分の位置を固定しておく発想が欠かせません。

スタイルの軸もサイズと一緒に決めておくと、量産が止まりません。
フラット寄りUIは、面を少ない色で分けて輪郭を明快にできるので、視認性と量産性の両方を取りにいけます。
小さなアイコン群を大量に並べる画面では、この整理された見え方が強いです。
その代わり、画面全体の物語性や豪華さは出にくく、ゲームジャンルによっては少し無機質に映ります。

一方で装飾寄りのUIは、金属、木、石、魔法陣のような材質や世界観を直接載せられます。
タイトル画面や装備画面のように、UI自体が作品の雰囲気を支える場面では魅力が出ます。
ただ、装飾が前に出るほど文字と操作面の優先順位が下がりやすいのが利点です。
以前、RPG調の装飾ボタンを組んだとき、額縁風のフレームと模様がきれいに見えているのに、ラベルだけ妙に埋もれたことがありました。
そのときは文字の周囲に1pxの内枠を追加して、背景の装飾層と文字層を分離したところ、雰囲気を崩さずに読みやすさが戻りました。
装飾を足すほど、文字には別の居場所を与える必要があります。

既存の素材パックを使う判断も、制作速度の面では現実的です。
たとえばOpenGameArtには750 assets規模のピクセルUIパックがあり、9-slice前提の部品も見つかりますし、Unity Asset Storeにも151 iconsを含むUIキットがあります。
ゼロから全部描くより、土台を既製素材でそろえて必要部分だけ描き替えるほうが、試作の立ち上がりは速くなります。
もっとも、ここで見るべきは量より統一感です。
角の丸め方、アウトラインの太さ、陰影の向き、色の温度感が合っていないパックを混ぜると、画面全体が寄せ集めに見えます。
加えて、配布元ごとに利用条件が違うので、ライセンスの扱いも制作の一部として整理しておく必要があります。

Before/After想定

同じ検索アイコンでも、16×16、24×24、32×32では設計の答えが変わります。
16×16では虫眼鏡の円と持ち手だけで成立させるのが基本です。
円の内側にハイライトや厚みを入れる余地はほぼないので、記号として読めることを最優先にします。
24×24になると、円の輪郭を安定させながら持ち手との接続も整えやすくなり、検索アイコンとしてもっとも扱いやすい形になります。
メニュー列に並べても面積が膨らみすぎず、単独でも読めるので、汎用サイズと言われる理由がここにあります。

32×32では、同じ虫眼鏡に世界観の層を足せます。
たとえば外周の余白を24×24版より2px広く取り、モチーフを中央で呼吸させると、装飾枠や背景テクスチャとぶつかりません。
そのうえでレンズ内側に1pxの内影を入れると、単なる記号だった検索アイコンに厚みが生まれます。
読みやすさを落とさず、RPG風やアドベンチャー風の画面にも馴染ませやすくなります。
ここで効くのは描き込み量そのものではなく、余白と陰影の置き方です。
32×32は「大きいから細部を増やす」のではなく、「余白を設計できるから雰囲気を乗せられる」と考えたほうがまとまります。

この比較を見ると、16×16は単機能、24×24は汎用、32×32は装飾つきアイコンや小ボタン向け、という住み分けがはっきりします。
同じ検索アイコンを無理に全サイズ同じ密度で描くより、サイズごとに削る部分と足す部分を変えたほうが、セット全体の完成度は上がります。

ドット絵ボタンの作り方｜5状態（default/hover/active/disabled/focus）を基本に1px差分で設計する

ボタンは単体の絵ではなく、状態の差分まで含めて1セットで設計すると破綻しません。
ドット絵UIでありがちなのは、通常状態だけ気持ちよく描けていて、ホバーや押下になった途端に別の部品のように見えてしまうことです。
これを防ぐには、最初に default、hover、active、disabled、focus の5状態をUI全体で共通定義して、どのボタンでも同じ変化ルールを守ることです。
サイズが違っても反応の文法が同じなら、画面全体の操作感が揃います。

対象サイズは、小さな無地ボタンなら本体32×16、テキスト付きなら48×16や64×20を起点にすると組み立てやすくなります。
内側余白は左右4px、上下3pxを基準にすると、ラベルや小さなアイコンを押し込まずに置けます。
小ボタンでも文字の居場所を先に確保しておくと、後から枠や陰影を足しても窮屈になりません。
とくに48×16と64×20は、短いラベルを置いたときに上下の圧迫感が出にくく、1px単位の陰影差も読み取りやすい幅です。

defaultは立体の基準面を固定する

通常状態では、外周1pxの濃色ボーダーで輪郭を確定し、その内側に上面1pxハイライト、下面1px影、中央面をベース色で埋めるのが基本です。
たとえば面を #4A7AB7、ハイライトを #6FA6E0、影を #2F5C8F、枠を #1E3F66 にすると、少ない色数でも押せる部品として成立します。
上が光を受け、下に重さがあるという読みが1pxずつで伝わるので、単なる青い長方形ではなく、指やカーソルが触れる対象に見えてきます。

ここで大事なのは、ハイライトと影を装飾として扱わないことです。
上1pxと下1pxは、見た目の味付けではなく、以後の hover や active の差分を受け止める土台です。
最初の面構成が曖昧だと、ホバー時に明るくしたいのか、押下時に沈ませたいのかが判別しにくくなります。
ドット絵のボタンは面積が小さいぶん、1列の色の意味を固定したほうが強いです。

hoverは「触れられる」を1pxで出す

hover では、面全体を別色に描き替えるより、明度を少し上げるか、外周に1pxの明色縁取りを足すほうが安定します。
変化量の目安は明度で5〜10%ほどに留め、内容物であるラベルやアイコンは据え置きにします。
文字まで一緒に明るくすると、ボタンの反応なのか文字の見え方の変化なのかが混ざってしまいます。
枠のコントラストだけをわずかに強めると、操作可能な対象としての輪郭が前に出ます。

自分の制作でも、hover はつい面を派手に変えたくなるのですが、実際に触って気持ちよく感じるのは外周1pxの明色縁取りを足したときでした。
ほんの1pxなのに、静止していた部品が「いま触れます」と前に出てきます。
ドット絵UIではこの差が大きくて、面の塗り替えよりも反応の意図が伝わりやすいのが利点です。
PCではこの hover が素直に効きますが、モバイルにはポインタ常駐の概念がないので、同じ見せ方を前提にはしません。
共通定義として hover を持ちつつ、モバイル側では押下反応と focus、選択状態の見え方で補うのが自然です。

activeは1px沈めて押下感を作る

押下状態は、色を変えるだけでは弱く、位置を1px動かすと一気に手応えが出ます。
active では面とラベルをまとめて1px下へシフトし、上のハイライトを消して、下影を半分ほどに抑えます。
さらに枠の上辺を影色で暗くすると、押し込まれた面として読めます。
見た目のロジックとしては、上面の光が消え、下の落ち影が縮み、内容物そのものが沈む、という順番です。

1px単位で具体化すると、押下時は内側の全ドットを下方向へ1px移動させます。
そのとき上辺のハイライト列を削除し、下辺の影列は1px短縮します。
こうすると、ボタンの厚みが上から圧縮されたように見えます。
ラベルまで一緒に沈めるのがポイントで、面だけ下げて文字がそのままだと、押した感触ではなく背景だけずれた印象になります。

この1px沈みは、見た目以上に効きます。
自分でも何度も試しましたが、active で1px下げた瞬間に、ただ色が変わっただけのボタンとは反応の説得力がまるで違います。
ドット絵は情報量が少ないので、触覚の代わりを位置変化が担います。
たった1ドットでも、押したという実感が出ます。

disabledは消すのではなく、使えないと分かる形にする

無効状態は、存在感を丸ごと消すのではなく、部品としては見えるが操作対象ではないところに落とします。
基本は彩度を50%落とし、明度を10〜15%上げてグレー寄りに寄せ、枠コントラストも下げます。
これで通常状態との距離が出ます。
面、枠、ハイライト、影の全部を同じ灰色に潰すと、ボタンなのか背景の飾りなのか判別が付きにくくなるので、階調差は残します。

テキストや記号は読みを捨てないことも欠かせません。
無効だからといって文字のコントラストを落としすぎると、何が置かれているのかさえ分からなくなります。
通常の文字は4.5:1以上が基準になりますが、disabled では少なくとも3:1を割らない位置に留めておくと、使えないことを示しながらラベルの判読は保てます。
無効状態は「押せない」ことの表示であって、「読ませない」ことではありません。

focusはキーボード操作の現在地を見失わせない

focus は hover の代用品ではなく、キーボード操作の現在地を示す独立した状態です。
外周に1pxの点線、またはハイライト色の内枠を追加して、色だけに依存しない差分を作ります。
ドット絵UIでは装飾が多いほど focus が埋もれやすいので、面色変更だけで済ませると見落とされます。
1pxの点線や内枠なら、小さなボタンでも「いまここにフォーカスがある」と伝わります。

focus を hover と同じ見た目にすると、マウス操作とキーボード操作の意味が混ざります。
hover は近づいた反応、focus は選ばれている反応です。
この違いを分けておくと、ゲームパッドやキーボードでUIを回したときにも位置関係が崩れません。
ドット絵UIは見た目の統一感を優先したくなりますが、状態の意味を重ねすぎると操作感のほうが壊れます。

PCとモバイルは同じ状態名で、見せ方だけ変える

状態定義そのものはPCとモバイルで共通にしておくと、設計と実装の往復が楽になります。
違ってくるのは見せ方です。
PCでは hover が入口になり、focus はキーボードやゲームパッド操作の補助として働きます。
モバイルでは hover を前提にせず、default と active、disabled、focus 相当の選択表示を軸に組みます。
視覚差の設計ルールが同じなら、入力手段が違ってもUIの人格がぶれません。

モバイルでは、見た目の本体サイズが32×16や48×16でも、実際のタップ領域は44px以上を確保します。
これはボタン自体を巨大化するという意味ではなく、周囲にインビジブルパディングを持たせて当たり判定を広げる方法でも成立します。
ドット絵の見た目を守りながら誤タップを減らせるので、小さなUIほどこの発想が効きます。
押下時の1px沈みもモバイルでは有効で、そこに音やバイブを重ねると、視覚だけに頼らない反応になります。
ピクセル単位の変化は小さいですが、触覚や聴覚が加わると押したことがはっきり残ります。

ドット絵アイコンの作り方｜16x16で意味が伝わる記号化のコツ

アイコンは、ボタン以上に記号化の精度が問われます。
とくに最小キャンバスを16x16に置く場合、描き込みを増やすほど伝わるわけではありません。
まず必要なのは、ひと目で読める外形です。
単機能の検索、設定、戻る、削除のような用途なら16x16を基本にし、意味が多義的で内側の情報まで必要なときだけ24x24へ広げます。
小さい面積で成立させる発想を先に持つと、UI全体に並べたときも密度が揃います。

外周は1pxのアウトラインで囲い、背景から分離します。
ここで黒100%の枠を固定で使うと、明るいUIでは締まって見えても、暗いUIでは輪郭だけが浮きすぎてモチーフ本体より先に枠が目に入ります。
実務では、面や背景との関係を見ながら、黒の代わりに1段階だけ明るい枠色へ落とすことがよくあります。
輪郭の役目は境界を伝えることであって、枠そのものを主役にすることではありません。

シルエットを先に決める

16x16で意味を伝えるときは、内部ディテールよりシルエットを優先します。
最初に45°と90°のストロークだけで主形状を決めると、拡大して見ても縮小して見ても形の芯が残ります。
検索アイコンなら円と柄、ゴミ箱なら胴体とふた、戻るなら矢印の向き、といった一番先に読ませたい形を先に置きます。
細かなギザギザや陰影は、その後で足しても遅くありません。

内側の意味づけには、中抜きの1pxが効きます。
これは単なる装飾ではなく、空隙を作って「何の記号か」を確定させる手段です。
歯車のアイコンを16x16で作っていたとき、外周の突起だけでまとめると、ぱっと見では花びらのある花に引っ張られました。
そこで中心に1pxの中抜きを入れ、さらにその周囲の空きが読めるように内側の抜けを整えたら、同じ大きさのまま一気に機械部品の顔になります。
外周だけでは装飾的な丸い形だったものが、内側の空洞を持った瞬間に「回る部品」として読まれるようになる。
この変化は、16x16ではとくに大きいです。

アウトラインと塗りをどう配分するか

小さなアイコンは、線だけで組むか、塗りを主体にするかで印象が変わります。
どちらか一方に寄せすぎると、意味がぼやけます。
外周1pxで形を固定し、主形状の面は塗りで押さえ、内側の意味づけだけを中抜きで見せると、輪郭と内容が分離されて読みやすくなります。
逆に、内側まで全部線で説明しようとすると、16x16では線同士が競合してノイズになります。

虫眼鏡はこの配分が分かりやすいモチーフです。
円形の外周を太さ1pxで描き、柄は幅2px、長さ4pxで付けます。
円と柄をぴったり直交でつなぐより、接合部に1pxの斜めピクセルを1つ入れたほうが、円から柄へ視線が滑らかにつながります。
この1pxがないと、拡大時には接合が硬く見え、等倍では円と棒が別物に割れて見えます。
16x16では、こういう1ドット単位の橋渡しが形の安定感を支えます。

既存メタファーを借りて学習コストを下げる

アイコンは独創性より、既存メタファーの共有を優先したほうが機能します。
検索は虫眼鏡、設定は歯車、削除はゴミ箱、戻るは矢印という形がすでに頭の中に入っているので、読む側に新しい辞書を渡さずに済みます。
ドット絵にするとレトロな味は出ますが、意味まで独自化すると操作の手が止まります。
UIのアイコンは作品ロゴではなく、まず操作記号です。

その一方で、複雑な概念を16x16だけで完結させるのには限界があります。
共有、並べ替え、アーカイブ、フィルターのように近い意味が並ぶ機能は、どれだけ丁寧に記号化しても混線しやすい場面があります。
そういう多義的な機能は、アイコン単体で勝負せず、ラベル併用を前提にしたほうがUI全体の理解速度が落ちません。
小さなピクトグラムは入口として働き、確定の意味は文字で渡す。
この役割分担のほうが、あとで機能が増えたときも整理しやすくなります。

等倍だけで判断しない

制作中は拡大表示で描く時間が長くなりますが、可読性の判定は100%、200%、400%を往復して行います。
400%では形の乱れ、200%では線のつながり、100%では実際の意味の通り方を見る、という順番で確認すると、修正の場所が切り分けやすくなります。
背景の明暗が変わったときに輪郭が埋もれないかも同時に見ます。
アイコンやラベルのコントラストは4.5:1を下回らない位置に置き、足りないときは色数を増やす前に輪郭と中抜きの設計を見直します。
小サイズでは、色の追加より形の整理のほうが効く場面が多いからです。

Asepriteで作るときも、拡大したまま描き込み続けるより、等倍プレビューを横に置いて1pxごとの差を確認したほうが判断がぶれません。
16x16のアイコンは、描いている感覚より、縮小された結果のほうが本体です。
見えているつもりの情報が等倍で消えていれば、そのドットは存在していないのと同じです。
次の工程でスプライトシートに並べたときも、記号の芯が揃っているアイコンは一列に並んだ瞬間に強いです。

メニュー・ウィンドウ・パネルの作り方｜タイル化と9-sliceを前提にする

可変サイズのメニューやダイアログを作るとき、毎回横幅違いの画像を描き分ける運用はすぐに破綻します。
ここで軸になるのが、角・辺・中央を分けて考える設計です。
1枚の枠画像を3×3に分割し、四隅の角は固定、上下左右の辺と中央は伸縮または繰り返しで広げる。
この考え方が9-slice（ナインスライス）です。
ゲームエンジン側では、たとえば Unity（公式ドキュメント: Border を設定し、Draw Mode を Sliced/Tiled にするだけで扱えます。

角・辺・中央を先に部品化する

私がよく組むのは、角ピース、辺ピース、中央ピースの3種類です。
実務では角はプロジェクトに依存しますが、例としては6〜8px程度で設計されることが多く、辺は幅可変の8xN、中央は繰り返し可能な8x8タイルとする運用が扱いやすいのが利点です。
そこから全体サイズを16px単位で増やしていくと、ラベル量が増えたときも寸法のルールが崩れません。

この分割を入れておくと、角丸や装飾角の扱いが安定します。
以前はパネル幅ごとに別画像を描いていたのですが、少し横長にしただけで角の階段が潰れたり、丸みのリズムが片側だけ崩れたりしていました。
9-slice に切り替えてからは、幅を任意に変えても角の形が固定されたまま残るので、角丸のギザりが出ません。
見た目の安定だけでなく、修正のたびに左右の端を描き直さなくて済むので、UI全体の量産速度も目に見えて変わります。

繰り返しタイルは中央8x8で作る

中央は「空白」で済ませず、繰り返しタイルとして成立させておくと強いです。
たとえば8x8の中央面に、明暗の粒や布目、石目、メタル調のノイズを最小限で組み、横にも縦にも継ぎ目なく並ぶようにしておきます。
この1枚ができると、細いステータス枠から横長の会話ウィンドウまで同じ素材で展開できます。
中央だけ別色で量産するのも簡単で、枠はそのまま、面のタイルだけ差し替えれば同系統の別UIがすぐに増やせます。

体感としても、この中央8x8タイルがあるだけで制作の回転が上がります。
ボタン、通知パネル、所持品欄、設定ウィンドウと、用途が違っても中身の面積部分は同じロジックで埋められるからです。
1回きれいに繋がるタイルを作ってしまえば、あとは「どこまで広げるか」を決める作業に近づきます。
装飾を毎回描き足すより、情報を載せる容器としての質が揃います。

1px縁取りと内側余白で箱の強度を出す

パネルは面積が大きいぶん、輪郭設計が甘いとただの色付き長方形に見えます。
基本形として安定するのは、外周1pxの濃色枠を置き、その内側に1pxの明色インナーラインを入れ、さらに内容物との間に4pxのパディングを取る構成です。
外枠で背景から切り離し、内側の明線で面の厚みを感じさせ、4pxの余白でテキストやアイコンを呼吸させます。
パディングがないと、文字が枠に触れて見え、せっかくの箱が窮屈な印象に変わります。

この1pxと4pxの組み合わせは、単なる装飾ではなく情報整理の仕組みでもあります。
外周の1pxは境界、内側の1pxは材質や段差、4pxの余白は内容領域の宣言です。
役割が分かれているので、後からタイトル帯やアイコン列を足しても、どこまでがフレームでどこからが中身かが濁りません。
ドット絵UIは1pxの差がそのまま機能差になるので、枠と余白は同時に設計したほうが崩れません。

1px単位で辺のリズムを揃える

9-slice素材は、分割した瞬間に継ぎ目の粗が露出します。
とくに辺パーツは、1タイルごとの影とハイライトの位置がずれると、横に伸ばしたときに縞が途切れて見えます。
実務では、角8x8の内側に1pxの45°ハイライトを置き、そこから辺タイルへ自然につながるように組むと収まりがいいです。
角で斜めに受けた光が、上辺の1pxハイライトへ、側面の影へ連続していく流れを作るわけです。

辺タイル側では、1pxごとの影とハイライトの縞を一定のリズムで並べます。
上辺なら明、面、影の順、下辺なら影を少し強める、といった規則を先に決め、その並びを1タイルぶんで完結させます。
ここが曖昧だと、横幅を伸ばしたとたんに「最初の8pxだけ立体で、残りは平面」に見えてしまいます。
9-sliceは拡張の技術ですが、実際には繰り返されたときに何が見えるかを先に設計する技術でもあります。

情報階層は枠のコントラストで整理する

ウィンドウ、パネル、ボタン、テキストが全部同じ強さで主張すると、UI全体が騒がしくなります。
そこで、ウィンドウ > パネル > ボタン > テキストの順にコントラストを弱め、上位コンテナほど枠の存在感を強くします。
最上位のウィンドウは外枠とインナーラインをはっきり見せ、その内側のサブパネルは一段おとなしい枠にする。
ボタンはさらに軽く、テキストは内容として読ませる位置に置く。
こうすると、視線が箱から箱へ迷わず降りていきます。

情報階層を色数だけで処理しようとすると、配色が増えたわりに読み順が整いません。
枠の太さは同じでも、濃淡差を一段ずつ落としていくだけで、どれが土台でどれが操作部品かが見えてきます。
大きなウィンドウほどコントラストを持ち、小さな部品ほど背景に溶けすぎない範囲で主張を抑える。
この序列があると、ラベルや数値が乗ったときに内容が前へ出ます。

OpenGameArtの9-slice系UI素材を見ると、角と辺の役割分担、中央タイルの反復、外枠と内側の明線の入れ方がよく整理されています。
こうした実例に共通するのは、拡大縮小のための画像ではなく、分割される前提の画像として描かれていることです。
Asepriteで作るときも、1枚の完成絵として詰めるより、スプライトシートに並べたあとやゲームエンジンでスケーリングしたあとに崩れないピクセル配置を意識したほうが、UIパネルは安定して量産できます。

色数制限を活かす表現｜ディザリング・コントラスト・アクセシビリティ

色数制限は制約というより、UIの役割を強制的に整理してくれる設計ルールです。
ここを曖昧にしたまま素材を増やすと、ボタンごとに色の意味がずれ、あとから hover や disabled を足した段階で統一感が崩れます。
先に決めておきたいのは、どのサイズに何を載せるか、何色で状態差を作るか、拡大表示されたときにも文字と記号が読めるかの3点です。

サイズごとに情報量の上限を決める

16x16、24x24、32x32は、単なる拡大縮小の関係ではありません。
16x16は検索、戻る、設定のような単機能アイコン向けで、形の芯だけを残す領域です。
24x24は汎用アイコンの基準にしやすく、記号性と判読性の釣り合いが取りやすいサイズです。
32x32になると、選択ボタンや装飾つきアイコンに陰影や段差を足せるので、RPG風UIのような世界観まで含めて見せられます。

この3サイズを混在させる場合は、用途の境界を先に固定したほうが後工程で迷いません。
16x16に装飾を持ち込むと潰れ、32x32を単純記号だけで埋めると面積を持て余します。
私は通知バッジや選択中マーカーを小さく見せたい場面では、ベースのアイコンを16x16か24x24に抑え、強調が必要なボタンだけ32x32へ上げる構成をよく使います。
サイズ差そのものが情報の強弱になるので、色だけで無理に序列を作らずに済みます。

8〜24色の小パレットで状態を回す

少色数UIは、8〜24色程度の小パレットに収めると運用が安定します。
内訳の基本は、ベース3〜5色に、影2段階、ハイライト2段階、アクセント1色、さらに success / warn / error / info の状態色を各1色です。
この配分にしておくと、通常状態から操作状態、通知、警告まで同じ設計思想で横展開できます。
色を増やす前に役割を決めるほうが、量産時の破綻が出ません。

特に効くのが、アクセント色を1つに絞る運用です。
選択中、通知バッジ、新着マーク、フォーカスの縁取りまで全部別色にすると、小サイズでは主張がぶつかります。
逆にアクセントを1色に限定すると、その色が現れた瞬間に「今ここを見てほしい」が通ります。
実務でも、24x24以下のUIではこの差がはっきり出ます。
通知バッジや選択状態が背景の装飾に埋もれず、1ドット単位の小さな差でも意味を持ちます。

ディザリングは質感用、判読性を壊さない範囲に留める

ディザリング（疑似中間調）は、少色数のドット絵では便利ですが、UIでは使いどころが限られます。
原則として、使うのは隣接する2色の間だけです。
明るい面と暗い影の間に離れた色を混ぜると、立体感よりノイズが先に見えます。
ボタン面の材質感や、パネル中央のごく薄い粒立ちなら効果がありますが、文字の周辺やアイコン輪郭にまで広げると、読むための境界が崩れます。

とくにUIでは、ディザリングは装飾ではなく中間調を疑似的に置くための補助手段として扱うのが安全です。
ベタ面で十分に読めるなら、そのままのほうが強いです。
私は金属調の32x32ボタンを作るときにだけ、面の中央から影へ落ちる帯に最小限のディザを入れますが、ラベルの周囲1pxには持ち込みません。
そこは読ませる場所であって、質感を見せる場所ではないからです。

余白とグリッドで、少色でも窮屈に見せない

色数を絞るほど、余白とグリッドの設計が画面の印象を左右します。
同じ8〜16色でも、要素同士が詰まっていると情報量が多く見え、パレットが足りないように感じます。
逆にグリッド上で位置を揃え、アイコン、文字、枠のあいだに一定の空きを作ると、少ない色でも整理された画面になります。

ここで効くのは、1px単位の線だけではなく、何も置かない領域を部品として扱うことです。
16x16アイコンでは外周ぎりぎりまで描かず、1pxでも呼吸できる余白を残す。
24x24や32x32の小ボタンでも、ラベルと枠が接触しないだけで視認の負荷が下がります。
色数制限を活かすというのは、色を詰め込むことではなく、グリッドの上で役割ごとに面積を配分することでもあります。

状態差は明度で管理し、押下感は陰影で作る

default、hover、active、disabledの差は、別デザインとして描き分けるより、明度と陰影のルールを揃えたほうが長持ちします。
defaultを基準にして、hoverでは明度を5〜10%上げるか、外周の縁を1段明るくする。
activeでは陰影を反転させるか、面とラベルを1px沈めて押下感を出す。
disabledではコントラストを落とし、彩度も抑えて、部品としては見えるが操作対象ではない位置まで引きます。

この設計だと、色数を増やさなくても状態差が作れます。
小パレットでありがちなのは、hover 用に新色、active 用にまた新色を足して、結果として状態ごとの色の意味がばらけることです。
明度差と陰影の方向を固定しておけば、ベース色が変わっても同じ文法で量産できます。
success や error の状態色を載せるときも、色相差だけに頼らず、hover や active の明暗ルールをそのまま適用できます。

文字は色だけで読ませず、1pxで支える

ドット絵UIでいちばん破綻しやすいのは、装飾より文字の可読性です。
通常テキストはコントラスト比4.5:1以上、大きい文字は3:1以上を基準に置きます。
ここで言う大きい文字は見出しや数値表示で、ボタンラベルや小見出しの多くは通常テキストとして扱う前提で見たほうが安全です。
色差が足りない場面では、色を変える前に輪郭、パターン、位置差のどれで補強するかを決めます。

強い背景の上に白文字を置く場合は、白を太らせるのではなく、外周に1pxの半透明風の中間色を置くと安定します。
たとえば #808080 に近い中間色を外周に回すか、文字の真下に1pxぶんの影列を敷くと、背景の明暗がばらついても字形が崩れません。
ドット絵では本当の半透明を使わず、疑似的な中間色で輪郭を作るほうが輪郭管理がしやすく、拡大表示でも境界が素直に読めます。

色だけに依存しない差分を入れる

アクセシビリティの観点でも、状態や意味を色だけで伝える設計は弱いです。
success、warn、error、info を色分けするにしても、記号、縁取り、パターン、位置の変化を組み合わせると判読の取りこぼしが減ります。
error は赤系にするだけでなく、1pxの外周強調や×記号を添える。
選択状態ならアクセント色の面を増やすだけでなく、内側に1pxの反転枠を置く。
hover は色相変更より、縁の光り方を変えるほうがUIとして自然です。

これは拡大前提の表示でも効きます。
ピクセルアートUIは制作時に何倍にも拡大して扱いますが、実際の表示では 100% 前後、あるいは 2x や 3x の整数倍で見ることが多くなります。
人の目が画素を独立して認識できる密度には限界があるので、拡大時に見える装飾と、実表示で意味として読める差分は一致しません。
400%で映えるディザ模様より、100%と2xで区別が残る1px輪郭や1pxシフトのほうがUIでは効きます。

GIFの少色運用はUIと相性がいい

アニメーションUIを軽くまとめたい場面では、GIFの最大256色という性質は少色UIと噛み合います。
もともと8〜24色の小パレットで設計していれば、点滅するカーソル、通知バッジの脈動、ボタンの短い点灯アニメーションを色崩れなくまとめやすいからです。
AsepriteでもGIF書き出しができるので、検証用の動きを手早く出す用途と相性があります。

ただし、UIで使うアニメーションGIFは、色数に余裕があるからといってグラデーションやディザを増やしすぎないほうがまとまります。
少色前提で組んだ輪郭や文字のコントラストが、圧縮後も残る設計にしておくと、静止時も動作時も印象が揃います。
動かした瞬間だけ読みにくくなるUIは、静止画の見た目が良くても実運用では崩れます。

よくある失敗と修正法｜読みにくい・押しにくい・世界観が散る

初心者のUIでまず起こりやすいのは、手を入れたぶんだけ良くなると思って、情報を足しすぎることです。
とくに小さいサイズでは、装飾の追加がそのまま密度の上昇になりません。
16x16や24x24で内側の線、角の飾り、疑似ハイライト、模様を順番に積むと、拡大表示では豪華に見えても、実寸では全部がノイズとして同じ強さでぶつかります。
修正するときは足し算ではなく、外周1px、主形、必要最小の内線1pxの順で引き算するとまとまります。
どれが骨格で、どれが飾りかを分離して、骨格だけ残して再構成する感覚です。

この引き算は、32x32の小ボタンやアイコンで特に効きます。
以前、32x32のボタンで内装飾を詰め込みすぎて、面の材質表現も枠の主張もラベルの読みやすさも全部が中途半端になったことがありました。
そのときに内側の装飾色を2色削って、外周の1pxだけを少し強く見えるように整理しただけで、UI全体の騒がしさが一段引きました。
個々のボタンは前より地味なのに、画面としては押せる場所と読ませたい場所がはっきりして、世界観まで整って見えたのをよく覚えています。

色が多すぎて判別できないとき

色数の失敗も同じで、増やした色がそのまま情報になるわけではありません。
似た明度と近い色相の中間色をいくつも並べると、作者の頭の中では役割が分かれていても、見る側には差が読めません。
少色数UIがまとまりやすいのは、色の意味が固定されるからです。
逆に多色寄りのUIで設計ルールが曖昧だと、装飾色、状態色、影色、アクセント色がぶつかって、結果としてどこを見ればいいのか分からなくなります。

修正は、まずパレットを統合するところから始めます。
近い色を役割ごとにまとめて、面、枠、影、ハイライトの担当を明確にします。
そのうえで、質感を増やしたい場所があっても、ディザリングは隣接した2色だけに絞ると破綻しません。
3色以上を細かく混ぜると、ドット単位では豊かでもUI単位ではざらつきとして見えます。
GIFが256色まで扱えても、UIに必要なのは色の上限ではなく、色の文法です。

装飾過多で世界観が散るとき

世界観を出したくて、金属、木、石、宝石の表現を1画面に全部入れる失敗もよくあります。
単体ではどれも悪くないのに、並んだ瞬間に別のゲームの部品の寄せ集めに見える状態です。
ドット絵UIの世界観は、模様の多さよりも、光の向き、枠の硬さ、角の処理、影の深さが揃っているかで決まります。
ボタンだけ立体で、パネルはフラット、アイコンだけ黒100%の強い輪郭、という混在が起きると、同じパレットを使っていても散ります。

ここでも修正の軸は引き算です。
全パーツの外周、面、内線の優先順位を揃えると、装飾を減らしてもむしろらしさが残ります。
Beforeでは黒100%の枠でアイコンを締めたくなりがちですが、これを背景と面の中間に寄せた1pxアウトラインへ置き換えるだけで、背景とのなじみと記号の読みやすさが両立します。
枠が主役から境界の役目に戻るので、背景が明るくても暗くても輪郭だけが浮いて見えにくくなります。
見た目の派手さは少し下がっても、画面全体の統一感は上がります。

hover と active の差が見えないとき

状態差が小さいUIも、初心者ほど陥りやすいところです。
hover と active を別データとして作ったのに、実際に並べると何が変わったのか分からない、という状態です。
原因は、変化が面の色替えだけに寄っていたり、差分が内側に偏っていたりすることです。
小さいUIでは、中央の模様より外周と位置の変化のほうが先に読まれます。

修正では、hover なら上側に1pxのハイライトを足す、あるいは基準状態にあったハイライトを一段強める。
active ならそのハイライトを削るか弱めて、面やラベルを1px下へ沈めます。
さらに基準状態とのあいだに明度差を8%ほど入れると、マウスを乗せた瞬間と押した瞬間の意味が明快になります。
見分けるための差分を、色相変更ではなく、光と位置のルールで固定するわけです。
これならボタンの種類が増えても、同じ文法で状態を量産できます。

余白不足で読みにくくなるとき

読みにくいUIは、文字そのものより余白設計が崩れていることが多いです。
ラベルが枠に近すぎると、文字の輪郭とボタンの境界が視覚的に干渉して、字が小さく見えます。
内側に影や内枠まで足しているのに、肝心の文字まわりに呼吸する空間がないと、詰め込んだぶんだけ読みにくくなります。

修正は単純で、内側パディングを上下3px、左右4pxに固定して、そこから文字サイズとアイコン位置を逆算します。
さらに必要なら1pxの内枠を置くと、面と文字の領域が分かれて視線の置き場ができます。
余白は空きではなく、情報を分離する部品です。
モバイルではタップ領域が44px以上あると誤操作が減るので、小さく見せたいUIでも見た目の枠だけを縮めて、中の情報まで窮屈にしない設計が効きます。

ドットが潰れて見えるとき

高精細な表示では、細かく描いた階段や疑似AAが見えなくなり、1x表示で潰れたように見えることがあります。
人の目が画素を独立して見分けられる密度には限界があるので、拡大時に見えていた細工が、そのまま実表示で伝わるとは限りません。
小さな差分を増やすほど、このギャップが大きくなります。

修正するときは、1xで情報を足して救おうとするのではなく、2xや3xスケールで見たときに等倍のシャープさが残る構造へ戻します。
Asepriteは2xや3xで書き出せるので、32x32のセルなら3xで96x96として確認でき、輪郭の崩れや装飾の潰れ方を切り分けやすくなります。
そこで残らないディテールは、実寸でも意味を持ちにくい装飾です。
消えるドットを守るより、残る輪郭を強くしたほうがUI全体の安定感につながります。

スプライトシート運用でも似た問題が起きます。
細い輪郭が隣接セルの色と干渉すると、ドットが潰れたようなにじみ方になります。
こういう場面ではセルまわりの余白やパディングが効きますが、UIそのものの設計としても、外周1pxを明快に保っておくと崩れが出ても形の芯が残ります。
潰れるケースで守るべきなのは、ディテールではなくシルエットです。

そのまま使えるUI素材仕様書ミニテンプレート

実務では、仕様書が立派すぎて誰も更新しない状態より、制作と書き出しにそのまま使える最小単位のテンプレートが役に立ちます。
とくにドット絵UIは、1pxの差分が見た目にも実装にも直結するので、サイズ、色、状態、命名の4つを最初から固定しておくと、量産の速度が落ちません。
私自身、チームでボタンやアイコンを並行制作するとき、命名とサイズ表と色トークンが揃っただけでレビューの往復が目に見えて減りました。
差分を見る側が「色が違う」のではなく「state.hover の処理が規則から外れている」と判断できるようになるからです。
感覚の話から、確認可能な仕様の話へ移せるのがテンプレートの強みです。

ミニテンプレート本体

下の表をそのままベースにすると、アイコン、ボタン、パネルの3系統を同じ文法で管理できます。

このサイズ表の意図は、見た目の種類を増やすことではなく、判断の分岐を減らすことにあります。
たとえば検索や歯車のように意味がシルエットで伝わるものは16x16、メニューの主役になりすぎない標準アイコンは24x24、RPG風の飾り枠つきアイコンや小さな選択ボタンは32x32、と割り切ると迷いが減ります。
ボタンも同じで、ラベル量に応じて32x16、48x16、64x20に着地させるだけで、作る前から余白設計が決まります。

色トークンの雛形

色は「見た目」ではなく「役割」で命名しておくと、差し替えに強くなります。
ドット絵UIでもこの考え方は相性がよく、木製、金属、SF風のどれに寄せても、役割名が固定されていれば運用がぶれません。

この命名にしておくと、たとえばAseprite上でパレットを組むときも、色見本が単なる並びではなく「どこに使う色か」で把握できます。
UIレビューでも「ボタンの青が違う」ではなく「accent.primary と state.hover の関係が逆転している」と指摘できるので、修正の着地点が揃います。
通常テキストはコントラスト比4.5:1以上、大きい文字は3:1以上を基準に置くと、ラベルの視認性を仕様として保ちやすくなります。

状態一覧テンプレート

状態差は、別デザインを量産するのではなく、1px差分と明度・彩度の規則で固定すると管理が軽くなります。下の表はそのまま仕様書に貼れる形です。

ここで効くのは、差分の主戦場を外周と位置に置くことです。
hoverは「明るくなった」、activeは「沈んだ」、disabledは「引いた」、focusは「選択中の輪郭が立った」と、読む側が一瞬で意味を取れます。
ドット絵UIは中央の模様を凝るより、上1px、下1px、外周1pxの扱いを固定したほうが全体の統一感が残ります。

命名規則テンプレート

命名は、ディレクトリ、用途、サイズ、状態を順に並べるだけで十分です。並び順を固定すると、ファイル名だけで内容が読めます。

この規則の利点は、差分確認のときに比較対象が自動的に並ぶことです。
primary_32x16_default と primary_32x16_hover が隣にあれば、変更が状態差なのかサイズ違いなのか一目で分かります。
レビュー時間が短くなるのは、作業が速くなるからではなく、見る順番が揃うからです。
制作側も実装側も同じ語彙で話せるようになります。

書き出し形式テンプレート

保存形式は、単体PNGとスプライトシートの2系統に分けると管理が安定します。
PNGは透過付きで扱え、可逆圧縮なのでUIの輪郭を崩しません。
スプライトシートは1枚にまとめることで読み込み回数を抑えられ、実装で扱う単位も揃えられます。
AsepriteならPNG書き出しに加えて、1列配置やグリッド配置のスプライトシート、さらにJSONのメタデータも合わせて出力できます。

スプライトシートでは、各セルに外周のセーフティマージンを確保しておくと、スライス時のにじみを抑えやすくなります。
一般的な目安は1〜2px程度ですが、最適な余白はテクスチャフィルタ（補間設定）、Mipmap の有無、ゲームエンジンのインポートオプションなどに依存します。
ビルド環境で実際にレンダリング確認を行い、必要に応じて余白を調整してください。

2xや3xの拡大量も同梱しておくと、デザイン確認と実装確認の両方で役立ちます。
たとえば元セルが32x32なら、3x書き出しで各セルは96x96になります。
1列に6フレーム並べたシートなら96x576になるので、押下差分や光の向きのズレを一覧で見つけやすくなります。
拡大プレビューで派手に見える装飾より、2xや3xでも輪郭が崩れない構造を残す、という判断にも使えます。

そのまま貼れる記入例

仕様書に載せる最小記入例としては、次の密度があれば制作に入れます。

このテンプレートの価値は、豪華なドキュメントを作ることではなく、誰が増産しても同じUI言語に戻ってこられることにあります。
サイズ、色トークン、状態、命名、書き出しの5点が固定されると、追加制作のたびに判断をやり直さなくて済みます。
ドット絵UIは小さいぶんだけ、曖昧さがそのままズレとして見えます。
仕様書も同じで、短くても粒度が揃っていれば、そのまま現場で効きます。

素材パック活用とライセンス注意点

素材パックは、立ち上がりを一気に短縮できる手段です。
ボタン、パネル、アイコン、装飾が最初から一式そろっているので、ゼロから部品を描き起こすよりも、画面を組みながら必要な要素を拾っていけます。
たとえばOpenGameArtには 750 assets を収録した Pixel UI pack のような配布物があり、探索段階で「どの部品が要るか」を洗い出す用途にも向きます。
Unity Asset Storeでも 151 icons を含む UI キットのように、実装寄りのまとまりで入手できる素材があります。
枚数が多いパックは、欠けている部品を想像で埋めずに済むぶん、設計の抜け漏れを見つけやすいのが利点です。

一方で、数がそろっていることと、作品にそのままなじむことは別問題です。
ドット絵UIは、光の向き、枠の硬さ、内影の深さ、角の処理が少し違うだけで、同じ画面に置いたときの統一感が崩れます。
既存パックを流用するとき、私はまず全部を描き直すのではなく、枠線色と内影の色だけを自作ルールに合わせて一括置換します。
これだけで部品ごとの出自の差が目立ちにくくなり、画面全体の温度感がそろいます。
面の質感やシルエットまで触る前に、境界と陰影の文法をそろえるわけです。
量の多いパックほど、この入口の整形で見た目が安定します。

ライセンスは「使えるか」ではなく「どう使えるか」で読む

素材パックで見落としやすいのがライセンスです。
無料配布だから安全、有料販売だから商用で自由、という分け方は成り立ちません。
OpenGameArtのような配布サイトでは、CC0、CC-BY などの CC 系ライセンスが混在します。
CC0 なら扱いは軽くなりますが、CC-BY はクレジット表記が前提です。
同じサイト内でも作品ごとに条件が異なるので、サイト名ではなく個別アセット単位で読みます。

Unity Asset StoreやArtStationの素材は、CC 系ではなく独自ライセンスで配布されるのが普通です。
この系統は、ゲームやアプリに組み込んで使う前提ではあっても、素材そのものを再配布する運用は通りません。
改変の可否、チーム内共有の扱い、納品物に元データを含めてよいかといった点で差が出るので、単に「商用利用可」だけ拾って進めると後で詰まります。
とくに UI 素材は、実装データ、差分PNG、編集元ファイルが近い場所に並ぶため、再配布不可の条件と制作フローがぶつかりやすい分野です。

価格は「完成品の値札」より「直す前提の工数」で見る

価格感にも幅があります。
ArtStationでは素材が USD $8.99 で販売されている例があり、入口としては手が届きやすい部類です。
個人受託の価格感では、たとえばPolycountで見かける相場例として、キャラクターが $10〜$25、タイルセットが $40〜というラインがあります。
UIパックもこの間のどこかに収まることが多いですが、収録点数、状態差分の有無、9-slice 対応、編集元データの有無で値付けは大きく動きます。
安いパックでも、世界観合わせの調整に時間がかかれば、実務上の総コストは上がります。
逆に、少し高くても状態差分や周辺部品まで揃っていれば、量産工程の摩擦は減ります。

導入時に仕様書へ残す項目

実務では、素材を入れた瞬間にライセンス情報が散らばります。
ダウンロードページ、同梱テキスト、ストア商品説明、チームの口頭共有が分離すると、数か月後に条件を追えなくなります。
そこで仕様書には、見た目のルールと同じ粒度で、ライセンス運用も記録しておくと事故が減ります。
最低限そろえたいのは、改変可否、クレジット表記要否、プロジェクト内再配布の扱いの3点です。

たとえば「色替えのみ可」「クレジットはスタッフロールに記載」「制作委託先へは編集元ファイルを渡さず、書き出しPNGのみ共有」といった形で残しておけば、デザイン調整と契約条件が同じ文書の上に並びます。
UI は量産工程で触る人数が増えやすく、後から差分を足す場面も多いので、ライセンス情報を法務メモとして別管理にすると現場から見えなくなります。
素材パックは便利ですが、速く作れるぶん、使い方の条件まで短時間で固定しておかないと、後半の修正で足を取られます。

作って検証する次のアクション

手を動かして検証する段階では、部品を増やすより先に、少ない種類でルールが通るかを見ます。
まずは 16x16 のアイコンを検索、設定、戻るの 3 つだけ作り、32x16 のボタンを default と active の 2 状態で並べてください。
この組み合わせなら、記号の読ませ方、1px の押下表現、枠と面の関係が一度に見えます。
ここで形の文法がそろえば、以後の追加部品も同じ基準で増やせます。

次に、パレットは 8〜16 色で固定し、default、hover、active、disabled の各状態に使う色を一覧にします。
面色、枠色、ハイライト、影を横並びにしておくと、どの状態差を色で出し、どの差を 1px の位置や陰影で出すのかが曖昧になりません。
通常テキストは 4.5:1 以上、大きい文字でも 3:1 以上のコントラストを確保する前提で見直すと、装飾を足す前に読めるUIへ寄せられます。
私はこの段階で 2x と 3x のスクリーンショットを並べて可読性レビューをします。
拡大率を変えて同じ部品を見ると、100%では気づきにくいにじみや、押下時だけ崩れる 1px のズレが一目で洗い出せます。

ウィンドウ枠は 9-slice で 1 セット作れば十分です。
角、辺、中央に分け、任意サイズへ伸ばして、角と辺の接合部、辺と中央の切り替わり、とくに 1px のハイライトと影が途切れていないかを確認します。
9-slice は仕組み自体は単純でも、接合部の粗は拡張した瞬間に露出します。
ここで破綻がなければ、パネル、ダイアログ、選択枠まで同じ設計を横展開できます。

Asepriteなら 2x や 3x でそのまま書き出して見比べられるので、実制作ではこの往復が速いです。
小さなUIは、描く工程より、並べて比較する工程で質が決まります。
3つのアイコン、2状態のボタン、1セットの 9-slice 枠。
この最小単位でルールが通るなら、量産に入っても画面は散りません。

関連事項: 将来的に本サイトで関連記事を公開する際は、記事本文内にドット絵 描き方Aseprite 使い方などの内部リンクを最低2本程度追加して、読者がさらに掘り下げられる導線を設けてください。