EdgeでWord自動ダウンロード時のダウンロードバー非表示｜AutoOpenFileTypesとカスタムURI/拡張で社内URLだけ抑止する方法

社内の Word 文書（.docx／.doc）を Microsoft Edge で自動ダウンロード → 自動起動させると、毎回 Edge の右上（旧 UI では下部）に「ダウンロード」メニュー（通称ダウンロードバブル／バー）が残り続け、ユーザーのクリックを誘発してしまいます。本稿は AutoOpenFileTypes と AutoOpenAllowedForURLs を有効化している前提で、社内サーバー配布の Word ファイルに限ってダウンロードバーを表示させないための実践的ワークアラウンドを、管理者視点で徹底解説します。

現象と要件の整理

現象

• レジストリ／ポリシーで AutoOpenFileTypes に docx, doc を追加、AutoOpenAllowedForURLs に自社サーバーの URL（例：https://intra.example.co.jp）を登録すると、Word は自動起動する。
• しかし Edge の右上（旧 UI ではウィンドウ下部）に「ダウンロード」メニューが毎回表示され、開いた後もしばらく残る。

要件

1. 社内サーバー配布の Word 文書に限り、ダウンロードバーを非表示（または即時消去）にしたい。
2. 社内以外のサイトでは、通常のダウンロード通知を残したい（ユーザーの安全性・可視性は維持）。

なぜバー（ダウンロードバブル）が出続けるのか

Edge の「ファイル自動オープン」と「ダウンロード UI 表示」は別レイヤーで制御されています。AutoOpenFileTypes はダウンロード完了後の「既定アプリで自動実行」を許可するだけで、通知 UI の出し分けまでは面倒を見ません。さらに通知 UI はセキュリティ（不審ダウンロードの気づき）や操作履歴へのアクセス手段も兼ねるため、URL 単位で抑止する公式ポリシーは現時点で提供されていません。したがって、要件を満たすには「UI を完全に無効化」ではなく、社内 URL だけ別ルートで Word を開かせ、Edge のダウンロード機構を経由させない／拡張機能で検知して直ちに消すといった応用が必要になります。

解決アプローチ早見表

方法	概要	メリット	デメリット／注意点
A. Edge の既定設定でバーを完全に無効化	「設定 > ダウンロード > ダウンロード開始時にメニューを表示」をオフ（ポリシー非依存のユーザー設定相当）。	即時・簡単に効果が出る。	全サイトで通知が消えるため、要件 2 を満たさない。ダウンロードの可視性が下がる。
B. カスタム URI プロトコル（推奨ワークアラウンド）	Windows に wordopen: などの独自プロトコルを登録し、社内リンクを wordopen:https://server/path/file.docx に変更。Edge の AutoLaunchProtocolsFromOrigins で社内ドメインからのプロトコル起動のみ無確認で許可。	社内 URL だけバーを回避。Word が即起動し、ダウンロード UI を経由しない。	初回の確認ダイアログ抑止にポリシー設定が必要。リンク書式の置換作業が発生。
C. Edge 拡張機能で UI を抑制	拡張の chrome.downloads API で社内配布ファイルを検出し、履歴を即時消去してバブルを短時間で消す。	既存リンクを変えずに細粒度の制御が可能。	Manifest V3 の実装・配布（ストア／企業配布）が必要。UI が一瞬見える可能性は残る。
D. 公式フィードバック提出	「URL 単位でダウンロード通知を抑止する」ポリシー追加を要望（Alt+Shift+I）。	将来的にネイティブ対応が期待できる。	反映時期は不明。即効性はない。

方法 A：Edge の既定設定でバーを無効化（全体無効）

運用手順

1. Edge の「…」メニュー > 設定 > ダウンロード を開く。
2. ダウンロード開始時にメニューを表示 をオフにする。

最も簡単ですが、社内外の区別なく通知が消えるため、セキュリティ運用上は推奨しません。ポリシーでユーザー操作を固定したい場合は、他の方法（B または C）を優先してください。

補足：一部の情報では UI 相当のレジストリ値（例：DownloadNotificationEnabled）に言及がありますが、公式ポリシーとして公開されておらず、将来変更・無効化される前提で捉えてください。サポート対象の方法ではありません。

方法 B（推奨）：カスタム URI プロトコルで Word をダイレクト起動

Edge のダウンロード機構を避け、プロトコルハンドラ → Word の経路で直接開く方式です。リンクが https:// ではなく wordopen: になるため、社内配布のときだけダウンロード UI を回避できます。

手順（ローカル検証）

1. プロトコル登録
   Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\wordopen] @="URL:Word Open Protocol" "URL Protocol"="" [HKEY_CLASSES_ROOT\wordopen\DefaultIcon] @="C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE,1" [HKEY_CLASSES_ROOT\wordopen\shell\open\command] @=""C:\Windows\System32\cmd.exe" /c "C:\Tools\openword.bat" "%1""
2. ランチャー（バッチ）
   @echo off set "uri=%~1" start "" "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE" "%uri%" exit /b 0 PowerShell 版（コンソール非表示）: Start-Process -FilePath "$env:ProgramFiles\\Microsoft Office\\root\\Office16\\WINWORD.EXE" ` -ArgumentList $args[0] -WindowStyle Hidden
3. 社内リンク差し替え
   社内ポータル／SharePoint／社内 Web の a 要素を href="wordopen:https://server/path/file.docx" に変更します。
4. Edge ポリシー（確認ダイアログ抑止）
   Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins] "1"="{"protocol":"wordopen","allowed_origins":["https://server","[https://intra.example.co.jp](https://intra.example.co.jp)"]}" これにより、指定ドメインから wordopen: を起動する際の「このサイトを開きますか？」が表示されなくなります。

展開（GPO／Intune／スクリプト）

GPO：コンピューターの構成 > 管理用テンプレート > Microsoft Edge にて AutoLaunchProtocolsFromOrigins を設定。プロトコル登録（HKEY_CLASSES_ROOT\wordopen）はグループポリシーの「基本設定（レジストリ）」か、スタートアップスクリプトで配布します。

Intune：設定カタログまたは ADMX バックドポリシーで AutoLaunchProtocolsFromOrigins を配布。プロトコル登録は PowerShell スクリプトで行います。

# PowerShell サンプル（昇格必須）
New-Item -Path "HKCR:\wordopen" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen" -Name "URL Protocol" -Value "" -Force | Out-Null
New-Item -Path "HKCR:\wordopen\DefaultIcon" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen\DefaultIcon" -Name "(default)" -Value "$env:ProgramFiles\Microsoft Office\root\Office16\WINWORD.EXE,1" -Force | Out-Null
New-Item -Path "HKCR:\wordopen\shell\open\command" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen\shell\open\command" -Name "(default)" -Value "`"C:\Windows\System32\cmd.exe`" /c `"`"C:\Tools\openword.bat`"`" `"%1`"" -Force | Out-Null

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins" -Name "1" `
-Value '{"protocol":"wordopen","allowed_origins":["https://server","[https://intra.example.co.jp](https://intra.example.co.jp)"]}' -PropertyType String -Force | Out-Null

既存リンクの置換を最小化するテクニック

• 逆リバースプロキシでの URL リライト：社内ポータルの対象リンクに wordopen: を付与するサーバーサイドテンプレート改修。
• DOM 書き換え：社内サイトに限り、JavaScript で a[href$=".docx"] を wordopen: に差し替える（自己責任／将来の保守に注意）。

この方式の評価

ダウンロード UI を通らないため、社内 URL 限定で通知を回避でき、要件を最も素直に満たします。プロトコル起動の初回警告はポリシーで抑止可能。唯一のコストは リンク形式の変更です。

方法 C：Edge 拡張機能でダウンロード UI を抑制

ダウンロード自体は発生させつつ、社内 URL のときだけ履歴を即時消去してバブルの表示時間を最小化します。既存リンクを変更できないときの現実解です。

Manifest V3 の最小実装

{
  "manifest_version": 3,
  "name": "Intranet Word Download Cleaner",
  "version": "1.0.0",
  "description": "社内URLのWordダウンロード履歴を即時消去してダウンロードバブルを見えにくくする",
  "permissions": ["downloads"],
  "host_permissions": ["https://server/*","https://intra.example.co.jp/*"],
  "background": { "service_worker": "bg.js" },
  "action": { "default_title": "Cleaner" }
}

// bg.js
const INTRANET = [/^https:\/\/server\//, /^https:\/\/intra\.example\.co\.jp\//];
function isIntranet(url){ return INTRANET.some(rx => rx.test(url)); }

chrome.downloads.onCreated.addListener(item => {
if (item.finalUrl && isIntranet(item.finalUrl)) {
// すぐ消すと処理レースになるので onChanged でステータス遷移を見て消す
const id = item.id;
const onChanged = delta => {
if (delta.id === id && delta.state && delta.state.current === 'complete') {
chrome.downloads.erase({ id }, () => { /* バブルが閉じるまで僅かに時間差 */ });
chrome.downloads.onChanged.removeListener(onChanged);
}
};
chrome.downloads.onChanged.addListener(onChanged);
}
});

企業配布

• 拡張の強制インストール：ExtensionInstallForcelist に <拡張ID>;<更新URL> を追加。
• 更新運用：社内ストア／ZIP ホストのいずれでも可。テスト OU → 本番 OU の順に段階展開を推奨。

制約：ブラウザの UI を完全に隠すことはできないため、一瞬だけバブルが見える可能性があります。ユーザー体験重視なら方法 B を優先してください。

方法 D：公式フィードバックの送付

「サイト（URL）単位でダウンロード通知の表示/非表示を制御するポリシー」を要望として送付します。Edge の機能改善として採用されれば、今後はネイティブ設定で解決できる可能性があります。

実装上の補足・落とし穴

• AutoOpen 回りの前提
  企業管理下（AD/AAD 参加 or MDM 登録）でないと AutoOpenFileTypes が効かない場合があります。適用対象端末のエンロール状態を確認してください。
• CMD ウィンドウを残さない
  バッチ末尾に exit を入れる、または PowerShell の -WindowStyle Hidden を使うと良いです。
• Office パスの違い
  Office LTSC／Microsoft 365 Apps／32bit/64bit でパスが異なるため、検出ロジックで補正してください（例：$env:ProgramFiles／$env:ProgramFiles(x86) の分岐）。
• HTTPS 強制
  プロトコルハンドラや自動実行は攻撃面を広げます。社内サイトは必ず HTTPS、証明書は信頼済みのものを使用。
• ファイルの実体
  リンクが最終的にクラウド（例：SharePoint/OneDrive の download.aspx）へリダイレクトする場合、finalUrl 側の判定（拡張機能）やプロトコル変換（方法 B）を調整してください。

検証チェックリスト

• ポリシーの反映：edge://policy で AutoOpenFileTypes／AutoOpenAllowedForURLs／AutoLaunchProtocolsFromOrigins を確認。
• 自動起動：社内ページから .docx をクリック → Word が即時起動するか。
• ダウンロード UI：社内リンクではバブルが表示されない（方法 B）、またはすぐ消える（方法 C）こと。
• 外部サイト：一般サイトでは従来どおりダウンロード UI が表示されること（要件 2）。
• ロールバック：プロトコル登録・拡張強制配布を外したとき、元に戻ること。

ユースケース別の最適解

要件／条件	推奨案	理由
完全自動化・社内 URL 限定	方法 B：カスタム URI + AutoLaunch	Edge のダウンロード経路を通さず、通知を根本回避できる。
既存リンクを変えたくない／コード開発が可能	方法 C：拡張機能	リンク無改修・ドメイン条件で挙動分岐可能。
IT 部門裁量で全ユーザー一律に「通知不要」	方法 A：ユーザー設定の固定化	最短で効果。ただし全サイトに影響・可視性低下に注意。

よくある質問（FAQ）

Q1：.docx 以外（.xlsm など）にも適用できますか？
A：AutoOpenFileTypes に対象拡張子を追加し、AutoOpenAllowedForURLs に社内 URL を登録すれば自動起動は可能です。方法 B を使う場合はプロトコル excelopen: など、アプリ別に設けることもできます。

Q2：SharePoint/OneDrive のダウンロード URL は動的で判定しにくいです。
A：方法 B でプロトコルに統一するのが安定です。方法 C の場合は finalUrl（最終的なダウンロード元）側でのドメイン・パス判定を行ってください。

Q3：IE モードで開くページでも有効ですか？
A：IE モードは別プロセスですが、リンクが Edge によって処理される時点でプロトコル・拡張のロジックが働きます。個別検証を推奨します。

Q4：自動実行はセキュリティ上危険では？
A：そのとおりです。ドメイン制限・HTTPS 強制・拡張のホワイトリスト化・最小権限を徹底し、標的型メールからの誘導など外部接点では通常のダウンロード通知を残してください（要件 2）。

サンプル .reg／.ps1 一式（コピペで検証）

AutoOpen（Word 自動起動）の基本

Windows Registry Editor Version 5.00

; 社内URLでのみ自動オープンを許可
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoOpenAllowedForURLs]
"1"="[https://server](https://server)"
"2"="[https://intra.example.co.jp](https://intra.example.co.jp)"

; 自動オープンする拡張子を定義（docx と doc）
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoOpenFileTypes]
"1"="docx"
"2"="doc"

AutoLaunchProtocolsFromOrigins（プロトコル起動の無確認許可）

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins]
"1"="{"protocol":"wordopen","allowed_origins":["https://server","[https://intra.example.co.jp](https://intra.example.co.jp)"]}"

プロトコル登録（Word）

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\wordopen]
@="URL:Word Open Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\wordopen\DefaultIcon]
@="C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE,1"

[HKEY_CLASSES_ROOT\wordopen\shell\open\command]
@=""C:\Windows\System32\cmd.exe" /c "C:\Tools\openword.bat" "%1""

PowerShell（存在する Office パスを自動検出）

$paths = @(
  "$env:ProgramFiles\Microsoft Office\root\Office16\WINWORD.EXE",
  "$env:ProgramFiles(x86)\Microsoft Office\root\Office16\WINWORD.EXE"
)
$winword = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $winword) { throw "WINWORD.EXE が見つかりません" }

New-Item -Path "HKCR:\wordopen" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen" -Name "URL Protocol" -Value "" -Force | Out-Null
New-Item -Path "HKCR:\wordopen\DefaultIcon" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen\DefaultIcon" -Name "(default)" -Value "$winword,1" -Force | Out-Null
New-Item -Path "HKCR:\wordopen\shell\open\command" -Force | Out-Null
New-ItemProperty -Path "HKCR:\wordopen\shell\open\command" -Name "(default)" -Value "`"C:\Windows\System32\cmd.exe`" /c `"`"C:\Tools\openword.bat`"`" `"%1`"" -Force | Out-Null

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Edge\AutoLaunchProtocolsFromOrigins" -Name "1" `
-Value '{"protocol":"wordopen","allowed_origins":["https://server","[https://intra.example.co.jp](https://intra.example.co.jp)"]}' -PropertyType String -Force | Out-Null

トラブルシューティング

• AutoOpen が効かない：端末が AD/AAD 参加または MDM 管理下であるか、再起動・サインアウト後に edge://policy へ反映されているかを確認。
• プロトコル初回警告が消えない：AutoLaunchProtocolsFromOrigins の JSON を再確認（protocol 値はコロンなし・小文字、allowed_origins は https:// を含む完全形）。
• 拡張で履歴が消えない：onCreated では早すぎるケースあり。onChanged で state=complete を待ってから downloads.erase を呼ぶ。
• ファイルがクラウドストレージへ転送される：最終 URL（finalUrl）のドメイン／パスで判定。サインインが絡む場合は リダイレクトチェーンをログ出力して調整。

セキュリティと運用のベストプラクティス

• 対象ドメインは最小限に絞る（ワイルドカードは慎重に）。
• プロトコルハンドラは Word のみ許可し、未知のアプリを起動させない。
• 監査：OS／ブラウザのイベントログ、拡張の内部ロギングで どの URL から何が起動されたか を追跡可能に。
• ロールバック手順を標準化（スクリプトで元に戻せる状態に）。

まとめ

現行の Edge には「URL 単位でダウンロードバーを抑止する」ネイティブ設定がないため、運用要件を満たす現実解は B または Cです。既存リンクを変えられるなら B（カスタム URI + AutoLaunch）、変えられないなら C（拡張）。A は全体無効化なので原則非推奨です。社内配布ファイルの体験を損なわず、外部サイトでは可視性と安全性を残す――このバランスを崩さない設計が肝要です。

---

最終的な選択指針（要件別）

要件	推奨案
完全自動化・社内 URL 限定	B. カスタム URI プロトコル + AutoLaunchProtocolsFromOrigins
既存リンクを変えたくない／JavaScript 実装可	C. 拡張機能
IT 部門で全ユーザー一律に通知を消してよい	A. Edge 側で「ダウンロード開始時にメニューを表示」をオフ

参考：社内配布向けのドキュメント雛形

対象ユーザー：社内ポータルから Word 文書を頻繁に開く部門ユーザー

提供内容：「Word 文書は自動で開きます。右上のダウンロード通知は表示されません（社内サイト限定）。外部サイトのダウンロードは従来どおり通知されます」。

問い合わせ先：情報システム部ヘルプデスク（内線 XXXX）