クラウド法務・セキュリティガバナンス週次ブリーフ

Azure・Entra ID・Microsoft 365・Intune・AIを取り巻く重要動向10選

基準日：2026年8月16日

クラウドを安全に利用するために、いま企業が見るべき対象は「クラウドの設定」だけではありません。

Azure、Microsoft Entra ID、Microsoft 365、Intune、Microsoft Defender、Microsoft Purview、Microsoft Sentinel、Copilot、AIエージェント。これらは、それぞれ独立した製品のように見えますが、実際の企業運用では、ID、端末、データ、AI、ログ、委託先、契約、BCP、インシデント対応が相互につながっています。

今週の結論は明確です。

「規程を書いたか」ではなく、「実際に技術で止められるか」「ログで説明できるか」「障害・侵害時に戻せるか」を確認する段階に入っています。

理由は、政府側では重要インフラの安全基準具体化や改正個人情報保護法への対応が進み、Microsoft側ではEntra Connectの強制更新期限、Copilot・MCPの端末統制、AIエージェントの実行時防御、SentinelのUEBA拡張、PurviewのAI・DLP強化が同時進行しているためです。

今回取り上げる重要項目は10件です。

本稿では、政府・公的機関およびMicrosoftなどの公式情報で確認できた事実と、そこから考えられる実務上の影響を分けて整理します。個別企業への適用可否、個別テナントへの機能展開状況、ライセンス条件については、各企業の契約・環境を確認しなければ判断できません。

1．重要インフラ「安全基準等策定ガイドライン（案）」の具体化が進む

確認できた事実

国家サイバー統括室は、重要インフラのサイバーセキュリティ対策について、「重要インフラのサイバーセキュリティ対策のための統一基準」を2026年7月31日に決定しています。

同統一基準は2026年10月1日施行予定です。

さらに、安全基準等策定ガイドライン案の検討も進められています。国家サイバー統括室の公式資料では、重要インフラ統一基準に基づく施策の実施や、安全基準等策定ガイドライン案の検討が明示されています。

なぜ企業に重要なのか

ここで注意したいのは、「重要インフラ事業者だけの話」と考えないことです。

重要インフラ事業者のシステムは、自社だけで完結しているとは限りません。

クラウド基盤を提供する事業者、AzureやMicrosoft 365の運用を請け負うMSP、SOC、システムインテグレーター、データセンター、保守会社、SaaS事業者など、多数の委託先・再委託先が関わっています。

そのため、直接的な規制対象ではない企業であっても、取引先から契約上のセキュリティ要求を受ける可能性があります。

実務で確認したいこと

重要インフラ関連の顧客を持つ企業では、少なくとも次を確認しておきたいところです。

• 重要システムの一覧

• Azure、Microsoft 365、SaaS、オンプレミスを含む構成

• 障害・侵害時の連絡ルート

• ログ提供義務

• インシデント報告期限

• 委託先への監査権

• 再委託の承認条件

• バックアップ・復旧責任

• SOCによる調査範囲

• サービス停止判断者

重要なのは、「契約書に書いてあること」と「実際に実行できること」を一致させることです。

ログ提供義務が契約に記載されていても、そもそも必要なログを取得していなければ意味がありません。

復旧支援義務が書かれていても、復旧手順を誰も試したことがなければ、実際の事故時に機能しない可能性があります。

確認できない点

一般企業すべてに重要インフラ統一基準が直接適用されるとは確認できません。

個別企業への影響は、業種、指定状況、所管省庁の基準、委託契約、サプライチェーン上の立場を確認して判断する必要があります。

2．2026年改正個人情報保護法――AIとクラウド委託を「データフロー」で見る

確認できた事実

個人情報保護委員会は、2026年7月17日、「個人情報の保護に関する法律等の一部を改正する法律」の公布について公表しています。

改正に向けた政府資料では、データとAIの活用を進める一方、個人情報保護の制度を見直す方向性が示されています。

具体的な政令、委員会規則、ガイドラインについては今後整備される部分が残っています。

なぜクラウド利用企業に重要なのか

企業がMicrosoft 365やAzureを利用すると、個人データは単純に「クラウドに保存される」だけではありません。

たとえば、

従業員がMicrosoft 365へ入力する。Copilotが情報を参照する。外部SaaSと連携する。MSPが管理者権限でアクセスする。海外拠点からサポートを行う。BPO事業者へデータ処理を委託する。

このように、一つのデータに複数の主体が関与します。

クラウド法務で重要なのは、「保存場所」を確認するだけではなく、データの流れ全体を把握することです。

実務で作るべきもの

改正対応を見据えるなら、まず作成したいのがデータフロー図です。

最低限、次を明確にします。

• どの個人情報を取得しているか

• 取得目的

• AzureやMicrosoft 365のどこへ保存するか

• CopilotやAIが参照するか

• 外部SaaSへ送信されるか

• MSPがアクセスするか

• 海外拠点からアクセスされるか

• 再委託が存在するか

• 保存期間

• 削除方法

• インシデント時の報告経路

契約書だけを確認するのではなく、「データがどう動くか」を技術担当者と法務担当者が同じ図で確認することが重要です。

確認できない点

改正法の具体的な施行日や、今後制定される政令・委員会規則・最終ガイドラインの内容は、現時点ではすべて確定しているわけではありません。

したがって、現時点で「改正法完全対応済み」と断定することは適切ではありません。

3．Entra Connectは2026年9月30日が重要期限

確認できた事実

Microsoftは、Microsoft Entra Connect Syncについて、2.5.79.0以上へ更新していない場合、2026年9月30日にすべての同期サービスが停止すると明記しています。

Microsoftは、期限までに更新できなかった場合でも、その後最新バージョンへ更新することで機能を回復できるとしていますが、更新までの期間は同期サービスが機能しないと説明しています。

なぜこれは法務・内部統制の問題なのか

Entra Connectは、単なる技術的な同期ソフトではありません。

多くのハイブリッドID環境では、

オンプレミスActive Directoryでユーザーを無効化する。その変更がEntra IDへ同期される。Microsoft 365やクラウドサービスへのアクセスも止まる。

というプロセスになっています。

もし同期が停止すると、オンプレミス側で退職者を無効化したにもかかわらず、クラウド側へ変更が反映されない可能性があります。

これは、アクセス管理上の重大な問題です。

まず確認すべきもの

全Entra Connectサーバーを棚卸しします。

対象は本番サーバーだけではありません。

• 本番

• ステージング

• DR用

• 旧サーバー

• 検証用サーバー

を含めます。

さらに、

• カスタム同期ルール

• 構成ファイル変更

• Password Hash Sync

• Pass-through Authentication

• AD FS

• Password Writeback

• FIPS

• TLS

• .NET

• OSバージョン

も確認します。

更新試験で確認したいこと

単にサービスが起動するかだけでは不十分です。

更新後、

新規ユーザーを作成する。Entra IDへ同期される。グループを変更する。属性を変更する。ユーザーを無効化する。パスワード変更を行う。

といった一連のライフサイクルを試験します。

Entra Connectは「同期しているから大丈夫」ではなく、人事イベントとアクセス停止が正しく連動するかを確認する必要があります。

4．Intune 2607――CopilotをURL単位で制御できる時代へ

確認できた事実

Microsoft Intuneの2026年7月27日の更新では、Microsoft EdgeでCopilotによる閲覧を許可するURLと禁止するURLを管理する設定が追加されています。

許可リストと禁止リストを組み合わせることもでき、ブロックリストが許可リストより優先されます。対象はHTTP／HTTPSです。

同じIntune更新では、Visual StudioでModel Context Protocol（MCP）を無効化する設定も追加されています。

さらに、Microsoft Defender Antivirusについて、IntuneまたはDefender for Endpointから配信した設定を権威ある設定として扱うControlled ConfigurationがPreview提供されています。

なぜ大きな変化なのか

これまでAIガバナンスというと、

「機密情報をAIへ入力しない」「会社が認めたAI以外を使わない」

といった利用規程が中心でした。

しかし、規程だけでは利用者の操作を技術的に防ぐことはできません。

今回のIntune設定によって、

人事サイトはCopilot参照禁止。会計システムは禁止。社内FAQは許可。公開Webサイトは許可。

といったように、AIが扱える情報の境界を端末側で具体的に設計できます。

最初に作りたいURL分類

Copilotを利用する企業では、URLの分類から始めると実務的です。

原則禁止候補

• 人事

• 給与

• 会計

• 法務

• 内部通報

• 特権管理画面

• 顧客個人情報

• 医療・健康情報

条件付き許可候補

• 社内ナレッジ

• プロジェクトサイト

• 業務マニュアル

原則許可候補

• 公開Webサイト

• 一般公開情報

規程の内容とIntuneの設定が一致して初めて、AIガバナンスが実際の統制になります。

5．MCPは「便利なAI連携」ではなく、新しいアクセス経路

MCPは、AIエージェントと外部ツール・データをつなぐ仕組みとして急速に利用が広がっています。

しかし、MCPサーバーを経由すれば、AIは単に回答を生成するだけでなく、外部データへアクセスしたり、ツールを実行したりできます。

MCPで確認すべきもの

企業内で利用する場合は、最低限次を台帳化します。

• MCPサーバー名

• 提供者

• 管理責任者

• 接続元AI

• 接続先システム

• 認証方式

• 利用する資格情報

• 読み取り可能データ

• 更新可能データ

• 実行可能ツール

• ログ

• 停止方法

Visual StudioでMCPを無効化できるIntune設定が追加されたことは、「MCPを使うかどうか」を個人開発者へ任せず、企業ポリシーとして管理する必要性が高まっていることを示しています。

6．Microsoft Defender――AIエージェントを「実行前」に止める

確認できた事実

Microsoft Defender XDRでは、AIエージェントの活動を監視し、ツール利用や実行パターンから、jailbreak、間接プロンプトインジェクション、資格情報漏えい、疑わしいアクセスなどを検知する機能が提供されています。

さらにローカルAIエージェントについては、ユーザープロンプト、ツール呼び出し、ツール応答を検査し、危険な動作を実行前にブロックするRuntime ProtectionがPreview提供されています。

ブロックや監査イベントはMicrosoft Defender上の調査データとして扱うことができます。

AIガバナンスは4段階へ

企業のAI統制は、次のように段階的に考えると分かりやすくなります。

第1段階：利用規程

何を入力してよいか。

第2段階：台帳

どのAI・エージェントを誰が使っているか。

第3段階：権限制御

どのデータ・ツールへアクセスできるか。

第4段階：実行時制御

危険な操作を実行前に止められるか。

現在、Microsoftの製品ロードマップは明らかに第4段階まで進んでいます。

法務上の新しい論点

AIエージェントのログには、利用者が入力したプロンプトや、その一部が含まれる可能性があります。

Microsoftも、AIエージェントの検知・調査にPrompt evidenceを利用できる仕組みを案内しています。

そのため、

誰がAIの監査ログを見られるのか。何日保存するのか。人事評価に利用するのか。顧客情報が含まれる場合どう扱うのか。

というプライバシー設計も必要になります。

AIセキュリティと個人情報保護は、別々のテーマではなくなりつつあります。

7．Sentinel UEBA――「ログを集めるSOC」から「行動を見るSOC」へ

確認できた事実

Microsoft SentinelのUEBA異常検知では、Check Point、Fortinet FortiGate、ZscalerのFirewall、VPN、Web ProxyイベントをCommonSecurityLogから分析できる機能が拡張されています。

Microsoftは10個の新しい異常ルールについて、

• 異常なVPNサインイン

• VPNサインイン失敗

• 高リスクWebカテゴリーへの異常アクセス

• セキュリティ検知の急増

• 不審な管理変更

などを対象としていると説明しています。

なぜログの「量」だけでは足りないのか

SIEM導入プロジェクトでは、「FirewallログをSentinelへ送信した」というところで完了とされることがあります。

しかしUEBAでは、

このユーザーは普段どこからログインするか。この端末は普段どのWebサイトへ接続するか。VPN失敗回数は通常と比べて異常か。

という文脈が必要です。

ログの項目が正しく正規化されていなければ、有効な分析はできません。

SOC契約で確認したいこと

SOCを外部委託している場合は、

• CommonSecurityLogの品質

• ユーザー名の正規化

• 端末ID

• IP

• Geo情報

• ログ保持期間

• 異常検知のチューニング

• 誤検知レビュー

まで確認する必要があります。

「ログを受け取っています」だけでは、脅威検知の品質は保証されません。

8．Purview――ラベルとDLPは「いきなり強制」しない

確認できた事実

Microsoft Purviewでは、2026年8月の更新として、Sensitivity Labelの自動ラベルポリシーを本番適用する前にSimulation Modeで実行できる機能が案内されています。

実際のアイテムを変更することなく、どのデータがラベル対象になるかを確認できます。

またPurviewは、Microsoft 365 CopilotなどのAI利用について、Data Security Posture Managementや情報保護、コンプライアンス機能を利用して統制する仕組みを提供しています。

なぜSimulationが重要なのか

DLPや自動ラベルは、強力な統制です。

しかし、設定を誤れば業務を止めます。

たとえば、

すべてのExcelファイルを機密扱いにして外部共有を止めてしまう。顧客へ送るべき資料まで送信不能になる。業務アプリとの連携が停止する。

といったことが起こり得ます。

Simulation Modeを使えば、

対象件数対象部署誤検知業務影響

を本番適用前に確認できます。

法務と情シスが一緒に見るべき画面

AI・DLPでは、法務部門が規程を書き、情シスが設定するだけでは不十分です。

シミュレーション結果を一緒に確認し、

このデータは本当に個人情報か。この資料は社外共有禁止か。AI参照を禁止する必要があるか。

という判断を共同で行う必要があります。

9．CaptiveCrunch――ホテルWi-FiがEntra ID侵害の入口になる

確認できた事実

Microsoft Threat Intelligenceは2026年7月31日、「CaptiveCrunch」と呼ばれる攻撃活動を公表しました。

この活動では、旅行者などが利用するキャプティブポータル型ネットワークを悪用し、認証情報窃取やマルウェア配布を行う手法が確認されています。

これまでの「公共Wi-Fi対策」と何が違うのか

従来、ホテルWi-Fiのリスクと言えば「通信を盗み見られる」という説明が中心でした。

しかし現在は、より直接的です。

ホテルのWi-Fi接続画面で、

「Microsoftへログインしてください」

と表示される。

デバイスコードを入力させられる。

偽のブラウザ更新を実行させられる。

そこからMicrosoft 365のセッションやクラウド認証情報が狙われる。

こうした流れを想定する必要があります。

出張規程に追加したい内容

出張者には、抽象的な「公共Wi-Fiに注意」ではなく、具体的に伝えます。

• Wi-Fi画面でMicrosoftのデバイスコードを入力しない

• Wi-Fi接続時に表示されたブラウザ更新を実行しない

• OS更新を実行しない

• 証明書をインストールしない

• 可能なら会社管理モバイル回線を利用する

• 異常を感じた場合は接続を切る

管理側では、

• 新規Entraデバイス登録

• OAuth同意

• 不審なサインイン

• セッショントークン異常

などの監視が必要です。

確認できない点

今回確認したMicrosoft公式情報から、日本国内の特定ホテルや特定日本企業が侵害された事実は確認できません。

10．ChainDrop――CI/CDは「開発ツール」ではなく高権限ID基盤

確認できた事実

Palo Alto Networks Unit 42は2026年8月6日、自己増殖型npmワーム「ChainDrop」の分析を公開しました。

Unit 42は、ChainDropがGitHub Actions RunnerのRunner.Workerプロセスのメモリを読み取り、OIDCトークンやRunner Secretsなどのインメモリ資格情報を探索する仕組みを報告しています。

Microsoft Threat Intelligenceも、このサプライチェーン攻撃が400を超えるnpmパッケージに影響したと報告しています。

「OIDCだから秘密情報はない」は誤解

近年、AzureとGitHub Actionsを連携するとき、長期的なClient Secretを使わず、OIDC Federationを使う設計が推奨されています。

これは重要なセキュリティ改善です。

しかし、「OIDCなら盗まれる秘密情報は存在しない」という意味ではありません。

ジョブ実行中には、一時的なトークンがメモリ上に存在します。

Runner自体が侵害されれば、その一時トークンを狙われる可能性があります。

GitHub Actions＋Azureで確認したいこと

• Federated CredentialのSubject条件

• 対象Repository

• Branch条件

• Environment条件

• Azure側Role Assignment

• Runnerからの外向き通信

• npm依存関係

• Lock file

• SBOM

• Self-hosted Runnerの利用

• Runnerの使い捨て化

• GitHub Actions Workflowの変更承認

CI/CDは、「開発部署の便利な自動化環境」ではありません。

本番Azureへアクセスできる場合、実質的には高権限のID基盤です。

したがって、Entra IDの管理者アカウントと同じように厳格な統制が必要です。

今週の実務対応――まず48時間以内に確認したいこと

すべてを同時に対応するのは現実的ではありません。

優先順位をつけるなら、まず次の4点です。

1．Entra Connectの全バージョン確認

2026年9月30日の期限まで時間はありますが、更新試験や変更申請を考えると、直前対応は危険です。

本番だけでなく、ステージングやDRも確認します。

2．Microsoftの8月更新状況を管理画面で確認

本稿では、前回ブリーフで触れた2026年8月版IPAのMicrosoft月例更新注意喚起について、今回の公式サイト検索では該当ページを確認できなかったため、個別CVEを確定情報として掲載していません。

Windows更新については、Microsoftの管理画面・リリース情報と、自社Intuneの適用状況を直接確認してください。

3．AIエージェントとMCPの棚卸し

AIエージェント名だけでは不十分です。

MCP接続先、ツール、データ、認証情報まで一覧化します。

4．出張者へのWi-Fi注意喚起

技術対応より早くできる対策です。

「ホテルWi-FiでMicrosoftのデバイスコードを入力しない」という具体的な注意喚起は、すぐ実施できます。

30日以内に進めたいガバナンス整備

今後30日で進めたいのは、個別の製品設定ではなく、横断的なガバナンスです。

AIガバナンス

AI利用規程、MCP台帳、AIエージェント台帳、DLP、Defenderの実行時保護を一つの体系にします。

IDガバナンス

Entra Connect、Conditional Access、サービスプリンシパル、AIエージェント、CI/CD OIDCを一つのID管理対象として扱います。

データガバナンス

Purviewのラベル、DLP、Copilot参照範囲、個人情報保護法上の利用目的を整合させます。

SOCガバナンス

Sentinelにログが入っているかではなく、「誰の行動として分析できるか」を確認します。

委託先ガバナンス

重要インフラ基準を見据えて、事故報告、監査、再委託、ログ、復旧を契約書と実運用で一致させます。

まとめ――クラウドの最大のリスクは「古い前提」

今週の動向を並べると、一見すると別々のニュースに見えます。

重要インフラ基準。改正個人情報保護法。Entra Connect。Intune。Copilot。MCP。Defender。Sentinel。Purview。ホテルWi-Fi。npmサプライチェーン。

しかし、共通している問題は一つです。

企業システムの境界が消えていることです。

従業員のIDはクラウドへつながっています。

AIエージェントも業務データへアクセスします。

開発用CI/CDも本番Azureへアクセスします。

ホテルのWi-FiからMicrosoft 365へログインします。

外部SOCがログを分析します。

委託先がシステムを保守します。

もはや、「社内ネットワークの中を守れば安全」という設計では対応できません。

そのため、クラウド法務とクラウドセキュリティを別々の仕事として扱うことにも限界があります。

法務は契約だけを見る。

情シスは設定だけを見る。

SOCはアラートだけを見る。

開発部門はCI/CDだけを見る。

AI担当はCopilotだけを見る。

この分断そのものが、新しいリスクになります。

これから必要なのは、

ID、端末、データ、AI、ログ、CI/CD、委託先、契約、BCP、復旧を一つのガバナンスとして見ることです。

クラウドの本当のリスクは、クラウドを利用することではありません。

技術や制度が変わったにもかかわらず、昨日まで正しかった前提を、今日も正しいと思って運用し続けることです。

2026年後半のクラウドガバナンスでは、「何を導入しているか」以上に、変化を継続的に検知し、その変更を契約・設定・運用へ反映できる組織であるかが問われることになります。