Microsoftが2026年8月3日、AIエージェントによるセキュリティ運用システム「Project Perception」の公開プレビューを開始した。攻撃側を模倣する「Red」、脅威を調査する「Blue」、防御を強化する「Green」という3種類のエージェントが連携し、脆弱性の発見から修復までを継続的に回す仕組みだ。同時に発表された専用モデル「MAI-Cyber-1-Flash」は、脆弱性評価ベンチマーク「CyberGym」で高スコアを記録している。
「AIエージェントをどう設計すれば、権限を絞りつつ自律性を発揮させられるのか」は、セキュリティ領域に限らず多くの開発チームが直面する課題だ。Project Perceptionはこの課題に対する大手ベンダーの回答の一つとして、設計面で参考になる部分が多い。この記事では発表内容を整理したうえで、AIエージェントを設計する開発者が読み取れるポイントを解説する。
そもそもProject Perceptionとは何か
Project Perceptionは、Microsoft Defenderに組み込まれる形で提供される、複数のAIエージェントが連携して動くセキュリティシステムだ。Microsoft公式ページでは「a new agentic security system designed for the realities of AI. It turns signals into real-time protections using AI to defend against AI」と説明されている。組織のセキュリティシグナル・ツール・ワークフローを横断的に読み取り、ギャップの可視化・脅威調査・修復までを継続的に行う点が特徴だ。
Microsoft Learnのドキュメントでは「a new multi-agent security system designed for the realities of AI」と定義されており、2026年7月27日に発表、8月3日から公開プレビューとしてMicrosoft Defenderポータル上で利用できる。
何が新しいのか — Red/Blue/Greenの3役割
Project Perceptionの核は、役割の異なる3種類のエージェントを連携させる設計にある。公式ドキュメントの定義は次の通り。
| エージェント区分 | 役割 |
|---|---|
| Red team agents | 攻撃者が悪用する前に、侵害経路や脆弱性を洗い出す |
| Blue team agents | 検知した内容を調査・トリアージし、重大なリスクかどうかを判断する |
| Green team agents | 修復措置を実行し、防御体制を強化する |
この3種のエージェントが一方向のパイプラインではなく、発見・評価・改善を繰り返す「クローズドループ」として動く点がポイントだ。単発のスキャンツールとは異なり、Red agentsが見つけた弱点をBlue agentsが優先順位付けし、Green agentsが直した結果を再びRed agentsが検証する、という循環が継続的に回る設計になっている。
どう動くのか — 「playbook」という仕組み
Microsoft Learnの公式解説によると、Project Perceptionは「playbook（プレイブック）」という単位でエージェントを動かす。playbookは特定のセキュリティ成果を得るための再利用可能なテンプレートで、複数の専門エージェントに目標を割り当て、ワークフロー全体でその行動をオーケストレーションする。原文では次のように説明されている。
“A playbook assigns a team of specialized agents a set of objectives and orchestrates their actions throughout the workflow. Each agent has a distinct role, but they work together by sharing intelligence, findings, and security context to drive coordinated defense.”
加えて、エージェントは判断が必要な場面で人間に承認を求める設計になっており、担当者は進行中・完了済みのセッションを監視し、行動を承認・却下したり、セッションを止めたりできる。自然言語でタスクを指示する「Chat」機能もあり、内容を伝えると適切なplaybookを自動で選び、入力値を事前に埋めた状態で実行してくれる。
この「目標を割り当てられた専門エージェントのチームが、共有コンテキストを介して連携し、要所で人間の承認を挟む」という設計は、セキュリティに限らず汎用的な考え方だ。以下は、この設計思想を一般化したイメージを疑似コードにしたもの（Microsoftの実際のAPI・SDKではなく、設計パターンを理解するための概念コード）。
# 概念コード: playbook型のマルチエージェント設計を一般化したイメージ
# 実際のMicrosoft APIではなく、設計パターンの理解用サンプル
class Playbook:
def __init__(self, name, objectives, agents):
self.name = name
self.objectives = objectives
self.agents = agents # 役割ごとに専門化したエージェントのリスト
self.shared_context = {} # 発見内容・調査結果を共有する領域
def run(self, approval_gate):
for agent in self.agents:
result = agent.act(self.shared_context)
self.shared_context.update(result.findings)
# 影響の大きい行動は人間の承認を必須にする
if result.requires_approval:
approved = approval_gate.request(agent.role, result.proposed_action)
if not approved:
agent.log("承認が得られず処理を停止")
continue
agent.execute(result.proposed_action)
# 使用例: 脆弱性の発見→評価→修復を1つのplaybookとして定義
vuln_playbook = Playbook(
name="脆弱性の発見と修復",
objectives=["攻撃経路の洗い出し", "リスク評価", "修復パッチの適用"],
agents=[red_agent, blue_agent, green_agent],
)
vuln_playbook.run(approval_gate=HumanApprovalGate())
ポイント: 重要なのは「エージェントを役割ごとに分割する」ことよりも、「発見・評価・改善の結果を1つの共有コンテキストに集約し、影響度の高い行動だけを人間承認のゲートに通す」という設計の方だ。全行動を人間承認にすると自律性のメリットが消え、逆に全自動化するとForrester等が指摘する「連鎖的な失敗」のリスクが高まる。承認が必要な行動の線引きをどこに置くかが、実運用での最大の設計判断になる。
専用モデルMAI-Cyber-1-Flashと「MDASH」の位置づけ
Microsoftは同日、脆弱性分析に特化したモデル「MAI-Cyber-1-Flash」も発表した。Microsoft公式ブログ（microsoft.ai）によると、GPT-5.4と組み合わせて「MDASH」（multi-agent vulnerability identification and remediation harness、脆弱性の特定と修復に特化した内部のマルチエージェント基盤）上で評価したところ、脆弱性評価ベンチマーク「CyberGym」で95.95%のスコアを記録した。比較対象となった他の4モデル構成は83.2%〜85.6%の範囲だったという。
公表資料では、この結果を「96% on CyberGym（Anthropicのフロンティアモデル群『Claude Mythos』比で+12ポイント）」とも表現しており、コスト面では従来Microsoftが使っていた構成（GPT-5.4＋5.4 mini＋5.3 Codexの組み合わせ）に比べて約50%削減できたとしている。CyberGymは、UC Berkeleyの研究チームが開発した評価基盤で、188件の実プロジェクトから抽出した1,507件の実在する脆弱性をもとに、AIエージェントが脆弱性を再現するプルーフオブコンセプトを生成できるかを測る仕組みだ。
MDASHは100以上のエージェントを動員して脆弱性の検出・検証・修復を行う基盤とされており、Microsoftは「Project Perceptionも今後、より多くのセキュリティワークフローでMAI-Cyber-1-Flashを利用する予定」としている。つまりProject Perceptionは、MDASHのような専用基盤やモデルを内部に取り込みながら拡張されていく設計になっている。
具体的に何ができるようになるのか
公式ドキュメントによれば、Project Perceptionの利用者は以下のような操作をMicrosoft Defenderポータル上で行える。
- エージェントの管理: 組織で有効化するエージェントの選択、役割・カスタム設定の変更、実行・閲覧できるユーザーの制御
- playbookによる委任: 定義済みのplaybookで自律実行を開始する、あるいはChatで自然言語のタスクを渡して該当するplaybookを自動選択させる
- 監督: 実行中・完了済みのセッションを監視し、行動の承認・却下、セッションの停止、代替方針の指示を行う
この記事の一次ターゲットである「AIエージェントを設計・導入する開発者」にとっての実務的なインパクトは、①脆弱性対応という高リスク領域でも、人間承認ゲートを挟めば自律実行を任せられるという実例が大手ベンダーから示されたこと、②「役割特化エージェント＋共有コンテキスト＋playbook」という構成が、社内向けの業務エージェント設計にもそのまま応用できる汎用パターンであることの2点だ。
AIエージェントを構築するツール自体の選定に迷っている場合は、AIエージェントツール比較完全ガイドで用途別の選び方を整理しているので、あわせて参照してほしい。
懸念点・注意が必要な点
発表を好意的に受け止める声がある一方、慎重な見方も出ている。調査会社Forresterは自社ブログで、デモやブログだけでは実際の制約条件（ビジネスコンテキストの欠如やコスト面）がわからないと指摘したうえで、「エージェントは非決定論的であり、複雑なアーキテクチャでは連鎖的な失敗（cascading failures）が起こりうる」と警告している。そのうえで、実運用に向けては次の3点を推奨している。
- 可観測性の確保: 問題発生時に何が起きたかを追跡できるログ・データの透明性
- 最小権限の原則: エージェントに与える権限を必要最小限に絞ること
- 適切なデータアクセス: エージェントが判断に必要な企業データへ、正しい形式でアクセスできること
Forresterは結論として「time and practitioner experience will tell（時間と実践者の経験が判断材料になる）」と述べており、現時点では実運用での検証が必要な段階だと位置づけている。公開プレビューという扱いであることからも、Microsoft自身、まだ実地での検証を積み上げている段階だと見るべきだろう。
よくある誤解
「Red/Blue/Greenのエージェントが完全に人手を代替する」と思われがちだが、実際には公式ドキュメントで「keeping humans firmly in control」と明記されており、影響の大きい行動は人間の承認を経る設計になっている。全自動の無人運用ではなく、人間の判断ポイントを残した「自律性の委任」という位置づけだ。
また「MAI-Cyber-1-FlashがそのままProject Perceptionの中核モデルである」というのも正確ではない。現時点でCyberGymのスコアはMDASHという脆弱性特定・修復専用の基盤上で計測されたものであり、Project Perception全体は今後段階的にMAI-Cyber-1-Flashを取り込んでいく計画とされている。両者を混同すると、性能評価の対象を取り違えることになる。
日本のAIエージェント開発者が学べる設計パターン
Project Perceptionの構成は、セキュリティ以外の業務エージェントを設計するときにも応用できる考え方が含まれている。
- 役割特化 × 共有コンテキスト: 1つの巨大なエージェントに全タスクを担わせるのではなく、役割ごとに専門化したエージェントを立て、発見内容や判断根拠を共有領域に集約する。役割の粒度が細かいほど、個々のプロンプトはシンプルに保てる。
- playbook＝再利用可能なワークフロー定義: 都度プロンプトを書き直すのではなく、「目的」「担当エージェント」「承認が必要な行動」をテンプレート化しておくと、同じワークフローを繰り返し安定して実行できる。
- 承認ゲートの粒度設計: 全行動を人間承認にすると自律化のメリットが消え、逆にゼロにするとForresterが指摘するような連鎖障害のリスクが上がる。「取り消しが難しい行動」「影響範囲が広い行動」だけをゲートに通す、という線引きの設計がボトルネックになりやすい。
マルチエージェントの設計パターン全般については、マルチエージェントの設計パターン3選｜失敗例と実装ガイド【2026】で失敗例とあわせて解説している。プロンプトインジェクション対策など、エージェントに権限を持たせる際に検討すべきセキュリティ対策はプロンプトインジェクション対策｜エージェント時代の多層防御5層【2026】にまとめている。
結局どうすればいいのか
Project Perceptionは2026年8月3日時点で公開プレビュー段階であり、日本国内での提供状況や料金体系については公式情報が明示されていない。まずは以下のアクションが現実的だ。
- 今すぐ: Microsoft Defenderを利用している組織は、管理コンソールでProject Perceptionのプレビュー提供状況を確認する。
- 今週中: 自社で構築中のAIエージェントに「playbook」「承認ゲート」の考え方を当てはめられないか、既存のワークフローを棚卸しする。
- 今月中: Forresterが指摘する「可観測性」「最小権限」「適切なデータアクセス」の3点を、自社のエージェント設計チェックリストに追加する。
よくある質問
Q. Project Perceptionとは何ですか？
MicrosoftがMicrosoft Defenderに組み込む形で提供する、複数の専門AIエージェントが連携して脆弱性の発見・調査・修復を継続的に行うセキュリティシステムです。2026年7月27日に発表され、8月3日から公開プレビューが始まっています。
Q. AIエージェントのセキュリティリスクとは何ですか？
権限が広すぎるエージェントが誤った判断で重大な操作を実行してしまうリスク、複数エージェントが連携する構成でのエラーの連鎖（Forresterが指摘する”cascading failures”）、プロンプトインジェクションによる意図しない挙動などが代表的です。Project Perceptionのように、影響の大きい行動を人間承認のゲートに通す設計が対策の一つになります。
Q. サイバーセキュリティにおけるAIエージェントとは何ですか？
攻撃経路の調査（Red）、脅威の調査・トリアージ（Blue）、修復・強化（Green）のように、セキュリティ業務の一部を自律的に担うAIエージェントを指します。Project Perceptionはこの3役割を組み合わせて、発見・評価・改善のループを継続的に回す設計を採用しています。
Q. MAI-Cyber-1-Flashとは何ですか？
Microsoftが発表した脆弱性分析に特化したAIモデルです。GPT-5.4と組み合わせてMDASH（脆弱性の特定・修復専用のマルチエージェント基盤）上で評価したところ、脆弱性評価ベンチマークCyberGymで95.95%のスコアを記録したと公表されています（2026年7月27日時点、Microsoft公式発表）。
Q. Project Perceptionは日本の企業でも使えますか？
2026年8月時点では公開プレビュー段階で、提供地域や料金についての詳細は公式資料に明記されていません。導入を検討する場合は、Microsoft Defenderの管理コンソールまたは担当営業窓口で最新の提供状況を確認してください。
Q. AIエージェントを完全に自動化しても大丈夫ですか？
Project Perceptionの設計は「人間を判断の中心に置いたまま自律性を委任する」考え方を採用しており、影響の大きい行動には人間の承認を求める仕組みになっています。Forresterも権限の最小化と可観測性の確保を推奨しており、現時点では全自動運用よりも承認ゲートを併用する設計が現実的です。
参考・出典
- Rethinking security for the age of AI — The Official Microsoft Blog（発表日: 2026-07-27、参照日: 2026-08-04）
- Project Perception | Microsoft Security — Microsoft公式製品ページ（参照日: 2026-08-04）
- What is Project Perception? | Microsoft Learn — Microsoft公式ドキュメント（更新日: 2026-07-31、参照日: 2026-08-04）
- Introducing MAI-Cyber-1-Flash inside MDASH — Microsoft AI公式ブログ（参照日: 2026-08-04）
- Microsoft’s Project Perception Announcement And How To Implement It Right — Forrester（参照日: 2026-08-04）
- CyberGym: Evaluating AI Agents’ Real-World Cybersecurity Capabilities at Scale — arXiv（参照日: 2026-08-04）
まとめ：今日から始める3つのアクション
Project Perceptionは、セキュリティという高リスク領域でAIエージェントに自律性を持たせるための設計を、大手ベンダーが具体的な形で示した事例だ。「役割特化エージェント＋共有コンテキスト＋承認ゲート」という構成は、業務エージェントを設計するチームにとっても再利用できる考え方が多い。Forresterが指摘するように、この種のシステムは実地での検証を積み上げていく段階にあり、日本の開発チームも動向を追いながら自社の設計に取り込んでいくのが現実的だろう。
- 今日やること: 自社のAIエージェント設計を「役割特化」「共有コンテキスト」「承認ゲート」の3観点で棚卸しする
- 今週中: 影響の大きい操作だけを人間承認に通すルールを、既存のエージェントワークフローに明文化する
- 今月中: Forresterが推奨する可観測性・最小権限・適切なデータアクセスの3点をチェックリスト化し、社内のエージェント導入基準に反映する
あわせて読みたい:
- マルチエージェントの設計パターン3選｜失敗例と実装ガイド【2026】 — 役割分担・失敗パターンを実装レベルで解説
- AIエージェントを守るセキュリティツール4選比較2026 — 他ベンダーのセキュリティツールとの比較
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー10万人超）。100社以上の企業向けAI研修・導入支援を展開。著書累計3万部突破。
AIエージェントの権限設計・承認フロー・社内導入ルールをどう設計すればいいか悩んでいる方へ
UravationではAIエージェント導入の研修・コンサルを行っています。ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
