WinFormsの高DPI対応 ── 4Kモニターでぼやける・崩れる原因と現実的な対処

「新しいノート PC に入れ替えたら、業務アプリの文字がにじんで読みにくい」「4K モニターにつないだらボタンとラベルが重なった」「客先の 125% 環境でだけ帳票プレビューが崩れる」。ここ数年、PC の入れ替え時期にこの種の相談が急増しています。フル HD を超える高解像度ディスプレイと 125〜200% の表示スケーリングが業務用 PC でも標準になり、96 DPI・100% 表示の時代に作られた WinForms アプリが、そのままでは快適に表示できなくなったためです。古い WinForms アプリの保守相談として、今いちばん頻度が高いテーマと言ってよいと思います。

厄介なのは、症状が「ぼやける」「崩れる」「一部だけ小さい」とばらばらに見えることです。実際には原因は数種類に整理でき、どの症状がどの原因に対応するかが分かれば、直し方も「どこまでやるか」の判断もできます。この記事では、Windows の DPI スケーリングの仕組みと DPI 認識モードを土台に、WinForms アプリ（.NET / .NET Framework 両方）の高DPI対応を、設定方法・定番の罠・段階的な対応戦略まで実務目線で整理します。

1. まず結論

• 高DPI環境で古いアプリがぼやけるのはバグではなく、OS の救済措置（DPI 仮想化）です。DPI 非対応のアプリを Windows が 96 DPI で描かせてからビットマップ拡大しているので、レイアウトは崩れない代わりににじみます。¹
• 逆に「くっきりしているのに崩れる」のは、DPI 対応を宣言しているのにレイアウトが追従できていない状態です。ぼやけと崩れは原因が正反対なので、対処の前にどちらなのかを見分けてください。
• 対応の第一歩は、自分のアプリが今どの DPI 認識モード（Unaware / System Aware / Per-Monitor V2）で動いているかを把握することです。マニフェスト・app.config・API 呼び出しのどれで（あるいは何も）宣言しているかを確認します。²
• 設定方法は世代で分かれます。.NET（Core 3.1〜.NET 8）ならプロジェクトファイルか Application.SetHighDpiMode、.NET Framework 4.7 以降なら app.config、4.6 以下はマニフェストで System Aware までが現実的なラインです。³⁴
• デザイナーは必ず 100%（96 DPI）のモニターで開くこと。150% 環境でフォームを開いて保存すると AutoScaleDimensions が書き換わり、チーム全員のレイアウトが壊れる定番事故になります。⁵
• 全面対応（Per-Monitor V2）は工数がかかります。「System Aware で主モニターだけくっきり」を第一段階、PMv2 完全対応を第二段階とする 2 段構えで、アプリの寿命と利用環境に見合った投資をするのが現実的です。
• 自社で改修できない・間に合わない場合の暫定策として、exe のプロパティ→互換性から利用者側で上書きできる「高DPI設定」も知っておくと、問い合わせ対応が一段楽になります。⁶

2. なぜぼやけるのか ── DPI仮想化の仕組み

Windows の表示スケーリングは 96 DPI を 100% とする倍率で表現されます。125% = 120 DPI、150% = 144 DPI、200% = 192 DPI です。4K（3840×2160）の 27 インチモニターを 100% で使うと文字が小さすぎるため、Windows は既定で 150% 前後を推奨してきます。つまり高解像度ディスプレイの普及は、そのまま「96 DPI 以外で動く環境の普及」を意味します。

問題は、古いデスクトップアプリの多くが「画面はずっと 96 DPI」という前提で書かれていることです。座標もフォントもアイコンもピクセル直書きで、150% 環境でそのまま描画すると、すべてが物理的に 2/3 の大きさに見えてしまいます。そこで Windows は、DPI 対応を宣言していないアプリには「画面は 96 DPI だ」と嘘をつき、アプリが 96 DPI のつもりで描いた結果をビットマップとして拡大表示します。これが DPI 仮想化（ビットマップストレッチ）です。¹

この仕組みを踏まえると、症状と原因はきれいに対応します。最初の切り分けにこの表を使ってください。

重要なのは、「ぼやけている」アプリはむしろ壊れていないということです。OS の救済措置が正しく効いています。改修とは、この救済措置を断って「自分でスケーリングします」と宣言する（＝DPI 認識モードを上げる）ことなので、宣言した瞬間にレイアウトの問題が全部自分の責任になります。「とりあえず PMv2 にしてみたら余計にひどくなった」という相談はこの構図で起きています。

3. DPI認識モードの整理

アプリはプロセス（正確には Windows 10 以降はトップレベルウィンドウ）単位で、自分がどこまで DPI を扱えるかを OS に宣言します。モードは実質 4 つです。¹⁶

Per-Monitor V1 と V2 の差は実務では決定的です。V1 は「通知は来るがあとは全部自分で」という素の Win32 向けの仕組みで、WinForms から使う理由はありません。V2 はタイトルバー・スクロールバー・メニューなどの非クライアント領域を OS が自動でスケールし、WinForms 側のフレームワーク支援（後述）も V2 前提で作られています。Per-Monitor を選ぶなら V2 一択です。⁶

もうひとつ、GDI スケーリング（DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED、Windows 10 1809〜）というモードがあります。アプリとしては Unaware のまま、GDI で描かれるテキストや図形だけ OS がベクターレベルで拡大してくれる改良版のビットマップ拡大です。⁶ コードを一切変えずに文字のにじみだけ軽減できる可能性があるため、改修できないアプリの暫定策として覚えておく価値があります（4.3 節）。

なお、Windows 10 1607 以降はトップレベルウィンドウ単位で異なるモードを混在させる Mixed-Mode もあり、「メイン画面だけ PMv2、直しきれないダイアログは Unaware のまま OS に拡大させる」という段階移行が Win32 レベルではサポートされています。⁷ WinForms から気軽に使えるものではありませんが、「全画面を一度に直さなくてもよい」という設計思想は 7 章の段階戦略につながります。

4. 設定方法 ── 世代別の正解

自分のアプリがどの世代かで、DPI 認識モードの宣言方法が違います。ここを取り違えると「設定したのに効かない」で時間を溶かすので、世代ごとに分けて書きます。

4.1 .NET (Core 3.1〜.NET 8) の WinForms

.NET では Application.SetHighDpiMode が用意されており、テンプレートが生成する ApplicationConfiguration.Initialize()（.NET 6 以降）がこれを呼び出します。既定は SystemAware です。³ 設定はプロジェクトファイルに書くのが推奨で、Visual Studio のデザイナーもこの設定を参照します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <!-- SystemAware（既定）/ PerMonitorV2 / DpiUnaware / DpiUnawareGdiScaled -->
    <ApplicationHighDpiMode>PerMonitorV2</ApplicationHighDpiMode>
  </PropertyGroup>
</Project>

注意点として、プロジェクトファイルの ApplicationHighDpiMode と ApplicationConfiguration.Initialize() は .NET 6 で入った仕組みです。³ .NET Core 3.1 / .NET 5 のプロジェクトではこのプロパティを書いても効かないので、次のように Application.SetHighDpiMode をコードで直接呼びます（ApplicationConfiguration.Initialize() を使わない古いスタイルの Main でも同様です）。どちらの場合も、ウィンドウを 1 つでも作る前に呼ぶ必要があります。

[STAThread]
static void Main()
{
    Application.SetHighDpiMode(HighDpiMode.PerMonitorV2);
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new MainForm());
}

.NET 6 以降は PMv2 時のコンテナーコントロールや MDI 子ウィンドウのスケーリングが改善されており、「200% のモニターから 100% のモニターへ移すとコントロールがずれる」といった .NET 5 までの問題がかなり解消されています。³ PMv2 で本気の対応をするなら、.NET Framework より新しい .NET のほうが明らかに戦いやすい、というのが実感です。.NET Framework からの移行を検討する材料は「.NET Framework から .NET への移行前チェックリスト」にまとめています。

4.2 .NET Framework 4.7以降

.NET Framework は 4.7 で高DPI対応が大きく強化されました。コントロールのスケーリング改善、DPI 変更イベント（DpiChanged 系）、DeviceDpi プロパティなどが入っています。ただしオプトインで、次の 2 点をセットで設定して初めて有効になります。⁴

まず、マニフェストで Windows 10 互換を宣言します（これがないと 4.7 の高DPI機能自体が有効になりません）。

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
  <application>
    <!-- Windows 10 互換宣言 -->
    <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
  </application>
</compatibility>

次に、app.config の System.Windows.Forms.ApplicationConfigurationSection で DPI 認識モードを宣言します。

<configuration>
  <System.Windows.Forms.ApplicationConfigurationSection>
    <add key="DpiAwareness" value="PerMonitorV2" />
    <!-- 自前でスケーリング済みの画面がある場合は個別機能をオフにできる -->
    <!-- <add key="EnableWindowsFormsHighDpiAutoResizing" value="false" /> -->
  </System.Windows.Forms.ApplicationConfigurationSection>
</configuration>

あわせて Main の先頭で Application.EnableVisualStyles() を呼んでいることを確認してください。ここで注意が 1 つあります。昔からの方法であるマニフェストへの <dpiAware> / <dpiAwareness> 記述は、app.config の設定を上書きしてしまうため、4.7 の WinForms では併用しないのが公式の推奨です。⁴ 過去に System Aware 化のためにマニフェストへ <dpiAware>true</dpiAware> を書いたアプリを 4.7+PMv2 へ上げるときは、マニフェスト側の宣言を整理するところから始めます。「app.config に書いたのに効かない」の原因はたいていこれです。

4.3 .NET Framework 4.6以下・VB6/MFC混在

4.6 以下の WinForms には PMv2 を支援するフレームワークコードがなく、無理に宣言してもレイアウト崩れを自力で全部処理することになります。この世代の現実解は マニフェストで System Aware を宣言するところまでです。OS レベルの宣言はマニフェストが推奨手段で、<dpiAware>（Vista〜）と <dpiAwareness>（Windows 10 1607〜）を併記すると新旧 OS の両方で意図どおりに解釈されます。²

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">system</dpiAwareness>
  </asmv3:windowsSettings>
</asmv3:application>

System Aware にすると、起動時の主モニター DPI に合わせて WinForms の自動スケーリング（5 章）が一度だけ働き、主モニター上ではくっきり表示されます。AutoScaleMode.Font が正しく設定されたフォームなら、この宣言だけでかなり見られる状態になることが多いです。なお SetProcessDpiAwareness などの API で実行時に宣言する方法もありますが、ウィンドウ作成後には変更できず、マニフェストでの宣言が公式に推奨されています。⁸ VB6 や MFC のコードが混在するアプリでも考え方は同じで、exe のマニフェストでプロセス全体のモードが決まります（MFC 自体には自動スケーリング支援がないため、System Aware 宣言後の画面点検は必須です。この世代の資産の扱いは「WindowsのMFCとは」も参照してください）。

改修そのものができない場合の利用者側の暫定策も紹介しておきます。exe を右クリック→プロパティ→互換性タブ→「高DPI設定の変更」で、そのアプリの DPI スケーリングを上書きできます。「高DPIスケール設定の上書き」を「システム」にすると DPI 仮想化を強制（＝崩れないがにじむ）、「システム（拡張）」にすると 3 章で触れた GDI スケーリングが適用され、GDI 描画のテキストだけくっきりします。⁶ 万能ではありませんが、「客先で今日なんとかしたい」ときに電話口で案内できる手段として、サポート手順書に入れておく価値があります。

5. AutoScaleModeとデザイナーの罠

WinForms には DPI 認識モードとは別に、フォーム自身の自動スケーリング機構があります。ここを理解していないと、System Aware にしても正しくスケールしません。

仕組みはこうです。デザイン時に各フォーム（ContainerControl）は、スケーリングの基準を AutoScaleMode に、デザインした環境での基準値を AutoScaleDimensions に記録します。実行時には現在の環境の値（CurrentAutoScaleDimensions）と比較し、差があれば子コントロールをまとめて拡大縮小します。⁹ つまり「デザイン時と実行時の環境差」を吸収する仕組みであり、基準値はコード（Designer.cs）に焼き込まれます。

AutoScaleMode の選択肢は実質 2 つです。

迷ったら Font です。注意点として、基底フォームと派生フォームで異なるモードを混在させると予期しない結果になることが公式にも明記されています。⁹ フォーム継承を使っているアプリでは、全フォームのモードをそろえる棚卸しが先です。

そして本題の罠です。AutoScaleDimensions は「デザインした環境の値」を記録する仕組みなので、150% のモニターで Visual Studio のデザイナーを開いてフォームを保存すると、Designer.cs の AutoScaleDimensions が 150% の値（Font モードなら 6F, 12F が 9F, 18F など）に書き換わります。座標・サイズも 1.5 倍値で保存されます。このフォームを 100% 環境のメンバーがビルド・実行すると全体が縮んで表示され、差分レビューでは全コントロールの座標が変わった巨大な diff が出ます。「高DPIのノート PC を支給された新メンバーがフォームを 1 枚触ったら、リポジトリのレイアウトが壊れた」という、高DPI相談の定番事故です。

対策は原則 1 つ、デザイナーは 100%（96 DPI）で開くことです。Visual Studio 自体は DPI 対応アプリですが、WinForms デザイナー（.NET Framework 向け）は DPI 非対応のため、高DPIモニターで開くと黄色い情報バーが出て「100% スケーリングで Visual Studio を再起動する」よう促されます。⁵ このバーに従って DPI 非対応モードで再起動してからフォームを編集し、終わったら通常モードに戻す、という運用をチームの規約にしてください。コマンドラインなら devenv /noScale でも起動できます。なお .NET 6 以降のプロジェクトでは、Visual Studio 2022 17.8 以降でプロジェクトファイルに <ForceDesignerDPIUnaware>true</ForceDesignerDPIUnaware> を設定すると、VS 全体を再起動せずデザイナーのタブだけ DPI 非対応で動かせます（.NET Framework プロジェクトでは使えません）。⁵

チェックの仕組み化としては、「Designer.cs の AutoScaleDimensions が規定値以外になっている差分を CI や pre-commit で弾く」のが手軽で効きます。事故は起きてから直すより、コミットの入口で止めるほうが安上がりです。

6. 崩れの典型パターンと直し方

DPI 認識モードを上げた（または上げようとしている）ときに崩れる箇所は、だいたい次のパターンに収まります。

レイアウトの置き換えが工数の中心です。逆に言えば、もともと TableLayoutPanel と Dock で組まれた画面は、DPI 認識モードを上げてもほとんど手がかかりません。今後の新規画面は最初からレイアウトパネルで組む、を規約にするだけで将来の負債が減ります。

自前描画のスケーリングは、Control.DeviceDpi（.NET Framework 4.7+ / .NET）を基準に 96 DPI 換算の値を変換するのが基本形です。

public partial class ChartPanel : Panel
{
    // 96 DPI 基準の設計値を現在の DPI へ変換
    private int Scale(int value96) => value96 * DeviceDpi / 96;

    protected override void OnPaint(PaintEventArgs e)
    {
        using var pen = new Pen(Color.Navy, Scale(2));
        e.Graphics.DrawRectangle(pen,
            Scale(16), Scale(16), Scale(320), Scale(120));
    }

    // PMv2 ではモニター間移動で DPI が変わるので再描画を促す
    protected override void OnDpiChangedAfterParent(EventArgs e)
    {
        base.OnDpiChangedAfterParent(e);
        Invalidate();
    }
}

System Aware までなら DPI は起動時に固定なので Scale の導入だけで済みますが、PMv2 ではモニター間移動のたびに DeviceDpi が変わるため、キャッシュしているフォント・画像・レイアウト値を DpiChanged 系イベントで作り直す設計が必要です。⁴ 「自前描画の画面がいくつあるか」は、PMv2 対応の工数見積りにそのまま効いてきます。

サードパーティ製コントロールと ActiveX/OCX は、この改修の上限を決める要素です。コントロール自体が DPI 非対応なら、ホスト側でどう頑張ってもその画面は完全にはなりません。ベンダーの対応状況を確認し、更新が望めない ActiveX については「ActiveX/OCXを維持するか、ラップするか、置き換えるか」の判断表で扱いを決めてから、高DPI対応のゴールを設定してください。

7. 段階的な対応戦略 ── どこまでやるかの判断表

ここまでの内容を踏まえると、対応レベルは 3 段階に整理できます。全アプリを PMv2 にするのが技術的な理想ですが、改修予算とアプリの寿命を考えると、割り切りが正解になる場面は多いです。

判断の軸は 3 つです。アプリの寿命（あと何年使うか）、利用環境（全員が同じ固定デスクトップなら System Aware で実質完結します。ノート PC＋外部モニターの組み合わせが多いなら、モニター間移動のたびににじむ System Aware は不満が残ります）、そして改修予算。おすすめの進め方は、まず (2) を全アプリの標準として実施し、その過程で見つかった崩れの量とサードパーティ製コントロールの制約を材料に、(3) へ進むか・どの画面だけ進むかを決めることです。(2) は「宣言＋点検」が中心で失敗のリスクが小さく、それでいて利用者の体感は大きく改善します。

テストについても触れておきます。高DPI問題は開発機で再現しないことが多いので、次の環境を意図的に作って確認します。¹

• 異なるスケーリングのモニターを 2 枚つなぎ（例: 150% のノート内蔵＋100% の外部）、ウィンドウを行き来させる
• 主モニターを入れ替えてサインインし直してから起動する（System DPI はサインイン時に固定されるため、再サインインしないと切り替わりません）
• アプリ起動中にスケーリング設定を変更する
• リモートデスクトップで高DPIのクライアントから接続する（RDP はクライアント側の DPI が持ち込まれるため、「サーバーのコンソールでは正常なのに RDP だと崩れる」はよくある報告です）

「125% でだけ崩れる」という報告があったら、その倍率を実際に作って見るのが結局いちばん早い、というのが経験則です。仮想マシンでもスケーリング設定は変えられるので、100 / 125 / 150 / 200% の検証環境を用意しておくと切り分けが速くなります。

8. まとめ

高DPI環境での「ぼやける」は OS の救済措置（DPI 仮想化）、「崩れる」は中途半端な DPI 対応──この対応関係さえ押さえれば、症状から原因と打ち手を逆引きできます。設定方法は世代別に、.NET ならプロジェクトファイルの ApplicationHighDpiMode、.NET Framework 4.7 以降なら app.config（マニフェストの dpiAware と併用しない）、4.6 以下はマニフェストで System Aware まで。あわせて AutoScaleMode.Font の統一と、デザイナーは 100% で開くという運用規約が、地味ですが事故を最も減らします。

そのうえで、どこまでやるかは 7 章の 3 段階から。まず System Aware 化で主モニターをくっきりさせ、利用環境とアプリの寿命が見合うなら PMv2 へ──という 2 段構えが、当社が実際の改修案件でおすすめしている進め方です。UI フレームワーク自体を見直すタイミング（WPF は最初から DPI に強い設計です）に来ているなら、「WinForms / WPF / WinUI をどう選ぶか」もあわせて検討材料にしてください。手元のアプリがどの段階まで直せるか判断に迷う場合は、画面構成とコントロール構成の棚卸しからお手伝いできます。

関連記事

• WinForms / WPF / WinUI をどう選ぶか - 判断表
• ActiveX/OCXを維持するか、ラップするか、置き換えるか - 判断表
• .NET Framework から .NET への移行前チェックリスト
• WindowsのMFCとは - 何であって、今どう扱うべきか

関連する相談領域

合同会社小村ソフトでは、古い WinForms / MFC アプリの高DPI対応（現状調査、対応レベルの判断、レイアウト改修）や、PC 入れ替えに伴う表示不具合の原因調査、UI 刷新の相談を扱っています。

• 技術相談・設計レビュー
• 既存資産活用・移行支援
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。