Windows 11 環境で Microsoft Edge 135.0.3179.54 を使い、Intune やグループポリシーで Google を既定の検索エンジンにすると、検索実行時に Edge が突然落ちる事象が報告されています。本記事では、この不具合の原因と Microsoft 公式情報に基づいた恒久対応、さらに更新までの暫定ワークアラウンドを管理者目線で解説します。
Microsoft Edge 135.0.3179.54 で「Google 検索するとクラッシュする」問題の概要
まず、本記事で扱う事象をはっきりさせておきます。想定している環境・条件は次のとおりです。
- OS：Windows 11（エディションは Home を除く企業利用を想定）
- ブラウザ：Microsoft Edge Stable 135.0.3179.54（公式ビルド、64-bit）
- 管理方法：Intune（またはグループポリシー）で
DefaultSearchProviderSearchURLなどのポリシーを使用し、「Google 検索」を既定検索エンジンに強制 - 現象：アドレスバーや新しいタブから検索を実行すると、即座に Edge がクラッシュ（ウィンドウが閉じる）
| 項目 | 内容 |
|---|---|
| 発生バージョン | Microsoft Edge 135.0.3179.54（Stable） |
| OS | Windows 11（Pro / Enterprise / Education を想定） |
| ポリシー | Intune / GPO による DefaultSearchProviderSearchURL などの既定検索プロバイダー関連ポリシー |
| 検索エンジン | Google を既定の検索エンジンに設定した場合にのみ発生 |
| 主な症状 | アドレスバーから検索すると Edge が強制終了し、イベントログにアプリケーション エラーが記録される |
この症状は、Microsoft Edge 自体の不具合であり、「Google 側の問題」や「検索 URL の設定ミス」だけが原因というわけではありません。Microsoft の Stable チャネルのリリースノートでも、バージョン 135.0.3179.66 において「Google を既定検索エンジンにした場合にクラッシュする問題」を修正した旨が明記されています。
Microsoft 公式情報から読み解く原因と修正状況
Stable 135.0.3179.66 での修正内容
Microsoft Edge Stable のアーカイブ リリースノートによると、バージョン 135.0.3179.66（2025 年 4 月 9 日公開）には「信頼性の向上」として、次のような趣旨の修正が記載されています。
- Google 検索結果を表示する際にブラウザがクラッシュすることがあり、その原因は、グループポリシーで Google を既定の検索エンジンに設定している環境に関連していた
同じく Microsoft Q&A でも、Edge 135.0.3179.54 と Intune ポリシーで Google を既定検索にしている環境で「検索時に Edge がクラッシュする」という問い合わせがあり、その回答で上記リリースノートが参照され、135.0.3179.66 以降への更新が推奨されています。
つまり、この問題は Edge 135.0.3179.54 時点のバグ であり、135.0.3179.66 で公式に修正されたことが確認できます。
| バージョン | 公開日（Stable） | リリースノートの要点 | 推奨アクション |
|---|---|---|---|
| 135.0.3179.54 | 2025-04-03 頃 | 各種バグ修正・機能更新。Google 既定検索環境でクラッシュするバグが残存 | Google を既定検索にしている企業環境では「要アップデート対象」として扱う |
| 135.0.3179.66 | 2025-04-09 頃 | 「Google 検索結果表示時にクラッシュする問題（グループポリシーで Google を既定にしている場合）」が修正されたと明記 | 恒久対策として、このバージョン以降へ更新することが最優先 |
したがって、管理者としての基本方針はとてもシンプルです。
- 既定の検索エンジンを Google に固定する運用を続けるなら、Edge を 135.0.3179.66 以降へ更新 する
- 更新までの間だけ、クラッシュを回避するためのワークアラウンドを検討する
恒久対応（推奨）：Microsoft Edge を 135.0.3179.66 以降へ更新する
なぜアップデートが最優先なのか
今回の不具合は、検索 URL ポリシーの設定が間違っているのではなく、その設定を前提とした Edge 本体のバグ です。公式リリースノートに「Google を既定検索エンジンにした場合のクラッシュを修正」と書かれている以上、根本的な解決にはバージョンアップが欠かせません。
レジストリ操作やポリシー変更で一時的に回避できるケースもありますが、それらはあくまで「バグを踏まないように避ける」だけの対処であり、将来のアップデートや他の機能との組み合わせで副作用が出る可能性もあります。
企業環境での更新パターン
企業・組織環境では、Edge の更新は次のようなパターンで行われていることが多いはずです。
- 自動更新を許可し、ユーザー端末がインターネット経由で直接最新版を取得
- Microsoft Edge 更新ポリシー（ADMX / Intune）を用いて更新チャネルや遅延日数を制御
- Intune や Windows Update for Business を使い、OS 更新と合わせてブラウザも運用
公式のポリシー一覧では、Edge 本体と更新に関するポリシーがそれぞれ定義されており、組織として細かく制御できます。
| 更新パターン | メリット | デメリット / 注意点 |
|---|---|---|
| 自動更新を許可（標準） | 常に最新バージョンを維持しやすく、今回のような不具合修正を素早く取り込める | 検証前に一部端末が更新されてしまう可能性 |
| 更新リング（段階的展開） | ステージング端末で動作確認後、全社展開できる。リスクとスピードのバランスを取りやすい | リング設計や割り当ての運用コストがかかる |
| 完全固定（特定バージョンにロック） | バージョン依存の業務アプリとの相性を保ちやすい | 脆弱性・不具合修正が取り込めず、今回のようなバグにも長期間さらされる |
今回のように 特定バージョン固有のバグ が明確になった場合は、「完全固定」運用でも 例外的に 135.0.3179.66 以降への更新を許可 することを強く推奨します。
Intune / Windows Update for Business での実践的なポイント
Intune や Windows Update for Business を利用している場合、実務的には次のようなステップで対応すると運用しやすくなります。
- ステージング用デバイス グループを準備
既に運用している場合はそのまま活用し、なければ小規模なテスト用グループを作成します。 - ステージング グループに対し Edge 135.0.3179.66 以降を適用
数日〜1 週間程度、業務アプリとの相性や新たな不具合がないかを確認します。 - 問題がなければ本番リングへ展開
段階的に割り当てを広げ、最終的には全端末を 135.0.3179.66 以降へ揃えます。 - 更新完了後にワークアラウンドを解除
暫定レジストリ操作や追加スクリプトを入れていた場合は、忘れずに元へ戻します。
影響端末を洗い出す簡易チェック方法
どの端末が問題のバージョンを使っているかを把握しておくと、優先順位付けが楽になります。代表的な確認方法は次のとおりです。
- ユーザー自身に確認させる
Edge のアドレスバーにedge://versionを入力し、「Microsoft Edge」欄のバージョンを申告してもらう。 - PowerShell スクリプトで収集
Intune のスクリプト機能で、msedge.exeのバージョン情報を取得し、ログとしてアップロードする。 - 資産管理ツールのインベントリ
既にソフトウェア インベントリを取っている場合、Edge バージョンでフィルタリングする。
例として、ローカルでバージョンを確認する PowerShell の極めてシンプルな例を示します（実運用ではエラーハンドリングやログ出力の追加を推奨）。
$paths = @(
"C:\Program Files\Microsoft\Edge\Application\msedge.exe",
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
)
foreach ($p in $paths) {
if (Test-Path $p) {
(Get-Item $p).VersionInfo.ProductVersion
}
}135.0.3179.54 など、問題バージョンが検出された端末を優先的に更新対象とするとよいでしょう。
暫定ワークアラウンド：DefaultSearchProviderSearchURL の一時リネーム
何らかの理由で「すぐには Edge を更新できない」という環境では、レジストリのポリシー値名を一時的に変更することで、クラッシュを回避できるケースがあります。
前提条件と注意事項
このワークアラウンドは、次のような前提で説明します。
- Google を既定検索にするために、
DefaultSearchProviderSearchURLポリシーを使用している - ポリシーは Intune またはグループポリシーにより、デバイス レベル（HKLM）に適用されている
- レジストリのバックアップを取得できる、ある程度のスキルを持った管理者が作業する
また、以下を必ず意識してください。
- レジストリの変更は誤るとシステムに影響を与える可能性があります。バックアップ取得とテスト環境での検証を行うこと。
- この方法は Microsoft の公式な回避策ではありません。環境によっては効果が出ない、あるいは別の問題が発生する可能性もあります。
- Edge を 135.0.3179.66 以降へ更新できたら、速やかにワークアラウンドを解除する前提で運用してください。
手動での作業手順（1 台ずつ対応する場合）
単一端末や台数が少ない場合の、代表的な手順は次のとおりです。
- Edge を完全に終了する
タスクバーから閉じるだけでなく、タスク マネージャーでmsedge.exeが残っていないことを確認します。 - レジストリ エディターを管理者権限で起動
regedit.exeを実行し、次のキーを開きます。HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge - レジストリのバックアップを取得
「ファイル」 > 「エクスポート」で、Edgeキーを .reg ファイルとして保存しておきます。 DefaultSearchProviderSearchURLの値名をリネーム
対象の値名を右クリックして「名前の変更」を選択し、例としてold.DefaultSearchProviderSearchURLなどに変更します。- Edge を起動してテスト
アドレスバーから適当なキーワードを入力し、検索を実行しても Edge がクラッシュしないかを確認します。 - 必要に応じて値名を元に戻す
テスト完了後、同じ手順で値名を元のDefaultSearchProviderSearchURLに戻します。
この操作により、ポリシー適用のタイミングやキャッシュがリセットされることで、クラッシュを踏まずに正常起動・検索できるようになるケースがあります。ただし、環境によって挙動が異なり得るため、必ずテスト端末で検証してから本番展開することをおすすめします。
| 項目 | 内容 |
|---|---|
| 変更対象キー | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge |
| 変更対象値名 | DefaultSearchProviderSearchURL |
| 変更内容 | 一時的に old.DefaultSearchProviderSearchURL などにリネーム |
| 目的 | ポリシー適用順序やキャッシュをリセットし、クラッシュ発生パターンを回避する |
| 注意点 | レジストリ操作前にバックアップを必ず取得し、更新後は元に戻すこと |
関連ポリシーを理解しておくと安心
Edge の既定検索エンジンは、複数のポリシーで構成されます。代表的なものは以下のとおりです。
DefaultSearchProviderEnabled：既定検索プロバイダーを有効にするかどうかDefaultSearchProviderName：検索プロバイダー名（例：Google）DefaultSearchProviderSearchURL：検索実行時の URL（{searchTerms}プレースホルダーを含む）DefaultSearchProviderSuggestURL：入力中に候補を取得するためのサジェスト用 URLDefaultSearchProviderKeyword：アドレスバーで使用するキーワード（省略可）
これらは公式ドキュメント上でも「Default search provider」カテゴリのポリシーとして整理されており、Google の検索 URL の例も記載されています。
ワークアラウンドとしては、検索 URL を変えずに「値名のみ」一時的に変更することがポイントです。値名を戻せば元の構成に復帰できるため、ポリシー全体を作り直す必要はありません。
スクリプトでレジストリを変更する場合のイメージ
多数の端末に対してこのワークアラウンドを適用する場合、PowerShell スクリプトなどで自動化したくなるかもしれません。あくまで概念的な例ですが、値名のリネームだけを行うスクリプトは次のようなイメージになります。
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Edge"
$oldName = "DefaultSearchProviderSearchURL"
$newName = "old.DefaultSearchProviderSearchURL"
if (Test-Path $regPath) {
try {
$value = Get-ItemProperty -Path $regPath -Name $oldName -ErrorAction SilentlyContinue
if ($null -ne $value) {
Rename-ItemProperty -Path $regPath -Name $oldName -NewName $newName
}
} catch {
# ログ出力など
}
}本番環境で利用する際は、
- 既にリネーム済みの場合に二重で処理しないようなチェック
- 実行ログや失敗時のロールバック処理
- 更新後に元の値名へ戻すためのスクリプト
などを追加実装することを推奨します。
運用上のポイントとベストプラクティス
更新配布の優先度を上げる
今回の問題に対するベストプラクティスは、「Edge を 135.0.3179.66 以降へできるだけ早く更新する」ことです。
- Intune を利用している場合は、対象デバイス グループに対する Edge の更新ポリシーを最優先で適用する
- Windows Update for Business で OS 更新とまとめて制御している場合も、Edge の更新タイミングを確認し、必要に応じて一時的に制限を緩和する
- アップデート後に再度クラッシュが発生しないか、小規模なユーザー グループで早期検証を実施する
影響端末の範囲を正確に把握する
すべての端末が Google を既定検索にしているとは限らず、一部の部門やテスト用環境だけで運用している場合もあります。そこで、
- 「Edge バージョン」と「既定検索エンジン構成」の両方を軸に、影響範囲を把握する
- Intune の構成プロファイル割り当てや、グループポリシー オブジェクト (GPO) のリンク先 OU を確認する
- 資産管理ツールと組み合わせて、「135.0.3179.54 かつ Google 既定検索」が条件に当てはまる端末を洗い出す
といった整理をしておくと、限られた時間・工数の中でも効率的に対応できます。
レジストリ操作のリスク管理
ワークアラウンドとしてレジストリを操作する場合は、次のポイントを抑えておきましょう。
- ポリシーの上書きタイミングに注意
Intune や GPO によるポリシー適用は、一定間隔で自動的に再適用されます。場合によっては、手動でリネームした値とは別に、元の値名が再び作られてしまうこともあります。 - ワークアラウンド適用の履歴を残す
どの端末にいつワークアラウンドを適用したかを記録しておかないと、アップデート後の「戻し漏れ」が発生しやすくなります。 - アップデート完了後に必ず元に戻す
Edge 更新後もレジストリ値名が変わったままだと、将来の構成変更やトラブルシューティング時に混乱の原因となります。
| やること | 目的 | 具体策 |
|---|---|---|
| 影響端末を把握 | 優先度付けと工数見積もり | バージョン & ポリシー適用状況をインベントリや Intune で確認 |
| 更新リングの調整 | リスクを抑えつつ迅速に更新 | ステージング → 本番リングの順に 135.0.3179.66 以降を展開 |
| ワークアラウンド管理 | レジストリ変更による副作用を最小化 | バックアップ取得・変更履歴を残し、更新後に必ず元に戻す |
その他の回避策オプションと選び方
環境によっては、次のような代替案も検討対象になります。
| 選択肢 | メリット | デメリット | 向いている環境 |
|---|---|---|---|
| Edge を最新へ更新（推奨） | 問題の根本原因を解消できる。今後の脆弱性修正も取り込める | 検証や展開に一定の工数が必要 | ほぼすべての企業環境。唯一の恒久対策 |
| 一時的に Bing を既定検索に戻す | Google に依存したクラッシュを避けられる。ポリシー変更だけで対応可能 | ユーザー体験が変わる、業務マニュアルの変更などが必要な場合あり | 検索エンジンが業務で厳密に固定されていない環境 |
| レジストリ値名の一時リネーム | Google を維持したままクラッシュ回避できるケースがある | 公式サポート外、環境依存。慎重な検証とロールバック計画が必要 | 短期間だけ運用をつなぎたい環境、限定的な端末数 |
| 既定検索ポリシー自体を一時無効化 | ユーザーが任意の検索エンジンを選べるため、クラッシュパターンを避けやすい | セキュリティやコンプライアンス上、検索エンジンを固定する必要がある場合には不適 | 検索エンジン統制の優先度が低い組織 |
セキュリティやコンプライアンス要件を考えると、検索エンジンを無制限にするのは避けたいケースも多いはずです。その場合は、「短期的にはレジストリ ワークアラウンド」＋「中長期的にはアップデートで恒久対応」という二段構えが現実的な落としどころになります。
よくある疑問への回答
135.0.3179.66 以降なら必ず安全なのか？
リリースノートおよび Microsoft Q&A の情報から、少なくとも「Google を既定検索にした場合に発生するクラッシュ」は 135.0.3179.66 で修正されていると読み取れます。
ただし、ブラウザは頻繁に更新されるソフトウェアであるため、別のバグや表示崩れなどが新たに見つかる可能性は常に存在します。そのため、
- ステージング環境での事前検証
- 問題発生時にすぐロールバックできる仕組み
を用意しておくことが、長期的な運用の観点で重要です。
Google の検索 URL 設定が間違っている可能性は？
Edge のポリシー ドキュメントには、Google を既定検索として利用するための URL の例が記載されています。そこでは {searchTerms} や {google:baseURL} などのプレースホルダーを使った検索 URL が紹介されています。
明らかに URL が破損している場合（プレースホルダーが抜けている、クエリ文字列が途中で切れているなど）には修正が必要ですが、今回の事象は「正しい URL を設定しているにもかかわらずクラッシュする」という報告が中心です。そのため、URL が正しい前提であれば、原因は Edge 本体の不具合と考えるのが自然です。
ユーザーに自由に検索エンジンを選ばせてもよいか？
ポリシーを無効化してユーザーに任せる運用も、不具合回避という観点だけで見れば一つの選択肢です。しかし、
- 業務で利用を許可していない検索エンジンに誘導されるリスク
- 検索履歴の取り扱いやログ一元管理ができなくなる懸念
などがあるため、セキュリティやコンプライアンス要件を満たせない場合があります。企業利用を前提とするなら、やはり ポリシーで検索エンジンを固定した上で、Edge 側を正しいバージョンに更新する 方針が望ましいでしょう。
まとめ：まずは Edge 135.0.3179.66 以降へのアップデートを最優先に
本記事で扱った内容を整理すると、ポイントは次の 3 つに集約できます。
- Edge 135.0.3179.54 ＋ Google を既定検索（ポリシー適用）の組み合わせでクラッシュが発生する問題は、Microsoft により 135.0.3179.66 で修正済み である。
- 恒久的な解決策は「Edge を 135.0.3179.66 以降へ更新すること」 であり、ポリシーやレジストリだけで根本解決することはできない。
- 更新までのつなぎとして、
DefaultSearchProviderSearchURLの値名を一時的にリネームするワークアラウンドが存在する が、レジストリ操作には十分な注意とロールバック計画が必要である。
企業の IT 管理者としては、「どの端末が問題バージョンか」「どのポリシーで Google を既定検索にしているか」をまず可視化し、リスクが高いところから優先的にアップデートを進めることが重要です。そのうえで、どうしても即時更新できない範囲にだけ、慎重にワークアラウンドを適用するという二段構えで対応すると、安全かつ効率的にこの問題を乗り越えられるはずです。
コメント