はじめに
「Excelのファイルを開いたら、ボタンが押せなくなった」
「IEモードで動いている社内システム、あと何年もつのか誰も答えられない」
現場でよく聞く相談だ。原因の多くはActiveX。1996年に登場した、Windows専用の古い部品技術になる。
ここで最初に、ひとつ誤解を解いておきたい。ActiveXは「廃止された」わけではない。既定で無効になっただけで、設定を戻せば今も動く。ただし、動くからといって放置していい状態でもない。この「まだ動くが、もう安全でも安泰でもない」という中途半端な位置こそが、担当者を悩ませている正体だ。
この記事では、次の3点を実務ベースで整理する。
- 2026年8月時点で、ActiveXとIEモードが実際どういう扱いになっているか
- 自社に依存箇所がどれだけあるかを、コマンドで洗い出す方法
- HTML＋JavaScriptやWebView2へ、何を基準にどう置き換えるか
そのまま社内展開できるよう、PowerShellやJavaScriptのコード例、判断用の表も載せた。
現状把握：いま何が決まっていて、何が決まっていないのか
まず事実だけを時系列で並べる。噂と公式発表が混ざりやすい領域なので、ここは正確に押さえてほしい。
| 時期 | 何が起きたか |
|---|---|
| 2022年6月 | Internet Explorer 11 デスクトップアプリが特定OSでサポート終了 |
| 2024年10月 | Office 2024（永続版）で、ActiveXコントロールが既定で無効に |
| 2025年4月 | Microsoft 365 Apps（バージョン2504以降）でも既定で無効に |
| 2025年8月〜10月 | EdgeのIEモードを悪用した攻撃を確認。Microsoftが起動導線を削除 |
| 2027年ごろ（予定） | VBScriptがオンデマンド機能として既定で無効化、その後Windowsから削除予定 |
| 少なくとも2029年まで | EdgeのIEモードはサポート継続。廃止する場合は1年前に告知 |
「無効化」であって「削除」ではない
Office 2024とMicrosoft 365の変更内容は、既定設定が「確認してから有効化」から「通知なしですべて無効」へ切り替わった、というものだ。対象はWord、Excel、PowerPoint、Visio。ファイルを開くとメッセージバーにブロックの表示が出て、既存のActiveXオブジェクトは静止画像のように見えるだけになり、操作はできない。
重要なのは、MicrosoftがActiveXの完全削除やサポート終了を宣言していない点だ。トラストセンター、グループポリシー、レジストリのいずれかを変更すれば再有効化できる。
では安心か。むしろ逆になる。参考になるのがVBScriptの前例で、こちらは「非推奨 → オンデマンド機能化 → 既定で無効 → 削除」という段階を踏むスケジュールが公表済みだ。ActiveXも既定無効という同じ第一段階に入った。明確な期限がないぶん、社内で危機感を共有しづらく、対応が後回しになりやすい。ここが厄介なところだ。
IEモードは「動くから安全」ではない
2025年8月、Microsoftのブラウザセキュリティチームが攻撃の報告を受けた。攻撃の流れはこうなる。
- 正規サイトに見せかけた偽サイトへ誘導する
- ページ上の案内で「IEモードで再読み込み」させる
- IEの古いJavaScriptエンジン（Chakra）の未修正の脆弱性を突いてコードを実行する
- さらに別の脆弱性で権限を昇格し、端末を掌握する
技術的に高度なのは後半だけで、入口はごく普通のソーシャルエンジニアリングだ。「このサイトはIEモードで見てください」という文言に、業務で慣れてしまっている組織ほど引っかかりやすい。
Microsoftの対応は素早かった。ツールバーのボタン、右クリックメニュー、ハンバーガーメニューからIEモードの起動項目を削除。以降は設定画面（edge://settings/defaultBrowser）で明示的に許可し、URLを1件ずつ登録する方式になった。企業向けのグループポリシーやIntuneによる管理は従来どおり使える。
つまりIEモードは、いまや「管理された例外」だ。誰でも気軽に押せるボタンではなくなった。
なぜActiveXは構造的に危ないのか
理由はシンプルで、権限の設計思想が現代と真逆だからだ。
現代のブラウザは、JavaScriptをサンドボックス（隔離された実行環境）の中で動かす。ファイルもカメラもマイクも、ユーザーが明示的に許可した範囲しか触れない。
一方でActiveXコントロールは、ネイティブアプリとほぼ同じ権限で動く。ローカルファイルシステムへのアクセスも、レジストリの変更も可能だ。一度「有効化」を押させれば、攻撃者は端末の中で自由に動ける。だからこそ、ActiveXは長年マルウェアの配布経路として使われ続けてきた。
手順1：ActiveX依存を洗い出す
対策は棚卸しから始まる。「たぶん使っていない」は根拠にならない。実際に探そう。
Officeファイルの中を調べる
xlsx / docx / pptx はZIP形式だ。中身に activeX/ フォルダがあれば、ActiveXコントロールが埋め込まれている。ファイルサーバー全体を一括で調べられる。
# 共有フォルダ配下のOfficeファイルからActiveX埋め込みを検出する
Add-Type -AssemblyName System.IO.Compression.FileSystem
Get-ChildItem -Path "\\fileserver\share" -Recurse -File `
-Include *.xlsx,*.xlsm,*.docx,*.docm,*.pptx,*.pptm -ErrorAction SilentlyContinue |
ForEach-Object {
$file = $_
try {
$zip = [System.IO.Compression.ZipFile]::OpenRead($file.FullName)
$hits = @($zip.Entries | Where-Object { $_.FullName -like "*activeX/*" })
if ($hits.Count -gt 0) {
[PSCustomObject]@{
Path = $file.FullName
Controls = $hits.Count
Updated = $file.LastWriteTime
}
}
$zip.Dispose()
}
catch {
Write-Warning "読み取り失敗: $($file.FullName)"
}
} | Export-Csv .\activex_report.csv -NoTypeInformation -Encoding UTF8
出力されたCSVがそのまま棚卸し表になる。最終更新日を入れておくのがコツだ。5年以上更新されていないファイルは、そもそも業務で使われていない可能性が高い。捨てる判断の材料になる。
Webシステムとスクリプトを調べる
社内Webアプリ、VBS、HTAの中も見てほしい。危険信号は次の3つになる。
# ソースコード内のActiveX参照を検索
Select-String -Path "C:\webroot\*" -Include *.html,*.htm,*.asp,*.aspx,*.js,*.vbs,*.hta `
-Pattern 'classid\s*=|\.ocx|CreateObject\s*\(|ActiveXObject' -Recurse |
Select-Object Path, LineNumber, Line
| 見つかる記述 | 意味 |
|---|---|
<object classid="clsid:..."> |
HTMLに直接ActiveXを埋め込んでいる |
.ocx / codebase= |
ActiveXコントロール本体の配布指定 |
new ActiveXObject(...) |
JavaScriptからのActiveX呼び出し（IE専用） |
CreateObject(...) |
VBA/VBScriptからのCOMオブジェクト生成 |
IEモードの利用実態を調べる
Enterprise Mode サイトリスト（IEモードで開くURLの一覧）を管理しているなら、そのXMLがそのまま「レガシー依存システムの一覧」になる。管理していない場合は、まずサイトリストによる管理へ移行してほしい。誰がどのサイトをIEモードで開いているかを可視化しないと、移行計画は立てられない。
手順2：影響度で仕分ける
洗い出した結果を、そのまま全部作り直そうとすると必ず頓挫する。4分類で整理しよう。
| 分類 | 判断の目安 | 対応方針 |
|---|---|---|
| 廃棄 | 直近1年以上使われていない | 削除・アーカイブ。工数ゼロで件数が減る |
| 代替可 | 日付選択、リスト表示、カレンダーなど汎用UI | Excel標準のフォームコントロールやWeb標準に置換 |
| 要改修 | ローカル機器制御、帳票印刷、電子証明書連携 | 設計から見直す。最も工数がかかる |
| 例外運用 | 業務停止に直結し、改修に時間が必要 | 期限を切って再有効化。放置しない |
経験上、最初の棚卸しで挙がったファイルの半分近くは「廃棄」に落ちる。まずここから着手すると、対象が一気に減って全体像が見えてくる。
手順3：どうしても必要な部分だけ、期限付きで例外運用する
業務が止まる状況では、一時的な再有効化も現実的な選択になる。ただし条件をつけてほしい。
- 対象部署・対象ファイルを限定する
- 「いつまでに置き換えるか」を文書に残す
- 有効化した端末を台帳で管理する
再有効化の方法は3つある。
1. トラストセンター（個人単位・最も安全）
ファイル → オプション → トラストセンター → トラストセンターの設定 → ActiveXの設定
2. グループポリシー（組織単位）
ユーザーの構成 → 管理用テンプレート → Microsoft Office 2016 → セキュリティ設定 → 「すべてのActiveXを無効にする」を「無効」に設定
3. レジストリ
HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security\DisableAllActiveX = 0 (REG_DWORD)
なお、トラストセンターの項目がグレーアウトしている場合は、管理者がポリシーで一括制御している。個人では変更できない。
設定変更は該当ファイルだけでなく、Word・Excel・PowerPoint・Visio全体に効く点にも注意したい。1つのファイルのために、すべてのOfficeファイルの防御を下げることになる。
手順4：移行先を選ぶ
ここからが本題だ。「とりあえずHTML5とJavaScriptで」と決める前に、用途で分ける。
ブラウザ内で完結する処理か？
├─ Yes → Web標準（HTML + JavaScript）へ移行
│ SPA化するならReact / Vue.jsなど
└─ No（ローカル機器・OS機能が必要）
├─ 社内端末が限定される → WebView2 / Electronでデスクトップアプリ化
└─ 機器メーカー製ドライバが必須 → ローカル常駐サービス + REST APIで橋渡し
WebView2は、Edgeの描画エンジンをデスクトップアプリに埋め込む仕組みだ。画面はWeb技術で作りつつ、ファイルやデバイス操作はネイティブ側に任せられる。IEモード依存の社内システムを移す先として、現実的な着地点になることが多い。
手順5：Web標準APIの「本当の対応範囲」を確認する
ここが他の解説記事といちばん差が出るところなので、丁寧に書く。
「ActiveXでしかできなかったことは、いまやWeb APIでできる」というのは半分正解だ。残り半分は、ブラウザを選ぶ。
| API | できること | 対応状況（2026年時点） |
|---|---|---|
| getUserMedia / WebRTC | カメラ・マイク、映像通話、P2P通信 | 主要ブラウザで広く対応 |
| File System Access API | ローカルファイルの直接読み書き | Chrome / Edge 86以降とOpera。FirefoxとSafariはOPFSのみでファイル選択ダイアログ非対応 |
| WebUSB | USB機器への直接接続 | Chromium系のみ。Firefox・Safari非対応（世界シェア約76%） |
| Web Serial | シリアル機器（計測器、レジ周辺機器など） | Chrome / Edge 89以降。Safari・Firefox安定版は非対応（約72%） |
| Web Bluetooth | BLE機器との通信 | Chromium系中心。Safari非対応 |
つまり社内標準ブラウザがEdgeやChromeなら、これらは十分に実用範囲だ。逆に「Macも使う」「iPadからも使う」という要件があるなら、File System Access APIやWebUSBを前提にした設計は破綻する。
対策はフォールバックの用意になる。ファイル保存を例にすると、こう書ける。
async function saveCsv(text, filename = "report.csv") {
const blob = new Blob([text], { type: "text/csv;charset=utf-8" });
// Chrome / Edge：保存先をユーザーが選べる
if ("showSaveFilePicker" in window) {
try {
const handle = await window.showSaveFilePicker({ suggestedName: filename });
const writable = await handle.createWritable();
await writable.write(blob);
await writable.close();
return;
} catch (err) {
if (err.name === "AbortError") return; // ユーザーがキャンセル
console.warn("ピッカー保存に失敗。従来方式へ切り替えます", err);
}
}
// Safari / Firefox / モバイル：ダウンロードフォルダへ保存
const url = URL.createObjectURL(blob);
const a = document.createElement("a");
a.href = url;
a.download = filename;
a.click();
URL.revokeObjectURL(url);
}
10行程度の分岐で、対応環境が一気に広がる。「新しいAPIを使う」ではなく「使えない環境でも壊れないように書く」。これが移行を成功させる分かれ目になる。
手順6：IEモードからの出口を設計する
EdgeのIEモードは、少なくとも2029年まではサポートされ、廃止する場合は1年前に告知される方針が示されている。
ここで押さえるべきは、2029年は「準備を始める期限」ではなく「移行を完了しておく期限」だという点だ。業務システムの改修は、要件定義から本番稼働まで1〜2年かかることも珍しくない。逆算すると、着手はもう遅いくらいになる。
加えて、IEモードはEdgeとWindowsのライフサイクルに乗った機能だ。Edgeは原則として最新版のみがサポート対象なので、更新のたびに挙動が変わる可能性がある。実際、Edgeの更新後にIEモードの表示が崩れる、起動しないといったトラブルは各所で報告されている。「2029年まで安泰」という前提で計画を立ててはいけない。
当面の運用としては、次の3点で管理する。
- サイトリストに登録したURLだけをIEモードで開く（登録外は原則禁止）
- 登録URLごとに移行担当と期限を紐づける
- 四半期ごとに登録件数を棚卸しし、減っているかを確認する
登録件数を減らすこと自体をKPIにすると、進捗が数字で見えて社内説明がしやすくなる。
手順7：ベンダーと社内に確認を投げる
自社開発でないシステムは、まず状況確認から。次のような内容で十分だ。
お世話になっております。
現在ご提供いただいている「〇〇システム」について、以下の3点をご確認いただけますでしょうか。
- ActiveXコントロール（.ocx）への依存の有無
- Microsoft EdgeのIEモード以外での動作可否
- モダンブラウザ対応版の提供予定と、その時期
Office 2024およびMicrosoft 365でActiveXが既定無効となったこと、EdgeのIEモードのサポート期限を踏まえ、社内の移行計画を策定しております。
回答が「対応予定なし」なら、それは製品の乗り換えを検討すべきサインだ。逆に「対応版が2027年に出る」といった具体的な回答が得られれば、それを起点に社内スケジュールを組める。
まとめ
ここまでの内容を、実務で使う優先順に整理する。
- ActiveXは削除されたのではなく、Office 2024（2024年10月）とMicrosoft 365（2025年4月）で既定無効になった。再有効化は可能だが、それは延命であって解決ではない
- IEモードは2025年に実際の攻撃で悪用され、起動導線が制限された。「動くから安全」は成り立たない
- 対応の第一歩は棚卸し。PowerShellでOfficeファイルとソースコードを検索すれば、数時間で全体像がつかめる
- 移行先はブラウザ内完結ならWeb標準、機器制御が必要ならWebView2やローカルサービス連携
- File System Access APIやWebUSBはChromium系限定。フォールバックを書けば実運用に耐える
- IEモードのサポートは少なくとも2029年まで。ただしそれは完了期限であり、準備の開始期限ではない
棚卸しさえ済めば、「何を捨てて、何をいつまでに直すか」が数字で語れるようになる。予算も工数も、そこから初めて動き出す。
今日できる最初の一歩
手順1のPowerShellスクリプトを、自部門の共有フォルダに対して1回実行してみてほしい。所要時間は数分から数十分。出てきたCSVの行数が、あなたの組織が抱えている負債の大きさになる。
0行なら安心していい。3桁なら、来週の会議の議題にしよう。
参考リンク
コメント