M365

Microsoft 365 Copilot のアナリティクス機能が、2026年4月下旬から5月下旬にかけて大幅に拡張される。これまで限定的だったアプリ別の利用データが統合され、管理者が組織全体のAI活用状況を一元的に把握できるようになる。ライセンス管理・投資対効果の可視化を求める声が多かっただけに、実務上の意義は小さくない。 何が追加されるのか 今回の更新（ロードマップID: 557981）では、Copilot Dashboard と Copilot Analytics の Advanced Analysis に新しいメトリクスが追加される。具体的には以下の3方向に強化される。 1. 新アプリのカバレッジ追加 これまでトラッキングが薄かった Microsoft Edge と OneNote、そして Microsoft 365 Copilot アプリ（旧 Copilot.microsoft.com）での操作が新たに計測対象となる。EdgeへのCopilot統合は企業での利用が増えているが、その実態がほとんど見えなかった。 2. インテントベースのシナリオ計測 Outlook・Word・Excel・PowerPointでは、単なる「Copilotを開いた回数」ではなく、何をしようとして使ったかという意図別の計測が加わる。具体的には以下が対象： 返信の提案（Suggested replies） 翻訳（Translation） 文章コーチング（Coaching） データクレンジング（Clean data） これにより「Copilotは導入したが、実際に何に使われているか分からない」という管理者の悩みに応える形となる。 3. 展開はテナント自動有効化 設定変更・ポリシー更新は不要で、ライセンス保持ユーザーのいる全テナントに自動展開される。ロールバックも用意されており、フライトコントロール経由で管理できる。 実務への影響 IT管理者・Copilotオーナーの方へ 5月上旬に予定されているオンラインドキュメントの更新を確認し、社内のCopilot利用レポートを作成しているチームに変更を周知しておくこと インテントベースのデータが取れるようになると、「使われているが効果が出ていない機能」の特定が容易になる。ユーザートレーニングの優先順位付けに直接活かせる 翻訳・コーチングの利用頻度が可視化されることで、ROI報告をより具体的な数字で構成できるようになる グローバル展開・多言語環境の企業 翻訳機能のインテント計測は、海外拠点との連携が多い日本企業にとって特に有益なデータになりうる。実際にどれだけ翻訳用途で使われているかが数値化される。 筆者の見解 Copilot Analytics の強化は、管理者として歓迎すべきアップデートだ。特にインテントベースの計測は「何となく使った件数」から「何のために使われたか」へと分析の質が変わる点で意義がある。 ただ、正直に言えば、データが増えることと、そのデータが活用されることは別の話だ。メトリクスが充実しても、それを見て「じゃあトレーニングを改善しよう」「この機能は使われていないから導入方法を見直そう」という次のアクションに繋げられている組織がどれだけあるか。ダッシュボードが増えるほど、かえって「見ている」だけで終わるリスクもある。 M365 Copilotへの投資効果を最大化したいなら、このアナリティクスを「報告用の数字」ではなく「改善のトリガー」として使う文化を組織内に根付かせることが先決だと思う。インテントデータは、ユーザーが実際に何を求めているかを正直に映す鏡でもある。その鏡を見て、次の一手を打てるかどうかが、AI活用の差を生む。 4〜5月にかけて自動展開されるので、展開後にCopilot Dashboardを確認し、新しいメトリクスの意味を理解しておくことをお勧めする。 出典: この記事は MC1266023 - Microsoft 365 Copilot: Comprehensive Copilot metrics in Copilot Analytics の内容をもとに、筆者の見解を加えて独自に執筆したものです。

モバイルデバイス管理（MDM）製品に重大な脆弱性が発見され、すでに実攻撃に悪用されていることが確認された。米国の政府機関向けサイバーセキュリティ機関であるCISA（Cybersecurity and Infrastructure Security Agency）は、Ivanti Endpoint Manager Mobile（EPMM）の深刻な脆弱性に対し、連邦民間機関に即時対応を求める緊急指令を発令した。他人事ではない。日本企業でも広く使われているMDM製品群に共通する構造的リスクが、今回の件で改めて浮き彫りになった。 Ivanti EPMMとは何か、何が問題なのか Ivanti EPMM（旧MobileIron Core）は、スマートフォンやタブレット、ノートPCを一元管理するエンタープライズ向けMDMソリューションだ。企業のBYOD（個人所有デバイスの業務利用）ポリシーの管理や、メール・VPN・アプリの配布制御を担う基盤として、世界中の中〜大規模企業で採用されている。 今回CISAが警告したのは、このEPMMに存在するクリティカルな脆弱性（CVE番号は記事執筆時点では確認中）が、すでに実環境で攻撃に利用されているという点だ。MDM製品の性質上、端末のフルコントロールや認証情報へのアクセス権限を持つため、攻撃者にとって非常に魅力的な標的となる。 CISAはKnown Exploited Vulnerabilities（KEV）カタログに本脆弱性を追加し、連邦機関に対して期限付きの修正適用を義務付けた。KEVカタログへの追加は「理論上のリスク」ではなく「実際の攻撃が確認された証拠」を意味する。 MDM製品が「攻撃の入口」になるリスク MDMは本来、デバイスを守るためのツールだ。しかしその管理サーバー自体が脆弱であれば、攻撃者にとって「全デバイスへの玄関口」となる逆転現象が起きる。 過去にもIvantiの製品群（Connect SecureやPolicy Secureなど）が相次いで攻撃に悪用されており、今回のEPMMはその文脈の延長線上にある。単一ベンダーへの過度な依存は、そのベンダーの製品群に問題が生じたときのリスク集中を意味する点も、改めて認識しておく必要がある。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. 自社のMDM製品・バージョンを即確認する Ivanti EPMMを使用している場合は、Ivantiのセキュリティアドバイザリページで最新のパッチ情報を確認し、速やかに適用する。バージョン管理が曖昧な環境では、まず棚卸しから始めること。 2. MDM管理サーバーへのアクセスを制限する インターネットに直接公開されているMDM管理コンソールは即座にアクセス制御を見直す。管理系インターフェースは原則として内部ネットワークまたはVPN（あるいはゼロトラストの条件付きアクセス）経由に限定すべきだ。 3. 侵害の痕跡（IoC）を調査する すでに攻撃が行われていた場合、パッチ適用前に侵害されている可能性がある。CISA等が公開するIoCを参照し、ログを精査すること。パッチを当てれば終わりではない。 4. Just-In-Timeアクセスの検討 MDMサーバーへの管理者アクセスは常時付与するのではなく、作業時のみ権限を払い出すJust-In-Time（JIT）方式を検討する。常時アクセス可能な管理者アカウントは、いざ侵害されたときの被害を際限なく広げる。 筆者の見解 今回の件を見て、改めて感じるのは「MDM製品はセキュリティツールであると同時に、最も狙われやすい資産の一つ」という現実だ。 ゼロトラストの観点から言えば、MDMのような管理系サーバーを「社内にあるから安全」「VPNの内側にあるから大丈夫」という前提で運用するのは、もはや通用しない。ネットワーク層で守る時代はとっくに終わっている。認証・認可の層で制御し、管理サーバーへのアクセスそのものを最小限に絞る設計が必要だ。 日本の大企業では、かつてのセキュリティモデルと、中途半端に導入されたゼロトラストの仕組みが混在した状態になっているケースをよく見かける。「VPNで囲えば安心」という発想から脱却できていない組織も多い。しかし現実には、VPNやMDMの管理サーバー自体が突破口になる事例が世界中で起きている。 MDM製品を使うことは正しい。モバイルとPCを統合管理する仕組みはエンタープライズに不可欠だ。ただし、その管理基盤を守ることへの投資を怠ると、守るはずのものが攻撃の橋頭堡になる。Ivantiに限った話ではなく、MDMという仕組みの全体を「攻撃者の目線」で見直すきっかけとしてほしい。 今すぐパッチを当てること。それが最初の一手だ。 出典: この記事は CISA Warns of Actively Exploited Ivanti EPMM Vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft PurviewのDSPM（Data Security Posture Management／データセキュリティ態勢管理）が2026年4月に正式提供（GA）を迎えた。マルチクラウド環境に散らばる機密データの可視化に加え、サードパーティのセキュリティシグナルとの統合や認証情報スキャンが新たに加わり、データセキュリティの「現状把握」という最も根本的な課題に本格的に向き合う機能が揃った。 DSPMとは何か——DLPとの違いを押さえる DSPM（データセキュリティ態勢管理）は、組織のデータ資産が「どこに」「どんな形で」「誰がアクセスできる状態で」存在するかを継続的に把握するための概念と技術の総称だ。 従来のDLP（データ損失防止）が「機密データを外に出さない」ことに注力するのに対し、DSPMは「そもそもデータはどこにあるのか」という根本的な問いから出発する。ポリシーを作る前に実態を知る、というアプローチだ。 今回の主要アップデート サードパーティシグナルの統合 BigID・Cyera・OneTrust・Varonisといった業界大手のデータセキュリティツールとのシグナル統合が実現した。Purviewのネイティブスキャンだけでは見えにくいオンプレミス資産や他クラウド環境のデータも、単一のダッシュボードに集約できるようになる。既存ツールへの投資を捨てずに、Purviewで「統合ビュー」を持てる設計は現実的で評価できる。 認証情報・シークレットスキャン パスワード・APIトークン・秘密鍵がデータ資産内に平文で保管されていないかをスキャンする機能が追加された。ゼロトラスト実装において盲点になりやすい「資格情報の散在」に直接対処するものだ。「動いているシステムのどこかにAPIキーが埋め込まれている」という状況は今でも珍しくなく、この機能の実用価値は高い。 Security Copilotとの連携強化 検出されたリスクに対して、AIが修復アクションを提案・自動実行を支援する仕組みが強化された。SOCチームが単純な修復作業から解放され、より高度な分析に集中できる環境を目指している。 実務への影響——日本の現場で何が変わるか 日本のエンタープライズ環境では、SharePoint Online・Exchange Online・Azureストレージが混在しつつ、オンプレミスNASやAWS S3が並走するケースが多い。このような複合環境でDSPMは特に価値を発揮する。 実務での活用ポイント 機密情報ラベルの棚卸しを先に行う。DSPMはラベルのないデータも検出するが、Sensitivity Labelsが整っているほど分類精度が上がる。ラベリングが未整備なら、DSPMと並行して進めると相乗効果がある サードパーティ連携は段階的に。BigIDやVaronisをすでに導入済みなら、まずそこから統合を始めると既存投資を活かせる シークレットスキャンは最優先で有効化を。「ソースコードリポジトリにAPIキーが入ったまま本番稼働」という事故は今も後を絶たない。発見から修復までのプロセスを先に設計しておくこと AI修復提案は「提案」として扱う。Security CopilotのAutofix機能は便利だが、人間が承認するワークフローを維持するほうが望ましい。自動化は段階的に広げる 筆者の見解 セキュリティの話はどうしてもコンプライアンス重視で硬くなりがちだが、DSPMの本質は「データの実態を正直に知ること」だと思っている。何が、どこに、どんな形で存在するか分からないまま精緻なポリシーだけ積み上げても、それは地図なしで見張りをするようなものだ。 日本の大規模エンタープライズでは、旧来のセキュリティモデルにゼロトラストの要素を後付けで重ねた結果、「どこが誰の責任範囲か誰も分からない」という状況が各所で起きている。DSPMの「まず現状把握」というアプローチは、そういった積み重なった複雑さを解きほぐす入り口としても有効だ。 マルチクラウドのシグナルを一元化するというPurviewの方向性は正しい。Microsoft 365とAzureの統合資産を持つMicrosoftが、ここで本来の統合プラットフォームとしての力を発揮できるかどうか——DSPMはその試金石になる。2026年後半にかけて機能がどこまで成熟するか、実際の導入事例とともに注目していきたい。 出典: この記事は Beyond Visibility: The new Microsoft Purview Data Security Posture Management (DSPM) experience の内容をもとに、筆者の見解を加えて独自に執筆したものです。

グローバルチームとの会議で「誰が何語で話しているか」をいちいち手動設定していた手間が、ついに不要になる。Microsoft Teamsの2026年4月アップデートは、地味に見えて実務直結の機能強化が揃っている。 4つの新機能：何が変わるのか 1. AI自動言語検出（10言語対応・精度95%） 多言語会議において、各話者がどの言語で話しているかをAIがリアルタイムで自動判別し、対応する字幕を表示する。対応言語は英語・日本語を含む10言語で、精度は95%と発表されている。 特筆すべきはデバイスローカルで処理される点だ。音声データがクラウドに送信されるのではなく、手元のデバイス上で推論が走る設計になっている。機密性の高い会議でも「音声が外部サーバーを経由している」という懸念を払拭できる。 2. AIによる会議後の動画要約・アクションアイテム生成 会議録画から重要ポイントを自動抽出し、「誰が何を決めたか」「次に誰が何をするか」をまとめたアクションアイテムを自動生成する。録画を見返す時間を大幅に削減できる。 3. 会議コントロールツールバーの非表示オプション プレゼンテーション中にマイクやカメラのコントロールバーが邪魔と感じていた人向けに、ツールバーを非表示にできる設定が追加された。画面共有時のUXが改善される。 4. Windows「集中モード（Do Not Disturb）」との連携 WindowsのDo Not Disturb設定と連動し、集中作業中は通知を自動で抑制する。OS側の設定がTeamsにも反映されるため、別途Teamsの通知をオフにする操作が不要になる。 実務への影響：日本のエンジニア・IT管理者へ 多国籍プロジェクトを抱える組織にとって、AI字幕の自動言語検出は即効性のある機能だ。 従来は「この会議は英語メイン」「日本語に切り替えて」と手動で設定するか、事前に言語設定を合わせておく必要があった。自動検出になることで、混在する言語環境でもシームレスに字幕が機能する。 ローカル処理という設計判断は、企業のコンプライアンス担当にとっても朗報だ。 特に製造業・金融・官公庁など、情報管理が厳しい業種では「クラウドに音声が出るかどうか」が導入可否の分かれ目になることがある。デバイス内完結という方式は、そのハードルを大きく下げる。 IT管理者への実務ポイント： 自動言語検出は設定で有効化が必要か確認しておく（テナント管理者側のポリシーに依存する可能性がある） ローカル処理の要件（RAM・CPU）を確認し、古いデバイスでの動作に注意 Do Not Disturb連携はWindows側のFocus Assist設定との整合性を確認 筆者の見解 Teamsの会議AI機能は、M365の中でも「実際に使われ、実際に効果が出る」領域の一つだと思っている。議事録作成・アクションアイテム整理・多言語対応——これらはルーティン業務の中でも特に時間を食うものだ。 そしてローカル処理という設計には、Microsoftの本気が見える。クラウド依存が当然視されるAI機能において、あえてデバイス側で完結させる実装は、エンタープライズ利用者のプライバシー懸念を正面から受け止めた結果だろう。こういうことをきちんとやれるのがMicrosoftの強みであり、エンタープライズ信頼の積み上げ方を熟知している証左だ。 この方向で着実に積み上げていけば、「本当に現場で使えるツール」としての地位はより盤石になる。会議まわりの改善は地味に見えて、実は日常業務の最も高頻度な摩擦点だ。そこを丁寧に磨いてきたこのアップデートは、素直に評価したい。 出典: この記事は Microsoft Teams April 2026 Update: Hide Toolbar, AI Video Recaps, Auto Language Captions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

17カ国・5,000人のIT意思決定者を対象にした大規模調査が、セキュリティ業界の根本的な問題を浮き彫りにした。Sophosが発表した「Cybersecurity Trust Reality 2026」レポートによると、大多数の組織が自社のサイバーセキュリティベンダーを「完全には信頼していない」という現実が明らかになった。透明性・説明責任・リスク管理——どれをとっても、ベンダーへの期待と現実の間には大きなギャップが存在する。 調査が示した「信頼の溝」 セキュリティベンダーとクライアント企業の間に横たわる信頼の問題は、長年業界で語られてきた。今回の調査はその実態を数字として可視化した点で意義深い。 信頼を損なっている主な要因として、調査では以下が浮かび上がっている： 透明性の欠如: 自社製品の限界や既知の脆弱性について十分な開示がない 説明責任の曖昧さ: インシデント発生時の責任の所在が不明確 脅威環境への追従不足: 急速に進化する攻撃手法に対し、提供ソリューションが後手に回る なぜこれが日本のIT現場に刺さるのか 「製品を入れれば安全」という幻想への強烈な警告——これが今回の調査の本質だ。 日本の大企業では、この問題はさらに複雑な様相を呈する。レガシーなオンプレミスのセキュリティモデルとクラウド時代の新しいアーキテクチャが混在し、中途半端なゼロトラスト実装が上乗せされることで、全体像を把握している担当者すら不在という状況が生まれやすい。そこにベンダー製品を積み重ねると、複雑性だけが増大し、何が何を守っているのかすら分からなくなる。 実務への影響——「賢い買い手」になる 1. SLA・インシデント対応の透明性を契約に明記する 「何かあったときにどうするか」を曖昧にしたまま契約するのはリスクそのものだ。レスポンスタイム、エスカレーションパス、情報開示の範囲を契約段階で明確化しておくことが必須になる。 2. ゼロトラストアーキテクチャとの整合性を確認する ベンダー製品がゼロトラストの思想と整合しているかを問い直す機会だ。境界防御型の製品を惰性で追加しても、現代の脅威には対応できない。ネットワーク層・認証層・認可層の3層で整理し、各製品が本当に必要かを見極める。 3. Just-In-Time（JIT）アクセスを軸に据える 常時アクセス権の付与は特権アカウント管理における最大のリスクだ。ベンダーが提供するソリューションがJITをサポートしているか、自社のIDaaS環境と統合できるかを確認したい。 4. 部分最適の積み重ねに注意する 複数ベンダーの製品が乱立すると、全体最適ではなく部分最適の積み重ねになる。統合管理の視点から、あえてベンダーを絞ることも有力な選択肢だ。 筆者の見解 ベンダーを信頼できない最大の原因は、そもそも「なんのためにこの製品を入れているのか」が購入側に明確でないことにある、というのが正直なところだ。要件定義が甘いまま営業提案ベースで導入を決め、インシデントが起きてから「これって対応してたんじゃないの？」となるサイクルが繰り返されている。 ゼロトラストは「概念」として語られても「実装」として根付いていないケースが多い。VPNを廃止してIDベースのアクセス制御に移行するだけでも、セキュリティの質は劇的に変わる。特定の製品への依存より、アーキテクチャの思想を先に固める——その順序を間違えると、高い製品を買っても安全にはなれない。 ベンダーへの不信が高まる今、求められているのは企業側が「賢い買い手」になることだ。信頼は与えられるものではなく、検証するものだ——これはゼロトラストの本質であり、ベンダー選定にもそのまま適用される原則だと思う。製品を「使いこなす」組織だけが、本当の意味でセキュリティを確保できる時代になった。 出典: この記事は Most Organizations Do Not Fully Trust Their Cybersecurity Vendors の内容をもとに、筆者の見解を加えて独自に執筆したものです。

企業のAI導入は、静かに、しかし確実に次のフェーズへ移行しつつある。「とりあえずAIを入れてみよう」から「きちんとガバナンスを設計してAIを運用しよう」への転換だ。この変化は一部の先進企業だけの話ではなく、日本の中堅・大企業にも直接関係してくる動きである。 なぜ「ポイントツール」では限界が来たのか ここ数年、多くの組織では部署ごとに異なるAIツールが導入されてきた。営業チームはA社のチャットAI、開発チームはB社のコード補完ツール、人事部門はC社の文書生成AI――といった具合だ。当初はこれで十分に見えた。個々のツールは確かに便利で、生産性も上がる。 ところが問題が積み重なってくる。誰がどのデータにアクセスしているのか把握できない。AIが出力した情報の根拠が不明なまま意思決定に使われる。コンプライアンス部門からは「内部情報がどのAIサービスに渡っているのか」という問いに答えられない。情報漏洩インシデントが起きたとき、責任の所在が曖昧になる。 企業がAIを「拒絶」したのではない。統制できないAIを拒絶したのだ。 プラットフォームが求められる理由 この文脈で「プラットフォーム型AI」が注目を集めている。ポイントツールの集積ではなく、認証・認可・監査ログ・データ境界・利用ポリシーが統一的に管理された基盤の上でAIを動かすアプローチだ。 具体的には以下のような要件が求められるようになっている： アカウンタビリティ：誰がいつ何のためにAIを使ったかを追跡できる データ境界の明確化：機密データがどのAIモデルに触れるのかを制御できる ポリシーの一元管理：部署ごとにバラバラな運用ルールではなく、組織として統一されたガバナンス 監査対応：法令・規制・社内コンプライアンスへの説明責任 Microsoft 365の環境で言えば、Copilotを単独で使うだけでなく、Azure AI FoundryやPurviewなどのガバナンス基盤と組み合わせて使うことが、まさにこの「プラットフォーム型」の実践に当たる。 実務への影響：日本のIT管理者・エンジニアへ 日本の大企業では現在、「Copilotを全社展開した」という段階で満足しているケースも多い。しかしそれはまだ出発点に過ぎない。 IT管理者が今すぐ取り組むべきこと： AI利用の棚卸し：社内で使われているAIツールを把握する。シャドーIT化しているものは特に注意 データ分類ポリシーの整備：どの情報をどのAIに与えてよいかのルールをPurview等で可視化する 監査ログの有効化：Copilotの利用ログをMicrosoft 365の監査機能で取得・保管する Foundry経由の外部AI活用を検討：Copilotだけに閉じず、高度なタスクには別のモデルをFoundry経由で安全に使える仕組みを設計する 「禁止する」アプローチは機能しない。ユーザーが公式に提供された仕組みを最も便利と感じる環境を整えることが、ガバナンスの本質だ。 筆者の見解 ポイントツールからプラットフォームへの移行は、技術トレンドというより「当然の帰結」だと筆者は見ている。バラバラなAIツールを部署ごとに入れ続けることは、部分最適の積み重ねであり、組織全体としては非効率で高コストな状態を生む。統合プラットフォームの全体最適という観点からすれば、今回の動きは遅すぎるくらいだ。 MicrosoftはM365・Entra・Purview・Foundryと、ガバナンス型プラットフォームを構成するピースを実は持っている。それを一貫したビジョンとして組み合わせ、ユーザーが迷わず使いこなせる形にしていけるはずだ。プラットフォームの総合力という点では、今でも強力なポジションにある。その実力を存分に発揮してほしいと思う。 Teamsの会議録やOutlookの定型作業はCopilotに任せ、高度な分析や創造的なタスクには外部AIをFoundry経由で安全に活用する——こうした「使い分け」の設計こそが、今の日本企業に最も必要なアーキテクチャ判断だ。プラットフォームの選定より、その上でどう設計するかを今こそ議論すべき時期に来ている。 出典: この記事は From Point Tools to Platforms: Why Enterprise AI Is Moving from Generic Assistants to Governed Platforms の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 365とMicrosoft Power Platform、そしてAzure Logic Appsを連携させる「Windows 365コネクタ」をパブリックプレビューとして公開した。IT部門や運用チームがクラウドPC（Cloud PC）に関連する管理タスクをローコード・ノーコードのツールで自動化できるようになる。地味なアップデートに見えるかもしれないが、実務への影響は意外と大きい。 Windows 365コネクタとは何か Windows 365は、Microsoftが提供するクラウドPCサービスだ。フルスペックのWindowsデスクトップをクラウドからストリーミングし、ユーザーはブラウザや専用クライアントからアクセスできる。VDI（仮想デスクトップインフラ）の現代版と言えるが、従来のVDIよりもセットアップが大幅に簡略化されており、ユーザーごとに専用のクラウドPCが割り当てられる点が特徴だ。 今回の発表の核心は、このWindows 365の管理操作をPower AutomateやLogic Appsのフローから呼び出せるようになった点だ。具体的には、Cloud PCのプロビジョニング・プロビジョニング解除、リセット、再起動、ユーザーへの割り当て変更といった操作をフロー内のアクションとして組み込める。 Power Platform・Logic Appsとの連携で何が変わるか これまでWindows 365の管理はMicrosoft Intune管理センターやGraph APIを通じて行うのが主流だった。Graph APIを直接叩く場合はある程度のプログラミングスキルが必要で、自動化のハードルが高かった。 Power Automateとの統合により、たとえば以下のようなシナリオが現実的になる。 オンボーディング自動化: 新入社員のAzure ADアカウントが作成されたタイミングをトリガーに、Windows 365 Cloud PCを自動でプロビジョニングし、入社手続きの完了をメールで通知するフローを構築できる オフボーディングの確実な実行: 退職者のアカウント無効化に連動してCloud PCを自動でプロビジョニング解除し、ライセンスを返還する処理を一気通貫で回せる 定期メンテナンスの自動化: 特定の条件（利用率が低いCloud PC群など）に対して、スケジュール実行でリセットや再起動を行う運用ができる Logic Appsとの統合はよりエンタープライズ寄りのシナリオ、つまりServiceNowやSAPなど外部システムと連携した高度なオーケストレーションを想定しているものと思われる。 なぜこれが重要か——日本のIT現場への影響 日本の企業IT部門では、Windows 365を検討・導入しているものの、「管理の自動化が追いついていない」という声をよく聞く。Intuneの管理センターからGUIで操作しているうちは良いが、台数が増えるにつれ手作業の限界がくる。かといってPowerShellやGraph APIを書けるエンジニアを常時確保するのも難しい。 Power Automateで自動化できるということは、システム管理者やいわゆる「ちょっとできるビジネス担当者」でも運用フローを組めるということだ。専任開発者に依頼しなくても、部門内でライフサイクル管理の自動化が回せる可能性が出てくる。 さらに、Power Automateは既にTeams・SharePoint・Outlookとの連携実績が豊富だ。Windows 365コネクタが加わることで、M365エコシステム内での一気通貫な自動化の絵が描きやすくなる。この「統合して使うことで初めて価値が出る」というのが、Microsoft 365というプラットフォームの本質だと筆者は考えている。 実務での活用ポイント まずはオフボーディングフローから手をつけよ: 退職者処理のCloud PC関連ステップを自動化するだけでも、情報漏洩リスクの軽減とライセンスコスト削減の両方に効く。実装難易度が低く、効果が測定しやすいため、初手に最適だ Graph APIと並列に考えない: Graph APIで複雑な処理をゴリゴリ書くか、Power Automateで簡単に組むか、という二択ではなく、Power AutomateからHTTPコネクタ経由でGraph APIを補完的に呼ぶ構成も有効だ Logic Appsは既存のITSMと組み合わせて: ServiceNowやJira Service Managementと連携させ、チケット起票をトリガーにCloud PCを払い出す、といったエンタープライズ向けフローに活路がある プレビュー段階のSLA・制限に注意: パブリックプレビューは本番利用には向かない。機能確認・検証目的で触れておき、GAを待って本番展開するのが堅実だ 筆者の見解 Windows 365とPower Platformの統合は、方向性としては正しい。むしろ「なぜこれほど時間がかかったのか」という気持ちもある。Intuneと並んでWindows 365の管理需要が高まる中、Power Automateとの連携は当然求められていたはずだ。 ...

Microsoft 365 CopilotのEU/EFTA向けに、静かに、しかし重大な変更が加わろうとしている。2026年4月17日、Microsoftは「Flex Routing（柔軟ルーティング）」をすべてのEU/EFTAテナントでデフォルト有効化する。メッセージセンターの投稿MC1269223で告知されたこの変更、見落としている管理者は今すぐ確認が必要だ。 Flex Routingとは何か Flex Routingとは、CopilotのLLMインファレンス処理（推論処理）のピーク需要時に、EU圏のGPUキャパシティが逼迫した場合に限り、米国・カナダ・オーストラリアのデータセンターへ処理をルーティングする仕組みだ。 ここで言う「インファレンス」とは、大規模言語モデルが実際にプロンプトを受け取り、応答を生成するフェーズを指す。このタイミングまでに、前処理・安全チェック・RAG（Retrieval-Augmented Generation）によって組織のデータ（メール・ファイル・メタデータ・システムプロンプト）がすでにプロンプトにバンドルされている。つまりFlex Routingが作動した場合、これらのデータ一式がEU域外で処理されることになる。 Microsoftは「転送中・保存時のデータは暗号化される」「保存データ（data at rest）はEUデータ境界内に留まる」と強調している。ただし「限定的な仮名化データ（pseudonymized data）」がセキュリティ・運用目的でEU域外に保存される可能性があることも認めている。 なぜこれが問題なのか 欧州のデータプライバシー規制は、クラウドサービスにとって常に厳格な制約だ。GDPRはもちろん、NIS2（ネットワーク・情報セキュリティ指令）やDORA（デジタル運用強靭性法）といったセクター固有の規制も、EU内組織のデータが域外で処理されることを厳しく制限している。 Microsoftが提供するEUデータ境界（EU Data Boundary）は、まさにこれらの規制に対応するための仕組みであり、多くの欧州企業がこれを前提にCopilotを導入してきた。Flex Routingはその「EU処理保証」に条件付きの例外を設けるものだ。 問題の核心はデフォルト設定にある。 2026年3月25日以降に作成された新規テナント：デフォルト有効 既存テナント：2026年4月17日からデフォルト有効に変更 管理者が自ら確認・判断しなければ、知らないうちにFlex Routingが有効になっている状態が生まれる。 管理者が今すぐやるべきこと EU/EFTAリージョンでテナントを管理している場合、以下の手順で設定を確認する。 Microsoft 365管理センターにAI管理者ロールを持つアカウントでサインイン Copilot > 設定 > 柔軟な推論処理（Flexible inferencing） に移動 自組織のデータガバナンスポリシーに照らし、有効・無効を判断する なお、以下のケースではFlex Routingの設定が表示されない（適用対象外）。 Multi-Geo機能を購入済みのテナント EU/EFTA以外のリージョンでサインアップしたテナント 実務への影響 日本企業には直接適用されないが、グローバル展開している組織でEUサブテナントを持つケースでは無関係ではない。また、EU顧客向けにサービスを提供しているSaaS事業者やMSP（マネージドサービスプロバイダー）は、顧客テナントの設定確認が急務になる。 実務上のチェックポイントを整理すると： GDPR DPO（データ保護責任者）への確認：インファレンス処理のEU域外転送がデータ処理契約（DPA）の範囲内かを確認する セクター規制の確認：金融（DORA）・医療・行政など規制が厳しい業種では慎重な検討が必要 社内データガバナンスポリシーの照合：「EU内処理のみ」という内規がある場合は即時無効化が必要 変更管理プロセスへの組み込み：今後もこの種のデフォルト変更が起こりうる。定期的なメッセージセンターレビューを運用に組み込む 筆者の見解 MicrosoftのEUデータ境界への取り組みは、クラウドプロバイダーとして高く評価できる部分だ。「どこでデータを処理し、どこに保存するか」を明確に説明しようとする姿勢は、他のプロバイダーと比べても誠実だと思う。 ただ、今回のFlex Routingのロールアウトには、正直言って「もったいない」という感想が先に立つ。技術的な透明性は確保されている——それは認める。しかし「デフォルト有効」で展開するという判断は、EU/EFTAのコンプライアンス担当者にとって受け入れがたいものだろう。規制環境が厳しいリージョンだからこそ、初期値は「オフ」にして管理者が能動的に有効化する設計が筋だったはずだ。 Copilotの処理能力が本当にEU域内のGPUキャパシティを圧迫するほど使われているのかという点も、率直に疑問符がつく。もしCapacity問題が実態として深刻なら、その旨を数字と共に開示してほしい。そうすれば管理者も「やむを得ない仕組みだ」と納得しやすい。 MicrosoftはEUデータ境界を「信頼の基盤」として構築してきた。その信頼を守るためにも、今後の機能追加では「コンプライアンスリスクを管理者に転嫁しないデフォルト設定」を徹底してほしい。それだけの技術力と組織力があるプロバイダーなのだから、この部分でも正面から向き合えるはずだ。 4月17日まで時間はわずかしかない。EU/EFTAテナントの管理者は今週中に設定を確認しよう。 出典: この記事は Copilot Compliance Nightmare? Microsoft Suddenly Rolls Out Flex Routing の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか Microsoftが、Microsoft 365（M365）のCopilot Chat機能をWord・Excel・PowerPoint・OneNoteのアプリ内で利用できなくする方針を、2026年4月15日から施行すると大規模テナント向けに通知した。対象は2,000ユーザー以上の大企業で、これらの環境ではアプリ内Copilot利用に有料の「Microsoft 365 Copilot」ライセンス（月額30ドル/ユーザー）が必要になる。 2,000ユーザー未満の中小規模テナントは「削除」ではなく「制限」という形で、ピーク時に品質や応答速度が低下する「スタンダードアクセス」扱いへと格下げされる。いずれのケースでも、Copilot Chatは今後「Copilot Chat (Basic)」、有料ライセンス版は「M365 Copilot (Premium)」という名称で区別される。 これが「撤回」と呼ばれる理由 時系列を振り返ると、Microsoftは2025年9月にCopilot ChatをM365の無料付随機能として全ユーザーへ開放し、Word・Excel・PowerPoint・Outlook・OneNoteのサイドパネルに統合した。その意図は明確で、有料版の普及率がわずか約3%にとどまっている現状を打破するための「試用期間」だったと見られる。 ところが今回の方針変更により、その試用機会が事実上制限される。アナリストのJ.P. Gownder氏（Forrester）は「mystifying backtrack（謎の後退）」と表現しており、業界全体が困惑している。 なぜMicrosoftはこの決断をしたのか J. Gold Associates のアナリスト・Jack Gold氏は2つの理由を挙げている。 インフラコスト: 無料ユーザーに対してもアプリ内Copilot機能を提供し続けることには、相応のコンピューティングリソースが必要 収益最大化: 利用者が一定の「慣れ」を得た段階で、有料への誘導を強化するタイミングと判断した可能性 Microsoftの公式コメントは「エンタープライズグレードのAI機能は有料版で提供するものであることを明確にする変更」という建前だが、実態として企業の自然な試用フローに水を差す形になっている。 実務への影響 大規模テナントの管理者へ 4月15日が締め切り: 既存のCopilot Chat利用者がアプリ内での操作に依存している場合、業務フローへの影響を今すぐ洗い出すべき Outlookは継続利用可能: Word・Excel等は制限対象だが、Outlook内のCopilot Chatはこのタイミングでは引き続き無料で使える。メールの要約・返信補助はそのまま活用できる ライセンス見直しの好機: 全社一括導入ではなく、実際にCopilot利用頻度の高いユーザー層（管理職・分析担当者など）に絞って有料ライセンスを付与する段階的アプローチを検討する価値がある 中小規模テナントの管理者へ 削除ではなく「品質低下・通知表示あり」での継続提供なので、即座に業務が止まるわけではない ただし「品質低下通知」や「有料版誘導の通知」がユーザーに見える形で表示されることは覚悟しておく必要がある ユーザーからの問い合わせ対応を事前に準備しておくとよい 筆者の見解 正直なところ、この変更を手放しで歓迎する気にはなれない。 試用機会を積極的に提供してユーザーに体験させ、価値を実感した人に有料移行してもらう——これは本来、最も健全なSaaS普及戦略だ。Copilot Chatの無料統合はその文脈で理解できる判断だった。それを「3%しか有料移行しなかった」という結果を受けて早々に制限する方向に動くのは、正直もったいないと思う。 Microsoftには、M365という巨大なプラットフォームと何億人というユーザーベースがある。AIアシスタントとして正面から勝負できる条件は十分に揃っている。だからこそ、こういう局面では「どれだけ多くのユーザーに使ってもらうか」を優先してほしかった。価値を体感させずに有料誘導を強化しても、3%が5%になるかどうかすら怪しい。 一方で、現実的な視点も忘れてはならない。無制限の無料提供は持続可能ではないし、Microsoft 365はバラバラに使うのではなく統合プラットフォームとして全体最適を図るものだ。Outlookの議事録要約や定型メール、Teamsのチャット整理のような「毎日必ず発生する業務」に絞ってCopilotを活用し、さらに高度な分析や創造的作業には別途仕組みを整える——このハイブリッドな運用が、今の日本の企業にとって現実的な着地点になるだろう。 Copilotがいつか「これなしでは仕事できない」と言われる存在になることを、応援する立場から期待している。今回の変更が、長い目で見てその実現を早めるものであってほしい。 出典: この記事は Microsoft backtracks on Copilot Chat access in M365 apps – Computerworld の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が2026年3月9日に発表した「Microsoft 365 E7（The Frontier Suite）」。2015年のE5以来11年ぶりとなる新エンタープライズライセンスティアは、単なるバンドルの改訂ではない。その中核に据えられた「Agent 365」の登場は、組織内AIエージェントの管理という、これまで誰も解を持っていなかった課題に正面から向き合うものだ。 E7とは何か——バンドルの中身を整理する E7（$99/ユーザー/月、2026年5月1日GA）は以下4つのコンポーネントで構成される。 Microsoft 365 E5（既存の生産性・セキュリティ・コンプライアンス全機能） Microsoft 365 Copilot（OfficeアプリへのAIアシスタント統合） Agent 365（AIエージェント管理コントロールプレーン） Microsoft Entra Suite（フルスタックのID・ネットワークセキュリティ） 現在E5を利用している組織にとっては、Copilot・Agent 365・Entra Suite フルエディションの3点が実質的な追加となる。 Agent 365——これが今回の本命 E7の中で最も注目すべきはAgent 365だ。Copilot Studio・Power Apps・Microsoft 365 Copilotで作成・展開されたAIエージェントが組織内に乱立する時代に、IT部門やセキュリティチームはその実態を把握できているだろうか。 Agent 365はこの問いへの直接的な回答として設計されている。具体的には以下を提供する。 エージェントインベントリ: 組織内で動作する全AIエージェントの一覧と採用状況の可視化 セキュリティリスクシグナル: 各エージェントのリスクスコアと異常検知 エージェントID管理: Entra経由でのエージェントID発行・ライフサイクル管理 コンプライアンス制御: Purview連携による監査・データ保持ポリシーの適用 セキュリティポスチャ管理: Defender連携によるエージェント起点の脅威対策 Microsoftは「AIエージェントは人間の従業員と同様にライセンスと管理が必要だ」と明言している。この思想は重要だ。エージェントが組織の基幹システムにアクセスし、自律的に行動を取る以上、その管理を「野放し」にすることはセキュリティ上も、コンプライアンス上も許容できない。 Entra Suite強化——VPN代替とアイデンティティガバナンス E7のもう一つの実質的な追加がEntra Suite（E5はPlan 2止まり）への格上げだ。主な追加機能は5つ。 Entra Private Access: オンプレアプリ向けのZero Trust Network Access（ZTNA）。レガシーVPNをCondition Access + リアルタイムリスク評価で置き換える Entra Internet Access: Microsoft グローバルネットワーク経由のWebフィルタリング・セキュアWebゲートウェイ Entra ID Protection: ハイブリッド環境・オンプレAD向けの拡張リスク検知 Entra ID Governance: JML（入社・異動・退職）ライフサイクル自動化と過剰権限防止 Face Check with Verified ID: 高保証シナリオ向けの生体認証によるID検証 Entra Suiteは現在E5ユーザー向けに$12/ユーザー/月のアドオンとして提供されている。E7では包含済みとなる。 ...

2015年のMicrosoft 365 E5登場から約10年。Microsoftが初の新エンタープライズティア「Microsoft 365 E7（Frontier Suite）」を発表した。2026年5月1日に一般提供（GA）開始、価格は月額99ドル／ユーザー。E5の全機能にMicrosoft 365 Copilot・AIエージェント統合管理の「Agent 365」・Entra Suiteをパッケージした構成で、業界では「過去10年で最大のライセンス変更」と評されている。 E7は何を同梱しているのか E7の核心は3つの追加要素だ。 ① Microsoft 365 Copilot これまで単体で約30ドル/ユーザー/月で提供されてきたCopilotがE7に内包された。Word・Excel・Teams・Outlookなど主要アプリに生成AI機能を統合するもので、ライセンス体系のシンプル化という観点では一定の整理が進んだと見ることができる。 ② Agent 365——今回最大の注目点 AIエージェントを統合管理するためのプラットフォームとされており、企業内でAIエージェントを安全に運用・管理・監査するための基盤と位置付けられている。Copilot Studioの延長線上にある機能と見られるが、ガバナンス・監査ログ・ポリシー管理といった管理者目線の強化が期待される。詳細はGAに向けた発表で明らかになるが、エンタープライズにとってAIエージェントを「使う」フェーズから「管理する」フェーズへの移行を象徴する要素だ。 ③ Entra Suite 旧Azure ADを核に、Private Access（ゼロトラストネットワークアクセス）、Internet Access（セキュアウェブゲートウェイ）、External ID（外部IDガバナンス）などを含む包括的なIDセキュリティプラットフォーム。これがE7に同梱されることは、特にゼロトラスト移行の途上にある日本企業にとって注目に値する。 実務への影響——日本のIT管理者が今すぐ動くべきこと 「Copilot込みならお得」が成立するかの試算を E5の単価（約57ドル）にCopilotアドオン（30ドル）を加算すると87ドル前後。E7の99ドルとの差額は約12ドルだ。Entra SuiteやAgent 365に利用価値があると判断できれば、E7移行がトータルコストを最適化する計算になりうる。ただし「Copilotを使う予定がない」企業にとっては実質的な値上げとなる点は正直に見積もる必要がある。 確認すべき3つのポイント 現在のCopilotライセンス付与状況と月次コスト Entra Suiteを単独で別途購入している場合のコスト比較 Agent 365のガバナンス機能がIT部門の監査・ポリシー要件を満たすか（GAまでに情報収集を） 5月GAに向けて今が動き時 年度予算サイクルを考えると、5月のGAに合わせて移行を判断するためには4月中に内部合意が必要になる。Microsoft パートナー経由の価格交渉も早めに着手したい。特にソフトウェアアシュアランス（SA）の更新時期が近い企業は、E7への移行タイミングと照らし合わせて検討する価値がある。 筆者の見解 E7の発表が示しているのは、MicrosoftがAIを「選べるオプション」から「エンタープライズの標準インフラ」として位置付け直す意志だと読む。Agent 365というエージェント管理レイヤーを基盤に組み込んだことは、単なる機能追加ではない。企業内でのAIガバナンスを当たり前のものにしようという構想の具体化だ。 Copilotのバンドルについては率直に述べる。この数年間、CopilotがE7という形でエンタープライズの全ユーザーに届く環境を得たことは、むしろこれからが本番だと思っている。毎日使われる環境に組み込まれることでフィードバックが蓄積され、改善サイクルが回る。Microsoftが持つ膨大なユーザーベースとデータは、本来これ以上ない強みのはずだ。その実力が正面から発揮されることを期待したい。 一方、Entraを中心とするIDとセキュリティ基盤の統合は素直に評価できる。ゼロトラストの観点から、Just-In-Timeアクセス・ネットワーク制御・認証基盤を一枚のライセンスで揃えられる方向性は筋が通っている。日本の大企業に多い「旧来のセキュリティモデルと部分的なゼロトラストが混在している」状況から抜け出すための入口として、E7のEntra Suiteは検討に値する。 Microsoftが「AIでプラットフォームを再定義する」という意志を持ち、そのために10年ぶりのライセンス体系を刷新してきたことは間違いない。日本のIT部門にとっては、静観ではなく能動的に試算と検証を始めるタイミングだ。 出典: この記事は Introducing Microsoft 365 E7: The Frontier Suite の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月15日より、Word・Excel・PowerPoint・OneNote内に組み込まれていた無料のCopilot Chat機能を、一定規模以上の組織に対して利用不可とする。わずか6ヶ月前にリリースされた機能を、数週間という短い告知期間で撤回するという今回の決定は、多くの企業のIT担当者に混乱をもたらしている。 何が変わるのか Microsoftは今回の変更にあわせ、Copilot関連のブランド名も整理する。 Copilot Chat（無料版） → 「Copilot Chat (Basic)」に改称 Microsoft 365 Copilot（有料版） → 「M365 Copilot (Premium)」に改称 名称の整理自体はわかりやすくなるという面もあるが、実態は機能制限の強化だ。 組織規模によって異なる影響 従業員300名超の大規模組織（エンタープライズ） 4月15日以降、Microsoft 365 Copilotライセンスを持たないユーザーは、Word・Excel・PowerPoint・OneNote内のCopilot Chatが完全に利用不可になる。ただしOutlookのCopilot Chatは引き続き無料で使用できる。 従業員300名未満の中小規模組織（SMB） アクセスが完全に遮断されるわけではないが、ピーク時間帯には「スタンダードアクセス」、すなわち品質・パフォーマンスが低下した状態での提供となる。加えて、有料ライセンスへの誘導プロンプトが頻繁に表示されるようになる。 有料ライセンスのコスト感 組織規模 月額コスト（1ユーザーあたり） 300名超（エンタープライズ） $30 300名以下（SMB） $21 いずれも既存のMicrosoft 365サブスクリプション料金に追加で課金される。たとえば50名規模の会社では月額$1,050（約15万円以上）の追加コストが発生する計算だ。 なぜMicrosoftはこの決定をしたのか Copilot AIの基盤維持コストが高騰しているにもかかわらず、有料ライセンスへの移行率が期待を下回っていることが背景にある。加えて、Copilotがほかの生成AIサービスと比較して「最良の選択肢ではない」という市場の印象が広がりつつあるという事情も重なっている。株主からの短期的な収益改善圧力も無視できない要因だろう。 実務への影響——日本のIT担当者が今すぐやること 1. 自社の組織規模と契約状況の確認 300名の境界線がどちらに引かれるかで対応方針が変わる。Microsoft 365管理センターでライセンス割り当て状況を今すぐ確認しておこう。 2. 4月15日をカレンダーに入れてユーザーへの事前周知 「突然Copilotが使えなくなった」という問い合わせが殺到する前に、影響を受けるユーザーへ告知を。特にWord・Excelをヘビーに使っている部門は要注意だ。 3. コスト試算と経営層への説明 Copilot Premiumライセンスを全社展開するか、対象ユーザーを絞るか、あるいは代替手段を検討するか——判断を求められる場面が近い。1ユーザーあたりの月額と人数を掛け合わせた試算を早めに準備しておきたい。 4. Outlookのみ継続提供される点を活用 議事録の要約や定型メール作成など、Outlookで完結するユースケースはCopilot Chat (Basic)のまま継続利用できる。ワークフロー設計を見直すと無駄な追加コストを抑えられる可能性がある。 5. Microsoft 365 Copilot以外のAIアシスタントとの併用を検討 MicrosoftがAzure AI Foundryを通じて外部モデルへのアクセスを広げていることを活用し、高度な分析・文書生成タスクには別のAIを並べて使う「複線構成」も現実的な選択肢として視野に入れておくべきだ。 筆者の見解 今回の変更で最も気になるのは、機能そのものの廃止よりも「たった6ヶ月で方針転換した」という事実だ。 Copilot Chatをワークフローに組み込み始めていた組織にとって、数週間の告知期間での撤回は現場に混乱を招く。MicrosoftはCopilotを「Microsoft 365の核心機能」として位置づけてきたはずだ。その看板機能の提供ルールがこれほど短期間で変わることは、信頼の基盤を揺るがしかねない。 もちろん、AI基盤コストの高さとビジネスの持続性を両立させることは容易ではない。無料で広くばらまき、価値を感じてもらってから有料転換を狙うフリーミアムモデル自体は理にかなっている。だが、そのサイクルを半年で完結させようとするのは、ユーザー側の受容速度を無視した急ぎすぎだと感じる。 Microsoftには、企業向けサービスとして積み上げてきた信頼資産がある。その強みを活かせる立ち位置にいるのだから、短期的な収益圧力に引っ張られた機能の付け替えではなく、ユーザーが「これだけの価値があるなら払う」と納得できる体験の設計で勝負してほしい。 ...

Microsoft が Microsoft 365 Copilot の一環として提供する「Agents in Communities」が、2026年4月より世界展開を開始した。Teams のコミュニティ（Viva Engage を含む）に蓄積された過去の会話・SharePoint サイトの情報をAIが参照し、未回答の質問への返答案を自動生成する機能だ。単なるチャットボットとは一線を画す、「組織の集合知を活用するAIエージェント」という位置づけである。 Teams コミュニティ向けAIエージェントとは何か Agents in Communities は、Viva Engage 上のコミュニティをベースに動作する。これまで「質問を投稿したものの数日間返答がなかった」「同じような質問が何度も繰り返されていた」といった課題は、多くの企業の社内コミュニティが抱える慢性的な問題だった。 このエージェントは、過去の会話ログや関連 SharePoint ドキュメントを参照して、未回答の質問に対して「候補回答」を提示する仕組みを持つ。投稿者やコミュニティ管理者が候補回答を確認・承認することで情報が共有される形式のため、精度の担保と人間の監督が両立している。 同時に、今回の発表では複数のエージェントが正式提供または拡張された： Researcher エージェント: Copilot Chat 内で複雑な調査・情報統合を担当。一般提供済み Analyst エージェント: データを視覚化・洞察に変換。一般提供済み Facilitator エージェント: Teams 会議のノート取得・モデレートを自動化。一般提供済み Interpreter エージェント: Teams 会議での9言語リアルタイム通訳。一般提供済み Project Manager エージェント: Planner 上でのプロジェクト管理を自動化。パブリックプレビュー Agents in Channels: チャンネル専門のAIで過去会話・会議を参照してチームをサポート。パブリックプレビュー 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本企業の社内コミュニティ運用で最も多い悩みは「投稿しても反応がない」「せっかく蓄積した情報が検索されない」という2点に集約される。Agents in Communities はこの両方に対して、コンテンツを能動的に活用するアプローチで応答する。 明日から意識すべき活用ポイント： 既存の SharePoint サイトを整備する: エージェントが参照する情報源の品質が回答品質に直結する。まず社内 FAQ・手順書の整備から始めると費用対効果が高い コミュニティ管理者のワークフローを再設計する: 自動生成された候補回答の承認フローを誰が担うかを事前に定義しておかないと運用が回らない Viva Engage の利用状況を確認する: Agents in Communities は Viva Engage のコミュニティ基盤で動作する。Teams チャンネルと Viva Engage の使い分けを組織として整理する良い機会だ Copilot ライセンスの有無を確認する: これらのエージェントは Microsoft 365 Copilot のライセンスが必要なものが多い。パブリックプレビュー中は確認が必要 筆者の見解 この方向性は、正しい。Microsoft が持つ最大の強みは、Teams・SharePoint・Viva Engage・Planner という「仕事が流れる場所」をすべて統合しているプラットフォーム力だ。そこに蓄積されたデータをAIが活用するというアーキテクチャは、外部サービスでは構造的に再現しにくい。 ...

Microsoftが公開した最新の「Digital Defense Report」に、見過ごせない数字が載っている。IDへの攻撃の97%は、パスワードスプレーによるものだ。 高度な解析ツールや量子コンピューターではない。ごく単純な手法——多数のアカウントに対し、ありがちなパスワードを少しずつ試し続けるだけ——が、現代のほぼすべてのID侵害を引き起こしている。これは、多くの現場が信じている「複雑なパスワードルールを設定すれば守られる」という前提そのものへの反証だ。 パスワードスプレー攻撃とは何か パスワードスプレーは、ブルートフォース攻撃の進化系だ。従来型のブルートフォースは「1つのアカウントに大量のパスワードを試す」ため、アカウントロックアウトで検知・ブロックされやすかった。これに対しスプレー攻撃は発想を逆転させる。 「多数のアカウントに対し、1〜3種類だけパスワードを試す」 たとえば Welcome2024! や Spring2026@ のような「複雑性要件を満たしつつ誰もが思いつく」文字列を、数千〜数万のアカウントに1回ずつ試すだけだ。ロックアウトのしきい値に引っかからず、ログ上でも「散発的な認証失敗」に見えるため、従来の監視体制では素通りしてしまう。 LinkedInや過去のデータ侵害から入手した実在のユーザー名リストと、「よく使われるパスワードTOP100」を組み合わせるだけで成立する、参入障壁の低い攻撃手法でもある。 従来のADパスワードポリシーが機能しない理由 Active Directoryの既定のパスワードポリシーは、こうした攻撃を想定して設計されていない。最小文字数・複雑性要件・有効期限・パスワード履歴——これらはすべて「ブルートフォース対策」や「内部からの単純な推測」を念頭に置いた設計だ。 問題は何を守れないかにある。 既知の侵害パスワードのチェック機能がない: Password1! は複雑性を満たすが、すでに数百万件の侵害リストに存在する スプレーパターンの横断検知ができない: ADは「このアカウントが何回失敗したか」は見るが、「組織全体で同じパスワードが何アカウントに試されたか」は見ない コンテキスト（場所・デバイス・時間帯）を考慮しない: 深夜に海外IPからのアクセスでも、パスワードが正しければ通ってしまう つまり、複雑なルールを設けてもスプレー攻撃には無力という構造的な問題がある。 管理者が今すぐ導入すべき対策 1. Microsoft Entra Password Protection オンプレミスのADにも展開できるMicrosoftの仕組みで、Microsoftが管理するグローバルの禁止パスワードリストと、組織独自のカスタム禁止リストを組み合わせてパスワード設定時点でブロックできる。「複雑なのに侵害済み」というパスワードを排除する最初のラインだ。 2. MFA（多要素認証）の全員展開 パスワードが漏れた前提で考える。Microsoft Authenticatorのプッシュ通知 + 番号一致（Number Matching）を有効化すれば、正しいパスワードを持っていても突破できない壁になる。「管理者だけMFA」は今や論外で、全ユーザーが対象だ。 3. Conditional Access（条件付きアクセス）による文脈評価 IP・デバイス・場所・サインインリスクスコアを組み合わせてアクセスを制御する。Entra ID Protectionのリスクベースポリシーと組み合わせれば、スプレー攻撃で正しいパスワードを入力された瞬間に「高リスクサインイン」として検知し、MFAを強制または遮断できる。 4. 特権アカウントへのJust-In-Time（JIT）アクセス ドメイン管理者やグローバル管理者の権限を「常時付与」している組織はまだ多い。常時付与は特権アカウント管理における最大のリスクだ。Microsoft Entra Privileged Identity Management（PIM）を使えば、必要なときだけ、承認ベースで一時的に昇格できる仕組みを作れる。攻撃者がパスワードを入手しても、権限が無効化された状態であれば実害は大幅に限定される。 5. パスワードレス認証への移行 根本的な解決策はパスワードをなくすことだ。FIDO2セキュリティキーやWindows Hello for Businessは、パスワード自体が存在しないためスプレー攻撃の対象にならない。段階的に高リスクユーザー（管理者・リモート接続ユーザー）から展開を始めるのが現実的だ。 日本のIT現場への影響 日本の大企業・中堅企業のオンプレAD環境では、グループポリシーによるパスワードポリシーを「セキュリティ対策済みの証拠」として扱っている現場が今でも少なくない。Entra IDへのハイブリッド移行途上で、認証周りの設定が中途半端なまま止まっているケースも多い。 「今まで大きな事故がなかった」は、「今まで攻撃者に見つかっていなかっただけ」の可能性が高い。侵害の多くは侵入から数ヶ月後に発覚する。 筆者の見解 セキュリティ全般は決して得意分野とは言えないが、認証・認可の設計には技術的な面白さを強く感じる領域でもある。 今回の「97%がパスワードスプレー」という数字は、正直に言って驚きではない。洗練された攻撃より、「普通の人が使いそうなパスワードを片っ端から試す」だけで9割以上が決まってしまうというのは、むしろ現在のID管理のあり方への問いかけだ。 MicrosoftはEntra IDにパスワードスプレー対策のための技術を揃えている。Password Protection、Entra ID Protection、Conditional Access、PIM——これらは単体ではなく組み合わせて使って初めて意味を持つ。M365やEntra IDを使いながら、パスワードポリシーだけ昔のままという状態は、道具を持っているのに使っていないのと同じだ。 ...

Microsoft 365 Copilotが2026年3月9日に発表した「Wave 3」は、Copilot史上最大規模のアップデートだ。単なる機能追加ではなく、AIが人間の代わりに業務フロー全体を自律的に実行する「デジタル労働力」への転換を宣言する内容である。日本の企業IT担当者にとっても、今すぐ評価と準備に着手すべき変化が詰まっている。 Wave 3の4本柱を整理する Wave 3の核心は以下の4つだ。 Copilot Cowork ── 自律型マルチステップ実行 Coworkは、ユーザーが指示を出したあとにCopilotがバックグラウンドで複数ステップの業務を自律的に進める機能だ。メール・ドキュメント・Teams・カレンダーにまたがる複合タスクを、人間が画面に張り付かなくても完遂する。プロジェクト報告書の下書き作成から関係者への送付スケジュール設定まで、従来は人間が1ステップずつ手動でつないでいた作業が一括委任できるようになる。 Agent 365 ── エージェント管理・ガバナンス基盤 Agent 365は、企業内で動くAIエージェントを一元的に管理・監視・制御するコントロールプレーンだ。どのエージェントが何のデータにアクセスできるか、どのワークフローを実行しているかをIT管理者が可視化・制御できる。Copilotエージェントが組織内に増えるにつれ、このガバナンス基盤の重要性は増す一方だ。 Model Choice ── マルチモデル対応 Wave 3では複数のAIモデルをCopilot基盤上で利用できるようになる。タスクの性質に応じてモデルが自動選択される仕組みで、IT管理者がモデルを意識せずに済む設計になっている。Microsoft 365のデータ保護ポリシーのもとで動作するため、セキュリティ面の責任境界は引き続きMicrosoftが担保する。 Microsoft 365 E7 ── $99/user/monthの新ライセンス E5＋Copilot＋Agent 365をまとめたフロンティアスイートとして「E7」が登場する。個別に積み上げるより割安になる設計で、企業が一括で最上位機能を導入しやすくなる。 展開ロードマップ：2026年前半に集中 今〜4月：現行環境のアセスメント。どの業務フローがCoworkの対象になるか整理 4〜5月：ガバナンスポリシー策定。Agent 365の管理ルール設計 5〜6月：パイロット展開。限定部門でCoworkとAgent 365を試験稼働 7月以降：全社スケールアウト 実務への影響：日本のIT管理者が今すぐやるべきこと 1. データ分類ポリシーの見直しが最優先 Coworkが自律的に動くということは、AIが自社データに能動的にアクセスしながら業務を進めることを意味する。現行のMicrosoft Purviewのデータ分類・ラベリングが不十分な組織では、意図しない範囲のデータがエージェントに渡るリスクがある。Wave 3導入前に、情報保護ラベルの適用状況を棚卸しすることを強くすすめる。 2. Agent 365の管理者ロール設計 「誰がどのエージェントを作れるか」「エージェントがアクセスできるサービスはどこまでか」を設計しないまま展開すると、シャドーITならぬ「シャドーエージェント」が組織内に増殖する。管理者ポリシーは展開前に確定させること。 3. E7ライセンスの費用対効果を試算する E3またはE5＋Copilot Add-onの現行構成からE7への移行コストを試算するタイミングだ。特にCopilotとAgent 365の両方を使う予定があるなら、E7の方がトータルコストで有利になる可能性が高い。Microsoft担当営業に今から試算を依頼しておくと良い。 4. エンドユーザートレーニングの再設計 「アシスタントとして使う」から「エージェントに委任する」へのUXは別物だ。何をどこまで任せていいかの判断基準、結果の確認フロー、承認が必要なタスクの分類など、現場ユーザーへの教育内容をゼロから組み直す必要がある。 筆者の見解 Wave 3を一言で表すなら「Copilotが本気を出してきた」という印象だ。Coworkもマルチモデル対応も、エンタープライズ向けに真面目に設計された機能だと感じる。E7のバンドル戦略も、統合プラットフォームとして全体最適を狙うMicrosoftらしいアプローチだ。 ただし、正直に言う。「今度こそ本物か」という問いに確信を持って答えるには、まだ実動環境での検証が必要だ。発表内容は申し分ない。しかし日本の現場で実際に使えるレベルになるまでのギャップ──日本語精度・コンプライアンス対応・ローカライズの遅れ──を何度か経験してきた身としては、慎重に見極める姿勢を崩せない。 一方で、ガバナンス基盤（Agent 365）を最初からセットで出してきた点は評価したい。エージェントAIが普及する上で最大の障壁は「どこまで信頼して任せていいか分からない」という組織側の不安だ。管理・可視化の仕組みを最初から提供するのは、正しい順序だと思う。 Wave 3は、CopilotをPoC止まりにしていた組織が「本格導入」に踏み出す契機になり得る。ただしその前に、データ分類とガバナンス設計という地味だが重要な土台固めを怠らないことが前提条件だ。Microsoftにはこのまま、エンタープライズとして信頼できるAIプラットフォームの道を歩み続けてほしいと思っている。 出典: この記事は Microsoft 365 Copilot Wave 3: The Complete Enterprise Guide for 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotを導入している企業にとって、長らく課題だった「Copilotがどこから情報を拾っているか分からない」問題に、ついてMicrosoftが本格的なメスを入れる。SharePointに「AI Citation Analytics（AI引用アナリティクス）」と「Authoritative Sources（権威コンテンツ指定）」という2つの新機能が4月よりロールアウトされる。 AI引用アナリティクス：Copilotが「何を引用したか」がわかる AI Citation Analyticsは、SharePoint上のコンテンツがCopilotによってどの程度引用されているかを可視化する機能だ。SharePoint管理センターから確認できるようになると見られており、「このドキュメントはCopilotの回答に何回使われたか」「このサイトのどのページがよく参照されているか」といったデータが得られる。 これは単純な閲覧数やダウンロード数とは根本的に異なる指標だ。Copilotに「参照された」ということは、その文書が社内の問い合わせに実際に答える情報として機能しているという証拠になる。コンテンツ品質の評価軸が「人が読んだ回数」から「AIが回答に使った回数」へと拡張されることで、情報管理の考え方そのものが変わってくる。 Authoritative Sources：信頼できる情報源を管理者が指定する 「Authoritative Sources」は、SharePoint Onlineの特定サイトをCopilot検索における権威ある情報源として管理者が明示的に指定できる機能だ。ウェブ検索エンジンにおける「信頼性の高いサイトを優先表示する」ロジックを、社内ナレッジ管理に持ち込んだイメージに近い。 指定されたサイトのコンテンツは、Copilotの検索・回答生成において優先的に参照される。例えば、人事部が管理する就業規則のサイト、情報システム部門のセキュリティポリシー集、プロジェクト管理部門の標準手順書などを「権威ある情報源」として指定することで、Copilotの回答の根拠がコントロールしやすくなる。 実務への影響 SharePointのコンテンツ整備が「Copilot品質の投資」になる これまで「SharePointの整備は手間がかかる割に使われない」という声は多かった。しかし、AI引用アナリティクスで「どのコンテンツが実際にCopilotに使われているか」が見えるようになると、整備の優先順位付けが論理的にできるようになる。引用されている文書を最新化することは、そのままCopilotの回答精度向上に直結する。SharePoint管理が「お作法」から「AI品質への投資」へと位置づけが変わる転換点になり得る。 誤情報・古い情報を引用させない「ネガティブコントロール」の重要性 Authoritative Sourcesで「良いコンテンツを優先する」一方で、古い情報や廃止されたポリシー文書が引き続きCopilotに引用されるリスクも存在する。権威ある情報源を指定するだけでなく、「引用させたくないコンテンツ」をどう管理するか—削除・アーカイブ・アクセス制限—の運用ポリシーも同時に整備することが重要だ。 情報ガバナンス担当者のロールが変わる 「SharePoint管理者」という職種の役割が、単なるサイト管理・権限設定からAIの「回答品質管理」へと広がりつつある。特に法務・コンプライアンス関連の文書は、Copilotに誤った根拠として引用されるリスクが高い。Authoritative Sourcesと組み合わせた情報ガバナンスの再設計を、今から検討しておくことを強くすすめる。 筆者の見解 この機能は、Copilotの実用性という観点で評価できる、まっとうな方向性だと思っている。Copilotをせっかく導入しても「どこから引っ張ってきたか分からない回答」が返ってくる状況では、現場の信頼が得られない。管理者がコンテンツの質と引用状況を把握できるようになることは、「管理できるシステムとしてのCopilot」という方向性の第一歩だ。 ただ、正直に言えばもったいないという気持ちが拭えない。この機能自体は正しいが、「なぜ今なのか」という問いが残る。Copilot for Microsoft 365が登場してから長い時間が経っているにもかかわらず、こうした基本的なコンテンツガバナンス機能が今ようやく実装されてきている。実務で導入を推進してきたIT管理者が、どれだけ「どのコンテンツが使われているか分からない」という不安と戦ってきたか。Microsoftにはその経験値を受け止めた上で、さらに踏み込んだ管理機能を早期に届けてほしい。 SharePointという資産を持つ企業にとって、この機能は活用する価値が十分ある。内部ナレッジの整備に力を入れてきた組織ほど、Copilotの回答品質向上という形でリターンが返ってくる仕組みが整いつつある。社内コンテンツを真剣にマネジメントしている担当者は、まずAuthoritative Sourcesで「信頼できるサイト」を洗い出すところから始めるのが現実的な一手だ。 出典: この記事は SharePoint AI Citation Analytics and Authoritative Sources for Copilot Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilot Researcherに「Critique Mode（批評モード）」が追加された。AIが自身の調査結果を自己評価・改善するこの機能は、エンタープライズ向けリサーチワークフローに実質的な価値をもたらす可能性を持つ。一見地味なアップデートだが、その意味合いは小さくない。 Critique Modeとは何か Critique Modeは、Copilot Researcherが生成したリサーチ結果に対して「自分自身で批評・検証し、出力を改善する」プロセスを組み込んだ機能だ。 従来のAIリサーチツールは、一度生成した結果をそのまま出力するパターンが多かった。しかしCritique Modeでは、生成後に自己評価のループを設けることで、内容の網羅性・一貫性・根拠の強さを内部でチェックしてから最終出力を返す設計になっている。 これはAI分野で「Self-Critique」または「Reflection」と呼ばれる手法の応用だ。単純な一回生成より精度が上がることは多くの研究で示されており、Microsoftがこのアプローチをエンタープライズ製品に正式統合したことは技術的な進歩として評価できる。 エンタープライズ利用での具体的な変化 リサーチ業務における典型的な課題は「AIが自信満々に不完全な情報を返す」点だ。特に複数の情報源を統合するような複雑な調査では、論点の抜け漏れや根拠の薄い結論が混入しやすい。 Critique Modeはこの問題にアプローチする。市場調査、競合分析、技術評価レポートなど、深い洞察が求められる業務においてアウトプットの品質底上げが期待できる。 実務への影響 日本のエンタープライズ環境でM365 Copilotを活用している組織にとって、実務上の活用ポイントをいくつか挙げておきたい。 活用が期待できるシナリオ 経営層向けの市場動向・競合環境レポート作成 新技術・製品の比較調査と採用判断の補助 規制・コンプライアンス要件の調査整理 運用上の注意点 Critique Modeが有効でも、最終的な検証は人間が担う必要がある。自己評価ループはあくまで品質向上の補助であり、ファクトチェックの代替ではない。また、データソースの品質に依存することは変わらないため、社内ナレッジとの連携設定が実運用の肝になる。 ライセンス面では、Copilot機能はMicrosoft 365 E3/E5に対してアドオンとして追加する形態が多い。既存のMicrosoft 365環境を持つ組織はライセンス構成を確認した上で活用計画を立てると良いだろう。 筆者の見解 Critique Modeの追加は、Copilotの進化方向として「正しい一手」だと率直に思う。 以前からCopilotのリサーチ機能には「もう一段階踏み込んでほしい」という声が多かった。一次情報を収集してまとめるだけであれば、他の選択肢でも十分実現できる。エンタープライズが本当に求めているのは、情報の取捨選択と論理的な精査を伴った「考えるリサーチ」だ。Critique Modeはその方向への一歩として評価できる。 Microsoftはエンタープライズ向けに必要なセキュリティ・コンプライアンス・他サービスとの統合性という、競合がそう簡単には追いつけない基盤を持っている。その強みの上でAIの精度と信頼性を積み上げていく戦略は、本来の持ち味に合致している。正面から勝負できる力があるのだから、そこに集中していってほしいと思う。 もちろん、一機能の追加で全てが変わるわけではない。「これなら信頼できる」と現場が感じる体験が積み重なることこそが、真の価値証明だ。今後のアップデートを引き続き注目して追いかけたい。 出典: この記事は Microsoft Upgrades 365 Copilot Researcher With New Critique Mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「2026 Release Wave 1」（2026年4〜9月）の全容を公開した。Dynamics 365（D365）・Power Platform・Microsoft 365（M365）Copilotの3系統にわたり、エージェント型AI機能を一斉展開するという大規模なアップデートだ。単なる機能追加ではなく、AIが人間の代わりに複数ステップの業務を自律的に実行するという方向性を明確に打ち出している点で、今回のリリースウェーブは注目に値する。 何が変わるのか——エージェントAIとは 今回のキーワードは「Agentic AI（エージェント型AI）」だ。これまでのCopilotが「質問に答えるAI」だとすれば、エージェント型AIは「目標を与えると、必要な手順を自分で組み立てて実行するAI」に相当する。 具体的には、以下のような変化が期待される。 D365 Sales / Customer Service: 顧客データの参照・要約・メール下書き・次のアクション提案を、担当者が指示を出すたびにではなく、AIが流れで処理する Power Platform（Power Automate / Copilot Studio）: 自然言語でフローを指示すると、AIが複数のコネクタをまたいだ処理を自動設計・実行する M365 Copilot（Teams / Outlook / Word）: 会議の録画から議事録を作成し、TODO項目をPlannerに登録し、関係者にメールを送信する——といった一連の流れをひとつの指示で完結させる GPT-5系モデルがCopilot Studioでも利用可能に 注目すべき技術的変化として、GPT-5.4 Thinking（複雑な推論・多段階タスク向け）とGPT-5.3 Instant（低レイテンシ・高頻度処理向け）の2つのモデルが、Copilot Studioでも選択できるようになる。 これは実務的に大きな意味を持つ。これまでCopilot Studioでカスタムエージェントを構築する際、モデルの選択肢は限られていた。GPT-5系が使えるようになることで、自社業務に特化したエージェントをより高い推論能力で動かせるようになる。特に規則が複雑な業種（会計・法務・製造の品質管理など）では、推論精度の向上は直接的に業務品質に影響する。 日本のIT現場への影響 この動きが日本のエンジニア・IT管理者にとって具体的に何を意味するか、整理しておきたい。 ▶ Power Platformユーザーへの影響 Power AutomateやPower Appsをすでに使っている組織は、今回の波に乗りやすい。Copilot Studioのエージェント機能は、既存のM365ライセンスの上位プランから段階的に展開される見込みだ。まずは自社の繰り返し業務のうち「5ステップ以上の判断を含むもの」をリストアップし、エージェント化の候補として検討しておくと良い。 ▶ D365導入済み企業の管理者へ D365側の強化は、特にカスタマーサービスと営業支援で顕著だ。Wave 1では、Copilotエージェントが顧客の過去履歴・契約情報・過去のサポートチケットを横断して回答を生成する機能が本格稼働する。現在、担当者が複数画面を手動で確認している作業がどの程度あるか——そのリストが、そのまま自動化のロードマップになる。 ▶ ライセンス管理・コスト設計の見直し エージェント機能はメッセージ消費量（Message Credits）やAPIコール数で課金されるモデルになる可能性が高い。「使えば使うほど課金が増える」構造に備えて、用途ごとに使うモデルや処理量の上限を設計しておくことが管理者の重要な仕事になる。 筆者の見解 今回の発表を見て率直に思うのは、「Microsoftはやっぱりプラットフォームとしての底力がある」ということだ。D365・Power Platform・M365という3つの巨大なビジネスアプリ群を横断して、同じエージェントAIのアーキテクチャで統一的に動かそうとしている。これは、単一製品では到底できないスケールの話だ。 GPT-5系モデルをCopilot Studioで使えるようにする動きも、開発者コミュニティへのメッセージとして受け取っている。「Foundry（Azure AI Foundry）経由で自前のエージェントを作りたい開発者」と「GUIでエージェントを組みたいビジネスユーザー」を、両方取り込もうという意図が透けて見える。この二段構えの設計は、正しい方向だと思う。 ただ、正直に言うと、過去数年のCopilotに関しては「この力があるのだから、もっとやれるはず」という気持ちが強くある。Wave 1で発表された機能が実際にリリース時点で品質水準に達しているかどうか——そこが今回の真価を問う部分だ。技術力に疑いはない。問題はいつも「使い物になるかどうか」のラストワンマイルだった。 今回のリリースウェーブには本物の期待をしている。日本のIT現場でも、繰り返し業務を抱えたチームにとって、エージェントAIは「ようやく実用フェーズに入った」と感じられるアップデートになりうる。Microsoftがその期待に正面から応えてくれることを、心から願っている。 出典: この記事は Microsoft Unveils Agentic AI Push Across D365, Power Platform and M365 Copilot in 2026 Release Wave 1 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 の「長年の積み残し」が、いよいよ清算される。2026年4月2日を境に、SharePoint Online のレガシーコンプライアンス機能が一斉に廃止される。「まだ動いているから大丈夫」と先送りしてきた組織にとって、猶予は実質的に尽きた。 何が廃止されるのか 今回の廃止対象は、SharePoint の「旧世代の仕組み」が集中している領域だ。 コンプライアンス・レコード管理の旧機能（4月中） 情報管理ポリシー（Information Management Policies） インプレースレコード管理（In-Place Records Management） 削除専用ポリシー これらは UI からもアクセス不可になり、API 経由での呼び出しも動作しなくなる。移行先は Microsoft Purview の「データライフサイクル管理」および「Purview レコード管理」だ。 SharePoint 2013 ワークフロー（4月2日） かつてはほぼすべての承認フローで使われていたこの仕組みが、延長なしで完全終了する。移行先は Power Automate。複雑なフローを抱えている場合は、設計の見直しも含めた対応が求められる。 SharePoint アドイン（4月2日） 既存テナントでも動作停止となる。Microsoft 365 Assessment ツールでアドインの使用状況をスキャンし、SharePoint Framework (SPFx) への移行、またはベンダーへの対応依頼が必要だ。 Azure ACS（Access Control Service）の M365 サポート終了（4月2日） カスタムアプリや外部アプリが Azure ACS を使って SharePoint Online に接続している場合、4月2日以降は動作しなくなる。移行先は Microsoft Entra ID。特にサードパーティ製品が絡む場合は、ベンダー側の対応も確認が必要だ。 SPFx のドメイン分離 Web パーツ（4月2日） 特定のセキュリティ要件を持つ組織が使っていたこの機能も廃止。既存の Web パーツはエラーを返すようになるため、通常の Web パーツへの変換と再デプロイが必要だ。 実務への影響——日本のエンジニア・IT管理者が今すぐやること ステップ 1: 使用状況の棚卸し Microsoft 365 Assessment ツールを実行して、Azure ACS やアドインの利用状況を確認する。このツールは無料で使えるため、まず現状を把握することが優先だ。 ...

Microsoft 365 Copilotの管理機能に、待望のアップデートが届く。2026年4月下旬より、IT管理者はサードパーティAIモデルプロバイダーへのアクセスをテナント全体ではなくEntra IDグループ・ユーザー単位で制御できるようになる。AnthropicやxAIといった外部AIとCopilotを組み合わせて使っている組織、あるいは今後の導入を検討している組織にとって、ガバナンス設計の幅が一気に広がる変更だ。 何が変わるのか これまでの管理コンソールでは、サードパーティモデルプロバイダーの有効/無効はテナント全体での一括切り替えのみだった。つまり、一部の部門・一部のパワーユーザーにだけ外部AIを開放するといった使い分けは仕組み上できなかった。 今回のRoadmap ID 557371で追加されるのは、Microsoft Admin CenterにおけるEntra IDグループ/ユーザーへのプロバイダー割り当て機能だ。主な仕様は以下のとおり。 設定粒度: プロバイダー単位（個別モデルではなくプロバイダーごと） 最大割り当て数: グループ＋ユーザーの組み合わせで最大999まで。ネストされたグループにも対応 適用範囲: Microsoft Admin Center・Power Platform Admin Center（PPAC）・Copilot Studioで設定が一貫して反映される 対象: サブプロセッサーおよびインディペンデントプロセッサーの両方を含む現在・将来のすべてのサードパーティプロバイダー なお本機能は、AnthropicモデルをCopilot体験の一部でデフォルト有効化したMC1193920と連動している。テナント全体で自動有効化されるリスクを懸念していた管理者は、グループ単位で「見えている人だけに開放する」という運用をとれるようになる。 日本の現場への影響 日本企業の多くはMicrosoft 365を中核に据えながら、一方でAI活用の高度化に向けて「Copilot以外の選択肢」を模索している段階だ。この管理機能の登場が現場に与えるインパクトは大きく二つある。 ① 段階的な展開が現実的になる 全社一斉展開ではなく、まずAIリテラシーの高いチームや先行ユーザー数十名だけに外部モデルへのアクセスを開放する——そんなパイロット運用がEntraグループ一つで完結するようになる。変更管理コストが下がり、社内調整がしやすくなる。 ② ガバナンスとコンプライアンスの両立 データ保護の観点から「外部AIとのデータ連携に慎重でなければならない」という組織も多い。今回の変更でサードパーティモデルへのアクセスをEntraの条件付きアクセスポリシーと組み合わせて制御できる道が開ける。情報システム部門が「誰が何を使っているか」を可視化・統制しやすくなる点は、セキュリティポリシーを厳格に運用しているエンタープライズにとって歓迎材料だ。 実務での活用ポイント 4月下旬のロールアウトに備えて、今から準備できることがある。 既存設定の棚卸し: Microsoft Admin Centerで現在のAnthropic・xAI（米国のみ）の有効/無効状態を確認する グループ設計: Entraの既存グループをそのまま使えるか、外部AI利用用の新グループを切るかを設計しておく 影響範囲の特定: 既存のCopilot StudioエージェントやPower Automateフローが外部モデルに依存している場合、アクセス制限によって動作が変わる可能性があるため事前に確認する ヘルプデスクへの共有: アクセス範囲が変わることでエンドユーザーから問い合わせが来る可能性がある。事前に社内周知とサポートシナリオの準備を 筆者の見解 CopilotとサードパーティAIの「併用」は、もはや一部の技術好きだけの話ではなく、多くの組織が現実解として検討しているアプローチだ。Teamsの議事録やOutlookの定型業務はCopilotに任せながら、高度な分析や創造的なタスクには外部AIを活用する——こうした使い分けを組織ポリシーとして制御できる仕組みが整うのは、現場にとって素直にありがたい進化だと思う。 ひとつ注文をつけるとすれば、「プロバイダー単位」の制御に留まっている点だ。同一プロバイダーのモデル間でアクセスレベルを変えたい、というニーズは必ず出てくる。今後のロードマップでモデル単位への粒度の細分化を期待したい。 それ以上に重要なのは、こうした管理機能の整備とCopilot本体の実力向上を、Microsoftが同時並行で進めてほしいという点だ。ガバナンス基盤が整っても、主役のCopilot自体がより使いたいと思えるものになっていかなければ、管理の仕組みだけが空回りする。Microsoftには、この仕組みの拡充と並走するかたちで、Copilot本体のエクスペリエンスを磨き続けてほしい。M365というプラットフォームが持つポテンシャルは、本来それだけの期待に十分応えられるはずだから。 出典: この記事は Microsoft 365 Copilot: Admins will be able to enable third-party model providers for specific users and groups の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...