Microsoft Edgeで監査用の台帳ファイルを確認したい管理者にとって、今回のポイントは「Edge本体の新機能」ではなく、Azure Confidential LedgerのバックアップファイルをWebベースのLedger Explorerで監査しやすくなったことです。2026年6月4日公開または更新のAzure Updatesでは、この機能がGeneral Availabilityとして案内されています。つまり、日常的なEdge利用者の画面や設定が変わる更新ではなく、Azure Confidential Ledgerを使っている組織の監査、証跡確認、フォレンジック対応に関係する変更です。(マイクロソフト アジュール)
結論から言うと、管理者が確認すべきことは3つです。バックアップ済みのledgerファイルを用意できるか、監査担当者に安全な読み取り手段を渡せるか、Microsoft Edgeなどの最新ブラウザー上でローカル検証する運用ルールを整備できるかです。特にSAS URLの取り扱い、.committedファイルの形式、監査担当者に渡すデータ範囲は、事前に決めておく必要があります。
Microsoft Edge本体の更新ではなく、Azure Confidential Ledgerの監査ツール更新
今回の更新は、Microsoft EdgeのAI機能やCopilot機能が追加される話ではありません。対象の中心は、Azure Confidential Ledgerのデータを監査するためのLedger Explorer（Offline）です。
Azure Confidential Ledgerは、改ざん耐性のある追記型のデータストアとして、監査証跡、重要なメタデータ、アクセス権限変更、業務トランザクションの記録などを保護する用途で使われます。Microsoftの説明では、イミュータビリティ、改ざん防止、追記のみの操作、暗号技術を組み合わせたデータ完全性の確保が特徴です。(Microsoft Learn)
一方で、監査の現場では「台帳に記録されている」と言うだけでは不十分です。監査担当者や外部のセキュリティ評価者が、実際にファイルを確認し、暗号学的証明を検証できる必要があります。今回のGAは、その確認作業をWebベースのツールで行いやすくするものです。
Microsoft Edgeとの関係は、ブラウザー上で動く監査体験を利用する際の実行環境として見るのが自然です。Edgeのポリシー、ダウンロード制御、SAS URLの扱い、ローカルファイルアップロードの許可などを管理している組織では、ブラウザー運用ルールにも影響します。
何が変わったのか
今回の変更を実務目線で整理すると、次のようになります。
| 観点 | これまで意識しやすかった確認方法 | 今回のGAで重要になる確認方法 | 管理者への影響 |
|---|---|---|---|
| 台帳データの確認 | Azure portal上のLedger Explorerでライブリソースを確認 | Ledger Explorer（Offline）でバックアップファイルやローカルledgerファイルを確認 | 監査用データを切り出して渡す運用がしやすくなる |
| 監査担当者への共有 | Azure環境へのアクセス権付与が必要になりやすい | Azure Ledger BackupのSAS URL、または.committedファイルを使ったローカル確認 | 外部監査人に本番リソース権限を渡さずに確認させやすい |
| 信頼モデル | Azure portal、Azure認証、ライブledgerサービスを経由 | ブラウザー上でファイルから直接検証 | フォレンジックや規制対応で説明しやすい |
| 確認できる情報 | トランザクションと暗号学的証明が中心 | トランザクション、ガバナンス履歴、公開テーブル、内部テーブル、暗号学的証明 | 権限変更やアクセス管理の履歴確認に使いやすい |
| 書き込み | portal explorerでは権限により作成操作も可能 | Offline版は読み取り専用 | 監査用途に限定しやすい |
Ledger Explorer（Offline）は、ブラウザー上で動作し、外部サーバーへデータを送信しないWeb体験として説明されています。データの読み込み方法は、Azure Blob Storageに保存されたバックアップファイルへSAS URLで接続する方法と、ローカルのCCF ledgerファイルである.committedファイルをアップロードする方法の2種類です。(Microsoft Learn)
影響を受ける利用者と、影響を受けにくい利用者
この更新は、すべてのMicrosoft Edge利用者に関係するものではありません。影響範囲を見誤ると、不要なEdge設定変更やユーザー告知をしてしまうため、対象を切り分けて考えることが重要です。
| 対象 | 影響度 | 確認すべきこと |
|---|---|---|
| Azure Confidential Ledgerを運用するAzure管理者 | 高 | バックアップ取得方法、Blob Storage、SAS URL発行、監査手順 |
| セキュリティ管理者・監査担当者 | 高 | 暗号学的証明、ガバナンス履歴、改ざん有無の確認手順 |
| 外部監査人・セキュリティ評価ベンダー | 中〜高 | 受け取るファイル範囲、SAS URLの有効期限、検証環境 |
| Edge管理者 | 中 | ファイルアップロード、SAS URL、GitHub Pagesなどの許可方針 |
| 一般のEdge利用者 | 低 | 通常利用への変更は基本的にない |
| Microsoft 365 Copilot利用者 | 低 | Copilot機能更新ではないため直接影響は限定的 |
Azure Updates上の「Launched」は、実稼働対応として完全にリリースされ、Azure顧客が利用できる状態を指します。今回の更新もAzure Confidential LedgerのGeneral Availabilityとして掲載されています。(マイクロソフト アジュール)
Ledger Explorer（Offline）でできること
Ledger Explorer（Offline）は、単にファイルを開くビューアではありません。監査で説明が求められやすい「誰が、いつ、何を記録し、その記録が改ざんされていないとどう確認できるのか」を見るためのツールです。
トランザクションを時系列で確認できる
読み込んだledgerデータから、台帳に書き込まれたトランザクションを順序付きで確認できます。各トランザクションでは、ペイロードや暗号学的証明データ、Merkle tree proofを確認できます。Microsoftのドキュメントでは、これらの証明によって外部のインデックスサービスに依存せずに独立した検証ができると説明されています。(Microsoft Learn)
実務では、次のような確認に使えます。
- 監査対象期間に記録されたイベントが存在するか
- 重要な権限変更や業務トランザクションが台帳に残っているか
- 台帳の記録が後から変更されていないと説明できるか
- 監査報告書に添付する確認結果を再現できるか
ガバナンス履歴を確認できる
Ledger Explorer（Offline）では、ユーザーの追加・削除、ロール割り当て、アクセス制御の変更など、台帳そのもののガバナンス履歴を確認できます。Microsoftの概念ドキュメントでは、この履歴はledgerに永続的に記録され、portal explorerでは利用できない情報として説明されています。(Microsoft Learn)
これは重要です。監査では「データが正しいか」だけでなく、「そのデータに誰がアクセスできたのか」「権限がいつ変更されたのか」も問われます。たとえば、インシデント調査で「ある期間に外部委託先のアカウントが権限を持っていたか」を確認する場合、ガバナンス履歴が見えることは大きな意味を持ちます。
公開テーブル・内部テーブルを確認できる
公開テーブルでは、アプリケーションレベルでledgerに書き込まれたデータを確認できます。内部テーブルでは、ledgerの正しさを維持するための低レベルな情報を確認できます。通常の監査では公開テーブルやトランザクション確認で足りるケースが多いですが、深いフォレンジック調査では内部テーブルが役立つことがあります。(Microsoft Learn)
ただし、内部テーブルは読み解く前提知識が必要です。一般の監査担当者にそのまま渡すより、開発者やAzure管理者が説明資料を添えて扱うほうが安全です。
管理者が確認すべき設定と準備
今回の更新を実務で活かすには、ツールの存在を知るだけでは不十分です。監査前に、バックアップ、アクセス、ブラウザー、ファイル形式、証跡管理の5点を確認しておきましょう。
バックアップファイルを取得できるか
Azure Ledger Backupを使う場合、Azure Confidential LedgerのバックアップファイルがAzure Blob Storageに保存されている必要があります。Microsoftの手順では、ledgerデータのエクスポートはAzure Confidential Ledger REST APIまたはAzure portalのバックアップ機能を使うと説明されています。(Microsoft Learn)
監査前に確認すべき項目は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| バックアップの保存先 | 監査対象期間のファイルがBlob Storageに存在する |
| バックアップの取得頻度 | 監査で求められる粒度に合っている |
| 保存期間 | 法務・監査・社内規程の保存要件を満たしている |
| 復元目的との切り分け | DR用バックアップと監査閲覧用バックアップの運用目的を混同しない |
| アクセス権 | 監査担当者に本番ledgerの管理権限を渡さずに済む設計にする |
特に失敗しやすいのは、「バックアップは取っているが、監査対象期間の範囲をすぐ特定できない」ケースです。Blob Storageのコンテナー名、フォルダー構成、ファイル命名、対象期間を台帳運用ルールとして残しておくと、監査直前の混乱を減らせます。
SAS URLを安全に発行できるか
Azure Ledger Backupでは、エクスポート済みバックアップファイルへの読み取りアクセスを提供するSAS URLが必要です。SASは便利ですが、漏えいすると第三者に利用されるリスクがあります。MicrosoftはSASについて、アクセス対象、権限、有効期間を細かく制御できる一方、漏えい時のリスクを明示し、HTTPSの利用や慎重な配布を推奨しています。(Microsoft Learn)
監査向けにSAS URLを発行する場合は、次の方針が現実的です。
- 権限は原則として読み取り専用にする
- 有効期限は監査作業に必要な最小期間にする
- URLはメール本文に平文で貼らず、承認済みの安全な共有経路を使う
- 発行者、発行日時、対象ファイル、渡した相手を記録する
- 監査終了後にアクセス不要になったことを確認する
- 可能であればMicrosoft Entra資格情報で保護されるUser delegation SASを優先する
SAS URLは「リンク」ではなく、実質的には一時的なアクセスキーです。Edge上で開けるからといって、チャットやチケットにそのまま貼る運用は避けるべきです。
.committedファイルの形式を満たしているか
ローカルファイルを使う「Audit Ledger Files」では、CCF ledgerファイルである.committedファイルをアップロードします。Microsoftの手順では、拡張子は.committedのみ、ファイル名はledger_<start>-<end>.committed形式、範囲は1から始まり、欠落や重複がないことが要件として示されています。(Microsoft Learn)
たとえば、次のような並びは扱いやすい形式です。
| ファイル例 | 判定 | 理由 |
|---|---|---|
ledger_1-18.committed、ledger_19-25.committed | 適切 | 1から始まり、範囲が連続している |
ledger_1-18.committed、ledger_20-25.committed | 不適切 | 19が欠落している |
ledger_1-18.committed、ledger_18-25.committed | 不適切 | 18が重複している |
audit_1-18.committed | 不適切 | 命名形式が異なる |
ledger_1-18.txt | 不適切 | 拡張子が.committedではない |
ファイル形式の不備は、監査当日に発覚すると対応が遅れます。事前リハーサルとして、実際にEdgeでLedger Explorer（Offline）を開き、サンプルデータを読み込めるか確認しておくと安全です。
Microsoft Edgeのポリシーでブロックされないか
Ledger Explorer（Offline）はWebアプリとして動作します。そのため、Microsoft Edgeを企業管理している場合は、ブラウザー側の制御が監査作業を妨げる可能性があります。
確認すべき代表例は次の通りです。
| 確認項目 | 起こり得る問題 | 対応の考え方 |
|---|---|---|
| 外部サイトへのアクセス制御 | Ledger Explorer（Offline）のページを開けない | 許可対象URLを事前に確認する |
| ローカルファイルアップロード制御 | .committedファイルを読み込めない | 監査端末・専用端末でポリシーを検証する |
| ダウンロード・添付ファイル制御 | バックアップファイルの取得や保存が止まる | 監査用ワークスペースを用意する |
| クリップボード制御 | SAS URL貼り付けが制限される | 安全な入力手順を決める |
| 拡張機能 | データ保護系拡張がファイル読み込みを妨げる | 最小構成の監査用Edgeプロファイルを使う |
ここで大切なのは、Edgeのセキュリティ設定を一律で緩めないことです。監査用端末、監査用プロファイル、監査用ネットワークを分け、必要な期間だけ許可する運用のほうがリスクを抑えられます。
機密データをローカルに残さない運用にする
Ledger Explorer（Offline）はブラウザー上で動作し、読み込んだデータはローカルで処理されると説明されています。外部サーバーに送信されない点は監査上の利点ですが、裏を返すと、監査端末のローカル環境に機密データを扱う責任が生じます。(Microsoft Learn)
次の運用ルールを事前に決めておくと安心です。
- 監査に使う端末を限定する
- 個人PCでの検証を禁止する
- 監査後にダウンロードファイルや一時ファイルを削除する
- 画面共有やスクリーンショットの範囲を制限する
- 監査データの保存場所を暗号化された領域に限定する
- 外部監査人に渡すファイルは必要最小限にする
「オフラインで確認できる」は「どこにでもコピーしてよい」という意味ではありません。むしろ、ローカルファイルの複製管理が重要になります。
開発者が確認すべきポイント
Azure Confidential Ledgerをアプリケーションから利用している開発者は、監査時に「何が記録され、どう説明できるか」を意識する必要があります。
トランザクションの意味が分かる形で記録する
監査担当者は、ハッシュ値やトランザクションIDだけを見ても業務上の意味を判断できません。アプリケーション側では、後から確認しやすい粒度で記録することが重要です。
たとえば、次のような設計が考えられます。
| 記録対象 | 良い例 | 避けたい例 |
|---|---|---|
| 権限変更 | userId、変更前ロール、変更後ロール、申請番号を記録 | 「権限を更新しました」だけを記録 |
| 承認処理 | 承認者、対象申請、承認日時、承認結果を記録 | 承認結果だけを記録 |
| データ連携 | 連携元、連携先、対象データのダイジェストを記録 | 生データを過剰に記録 |
| セキュリティイベント | 検知ルール、重大度、関連リソースIDを記録 | ログ本文を無加工で大量投入 |
台帳は「何でも保存する場所」ではなく、「後から完全性を証明したい重要な記録を残す場所」です。個人情報や機密情報をそのまま入れすぎると、監査時の共有範囲が広がり、かえって扱いにくくなります。
監査用に読み解けるメタデータを残す
Ledger Explorer（Offline）でトランザクションを確認できても、その内容がアプリケーション独自形式すぎると、監査担当者は判断できません。最低限、次の情報を記録設計に含めると実務で使いやすくなります。
- イベント種別
- 業務上の対象ID
- 実行者またはシステム主体
- 実行日時
- 変更前後の要約
- 関連する申請番号、チケット番号、インシデント番号
- データ本体ではなく検証用ハッシュやダイジェスト
特に外部監査に出す可能性がある場合は、開発段階で「この1件のledger記録を見て、第三者が何を判断できるか」を確認しておくべきです。
portal explorerとOffline版の使い分けを決める
Azure Confidential Ledgerには、Azure portal上で使うledger explorerと、ブラウザー上で動作するLedger Explorer（Offline）があります。Microsoftの概念ドキュメントでは、portal explorerは日常的な参照や簡易確認、Offline版はフォレンジック、規制監査、高保証の検証向けと整理されています。(Microsoft Learn)
使い分けの目安は次の通りです。
| シーン | 推奨される確認方法 |
|---|---|
| 開発中に書き込み結果をすぐ確認したい | Azure portal ledger explorer |
| 運用担当者が日常的にトランザクションを確認したい | Azure portal ledger explorer |
| 外部監査人に本番環境権限を渡したくない | Ledger Explorer（Offline） |
| インシデント後に証跡を独立検証したい | Ledger Explorer（Offline） |
| ガバナンス履歴や内部テーブルまで確認したい | Ledger Explorer（Offline） |
この使い分けを決めずに運用すると、監査のたびに「誰にAzure権限を付与するか」で揉めます。平時から、監査用の標準手順としてOffline版を組み込んでおくとよいでしょう。
展開時に失敗しやすいポイント
「Edgeの新機能」と誤解して社内告知してしまう
今回の更新は、Microsoft EdgeのUIやCopilot機能が変わるものではありません。社内告知では「Edgeの更新」ではなく、Azure Confidential Ledger監査用のWebツールがGAになったと説明するほうが正確です。
Edge管理者向けには、次のように伝えると誤解が少なくなります。
Azure Confidential Ledgerの監査作業で、Microsoft Edge上からLedger Explorer（Offline）を利用する可能性があります。必要に応じて、監査用端末でWebアプリへのアクセス、ローカルledgerファイルの読み込み、SAS URL貼り付けが可能か確認してください。
SAS URLを長期間有効にしてしまう
監査日程に余裕を見てSAS URLを長期間有効にしたくなりますが、これは漏えい時の影響範囲を広げます。MicrosoftはSASが漏えいした場合に取得者が利用できるリスクを示しており、HTTPS利用や慎重な配布を推奨しています。(Microsoft Learn)
実務では、監査作業日ごとに短期間のSASを発行し、必要に応じて再発行するほうが安全です。監査担当者が複数いる場合は、誰にどのSASを渡したかも記録しましょう。
ローカルファイルの欠落に気づかない
.committedファイルは、範囲が連続していないと正しく検証できません。ledger_1-18.committedの次がledger_20-25.committedになっているような欠落は、監査結果の信頼性に関わります。ファイルを渡す前に、ファイル名、範囲、件数、ハッシュ値を一覧化しておくと、受け渡しミスを防げます。
監査担当者に渡す情報が多すぎる
「確認できるなら全部渡す」は危険です。Ledger Explorer（Offline）では、トランザクションだけでなく、ガバナンス履歴、公開テーブル、内部テーブルなども確認できます。監査目的に対して過剰な情報を渡すと、機密情報の露出や説明コストが増えます。
監査依頼を受けたら、まず次を確認します。
- 監査対象期間
- 確認したいトランザクション種別
- 必要な証明レベル
- 外部監査人に見せてよい情報範囲
- 内部テーブルまで必要か
- 証跡の保存方法
この整理をせずにファイル一式を渡すと、後から「このデータは見せるべきではなかった」という問題が起きやすくなります。
実務でのおすすめ導入手順
いきなり本番監査で使うのではなく、小さく検証してから標準手順に組み込みましょう。
| 手順 | 実施内容 | 完了条件 |
|---|---|---|
| 事前確認 | Azure Confidential Ledgerの利用状況を棚卸しする | 対象ledger、用途、管理者が分かる |
| バックアップ確認 | 監査対象期間のバックアップをBlob Storageに用意する | ファイル範囲と保存場所が明確 |
| Edge検証 | 監査用端末でLedger Explorer（Offline）を開く | Webアプリへのアクセスが許可されている |
| 読み込みテスト | SAS URLまたは.committedファイルを読み込む | トランザクション一覧が表示される |
| 証明確認 | サンプルトランザクションの暗号学的証明を確認する | 検証結果を説明できる |
| 権限確認 | 監査担当者に渡すデータ範囲を決める | 過不足のない共有範囲になる |
| 手順化 | 画面操作、ファイル受け渡し、削除手順を文書化する | 次回監査で再現できる |
特におすすめなのは、年次監査の直前ではなく、四半期ごとの内部点検で一度試すことです。ファイル形式、Edgeポリシー、SAS URL、監査端末の制約は、実際に操作しないと気づきにくい問題が多いためです。
監査担当者に渡す前のチェックリスト
最後に、管理者向けの実用チェックリストをまとめます。
| チェック項目 | 確認 |
|---|---|
| 今回の更新がEdge本体ではなくAzure Confidential Ledger向けであることを関係者に説明した | □ |
| 監査対象のAzure Confidential Ledgerインスタンスを特定した | □ |
| 監査対象期間のバックアップファイルを用意した | □ |
| SAS URLは読み取り専用・短期間・安全な経路で共有する方針にした | □ |
.committedファイルの命名規則と連続性を確認した | □ |
| Microsoft Edgeの管理ポリシーでWebアプリやファイルアップロードが妨げられないか確認した | □ |
| 監査用端末でLedger Explorer（Offline）の読み込みテストを行った | □ |
| 監査担当者に見せる範囲と見せない範囲を決めた | □ |
| 監査後のローカルファイル削除・SAS無効化・記録保存の手順を決めた | □ |
| 次回以降も再現できるように手順書へ反映した | □ |
今回のGeneral Availabilityは、Microsoft Edgeを日常利用するユーザー向けの目立つ変更ではありません。しかし、Azure Confidential Ledgerを使って重要な証跡を保管している組織にとっては、監査対応を現実的に進めるための大きな改善です。まずは、監査対象のledger、バックアップファイル、SAS URL、Edgeの利用ポリシーを確認し、社内の監査手順にLedger Explorer（Offline）を組み込むところから始めましょう。
コメント