SharePoint で共有している .xlsm テンプレートを、外部ユーザーが Excel Online（Excel for the Web）で開いたらチェックボックス等が動かない——この手の相談はここ数年で一気に増えました。本記事では「なぜ起きるのか」を仕様ベースで整理し、短期の運用回避と、Office Scripts／Office.js／Power Apps／Power Pages への現実的な移行手順までまとめます。
結論：Excel for the Web では ActiveX／フォームコントロールは動かない
Excel for the Web（ブラウザー版 Excel）では、ActiveX コントロールもフォームコントロールも「実行・操作の対象外」です。そのため、設定変更（Trusted Location、信頼センター、レジストリ等）で Web 側の制約を覆す “正式な回避策” はありません。
- フォームコントロールに置き換えても Web 互換にはなりません（同じく未サポート扱い）。
- VBA マクロも、Web では「開けるが作成・実行・編集はできない」ため、コントロールと VBA の組み合わせで作った UI は動きません。
- Web で “動く形” にしたいなら、目的別に Office Scripts／Office.js アドイン／Power Apps／Power Pages などへ作り替えるのが現実解です。
まず整理：今回の症状は「ActiveX が無効化された」以前に、Web 版の仕様で詰んでいる
2025年4月以降、Microsoft 365 アプリ（デスクトップ版）では ActiveX が既定で無効化される流れが明確になり、以前より “ActiveX 前提の資産” が壊れやすくなりました。
ただし今回のポイントは、Excel for the Web が ActiveX／フォームコントロールをそもそも実行できない点です。デスクトップ版の信頼センター設定や Trusted Location は、基本的にデスクトップ版 Office アプリの制御であり、Web 版の非対応を解除するものではありません。
対応可否の早見表（SharePoint / OneDrive で開く前提）
| 機能・部品 | デスクトップ版 Excel | Excel for the Web | 補足 |
|---|---|---|---|
| ActiveX コントロール | 条件付き（既定無効の影響あり） | 不可 | デスクトップでも既定で無効化される流れ。 |
| フォームコントロール | 可 | 不可 | Web では操作・実行の対象外。 |
| VBA マクロ（.xlsm） | 可 | 実行不可 | Web では開けるが作成・実行・編集は不可。 |
| Office Scripts | 可 | 可 | Web での自動化向け。ボタン配置も可能。 |
| Office.js（Office アドイン） | 可 | 可 | Excel 内にタスクペイン等の UI を追加できる。 |
| セル内チェックボックス（新機能） | 可 | 可 | TRUE/FALSE をセルに保持するタイプ。フォームコントロールとは別物。 |
なぜ Web では無理？（技術というより設計思想とセキュリティ）
ActiveX は Windows の COM 技術に依存し、Excel のプロセス内で動作する “クライアントローカル実行” の色が濃い仕組みです。一方、Excel for the Web はブラウザー上で安全に動かすために、実行環境・権限・互換性の前提が根本的に違います。だから「Trusted Location に入れれば Web でも動く」といった類の話にはなりません。
さらに VBA も Web では実行できないため、ActiveX/フォームコントロールに紐づくイベント（Click、Change 等）で業務ロジックを回している構成は、Web に持ち込むほど破綻します。
短期（暫定）対応：現実的に選べるのはこの3パターン
デスクトップ アプリで開く運用に寄せる（最短で止血）
「今の .xlsm を維持したい」「既存の VBA/ActiveX をすぐ作り替えられない」なら、短期はこれが最も成功確率が高いです。
| やること | 効果 | 注意点（外部ユーザー） |
|---|---|---|
| SharePoint/OneDrive 側で “デスクトップで開く” 導線を案内 | Web 非対応機能を回避 | 外部ユーザーがデスクトップ版 Excel を使えない環境だと成立しない。 |
| ユーザー側の既定設定を Desktop 優先に | 誤って Web で開く事故を減らす | 個人設定に依存。組織外だと統制しにくい。 |
| サポートチケットでテナント設定・影響範囲の確認 | 想定外の制限や展開状況を把握 | 時間はかかるが “仕様確認の証跡” が残る |
SharePoint/OneDrive には「ブラウザーではなくデスクトップ アプリで開く」導線や既定アプリの考え方が用意されています。運用設計としては、リンク配布時の案内文に「デスクトップで開く」を明記し、問い合わせの一次対応コストを下げるのがコツです。
“ブラウザー完結” が必須なら、Excel 内を「セル駆動 UI」に寄せる
フォームコントロールの置換は Web 互換になりませんが、「そもそもコントロールを使わない Excel」に寄せると Web 運用が成立することがあります。
- セル内チェックボックス：チェックでセル値（TRUE/FALSE）が変わるタイプ。簡易なチェックリストや入力補助ならこれで代替できるケースが多いです。
- データの入力はテーブル＋入力規則（プルダウン）：入力揺れを減らし、集計・検証もやりやすい。
- 状態表示は条件付き書式：未入力・不備・完了などを色やアイコンで可視化。
割り切りポイント：セル駆動 UI は「クリックでマクロが走る」ような体験は作れません。代わりに “入力の失敗を減らす” 方向で UX を組み直すと、Web でも十分に回る帳票が作れます。
ActiveX を再有効化して凌ぐ（ただしデスクトップ限定、推奨はしづらい）
ActiveX が既定で無効化された後でも、デスクトップ版では信頼センター設定等で再有効化できる余地があります。
ただしこれはデスクトップ版の話で、Excel for the Web の非対応を解決しません。また、ActiveX はセキュリティリスクの文脈で扱われることが多く、外部ユーザー配布のテンプレートで “有効化をお願いする運用” は、説明責任・監査の観点で厳しくなりがちです。
中長期：ActiveX からモダン技術へ（目的別の最適解）
「外部ユーザーにもブラウザーで使わせたい」なら、最終的には作り替えが必要になります。ここは “何を実現したいか” で分岐します。
| 選択肢 | 得意なこと | 外部ユーザー適性 | ハマりどころ |
|---|---|---|---|
| Office Scripts | Excel（特に Web）での自動処理・整形・定型作業 | △（基本は組織内） | スクリプト共有は組織内に限定される。外部ユーザー運用の主役にしにくい。 |
| Office.js アドイン | Excel 内にタスクペイン等の UI、対話、外部 API 連携 | △（配布設計次第） | 配布・権限・サイドロード・管理（中央展開等）をどうするかが先に来る。 |
| Power Apps | 入力フォーム／業務アプリ化（スマホ・Web） | ○（ゲスト共有は要設計） | 外部ユーザーはゲスト招待やライセンス、データソース権限が論点。 |
| Power Pages | 外部向けポータル／Web サイト（認証あり・匿名含む） | ◎ | データは Dataverse 前提に寄せる設計が基本。外部公開のガバナンスが組みやすい。 |
Office Scripts がハマる条件（ただし “外部ユーザー配布テンプレ” の主役にはしにくい）
Office Scripts は Excel for the Web の自動化に向いており、スクリプトをボタンとしてブックに配置することもできます。
一方で、スクリプト共有は「組織内に限定」されるため、SharePoint の共有リンクで外部ユーザーにそのまま実行させるシナリオとは相性がよくありません。
外部ユーザーが入力→内部ユーザーがスクリプトで処理（または Power Automate 経由で自動処理）という “分業” の形なら成立しやすいです。
Office.js アドインがハマる条件（Excel 内でリッチ UI を作りたい）
「Excel の中に専用 UI を置きたい」「ボタン押下で処理」「外部システム API と連携」「入力チェックを対話的にしたい」など、ActiveX で作っていた “画面っぽさ” を Excel の体験のまま再現したいなら Office.js アドインが候補です。Office Add-ins は Web 技術（HTML/CSS/JavaScript）で作れ、Excel on the web でも動作します。
ただし外部ユーザーに配る場合は、「誰がどのテナントでアドインを使うのか」が最初の壁になります。中央展開の範囲、サイドロード可否、認証（Entra ID 等）といった配布設計を先に固めると失敗しにくいです。
Power Apps がハマる条件（入力フォーム／業務アプリとして切り出す）
チェックボックスや選択肢、入力フォームを外部ユーザーに触らせたいなら、Excel のシート上に UI を作るより、最初からフォームアプリに切り出す方が運用が安定します。Power Apps はデータソース（SharePoint リスト、Dataverse など）を背後に置いて、入力・承認・通知まで含めた業務導線を作りやすいのが利点です。
注意点として、Excel コネクタは便利ですが制約が多く、データ規模や同時利用を前提にするほど辛くなります（例：取得件数や委任の制限など）。長期運用なら SharePoint リストや Dataverse に寄せる方が安全です。
Power Pages がハマる条件（外部向けポータルを作りたい）
外部ユーザーを想定するなら、Power Pages はかなり強力です。外部向けサイトとして設計されており、外部の認証や匿名閲覧も含めたパターンを取りやすいのが特徴です。
「外部ユーザーに入力してもらう」「入力内容を安全に保管し、内部で処理・承認する」という構造は、ActiveX チェックボックス付き .xlsm を配るより、セキュリティ面・運用面で説明がつきやすくなります。
“公式の移行ツール” はある？→自動変換は期待せず、要件分解が近道
現場感として、ActiveX 画面を自動で Office Scripts／Office.js／Power Apps に変換してくれる “公式の一括移行ツール” を期待すると詰みます。実務では、既存資産を「UI」「データ」「業務ルール」「自動化」に分解して、最適な置き場に移すのが一番早いです。
移行を成功させる分解テンプレ（そのまま棚卸しに使える）
| 分解対象 | 質問 | 移行先の当たり |
|---|---|---|
| UI（入力・選択） | 誰が、どこで、何を入力する？（外部ユーザー？社内？） | Power Apps / Power Pages、または Excel のセル駆動 UI |
| 業務ルール（チェック・分岐） | 入力チェックはどこでやる？エラーはどう返す？ | Power Apps / Power Pages / Office.js（対話型）、Excel 関数（軽量） |
| 自動処理（整形・集計） | ボタン押下？定時？保存時？承認後？ | Office Scripts + Power Automate、または Power Automate 単体 |
| データ保管 | 同時更新がある？監査ログは？権限は？ | SharePoint リスト / Dataverse（推奨）、Excel は短期・小規模向け |
外部ユーザー配布（SharePoint 共有リンク）で特に注意すべきこと
「Excel をデータベース化」しない方がいいラインを決める
外部ユーザーが編集する前提だと、同時編集・行ロック・権限・誤操作の復旧など、Excel でやるほど辛い領域が必ず出ます。Power Apps で Excel をデータソースにすること自体は可能ですが、制約（例：扱える件数や委任、性能面の注意）があるため、長期ならデータは SharePoint リストや Dataverse に寄せる判断が堅いです。
Power Apps の “外部ユーザー共有” は権限とライセンス設計が本体
外部ユーザー（ゲスト）にアプリを使ってもらう場合、ゲスト招待、データソース権限、必要なライセンスといった前提が絡みます。「アプリを共有したのに動かない」は、だいたいここが原因です。
Office Scripts は「外部ユーザーに配って実行させる」用途だと詰まりやすい
Office Scripts は便利ですが、共有できる範囲が組織内に限定されるため、外部ユーザー配布テンプレートの “ボタンの置き換え” としてはハマりづらいのが実情です。外部入力→内部で処理、のように役割分担すると活きます。
よくある質問（検索されがちな論点を先回り）
フォームコントロールに置き換えたら、Excel Online で動きますか？
動きません。フォームコントロールも Excel for the Web では未サポートです。
Trusted Location にすれば、Web でも ActiveX が動きますか？
動きません。Trusted Location は主にデスクトップ版 Office アプリの信頼設定です。Web 版の非対応を解除するものではありません。
とにかくチェックボックスだけ Web で使いたい。最短の代替は？
フォームコントロールのチェックボックスではなく、セル内チェックボックス（TRUE/FALSE を保持するタイプ）を検討してください。簡易なチェック用途なら Web でも運用が成立しやすいです。
VBA マクロは Web で実行できないんですか？
Excel for the Web では、VBA マクロを作成・実行・編集できません（ファイルを開いて編集すること自体は可能です）。
「常にデスクトップで開く」を強制できますか？
環境や権限に依存しますが、SharePoint/OneDrive/Office 側には “ブラウザーではなくデスクトップ アプリで開く” 方向の設定・導線が用意されています。外部ユーザーを含む場合は、利用環境（デスクトップ版の有無）も含めて運用設計が必要です。
実務でのおすすめ進め方（失敗しにくい順）
- 止血：当面の運用を「デスクトップで開く」へ寄せるか、「セル駆動 UI」へ寄せるかを決める
- 棚卸し：ActiveX/フォームコントロールが担っている役割（入力・検証・自動化・連携）を分解する
- 再設計：外部ユーザーが触る導線は Power Apps / Power Pages に寄せ、Excel は帳票・出力に寄せる
- 段階移行：まずは “入力だけ” を移行 → 次に “自動処理” を Office Scripts/Power Automate へ → 最後に Excel 資産を軽量化
現場のコツ：「Excel を Web で使うこと」自体が目的になってしまうと、設計が歪みます。外部ユーザーが必要なのは多くの場合 “入力フォーム” で、Excel は裏側（集計・出力）に回した方がトラブルが減ります。
まとめ
SharePoint 共有の .xlsm で ActiveX／フォームコントロールが動かなくなった場合、Excel for the Web で動かす公式な回避策はありません。短期は「デスクトップで開く」運用に寄せるか、「セル駆動 UI（セル内チェックボックス等）」へ寄せて Web 互換の範囲で再構成するのが現実的です。中長期は、外部ユーザー要件があるほど Power Apps／Power Pages を中心に据え、Office Scripts／Office.js を補助的に使う設計が安定します。
コメント