M365

Microsoftは2026年7月13日、Entra ID(旧Azure AD)の多要素認証(MFA)において、SMSワンタイムコードと音声通話による認証方式を2027年2月1日をもって提供終了すると発表した。管理者向けメッセージセンター通知(MC1426371)で明らかにしたもので、Microsoft自身がホストするSMS・音声認証サービスが姿を消し、以降はパスキーが既定の認証方式となる。 何が終了し、何が変わるのか 現在Entra IDでは、MFAチャレンジの選択肢としてMicrosoftが無償でSMSワンタイムコードや音声通話の確認コードを送信している。この仕組みが2027年2月1日で終了する。それでもSMS・音声認証を続けたいテナントは、2026年9月18日から提供されるMicrosoft Security Store経由でテレコムプロバイダーのサービスを別途購入する必要がある。「無料でついてくる」認証方式ではなくなるわけだ。Microsoft Authenticatorアプリやパスキーは対象外で、引き続き無償で使える。 なぜ電話認証を切り捨てるのか SMS・音声によるMFAは、共有シークレットと公衆電話網に依存する認証方式で、SIMスワッピング(攻撃者が携帯キャリアを騙して被害者の番号を自分のSIMに移す手口)やメッセージ傍受、番号の再割り当て、ソーシャルエンジニアリングによる突破が以前から知られていた。パスキーは公開鍵暗号方式のため、こうした攻撃への耐性が格段に高い。 Microsoftは2024年時点でMFA応答の44%がSMS・音声経由であり、SMSはAuthenticatorアプリより突破される確率が40%高いというデータを示している。管理者向けMFA必須化以来、段階的に電話認証からの移行を促してきたMicrosoftだが、今回はいよいよ「終了日」を明示した格好だ。 移行スケジュールとテナントの準備 2026年9月からEntra IDはSMS・音声利用者に対して自動的にパスキーを有効化し、登録キャンペーンを「Microsoft managed」に設定してパスキー作成を促す。ユーザーは一時的にスキップできるが、最終的には登録が必要になる。2027年2月1日以降、準備が整っていないユーザーはMFAチャレンジに応答できずサインインできなくなる可能性があり、ヘルプデスクへの問い合わせ増加は避けられないだろう。対象ユーザーの洗い出しには、Microsoftが提供する「passwords and authentication methods report」PowerShellスクリプトが使える。 実務への影響 日本企業のEntra ID管理者にとって、これは対岸の火事ではない。現場作業員や非デスクワーカー向けにSMS認証を採用している企業、取引先・協力会社アカウントでSMSを既定にしている企業、古い条件付きアクセスポリシーのままMFA方式を限定していないテナントは要注意だ。まずは前述のPowerShellレポートで対象アカウントを棚卸しし、パスキー対応デバイス(Windows Hello、iOS/AndroidのFIDO2対応、セキュリティキー等)の可用性を確認したい。17か月の猶予は十分に見えるが、非デスクワーカーへのデバイス展開や取引先への周知には想像以上に時間がかかる。年内に移行計画を立てて動き出すのが賢明だ。 筆者の見解 今回の発表は、素直に評価できる判断だと思う。SMSや音声通話は仕組み上どうしても攻撃の余地が残る認証方式で、SIMスワップ被害のニュースは以前から後を絶たない。ゼロトラストの観点でも認証層の強度を底上げする今回の動きは筋が通っている。 好感が持てるのは、いきなり「禁止」にするのではなく、自動でパスキーを有効化しつつ登録キャンペーンで気づかせ、猶予期間を設けて段階的に移行させる設計になっている点だ。ユーザーが一番使いやすいと感じる方式が結果的に一番安全な方式になる——これがセキュリティ施策の理想形で、Microsoftはこの手の「使ってもらう工夫」に関しては昔から強い。応援したくなる部分だ。 一方で、日本の大企業の現場を見ていると、SMS認証に頼っているアカウントが今でも相当数残っているのが実情だ。昔ながらのセキュリティ運用と中途半端なゼロトラスト導入が混在したテナントでは、今回のような「土台からの変更」に対応しきれず、2027年2月に駆け込みで慌てる組織が出てくるのは目に見えている。今のうちから対象アカウントを洗い出し、パスキー移行を粛々と進めておくことをお勧めしたい。正面から準備すれば怖くない変更のはずだ。 出典: この記事は Microsoft to Stop Providing Telephony-Based Authentication Methods for MFA in February 2027 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米Microsoftは2026年7月13日、Office 2019および一部の古いバージョンのOffice 2021・Microsoft 365アプリについて、Mac版とiOS版を「機能制限モード」へ移行させた。対象デバイスではファイルの閲覧・印刷は引き続きできるが、編集・保存・新規作成は一切できなくなる。Windows版・Android版は今回の対象外だ。 何が起きているのか 対象はWord、Excel、PowerPoint、Outlook、OneNoteといった主要アプリ。Microsoftのサポートページによれば、ライセンス認証に使っている証明書が期限切れを迎えることが理由とされている。証明書が失効するとアプリ側でライセンスの正当性を確認できなくなり、安全側に倒して編集機能を止める、という理屈だ。 ただし証明書は本来更新できるものでもある。Microsoft 365サブスクリプションおよびOffice 2021のユーザーは、アプリをバージョン16.83以降に更新すれば影響を回避できる。macOS 11以前を使っている場合は、先にmacOS Monterey（12）以降へアップデートする必要がある。 問題は買い切り版のOffice 2019だ。こちらにはMicrosoftから救済アップデートが提供されない。つまり「一度購入したソフトウェアの機能が、ベンダー側の判断で止まる」形になる。Microsoftは2023年10月にOffice 2019 for Macのサポートを終了した際、「Office 2019アプリは引き続き機能する」と案内していた経緯があり、今回の措置はその説明とかみ合っていない。 対象かどうかの確認方法 Wordを開き「Word」>「Wordについて」からバージョン番号とライセンス種別を確認する。バージョンが16.83以上であれば当面は問題ない。16.82以下でライセンス種別が「Retail License 2019」の場合、Microsoft 365への切り替え、Office 2024の購入、あるいはPagesやGoogle Docsなど代替アプリへの移行が現実的な選択肢になる。 実務への影響 日本のIT現場でまず点検すべきは「個人所有Mac・iPadでの業務利用」だ。BYOD環境や、経費精算の隙間で私物Macに古いOfficeを入れっぱなしにしているケースは珍しくない。情報システム部門が把握していない「野良Office 2019」は、7月13日を境に編集不能になり、現場からの問い合わせが集中する可能性がある。 対応の勘所は3つ。第一に、社内のMacデバイス台帳とOfficeライセンス種別を突き合わせ、Retail License 2019の残存を洗い出すこと。第二に、Microsoft 365サブスクリプションへの統合を優先すること。買い切り版は今回のように予告なく機能が止まるリスクを内包しており、サブスクリプション型に寄せておいた方が長期的な運用コストは低い。第三に、Windows/Android端末は今回影響を受けないため、対応範囲をMac/iOSに絞ってよい。 筆者の見解 証明書の期限切れという技術的な理由づけ自体は理解できる。だが、買い切りライセンスで購入したソフトウェアの編集機能を、ユーザー側に非のない形で止めてしまうやり方には正直、賛成しがたい。2023年には「引き続き機能する」と案内していたのだから、なおさらだ。 筆者はMicrosoft製品を長年使い、応援する立場のMVPとして書いているからこそ言いたいのだが、これは「やらなくていいこと」だと思う。買い切り版というライセンス形態を選んだユーザーは、そこに「一度払えば安心して使い続けられる」という価値を見出していたはずだ。その前提を後から崩すやり方は、サブスクリプションへの移行を促す近道に見えても、長期的にはブランドへの信頼を削ってしまう。Microsoftほどの技術力と顧客基盤があるのだから、正面から「Microsoft 365の方がこれだけお得です」と価値で選んでもらう戦略の方が、よほど筋が良いはずだ。 日本企業にとっての教訓はむしろ別のところにある。資産管理台帳とライセンス実態が一致していない組織は、今回のような「静かな仕様変更」のたびに現場が混乱する。サブスクリプション統合と資産の可視化を平時から進めておくことが、この手のニュースに振り回されない一番の予防策だ。 出典: この記事は Microsoft is disabling Office 2019 for Mac on July 13, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotの公式コミュニティブログで、Copilot Studioで構築したAIエージェントをMicrosoft Teams上に公開し、社内のユーザーと共有するための手順を解説する記事が取り上げられた。エージェントを作るところまでは多くの解説があるが、今回は実際に現場の従業員が使える状態にするまでの「公開」フェーズに焦点を当てている。 Copilot Studioエージェントを「作る」から「使わせる」へ Copilot Studioで作成したエージェントは、作っただけでは開発者本人の環境でしか動かない。Teamsチャネルとして有効化し、組織のTeams環境に配布して初めて、現場の従業員が実際にチャットから呼び出せるようになる。この配布プロセスにはいくつかの段階がある。 まずテストキャンバスでエージェントの応答が意図通りかを検証する。次に「チャネル」設定でMicrosoft Teamsを有効化し、エージェントをTeamsアプリとしてパッケージ化する。ここまでは基本的に開発者個人の作業だ。 その先の組織展開が今回の記事の本題になる。パッケージ化したエージェントは、個別ユーザーへの直接共有、特定チームへの限定公開、組織のアプリカタログへの登録という段階を踏んで配布できる。特にアプリカタログへの登録を選ぶ場合は、Teams管理センターでのテナント管理者による承認が必須になる。誰でも自由に全社公開できるわけではなく、管理者の統制を経由する設計になっている点が実務上のポイントだ。 実務への影響 日本企業のIT管理者にとって重要なのは、「管理者承認を経由した公開」という仕組みそのものだ。Copilot Studioのようなローコードツールは現場主導でエージェントがどんどん作られていく一方、野良エージェントが無秩序に全社展開されると、情報漏洩や誤動作のリスクが一気に高まる。Teams管理センターのカスタムアプリポリシーを使えば、公開範囲を「特定チームのみ」「承認制」などに制御でき、禁止一辺倒ではなく安全に使わせる仕組みとして機能する。 エージェント自体も一種の非人間アイデンティティ(NHI)であり、誰が・どの権限で・どこまで自動実行してよいかを最初から設計しておく必要がある。IT管理者は、まずTeams管理センターの「アプリの管理」でカスタムアプリの提出ポリシーと承認フローが有効になっているかを点検し、全社公開の前に特定チームでの限定公開期間を設ける段階的な運用を検討するとよい。 筆者の見解 CopilotやCopilot Studioは、この数年でMicrosoftが最も力を入れてきた領域であり、率直に言えばこれまでの体験には物足りなさを感じることも多かった。ただ、今回のように「エージェントの作成と公開を分離し、管理者の統制を挟む」という設計思想自体は正しい方向だと思う。 Teamsは既に多くの日本企業で日常業務のハブになっている。そこにエージェントを安全に流通させる仕組みが整うなら、Copilotひとつに閉じず、Teams上で複数のAIエージェントを併用していく未来にもつながっていく。ガバナンスの土台はできつつあるので、あとはエージェントそのものの実力をどこまで引き上げられるかが問われる。正面から勝負できる力があるはずのプラットフォームだからこそ、この仕組みを活かしきれる中身を伴わせてほしい。 出典: この記事は Publishing and Sharing Your Agent Across Microsoft Teams: A Complete Step-by-Step Guide の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365上でAIが生成・加工した動画および音声コンテンツに「透かし（ウォーターマーク）」を付与する新しいクラウドポリシーを発表した。対象となるのは、動画編集ツールClipchampで生成したAI動画や、Copilotが自動生成する音声概要（Audio Overview）などのコンテンツだ。ポリシーは既定で無効になっており、テナント管理者がMicrosoft 365管理センターから明示的に有効化する必要がある。 何が変わるのか 今回追加されたのは、AIによって生成・加工されたことを示す情報を、動画・音声ファイルに埋め込む仕組みだ。コンテンツの来歴（プロブナンス）を示すという発想自体は目新しいものではなく、業界全体で進むC2PA（Coalition for Content Provenance and Authenticity）のContent Credentialsのような取り組みと軌を一にする。Microsoftも以前からBing Image CreatorやDesignerが生成した画像にC2PAベースの来歴情報を付与しており、今回はその考え方を動画・音声というメディアにも広げた形になる。 管理はテナント単位のクラウドポリシーで行う。管理者がポリシーを有効化すると、対象アプリで生成・加工されたコンテンツに自動的に透かしが付与されるようになる。個々のユーザーが都度オン・オフを選ぶ機能ではなく、組織のガバナンス方針として一括適用する設計だ。 画像の透かしとは別管理 注意したいのは、画像コンテンツにはこのポリシーとは別に、ユーザーが個別に制御できる透かし機能が既に存在する点だ。今回のクラウドポリシーはあくまで動画・音声を対象としており、画像側の仕組みとは管理経路も適用範囲も異なる。両者を混同して「画像も含めて一括で制御できる」と誤解しないよう、社内周知の際は対象範囲を明確にしておく必要がある。 実務への影響 日本企業のIT管理者にとって、この機能は「AI生成コンテンツであることをどう開示するか」という、今後避けて通れない課題への一つの答えになる。生成AIで作った紹介動画や、Copilotが要約した音声資料が社外に出ていく機会は今後確実に増える。透かしという形で来歴を残しておけば、フェイクコンテンツ対策や、受け手への誠実な情報開示という観点で組織を守ることにつながる。特に金融・メディア・広報部門など、対外的な説明責任が重い部署では、開示ルールが法制度で求められる前に自主的に整備しておく価値は大きい。 実務的には、まず自社でClipchampやCopilotの音声概要機能をどの部署がどの程度使っているかを棚卸しし、有効化した場合の影響範囲を確認するところから始めたい。既定が無効のため今すぐ何かが変わるわけではないが、コンプライアンス要件がある組織ほど早めに評価しておく価値がある。 筆者の見解 生成AIコンテンツの透明性確保は、今後あらゆるプラットフォームが避けて通れないテーマだ。MicrosoftがMicrosoft 365という統合プラットフォームの中に、動画・音声の透かしをテナント単位のポリシーとして組み込んだこと自体は、地に足のついた前進だと感じる。派手な新機能ではないが、こうした地道なガバナンス機能の積み重ねこそが、企業がAIを本格的に業務へ組み込んでいくための土台になる。 一方で、今回の仕組みはあくまで「管理者が有効化して初めて動く」オプトイン方式であり、既定オフという設計にはやや物足りなさも残る。Copilotの音声概要のような機能は今後さらに使われる場面が増えていくはずで、AI生成物であることの開示は本来もっと当たり前の標準機能になっていてよいはずだ。透明性確保の仕組みをせっかく作ったのだから、デフォルトで有効にしても違和感がないくらいの立ち位置に、Microsoftには早めに踏み込んでほしい。AIガバナンスの領域で正面から勝負できるだけの力は十分にあるはずなので、そこは素直に期待している。 出典: この記事は Bringing transparency to AI-generated content with watermarks in Microsoft 365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Teams/OBSから4プラットフォームに同時ライブ配信するOSSツールを作った話この記事はClaude Code（AI）との共同作業で書かれています。 続きをみる note.com で続きを読む →

Microsoft Teams meetingsに、外部AIボットを自動検知してロビー（待機室）に留め置く新しい保護機能が追加される。Microsoftが2026年7月9日(米国時間)に公式ブログで発表したもので、Otter.aiやFireflies、Read.aiといった外部の会議録音・文字起こしボットが会議に参加しようとした際、既定で待機室に足止めし、ホストが明示的に許可するまで参加させない仕組みになる。管理者は「外部ボット管理」ポリシーをユーザー単位・グループ単位で個別に割り当てられる。 何が起きるのか これまでTeams会議は、リンクさえ知っていれば外部の録音・文字起こしボットが会議室に「参加者」として入り込むことができた。会議主催者が気づかないまま、社外のAIサービスに会議内容が送信され、要約・保存されるケースも珍しくない。今回の機能は、こうした外部ボットを自動的に識別し、既定で「ロビー」に足止めする。人間の参加者と同様に、ホストが個別に入室を許可しない限り会議には参加できない。 管理者向けにはTeams管理センターに新しい「外部ボット管理」ポリシーが追加される。既存の会議ポリシーと同様、テナント全体・特定グループ・特定ユーザー単位で挙動を変更できるため、たとえば営業部門には特定の議事録ボットの利用を許可しつつ、それ以外の部門では原則ブロックする、といった柔軟な運用が可能になる。 展開スケジュール 2026年7月にロールアウトが始まり、8月に一般提供(GA)、9月にはポリシー未設定のテナントにも既定で適用される。つまり管理者が何もしなければ、9月以降は自動的に外部ボットがロビー待機の対象になる。 実務への影響 日本企業でも、AI議事録ツールは会議の生産性を大きく高める一方、統制のかからない形で普及していることが多い。会議参加者の一人が個人契約のAIボットを招待し、社外秘の会議内容が海外のクラウドサービスに送信されているケースは、情報漏えいのリスクとして見過ごせない。今回の機能は、こうした「野良ボット」の混入を防ぐ最初の一歩になる。 IT管理者は9月の既定適用を待たず、まず社内でどの議事録ボットが実際に使われているかを棚卸しすることをお勧めする。そのうえで、業務上必要なツールだけをグループ単位で許可リストに載せ、それ以外は原則ブロックする設計にすれば、利便性を損なわずに統制を効かせられる。会議主催者にも、ロビーに知らないボットが現れたときの対応方針(安易に許可しない)を周知しておく必要がある。 筆者の見解 この機能は、ゼロトラストの発想を会議室という身近な場所に持ち込んだ好例だと感じる。ボットやAIエージェントのような「人間ではない身分(Non-Human Identity)」に常時アクセス権を与えるのではなく、既定は拒否、必要なときだけ明示的に許可するというJust-In-Time的な設計は、筆者が普段から重要だと考えている考え方そのものだ。 なにより評価したいのは、「外部ボットを一律禁止」にしなかった点だ。禁止だけのアプローチは必ずどこかで抜け道が生まれ、結局はシャドーIT化する。今回のように、既定は安全側に倒しつつ、管理者が業務に必要なツールを個別に許可できる仕組みにしたことで、現場の利便性を落とさずに統制できる。Microsoftのセキュリティ機能は地味に映ることも多いが、こうした「安全に使える仕組み」を丁寧に積み上げていく姿勢は、もっと評価されてよいと思う。 出典: この記事は Introducing smarter bot protection in Microsoft Teams meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 CopilotがPower BIのレポートやセマンティックモデルを直接参照し、そのデータに基づいた「根拠のある回答」を返せる機能を提供し始めた。レポートのリンクをチャットに貼り付けたり、レポート名を言及するだけでCopilotが該当データに接続できるほか、何も指定しなくてもCopilotが質問内容から適切なレポートを自動的に探し出して参照する。ポイントは、この機能がユーザー自身が本来持っているPower BIの権限の範囲内でしか動作しない設計になっていることだ。現時点ではFrontierプログラムのテナント向けにCopilot Premiumライセンスが必要とされている。 Work IQを基盤にした「根拠ある回答」の仕組み この機能は、Microsoftが進める「Work IQ」という基盤技術の上に成り立っている。Work IQは、ユーザーが日々やり取りするメール・Teams・SharePoint・Power BIなど組織内のデータをCopilotが横断的に理解し、文脈に応じて適切な情報源から回答を組み立てるための仕組みだ。今回のアップデートで、そのデータソースにPower BIのレポートとセマンティックモデルが加わったことになる。ユーザーが特定のレポートを共有していればそれを根拠にし、共有がなくても質問の内容からCopilotが自動的に該当レポートを見つけて参照する点が特徴だ。 ユーザー本来の権限モデルを変えない設計 注目すべきは、この機能がCopilot専用の特権的なアクセス経路を新設するものではなく、ユーザーが元々見られる範囲のPower BIデータしか回答に使わない設計になっている点だ。Copilotが裏側で万能のサービスアカウントを使ってテナント内のあらゆるレポートを読めてしまう、という仕組みではない。ユーザーの権限がそのまま回答の範囲を決める。 管理者側の設定は二段階 有効化は管理者側で2段階の作業になる。まずMicrosoft 365管理センターのCopilot設定から「Fabric data in Microsoft 365 Copilot」を開き、対象ユーザーを「なし」「全員」「特定のグループ」から選ぶ。次に、Fabric管理者がFabric管理ポータルのテナント設定で「Share Fabric data with your Microsoft 365 services」を有効にする必要がある。この設定を入れない限り、CopilotからFabric側のデータを検索・参照することはできない。なお、この設定を有効にすると、Copilot側のクエリデータがFabricに共有される点は明記されている。FabricはM365 Copilotとは別のコミットメントで運用されており、そこで処理されるデータはFabric Product Termsの適用を受ける。 実務への影響 日本のエンタープライズでPower BIを使い込んでいる企業は多いが、目的のレポートを探し出し、該当シートを開き、数値を拾って会議資料に転記するという作業は今も人手に依存しがちだ。この機能が定着すれば「このレポートのこの数字の背景を説明して」とCopilotに聞くだけで済むようになる可能性がある。ただし、いきなり「全員」で有効化するのではなく、まず「特定のグループ」で限定的に試し、意図しないレポートまで拾ってきていないか、権限設計に想定外の穴がないかを確認してから段階的に広げるのが安全だ。また、Fabric管理者とM365管理者は別部門・別担当者であることも多いため、この2段階設定を誰がいつ有効にするのかを事前にすり合わせておく必要がある。 筆者の見解 この数年、Copilot関連の新機能発表に以前ほど手放しでは反応できなくなっていたのが正直なところだ。期待した完成度に届かない発表が続いたのも事実である。ただ、セキュリティを専門領域のひとつとして見ている筆者から見ると、今回のPower BI連携は方向性としてかなり筋が良い。AIエージェントが業務データにアクセスする際、専用の特権サービスアカウントを新設してあらゆるデータへの常時アクセス権を持たせてしまう、というやり方が最も危ういパターンだ。今回の実装はそうではなく、あくまでユーザー本人の権限の範囲内でCopilotが動く。「禁止するのではなく、安全に使える形で便利さを提供する」という、AI活用のセキュリティ設計として本来あるべき姿に近い。Non-Human Identityの管理がこれからの業務効率化のボトルネックになっていく中で、こうした「権限を昇格させない」設計をきちんと作り込んでくることには素直に期待したい。Power BIというデータ資産とCopilotという対話インターフェースを両方持っているのだから、この強みを正面から活かしてほしい。あとは実際にどれだけ精度の高い回答を返せるかどうかにかかっている。そこが伴って初めて、今回の設計の良さが本当の意味で活きてくる。 出典: この記事は Use Power BI data in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはSharePointとOneDrive上でMarkdown（.md）ファイルを閲覧・編集する際に、特定の文章箇所へインラインコメントを付けられる機能を追加すると発表した。コメントされた際のメンション通知にも対応し、2026年8月から段階的に一般提供（GA）される。対象はWeb版で、提供範囲はWorldwide（Standard Multi-Tenant）となっている。 何が変わるのか これまでSharePointやOneDrive上のMarkdownファイルは、閲覧やレンダリング表示こそサポートされていたものの、コラボレーション機能という点ではWord・Excel・PowerPointといった従来のOfficeファイルに見劣りしていた。Officeファイルであれば当たり前にできる「この一文にコメントを付けて、担当者にメンションで通知する」という操作が、Markdownファイルでは実質できなかったのだ。 今回のアップデートにより、Markdownファイル内の任意の箇所を選択してコメントを残し、特定の相手をメンションして通知を飛ばせるようになる。GitHubのプルリクエストレビューやObsidianのようなツールで馴染みのある「文書の特定箇所に対する会話」が、SharePoint・OneDriveという企業の標準的なファイル置き場の上でネイティブに完結する形だ。 なぜMarkdownコメント機能が必要だったのか 近年、README、設計ドキュメント、ADR（Architecture Decision Record）、技術仕様書などをMarkdownで書く文化は開発チームだけでなく、IT部門や企画部門にも広がっている。プレーンテキストでバージョン管理しやすく、Git等との親和性も高いためだ。 一方で、こうしたMarkdownドキュメントを社内の非開発者も含めてレビューしようとすると、これまでは「Teamsでスクリーンショットを貼ってやり取りする」「別途Wordに変換してコメントを付ける」といった非効率な運用を強いられがちだった。今回の機能追加は、この隙間を埋めるものと言える。 実務への影響 日本のIT現場では、開発ドキュメントや技術仕様書をSharePoint上のライブラリで一元管理している組織も多い。これらのチームにとって、今回のアップデートは地味だが実務に直結する改善だ。 具体的な活用ポイントは以下の通り。 技術ドキュメントのレビューフロー簡略化: 設計ドキュメントやADRのレビューを、Teamsチャットやメールでのやり取りから、ファイル内の該当箇所への直接コメントに移行できる。GitHubのPRコメントに近い体験がM365内で完結する メンション通知による確実なフィードバック依頼: レビュー担当者を明示的にメンションできるため、「誰が何にコメントしたか」「誰への確認待ちか」が可視化される 展開時の注意点: 現時点ではWeb版が対象で、デスクトップアプリやモバイルでの対応状況は別途確認が必要。IT管理者は8月のロールアウト前に、対象ライブラリの利用者へ周知しておくとよい 非開発部門を含めてMarkdownでのドキュメント作成が広がる中、SharePoint・OneDriveという既存の企業インフラがそれに追従してくれるのは、新しいツールの導入コストをかけずにレビュー文化を整備できるという意味で価値がある。 筆者の見解 この手のアップデートは派手さこそないが、個人的には歓迎したいアップデートだ。Microsoft 365は本来、SharePoint・Teams・OneDriveといった各コンポーネントを統合して使うことで真価を発揮するプラットフォームであり、Markdownという開発者文化に根ざしたフォーマットへの対応強化は、その統合価値を底上げする地道な積み重ねだと思う。 奇をてらった新機能よりも、こうした「当たり前にできてほしかったこと」を一つずつ埋めていく姿勢の方が、結局のところ現場での定着率は高い。GitHubのような外部ツールと役割分担しつつ、社内標準の情報基盤としてSharePointを使い続けているチームにとっては、今回のような細かい機能改善こそが日々の生産性に直結する。 Microsoftには、こうした地に足の着いたアップデートを今後も着実に積み上げてほしい。派手なAI機能の発表の裏で、こういう基盤機能の充実こそが「使われ続けるプラットフォーム」の条件だと筆者は考えている。 出典: この記事は Introducing Markdown support in SharePoint and OneDrive (inline commenting) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Excel上のAIアシスタント「Copilot in Excel」に、業務手順を再利用できる「スキル」機能と、ワークブックごとのルールを定義する「Rulesシート」、さらに財務データコネクタを追加した。いずれもOneDrive上にファイルとして保存でき、毎回同じ指示をチャットに書き込まなくても、Copilotが定型業務を一貫した手順で実行できるようにする狙いだ。 SKILL.mdファイルによる「再利用可能スキル」とは何か 今回追加された目玉機能が、SKILL.mdというテキストファイルの形で保存できる「再利用可能スキル」だ。たとえば「月次売上レポートのフォーマットに整形する」「特定の集計ロジックでピボットを作る」といった一連の作業手順を一度SKILL.mdに書いておけば、以降はそのスキルを呼び出すだけでCopilotが同じ手順を再現してくれる。OneDriveに置いておけばチーム内で共有もできるため、属人化しがちだったExcel作業の「暗黙知」を明文化・資産化できる点が大きい。 手順やルールをMarkdown形式のファイルとして定義し、AIエージェントに読み込ませるという設計自体は、近年のAIエージェント界隈で広がりつつある考え方で、Microsoftもこの流れに追随した形だ。 Rulesシートで書式・命名規則・数式の「お作法」を固定化 もう一つの新機能「Rulesシート」は、ワークブック単位で書式ルール・セルの命名規則・数式の書き方の慣習をあらかじめ定義しておける仕組みだ。「金額セルは常に3桁区切りでカンマ表示」「シート名はプロジェクトコード_年月の形式」といった社内ルールをRulesシートに書いておけば、Copilotがそのワークブックを編集する際に自動的にルールを守るようになる。これまでのように毎回チャットで細かい書式指定をし直す手間が減る。 加えて、財務データを直接取り込める新しいデータコネクタも追加された。会計・財務系のデータソースとExcelの間の橋渡しをCopilotが担うことで、レポート作成のためのデータ収集・整形作業そのものを短縮できる。 実務への影響 日本企業のバックオフィス、特に経理・財務部門にとっては地味だが効きそうな機能強化だ。月次・四半期決算のレポート作成は「同じフォーマットに同じ手順で整える」という反復作業の塊であり、SKILL.mdとRulesシートはまさにこの反復を仕組み化するための道具になる。IT管理者の視点では、誰がどんなスキルをOneDriveに公開しているのか、部門をまたいで共有していいスキルなのかというガバナンス設計が新たな検討課題になるだろう。野良のSKILL.mdが乱立すると、かえって「どのルールが正なのか」が分からなくなる恐れもあるため、テンプレートの管理者を決めて配布する運用ルールを早めに整備しておきたい。 筆者の見解 Copilotについては、これまで機能の割に実務での「効く感」が乏しいという印象を持ってきたが、今回の追加は方向性として素直に評価したい。ルールや手順をファイルとして明文化し、AIに毎回同じ指示を繰り返させない設計は、「禁止ではなく安全に使える仕組みを作る」という考え方そのものだ。属人化した業務ノウハウを個人の頭の中に閉じ込めるのではなく、SKILL.mdやRulesシートという形でチームの資産にできるなら、それはCopilotが「その場しのぎのチャットボット」から「業務基盤の一部」へと一歩進んだことを意味する。 一方で、こうした仕組みは作って終わりではなく、実際に現場で使われて初めて価値が出る。Microsoft 365は本来、統合して使うことで真価を発揮するプラットフォームであり、今回のような地道な機能強化を着実に積み重ねてこそ、Copilotが名実ともに現場の主力ツールになっていく。正面から勝負できるだけの土台は十分にあるはずなので、この路線を粘り強く伸ばしていってほしいというのが率直なところだ。 出典: この記事は Microsoft adds reusable skills and finance data connectors to Copilot in Excel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界規模で相次ぐMicrosoft 365の障害 2025年10月8日、Microsoftは Teams、Exchange Online、そして管理センターへのアクセスを妨げる大規模障害への対応に追われた。影響はサインインそのものに及び、Microsoft Entra IDのシングルサインオン(SSO)や多要素認証(MFA)まで巻き込まれたため、正常にログインできるはずのユーザーまで「しばらくしてページを再読み込みしてください」というエラーに突き当たった。Microsoftはこの障害を数時間で収束させたが、これは孤立した出来事ではない。2026年に入ってからも同種の障害が繰り返し報告されており、2026年第1四半期のグローバル稼働率はSLA基準である99.9%を下回る99.526%にとどまったことが明らかになっている。 原因はディレクトリ操作基盤の輻輳 Microsoftの事後分析によれば、今回の障害はディレクトリ操作(directory operations)を担うインフラの一部が、トラフィック集中時に負荷の偏り(imbalance)を起こし、認可(authorization)処理が失敗したことが原因だった。認証・認可はMicrosoft 365全体の入り口であり、ここが詰まればTeamsもExchange Onlineも管理センターも一斉に使えなくなる。実際、今回以前にも1月にはMFA関連の障害でOfficeアプリにアクセスできなくなり、7月には管理センターへのアクセス障害、8月には北米でOffice.comとCopilotが同時に使えなくなるなど、認証基盤起点の障害が繰り返されてきた。 実務への影響——可用性前提の設計を見直す 日本企業の多くはTeamsを電話・会議・チャットの主要インフラとして、Exchange Onlineを業務メールの基盤として全面的に依存している。今回のような障害はSSOやMFAという「入り口」で起きるため、代替の連絡手段(緊急連絡網、電話、別クラウドのチャットなど)をあらかじめ用意しておくことが欠かせない。IT管理者はstatus.cloud.microsoftやService Health Dashboardの監視を業務継続計画(BCP)に組み込み、条件付きアクセスやMFAの構成が単一の認証基盤に完全依存しないよう、緊急アクセス用アカウント(Break Glassアカウント)の運用を今一度点検すべきタイミングだ。 筆者の見解 Microsoft 365は統合して使ってこそ価値が出るプラットフォームであり、筆者自身も長くMicrosoftを中心に据えて仕事をしてきた。だからこそ言いたいのだが、認証基盤という最も止めてはいけない場所でこれだけ障害が繰り返され、SLAすら割り込んだという事実は素直に受け止めるべきだ。もったいない。Teams・Exchange・管理センターを一枚岩で支える基盤だからこそ、可用性への信頼が価値の土台になる。正面から勝負できる技術力を持つ会社なのだから、ここの底上げには本気で取り組んでほしい。ユーザー側としても、ゼロトラストの発想と同じで「今動いているから大丈夫」で終わらせず、認証基盤が落ちた前提での代替手段を平時から準備しておくことが、結局は最も現実的な防衛策になる。 出典: この記事は Microsoft 365 outage blocks access to Teams, Exchange Online の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotに、CVSSスコア最大9.8相当と評価される重大な脆弱性「CVE-2026-54130」が発見され、2026年6月18日に開示された。Microsoftはこの脆弱性を「CWE-306:重要な機能に対する認証の欠如」に分類しており、攻撃者はパスワードも盗んだ認証情報も持たないまま、ネットワーク経由でCopilotから情報を窃取できる可能性があった。しかも今回のケースには、通常のCVE対応とは異なる大きな特徴がある。企業側が適用すべきパッチが存在しないのだ。 クラウドサービスだからこその「即時修正」 Microsoft 365 CopilotはMicrosoftが運用するクラウドサービスであるため、今回の脆弱性はMicrosoft側のインフラで直接修正された。管理者がWindows UpdateやAdminセンターで何かを適用する必要はなく、ビルド更新も存在しない。現時点でCISA(米国土安全保障省サイバーセキュリティ・インフラセキュリティ庁)のKnown Exploited Vulnerabilitiesカタログにも掲載されておらず、悪用の痕跡も確認されていない。 これは裏を返せば、SaaS型で提供されるAIサービスの強みでもある。オンプレミス製品であれば、脆弱性の公表から実際にパッチが行き渡るまでに数週間から数ヶ月かかることも珍しくない。Copilotのようなクラウドネイティブなサービスは、Microsoft側で修正が完了した時点で全利用者への適用が完了する。 「対応不要」が招く油断こそが本当のリスク 問題は、この「パッチ不要」という言葉が、企業のセキュリティ担当者に誤ったメッセージを与えかねない点だ。今回のCVE自体はMicrosoftの管轄で解決済みだが、Copilotが日常的にどこまでのデータへアクセスできる設定になっているかは、完全に利用者側の管理範囲にある。SharePoint、Teams、Exchangeにまたがる権限設計、共有範囲の広すぎるドキュメントライブラリ、退職者アカウントに残った過剰な権限。これらはCVEの有無に関わらず、Copilotが静かに到達できてしまうデータの範囲を決めている。 米国の金融機関向けセキュリティサービスABTのブログも指摘する通り、今回の一件は「パッチを適用する作業」ではなく「ガバナンスを見直す作業」を企業に突きつけている。特に金融機関のような規制業界では、次の監査で「Copilotがアクセスできるデータの範囲をどう統治しているか」を問われる可能性が高い。 実務への影響 日本のIT管理者にとっての宿題は明確だ。Microsoft Purviewの機密度ラベルやSharePointの共有権限を棚卸しし、Copilotの検索対象になっているサイトやドキュメントライブラリを定期的に確認すること。特に「全社共有」設定のまま放置されたSharePointサイトは、Copilotから見れば格好の情報源になる。M365 E5環境であればPurview監査ログでCopilotのアクセスパターンを追跡できるので、四半期に一度は棚卸しのサイクルに組み込みたい。 筆者の見解 今回の対応スピードは、Microsoftのクラウド事業者としての基礎体力の高さを示している。エンタープライズ規模でこれだけ速く穴を塞げるのは、正面から評価していい部分だ。 一方で、この一件が浮き彫りにしたのは「Copilotに何を見せるか」を突き詰めて設計してこなかった企業がまだ多いという現実である。CopilotのようなAIエージェントは、人間のアカウントと同じかそれ以上の速さで大量のデータへアクセスする。常時フルアクセスを前提にした権限設計のままAIを導入すれば、CVEの有無にかかわらずリスクは残り続ける。必要な時に必要な範囲だけアクセスを許可する発想を、AIエージェントの権限設計にも当てはめるべき時期に来ている。 禁止すればいいという話でもない。Copilotを制限しすぎて使い物にならなくすれば、結局シャドーAIが横行するだけだ。求められているのは、安全に使える権限設計をきちんと用意した上で、Copilotを正々堂々と使ってもらう仕組みづくりである。Microsoftにはクラウド側の速さだけでなく、顧客側がその仕組みを作りやすい管理ツールの提供でも、もう一段引っ張ってほしいところだ。 出典: この記事は Microsoft 365 Copilot CVE-2026-54130: Nothing to Patch, Plenty to Govern の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年6月、Microsoft 365 Copilot Chat に実用性の高い2つの改善を展開した。会話スレッドの自動保存と、メモリ管理UIの改善が主な変更内容で、日常的にCopilot Chatを利用しているユーザーの操作体験が向上する。 会話スレッドの自動保存（MC1174856） これまでCopilot Chatでは、会話スレッドの保存タイミングが一貫しないケースがあった。今回の変更（ロードマップID: 500638）により、ユーザーが最初のプロンプトを送信した直後に即座に会話スレッドが生成されるようになった。 ナビゲーションペインに会話エントリが作成され、その後のやり取りがTeamsのチャットスレッドと同様に積み重なっていく。一度作業を中断して後から同じコンテキストで会話を再開できるようになるため、「考えを整理してから続きを聞く」というワークスタイルに対応しやすくなる。 当初の展開予定から大幅に遅延していたが、2026年6月末時点で商用・政府向けテナント全体への展開が完了する見込みだ。 メモリ管理UIの改善（MC1158329） Copilot メモリは、ユーザーが「Copilotに常に覚えておいてほしいこと」を登録しておく機能だ。約1年前に導入されたが、設定UIが分かりにくく見落とされがちだった。今回の改善（2026年6月8日更新）では、メモリ設定の発見性と管理しやすさが向上している。 メモリの登録方法はチャット入力から「〇〇を覚えておいて」と話しかける形が基本。設定の確認・管理は画面右上のメニュー → 「Chat Settings」→「Personalization」→「Shared memories」から行える。 設定できるメモリの例を挙げると： 「回答は簡潔にまとめてほしい」 「PowerShellの例はMicrosoft Graph PowerShell SDKで書いてほしい」 「Microsoft技術を調べるときは必ず公式ドキュメントの引用元を示してほしい」 こうした指示をメモリとして登録しておくと、Copilotの応答が個人の業務スタイルに合った形になる。毎回同じ前置きをプロンプトに書く手間が省けるのは、実務上の明確なメリットだ。 実務への影響 メモリ設定は「育てる投資」と考える メモリ機能は登録した瞬間から劇的に変わるものではなく、自分の業務パターンを少しずつ蓄積することで精度が上がっていく。 エンジニアであれば「コードはPythonで、型ヒントを必ず付けてほしい」「エラーの説明は原因→対処の順で書いてほしい」といった指示が有効だ。IT管理者であれば「M365のテナント設定に関する質問では、PowerShell Graphコマンドも必ず示してほしい」「英語ドキュメントを参照したときは日本語で要約してほしい」といった指示が実用的だ。 最初から完璧なメモリセットを作ろうとせず、使いながら「あ、毎回これを書いてるな」と気づいた時点でメモリに登録していく運用が現実的だろう。 会話の「コンテキスト継続」を使い倒す 会話スレッドの自動保存により、Copilotとのやり取りを後から参照・再開できる。複数日にまたがるプロジェクト検討や、同一テーマで繰り返し深掘りするシナリオで特に有効だ。「先週Copilotと話したあの議論の続きから始めたい」という使い方がより自然にできるようになる。 IT管理者の視点では、これらの変更は管理コンソールからの設定変更を必要としない。エンドユーザー側の体験改善として自動的に展開されるため、組織として特別な対応は不要だ。ただし展開状況が気になる場合はメッセージセンター（MC1174856・MC1158329）を確認しておくとよい。 筆者の見解 Copilot のメモリ機能は、登場した1年前から「ポテンシャルはある、ただ使いこなすまでの障壁が高い」という印象を持っていた。今回のUI改善と会話スレッドの自動保存は、その障壁を地道に下げようとする着実な改善だ。 こうした「基本操作の磨き込み」は地味に見えるが、競合するAIチャットサービスとの差を縮める上で重要な積み重ねだと思う。「会話が消えた」「設定が探せない」といった基本的なUXの問題は、それだけで離反を招きうる。その穴を塞ぐ今回の対応の方向性は正しい。 一方で、Copilotの本来の強みはM365エコシステムとの統合にある。Teamsの会議録、Outlookのメール処理、SharePointドキュメントの横断検索——M365内の業務文脈を丸ごと扱える点は、単独のAIチャットサービスが真似できない固有の領域だ。メモリ機能の充実とあわせて、この統合の強みをユーザーが実感できる体験にもっと磨きをかけてほしい。 Copilotが本来持っている力を、ユーザーが日常の業務の中で素直に実感できる体験に変えていく——そこが最大のチャンスだと感じている。 出典: この記事は Two Microsoft 365 Copilot Changes That Just Make Sense の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が SharePoint Online（OneDrive for Business を含む）向けに、ファイル単位でコールドストレージへアーカイブできる新機能「Microsoft 365 Archive ファイルレベルアーカイブ」を2026年7月に一般提供（GA）開始する。2024年5月にリリースされたサイト単位アーカイブからの進化であり、アクティブなサイトを停止することなく、放置されたファイルだけをコスト効率の高いストレージへ移動できるようになる。 サイト単位から「ファイル単位」へ——何が変わるのか Microsoft 365 Archive は2023年後半に登場し、2024年5月に GA となった SharePoint サイト全体のアーカイブ機能だ。サイトごとコールドストレージへ移すことでプライマリストレージを解放し、コストを削減する仕組みだった。しかし現場での運用では「サイト全体は使っているが、古いファイルだけ安くしたい」というニーズが強く、今回の機能強化はその声に直接応えるものとなる。 ファイルレベルアーカイブでは、ドキュメントライブラリ内の個別ファイル（またはアイテム）を選択的にコールドストレージへ移動できる。数年間アクセスされていない文書や、法務・コンプライアンス上の保持義務はあるが日常業務では使わないファイルが典型的な対象となる。 主要な仕様と維持される機能 注目すべき点は、アーカイブ後も以下の機能がそのまま維持されることだ： 検索性：アーカイブ済みファイルは Microsoft 365 の検索結果に引き続き表示される（2025年7月に追加されたエンドユーザー向け検索機能を含む） 秘密度ラベル：Microsoft Purview で設定した秘密度ラベルがアーカイブ後も有効に適用され続ける DLP ポリシー：データ損失防止ポリシーの対象として引き続き扱われる コンプライアンス保持：法令や社内ポリシーに基づく保持期間の管理が途切れない つまり「コスト削減のためにアーカイブしたら、ガバナンスが抜け穴になった」という問題が起きない設計になっている。 開発タイムライン 時期 マイルストーン 2024年5月 Microsoft 365 Archive（サイトレベル）GA 2025年2月 ファイルレベルアーカイブをロードマップに追加（ID: 477371） 2025年3月 再アクティブ化費用を廃止（ただし再アーカイブには120日の制限） 2025年7月 エンドユーザー向けアーカイブ済みコンテンツ検索機能を追加 2026年4月 パブリックプレビュー開始（Targeted Release） 2026年7月 全テナント向け GA 2026年後半 自動アーカイブポリシー（非アクティブ日数による自動移動）を計画 特筆すべきは2025年3月の「再アクティブ化費用の廃止」だ。当初は再アクティブ化に課金する設計だったが、顧客フィードバックを受けて撤廃した。現在は無料で再アクティブ化できるが、再アーカイブまでに120日の待機期間が設けられている。 2026年後半に予定される自動アーカイブポリシー GA と同時に完結する話ではなく、2026年後半に「X 日間非アクティブのファイルを自動的にアーカイブする」ポリシー機能が追加予定だ。SharePoint Advanced Management アドオンで提供されているサイトレベルのライフサイクルポリシーと同様の仕組みがファイル単位にも展開される見込みで、管理者が大量のファイルを手動で選ぶ手間がなくなる。 実務への影響 SharePoint 管理者・情報システム部門にとって、今回の機能は大きく3つの文脈で使える。 1. ストレージコストの段階的最適化 サイトを止めずにコスト削減できるため、「大規模なサイト整理プロジェクト」を立ち上げなくても継続的なコスト管理が可能になる。特に数年単位で蓄積されたドキュメントライブラリを抱える組織で効果が大きい。 2. コンプライアンス管理の簡素化 法令上の保持義務がある文書を「保持しつつ、プライマリストレージからは外す」という運用が整合的に行えるようになる。従来は保持ポリシーとストレージコストのバランスをとるために、別途アーカイブシステムを用意するケースもあったが、Microsoft 365 の範囲内で完結できる。 ...

Microsoftは2026年6月中旬より、SharePoint向けCopilot機能のプレビューをオプトインからオプトアウト方式へ切り替えた。Microsoft 365 Copilotライセンスを保有するテナントでは、管理者が明示的に無効化しない限り、SharePoint全体でCopilot機能が自動的に利用可能となる。 オプトアウトプレビューとは何か これまでのCopilotプレビューは、管理者やユーザーが意図的に「有効化」する「オプトイン」方式だった。今回の変更は、その逆——何もしなければ有効になるという「オプトアウト」方式への転換だ。 具体的には、Microsoft 365 Copilotライセンスが割り当てられているテナントの対象ユーザーに対して、次の領域でCopilot機能が利用可能になる。 SharePointサイト全体: サイト内コンテンツへの自然言語による質問・検索 ページ: ページ内容の要約や関連情報の提示 ドキュメントライブラリ: ファイル群を横断した情報抽出 リスト: リストデータへの自然言語クエリ 管理者がオフにしたい場合は、SharePoint管理センターから明示的に無効化する操作が必要となる。 日本のIT管理者が今すぐ確認すべきこと 1. ライセンス保有状況の確認 Microsoft 365 CopilotライセンスをE3/E5に追加購入しているテナントが対象だ。M365管理センター→ライセンスから保有状況を確認しよう。 2. 情報管理ポリシーとの整合性チェック SharePoint上に機密情報や未公開の業務データが存在する場合、Copilotが意図しない情報を要約・提示するリスクがある。Microsoft Purviewの機密ラベルおよびアクセス権設定が正しく構成されているかどうかを優先的に確認する必要がある。Copilotはアクセス権を無視しないが、「アクセス権が雑に設定されているサイト」では予期しない情報露出が起きうる。 3. 管理センターでの無効化手順 プレビュー期間中に無効化するには、SharePoint管理センター → 設定 → Copilot関連のトグルから操作する。管理センターのUIは随時更新されるため、Microsoftの公式ドキュメントを参照しながら設定すること。 4. ユーザー教育のタイミング 突然Copilotが使えるようになったユーザーが「何これ？」と混乱するケースは十分ありうる。有効化するのであれば、事前に簡単なアナウンスと使い方のガイドを用意しておくと現場の混乱を避けられる。 オプトアウト方式が意味するもの Microsoftがオプトアウト方式を採用した背景には、Copilotの利用率を引き上げたいという意図が透けて見える。オプトイン方式では「気づかなかった」「後回しにした」という理由で利用が広がりにくい。自動有効化によってユーザーに使ってもらい、価値を体感させる戦略だ。 ただし、IT管理者の立場からすると「知らないうちに有効になっていた」という状況は、ガバナンス上のリスクだ。特に金融・医療・官公庁など、コンプライアンス要件が厳しい業界では、有効化の前に法務・コンプライアンス部門との確認が必須になる。 筆者の見解 SharePointにCopilotが入ること自体は、方向性として正しいと思う。社内のドキュメント・リスト・ページを横断して自然言語で情報を引き出せるのは、SharePointを真剣に活用している現場には本当に便利な機能だからだ。 ただ、オプトアウト方式への切り替えは、管理者が「試す前に判断しなければならない」プレッシャーを生む。プレビューの段階でオプトアウトにするのであれば、セットアップガイドやガバナンスのベストプラクティスをもっと前面に押し出してほしかった。展開を急ぐあまり、管理者の準備が追いつかないシナリオは避けるべきだろう。 SharePoint Copilotを実際に活かすには、その前提として「SharePoin上の情報整理ができているか」が問われる。アクセス権がぐちゃぐちゃなまま、ラベルも未設定のまま有効化しても、Copilotは役に立つどころか問題の火種になりかねない。情報アーキテクチャを整えることへの投資——これが、Copilotの価値を最大化するための本当の第一歩だ。 MicrosoftにはSharePointを「真剣に使っている組織のためのプラットフォーム」として育てていく力が十分にある。Copilotをその柱の一本にするためにも、展開の丁寧さと情報管理の支援をセットで強化していくことを期待したい。 出典: この記事は Copilot in SharePoint moves to opt-out preview starting mid-June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Threat Intelligenceは2026年6月25日、欧州とアジアのホテル・旅行業界を標的とした多段階侵入キャンペーンを確認したと公式ブログで報告した。攻撃者は「写真テーマのZIPファイル」と偽の画像ショートカットを組み合わせ、検知を回避しながらNode.jsベースのインプラントを展開、標的システムへの永続的なアクセスを確立する手口を用いている。 攻撃の全体像：多段階で「無害に見せる」設計 今回確認されたキャンペーンの最大の特徴は、各段階で「無害なファイル」に見せる工夫が施されている点だ。攻撃の入口は写真ファイルに見せかけたZIPアーカイブ。内部には実際の画像ではなく、Windowsショートカット（.lnk）ファイルが仕込まれており、これを開くことで攻撃チェーンが始動する。 偽ショートカットはPowerShellやwscript.exeなどのシステム標準ツールを呼び出し、外部サーバーからペイロードを取得する「Living off the Land（LotL）」手法を採用。最終的にNode.jsランタイムを悪用したインプラントが展開され、攻撃者はC2（コマンド＆コントロール）サーバーとの通信を通じて、感染端末への継続的なアクセスを維持する。 なぜNode.jsが使われるのか Node.jsはWebアプリケーション開発で広く使われる正規のランタイム環境だ。多くの企業環境でインストール済みか、インストールが許可されているため、セキュリティソフトのホワイトリストを通過しやすい。また、JavaScriptベースのマルウェアは難読化が容易で、署名ベースの検知を回避しやすいという特性もある。 攻撃者がカスタムマルウェアを書く代わりに「正規ツール＋スクリプト」を組み合わせるアプローチは、近年の高度な脅威グループが多用する手口だ。企業の監視ツールが「既知の悪意あるバイナリ」を探すのに対し、正規のnode.exeが走っているだけでは検知トリガーがかかりにくい。 なぜホスピタリティ業界が狙われるのか ホテルや旅行代理店は、サイバー攻撃者にとって魅力的なターゲットを複数抱えている。 クレジットカード情報と個人データの宝庫：チェックインやオンライン予約のフローには、決済情報・パスポート番号・滞在履歴など価値の高い個人情報が集中する。 写真ファイルへの心理的抵抗が低い：旅行業界ではホテルの客室写真や観光スポットの画像を日常的にやり取りする文化がある。「写真ZIP」という偽装は、この業種の業務フローにフィットしたソーシャルエンジニアリングと言える。 サードパーティとの接続が多い：OTA（Online Travel Agency）、決済ゲートウェイ、予約システムなど多数の外部サービスと連携しているため、侵害後のラテラルムーブメント（横方向への移動）や二次被害の範囲が広がりやすい。 実務への影響：日本のIT管理者がとるべき対策 日本でも欧州・アジアをまたぐ旅行業・ホテルチェーンは多数存在する。今回のキャンペーンは日本を明示的なターゲットとは報告されていないが、「アジア」という記述から対岸の火事と見るのは危険だ。 即時確認事項 エンドポイントでのNode.jsの実行ポリシーを確認する。業務で不要な環境にインストールされていないか棚卸しを行う .lnkファイルの実行をグループポリシーで制限する（特にメール添付・ダウンロードフォルダ内からの実行） 外部ZIPファイルを開く前のサンドボックス検査フローを整備する 中長期の対策 Microsoft Defender for Endpointを導入済みの環境では、「Attack Surface Reduction（ASR）ルール」の有効化を確認する。LotL攻撃に対して特に有効なルールが複数存在する 不審なプロセスの親子関係（wscript.exe → powershell.exe → node.exe など）を検知するための行動ベースのルールをSIEMに追加する 写真・画像ファイルを業務でやり取りする部門には、「拡張子を必ず確認する」「ショートカットファイル（.lnk）に注意する」という具体的なフィッシング訓練を実施する 筆者の見解 セキュリティの話は細かい話が多くてあまり好きではないのだが、今回のキャンペーンは「攻撃者の設計思想」として純粋に興味深い。ショートカットファイル→LotL→Node.jsインプラントという構成は、「バイナリを落とさない」「正規プロセスの中に隠れる」という方向性が一貫しており、完成度が高い。 この種の攻撃が増えている背景として、従来の「既知のマルウェアを検知する」モデルが限界を迎えつつあることがある。もはや「見知らぬ実行ファイルが来たら止める」では足りない。プロセスの挙動・ネットワーク通信の文脈・ユーザーの行動パターンを総合的に見る「ゼロトラスト的な行動分析」が必要になっている。 Microsoft Defender for Endpointは、こうした行動ベースの検知においてかなりの水準に達してきている。今回の脅威インテリジェンスを自社製品の検知シグネチャに素早くフィードバックできるエコシステムは、Microsoft統合環境の強みだ。セキュリティ対策をバラバラのポイントソリューションで積み上げるより、M365 E5レベルの統合環境で一元管理する方向性は、こういうケースで特に力を発揮する。 日本の企業、特に大手ホテルチェーンや旅行業者は、クレジットカード情報を大量に扱いながらもIT部門が手薄なケースが珍しくない。「今動いているから大丈夫」という感覚は通用しない時代に入っている。今回のMicrosoftの報告を機に、自社のエンドポイント保護とプロセス監視の現状を棚卸しする価値は十分にある。 出典: この記事は Photo ZIP campaign targeting hospitality industry delivers Node.js implant for persistent access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、SharePointに組み込まれたAI機能「AI in SharePoint」に対して、業務固有の処理手順を自然言語で定義・再利用できる「カスタムスキル（Custom Skills）」機能を追加し、2026年7月初旬のGA（一般提供）完了に向けてロールアウトを進めている。 カスタムスキルとは何か カスタムスキルとは、SharePoint上のAIに対して「この種の文書を処理するときはこう動け」という手順を事前に登録しておく仕組みだ。たとえば「コンプライアンス審査書類を受け取ったら、〇〇の観点でチェックして、標準フォーマットで結果をまとめる」といった複数ステップの処理を、自然言語で記述するだけで定義できる。 作成したスキルはMarkdown形式（.md）のファイルとして、各SharePointサイトの「Agent Assets」ライブラリ（/Agent Assets/Skills/<スキル名>/SKILL.md）に保存される。ユーザーはスキルを名前で直接呼び出すことも、クエリの内容に応じてAIが自動的に適切なスキルを選択することも可能だ。 技術仕様と権限モデル この機能で押さえておくべきポイントを整理する。 誰が作成・利用できるか 作成: 対象SharePointサイトの編集権限（Edit）を持つユーザー 利用: 閲覧権限（Read）以上を持つユーザー テナント管理者による一括オン/オフの設定は存在せず、デフォルトで有効 できること・できないこと できること: SharePoint内のコンテンツ理解、リスト操作、フォルダ整理、その他SharePoint標準アクション できないこと: 外部システムへの接続、カスタムコードの実行 ガバナンス面 スキルはMarkdownファイルなので、既存のSharePoint権限ポリシー・保持ポリシー・コンプライアンスポリシーがそのまま適用される Agent Assetsライブラリの権限継承を切ることで、スキルの作成・利用者を絞り込む運用も可能 なぜこれが重要か——日本のIT現場への影響 これまで「AIに業務ルールを覚えさせる」には、Copilot Studioや外部ツールでのプロンプト管理が必要だった。それなりの技術知識と管理コストがかかる上、SharePointのドキュメント処理と組み合わせる際の連携も煩雑だった。 カスタムスキルはその障壁を大幅に下げる。SharePointを日常的に使っているパワーユーザーやサイトオーナーが、自分たちの業務ルールをそのままAIに教えられる。「AI活用はIT部門が管理するもの」という従来の構図から、「現場が自分でAIの振る舞いをカスタマイズする」構図へのシフトが、Microsoft 365の中で静かに始まっている。 とくにSharePointをイントラネットや文書管理基盤として活用している企業では、コンプライアンスチェック・契約書レビュー・稟議書の形式確認といった繰り返し業務への適用が現実的な最初のステップになるだろう。 実務での活用ポイント 管理者が今すぐやるべきこと 権限の棚卸し: 編集権限を持つユーザーが意図せずスキルを量産するリスクがある。Agent Assetsライブラリの権限継承を見直し、「スキルを作れるのは誰か」を明示的に決めておく 命名規則を決める: スキルはMarkdownファイルとして蓄積されていく。ファイル名・説明文の命名規則をあらかじめ整備しないと、後で「誰が何のために作ったスキルか」がわからなくなる ガイドラインの更新: 社内のAI利用ポリシーや情報セキュリティガイドラインに、スキルの作成・管理に関する項目を追加しておく エンジニア・パワーユーザーが試すべきユースケース 社内規程や用語集を参照しながら文書を審査するスキル 入力文書のフォーマットを標準テンプレートに変換するスキル 特定のリストやフォルダを整理・分類するスキル まずは繰り返し頻度が高く、「やり方が決まっている」業務から試すのが鉄則だ。 筆者の見解 この機能の設計思想は正直「悪くない」と思っている。スキルをMarkdownファイルとして既存のSharePoint権限管理に乗せた点は、新しいガバナンスレイヤーを作らずに済むという意味で堅実だ。「作れる人と使える人を分けて、既存の権限モデルで制御する」というアプローチは、エンタープライズ現場の実情をよく理解している設計だと感じる。 一方で、「外部システム接続不可・カスタムコード実行不可」という制約は、現時点では仕方ないとしても、今後どこまで拡張できるかが肝心だ。SharePoint単体で閉じた業務には十分機能するが、基幹システムや外部APIと連携したい場面ではすぐに壁にぶつかる。そこはCopilot StudioやAzure AI Foundryとの役割分担を明確にしてほしいところだ。 MicrosoftがSharePoint内AIを「現場がカスタマイズできるプラットフォーム」として育てようとしている方向性は支持したい。あとはその方向性を、CopilotやFoundryなどの周辺機能と一貫したストーリーで説明しきる力があるかどうか。ユーザーが「どれを使えばいいのか」と迷わずに済む整理を、早めに出してほしいと思っている。 出典: この記事は Extending AI in SharePoint using custom skills — GA rollout in progress の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365が2026年6月に大規模アップデートを実施した。Microsoft TeamsはAIが録音や文字起こしを保存せず会議要約を生成できるプライバシー重視の新機能を追加し、同時にWordやExcelなどOfficeアプリのCopilot機能は有償ライセンス必須へと移行した。 TeamsのAI議事録が「録音なし」で動くようになった これまでTeamsのAI議事録（Intelligent Recap）は、録音または文字起こしを保存した会議にしか機能しなかった。6月からはその制約が緩和され、録音・文字起こしのデータをクラウドに残さなくても、AIがリアルタイムで会議の要点・決定事項・アクションアイテムを生成できるオプションが提供される。 これはM365 Copilotの有償ユーザー向けに展開される機能で、会議内容の保持を最小化しながら議事録だけを残したいというニーズに応えるものだ。医療・法律・金融といったコンプライアンス要件が厳しい業種や、個人情報や機密情報が飛び交う会議での活用が期待される。 日本においても、録音データの保存に対して心理的・法的なハードルを感じる組織は少なくない。この機能により「議事録は欲しいが録音は残したくない」というジレンマが解消される可能性がある。 Word・Excel の Copilot が有償ライセンス必須に 2026年4月15日付けで、Word・Excel・PowerPoint・OneNoteに組み込まれていたCopilot機能は、M365 Copilot（有償ライセンス）を保有していないユーザー向けには無効化された。6月は多くの組織でライセンス更新が集中する時期であり、この変更の影響を受けるユーザーが一気に顕在化している。 無償で引き続き使える機能は「Copilot Chat（Basic）」のみで、M365 Copilot アプリやWebブラウザからのチャット機能はライセンスなしでも利用できる。OutlookのCopilot機能も当面は広く提供が継続される。 テナントの規模によって扱いが異なる点も注意が必要だ。 大規模テナント（約2,000ユーザー超）: 有償ライセンスなしではOfficeアプリ内のCopilotが完全に無効 中小テナント: ChatのみのStandardアクセスが残る場合があるが、Word・ExcelのAI機能は同様に有償ライセンスが必要 2026年6月30日が期限：Copilotプロモ価格が終了 M365 Copilotの定価は1ユーザー月額約30ドル（税別）だが、Microsoft は「Copilot Business」として1ユーザー月額約18ドルのプロモーション価格を提供してきた。このプロモーションが6月30日をもって終了する。 日本法人での導入を検討しているIT部門は、7月以降は通常価格での見積もりが必要になる。試験導入の稟議を通したばかりの組織は予算の見直しが急務だ。 SharePoint スタンドアロンプランが販売終了 旧来から提供されていたSharePointのスタンドアロンプランは2026年5月31日に新規販売を停止、完全廃止は2029年12月の予定だ。SharePoint単体プランで契約していた組織は、M365スイートへの移行計画を立てる必要がある。 実務への影響 IT管理者が今すぐすべきこと： ライセンス棚卸し: 誰がOfficeアプリ内Copilotを日常的に使っているかを確認する。全員に一律付与はコスト過剰、必要な人に付与しないと生産性損失——最悪のパターンを避けるためにも使用状況の確認が先決 6月30日前の意思決定: Copilotプロモ価格の終了前にライセンス数を確定させるか、7月以降の正規価格で予算を組み直すかの判断が必要 Teams議事録ポリシーの見直し: 録音なしのAI要約が利用できるようになることで、会議ポリシーを更新できる。特にコンプライアンス部門との連携が効果的 SharePoint移行計画: スタンドアロンプランを利用中の組織は廃止スケジュールに合わせた移行ロードマップを今から準備する 筆者の見解 今回の一連の変更の中で、最も評価できるのはTeamsのAI議事録機能の「録音なし」オプションだ。会議コンテンツのプライバシー管理という、長年現場から声が上がっていた課題に対する実質的な答えが出た形で、方向性は正しい。 一方で、Copilot機能の有償化と価格体系の複雑化については、正直に言えば「もったいない」と感じる。Microsoftが持つOffice統合という他社には真似できない強みを活かせるプラットフォームがM365であるだけに、ライセンス管理の煩雑さが現場のCopilot活用の足かせになっているとすれば、本来の実力を発揮できていないことになる。 Copilotの機能そのものの進化は続いている。TeamsやOutlookとの深い統合は、スタンドアロンのAIツールでは実現しにくい体験だ。日本のIT部門には、「禁止か全員導入か」の二択ではなく、業務ロール別に最適なライセンス構成を設計するアプローチをお勧めしたい。使う人に適切に届けることで、初めてM365 Copilotの投資対効果が見えてくる。 6月は変化の多い月だった。7月以降の価格体系が固まった今こそ、M365ライセンス全体を整理する好機でもある。 出典: この記事は Microsoft Teams to offer AI-powered meeting recap without saving recording or transcript の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 CopilotのPlanner Agentを全世界で一般提供（GA）開始した。Copilotライセンスを保有するすべてのユーザーに自動インストールされ、Microsoft Plannerのタスク管理をAIとの自然言語対話で操作できるようになる。 Planner Agentとは何か Planner Agentは、Microsoft 365 Copilotのチャット画面からPlannerのタスクを自然言語で操作できるAIエージェントだ。「来週のリリースに向けてやるべきことをリストアップして」「このタスクを鈴木さんに割り当てて期限を金曜にして」といった指示を日本語で入力するだけで、Plannerのプランが自動生成・更新される。 従来のPlanner操作は、Web UIやTeamsアプリを開いてバケツ・タスク・担当者・期限をそれぞれクリックして入力する手順が必要だった。これをチャット一言で済ませられるのが最大の変化点だ。 「ドラフトモード」が安全性のカギ Planner Agentの重要な設計思想がドラフトモードだ。AIが生成したタスク計画は、いきなりPlannerに書き込まれるのではなく、まず「こういう計画を立てました、確認してください」という形でチャット画面に提示される。ユーザーが承認（Approve）ボタンを押して初めて実際のPlannerに反映される。 これはAIエージェントが普及する中で非常に重要な設計だ。「AIが勝手に動いて業務データを書き換えた」という事故を防ぐ仕組みであり、Human-in-the-loop（人間が意思決定の要所に介在する）アーキテクチャの典型例と言える。 実務での活用ポイント プロジェクトキックオフ直後の計画立案に効く。「〇〇プロジェクトのWBSをPlanner化して」とCopilotに依頼し、AIが叩き台を作った後で人間がレビュー・承認するフローは、特に定例的なプロジェクト構成のある業種（SI、製造、コンサルなど）で時間短縮効果が高い。 週次レビューの棚卸しにも使える。「今週完了していないタスクを整理して、来週に繰り越す優先度を教えて」という使い方は、プロジェクトマネージャーの定例作業と相性が良い。 なお、Planner Agentの利用にはMicrosoft 365 Copilotライセンス（ユーザーライセンス月額約4,500円前後）が必要だ。Copilotライセンスを持つユーザーへは自動インストールされるが、IT管理者はMicrosoft 365管理センター→統合アプリから展開設定を確認・制御できる。ガバナンス上、一斉展開前にポリシーの見直しを推奨する。 筆者の見解 Planner Agentのドラフトモードは、正しいアーキテクチャの選択だと思う。AIエージェントが業務データを直接書き換えるリスクを最小化しつつ、操作の手間を削減するバランスが取れている。「AIに任せきりにする」のではなく「AIに案を出させて人間が判断する」というフローを標準化した点は評価できる。 ただし、Planner自体の普及度が課題だ。日本のMicrosoft 365環境では、PlannerよりもExcelやSharePointリストでタスク管理している組織がまだ多い。エージェントがいくら賢くなっても、そもそもPlannerを使っていなければ恩恵は届かない。Microsoftには、PlannerとExcel・SharePointの連携をもっと自然にする投資も同時に進めてほしいと思う。 Copilotが「個別機能のAI化」から「ワークフロー全体を動かすエージェント」へと進化しているのは確かな方向性だ。Planner AgentのGA発表は、その第一歩として意味がある。ただし、この良い取り組みが正しく評価されるかどうかは、実際のユーザー体験の質次第。「承認ボタンを押したら意図と違う結果になった」が繰り返されれば、信頼は積み上がらない。品質維持の継続的な取り組みに期待したい。 出典: この記事は Planner Agent in Microsoft 365 Copilot is now generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が AIエージェント管理基盤「Agent 365」の一般提供（GA）を開始し、コンテキストマッピング・ポリシーベース制御・ランタイムブロック＆アラートの各機能を Intune および Microsoft Defender との連携パブリックプレビューとして展開した。 Agent 365とは何か Agent 365は、Microsoft 365環境に展開されたAIエージェント（Copilot Studio製エージェントや外部連携エージェントを含む）を組織として一元管理するためのプラットフォームだ。 従来、企業がCopilot StudioなどでAIエージェントを作成・展開する際、「どのエージェントが何にアクセスしているか」「どんな権限で動いているか」を把握する手段が限られていた。Agent 365はこの可視性の欠如に正面から対応する。 コンテキストマッピング エージェントが利用するデータソース、ツール、APIを可視化し、「このエージェントはどのリソースに触れているか」をマップ上で把握できるようにする機能だ。セキュリティ監査の際に手動で棚卸しをしていた作業が大幅に効率化される。 ポリシーベース制御 組織ポリシーに基づいてエージェントの動作を制限できる。「特定のデータへのアクセスは禁止」「この部門では特定ツールの呼び出しを制限」といったルールを、コードを書かずにポリシーとして定義・適用できる。 ランタイムブロック＆アラート エージェントが実行中に不審な動作や許可されていない操作を試みた際、リアルタイムでブロックしてアラートを飛ばす機能。事後の調査ではなく、インシデント発生前の遮断が可能になる。 IntuneとDefender連携のパブリックプレビュー Intune連携では、デバイス管理の観点からAIエージェントを統制する。どのデバイスからエージェントが起動しているか、コンプライアンスポリシーを満たしたデバイスからのみ利用を許可する、といった制御が可能になる。 Defender連携では、脅威インテリジェンスと連動したリスク評価がエージェントにも適用される。既存のSecurity Operations Centerのワークフローに、AIエージェント由来のインシデントを自然に組み込める点が大きい。 日本のIT現場への影響 日本企業でもCopilot StudioによるAIエージェント開発が本格化しつつある。しかし実際に現場で聞くのは「作ったはいいが、管理できていない」「どのエージェントが何にアクセスしているか把握できていない」という声だ。 Agent 365のGAは、この「野良エージェント問題」に公式の解決策が提供されたことを意味する。IT管理者にとっては待望の機能と言える。 明日から使える実務ポイント まず棚卸しから始める: コンテキストマッピングを使い、現在の環境に存在するAIエージェントとそのアクセス先を把握する。知らないエージェントが動いていた、という発見がある可能性が高い ポリシーは「禁止」ではなく「条件付き許可」で設計する: 全面禁止は必ず回避される。「この条件を満たせば使える」という設計にすることで、ユーザーが抜け道を探す動機を減らせる Defenderとのアラート統合を優先する: すでにDefenderを使っているSOCチームがある組織は、エージェント由来のアラートを既存のインシデント対応フローに載せることが最短経路だ NHIとしてエージェントを扱う意識を持つ: AIエージェントは「Non-Human Identity（NHI）」の一種だ。最小権限・Just-In-Timeアクセスの原則を人間ユーザーと同様に適用することが、長期的な管理の鍵になる 筆者の見解 AIエージェントをただ使い始めるのではなく、「管理できる状態で使う」基盤を整えることの重要性を、MicrosoftがAgent 365でプラットフォームとして提供したことは評価できる。 特に注目しているのはNHI（Non-Human Identity）としてのエージェント管理という視点だ。サービスアカウントや自動化スクリプトが「管理されていない特権ID」として放置されてきた歴史と同じ失敗を、AIエージェントでは繰り返してほしくない。Agent 365が提供する可視化とポリシー制御は、その意味で方向性として正しい。 IntuneやDefenderとの統合も、M365が統合して使うことで価値を発揮するプラットフォームであることを体現している。今後ポリシー管理がEntra IDのConditional Accessと深く連携するようになれば、さらに実用的な統制基盤になる可能性がある。 一方で、「ガバナンスの仕組みがある」と「実際に使いこなせる」は別の話だ。中堅〜中小規模の組織では、Intune・Defender・Agent 365の3製品を適切に連携させるためのスキルセットとリソースが課題になるだろう。機能を提供するだけでなく、導入をシンプルにするガイダンスや自動化テンプレートの整備も期待したいところだ。正面から勝負できる製品ポートフォリオを持っているのだから、使いこなしやすさの部分でも引っ張っていってほしい。 出典: この記事は Microsoft Agent 365, now generally available, expands capabilities and integrations の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年7月から、Microsoft 365 E3/E5ユーザーを対象にIntune Suite機能群とDefender for Office 365 Plan 1を追加付与する。同時期に実施されるクラウド製品の価格改定と合わせた施策で、既存ライセンスの価値が大幅に向上する。 E3/E5ユーザーに追加される機能 Microsoft 365 E3・EMS E3ユーザー Intune Remote Help — リモートからのデバイスサポートを可能にするリモートアシスタンス機能 Intune Advanced Analytics — デバイスの正常性・コンプライアンス状況の高度な分析機能 Intune Plan 2 — より高度なデバイス管理機能を含む上位プラン Defender for Office 365 Plan 1 — 高度なフィッシング対策・安全なリンク・添付ファイルスキャンなど、Exchange Online Protectionに加わるメールセキュリティ強化 Microsoft 365 E5ユーザー（E3の追加機能に加えてさらに） Endpoint Privilege Management（Intune Privilege Management） — エンドポイント権限管理。最小権限原則の実装を自動化する機能 Enterprise Application Management（Intune Application Management） — エンタープライズアプリの一元管理 Microsoft Cloud PKI — クラウドベースの証明書インフラ（PKI）管理サービス ロールアウトのスケジュール ロールアウトは2026年CY Q3（7月）に開始し、2026年8月1日までに完了予定。テナント管理者側での特別な作業は一切不要で、Microsoftが自動的に有効化する。 各テナントへの適用の30日前にメッセージセンターで事前通知が届く仕組みになっている。通知を見落とさないよう、管理センターのメッセージセンターのアラート設定を事前に確認しておくことを勧める。 価格改定との関係 今回の機能追加は、2026年7月1日実施のクラウド製品価格改定と合わせた施策だ。改定対象の主なライセンスは以下の通り： Microsoft 365 E3/E5、Office 365 E3/E5 Enterprise Mobility and Security（EMS）E3/E5 Microsoft 365 Business Basic/Business Standard Microsoft 365 F1/F3、G3/G5 Microsoft Entra P1/P2 Windows Enterprise、Microsoft 365 Apps for Business/Enterprise なお、Microsoft 365 Business Premiumは今回の価格改定の対象外となっている点は押さえておきたい。 ...