バックグラウンド起動を直結するWindowsの新機構、Edgeが名乗りをあげた高速化の条件

Microsoftは2026年10月29日、Microsoft EdgeがWindowsの新機能「Accelerated App Launch（アプリ起動の高速化）」に対応したと発表した。タスクバーからEdgeを開いたり、別のアプリでリンクをクリックしたりする際、すでに動作しているEdgeプロセスへWindowsが直接通知を送ることで、起動にかかる処理を減らす仕組みだ。Microsoftによれば、この機能に対応したブラウザはEdgeが初めてとなる。

Microsoft Edge Blogの発表によると、一般的な利用環境では起動速度が15%改善し、複数のアプリを同時に動かす高負荷環境では最大33%の改善が得られるという。ただし、この数値はEdgeのプロセスがすでに動作している状態で、Accelerated App Launchを使用しない場合と比較したものだ。ブラウザを完全に終了した状態から起動する「コールド起動」ではなく、既存のプロセスを再利用する「ウォーム起動」が高速化の対象となる。また、比較に用いた起動時間の絶対値や詳細な測定条件は公表されていない。

この機能を利用するには、Microsoft Edgeバージョン150以降と、2026年10月28日に公開されたWindows 11の対応更新プログラムが必要だ。Windows 11のバージョンによって適用すべき更新プログラムも異なるため、Edgeを最新版にするだけでは利用できない。本稿では、高速化の仕組みとMicrosoftが公表した性能改善の条件、利用に必要なWindowsの更新、開発者向けAPIの制約を整理する。

仲介プロセスを省く「直接通知」の仕組み

Microsoft Edgeは、画面上にブラウザのウィンドウが表示されていなくても、バックグラウンドで動作している場合がある。例えば、後述する「Startup Boost（スタートアップブースト）」が有効であれば、ブラウザを開く前からコアプロセスを起動しておける。こうした状態でユーザーがEdgeを再び開こうとした場合、既存のプロセスを利用して新しいウィンドウやタブを表示する。

従来のWindowsでは、すでに動作しているアプリを再び起動する際、まず仲介プロセス（intermediary process）を立ち上げる必要があった。このプロセスが既存のアプリを探し、動作中のインスタンスが見つかれば、起動要求やURLなどの情報を引き渡す。つまり、アプリ本体がすでにメモリ上に存在していても、そのプロセスへ要求を届けるために、一時的なプロセスの生成と既存プロセスの探索が発生していた。

Accelerated App Launchは、この仲介プロセスを不要にする仕組みだ。Edgeが最初に起動すると、自身が起動要求の受信先であることをWindowsに登録する。Windowsはその登録要求を検証して受け付け、次にEdgeの起動要求が発生した際には、保存している登録情報を使って既存のEdgeプロセスへ直接通知を送る。これにより、仲介プロセスの生成や既存プロセスの探索にかかる処理を省略できる。

Microsoftは、特に複数のアプリケーションが動作する高負荷環境で、この仕組みが効果を発揮すると説明している。PCを起動した直後など、システムに余裕がある状態では、仲介プロセスの処理時間はほとんど気にならない場合もある。しかし、CPUやメモリが多数のアプリケーションに使われている状況では、新しいプロセスを生成する処理が起動遅延の一因となる。今回の改修は、このようなWindows側の処理負荷を減らすものだ。

Microsoftが公表した改善率は次の通りである。

測定条件	Microsoft公表の起動速度改善率
一般的な利用環境	15%
高負荷のマルチタスク環境	最大33%

これらは、Edgeプロセスがすでに動作している状態で、Accelerated App Launchを使用しない従来の起動方法と比較した数値だ。ブラウザ本体の処理速度やWebページの読み込み速度が15〜33%向上するわけではなく、ストレージから実行ファイルを読み込むコールド起動の高速化でもない。また、Microsoftは起動時間の絶対値を示していないため、実際に何ミリ秒短縮されたのかを、この公表値だけから判断することはできない。

公表された改善率と必要なWindows更新プログラム

Microsoftが示した「15%」「最大33%」という数字については、測定条件を慎重に捉える必要がある。発表資料の脚注には、Edgeがすでに動作している状態で、Accelerated App Launchを使用しないWindows環境との比較であることが明記されている。一方、測定に用いたCPUやメモリ容量、ストレージの種類、試行回数、起動時間の計測開始点と終了点などは示されていない。「高負荷のマルチタスク環境」が具体的にどの程度の負荷を指すのかも不明だ。

このため、Microsoftが公表した改善率は、現時点では開発元による測定結果として扱うのが適切だ。すべてのWindows PCで同じ改善が得られることを保証するものではなく、処理負荷やバックグラウンドで動作しているアプリの状況によって、効果は変わると考えられる。実際の操作感にどの程度の違いが生じるかについては、第三者による測定が必要となる。

また、この高速化を利用するには、EdgeとWindowsの両方が対応している必要がある。MicrosoftのWindows更新履歴によると、2026年10月28日に公開された更新プログラムには、Accelerated App Launchへの対応が含まれている。ただし、Windows 11のバージョン25H2／26H2と26H1では、適用する更新プログラムが異なる。

対象	必要なバージョン・更新プログラム	状態と注意点
Microsoft Edge	バージョン150以降	Edge 150の安定版は2026年7月2日に公開済み
Windows 11 25H2／26H2	KB5127936（2026年10月28日）	オプションの非セキュリティプレビュー更新
Windows 11 26H1	KB5127653（2026年10月28日）	26H1専用のプレビュー更新
Windows 10	対象外	今回の高速化はWindows 11向け
Edgeの動作状態	既存のEdgeプロセスが動作していること	フォアグラウンドまたはバックグラウンドでの起動が前提

ブラウザ側の要件となるEdge 150は、すでに数カ月前から提供されている。Microsoftのリリーススケジュールによれば、Edge 150の安定版（150.0.4078.48）は2026年7月2日に公開された。そのため、Edgeを定期的に更新している環境では、ブラウザ側のバージョン要件を満たしている可能性が高い。

一方、Windows 11のバージョン25H2および26H2では、10月28日公開の「KB5127936」が対応する更新プログラムとなる。Microsoftのサポート文書では、Accelerated App Launchは「通常ロールアウト（Normal rollout）」に分類されている。段階的に対象を広げる機能とは異なり、対応する更新プログラムを適用した対象環境へ広く提供される扱いだ。

Windows 11のバージョン26H1については、専用の更新プログラム「KB5127653」で同じ機能が追加される。Microsoft Edge Blogでは代表的な更新プログラムとしてKB5127936以降を挙げているが、26H1ではKB5127653が該当する。利用者は「設定」からWindowsのバージョンと更新履歴を確認し、自分の環境に対応する更新プログラムが適用されているかを確かめる必要がある。

なお、これらは現時点ではオプションのプレビュー更新として提供されている。Windows Updateの詳細オプションにある「オプションの更新プログラム」から導入でき、企業向けのWindows Update for Businessでは、変更が次のセキュリティ更新に含まれると案内されている。したがって、Edgeが対応バージョンであっても、Windows側の更新が未適用なら高速化は働かない。

「Startup Boost」とは別の高速化、どんな場面で働くのか

今回のAccelerated App Launchは、Edgeが従来から備える「Startup Boost（スタートアップブースト）」と混同しないことが重要だ。どちらもブラウザの起動を高速化する機能だが、改善する処理が異なる。

Startup Boostは、Edgeのコアプロセスをバックグラウンドで起動しておき、ユーザーがブラウザを開いたときの待ち時間を減らす仕組みだ。Microsoftのグループポリシー文書「StartupBoostEnabled」によると、この機能はOSへのサインイン時にEdgeのプロセスを起動し、最後のブラウザウィンドウを閉じた後もバックグラウンドで再起動できるようにする。つまり、ユーザーが次にブラウザを開く前から、必要なプロセスをメモリ上に用意しておくことが目的だ。

これに対してAccelerated App Launchは、すでに動作しているプロセスへWindowsが起動要求を届ける方法を改善する。Startup Boostがプロセスを事前に用意する機能だとすれば、Accelerated App Launchは、そのプロセスに起動要求を渡すまでの処理を短縮する機能といえる。両者は組み合わせて利用できるが、Accelerated App Launchを使うためにStartup Boostの有効化が必須というわけではない。

例えば、EdgeでWebページを閲覧している最中に、メールアプリ内のリンクを開く場合を考えてみよう。すでにEdgeのプロセスが動いているため、Windowsは新たな仲介プロセスを生成せず、既存のEdgeへ直接URLの起動要求を送れる。同様に、ブラウザのウィンドウを閉じていても、Startup BoostによってEdgeがバックグラウンドで動作していれば、高速化の対象になり得る。

ただし、すべての起動経路でAccelerated App Launchが機能するわけではない。Microsoftが公式に対応を明示しているのは、スタートメニュー、タスクバー、そしてEdgeが既定のブラウザとして設定されている対応リンクを開く場合だ。

起動する場面	従来の処理	Accelerated App Launch適用時	注意点
スタートメニューからEdgeを開く	仲介プロセスが既存のEdgeを探索して要求を引き渡す	Windowsから既存プロセスへ直接通知する	Edgeが動作中であることが必要
タスクバーからEdgeを開く	仲介プロセスを経由して既存インスタンスを呼び出す	登録済みプロセスへ直接通知する	対応するWindows 11とEdgeが必要
Edgeが既定ブラウザの状態でリンクを開く	起動要求を仲介プロセス経由で既存のEdgeへ転送する	Windowsから対象のウィンドウハンドルへ直接通知する	対応するURIスキームに限られる
Edgeが完全に終了した状態から起動する	新しいプロセスを生成する	従来通りの新規プロセス生成処理を行う	今回の高速化の対象外

開発者向けドキュメントでも、Accelerated App Launchはあらゆる起動方法を網羅するものではないと説明されている。デスクトップ上のショートカットや特殊なコマンドライン引数を使った起動、外部ランチャー経由の起動などについては、同じ高速化が適用されるとは限らない。対応していない起動経路では、既存のプロセスへ要求を転送する従来の処理が引き続き必要になる。

また、今回の変更によってWebページのレンダリングやJavaScriptの実行速度が向上するわけではない。高速化されるのは、Windowsが起動要求を既存のEdgeプロセスへ届けるまでの処理だ。CPU負荷が低い環境では差を感じにくい可能性がある一方、多数のアプリケーションが動作している環境では、余計なプロセス生成を省く効果が大きくなると考えられる。

開発者向けAPIの制約と実装上の負担

Accelerated App Launchは、Edge専用の仕組みとして設計されたわけではない。Microsoftは、ほかのWindowsアプリケーションでも利用できるように、開発者向けドキュメント「Register your application for accelerated warm launches」を公開している。ただし、そのAPIは誰でも無条件に利用できる一般公開インターフェースではなく、「Limited Access Feature（制限付きアクセス機能）」として扱われている。

外部の開発者がこの機能をアプリに組み込むには、Microsoftへ利用を申請し、アンロックトークンを取得する必要がある。また、APIを利用できるようになっても、既存のシングルインスタンス制御を完全に置き換えられるわけではない。Microsoftは、Accelerated App LaunchがすべてのWindowsバージョンや起動経路に対応するものではないため、開発者が従来の起動処理を維持する必要があると明記している。

シングルインスタンス制御とは、同じアプリケーションを何度も起動しても、必要に応じて既存のプロセスを再利用する仕組みだ。Accelerated App Launchが利用できない環境では、従来通り、新しい起動要求を受け取ったプロセスが既存インスタンスへ処理を引き継ぐ必要がある。このため、開発者は高速化に対応する経路と、従来の起動処理へ戻る経路の両方を管理しなければならない。

さらに、URIスキームを使った起動高速化にも条件がある。アプリケーションが特定のURIスキームを登録していても、そのスキームの既定のハンドラーとして設定されていなければ、Accelerated App Launchの対象にならない。これは、Windowsがそのリンクを開くアプリとして実際に選択しているプロセスに対してのみ、直接通知を送る仕組みだからだ。

技術的には、Accelerated App LaunchはWindowsが従来から備えるWin32のウィンドウメッセージ機構を利用している。アプリケーションは登録時に、通知を受け取るウィンドウハンドル（HWND）をWindowsへ渡す。Windowsはその登録情報を使い、既存プロセス内の対象ウィンドウへ起動要求を直接届ける。

具体的な登録処理には、IExperimentalAPIInvokerインターフェースが使われる。このインターフェースはCLSID_ExperimentalAPIInvokerによって実装されており、名前付きプロパティを渡して登録用メソッドを呼び出す。Accelerated App Launchでは、主に次の2種類の登録方法が用意されている。

• RegisterAcceleratedTileLaunch：スタートメニューやタスクバーからの起動要求を、指定したウィンドウメッセージで受け取る。
• RegisterAcceleratedUriLaunch：URIスキームによる起動要求を、WM_COPYDATAメッセージで受け取る。

タイル起動では、アプリケーションが指定したメッセージIDを使って通知を受け取る。一方、URI起動では、古くからWindowsのプロセス間通信に使われてきたWM_COPYDATAメッセージが利用される。URI文字列はNULL終端のUTF-16文字列として対象のHWNDへ渡され、アプリケーション側で処理される。

実装方法の違いを整理すると、次のようになる。

比較項目	従来のシングルインスタンス起動	Accelerated App Launch
起動要求の伝達	仲介プロセスを生成し、既存プロセスを探索して引き渡す	Windowsが登録済みプロセスへ直接通知する
通信手段	名前付きパイプ、共有メモリ、アプリ独自の通信など	HWND宛てのウィンドウメッセージ
URIの受信	アプリ側で実装した転送処理	WM_COPYDATA
スタートメニュー・タスクバー起動	従来の起動・転送処理	登録時に指定したウィンドウメッセージ
APIの利用制限	通常のWindows APIで実装可能	制限付きアクセス機能の利用申請が必要
従来処理の維持	必要	非対応環境や起動経路のために引き続き必要
対象OS	実装方法に応じて幅広いWindows環境に対応可能	対応するWindows 11の更新プログラムが必要

APIの利用には、登録オブジェクトのライフサイクル管理にも注意が必要だ。RegisterAcceleratedUriLaunchとRegisterAcceleratedTileLaunchは、それぞれ同一のIExperimentalAPIInvokerオブジェクトに対して1回だけ呼び出せる。登録後はオブジェクトを保持し、登録解除の際にも、登録に使用したのと同じオブジェクトを使わなければならない。

また、Microsoftが公開したサンプルコードでは、通知を受け取るための専用ウィンドウを作成している。この処理を行うヘルパーオブジェクトは、アクティブなメッセージループを持つスレッド上で生成する必要がある。例えばWinUIアプリであれば、UIスレッドを利用できる。通知が届いても、受信側のスレッドがメッセージを処理できなければ、起動要求に応答できないためだ。

このように、Accelerated App Launchが肩代わりするのは、主に仲介プロセスの生成と既存プロセスへの要求転送である。通知を受け取った後の処理は、引き続きアプリケーション側が担当する。新しいタブの作成やウィンドウの表示、受け取ったURLの処理などが重ければ、Windows側で削減した遅延が、その後の処理に埋もれてしまう可能性もある。

開発者にとっては、既存の起動処理を維持しながら、新しい高速化経路を追加する必要がある点が課題となる。制限付きAPIの利用申請や、対応するOSバージョンの判定、登録オブジェクトとメッセージ受信の管理も必要だ。単にAPIを呼び出すだけで起動が高速化されるわけではなく、アプリケーション全体の起動処理を考慮した実装が求められる。

Chromiumへの還元と今後の検証課題

Microsoftは今回の発表で、Accelerated App Launchの利用範囲を今後さらに広げる方針も明らかにした。その具体例として挙げられたのが、PDFファイルを開く際の高速化だ。現在の実装では、スタートメニューやタスクバー、対応するURIスキームからの起動が主な対象となっているが、MicrosoftはPDFファイルを開く場合にも同じ仕組みを利用できるように、Windows側と協力して開発を進めている。

ただし、PDFファイルを開く際の高速化は、現時点では今後の対応予定として示されているものだ。2026年10月28日の更新プログラムによって、ローカルPDFファイルの起動も同様に高速化されたわけではない。具体的な提供時期や、どのようなファイルの関連付けで利用できるようになるかについても、まだ明らかになっていない。

もう一つの注目点は、オープンソースプロジェクトであるChromiumへのコード還元だ。Microsoftは、Edgeの基盤となっているChromiumへ今回の成果を提供し、将来的にはほかのChromiumベースのブラウザでもAccelerated App Launchを利用できるようにする方針を表明している。これが実現すれば、Google ChromeやBrave、Vivaldiなども、同様の起動高速化を採用できる可能性がある。

もっとも、MicrosoftがChromiumへの還元を表明したことと、実際に各ブラウザへ機能が導入されたことは別だ。2026年10月30日時点で確認できた公式発表では、Chromiumへの具体的なコードの取り込み状況や、ほかのブラウザでの提供時期は示されていない。今後はChromium側での実装状況に加え、各ブラウザがこの機能を採用するかどうかが焦点となる。

サードパーティー製ブラウザへの展開を考えるうえでは、Windows側のAPIが制限付きアクセス機能であることも見逃せない。Chromiumのコードベースに対応処理が追加されたとしても、各ブラウザが実際に利用するには、Windows側のAPIを使用できることが前提となる。Microsoftがどのような条件で外部開発者へのアクセスを認めるのかも、普及を左右する要素の一つだ。

今回のAccelerated App Launchは、ブラウザそのものの処理を高速化するのではなく、Windowsと既存のブラウザプロセスの間にある余分な処理を取り除く改良だ。すでに動作しているアプリへ起動要求を届けるためだけに、新しい仲介プロセスを生成する必要があるという従来の仕組みを見直した点に、技術的な意義がある。

一方、その効果が現れるのは、対応するWindows 11環境でEdgeがすでに動作しており、さらに対象となる起動経路を利用した場合に限られる。Microsoftが公表した15%から最大33%という改善率についても、測定時間の絶対値や詳しい試験条件が示されていないため、現時点では第三者による再現性の検証が必要だ。

今後は、異なるCPUやメモリ構成、負荷条件での実測を通じて、仲介プロセスの省略が実際の起動時間を何ミリ秒短縮するのかを明らかにすることが重要となる。また、PDFファイルへの対応拡大やChromiumへのコード還元が進めば、今回の改良はEdgeにとどまらず、Windows上で動作する幅広いアプリケーションの起動処理を見直すきっかけになる可能性がある。