令和6年の今、IE対応を求められた時に気を付けること5選

tanaka.h

3週間前

1. はじめに

こんにちは。田中（博）です。お久しぶりになってしまいました。酷暑がニュースになり続けていたこの一年もあっという間に過ぎ、師走が目前です。能登半島の大震災からスタートした激動の2024年、皆様はどのように過ごされましたか？

令和6年に感じるIEの息吹

久しぶりの記事はサポート終了から2年経過したレガシーブラウザ、Internet Explorer（以下IE）についてです。このたび、今どき滅多に見られないIE11対応要件のあるWebアプリの開発に携わる機会を幸運にも得られました。

2024年現在、ChromeやEdge、SafariといったモダンブラウザがWebブラウジングにおいてデファクトスタンダードとなっていますが、一部のオフィス環境ではInternet Explorerが現役で稼働し続けています。

私が参画したプロジェクトではフロントエンドフレームワークにAngular、バックエンドフレームワークにNestJSを採用することとなり、その過程でEdge＋IE対応に携わりました。本記事はその経験から得られた知見のまとめです。

結論として、現代のIE対応において最も重要なのは、「諦めどころ」を見極めることだと感じています。モダンブラウザの進化は留まることを知らず、その最新機能に支えられた挙動とIEの挙動を完全に一致させることは、もはや不可能です。

2. 2024年の今、IE対応するときに気を付けたいこと

注意点1：CSSは基本的に破綻する

IEでもモダンブラウザと同じ見た目にしたい、してほしい、という欲求は自然に発生するものかと思います。しかし、端的に言ってこれは諦めたほうがよいことの一つです。

そもそもとして、同じIE間ですらバージョンによって動作・対応状況が異なるという問題があります。インターネットを検索したり生成AIに尋ねたりすればIE対応についてのヒントを得られますが、それが「どのバージョンを前提としているのか」という点は常に意識しながら調査を進める必要があります。例えば、IE9では有効だが、IE10とIE11では無効である、というプロパティもあります。実際に遭遇したものとしてはfilterがあります。私が調べた限りでは、IE10～11ではfilterの代替となる迂回策は存在しないようでした。（もし知っている方はこっそり教えてください）

他にも、利用頻度が高いプロパティであるpaddingも挙動が異なります。こんな基本的なプロパティでもIEではレイアウト崩れの引き金になるケースがあります。モダンブラウザとIEでbox-sizingの解釈が異なるためです。

さらに、display:flexのgapプロパティはIEでは完全に無視されます。対策として、子要素に対してmargin-rightやmargin-bottomを指定する必要があります。

例えば、

.container > *:not(:last-child) {
 margin-right: 16px;
}

のように指定が代わりになります。

また、CSS変数（var()）もIEでは使用できません。つまり、CSSだけではカスタムテーマの切り替えが事実上できません。 SCSSの変数を使用してコンパイルする方法で代替する事も可能ですが、開発が進んでからSCSSを入れようとするとコンポーネント間の一貫性を維持するのが大変になります。私に関してはカスタムテーマの切り替えは断念しました。仮にテーマの切り替えをIE11で実現する場合、設計の段階で調査と戦略の決定が必要かと思います。

注意点2：JavaScriptはPolyfillで対応、それでも完璧には動かない

JavaScriptのモダンな機能を使用する際、トランスパイラを利用するか、外部ライブラリとして公開されているPolyfillを利用することになります。

一見、「ライブラリでどうにかなるならそこまで負担にならないのでは？」と思われるかもしれません。しかし、これも気を付けるべき点が多々あります。

Polyfill対応はカロリーが高い

まず、どのバージョンのECMAScriptに対応すればトランスパイラで解決可能なのかを調べる必要があります。フロントエンドの経験が少ないメンバーが中心に対応している場合は大きな負担に繋がります。

もし調査の時間が十分に取れず、後から部分的に外部ライブラリのPolyfillに頼る場合、今度はセキュリティの懸念（サプライチェーン攻撃等）が付きまといます。一番手軽なのは公開されている外部CDNによる導入ですが、外部CDNは性質上セキュリティリスクのあるソリューションです。それに加えてIEが現役で駆動しているセキュリティ上脆弱な環境で外部CDNを使ってPolyfillを導入するのは、忌憚なく言えば紐なしバンジーレベルの暴挙と表現して差し支えないかと思います。（いらっしゃらないとは思いますが）もしCDNによるPolyfillの導入を検討している方がいたら、違う手段の検討を非常に強くお勧めします。

悪意ある企業にPolyfillのCDNが乗っ取られてサイバー攻撃が発生したという報道も現実として存在しています。

CDNを使わない場合でも、外部ライブラリの導入は慎重な検討が必要です。 IEを使用している環境は往々にしてセキュリティ要件が厳しく、新規ライブラリの導入がセキュリティポリシーに抵触する可能性もあるためです。

セキュリティ上の問題をクリアにしながらPolyfillで対応しようとすると、ライブラリのコードの調査やスクラッチでの開発が必要になります。これもまた小さくないコストに繋がります。（今回のプロジェクトでは極力最低限のみPolyfillを導入するようにし、導入する際は外部ライブラリは使用せず、スクラッチで作成することにしました）

したがって、プロジェクト開始時点で「どのPolyfillを導入し、どの機能を諦めるか」を明確に決定するのが結果的に早道になります。これは技術的な判断というより、プロジェクトマネジメント上求められる意思決定です。

ここまでして対応しても、想定通りに動くとは限らない

特に注意すべきなのが、アニメーションの実装です。モダンブラウザで実装したアニメーションをIEで動作させようとすると、予期せぬ問題が発生します。例えば、RequestAnimationFrameの動作が異なるため、スムーズなアニメーションの実現は困難です。

他にもバグなのか仕様なのか判断が難しい違いが存在するため、細部のクオリティを追及しようとすると泥沼にハマります。

注意点3：フォントはあきらめる

フォントの制御もIEにおいては困難が伴う要素の一つです。まず、CSSプロパティであるfont-variation-settingsが効きません。

フォントそのものの制御が難しくなる問題もありますが、これによって、Material IconsやFont Awesomeなどのアイコンフォントが制御できないという問題が発生します。これらは昨今のWebデザインにおいては非常に依存度の大きい存在となっていますが、IEでは扱いが難しくなります。部分的にアイコンのFILLを変更するなどの操作はできないため、戦略を考える必要があります。

注意点4：開発者ツールもIEオリジナル

実際に開発に進んでから直面することになりがちな事実ですが、IEは開発者ツールも独自の進化を遂げています。

例えば、モダンブラウザで当たり前のように使用できる以下の機能も、IEでは利用できないようです。

ネットワークスロットリング
デバイスエミュレーション
メモリプロファイリング
パフォーマンス分析

このため、IEで挙動を確認してからモダンブラウザの開発者ツールで細部を調整するという、2つのブラウザを行き来しながら作業せざるを得ない場面が出てきます。

これは思わぬ確認漏れやテストケース作成時のトラブル（テストケースで実施するように記載した操作がIE上だとできない、等）に繋がります。

予めIEでどのような検証が可能か調査しておくと、後からの手戻りを減らすことができます。

注意点5：ファイルアップロード＆ダウンロードは罠だらけ

ファイルの取り扱いにおいても、IEの場合独自の処理が行われます。例えばCSVファイルのアップロード時にMIMEタイプを何も指定しない場合、モダンブラウザではtext/csvとなりますが、IEでかつExcelをインストールしている環境だとMIMEタイプがapplication/vnd.ms-excelになったりします。私はNestJS側でMIMEタイプのバリデーションを実装していたため、ここでハマることになりました。フロントエンド側でバリデーションを行なった後、アップロード処理を行なうタイミングで明示的にMIMEタイプを上書きしてあげることでこの問題を回避することができます。

const modifiedFile = new File([csvFile], csvFile.name, { type: "text/csv" });

さらに、ファイルダウンロードの実装方法も大きく異なります。モダンブラウザではBlobを使用した実装が一般的ですが、IEではこれが正常に動作しません。

結果として、以下のような冗長な実装が必要になります：

if (isIE) {
    window.navigator.msSaveBlob(blob, filename);
} else {
    const url = window.URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = filename;
    a.click();
    window.URL.revokeObjectURL(url);
}

3. まとめ

IE対応の終着点は…IEを捨てること

ここまで様々な対応方法をご紹介してきましたが、最も重要なのは言うまでもなく「IEを使用せず、IE以外のモダンブラウザを使用すること」です。こういうレガシーなソリューションについて解説している記事では、手法にのみ言及して問題の本質に触れないものも見かけますが、本記事ではIEの利用そのものに大きなリスクがあるという点について改めて強調したいと思います。

サポート切れの製品を使用し続ける本質的なリスク

上記の通り、IE対応は付け焼刃的な対処に終始せざるを得ず、セキュリティ面のリスクも伴います。この不完全な解決策のために投資し続けなくてはならない工数と労力は、新しいブラウザへの移行コストを大きく上回るのではないでしょうか。

特に深刻なのはセキュリティの問題です。サポートが終了したブラウザの使用は、昨今、日本国内でも被害報告数が右肩上がりに上昇しているサイバー攻撃に対してあまりにも無防備です。閉域網で使用している場合でも、人間が触れる以上リスクはゼロにはなりません。ゼロトラストなどのセキュリティの概念が登場していることからもわかる通り、攻撃者が外部にのみ存在するとは限らないためです。

サイバー攻撃によって多大な被害が発生したというニュースが日々流れています。 IEに限らず、サポート終了を迎えたソフトウェア製品に依存し続けているのは、「技術的負債」といった表面的な言葉では片づけられない、より深刻なレピュテーションリスクを孕みます。

「ウチは体質が古いよね～」というようなあるある話やトホホ話で終わらせるのではなく、抜本的な対策が取れないか考えるきっかけにしていただければ幸いです。