Microsoftは2026年10月19日、AIエージェントを「agentic insider（エージェント内部者）」と捉え、Project PerceptionにGuardian AgentsとPlaybooksを導入すると発表しました。
AIエージェントは企業データ、アプリケーション、ツール、他のエージェントにアクセスし、機械速度で動きます。利用者の権限をそのまま与えると、変化する行動やリスクを抑えきれません。
Project Perceptionは、エージェントを個別のIDと権限を持つ管理対象として棚卸しし、リスクに応じて読み取り、書き込み、承認、実行を段階的に制御します。なお、同機能は2026年10月28日時点で限定公開プレビューです。
※本記事は2026年10月28日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
Project Perception｜AIエージェントを「内部の人」とみなす
従業員が操作するソフトウェアは、決められた画面や手順の範囲で動く設計が一般的でした。AIエージェントは、受け取った文脈や外部データによって計画を変え、複数のツールを呼び出しながら仕事を進めます。意図どおりに始まった処理でも、途中で別の行動に移ることがあります。
Microsoftはこの性質を、エージェント固有の内部者リスクとして整理しました。悪意のあるプログラムに限った話ではありません。誤り、操作、侵害によって、正規のアクセスを持つエージェントが想定外の操作をする可能性があるためです。
Project Perceptionは、ID、権限、データ、エンドポイント、ネットワーク、クラウド、ランタイムのシグナルを横断して扱います。責任は「存在と所有者を把握する」「行動の前に範囲を抑える」「経路上の資源を守る」「行動とリスクの変化に合わせて保護を変える」の4つです。
4つの責任は、棚卸し、権限付与、監視、停止を順番に一度だけ行う仕組みではありません。証拠がリスクを変え、リスクがポリシーを変え、ポリシーがエージェントの行動範囲を変える循環として設計されます。
ポイント
エージェントを「人が使う機能」ではなく、企業システム上で判断と操作を行う別の主体として定義すると、監査・権限・停止条件を設計しやすくなります。
60種類のローカルエージェント｜検出した後に個別IDを付ける
Microsoft Securityは、ローカルエージェントの検出対象を35種類追加し、合計60種類に拡大しました。対象にはClaude Code、OpenAI Codex、GitHub Copilotが含まれます。
ここで見るべきなのは、検出数の多さだけではありません。AIエージェントはMicrosoftの管理画面から作成されるとは限らず、パートナー製品、SDK、端末上のローカルツールとして導入されます。申請されたエージェントだけを管理する方法では、実際の利用状況と台帳の一致を保てません。
Microsoftは、発見したエージェントを統合レジストリに集め、所有者、活動、リスクを把握する構成を示しています。さらに、利用者やスポンサーとは別のファーストクラスIDをエージェントに付与します。Microsoft Entra Agent IDを、ローカルエージェントやセンサーが見つけた未知のエージェントにも広げる考え方です。
個別IDがあれば、「誰が操作したか」だけでなく「どのエージェントが、誰の依頼で、どの権限を使ったか」を分けて記録可能です。非人間IDの棚卸しと権限管理については、非人間IDの管理も参考になります。
台帳には、所有者、目的、実行端末、接続するツールやMCPサーバー、扱うデータ、終了条件を記録します。シャドーAIエージェントへの対応では、検出から統制までの運用を先に決めます。
ポイント
60種類への拡大は、導入済み製品の一覧を増やす話にとどまりません。端末に存在するエージェントを見つけ、所有者と個別IDを結び付けることが統制の出発点です。
Dynamic Permissions｜ユーザーの権限をそのまま渡さない
エージェントを発見してIDを付けても、実行環境とアクセス経路が広ければ被害範囲は縮まりません。Microsoftは、モデルとハーネスを端末の完全な権限から切り離し、制御されたランタイムで動かします。
Microsoft Execution Container（MXC）のようなサンドボックスは、タスクに必要な資源へのアクセスをポリシーで制御し、監視と強制の境界を作ります。エージェントやハーネスが侵害されても、監視機構を自分で無効にできない位置に置く設計です。実行環境の詳しい考え方は、Microsoft Execution Containers（MXC）の記事をご覧ください。
呼び出し先も限定対象です。エージェントが任意のツール、API、MCPサーバー、データ資源、別のエージェントへ接続できる状態を避け、ローカル、ネットワーク、データの制御で呼び出しを仲介します。宛先だけでなく、入出力の内容や出所、信頼できないデータが行動に影響していないかも見ます。
Dynamic Permissionsでは、組織ポリシーが上限を決め、エージェントは承認済みタスクに必要な権限だけを、必要な期間に限って受け取る仕組みです。ユーザーが持つ常時権限を自動的に引き継がせず、タスクの変化や完了時には権限を縮小・削除する設計です。高い影響を持つ操作には、人の承認を挟んでください。
ポイント
「ユーザーと同じ権限」ではなく、タスク・時間・操作種別でエージェントの権限を分けます。ランタイム、ツール、データ経路を別々の境界として設計してください。
Dynamic Agent Risk｜停止だけに頼らず、リスクに合わせて制限する
最小権限でも、タスクの途中で危険性は変わります。たとえば外部文書にプロンプトインジェクションが含まれていた場合、設定は同じでも、エージェントの行動や到達先が変わる可能性があります。人がすべてのシグナルを調べてから対応する運用では、機械速度の処理に間に合いません。
Dynamic Agent Riskは、ID、データ、エンドポイント、クラウド、ネットワーク、ランタイム、エージェント自身の活動からシグナルを集めます。構成の安全性、到達可能な資源、失敗時の影響、ユーザーや組織の意図からのずれを見て、リスクと現在の権限が合っているかを継続的に更新します。
リスクが上がったときの対応は、実行を続けるか停止するかの二択ではありません。Dynamic Conditional Accessは、権限を縮小し、読み取りを残したまま書き込みを止めます。データや資源、ネットワーク経路の限定、期限付きアクセスの短縮、人の承認、ランタイムの隔離、実行停止も段階的に適用する仕組みです。
この設計なら、危険な書き込みだけを止めながら安全な読み取りを続ける判断ができます。逆に、隔離や停止へ移す条件も定義できます。企業側は、リスク指標の名前だけを採用するのではなく、業務影響、証跡、復旧手順まで一つのルールにまとめる必要があります。
運用ログを集めるだけでは、対応の遅れは解消しません。検知、原因調査、権限変更、承認、復旧を同じタイムラインで追える状態を作ります。可観測性や評価を運用に組み込む方法は、AgentOpsの考え方ともつながります。
ポイント
リスク対応はキルスイッチだけにしません。書き込み停止や経路限定、人の承認、隔離を段階化し、どの証拠で次の段階へ移るかを業務ごとに決めます。
Guardian AgentsとE7｜自動化する範囲と人の判断を分ける
Guardian Agentsは、エージェントを監視する別のエージェント群です。Project PerceptionのPlaybooksは、望ましいセキュリティ結果を定義します。Guardian Agentsはリスクの変化を調べ、封じ込めを提案または適用します。得られた知見はポリシーの強化につなげます。
ただし、目的、承認境界、委任ルール、重大な判断を人から切り離す設計ではありません。Microsoftの説明では、人が目的と重大な判断を保持し、手作業では継続できない調査や保護の実行をGuardian Agentsが担います。自動化の範囲を先に決めることが前提です。
ライセンスの整理も必要です。Agent 365はMicrosoft製・第三者製エージェントの管理・統制を担う集中管理プレーンです。対象となるMicrosoft 365サブスクリプションと組み合わせて利用する単体サブスクリプションで、Microsoft 365 E7にも含まれます。E7またはAgent 365が必要な機能には、活動の可視化・監視、ツールアクセス制御、エージェント向け条件付きアクセス、監査ログ、DLPなどがあります。
一方、Project Perceptionそのものは、2026年10月28日時点でLimited Public Previewです。Learnでは、Security AdminがエージェントのIDや権限を設定し、Security Readerがセッションを閲覧・開始する役割分担が示されています。E7を契約すればProject Perceptionのプレビューが無条件に一般提供される、という意味ではありません。
| 対象 | 最初に決めること | リスク上昇時の対応 | 人が保持する判断 |
|---|---|---|---|
| 従業員アカウント | 職務と常時権限 | 条件付きアクセス、利用停止 | 業務上の責任と承認 |
| AIエージェント | 個別ID、タスク、実行範囲 | 書き込み停止、経路限定、隔離 | 目的、所有者、例外承認 |
| Guardian Agents | ポリシー、Playbook、委任境界 | 調査、封じ込め提案・適用 | 重大操作の承認と結果責任 |
導入前には、エージェント台帳、権限の初期値、書き込みと承認の境界、リスク上昇時の段階、ログ保存期間、例外の責任者を決めます。限定公開プレビューでは、低リスクの読み取り処理から自動化の範囲を評価しましょう。
ポイント
E7やAgent 365は管理・可視化のライセンス判断、Project PerceptionはGuardian Agentsを含むセキュリティ運用のプレビューとして整理します。製品名より先に、誰が何を止めるかを決めることが導入の条件です。
よくある質問
Q. Project Perceptionは一般提供されていますか？
2026年10月28日時点ではLimited Public Previewです。招待制の限定公開プレビューとして提供されています。
Q. Guardian Agentsは人の代わりに重大な判断をしますか？
いいえ。人が目的、承認境界、委任ルール、重大な判断を保持し、Guardian Agentsは調査や封じ込めなど継続的な作業を担います。
Q. AIエージェントにユーザーと同じ権限を与えてよいですか？
ユーザーの常時権限をそのまま渡さず、タスクに必要な権限だけを必要な期間に限って付与します。高い影響を持つ操作には人の承認を設定してください。
Q. Microsoft 365 E7とAgent 365はどのような関係ですか？
Agent 365は、対象となるMicrosoft 365サブスクリプションと組み合わせて利用する単体サブスクリプションです。Microsoft 365 E7にも含まれます。E7またはAgent 365が必要な管理・監視・統制機能があります。
まとめ
MicrosoftのProject Perceptionは、AIエージェントを企業内の新しい内部者として捉えます。Guardian Agentsによる継続監視と、ID・権限・実行環境・データ経路の外部制御を組み合わせる構想です。エージェントの数が増えるほど、個別のアラートを人が処理するだけでは運用が回りません。
自社で始めるなら、まずローカルを含むエージェントの台帳を作り、個別IDと所有者を割り当てます。次に読み取り・書き込み・承認を分け、リスクが上がったときの段階的な制限と、人が必ず判断する操作を定義してください。
ポイント
AIエージェントの導入判断は、モデルの性能だけで決まりません。誰が監視し、どの証拠で権限を変え、どの操作に人の承認を残すかまでを一つの運用として評価します。
関連記事
- AIブラウザのプロンプトインジェクションを解説｜構造的なリスクと対策
- 非人間IDを解説｜AIエージェントの権限管理と監視のポイント
- シャドーAIエージェント対策を解説｜検出・統制の進め方
- Microsoft Execution Containers（MXC）を解説｜AIエージェントをOSで閉じ込める仕組み
- AgentOpsを解説｜AIエージェントの可観測性・評価・監視のポイント
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。