Arm版Windowsで業務アプリは動くのか ── x64エミュレーション(Prism)とネイティブDLL・COMの現実

「来月からの新しいPC、Copilot+ PCというやつにするんですが、うちの業務システムは動きますか？」── Snapdragon搭載PCの法人導入が進むにつれて、この質問を受ける開発会社・情シスが増えています。カタログには「既存アプリもエミュレーションで動作」と書いてある。でも自社の業務アプリは、C#の画面の裏でベンダー提供のネイティブDLLをP/Invokeし、帳票はCOMコンポーネント経由、おまけに専用機器のドライバーまで入っている。「動きますか？」に即答できないのが正直なところではないでしょうか。

答えを先に言えば、「アプリ本体はたいてい動く。危ないのはアプリの周辺にいる連中」です。x86/x64のユーザーモードコードはWindows 11のエミュレーションがかなりの精度で面倒を見てくれる一方、ドライバー・シェル拡張・プロセス内のアーキテクチャ混在という「エミュレーションの守備範囲外」がはっきり存在します。そしてこの守備範囲外こそ、業務アプリが好んで使ってきた領域です。

この記事では、Windows on Armのエミュレーションの仕組みと限界、x64とArm64をプロセス内で混ぜられないという大原則、.NETアプリ特有の組み合わせ問題、そして「自社アプリがArm機で動くか」を確認する実務手順を、Microsoft Learnで裏取りできる範囲で整理します。

1. まず結論

急いでいる方は、まずこの3点だけで足ります。

1. アプリ本体はたいてい動きます。Windows 11 on Armはx86/x64アプリをOS組み込みのエミュレーションで実行でき、24H2以降はPrismで性能も改善されています。¹
2. 危ないのは「周辺」です。カーネルモードドライバー、シェル拡張やIMEのように他プロセスへロードされるDLL、そしてネイティブDLL・COMのアーキテクチャ不一致。動くかどうかはアプリ本体ではなく、ここで決まります。²³⁴
3. 確認は3段階で足ります。依存の棚卸し → x64のままArm機で実機確認 → 必要ならArm64ネイティブ化。手順は第6章です。

Arm64EC・Arm64Xという用語は第4章で説明します。ここで覚える必要はありません。以下は、この3点の内訳と出典です。細部が必要になったときに戻ってきてください。

• 純粋なマネージド(.NET)アプリや普通のx86/x64デスクトップアプリは、Arm版Windows 11のエミュレーションでほぼ動きます。エミュレーションはOS組み込みで、アプリの修正も追加コンポーネントも不要です。¹
• エミュレーションが面倒を見るのはユーザーモードのコードだけです。カーネルモードドライバーはエミュレーションされず、Arm64ネイティブが必須です。UMDFドライバーやプリンタードライバーもOSのアーキテクチャに一致させる必要があります。²³
• シェル拡張・IME・支援技術など「他プロセス(Explorer等)にロードされるDLL」も、システムと同じArm64への再コンパイルが必要です。エミュレーションでは救えません。⁴
• 1つのプロセス内でx64とArm64は混在できません。x64/Arm64ECプロセスがロードできるのはx64とArm64ECのバイナリ、Arm64プロセスがロードできるのはArm64のバイナリだけです。x64のexeからArm64のDLLは呼べず、逆も呼べません。⁵
• この制約を1ファイルで越えるための仕組みがArm64EC(x64と同一プロセスで混在できるネイティブArm64コード)とArm64X(Arm64とArm64ECを1つのPEに同居させ、どちらのプロセスにもロードできるバイナリ)です。両アーキテクチャから呼ばれるCOMインプロセスサーバーやプラグインはArm64Xの出番です。⁵⁶
• .NETは.NET 6以降でWindows Arm64を正式サポートしており(現在サポート中の.NET 8/9/10ではWindows 11/10のArm64がサポート対象OSに明記されています)、RID win-arm64 でネイティブ発行できます。一方でAnyCPUのアプリをArm64の.NETランタイムで動かすとプロセスはArm64として走るため、x64しかないネイティブDLLをP/Invokeしていると読み込みに失敗する、という組み合わせ問題が起きます。⁷⁸⁵
• 検証環境は、実機(Copilot+ PC等)のほか、AzureのWindows 11 Arm64 VM、Arm機上のHyper-VやApple SiliconのMacで使えるWindows 11 Arm64 ISOで用意できます。※x64機のHyper-VではArm64 VMは作れません。⁹¹⁰

この記事の知識マップ

Windows on Armは、OS組み込みのx86/x64エミュレーション(24H2以降はPrism)によってユーザーモードのアプリを無修正で実行しますが、カーネルモードドライバーやシェル拡張・IMEのように他プロセスへロードされるDLLはエミュレーションの対象外でArm64ネイティブが必須です。1つのプロセスの中でx64とArm64のバイナリは混在できないという原則があり、Arm64ECとArm64Xはこの制約を緩和して、COMインプロセスサーバーのような両対応が必要なDLLに使われます。.NETはRID win-arm64でネイティブ発行できますが、AnyCPUアプリがArm64プロセスとして実行されるとx64専用のネイティブDLLのP/Invokeが失敗し、BadImageFormatExceptionとして現れます。行き詰まった開発者にはApp Assureという支援窓口があります。

flowchart LR
    accTitle: Arm版Windowsでの業務アプリ互換性の知識マップ
    accDescr: Windows on Armのx86/x64エミュレーションがユーザーモードのアプリを無修正で動かす一方、カーネルモードドライバーやシェル拡張はArm64ネイティブが必須であること、1プロセス内でx64とArm64を混在できずArm64EC・Arm64Xがその制約を緩和すること、.NETのwin-arm64発行とAnyCPU+P/Invokeの組み合わせ問題、App Assureによる支援の関係を示す図。
    windows_on_arm["Windows on Arm"]
    x86_x64_emulation["x86/x64エミュレーション"]
    prism["Prism(エミュレーター)"]
    user_mode["ユーザーモード"]
    kernel_mode["カーネルモード"]
    shell_extension_dll["シェル拡張・IME等(他プロセスにロードされるDLL)"]
    wow64["WOW64"]
    copilot_plus_pc["Copilot+ PC"]
    process_architecture_mixing_restriction["プロセス内アーキテクチャ混在の制約"]
    arm64ec["Arm64EC"]
    arm64x["Arm64X"]
    com_inprocess_server["COMインプロセスサーバー"]
    com_localserver["COM LocalServer(別プロセスCOMサーバー)"]
    rid_win_arm64["RID win-arm64"]
    dotnet[".NET(Core以降)"]
    dotnet_framework[".NET Framework"]
    anycpu_arm64_pinvoke_mismatch["AnyCPUとP/Invokeの組み合わせ問題"]
    badimageformatexception["BadImageFormatException"]
    runtimeinformation_api["RuntimeInformation.ProcessArchitecture/OSArchitecture"]
    app_assure["App Assure"]
    fasttrack["FastTrack"]
    windows_on_arm -->|"利用する"| x86_x64_emulation
    x86_x64_emulation -.->|"利用する"| prism
    x86_x64_emulation -->|"前提とする"| user_mode
    x86_x64_emulation -->|"両立しない"| kernel_mode
    x86_x64_emulation -->|"両立しない"| shell_extension_dll
    x86_x64_emulation -.->|"利用する"| wow64
    copilot_plus_pc -.->|"利用する"| windows_on_arm
    windows_on_arm -->|"前提とする"| process_architecture_mixing_restriction
    arm64ec -->|"軽減する"| process_architecture_mixing_restriction
    arm64x -->|"軽減する"| process_architecture_mixing_restriction
    com_inprocess_server -->|"前提とする"| process_architecture_mixing_restriction
    com_localserver -->|"軽減する"| process_architecture_mixing_restriction
    windows_on_arm -.->|"利用する"| rid_win_arm64
    rid_win_arm64 -->|"前提とする"| dotnet
    dotnet_framework -.->|"利用する"| x86_x64_emulation
    anycpu_arm64_pinvoke_mismatch -->|"原因になり得る"| badimageformatexception
    rid_win_arm64 -.->|"原因になり得る"| anycpu_arm64_pinvoke_mismatch
    anycpu_arm64_pinvoke_mismatch -->|"で確認できる"| runtimeinformation_api
    app_assure -->|"推奨される対応"| windows_on_arm
    app_assure -->|"前提とする"| fasttrack

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全20件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. Arm版Windowsとは ── Snapdragon搭載PCとPrism

Arm版Windowsは、Arm64プロセッサー上で動くWindowsです。2024年以降、「Copilot+ PC」── 毎秒40兆回以上の演算(40+ TOPS)が可能なNPUを搭載したWindows 11 PCの新カテゴリー ── の多くがArmベースのSnapdragon Xシリーズを採用したことで、開発者が意識せざるを得ない存在になりました。¹¹¹²

既存アプリとの互換性を支えるのがOS組み込みのエミュレーションです。仕組みの要点は次のとおりです。¹

• エミュレーターはx86/x64命令のブロックをArm64命令へJITコンパイルし、変換結果をモジュールごとにキャッシュして2回目以降の起動を速くします。
• Windows 11はx86とx64の両方をエミュレーションできます。Windows 10 on Armがエミュレーションできるのはx86のみなので、x64業務アプリの話は実質Windows 11前提です。
• Windows 11 24H2では新しいエミュレーターPrismが導入され、従来より性能が向上しCPU使用率が下がりました。PrismはQualcomm Snapdragon向けに最適化されています。
• 32bit(x86)アプリは、x64版Windowsと同じWOW64レイヤーの上で動き、ファイルシステム・レジストリのリダイレクトを受けます。一方x64アプリにはWOW64レイヤーがなく、システムバイナリが後述のArm64X形式でコンパイルされているため、x64アプリはリダイレクトなしでOS全体(ファイルシステムもレジストリも)にアクセスできます。¹

エミュレーション下のアプリから見えるCPU情報は「エミュレートされた仮想プロセッサー」のものです。互換性のため GetNativeSystemInfo すらエミュレートされた値を返すので、ホストがArm64かどうかを知りたければ IsWow64Process2 や GetMachineTypeAttributes を使います。¹³

なお、エミュレーションで問題が出たアプリ向けに、exeを右クリック→プロパティ→互換性タブからエミュレーション設定(既定/安全/厳密/非常に厳密のプリセットと個別詳細設定)を変更する仕組みがWindows側に用意されています。互換性と引き換えに性能が落ちる調整ですが、「昔のWindows on Armでは動いていたのに」というケースの逃げ道として覚えておく価値があります。¹⁴

3. エミュレーションで動くもの・動かないもの

「動きますか？」への回答は、アプリ本体ではなく依存物の種類で決まります。細目に入る前に、エミュレーションの守備範囲がどこで切れるのかを層で押さえておくと、以降の判断が速くなります。

境界は「自分のプロセスの中か外か」、そして「ユーザーモードかカーネルモードか」の2本です。この2本の外側にある依存物を数え上げる作業が、実質的にArm対応調査のすべてだと言っても言い過ぎではありません。以下は同じ内容を、実際に検討対象になる単位で並べた判断表です。

業務アプリの文脈で言い直すと、危険信号は次のようなものです。

• VPNクライアント、資産管理エージェント、セキュリティ製品 ── カーネルドライバーの塊です。Arm64対応版の有無をベンダーに確認する必要があります。
• USBドングル認証、専用機器(計測器・決済端末等) ── デバイスドライバーがArm64で提供されているかが生命線です。
• 「Explorerに機能を足す」系ツール ── シェル拡張はArm64のExplorerにロードされるため、x64のままでは機能しません。
• アプリ本体がこれらに該当しなくても、インストーラーがドライバーを同梱しているケース(仮想プリンタードライバー方式のPDF出力など)は同じ問題を踏みます。

4. プロセス内のアーキテクチャ混在はできない ── P/InvokeとCOMの現実

32bit時代から「64bitプロセスは32bit DLLをロードできない」という鉄則がありました¹⁶。Arm版Windowsにも同じ構造の鉄則があります。ロード可否のルールは公式に次のとおり整理されています。⁵

ここで登場する2つの仕組みが、Arm対応の設計を考えるうえでの鍵です。

• Arm64EC(Emulation Compatible)は、x64の呼び出し規約・スタック使用・データレイアウトに従うことで、同一プロセス内でエミュレーション実行されるx64コードと混在できるネイティブArm64コードのABIです。x64アプリがWindows 11 on Armで動くとき、そのプロセスにロードされるOSコードの大半はArm64ECでコンパイルされており、アプリが知らないままネイティブ速度で実行されています。依存DLLがx64のままでも、自分のコードから順にArm64EC化して性能を上げていく、という段階的移行に使えます。⁵
• Arm64Xは、従来のArm64コードとArm64ECコードを1つのPEファイルに同居させたバイナリ形式です。ロードするプロセスがx64ならx64のDLLとして、Arm64ならArm64のDLLとして振る舞うため、両方のアーキテクチャのプロセスから呼ばれる可能性があるDLLに向いています。公式ドキュメントはArm64Xが必要な状況として「x64とArm64の両方のアプリから呼ばれる64bit COMサーバー」「x64/Arm64どちらのアプリにもロードされるプラグイン」「x64/Arm64プロセスに注入される単一バイナリ」を挙げています。⁶

業務アプリでの実害を具体化しましょう。

ケース1: x64のexe + x64のネイティブDLL(P/Invoke)。プロセス全体がx64で統一されているなら、丸ごとエミュレーションの中で動きます。「一部だけ速くしたい」とArm64のDLLを混ぜることはできません(上表のとおり不可)。

ケース2: COMインプロセスサーバー。COMのin-procサーバーはただのDLLなので、上表のルールがそのまま適用されます。x64クライアントからはx64(またはArm64EC/Arm64X)のCOM DLLしか使えず、アプリをArm64ネイティブ化した瞬間、x64のCOM DLLはロードできなくなります。両対応が必要なら、DLLをArm64X化するか、32bit↔64bitで実績のあるアウトプロセスCOM/IPC分離(プロセスを分けてプロセス間通信でつなぐ)の定石を適用します。アーキテクチャの壁はプロセス境界で越えるのが昔からの基本形です。¹⁶⁶

ケース3: 自分がプラグインをホストする/される。Excelアドイン、業務パッケージのプラグイン、印刷ミドルウェアなど、「相手のプロセスに自分のDLLがロードされる」形態は、相手のアーキテクチャに合わせる必要があります。逆に自社アプリがプラグインをホストしているなら、自社アプリをArm64化するとx64のサードパーティプラグインが全滅する、という影響範囲の読みが必要です。

ちなみに、手元のバイナリがどれなのかは開発者コマンドプロンプトで確認できます。⁵

link /dump /headers MyLibrary.dll

見るのは FILE HEADER VALUES の直後の1行だけです。公式ドキュメントには、次の形の出力が示されています。⁵

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (x64) (ARM64X)

この machine の行を読み分けます。

出力は長いので、link /dump /headers MyLibrary.dll | findstr machine と繋いでこの1行だけを取り出すのが実務的です。なお、ビルド途中のOBJ/LIBを同じコマンドで調べると A641 machine (ARM64EC) と表示されますが、これはMSVC内部の識別子で、最終的なEXE/DLLのmachine値ではありません。⁵

すでに動いているアプリを調べたいだけなら、タスクマネージャーの「詳細」タブに「アーキテクチャ」列を表示する方法もあります。実行ファイルがArm64ECでコンパイルされているアプリは ARM64 (x64 compatible) と表示されます。⁵

5. .NETアプリの場合 ── AnyCPUの罠とアーキテクチャ判定

.NET(Core系)は.NET 6以降でWindows Arm64を正式サポートしており、現在サポート中の.NET 8/9/10ではWindows 11/10のArm64がサポート対象OSに明記されています。発行はRIDに win-arm64 を指定するだけです。¹⁷⁷

<!-- csproj: Arm64ネイティブ向けに発行する -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

純粋なマネージドコードだけのアプリなら、これでArm64ネイティブ化はほぼ完了です。JITがArm64コードを吐くだけで、ソース修正は基本的に不要です。.NET Frameworkアプリの場合は、.NET Framework 4.8.1がArm64ネイティブサポートを追加しています(Windows 11のArm64機向け。4.8.1ランタイムはWindows 10のArm機ではネイティブArm64アプリをサポートしません)。x64ビルドのままのFrameworkアプリは、エミュレーションで動く扱いです。¹⁸¹⁹

問題はネイティブDLLをP/Invokeしている場合の組み合わせです。Arm機では「.NETアプリだからAnyCPUでどこでも動く」という長年の感覚が裏切られます。

• Arm64の.NET SDK/ランタイムで実行すると、アプリは既定でArm64プロセスとして走ります。⁸
• Arm64プロセスはx64のDLLをロードできません(第4章の表)。つまりAnyCPUの自社コードは無傷でも、DllImport しているx64ネイティブDLLの読み込みで失敗します。⁵
• 逆に、win-x64 として発行したアプリはプロセス全体がx64となり、エミュレーションの中で(x64ネイティブDLLごと)動きます。この場合Arm64ネイティブの性能は得られませんが、動作互換性は最も高い構成です。¹²

「動いたり動かなかったりする」ように見える正体は、たいていプロセスのアーキテクチャとネイティブ依存物のアーキテクチャの不一致です。切り分けの第一歩として、実行中のプロセスが何で走っているかをコードで確認できるようにしておくと調査が一気に楽になります。

using System.Runtime.InteropServices;

// プロセス自身のアーキテクチャ(x64エミュレーション下なら X64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// OS本来のアーキテクチャ(Arm機なら Arm64)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

注意点として、OSArchitecture が「エミュレーションを剥がした本来のOSアーキテクチャ」を返すようになったのは.NET 7からです。それ以前はエミュレーション下でX64を返していたため、.NET 6以前で「Arm機かどうか」をこのAPIで判定しているコードは期待どおり動きません。²⁰²¹

.NET固有のチェックポイントをまとめます。

• NuGetパッケージのネイティブ資産: runtimes/win-x64/native しか持たないパッケージは、win-arm64 発行時に頼るものがありません。パッケージの中身(またはリポジトリ)で win-arm64 資産の有無を確認します。RIDはまさにこの「プラットフォーム固有資産の振り分け」のための仕組みです。⁷
• 開発機のSDK構成: Arm機では、Arm64版.NETは通常の C:\Program Files\dotnet\ に、x64版SDKは C:\Program Files\dotnet\x64\ にインストールされ、共存できます。PATHやDOTNET_ROOTがどちらを向いているかで dotnet run の実行アーキテクチャが変わるので、検証時は意識してください。¹⁷
• 例外の読み方: マネージドアセンブリのアーキテクチャ不一致は BadImageFormatException として現れます(公式リファレンスにも「異なるプラットフォームを対象とするコンポーネントの読み込み」が発生条件として明記されています)。²²

6. 自社アプリのArm対応チェックリスト

実務では次の3段階で確認するのが効率的です。

第4章で見たケースが、どの段階で効いてくるかも対応させておきます。

②③のための検証環境は、次の選択肢があります。

• 実機: Copilot+ PC等のSnapdragon搭載機。1台あるとトラブル調査まで含めて最も確実です。¹²
• Azure VM: AzureポータルでイメージをArm64でフィルターし、Windows 11のArm64 VM(推奨サイズD2ps_v5等、Ampere Altraベース)を作成できます。手元にArm機が1台もなくても検証を始められるのが利点です。⁹
• ローカルVM: Windows 11 Arm64のISOが公式配布されており、Arm機上のHyper-VやArmベースのApple Silicon Mac上でVMを作れます。x64機のHyper-VではArm64 VMは作成できない点に注意してください。¹⁰

サードパーティ製品の対応状況は、Microsoftが案内している対応状況サイト(Windows on Arm Ready Software)で確認できます。そのうえで、自社開発の業務アプリ(LOB)やISV製アプリの互換性問題については、App Assureという公式の支援窓口があります。「動かないので八方塞がり」の前に使える窓口がある、というのは情シスへの説明材料としても有効です。¹²¹⁵

自社が対象かどうかの判断材料を整理すると、次のとおりです。²⁴²⁵

自社のライセンス構成が対象かどうかは、上のプラン名を情シス・調達部門の契約内容と突き合わせるのが最短です。ライセンス数の条件や対象プランの一覧は変わることがあるため、実際に申請する前にFastTrackの対象条件のページで最新の記載を確認してください。

7. 当面の現実解 ── 3つの選択肢の使い分け

Arm対応は「全部ネイティブ化」一択ではありません。むしろ多くの業務アプリでは、段階的な使い分けが現実解です。

C++資産が大きい場合は、(a)と(c)の中間としてArm64ECがあります。x64の依存DLLをそのままに、自分のコードだけを段階的にネイティブ化できるため、「巨大なx64アプリを一気に移行できない」ケースの公式ルートです。⁵²³

開発環境の面では、Visual StudioにArm64ネイティブ版があり、Arm機上でArm64/x64/x86すべてをターゲットにできるコンパイラーツールセットが揃っています。CI用のビルドは既存のx64ビルドマシンでのクロスコンパイルでも作れるので、「テスト実行だけArm実機/VMに寄せる」構成が組みやすくなっています。²⁶²³

8. まとめ

• Arm版Windows 11はx86/x64アプリをOS組み込みのエミュレーションで実行でき、24H2以降はPrismで性能も改善されています。x64エミュレーションはWindows 11からで、Windows 10 on Armはx86のみです。
• エミュレーションの守備範囲はユーザーモードだけです。カーネルモード/UMDF/プリンターの各ドライバー、シェル拡張・IME・支援技術のような「他プロセスにロードされるDLL」はArm64ネイティブが必須です。業務アプリの可否はアプリ本体ではなく、この周辺依存で決まります。
• プロセス内でx64とArm64は混在できません。x64/Arm64ECプロセスはx64+Arm64ECを、Arm64プロセスはArm64のみをロードできます。COMインプロセスサーバーもプラグインも同じルールに従い、両対応にはArm64X、プロセス境界を越えるならアウトプロセスCOM/IPCが定石です。
• .NETは win-arm64 でネイティブ発行できますが、Arm64ランタイム上のAnyCPUアプリはArm64プロセスとして走るため、x64のみのネイティブDLLをP/Invokeしていると失敗します。RuntimeInformation.ProcessArchitecture / OSArchitecture(.NET 7以降)で切り分けます。
• 確認手順は「依存の棚卸し→x64のままエミュレーションで実機確認→必要ならArm64ネイティブ化」の3段階です。検証環境はAzureのArm64 VMやArm64 ISOで用意でき、法人はApp Assureの支援も受けられます。
• 当面は「エミュレーションで動けばそのまま」「ドライバー・DLLベンダーの対応確認」「要件次第でArm64ネイティブ化(C++はArm64ECの段階移行も)」の使い分けが現実解です。

関連記事

• C#からネイティブDLLを呼ぶ：C++/CLIラッパー vs P/Invoke
• C#からWin32 APIを安全に呼ぶ ── P/Invoke実務ガイド(DllImport / LibraryImport / CsWin32)
• C# Native AOT DLLをC/C++から呼び出す方法
• Windowsアプリの1ファイル配布 - シングルバイナリとOS依存の限界
• 32bitアプリから64bit DLLを呼ぶCOMブリッジ実例

関連する相談領域

合同会社小村ソフトでは、既存業務アプリのArm版Windows対応可否の調査、ネイティブDLL・COM連携を含むアプリのアーキテクチャ移行設計、「Arm機でだけ動かない」不具合の原因解析を扱っています。

• Windowsアプリ開発
• 技術相談・設計レビュー
• 不具合調査・原因解析
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Arm版Windowsで普通のx64業務アプリは動きますか？

多くの場合は動きます。Windows 11 on Armにはx86/x64アプリを無修正で実行するエミュレーション機能が組み込まれており、Windows 11 24H2以降はPrismという新しいエミュレーターで性能も改善されています。ただしエミュレーションが面倒を見るのはユーザーモードのコードだけで、カーネルモードドライバーや、Explorerなど他プロセスにロードされるシェル拡張・IMEの類はArm64ネイティブが必須です。アプリ本体よりも周辺の依存物で決まる、と考えてください。

x64のexeからArm64のDLLを呼べますか？

呼べません。1つのプロセスの中でx64とArm64のバイナリを混在させることはできず、x64(またはArm64EC)プロセスがロードできるのはx64とArm64ECのバイナリ、Arm64プロセスがロードできるのはArm64のバイナリだけです。逆方向(Arm64のexeからx64のDLL)も同様に不可です。どうしても両対応の1つのDLLが必要な場合は、Arm64とArm64ECのコードを1ファイルに同居させるArm64Xという形式か、プロセスを分けてIPCで連携する構成を使います。

.NETアプリをArm64対応するには何が必要ですか？

.NET 6以降はWindows Arm64を正式サポートしており、現在サポート中の.NET 8/9/10ではWindows 11/10のArm64がサポート対象OSに明記されています。RID(ランタイム識別子)win-arm64を指定してpublishするだけでArm64ネイティブの実行ファイルを作れます。純粋なマネージドコードだけならこれでほぼ完了ですが、P/InvokeしているネイティブDLLやネイティブ資産を含むNuGetパッケージがあれば、それぞれのArm64版が存在するかの確認が必要です。.NET Frameworkアプリの場合は4.8.1がWindows 11上でのArm64ネイティブ実行をサポートしています。

Arm版Windowsで動かないのはどんなソフトですか？

カーネルモードドライバーを含むソフトが筆頭です。ドライバーはエミュレーションされないため、VPNクライアント、セキュリティ製品、仮想デバイス、USBドングル認証などはArm64ドライバーがなければ動きません。次に、シェル拡張・IME・支援技術のようにOS側のプロセスへDLLをロードさせるソフト、動的コード生成を禁止しているアプリ、古いOpenGLやアンチチートドライバーに依存するゲームなどが該当します。周辺機器もArm64ドライバーの有無で使えるかが決まります。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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