M365

多要素認証（MFA）を導入しているから安心、という認識が今まさに崩されようとしている。「EvilTokens」と名付けられた新型フィッシングキットは、MicrosoftのデバイスコードAuthentication Flowという正規の認証メカニズムそのものを武器に変え、AIと自動化を組み合わせて大規模な標的型攻撃を可能にしている。MFAを入れた企業が「対策済み」と油断するなかで、静かに侵害が広がっている点が最も深刻だ。 デバイスコード認証の仕組みと悪用の構造 Microsoftのデバイスコードフロー（Device Authorization Grant）は、ブラウザやキーボードを持たないデバイス——スマートTVやIoT機器、プリンター等——向けに設計された認証方式だ。ユーザーは別のデバイスから microsoft.com/devicelogin にアクセスし、表示されたコードを入力することで認証を完了させる。 EvilTokensはこの仕組みを逆手に取る。攻撃者があらかじめデバイスコードを生成し、それをフィッシングメールやTeamsメッセージなどに埋め込んで標的に送りつける。被害者が「正規のサインインページ」だと思ってコードを入力した瞬間、攻撃者側のセッションに有効なアクセストークンとリフレッシュトークンが払い出される。 ここが重要なポイントだ。 被害者は自分のパスワードとMFAを正しく使って認証を完了している。だからこそMFAが役に立たない。払い出されたトークンは長期有効であることも多く、攻撃者はパスワードを知らなくても長期間にわたって企業メールや各種M365サービスに侵入し続けられる。 さらにEvilTokensはAIによるフィッシング文面の自動生成と、攻撃フロー全体の自動化を組み込んでいる。従来の手動攻撃より大幅にスケールアップが可能で、一人の攻撃者が多数の標的を同時並行で狙える構造になっている。 狙われる情報と被害のシナリオ 主たる標的はExchange Online上の企業メールアカウントだ。侵害に成功した後、攻撃者は受信トレイを監視し、財務情報や契約書、社内決裁フローなどを収集する。BEC（ビジネスメール詐欺）への転用や、他社への横展開も容易に行える。 日本企業においても、M365を全社展開しているケースは珍しくなく、Teamsを業務連絡の主軸に置く組織ではフィッシングメッセージが社内連絡に見せかけて届くリスクがある。 実務での対策ポイント 1. デバイスコードフローを条件付きアクセスでブロックする 最も直接的な対策は、必要のない場面でデバイスコードフローそのものを無効化することだ。Microsoft Entra IDの条件付きアクセスポリシーで、デバイスコードフローを使用できる対象を管理デバイスや特定のIPレンジに限定する、もしくは原則ブロックする設定を適用する。多くの一般従業員にとって、このフローを使う正当な理由はほぼない。 2. 継続的アクセス評価（CAE）とトークン有効期間の見直し アクセストークンのデフォルト有効期間を短縮し、Continuous Access Evaluation（CAE）を有効にする。これにより、不審なセッション変化を検出した際にトークンをリアルタイムで失効させられる。 3. Microsoft Defender for Cloud Apps（MCAS）でトークン利用を監視 異常な地域からのトークン利用や、短時間での大量メール参照などの行動を検出するルールを設定しておく。侵害されていても早期に検知できる体制が欠かせない。 4. 社員教育でデバイスコードフィッシングを周知する 「MFAをきちんと使ったのに侵害された」という事例を共有し、「見覚えのないページにコードを入力しない」という習慣を根付かせる。ITリテラシー研修にこのシナリオを追加することを強く推奨する。 筆者の見解 セキュリティの話題は細かい議論になりがちで、正直あまり得意なジャンルではない——とはいえ、このトピックには技術的に強い関心を持っている。 EvilTokensが突いているのは、Microsoftが「利便性のために設計した正規機能」だ。悪意あるコードが混入したわけでも、脆弱性を突かれたわけでもない。ゼロトラストの観点からすれば、これは「デフォルトで過剰な信頼を与えてしまっているフロー」の問題に他ならない。必要な人だけが、必要なときだけ使える——そのJust-In-Timeの思想が徹底されていれば、攻撃面を大幅に削れる。 MicrosoftはEntra IDに条件付きアクセスやCAEといった強力な制御手段を持っている。問題は、それらの設定が「やろうと思えばできる」状態に留まっていて、多くの組織でデフォルトのまま放置されている点だ。「今動いているから大丈夫」という空気がある限り、こうした攻撃は静かに成功し続ける。 Microsoftにはゼロトラストの理念をより積極的に「デフォルト設定」へ組み込んでいってほしい。設定しなければセキュアにならないのではなく、設定しなくてもある程度セキュアである——そのベースラインを引き上げる力は、Microsoftには十分にあるはずだ。 出典: この記事は EvilTokens Phishing Kit Uses Microsoft Device Codes to Bypass MFA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

M365 Community Conference 2026（4月下旬開催）の直前、SharePointチームが「AI引用の可視化と制御」に関わる新機能群を4月中にロールアウトすると発表した。Copilotが何を根拠に回答しているか見えづらかった状況に、ようやく管理者が踏み込める仕組みが整いつつある。 4月ロールアウト予定の3つの新機能 1. AI引用ランキング表示 SharePointサイト上で、Copilotが実際にどのページを「回答の根拠」として引用しているかをランキング形式で確認できるようになる。これまで、どの社内ドキュメントが使われているかは管理者にとってほぼブラックボックスだった。この機能で「頻繁に引用される高品質コンテンツ」と「引用されていないコンテンツ」が一目でわかるようになる。 2. サイト利用統計へのAI引用メトリクス追加 SharePointのサイト分析ダッシュボードに「Copilotに何回引用されたか」という新指標が加わる。従来のページビューやユニークユーザー数に並ぶ形で、AIの文脈でのコンテンツ価値が計測できるようになる。 3. Copilot検索の権威ソース（Authoritative Source）管理機能 3つの中でもっとも実務インパクトが大きい機能だ。管理者が「この種の質問にはこのSharePointサイトを優先して参照せよ」と明示的に設定できるようになる。Copilotの回答精度を、組織の意図として制御できる仕組みだ。 なぜこれが重要か Copilotを導入した多くの組織が「回答の品質にばらつきがある」「どこから引っ張ってきた情報なのかわからない」という課題を抱えてきた。その根本原因の一つは、SharePointに蓄積されたコンテンツの品質や信頼性にばらつきがあるにもかかわらず、Copilotがそれを区別できていなかった点にある。 権威ソース管理機能は、この問題に組織的に対処するための仕組みだ。「Copilotを野放しにするのではなく、組織が責任を持ってナレッジを管理する」というアプローチは、コンプライアンス要件が厳しい日本のエンタープライズにとっても重要な考え方になる。 またAI引用メトリクスは、コンテンツガバナンスに新しい評価軸をもたらす。「人が読んでいるか」だけでなく「AIが引用しているか」が文書の価値指標に加わることで、ナレッジマネジメント全体の設計が変わってくる。 実務への影響——日本のIT担当者が今すぐやるべきこと SharePoint管理者・情報システム担当者向け: 権威ソースの棚卸しを先に: 権威ソース管理機能を活用するには「どのサイトが公式情報源か」を組織で整理しておく必要がある。機能ロールアウト前に、古くなったコンテンツや重複情報の整理を進めておきたい AI引用ランキングを品質改善の起点に: 引用されているページの特徴（見出し構造・更新頻度・情報の正確性）を分析することで、「Copilotに正確に使ってもらえるコンテンツ」の書き方が見えてくる AI引用数をコンテンツKPIに加える検討を: 社内ポータルや部門Wikiの品質向上活動において、AI引用数を評価指標の一つとして組み込むことを検討する価値がある コンテンツ作成者向け: Copilotに「信頼できるソース」として認識されるには、情報の鮮度・正確性・構造化が重要だ。定期的なコンテンツレビューを習慣化し、陳腐化した情報を積極的に更新する体制を今から整えておくと、この機能が最大限に機能する。 筆者の見解 正直に言えば、「あって当然の機能がようやく来た」という印象は否めない。Copilotが何を参照しているか見えない状態でロールアウトを続けてきたことを考えると、管理者がブラックボックス感を抱えたのも無理はなかった。 とはいえ、今回のアップデートの方向性は評価したい。「Copilotの精度を組織側のガバナンスで高めていける」という設計思想は、これまでの「おまかせ」スタイルからの大きな転換だ。特に権威ソース管理機能は、真剣に活用すれば回答品質を劇的に改善できるポテンシャルを持っている。 SharePointは長年、組織の知識インフラとして地道に進化を続けてきた。ナレッジ管理に真剣に取り組んできた組織ほど、これらの機能のメリットを享受できる構造になっている。「ちゃんと使いこなしてきた組織が報われる」時代がようやく来るかもしれない——そう感じさせてくれるアップデートだ。 M365 Community Conference 2026の場でさらなる詳細が明らかになることを期待している。SharePointへの地道な投資が、AI時代に花開く局面が来ることを願いたい。 出典: この記事は Your Frontier Transformation Starts at the Door with SharePoint at M365 Community Conference 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 CopilotにPurview DLP（データ損失防止）ポリシーの直接適用と、新しい利用分析機能が追加された。組織がAI駆動のワークフロー全体を可視化・統制できるこの機能強化は、エンタープライズ展開を本気で考えるなら見逃せないアップデートだ。 Purview DLPがCopilotの出力に直接介入できるようになった 今回の目玉は、Microsoft PurviewのDLPポリシーがCopilotの出力フェーズに直接作用するようになった点だ。 従来、CopilotはExchangeやSharePointのようなDLP適用対象と別扱いになっており、Copilotのチャット応答に機密データが含まれていても制御が効かないケースがあった。今回の更新で、特定の機密ラベルが付与されたコンテンツを含む出力をブロックしたり、ユーザーに警告を表示したりといった制御が統合管理下に入る。 PurviewはすでにExchange・SharePoint・Teams・OneDriveなど広範なサービスに展開されており、Copilotがその管理体系に組み込まれることで、「AIだけ別ルール」という隙間を塞ぐ形になる。 分析機能の強化——利用実態が初めて見えてくる 新しいアナリティクス機能では、管理者コンソールからCopilotの利用状況をより粒度細かく把握できる。どのMicrosoft 365アプリでCopilotが活用されているか、プロンプトのカテゴリ分布、ユーザーの活用パターンといったデータが可視化される。 これは単なるレポート機能ではない。ライセンスコストに見合った活用がされているかを客観的に評価する「ROI測定の基盤」として機能する。経営層への説明責任を果たす材料としても使えるし、活用が伸び悩んでいる部署を特定してピンポイントで教育投資する判断にも役立つ。 実務での活用ポイント 情報システム部門・IT管理者へ：既存のPurviewポリシーをCopilotへ拡張適用する準備を今から進めておこう。機密ラベルの整理とDLPポリシーの棚卸しは、Copilot展開前にやっておくと後が楽になる。後から整備しようとすると現場との摩擦が大きくなりがちだ。 コンプライアンス・法務チームへ：Copilotの利用ログが取れる環境が整ってきた。「AIを使ってよい業務・使ってはいけない業務」の社内規程を明文化するタイミングとして、今がちょうどいい。監査対応への備えとしても有効だ。 経営層・予算承認者へ：アナリティクスで利用実態が可視化されると、使われていないライセンスの存在が明確になる。単純な削減ではなく、「なぜ使われていないか」を掘り下げ、本当に価値を生む使い方への転換に投資する判断軸として活用してほしい。 筆者の見解 率直に言えば、「やっと来た」という印象だ。 CopilotをエンタープライズAIとして本格展開するなら、DLP統合は最低限の前提条件のはずだった。ExchangeやSharePointで何年も前から実績のあるDLPが、Copilotには後追いで適用される形になったのは正直もったいない。ガバナンス機能が早期に揃っていれば、導入をためらっていた組織はもっと早く動けていただろう。 ただし、方向性は正しいし、Microsoftらしい強みを活かしたアプローチだと思う。Purviewという既存の統合管理資産をCopilotにも接続していく姿勢は、「バラバラなツールを寄せ集めた」競合との明確な差別化になりうる。この統合ガバナンスの路線を徹底的に磨き続けてほしい。それこそがMicrosoftに期待する正面勝負の姿だ。 一方で、アナリティクスが整備されると「思ったほど使われていない」という現実が浮き彫りになる組織が出てくるはずだ。数字を見てライセンスを削るのではなく、活用が伸び悩む根本原因——UIの使いにくさなのか、適切なユースケースの未整理なのか、研修不足なのか——を特定することが次のステップになる。ツールが揃い始めた今こそ、AI活用戦略を腰を据えて見直す好機だ。 出典: この記事は Microsoft 365 Copilot Gets Purview DLP Controls and New Analytics の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Backup に待望の機能追加が迫っている。2026年4月末から5月初旬にかけて、SharePoint サイトおよび OneDrive に対する「細粒度復元（Granular Restore）」が一般提供される予定だ。これまでは「復元ポイント全体に巻き戻す」しか選択肢がなかったが、今後は管理者が特定のファイルやフォルダを検索・選択して単体で取り戻せるようになる。 これまでの課題：「1ファイルのためにサイト全体を戻す」という現実 Microsoft 365 Backup は 2023 年に登場した比較的新しいサービスで、Exchange・SharePoint・OneDrive のデータを Microsoft のインフラ上でネイティブにバックアップする仕組みだ。サードパーティのバックアップ製品を別途契約しなくても M365 のライセンス体系の中でデータ保護を完結できる点が評価されてきた。 しかしこれまでの復元機能には大きな制約があった。復元の単位が「サイト全体」または「OneDrive 全体」に限られており、誤って削除したファイルを 1 本だけ戻したい場合でも、サイト全体を過去のある時点に巻き戻すしかなかった。当然ながら、その間に行われた他の更新も一緒に失われるリスクがある。現場の管理者からすれば「やっと使えるバックアップが来た」と思ったら実運用では二の足を踏む、という状況が続いていた。 何が変わるのか：アイテム単位での検索・選択・復元 今回の「Granular Restore」対応により、管理者は復元ポイントの中から目的のファイルやフォルダをピンポイントで検索し、選択した上で復元先を指定して取り戻せるようになる。全体ロールバックは不要だ。 主なシナリオとして想定されるのは以下のようなケースだ： 誤削除・誤上書き：ユーザーが重要な Excel ファイルを削除・上書きしてしまったが、直前の状態に戻したい ランサムウェア被害の部分回復：暗号化されたファイルだけを選んで復元し、被害を受けていない部分には手を触れない 意図的な変更の取り消し：特定のドキュメントライブラリに加えられた変更だけを元に戻したい いずれも「サイト全体を巻き戻す」前提では対応が難しかった典型例だ。 実務への影響：管理者・エンドユーザー双方に恩恵 IT 管理者へのインパクト これまで M365 Backup を「いざという時のための保険」として契約しつつも、実際に使うと副作用が大きすぎると判断し、サードパーティ製品を併用していた組織は多い。今回の対応により、M365 Backup 単体での運用が現実的な選択肢になってくる。ライセンスコストの見直し余地が生まれるかもしれない。 管理者が意識すべき実践ポイントは次のとおりだ： 復元ポイントの保持期間と頻度を見直す：細粒度復元が使えるようになっても、復元ポイント自体が少なければ意味がない。バックアップポリシーを改めて精査する機会にしよう 権限設計を確認する：誰が復元操作を実行できるかを明確にしておく。SharePoint 管理者と情報保護担当者の役割分担を整理する テスト復元を定期的に実施する：復元機能が使えることと、実際に期待どおりに動くことは別物。本番稼働前の検証習慣をつける エンドユーザーへのインパクト ユーザー側からは直接見えない機能ではあるが、「ファイルを誰かが消したかもしれない」「昨日の版に戻したい」といった問い合わせに管理者がより迅速かつ低リスクで対応できるようになる。結果としてビジネス継続性が向上する。 筆者の見解 M365 Backup が登場した当初から、「全体ロールバックしかできないのでは実用性に欠ける」という声は絶えなかった。この改善は方向性として正しいし、遅すぎたくらいだと思う。 Microsoft 365 のプラットフォームとしての強みは、バックアップ・コンプライアンス・セキュリティ・コラボレーションが一つの管理体系の中に収まっていることだ。その統合価値をフルに活かすためには、個々の機能が「実際に使えるもの」になっている必要がある。今回の Granular Restore はその一歩として素直に評価できる。 一方で、M365 Backup の認知度はまだ高くない。特に中堅・中小の日本企業では、データ保護の仕組みをサードパーティに丸投げしているか、あるいは「ごみ箱と過去バージョン履歴で何とかなる」という認識のままの組織も多い。今回のアップデートを機に、自社のデータ保護方針を一度棚卸しする価値はある。 Microsoft には、こうした地道な機能の完成度向上を今後も着実に積み重ねてほしい。プラットフォームとしての総合力はまだ他の追随を許さないものがある。その力をしっかり発揮したサービスが増えれば、現場の信頼はさらに厚くなるはずだ。 出典: この記事は Microsoft 365 Backup: Granular restore for SharePoint and OneDrive coming late April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ライセンス失効と同時にアクセス停止——「猶予」はもう存在しない 2026年4月1日付けで、Microsoft 365をCSP（クラウドソリューションプロバイダー）経由で契約している企業に対し、これまで提供されていた30日間の猶予期間（グレース期間）が廃止された。 これまでは、ライセンスが失効しても30日間はサービスが継続していた。言い換えれば「うっかり更新を忘れても翌月末まで大丈夫」というバッファが存在していた。このバッファが4月1日をもって消滅した。 代わりに登場した「Extended Service Term（延長サービス期間）」 廃止された猶予期間の代替として導入されたのが Extended Service Term（延長サービス期間） だ。自動更新が無効になっていて、かつ失効前に更新注文が入らなかった場合、サブスクリプションは自動的にこの状態に移行する。 サービスは継続されるが、料金は月次換算レート（年額プランの約20%割高）＋さらに3%のアップリフトが適用される。すなわち、更新忘れは実質的なコスト増に直結する。 ただし、Extended Service Termはいつでもキャンセル可能で、日割り課金となる点は柔軟性があると言えよう。 実務でのリスク：「気づいたらアクセス停止」は十分に起こりうる 日本の企業では、ライセンス管理を経理部門・購買部門・IT部門が三者で分担しているケースが多い。更新手続きの連絡が途切れたり、担当者の異動・退職があったりすると、更新漏れが起きる。これまでは猶予期間が事故を防いでいたが、今後はそのセーフティネットがない。 今すぐ確認すべき項目： テナントの自動更新設定の有効/無効状態 ライセンス更新フローの担当者と手順の文書化 更新期限の社内カレンダーへの登録と複数担当者への通知設定 Microsoft 365 E7——AIを「オプション」ではなく「基盤」として組み込んだ次世代SKU 2026年5月1日、Microsoftはエンタープライズ向け最上位ライセンスとして Microsoft 365 E7 を投入する。長年にわたってフラグシップの座にあったE5の後継に相当する位置づけだ。 E7の構成はE5のすべての機能に加え、以下が追加される： Microsoft 365 Copilot（月額従量課金のアドオンではなく包含） Entra Suite（旧Azure AD Premium含む包括的なID管理） Agent 365（組織内エージェントの統合管理・ガバナンス基盤） 何が変わるのか：AIが「使うもの」から「働くもの」へ E7の設計思想は明確だ。AIをユーザーがオプションで追加するツールではなく、組織のワークフローに深く組み込まれた実働基盤として位置づけることにある。 Agent 365を通じて、AIエージェントが個々のユーザーを補助するだけでなく、組織横断でタスクを実行・自動化し、かつそのガバナンス（権限管理・データ過剰共有リスクの監視）をプラットフォーム側で担う構成になる。 Agent 365の単独提供も開始 Agent 365はE7に包含されるだけでなく、単独ライセンスとしても5月1日から提供開始される。自社テナント内のすべてのマネージドエージェントを一元把握し、パフォーマンス・挙動・リスクシグナル（データ過剰共有の可能性など）に対して素早く対処できる仕組みだ。 Windows 10 Enterprise LTSB——2026年10月にサポート終了、ESU費用は毎年倍増 Windows 10 Enterprise LTSB（Long Term Servicing Branch）が2026年10月にサポート終了を迎える。 移行が難しい環境向けに延長セキュリティ更新プログラム（ESU）の購入は可能だが、費用は毎年倍増するモデルだ： 年 費用（1デバイスあたり） Year 1（2026年10月〜） 約65ユーロ Year 2（2027年10月〜） 約130ユーロ Year 3（2028年10月〜） 約260ユーロ ...

Microsoft 365 Copilotの診断ログ送信機能に、ユーザーのプライバシーを脅かしかねない設計上の問題が明らかになった。管理者が「サポート目的」でログを送信する際、ユーザーが入力したプロンプトと、Copilotが生成した応答のすべてが平文（JSON形式）で管理者自身にも丸見えになっている。これは、多くのユーザーが想定しているであろう「プライバシーの範囲」を大きく逸脱している可能性がある。 何が問題なのか Microsoft 365管理センターのCopilotセクションには、「ユーザーに代わって診断ログをMicrosoftに送信する」機能が存在する。公式の説明によれば、これはユーザー自身がフィードバックを提供できない場合でも、組織がCopilotの品質改善に貢献できるようにするためのものだ。 具体的には、特定のアプリケーション（たとえばCopilot Chat / BizChat）を対象として、過去30日以内の最大30件のインタラクションをログとして収集できる。収集されたデータはJSONファイルとして生成され、リンクをクリックするとブラウザで即座に中身が確認できる。 そしてここが問題の核心だ——そのJSONには、ユーザーが入力したプロンプトと、Copilotが返した応答がそのまま記録されている。 サポートエンジニアが読み解きやすいように平文にしているという設計意図は理解できる。しかし、管理者がユーザーの同意なく、あるいは最低限の監査証跡もなく、その内容を閲覧できてしまう点は問題だ。現時点では、管理者がこのログをエクスポートしても監査ログに記録が残らないという指摘もあり、「誰がいつ誰のプロンプトを見たか」すら追跡できない状態になっている。 なぜこれが重要か AIツールの使われ方を考えると、この問題の深刻さが見えてくる。ユーザーはCopilotに対して、HR上の相談、戦略的な方向性の検討、個人的な業務上の悩みなど、対外的には共有したくない内容を入力することも少なくない。AIへの問いかけが「考えの鏡」のような役割を担っている以上、そこには相応の秘密保持が前提として存在する。 そうした前提のもとで、管理者がユーザーの知らないところでプロンプト履歴を参照できる——これは、組織のコンプライアンス担当者や法務部門にとっても、看過できないリスクだ。GDPRや日本の個人情報保護法の観点からも、「業務利用のAIインタラクションをどう扱うか」という議論に直結する問題である。 実務への影響 IT管理者・情報セキュリティ担当者が今すぐ確認すべきポイントを整理する。 1. 診断ログ機能の利用ポリシーを策定する 管理センターの「Copilot診断ログの送信」機能は、利用できる状態になっているか確認しておく必要がある。既存のポリシーにこの機能の取り扱いが含まれていなければ、早急に追記すべきだ。 2. ユーザーへの周知 「管理者があなたの代わりにCopilot診断ログを送信することがある」という事実は、利用規約や社内ガイドラインとしてユーザーに明示しておくことが求められる。特に、機微な情報をCopilotに入力しないよう促すコミュニケーションが重要になる。 3. 監査ログの空白を意識する 現時点ではログエクスポートの監査記録が残らない。この空白を認識したうえで、「誰がこの機能を使えるか」をロールベースで制限する運用を検討する。 4. Microsoftの対応をウォッチする この問題はすでにMicrosoft 365 Copilotのフィードバックフォーラムに報告されており、改善を求める声が集まっている。Microsoftが難読化や監査記録の整備といった対応を取るかどうか、今後のアップデートに注目しておきたい。 筆者の見解 MicrosoftがCopilotのプロンプトと応答を平文でログに保持し、管理者が容易に閲覧できる設計を選んだことは、「もったいない」の一言に尽きる。 Microsoftはエンタープライズセキュリティとコンプライアンスのノウハウを世界トップレベルで持っている。使用状況レポートの匿名化オプションを既に備えているように、「ユーザーデータをどう守るか」という設計思想を実装する力は十分にある。それだけに、Copilotの診断ログがここまで無防備な形で提供されていることは、正直なところ驚きだった。 「デバッグのために平文が必要」という要件と「管理者からプロンプトを守る」という要件は、技術的には両立できるはずだ。暗号化されたログをMicrosoftのサポートエンジニアだけが復号できる設計にするなど、選択肢は複数ある。今の設計はあくまで「開発フェーズの利便性優先」が残ったまま本番リリースされた印象を受ける。 Copilotを組織全体へ展開していく上で、この種のプライバシーリスクは「信頼の土台」に関わる問題だ。Microsoftにはその土台をしっかり固めてほしい。CopilotがエンタープライズAIの本命として進化していく姿を期待しているからこそ、こういった部分を丁寧に直していってほしいと思う。 Microsoftのフィードバックフォーラムへの投票で改善を求めることが、今できる最善のアクションだ。こうしたコミュニティからの声がプロダクトを動かした実績は十分にある。 出典: この記事は The Open Nature of Microsoft 365 Copilot Diagnostic Logs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが矢継ぎ早にMicrosoft 365のセキュリティ強化策を打ち出している。M365 Appsのセキュリティベースライン公開、Teams管理センターへのTrust機能追加、そしてDefender for Office 365 Plan 1のE3プランへの標準搭載——これらが同時に展開され始めた。日本のIT現場にとっても他人事ではない動きだ。 セキュリティベースラインとは何か 「セキュリティベースライン」とは、Microsoftが推奨するセキュリティ設定の基準値をまとめたものだ。今回のM365 Apps向けベースラインは、Word・Excel・PowerPoint・Outlookといったアプリ群に対して、どのポリシーをどの値に設定すべきかを明示した公式ガイダンスとなる。 これまでも非公式の推奨設定はあったが、今回は明確に「ベースライン」として整理された。つまり、「このポリシー設定を下回るのはリスクがある」という公式のラインが引かれたことを意味する。グループポリシーやIntune経由で展開できるため、大規模環境でも適用しやすい。 Teams管理センターのTrust機能 Teams管理センターに追加されたTrust機能は、外部ユーザーや外部テナントとのコラボレーション時の信頼レベルを細かく制御するものだ。どのテナントを「信頼する」か、どの操作を許可するかをきめ細かく管理できるようになる。 ゼロトラストのコンセプトである「すべてを検証し、最小権限を付与する」に沿った機能拡張であり、特にマルチテナント環境を持つ企業や、顧客・パートナーと頻繁にTeamsを使ってコラボする組織にとって重要な管理ポイントとなる。 E3にDefender for Office 365 Plan 1が標準搭載 今回の施策の中で最も実務的なインパクトが大きいのが、Defender for Office 365 Plan 1のE3プランへの標準搭載だ。これにより、Safe Links（URLの動的検証）やSafe Attachments（添付ファイルのサンドボックス検査）などの機能が、E3ライセンスのユーザーも追加コストなしで利用できるようになる。 これまでこれらの機能はE5ライセンスまたは別途アドオン購入が必要だった。E3止まりで運用している中堅企業にとっては、実質的なセキュリティ機能の引き上げが無償で行われることになる。 Security Copilotは2026年4月〜6月にE5向け段階展開 AIを活用したセキュリティ分析機能であるSecurity CopilotについてはE5ライセンス向けに、2026年4月20日から6月30日にかけて段階的に展開される予定だ。セキュリティインシデントの要約・分析、脅威の自動調査などを支援する機能群であり、セキュリティオペレーションチームの負担軽減に貢献することが期待される。 実務への影響——日本のIT管理者が今すぐすべきこと 1. ベースラインの把握と現状ギャップの確認 公開されたM365 Appsセキュリティベースラインを入手し、現在の組織ポリシーとの差分を確認する。特にIntuneやグループポリシーを使ってM365アプリを管理している場合、どの設定がベースラインを下回っているかを可視化することが第一歩だ。 2. E3環境ではDefender機能の有効化を確認 E3ライセンスを使っている場合、Safe LinksやSafe AttachmentsがテナントでONになっているか確認する。ライセンス上使えるようになっても、管理者が明示的に有効化しなければ機能しない設定も多い。 3. Teamsの外部連携ポリシーの棚卸し Trust機能が追加されたこのタイミングで、外部テナントとの共有設定を一度見直す良い機会だ。「なんとなく許可になっている」設定が残っていないか確認する。 筆者の見解 セキュリティは正直、細かい話が多くて食指が動きにくいジャンルではある。が、今回の一連の施策はその「細かさ」の中でも骨太な方向性が見えるものだと思う。 E3へのDefender標準搭載は、現場への影響という意味では地味に大きい。これまで「E5は高くて買えないので、Safe Linksは諦めている」という組織が日本にも相当数存在する。その現実に対してMicrosoftがアンサーを出したと読むことができる。セキュリティ機能を「上位プランだけの特権」にし続けることのリスクを、Microsoftが認識したということでもある。 セキュリティベースラインの公式化も評価できる。「ベンダーの推奨には理由がある」と常々思っているが、その推奨が公式ドキュメントとして整理されることで、管理者がステークホルダーに説明するための根拠が得られる。「MicrosoftがこのポリシーをONにしろと言っている」という文書は、現場でのセキュリティ施策の推進力になる。 Zero Trustを本気でやろうとすると、ネットワーク・認証・認可の3層すべてに手を入れる必要がある。今回のTrust機能や設定ベースラインの整備は、「認可層」の管理をより精緻にするための布石として機能する。道のりはまだ長いが、プラットフォームとして必要な仕組みを着実に積み上げているのは確かだ。MicrosoftにはMicrosoft 365という強力なプラットフォームがある。この方向で積み上げ続ければ、エンタープライズのセキュリティ基盤として揺るぎない地位を確立できる力は十分にある。 出典: この記事は Microsoft Rolls Out Security Baseline for Microsoft 365 Apps, Teams Admin Center Trust Features の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが5月1日より、クラウドPC サービス「Windows 365」の価格を一律20%引き下げると、チャネルパートナーへの通知を通じて明らかにした。主なターゲットは中小企業（SMB）であり、クラウドベースのデスクトップ環境をより多くの組織に届けようという意図が透けて見える。 Windows 365とは何か——改めて整理する Windows 365はフル機能のWindowsデスクトップをクラウド上に展開し、任意のデバイスからブラウザ経由でストリーミングできるサービスだ。Azure Virtual Desktop（AVD）と混同されることが多いが、AVDが仮想化基盤の構築・管理を伴うエンタープライズ向けであるのに対し、Windows 365はPC1台分のリソースをそのままクラウドに置き換えるイメージに近い。ライセンス体系もシンプルで、ユーザー単位の固定月額という分かりやすさが特徴だ。 なぜ今、20%値下げなのか ここ数年でクラウドデスクトップ市場には競合が増えた。AWSのWorkSpaces、Google ChromeOSの企業展開など、選択肢が広がる中でMicrosoftが価格競争力を高める動きは自然な流れといえる。特にSMBセグメントは、初期投資の少なさと運用の簡便さを重視する傾向が強く、月額コストの20%削減はIT担当者の稟議を通りやすくする上で十分な効果がある。 一方で、この値下げには別の文脈もある。端末更新サイクルと絡めた提案だ。Windows 10のサポートが2025年10月に終了を迎え、多くの中小企業が端末リプレースの判断を迫られている。老朽化したハードウェアをそのまま使いながらWindows 11のクラウド環境へ移行するシナリオは、CapExを削減したい企業にとって魅力的な選択肢になりうる。 実務への影響——日本の中小企業IT担当者へのヒント 今が見直しのタイミングとして押さえておきたいポイントを整理する。 Windows 10 EOS対応と組み合わせる: ハードウェアの買い替えコストとWindows 365の月額を5年総コストで比較すると、特に少数台数（10〜50台程度）の環境ではクラウドPC移行が有利になるケースが増える。5月1日の価格改定後の試算を必ず行うこと。 ゼロトラスト推進と相性が良い: Windows 365はデータがエンドポイントに残らない構造であるため、デバイス紛失・盗難時のデータ漏洩リスクが大幅に下がる。ゼロトラスト移行を検討している組織には特に有効な一手となる。 ライセンス体系の整理を忘れずに: Microsoft 365との組み合わせ次第でEntitlementが変わることがある。CSP経由の購入であれば、パートナーに最新の価格表と推奨構成を確認してほしい。 AVDとの使い分けを明確に: ユーザー数が増えるほどAVDの方がコスト効率が上がる場合がある。50名を超える規模なら、両者の比較検討が必要だ。 筆者の見解 この価格改定を見て、正直「やっとここに踏み込んだか」という感想を持った。Windows 365は技術的には完成度の高いサービスだが、価格のせいで中小企業への訴求力が弱かった。ハードウェアの買い替えコストとの比較試算で「高い」と弾かれてきた案件が、この値下げによって再評価されるケースは少なくないはずだ。 Microsoftの総合力——Azure、Entra ID、Intune、Microsoft 365との統合——は他のクラウドデスクトップサービスにはない強みだ。この「プラットフォームの一部として機能するクラウドPC」という価値は、バラバラなポイント製品を組み合わせるコストを考えると、十分に競争力がある。その強さを、もっと多くの企業に届けられる価格帯になったことは素直に評価したい。 あとはパートナーエコシステムが適切な提案活動を行えるかどうか。技術的な優位性があっても、現場に届く言葉で伝えられなければ選ばれない。日本のIT企業・SIerがこの価格改定を機に、クラウドPC移行提案を本格的に始動させる契機になることを期待している。 出典: この記事は Microsoft Cuts Windows 365 Prices by 20% to Attract SMBs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月のパートナー向けAIビジネスソリューション更新情報を公開した。注目はSecurity CopilotのM365 E5への段階的統合だが、その背後には「バラバラに生まれたAI機能を一本の線でつなごうとする」意図が透けて見える。個々の発表を追うだけでなく、この流れ全体をどう解釈するかが今後の導入判断に直結する。 Security CopilotがM365 E5に入ってくる——何が変わるのか 最大のニュースはSecurity CopilotのM365 E5への段階的追加だ。ロールアウトは2026年4月20日に開始、6月30日までに順次展開される。 これまでSecurity Copilotは単独のSKU（Security Copilot Standalone）かアドオンとして提供されており、M365 E5との組み合わせといえどもライセンス的には別物だった。今回の統合によって、すでにE5ライセンスを持っている組織はSecurity Copilotの機能に追加コストなしでアクセスできる可能性が出てくる（詳細な条件は確認が必要）。 Security Copilotが担う役割 Security CopilotはMicrosoft Defenderや Sentinel、Purview などのセキュリティ製品と統合し、インシデント調査・脅威ハンティング・コンプライアンスレポートの自動化を担う。GPT-4ベースのAIが自然言語で問い合わせに答え、セキュリティアナリストの分析時間を短縮することが主な価値提案だ。 M365 E5はもともとMicrosoft Defender for EndpointやDefender for Identity、Entra ID P2などのセキュリティ機能を包含する上位ライセンスであり、そこにSecurity Copilotが加わることは、「ゼロトラスト＋AIアシスト」の組み合わせを標準装備にする方向への大きなステップといえる。 Agent 365とFrontier Suite——「AIエージェント化」の足場固め もう一つの注目点はAgent 365関連の販売支援ツールとFrontier Suiteに関するアップデートだ。Agent 365はM365 Copilot Studioと連携し、業務プロセスを自律的にこなすAIエージェントを企業内に展開するためのフレームワークと位置づけられている。 Frontier Suiteは現時点では詳細が限定的ではあるが、Microsoftが「AIビジネスソリューション」の最上位層として位置づけるプロダクト群だ。今回のパートナーアップデートで販売支援ツールが整備されたということは、パートナー経由でのエンタープライズ展開を本格的に加速させようとしていることを意味する。 日本では多くのMicrosoftパートナー企業が顧客の導入支援を担っており、これらのツール整備は現場レベルで具体的なメリットをもたらす可能性がある。 実務への影響——日本のIT管理者・エンジニアが今すべきこと ①M365 E5ライセンスの棚卸しを今すぐ Security Copilotが段階展開されるタイミングに合わせ、自組織のM365 E5ライセンス範囲と対象ユーザーを確認しておく。展開対象に含まれれば、追加コストなしでセキュリティ対応力が底上げされる可能性がある。まずはMicrosoft 365管理センターでライセンス状況を確認し、パートナーや担当CSAMに問い合わせを入れる価値がある。 ②「禁止ではなく仕組みで制御」の視点でSecurity Copilotを評価する Security Copilotは「AIにアクセスを与えるのは危険だから禁止」という発想の対極にある。アナリストが行うべき作業をAIが補佐し、人間が意思決定に集中できる構造を作る。ゼロトラストアーキテクチャと組み合わせることで、常時アクセス権の最小化（Just-In-Time）と自動検知・対応の両立が現実的になってくる。 ③AIエージェント導入の「入口」を見極める Agent 365を通じたAIエージェント展開は今後1〜2年で加速するだろう。ただし「エージェントを入れること」が目的化すると失敗する。Teamsでの議事録要約や定型メール処理など、ROIが明確な小さな業務から始め、実績を積み上げる進め方が現実的だ。 筆者の見解 今回のアップデートを見て率直に思うのは、「ようやく点と点がつながり始めてきた」という感触だ。Security CopilotをE5に統合し、Agent 365でエージェント化の基盤を作り、Frontier Suiteで上位層を整える——これは個別の機能追加ではなく、プラットフォームとしての全体設計を意識した動きだ。 Microsoftが「統合によって価値を生む」プラットフォームであることは長年変わらない強みであり、今回の方向性はその本来の強みに立ち返っているように見える。Security Copilotの単独課金から統合へのシフトは、エンタープライズ顧客にとって導入判断のハードルを下げるという意味でも賢い一手だ。 ただし、機能が揃うことと「使えること」は別の話だ。日本の現場では、セキュリティチームの人材不足、既存の承認プロセスの複雑さ、ゼロトラスト移行が道半ばの環境など、AIを有効活用するための前提条件が整っていないケースが少なくない。機能の発表に飛びつくよりも、自組織の「AIが活きる土台」をどう整えるかを先に考えることが、今この瞬間の正しい行動だと思う。 Microsoftには、この整合のとれた設計をCopilot全体で一貫させてほしい。そうすれば、今以上に「Microsoftでまとめる意味がある」と自信を持って言える日が来るはずだ。その日を楽しみにしながら、今回の4月アップデートを注目している。 出典: この記事は AI Solutions April Updates – What’s New for Partners in AI Business Solutions の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月15日、Microsoft 365のCopilot提供形態が静かに変わる。対象は有償の「Microsoft 365 Copilot」ライセンスを持たない、いわゆる基本プランの「Copilot Chat」利用者だ。変更の規模は地味に見えるが、組織のIT管理者にとっては利用ガイドやサポート対応を見直す契機になり得る。 何が変わるのか——変更のポイントを整理する 今回の変更は一言でいうと、「アプリ内Copilotアクセスの制限」だ。 これまでCopilot Chatの基本プランでも、Word・Excel・PowerPointといったM365アプリ内にCopilotのUIが表示されており、一部の機能を使える状態にあった。4月15日以降、この「アプリ内UI」が基本プランのユーザーには表示されなくなる。 一方で、以下は変わらない点として明示されている： Copilot Chat本体：EdgeまたはChromeを通じたセキュアなAIウェブチャットは引き続き利用可能 チャット経由のコンテンツ作成：Microsoft 365 Copilotのウェブインターフェースから、Word・Excel・PowerPoint向けの文書をAI支援で作成できる Outlookのコパイロット機能：受信トレイ整理・カレンダー調整・会議サマリーなど、Outlook内のCopilot機能はそのまま残る 有償の「Microsoft 365 Copilotライセンス」保有者は今回の変更に一切影響を受けない。アプリへの深い統合（ドキュメント内でのリアルタイム提案・要約など）は、引き続きフルライセンスのみの特権となる。 「削減」ではなく「整理」——Microsoftの意図を読む 技術的な実態を見ると、今回の変更は機能の廃止ではなく利用経路の整理と解釈できる。 Copilot Chatを通じたドキュメント生成（Word/Excel/PowerPoint）は引き続き可能であり、できることの本質は変わっていない。ただし「アプリを開いた状態でその中でCopilotを呼び出す」というUI体験が基本プランでは使えなくなる。生産性ツールとしてのシームレスな統合感——それがフルライセンスの価値として改めて明確化された形だ。 Microsoftが段階的にライセンス体系を整理しながら、アプリ統合の深さをマネタイズポイントに設定していく意図は明らかだ。 実務への影響——IT管理者がすべきこと 利用者へのアナウンスを先手で打つ 「4月15日以降にWord内でCopilotが消えた」という問い合わせが現場から多発する可能性がある。変更前に組織内の利用者へ変更内容と代替手順（Copilot Chat経由の利用方法）を周知しておくことで、ヘルプデスクへの問い合わせ急増を防げる。 ライセンス棚卸しの好機 Copilotを日常的に使い込んでいるユーザーと、ほとんど使っていないユーザーの差が今回の変更で可視化されやすい。「アプリ内Copilotが必要」という要望が多い部署・ロールについては、フルライセンス付与の費用対効果を改めて評価するきっかけになる。 教育機関・パブリックセクターは特に注意 今回の元情報がアイオワ大学のITS（情報システム部門）からのものであることが示すように、全教職員・学生にCopilot Chatを展開している教育機関では影響範囲が広い。「誰に何のライセンスを付与しているか」の台帳整理が急務になる場合がある。 Outlook依存の業務フローは安心して継続 会議サマリーの自動生成・受信トレイの優先度整理など、Outlookに依存した業務フローは今回の変更対象外だ。日常業務でOutlookのCopilot機能を活用しているユーザーに対しては「影響なし」と明確に伝えられる。 筆者の見解 Microsoftが基本プランとフルライセンスの差を改めて明確化したことは、製品戦略として理解できる。だが「Copilotをもっと使ってほしい」という方向性と「基本プランでアクセスできるものを絞る」という方向性は、本来であれば緊張関係にある。 Copilotというブランドをここまで広げた以上、触れる機会を増やすことが普及への近道だったはずだ。アプリ内の直感的な起動ポイントがなくなれば、日常的に使う習慣がついていないユーザーがわざわざWebインターフェースを開く可能性は高くない。「便利を感じる前に離脱する」というリスクは看過できない。 Microsoftが誇るM365の統合エコシステムは、シームレスな体験にこそ価値がある。その核心部分をライセンス差異のロック機構として使うのであれば、「まず触ってもらう」という導線設計を別途用意する必要があるだろう。 いずれにせよ、4月15日は急ぐほどの変更ではない。ただしIT管理者にとって「Copilotのライセンス体系を正確に把握しているか」を問い直す機会として、今回の変更は無駄にしない方がいい。 出典: この記事は Update to Copilot availability in Microsoft 365 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ドキュメント編集の現場でCopilotが使いものになるかどうか——その答えは長らく「惜しい」だった。しかし今回のアップデートで、その評価がいよいよ変わるかもしれない。MicrosoftはCopilot in Wordに対して、変更追跡（Tracked Changes）を維持しながら複数ステップの編集をリアルタイム表示する機能を追加した。対象は法務・財務・コンプライアンス部門向けのドキュメントワークフローだ。 何が変わったのか これまでのCopilot in Wordは、文書に直接変更を加える形で動作していた。つまり、AIが行った編集が即座に文書に反映され、「どこが変わったか」が人間にとって追いにくいという問題があった。 今回追加されたのは、Copilotが行う編集をすべてTracked Changesとして記録しながら処理するモードだ。編集の各ステップがリアルタイムで表示されるため、内容を人間がステップごとに確認・承認または却下できる。これは文書レビューのワークフローとしては当たり前の要件だが、AIアシスタントがこれを正式にサポートするのは重要な進化だ。 現時点での提供範囲は、FrontierプログラムおよびOffice Insiders Beta Channelに限定されており、Web版・Mac版は近日対応予定とのことだ。 なぜこれが重要か 日本の企業、特に法務・財務・コンプライアンス部門にとって、文書の変更管理は非常にセンシティブな問題だ。契約書や稟議書、コンプライアンス報告書には、誰が何をどのタイミングで変更したかという証跡が必須となる。 これまでAIに文書作成・編集を任せることへの心理的ハードルの一つは、まさにこの「変更の可視性」だった。AIが自動で文書を書き換えても、どこが変わったのか人間が把握できなければ、業務プロセスとして成立しない。Tracked Changesへの対応は、その根本的な懸念を払拭する方向への一歩だ。 さらに、複数ステップの編集をリアルタイム表示する設計は、AIによる一括変換への不安（「気づかないうちに大幅に変わっていた」問題）も軽減する。人間がフィードバックループに入りやすくなることで、AIの編集を管理下に置きながら活用できるという、現場が求めてきたあり方に近づいた。 実務への活用ポイント 今すぐできること: Office Insiders Beta Channelへの参加を検討する（IT管理者は展開ポリシーの確認が必要） 法務・財務チームを対象に、Tracked Changes対応Copilotのパイロット運用計画を立てておく 現在の文書レビューフローを整理し、どのステップにCopilot編集を差し込めるかを事前にマッピングする 注意点: 本機能はまだInsiderチャンネル限定のため、本番業務への展開は一般提供（GA）後が望ましい Tracked Changesが残る仕様上、最終的な承認・マージは人間が行う設計。この「人間の関与」をプロセスに明示的に組み込んでおくこと 機密性の高い文書にCopilotを使う場合は、Microsoft 365のデータ処理ポリシーと社内のAI利用ガイドラインを再確認する 筆者の見解 Copilot in Wordがここまで来るのに、正直もう少し早ければよかったとは思う。法務や財務の現場がAIに文書編集を任せられない最大の理由が「変更の追跡ができない」ことだったのは、ずっと前から明白だった。それでも「今回ついに」とその進化を素直に評価したい。 Microsoftはドキュメントエコシステムにおいて圧倒的な資産を持つ。WordのTracked ChangesはOffice文化に深く根付いたUIパターンであり、それをAI編集と統合できるポジションにいるのはMicrosoft以外にほとんどいない。正面から勝負できる力がある、というのがこのニュースを見ての実感だ。 ただし、一般提供（GA）後の動作安定性と、大組織での展開しやすさの検証はこれからだ。FrontierやBetaでの挙動が本番チャンネルでどこまで再現されるか。法務・財務ユーザーが実際に使い続けられるUXになっているか。そこを確認してから判断したい。期待を込めて、続報を注視している。 出典: この記事は Copilot in Word: New Capabilities for Document Workflows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

なぜ今これが重要なのか Microsoft 365テナントで動くアプリケーションの数は年々増加している。Graph APIを通じて Sites.FullControl.All や Mail.Read といった強力な権限に同意済みのアプリが野放しになっているテナントは、正直なところ珍しくない。攻撃者がそこを突いてくるのは自明だ。 Entra IDには「ユーザー・グループ割り当て」という機能がある。これを有効にすると、割り当てを持つユーザーだけがそのアプリを使えるようになる。地味に見えて、実はゼロトラスト戦略の一環として非常に有効な手段だ。 割り当て機能の仕組みをおさらい Entra IDのアプリ（厳密にはサービスプリンシパル）には、ユーザーまたはグループを割り当てる機能がある。割り当てが1件でも存在する状態になると、割り当てを持たないユーザーはそのアプリにサインインできなくなる。 何も割り当てがない初期状態では全ユーザーが使えるため、この「デフォルト全開」という設計を意図的に閉じていく作業が必要だ。 Microsoftドキュメントでは「エンタープライズアプリケーション」という用語が使われているが、実体はサービスプリンシパルだ。テナント内で作ったアプリ登録にも、Microsoftやサードパーティのマルチテナントアプリにもこのしくみはどちらにも適用できる。 管理センターからの操作 Entra管理センターの「エンタープライズアプリケーション」から対象アプリを開き、「ユーザーとグループ」ブレードから割り当てを追加するだけだ。個人ユーザーへの割り当ては無償で行えるが、グループへの割り当てにはEntra ID P1以上が必要な点は覚えておきたい。動的グループも使えるため、部署や役職属性と連動した自動管理も可能だ。 PowerShellによる一括操作 管理センターのGUIで1件ずつ作業するのが辛い規模になったら、Microsoft Graph PowerShell SDKを使う。ユーザーへの割り当ては New-MgUserAppRoleAssignment、グループへの割り当ては New-MgGroupAppRoleAssignment で行う。 出典: この記事は Leverage User and Group Assignments to Limit User Access to Apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

モバイルデバイス管理（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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。