Office 2024/Microsoft 365でActiveXが動かない原因と確認手順

1. 最初に知っておくべきこと

Office 2024 と Microsoft 365 では、ActiveX コントロールが既定で無効化されています。 以前は動いていた Excel のボタンやフォーム、Word / PowerPoint の埋め込みオブジェクトが更新後に突然「動かない」ように見えるのは、たいてい プログラムの故障ではなく、セキュリティ既定値の変更 が原因です。

原因は大きく3つに分類できます。

1. セキュリティ設定の変化（Trust Center、ActiveX 既定無効）
2. 32bit / 64bit の不一致（64bit Office に 32bit 専用コントロールを載せている）
3. COM 登録や依存 DLL / ランタイムの不足（regsvr32 未実行、VC++ ランタイム欠落）

実務の鉄則: この順番で上から潰すのが最短です。

この記事で使う用語

情シス担当者向けに、本文で断りなく出てくる用語を先にまとめます。

この記事の構成

長いので、必要なところから読んでください。大きく3つのまとまりに分かれています。

急いでいる場合は、まず 11章「よくある症状と対処法」で自分の症状を探し、そこから該当する Step へ戻ってください。

この記事の知識マップ

Office 2024とMicrosoft 365ではActiveXコントロールが既定で無効化されており、以前動いていたボタンや埋め込みオブジェクトが動かなくなる主因はこの既定値の変更にある。ActiveXの動作はCOMとしてのレジストリ登録を前提とし、Officeとコンポーネントのbitnessが一致していないと動かず、RegAsmのbitness違いも同じ不一致を招く。Trust CenterのActiveX設定とTrusted Publisherによるコード署名の扱い、MOTW付与による保護ビュー、.NET FrameworkやVisual C++再頒布可能パッケージといった依存ランタイムの不足、Click-to-Run特有の導入方式、Edgeの IEモード未構成も同様の症状を引き起こしうる。原因の切り分けにはProcess ExplorerやProcmonでの実測が有効で、恒久対応には限定的な許可と月次エンタープライズチャネルの採用が推奨される。

flowchart LR
    accTitle: Office 2024/Microsoft 365のActiveXトラブルシューティングの知識マップ
    accDescr: ActiveXが既定で無効化されていること、COM登録とbitness一致の前提、Trust Center・保護ビュー・依存ランタイム・Click-to-Run・IEモードという複数の原因がActiveXの動作失敗にどうつながるかを示す図。
    activex["ActiveX"]
    com["COM(コンポーネントオブジェクトモデル)"]
    clsid["CLSID(Class ID)"]
    wow6432node["WOW6432Node"]
    regsvr32["regsvr32"]
    regasm["Regasm.exe"]
    bitness_match_requirement["bitness一致要件"]
    activex_load_failure["ActiveX動作失敗"]
    office_trust_center["トラスト センター"]
    trusted_publisher_store["信頼された発行元ストア"]
    code_signing_cert["コード署名証明書"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    protected_view["保護ビュー"]
    dotnet_framework[".NET Framework"]
    vc_redistributable["Visual C++ 再頒布可能パッケージ"]
    procmon["Process Monitor(procmon.exe)"]
    process_explorer["Process Explorer"]
    ie_mode["IEモード"]
    enterprise_site_list["Enterprise Site List"]
    click_to_run["Click-to-Run"]
    office_msi_install["Office MSIインストール(旧方式)"]
    disableallactivex_policy["DisableAllActiveX(検証用レジストリ)"]
    monthly_enterprise_channel["月次エンタープライズ チャネル"]
    activex -->|"前提とする"| com
    com -->|"利用する"| clsid
    com -.->|"に保存される"| wow6432node
    regsvr32 -->|"実装を担う"| com
    regasm -->|"実装を担う"| com
    regasm -->|"前提とする"| bitness_match_requirement
    activex -->|"前提とする"| bitness_match_requirement
    bitness_match_requirement -->|"原因になり得る"| activex_load_failure
    activex -.->|"で構成できる"| office_trust_center
    office_trust_center -->|"利用する"| trusted_publisher_store
    trusted_publisher_store -->|"前提とする"| code_signing_cert
    code_signing_cert -->|"推奨される対応"| activex
    zone_identifier -->|"原因になり得る"| protected_view
    protected_view -.->|"原因になり得る"| activex_load_failure
    activex -.->|"前提とする"| dotnet_framework
    activex -.->|"前提とする"| vc_redistributable
    activex_load_failure -->|"で確認できる"| procmon
    activex_load_failure -->|"で確認できる"| process_explorer
    ie_mode -.->|"で構成できる"| enterprise_site_list
    ie_mode -.->|"原因になり得る"| activex_load_failure
    click_to_run -->|"の後継"| office_msi_install
    click_to_run -.->|"原因になり得る"| activex_load_failure
    disableallactivex_policy -->|"用いるのは非推奨"| activex
    monthly_enterprise_channel -->|"推奨される対応"| activex

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. Office 2024 系 vs Microsoft 365 ── 何が違うのか

重要: レジストリパスは Office 2024 でも 16.0 のままです。「2024 だから 24.0 を探す」は典型的な遠回りです。

Windows 10 での注意点

Windows 10 の一般サポートは 2025 年 10 月 14 日に終了 しています。ただし Microsoft 365 Apps は Windows 10 上でも 2028 年 10 月 10 日まで セキュリティ更新が提供される移行猶予期間中です。つまり次のような状態です。

• 「Windows 10 では完全に動かない」わけではない
• 「OS はサポート切れ、Apps は猶予中」の二重前提で運用している状態

3. トラブルシューティングの全体像

flowchart TD
    A[症状を再現] --> B[Office の製品名・build・bitness・OS 情報を採取]
    B --> C{OS / Office のサポート前提は OK?}
    C -- NG --> C1[前提修正: OS / Office エディション / チャネル見直し]
    C -- OK --> D[Trust Center を確認]
    D --> E{ActiveX 設定 / 保護ビュー / 信頼済みドキュメントに問題?}
    E -- あり --> E1[設定・署名・配布設計を修正]
    E -- なし --> F{レガシー Web / IE 前提?}
    F -- はい --> F1[IE モードとサイトリストを確認]
    F -- いいえ --> G[CLSID / InprocServer32 / TypeLib を確認]
    G --> H{COM 登録は正常?}
    H -- NG --> H1[regsvr32 / RegAsm / 再インストール]
    H -- OK --> I[依存 DLL / .NET / VC++ ランタイムを確認]
    I --> J{依存関係は満たしている?}
    J -- NG --> J1[該当ランタイムを修復・再配布]
    J -- OK --> K[ログ採取 / Procmon / Process Explorer]
    K --> L[build 差分・セキュリティ更新差分を確認]

4. Step 1 ── 環境情報を採取する

まず以下の情報を必ず記録します。感覚ではなく 数値 で判断するためです。

Office 側

• [ファイル] → [アカウント] → [製品情報] で確認
  • 製品名（Office 2024 / Microsoft 365 の別）
  • バージョンと ビルド番号（最重要）
  • インストール種別（Click-to-Run）
• [Excel のバージョン情報] / [Word のバージョン情報] などの製品情報ダイアログで 32bit / 64bit を確認

Windows 側

# OS の基本情報
Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber, OSArchitecture

# Office プロセスの実行ファイルパス
Get-Process WINWORD, EXCEL, POWERPNT, VISIO -ErrorAction SilentlyContinue |
  Select-Object ProcessName, Path

取得した結果をどう読むか

出力そのものは環境ごとに違うので、見るべき列と判断基準を挙げます。

Get-Process が1件も返さないときは、対象の Office アプリが起動していないだけです。確認したいアプリを開いてから実行し直してください。-ErrorAction SilentlyContinue を付けているため、起動していないプロセス名があってもエラーにはなりません。

Office 側の bitness は、アプリのメニューからも確認できます。Excel なら「ファイル」→「アカウント」→「Excel のバージョン情報」と進むと、開いたダイアログの先頭行にバージョン、ビルド番号、「32 ビット」または「64 ビット」の表記が並びます。この行をそのまま控えておくと、ベンダー問い合わせや再現検証で話が早くなります。

よくある落とし穴

5. Step 2 ── Trust Center とセキュリティ設定を確認する

ここでやるのは、「ファイル自体がブロックされているのか」、それとも 「COM 実体の読み込みに失敗しているのか」 の切り分けです。

チェックリスト（上から順に）

画面のどこを見るか

画面例の代わりに、位置と操作の順序を書いておきます。

• メッセージバー: ファイルを開いた直後に、リボンと編集領域の間へ横長の帯として表示されます。閉じてしまったときは、ファイルをいったん閉じて開き直すと再表示されます。
• ActiveX の設定画面: 「ファイル」→「オプション」→「トラスト センター」まで進んでも、そこに見えているのは説明文とボタンだけです。設定の実体は「トラスト センターの設定(T)…」ボタンを押した先にあり、開いた画面の左側の一覧から「ActiveX の設定」を選びます。この1段を飛ばすと目的の画面には着きません。Microsoft の案内でも、ActiveX を有効にする手順は、メッセージバーからの一時許可ではなく、この設定変更として説明されています。
• 保護ビュー / 信頼済みドキュメント / 信頼できる発行元: いずれも同じ「トラスト センターの設定」画面の左側一覧に並んでいます。再現確認の前に信頼済みドキュメントの記録をクリアしておくと、端末ごとの差が出にくくなります。

設定の適用範囲に注意: ActiveX の設定は、いま開いているファイルだけでなく、Word / Excel / PowerPoint / Visio のすべてのファイルに適用されます。「この1ファイルだけ許可する」設定ではありません。調査のために一時的に緩めたら、必ず元に戻してください。

最初に試すこと

1. 問題のファイルを ローカルの管理されたフォルダ（例: C:\Temp）にコピーし、別名で保存
2. ネットワーク共有やメール添付から直接開くのを避ける（保護ビューの影響を排除）
3. Office を セーフモード で起動してアドインの影響を切り分ける

excel /safe
winword /safe
powerpnt /safe

6. Step 3 ── IE モード依存かどうかを確認する

「通常の ActiveX 障害」だと思っていたら、実は Edge の IE モード未構成 が原因というケースがあります。

• IE モードはブラウザ全体のスイッチではなく、Enterprise Site List に登録したサイトだけ に適用される
• 社内 Web 連携の一部だけが動かない場合は、そのサイトが IE モード対象になっているか確認する

確認先は次のとおりです。

• Edge ポリシー: 管理用テンプレート > Microsoft Edge
• レジストリ: HKLM\SOFTWARE\Policies\Microsoft\Edge
• 診断ページ: edge://compat/iediagnostic

7. Step 4 ── COM 登録を確認する

Trust Center に問題がない場合、次は COM の実体が正しく登録されているかを確認します。

基本確認コマンド

:: CLSID の登録状況を確認
reg query "HKLM\SOFTWARE\Classes\CLSID\{YOUR-CLSID-HERE}\InprocServer32" /s

:: ネイティブ COM / ActiveX DLL の登録・解除
regsvr32 C:\Path\YourControl.dll
regsvr32 /u C:\Path\YourControl.dll

確認結果の読み方

reg query の結果で見るのは3点です。

1. キーが存在するか。キーが無ければ何も表示されず、「見つかりません」というエラーだけが返ります。この時点で未登録が確定します。
2. 既定値に入っている DLL のパス。ここが COM の実体です。
3. そのパスにファイルが実在するか。アンインストールや移動で実体だけが消え、登録が残っている状態はよくあります。

判定まで一度に行うなら、PowerShell の方が読みやすくなります。

# 調べたい CLSID に置き換えて実行します（波かっこを含めて指定）
$clsid = '{00000000-0000-0000-0000-000000000000}'
$key   = "HKLM:\SOFTWARE\Classes\CLSID\$clsid\InprocServer32"

if (Test-Path $key) {
  $server = Get-ItemPropertyValue -Path $key -Name '(default)'
  [pscustomobject]@{
    CLSID      = $clsid
    Server     = $server
    FileExists = Test-Path $server
  }
} else {
  Write-Host "未登録: $key が見つかりません"
}

FileExists が False なら、登録は残っているのに実体が無い状態です。再インストールか再登録が必要です。

見る場所を間違えない: 64bit Windows 上で 32bit の COM を登録すると、実体は HKLM\SOFTWARE\Classes\WOW6432Node\CLSID\{CLSID} 側に入ります。64bit の PowerShell や reg query から HKLM\SOFTWARE\Classes\CLSID だけを見ると「未登録」に見えるため、32bit Office のトラブルでは WOW6432Node 配下も必ず確認してください。

.NET 製 COM の場合（重要）

.NET アセンブリに regsvr32 は使えません。RegAsm を使います。

:: 32bit Office on 64bit Windows → Framework の RegAsm を使う
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

:: 64bit Office → Framework64 の RegAsm を使う
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\Path\YourControl.dll" /codebase /tlb

典型的な事故: 「RegAsm の bitness が Office の bitness と揃っていない」 → レジストリ上は登録成功でも Office からは見つからない。

8. Step 5 ── 依存 DLL / ランタイムを確認する

「本体 DLL はあるのにロードされない」場合は、依存先が不足している ケースが多いです。

実務で頻発する不足ランタイム

低レベル調査ツール

Procmon で再現時のログを取り、NAME NOT FOUND でフィルタリングすれば、どの DLL やレジストリキーが見つからなかったかが一目でわかります。

フィルターの掛け方、ノイズの落とし方、どのイベントから読むかはProcess Monitor(ProcMon)実践ガイドに手順としてまとめています。また、登録と bitness の組み合わせで詰まった場合はCOM/OCX/ActiveX開発でハマる登録とbitnessの罠が、開発側から見た同じ問題を扱っています。

9. Step 6 ── ログを取得して最終確認

ここまでで原因が特定できない場合は、ログを有効にして 再現の瞬間 を捕まえます。

Office 一般ログの有効化

reg add HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /t REG_DWORD /d 1

Click-to-Run 詳細ログの有効化

reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /t REG_DWORD /d 1

ログは %windir%\temp や %temp% に出力されます。

イベントビューアーも併用

eventvwr.msc

• Windows ログ > アプリケーション を確認
• .NET Runtime や SideBySide のエラーが決定打になることが多い

検証後のログ無効化（忘れずに）

reg delete HKCU\Software\Microsoft\Office\16.0\Common\Logging /v EnableLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v PipelineLogging /f
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f

10. 主要レジストリ / ポリシー早見表

覚えるべき4つのパス

32bit Office on 64bit Windows では、COM 関連は Wow6432Node 配下も確認すること。

よく使うテスト用レジストリ（検証専用）

Windows Registry Editor Version 5.00

; テスト専用: ActiveX 一括無効を解除
[HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Security]
"DisableAllActiveX"=dword:00000000

警告: これらの設定は検証専用です。恒久対応は「信頼できる配布経路と署名」で行ってください。

11. よくある症状と対処法

12. 企業向け推奨設定

恒久対策の基本は 「全体のセキュリティを下げる」ではなく「必要な対象だけを限定的に許可する」 ことです。

Microsoft 365 の展開設定例（32bit + 月次エンタープライズ）

<Configuration>
  <Add OfficeClientEdition="32" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

13. 最終手段 ── 修復

• クイック修復 / オンライン修復 は、設定や登録破損には効く
• ただし x86 / x64 不一致や署名 / ポリシー問題そのものは解決しない
• 修復は「最後にやる」（先にやると調査ログが汚れる）

14. コマンド早見表

15. まとめ ── 潰す順番を間違えない

設定ミス → OS / bitness の不一致 → COM 実体問題 → 依存関係 → 更新差分

ActiveX のトラブルは「Excel だけの問題」に見えても、実際には Office の既定セキュリティ + Windows のサポート前提 + COM 実体登録 + 依存ランタイム + 更新モデル の5層が交差する問題です。闇雲に設定を緩める前に、上から順に切り分ければ、再発しにくい修復にたどり着けます。

参考リンク

• ActiveX controls are disabled by default in Microsoft 365 and Office 2024 ─ 既定無効化の影響範囲
• Enable or disable ActiveX settings in Office files ─ ユーザー操作に最も近い資料
• Update history for Office LTSC 2024 and Office 2024 ─ build 比較、更新前後差分
• Overview of update channels for Microsoft 365 Apps ─ Current / Monthly Enterprise / Semi-Annual の違い
• Release Information for Updates to Microsoft 365 Apps ─ チャネル起因の挙動差
• Compatibility between the 32-bit and 64-bit versions of Office ─ ActiveX / COM 資産が絡むときの判断基準
• Microsoft Edge での Internet Explorer モード ─ Enterprise Site List とポリシー
• regsvr32 コマンド ─ ネイティブ COM の登録 / 解除
• Regasm.exe (アセンブリ登録ツール) ─ .NET 製 COM の登録
• Process Monitor (Procmon) ─ NAME NOT FOUND / PATH NOT FOUND の追跡
• Process Explorer ─ プロセスの DLL ロード状況
• Latest supported Visual C++ Redistributable Downloads ─ VC++ ランタイム不足の確認先
• .NET Framework インストール ガイド ─ .NET Framework のバージョン確認

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Office 2024やMicrosoft 365でActiveXが既定で無効化されたとはどういうことですか？

Office 2024 と Microsoft 365 では、ActiveX コントロールが既定で無効化されています。以前は動いていた Excel のボタンやフォーム、Word / PowerPoint の埋め込みオブジェクトが更新後に突然「動かない」ように見えるのは、たいていプログラムの故障ではなく、このセキュリティ既定値の変更が原因です。ファイルを開いたときの黄色いメッセージバーで [コンテンツの有効化] を選んで一時的に動くか試し、Trust Center（セキュリティ センター）の ActiveX 設定を確認するのが最初のステップです。

Office更新後にExcelのActiveXボタンが無反応になりました。何から確認すべきですか？

原因は大きく 3 つに分類できます。1 つ目はセキュリティ設定の変化（Trust Center、ActiveX 既定無効、保護ビュー）、2 つ目は 32bit / 64bit の不一致（64bit Office に 32bit 専用コントロールを載せている）、3 つ目は COM 登録や依存 DLL / ランタイムの不足（regsvr32 未実行、VC++ ランタイム欠落）です。この順番で上から潰すのが最短です。あわせて、製品名・ビルド番号・Office の bitness・OS 情報を最初に記録し、ネットワーク共有やメール添付から直接開かずローカルフォルダで再現差を確認します。

64bit OfficeでだけActiveXコントロールが動かないのはなぜですか？

Office の bitness と COM / ActiveX の bitness は一致が必須だからです。64bit Office に 32bit 専用のコントロールを載せても動きません。ベンダーに x64 版の有無を確認し、なければ Office 32bit への切り替えを検討します。.NET 製 COM の場合は regsvr32 ではなく RegAsm を使い、32bit Office なら Framework、64bit Office なら Framework64 の RegAsm で登録します。RegAsm の bitness が Office と揃っていないと、レジストリ上は登録成功でも Office からは見つからない、という典型的な事故になります。

ActiveXを恒久的に使えるようにするには、どう設定すべきですか？

全体のセキュリティを下げるのではなく、必要な対象だけを限定的に許可するのが基本です。DisableAllActiveX のレジストリ変更はあくまで検証専用で、恒久対応は信頼できる配布経路と署名で行います。具体的には、自社配布の ActiveX / マクロ / アドインにコード署名して Trusted Publisher を一元管理し、Microsoft 365 では変化点が読みやすい月次エンタープライズ チャネルを検討し、ベンダーが x64 対応を明言していない限り Office 32bit を優先検討します。本番配布前には pilot ring を作り、代表帳票・代表端末でビルドを固定して検証します。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。