Windows アプリ開発に関してよく寄せられる質問

この FAQ では、プロジェクトに適したフレームワークの選択に関するガイダンスなど、Windowsアプリケーション開発に関する一般的な質問に対する回答を提供します。 取り上げるトピックは次のとおりです。

  • はじめにとWindowsアプリ開発の全体像。
  • WinUI 3、Windows Presentation Foundation (WPF)、Windows フォーム (WinForms) を使用したネイティブ Windows専用アプリ開発。
  • Windows ソフトウェア開発キット (SDK) とWindows アプリ SDK。
  • クロスプラットフォーム開発戦略の一環としてWindowsをターゲットに設定します。
  • .NET MAUI、Blazor、ASP.NET Coreを使用したハイブリッドおよび Web アプリ開発。
  • Microsoftの投資を理解しながらアプローチを選択する方法。

Windowsアプリ開発の状況

Windows開発テクノロジの簡単な概要はどこで確認できますか?

Windows開発者向けの現在のオプションの概要については、WinUI 3、.NET MAUI、React Native、Blazor、およびプログレッシブ Web Apps (PWA) について説明する理想的な開発プラットフォームの選択に関する Windows Dev Chat エピソードをご覧ください。 その他のエピソードは、Windows Dev Chat プレイリストで見つけることができます。

また、Windows開発者向けのアプリ開発オプションの概要を参照することもできます。

cloud services時代の最新のデジタル変革にクライアント アプリ開発は依然として重要

クラウド サービスの時代には、クライアント アプリの開発は、ユーザー デバイスで応答性の高い意味のある対話を実現するために引き続き重要です。

クライアント アプリが重要な理由は次のとおりです。

  • デバイスのリーチ: クライアント アプリを使用すると、選択したデバイス上のユーザーにアプリケーションを直接移動できます。
  • Gateway to Intelligent Services: クライアント アプリは、多くの場合、ユーザーがサービスと最初にやり取りします。 インテリジェントな機能を紹介し、製品を他のユーザーと区別できる、豊富でインタラクティブなインターフェイスを提供します。
  • Scalability with Cloud Integration: 適切に統合されたクライアント アプリをバックエンド cloud servicesと簡単に同期できるため、ユーザー ベースの拡大に合わせてリアルタイムのデータ accessとシームレスなスケーラビリティを実現できます。
  • 生産性とユーザー ロイヤルティの向上: 慎重に設計されたアプリは、生産性を向上させ、ユーザーが時間の経過と共に製品やサービスに関与し続けることができます。

ネイティブ Windows専用アプリ開発

Windows アプリ SDKは何ですか?

Windows アプリ SDKは、WinUI 3、アプリのライフサイクル、ウィンドウ化、通知、リソース、テキスト API など、Windowsデスクトップ アプリ用の個別に更新されるコンポーネントを提供します。 Windows リリースと Windows アプリ SDK バージョンのサポート ライフサイクルに従って、Windows 10 バージョン 1809 以降で実行されるアプリをサポートします。

Windows アプリ SDKとWindows SDK の違いは何ですか?

どちらも、Windows アプリを構築できるソフトウェア開発キット (SDK) です。

Windows アプリ SDKは、Windowsとは独立して出荷され、サポートされているWindows リリース全体で動作するコンポーネントを、バージョン 1809 Windows 10まで提供します。 これには、アプリのライフサイクル、ウィンドウ化、通知、リソース、テキスト、その他の機能用の WinUI 3 と API が含まれています。

Windows SDK には、Win32、WinRT、COM、DirectX、デバイス、シェル機能などのオペレーティング システム API 用のヘッダー、ライブラリ、メタデータ、およびツールが用意されています。

Windows アプリ SDKでは、Windows SDK は置き換えられません。 Windows アプリ SDKを採用するアプリは引き続き Windows SDK API を使用でき、WinUI 3 アプリでは一般的に両方を使用します。

Windows専用アプリを開発するための新しいチームを構築しています。WinUI 3、WPF、WinForms などのネイティブ Windows フレームワークを使用して開発するべき理由は何ですか？

Windows専用アプリのネイティブ Windows フレームワークを選択する理由を次に示します。

  • Performance: ネイティブ Windows フレームワークは、最新のWindows ハードウェアを活用するように最適化されており、高速で応答性の高いユーザー エクスペリエンスを提供します。
  • Integration: Windows には、Windowsでのみ使用できる高度なエクスペリエンスを実現するさまざまな API が付属しています。 ネイティブ フレームワークは、これらの機能と API との緊密な統合を提供します。
  • Native ユーザー エクスペリエンス: ネイティブ フレームワークは、Windows デバイス間で一貫したエクスペリエンスを提供し、アプリがあらゆる場所で優れた外観と動作を保証します。
  • オフライン サポート: ネイティブ フレームワークはオフライン シナリオをサポートし、インターネットに接続しなくてもアプリを機能させます。
  • サポートとツール: Microsoftはネイティブ フレームワークを維持し、現在の SDK、ドキュメント、デバッグ ツール、サンプルを提供します。
Microsoftの最新の投資を活用するために、どのフレームワークを使用してWindowsアプリ開発を行うべきですか？

新しい汎用Windowsデスクトップ アプリを構築する場合は、WinUI 3 を使用することをお勧めします。 WinUI 3 は、Windows アプリ SDKで提供されるネイティブ UI フレームワークです。 Windowsデスクトップ アプリをサポートし、現在の Fluent コントロールとWindows プラットフォーム機能へのアクセスを提供します。

既存のWindows アプリで Windows アプリ SDK/ WinUI 3 を使用できますか?

WinUI 3（UI フレームワーク）は、Windows アプリ SDK（Windows プラットフォーム開発フレームワーク）に付属しています。

アプリの UI を WinUI 3 に移行することも、WinUI XAML Islands を使用して、サポートされている既存のデスクトップ ホストでWindows アプリ SDK コントロールをホストすることもできます。 従来のシステム XAML Islands は、UWP XAML コントロールをホストし、さまざまな API を使用します。

Windows アプリ SDKの要素は、多くの場合、既存のアプリの構築方法に応じて、デスクトップ アプリで使用できます。 UWP アプリは、Windows アプリ SDKではサポートされていません。

つまり、WPF/MFC/WinForms アプリでは、WinUI 3 とは無関係Windows アプリ SDK API を使用できます。 たとえば、アプリのライフサイクル、ウィンドウ化、アプリ通知などがあります。

詳細については、「既存のプロジェクトでWindows アプリ SDKを使用するを参照してください。

WinUI 3 アプリをビルドするには、Visual Studioを使用する必要がありますか?

No. WinUI 3 XAML ビルドでは MSBuild を使用しますが、別のエディターのコマンド ラインから .NET SDK と現在の WinUI 3 テンプレートを使用してビルドできます。 コマンド ライン クイック スタートを参照してください。

Visual Studio 2026 では、最も豊富な統合された編集、デバッグ、プロファイリング、XAML ホット リロード エクスペリエンスが提供されます。 使用するツールの要件に合ったワークフローを使用してください。

アプリの実行時に "DLL 'Microsoft.ui.xaml.dll'' を読み込むことができません" というエラーが表示されます。どのように修正しますか?

このエラーは、通常、Windows アプリ SDK ランタイムがコンピューターにインストールされていない unpackaged アプリ シナリオで発生します。 以下を試してみてください。

  • packaged アプリ (推奨される既定値) を実行している場合は、MsixPackage 起動プロファイルが選択された (プレーンな実行可能プロファイルではなく) Visual Studio経由で起動していることを確認します。 MSIX パッケージ化手順では、必要なランタイム コンポーネントがインストールされます。
  • フレームワークに依存するパッケージ化されていないアプリを実行している場合は、一致するWindows アプリ SDKランタイムをインストールします。 自己完結型のデプロイには、そのWindows アプリ SDK依存関係が含まれます。
  • プロジェクトがデプロイ モデルと一致することを確認します。 通常の.NETパッケージ化されていないアプリの場合、<WindowsPackageType>None</WindowsPackageType>を設定すると、ランタイムの自動初期化Windows アプリ SDK有効になります。 ブートストラップ API は、動的な依存関係の初期化を明示的に制御する必要がある場合にのみ直接使用します。

デプロイ要件の詳細については、 Windows アプリ SDK を使用するアプリのデプロイに関するページを参照してください。

UWP の WinUI 3 と WinUI 2 の違いは何ですか?

WinUI 3 は、Windows デスクトップ アプリ用のMicrosoftの現在のネイティブ UI フレームワークであり、Windows アプリ SDKの一部として提供されます。

WinUI 2 は、 UWP 用 WinUI とも呼ばれ、UWP アプリ用のコントロールおよびスタイルライブラリです。 WinUI 2 と WinUI 3 では異なる XAML 名前空間が使用され、バイナリ互換ではありません。

Windows アプリ SDKと WinUI 3 を使用してアプリをビルドする場合、"WinUI アプリ" をビルドしていますか?

Yes. WinUI 3 アプリは、UI で WinUI 3 と Windows アプリ SDK を使用するアプリの最も分かりやすい呼称です。 WinUI アプリ は、コンテキストが明確な場合にも一般的に使用されます。

コントロールを徐々に置き換えることで、WinUI の UWP コントロールを使用する UWP アプリを WinUI 3 に段階的に更新できますか?

No. Windows アプリ SDKは UWP アプリでは使用できません。また、UWP 用 WinUI を WinUI 3 と混在させることはできません。 UWP から Windows アプリ SDK への移行を参照してください。

UWP アプリを WinUI 3 に移行するのはどのくらい難しいですか?

UWP と WinUI 3 は多くの XAML 概念を共有していますが、移行は名前空間の直接的な変更ではありません。 コストは主に次の要素によって決まります:

  1. Project ファイルと MSBuild のカスタマイズ:移行作業は、高度な MSBuild の使用によって異なります。
  2. .NET API の移行: .NET Native を使用する UWP アプリは、ネイティブ AOT で現在サポートされている.NET リリースに移行できます。 この最新化は、UI を WinUI 3 に移行するのとは別です。
  3. UI コンポーネント ライブラリ: ライブラリには、WinUI 3 を対象とするバージョンが必要です。
  4. ウィンドウ API とアプリケーション モデル API: CoreWindow、ApplicationView、または GetForCurrentView などの概念に関連付けられている UWP API には、Windows アプリ SDK の代替または別のデスクトップ アプローチが必要です。
  5. C++ 言語プロジェクション: UWP アプリで旧式の C++/CX プロジェクションを使用している場合は、そのコードを C++/WinRT に移植します。

詳細については、「UWP から Windows アプリ SDK への移行」および「UWP から Windows アプリ SDK への API マッピング」を参照してください。

ストアに既存の UWP アプリがある場合、同じ識別子を使用して新しいパッケージ化された WinUI 3 アプリを発行できますか?

はい。アップグレードされたアプリは、アプリケーション ID を更新せずに発行できます。 以前のバージョンのユーザーは、新しいバージョンに更新されます。 これはデスクトップ アプリにのみ適用されます。 Xbox、HoloLens、標準の Surface Hub アプリはいずれも WinUI 3 に移行することはできません。

WinUI 3 アプリをパッケージ化または配布するにはどうすればよいですか?

パッケージとデプロイの概要を参照してください。

Windows アプリ SDK の移行ガイダンスはどこで見つけることができますか？

UWP から Windows アプリ SDK への移行を参照してください。

WinUI 3 を使用する場合は、XAML マークアップを使用する必要がありますか?

No. UI コントロールは、コードで作成できます。 ただし、宣言型 XAML マークアップで UI を表すには、開発者エクスペリエンスの向上など、多くの利点があります。

  • UWP から WinUI 3 への移行: 多くの XAML と UI の概念が引き継がれますが、名前空間、プロジェクト モデル、一部の API は異なります。
  • WPFから WinUI 3 への移行: 多くの概念が引き継がれ、コントロール セットと API が異なります。
Visual Studio WinUI 3 のデザイン サーフェイスまたは UI デザイナーはありますか?

現時点ではまだできません。 XAML ホット リロード、Live Visual Tree、Live Property Explorer、および関連するランタイム ツールを使用して、アプリの実行中に XAML を検査および更新します。

WinUI 3 で使用できるランタイム デザイン ツールの完全なチュートリアルについては、 WinUI 3 の XAML ランタイム デザイン ツールに関する記事を参照してください。

Windows アプリ SDKには WinUI 3 が含まれていますか?

Yes. WinUI 3 は Windows アプリ SDK に付属しています。

Windows アプリ SDK は UWP の WinUI を含んでいますか？

No. UWP 用 WinUI は、UWP プラットフォームの一部です。

UWP 用の WinUI と WinUI 3 は同じテクノロジに基づいて構築されていますか?

そうとも言えません。 WinUI 3 は、UWP 向け WinUI のコードベースを基にしていますが、両者は別個のテクノロジです。 どちらも .NET と C++ で動作する XAML ベースの UI フレームワークですが、UWP 向けの WinUI と WinUI 3 は互いに互換性がありません。

Windows アプリ SDKを使用せずに WinUI 3 を使用できますか?

No. WinUI 3 は Windows アプリ SDK に付属しています。

パッケージ化されていないアプリで WinUI 3 を使用できますか?

Yes. WinUI 3 と多くのWindows アプリ SDK API は、パッケージ化されていないアプリで動作します。 ただし、一部のWindows機能にはパッケージ ID が必要であり、フレームワークに依存するパッケージ化されていないアプリでは、Windows アプリ SDK ランタイムを初期化する必要があります。 パッケージの概要とパッケージ ID が必要な機能のオプションを比較します。

XAML Islands と WinUI 3 の違いは何ですか?

WinUI 3 は、Windows アプリ SDKに含まれる UI フレームワークです。 XAML Islands は、既存のデスクトップ アプリが別のフレームワークの UI と共に XAML コンテンツを配置できるようにするホスティング手法です。

この用語は、UWP XAML コントロールをホストする従来のシステム XAML Islands、またはサポートされているデスクトップ ホストでWindows アプリ SDK コントロールをホストする WinUI XAML Islands を指すことができます。 API、名前空間、ホストの要件は異なります。

WinUI 3 アプリを作成すると、Windows 11とWindows 10の両方で最新の外観になりますか?

WinUI 3 コントロールは、パッケージアプリとパッケージ化されていないアプリの両方で、サポートされているバージョンのWindows 10とWindows 11で Fluent スタイルを使用します。 一部のオペレーティング システムの影響と動作は、Windows バージョンによって異なります。 たとえば、Mica は Windows 11 で使用でき、Windows 10 では単色にフォールバックします。

Windows アプリ SDKでビルドされたアプリでマイカまたはアクリルの背景を使用できますか？

Yes. デスクトップ アクリルは、Windows 10 バージョン 1809 以降でサポートされています。 Mica は Windows 11 を必要とし、Windows 10 では単色のテーマ カラーにフォールバックします。 背景を適用する前に、実行時に MicaController.IsSupported または DesktopAcrylicController.IsSupported を呼び出します。 Windows 11 用デスクトップ アプリで Mica またはアクリル素材を適用する方法 を参照してください。

WinUI 3 サンプルはどこにありますか?

「サンプルとリソース」を参照してください。 いくつかの注目すべきリポジトリ:

既にWPFに多額の投資を行っている場合は、引き続きWPFを使用するか、WinUI 3 への移行を検討する必要がありますか?

既にWPFに多額の投資を行っている場合は、既存のアプリで引き続き使用できます。 WPFは、Windowsデスクトップ アプリを構築するために広く使用されている成熟した安定したフレームワークです。

GitHub Copilotアップグレードを使用して、.NET Framework WPF アプリを最新の.NETに評価してアップグレードします。 生成されたプランを確認し、アプリの各変更を検証します。

新しいWPFアプリをビルドした場合、他の新しいWindowsアプリと比較して古臭く見えるでしょうか?

.NET 9 以降でWPF アプリケーションを開発する場合、アプリがWindows 11の洗練された最新の外観と一致することを確認できます。 WPF用の新しい Fluent テーマでは、明暗モードとシステム アクセント カラーのサポートが統合された、現代的なWindows 11美学が導入されています。 これにより、アプリの外観が最新化され、洗練されたまとまりのあるユーザー エクスペリエンスが提供されます。

私のチームは WinForms アプリの構築に慣れているので、ニーズに合っています。WinUI 3 または別のフレームワークへの移行を検討する必要がありますか?

WinForms がニーズを満たし、チームがそれに慣れている場合は、既存のアプリに WinForms を引き続き使用できます。 WinForms は、Windowsデスクトップ開発に広く使用されている成熟した安定したフレームワークです。

WinForms チームは引き続きプラットフォームに投資します。 最近の進行中の作業には、次のものが含まれます。

  • 非同期フォームとダイアログ API
  • ダーク モードとビジュアル スタイルのサポート
  • アクセシビリティ、高 DPI、レイアウト、およびデザイナーの改善
  • クリップボードと DataObject の最新化

クロスプラットフォーム ネイティブ開発

Windowsをターゲットとするクロスプラットフォームのネイティブ アプリを構築する理由

複数の OS プラットフォームでユーザーを対象としている場合、.NET MAUIまたは React Native を使用してクロスプラットフォーム アプリを構築すると、次のような利点があります。

  • 達する： クロスプラットフォーム アプリは、さまざまなデバイスやオペレーティング システムで、より多くのユーザーにリーチします。
  • コードの再利用: プラットフォーム間でコードを再利用すると、開発時間とコストが削減されます。 Windows、Android、iOS、macOS 用に個別のアプリをビルドすると、非常にコストがかかる場合があります。
  • 一貫したユーザー エクスペリエンス: クロスプラットフォーム フレームワークは、プラットフォーム間で一貫した外観を提供するのに役立ちます。
  • 統合： クロスプラットフォーム アプリは、引き続きプラットフォーム固有のサービスと統合して、包括的なエクスペリエンスを提供できます。
Windows 上で .NET MAUI アプリが適切に動作することを確信できますか？

Windows用の.NET MAUI アプリをビルドすると、出力で WinUI 3 が使用されます。 開発中、.NET MAUIはプラットフォーム間で 1 つの.NETエクスペリエンスを提供しますが、内部でプラットフォーム固有のコードを生成します。

.NET MAUIはどのようにすべてのプラットフォームでネイティブ デバイス API を提供できますか？

.NET MAUIでは、Windows、iOS、Android、macOS 全体で統一された.NET エクスペリエンスが提供されます。 ストレージ、ネットワーク、デバイス センサーなどの一般的な機能用のクロスプラットフォーム API を提供します。 プラットフォーム固有の API を呼び出したり、プラットフォームごとに特殊な実装を提供したりすることもできます。

WinUI 3 から始めて、最終的にクロスプラットフォーム シナリオをターゲットにしたい場合は、後で.NET MAUIを統合できますか?

現時点ではできません。 .NET MAUIはWindowsで実行するときに WinUI 3 を使用しますが、複数のプラットフォームをターゲットにすることを期待しているチームは、.NET MAUIまたは React Native for Desktop から始める必要があります。

私たちのチームは、強力なWebフロントエンド開発スキルを持っています。React Native for Desktop の使用を検討する必要がありますか?

強力な Web 開発エクスペリエンスを持つチームは、デスクトップ向けの React Native を検討する必要がある場合があります。 Windows および macOS 用の React Native が含まれます。 "Learn once, write anywhere" アプローチを使用すると、既存の JavaScript、TypeScript、React スキルを使用して、ネイティブ Windowsおよび macOS アプリを構築できます。

React Native for Desktop では、UI がネイティブ プリミティブに直接レンダリングされ、ネイティブのパフォーマンスとプラットフォームの機能が提供されます。

始めるには、React Native for Desktop のドキュメントを参照してください。

React Native for Desktop でサポートされているその他のWindows デバイスはありますか?

React Native for Windows では、互換性に関するドキュメントに記載されているWindowsバージョンがサポートされています。 すべての Windows デバイスがサポートされていると想定するのではなく、対象の React Native for Windows のバージョンに対するデバイス ファミリのサポートを確認します。

WindowsおよびXboxで動作するアプリを開発する場合、何を使用すればよいですか？

Xbox アプリの場合は、UWP を使用し、Xbox 固有の UWP の制限を考慮します。 ゲーム開発には、Microsoft Game Development Kit を使用します。

Windows と Surface Hub で動作するアプリをビルドするには何を使用すればよいですか？

標準の Teams Rooms または Surface Hub 環境を実行しているSurface ハブの場合は、Surface Hub アプリの要件を満たす UWP アプリを使用します。 Windows 11 Pro または Enterprise で構成された Surface Hub 3 では、サポートされているデスクトップ アプリ テクノロジを実行できるため、その構成では UWP だけがオプションではありません。

ハイブリッドおよび Web 開発

ハイブリッド アプリとは何ですか。また、その構築を検討する必要がある理由は何ですか?

ハイブリッド アプリは、最高の Web アプリとネイティブ アプリ開発を組み合わせたアプリです。 コアは HTML、CSS、JavaScript などの Web テクノロジを使用して構築され、特定のネイティブ プラットフォーム機能とハードウェアにaccessを提供するネイティブ コンテナーにラップされています。 アプリ ストアを通じて配布することもできます。

主な利点は、ハイブリッド アプリを使用すると、複数のネイティブ プラットフォームと Web 上で実行できる 1 つのアプリを構築できるため、開発時間とコストを削減できることです。 ハイブリッド アプリ開発プラットフォームの例を次に示します。

  • デスクトップ アプリ用 Electron
  • モバイル アプリ用の Ionic
  • クロスプラットフォーム アプリ用の .NET MAUI Blazor ハイブリッド
Windows でネイティブのように感じるプログレッシブ Web アプリ (PWA) を構築するにはどうすればよいですか？

Windows での Web 開発およびプログレッシブ Web Apps の概要を参照してください。

.NET MAUI Blazor ハイブリッド アプリとは何ですか?

.NET MAUIを使用すると、Blazor アプリは、Windows、iOS、Android、macOS でネイティブに実行できます。 これにより、Blazor コンポーネントと.NET MAUI コンポーネントを 1 つのネイティブ クライアント アプリに組み合わせたハイブリッド クライアント アプリを作成し、ネイティブ プラットフォーム機能にフル アクセスできます。

詳細については、ASP.NET Core Blazor Hybrid を参照してください。

.NET MAUIハイブリッド アプリのWebコンポーネントはBlazorで作成する必要がありますか？

No. .NET 9 以降、.NET MAUIには、ネイティブ アプリ内で他の JavaScript ベースの UI をホストできる HybridWebView コントロールが含まれています。

これにより、.NET MAUI アプリ内で Angular、React、Vue、またはその他の HTML/JavaScript アプリをホストできます。 ハイブリッド コントロールは C# と JavaScript の間の相互運用機能を提供するため、C# コードは JavaScript 関数を呼び出すことができます。その逆も同様です。

他のネイティブ アプリの種類は Blazor ハイブリッド コンポーネントをホストできますか?

Yes. WPFアプリと WinForms アプリでは Blazor ハイブリッド コンポーネントをホストすることもできます。これにより、既存のアプリに最新の Web UI を追加できます。 これは、.NET Framework 上に構築されたWPFまたは WinForms アプリではサポートされていません。

アプリ全体をハイブリッド アプリにする必要があるか、ネイティブ コンポーネントとハイブリッド コンポーネントを混在させ、一致させるか。

ネイティブ コンポーネントとハイブリッド コンポーネントは、アプリ内で混在させることができます。 たとえば、アプリのコアは.NET MAUI コンポーネントを使用して構築できますが、ハイブリッド コンポーネントは追加の機能を提供します。 これにより、ネイティブ コンポーネントのパフォーマンスと機能と、ハイブリッド コンポーネントの柔軟性とコスト効率を組み合わせることが可能になります。

Windows のモダンブラウザーで見栄えのする.NETベースのWebアプリを構築するための選択肢には何がありますか？

Web appsは、クライアント アプリ プラットフォームの幅広い範囲を提供します。 美しい.NET Web アプリを作成するためのオプションは次のとおりです。

  • Razor Pages を使用した ASP.NET Core アプリケーション
  • ASP.NET CORE MVC アプリ
  • ASP.NET Core でホスティング モデル オプションを使用できる Blazor アプリ。
    • Blazor WebAssembly（ブレイザー ウェブアセンブリ）
    • Blazor Server

Blazor ホスティング モデルをコンポーネント レベルで構成できるようになりました。これにより、Blazor Server アプリ内で Blazor WebAssembly コンポーネントをホストするなどのシナリオが可能になります。

詳細については、ASP.NET Core ドキュメントを参照してください。

アプローチを選択し、Microsoftの投資を理解する

Windowsを対象とするアプリを構築するためのフレームワーク オプションは非常に多く存在します。決定方法

Windowsは、多くのテクノロジをサポートするオープン プラットフォームです。 プラットフォームの選択に役立ついくつかの条件を次に示します。

  • Windowsファーストまたはクロスプラットフォームを構築していますか?
  • あなたが既に持っている言語やスキルは何ですか。.NETやJavaScript、その他のものがありますか?
  • Windows固有の API にアクセスする必要がありますか?
  • アプリの要件に最も適したフレームワークの機能はどれですか?
  • その他の比較要因については、 次の表 を参照してください。

多くのビジネス アプリでは、多くの場合、チームは既存のスキルと、チームが最も使い慣れているものに基づいて選択します。

ウェブアプリに最適な開発方法を選ぶにはどうすればいいですか?

Web アプリの開発アプローチを選択するときは、次の点を考慮してください。

  • blazor は、.NETを使用してフロントエンド Web アプリを構築する場合に推奨されます。 .NETを使用してフロントエンドとバックエンドの両方を構築できるため、時間とコストを節約でき、エンタープライズ アプリに特に適しています。
  • JavaScript web apps、既存の JavaScript スキルを活用したい場合や、確立された JS ライブラリやフレームワークと統合する必要がある場合は、依然として意味があります。
  • Web フォーム、MVC、Razor Pages などの古いフレームワークを使用する既存のアプリは引き続きサポートされ、引き続き開発および保守できます。
現在、WinUI 3 でアプリを構築するのは誰ですか?

Microsoft Photos は、文書化された例の 1 つです。 アプリは UWP からWindows アプリ SDKに移行され、WinUI 3 を引き続き使用します。 アーキテクチャと移行の詳細については、「Microsoftフォト: UWP から Windows アプリ SDK への移行」を参照してください。

今日.NET MAUIアプリを開発しているのは誰ですか?

組織は、.NET MAUIを使用して、Android、iOS、macOS、Windows用のクロスプラットフォーム アプリを構築します。 .NETカスタマー ショーケースの例を参照してください。

現在WPFアプリをビルドしていますか?

Microsoft Visual Studio UI のほとんどは、WPFを使用して構築されています。 Visual Studio IDE 自体は、複雑で高性能なWPF アプリの主要な例です。

現在 Blazor アプリを構築しているのは誰ですか?

GE DigitalのFlightPulse航空会社システムは、パイロットが見るすべてのバックエンド構成に Blazor を使用し、センサー データと分析をパイロットに直接取り込み、安全性と効率を向上させます。

.NETサイトBlazor の顧客事例を参照してください。

言語の選択 (.NETと C++)

Windows アプリに C# または C++ を使用する必要がありますか?

ほとんどの場合、C# (.NET) を使用します。 C# では、開発の高速化、メモリの安全性、豊富なライブラリ、優れたツールが提供されます。 WinUI 3、WPF、WinForms、.NET MAUI アプリなど、ほとんどのWindows アプリは C# を使用して最適に構築されます。

直接ハードウェア アクセス、最小限のランタイム オーバーヘッド、または既存の C++ コードベースとの相互運用が必要な場合は、C++ を使用します。 一般的な C++ シナリオには、ゲーム エンジン (DirectX)、ドライバー、システム レベルのユーティリティ、パフォーマンスに重要なコンポーネントが含まれます。

要因 C# (.NET) C++
開発速度 ✅ 高速 — マネージド メモリ、豊富なエコシステム ⚠️ 低速 — 手動リソース管理
実行時のパフォーマンス ✅モダンな .NET（AOT、Span<T>）との相性が抜群 ✅ 可能な限り最善 - GC の一時停止なし
メモリの安全性 ✅ ガベージ コレクター ⚠️ マニュアル — 漏えいや脆弱性のリスク
Windows API アクセス ✅ C#/WinRT プロジェクション経由 ✅ C++/WinRT プロジェクション経由
WinUI 3 のサポート ✅ 完全なサポート ✅ C++/WinRT による完全なサポート
クロスプラットフォーム ✅.NETは、Windows、Linux、macOS で実行されます ✅ プラットフォーム固有のコードを使用する
最適な用途 ビジネス アプリ、CRUD、サービス、UI が多いアプリ ゲーム、ドライバー、システム ツール、低待機時間

C# でアプリをビルドし、 P/Invoke (CsWin32) または C ++/WinRT コンポーネントを使用してパフォーマンスクリティカルなネイティブ コードを呼び出すという両方を混在させることもできます。

C# から Win32 API を呼び出す方法

ビルド時にタイプ セーフな P/Invoke シグネチャを作成するソース ジェネレーター である CsWin32 を使用します。 Microsoft.Windows.CsWin32 NuGet パッケージを追加し、必要な API をNativeMethods.txt ファイルに一覧表示し、生成されたPInvoke クラスを介して呼び出します。

CsWin32 は、手書きの[DllImport]宣言を置き換え、WinUI 3、WPF、WinForms、コンソール アプリなど、任意の C# プロジェクトで動作します。 詳細なチュートリアルについては、C# Windows アプリ (CsWin32) から Win32 API を呼び出す方法に関する記事を参照してください。

C++/WinRT とは何ですか。また、どのような場合に使用すべきですか？

C++/WinRT は、Windows ランタイム API の標準的な C++17 言語プロジェクションです。 WinRT API を利用または作成する C++ の Windows アプリをビルドするときに使用します。 C++/CX と Windows ランタイム C++ テンプレート ライブラリ (WRL) が置き換えられます。

次の場合に C++/WinRT を選択します。

  • C++ WinUI 3 アプリを構築している
  • 他の言語から利用される Windows ランタイム コンポーネントを作成する必要があります
  • C++/CX から移植する
C#/WinRT とは何ですか。どのような場合に必要ですか?

C#/WinRT は、C# の WinRT プロジェクション サポートを提供します。 ほとんどの場合、直接操作することはありません。Windowsを対象とするアプリ.NET、ターゲット フレームワーク モニカー (TFM) を介して WinRT API に自動的にアクセスします。 C# で Windows ランタイム コンポーネントを作成するとき、またはサードパーティの WinRT コンポーネントの相互運用機能アセンブリを生成する場合は、C#/WinRT が明示的に必要です。

パッケージ化、展開、更新

外部の場所でパッケージ化、パッケージ化解除、パッケージ化されるアプリの違いは何ですか?

パッケージ化されたアプリには、MSIX などのパッケージ内のファイル、ID、および展開情報が含まれています。 パッケージ化されていないアプリは、Windows パッケージ システムの外部でインストーラーまたは展開プロセスを使用し、既定ではパッケージ ID を持ちません。 外部の場所でパッケージ化されたアプリは、外部に配置されたバイナリとその既存のインストーラーと更新プロセスを保持しながら、小さな ID パッケージを使用します。

要件とトレードオフについては、「 パッケージ化の概要 」を参照してください。

パッケージ ID は必要ですか?

これは、アプリで使用するWindows機能によって異なります。 パッケージ ID は、パッケージ化されたバックグラウンド タスク、共有ターゲット、スタートアップ タスク、カスタム コンテキスト メニュー パッケージ拡張機能、マニフェスト ベースのファイルの種類とプロトコルの関連付け、および多くのWindows AI API などのシナリオに必要です。 Windows アプリ SDK プッシュ通知では、ID なしの限られたフォアグラウンド シナリオがサポートされますが、バックグラウンド配信と COM アクティブ化には ID が必要です。 WinUI 3 とローカル アプリの通知は、パッケージ ID なしで動作できます。

「パッケージ ID が必要な機能」を参照してください。 ID が必要であっても、既存のインストーラーを保持する必要がある場合は、 外部の場所でパッケージ化することを検討してください。

フレームワークに依存するデプロイと自己完結型デプロイの違いは何ですか?

フレームワークに依存するアプリでは、デバイスWindows アプリ SDK個別にインストールされたランタイム パッケージが使用されます。 これにより、アプリの展開サイズが縮小され、インストールされているフレームワークがサービス更新を受信できるようになります。 自己完結型アプリは、Windows アプリ SDK の依存関係をアプリに含めて配布し、デプロイ サイズを増やし、アプリの発行元が新しいアプリ バージョンで Windows アプリ SDK サービス更新を配布する責任を負います。

シングルトン パッケージなどの追加の MSIX パッケージに依存する API では、自己完結型アプリでも個別の展開またはランタイム サポート チェックが必要な場合があります。 パッケージ化と実行時のデプロイは、個別の決定です。 「Windows アプリ SDK 展開の概要」を参照してください。

WinUI 3 アプリはエンド ユーザー向けに自動的に更新されますか?

WinUI 3 アプリは、Microsoft Store、.appinstaller ファイル、MSI またはセットアップ実行可能ファイルを介して配信できます。 ストア パッケージは、ストアと組織の設定に従って、Microsoft Storeサービスを通じて更新できます。 .appinstaller のデプロイでは、その UpdateSettings が起動時またはバックグラウンド チェックを実行するように構成されている場合にのみ、自動更新がサポートされます。 MSI とセットアップの展開では、独自の更新メカニズムを提供または統合する必要があります。

MSBuild を使用せずにWindows アプリ SDKを使用できますか?

はい、一部のシナリオでは。 WinUI 3 XAML プロジェクトでは現在、MSBuild が必要ですが、Visual Studio は必要なく、dotnet buildコマンド ラインから MSBuild を呼び出すこともできます。 C++ および CMake プロジェクトの XAML 以外の Windows アプリ SDK API は、プレビュー Windows アプリ Development CLI を使用して使用することも、ランタイムを手動で統合することもできます。

Windows AI（人工知能）

WINDOWS AI API、Foundry Local、Windows ML を選択するにはどうすればよいですか?

最初の 3 つのテクノロジは、Windows 上の Microsoft Foundryの一部です。 同じアプリ内で、それらを互いに組み合わせ、クラウド モデルと組み合わせることができます。

  • Windows が管理するモデルとハードウェア アクセラレーションを備えた、すぐに使用できる機能には、Windows AI API を使用します。
  • Foundry Local を使用して、サポートされているオープンソース言語モデルと音声モデルをローカルで検出、ダウンロード、実行します。
  • Windows ML を使用して、使用可能な CPU、GPU、および NPU ハードウェアの実行プロバイダーで独自の ONNX モデルを実行します。
  • クラウドホスト型モデル、情報検索、一元管理されたガバナンス、またはターゲット デバイスで使用できない機能が必要な場合は、別のクラウド AI プラットフォームである Microsoft Foundry を使用します。

[Windows AI ソリューションの選択] のオプションを比較してください。 モデルの機能、プライバシー、接続性、待機時間、ハードウェアカバレッジ、展開サイズ、運用コストを考慮してください。

Windows AI 機能にはCopilot+ PCが必要ですか?

すべてではありません。 多くのWindows AI API にはCopilot+ PCが必要ですが、一部の API では特定の GPU または CPU もサポートされています。 Foundry Local および Windows ML では、現在のオペレーティング システム、モデル、ランタイム、実行プロバイダーの要件に従って、より広範なハードウェア構成がサポートされます。

Windows AI API ハードウェア テーブルと、特定の API またはモデルの要件を確認します。 実行時にサポートとモデルの準備状況を検出し、機能が使用できない場合は、AI を使わない代替手段、ローカル モデル、またはクラウドベースの代替手段を提供します。

Windows AI 機能はローカルとオフラインで実行できますか?

Yes. Windows AI API、Foundry Local、および Windows ML では、ユーザーのデバイスで推論を実行できます。これにより、待機時間を短縮し、入力データをローカルに保つことができます。 一部のモデルまたは実行プロバイダーは、最初にダウンロードまたはプロビジョニングする必要があり、セットアップまたは保守時にインターネット接続が必要になる場合があります。 クラウド AI サービスには接続が必要であり、当該サービスのデータ取り扱い条件に従ってサービスにデータを送信します。

モデルのダウンロードが必要なタイミングと、データがデバイス外に送信されるタイミングをユーザーに伝えます。 最初の実行、更新、フォールバックの完全なエクスペリエンスをテストするまで、機能をオフライン対応として記述しないでください。

AI ツールは、Windows アプリの構築や最新化に役立ちますか?

Yes. AI コーディング エージェントは、プロジェクトのスキャフォールディング、API の説明、コードの移行、テストの生成、ビルドの問題の診断に役立ちます。 GitHub Copilot、WinUI エージェント プラグイン、Microsoft Learn MCP Server、移行ワークフロー、AI 支援テスト向けのAI 支援 Windows 開発ガイダンスを使用します。

他の変更と同様に、生成されたコードを確認してテストします。 特に、API 名とバージョン、パッケージ機能、セキュリティに依存するコード、アクセシビリティ、UWP から WinUI 3 への置換を確認します。

AI 支援機能を出荷する前に考慮すべき点

機能の使用目的と制限を定義し、代表的なデータを使用して品質と安全性を評価し、必要に応じて AI の動作を開示し、ユーザー データを保護し、モデルまたは必要なハードウェアが使用できない場合はフォールバックを提供します。 シークレットと特権サービスの資格情報をクライアント アプリに含めず、重大な影響のある、または元に戻せないアクションの前にユーザーの確認を必要とします。 Windows における責任ある生成 AI の開発 と Windows 開発のためのセキュリティと責任ある AI を参照してください。

パフォーマンスと最適化

Windowsアプリをエンドユーザーに優しくするために何ができますか?

Windowsアプリケーション開発 - ベスト プラクティスおよびWindowsアプリのパフォーマンスと基礎の概要を参照してください。

Compatibility

ユーザーは WinUI 3 アプリを使用するために今後 Windows を更新する必要が生じることはありますか?

Windows アプリ SDK の最小対応 OS は Windows 10 バージョン 1809（ビルド 17763）です。 Microsoft のサポートを受けるには、最新のサービス更新プログラムが適用されたサポート対象の Windows アプリ SDK リリースと、現在もサポートされている Windows のエディション、バージョン、およびサービス チャネルが必要です。 個々の API には、新しいWindowsバージョンまたは特定のハードウェアが必要な場合があります。 サポートチャネルとリリース チャネルWindows アプリ SDK参照してください。

WinUI 3 アプリで Arm64 をターゲットにすることはできますか?

Yes. 最適なパフォーマンスと効率を得るためのネイティブ Arm64 アプリを構築します。 x64 依存関係を持つ大規模な C++ コードベースの場合、 Arm64EC ではモジュールを段階的に移行できます。 Arm のWindows 11では、Prism エミュレーションを使用して既存の x86 および x64 アプリを多数実行することもできますが、代表的な Arm デバイスでパフォーマンスと互換性をテストする必要があります。

非推奨と移行

UWP/WinUI for UWP は非推奨ですか?

UWP と WinUI 2 は正式には非推奨ではありません。 Visual Studio 2026 では、最新の.NETとネイティブ AOT を使用した UWP がサポートされますが、WinUI 2.8 は UWP の最新の安定した WinUI リリースのままです。 ただし、Microsoftでは、新しい汎用Windowsデスクトップ アプリ用の WinUI 3 とWindows アプリ SDKをお勧めします。

ネイティブ AOT を使用したモダン .NETの UWP サポートは一般提供されており、Visual Studio 2026 の既定の C# UWP プロジェクトの種類です。 既存の UWP アプリを .NET Native からモダン .NETに移行することは、UI を WinUI 3 に移行するのとは別の最新化手順です。 「.NETとネイティブ AOT を使用して UWP アプリを最新化する」を参照してください。

UWP / WinUI for UWP アプリを WinUI 3 に移行するのはいつですか?

UWP 開発者は、UWP とその機能セットに満足している場合、移行の圧力を感じるべきではありません。多くのアプリでは、UWP を使用し続けるのが適切な選択肢である可能性があります。

最新のWindows プラットフォームと.NETへの投資の恩恵を受けたいアプリは、WinUI 3 とWindows アプリ SDKに移行することを検討する必要があります。 UWP から Windows アプリ SDK への移行を参照してください。

どのような場合に、UWP と WinUI for UWP を使用したアプリを WinUI 3 に移行すべきではありませんか?

ターゲット デバイスまたはアプリ モデルで必要な場合 (Xbox アプリ、HoloLens 2D アプリ、標準の Surface Hub 環境用アプリなど) は、引き続き UWP を使用し続けてください。 Windows IoT Enterprise ではデスクトップ アプリ テクノロジがサポートされており、これには Windows アプリ SDK も含まれるため、IoT ターゲット自体が UWP を使用する理由にはなりません。

WPFは非推奨ですか？

No. WPFはサポートされており、モダンな.NET において、機能、パフォーマンス、アクセシビリティ、Fluent スタイルの改善が継続されています。 既存のWPFアプリや、要件がWPFに適合する新しいアプリにとって、引き続き適切な選択肢です。 新しい汎用 Windows デスクトップ アプリの場合、Microsoft の主な推奨事項は、Windows アプリ SDK を使用する WinUI 3 です。 GitHubのWPFロードマップを参照してください。

WinForms は非推奨ですか?

No. WinForms はサポートされており、引き続き機能更新プログラムを受け取ります。 GitHubのWindows フォームロードマップを参照してください。

Windows ランタイム (WinRT) は非推奨ですか?

No. WinRT は、複数の言語間の相互運用を可能にするアプリケーション バイナリ インターフェイス (ABI) です。 WinRT は COM の進化であり、Windows アプリ SDKは WinRT API を通じてほとんどの機能を提供します。

リリース ノート

Windows アプリ SDKのリリース ノートはどこで入手できますか?

安定版、プレビュー版、および試験段階のリリースについては、Windows アプリ SDKリリース ノートを参照してください。 Windows開発者向けの新機能ページには、最新の Windows SDK、Windows アプリ SDK、WinUI 3、ツール、プラットフォームの更新プログラムがまとめられます。

関連コンテンツ

  • 最終更新: