Windows デスクトップ アプリの認定要件
ドキュメントのバージョン: 10
ドキュメントの日付: 2015 年 7 月 29 日
このドキュメントには、Windows 10 デスクトップ アプリ認定プログラムに参加するためにデスクトップ アプリが満たす必要がある技術的要件と適格性の資格が含まれています。
ようこそ。
Windows プラットフォームは、製品とパートナーの広範なエコシステムをサポートしています。 製品に Windows ロゴを表示することは、Microsoft と会社の間の品質に対する関係と共有のコミットメントを表します。 お客様は、互換性基準を満たし、Windows プラットフォームで良好なパフォーマンスを発揮するため、製品の Windows ブランドを信頼しています。 Windows アプリ認定を正常に通過すると、アプリを Windows 互換センターに表示でき、サイトに認定ロゴを表示できます。
Windows アプリ認定プログラムは、Windows ブランドを搭載したサードパーティ製アプリが Windows を実行している PC に簡単にインストールでき、信頼性を確保するために役立つプログラムと技術要件で構成されています。 お客様は、購入するシステムの安定性、互換性、信頼性、パフォーマンス、品質を評価します。 Microsoft は、PC 用 Windows プラットフォームで実行するように設計されたソフトウェア アプリのこれらの要件を満たすために投資に重点を置いています。 これらの取り組みには、Windows ソフトウェアを実行している PC でのエクスペリエンスの一貫性、パフォーマンスの向上、セキュリティの強化のための互換性テストが含まれます。 Microsoft 互換性テストは、業界パートナーと共同で設計されており、業界の発展と消費者の需要に応じて継続的に改善されています。
Windows アプリ認定キットは、これらの要件への準拠を検証するために使用され、Windows 7、Windows 8、またはWindows 8.1での検証に使用されていた以前のバージョンのキットに置き換えられます。 Windows アプリ認定キットは、Windows Software Development Kit (SDK) for Windows 10に含まれるコンポーネントの 1 つです。
アプリの適格性
アプリが Windows 10 デスクトップ アプリ認定資格を取得するには、次の条件と、このドキュメントに記載されているすべての技術的要件を満たす必要があります。
- スタンドアロン アプリである必要があります
- ローカル Windows 10 PC で実行する必要があります
- 認定された Windows Server アプリのクライアント コンポーネントにすることができます
- コードと機能が完成している必要があります
- サポートされているエンタープライズ シナリオを除き、ファイルとレジストリ キーを介してなど、ローカル メカニズムを介して Windows ストア アプリと通信することはできません
- Windows システムのセキュリティや機能を危険にさらしたり、侵害したりしてはなりません
- 一意の名前を持つ必要があり、他のユーザーが商標登録することはできません
- すべての外部コンポーネントは、個別に認定されているか、Windows アプリ認定キットに準拠している必要があります
- バンドルされているアプリのオプトアウト オプションが必要です
デスクトップ アプリがウイルス対策および/またはスパイウェア対策 (マルウェア対策) 製品カテゴリに送信される場合は、マルウェア対策プラットフォームガイドラインに準拠している必要があります。 WINDOWS 10 ANTIMALWARE API ライセンスおよび登録契約は、提出前に署名され、有効である必要があります。 パートナーは、 のメンバーであるか、または契約に記載されている組織のメンバーであり、良好な立場にある研究者を持っている必要があります。 この機能は、契約に記載されている組織によってWindows 10で認定されている必要があります。 アプリは、過去 12 か月間に少なくとも 1 回テストされ、検出とクリーニングの認定を受けている必要があります。
1.アプリは互換性があり、回復性があります
アプリがクラッシュしたり、応答を停止したりすると、ユーザーが多くの不満を引き起こします。 アプリは回復性と安定性が期待されており、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。
- 1.1 アプリは、Windows 互換性モード、AppHelp メッセージ、およびその他の互換性修正プログラムに依存してはなりません
1.2 アプリには互換性マニフェストが必要で、サポートされているバージョンの Windows に適した GUID を使用する必要があります
1.3 SetProcessDPIAware を呼び出すのではなく、アプリケーションのアセンブリ マニフェストを使用してアプリを DPI 対応にする必要がある
1.4 アプリが VB6 ランタイムに依存しないようにする
1.5 アプリは、HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dllsを使用して Win32 API 呼び出しをインターセプトするために任意の DLL を読み込まてはなりません。
2. アプリは Windows セキュリティのベスト プラクティスに従う必要がある
Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃対象領域への露出を回避するのに役立ちます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用するエントリ ポイントです。 最悪のセキュリティ脆弱性の 1 つは、特権の昇格です。
テスト 2.1 2.6 は、Windows 7、Windows 8、またはWindows 8.1でテストされたデスクトップ アプリにのみ適用されることに注意してください。
- 2.1 アプリで実行可能ファイルをセキュリティで保護するには、強力で適切な ACL を 使用する必要があります
2.2 アプリでディレクトリをセキュリティで保護するには、強力で適切な ACL を 使用する必要がある
2.3 アプリでは、レジストリ キーをセキュリティで保護するために、強力で適切な ACL を 使用する必要があります
2.4 アプリでは、オブジェクトを含むディレクトリをセキュリティで保護するために、強力で適切な ACL を 使用する必要があります
2.5 アプリは、改ざんに対して脆弱なサービスへの管理者以外のアクセスを減らす必要がある
2.6 アプリでは、高速再起動のサービスが 24 時間ごとに 2 回以上再起動されないようにする必要があります
注: アクセスは、必要なエンティティにのみ付与する必要があります。
Windows アプリ認定プログラムは、WINDOWS システムを危険にさらさない方法で ACL とサービスが実装されていることを確認することで、Windows 攻撃サーフェスが公開されていないことを確認します。
3. アプリで Windows セキュリティ機能がサポートされる
Windows オペレーティング システムには、システムのセキュリティとプライバシーをサポートする多くの機能があります。 オペレーティング システムの整合性を維持するには、アプリでこれらの機能をサポートする必要があります。 不適切にコンパイルされたアプリでは、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。
- 3.1 アプリで AllowPartiallyTrustedCallersAttribute (APTCA) を使用して、厳密な名前付きアセンブリへの安全なアクセスを確保する必要がある
3.2 安全な例外処理を保証するには、/SafeSEH フラグを使用してアプリをコンパイルする必要があります
3.3 データの実行を防ぐために、/NXCOMPAT フラグを使用してアプリをコンパイルする必要がある
3.4 アドレス空間レイアウトのランダム化 (ASLR) に /DYNAMICBASE フラグを使用してアプリをコンパイルする必要がある
3.5 アプリで共有 PE セクションの読み取り/書き込みを行わない
4.アプリは、システム再起動マネージャーのメッセージに従う必要があります
ユーザーがシャットダウンを開始すると、通常、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、ちょうど自分のコンピュータをオフにしたいかもしれません。 アプリは、シャットダウンをブロックしないことで、この望みを尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない場合があります。アプリは重大なシャットダウンの可能性に備える必要があります。
- 4.1 アプリで重大なシャットダウンを適切に処理する必要がある
- 重大なシャットダウンでは、FALSE をWM_QUERYENDSESSIONに返すアプリはWM_ENDSESSION送信され、閉じられますが、WM_QUERYENDSESSIONに応答してタイムアウトしたアプリは終了します。
- WM\_QUERYENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
コンソール アプリは SetConsoleCtrlHandler を呼び出して、シャットダウン通知を処理する関数を指定できます。 サービス アプリは RegisterServiceCtrlHandlerEx を呼び出して、シャットダウン通知を受け取る関数を指定できます。
- WM\_ENDSESSION と LPARAM = ENDSESSION\_CLOSEAPP(0x1)。
少なくとも、アプリはユーザー データを保存して準備し、再起動後に必要な情報を指定する必要があります。
5.アプリは、クリーン、元に戻せるインストールをサポートする必要があります
クリーン、元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。
- 5.1 アプリは、クリーン、元に戻せるインストールを適切に実装する必要があります
- DisplayName
- InstallLocation
- Publisher
- UninstallString
- VersionMajor または MajorVersion
- VersionMinor または MinorVersion
- インストールが失敗した場合、アプリはそれをロールバックし、マシンを以前の状態に復元できる必要があります。
- インストール、アンインストール、または更新の最後に、コンピューターの再起動が唯一のオプションになることはありません。 ユーザーには、後で再起動する機会が必要です。
- Windows インベントリ ツールとテレメトリ ツールには、インストールされているアプリに関する完全な情報が必要です。 MSI ベースのインストーラーを使用している場合、MSI によって以下のレジストリ エントリが自動的に作成されます。 MSI インストーラーを使用していない場合、インストール モジュールはインストール時に次のレジストリ エントリを作成する必要があります。
6. アプリは、ファイルとドライバーにデジタル署名する必要があります
Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染しているかどうかなど、ファイルが改ざんされているかどうかを検出することもできます。 カーネル モード コード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これにより、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティが向上します。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 また、カーネル モジュールの署名が正しく検証されない場合に、診断およびシステム監査ログ イベントを生成します。
- 6.1 すべての実行可能ファイル (.exe、.dll、.ocx、.sys、.cpl、.drv、.scr) は Authenticode 証明書で署名する必要があります
6.2 アプリによってインストールされるすべてのカーネル モード ドライバーには、Windows ハードウェア認定プログラムを通じて取得された Microsoft 署名が必要です。 すべてのファイル システム フィルター ドライバーは、Microsoft によって署名されている必要があります。
6.3 例外と免除
- 権利放棄は、署名されていないサードパーティ再頒布可能パッケージ (ドライバーを除く) に対してのみ考慮されます。 この放棄を許可するには、再頒布可能パッケージの署名付きバージョンを要求する通信の証明が必要です.
7. アプリは、オペレーティング システムのバージョンに基づいてインストールまたはアプリの起動をブロックしませんチェック
技術的な制限がない場合、ユーザーがアプリのインストールや実行を人為的にブロックされていないことが重要です。 一般に、アプリが Windows Vista 以降のバージョンの Windows 用に作成された場合、オペレーティング システムのバージョンをチェックする必要はありません。
- 7.1 アプリでバージョンチェックを実行してはいけません
- Windows 7、Windows 8、Windows 8.1でも実行される 1 つのパッケージとして提供され、オペレーティング システムのバージョンをチェックして、特定のオペレーティング システムにインストールするコンポーネントを決定する必要があるアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムの最小バージョンのみをチェックするアプリ (実行時ではなくインストール時のみ) で、アプリ マニフェストの最小バージョン要件を適切に一覧表示するアプリ。
- 承認された API 呼び出しのみを使用してオペレーティング システムのバージョンをチェックするセキュリティ アプリ (ウイルス対策、ファイアウォールなど)、システム ユーティリティ (デフラグ、バックアップ、診断 ツールなど)。
- 特定の機能が必要な場合は、その機能自体が使用可能かどうかをチェックします。 Windows 7 が必要な場合は、Windows 7 以降 (>= 6.2) のチェック。 これにより、検出コードは今後のバージョンの Windows で引き続き機能します。 ドライバー インストーラーとアンインストール モジュールは、オペレーティング システムのバージョンをチェックしないでください。
8. アプリがセーフ モードでサービスまたはドライバーを読み込まない
セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 ドライバーとサービスは、ストレージ デバイス ドライバーなどの基本的なシステム操作や、ウイルス対策スキャナーなどの診断と回復の目的で必要な場合を除き、セーフ モードで読み込まれるように設定しないでください。 既定では、Windows がセーフ モードの場合、Windows にプレインストールされたドライバーとサービスのみが開始されます。
- 8.1 例外と免除
- セーフ モードで開始する必要があるドライバーとサービスには免除が必要です。 権利放棄要求には、SafeBoot レジストリ キーへの該当するドライバーまたはサービスの書き込みを含め、アプリまたはサービスをセーフ モードで実行する必要がある技術的な理由について説明する必要があります。 アプリ インストーラーでは、次のレジストリ キーを使用して、このようなすべてのドライバーとサービスを登録する必要があります。
メモ： これらのドライバーとサービスをテストして、エラーなしでセーフ モードで機能することを確認する必要があります。
9. アプリは、ユーザー アカウント制御のガイドラインに従う必要があります
一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、アプリは多くの場合、過剰なユーザー権限と Windows 特権を要求します。 リソースへのアクセスを制御することで、ユーザーはシステムを制御し、不要な変更から保護できます。 望ましくない変更は、コンピューターを制御するルートキットなどの悪意のあるもの、または特権が制限されているユーザーによって行われたアクションの結果である可能性があります。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要な最小限のアクセス標準ユーザー コンテキストを提供することです。 ユーザー アカウント制御 (UAC) ガイドラインに従うと、アプリが必要なときに必要なアクセス許可をアプリに提供します。システムは常にセキュリティ 上のリスクにさらされることはありません。 ほとんどのアプリでは、実行時に管理者特権は必要ありません。標準ユーザーとして実行するだけで十分です。
- 9.1 アプリには、実行レベルを定義し、実行するためにアプリに必要な特権をオペレーティング システムに通知するマニフェストが必要です
- 実行レベルが highestAvailable に設定されている管理ツールまたはシステム ツール、および/または requireAdministrator
- ユーザー インターフェイス特権分離 (UIPI) をバイパスするには、アクセシビリティまたは UI オートメーション フレームワーク アプリのみが uiAccess フラグを true に設定します。 アプリの使用率を適切に開始するには、このフラグは Authenticode 署名済みであり、ファイル システム内の保護された場所 (Program Files) に存在する必要があります。
- アプリ マニフェストのマーキングは、DLL ではなく EXEs にのみ適用されます。 これは、UAC がプロセスの作成時に DLL を検査しないためです。 UAC ルールは Microsoft サービスには適用されないことにも注目してください。 マニフェストは、埋め込みまたは外部にすることができます。
マニフェストを作成するには、.exe.manifest という名前 <app_name> ファイルを作成し、EXE と同じディレクトリに格納します。 アプリに内部マニフェストがある場合、外部マニフェストは無視されることに注意してください。 次に例を示します。
<requestedExecutionLevel level=""asInvoker |highestAvailable |requireAdministrator"" uiAccess=""true|false"""/>
- 管理機能は、管理特権で実行される別のプロセスに移動する必要があります。 スタート メニューのプログラム グループからアクセスできるアプリなど、ユーザー向けのアプリで、昇格を要求するには Authenticode 署名が必要です。
- 昇格された特権 (requireAdministrator または highestAvailable) を使用してメイン プロセスを実行するアプリでは、免除が必要です。 メイン プロセスは、アプリへのユーザーのエントリ ポイントとして識別されます。 免除は、次のシナリオで考慮されます。
10. アプリは、既定で正しいフォルダーにインストールする必要があります
ユーザーは、選択した場所にアプリをインストールするオプションを維持しながら、ファイルの既定のインストール場所と一貫性があり、セキュリティで保護されたエクスペリエンスを持っている必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 Windows には、プログラムとソフトウェア コンポーネント、共有アプリ データ、およびユーザー固有のアプリ データを格納するためのファイル システム内の特定の場所が用意されています
- 10.1 アプリは、既定で Program Files フォルダーにインストールされている必要があります
- レジストリ実行キー HKLM と、またはソフトウェア\Microsoft\Windows\CurrentVersion の HKCU
- レジストリ実行キー HKLM、またはソフトウェア\Wow6432Node\Microsoft\windows\CurrentVersion の HKCU
- [スタート] メニュー [AllPrograms > STARTUP]
- %ProgramFiles% のネイティブ 32 ビットおよび 64 ビット アプリの場合は 、x64 で実行されている 32 ビット アプリの場合は %ProgramFiles(x86)% です。 このフォルダーに対して構成されたセキュリティ アクセス許可のため、ユーザー データまたはアプリ データをこの場所に格納しないでください。
- たとえば、アプリで次の設定を行うべきではありません。
- フォントやドライバーなどのファイルをインストールするための正しい方法を使用します。
- アプリがインストールされると、データを格納する適切なユーザーの場所がありません。 インストール後にコンピューター レベルで既定の関連付け動作を変更しようとすると、アプリによって失敗します。 代わりに、既定値をユーザー単位レベルで要求する必要があります。これにより、複数のユーザーが互いの既定値を上書きできなくなります。
- グローバル アセンブリ キャッシュ (GAC) に書き込むアプリには放棄が必要です。.NET アプリでは、アセンブリの依存関係をプライベートに保ち、アセンブリの共有が明示的に必要でない限り、アプリ ディレクトリに格納する必要があります。
11. アプリはマルチユーザー セッションをサポートする必要がある
Windows ユーザーは、競合や中断なしで同時セッションを実行できる必要があります。
- 11.1 アプリは、ローカルまたはリモートで複数のセッションで実行する場合、アプリの通常の機能が悪影響を受けないようにする必要があります
11.2 アプリの設定とデータ ファイルをユーザー間で保持しない
11.3 ユーザーのプライバシーと設定をユーザーのセッションに分離する必要がある
11.4 アプリのインスタンスを互いに分離する必要がある
- これは、あるインスタンスのユーザー データがアプリの別のインスタンスに表示されないことを意味します。 アクティブでないユーザー セッションのサウンドは、アクティブなユーザー セッションでは聞こえないはずです。 複数のアプリ インスタンスが共有リソースを使用する場合、アプリは競合がないことを確認する必要があります。
- UAC の要件を参照してください。
12. アプリは x64 バージョンの Windows をサポートする必要がある
64 ビット ハードウェアがより一般的になるにつれて、ユーザーはアプリ開発者が 64 ビット アーキテクチャの利点を利用することを期待しています。アプリを 64 ビットに移行するか、32 ビット バージョンのアプリが 64 ビット バージョンの Windows で十分に実行されることを期待しています。
- 12.1 アプリは 64 ビットをネイティブにサポートする必要があります。または、64 ビット バージョンの Windows との互換性を維持するために、少なくとも 32 ビットの Windows ベースのアプリを 64 ビット システムでシームレスに実行する必要があります
12.2 アプリとそのインストーラーに 16 ビット コードを含めたり、16 ビット コンポーネントに依存したりしてはなりません
12.3 アプリのセットアップでは、64 ビット アーキテクチャ用の適切なドライバーとコンポーネントを検出してインストールする必要があります
12.4 シェル プラグインは、64 ビット バージョンの Windows で実行する必要があります
12.5 WoW64 エミュレーターで実行されているアプリは、Wow64 仮想化メカニズムを転覆またはバイパスしないでください
- アプリが WoW64 エミュレーターで実行されているかどうかを検出する必要がある特定のシナリオがある場合は、IsWow64Process を呼び出して実行する必要があります。
まとめ
これらの要件が進化するにつれて、以下のリビジョン履歴の変更に注目します。 最適な作業を行うには安定した要件が不可欠であるため、Microsoft は、行う変更が持続可能であることを確認し、アプリの保護と強化を続けるよう努めます。
素晴らしいカスタマー エクスペリエンスを提供する取り組みに参加していただきありがとうございます。
改定履歴
| Date | バージョン | リビジョンの説明 | ドキュメントへのリンク |
|---|---|---|---|
| 2011 年 12 月 20 日 | 1.0 | プレビュー用のドキュメントの最初のドラフト。 | |
| 2012 年 1 月 26 日 | 1.1 | セクション #2 に更新します。 | 1.1 |
| 2012 年 5 月 31 日 | 1.2 | 概要テスト結果を追加しました | 1.2 |
| 2012 年 6 月 29 日 | 3.0 | 最終的なドキュメントWindows 8する | 3.0 |
| 2013 年 6 月 18 日 | 3.1 | ドキュメントのWindows 8.1 | 3.1 |
| 2014 年 2 月 20 日 | 3.2 | 内部更新 | |
| 2014 年 3 月 18 日 | 3.3 | Windows 8.1 Update 1 | 3.3 |
| 2015 年 7 月 29 日 | 10 | Windows 10 更新プログラム | 10 |
デスクトップ アプリ認定の詳細を確認する
| 要件 | 説明 |
| 互換性と回復性 | クラッシュ&ハングは、ユーザーにとって大きな中断であり、フラストレーションを引き起こします。 アプリは回復性と安定性が期待されるため、このような障害を排除することで、ソフトウェアの予測性、保守性、パフォーマンス、信頼性を高めるのに役立ちます。 互換性を保つだけでなく、適切な GUID を宣言するために、ユーザー向けのアプリ エントリ ポイントをマニフェストする必要があります。 ユーザー向けのアプリ エントリ ポイントは、高 DPI 対応のためにマニフェストする必要があり、HIGH-DPI をサポートするために適切な API が呼び出されていること。 詳細については、次のトピックを参照してください。 |
| Windows セキュリティのベスト プラクティスに従う | Windows セキュリティのベスト プラクティスを使用すると、Windows 攻撃対象領域への露出を回避するのに役立ちます。 攻撃対象のサーフェスは、悪意のある攻撃者がターゲット ソフトウェアの脆弱性を利用してオペレーティング システムを悪用するために使用するエントリ ポイントです。 最悪のセキュリティ脆弱性の 1 つは、特権の昇格です。 詳細については、次のトピックを参照してください。 |
| Windows セキュリティ機能のサポート | Windows オペレーティング システムでは、システムのセキュリティとプライバシーをサポートするための多くの手段が実装されています。 アプリケーションでは、OS の整合性を維持するために、これらのメジャーをサポートする必要があります。 アプリケーションを不適切にコンパイルすると、バッファー オーバーランが発生し、サービス拒否が発生したり、悪意のあるコードが実行されたりする可能性があります。 詳細については、「 BinScope ツールリファレンス」を参照してください。 |
| システム再起動マネージャー メッセージに従う | ユーザーがシャットダウンを開始すると、ほとんどの場合、シャットダウンが成功することを強く望みます。彼らは急いでオフィスを出て、自分のコンピュータをオフにしたいだけかもしれません。 アプリは、シャットダウンをブロックしないことで、この望みを尊重する必要があります。 ほとんどの場合、シャットダウンは重要ではない場合があります。アプリは重大なシャットダウンの可能性に備える必要があります。 |
| クリーンリバーシブルインストール | クリーン、元に戻せるインストールにより、ユーザーはシステム上のアプリを正常に管理 (展開および削除) できます。 詳細については、「 How to: Install Prerequisites with a ClickOnce Application」を参照してください。 |
| ファイルとドライバーにデジタル署名する | Authenticode デジタル署名を使用すると、ユーザーはソフトウェアが本物であることを確認できます。 また、ファイルがウイルスに感染した場合など、ファイルが改ざんされているかどうかを検出することもできます。 カーネル モード コード署名の適用は、コード整合性 (CI) と呼ばれる Windows 機能です。これにより、ファイルのイメージがメモリに読み込まれるたびにファイルの整合性を検証することで、オペレーティング システムのセキュリティが向上します。 CI は、悪意のあるコードがシステム バイナリ ファイルを変更したかどうかを検出します。 また、カーネル モジュールの署名が正しく検証されない場合に、診断およびシステム監査ログ イベントを生成します。 |
| オペレーティング システムのバージョンに基づいてインストールまたはアプリの起動をブロックしないチェック | 技術的な制限がない場合、ユーザーがアプリのインストールや実行を人為的にブロックされていないことが重要です。 一般に、アプリが Windows Vista 以降のリリース用に作成された場合、オペレーティング システムのバージョンをチェックする理由はありません。 詳細については、「 オペレーティング システムのバージョン管理」を参照してください。 |
| セーフ モードでサービスとドライバーを読み込まない | セーフ モードを使用すると、ユーザーは Windows の診断とトラブルシューティングを行うことができます。 システムの基本的な操作 (ストレージ デバイス ドライバーなど) や診断と回復の目的 (ウイルス対策スキャナーなど) に必要な場合を除き、ドライバーとサービスをセーフ モードで読み込むよう設定しないでください。 既定では、セーフ モードでは、Windows にプレインストールされていないほとんどのドライバーとサービスは起動しません。 システムが基本的な操作または診断と回復の目的で必要とする場合を除き、これらは無効のままにする必要があります。 詳細については、次のトピックを参照してください。 |
| ユーザー アカウント制御 (UAC) ガイドラインに従う | 一部の Windows アプリは管理者アカウントのセキュリティ コンテキストで実行され、多くは過剰なユーザー権限と Windows 特権を必要とします。 リソースへのアクセスを制御することで、ユーザーは不要な変更に対してシステムを制御できます (望ましくない変更は、マシンを密に引き継ぐルートキットや、従業員が職場のコンピューターに禁止ソフトウェアをインストールするなど、特権が制限されているユーザーからのアクションなど、悪意のある可能性があります)。 リソースへのアクセスを制御するための最も重要なルールは、ユーザーが必要なタスクを実行するために必要な最小限のアクセス標準ユーザー コンテキストを提供することです。 UAC ガイドラインに従うと、必要に応じてアプリに必要なアクセス許可が提供され、システムは常にセキュリティ 上のリスクにさらされることはありません。 詳細については、次のトピックを参照してください。 |
| 既定で正しいフォルダーにインストールする | ユーザーは、選択した場所にアプリをインストールするオプションを維持しながら、ファイルの既定のインストール場所と一貫性のある安全なエクスペリエンスを持っている必要があります。 また、複数のユーザーが互いのデータと設定を破損または上書きすることなく、同じコンピューターを使用できるように、アプリ データを正しい場所に格納する必要があります。 詳細については、「 インストール/アンインストール要件の概要」を参照してください。 |
| マルチユーザー セッションのサポート | Windows ユーザーは、競合や中断なしで同時セッションを実行できる必要があります。 詳細については、「 リモート デスクトップ サービスプログラミングガイドライン」を参照してください。 |
| x64 バージョンの Windows をサポートする | 64 ビット ハードウェアの普及に伴い、ユーザーはアプリ開発者がアプリを 64 ビットに移行することで 64 ビット アーキテクチャの利点を活用するか、32 ビット バージョンのアプリが 64 ビット バージョンの Windows で十分に実行されることを期待しています。 |
こちらもご覧ください
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示