WebView2を組み込んだデスクトップアプリで「このドメインだけ厳しくしたい」「社内ポータルだけ例外扱いしたい」と考えていた開発者にとって、Microsoft Edge WebView2 Runtime 148 prereleaseのOrigin Configuration APIは注目すべき変更です。2026年4月18日時点で確認できるMicrosoftのリリースノートでは、WebView2アプリがオリジン単位で機能やセキュリティポリシーを制御できるExperimental APIとして追加されています。(Microsoft Learn)
結論から言うと、このAPIは「WebView2全体に一律の設定をかける」設計から、「読み込むWebコンテンツの出所ごとにポリシーを変える」設計へ進むための土台です。まだprerelease段階のため本番投入前提で固定的に設計するのは早いものの、デスクトップアプリ開発者、セキュリティアーキテクト、エンタープライズ製品チームは今のうちに評価しておく価値があります。
WebView2 Runtime 148 prereleaseで追加されたOrigin Configuration APIとは
Microsoft Edge WebView2 Runtime 148向けのPrerelease SDK 1.0.3965-prereleaseでは、Origin Configuration APIがExperimental APIとして追加されました。対象となるRuntimeは、Microsoft Edge 148.0.3965.0以降に同梱されるWebView2 Runtimeです。(Microsoft Learn)
Origin Configuration APIの役割は、WebView2内で表示するコンテンツのオリジンごとに、機能やセキュリティポリシーを切り替えることです。従来はWebView2プロファイルやコントロール全体に対して一律の設定を行う考え方が中心でした。新APIでは、たとえば以下のような判断がしやすくなります。
| これまで起きやすかった設計課題 | Origin Configuration APIで考えやすくなる設計 |
|---|---|
| WebView2全体に同じセキュリティ設定を適用するしかない | 信頼済みドメインと外部ドメインで設定を分ける |
| セキュリティを強めると一部の既存Web機能が壊れる | 影響範囲をオリジン単位で切り分けて検証する |
| 社内コンテンツ、SaaS、外部ページを同じ扱いにしがち | コンテンツの出所ごとにリスク評価を反映する |
| 例外設定がコード上で散らばりやすい | ポリシー設計として整理しやすくなる |
特に重要なのは、今回のAPIが単なる利便性向上ではなく、埋め込みブラウザーのセキュリティポリシー設計に新しい選択肢を与える変更だという点です。
なぜ「オリジン単位」の制御が重要なのか
WebView2は、Windowsデスクトップアプリの中にWebコンテンツを表示できる強力な仕組みです。WPF、WinForms、Win32、.NETアプリなどで、WebベースのUI、認証画面、管理コンソール、外部SaaS連携画面を組み込む用途で使われます。
一方で、WebView2は通常のブラウザーとは違い、ネイティブアプリとの距離が近くなります。Microsoftのセキュリティガイドでも、WebView2でホストするWebコンテンツはネイティブアプリのリソースやAPIへ近づき得るため、適切に分離しないと脆弱性につながると説明されています。(Microsoft Learn)
ここで問題になるのが、WebView2内で表示するコンテンツの信頼度が同じではないことです。
たとえば、同じアプリ内でも次のようにリスクは異なります。
| 表示するコンテンツ | 典型的な例 | リスクの見方 |
|---|---|---|
| 自社管理の固定コンテンツ | https://app.example.com | 比較的管理しやすいが、サプライチェーンや設定ミスは残る |
| 社内ポータル | https://portal.corp.example | 認証・権限管理と連動するため、情報漏えい時の影響が大きい |
| 外部SaaS | CRM、ヘルプデスク、BIツール | 自社でコードを制御できないため、例外設計が必要 |
| ユーザー入力に基づくURL | ドキュメントビューア、リンクプレビュー | フィッシングや意図しない遷移への警戒が必要 |
| ローカルまたは開発用コンテンツ | localhost、検証環境 | 本番と開発でポリシー差が生まれやすい |
すべてを同じセキュリティ設定で扱うと、厳しすぎて動かない画面が出るか、緩すぎて攻撃面が広がるかのどちらかになりがちです。Origin Configuration APIは、この中間を設計するためのAPIとして見られます。
Origin Configuration APIでできること
リリースノートによると、Origin Configuration APIではCoreWebView2ProfileのSetOriginFeaturesメソッドを使い、1つ以上のオリジンまたはオリジンパターンに対して機能設定を適用できます。指定方法は、https://contoso.comのような完全一致の文字列だけでなく、https://[*.]contoso.comのようなワイルドカードパターンにも対応します。 (Microsoft Learn)
2026年4月18日時点で注目される構成要素は次のとおりです。
| API・要素 | 役割 |
|---|---|
CoreWebView2Profile.SetOriginFeatures | 指定したオリジンパターンに対して機能の有効・無効を設定する |
CoreWebView2Profile.GetEffectiveFeaturesForOriginAsync | 指定したオリジンに最終的に適用される機能設定を非同期で取得する |
CoreWebView2OriginFeature | オリジン単位で制御可能な機能を表す列挙型 |
CoreWebView2OriginFeatureState | 機能をEnabledまたはDisabledに設定する状態値 |
EnhancedSecurityMode | 現時点でオリジン単位制御の対象として示されている機能 |
SetOriginFeaturesのドキュメントでは、同じ機能と状態の組み合わせで複数回呼び出した場合、以前のオリジン一覧は上書きされ、最新の呼び出しが優先されると説明されています。また、同じ機能設定に対して空のoriginsコレクションを渡すと、設定を既定値へ戻す扱いになります。(Microsoft Learn)
現時点での中心はEnhanced Security Modeのオリジン制御
今回のAPIで最初に見るべき対象は、EnhancedSecurityModeです。MicrosoftのAPIドキュメントでは、CoreWebView2OriginFeatureのフィールドとしてEnhancedSecurityModeが示されており、JITコンパイルや一部のJavaScript APIなど、セキュリティリスクになり得るWebプラットフォーム機能を制限または無効化する追加保護として説明されています。(Microsoft Learn)
実務上は、次のような設計が考えられます。
| シナリオ | 設計例 |
|---|---|
| 外部サイトをWebView2で表示する | 外部オリジンではEnhanced Security Modeを有効化する |
| 自社の業務アプリだけ高度なWeb機能が必要 | 自社オリジンでは通常モード、外部オリジンでは強化モードを検討する |
| 複数のサブドメインを持つSaaSを組み込む | https://[*.]example.comのようなパターンでまとめて評価する |
| セキュリティレビューで例外管理が必要 | オリジン、機能、理由、担当者、検証日を台帳化する |
ただし、「Enhanced Security Modeを有効にすれば安全」と単純化するのは危険です。セキュリティ設定は攻撃面を減らすための手段であり、入力検証、ナビゲーション制御、メッセージ検証、ホストオブジェクトの公開範囲管理と組み合わせて初めて効果を発揮します。
実装前に押さえるべきAPIの挙動
Origin Configuration APIを評価するときは、機能名だけでなく、設定の適用ルールを確認しておく必要があります。
より具体的なパターンが優先される
複数の設定が同じオリジンに該当する場合、Microsoftのリリースノートでは、ホスト名、スキーム、ポートの順に評価され、最も具体的なパターンが優先されると説明されています。(Microsoft Learn)
たとえば、次のような設計では注意が必要です。
https://[*.]example.com → EnhancedSecurityMode: Enabled
https://admin.example.com → EnhancedSecurityMode: Disabledこの場合、admin.example.comにはより具体的な設定が適用される可能性があります。便利な一方で、例外設定が増えると「どのポリシーが効いているのか」が分かりにくくなります。
そのため、実装時は設定をコードに直接散らすのではなく、次のようなルール表を先に作るべきです。
| 優先度 | オリジンパターン | 設定 | 理由 |
|---|---|---|---|
| 高 | https://admin.example.com | Disabled | 管理画面の互換性検証用。恒久例外にしない |
| 中 | https://[*.]example.com | Enabled | 自社サブドメイン全体の保護を強化 |
| 低 | その他外部オリジン | Enabled | 未分類コンテンツの攻撃面を減らす |
例外が必要な場合でも、理由と期限を残しておくと、後からセキュリティレビューや監査で説明しやすくなります。
有効なオリジン形式を使う必要がある
GetEffectiveFeaturesForOriginAsyncは、指定したオリジンに対して最終的に適用される機能設定を返すAPIです。ドキュメントでは、問い合わせるoriginはスキームとホストを含む有効なオリジンである必要があり、無効な場合はE_INVALIDARGで失敗すると説明されています。(Microsoft Learn)
実装時にありがちな失敗は、URLとオリジンを混同することです。
| 入力例 | 扱い |
|---|---|
https://www.example.com | オリジンとして扱いやすい |
https://www.example.com/path/page.html | URLであり、オリジン設計では切り分けが必要 |
www.example.com | スキームがないため不適切 |
javascript:alert(1) | オリジンとして扱うべきではない |
| 空文字やnull | 例外処理が必要 |
アプリ側では、ユーザー入力や設定ファイルの値をそのままAPIへ渡さず、スキーム、ホスト、ポートを明示的に正規化してから扱う設計が望ましいです。
デスクトップアプリ開発者が評価すべきポイント
WebView2アプリを開発しているチームは、まず「自分たちのアプリがどのオリジンを表示しているか」を棚卸しするところから始めるべきです。Origin Configuration APIはポリシー制御のAPIですが、前提となるオリジン管理が曖昧だと効果を発揮しません。
まず確認するべきチェックリスト
| 確認項目 | 見るべきポイント |
|---|---|
| WebView2で表示するURLの一覧 | 固定URLか、ユーザー操作で変わるURLか |
| 自社管理と外部管理の区別 | 自社がコード・設定・配信を制御できるか |
| 認証情報の扱い | Cookie、トークン、SSO、ローカルストレージの利用状況 |
| ネイティブ連携の有無 | postMessage、ホストオブジェクト、ExecuteScriptの使用箇所 |
| 互換性に敏感な機能 | JavaScript、WebAssembly、拡張的なWeb APIへの依存 |
| セキュリティ例外の有無 | 一時例外か、恒久的な仕様か |
特にExecuteScriptやWebメッセージを使っているアプリでは、オリジン確認が重要です。Microsoftのセキュリティガイドでも、WebView2内のドキュメントのオリジンを常に確認し、ExecuteScriptやPostWebMessageAsJsonなどで情報を渡す前に信頼性を評価することが推奨されています。(Microsoft Learn)
セキュリティアーキテクト向けの設計観点
Origin Configuration APIは、開発者だけでなくセキュリティアーキテクトにとっても重要です。理由は、WebView2のセキュリティ設定を「実装詳細」ではなく「ポリシー」として扱いやすくなるからです。
ポリシー設計では「信頼度」ではなく「必要権限」で考える
よくある失敗は、「自社ドメインだから安全」「有名SaaSだから安全」といった信頼度だけで設定を決めることです。実務では、信頼度よりもそのオリジンに何を許可する必要があるのかで判断するほうが安全です。
| 判断軸 | 良くない判断 | 望ましい判断 |
|---|---|---|
| 自社サイト | 自社だからすべて許可 | 必要なWeb機能だけ許可 |
| 外部SaaS | 大手サービスだから許可 | 連携に必要な範囲を確認 |
| 管理画面 | 管理者しか使わないから緩くする | 権限が強い画面ほど慎重に扱う |
| 開発環境 | 社内だけだから例外にする | 本番との差分を明示し、期限を設ける |
Origin Configuration APIを使う場合も、まずは次のような分類を作ると実装に落とし込みやすくなります。
| 分類 | 例 | 推奨される考え方 |
|---|---|---|
| 許可済み自社オリジン | 業務UI、管理コンソール | 必要機能を確認し、最小権限で設定 |
| 制限付き外部オリジン | SaaS、外部ヘルプページ | 既定で強めの制限を検討 |
| 一時許可オリジン | 移行中サービス、検証環境 | 期限、責任者、削除条件を明記 |
| 未分類オリジン | ユーザー入力URL、リダイレクト先 | 原則として厳格に扱う |
エンタープライズ製品チームでの活用シーン
グローバル向けのエンタープライズデスクトップアプリでは、顧客ごとにWebView2へ読み込むURLが異なることがあります。地域別のIdP、顧客専用ドメイン、オンプレミス連携、SaaS連携などが混在するため、全顧客に同じ設定を強制すると運用が難しくなります。
Origin Configuration APIが安定すれば、将来的には次のような設計に発展させやすくなります。
| 活用シーン | 期待できる効果 |
|---|---|
| 顧客テナントごとのドメイン許可 | 企業ごとのセキュリティ要件に合わせやすい |
| 地域別サービスのポリシー分離 | EU、米国、日本などの運用差分を管理しやすい |
| 外部IdP連携の例外管理 | 認証フローの互換性と安全性を両立しやすい |
| サポート用診断ツール | 実際に適用された機能設定を確認しやすい |
| 管理者向けポリシーテンプレート | 製品設定として説明しやすい |
ただし、prerelease段階のAPIを前提に顧客向け管理画面や契約仕様を固めるのは避けるべきです。MicrosoftのAPIドキュメントにも、prerelease製品に関する情報は正式リリース前に大きく変更される可能性があり、Microsoftは提供情報について保証しない旨が記載されています。(Microsoft Learn)
現時点では、製品ロードマップ上の調査項目、検証ブランチ、PoCとして扱うのが現実的です。
実装イメージ: C#でどう考えるか
以下は、設計イメージを示すための疑似的なC#例です。実際のコードでは、利用しているSDKバージョン、APIの最終仕様、例外処理、アプリの初期化順序に合わせて調整してください。
// 例: 特定のオリジンに対してEnhanced Security Modeを有効化する設計イメージ
var origins = new[]
{
"https://[*.]example.com",
"https://external-service.example"
};
var features = new[]
{
new KeyValuePair<CoreWebView2OriginFeature, CoreWebView2OriginFeatureState>(
CoreWebView2OriginFeature.EnhancedSecurityMode,
CoreWebView2OriginFeatureState.Enabled
)
};
webView.CoreWebView2.Profile.SetOriginFeatures(origins, features);評価時は、設定後にGetEffectiveFeaturesForOriginAsyncで実際に効いている設定を確認する運用を入れると安全です。
var effectiveFeatures =
await webView.CoreWebView2.Profile.GetEffectiveFeaturesForOriginAsync(
"https://app.example.com"
);
foreach (var feature in effectiveFeatures)
{
Console.WriteLine($"{feature.Key}: {feature.Value}");
}この確認処理は、開発中のデバッグだけでなく、社内検証ツールや診断ログにも応用できます。特に複数のワイルドカード設定と個別例外が混在する場合、「意図した設定が本当に適用されているか」を可視化する仕組みは重要です。
既存のWebView2セキュリティ対策とどう組み合わせるか
Origin Configuration APIは便利ですが、既存のWebView2セキュリティ対策を置き換えるものではありません。むしろ、既存対策にオリジン単位のポリシー層を追加するものとして捉えるべきです。
Microsoftのセキュリティガイドでは、不要なWebコンテンツ機能を制限する方法として、AreHostObjectsAllowed、IsWebMessageEnabled、IsScriptEnabled、AreDefaultScriptDialogsEnabledなどの設定を必要に応じて無効化することが示されています。(Microsoft Learn)
実務では次のように組み合わせます。
| レイヤー | 対策例 | 目的 |
|---|---|---|
| ナビゲーション制御 | 許可済みURL以外への遷移をブロック | 想定外のページ表示を防ぐ |
| メッセージ検証 | WebMessageReceivedで送信元と内容を検証 | 悪意ある入力を防ぐ |
| ホストオブジェクト制御 | 必要な画面だけ公開 | ネイティブAPIへの攻撃面を減らす |
| WebView2設定 | 不要なスクリプトやダイアログを制限 | 機能の最小化 |
| Origin Configuration API | オリジンごとに機能ポリシーを切り替え | 信頼境界に応じた制御 |
| ログ・監査 | 適用ポリシーと遷移履歴を記録 | 障害調査とセキュリティレビュー |
セキュリティ設計で重要なのは、1つのAPIに依存しないことです。WebView2はネイティブアプリとWebの境界にあるため、ナビゲーション、メッセージ、ホスト連携、ポリシー、監査をセットで考える必要があります。
Runtime 148 prereleaseで同時に確認したい破壊的変更
WebView2 Runtime 148 prereleaseでは、Origin Configuration API以外にも、ProcessFailedイベントの理由がより細かく返るようになる変更が示されています。これまでUnexpectedにまとめられていた一部の終了シナリオについて、NormalExit、AbnormalExit、IntegrityFailureなどの値で判別できるようになる内容です。(Microsoft Learn)
この変更はセキュリティ運用にも関係します。たとえば、IntegrityFailureを検知できれば、単なるクラッシュではなくコード整合性に関わる問題としてログやアラートの扱いを変えられます。
| 変更点 | 開発チームが確認すべきこと |
|---|---|
ProcessFailedの理由が細分化 | 既存のUnexpected前提の分岐が壊れないか |
| 148・149では機能フラグが既定無効 | 早めにフラグ有効化でテストする |
| 150以降で既定有効予定 | 監視、ログ、例外処理の見直しが必要 |
Origin Configuration APIの検証とあわせて、WebView2の異常終了時の復旧処理やログ分類も確認しておくと、セキュリティと運用の両面で準備が進みます。
導入判断: 今すぐ本番採用するべきか
現時点での判断は、本番採用ではなく、設計検証と互換性評価を始める段階です。
理由は明確です。Origin Configuration APIはPrerelease SDKのExperimental APIです。正式リリース前に仕様や挙動が変わる可能性があります。したがって、顧客向けの安定機能としてすぐに前提化するより、次のような進め方が現実的です。
| フェーズ | やること |
|---|---|
| 調査 | Microsoft LearnのリリースノートとAPIドキュメントを確認 |
| 棚卸し | WebView2で表示する全オリジンを一覧化 |
| 分類 | 自社、外部、顧客管理、開発環境、未分類に分ける |
| PoC | 代表的なオリジンにEnhanced Security Modeを適用して検証 |
| 互換性確認 | ログイン、SSO、Webメッセージ、JavaScript依存箇所をテスト |
| 診断整備 | GetEffectiveFeaturesForOriginAsyncで適用状態を確認 |
| レビュー | セキュリティチームと例外ルールを整理 |
特にエンタープライズ製品では、顧客環境ごとにWebView2 Runtimeの更新タイミングが異なることがあります。Runtimeのバージョン、Evergreen Runtimeの配布状況、固定バージョンRuntimeの利用有無も含めて確認しましょう。
よくある失敗と回避策
ワイルドカードを広くしすぎる
回避策は、最初から広いワイルドカードを使わず、重要なオリジンを個別指定してから範囲を広げることです。
例外設定を恒久化してしまう
互換性問題を避けるために特定オリジンだけ制限を緩めることはあります。しかし、理由や期限を記録しないと、数年後には誰も削除できない「謎の例外」になります。
例外には必ず次の情報を残します。
| 記録項目 | 例 |
|---|---|
| 対象オリジン | https://legacy.example.com |
| 例外内容 | Enhanced Security Modeを無効化 |
| 理由 | 旧UIが特定のJavaScript挙動に依存 |
| 期限 | 次回メジャーアップデートまで |
| 担当 | AppSecチーム、対象機能オーナー |
| 再評価条件 | SDK安定版昇格時、またはUI刷新時 |
WebView2のURL遷移を過信する
初期表示URLが安全でも、ユーザー操作、リダイレクト、スクリプトによって別のページへ遷移することがあります。Microsoftのセキュリティガイドでも、WebView2コントロールが別ページへ移動している可能性を踏まえ、ドキュメントのオリジンを確認することが推奨されています。(Microsoft Learn)
Origin Configuration APIを使っても、ナビゲーションイベントでの確認やブロック処理は引き続き必要です。
評価を始めるための実務手順
WebView2 Runtime 148 prereleaseのOrigin Configuration APIを評価するなら、次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 成果物 |
| -: | ——————————- | ———— |
| 1 | WebView2 SDKとRuntimeの対象バージョンを確認 | 検証環境のバージョン一覧 |
| 2 | アプリが表示するURLを収集 | オリジン一覧 |
| 3 | オリジンを信頼境界ごとに分類 | ポリシー分類表 |
| 4 | Enhanced Security Modeの適用候補を決める | 適用候補リスト |
| 5 | 代表画面でPoCを実装 | 検証ブランチ |
| 6 | ログイン、SSO、Webメッセージ、ホスト連携をテスト | 互換性レポート |
| 7 | 実効設定を取得してログ化 | 診断ログ |
| 8 | 例外ルールをレビュー | セキュリティレビュー記録 |
この手順で進めると、単に「新APIを試した」だけでなく、将来の正式採用に向けた判断材料を残せます。
WebView2のセキュリティ設計は「一律」から「文脈別」へ進む
Microsoft Edge WebView2 Runtime 148 prereleaseで追加されたOrigin Configuration APIは、WebView2のセキュリティ設計を一段細かくするための重要な動きです。オリジンごとにEnhanced Security Modeなどの機能を制御できるようになることで、埋め込みブラウザーのポリシー設計は「全体設定」から「コンテンツの出所に応じた制御」へ進みやすくなります。
ただし、現時点ではprereleaseのExperimental APIです。本番機能として急いで組み込むより、まずはWebView2で表示しているオリジンを棚卸しし、信頼境界、例外ルール、互換性リスクを整理することが先です。
次に取るべき行動はシンプルです。自社アプリのWebView2利用箇所を洗い出し、どのオリジンにどのセキュリティポリシーを適用したいのかを表にしてください。そのうえで、Runtime 148 prerelease環境でOrigin Configuration APIを小さく検証すれば、正式化されたときに慌てず設計へ取り込めます。
コメント