Microsoft Project Perceptionが示すエージェント型セキュリティ｜AI防御を常時運用に組み込む方法

目次

---

1. セキュリティ運用は「アラートを読む仕事」から変わり始める

セキュリティチームの仕事は、すでに人間の注意力だけでは追いつきにくくなっています。ID、端末、クラウド、SaaS、開発環境、AIエージェントのログが同時に増え、そこへ攻撃者側のAI活用も重なります。アラートを増やすだけでは、守る側の判断待ちが増え、重要な兆候ほど埋もれやすくなります。

Microsoftは2026年7月27日、AI時代のセキュリティシステムとしてProject Perceptionを公式ブログで発表しました。Microsoftの説明によると、Project Perceptionは、攻撃者の視点を探るRed team agents、リスクを調査・判断するBlue team agents、是正や防御強化を担うGreen team agentsを組み合わせた、エージェント型の防御システムです。2026年8月3日にパブリックプレビューへ入る予定とされています。

この発表のポイントは、セキュリティAIを「調査を手伝うチャットボット」としてではなく、常時稼働する防御の仕組みとして位置づけていることです。AIが攻撃にも防御にも使われる時代には、検知、調査、優先順位づけ、是正を人間が順番に回すだけでは遅くなります。ただし、すべてをAIに任せればよいわけでもありません。重要なのは、AIに見せる文脈、AIが取れる行動、人間が承認すべき境界を設計することです。

2. Project Perceptionとは何か

Microsoftの公式発表では、Project Perceptionは「AIを使ってAIに対抗する」ためのシステムとして説明されています。単にログを要約するのではなく、信号、文脈、モデル、専門エージェントを組み合わせ、組織のセキュリティ状態を継続的に理解し、優先順位をつけ、改善につなげる考え方です。

特徴的なのは、Red、Blue、Greenという3種類のエージェントの役割分担です。Red team agentsは、攻撃者が取り得る経路や悪用可能性を先回りして探ります。Blue team agentsは、ID、端末、アプリケーション、データ、クラウド、AIシステムにまたがる文脈をもとに、何が本当に意味のあるリスクかを調査します。Green team agentsは、判断されたリスクに対して是正や防御強化を行います。

Microsoftは、この仕組みを支える土台として新しいCyber Stackも示しています。構成要素は、デジタル環境を観測するsignals and sensors、AIが扱いやすい形に整理されたsecurity context、判断を担うmodels、モデルとエージェントを調整するharness、実際にセキュリティ業務を進めるagents、そして意思決定を防御アクションへ変えるactuatorsです。ここで重要なのは、AIモデル単体ではなく、周辺の文脈、権限、実行制御まで含めて設計している点です。

モデル設計でも、Microsoftは単一の高性能モデルに寄せるのではなく、フロンティアモデルとサイバー領域に特化したモデルを組み合わせるマルチモデル構成を採用すると説明しています。最初の適用領域はソフトウェア脆弱性管理で、MAI-Cyber-1-FlashをMDASHというマルチモデルのエージェント型スキャン基盤へ組み込むとされています。Microsoftによると、この構成はCyberGymで96%を達成し、Mythosを12ポイント上回り、現行のMDASH構成に比べて約50%のコスト削減を見込むとされています。

3. なぜエージェント型の防御が必要になるのか

AI時代のセキュリティで難しいのは、攻撃の量だけではありません。攻撃者がAIを使うと、偵察、脆弱性探索、フィッシング文面、権限昇格の試行、ログに残りにくい横移動の仮説づくりが速くなります。守る側が従来どおり、検知、調査、チケット化、修正依頼、再確認を人手中心に回していると、判断の待ち時間そのものがリスクになります。

たとえば、ある社内SaaSで不審なログインがあり、同じユーザーの端末で未知のプロセスが動き、さらに開発リポジトリで認証まわりの変更が入ったとします。個々のアラートは低から中程度でも、組み合わせると重要な攻撃経路を示している可能性があります。このとき必要なのは、アラートを増やすことではなく、ID、端末、コード、クラウド権限、直近の変更履歴を横断して、リスクの意味をすばやく組み立てることです。

Project Perceptionが示す方向性は、この組み立てをAIエージェントに担わせるものです。ただし、AIが自由に社内環境を操作するという意味ではありません。Microsoftの発表でも、人間を制御の中心に置くことが強調されています。AIはリスクを見つけ、仮説を立て、是正案を出し、低リスクな改善を進める一方で、権限変更、本番遮断、ユーザー停止、重要設定の変更といった操作には明確な統制が必要です。

企業にとっての示唆は、SOCや情シスの業務を「人が読むアラート一覧」から「AIが文脈化したリスクキュー」へ変えていくことです。アラート件数、平均対応時間、検知率だけを見るのではなく、どのリスクを自動で調査できるか、どの是正は人間承認が必要か、どのログや構成情報をAIが安全に参照できるかを設計する必要があります。

4. 企業が設計すべきAI防御スタック

第一に、AIに渡すセキュリティ文脈を整理することです。ログをそのまま大量に流し込むだけでは、精度もコストも安定しません。資産、ID、権限、ネットワーク、クラウド設定、脆弱性、過去インシデント、変更履歴を、AIが関連づけて読める形にする必要があります。Microsoftがsecurity contextを重視しているのは、AIエージェントの判断品質が文脈の質に強く依存するからです。

第二に、モデルを用途ごとに使い分けることです。脆弱性の再現可能性を評価する、ログの時系列を要約する、攻撃経路を推定する、是正手順を生成する、開発者向けに説明する。これらは同じセキュリティ業務でも、必要な精度、速度、コスト、説明性が違います。フロンティアモデルだけに任せるとコストが重くなり、軽量モデルだけでは複雑な判断に弱くなります。マルチモデル構成は、AI運用の経済性を保つための現実解になります。

第三に、エージェントが取れる行動を段階化することです。ログ検索、相関分析、チケット作成、影響範囲の提示は比較的低リスクです。一方、ユーザー停止、ファイアウォール変更、権限剥奪、本番設定の変更は、誤作動時の影響が大きくなります。AI防御を導入する企業は、どのアクションを自動化し、どこから人間承認にするかを、操作の危険度と業務影響で分けるべきです。

第四に、検証と監査を最初から組み込むことです。AIが出したリスク判定が正しかったか、どのログを根拠にしたか、どのモデルが判断したか、誰が承認したか、是正後にリスクが下がったか。これらを残さないと、AIセキュリティは説明できないブラックボックスになります。特に、規制業種や個人情報を扱う業務では、判断履歴そのものが内部統制の一部になります。

第五に、AIエージェント同士の役割を混ぜないことです。攻撃経路を探す役割、リスクを評価する役割、是正を実行する役割が曖昧になると、強い権限を持つAIが自分で仮説を立て、自分で実行する構図になりやすくなります。Red、Blue、Greenのように役割を分け、相互確認と人間承認を組み合わせることで、自動化の速度と統制を両立しやすくなります。

5. 導入時に見落としやすい注意点

一つ目の注意点は、AI防御をSOCだけの話に閉じないことです。Project Perceptionが扱う世界は、ID、端末、アプリケーション、データ、クラウド、AIシステムにまたがります。つまり、情シス、セキュリティ、開発、クラウド運用、法務、事業部門の境界を越えます。AIが見つけたリスクを誰が修正するのか、開発チームのスプリントにどう入れるのか、事業停止リスクを誰が判断するのかまで決めなければ、検知だけが先に進みます。

二つ目は、専門モデルの数値をそのまま自社効果と見なさないことです。Microsoftが示したCyberGymでの96%という結果や約50%のコスト削減は注目に値しますが、自社のログ品質、対象システム、脆弱性管理プロセス、承認フローによって効果は変わります。導入時は、公開ベンチマークに加えて、自社の過去インシデント、既知脆弱性、誤検知パターンを使った評価が必要です。

三つ目は、AIに広い閲覧権限を与えすぎることです。セキュリティAIは、多くの情報を見られるほど判断しやすくなります。しかし、社員情報、顧客データ、秘密鍵、契約情報、ソースコード、セキュリティ設定を横断して扱うため、AIそのものが高価値な権限主体になります。最小権限、データマスキング、監査ログ、用途別のアクセス制御を設けなければ、防御システムが新たなリスクになります。

四つ目は、自動是正を急ぎすぎることです。AIが危険と判断したユーザーを止める、通信を遮断する、設定を変更する。これらは被害を抑える一方で、誤判定なら業務停止につながります。最初は調査支援、証跡整理、チケット作成、低リスクな設定提案から始め、実行権限は段階的に広げるほうが現実的です。

最後に、AI時代のセキュリティは一度導入して終わるものではありません。攻撃手法、モデル性能、社内システム、規制要件、事業の許容リスクは変化します。エージェントの権限、モデル選択、評価基準、承認ルール、ログ保存期間を定期的に見直す運用が必要です。AIが常時学習する防御システムになるほど、人間側のガバナンスも継続的でなければなりません。

6. まとめ

MicrosoftのProject Perception発表は、AI時代のセキュリティ運用が、アラート監視からエージェント型の継続的な防御へ進むことを示しています。Red team agents、Blue team agents、Green team agentsの役割分担、security context、マルチモデル構成、actuatorsによる実行制御は、単なるAI要約ツールとは違う本番運用の設計思想です。

企業が今考えるべきなのは、どの製品を入れるかだけではありません。AIにどの文脈を見せるか、どのモデルをどの業務に使うか、どの操作を自動化し、どこで人間が承認するか、判断根拠をどう監査できるようにするか。ここを先に決めることで、AI防御は便利な実験ではなく、事業を守る運用基盤になります。

OpenBridgeでは、AIエージェント、RAG、MCP、社内システム連携、権限管理、監査ログを含むAIシステム開発を支援しています。セキュリティ運用にAIを組み込む際は、モデル導入だけでなく、文脈設計、権限制御、人間承認、評価ログまで含めた全体設計が、本番化の第一歩になります。