M365

Microsoft Purview Insider Risk Managementが、2026年5月〜6月のロールアウトで、AIとのやり取りを平文（プレーンテキスト）で確認できる機能を追加する。リスクポリシーがトリガーされた際に、ユーザーの匿名性を保ちながら、AIプロンプトとその応答の全文をセキュリティアナリストが直接確認できるようになる。 Microsoft Purview Insider Risk Managementとは Microsoft Purview Insider Risk Management（IRM）は、社内の人間——従業員・請負業者・パートナー——によるリスク行動を検出・調査・対応するためのコンプライアンスソリューションだ。Microsoft 365 E5ライセンスに含まれるほか、アドオンとしても購入できる。 ファイルの大量ダウンロード、メール転送、異常なサインインといったアクティビティをリスク指標と照合し、閾値を超えるとアラートを生成、調査ケースが自動作成される。これまでSharePoint・OneDrive・Exchange・Teamsといった従来型データソースが対象だったが、生成AIの普及で「AIチャットボックス」という新たなリスク経路が生まれた。 AIプロンプトの「中身」が見えなかった問題 従来のIRMは「AIとのやり取りが発生した」という事実ログは残せても、その内容——具体的に何を入力し、AIが何を返したか——を把握できなかった。これが大きな死角だった。 社員が機密コードをCopilotに貼り付けて解析を依頼した場合、あるいは非公開の財務情報をプロンプトに含めた場合、セキュリティチームはそれを後から読むことができなかったのだ。 新機能の仕組み：平文レビューと匿名化の両立 今回の機能拡張でIRMは、クレジットカード番号・社会保障番号・カスタム分類子といったセンシティブ情報タイプが含まれるプロンプトを検出すると、そのやり取り全文をキャプチャする。調査アナリストは、ケース画面から実際の会話を平文で確認できるようになる。 一方で、プライバシーへの配慮も盛り込まれている。調査段階ではユーザーの匿名化が維持される設計で、必要な権限を持つ担当者だけが氏名を確認できる段階的開示の仕組みが提供される。 また、監視対象とする生成AIアプリを管理者が選択できる機能も追加される。Microsoft 365 Copilotだけでなく、組織が業務で使用する外部AIサービスも対象に加えられるため、シャドーAIのリスク管理にも使える可能性がある。 実務への影響——日本のIT管理者・セキュリティ担当者へ 即座に確認すべきこと： ライセンス確認: M365 E5を持っているか、IRMのアドオンが有効になっているかを確認する。この機能は上位ライセンス限定だ 既存のDLPポリシーとの整合性: 従来のデータ損失防止（DLP）ポリシーに「AIプロンプト経由の情報流出」のシナリオが抜けていないか見直すタイミングだ 利用規程の更新: 「AIツールへの業務データ入力ルール」を就業規則・情報セキュリティポリシーに明文化する。監視される事実を従業員に適切に周知しなければ、従業員の信頼を損なう可能性がある（欧州のGDPR対応も要注意） 段階的展開の計画: まずは特定の部門・職種だけを対象にパイロット運用し、アラートの精度と業務への影響を評価してから全社展開を検討するのが現実解だ 長期的な視点では： Copilot・外部AI・社内構築LLMと複数のAIが混在する環境では、一元的なガバナンス基盤が不可欠になる。IRMとMicrosoft Purview全体（DLP・情報保護・コンプライアンスマネージャー）を統合して使う設計が、長期的にコストと複雑性を下げる。 筆者の見解 この機能追加は、Purviewとして「当然やるべきことをついにやった」という印象だ。生成AIの業務利用が急拡大するなか、AIとのやり取りだけがセキュリティの視野外に置かれていた状況は、どう考えても無理があった。 ゼロトラストの文脈でいえば、「可視化なきアクセス制御はゼロトラストではない」。AIへのプロンプトという行動が可視化されることで、ようやくIRMがAI時代のリスク管理ツールとして機能し始める。これはMicrosoftのセキュリティ統合プラットフォームとしての地力が発揮される場面であり、素直に評価したい。 一方で、正直に言えば「遅い」とも感じる。Copilotが本格展開されたのは2023年後半。それから2年以上、AIプロンプトの中身が見えないままリスク管理ツールとして販売されていたわけで、そこは「もったいなかった」と言わざるを得ない。M365のセキュリティ機能は確かに統合度が高く、使いこなせば強力なのだから、こういうギャップは早めに埋めてほしい——それが長年のM365ユーザーとしての率直な声だ。 今後の課題は「何をAIプロンプトのリスク指標と定義するか」のチューニングだ。センシティブ情報の検出精度が低ければ誤検知が増えてアナリストの業務を圧迫し、高すぎれば見落としが増える。この「閾値設計」こそ、管理者に問われる本当の専門性になる。 出典: この記事は Microsoft Purview Insider Risk to Review AI Prompts in Plaintext (May–Jun 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft PlacesおよびMicrosoft Teamsにおいて、社内Wi-Fiネットワークへの接続を利用してオフィスへの出社を自動検知する「Wi-Fiチェックイン」機能を発表した。従業員が手動でワークプレイスロケーションを更新しなくても、ノートPCが社内ネットワークに接続した瞬間にTeamsが検知し、勤務場所を自動更新する。 「今日、誰がオフィスにいるか」を自動で可視化 ハイブリッドワークが定着した現在、チームメンバーの物理的な居場所を把握するのは意外と手間だ。Outlookのカレンダーを見ても「在宅か出社か」までは分からないことが多く、Teamsのプレゼンスは「オンライン中」かどうかは示しても「今日どこから働いているか」は示さない。 Microsoft Placesのワークプレイスプレゼンスはこのギャップを埋める機能だ。そして今回の「Wi-Fiチェックイン」は、その情報を手動入力なしで常に最新状態に保つ仕組みである。 技術的な仕組みはシンプルだ。各オフィスのWi-FiアクセスポイントのBSSID（基地局識別子）をMicrosoft Placesのディレクトリに登録しておくと、従業員のノートPCがそのネットワークに接続したタイミングでTeamsクライアントがそれを検知し、その日の勤務場所を「オフィス」に自動更新する。既存の「周辺機器チェックイン」（ディスプレイやドックへの接続で検知）と同じコンセプトをWi-Fiに拡張したものと考えると理解しやすい。 プライバシーへの配慮：3層の同意モデル こうした「位置検知」機能には、常に監視懸念がつきまとう。Microsoftはその点を意識してか、3層の同意モデルを設計している。 第1層：組織レベルの有効化 テナント管理者が機能そのものを有効にするかどうかを決める。有効にしない限り、従業員のデバイスでは機能しない。 第2層：設定方式の選択 組織がオプトイン（従業員が明示的に有効化）かオプトアウト（デフォルト有効だが個人が無効化可）かを選択できる。 第3層：個人レベルの制御 最終的には個人がいつでも設定を変更でき、手動でロケーションを上書きすることも可能。デバイスの位置情報設定がオフであれば、組織が有効にしていても機能しない。 また、過去の行動履歴は保存されない。「現時点でどこにいるか」だけを示す現在進行形のシグナルであり、「いつ何時間オフィスにいたか」のような追跡には利用されない点は明記されている。 実務への影響 IT管理者の準備事項 今年後半のロールアウトに備えて、以下の準備が求められる。 Microsoft Placesのセットアップ確認: Placesディレクトリにビルディング情報が登録されているかを確認する BSSIDの収集と登録: 対象オフィスのWi-FiアクセスポイントすべてのBSSIDを収集し、Placesディレクトリに登録する Teamsの作業場所検出ポリシーの有効化: 管理センターで該当ポリシーを設定する 従業員への周知: 機能の概要・できないこと（履歴は保存されないなど）・個人での制御方法を事前に説明する BSSIDの収集は、フロアごとに多数のアクセスポイントが存在する大規模オフィスでは一定の手間がかかる。ネットワーク担当部門と連携して、AP一覧のエクスポート方法を事前に確認しておくとスムーズだ。また、オフィスの移転・増設・Wi-Fiリプレイス時には「Placesのディレクトリも更新が必要」という新たな運用タスクが発生することを、ネットワーク管理のライフサイクルに組み込んでおく必要がある。 エンジニア・ビジネスユーザーへの恩恵 Teamsやカレンダーから「今日誰がオフィスにいるか」がリアルタイムで確認できる 「せっかく出社したのに全員リモートだった」という状況を事前に回避できる フリーアドレスのデスク予約と連携し、チームメンバーの近くに席を取りやすくなる 筆者の見解 Microsoft Placesは、ハイブリッドワーク時代の「コラボレーション基盤」として地道に機能を積み上げている印象だ。カレンダーの空き状況・Teamsのアクティビティプレゼンス・ワークプレイスプレゼンスを組み合わせた多層的な可視化は、M365を統合プラットフォームとして活用することの具体的な価値を示している。バラバラに導入していては得られないメリットだ。 プライバシー設計については、オプトイン/オプトアウトを組織が選択できる構造は実際的だと思う。日本企業の文化的な背景を考えると、「オプトイン」から始めて従業員の理解を得ながら段階的に展開するアプローチが現実的だろう。 一方で、BSSIDベースの設定管理は運用負荷の観点でやや気になる。Wi-Fiインフラの更新サイクルとPlaces管理のサイクルを意識的に連携させなければ、気づかないうちにチェックインが機能しなくなるケースが出てくるかもしれない。Microsoftには、ネットワーク管理ツールとの統合や自動同期の仕組みを将来的に検討してほしいところだ。 とはいえ、M365エコシステムをフル活用できている組織にとっては、すぐに「あって当然」の機能になるポテンシャルがある。まだMicrosoft Placesを導入していない組織にとっては、今回の機能を評価のきっかけにしてみる価値は十分あるだろう。 出典: この記事は Workplace presence, made effortless: Workplace check-in via Wi-Fi for Microsoft Places and Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、職場内で稼働する自律型AIエージェントを一元管理・追跡するプラットフォーム「Microsoft Agent 365」を発表した。2028年までに企業の業務自動化を担うエージェントが13億個に達すると予測する同社が、ガバナンス基盤の整備に本格的に乗り出した形だ。 AIエージェント管理という新しい課題 コード生成やデータ分析、サプライチェーン管理など、業務の自動化を担うAIエージェントの導入が企業で加速している。個別に便利なエージェントを次々と導入した結果、「社内に何個のエージェントが動いているのかわからない」という状況は、すでに多くの企業で現実になりつつある。 Microsoft商業部門CEOのジャドソン・オルソフ氏は「棚卸エージェント」「在庫不足エージェント」など複数のエージェントが並走する環境を例に挙げ、「ツールなしに、それらがプロセス全体でどう組み合わさっているかを把握するのは非常に困難」と述べた。このコメントは、現場の痛みをそのまま言語化したものとして説得力がある。 Microsoft Agent 365の主な機能 Microsoft Agent 365は、IT管理者がネットワーク上のユーザー管理と同じ感覚でAIエージェントを管理できるプラットフォームとして設計されている。主な機能は以下のとおりだ： エージェントの可視化・追跡: 社内で稼働するすべてのエージェントをダッシュボード上で一覧把握 不正エージェントの隔離: 想定外の動作をするエージェントをシステムから切り離す「検疫」機能 生産性ツールの付与: 承認済みエージェントに必要なツールセットを割り当て サイバー攻撃からの保護: エージェントを経由したセキュリティリスクへの対応 ROI計測: AIエージェントへの投資対効果を定量的に可視化 特筆すべきは、Microsoft製だけでなくSalesforceなど他社製エージェントも管理対象に含まれる点だ。マルチベンダー環境を前提とした設計は、実際の企業ITの現実に正直に向き合った判断といえる。 同時に発表された「Work IQ」は、Microsoft 365 Copilotを動かすインテリジェンスとビジネスデータを活用して独自エージェントを構築できるサービスで、企業独自のAIカスタマイズ需要にも対応する。現在、Microsoft 365ライセンス保有者向けの早期アクセスプログラムへの申請が可能だ。 実務への影響——「エージェントも人間と同じように管理する」発想の転換 日本のエンジニア・IT管理者にとって、このプラットフォームが突きつけるのは根本的な認識の転換だ。AIエージェントも、人間のユーザーアカウントと同様にアイデンティティ管理の対象になる。 明日から意識すべきポイントは3つある： エージェントのインベントリ化を今すぐ始める: 社内に何個のエージェントが稼働しているかを把握できていない時点でリスクがある。まず現状把握から着手すること Non-Human Identity（NHI）管理の設計を見直す: AIエージェントはサービスアカウントやAPIキーと同じく「人間ではないアイデンティティ」として管理が必要になる。既存のIAMフレームワークにエージェントをどう組み込むかを今から検討しておく 最小権限の原則を徹底する: エージェントに「必要以上のアクセス権」を与えないことがリスク低減の基本。Just-In-Timeアクセス制御をエージェントにも適用する設計を標準にすべきだ 監視なしのエージェントがどれほどの被害をもたらすか——AIエージェントが意図せずAWSで多額の費用を発生させた事例が話題になったように、エージェントの暴走コストは甚大だ。ガバナンス基盤の整備は「あったら便利」ではなく「必須インフラ」の問題になってきている。 筆者の見解 AIエージェントのガバナンス基盤は、これから1〜2年で企業ITの最重要課題になると見ている。「エージェントを使いこなす前に、管理できる状態を作る」——この順序は間違いなく正しい。 Microsoftがこの問題に本腰を入れてきたこと自体は評価したい。他社製エージェントも管理対象に含めるオープンな設計は、プラットフォームとしての全体最適を志向するMicrosoftらしいアプローチだ。Microsoft 365が持つ深いデータ統合と認証基盤との組み合わせで、エージェントガバナンスに強力な土台を提供できるポテンシャルは確かにある。 正直に言えば、「もう少し早く来てほしかった」という思いもある。エージェント市場が爆発的に拡大している今、ガバナンス側が後追いになってしまっているのはもったいない。これだけのインフラ資産を持っているのだから、先行してこの問題を定義できる立場にいたはずだ。 とはいえ、「早くて中途半端」よりも「しっかりとした仕組みが遅れて来る」方が長期的には価値がある。NHI管理の観点から、エージェントに最小権限を付与しJust-In-Timeでアクセスを制御する仕組みがMicrosoftの標準プラットフォームとして整備されれば、日本企業の自動化推進は大きく前進するはずだ。その期待を込めて、今後の展開を注視していきたい。 出典: この記事は Microsoft launches tracker to manage autonomous AI in the workplace の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月11日、Power Platformの大型月次アップデートを公開し、AIエージェントの「クローズドループ学習」機能をはじめ、コネクタガバナンスの強化、インベントリAPI、RPAデバッガーのバージョン比較対応など、エンタープライズ向けの機能が一挙に追加された。 今回のアップデートの主要機能 クローズドループエージェント学習 今回の目玉機能が「クローズドループエージェント学習（Closed-loop Agent Learning）」だ。AIエージェントが実行した処理の結果をフィードバックとして取り込み、次回以降の意思決定に反映させる仕組みである。 従来のPower Automateフローは「設計者が明示的に定義したロジックを実行する」だけだったが、クローズドループ学習を組み込んだエージェントは実行結果を自分で評価して改善していく。受注データの分類精度を自ら向上させたり、異常検知のしきい値をビジネスの実態に合わせて動的に調整したりするユースケースが想定される。 コネクタガバナンスとインベントリAPI Power Platformではサードパーティ製「コネクタ」を通じて数百のサービスと連携できるが、企業IT管理者の長年の悩みは「どのコネクタが使われているか把握できない」「未承認のコネクタがセキュリティリスクになる」という点だった。 今回追加されたコネクタガバナンス機能とインベントリAPIにより、テナント内で使用中のコネクタを一覧化し、承認・禁止のポリシーをAPIレベルで制御できるようになった。さらにCMDB（構成管理データベース）との連携により、コネクタの使用状況を既存の資産管理ツールに統合できる。ServiceNowやその他のITSMツールと組み合わせれば、Power Platform全体のガバナンスを一元管理する基盤になりえる。 RPAデバッガーのバージョン比較対応 Desktop Flow（デスクトップ自動化）のデバッガーが強化され、フローの異なるバージョン間での差分をビジュアルに比較できるようになった。更新後に挙動が変わった際の原因特定が大幅に効率化される。 実務では「誰かが修正したフローで別の担当者のワークフローが動かなくなった」というトラブルが頻繁に発生する。バージョン比較機能はそうした現場課題を直接解決する実践的な強化だ。 実務への影響 IT管理者へ: コネクタガバナンスのAPIとCMDB連携は、ゼロトラスト戦略の観点でも重要だ。使用中のコネクタが把握できていない状態は、認可されていない接続経路が存在するリスクと同義である。今回の機能を活用して、まず「現状の棚卸し」から着手することを強く推奨する。 開発者・市民開発者へ: クローズドループ学習を活用するには、エージェントに「何を正解とするか」を明確に定義するフィードバックループの設計が不可欠だ。「なんとなくAIに任せる」ではなく、ビジネスロジックの評価軸を先に定義してからエージェントを構築する順番が重要になる。 全社展開を検討している企業へ: インベントリAPIはPower Platformガバナンスの「見える化」に直結する。CISOや情報システム部門が全社展開に慎重なケースの多くは「何が動いているかわからない」という不安からきている。このAPIがその心理的障壁を下げる可能性がある。 筆者の見解 Power Platformのアップデートサイクルは一貫して速く、今月も企業が実際に困っているポイントを正面から突いた機能が揃った印象だ。特にコネクタガバナンスとCMDB連携は「自動化を広げたいが統制が怖い」というIT部門の典型的なジレンマに対する、現実的な回答になりえる。 クローズドループ学習については、「エージェントが自ら学習する」という言葉のインパクトに対して、実際の運用設計は丁寧に行う必要がある。学習の方向性を定義するのは結局人間であり、フィードバックループの品質がエージェントの品質を決める。「AIに任せたら勝手に良くなる」という期待値のズレは、現場でしっかり管理しなければならない。 もったいないと感じるのは、これだけ実用的な機能が揃っているにもかかわらず、日本の大企業では「Power Platform＝市民開発のおもちゃ」という認識がまだ残っているケースがあることだ。エンタープライズグレードのガバナンス機能が整ってきた今、その認識をアップデートする絶好のタイミングに来ている。Microsoftはこの領域できちんとした実力を持っているのだから、現場がその実力を正当に評価できる環境を作っていくことが重要だ。 出典: この記事は What’s New in Power Platform: June 2026 Feature Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月5日（9日更新）、メッセージセンター通知MC1381110を通じて、ライセンスが割り当てられていないOneDrive for Businessアカウントのデータを、未払い状態が365日を超えた時点で削除すると発表した。保持ポリシーやeDiscovery保留が存在していても削除対象となるという点が、これまでの運用との決定的な違いだ。 何が変わるのか——従来との決定的な違い これまでのMicrosoft 365では、退職・異動でライセンスを剥奪されたOneDrive for Businessアカウントは、Microsoft 365アーカイブに移行したうえで、保持ポリシーや訴訟ホールド（eDiscovery保留）が存在する限り削除されずに残り続けた。 今回の変更はその前提を覆すものだ。2026年7月以降、未ライセンス状態が365日を経過したOneDrive for Businessアカウントのデータは、保持ポリシー・保持ラベル・eDiscovery保留・プリザベーションロックの有無にかかわらず削除される可能性がある。 Microsoftの公式ドキュメントには「12カ月の未払いアーカイブ後、OneDriveデータは保持設定・保持ポリシー・eDiscovery・すべての保留にかかわらず削除される可能性がある（might be deleted）」と記載されている。「might be deleted（削除される可能性がある）」という表現にとどまっているが、実際には「will be deleted（削除される）」に近い運用を想定すべきだろう。 スケジュールと対象テナント 有効開始: 2026年7月上旬（テナントごとに段階展開） 対象外: 教育機関・政府機関テナント 猶予期間: ライセンス削除後365日間 展開はテナントによって段階的に行われるため、正確な削除日はテナントごとに異なる。ただし、2025年6月以前にライセンスを剥奪されたアカウントは、7月のロールアウト後すぐに削除対象となる可能性があることを念頭に置いておきたい。 影響範囲を確認する方法 SharePoint管理センターには「ライセンスのないOneDrive for Businessアカウントレポート」が提供されており、未ライセンスアカウントの一覧と、そのアカウントがアーカイブに残っている理由（保持ポリシー、訴訟ホールド等）を確認できる。 「retention policy, active lock（保持ポリシー、アクティブロック）」と表示されているアカウントも、今後は保護対象外となる点に注意が必要だ。 管理者が取るべき対応は大きく3つだ： SharePoint管理センターで未ライセンスアカウントを棚卸し — レポートで全件確認し、未ライセンス化からの経過日数を把握する 保全が必要なデータの特定 — コンプライアンス担当・法務部門と連携して、どのアカウントのデータを継続保存すべきか判断する Azureサブスクリプション経由での保存継続か削除受け入れかを判断 — 本当に保全が必要なアカウントはMicrosoft 365アーカイブの課金を開始し、それ以外は削除を受け入れる方針を明確化する 実務への影響——日本のIT管理者が今すぐやること コンプライアンスや情報ガバナンスを重視する組織にとって、今回の変更は見過ごせない。特に以下のシナリオに該当する場合は即座の対応が必要だ： 訴訟・調査中のケースでeDiscovery保留をかけているアカウントがある 退職者のOneDriveデータに未処理の保持ポリシーがかかっている 定期的なライセンス棚卸しを実施していない、または担当者が曖昧な状態になっている Microsoft 365ではライセンス管理と情報ガバナンスが別々の担当者・チームに分かれていることが多い。今後はライセンス担当とコンプライアンス担当が連携して、アカウントのライフサイクル管理を一体で回す体制が不可欠になる。 特に重要なのは、「保持ポリシーがかかっているから大丈夫」という思い込みを今すぐ捨てることだ。2026年7月以降は、ライセンスの有無が保持ポリシーより上位の条件として機能する。これは従来の情報ガバナンス設計の根幹に関わる変更であり、既存の運用ドキュメントやポリシーの見直しも必要になる。 筆者の見解 15年にわたるOffice 365の歴史の中で、未ライセンスアカウントが大量に蓄積されてきたことは事実であり、今回の方針変更はMicrosoftにとっても管理者にとっても、合理的な整理の機会といえる。放置されたままのデータは、ストレージコストとセキュリティリスクの両面で組織にじわじわと負担をかける。「必要なデータは払って保存する、不要なものは削除する」というシンプルな原則への回帰自体は、正しい方向性だ。 一方で、保持ポリシーやeDiscovery保留を「強制的に無効化して削除する」という判断は、コンプライアンス管理者にとって相当なインパクトがある。これまで「保持ポリシーをかけておけば安全」という前提で運用設計をしてきた組織は少なくないはずだ。その前提を実質1カ月足らずの猶予で変えるのは、真面目にガバナンスを構築してきた組織ほど困る、という皮肉な構造になりかねない。 M365は統合プラットフォームとして正しく活用されているほど、ライセンス管理・保持ポリシー・eDiscoveryが複雑に絡み合う。このようなガバナンスの根幹に関わる変更には、本来であればもう少し長い移行期間と、組織の法務・コンプライアンス担当者が腰を据えて対応できる準備期間を設けてほしかった。こうした点については、Microsoftにはより丁寧なコミュニケーションを期待したい。 今回の変更を、ライセンス管理・保持ポリシー・eDiscoveryの三者を統合的に見直す機会として活用してほしい。M365は「バラバラに使うと意味がない」プラットフォームだ。アカウントのライフサイクル管理を起点に、情報ガバナンス全体の設計を一度点検する絶好のタイミングである。 出典: この記事は Microsoft to Delete Unlicensed OneDrive for Business Accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が 2026年6月4日、Microsoft 365 Copilot のリモートコード実行（RCE）脆弱性 CVE-2026-45497（CVSS 7.7）と、Exchange Online の情報漏洩脆弱性 CVE-2026-48579（CVSS 9.1）を開示した。両脆弱性とも開示時点ですでにサービス側での修正が完了しており、ユーザー側でのパッチ適用は不要だ。 今回開示された脆弱性の内容 今回公開されたのは「June 2026 Early Security Updates」と呼ばれる、月例 Patch Tuesday に先行するクラウドサービス向けの早期セキュリティ更新パッケージだ。9件の CVE が含まれ、うち以下の2件が金融機関にとって特に注目すべき内容だった。 CVE-2026-45497（CVSS 7.7 / 重要） Microsoft 365 Copilot のリモートコード実行脆弱性。根本原因はコマンドインジェクションで、公開されたベクターには「S:C（スコープ変更）」フラグが含まれている。これは、攻撃に成功した場合に Copilot サービスの境界を越えて Microsoft 365 の他のコンポーネントへ影響が及びうることを意味する。単体サービスの誤動作にとどまらない、より広範な影響を持つ欠陥だった。 CVE-2026-48579（CVSS 9.1 / 緊急） Microsoft Exchange Online の情報漏洩脆弱性。CVSS 9.1 という高いスコアが示すように、悪用された場合の影響は深刻だ。メールや添付文書など機密性の高い情報が対象となりうる。 両脆弱性とも、Microsoft 側のサービス修正はすでに完了しており、テナント管理者や IT 部門が個別に適用するパッチは存在しない。 「パッチ不要」はゴールではなく出発点 クラウドサービスの脆弱性対応は、オンプレミスのそれとは構造が根本的に異なる。Microsoft はクラウドサービスを自社で運営しているため、CVE を公開する前に修正をサービス側に適用し、後から透明性のために CVE として記録する。これが「Early Security Updates」という名称の意味するところだ。 比較として、2026年5月の Patch Tuesday では Netlogon や DNS の修正を実際のサーバーに手動で適用する必要があった。今回はその逆で「修正はすでに終わっている。CVE はその記録だ」という性質のものだ。 しかし銀行・信用金庫・住宅ローン会社など規制対象の金融機関にとって、「パッチ不要」は会話の終わりではなく始まりに過ぎない。 金融機関が直視すべき3つの問い 1. どの業務でCopilotが使われているか把握できているか Copilot はすでに融資担当者・引受担当者・コンプライアンスチームの日常業務に入り込んでいる。メール要約、社内メモ作成、ローン書類の整理といった業務がその代表例だ。この「業務の中心にいるアシスタント」に RCE 脆弱性が存在していたという事実は、規制当局への説明責任の観点からも看過できない。 ...

MicrosoftがMicrosoft TeamsとOutlookに対し、会議UIの刷新・大規模イベント対応強化・モバイルの日程調整改善など複数のアップデートを近日中に順次展開することを明らかにした。 Teams会議ツールバーが刷新——ボタンの固定・並べ替えが自由に 今回のアップデートの目玉のひとつが、Teams会議中に表示されるツールバーの再設計だ。現状はボタン配置が固定されており、「よく使う機能にすぐ手が届かない」と感じるユーザーが多かった。新しいデザインでは、ボタンを任意に固定・並べ替えできるようになる。 一見地味に見えるが、会議中の操作ストレスを減らす効果は体感で大きい。「画面共有」「チャット」「挙手」など自分のワークスタイルに合わせて最前面に配置し直すだけで、会議中に「あのボタンどこだっけ」と画面をさまよう時間がなくなる。 Efficiency Mode——非力なデバイスでも快適な会議を 注目すべき新機能が「Efficiency Mode」だ。企業内には古いPCや性能の低いデバイスが一定数存在する。Teams会議でCPUやメモリが圧迫されると会議中に他の作業ができなくなるケースが多く、「Teamsが重い」はIT管理者にとって定番の苦情だった。 Efficiency Modeはリソース制約デバイス向けにTeamsの処理負荷を意図的に抑える機能で、映像品質を若干落とす代わりに他のアプリへのCPU割り当てを確保する。ハードウェア更新の予算が取りにくい組織では、展開するだけで現場の不満が一定数解消される可能性がある。 最大1,000人のブレークアウトルームが解禁 グループワークや研修での活用が広がっているブレークアウトルーム機能について、参加者上限が最大1,000人規模まで大幅に引き上げられる予定だ。 大企業の全社研修、ハイブリッド型の大規模カンファレンス、パートナーイベントなど、これまでZoomやWebExを使わざるを得なかったシナリオが、Teamsだけで完結できるようになる。外部ツールの管理コスト・ライセンスコスト・セキュリティポリシー統一の観点から、Teamsへの一本化を進めたい組織には大きな後押しだ。 Outlookモバイルの日程調整が大幅強化 Outlookモバイルにも実務直結の改善が加わる。 Decline & Propose New Time対応：PCのOutlookでは以前から「辞退して別の時間を提案」ができたが、モバイルでは未対応だった。外出先で会議招待を受けることが増えた現代のビジネス環境では、これが使えないモバイルからわざわざPCを開いて操作するという非効率が生まれていた。待望の機能がようやく揃う。 スキップ時のフォロー通知：会議をスキップした際にフォローアップを促す通知が届くようになる。急なスケジュール変更で欠席した会議をそのまま忘れてしまう——よくある失敗を防ぐ仕組みだ。 日本のIT現場への実務的影響 今回のアップデート群で、日本の現場が特に恩恵を受けそうなシナリオを整理すると以下のようになる。 大規模ハイブリッド研修の主幹ツール化: 1,000人ブレークアウトルーム対応により、全社研修や大型イベントをTeams1本で運用できる可能性が高まる PCスペック問題の一時的な緩和: Efficiency Modeを活用することでハードウェア更新コストを先送りにできるケースが増える モバイルファーストな日程管理: OutlookモバイルのDecline & Propose対応で、PCを開かずにスケジュール調整が完結する Teamsを核にM365を統合運用している組織ほど、今回のアップデートの恩恵は大きい。逆に「Teamsだけ使ってあとはバラバラ」という運用では、プラットフォーム全体の価値が半減する点は変わらない。 筆者の見解 正直に言えば、TeamsとOutlookまわりの「使い勝手の改善」はここ数年ずっと後追い感が否めなかった。競合がとっくに当たり前にしていた機能が、ようやくMicrosoft 365にも来た——という話が続いていたのは事実だ。 ただ今回のアップデートは、「ユーザーが実際に困っている場所に手を入れた」という印象がある。ツールバーのカスタマイズもEfficiency Modeも、現場から長年声が上がり続けていた要望だ。積み残してきた宿題をようやく片付けた感はあるが、それでも前進は前進だ。 TeamsはM365統合プラットフォームの核であり、会議体験の質は周辺機能の使われ方にも直結する。個別機能の比較ではなく、「日程調整→会議→タスク→ドキュメント共有」が一気通貫で動くというプラットフォームとしての総合体験を磨いていく方向性は正しい。Microsoftが持っているユーザーベースとインフラの規模を考えれば、この方向性を愚直に磨き続けることで、十分に勝負できる力があるはずだ。今後のアップデートでその蓄積が加速することを期待している。 出典: この記事は Microsoft Teams and Outlook are getting significant changes soon | Neowin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5〜7月、Microsoft 365 Copilot関連の変更をMessage Centerに多数投稿した。その大半は「ユーザーが新機能を使えるようになった」という静かな更新だが、一部は管理者がアクションを取らなければ環境に影響が出るものだ。今回はIT管理者が特に注目すべき5つのアップデートを解説する。 1. Data Security Posture Agent がプレビュー開始（MC1217155） リリース：2026年5月31日 Microsoft PurviewにLLM（大規模言語モデル）を活用した「Data Security Posture Agent」のプレビューが始まった。機密データを自動検出し、データセキュリティの現状をAIが要約・勧告する機能だ。 ここで注意すべき重要な点がある。このエージェントはデフォルトで有効化されない。 管理者がPurviewにアクセスして手動でセットアップしなければ、機能は存在しないも同然となる。 管理者が取るべきアクション： 自組織のコンプライアンス要件・リスク許容度に照らして評価する Purviewで構成・テストを担当する管理者を指定する プレビュー版の利用条件とAI分析のデータスコープを確認する 対応しなかった場合、手動でのPurview作業を継続することになり、AIが自動検出できるリスクパターンを見落とす可能性がある。GA（一般提供）前の先行評価機会も逃す。 2. Copilot StudioでClaude Sonnet 4.5が廃止——6月30日が期限（MC1296875） 期限：2026年6月30日 Microsoftコミュニティで最も注目を集めているアップデートだ。Copilot Studioで使用可能なAnthropicのClaude Sonnet 4.5モデルが廃止（retired）状態に移行する。 6月30日以降、Claude Sonnet 4.5を使用しているエージェントはMicrosoftによって自動的にClaude Sonnet 4.6へマイグレーションされる。30日間の延期（deferral）は可能だが、これはマイグレーションを防ぐ手段ではなく遅延措置にすぎない。 Microsoftが「Plan for Change」に分類する変更であり、管理者アクションが明示的に求められている。 管理者が取るべきアクション： Copilot Studio内でClaude Sonnet 4.5を使用しているエージェントを洗い出す Claude Sonnet 4.6での動作検証を期限前に完了させる 内部の移行期限を設定し、エージェント設定担当者に周知する よくある失敗パターン：自動マイグレーション後に本番環境でレスポンスが変わり、ユーザーからITより先に指摘される——というケースだ。自動化に任せず、事前テストで差分を確認しておくことを強く勧める。 3. TeamsでMeeting Recap リンクの共有が可能に（MC1289724） リリース：2026年6月 会議の録画・文字起こし・AIサマリー・メモを1本のURLにまとめた「Recap リンク」の共有機能が追加された。出席者がリンクを共有し、欠席者が直接アクセスリクエストを送ることも可能だ。 これまでは会議内容を共有するために、録画・文字起こし・サマリーをそれぞれメール転送したり手動でまとめたりする必要があった。Recap リンクはその手間を大幅に削減する。特にCopilotのAI議事録を活用している組織では、その成果物が格段に配布しやすくなる。 実務への影響 Data Security Posture Agentは、情報漏洩リスクへの対応が厳しくなる昨今、手動監査の限界を補うツールとなり得る。ただしプレビュー段階であり、AI分析の範囲・精度の見極めが必要なことから、セキュリティ・コンプライアンス担当との連携を早期に開始することが重要だ。 Claude Sonnet 4.5の廃止は、Copilot Studioでカスタムエージェントを構築している企業に直接影響する。6月30日という期限は目前に迫っており、エージェント台帳がなく「使っているかどうかわからない」という状態の組織は、今すぐ棚卸しを行う必要がある。 Recap リンクは小さな改善に見えるが、「AI議事録を作ったはいいが誰も見ない」という課題を解決する可能性がある。Copilotの会議機能投資を回収する上で、地味に効いてくる変更だ。 ...

Microsoft Teams Rooms on Windowsに、国際会議や多言語イベント向けの新機能「Human Interpreter Listening Mode（通訳者リスニングモード）」が追加される。参加者それぞれが会議中に任意の通訳者チャンネルを選択して音声を受聴できる仕組みで、グローバル会議のアクセシビリティを大きく引き上げる施策だ。 何が変わるのか これまでの Teams 会議では、多言語対応は主にキャプションや字幕機能、あるいはサードパーティのハイブリッド通訳サービスに頼る形が一般的だった。今回の「Human Interpreter Listening Mode」は、生身の通訳者が担当する音声チャンネルをプラットフォームに直接統合する。 具体的には以下のような動作になる： 通訳者チャンネルの個別選択: 参加者は会議 UI から通訳者ごとのチャンネルを選び、オリジナル音声と切り替えて聴取できる Teams Rooms on Windows 対応: 会議室デバイス側での操作が可能で、大型スクリーンやスピーカーシステムと連携した多言語体験が実現する インクルーシブな会議設計: AIによる自動翻訳・機械通訳とは別に、人間通訳者の品質を活かしたチャンネルを正式サポートする位置付け 国際的なカンファレンスや株主総会、グローバル全社ミーティングなど、機械翻訳の精度では対応しきれない高精度通訳が求められるシーンを明確にターゲットにしている。 AI機械翻訳との棲み分け 近年、Copilotを含む各種AIサービスが「リアルタイム翻訳」機能を強化してきた。しかしビジネスの現場では、法律・金融・医療分野の用語や微妙なニュアンス、文化的な背景を含む発言を正確に伝えるためには、依然として人間通訳者の専門性が欠かせない。 Microsoftがこのタイミングで「Human Interpreter Listening Mode」をロードマップに載せてきた背景には、AIが得意な「大量・高速・低コスト」とは別の領域——高精度・高信頼が必須のシナリオ——をプラットフォームとしてカバーしていく意図が読み取れる。 実務への影響—日本のIT管理者・エンジニアが備えるべきこと この機能が実稼働する前に、以下の準備を進めておくとスムーズだ。 1. 対象シナリオの洗い出し 自社でグローバル会議・多言語イベントをどの頻度・規模で実施しているか棚卸しする。年数回の株主総会や全社 Town Hall が対象になるか、それとも日常的な国際会議が主戦場かで、導入優先度が変わる。 2. Teams Rooms on Windows 環境の確認 本機能は Teams Rooms on Windows が前提。macOS 版やモバイルクライアントでの対応範囲はアップデートを追う必要がある。既存の会議室デバイスが Windows ベースかどうか、ファームウェアのアップデートポリシーとともに確認しておく。 3. 通訳者のオンボーディング設計 生通訳者が Teams のチャンネルに参加する運用フロー（招待方法・権限設計・通訳者用デバイス要件）を事前に整備しておく。外部通訳ベンダーとの契約条件に Teams 対応が含まれているか確認することも忘れずに。 4. 参加者向けの事前周知 会議 UI に新しい選択肢が追加されるため、特にリテラシーが多様な参加者層（役員層・社外ゲスト等）への事前説明があると会議中の混乱を防げる。 ...

Microsoft 365 Copilotが、Model Context Protocol（MCP）を基盤とした「Federated Copilotコネクター」の一般提供（GA）を開始した。Canva・HubSpot・Google Calendarなどの外部サービスデータをMicrosoft 365内に保存・索引することなくリアルタイムで取得・活用できる新機能だ。 Federated Copilotコネクターとは何か これまでのCopilotコネクター（旧称：Microsoft Graph コネクター）は、外部データをMicrosoftのサービスにインポートして索引登録するアーキテクチャだった。つまりデータのコピーをMicrosoftのクラウド上に持つ必要があり、データガバナンスやコンプライアンスの観点から慎重な検討が必要だった。 Federated Copilotコネクターはアーキテクチャが根本的に異なる。データは外部サービス側にとどまり、Copilotがリアルタイムにアクセスして取得する方式だ。この仕組みを支えるのがModel Context Protocol（MCP）——LLMと外部ツール・データソースを標準化された形で接続するプロトコルである。 アクセスはユーザーのIDを使ったリアルタイム認証で行われるため、ユーザーが本来アクセスできないデータを取得することはない。Copilotがユーザーの代わりに動くが、権限は元のユーザーのものを引き継ぐ形になる。 対応サービスと利用できる機能 GA時点で対応するMicrosoft公開コネクターは以下の通り： サービス カテゴリ Canva デザイン HubSpot CRM Google Calendar カレンダー Google Contacts 連絡先 Linear プロジェクト管理 Intercom カスタマーサポート Notion ナレッジベース S&P Global / Moody’s / LSEG 金融データ ユーザーはこれらのコネクターを以下の3つのインターフェースから利用できる： Researcherエージェント：複数ソースを横断した調査タスク Microsoft 365 Chat：日常的な情報検索・整理 Agent Mode in Excel：スプレッドシート内での外部データ活用 管理者が知っておくべき設定と注意点 Federated CopilotコネクターはMicrosoft 365 Copilot Premiumライセンスを持つ組織にデフォルトで有効の状態で提供される。管理センターの「Copilot → Connectors」で確認・管理できる。 重要なのは7日間の管理者専用レビュー期間の存在だ。コネクターがユーザーに公開される前に、管理者はこの期間を使ってコンプライアンスリスクや自社ポリシーとの整合性を確認できる。具体的には： Entra IDのグループターゲティングを使った段階的ロールアウト 特定コネクターの個別無効化 CLIを使った全コネクターの一括無効化（後から個別に再有効化） また、Microsoftは利用規約の中で重要な点を明示している。データコントローラーとしての責任はユーザー組織側にある。第三者サービスとのデータのやり取りを承認しているのはあくまで組織であり、データ残存地域や第三者契約の確認は組織の義務だ。 実務への影響 IT管理者へ：デフォルト有効という点を見落とすと、気づかないうちにGoogle CalendarやHubSpotとのデータ連携が始まる。展開前に必ずコネクター一覧を確認し、自社のデータ分類・情報セキュリティポリシーと照合すること。特に金融機関・医療機関・官公庁など規制産業では、有効化前に法務・コンプライアンス部門との確認が必須だ。 ...

Anthropicが提供するAIコーディング支援ツール「Claude Code」のGitHub Actionに、プロンプトインジェクションによってCI/CDワークフローのシークレットへアクセスできる脆弱性が存在していた。MicrosoftのThreat Intelligence（脅威インテリジェンス）チームがこの経路を発見し、Anthropicへの責任ある開示（Responsible Disclosure）を経て修正が完了している。 何が起きたのか：プロンプトインジェクションとCI/CDの交差点 Claude Code GitHub Actionは、GitHub Actionsのワークフロー内でClaudeを直接呼び出し、コードレビュー・テスト生成・ドキュメント作成などを自動化するためのOSSコンポーネントだ。AIエージェントをCI/CDパイプラインに組み込む取り組みとして注目を集めており、多くのプロジェクトで採用が広がっていた。 Microsoftが発見した脆弱性は「プロンプトインジェクション」と呼ばれる攻撃手法を利用する。攻撃者が悪意のある指示をプルリクエストのコメント、コミットメッセージ、またはリポジトリ内のファイルに埋め込むと、それをClaude Codeが解釈・実行してしまう可能性があった。 具体的な攻撃チェーンは以下のような流れだ： 悪意のある入力の埋め込み：攻撃者がプルリクエスト等に、Claudeへの命令を模した文字列を含める AIによる指示の誤認識：Claude Code GitHub Actionがその内容を処理する際、埋め込まれた指示を正規の命令と誤認する シークレットへのアクセス：特定の条件が揃うと、ワークフロー内で利用可能なシークレット（APIキー、認証情報など）が漏洩するリスクがあった この攻撃が成立するには「特定の条件」が必要であり、すべての環境で無条件に発火するものではなかった。しかしオープンなリポジトリや、外部からプルリクエストを受け付けている環境では現実的な脅威となりうる。 Anthropicの対応：責任ある開示プロセスが機能 Microsoftは発見後、Anthropicに責任ある開示を行った。Anthropicはこれを受けて、Claude Code GitHub Actionに対する緩和策（ミティゲーション）を実施し、修正済みバージョンをリリースしている。 AIエージェントのセキュリティ問題に対する業界の対応速度はまだ成熟途上にある中で、今回のケースでは責任ある開示のプロセスが適切に機能した。MicrosoftとAnthropicの双方がセキュリティコミュニティの標準的なルールに従ったことは、業界全体にとって良い前例となる。 AIエージェント時代のCI/CDセキュリティ：何を対策すべきか このインシデントが示す本質的な課題は、「AIエージェントをパイプラインに組み込む際の権限設計」だ。CI/CDでAIを使う場合のベストプラクティスをまとめると以下になる。 最小権限の徹底 GitHub ActionsでClaude Code等のAIアクションを使用する際は、ワークフローに必要最小限の権限のみを付与する。GITHUB_TOKENのスコープを可能な限り絞り、シークレットへのアクセス権も必要なもののみに限定する。 出典: この記事は Securing CI/CD in an agentic world: Claude Code Github action case の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、エンタープライズ向けエージェントがMicrosoft 365のコンテキストやツール、Copilotの知性を安全に利用するための「Work IQ API」を、2026年6月16日（月）に一般提供（GA）開始すると発表した。エージェント開発者がM365データへの独自のRAGスタックやガバナンス基盤を自前で構築せずとも、テナント境界・監査・権限制御を備えた形でM365全体の情報にアクセスできる仕組みが整う。 Work IQ APIとは何か Work IQ APIは、Chat・Context・Tools・Workspacesの4つのAPIドメインで構成される、エージェント向けM365インテリジェンスレイヤーだ。 Chat API: M365 Copilotが持つ応答能力全体へのプログラムアクセスを提供する。エージェントからCopilotの回答生成能力を呼び出せる Context API: メール・カレンダー・Teams・ファイル・SharePoint・OneDriveといった職場データを、エージェントが消費しやすい最適化された形式で返却する Tools API: ファイル操作・メール送信・会議スケジュールなどのM365アクションをエージェントから実行できる Workspaces API: エージェントが中間状態を保存・参照するための作業領域を提供する これら4つのAPIを組み合わせることで、エージェントはM365テナントの情報を読み書きしながら、人間の代わりに業務フローを自律実行できるようになる。 GAで提供される主要機能 GA時点で利用可能になる機能として、Microsoftの開発者ブログは以下を明記している。 エージェント間通信（A2A） Agent-to-Agent（A2A）プロトコルのサポートにより、Work IQ APIを呼び出すエージェント同士が委譲・連携できる。複数のスペシャリストエージェントをオーケストレーターが束ねるマルチエージェント構成で活用しやすい。 リモートMCPサーバー（再設計版） Model Context Protocol（MCP）向けのリモートサーバーが刷新される。MCPはローカルとリモートの2形態があるが、GAではリモートMCPが整備され、ツールスタイルでWork IQ機能にアクセスできる。 REST API 標準的なREST APIアクセスにより、既存のアプリケーションやサードパーティエージェントからWork IQを呼び出せる。Microsoftはサードパーティエージェントからの呼び出しも正式にサポートすると明言している。 ライセンスとコスト構造 Work IQ APIの利用料金は、Copilot Creditsによる従量課金モデルを採用する。Work IQ API専用のSKU・サブスクリプション・ユーザーライセンスは存在せず、既存のCopilotクレジット枠から消費される形になる。 この構造が意味するのは、利用量をコントロールしやすい反面、エージェントが想定外のツール呼び出しを繰り返すとクレジット消費が膨らむという点だ。Microsoft自身も管理者向けのコストコントロール機能の整備を強調しており、事前に使用量を試算した上で予算キャップをかけることを推奨している。 セキュリティとガバナンス Work IQ APIがエンタープライズ環境に向けて特に強調するのがガバナンス面だ。 テナント境界の厳格な管理: 他テナントのデータへのアクセスは設計上できない パーミッション・トリミング: 委任ユーザーコンテキストに基づき、呼び出しエージェントが本来アクセスできない範囲のデータは返却されない 監査ログ: エージェントがどのAPIを何回呼び出したかが記録される 管理者によるコストコントロール: テナント管理者がCopilotクレジット消費に上限を設けられる エージェントがメール送信・会議作成・ファイル操作といった破壊的アクションを取れる以上、権限設計と監査体制の整備は必須だ。 実務への影響――日本のエンジニア・IT管理者へ エージェント構築者へ 自前でM365データ連携のRAGレイヤーを構築していた開発者は、Work IQ APIへの移行を検討する価値がある。特に以下のケースでは効果が高い： 社内エンタープライズアシスタントが「社員の予定・メール・ファイル」を横断して回答する必要がある Copilot Studioで構築したエージェントを、社外のPythonやNode.jsアプリから呼び出したい マルチエージェント構成で、専門化されたエージェント同士に業務を委譲させたい まず検証すべき3点 必要なプロトコルの確認: A2A（エージェント委譲）・REST（アプリ統合）・MCP（ツールアクセス）のどれが自分のユースケースに合うかを先に絞る 認証・権限の事前テスト: Microsoft Learnには委任ユーザーコンテキストへの言及があるが、実テナントでの挙動確認が不可欠。本番前に検証環境で試す Copilotクレジット消費の試算: 「ツール呼び出し1回あたりのクレジット消費×想定呼び出し数」を算出し、月間コストの上限を管理者と合意してから開発を進める 6月16日以降に確認すること 現時点でMicrosoft Learnにはプレビュー時点の記述が残っているため、GA後のドキュメントで最終的なエンドポイントと制約事項を必ず再確認する必要がある。プレビューと仕様が変わっているケースは珍しくない。 ...

Microsoftのセキュリティ部門が、12ヶ月にわたるエージェントAIシステムへのレッドチーミングを通じて新たに7つの失敗モードを特定し、実環境での攻撃急増を受けてリスク分類体系を大幅に更新した。 エージェントAIへの攻撃が「実害」のステージへ これまでエージェントAIのセキュリティリスクは「将来の懸念」として扱われることが多かったが、状況は変わった。Microsoftのレッドチームによれば、実環境においてエージェントAIを標的にした攻撃が急増しており、もはや理論的なシナリオではない。 エージェントAIとは、目標を設定されると自律的にツールを呼び出し、複数のステップを踏んで課題を解決するシステムだ。Microsoft 365 CopilotやAzure AI Foundryで構築されるカスタムエージェントがその代表例で、メール処理・ドキュメント生成・コード実行・外部API呼び出しなど広範な操作を自律的にこなす。その「自律性」こそが新たな攻撃面を生んでいる。 新たに特定された7つの失敗モード 1. サプライチェーン侵害（Supply Chain Compromise） エージェントが参照する外部ツール・ライブラリ・モデルが改ざんされるリスク。人間のコードと同様に、AIが呼び出すコンポーネントも検証が必要になった。 2. ゴールハイジャック（Goal Hijacking） エージェントが処理中のデータや環境内の悪意ある入力によって、本来の目標から逸脱した行動を取らされる攻撃。プロンプトインジェクションの進化形と捉えるとわかりやすい。 3. 記憶の汚染（Memory Poisoning） エージェントが参照する長期記憶やベクターデータベースに偽情報を埋め込み、将来の判断を歪める手法。RAG（Retrieval-Augmented Generation）を活用するシステムで特に危険。 4. クロスエージェント攻撃（Cross-Agent Attacks） マルチエージェント構成において、あるエージェントを経由して別のエージェントを操作する攻撃。エージェント間の信頼モデルを悪用する。 5. 権限の過剰付与（Excessive Agency） エージェントに必要以上の権限が与えられることで、誤動作や攻撃時の被害が拡大する。最小権限原則の適用がここでも必須になる。 6. ツールの誤用誘発（Tool Misuse Induction） エージェントが持つツール（メール送信・ファイル操作・APIコールなど）を悪意ある入力によって不正に実行させる攻撃。 7. 観測回避（Observability Evasion） エージェントの動作ログや監査証跡を意図的に回避・改ざんし、攻撃の痕跡を消す手法。 Microsoftが示す実践的な緩和策 レッドチームの知見をもとに、Microsoftはいくつかの具体的な対策を提示している： 入力検証の厳格化：エージェントが処理するすべての外部入力（ユーザー入力・ツール出力・外部API応答）を信頼しない設計 最小権限の徹底：エージェントへの権限付与はタスクに必要な最小限に留め、Just-In-Time（JIT）アクセスを活用する エージェント間の信頼境界の明示：マルチエージェント環境では、エージェント同士が無制限に信頼し合わない設計にする 可観測性の確保：すべてのエージェント動作を詳細にロギングし、異常行動を検知できる仕組みを入れる サプライチェーン検証：エージェントが呼び出すツール・モデル・ライブラリの整合性を定期的に確認する 日本のエンジニア・IT管理者への影響 このレポートが示すリスクは、「エージェントAIを本番導入しているなら今すぐ対応が必要」というレベルの話だ。 日本企業でも、M365 Copilotのカスタムエージェントや、Azure AI Foundryを使った業務自動化の導入事例が急速に増えている。特に注意すべきは以下の点だ： Non-Human Identities（NHI）の管理が急務：エージェントAIはサービスプリンシパルやマネージドIDとして動作する。これらの権限管理が甘いと、エージェントが侵害された際の被害が組織全体に及ぶ。Entra IDでのJITアクセス設定と定期的な権限棚卸しを実施すること。 社内RAGシステムの汚染対策：SharePointや社内ドキュメントをベースにしたRAG構成を持つ場合、そのナレッジベースへの不正書き込みが記憶汚染攻撃の起点になりうる。ドキュメントの書き込み権限と読み取り権限を分離し、変更監査ログを有効にする。 マルチエージェント設計時の信頼境界定義：複数エージェントを連携させるフローでは、各エージェントが受け取る入力の信頼レベルを設計段階で明示する。「上位エージェントからの指示だから信頼する」という設計は危険だ。 筆者の見解 このレポートは、Microsoftのセキュリティ組織が1年間の実戦的なレッドチーミングから得た知見をまとめたもので、内容の質は高い。エージェントAIのリスクを「ベンダーがよく言う将来の脅威」ではなく「今起きている問題」として体系化した点は、現場にとって価値がある。 私がここで強調したいのは、このリスクはCopilotだけの話ではないということだ。Azure AI FoundryでカスタムエージェントをPythonで実装していても、LangChainや他のフレームワークを使っていても、エージェントが外部ツールを呼び出す構造を持っている時点で同じリスクを抱えている。 とりわけ気になるのはNHIの権限管理だ。「エージェントを動かすためにグローバル管理者権限のサービスプリンシパルを使う」という実装を、今もゼロにはなっていないと思う。エージェントAIの登場で、Non-Human Identitiesの数は今後さらに爆発的に増える。ここを甘く見ていると、エージェントが侵害された際の被害範囲がそのまま組織全体になる。 Microsoftにはこのような知見を、ドキュメントだけでなく製品側の「デフォルト設定」に反映してほしい。最小権限でエージェントを動かすのが「難しい選択肢」ではなく「一番簡単な選択肢」になるような設計を、Foundryやその周辺ツールで実現できるはずだ。力があるからこそ、そこまで踏み込んでほしいと思う。 出典: この記事は Updating the taxonomy of failure modes in agentic AI systems: What a year of red teaming taught us の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月20日、PowerShell開発者に対してモジュールの取得元をMicrosoft Artifact Registry（MAR）へ移行するよう求めるブログ記事を公開した。長年にわたってコミュニティの中心地であったPowerShell Galleryのセキュリティリスクを直視し、Microsoft公式モジュールの配布を自社管理の信頼済みリポジトリに一本化する方針を明示したものだ。 Microsoft Artifact Registry（MAR）とは何か MARは、Dockerイメージなどのコンテナアーティファクトに加え、PowerShellモジュールを含む各種ソフトウェアパッケージをMicrosoftが一元管理する公式レジストリだ。その最大の特徴は「Microsoft管理の公開パイプライン」という点にある。つまり、誰でも公開・更新できるPowerShell Galleryとは異なり、MARに登録されているMicrosoftモジュールは出所が明確で、改ざんや悪意ある模倣モジュールのリスクを排除できる。 Microsoftが示す主な優位性は以下の3点だ： 強固なプロビナンス（出所保証）と所有者保証：誰が何を公開したか追跡可能 PowerShell Galleryと比べて高い可用性：SLA観点での安定供給 コミュニティミラーへの依存排除：ファーストパーティモジュールをコミュニティ経由で取得する必要がなくなる 新しいモジュール管理ツール「PSResourceGet」 合わせてMicrosoftが推奨するのがPSResourceGet（旧PowerShellGet v3）の採用だ。このツールは「パッケージの探索（discovery）」と「インストール（consumption）」を明確に分離して設計されており、複数リポジトリを管理しながら本番環境ではMAR等の信頼済みソースからのみインストールする、という運用が可能になる。 MARをPSResourceGetに登録する基本コマンドは次のとおりだ： 出典: この記事は Microsoft Wants PowerShell Developers to Change How They Download Microsoft Modules の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Build 2026（6月2日）で発表した「Scout」は、Microsoft 365に常時稼働するAIエージェントとして、ユーザーの指示を待たずにメール整理・会議要約・スケジュール調整を自動実行する新しいワークエージェントだ。しかし、その基盤となる「OpenClaw」フレームワークのガバナンス課題が、当初の2026年3月リリース計画を遅延させていたことが内部文書で明らかになった。 Scout とは何か Scout は従来の Copilot とは根本的に異なる設計思想を持つ。Copilot がユーザーの質問・指示に応答する「リアクティブ型」であるのに対し、Scout は「プロアクティブ型」だ。ユーザーが会議中でも、バックグラウンドでプロジェクト提案書を下書きし、レビュー送付まで完了する——Build のデモで披露されたのはそういうシナリオだ。 Scout は Microsoft Graph 全体（メール・チャット・ファイル・カレンダー等）にアクセスし、ユーザーの業務パターンを学習する。この「常時稼働＋自律行動」という組み合わせが、従来の AI アシスタントとの最大の差異点だ。 OpenClaw：エージェントを動かすフレームワーク Scout のエンジンが OpenClaw だ。2025年末に初公開されたこのフレームワークは、エージェントが「ステートフル」に動作できる点が革新的だ。従来のチャットボットが1回の会話で状態をリセットするのに対し、OpenClaw エージェントは数時間〜数日にわたって文脈を保持し続ける。 Microsoft Graph への接続管理、認証トークンの制御、コンプライアンス境界の強制、すべてのアクションの監査ログ生成——これらを OpenClaw が担う。金融・医療・法務など規制業界での利用を想定した設計だ。 ガバナンスと権限管理の課題 問題は権限モデルだ。内部文書によると、OpenClaw の初期バージョンは細粒度の権限モデルが欠如しており、エージェントがユーザーの意図以上のデータにアクセスできる状態だったという。さらに、Scout の初期ビルドがコンテンツ要約時にユーザー設定の機密ラベルを上書きできる不具合も報告されている。 現在のガバナンス設計は3層構造だ： ユーザーレベル：個人の境界設定（例：外部メール送信は確認必須） チーム管理者レベル：部門ポリシーの定義 グローバル管理者レベル：テナント全体のルール強制 この階層型アプローチは適切な方向性だが、IT 管理者にとっては新たな管理負荷を意味する。 実務への影響 日本の IT 管理者・エンジニアが今すぐ考えるべきポイントは以下の3点だ。 1. 条件付きアクセスポリシーの見直し Scout は Microsoft Entra ID の条件付きアクセスと統合される。既存ポリシーが Scout のバックグラウンド動作を想定していない場合、予期しないブロックや逆に意図しない許可が発生するリスクがある。 2. 情報保護ラベルの整備 機密ラベルの上書き問題が修正されたとしても、そもそもラベル付けが不完全なテナントでは Scout の自動処理が誤った範囲で動作する。Microsoft Purview による情報分類の整備を今から進めるべきだ。 3. Non-Human Identity（NHI）管理 Scout はエージェントとして独立した ID を持つ。これは NHI 管理の文脈そのものだ。Scout に割り当てられた権限スコープ、アクセス履歴の監査、不要になった際の権限剥奪——これらのライフサイクル管理が新たに必要になる。NHI 管理の仕組みが整っていないテナントでは、Scout の導入自体がリスクになりかねない。 ...

Microsoftは2026年6月から、Microsoft 365 Copilotアプリを対象商用WindowsデバイスへWindows Update経由で自動インストールする施策を再開すると発表した。2025年初頭に管理者の反発を受けて一時中断された経緯があり、今回は新たな管理コントロールが追加されての「再挑戦」となる。 2025年の教訓—なぜ一度中断されたのか 2025年の最初の試みでは、IT管理者が「気づいたらタスクバーにCopilotが固定されていた」という事態が多発した。事前テストや承認プロセスなしに1万台規模のエンドポイントへ突然現れるAIアシスタントは、特にコンプライアンス要件の厳しい金融・医療・官公庁系の組織において深刻な問題となった。ソフトウェア管理ワークフローへの影響も小さくなく、Microsoftは数週間で展開を停止することを余儀なくされた。 今回のアナウンスでは「フィードバックを受けて詳細な制御機能を追加した」とMicrosoftが説明しており、その言葉通り管理コントロールは前回より整備されている。 インストール対象デバイスの3条件 自動インストールが実行されるのは、以下の3条件をすべて満たすデバイスに限られる。 OS: Windows 11、またはWindows 10 22H2（サポート対象バージョン） M365アプリのバージョン: Microsoft 365 Appsのバージョン2308以降がインストール済み 更新チャネル: Current ChannelまたはMonthly Enterprise Channel 逆に言えば、Semi-Annual Enterprise Channel（SAEC）やLTSCリリースのデバイスは対象外となる。日本の大企業では安定性を重視してSAECを採用しているケースが多いため、即座に影響を受けるのは現在のチャネルに沿った環境に限られる。 アプリ本体は約12MBと軽量だが、機能を実際に使用するにはMicrosoft 365 CopilotライセンスまたはCopilot for Microsoft 365アドオンが別途必要となる点も押さえておきたい。 IT管理者が使える制御手段 今回の展開で最も重要なのが管理コントロールの充実だ。主な手段を整理する。 Microsoft 365管理センター 管理センターに新設されたポリシー 「AutoInstall M365 Copilot App」 がデフォルトで有効（Enabled）になっている。テナント全体でオフにするには、このポリシーを手動で無効化する必要がある。 グループポリシー / Intune CSP 従来の管理ツールでも制御可能だ。 グループポリシー: Administrative Templates > Microsoft 365 Copilot > 「Prevent automatic installation of the Microsoft 365 Copilot app」を有効化 Intune CSP: 同等の設定をCSP経由で展開可能 M365 Appsサービシングプロファイル: 管理センター内のサービシングプロファイルにオプトアウトチェックボックスが追加 Windows Update for Businessリングとの連動 インストールはWindows品質更新プログラムに同梱されて配信される。既存のWUfBリングによる更新延期が設定されていれば、Copilotアプリも同じ期間インストールが遅延する。ただし注意点がある。60日を超えて延期すると、後続の累積更新プログラムにアプリが同梱され、リング制御外でインストールされる可能性があるとMicrosoftは警告している。 ...

Microsoft が、Microsoft 365 Copilot の Declarative Agents において MCP（Model Context Protocol）サポートの一般提供（GA）を発表した。これにより開発者は、外部の SaaS や基幹業務（LoB）システムを Copilot チャットに直接統合できるようになり、エンタープライズのワークフロー自動化が大きく前進する。 MCPとDeclarative Agentsの組み合わせが実現すること MCP は、AI モデルが外部システムとやり取りするための標準プロトコルとして急速に普及している。これまで Copilot の Declarative Agents に外部機能を追加するには、REST API プラグインを手動で定義する必要があり、スキーマ記述や認証設定など、相当量のボイラープレート作業が伴っていた。 MCP 対応 GA によって、この状況が一変する。MCP サーバーが公開しているツール一覧を Agents Toolkit が自動的に読み込み、必要なプラグイン定義（ai-plugin.json）やエージェント設定（declarativeAgent.json）を自動生成してくれるようになった。開発者は「何をつなぐか」だけに集中すればよく、「どうつなぐか」のコードをほぼ書かずに済む。 VS Code Agents ToolkitでのMCPエージェント構築手順 Microsoft 365 Agents Toolkit（VS Code 拡張）を使った構築フローは次のとおりだ。 エージェントのスキャフォールド VS Code で「Create a new Declarative Agent」を選択。プロジェクト構造とマニフェストファイルが自動生成される。 MCP アクションの追加 「Add Action → Start with an MCP server」から MCP サーバーの URL（https://<your-server>/mcp）を入力するだけで、ツール一覧が自動取得され、プラグインスペックが生成される。 ツールの選択 MCP サーバーが多数のツールを公開している場合、セキュリティや用途に応じて使用するツールのサブセットを選択できる。 認証設定 現時点では SSO（シングルサインオン）と静的 OAuth 2.0 をデフォルトでサポート。Toolkit がウィザード形式でガイドしてくれるため、認証フローの実装コードを自前で書く必要はない。 ...

ユニファイドAPI企業のMergeが、Microsoft Agent StoreにAgent Handlerを公開した。Model Context Protocol（MCP）を活用し、M365 CopilotエージェントからSalesforce・Workday・SAPなどの外部業務システムへ、ガバナンスを維持したまま直接アクセスできる仕組みを提供する。 Merge Agent Handlerとは何か Mergeは人事・給与・会計・CRM・ATS（採用管理）など180以上の業務システムを一本のAPIで束ねる「ユニファイドAPI」プラットフォームを提供する企業だ。今回、そのプラットフォームをMicrosoft Agent StoreにAgent Handlerとして登録した。M365 Copilotのエージェントは、MCPツールとして定義されたMergeのAPIを呼び出すことで、外部の業務システムにアクセスできるようになる。 MCPがM365エコシステムに入ってきた意味 MCP（Model Context Protocol）はAnthropicが提唱したオープンプロトコルで、AIがツールやデータソースを呼び出す際の標準仕様だ。Microsoftはこのプロトコルを採用し、M365 CopilotのAgent Frameworkに組み込んでいる。 Microsoft Agent StoreにMCPサーバーを登録すれば、Copilotエージェントから呼び出せる仕組みが整う。今回のMergeの登録はその最初の大型ケースのひとつと言え、他のSaaS企業がMCPベースのAgent Handlerを展開する際のリファレンスにもなりうる。 ガバナンスを保ちながらの外部連携 今回の仕組みの核心は「ガバナンスつき」という点にある。 認証の一元管理: Mergeが各外部システムへの認証を代理で管理し、M365のIT管理者が個別のAPIキーを直接持つ必要がなくなる アクセスログの可視化: どのエージェントがどのデータにアクセスしたかを記録する スコープ制限: 必要最小限の権限に絞ったAPIアクセスが可能 M365と外部システムの間に「信頼できるブローカー」を挟む構成は、ゼロトラストアーキテクチャの考え方とも親和性が高い。 連携可能な主な業務システム MergeのユニファイドAPIが対応する代表的なシステムは以下の通りだ。 人事・給与: Workday、BambooHR、SAP SuccessFactors CRM: Salesforce、HubSpot 会計: QuickBooks、Xero、NetSuite ATS（採用管理）: Greenhouse、Lever Teamsの会話画面やOutlookのメール作成中に、これらのシステムのデータをCopilotが参照・操作できるようになる。 実務への影響——日本のIT現場での活用ポイント 今すぐ検討できる活用例 M365 Copilot + Mergeを組み合わせた「Copilot for HR」「Copilot for Sales」のような用途特化エージェントの構築 TeamsやOutlookから自然言語でWorkdayやSalesforceのデータを照会するインターフェースの実装 IT管理者がAPIキーを直接管理しない安全な外部連携基盤の構築 日本市場特有の注意点 勘定奉行・SmartHRなど国産システムへの対応状況は別途確認が必要 Mergeは外部SaaSであるため、データの流れを設計段階でしっかり把握しておくこと 現時点では英語圏向けのリリースが先行しており、日本語UIや日本企業向けサポートの展開タイムラインは不明 筆者の見解 M365 Copilotが「外」に開きはじめた。この流れは率直に歓迎したい。 これまでCopilotが企業現場で使いにくかった理由のひとつは、M365エコシステムの内側で完結しようとする傾向にあった。SharePointのドキュメントやTeamsの履歴は参照できても、SalesforceやWorkdayとの連携になった途端に壁が立ちはだかる——多くの企業が感じてきたジレンマだ。 MCPという標準プロトコルを通じてMicrosoft Agent Storeがサードパーティに開かれていくのは、プラットフォームとして正しい方向性だと思う。MicrosoftはAzureや.NETの時代から「エコシステムを育てる」ことが得意な会社だ。AI分野でも同じ戦略が機能すれば、統合プラットフォームとしての強みが活きてくる。 ただし、外部連携の口が広がるほど「誰がどのデータにアクセスできるか」の管理は複雑になる。ガバナンス機能をMergeに丸投げするのではなく、Entra IDやMicrosoft Purviewと組み合わせてM365側でも可視化・制御できる構成を検討するのが賢明だ。正面から向き合うべきはそこだろう。 ...

Microsoft は、Microsoft Purview のデータ損失防止（DLP）機能を Island Enterprise Browser と統合し、管理外クラウドアプリへのブラウザ経由データ共有をポリシーで制御できるようにした。2026年6月末から一般提供（GA）が順次開始される予定で、既存の Purview ポリシーをそのまま流用できる点が大きな特徴だ。 何が変わるのか これまで Microsoft Purview の DLP は、Microsoft 365 アプリや管理デバイスへのエンドポイント DLP、あるいは自社ネットワークを経由するトラフィックには有効だった。しかし、未管理のクラウドアプリ（会社が契約していない SaaS、個人アカウントのストレージサービスなど）に対しては、ブラウザ経由でデータが直接渡ってしまうと取り締まれない「穴」が存在した。 Island Enterprise Browser との統合はこのギャップを埋める。Island はエンタープライズ向けのセキュリティ特化ブラウザで、プレゼンテーション層（画面表示の手前）でユーザーの操作を監視できる。具体的には次のようなアクティビティを Purview が検査できるようになる： テキストの入力・ペースト ファイルのアップロード・ダウンロード ブラウザ拡張機能（アドオン）の通信 HTTP / HTTPS 経由のデータ共有 Purview に登録済みの機密情報タイプ、秘密度ラベル（Sensitivity Labels）、カスタム分類器がそのまま適用されるため、ポリシーの重複定義は不要だ。Island 側で検知した内容は Purview の Data Security Posture Management（DSPM） や Insider Risk Management（IRM） のリスクスコアにも反映される。 展開スケジュールと前提条件 フェーズ 開始時期 完了目標 パブリックプレビュー 2026年3月末 2026年4月末 一般提供（GA） 2026年6月末 2026年7月末 注意点として、この機能はデフォルトで無効になっている。管理者が Purview DLP Security Store から Island インテグレーションを明示的に有効化しない限り、エンドユーザーへの影響はない。 有効化にあたって必須の前提条件は次の通りだ： Purview の従量課金（pay-as-you-go）が有効化されていること Island Enterprise Browser、Island Extension、または対応ブラウザアドオンを組織が展開していること Purview DLP ポリシーを管理する M365 管理者権限 実務への影響 日本のエンタープライズ IT 管理者にとって、この統合が刺さる場面は主に以下の3つだ。 ...

Microsoftは2026年5月末より、Microsoft Purview データ損失防止（DLP）のポリシー同期時間を最大2時間から最大30分に短縮するアップデートをグローバルで展開している。管理者側での操作は一切不要で、Microsoft 365全体に自動適用される。 何が変わったのか Microsoft Purview DLPは、組織内のデータ（メール・Teams・SharePointなど）が意図せず外部に漏洩するのを防ぐポリシーエンジンだ。機密情報の検出ルールやブロック条件を「ポリシー」として定義し、Microsoft 365の各サービスに配布する仕組みになっている。 これまで、DLPポリシーを変更・追加した場合、その内容がすべてのサービスに反映されるまで最大2時間かかるというSLA（サービスレベルアグリーメント）が設定されていた。今回のアップデートにより、このSLAが最大30分に引き下げられる。 項目 変更前 変更後 ポリシー同期SLA 最大2時間 最大30分 管理者の操作 不要 不要（変更なし） ポリシーの動作 変更なし 変更なし データ処理・保存 変更なし 変更なし Microsoft 365ロードマップID: 558682 展開スケジュール: 2026年5月下旬〜2026年6月下旬（全世界） 技術的な背景：なぜ「同期遅延」が問題だったか DLPポリシーの反映遅延は、一見地味な技術的制約に見えるが、実際のセキュリティ運用では無視できないギャップを生んでいた。 典型的なシナリオとして、インシデント発生後に「特定キーワードを含むファイルの外部共有を即時ブロック」するポリシーを追加しても、最大2時間はその保護が有効にならない状況があった。攻撃者やインサイダーが意図的にこの「ウィンドウ」を利用するリスクは低くないが、運用上の懸念として多くの管理者が抱えていた課題でもある。 30分への短縮は、この「保護の空白」を75%削減することを意味する。ポリシー変更の即応性が上がることで、セキュリティ・コンプライアンス担当者が「変更を反映したか確認するために2時間待つ」という運用の非効率も解消される。 実務への影響：日本のIT管理者はここを押さえよ 1. セキュリティ・コンプライアンスチームへの周知が重要 Microsoftが明示しているとおり、管理者側での設定変更は不要だ。しかし、運用フローの見直しは必要になる場面がある。 これまで「ポリシー変更後は2時間後に効果確認」としていたチェックリストや手順書があれば、「30分後に確認」へ更新しておくと良い。セキュリティ担当者が変更の有効性を確認するタイミングを早められる。 2. インシデント対応手順（IR）の見直しポイント DLPポリシーはインシデント対応の初動封じ込めにも使われる。「侵害を検知してからDLPで追加ブロックをかけるまでの時間」が30分以内に収まるようになる点は、IR（Incident Response）手順の想定タイムラインに影響する。 IRプレイブックにDLPポリシー変更のステップが含まれている場合は、「最大2時間の反映待ち」という前提を修正しておきたい。 3. テナント間・マルチテナント構成での注意 展開は2026年5月〜6月末にかけて段階的にロールアウトされる。複数テナントを管理している場合、テナントによって改善タイミングが異なる可能性がある。重要なポリシー変更後は、引き続き同期状況を確認する習慣を維持しておくことを推奨する。 筆者の見解 セキュリティ領域の細かいアップデートは、ともすると「また細かいアップデートか」と流されがちだが、このDLP同期時間の短縮は地味ながら実質的に効く改善だと思う。 セキュリティにおいて「遅延」はそれ自体が脆弱性になりうる。ゼロトラストの考え方で言えば、ポリシーの反映速度は「動的なアクセス制御をどこまでリアルタイムに近づけられるか」に直結する。2時間の遅延が当たり前だった世界から、30分以内に収まる世界へ移行するのは、小さいようで運用上のインパクトは大きい。 Microsoftのコンプライアンス・セキュリティ製品群は、地道な改善の積み重ねで実用性を上げてきた歴史がある。派手な新機能ではないが、現場で使う管理者が「ちゃんと動く・ちゃんと速い」と感じられる改善こそ、プラットフォームへの信頼を積み上げるものだ。今後も、こういった「実務に刺さる地道な改善」を継続してほしいと思う。 出典: この記事は Microsoft Purview | Data Loss Prevention: Faster policy sync (2 hours to 30 minutes) の内容をもとに、筆者の見解を加えて独自に執筆したものです。