AIエージェント時代に、IT技術者が最初に直すべき土台

Microsoft 365のセキュリティを考えるとき、どうしても「外部からの侵入」を先に思い浮かべがちです。もちろん、ランサムウェアやサプライチェーン攻撃への対策は今も重要です。
ただ、ここ数年でもうひとつの現実がはっきりしてきました。侵入されなくても、見せすぎた情報は漏れるという現実です。

しかもAIエージェントが普及し始めたことで、この問題は「設定ミス」ではなく「運用設計の欠陥」として表面化しやすくなりました。この記事では、Microsoft 365を運用するIT技術者向けに、事例と一次情報をもとに、いま見直すべき実務ポイントを整理します。

「攻撃対策だけでは足りない」が現実になった背景

セキュリティ脅威のランキングを見ると、従来型の攻撃は依然として上位です。一方で、AIの利用に伴うリスクが新たに上位へ入ってきたことは、攻撃手法が増えたというより、既存の権限や共有状態がそのままリスクとして増幅される段階に入ったことを示しています。

日本企業のIT環境も、この変化を受け止める前提にあります。クラウドはもはや「一部部署の実験環境」ではなく、業務の標準基盤です。基盤になった以上、アクセス権や公開範囲の曖昧さは、運用上の小さな癖では済みません。そのまま、事故の入口になります。

参考: IPA 情報セキュリティ10大脅威 2026
参考: 総務省令和5年通信利用動向調査（企業のクラウド利用率）

共有責任モデルを誤解すると、Microsoft 365運用は崩れる

「SaaSだから、基盤側でだいたい守られている」という感覚は、現場で今もよく見かけます。ですが、Microsoftの共有責任モデルが示しているのは、クラウド事業者と利用者で責任範囲が明確に分かれるという原則です。
サービス基盤の防御はベンダー側でも、データ、ID、アクセス権、設定、端末保護の多くは利用者側の責任です。

つまり、Microsoft 365を導入した時点でセキュリティを外部委託したのではなく、守る場所が「境界」から「ID・権限・データ分類」に移っただけです。ここを誤解したままAI導入へ進むと、便利さだけが先に立って、後で権限事故が一気に噴き出します。

参考: Microsoft Learn - Shared responsibility in the cloud
参考: Microsoft Trust Center - Shared Responsibility Model

侵入なしで起きる漏えいは、もう特殊事例ではない

2024年に公表された東京都立小金井工科高校の事案は、この構造を理解するうえで象徴的です。報道と公表情報によると、Teams上の共有設定運用に起因して、他校生徒から閲覧可能な状態が発生しました。
ここで重要なのは、ゼロデイや高度な認証突破が使われたわけではない点です。共有アカウント運用と公開範囲設定の組み合わせだけで漏えいが成立することが明確になりました。

この現象は教育現場に限りません。企業でも、権限継承や共有リンクの管理が曖昧なまま運用されると、同じ構造が再現されます。攻撃を受ける前に、自組織の設定が情報を見せてしまう状態です。

参考: 東京都教育委員会の公表に基づく報道（NHK）

Power BIの「公開しやすさ」は、同時に事故導線でもある

Power BIのPublish to webは、レポート共有を極端に簡単にしてくれる便利機能です。だからこそ、運用ガードがない環境では事故導線になります。
Microsoft公式ドキュメントは、この機能がインターネット上での公開につながること、機密情報に使うべきでないことを明示しています。

現場では「いったん見てもらうために公開」を短期的に行い、そのまま戻し忘れるケースが起きます。ですが、AIエージェント時代はこの“戻し忘れ”がより危険です。人が気づかなかった公開状態を、AIは検索・要約・再構成によって高速に利用できるためです。

参考: Power BI - Publish to web considerations
参考: Power BI governance and security overview

Copilotは「権限の範囲内」で動く。だから権限が最重要になる

Microsoft 365 Copilotのセキュリティ説明で繰り返し強調されているのは、Copilotが既存のアクセス制御を前提に応答するという点です。これは一見安心材料ですが、運用側から見ると逆です。
過剰共有やガバナンス不備があると、その状態を前提に高精度な回答が生成されることになります。

これまでの環境では、見ようと思っても見つけにくい情報が実質的な防壁になっていたことがあります。Copilotはその防壁を消します。「権限上は見えるが、人は探せなかった情報」が、自然言語で取り出せるようになるためです。
Copilot導入の成否は、モデル性能より先に、SharePointやTeamsの権限設計と運用品質で決まると言ってよい段階です。

参考: Data, Privacy, and Security for Microsoft 365 Copilot
参考: Prepare your organization for Microsoft 365 Copilot

AIエージェント導入前に、まず直すべき4つの実務

ここからは、PoCの成否ではなく本番運用で効く観点に絞って整理します。ポイントは個別製品最適ではなく、Microsoft 365全体をひとつのデータ平面として扱うことです。

1) Teams・SharePoint・OneDrive・Power BIを「別製品」で見ない

実務では製品ごとに管理担当が分かれがちですが、IDと権限は相互に影響します。ある製品での共有設定が、別製品経由の情報露出につながることは珍しくありません。
運用レビューの単位を製品別から、ユーザー・グループ・共有リンク・外部共有ポリシーへ切り替えるだけでも、事故の予兆はかなり見つけやすくなります。

2) 権限管理を「設定作業」ではなく「定期運用」に変える

特に注意したいのは、退職者・異動者・外部委託先・終了プロジェクトの残存権限です。通常時は目立たなくても、AI導入後は検索性向上により一気に露出しやすくなります。
最低でも四半期ごとに、利用実績のない共有リンク、所有者不明チーム、外部共有が継続するサイトを棚卸しし、解除・再承認の流れを標準化しておくと、後戻りコストが大きく下がります。

3) データ分類とDLPを、監査のための飾りにしない

ラベル付け自体をゴールにすると、運用は必ず形骸化します。重要なのは、ラベルに応じて公開・外部共有・ダウンロード・コピー制御まで連動させることです。
Power BIやMicrosoft Purviewの仕組みは、設計次第で「分類」から「制御」へつなげられます。AI時代は、この連動がないと“ラベルはあるのに漏れる”状態になりやすくなります。

参考: Microsoft Purview DLP
参考: Sensitivity labels in Power BI

4) バックアップを最後の復元線として明確に置く

Microsoft 365では可用性が高くても、誤削除、設定誤適用、内部不正、ランサム後の論理破壊までは防ぎきれません。
ゼロトラストやDLPが予防策なら、バックアップは復旧策です。どちらか片方ではなく、事故フェーズに応じて役割が違います。運用設計ではこの2層を分けて考えると、対策の抜け漏れが減ります。

参考: Microsoft 365 Backup
参考: Microsoft 365 data protection and resiliency

PoCが成功しても、本番で崩れる理由

PoCは、権限を整理した少人数・限定データ・短期間運用で実施されるため、結果が良く見えます。問題は本番です。
本番環境には、長年の共有リンク、部門ごとの命名ゆれ、所有者不明サイト、例外設定、引き継ぎ不足が蓄積しています。AIエージェントはそれを無視して賢くなるのではなく、その環境を前提に高速で働くだけです。

市場予測でも、AIエージェントの普及期待と、運用不備による失敗見通しが同時に語られています。これは技術の矛盾ではなく、土台の品質が成果を分けるという、非常に現場的なメッセージです。

参考: Gartner Press Release (2025) - Agentic AI adoption forecast
参考: Reuters - Gartner view on agentic AI project failure risk

今日からの運用を変える一歩

Microsoft 365時代の情報漏えいは、「防御を破られたかどうか」だけで説明できなくなりました。
見えていなかったものが、権限上は見えていたという状態を、AIが可視化してしまう時代です。

だからこそ、AIエージェント導入の前にやるべきことはシンプルです。
共有責任モデルを前提に、ID・権限・データ分類・監査・バックアップを、日常運用として回る設計へ戻すこと。これができる組織では、Copilotや今後のAIエージェントはリスクの増幅器ではなく、業務改善の加速装置になります。

「AIを入れるかどうか」より先に、「いま見えすぎていないか」を確認する。
この順番が、2026年のMicrosoft 365運用では最も効くセキュリティ施策です。

作成日: 2026-04-20