速報

Firefoxが不正な証明書への対策を追加!OneCRL配信が届かない端末も更新を確認

CATEGORY

MicrosoftがAIエージェントの監督を拡張!検出・権限調整・実行時保護の確認点

※本ページのリンクにはプロモーションが含まれています。

AIエージェントの検出と独立した監督設定、読み取りの継続と書き込みの一時停止を表す緑背景のフラットな概念イラスト

目次

Microsoftは2026年10月19日、Project Perceptionを、企業内で動くAIエージェントの監督へ拡張する考え方と機能を発表しました。AIが作業を進める間にリスクを継続評価し、その時点で許す操作を調整することが中心です。

Web開発やサイト運用で注目したいのは、使い始めの許可設定から一歩進み、実行中の変化に対応する点です。外部資料を読んだ後で作業が逸れた場合にも、読む操作を残しながら書き込みを制限するといった段階的な対応を想定しています。

発表日は10月19日、この記事の情報確認日は日本時間10月20日です。以下では、提供元が説明する新しい仕組み、公式対応表から分かる条件、本サイトが提案する導入判断を整理します。性能や防御効果を本サイトで実測した記事ではありません。

スポンサーリンク

変化したのは作業中のリスクを制御へつなぐ部分

Microsoftは、モデル、処理を組み立てる仕組み、利用するツール、実行環境を含めてエージェントを管理する必要があると説明しています。Project Perceptionでは、複数の観測情報を集め、リスクを評価し、監督するGuardian Agentsなどの仕組みへ結び付ける構想を示しました。

本サイトの見方では、ここでの判断材料は「AIを監視するAIが増えた」という名前よりも、観測した変化をどの操作の制限へ反映できるかです。ログを集めるだけの場合と、書き込みなどの実行条件を変えられる場合では、導入で得られる範囲が異なります。

Microsoft公式ブログ:Securing the agentic insider(2026年10月19日)

固定権限と毎回の全停止の間にある選択肢

10月19日の技術説明では、Dynamic Permissions、Dynamic Agent Risk、Dynamic Conditional Accessを紹介しています。作業に必要な期間と範囲の権限を与え、リスクの変化に応じて縮小し、必要な操作では人の承認を求めるという説明です。

その中には、読み取りを維持しながら書き込みを止める、到達できるデータやネットワーク経路を絞る、実行環境を隔離するなどの段階が含まれます。これらはMicrosoftが示す機能・設計の説明で、あらゆる連携先に同じ制御が自動適用されると確認したものではありません。

Microsoft Security Blog:社内AIエージェントの監督拡張(2026年10月19日)

スポンサーリンク

検出できるエージェントと保護できる操作を分けて読む

Microsoft Learnの対応表は、ローカルAIエージェントの検出と実行時保護を分けて記載しています。OSや連携方法の要件が異なり、表にない組み合わせは、現時点で対応が文書化されていないという扱いです。

Windowsの検出欄にはCodex CLI、Codex Desktop、Claude Codeなどが載っています。一方、実行時保護は別の表です。検出欄のチェックを見て、自社の全ツール呼び出しが遮断対象になると解釈すると、保護範囲を広く見積もることになります。

対応表ではmacOSの検出とWSLの検出にプレビュー表記があり、Windowsの実行時保護もプレビューです。WSLでの対応はネイティブLinux端末への対応を意味しないと説明されています。制作端末と本番Linuxサーバーを同じ条件として計画しないことが必要です。

Microsoft Learn:Defender for EndpointのAIエージェント対応表

インストール一覧と活動の検出は目的が異なる

同じ公式対応表によると、検出は管理対象端末上の活動を観測して行われます。インストール済みだから必ず一覧に現れるという仕組みではありません。また、実行時保護の対応が記載されていても、それだけで端末上の保護が有効になっているとは限りません。

ここからは本サイトの提案です。試験導入では、製品名、CLIや拡張機能などの形態、OS、使用モード、MCPの接続方法を一組にして記録します。「Codexを使っている」「Claudeを入れている」という申告だけでは、対応表のどの行を確認すべきか決まりません。

資産台帳と検出結果に差がある場合も、すぐに不正利用と判断しないでください。まだ動かしていない、対象端末の登録が済んでいない、対応していない形態を使っているなどの条件を確認します。見つからないことを利用がない証拠へ置き換えない運用が必要です。

スポンサーリンク

Agent IDの利用と追加の保護機能には条件がある

Entra Agent IDの公式概要は、エージェント向けの識別子を作成・管理する基盤を説明しています。Agent IDはMicrosoft Entraの顧客が利用できるとする一方、エージェントへEntraのセキュリティ機能を拡張するにはMicrosoft Agent 365が必要としています。

同資料は、Agent 365がMicrosoft 365 E7に含まれ、指定された既存プラン等への追加としても提供されると説明しています。識別子を作れることと、必要な監督機能の利用条件を満たすことは、見積もりで別々に確認してください。

本記事では地域別の価格や、新機能一式の日本向け一般提供日を確定していません。発表日を導入可能日として扱わず、契約する販売元へ、対象テナント、提供段階、必要ライセンス、利用するOSと実行形態をまとめて照会することを提案します。

Microsoft Learn:Microsoft Entra Agent IDの概要と利用条件

Web運用の試験なら一つの実行経路から始める

説明用の仮想例として、問い合わせ内容を分類し、CMSの返信案を作るエージェントを考えます。正常時には問い合わせの閲覧と下書き保存だけを許し、外部送信や権限変更は作業に含めない構成です。今回のMicrosoft製品を実際に設定した例ではありません。

試験では、分類中に予定外の送信操作を要求した場合、どの仕組みが何を観測し、どの境界で止めるかを確かめます。モデルが「中止します」と文章で答えることと、実際の送信経路が拒否することは、別の検証項目です。

最初からすべての開発者ツールへ適用するより、利用する端末、エージェント、接続先を一組に絞ると、観測漏れと誤検知の原因を特定しやすくなります。この小さな経路で有効な制御を確認してから、他の組み合わせへ広げることを提案します。

導入前に作るのは操作ごとの確認表

各操作について、利用目的、必要な権限、観測できる出来事、制限を実行する場所、解除を判断する担当を整理します。閲覧、下書き作成、公開、外部送信では、失敗時の影響も、止めた後の業務も異なります。

例えば、リスクが上がったときに下書き保存を止め、資料の閲覧を残す設計を採るなら、保存先が本当に変更を受け付けないことを確認します。別のAPIや人のアカウントへ切り替えることで同じ処理が続かないかも、自社で許可した環境で検証します。

この確認表は製品の設定を推測して補うものではありません。提供側の対応範囲と、自社の実行経路を照合するための資料です。機能が未対応なら、作業を限定する、別の境界で拒否する、導入を保留するなど、判断を明示できます。

段階的な制限では継続させる作業も試験する

制限が強すぎると、正当な業務まで止まります。継続監督の評価では、危険な操作を拒否する試験に加え、予定どおりの閲覧や下書き作成が続けられるかも確認します。止まる件数だけでは、導入の効果を判断しにくくなります。

本サイトでは、検知までの時間、制限が反映されるまでの時間、許可される操作、保留される操作、復旧に要した手間を記録することを提案します。本記事に共通の目標秒数は設けていません。扱う情報と業務が許容できる遅れに応じて決めます。

誤検知の解除には根拠と期限を残します。通知が多いから監督を広く無効にする運用へ流れないよう、調整対象のルールと影響するエージェントを限定して変更します。変更後に正常な作業と拒否対象の両方を再確認してください。

スポンサーリンク

モデルの説明だけでは検証できない部分を残さない

Microsoftは、モデルの透明性が監督の判断材料を増やすという方向性にも言及しています。ただし、本サイトの提案としては、モデルが述べた理由だけに依存せず、ツールへ渡された要求、認可の結果、実際の変更、外部サービスの結果を照合します。

監督対象のエージェントが、自分を監督する設定や記録を変更できないことも、構成の確認点になります。業務用の実行権限と、監督方針の変更権限を同じ接続へまとめないよう、管理する担当者と経路を確認します。

記録へ会話やファイルを無制限に複製すると、監督のための保存先にも情報管理が必要になります。何を集め、誰が読めて、どれだけ残すかを決め、試験には架空データを使います。詳細な思考の取得を、基本的な実行結果の確認の前提にする必要はありません。

費用はライセンスと運用負担の両方で比べる

見積もりには、契約費用に加えて、端末の登録、ログの保存・調査、ルールの調整、例外の承認、更新時の再検証を含めることを提案します。製品を買った後に担当不明となる作業がないか、運用部署と開発側で確認します。

すでにMicrosoftの端末管理やID管理を使う組織と、小規模な制作チームでは導入の前提が違います。自社の主要なエージェントと接続先を保護できる範囲、既存環境との重複、必要な担当時間を比較し、機能名の数だけで選ばないことが大切です。

今回の発表から見るべき動向は、AIの利用状況を把握する段階から、作業中の権限を変える運用へ対象が広がっていることです。採用判断では、自社の組み合わせに対応するか、制限を実際に反映できるか、正規の業務を続けられるかを、小さな試験で確かめてください。

スポンサーリンク

参考資料

Microsoft公式ブログ:Securing the agentic insider(2026年10月19日)

Microsoft Security Blog:社内AIエージェントの監督拡張(2026年10月19日)

Microsoft Learn:Defender for EndpointのAIエージェント対応表

Microsoft Learn:Microsoft Entra Agent IDの概要と利用条件

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
PHP8技術者認定ウィザード
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

スポンサーリンク

関連する記事

おすすめの書籍

キーワードから探す