Developer Support Internet Japan Hexo https://microsoft.github.io/jpbrowsers/ All rights reserved 2026, Developer Support Internet Japan 日本マイクロソフトの Microsoft Edge / Internet Explorer に関するサポート情報のブログです。 Japan Browsers Support Team Blog 2026-06-02T06:09:44.947Z Developer Support Internet Japan こんにちは。Developer Support チームです。

今回は、弊社サポートサービスにトラブルシューティングのお問い合わせをいただく際に、事前にご用意いただきたい情報についてご紹介します。
これらの情報をあらかじめご提供いただくことで、現象や環境の理解が深まり、スムーズに対応を開始できます。
ほとんどのケースで必要になる情報なので、最初にご準備いただくと「弊社からの依頼 → お客様の返信 → 情報提供」といったやり取りを省略でき、より早く問題解決に近づけます。
手順はとてもシンプルですので、ぜひご協力ください！

Edge は 最新 3 バージョンがサポート対象です。
例えば、最新が 141 の場合は 141 / 140 / 139 が対象となります。
※ 拡張安定版の場合は偶数の最新 2 バージョン（例：140 / 138）が対象です。
サポートは対象バージョンで発生する問題のみとなりますので、まずはご利用中のバージョンをご確認ください。
対象外の場合は、最新バージョンまたは対象バージョンで再現するか確認をお願いします。

なお、Edge のバージョンは Edge のアドレス バーに edge://version と入力してアクセスした画面で確認することができます。
edge://version

ただ、ご利用環境の要件として、どうしても Edge のバージョン アップができない、といったご事情もあろうかと思います。
その場合、Edge Beta も最新バージョンであればサポート対象となりますので、Edge Beta での現象再現をご確認ください。
Edge Beta は Edge とは異なるアプリとして独立してインストールが可能ですので、既存の Edge には影響を与えることなく、最新状態での動作確認ができます。

各チャネル、サポート対象バージョン、Edge Beta の取得先については以下の公開情報をご確認ください。

   Microsoft Edge チャネルの概要
   https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-channels
   サービスとアシスト サポートのタイムライン
   https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-support-lifecycle#service-and-assisted-support-timeline
   Edge Beta オフライン インストーラー
   https://www.microsoft.com/ja-jp/edge/business/download?msockid=1b5cad06a7ee63340a0ebb52a6cf6272&form=MA13FJ
    Edge Beta 取得先

1. IEDigest ログ

  1. https://aka.ms/iedigest から IEDigest.zip をダウンロード
  2. ZIP を展開し中のiedigest.exe を実行
  3. Reports タブに [Create report archive] にチェックを入れ[Create report] ボタンをクリック
    IEDigest
  4. ツールを実行したユーザーのデスクトップ上に IEDigest フォルダが自動的に作成され、以下のファイル名の ZIP ファイルが生成されます。生成された ZIP ファイルをご提供ください。
    IEDigest__YYYYMMDD_hhssmm_PID.ZIP

2. 診断データ

  1. Edge の右上にある … メニュー内の「ヘルプとフィードバック」-「フィードバックの送信」をクリック
    フィードバックの送信
  2. フィードバックの送信画面で「診断データ」のリンクをクリック
    「診断データ」のリンク
  3. すべての項目のトグルが ON (画像のように青色) になっていることを確認し、「エクスポート」をクリック
    エクスポート
  4. 名前を付けて保存メニューにて、任意の保存場所を指定します。
        作成された exportedDiagnosticLogs.zip ファイルをご提供ください。

3. 現象再現時の動画

現象を視覚的に確認することで理解が深まります。
スマホ撮影でも OK ですが、ここでは PowerPoint の画面録画機能を例に紹介します。

  1. Powert Point を起動して新しいプレゼンテーションを作成します。
    Powert Point を起動して新しいプレゼンテーション
  2. 「挿入」タブを選択し「メディア」から「画面録画」をクリックします。
    画面録画
  3. 画面中央上部に表示されたメニュー内の「領域の選択」をクリックし、録画したい画面の領域をドラッグ & ドロップで範囲指定します。
    総合的に状況を確認したいため、可能であれば録画領域は画面全体が含まれた状態としてください。
    音声が不要な場合は「オーディオ」を無効化してください。
    領域の選択
  4. 「録画」ボタンが活性化されますので、クリックして録画を開始します。
    録画
  5. 現象を再現させます。
  6. 画面中央上部にマウスカーソルを移動させるとメニューが表示されますので、□ をクリックして録画を終了します。
    録画を終了
  7. プレゼンテーションに動画が貼り付けられたことを確認し、プレゼンテーションを保存しご提供ください。

以上でご提供いただきたい情報のご紹介は終了です。

最後に

今回ご紹介した情報は基本的な環境情報の採取です。
これだけで必ず解決できるわけではありませんが、迅速な対応のためにぜひご協力ください。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/edge-basic-info-capture/ 2025-10-16T15:00:00.000Z こんにちは。Developer Support チームです。

今回は、弊社サポートサービスにトラブルシューティングのお問い合わせをいただく際に、事前にご用意いただきたい情報についてご紹介します。
これらの情報をあらかじめご提供いただくことで、現象や環境の]]>

Edge の基本的な情報の採取について 2026-06-02T06:09:44.947Z Developer Support Internet Japan 2023/05/23 本記事公開
2023/08/28 更新 : WSUS による WebView2 Runtime の更新制御を追記しました。
2024/03/04 WebView2 Runtime に依存する Microsoft 365 製品を追記しました。

みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

今回はお客様からよくご質問をいただく Microsoft Edge WebView2 (以下 WebView2) のお話をお伝えしたいと思います。

最近では WebView2 Runtime を利用する WebView2 アプリケーションも増えており、その折に端末に勝手に WebView2 Runtime がインストールされているのはなぜか？といったお問い合わせをよくいただきます。 WebView2 Runtime と WebView2 アプリケーションの違いや、そもそも Microsoft Edge とはなにが違うのかなど、よくいただく質問についてこちらのブログにまとめました。

WebView2 に関しては下記 URL 関連するドキュメントにおいて、WebView2 のサンプル アプリケーションや WebView2 のアーキテクチャなどを詳述しています。
本ブログにおいて不明な点がございましたら、まずはドキュメントをご確認いただけますと幸いです。

Introduction to Microsoft Edge WebView2

※ なお全てのドキュメントは英語版のリンクを掲載しています。 /en-us/ の記述を /ja-jp/ にすることで日本語版のドキュメントを参照できます。日本語版は自動翻訳のためアップデートが遅れることがあります。最新の情報については英語版のドキュメントをご参考ください。

目次

WebView2 と WebView2 Runtime と WebView2 SDK はどのような違いがありますか

「WebView2」 はご利用いただいているデスクトップ アプリケーションなどに、Edge のブラウザー機能を埋め込むためにご利用いただける機能 (コントロール) です。
WebView2 を利用することで、例えばネイティブ アプリ内でブラウジングの機能を実装したり、またネイティブ アプリより WebView2 のブラウザーを操作するなどが可能になります。

詳細は Introduction to Microsoft Edge WebView2 をご確認ください。

The Microsoft Edge WebView2 control allows you to embed web technologies (HTML, CSS, and JavaScript) in your native apps.

例えば以下は弊社が公開している WebView2 のサンプル アプリケーション です。画像を見るとわかるように、Bing のブラウザー画面にもかかわらずアプリは Edge などではなく、デスクトップ アプリケーションになっています。

WebView2 Sample Application

上記のようにデスクトップ アプリケーションにブラウザー画面を埋め込むことができ、なおかつよく見ると、Back や Refresh、GO やアドレス バーなどがブラウザー画面の外にあることがわかります。これは WebView2 の API を利用することで、デスクトップ アプリケーション側からブラウザー コンポーネントの操作を行えることを意味します。つまり、デスクトップ アプリケーションからブラウザー コンポーネントを操作したり、コンポーネントで表示された内容にもとづいてアプリを処理させたりできます。

一般に WebView2 の機能を利用したアプリケーションを 「WebView2 アプリケーション」 と表現します。

過去の IE の WebBrowser コントロールの場合は、通常 C:\Windows\System32 配下に存在する、shdocvw.dll や mshtml.dll 等の DLL を利用して動かすため、WebBrowser コントロールを利用するアプリケーションのために端末になにかを追加でインストールすることは必要ありませんでした。
一方で WebView2 についてはアプリケーションを実行する上で必要とするモジュールを別途インストールする必要があります。

WebView2 アプリケーションを実行するために必要になるのが「WebView2 Runtime」というランタイムです。

そのため WebView2 アプリケーションを利用するためには、WebView2 Runtime が端末にインストールされている必要があります。

クライアントに WebView2 Runtime が存在すれば、WebView2 アプリケーションを問題なく実行することができます。

一方で WebView2 アプリケーションを開発の視点に立ちますと、アプリケーションに WebView2 の機能を埋め込む必要があります。
そのために利用するのが 「WebView2 SDK」 です。

SDK については Release Notes for the WebView2 SDK のドキュメントをご確認ください。

上記をまとめますと以下になります。

  • 「WebView2」 はデスクトップ アプリケーションにブラウザー機能を導入できるコントロール
  • 「WebView2 Runtime」 は WebView2 アプリケーションの実行に必要なクライアントにインストールされるモジュール
  • 「WebView2 SDK」 は開発者がアプリケーションに WebView2 を埋め込むために利用するコンポーネント

※ 下記「注意」は発展的な事項のためこちらのブログを通読し理解いただいた上でご確認ください。

注意：
固定バージョン配布モードを利用すれば、WebView2 アプリケーション内に、WebView2 Runtime の実行可能ファイルを同梱させることも可能なため、必ずしも WebView2 アプリケーションを利用するために、端末に WebView2 Runtime が必須というわけではありません。
ただし WebView2 Runtime 自体のファイルサイズは 130~140 MB にもなるので、アプリケーションの大きさを小さく保ちたいなどを理由として、端末に WebView2 Runtime がインストールされていることを前提として WebView2 アプリケーションを作成することが一般的です。
なお Windows 11 においては最初から WebView2 Runtime がインストールされており、アンインストールが行えない様になっています。

WebView2 はどのようなアプリケーションで利用されますか

Microsoft 製品においても様々な場面で利用されています。

Understanding the Office Add-ins runtime において述べられておりますように 16.0.13530.20424 以降の Office においては WebView2 Runtime が存在する場合は WebView2 をアドインに利用されます。

Office released support for WebView2 starting with Office version 16.0.13530.20424. This means if you have Office version 16.0.13530.20424 or later, and have the WebView2 runtime installed, Office will use WebView2 as the runtime for add-ins. This is an incredibly exciting step for the Office Platform — not only because of all the benefits of WebView2, but also because it provides for uniformity of the runtime for add-ins across various versions of Windows.

その他にも、Microsoft Edge WebView2 and Microsoft 365 Apps に述べられておりますように M365 アプリにおいて、ルーム検索やミーティング インサイトなどにおいて WebView2 が利用されている旨が記載されています。

Microsoft 365 Apps is starting to provide new or improved features that rely on Microsoft Edge WebView2. For example, the Room Finder and the Meeting Insights features in Outlook. WebView2 uses Microsoft Edge as a rendering engine to display web-based features in a desktop application.

New Teams について

Introducing the new Microsoft Teams client にて述べられているように、新しい Teams に置いてはWebView2 Runtime が利用されるようになっています。

The new Teams client uses the Evergreen version of Microsoft Edge WebView2 to ensure Teams client is always up to date with the latest fixes and improvements available in Microsoft Edge and Chromium.

また、New Teams での WebView2 Runtime の前提条件は最新版であることが述べられています。

Upgrade to the new Teams using policies

Webview2Update to the most current version. Learn more: Enterprise management of WebView2 Runtimes

Dynamics 365 Commerce について

Dynamics 365Commerce も WebView2 Runtime を利用いたします。

Store Commerce app において以下が述べられています。

The Store Commerce app is a Windows Presentation Foundation (WPF) shell application for Windows that uses the Microsoft Edge WebView2 control to render Store Commerce for web.

Power BI Desktop について

Power BI Desktop についても Get Power BI Desktop において WebView2 Runtime を利用する旨の記載がございます。

Minimum requirements
The following list provides the minimum requirements to run Power BI Desktop:
(…中略…)
WebView2: If WebView2 wasn’t automatically installed with Power BI Desktop or if it was uninstalled, download and run the installer for WebView2.

また Power BI についてはサポートチームの Blog でも詳細にご案内しておりますのでご参考ください。

Power BI Desktop のコンポーネント変更について(Webview2)

その他基本的な考え方について

今後も WebView2 Runtime に依存する製品が増える場合がございます。

すでに Windows11 においては WebView2 Runtime は標準搭載されており、Windows10 においても本来は自動的にインストールがなされるものであるため、
依存するアプリ等の懸念がございます場合は、WebView2 Runtime のインストールをしていただくことでご安心いただけるかと存じます。

WebView2 アプリケーションと WebView2 Runtime の互換性について

前述したように WebView2 アプリケーションは WebView2 SDK によって WebView2 の機能をアプリケーションに取り込んでいます。

そのため、例えば古い WebView2 SDK と 新しいバージョンの WebView2 SDK を比較すると、新しいバージョンにしかない API が存在することもあります。

そのため例えば以下のような組み合わせの場合については、(1) と (2) はそれぞれで問題なく動作はします。

  • (1) ◯ 古い WebView2 SDK 利用アプリ <=> 古い WebView2 Runtime
  • (2) ◯ 新しい WebView2 SDK 利用アプリ <=> 新しい WebView2 Runtime

しかし、新しい WebView2 SDK の機能を利用したアプリケーションを古い WebView2 Runtime で実行しようとした場合、クライアントに存在する Runtime がその API を認識できないために実行に失敗し、アプリケーションがクラッシュする可能性 (4) があります。

  • (3) ◯ 古い WebView2 SDK 利用アプリ <=> 新しい WebView2 Runtime
  • (4) ✕ 新しい WebView2 SDK 利用アプリ <=> 古い WebView2 Runtime

一方で (3) の古い WebView2 SDK のアプリケーションを新しい WebView2 Runtime で実行させる場合は特に問題は発生しません。これは WebView2 Runtime 自体が WebView2 SDK の API の前方互換性を保っているためです。

なおこの前方互換性として記事作成時において担保されているのは WebView2 Runtime 86.0.616.0 (対応する SDK は 1.0.622.22) までです。つまり SDK が 1.0.622.22 において作成されたアプリケーションは、(3) の例のように、それから先の WebView2 Runtime のいずれでも動作させることが可能です。

Minimum version of the browser or Runtime to load WebView2

To load WebView2, the minimum version of Microsoft Edge or the WebView2 Runtime is 86.0.616.0.
The minimum version to load WebView2 only changes when a breaking change occurs in the web platform.

WebView2 SDK に対応する WebView2 Runtime のバージョンはそれぞれの SDK のリリース ノートにおいて記載があります。

https://learn.microsoft.com/en-us/microsoft-edge/webview2/release-notes?tabs=dotnetcsharp

例えば SDK 1.0.1722.32 の機能に完全に対応するランタイムについては 112.0.1722.32 以上であることが必要となります。

For full API compatibility, this version of the WebView2 SDK requires WebView2 Runtime version 112.0.1722.32 or higher.

WebView2 Runtime と WebView2 SDK のバージョンの関係性について

WebView2 SDK より作成したアプリケーションが、どの WebView2 Runtime 以上で完全互換性を持つかについては、バージョン情報のビルド バージョンを確認することで簡易的に判断ができます。

SDK および Runtime のバージョンは AA.BB.CC.DD で表記され、AA.BB.CC.DD のバージョンについて、AA は「メジャー バージョン」、BB は「マイナー バージョン」、CC は「ビルド バージョン」、DD は 「パッチ バージョン」です。

以下の Chromium のドキュメントと同様の表記になります。

https://www.chromium.org/developers/version-numbers/

この内の CC の部分がビルド バージョンであり、下記のドキュメントにあるように Runtime のビルド バージョンが SDK のバージョンよりも高い場合は完全互換性を持ちます。

Forward compatibility of APIs

For example, if an API is introduced in SDK 1.0.900.0, that API would work with Runtime 94.0.900+.0, but not with Runtime 90.0.700.0.

WebView2 のサポート範囲について

WebView2 は下記のドキュメントにあるように Edge とサポート範囲は同様です。

Microsoft Edge WebView2

WebView2 follows the same Lifecycle as Microsoft Edge.

Edge のサポート バージョンは下記ブログに詳述していますが Edge 最新版バージョン - 2 までであり、WebView2 Runtime も同様に 最新版バージョン - 2 までとなります。

https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#Edge-%E3%81%AE%E7%A8%AE%E9%A1%9E%E3%81%A8-Edge-%E3%81%AE%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E7%AF%84%E5%9B%B2%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

WebView2 Runtime のインストーラーについて

Distribute your app and the WebView2 Runtime において詳細を述べております。

配布方法としては主に大きく 2 つあります。
1 つは 「Evergreen 配布モード」、もう 1 つが 「固定バージョン配布モード」 です。

Evergreen 配布モードは、オンライン インストーラーまたはオフライン インストーラーによって WebView2 Runtime を配布する方法です。

Evergreen 配布モードによって配布した WebView2 Runtime は通常自動更新によって最新版に更新され続けます。

なお Windows 11 においてはすでに WebView2 Runtime がプリインストールされており、Evergreen 配布モードによって配布された WebView2 Runtime と同様に自動更新によって管理されます。

弊社としては Evergreen 配布モードによる WebView2 Runtime のインストール、更新管理を推奨しています。

固定バージョン配布は、WebView2 アプリケーション自体に WebView2 Runtime を同梱する方法です。WebView2 アプリに WebView2 Runtime を一緒にパッケージしてアプリケーションを作成し、そのアプリをクライアントに配布します。

固定バージョンとあるように、アプリケーションに同梱された WebView2 Runtime のバージョンは固定化されているため、WebView2 Runtime のサポート期間は 最新版 - 2 であることからも、数ヶ月おきに、新しい WebView2 Runtime を含めたアプリケーションに更新する必要があります。

固定バージョン配布のメリットとして、アプリケーションに WebView2 Runtime が同梱されているため、クライアントにおいて WebView2 Runtime を別途インストールする必要がありません。

一方でデメリットは以下です。

  • 合計で 100 数十 MB ほどある WebView2 Runtime を同梱することで、アプリケーション全体のファイル サイズが肥大すること。
  • アプリケーションが利用する WebView2 Runtime のバージョンは自動的に更新されないため、サポートが切れたバージョンを利用することは、サポートを受けられないことに加えて、セキュリティの問題が懸念されること。

固定バージョン配布の場合 WebView2 Runtime の更新のために、数ヶ月ごとにアプリケーションを配布し直す必要があるため、通常は Evergreen 配布モードをご利用いただくことが一般的です。

Evergreen 配布モードの WebView2 Runtime のダウンロードについて

WebView2 Runtime の Evergreen 配布についてはいくつかの方法があります。 詳細は Understanding the options at the Runtime download page をご確認ください。

Download the WebView2 Runtime のダウンロードページを確認すると、Evergreen 配布モードのためのインストーラーとして 「Evergreen ブートストラッパー」および「Evergreen スタンドアローン インストーラー」を確認できます。

Evergreen ブートストラッパーは WebView2 Runtime のオンラインインストーラーです。ブートストラッパー自体は軽量ですが、実行時に Edge のエンドポイント から最新の WebView2 Runtime 本体をインターネット上からダウンロードします。

そのためインターネット上のエンド ポイントへの接続の許可および、100 数十 MB のファイルをダウンロードするため、そのダウンロード負荷を許容頂く必要があります。

また Evergreen ブートストラッパーは、自身を別のアプリケーションから実行させるためのリンクなども提供しています。これは例えば WebView2 アプリケーションが、アプリケーションを実行する端末に WebView2 Runtime がインストールされていない場合に、自動的にインストールさせられるようにするなどを想定しています。

Evergreen スタンドアローン インストーラーは WebView2 Runtime のオフライン インストーラーです。オフライン インストーラー自体に WebView2 Runtime 本体が内蔵されているため、オフライン インストーラーを起動しても、外部への通信は発生せず、インストールが可能です。

Evergreen スタンドアローン インストーラーは最新版の WebView2 Runtime しか提供はしていません。そのため過去バージョンの WebView2 Runtime は取得できませんのでご注意ください。

固定バージョン配布モードの WebView2 Runtime のダウンロードについて

固定バージョン配布の場合、Download the WebView2 Runtime のサイトの Fixed Version をアプリケーションに埋め込む必要があります。

WebView2 Runtime の自動展開について

上述いたしましたように WebView2 Runtime はさまざまな Microsoft 製品での導入が進んでいることもあるため、2023 年 1 月 16 日以降ではすべての Windows 10 デバイスに対して WebView2 Runtime が自動的に展開されるようになっています。

WSUS による WebView2 Runtime の更新制御

WSUS による更新管理については弊社 WSUS チームより以下のブログがございますのでご確認いただけますと幸いです。

WSUS による更新管理:
https://jpmem.github.io/blog/wsus/2023-03-27_01/

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/webview2-faq/ 2024-03-03T15:00:00.000Z 2023/05/23 本記事公開
2023/08/28 更新 : WSUS による WebView2 Runtime の更新制御を追記しました]]> WebView2 のよくあるご質問 2026-06-02T06:09:44.972Z Developer Support Internet Japan 更新履歴:
2023/01/06 更新: UpdateDefault によって WebView2 の更新制御が行えなくなった旨
2023/04/27 更新: WebView2 Runtime の強制インストールについては Install ポリシーの設定が必要な旨
2023/09/21 更新:ドメイン管理外の端末での更新制御方法について加筆
2024/02/27 更新: Edge や WebView2 Runtime がオフラインインストーラーで失敗する場合の切り分けについて

みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

今回はお客様からよくいただく 「Edge の更新制御」と 「Edge のサポート範囲」のお話をお伝えしたいと思います。

通常 Microsoft Edge (以下 Edge と呼称) は自動更新によってバージョンが管理されます。

端末には Edge の更新管理用モジュールがインストールされています。モジュールはインターネットを経由してアップデートを確認すると、最新のファイルをダウンロードして、Edge を自動的に更新します。これにより常に最新版の Edge をご利用いただけます。

一方で、ユーザーによっては、ダウンロードによるネットワークの帯域負荷への問題や、ストレージが圧迫されるなどの問題から、アップデートを制御したいというご要望をいただくことがあります。また、勝手にアップデートがされることが運用上困ってしまう方もいらっしゃるかと思います。

こうしたアップデートに関する弊社のデザインとお客様のご要望のミスマッチはなぜ起きるのか。それは弊社の Edge に関するセキュリティへの考え方に理由があります。

目次

なぜ Edge は自動更新を行うのか

弊社の Microsoft Edge をはじめ Google Chrome などブラウザは常にセキュリティの脅威にさらされています。大多数のユーザーが利用するアプリケーションの脆弱性を悪用すれば、大多数のユーザーに影響を与えることができます。ブラウザ アプリケーションは絶えずこうしたセキュリティの脆弱性の対応を行い、修正したアプリケーションを提供する必要があります。

しかし一方で、ブラウザは莫大なユーザーが利用していることから、すべてのユーザーが適切に脆弱性を確認して修正済みの Edge を利用してくれるとは限りません。

例えば、問題が発生する度に弊社サイトにアクセスしてダウンロードを行い、インストーラーを起動しなければアップデートされないとするといかがでしょうか。

どのように脆弱性が危険であるかをお伝えしたとしても、すべてのユーザーがそうしたアップデートをおこなうとは限りません。

そのため、ユーザーに Edge を管理する負担をかけないようにするために、ユーザーの端末には Edge の更新管理用モジュールを常駐させ、モジュールが新しい Edge を確認したら自動更新するようにデザインをしています。

こちらによりユーザーは手動でインストールをすることなく、問題があれば勝手にブラウザが更新されることで、安全なブラウザ体験をお楽しみいただくことができるようになっています。

こうしたデザインは弊社としても脆弱性の対応やブラウザの不具合の修正などを簡単に行うことができ、開発を効率的に進めることができます。

Edge の種類と Edge のサポート範囲について

Edge は以下 5 つのチャネルとしてご提供しています。

  • Stable 版
  • Extended Stable 版
  • Beta 版
  • Dev 版
  • Canary 版

通常ユーザーにご利用いただくのは Stable 版か Extended Stable になります。

例: Stable 版が 100 とすると、Beta が 101、Dev が 102、Canary が 103 になり、Stable が 1 繰り上がれば基本的にすべてのバージョンが 1 繰り上がります。

チャネルの詳細については以下をご確認ください:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-channels
※ なお全てのドキュメントは英語版のリンクを掲載しております。 /en-us/ の記述を /ja-jp/ にすることで日本語版のドキュメントを参照可能です。日本語版は自動翻訳のかつアップデートが遅れていることがあります。最新の情報を確認するためには英語版のドキュメントをご参考いただけますと幸いです。

このうち、弊社サポートにてお問い合わせを承ることができるのは Stable 版, Extended Stable 版 と Beta 版になります。

Beta 版、Dev 版、Canary 版などは Stable 版に実装するための機能について先行実験を行い、不具合の修正や機能要望を試すために利用しております。

弊社としてサポートする Edge のバージョンは Stable 版においては “最新版のバージョン - 2” までになります。 Extended Stable 版においては “最新の偶数バージョン - 2”までがサポート範囲となっています。

サポート ライフサイクルの詳細については以下をご確認ください:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-support-lifecycle

例1 最新版が 101 のときのサポート範囲:

  • Stable 版は 99, 100, 101 までがサポート範囲
  • Extended Stable 版は 101 が奇数であることからもっとも近い偶数の 100 を基準として、98, 100 がサポート範囲

例2 最新版が 102 のときのサポート範囲:

  • Stable 版は 100, 101, 102 までがサポート範囲
  • Extended Stable の場合は 100, 102 がサポート範囲

Edge のバージョンの読み方について

Edge のバージョン管理は以下の Chromium のドキュメントと同様です。

AA.BB.CC.DD のバージョンについて、AA は「メジャー バージョン」、BB は「マイナー バージョン」、CC は「ビルド バージョン」、DD は 「パッチ バージョン」となります。

https://www.chromium.org/developers/version-numbers/

Edge のバージョン 100.0.1185.44 を例にして考えますと、メジャー バージョンは 100, マイナーバージョンは 0, ビルド バージョンは 1185, パッチ バージョンは 44 になります。

Edge のバージョン アップデートの頻度について

Stable 版 のメジャー バージョン アップデートは 約 4 週間 になります。この “約” という点に注意が必要です。あくまでも目安であり多少のズレが発生する場合があります。

リリース スケジュールの詳細については以下をご確認ください:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule

Stable 版を考えますと、101 のバージョンが登場してから、その 101 のサポートが終了するのは、104 が出てくる際になります。
よって 101 が登場してから、約 4 週間後に 102, その約 4 週間後に 103, その約 4 週間後に 104 が出てきますので、通常 Edge の最新版として提供されるバージョンのサポート期限は 約 12 週間 となります。

あくまでも “約” であり、Edge のサポート条件は最新版 - 2 までとご理解ください。

パッチ バージョン アップデートより細かい頻度で行われますが、こちらはサポート範囲には関係しません。

準備が整えば提供され、提供されたバージョンについてはリリース ノートに記述されます。

Stable 版のリリースノート:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Extended Stable 版について

Extended Stable 版では 最新版の 102 が出ると、その 102 は次に 106 が出るまではサポート範囲になるため、約 16 週間がサポート範囲になります。Stable 版よりも約 4 週間ほどサポート期限が長くなります。

最新版の確認方法

最新版がいつリリースされるのかなどの情報は以下 2 つをご確認いただけますと幸いです。

リリーススケジュール:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-release-schedule

Stable 版のリリースノート:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel

Edge のインストールおよび更新制御方法について

Edge の更新を制御できるのは、対象がドメイン管理下の端末のみになります。
※ ここにおいてのドメイン管理下とは、Intune や Active Directory, Azure Active Directory の制御下であることを指します。

ドメイン環境においてはドメインを管理する管理者がおり、端末へのグループ ポリシーやレジストリの配布を行えることから、管理者において適切に Edge のバージョンも管理されることが想定されるため、Edge の更新管理を行うことが可能です。

一方で、ドメイン管理下外の端末においては弊社としてサポートしている更新制御の方法はございません。

こちらは前述いたしましたように、ユーザーが Edge の更新を止めてしまうことにより脆弱性が放置されるなどのリスクを避けるためになります。

ドメイン管理下においては弊社がサポートしている更新管理方法は以下のグループ ポリシー またはレジストリの設定になります。
※ MECM/SCCM や WSUS による制御については後述します。
※ ドメイン管理外の端末においては下記の設定を行っても、設定は無視され自動更新されますのでご注意ください。

    1. Edge のインストールの制御
    1. WebView2 のインストールの制御
    1. Edge の更新の制御
    1. WebView2 の更新の制御
    1. 更新タイミングについての制御
    1. Edge の自動更新用のモジュールの更新の制御

1) Edge のインストールの制御

すべてのチャネルを制御する場合は、以下の InstallDefault のポリシーによって制御可能です。

InstallDefault (インストールの既定の動作を許可する):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#installdefault

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: InstallDefault
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / インストールが無効になっています
  • 値: 1 / 常にインストールを許可する(推奨)

個々それぞれのチャネルを制御するには以下の Install ポリシーによって制御可能です。

Install (インストールを許可する):
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-update-policies#install

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • キーの値:
  • (Stable): Install{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • (Beta): Install{2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}
  • (Dev): Install{0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}
  • (Canary): Install{65C35B14-6C1D-4122-AC46-7148CC9D6497}
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / インストールが無効になっています
  • 値: 1 / 常にインストールを許可する (推奨)
  • 値: 4 / 常にコンピューター全体へのインストールが許可されますが、ユーザーごとのインストールは許可されません。
  • 値: 5 / 強制インストール (コンピューター全体)
  • 値: 6 / 強制インストール (ユーザーごと)

2) WebView2 のインストールの制御

以下で設定可能です。

Install (インストール (WebView)):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#install-webview

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • キーの値: Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / インストールが無効になっています
  • 値: 1 / 常にインストールを許可する (推奨)
  • 値: 4 / 常にコンピューター全体へのインストールが許可されますが、ユーザーごとのインストールは許可されません。
  • 値: 5 / 強制インストール (コンピューター全体)


※ 2023-04-27 追記：
WebView2 Runtime に依存するアプリケーションが増えてきたこともあり、弊社は過去 Unmanaged 環境においての WebView2 Runtime の強制展開 および Managed 環境においての WebView2 Runtime の強制展開 をアナウンスしてきました。

Managed 環境においても、2023年 1 月 16 日以降においては WebView2 Runtime が自動配布される可能性があるため、もし当該の強制展開を抑止したい場合は、ドキュメントにございますように Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} のポリシーを 0 (無効) にしていただく必要がございますのでご注意ください。(なお Microsoft としては Install を無効化し WebView2 Runtime がインストールされない場合、WebView2 Runtime に依存するアプリケーションが強制終了したり、起動できないといった問題を引き起こすこともあるため推奨はしておりません。)

1
2
3
As a follow-up step to the Consumer rollout, we are also announcing that after January 16th, 2023, we will start rolling out WebView2 Runtime to managed/domain-joined devices with Windows 10 April 2018 Update or later.
(…中略…)
You may also opt out of the rollout by configuring the WebView2 install policy, although in most cases we do not recommend so as disabling WebView2 Runtime installation may severely impair the normal usage of WebView2 applications such as Outlook on your tenants’ device.

なお、当該の Install{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} を 0 に設定した場合は、WebView2 Runtime のオフライン インストーラー、オンライン インストーラーにかかわらずインストールのブロックが行われますのでご注意ください。

どのような方法を取るにせよ WebView2 Runtime をインストールしたい場合は、当該のポリシーを 1 (有効) または未設定にしていただく必要がございます。

また、インストールのポリシーを無効化しても、すでにインストールされている環境の更新を制御するものではございません。その場合は Update{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} による制御が必要になりますので、ご注意ください。

2023-04-27 追記終了

3) Edge の更新制御

すべてのチャネルを制御する場合は以下の UpdateDefault のポリシーによって制御可能です。

UpdateDefault (更新ポリシーのオーバーライドの既定値):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#updatedefault

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: UpdateDefault
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / 更新を無効にする (すべてのチャネルのアップデートを停止します。)
  • 値: 1 / 常に更新を許可する (推奨) (通常の自動更新になります。)
  • 値: 2 / 手動更新のみ (edge://settings/help による手動更新のみ可能になります。)
  • 値: 3 / 自動サイレント更新のみ (Edge の更新モジュールによる自動更新のみ可能になります。)

個々それぞれのチャネルを制御するには以下の Update ポリシーによって制御可能です。

Update (更新ポリシーのオーバーライド):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#update

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前:
  • (Stable): Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • (Beta): Update{2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}
  • (Dev): Update{0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}
  • (Canary): Update{65C35B14-6C1D-4122-AC46-7148CC9D6497}

詳細:

  • 値: 0 / 更新を無効にする (すべてのチャネルのアップデートを停止します。)
  • 値: 1 / 常に更新を許可する(推奨) (通常の自動更新になります。)
  • 値: 2 / 手動更新のみ (edge://settings/help による手動更新のみ可能になります。)
  • 値: 3 / 自動サイレント更新のみ (Edge の更新モジュールによる自動更新のみ可能になります。)

4) WebView2 の更新制御

以下で設定可能です。

Update (WebView) (更新ポリシーのオーバーライド):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#update-webview

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • キーの値: Update{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / 更新を無効にする
  • 値: 1 / 常に更新を許可する


※ 2023-01-06 追記：
なお、Edge の更新用モジュールである MicrosoftEdgeUpdate.exe は、これまで UpdateDefault を 0 にしていた場合 Edge ブラウザーだけではなく WebView2 の更新も抑止しましたが、1.3.171.39 以降は UpdateDefault を 0 に設定していてもWebView2 の更新を抑止しなくなりました。

WebView2 の更新を抑止したい場合は上記の Update{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5} を 0 に設定ください。

2023-01-06 追記終了

Edge の更新タイミングの制御方法について

Edge に関連するものとして以下 3 つがあげられます。それぞれについて更新タイミングを制御することができます。

  • ① Edge アプリケーション (Stable 版、Beta 版など)
  • ② WebView2 runtime
  • ③ Edge の更新管理用モジュール (実体としては MicrosoftEdgeUpdate.exe やそれに関連するサービスやタスク)

Edge の更新の流れについて

① Edge や ② WebView2 runtime をインストールすると、同時に ③ Edge の更新管理用モジュールがインストールされます。

この更新管理用モジュールは MicrosoftEdgeUpdate.exe や関連するタスク、サービスなど様々なもので構成されております。Windows の更新管理が Windows Update によって管理がされるのと同様に、Edge についてはこの更新管理用モジュールによって管理が行われます。

※ よくある誤解として Edge のバージョンアップデートを Windows Update で行う方法がわからないというご質問をいただくことがあります。 Edge の更新管理用モジュールと Windows Update とは直接的な関係はありません。 Windows Update を契機として Edge のバージョンが上がるということは基本的にありませんのでご安心ください。

流れは以下の様になります。

  • Edge の更新管理用モジュールがインストールされると、関連するタスクによって通常 1 時間置きに更新チェックフラグが ON になっているかを確認し、ON の場合は次に進みます。—1⃣
  • フラグが ON の場合は実際にインターネット上に公開されている Edge のサーバーへ更新チェックを行い、次に進みます。—2⃣
  • サーバーに新しい Edge や WebView2 runtime、Edge の更新管理用モジュール(MicrosoftEdgeUpdate.exe) が存在し、現在のバージョンがそれよりも古い場合はダウンロードを行い、自動的にアップデートを行います。 —3⃣

なお以下が補足になります。

  • 2⃣ のチェックを行うと、後述する UpdatesSuppressed の指定された時間または既定であれば 595 分間更新チェックフラグを OFF にします。(つまり 2⃣ まで到達すると、約 10 時間は 1⃣ から 2⃣ に進めません。)
  • 更新チェックは端末起動時やユーザーログイン時などに遅延実行される場合がございます。判定条件としては 1 時間起きの更新チェックがシャットダウン等を理由として行われない場合などですが、詳細は内部仕様につき開示しておりません。

以下イメージのための図解になります。

Edge の更新タイミングについて

※ 上記の図は正常な端末での動作であり、異常な状態の端末では図通りの更新チェックが行われない可能性もございます。
※ インストール後 30 分に更新チェックが起きる想定ですが、実際は Edge をインストール後 0~59 分の間の一意のタイミングです。
※ 遅延実行によって、端末を一斉に同じ時間に起動することによりダウンロードが多重で発生し、ドメイン内のネットワーク帯域が圧迫される可能性はあります。
※ Edge はどのような状況でも Edge に関連するモジュールを最新に保つために様々な仕組みによって重層的に制御しているため、必ずしも上記の図解通りの更新を行わない可能性もございます。

具体的な更新タイミングについての制御方法について

グループ ポリシーやレジストリによって 1⃣ のフラグの条件を詳細に設定できます。

5) アップデートできない時間帯を指定する方法

UpdatesSuppressed は、1⃣ のフラグ チェックについて、ある時間帯は必ず OFF にすることができます。

UpdatesSuppressed (自動更新チェックを停止する 1 日あたりの時間帯):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#updatessuppressed

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前:
  • UpdatesSuppressedDurationMin
  • UpdatesSuppressedStartHour
  • UpdatesSuppressedStartMin
  • 値の種類: REG_DWORD

値の範囲:

  • UpdatesSuppressedDurationMin : 1 ~ 960 / (アップデートさせない分数を指定します)
  • UpdatesSuppressedStartHour : 0 ~ 23 / (OFF にする開始時間の Hour を設定します)
  • UpdatesSuppressedStartMin : 0 ~ 59 / (OFFを にする開始時間の Minutes を設定します)

6) 更新チェック後の次の更新チェックまでの最低猶予時間を指定する方法

AutoUpdateCheckPeriodMinutes は、2⃣ が実行されてからどれくらいの間 1⃣ のフラグを OFF にするかを指定できます。

AutoUpdateCheckPeriodMinutes (自動更新チェック期間のオーバーライド):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#autoupdatecheckperiodminutes

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: AutoUpdateCheckPeriodMinutes
  • 値の種類: REG_DWORD

詳細:

  • 値の範囲: 0 ~ 43200

UpdateSuppressed および AutoUpdateCheckPeriodMinutes が設定された場合

UpdatesSuppressed および AutoUpdateCheckPeriodMinutes 両方が設定されている場合は、それぞれの条件に適合したフラグが ON のときのみ更新が可能です。

端末がシャットダウンしていた場合は、端末が起動した場合やユーザーがログインした場合などに 1⃣ が遅延実行されます。

例えば、毎日 X 時 20 分のタイミングで 1⃣ のフラグ チェックが行われる場合において、端末が 0:00 にシャットダウンし 10:40 に端末を起動した場合、10:40 のタイミングで 1⃣ が行われます。その後 X 時 20 分のタイミングで 1⃣ のフラグ チェックが行われます。

遅延実行は Edge のインストールがシステム インストールの場合は端末起動後に、ユーザー インストールの場合はログイン後に行われますが、詳細については公開していません。

あくまでも UpdatesSuppressed および AutoUpdateCheckPeriodMinutes によって更新タイミングの制御が可能であるとご理解いただけますと幸いです。

※ 上記の遅延実行によって、例えば端末を一斉に同じ時間に起動することによりダウンロードが多重で発生し、ドメイン内のネットワーク帯域が圧迫される可能性はあります。

その場合は端末が一斉に起動するタイミングにおいては UpdatesSuppressed をご設定いただくことで、瞬間的なダウンロードを抑え、それ以降の 1⃣ のチェックは端末によってバラバラですので、負荷をならすことができます。

関連して、Edge の新しいバージョンは段階的なロールアウトによってご提供をしています。すべての端末で一度にアップデート可能な状態になるわけではありません。前提として端末に徐々にアップデートが提供され負荷分散がなされるように配慮しています。

段階的なロールアウトについて:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-progressive-rollout

7) Edge の自動更新用のモジュールの更新の制御

AutoUpdateCheckPeriodMinutes は通常入力しうる値の範囲は 1 ~ 43200 ですが、こちらに 0 をご設定いただくと、Edge および WebView2 および Edge の自動更新用のモジュール の中心である MicrosoftEdgeUpdate.exe 自体の更新はすべて停止いたします。

(※ edge://settings/help より Edge の UI 上から手動で更新は可能です。手動更新を止めたい場合は 3) Edge の更新制御 をご設定ください。)

通常 Edge の自動更新用のモジュールは Edge を管理する上での核となるものになります。
そのため弊社は MicrosoftEdgeUpdate.exe 自体の更新を止めることを推奨しておりません。

https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#autoupdatecheckperiodminutes

1
Set this policy to the value 0 to disable all periodic network traffic by Microsoft Edge Update. This is not recommended, as it prevents Microsoft Edge Update itself from receiving stability and security updates.

なおこちらの設定を頂いていた場合においても Edge の自動更新用のモジュールが古くなりすぎるとセキュリティの脆弱性への対策のためにアップデートを行うモジュールが別途起動を行い、MicrosoftEdgeUpdate.exe が更新される場合がございます。こちらについては詳細は公開しておりません。

その他更新の制御について

MECM/SCCM や WSUS などその他更新の制御については以下をご確認ください。

MECM/SCCM および WSUS による Edge の更新制御

WSUS による更新管理については弊社 WSUS チームより以下のブログがございますのでご確認いただけますと幸いです。

WSUS による更新管理:
https://jpmem.github.io/blog/wsus/2022-04-22_01/

MECM/SCCM による Edge の更新制御方法については以下弊社のドキュメントをご確認いただけますと幸いです。

Microsoft Edge管理:
https://docs.microsoft.com/ja-jp/mem/configmgr/apps/deploy-use/deploy-edge#update-microsoft-edge

ドメイン管理外の端末での更新制御方法について

ドメイン管理下外の端末において弊社としてサポートしている更新制御方法はありません。ドメイン管理下の端末につきましては、本ブログの Edge のインストールおよび更新制御方法について のチャプターにてサポートされた方法をご案内しておりますのでそちらをご利用ください。

本ブログの なぜ Edge は自動更新を行うのか のチャプターで説明したように、弊社は脆弱性や仕様の不具合などの問題への修正をお客様に負担をかけないようにするために、常に最新版の Edge アプリケーションをインターネット上に公開し、ユーザーの端末には Edge の自動管理用モジュールを常駐させ、モジュールが修正済みの Edge を確認したら自動更新するようにデザインをしています。

そのため ドメイン管理下かそうでないかに関わらず Edge の更新管理用モジュールである MicrosoftEdgeUpdate.exe やそれに類するタスク、サービスなど一切の Edge の更新管理用モジュールに変更を加えることは非サポートとなります。

そうした変更を加えたことによって Edge の更新がうまく行うことができなくなったというお問い合わせをいただいた場合は、元の状態に戻していただく、または最悪の場合は端末のクリーンインストールをしていただくなどのご提案をさせていただく場合があります。

また、 Edge の更新を防ぐために以下の弊社ドキュメントに存在するアップデートにかかわるエンドポイントの通信を止めるといった方法についても、ドメイン管理下かそうでないかに依らず弊社としてサポートしていません。通信を止めることによってアップデート以外の Edge の機能への不具合を生じる可能性もありますので、そうして問題が発生したとお問い合わせをいただいた場合はエンドポイントへの通信の許可を再度お願いさせていただく場合があります。

Microsoft Edge エンドポイントの許可リスト:
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-security-endpoints#download-locations-for-microsoft-edge

大変恐縮ではございますが、ドメイン管理外の端末においては皆様にセキュリティとして安全なブラウザ体験をしていただくために更新管理を行わせていないこと、また弊社としてサポートする方法はない旨をご理解いただけますと幸いです。

Edge や WebView2 Runtime がオフラインインストーラーで失敗する場合の切り分けについて

過去に ロールバックに失敗する場合について の記事において、自動更新を挟んでロールバックする場合は問題が発生する可能性の旨を述べておりました。

一方で、ロールバックに寄らない単純な Edge や WebView2 Runtime の更新についても、稀にオフラインインストーラーで失敗する場合がございます。
こちらは端末のインストール状態が正常ではない場合に発生するものであり、下記ドキュメントに記載された手順を実行することにより改善する可能性がございます。

プログラムのインストールまたは削除がブロックされる問題を解決する

当該ツールは、上記の URL から入手できる MicrosoftProgram_Install_and_Uninstall.meta.diagcab を現象発生環境に配置し、ダブル クリックすることで実行することが可能です。
こちらを実施いただくことが可能な場合、まずは検証環境や影響が少ない環境にて実行いただくことを推奨いたします。

トラブル シューティング ツールの利用手順の概要

  1. MicrosoftProgram_Install_and_Uninstall.meta.diagcab をクリックし、
    トラブル シューティング ツールを起動します。

  2. プログラムのインストールまたはアンインストールの選択においては
    [インストール] を選択します。

  3. インストールするプログラムの一覧に Microsoft Edge が存在する場合は、
    これをクリックして次へ進みます。

  4. 以降は画面に表示される指示に従い、ツールを完了してください。

※ なお、ツールの実行に際しては、数時間程度時間を要する場合がございますので、端末の再起動などが求められないように Windows Update 等を済ませた状態で実行します。
※ 実測値として 6 時間程度かかる場合を確認しております。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/ 2024-02-29T15:00:00.000Z 更新履歴:
2023/01/06 更新: UpdateDefault によって WebView2 の更新制御が行えなくなった旨
2020/8/7 更新 : ブラウザーのキャッシュが利用されてキャプチャーに記録されないことを避けるために、InPrivate ブラウズをご利用いただく方法をご案内していますが、InPrivate ブラウズをご利用いただけない場合には、ログ取得前にブラウザーのキャッシュをすべて消去してください。
2023/8/28 更新 : 事前準備と環境変数 SSLKEYLOGFILE 追加時について見直しました。

こんにちは。Developer Support Internet チームの大嶋です！

今回は、Chromium ベースの New Microsoft Edge で動作する Web アプリケーションにて、ネットワークに関連する問題が起こった際に、もしかしたら活用できるかもしれない Wireshark を用いたネットワークトレース取得方法の Tips をご紹介いたします。

今回は Wireshark を利用して New Microsoft Edge で動作するクライアントアプリ側にてトレースを取得します。
なお、本方法では HTTPS の通信をキャプチャすることも可能ですが、TLS のバージョンや暗号化の種類等によっては正常に復号できない可能性もあり、全ての HTTPS 通信を分析できるものではありません。

また、この方法については、Chromium ベースではない旧 Microsoft Edge や Internet Explorer では適用できませんのでご注意ください。
また弊社サポート製品ではございませんが、Google Chrome で動作するクライアントアプリのネットワークトレース取得にも現時点では適用可能な方法と存じます。

0. 前提

1. 事前準備

  1. この Blog の記事の手順や再現するアプリの URL 等をノート帳 (Notepad) で開けるテキストファイル (.txt) などにコピーし開いておきます。

  2. New Microsoft Edge や Google Chrome を含めて、全てのブラウザを閉じます。なお、Microsoft Edge で edge://settings/system にあるスタートアップ ブーストがオンの場合は一時的にオフにしてください。このあとの環境変数の設定変更をすぐに反映させるためです。

  3. ブラウザ以外のアプリも上記の 1. の手順のテキストファイル以外はすべて閉じます。

  4. エクスプローラーにて、キーを保存する任意のフォルダ (C:\tmp) 等を作成しておきます。このフォルダーはこのあとの手順 2 で環境変数 SSLKEYLOGFILE のパスに含めるものです。



2. ユーザー環境変数の設定

ツールバーの検索等から “環境変数を編集” を開き、ユーザー環境変数の “新規” ボタンを
クリックし、”ユーザー変数の編集” にて、以下のように、ユーザー変数の環境変数を設定します。

1
2
変数名 : SSLKEYLOGFILE
変数値 : C:\tmp\ssl.txt


sslkeylogfile



なお、上記で指定したファイル (例 : C:\tmp\ssl.txt) が存在している場合はファイルを削除しておきます。

3. Wireshark の準備

  1. Wireshark を開きます。

  2. キャプチャーしたいインターフェース (イーサネット や wifi、vEthernet など) を選択します。

  3. 左上の赤い四角ボタンを押し、一度、停止しておきます。

STOP



4. New Microsoft Edge による再現とキャプチャ

4-1. New Microsoft Edge を InPrivate ウィンドウで開く。
(タスクバー等の Edge アイコンを右クリックで “新しい InPrivate ウィンドウ” で開けます)
※ InPrivate ブラウズをご利用いただけない場合には、ログ取得前にブラウザーのキャッシュをすべて消去してください。手順は後述の補足をご覧ください。

4-2. Wireshark にて、左上の青いシャークの形をしたボタンを押してキャプチャを開始する。
(保存に関するダイアログが出た場合、”保存せずに続ける” を押しキャプチャを開始する)

START


4-3. New Microsoft Edge にて該当のサイトを開き、素早く事象の再現を行う。

4-4. 再現後、すぐに Wireshark に戻り、左上の赤い四角のボタンを再度押し、停止する。

5. 復号

5-1. Wireshark 上部の [編集] タブを押し、[設定] ボタンを押す。

5-2. 左側の [Protocols] 内の [TLS] を選択する。

5-3. [(Pre)-Master-Secret log filename] の [Browse] ボタンを選択し、C:\tmp\ssl.txt を選択する。


premaster



5-4. [OK] ボタンを押し、復号し、キャプチャした内容を確認します。
(これを行うことで、全てではないものの、HTTPS の通信が復号されたキャプチャを見ることが可能となります)

イメージ :

wireshark



5-5. 必要に応じて、Wireshark 上部の [ファイル] タブを押し、[保存] ボタンから .pcapng 形式で保存します。

5-6. もし私共サポートから本 Blog による情報採取をご依頼された場合は、.pcapng ファイルと C:\tmp\ssl.txt の 2 つ両方とも提供します。

※ なお、Wireshark 自体のツールに関するトラブルシューティングや操作方法等のご質問は 3 rd party 製品となる為、Microsoft のサポートでは承ることができませんのでご了承ください。

6. 後片付け

2 で追加した環境変数 SSLKEYLOGFILE を削除します。

補足 : ブラウザーのキャッシュ消去について

  1. New Microsoft Edge にて edge://settings/clearBrowserData を開きます。

  2. 以下のように設定し、[今すぐクリア] ボタンをクリックします。

clearcache

補足 : netsh でのトレース取得方法

New Microsoft Edge の SSLKEYLOGFILE を用いたネットワークトレースの復号について、ネットワークトレースを取得するツール自体は Wireshark ではなく、netsh でも取得は可能です。

私共サポートから netsh を用いた New Microsoft Edge のトレース取得をご案内することもございますため、以下、簡単にその方法についても記載いたします。

  1. 上部の “1. 事前準備” を行います。

  2. “2. ユーザー環境変数の設定” を行います。

  3. “Wireshark の準備”　は実施せずにスキップ

  4. “4. New Microsoft Edge による再現とキャプチャ” は以下の手順で実施します (上部の 5 はスキップします)

4-1. New Microsoft Edge を InPrivate ウィンドウで開く。
(タスクバー等の Edge アイコンを右クリックで “新しい InPrivate ウィンドウ” で開けます)
※ InPrivate ブラウズをご利用いただけない場合には、ログ取得前にブラウザーのキャッシュをすべて消去してください。手順は上述の補足をご覧ください。

4-2. 管理者権限でコマンド プロンプトを開き、次のコマンドを実行し、キャプチャを開始します。

1
　netsh trace start capture=yes maxSize=2000MB

4-3. New Microsoft Edge にて該当のサイトを開き、素早く事象の再現を行う。

4-4. 次のコマンドを実行して、キャプチャを停止します (しばらく時間がかかります)

1
　netsh trace stop

4-5. もし私共サポートから本 Blog による New Microsoft Edge の netsh の情報採取をご依頼された場合は、トレースの .etl ファイルと .cab ファイルと C:\tmp\ssl.txt の 3 つ両方とも提供します。

(参考) 以下の etl2pcapng を利用すると、.etl を Wireshark で開ける .pcapng　形式に変換できます。

etl2pcapng
https://github.com/microsoft/etl2pcapng

コマンド例

1
etl2pcapng in.etl out.pcapng

補足２ : pktmon でのトレース取得方法

Windows 10 の 1809 から pktmon が搭載されており、上述の netsh と同様にネットワークトレースを取ることができます。

  1. 上部の “1. 事前準備” を行います。

  2. “2. ユーザー環境変数の設定” を行います。

  3. “Wireshark の準備”　は実施せずにスキップ

  4. “4. New Microsoft Edge による再現とキャプチャ” は以下の手順で実施します (上部の 5 はスキップします)

4-1. New Microsoft Edge を InPrivate ウィンドウで開く。
(タスクバー等の Edge アイコンを右クリックで “新しい InPrivate ウィンドウ” で開けます)
※ InPrivate ブラウズをご利用いただけない場合には、ログ取得前にブラウザーのキャッシュをすべて消去してください。手順は上述の補足をご覧ください。

4-2. 管理者権限でコマンド プロンプトを開き、次のコマンドを実行し、キャプチャを開始します。

1
　pktmon start -c -f client.etl -s 2000 --pkt-size 0

4-3. New Microsoft Edge にて該当のサイトを開き、素早く事象の再現を行う。

4-4. 次のコマンドを実行して、キャプチャを停止します

1
　pktmon stop

4-5. もし私共サポートから本 Blog による New Microsoft Edge の pktmon の情報採取をご依頼された場合は、トレースの .etl ファイルと C:\tmp\ssl.txt の両方とも提供します。

(参考) 以下のコマンドを実行すると、Wireshark で開ける .pcapng　形式に変換できます。

1
pktmon pcapng PktMon.etl -o PktMon.pcapng

以上で今回のご紹介は終了です。

私共では様々なお客様のお問い合わせの内容や状況等に合わせて、お問い合わせ後に、Fiddler や netsh、Wireshark によるトレース、その他の情報等のご提供をお願いしております。また、多くの場合ではクライアント側のキャプチャだけでは原因究明が出来ないことも多々あり、その場合はサーバー側や中間機器等でも情報を採取いただく必要もございます。

今回はその中のあくまで 1 つである Wireshark を用いて、クライアント側のブラウザ New Microsoft Edge で動作する　Web アプリに関するネットワークトレースの取得方法をご紹介いたしました。

今回は以上です。それでは、また次回！

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/New-Edge-Wireshark/ 2023-08-27T15:00:00.000Z 2020/8/7 更新 : ブラウザーのキャッシュが利用されてキャプチャーに記録されないことを避けるために、InPrivate ブラウズをご利用いただく方法をご案内していますが、InPrivate ブラウズをご利用いた]]> Wireshark による New Microsoft Edge のトレース取得方法 2026-06-02T06:09:44.940Z Developer Support Internet Japan みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

皆様からいただく Edge に関するよくある質問についてこちらにまとめました。

目次

Edge バージョン 128.0.2739.42 以降において お気に入りの復元 は行えなくなりました

以下の画像のように Edge 127.0.2651.105 においてはお気に入りのアイコンをクリックすると、削除したお気に入りの設定を復元するためのビンマークがございました。

Edge 127.0.2651.105 でのお気に入りの復元の設定値

こちらは Edge 128.0.2739.42 以降においてはビンマークがなくなりました。

Edge 128.0.2739.42 でのお気に入りの復元の設定値

お気に入りの設定を保持したい場合については ManagedFavorites のご利用をご検討いただけますと幸いです。

その他にもお気に入りのインポートやエクスポートの機能もございます。詳細は Microsoft Edge でお気に入りをインポートする をご確認ください。

拡張機能でもお気に入りを操作する API もございます。
詳細は Microsoft Edge 拡張機能でサポートされている API の 「ブックマーク」をご参考いただけますと幸いです。

Edge のバージョンを Edge の UI 以外でコマンドライン等で確認する方法はありますか

バージョンを Edge 上で確認したい場合は edge://version や edge://settings/help を見ることで判断が可能です。edge://settings/help は更新制御を行っていない場合、ページを開くと自動更新が始まります。

コントロール パネルで Edge のバージョンを確認いただくことも可能です。

注意点として、コントロール パネル上のバージョン表記と edge://version のバージョンが異なる状態になったという問い合わせをいただいたことがあります。

ご利用いただいている Edge の正しいバージョンは edge://version で表示されるものになります。 バージョン不一致が発生した場合、オンライン インストーラーまたはオフライン インストーラーを再度実行してください。そうすることで、コントロール パネル上での表示が正常になることが期待されます。

UI 以外での確認方法について

コマンドラインや API 等で Edge のバージョンを取得したいというシナリオもあるかと思います。

システムインストールされた Edge を前提とした場合、コマンドラインから確認する方法があります。
(Windows 10 20H2 以降においては Edge はシステムインストールになります)

実際に利用する “C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe” から直接確認します。

PowerShell で下記コマンドを実行します。

入力:

1
(Get-Command "C:\Program Files (x86)\Microsoft\edge\Application\msedge.exe").Version

出力例:

1
2
3
Major  Minor  Build  Revision
-----  -----  -----  --------
115    0      1901   200

バージョンを取得したい場合は下記の例になります。

入力:

1
2
3
$version = (Get-Command "C:\Program Files (x86)\Microsoft\edge\Application\msedge.exe").Version
$versionString = "$($version.Major).$($version.Minor).$($version.Build).$($version.Revision)"
Write-Output $versionString

出力例:

1
115.0.1901.200

Get-Command については、弊社ドキュメント Get-Command をご確認ください。

レジストリで確認する方法について

コントロール パネルで表示される Edge のバージョンは特定のレジストリを参照しています。

通常、オンライン インストーラーやオフライン インストーラーによるインストールが正常に終了した場合、当該のレジストリが更新されます。ただし、状況によっては正常に更新されない場合もあります。

そのため、 レジストリに正常なバージョンが書き込まれることを保証していません。こうしたレジストリの値を利用するアプリケーションを開発されている場合はご注意ください。

インストールされている Edge のバージョンの確認については edge://version 等による UI での確認または、msedge.exe 自体を PowerShell 等で確認する方法がより適切であるとご理解ください。

Edge のバージョンと WebView2 Runtime のバージョンを揃える必要性はありますか

こちらもよくいただく質問になりますが、Edge と WebView2 Runtime は開発スケジュールは同様ですが、相互に依存関係はありません。

Edge は WebView2 Runtime に関係なく動作し、その逆に WebView2 アプリケーションは Edge に関係なく動作し、WebView2 Runtime に依存します。

WebView2 の詳細については、弊社ブログの WebView2 と WebView2 Runtime と WebView2 SDK はどのような違いがありますか をご確認ください。

Edge のバージョンは、弊社ブログの Edge のバージョンの読み方について で紹介しています。

Edge のバージョン 100.0.1185.44 を例にして考えますと、メジャー バージョンは 100, マイナーバージョンは 0, ビルド バージョンは 1185, パッチ バージョンは 44 になります。

Edge も WebView2 の同じ開発スケジュールで提供されているため、メジャー バージョンが更新されるタイミングは似ています。

ただし、相互に依存関係はないため、パッチ バージョンが同じになる場合、異なる場合もあります。パッチ バージョンが異なるからといって、問題はありませんのでご安心ください。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/edge-faq/ 2023-08-13T15:00:00.000Z みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

皆様からいただく Edge に関するよくある質問についてこちらにまとめました。

更新履歴:
2021/05/14 新規
2021/05/19 更新
2021/06/15 更新
2021/06/23 更新
2021/06/30 更新
2021/07/02 更新
2021/07/19 更新
2021/07/30 更新
2021/10/01 更新
2021/10/19 更新
2021/10/20 更新
2021/11/22 更新
2021/12/29 更新
2022/06/09 更新
2022/08/04 更新
2023/05/01 更新

みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

これまでに「IE モード」について以下の２つのブログ記事を公開していますが、今回はよくあるご質問についてまとめたいと思います。

新しいバージョンの Microsoft Edge の “IE モード” について
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/IEMode/

まだデフォルトIE？ 新しい Microsoft Edge を使いませんか？
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-about-using-new-edge/

なお、IE モードに関する公式ドキュメントは以下にまとまっていますので、基本的な内容についてはこちらをご覧ください。

Internet Explorer (IE) モードとは

IE モードのトラブルシューティングと FAQ

(PDF) Microsoft Edge + Internet Explorer モード Getting Started ガイド

※ こちらの前提条件　に記載のとおり、IE モードは最新の OS 更新と最新の Edge であることが前提となっていますので、おや?? と思ったらまずは最新状態かどうかをご確認ください。

※ Microsoft Edge の展開または IE モードの構成支援や IE から IE モードへの移行に関する互換性の動作に関して、上記「(PDF) Microsoft Edge + Internet Explorer モード Getting Started ガイド」の「リソース - サポート」項にて、ご利用いただける弊社サポートサービスを紹介しています。
お困りのことがありましたらご利用をご検討ください。

目次

互換性に関する情報

How to/Tips

window.open による子ウィンドウの扱い

Microsoft Edge の IE11 モードでは、IE11 のブラウザー エンジンで表示する必要のある Web サイトを Microsoft Edge 上のタブ内で表示しますが、IE モードで表示されている Web コンテンツ内で window.open メソッドを実行して表示される子ウィンドウは新しい Microsoft Edge のウィンドウとなります。

IE モードでは、Web ページ コンテンツの表示 (レンダリング) やスクリプトは IE11 のブラウザー エンジンによって処理されますが、ブラウザー ウィンドウとしての外枠 (フレーム) 部分は Microsoft Edge によって制御されます。具体的には、以下の図の緑色の枠線内は IE モードによって処理されますが、枠の外側は Microsoft Edge によって処理されます。

ウィンドウの構造

上記動作に伴い、window.open(url, windowName, windowFeatures) の引数 windowFeatures で指定する以下のオプションは反映されません。
なお、この動作は Microsoft Edge における想定された動作となります。

  • location
    引数 url で指定されるサイトがローカル イントラネットや信頼済みサイト ゾーンで、かつ、引数 windowFeatures において location=no と指定していても、以下のようにアドレス バーは表示されます (ただし、アドレス バーでの操作はできません)。

画面例

  • resizable
    resizable オプション指定は常に無視され、ユーザーはウィンドウ サイズを変更することができます。

  • fullscreen
    fullscreen オプション指定は常に無視され、全画面表示とはなりません。

  • channelmode
    channelmode オプション指定は常に無視され、シアター表示とはなりません。

(参考情報)
window.open - Web API | MDN
https://developer.mozilla.org/ja/docs/Web/API/Window/open

ウィンドウのクライアント領域のサイズ

IE モードであっても、ブラウザー ウィンドウとしての外枠 (フレーム) 部分は Microsoft Edge によって制御されます。

異なるブラウザー内での表示となるため、IE11 デスクトップ アプリと比較して、クライアント領域のサイズがわずかに異なります。
コンテンツが 1 ピクセル単位で厳密な位置調整をしている場合、テキストの折り返しが発生する、表示しきれないなどの問題が生じることがあります。

クライアント領域のサイズの差異によるレイアウトの崩れが起きていないか、実際に IE モードで動作させての確認を推奨します。
もしレイアウトの崩れが発生する場合は、クライアント領域のサイズの差異に影響を受けないようなページ レイアウトへ変更してください。

2021/10/19 追記: バージョン 95 より追加される以下のふたつのポリシーにより、IE モードのサイトから window.open メソッドを介して生成されるポップアップ ウィンドウの高さと幅に対するカスタム調整値を指定できます。
このカスタム調整値により、指定したピクセル数ぶん既定よりクライアント領域を広げることが可能になります。

InternetExplorerIntegrationWindowOpenHeightAdjustment
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-policies#internetexplorerintegrationwindowopenheightadjustment

InternetExplorerIntegrationWindowOpenWidthAdjustment
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-policies#internetexplorerintegrationwindowopenwidthadjustment

ウィンドウをデスクトップ外に開けない

IE11 デスクトップ アプリでは、セキュリティ設定の [サイズや位置の制限なしにスクリプトでウィンドウを開くことを許可する] が有効であれば、window.open メソッドや window.moveTo メソッドでデスクトップ外の座標を指定することにより、デスクトップ外でウィンドウを開くことができます。

IE モードでもこれらの API の動作自体は変わりませんが、別途 Chromium のセキュリティ上の制約により、デスクトップ外に開いたウィンドウはデスクトップ内に戻されてしまいます。そのため、結果としては、IE モードでデスクトップ外にウィンドウを開くことができません。

デスクトップ外のウィンドウで処理を行うのではなく、表示されているウィンドウ内のスクリプトや iframe で処理を行うよう変更してください。

ブラウザー エンジンの切り替え時の通信で起こること

ブラウザー エンジンの切り替え時 (Edge から IE モード、およびその逆) の通信は以下のようになります。

  • POST メソッドが GET メソッドになる
  • HTTP リクエスト ヘッダーに Referrer が含まれない

ページ遷移時に POST リクエストではなく GET リクエストが Web サーバーに送信されている場合には、こちらの制限に該当していると言えます。
POST リクエストが GET リクエストとなる動作は、異なるプロセス間での POST データのやり取りに対するセキュリティ的な懸念の観点と、技術的な制約からなる想定された動作となり、この動作を変更することはできません。

元のページから POST リクエストで通信を行った場合は GET リクエストに変わるため、POST リクエストの body に含まれる内容は消失します。
対処策としては、データを引き渡す必要がないように、関連する一連のページをすべて IE モードで表示するか、Edge で開けるように統一するかのどちらかとなります。

2021/10/20 変更: なお、こちらのロードマップにて情報公開されましたが、早くて 2021/11/18 の週にリリース予定のバージョン 96 から上記の制限がなくなる見込みです。今後の予定についてはロードマップのドキュメントをご覧ください。

2021/11/22 追記: バージョン 96 から既定の動作として上記の制限がなくなりました。なお、Internet Explorer モードの開始時または終了時にフォーム データや HTTP ヘッダーを送信するかどうかを構成します ポリシーを使用して、Microsoft Edge と Internet Explorer モードを切り替えるナビゲーションに含めるデータ型を指定できます。

2022/06/09 追記:
バージョン 101 より、InternetExplorerIntegrationComplexNavDataTypes ポリシーの既定の動作が変更となりました。
具体的には、”フォーム データと追加のヘッダーを送信する” 動作から、”フォーム データのみ送信する” へ変わっています。
既定で追加のヘッダーが含まれる動作に変更したことによる、サイトの互換性の問題が多く報告されたためです。
バージョン 101 以降においては、Microsoft Edge と Internet Explorer モードを切り替えるナビゲーション時に、既定で Referrer などの追加のヘッダー情報は含まれません。

バージョン 100 以前と同様に追加のヘッダー情報を含めたい場合は、InternetExplorerIntegrationComplexNavDataTypes のポリシーにて IncludeFormDataAndHeaders (3) を指定してください。

2021/12/29 変更: 注意 : この追加機能をご利用いただくには以下の更新プログラムの適用が必要です。(リストにない OS バージョンではご利用いただけません)
Windows 11 : KB5007262 以降
Windows Server 2022 : KB5007254 以降
Windows 10 バージョン 2004 以降、Windows Server 2004/20H2 : KB5006738 以降
Windows 10 バージョン 1909 : KB5007189 以降

(参考)
IE モードのトラブルシューティングと FAQ も併せてご覧ください。

クライアント証明書を要求する場合の制限

ここでは、よくあるご質問の 1 つとして IE モードを使用する上で “SSL クライアント認証を使用しており、アクセスするサイトがクライアント証明書を要求する場合” の制限についてお伝えします。

なお、以下は 2021 年 7 月 30 日現在の Edge の最新版（バージョン 92）の動作をもとに説明していますが、今後、この制限によるお客様へのインパクト状況などを鑑みて、当該動作の変更を再検討する可能性もあります。

IE モードを使用している場合に証明書の選択ダイアログが 2 回表示される動作について

Edge 上で IE モードを使用し、SSL クライアント認証を使用しており、アクセスするサイトがクライアント証明書を要求する場合、サイトにアクセスしてページが表示されるまでに、クライアント証明書の要求ダイアログが合計 2 回表示される場合があります。

具体的には、以下の 2 回のリクエストが Web サーバーに送信されるため、その都度 Web サーバーがクライアント証明書を要求するため、合計で 2 回のクライアント証明書選択ダイアログが表示されることになります。

　1 回目
　IE モードを動作させるプロセス（iexplore.exe）が、サイトにアクセスしてクライアント証明書を要求される

　2 回目
　Edge のプロセス（msedge.exe）が、ブラウザーのタブ部分に表示する Favicon ファイル（*）のリクエストのためにサイトにアクセスしてクライアント証明書を要求される

　*Favicon ファイルとは Web ページのアイコン画像のことであり、Favicon の取得が行えない場合、Edge では Internet Explorer の画像を既定で表示させます

Favicon ファイルの表示部分のイメージ

iexplore.exe が表示する証明書選択ダイアログ

msedge.exe が表示する証明書選択ダイアログ

<補足>
・2 回目の証明書選択ダイアログにて [キャンセル] をクリックしていただいても、Web ページ自体には影響はありません。ただ、Favicon ファイルは取得できなくなるため、Edge のタブ部分にはアイコン画像が表示されなくなります。

・2 回目の証明書選択ダイアログにて [キャンセル] をクリックした後、別のページに遷移した場合には、再度 Favicon ファイルを要求するため、再度 2 回目のクライアント証明書選択ダイアログが表示されます。

・Favicon ファイルは、その他のリソース（HTML, CSS ファイルなどと）同様ローカルにキャッシュされます。一度 Favicon ファイルがローカルにキャッシュされた場合、次回以降、Edge はローカルにあるキャッシュされた Favicon ファイルを使用するため、2 回目の証明書選択ダイアログは表示されなくなります。ただし、ブラウザー終了後にキャッシュを削除する設定、または明示的にキャッシュを削除した場合には、ローカルにキャッシュされた Favicon ファイルが削除されてしまうため、それ以降は再度 2 回目の証明書選択ダイアログが表示されることになります。

・クライアント証明書を Smart Card などから取得する際には PIN が要求されるため、その場合はクライアント証明書選択ダイアログと PIN 入力画面が 2 回表示される動作となります。

当該動作と IE モードの制限について

Favicon を表示しているウィンドウ部分は、IE モードではなく、Edge が担う部分となるため、通信を発行する主体は Edge となります。なお、他社製のブラウザー同様、この Favicon へのリクエスト自体は想定された動作となります。

ただ、上記 1 回目, 2 回目がそれぞれのプロセスにて実行されるのは、Edge と IE モードを安全に分離させる上での技術的な制約があるためです。Web ページを表示する IE と、それをホストする Edge を完全に分離してセキュアなブラウジングを維持するための制限であるため当該動作についてお困りの場合には後述の対処策のご検討をお願いいたします。

対処策について

2 回目の証明書選択ダイアログを非表示にする場合、以下の 2 つの方法が考えられます。

　a) Web サーバーにて Favicon ファイルだけ、クライアント証明書を要求しないよう設定を変更する
　b) ブラウザーがアクセスするサイトの head タグ内に、ダミーの Favicon ファイルへのリンクを埋め込み、Favicon ファイルへのリクエストの送信を抑止させる

a について手順イメージ
IIS マネージャーを使用されている場合には、まず SSL 設定にて [SSL が必要] をオン、そして “クライアント証明書:” を “必要” と指定します。
その上で、”コンテンツ ビュー” を選択して、表示される Favicon ファイルを選択します。

IIS マネージャー上での "コンテンツ ビュー" のイメージ

IIS マネージャー上での "機能ビューに切り替え" のイメージ

画面右にある [機能ビューに切り替え] を押下し、画面左側のフレームに表示された
Favicon ファイルに対して、再度 SSL 設定から [SSL が必要] をオフにします。

SSL の設定にて、Favicon ファイルにのみ [SSL が必要] をオフにするイメージ

b について設定イメージ
head タグ内に記載するダミーの Favicon ファイルへのリンクは以下となります。

1
<link rel="icon" href="data:,">

例えば IIS であれば、iisstart.htm 内に以下の様に埋め込みます。

1
2
3
4
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="icon" href="data:,">
<title>IIS Windows</title>

<補足>
ご参考までとはなりますが、サーバー側での対応策以外にも Edge の設定でもクライアント証明書選択ダイアログが 2 回表示される動作を回避することは可能です。

シンプルな方法としては、例えば以下の Edge の拡張機能をインストールすることで特定に URL へのリクエストをブロックすることができるため、Favicon ファイルの
URL を登録することで 2 回目のクライアント証明書選択ダイアログは表示されません。

HTTP Request Blocker
https://chrome.google.com/webstore/detail/http-request-blocker/eckpjmeijpoipmldfbckahppeonkoeko/related

また、以下の Edge のグループ ポリシーを構成することで、特定のパターンの場合にはクライアント証明書を自動的に送信させることが可能となりますので、これらを構成した
場合も、2 回目のクライアント証明書選択ダイアログを表示されないよう構成可能です。

AutoSelectCertificateForUrls
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-policies#autoselectcertificateforurls

ForceCertificatePromptsOnMultipleMatches
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-policies#forcecertificatepromptsonmultiplematches

WebBrowser コントロールからの window.open

2023/05/01 追加:

WebBrowser コントロールからの window.open は IE モードで開きません。

WebBrowser コントロールで表示している Web ページから window.open を実行したとき、既定の実装では新しいウィンドウは IE で開かれます。
最初から IE が起動できない Windows 11 や、2023 年 2 月 14 日に IE11 デスクトップアプリケーションが完全に無効になった特定のバージョンの Windows 10 の環境でも、上記のこれまでの動きのまま変わりません。

Web コンテンツのデバッグ方法

Microsoft Edge の IE モードでは、IE11 のブラウザー エンジンで表示する必要のある Web サイトを Microsoft Edge 上のタブ内で表示しますが、IE モードで表示されている Web コンテンツに対して、Microsoft Edge の F12 開発者ツールを使用することはできません。
IE モードで表示されている Web コンテンツをデバッグするには、IEChooser (Microsoft Edge 開発者ツール) を使用します。具体的には、以下の手順にてデバッグ作業を行います。

※ このトピックは、Windows 10 および Windows Server 2016、Windows Server 2019 以上の環境を前提としています。Windows 8.1 および Windows Server 2012 R2 以前の Windows プラットフォームについては、恐れ入りますが、後述の方法で IE モードで表示されている Web コンテンツをデバッグすることはできません。

  1. Microsoft Edge 上で、IE モードの Web コンテンツを表示します。
  2. %WINDIR%\System32\F12 フォルダー内にある、IEChooser.exe (Windows 10 のバージョン 1709 以前、および Windows Server 2016 では F12Chooser.exe) を起動します。
  3. 以下のようなウィンドウが表示されますので、IE モードで表示されている Web コンテンツをクリックします。
    なお、以下のウィンドウ内には、IE11 および IE モードで表示されている Web コンテンツのファイル名またはタイトルが表示されますので、その情報を基に対象の Web コンテンツを選択します。

ターゲットの選択

  1. 開発者ツールが起動しますので、Web コンテンツをデバッグします。

開発者ツール画面

以下のドキュメントに詳細がまとまっていますが、セッション Cookie に関して、Edge から IE モードに共有することができます。
2022/08/04 変更: バージョン 99 より、Edge と IE モード間で双方向にセッション Cookie を共有できるようになりました。
ただし、Windows の更新プログラム適用の前提条件がありますので、詳細は以下のドキュメントをよくご確認ください。

Microsoft Edge から Internet Explorer への Cookie の共有
https://docs.microsoft.com/ja-jp/deployedge/edge-ie-mode-add-guidance-cookieshare

※ 共有できる Cookie の種類は、有効期限のある永続 Cookie ではなく、有効期間のないセッション Cookie のみですのでご注意ください。

最も理想的な解決方法は、Cookie の共有が必要なコンテンツを全て Edge に移行させることです。

ページ遷移時のブラウザー エンジンの切り替え

以下のポリシーの設定状態によって、IE モードで表示しているページからの遷移時の動作が変わります。

InternetExplorerIntegrationSiteRedirect
https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-policies#internetexplorerintegrationsiteredirect

実際の動きをみてみましょう。(ポリシー変更後はいったん Edge を再起動させてください)

サイトリストには以下のふたつの URL を登録した状態にします。

1
2
3
4
5
6
<site url="docs.microsoft.com/ja-jp/deployedge/edge-ie-mode">
<open-in>IE11</open-in>
</site>
<site url="aka.ms">
<open-in>IE11</open-in>
</site>

このサイトリストが反映された状態で以下の A, B の操作をすると、ポリシーの設定状態によって下記のとおりになります。

A) https://docs.microsoft.com/ja-jp/deployedge/edge-ie-mode を (IE モードで) 開いたあと、ページ左側の目次から任意の別のページを開く
B) https://aka.ms/windows/releaseinfo を開く

  • 未構成もしくは既定
    A, B) 遷移先のページが Edge モードで表示される。

  • 自動ナビゲーションのみを Internet Explorer モードで維持する
    A) 遷移先のページが Edge モードで表示される。
    B) 遷移先のページが IE モードで表示される。

  • すべてのページ内ナビゲーション を Internet Explorer モードで維持する
    A, B) 遷移先のページが IE モードで表示される。

  • 目次へ

IE モードでの表示をテストしたい

IE モードのテストのために、毎回サイトリストを書き替えたり、ポリシーを設定しなおすことは大変な手間がかかります。
この手間を解消するために、以下の A, B どちらかの方法でメニューから IE モードもしくは Edge モードを切り替え、コンテンツを表示することが可能です。

これらの機能はテストを目的に用意されており、意図しないサイトで IE モードを利用することは、想定しない ActiveX の実行など、セキュリティのリスクがありますので十分ご注意ください。

以下の通知は、サイトリストを使用せずに後述の A, B の方法で手動で IE モードに切り替えた場合に表示されるものです。テスト モードでこのメッセージを抑止する方法はありません。サイトリストを使用して IE モードを利用する場合には表示されません。

このサイトは Internet Explorer モードで開かれています

なお、テスト モードの利用は IE モードが構成されていることが前提となります。以下のポリシーで IE モードを有効に設定してください。

  [コンピューターの構成] or [ユーザーの構成]   ＋[管理用テンプレート]    ＋[Microsoft Edge]  「Internet Explorer 統合を構成する」有効にし IE モードを選択

A) InternetExplorerIntegrationTestingAllowed (Internet Explorer モードのテストを許可) ポリシー を有効に設定する

  [コンピューターの構成] or [ユーザーの構成]   ＋[管理用テンプレート]    ＋[Microsoft Edge]  「Internet Explorer モードのテストを許可」有効

※ 上記のポリシーはバージョン 95 から利用できなくなりますので、バージョン 92 (2021/7/22 の週にリリース予定) からは、Internet Explorer モードでサイトの再読み込みを許可 をご利用ください。

B) “--ie-mode-test” オプションを付加して msedge.exe を実行する
実行例)

1
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --ie-mode-test

上記 A, B の方法を利用することで、ポリシーの説明にもあるように [その他のツール] 以下に、[サイトを Internet Explorer モードで開く]、[サイトを Edge モードで開く] メニューが表示されます。

選択したモードで開く操作

(参考)
グループ ポリシーを使用して Internet Explorer 統合を有効にする
https://docs.microsoft.com/ja-jp/deployedge/edge-ie-mode-policies#enable-internet-explorer-integration-using-group-policy

Internet Explorer モードでサイトの再読み込みを許可

現在この機能はコンシューマー向けであり、Windows 10 Home、あるいはドメイン不参加の Windows 10 Pro で利用可能です。
Windows 10 Enterprise エディションやドメイン参加環境の Pro エディションでは使用できません(※) ので、上述の A もしくは B の方法で「サイトを Internet Explorer モードで開く」という機能を使用します。
(なお上記は OS のエディションについてであり、Edge 自体に OOOO エディションのようなものはありません。)

Internet Explorer モードでサイトの再読み込みを許可 設定

Internet Explorer モードでサイトの再読み込みを許可 メニュー

(参考) 以下の注釈部分でも触れています。
Microsoft Edge の Internet Explorer モード

※ バージョン 92 (2021/7/22 の週にリリース予定) から、Internet Explorer モードで未構成のサイトを再度読み込みできるようにする ポリシーを有効にすることで、エンタープライズ環境でも「Internet Explorer モードでサイトの再読み込みを許可」を利用可能になります。

※ Internet Explorer モードで未構成のサイトを再度読み込みできるようにする ポリシーで機能を利用するには、Windows 10 version 1909 では KB5003698 以上、Windows 10 version 2004 / 20H2 / 21H1 では KB5003690 以上を適用する必要があります。

サイトリストで指定しているサイトが IE モードで表示されない

まずは edge://compat を開いて、Edge が読み込んでいるサイトリストの内容を確認します。

Edge が読み込んでいるサイトリストの内容

確認ポイント

  • URL 一覧の中に、IE モードで表示したい項目が存在するか。
  • 対象のサイトについて “エンジン” が “IE11” となっているか。
  • “エンジン”が “ニュートラル” となっている場合、遷移元のページが IE モードで表示されているか。

もし想定していない状態であれば、なぜ意図したサイトリストが利用されていないのかを掘り下げていきます。

確認ポイント

サイトリストの内容には問題がない場合、edge://compat/iediagnostic を開いて、ポリシーの設定状態を確認します。

診断情報の画面
診断情報の画面

確認ポイント

  • “Internet Explorer モードの設定” で上記のようになっているかどうか。
  • “グループ ポリシーの設定” が想定したとおりになっているかどうか。
  • Edge と Windows のそれぞれの更新状態は最新か。

設定について IE モード ポリシーの構成 のドキュメントをみながら構成を確認します。

ドキュメント モードを確認したい

アドレス バーの横にある IE モードのアイコンをクリックすると確認できます。

ドキュメント モードなどの確認

なお、ドキュメント モードは IE11 デスクトップ アプリと同じく こちらにあるフロー に従って決定されます。

たとえば、エンタープライズ モードで Web ページを表示するように指定している場合に、対象の Web ページにて meta タグ (X-UA-Compatible) の指定や !DOCTYPE 宣言がないとドキュメント モードは IE5 となります。

エンタープライズ モードでドキュメント モードが IE5 の例

ニュートラル サイト

ニュートラルの機能は、その URL に遷移してきた際の直前のブラウザーを維持することです。
つまり、Edge で遷移してきた場合には Edge を維持し、IE モードで遷移してきた場合には IE モードを維持するにようにできます。

以下のような場面で利用します。

認証がうまくいかないケース

IE モードを利用するとき『認証がうまくいかない』というお問い合せをよくいただきますので、ここで紹介します。

認証がうまくいかないという話では 保護モードをまたいだ Cookie について という記事で、Azure AD (AAD) 認証を必要とする Web アプリケーションを例としました。
対象の Web アプリケーションのドメインと認証時にアクセスする login.microsoftonline.com が異なったセキュリティ ゾーンに属していた場合、認証済みを示す Cookie がリクエストに含まれないことで、ユーザーがログオンしていないと判断され、再度認証を求められてしまうという現象を解説しました。

IE モードを利用するとき『どの URL を IE モードで表示するか』を設定しますが、対象の Web アプリケーションの URL に加えて、認証サーバー / シングル サインオン サーバーに対してのアクセスも IE モードで動作するように明示的に構成する 必要があります。
認証サーバーも含めておかないと、以下のように IE モードと Edge とで行き来するときに認証に必要な Cookie が共有されずに認証ができません。

  1. 対象の Web アプリケーションの URL にアクセスします。(IE モードで動作します)
  2. 認証のために認証サーバーにアクセスします。(Edge で通信します)
  3. Edge 側で認証済みを示す Cookie を受け取ります。
  4. 対象の Web アプリケーションにリダイレクトしますが、ここで IE モードに切り替わります。
  5. IE モードとしては認証済みを示す Cookie を持っていないので、Cookie なしの状態でリクエストすることになります。
  6. 認証済みを示す Cookie がリクエストに含まれないことで、ユーザーがログオンしていないと判断され、再度認証を求められます。

ただ、認証時に通信するサーバーをすべて IE モードで動作するように明示的に指定してしまうと、逆に Edge でアクセスする必要があるパターンでうまくいきません。

具体例として、Azure AD (AAD) 認証を必要とする Web アプリケーションとして Office.com を使って試してみます。
(本来は IE モードを使わずに Edge でご覧いただくことをおすすめします)

まずは以下のように対象サイト (office.com) だけを登録してみます。

1
2
3
<site url="office.com">
    <open-in>IE11</open-in>
</site>

このサイト リストを読み込んで、office.com にアクセスすると IE モードで開きます。
サインインの操作をしてみるとわかりますが、サインインが完了しません。(場合によっては、認証画面の表示がループしてしまうこともあります)
これは、上述のとおり、認証済みを示す Cookie がリクエストに含まれないことで、ユーザーがログオンしていないと判断されたためです。

そこで以下のように、今回の認証時に経由する可能性がある、login.microsoftonline.com, login.windows.net, login.live.com に対しても IE モードになるように <open-in>IE11</open-in> を設定してみます。

1
2
3
4
5
6
7
8
9
10
11
12
<site url="office.com">
    <open-in>IE11</open-in>
</site>
<site url="login.microsoftonline.com">
    <open-in>IE11</open-in>
</site>
<site url="login.windows.net">
    <open-in>IE11</open-in>
</site>
<site url="login.live.com">
    <open-in>IE11</open-in>
</site>

これにより、認証時に通信するサーバーすべてが IE モードで動作し、認証完了まで進みます。

それでは、この状態で Outlook on the web (OWA) を開いてみましょう。
OWA は IE モードで開くように登録をしていないので、通常の Edge で開きます。
サインインをしようとすると、login.live.com が IE モードとして登録されているので、サインイン画面が IE モードで開きます。
アカウント情報を入力してみると…

エラーになってしまいました :(

サインインのエラー画面

認証サーバー (login.microsoftonline.com, login.windows.net, login.live.com) を IE モードの対象から外せば、OWA は開きます。
でもそうすると、先ほどの Office.com がまたダメになってしまいます。

どちらもうまくいくように構成するにはどうしたらよいか…

Edge と IE のどちらからも経由され得るサイトを『ニュートラル』に登録することで解決できます！

冒頭に記述したように、ニュートラルの機能は、その URL に遷移してきた際の直前のブラウザーを維持することです。
つまり、Edge で遷移してきた場合には Edge を維持し、IE モードで遷移してきた場合には IE モードを維持するにようにできます。

それでは、先ほどのサイト リストを以下のように認証サーバー (login.microsoftonline.com, login.windows.net, login.live.com) に対してそれぞれ <open-in>None</open-in> に変えます。

1
2
3
4
5
6
7
8
9
10
11
12
<site url="office.com">
    <open-in>IE11</open-in>
</site>
<site url="login.microsoftonline.com">
    <open-in>None</open-in>
</site>
<site url="login.windows.net">
    <open-in>None</open-in>
</site>
<site url="login.live.com">
    <open-in>None</open-in>
</site>

こうすると、IE モードで開く Office.com から認証サーバーにアクセスするときは IE モードが維持され、Edge で開く OWA から認証サーバーにアクセスするときは Edge が維持されますので、認証処理の途中でモードが変わってしまうことを回避できます。

なお、下記ドキュメントの「ニュートラル サイトを構成する」の部分にも記載がありますが、上記の例のように Edge と IE のどちらからも経由され得るサイトはすべてニュートラルに登録する必要があります。

エンタープライズ モード サイト リストでのサイトの構成
https://docs.microsoft.com/ja-jp/deployedge/edge-ie-mode-sitelist

一時的な対応策としては [Internet Explorer モード ページから起動したときに未構成サイトへの「ページ内」ナビゲーションの動作を指定する] というポリシーが利用できますので、状況に合わせた対応をご検討いただければと思います。

Internet Explorer モードでページ内ナビゲーションを保持する
https://docs.microsoft.com/ja-jp/deployedge/edge-learnmore-inpage-nav

アドレス バーを非表示にする方法

2021/10/20 追加:
window.open による子ウィンドウの扱い で説明している通り、Edge では基本的にアドレス バーを非表示にできません。
ただし、Edge を キオスク モード で起動したり、サイトを PWA としてインストールしたりすることで、そのサイトのアドレス バーは表示されなくなります。

また、Chromium で提供している –app コマンドライン スイッチ を msedge.exe に指定して起動できる “アプリケーション モード” でも、そのサイトのアドレス バーは表示されなくなります。
アプリケーション モードは、ユーザーが Web ページをコンピューター上のネイティブ アプリケーションに近い外観で動作させることを可能にします。つまり、ツール バーやアドレス バーをすべて非表示にして、Web ページの本文を中心に表示します。
この機能は Edge で開発を行っているわけではありませんが、以下の通り、–app コマンドライン スイッチは現状のまま引き続き Edge で利用できます。

Microsoft Edge における “–app” コマンドライン スイッチのサポート
私たちは、Google が Chromium から “–app” コマンドライン スイッチを削除できるかどうかを判断するためのオープンなバグを持っていることを理解しています。
Google は現在、このスイッチが使用されているかどうか、また、このスイッチを削除することでお客様にどのような影響があるかを判断するために、より多くの使用情報を収集しています。
Google が “–app” スイッチの廃止を決定した場合でも、Microsoft Edge 製品チームは、Edge 製品でこのスイッチを提供し続けることをお約束し、お客様のためにこの機能の継続性を確保します。

Jason McConnell
Microsoft Edge プログラム マネージャー

IE モードで互換表示を切り替えたい

2022/06/09 追加:
バージョン 102 より、IE モードのインジケーターから互換表示を切り替えることができる機能を利用できます。
この機能により、IE11 の互換表示設定で、互換表示をする Web サイトを追加すると同等の効果が得られます。
なお、この機能は Internet Explorer モードでサイトの再読み込みを許可 により、手動で IE モードに切り替えた場合にのみ表示されます。
組織のサイトリストで IE モードを設定しているサイトに関しては、サイトリストで必要な互換モードを設定ください。

IE モードで互換表示

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/ie-mode-faq/ 2023-04-30T15:00:00.000Z 更新履歴:
2021/05/14 新規
2021/05/19 更新
2021/06/15 更新
2021/06/23 更新
2021/06/30]]> IE モードのよくあるご質問 2026-06-02T06:09:44.965Z Developer Support Internet Japan 2023/02/20 更新: IE ショートカット アイコン

みなさんこんにちは！

Microsoft は Internet Explorer (以降 IE) デスクトップ アプリのサポートを 2022 年 6 月 15 日に終了することをブログで公開しました。

Internet Explorer は Microsoft Edge へ – Windows 10 の Internet Explorer 11 デスクトップアプリは 2022 年 6 月 15 日にサポート終了

Internet Explorer 11 デスクトップ アプリのサポート終了へ! IE モードへの移行を進めましょう!

(PDF) Microsoft Edge + Internet Explorer モード Getting Started ガイド

これに伴い IE から Microsoft Edge (以降 Edge) やモダン ブラウザーへの移行を本格的に検討される方が多くなることを予想しています。
そんなことで今日は IE から Microsoft Edge へのステージ別移行ガイドライン的なブログを書きたいと思います。

2029 年をターゲットに 4 つのステージでやるべきことをご紹介します。
最終的にはステージ 4 の “IE が不要な状態” となることが望ましいので、本記事を参考に Edge への移行を進めてみてください。

目次

ステージ 1. IE を既定のブラウザーとして運用している

1-1. IE に依存しているサイトの洗い出し

まずは IE に依存しているサイトがどれくらいあるのか、また、具体的にどのサイトが依存しているのか洗い出します。
1 ページずつ確認することが確実ですが、Enterprise Site Discoveryを使えば従来のドキュメント モードを使用しているサイトを機械的に検出することができます。

Enterprise Site Discovery ステップ バイ ステップ ガイド

1-2. IE モードでの動作確認

洗い出したサイトが Edge の IE モードで動作するかテストを行い、動作しない場合は改修もしくは Microsoft のサポートに問い合わせてください。
なお、簡易的に IE モードでの動作を確認したい場合は IE モード テスト機能が便利です。
この機能は IE モードをタブ全体で有効にし、そのタブで開いたサイトはすべて IE モードになる機能です。
以下 2 つのポリシーを設定することで「…」->「その他のツール」->に「サイトを Internet Explorer モードで開く」のメニューが追加され使用できるようになります。

※ 参考 IE モードでの表示をテストしたい

  [コンピューターの構成] or [ユーザーの構成]   ＋[管理用テンプレート]    ＋[Microsoft Edge]  「Internet Explorer 統合を構成する」有効にし IE モードを選択  「Internet Explorer モードのテストを許可」有効

ポリシーの設定

なお こちら で動画による解説もしていますのでぜひご覧ください。

1-3. サイト一覧 (.xml) ファイルの作成とポリシーの設定

IE モードで問題なくサイトが動作することを確認したら、サイト一覧ファイルに IE モードで表示したいサイトを定義します。
サイト一覧の作り方については こちらの記事 がありますので参考にしてみてください。
そして以下のポリシーを使って、作成したサイト一覧の取得先を設定します。

  [コンピューターの構成] or [ユーザーの構成]   ＋[管理用テンプレート]    ＋[Microsoft Edge]   「エンタープライズ モード サイト一覧を構成する」有効にしサイト一覧の取得先を設定   (例 http://contoso.com/Sitelist.xml)    ※IE モードを使うためには以下ポリシー設定も必要なので合わせて有効にします。   「Internet Explorer 統合を構成する」有効にし IE モードを選択

1-4. 既定のブラウザーの変更

上記までの作業でサイト表示に IE が必要なサイトは IE モードで表示できるになったのでもう IE は必要ありません。
既定のブラウザーを IE から Edge に変更します。
既定のブラウザーの設定

なお、既定のブラウザーの変更はグループ ポリシーで配布することも可能です。詳細は こちら をご覧ください。

ステージ 2. Edge には移行しているが、IE モードと IE デスクトップ アプリ (スタンドアロンの IE11) を併用している

2-1. IE デスクトップ アプリ依存サイトの洗い出し

すでに IE モードを使用している環境であれば、何等かの理由で Edge or IE モード で動作しないサイトを止むを得ず IE デスクトップ アプリで表示させているのだと思います。
まずは、なにが IE デスクトップ アプリから IE モードへの移行を妨げているのかを整理し、IE デスクトップ アプリ依存のサイトの改修を進めます。

2-2. サイト一覧へのサイトの追加

IE デスクトップ アプリ依存のサイトの改修が完了したら、既存のサイト一覧に改修したサイトを追加して IE デスクトップ アプリではなく IE モードで表示するよう定義してください。

ステージ 3. IE モードを部分的に利用しているが IE デスクトップ アプリはもう使っていない

IE モードがあれば IE デスクトップ アプリは必要ない状況になったら、IE デスクトップ アプリの起動を無効化する以下のポリシーを配布し、IE モードのみを使用できるようにします。

    [コンピューターの構成] or [ユーザーの構成]   ＋[管理用テンプレート]    ＋[Windows コンポーネント]     ＋[Internet Explorer]  「Internet Explorer 11 をスタンドアロンブラウザーとして無効にする」

参考 : Internet Explorer 11 を無効にする


2023/02/20 更新
<補足>
当該のポリシーを有効にした場合、IE を起動しようとすると Edge にリダイレクトされ、且つ、IE のショートカット アイコンは削除されます。
なお、更新プログラム適用することでスタート メニューの Windows アクセサリに IE のアイコンが再度表示される場合がございます。
再表示されたアイコンをクリックしても Edge にリダイレクトされ、且つ、IE のショートカット アイコンは再度削除されます。

ステージ 4. Edge に完全に移行できており、IE モード含めて完全に必要ない

IE に依存したサイトはすべて改修され、すべてのサイトを Edge で動作させることができるようになったら、IE デスクトップ アプリの機能を無効化することを検討してください。
「Windows の機能の有効化または無効化」にて「Internet Explorer 11」のチェックを外すことで無効化できます。
以下ドキュメントの「Method 1 - Use Control Panel (client systems only)」でも紹介しているので参考にしてください。

Disable Internet Explorer on Windows (機械翻訳版は こちら )

IE デスクトップ アプリから IE モードへの移行にあたり、互換性の問題でお困りの場合は こちらの FAQ No.17 にある App Assure のご利用をご検討ください。

<参考リンク>
(PDF) Microsoft Edge + Internet Explorer モード Getting Started ガイド

それでは皆様またの機会に！

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/guidelines-for-migrating-from-ie-to-microsoft-edge/ 2023-02-19T15:00:00.000Z 2023/02/20 更新: IE ショートカット アイコン

みなさんこんにちは！

Microsoft は Internet Explorer (]]>

Internet Explorer から Microsoft Edge への移行ガイドライン 2026-06-02T06:09:44.958Z Developer Support Internet Japan 更新履歴:
2023/02/27 更新: 同一のバージョンにロールバックを行うと失敗する場合がある件について

みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

今回はお客様からよくいただく Microsoft Edge (以下 Edge と呼称) のロールバックについてのお話をお伝えしたいと思います。

ロールバック手順については以下のドキュメントにまとめられております。

Microsoft Edge を以前のバージョンにロールバックする方法:
https://learn.microsoft.com/ja-jp/deployedge/edge-learnmore-rollback

ただしロールバックは前提条件や管理体制などによって選択しうるシナリオが異なります。

そのため、改めてこちらのブログにてロールバックを検討する場合に必要なポイント、やり方についておまとめさせていただきました。

目次

ロールバックの前提条件

ロールバックは端末がドメイン管理下にあることを前提条件としています。
※ ここにおいてのドメイン管理下とは、Intune や Active Directory, Azure Active Directory の制御下であることを指します。

ドメイン管理下ではない端末については、グループ ポリシーによるロールバックは行えません。

ロールバックに必要な Edge の更新管理にかかわる GPO の設定を行っても、設定値が無視されるためです。

※ ただし、ドメイン管理下ではない端末でも「Edge のオフライン インストーラーの .msi ファイルを利用する方法」についてはロールバックを行うことは可能です。

ただし、ドメイン管理下ではない端末は通常自動更新によってバージョンが管理されています。そのため、インターネットに接続可能な環境の場合は、再度最新版へ自動更新が行われてしまいます。また最新版への自動更新は、インターネット上から Edge 本体のダウンロードを行うため、端末数が多い場合は通信帯域を圧迫する可能性もございますのでご注意ください。

ロールバックの注意点

弊社は Edge を最新版に保つことを推奨しております。

以前のバージョンにロールバックすると、最新版で修正された既知のセキュリティ問題にさらされるリスクがありますのでご注意ください。

そのため、ロールバック機能については、例えば最新版の Edge で発生する問題を一時的に退避するためなどにご検討いただく機能として理解が必要です。

端末の同期状態について

ロールバックを行う前に、ロールバックを行うすべての端末において同期機能を有効にし、同期が正常に終了していることを推奨します。

正常に終了しているかどうかは、 edge://settings/profiles/sync にアクセスし、**「同期は有効になっています」**と表示されているかをご確認ください。

同期が正常に行えている図

**問題がある場合は以下の画像のように「同期していません」**などのように表示されます。その場合は同期を有効にし、「同期は有効になっています」と表示されるようにしてください。

同期に失敗している図

同期に失敗している場合に置いてもロールバックは可能ですが、閲覧データや設定、お気に入りなどのデータが永久に失われる危険性があります。

データが永久に失われる危険性について

通常何も設定しない場合は Azure のクラウド上でデータの同期が行われます。この場合、正常に動作していれば、同期対象の項目については維持されることが期待されます。

ただし、同期をしないように設定したデータや、キャッシュや Cookie などについては、消えてしまう可能性はございます。

また、通常利用されるクラウド同期ではなく、オンプレミス同期を行っている場合については、実際に過去問い合わせとしてデータが消えたという報告もございます。

同期についてご不明な点がある場合は以下のドキュメントをご参照ください。

Microsoft Edge エンタープライズの同期を構成する:
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-enterprise-sync

ロールバックが難しい場合について

ロールバックの利用が難しい、その場合は以下をご検討ください。

  • Stable 版ではない Beta 版や Dev 版、Canary 版、Edge の IE モードで回避できないか
  • それ以外のブラウザを利用することで回避できないか

Beta 版、Dev 版、Canary 版について (Microsoft Edge Insider Channels):
https://www.microsoftedgeinsider.com/ja-jp/download

※ Dev 版および Canary 版は弊社で問い合わせのサポートをしていません。
※ Beta 版や Dev 版、Canary 版を利用することで、別の不具合や意図せぬ状態の変更につながることもございます。

ロールバックするバージョンについて

下記ブログに記載しておりますように、弊社として支援している Edge のバージョンは Stable 版においては “最新版のバージョン - 2” までになります。 Extended Stable 版においては “最新の偶数バージョン - 2”までがサポート範囲となっています。

ロールバック先のバージョンが古い場合は、ロールバックに関するご質問についてもお答えしかねる場合がございますので、必ずロールバックについては弊社がサポートしているバージョンを対象にしていただけますと幸いです。

Edge の種類と Edge のサポート範囲について:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#Edge-%E3%81%AE%E7%A8%AE%E9%A1%9E%E3%81%A8-Edge-%E3%81%AE%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E7%AF%84%E5%9B%B2%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

ロールバックに失敗する場合について

Edge のロールバックにおいて、同一のバージョンに対して複数回のロールバックを
行った場合に、二回目以降のロールバック処理が失敗する事例がございます。

例)
109.0.1518.69 → 108.0.1462.46 (ロールバック) → 109.0.1518.69 (自動更新) → 108.0.1462.46 (ロールバック失敗)

回避策として、該当のバージョンとは異なるバージョンに対して一度ロールバックしていただくことで、ロールバックが可能である場合がございます。そのため、下記記載のロールバック手順を実施いただいた際に、Edge のバージョンが正しくロールバックされないといった場合には、一度こちらの回避方法をお試しいただければと存じます。

例)
109.0.1518.69 → 108.0.1462.42 → 108.0.1462.46

ロールバック方法の種類について

大きくロールバックの方法としては以下 2 つに分けられます。

  • ① Edge のオフライン インストーラーの .msi ファイルを利用する方法
  • ② グループ ポリシーを利用する方法

※ なお WSUS を利用したロールバック方法はございません。全体に自動的に配布したい場合は、後述する **「 ①-B の SCCM を利用する方法」か、「 ② グループ ポリシーを利用する方法」**のいずれかになりますのでご注意ください。

① Edge のオフライン インストーラーの .msi ファイルを利用する方法

オフライン インストーラーを利用する場合については、さらに細かく二つに方法が分けられます。

  • ①-A 手動で行う方法
  • ①-B SCCM を利用してパッケージ展開によりロールバックする方法

①-A 手動で行う方法

まずは Edge の自動更新をオフにします。

Edge の自動更新を無効化する

以下のブログにも記載されているように Edge の更新制御として存在する UpdateDefault または Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} 等の Edge のチャネルごとの制御を 0 (更新を無効にする) に設定します。

Edge の更新制御:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#3-Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E5%88%B6%E5%BE%A1

オフライン インストーラーをダウンロードする

以下の URL より Edge のオフライン インストーラーをダウンロードします。

ビジネス向け Microsoft Edge をダウンロードして構成する:
https://www.microsoft.com/edge/business/download

以下は例として Edge 108 にロールバックする場合になります。

Stable 版をロールバックしたい場合、「古いバージョンの Edge をお探しですか？」の項目からチャンネルを Stable 108 で選択し、その中からビルドを選択します。

Stable 版と Extended Stable 版のビルド バージョンの見分け方

※ 注意点として偶数バージョンの Edge は Stable 版(安定版) および Extended Stable 版(拡張安定版) が混在しております。
※ Stable 版のロールバックの場合は Extended Stable 版ではなく、Stable 版をご選択いただく必要がございます。

ビルド バージョンが Extended Stable 版なのか Stable 版なのかを確認したい場合は、以下のチャネルのリリース ノートを見ていただき、「for Extended Stable release」 は拡張安定版のみ、「Stable and Extended Stable release」 は安定版もあると判断できます。

Microsoft Edge Stable チャネルのリリース ノート:
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-relnote-stable-channel

※ 奇数( 103, 105, 107 等)は Extended Stable 版はございませんので、すべて Stable 版になります。
※ 後述する TargetChannel{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} を指定することで Stable 版から Extended Stable 版へのロールバックや、その逆も可能ではございます。

ロールバックを実行する

ダウンロードした .msi ファイルを利用してロールバックを行います。 ロールバックには管理者権限が必須ですのでご注意ください。

コマンド プロンプトまたは PowerShell を管理者権限で起動します。

1
2
3
4
5
例:
msiexec /I <ロールバック対象の MSI ファイル> /qn ALLOWDOWNGRADE=1

実例:
msiexec /I MicrosoftEdgeEnterpriseX64.msi /qn ALLOWDOWNGRADE=1

Edge を再起動し、ロールバックの確認のためアドレスバーに edge://version を打ち込み、当該 URL にアクセスします。期待するバージョンになっていることを確認してください。

なお、もし期待するバージョンになっていない場合は、ロールバックがまだ完了していない可能性がございます、1 分ほど時間をおいて再度 Edge を再起動しなおして edge://version を確認してください。

なお、edge://version 以外にも edge://settings/help からも確認は可能です。 edge://settings/help で表示させた場合、自動更新を無効化していない場合は自動的に更新が始まる場合がございますのでご注意ください。

①-B SCCM を利用してパッケージ展開によりロールバックする方法

SCCM のパッケージ展開機能を利用してロールバックする方法になります。

Configuration Manager を使用してアプリケーションを作成してデプロイする:
https://learn.microsoft.com/ja-jp/mem/configmgr/apps/get-started/create-and-deploy-an-application

SCCM を利用する方法は手動配布と同様にスクリプトと .msi ファイルを利用します。手動配布と大きく異なるのは SCCM クライアント全体に自動で配布することができることです。

また SCCM の仕組みを利用してオフライン インストーラーを配布するため、後に説明するグループ ポリシーを利用する方法とは異なり、インターネットから Edge アプリケーションをダウンロードする必要がございません。そのためインターネット用の通信帯域に懸念がある場合などは SCCM を利用する方法をご検討いただくのが一番よいかと存じます。

Edge の自動更新を無効化する

手動更新同様に、まずは Edge の自動更新をオフにします。

以下のブログにも記載されているように Edge の更新制御として存在する UpdateDefault または Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} 等の Edge のチャネルごとの制御を 0 (更新を無効にする) に設定します。

Edge の更新制御:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#3-Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E5%88%B6%E5%BE%A1

SCCM の自動展開規則を無効化

\ソフトウェア ライブラリ\概要\ソフトウェア更新プログラム\自動展開規則 にて該当のEdge の自動展開規則を選択し、右クリックメニューから [無効] を選択ください。

SCCM の自動展開規則を無効化

オフライン インストーラーをダウンロードする

オフライン インストーラー (.msi ファイル) を入手します。以下のリンク先から、ロールバック先のバージョンやアーキテクチャ等を選択した上でダウンロードします。

ビジネス向け Microsoft Edge をダウンロードして構成する:
https://www.microsoft.com/edge/business/download

パッケージの作成

.msi を入手後は、以下の手順でパッケージの作成を行います。

  • コンソールにて、[ソフトウェア ライブラリ] - [概要] - [アプリケーション管理] - [パッケージ] を開きます。

  • [パッケージ] を右クリックし、[パッケージの作成] をクリックします。

  • [パッケージとプログラムの作成ウィザード] が表示されますので、[名前] に任意の名前を入力し、[このパッケージにソース ファイルを含める] にチェックを入れます。

  • [ソース フォルダー] の参照ボタンをクリックし、事前にダウンロードしたMSIファイルの格納場所(ローカルドライブ上のフォルダや共有フォルダ)を指定します。

  • 次のページで、[標準プログラム] を指定します。

  • 次のページで、[名前] に任意の名前を指定し、以下の様に指定します。

  • コマンドライン( .msi ファイル名は必要に応じて読み替えください)

    • 64bit OS の場合: %windir%\sysnative\msiexec.exe /I MicrosoftEdgeEnterpriseX64.msi /qn ALLOWDOWNGRADE=1
    • 32bit OSの場合: msiexec.exe /I MicrosoftEdgeEnterpriseX86.msi /qn ALLOWDOWNGRADE=1

  • 実行モード: 管理者権限で実行する

その他の設定項目は既定のまま、パッケージの作成を完了します。

パッケージの展開

パッケージの作成が完了したら、パッケージを展開します。

  • 作成されたパッケージを右クリックし、[展開] をクリックします。
  • ソフトウェアの展開ウィザードが開きます。[参照] をクリックし、配布先のコレクションを指定して [次へ] をクリックします。
  • [コンテンツ] ページにおいて、[追加] をクリックし配布ポイントを選択し、[次へ] をクリックします。
  • [展開設定] ページにおいて、目的を [必須] にし [次へ] をクリックします。
  • [展開スケジュール] ページからスケジュールを以下のように設定し、[次へ] をクリックします。
  • 割り当てスケジュールの [新規] をクリックし、[次のイベントの直後に割り当てる] > [直ちに] をクリックして、[OK] をクリックします。
  • [ユーザー側の表示と操作] において、通知設定を設定し [次へ] をクリックします。
  • [配布ポイント] ページにおいて、展開設定を設定し [次へ] をクリックします。(他のパッケージの展開設定と合わせて頂くとよいかと存じます。)

以降のページを進み、ソフトウェアの展開ウィザードが正常に完了することを確認します。

上記の手順を実施いただくことで、クライアントへの展開は完了します。

各項目のご説明については、次の技術情報を参照いただければ幸いです。

パッケージとプログラムを作成する:
https://docs.microsoft.com/ja-jp/sccm/apps/deploy-use/packages-and-programs#create-a-package-and-program

配布タイミングについて

パッケージを展開した後は、クライアント側で [コンピューター ポリシーの取得および評価サイクル] が実行されることで、コンテンツのダウンロードと実行が行われます。

こちらは既定で 60 ～ 120 分 (60 分 + ランダム時間 [ 1～60 分] )間隔で実行されています。

なお、できる限り早く実行させたい場合は、「クライアント通知」という機能を使用します。「コンピューターポリシーの取得および評価サイクル」を直ちに実行するように、サーバー側からクライアントに通知させることができます。(デバイス単位でもコレクション単位でも実行可能です)

Configuration Manager のクライアント通知:
https://docs.microsoft.com/ja-jp/sccm/core/clients/manage/client-notification

SCCM による配布の補足

作成したパッケージの利用を停止する場合は以下の手順になります。

  • SCCM コンソールより、[ソフトウェア ライブラリ] - [概要] - [アプリケーション管理] - [パッケージ] を開きます。
  • プログラムを選択し、下ペインより [プログラム] に移動します。
  • 下ペインより、プログラム名を右クリック > 無効 をクリックします。ポップアップが表示されるので [はい] をクリックします。
  • 再度、クライアント上でスクリプトを実行する場合は、プログラムを [有効] とします。

グループ ポリシーを利用する方法

ドメイン管理下の端末についてはグループ ポリシーによってロールバックを制御することが可能です。

注意点として、端末それぞれが持つ Edge の更新チェックのタイミングに合わせてロールバックを行います。そのためグループ ポリシーを設定をしてからすぐにロールバックが行われるとは限りません。

更新チェックのタイミングについては以下のブログをご参考いただけますと幸いです。

Edge の更新の流れについて:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E3%81%AE%E6%B5%81%E3%82%8C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

ターゲット バージョンのロールバックの有効化

Edge のチャネルのロールバック機能を有効化させます。通常は Stable 版 (安定版) ですので、以下のポリシーを 有効 にします。 (Extended Stable 版も同様の設定値です。)

RollbackToTargetVersion(ターゲット バージョンへのロールバック):
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-update-policies#rollbacktotargetversion

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: RollbackToTargetVersion{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / 無効
  • 値: 1 / 有効

Beta 版の Edge や Dev 版の Edge などをロールバックさせたい場合は、以下それぞれ別の値を有効にする必要があります。

  • 値の名前:
  • (Beta) RollbackToTargetVersion{2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}
  • (Dev) RollbackToTargetVersion{0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}
  • (Canary) RollbackToTargetVersion{65C35B14-6C1D-4122-AC46-7148CC9D6497}

(Optional) ターゲット チャネルの上書きの有効化

Stable 版から Extended Stable 版にロールバックしたい場合や、Extended Stable 版を止め Stable 版にロールバックしたい場合などについてはこちらのポリシーをご検討ください。

ターゲット チャネルの上書きを指定すると、指定されたターゲット チャネルのアプリケーションが配布されるようになります。

つまり Stable 版の Edge にもかかわらず、ターゲット チャネルの上書きを行えば、Beta 版や Dev 版、Extended Stable 版として認識され、アプリケーションが配信されます。

例えば、以下の図では Stable 版のアプリケーションにもかかわらず、ターゲット チャネルの上書きによって Dev 版を指定することで、よりバージョンが新しい Dev 版の Edge が配布されています。

Stable 版の Edge に Dev のビルドバージョンをダウンロード

※ なお Dev 版については弊社のサポート対象外のバージョンになります。検証用途など以外で配布することは推奨しておりません。
※ Beta 版や Dev 版に適用することで現状修正されていない不具合や意図せぬ状態の変更につながることもございますのでご注意ください。
※ 通常 Stable 版から Extended Stable 版、Extended Stable 版から Stable 版への移行に関してをイメージいただけますと幸いです。
※ Stable 版から Stable 版にロールバックする場合については、この「ターゲット チャネルの上書き」の設定をする必要はございません。

TargetChannel (ターゲット チャネルの上書き):
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-update-policies#targetchannel

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: TargetChannel{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • 値の種類: REG_SZ

詳細:

  • 値: stable / Stable 版を指定
  • 値: beta / ベータ版を指定
  • 値: dev / Dev 版を指定
  • 値: extended / Extended Stable 版を指定

ターゲット バージョンのオーバーライドの設定

次に、ロールバックによって戻りたいバージョンを指定します。

TargetVersionPrefix (ターゲット バージョンのオーバーライド):
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-update-policies#targetversionprefix

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: TargetVersionPrefix{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • 値の種類: REG_SZ

詳細:

  • 値: <バージョン番号を指定> / (例: 108.0.1462.76 など)

※ なお、Stable 版から Stable 版にロールバックしたい場合は、前述した画像のように Extended Stable 版のみ提供しているビルドを指定しないようにご注意ください。Stable 版として提供しているビルドを指定する必要があります。

Stable 版と Extended Stable 版のビルドバージョンの見分け方

TargetChannel のグループ ポリシーによって Extended Stable を指定している場合は Extended Stable のみ提供しているビルドもロールバック可能になります。その場合 Extended Stable 版の更新スケジュールになるため、Edge の奇数バージョンには更新しなくなりますのでご注意ください。

更新ポリシーのオーバーライドを有効化

※ Edge の更新を無効化している場合は、加えてこちらの設定が必要になります。

下記ブログにも述べられている UpdateDefault またはそれぞれのチャネルの Update を個別に有効化します。ロールバックしたい Edge のチャネルに合わせて、「常に更新を許可する (推奨)」または「自動サイレント更新のみ」に設定します。

※ なお Edge は通常ポリシーを設定しない場合、「常に更新を許可する」がデフォルトで設定されておりますので、追加の設定は必要ありません。

Edge の更新制御:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#3-Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E5%88%B6%E5%BE%A1

すべてのチャネルを制御する場合は以下の UpdateDefault のポリシーによって制御可能です。

UpdateDefault (更新ポリシーのオーバーライドの既定値):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#updatedefault

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前: UpdateDefault
  • 値の種類: REG_DWORD

詳細:

  • 値: 0 / 更新を無効にする (すべてのチャネルのアップデートを停止します。)
  • 値: 1 / 常に更新を許可する (推奨) (通常の自動更新になります。)
  • 値: 2 / 手動更新のみ (edge://settings/help による手動更新のみ可能になります。)
  • 値: 3 / 自動サイレント更新のみ (Edge の更新モジュールによる自動更新のみ可能になります。)

個々それぞれのチャネルを制御するには以下の Update ポリシーによって制御可能です。

Update (更新ポリシーのオーバーライド):
https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#update

  • パス: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
  • 値の名前:
  • (Stable): Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
  • (Beta): Update{2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}
  • (Dev): Update{0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}
  • (Canary): Update{65C35B14-6C1D-4122-AC46-7148CC9D6497}

詳細:

  • 値: 0 / 更新を無効にする (すべてのチャネルのアップデートを停止します。)
  • 値: 1 / 常に更新を許可する(推奨) (通常の自動更新になります。)
  • 値: 2 / 手動更新のみ (edge://settings/help による手動更新のみ可能になります。)
  • 値: 3 / 自動サイレント更新のみ (Edge の更新モジュールによる自動更新のみ可能になります。)

上記設定を行い、端末にグループ ポリシーが適用されると、端末は次回の更新チェックのタイミングでロールバックを行います。

更新チェックのタイミングについては以下のブログをご確認ください。

Edge の更新タイミングの制御方法について:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%AE%E5%88%B6%E5%BE%A1%E6%96%B9%E6%B3%95%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

(補足) グループ ポリシーを利用する方法のロールバックのタイミングについて

グループ ポリシーを利用する方法の場合、ロールバックは Edge の更新チェックのタイミングにおいて行われます。

その場合、ロールバック対象のアプリケーションはインターネット上からダウンロードを行います。そのため、ロールバック対象の端末が大量にあり、その端末が同時期にダウンロードを行う場合は、Edge アプリケーションのサイズが 数百 MB 相当あることからも、帯域圧迫が発生する可能性がございます。

帯域圧迫が発生しないように更新制御を行いたい場合は、端末をグループに分けて更新をさせるタイミングを分散させる必要があります。

例えば、以下 UpdatesSuppressed をグループごとに仕掛けることで、時間帯に合わせて更新ができる端末を絞ることができます。

アップデートできない時間帯を指定する方法:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#5-%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84%E6%99%82%E9%96%93%E5%B8%AF%E3%82%92%E6%8C%87%E5%AE%9A%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95

それ以外にも、更新チェックを行うタイミングは既定では前回の更新チェックから 10 時間以上経過しなければ発生しませんが、AutoUpdateCheckPeriodMinutes を設定することでそのタイミングを制御できます。

例えば AutoUpdateCheckPeriodMinutes を 1~59 に指定した場合は、1 時間以内に発生する更新チェックのタイミングで更新を行いますので、1 時間以内にロールバックをさせることが可能です。

更新チェック後の次の更新チェックまでの最低猶予時間を指定する方法:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#6-%E6%9B%B4%E6%96%B0%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E5%BE%8C%E3%81%AE%E6%AC%A1%E3%81%AE%E6%9B%B4%E6%96%B0%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%81%BE%E3%81%A7%E3%81%AE%E6%9C%80%E4%BD%8E%E7%8C%B6%E4%BA%88%E6%99%82%E9%96%93%E3%82%92%E6%8C%87%E5%AE%9A%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95

更新チェックの詳細については以下のブログをご確認ください。

Edge の更新の流れについて:
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-and-why-to-update-edge/#Edge-%E3%81%AE%E6%9B%B4%E6%96%B0%E3%81%AE%E6%B5%81%E3%82%8C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-to-rollback-edge/ 2023-01-22T15:00:00.000Z 更新履歴:
こんにちは。Developer Support チームの大嶋です。

実は Microsoft Edge は Linux 版もあることはご存じでしょうか？
例えば Edge Download サイト の Linux の欄からもダウンロードできます。

今回はその Microsoft Edge の Linux 版 Microsoft Edge on Linux (今回は Ubuntu を想定) で動作する Web アプリケーションにて、例えば事前に ssllogkey を設定し、ネットワークに関連する調査に活用できるネットワークトレースを Linux 上で取得する方法等をご紹介いたします。なお、実際のトラブルシューティングの際は、同時に net-export の取得も併せてご実施ください。

なお、本方法では多くの HTTPS の通信を調査のために見ることも可能であると想定されますが、TLS のバージョンや暗号化の種類等によっては正常に復号できない可能性もあり、全ての HTTPS 通信を分析が可能であることを保証するものではありません。

Edge ブラウザーのキャッシュが利用されてキャプチャーに記録されないことを避けるために、InPrivate ブラウズをご利用いただく方法をご案内していますが、InPrivate ブラウズをご利用いただけない場合には、ログ取得前にブラウザーのキャッシュを下部の補足に記載の方法で必ずすべて消去して実施ください。

0. 前提

1. 事前準備

  1. Ubuntu 上で Microsoft Edge や Google Chrome を含めて、一度、全てのブラウザを閉じます。ブラウザ以外のアプリも出来る限り通信を減らすために閉じます。

  2. System Monitor アプリ等で msedge に関するプロセスがいないことを念の為確認します。

  3. エクスプローラーまたはターミナルのコマンドにて、キーを保存する任意のディレクトリ等を作成しておきます。

1
:~$ mkdir tmp
  1. ターミナルにて上記作成のディレクトリに移動し、以下の echo コマンドで上記で作成した任意のディレクトリ (ここでは ~/tmp と仮定) に空の新規ファイルを作成します。作成後は該当ディレクトリで ls コマンド等で正常に sslkey.log ファイルが存在していることを念の為確認下さい。
1
:~/tmp$ echo > sslkey.log


2. ユーザー環境変数の設定

再ログイン時に自動的に SSLKEYLOGFILE の環境変数を設定するように ~/.bash_profile ファイルに以下の内容で追記で指定しておきます。

1
export SSLKEYLOGFILE=~/tmp/sslkey.log

その後、Ubutsu OS を再起動します。



3. Microsoft Edge on Linux による再現と tcpdump によるキャプチャ

3-1. OS 再起動後に New Microsoft Edge を InPrivate ウィンドウで開きます。
(タスクバー等の Edge アイコンを右クリックで “新しい InPrivate ウィンドウ” で開けます)
※ InPrivate ブラウズをご利用いただけない場合には、ログ取得前に Edge ブラウザーのキャッシュを必ずすべて消去してください。手順は下部の補足をご覧ください。

3-2. ターミナルを開き tcpdump でキャプチャを開始する。ターミナルはそのままにしておきます。

1
:~$ sudo tcpdump -s0 -i any -n -w edgeclient.pcap

※ 上部に記載の通り、net-export で net-export のログも同時に採取開始することも併せてご検討下さい。

3-3. Microsoft Edge にて該当のサイトを開き、素早く事象の再現を行います。

3-4. ターミナルに戻り、取得中のパケットキャプチャを Ctrl + C で停止します。

4. 復号

4-1. Wireshark を開き、上部の [編集] タブを押し、[設定] ボタンを押します。

4-2. 左側の [Protocols] 内の [TLS] を選択します。

4-3. [(Pre)-Master-Secret log filename] の [Browse] ボタンを選択し、sslkey.log ファイルを選択します。


Master secret log file name on Linux



4-4. [OK] ボタンを押し、キャプチャした pcap ファイルを開き、キャプチャした内容を確認します。

4-5. もし私共サポートから本 Blog による情報採取をご依頼された場合は、.pcap ファイルと sslkey.log の 2 つ両方とも提供します。

※ なお、Wireshark 自体のツールや tcpdump コマンドに関するトラブルシューティングや操作方法等のご質問は 3 rd party 製品となる為、Microsoft の技術サポートでは承ることができませんのでご了承ください。

5. 後片付け

もし不要であれば、先の手順で追加した ~/.bash_profile で設定した SSLKEYLOGFILE の export コマンドを削除しておきます。

補足 : ブラウザーのキャッシュ消去について

  1. Microsoft Edge on Linux にて edge://settings/clearBrowserData を開きます。

  2. 以下のように設定し、[今すぐクリア] ボタンをクリックします。

Clear Edge Browser Cache Data on Linux



以上で今回のご紹介は終了です。

なお、私共では様々なお客様のお問い合わせの内容や状況等に合わせて、お問い合わせ後にその他の情報等のご提供もお願いすることもあります。また、多くの場合ではクライアント側のキャプチャだけでは原因究明が出来ないことも多々あり、その場合はサーバー側や中間機器等でも情報を採取いただく必要もございます。

今回はその中のあくまで 1 つである ssllogkey を用いて、Linux 上のクライアント側のブラウザ Microsoft Edge で動作する　Web アプリに関するネットワークトレースの取得方法をご紹介いたしました。

今回は以上です。それでは、また次回！

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/Edge-Linux-sslkeylog/ 2022-09-28T15:00:00.000Z こんにちは。Developer Support チームの大嶋です。

実は Microsoft Edge は Linux 版もあることはご存じでしょうか？
例えば 更新履歴:
2022/06/22 更新
2023/03/14 ターゲット バージョンについて補足

本記事は Technet Blog の更新停止に伴い、もともとばらばらに存在していた記事を一つのブログに集約／移行したものです。
元の記事の最新の更新情報については、本内容をご参照ください。

(※ 2018 年 10 月 11 日に Japan IE Support Team Blog に公開した情報をアーカイブする目的で、Microsoft 社員にて改めて公開しております。)

みなさん、こんにちは。

.NET Framework での TLS 1.1 および 1.2 対応について、以前 .NET Framework で TLS1.1 および 1.2 を有効化する方法 という記事を投稿しています。
しかしながら、記載の内容がわかりづらいこと、また、記事の公開以降に Update できていなかった点があるため、まとめとして本記事を作成しました。
今後のご対応の一助となれましたら大変うれしく思います。

はじめに

本資料は下記の構成でまとめています。

  1. TLS 1.1 および 1.2 に対応するうえでの考え方
  2. Windows OS の TLS 1.1 および 1.2 への対応状況
  3. .NET Framework で利用される既定のプロトコル バージョン
  4. .NET Framework 3.5 で TLS 1.1 および 1.2 を利用できるようにするための更新プログラム
  5. .NET Framework 3.5 で TLS 1.1 および 1.2 を既定値にするための方法
  6. .NET Framework 4.5.2 で TLS 1.1 および 1.2 を既定値にするための方法
  7. .NET Framework のサポート状況
  8. 各 OS ごとの対応方法

また、本資料と併せて下記の資料もご参考ください。

Transport Layer Security (TLS) best practices with the .NET Framework
(日本語訳) .NET Framework でのトランスポート層セキュリティ (TLS) のベスト プラクティス

1. TLS 1.1 および 1.2 に対応するうえでの考え方

.NET Framework で作成されたアプリケーションを TLS 1.2 (TLS 1.1) に対応させるには下記の点を考慮する必要があります。
ご利用の OS が TLS 1.1 および 1.2 を利用できるかどうか、また、アプリケーションで独自に設定しているかどうか、により必要な対応が異なります。
このため、まずは下記の観点で、ご利用対象の環境やアプリケーションについて理解することが第一歩となります。

  • 対象の環境は OS として TLS 1.2 (TLS 1.1) を利用できるかどうか
  • アプリケーション側で ServicePointManager.SecurityProtocol プロパティにすでに明示的に設定しているものがないか
  • アプリケーションがターゲットしている .NET Framework のバージョンはいくつか
  • 稼働対象の環境にインストールされている .NET Framework のバージョンはいくつか
  • アプリケーションを改修することはできるか

各ポイントの詳細については次項以降をご覧ください。

2. Windows OS の TLS 1.1 および 1.2 への対応状況

ご利用対象の Windows OS 自体が TLS 1.1 および 1.2 を利用することができない場合には、.NET Framework 側でいくら対応しても TLS 1.1 および 1.2 に対応することはできません。
.NET Framework での対応の前に、Windows OS 自体を TLS 1.1 および 1.2 を利用できるように構成する必要があります。

！ご注意ください！
Windows OS 自体が TLS 1.1 および 1.2 を利用することができない状態でアプリケーション側で TLS 1.1 および 1.2 が指定されると、アプリケーション実行時に例外が発生します。

Windows Server 2008 SP2

既定の状態では OS として TLS 1.1 および 1.2 を利用することができません。
.NET Framework での TLS 1.1 および 1.2 への対応の前に、事前に下記の更新プログラムを適用し、OS として TLS 1.1 および 1.2 を利用できるようにする必要があります。

Windows Server 2008 SP2、Windows Embedded POSReady 2009、および Windows Embedded Standard 2009 に TLS 1.1 および TLS 1.2 のサポートを追加する更新プログラム

更新プログラム適用後、必要に応じて上記資料に記載のレジストリ値を設定します。

2022/06/22 変更: DisabledByDefault に設定する値を 1 から 0 へ訂正

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]  "DisabledByDefault"=dword:00000000  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]  "DisabledByDefault"=dword:00000000  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]  "DisabledByDefault"=dword:00000000  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]  "DisabledByDefault"=dword:00000000

設定のポイント
クライアント OS として利用する場合 (任意のアプリケーションが別の Web サーバーに接続するような場合) には Client に設定します。
サーバー OS として利用する場合 (Web サーバーのように接続を待ち受けるような場合) には Server に設定します。

Windows Server 2008 R2 / Windows 7

OS としては TLS 1.1 および 1.2 を利用できますが、アプリケーション側より明示的に TLS 1.1 もしくは 1.2 を利用する指定がない限り利用されません。
アプリケーション側からの指定がなくとも利用されるように構成するには、上記の Windows Server 2008 SP2 に記載したレジストリ値 (DisabledByDefault) を必要に応じて設定します。
(参考) TLS/SSL Settings

Windows Server 2012 / Windows 8.1 以降

OS として TLS 1.1 および 1.2 を利用でき、かつ、既定の状態で TLS 1.1 および 1.2 が利用されるように構成されています。
追加で必要な設定はありません。

3. .NET Framework で利用される既定のプロトコル バージョン

.NET Framework では、HttpWebRequest クラスなどを利用した通信において ServicePointManager.SecurityProtocol プロパティに指定されたプロトコル バージョンが利用されます。
プログラム上で明示的に指定されている場合は指定されたプロトコル バージョンが利用されますが、指定されていない場合に利用される既定のプロトコル バージョンは下記のとおりです。
.NET Framework の各バージョンごとに、TLS 1.1 および 1.2 への対応状況と併せてまとめました。

(2023/03/14 追記 ここから)
なお、本記事の 1 で『アプリケーションがターゲットしている .NET Framework のバージョンはいくつか』と示したように、バージョンについて大事なことは、端末にインストールされている .NET Framework ランタイムのバージョンではなく、対象の .NET アプリ開発時にターゲットとして選択する .NET Framework のバージョンであることにご注意ください。参考画面イメージはこちら
具体的には、本記事の 8 に示すそれぞれの表の横軸について、確認対象のアプリがどのターゲット バージョンなのかをもとにみていきます。
(2023/03/14 追記 ここまで)

.NET Framework 3.5 (3.5.1)

既定では TLS 1.1 および 1.2 は未対応
プロパティの既定値は SSL 3.0 および TLS 1.0

.NET Framework 4.5.2

TLS 1.1 / TLS 1.2 に対応済み
プロパティの既定値は SSL 3.0 および TLS 1.0

.NET Framework 4.6.x

TLS 1.1 / TLS 1.2 に対応済み
プロパティの既定値は TLS 1.0、1.1 および 1.2

.NET Framework 4.7.x

TLS 1.1 / TLS 1.2 に対応済み
プロパティの既定値は SystemDefault となり、OS の TLS の設定状態に依存する

.NET Framework 4.8.x

TLS 1.1 / TLS 1.2 に対応済み
プロパティの既定値は SystemDefault となり、OS の TLS の設定状態に依存する

4. .NET Framework 3.5 で TLS 1.1 および 1.2 を利用できるようにするための更新プログラム

.NET Framework 3.5 は既定の状態では TLS 1.1 および 1.2 を利用することができません。
.NET Framework 3.5 で TLS 1.1 および 1.2 を利用できるようにするために下記の更新プログラムを適用する必要があります。
※ 下記更新プログラムはそれ以降の更新プログラムで置き換えられていますので、セキュリティの観点では『Windows 10 および Windows Server 2016 の場合は OS 向けの最新のロールアップ』を、『それ以外の OS では .NET Framework 向けの最新の品質ロールアップ』を適用することをおすすめします。

！ご注意ください！
更新プログラムを適用しない状態でアプリケーション側で TLS 1.1 および 1.2 が指定されると、アプリケーション実行時に例外が発生します。

Windows Server 2008

Support for TLS System Default Versions included in the .NET Framework 2.0 SP2 on Windows Vista SP2 and Server 2008 SP2

Windows Server 2008 R2 / Windows 7

Support for TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and Server 2008 R2 SP1

Windows Server 2012

Support for TLS System Default Versions included in the .NET Framework 3.5 on Windows Server 2012

Windows Server 2012 R2 / Windows 8.1

Support for TLS System Default Versions included in the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2
※ 更新プログラムの適用には Windows 8.1 Update / Windows Server 2012 R2 Update (KB2919355) が事前に適用されている必要があります

Windows 10 v1507 (LTSC)

Windows 10 v1507 環境向けに公開されている更新プログラムを適用します。
※ 本記事執筆時点で、最も古い更新プログラムは下記の 2016 年 10 月に公開された更新プログラムです。下記以降の更新プログラムの適用をご検討ください。
2016 年 10 月 11 日 — KB3192440 (OS ビルド 10240.17146)

Windows 10 v1607 (LTSC) / Windows Server 2016

下記のいずれかの更新プログラム以降で対応されています。
2016 年 12 月 9 日 — KB3201845 (OS ビルド 14393.479)
2016 年 12 月 13 日 — KB3206632 (OS ビルド 14393.576)

Windows 10 v1703 / Windows Server 2019 以降

.NET Framework 3.5 の機能を有効化した時点ですでに対応されています。
追加で適用が必要な更新プログラムはありません。

5. .NET Framework 3.5 で TLS 1.1 および 1.2 を既定値にするための方法

.NET Framework 3.5 は、SSL 3.0 および TLS 1.0 が既定で利用されるプロトコル バージョンです。
既定値を変更するには、Windows OS 側で TLS 1.1 および 1.2 が利用されるよう構成し、かつ、.NET Framework 3.5 で TLS 1.1 および 1.2 を利用できるようにするための更新プログラムを適用したうえで各資料に記載の下記のレジストリ値を設定します。

下記のレジストリ値が設定されると Windows OS 側で構成しているプロトコル バージョンに従うようになります。
Windows OS 側で TLS 1.1 および 1.2 が利用されるよう構成することで、.NET Framework 3.5 で利用されるプロトコル バージョンも TLS 1.0、TLS 1.1 および TLS 1.2 に変更されます。 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]  "SystemDefaultTlsVersions"=dword:00000001

64 ビット OS の環境の場合は下記にも設定します。

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]  "SystemDefaultTlsVersions"=dword:00000001

設定のポイント
プログラム上で ServicePointManager.SecurityProtocol プロパティに明示的に任意のプロトコル バージョンを指定している場合は、上記のレジストリ値の設定の有無にかかわらずプログラムで指定したプロトコル バージョンが利用されます。

6. .NET Framework 4.5.2 で TLS 1.1 および 1.2 を既定値にするための方法

.NET Framework 4.5.2 は、SSL 3.0 および TLS 1.0 が既定で利用されるプロトコル バージョンです。
既定値を変更するには、下記のセキュリティ アドバイザリー 2960358 で公開されている更新プログラムを適用します。
※ 下記更新プログラムはそれ以降の更新プログラムで置き換えられていますので、セキュリティの観点では『Windows 10 および Windows Server 2016 の場合は OS 向けの最新のロールアップ』を、『それ以外の OS では .NET Framework 向けの最新の品質ロールアップ』を適用することをおすすめします。

Microsoft Security Advisory 2960358
(日本語訳) マイクロソフト セキュリティ アドバイザリ 2960358

上記のセキュリティ アドバイザリーを適用すると下記のレジストリ値が構成され、.NET Framework 4.5.2 で利用されるプロトコル バージョンが TLS 1.0、TLS 1.1 および TLS 1.2 に変更されます。
念のためレジストリ値が構成されているか確認し、万が一構成されていない場合は手動で構成します。 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]  "SchUseStrongCrypto"=dword:00000001

64 ビット OS 環境の場合は下記にも設定します。

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]  "SchUseStrongCrypto"=dword:00000001

設定のポイント
プログラム上で ServicePointManager.SecurityProtocol プロパティに明示的に任意のプロトコル バージョンを指定している場合は、上記のレジストリ値の設定の有無にかかわらずプログラムで指定したプロトコル バージョンが利用されます。

7. .NET Framework のサポート状況

.NET Framework 4.x 系は、4.5.2 以降がサポート対象です。
稼働対象の環境にインストールするバージョンは可能な限り最新のバージョンとすることをご検討ください。

.NET Framework サポート ライフサイクル ポリシーについて (2015 年 10 月)
.NET Framework 4 を対象に作成したアプリケーションのサポートについて

各 OS 上での .NET Framework の既定のバージョン

OS ごとに既定でインストールされている .NET Framework のバージョンは下記の資料をご覧ください。
OS によってはクリーンインストールした状態ですでにサポートが終了している状況もあり得るため、インストールすることのできる最新バージョンへの更新をご検討ください。

.NET Framework Versions and Dependencies
(日本語訳) .NET Framework のバージョンおよび依存関係

Installation guide
(日本語訳) インストール ガイド

各 OS 上でサポートされるバージョン

各 OS ごとにサポートされているバージョンは下表のとおりです。
各 OS 上でサポートされるバージョン

8. 各 OS ごとの対応方法

上記までの内容を踏まえたうえでの各 OS ごとの対応方法について下記にまとめました。
なお、.NET Framework 3.5(.1) は、事前に TLS 1.1 および TLS 1.2 に対応するための更新プログラムが適用されていることが前提 です。
また、Windows Server 2008 は、事前に OS 向けの TLS 1.1 および 1.2 に対応するための更新プログラムが適用されていることが前提 です。

各 OS 共通

何度も記載していますが、ServicePointManager.SecurityProtocol プロパティに明示的にプロトコル バージョンを指定している場合には、当プロパティに指定したプロトコル バージョンが利用されます。
下表は当プロパティに TLS 1.2 を設定した場合の対応表になります。
各 OS 共通

ServicePointManager.SecurityProtocol プロパティに明示的に指定していない場合の各 OS ごとの対応表は下記のとおりです。

Windows Server 2008

※ 前提条件 ※
Windows Server 2008 は、既定の状態では OS として TLS 1.1 および 1.2 を利用することができません。
事前に TLS 1.1 および 1.2 を利用できるようにするための更新プログラムの適用が必須 です。
Windows Server 2008

Windows Server 2008 R2 / Windows 7

※ 前提条件 ※
Windows Server 2008 R2 / Windows 7 は OS としては TLS 1.1 および 1.2 を利用できますが、アプリケーション側より明示的に TLS 1.1 もしくは 1.2 を利用する指定がない限り利用されません。
必要に応じて アプリケーション側からの指定がなくとも TLS 1.1 および 1.2 が利用されるためのレジストリ値を設定します。
Windows 7 および Windows Server 2008 R2

Windows Server 2012

Windows Server 2012

Windows Server 2012 R2 / Windows 8.1

Windows 8.1 および Windows Server 2012 R2

Windows 10 v1507 (LTSC 2015)

Windows 10 v1507 (LTSC 2015)

Windows 10 v1607 (LTSC 2016) / Windows Server 2016

Windows 10 v1607 (LTSC 2016) および Windows Server 2016

Windows 10 v1803

Windows 10 v1803

Windows 10 v1809 (LTSC 2019) / Windows Server 2019

Windows 10 v1809 (LTSC 2019) および Windows Server 2019

Windows 10 v1903 / v1909 / v2004 / v20H2

Windows 10 v1903 / v1909 / v2004 / v20H2

いかがでしょうか。
本記事が今後のご対応のお役に立てますと幸いです。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/dotnet-framework-tls12/ 2022-06-21T15:00:00.000Z 更新履歴:
2022/06/22 更新
2023/03/14 ターゲット バージョンについて補足

本記事は Technet Blog の更新停止に伴い、もともとばらばらに存在していた]]>

.NET Framework で TLS 1.1 および TLS 1.2 を有効化する方法 - まとめ - 2026-06-02T06:09:44.944Z Developer Support Internet Japan 更新履歴:
2021/10/06 更新
2021/11/18 更新
2022/04/15 更新

※ 後述の追記の内容をご覧ください

こんにちは！

今回は、新しい Microsoft Edge での file: プロトコルの制限についてお知らせします。
Chromium ベースの新しい Microsoft Edge では、セキュリティ上の制限により file: プロトコルのリンクは機能しません。
この制限は Chromium における制限となりますが、新しい Microsoft Edge 側でこの制限を解除可能なオプションを提供する予定は現状ありません。

Restrictions on File Urls
https://textslashplain.com/2019/10/09/navigating-to-file-urls/

新しい Microsoft Edge においても file プロトコルが使用できるようにするには、サードパーティー製の拡張機能ですが Enable local file links などのご利用や、IE モード のご利用をご検討ください。

以下に動作の具体例をあげます。

A : アドレスバーに file:// の URL を直接入力して開く場合
外部からのアクセスではなく、ファイルを直接開く動作となります。
そのため、ファイルを開くことが可能です。

B : ローカル マシンに保存している HTML ファイルを Microsoft Edge (Chromium) で開いている場合
外部ではなくローカル ファイルからのアクセスのため、file:// のリンク先を開くことが可能です。

C : IE モード を利用した場合
端末にインストールされている Internet Explorer を利用してサイトを開きます。
Internet Explorer の単体利用時と同様に file:// のリンク先を開くことが可能です。

※ IE モードについて、以下の記事もご参照いただければと思いますが、ご利用に関してお困りなことがありましたら私たちサポートまでお問い合わせください！

新しいバージョンの Microsoft Edge の “IE モード” について
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/IEMode/

2021/10/06 追記: なお、こちらのロードマップにて情報公開されました通り、早くて 2021/10/21 の週にリリース予定のバージョン 95 にて file:// のリンクを有効にできる新しいポリシーを追加する見込みです。今後の予定についてはロードマップのドキュメントをご覧ください。

2021/11/18 追記: 2021/10/21 にリリースされたバージョン 95 にて、”ローカル イントラネット” ゾーン、かつ HTTPS のサイトに限って、file:// のリンク押下した場合に、リンクの指定対象ファイル (もしくは対象フォルダ) の一階層上のフォルダ (親フォルダ) をエクスプローラーで開くことを可能とする IntranetFileLinksEnabled ポリシー をリリースしました。セキュリティ上の観点から、ファイルを直接開くわけではなく一階層上のフォルダを開く動作となっています。予めご了承ください。

2022/04/15 追記: 2022/04/01 にリリースされたバージョン 100 から、上記のバージョン 95 と同じ条件でフォルダを開くことができますが、開く対象がフォルダであればそのものがエクスプローラーで開きます。開く対象がファイルであれば、そのファイルが存在するフォルダが開き、対象のファイルが選択された状態になります。

短いですが、今回は以上です。
それでは、また次回！

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/FileProtocol/ 2022-04-14T15:00:00.000Z 更新履歴:
2021/10/06 更新
2021/11/18 更新
2022/04/15 更新

※ 後述の追記の内容をご覧ください

こんにちは！

 新しい Microsoft Edge での file プロトコルの制限について 2026-06-02T06:09:44.916Z Developer Support Internet Japan ＊本記事はこれから日本マイクロソフトのインターンシップ、あるいは就職先として考える学生に向けて、実際に 2021 年のサマーインターンシップに参加してもらった学生に書いてもらいました。
インターン生の率直な感想を皆さんにお伝えするために、普段の内容より少々くだけた表現となっておりますのでご了承ください。
以下からが本文となります。

こんにちは！CSS Developer Support Internet チームでサマーインターンシップに参加しております宮脇（Miyawaki）と申します。
本記事では、私が Microsoft Japan で働いてみた所感と将来のインターン生、今後マイクロソフトを就職先に考える学生に向けた Tips をまとめようと思います。

例えば、以下のような質問に、私見ではありますが回答できればと思います。

  • インターンシップには参加したいけど、不安……
  • Microsoft のインターンシップって何をするの？
  • インターンシップ期間は長いけど、他のことは何もできなくなるの？

目次は以下の通りです。

  1. Microsoft のミッション
  2. Customer Service & Support (CSS) Developer Support Internet について
  3. インターンシップで行ったこと（私の場合）
  4. インターンシップでの学び・所感

それでは、Let’s Explorer the Internship at Microsoft!

2021 年度の場合は、1 ヵ月半のインターンシップのうち、最初の一週間に “Intern Learning Week” という期間が設けられていて、Microsoft の mission や culture について知ることができました。

Our Mission : Empower every person and every organization on the planet to achieve more.（地球上のすべての個人とすべての組織が、より多くのことを達成できるようにする）
Culture :

  • GROWTH MINDSET（成長する考え方）
  • CUSTOMER OBSESSED（お客様に寄り添う）
  • DIVERSITY AND INCLUSION（ダイバーシティ & インクルージョン）
  • ONE MICROSOFT（ワン・マイクロソフト）
  • MAKING A DIFFERENCE（世界を変える）
    参考 : https://www.microsoft.com/ja-jp/mscorp/college/msd-company-mv.aspx

Intern Learning Week で学べる Microsoft のいわゆる「社訓・社風」はすべて上に詰まっているといっても過言ではないでしょう。

ちなみに私が最も好きな Culture は “ONE MICROSOFT” です！
チームとしての Microsoft の団結力は限りなく強固で、他者貢献の意識を非常に重要視しています。
インターンシップに参加していただくことで、よりリアルに肌で感じることができるのではないかと思います。

2. Customer Service & Support (CSS) Developer Support Internet について

Customer Service & Support (CSS) は、Microsoft の製品／サービスを利用するお客様をサポートし、Empower していく役割を担っています。
その中でも、私が所属した Developer Support Internet (DSI) は、Edge, Internet Explorer, IIS (Internet Information Services), Azure Bot Service といったサービスのサポートをを担当しています。

私は「サポート業務」というと、電話の受け答えを淡々と行う業務かと思っていました。
しかし、実際には顧客目線で出来るだけ早く的確な返答を行う高度なコミュニケーション、担当分野に対する専門的で幅広い技術知識、チーム内外での連携するチームワークといったプロフェッショナルスキルを要求される業務でした。

この点については、Microsoft の Culture である “ONE MICROSOFT” や “CUSTOMER OBSESSED” を社員全員が意識している結果が反映されているのではと考えています。

3. インターンシップで行ったこと

インターンシップでは、大きく下の 3 つについて取り組みました。

  • チーム内業務
  • インターン生同士のプロジェクト
  • インターン生個人の活動

まずチーム内業務について、こちらはみなさんが主にイメージしているインターンシップの内容と一致していると思います。
具体的には、CSS のサポート業務の一連の流れについての理解、DSI で担当しているサービスの体験、関連する知識の学習、模擬サポート業務体験が挙げられます。

次にインターン生同士のプロジェクトについて、これは今年度 (FY21) に取り組まれたサマーインターンシップのイベントです。
人事の方が用意してくださった 4 つのテーマから一つ選び、インターン生同士が協力してプロジェクトに取り組みます。
参考までに、私は日本マイクロソフトの組織内に存在するコミュニティーからゲストをお呼びして、
インターン生と社員の交流を促進するためのプロジェクトに所属して、交流の場を儲けるイベントを開催しました。

最後にインターン生個人の活動について、こちらはインターン生がメンターやマネージャーと相談し、目標とやることを明確にしたうえで業務時間中に取り組む活動です。
正直、何をするのかはみなさん次第だと思います。以前のインターン生の活動履歴や、インターンシップ応募時に提出した履歴書の内容がヒントになるかもしれません！

参考までに、私は DSI 内と CSS 全体でそれぞれ勉強会を開催しました。

通常のインターンシップでは味わえないほど、リアルで濃い体験ができると思います。
もちろん、メンターやその他社員の方が相談に乗ってくださりますので、のびのびと活動できるかと思います！

4. インターンシップでの学び・所感

次に、インターンシップでの学びについて簡単にまとめさせていただきます

  • コミュニケーション x 技術
  • GROWTH MINDSET

最初にコミュニケーション x 技術について、これは私がこれからのキャリアを考えたときに、Microsoft でフル活用できると思ったスキルです。 これらは単体でなくセットになったとき初めて CSS で活かされるのだと思います。

具体的にコミュニケーションでは、迅速な返答、わかりやすく言語化する能力、相手の考えていることを推察する能力、お客様に合わせた柔軟な言葉選び等が該当します。
そして技術では、製品／サービスに対する知識、トラブルシューティング能力、既存の知識とトラブル発生の現状を結びつける能力等が該当します。

ただし、決して私も最初からこのような能力があったわけではありませんし、今も全て備えているわけではありません。
それよりもむしろ、インターンシップを通して業務に必要とされている能力と自身に足りない点が明確になったと考えています。そういった点で、インターンシップは有意義でした。

次にGROWTH MINDSET について、こちらは Microsoft の Culture からの引用です。
本インターンシップを通して学んだのは、「GROWTH MINDSET （成長し続ける心）の醸成には明確な目的と行動が必要であること」であり、Microsoft のインターンシップではそれらが実践できます。

今までしてきたことよりも、何をするのか？またその行動の明確な目標と想定されるインパクトは考えているか？
この実践は、これからのキャリア形成のときにも活かされるのではないかと思います。

……と、上では抽象的でポジティブなことばかり書いてきました。
そこで、苦労したことについても取り上げようかと思います。

私がインターンシップで苦労したこと、それは自身の体力・時間の確保です。
私は本インターンシップに加えて、大学院での研究活動、各種作品コンテストの制作等を並行してきました。

なんとなく想像できるかと思いますが、これらすべてを並行して両立することは物理的に難しいです。
どれかが中途半端にならないように、スケジューリングとキャパシティの把握には気を付けておくべきかなと思います。

以上、少しリアルなことについても書きましたが、成長意欲と他人の役に立ちたいという意思を持っておられる方、そしてなにより Microsoft とそのテクノロジーに興味を持っている方は、Microsoft のインターンシップに参加するべきです！
他社では味わえない、リアルな体験があなたを待っています！

最後に

長くなってしまいましたが、インターンシップに参加する方、また参加を検討されている方のお役に立てるのであれば幸いです。
皆さんにとって最高の夏になりますように！Come as you are!

]]> https://microsoft.github.io/jpbrowsers/general/career2-intern-experience/ 2021-11-24T15:00:00.000Z ＊本記事はこれから日本マイクロソフトのインターンシップ、あるいは就職先として考える学生に向けて、実際に 2021 年のサマーインターンシップに参加してもらった学生に書いてもらいました。
インターン生の率直な感想を皆さんにお伝えするために、普段の内容より少々くだけた表現]]> <![CDATA[<Career><第二弾> インターンから見た Microsoft と Developer Support Internet (DSI) チーム (2021)]]> 2026-06-02T06:09:44.916Z Developer Support Internet Japan こんにちは。Developer Support Internet (DSI) サポート チームの大嶋です。

この度は少し前から 我々の DSI チームで採用活動が再開 したこともあり、ぜひ我々のチーム DSI ってどういうチームなのか？を知っていただきたいという思いから、チーム紹介の Blog を開始します！

今回は第一弾ということで、シンプルに我々のチームがサポートしている技術製品を紹介し、テクニカルな面にフォーカスしお話しします。

Developer Support チームということで、お客様の課題解決のために、技術的に幅広く難易度の高い様々な開発系のお問い合わせに触れられることが醍醐味の 1 つであり、それぞれカテゴリごとに技術的な面白さを少しばかりご紹介したいと思います。ちなみに、我々のチームは現在はフルリモートで働いており、既に完全リモートワークを開始して約 1 年半以上が経ちます。(2021 年 11 月現在)

目次

Developer Support Internet がサポートする技術カテゴリは？

その名の通り Developer Support 部門の Internet 周りを担当しているチームのため、主な範囲は Web 系の技術全般と多種多様です。

まず、大きく分けて、オンプレミス製品は Web のクライアントサイドとして Web ブラウザ、サーバーサイドとして Web サーバー・アプリの 2 つのカテゴリがあります。更に、オンプレミス製品のみならず、以下に挙げた Azure 製品カテゴリも一部サポートしております。

  • ブラウザ : Chromium ベースの Microsoft Edge, WebView2, IE モード, Internet Explorer etc…
  • Web サーバー・Web アプリ : IIS (Internet Information Services), ASP.NET, ASP.NET Core, Blazor etc…
  • Azure : Azure Bot Service, Bot Framework SDK, Azure SignalR Service, Azure PubSub Service

各製品の開発はグローバルで行っているため海外の各関連部門と連携する機会もあり、楽しみの 1 つです。また、DSI のサポートエンジニアの中でも各カテゴリの中で得意領域等がありますが、Web ブラウザ領域は現在 DSI チーム全員で担当している領域です。

それでは、それぞれの紹介を深掘りしていきましょう。

ブラウザ領域

Web ブラウザのサポート領域は Chromium ベースの Microsoft Edge, Microsoft Edge WebView2, Internet Explorer、それに付随するコンポーネントとなり、多岐に渡ります。また、Chromium ベースの 新しい Microsoft Edge は Windows だけでなく、Linux や Mobile (Android や iOS) でも動作します。

そのため、調査・解析にあたって、技術的に触れることができる領域というのもそれに伴い、数えきれないほど多様なエリアとなります。Microsoft Edge の加速化に伴い、お問い合わせも日々増加傾向にあり、以前より更にお問い合わせ内容の幅も大きく広がっています。また Web ブラウザ領域は現在 DSI チーム全員で担当していることもあり、それぞれのエンジニアが感じる魅力も異なるのでは？という疑問から実際に複数人にヒアリングをしてみました。以下に回答いただいた魅力の一部を紹介します。

  • ブラウザは世界中のユーザーが、必ず利用する様々なサービスの入り口となる存在で必要不可欠であり、OS に匹敵する巨大なプラットフォームで最先端の Web 技術に触れられる
  • 通信ログやパケット、メモリダンプ等の様々なレイヤーの情報を状況毎に多角的に判断・利用し、最終的にお客様の問題解決ができたことに喜びを感じる
  • Microsoft Edge も採用した Chromium のサポートを通じてグローバルのモダンな Web 業界の発展に貢献できる
  • ブラウー サポートの職という希少なプロフェッショナルとして働くことができ、世界的なシェア向上に貢献できる
  • バージョンアップのスピードが加速しており、大変な面もある反面、より新しいことができるようになる瞬間を身近に感じることができる

ここに記載出来ない魅力も沢山あります。少しでも興味を持ち、アプリケーションの中でも稀有なブラウザに興味がある、Edge のシェアを伸ばしたい、Web 技術の発展の一端に触れたいといった方はぜひ我々と一緒に働きましょう！下部の応募サイトにてお待ちしております。

Web サーバー・Web アプリ領域

それでは今度は別のカテゴリに移ります。我々のサポートする Web サーバー・Web アプリ領域も近年、実は Web ブラウザ同様、多様化しております。

まず、古くからサポートしている Microsoft の各種 Web 製品を支えている以下の 3 つが挙げられます。

上記の各コンポーネントは各種 Office 製品や Azure 製品の基盤としても利用されているものもあり、クラウド化が進む現在でも、重要な技術の 1 つです。また、内部的に Windows OS の各標準コンポーネントを利用していることから、関連チームともコラボレーションをしながら OS のネットワークレイヤーや認証等の幅広い知識にも触れることができます。また、Classic ASP や WCF といったテクノロジーもサポートしています。

更に近年は、Windows OS 上の Web アプリ開発には留まりません。Microsoft はクロス プラットフォーム化にも力を入れており、DSI ではクロス プラットフォームで動作する以下の製品をサポートしています。

macOS や Linux 上、もちろん Linux コンテナ上でも動作が可能な .NET Core/.NET ベースの ASP.NET Core という Web アプリ開発のプラットフォーム、それに付随する MVC や Web API 等の ASP.NET Core 用のフレームワークをサポートしております。ASP.NET と異なり、ASP.NET Core は IIS にも Windows OS にも縛られません！

更には、サーバーサイドにも留まらず、WebAssembly (wasm) を活用したフロントエンド フレームワーク Blazor wasm もサポートしており、近年注目が集まる wasm の最新技術の一端に触れることもできます。加えて、WebSockets を含む双方向通信をサポートするための ASP.NET Core SignalR というフレームワークや .NET の gRPC もサポートしており、多様化するプロトコルもサポート範囲となります。

Azure 領域

本チームの特徴は、上記のオンプレミス製品に加えて、以下の Azure クラウド製品にも触れることができる点です。

Azure Bot Service と Bot Framework SDK を利用することで、Bot アプリを開発・運用が可能です。Web Chat という Web アプリ用のクライアントに加えて、Teams やサードパーティ製の LINE や Slack 等様々なクライアントチャンネルをサポートしていることも特徴の一つです。

また、Bot Framework SDK は C# (.NET Core) だけでなく、JavaScript (Node.js) や Python といった別のプログラミング言語に触れることもできます。

加えて、Azure Bot Service を利用している場合の多くは Azure Web Apps という PaaS サービス) に Bot アプリをホストしてお客様が多いことから、Azure Web Apps の専任チームと連携をしながら、PaaS の知識も蓄えることができます。また、Azure 製品という側面から、他の Azure PaaS、Azure Net、Azure AI 部門等の他の各 Azure 製品のサポート チームと連携が必要不可欠で、それらの Cloud に関する知識も得られます。

更に、Azure SignalR Service や Azure PubSub Service (Preview) 製品をサポートしており、WebSockets を含む双方向通信等の知識が必要となる Azure マネージドな製品の技術支援も行っております。

最後に

まとめ

Developer Support Internet チームでは、技術的な面は勿論のこと、技術以外にも伝えきれないほどの魅力、多くのやりがいがまだまだございます。長くなってしまうので、我々のチームならではの上記以外の部分のご紹介は次回以降に持ち越しますが、”Microsoft のテクニカルサポートの魅力や一般的な仕事内容自体が気になる” という方向けに、同じサポート部門の方の以下 2 つの記事のご紹介をして終わろうと思います。

なぜ今サポートエンジニアが熱いか
Escalation Engineer の Rika さんのインタビュー

さらに、動画でも我々テクニカルサポート部門の仕事をご紹介してます。ぜひこちらもご覧ください。

マイクロソフト カスタマーサービス＆サポート ‐ How we deliver best customer experience | 日本マイクロソフト

現在、我々のチームは採用中です！！

最後に、我々 Developer Support Internet チームも、採用活動中です。少しでもご興味を持っていただいた方は、以下から現在ご応募をお待ちしております！

Developer Support Internet (DSI) チームの採用応募ページ
※ あくまで現在 11/2 時点で採用活動中であり、タイミングによって採用が終了している、上記リンクが有効でない可能性もございますので、その点ご了承ください。

そして、本ブログ内容を見て、まだその分野に詳しくない…技術的なスキルに不安がある…という方、少しでも上記の内容に興味があれば、ぜひご応募をお待ちしております。技術的な部分は本業務を通じて学べる環境がありますし、チームでフォローしていますのでご安心ください！そのため、上記の募集要項に満たないけど、興味がありぜひ受けてみたいという方も、まずはご応募をご検討ください！

なお、本チームだけではなく、Microsoft やテクニカルサポートの仕事等に興味が出てきたという方は、Microsoft では様々な多種多様な職種を募集しております。ぜひ以下の募集から興味のあるチームを探してみて頂ければと思います。

Microsoft Careers - Microsoft 採用検索サイト
サポートエンジニア - キャリアイベント

]]> https://microsoft.github.io/jpbrowsers/general/career1-dsi-technologies/ 2021-11-01T15:00:00.000Z こんにちは。Developer Support Internet (DSI) サポート チームの大嶋です。

この度は少し前から みなさん、こんにちは!

サイトにアクセスした際に、Edge や IE モードなど指定したブラウザでページを表示させるために設定する Enterprise Mode Site List (以下、サイトリスト) に関連して、
「設定したのにうまく反映されない」、「IE モードで開かれない」、
「Edge で開かれず IE ブラウザで開かれる」など、様々なお問い合わせをいただいております。

サイトリストに関するお問い合わせは多岐に及び、その原因もお客様の環境によって様々なため、画一的にこのログを取得すれば原因がわかるということはございません。

ただし、お問い合わせいただいた最初の段階で、問題の把握 のためによく取得をご依頼するログがあるため、それを サイトリストの調査に必要な基本的なログ情報 として以下おまとめいたしました。

事象が発生した際は、こちらをご参考にログ採取を行い、弊社サポートチームにご提供いただけますと幸いです。

調査を加速させ、翻ってお客様の問題解決までの時間を短くすることが可能になります。
(※ なおあくまでもこちらのログ取得は 問題の把握 のために利用するものであり、こちらのログをいただくことによって 原因究明 を保証するものではございません。状況によってはさらなるログ採取をご依頼することがございますので、予めご了承ください。)

目次

取得いただきたいログについて

取得いただきたいログは以下 6 点ございます。

  • 1 事象に関連する発生頻度、発生するサイトなど関連情報
  • 2 PowerPoint 等による動画撮影、または、ステップ記録ツールによる事象の記録
  • 3 IEDigest による適用されている GPO や レジストリ設定
  • 4 edge://policy による Edge に関連するポリシー設定
  • 5 edge://compat/iediagnostic による サイトリストに関連するポリシー設定
  • 6 サイトリストとして設定されている .xml のスキーマファイル

それぞれについて説明を行います。

事前準備が必要なものについて

取得いただきたいログの中で、唯一事前にインストールが必要なのが IEDigest です。

IEDigest のインストール

IEDigest のインストーラを以下の URL よりダウンロードします。

リンクをクリックすると自動的にダウンロードが開始されます。

端末によってはダウンロード時に以下のような警告が表示される場合がございますが、その場合は [もっと見る] からダウンロードを行ってください。

ダウンロード後、以下の画像のように 2 つのファイルが確認できる場合は、iedigest.exe を利用します。

iedigest.exe を起動すると、最初はライセンスに同意するかと表示されますので、[Agree] を選択します。

事前準備はこれにて完了です。

1 事象に関連する発生頻度や発生するサイトなど関連情報

我々サポートチームが調査をするにあたって、「何をお客様が問題として捉えているのか、そして理想的な状態はどのようなものか」を明確に把握する必要がございます。

そのため、弊社にご連絡をする際には以下の 2 択の質問についてメモ帳などにコピーペーストを行い、それぞれの質問についてお答えしたファイルをご提供いただけますと幸いです。

  • 事象が発生する頻度は 100% か [YES/NO]
  • 複数のサイトにおいて事象は発生するか、それとも単一のサイトにおいてのみ事象は発生するか [複数/単一]
  • 事象はユーザー全員で発生するか、複数のユーザーで発生するか、それとも単一のユーザーのみか [全員/複数/単一 複数の場合はその共通項]
  • 事象が発生するサイトのパスはどこか [http[s]://<path>]
  • 事象が発生せず問題なくサイトリスト通り読み込めるサイトはあるか [YES/NO, YES の場合はサイトのパス http[s]://<path\ ]
  • いつから発生したか [XXXX/XX/XX XX:XX]
  • 事象が発生した以前にはサイトリストを設定できていたのか [YES/NO]
  • 事象が発生する以前と以後でなにか設定を行ったか [YES/NO, YES の場合はその詳細]

特に時間については非常に重要なため、できる限り正確な日時をお答えください。まとめたら CheckList.txt などの名前としてテキストファイルを保存します。

2 PowerPoint の動画撮影またはステップ記録ツールによる事象の記録

我々サポートチームが調査をするにあたって、「何をお客様が問題として捉えているのか、そして理想的な状態はどのようなものか」を明確に把握する必要がございます。
そのために事象を動画などで記録することをお願いしております。

そのために利用するのが、PowerPoint による動画撮影 または ステップ記録ツール (以下、PSR) です。

PowerPoint の動画撮影による事象の記録方法

  • PowerPoint を開きます。

  • [記録] を表示し、[画面録画] を選択します。

  • ( ※もし [記録] がない場合は、[挿入] から [画面録画] を選択します。)

  • 領域の選択が行えますので、こちらでディスプレイ全体または対象のブラウザやアプリケーションなどを選択し、録画ボタンを押します。 (なおオーディオは状況に応じてオフにしていただいても構いません)

  • 録画が開始されるので、事象を再現させその一部始終を記録します。

  • 記録が終わりましたら [Windows] + [Shift] + [Q ボタン] を押すか、画面中央上部にマウスカーソルをあわせ ■ のマークをクリックして停止を行ってください。

  • PowerPoint に動画が貼り付けられておりますので、 [メディアに名前を付けて保存] を選択し、保存した動画ファイルをご提供ください。

    ※ なお PowerPoint がない場合は [Windows] + [G ボタン] でゲームバーを開き、そこから動画取得する方法もございますが、今回は詳述いたしませんので、PowerPoint がインストールされていない環境などではそちらをお調べいただき動画撮影をいただけますと幸いです。
    ※ もしくはディスプレイ自体をスマホなどで撮影頂く方法でも構いません。(その場合は視認がしやすいように画質に注意してください。)

PSR による事象の記録方法

事象の確認のために、原則として動画撮影を推奨しておりますが、同時に以下の PSR による画面キャプチャによるログ取得もいただけますと幸いです。

PSR の事前設定

PSR は、画面上の操作（クリックなど）の際にスクリーンショットが記録されるものです。これにより問題発生時の GUI 上での動作を確認することができます。

  • [スタート ボタン] を開き、”PSR” と入力し、[ステップ記録ツール] を開きます。

  • 起動しましたら、右端の [?] マークをクリックし、[設定] を開きます。

  • [保存する最新の取り込み画像数] に “999” を設定します。

  • [記録の開始] をクリックします。

  • 一連の操作を行い、現象を再現させます。

    ※ 事象が発生しても例えばその画面を操作をせずに取得を終了すると事象発生時の画面状態が記録されません。操作が可能な場合、事象発生後の画面上でクリックをする／ウィンドウを動かす、閉じるなどの操作を実施頂き、事象再現時の状況のスクリーンショットが取得されるようにしたうえで以降の記録の停止を実施ください。
    PSR によってキャプチャが行われる際は、以下の画像の様に赤い丸が出現し、フェードアウトします。 こちらが生成されていない場合は記録がされていませんのでご注意ください。

  • [記録の停止] をクリックします。

  • “名前を付けて保存” のダイアログが表示されますので、ファイルの保存場所、ファイル名を指定し、 [保存] をクリックします。

ステップ記録ツールの取得方法について: https://support.microsoft.com/ja-jp/help/22878/windows-10-record-steps

3 IEDigest によるログ取得

  • ダウンロードした IEDigest のツール (iedigest.exe) をダブルクリックします。

  • [Reports] タブの [Create report] をクリックすると、ログが取得されます。

  • [Compare] タブに出力先設定がございますので、保存されたログをご提供ください。

4 edge://policy による Edge に関連するポリシー設定の取得

  • Edge を起動し、アドレスバーに edge://policy と入力します。
  • [JSON にエクスポート] を行い、その出力した JSON ファイルをご提供ください。

5 edge://compat/iediagnostic による サイトリストに関連するポリシー設定の取得

  • Edge を起動し、 edge://compat/iediagnostic と入力します。

  • [診断データをエクスポート] という項目の [Export] をクリックし、出力される .xml ファイルをご提供ください。

    ※ なお、ダウンロードの際に Edge による警告が表示される場合もございますが、こちらは無視し […] から [保存] を選択ください。

6 サイトリストとして設定されている .xml のスキーマファイル

現在サイトリストとして参照されている .xml のスキーマファイルを edge://compat/iediagnostic または GPO またはレジストリから参照し、取得します。

edge://compat/iediagnostic で検索する場合

  • edge://compat/iediagnostic のページの下部に存在する[エンタープライズ モード IE の Web サイト一覧を使用する (IE ポリシー)] と、
    [エンタープライズ モード サイトリストを構成する(Edge ポリシー)] のいずれかまたは両方において指定されているサイトリストをご提供ください。

GPO で検索する場合

いずれかの 2 箇所を確認します

  • [コンピューターの構成 または ユーザーの構成] - [管理用テンプレート] - [Microsoft Edge] - [エンタープライズ モード サイト一覧を構成する] に存在する、.xml ファイルのパス
  • [コンピューターの構成 または ユーザーの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Internet Explorer] - [エンタープライズ モード IE の Web サイト一覧を利用する] に 存在する .xml ファイルのパス

レジストリで検索する場合

いずれかの 2 箇所を確認します

  • キー (HKEY_LOCAL_MACHINE または HKEY_CURRENT_USER)\Software\Policies\Microsoft\Edge の InternetExplorerIntegrationSiteList の バリューとして存在する .xml のファイルパス

  • キー (HKEY_LOCAL_MACHINE または HKEY_CURRENT_USER)\SOFTWARE\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode に存在する SiteList のバリューとして存在する .xml のファイルパス

※ それぞれにおいて異なるサイトリストが指定されている場合もございますので、指定されているすべての .xml ファイルをご提供ください。

アップロードについて

以上のログ採取により以下 6 点のログ取得をいただきました。

  • 事象に関連する発生頻度、発生するサイトなど関連情報についての CheckList.txt ファイル
  • 動画ファイルまたは PSR の.zip ファイル
  • IEDigest の .zip ファイル
  • edge://policy の .json ファイル
  • edge://compat/iediagnostic の .xml ファイル
  • サイトリストの .xml スキーマファイル

これらすべてのログを 1 つの .zip ファイルにまとめ、ファイル名として 202X-XX-XX-SiteList-Basic-Log-Collection.zip のような形にしてご提供ください。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/enterprise-mode-site-list-basic-log-collection/ 2021-09-06T15:00:00.000Z みなさん、こんにちは!

サイトにアクセスした際に、Edge や IE モードなど指定したブラウザでページを表示させるために設定する Enterprise Mode Site List (以下、サイトリスト) に関連して、

Enterprise Mode Site List (サイトリスト) のお問い合わせの調査に必要な基本的なログ情報について 2026-06-02T06:09:44.954Z Developer Support Internet Japan みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

今回は Chromium の機能である net-export を使用して、Chromium Edge のネットワーク レベルのイベントや状態に関する詳細情報を確認する方法を紹介します。
サポートにお問い合せいただいたときにも、今回の手順でログを取得いただくこともありますので、以下を参考にしていただければと思います。

ログの取得方法

  1. Microsoft Edge を起動し、アドレス バーに edge://net-export/ を入力してページを開きます。

  2. OPTIONS で、[Include raw bytes (will include cookies and credentials)] をオンにします。
    ログ取得の設定

  3. [Start Logging to Disk] をクリックします。
    ログ取得の開始

  4. ファイル名を入力し、保存場所を選択します。

  5. [保存] をクリックします。
    保存するファイル名を指定

  6. 新しいタブを開き、問題を再現させます。
    現象の再現

  7. 現象再現後に net-export のタブに戻り、[Stop logging] をクリックします。

  8. 停止すると以下の画面になります。
    ログ取得の終了

保存したログの確認方法

上記の手順で取得した json ファイルは、以下のようにして任意の PC で表示できます。

  1. Microsoft Edge を起動し、https://netlog-viewer.appspot.com/ を開きます。
    ※ netlog-viewer は、クライアント (ブラウザー) 上だけで json ファイルを解析して視覚化します。外部へデータを送信することはありません。

  2. [ファイルの選択] をクリックして json ファイルのパスを指定します。
    表示するログ ファイルの選択

  3. ファイルが読み込まれると以下の画面になります。
    ログの表示画面

左側のメニューから各種情報を確認できます。

  • Import
    net-export で取得した json ファイルを読み込みます。

  • Proxy
    ブラウザで使用しているプロキシ設定に関する情報を表示します。プロキシを使用していない場合は、”Use DIRECT connections” と表示されます。

  • Events
    発生したイベントのリストを表示します。イベントには、ソケット接続、SPDY セッション、HTTP-TCP 接続、URL 要求などがあります。エラーは赤い文字で表示されます。

  • Timeline
    開いているソケット数、使用中のソケット数、URL 要求、DNS 要求、送受信したデータ量などの情報をグラフに表示します。

  • DNS
    端末の DNS ルックアップのログを表示します。ウェブページを読み込めない場合の問題のトラブルシューティングに役立ちます。ログには、URL とそれに対応する IP だけでなく、DNS 要求の時間も示されます。

  • Sockets
    開いているソケットと使用されているソケットのログを表示します。このログはネットワークの高度なトラブルシューティングに使用します。

  • Alt-Svc
    代替サービス マッピングに関する情報を表示します。

  • HTTP/2
    HTTP/2 セッションと代替サービス マッピングのログを表示します。

  • QUIC
    Quick UDP Internet Connections（QUIC）に関する情報を表示します。これは、TCP を使用する接続指向のウェブアプリを最適化するネットワーク プロトコル（試験運用中）です。

  • Reporting
    送信元の設定、ネットワーク エラーのログ記録に関するポリシー、キューに登録されたレポートを表示します。

  • Cache
    キャッシュされたエントリと統計情報のリストを表示します。

  • Modules
    アクティブな Edge / Chrome 拡張機能とアプリのリストを表示します。

  • Prerender
    アクティブな事前レンダリング ウェブサイトとその履歴を表示します。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-to-use-net-export/ 2021-05-20T15:00:00.000Z みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

今回は Chromium の機能である net-export を使用して、Chromium Edge のネットワーク レベルのイベントや状態に関する詳細情報を確認する方法]]>

net-export の使い方 2026-06-02T06:09:44.964Z Developer Support Internet Japan みなさんこんにちは！

Microsoft Edge に組み込まれた サイト リスト マネージャー をご紹介します。

モダンなブラウザーにまだ対応できていないサイトを IE モードで表示させたい場合や、逆にモダンなサイトを IE で開こうとした場合に Edge に転送したい場合などにサイト リスト (.xml) をご利用いただいているかと思います。

これまでサイト リストの作成を支援するために スタンドアロンの Enterprise Mode Site List Manager というツール を提供してきましたが、今後は機能の更新は行われませんので、代わりに Microsoft Edge の組み込みの機能をご利用ください。

この機能は Microsoft Edge の Enterprise Site List Manager でもご紹介していますが、今回は画面ショットを交えてご説明していきます。

  1. Microsoft Edge を起動してアドレスバーに edge://compat/sitelistmanager と入力し開きます。

※ 以下ポリシーを設定することで、「Microsoft Edge の互換性」の画面 (edge://compat/) に「エンタープライズ サイト リスト マネージャー」へのメニューを追加することもできます。

  [コンピューターの構成]or[ユーザーの構成]   ＋[管理用テンプレート]    ＋[Microsoft Edge]  「Enterprise Mode Site List Manager」有効

エンタープライズ サイト リスト マネージャー

  1. 「サイトの追加」をクリックします。
    サイトの追加

  2. Web サイトの URL を指定します。この時 https:// や http:// などのプロトコルの指定を含めてはいけません。
    URL の指定

  3. Web サイトを開くブラウザーを選択します。
    IE モードについては こちらのブログ記事 をご参考ください。
    ブラウザーの選択

  4. Web サイトに合わせて互換モードを選択します。いままでサイトリストでの制御をおこなっていない場合は “既定のモード” にします。

IE モードで開く場合のドキュメント モードの指定

  1. 必要に応じてコメントを記載します。そして「追加」をクリックして Web サイトをエンタープライズ サイト リストに追加します。
    コメントの入力

  2. 必要に応じて「XML プレビュー」を使用してエクスポート時に作成される XML の内容を事前に確認します。
    サイト リスト (XML 形式) のプレビュー

サイト リスト (XML 形式) の内容

また、フィルターを利用してどの URL を追加したか確認できますのでこちらもご活用ください。
検索方法

  1. Web サイトの追加や確認が完了したら、XML ファイルに書き出すため「XML にエクスポート」をクリックします。
    エクスポート

  2. バージョン番号とファイル名を指定し、XML ファイルに「エクスポート」します。
    XML ファイルはダウンロード フォルダーに保存されます。
    エクスポート

以上の方法でサイト リストを作成することができます。
会社に管理された環境で新たなソフトウェアをインストールできない場合でもこの方法ならサイト リストを作成できますね。

<参考情報>

エンタープライズ モードとエンタープライズ モード サイト一覧

エンタープライズ モード スキーマ v.2 ガイダンス

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/edge-ie-mode-site-list-manager/ 2021-05-19T15:00:00.000Z みなさんこんにちは！

Microsoft Edge に組み込まれた サイト リスト マネージャー をご紹介します。

モダンなブラウザーにまだ対応できていないサイトを IE モードで表示させたい場合や、逆にモダンなサイトを IE で開こうとした場合]]>

Microsoft Edge 組み込みのサイト リスト マネージャーについて 2026-06-02T06:09:44.952Z Developer Support Internet Japan みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

本日、以下の情報が公開されました。
FAQ を含め日本語での資料が充実していますので、まず以下のふたつの公式ドキュメントを一通りご覧ください。

Internet Explorer は Microsoft Edge へ – Windows 10 の Internet Explorer 11 デスクトップアプリは 2022 年 6 月 15 日にサポート終了

「Internet Explorer 11 デスクトップ アプリケーションのサポート終了」の発表に関連する FAQ

(英語原文)
The future of Internet Explorer on Windows 10 is in Microsoft Edge—the Internet Explorer 11 desktop application will be retired on June 15, 2022

Internet Explorer 11 desktop app retirement FAQ

以下には上記の公式ドキュメントにある内容から要点のみ簡潔にまとめています。

2022 年 6 月 15 日に Windows 10 の Internet Explorer 11 “デスクトップ アプリ” のサポートを終了し、Microsoft Edge に組み込まれている “IE モード” で少なくとも 2029 年までは引き続きサポートします。

サポート終了対象

  • 半期チャネル (SAC) で配信される以下の OS 上の Internet Explorer 11 デスクトップ アプリ (スタンドアロンの IE11)
    • Windows 10 desktop 全エディション (20H2 およびそれ以降にリリースされるバージョン)
    • Windows 10 IoT (20H2 およびそれ以降にリリースされるバージョン)

サポート終了対象外

  • IE モード
  • Internet Explorer platform (MSHTML / Trident) (WebBrowser コントロールの利用)
  • 現在リリースされている 以下の OS 上の Internet Explorer 11 デスクトップ アプリ (スタンドアロンの IE11)
    • Windows 8.1
    • Windows 7 ESU
    • Windows 10 Server SAC (全バージョン)
    • Windows 10 IoT LTSC (旧 LTSB 含む) (全バージョン)
    • Windows 10 Server LTSC (旧 LTSB 含む) (全バージョン)
    • Windows 10 client LTSC (旧 LTSB 含む) (全バージョン)

なお、上記 Windows OS のサポート終了日は こちらの “8) IE モードはいつまでサポートされますか？” の部分にある表 をご覧ください。

  • IE でなければ閲覧できない古い技術を使って作成されたレガシーな Web サイトは、2022 年 6 月 15 日以降は IE モードで閲覧してください。(以下のイメージをご覧ください)
  • スタンドアロンの IE についてはサポートを終了しますが、IE モードは少なくとも 2029 年まではサポートされますので、IE モードへの移行、さらには Edge への移行 (HTML5 に対応したモダンなウェブ アプリへの移行) を計画的に進めていただくことをお勧めします。
  • IE モードのよくあるご質問は こちら をご覧ください。

これまで : 二つのブラウザーを使い分ける

これまで : IE と Edge Legacy のブラウザーを使い分ける

これから : 一つの Edge を利用する

これから : IE が Edge に統合されて IE モードとして利用できる

(参考) 関連する記事

これまでに当サポート チームで公開した記事
その他弊社社員が作成した資料
]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/internet-explorer-app-end-of-support/ 2021-05-19T15:00:00.000Z みなさんこんにちは。日本マイクロソフトの IE/Edge サポートチームです。

本日、以下の情報が公開されました。
FAQ を含め日本語での資料が充実]]>

Internet Explorer 11 デスクトップ アプリのサポート終了へ! IE モードへの移行を進めましょう! 2026-06-02T06:09:44.968Z Developer Support Internet Japan 更新履歴:
2020/9/9 更新: 今後に関する最新情報を追記しました。
2020/10/28 更新: Update for Removal of Adobe Flash Player がリリースされました。
2020/10/30 更新: Flash のブロックに関して追記しました。
2020/11/06 更新: 古くなった情報を削除し、最新情報を見やすくしました。よくあるお問い合わせを追記しました。
2020/12/09 更新: Adobe 社の公開情報をもとに、『Flash の既定で無効化』について追記しました。
2021/1/5 更新 : 2020 年 12 月末をもって Adobe Flash Player のサポートを終了しました。
2021/1/12 更新 : 『Flash の実行ブロック』について内容を更新しました。
2021/4/28 更新 : KB4577586 (Update for Removal of Adobe Flash Player) について更新しました。

弊社も Adobe 社も 2020 年 12 月末をもって Adobe Flash Player のサポート (お問い合わせの受付やセキュリティ更新の提供) を終了しました。セキュリティの観点からは 2021 年夏予定の Flash の永久削除を待つのではなく、『Update for Removal of Adobe Flash Player』を使用してできる限り早急に自発的に Flash を永久削除することをお勧めしています。

2020 年 9 月 4 日に今後の最新情報が公開されました。以下に概要をまとめます。

Update on Adobe Flash Player End of Support
https://blogs.windows.com/msedgedev/2020/09/04/update-adobe-flash-end-support/

Adobe Flash Player のサポート終了に関する最新情報
https://blogs.windows.com/japan/2020/09/14/update-adobe-flash-end-support/

  • これまでの予定と変わりなく、Adobe Flash Player のサポート終了は 2020 年 12 月 31 日です。
  • それ以降の法人向け対応サポートについては、Adobe 社の情報をご覧ください。
  • Adobe 社の情報で案内される法人向け対応サポート契約を結び、今まで弊社から提供をしてきた Adobe Flash Player に代わるプラグインの提供を受けた場合、それを『Internet Explorer 11』 および 『Microsoft Edge (Chromium 版) の IE モード』で動作させることができますが、『サードパーティー製のプラグイン』の扱いとなり弊社でのサポートはありません。
  • 2021 年 1 月リリース予定 の Microsoft Edge (Chromium 版) の バージョン 88 にて Flash が削除される予定 です。
  • 2020 年末以降は、 Microsoft Edge (EdgeHTML 版) と Internet Explorer 向けの『Adobe Flash Player のセキュリティ更新プログラム』の提供はありません。
  • 2021 年 1 月初旬に、Microsoft Edge (EdgeHTML 版) と Internet Explorer で Flash は既定で無効化され、また、2020 年 6 月リリースの KB4561600 より古いバージョンの実行はブロックされます。
  • Windows OS のコンポーネントとしての Flash を永久的に削除するための『KB4577586 Update for Removal of Adobe Flash Player』というタイトルの更新プログラムがリリース予定です。この更新を適用したあとは元に戻すことはできません。
  • 2020 年 10 月 28 日 (日本時間) から『KB4577586 Update for Removal of Adobe Flash Player』を Microsoft Update カタログから入手 できるようになりました。2020 年 12 月 31 日のサポート終了より前に Flash を永久削除したい場合は、カタログから更新プログラムを入手して実行できます。
  • 『KB4577586 Update for Removal of Adobe Flash Player』は、2021 年の初めに Windows Update (オプション) と WSUS で配信予定で、その 2 ～ 3 か月後には Windows Update では推奨として配信予定です。

ロールアップ更新への組み込みについて
以下のスケジュールで各更新プログラムに『KB4577586 Update for Removal of Adobe Flash Player』が組み込まれ、更新プログラムの適用により Flash が永久的に削除されます。

  • (Windows 10 LTSC 2019 および Windows 10 1909 以上, Windows Server 2019) 2021 年 6 月のプレビューのロールアップ更新から
  • (Windows 10 LTSB 2015, LTSC 2016, Windows Server 2016) 2021 年 7 月のロールアップ更新から
  • (Windows 8.1, Windows Server 2012 R2, Windows Server 2012 and Windows Embedded 8 Standard) 2021 年 7 月から (マンスリー ロールアップおよびセキュリティのみの更新)

Adobe 社公開情報

Adobe Flash Player法人向けサポート終了情報ページ
https://www.adobe.com/jp/products/flashplayer/enterprise-end-of-life.html

Update for Enterprise Customers Using Adobe Flash Player
https://blog.adobe.com/en/fpost/2020/update-for-enterprise-adobe-flash-player.html

Adobe Flash Playerサポート終了情報ページ
https://www.adobe.com/jp/products/flashplayer/end-of-life.html

よくあるお問い合わせ

Flash に関して弊社のサポートは終了いたしました。
サポート期間中に弊社サポートへよくお問い合わせいただいたご質問についてまとめておりますが、2021 年以降の Flash の実行はお勧めできません。セキュリティの観点からは 2021 年夏予定の Flash の永久削除を待つのではなく、『Update for Removal of Adobe Flash Player』を使用してできる限り早急に自発的に Flash を永久削除することをお勧めします。

全般

Q. 2021 年 1 月以降、Flash を使い続けるにはどうしたらいいですか？
A. Adobe Flash Player のサポート終了は 2020 年 12 月 31 日です。それ以降に使い続ける方法について、弊社ではサポートできません。2021 年以降の法人向け対応サポートについては、Adobe 社の情報 をご覧ください。

『Flash の実行ブロック』について

Q. ブロックとは具体的にどのような動作ですか？
A. サイレントに Flash の実行がブロックされます。

Q. どうすれば回避できますか？
A. KB4561600 以上の Adobe Flash Player のセキュリティ更新プログラムを適用してください。
なお、現在入手可能な Adobe Flash Player のセキュリティ更新プログラムは、KB4561600 を置き換える KB4580325 が最新です。KB4561600 もしくは KB4580325 のいずれかがインストールされている環境であれば、『Flash の実行ブロック』の対象外です。

Q. Adobe Flash Player のセキュリティ更新プログラムは、OS のロールアップ更新プログラムに含まれますか？
A. 含まれません。独立した更新プログラムです。前提条件などは更新プログラムの公開ドキュメントをご確認ください。

『Flash の既定で無効化』について

Q. ブロックとは別ですか？
A. はい。『ブロック』はブラウザー側の動作であり、『無効化』は Adobe Flash Player による動作です。

Q. どうすれば回避できますか？
A. Adobe 社の公開ドキュメント (Adobe Flash Player法人向けサポート終了情報ページ) 内の「デフォルトでFlashの再生をブロック」「Flash Playerは2020年末を過ぎても動作しますか？」をご確認ください。

Q. 無効化に関してサポートしてほしいのですが。
A. Adobe 社の公開ドキュメント (Adobe Flash Player法人向けサポート終了情報ページ) の内容も含め、Adobe 社へお問い合わせいただくようお願いしています。

Q. いつから無効化されますか？
A. Adobe 社の公開ドキュメント をご覧ください。

『Update for Removal of Adobe Flash Player』について

Q. 今後のスケジュールについて教えてください。
A. 2021 年の初めに Windows Update (オプション) と WSUS で配信予定で、その 2 ～ 3 か月後には Windows Update では推奨として配信予定です。2021 年夏には、Windows 10 での OS のロールアップ更新プログラム、および Windows 8.1, Windows Server 2012 and Windows Embedded 8 Standard での Internet Explorer 用の累積的なセキュリティ更新プログラムやマンスリー ロールアップの一部としてが組み込まれます。

Q. WSUS に配信される前に展開することは可能ですか？
A. はい。手動で WSUS にインポートを行い、配信することが可能です。

Q. 更新の適用時に OS の再起動は必要ですか？
A. 必要に応じて求められる場合があります。

Q. 更新の適用後にアンインストールできますか？ (Flash が存在する状態に戻せますか？)
A. できません。更新適用前に作成した復元ポイントから OS を復元するか、OS の再インストールが必要です。

Q. Windows 7 のときのようにユーザーが個別に Flash をインストールすることはできますか？
A. できません。

Q. Microsoft Edge (Chromium 版) に影響しますか？
A. 影響しません。Microsoft Edge (Chromium 版) は 2021 年 1 月リリース予定のバージョン 88 にて Flash が削除される予定です。それ以前のバージョンはそのままになります。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/flash/ 2021-04-27T15:00:00.000Z Internet Explorer および Microsoft Edge での Flash の今後の対応について 2026-06-02T06:09:44.958Z Developer Support Internet Japan みなさんこんにちは。
日本マイクロソフトの IE/Edge サポートチームです。

近頃、「いつのまにか IE で表示されなくなり、新しい Microsoft Edge でサイトが表示されるようになった」とお問い合わせを頂くことがあります。
IE での表示を前提として Web アプリを作成されている方では、IE で開くようにしたいという方もいらっしゃるかと思います。

 
そこで、少しでも本事象でお困りな皆様のお力になれればと、本ブログにて情報をまとめました！
本記事は以下のような構成となってます。

 

1 : どのような動作？

近年のモダンブラウザ移行に伴い、最新の web サイトの多くは、Internet Explorer と互換性のないデザインが多く使用されています。
今回の IE で利用していたサイトを新しい Microsoft Edge (以降、単に Edge と表記します)へリダイレクトさせる機能は、 最新のブラウザでユーザーにスムーズにブラウジングをして頂くための機能となります。

Internet Explorer から Microsoft Edge にユーザーを移動する - Microsoft Edge Development | Microsoft Docs

なお、私どもブラウザ チームは Edge へのお早めの移行をお奨めしております。

まだデフォルトIE？ 新しい Microsoft Edge を使いませんか？ | Japan Developer Support Internet Team Blog (jpdsi.github.io)

具体的な内容

本機能はEdgeの既定のブラウザにおける 「Internet Explorer に Microsoft Edge でサイトを開かせる」の設定項目に依存します。
具体的な設定は Edge を開き、アドレスバーに edge://settings/defaultBrowser  と入力することで確認できます。

Picture

上記のように「Internet Explorer に Microsoft Edge でサイトを開かせる」の設定で「互換性のないサイトのみ(推奨)」を選択した状態で、
互換性のないサイト (例： youtube.com) を IE で開こうとすると、IE上には以下のように表示され、Edgeで YouTube のサイトページが表示されます。

Picture

互換性のないサイトは以下にリスト化されており、本設定の際にはこちらに当てはまるものは Edge で開かれます。

https://edge.microsoft.com/neededge/v1

そのため、もし開こうとしていたサイトがこちらのリストに存在する場合は、
「互換性のないサイトのみ(推奨)」の設定をしていた場合には IE ではなく、Edge で開かれます。 

2 : すべての Web サイトが Edge で開かれる？

また、上記互換性のないサイトのリストにない Web サイトを含め、全ての Web サイトが IE ではなく、Edge で開かれるパターンもあります。

IE でブラウジングをしていると、以下のようなオプトインが表示されることがありますが、
「Microsoft Edge に切り替える」 を選択することで、今後 全ての Web サイトがEdge で開かれるようになります。

Picture

3 :  対処法はあるのか？

予防策

2 の予防措置としては、上記オプトインが表示された場合は、「今は実行しない」を押して切り替えないようにすることが考えられます。

Picture 

対処策

一度設定を変更された場合においても、「Internet Explorer に Microsoft Edge でサイトを開かせる」において「なし」を選択していただくことによって解決可能です。 

上記方法で、IE のままサイトを閲覧するように変更することも可能ですが、Web サイトの技術も日進月歩進化しており、新しい Microsoft Edge へお早めの移行をご検討ください。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/IEtoEdgeRedirection/ 2021-02-17T15:00:00.000Z みなさんこんにちは。
日本マイクロソフトの IE/Edge サポートチームです。

近頃、「いつのまにか IE で表示されなくなり、新しい Microsoft Edge でサイトが表示されるようになった」とお問い合わせを頂くことがあります。<]]>

IE で開いていたページが Microsoft Edge にリダイレクトされる動作について 2026-06-02T06:09:44.935Z Developer Support Internet Japan こんにちは。

今回は、自社開発などで Microsoft Store に登録されていない Microsoft Edge (Chromium) の拡張機能を、社内で自動展開する方法について紹介します。拡張機能のサンプルは チュートリアル からダウンロードできます。

自動展開 (強制インストール) を行うには、Microsoft Active Directory ドメインに参加している Windows デバイスである必要があります。ドメインに参加していない Windows デバイスについては、強制インストールは Microsoft Store で利用できる拡張機能に限定されます。

拡張機能のパック (CRX ファイルの作成) と ID の確認

まずは開発した (用意した) 拡張機能をパッケージ化する必要があります。パッケージ化と ID の確認は以下の手順で行います。

  1. edge://extensions を開いて [開発者モード] を有効にします。

開発者モード

  1. [拡張機能のパック] をクリックして、[拡張ルート ディレクトリ] に用意した拡張機能のルートを指定します。

拡張機能のパックをクリック

拡張機能のパックのダイアログ

  1. [拡張機能のパック] ボタンをクリックすると、指定したパスの親フォルダーにパッケージ (CRX ファイル) が作成されます。

※ 秘密鍵 (PEM ファイル) は今回使用しませんが、今後拡張機能をアップデートして再パッケージする際に必要になります

  1. 作成された CRX ファイルを Microsoft Edge にドラッグ & ドロップして [拡張機能の追加] をクリックします。

拡張機能の追加

  1. 追加された拡張機能を確認し、ID とバージョン番号をメモしておきます。

拡張機能の ID を確認

CRX ファイルの Web サーバーへの配置と更新マニフェストの作成

作成した CRX ファイルを Web サーバーに配置し、ダウンロードできることを確認しておきます。
CRX ファイルは既定で許可された MIME タイプではないため、Web サーバーで設定が必要な場合があります。
例えば、IIS では、以下のように Web.config で MIME タイプの設定を行う必要があります。

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
  <system.webServer> 
    <staticContent> 
      <mimeMap fileExtension=".crx" mimeType="application/x-chrome-extension" /> 
    </staticContent> 
  </system.webServer> 
</configuration>

更新マニフェスト (XML ファイル) を作成し、同じく Web サーバーに配置します。
更新マニフェストは、以下のような内容のファイルを用意します。ID とバージョンは先ほどメモした値を使用し、codebase には CRX ファイルの URL を記載します。

1
2
3
4
5
6
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='gcfmppplpjjdihbhljakgaihencjcngk'>
<updatecheck codebase= 'https://edgewatcher.azurewebsites.net/nasa_picture_viewer.crx' version='0.0.0.1' />
</app>
</gupdate>

グループ ポリシーを構成する

拡張機能の自動展開のために サイレント インストールされる拡張機能を制御する のグループ ポリシーを構成します。
値の部分には、拡張機能の ID と更新マニフェストの URL をセミ コロン (;) で連結した文字列を設定します。
ポリシーが正しくクライアントに適用されたかどうかは、edge://policy で確認できます。

1
gcfmppplpjjdihbhljakgaihencjcngk;https://edgewatcher.azurewebsites.net/nasa_picture_viewer.xml

以上で設定は完了です。正しく設定できていれば、Microsoft Edge 起動時に自動的に拡張機能がインストールされ、有効になります。

]]> https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/how-to-deploy-edge-extensions/ 2020-08-25T15:00:00.000Z こんにちは。

今回は、自社開発などで Microsoft Store に登録されていない Microsoft Edge (Chromium) の拡張機能を、社内で自動展開する方法について紹介します。拡張機能のサンプルは