伝説のチーフアーキテクトが解き明かす：VB.NET高DPI対応の深層と極限レイアウト設計
現場のエンジニアなら一度は絶望したことがあるはずだ。
「フルHDで作った社内業務システムのWindowsフォームアプリを、4Kモニターや最新のノートPC（スケーリング150%や200%）で起動したら、文字が切れている」「ボタンが重なっている」「Gridの幅が勝手に爆発している」――。
レガシーなVBAマクロからの移行組や、VB 6.0時代の呪縛を引きずったコードベースで構築されたシステムにおいて、高DPI環境への適応は避けて通れないパンドラの箱となっている。
今回は、.NET Frameworkおよび.NET Core/5+におけるWindowsフォーム（WinForms）のレイアウトエンジン、特に `AutoScaleMode` の本質と、メモリ管理・API連携を視野に入れた「現場で生き残るための極限の知見」を叩き込む。
—
1. なぜUIは崩壊するのか？：DPIスケーリングのメカニズム
WindowsのDPI（Dots Per Inch）スケーリングは、高解像度ディスプレイでUIが米粒のように小さく表示されるのを防ぐための機能だ。
しかし、VB.NETのWindowsフォームは、その誕生背景（Win32 APIのラッパー）に起因し、デフォルトではピクセル単位のハードコードに依存しやすい。
ここで重要になるのが、フォームが生成される際のオブジェクトのライフサイクルである。
1. コンストラクタの実行 (`New`)
2. `InitializeComponent()` の呼び出し：ここでデザイナーが吐き出したコントロールの初期プロパティ（`Size`, `Location` 等）が設定される。
3. `AutoScaleMode` の評価とスケーリングの適用：親コンテナのDPIと、コントロールがデザインされた時点のDPI（`AutoScaleDimensions`）の比率に基づき、座標とサイズが動的に再計算される。
このライフサイクルのどこか一つでも狂いが生じると、二重スケーリング（DPI仮想化によるボケ）や、レイアウトの破綻が発生する。
—
2. `AutoScaleMode` の3つの選択肢と「Dpi」一択の理由
フォームのプロパティにある `AutoScaleMode` には以下の3つが存在するが、現代の開発において迷う余地はない。`Dpi` 以外を選ぶことは、自ら地雷を踏みに行く行為に等しい。
- `None`: スケーリングを行わない。4K環境ではUIがゴミのように小さくなる。即刻封印すべき。
- `Font`: システムのフォントサイズ（通常は9pt等のDPIスケーリングに連動）を基準にする。一見良さそうに見えるが、ユーザーがOSのカスタムフォントやClearTypeの設定を変更しただけでレイアウトが崩壊する致命的な欠点がある。
- `Dpi` (推奨): モニター自体の物理的なDPI解像度を基準にスケーリングを行う。マルチモニター環境でウィンドウを移動させた際のスケーリング追従性においても最も優れている。
.NET 6/7/8以降におけるマニフェストの設定
コード側でいかに `AutoScaleMode = AutoScaleMode.Dpi` と指定しても、アプリケーションの実行マニフェスト（`app.manifest`）側でPer-Monitor V2（HighDPI対応）が有効になっていなければ意味がない。
プロジェクトファイル（`.vbproj`）に以下の設定が明記されているか確認せよ。
—
3. 実践：コードによる動的コントロール配置とメモリ最適化
デザイナー頼みのレイアウトは、動的なデータバインドや複雑な業務画面においては破綻する。真に堅牢なシステムは、コードベースでレイアウトのライフサイクルを完全に制御する。
以下に、高DPI環境下でも絶対に崩れない、パネルとテーブルレイアウトを用いた堅牢なフォーム初期化のサンプルコードを示す。
Public Class SecureForm
‘ パフォーマンスとメモリリーク防衛のためのコンポーネント定義
Private ReadOnly _mainTableLayout As New TableLayoutPanel()
Private ReadOnly _actionButton As New Button()
Private ReadOnly _dataGrid As New DataGridView()
Public Sub New()
‘ この呼び出しは Windows フォーム デザイナーで必要です。
InitializeComponent()
‘ 【極限知見】AutoScaleModeの明示的指定とDPIスケーリングのフック
Me.AutoScaleMode = AutoScaleMode.Dpi
Me.AutoScaleDimensions = New SizeF(96.0!, 96.0!) ‘ 基準DPI（96 = 100%）
‘ 独自のレイアウト構築メソッドを呼び出し
InitializeCustomLayout()
End Sub
Private Sub InitializeCustomLayout()
‘ 描画ちらつき（フラッシュ）を極限まで抑制するためのダブルバッファリング有効化
Me.SetStyle(ControlStyles.OptimizedDoubleBuffer Or _
ControlStyles.AllPaintingInWmPaint Or _
ControlStyles.UserPaint, True)
Me.UpdateStyles()
‘ TableLayoutPanelによるグリッドフリーな絶対防衛レイアウト
_mainTableLayout.Dock = DockStyle.Fill
_mainTableLayout.ColumnCount = 1
_mainTableLayout.RowCount = 2
_mainTableLayout.RowStyles.Add(New RowStyle(SizeType.Percent, 85.0!))
_mainTableLayout.RowStyles.Add(New RowStyle(SizeType.Percent, 15.0!))
‘ DataGridViewの設定（高DPIでのスケーリング考慮）
_dataGrid.Dock = DockStyle.Fill
_dataGrid.AutoSizeColumnsMode = DataGridViewAutoSizeColumnsMode.Fill
‘ ボタンの設定
_actionButton.Text = “一括処理を実行”
_actionButton.Dock = DockStyle.Fill
‘ コントロールの安全なアタッチ
_mainTableLayout.Controls.Add(_dataGrid, 0, 0)
_mainTableLayout.Controls.Add(_actionButton, 0, 1)
Me.Controls.Add(_mainTableLayout)
End Sub
‘ 【極限知見】マネージド・アンマネージド資源の厳密な解放 (IDisposableパターン)
Protected Overrides Sub Dispose(disposing As Boolean)
Try
If disposing Then
‘ コントロールコレクションのクリアと明示的破棄
‘ これを怠ると、特に古い.NET Framework環境でGDIオブジェクトのリークを引き起こす
If _mainTableLayout IsNot Nothing Then
_mainTableLayout.Controls.Clear()
_mainTableLayout.Dispose()
End If
If _actionButton IsNot Nothing Then _actionButton.Dispose()
If _dataGrid IsNot Nothing Then _dataGrid.Dispose()
End If
Finally
MyBase.Dispose(disposing)
End Try
End Sub
End Class
—
4. レガシー環境・API連携における「落とし穴」
既存の巨大なVB.NETシステム（主に .NET Framework 4.5~4.8）を保守している現場では、社内ニッチなWin32 APIを直接叩いているケースが多々ある。
例えば、ウィンドウのハンドル（HWND）を操作して独自描画を行っている場合、高DPI環境下では座標系のズレ（Logical Pixel vs Physical Pixel）が発生する。これを解決するには、Windows APIの `GetDpiForWindow` や `ClientToScreen` を適切に呼び出し、座標変換を行う必要がある。
Imports System.Runtime.InteropServices
Public Module NativeMethods
‘ Windows 10 (1607以降) または Windows 11 で有効なDPI取得API
Friend Function GetDpiForWindow(hWnd As IntPtr) As UInteger
End Function
”’
”’
Public Function GetCurrentScaleFactor(hWnd As IntPtr) As Single
If Environment.OSVersion.Version.Major >= 10 Then
Dim dpi As UInteger = GetDpiForWindow(hWnd)
If dpi > 0 Then
Return dpi / 96.0F ‘ 96DPIを基準(1.0)とした倍率を返す
End If
End If
Return 1.0F
End Function
End Module
このスケーリング倍率を取得し、カスタム描画処理や、フォントサイズの動的調整に組み込むことで、レガシーなAPI連携コードであっても高DPIの波に完全に対応させることが可能となる。
—
5. チーフアーキテクトからの総括
高DPI対応を「後回しにできる見た目の問題」として片付けているプロジェクトは、やがてマルチディスプレイ環境の普及によってユーザーからのクレームの嵐にさらされることになる。
- `AutoScaleMode` は迷わず `Dpi` を選択する。
- レイアウトはハードコードの座標指定を捨て、`TableLayoutPanel` や `Anchor` / `Dock` を駆使した流体レイアウトへ移行する。
- GDIリソースの枯渇を防ぐため、フォーム破棄時には `Dispose` を徹底し、メモリライフサイクルを支配する。
技術の本質を見極め、コードの隅々にまで意図を宿すこと。それこそが、レガシーとモダンを繋ぐ真のプロフェッショナルの仕事である。あなたの書くVB.NETコードが、過酷な現場で美しく稼働し続けることを願ってやまない。
