Unity 2Dドット絵設定｜ぼやけないPixel Perfect

Unity 6で同じ32x32素材がぼやけたり輪郭がにじんだり、動かすとチラついたりする場合、原因の多くは設定同士の不整合です。
まずは Game ビューを Free Aspect にし、Run in Edit Mode を有効にして、ズームを変えながら Filter Mode を Point に切り替え、Compression 設定を変えて輪郭の出方を比較してください。
多くの場合、この段階で原因の見当がつきます。
Texture Import の Sprite/Point/無圧縮系設定、全スプライトでの PPU 統一、そして Pixel Perfect Camera の Assets PPU・Reference Resolution・Crop・Pixel Snapping を一貫した設計として整理します。
設定は項目を個別に覚えるより、1枚の絵が「何ピクセルで、1ユニットとして、どの解像度基準で、どのグリッドに載るか」を揃えたほうが早く安定します。
32x32の6フレーム歩行を例に、スプライトシート分割からアニメーション作成まで、そのまま表示確認できるところまで最短で進めます。

Unityでドット絵ゲームを作る前に決める3つの基準

スプライト基準サイズの選び方

ドット絵ゲームの設定で最初に固定したいのは、キャラクターやタイルを何ピクセル単位で作るかという基準サイズです。
ここが曖昧なまま進むと、32x32の主人公の横に48x48のオブジェクトが並び、あとから縮尺だけで帳尻を合わせる流れになりがちです。
そうなると、同じUnityプロジェクト内に「絵の密度が違う素材」が混ざり、輪郭の見え方や当たり判定の感触までバラつきます。

初心者なら、基準サイズは 16x16、32x32、64x64 のいずれかに絞るのが安全です。
情報量と描きやすさのバランスを考えると、最初の検証は 32x32 を推奨します。
タイルもキャラクターも、まずは同じ基準サイズで揃えると設計が明快です。
たとえば 1タイルを32px、キャラクターも基本1マス幅を32x32で置く方針にすると、Tilemap上の位置、衝突サイズ、アニメーション用のフレーム分割まで一本のルールでつながります。
歩行6コマのシートを作るときも、1コマ32x32なら全体寸法をすぐ逆算できますし、Sprite Editorでの分割も迷いません。

32x32キャラクターを 1タイル=32px、PPU=32 で置いた状態でGameビューの倍率を ×2 と ×3 に切り替えて確認すると、整数スケールで輪郭がぴたりと揃うことが確認できます。

PPUを全素材で統一する理由と決め方

基準サイズを決めたら、次に固定するのが PPU（Pixels Per Unit） です。
Unityではスプライトの大きさをワールド空間に置き換える基準として PPU を使うので、ここが揃っていないと同じ32pxの絵でもシーン上の大きさが変わります。
ドット絵で最も避けたいのは、画像の見た目は同じなのに、インポート設定だけ違ってサイズ感がずれる状態です。

原則は単純で、全素材を同じ PPU に統一する ことです。
たとえば 1タイル=32px で設計するなら、キャラクター、地形、アイテム、UI用でない世界内オブジェクトまで PPU=32 に揃えます。
16px基準なら PPU=16、64px基準なら PPU=64 です。
後から一部の素材だけ PPU=100 にすると、Scene 上では縮尺で見た目を合わせられても、Pixel Perfect の計算基準と噛み合わず、位置合わせやスナップが崩れます。

この統一が効いてくるのが、Pixel Snapping のグリッドです。
ピクセルスナップの基準量は 1/PPU なので、PPU=100 なら 0.01、PPU=32 なら 0.03125 になります。
つまり、PPU=32 のプロジェクトでは「1ピクセルぶん動かす」とは 0.03125 ユニット動かすことと同じ意味です。
移動量、ノックバック距離、グリッドへの丸め値を考えるとき、この数字が根拠になります。
ドット絵なのに Transform の位置が中途半端な小数になっていると、見た目のブレはだいたいここから始まります。

PPU を統一しておくと、Pivot をピクセル単位で合わせる場面でも判断がぶれません。
足元基準のキャラクター、タイル中央基準のオブジェクト、弾の発射位置など、どこを原点にするかを決めたあとも「1pxのズレ」がそのまま同じ尺度で扱えます。
逆に PPU が混在すると、同じ 1px のつもりで調整しても、素材ごとにワールド上の移動量が変わってしまいます。
見た目のズレを Inspector の Scale で吸収し始めると、あとでアニメーション差し替えや当たり判定調整に響きます。

Reference Resolutionの決め方

3つ目の基準は Reference Resolution（基準解像度） です。
これは「どの論理解像度をゲームの見た目の土台にするか」という話で、Pixel Perfect Camera を使うときの中心になります。
スプライトサイズと PPU が決まっていても、画面全体を何ピクセルで設計するかが未定のままだと、何タイル見せるゲームなのか、キャラをどれだけ大きく映すのかが定まりません。

横スクロールでは、16:9 の低解像度候補として 320x180 がよく使われます。
384x216 や 256x224 はコミュニティや実務で用いられる有用な例ですが、公式の“推奨リスト”として明示されているわけではありません。
ここで大切なのは「タイルサイズと見せたい範囲に合う数字を先に固定すること」です。
たとえば 1タイル=32px のゲームで Reference Resolution を 320x180 にすると、横方向は 10 タイルぶん見せる設計になります。
キャラクターを大きく見せたい横スクロールでは、このくらいの密度が扱いやすい場面が多いです。
一方で、もっと周囲を広く見せたいなら 384x216 にすると、同じ 16:9 のまま表示範囲を少し広げられます。
画面に何マス入るかを先に決めておくと、マップ設計、敵配置、カメラ追従の気持ちよさが揃ってきます。

この基準解像度は、最終的な表示サイズともつなげて考えます。
たとえば設計メモを「Reference Resolution=320x180、画面スケール=×3」にしておけば、出力イメージは 960x540 です。
整数スケールで拡大できるので、ドットの輪郭が安定しやすく、Gameビューでの確認も明快になります。
私が 32x32 キャラクターで検証するときに ×2 や ×3 をよく切り替えるのは、まさにこの整数倍での見え方を確かめるためです。
整数で拡大された状態は、1px の段差や目の位置が崩れず、動いたときの印象も落ち着きます。

Reference Resolution を後回しにすると、UI の配置、カメラの切り取り方、1画面に収まるタイル数がすべて仮置きになります。
ドット絵ゲームは、絵そのものより「1pxが画面でどう見えるか」の積み重ねで印象が決まります。
だからこそ、スプライト基準サイズ、PPU、Reference Resolution は別々の設定ではなく、最初に1枚の設計メモへ固定しておくのがいちばん崩れません。

プロジェクト作成時の基本設定｜2Dテンプレートと必要パッケージ

Unity Hubで新規作成

出発点はUnity Hubです。
ここでUnity 6系のエディターを入れたあと、新規プロジェクトを作成します。
プロジェクト作成画面ではテンプレート候補が並ぶので、ドット絵の2Dゲームなら 2D か Universal 2D のどちらかを選べば軸がぶれません。
Unity Hubはエディター管理とプロジェクト管理をまとめて行う公式アプリなので、ここから始めるとバージョン違いの混線も起きにくくなります。

テンプレート選びの段階で迷う人は多いですが、最初に決めるべきことは「最小構成で進むか」「URP前提で組むか」の2点だけです。
ドット絵の表示確認を早く始めたいなら2D、ライティングや2D Rendererまで見据えるならUniversal 2Dという切り分けで十分です。
どちらを選んでも2D開発自体は進められるので、ここで立ち止まる必要はありません。

実作業では、Universal 2Dで始めて最初に2D Rendererの設定を確認し、その後で2D Pixel Perfectを導入する流れにすると、描画の土台とカメラ設定を切り分けやすくなります。

2DとUniversal 2Dの使い分け

2Dテンプレートは、余計な要素が少ない最小構成です。
カメラ、スプライト、アニメーション、Tilemapといった基本を追いやすいので、Unityの2Dワークフロー自体を覚える段階と相性がいいです。
インポート設定、PPU、スプライト分割、アニメーション作成までを一直線につなげたいときは、この軽さが効きます。

一方のUniversal 2Dは、URPの2D Rendererを前提にした構成です。
2Dライトやブレンド表現、Rendererまわりの拡張を視野に入れるなら、こちらから始めたほうが後で組み替える手間が減ります。
ドット絵のプロジェクトでも、ゲームが育っていくと「暗い部屋だけライティングを変えたい」「エフェクトだけ描画の見え方を変えたい」といった要望が出やすく、そこでURPの土台があると対応の筋道が見えます。

テンプレートの違いをざっくり整理すると、次のようになります。

ドット絵だけを見ると、どちらでも成立します。
差が出るのは「どこまで先の構成を見ているか」です。
学習を優先して表示の安定を先に掴むなら2D、あとでURP構成に寄せる予定があるならUniversal 2Dのほうが流れが自然です。

Pixel Perfect Cameraが無いときのパッケージ確認

プロジェクトを作ったあと、Main CameraにPixel Perfect Cameraを付けようとして見当たらないことがあります。
この場合は機能が消えたわけではなく、2D Pixel Perfectパッケージの導入状況を見れば整理できます。
Pixel Perfect Cameraはこのパッケージに含まれるコンポーネントなので、カメラ側だけ探しても出てこないときはPackage Manager側を先に見るのが順序として正しいです。

操作はWindowからPackage Managerを開き、パッケージ一覧で2D Pixel Perfectを確認します。
未導入ならインストールし、導入済みならバージョンが認識されている状態で Main Camera のコンポーネント追加欄を見直します。
詳しい公式ドキュメントは 2D Pixel Perfect のパッケージページや Texture Importer の仕様を参照してください。
Pixel Perfect Cameraは Main Camera にアタッチして使う前提なので、探す場所も Main Camera で合っています。
詳しい公式ドキュメント: ここで一度パッケージの所在を掴んでおくと、後工程で「機能名は知っているのにメニューに出ない」という混乱を避けられます。
とくにUniversal 2Dで始めた場合は、2D Rendererの存在を確認してから2D Pixel Perfectを入れる流れにしておくと、描画設定とカメラ設定の境界が見えます。
私はこの順番にしてから、Renderer設定とPixel Perfect設定を別の問題として切り分けられるようになりました。
この順序にすると、Renderer 設定と Pixel Perfect 設定を別個の問題として整理でき、導入時の混乱を減らせます。

ライセンスとバージョンの注意

開始時点で押さえておきたいのが、ライセンス条件とUnity 6系の見方です。
Unity Personalは無料で使えますが、利用の目安は 過去12か月の売上・資金調達が20万USD未満 です。
古い記事では別の金額が残っていることがありますが、ここは現行条件で見ておくほうが混乱しません。

バージョンについては、Unity 6が現行世代として案内されており、Unity 6.3 LTSは2025年12月提供予定 です。
LTSを待つか先に現行版で学ぶかは用途次第ですが、この記事の手順そのものはUnity 6系の開始フローとして再現できます。
公開タイミングによって細かい画面表記が前後することはあっても、Unity Hubから新規作成し、2DまたはUniversal 2Dを選び、2D Pixel Perfectの有無を確認するという骨格は変わりません。

ライセンスとバージョンを最初に整理しておくと、「どのテンプレートで始めるか」と「どの設定が見えるか」の理解がつながります。
Unity 6系では、まずテンプレートの方向性を決め、その上で必要パッケージを揃えるという順番で進めると、初回セットアップの見通しが一気に立ちます。

画像がぼやけないTexture Import設定

Sprite (2D and UI) にする理由

ドット絵がぼやけるとき、最初に見るべき場所は素材そのものではなく、画像を読み込んだ瞬間の扱いです。
Inspectorで対象のPNGを開き、Texture TypeをSprite (2D and UI)にしておくと、2D用スプライトとして前提が揃います。
ここが別の種類のままだと、あとからSprite Rendererやアニメーションに乗せても、2D表示のための設定が噛み合わず、見た目の確認が遠回りになります。

Unityの2Dワークフローは、このTexture Typeを起点にしてSprite Editorでの分割、Animator Controllerへの流し込み、Tilemapへの利用までつながっています。
単体の立ち絵でも、UIアイコンでも、フレームアニメのシートでも、まずSprite (2D and UI)にしておくと後工程が一本の線になります。
とくにドット絵は、1px単位の輪郭が情報量そのものなので、テクスチャとして曖昧に扱うより、最初からスプライトとして管理したほうが破綻の原因を追いやすくなります。

私自身、同じ32x32のPNGが「絵は同じなのに見え方だけ違う」状態になったとき、最初はカメラや解像度を疑いましたが、実際はImport設定の入口が揃っていないケースが多くありました。
ドット絵の崩れは表示段階で起きているように見えて、実際には読み込み時点で種がまかれていることが珍しくありません。

Filter Mode: Point (no filter)

ドット絵で輪郭を保つなら、Filter ModeはPoint (no filter)が基準です。
BilinearやTrilinearは周囲のピクセルを補間して滑らかに見せる方式なので、写真や高解像度イラストには向いていても、ドット絵では1pxのエッジが混ざってしまいます。
結果として、意図した角の立ち方が消え、線が少し溶けたように見えます。

この差は、同じ32x32 PNGを切り替えるとすぐ分かります。
輪郭に1pxの黒線を置いたキャラを用意して、BilinearとPointを交互に見ると、黒線の外周がにじむか、きっぱり止まるかが即座に変わります。
スクリーンショットを並べる前提で確認すると、拡大表示したときの差がさらに見えます。
Bilinearでは境界の色が中間色に引っぱられ、Pointでは打ったピクセルがそのまま残ります。
ドット絵の「線が甘い」という違和感は、この補間で起きていることが多いです。

Trilinearまで入ると、ミップマップを含む補間の影響で、ドット絵にはなおさら不向きです。
このセクションではImport設定に絞っているので、まずは迷わずPoint (no filter)に固定しておくと、ぼやけの主因を1つ確実に消せます。

Compression: 無圧縮系の考え方

色のにごりを避けたいなら、Compressionも見逃せません。
基本はNoneのような無圧縮系を選びます。
ドット絵は色数が少なく、隣り合うピクセルの差で輪郭や陰影を作っているので、圧縮で色が丸められると、小さな差分が先に潰れます。
結果として、輪郭がぼやけたように感じたり、影色が少し濁って見えたりします。

実務では、プラットフォーム別の設定名が揃わないことが多いです。
その場合も考え方は同じで、無圧縮に近い設定を選んで、色の変質を避けるという軸で見ます。
ドット絵はグラデーションの滑らかさより、ピクセルごとの色の独立性のほうが見た目に直結します。
圧縮率の都合で中間色が足されると、輪郭線の締まりや配色のキレが落ちます。

とくに少ない色で設計したUIアイコンや、影色を1段だけ置いたキャラクターでは、この差が目立ちます。
16色前後の感覚で組んだ絵ほど、1色の変化が全体の印象を動かします。
ドット絵で「なんとなく眠い画面」になったとき、Filter ModeだけでなくCompressionも一緒に直すと、急に線と色が噛み合うことがあります。

Sprite Mode Single/Multipleの使い分け

Sprite Modeは、画像をどう使うかで決めます。
アイコンや単体画像はSingle、シートから複数フレームを使う場合はMultipleです。
この切り分けが曖昧だと、Sprite Editorで必要な操作が出てこなかったり、アニメーション素材の管理が散らかったりします。

Singleは、1枚のPNGを1つのスプライトとして扱う設定です。
ボタン用アイコン、1枚絵のオブジェクト、単独表示の顔グラフィックのように、画像全体をそのまま使う素材に向いています。
対してMultipleは、1枚のシートの中に複数コマが入っている前提です。
歩行、待機、攻撃のフレームを並べたキャラクターシートや、連番エフェクトの管理ではこちらが基本になります。

たとえば6フレームを3x2で並べ、1コマが32x32ならシート全体は96x64になります。
24フレームを6x4で並べるなら、同じく1コマ32x32で192x128です。
こうしたシートはMultipleにしてからSprite EditorでSliceする流れが自然です。
セル寸法が固定ならGrid By Cell Sizeで32x32を指定すると、1コマずつ切り出しやすく、ズレも起きにくくなります。

一方、単体画像なのにMultipleにしていると、管理対象だけ増えて中身が増えません。
逆にシートなのにSingleのままだと、複数フレームとして扱えず、アニメーション作成の段階で詰まります。
ここは「画像の見た目」ではなく「Unity内での利用単位」で決めると迷いません。

PPU統一の実務ポイント

ドット絵の見た目を安定させるうえで、Pixels Per Unitは全スプライトで同一値に揃えるのが実務の基本です。
PPUが混在すると、同じ1 Unity unitでも画像ごとの実寸が変わるため、キャラだけ少し大きい、UI用アイコンだけ縮尺感が違う、といった破綻が起きます。
さらに、ピクセル単位で位置を合わせる工程でも誤差が出やすくなります。
URP 2D Pixel Perfectの基準でも、スナップの最小単位は1/PPUで決まるので、PPUが揃っていないとスプライトごとに別の物差しを使うことになります。

「画像サイズ」そのものではなく、「その画像を何unitとして置きたいか」を基準に考えます。代表的な素材サイズで整理すると、次のような対応になります。

この揃え方なら、16x16のタイル、32x32のキャラ、64x64の大きめオブジェクトでも、それぞれ「画像のピクセル数ぶんの密度」を保ったまま、Unity空間では同じ1unit基準で扱えます。
逆に、32x32素材だけPPUを16にすると、同じ画像が2x2 unit扱いになり、他のスプライトとのサイズ感が崩れます。

別の設計もあります。
たとえば32x32キャラを2x2 unitで扱いたいなら、全素材をその基準に合わせてPPUを統一します。
大事なのは値そのものより、混在させないことです。
私は序盤の試作で、背景タイルを16、キャラを32、UI用装飾を100のように入れてしまい、配置した瞬間は合って見えても、動かすとズレ方が揃わず、あとで全部見直すことになりました。
ドット絵の崩れは絵柄よりも、こういう単位の不統一から始まる場面が多いです。

Pixel Perfect Cameraの設定方法

コンポーネントの追加と基本パラメータ

Unity 6でドット絵を崩さず表示する土台は、Main CameraにPixel Perfect Cameraを載せるところから始まります。
2D Pixel Perfectパッケージを入れた状態で、カメラの Inspector にこのコンポーネントを追加すると、描画をピクセル基準で揃えるための項目がまとまって現れます。
ここで見るべき軸は、アセット側の密度と、画面側の基準解像度を同じ設計思想で結ぶことです。

最初に合わせるのが Assets Pixels Per Unit です。
ここには、素材で統一した PPU をそのまま入れます。
前のセクションで PPU を揃えたなら、その値をカメラ側にも反映させるだけです。
たとえば 32x32 のキャラを 1x1 unit 基準で扱う設計なら、ここは 32 になります。
スプライトの Import 設定が 32、カメラ側が 16 のように食い違うと、ワールド上では合って見えても、表示時のスナップ単位だけ別の物差しになります。
輪郭の締まりが安定しないときは、Texture Import と Camera の両方に同じ数字が入っているかを先に見ます。

次に決めるのが Reference Resolution です。
ここにはゲーム全体の基準解像度を入れます。
16:9 の横長画面で組むなら、320x180 のような低解像度基準が扱いやすく、拡大時も整数倍率で画面全体を設計しやすくなります。
基準解像度は「最終的に何ピクセルで見せたいか」ではなく、「何ピクセルを原寸として世界を切り取るか」という考え方で決めると噛み合います。
キャラの頭身、UI の文字サイズ、1画面に入る地形量までここから連鎖するので、カメラ設定というよりレベル設計の基準点です。

私は序盤の試作で、アセット側は PPU を揃えていたのに、カメラの Reference Resolution だけ曖昧なまま進めて、Game ビューのサイズごとに見え方が変わる状態を作ってしまったことがあります。
ドット絵の鮮明さは Import 設定だけで完結せず、カメラがどの密度で世界を見るかまで揃って初めて安定します。

Assets PPUとReference Resolutionの整合

Assets Pixels Per Unit と Reference Resolution は別項目ですが、実際にはセットで考えます。
PPU は「1 unit を何ピクセルで表すか」、Reference Resolution は「画面に何ピクセルぶんの世界を入れるか」です。
この 2 つが噛み合っていると、キャラ、タイル、背景、UI の密度が一貫します。

たとえば PPU を 32 にした場合、1 unit は 32 ピクセルです。
この状態で Reference Resolution を 320x180 にすると、横方向には 320 ピクセルぶんの世界を切り取る設計になります。
結果として、1 unit の物体は画面上で 32 ピクセル単位の密度を保ったまま、整数スケールで拡大されます。
ここで基準解像度を半端な設計にすると、表示上は拡大できていても、どこかで補間や端数処理が入り、線の太さやエッジの位置が揺れます。

この整合が効いてくるのは、解像度違いの画面へ出したときです。
PC の横長モニターでも、縦横比が近いスマホ画面でも、基準となる 320x180 を中心に整数スケールで拡大できていれば、1 ピクセルの見え方が保たれます。
逆に、アートは 32 基準なのにカメラ側の設計がその前提から外れていると、同じ 32x32 素材でもある画面では締まり、別の画面では眠く見えるという差が出ます。

ここは数式で難しく考えるより、素材の PPU と、ゲーム全体の“原寸画面”を同じ世界観で固定すると整理すると通ります。
アセット解像度とゲームの表示解像度は切り離さず設計するのが実務上の基本です。
基準解像度を決めたあとに効いてくるのが、Crop Frame、Pixel Snapping、Run in Edit Mode の 3 つです。
ここは見た目の安定と確認作業の両方に直結します。

Crop Frame は、基準アスペクトから外れた画面でどこに黒帯を入れるかを制御する項目です。
X を有効にすると左右方向、Y を有効にすると上下方向の切り方が変わります。
PC とスマホが混ざる構成では、画面いっぱいに見せることだけを優先すると、どこかでピクセルの伸びや中途半端な表示領域が出ます。
黒帯を受け入れて整数スケールを守るほうが、ドット絵では画面の印象が締まります。
アクションなら上下の視界を維持したい、トップダウンなら左右の情報量を守りたい、といった設計意図で X/Y の選び方も変わります。

Pixel Snapping を ON にすると、スプライトのワールド座標がピクセルグリッドに吸着されます。
Transform の座標そのものを手で丸めなくても、描画時にピクセル境界へ寄せてくれるので、移動中の輪郭の揺れが減ります。
とくに、カメラやキャラが少しずつ動く横スクロールでは差が見えやすく、地面の縁や頭の輪郭がフレームごとにぶれる症状を抑えられます。

Run in Edit Mode は、再生せずに Game ビュー上で効果を確認したいときに効きます。
これを ON にしておくと、編集状態のままFree Aspectの Game ビューを広げたり縮めたりしながら、鮮明さと黒帯の出方をその場で見比べられます。
基準解像度の設計が良いか、Crop Frame の方向が合っているかを一往復で判断できるので、細かい調整のたびに Play を押して止める手間が減ります。
Pixel Perfect Camera component reference for URPにある各項目も、この段階で見た目と結びつけて触ると理解が早いです。

ドット絵が動いたときにチラつく原因は、画像そのものより Transform の位置がピクセル境界に乗っていない ことにある場面が多いです。
1 ピクセル単位で置かれている絵でも、ワールド座標が 1/PPU 未満の端数を含んだままフレームごとに動くと、サンプリング位置が毎回少しずつズレます。
その結果、あるフレームでは左に寄って見え、次のフレームでは右に寄って見える、といった震えがエッジに出ます。
これがいわゆる半ドット移動のチラつきです。

対策は、移動量を 1/PPU 刻みで量子化する ことです。
PPU が 100 なら最小単位は 0.01、PPU が 32 なら 1/32 なので 0.03125 です。
この刻みで座標や移動量を揃えると、毎フレームの描画位置が同じグリッドに乗るため、輪郭が暴れません。
URP 2D Pixel Perfect 公式マニュアルの考え方でも、ピクセル単位の安定は 1/PPU の整合で説明できます。

この差は実際に触るとすぐ見えます。
私も PPU を 32、Reference Resolution を 320x180 に固定した状態で、Player の移動量を最初は 0.02 にしていました。
静止画では問題なく見えるのに、歩き出すと頭や肩の外周が細かく震え、背景の縁に対してキャラだけがわずかに滲んで見えます。
そこで移動量を 0.03125、つまり 1/32 に切り替えた瞬間、移動中のエッジがピタッと落ち着きました。
絵を描き直したわけでも、アニメ枚数を変えたわけでもなく、座標の刻みをピクセルグリッドに合わせただけで止まる震え です。
ドット絵のチラつきは感覚の問題に見えて、実際には端数の残り方で説明できます。

もちろん、毎回スクリプト側で量子化しなくても、Pixel Snapping を有効にし、整数スケールを崩さない だけで改善する場面は多いです。
ただ、カメラ追従や物理移動を組み合わせると、内部では端数が積み上がりやすくなります。
そういうときに「PPU が 32 なら 0.03125 単位で動かす」という物差しを持っていると、原因の切り分けが早くなります。
輪郭の震えを見たら、まず Filter Mode や圧縮ではなく、座標が 1/PPU のグリッドに収まっているか を疑うと、修正点がまっすぐ見えてきます。

スプライトシートの分割とPivot設定

Sprite Editorを開く

ドット絵のアニメーション素材を1枚のシートで管理するなら、インポート直後の設定で Sprite Mode をMultiple に切り替えるところが出発点です。
Singleのままだと1枚絵としてしか扱われず、フレーム単位で切り出す作業に進めません。
Inspector の Texture Import 設定でSprite (2D and UI)を使っている前提で、Sprite Mode をMultipleに変更し、Apply したあとに Sprite Editor を開きます。

この流れを先に済ませておくと、あとで Animation 作成へ入ったときにフレーム選択が素直に通ります。
逆にここを曖昧にしたまま進めると、シート全体が1コマとして登録され、切り出し直しで手が止まります。
ドット絵は1ピクセル単位で整えているぶん、分割の起点がずれると後工程の違和感がそのまま残ります。
前のセクションでぼやけ対策やピクセル境界の話をしてきましたが、ここでは 「何ピクセルで1コマか」をUnityに正確に教える 段階だと考えると整理しやすくなります。

Sprite Editorを開くと、シート上にフレーム枠を作るための Slice 機能が使えます。
手動でも切れますが、ドット絵の待機・歩行・攻撃のように 等間隔で並んだコマ は、グリッドで切るほうがズレません。
特にキャラシートは、描き足しのたびに余白が微妙に変わると事故が起きるので、最初から規格を決めて Grid 系で処理したほうが再現性が出ます。

Grid by Cell Size / Countの使い分けと数値例

Slice の方式は、ドット絵なら Grid by Cell Size か Grid by Cell Count の二択で考えると迷いません。
等間隔配置のスプライトシートでは、この2つが最もズレにくく、1コマずつ囲み直す手間も減ります。
Automaticは不均等配置には向きますが、きれいな格子で並んだドット絵では、狙ったセル寸法や列数を直接指定したほうが結果が安定します。

使い分けは単純です。
1コマのピクセル寸法が決まっているならGrid by Cell Size、行と列の数が先に決まっているならGrid by Cell Count を選びます。
たとえば 32x32 のキャラを並べたシートなら、セルサイズが基準になるのでGrid by Cell Sizeの相性が良いです。
逆に、もらったシートが「3列2行で6コマ」「6列4行で24コマ」と構成だけ分かっているなら、Grid by Cell Countから入ると切り出し位置を合わせやすくなります。

数値を具体化すると判断しやすくなります。
1コマが 32x32 セルで、6フレームを 3x2 に並べる なら、シート全体は 96x64 です。
この場合はGrid by Cell Sizeで Width 32、Height 32 を入れればそのまま6コマに分かれますし、Grid by Cell Countで Columns 3、Rows 2 としても同じ結果になります。
24フレームを 6x4 配置 にしているなら、全体は 192x128 です。
こちらも 32x32 を基準に切るか、6列4行で切るかの違いで、狙う枠は一致します。

実務では、私はラフ段階ではGrid by Cell Sizeを使うことが多いです。
理由は、32x32 や 16x16 のように 1コマの規格を先に固定したほうが、差し替えや追加に強い からです。
アニメ枚数が増えて 6 コマから 8 コマになっても、セルサイズが同じならシートを増築するだけで済みます。
反対に、他の人が組んだシートを受け取る場面ではGrid by Cell Countが効きます。
全体サイズと列行が分かっていれば、元データの意図に沿って切り戻せます。

フレームを切り出したあとに見落とされやすいのが Pivot です。
ここが揃っていないと、画像そのものは正しく分割できていても、再生時にキャラが上下左右へふらついて見えます。
いわゆる wobble の正体は、絵の巧拙よりも 各フレームの基準点が一致していない ことにある場合が多いです。

ドット絵アニメでは、Pivot を Custom にして、さらに Pivot Unit Mode: Pixels で扱うと基準点を統一しやすくなります。
正規化された 0〜1 の比率ではなく、ピクセル単位で「どこを支点にするか」を決められるので、32x32 セルなら足元中央を x=16, y=0 のように明示できます。
これは、各コマの絵柄が少し上下していても、「ゲーム内で床に接している位置」は同じだと固定するための設定です。

例えば、待機6フレームで頭飾りや肩を1ピクセルずつ揺らすケースでは、各フレームの Pivot がばらつくとキャラ全体が上下に跳ねて見えます。
6フレームの Pivot を足裏中央（x=16, y=0）に統一すると、再生時の頭の上下ブレが消え、足元が床に吸い付いたまま上半身だけが自然に動くようになります。
この設定は、後で当たり判定や武器の子オブジェクトを付けるときにも効いてきます。
基準点が毎フレーム動くと、SpriteRenderer 上では小さなズレでも、エフェクトの発生位置や地面との接地感に連鎖します。
だからこそ、Slice が終わったら サイズの統一だけで満足せず、Pivot も一括で揃える ところまでを1セットで考えるべきです。
ドット絵アニメの安定感は、線のきれいさだけでなく、どのピクセルを「立っている場所」と定義したかで決まります。

アニメーション作成の最短手順

分割済みスプライトからClipを作る

分割と Pivot の基準が揃ったら、ここからは静止画を実際に動かします。
手順は短く、Projectウィンドウで同じモーションに使う分割済み Sprite を複数選択し、そのままSceneへドラッグするだけです。
歩行なら歩行の6コマ、待機なら待機の6コマというように、ひとまとまりで選ぶのが出発点になります。
すると Unity は新しい Animation Clip の保存先を尋ね、その流れで Animator Controller も自動で用意し、ドラッグしたオブジェクトに Animator を割り当てます。
1枚ずつ置いてから手作業で差し替えるより、この流れのほうがコマ順を保ったまま一気に形になります。

ここで気をつけたいのは、選択順とフレーム名の並びです。
ファイル名が walk_0 walk_1 walk_2 のように素直に並んでいれば、そのまま意図通りの順番でクリップになりやすく、作業が止まりません。
逆に命名が前後していると、足が前に出た次の瞬間に戻るような不自然な再生になります。
絵の出来以前に、単にコマ順が崩れているだけという場面は実務でもよくあります。

Scene に置いた直後は、まず Game ビューで輪郭のにじみ、キャラ全体の微揺れ、動きの速さ を見ます。
ドット絵アニメは、止め絵では気づかなかったズレが再生すると一気に表面化します。
輪郭がふわつくならフレーム位置か表示位置、キャラ全体が上下左右に震えるなら Pivot、一定のテンポに見えないならコマの配分や Sample Rate を疑う、という切り分けで見ると原因が追いやすくなります。
フレームサイズが揃っていないケースでも、腕や髪ではなく体全体が揺れて見えるので判別できます。

Animation Clip ができたら、次は Sample Rate を調整します。
Unity の AnimationClip はデフォルトで 60 を基準に扱えますが、ドット絵アニメでは見た目のテンポ調整が欠かせません。
実務ではコマの存在感を残すために 6〜12FPS 程度を経験則として使うケースが多いですが、これは公式の必須値ではなくプロジェクトや表現意図に合わせて調整してください。
例えば 32x32 の歩行6フレームでは、Sample Rate を 8〜12 の間で試し、移動量との関係で最適値を決めると管理が楽になります。

再生確認では、単に速いか遅いかだけでなく、等速に見えるかも見逃せません。
歩行6コマのうち、接地のコマだけ長く感じる、逆に空中側だけ流れて見えるといった違和感は、フレーム内容と速度設定の噛み合わせで起こります。
キャラが前進しているのに脚だけ空回りして見える場合は、移動量に対して Sample Rate が低いことが多く、足踏みなのにせわしない場合は高すぎることが多いです。
数値の正解を先に決めるというより、1歩の重さをどこに置くかで決めるとまとまりやすくなります。
Animation Clip の Sample Rate はデフォルトで 60 ですが、ドット絵ではコマの存在感を残すために、実務やコミュニティの経験則として 6〜12 FPS 程度がよく試されます。
これは Unity の公式が必ずしも推奨する数値ではなく、表現意図や移動量に合わせて調整してください。
たとえば 32x32 の歩行6フレームでは、8〜12 の範囲を試して最適値を見つけると管理が楽になります。
Loop Time を OFF にしたクリップでは、終わったあとに止まってほしい姿になっているかが判断材料になります。
攻撃や被弾は、最後の1コマが次の状態への受け渡しになります。
そこが中途半端だと、再生終了後の見た目が落ち着きません。
たとえば被弾でのけぞったあとに通常立ちへ戻す設計なら、OFF の単発クリップとして切り、Animator 側で次ステートへ渡す前提にすると整理しやすくなります。

この段階でも、再生結果に違和感が出たら 輪郭のにじみ、wobble、等速性 の3点に戻って確認します。
ループの継ぎ目でだけ揺れるなら終端と始点の差、全編で揺れるなら Pivot かフレームサイズ、動きが引っかかるなら Sample Rate とコマ配分です。
見た目の違和感を「アニメが変」とまとめてしまうと直しどころがぼやけますが、どの種類の崩れなのか切り分けると修正は短時間で済みます。
静止画を置いただけの状態から、ゲーム内で自然に繰り返す動きまで持っていく流れは、この3つの設定でほぼ決まります。

よくある失敗と対策

PPU混在

ドット絵で最初につまずきやすいのが、素材ごとに PPU（Pixels Per Unit）が混在したまま進めてしまうことです。
同じ 32x32 の絵でも、あるスプライトは 32、別のスプライトは 100 という状態で置くと、Unity 上の見た目サイズが揃いません。
キャラだけ大きい、武器だけ小さい、当たり判定を合わせると見た目が崩れる、といった症状はこの段階で発生します。
絵の解像度が同じでも、Unity にとっての 1 unit あたり何ピクセルとして扱うかが違えば、別スケールの素材として解釈されるからです。

この崩れ方は、後から個別に Scale を触って帳尻を合わせ始めるとさらに複雑になります。
Hierarchy 上では合って見えても、アニメ差し替えや別モーション追加のたびにズレが再発します。
私はこの手の案件では、プロジェクトの初期段階で「キャラ」「タイル」「UI 以外のゲーム内スプライト」は同じ PPU に固定し、Import した時点で必ずその値に揃える運用にしています。
スプライト単位で例外を増やすより、設計で先に縛ったほうが後工程の事故が減ります。

すでに素材が増えている場合は、見た目サイズが合わない原因を Transform の Scale ではなく Import Settings 側の PPU に戻って洗い直したほうが早く収まります。
Scale で無理に合わせる方法は、その場では整って見えても、Pixel Perfect と組み合わせたときに輪郭の安定感を失いやすく、アニメーション差し替えでも破綻します。

Filter/Compressionのミス

ドット絵がぼやける原因として、Filter Mode と Compression の設定漏れも再発率が高い項目です。
Bilinear のまま取り込むと、拡大縮小時にピクセル同士が補間されて輪郭がにじみます。
さらに圧縮設定が入ると、1ピクセル単位で置いた色の境界が鈍り、シャドウや外周線が薄く溶けたような見え方になります。
特に少ない色数で作ったスプライトは影響が出やすく、線のキレが先に失われます。

対策は明快で、ドット絵のスプライトは Point を基準にし、Compression もにじみを生まない設定に揃えることです。
エディタ上で綺麗でも、プラットフォーム別オーバーライドで別の圧縮設定が入っていると、実機でだけ色が崩れることがあります。
PC 向けだけ見て進めると見落としやすいので、Import Settings の本体だけでなくプラットフォーム個別の項目まで一列で確認したほうが事故を切り分けやすくなります。

見た目の症状としては、「拡大したら滲む」だけでなく、「静止画では平気なのに動かすと輪郭が柔らかく見える」という出方もあります。
このとき移動処理を疑う前に、テクスチャ設定が Point になっているか、圧縮で色境界が丸くなっていないかを先に潰すと、修正箇所が一気に絞れます。

フレームサイズ不統一とwobble

アニメーションでキャラがふらついて見えるとき、原因がモーションではなく フレームごとのサイズ不統一であることは珍しくありません。
1コマごとのセルサイズや余白が微妙に違うと、同じ Pivot を設定しても見た目の重心が揺れます。
足元が固定されているつもりでも、実際にはコマごとに bounding が変わり、頭や肩の位置がわずかに上下左右へ動いて見えます。
いわゆる wobble は、この「絵のズレ」と「分割基準のズレ」が重なって出ることが多いです。

対策は、Sprite Editor で Grid Slice を使ってセル寸法を固定し、Pivot も全フレームで統一することです。
Automatic に任せると、透明余白の取り方次第でコマの切り出し範囲が揺れます。
均等配置のシートなら Grid By Cell Size か Grid By Cell Count に寄せたほうが、フレームの基準がブレません。
ドット絵の歩行や待機で気になるのは、派手な腕振りよりも足元の接地感なので、各コマを並べて見たときに足先と地面の関係が固定されているかを先に見ると判断が速くなります。

半ドット単位の移動も、wobble を強く見せる原因です。
スプライト自体が綺麗でも、Transform の位置が 1 ピクセル未満の刻みで変化すると、描画時に輪郭が揺れて見えます。
PPU が 100 なら 1 ピクセルは 0.01 unit なので、移動量や座標を 1/PPU の整数倍に量子化しておくと、チラつきの発生箇所を抑えられます。
アニメの wobble とカメラ由来の揺れは見分けがつきにくいので、まずキャラ単体を停止カメラで見て、それでも揺れるならフレームと Pivot、動かしたときだけ揺れるなら座標の量子化を疑うと整理しやすくなります。

Cinemachine併用の注意点

Cinemachineを入れた途端に、静止時は綺麗なのに追従中だけ画面がわずかに上下して滲む、という現象も初心者がはまりやすいところです。
原因は、Pixel Perfect CameraとCinemachineがどちらも orthographic size に関わるため、制御が競合することがあるからです。
画角の計算を複数の側が持つと、キャラ追従そのものは動いていても、ピクセル基準の拡大率がフレームごとに揺れ、結果としてドットの輪郭が安定しません。

私もCinemachineを導入した直後に、カメラの追従自体は滑らかなのに、画面の見え方だけが微妙に上下してにじむ場面に当たりました。
キャラや背景の座標をいくら見直しても収まらず、最終的には「何が画角を決めているか」を整理して解消しました。
手順としては、Pixel Perfect Cameraを基準にするのか、Cinemachine Virtual Camera側の見え方を軸にするのかを先に決め、両方に同じ役目を持たせない形へ寄せました。
その内容は後で再利用できるようにメモ化してあり、以後は導入時に最初に確認する項目になっています。

Cinemachine Pixel Perfect拡張を Virtual Camera に追加すると、この競合は整理しやすくなります。
Pixel Perfect の設定を前提に、適切な orthographic size を計算して適用する役割を持つためです。
ただし、ブレンド中は一時的にピクセルパーフェクトでなくなる場面があり、Target Group と Framing Transposer の組み合わせでは不規則な動きが出ることもあります。
追従の見栄えを優先したい場面と、ドットの安定を優先したい場面の線引きを先に決めておくと、設定の迷子になりません。

スナップ設定の遡及と丸め直し

Pixel Perfect まわりで見落としやすいのが、Snap 設定を有効にしても、既に配置済みのオブジェクトの座標までは自動で直らないという点です。
設定を入れた瞬間に過去の端数座標まで揃うわけではないので、以前に置いた Tile、キャラ、装飾オブジェクトが 0.003 や 0.127 のような中途半端な位置に残っていると、そこだけチラつきが続きます。
「設定は合っているのに一部だけ滲む」というときは、この残留端数が原因であることが多いです。

対策は、配置済みオブジェクトを グリッドに再スナップし、Transform を 1/PPU 刻みに丸め直すことです。
PPU が 100 なら 0.01 刻み、というようにプロジェクトの基準へ戻します。
Tilemap は揃っているのにプレイヤーやエフェクトだけ揺れる場合、Prefab 化前の座標や生成位置の計算結果に端数が残っていることがあります。
ここを放置すると、カメラやアニメ側の調整に時間を使っても症状が消えません。

移動処理でも同じで、Velocity や補間で半端な移動量が出ると半ドット移動のチラつきが発生します。
ドット絵では「なめらかに動くこと」より「ピクセル境界に乗ったまま動くこと」のほうが見た目の安定につながります。
1 フレームごとの移動量を 1/PPU の整数倍へ揃え、描画側も整数スケールを崩さないようにすると、静止時は綺麗なのに走り出すとだけ滲む現象を抑えられます。
設定を入れることと、既存の座標を清算することは別作業として扱ったほうが、原因の切り分けが明確になります。

次にやること｜タイルマップ・アニメーション・解像度設計

静止画が崩れずに置ける段階まで来たら、次は「1体だけ、短い動きだけ、表示条件だけ固定」で動作確認へ進むのが近道です。
私はここで欲張って背景やUIまで同時に触るより、まずキャラ1体の歩行を通して、絵・アニメ・表示解像度のつながりを一度通しで確かめます。
見た目の違和感はアニメの問題に見えて、実際は解像度設計やクロップ設定にあることが珍しくありません。

横スクロール前提で画面基準を 320x180 に置いた案件では、Android の 2340x1080 を想定してGameビューを切り替え、Crop の設定差で UI の端がどこまで押し出されるかを先に見ました。
キャラの歩行自体は問題なくても、表示領域の取り方ひとつでライフ表示やボタンの余白感が変わるので、動かし始める段階でここまで見ておくと後戻りが減ります。

最小構成での実験プラン

最初の実験は、32x32 のキャラ1体で 6 フレームの歩行だけに絞るのがおすすめです。
分割済み Sprite をシーンに置き、Project ウィンドウで歩行に使うコマを複数フレーム選択して、そのまま Hierarchy のキャラへドラッグします。
これで Animation Clip の作成に進めるので、待機や攻撃まで一気に作らず、歩行だけを先に完成させます。

この段階では、Animation Clip を作ったあとに Sample Rate を触る前提で見ておくと作業が安定します。
Unity の初期状態では 60 ベースでタイムラインが進むため、ドット絵の歩行をゆっくり見たいときほど編集感覚がずれやすくなります。
6 フレーム歩行なら、1 コマごとの見え方を確認しながら Sample Rate を下げて、コマ送りの感覚とタイムラインの感覚を揃えたほうが、足の接地や腕の戻りを詰めやすくなります。

Loop Time もここで切り替えて試します。
歩行は Loop Time を ON にして循環させ、止め絵や単発モーションの確認用クリップは OFF にしておくと、クリップごとの役割が明確になります。
歩行を無限再生にした状態で輪郭の揺れや接地のズレがないかを見ると、1 周だけ再生したときには見逃した違和感が出やすいのが利点です。

設計メモの固定

動きが一度でも成立したら、PPU・Reference Resolution・1タイルのサイズをその場で固定しておくべきです。
ここを頭の中だけで覚えていると、数日後に Tilemap を置き始めたとき、キャラだけ縮尺が合わない、UI だけ余白感が違う、といったズレが起きます。
チーム制作ではもちろん、個人制作でも未来の自分がいちばん容赦なく混乱します。

私が毎回残すのは、キャラの基準サイズ、1 タイルのピクセル寸法、ゲーム画面の基準解像度、UI をどの解像度前提で置くかの4点です。
これが揃っていると、あとから素材が増えても「この 32x32 キャラは 1 マス想定なのか、2 マス想定なのか」で迷いません。
ドット絵ゲームは、1枚ごとの絵作りより、共通ルールを崩さないことのほうが画面全体の完成度に直結します。

TilemapとAnimatorに進む

歩行クリップが狙った見え方になったら、次は背景側にTilemapを入れて、キャラと地形のスケール感を合わせます。
GameObject > 2D Object > Tilemapで土台を作り、キャラが立つ床だけでも先に敷くと、空中で歩いていたときには気づかなかった頭身バランスや接地の違和感が見えてきます。
1 タイルのサイズを先にメモ化しておく意味は、ここで効いてきます。

同時にAnimator Controllerで状態遷移も組み始めます。
まずは待機と歩行の2状態だけで十分です。
待機は静止、歩行は先ほど作った6フレームのクリップを使い、入力や速度の有無で 待機→歩行 が切り替わる形にすると、ゲームらしい確認が一気に進みます。
シーンに置いた Sprite を起点に複数フレーム選択から Animation Clip を作成し、そのクリップを状態として分けていく流れにすると、素材整理と実装整理が同じ方向を向きます。

ここでも Loop Time の使い分けが効きます。
待機を1枚絵ベースで置くならループ不要ですし、呼吸のような微動を入れるなら ON にします。
歩行は ON が前提です。
Sample Rate も待機と歩行で同じにする必要はなく、歩行だけテンポを詰める形でも構いません。
ドット絵では「全部同じ設定に揃える」より、「その動きが何を見せたいか」でクリップ単位に決めたほうが画面に芯が出ます。

複数解像度のGameビュー検証

アニメが動いたら、必ずGameビューで複数解像度に切り替えて見ます。
PC 向けの代表的な横長画面だけでなく、スマホ縦横を含めて確認すると、黒帯の出方、にじみの有無、UI の収まり方を早い段階で把握できます。
静止画では問題なく見えたスプライトも、拡大率が変わると輪郭の印象が変わるので、歩行中の見え方まで含めてチェックしたほうが判断が速いです。

横スク 320x180 の設計で Android 2340x1080 を想定したときは、整数拡大の見た目そのものより、Crop の違いで画面上下左右のどこが削られるかが気になりました。
背景の見え方より先に UI の切れ方が変わるので、ライフバーや会話ウィンドウを画面端に寄せる設計なら、この時点で余白ルールまで決めておいたほうが安全です。
黒帯を許容するのか、表示範囲を優先して切るのかで、同じ素材でも完成画面の印象は別物になります。

検証時は、キャラだけを見ずに「床タイルとの接地」「画面端でのUIの残り方」「移動中の輪郭の安定」を1セットで見ます。
Pixel Perfect が効いていても、解像度切り替えのたびに画面構成の見え方は変わります。
だからこそ、静止画表示の成功をそのまま完成扱いにせず、分割済み Sprite をシーンに置くところから Animation Clip 作成、Sample Rate 調整、Loop Time の切り替え、そして複数解像度検証までを一続きで通すと、次の実装で迷いません。