2026年7月9日時点で確認できるMicrosoft公式情報「Protecting Microsoft at AI speed: How SFI proactively hardens our cloud」（公式ページの日付表記は7月8日）は、Microsoft 365やAzureに追加される顧客向け新機能ではありません。
結論から言えば、管理者が今すぐ有効化する設定や、追加購入すべきライセンスはありません。今回発表されたのは、Microsoftが自社クラウドのコード、構成、ID、ネットワーク、実行時状態をマルチエージェントAIで横断的に評価し、侵害されにくい状態へ継続的に強化するための内部システムです。(Microsoft)
ただし、「顧客向け製品ではないから関係ない」と判断するのも早計です。この発表の重要点は、セキュリティ評価の対象をコード単体からサービス全体へ広げ、複数の小さな不備が連鎖する攻撃経路まで検証していることです。AzureやMicrosoft Entra IDを使ったシステムを開発・運用している企業は、自社のセキュリティレビューを見直すための実践モデルとして活用できます。
MicrosoftのAI更新「Protecting Microsoft at AI speed」の結論
公式発表の内容を、利用者や管理者の判断に必要な項目へ整理すると次のようになります。
| 確認項目 | 結論 |
|---|---|
| 何が発表されたか | MicrosoftのクラウドサービスをAIで評価・強化する内部システム |
| 顧客が直接利用できるか | 利用できない。顧客向け製品やサービスではない |
| ライセンスや契約 | 本システムを利用するための購入手続きはない |
| 管理者による有効化 | 顧客向けの設定、ポリシー、APIは案内されていない |
| 主な評価対象 | コード、インフラ定義、ID設定、実行時設定、ネットワーク構成、稼働中リソース |
| 顧客への直接的な変更 | テナント設定や利用方法の変更は発表されていない |
| 推奨される対応 | SFIの考え方を使い、自社サービスをシステム全体で点検する |
Microsoftは、このシステムを自社クラウド専用の内部機能と明記しています。一方で、そこで得られた知見やパターンは、今後のMicrosoft製品の改善へ反映されると説明しています。(Microsoft)
そのため、今回の発表は「新機能を導入するための更新」ではなく、「Microsoftのクラウドがどのような考え方で強化されていくのかを示す更新」と捉えるのが適切です。
何が変わるのか：コードスキャンからサービス全体の検証へ
従来の脆弱性検査では、ソースコード、クラウド設定、ID権限、ネットワークなどを別々に確認する方法が一般的です。しかし、実際の侵害は一つの重大なバグだけで起きるとは限りません。
例えば、次の三つが同時に存在するケースを考えてみます。
- サービス間の信頼設定が必要以上に広い
- アクセストークンの権限範囲が業務上の必要量を超えている
- 本来は内部用のAPIが隣接するネットワークから到達できる
個別に見ると、緊急対応が必要な問題に見えないことがあります。しかし、攻撃者が三つを組み合わせれば、認証情報の悪用や別サービスへの横移動につながる可能性があります。
今回のAIシステムは、このような複数領域にまたがる攻撃経路を見つけることを重視しています。コードの問題だけでなく、構成、ID、ネットワーク、実行時の状態を一つのサービスとして評価する点が大きな特徴です。(Microsoft)
マルチエージェントAIがサービスを段階的に評価する
Microsoftが説明する評価処理は、概ね次の流れです。
- サービスの構成要素、データフロー、信頼境界、外部公開範囲を把握する
- SFIの要件から、そのサービスに適用すべきセキュリティ統制を選ぶ
- コード、設定、クラウドリソースを調査し、統制が実装されているか確認する
- 単一の対策だけでなく、多層防御が成立しているか評価する
- 欠落、設定ミス、壊れやすい統制を特定する
- 当面のリスクを下げる補完的統制と、恒久対策を提案する
- セキュリティ担当者やサービスチームのフィードバックを取り込み、評価方法を改善する
単に問題を列挙するだけでなく、「実際に悪用できるのか」「別の統制で防げるのか」「恒久的に何を直すべきか」まで判断材料を出す設計です。(Microsoft)
Assurance Treeで必要な統制をサービスごとに定義する
評価の中心となるのが、Microsoftが「Assurance Tree」と呼ぶ階層型の統制マップです。
最上位には、Secure Future Initiative（SFI）の主要領域が置かれます。
- IDとシークレットの保護
- テナントの保護とシステム分離
- ネットワークの保護
- エンジニアリングシステムの保護
- 脅威の監視と検出
- 対応と修復の迅速化
そこから、対象サービスの構成に応じて統制を細分化します。例えばID領域であれば、多要素認証の適用だけでなく、OAuthトークンの扱い、JWTの発行者や有効期限の検証、アプリケーション権限の範囲まで掘り下げます。
固定されたチェックリストを全サービスへ一律適用するのではなく、サービス固有の構成、用途、リスクに合わせて確認項目を作ることがポイントです。(Microsoft)
数週間のレビューを数時間へ短縮したとMicrosoftは説明
Microsoftによると、従来は複数分野の専門家が数週間かけていた複雑なサービスのセキュリティレビューを、今回のシステムでは数時間に短縮できるとしています。
また、システムが提示した検出結果のうち、90％を超える項目がセキュリティエンジニアによって実際の問題と確認されたと報告されています。(Microsoft)
ただし、この90％は「すべての脆弱性の90％を発見できた」という意味ではありません。AIが提示した項目の確認精度を示す数値であり、未検出の問題を含めた網羅率ではない点に注意が必要です。
検出後の確認や修正も完全自動ではありません。Microsoftのセキュリティチームが内容を検証し、各サービスのエンジニアリングチームが対策を実装する運用です。
利用条件：顧客が直接使える機能ではない
今回発表されたクラウド強化システムについて、Microsoftは顧客向けの製品やサービスではないと明記しています。
したがって、次のような作業は不要です。
- Microsoft 365管理センターで機能を有効化する
- Azureサブスクリプションへリソースを追加する
- Microsoft Entra IDでアプリを登録する
- 専用ライセンスをユーザーへ割り当てる
- 自社のソースコードを新しいMicrosoftサービスへアップロードする
利用条件を関連サービスと分けて整理すると、次のようになります。
| 対象 | 提供状況・条件 |
|---|---|
| 今回のSFIクラウド強化システム | Microsoft内部専用。顧客は直接利用できない |
| Secure Nowガイダンス | Microsoft Entra IDを持つ顧客がアクセスできると説明されている |
| 露出評価や対処を支援するMicrosoft Security機能 | Microsoft Security顧客向けとされるが、対象プランや提供時期は記事内で特定されていない |
| SFIのパターンとプラクティス | 一般公開されているガイダンスを参照可能 |
| 各ガイダンスを実装するMicrosoft製品機能 | Microsoft Entra、Defenderなど、利用機能によってライセンスや権限が異なる |
Microsoftは、Microsoft Entra IDを持つ顧客が「Secure Now」のガイダンスへアクセスできると案内しています。ただし、実際に表示される推奨事項や操作可能な範囲は、テナントの契約内容やユーザーの管理ロールによって異なる可能性があります。(Microsoft)
MDASHのプライベートプレビューとは別のシステム
混同しやすいのが、コードネーム「MDASH」です。
MDASHは、複数のAIモデルと専門エージェントを使い、ソースコードから脆弱性を発見、検証、重複排除、実証するためのシステムです。Microsoftは2026年6月30日時点で、MDASHのプライベートプレビュー参加を案内しています。(Microsoft)
一方、今回の「Protecting Microsoft at AI speed」で説明されたシステムは、MDASHなどから得られるコードレベルの情報に加え、ID、ネットワーク、構成、実行時状態を組み合わせて、Microsoftのクラウドサービス全体を評価します。
つまり、次のように役割が異なります。
- MDASH：主にコードの脆弱性発見と検証
- 今回のSFI内部システム：コードを含むサービス全体の統制評価
MDASHのプレビューへ参加できる可能性があることと、今回のSFI内部システムを顧客が利用できることは同じではありません。
データ境界：公開情報から分かる範囲を切り分ける
今回の発表を確認する際は、「セキュリティ上の信頼境界」と「契約上のデータ所在地」を分けて考える必要があります。
SFIが扱う信頼境界とは、例えば本番環境とテスト環境、管理用テナントと顧客用テナント、社内ネットワークと外部ネットワークの間にあるアクセス境界です。
一方、データ所在地やデータ処理地域は、顧客データをどの国・地域で保存・処理するかという契約・コンプライアンス上の問題です。
今回のブログが詳しく説明しているのは前者であり、後者の新しい条件を発表したものではありません。
| 確認項目 | 公開情報から分かること |
|---|---|
| AIシステムの評価対象 | Microsoft内部のコードリポジトリ、インフラ定義、ID設定、実行時設定、ネットワーク構成、稼働中リソース |
| 顧客によるデータ投入 | 顧客向け製品ではないため、新たにコードや業務データをアップロードする利用フローはない |
| 処理リージョン | 記事では説明されていない |
| データ保持期間 | 記事では説明されていない |
| 利用するAIモデル | 特定のモデル名やモデル提供者は説明されていない |
| 学習データへの利用 | 記事では説明されていない |
| 顧客によるオプトアウト | 顧客向けの設定やオプトアウト手段は案内されていない |
| 既存サービスのデータ所在地 | 今回の記事による変更は発表されていない |
「Microsoft内部専用だから、顧客に関連するデータは一切処理されない」とまでは断定できません。AIシステムはMicrosoftの稼働中クラウドリソースも確認するとされている一方、どの種類のデータをどの範囲まで参照するかは公開されていないためです。(Microsoft)
また、このブログ記事は製品条項やデータ処理契約ではありません。データ所在地、国外移転、監査、保持期間などの確認が必要な場合は、利用中のMicrosoft 365、Azure、Microsoft Entraなどのサービス別文書、製品条項、データ保護に関する契約文書、Service Trust Portalの監査資料を確認する必要があります。(servicetrust.microsoft.com)
管理者制御：新しいスイッチはないが、既存設定の見直しは必要
今回の内部システムを制御するための管理画面やポリシーは、顧客向けに提供されていません。
管理者が行うべきことは、AIシステムそのものを管理することではなく、MicrosoftがSFIで重視している統制を自社環境へ適用することです。
Microsoftが公開しているSFIガイダンスを基にすると、優先して確認したい領域は次のとおりです。(Microsoft Learn)
| 領域 | 確認する内容 | 初期対応の例 |
|---|---|---|
| IDとシークレット | 管理者認証、アプリ権限、固定資格情報 | 管理者へフィッシング耐性MFAを適用し、ワークロードはマネージドIDや短期トークンへ移行する |
| テナント分離 | テナント一覧、環境間の共有権限、不要なアプリ | 本番・検証環境を分離し、共有管理者や共有アプリ登録を減らす |
| 特権アクセス | 常時付与された管理者権限 | PIMなどを使い、必要な時間だけ権限を有効化する |
| ネットワーク | 公開エンドポイント、管理経路、サービス間通信 | 不要なパブリックアクセスを閉じ、管理経路と業務通信を分離する |
| 開発基盤 | CI/CD、依存関係、シークレット混入 | 標準パイプラインを用意し、コード、IaC、依存関係、資格情報を継続検査する |
| 監視と対応 | ログ、検知ルール、修正担当者 | 重要ログを集中管理し、検出項目ごとに担当者と修正期限を設定する |
Microsoft Entraの条件付きアクセス、Privileged Identity Management、ID Protection、Microsoft Defender製品などは、契約プランによって利用できる機能が異なります。製品名だけを先に決めるのではなく、まず必要な統制を定義し、その統制を実現できる機能とライセンスを選ぶことが重要です。
最初に作るべきはテナントとアプリの棚卸し
設定変更より先に必要なのは、管理対象の全体像を把握することです。
最低限、次の対象を一覧化します。
- Microsoft Entraテナント
- Azureサブスクリプションと管理グループ
- アプリ登録とサービスプリンシパル
- マネージドID
- 管理者ロールの保有者
- 外部ユーザーとクロステナント接続
- ソースコードリポジトリ
- CI/CDパイプライン
- インターネットへ公開されたエンドポイント
- 長期間使われていないシークレットや証明書
MicrosoftのSFIでは、テナント、ディレクトリ、アプリ、サービスプリンシパル、クラウドリソースを完全に把握することが、分離と統制の前提とされています。(Microsoft Learn)
棚卸しできていない資産は、MFAや条件付きアクセス、ログ監視、脆弱性対応の対象から漏れやすくなります。まず「何を守るのか」を明確にしてから、設定を強化する必要があります。
業務や開発での使いどころ
顧客が今回のAIシステムを直接利用することはできませんが、そこで採用されている評価方法は、セキュリティ設計や開発プロセスへ取り入れられます。
| 担当者・部門 | 活用場面 | 作成する成果物 |
|---|---|---|
| CISO・IT統制部門 | 重要サービスの統制状況を比較する | Assurance Tree、統制一覧、改善計画 |
| クラウドアーキテクト | 新規システムの設計審査 | データフロー図、信頼境界、攻撃経路 |
| DevSecOps担当 | リリース前のセキュリティゲート | コード・構成・ID・ネットワークの検査結果 |
| 開発チーム | アプリ間認証やAPI権限の確認 | 必要最小限の権限表、トークンスコープ |
| 内部監査・リスク管理 | 統制の実装証拠を確認する | 設定証跡、例外記録、補完的統制 |
| M&A・グループIT | 取得企業や子会社のテナント統合 | テナント台帳、分離方針、廃止計画 |
| AIエージェント開発者 | エージェント間通信とツール利用を設計する | 委任権限、操作範囲、停止・失効手順 |
DevSecOpsでは検査結果を一つにまとめる
よくある失敗は、各ツールの結果を別々の担当者が管理し、問題の組み合わせを確認しないことです。
例えば、次の検査がすべて個別に合格していても、安全とは限りません。
- 静的コード解析
- 依存ライブラリの脆弱性検査
- Infrastructure as Codeの設定検査
- Microsoft Entraのアプリ権限レビュー
- ネットワーク公開範囲の確認
- 実行時のログ監視
重要なのは、それぞれの結果をサービス単位で関連付けることです。
「権限が広いアプリが、どのネットワークから到達でき、どのデータへアクセスできるか」「認証情報が盗まれた場合に、別のテナントや環境へ移動できるか」といった攻撃経路を確認します。
AIエージェント開発ではエージェント間の信頼を明示する
Microsoftは、サービス固有の構成として、エージェント間通信を利用するアーキテクチャも評価対象に挙げています。(Microsoft)
AIエージェントを業務システムへ組み込む場合は、次の点を明示する必要があります。
- エージェントが利用できるツール
- 読み取りと更新が可能なデータ
- 他のエージェントへ委任できる権限
- ユーザー本人の権限を引き継ぐ範囲
- 長時間有効なトークンの有無
- 操作ログを記録する場所
- 異常時に権限を失効させる方法
- 人による承認が必要な操作
「エージェントが便利に動ける権限」ではなく、「業務を完了するために必要な最小権限」を基準に設計します。
自社で小さなAssurance Treeを作る手順
Microsoftと同じ規模のAIシステムを構築しなくても、Assurance Treeの考え方は表計算やチケット管理ツールで実践できます。
対象サービスを一つに絞る
最初から全社システムを対象にすると、棚卸しだけで作業が止まります。
個人情報、決済情報、機密文書などを扱うサービスや、インターネットへ公開されているサービスを一つ選びます。
構成と信頼境界を図にする
次の要素を図へ配置します。
- ユーザー
- フロントエンド
- API
- データベース
- 外部サービス
- Microsoft Entra ID
- 管理端末
- CI/CD
- ログ基盤
通信方向、認証方式、利用するID、保存データ、管理者経路も記載します。
必要な統制を領域別に定義する
例えばAPIサービスであれば、次のように分解できます。
ID
- 管理者にフィッシング耐性MFAが適用されている
- ワークロードが固定シークレットを使用していない
- トークンの発行者、有効期限、対象受信者を検証している
テナント
- 本番環境と検証環境で管理者アカウントを共有していない
- 不要なクロステナントアクセスがない
- 使われていないアプリ登録が残っていない
ネットワーク
- 公開が必要なエンドポイントだけインターネットへ公開している
- 管理用通信と業務通信を分離している
- サービス間通信の送信元と宛先を限定している
開発基盤
- 承認済みのパイプラインからのみ本番へ展開できる
- シークレットと依存関係を自動検査している
- リリース成果物とソースコードの対応を追跡できる
監視と対応
- 認証失敗、権限変更、重要データへのアクセスを記録している
- アラートの対応担当者が決まっている
- 資格情報の失効や公開停止を短時間で実行できる
設定ではなく証拠を確認する
「MFAを使う方針になっている」だけでは不十分です。
実際の適用対象、除外ユーザー、ポリシー変更履歴、テスト結果などを確認します。コードレビューについても、ルールが存在するかではなく、保護ブランチや承認履歴が残っているかを見ます。
問題の組み合わせを検討する
各統制の合否を確認した後、複数の不備を組み合わせます。
例えば、次の組み合わせは単独の設定ミスより優先度が高くなります。
- 広すぎるアプリ権限
- 長期間更新されていないシークレット
- インターネットから到達できるAPI
- トークン利用の監視不足
攻撃者がどの順番で悪用できるかを文章で書くと、単純なチェックリストより修正優先度を判断しやすくなります。
補完的統制と恒久対策を分ける
すぐにコードを修正できない場合は、当面の対策を設定します。
例えばAPIの改修に時間がかかるなら、ネットワークで接続元を限定し、アプリ権限を縮小し、監視ルールを追加します。ただし、補完的統制を設定しただけで対応完了にしてはいけません。
チケットには次の項目を記録します。
- 暫定対策
- 恒久対策
- 担当者
- 期限
- 再検証日
- 受容する残存リスク
対応要否を判断する基準
今回の発表に対する対応は、Microsoftサービスの利用形態によって異なります。
| 利用状況 | 対応要否 | 推奨対応 |
|---|---|---|
| Microsoft 365を一般的な設定で利用している | 直接的な機能対応は不要 | 管理者MFA、不要アカウント、アプリ権限を確認する |
| Azureで独自アプリやAPIを運用している | 対応を推奨 | コード、ID、ネットワーク、実行時設定を横断レビューする |
| 複数のEntraテナントを管理している | 優先度が高い | テナント、アプリ、サービスプリンシパルを棚卸しする |
| 本番と検証でIDやアプリ登録を共有している | 早急な確認が必要 | 環境を分離し、共有資格情報を廃止する |
| AIエージェントや自動化基盤を開発している | 優先度が高い | トークンスコープ、ツール権限、エージェント間通信を確認する |
| データ所在地に厳しい要件がある | 別途確認が必要 | ブログではなく契約文書とサービス別資料で確認する |
| 新しいMicrosoft製品として購入を検討している | 現時点では購入対象ではない | 顧客向け正式発表を待ち、MDASHなど別サービスと区別する |
変更管理上は、今回の発表を「テナント設定変更なし、情報収集と既存統制の確認が必要」と分類すると整理しやすくなります。
誤解しやすいポイントと注意点
Microsoft Security Copilotの新機能ではない
今回の発表は、Microsoft Security Copilotへ追加されるプロンプト機能やエージェント機能の案内ではありません。顧客がSecurity Copilotの画面から今回の内部システムを実行できるわけではありません。
90％超は脆弱性の検出率ではない
90％を超える検出結果が実際の問題と確認されたという説明は、検出結果の品質に関するものです。
すべての脆弱性をどの程度発見できたかを示す再現率や網羅率とは異なります。
AIが自動的に修正を完了するわけではない
AIは検出と推奨事項の作成を支援しますが、Microsoftのセキュリティエンジニアが内容を確認し、サービスチームが修正を実装します。
自社へ考え方を取り入れる場合も、人による承認、例外判断、再テストを省略してはいけません。
「継続評価」をリアルタイム監視と断定しない
Microsoftは継続的な評価と改善を説明していますが、各サービスを評価する頻度、実行間隔、対応時間の保証は公開していません。
「すべてのMicrosoftクラウドが常時リアルタイムでAI監査されている」とは断定しない方が安全です。
ブログ記事をコンプライアンス証拠にしない
今回の記事は、Microsoftのセキュリティ設計や運用方針を理解する資料としては有用です。
一方、データ所在地、処理目的、保持期間、監査範囲、契約上の保証を証明する文書ではありません。監査対応では、契約文書やService Trust Portalの正式資料を使用します。
まず一つの重要サービスをシステム全体で点検する
「Protecting Microsoft at AI speed」で発表された内容は、顧客が導入する新製品ではありません。Microsoft側の内部的なクラウド強化であり、利用者が今すぐ変更する設定や追加ライセンスはありません。
一方、発表が示した「コードだけでなく、ID、テナント、ネットワーク、実行時状態を組み合わせて評価する」という考え方は、自社のクラウド運用にも直接活用できます。
最初に行うべきことは次の三つです。
- 今回の更新を、設定変更のない情報更新として管理台帳へ記録する
- 自社の重要サービスを一つ選び、構成、データフロー、信頼境界を図にする
- 管理者権限、アプリ権限、固定シークレット、クロステナント接続、公開エンドポイントを横断的に確認する
単体の脆弱性を探すだけでなく、複数の弱点が連鎖したときに何が起きるかを確認することが、今回の発表から取り入れるべき最も重要な実務ポイントです。
コメント