Part 3. WaaS の正しい理解


さて、ここからいよいよ本題である WaaS の解説に移っていきます。

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

ここまで解説したきたように、「Windows 10 の導入」とは、「継続的にアップグレードされ続ける環境への移行」でもあります。このため、Windows 10 の導入に際しては、『導入後にどのようになるのか?』を理解・検討しておくことが極めて重要です。まずは、Windows 10 移行後の、WaaS による継続的更新(機能追加)の仕組みについて理解しましょう。

image

[4 つの OS 更新モデル(IP, CB, CBB, LTSB)]

ご存じのように、Windows には Home, Enterprise, Pro などの「エディション」という分類が存在しますが、これとは別にもう一つ重要な分類として、「機能追加の受け取りタイミング」という選択肢が存在します。例えばこれまで、Windows 10 は November Update、Anniversary Update という機能追加が実施されているのですが、この機能追加をいつのタイミングで受け取るのかを調整することができるようになっています。具体的には、以下の 4 つの選択肢があります。この 4 つの選択肢については(名称も含めて)暗記してください。

名称 この資料での略称 概要 主な利用者
Insider Preview IP 機能追加の受け取り時期を早める 一部の早期利用ユーザ
Current Branch CB 4~8 ヶ月間隔で OS の機能追加を行う 一般のコンシューマユーザ
Current Branch for Business CBB 機能追加の受け取り時期を 4 ヶ月間 遅らせる 一般的なビジネスユーザ
Long-term Servicing Branch LTSB 機能追加を一切受け取らない 特定用途の固定端末

これらの考え方ですが、CB を基準にして考えると非常にわかりやすいです。

  • CB : コンシューマユーザには、約 4~8 ヵ月の間隔で、OS の機能追加が行われる
  • IP, CBB : 機能追加の受け取り時期を、ある程度、早める or 遅らせることができる
  • LTSB : 特定用途の端末向けに、機能追加を一切受け取らない方式も提供される

企業内では、用途に応じてこの 4 つの選択肢を使い分ける必要があります。すなわち、以下のようになります。

  • 一般的なビジネスユーザ(大多数の従業員)は CBB を利用することで、コンシューマ市場で「4 ヶ月間揉まれて安定性を高めた」 Windows OS を利用することができる。
  • パワーユーザーは、CB や IP を利用することで、早い段階で OS の最新機能を使ったり試したりすることができる。
  • 一方で、特定用途の固定端末では、LTSB を使うことで、「ずっと変わらない Windows」を使うことができる。

 

image

なお、LTSB に関しては一般的な OA 端末での利用を想定していないため、利用に際しては十分な注意が必要です。このため、LTSB に関しては IP/CB/CBB とは分けてこのエントリの後ろの方で詳しく解説します。

上に示した IP/CB/CBB の違いをより詳しく理解するために、ここまでの Windows OS のリリースの流れを見てみると、次のようになります。

image

要点は以下の通りです。

  • まずは CB のリリースの流れに着目すると理解しやすい
    • 従来のサービスパックに相当する「機能アップグレード」が 4~8 ヶ月おきに登場
      • 当初想定では 4 ヶ月おきだったが、実際には約半年に 1 回程度のペースで機能アップグレードが行われている
      • この「機能アップグレード」により、機能の追加・改善が行われる(例:Cortana など)
  • これに対して、IP を利用すると、開発中の β 版を先行して利用できる
  • 逆に CBB を利用すると、 4 ヶ月間コンシューマ市場で揉まれた後の、より安定化した OS を利用することができる

すなわち、CBB = CB + 4 ヶ月分の累積パッチ、であり、CB/CBB の機能的差異はありません。ここは非常に重要なポイントなので、必ず押さえておいてください。

※ また、上記の各機能アップグレードのコード名とバージョン番号/ビルド番号についても覚えておくとよいでしょう。マイクロソフトの資料では、これらの名称がよく出てくるためです。

  • 無印(初回リリース):TH1, 1507, 10240
  • November Update : TH2, 1511, 10586
  • Anniversay Update : RS1, 1607, 14393

[IP/CB/CBB の切り替え方法]

上で述べたように、IP/CB/CBB の違いは、機能アップグレードの受け取りタイミングの違いにあります。IP/CB/CBB は、OS の設定オプションから切り替えることができます(※ GUI 以外からの設定方法(例えばグループポリシーや MDM による変更など)についてはこちらを参照してください)。

image

また、Insider Preview に関しては、受け取り頻度を Fast/Microsoft/Slow などの中から選択することができるようになっています。Insider Preview は開発中の中間ビルドを受け取るオプションであり、場合によっては極めて不安定なビルドを受け取ってしまうことがあるためです。中間ビルドを受け取るときでも、ある程度安定したもののみを受け取りたい場合には、Slow などを選択していただけるとよい、ということになります。(ちなみに最も展開が早いビルドはカナリアビルドと言われていますが、これはさすがにマイクロソフト社内の R&D 内部のみでしか入手することができません。私も受け取れません;。)

image image

ここは重要なポイントですが、Windows 10 では、ビジネスユーザーが受け取る OS(すなわち CBB)がなるべく安定したものになるよう、OS の利用者を段階的に増やしていっている、という形になっています。ある意味、Insider Preview の参加者は一般コンシューマユーザに対する人柱であり、そして一般コンシューマユーザはビジネスユーザの人柱である、という構図が読み取れるわけですが;、このように、段階的な展開の仕組みを使うことで、最終的に安定したものを大多数のユーザーに届けられるようにする配信方式の考え方を、リング配信(Ringed Deployment)と呼びます。このリング配信の考え方は、アプリ互換性検証においても極めて重要なポイントになるため、しっかり理解しておいてください。

[IP/CB/CBB/LTSB と Home/Enterprise/Pro/Ent-LTSB の関係]

さて、ここまで機能アップグレードの受け取りタイミングについて解説してきましたが、OS のエディション(Home/Enterprise/Pro)により、利用できる受け取りタイミングオプションが異なります。具体的には下図の通りです。

image

ポイントは以下の通りです。

  • Home エディションでは CBB は使えない(=機能アップグレードの受け取りタイミングを遅らせることはできない)。
    • 理由は……上に書いた話から察してくださいw。
  • LTSB は特殊なエディションのため、異なるインストールメディアが必要になる。
    • Home/Enteprise/Pro のオプション変更では、LTSB にすることはできません。LTSB を使いたい場合には、Enterprise-LTSB と呼ばれる特殊なインストールメディアが必要です。
    • 例えば下図は MSDN サブスクライバダウンロードの画面ですが、この中の “Windows 10 Enterprise 2015 LTSB” と書かれているものが Enterprise-LTSB エディションに該当します。
      image

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

次に、企業内ではどのタイミングでどのように OS をアップグレードしていくべきなのか、という点について考えてみます。下図は現在までの Windows 10 の機能アップグレードのリリースタイミングを示したものです。

image

まずはこの図の要点をいくつか説明します。

  • 機能追加・機能変更は、Insider Preview の期間中(図中の “Evaluate” の期間中)しか行われない。
    • 一度 CB がリリースされると、以降は脆弱性・信頼性などの修正(パッチ)しか出ない。
    • このため、CB/CBB 間には機能的差異はない
  • CB リリース後、4 ヶ月後にそれが CBB 扱いとなる。
    • 名目上の取り扱いが変わるだけなので、インストールメディアなどが入れ替えになるわけではない。
    • ただし、インストールの手間を容易化するため、CBB 扱いになったタイミングで、累積パッチを取り込んだメディアが再作成されて提供されている。
    • (TH1 だけは初回リリースが CB 兼 CBB となっているが、これは例外的取り扱い)
  • 各機能アップグレード(TH1, TH2, RS1, RS2,…)に対するパッチ提供は、n+2 バージョンの CBB がリリースされるまで行われる
    • よって、どんなに遅くても n+2 バージョンの CBB がリリースされるまでに(脆弱性パッチが提供されなくなるので)アップグレードを行う必要がある。

さて、実際の企業内システムの場合に問題になるのは、CBB リリース後のいつのタイミングで新しい CBB にアップグレードするのか、です。例えば、業務アプリの互換性検証が終わっていない場合や一部のサードパーティ製アプリが新しい CBB のサポート表明をしていない場合、たとえ新しい CBB がリリースされてもアップグレードができないということが起こりえます。このため、グループポリシーを使うことで、通常は CB リリースから 4 ヶ月後とする機能アップグレードの適用を、さらに遅らせることができるようになっています

ただし(ここめちゃめちゃ重要です)注意していただきたいこととして、上記の機能アップグレードの適用遅延機能は、CBB の 1 バージョンスキップを認めるものではない(=必ずすべての CBB を順次適用していく必要がある)、ということを理解しておく必要があります。

  • 先に述べたように、各機能アップグレード(TH1, TH2, RS1, RS2,…)に対するパッチ提供は、n+2 バージョンの CBB がリリースされるまで行われます。
    • 例えば TH1 へのパッチ提供は、RS1 の CBB リリースと共に打ち切られることになります。
  • このことに関連して、パッチ提供期間を少し(60 日間)だけ延長する、という話があるのですが、仮にパッチ提供期間が延長されたとしても、CBB を 1 バージョンスキップする、という考え方は避けるべきです
    • 例えば下図のように n+2 バージョンの CBB がリリースされたら速やかに 1 バージョンスキップして機能アップグレードを適用する、という考え方を採るのは非現実的です。
    • image
    • もともとこの “60日間延長” は、パッチ提供期間を少しだけ伸ばしてもらうことで、CBB を 1 バージョンスキップして業務アプリの互換性テストを年 2 回程度から年 1 回程度に減らしたい、というお客様の要望から来ています。
    • しかしその一方で、上図のようにアップグレードを行おうとした場合、n+2 の CB リリース後、6 ヶ月以内に業務アプリや ISV アプリの対応を完全に済ませ、社内すべての OS を完全にアップグレードする必要があります。しかしこれはどう考えても極めてリスクが高く、現実的ではありません。 (特に ISV アプリのような、社外アプリの対応が間に合わないリスクがあります)
    • このため、n+1 の CBB リリースから n+2 の CBB リリース + 60 日間が、機能アップグレードの適用猶予期間である、と考えて、ひとつずつ CBB のアップグレードを繰り返していく必要があります。
    • image

というわけで、企業内における機能アップグレードの適用タイミングの考え方の基本について説明しましたが、実際のアップグレードタイミングについては業務アプリの互換性検証と強くかかわる部分がありますので、それについては Part 6 にて解説します。

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

さて、ここまで Windows 10 の機能アップグレード(November Update や Anniversary Update)について解説してきましたが、Windows 10 に対して行われる「更新」について、ここで整理しておきたいと思います。Windows 10 では、3 種類の「更新」が行われており、それぞれ名称が異なります。これらについては名称をしっかり覚えておいてください

  • ① 機能アップグレード(Feature Upgrades)
    • 従来のサービスパックに相当するもの。
    • スタートメニュー、設定画面、Cortana、Edge ブラウザなどの機能追加・変更が含まれる。
    • CB としてリリースれさる前に先行検証したい場合には、Insider Program に参加する。
  • ➁ サービス更新プログラム(Servicing Updates)(または 品質更新プログラム(Quality Updates/QU))
    • 従来の更新プログラムに相当するもの。
    • 脆弱性修正(セキュリティパッチ)が中心で、信頼性やバグに関する修正も含まれる。
    • 以下の 2 点に注意する。
      • OS Edge ブラウザに対する機能追加・変更は含まれない。
      • 従来と異なり、必ず累積パッチとして提供される(個別の適用はできない)
    • 配布前に先行検証したい場合には、SUVP(Security Update Validation Program)に参加する。
  • ③ ストアアプリの更新の配信
    • メールやカレンダアプリの更新は、①➁とは別に、Windows ストア経由で配布される

整理すると、以下のようになります。これを覚えておくとよいでしょう

配信内容 英語表記 簡単に言うと… 備考
① 機能アップグレード Feature Upgrades (FU) サービスパック OS や Edge ブラウザの更新
② サービス更新プログラム Servicing Updates (SU) 累積セキュリティパッチ 通常、毎月第二火曜日に配信
③ ストアアプリの更新の配信 メールやカレンダーアプリの自動更新 ①②とは無関係に配信

ちなみに細かい話で恐縮ですが、”Upgrade” と “Update” という用語が使い分けられていることに注意してください。FU は「アップグレード」、SU は「アップデート」です。(といいつつ、一般的に使われている November Update や Anniversary Update はいずれも FU なのに Update という名称になっているのはどうよ? という感じなんですけどね;、とグチってみる。)

なお、②に関しては RS1 以降は品質更新プログラム(Quality Updates, QU)の名称に変更される予定です。しばらくは SU/QU 両方の表記が出てくると思いますのでご注意ください。(この blog では SU で統一しています)

[LTSB (Long Term Servicing Branch)について]

さて、ここまで IP/CB/CBB を念頭に置いて解説を進めてきましたが、ここで LTSB について整理します。LTSB は、10 年間にわたりパッチのみが提供され続ける、非常に特殊なエディションで、その間、機能追加・変更は行われないというものです。今はまだしも、10 年後には超レガシー端末になるというもので、一般な OA 端末では使うべきではない特殊なエディションです。

もともと LTSB は、例えば製造ラインに据え付けで利用する制御用の PC や、キオスク端末のように特定の業務アプリだけしか動作させない PC での利用を想定しているもので、いわば組み込み用の Windows OS である、と理解するとわかりやすいです。インストールに利用する媒体も通常の Home/Enterprise/Pro とは別のメディアになっており、インストールした際の画面も大きく異なります(ストアもなければ Edge ブラウザもない)。ストアや Edge ブラウザが削られているのは、上記のような「ずっと変わらない端末」での用途を想定していることを念頭におけば当然のことと言えます。

image

LTSB に関しては、頻繁な(半年に一度の)アプリ互換性検証を回避するための魔法の杖であると誤解されているケースが非常に多いのですが、これは全くの誤りです。確かに LTSB を使えば機能追加・変更が行われなくなりますが、それは同時に技術革新が一切行われない、ということでもあります。10 年間同じ OS を使い続けるということは、言ってみれば 2016 年においてもまだ 2007 年にリリースされた Vista を使い続けている、というようなものです。

基本的に、一般社員向けの端末では、CBB を利用することをまず念頭に置いて考えてください。イメージとしては、Office を入れて使うような一般的な OA 端末は CBB を選択するのが基本、と考えるとわかりやすいでしょう。逆に、OS に新しい機能を取り込む必要のない特定用途の固定端末では、LTSB を使うことも検討していただければと思います。

# LTSB に関するこの誤解を誘発しているのはいくつかの原因がありますが、大きくは、① アプリ互換性検証に関して正しい理解や考え方がされていない、② LTSB にも MSI 版の Office がインストールできてしまう、③ LTSB → LTSB のアップグレードがサポートされている、といったところがあります。しかし、繰り返しになりますが、LTSB はそもそも特定用途の固定端末で使うことを想定して作られているエディションである、という点については必ず念頭において考えてください。企業内のユーザのほとんどが LTSB を使って仕事をする、といったシナリオは想定されていません

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

さて、ここまで IP/CB/CBB/LTSB について解説してきたわけですが、最後に見落としやすい、けれども非常に重要なポイントを指摘しておきます。それは、 今後の IT インフラは、複数の OS バージョンが混在することになる、という点です。

従来の IT インフラでは、基本的に、すべての社員が完全に同一の OS を利用することを前提としていたケースも多かったと思います。しかしここまで解説してきたように、Windows 10 WaaS 時代では、端末あるいはユーザごとに、複数の更新モデルを使い分ける必要があります。それは結果的に、複数の機能バージョンの Windows OS が混在する環境を生み出します。

image

ですので、例えば RS1 を使っている A さんが隣の B さんの端末を見たらすでに RS2 を使っていたとか、あるいは部屋の隅に置かれている特定業務端末は LTSB で動いている、といったことが発生します。欧米では BYOD も多く、端末ごとに OS バージョンが違うことも珍しくないらしいのですが、日本の場合にはこうした環境にまだ馴染みがないというケースが多いと思いますので注意していただければと思います。

[New! 2017/05/24 追記]

Creators Update から FU の更新サイクルが 6 ヶ月に固定されました。このエントリでご紹介している基本的な考え方は特に変わりませんが、更新サイクルの図に関しては更新版があった方がわかりやすいため、作成しました。こちらにアップロードしてありますので、上記と併せてご確認・ご利用ください。


Comments (3)

  1. Eiji Nagai says:

    >6 ヶ月以内に業務アプリや ISV アプリの対応を完全に済ませ、社内すべての OS を完全にアップグレードする必要があります。しかしこれはどう考えても極めてリスクが高く、現実的ではありません。
    n+1への2か月ごとの検証のほうが現実的でないように思えますが、どういう理由でしょうか?

    1. XYZR says:

      根本的にOSの機能アップなんか誰も必要としてないってのをそろそろ理解して欲しいです。
      OSは裏でただ安定して動けば良いだけの物です。
      Egdeとかはただのアプリです。アプリの追加変更はOSとは別に扱えるようにすべきです。アプリの為に、OSを変更するのは本末転倒です。
      OSはただ、寡黙に、セキュリティ対策や新ハード対応だけを行えば良い物です。
      という所で、LTSBがとてもいい形のように思えます。企業の業務向けにストアアプリなど一切不要な事は間違いありません。

      1. nakama says:

        Eiji Nagai さん、XYZR さん、コメントありがとうございます。
        すみません、見逃しており返信遅れました。

        > n+1への2か月ごとの検証のほうが現実的でないように思えますが、どういう理由でしょうか?

        アプリ互換検証に関しては、後続のエントリでも触れているように、「全部きっちりと互換性検証を行う」という従来型のアプローチを取り続ける限りは、おっしゃる通り、「n+1 への 2 ヶ月ごとの検証」は非現実的です。
        しかしその一方で、今まで数年単位で行われていた「大規模なOSアップグレード」と同等のアップグレードが半年単位で行われるようになった、というわけでもありません(そこまで開発速度が上がったわけではない)。後続のエントリでも触れているように、

        ・基本的に、IE11 や .NET などのレガシーランタイムには変更は入らない。
        ・OS の FU アップグレードの内容は、設定画面などに入っているので、レガシーアプリの非互換を引き起こすようなものは少ない。

        という実態があり、また加えて言うのであれば、

        ・実際の業務アプリの多くは、OS アップグレード時にフルパス再テストをしているわけでもない。

        ということもあります。このあたりの考え方やアプローチ方法は、後続のエントリでご紹介しておりますので、ご確認いただければと思います。

        > 根本的にOSの機能アップなんか誰も必要としてないってのをそろそろ理解して欲しいです。

        こちらに関しては非常に難しい点だと思います。少し長くなりますが、よく聞かれる話なのでつぶやかせてください。

        「OS の機能アップなんか誰も必要としていない」と言いながら、実際に私も含めた多くのユーザは、コンシューマユースで iPhone や Chrome がガンガンアップデートすることを当たり前とし、さらに iPhone や Chrome などに比べて Windows や IE は時代遅れだと評価する向きがあります。
        また、「OS の機能アップ」というのは目に見える「機能」だけではなく、「セキュリティ強化」も含まれており、より安全・安心なプラットフォームを提供し続けるためには、OS の機能アップはどうしても必要です。
        さらに、例えばアプリ互換性問題から LTSB を使いたいと言いながら、一方では最新のクラウド SaaS サービスを使いたい、最新のパッケージ製品を使いたいとおっしゃる方々も実態として非常に多いです。

        このことに関して、「コンシューマユースとビジネスユースを一緒くたにするな」というご意見があることも理解しているのですが、その一方で歴史が証明するように、IT 業界のトレンドはその多くがコンシューマから来ており、コンシューマ市場で市場を席捲したベンダーがビジネス市場でどんどんシェアを広げていく、という実態があります。このトレンドは IT のコンシューマ化などと呼ばれており、UNIX vs Windows しかり、Intel IA64 vs x64 しかり、IE vs Chrome しかり、様々なところに見られます。より安全で安価で、快適で使いやすいプラットフォームが後から出てくれば、それにどんどん乗り換えていこう、それをビジネスでも活用しよう、という考え方は至極当然です。

        こういう観点で見たとき、ご承知のように OS シェアでは Android, iOS が圧倒的なシェアを取りつつあり、まさに Windows は「倒されるべき過去の巨人」になっています。Microsoft が WaaS で CB/CBB モデルを導入してきたのはこうした背景があります。

        しかしその一方で、「ウチはどれだけレガシーだろうが今まで通りでよい、というより組み込み端末みたいなところで FU が降ってくるなど意味がない」などのお客様がいることも理解しており、そのために LTSB モデルも提供しているわけです。

        私が実際にお客様と接している限り、本当にお客様が求めているのは、「OS としての機能やセキュリティがガンガンよくなっていきながらも、既存アプリに関しては一切非互換問題を起こさない OS」というものです。しかしエンジニアリング(技術観点)から見た場合、そんな魔法の杖は物理的に存在しえません。こうした背景を考えると、WaaS における以下のような指針は確かに理に叶っている、と私は思います(一人のエンジニアとして)。

        ・基本指針として、レガシーランタイム(IE11, .NET)はいじらない。
        ・機能追加は OS とモダンランタイム(Edge, UWP)に対して行う。
        ・FU アップデートが不要なシステム向けに、LTSB という選択肢を提供する。

        考え方が複雑になっていることは確かですし、個々のお客様の個別ニーズを考えるとピタリと当てはまるソリューションにはなっていないとは思います(前述したように「無茶なリクエスト」をおっしゃられているケースも多いので)。また、ベンダー側だけでなくユーザ企業側にも正しく理解していただく必要がある部分も大きいです(ユーザさんからの無茶な要求(完全互換要求)で、ベンダー側が板挟みにあうケースが多いため)。

        こうした部分に関しては、これからも継続的に情報提供していきたい・訴えていきたい部分です。時間はどうしてもかかると思いますが、ご理解とご協力を賜れれば幸いです。

Skip to main content