これまでのAIセキュリティは、要するに「賢いアラート機」でした。ログを読み、怪しい兆候を見つけ、担当者に「調べてください」と通知する——判断と行動は、あくまで人間の側に残っていた。2026年夏、その前提が崩れつつあります。AIエージェントが自ら調査し、優先順位を付け、（承認のもとで）修復まで踏み込む。セキュリティは「通知するAI」から「行動するAI」へと軸足を移しました。
homula はエンタープライズ向けのAIエージェント・インテグレーターとして、この「行動するAI」を業務にどう組み込むかを日々設計しています。本稿では、その号砲となった Microsoft の新発表を起点に、行動するエージェントを企業が安全に動かすために「最初に置くべき制御点」を実務目線で整理します。
何が起きたか——Microsoftが「Project Perception」を公開プレビュー
Microsoft は2026年7月27日にエージェント型セキュリティ基盤 Project Perception を発表し、8月3日に公開プレビューを開始しました。提供形態は Microsoft Defender の中に組み込まれる形です（Microsoft Security、The Next Web）。
特徴は、単一の万能AIではなく役割の違う複数エージェントの分業で成り立っている点です。
| エージェント | 役割 | 従来の担い手 |
|---|---|---|
| Red（攻撃） | 攻撃経路と脆弱性をマッピングし、どこが突かれ得るかを洗い出す | レッドチーム／ペンテスター |
| Blue（防御） | 検知結果を調査し、何が「意味のあるリスク」かを判断・優先順位付け | SOCアナリスト |
| Green（修復） | 是正措置を取り、防御を固める（重要な操作は人間の承認が前提） | インシデント対応・IT運用 |
これらをオーケストレーター・エージェントが差配し、エージェント間はメッセージバスで文脈を受け渡します。IDとガバナンスは Microsoft の「Agent 365」で扱い、影響の大きい操作にはプレビュー段階で人間の承認を必須とする設計です。Microsoft は、こうした一連のワークフローが専門家の約146時間分の作業を圧縮すると説明しています。
あわせて、初のサイバーセキュリティ特化モデル MAI-Cyber-1-Flash も投入されました。総パラメータ1,370億・アクティブ50億のスパースMoEで、脆弱性解析システム MDASH に組み込むと、業界ベンチマーク CyberGym のスコアが88.4%から95.95%へ向上し、しかも運用コストは約半分だとされています（MarkTechPost、Help Net Security）。
これはMicrosoftだけの話ではない——「エージェント型SOC」という潮流
Microsoft の発表が象徴的なのは、それが業界全体の地殻変動の一角だからです。RSAC 2026 以降、CrowdStrike（複数エージェントによる「Agentic Security Workforce」）、Palo Alto Networks、Cisco、SentinelOne、Google、AWS といった主要各社が、こぞってエージェント型のセキュリティを打ち出しています。エージェント型セキュリティは、もはや差別化要因ではなく「あって当然」の水準に近づきつつあります。
この新しい形は「エージェント型SOC（Agentic SOC）」と呼ばれます。定義はシンプルで、アラートの分類（トリアージ）→調査→封じ込め→修復→ケース管理という一連のライフサイクルを、自律エージェントが機械速度で回し、重要な判断だけ人間が承認するというものです。
ポイントは「全自動」ではなく「分業と段階化」にあります。アラートの選別や調査の下ごしらえは自動化しつつ、マシンの隔離のような可逆的な操作、ホストへのパッチ適用のような不可逆な操作は、リスクに応じて人間の承認の下に置く。エージェント型SOCは一足飛びの全自動ではなく、低リスクのトリアージから段階的に踏み込む「多年度の旅」として設計されます。
なぜ「役割分担」なのか——単一エージェントでは回らない
ここで見落とされがちなのが、なぜ各社が判で押したように複数エージェント＋オーケストレーター＋専用モデルという構図に収束したのか、という点です。
第一に、タスクの性質がまるで違うからです。攻撃経路の探索（発散的な思考）と、リスクの選別（収束的な判断）と、修復操作の実行（副作用を伴う行動）では、求められる振る舞いも、許してよいミスの種類も異なります。一つのプロンプトに全部を詰め込むと、どの局面でも中途半端になります。
第二に、行動には文脈の受け渡しが要るからです。「調べた結果」が「直す判断」に、ハンドオフの度に人手を挟まず流れていく必要がある。だからメッセージバスとオーケストレーターで、発見が"そのまま"修復につながる回路を作る。
第三に、専用モデルの効き所です。MAI-Cyber-1-Flash が示したのは、汎用の大型モデルを漫然と使うより、ドメイン特化の軽量モデルを要所に据えたほうが、精度もコストも改善するという事実でした。これは業務エージェント全般にも通じる設計原則です。
落とし穴——「行動するAI」に企業が置くべき制御点
行動するエージェントは強力ですが、「通知するAI」の失敗と「行動するAI」の失敗は、被害の重さが桁違いです。誤検知の通知は無視すれば済みますが、誤った修復は本番環境を止めます。導入前に、次の制御点を先に設計しておくべきです。
- 行動の可逆性で線を引く：読み取り・調査は自動、可逆的な操作（隔離・一時遮断）は条件付き自動、不可逆な操作（削除・パッチ適用・権限変更）は人間の承認を必須にする。承認ゲートをどこに置くかは、モデルの賢さではなく「取り返しがつくか」で決める。
- エージェントIDと最小権限：どのエージェントが、誰の権限で、何をしてよいのか。人間と同じくエージェントにもIDを与え、RBAC で権限を絞る。「つながる」ことと「実行してよい」ことは別物です。
- 全操作の監査ログ：誰が（どのエージェントが）何を要求し、どの権限で、承認されたか——end-to-end で記録し、後から追跡・分析できる状態にする。規制対応（2026年8月2日にEU AI法の透明性義務やAI OfficeによるGPAI提供者への制裁権限が適用開始）を待つまでもなく、行動するAIの前提条件です。
とりわけ危険なのが、行動するエージェントとプロンプトインジェクションの組み合わせです。攻撃者が仕込んだ入力を"指示"と誤認したエージェントが、実際の是正操作を実行してしまえば、防御装置がそのまま攻撃面になります。行動系のエージェントほど、入力の信頼境界と承認ゲートを厳格にすること。関連する設計は「『許可リスト』では意図を守れない」「無人で走るAIエージェントの秘密管理」も参照してください。
homulaの観点——「通知から行動へ」は、セキュリティだけの話ではない
エージェント型SOC が突きつけている本質は、実はセキュリティに限りません。業務エージェントもまた、答えを返すだけの段階から、承認や監査を伴って実際の業務操作を行う段階へ移りつつあります。請求処理、契約更新、在庫調整——「行動するAI」を業務に置くとき、必要になる制御点は SOC の議論とほぼ同じです。
homula は、この二段構えを分けて設計することを勧めています。
- 接続と実行は Agens で共通化する：Agens は MCP を活用したエンタープライズ向け統合プラットフォームで、200以上のツールと構築ゼロで接続します。まず「エージェントが何につながれるか」を一元化する。
- 統制は Agens Control で一点に集約する：承認フロー・DLP・5年分の監査ログ・RBAC を提供します。可逆／不可逆の線引き、エージェントIDと最小権限、全操作の記録——本稿で挙げた制御点を、業務エージェントに対して実装する層です。
- 実装は段階的に：homula は n8n / Dify / LangGraph などで役割分担型のマルチエージェントを実装し、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化までを一気通貫で支援します。まず低リスクのトリアージ的タスクから自動化し、承認ゲート越しに行動の範囲を広げる。業務の棚卸しから始めたい場合は、AIエージェント・ブートキャンプ（3〜5日）が入口になります。
モデルの賢さは、もはや各社横並びの前提条件です。差がつくのは、どの行動を自動化し、どの行動を人が承認し、すべてをどう記録するかという統制設計のほうにあります。
まとめ
2026年夏、Microsoft の Project Perception を号砲に、セキュリティのAIは「通知」から「行動」へと動きました。攻撃・調査・修復を役割分担し、オーケストレーターが差配し、重要な操作は人間が承認する——このエージェント型SOCの構図は、そのまま業務エージェントの設計図でもあります。
行動するAIを安全に走らせる鍵は、より賢いモデルではありません。可逆性による承認ゲートの線引き、エージェントIDと最小権限、そして全操作の監査ログ。この三点を「先に」置いた企業だけが、エージェントに仕事を任せながら、取り返しのつかない失敗を避けられます。
「行動するAI」を、統制を効かせながら業務に組み込みたい方へ。homula が承認・監査・権限の設計から実装までを伴走します。