AIを内部者として扱う|Microsoftの統制4責務

Microsoftが2026年10月19日、AIエージェントを社内の内部者として扱うセキュリティ機能を公開。権限ゼロ起点の付与とClaude Code等60種の検出が柱です。製品を待たずに要件へ落とす4責務を整理します。

AIエージェントを社内の内部者として扱う統制のイメージ

Microsoftが2026年10月19日、AIエージェントを「社内の内部者」として扱うセキュリティ機能を公開しました。中心にあるのは、エージェントに人の権限を借りさせるのをやめ、権限ゼロから始めてタスク単位・時間制限つきで渡すという設計です。提供時期も価格も未公表のため今すぐ買える話ではありませんが、発注側が自社の要件に落とすべき論点は今日から整理できます。この記事では、発表内容を要件定義の言葉に翻訳します。

Microsoftは「エージェント的な内部者」という枠組みを打ち出した

Microsoftは2026年10月19日、セキュリティ基盤「Project Perception」を、社内で動くAIエージェント(agentic insider)の保護へ拡張すると発表しました。執筆者はIdentity and Network Access担当コーポレートバイスプレジデントのNadim Abdo氏です。

発表の出発点は、AIエージェントが悪意を持つという話ではありません。Microsoft Security Blogの原文は、エージェントは有能な道具であり、間違えることも、操作されることも、侵害されることもある、と整理しています。そのうえで掲げている原則が「非決定的な知能を、決定的な統制・独立した証跡・封じ込め境界で囲む」です。

今回公開された主な機能は次の6つです。

名称内容
Dynamic Permissionsエージェントに権限ゼロから、タスク単位・時間制限つきで権限を渡す
Dynamic Agent RiskID・データ・エンドポイント・クラウド・ネットワーク・ランタイム・エージェントの活動からリスクを継続的に更新する
Dynamic Conditional AccessMicrosoft Entra Conditional Access をエージェント向けに拡張。段階的に権限を絞る
Guardian AgentsProject Perception 内のエージェント群。証跡の調査・封じ込めの推奨と適用・ポリシー強化を機械速度で行う
ローカルエージェントの検出拡張35種類を追加し合計60種類に対応。Claude Code・OpenAI Codex・GitHub Copilot を名指し
Microsoft Entra Agent ID の拡張ローカルや未知のエージェントにもIDタイプを追加し、統合レジストリに取り込む

ランタイムの隔離には、サンドボックスである Microsoft Execution Container(MXC)が位置づけられています。エージェントや実行基盤が侵害されても、監視している統制そのものを無効化できないようにする、という考え方です。

「Know・Contain・Protect・Adapt」は、そのまま自社の要件になる

Microsoftは、エージェントを守るシステムが継続的に果たすべき責務を4つ挙げています。この4つは製品名ではなく、どのベンダーに発注する場合でも要件として使えます。

責務問い自社で決めること
Know(把握する)どのエージェントが存在し、誰が所有し、なぜ存在し、何をしているかエージェントの台帳を誰が持つか。登録せずに使える抜け道を残さない
Contain(限定する)行動する前に、何にアクセスでき何ができるか読み取りだけ/書き込みあり/承認必須、の3段階を業務ごとに割り当てる
Protect(守る)経路上のデータ・ツール・ランタイム・資源をどう守るかエージェントが触れる社内データの機微度を分類しておく
Adapt(適応する)挙動・文脈・リスクの変化に、どう保護を追随させるか異常時に誰が止めるか、止める前に何を自動で絞るかを決める

Microsoftは「これらは4つの製品でも順番に進める段階でもなく、同時に働く」と書いています。実務の言葉にすれば、台帳だけ作って権限設計を後回しにする、あるいは権限は絞ったが異常時の対応が人手の調査待ちになっている、という状態ではどちらも効かないということです。

Know・Contain・Protect・Adaptの4責務が循環する構造図

権限ゼロ起点は、「人の権限を借りる」設計からの転換

今回の発表で実務への影響が最も大きいのは Dynamic Permissions です。エージェントが依頼者である従業員の権限をそのまま引き継ぐ従来の形をやめ、エージェント自身のIDに対して、承認されたタスクに必要な分だけを、必要な期間だけ渡します。

Microsoftは「従業員は従業員のアクセスを保持する。エージェントは自身のID・権限と、現在のタスクに限定されタスクの期間だけ有効な権限を受け取る」と説明しています。組織全体のポリシーが外枠となり、利用者本人が持たない権限をエージェントが獲得することも防ぎます。

観点従来(人の権限を借りる)Dynamic Permissions
権限の出発点依頼者の持つ権限すべてゼロ。承認されたタスクに必要な分だけ
有効期間依頼者の在籍期間に準じるタスクの期間のみ。完了・変化で縮小または剥奪
影響の大きい操作依頼者の権限で実行できてしまう検証済みの人間承認を要求できる
監査の単位人の操作とエージェントの操作が混ざるエージェント固有のIDで分離して追える
異常時の対応アカウント停止という二択になりがち読み取りは残して書き込みを遮断、資源を絞る等の段階的対応

Dynamic Conditional Access の応答が二択ではなく段階的である点も重要です。権限の削減、読み取りを残した書き込みの遮断、到達できる資源やネットワーク経路の絞り込み、時間制限アクセスの短縮や取り消し、証明可能な人間承認の要求、そして最高リスク時のランタイム隔離・実行停止まで、強度の違う手が並んでいます。経費承認エージェントが外部文書のプロンプトインジェクションに遭遇した場合、承認と書き込みだけを止めて参照は残す、という対応が取れる設計です。

権限ゼロから必要な分だけ渡し、リスクに応じて段階的に絞る流れの図

Claude Code・Codex を含む60種の検出は「見えていない利用」への対応

Microsoftはローカルで動くエージェントの検出対象を35種類追加し、合計60種類に広げました。名指しされているのは Claude Code、OpenAI Codex、GitHub Copilot です。

この拡張が示しているのは、エージェントが中央の導入プロセスを経ずに現場の端末へ入ってくる現実です。Microsoftは、エージェントは自社プラットフォームで作られるほか、パートナーのプラットフォームやSDK経由で統合され、あるいは中央の配備プロセスなしにローカルで導入されうる、と書いています。検出されたエージェントは統合レジストリに取り込まれ、Microsoft Entra Agent ID によってポリシーの適用対象になります。

経営・DX担当者にとっての意味は明確です。開発部門が個人の判断で入れたコーディングエージェントも、統制の対象として数える前提に変わります。シャドーITの議論がシャドーエージェントに移った、と言い換えてもよい状況です。

提供時期も価格も未公表、という前提を外さない

今回の発表で注意すべき点は、各機能の提供開始日・プレビューと一般提供の区分・価格・ライセンス要件が、いずれも公式ブログに書かれていないことです。

確認範囲を明示します。Microsoft Security Blog の当該記事本文を全文取得して確認したところ、”preview”、”pricing”、”license”、”E7″ のいずれの語も本文中に出現しませんでした。一部の海外メディアは今回の機能を「Microsoft 365 E7 向け」と報じていますが、The Next Web は同時に「提供時期も、Microsoft 365 E7 のライセンスに追加費用がかかるかどうかも、Microsoftは明らかにしていない」と書いています。

Microsoft 365 E7(The Frontier Suite)自体は、2026年3月9日にMicrosoftが発表し、2026年5月1日に一般提供が始まった1ユーザーあたり99ドルのSKUで、Microsoft 365 E5・Microsoft 365 Copilot・Agent 365 などを束ねたものです。今回の新機能がこのSKUの範囲で使えるのか、追加費用が要るのかは、2026年10月23日時点で確認できません。

したがって、この発表を根拠に予算を確保するのは時期尚早です。Microsoft Ignite(2026年11月17〜20日)で続報が出る可能性はありますが、現時点では内容は未発表です。

製品を待たずに、今日決められる4項目

Microsoftの製品提供を待つ間にも、発注側として決めておける論点があります。どのベンダーを選ぶ場合でも必要になる項目です。

1. エージェントの台帳を誰が持つか決める

まず「社内で何が動いているか」を1枚にします。業務部門が導入したものだけでなく、開発者が個人の判断で入れたコーディングエージェントも対象です。台帳の項目は、エージェント名・所有者・用途・アクセスする先・停止する責任者の5つで足ります。

2. 権限を「読み取り/書き込み/承認必須」の3段階に割り当てる

いきなりタスク単位の動的な権限制御は組めません。まず業務ごとに、エージェントに許す操作を3段階のどれかに割り当てます。承認必須にする操作を決めておくと、将来どの製品を選んでもその定義がそのまま使えます。AIエージェントの権限をどう設計するかは「AIエージェントの権限管理|野良化を防ぐ3つの設計変数」でも整理しています。

3. 異常時に「段階的に絞る」手順を書く

アカウント停止しか手がない状態だと、小さな異常でも業務が止まります。読み取りは残して書き込みだけ止める、特定のデータへの到達だけ遮断する、といった中間の手を自社の手順書に用意しておきます。エージェントが想定外の動きをした実例は「AIが検証環境を脱出|OpenAI報告が示す統制4つの穴」で扱っています。

4. エージェント固有のIDを要件に入れる

人のアカウントを使い回す運用では、「人がやったこと」と「エージェントがやったこと」を分けて追えません。ベンダー選定の際、エージェントに固有のIDを発行できるか、その単位で監査ログを取れるかを確認項目に入れておきます。エージェントのID・委任の考え方は「MCPがAPIキー依存を脱する|発注前に効く4つの問い」で解説しています。

よくある質問

今回発表された機能は、いつから使えますか。

2026年10月23日時点で提供開始日は公表されていません。Microsoftの公式ブログには、プレビューと一般提供の区分・価格・ライセンス要件の記載がありません。Microsoft Ignite(2026年11月17〜20日)での続報を待つ段階です。

Microsoft製品を使っていない企業にも関係がありますか。

関係があります。Know・Contain・Protect・Adapt の4責務は特定の製品に依存しない要件で、どのベンダーに発注する場合でも、エージェントの台帳・権限の限定・異常時の段階的対応として自社の要件に落とせます。

既存のID管理(IAM)と何が違いますか。

人のアカウントに権限を紐づけるのではなく、エージェント自身のIDに、承認されたタスクの分だけを期間限定で渡す点が異なります。異常時の対応も停止の二択ではなく、書き込みだけ遮断するといった段階的な絞り込みになります。

社内のAIエージェント統制は何から着手すべきですか。

エージェントの台帳づくりからです。何が動いているかを把握しないと、権限設計も異常時の手順も作れません。業務部門の導入分だけでなく、開発者がローカルで使っているコーディングエージェントも対象に含めてください。

まとめ

Microsoftが2026年10月19日に公開したのは、AIエージェントを社内の内部者として扱い、権限ゼロから始めてタスク単位・時間制限つきで渡し、リスクの変化に応じて段階的に絞るという設計です。ローカルエージェントの検出対象は35種類追加されて合計60種類となり、Claude Code・OpenAI Codex・GitHub Copilot が名指しされました。一方で提供時期も価格も未公表であり、現時点では購買判断の材料にはなりません。

Auto-IDフロンティアとしては、この発表を「待つべき製品ニュース」ではなく「要件定義のたたき台」として使うことを勧めます。Know・Contain・Protect・Adapt の4責務は、どのベンダーに発注する場合でも共通の確認軸になります。

AI導入の進め方全体は「AI導入支援|中小企業の進め方と支援会社の選び方」、発注前に確認する具体的な基準は「AI導入支援会社の選び方|発注前に確認する7つの基準」で解説しています。

次のアクションは1つです。社内で動いているAIエージェントを、所有者と用途とアクセス先を付けて書き出してください。1枚の表ができれば、権限の3段階割り当ても、異常時の手順も、ベンダーへの確認事項も、そこから順に決まります。

社内のAIエージェント統制をどう設計するか、どこまで自社で決めてどこからベンダーに任せるかを整理したいという方は、AI導入相談フォームからご相談ください。

出典・参考資料

CONTACT

記事を読んで、自社ではどうか気になったら

一般論ではなく、御社の業務に当てはめて一緒に考えます。
まずは無料相談からどうぞ。

無料で相談する 1分でAI活用度診断 →
無料相談する 1分でAI診断