M365

Microsoft 365 Copilotのセキュリティ・管理・分析機能が大幅に強化された。目玉はMicrosoft PurviewのDLP（データ損失防止）ポリシーがCopilot ChatのWeb検索にも適用されるようになったこと。加えて過剰共有リンクの一括修復機能、M365管理センターからの可視性向上と、企業のIT管理者が切実に求めていた機能が一気に揃ってきた。 Copilot ChatのWeb検索にDLPが適用可能に これまでMicrosoft PurviewのDLPポリシーは、SharePointやTeamsといったM365内部のデータに対して機能していた。しかし今回の拡張により、Copilot ChatがWeb検索を行う際のプロンプトにも同じDLPポリシーが適用できるようになった。 具体的には、センシティブ情報（個人番号、クレジットカード番号、社内機密に該当するカスタム分類など）を含むプロンプトがWeb検索付きで送信されようとした場合、ポリシーに基づいてブロックまたは警告を出せる。 これはエンタープライズ利用において見過ごされやすいリスクへの対処だ。「Copilot Chatは社内データのみ扱う」という認識を持つ管理者も多いが、実際にはユーザーがWeb検索を併用しながら業務処理を行うシナリオは多い。そのプロンプトの中に機密データが含まれる可能性は十分ある。 過剰共有リンクの「一括修復」が登場 もう一つの実用的な強化が、過剰共有（Oversharing）リンクの一括修復機能だ。 SharePoint上の「リンクを知っていれば誰でもアクセス可能」なファイルや、組織全体に共有されているリンクは、Copilot導入後にリスクが顕在化しやすい。CopilotはユーザーがアクセスできるすべてのファイルをRAG（Retrieval-Augmented Generation）の対象とするため、意図せず広く共有されていたファイルがCopilotの回答に使われてしまう、という問題が起きうる。 これまでは管理者が1件ずつ対処するしかなかったが、今回の機能追加により、ポリシーに引っかかる過剰共有リンクをスケールで検出・修復できる。大規模テナントでの運用に耐えうる管理ツールになってきた、と評価したい。 M365管理センターの可視性向上 Copilotのアクティビティや利用状況をM365管理センターから把握しやすくなった。管理者がCopilotの活用状況を把握・報告するための基盤として、レポーティング機能も継続強化されている。 実務への影響——日本のIT管理者が今すぐやること 1. DLPポリシーの棚卸しと適用範囲の見直し すでにM365用のDLPポリシーを運用しているなら、それをCopilot Chatのスコープに拡張できるか確認する。まずはMicrosoft Purview コンプライアンスポータルで「Copilot」が適用先として選択できるか見てみよう。 2. 過剰共有リンクの実態調査を先行させる 一括修復機能を使う前に、まず現状のリンク共有状態を可視化することを勧める。SharePoint管理センターの「共有」レポートと組み合わせて、どの程度の過剰共有が存在するかを把握してから修復に入ると混乱が少ない。 3. 「禁止」ではなく「安全に使える仕組み」を整備する Web検索をDLPでブロックするだけでは、ユーザーは別の回避手段（個人アカウント、別ツール）を探し始める。DLPは「万が一の安全網」として機能させつつ、ユーザーに「公式チャネルが一番便利」と感じてもらえる環境を整えることが、長期的なセキュリティ向上につながる。 筆者の見解 率直に言って、今回の機能群は「ようやく来たか」という感想だ。Copilotをエンタープライズで安全に使うには、データ保護の仕組みと管理ツールがセットで揃っていなければならない。それが揃わないまま展開を求められてきた現場の管理者たちには、今回のアップデートは朗報だろう。 筆者が長年主張してきた「禁止ではなく安全に使える仕組みを」という考え方からすると、DLPのCopilot Chat対応はまさに正しい方向性だ。AIを禁止するアプローチは必ず失敗する。ユーザーが「公式ツールが一番安全で便利だ」と感じられる状況を作ることが、セキュリティの本質だと思っている。 その一方で、過剰共有問題はCopilot以前からSharePointの運用課題として存在していたはずで、なぜCopilot導入のタイミングまで放置されていたのかという問いも残る。これはMicrosoftというよりも、導入側の課題だ。CopilotはSharePointの「長年の負債」を一気に顕在化させるエンジンでもある。今回の一括修復機能を機に、テナント全体のデータガバナンスを見直す契機にしてほしい。 Microsoftにはこういうインフラ・ガバナンス周りで強みを発揮できる底力がある。エンタープライズへの責任感と技術力を持ってガバナンス基盤を磨き続けてくれることを、引き続き期待している。 出典: この記事は Latest enhancements for Copilot security, management, and analytics の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月16日、Microsoft 365の更新配信の仕組みを大幅に刷新した。これまでの「Targeted Release / Standard Release」という2系統から、Frontier・Standard・Deferredという新たな3チャネル体制へ移行する。しかも告知と同日に展開が始まるという、IT管理者にとっては「えっ、もう始まってるの？」という状況だ。現時点でCopilot機能に限定された変更だが、いずれ全サービスへ拡大されることが明言されている。今のうちに仕組みを把握しておくことが重要だ。 3チャネルの違いを整理する 新しいリリーストラックは以下の3つだ。 Frontier（フロンティア） 最速でAI新機能を試せる早期アクセスチャネル。ただし本番利用不可と明記されており、あくまでも「AI機能の評価・検証用」と位置付けられている。つまり、Copilotの新機能をいち早く触って社内展開の可否を判断したい情報システム部門向けのチャネルだ。 Standard（スタンダード） 一般提供（GA）になった機能を受け取る標準チャネル。多くの組織にとってメインのトラックになる。 Deferred（ディファード） 標準より約30日遅れで機能を受け取るチャネル。変更管理のプロセスが厳格な組織や、慎重に展開したい業種向けの選択肢だ。 誰に影響があるのか 現時点での影響範囲はシンプルにまとめると以下のとおり。 Copilotライセンスを持つ商用テナント → 今すぐ設定を確認すべき対象 Copilotなしの標準M365プラン → 現時点では変更なし。ただし将来的には拡張される GCC / GCC High / DoD環境 → 現時点では対象外 Microsoft 365 Apps（Word・Excel等のデスクトップアプリ） → 別系統のUpdate Channelが引き続き適用されるため対象外 個人・家族向けコンシューマープラン → 管理センターへのアクセス自体がなく、対象外 注意点として、現在Targeted Releaseを利用している組織はそのまま継続利用できる。ただし段階的にFrontier/Standard/Deferredへ統一していくことをMicrosoftは推奨している。 Message CenterとAIトラッキングの強化 今回の刷新には、更新配信の仕組みだけでなく、Message Centerの改善とAIを活用した変更追跡ツールの提供も含まれている。「何が来るか、いつ来るか」を把握しやすくすることが狙いだ。これは変更管理（Change Management）の観点から見ると、理想的には歓迎すべき方向性だ。「知らないうちに機能が増えていた」という状況をなくす取り組みは正しい。 実務への影響 IT管理者がまず取るべきアクション： Microsoft 365管理センターで現在のリリース設定を確認する Settings > Org settings > Organization profile > Release preferences から現状を把握する。 Frontierは本番テナントに設定しない 評価用途に限定するため、検証専用のテナントやサンドボックス環境に割り当てるのが基本だ。 変更管理プロセスをこのモデルに合わせて再設計する 30日のDeferredバッファは「気づいたらロールアウトされていた」を防ぐための猶予。活用しない手はない。 今後の全サービス拡張に備えて社内ルールを策定しておく Copilotから始まった変更は他のM365サービスへも順次広がる。今のうちに「うちはどのチャネルを使うか」の方針を定めておくと、後で慌てずに済む。 筆者の見解 「変更管理の強化」という方向性は、M365を管理するIT担当者の長年の要望に応えるものであり、素直に評価できる。特にDeferredチャネルは、Copilotに限らず全M365サービスに適用が広がれば、変更管理の成熟度を上げる実用的な手段になる。 ただ、正直に言えば今回の展開には「もったいない」と感じる部分もある。告知と展開が同日という運用は、IT管理者がしっかり準備して新機能を受け入れられる体制を整える機会を奪う。Microsoftには、テナントを安定運用している現場への敬意として、「最低でも2週間前の告知」という原則を守ってほしいと思う。技術的に正しいアーキテクチャへのリニューアルなのだから、展開プロセスも同じくらい丁寧にやれる力があるはずだ。 ...

2026年4月15日、Microsoftはひっそりと、しかし確実に変化を起こした。これまでMicrosoft 365の商用プランユーザーであれば追加費用なしで使えていたWord・Excel・PowerPoint・OneNote内のCopilot Chat——その無料アクセスが終了した。 この変更は単なる機能制限ではない。多くの組織にとって「あって当然」になっていたAI体験が突然消えるという、ユーザー体験の断絶だ。IT部門が先手を打っていなければ、4月16日の朝から「あのAIボタンどこ行った？」という問い合わせが殺到していたはずだ。 何がどう変わったのか 変更はテナントの規模によって二段階に分かれている。 2,000ユーザー以上のテナント（MC1253858） Word・Excel・PowerPoint・OneNote内のCopilotペインが完全に非表示になる。ライセンスなしでは一切アクセス不可。 2,000ユーザー未満のテナント（MC1253863） 「スタンダードアクセス」という制限付き体験に移行。オフィスアプリ内のCopilotペインは消え、copilot.microsoft.com へのWebアクセスは残るが、ピーク時には応答品質が低下するスロットリングが入る。 影響を受けないのはTeams内のCopilot Chatと、当然ながらM365 Copilotライセンス保有者だ。 日本のIT現場への影響 日本企業で特に注意すべきは「気づかずに使っていたユーザー」の存在だ。Copilot ChatはMicrosoft 365の商用プランに自動で付いてきたため、IT部門が展開を許可した覚えがないままユーザーが活用しているケースが多い。文書の要約や下書きをCopilotに頼むワークフローが現場で静かに定着していた——そのワークフローが今日から機能しない。 ヘルプデスクへの備えとして今週中にやること： Message Centerで該当通知を確認する Microsoft 365管理センター → 正常性 → メッセージセンターで「MC1253858」または「MC1253863」を検索し、自テナントがどちらに該当するか把握する。 影響ユーザーの可視化 Copilotライセンスを持たないユーザーのリストを作成し、どの部署・どの業務で利用実態があるかを調査する。M365管理センターのUsage Reportが参考になる。 社内コミュニケーションを先に打つ 「機能が消える前に伝える」が鉄則。「Copilot Chatがアプリ内で使えなくなります。引き続き利用したい方はIT部門へご連絡を」という一文を事前にアナウンスするだけで、問い合わせ件数は大幅に減る。 ライセンス追加の可否を判断する M365 Copilotライセンスは現在1ユーザーあたり月額4,497円（2026年4月時点・税抜）。「全員分は難しいが、ヘビーユーザー上位20%には配る」という部分展開が現実的な選択肢になるケースが多い。 ライセンス戦略の見直しを この変更は、単なるコスト増ではなくライセンス体系の整理を求めるサインだと捉えた方がいい。これまで「タダで使えるから放置」していたCopilot利用実態が可視化され、「本当に価値を生んでいる機能は何か」を棚卸しする機会になる。 Teams内のCopilot Chat（議事録・要約）は引き続き利用可能なため、テレワーク中心の組織であれば影響が限定的なケースもある。オフィスアプリでの文書作成支援と、Teams上のコラボレーション支援——どちらが自社の業務にとって価値が高いかを再評価し、ライセンス配分を最適化したい。 筆者の見解 この変更に接して、まず思ったのは「もったいないな」だ。 Copilot ChatがM365に付属していたことで、AIアシスタントの存在をエンドユーザーが自然に体験し始めていた。ハードルの低さが普及の鍵だったはずで、そこに有料の壁を設けることで、せっかく芽生えかけていたAIリテラシーが刈り込まれる可能性がある。 一方で、ビジネスとしての判断は理解できる。「タダでいい体験を提供し続ける」モデルには限界があり、収益化は避けられない。問題は、そのタイミングと見せ方だ。変更の告知が十分でなかった組織も多く、現場の混乱を招いた点は正直に言えば残念だった。 MicrosoftにはAIアシスタントを本当の意味で業務に定着させる技術力とプラットフォーム基盤がある。Copilot自体の機能進化は続いており、それは評価したい。だからこそ「使い始めてくれたユーザーに水を差す」施策ではなく、「使ってよかった、もっと使いたい」と自然に思わせる価値提供の道を歩んでほしい。 IT管理者として今できることは、この変化をネガティブなイベントではなく「AIリテラシーとライセンス戦略を組織的に整備するきっかけ」と捉えることだ。場当たり的な対応より、腰を据えた全社的なAI活用設計——それが今回の変更が本当に促しているものだと思う。 出典: この記事は Microsoft Removing Copilot Chat from Word, Excel, PowerPoint for Unlicensed Users (April 15, 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teams を音声通信インフラとして本格導入している組織にとって、見過ごせないアップデートが届いた。Microsoft Purview のデータライフサイクル管理（DLM）が、Teams の通話ログ（Call Detail Record：CDR）に対する保持・削除ポリシーの適用に対応する。ロールアウトは2026年4月末から開始予定だ。 これまでの「無期限保存」という盲点 Microsoft Teams は通話のたびに CDR ログを生成し、Exchange Online のメールボックス内に保存してきた。問題は、このデータがこれまでデフォルトで無期限に保存されていた点にある。 多くの組織はこの事実をあまり意識してこなかったかもしれないが、法規制の観点では深刻な問題になりえる。日本国内でも個人情報保護法や電気通信事業法の解釈によっては、通話関連ログの保存期間を明示的に定め、一定期間経過後に削除することが求められるケースがある。EU の GDPR や、金融・医療分野の業界規制はさらに厳格だ。「取っているだけ」「消し方がわからない」という状態は、コンプライアンス上のリスクを静かに積み上げていた。 Purview DLM で何が変わるか 今回の対応により、コンプライアンス管理者は Purview の既存のリテンションポリシー機能を使って、Teams 通話ログの保持期間と削除タイミングを明示的に定義できるようになる。 主なポイントは以下のとおりだ。 既存の Purview ワークフローをそのまま活用：新しいツールや管理画面を覚える必要はない。すでに Exchange メールや SharePoint のデータに設定しているポリシーと同じ仕組みで管理できる ユーザーの通話体験には影響なし：バックエンドのデータライフサイクル制御であり、エンドユーザーが気づく変化はない デフォルトの無期限保存が終了：ポリシー未設定の場合の挙動が変わる可能性があるため、「何もしない」は選択肢にならない 実務への影響——IT管理者・コンプライアンス担当者がすべきこと ロールアウト前に最低限やっておきたい準備が3つある。 1. 自社の規制要件を棚卸しする どの規制が自社に適用されるかを確認し、通話ログの保存期間について法務・コンプライアンス部門と合意を形成しておく。業種によっては「3年保存」「5年保存」のルールが存在するため、安易に削除ポリシーを設定しないよう注意。 2. Purview のリテンションポリシーを作成または更新する 機能がロールアウトされたら、Teams 通話ログを対象スコープに含んだポリシーを作成する。すでに Teams チャットや会議ログ向けのポリシーを持つ組織は、それを拡張する形で対応できる。 3. 内部ドキュメントを更新する コンプライアンス担当者や法務チームへの周知が不可欠だ。「Teams の通話ログはいつまで残るか」という問いへの答えが変わるため、ガイドラインや BCP 文書への反映も検討したい。 日本企業への具体的な示唆 国内の大手エンタープライズ企業では、PBX から Teams Phone への移行が進みつつある。その過程で「通話録音は管理しているが CDR ログは把握していない」というケースが意外と多い。CDR ログには発信先番号・通話時間・参加者情報などが含まれており、個人データとして扱うべき情報が混入している可能性がある。 Purview DLM の対応は、こうした「管理の空白地帯」を埋めるうえで素直に歓迎できる進化だ。Purview を既に使っている組織なら、追加コストなしにガバナンスの網を広げられる。 筆者の見解 Purview がカバーする範囲が着実に広がっていることは評価したい。Teams の通話ログは「存在は知っているが誰も管理していない」データの典型例であり、今回の対応でコンプライアンスの穴がひとつ塞がれる。 ...

「保存してから守る」時代が終わる Microsoft PurviewのEndpoint DLP（データ損失防止）に、2026年4月から重要なアップデートが加わった。これまでEndpoint DLPが保護できるのは「ディスクに保存済みのファイル」に限られていたが、新機能によりまだ保存されていない状態のファイルに対しても、印刷・外部転送などのエグレス（流出）アクティビティを検知・ブロックできるようになった。 これは地味に見えて、実は相当大きな変化だ。 何が変わるのか 従来の限界 これまでのEndpoint DLPは「ファイルが保存されたタイミング」からしか保護を開始できなかった。つまり、ユーザーがWordやメモ帳で機密情報を入力し、保存する前にスクリーンショット印刷やクラウドストレージへドラッグした場合、DLPポリシーが発動しないという抜け穴が存在していた。 新機能の仕組み 新しい「未保存ファイルへのDLP保護」が有効になると、ポリシーの評価がファイル書き込みより前の段階から始まる。具体的には以下の2つの制御が可能になる： 監査モード: 未保存ファイルの印刷・転送アクティビティをログに記録する ブロックモード: 未保存ファイルの印刷・転送アクティビティを実際に遮断する 有効化の条件 この機能はデフォルトでは無効であり、管理者が明示的に設定する必要がある。また、対象デバイスが以下の要件を満たしていることが前提となる： マルウェア対策クライアント バージョン 4.18.26020 以降が稼働していること Microsoft PurviewのコンプライアンスポータルからEndpoint DLPが構成済みであること 既存のDLPポリシーは変更なくそのまま動作する。新設定を追加した場合のみ挙動が変わる。 実務への影響——IT管理者が今すぐやること 1. デバイスのクライアントバージョン確認 まず社内エンドポイントのマルウェア対策クライアントが 4.18.26020以降であることを確認しよう。Microsoft Defender for Endpointの管理コンソール、またはIntune経由でデバイスコンプライアンス状況を一括確認できる。古いバージョンのデバイスは今回の機能が適用されないため、展開ロードマップに組み込む必要がある。 2. 既存ポリシーの見直し 既存のEndpoint DLPポリシーが「どのシナリオをカバーしていたか」を棚卸しし、今回の「未保存ファイル制御」を有効化すべきユースケースを洗い出す。特に、以下の業務シーンは優先的に検討を推奨する： 個人情報・機密情報を扱うアプリケーション（医療・金融・人事系） 外部転送リスクが高い部門（営業・経営企画等） BYODや共用PCが混在する環境 3. まずは監査モードで運用開始 いきなりブロックモードを有効化すると業務影響が出る可能性がある。最初は監査モードで運用し、ログを分析してから徐々にブロックモードへ移行するフェーズドアプローチが無難だ。 4. ヘルプデスク・社内周知 ブロックモードを有効化した場合、ユーザーが「ファイルを保存もしていないのに印刷できない」という体験をすることになる。混乱を防ぐため、事前に社内アナウンスと問い合わせ窓口の準備が必要だ。 筆者の見解 「保存前のファイル」に対してDLPを効かせるというのは、セキュリティの時間軸を根本から変える取り組みだ。従来型のDLPは「データが定着してから守る」という発想だったが、今回の機能は「データが生まれた瞬間から守る」という方向に踏み込んでいる。これはゼロトラストの思想——「アクセスを許可したあとも継続的に評価する」——のエンドポイント版とも言える。 個人的に注目しているのは、この機能がNHI（Non-Human Identity）や自動化フローとの相互作用だ。RPA・マクロ・スクリプト類が「未保存の一時ファイル」を経由してデータを移送するパターンは珍しくない。今回の機能がそういった自動化プロセスをどう扱うか、ポリシー設計次第では意図せず業務自動化を止めてしまうリスクもある。展開前にテスト環境での検証を強く勧めたい。 Microsoft Purviewはここ数年でコンプライアンス基盤としての完成度を着実に高めている。今回のアップデートもその延長線上にあり、正しく設計・運用すれば実際の情報漏洩リスクを大きく下げられる。デフォルトがオフになっていることから、運用インパクトへの配慮も感じられる。あとは管理者側がこの機能をどれだけ迅速に実戦投入できるか——機能があっても使われなければ意味がない。ぜひ積極的に活用してほしい。 出典: この記事は Microsoft Purview compliance portal: Enforce DLP protection on new content before it’s saved - M365 Admin の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotの宣言型エージェント（Declarative Agents）に、まとめて3つの大きなアップデートが降ってきた。なかでも注目すべきはMCP Appsのサポートだ。2026年4月7日に正式アナウンスされたこの機能は、Copilotチャットの性格を根本から変える可能性を持っている。 何が変わったのか——3つの制約が同時に崩れた これまでの宣言型エージェントには、開発者なら誰でも痛感してきた3つの壁があった。 テキスト応答しかできない 知識ソースがSharePoint・OneDrive・一部URLなどに限定されている 開発ループがポータルとJSONとエディタをまたぐ煩雑なもの 今回のアップデートはこの3つを一気に崩した。MCP Appsが「壁その1」を、埋め込み知識（Embedded Knowledge）が「壁その2」を、Microsoft 365 Agents Toolkitの新プラグインが「壁その3」をそれぞれ解決する構成だ。 MCP Appsとは何か——チャットの中に「生きたUI」を置く Model Context Protocol（MCP）は、もともとAIクライアントとサーバー間でデータをやり取りするための仕様として広まった。その拡張として最近追加されたのが、データだけでなくフルUIもクライアント側に返せる仕組みだ。 Copilotではこれに対応した形式が2種類サポートされている。 MCP Apps：MCPの仕様を拡張したもの OpenAI Apps SDK：OpenAIが同時期にリリースした同様の仕組み 実際にどう見えるかというと、チャット内に「経費承認フォーム」「プロジェクトステータスダッシュボード」「並列ドキュメント比較ビュー」といったインタラクティブなUIが出現する。リンクではない。カードでもない。ユーザーが操作できるライブな作業面がそのままチャットの中に埋め込まれる。 表示モードは2種類ある。 モード 特徴 用途例 インライン（Inline） モデルの応答より前に表示される軽量ウィジェット 承認フロー、クイック確認、プルリクレビュー サイドバイサイド（Side-by-side） メインエリアを占有する没入型ワークスペース 複数ステップの編集作業、レイアウト確認、比較作業 インラインモードはチャットの流れを邪魔しない軽い操作に向いており、サイドバイサイドはCopilotチャットを横に追いやって「本格的な作業台」として使う構成だ。 開発者にとって重要な設計上のポイント この機能設計で評価したいのは後方互換性だ。UIコンポーネントはMCPレスポンスのmetaプロパティに乗せる形で追加され、既存のMCPサーバー実装を壊さない。認証・インテグレーション・既存ロジックはそのままに、UI層だけを後乗せできる。 過去のMicrosoftが得意としてきた「壊さずに積む」設計の良い例だ。既にエージェントを本番運用している開発者にとっては、リアーキテクチャなしで対応できる点がありがたい。 ローンチパートナーにはAdobe Express・Coursera・Figma・monday.comといった名前が並び、Outlookの作成・スケジュール機能も対象に含まれる。4月中旬からMicrosoft 365 Agent Storeに順次登場する予定だ。 実務への影響——IT管理者・エンジニアが押さえるべきこと エージェント開発者向け 既存のMCPサーバーがある場合、metaプロパティにUI定義を追加するだけで対応可能。フルリライトは不要 インラインとサイドバイサイドの使い分けを先に設計してから実装に入ると無駄が少ない 承認フロー系の業務（稟議・経費・購買）は即座にユースケースの候補になる IT管理者向け Copilotチャット内で「アプリが動く」体験が始まることで、ユーザーのCopilot利用時間が増加する可能性がある。ガバナンスポリシーの見直しが必要になるかもしれない Agent Storeからインストールされるサードパーティエージェントの管理方針を今から整備しておくと後が楽になる Adobe Express・Figmaといったクリエイティブ系ツールとのCopilot統合が進むことで、M365の外にあったワークフローが内側に取り込まれる流れが加速しそうだ 筆者の見解 Copilotがテキスト応答の外に出始めたこと自体は、正直なところ歓迎したい変化だ。チャットで返ってくるのが文字だけというのはいつまでも「頭のいい検索」の域を出られず、業務ツールとして本当の意味で使いものになるには、これくらいのUIリッチ化は必要だった。 ただ、率直に言えば「遅い」という感想も拭えない。チャット内に作業UIを持ち込むというコンセプト自体は技術的に新しいわけではなく、それが2026年春にようやく宣言型エージェントで使えるようになったというのは、Microsoftが持っているブランドと開発者コミュニティの規模を考えると、もったいないスピード感だ。 とはいえ、ここで重要なのは「後方互換を保って積み上げた」という実装の筋の良さだ。この設計判断は正しい。Microsoftが本気でエコシステムを育てようとするなら、既存投資を無駄にさせないアーキテクチャが不可欠で、その点は今回しっかりやりきっている。 MCPという業界共通の仕様をベースに据えたことも長期的には有利に働くはずだ。独自規格に閉じず、OpenAI Apps SDKも並列サポートする姿勢は、エコシステムの裾野を広げる上で現実的な判断だと思う。 日本のM365環境でCopilotを展開している企業には、まずはAdobe ExpressやFigmaといった既導入ツールとのインテグレーションを試しにいくのが最初の一手として手堅い。承認フロー系の業務をインライン対応させるだけでも、「Copilotを開かない理由」が一つ減る。それが積み重なると、利用定着率の数字は変わってくる。 Copilotが実力を発揮できる土台が少しずつ整ってきたのは確かだ。この方向性でのアップデートが続くことを期待したい。 出典: この記事は M365 Copilot Declarative Agents: What’s New April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントが業務システムに組み込まれつつある今、「エージェントそのものをどう守るか」という問いが現実的な課題として浮上している。Microsoftはこの問いに対し、既存のセキュリティ製品群——Entra、Purview、Defender——を組み合わせた4層の統合アーキテクチャで答えようとしている。日本語メディアでほとんど取り上げられていない技術詳細を、今回は実務の文脈で読み解く。 AIエージェントは「新しいID」を持つ存在である まず押さえておきたいのは、AIエージェントはユーザーでも従来のサービスアカウントでもない、第三のID種別だという点だ。Microsoftはこれを「Workload Identity（ワークロードID）」としてMicrosoft Entra上で管理する設計を取っている。 具体的には以下のメカニズムが働く： マネージドID / サービスプリンシパルによるエージェントのID発行 条件付きアクセス（Conditional Access）でエージェントのアクセス元・スコープを制限 Just-In-Time（JIT）アクセスにより、必要なときだけ必要な権限を付与 特にJITは重要だ。「常時アクセス権の付与は特権アカウント管理における最大のリスク」——これはAIエージェントにもそのまま当てはまる。エージェントに広い権限を常時持たせる設計は、侵害時の爆発半径（blast radius）を最大化する最悪のパターンだ。 データ保護層：PurviewがエージェントのI/Oを監視する エージェントが触れる情報の機密性を制御するのがMicrosoft Purviewの役割だ。 情報保護ラベル（Sensitivity Labels）がエージェントの入出力にも適用される エージェントが「機密」ラベルの付いたデータにアクセスしようとした場合、ポリシーに基づいてブロックまたは監査 データ損失防止（DLP）ポリシーはエージェントの応答にも適用可能 ここで注目すべきは、Purviewがエージェントの「振る舞い」をログとして残す点だ。「何を入力し、何を出力したか」の監査証跡は、インシデント発生時の調査はもちろん、コンプライアンス対応においても不可欠になる。 脅威検出層：Defenderがプロンプトインジェクションを検知 Microsoft DefenderはAIエージェント特有の脅威に対応するための拡張が進んでいる。注目すべきはプロンプトインジェクション攻撃への対応だ。 悪意ある外部コンテンツ（メール本文、Webページ等）にエージェントを操作する命令を埋め込む攻撃は、従来のマルウェアとは異なるベクトルであり、既存のエンドポイント保護では検知できない。Defenderはこのような間接プロンプトインジェクションを検知するシグネチャを持ち始めている。 さらに： エージェントの異常な動作パターン（通常より大量のデータアクセス等）をアラート Microsoft Sentinel連携によるSIEM/SOARへの統合 コンプライアンス層：エージェントの「行動記録」を残す 4層目はコンプライアンスだ。規制対応の観点から、エージェントの判断根拠と実行ログをどこまで記録・保全できるかが問われる。Purviewの監査ログとDefenderのインシデントログを組み合わせることで、エージェントの行動を事後検証できる体制を構築できる。 実務への影響——日本のIT管理者が今すぐ動くべきこと このアーキテクチャを踏まえ、実務で取るべき行動を整理する。 1. AIエージェントを「人間のアカウント」で動かすのを今すぐやめる Copilot StudioやAzure AI Foundryで作成したエージェントに、個人アカウントや共有サービスアカウントを使い回している構成は即刻見直しだ。マネージドIDを使ったEntra統合が正解。 2. 最小権限の原則を徹底する エージェントに付与する権限は「実際に必要な最小限」に絞る。SharePoint全サイトの読み取り権限を付与したエージェントが侵害されたときのリスクを想像してほしい。 3. Purviewの情報保護ラベルをAIワークロードにも適用する ラベルが整備されていないと、Purviewによるエージェント制御は機能しない。ラベル整備が先決。 4. プロンプトインジェクションを「新しい攻撃ベクトル」として認識する セキュリティ研修やインシデント対応プレイブックに、AIエージェント固有の攻撃シナリオを追加する時期に来ている。 筆者の見解 MicrosoftがAIエージェントセキュリティに対してEntra・Purview・Defenderの既存資産を統合して使う設計を選んだことは、技術的に理にかなっていると思う。ゼロから作るのではなく、実績のある製品群を組み合わせて対応する——これはMicrosoftらしい、そして正しいアプローチだ。 とりわけNon-Human Identity（NHI）の管理をEntraの枠組みで統一しようとしている点は評価したい。AIエージェントの普及で、NHIの数は今後人間のIDを大幅に上回るようになる。NHI管理の基盤ができていない組織は、自動化を進めようとするたびにボトルネックに直面することになる。 一方で、率直に言えば、これらの機能が「使える状態」になるまでの道のりはまだ長い。条件付きアクセスのエージェント対応、Defenderのプロンプトインジェクション検知精度、Purviewのエージェントログ保全——どれも完成形には程遠く、プレビュー段階の機能が多い。 それでも、統合プラットフォームとして全体最適を目指す方向性は変わっていない。M365・Azure・Defenderのエコシステム内でこれらが統合されれば、バラバラのポイントソリューションを寄せ集めるよりも確実に運用しやすくなる。これがMicrosoftの強みであり、AI時代においてもその強みは有効だ。 日本企業の多くはまだAIエージェントのセキュリティを「先の話」と捉えているかもしれない。だが、Copilot Studioで作ったエージェントが社内SharePointに接続された瞬間から、この話は「今の話」になる。アーキテクチャの理解は、導入の前に必要だ。 出典: この記事は How Microsoft Is Securing AI Agents Across Identity, Data, Threats, and Compliance の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 E5ライセンスを持つ組織にとって、見逃せないアナウンスが届いた。Security Copilotのエージェント機能が2026年4月20日から6月30日にかけて段階的にロールアウトされ、追加費用なしで利用できるようになる。セキュリティ運用の自動化に一歩踏み込む機会として、IT管理者はこのタイミングをきちんと把握しておきたい。 Security Copilotとは何か Microsoft Security Copilotは、セキュリティ運用・IT運用の日常業務を支援する生成AI＆エージェント型AIアシスタントだ。脅威インテリジェンス、業界ベストプラクティス、組織固有のデータを統合し、インシデント対応の高速化や見落とし防止を支援する。単なる検索・回答型AIではなく、自律的に判断して行動するエージェントとして動作する点が特徴だ。 処理量は「SCU（Security Compute Units）」という単位で管理される。今回のE5向け特典では、1000ユーザーライセンスあたり月400 SCU（上限1万SCU/月）が無償で付与される。 具体例で確認しよう： 400席の組織 → 月160 SCU 4,000席の組織 → 月1,600 SCU 4つのコアエージェント 今回含まれるエージェントは、日常的なセキュリティ運用の「重労働」を引き受けてくれる構成になっている。 Phishing Triage Agent（Microsoft Defender） ユーザーから報告されたフィッシングアラートを分析し、自然言語で「これは本物か、無害か」を判定する。SOCアナリストが1件ずつ目視確認していた作業を、エージェントが優先度付きで整理してくれる。 Conditional Access Optimization Agent（Microsoft Entra） 条件付きアクセス（CA）ポリシーのギャップを検出し、最適化の提案を行う。CAポリシーは組織の規模が大きくなるほど複雑化しやすく、「気づいたら穴が開いていた」という状況になりがちだ。このエージェントが定期的にチェックする仕組みを持てるのは心強い。 Threat Intelligence Briefing Agent（Microsoft Defender） 組織の環境に合わせた脅威インテリジェンスのブリーフィングレポートを自動生成する。「最新の脅威を把握したいが、レポート作成に時間がかかる」という課題をAIが肩代わりしてくれる。 Data Security Triage Agent（Microsoft Purview） DLP（データ損失防止）やインサイダーリスクのアラートを優先度付きで整理する。Purviewのアラートは膨大になりがちで、真に対処すべき案件が埋もれてしまう問題がある。このエージェントが「本当に見るべきもの」を浮かび上がらせてくれる。 実務への影響 すでにM365 E5を持っている組織は、4月20日以降に有効化通知が届き次第、即座に試せる状態になる（2025年11月18日以前からSecurity Copilotを利用中の組織はすでに適用済み）。 IT管理者として押さえておくべきポイントを整理する。 SCU消費量を把握する: 無償枠は「典型的な利用シナリオ」をカバーする設計とされているが、組織の規模や利用頻度によっては上限に達する可能性がある。初期はエージェントの稼働状況と消費量をモニタリングしながら使うのが賢明だ。 CAポリシーの棚卸しに活用する: Conditional Access Optimization Agentは、長年放置されてきたCAポリシーの見直しに絶好のきっかけになる。ゼロトラスト推進の文脈でも、「今のポリシーが本当に意図通りか」を定期的に検証する仕組みを持つことは重要だ。 SOC担当者の負荷軽減に焦点を当てる: フィッシングトリアージやデータセキュリティトリアージは、人が時間をかけていた定型的な判断業務をAIに任せることを意味する。担当者が本当に判断すべき案件に集中できる体制を作る一歩として位置付けよう。 Entra・Intune・Purview・Defenderの連携を前提に考える: これら4製品を連携して使っている組織でこそ、エージェントが真価を発揮する。バラバラに導入している場合は、統合活用の見直し時期かもしれない。 筆者の見解 セキュリティ運用における「人間のボトルネック」は深刻だ。アラートは溢れ、対応できる人材は限られ、見逃しが重大インシデントに繋がる——この構図はどの組織でも変わらない。Security CopilotのエージェントがEntraやDefender、Purviewに直接組み込まれ、日常業務のなかで自律的に動く設計は、この問題への現実的なアプローチとして評価できる。 M365 E5ライセンスの利用者にとって、この無償提供は使わない理由がない。ただし、「入れたら終わり」ではなく、エージェントが何をどう判断しているかを継続的に確認し、組織の運用フローに組み込んでいくことが大切だ。AIエージェントは自動化の入り口であり、人間の判断を完全に置き換えるものではない——少なくとも現時点では。 Copilot全体への評価はさておき、このSecurity Copilotエージェントのアプローチは方向性として正しいと思っている。セキュリティという領域は「速さ」と「網羅性」の両立が求められる。人間だけでは絶対に追いつけない規模・速度の脅威環境において、AIエージェントが最前線で動く仕組みを育てていく——MicrosoftがE5という上位ライセンスでこのアプローチに本気で取り組んでいること自体は、素直に歓迎したい。 ...

AIエージェントが社内データに触れ、ユーザーに代わって処理を自動実行するようになった今、「誰が・何に・いつアクセスしたか」を把握できない組織はガバナンスの死角を抱えることになる。Microsoft Purviewがそこに本格的に踏み込んだ。DSPM（データセキュリティポスチャー管理）のAI ObservabilityとInsider Risk Management for agentsが、2026年5月末にGenerally Available（GA）となる。 何が変わるのか 今回GAとなるのは、Roadmap ID 516032 として登録されていた機能群だ。パブリックプレビュー自体は2025年12月から始まっており、早期採用組はすでに評価段階にある。GA展開は2026年5月初旬に開始、5月末までに完了予定。 主な機能は大きく2つに整理できる。 DSPM – AI Observability AIエージェントがエンタープライズ環境内でどのような活動をしているかをリアルタイムに近い形で可視化する機能だ。具体的には以下が可能になる。 エージェントの行動ログの収集・分析 コンプライアンス違反の疑いがある行動の特定 組織ポリシーに沿ったガバナンスポリシーの適用 Insider Risk Management for agents こちらは従来人間向けに存在したInsider Risk Managementのエージェント版だ。知的財産の窃取・データ漏洩・セキュリティ違反といったリスクシグナルを複数のソースから相関分析し、ポリシーベースで検知・対応できる。プライバシー設計として、ユーザーはデフォルトで仮名化（pseudonymize）され、RBAC（ロールベースアクセス制御）と監査ログによってユーザーレベルのプライバシーが保護される点は評価できる。 ライセンスの壁——M365 E7またはAgent 365が必須 見落とせないのがライセンス要件だ。これらの機能はMicrosoft 365 E7またはAgent 365サブスクリプションがなければ使えない。現在のM365 E3やE5ライセンスでは対象外となる。 日本企業でE7を契約しているケースはまだ少ない。Agent 365は比較的新しいSKUであり、AIエージェントの本格活用に踏み切った組織向けの位置づけだ。「うちにはまだ関係ない」と思いがちだが、Copilot Studio・Azure AI Foundry・Microsoft 365 Copilotのいずれかを使ってエージェントを動かしているなら、今すぐ準備の検討を始めるべきフェーズに入っている。 日本のIT現場にとっての意味 日本のエンタープライズでは、AIエージェントの導入がやや遅れ気味だったが、2026年に入って急速に実案件が増えている。問題は、エージェントをとりあえず動かしているものの、「それが社内でどう動いているか」を把握している管理者が少ないことだ。 AIエージェントは本質的にNon-Human Identity（NHI）——人間ではないがシステムに代わってアクセスと処理を行う主体だ。人間の社員に適用していた内部リスク管理の考え方を、AIエージェントにも同等に適用する必要がある。Microsoft Purviewが今回この領域に手を伸ばしたのは、その認識に基づいた自然な流れと言える。 実務での活用ポイント 今すぐできる準備 エージェントの棚卸しから始める: 自組織のどのエージェントが企業データにアクセスしているかをリスト化する。Copilot Studio・Azure AI Foundryで作ったカスタムエージェントも含めて把握すること ライセンス計画を見直す: E7・Agent 365へのアップグレードが必要かどうか、コストと対応の必要性を天秤にかける。「エージェントを使っていないから不要」ではなく、「近い将来使うかどうか」で判断する ガバナンスポリシーを先に整備する: 機能がGAになってからポリシーを考えるのでは遅い。今のうちにセキュリティ・コンプライアンス担当と連携して、エージェントに適用すべき行動規範を文書化しておく DSPM有効化手順を確認する: 公式Learnページ（Microsoft Agent 365 Overview）にActivationの手順が記載されている。GA後に慌てないよう、プレビュー段階から読み込んでおくことを勧める 筆者の見解 AIエージェントのガバナンスは、今後のエンタープライズIT管理における最重要テーマの一つになる。その理由はシンプルで、ボトルネックは常に人間にあるからだ。業務効率を本当に上げようとするなら、AIエージェント＝Non-Human Identityが安全に・自律的に動ける仕組みが不可欠であり、そのためにはNHIの活動を可視化・管理する仕組みが土台として必要になる。 ...

Microsoftが新たなエンタープライズ向けSKU「Microsoft 365 E7」を発表した。既存のM365 E5とMicrosoft 365 Copilot、そして新たに登場する「Agent 365」を一つのライセンス体系に統合するという、かなり大胆な動きだ。AIをどう組織に根付かせるかという問いへの、Microsoftなりの現時点での回答といえる。 Agent 365とは何か Agent 365は、Microsoft 365エコシステム上で動作するAIエージェントの「コントロールプレーン」として位置づけられる新製品だ。単なるCopilotの延長線上ではなく、複数のAIエージェントをオーケストレーションし、業務プロセスへの組み込みをガバナンスと一体で管理するための基盤という理解が正確だろう。 具体的には以下の要素が含まれる。 AIエージェントのライフサイクル管理 — デプロイ・監視・廃止をIT管理者が一元管理できる Work IQ（ワーク・インテリジェンス） — 組織内の業務パターンや生産性をAIが分析・可視化する機能。Viva Insightsを発展させたイメージ セキュリティスタックとの統合 — Purview・Defender・Entraと連携し、エージェントの行動をゼロトラスト原則のもとで制御する これらをM365 E5の既存セキュリティ・コンプライアンス機能と組み合わせてパッケージ化したのが、E7というわけだ。 E5→E7という価格体系の意味 現在M365 E5を契約している企業にとって、E7はアップグレードの選択肢になる。M365 Copilotのライセンスを別途購入している場合は、E7に統合することでコスト最適化を図れる可能性がある。 ただし、ここは慎重に読む必要がある。「統合してお得」という構造は、実際には利用状況に依存する。Copilotを全社展開している大企業にとっては合理的な選択だが、一部部門だけに展開している企業では、逆にコストが増える可能性もある。ライセンスの棚卸しと利用実態の把握が、判断の前提として必要になる。 実務への影響——日本のIT管理者が押さえるべきポイント 短期的に動くべきこと 現行ライセンス構成の把握 — E5 + Copilotを別々に持っているなら、E7への移行コスト試算を今から始める。特に大手SIer経由で契約している場合は、見積もりのタイムラグがあるため早めに動くこと。 AIエージェント利用計画の棚卸し — Copilot Studioで作成したカスタムエージェント、あるいは今後作る予定のエージェントがあれば、Agent 365の管理フレームワークの対象になりうる。どのエージェントが何にアクセスしているかを整理しておく。 Work IQのプライバシーポリシー確認 — 業務インテリジェンス分析は、個人の行動データを扱う性質上、社内プライバシーポリシーや労使協定との整合確認が必須になる。技術評価と並行して法務・人事との連携を早めに始めること。 中長期の視点 Agent 365が「コントロールプレーン」として機能するなら、今後のMicrosoft 365上のAI活用は「個別ツールの導入」から「エージェントのポートフォリオ管理」へとパラダイムシフトする。IT部門の役割が「インフラ管理」から「エージェント・ガバナンス」へと変化していく流れは、すでに始まりつつある。 筆者の見解 この発表を見て、率直に「方向性は正しい」と思った。Microsoftのこういう動きは、実際に評価したい。 AIエージェントが増殖するにつれて、「誰が何にアクセスできるのか」「どのエージェントが今何をしているのか」が見えなくなるという問題は、現場でも実感としてある。Agent 365がそのコントロールプレーンとして機能するなら、ゼロトラストの観点からも意義は大きい。Non-Human Identities（NHI）の管理問題——つまりエージェントやサービスアカウントのアイデンティティ統制——は業務自動化の最大のボトルネックの一つだ。そこにMicrosoftがプラットフォームレベルで応答しようとしているのは、歓迎すべき動きだと思っている。 Work IQについても、「業務の可視化」という切り口は組織改革の文脈で使い道がある。ただ、日本企業においては「社員を監視されているように感じる」という心理的ハードルが高い傾向があるため、導入時のコミュニケーション設計が成否を分けるだろう。 一方で、気になるのはE7という統合パッケージ戦略の現実的な定着速度だ。日本の大企業では、M365のライセンス体系変更が実際の現場に浸透するまでに相当な時間を要することが多い。「発表された」と「使われている」の間にある距離を、Microsoftはもう少し丁寧に埋めるための支援策——ドキュメント・パートナー教育・パイロット支援——に力を入れてほしい。これだけの構想力がある会社なのだから、展開力でも同等の本気度を見せてほしい、というのが正直なところだ。 Microsoft 365というプラットフォームは、統合して使うことで初めて価値が最大化される。E7の構想はその方向性に沿っている。あとは、実装と展開のクオリティがこの構想に追いつくかどうか。それを見届けたい。 出典: この記事は Microsoft to introduce Agent 365 as M365 E7 unified suite の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2022年以来最大規模の価格改定が始まる Microsoftは2026年7月1日より、法人向けMicrosoft 365（M365）の主要SKUの価格を一斉に引き上げる。2022年の価格改定以来、最大規模となる今回の変更は、エンタープライズ・ビジネス・フロントラインの全カテゴリが対象で、値上げ幅は5〜43%と幅広い。既存顧客は更新タイミングまで旧価格が維持されるが、2026年7月以降の更新には新価格が適用される。 SKU別の主な価格変更（USD） エンタープライズスイート（Teams込み） SKU 旧価格 新価格 変化率 Microsoft 365 E3 $36.00 $39.00 +8% Microsoft 365 E5 $57.00 $60.00 +5% Office 365 E3 $23.00 $26.00 +13% Office 365 E5 $38.00 $41.00 +8% ビジネススイート（Teams込み） SKU 旧価格 新価格 変化率 Business Basic $6.00 $7.00 +16% Business Standard $12.50 $14.00 +12% フロントラインスイート（最大の値上げ幅） SKU 旧価格 新価格 変化率 M365 F1 $2.25 $3.00 +33% M365 F3 $8.00 $10.00 +25% スタンドアロンコンポーネントも軒並み値上がりしており、Entra Plan 1は+16%（$6→$7）、EMS E3は+13%（$10.60→$12.00）、Microsoft 365 Appsは+17%（$12→$14）となる。 価格転嫁の名目——何が追加されるのか Microsoftは今回の価格改定と合わせ、2026年夏から以下の機能をパッケージに追加すると発表している。 ...

会議室に「見えない参加者」が紛れ込んでいる——そんな状況に終止符を打つ機能が、Microsoft Teamsに追加される。2026年5月中旬から順次展開が始まる「外部ボットのロビーでのラベル表示」機能は、録音・文字起こしツールなどの自動化ボットが人間の参加者に混じって承認されてしまうリスクを根本から解消する、地味ながら実務への影響が大きいアップデートだ。 何が変わるのか 従来のTeams会議では、外部から参加しようとするボットが、見た目上は一般の参加者と区別がつかない状態でロビーに並んでいた。主催者がロビーを一括承認する際に、意図せずボットを入室させてしまうケースが実際に発生していた。 今回の変更では、外部の第三者製ボット（3P Bot）がロビーに来た際、明確なラベルが付与されて表示される。さらに、ボットの入室承認は人間の参加者とは別操作で、明示的に行う必要がある。うっかり全員まとめて承認、という事故がシステム的に防止される設計だ。 対応プラットフォームはWindows・macOS・Android・iOSの全プラットフォーム。対象テナントはWorldwideの標準マルチテナントおよびGCC環境。 なぜこれが重要か この機能が登場した背景には、AIノートテイクツールの急速な普及がある。Otter.ai・Fireflies・Notionなど、会議の録音・文字起こし・要約を自動化するサービスは今や数え切れないほど存在し、ビジネス現場での利用も珍しくなくなった。 問題は、こうしたツールが会議内容をどこかのサーバーに送信していることだ。日本企業にとっては、個人情報保護法への適合、社内規程との整合性、機密情報の漏洩リスクが現実の懸念として浮上する。特に、医療・金融・法務・官公庁系の組織では、外部サービスへのデータ転送自体が許可されていないケースも多い。 さらにセキュリティ観点では、悪意ある攻撃者がボットを会議に紛れ込ませるシナリオも現実的だ。Teamsを悪用したソーシャルエンジニアリング攻撃はすでに観測されており（ランサムウェアグループによる事例も含む）、Microsoftは昨年末から段階的に詐欺対策機能を強化してきた。今回の機能はその流れに沿った追加策と位置づけられる。 実務での活用ポイント IT管理者・セキュリティ担当者向け まず確認すべきは、自組織のTeams利用ポリシーに「外部ボットの参加可否」が明記されているかどうかだ。この機能が展開されると、主催者個人の判断に委ねられる部分が増える。組織全体として「外部ボットは原則拒否」「事前申請したツールのみ許可」などの方針を定め、主催者に周知しておく必要がある。 Teams管理センターからボットの参加自体をポリシーで制御できるかも、この機能と合わせて確認しておきたい。 会議主催者・一般ユーザー向け ロビー画面に「Bot」とラベルされた参加者が表示されたら、それは自動化ツールだ。承認前に「誰がこのボットを招待したのか」「このツールの利用は自社ポリシーに適合しているか」を必ず確認する習慣をつけたい。参加者の誰かが便利ツールのつもりで招待していても、会議内容の録音・クラウド送信が発生することへの認識共有が不可欠だ。 ゼロトラスト設計との整合性 この機能は「デフォルト拒否、明示的許可」という原則に則っており、ゼロトラストセキュリティの考え方と自然に整合する。ネットワーク・認証・認可の各層で防御を重ねるアーキテクチャにおいて、会議参加者の可視化と明示的承認の義務付けは、アイデンティティ管理の観点でも正しいアプローチだ。 筆者の見解 この機能、率直に言って「やっと来たか」という感想だ。AIノートテイクツールが会議に参加することへの違和感は以前から指摘されていたが、Teamsがプラットフォームとして対応策を提供するまでに時間がかかりすぎた感はある。 とはいえ、方向性は間違いなく正しい。「禁止する」のではなく「可視化と明示的承認を義務付ける」というアプローチは、現場の実態に即している。録音・文字起こしツール自体には正当なユースケースが多い。全面禁止すれば現場は非公式なツールに流れるだけで、かえってガバナンスが崩れる。公式の仕組みで安全に使える環境を整える——この発想は評価したい。 Teamsは会議体験において確実に機能を積み上げてきている。詐欺通話の報告機能、外部ユーザーのブロック機能、そして今回のボット検出——セキュリティ文脈での機能拡充は地道だが着実だ。M365を統合プラットフォームとして活用している組織にとって、こうした基盤整備は長期的な資産になる。 5月の展開後は、管理者・ユーザー双方へのアナウンスをセットで行うことを強く勧める。機能があっても使い方を知らなければ意味がない。この変更を機に、自組織の「会議ポリシー」を見直す良い機会にしてほしい。 出典: この記事は Microsoft Teams will tag third-party bots in meeting lobbies の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft FoundryおよびMicrosoft 365 Copilotにおいて、AnthropicのClaudeモデルが利用可能になったと発表された。CopilotチャットでOpenAIモデルと並んでサードパーティ製AIを選択できるようになり、さらにExcelの「Agent Mode」でも外部AIを活用したスプレッドシート操作が可能となった。単なる「別のAIが使えます」という話ではなく、Microsoftエコシステムの枠組みの中でマルチAI戦略が現実的な選択肢として企業に開かれたという意味で、注目に値するアップデートだ。 Microsoft Foundryによる統合：調達コストの壁を崩す これまでエンタープライズ企業がMicrosoftエコシステムの外からAIサービスを調達しようとすると、別途ベンダー契約・請求系統・セキュリティ審査が必要となり、導入に数週間から数か月かかることも珍しくなかった。 Microsoft Foundryへの統合で変わるのは、まさにこの調達の壁だ。FoundryのAPIやワークフローを通じてモデルを利用でき、既存のAzure契約（MACC：Microsoft Azure Consumption Commitment）の消費枠で課金が完結する。Microsoft Entra認証との連携も確保されており、Python・TypeScript・C#の各SDKから利用できる。 別途PoC申請・契約交渉・コスト配分の説明資料を用意しなくても、Azureの延長線上でモデルの評価と本番適用ができる。これは現場のエンジニアや調達担当にとって、地味だが実質的に大きい変化だ。 M365 Copilot側の変化：Researcherと「デュアルモデル方式」 Copilot側の変化も見ておきたい。M365 CopilotのResearcher機能では、複数のAIモデルを役割分担させる構成が採用されている。具体的には、一方のモデルが草稿を生成し、もう一方がその内容の精度検証を行うという二段構えの仕組みだ。 さらにExcelのAgent Modeでは、外部AIによるスプレッドシートの直接操作がプレビューとして提供開始された。数式の生成・データ分析・エラー検出・反復改善をAIに任せられる機能で、業務効率化の観点から注目に値する。 実務への影響：IT管理者・エンジニアが押さえるべきこと Azure利用企業のエンジニアへ Microsoft Foundryカタログからモデルをデプロイできる。既存のMACCに乗せられるか確認した上で、まずスモールスタートで評価を進めることをお勧めする サーバーレスデプロイのため、インフラ管理不要で即スタートできる点は評価できる モデルごとの特性（速度重視 / 高精度重視）を用途別に使い分けることが、コスト最適化につながる M365管理者・IT部門へ CopilotのResearcher機能はすでに業務利用されている組織もあるはず。その処理フローが今後マルチモデル構成に変化する点を把握しておくこと ExcelのAgent Modeはプレビュー段階。業務利用の前にデータガバナンスポリシーとの整合を確認しておくことが必要 Copilot Studio経由のカスタムエージェントにFoundryモデルを組み込む構成も可能になっており、エージェント開発の選択肢が広がった 筆者の見解 ここ数年、「M365のAI活用はCopilotだけで考える」という前提でIT戦略を立ててきた企業は少なくない。しかし現場の実感として、Copilotが全業務に対してベストな選択肢であるとは言いきれない局面も出てきている。 その意味で、今回の発表が意味しているのは「Copilot一択からの解放」だ。Teamsの議事録やOutlookの定型業務はCopilotに任せ、より高度な分析・推論・創造的なタスクには用途に応じた別のモデルを使う——こうした使い分けが、Microsoftの正規の枠組みの中で行えるようになった。 MicrosoftがAzureを通じてサードパーティAIをファーストクラスで扱う姿勢を示したことは、プラットフォームとしての「懐の深さ」を示すものだ。これはMicrosoftの強みである統合プラットフォームとしての価値を高める方向性であり、素直に評価したい動きである。 Copilotそのものがこの先どこまで進化するかは引き続き注目しているが、エコシステムとして多様な選択肢を束ねていく方向性は、これまでMicrosoftが得意としてきたことだ。このアーキテクチャの方向性が、AI時代においても真価を発揮することを期待したい。 「とりあえずCopilotを入れたが活用が進んでいない」という状況に直面している企業にとって、今こそFoundryを起点にしたマルチAI戦略を再設計するタイミングかもしれない。 出典: この記事は Claude now available in Microsoft Foundry and Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Microsoft Entra ID に待望のバックアップ・リカバリ機能を追加した。Entra 管理センター上でパブリックプレビューとして公開されたこの機能は、ディレクトリオブジェクトの自動バックアップと復元を標準で提供するものだ。「いつか必要になる」と分かっていながら、これまでサードパーティ製品や自前スクリプトで賄ってきた組織には、シンプルに朗報である。 何ができるようになったのか Microsoft Entra Backup and Recovery は、サポート対象のディレクトリオブジェクトを 1日1回自動的にバックアップし、最大5日分のスナップショットを保持する。管理者は Entra 管理センターから GUI 操作で過去のバックアップを参照し、誤って削除または変更されたオブジェクトを復元できる。 特に有効なシナリオとして想定されているのは以下の通りだ。 運用ミスによる誤削除: ユーザーアカウント・グループ・ロール割り当てなど、「消してから気づく」パターン セキュリティインシデント後の復旧: 攻撃者による不正変更や、条件付きアクセスポリシーの改ざん後の原状回復 構成変更の切り戻し: 設定変更が思わぬ副作用を生んだときのロールバック 現時点ではパブリックプレビューのため、対象オブジェクトの種類や復元の粒度に制限がある可能性がある。GA（一般提供）に向けてスコープが広がることが期待される。 なぜこれが重要か Entra ID（旧 Azure AD）は、Microsoft 365・Azure・Intune など多くのサービスの認証・認可の起点となるアイデンティティ基盤だ。ここに格納されるオブジェクトは「すべてのサービスへの鍵」に等しく、誤削除や不正変更のインパクトは計り知れない。 従来、Microsoft が提供する標準機能としては「ごみ箱（Recycle Bin）」があり、削除から30日以内であれば一部のオブジェクトは復元可能だった。しかし、削除以外の変更（たとえば条件付きアクセスポリシーの書き換えやグループメンバーシップの変更）には対応しておらず、タイムトラベル的な「変更前の状態への復元」は難しかった。 そこを補完するために、Entra Exporter のようなコミュニティツールや、Microsoft Graph API を叩く自前スクリプトで定期バックアップを実装している組織は少なくない。今回の機能はそれを ネイティブ機能として提供する点で価値がある。 実務への影響——日本の IT 管理者が押さえるべきポイント 1. 既存のサードパーティ製バックアップ製品との関係を整理する すでに Entra ID バックアップ目的でサードパーティ製品（例：IDFIX, Semperis DSP, AvePoint 等）を導入している組織は多い。今回の標準機能は「5日間保持・1日1回」というシンプルな仕様であり、監査ログとの突合、変更履歴の可視化、長期保持といった要件は引き続きサードパーティが担う場面が残るだろう。ただし「とりあえずバックアップがあれば十分」なレベルの用途では、コスト削減の検討材料になり得る。 2. バックアップの存在を「セキュリティインシデント対応手順書」に組み込む インシデントが起きてから「どこで何を復元できるか」を調べるのでは遅すぎる。今回の機能の存在をインシデントレスポンス手順書に明記し、Entra 管理センターの操作を事前に演習しておくことを推奨する。特に、条件付きアクセスポリシーが攻撃者に書き換えられた場合の復旧シナリオは一度通しで確認しておくべきだ。 3. Just-In-Time アクセスと組み合わせて多層防御を バックアップはあくまで「事後対応」の手段だ。「誤削除・改ざんをそもそも減らす」という観点では、Entra PIM（Privileged Identity Management） によるロール割り当ての時限化（Just-In-Time）や、重要な変更に対する多要素認証・承認フローの整備が先行すべき対策である。「常時アクセス権の付与は最大のリスク」という原則は、どれだけ優れたバックアップがあっても変わらない。 筆者の見解 正直に言えば、「なぜこれを5年前に作らなかったのか」 という気持ちを抑えることが難しい。Entra ID はすでに世界中の何十万という組織のアイデンティット基盤として稼働している。「バックアップはサードパーティで」という状況がこれだけ長く続いてきたことは、プラットフォームの信頼性という観点でもったいなかったと思う。 ...

April 2026のWindowsセキュリティ更新プログラムを適用したドメインコントローラーが再起動を繰り返す——。Microsoftがこの重大な不具合を公式に認定した。Active Directory環境を運用するIT管理者は、今すぐ対応状況を確認する必要がある。 何が起きているか 2026年4月のセキュリティ更新プログラム KB5082063 を適用したWindows Serverドメインコントローラーで、LSASS（Local Security Authority Subsystem Service） がクラッシュし、システムが再起動ループに陥るという深刻な不具合が報告されている。Microsoftはこの問題を正式に確認した。 LSASSはWindowsの認証基盤を担うコアプロセスだ。ローカルログオン、Active Directoryの認証、グループポリシーの適用など、Windowsドメイン環境の根幹をなす。これがクラッシュするということは、ドメインコントローラーとしての機能が完全に失われることを意味する。業務全体の停止に直結する最上位クラスの障害だ。 影響範囲 既存のドメインコントローラー: KB5082063を適用後にLSASSクラッシュ → 再起動ループ 新規デプロイのドメインコントローラー: 新しく展開した環境にも同様の問題が発生する可能性がある 新規デプロイにも影響が出るという点が特に厄介だ。通常、問題のある更新プログラムへの対処として「クリーンな環境に再デプロイ」という選択肢があるが、今回はその手が使えない可能性がある。リカバリーと展開作業の両面で制約が生じている状況だ。 現時点での対処方法 Microsoftのサポート情報を随時確認しつつ、以下の対応を検討してほしい。 1. 未適用環境：適用を保留する KB5082063をまだ適用していない環境では、修正済み更新プログラムがリリースされるまで適用を控えることを強く推奨する。 2. 適用済みで再起動ループ中の場合 ディレクトリサービス復元モード（DSRM） で起動し、問題の更新プログラムをアンインストールする。このためにDSRMパスワードが管理されていることが前提になる。管理されていない場合は……今すぐ確認せよ。 3. 複数DCがある環境 影響を受けていないドメインコントローラーで認証を継続させながら、問題のあるDCを切り離してリカバリーを行う。これが冗長化の本来の意味だ。 実務への影響 — 日本のIT管理者へ 日本のエンタープライズ環境では、いまだに多くの組織がActive Directoryをオンプレミスで運用している。ドメインコントローラーが再起動ループに陥ると、ユーザーはネットワークリソースへのアクセスができなくなり、業務が全面停止する。 明日から取れる具体的なアクション： パッチ管理フローを見直す: セキュリティ更新を即時適用するポリシーになっている場合、テスト環境での事前検証ステップが機能しているか確認する DSRMパスワードを確認・棚卸しする: 今回のような再起動ループへの最後の砦がDSRMだ。パスワードが適切に管理・記録されているか今すぐ確認せよ DCの冗長性を確認する: ドメインコントローラーが1台しかない環境は、こういった事態で完全に詰む。最低2台は必要だ Microsoftサービスヘルスとリリースノートを購読する: Windows ServerのリリースノートとMicrosoft Tech Communityのブログは、定期的に確認できる仕組みを整えておく 筆者の見解 セキュリティ更新プログラムの適用がこれだけのインパクトを持つ障害を引き起こすのは、正直「もったいない」の一言だ。Microsoftには世界最高水準の品質保証体制と検証プロセスがあるはずで、こういった問題が本番環境に流れ出る前に食い止める力のある会社のはずだ。 今回の件が改めて示すのは、「パッチ管理は仕組みで回せ」 というメッセージだ。セキュリティ更新プログラムを適用しないことは別のリスクを生む。だからといって盲目的な即時適用も危険だ。「テスト環境で検証してから本番展開」という当たり前のプロセスが、多くの現場でまだ機能していないのが現実だ。 「今動いているから大丈夫」——これは永遠に通用しない。DSRM、DCの冗長化、イベントログの監視体制——こういった備えは有事が起きてから調べるものではなく、日常の運用として整えておくべきものだ。今回の障害をきっかけに、自分たちのActive Directory運用の「有事対応力」を棚卸しする機会にしてほしい。 Microsoftには一刻も早い修正済み更新プログラムのリリースを期待したい。そして今後は、このクラスの問題がリリース前に検出されるような品質プロセスをさらに強化してほしい。実力は間違いなくある会社なのだから、こういう形で信頼を損なうのは本当にもったいない。 出典: この記事は Microsoft Confirms LSASS Crash Bug Causing Reboot Loops on Windows Server の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIエージェントが「実験」から「本番稼働」へと移行しつつある今、企業のCIOとCISOが直面している問いがある。「エージェントを野放しにせず、かつ業務を止めずに統制するにはどうすればいいか」——Microsoftが5月1日のGAを予告しているAgent 365は、まさにこの問いに正面から答えるプラットフォームだ。 AIエージェントは「もう一人の従業員」ではなく「もう一種のアイデンティティ」 Agent 365の設計思想を理解する上で鍵となるのが、AIエージェントをNon-Human Identity（NHI）として扱う点だ。エージェントは企業のデータにアクセスし、ワークフローを起動し、外部システムと連携する。これはかつてサービスアカウントやAPIキーが担っていた役割と構造的に似ているが、AIエージェントは「自律的に判断して動く」という点が根本的に異なる。 MicrosoftはAgent 365を、EntraがユーザーIDを管理するように、PurviewがデータをガバナンスするようにAgentを管理する「エンタープライズ・コントロールプレーン」と位置付けている。つまり、既存のMicrosoft 365セキュリティ基盤の延長線上にエージェント管理を乗せる設計だ。 コア機能：可視化・最小権限・監査 Agent 365が提供する主要な機能は以下の3点に集約される。 1. 組織全体のエージェント一元可視化 誰がどのエージェントを作り、どのシステムにアクセスし、何をしているのかを把握できない状態ではガバナンスは始まらない。Agent 365は内製・外部調達・ローコード作成のいずれであっても、稼働中のエージェントを一元インベントリとして管理する。ProコードのAgent 365 SDKやFoundryとのネイティブ統合も提供される。 2. ゼロトラスト原則に基づくアクセス制御 エージェントには最小権限（Least Privilege）が適用され、ポリシーベースのアクセス制御が機能する。人間ユーザーと同等のライフサイクル管理（所有者の明確化・権限の期限管理）が可能になる。常時フルアクセスを与えるのではなく、必要な時に必要な範囲だけ許可するJust-In-Time的な思想がここに反映されている。 3. 監査・コンプライアンス対応 エージェントが何を参照し、どのプロンプトを受け取り、どう応答・行動したかを追跡可能にするログ基盤を提供する。規制対応や内部監査の観点から、「AIが何をしたか説明できること」が企業に求められる水準は今後急速に高まる。 実務への影響 日本のIT管理者・エンジニアにとって、Agent 365は以下のシナリオで直接的な意味を持つ。 自動化推進チームにとって：エージェントを「実験フェーズ」で止めずに本番展開できる組織的根拠が生まれる。ガバナンス基盤がなければ情報システム部門やリスク管理部門の承認が下りないというボトルネックが、このレイヤーで解消しやすくなる。 IT管理者・セキュリティ担当にとって：Microsoft Entra・Purview・Defenderとの統合設計は、既存のM365管理スキルを活かしてエージェント管理に入れることを意味する。新しいサイロが生まれにくい構造は評価できる。 コンプライアンス担当にとって：AIの利用状況に対する監督義務は国内外で法制化の動きが加速している。Agent 365の監査ログ機能は、将来的な説明責任の要求に備えた布石として機能する。 なお、5月1日のGA後も機能追加は段階的に行われる見込みであり、初期リリースの範囲と将来ロードマップの確認は必須だ。 筆者の見解 NHI（Non-Human Identity）の管理こそが現代の自動化推進における最大のボトルネックだ——これは筆者が以前から繰り返し言ってきた話だが、Agent 365はその問題への構造的な答えとして、方向性は完全に正しい。 ゼロトラストの観点から言えば、エージェントに「常時アクセス権」を与えたまま運用するのは特権アカウント管理における最大のアンチパターンだ。Agent 365がこれを最小権限・ポリシー制御で押さえに来ているのは本質を突いている。エンタープライズにAI自動化を展開したいなら、このレイヤーを先に固めるのが「道のド真ん中」だと思う。 一方で、率直に言えば「発表から実装までの距離」への警戒も忘れてはならない。Microsoftが優れたアーキテクチャビジョンを示しながら、実際の製品がそれに追いつくまでに時間がかかる事例は珍しくない。5月1日のGAを待って、実際に触ってから判断する——その姿勢が重要だ。 今の企業に求められているのは「AIを禁止するか解禁するか」という二択ではなく、「安全に使い続けられる仕組みを先に作る」ことだ。Agent 365がその仕組みの一角を担えるとすれば、Microsoft 365プラットフォームへの投資を既にしている組織にとっては、非常に価値の高い選択肢になりうる。Microsoftにはぜひ、このビジョンを絵に描いた餅で終わらせず、現場で動く製品として仕上げてほしいと思っている。 出典: この記事は Microsoft Agent 365 Brings Enterprise-Grade Control to Agentic AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

法律事務所とコンプライアンス部門をターゲットに据えた本格展開 2026年4月15日、MicrosoftはCopilot in Wordに新機能を追加した。「法務・財務・コンプライアンスのプロフェッショナル向け」と明示された今回のリリースは、これまでのような「あらゆる場面で使えます」という汎用的な訴求とは一線を画している。特定の職種・業務フローに特化した機能群を打ち出してきたのは、少なくともCopilotの歴史の中では珍しい。 デモ動画でMicrosoftが選んだ例は「デューデリジェンスレポートの作成」。リスク分析・法的サインオフ・レビューサマリーといったワードが機能説明に並ぶ。意図は明確だ。 追加された3つの主要機能 1. ワードレベル精度の変更履歴（Track Changes） Copilotが生成・修正した内容に対して、変更履歴がデフォルトでオンになる。「どこを変えたか」が常に可視化され、監査証跡が自動的に残る仕組みだ。 契約書や規制対応文書では、誰が・いつ・何を変えたかの記録が法的効力を持つ場合がある。これまでCopilotを使うと「AIが書き直してしまって履歴が消えた」という懸念があったが、この機能はそこを直接解消する。 2. コンテキスト付きコメント管理 コメントの追加・返信・スレッド管理をCopilot経由で実行できる。重要なのは「正しいテキストに紐付いたまま保持される」という点で、長文文書でコメントが迷子になる問題を防ぐ。 「法務確認が必要な箇所にコメントを入れて、Financeのサインオフが必要な部分にフラグを立てる」という実務フローがそのまま命令文として書ける。具体的には： 「リスクファクターセクションで不明瞭な箇所にフラグを立て、先週のレビュー会議で出た内容に基づいてFinance確認または法的サインオフが必要なコメントを追加せよ」 これがWordの中でCopilotに指示できる。 3. 目次の自動挿入・更新 Wordの標準見出しスタイルに基づいて目次を挿入・更新する。文書が進化するたびに手動で直す手間がなくなる。地味に見えるが、何十ページにもわたる規制文書や報告書では相当な時短になる。 実務での活用ポイント 契約書レビューフロー Copilotにエグゼクティブサマリーをタイトに修正させ、変更履歴をオンにする リスクファクターセクションで法務・財務確認が必要な箇所にコメントフラグを入れる 目次を作成し、ヘッダーに文書タイトルと日付、フッターにページ番号を追加する 未解決の変更履歴とコメントを一覧化した「レビューサマリー」セクションを冒頭に自動生成する この一連の流れがすべてWordを出ずに完結する。法律事務所・企業法務・コンプライアンス部門にとって、ツールを行き来するコストは意外と大きく、そこを「Wordの中で完結できる」と訴えるのは理にかなっている。 注意点：現時点の制約 現在はWork IQのFrontierプログラム（Office Insiders Betaチャンネル）経由での提供で、一般展開ではない。Macバージョンは後日とされている。日本のM365テナントでいつ利用できるかは別途確認が必要だ。 マルチモデル戦略という背景 MicrosoftはCopilotが「OpenAIのLLMだけでなく、複数のモデルを活用している」と明言し始めている。今回の発表と同じタイミングで、他社AIがWordへの統合を発表したことも報じられているが、Microsoftはそれを追いかけるのではなく「Copilotはマルチモデルだから、業界最良のモデルを選んで使える」というポジションを打ち出している。 この戦略は興味深い。単一AIへの依存ではなく、ネイティブな統合・コラボレーション履歴の保持・Wordの書式尊重、これらを「モデル非依存で提供できる器」として差別化しようとしている。 筆者の見解 正直に言えば、Copilotには長い間、「帯に短し、たすきに長し」という印象を持ち続けてきた。汎用的すぎて結局何でもそれなりにしかできない、という場面が多かった。 ただ、今回の法務向け機能は方向性として間違っていない。「Track Changesがデフォルトでオン」「コメントスレッドが崩れない」「目次が文書の変化に追従する」——これらはCopilotの「すごさ」ではなく、プロフェッショナルが文書を扱う上での「当たり前の要件」だ。その当たり前を押さえてきたことは評価したい。 MicrosoftにはWordというプラットフォームを長年磨いてきた実績があり、法務文書の複雑さを理解するだけの素地もある。Wordの中でコラボレーション履歴・変更履歴・コメントスレッドという三位一体が機能するなら、専用の法務AIツールに飛び出す理由は薄れる。「Wordの中で完結できる」という価値提案は、特に日本企業のように「とにかくOfficeが標準」という環境では刺さりやすい。 一方で、現時点ではInsiders Beta限定という制約がある。この手の機能はGAまでに削られたり、UIが変わったりすることも少なくない。「本気でこの方向に投資するのか」は、GA後の展開を見てから最終判断したい。それだけのポテンシャルはある。Copilotが法務・コンプライアンス領域で本当に頼れるツールになれるか、今後の展開を注目している。 出典: この記事は Microsoft Copilot Specifically Targets Lawyers With New Capabilities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Exchange Online を使い続けているすべての組織に関係する話だ。Microsoft が Exchange Web Services（EWS）の完全廃止スケジュールを正式に発表し、カウントダウンが始まった。2027年5月の最終撤廃に向けて、2026年10月という「最初の壁」が迫っている。バックアップ製品、メールボックス移行ツール、社内開発のスクリプト——EWS に依存した仕組みを持つ組織は、今すぐ棚卸しを始める必要がある。 EWS とは何か、なぜ今廃止されるのか Exchange Web Services は約20年前に設計されたプロトコルだ。当時はオンプレミスの Exchange サーバーが主流で、ISV やサードパーティ開発者がメールボックスにアクセスする手段として事実上の標準となった。バックアップ製品、メールボックスのインポート・エクスポートユーティリティ、監査ツール——ありとあらゆる用途に EWS が使われてきた歴史がある。 しかし、クラウド時代のセキュリティ要件と照らし合わせると、EWS は設計思想そのものが古すぎる。Microsoft Graph API という現代的な代替手段が整備された今、20年前のプロトコルをクラウドサービスで維持し続けるコストとリスクは正当化できない、というのが Microsoft の判断だ。 廃止タイムライン：3つのフェーズを把握せよ 廃止は段階的に進む。整理すると以下のとおりだ。 2026年10月：EWS の無効化開始 テナントの EWSEnabled プロパティが True から False に変更され、EWS によるアクセスがブロックされる。ただしこのフェーズでは、管理者が設定を Null（デフォルト）または True に戻すことで EWS を再び有効化できる。完全に手を縛られるわけではない。 2027年4月1日：永続的な無効化の開始 この日から EWS の恒久的な無効化プロセスが始まる。数十万台に上る Exchange Online メールボックスサーバー全体への設定反映には時間がかかるため、プロセス自体は数週間かかる見込みだ。「4月1日以降は EWS が使えると思わないこと」と Microsoft は明言している。 2027年5月：完全撤廃完了 すべての Exchange Online サーバーから EWS が削除される。ここがゴールだ。 アローリストと EWSApplicationAccessPolicy の関係 2026年10月の無効化フェーズ前に、Microsoft は各テナントで実際に EWS を使っているアプリを観測してアローリスト（許可リスト）を自動生成する予定だ。このアローリストは既存の EWSApplicationAccessPolicy より優先される。 ...

MicrosoftはExchange Online PowerShellモジュールのConnect-ExchangeOnlineコマンドレットが持つCredentialパラメーターを、2026年6月に廃止することを発表した（MC1248389）。「また廃止か」と流し読みしてしまいそうな告知だが、バックグラウンドで動き続けている古いスクリプトを持つ組織にとっては見逃せない変更だ。 Credentialパラメーターとは何だったのか Credentialパラメーターはユーザー名とパスワードを格納したPSCredentialオブジェクトを受け取り、ROPC（Resource Owner Password Credentials）と呼ばれる認証フローでExchange Onlineに接続する仕組みだ。ROPCはOAuthの仕様上は存在するが、多要素認証（MFA）に対応していない。要するに「ユーザー名＋パスワードだけで認証する、昔ながらのやり方」をそのままスクリプトに持ち込んだ形態である。 MicrosoftのEntra IDトークン取得ライブラリであるMSAL（Microsoft Authentication Library）がすでにROPCのサポートを非推奨とした以上、それに依存するExchange Online PowerShellモジュールが追従するのは自然な流れだ。 どこに影響が出るか 対話セッションには実質的な影響はない。 管理者アカウントにはすでにMFAが設定されているはずであり、そもそもCredentialパラメーターを使って手動でログインするケースは稀だろう。 問題はバックグラウンドジョブだ。具体的には次のようなケースが該当する。 Windowsタスクスケジューラーから起動するPowerShellスクリプト 数年前に書かれ、メンテナンスがほとんど行われていない自動化スクリプト サービスアカウントのユーザー名＋パスワードをスクリプト内や別ファイルに保持しているもの こうしたスクリプトは、6月以降にMicrosoft側のサーバーコンポーネントがROPC対応を終了した段階でサイレントに壊れる可能性がある。エラーが出るならまだいい。最悪なのは「実行されているように見えて、実際には接続に失敗してスキップされている」状態だ。 移行先：Azure AutomationとマネージドID 推奨される移行先はAzure Automationのマネージドアイデンティティ（Managed Identity）を使ったRunbookだ。 比較項目 Windowsタスクスケジューラー Azure Automation + Managed Identity 認証方式 ユーザー名＋パスワード（ROPC） マネージドID（証明書不要） MFA対応 非対応 対応 シークレット管理 スクリプト内に埋め込みがち 不要（IDベース） 実行ログ ローカルイベントログ Azure Monitorで一元管理 コスト 無料（ただしWindowsサーバーが必要） 月500分まで無料、超過分は$0.002/分 Azure Automationの無料枠（月500分）は、典型的なExchange Online管理タスクであれば十分すぎる量だ。「Azureサブスクリプションが必要」「設定が複雑」という声はよく聞くが、一度慣れてしまえばタスクスケジューラーには戻りたくなくなる。 実務への影響——今すぐやること ステップ1: スクリプトの棚卸し 出典: この記事は Exchange Online PowerShell Dumps the Credential Parameter の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のエコシステムを支える根幹インフラであるMicrosoft Graph APIに対し、複数のMicrosoft MVPがフィードバックフォーラムで正式に問題提起した。単なる不満の声ではなく、「このままでは開発者が壊れる」という切実な訴えだ。 Graph APIが抱える5つの構造問題 1. カバレッジの欠落と一貫性のなさ Microsoft Graphは当初「M365のあらゆるデータに一貫したAPIで触れる」という約束のもと設計された。しかし現実は厳しい。Exchange Onlineはメールボックス作成にGraph APIがなく、未だにPowerShell頼み。SharePoint OnlineのGraph APIは2022年に登場したが、それ以降ほとんど進化していない。TeamsのポリシーはSkype for Business時代の枠組みを引きずったままで、Graph APIが存在しない領域が多い。 2. 未ドキュメントAPIの横行 管理ポータルの裏側では、PowerShellにもGraphにも公開されていないAPIが静かに動いている。Microsoft XDRなどの重要ソリューションにはインターフェース自体が存在しない。エンジニアリングチームが「作り中」であることは理解できるが、主要な管理ポータルが未公開APIに依存したまま運用され続けているのは問題だ。 3. ベータAPIの「永久ベータ」化 AuditLogQuery APIはその象徴だ。Purviewの監査検索で実際に使われている非同期APIが、長期にわたってベータのままだ。テナント側はベータAPIを本番運用に組み込むことを避けたい。「いつ仕様が変わるかわからない」リスクを抱えながら開発することは非常に困難で、プロダクション昇格の見通しも示されていない。 4. PowerShell SDKのリソース不足 Microsoft Graph PowerShell SDKは新バージョンのたびに70万件以上ダウンロードされるほど利用されている。それでもSDKを担当するチームは極めて小規模で、報告されたバグが長期間放置されることが常態化している。需要と投資のアンバランスは明らかだ。 5. アセンブリ競合という開発者への嫌がらせ Exchange Online PowerShellモジュールとGraph PowerShell SDKを同一セッションでロードしようとすると、順番によってクラッシュする。「Exchange → Graph」はOKだが「Graph → Exchange」は失敗する。自動化スクリプトを書いている人間にとって、これは単純に業務を止める問題だ。 なぜこれが重要か Graph APIの整備不足は、単なる開発体験の問題ではない。自動化・ガバナンス・セキュリティ運用のすべてがAPIの質に直結する。Non-Human Identity（NHI）を活用した業務自動化を進めようとしても、APIが不完全では自動化できない領域が残り続ける。結局「人間が手でやる」フローが温存される。これは効率化の根幹に影響する話だ。 実務での活用ポイント ベータAPIの利用判断: 本番システムへのベータAPI組み込みは、プロダクション昇格のロードマップが明示されているものに限定する。Microsoftの公式フィードバックフォーラムでステータスを定期的に確認する習慣を PowerShell SDKのバージョン管理: アセンブリ競合を避けるため、Exchange Online管理スクリプトとGraph SDKを使うスクリプトは別セッション・別スクリプトとして明確に分離する Entra ID + Graph を組み合わせた自動化設計: APIが存在する領域は積極的にGraph経由で実装し、存在しない領域はPowerShell + マネージドIDの組み合わせで補完する設計を標準化しておく MVPフォーラムのモニタリング: 今回のような提言はMicrosoft Feedback Forumに公開されている。MS製品の動向を追う上でエンジニアブログ以上に生の情報が集まる場所なので、定期的に目を通すと良い 筆者の見解 Microsoftが「GraphはM365外部アクセスの標準ルート」と掲げながら、その整備に十分なリソースを割かないのは、正直もったいないと思う。Graphは単なるAPIではなく、自動化・セキュリティ・ガバナンスを束ねるプラットフォームの土台だ。ここが脆弱なままでは、いくら上のレイヤーで高度な機能を打ち出しても、運用現場での信頼は積み上がらない。 ...