社内AIエージェントが増えすぎる前に：Microsoft Agent 365から学ぶガバナンスの型

社内AIエージェントのガバナンス概要

社内AIエージェントのガバナンスは、 台帳・権限・監査ログの3点セット から始めます。禁止令でも完璧な管理システムでもなく、「何が動いているか」を可視化し、責任者を明確にし、変更を追跡できる状態にすることが出発点です。

情シスが「さてガバナンスを考えよう」と思っていた時点で、現場はすでに動き出しています。問いは「許可するか禁止するか」ではなく、 「止めずにどう統制するか」 です。

このガイドでは、エージェント乱立に伴う3つの問題を整理したうえで、Microsoftがその解決策として構築した統制の仕組みを参照モデルとして紹介します。そのうえで、どのプラットフォームでも応用できる統制の型を示します。

この記事でわかること

エージェント乱立で起きる問題は「責任の所在」「権限の乖離」「データ経路の不可視化」の3つに集約されます
Microsoftは「Administering and Governing Agents」ホワイトペーパー（v3.2）とMicrosoft Agent 365（2026年5月GA）で、インベントリ・権限・ライフサイクルの3要素による統制基盤を確立しました
同様の統制を実現するための最小単位は5項目のエージェント台帳（目的・権限・データ・オーナー・停止条件）です
台帳の技術的フィールドはプラットフォームAPIから自動取得し、ガバナンスフィールドは人間が入力する「ハイブリッド台帳」が取り組みやすいアプローチです
90日ロードマップで「現状把握→台帳整備→統制定着」の順に進めます

エージェント乱立で起きる3つの問題

乱立自体が問題ではありません。乱立した状態で「誰も全体を把握していない」ことが問題です。実際に起きることは次の3つに集約されます。

責任の所在が消える

「そのエージェント、誰が作ったんですか？」——この質問に誰も答えられない状況が起きます。

エージェントは作成者が部門内でシェアすると、その後は作成者の関与なく動き続けます。作成者が異動・退職しても、エージェント自体は稼働を続けます。オーナーシップが引き継がれなければ、誰も「止める権限も、止める判断もできない」状態が生まれます。インシデントが発生しても調査の起点が定まらず、「どこから手をつければいいか」がわからないまま時間が過ぎます。

Microsoft環境での例: Copilot Studioで作成されたエージェントは、テナントのCopilotクレジットを消費して動作します（「Copilot Studio licensing」）。データへのアクセスには「エンドユーザー認証」と「作成者の共有コネクション（maker-provided credentials）」の2通りがあり、後者を採用した場合は作成者の認証情報がエージェントに埋め込まれた状態になります。作成者が退職してもエージェントは稼働を続けますが、埋め込まれた認証情報は無効化も更新もされないまま残ります。

オーナー不在のエージェントが外部APIへのデータ送信を続けているケースは珍しくありません。発覚が月次のネットワークログレビュー時になるのが典型例で、エージェント自体は数ヶ月前に作成されていてもオーナーが異動・退職していれば調査の起点が定まらず、対応に余分な工数がかかります。

権限が実態と乖離する

現場がエージェントに権限を付与する際、「動けば十分」という判断で業務スコープより広い権限を渡しがちです。一度付与した権限はガバナンスがなければ棚卸しされず、実態と乖離したままになります。エージェントは「必要以上にできる状態」で動き続けることになります。

Microsoft環境での例: Microsoft Agent 365では、エージェントに独自のEntra ID（Microsoftのクラウド認証・ID管理基盤）が割り当てられるようになりました。これは権限管理を明確にする仕組みですが、同時にそのEntra IDが誰の管理下にあるかを組織として定義しなければ意味をなしません。「エージェントのアカウントはあるが、誰も棚卸しをしていない」状態が新たに生まれます。

データの流れが見えない

エージェントが複数のシステムをまたいで動くと、どこからどこにデータが流れたかが見えなくなります。コンプライアンス監査でも情報漏洩の事後調査でも「調べようがない」状態になります。監査ツールが存在していても、それが正しく設定・運用されていなければ機能しません。ツールがあることと、それが機能していることは別の話です。

Microsoft環境での例: エージェントがSharePointのドキュメントを参照し、外部SaaSに書き込み、Teamsにサマリーを投稿するケースで考えると、このデータ経路を追跡するにはMicrosoft Purview（データガバナンス・コンプライアンス管理ツール）が必要です。しかし、管理者がPurviewのポリシーを設定し保持期間を定義した状態でなければ、監査ログは機能しません。

MicrosoftはAIエージェントをどう統制しているか

これらの3つの問題に対して、Microsoftは体系的な統制の仕組みを構築しています。2026年5月にGA（一般提供）されたMicrosoft Agent 365と、同時期に更新された「Administering and Governing Agents」ホワイトペーパー（v3.2）が、その全体像を示しています（「Microsoft Agent 365 Now Generally Available」、「Microsoft 365 E7 and Agent 365 are now generally available」）。

統制の基本思想：インベントリ・権限・ライフサイクルの3要素

ホワイトペーパーが整理するエージェントガバナンスの3要素は次のとおりです。

1. インベントリ（全エージェントの可視化）: すべてのエージェントを単一のインベントリに記録することを最初のステップとして明示しています。記録項目は「目的・プラットフォーム・アクセススコープ・オーナーシップ」の4点です。Microsoft 365管理センターにはこのインベントリに対応するInventory・Monitoring・Securityの3レポートが統合されており、テナント上のエージェントを一覧・分析できます。

2. 権限（最小権限原則の徹底）: Microsoft Agent 365では各エージェントにEntra IDが割り当てられ、エージェントを「人」と同様のアイデンティティとして管理します。Entra・Purview・Defenderのポリシーをひとまとめにした「ポリシーテンプレート」を管理センターから一括適用できるため、エージェント採用が拡大しても一貫したアクセス制御を維持できます。

3. ライフサイクル（存在管理の自動化）: エージェントは作られるだけでなく、使われなくなったりオーナーが不在になったりします。Microsoft Agent 365はライフサイクルポリシーとして、オーナーが不在になったエージェントの自動フラグと、一定期間非アクティブなエージェントの自動失効を提供します。人手を介さずに「野良エージェント化」を防ぐ仕組みです。

ゾーンガバナンスモデル：リスクに応じた3段階の統制

ホワイトペーパーが示す「ゾーンガバナンスモデル」は、エージェントのリスクと技術的複雑さに応じて統制レベルを3段階に分類するフレームワークです。試行・実験段階のエージェントには緩やかな統制を、高リスクな業務に関わるエージェントには厳格な統制を適用します。

重要: この考え方のポイントは、「すべてのエージェントを同じルールで管理しない」ことです。一律に厳しいルールを課せば現場は非公式の抜け道を探し、一律に緩いルールでは管理が形骸化します。リスクに応じて統制レベルを変えることで、現場の自由度と組織のリスク管理を両立しています。

エコシステム統合：n8nを例にした二層構造

Microsoft層とn8n層の二層責任分担

Microsoft Agent 365はサードパーティの自動化ツールもエコシステムに統合しています（「Bring your everyday business apps into the flow of work with agents in Microsoft 365 Copilot」）。n8nがその代表例で、n8nで作成したエージェントにもEntra IDが割り当てられ、Teams・Outlook・SharePoint内でMicrosoft製エージェントと同様に利用できます。

n8n公式ブログが示すこの統制モデルは「Microsoft層」と「n8n層」の二層構造です（「Deploy n8n agents that show up as members of the team inside Microsoft apps」）。

Microsoft層（プラットフォーム統制）:

Entra ID（エージェントID管理）
条件付きアクセスポリシー（デバイス・リスクスコアによるアクセス制御）
Microsoft Purview（コンプライアンス・データ保護）
Microsoft Defender for Cloud Apps（脅威検出・シャドーAI検出）
Microsoft 365管理センター（エージェント登録・ポリシー管理）

n8n層（ワークフロー統制）:

ワークフローレベルのRBAC（役割ベースアクセス制御）
認証情報の安全な管理
PII（個人情報）検出を含む入力検証
エラーハンドリングとアラート設定

情シスがコントロールするのは主にMicrosoft層です。n8n層は現場の自動化担当者が管理します。この役割分担が「現場の自由度を保ちながらリスクをプラットフォーム側で担保する」という両立を可能にしています。

導入コストの目安: n8nエージェントをMicrosoft Agent 365に接続する場合、スタンドアロンプランでは月額USD15/ユーザーのAgent 365ライセンスが必要です。Microsoft 365 E7（Enterprise向け）に含まれる形での利用も選択肢になります。事前にコスト試算し、Agent 365管理下に置くエージェントとスタンドアロン運用するエージェントを分類します。

シャドーAI検出とランタイム保護

Microsoft Agent 365のGA発表では、シャドーAI検出機能としてまずOpenClawを対象にローカルで動くAIエージェントの検出を開始し、GitHub Copilot CLIやClaude Codeなど他の主要エージェントへ順次拡大予定とされています。一方、ランタイム保護ではClaude CodeとGitHub Copilot CLIがPreview開始時点からサポート対象として明記されており、エージェントのフックポイントを通じてDefenderが動作を検査します。Microsoft自身が「エージェントの乱立は既に起きている」と前提として動いています。

2026年5月より、ランタイム検出とブロック機能がPublic Previewとして提供開始されています（「AI agent runtime protection with Microsoft Defender for Endpoint (Preview)」）。ポリシー違反の動作をリアルタイムで検出できるようになりましたが、現時点ではPreviewの範囲に留まるため、人的なログレビューによる補完を維持することが現実的です。

ランタイムという概念自体が気になる方は、ランタイムとは？実行環境の基本と選定ポイントを実務視点で解説も参考にしてください。

自社への応用：統制の型

Microsoftの仕組みを踏まえたうえで、プラットフォームを問わず応用できる統制の型を示します。ServiceNow（AI Control Tower）やAWS（Agent Registry、2026年4月Preview開始）など他のプラットフォームも同様の考え方で統制機能を整備しています（「The future of managing agents at scale: AWS Agent Registry now in Preview」）。基本的な考え方はどの環境でも共通です。

エージェント台帳を整える

Microsoftのホワイトペーパーが推奨するように、ガバナンスの最小単位は エージェント台帳 です。Excelでも、Notionでも、プラットフォーム標準のリスト機能でも構いません。形式より、「申告なしには新しいエージェントが正式に動かせない」という規範を先に作ることの方が重要です。

台帳の5項目

台帳に含める項目は以下の5つに絞ります。Microsoftホワイトペーパーが推奨する4項目（目的・プラットフォーム・アクセススコープ・オーナーシップ）に、運用上の判断基準として「停止条件」を加えた構成です。

項目	記載内容の例（汎用）	Microsoft環境での例
目的	「問い合わせ一次対応」「請求書データ抽出と承認ルーティング」など業務単位で記述	—
権限スコープ	アクセスするシステム名・データソース名と操作種別（読み取り/書き込み）を列挙	SharePointサイトID・TeamsチャネルID・外部サービス名（読み/書きの別も明記）
扱うデータ	個人情報を含むか（Yes/No）、情報区分（社外秘・内部限定・公開可など）	Microsoft Purviewの秘密度ラベル（「機密」「社外秘」等）に合わせて分類
オーナー	部署名と担当者名。異動・退職時の引き継ぎ義務者を明示	Entra IDのユーザーアカウントと対応づけると退職・異動時の自動通知と連動可
停止条件	「オーナー退職後30日で自動無効化」「四半期レビュー未実施で一時停止」など	Agent 365のライフサイクルポリシーで管理センターから自動設定可

主要なエージェント管理プラットフォームでは、このインベントリに対応する登録機能の整備が進んでいます。ServiceNow（AI Control Tower）は商用化済みで最も成熟した評価を受けており、AWS（Agent Registry）は2026年4月よりPreviewで提供開始されています。この台帳を利用するプラットフォームの登録機能と対応づけることで、手作業の台帳とシステムの自動管理を橋渡しできます。

Microsoft環境での例: Microsoft 365管理センターではエージェント登録・分析・ポリシー管理が統合提供されています。台帳の各行を管理センター上の登録エントリに対応させることで、手作業の台帳とシステムの自動管理を橋渡しできます。

自動化・半自動化のアプローチ

手作業での台帳更新には、記入漏れ・誤り・更新遅延のリスクが伴います。現実的なアプローチは、「プラットフォームが自動検出できる項目」と「人間が判断する必要がある項目」を分けることです。

プラットフォームのAPIから自動取得できる情報は、エージェント名・作成日時・最終アクティブ日時・接続先ツールやデータソースなどです。一方、業務上の目的・責任者としてのオーナー・停止条件は組織の意思決定が必要なため人間が入力しなければなりません。技術的なフィールドはAPIから自動同期し、ガバナンスフィールドは人間が入力する「ハイブリッド台帳」が、多くの組織にとって取り組みやすいアプローチです。

Microsoft環境での例: Microsoft 365管理センターのエクスポート機能やMicrosoft Graph APIを使い、テナント上のエージェント一覧・権限情報・アクティビティログを定期取得してMicrosoft Listsの台帳に自動反映するフローをPower Automateで構築できます。

ポイント: 台帳の整備は「完璧な状態を目指す」のではなく、「今動いているものを全部書き出す」ことから始めます。現状把握が先、精度向上は後です。

評価基準：何を許可し、何を禁止するか

台帳ができたら、次は「何を許可し、何を追加審査し、何を禁止するか」の基準を作ります。全部禁止も全部許可も組織として機能しません。以下は実務で使える評価基準の例です。

許可の3条件（すべて満たす場合）

台帳登録済みであること：未申告のエージェントは原則停止対象
オーナーが明確で、連絡可能な状態にあること：退職者・異動者のオーナーシップは移転完了まで停止
権限スコープが最小限（Least Privilege）に設定されていること：「とりあえず広めに」は許可しない（「NEW UPDATES: Administering and Governing Agents whitepaper v3.2」）

追加審査のトリガー（リスクが高い操作）

外部APIへのデータ送信（CRM、ERP、外部SaaSへの書き込み）
ユーザーの代理でメール送信・カレンダー操作
個人情報または機密区分データへのアクセス
複数部門をまたぐデータ参照
自然言語による「承認」「決定」などのアクション（「Agentic AI Threats and Mitigations」）

追加審査は、情シスとセキュリティチームによるレビューとします。レビュー期間の目安は5営業日以内に設定すると、現場の「面倒くさくて非公式で動かす」行動を抑止できます。

禁止の例

組織外への認証情報の転送
ユーザーの明示的な同意なしに個人チャットを読み取る操作
台帳に登録されていない外部エージェントサービスとの統合
監査ログが残らない経路でのデータ処理（「OWASP Top 10 for Large Language Model Applications 2025」）

重要: この基準は「禁止リスト」を厳格にすることより、「許可条件を明確にすること」の方が運用しやすくなります。禁止事項を列挙するより、「この条件を満たせば動かせる」というルールの方が現場の行動が変わります。

運用を定着させる3つのポイント

台帳と評価基準を作った後、運用が定着するかどうかは次の3つの仕組みにかかっています。

①変更管理、②監査ログ、③インシデント対応——この3つを押さえることが、エージェント運用を回し続けるための土台になります。

変更管理

エージェントの権限変更、オーナー変更、新機能追加は、すべて台帳更新と変更申請を必須とします。GitHubのPull Requestに相当するプロセスを、エージェント管理にも適用するイメージです。

変更申請はチケット管理ツール（Jira等）やフォームで受け付け、情シスが承認後に台帳を更新します。変更履歴を台帳に残すことで、「いつ誰が何を変えたか」が追跡可能になります。

変更管理のもう一つの意義は、 廃止の管理 です。使われなくなったエージェントが放置されることは、セキュリティリスクだけでなくライセンスコストの無駄にもなります。四半期ごとに台帳を棚卸しし、直近90日間のアクティビティがないエージェントは停止候補として通知する運用が有効です。

Microsoftのライフサイクルポリシーがこの棚卸しを自動化しているように、他のプラットフォームでも同様のAPI連携や自動通知の仕組みを検討することを推奨します（「Microsoft Agent 365 overview」）。

監査ログ

エージェントが行ったデータアクセスやアクションの監査ログを記録します。ただしこれは「デフォルトで完全に機能する」ものではなく、管理者がポリシーを設定し、保持期間を定義し、定期的にレビューする体制が必要です。どのプラットフォームでも「ツールがあることと、機能していることは別の話」です。

監査ログで最低限確認すべき項目:

エージェントが参照したデータソースとタイムスタンプ
外部サービスへの送信ログ
権限昇格のリクエスト履歴
エラー・異常終了のログ

Microsoft環境での例: Microsoft Purviewが監査ログを担います。管理者がポリシーと保持期間を設定した状態で運用します。Microsoft Agent 365では2026年5月よりランタイム検出とブロック機能がPublic Previewとして提供開始されており、ポリシー違反の動作をリアルタイムで検出できるようになりました。ただし現時点ではPreviewの範囲に留まるため、人的なログレビューによる補完を維持することが現実的です（「What's New in Agent 365: May 2026」）。

インシデント対応

エージェント関連インシデントの対応フローを事前に定義しておきます。最低限、以下の3ステップを準備しておく必要があります。

Step 1 ―隔離: 問題のあるエージェントを即時停止できる権限を情シスが持ちます。利用するプラットフォームの管理画面からエージェントを無効化する手順を、担当者全員が把握している状態にしておきます。

Step 2 ―調査: 台帳からオーナーを特定し、プラットフォームの監査ログで該当期間のアクティビティを抽出します。「誰が何をどこに送ったか」を48時間以内に概要把握できる体制を目標とします。

Step 3 ―報告・是正: インシデントの根本原因を特定し、台帳・評価基準・運用フローのどこに穴があったかを記録します。同種のインシデントを防ぐための是正措置を台帳ルールに反映して完結させます（「SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management」）。

90日ロードマップ：小さく始める導入の型

90日ロードマップ

「完璧な体制ができてから動き出す」では、その間も現場はエージェントを増やし続けます。90日間で「最初の型」を作ることを目標に、以下のフェーズで進めます。

Day 1〜30：現状把握フェーズ

目標: 今組織内で動いているエージェントをすべて洗い出します。

利用するプラットフォームの管理画面でエージェント一覧を取得する
シャドーアプリ検出機能（Microsoft環境ではDefender for Cloud Apps）で未登録のAIサービス接続を把握する
各部門のIT担当者に「現場で動いているBot・エージェント・自動化ツール」のヒアリングを実施する
洗い出した結果を台帳（暫定版）に記入する

この時点では精度より網羅性を優先します。台帳に「調査中」「不明」という記載が残っても構いません。

マイルストーン: 組織内のエージェントを80%以上把握した台帳（暫定版）の完成。

Day 31〜60：台帳整備フェーズ

目標: 台帳を運用可能な状態に整備し、評価基準を確定します。

台帳の5項目（目的・権限・データ・オーナー・停止条件）を各エージェントについて記入する
オーナーが不明なエージェントは部門ヒアリングで確定するか、停止候補として通知する
評価基準（許可条件・追加審査トリガー・禁止事例）を情シス・セキュリティチームで合意する
新規エージェント申請のフロー（フォーム・承認プロセス）を作成し、社内に周知する

マイルストーン: 台帳の完成版と、新規申請フローの社内公開。

Day 61〜90：統制定着フェーズ

目標: 運用を回し、仕組みとして定着させます。

新規エージェント申請が実際にフローを通じて処理されることを確認する
プラットフォームの監査ログ設定を行い、定期レビューのスケジュールを設定する
インシデント対応フロー（隔離・調査・報告）を文書化し、担当者に共有する
四半期棚卸しの日程を年間カレンダーに登録する
台帳の未記入項目を90%以上埋める

マイルストーン: 最初のエージェント棚卸しレポートの作成と、統制フロー全体の文書化完了。

まとめ：「止めない統制」を最初に設計する

エージェントを止めることはできません。Microsoftが2026年5月にAgent 365をGAとして提供し、インベントリ・権限・ライフサイクル管理を統合した統制基盤を確立したことが示すように、エージェントはすでにビジネスの基盤に組み込まれる方向で進んでいます。

Microsoftが整理した統制の3要素——インベントリ（全エージェントの可視化）・権限（最小権限原則）・ライフサイクル（存在管理の自動化）——は、プラットフォームを問わず通用する考え方です。ServiceNow・AWSなど他のプラットフォームも同じ思想で統制機能を整備しています。

情シスが取るべきスタンスは「禁止するか許可するか」ではなく、「どう見え、誰が責任を持ち、何が起きたら追跡できるか」を設計することです。台帳・権限・監査ログの3点セットはその最小単位です。まず90日で「最初の型」を作ることが、組織がエージェントと上手く付き合い続けるための最短ルートになります。

出典一覧

Microsoft公式

「Microsoft Agent 365 Now Generally Available」（2026-05-01）
「Microsoft 365 E7 and Agent 365 are now generally available」（2026-05-01）
「NEW UPDATES: Administering and Governing Agents whitepaper v3.2」
「Microsoft Agent 365 overview」
「Copilot Studio licensing」
「Bring your everyday business apps into the flow of work with agents in Microsoft 365 Copilot」（2026-04-13）
「What's New in Agent 365: May 2026」
「AI agent runtime protection with Microsoft Defender for Endpoint (Preview)」（2026-05-27）
「Agentic AI Threats and Mitigations」 — OWASP GenAI Security Project
「OWASP Top 10 for Large Language Model Applications 2025」 — OWASP Foundation
「SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management」 — NIST（2025）
「Deploy n8n agents that show up as members of the team inside Microsoft apps」 — n8n Blog
「The future of managing agents at scale: AWS Agent Registry now in Preview」 — AWS Machine Learning Blog