Edge 147 Web プラットフォームのリリースで最も実務的に重要なのは、Device Bound Session Credentials（DBSC）の掲載です。これはセッション Cookie を特定のデバイスに結び付け、盗まれた Cookie だけではセッションを継続しにくくする仕組みです。結論からいえば、一般利用者は Edge を最新に保ち、Web サービス運営者や認証基盤担当者は「ブラウザー更新だけで完結する機能ではなく、サイト側実装が前提」と理解するのが第一歩です。Microsoft の Stable Channel リリースノートでは Edge 147.0.3912.60 が 2026年4月10日に公開され、そこから Edge 147 の Web プラットフォーム リリースノートが案内されています。(Microsoft Learn)
この記事では、Edge 147 の DBSC が何を変えるのか、Cookie 対策としてどこまで有効か、Microsoft Entra の Token Protection と何が違うのか、現場で何を確認すべきかを実務目線で整理します。
Edge 147 Web プラットフォームのリリースで確認できること
日付を分けて見ると整理しやすいです。Edge 147 の Web プラットフォーム リリースノート自体は 2026年4月1日付で公開されており、Stable Channel の Edge 147.0.3912.60 は 2026年4月10日に公開されています。Stable Channel 側は、この Web プラットフォーム更新を「最新の Web プラットフォーム機能」として参照しており、147世代で注目すべき変更のひとつとして DBSC を確認できます。(Microsoft Learn)
Edge 147 のノートでは、DBSC は「セッション資格情報を特定のデバイスに結び付け、盗まれたセッション Cookie を再利用しにくくする」機能として紹介されています。つまり今回の要点は、単なる不具合修正ではなく、ブラウザーのセッション保護モデルが一段進んだことにあります。(Microsoft Learn)
なお、公開中の Microsoft Learn を見ると、Edge 145 の Web プラットフォーム ノートにも device-bound session credentials の記載があります。そのため、147を「初登場」と断定するより、「147の公開ノートでも重要機能として確認できる」と整理したほうが事実関係に忠実です。社内共有や記事化では、この一点を丁寧に書くだけで信頼感が上がります。(Microsoft Learn)
Device Bound Session Credentials（DBSC）の仕組み
DBSC の狙いは、長寿命の Cookie をそのまま bearer 型の認証材料として使い続ける弱点を減らすことです。W3C の仕様では、DBSC は長寿命 Cookie ベースのセッション盗難を減らし、より安全に保護できる秘密鍵を使ったセッション認証へ移すための仕組みと説明されています。要するに、「Cookie の値さえ持っていれば使える」状態から、「Cookie に加えて、その端末にある秘密鍵の所持も必要」な状態へ近づける技術です。(W3C)
ここで重要なのは、DBSC は端末準拠や資産管理の証明をする仕組みではないことです。W3C 仕様は、新たなプライバシー識別子を漏らさないことを重視しつつ、特定の端末状態やその端末が信頼済みかどうかを保証するものではないと明示しています。つまり、MDM やデバイスコンプライアンスの代替ではなく、あくまでセッション継続の証明を強める技術です。(W3C)
仕組みを3ステップで理解する
- ログイン成功時、サイトは通常の Cookie に加え、
Secure-Session-Registrationヘッダーを返します。 - ブラウザーは登録エンドポイントへ公開鍵を送り、サーバーはその鍵をセッションと紐付けたうえで短寿命 Cookie へ切り替えます。
- 短寿命 Cookie の更新時には、ブラウザーが秘密鍵の所持を証明できた場合だけ、新しい Cookie が発行されます。
このため、攻撃者が Cookie だけを別デバイスへ持ち出しても、更新フェーズで秘密鍵を示せなければセッション継続が難しくなります。DBSC の実装ガイドでは、既存の大半のエンドポイントはそのままにしつつ、登録エンドポイントと更新エンドポイントを追加する設計が想定されています。(Chrome for Developers)
DBSCで変わるのは「Cookie が盗まれた後」の防御
従来のセッション防御は、「Cookie を盗まれにくくする」「有効期限を短くする」「怪しいアクセスを検知する」といった対策が中心でした。DBSC が重要なのは、盗難後の再利用そのものを難しくする点です。W3C 仕様でも、DBSC のゴールはセッション盗難を減らすことにあり、短寿命 Cookie の更新時に秘密鍵ベースの証明を要求する実装が想定されています。(W3C)
ただし、ここを過大評価してはいけません。W3C の仕様は、攻撃者がすでにユーザー端末上で活動している場合の一時的なブラウザー操作や、セッション登録時点でユーザーエージェントに干渉されているケースまでは防げないとしています。DBSC は「別デバイスへの持ち出し再利用」に強いのであって、端末侵害そのものを無効化する魔法ではありません。EDR、端末準拠、セッション失効、異常検知は引き続き必要です。(W3C)
Edge を 147 に更新しただけで、すべてのサイトが自動で保護されるわけでもありません。 DBSC は Web プラットフォーム機能なので、効果を出すにはサイト側が登録ヘッダーや更新エンドポイントを実装する必要があります。利用者目線では「対応サイトで恩恵を受ける機能」、運営者目線では「認証基盤に手を入れて初めて効く機能」と捉えるのが正確です。(Chrome for Developers)
実装・運用で失敗しやすいポイント
DBSC は既存システムを全面刷新せずに導入しやすい一方、更新フローとフォールバック設計を雑にすると、可用性や UX で詰まりやすい機能です。公開されている仕様と実装ガイドから、特に見落としやすい点を整理すると次の通りです。(Chrome for Developers)
| 失敗しやすい点 | 起きやすい理由 | 実務での対策 |
|---|---|---|
| 更新間隔を極端に短くする | 鍵署名や更新処理が増え、失敗率や遅延の温床になりやすい | まずは PoC で更新頻度と体感性能を測る |
| 更新エンドポイントの可用性を軽視する | 到達不能時に意図しない再認証や無 Cookie リクエストが起こりうる | 監視、冗長化、障害時フローを決める |
| iframe やサードパーティ Cookie 前提の構成を見落とす | DBSC 管理の短寿命 Cookie が制約を受けることがある | 埋め込み構成と Cookie 属性を先に洗い出す |
| DBSC だけで端末侵害も防げると考える | ローカル常駐攻撃や登録時侵害は別問題 | EDR、端末準拠、セッション失効と併用する |
実装ガイドでは、DBSC 管理の短寿命 Cookie に加えて、更新用の長寿命 Cookie を併用する代替パターンも示されています。これは DBSC 障害と純粋な未認証を分けて扱いやすくする一方、長寿命 Cookie をどう守るかという運用設計は残ります。また、DBSC は HTTPS 限定で、Partitioned cookies は対象外です。(Chrome for Developers)
設計の起点として、公開ガイドの例では 10 分の短寿命 Cookie が使われていますが、これは固定値ではありません。管理画面なのか、一般利用画面なのか、更新失敗をどこまで許容できるのかで最適値は変わります。短くすれば安全、ではなく、「更新に失敗したときの影響」まで含めて決めるのが実務です。(Chrome for Developers)
Microsoft Entra の Token Protection とどう違うか
名前が似ているので混同しやすいのですが、DBSC と Microsoft Entra の Token Protection は別物です。Token Protection は Conditional Access のセッション制御で、PRT などのデバイス バインド済みサインイントークンのみを受け付けることでトークンのリプレイを減らす機能です。一方 DBSC は、Web サイト側が実装することでブラウザーの Cookie セッション継続を保護する仕組みです。(Microsoft Learn)
さらに実務上大きい違いとして、Microsoft Entra の Token Protection は現時点でネイティブアプリ中心で、ブラウザーベースのアプリはサポート対象外です。Windows 向けガイドでも、Microsoft Edge の対応は「Edge プロファイルへのサインインのみ」とされており、一般的な Web アプリの Cookie セッション保護とは切り分けて考える必要があります。つまり、Edge 147 の DBSC が話題だからといって、Entra のポリシーだけで同じ保護がブラウザー全体に広がるわけではありません。(Microsoft Learn)
判断に迷ったら、次の切り分けで考えると整理しやすいです。
- 自社 Web アプリや SaaS の Cookie セッションを守りたい → DBSC
- Microsoft 365 や Entra 管理下のサインイントークンを守りたい → Token Protection
(Microsoft Learn)
立場別に何を確認すべきか
DBSC の設計要件と Entra の導入ガイドを合わせてみると、やるべきことは立場ごとにかなり違います。特に情シスと Web 開発が「どちらの層を守る話か」を最初に分けるのが重要です。(Chrome for Developers)
| 立場 | まず押さえること | 最初の一手 |
|---|---|---|
| 一般ユーザー | DBSC は対応サイトで効く機能で、Edge 更新だけで全サイトが自動保護されるわけではない | Edge を最新にし、重要サービスのセッション一覧やログイン通知も確認する |
| 情シス・セキュリティ担当 | DBSC と Token Protection は別系統。混同すると施策がずれる | 高リスク Web アプリとネイティブアプリを棚卸しし、Entra 側は影響確認から始める |
| Web アプリ・認証基盤担当 | サイト側の登録・更新実装が前提。監視とフォールバックも必要 | PoC でヘッダー追加、短寿命 Cookie、更新エンドポイント、ログ設計を固める |
Edge 147 を受けて今やること
長寿命 Cookie を棚卸しする。 まずは管理画面、顧客ポータル、SSO ハブ、サポートツールなど、Cookie が盗まれたときの被害が大きい画面を洗い出します。DBSC は既存スタックを全面的に書き換えずに段階導入しやすいので、価値の高いセッションから優先順位を付けるのが現実的です。(W3C)
登録と更新の PoC を小さく始める。 Secure-Session-Registration ヘッダー、登録エンドポイント、更新エンドポイントの3点を最小構成で試し、「正常系」より先に「更新失敗時に何が起こるか」を確認します。既存エンドポイントの大半に手を入れなくてよい設計なので、最初から全画面に広げる必要はありません。(Chrome for Developers)
可用性とフォールバックを先に決める。 更新エンドポイントの障害、鍵署名の失敗、サードパーティ Cookie 制約が起きたときに、再認証へ倒すのか、長寿命 Cookie にフォールバックさせるのかで UX とリスクは大きく変わります。実装前にここを決めないと、本番で「安全になったが使えない」状態になりがちです。(Chrome for Developers)
Entra 環境は別トラックで report-only から検証する。 Microsoft Entra の Token Protection は、対応アプリと対応リソースに対して段階的に広げるべき機能です。Microsoft のガイドでも、まず pilot グループと report-only で影響を確認し、ログを見てから強制に進めることが推奨されています。(Microsoft Learn)
Edge 147 Web プラットフォームのリリースで注目すべきなのは、ブラウザーのセッション保護が「盗難の検知」中心から「盗難後の再利用妨害」へ一歩進んだことです。まずは、自社や利用中サービスの認証方式を棚卸しし、Cookie セッションの話なのか、Entra のサインイントークンの話なのかを分けて考えるところから始めると、次の施策がぶれません。(Microsoft Learn)
コメント