0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

MicrosoftのProject Perceptionは、SOCを「アラート処理」から連続防御へ変える

0
Posted at

Microsoftは2026年7月27日、AIを活用したエージェント型セキュリティシステム「Project Perception」を発表した。パブリックプレビューは8月3日に始まる予定だ。

発表を「AIが脅威を検知する新しいツール」とだけ捉えると、本質を見落とす。Project Perceptionが示しているのは、SOCをアラートの受信・調査・チケット起票の場から、リスクを継続的に把握し、優先順位を付け、対処までつなぐ仕組みへ変えようとする方向性である。

ただし、これはAIが人間に代わって防御を完結させるという話ではない。AIが速くなるほど、誰に何の実行権限を渡すか、どの操作を人が承認するか、誤操作をどう戻すかという運用設計が重要になる。

発表されたのは、単独のAIアシスタントではない

MicrosoftはProject Perceptionを、AIがAIを使った攻撃に対抗するための「agentic security system」と位置付ける。構成要素は、ログやテレメトリなどのシグナル、組織の資産・ID・活動・リスクを結び付けるセキュリティコンテキスト、複数のモデル、専門エージェント、実際の保護操作を行う仕組みである。

特徴は、役割の異なるエージェントを連携させる点にある。

  • Red team agents:攻撃者に悪用される前に、侵入経路や弱点を探す
  • Blue team agents:シグナルと周辺情報を調査し、本当に重要なリスクかを判断する
  • Green team agents:修正・設定変更などの対処を行い、防御態勢を強化する

Microsoftは、ID、エンドポイント、アプリケーション、データ、クラウド、AIシステムを横断して状況を把握し、専門エージェントが継続的に「発見・評価・改善」する閉ループを目指すとしている。公式発表で強調されるのは、アラートを増やすことではなく、リスクを認識し、推論し、行動へつなげることだ。

背景:攻撃だけでなく、防御の前提も機械速度になる

従来のSOCは、検知ルールでアラートを出し、担当者が情報を集め、影響を判断し、必要なら封じ込める流れで動いてきた。この方法は、攻撃の量と変化の速度が人間の調査能力を超え始めると詰まりやすい。

AIを使う攻撃者は、公開情報の収集、コードや設定の分析、標的の絞り込み、フィッシング文面や悪性コードの改善を高速に繰り返せる。一方、防御側には、アラートのノイズ、資産情報の欠落、部門ごとに分断されたログ、業務停止を避けるための慎重な判断がある。

だから防御側に必要なのは、AIにアラートを要約させることだけではない。資産・ID・脆弱性・脅威情報・過去の対応履歴を結び付け、AIが「何を先に調べるべきか」を示し、人が判断できる材料を短時間で作る仕組みである。

Microsoftは2026年6月のBuildでも、複数モデルと100以上のエージェントを用いて、データフロー、業務ロジック、悪用経路を分析し、修正案をDefenderポータルへ届ける「Codename MDASH」を紹介していた。Build 2026の発表と今回のProject Perceptionを並べると、Microsoftが単発の支援機能ではなく、AIエージェントを前提にセキュリティ運用そのものを再設計しようとしていることが分かる。

期待できる効果は「検知件数」より、判断までの時間短縮

Project Perceptionの価値は、AIが侵害を魔法のように見抜くことではない。調査に必要な情報を集め直す時間を減らし、重要な事案へ人の注意を集中させることにある。

たとえば、ある端末で不審な通信を検知したとき、AIは次のような材料を並べられる可能性がある。

  • 端末の所有者、役割、重要度、外部公開の有無
  • 直近の認証、権限変更、メール、クラウド操作
  • 関連する脆弱性と、実際の悪用情報
  • 同一のIPアドレス、アカウント、端末で起きた類似事象
  • 影響を抑えるための隔離・無効化・監視強化の候補

この情報が根拠付きでまとまれば、アナリストは「調べる」時間を減らし、「隔離するか」「誰に連絡するか」「業務影響をどこまで許容するか」の判断へ時間を使える。

一方、ベンダーが示す性能や効果は、自組織で再現されるとは限らない。ログの品質、資産台帳の正確さ、ID管理、連携できる製品、担当者の運用手順によって結果は変わる。導入効果は、検知件数ではなく、重大事案の調査開始までの時間、誤検知率、封じ込めまでの時間、誤操作からの復旧可能性で測るべきである。

自律化の範囲を先に決める

セキュリティ運用でAIに実行権限を渡すと、対応速度は上がる。しかし、誤った隔離、アカウント無効化、通信遮断、クラウド設定変更は業務停止や二次被害を招き得る。

そのため、導入前に自律化の段階を明確にしておく必要がある。

段階 AIに任せる処理 人が担う処理
調査支援 ログ整理、根拠収集、影響範囲の仮説、チケット下書き 侵害の認定、対外説明
提案 優先順位、封じ込め案、復旧手順の提示 実行可否と業務影響の判断
限定実行 低リスクな証跡保全、監視強化、期限付きの遮断 アカウント停止、広域遮断、権限・設定変更
高影響操作 実行前チェックと復旧案の提示 二者承認、実行、事後レビュー

特に重要なのは、エージェントの閲覧権限と実行権限を分けることだ。調査に必要な広い可視性と、環境を変更できる強い権限を同じ主体に与えてはいけない。高影響操作には承認、有効期限、対象範囲の制限、解除手順、実行ログを必須にする。

MicrosoftがProject Perceptionで「humans firmly in control」を掲げるなら、導入側もその言葉を設計に落とし込まなければならない。人が最終判断するというだけでは不十分であり、どの操作を誰が承認し、どのログを残し、誤ったときにどう止めるかまで決めて初めて統制になる。

今後の影響:SOCは「画面を見る仕事」から変わる

この方向性が広がれば、SOCの仕事はなくなるのではなく変わる。担当者は、アラートを一件ずつ読む人から、AIが整理した根拠を検証し、例外を見極め、自動化の境界を設計し、重大事案の判断を担う人へ比重が移る。

組織側にも変化が求められる。

  • セキュリティチームは、検知ルールだけでなく、AIの実行権限、承認、監査、評価を設計する
  • IT運用チームは、資産・構成・変更履歴をAIが参照できる品質で維持する
  • ID管理チームは、人間だけでなくエージェントにも最小権限、期限、アクセスレビューを適用する
  • 経営・業務部門は、被害抑止と業務継続のどちらを優先するかという判断基準を事前に定める

最終的に差が付くのは、どのモデルを使うかだけではない。データがつながっているか、権限が分離されているか、AIの提案を検証できるか、止めて戻せるか、そして人が責任を持って判断できるかである。

まず確認したい5項目

Project Perceptionのようなエージェント型セキュリティを検討する際は、デモの精度だけでなく、次を確認したい。

  1. AIが参照するログ、資産、ID、脅威情報の範囲と保存先は明確か
  2. 調査用の閲覧権限と、対処用の実行権限は分離されているか
  3. 高影響操作に二者承認、時間制限、ロールバック手順を設定できるか
  4. AIの結論だけでなく、参照根拠・指示・実行履歴を監査できるか
  5. 誤検知や誤操作を前提に、停止・復旧・事後レビューを実施できるか

AI時代のセキュリティでは、速く見つけることと同じくらい、速く安全に止めることが重要になる。MicrosoftのProject Perceptionは、そのためにSOCを「検知の集積所」から「人とAIが連続的に防御を改善する運用基盤」へ変えようとする発表として読むべきだろう。

参考情報


作成日: 2026年7月28日

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?