Microsoftのセキュリティ変革、リリース速度より説明責任を優先

繰り返される侵害によって、リリース速度と十分な保護の間にある対立が明らかになってから、Microsoftは約3年をかけてセキュリティ変革を測定可能なものにしてきた。現在では、セキュリティが従業員評価、役員報酬、製品設計の承認、エンジニアリングパイプライン、顧客向けのデフォルト設定にまで影響を及ぼしている。

同社はこのプログラムをSecure Future Initiative、略してSFIと呼ぶ。Microsoftは2023年11月にこれを開始し、連邦政府のレビューでセキュリティ文化が厳しく批判された後に拡大した。問われているのは、Microsoftがさらに多くのセキュリティ上の約束を発表できるかではない。既知のリスクや老朽化したシステムの放置をこれまで許してきたインセンティブを変えたのかどうかだ。

この違いは、MicrosoftがAI事業を加速させる中で重要になる。AIは脆弱性の発見、検知ルールの作成、システム横断でのリスクの関連付けに役立つ。一方で、開発速度を高め、挙動の予測が難しいソフトウェアを導入する可能性もある。そのためMicrosoftは、一つの決定的な課題に直面している。製品チームが新たなAI機能のリリースを急ぐ場面でも、保証プロセスが権限を保ち続けなければならない。

Microsoftのセキュリティ変革、すべての人事評価に及ぶ

Microsoftは、セキュリティを専門家に委ねられる責務ではなく、キャリアで成功するための条件にしようとしている。

Cybersecurity Diveが公開したインタビューによると、Microsoftのすべての人事評価には、従業員が会社と顧客のセキュリティにどのように貢献したかについての議論が含まれる。この要件は、エンジニアリング、マーケティング、営業、インシデント対応にわたって適用される。

この変更により、SFIは単なる社内啓発キャンペーン以上の重みを持つことになった。昇進、報酬、キャリアの進展は、大規模組織全体の行動を形作る。製品が予定通りに提供されていても、セキュリティ上の懸念を無視した従業員には、今や個人的な結果が伴う。

Microsoftは以前、機能完成を重視するエンジニアリングワークフローの中に、多くのセキュリティ判断を置いていた。開発者は自動チェックを実行し、リリース直前にセキュリティチームへ相談して、最終承認を求めることができた。このプロセスでは、セキュリティは設計上の制約ではなく、後段のチェックポイントとして扱われていた。

MicrosoftのWindows Security担当コーポレートバイスプレジデントであるDana Huangは、従来のアプローチを、リリース直前にチェックボックスを得ようとするものだと説明した。現在、同氏のチームは選定された重要領域でより早期から関与している。製品チームが製品の仕組みをまだ検討している段階から、セキュリティエンジニアが参加できる。

この実践は一般に「シフトレフト」と呼ばれる。この用語は、チームが完成品を作り直すことなくアーキテクチャを変更できる、ソフトウェア開発の初期段階へセキュリティレビューを前倒しすることを意味する。

早期の関与は、議論される問いも変える。最終段階のスキャナーは特定のコーディングミスを検出できるが、安全でない製品上の前提まで常に問えるわけではない。設計段階から参加するセキュリティ専門家は、信頼境界、アイデンティティ要件、データフロー、復旧メカニズム、悪用シナリオを検討できる。

MicrosoftはCybersecurity Governance Councilも設置した。副最高情報セキュリティ責任者がWindows、Azure、Microsoft 365を含む主要事業を代表し、それらの組織をまたいで優先順位とセキュリティ上のトレードオフを定期的に検討する。

この協議会は、提供目標と未解決のリスクが衝突した際のエスカレーション経路を確立する。Microsoftによると、CEOのSatya Nadellaはリーダーたちに対し、何よりもセキュリティを優先するよう指示している。SFIディレクターのHammad RajjoubはCybersecurity Diveに対し、チームは一つの項目を延期して別の問題を修正することを日常的に議論していると語った。

このガバナンス構造が重要なのは、Microsoftの製品がアイデンティティ、インフラ、開発ツール、依存関係を共有しているためだ。一つのサービス内の弱点が、他の場所での露出につながる可能性がある。事業レベルのセキュリティリーダーは、孤立した製品チームよりも、こうしたつながりを効果的に特定できる。

同社は、セキュリティ推進に対する従業員の意識が平均88%であると報告している。この数値はMicrosoftの2026年7月のSFIレポートに基づくものであり、独立監査ではなく社内測定を示す。それでも、このプログラムが従業員の間で一様な抵抗を生んでいるわけではないことを示唆している。

意識はシステムが安全かどうかを測るものではない。従業員がこの変革を有用で実行可能だと考えているかを測るものだ。セキュリティプログラムは、従業員が統制を障害と見なし、非公式な回避策を見つけると弱体化しがちなため、これは重要である。

Microsoftは、説明責任、ガバナンス、従業員の受容が相互に強化し合うと見込んでいる。評価は個人のインセンティブを生み、副CISOは監督を担い、経営陣の指示はセキュリティチームがリリースに異議を唱える際の権限を与える。

この組み合わせが、組織面での中心的な変化を表している。Microsoftはもはや、セキュリティを製品開発の隣で機能する専門部署として提示していない。セキュリティに関する判断を、すべての従業員が通常業務をどのように遂行しているかを示す証拠として扱っている。

相次ぐ侵害により文化変革は不可避となった

Microsoftの新たな統制は、単なるセキュリティツールの不足ではなく、文化、判断、透明性における記録された失敗への対応である。

SFIは、複数の深刻な侵入事案を受けて導入された。サイバー犯罪グループLAPSUS$は2022年にMicrosoftを侵害した。2023年には、別個のロシアおよび中国の活動がMicrosoftのシステムと機密情報にアクセスした。

Storm-0558として追跡される中国国家関連グループは、Microsoftの署名キーを入手し、Exchange Onlineのアカウントにアクセスした。影響を受けた対象には、中国との関係に関わる米国政府の高官や機関が含まれていた。

連邦Cyber Safety Review Boardはこのインシデントを調査し、回避可能だったと結論付けた。同委員会のExchange Online reviewは、回避可能なエラーの連鎖を記述し、Microsoftのセキュリティ文化を不十分だとした。

同委員会は、キー管理、ログ記録、検知、インシデント対応、対外コミュニケーションに関わる弱点を特定した。また、Microsoftが後に不正確と判明したインシデントに関する説明を行ったことも批判した。

これらの調査結果により、問題の重大性は従来のソフトウェア脆弱性を超えるものとなった。Microsoftは、政府や大企業に対して、オペレーティングシステム、クラウドインフラ、生産性アプリケーション、アイデンティティサービス、セキュリティ製品を提供している。顧客は多くの場合、これらのサービスを複数同時に利用している。

この集中は、Microsoftに例外的な可視性とリソースをもたらす。同時に、相関リスクも生む。共有のアイデンティティまたはクラウドコンポーネントに関わるセキュリティ障害は、異なるアプリケーションに露出を分散していると考えていた組織にも影響を与え得る。

そのためレビュー委員会は、Microsoftの経営上層部と取締役会に対して、迅速な文化変革を主導するよう求めた。また、製品ポートフォリオ全体での具体的なスケジュールと改革を盛り込んだ計画の公表を推奨した。

Microsoftは2024年5月にSFIを拡大し、委員会の勧告を実施すると約束した。同社は、アイデンティティ、テナント、ネットワーク、開発システム、脅威検知、脆弱性修復を軸にエンジニアリング作業を編成した。

また、経営上層部の報酬の一部をセキュリティ成果と連動させた。この決定は、基本的なガバナンス上の問題を認識したものだった。成長とリリース成果を主な尺度としてリーダーを評価しながら、経営陣がセキュリティを最優先事項だと説得力を持って述べることはできない。

Microsoftのセキュリティ変革は現在、その不均衡を是正しようとしている。機能追加とセキュリティ修復のどちらを選ぶかを判断するマネージャーは、正式なセキュリティ目標、従業員評価、ガバナンスレビュー、役員報酬を考慮しなければならない。

外部の観察者も、この変化を慎重に評価している。FuturumのFernando MontenegroはCybersecurity Diveに対し、SFIは成果を生み始めているようだと語った。ForresterのアナリストであるMerritt MaximとAllie Mellenも、この改革を価値あるものと表現した。

ただし、その支持には条件がある。Mellenは、これらの変化が組織に定着し、時間とともに改善されなければならないと述べた。Maximは、AIをめぐる緊急性が世間の注目が薄れた後にセキュリティ規律を静かに弱める可能性があると警告した。

この警告は、真の圧力がかかる対象を示している。Microsoftのセキュリティ組織が主に競っているのは、他社ベンダーのプログラムではない。特にAI分野における、より迅速な製品開発を求めるMicrosoft自身の意欲である。

同社はすでに、この対立を公の場で経験している。Copilot+ PCs向けのRecall機能は、ユーザーが過去の情報を取得できるよう活動を記録する設計だった。研究者らがこれらの記録の保存と保護について懸念を示したため、Microsoftはこの体験の提供を延期し、再設計した。

Recallは、AI関連機能がプライバシー、アイデンティティ、ストレージ、アクセスのリスクをいかに迅速に組み合わせ得るかを示した。また、製品がパブリックプレビューに到達する前からセキュリティレビューを始める必要がある理由も示した。

Microsoftの過去の失敗により、あらゆる新しい指標は暫定的なものとなる。顧客が必要としているのは、統制がレガシーサービスと新製品の全体で一貫して機能している証拠だ。また、その統制が失敗した際には速やかな開示も必要としている。

SFIは、誰がセキュリティを議論し、いつその議論が行われるかを変えた。侵害事案が説明するのは、こうした対話が異なるエンジニアリング上の判断につながることを、Microsoftが今後証明しなければならない理由である。

監督体制は少数の専門家を超えて拡張されなければならない

新たなガバナンスモデルが成功するのは、小規模なセキュリティチームが自らすべての行をレビューすることなく、数千件のエンジニアリング上の判断を変えられる場合に限られる。

Windowsは、この拡張性の課題をよく示している。HuangはCybersecurity Diveに対し、この部門には約7,000人の従業員がおり、そのうち約5,000人がエンジニアだと語った。同氏のWindowsセキュリティエンジニアリングチームは、およそ12人で構成される。

12人の専門家では、5,000人のエンジニアが生み出すすべてを手作業で検査することはできない。このモデルを試みれば遅延が生じる一方で、製品チームはセキュリティを他人の仕事として扱うようになるだろう。

Montenegroはその代わりに、セキュリティチームが開発チームに継承される標準、ツール、安全なデフォルトを構築すべきだと主張した。このモデルでは、小規模グループの専門性がすべてのエンジニアが使うシステムを通じて広がる。

安全なデフォルトとは、ユーザーや開発者が保護機能を有効化しなくても、より安全な挙動を提供する設定のことだ。デプロイ時に完全な判断を下せることへの依存を減らす。

Microsoftはこの原則を社内の開発パイプラインに適用している。2026年7月のSFI progress reportによると、エンジニアリングのデフォルト設定により、パイプラインの83%が未承認のパッケージエンドポイントへアクセスすることを阻止している。

この統制は、ソフトウェアサプライチェーンのリスクに対応する。侵害された外部パッケージや誤って選択された外部パッケージは、信頼された製品に悪意あるコードを持ち込む可能性がある。パッケージの取得元を制限することで、この失敗が生じる機会を減らせる。

同じレポートによると、フィッシング耐性のある多要素認証は、Microsoftのユーザーとデバイスのペアの99.97%を保護している。フィッシング耐性認証は、攻撃者が不正なサイトで認証情報を再利用することを防ぐよう設計された方式を使用する。

Microsoftはまた、73万2,000件を超えるリソースの公開アクセスを取り消したと述べている。ネットワーク分離は100万件のリソースに拡大され、同社は使用されていない140万件のアプリケーションを廃止した。

未使用のアプリケーションや公開されたリソースは、攻撃者が標的にできるシステム群である攻撃対象領域を拡大させる。これらを削除することで、盗まれた認証情報、忘れ去られた権限、脆弱なサービスが侵入口となる機会を減らせる。

Microsoftによると、境界をまたぐ認証情報の分離は98.7%に達した。この制御は、ある環境または信頼ゾーンの認証情報が別の環境で悪用可能になることを防ぐことを目的としている。

こうした測定値は、文化を改善するという一般的な約束よりも多くを示す。特定の制御対象集団を特定し、Microsoftが保護をどの程度広範に導入したとしているかを示している。

ただし、この割合は未完了の作業も浮き彫りにする。非常に大規模な環境に99%適用された制御でも、無視できないリスクが残る可能性がある。攻撃者は例外を探す。見落とされた1つのIDやレガシーシステムが足がかりになり得るためだ。

これらの指標だけでは、Microsoftが適切な分母を選択しているかを独立して立証できない。また、制御がどの程度の頻度で失敗するか、例外がどれほど迅速に解消されるか、敵対者がどれほど効果的に回避するかも示していない。

したがって、独立した検証は依然として不可欠だ。顧客は、インシデント頻度、悪用可能性、開示の質、是正の速度を注視すべきである。こうした結果によって、内部のカバレッジ統計が外部リスクの低下につながっているかが分かる。

Microsoftは、脆弱性が発見される段階も測定できる。リリース前により深刻な欠陥を多く見つけられるなら、シフトレフト戦略を裏付けることになる。一方、本番環境で繰り返し発見されるなら、設計レビューと自動ゲートがなお不十分であることを示唆する。

平均是正時間も有用な指標となる。これは、確認済みの問題をチームが封じ込めまたは修復するまでに要する時間を追跡する。平均値だけでは深刻な外れ値が隠れるため、Microsoftは最高リスク案件における実績も開示すべきである。

大規模な監督には最終的に、製品チーム自身がリスクを担うことが必要となる。セキュリティ専門家はアーキテクチャを定義し、ゲートを維持し、例外的な案件をレビューできる。しかし、Windows、Azure、Microsoft 365を構築するすべてのエンジニアの判断を置き換えることはできない。

人事評価に関する要件は、このモデルを支える。中央のセキュリティ制御を利用することが開発者の業務の一部であると伝えるものだ。また、これらの制御を迂回することは、精査の対象となるリーダーシップ上の意思決定であることも管理者に伝える。

ここで説明責任とエンジニアリングが交わる。文化的変革は、チームに標準を採用する理由を与える。技術的なデフォルトは、大規模な組織全体でより安全な判断を繰り返しやすくする。

AIスキャンが成熟したコードレビューで見落とされたリスクを発見

MicrosoftはAIを使ってセキュリティのカバレッジを広げているが、この技術は専門家によるレビューの代替ではなく、その効果を増幅する役割を果たす。

Microsoftは、脆弱性を調査するマルチモデルのエージェント型スキャナー、MDASHを導入した。エージェント型システムは、単発のモデル応答を生成するのではなく、相互に関連する複数の分析ステップを計画・実行できる。

Microsoftによると、MDASHはTCP/IPネットワークスタックを含むWindowsコンポーネントで、重大なリモートコード実行の脆弱性を発見した。リモートコード実行では、脆弱な条件下で攻撃者が別のシステム上のソフトウェアを実行できる。

この発見は、成熟したエンジニアリング組織で一般的な前提に疑問を投げかけた。開発者は、関連するコードについて、チームが長年にわたって監査・運用してきたため安定していると考えていた。

Microsoftのセキュリティ研究担当バイスプレジデントであるTaesoo Kim氏は、開発者は当初、この発見を疑っていたと述べた。Microsoftによると、その後同社は調査を行い、脆弱性に対処した。

MDASHは、Microsoftが開発中のコードだけでなく、リリースが近いソフトウェアもスキャンする。Rajjoub氏によると、強制メカニズムにより、コードが求められるセキュリティ基準を満たすまで出荷を阻止できる。

Microsoftはこのスキャナーを、LinuxカーネルやFFmpegを含むオープンソースの依存関係にも適用している。これらのプロジェクトは広範な公開レビューを受けているが、その規模と複雑性ゆえに、微妙な欠陥が残る余地は依然としてある。

同社はこのスキャン技術を顧客向けにも提供し始めた。この商業的展開は追加の試金石を生む。Microsoftは、MDASHが自社環境を超えるコードベースでも有用な発見をもたらすことを示さなければならない。

7月の報告書では、より広範なマルチエージェント評価システムについて説明している。Microsoftによると、このシステムはソースコード、ID設定、ネットワークトポロジー、実行時の状態を分析し、複合脆弱性を特定する。

複合脆弱性は、それぞれ単独では軽微な複数の弱点が、危険な攻撃経路を形成したときに生じる。寛容なID設定、到達可能なネットワークエンドポイント、コーディング上のミスは、組み合わせて調べた場合にのみ重大な問題となる可能性がある。

従来のスキャナーは、多くの場合、一度に1つの層を分析する。アーキテクチャと実行時コンテキストを結び付けることで、攻撃者が現実的に組み合わせられる発見事項の優先順位付けを支援できる。

Microsoftによると、同社のセキュリティエンジニアはシステムの発見事項の90%以上を確認した。これは有望な社内結果だが、独立して再現できるほどの公開情報は同社から提供されていない。

この数字を普遍的な精度率と解釈すべきではない。結果は、テストしたサービス、確認の定義、計算に含めた発見事項に左右される。

AI支援スキャンは、新たな運用上の課題も生む。より多くの脆弱性を発見しても、チームが検証し修正できる場合にのみ価値が生まれる。急速に拡大するキューはエンジニアを圧倒したり、表面的な是正を促したりする可能性がある。

誤検知は、専門家が調査しなければならないため、依然としてコストが高い。見逃しは、チームがスキャンによって安全でないコードが問題なしと判断されたと考える可能性があるため、より危険である。

したがって、人によるレビューは依然として中心的な役割を担う。セキュリティエンジニアは、悪用可能性を検証し、アーキテクチャへの影響を理解し、修正によって別の問題が生じないかを判断しなければならない。AIは、最終的なリスク判断を担うことなく、彼らの探索能力を拡張できる。

Microsoftによると、2026年中に100件以上の検知を追加し、総数は350件を超えた。同社はシグネチャベースの検知から、振る舞いとベースラインの分析へ移行している。

シグネチャ検知は、既知の悪意あるパターンを探す。振る舞いベースの検知は、想定される運用と異なる不審な活動を探すため、未知の攻撃の発見に役立つ可能性がある。

Microsoftのセキュリティ変革では、開発ライフサイクルの両側でAIを活用している。モデルはリリース前にコードを調査し、検知機能は導入後にシステムを監視する。そこから得られるシグナルにどう対応するかは、人間が判断する。

この構成は実務的なトレードオフを反映している。手動レビューだけではMicrosoftのコード量に追いつけない。AIだけでは、説明責任、文脈に基づく判断、信頼できる保証を提供できない。

MDASHの最も強い証拠となるのは、生成する発見件数ではない。顧客が遭遇する前にMicrosoftが除去できる重大な脆弱性の割合である。

セキュアなデフォルト設定が顧客に一部の負担を移す

より安全なデフォルト設定は防止可能な露出を減らすが、既存のワークフローを妨げ、実装作業をMicrosoftの顧客に移転する可能性がある。

Microsoftは、顧客が従来は選択して省略できた保護機能を必須化している。Azureは2024年10月から段階的に多要素認証を必須化し始めた。

多要素認証では、アクセスを許可する前に複数の形式の証拠を求める。認証方法によって保護の程度は異なるものの、盗まれたパスワードの価値を下げる。

MicrosoftがAzureの展開を段階化したのは、即時の義務化が顧客のワークフローを壊す可能性があったためだ。新規アカウントに先に要件を適用し、既存環境には移行期間を与えた。

この判断は、セキュリティと速度の対立における第2の層を明らかにする。Microsoftは、安全でない設定を取り除くために、ときに顧客に不便を強いる必要がある。要件を遅らせれば継続性は保てるが、脆弱な慣行が残り得る期間も延びる。

同社は一部のリスクの高い機能をデフォルトで無効化している。顧客は、特定のニーズと適切なガードレールがある場合に、選択した機能を有効化できる。

このアプローチは、長年続いてきたソフトウェアの慣行を逆転させる。ベンダーは多くの場合、製品を完全で導入しやすく見せるために機能を有効化する。稼働中のサービス、プロトコル、統合が増えるごとに、保護を要する経路も増え得る。

セキュア・バイ・デフォルトの製品は、管理者が選択を行う前にその露出を減らす。また、すべての技術設定を評価できる専門家を欠く小規模組織にも役立つ。

ただし、デフォルト設定が顧客の責任をなくすわけではない。組織は、例外、過剰な権限、管理されていないデバイス、不十分な復旧手順を通じて保護を弱める可能性がある。

Microsoftがエンタープライズ技術で大きな存在感を持つため、これらのデフォルト設定の設計は特に重要な意味を持つ。より安全なAzureまたはMicrosoft 365の設定は、多数の組織のリスクを一度に下げられる。欠陥のある設定も同様に広範な露出を広げ得る。

顧客は、新しいデフォルト設定が新規導入だけでなく既存テナントにも適用されるかを確認すべきである。また、免除に期限があるか、管理者が逸脱を中央で特定できるかも検討すべきだ。

Microsoftが制御を変更する際には透明性が重要となる。管理者には、自動化を更新し、依存関係をテストし、運用上の影響を説明するために十分な通知が必要だ。コミュニケーションが不十分だと、健全なセキュリティ要件が可用性インシデントに転じる可能性がある。

Microsoftによると、同社のCustomer Security Management Officeは現在、定義済みのプレイブックを用いて重大インシデント時のコミュニケーションを調整している。更新されたSFI資料では、業界標準を通じたクラウド脆弱性の公開についても説明している。

同社のSFI拡張では、より迅速な緩和策と、より明確な公開メッセージを約束した。これらの約束は、Storm-0558侵入後の批判に直接対応するものである。

しかし、開示は依然として社内で評価するのが最も難しい結果の一つである。企業は、インシデントをいつ発表するか、影響範囲をどのように説明するか、どの技術的詳細を公表するかを管理できる。

Cyber Safety Review Boardは、重要な説明が調査の過程で変化したとして、Microsoftの以前の公開声明を批判した。この経緯により、今後のインシデントコミュニケーションにはより高い基準が求められる。

したがって、顧客は予防指標と信頼指標を区別すべきである。認証のカバレッジとリソース分離は導入済みの制御を測定する。迅速、正確、かつ完全な開示は、それらの制御が失敗した後にMicrosoftがどう行動するかを測定する。

重大な脆弱性が継続して発見されていることも、勝利宣言を妨げる。Cybersecurity Diveは、2026年9月の記事までの5カ月間に、少なくとも5件の重大なSharePoint脆弱性が開示されたと報じた。

頻繁な開示は、研究者や内部ツールが問題をより効果的に発見していることを意味する可能性がある。一方で、エンジニアリング上の弱点が続いていることを示す可能性もある。どちらの解釈がより妥当かは、文脈、悪用状況、影響を受ける構成、是正までの時間によって決まる。

Microsoftの規模を考えれば、脆弱性報告が続くことは避けられない。信頼できる変革は、欠陥の完全な排除を約束できない。重要なのは、深刻な失敗がより防ぎにくく、より大きな被害をもたらし、より不透明に扱われるものにならないかである。

セキュアなデフォルト設定は、日常的なミスの影響を抑える助けになる。しかし、規律ある設計、正確な資産インベントリ、統制されたID、有効なインシデント対応を置き換えることはできない。

エンタープライズの購入担当者にとって実務的な問いは、Microsoftの統制が隠れた依存関係を生まずに、全体的なリスク曝露を低減できるかどうかだ。その答えは、レガシーシステム、クラウドサービス、規制の厳しい環境によって異なる。

次に必要なのは成果による証明だ

Microsoftのセキュリティ変革の次の段階では、より多くの社内進捗率ではなく、独立して観測可能な成果が求められる。

最初に注目すべき指標は、リリース前の発見能力だ。Microsoftは、AIスキャンと初期設計レビューによって、製品が顧客に届く前に重大な脆弱性を発見する割合が高まっていることを示すべきである。

この測定は、MDASHとシフトレフト型の監督を直接的なエンジニアリング成果へと結び付けるものになる。低下すれば、新たなツールやガバナンスがより早い段階で障害を防ぐというMicrosoftの主張は弱まる。

2つ目の指標は、深刻度の高いクラウド脆弱性に対する修復パフォーマンスだ。Microsoftの現在の資料では、積極的に悪用されていたクライアント側の問題1件を1日未満で対処した事例を含め、緩和の迅速化が説明されている。

ただし、1件の事例だけで一貫した運用基準が確立されたとは言えない。購入者には、分布、深刻度区分、例外件数が必要だ。修復時間が持続的に短縮されれば、説明責任の変化が実行面にも及んでいるという主張を裏付けるだろう。

3つ目の指標は、Microsoftが次の重大インシデントをどう扱うかだ。同社は迅速に検知し、影響を受けたシステムを正確に特定し、顧客へ速やかに通知し、繰り返し訂正することなく根本原因を説明しなければならない。

社内の意識スコアは、この試験の代わりにはならない。明確な対応は、Microsoftのガバナンス改革に対する信頼を強める。一方、回避可能な侵害が再び発生し、その後の説明も不完全であれば、このプログラムが掲げる中核的な約束は損なわれる。

AIは、この3つの指標すべてに圧力をかける。AIはMicrosoftがより多くのコードを調査し、より多くのテレメトリーを相関分析する助けとなる。一方で、製品チームの開発速度を高め、攻撃者には弱点を発見・組み合わせるためのツールを与える。

Forresterの警告はここで重視すべきだ。AIをめぐる緊急性は、特に競争上の期限が再び重視され、世間の注目が別の場所へ移るとき、セキュリティ規律を静かに損なうおそれがある。

Microsoftのセキュリティ評議会と評価インセンティブは、このサイクルに抵抗するために設計されている。その有効性は、セキュリティリーダーが異議を唱えたことで、上級製品チームがリリース延期、再設計、あるいは機能範囲の縮小を受け入れる場面で明らかになる。

顧客が社内のあらゆる意思決定を見ることはほとんどない。それでも、リリースノート、インシデント報告、脆弱性記録、デフォルト設定、悪用された脆弱性を解消するまでの時間を通じて、成果を評価できる。

Microsoftのサービスを導入するセキュリティチームも、独立した統制を維持すべきだ。自らのID監視、資産インベントリ、復旧計画、セグメンテーション、ベンダーリスク評価を維持する必要がある。

サプライヤーが改善しても、集中リスクは消えない。組織は依然として、どの重要プロセスが単一のIDプロバイダー、クラウドプラットフォーム、または管理インターフェースに依存しているかを把握する必要がある。

それでもMicrosoftのSFIは、他の大企業にとって有用なモデルを提示している。レビュー、報酬、製品アーキテクチャ、開発ゲート、顧客向けデフォルト設定が同じ目標に向かうとき、セキュリティの信頼性は高まる。

このモデルは、AIセキュリティが組織の問題である理由も示している。スキャナーは疑わしいコードを特定できるが、どの経営幹部が遅延を受け入れるかを決めることはできない。従業員が懸念を表明することを保証することも、正確な公開開示を担保することもできない。

説明責任が、その欠けている層を補う。AIが判断の根拠となる証拠を生み出しても、意思決定の責任は人間に残る。

Microsoftのセキュリティ変革は、同社がインセンティブを変え、測定可能な統制を導入したことで、スローガンの段階を超えて前進している。しかし、恒久的な評価を得たわけではない。

決定的な証拠は、日常の運用を通じてもたらされる。すなわち、防止可能な障害の減少、より迅速な修復、より明確な開示、そしてAIリリース競争の中での目に見える自制だ。

テクノロジーリーダーにとって次の段階は、Microsoftが報告する統制と、自社環境内の状況を比較することである。どの例外が残っているのか、誰が所有しているのか、そしてどのような証拠が経営層に届いているのか。こうした問いによって、情報提供としての更新は実践的なリスクレビューへと変わる。

脆弱性の結果、修復時間、インシデントの透明性を通じて、Microsoftのセキュリティ変革を引き続き注視すべきだ。これらの指標が揃って改善すれば、Microsoftのガバナンス変更は機能している。リリース圧力によってそのいずれかが弱まれば、かつての対立は形を変えて再編されただけである。