windows 10 導入と waas...

エンタープライズ企業におけるWindows 10 導入と WaaS 適用の要点

Microsoft Enterprise Services Japan

Principal Consultant

Nobuyuki Akama

p.2

Agenda

エンタープライズ企業における Windows 10 導入と WaaS 適用の要点

Windows 10 の導入と WaaS モデルへの対応

Windows 10 導入の目的

WaaS の正しい理解

Windows 10 における OS の更新モデル

Windows 10 導入時の検討の流れ

導入計画の立案と特に検討すべきポイント

Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ系

互換性検証の基本的な考え方

互換性検証の効率化手法

事例：マイクロソフト社内の互換性検証作業の効率化

大企業への WaaS 導入時の注意点

近代的な業務アプリケーション開発を目指すために

Windows 10 導入時に考え方・やり方を変えるべきポイント – インフラ系

IT インフラ管理の見直しの必要性

3 つの重点検討ポイント

Windows OS の変更ログの入手方法

変更ログ情報を提供している主な公式・非公式サイト

Premier 非互換情報提供サービス

まとめ

Windows 10 の導入と WaaS モデルへの対応

p.4

Windows 10 と WaaS

昨今、Windows 10 の導入を検討する大企業が増えてきている

日本の大企業では、端末更改のタイミングに合わせて OS を入れ替えることが多い

Windows 10 は 2015/07/29 にリリースされているが、特にエンタープライズ系企業での導入はまだ十分に進んではいない

大きな背景としては、日本の大企業ではハードウェアの老朽更新に併せて OS 入れ替えを行うことが多いこと、ハードウェアの買い替えサイクルが諸外国より長いことがある

いくつかの要因が重なり、昨今、次期端末の購入・導入計画に併せて Windows 10 の導入計画を進めているお客様が非常に増えている

Windows 10 のリリースから約 1 年間が経過している

昨今のセキュリティ脅威に対する安全性を高めるために OS を最新化したい

多彩な Windows 10 デバイスとモバイルワークスタイルで、社員の生産性を高めたい

p.5

Windows 10 と WaaS

一方で、Windows 10 の導入に際しては、必然的に WaaS （Windows as a

Service）モデルへの適応方法を検討しておく必要がある

従来の「約 3 年に一度の大型アップデート」では時代の要求に追随できない

このため Windows 10 では、新しい機能（機能追加や機能強化）を、いち早く、オンラインでのアップデートとしてこまめに提供していくこととなった

この WaaS に継続的に追随していく仕組みを、社内に作っておく必要がある

① IT のコンシューマ化

• スマートデバイスの急速な普及

• スマートデバイスでは OS

を常に最新化するのが当然

② セキュリティ脅威の進化

• 近年、民間企業を対象にしたサイバー攻撃が激化

• 攻撃手法の進化に追随する最新の対策が必要

③ テクノロジーの進化

• ハードウェア技術とソフトウェア技術がどんどん進化

• 利用者の生産性を高める最新技術が次々と登場

時代背景

WaaS

Windows 10 搭載デバイスに機能追加・強化のアップデートを定期的・継続的に無償で提供

約 3 年に一度

より頻繁に

p.6

Windows 10 と WaaS

本資料では、『継続的に最新化されていく Windows 10 インフラ』を実現するために必要となる考え方やアプローチを解説する

オンラインでの随時更新が基本となり、さらに更新頻度も大きく変わる（数年に 1 度 →

4～8 カ月に 1 度になる）ため、従来の考え方を踏襲できないところがある

このため、以下のようなポイントを理解＆事前検討しておくと、実際の導入作業がスムーズに進められる

【Windows 10 導入時の検討の流れ】

• アプリ対応で考えるべきこと• インフラ対応で考えるべきこと

【アプリ互換性検証の要点】

• アプリ互換性の基本的な考え方• アプリ互換性検証の効率化の手法• 大企業における開発近代化の必要性

【インフラ対応の要点】

• セキュリティ• マスタイメージ管理• FU/SU 配信方式

【変更ログの入手方法】

• 代表的な Web サイト• プレミアサポートサービスによる情報提供

【Windows 10 導入の目的】

• セキュリティ• マルチデバイス活用（UWP）• モバイルワークスタイル

【WaaS の正しい理解】

• IP/CB/CBB/LTSB の使い分け• Win10 バージョン間の移行方針• 混在を前提とするインフラへの移行

代表的な Windows 10 導入の目的

p.8


Windows 10 導入を始めるにあたり、どのようなメリットを得るのかを考えておく

どのような場合であっても、Windows 10 導入により得られるメリットの明確化は必要

Windows 10 導入がまだ決まっていない場合（予算化されていない場合）

ハードウェアサポート切れなどの消極的な理由で Windows 10 を導入する場合、etc…

お客様（エンドユーザ）目線では、以下の 3 点がメリットになりやすい

管理者目線も重要だが、まずはユーザ目線での訴求ポイントを整理するとよい

1. セキュリティ強化

2. モバイルワークスタイル

3. 多彩なデバイス活用

• 最新・最高レベルのセキュリティを持つ OS の活用• 単一のプラットフォーム利用により、運用環境の合理化とコスト削減

を同時に実現

• ホワイトカラー（知的労働者）の生産性を改善• マイクロソフトのクラウドサービス（Office 365, Azure）と、Windows

10 の多彩なデバイスにより、かなりの部分の実現が可能

• PC、8 インチタブレット、スマホなど、多彩なフォームファクターをシングル OS・シングルユーザエクスペリエンスで実現可能

• UWP により、デバイスごとのアプリ重複開発の回避が可能

p.9


1. セキュリティ強化

サイバー攻撃は直近 10 年で大きく変化、いたずらではなく利益やテロが目的に

サイバー攻撃による現在の ROI は 1425% とも言われている

ゼロデイ脆弱性を売買する企業、さらにマルウェア開発のためのツールキットも存在

企業の約 9 割は未知の脅威が侵入済みであると言われているほど

Windows 10 を導入・活用することで、セキュリティ強化と対策コスト低減を狙う

最新・最高レベルのセキュリティを持つ OS の活用

単一のプラットフォーム利用により、運用環境の合理化とコスト削減を同時に実現

ターゲットの規模

複雑度

2003 年～ 2004 年 2005 年～現在 2012 年以降

/ 国民国家、活動家、テロ集団動機: 知的財産の盗難、損害、混乱

組織的な犯罪動機: 利益の獲得

スクリプトキディ動機: いたずら

（参考 URL） https://blogs.windows.com/japan/2016/02/19/us-department-

of-defense-commits-to-upgrade-4-million-seats-to-windows-10/

p.10


2. モバイルワークスタイルの実現

日本の労働人口の生産性は、先進諸国の中では群を抜いて低い

今後の日本は少子高齢化により、社会保障費の増大・貯蓄率低下・投資率低下などが進み、労働集約型産業は成立しなくなる

しかし、日本は特にホワイトカラー（知的労働者）の生産性が依然として低い

老若男女が共に働き、高い生産性で短時間で稼ぎ、多様な働き方を認めることが必要

モバイルワークスタイルは、ユビキタスコンピューティングとの両輪で実現される

マイクロソフトのクラウドサービス（Office 365 や Azure）と、Windows 10 の多彩なデバイス（後述）により、かなりの部分を実現できる

移動店舗などのユビキタスサービスへのニー

ズ

BCP （事業継続）への

ニーズ

育児や介護など在宅勤務へのニー

ズ

ビジネスニーズ

モバイルワークスタイルいつでも・どこでも効率的な仕事ができる

1 日 24 時間を柔軟かつ効率的に活用できる

ユビキタスコンピューティングいつでも・どこでもクラウド接続したデバイスで

高付加価値サービスを享受できる

テクノロジトレンド

豊富なスマート

デバイスの登場

クラウド及び SaaS

サービスの拡充

3G/4G などの高速モバイル回線の

普及

ユビキタスアプリケーション

へのニーズ

いつでも・どこでも使えるアプリ

p.11



Windows 10 であれば、多彩なデバイス活用をシングル OS により実現できる

実際のモバイルワークスタイルを考えると、単一のデバイス利用だけでは完結しにくい

多彩なデバイスを、状況に併せて使い分け＆併用するのが現実的

しかも、Windows であれば各種の既存資産（ドキュメント・アプリ）を再利用しやすい

UWP（Universal Windows Platform）を使えば、複数の Windows 10 デバイスに対して一つのバイナリで対応するアプリケーションの開発ができる

Windows Mobile, Windows タブレット両方で動作するアプリの開発が可能

マルチデバイスに対する重複開発の問題を最小限に抑え込むことができる

ウェアラブルスマートデバイスデスクトップ大型デバイス

Microsoft Band

HoloLens

Windows

Mobile

(Lumia)

Surface Pro

Surface Book Windows PC Surface Hub

可搬性高低

閲覧性・操作性低高

p.12



デバイスの具体的な活用方法の例

社員の生産性の改善オペレーションコストの低減お客様サービスの改善

• お客様折衝でのタブレット活用• 電子カタログや電子サイン• ビジュアルシミュレーション• デジタル教科書や VOD

• デジタルホワイトボード

• 「その場での」データ入力• POS レジ、キオスク端末• セルフオーダー端末• 日報入力、レポート入力• 倉庫・在庫管理

• リモートワーク・モバイルワーク• デジタルダッシュボード• オンライン会議、ストリーミング、

電話統合・電話録音、IM

• 端末間でのファイル同期• 社外でのメール・予定表の確認• Continuum の利用

p.13


（参考・注意） UWP 以外の開発技術について

汎用開発技術としてむやみに HTML5 を利用するのは不適切であることに注意する

Web 系開発技術（HTML5）であれば、Windows 10 以外のプラットフォームもカバーできるが、半面、開発生産性やユーザビリティに難がある

このため、どこまでのユーザーやデバイスをカバーするのかを考えて、最適なテクノロジを選択することが必要

【HTML5】マルチブラウザでのマルチデバイス対応

【UWP】Windows 系 OS でのマルチデバイス対応

【Xamarin】マルチ OS でのマルチデバイス対応

開発言語

サポートデバイス

C# （高水準言語） C# （高水準言語）HTML/JavaScript/CSS

（低水準言語）

Windows PC, タブレット,

Windows Mobile などiPad/iPhone,. Android,

Windows タブレットほぼ全デバイスEdge, Chrome, FireFox

リーチ性

開発生産性

低高

高低

ユーザビリティ（表現力や操作性）

高低

社員のみ

協力会社・代理店までカバー

コンシューマ（エンドユーザー）までカバー

カバーする範囲（例）

WaaS の正しい理解 – Windows 10 における OS 更新モデル

p.15

WaaS の正しい理解 – Windows 10 における OS 更新モデル

Windows 10 の導入に際しては、『導入後にどのようになるのか？』を理解・検討しておくことが極めて重要

Windows 7/8/8.1 → 10 への移行そのものは、従来と同じように考えればよいが…

Windows 10 の導入＝継続的にアップグレードされ続ける環境への移行でもある

このため、WaaS での継続的な機能アップグレードの仕組みを理解しておくことが重要

ここでは、Windows 10 移行後の、WaaS による継続的更新（機能追加）の仕組みについて解説する

OS としての機能

機能追加・変更







修正（バグ・脆弱性・安定性など）

Windows 8 Windows 10

TH1 (1507) TH2 (1511) RS1(1607)

Windows 7

8.0 8.1SP0 SP1 RS2(???)

① Windows 10 への移行（従来と同様な OS アップグレードとして考えればよい）

② WaaS による継続的更新

（機能アップグレード）

November

Update

Anniversary

Update

（最初のリリース）

重要！

p.16

4 つの OS 更新モデル（IP, CB, CBB, LTSB）

WaaS では、機能追加の「受け取り方」に関して、以下の 4 つの選択肢がある

CB : コンシューマユーザには、約 4～8 ヵ月の間隔で、OS の機能追加が行われる

IP, CBB : 機能追加の受け取り時期を、ある程度、早める or 遅らせることができる

LTSB : 特定用途の端末向けに、機能追加を一切受け取らない方式も提供される

企業内では、用途に応じて、この 4 つの選択肢を使い分ける必要がある

ビジネスユーザは CBB を利用することで、コンシューマ市場で「4 ヶ月間揉まれて安定性を高めた」 Windows OS を利用することができる

用途と必要性に応じて、IP, CB, LTSB を組み合わせて利用する

大多数の従業員（新しい機能やサービスを積極的に

使って生産性を改善していく一般的な社員向け）

特定用途の固定端末（長期に渡って、特定の

ことしか実施しない端末）

一部の従業員（各部署の中の先行ユーザ）

一部の従業員（コンシューマ向けサービスを提供している部門）

LTSBLong-term servicing Branch

CBBCurrent Branch for Business

IPInsider Preview

CBCurrent Branch

ずっとレガシー

コンシューマユーザ

ビジネスユーザ

パワーユーザ

特定用途の端末

約 4 カ月遅れで更新を受け取る

早くに受け取る

p.17


現在に至るまでの Windows 10 の機能アップグレードのリリースは以下の通り

まずは CB のリリースの流れに着目すると理解しやすい

従来のサービスパックに相当する「機能アップグレード」が 4～8 ヶ月おきに登場

当初想定では 4 ヶ月おきだったが、実際には約半年に 1 回程度のペース

この「機能アップグレード」により、機能の追加・改善が行われる（例：Cortana など）

これに対して、IP を利用すると、開発中の β 版を先行して利用できる

逆に CBB を利用すると、 4 ヶ月間コンシューマ市場で揉まれた後の、より安定化したOS を利用することができる

CBB = CB + 4 ヶ月分の累積パッチ、と考えればよい（CB/CBB の機能的差異はない）

※ LTSB に関しては特殊なため、別途後述する

機能アップグレード無印（初回リリース版） November Update Anniversary Update （名称未定）

コード名 TH1 （Threshold 1） TH2 （Threshold 2） RS1 （Redstone 1） RS2 （Redstone 2）

バージョン番号 1507 1511 1607 （未定）

ビルド番号 10240 10586 14393 （未定）

IP リリース 2014/10/01～2015/07/15 2015/08/18～2015/10/29 2015/12/16～2016/07/15 2016/08/11～（未定）

CB リリース 2015/07/29 2015/11/12 2016/08/02 （未定）

CBB リリース 2015/07/29 2016/04/08 2016/12 頃（未定）

LTSB リリース 2015/08/01 なし（未定）（未定）

約 4 ヶ月後約 8 ヶ月後

約 4 ヶ月後約 4 ヶ月後

約 ?? ヶ月後

p.18


IP/CB/CBB の切り替え方法について

IP, CB, CBB は、Windows 10 の設定画面の変更で切り替えることが可能

LTSB は特殊なエディションのため、異なるインストールメディアの利用が必要（後述）

IP CB CBB LTSB

Home ○ ○ × ×

Enterprise, Pro ○ ○ ○ ×

Enterprise-LTSB × × × ○

【CB から CBB に変更】

【CB から IP に変更】

※グループポリシーでの設定配布も可能

【Windows 10 エディションと利用可能な IP/CB/CBB/LTSB の対応関係】

RS1 以降では、受け取り速度を選ぶことが可能

カナリア

Insider Fast

Microsoft Insider Slow CB CBB

Insider Preview

p.19

企業内における機能アップグレードのタイミングの考え方

IP/CB/CBB の提供サイクルと、そのサポート期間は下図の通り

最新バージョンへの逐次アップグレードを推奨しているが、企業内ではそうもいかない

このため、各バージョンは n+2 の CBB リリースの 60 日後までパッチが提供される

~4 months 12 months

~8 months ~4 months ~16 months

July Nov Feb July Nov Feb July

4 months ~4 months ~ 20 months

Nov

Evaluate Pilot Deploy / Use


Grace

Grace


~8 months ~4 months

Evaluate

2016 2017

Pilot Deploy / Use

60 days

60 days

~6 months ~4 months

Evaluate Pilot

Grace

Feb

2018

60 days

July

CB リリース

CBB リリース

※ この CBB だけ例外的に早期リリース

この期間がパッチ提供期間＝サポート期間MS による新機能開発と Insider

Program による F/B 受付期間

このタイミングでOS 機能を確定

この 4 ヶ月間、コンシューマでの利用を元にさらに信頼性を高める

ビジネスユーザ向けの CBB の扱いとなる

推奨アップグレードパス

1507 (TH1)

1511 (TH2)

November Update

1607 (RS1)

Anniversary Update

H1 2017 (RS2)

(Subject to change)

H2 2017 (???)

(Subject to change)

p.20


（重要）企業内におけるバージョン間の乗り換えの流れについて

前掲の図を見ると 1 バージョンスキップが可能なように見えるが、これは推奨されない

具体例） TH1 から（TH2 をスキップして）RS1 に乗り換えることは非現実的

理由： CBB リリース後、60 日間で完全にアップグレードしなければならないが、業務アプリや ISV アプリの対応が 60 日間では間に合わないリスクがある

~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


1607 (RS1)

Anniversary Update



H1 2017 (RS2)

(Subject to change)

Nov



Grace

Grace


~8 months ~4 months

Evaluate

2016 2017

Pilot Deploy / Use

60 days

60 days

H2 2017 (???)

(Subject to change) ~6 months ~4 months

Evaluate Pilot

Grace

Feb

2018

60 days

July

CB リリース

CBB リリース


非現実的

p.21


（重要）企業内におけるバージョン間の乗り換えの流れについて

このため、先の図は次のように捉える必要がある

TH2 CBB リリース後、なるべく早期に TH1 → TH2 に乗り換えるべき

しかし、業務アプリや ISV アプリの非互換問題で、すぐに乗り換えできない場合もある

この場合でも、RS1 CBB リリース + 60 日後までは移行猶予期間がある

~4 months 12 months




Nov



Grace

Grace


~8 months ~4 months

Evaluate

2016 2017

Pilot Deploy / Use

60 days

60 days

~6 months ~4 months

Evaluate Pilot

Grace

Feb

2018

60 days

July

CB リリース

CBB リリース


TH1 → TH2 への移行猶予期間

TH2 → RS1 への移行猶予期間

1507 (TH1)

1511 (TH2)

November Update

1607 (RS1)

Anniversary Update

H1 2017 (RS2)

(Subject to change)

H2 2017 (???)

(Subject to change)

p.22

Windows 10 に対する「更新」の分類について

Windows 10 では、3 種類の「更新」が行われており、それぞれ名称が異なる

① 機能アップグレード（Feature Upgrades）

従来のサービスパックに相当するもの

スタートメニューや設定画面、Cortana、Edge ブラウザなどの機能追加・変更が含まれる

➁ サービス更新プログラム（Servicing Updates）

従来の更新プログラムに相当するもの

脆弱性修正（セキュリティパッチ）が中心で、信頼性やバグに関する修正も含まれる

OS や Edge ブラウザに対する機能追加・変更は含まれない

従来と異なり、必ず累積パッチとして提供される（個別の適用はできない）

配布前に先行検証したい場合には、SUVP（Security Update Validation Program）への参加が必要

※ RS1 以降は品質更新プログラム（Quality Updates, QU）の名称に変更予定

③ ストアアプリの更新の配信

メールやカレンダアプリの更新は、①➁とは別に、Windows ストア経由で配布される

配信内容英語表記簡単に言うと... 備考

① 機能アップグレード Feature Upgrades サービスパック OS や Edge ブラウザの更新

② サービス更新プログラム Servicing Updates 累積セキュリティパッチ通常、毎月第 2 火曜日に配信

③ ストアアプリの更新の配信－メールやカレンダーアプリの自動更新 ①➁とは無関係に配信

簡単に言えば、FU の受け取りタイミングを調整するのが IP/CB/CBB の設定

簡単に言えば、SU の提供期間＝当該 OS バージョンのサポート期間

p.23

LTSB （Long Term Servicing Branch）について

（重要） LTSB は、一般な OA 端末では使うべきではない特殊なエディション

LTSB は、10 年間にわたりパッチのみが提供され続ける、非常に特殊なエディション

その間、機能追加・変更は行われない（＝10 年後には超レガシー端末になる）

インストールメディアも、IP/CB/CBB 用とは別の媒体（Ent-LTSB）を使う必要がある

一般的な従業員の OA 端末で利用すべきものではない

製造ラインの据え付け端末、組み込み端末などに利用すべきもの

ストアなし

Edge

ブラウザなし

LTSB

Windows 10 Enterprise

2015 LTSB

CBB

IP

CB

Windows 10 Enterprise

IP/CB/CBB LTSB

主な利用目的一般的なユーザーや従業員の端末特殊なデバイス

Windows の機能すべて Cortana, ストアなどは利用不可

ブラウザ Edge, IE11 を搭載 IE11 のみ搭載

リリース頻度 4～8 ヶ月おきに Feature Upgrade を提供数年に 1 回程度、新しいメディアを提供※ RS1 以降での提供予定は、現時点では未定

アプリすべてのアプリシステムアプリのみ

p.24

バージョンの混在を前提とするインフラへの移行

（重要）今後の IT インフラは、複数の OS バージョンが混在することになる

従来は、すべての社員が完全に同一の OS を利用することを前提としていたが…

Windows 10 WaaS 時代では、複数の更新モデルを使い分けるとともに、複数の機能バージョンが混在する IT インフラを運用していく必要がある

大多数の従業員（新しい機能やサービスを積極的に

使って生産性を改善していく一般的な社員向け）

特定用途の固定端末（長期に渡って、特定の

ことしか実施しない端末）

一部の従業員（各部署の中の先行ユーザ）

一部の従業員（コンシューマ向けサービスを提供している部門）

先行検証

先行検証

LTSBLong-term servicing Branch

CBBCurrent Branch for Business

IPInsider Preview

CBCurrent Branch

ずっとレガシー

アーリーアダプタ

ビジネスユーザ

パワーユーザ

特定用途の端末


従来の IT インフラ

Win10 時代の IT インフラ


これからは…

すべての社員が完全に統一された

ハードウェアと特定のバージョンの

OS を利用する

Windows 10 導入時の検討の流れ

p.26

Windows 10 導入時の検討の流れ – 導入計画の立案

Windows 10 導入では、アプリ／インフラ両側面からの対応検討が必要になる

特に大企業では、WaaS における頻繁なアプリ互換性検証が課題になりやすい

一方で、インフラ面では、保守性の向上（保守コストの削減）や、ネットワーク経由での継続的な FU/SU 配信が課題になる

実際の導入時は、全体計画の立案後、やるべきことを「インフラ／アプリ」「短期／中長期」に分けて整理し、順次対応を進めていくとよい

本資料では、インフラ／アプリそれぞれでの対応の考え方を解説する

Window 10 導入検討 Windows 10 導入準備Windows 10

展開Windows 10 WaaS

Windows 10

展開開始

継続的な機能アップグレードと品質アップデートの配信

• Windows 10 WaaS の正しい理解• Windows 10 導入目的の明確化• 移行障壁の洗い出し• インフラ / アプリへの課題切り分け• 短期 / 中長期対策への切り分け

全体計画の立案

• Windows 10 クライアント設計• ハードウェア選定と展開計画策定• イメージ作成方式の見直し• FU / SU 配信インフラの整備

インフラ短期対応

• アプリポートフォリオの整備

• 非互換情報の入手方法・効率化の検討

• アプリ非互換検証の実施

アプリ短期対応

• 継続的な FU / SU の配信• Windows 10 新機能の継続的な取り込み

• 全社最適化の推進（共用テストインフラ・集約テストチームの運営など）

インフラ中長期対応

• 非互換情報を元にした継続的な非互換検証の実施• アプリケーション開発の近代化• 既存システムの技術的負債の解消

アプリ中長期対応

p.27

Windows 10 導入時の検討の流れ – 検討すべきポイント

Windows 10 では、従来からの考え方を大きく変えるべき点がいくつかある

「OS アップグレード」という観点では、従来の XP → 7 などと似ている点が多いが…

旧態依然としたやり方を続けていると、今後の WaaS （継続的な機能アップグレード）に耐えられなくなる

以下のようなポイントについては、Windows 10 導入に併せて、従来のやり方を見直すことが望ましい

以降では、これらについて解説する

② システム開発の近代化

① アプリ互換性検証

② 端末管理とイメージ作成

③ FU/SU リング配信インフラ

① セキュリティインフラ系

アプリ系

従来と大きく考え方が変わる点

重要

重要

• 様々なセキュリティ機能をどのように捉え、どれを使えばよいか？

• パラメータシートやマスタイメージ管理をどのように効率化するか？

• FU/SU のリング配信をどのように実施すればよいか？

• FU/SU に対する頻繁なアプリ互換性検証をどのように行えばよいか？

• Windows 10 時代の近代的なシステム開発はどのように実施すべきか？

Windows 10 導入時に考え方・やり方を変えるべきポイント – アプリ系

p.29

大企業におけるレガシー業務アプリ資産

Windows 10 への移行における大きな障壁のひとつに、アプリ互換性検証の問題がある

大企業では、多数のレガシー業務アプリ資産を抱えていることが多い

従来は OS アップグレードやサービスパック適用時に大規模な再テストを手作業で実施していることが多かったが、頻度が高まると、同じやり方が通用しなくなる

以降では、主にエンタープライズ企業における、既存業務アプリケーションの互換性検証について解説する

モダンアプリ（エッジブラウザ向け Web アプリや UWP など）については解説しない

これらは、ランタイムの頻繁な更新を念頭において作られていると考えられるため

主に、VB6, .NET（CLR 2, 4）, IE11 などを用いて作られた、『作りっぱなし』になっている、社内向けの既存レガシー業務アプリを念頭に置いて解説する

XP Vista 7 8/8.1 10(TH1) 10(TH2)98 10(RS1)

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017

p.30

既存レガシーアプリに対する互換性検証の基本的な考え方

基本的なポイントとして、OS バージョン間の互換性は昔に比べて高まっている

特に 7 以降では、製品開発チームでの互換性に対するアプローチが大きく変わっており、OS バージョン間の互換性はそれ以前の Windows に比べて遥かに高くなっている

原理的に非互換問題がゼロになることはないが、必要以上に恐れすぎる必要もない

例えばカーネル依存性のないデスクトップアプリケーションの場合、Windows 7

以降では高い互換性が実現されている

クラッシュしたり全く動かなかったりインストールできないアプリなども確かにあるが...

典型例） 16 ビットアプリ、OS バージョン番号に基づいて制御をかけているアプリ（特にインストーラ）、デバイスドライバに依存するアプリなど

カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ない

以降では、既存レガシーアプリに対する互換性検証の考え方を整理する

IE11 ベースのブラウザアプリ

Win32 ベースのデスクトップアプリ（VB6 や .NET アプリ） ※ カーネル依存のないもの

変更小

XP Vista 7 8/8.1 10(TH1) 10(TH2)

変更大

98

変更小

10(RS1)

p.31

OS としての機能








修正（バグ・脆弱性・安定性など）

既存レガシーアプリに対する互換性検証の基本的な考え方

高い互換性は、既存ランタイムへの変更を最低限にすることで実現されている

ブラウザアプリについては、IE11 を継続的にサポート

デスクトップアプリについては、各種ランタイム・フレームワークへの変更を最小限に留めることで、互換性を最大限確保

レガシーランタイム開発基盤

モダンランタイム開発基盤

ブラウザ

ネイティブ

ブラウザ

ネイティブ

IE8

IE9

IE10

IE11

VB6

CLR2.0 （.NET 2.0, 3.0, 3.5）（WinForms, WPF）

WinRT

Edge

UWP

サポート切れ

新機能・機能強化

サポート切れ


新機能・機能強化新機能・

機能強化


バグ・脆弱性修正などの最低限の修正



CLR4.0 （.NET 4.0, 4.5, 4.6）（WinForms, WPF）


TH1 (1507) TH2 (1511) RS1(1607)

Windows 7

8.0 8.1SP0 SP1 RS2(?)

p.32


その一方で、特にミッションクリティカルな業務システムの場合には、「アプリが起動すればよい」というものでもない

具体例） .NET で開発されたデスクトップアプリの場合

「だいたい動作は同じ」だが...

ウィンドウ枠のデザインの違い、UI 部品の見た目の違い、ドット単位の微妙な描画の違い、連動する標準ブラウザなどの細かい違いが出てくる

これらは、ミッションクリティカルアプリでは、時として業務継続を妨げる問題となりうる

Windows 7 上での動作 Windows 10 上での動作

ウィンドウ枠のデザインの違い

UI 部品の描画の違い

起動する標準ブラウザの違い

ドット単位の微妙な描画の違い

p.33


OS バージョンの違いで既存レガシーアプリの挙動が変化するのは、アプリケーションランタイムが OS の機能を利用しているため

例） .NET アプリの場合

計算処理などはアプリランタイム内で行われるため、互換性リスクはほとんどないが...

UI 描画などは OS の API （Win32API など）を呼び出すため、挙動が変わることもある

この非互換リスクの発生は、大きく 2 つのレベルに分けて捉えることができる

機能追加・変更による非互換リスク：例） Win32 UI 部品の描画の変更

修正パッチによる非互換リスク：例）ブルースクリーン発生に対するパッチ修正

OS （Windows 7）

.NET ランタイム

ユーザアプリ

OS （Windows 10）


ユーザアプリ


不変

概ね動作はするが、見た目や挙動は一部変わる

計算処理などは .NET の中のみで行われるため互換性リスクは（ほぼ）ない

修正パッチ（バグ、脆弱性、安定性など）

機能追加・変更は（ほぼ）なし

修正パッチ（バグ、脆弱性、安定性など）

非互換リスク大

非互換問題は出にくい

Windows 7 上での動作 Windows 10 上での動作

一般にこちらが

問題

p.34


まず、現在、既存アプリでどの程度の互換性検証を実施しているのかを確認してみるとよい

理屈上は「あらゆる修正に対して互換性を検証する」のが正しいが、実際の現場で行われている互換性検証は、以下の①または②であることが多い

① 事前の互換性検証をしていない

② サービスパックのような機能追加・変更がある場合のみ、互換性検証をする

③ パッチを含め、あらゆる修正に対して互換性検証を行う

理由： ③の互換性検証を行うには、実質的にテストの自動化が必要であるため

手作業で行うことが可能なのは、現実的には②のレベルまで

Win10 への移行時に、現在の実施レベルをむやみに高める必要はない

現在の実施レベルが②であるのなら、Win10 への移行後も、②のレベルに留めるべき

理由： OS バージョン間の互換性レベルは、以前に比べて向上しているため

ミッションクリティカル度 ① 低 ② 中 ③ 高

事前の互換性検証しないするする

事前の互換性検証範囲－機能追加・変更のみ修正パッチレベルまで

互換性検証の頻度－ • 低（半年に一度程度）• 機能アップデートごと

（サービスパックごと）

• 高（月に一度程度）• サービスアップデートご

と（累積パッチごと）

互換性検証の実施方法－手作業でもある程度可能自動化が必須

リスクヘッジ施策段階的OS展開を行い、非互換発生時は速やかにコード修正・リリースを実施

重要！

p.35


Windows 10 の機能アップグレードには、以下のような全体傾向がある

Windows 8.1 → Windows 10 TH1

UI まわりが大きく変更されており、.NET や VB6 アプリもその影響を受ける

その他、OS 全体に比較的大きな機能追加・変更が加えられている

Windows 10 TH1 → TH2 および TH2 → RS1

TH1 → TH2 : Edge ブラウザの強化がメイン

TH2 → RS1 : Edge ブラウザに加え、スタートメニューや設定画面、IME などの強化が中心であり、既存レガシーアプリには影響が出にくい変更内容がほとんど

Windows 8.1Windows 10

TH1

Windows 10

TH2

Windows 10

RS1

UI デザインの変更スタートメニュー・デスクトップの変更

Edge ブラウザの追加設定画面の変更

Edge ブラウザの強化

スタートメニューの強化Cortana・検索の強化Edge ブラウザの強化

設定画面の強化

レガシーアプリとは無関係な場所を中心に機能強化

変更大変更小変更小

p.36


（参考）主な機能追加・変更箇所の傾向について

changewindows.org （非公式サイト）の情報を元に分析・整理

以下の URL の情報を元に作成

8.1 → TH1 : http://changewindows.org/build/10240/desktop

TH1 → TH2 : http://changewindows.org/build/10586/desktop

TH2 → RS1 : 中間ビルド 14361 までの変更内容を累積して確認

分類 8.1→TH1 TH1→TH2 TH2→RS1 (14361)

スタートメニュー 42 9 36

Cortana・検索 15 6 28

デスクトップ 25 2 10

ファイルエクスプローラ 8 1

ユーザインタフェース 24 11 16

Edge ブラウザ 89 27 85

IE 2

設定 25 19 76

システム 12 10

UWP アプリ - 7 24

その他 18 16 22

合計 260 97 308

情報ソース : changewindows.org

p.37


このため、実際の Windows 10 への移行に関しては、7/8/8.1 → 10 の移行と、10 → 10 の移行とを分けて考えた方がよい

① 7/8/8.1 → 10 : 比較的きっちりと検証作業を行う

日本の業務アプリケーションの多くは UI が非常に複雑、かつ若干の変更であってもエンドユーザからのクレームに繋がり兼ねないため

ただし、以降の 10 → 10 の互換性検証を見据えながら作業を進めるのがポイント

② 10 → 10 : 極力、効率化・省力化を行う

既存のレガシーアプリに対して影響を及ぼしうる OS への機能追加・変更はごくわずか

このため、この互換性検証は、実施するとしても極力、効率的に実施する必要がある

Windows 7

Windows 8

Windows 8.1


【アーキテクチャ情報】【テストケース】

Win7 → Win10 移行

【10→10 互換性検証を見据えた作業の実施】

Win10 → Win10 移行

【テストケース】【非互換情報】

【最小範囲に絞った互換性検証】

①②

p.38

互換性検証の効率化手法

実際に互換性検証を行う際の効率化手法としては、右図のようなものがある

① テストケースの絞り込み

実施する非互換検証の物理的な実施量を減らす

② 見逃しリスクへの対応

テストケースを減らしたことによる見逃しリスクを緩和するための施策を打つ

③ 更なる実施効率化

①②を行った上で、さらに効率化を進めたい場合に追加の施策を打つ

これらについて、具体的なテクニックを解説する

大方針主な具体的施策


③ テストの更なる実施効率化

アーキテクチャ情報と非互換情報を元にした絞り込み

業務的重要度を元にした絞り込み

OS 更新の段階的配布

素早いコード修正とアプリ再配布


仮想環境の活用

非有識者による再テストの実施

UI テストの自動化

全社的視点での互換性検証の最適化

探索的テストや過去の実施結果を元にした絞り込み

重要！

重要！

p.39

主に 3 通りの考え方があり、これらを組み合わせてテストケースを絞り込む

A. アーキテクチャ情報を元に絞り込む（処理の類似性や技術要素などから絞る）

B. 業務的観点から絞り込む（重要度の高い業務に絞る）

C. 実践的な知見から絞り込む（過去の互換性検証の結果や探索的テストから絞る）

この中で特に重要なのは A. のポイント

実際の非互換問題は、下記の図の『技術的接点』で発生しやすい

こうしたパスを少なくとも 1 度通るようなテストケースを設計するとよい

ネッ

トワ

ーク

アク

セス

デバイスドライバ

互換性検証の効率化手法 - ① テストケースの絞り込み

Windows 10 PC

ユーザーアプリ（デスクトップアプリ）

アプリケーションコード

【アプリケーションランタイム】• VB6, CLR, MFC, etc...

【ミドルウェア・部品群】• ADO, OLE DB, ODBC

• SPREAD, InputMan,

OCX, etc...

インストーラ

【OS 機能】• ファイルシステム、レジストリ• WOW64

• セキュリティ（証明書、暗号化API、ログイン認証）

【外部プロセスアプリ】• Excel

• 帳票ソフト• etc...

UI 画面

入力デバイス

• ウィンドウやダイアログ、UI 部品の見た目の変化

• フォント・レイアウト崩れ• 文字化け

• キーボード、マウス操作• IME 制御• 各種センサー類（マイク、

カメラなど）

外部周辺機器

プリンタスキャナUSB

リーダ制御装置やセンサー

外部サーバ

DB サーバ

各種サーバ• Web API

• J2EE サーバ• ホスト• etc...

• 初回セットアップ• 差分パッチ適用

デスクトップアプリの非互換検証ポイント

アプリ配信サーバ

• オンライン配布• オンラインアップデート

p.40

各種プラグイン・拡張ランタイム


Web アプリケーションの非互換検証（リグレッションテスト）に関して

業務 Web アプリでは、内部で様々なプラグインを利用していることが多く、これらはデスクトップアプリと同様の非互換検証が必要になる

IE11 は基本的に機能変更が入らないが、セキュリティ強化に伴う仕様変更は今後も入る可能性があるため、注意して検証することが必要

ネッ

トワ

ーク

アク

セス

デバイスドライバWindows 10 PC

ユーザーアプリ（ブラウザアプリ）

HTML, CSS, JavaScript

（Pure HTML）

Active X コントロール

インストーラ

【OS 機能】• ファイルシステム、レジストリ• WOW64

• セキュリティ（証明書、暗号化API、ログイン認証）

【外部プロセスアプリ】• Excel

• 帳票ソフト• etc...

UI 画面

入力デバイス

• ウィンドウやダイアログ、UI 部品の見た目の変化

• フォント・レイアウト崩れ• 文字化け

• キーボード、マウス操作• IME 制御• 各種センサー類（マイク、

カメラなど）

外部周辺機器

プリンタスキャナUSB

リーダ制御装置やセンサー

外部サーバ

DB サーバ

各種サーバ• Web API

• J2EE サーバ• ホスト• etc...

• 初回セットアップ• 差分パッチ適用

Web アプリの非互換検証ポイント

IE11 実行エンジン

Silverlight

Java Applet Flash

Web サーバ非互換リスク低

非互換リスク高

• オンライン配布

p.41


（参考）特に検証すべきポイントについて

技術要素に分解して考えた場合、場所ごとに非互換リスクの度合いが随分違う

このことを意識して、テストケース設計時に濃淡をつけると費用対効果が高くなる

主な非互換検証箇所検証ポイント備考 7/8/8.1→10 10→10

インストーラインストール可否インストーラが OS 依存している場合が多い

特に注意比較的安全

デバイスドライバプリンタやスキャナなどの周辺デバイス

古いデバイスドライバは動作しない場合が多い

特に注意注意

UI 画面見た目の変更デザイン変更が定期的に行われる場合が多い


入力デバイス IME 動作、各種センサーの動作

継続的に改善が加わる箇所であるため（IME 制御などは特に要注意）

特に注意特に注意

外部プロセスアプリ特に古いアプリの互換性古いアプリはサポート切れなどのリスクがある

特に注意注意

ミドルウェア・部品群特に古いミドルウェアの互換性古いミドルウェアはサポート切れなどのリスクがある

特に注意注意

外部サーバ外部サーバとの接続可否ネットワークセキュリティ強化の影響を受けやすい


OS 機能上記に含まれない OS 機能の利用

カーネルに近い機能を使っているものやセキュリティ関連の強化・変更は特に影響を受けやすい

特に注意特に注意

アプリケーションランタイムアプリケーションランタイム機能の利用

レガシーランタイムは基本的に修正なし

比較的安全比較的安全

p.42


（重要）非互換情報との突合せ確認について

特に 10 → 10 での互換性検証では、非互換情報との突合せが重要になるが...

どのレベルで非互換情報を確認するのかを意識することが非常に大切

ミッションクリティカル度が高い場合

機能追加・変更だけでなく、修正パッチ情報についても確認が必要だが...

この場合、パッチリリースごとの確認が必要 → 自動化されたテストの繰り返しが必要

ミッションクリティカル度が中程度の場合

この場合、機能追加・変更を中心に確認することになる


修正パッチ

機能追加・変更（ほぼなし）

修正パッチ

OS （Windows 7）


ユーザアプリ

Windows 7

OS （Windows 10）


ユーザアプリ

Windows 10


修正パッチ


修正パッチ

OS （Windows 10）


ユーザアプリ

Windows 10

要確認要確認

p.43


（重要）非互換情報との突合せ確認について

非互換情報は、公式／非公式さまざまなサイトから提供されているが、前述のテストケース絞り込みの目的で役立つものは比較的少ない

changewindows.org の情報が最も使い勝手がよいが、非公式・英語という難点あり

この問題を解決するため、日本独自で WaaS 非互換情報提供サービス（有償）を実施

変更情報の入手場所

スコープ提供頻度情報粒度公式／非公式

有償／無償 URL 備考

Insider Preview ごと

機能アップグレードごと

サービス更新（累積パッチ）ごと


修正（脆弱性・バグなど）

Windows Insider blog Windows OS 全体

〇 × × 〇 △ 公式無償リンク情報がやや細かいため、整理が必要

Microsoft Edge Changelog

Edge ブラウザ

〇〇 × 〇 △ 公式無償リンク

ChangeWindows.org Windows OS 全体

〇〇 × 〇 × 非公式無償（寄付）リンク非公式だが、最も使い勝手はよい

ASKVG Windows OS 全体

〇〇 × 〇 × 非公式無償リンク

Windows 10 release information

Windows OS 全体

× × 〇 × △ 公式無償リンク日本語情報あり

WaaS 非互換情報提供サービス

Windows OS 全体

× 〇 × 〇 × 公式有償 - 有償だが、日本語での使い勝手のよい情報提供が可能

〇 : 含まれている△ : 含まれているが完全ではない（代表的なものに限られる）× : 含まれていない

〇 : この頻度で情報公開

※パッケージ製品の OS 対応状況については各ベンダーにお問い合わせください

https://blogs.windows.com/windowsexperience/tag/windows-10-insider-preview/

https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/

http://changewindows.org/

http://www.askvg.com/

https://technet.microsoft.com/en-us/windows/release-info.aspx

p.44


WaaS 非互換情報提供サービスでは、以下を機能アップグレードごとにご提供

① 主要な追加機能や変更点について解説する ppt 資料

新製品リリースに関するカタログ情報に近い内容であり、網羅的な情報ではない

② 機能追加・変更点に関する Excel 一覧表

アプリ開発チームが、OS 機能変更内容の影響有無を素早く確認するために使うリスト

カテゴリ変更内容（機能追加・変更）ビルド番号参考 URL 要注意項目備考

スタートスタートメニューのタイル列数を 3→4 に増やせるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートタイルの表示増加機能を使った際のアプリリストの文字のスペースがより詰められた 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートスタートメニューのタイルでジャンプリストが使えるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートタイルのコンテキストメニューが再編成された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートデスクトップアプリのタイルに個別の色を付与できるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートスタートメニューのタイル数上限が 512 から 2048 に変わった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI スタート画面、タスクバー、アクションセンターの色とタイトルバーの色が連動するようになった10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

UI コンテキストメニューのデザインが変更された 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

UI ダークとライトのテーマが改善された 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

UI タスクビューからのアプリのスナップや入れ替えが可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI 横方向にアプリをスナップで並べた後、水平方向にサイズを同時に変更可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI コンテキストメニューの色が白からグレーに変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI ドロップダウンの見た目が変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI Windows アプリについて、起動・終了のアニメーションが追加された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI 一部のアイコンが変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

Cortana ローカルアカウントでも Cortana が動作可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

Edge ブラウザ Object RTC をサポート 10525 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10525/?compareWith=10240-

Edge ブラウザ新しい input type のサポート (time. text selectionDirection など) 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザポインターロック（マウスロック）に対応 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ Canvas のブレンドモードに対応 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザメーター要素の追加 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ asm.js が既定で有効になった 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ ES2015 関連の機能強化 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ User Agent 文字列が変更された 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ template, picture のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ srcset のサイズ拡張 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ a[download] 属性のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザプロキシ設定を Edge の設定から開くことが可能になった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ Edge のスタート画面が新しくなった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザメディアを別の画面と共有できるようになった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ適切にページングされている場合、次ページへのボタンがライトアップされるようになった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ Canvas ellipse のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ CSS :read-write, :read-only のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ CSS :in-range, :out-of-range のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ input type=datetype-local のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ SVG 外部コンテンツのサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ WebRTC - Object RTC API のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ ES2016 Async 関数のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ ES2016 累乗演算子のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

設定スタート画面、タスクバー、アクションセンターの色とタイトルバーの色が連動するようになった10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

設定タスクバーの設定アイコンの背景色がなくなった 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

設定設定画面のタイトルが透過色となった 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

システムメモリ管理が改善された 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

アプリ Windows Feedback でのフィードバックがより簡単になった 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

• カテゴリ• 変更内容（機能追加・変更のみ）• 導入された Windows Insider ビルド番号• 参考 URL

• 要注意項目（特に気を付けた方がよいもの）※実際には必ず全項目を確認してください

• 備考

現在開発中Sample 版

【① 主要な追加機能や変更点（一部のみ）】【② 機能追加・変更点に関するリスト】

有償サービス（Premier サポート）

p.45


（注意）非互換情報を元にしたテストケース絞り込みの注意点

どのような非互換情報リストを利用しても、完全にそれだけで非互換問題を事前に100% 洗い出すことは原理的にできない

「何を機能追加・変更とみなすのか？」に関しては、ある程度、人間の恣意的な判断が入ることが原理的に避けられないため

あらゆる修正は、たとえ API 外部仕様が一致していても、機能変更であるとも言える

かといって、あらゆる修正を機能変更であるとみなすと、リストが膨大になり、突合せ確認を行うことが不可能になってしまう

Windows OS の場合だと、API レベルでは数千～数万件単位の変更になってしまう

このため、各自のアプリに対して「最も実用的なレベル感・粒度感」に整理された非互換情報リストを使うことが、最も重要になる

WaaS 非互換情報提供サービスは、このことを意識して開発されている

どのような非互換情報を使った場合でも、見逃しは原理的に発生しうる

このため、より高い安全性のため、② 見逃しリスクへの対応の併用が必要

実際に非互換見逃しがあった場合には、次回の機能アップグレード時に、より粒度の粗い／細かい非互換情報リストを使うように変更していけばよい

機能追加

機能変更

全く変わっていない

Windows 10

Windows 10

機能変更に近い比較的大きな修正

極めて軽微な修正機能アップグレード

互換性リスク高

互換性リスク低

これらの境界線は原理的にグレー

修正（バグ、脆弱性、信頼性など）

微修正（リビルドなど）

p.46

互換性検証の効率化手法 - ② 見逃しリスクへの対応

非互換障害の見逃しリスクへの対応（被害の極小化）方法は、主に以下の 2 つ

A. 一部のアーリアダプタユーザに対する CB（または IP）の先行配信（リング配信）

社員の一部に、先行して CB （または IP）を配布して実業務で使ってもらう

非互換障害が発生した場合には、すみやかに修正を行う

B. ベンダーとの協業強化による迅速な障害修正対応フローの確立

特にアプリを外注している場合には、速やかな修正ができる体制を整えてくおく

エンド企業 SI ベンダー（協力会社）

CB リリース

インフラ IT 部門

• ハードウェアなどの基本互換性検証• 展開イメージ作成

業務部門テスター

• アプリ非互換検証（リグレッションテスト）

アーリアダプタユーザ

一般エンドユーザ

• CB を先行利用• 障害があれば報告

CBB リリース（CB + 累積パッチ）

• CBB を利用

1 ヶ

月1

ヶ月

2 ヶ

月

累積月例パッチ

非互換障害

非互換障害

修正依頼

修正版納品

4 ヶ

月

開発環境

ソース管理

自動ビルド

成果物

テスト環境

A

B

修正リードタイムの短縮

p.47

A. 一部のアーリアダプタユーザに対する CB（または IP）の先行配信

Windows OS そのものの開発でも利用されている手法（リング配信と呼ばれる）

段階的に利用者を増やしていくことにより、非互換問題発生時の問題を極小化する

アプリによって、先行検証の実施時期や、利用する OS ビルドが異なる

アプリの特性に合わせた、実地検証の期間の取り方などを事前に決定しておくこと

社内アーリーアダプタ

開発チーム

一般コンシューマユーザ

開発チーム


4 months

CB リリース（コンシューマ向け

リリース）

CBB リリース（ビジネスユーザ

向けリリース）

前バージョンの CB リリース

• コンシューマ向けサービス• ISV パッケージ製品・サービス

β テスター

• まず開発チームのメンバーが先行してInsider Preview を利用して検証・テスト

• 頻度が高く、検証に取れる時間も限られているため、テストはある程度自動化されていることが望ましい

• 一部のエンドユーザに先行検証利用を依頼し、現場で実地的な検証を実施

• CB リリースに併せて一気に利用ユーザが増える

• このため、CB リリースまでに十分な検証を済ませることが必要

• 社内業務アプリ（機能アップグレードのみ事前互換検証する場合）

インフラ部門側での準備期間

• 非互換情報を元に、互換性検証を実施

• 必要に応じて修正

一般社員

• 一部ユーザに OS を先行展開

• 不具合報告してもらう

• CBB がリリースされたら大規模に展開していく

Insider Preview リリース

アプリチーム事前チェック

期間

OS 先行展開実地検証期間

p.48


B. ベンダーとの協業強化による迅速な障害修正対応フローの確立

アーリーアダプタやエンドユーザから非互換障害が報告された際に、速やかに修正・再リリースが実施できる体制を整えておくことも重要

以下のような場合、障害修正に時間がかかることが多いため、見直しを推奨

内製あるいはそれに準じる体制を取っていない場合

リリースに必要なテスト（デグレードテスト）が手作業で行われている場合

修正作業の依頼や確認に、大量の書類による手続きが必要になっている場合

エンド企業 SI ベンダー（協力会社）

修正依頼

修正版納品

開発環境

ソース管理

自動ビルド

成果物

テスト環境

エンドユーザ

IT 部門

アプリ A

主幹部門

障害情報

障害情報

開発体制が社外にあるとすぐに修正・リリースできない

手作業だと再テストに時間がかかる

書類手続きが煩雑だとそれだけで時間がかかる

p.49

互換性検証の効率化手法 - ③ テストの更なる実施効率化

さらに、以下のような手法を組み合わせると、互換性検証作業をより効率的に実施することができる

• 以下のような用途で仮想環境を活用すると、テストの作業効率が大幅に改善する

次期 CBB クライアント環境を仮想環境として用意する（互換性検証用のテストマシンの準備工数が大きく削減される）

テスト用サーバ側環境を仮想環境として構築する（スナップショットを活用することで、テスト用サーバを容易に初期状態に巻き戻せるようになる）

• 互換性検証のたびに、業務や技術に詳しい SE やエンジニアが狩り出されると、現場業務に支障が出る

このため、非有識者でも再テストできるようにする• 具体的には、以下のような手法を組み合わせる

テスト環境の状態によって、テスト実施結果が変わらないようにテストケースを作成する（リピータブルにテストを設計する）

有識者によるテストを、ビデオ録画などで記録しておき、これを活用する

• 仮想環境の利用や、リピータブルなテストケース設計が正しくできていると、UI テストの自動化も可能になる

UI テストの完全自動化はコストメリットが薄いが...

互換性検証に必要な最小限のテストケースのみを自動化すると、メリットが非常に大きい

累積パッチに対しても素早い互換性検証が可能になる他、迅速なデグレードテストなども可能に

• CUIT （Coded UI Test）ツールなどを用いて、UI 打鍵を

自動化すると共に、適切な結果検証ロジックを開発して利用する

• 特に大企業の場合には、互換性検証は全社的な目線で考えると、大きく最適化できる可能性がある

• 主なポイントとしては...

テスト対象とする業務システムそのものの絞り込み（類似アーキテクチャを持つシステム群は、そのうち一つだけを互換性検証の対象とする）

テストインフラの準備（個々の業務システムごとに用意するより、全社的に用意した方が安価）

互換性検証テストチームの運営（専任チームを作った方が互換性検証のノウハウが貯まる）

A. 仮想環境の活用 B. 非有識者による再テストの実施

C. UI テストの自動化 D. 全社的視点での互換性検証の最適化

p.50


（参考）テストインフラの必要性について

前述のような様々なテスト実施改善を進めていく際には、テストインフラの構築とテストツールの導入が欠かせない

日本の開発現場の多くでは、未だ Excel でのテストケース管理やテスト結果管理が行われているが、これではテストの実施効率がまったく上がらない

近代的なテストインフラの構築とテストツールの導入により、テスト実施作業の効率化を推進していくことが望ましい

マイクロソフト製品であれば、以下のようにするとよい

Hyper-V を用いた仮想化テスト環境（※ ラボ環境と呼ばれる）を構築する

テスター向けツールである Microsoft Test Manager を使う（次ページ参照）

※ これらのツールや環境は、全社レベルで導入するとコスト効果が高い

テストチーム

テスターテストサーバ①

テストサーバ②

ラボ環境（仮想化テスト環境）

テストマシン①

テストマシン②

リモートデスクトップ接続

テスターリモートデスクトップ接続

テスト管理サーバ

テスト結果データの集積

テストツールがセットアップされた新しいバージョンのOS 環境

p.51


（参考）テストインフラの必要性について（続き）

Microsoft Test Manager （MTM）の主な機能

• コンピュータ名• ユーザ名、ドメイン名• OS バージョン• システムディレクトリ• ロケール• CPU 種別• 物理メモリ、空きメモリ• スクリーンサイズ• IE バージョン、etc...

ユーザの操作に関する情報（わかりやすい日本語で表記）

当該テスト中に動作したコードに関する情報

テスト実施中の画像（既定では 4fps, 512Kbps）

MTM によるテスト結果収集MTM によるテストケース管理

MTM によるバグ管理

MTM でのログを元にして、自動的に再現手順が作成される（ここに必要に応じて追記してよい）

どのようになっていれば修正が完了したと言えるのか、期待される動作についてここに記述する

バグに対して適切な名称を付与する

ユーザが被る被害の深刻度を報告

MTM による結果分析

システム情報

操作ビデオ

テスト影響データ

操作テキストログ

成功したテストケース

失敗したテストケース

まだ実施されていないテストケース

その他の状態のテストケース

何らかの理由で実施できないテストケース

テスト実施状況レポート

p.52


（注意）特に③の改善施策は、アプリ開発時から手を打つ必要があるものが多い

このため、既存レガシーアプリに対しては、③の施策が打てないことも多い

現行システムに対して施策が打てない場合でも、次期大規模改修の際には、『テストしやすいように』アプリ開発を行うとよい

適切なアプリアーキ定義

適切なテストケース設計

適切なテストインフラ上でのテスト

テスト自動化を踏まえた開発

効率的な互換性検証の実施

自動テストによる再テスト実施

手動再テストの効率化

テストケースのロジカルな抽出

テストゴールの適切な設定

UT/IT のテスト自動化

自動テスト環境の維持

手動テスト環境の維持

テスト結果のデータ蓄積

テストケースの適切な整理

アーキテクチャ情報の整理

ミドルウェア情報の整理

バグ・障害情報の共有適切な

アプリ開発

開発時にしておくべきことスムーズな互換性検証の実施に必要なこと

CI/CD 環境を用いた開発

速やかなバグ修正と再リリース

CI/CD 環境の維持

適切な設計

適切なテスト

テスト駆動開発

ビルド・リリース基盤

p.53


マイクロソフト社内の Win10 WaaS 対応に関する情報は、比較的詳細なレベルまで Web 上に公開されている

MS 社内の約 2,100 個程度の社内業務アプリに対する非互換検証の実施方法がまとめられている

MSIT と呼ばれる社内 IT 部門が社内業務アプリを管理しており、非互換検証についても積極的に対処している

非互換障害が発見された場合、必要に応じて、アプリ側の修正ではなく Windows OS 側の修正となる点は一般と異なるが...

非互換検証作業の具体的な効率化手法に関しては、参考になる部分も多い

事例 URL は以下の通りですhttps://www.microsoft.com/itshowcase/Article/Content/668/Deploying-Windows-10-at-Microsoft-as-an-inplace-upgrade

https://www.microsoft.com/itshowcase/Article/Content/519/Microsoft-IT-improves-LOB-application-testing-ensuring-readiness-for-Windows

https://www.microsoft.com/itshowcase/Article/Content/520/Microsoft-IT-prepares-LOB-apps-for-Windows

p.54


Web 上の情報を要約すると、以下の通り

互換性検証を効率的に進めるため、グローバルで集約テストチームを運営

2,100 個の業務アプリから 300 個を選出して集中的にテスト、段階的な OS 配布を併用することで、致命的な非互換問題の発生を防いでいる

これらにより、互換性維持の費用を約 7,000 万円／年程度にキープし続けている



③ テストの更なる実施効率化

【テスト対象システムの絞り込み】• アプリケーションポートフォリオ

管理ツールで、社内 LOB システム約 2,100 個を一元管理

• この中から約 300 個を Key

Test Group として選出、これ

を重点的にテストし、その結果を元にアップグレードを判断

• 選出の観点は以下の 2 つ業務の重要度：約 150 個技術的類似性や過去の非

互換問題に基づく選出：約150 個

• 選出されなかったシステムは、特に積極的なテストはしない（OS 展開前に、ローカル部門の判断でテストできる猶予期間を 3 週間設けてはいる）

【段階的な OS 配布】• 社内アーリアダプタユーザ（ボ

ランティア）が Insider

Program に参加して業務で利用

• 見つかった障害に対してはR&D と連携し、必要に応じてOS 側を修正して互換性を向上させる

【コード修正】• 多くのシステム（約 80%）は内

製のため、速やかなコード修正が可能

• 非内製アプリは修正に時間がかかるため、なるべくテスト優先度を高めている

【集約テストチームの運営】• Key Test Group に関しては、

グローバルで集約テストチームが積極的にテストを実施

【テストの自動化】• 自動化テストを駆使し、5 日間

で全システムをテストできる状態を保ち続けている

• 自動化率は 50～85% 程度

【仮想環境の活用】• アプリ互換性検証はすべて仮

想マシンで実施• ローカル部門のテスト容易化

のために、テスト用仮想マシンの貸し出しを実施（※現在はクラウドを活用）

p.55


MSIT の事例からわかるように、アプリ互換性検証の効率化を大きく高めたい場合、会社全体としての取り組みが必要になる

下図のように、全社で取り組むべきものと個々のシステムで取り組むべきものがある

しかし日本の大企業の場合、こうしたアプローチが困難なことも実際には多い

互換性検証の効率化

会社全体としての効率化

個別システムでの効率化

テスト対象システムの絞り込み

アーリーアダプタコミュニティの運営

集約テストチームによる非互換検証

テストケースの絞り込み

UI テストの自動化

テスト管理・実施の効率化

迅速なバグ修正とリリース

分類主な施策目的施策の内容

• アプリケーションポートフォリオ情報を元に、アプリ互換性検証を実施するシステムを絞り込む

• 一部ユーザに先行して IP/CB を配布できるインフラを用意し、見逃し非互換を実地的に発見していく

• 個別システムで実施されるアプリ互換性検証（の一部）を巻き取って集約実施することで、効率的な非互換検証を行う

• 処理の類似性、業務的重要度、過去の互換性問題の傾向などから、実施するテストケースを絞り込む

• 打鍵テストの一部をツールにより自動化することで、アプリ互換検証の省力化を行う

• ビデオログの取得や仮想環境の活用により、非有識者によるテスト実施やテスト実施の作業効率化を進める

• 障害（見逃し非互換）発覚時に、速やかにバグ修正を行いユーザに再リリースできるようにする

①

②

③

①

②

③

③

（主に全社 IT 部門で実施）

（主に個別業務部門で実施）

①

②

③

テストケースの絞り込み

見逃しリスクへの対応

テストの更なる実施効率化

p.56


会社全体としての取り組みが困難な理由として、主に以下のようなものがある

各業務部門が異なる SIer・ベンダーを使っており、システムが個別最適化されている

技術的アーキテクチャ、作業プロセスがすべて異なるため、全体最適化ができない

予算管理・執行が分断しており、全体最適化が図られていない

IT インフラは標準化されているが、開発ツールやテストインフラは標準化されていない

IT 部門がインフラ管理に特化しており、アプリ領域の実態に関する知見を持たない

IT 部門側がアプリの作りや非互換検証の実態を把握できていない

これらの問題が解決されないと、全体最適化が進められないことが多い

部門単位で解決できる課題ではないため、経営層も巻き込んだ検討が必要

アプリ A

主幹部門SI ベンダー A

アプリ B

主幹部門SI ベンダー B

アプリ C

主幹部門SI ベンダー C

IT 部門

インフラのみアプリのみ

予算管理と執行の壁

個別最適化された

システム開発

p.57


今後の業務アプリ開発では、開発のやり方の見直しが必要になる場合もある

もともと Win10 WaaS は、時代の要求から生まれてきたもの

業務アプリも、基本的に「進化していく基盤上で動作を保証し続ける」ことが必要になる

このためには、開発手法や開発のガバナンスの考え方の見直しが必要になる

塩漬けの開発基盤

レガシーアプリモダンアプリ開発手法の変化

進化する開発基盤

後付けの保守作業最初から保守を想定した開発

手作業のビルドとリリース継続的なビルドとリリース

場当たり的なデバッグユニットテストツールの積極活用

手作業での打鍵結合機能テスト仮想環境と自動テスト技術の活用

技術的負債の蓄積定期的なリファクタリング

開発基盤

保守作業

ビルド・リリース作業

単体機能テスト

結合機能テスト

継続的改善

バラバラの利用技術

個別最適化された開発全体最適化された開発開発に関するガバナンス

標準化された利用技術

個別最適化された開発インフラ標準化された開発インフラ

個別最適化されたテストインフラ標準化されたテストインフラ

テクニカルアーキテクチャ

開発作業基盤

テスト実施基盤

個別最適化された運用環境と配布方式標準化された運用環境と配布方式運用基盤

これまでのシステム開発今後のシステム開発

p.58


特にテクニカルアーキテクチャの領域に関しては、以下がポイントになる

利用する開発技術と、作り方に関する開発標準の導入

大企業では、各部門ごとに異なる SI ベンダーを利用し、SI ベンダーごとのやり方をそのまま採用しているケースも少なくない

縛りを入れすぎると SI ベンダー側の生産性を損なうが、ある程度の「緩い」開発標準を導入して、『作り』に関する標準化を進めることは、運用や保守の容易化につながる

具体的なポイントとしては...

クラウド PaaS モデルの考え方の利用（運用や配置などの流れを標準化できる）

開発技術の「標準」パターンの策定（開発パターンごとに利用する技術を決めておく）

アプリ A

主幹部門SI ベンダー A

アプリ B

主幹部門SI ベンダー B

アプリ C

主幹部門SI ベンダー C

IT 部門

ある程度の標準の導入

p.59


特に画面設計の領域では、以下がポイントになる

硬直的な UI デザインの回避（柔軟な UI デザインの採用）

非互換問題のひとつに、日本ならではの職人的精密さを持つ UI デザインがある

しかし Windows OS の UI は、時代の UI トレンドに併せて進化してきている

硬直的な UI デザインを行うと、OS バージョンアップ時にレイアウトが崩れやすくなる

具体的なポイントとしては...

レスポンシブ対応による、様々なスクリーンサイズへの柔軟な対応

XP, 7, 10 などを振り返った際に、すべての OS で通用しうる UI デザインの採用

Windows 10

Mobileタブレット

Surface Hub

どのスクリーンサイズでもそれなりに通用する UI

どのデザインでもそれなりに通用する UI

PC

Windows 7

Windows 10

p.60


特に非互換検証の領域に関しては、以下の 2 つがポイントになる

1. 「テスタブル」にアプリケーションを開発する

何も考えずに作ったアプリをテストするよりも、「テストしやすいように」作られたアプリの方が、圧倒的に効率的にテストを行うことができる

2. テスト駆動型（テストファースト）な実装スタイルを確立する

「出来上がってからテスト」するのではなく、「作りながらテストも開発する」

単体機能テストや結合機能テストをコードとして実装し、手作業で行うテストを最小化しておくことにより、繰り返しの互換性検証の実施が容易になる

こうした「先々の非互換検証」や「先々の機能追加」を見越した開発スタイルは、現在の多くの開発現場の開発スタイルと大きく異なるため、現場の改善が必要になる

AuthorFirstName

AuthorLastName

Phone

State

ViewModel クラス

エラー

エラーテスト

テスト

1. テスタブルなアプリ開発 2. テスト駆動型でのアプリ実装

例）設計に MVVM モデルを使うことで、打鍵テストを自動テストに変えてしまう

開発環境ラボ環境ドロップポイント

テストサーバ①

テストマシン①

自動配置＋自動テスト

ソースコード管理

自動ビルド

単体機能テスト

結合機能テスト

p.61

Windows 10 WaaS でのレガシーアプリ互換性検証のまとめ

Windows 10 → 10 の既存レガシーアプリ非互換を、過度に恐れる必要はない

Windows 10 WaaS に移行した後に、非互換検証を過度に繰り返す必要はない

基本的なアプローチは以下の 3 つだが、既存レガシーアプリでは①②の対応しか取れないことが多い

① テストケース割愛

② リスク低減のための OS 段階展開と迅速な非互換障害修正

③ 更なる互換性検証の実施効率化

現在実施している非互換検証のレベルに基づいて、Win10 移行後の非互換検証方式を決めるとよい

中長期的な対応としては、開発のやり方そのものに対する改善が必要

テクニカルアーキテクチャの領域

利用する開発技術と、作り方に関する開発標準の導入により、全体最適化を図る

画面設計の領域

硬直的な UI デザインの回避（柔軟な UI デザインの採用）

非互換検証の領域

「テスタブル」にアプリケーションを開発する

テスト駆動型（テストファースト）な実装スタイルを確立する

Windows 10 導入時に考え方・やり方を変えるべきポイント – インフラ系

p.63

IT インフラ管理の見直しの重要性

Windows 10 導入に際しては、現在の IT インフラ管理の見直しが重要になる

日本の大企業では、IT インフラ管理に関する「人手での作業」が非常に多いが…

昨今のクラウド化の流れや IT 自動化の流れを踏まえると、こうした「人手での作業」は限界を迎えつつある

Windows 10 導入時に『負の遺産』を清算し、IT インフラの近代化を進めることが重要

以下の 3 つのトピックは、従来の考え方を大きく変えるべきポイントであるため、見直しや検討を進めるとよい

1. セキュリティ

• Windows 10 のセキュリティ機能の活用方法を考える

• ハードウェア選定などに関わるため、将来的な利用も含めて検討する

2. マスタイメージ管理

• Excel の情報管理や Word の手順書などに依存した作業を見直す

• これにより IT インフラ保守作業の近代化を図る

3. FU/SU 配信制御

• 継続的な FU/SU 配信ができる仕組みを作り上げる

• これにより、Windows 10 OS

の継続的な最新化を図る

① ID 保護・アクセス制御

② 情報保護

③ 脅威対策

① パラメータシートの扱い

② マスタイメージの作成

① リング配信制御

② 分散拠点への配信

p.64


近代的なセキュリティの脅威に対応していくため、以下をよく考える必要がある

安全性と利便性の両方を取る

安全性を高めようとして制限を増やしすぎると、社員の生産性が低下してしまう

安全性と利便性のバランス（＝効用）を考えて、適切な落としどころを考える必要がある

「ルール」を増やさず「技術」を活用

覚えられない＆守れないルールを作るのではなく、「技術」で安全性を高める

技術的に見た場合には、主に以下の 3 つのカテゴリに分けて考えるとよい

（Windows 10 の新機能ではないものもあるが）この機会に導入を検討するとよい

カテゴリ

主な機能

① ID 保護・アクセス制御 ② 情報保護 ③ 脅威対策

パスワードやトークンを盗まれないようにする

機密情報を流出させないマルウェア対策（不正なアプリを動作させない）、不正検知

Windows Hello（パスワードを使わせない）

Microsoft Passport（多要素認証を容易に実現）

Credential Guard（クレデンシャルを盗ませない）

BitLocker, BitLocker To Go（端末・USB 紛失時のリスク低減）

Azure RMS（Office ドキュメントの漏洩リスク低減）

Windows Information Protection（企業データの漏洩リスク低減）

Device Guard（不正アプリの実行防止）

AppLocker, ソフトウェア制限ポリシー（不正アプリの実行防止）

Windows Defender（アンチマルウェア）

概要

リモートワイプ（端末紛失時のリスク低減）

Windows Defender ATP（セキュリティ警告やログの一元管理）

p.65


（ご参考） Windows OS の代表的なセキュリティ機能と強化の経緯

TH12015年7月リリース

RS12016年8月リリース

TH22015年11月リリース

認証マルウェア対策とネットワーク保護

Webブラウザー

脆弱性防御データ保護

マイクロソフトアカウント連携

仮想スマートカード

PIN/ピクチャパスワード

Windows Defender(Malware)

Secure Boot / Trusted Boot

Windows RT アプリ

OMA-DM

Microsoft Intune 連携

IE10 拡張保護モード

SmartScreen 機能強化

ASLR v2Kernel SMEP & DEPHeap hardening v3

Windows Firewall マルチプロファイル

IE9 通知バー

InPrivate ブラウズ

追跡防止機能

ActiveX フィルター

SmartScreen

Windows Biometric Framework

新しいサービスアカウントモデル

User Access Control の機能強化

IE8 保護モード

AppLocker

Network Access Protection

証明書展開機能強化

Direct Access

監査ログ機能の強化

BitLocker to Go (USB)

クロスサイトスクリプティングフィルター

Microsoft Passport

Windows Hello

Azure AD 連携

OMA-DM 機能拡張

Microsoft Intune 連携

Windows Defender(OMA-DM 連携)

ロックダウン

Microsoft Edge

制御フローガード

User Access Control

Credential Provider

高度な Windows Firewall

Windows Defender (Spyware)

Windows セキュリティセンター

Windows Resource Protection

プロセスの整合性レベル

監査ログ機能

BitLocker (OS)

BitLocker (Data)

ASLR v1SEHOP

Heap hardening v2

IE7 保護モード

IE7 アンチフィッシイング

DEP/GS

SafeSEHHeap hardening v1

IRM/RMS

Windows Firewall

暗号化ファイルシステム

企業データ保護Windows Information Protection

Windows DefenderAdvanced Threat Protection

Lockdown VPN

Phone Sign-In

Windows HelloMicrosoft Passport

機能拡張

Credential Guard

Device Guard

Microsoft Passport 機能拡張

Microsoft Intune フルワイプサポート

Conditional Access

Device Health Attestation

p.66


セキュリティ機能によっては、デバイス, OS（アーキテクチャ）, ブートシステムなどの選択に影響が出るものがあるため、注意して検討しておくこと

Windows 10 導入直後には採用しないものの、いずれ採用したいというセキュリティ機能がある場合には、その制約を確認しておく必要がある

例えば x64/x86, ブートシステムなどは、OS 再インストールを必要とする場合があるため、Windows 10 導入時の検討ポイントに入れておくことが必要

セキュリティ機能 Windows Hello Credential Guard BitLocker Device Guard

ハードウェア

生体認証 WBF 対応ハード

TPM 1.2 or 2.0 1.2 or 2.0 1.2 or 2.0 1.2 or 2.0

仮想化拡張機能Intel VT-x/AMD-V,

SLAT

Intel VT-x/AMD-V,

SLAT

入出力メモリ管理ユニット

VT-D/AMD-Vi VT-D/AMD-Vi

BIOSセキュア MOR ビット

セキュア MOR ビット

物理 PC 仮想マシン不可仮想マシン不可

OS

アーキテクチャ x64 x64

エディション Enterprise Enterprise

ブートUEFI 2.3.1 セキュアブート

UEFI 2.3.1 セキュアブート

※上記の表は Windows 10 OS バージョンにより異なる場合があるため、必ず最新情報を確認すること

p.67

2. マスタイメージ管理

以下の 2 つを行っている場合は見直しを行い、IT インフラ保守の近代化を図る

① パラメータシートによる設定値の一覧管理

増え続けるパラメータを管理し続けること自体に無理がある

「実態」を実物管理し、そこに機能差分を調べて「追加していく」アプローチを採用する

② 手作業でのクライアント端末マスタイメージの作成・保守作業

端末種類が増えるとイメージ管理作業が膨大になるため、タスクシーケンスを作成する

さらに SCCM を使えば、キッティング作業も大幅に簡素化される

① 設定値の一覧管理 ② マスタイメージの作成・保守

• 従来は、Excel ファイルを正として設定値一覧を管理していたが…

• メンテナンスが非常に大変！

• グループポリシーや OCT ツールによる設定情報の実物そのものを正とする

• 既定値のまま利用することを基本とし、使いたい機能の差分だけを設定する（むやみに設定値を変えない）

インストール手順書

エンジニアが機種ごとに作成

sysprep

FU リリース時にイメージを更新

最新版イメージのメンテが大変！

インストール時のカスタマイズ内容を

検討

MDT / SCCM

タスクシーケンス

機種ごとのドライバ

SCCM

サーバ

OS

イメージネットワークインストール

ネットワークブートから

簡単にセットアップできる

定期的に差し替え

Before

After

（参考情報）System Center 2012 R2 Configuration Manager 評価ガイド - OS 展開編https://www.microsoft.com/ja-jp/download/details.aspx?id=41687

p.68


FU/SU 配信制御では、以下の 2 つを加味して配信方式を検討する必要がある


アプリ非互換の見逃しリスク低減のため、FU/SU の段階展開が必要になる

拠点のような単位ではなく、部門内・拠点内での段階展開が必要であることに注意する

② 分散拠点への FU/SU 配信

FU は 3～4GB（半年ごと）程度、SU は累積パッチであるため最大 1GB 程度（月次）

このため、細い WAN 回線を利用している分散拠点への配信方法の検討が必要

IT 部門の一部社員

IT 部門

各部門の有志の社員

一部の社員大多数の社員

先行検証期間

本格展開（CBB リリース）

検証用の導入（CB リリース）

① リング配信制御 ② 分散拠点への FU/SU 配信

インターネット

WAN

（太い回線）WAN

（細い回線）WAN

（細い回線）

小さな分散拠点

大きな分散拠点

本社

ネットワーク配信が困難

p.69


FU/SU の代表的な配信方法は主に以下の 3 通り（＋メディア配布）だが、主に以下のような指針で最適なものを選ぶ


『特定のユーザ』への段階展開が必要だが、この制御は SCCM が最も柔軟にできる

マスタイメージの作成や端末管理などでも活用できるため、SCCM が導入されている場合には、これが第一選択となる

SCCM が導入されていない or 導入予定がなければ、WSUS, WU のどちらかを選ぶ

② 分散拠点への FU/SU 配信

WAN 帯域が細い場合、分散拠点側に配布ポイントや子サーバを配置する方法が考えられるが、分散拠点側でこうしたサーバマシンを運用できないケースもある

このような場合には、P2P オプションを使う

WAN 帯域が極端に細い場合には、最後はメディア配布でカバーすることになる

配信方法リング制御分散配布 P2P オプション備考

SCCM ◎ 柔軟に可能 ◎ 配布ポイント ◎ BranchCache• SCCM のバージョンアップが必要• SCCM は端末管理やマスタ管理にも活用可能

WSUS △ 可能だが面倒 ◎ 子サーバ◎ BranchCache

◎ DO (RS1 以降)

• 差分配布（高速インストールファイル）をサポート• O365 ProPlus の配信ができない

WU× 細かい制御は困難

× なし ◎ WUDO －

メディア（手作業での配布）（手作業での配布）（手作業での配布）－

SCCM : System Center Configuration Manager

WSUS : Windows Server Update Services

WU : Windows Update

WUDO : Windows Update Delivery Optimization

DO : Delivery Optimization

p.70

（参考） Windows 10 における継続的な情報入手について

OS としての大きな機能追加・変更点を把握する際は、Windows for Business

サイトを活用するとよい

セキュリティをはじめとする新機能を「大きな粒度で」把握したい場合には、Windows

Insider blog や Premier WaaS 非互換情報提供サービスだとかえって分かりづらい

このような場合には、まず下記 2 つのマイクロソフト公式サイトから「大きな粒度での」機能追加・変更を把握する

その後、新機能を詳細検討し、グループポリシーやマスタイメージへの組み込みなどを進めていくとよい

大企業向けオススメ機能リストhttps://www.microsoft.com/ja-jp/WindowsForBusiness/windows-product-home

機能追加リストhttps://www.microsoft.com/ja-jp/WindowsForBusiness/windows-roadmap

p.72


インフラ／アプリどちらの観点であっても、FU/SU での変更点を把握して検討することが重要になる

インフラ観点 : FU で提供される新機能をどのように取り込むか？

アプリ観点 : FU/SU で行われた変更でどのようなデグレードが発生しそうか？

基本的な流れは、以下のように整理することができる

① IP リリースごとに、機能追加・変更と、修正（脆弱性・バグ）が行われる

② ①がある程度貯まると、CB として FU がリリースされる

③ FU リリース後は、サポート終了まで修正（脆弱性・バグ）が SU として配信される

これらの一連の流れにおいて、以下を整理しておく必要がある

マイクロソフトから、どのタイミングでどこからどのように情報が提供されているのか？

自社での検討のために、どのタイミングでどのような情報が欲しいのか？

~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


1607 (RS1)

Anniversary Update



Nov



Grace

Grace


2016 2017

60 days

60 days

Grace

Feb2018

60 days

July

CB リリース

CBB リリース

IP リリース

FU リリース

SU リリース

p.73


変更情報には、「機能追加・変更」に関する情報と、「修正」に関する情報がある

どのレベルで非互換情報を確認するのかを意識することが非常に大切

ミッションクリティカル度が高い場合

機能追加・変更だけでなく、修正情報（パッチ情報）についても確認が必要だが...

この場合、パッチリリースごとの確認が必要 → 自動化されたテストの繰り返しが必要

ミッションクリティカル度が中程度の場合

この場合、機能追加・変更を中心に確認することになる


パッチ


パッチ

OS （Windows 7）


ユーザアプリ

Windows 7

OS （Windows 10）


ユーザアプリ

Windows 10


パッチ


パッチ

OS （Windows 10）


ユーザアプリ

Windows 10

要確認要確認

p.74

代表的な非互換情報の提供サイトについて

非互換情報は、公式／非公式さまざまなサイトから提供されているが、前述のテストケース絞り込みの目的で役立つものは比較的少ない

changewindows.org の情報が最も使い勝手がよいが、非公式・英語という難点あり

この問題を解決するため、日本独自のサービスメニューとしてプレミアサポートより WaaS 非互換情報提供サービス（有償）を開発・ご提供している

変更情報の入手場所

スコープ提供頻度情報粒度公式／非公式

有償／無償 URL 備考

Insider Preview ごと

機能アップグレードごと

サービス更新（累積パッチ）ごと


修正（脆弱性・バグなど）

Windows Insider blog Windows OS 全体

〇 × × 〇 △ 公式無償リンク情報がやや細かいため、整理が必要


Edge ブラウザ

〇〇 × 〇 △ 公式無償リンク

ChangeWindows.org Windows OS 全体

〇〇 × 〇 × 非公式無償（寄付）リンク非公式だが、最も使い勝手はよい

ASKVG Windows OS 全体

〇〇 × 〇 × 非公式無償リンク


Windows OS 全体

× × 〇 × △ 公式無償リンク日本語情報あり

Premier WaaS 非互換情報提供サービス

Windows OS 全体

× 〇 × 〇 × 公式有償 - 有償だが、日本語での使い勝手のよい情報提供が可能

〇 : 含まれている△ : 含まれているが完全ではない（代表的なものに限られる）× : 含まれていない

〇 : この頻度で情報公開

※パッケージ製品の OS 対応状況については各ベンダーにお問い合わせください




http://www.askvg.com/


p.75

Windows Insider blog

マイクロソフトから公式情報として公開されている、機能追加・変更・修正情報

機能追加・変更を網羅しており、修正情報は代表的なものが取り上げられている

プレビュービルド毎に情報公開しているが、機能アップグレード毎に整理されていない


~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


Summer 2016 (RS1)

(Anniversary Update)(Exact date TBD)



Nov



Grace

Grace


2016 2017

60 days

60 days

Grace

Feb2018

60 days

July

CB リリース

CBB リリース

情報提供

p.76


Edge 開発チームから公式情報として公開されている機能追加・変更・修正情報

機能追加・変更を網羅しており、修正情報は代表的なものが取り上げられている

Web 上で、任意のプレビュービルド間での差分情報をまとめて表示することが可能


~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


Summer 2016 (RS1)




Nov



Grace

Grace


2016 2017

60 days

60 days

Grace

Feb2018

60 days

July

CB リリース

CBB リリース

情報提供

差分情報

p.77

ChangeWindows.org

公式サイトなどの情報を元に作られた、非公式の機能追加・変更情報サイト

Insider Preview 単位の情報提供に加え、機能アップグレードごとに集約情報を提供

PC, Mobile, Xbox, Server, IoT すべての情報をわかりやすく一覧化して情報提供


~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


Summer 2016 (RS1)




Nov



Grace

Grace


2016 2017

60 days

60 days

Grace

Feb2018

60 days

July

CB リリース

CBB リリース

情報提供

まとめ情報提供

p.78

ASKVG

公式サイトなどの情報を元に作られた、非公式の機能追加・変更情報サイト

Insider Preview 単位の情報提供に加え、機能アップグレードごとに集約情報を提供

ChangeWindows.org に比べて説明は細かいが、一覧性には劣る

http://www.askvg.com/category/windows-10/

~4 months 12 months

1507 (TH1)

1511 (TH2)

November Update


Summer 2016 (RS1)




Nov



Grace

Grace


2016 2017

60 days

60 days

Grace

Feb2018

60 days

July

CB リリース

CBB リリース

情報提供

まとめ情報提供

p.79


サービスアップデート（累積パッチ）の内容を解説した内容

CB リリース後の脆弱性・信頼性・バグ修正に関する情報を提供するもの

日本語での情報提供もある


1507 (TH1)

1511 (TH2)

November Update

~8 months

Summer 2016 (RS1)



4 months

Nov



Grace

Grace


2016 2017

Grace

Feb2018

July

CB リリース

CBB リリース

情報提供

p.80

Premier WaaS 非互換情報提供サービス

WaaS 非互換情報提供サービスでは、以下を機能アップグレードごとにご提供

① 主要な追加機能や変更点について解説する ppt 資料

※新製品リリースに関するカタログ情報に近い内容であり、網羅的な情報ではない

② 機能追加・変更点に関する Excel 一覧表

アプリ開発チームが、OS 機能変更内容の影響有無を素早く確認するために使うリスト

カテゴリ変更内容（機能追加・変更）ビルド番号参考 URL 要注意項目備考

スタートスタートメニューのタイル列数を 3→4 に増やせるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートタイルの表示増加機能を使った際のアプリリストの文字のスペースがより詰められた 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートスタートメニューのタイルでジャンプリストが使えるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートタイルのコンテキストメニューが再編成された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートデスクトップアプリのタイルに個別の色を付与できるようになった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

スタートスタートメニューのタイル数上限が 512 から 2048 に変わった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI スタート画面、タスクバー、アクションセンターの色とタイトルバーの色が連動するようになった10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

UI コンテキストメニューのデザインが変更された 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

UI ダークとライトのテーマが改善された 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

UI タスクビューからのアプリのスナップや入れ替えが可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI 横方向にアプリをスナップで並べた後、水平方向にサイズを同時に変更可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI コンテキストメニューの色が白からグレーに変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI ドロップダウンの見た目が変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI Windows アプリについて、起動・終了のアニメーションが追加された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

UI 一部のアイコンが変更された 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

Cortana ローカルアカウントでも Cortana が動作可能になった 10547 https://blogs.windows.com/windowsexperience/2015/09/18/announcing-windows-10-insider-preview-build-10547/-

Edge ブラウザ Object RTC をサポート 10525 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10525/?compareWith=10240-

Edge ブラウザ新しい input type のサポート (time. text selectionDirection など) 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザポインターロック（マウスロック）に対応 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ Canvas のブレンドモードに対応 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザメーター要素の追加 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ asm.js が既定で有効になった 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ ES2015 関連の機能強化 10532 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10532/?compareWith=10525-

Edge ブラウザ User Agent 文字列が変更された 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ template, picture のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ srcset のサイズ拡張 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ a[download] 属性のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザプロキシ設定を Edge の設定から開くことが可能になった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ Edge のスタート画面が新しくなった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザメディアを別の画面と共有できるようになった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ適切にページングされている場合、次ページへのボタンがライトアップされるようになった 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ Canvas ellipse のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ CSS :read-write, :read-only のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ CSS :in-range, :out-of-range のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ input type=datetype-local のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ SVG 外部コンテンツのサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ WebRTC - Object RTC API のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ ES2016 Async 関数のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

Edge ブラウザ ES2016 累乗演算子のサポート 10547 https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/desktop/10547/?compareWith=10532-

設定スタート画面、タスクバー、アクションセンターの色とタイトルバーの色が連動するようになった10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

設定タスクバーの設定アイコンの背景色がなくなった 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

設定設定画面のタイトルが透過色となった 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

システムメモリ管理が改善された 10525 https://blogs.windows.com/windowsexperience/2015/08/18/announcing-windows-10-insider-preview-build-10525/-

アプリ Windows Feedback でのフィードバックがより簡単になった 10532 https://blogs.windows.com/windowsexperience/2015/08/27/windows-10-insider-preview-build-10532-for-pc/-

• カテゴリ• 変更内容（機能追加・変更のみ）• 導入された Windows Insider ビルド番号• 参考 URL

• 要注意項目（特に気を付けた方がよいもの）※実際には必ず全項目を確認してください

• 備考

現在開発中

【① 主要な追加機能や変更点（一部のみ）】【② 機能追加・変更点に関するリスト】

有償サービス（Premier サポート）

p.81

Premier Windows 7 → 10 非互換情報提供サービス

Premier では、Windows 7 → 10 非互換情報提供サービスにて、7 → 10

への非互換情報を一覧化したリストもご提供が可能

前述の “WaaS 非互換情報提供サービス” は、Windows 10 以降後の 10

→ 10 での差分情報を提供するもの

初回の Windows 10 への移行時に非互換情報リストが必要な場合は、こちらを利用するとよい

7 8 8.1 10（TH1） 10（TH2） 10（RS1） 10（RS2） 10（???）

機能追加・変更情報

主に Windows Insider blog にて差分情報を提供主に Windows Compatibility

Cookbook にて差分情報を提供

① 初回の Windows 10 への移行 ② WaaS による継続的更新

Windows and Windows Server compatibility cookbook

https://msdn.microsoft.com/en-us/library/windows/desktop/hh848074.aspx

p.82

（重要）弊社から提供される非互換情報について

注意：弊社から提供される全ての非互換情報は、完全・網羅的な情報ではない

「何を機能追加・変更とみなすのか？」に関しては、ある程度、人間の恣意的な判断が入ることが原理的に避けられないため

あらゆる修正は、たとえ API 外部仕様が一致していても、機能変更であるとも言える

すなわち、あらゆる修正には、必ずデグレードのリスクがある

かといって、あらゆる修正を機能変更であるとみなすと、リストが膨大になり、突合せ確認を行うことが不可能になってしまう

例） Windows OS の場合、API レベルでは数千～数万件単位の変更がある

このため、各自のアプリに対して「最も実用的なレベル感・粒度感」に整理された非互換情報リストを使うことが必要になる

マイクロソフト公式サイトからの情報提供も、Premier 非互換情報提供サービスも、実用的なレベル感を意識して作られているが、完全・網羅的なものではない

このため、マイクロソフトから提供される非互換情報を元に確認すれば、非互換問題をすべて回避できるというものではない

どのような非互換情報を使う場合でも、見逃しリスクへの対応の併用が必要

このために、リング配信を必ず併用する必要がある

機能追加

機能変更

修正（バグ、脆弱性、

信頼性など）

全く変わっていない

Windows 10

Windows 10

機能変更に近い比較的大きな修正

極めて軽微な修正機能アップグレード

互換性リスク高

互換性リスク低

この境界線は原理的にグレー

まとめ

p.84

まとめ

エンタープライズ企業における Windows 10 の導入では、その後の WaaS 適用を見越した対応を行うことが重要である

Windows 10 の導入＝継続的にアップグレードされ続ける環境への移行

このため、WaaS での継続的な機能アップグレードの仕組みを理解するとともに、過去のやり方を見直し、効率的な保守・運用ができる仕組みを整えることが重要になる

【Windows 10 導入時の検討の流れ】

• アプリ対応で考えるべきこと• インフラ対応で考えるべきこと

【アプリ互換性検証の要点】

• アプリ互換性の基本的な考え方• アプリ互換性検証の効率化の手法• 大企業における開発近代化の必要性

【インフラ対応の要点】

• セキュリティ• マスタイメージ管理• FU/SU 配信方式

【変更ログの入手方法】

• 代表的な Web サイト• プレミアサポートサービスによる情報提供

【Windows 10 導入の目的】

• セキュリティ• マルチデバイス活用（UWP）• モバイルワークスタイル

【WaaS の正しい理解】

• IP/CB/CBB/LTSB の使い分け• Win10 バージョン間の移行方針• 混在を前提とするインフラへの移行

p.85

利用条件：

• 本書に関するすべての権利は、Microsoft Corporationおよびその関連会社（以下、マイクロソフト）が保有しています。本書は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点での情報となります。

• 状況等の変化により、内容は変更される場合があります。マイクロソフトによる事前の承諾がない限り、本書の全部または一部を複製、改変、翻案、再頒布、公衆送信、貸与、譲渡したり、第三者に開示または共有することは、認められません。

• マイクロソフトは、本書の内容について何ら保証するものではなく、本書の使用に関連してお客様、お客様の関連会社、または第三者に生ずる間接的、付随的、結果的な損害（営業機会や営業情報の損失などを含む）について一切責任を負いません。

• 本書の中で例として使用されている企業、名前およびデータは、特に記述がない限り、架空のものです。

© 2016 Microsoft Corporation. All rights reserved.

windows 10 導入と waas...

Documents