こんにちは、セキュリティ製品の名前とエージェントの名前が増えすぎて、頭の中で整理しきれないアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
2026/07/27 に Microsoft が発表した Project Perception を調べました。最初は ChatGPT にまとめてもらい、そのうえで Microsoft Learn と公式ブログを読み直して、裏が取れた内容だけを残しています。
エージェントの一覧、Azure に関係が深い Recon Agent（Recon は reconnaissance＝偵察の略）、Security Copilot や MDASH との関係までを 1 本にまとめたので、参考になれば幸いです。私はまだ実機で動かしていません。公式ドキュメントの読み解きです。
Project Perception はプレビュー（Limited Public Preview）の製品です。この記事は 2026/10/05 時点 の情報で、名称・機能・構成・前提条件・課金は今後変わる可能性があります。参照した Learn のページも、多くが機械翻訳を含み、プレリリース製品として内容が大きく変わる可能性があると明記しています。利用時点の公式ドキュメントを確認してください。
TL;DR
- Project Perception は、赤・青・緑の 3 チーム 6 種類の専用エージェントが、同じセキュリティコンテキストを共有して動くマルチエージェント防御システムです（Microsoft Defender ポータルの Perception メニュー。画面構成（Learn））
- 公式ブログの言い方では、シグナルから対応までを perceive → reason → act（把握 → 推論 → 実行）で回す新しいサイバースタックです
- Azure の人に関係が深いのは Recon Agent です。侵害済みと仮定した攻撃パス分析を、読み取り専用の API で行います。前提は Entra ID P2、Defender XDR、Defender CSPM、Azure サブスクリプションです
- 影響の大きい操作は、エージェントが承認待ちで止まります。人は承認・拒否・代替案の提示・セッション停止ができます
- MDASH（コード脆弱性の発見エージェント）は、MDASH 開発者の説明では Perception の前段に差し込める位置づけです。MAI-Cyber-1-Flash は MDASH の中で最初に使われているモデルです
- 前提ライセンスはエージェントごとに違います（Microsoft 365 E5、Entra ID P2、Defender CSPM など）。Perception 自体の金額は、確認した Learn のページには出ていません
- 提供状態は Limited Public Preview（招待制）です。2026/10/05 時点の話で、採用判断には正式公開後の要件・課金・運用実績の再確認が必要です
この図は、この記事で整理した Learn と公式ブログの内容をもとに、筆者が作った要約図です（公式の図ではありません）
何を狙った仕組みか
公式ブログの主張は、攻撃側が AI で攻撃コードを速く大量に作れるようになった以上、人間の速度を前提にしたセキュリティでは追いつかない、というものです。そこで、環境全体のリスクを把握し、膨大なコンテキストを推論し、機械の速度で行動する新しいスタックが必要だと述べています。
Rethinking security for the age of AI（The Official Microsoft Blog）
Learn の概要ページでは、Perception をシグナル・コンテキスト・モデル・専用エージェントを継続的に学習する防御システムにまとめたものと説明しています。人が制御し続ける前提です。
6 つの層
公式ブログは、このスタックを 6 層で説明しています。元の図は英語なので、内容を日本語で作り直しました。上が最終的な行動、下が土台です。
元の図（英語）: The new cyber stack（The Official Microsoft Blog）。記事は Rethinking security for the age of AI。この図は公式の図を日本語で再構成したものです
Security Context
Context の層では、資産・ID・関係性・リスク・アクティビティを結び付けた表現を作って、全エージェントで共有します。ブログによると、エージェントが生シグナルから状況を毎回組み立て直さずに済むので、推論の精度と一貫性が上がり、時間・計算量・コストが下がります。
モデルは品質・信頼性・レイテンシ・コストを見てタスクごとに選ぶマルチモデル構成で、特定のモデルに縛られないと公式は説明しています。
シグナルがコンテキストを経由して赤・青・緑のエージェントへ届く流れは、公式ブログの Sankey 図に描かれています。元の図は英語で線の数も多いので、3 段の流れに簡略化して日本語にしました。
元の図（英語）: Sankey 図（The Official Microsoft Blog）。この図は公式の図を日本語で簡略化して再構成したもので、個々の線のつながりは省いています。各チームの一言説明は、Learn のカテゴリ説明に基づく補足です
センサー側の例として、図には Microsoft Defender for Endpoint、Microsoft Entra ID、Microsoft Sentinel、Azure Resource Manager、Exposure Management、Threat Intelligence などが並んでいます。Azure Resource Manager が入っているので、Azure の構成情報もコンテキストの材料です。
赤・青・緑の 6 エージェント
Learn では、エージェントを次の 3 カテゴリに分けています。
- 赤チーム: 攻撃者の動きをシミュレートして、悪用される前の弱点を表に出す
- 青チーム: 脅威を検出し、トリアージし、調査する
- 緑チーム: セキュリティ体制を修復し、強化する
Project Perception のエージェント カテゴリ（Learn）
3 チームの役割分担は、Learn の図を見ると一目で分かります。赤は「弱点を見つける」、青は「調査してリスクを見極める」、緑は「直して固める」で、矢印は 3 チームの作業がつながることを示しています。元の図は英語なので、日本語で作り直しました。
元の図（英語）: Accelerate security with agents（Learn の画像）。ページは Project Perception のエージェント カテゴリ（Learn）。この図は公式の図を日本語で再構成したものです
| チーム | エージェント | 役割（Learn の説明） |
|---|---|---|
| 赤 | Recon Agent | 攻撃者の偵察を実行し、環境・攻撃パス・チョークポイント・貴重な資産・構成の問題・過剰なアクセス許可をマップする |
| 青 | Triage Agent | アラートを真陽性または偽陽性に分類して解決し、理由を説明する |
| 青 | Threat Intelligence Agent | 攻撃パターン・インジケーター・脅威インテリジェンスオブジェクトを抽出し、防御方法や対応方法を分析する |
| 青 | Attack Investigation Agent | アラート・インシデント・シグナルを関連付けて攻撃ストーリーを再構築し、判定・タイムライン・手法・IoC・影響を受けるエンティティを返す |
| 青 | Detection Authoring Agent | 検出カバレッジのギャップを特定し、検出ルールを作成する |
| 緑 | Posture Prioritization Agent | 現実のリスク・露出・悪用可能性・資産の重要度で体制の問題をランク付けし、最初に直すものと理由を示す |
Attack Investigation Agent は、概念ページで「自律的な Tier-2 調査」を行うプレイブックの担当とされています。SOC の二次対応（Tier 2）を肩代わりする立ち位置です。
エージェント同士のつながり方
エージェントは、前のエージェントの出力が次の入力になるように設計されています。Learn の例では、Threat Intelligence Agent が抽出した脅威情報が、そのまま Detection Authoring Agent の検出作成に流れます。
プレイブックは、特定のセキュリティ目標に向けてエージェントを並べた再利用可能なテンプレートです。新しい脅威への対応を例にした流れが、カテゴリページに書かれています。
この図は、Learn のエージェント カテゴリに書かれた「新しい脅威への対応」の流れをもとに、筆者が作った図です（公式の図ではありません）
プレイブックの注意点が 2 つあります。現時点のプレイブックは Microsoft が用意したもので、作成・編集・削除はできません。また、プレイブックに必要なエージェントがすべて設定済みで有効になっていないと、そのプレイブックは動きません。
対象環境と前提ライセンス
Perception は Microsoft Defender ポータル上の機能です。共通の前提は、Defender ポータルへのアクセスと、すべての Defender ワークロードで統合 RBAC（URBAC）を有効にしていることです。エージェントごとの追加前提は次のとおりです。
| エージェント | 前提の製品・ライセンス（Learn の記載） | 対象範囲 |
|---|---|---|
| Recon | Entra ID P2、Defender XDR、Defender for Cloud の Defender CSPM、Azure サブスクリプション | Azure 環境。エージェント ID から見えるサブスクリプションとリソースだけ |
| Triage | アラート種別ごとに異なる（メール: Defender for Office 365 プラン 2、ID: Entra ID P2 + Defender for Identity + Defender for Cloud Apps、クラウド: Defender for Cloud + Defender for Containers） | サポート対象の Defender アラートの一部 |
| Threat Intelligence | Defender XDR、完全な TI データアクセスとエンリッチメントには Microsoft Defender 脅威インテリジェンス | TI 記事・脅威アクタープロファイル・TI レポート |
| Attack Investigation | Microsoft 365 E5、Defender XDR、Microsoft Defender Data Lake と統合セキュリティエクスペリエンスへのオンボード。攻撃の種類では Defender for Cloud や Entra ID P2 なども推奨 | Defender のアラート・インシデント 1 件単位 |
| Detection Authoring | Security Copilot プラグイン（Defender XDR、Microsoft 脅威インテリジェンス、該当する場合は Sentinel）が自動で有効になる。追加権限としてカスタム検出ルールの読み取りと書き込み、高度なハンティングの読み取り、セキュリティ データの基本（読み取り） | TI 記事を起点にした検出提案 |
| Posture Prioritization | Microsoft 365 E5、Defender for Cloud の Defender CSPM | クラウド資産とデバイス。Defender のシグナルのみ（サードパーティの CSPM データはプレビューで未サポート） |
読むときのポイントは 3 つです。
- Recon が分析するのは Azure 環境です（Learn の記述は Azure のみ）
- Microsoft 365 E5 の記載があるのは Attack Investigation と Posture Prioritization です。それ以外は Learn 上、製品単位の前提（Recon なら Entra ID P2 と Defender CSPM など）で書かれています
- エージェントの推論には、Azure の Foundry Models にある OpenAI の大規模言語モデルが使われます。アプリケーション カードによると、セッションの顧客データはモデルのトレーニングに使われません。プロンプトの処理場所は、テナントの Customer Data Storage が EU なら EU、それ以外なら地域と GPU の空き次第で米国・英国・EU・オーストラリア・ニュージーランドのいずれかです。挙がっている地域に日本はありません
Project Perception のアプリケーション カード（Learn）
どこで動き、何に触れるか
実行基盤の種類（コンテナーか Functions かなど）は、Perception の Learn に記載がありません。分かるのは、利用者がエージェントを自分の環境へデプロイする形ではなく、エージェント ID・権限・スコープ付きリソースへのアクセスと、エージェントごとの前提設定を整える形だという点です。私は、Microsoft が提供する SaaS に近い形だと読みました。利用者が決めるのは、エージェント ID、権限とスコープ、承認の運用です。
裏側の流れは、Learn の記述をつないだ私の整理です（公式の構成図ではありません）。
- 入口: Defender ポータルの Perception（チャット、エージェント、プレイブック）、またはインシデントや TI 記事のページから始めます。チャットで頼むと、Perception が適切なプレイブックを選び、入力を事前設定して実行します
- セッション: プレイブックが、実行する仕事、動かすエージェント、必要な入力を決めます。やり取りと成果物はセッションに残り、セッションは後から変更できない監査記録です。複数のエージェントを使うプレイブックでは、前のエージェントの出力が次の入力になります
- 推論: Azure の Foundry Models の LLM が推論します。プロンプトは Azure データセンターの GPU クラスターで評価され、セッションはテナント境界内で動きます
- データへのアクセス: エージェント ID に付けた権限とスコープの範囲で、Defender、Microsoft Graph、Azure の API を読みます。範囲外は読めません
- 承認ゲート: 影響の大きい操作の前でセッションが一時停止し、人が承認・拒否・別の提案・停止を選びます
- 出力: Markdown のレポートなどが、セッションの成果物に残ります
関連が深い Security Copilot については、アプリケーション カードが Security Copilot 全体を「Microsoft のハイパースケール インフラストラクチャとセキュリティ固有のオーケストレーション レイヤー上で実行され」と説明しています。エージェントは、構成された ID、権限、トリガーの範囲で動くという説明です。
Security Copilot エージェントのアプリケーション カード（Learn）
Perception の Triage Agent と Detection Authoring Agent は Security Copilot のプラグインを使うので、近い構造だと私は見ています。同じ基盤で動くかどうかは、Perception の Learn に明記がなく、私の推測です。
エージェントごとの入口とデータは次のとおりです。
| エージェント | 動かす入口 | 触るデータ・API |
|---|---|---|
| Recon | プレイブック（ID リスクを評価する、攻撃パスを特定する、脅威から保護する） | Microsoft Graph の読み取り 8 権限と、Azure サブスクリプションの閲覧系 4 ロール |
| Triage | 新しいアラートで自動。プレイブック「トリアージ アラート」で手動も可 | Defender のアラート。Security Copilot のプラグインが自動で有効になる |
| Threat Intelligence | プレイブック、または Defender ポータルの TI 記事ページ | Defender XDR API、Defender 脅威インテリジェンス API、Graph の SecurityEvents.Read.All
|
| Attack Investigation | アラートやインシデントの詳細ページ、またはプレイブック「攻撃を調査する」 | Defender のシグナル。前提に Defender Data Lake |
| Detection Authoring | プレイブック「脅威から保護する」 | Security Copilot のプラグイン、カスタム検出ルールと高度なハンティングの権限 |
| Posture Prioritization | プレイブック（態勢の修復計画、脅威から保護する） | Defender のポスチャシグナル（クラウド資産とデバイス） |
使い始める流れ
入口はどこか
入口は Microsoft Defender ポータルです。サインインして、ナビゲーション ウィンドウの Perception を選びます。初回はチャットとプレイブックを選べるウェルカム ページが出て、概要ダッシュボードが既定で開きます。Perception の中には次のページがあります。
| ページ | 開き方 | できること |
|---|---|---|
| Overview | Perception を選ぶと既定で開く | 入力待ちのセッション、エージェントの活動量、推奨プレイブック、セッションの状態、エージェント別のパフォーマンスを見る。「新しいセッション」もここから |
| 新しいチャット | Perception → 新しいチャット | 自然言語で依頼する。適切なプレイブックの選択と入力の事前設定は Perception がやる |
| セッション | Perception → セッション | 全エージェントのセッションを、かんばんまたは一覧で見る。承認要求への応答、成果物の確認、停止もここ |
| エージェント | Perception → エージェント | 「セットアップの準備完了」と「使用中」に分かれる。ID・権限・関連プレイブック・最近の活動を確認し、セットアップ（要セキュリティ管理者）をする |
| プレイブック | Perception → プレイブック | 説明、エージェント数、必要な入力、トリガー種別の一覧。選んでセッションを開始する |
| インシデント | Defender のインシデントキュー、インシデントページ | Triage Agent の結果が出る場所（後述の画面例）。インシデントのページからセッションを起動することもできます |
各ページの詳細は、Learn の概要とナビゲーション、チャット、セッション、エージェント、プレイブックにあります。
利用開始の 3 経路とセットアップ手順
利用開始の経路は、チャット（自然言語で依頼する一番手軽な方法）、エージェント（ID と権限を自分で設定し、手動またはトリガーで動かす）、プレイブック（複数のエージェントを順に動かす一連のワークフロー）の 3 つです。チャットを使う場合も、最適な体験のために、少なくとも 1 つのエージェントを設定済みにしておくよう Learn は勧めています。エージェントを設定して動かす流れは次のとおりです。
- Microsoft Defender ポータルにサインインし、ナビゲーションで Perception → エージェント を開きます
- 「セットアップの準備完了」の欄で、有効にしたいエージェントの「セットアップ」を選びます。この操作には Entra ID のセキュリティ管理者ロールが必要です
- ウィザードが Entra エージェント ID を自動で作ります。エージェントの詳細ページに表示される最低限の権限を割り当てます
- スコープ付きリソースへのアクセスをエージェント ID に与えます。Defender for Endpoint のデバイスグループを使っているなら、手動で紐付けます
- 「セットアップの終了」を選ぶと、エージェントが使用中の一覧に移ります
- エージェントの詳細ページから「新しいセッション」を開始します。プレイブックごとに必要な入力（インシデント ID、TI 記事の URL、Azure サブスクリプションなど）を渡します。インシデントや TI 記事のページから起動することもできます
- セッションの状態が「入力の待機中」になったら、承認・拒否・別の提案を選びます。Threat Intelligence Agent は、最初にタスク計画の承認を求めて一時停止します
- 完了後は、セッションの成果物に出る Markdown のレポートを確認します。レポートとして出てくる KQL（Kusto Query Language）のハンティングクエリは、Defender ポータルの Advanced hunting で実行できます。本番で実行する前に、テスト環境で検証するよう Learn は求めています
セッションを開始するにはセキュリティ閲覧者以上のロールが要り、セットアップと削除はセキュリティ管理者の仕事です。最初のエージェントには、Learn が Threat Intelligence Agent か Triage Agent を勧めています。権限が限られていて、すぐ効果が見えるためです。
画面のイメージ
手順 6 の「プレイブックから開始」は、Learn の画面例だとこうなります。Recon Agent で絞り込んだ一覧には、プレイブック名・説明・使うエージェント数・必要な入力・トリガー（ここでは Manual）が並びます。
出典: Recon エージェント（Learn）。画面は英語です
プレイブックを選ぶと、開始前の確認ダイアログが開きます。Azure サブスクリプションとマネージド ID の 2 つが必要な入力で、使われるエージェント（ここでは Recon Agent、発行元は Microsoft）が下に出ます。確認して「Start session」を押すとセッションが始まります。
出典: Recon エージェント（Learn）。入力欄は Learn 側でぼかされています
Recon Agent を Azure 視点で見る
Azure の環境を見る立場だと、6 つのうち一番関係が深いのは Recon Agent です。ID・RBAC・ネットワーク露出の組み合わせから攻撃パスを組み立てるので、私はセキュリティ面のアーキテクチャレビューに近い仕事だと見ています。
侵害済みと仮定した分析
Microsoft Security Exposure Management は、インターネットに公開された資産・重要なリソース・機密性の高い ID を起点に、攻撃パスを継続的に洗い出します。起点の条件を満たさない資産や ID からの攻撃パスは、通常は生成されません。
Recon Agent は、Azure サブスクリプション内の任意の資産・ID を起点にできます。重要資産や機密 ID としてマークされていなくても構いません。「攻撃者がこの資産や ID をすでに制御しているなら、次にどこへ行けるか」に答えます。Learn が挙げる例は、フィッシングで機密 ID としてマークされていないユーザーが侵害されたケースです。Exposure Management ではそのユーザーからの攻撃パスが出ないことがあり、Recon Agent はそのユーザーを起点に横展開の経路を出せます。
Azure の資産に置き換えたイメージは次のとおりです（私の想定例です）。
侵害された一般ユーザー
→ ユーザーが触れるマネージド ID
→ サブスクリプションの RBAC ロール
→ Key Vault
→ 本番 VM
Learn によれば、出力には攻撃パスのグラフに加えて、MITRE ATT&CK（攻撃者の戦術と手法を整理したナレッジベース。日本語の解説）へのマッピング、既存の Defender 検出でカバーされていない攻撃パスの指摘（カバーされている場合は関連アラートと KQL のハンティングクエリ）が含まれます。加えて Learn は、最も多くの攻撃パスを中断できる最小の変更セット（チョークポイント）の特定も、Recon の用途として挙げています。調査結果には証拠の強さを示す「確認」「可能性」「推論」のラベルが付きます。
セッションの画面は次のようになります。左がエージェントとの会話で、攻撃パスごとに CONFIRMED（確認）や LIKELY（可能性）、INFERRED（推論）が付いた説明が流れます。右の Overview には、入力と、Credential・Data Plane・Identity・Workload・Choke Points・Fingerprint の Markdown ファイル 6 本が出力として並んでいます。
出典: Recon エージェント（Learn）。画面は英語で、環境固有の値の多くは Learn 側でぼかされています
読み取り専用で、実際には攻撃しない
名前は Red Team ですが、Recon Agent は読み取り専用の評価を出すだけです。公式は、脆弱性の悪用、ペイロードの実行、リソースの変更、検出のデプロイ、攻撃グラフの保持、組織外での動作は行わないと明記しています。結果は特定時点のスナップショットで、継続監視の代わりにはなりません。
前提条件と権限
Recon Agent を使うには、次の 4 つが必要です。
- Microsoft Entra ID P2
- Microsoft Defender XDR
- Microsoft Defender for Cloud の Defender CSPM プラン
- Azure サブスクリプション
エージェントの ID には、Microsoft Entra Agent ID が使われます。セットアップウィザードが ID を作り、そこへ追加で次の権限を与えます。
| 付与する権限 | 内容 | 付与する人に必要なロール |
|---|---|---|
| Microsoft Graph アプリケーション権限（8 個） |
User.Read.All、Organization.Read.All、GroupMember.Read.All、Application.Read.All、DelegatedPermissionGrant.Read.All、Policy.Read.All、RoleManagement.Read.Directory、AuditLog.Read.All
|
特権ロール管理者（Entra ロール） |
| Azure RBAC（サブスクリプションスコープ） | 閲覧者、Key Vault 閲覧者、Log Analytics 閲覧者、セキュリティ閲覧者 | 対象サブスクリプションの RBAC 管理者 |
Learn の「Recon エージェントを設定する」の節に、この割り当てを行う PowerShell スクリプトも載っています。Graph の権限 8 個はすべて読み取り系で、Azure のロールも閲覧系です。
余談: エージェント ID とエージェント ユーザー ID
Recon の Learn ページには「Recon エージェントは、エージェント ユーザー ID ではなくエージェント ID を使用します」とあります。先に結論を書くと、Perception のエージェントが使うのは左列の エージェント ID です。セットアップ手順はどのエージェントも、ウィザードが新しいエージェント ID を作る流れです。
Entra Agent ID には 2 種類の ID があり、役割が違います。右列は Entra 側のドキュメントでは「エージェントのユーザー アカウント」という名前で、Recon のページの「エージェント ユーザー ID」はこれを指すと私は読みました。
| エージェント ID | エージェントのユーザー アカウント | |
|---|---|---|
| Perception での扱い | こちらを使う。セットアップウィザードが作る | Recon では使えない（技術的な制限として Learn に明記） |
| 位置づけ | AI エージェントが認証とリソースアクセスに使う主な ID | エージェント ID と 1 対 1 で対応する、省略可能なユーザー オブジェクト |
| 認証 | 自前の資格情報はなく、エージェント ID ブループリント（エージェント ID のテンプレートと認証基盤になる Entra のオブジェクト）が発行するトークンで認証する | パスワードやパスキーは持てず、親のエージェント ID を通じてだけ認証する |
| 向く場面 | ログ監視のように、バックグラウンドで独自の ID を使って自律的に動く | メールボックス、予定表、Teams など、ユーザー オブジェクトが必要なリソースを使う。ライセンスも割り当てられる |
| 作成 | ブループリントから作られる | 自動では作られず、明示的な作成が必要。ライフサイクルは管理者が管理する |
Recon が使うのはエージェント ID です。Learn が挙げる理由は、現在の技術的な制限により、エージェント ユーザー ID が Recon の読み取り専用操作をサポートしていないことです。
エージェントのユーザー アカウント（Learn）とEntra Agent ID の基本的な概念（Learn）に、ブループリントや所有者・スポンサーの説明もあります。
セッションは 1 つのサブスクリプションに限られます。ID リスクの評価では、管理者がセットアップ時に構成した一覧からだけ選べます。攻撃パスの特定では、サインインしたユーザーが使えるサブスクリプションがピッカーに出て、開始時にそのユーザーの読み取り権限が確認されます。使えるプレイブックは「ID リスクを評価する」「攻撃パスを特定する」「脅威から保護する」の 3 つです。
Triage Agent の対象と前提
Triage Agent は、サポート対象のアラートが作られると自動で動きます。判定は真陽性または偽陽性で、偽陽性なら解決し、真陽性ならインシデントを開いたままアナリストに渡します。判定の理由は、インシデント側に自然言語とグラフで残ります。
Triage Agent の結果は、Perception だけでなく Defender の通常のインシデント画面にも出ます。インシデントキューの上部に、エージェントが扱えるインシデントのうち処理した数（画像では 30 日間で 150/200 件）と「Manage agent」のリンクが出て、一覧には Agent タグが付いたインシデントが並びます。
出典: トリアージ エージェント（Learn）。画面は英語です
インシデントを開くと、右側の Tasks ペインに Triage Agent の判定が出ます。画像では「True positive として分類・解決」という結果と、その理由（コンテナーでの暗号マイニングや資格情報の窃取の試みなど）が自然言語で書かれ、「Change classification」で分類を変えられます。
出典: トリアージ エージェント（Learn）。画面は英語です
押さえておく点は次のとおりです。
- 対象は Defender のアラートの一部です。メールとコラボレーション、クラウド（コンテナーを含む）、ID、エンドポイント、クラウドアプリのアラートが対象で、種類ごとに必要な製品とライセンスが違います。たとえばメールのアラートには Defender for Office 365 プラン 2、ID のアラートには Entra ID P2 と Defender for Identity と Defender for Cloud Apps が必要です
- 自動解決してしまうチューニングルールで解決済みになったアラートは、対象外です。前提条件では、該当するルールを無効にするよう求められています。FAQ には組み込みルールはセットアップで無効化されるとあり、カスタムルールは自分で確認する必要がありそうです
- アナリストのフィードバックを学習する機能は、現時点ではメールとコラボレーションのアラートだけです
- 既存の Phishing Triage Agent は Perception の Triage Agent を設定すると置き換わり、実行履歴・メトリック・設定は引き継がれます。同時に有効にできる Triage Agent は 1 つです
SOAR との違いについて、Learn は、SOAR が定義済みルールのワークフローに依存するのに対し、Triage Agent は推論ベースの分析でトリアージして Defender に分類を記録すると説明しています。既存の調査・対応ツールを置き換えるものではなく、Defender で定義された権限とワークフローの中で動きます。
Posture Prioritization Agent の使い方と制限
体制の問題が大量に出ているとき、何から直すかを決めるエージェントです。使い方は 2 通りあります。脅威の入力なしで全体を見る「態勢の修復計画」と、脅威インテリジェンスの記事 URL・脅威アクター名・CVE などを渡して絞り込む「脅威から保護する」です（入力例は Learn のシナリオ節の記述で、開始手順には脅威インテリジェンスの記事とだけあります）。
プレビュー期間中は読み取り専用で、環境の変更や修復の適用はしません。Learn のエージェントページでは、対象はクラウド資産とデバイスに重点が置かれ、使うシグナルは Defender の環境にあるものだけです。サードパーティの CSPM データや外部ソースは未サポートです。前提は Microsoft 365 E5 と、Defender for Cloud の Defender CSPM です。
同じ入力でも結果が実行ごとに変わることがあり、それは推奨が間違っているという意味ではない、とも書かれています。
人が承認する仕組み
Perception は、実行前に人が判断する前提で作られています。エージェントが承認や追加情報を必要としたとき、セッションは「入力の待機中」に変わります。承認が要る操作の例として、Learn はユーザーアカウントの無効化とデバイスの分離を挙げています。
承認要求には、アクションの説明、影響評価、そのアクションを勧める理由が付きます。人ができる操作は 4 つです。
- 承認: エージェントが続行する
- 拒否: 提案をスキップさせる。理由の入力は任意ですが、Learn は具体的に書くことを勧めています
- 別の提案: 「ユーザーを無効にせずデバイスを隔離する」のように別のやり方を指示する。エージェントが実現可否を評価し、可能なら新しい影響評価つきで再度承認を求める
- 停止: セッションを終了する。元に戻せず、再開もできません
Learn のベストプラクティスには、承認要求に素早く応答すること、拒否するときは具体的な理由を書くこと、頻繁に拒否するならエージェントの設定を見直すこと、成績の良いエージェントは承認ゲートを減らす検討をすることが並んでいます。承認が止まっている間はエージェントも止まるので、運用では「入力の待機中」のセッションを見落とさない仕組みが要りそうです。
Security Copilot との関係
Learn から確認できる範囲では、Perception と Security Copilot は関わりが深いです。Triage Agent は Microsoft Defender XDR や Microsoft Threat Intelligence などの Security Copilot プラグインを自動で有効にします。エージェントに付ける権限にも「Security Copilot (読み取り)」が含まれます。
Perception 側は、目標に向けて複数のエージェントが順に進める作業単位（セッション）が中心だと私は読みました。Defender ポータルでは、Perception の下に概要・新しいチャット・セッション・エージェント・プレイブックが並びます。チャットで「このインシデントを調査して」と書くと、Perception が適切なプレイブックを選び、入力を事前設定して実行します。
MAI-Cyber-1-Flash と MDASH
MDASH は、Command Line のインタビューで Microsoft Security の Taesoo Kim 氏が「マルチエージェント・マルチモデルの脆弱性発見・修復エージェント」と説明しているものです。リポジトリから脆弱性を見つけ、修正案を出します。100 以上の専門エージェントが動き、見つけた脆弱性を、開発者役と攻撃者役のペルソナが議論して検証します。
From research to reality（Command Line）
Perception との関係について、同氏は次のように述べています。MDASH は Perception のごく初期の段階に差し込める。リポジトリ内の潜在的な脆弱性を見つけて Perception に渡すと、Perception は実際のデプロイ環境にそれが存在するか、ネットワークトポロジーも含めて確かめる。MDASH の情報は Perception にとって、信頼度が高く精度の高いシグナルの 1 つになる。
役割分担を表にします。
| 要素 | 役割 |
|---|---|
| MAI-Cyber-1-Flash | Microsoft の特化型サイバーモデル |
| MDASH | 複数モデルでコードを調べ、脆弱性を発見・検証するエージェントシステム |
| Perception | 環境全体のセキュリティコンテキストで、リスクの有無・優先度・対応までを扱うシステム |
公式ブログによると、MAI-Cyber-1-Flash は最初の適用先として MDASH に組み込まれました。MDASH に組み込んだ構成で、業界ベンチマーク CyberGym の any-crash スコアが 96%、現行の MDASH 構成に比べて約 50% のコスト削減とされています（公式はリーダーボードでも Mythos などを上回ると述べています）。any-crash は、評価対象のコードをクラッシュさせる入力を、既知・未知（0-day）を問わずどれか 1 つでも見つけられれば成功とみなす指標です。この 96% は MDASH に組み込んだ構成の CyberGym 上の数字で、Perception 全体の性能を示す数字ではありません。今後は脆弱性管理以外のセキュリティワークフローにも MAI-Cyber-1-Flash を使う予定と書かれています。
Azure の人に関係するのは、MDASH の接続方法です。Security Exposure Management の Agentic コード スキャナーとして使うとき、利用者自身の Microsoft Foundry リソースにモデルをデプロイします。
Codename MDASH 向けに Microsoft Foundry を設定する（Learn）
- デプロイするのは
gpt-5.4、gpt-5.3-codex、gpt-5.4-miniの 3 つです。MAI-Cyber-1-Flash は、この 3 つに加えてデプロイする構成（プレビュー）として載っています - 各デプロイの TPM（1 分あたりのトークン数）のレート制限を 1,000,000 以上にします。同時スキャンを使うなら 5,000,000 以上です
- コンテンツフィルターは、セキュリティ関連の内容が有害と誤分類されてスキャンが漏れないよう、最小のしきい値にします。この設定を他のワークロードと共有しないよう、MDASH 専用のエンドポイントを使うとも書かれています
コスト
Perception の料金は、今回確認した Perception の Learn ページ（概要、使ってみる、トリアージ、Recon など）には、2026/10/05 時点で記載がありません。金額の目安は示せないので、費用に関わる要素を公開情報から 4 つに分けて整理します。
- 前提ライセンス: 前述の表のとおり、Microsoft 365 E5、Entra ID P2、Defender CSPM、Defender for Office 365 プラン 2 などがエージェントごとに必要です。すでに持っているライセンスで足りるかで、追加費用が大きく変わります
- Security Copilot の SCU 容量: Triage Agent などは Security Copilot のプラグインを自動で有効にし、Learn のメタデータ上も一部のページは Security Copilot のコレクションに含まれています。Triage Agent の FAQ には、管理者が容量の消費量を構成できるとあります。Security Copilot 側のドキュメントでは、Microsoft 開発のエージェントの実行が SCU を消費します。Perception のセッションでも同じ容量の仕組みを使うかは、見積りの際に最初に聞いておきたいポイントです
- SCU の課金モデル: Security Copilot の資料では、Microsoft 365 E5 で対象になる顧客は既定の容量が自動でプロビジョニングされます。E5 以外の顧客は、まずプロビジョニング容量（時間単位で課金）を確保する必要があり、急な増加に備えて、使った分だけ課金される「超過容量」を任意で追加できます
- MDASH を使う場合: モデルを利用者自身の Foundry リソースにデプロイし、TPM の枠を確保します。モデル利用料の課金先も、見積りの際に合わせて聞いておくと安心です
Security Copilot の SCU と容量（Learn）
見積りの前に聞くことは、Perception の課金単位、SCU 容量を使うかどうか、プレビュー期間中の扱いの 3 つです。窓口は Microsoft の営業担当か、公式の最新の案内です。
試す前の注意点
- 提供状態: 発表時の公式ブログは「8 月 3 日にパブリックプレビューへ入る」と書いていますが、Learn の各ページは 2026/10/05 時点で Limited Public Preview と明記しています。対象は招待された少数の顧客です
- AI の出力: Recon Agent のレポートには「AI によって生成されたコンテンツが正しくない可能性があります」と表示され、修復計画やリスク報告に使う前に結果の確認が必要だと書かれています
- ID と RBAC: エージェント ID は、スコープ付きリソースへのアクセスを自動では継承しません。ロールの割り当てだけでは足りず、Defender for Endpoint のデバイスグループは手動でエージェント ID を紐付けます。アナリストよりエージェントのスコープが狭いと、セッションが失敗するか不完全な結果になります
まとめ
Perception の核は、赤・青・緑のエージェントが同じ Security Context を共有して動く点にあると私は読みました。Azure の構成を見る立場なら Recon Agent が近い入口ですが、Learn が最初のエージェントに勧めているのは Threat Intelligence Agent と Triage Agent です。
大きな絵としては、攻撃側が AI で攻撃を速く安く作れるようになり、守る側も AI で対抗する AI 対 AI の構図になっています。公式ブログも、Perception を AI で AI から守る仕組みと位置づけています。MDASH の Kim 氏は、リリース前に脆弱性を潰し切れるなら、守る側が勝てるかもしれないと話しています。Perception は、その守る側の AI を、赤・青・緑のエージェントとして束ねたものだと私は見ています。
その流れで、セキュリティ運用は、人がツールを操作して調べる形から、エージェントが調べて提案し、人が承認する形へ動いていくと思います。そうなると Azure の運用側では、エージェントにどこまでの権限を渡すかという ID と RBAC の設計が、これまで以上に効いてくると思います。
参考
- Project Perception とは（Learn）: 概要、3 カテゴリ、プレビュー状態
- Project Perception の主要な概念（Learn）: セッション、エージェント、プレイブックの一覧
- Project Perception のエージェント カテゴリ（Learn）: 6 エージェントの役割と連携
- Project Perception を使ってみる（Learn）: 利用開始の 3 経路、ID と権限のセットアップ
- Recon エージェント（Learn）: 前提条件、権限、レポート
- トリアージ エージェント（Learn）: 対象アラート、前提、フィードバック
- 姿勢の優先順位付けエージェント（Learn）: シナリオとプレビュー制限
- エージェント作業を承認、拒否、または停止する（Learn）: 承認フロー
- Project Perception のアプリケーション カード（Learn）: 対象ユーザー、制限事項、データ処理場所
- Security Copilot の SCU と容量（Learn）: SCU の課金モデル
- Codename MDASH 向けに Microsoft Foundry を設定する（Learn）: MDASH の Foundry 設定
- Rethinking security for the age of AI（The Official Microsoft Blog）: 発表内容、6 層スタック、MAI-Cyber-1-Flash
- From research to reality（Command Line）: MDASH と Perception の関係