Windows on ARM の普及で「ひとつの .NET Framework（Any CPU）アプリを、ARM64 ではネイティブ、Intel/AMD では軽量な x86 で動かしたい」という要望が急増しています。しかし Visual Studio の「Prefer native ARM64」と「Prefer 32‑bit」は排他的で、素直には両立できません。本稿はその背景と落としどころ、実装手順、現場で使える判断材料をまとめた実践的ガイドです。
.NET Framework アプリで実現したいことと現状の壁
要件の整理
- 1 本の Any CPU アセンブリを配りたい（保守と配布を簡素化）。
- ARM64 Windowsでは ARM64 ネイティブで実行して性能・省電力を取りたい。
- Intel/AMD Windows（x64）では x86 で動かしたい（x64 より軽量にしたい／ネイティブ依存が x86）。
Visual Studio 設定の実像
Visual Studio には Any CPU 実行時のふるまいを示すふたつのチェックがあります。
- Prefer native ARM64：ARM64 OS 上では 64‑bit（ARM64）として起動。
- Prefer 32‑bit：64‑bit OS 上でも 32‑bit（x86）として起動。
両者は 矛盾する命令なので同時に選択できません。結果として、「ARM64 では ARM64、その他は x86」という自動分岐を ひとつの Any CPU EXE だけで達成する仕組みは現在存在しません。チェックの排他は仕様であり、Visual Studio 2022（17.11 以降でも）変わりません。
まず押さえたい基礎：Any CPU とビット数選択ロジック
.NET Framework の EXE は、次の要素でプロセスのビット数が決まります。
- プラットフォーム ターゲット（Any CPU／x86／x64／ARM64）
- Prefer 32‑bit フラグ（EXE の CLR ヘッダーの 32BITPREFERRED）
- ARM64 優先（ARM64 OS のときに 64‑bit ARM を選ぶ挙動）
- OS の実アーキテクチャ（x86 / x64 / ARM64）
| プロジェクト設定 | OS | 起動ビット数 | 備考 |
|---|---|---|---|
| Any CPU（チェックなし） | x86 | x86 | 32‑bit OS では常に x86 |
| Any CPU（チェックなし） | x64 | x64 | 既定で 64‑bit |
| Any CPU（チェックなし） | ARM64 | ARM64 | ARM64 ネイティブ |
| Any CPU + Prefer 32‑bit | x64 | x86 | WOW64 で 32‑bit |
| Any CPU + Prefer 32‑bit | ARM64 | x86 | x86 エミュレーションで起動 |
| Any CPU + Prefer native ARM64 | ARM64 | ARM64 | 常に 64‑bit ARM として起動 |
表のとおり、Prefer native ARM64 と Prefer 32‑bit は同時に成立しません。ゆえに「ARM64 → ARM64／それ以外 → x86」という単一バイナリでの自動切替はできません。
実務で取れる三つの戦略（推奨順）
戦略 A：ビルド構成を分け、配布で自動選択（最も堅い）
ARM64 版とx86 版を別々にビルドし、MSIX バンドルや インストーラ（WiX Burn など）で OS アーキテクチャを判定して適切なパッケージをインストールする方式です。ユーザーは常に同じ「セットアップ」を実行するだけで、OS に最適な実装が入ります。
手順（MSIX バンドル例）
- ソリューションの Configuration Manager で x86 と ARM64 のプラットフォームを作成。
- それぞれの構成で .NET Framework プロジェクトをビルド。
- Windows アプリ パッケージング プロジェクトを追加し、x86 と ARM64 の両方を含む MSIX バンドルを作成。
- 配布はバンドル 1 個のみ。インストール時に OS が最適なもの（ARM64 OS なら ARM64 パッケージ）を選択。
手順（WiX Burn 例）
- x86 MSI と ARM64 MSI を作成（製品コード・コンポーネント GUID はアーキ別）。
- Burn の Bundle で条件付きチェーンを構成（ARM64 OS なら ARM64 MSI、その他は x86 MSI）。
- ユーザーは
setup.exeを 1 回実行するだけ。
| 長所 | 短所 |
|---|---|
| 最小摩擦で確実。起動ランタイムも最適化。 | ビルド成果物が複数。CI/CD 設計がやや増える。 |
戦略 B：自己診断ローダー（小さなランチャーで切替）
小さなランチャー EXEを用意し、実行時に OS/プロセスのアーキテクチャを判定して ARM64 版または x86 版の本体 EXE を起動する方法です。既存アプリの大規模改修は不要で、実装の自由度が高いのが利点です。
設計のコツ
- ローダー自体は x86（Native/C# どちらでも可）にすると、x64/ARM64 のどちらの OS でも必ず起動できます。
- 起動後に IsWow64Process2 や RuntimeInformation.OSArchitecture でネイティブ OS を判定。
- コマンドライン引数・標準入出力・終了コードを 完全に委譲（ラッパー透明性）。
- 「単一インスタンス」アプリは ミューテックスと 引数横流しを設計する。
サンプル（C# ランチャー：x86 ビルド）
using System;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices;
internal static class Program
{
// WinNT.h
private const ushort IMAGE_FILE_MACHINE_I386 = 0x014c;
private const ushort IMAGE_FILE_MACHINE_AMD64 = 0x8664;
private const ushort IMAGE_FILE_MACHINE_ARM64 = 0xAA64;
[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool IsWow64Process2(
IntPtr hProcess, out ushort processMachine, out ushort nativeMachine);
private static bool IsArm64OS()
{
if (IsWow64Process2(Process.GetCurrentProcess().Handle,
out _, out ushort native))
{
return native == IMAGE_FILE_MACHINE_ARM64;
}
// 後方互換：API 非対応 OS では RuntimeInformation を利用
return RuntimeInformation.OSArchitecture == Architecture.Arm64;
}
[STAThread]
private static int Main(string[] args)
{
string baseDir = AppContext.BaseDirectory;
string targetExe = IsArm64OS()
? Path.Combine(baseDir, "app.arm64\\MyApp.exe")
: Path.Combine(baseDir, "app.x86\\MyApp.exe");
var psi = new ProcessStartInfo(targetExe)
{
UseShellExecute = false,
RedirectStandardInput = false,
RedirectStandardOutput = false,
RedirectStandardError = false,
Arguments = string.Join(" ", args.Select(QuoteIfNeeded))
};
using var child = Process.Start(psi);
child.WaitForExit();
return child.ExitCode;
static string QuoteIfNeeded(string s)
=> s.Any(char.IsWhiteSpace) ? $"\"{s.Replace("\"", "\\\"")}\"" : s;
}
} この方式では配布物は Launcher.exe（x86）＋ app.arm64\MyApp.exe（ARM64）＋ app.x86\MyApp.exe（x86）という 3 点セットになります。ショートカットは Launcher.exe に向けます。
| 長所 | 短所 |
|---|---|
| 既存本体をほぼ無改修で切替。UAC/引数/終了コードを透過設計できる。 | ごく短時間だがローダーの起動オーバーヘッドが発生。実装・テストが必要。 |
戦略 C：プロダクト改善要望を継続的に投票
「単一 Any CPU バイナリで ARM64 と x86 を自動分岐したい」というニーズは実運用で強く、開発者コミュニティに要望を上げ続けるのも重要です。票が集まるほど優先度は上がります（ただし時期は未定）。
メモリ使用量とパフォーマンスの現実的な見立て
同一アプリでもプロセスのビット数でメモリ使用量は変わります。実測例として、
- x86 プロセス：約 39 MB
- x64 プロセス：約 54 MB
- ARM64 ネイティブ：約 56 MB
といった差が観測されることがあります（値はアプリの構造次第で上下します）。主な要因は ポインタ幅（32→64bit）、JIT 生成コードのサイズ、GC セグメント既定サイズなどです。省メモリが第一なら x86 を維持する選択も現実的です。一方で ARM64 ネイティブは CPU 集約処理でのスループットや 電力効率で優位になりやすく、長時間稼働やバッテリー運用では効果が見込みやすい、というトレードオフを評価しましょう。
現場で迷わない判断フロー
| 条件 | 推奨アクション |
|---|---|
| ネイティブ依存（P/Invoke/COM）が x86 専用 | 当面は x86 を軸に。ARM64 対応の可否を中長期で検討。 |
| ARM64 機を主力運用し 性能/省電力を重視 | ARM64 版を用意し、MSIX/インストーラで自動選択。 |
| 配布の一元化を最優先 | MSIX バンドルまたは WiX Burn で 1 セットアップに統合。 |
| 既存配布方式を変えにくい | 自己診断ローダー（x86）で ARM64/x86 の二択起動。 |
Visual Studio 設定とビルドの具体手順
x86 ビルドと ARM64 ビルドを用意する
- プロジェクトの プラットフォームに x86 と ARM64 を追加。
- x86 構成では Prefer 32‑bit にチェック（EXE のみ）。
- ARM64 構成では Prefer native ARM64 を選択（対象が .NET Framework 4.8.1 以降）。
- 共通コードはひとつ。条件付きコンパイルでネイティブ依存差分を吸収（
ARM64やWIN32などの記号定義）。
ビルド成果物の健全性チェック（corflags）
EXE のフラグを検証しておくと、配布後の事故を防げます。
corflags MyApp.exe
// 32BITPREFERRED=1 なら Prefer 32‑bit が有効
// 32BITREQUIRED=1 なら「x86 固定」ビルド
ローダー方式を採る場合の実装ディテール
引数・標準入出力・終了コードの“透明性”
- 引数は そのまま子プロセスへ。空白・引用符のエスケープに注意。
- CLI ツールなら 標準出力/標準エラーを子プロセスにブリッジ。
- 終了コードは 子プロセスのコードを返す（例：0=成功、非 0=失敗）。
UAC・管理者権限
本体が昇格を要求する場合、ローダーは runas 動作で起動するか、マニフェストの権限レベルを本体と整合させてください。ローダーはあくまで薄いラッパーです。
単一インスタンスの引数転送
単一インスタンス設計の場合、ローダーでミューテックスを張るのではなく、本体側の既存実装（NamedPipe や WM_COPYDATA）に従い、ローダーは単に 本体プロセスに引数を届ける役割に徹するとテストが軽くなります。
避けたいアンチパターン
- Any CPU ひとつに過度な期待：単一 EXE でビット数を自在に切り替えることはできません。
- x64 フォールバック：妥協で「x64 にしておく」と、x86 ネイティブ依存やメモリ増が裏目に出ます。
- ローダーが引数を食べる：デバッグが極端に難しくなります。必ずロギングと透過転送を。
FAQ（よくある質問）
Q：ARM64EC を使えば混在できるのでは？
A：ARM64EC は ネイティブ C/C++ の世界で x64 バイナリを ARM64 と混在させるための仕組みです。.NET Framework のマネージ プロセスでは一般的な解ではありません。P/Invoke 先を ARM64EC 化するなど高度なテクニックはありますが、運用難度が上がります。
Q：ClickOnce だけでアーキ別配布はできますか？
A：ClickOnce はアーキテクチャ別選択が弱く、複数の公開プロファイルを使って URL を分ける運用が現実的です。ユーザー体験を整えるなら MSIX かインストーラの採用が無難です。
Q：1 本の Any CPU でどうしても…
A：現在の仕様上は不可能です。どうしても単一エントリにこだわるなら、「単一セットアップ（バンドル/ブートストラップ）」でユーザー目線の一体感を担保し、内部ではアーキ別実行ファイルに分岐させるのが最短距離です。
実測と監視：メモリ・CPU・電力の見える化
評価では次を最低限確認しましょう。
- 起動時間：ARM64 ネイティブで短縮するケースが多い。ローダー方式でも実用上問題ない数百 ms 程度に収まるのが一般的。
- アイドル時メモリ：x86 < x64 ≒ ARM64 の傾向。ウィンドウ数・画像やフォントの読み込みで差が広がる。
- 電力：UI 待機や軽作業では ARM64 ネイティブの利点が出やすい。CPU バウンドは更に差が出ることがある。
移行ロードマップ（サンプル）
- Week 1–2：x86/ARM64 の二構成をビルド。P/Invoke/COM 依存を棚卸し。
- Week 3：自己診断ローダーの PoC。引数・終了コードの透明性試験。
- Week 4：MSIX バンドル化、社内配布チャネルに統合。
- Week 5–6：ARM64 での回帰試験、メモリ・電力の測定レポート化。
- Week 7：段階ロールアウト。ヘルプデスク向けナレッジ更新。
チェックリスト（配布前に）
- ARM64 と x86 の アセンブリ バージョンを揃えたか。
- 起動パス上の 構成ファイル（
app.config等）の差異は管理できているか。 - ファイル関連付け・URL プロトコルの ハンドラ登録はローダー経由でも正しく機能するか。
- ショートカットは ランチャー（またはアプリ ID）を指しているか。
- クラッシュ レポート／ログが どのアーキテクチャで発生したか識別できるか。
結論：いま選ぶなら「二実装＋一配布」
単一 Any CPU EXE による「ARM64 ネイティブ／x86 フォールバックの自動切替」は現行仕様上できません。しかし、アプリ本体を x86 と ARM64 の 2 ビルドに分け、MSIX バンドルやローダーでエントリを一つに統合すれば、ユーザー体験と保守性を両立できます。メモリ消費の観点で x86 を維持する価値は依然として高く、ARM64 ネイティブの性能・電力効率との トレードオフを定量評価しながら段階移行するのが、2025 年時点の最適解です。
付録：最小ローダー（C/C++・ネイティブ x86 版の骨格）
#include <windows.h>
int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int)
{
USHORT processMachine = 0, nativeMachine = 0;
typedef BOOL (WINAPI *PFN)(HANDLE, USHORT*, USHORT*);
auto pIsWow64Process2 = (PFN)GetProcAddress(GetModuleHandleW(L"kernel32.dll"), "IsWow64Process2");
bool isArm64 = false;
if (pIsWow64Process2 && pIsWow64Process2(GetCurrentProcess(), &processMachine, &nativeMachine))
isArm64 = (nativeMachine == 0xAA64); // IMAGE_FILE_MACHINE_ARM64
wchar_t modulePath[MAX_PATH];
GetModuleFileNameW(nullptr, modulePath, MAX_PATH);
// ディレクトリ基準に子 EXE を選択
wchar_t target[MAX_PATH];
wsprintfW(target, L"%s\\..\\app.%s\\MyApp.exe",
modulePath, isArm64 ? L"arm64" : L"x86");
STARTUPINFOW si{ sizeof(si) };
PROCESS_INFORMATION pi{};
// 引数連結（省略）。必要に応じてコマンドラインを構築
if (!CreateProcessW(target, GetCommandLineW(), nullptr, nullptr, FALSE, 0, nullptr, nullptr, &si, &pi))
return (int)GetLastError();
WaitForSingleObject(pi.hProcess, INFINITE);
DWORD exitCode = 0;
GetExitCodeProcess(pi.hProcess, &exitCode);
CloseHandle(pi.hThread);
CloseHandle(pi.hProcess);
return (int)exitCode;
} 付録：運用メモ（トラブルを減らすために）
- シンボル（PDB）はアーキ別に用意し、クラッシュ収集基盤で突合できるように。
- 外部プロセス呼び出し（ブラウザ、オフィス連携など）の パス依存を確認（ARM64 では既定アプリが x64 と異なることがある）。
- ネイティブ DLL の探索規則（
LoadLibraryの検索パス）と Bitness の混在禁止を再度周知。 - MSIX の ファイル仮想化や レジストリ リダイレクトの影響をテスト（とくに COM 登録）。
まとめ：いま動く現実解を最短で
仕様上の制約で “魔法のチェック” は存在しません。だからこそ、配布時に最適化する設計に寄せるのがプロダクトとして賢い選択です。この記事のステップに沿って二実装を整え、バンドルまたはローダーで一本化すれば、ARM64 ネイティブの恩恵と x86 の互換性・省メモリを両取りできます。あとは CI/CD とテレメトリで差分を可視化し、段階的に ARM64 化の比重を上げていく――それが “2025 年の正解” です。
コメント