M365

Microsoftは2026年7月から Microsoft 365 の価格体系を改定し、Defender 系セキュリティ機能を既存プランに統合した新バンドルへの移行を開始する。企業規模を問わず、すべての Microsoft 365 契約組織が影響を受ける可能性があり、IT管理者は今から対応を計画しておく必要がある。 今回の改定で何が変わるのか 今回の改定の骨子は大きく2点だ。価格の引き上げと、Defender機能のプラン統合である。 Microsoftは近年、バラ売りしていたセキュリティ製品をM365プランに内包する方向で一貫してラインアップを整理してきた。2023年の大幅値上げに続く今回の改定も、この流れの延長線上にある。具体的には、これまで上位プランや追加ライセンスが必要だった Microsoft Defender for Business 相当の機能が、一部の中小企業向けプランに標準搭載される形での価格改定となる。 新しく設けられる「セキュリティバンドル」は、エンドポイント保護・フィッシング対策・メール脅威防御・脆弱性管理を一体化したもので、従来は複数のアドオンを組み合わせて実現していた構成を1つのプランで賄えるようにすることを狙っている。 影響を受けるプランと価格変動の目安 今回の改定が影響するのは主に以下の範囲だ： Microsoft 365 Business Standard / Premium: 既存プランの月額が引き上げられる一方、Defender 機能が追加される Microsoft 365 E3 / E5 エンタープライズ向け: E3 ユーザーへのセキュリティ機能追加に伴う価格調整 新設「Microsoft 365 Security Bundle」系: Defender for Business・Entra ID P1・Intune をセットにした新パッケージが登場 日本では円建て価格への反映タイミングが遅れることも多いため、現行契約の更新時期を確認しておくことが重要だ。 なぜこれが重要か——セキュリティ統合の本質的な意味 この改定を単純な「値上げ」と捉えるのは半分正しくて半分間違いだ。 Microsoftの戦略は明確で、エンドポイントセキュリティ・ID管理・デバイス管理を同一プラットフォームで一元管理できる状態を標準にすることにある。バラバラのセキュリティ製品を寄せ集めた構成は、運用コストが高く、設定漏れやポリシーの齟齬が生じやすい。統合プラットフォームとして使うことで初めて価値が出るというのがMicrosoft 365の本来の設計思想であり、今回の改定はそれを価格構造でも強制する形になっている。 特に ゼロトラスト移行の文脈では、Defender for Endpoint・Entra ID・Intune の3製品が連携して初めて「デバイスコンプライアンスに基づく条件付きアクセス」が機能する。これらがバンドルに含まれることは、ゼロトラスト構成の敷居を実質的に下げる効果がある。 実務での活用ポイント——IT管理者が今すぐすべきこと ① 現行ライセンスの棚卸しを今すぐやる 新バンドルへの移行で「重複支払い」が発生するケースがある。すでに Defender for Endpoint や Intune を個別に契約している組織は、バンドルへの統合後に従来の個別ライセンスを切る必要がある。Microsoft 365 管理センターの「課金 → ライセンス」から現状を確認しておこう。 ...

Microsoftは、オンプレミス環境でOfficeファイルのブラウザ表示・編集を可能にするOffice Online Server（OOS）の廃止を正式に発表し、廃止スケジュールを公開した。長年にわたってSharePoint ServerやExchange Serverのブラウザプレビュー基盤として使われてきた製品が、クラウドファーストへの全面移行に伴い、その役割を終えることになる。 Office Online Serverとは何か Office Online Serverは、SharePoint Server、Exchange Server、Skype for Business Serverなどのオンプレミス製品と連携し、Webブラウザ上でWord・Excel・PowerPointドキュメントを表示・編集できるようにするサーバー製品だ。以前は「Office Web Apps Server」と呼ばれており、2016年にOffice Online Serverへ改称された経緯を持つ。 主な用途は以下の通りだ。 SharePoint Server上のドキュメントプレビュー — エクスプローラービューで添付されたファイルをブラウザ上で直接開ける Exchange Serverのメール添付プレビュー — Outlookオンラインプレビュー機能の裏側 オンプレミス環境でのリアルタイム共同編集 クラウド版のMicrosoft 365では、同等機能が「Office for the Web」として提供されており、OOSはあくまでオンプレミス向けの代替として位置づけられてきた。 廃止の背景：クラウドへの全面シフト Microsoftのクラウドファースト戦略は今に始まった話ではないが、今回の廃止発表はその流れの集大成とも言える。OOSはここ数年、実質的に「機能追加なしのメンテナンスモード」状態にあり、Microsoftのエンジニアリングリソースが実質的にMicrosoft 365側に集中していることは業界内では広く知られていた。 廃止に向けた移行先としてMicrosoftが示す道筋は明確だ。Microsoft 365（SharePoint Online + Office for the Web）への移行が推奨パスであり、クラウド上では既に同等以上の機能が提供されている。 実務への影響：日本のオンプレ組織は今すぐ動け 日本の大企業・官公庁・医療機関には、さまざまな事情からオンプレミスのSharePoint Serverを維持し続けているケースが少なくない。 セキュリティ・コンプライアンス要件によりクラウド利用が制限されている 既存の業務システムとSharePoint Serverが密結合しており、移行コストが膨大 ネットワーク環境や帯域の制約 こうした組織では、OOSが「あって当たり前の基盤」として組み込まれているため、廃止スケジュールを見落とすと思わぬ箇所でシステム障害が発生するリスクがある。特に「ドキュメントがブラウザで開けなくなった」という形で顕在化しやすく、エンドユーザーへの影響が直接的だ。 今すぐ確認・対応すべき事項： OOS稼働の有無を確認する — SharePoint Serverのドキュメントプレビューが機能しているなら、高確率でOOSが稼働中。サーバーリストと構成ドキュメントを今すぐ確認する Microsoftが公表した廃止タイムラインを把握する — Tech Communityの公式発表ページで具体的な日付を確認し、逆算して移行計画を立てる SharePoint Onlineへの移行可否を評価する — 法的・業務的制約を洗い出し、移行の障壁を明確化する。「無理」と決めつける前に、Microsoft Fasttrack（無償移行支援）の活用も検討する サードパーティの代替を検討する — 即座にクラウド移行できない場合でも、代替のドキュメントプレビューソリューション（WOPIプロトコル対応の製品など）を調査しておく SharePoint Server Subscription Editionのロードマップ確認 — OOS廃止後、オンプレSharePointのブラウザプレビュー機能がどう提供されるかをMicrosoftに確認する 筆者の見解 OOSの廃止は戦略的には理解できる判断だ。クラウド上のOffice for the Webが既に高品質で提供されている以上、オンプレ向けの並行製品をいつまでも維持し続けることにMicrosoftとしての合理性はない。 ...

Microsoft Teamsが2026年5月のアップデートで、AI通訳機能の品質向上と繁体字中国語サポートの追加を実施した。グローバル会議での実用性が一段と高まる一方、Teams Live Eventsの段階的廃止スケジュールも改めて明示され、移行対応が急務となっている。 AI通訳の品質向上：専門用語と人名の精度が改善 Teams会議のリアルタイム翻訳・通訳を担うAI通訳機能が、今回のアップデートで認識精度の大幅な改善を受けた。強化されたポイントは次の通りだ。 人名の認識精度向上: 参加者の名前などの固有名詞が、トランスクリプトや翻訳に正確に反映されるよう改善 業界専門用語への対応強化: 医療・法律・金融・テクノロジーなど各分野の専門用語が誤変換されにくくなった 繁体字中国語のサポート追加: 台湾・香港向けの繁体字中国語が新たに対応言語に加わり、アジア太平洋地域での活用シーンが広がった AI通訳は会議参加者それぞれが希望言語で音声通訳を受け取れる機能で、グローバルチームや国際会議での言語障壁を下げる役割を担う。人名の誤認識は議事録品質の低下に直結し、専門用語の誤訳はそのまま情報伝達ミスにつながるため、今回の改善は「参考程度」から「業務実用レベル」への重要な一歩といえる。 Teams Live Events廃止：移行スケジュールの全容 もう一つ見逃せない発表が、Teams Live Eventsの廃止スケジュールの再確認だ。 タイムライン 内容 2026年6月30日 新規Live Eventsのスケジュール不可 2027年2月 完全廃止（既存イベントも利用終了） Live Eventsはこれまで大規模ウェビナーや全社集会などに活用されてきたが、Microsoftはその後継としてTown Hallsを位置づけている。Town Hallsは最大1万人の参加をサポートし、Q&A・録画・配信機能も統合されている。 実務への影響 AI通訳の改善について 英語・日本語・中国語が混在する会議が日常的に発生するグローバル企業や外資系テクノロジー企業にとって、今回の精度向上は直接的なメリットになる。繁体字中国語サポートの追加は、台湾・香港拠点を持つ日系企業でもすぐに恩恵を受けられる変更だ。 Live Events廃止への対応 定期的な全社集会やウェビナーにLive Eventsを使っている場合、移行は早めに着手したい。以下の手順で準備を進めることを勧める。 既存Live Eventsの棚卸し ── 2026年6月末までに予定されているイベントをすべてリストアップする Town Hallsの機能検証 ── 社内リハーサルで配信品質やQ&A機能を事前確認する 外部参加者への告知方法の見直し ── URLや参加方法が変わるため、外部向け告知テンプレートも更新が必要 筆者の見解 AI通訳の精度向上は地味に見えるが、実務への影響は意外と大きい。専門用語や人名の誤認識が減るだけで、議事録の後補正にかかっていた時間が大幅に削減できる。こうした地道な改善の積み重ねが、AI通訳を「使ってみたけど微妙だった」から「普通に使えるもの」に変えていく。 Live Eventsの廃止については、Town Hallsという後継機能がある以上、実運用上の影響は限定的なはずだ。ただし、イベント運営ワークフロー自体がLive Eventsに最適化されている組織では、想定外の手戻りが発生することもある。移行期間を有効に使って検証を済ませておきたい。 MicrosoftはTeamsを会議・イベント・コラボレーションを一体化したプラットフォームへ進化させようとしており、AI通訳の品質改善はその方向性と一致している。統合プラットフォームとしての価値を最大化するには、こうした個々の機能が「使えるレベル」に達していることが前提条件になる。今回の改善はその条件をひとつ満たした、という評価が適切だろう。 出典: この記事は Empowering.Cloud Community Update – May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Exchange Server SE（Subscription Edition）向けに2026年5月のホットフィックスアップデート（HU）を公開した。今回のHUは単なるバグ修正にとどまらず、ハイブリッド環境におけるリッチ共存機能をExchange Web Services（EWS）からREST/Microsoft Graph APIへ移行するための新機能を含んでいる点が注目される。 今回のHUのポイント 通常、ホットフィックスアップデートは不具合修正が中心だが、今回は新機能の追加を伴う。具体的には、オンプレミスのExchange ServerとExchange Online間のリッチ共存機能——フリー/ビジー情報の共有、クロスプレミスのカレンダー参照、空き会議室検索など——の通信基盤を、これまでのEWSからMicrosoft Graph APIベースのREST通信へ切り替える準備が整えられた。 Exchange Server SEを最新のCU（累積更新プログラム）に維持している組織は、このHUを適用することでGraph API対応のハイブリッド共存に向けた移行パスを取れるようになる。 なぜ今EWSからGraph APIへ切り替えるのか EWSはExchangeエコシステムで長年使われてきたAPIだが、MicrosoftはExchange Online側でのEWSサポートを縮小してきた経緯がある。新規アプリへのEWSアクセスはすでに制限されており、長期的にはGraph APIへの一本化が方針だ。 ハイブリッド環境では、オンプレミスとクラウド間の連携にこのEWSが使われてきた。Exchange Online側の変化に追随するには、オンプレミス側もGraph APIに対応しなければならない。今回のHUはその橋渡しとなる。 Graph APIへ移行することで得られる主なメリットは次のとおりだ： 長期サポートの確保: MicrosoftがGraph APIに長期投資しており、将来の変更への追随が容易になる 認証セキュリティの強化: OAuth 2.0ベースの認証が標準となり、レガシー認証に依存するリスクが下がる Microsoft 365エコシステムとの整合: Teamsや他のM365サービスとの連携も同一基盤で扱いやすくなる 日本のハイブリッド環境への実務的影響 日本の大企業・中堅企業では、段階的なクラウド移行の過程でExchange Serverをオンプレミスに残したまま、一部メールボックスをExchange Onlineへ移行したハイブリッド構成を長期間維持しているケースが多い。 そうした環境では、フリー/ビジー情報の正確な表示や会議室予約のクロスプレミス動作が日常業務に直結しており、ここが壊れると現場への影響が大きい。今回のHUを適用することで、EWS廃止の流れに対応したハイブリッド構成の維持と延命が可能になる。 実務での活用ポイント 今すぐ確認すべきこと： HUの適用前提を確認する: Exchange ServerのHUはCUが最新であることが前提。まず現在のCUバージョンを確認する ハイブリッド接続方式の把握: Classic HybridとHybrid Agentのどちらを使っているかを確認し、Graph API対応への切り替え手順を事前に把握しておく Hybrid Agentのバージョン確認: Hybrid Agent経由の接続を使っている場合、エージェント自体も最新に保つ必要がある 中期的な計画として： EWS廃止の波はExchange Online側からやってくる。オンプレミスのExchange Serverを当面維持する予定の組織は、Graph APIベースのハイブリッド共存への移行ロードマップを今のうちに描いておくことを強く勧める。早めに準備した組織ほど、突発的な互換性問題のリスクを小さくできる。 筆者の見解 MicrosoftがExchange Server SEという形でオンプレミス製品を継続提供し、かつAPIレイヤーをモダン化するアップデートを着実に届けていることは評価できる。完全クラウド移行に時間のかかる日本のエンタープライズにとって、「使い続けられる道」を塞がずに技術的な健全性を保とうとする姿勢は、Microsoftがエンタープライズ市場で積み上げてきた強みそのものだ。 EWSからGraph APIへの移行は技術的には自然な進化だが、それをオンプレミス側にもきちんとバックポートしてくることに意味がある。現場の現実に向き合いながら、同時にモダンアーキテクチャへの道を開く——この両立こそMicrosoftが本来得意とするところであり、Exchange Server SEはその好例だと思う。 ただし、こうした対応には適切なタイミングでの適用が前提だ。「今動いているから触らない」という判断が続くと、EWS廃止のタイムラインに気づかないまま互換性問題に直面するリスクがある。定期的なCU・HUの適用と、Microsoft側のアナウンスを追い続ける運用習慣が、ハイブリッド環境を健全に保つ鍵になる。 ...

Microsoft（マイクロソフト）は、Microsoft 365 Apps管理センターのクラウドアップデート機能を大幅に刷新し、新しいプロファイル割り当て・チャンネル管理エクスペリエンスと「Update Health（更新の正常性）」機能を2026年5月〜6月にかけて順次展開することを発表した。大規模テナントを管理するIT管理者にとって、デバイス管理の運用フロー自体が変わる重要なアップデートだ。 何が変わるのか——新しいプロファイル割り当てエクスペリエンス これまでのクラウドアップデートは、プロファイルの管理とデバイスのチャンネル変更が別々の操作として分散していた。今回の刷新では、プロファイルへの割り当て＝チャンネル管理という形で一本化されるのが最大の変更点だ。 Microsoft Entraグループによる割り当て 新エクスペリエンスでは、クラウドアップデートのプロファイルはMicrosoft Entraグループ（旧Azure ADグループ）またはビルトインチャンネルグループへの割り当てによって有効化される。グループに含まれるデバイスが自動的にそのプロファイルの管理対象となり、まだ対象チャンネルにいないデバイスは自動的に移行される。 従来の「Inventoryの『Switch device update channel』コントロール」は廃止される。チャンネルを変更したい場合は、対象チャンネルのプロファイルにEntraグループを割り当てるという手順に統一される。 自動オフボーディング 注目すべき新機能のひとつが自動オフボーディングだ。すべてのプロファイル割り当てから外れたデバイスは、クラウドアップデートの管理対象から自動的に除外される。「意図しないデバイスがいつまでも管理対象に残り続ける」という運用上の悩みが解消される。 設定の集約——新しいSettingsページ 除外ウィンドウや除外グループなどのテナント共通設定が、クラウドアップデートナビゲーション内の専用「Settings」ページに集約される。これまで散在していた設定をまとめて確認・変更できるようになる。 既存テナントへの影響——移行は自動 すでにクラウドアップデートを利用しているテナントに対しては、以下の点が保証されている： 既存プロファイルは引き続き有効：追加設定なしで管理継続 自動マイグレーション：各プロファイルに対応するビルトインチャンネルグループが自動的に割り当てられる 既存設定の引き継ぎ：除外設定、ロールアウトウェーブ、一時停止・ロールバック設定はそのまま継続 新規テナントの場合は、少なくとも1つのEntraグループまたはビルトインチャンネルグループをプロファイルに割り当てるまで、プロファイルは非アクティブ状態のままとなる。 Update Health——更新トラブルの特定を効率化 2026年5月展開予定の「Update Health」は、テナント内のMicrosoft 365 Appsの更新に関する問題を特定・解決しやすくするための新機能だ。更新が正常に適用されているかどうかをプロファイル単位で把握でき、問題のあるデバイスの早期発見に役立つ。大規模テナントではアップデートの状況把握自体がコストになりがちだったが、この機能によってトラブルシューティングのサイクルが短縮されることが期待される。 実務への影響——IT管理者が今から準備すべきこと チャンネル変更の運用手順を見直す 「Inventoryからチャンネル変更」という手順は廃止される。既存の手順書やRunbookに「Switch device update channel」操作が含まれている場合は、Entraグループ割り当てベースのフローへの更新が必要だ。 Entraグループ設計の再確認 プロファイル割り当て＝チャンネル管理という構造になるため、どのデバイスをどのEntraグループに入れるかの設計が直接アップデートチャンネル管理に影響する。既存のグループ構造とチャンネル計画を照らし合わせておくことを推奨する。 自動オフボーディングの影響確認 意図的に「プロファイルなし」状態にしていたデバイスがある場合、その扱いが変わる可能性がある。管理対象に含めたいデバイスが除外されないよう、グループ割り当ての設計を事前に確認しておきたい。 ロールアウトタイミング 新プロファイル割り当て・チャンネルエクスペリエンス：2026年5月〜6月展開 Update Health：2026年5月展開 Microsoft 365 Roadmapで最新の展開状況を定期的に確認することを推奨する。 筆者の見解 今回の刷新は、地味ではあるが方向性として正しいアップデートだと感じている。「プロファイル管理」「チャンネル変更」「除外設定」がバラバラの場所に存在していた構造は、正直なところ管理者にとって使いにくかった。それをEntraグループ割り当てという一つの軸に統合したのは理にかなっている。 Microsoft 365は「統合して使ってこそ価値が出るプラットフォーム」だ。その観点からすると、管理ツール側も同様に統合されていなければ運用コストが膨らむ一方になる。今回の変更はその整合性を取りに行った動きとも読める。 一方で、既存テナントへの自動マイグレーションがどこまでスムーズに機能するかは、実際に展開が完了してからでないと評価しにくい。特に複雑なグループ構成や独自の除外設定を持つ大規模テナントでは、展開前後の動作確認を丁寧に行うことを強くお勧めしたい。変更が5〜6月に集中しているため、テスト用テナントでの先行確認を今から計画しておくのが賢明だ。 管理センターの使い勝手が改善されることで、IT管理者が本来注力すべき業務に時間を回せるようになる——Microsoft 365がそういう方向に着実に進化してくれることを期待している。 出典: この記事は New changes coming to cloud update - Microsoft 365 Apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月21日付のMicrosoft 365公式ロードマップ更新で、SharePoint上のAI引用分析機能（AI Citation Analytics）と、自然言語によるカレンダー管理を可能にする「Copilot Calendar Agent」を新たに追加した。いずれもCopilotの実用性と管理可視性を高める施策であり、現場での活用フェーズに踏み込んだアップデートといえる。 SharePoint AI引用分析：「Copilotは何を根拠にしているか」が見える時代へ SharePoint AI引用分析（AI Citation Analytics）は、Copilotが応答を生成する際にどのドキュメントをどのくらいの頻度で参照しているかを可視化する機能だ。 これまでCopilotの回答品質は「試してみないとわからない」部分が大きかった。特に企業内コンテンツを対象としたRAG（Retrieval-Augmented Generation）的な動作においては、参照先の偏りや古いドキュメントへの依存が問題になるケースもあった。この機能が実装されることで、IT管理者やコンテンツ管理者は「よく参照されているドキュメントはどれか」「逆に参照されていない情報資産はどれか」を把握できるようになる。 コンテンツガバナンスの観点でも意義は大きい。参照頻度の高いドキュメントが最新情報に保たれているかを優先的にレビューするワークフローを組むことが可能になり、「AIが古い情報を元に回答している」という典型的なリスクを組織的に管理できる。 Copilot Calendar Agent：自然言語でスケジュールを動かす 「来週の水曜日の午後に空きがあれば、1時間のミーティングを入れておいて」——そんな指示をCopilotに投げかけるだけでOutlookカレンダーを操作できるのが、Copilot Calendar Agentだ。 従来のCopilot in Outlookはメールの要約や返信文の生成が中心だったが、Calendar Agentはスケジュール管理そのものをエージェント的に処理する。空き時間の検出、招待の送信、既存予定との競合確認といった一連の作業を自然言語で指示できる点が特徴だ。 加えて、Microsoft Plannerとの統合も今回のロードマップに追加された。カレンダーとタスクの境界線が曖昧になりがちな日常業務において、「MTGをブロックしながら関連タスクをPlannerに作成する」といった連携が可能になれば、M365エコシステム内での作業完結性がさらに高まる。 実務への影響——IT管理者・現場エンジニアが押さえるべき点 コンテンツ棚卸しのトリガーにする SharePoint AI引用分析のデータは、社内ナレッジベースの見直しに活用できる。「参照頻度ゼロのドキュメント＝アーカイブ候補」という判断軸を加えることで、情報資産管理の優先順位付けが自動化に近い形で実現できる。 Calendar Agentの適用範囲を最初に決める カレンダー操作をAIに委ねる場合、どのカレンダーへのアクセスを許可するかを事前にポリシーで定義しておくことが重要だ。個人用・共有用・会議室リソースなど、スコープを明示することでエージェントの誤操作リスクを下げられる。 Planner統合はワークフロー設計のタイミング Calendar AgentとPlannerの連携が本格化するタイミングは、チームのタスク管理ルールを整理する好機でもある。既存のTo Doや手動でのPlanner運用と重複しないよう、誰がどこでタスクを管理するかを明文化しておきたい。 筆者の見解 AI引用分析は、Copilotを「使い始める」フェーズから「ちゃんと運用する」フェーズへの移行を支える機能として、個人的には高く評価している。導入後に「Copilotの回答、なんか信頼できない」という空気が現場に漂うのは、参照元の不透明さが原因であることも多い。可視化によってその霧が晴れるなら、現場の信頼醸成にも直結する。 Calendar Agentについては、実際の使い勝手が鍵になると見ている。自然言語によるカレンダー操作は技術的に面白いが、日本語の文脈理解の精度や、既存予定の優先度判断をどこまでこなせるかが実用性を決める。「使えるAIエージェント」か「デモ映えするだけの機能」かは、フィールドテストを経てみないとまだわからない。 M365全体の方向性として、単一機能の強化よりもこうした連携と可視性の充実に力を入れてほしいと思っている。Copilotを使いこなすための情報が増え、組織がより賢く制御できる環境が整うほど、M365というプラットフォームとしての底力が発揮されるはずだ。その意味で、今回のロードマップ更新は地味だが実質のある一歩だと評価している。 出典: この記事は Microsoft 365 Roadmap Updates - May 21, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年5月のメッセージセンター通知 MC1315220 で、Exchange Online 組織構成のオプション更新を発表した。この更新を適用すると、OWA（Outlook on the Web）のクライアントサイドDLPチェックが Exchange Online ベースの処理から、ワークロード横断型の データ分類サービス（Data Classification Services：DCS） に切り替わる。一見シンプルな近代化対応だが、既存の DLP ポリシーに Exchange 固有の条件が含まれている環境ではポリシーが意図どおりに動かなくなるリスクがある。 Exchange DLP の歴史と二層構造 Exchange Server 2013 で初めて実装された DLP は、メールがトランスポートパイプラインを通過する際にルールチェックを行う方式だった。この仕組みは Exchange 2019・Exchange SE でも現在も使われている。 Exchange Online ではこの基盤が Microsoft 365 へと引き継がれ、現在の Microsoft Purview DLP へと発展した。Purview DLP は今も Exchange Online のトランスポートパイプラインをバックストップとして使い、すべてのメールを通過させることでポリシー違反の検出と強制を担っている。 クライアントサイド（OWA・新しい Outlook・Outlook クラシック）でも、ユーザーがメールを作成する時点で DLP チェックを行い、DLP ポリシーヒントとして警告を表示する機能がある。ユーザーが送信前に内容を修正できるため、サーバー側での差し戻しを未然に防ぐ仕組みだ。 今回の変更：OWA のチェック主体が DCS へ MC1315220 が提案するのは、OWA のクライアントサイドチェックを Exchange Online から DCS（データ分類サービス） に切り替えることだ。DCS はすでに「新しい Outlook」でも使われており、Teams・SharePoint Online・OneDrive for Business など複数のワークロードで共通利用されるワークロード中立型サービスである。 ...

Microsoft は 2026 年 5 月 12 日に Microsoft Graph PowerShell SDK V2.37 をリリースした。しかしその裏では、SDK の生成パイプラインを支える中核ツール「AutoRest」の廃止予告が静かに掲示されており、M365 自動化に取り組む管理者・エンジニアに不安が広がっている。 Microsoft Graph PowerShell SDK V2.37 の概要 V2.37 は 5 月 12 日のリリース以降、現時点では安定して動作しているとの報告が多い。ただし、いきなり本番環境へ展開するのは禁物だ。まずワークステーション環境で主要スクリプトをテストしてから段階的に展開するのがベストプラクティスとなる。 特に Azure Automation のランタイム環境を利用している場合は注意が必要だ。SDK モジュール間には Microsoft.Graph.Authentication モジュールへの依存関係があるため、同一のランタイム環境内に異なるバージョンのモジュールを混在させることはできない。たとえば、Microsoft.Graph.Authentication が V2.36.1 の環境に Microsoft.Graph.User.Actions の V2.37 だけをインストールしようとしてもエラーになる。すべてのモジュールを同一バージョンに統一することが前提となる。 ダウンロード数が示す普及の加速 前バージョンの SDK V2.36.1 のダウンロード数は 104 万回超を記録した。旧来の AzureAD モジュールおよび MSOnline モジュールの廃止に伴い、代替手段として SDK への移行が本格化した結果だ。SDK をベースとした Entra モジュール（v1.2.0）もさらに約 30 万ダウンロードを積み上げており、Microsoft の認証・認可系 PowerShell エコシステムが SDK 中心へと集約されつつあることがよくわかる。 AutoRest 廃止問題——自作自演の混乱 2026 年 2 月 27 日、Microsoft は GitHub リポジトリ上で AutoRest の廃止予告を静かに掲示した。廃止予定日は 2026 年 7 月 1 日だ。 ...

Microsoft は 2026年5月14日のメッセージセンター通知（MC1310672）で、Search-UnifiedAuditLog PowerShell コマンドレットの動作変更を発表した。新プロパティ AuditSearchRequestMetadata.moreRecordsAvailable が追加され、最大50,000件の監査レコードを取得する大規模検索がより正確に制御できるようになる。世界商用テナントへの展開は2026年5月末を目標に進行中で、政府クラウドは2026年6月に対応予定だ。 何が変わったのか ResultCount プロパティの仕様変更（既存スクリプトへの影響大） 従来、ResultCount プロパティは「その検索で返されるレコードの総数（見込み件数）」を示していた。今回の変更後は 「取得済みレコードの累積数（ランニングカウント）」 に意味が変わった。 ResultCount を使って「全レコードを取り終えたかどうか」を判定しているスクリプトは、今回の変更で動作が変わる。Microsoft Sentinel や Splunk への定期エクスポートなど、本番運用スクリプトを持つ環境では早急な確認が必要だ。 新プロパティ: moreRecordsAvailable 代わりに使うべき新プロパティが AuditSearchRequestMetadata.moreRecordsAvailable だ。 false → 条件に一致する追加レコードなし（取得完了） true → まだ取得すべきレコードが残っている シンプルなブール値で終了判定ができるため、ループ制御がより明示的かつ堅牢になる。 実装例：moreRecordsAvailable を使った大規模検索 出典: この記事は Search-UnifiedAuditLog Updated to Make Large Searches Easier to Manage の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月1日、AIエージェントのガバナンス基盤「Microsoft Agent 365」を正式リリースした。IT部門の承認なく社員が独自に展開した「シャドーAIエージェント」を発見・可視化・制御するコントロールプレーンとして、月額15ドル/ユーザー（またはM365 E7に同梱）での提供が始まった。 シャドーAIという「加速するシャドーIT」 2026年時点で、ナレッジワーカーの78%が週1回以上AIエージェントを利用しているという。2024年の12%からの急増が示すのは、普及とガバナンスの深刻な乖離だ。 MicrosoftのWork Trend Index 2026は、AIの成果に与える影響の67%が「組織側の要因」であり、個人利用の寄与は32%に過ぎないと指摘している。ツールを渡すのは簡単だが、その後の管理こそが本質的な課題だ。 10年前に企業を悩ませた「シャドーIT」——社員が勝手にDropboxを使い、Slackを未承認導入し、個人SaaSを会社デバイスで使う問題——の2026年版が、さらに速いスピードで進行している。エージェントベースツールが社員のラップトップにインストールされ、ITチケット一枚なしにCRM・人事データベース・財務システムと接続されていく。 未承認のAIエージェントが機密データへの読み取りアクセスを持つリスクは、未承認プロジェクト管理ツールとは次元が違う。そしてAIエージェントの採用曲線は指数関数的に伸びる一方、ガバナンス整備は線形——存在しないケースすら多い——という構造問題が根底にある。 Microsoftのデータでは、AI戦略をトップダウンで明確に定めている組織はわずか25%。残り75%は、エージェントがルールなしに本番環境で動いている状態だ。 Agent 365の実態：3つのコア機能 Agent 365はエージェントビルダーではない。すでに組織内で動いているエージェント——社内開発、ベンダー製、誰かが黙って先週インストールしたものも含め——を統制するためのコントロールプレーンだ。 1. 発見とインベントリ管理 管理センターに専用の「Shadow AI」ページが設けられ、ITの監視外で動くエージェントをエンドポイントスキャンで検出できる。サードパーティ製エージェントツールもマネージドデバイス上で検知し、中央レジストリに登録する。多くの組織がまったく手をつけていない「現状把握」がここから始まる。 2. ID・アクセス管理（Microsoft Entra連携） Agent 365はMicrosoft EntraのIDガバナンスをAIエージェントに拡張する。人間ユーザーに適用してきた最小権限の原則が、エージェント（Non-Human Identities）にも適用される。カスタマーサポートのチケットを読むだけのエージェントが、財務データへのアクセスを持つ必要はない——当たり前の話だが、現実には多くのエージェントが作成者と同等の権限を持ったまま動き続けている。 3. データガバナンス（Microsoft Purview連携） Purviewとの統合により、機密タグが付いたデータへのエージェントアクセスをポリシーで制御できる。これはAIエージェントのセキュリティリスクの中で最も頻発するパターン——広範なアクセス権を持つエージェントが機密データを不適切なコンテキストに引き込む問題——を直接解決する。 2026年6月にパブリックプレビュー予定の追加機能 コンテキストマッピング: エージェントとエンタープライズシステム間のデータフローを可視化 ランタイムブロック: 動作中のエージェントをリアルタイムで停止 実務への影響——日本のIT管理者がやるべきこと 今すぐ確認すべき3点: 社内で稼働中のAIエージェントを棚卸しする — おそらく把握していないものが複数存在する M365ライセンスでAgent 365が含まれるか確認する — E7バンドルか、単体購入（$15/ユーザー/月）かを把握する Entra・Purviewの既存ポリシーをエージェント対応で見直す — NHI（Non-Human Identities）の権限設計を人間アカウントと同等の厳しさで整備する 見落としがちなポイント: 「エージェントを禁止する」アプローチは機能しない。シャドーITへの禁止令が失敗し続けてきたのと同じ理由だ。公式ルートで提供されるものが最も便利に使える環境を作ることが、ガバナンスの唯一の正解に近い。 筆者の見解 シャドーAIの問題は、日本企業にとってシャドーITより遥かに速く、遥かに深く侵食する。セキュリティ分野は細かい議論が多くて得意ではないが、この問題の構造は明快だ。 Agent 365のアプローチが評価できるのは、「禁止」ではなく「管理可能にする」方向性を選んでいる点だ。EntraやPurviewという既存のIDガバナンス基盤をエージェントに横展開する設計は、M365を中心に構築してきた企業には素直なメリットがある。バラバラに使うのではなく統合して使うことで価値が出るプラットフォームとしての一貫性がある。 NHI管理はこれまで「面倒な付帯作業」として後回しにされがちだったが、AIエージェントが業務に深く入り込む以上、これを整備しないと自動化も進まない。業務効率向上の観点でも、今こそ向き合うべきタイミングだ。 月額15ドル/ユーザーのコスト正当化は各社の判断になるが、E7を検討している組織には実質的に含まれる。「何体のエージェントが今どんな権限で動いているかわからない」状態を解消するだけで、セキュリティ監査への備えとしての価値は十分ある。M365の統合プラットフォームとしての本領を、AIエージェントのガバナンス領域でも発揮してほしい。そう期待できる製品だ。 出典: この記事は Microsoft Agent 365: The AI Agent Security Gap Enterprises Can’t Ignore の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Copilot StudioとAzure AI Foundryを横断したAIエージェントの管理・ガバナンスベストプラクティスをまとめた公式ホワイトペーパーを最新版「v3.2」に更新し、IT管理者・セキュリティ担当者向けの統制指針を刷新した。 エージェントガバナンスホワイトペーパー v3.2 とは MicrosoftのCopilot Studio Blogで公開された本ホワイトペーパーは、企業がMicrosoft 365環境にAIエージェントを展開する際のガバナンス課題に正面から向き合ったドキュメントだ。バージョン3.2の更新では、以下の領域が体系的にカバーされている。 Copilot Studioエージェントの管理ポリシーとアクセス制御 Azure AI Foundryで構築されたカスタムエージェントの統制指針 両プラットフォームを横断したエージェントのライフサイクル管理 Microsoft PurviewのDLP（データ損失防止）ポリシーとの統合 監査・ログ記録のベストプラクティス なぜいまガバナンスフレームワークが必要なのか AIエージェントは「使って終わり」の単機能ツールではない。外部サービスと連携し、ユーザーの代わりに操作を実行し、機密データにアクセスする「Non-Human Identity（NHI）」として動作する。従来のSaaSアプリ管理とは根本的に異なる性質を持っており、既存のITガバナンスの枠組みをそのまま適用しても機能しない。 具体的には以下のリスクが顕在化しやすい。 エージェントに付与されたアクセス権限の範囲が管理者に把握されていない 誰がどのエージェントを作成・展開したかの追跡が困難 エージェントが参照するデータソースと機密分類の整合性が取れていない インシデント発生時に原因を追跡する手段がない v3.2はこれらの課題に対し、Microsoft Entra IDやMicrosoft Purviewとの連携を軸にした実践的な対応策を示している。 Copilot Studio と Azure AI Foundry の二層構造に対応した設計 今回の更新で特筆すべきは、2つのプラットフォームの違いを意識した「段階的なガバナンス設計」が明示された点だ。 Copilot Studioはビジネスユーザー向けのローコード環境で、Teamsやブラウザから手軽にエージェントを作れる。その手軽さゆえ、IT部門の管理が届かない場所でエージェントが増殖する「シャドーAI」が起きやすい。 Azure AI Foundryは開発者向けのフルスタック環境で、カスタムモデルの呼び出しや複雑なオーケストレーションが可能だ。その分、アクセス権限の設計が複雑になり、ミス時の影響範囲も大きい。 両者を同一ポリシーで管理しようとすると、オーバーキルになる部分と穴が生じる部分が混在する。ホワイトペーパーでは利用シナリオとリスクレベルに応じた段階的な適用を推奨しており、この整理は現場感覚に合っている。 実務での活用ポイント 1. まず現状の棚卸しから Microsoft 365管理センターとEntra管理センターで、現在組織内に存在するCopilot Studioエージェントの一覧を取得する。把握されていないエージェントが稼働しているケースは想像以上に多い。 2. Minimum Privilege原則をエージェントにも徹底 エージェントに付与するアクセス権は業務上必要な最小限に絞る。「広めに設定しておけば後で困らない」という発想がリスクの温床になる。 3. 既存DLPポリシーのエージェント対応確認 現行のDLPポリシーがAIエージェントの操作をカバーしているかを確認する。外部コネクタを使うCopilot Studioエージェントは特に要注意だ。 4. Purviewで監査ログを確保 エージェントの操作ログを一定期間保持する設定を事前に入れておく。インシデント時の初動対応で天と地の差が出る。 5. ホワイトペーパーをチームで共有する IT管理者だけが把握しても機能しない。エージェントを展開するビジネスユーザーやPower Platform担当者にも共有し、組織全体のリテラシーを底上げすることが不可欠だ。 筆者の見解 AIエージェントのガバナンスは、「気づいたら手遅れ」になりやすい領域だ。Copilot Studioのローコード性はAI普及を加速させる一方、IT部門の管理が届かない場所でエージェントが増え続けるリスクを同時に生む。 ...

Microsoft が Microsoft Planner の大規模刷新を2026年に実施する。タスクへのチャット機能、カスタムテンプレート、Copilot AI統合の3つの新機能を追加する一方、iCal（iCalendar）フォーマットのサポートを廃止する予定で、カレンダー連携を利用しているユーザーは早急な移行対応が求められる。 Microsoft Planner 2026年刷新の全容 タスクチャット機能 新たに追加される「Task Chat（タスクチャット）」は、各タスクの中でメンバーと直接会話できる機能だ。これまでPlannerを使うチームは、タスクの詳細について別途Teamsのチャットやメールでやりとりしなければならず、「どのタスクについての話か」という文脈がすぐに失われる課題があった。 タスクチャットが実装されることで、タスクとコミュニケーションが一体化される。誰が何を発言したかの履歴がタスクに紐づいて残るため、後から参加したメンバーがキャッチアップしやすくなる点もメリットだ。 カスタムテンプレート 「Custom Templates（カスタムテンプレート）」機能により、組織独自のプロジェクト計画テンプレートを作成・保存・再利用できるようになる。毎回ゼロから作っていたプロジェクト計画をテンプレート化することで、スタート時のセットアップ工数を大幅に削減できる。特に繰り返し型のプロジェクト（月次業務、リリースサイクル管理など）を多く抱えるチームには即効性が高い機能だ。 Copilot AI統合 Copilot AI との統合により、タスクの提案、進捗のサマリー、次のアクション自動生成といった機能が Planner 内に統合される予定だ。プロジェクト管理の定型的な判断をCopilotが補助する形となる。 iCalサポートの廃止 特に注意が必要なのが「iCal（iCalendar）フォーマットのサポート廃止」だ。PlannerのタスクをGoogleカレンダーやAppleカレンダーへ購読するために使われてきたiCal形式のURLのサポートが終了する。既存の購読リンクは無効になるため、現在利用しているユーザーは代替手段への移行が必要になる。 日本のエンジニア・IT管理者が今すぐやるべきこと iCal廃止への対応（最優先） iCalの購読リンクを社内でどこが利用しているかを今すぐ調査してほしい。特に以下のシナリオで使われているケースが多い： 外部ツール連携: GoogleカレンダーやAppleカレンダーとPlannerを連携している 社内ダッシュボード: Power BIや社内ポータルにPlannerのタスクをカレンダー表示している サードパーティ製PMツール連携: iCalフィードを受け取るタイプのツールとの連携 廃止前に代替手段（Microsoft Graph API経由のカレンダー連携、Outlookカレンダーとの直接同期）を検証し、移行計画を立てることを強くお勧めする。 タスクチャットの活用ルールを先に決める タスクチャットはTeamsのチャットとの住み分けが鍵になる。「プロジェクトのタスクに関する会話はPlannerのタスクチャットへ」「日常的な雑談や素早い確認はTeams」という使い分けをチーム内でルール化することで、情報の散逸を防ぐことができる。機能がリリースされてから「どこに書けばいいのか」が曖昧になるよりも、事前にルールを決めておく方が定着は早い。 テンプレート整備の準備を今から カスタムテンプレート機能がリリースされた際にすぐ活用できるよう、「自チームで繰り返し使っているプロジェクト計画の型」を今のうちに洗い出しておこう。候補リストを準備しておくだけで、機能リリース直後から業務効率を引き上げるスピードが変わる。 筆者の見解 今回のPlannerの刷新は、Microsoft が「タスク管理をTeams・Outlook・Loopと統合された体験にしていく」という方向性の一環として見ている。タスクチャットはその象徴的な機能で、バラバラになりがちなコミュニケーションとタスクを一体化する方向性は正しい。 Copilot AI統合については、正直なところ「どこまで実用的になるか」を見極める段階だ。タスク管理AIに本当に必要なのは機能の網羅性よりも「現場で使い物になる精度」だと思っている。Microsoftにはその技術力があるはずで、具体的なシナリオで精度を出せるかどうかに注目したい。 iCalの廃止は移行コストが発生するのは避けられないが、長期的にはMicrosoft 365エコシステム内で一貫した連携体験に集約されていく方が全体最適につながる。「標準の仕組みで動いている前提」を崩さないよう、移行は計画的に進めてほしい。 Plannerはこれまで「軽量タスク管理ツール」として中途半端な立ち位置にあった印象があるが、今回の刷新でTeams・Outlook・Loopとの統合が深まれば、Microsoft 365の中核的なワークフロー基盤になり得る可能性を秘めている。その可能性を本当に引き出せるかどうか、今後のロードマップに注目している。 出典: この記事は Microsoft Planner 2026 Overhaul: Task Chat, Custom Templates, Copilot AI, iCal Retirement の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは5月12日、Agent 365に関するAMA（Ask Me Anything）セッションを開催し、AWS BedrockおよびGoogle CloudとのAIエージェントレジストリ同期がパブリックプレビューへ移行したことを正式に発表した。異なるクラウド上で稼働するAIエージェントをMicrosoft 365の管理基盤から横断的に制御できる体制が、いよいよ試せる段階に入った。 Agent 365とは何か？ Agent 365は、Microsoft 365エコシステム内でAIエージェントを作成・展開・管理するためのプラットフォームだ。Copilot Studioで構築したエージェントはもちろん、外部クラウドで動くエージェントとの連携も射程に入れている。 今回のAMAでは製品チームが参加者からの質問に幅広く回答し、ロードマップや現在の制限事項なども共有された。 最大のニュース：AWS Bedrock・Google Cloudとのレジストリ同期 今回のアップデートで最も注目すべきは、AWS BedrockおよびGoogle CloudのAIエージェントとのレジストリ同期がパブリックプレビューに移行した点だ。 これが意味するのは、クラウドをまたいで稼働するAIエージェントを、Microsoft 365の管理コンソールから一元的に把握・管理できるようになるということだ。 従来、企業がAIエージェントを活用しようとすると： Microsoft Copilot / Copilot Studioで構築したエージェント AWS Bedrockで動くエージェント Google Cloud上のエージェント これらはそれぞれ別々の管理コンソールで扱うしかなかった。セキュリティポリシーの統一適用やアクセス権管理もバラバラで、IT管理者にとっては頭痛の種だった。Agent 365のレジストリ同期は、この分断を緩和する。どのクラウドで動くエージェントなのかを問わず、Microsoft 365側からディスカバリー・管理できる統一レイヤーを提供しようとしている。 ライセンスと価格 Agent 365のスタンドアロンライセンスは月額15ドル/ユーザー。Microsoft 365のサブスクリプションとは独立して購入できる形態も用意されている。 なお、マルチクラウドのエージェントレジストリ同期を活用する場合、各クラウド側のエージェントサービスコストは別途かかる点には留意が必要だ。 実務への影響 — 日本のエンジニア・IT管理者に何が変わるか マルチクラウド環境の管理コストが下がる可能性 日本の大企業でも「Microsoft 365を中核に置きつつ、AWSやGoogle Cloudも使う」というマルチクラウド構成はもはや標準的だ。AIエージェントをこうした環境に展開するとき、Agent 365のレジストリ同期は管理の統一化という観点で有用になりうる。 ガバナンスの観点 AIエージェントが乱立する組織では、「どのエージェントが何にアクセスできるか」の把握が急務だ。エージェントのレジストリを一元管理できれば、セキュリティ審査や監査の作業が大幅に楽になる。特に金融・医療・官公庁系など厳しいガバナンスが求められる業種では、この可視化レイヤーの価値は大きい。 今すぐ確認すべきこと テナントのAgent 365設定を確認する: Microsoft 365管理センターのAgent設定ページから機能が有効化できるか確認する Copilot Studioとの連携ポイントを把握する: 既存のCopilot Studioフローと統合できる部分を洗い出す AWS / Google Cloud側の準備: BedrockやVertex AIで動かしているエージェントがある場合、レジストリ同期の要件を満たしているか事前確認する パブリックプレビューの早期評価: 本番適用前の検証フェーズとして、今のうちに試験環境で動作確認を進めておくことを勧めたい 筆者の見解 マルチクラウドのエージェントレジストリ同期という方向性は、率直に言って理にかなっていると思う。AIエージェントの時代に「自社クラウドのエージェントしか管理できない」では、企業の現実に即していない。MicrosoftがここでAWSやGoogle Cloudとのオープンな連携を選んだことは、プラットフォームとしての競争力を維持する上で必要な判断だ。 ...

Microsoftは2026年6月中旬から7月末にかけて、SharePointのユーザーインターフェースを大幅に刷新した「新SharePointエクスペリエンス」を段階的に展開する。アプリバーの全面再設計と開始ページの刷新が目玉で、AIを活用したコンテンツ作成支援機能も同時に提供される。 新アプリバーの構成：5つのアイコンで業務を整理 新しいSharePointアプリバーには、左端から以下の5つのアイコンが並ぶ。 組織のホームサイト：グローバルナビゲーションが設定されている場合のみ表示。イントラネットのトップページへのクイックアクセスとして機能する Discover：自分に関連するサイト・コンテンツ・ニュースをパーソナライズして表示するビュー Publish：組織全体に向けたコミュニケーションやページを作成・共有するための拠点 Build：サイト・リスト・ドキュメントライブラリ・エージェントを作成・管理する場所 OneDrive：個人ファイルへのクイックアクセス 現行のアプリバーと比べると、機能ごとの役割分担が明確になっている。特に「Publish」と「Build」の分離は、コンテンツを公開する人と、基盤を構築・管理するIT担当者の役割の違いを UI レベルで整理した設計と言える。 AI支援機能：自然言語でグラフ作成、Copilot引用の可視化 今回のリニューアルと同時期に展開される AI 関連機能として、以下の2点が注目される。 AIチャートWebパーツ SharePointページ上で、自然言語の指示からインタラクティブなグラフを生成できる新Webパーツが追加される。データを別ツールに持ち出してグラフ化する手間なく、ページ内で完結できる。 AI Citations Analytics（AI引用分析） 組織内のどのSharePointドキュメントが、Copilotの回答に引用されているかを可視化する機能。「どのドキュメントが実際に使われているか」「古い情報が引用されていないか」を把握するための管理者向けツールとして機能する。 なお、AI支援による作成機能の一部はCopilotプレミアムライセンスが必要となっている点は留意が必要だ。 展開スケジュールと管理者が確認すべきこと 当初は2026年5月上旬からの展開が予定されていたが、現在は2026年6月中旬〜7月末に変更されている。大規模テナントへの展開は遅い方のタイミングになる可能性が高い。 Microsoft 365管理センターのメッセージセンター（MC1240699）および365ロードマップID 547732で展開状況を確認できる。グローバルナビゲーションを設定していないテナントではホームサイトのアイコンが表示されないため、組織ナビゲーションの整備状況も事前に確認しておきたい。 実務への影響：IT管理者・エンジニアが今やるべきこと 1. グローバルナビゲーションの設定状況を確認する 新アプリバーの最初のアイコン（組織ホームサイト）は、グローバルナビゲーションが設定されていないと表示されない。展開前にSharePoint管理センターでホームサイトとグローバルナビゲーションの設定を確認・整備しておくと、ユーザーへの影響を最小化できる。 2. エンドユーザー向けのコミュニケーションを事前に準備する UIが大きく変わるため、「突然変わった」という混乱を避けるためのインターナルコミュニケーションが重要。変更時期のアナウンス、新しいナビバーの使い方説明、Yammer・Teamsでの周知など、展開前に準備を進めておきたい。 3. AI Citations Analyticsでコンテンツ品質を評価する Copilotを導入済みのテナントであれば、AI引用分析は「組織の知識資産のヘルスチェック」として活用できる。引用頻度の高いドキュメントは最新状態に保ち、古い情報が多く参照されていないかを定期的に確認するワークフローを組み込むと良い。 4. Publish/Build の役割分担をチームに周知する 「誰がどのアイコンを使うのか」を事前に整理しておくと、展開後の混乱が減る。コンテンツ編集者は主にPublish、IT管理者・サイトオーナーはBuildを使う、という役割整理をドキュメント化しておくことを勧める。 筆者の見解 SharePointのUI刷新は「ようやく」という印象だ。現行のアプリバーは機能が増えるたびに場当たり的に追加された感があり、初めてSharePointを使うユーザーには直感的ではなかった。Discover・Publish・Buildという役割ベースの整理は、情報アーキテクチャとして正しい方向性だと思う。 AI Citations Analyticsは地味に見えて、実は実用性が高い機能だ。「Copilotが何を参照して回答しているか」はブラックボックスになりがちだった。これが可視化されれば、コンテンツ管理の優先度をデータで判断できるようになる。イントラネット担当者には刺さる機能だろう。 ただ、今回の機能の多くが「Copilotプレミアム必須」という壁に阻まれている点は、正直もったいないと感じる。SharePointはM365の土台であり、AI機能をその土台に統合することはMicrosoftにしかできない強みのはずだ。ライセンスの敷居が高いと、その強みを活かせる組織が限られてしまう。SharePoint自体の競争力を高めるためにも、基礎的なAI統合はより広いライセンス層で使えるように展開を広げてほしいというのが率直な期待だ。 UIリニューアルと合わせて、今こそSharePointのコンテンツ整備・情報設計を見直す好機でもある。展開を待つだけでなく、自組織のSharepoint活用状況をこの機会に棚卸ししてみてはどうだろうか。 出典: この記事は New SharePoint experience (2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月15日、MicrosoftはMicrosoft TeamsウェブアプリへのアクセスにECMAScript 2022（ES2022）準拠ブラウザを必須要件として適用開始した。対象外ブラウザからのTeams Webアクセスはこの日からブロックされる。デスクトップクライアントおよびモバイルアプリへの影響はない。 ECMAScript 2022とは何か ECMAScript（ES）は、JavaScriptの動作仕様を定める国際標準規格（ECMA-262）だ。2022年版ではクラスのプライベートフィールド宣言、Array.prototype.at()、Object.hasOwn()、Top-level await など、現代的なWebアプリ開発に不可欠な機能が正式に仕様化された。 Microsoft TeamsのWebアプリはReact/TypeScriptベースの大規模SPAであり、こうした最新JS仕様を活用することでコードの簡潔化・パフォーマンス向上が見込める。今回の要件変更は、Webアプリの内部実装を近代化するうえで避けられないステップといえる。 影響を受けるブラウザバージョン ES2022への非準拠が確認されている主なブラウザバージョンは以下のとおりだ。 ブラウザ 影響を受けるバージョン Google Chrome 94以前 Microsoft Edge 94以前 Mozilla Firefox 93以前 Safari 15.4以前 自動更新が有効な一般的なWindows 10/11環境やmacOS環境であれば、現時点ですでに対応済みのバージョンが動作しているはずだ。問題が起きやすいのは、以下のような管理下環境だ。 グループポリシーやMDMでブラウザの自動更新を意図的に無効化している環境 共有PC・キオスク端末など、管理者が手動でバージョン管理している端末 Internet Explorerの互換モードを常用しているレガシーイントラネット環境（EdgeのIEモードはChromium版Edgeのバージョンに依存するため、Edgeが古ければ同様に影響を受ける） なぜ今、この変更が重要か Teams Webアプリは、デスクトップクライアントのインストールが制限されているシンクライアント環境・Chromebook・Linuxマシンでの主要アクセス手段だ。このような端末はOSやブラウザの更新管理が手薄になりがちであり、今回の変更で突然Teams Webに繋がらなくなるケースが国内企業でも発生する可能性がある。 特に日本では「動いているから大丈夫」という運用が続いているレガシー端末が現場に残っていることも多い。今回の変更はそういった環境に対して、ブラウザ管理ポリシーを見直す契機となる。 実務での対応ポイント 1. Intuneを使ったブラウザバージョン棚卸し Microsoft Intune（Endpoint Manager）を運用している環境であれば、デバイスレポートからブラウザバージョンを一覧抽出できる。「Chrome 94以前」「Edge 94以前」に該当する端末を洗い出し、優先的に更新計画を立てよう。 2. Teamsデスクトップクライアントへの移行検討 Teams Webを使っている主な理由がインストールポリシーの制約であれば、この機にTeamsデスクトップクライアント（新クライアント）への移行を検討する価値がある。デスクトップ版はブラウザのES仕様に依存せず、パフォーマンスも優れている。 3. 先手を打った社内周知 「Teams Webが突然使えなくなった」というヘルプデスクへの問い合わせ急増を防ぐため、社内ポータルや一斉メールで事前周知を行っておくことを強く勧める。IT部門が把握していても現場に伝わっていないケースが多い。 筆者の見解 今回のES2022要件化は技術的に筋の通った判断だ。ES2022は策定から4年が経過しており、モダンブラウザへの準拠はとっくに完了している。Microsoftがこのタイミングでレガシーブラウザのサポートを切ること自体は、むしろ遅すぎたくらいだと思う。 ただ、気になるのはエンタープライズ向けの変更告知の質だ。大企業ほど、ブラウザのバージョン管理は複数部署をまたぐ調整が必要になる。Message CenterやAdminポータルでの通知が十分早期かつ明確だったかどうか——この点は今後も改善を期待したい。Microsoftにはエンタープライズ対応力という強みがあるのだから、告知の丁寧さでもその強みを発揮してほしい。 日本のIT現場に目を向けると、こうした「要件変更に気づかず突然使えなくなる」という事態は、エンドポイント管理が属人化している組織で起きやすい。Intuneによる一元管理へ移行できていない場合、このような変更のたびに現場が混乱することになる。今回の件を棚卸しのきっかけにしてほしい。 出典: この記事は Microsoft Teams on the web requires ECMAScript 2022 compliant browsers from May 15, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年7月1日より、Microsoft 365商用プランの価格を改定する。エンタープライズ・ビジネス・フロントラインの各スイートおよびスタンドアロンコンポーネントが対象で、値上げ幅は最大43%に達する。既存ユーザーは更新時まで現行価格が維持されるが、購買・IT担当者は早急な対応が求められる。 改定の全体像：誰が最も影響を受けるか 今回の価格改定は大きく3つのセグメントに分かれる。 エンタープライズスイート Teams同梱版の改定は以下の通り（ユーザー/月、USD）。 SKU 旧価格 新価格 変動率 Office 365 E1 $10.00 据え置き — Office 365 E3 $23.00 $26.00 +13% Office 365 E5 $38.00 $41.00 +8% Microsoft 365 E3 $36.00 $39.00 +8% Microsoft 365 E5 $57.00 $60.00 +5% E3系のパンチが重い。1,000ユーザー規模の企業がOffice 365 E3を使っている場合、年間コストは約3,600ドルの増加になる。 スタンドアロンでは、Microsoft 365 Apps（ユーザーライセンス）が$12→$14（+17%）、Entra Plan 1が$6→$7（+16%）と、単品での調達コストも上がる。Windows E3も$6.63→$7.63（+15%）で、デバイスライセンスの積み上げ企業にも影響が出る。 Frontlineスイート：最大43%増の衝撃 製造・小売・医療などの現場系ユーザー向けFrontlineプランの値上げ幅が突出している。 SKU 旧価格 新価格 変動率 Microsoft 365 F1 $2.25 $3.00 +33% Microsoft 365 F3 $8.00 $10.00 +25% F1（no Teams） $1.75 $2.50 +43% ...

Microsoft TeamsにおけるOffice 365コネクタ（Office 365 Connectors）が、2026年5月18日をもって完全廃止となる。長期間にわたって廃止予告が続いてきた機能だが、いよいよ期限が目前に迫った。外部サービスとのWebhook連携や通知を利用していた組織で移行が完了していない場合、同日以降は通知が一切届かなくなる。 Office 365コネクタとは何だったのか Office 365コネクタは、Teamsチャンネルに外部サービスからの通知やアラートを直接投稿できる機能だ。GitHubのプッシュ通知、JiraやAzure DevOpsのチケット更新、CI/CDパイプラインのビルド結果など、さまざまな開発・業務ツールをTeamsと繋ぐ手段として2016年頃から広く活用されてきた。 Incoming Webhook（着信Webhook）を使ったカスタム通知も同様の仕組みに依存しており、監視システムや業務自動化スクリプトとの連携を担ってきた組織は少なくない。 何が変わるのか 5月18日以降、Office 365コネクタ経由で設定されたすべての連携が機能停止する。既存の設定は無効化され、新規設定も不可能になる。 Microsoftが提示する移行先は主に2つだ。 1. Power Automate（推奨） Microsoft純正のローコード自動化ツール。Teams連携テンプレートが豊富に用意されており、既存コネクタ連携の多くをフローで再構築できる。ただし、ライセンス構成によっては追加コストが発生する点に注意が必要だ。 2. Incoming Webhook（移行版） Teamsには廃止されるコネクタ版とは別の、より新しいIncoming Webhookの仕組みが提供されている。カスタム通知の送信には引き続き利用可能だが、URLスキームや設定手順が変わるため、既存スクリプトの修正が必要になる。 実務への影響——日本のIT管理者・エンジニアへ まず今すぐやること 1. 影響範囲の確認 Teams管理センター（teams.microsoft.com/admin）で、コネクタを利用しているチャンネルを棚卸しする。管理センターからだけでは把握しきれない場合、開発チームへのヒアリングが欠かせない。 2. 開発チームへの確認 CI/CDツール（Jenkins、GitHub Actions等）からTeamsへの通知が来ている場合は要確認。運用担当が独自に設定したWebhookが「誰も把握していない状態」で稼働しているケースが多い。廃止後に「通知が来なくなった」と問題が顕在化する典型パターンだ。 3. 移行先の選定と実装 ユースケース 推奨移行先 GitHubプッシュ通知 GitHub Actions + Incoming Webhook CI/CDビルド結果通知 ビルドシステムのWebhook設定変更 監視アラート（Zabbix等） Power Automate HTTP Trigger カスタム業務通知スクリプト Incoming Webhook（URL再発行が必要） 少数の通知であればIncoming Webhookへの移行で十分対応できる。複雑なフロー制御や条件分岐が必要なケースはPower Automateを選択したい。 筆者の見解 今回の廃止自体は、長期的に見て理にかなった判断だと思う。Office 365コネクタは2016年頃の機能であり、Power Platformが充実した現在、統合管理の観点から刷新は自然な流れだ。告知から廃止まで時間も十分にあった。 ただ、こうした廃止予告がM365全体で積み重なることで、IT部門の疲弊感が増しているのも事実だ。「また廃止か」という声は現場から頻繁に聞こえる。変更の告知精度と移行支援ドキュメントの充実は、今後も継続して改善してほしいところだ。Microsoftにはそれができる組織力があるのだから、ここは丁寧にやってほしい。 ポジティブな側面として、Power Automateへの移行は単なる代替手段にとどまらない。コネクタで「通知を受け取るだけ」だった連携を、Power Automateで「受け取ったら承認フローを起動する」「特定条件でエスカレーションする」といった仕組みに昇華できれば、廃止を業務改善の契機にできる。この機会にTeams通知周りの設計を一度整理してみてはどうだろうか。 出典: この記事は Office 365 Connectors in Microsoft Teams fully retired on May 18, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が Anthropic との連携を強化し、Microsoft 365 Copilot において Anthropic の Claude AI がサブプロセッサとして正式に組み込まれることになった。英国テナントでは管理者が明示的にオプトインしない限り Copilot 内での Claude 機能が利用できない仕組みが2026年5月12日時点で適用されており、多くの企業が設定判断を迫られている。 何が変わったのか これまで Microsoft 365 Copilot は主に Microsoft が管理する AI モデルを使用していたが、今回の変更により Anthropic の Claude がサブプロセッサとして追加された。Microsoft の AI Foundry 経由で外部モデルを利用する流れの一環とみられる。 重要なのはデータ処理の所在だ。Anthropic がサブプロセッサになることは、一部のデータが Anthropic のインフラに渡ることを意味する。英国 GDPR（UK GDPR）の観点から、企業はデータ移転の正当性確認と処理記録の整備が求められる。 英国テナントが判断すべきポイント オプトインを検討すべき組織 生成 AI の活用を積極的に推進している GDPR コンプライアンスの整備が済んでいる データ処理者の追加を DPA（データ処理契約）に通知できる体制がある オプトインを見送るべき組織 厳格なデータ主権要件がある（金融・医療・公共機関等） 社内のデータ処理者変更審査プロセスに時間がかかる 現時点で Copilot をほとんど使用していない 管理者が確認すべき設定手順 Microsoft 365 管理センター → Copilot 設定から Anthropic へのデータ処理同意を確認 プライバシーポリシーの更新: Anthropic をサブプロセッサとして追記 ROPA（処理活動記録）の更新: 新たなデータフローを記録 DPO（データ保護責任者）への連絡: 必要に応じて GDPR 第28条に基づく合意書を更新 日本のIT管理者への示唆 日本テナントへの直接的な影響は現時点では限定的だが、英国での運用は今後の展開の先行事例になる。Microsoft が外部モデルを Copilot に組み込む方向性を明確にした以上、日本の IT 管理者も以下を準備しておくべきだ。 ...

Microsoft が 2026年5月の累積更新プログラム（CU）で、SharePoint Server の全オンプレミスバージョンに影響するリモートコード実行（RCE）脆弱性を含む計10件のセキュリティ修正を提供開始した。Critical 評価の RCE が2件含まれており、オンプレミス SharePoint を運用する組織は速やかな対応が求められる。 修正対象のバージョンと KB 番号 今月の更新は以下のバージョンに適用される。 バージョン 言語非依存 言語依存 SharePoint Server 2016 KB5002868 KB5002869 SharePoint Server 2019 KB5002870 KB5002872 SharePoint Server SE KB5002863 （CU と同一） Office Online Server KB5002871 — Microsoft はセキュリティ修正を単体で適用するのではなく、完全な CU を適用することを強く推奨している。SharePoint Server Subscription Edition（SE）については、5月 CU 自体がセキュリティ修正と同一内容となっている。 また今月の更新は Microsoft Update 経由での自動配信も実施されている。Windows Update を受け入れる設定にしているファームでは、意図せず更新が開始される可能性がある点に注意が必要だ。 今月修正された脆弱性一覧 計10件の脆弱性が修正された。Critical 評価が2件、残る8件は Important 評価の RCE または情報漏えい（Information Disclosure）だ。 CVE 影響バージョン 種別 深刻度 CVE-2026-33110 2016, 2019, SE RCE Important ...

Microsoft Edgeは2026年5月13日、これまで独立していた「Copilot Mode」を廃止し、AI支援機能をブラウザエンジン本体に直接統合する大規模アップデートを実施した。タブ横断推論、Voice and Vision（音声＋画像によるハンズフリー操作）、閲覧履歴を自動整理する「Journeys」が、デスクトップとEdgeモバイルアプリの双方で利用可能になる。 Copilotモード廃止という方向転換 「Copilot Mode」は、Edgeのサイドバーや専用UIとしてCopilotを呼び出す仕組みだった。今回のアップデートでこのモードは正式に廃止となり、同等以上の機能がブラウザ本体のUIに組み込まれる。右上のCopilotアイコンをクリックするだけで、追加設定なしにAI機能が起動する設計だ。 これは「AIをサードパーティ的に乗せる」発想から「ブラウザとAIが一体」という発想への転換であり、アーキテクチャレベルの変化といえる。 3つの主要機能 タブ横断推論（Reasoning across tabs） 開いている複数のタブをまたいでCopilotが情報を収集・比較し、ひとつの回答にまとめる機能。例えば10数件のワイナリーサイトを開いた状態で「どこが一番アクセスがいい？」と聞けば、各サイトの情報を読み取って比較結果を返す。ユーザーの明示的な許可のもとで動作し、現在のページを離れることなく回答が得られる。 Voice and Vision（ハンズフリーブラウジング） 音声とカメラ（画面共有）を組み合わせてEdgeを操作できる機能。「この画面に表示されている契約書の要点を教えて」といった使い方が可能で、Copilotが動作中は常に視覚的なインジケーターが表示されるため、どのタイミングで聴取・撮影しているかを明確に把握できる。 Journeys 閲覧履歴を「旅行計画」「購入検討中の商品」のようなトピック単位に自動整理し、サマリーと次のステップの提案を付与する機能。デスクトップでは先行提供されていたが、今回Edgeモバイルアプリでも利用可能になる。長期間にわたるリサーチや比較検討作業を「途中から再開」しやすくする仕組みだ。 実務への影響 日本のエンジニアやIT管理者にとって、今回の変更で注目すべき点は2つある。 1. ブラウザポリシー管理の見直し Copilot Modeが廃止され機能がブラウザ本体に統合されたことで、これまで「Copilot Mode」を無効化するポリシーで管理していた企業は設定の見直しが必要になる可能性がある。Microsoft Intune経由のEdge管理ポリシーを定期的にレビューする習慣がない組織は、想定外の機能が有効化されるリスクがある。 2. 閲覧履歴の取り扱い Journeysやタブ横断推論は「ユーザーの許可のもとで」閲覧データにアクセスする。社内システムや機密情報を扱うブラウザセッションにおいて、どのデータをAI機能に渡すかの意識を持つことが求められる。企業ポリシーとして「どの機能を許可するか」を明示的に定義しておくことを推奨する。 実務活用のヒント 複数の見積もりサイトや仕様書を並べてタブ横断推論で比較 → 調達・評価業務の効率化に直結 Voice and Visionでマニュアルや障害報告書を音声で要約 → ハンズオン作業中の情報収集に有効 Journeysで長期リサーチの文脈を保持 → 技術選定や要件調査の継続性確保 筆者の見解 率直に言えば、今回の方向性は評価できる。AIをサイドパネルに「乗せる」設計では、どうしても「補助ツール感」が拭えなかった。タブ横断推論のようにブラウザ本体の文脈を活かした機能は、使用感が本質的に変わる可能性を持っている。 ただ、機能の多さと実際の精度は別の話だ。タブ横断推論にしても、開いているタブの内容を正確に読み取り、的外れな回答を返さないかどうかが実運用での評価軸になる。機能名が並んでいるフェーズから、「毎日使い続けたくなる精度」を証明するフェーズへの移行が、今のEdgeに問われている。 MicrosoftにはブラウザとOSとクラウドをつなぐ資産がある。それを活かした形でのAI統合というのは、他社には簡単に真似できない勝負ができるはずだ。Journeysのような「文脈を持続させる」アプローチはその方向性と合致している。この路線を、地道に精度で証明し続けてほしい。 出典: この記事は New updates to Edge across desktop and mobile の内容をもとに、筆者の見解を加えて独自に執筆したものです。