サービスとしての Windows アプリケーション開発

適用対象

• Windows 11
• Windows 10
• Windows 10 Mobile
• Windows 10 IoT Core

現在の環境では、ユーザーはデバイス中心のエクスペリエンスで期待を抱くことが多いため、完全な製品サイクルを年ではなく月で測定する必要があります。 また、新しいリリースは頻繁に入手可能にする必要があり、ユーザーへの影響を最小限に抑えて展開できる必要があります。 Microsoft は革新、開発、配信のための新しいアプローチを実装することで、これらの要件を満たすように Windows 10 を設計しました。このアプローチは、サービスとしての Windows (WaaS) と呼ばれます。 高い品質レベルを維持しながら、非常に短い製品サイクルを実現するためにキーとなるのは、Microsoft が Windows 10 向けに実装したテストに対するコミュニティ中心の革新的なアプローチです。 Windows Insider として知られるこのコミュニティは、世界中の何百万ものユーザーで構成されています。 Windows Insider ユーザーはコミュニティにオプトインすると、製品サイクルの経過と共に数多くのビルドをテストし、Insider プレビュー ビルドという反復的な方法で Microsoft にフィードバックを提供します。

Insider プレビュー ビルドとして配布されるビルドは、実際の使用中にビルドが適切に実行されるかどうかに関する重要なデータを Windows エンジニアリング チームに提供します。 また、Windows Insider による Insider プレビュー ビルドを利用することで、Microsoft は以前よりはるかに多様なハードウェア、アプリケーション、およびネットワーク環境でビルドをテストし、より早く問題を特定することができます。 その結果、Microsoft はコミュニティに重点を置いた Insider プレビュー ビルドによって、これまでより速いペースで革新的機能を配信でき、より高品質な一般リリースを公開できると考えています。

Windows 10 および Windows 11 のリリースの種類と更新間隔

Microsoft は Windows Insider に Insider プレビュー ビルドをリリースしますが、それに加えて継続的に次の 2 種類の Windows 10 および Windows 11 リリースを広く一般に公開します。

機能更新プログラム 既に Windows 10 を実行しているデバイスに、最新の機能とエクスペリエンスをインストールします。 機能更新プログラムには Windows の全体のコピーが含まれているため、Windows 7 または Windows 8.1 を実行している既存のデバイス、およびオペレーティング システムがインストールされていない新しいデバイスに Windows 10 をインストールするためにも使用できます。 Microsoft では、更新プログラムを半年に一度公開することを想定しています。

品質更新プログラム セキュリティの問題解決やその他の重要なバグ修正を提供します。 品質更新プログラムは、現在サポートされている個々の機能を改善するために、毎月 1 回以上の間隔で提供されます。 Microsoft は、Update Tuesday (Patch Tuesday とも呼ばれます) の品質更新プログラムの公開を継続します。 また、Microsoft はユーザーのニーズへの対応が必要なとき、Update Tuesday のプロセス以外で Windows 10 向けの追加の品質更新プログラムを公開することがあります。

Windows 10 の開発時、ユーザーが求める機能やエクスペリエンスを Microsoft がこれまでより迅速に提供できるように、Windows 製品のエンジニアリングおよびリリース サイクルを合理化しました。 また、機能更新プログラムと品質更新プログラムを配信およびインストールするための新しい手段を開発しました。これにより、展開および継続的な管理が簡略化され、最新の Windows の機能とエクスペリエンスによって最新の環境に保たれる従業員の基盤が広がり、総保有コストが削減されます。 それに伴い、半期チャネル、および長期的なサービス チャネル (LTSC) と呼ばれる新しいサービス オプションを実装しました。これらは、エンタープライズ環境で以前より多くのデバイスをより新しい状態に保つための実際的なソリューションを提供します。

次の表は、さまざまなサービス チャネルと、それらの重要な特性を示しています。

詳しくは、「更新とアップグレードに関する Windows 10/11 のサービス オプション」をご覧ください。

サービスとしての Windows におけるアプリのサポート

従来のアプリ サポートのアプローチは、Windows のリリースに応じて新しいアプリのバージョンをリリースするというものでした。 このアプローチは、基になる OS で行われた仕様変更により、アプリケーションに不具合が発生する可能性があることを前提としています。 このモデルでの開発と検証には独自のサイクルがあり、そのため ISV パートナーは Windows のリリース間隔に合わせる必要がありました。

サービスとしての Windows のモデルで、Microsoft は基になる OS の互換性の維持に取り組んでいます。 そのため Microsoft は、仕様変更によってアプリのエコシステムに悪影響が出ないように、一致協力して取り組んでいきます。 このシナリオでは、Windows ビルドがリリースされた場合、ほとんどのアプリ (カーネルに依存しないアプリ) は引き続き動作します。

この変更の観点から、ISV パートナーの皆様には、アプリのリリースとサポートを特定の Windows ビルドから切り離すことをお勧めします。 アプリケーション ライフサイクルのアプローチを使用すると、Microsoft と ISV パートナーの共通のお客様に対するサービスが向上します。 つまり、アプリケーションのバージョンがリリースされると、このバージョンは特定の期間サポートされます。これはその間に多くの Windows ビルドがリリースされても関係ありません。 ISV は、そのアプリの特定のバージョンがライフサイクルでサポートされている限り、サポートを提供します。 Microsoft は、Windows について同様のライフサイクル アプローチに従っています。こちらをご覧ください。

このアプローチでは、Windows のリリースに合わせてアプリのスケジュールを維持せずに済むため、負担が軽減されます。 ISV パートナーは、独自の間隔で機能更新プログラムや品質更新プログラムを自由にリリースできます。 Microsoft は、パートナーが Windows のリリースに依存することなく、それぞれの顧客ベースを最新のアプリ更新プログラムによって継続的に更新できると考えています。 さらに、Windows ビルドがリリースされるたびに、お客様が明示的にサポート ステートメントを探す必要はなくなります。 OS の異なるバージョン間でアプリがどのようにサポートされるかを説明するサポート ステートメントの例を次に示します。

アプリケーション ライフサイクルのサポート ステートメントの例

Contoso はソフトウェア開発会社であり、エンタープライズ市場で大きなシェアを持つ、Mojave という人気のあるアプリを所有しています。 Contoso は次期メジャー リリースである Mojave 14.0 をリリースし、リリース日から 3 年間のメイン ストリーム サポートを宣言しました。 メインストリーム サポートの期間中、すべての更新プログラムとサポートは、ライセンス認証された製品については無料です。 また、Contoso は、2 年間の延長サポートも宣言しました。その期間は猶予期間として、お客様が更新プログラムとサポートを購入できます。 延長サポート終了日を過ぎると、この製品バージョンはサポートされません。 メインストリーム サポート期間中、Contoso はリリースされたすべての Windows ビルドで Mojave 14.0 をサポートします。 また、Windows の製品リリースとは関係なく、必要に応じて Mojave の更新プログラムをリリースします。

以下のセクションでは、基になる OS の互換性を維持するために Microsoft が実施している手順について、詳しい情報を示します。 OS とアプリを組み合わせたエコシステムの互換性を維持するために実行できる手順のガイダンスも記載します。 さらに、Windows ビルドのリリース前に Windows フライティング ビルドを使ってアプリの不具合を検出する方法について説明したセクションがあります。 最後に、インストルメンテーションと利用統計情報に基づくアプローチを使用して Windows ビルドの品質を高める方法について説明します。 ISV の皆様に、自社のアプリのポートフォリオに対して同様のアプローチを採用することをお勧めします。

Windows 7 以降に行われたアプリの互換性を確保するための重要な変更

Microsoft は互換性が開発者にとって重要なことを理解しています。 ISV と開発者は、サポートされているすべてのバージョンの Windows オペレーティング システムで、アプリが予期したとおりに動作することを確認する必要があります。 一般ユーザーと企業は、アプリに重要な投資をしているため、購入したアプリが引き続き機能することを確認したいと考えます。 Microsoft は、購入決定時に最優先される条件が互換性であることを認識しています。 アプリがベスト プラクティスに基づいて正しく記述されていれば、新しい Windows のバージョンがリリースされたときに、コード チャーンが大幅に少なくて済み、断片化が抑えられます。このようなアプリは、メンテナンスに必要なエンジニアリングの投資の削減と、市場投入期間の短縮をもたらします。

Windows 7 のサポート期間中、互換性に対するアプローチは事後対応の度合いが大きいものでした。 Windows 8 では互換性に対する見方を変えて、後から合わせるのではなく、Windows 自体のしくみとして設計による互換性を確保する取り組みを始めました。

Windows 10 は、これまでの OS の中で、設計による互換性を最大限に高めた OS です。 これを実現した重要な方法をいくつか紹介します。

• アプリの利用統計情報:Windows エコシステムにおけるアプリの需要を把握して互換性テストを通知するときに役立ちます。
• ISV とのパートナーシップ:外部パートナーとの直接的な共同作業によってパートナーにデータを提供し、ユーザーに発生する問題を解決します。
• 設計のレビュー、アップストリームの検出:Windows の仕様変更の数を減らすために機能チームと協力します。 互換性レビューは、機能チームが通過しなければならない関門です。
• コミュニケーション:API の変更をより厳密にコントロールし、コミュニケーションを改善しました。
• フライティングとフィードバック ループ:Windows Insider ユーザーは、フライティング後のビルドを受け取ります。このため、お客様に最終ビルドをリリースする前に互換性の問題が見つかりやすくなります。 このフィードバック プロセスでバグが明らかになるだけでなく、ユーザーが求めている機能を提供していることを確認できます。

アプリの互換性のためのベスト プラクティス

Microsoft は、診断データと使用状況データを、問題の特定とトラブルシューティング、製品とサービスの向上、パーソナル化されたエクスペリエンスの提供に利用しています。 Microsoft が収集する使用状況データには、Windows エコシステム内の PC で実行しているアプリまでが含まれます。 お客様が何を使用しているかに基づいて、新しいバージョンの Windows OS に対してテストする対象として、それらのアプリ、デバイス、ドライバーのリストを作成します。 Windows 10 は、これまでで最も互換性が高いバージョンの Windows となっており、人気のある数千ものアプリに対して 90% を超える互換性があります。 Windows 互換性チームは通常、問題が見つかった場合は ISV パートナーに連絡してフィードバックを提供し、協力して解決策を作成できます。 理想は、一般的なユーザーの Windows をシームレスに更新できるようにすることです。しかも、OS またはユーザーがよく使用する生産性アプリやエンターテイメント アプリのどちらについても、機能が失われないようにする必要があります。

以下のセクションでは、アプリと Windows 10 の互換性を確保するために、Microsoft がお勧めするベスト プラクティスをいくつか紹介します。

Windows バージョン確認

Windows 10 で OS のバージョンがインクリメントされています。 つまり、内部バージョン番号が 10.0 に変更されています。 Microsoft はこれまでと同様に、OS のバージョン変更後のアプリケーションとデバイスの互換性を維持するために全力を尽くしています。 ほとんどのアプリ カテゴリ (カーネルに依存しない) では、変更によってアプリの機能への悪影響はなく、既存のアプリは Windows 10 で正しく動作します。

この変更の影響はアプリ固有です。 つまり、OS のバージョンを厳密にチェックするアプリは大きいバージョン番号を取得します。その結果、次の 1 つ以上の状況が発生する場合があります。

• アプリ インストーラーでアプリをインストールできず、アプリを開始できない場合があります。
• アプリが不安定になる可能性またはクラッシュする可能性があります。
• アプリでエラー メッセージが生成されても、アプリは正しく機能し続ける場合があります。

一部のアプリでは、バージョン チェックを実行して、ユーザーに警告を渡します。 ただし、(ドライバーで、または検出を回避するためのカーネル モードで) バージョン チェックに非常に緊密にバインドされているアプリがあります。 このような場合、正しくないバージョンが見つかると、アプリは失敗します。 バージョン チェックではなく、次のいずれかのアプローチをお勧めします。

• アプリが特定の API 機能に依存している場合は、正しい API バージョンをターゲットにしてください。
• APISet または別のパブリック API を使用して変更を検出し、そのバージョンは機能や修正プログラムのプロキシとして使用しないでください。 仕様変更があり、しかも適切なチェックが公開されていない場合、それはバグです。
• アプリがその他の方法 (レジストリ、ファイルのバージョン、オフセット、カーネル モード、ドライバーなどの方法) でバージョン チェックを行わないことを確認します。 アプリでどうしてもバージョンを確認する必要がある場合は、メジャー番号、マイナー番号、およびビルド番号を返す GetVersion API を使用します。
• GetVersion API を使用している場合は、この API の動作が Windows 8.1 以降に変更されていることにご注意ください。

マルウェア対策やファイアウォール アプリなどのアプリを所有している場合は、通常のフィードバックのチャンネルを通じて、または Windows Insider プログラムから対応してください。

文書化されていない API

アプリでは、文書化されていない Windows API を呼び出さないでください。また、特定の Windows ファイルのエクスポートやレジストリ キーに依存しないようにします。 これに従わないと、機能の破損やデータの損失、セキュリティ上の潜在的な問題につながります。 アプリに必要な機能がない場合は、通常のフィードバックのチャンネルを通じて、または Windows Insider プログラムから、フィードバックをお送りください。

ユニバーサル Windows プラットフォーム (UWP) アプリおよび Centennial アプリの開発

すべての Win32 アプリの ISV に、今後はユニバーサル Windows プラットフォーム (UWP) アプリ、中でも特に Centennial アプリを開発することをお勧めします。 従来の Win32 インストーラーを使用するのではなく、これらのアプリ パッケージを開発することには大きな利点があります。 UWP アプリは Microsoft Storeでもサポートされているため、一貫した同じバージョンにユーザーを自動的に更新することが簡単にできるようになりました。これにより、サポートのコストを削減できます。

Win32 アプリの種類が Centennial モデルで動作しない場合は、適切なインストーラーを使用し、これが完全にテストされていることを確認します。 インストーラーは、ユーザーまたはお客様が体験するアプリの最初のエクスペリエンスであるため、適切に動作するようにします。 これが十分に動作しなかったり、すべてのシナリオに対して完全にテストされていなかったりすることがよくあります。 Windows アプリ認定キットを使用すると、ユーザーよりも前に、Win32 アプリのインストールとアンインストールを試し、文書化されていない API を使用していないことを確認できます。また、パフォーマンスに関連した他の基本的なベスト プラクティスの問題がないかも確認できます。

ベスト プラクティス:

• 32 ビットと 64 ビットの両方のバージョンの Windows で動作するインストーラーを使用します。
• 複数のシナリオ (ユーザー レベルまたはコンピューター レベル) で実行するようにインストーラーを設計します。
• 元のパッケージ化のときに Windows 再頒布可能ファイルをすべて維持します。ファイルを再パッケージ化すると、インストーラーが壊れる可能性があります。
• ソフトウェア開発ライフサイクルで見過ごされがちな成果物として、インストーラーの開発時間のスケジュールを設定します。

最適化されたテスト戦略とフライティング

Windows OS のフライティングは、一般ユーザーに最終ビルドがリリースされる前に、Windows Insider ユーザーが利用できる中間ビルドのことです。 中間ビルドのフライティングを行う Insider ユーザーが増えるほど、ビルドの品質や互換性などについてより多くのフィードバックが集まり、最終ビルドの品質向上につながります。 このフライティング プログラムに参加して、OS の反復的なビルドでアプリが期待どおりに動作することを確認します。 フライティング後のビルドの動作、発生した問題などについて、ぜひフィードバックをお寄せください。

アプリがストアに登録されている場合は、ストアを通してアプリのフライティングを行うことができます。つまり、Windows Insider カタログからアプリを選んでインストールできるようになります。 ユーザーにアプリをインストールしてもらい、一般リリースの前にアプリについて予備的なフィードバックを受け取ることができます。 以下のセクションでは、フライティング後の Windows ビルドに対してアプリをテストする手順の概要を示します。

手順 1:Windows Insider に参加してフライティングに参加する

Windows Insider に登録して Windows の将来像を形作るためにご協力ください。皆様からのフィードバックは、プラットフォームの機能向上に役立てられます。 この活発なコミュニティで熱意のある他のユーザーと交流できます。フォーラムに参加して互いにアドバイスし合ったり、Insider 参加者限定イベントの予定を把握したりできます。

Windows 10、Windows 10 Mobile、最新の Windows SDK とエミュレーターのプレビュー ビルドにアクセスできるため、優れたアプリの開発に自由に使用できるあらゆるツールを手にすることができます。また、ユニバーサル Windows プラットフォームと Microsoft Store の新着情報を探すこともできます。

優れたハードウェアを構築する機会でもあります。ハードウェア開発キットのプレビュー ビルドを入手して、Windows 用ユニバーサル ドライバーの開発を始めましょう。 サポートされている IoT 開発ボードで IoT Core Insider Preview を使用して、ユニバーサル Windows プラットフォームで優れた接続ソリューションを構築しましょう。

Windows Insider に登録する前に、参加するユーザーについて次のように想定されていることをご確認ください。

• まだ開発段階のソフトウェアを試したい。
• ソフトウェアとプラットフォームに関するフィードバックを共有したい。
• 一定期間に多数の更新プログラムや UI 設計の大幅な変更があっても問題ない。
• PC に関する確実な知識があり、問題のトラブルシューティング、データのバックアップ、ハード ドライブのフォーマット、ゼロからのオペレーティング システムのインストールに慣れていて、必要な場合は以前のシステムに復元することも問題ない。
• ISO ファイルが何であるかと、その使用方法を理解している。
• 日常的に使用しているコンピューターやデバイスにはインストールしない。

手順 2:シナリオをテストする

フライティングを経たビルドを更新した後、テストの実行とフィードバックの収集を始めるときに参考にできるサンプルのテストケースを以下に示します。 これらのテストのほとんどでは、x86 システムと AMD64 システムの両方に対処するようにします。 クリーン インストールのテスト: クリーン インストールした Windows 10 で、アプリが完全に機能することを確認します。 アプリがこのテストとアップグレード テストに失敗した場合は、問題は基になる OS の変更によるものか、アプリのバグである可能性があります。 調査の結果、前者が原因である場合は、Windows Insider プログラムを使用してフィードバックを送り、解決にご協力ください。

アップグレード テスト: 下位バージョンの Windows (Windows 7 または Windows 8.1) から Windows 10 にアップグレードした後、アプリが動作することを確認します。 アップグレード中にアプリでロールバックが発生することなく、アップグレード後にアプリが予期したとおりに動作する必要があります。これはシームレスなアップグレード エクスペリエンスを実現するために非常に重要です。

再インストール テスト: 下位レベルの OS から Windows 10 に PC をアップグレードした後、アプリを再インストールすることで、アプリの機能を復元できることを確認します。 アプリがアップグレード テストに合格しなかった場合、問題の原因を絞り込むことができないときは、失われた機能を再インストールによって復元することができます。 再インストール テストに合格した場合、アプリが部分的に Windows 10 に移行されていない可能性があります。

OS/デバイスの機能テスト: アプリが OS の特定の機能に依存している場合は、アプリが予期したとおりに動作することを確認します。 一般的なテスト対象範囲は次のとおりです。多くの場合、一般的に使用されているさまざまな PC モデルに対して実行することで、対応を確認します。

• オーディオ
• USB デバイスの機能 (キーボード、マウス、メモリ スティック、外付けハード ディスクなど)
• Bluetooth
• グラフィックス/ディスプレイ (マルチモニター、画面出力、画面の向きなど)
• タッチ スクリーン (向き、スクリーン キーボード、ペン、ジェスチャなど)
• タッチパッド (左/右ボタン、タップ、スクロールなど)
• ペン (シングル/ダブルタップ、プッシュ、長押し、消しゴムなど)
• 印刷/スキャン
• センサー (加速度計、フュージョン センサーなど)
• カメラ

手順 3:ご意見とご感想

フライティング後のビルドに対してアプリが動作するかどうかをお知らせください。 テスト中にアプリで問題が見つかった場合、パートナー ポータルにアクセスできる場合はパートナー ポータルにログを登録してください。または、Microsoft の担当者にお伝えください。 ユーザー向けの高品質なエクスペリエンスを協力して構築するために、情報をお寄せください。

関連トピック

更新プログラムおよびアップグレードに関する Windows 10/11 のサービス オプション