Outlook アドインを AngularJS から Angular 19 へ移行するとき、最大の不安が Outlook 2016 に残る IE11（Trident）問題です。UA 解析は 0 件なのに Office.js の hostVersion では Outlook 2016 が一定数いる――このズレをどう解釈し、どの方法で検出し、移行後の事故をどう防ぐかを実務目線で整理します。
なぜ「Outlook 2016（IE11/Trident）」が Angular 19 移行で問題になるのか
Outlook アドインは、見た目は「Outlook の中に表示される Web アプリ」ですが、実際にはホスト（Outlook の種類・ビルド・配布形態）によって表示エンジンが変わります。特に組織内で長く使われがちな Outlook 2016 は、環境によって IE11（Trident）系の WebView で動く可能性があり、モダン Web 前提の SPA に移行した瞬間に“表示できない／起動しない”が起こり得ます。
そして Angular は Angular 12 以降で IE11 を公式にサポートしなくなりました。Angular 19 を採用する場合、「IE11 が少しでも残っているなら移行でユーザーが脱落する」リスクが現実になります。
つまり移行判断で重要なのは次の 2 点です。
- 今の利用実態として、アドインが IE11（Trident）で開かれているセッションがあるのか
- 残っているなら、どの程度の割合で、どの部署・どの端末群に偏っているのか
「UA は IE11 0 件」なのに「hostVersion は Outlook 2016 がいる」が噛み合わない理由
結論から言うと、この 2 つの結果は同時に成立することがあります。噛み合わないように見えるのは、見ているものが違うからです。
UA 解析が見ているもの
UA（ユーザーエージェント）解析は、基本的に「その瞬間にアドインが開かれている WebView/ブラウザのエンジン」を推定します。IE11（Trident）なら UA に特徴的な文字列が入り、そこから判定できます。つまり UA は “レンダリングエンジンの現場” に近い情報です。
Office.js の hostVersion が見ているもの
Office.context.mailbox.diagnostics.hostVersion は、「Outlook のホストのバージョン情報」を示します。これは“Outlook の版（クライアント）を把握する”には有効ですが、そこで使われている WebView が必ず Trident なのか、必ず WebView2 なのかまでは確定できません。
ズレが起きる代表パターン
- Outlook 2016 でも WebView が Trident とは限らない
同じ Outlook 2016 でも、更新状況や環境条件によって実際の表示エンジンが変わることがあります。「Outlook 2016 がいる＝必ず IE11」と短絡しないのが安全です。 - UA の計測タイミングが遅く、IE11 だと計測処理まで到達していない
もっとも実務で多い落とし穴です。Angular（あるいは現行アプリ）の初期化後に UA を送っていると、IE11 では初期化がコケてログが飛ばず、結果として「IE11 0 件」に見えます。 - 計測が特定経路だけ漏れている
例えば「閲覧はできているが、計測 API だけがプロキシ/証明書/混在コンテンツで弾かれている」「社内ネットワークからは到達できない」などで、特定の端末群だけ計測が欠落することがあります。 - 同一ユーザーが複数クライアントで Outlook を使っている
デスクトップ Outlook 2016 と Outlook on the web を併用していると、hostVersion は 2016 由来のセッションも出る一方、UA はモダンブラウザ由来に寄ることがあります。ログの集計単位（ユーザー/端末/セッション）次第で見え方が変わります。
ソース・オブ・トゥルースはどれか：結論は「目的で使い分け」
「どちらを真実として扱うべきか」は、目的で決まります。レンダリングエンジンを知りたいのか、Outlook の版を知りたいのかで“真実”が変わるためです。
| 知りたいこと | 最適な情報源 | 理由 | 注意点 |
|---|---|---|---|
| IE11（Trident）で開かれているか | UA（＋ documentMode） | 実際に描画しているエンジンの情報に最も近い | 計測処理はAngular 起動前に行う |
| Outlook 2016 利用者がどれくらいいるか | hostVersion | Outlook のバージョン把握に適する | それだけで Trident とは断定しない |
| 移行影響を受けるユーザー群の特定 | UA と hostVersion を同時に保存 | 「Outlook 2016 × Trident」の実数が取れる | 同一ユーザーの複数端末・複数クライアントに注意 |
この整理に立つと、あなたの状況（UA は IE11 0 件、hostVersion は Outlook 2016 が一定数）に対して、実務でまずやるべきことが明確になります。
- UA の計測が確実に IE11 でも送れる実装になっているかを点検する
- 点検後も 0 件なら、「Outlook 2016 はいるが Trident でアドインを開いていない（または極小）」可能性が高い
- hostVersion は「Outlook 2016 がいる」という影響範囲把握に使い、エンジン断定には使わない
Office.js で「IE11 だけを公式に判定する API」がない理由と、現実的な代替
現場でよくある期待は「Office.js で IE11 かどうかを確定する API が欲しい」です。しかし、hostVersion のような診断情報は “ホスト（Outlook）の情報” が中心であり、レンダリングエンジン（Trident / WebView2 / ブラウザ）を確実に判定するための専用 API は用意されていない、という理解が現実的です。
そのため、エンジン判定は次のように割り切ります。
- エンジン判定：UA（＋ documentMode などのブラウザ側情報）
- ホスト判定：Office.js の diagnostics（hostVersion など）
- 最終判断：両方をログに残して、実際の分布で判断する
IE11（Trident）を「確実に検出」するための実装ポイント
IE11 を見落とす最大原因は「IE11 では Angular が動かず、UA を送るところまで到達しない」ことです。したがって、検出はアプリ本体（Angular）とは切り離し、最小の ES5 スクリプトで最速に実行するのがコツです。
最低限の判定ロジック
IE11（Trident）で典型的に使える判定材料は次の 2 つです。
- UA に “Trident” または “MSIE” が含まれる
- document.documentMode が存在する（IE 固有）
判定の目安になる UA 断片
| エンジン | UA の特徴 | 補足 |
|---|---|---|
| IE11（Trident） | Trident/7.0、rv:11.0 | “MSIE” が無くても IE11 は判定可能 |
| 旧 Edge（EdgeHTML） | Edge/xx | 現在は組織内に残っている場合のみ注意 |
| Chromium 系（Edge / Chrome / WebView2） | AppleWebKit、Chrome/xx、Edg/xx | “Edg/” があれば Edge（Chromium）寄り |
Angular 起動前に動く「最小テレメトリ」例
以下は、IE11 でも動くようにES5 記法だけで書いた例です。ポイントは、ログ送信を fetch に頼らないこと（IE11 は未対応）と、アドイン本体のロード前に実行することです。
<script>
(function () {
// 1) まずは IE/Trident 判定（ES5）
var ua = window.navigator && window.navigator.userAgent ? window.navigator.userAgent : '';
var isTrident = ua.indexOf('Trident/') !== -1 || ua.indexOf('MSIE ') !== -1;
var docMode = document.documentMode; // IE のとき数値が入る
// 2) 送信データ（必要最小限に）
// 取り回しやすいように長すぎる UA は切る、個人情報は載せない
var payload = {
ua: ua.substring(0, 200),
isTrident: isTrident ? 1 : 0,
docMode: docMode ? docMode : ''
};
// 3) 送信（IE11 でも動くように Image ピクセルで送る）
// 実運用では受け側で JSON を組み立てるか、クエリを最小にする
var img = new Image();
img.src = '/addin-telemetry/engine.gif'
+ '?t=' + new Date().getTime()
+ '&tr=' + encodeURIComponent(payload.isTrident)
+ '&dm=' + encodeURIComponent(payload.docMode)
+ '&ua=' + encodeURIComponent(payload.ua);
// 4) Trident の場合は Angular を読まずに案内を表示する（事故防止）
if (isTrident) {
var el = document.getElementById('app');
if (el) {
el.innerHTML =
'<div style="font-family:Segoe UI,Arial,sans-serif; padding:16px;">'
+ '<h3 style="margin:0 0 8px;">この Outlook では最新版アドインを表示できません</h3>'
+ '<p style="margin:0 0 8px;">Outlook の更新が必要です。社内手順に従って更新してください。</p>'
+ '<p style="margin:0;">（管理者の方へ）この画面が出た端末は IE11（Trident）で起動しています。</p>'
+ '</div>';
}
return;
}
// 5) モダン環境なら Angular をロード
var s = document.createElement('script');
s.src = '/assets/app/main.modern.js';
document.body.appendChild(s);
})();
</script>この方式にすると、IE11 で Angular が起動しなくても「IE11 だった」という事実だけは確実に拾えます。UA が 0 件という結果が本当に“ゼロ”なのか、“拾えていないだけ”なのかを切り分けるためにも有効です。
「UA 解析が最も現実的で信頼できる」ための条件
UA は強力ですが、条件が揃ってはじめて「ソース・オブ・トゥルース」として機能します。
- 計測が最初に実行される（Angular/React/Vue などの起動前）
- IE11 でも送れる通信手段を使う（Image / XHR など）
- 計測先が社内ネットワークから確実に到達できる（プロキシ、証明書、FW）
- 集計単位を決める（セッション単位か、端末単位か、ユーザー単位か）
これらを満たしたうえで IE11 UA が 0 件なら、その結果は非常に強い根拠になります。
Angular 19 で IE11 を「無理やりサポート」できるのか
ここは期待値調整が重要です。Angular 12 以降（Angular 19 を含む）は IE11 を公式サポートしていません。理屈としては「トランスパイルして ES5 に落とす」「必要ポリフィルを積む」といった延命策が考えられますが、実務では次の壁に当たります。
- ビルドチェーンや依存ライブラリが IE11 を前提にしていない（想定外の箇所で壊れる）
- 動いても “動作保証外” で、障害時に原因切り分けと保守コストが跳ね上がる
- セキュリティ・運用の観点で IE11 を延命させること自体が負債になる
そのため現実的な結論は次の通りです。
- Angular 19 に移行するなら、IE11（Trident）対応は段階的に廃止する方針が基本
- どうしても残るユーザーには、Angular 19 を “IE11 で動かす” のではなく、別の体験（案内画面／レガシー版）を用意する
移行時の選択肢を整理する
「IE11 が残っているかもしれない」状況で Angular 19 へ移行する場合、取り得る手は大きく分けて 4 つです。
| 方針 | やること | メリット | デメリット | 現実度 |
|---|---|---|---|---|
| IE11 を対象外にする | Trident 検出で案内画面／更新促進 | 開発・保守が最も軽い。品質が上げやすい | 残存ユーザーは使えなくなる（案内が必須） | 高 |
| レガシー画面だけ提供 | IE11 では最低限の機能だけ（静的 UI） | 業務停止を避けつつ移行できる | 機能差が出る。要件調整が必要 | 中 |
| 二重運用（新旧アプリ併存） | IE11 は AngularJS/旧版、モダンは Angular 19 | 既存業務を守りながら刷新できる | 運用が複雑（デプロイ、障害対応、テストが倍） | 中〜高 |
| Angular 19 を IE11 対応に“改造” | ES5 化・ポリフィル・依存見直し | 単一コードベースの理想形に見える | 動作保証外。工数が読めず、壊れやすい | 低 |
多くの組織で落とし所になりやすいのは「IE11 を対象外にしつつ、影響を最小化する」か「二重運用で段階的に畳む」です。どちらを選ぶにしても、まずは現状の Trident 実数を取ることが最重要です。
Outlook 2016 がいる環境で、事故を起こしにくいアーキテクチャ
Outlook アドイン移行で失敗しにくい構成は「入口は軽く・古く、アプリ本体は新しく」です。
入口（index.html）は “レガシーでも動く” を最優先にする
Angular 19 に移行しても、最初に読み込まれる HTML と小さな判定スクリプトだけは IE11 でも動くようにしておくと、次が実現できます。
- IE11 を確実に検出してログに残せる
- IE11 には Angular を読ませず、案内画面に切り替えられる
- 「真っ白」「エラーだけ出て何も起きない」を防げる
サーバー側で「UA に応じて配信を分ける」
もし二重運用やレガシー画面提供をするなら、同一の SourceLocation でもサーバー側で振り分けできます。
- Trident 判定なら
/legacy/を返す（旧 AngularJS、または最小 UI） - モダン判定なら
/app/を返す（Angular 19）
これにより、Outlook 管理（マニフェスト配布）を過度に複雑化せずに移行を進められます。
「非対応です」の出し方が移行成否を分ける
IE11（Trident）を切る場合でも、ただ動かなくするのは最悪の体験です。Outlook アドインは業務フローに組み込まれていることが多く、突然使えなくなると問い合わせ・炎上・ロールバックに直結します。
案内画面に入れるべき要素
| 要素 | 入れる理由 | 例 |
|---|---|---|
| 何が起きているか | ユーザーの不安を減らす | 「この Outlook では最新版アドインを表示できません」 |
| ユーザーがやること | 次の行動を明確にする | 「Outlook を更新してください」「管理者に連絡してください」 |
| 管理者向けの手がかり | 原因切り分けを早める | 「IE11（Trident）で起動しています」 |
| 問い合わせ導線 | 現場が詰まらない | 社内ヘルプデスクの連絡先、チケット URL |
| アドインのバージョン | トラブル時の特定 | 「Add-in version: 2.3.0」 |
案内画面を用意しておくと、残存ユーザーがいた場合でも “業務が止まる” から “更新の必要に気づける” に変わり、移行の失敗確率が大きく下がります。
テレメトリ設計：UA と hostVersion を「同じイベント」に入れる
判断を誤らないためには、UA と hostVersion を別々に集計するのではなく、同一セッションのイベントとして一緒に保存するのが効果的です。あとで「Outlook 2016 のうち、Trident は何件か？」が一発で出せます。
| ログ項目 | 例 | 目的 |
|---|---|---|
| timestamp | 2025-12-29T10:15:30Z | 時系列・ロールアウト判定 |
| addinVersion | 2.3.0 | バージョン別の障害把握 |
| userAgent（短縮） | Mozilla/5.0 … Trident/7.0 … | エンジン推定 |
| isTrident | 1 / 0 | 集計を高速化 |
| documentMode | 11 | 互換表示の検知 |
| hostVersion | 16.0.xxxx.xxxx | Outlook バージョン把握 |
| hostName（取れる場合） | Outlook | ホスト識別 |
| platform（取れる場合） | PC / OfficeOnline など | デスクトップと Web の切り分け |
| correlationId | GUID | 1 操作の追跡、障害解析 |
個人情報や機微情報の扱いは組織のポリシーに従いつつ、少なくとも「UA（短縮）」「isTrident」「hostVersion」「addinVersion」は移行期間だけでも確実に残すと、判断が圧倒的にしやすくなります。
移行前にやっておくと強い「テスト観点」
Outlook アドインの移行は、単体テストだけでは拾えない “ホスト差” でハマりがちです。特に IE11 を切る判断をするなら、次の観点を先に潰しておくと安全です。
| 観点 | 確認内容 | 狙い |
|---|---|---|
| 起動の最初の 1 秒 | 判定スクリプトが必ず動くか | IE11 でもログを取り逃がさない |
| 通信経路 | 社内端末から計測先に到達できるか | “IE11 0 件” が本当に 0 になる |
| プロキシ・証明書 | 混在コンテンツや TLS で止まらないか | 特定部署だけログ欠落を防ぐ |
| 案内画面 | 文言・導線・問い合わせ先が妥当か | ユーザーの自己解決率を上げる |
| ロールバック | 不具合時に旧版へ戻せるか | 移行の心理的安全性を確保 |
段階的に廃止するための進め方
IE11（Trident）を一気に切るのが難しい場合は、段階的に“出口”を作ると現実的です。
- 観測フェーズ：UA（Trident）と hostVersion の同時ログを取り、残存割合と偏りを把握する
- 告知フェーズ：Trident で開いた場合に「今後非対応になる」警告を出す（まずは業務は継続）
- 制限フェーズ：Trident では閲覧のみ・一部機能停止など段階制限（要件次第）
- 廃止フェーズ：Trident は案内画面のみ、モダン WebView 前提へ
この流れにすると、現場の反発を最小化しながら Angular 19 への移行を推進しやすくなります。
よくある質問
Outlook 2016 の利用者がいるなら、Angular 19 移行はやめるべき？
やめるかどうかは「Outlook 2016 がいるか」ではなく「Trident（IE11）でアドインが開かれているか」で決めるのが安全です。Outlook 2016 が一定数いても、実際のレンダリングエンジンが Trident でない（またはアドイン利用がない）なら、移行しても影響が出ない可能性があります。まずは UA と hostVersion の同時ログで事実を取りに行くのが最短です。
UA は改ざんできるから信頼できないのでは？
一般論として UA だけに依存するのは危険という話はあります。ただし Outlook アドインのような埋め込み WebView 環境では、ユーザーが任意に UA を変更して運用しているケースは稀で、しかも “Trident かどうか” のような粗い判定なら UA は現実的に十分使えます。より確度を上げたいなら、document.documentMode のような IE 固有の特徴と組み合わせると堅牢になります。
「IE11 0 件」なら安心して切っていい？
安心できる可能性は高いですが、条件付きです。計測が Angular 起動前に実行され、IE11 でも送信でき、社内ネットワークの到達性に問題がない――この前提が揃っていれば 0 件は強い根拠になります。逆に、計測が Angular 内にある、fetch に依存している、特定端末で計測先が弾かれる、といった状態だと 0 件は「見えていないだけ」になり得ます。
IE11 を切る場合、ユーザーへの説明はどう書けばいい？
ユーザー向けには「この Outlook では表示できない」「更新が必要」「問い合わせ先」を短く。管理者向けには「IE11（Trident）で起動している」など原因に直結する情報を添えるのが効果的です。責める文言ではなく、次の行動が取れる文言に寄せると問い合わせが減ります。
まとめ：判断軸は「Outlook の版」ではなく「実際のエンジン」
Outlook アドインを AngularJS から Angular 19 へ移行する際、IE11（Trident）対応の可否は最大の分岐点になります。ここで重要なのは、hostVersion は “Outlook のバージョン把握” に役立つ一方で、レンダリングエンジンの確定には向かないという点です。エンジン検出としては UA（＋ documentMode）が現実的で、しかも Angular が動かない環境でも取り逃がさないために「入口で計測する」設計が効きます。
UA 計測が正しく実装され、十分な網羅性が担保できたうえで IE11 UA が 0 件なら、移行判断の根拠として強力です。もしレガシー環境が残っていた場合でも、案内画面と段階的ロールアウトを用意しておけば、業務影響を最小化しながら Angular 19 への刷新を進められます。
コメント