12年強もの長い期間に渡り利用されたWindows XPも、2014年4月9日をもって延長サポートを終了しEOLです。しかし世間では依然として、騒ぎが落ち着かないようですね。
アップグレード問題は、本ブログでもかなり取り扱ってきたネタですが、もう十分に情報が揃ってきたように思えます。ここで一旦整理して、Webシステムにターゲットを絞ったレガシー資産の維持方法・対策について、その全体像を眺めてみましょう。
1. アップグレード先のWindowsのバージョンについて
まずは、アップグレード先のOSについてです。
バージョンごとに強い癖を持つIE8以下向けに開発されたWebシステムであっても、大きな改修を行うこと無く移行する方法を、IEは機能として提供しています。「ドキュメントモード」です。これまではアップグレード先がWindowsであれば、その上で動作するIEが必ず持っている機能であり、レガシーWebシステム維持には必須の要件でした。
(※参考 : ドキュメント互換性の定義 - Microsoft )
しかし、Windows 8.1上のIE11は、ドキュメントモードが非推奨化されました。そして、Windows 8はサービスパックサポートという扱いになり、8.1リリース後24ヶ月でEOLを迎えることになりました。これら2点の課題から、理論上、移行先のOSはWindows7に限定されてしまっていることが理解できるでしょう。
(※参考 : ドキュメント モードの非推奨 - Microsoft )
IE11の思い切った仕様変更は歓迎されるべきものです。ただ、その流れに追い付くにも、多くの資産を持ちすぎて、短期間での対策が困難という悩みもあるかと思います。本記事では現実を見て、Windows 7への移行を前提にその方法について整理します。
2. Webシステム移行の長期的戦略
Windows XP上で動作するIE6/7/8は、同じHTML/JS/CSSであっても、バージョンごとに異なる仕様として動作することをMicrosoft側が暗に認めているブラウザです。このため、Windows 7上で動作するIE8/9/10には、過去のIEの動作をエミュレートすることができる「ドキュメントモード」を利用します。レガシーWebシステムは、この機能を利用して動作させます。
エンタープライズの場合、恐らくWindows XP以前のOSで動いていたWebシステムも存在するでしょう。場合によっては、開発の方法に問題があり、IE5の動作を再現させる「Quirksモード」という動作が有効になったWebシステムが含まれているかもしれません。これらも全て、Windows 7のIEではドキュメントモードによってエミュレートさせてしまいます。
全体像としては、以下の通りです。
ドキュメントモード利用時は、Windows XPの各IEごとのコンテンツは、上記の図で対応されるバージョンのモードへ移行させます。IE6モードは機能として提供されていませんが、IE7がほぼ同じ機能を持つため、IE6のWebシステムはIE7モード側へ倒すのが一般的です。動かない場合は、Quirksに落とすと動く可能性があります。このあたりは、テスト次第でしょう。
ドキュメントモードは寿命が決まった対策です。一気に改修し、Windows8まで上げてしまうのがコストメリットとして優れていることは、上記の図を見れば明白でしょう。ドキュメントモードは、あくまで「短期的なコストメリットの優先」という選択です。しかし多くの場合は、この選択を行わざる得ない状況に追い込まれているように思えます。
OSの寿命にWebシステムが引っ張られる問題については、以下のページでも取り上げています。
＞＞ IE8以下向けのWebシステムのEOLは、2020年より後になってはいけない
3. アップグレード先のIEのバージョン・ブラウザ
次に、アップグレード先OS上で動作させるブラウザの話です。
IEをアップグレードして継続利用する場合は、対象バージョンは9か10を選択するのが一般的のようです。早い時期にアップグレードを行っている場合、8という選択もあったようです。IEの持つ機能性から考えると、「IE10」が妥当な選択になります。では、その根拠について確認してみましょう。
8はまだ、相互運用性が確保されていないブラウザです。IE8向けにWebシステムを作ってしまった場合、Windows 7から8以上へのWebシステムの移行が行えなくなってしまいます。業務システムのような長いライフサイクルを支えることができないため、選択されることは100%ありえません。
(※参考 : IE8向けに開発するWebシステムのEOLの制約 - ふろしき.js)
11は、ドキュメントモードが非推奨であるため移行が困難になります。ただし、Windows 8系へ移行する場合、IE10は2015年の中旬にEOLを迎えるため、実質的にIE11しか選択できません。IE11への移行は、Windows 7時代にWindows XP以前のWebシステムの改修を行ってからになるでしょう。
(※参考 : 意外と知られていない、IE11リリースによる本当の危機 - ふろしき.js )
9も多いですが、Visual Studio 2013からIE10が必須になったため、今後開発されるWebシステムに制約を作ってしまうことになります。FlexやSilverLightのようなプラグインを利用したアプリを作ることも今後は困難になりますが、IE10はこれをある程度克服できる機能性を兼ね備えています。業務系だと多い、パフォーマンスの評価を行うための機能もこのバージョンから多くサポートされています。このため、IE10へ移行するのが妥当な選択になります。
(※参考 : Visual Studio 2013 は何が違うのか？ - ふろしき.js )
それでも、あえて9を選択する理由があるとすれば、Quirksモードの仕様変更問題に対するリスクヘッジが挙げられるのではないでしょうか。
(※参考 : IE6〜9とIE10とでQuirksモードの動作が違う - ふろしき.js )
IEのバージョンごとの違いは、以下のページにまとめています。
＞＞ IEのバージョンごとの機能の違い、選定の目安 - ふろしき.js
なお、レガシーWeb資産の維持については、Google Chromeでもエクステンション「LBS(Legacy Browser Support)」として提供されています。内部的にはIEと共通のレンダリングエンジンを使うような動きに見えますので、当然ですがMac版では動きません。Windows限定になりますが、視野にいれておくと選択の幅が広がり、より深い検討に結びつくかもしれません。
＞＞ レガシー ブラウザ サポート - Google
4. 移行に利用する具体的な技術
ここでは、3章でIEのアップグレードを選択した場合を想定し、どのような方法で実装するか整理します。IEのアップグレード後、IEに対してドキュメントモードが有効に機能するよう設定を行う必要がありますが、その方法はおおよそ、以下4つの中から選択できます。
★ 作戦１：Active Directory設定型
運用するクライアント端末が全てActive Directoryの制御下に置かれている場合、Active Directoryの設定により一括で実施することができます。Active Directoryを利用する場合、イントラネットを認識するように設定し、イントラネット環境下に置かれたサーバを全てイントラネット互換表示という状態で動作させるようにします。
戦略としては、以下2点です。
- プロキシを介さないアクセスを全てイントラネットと認識させる。
- イントラネットとして扱うURLを直接指定する
前者は設定が非常にシンプルですが、新規に開発され追加されるWebシステムへの影響が心配されます。例えば、IE9向けに開発したシステムが、いざ本番環境で動かすと、IE7モードとして動いてしまったというというミスを犯すリスクがあります。新規システムは、ホワイトリスト的にドキュメントモードを明示しなくてはいけないため、煩雑になります。
後者はそのリスクが小さくなる反面、全WebシステムのURLをブラックリストへ登録しなくてはいけなくなります。ただ、イントラネットとインターネットとではセキュリティレベルが異なるため、内部のサーバをインターネットと認識させるのは、他のグループポリシへの影響も心配されます。
正攻法では、前者を選択すべきなのでしょう。この場合、Windows 7時代、全ての新規開発Webシステムは、Edgeモードで動作するようにルール化する必要があります。
★ 作戦２：サーバ完結型
個々のシステムのサーバに対して、X-UA-Compatibleを設定するという方法です。設定は、ApacheかIISか、或いはTomcatか、何をWebサーバにしているかで異なる手段を講じる必要があります。手間がかかります。
ただ、この方法の良い所は、システムごとにしかドキュメントモードの設定を行わないため、新しくWebシステムが開発されても、そこに影響を及ぼすことがありません。責任分界点がはっきりとしており、複数のベンダにより運用されている動作環境下では、効果が高いように思えます。
＞＞ IE9のX-UA-Compatibleの使い方/動作仕様 - ふろしき.js
＞＞ IE10のX-UA-Compatibleの使い方/動作仕様 - ふろしき.js
★ 作戦３：設定ファイル配布型
IEの設定情報を配布するIEAKというツールを使う方法です。
「イントラネット互換表示」や「互換表示リスト」を活用してチューニングされた状態のIEを、クライアント側へインストールさせるという方法になります。強制力が低いため、ユーザに容易に変更されるというリスクを持ち、作戦１〜２ほど細かいドキュメントモードの制御が行えないという問題も持ちます。
作戦３〜４にかけての問題点は、IE8〜10で「互換表示ボタン」がアドレスバーの右に表示されてしまうことです。ユーザで自由にドキュメントモードが変更できてしまうため、トラブルに繋がりやすいという印象を受けます。
＞＞ IE9の互換表示リスト(互換表示一覧)の使い方/動作仕様 - ふろしき.js
＞＞ IE10の互換表示リスト(互換表示一覧)の使い方/動作仕様 - ふろしき.js
＞＞ Internet Explorer 管理者キット 技術情報とダウンロード - Microsoft
★ 作戦４：ユーザ手動型
作戦３の手順を、ユーザの手で逐次行うという方法です。互換表示リストは、「互換表示ボタン」で代替します。
オペレーターへの負荷が非常に高く、また強制力も低いため、トラブルに繋がる可能性が非常に高いです。
＞＞ IE9の互換表示ボタンの使い方/動作仕様 - ふろしき.js
＞＞ IE10の互換表示ボタンの使い方/動作仕様 - ふろしき.js
▼ 注意点１：DOCTYPEスイッチの誤作動
IE6のDOCTYPEスイッチには問題があり、XHTML1.0で動作するものについては、解釈に失敗し誤作動を起こす可能性があります。この問題へ対応するには、サーバ側でのX-UA-Compatibleの指定が有効です。X-UA-Compatibleは、他のドキュメントモード設定手段よりも優先されます。
▼ 注意点２：IE7モードで動作しないIE6向けシステム
IE7モードは、IE6と完全な互換性を持つわけではありません。IE7でも、サポートされなくなった項目があります。この場合、Quirksモードに倒した方が良い場合もあります。対策としては、注意点１と同様、X-UA-Compatibleにより強制でIE5を指定することが求められます。
(※参考 : Information Index for Internet Explorer 7 - Microsoft )
5. Webシステム移行前の動作テスト
大前提ですが、ドキュメントモードは過信しないで下さい。テストは絶対に必要です。
動作テストについては、実機がベストです。ただ、コストの問題から全てを実機でとはいかないケースもあるでしょう。単純に動作のチェックを行いたいだけであれば、Microsoftが提供しているModern.IEというサービスを利用するという手もあります。Modern.IEでは、無償で利用できるOS+IE(バージョン)の組み合わせを取り揃えた、「Modern.IE VM」というサービスが提供されています。
動作テストを行うという目的であれば、ライセンスに合致し無償のVMを利用した動作検証が行えます。
＞＞ 無料でIEのマルチバージョンテスト「Modern.IE」開発での利用時の注意点
テストの自体の注意点があるとすれば、以下が挙げられます。
★ Active Directoryとの連携のテスト
Windows XPからの移行では、ドキュメントモードの有効化にActive Directoryの利用を行う場合も多いでしょう。この場合、Modern.IE VM単独でのテストは難しいため、別途動作テストの環境を構築することも視野に入れる必要があります。ドキュメントモードそのものの動作自体はVMで十分ですが、ドキュメントモード自体が正しく有効化するかまでは、Active Directoryを利用するまではテストされないのです。
★ ドキュメントモードの指定値の確認
ドキュメントモードは、IEのバージョンアップが進む都度複雑化が進んでいます。例えば、IE10からはQuirksモードが2種類になったり、ドキュメントモードが非推奨化されたIE11では、この2種類のQuirksモードのどちらが利用されているかをシンプルに把握する術は失われています。
(※参考 : IE10のQuirksモードについて - ふろしき.js )
(※参考 : IE11のQuirksモードについて - ふろしき.js )
基本は「F12開発者ツール」を利用し確認することになりますが、開発者ツールを常時動かしていると、何かしらの要因で設定情報をキャッシュし、ドキュメントモードが誤作動を起こすことがあります。筆者も、IE9で結構ハマってます。何がきっかけで正常な動作に戻ったのか、その再現性を確認することができませんでした。注意が必要です。
★ OSの違いによる動作の差異
例えば、アップグレード先がIE8だとしても、Windows XP版のIE8とWindows 7版のIE8とでは、OSレイヤーの機能の差異により、必ずしも同じ動作になるとは限りません。IE11にしても、Windows 7、Windows 8.1(デスクトップモード)、Windows 8.1(Windows 8モード)で異なります。
レイアウトをガチガチに決めてしまっている場合、以下の様な事象も発生します。
最後に
アップグレードの実態としては、FlexやSilverLight、Javaアプレットなど、プラグインが邪魔してここまでスムーズにはいかないことも多いでしょう。HTMLベースなシンプルなものは、今回整理した内容が正攻法になるかと思います。
Windows 7のアップグレードが終わったとしても、バージョン問題との本格的な戦いはこれからです。Web開発で、従来の方法を守り続けると、次のアップグレードでは今回の比にならないコストを発生させることになります。提案力、開発プロセスの設計力が試されています。
「Web技術はプラットフォームによって動作が違う！」とは言われていますが、IE、Firefox、Chromeとで、相互運用性は改善に向かっています。これを前提として、Windows XPの時代を支えたIEも、方針をシフトし、以前の方法を許すような手段を潰す流れに入っています。
Windows 7世代のWebシステム開発で行うべき対策については、今後以下のページで扱っていく予定です。
＞＞ HTML5/IE11対応 - Webシステム・ガイドライン集
本記事をきっかけとして、Windows XPアップグレード問題をうまく解決し、クライアントの健全な運用に貢献できたなら、情報整理を行ってきた私としても幸せです。フィードバックがあれば、恐れ入りますがTwitter(@kawada_hiroshi)でご報告下さい。メールでも受け付けています。
それでは、健闘を祈ります。
