MicrosoftのCyber Stackとは?Project Perceptionの仕組みと中小企業が先に備えること
顧客企業から「Microsoftの新しいAIセキュリティを導入すべきでしょうか」と相談されても、料金や日本での利用条件が分からなければ、判断に迷います。
この段階で製品の良し悪しを急いで決めるより、重要なシステム、アラートの通知先、端末隔離の権限者が決まっているかを確認することが先です。
Microsoftの「Cyber Stack」は単独製品ではなく、「Project Perception」を支える技術構成・設計思想として発表されました。
本記事では両者の違いを整理し、中小企業診断士が顧客と今日から確認できる実務項目を解説します。
MicrosoftのCyber StackとProject Perceptionは何が違うのか
Microsoftは2026年7月27日、AI時代のセキュリティ構想として、Cyber StackとProject Perceptionを発表しました。
Microsoftは、AIやエージェントによって攻撃の速度が上がるなか、人間が個別のアラートを確認して対応する従来型の運用だけでは追いつきにくくなるとの認識を示しています。そのうえで、デジタル環境の把握から判断、対応までを連携させる新しい設計を提示しました。
ここで注意したいのは、Cyber StackとProject Perceptionが同じものではないことです。
Cyber Stackは6要素を組み合わせる設計思想
Cyber Stackは、2026年8月1日時点で購入可能な独立製品として発表されたものではありません。Microsoftの公式発表では、次の6要素を組み合わせる技術構成・設計思想として説明されています。
- デジタル環境を把握するシグナルとセンサー
- シグナルをエージェントが利用できる情報へ変換するセキュリティコンテキスト
- 推論を担うモデル
- モデルとエージェントを調整するハーネス
- セキュリティ業務を実行するエージェント
- 判断を防御措置へ変換するアクチュエーター
中小企業の業務に置き換えると、「情報を集める」「状況を理解する」「優先順位を判断する」「必要な操作を実行する」という一連の流れに相当します。
たとえば、ある従業員のアカウントで通常と異なる活動が検知されたとします。検知情報だけでは、その活動が本当に危険なのか、どの端末やデータへ影響するのかは分かりません。関連する資産、ID、権限、過去の活動などを組み合わせて状況を理解し、対応の必要性を判断したうえで、アカウント停止などの措置へつなげる必要があります。
Cyber Stackは、この流れをAIやエージェントが扱える形で構成する考え方です。「Cyber Stackという製品を導入する」と表現すると、公式発表の位置付けと異なるため注意が必要です。
Project Perceptionは構想を具体化するシステム
Project Perceptionは、Cyber Stackの考え方を具体化するエージェント型セキュリティシステムです。Microsoftによると、シグナル、セキュリティコンテキスト、モデル、専門エージェントを統合し、Microsoft Security製品群の検知結果を防御措置へつなげます。
セキュリティコンテキストには、資産、ID、関係性、リスク、活動が含まれ、組織の環境をほぼリアルタイムで表すよう継続的に更新されると説明されています。
また、Project Perceptionは単一のAIモデルだけを利用する仕組みではありません。品質、信頼性、処理の遅延、コストを考慮してモデルを使い分けるマルチモデル構成を採用します。最初のシナリオとして発表されたソフトウェア脆弱性管理では、MDASHとMAI-Cyber-1-Flashが使用されます。
ただし、2026年8月1日時点では、Project Perceptionのパブリックプレビューは同年8月3日に開始される予定です。日本が対象に含まれるか、どの契約やライセンスが必要か、料金や申込方法がどうなるかは、同日時点の公式発表では確認できません。
したがって、中小企業への提案では「すでに日本で利用できるサービス」や「この料金で導入できる製品」として説明せず、提供条件の公表を待って判断する必要があります。
レッド・ブルー・グリーンのAIエージェントは何をするのか
Project Perceptionの特徴の一つが、レッド、ブルー、グリーンという3種類の専門エージェントを連携させる設計です。それぞれを「探す」「判断する」「直す」という役割に分けると、全体像を理解しやすくなります。
レッドチームエージェントは侵害経路の候補を探す
レッドチームエージェントは、攻撃者に悪用される前に侵害経路の候補を特定する役割を担います。
たとえば、外部から接触できるシステム、脆弱性のあるソフトウェア、強い権限を持つアカウントの関係を調べ、攻撃に利用される可能性のある経路を探すイメージです。
ただし、将来の攻撃を完全に予測したり、すべての侵害を防いだりできるという意味ではありません。公式発表で示されているのは、環境内の情報を基に侵害経路の候補を特定する役割です。
ブルーチームエージェントは調査し、リスクを判断する
ブルーチームエージェントは、調査結果とセキュリティコンテキストに基づいて推論し、意味のあるリスクを判断します。
現場では、警告が多すぎると、担当者が一件ずつ内容を調べることになります。重要度の低い通知に時間を取られれば、事業への影響が大きい異常への対応が遅れる可能性があります。
Microsoftは、次世代のセキュリティシステムを特徴付けるのは、単にアラートを増やす能力ではないとの考えを示しています。ブルーチームエージェントには、資産やIDの関係を踏まえて、対応の優先順位を判断する役割が期待されています。
グリーンチームエージェントは是正措置へつなげる
グリーンチームエージェントは、判断結果を是正措置や環境の防御強化へつなげます。異常を見つけて報告するだけではなく、実際の対応まで結び付ける役割です。
一方、2026年8月1日時点の公式発表では、実行できる具体的な操作や、人間の承認が必要となる条件の詳細は確認できません。端末隔離やアカウント停止のように業務へ影響する操作を、どの範囲まで自動化できるかは未確認です。
そのため、Project Perceptionが自動的にあらゆる是正措置を実行すると断定することはできません。
人間は統制主体として残る
Microsoftは、Project Perceptionが機械速度で推論、優先順位付け、対応を行う一方、人間を統制主体として維持する設計だと説明しています。
これは、中小企業がAIを導入するとセキュリティ担当者や経営者の判断が不要になる、という意味ではありません。AIが対応候補を示したとしても、事業への影響を伴う操作を誰が承認するか、誤検知が起きたときに誰が停止・復旧を判断するかは、組織側で決める必要があります。
自動化を検討する際には、少なくとも次の点を運用設計へ含めることが重要と考えられます。
- 自動実行を許可する操作
- 人間の承認を必要とする操作
- AIや自動処理を停止する手順
- 正常な業務を止めた場合の復旧手順
- 操作記録と監査ログの保存方針
- 判断する責任者と不在時の代替担当者
発表された効果と先行事例をどう評価するか
新しいセキュリティシステムを顧客へ説明するとき、性能や時間短縮の数字は分かりやすい材料になります。しかし、その数字がどの環境で測定され、誰が公表したものかを分けて読む必要があります。
ベンチマークとコスト削減はMicrosoftの発表値
Microsoftは、ソフトウェア脆弱性管理に使用するMDASHとMAI-Cyber-1-Flashの構成について、CyberGymで96%を記録し、Mythosを12ポイント上回ったと発表しています。
また、当時市場で提供されていたMDASH構成との比較では、約50%のコスト削減になると説明しています。
これらはMicrosoft自身が公表した数値です。今回確認した公式情報だけでは、CyberGymの詳しい評価条件、使用データ、比較対象となったMythosの詳細、第三者による独立検証の結果までは確認できません。
したがって、「従来より50%安くなる」「中小企業でも96%の性能が得られる」と一般化することは適切ではありません。顧客企業へ紹介する場合は、Microsoftの発表値であることと、自社環境で同じ結果が得られるかは未確認であることを併記する必要があります。
Nationwideの「4週間から4時間」という事例
Microsoft Security Community Blogでは、英国のNationwide Building SocietyがProject Perceptionの初期利用組織の一つとして紹介されています。
同組織は既存のMicrosoft Defender環境にProject Perceptionを組み合わせ、レッド、ブルー、グリーンの各エージェントを分析担当者と連携させているとされます。利用者の説明では、脅威の特定から修復までを複数のツールにまたがらず追跡でき、4週間分の脅威インテリジェンス分析を4時間へ短縮した事例があったとされています。
注目すべき数字ですが、これはMicrosoftの公式媒体に掲載された特定顧客の証言です。対象業務、計測方法、導入費用、運用人数などの詳細は、今回確認した情報だけでは分かりません。
また、Nationwideは英国の大規模金融機関です。日本の中小企業とは、組織規模、規制、既存システム、データ量、セキュリティ担当者の人数が異なります。「4週間から4時間」を中小企業で期待できる標準的な効果として扱うことはできません。
自社の現状値と同じ条件で比較する
パブリックプレビューへの参加や将来の導入を検討する場合は、発表された数値をそのまま目標にせず、まず自社の現状を測ることが重要です。
評価項目としては、次のようなものが考えられます。
- 調査と優先順位付けに要した時間
- 誤検知や見逃しの発生状況
- 人間による確認と承認に要した工数
- 自動対応が通常業務へ与えた影響
- 操作記録を後から確認できるか
- 既存製品を含めた総費用
- 導入前後に必要となる運用人員
- 異常時に自動処理を停止し、復旧できるか
これらの現状値を記録しておけば、自社環境で限定的に検証するときの比較基準になります。提供地域、契約条件、必要製品、料金が公表された後に、費用と運用負担を含めて判断するのが妥当です。
中小企業診断士が顧客と先に確認したい4つの領域
Project Perceptionを導入するかどうかにかかわらず、中小企業が整えられる項目があります。
NIST SP 1300は、サイバーセキュリティ計画が限定的または未整備の小規模組織向けに、CSF 2.0を「Govern、Identify、Protect、Detect、Respond、Recover」の6機能で整理しています。ここでは、その指針とMicrosoftの構想を混同せず、中小企業診断士が顧客との面談で使える4領域に落とし込みます。
重要資産を把握する
最初に確認したいのは、守る対象が一覧になっているかです。NISTも、資産を保護するには、まず資産を特定する必要があるという考えを示しています。
資産台帳には、パソコンだけでなく、業務ソフト、クラウドサービス、Webサイト、サーバー、ドメイン、管理アカウントなども含めます。行政書士事務所であれば案件情報を扱う端末やクラウドストレージ、顧客とのデータ共有サービスなどが候補になります。Web制作会社であれば、顧客サイトのCMS、プラグイン、ドメイン管理サービス、サーバー、外部連携サービスも対象です。
各資産について、次の項目を記録します。
- 資産の名称と用途
- 管理者または所有者
- アクセスできる機密データ
- MFA(多要素認証)の有無
- 利用不能になった場合の事業影響
- 異常発生時の連絡先
- 最終確認日と更新責任者
MFAとは、パスワードに加えて、認証アプリやセキュリティキーなど複数の要素で本人確認を行う仕組みです。
すべての機器やサービスを一度に整理しようとすると、台帳作成が止まりやすくなります。まずは「停止すると当日の業務が続けられない」「顧客情報へアクセスできる」という二つの基準で重要資産を選び、5件から10件程度を記録すると着手しやすくなります。
継続監視と通知体制を可視化する
次に、異常をどのように検知し、誰へ知らせるかを確認します。監視製品を契約していても、アラートの確認担当者が決まっていなければ、通知が対応につながらない可能性があります。
顧客とのヒアリングでは、次の順で確認すると現状を整理できます。
- 端末、アカウント、クラウドサービスのうち、何を監視しているか確認します。
- ログとアラートを誰が見ているか確認します。
- 担当者が確認できる曜日と時間帯を記録します。
- 夜間や休日の通知先を確認します。
- 一定時間応答がない場合の代替担当者を決めます。
- 通知を受けた後、誰が調査や対応を開始するか確認します。
ログとは、システムへのアクセスや操作、エラーなどを記録した情報です。アラートは、その記録や検知結果に基づいて異常の可能性を知らせる通知を指します。
社内で継続的な監視を行う人員がいない場合、NISTは監視サービス事業者の利用を優先事項として検討するよう示しています。選択肢にはMSSPがあります。MSSPとは、組織に代わってセキュリティ監視や運用を提供する事業者です。
ただし、外部委託がすべての中小企業に適するとは限りません。費用だけでなく、監視する対象、通知だけか初動対応まで含むか、夜間の対応時間、事故発生時の責任分界を比較する必要があります。
初動対応の権限と連絡先を決める
休日に重要端末で異常が検知された場面を想像してください。担当者が通知を受けても、端末をネットワークから切り離す権限がなく、経営者とも連絡が取れなければ、対応が止まる可能性があります。
初動対応表を1枚作り、少なくとも次の操作について、実行条件、実行者、承認者、代替担当者を記載します。
- 端末をネットワークから隔離する
- アカウントを一時停止する
- パスワードや認証情報を変更する
- ログや関連記録を保全する
- 外部の保守・監視事業者へ連絡する
- 経営者へ報告する
- 顧客や取引先への連絡要否を判断する
- 復旧作業を開始する
情報漏えい時などの報告先や報告条件は、扱う情報、法令、契約によって異なる可能性があります。資格名だけを根拠に中小企業診断士や行政書士などが個別の法的・技術的対応を担えると判断せず、必要に応じて情報セキュリティ事業者や関係分野の専門家と連携します。
対応表を作ったら、「土曜日の午前2時に、顧客情報を扱う端末で異常が検知された」という想定で机上演習を行います。連絡がつかない、操作権限がない、保守会社の契約範囲が分からないといった問題が見つかったら、台帳と対応表を更新します。NISTも、対応計画が実行可能かを事前に演習することを確認項目として挙げています。
AIへ許可する操作範囲を段階化する
自動化は「使うか、使わないか」の二択ではありません。業務への影響に応じて、次の3段階に分ける方法が考えられます。
| 段階 | 運用方針の例 |
|---|---|
| 通知のみ | AIが異常や対応候補を示し、人間が内容を確認します。 |
| 承認後に実行 | 端末隔離やアカウント停止などは、責任者が承認してから実行します。 |
| 条件付き自動実行 | 対象、時間帯、重大度などを限定し、条件を満たす場合だけ自動実行します。 |
条件付き自動実行を採用する場合でも、誤検知によって正常な端末やアカウントが止まる可能性を考える必要があります。対象を限定し、停止方法、手動運用へ戻す方法、復旧の責任者を事前に決めます。操作記録を残し、誰が何を承認し、どの処理が実行されたかを確認できる状態にすることも必要です。
Project Perceptionの具体的な自動操作や承認条件が公表された後は、自社で決めた段階と製品仕様を照合します。仕様に運用を合わせるのではなく、許容できる事業影響と責任分担を先に決めることが重要です。
まとめ|製品選定より先に「資産・監視・初動・承認」を整える
Cyber Stackは、2026年8月1日時点では購入可能な単独製品ではなく、Project Perceptionを支える技術構成・設計思想です。Project Perceptionは、レッド、ブルー、グリーンの専門エージェントを連携させ、情報の把握、リスク判断、是正措置をつなぐシステムとして発表されました。
一方、パブリックプレビューは2026年8月3日に開始される予定であり、日本での提供可否、料金、必要ライセンス、具体的な自動対応範囲は確認できません。MicrosoftのベンチマークやNationwideの時間短縮事例も、日本の中小企業における一般的な導入効果として扱うことはできません。
中小企業診断士が今日から取れる行動は、次回の顧客面談で以下の4点をヒアリング票へ追加することです。
- 停止すると事業への影響が大きいシステムは何か
- 夜間や休日のアラートを誰が受け取るか
- 端末隔離やアカウント停止を誰が実行し、誰が承認するか
- 誤検知で業務が止まった場合、誰が自動処理の停止と復旧を判断するか
回答できない項目があれば、まず重要資産を5件から10件選んで簡易台帳を作り、初動対応の実行者、承認者、代替担当者、連絡先を1枚にまとめます。その後、休日の異常検知を想定した机上演習を行い、連絡不能や権限不足が見つかった箇所を修正します。
高度なAIセキュリティを評価する土台になるのは、製品名ではなく、自社の資産、監視、初動、承認の現状を説明できることです。提供条件が公表されたときに、この4領域と照合すれば、導入の必要性と運用負担を具体的に判断しやすくなると考えられます。
出典一覧
- Microsoft「Rethinking security for the age of AI」(2026-07-27)
- Microsoft Security Community Blog「How Nationwide stays ahead of attackers with Project Perception」(2026-07-27)
- NIST SP 1300「NIST Cybersecurity Framework 2.0: Small Business Quick-Start Guide」(2024-02)
- NIST「NIST Cybersecurity Framework 2.0 for Small Business」(2019-02-07)
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」(2024-02-26)
この記事はAIが生成し、編集長のチェックを受けて公開しています。