M365

2026年4月1日より、Microsoft Teamsの「Shared Device」ライセンスが「Teams Shared Space」に改称されました。名前が変わっただけではなく、1ライセンスで最大4スペースを管理できる柔軟な体系に刷新されています。受付や会議室といった共用端末の管理コスト削減に直結する変更であり、ハイブリッドワークが定着した今の日本企業には見逃せないアップデートです。 何が変わったのか：「デバイス」から「スペース」へ これまでの「Teams Shared Device」は、文字通り「1台の共有デバイス」に紐づくライセンス体系でした。今回の変更で「Teams Shared Space」に改称されるとともに、概念が「デバイス単位」から「物理スペース単位」へシフトしています。 同一フロアの複数会議室や複数のキオスク端末を1ライセンスでまとめてカバーできるようになるため、管理の粒度が変わります。会議室10部屋を管理する場合、従来は10ライセンス必要だったところが実質3ライセンスに近い形でカバーできる計算になり、大規模オフィスほど削減効果は顕著です。 対象となる主なシナリオ 受付・フロントデスク: 来客対応用キオスク端末 会議室・カンファレンスルーム: Microsoft Teams Roomsと組み合わせたスペース 共用ラウンジ・オープンスペース: 一時利用の作業スペース 製造・現場の情報端末: 工場・倉庫のフロア端末 とりわけTeams Roomsの普及が進みつつある日本のオフィス環境では、今回の変更による恩恵を受けやすい状況です。 実務への影響：今すぐ確認すべき4つのポイント 1. 既存ライセンスの棚卸し Microsoft 365管理センターで現在のShared Deviceライセンス割り当て状況を確認し、新体系に移行した場合のコスト試算を行いましょう。 2. スペース割り当ての設計 1ライセンスに対して最大4スペースを割り当てる論理設計が必要になります。フロア別・エリア別など、グループ分けの方針を事前に整理しておくと移行がスムーズです。 3. Teams Rooms との組み合わせ確認 ハードウェア要件やサポート範囲が変わる可能性があるため、Microsoft Teams RoomsデバイスとShared Spaceライセンスの組み合わせ可否は公式ドキュメントで必ず確認してください。 4. テナント管理者への情報共有 4月1日以降に適用される変更です。未対応の場合は優先して社内の担当者と情報を共有し、移行計画を立てましょう。 筆者の見解 今回の変更は、Microsoftが「デバイス管理」から「空間（スペース）管理」へ軸足を移した動きとして捉えています。Teams Roomsの普及に合わせた自然な進化であり、ハイブリッドワーク時代のオフィス設計を意識した方向性は評価できます。 ライセンス体系の「複雑化ではなく整理」という点も好ましいと感じます。IT管理者を苦しめてきた細かいSKUの乱立に比べれば、シンプルな4スペース単位への統合は歓迎すべき姿勢です。 一方で「4スペースという上限設定の根拠」はもう少し丁寧に説明してほしいところです。大規模な製造現場やキャンパス型オフィスでは、4スペース単位では管理しにくいケースも出てくるでしょう。エンタープライズ向けのさらなる柔軟性には今後の拡張を期待したいと思います。 それよりも重要なのは、この機会に会議室のデジタル化の全体設計を見直すことです。ライセンス体系だけ最適化しても、会議室予約、入室管理、録画・文字起こしが統合されていなければ意味がありません。M365のプラットフォームは統合して使い倒してこそ真価を発揮します。今回のアップデートをきっかけに、Teams Roomsを含む会議室インフラの全体最適に取り組む企業が増えることを期待しています。 出典: この記事は Microsoft Teams Licensing Updates FAQ Effective April 1, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SharePointといえば、Microsoft 365の中でも「機能は多いのになぜか嫌われる」プロダクトの代表格だった。それがついに本腰を入れた刷新を迎える。Microsoftは次世代SharePoint体験を正式に発表し、AIを基盤レベルから組み込んだ新UIの一般提供（GA）を2026年4月に予定している。単なるデザインリフレッシュではなく、情報アーキテクチャそのものを再設計するというのが今回の核心だ。 3つの軸で再設計される情報アーキテクチャ 新SharePointは「知識の発見（Discover）」「コンテンツの公開（Publish）」「ソリューションの構築（Build）」という3つのコア領域を軸に作り直された。現行のアプリバーはこれら3つのナビゲーションに一新され、「今何をしたいのか」をUIが先導する設計になっている。 Microsoftが明言しているのは「統一されたデザイン言語（Cohesive Design Language）」と「情報アーキテクチャの更新」の2点。TeamsやOutlookといった他のM365製品との操作感の統一も進み、「M365なのにツールごとに使い勝手が違う」という長年の不満に応えようとしている。 AI基盤の整備——プラットフォーム自体の知能化 今回の発表で最も注目すべきは、ロードマップに記載された「この更新がAI支援型コンテンツ作成の基盤を確立する（establishes the foundation for AI-assisted creation across the product）」という一文だ。 現状でも生成AI機能はM365全体で提供されているが、今回はSharePointというプラットフォーム自体をAIネイティブな構造に変えることを意味する。自然言語でのWebパーツ追加、ページレイアウトの自動提案、コンテンツ整理の自動化——こうした機能が実現しやすくなる土台を今回の刷新で作るということだ。 これはAIライセンスの有無に関わらず、SharePoint自体が賢くなる方向性であり、長期的な運用コスト削減につながる変化と捉えられる。 M365共有体験の刷新——「ヒーローリンク」の登場 SharePointと並行して、M365全体の共有機能も第3世代に進化する。新機能の核は「ヒーローリンク（Hero Link）」だ。「1本のリンクでファイルへのアクセス制御を一元管理する」という考え方で、現状では散在しがちな権限設定を整理する。SharePointとOneDriveの機能境界が曖昧な問題への間接的な回答にもなっており、こちらも2026年4月からのロールアウト開始が予定されている。 実務への影響 SharePoint管理者・イントラネット担当者 にとって最初の安心材料は、既存サイトのブランディング（テーマカラーやロゴ）が維持されたまま新UIに移行することをMicrosoftが明言している点だ。大規模なサイト再構築を強いられる心配は今のところ少ない。 一方、AI基盤の整備 は長期的に大きな意味を持つ。SharePointをベースにした社内ポータルやナレッジベースが、今後のAI機能拡充の恩恵を直接受ける立場になる。今から「SharePointに情報を集約する」方針を取っておくことは、将来の自動化・AI活用への布石になる。 権限管理の観点 では、ヒーローリンクの導入で外部共有の誤設定リスクを減らす効果が期待できる。情報セキュリティポリシーの運用においても、「誰が何にアクセスできるか」の可視化が改善されることは現場の担当者にとって実務的なメリットだ。 筆者の見解 SharePointは長年、「機能は多いのに使いこなせない」という評価が定着していた。日本中の企業に「作ったが誰も更新しない」イントラネットサイトが眠っているのではないだろうか。今回の刷新はそこに本気で向き合ったアップデートだと感じる。 特にAIによるページ作成支援が本物になれば、「SharePointを触ったことがない社員が自分でコンテンツを更新できる」世界が近づく。それが実現すれば、情報システム部門の運用負荷は劇的に変わりうる。SharePoint・OneDrive・Teams・Entra・Purviewを横断した統合プラットフォームとしての強みは、他社が簡単に追随できない本物の資産だ。今回のリデザインがそのポテンシャルを正面から引き出すものになることを期待している。 ただし、M365の機能追加は「発表→プレビュー→GA→実際に安定して使えるまでさらに数ヶ月」というサイクルが珍しくない。2026年4月GAは予定通り進んでいるが、実際の体験がロードマップ通りになるかどうかはプレビュー期間中の評価を見てから判断するのが賢明だ。焦って既存の運用を変えるより、まずプレビューで触ってみることから始めるのをお勧めする。 出典: この記事は Microsoft has big plans for the next generation of SharePoint の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 365のCloud PCをPower AutomateやAzure Logic Appsから直接操作できる「Windows 365 Power Platform コネクタ」がパブリックプレビューとして公開された。Cloud PCの払い出しから回収まで、これまで手作業や専用スクリプトに頼っていた管理フローを自動化できる時代がついやってきた。IT管理者にとって、これは単なる機能追加ではなく、クラウドPC運用の設計思想を見直す契機になりうる。 Windows 365 Power Platform コネクタとは 従来、Windows 365のCloud PCに関する操作——プロビジョニング、リサイズ、解放など——は、Intuneの管理センターを手動で操作するか、Microsoft Graph APIを直接叩くしかなかった。今回のパブリックプレビューで登場した公式コネクタは、Power AutomateやAzure Logic Appsから直接Cloud PCを操作できる橋渡し役だ。 たとえば、以下のようなシナリオが「コードなし」または「低コード」で実装できる： オンボーディング自動化: 人事システムへの新入社員登録を検知し、自動でCloud PCをプロビジョニング オフボーディング自動化: Entra IDからのユーザー削除をトリガーに、Cloud PCを自動で回収・解放 コスト最適化: 長期未使用のCloud PCを定期検出して管理者へ通知、または自動停止 同時発表されたその他の更新 Windows 365 Reserve のユーザー自己プロビジョニング（パブリックプレビュー） これまで管理者起点だったCloud PCの払い出しを、ユーザー自身がWindows Appから実行できるようになった。端末の故障時や出張先での緊急アクセスなど「今すぐ環境が必要」な場面に対応する。管理者はEntra IDのグループ単位で対象を絞り込めるため、全員に開放せず特定のユーザー層だけに許可するといった細かい制御も可能だ。デフォルトはオフで、既存の管理統制を崩さず段階的に展開できる点は評価に値する。 Cloud PC モニタリング（パブリックプレビュー） Intune管理センターに専用ダッシュボードが追加され、Cloud PCの接続健全性、パフォーマンスデータ、ユーザーレベル・デバイスレベルのインサイトを一元的に確認できる。問題の早期検出やヘルプデスク対応を効率化するための機能で、これまで別ツールで補っていた可視性をプラットフォーム内に取り込む方向性が見える。 Azure Network Connection ヘルスチェックの厳格化 2026年4月以降、ANC（Azure Network Connection）のヘルスチェックで必須エンドポイント（*.service.windows.cloud.microsoft など）への疎通が取れない場合、従来の「警告」から「エラー」に格上げされ、新規Cloud PCのプロビジョニングがブロックされる。新たなエンドポイント追加ではなく既存要件の厳格化だが、ファイアウォールやプロキシで通信を管理している環境では見落とすと痛い。すでに展開済みのため、心当たりがある場合は速やかに疎通確認を行いたい。 実務への影響 日本のIT現場で最もインパクトが大きいのは、Power Platform コネクタによる自動化の民主化だろう。 Graph API経由でCloud PCを制御しようとすると、これまでは相応の開発スキルが必要だった。Power Automateであれば、プログラミング経験が限られているIT担当者でもワークフローを組める。特に開発リソースを持たない情報システム部門や中堅・中小企業にとっては、実装コストの大幅な低下を意味する。 一方でANCの要件変更は即座に対応が必要な項目だ。新規プロビジョニングがエラーでブロックされてから気づくのでは遅い。ネットワーク担当者と連携して、該当エンドポイントのホワイトリスト登録状況を確認しておくことを強くお勧めする。 筆者の見解 「統合プラットフォームとして使うことで価値が出る」——Microsoft 365を長年見てきた中で変わらない信念だ。今回のPower Platformコネクタはまさにその方向性の具現化と言える。 ...

Microsoftが毎月恒例の「What’s new in Power Platform」として、2026年4月版のアップデート情報を公式ブログで公開した。今回の更新はAI機能の実用性向上とM365エコシステムとのさらなる統合深化が軸になっており、Power Automateを日常業務に使っている組織には見逃せない内容が揃っている。 Power Automate × Copilot Studioの連携強化 今回の目玉のひとつが、Power AutomateとCopilot Studioの統合がより深まった点だ。これまではCopilot Studioで作成したボットとフローを連携させるには、ある程度の設定コストが必要だった。新しいアップデートでは、Copilot Studio上のエージェント（Agent）がPower Automateのフローを直接トリガー・参照できる仕組みが整備されており、「対話→自動化」の流れをよりシームレスに組めるようになっている。 たとえば、社内ヘルプデスクのボットが問い合わせを受け取り、内容に応じてバックエンドのフロー（TicketシステムへのAPI呼び出しや承認ルーティングなど）を自動で走らせる、といった構成が格段に組みやすくなった。「アシスタントが答えるだけ」から「アシスタントが実際に動かす」への進化と捉えていい。 Power AppsへのAI機能追加 Power Appsでは、AI Builderとの統合がさらに前進した。フォームや一覧画面に対してAIによる自動分類・要約・インサイト生成が組み込みやすくなっており、ノーコード・ローコードの範囲で「AIを使ったアプリ」が作れるバーが下がっている。 特に注目したいのは、自然言語でアプリの動作条件やデータ変換ロジックを記述できるコパイロット支援機能の改善だ。Power Fxを書いたことがない非エンジニアでも、「売上が前月比で10%以上落ちたらアラートを出す」といった要件を自然言語で入力するだけで、ある程度動くアプリが生成されるようになりつつある。 M365エコシステムとの統合深化 SharePoint・Teams・Outlookとの連携がさらに強化され、M365のデータをPower Platformからシームレスに読み書きできる範囲が広がっている。これはMicrosoftが一貫して推進する「M365をプラットフォームとして使う」という方向性の延長線上にある。 Teamsでの承認フローやOutlookからのデータトリガーといった定番ユースケースも、設定ステップが減り、より安定して動作するよう改善されているとのことだ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 今すぐ確認すべきポイントを整理する。 Copilot Studio利用組織はフロー連携を再設計する好機: これまで「ボットと自動化は別物」として管理していた場合、今回の統合強化を機にアーキテクチャを見直す価値がある。対話と自動化を一体で設計すると、ユーザー体験が大きく変わる Power Apps開発者はAI Builder連携の学習コストを今のうちに払う: AI Builderのライセンス体系はやや複雑だが、Power Apps Premiumライセンスに含まれる範囲が拡張されてきている。まず試せる環境を整えておきたい M365テナント管理者はPower Platformの権限設計を見直すタイミング: 統合が深まるほど、「誰が何を作れるか」のガバナンスが重要になる。環境（Environment）の分離とDLP（データ損失防止）ポリシーの棚卸しを定期的に行うことを強く推奨する 筆者の見解 Power Platformは、毎月のアップデートを積み重ねることで、気づけば2〜3年前とは別物といえるほど進化している。特にCopilot Studioとの統合については、「対話型AIと業務自動化をひとつのプラットフォームで完結させる」という思想が着実に具現化されていると感じる。 ただ、正直に言うと、まだ「完成品」ではない。フローのデバッグ体験や、複雑な条件分岐における信頼性には、まだ改善の余地がある。そこは応援する立場から率直に言いたい。 Microsoftが力を持っているのは、TeamsもSharePointもOutlookもPower Platformも、すべてが同じM365テナントに乗っているという統合の深さだ。その強みを最大限に生かす方向で開発が進んでいる今の路線は正しいと思う。あとはユーザーが「使いこなしている」と実感できる品質の底上げを、引き続き期待したい。 自動化への投資を検討している組織にとっては、今のPower PlatformはROIを出せるフェーズに入ってきた。毎月のアップデートをすべて追う必要はないが、今回のCopilot Studio連携強化は、自社の業務フローを見直すきっかけとして十分に価値がある。 出典: この記事は What’s new in Power Platform: April 2026 feature update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがパートナーエコシステムとともにAI・セキュリティ・ガバナンスを一体化した新スイート「Microsoft 365 E7（Frontier Suite）」を2026年5月1日にローンチすることを発表した。「Frontier Transformation」と銘打ったこの取り組みは、エンタープライズITの根本的な変革を本格的に推進するための市場戦略の一環だ。 Frontier Suiteの正体——E3/E5の上に何を乗せるのか M365 E7、通称「Frontier Suite」は、Microsoft 365の中でも最上位のエンタープライズ向けSKUとして位置づけられる。AI Copilot・Microsoft Defender・Microsoft Purview（コンプライアンス・ガバナンス）を統合した形での提供が特徴だ。これまでE3やE5で個別に購入・管理してきたライセンスを一本化し、AI機能とセキュリティ機能を「最初から組み込まれた状態」で使える構成になっている。 Microsoftはこの新スイートの市場展開にあたり、パートナーへの販売インセンティブを拡充し、技術支援プログラムも強化する。グローバルなパートナーエコシステムを通じてエンタープライズ市場へ浸透させる戦略だ。 なぜこれが重要か——「パーツの寄せ集め」から「統合プラットフォーム」へ この発表が持つ意味は、単なるSKU追加にとどまらない。Microsoft 365は「統合して使うことで価値が出るプラットフォーム」だ。バラバラに導入・運用しているうちは、全体最適には程遠い。 日本企業の現場を見ると、E3ライセンスでTeamsだけ使い、セキュリティはオンプレミスのVPNや旧来のDLPで補完し、コンプライアンスは別途ツールを追加——という「部分最適の積み重ね」が非常に多い。そのままではコストも運用負荷も増え続ける。 E7がAI・セキュリティ・ガバナンスを一体化することで、企業はこの「分断の呪い」から解放される可能性がある。もちろん、それはライセンスを購入しただけでは実現しない。しっかりと設計して使い倒してこそ、だ。 実務への影響——IT管理者が今すぐ確認すべきこと 1. 現行ライセンスの棚卸しを今すぐ E3・E5を混在運用している組織は、E7への移行でコスト構造が変わる可能性がある。5月1日ローンチ前に現状のライセンスポートフォリオを整理し、パートナーと移行試算を行うことを強く推奨する。 2. セキュリティ機能の統合設計を見直す Defenderシリーズを個別契約・個別管理している場合、E7の統合SKUへの移行で管理コンソールの一元化とライセンスコスト削減が期待できる。特にDefender for Cloud AppsやPurviewのコンプライアンス機能は、単体で導入するより統合環境で動かす方が効果が高い。 3. パートナーの支援体制を今のうちに確認する Microsoftがパートナーへのインセンティブを拡充しているということは、認定パートナー経由での導入が今後しばらくは有利になる可能性が高い。技術支援・価格交渉の両面で、パートナーとの関係を早めに整理しておくとよい。 筆者の見解 正直に言えば、「Frontier Transformation」というネーミングには、Microsoftらしい「名前から入る」感がある。ただ、今回の取り組みの方向性自体は正しいと思っている。 AIとセキュリティとガバナンスを同じ傘の下に置く——これは本来あるべき姿だ。セキュリティは後付けで追加するものではなく、設計の中心に置くものだ。Purviewのようなガバナンス機能も、AIが業務データに触れる以上、切り離せない問題になってきた。その統合を製品ラインナップで実現しようとするアプローチは、評価に値する。 ただし、製品の箱を統合するだけでは不十分だ。ユーザーが「これを使うと実際に楽になる」「これがないと困る」と感じる体験を届けなければ、どれだけパートナーインセンティブを積んでも浸透はしない。 Microsoftには統合プラットフォームとしての圧倒的な強みがある。それを活かしきれるかどうかは、今後の実装品質と、日本のパートナーエコシステムの実行力にかかっている。この「Frontier Suite」が名前だけで終わらないことを期待している。日本のIT現場に届く形で変革を実現できる力が、Microsoftにはあるはずだから。 出典: この記事は Accelerating Frontier Transformation with Microsoft partners の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Exchange Online の大量メール送信機能「High-Volume Email（HVE）」が2026年4月1日に正式GA（一般提供）を迎え、同時に課金スケジュールが明らかになった。2026年6月1日から従量課金（PAYG）が始まるため、現在HVEを利用中のテナントは今月中に請求ポリシーを設定しておく必要がある。 HVEとは何か——「内部専用の大量送信レーン」 HVEはExchange Onlineに組み込まれた大量メール送信ソリューションで、テナント内部の受信者にのみメールを送信できる。社内向けニュースレター、システム通知、バッチ処理後のレポート配信など、「社内に向けて大量に送る」ユースケースに特化している。外部送信には対応しないため、顧客向けメルマガ等の用途には別サービスが必要だ。 料金体系——100万受信者あたり約6,000円 HVEの基本単価は1受信者あたり0.000042米ドル（100万受信者=42米ドル）。為替レート145円換算で約6,090円となる。課金は「受信者数」ベースであり、メッセージ数ではない点に注意が必要だ。 よく比較されるAzure Email Communication Service（ECS）は外部宛100万通で274米ドル（メッセージ数ベース）と単価は高いが、メッセージ追跡などの高度な機能を備えている。HVEは最大10MBのメッセージを扱えるシンプルな構成で、内部向け配信に特化しているぶん低コストに収まる設計だ。ただし、ECSがメッセージ数ベースで請求されるのに対しHVEは受信者数ベースであるため、「1メッセージ=複数受信者」のケースでは単純な数字比較に意味はない。用途に応じて正しく使い分けることが重要だ。 実務での活用ポイント——6月1日までにやること 請求ポリシーの設定はMicrosoft 365管理センター → 課金 → 従量課金から行う。主な手順は以下のとおり。 有効なAzureサブスクリプションを用意する — クレジットカードが紐付いているアクティブなサブスクリプションが必要。 HVE専用のAzureリソースグループを作成する — 既存のリソースグループを流用するとコスト分析が煩雑になる。専用グループを新規作成するのがベストプラクティス。 予算アラートを設定する — 月次予算の上限と通知先のメールセキュリティグループを設定しておくと、予期しない費用超過を早期に検知できる。 請求ポリシーをHVEサービスに割り当てる — ここまで完了して初めて課金対象となる。6月1日以降、この設定がないとHVEは利用停止になる可能性があるため要注意。 管理操作はGUIで完結するが、Get-BillingPolicyなどのPowerShellコマンドレットも用意されている。複数テナントを管理するMSP環境やスクリプトで自動化したい場合に活用できる。 日本のIT現場への影響 社内向け大量通知をExchange Onlineで処理している組織は少なくない。これまでHVEをプレビューで無償利用していたケースでは、6月1日を境に請求ポリシー未設定のまま送信が止まるリスクがある。まず「自テナントでHVEを使っているか」を確認し、使っているなら請求ポリシーの設定とAzureサブスクリプションの準備を今月中に終わらせておきたい。 一方で「そもそも大量送信にHVEを使う必要があるか」も見直すタイミングだ。配信数が少なく標準のExchange Online送信制限で収まるなら、わざわざHVEを有効化してAzure課金と紐付ける必要はない。 筆者の見解 HVEそのものの設計は理にかなっていると思う。「内部専用」に特化することで料金を低く抑え、ECSと役割分担を明確にする——これはMicrosoft 365とAzureを統合プラットフォームとして捉えたとき、全体最適として筋が通っている。 ただ、課金開始まで2カ月弱しかないのに告知が4月1日というのは、エイプリルフールを疑うタイミングで正直どうかと思う。プレビューから本番移行を急ぐユーザーがAzureの課金設定に不慣れだった場合、意図せずサービスが止まるリスクがある。「GA発表と同時に課金開始日も発表する」ならせめて3〜4カ月の猶予が欲しい。これは意地悪な批判ではなく、ユーザーのオペレーション現実を考えた率直な意見だ。 M365とAzureの請求を一元管理するパターンはこれからも増えるだろう。その意味でHVEの請求ポリシー設定は「AzureとM365の連携運用に慣れる最初の一歩」として捉えると、IT管理者にとって有益な学習機会でもある。請求設定を正しく組み込む力は、これからの統合プラットフォーム運用に必ず生きてくる。 出典: この記事は High Volume Email is Generally Available and Ready to Charge の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年4月15日、すべてのサポート対象Windowsバージョンに向けた月例セキュリティ更新プログラムを公開した。今月は単なるバグ修正にとどまらず、現実の攻撃手法に正面から対応した機能強化が含まれている点で注目に値する。特にリモートデスクトップ（RDP）ファイルを悪用したフィッシング攻撃への対策は、昨今の企業環境における脅威動向を踏まえると、IT管理者にとって見逃せない変更だ。 今月の主要な変更内容 RDPファイルを使ったフィッシング攻撃への防御強化 今月の更新で最も実務的なインパクトがあるのが、.rdp ファイル経由のフィッシング攻撃対策だ。改善後は、RDPファイルを実行しようとすると接続前にすべての要求された接続設定が表示されるようになり、初回使用時にはワンタイムのセキュリティ警告も表示される。また、危険な接続設定はデフォルトでオフに変更された。 この変更の背景には、攻撃者がメールに .rdp ファイルを添付し、ユーザーが気づかないうちに攻撃者管理のサーバーへRDP接続させてしまう手口が増加していることがある。認証情報の窃取やマルウェア配布に利用されており、企業のヘルプデスクや外部委託業者との連携が多い日本の大規模エンタープライズ環境では特に注意が必要だ。 Secure Boot証明書の段階的更新——追加再起動の可能性あり 今月からの数カ月にわたり、一部のデバイスでインストール中に追加の再起動が1回発生することをMicrosoftは明記している。これはSecure Boot証明書更新プロセスの一環として発生するもので、段階的ロールアウトにより「十分な成功シグナル」が確認されたデバイスのみに新証明書が配布される設計だ。 計画メンテナンス外の再起動が発生する可能性があるため、展開スケジュールを管理しているIT部門は今月の更新を適用する前にこの点を運用チームに周知しておくことを強く推奨する。特に業務時間中に自動更新が走る設定のデバイスは注意が必要だ。 SMB over QUICの信頼性向上 SMB（Server Message Block）圧縮のQUICトランスポート上での動作において、タイムアウトが削減され、より安定した通信が実現されている。ハイブリッドワーク環境でAzure File ShareやWindows Server上のファイル共有をリモートから利用している組織には恩恵がある変更だ。 Azure Network Connection（ANC）ヘルスチェックの動作変更 Windows 365（Cloud PC）を利用している環境では特に注意が必要な変更がある。Azure Network Connection（ANC）のヘルスチェックにおいて、必要なエンドポイントに到達できない場合の応答がWarningからErrorに変更された。これにより、ネットワーク要件を満たしていない環境ではCloud PCのプロビジョニングがブロックされるようになる。 「これまでWarningだったのだから大丈夫だろう」と油断している組織は要確認だ。Microsoftが要求するエンドポイントへの疎通が取れているか、ファイアウォールやプロキシのルールを今一度見直すべきタイミングだ。 今月の更新対象KB一覧 OS KB番号 Windows 11 26H1 KB5083768 Windows 11 25H2 / 24H2 KB5083769 Windows 11 23H2 KB5082052 Windows 10 22H2 / 21H2 KB5082200 Windows Server 2025 KB5082063 Windows Server 2022 KB5082142 Windows Server 2019 KB5082123 実務への影響——IT管理者が今週すべきこと 1. 追加再起動の周知と展開スケジュールの調整 Secure Boot証明書更新による追加再起動が発生しうる旨を、エンドユーザーおよびヘルプデスクに事前通知しておく。業務時間外に更新を完了させるポリシーがある環境では特に意識的に管理する。 ...

Microsoftが2026年4月20日付けのM365ロードマップ更新で、SharePointまわりの注目機能を複数開示した。UI刷新、AI活用のナビゲーション最適化、そして情報保護ラベルの自動剥奪——いずれも「地味に見えて実務では大きく効く」類の変更だ。特にラベルの自動除去は、日本のコンプライアンス担当者が今すぐポリシーを見直す必要がある可能性がある。 SharePointの新デザインエクスペリエンスとは 今回のロードマップで確認できるのは、SharePointの「新デザインエクスペリエンス」が2026年後半にかけて順次展開されるという計画だ。具体的な画面レイアウトの詳細はまだ限られているが、モダンUIの延長線上でより統一感のある操作体験を提供するものとみられる。 SharePointは長年にわたってクラシックUIとモダンUIが混在してきた経緯がある。日本の大企業でも「モダンに移行しきれていない部分が残っている」という現場は多い。新デザインの展開が進むにつれ、カスタムWebパーツや既存のページレイアウトとの互換性を事前に確認しておくことが重要になる。 AI強化ナビゲーション——「探す」から「辿り着く」へ 同時期に展開予定とされているのが、AIを活用したナビゲーション最適化だ。ユーザーの行動パターンや利用頻度に基づいて、サイト内のナビゲーションが動的に最適化される仕組みを指すとみられる。 これまでのSharePointナビゲーションはサイト管理者が手動で設計・メンテナンスするものだった。AI最適化が加わることで、「よく使うがメニューに出てこない」というUX上の摩擦が減少することが期待できる。情報アーキテクチャの設計コストが下がる方向性であり、SharePointを社内ポータルとして活用している組織にとっては歓迎すべき変化だ。 自動ラベル剥奪ポリシー——見落としやすいが重要な変更 今回の更新で最も実務インパクトが大きいのが、OneDriveとSharePointにおける「自動ラベル剥奪ポリシー（Auto-Label Removal Policy）」の追加だ。 Microsoft Purviewの機密ラベルは、コンテンツに含まれるパターン（個人情報・クレジットカード番号など）を検出して自動付与できる。このラベルは一度付与されると、コンテンツが変更されて判定基準を満たさなくなっても、従来は手動で外すか管理者が対応する必要があった。 新しい自動剥奪ポリシーにより、「基準を満たさなくなったファイルのラベルを自動的に除去する」という動作が可能になる。コンプライアンス運用の自動化という観点では前進だが、注意点もある。 意図しないラベル剥奪が発生するリスクがある。たとえば、個人情報を含むファイルから当該情報が削除された場合、保護ラベルが自動的に外れる。これは正しい動作だが、ラベルが外れたことで「保護が消えた」状態が発生することを、管理者とユーザー双方が認識していなければならない。 また、日本企業の多くは「一度付けたラベルはなるべく外さない」という運用慣行を持っている場合がある。自動剥奪ポリシーを有効にする前に、既存の情報保護ポリシーとの整合性確認が欠かせない。 実務への影響 SharePoint管理者がすべき対応（今すぐ）: 自社のSharePointにクラシックUIのカスタマイズが残っていないか棚卸しする Microsoft Purviewで自動ラベルポリシーを運用している場合、「剥奪ポリシー」をどう扱うかを情報セキュリティチームと合意しておく テナントのメッセージセンターでロールアウト通知が届くタイミングを見逃さないよう、通知設定を確認する IT部門全体として意識すべき変化: SharePointのUI刷新は、エンドユーザー向けトレーニング資料の更新を伴う。特に「画面が変わった」という混乱が起きやすい組織では、事前のコミュニケーションプランが鍵になる。ロードマップを確認して、展開タイミングに合わせた社内周知準備を始めておきたい。 筆者の見解 自動ラベル剥奪ポリシーは、情報保護の自動化という観点では正しい方向性だと思う。これまで「一度ついたラベルが永続してしまい、実態と乖離している」という状態は少なくなかった。ラベルの信頼性を保つためには、付与と同様に除去も自動化されるべきだ。 ただし、ここで大切なのは「自動化＝放置してよい」ではないという点だ。ポリシーを設定したらあとは任せきり、ではなく、定期的に剥奪ログを確認し、意図しない動作が起きていないかを監視する運用体制が必要になる。これはゼロトラストの文脈でいう「継続的な検証」とも通じる考え方だ。 SharePointのUIとナビゲーション改善については、率直に言って「遅すぎた」感はある。ただ、AIを活用してナビゲーションを動的に最適化するアプローチは、情報アーキテクチャの管理コストを下げる可能性があり、方向性自体は面白い。SharePointはMicrosoft 365の中核インフラとして使い続けている組織が多い。この基盤をしっかり磨いてくれることは、プラットフォーム全体の底上げにつながる。そこへの期待を込めて、引き続き注目していきたい。 出典: この記事は Microsoft roadmap roundup – 20 April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月のMicrosoft 365 Copilotアップデートが公開された。目玉は「Excel Work IQ」の強化とTeams会議のナレーション付きハイライトリール、音声サマリーの日本語対応だ。「また新機能か」と流しがちなリリースだが、今回は現場レベルで体感できる実務直結の改善が複数含まれている。 ExcelがメールやTeams会議の文脈を「理解」する——Work IQ強化 今回最も注目すべきは、ExcelのWork IQ機能の強化だ。これまでExcel内のデータに閉じていたCopilotの認識範囲が、メール・会議・チャット・ファイルという4つのコンテキストにまで拡張された。さらに多段階編集（複数ステップの操作を連続実行する処理）が可能になり、「会議で合意した数字をそのままシートに反映する」というワークフローが現実に近づいた。 また、ローカル保存のExcelファイルへのCopilot編集がWindowsとMac両方で対応した。これまではSharePointやOneDriveに保存されたファイルのみが対象だったため、「ローカル作業が多い現場では使えない」という声は根強かった。この制約が取り除かれた意味は大きい。 Teams会議のナレーション付きハイライトリール——「後追い参加」を変える 会議を欠席したとき、45分の録画を全部見るのか、誰かのまとめを読むのか——そのどちらでもない第三の選択肢が登場した。 Copilot ChatとMicrosoft Clipchampのウェブプレイヤーで会議サマリーを求めると、ナレーション付きの短いハイライトリールが生成される。テキスト要約ではなく、実際の録画クリップをAIが重要箇所で切り出してナレーションをつけた動画形式だ。10分以上の会議で録画がオンになっていることが条件で、現時点では英語のみ対応。 音声サマリーが日本語対応——グローバルチームへの朗報 地味に見えて実は大きいのが、Audio Recap（音声によるAI会議サマリー）の多言語対応だ。これまで英語のみだったが、今回のアップデートで日本語を含む7言語に拡張された（中国語・フランス語・ドイツ語・イタリア語・日本語・ポルトガル語・スペイン語）。 通勤中や他の作業と並行した「ながら把握」の選択肢として実用性は高い。英語主体の社内会議のサマリーを日本語で音声取得できれば、言語ハードルも下がる。グローバル展開している日本企業にとっては即戦力になるアップデートだ。 Researcherの出力形式が一気に拡張 Microsoft 365 CopilotのResearcher機能が生成したレポートを、クリック一つでPowerPoint・PDF・インフォグラフィック・音声オーバービューに変換できるようになった。会議向けにはPPT、役員サマリーにはPDF、SNSシェア用にはインフォグラフィックと、同じ調査結果を場面に応じた形式で即座に展開できる。 Copilot Notebooksのリニューアル Copilot NotebooksのUIが全面刷新され、参照情報・Copilot Pagesのコンテンツ・チャット履歴が一つのサイドバイサイドビューにまとまった。概要ページの新設、参照セットの充実、成果物の作成・共有の簡略化と、長期プロジェクトを複数人で進めるシーンでの使い勝手が格段に向上している。 ブランドフッターでシャドーAI対策 管理者向けには、Copilotアプリのチャット画面下部に組織のブランドフッターを表示できる機能が追加された。Microsoft 365管理センターから設定し、「これは組織が認めたAIツールです」というメッセージをユーザーに見せる仕組みだ。禁止ではなく「正規ルートを見せる」アプローチとして、IT管理者にとって地に足のついた対策になる。 実務への影響 Excelのローカルファイル対応は、日本の現場では特に影響が大きい。Excelを基幹業務ツールとして使い続けている企業では、「クラウド保存に移行しなければCopilotが使えない」という障壁が事実上なくなる。Work IQのコンテキスト統合と合わせると、「会議→合意→Excelへの転記」という手作業フローの自動化が現実のものとなる。 管理者向けのブランドフッターは、AI利用ガバナンスを強化したいIT部門に刺さる機能だ。「野良AIツールを禁止する」のではなく、「承認済みのツールをいちばん使いやすくする」という方向性は理にかなっている。シャドーIT対策の定石でもある。 筆者の見解 正直に言えば、今回のアップデートは「ようやく」という感が強い。ExcelのローカルファイルへのCopilot適用は、クラウドファースト前提の設計から抜けられなかった象徴的な制約だった。それが解消されたことは素直に評価したい。 Teams音声サマリーの日本語対応も同様だ。日本語でのCopilot体験が英語圏と同水準に近づくことは、プラットフォームとしての価値向上に直結する。こういった着実な改善の積み重ねが、信頼回復への正攻法だ。 Work IQのコンテキスト統合は、方向性として正しい。メール・会議・Excelをシームレスにつないで業務フローを自動化する——これはまさしく、Microsoft 365が統合プラットフォームとして持つ最大の強みを生かす戦略だ。「Excelだけ」「Teamsだけ」という部分最適ではなく、全体最適の実現に本気で向かっている姿勢は伝わる。 Microsoftには、この方向性を維持し続けてほしい。「M365があれば業務の大半は完結する」という体験を本当の意味で実現できる力は、間違いなくある。それを証明する続きを、次のアップデートで見せてもらいたい。 出典: この記事は Microsoft 365 Copilot Updates | April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SharePointの使いにくさに悩まされてきたすべてのIT担当者に、注目すべき動きが出てきた。2025年9月に登場した「Knowledge Agent」が「AI in SharePoint」としてリブランドされ、機能も大幅に強化された。自然言語でSharePointサイトの設計・構築が行えるようになるというこのアップデートは、「SharePoint難民」を量産してきた構造的な問題を正面から解決しようとする試みだ。 Knowledge Agentから「AI in SharePoint」へ——何が変わったのか リブランドの最大のポイントは、自然言語によるサイト・ライブラリ・ページ・リストの設計と構築が可能になることだ。これまでSharePointのサイト構築は、情報アーキテクチャの知識を持つ専任担当者か、経験豊富なSharePoint管理者が担うのが一般的だった。列の追加、コンテンツタイプの設計、ナビゲーション構造の整理——これらすべてがGUIの迷路をくぐり抜ける作業であり、ビジネスユーザーが自力でやるには現実的でなかった。 「プロジェクト管理用のサイトを作りたい。進捗を管理するリストと、ドキュメントを整理するライブラリと、週次レポート掲載用のページが必要だ」——そういった要望を自然言語で伝えれば、AIがサイト構造を組み上げる。これが実用レベルで動くなら、SharePointの民主化が本当の意味で始まる可能性がある。 また、「ナレッジ管理」機能の強化も重要だ。組織内のドキュメントや情報をSharePoint上で体系的に整理・検索・提示する能力が向上し、単なるファイルサーバーとしての利用から、真のナレッジベースとして機能させる方向への転換が加速する。 なぜこれが重要か——日本のIT現場への影響 日本の中堅〜大手企業でSharePointを使っている組織は多い。しかし実態を見ると、「一応SharePointはある。でも誰も使い方を知らないし、ファイルが散らばっていて整理もできていない」という状況が珍しくない。SharePointのポテンシャルを活かしきれず、結果としてBoxやGoogle Driveと並行運用が続いているケースも多数ある。 その根本原因の一つが「設計・構築の難しさ」だ。ちゃんと使えるSharePoint環境を作るには相応の専門知識と工数がかかる。それがAIによる自然言語操作で大幅に下がるなら、放置されていたSharePoint活用が一気に動き出す可能性がある。 M365ライセンスを保有しているのにSharePointを使いこなせていない組織にとって、追加投資なしで活用レベルを引き上げられるチャンスになりうる。これはコスト観点でも無視できない。 実務での活用ポイント 1. まず「試してみる」環境を用意する AI in SharePointが自テナントで利用可能になったら、まず開発・検証サイトで動作を確認する。自然言語でどの程度の粒度まで指示できるか、生成されたサイト構造の品質はどうかを把握してから本番展開の設計に入る。 2. 既存の「使われていないSharePointサイト」の棚卸しに使う AIに「このサイトにどんな情報が入っているか要約・整理して」と聞けるなら、放置されてきた古いサイトの棚卸しにも活用できる。まずは情報整理ツールとして使い始めるアプローチが現実的だ。 3. ビジネスユーザーへの展開教育を見直す 自然言語で操作できるなら、従来の「SharePoint操作研修（GUIの使い方）」の価値が変わる。「何を実現したいかをAIに伝える方法」へと教育内容をシフトさせることを検討する時期だ。 4. Copilot for M365との組み合わせを前提に設計する AI in SharePointで整備したナレッジ構造は、Copilot for M365がRAG（検索拡張生成）する際の情報源になる。SharePointをきちんと整理することは、M365全体のAI活用基盤を整えることと同義だ。ナレッジ管理の品質がそのままCopilotの回答品質に直結する。 筆者の見解 MicrosoftがSharePointのAI機能を「Knowledge Agent」という名称から「AI in SharePoint」に変えた判断は正しいと思う。「エージェント」という言葉が氾濫し始めたこのタイミングで、機能をプロダクト名に紐付けたブランディングにシフトしたのは、ユーザーが機能を見つけやすくする意味でも理にかなっている。 SharePointはずっと「ポテンシャルはあるのに使われない」という問題を抱えてきた。UIの複雑さと設計の難しさが普及の壁になってきたわけだが、自然言語による構築支援はその壁を正面から崩しに来ている。Microsoftにはこういうことができる力がある。M365というプラットフォームと数億のユーザーベースを持っているのだから、AIをその中に深く組み込む方向性は正しい。 ただ、自然言語で生成されたサイト構造が「本当に使いやすいか」は別の話だ。AIが自動生成したサイト構造は、組織の業務フローに合っているとは限らない。生成結果を人間がレビュー・調整する工程を省くと、「AIが作ったけど誰も使わないSharePoint」が大量に量産されるリスクがある。 ツールがいくら賢くなっても、何をどう整理すれば組織のナレッジが活きるかを考える人間の役割は変わらない。AI in SharePointは「考える負荷を減らすツール」であって「考えなくていいツール」ではない。この点を組織内で正しく伝えながら展開できるかどうかが、成功と失敗を分ける鍵になるだろう。 MicrosoftのSharePoint周辺への投資は継続されており、この方向性は歓迎したい。あとは「使って良かった」という実績を積み上げていくフェーズだ。 出典: この記事は AI in SharePoint: Knowledge Agent Rebranded and Upgraded with Natural Language Site Building の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年第1四半期（1月〜3月）のMicrosoft 365稼働率が**99.526%**という数値を記録した。これは、Office 365 IT ProsチームがMicrosoftのSLA保証導入以来データを追い始めた2013年以降、最も低い数値だ。前四半期（2025年Q4）の99.954%から一気に落ち込んだこの数字は、多くのIT管理者にとって見過ごせないシグナルとなっている。 99.526%が意味する「約10時間の停止」 稼働率の数字だけを見ると小さな差に思えるが、実際の影響はそれだけでは語れない。99.526%という数値をQ1（約90日間）に換算すると、合計約614分——つまり10時間超の障害時間が発生したことになる。 Microsoftはサービス健全性と継続性のページで四半期ごとに稼働率を公開しているが、この数値は全商用リージョン・全ワークロードを合算したグローバル指標だ。特定のリージョンや個別テナントの状況を直接反映するものではない。つまり、日本リージョンだけを使っている組織の体感とは乖離がある可能性もある。 SLA違反にはならない——その仕組みを理解せよ 「99.9%を下回ったのだから補償が受けられるはずだ」と考えた方もいるかもしれないが、実際には補償（サービスクレジット）の対象にはならない。 MicrosoftのオンラインサービスSLAは、稼働率をサービスごと・月単位で計測する。Exchange OnlineやSharePoint Onlineといった個別サービスが月単位で99.9%を下回った場合のみ、クレジット申請が可能になる。四半期の合算グローバル値が低かったとしても、それだけでは補償請求の根拠にはならない。 なお、Teams Phone・Calling Plans・音声会議については99.999%という一段高い目標が設定されており、これは2021年に引き上げられた水準だ。ビジネスクリティカルな音声通話サービスには特別に厳しい基準が課されている点は覚えておきたい。 日本のIT現場への影響を考える グローバル指標であるとはいえ、今回の数値が示すのは「Q1に世界のどこかで大規模障害が複数発生し、グローバル集計に影響を与えるほどだった」という事実だ。 Microsoft 365を基幹業務基盤として使っている日本企業にとって、この状況が突きつける課題は明確だ。 実務での活用ポイント サービス正常性ダッシュボードをルーティン監視に組み込む Microsoft 365管理センターの「サービス正常性」はリアルタイムで障害状況を確認できる。自組織に影響が出ている障害かどうかを素早く判断するため、IT担当者のモニタリング体制に組み込んでおきたい。 SLAの構造を経営層・関係部門に正確に伝えておく 「四半期稼働率が低い＝補償請求できる」という誤解は意外に多い。SLAがサービス別・月単位であること、補償額の上限（月額の一定%）を事前に共有しておくと、障害発生時の混乱を防げる。 BCP視点での依存度を棚卸しする Teams・Exchange Online・SharePointへの依存が高い業務フローほど、障害時の代替手段が必要になる。「Teamsが落ちたら何で連絡するか」を決めておくだけで現場の混乱は大きく変わる。 インシデントの事後レポート（PIR）を活用する 大規模障害の後、MicrosoftはPost-Incident Review（PIR）を公開することがある。根本原因や再発防止策を確認することで、自社のリスク管理にも活かせる。 筆者の見解 Microsoft 365はいまや多くの日本企業にとってインフラそのものだ。メール・ビデオ会議・ファイル共有・社内コミュニケーションがひとつのプラットフォームに集約されているからこそ、その停止が業務に与えるダメージは大きい。 今回の99.526%という数値は、正直なところ「もったいないな」と思う。クラウドサービスに障害はつきものとはいえ、長年の実績を見ると明らかに水準を下回っている。Microsoftはこのプラットフォームを正面から守り抜く力を持っている企業のはずだ。それだけに、この下落が一過性の出来事として早期に終わることを期待したい。 一方で、SLAの仕組みに対する理解不足が「被害を大きく見せている」側面もある。四半期グローバル指標は透明性のための数値であり、個別テナントの補償根拠にはならない。数字に一喜一憂するより、自分の組織がどのサービスにどれだけ依存しているかを把握し、障害時の対応手順を整えておくことの方がよほど重要だ。 Microsoft 365は統合して使うことで真価を発揮するプラットフォームだ。バラバラに使ったり、「とりあえず入れた」状態では本来の価値も得られず、障害時のリスクだけが残る。この機会に、自組織の活用度と依存構造を見直してみる価値はあるだろう。 出典: この記事は Microsoft 365 Quarterly Uptime Number Sinks to New Low の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月15日、業界全体で「DigiCert Global Root CA（G1）」の信頼が打ち切られた。Microsoft 365側の対応は既に完了しているが、古い証明書ストアを抱えるシステムやコンテナ環境では今まさに接続障害が起きている可能性がある。静かに進む変更だが、影響を受ける組織にとっては無視できない問題だ。 そもそも何が起きているのか TLS通信では、サーバー証明書の信頼を辿っていくと最終的に「ルートCA証明書」に行き着く。このルートCAがOSやブラウザの「信頼ストア」に含まれていなければ、通信は失敗する。 今回の変更は、Mozilla・Chromeという業界の主要な信頼ストアが「DigiCert Global Root CA G1」を信頼リストから除外したことに起因する。Microsoftはすでに数年前から対応を進めており、Microsoft 365のエンドポイントは「DigiCert Global Root G2」および「G3」ベースの新しい証明書チェーンに移行済みだ。 つまり、Microsoft側の問題ではなく、クライアント側の「信頼ストアが古いまま」である場合に問題が顕在化する構造になっている。 どんな環境が影響を受けるか 影響を受ける可能性があるのは以下のような環境だ： Linuxベースのシステム・コンテナ・アプライアンス：Mozilla/NSS信頼ストアに依存しており、OSイメージやコンテナイメージが古いまま放置されているケース Google Chrome・Mozilla Firefox：最新版は自動更新で対処済みだが、ブラウザの更新を制限している環境では注意が必要 オンプレミスのメール中継やプロキシ装置：TLSインスペクション機能を持つ機器で、ファームウェアが古い場合に証明書チェーン検証が失敗することがある CI/CDパイプラインやバッチ処理のコンテナイメージ：ベースイメージを長期間更新していない場合、信頼ストアが古くなっている可能性がある 典型的なエラーメッセージとしては以下が挙げられる： 出典: この記事は DigiCert Global Root CA G1 Distrust: Impact on Microsoft 365 (MC1282565) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

M365のデータを「持ち込む」時代から「つなぐ」時代へ Anthropicは2026年4月3日、ClaudeのMicrosoft 365コネクタをすべてのプランで無料開放したと発表した。これまでTeam・Enterpriseプランに限られていた機能が、個人の無料アカウントでも使えるようになった。Outlook、OneDrive、SharePoint、そしてTeamsの会話にClaude側から直接アクセスし、ファイルのアップロードなしに「M365上にある情報をAIとの会話に持ち込む」ことが可能になる。 これは表面的には「無料プランの機能拡充」だが、実態としてはAIアシスタント市場における構造的な地殻変動の一コマだ。Microsoft 365は日本の多くの企業が基盤として使っているプラットフォームであり、そこへのアクセス権を外部AIが持つ意味は決して小さくない。 何が変わるのか——技術的なポイント コネクタによる権限委譲 今回の統合はOAuthベースのコネクタ経由で行われる。ユーザーがClaude側でMicrosoftアカウントへの接続を許可すると、Claude側がOutlookのメール内容、OneDrive上のドキュメント、SharePointのファイルを読み取れるようになる（書き込み権限ではなく読み取りが基本）。 従来は「ファイルをダウンロードしてアップロードして要約させる」というステップが必要だったが、それが不要になる。メールスレッドの文脈を保ちながら返信案を生成させる、SharePoint上の複数ドキュメントを横断的に検索させる、といった使い方が現実的になる。 MicrosoftはAnthropicと協業もしている 興味深いのは、Microsoft自身もAnthropicとの協業を深めていることだ。Microsoftが発表したCopilot Councilは、複数のAIモデルを並列活用できる仕組みであり、ClaudeやほかのモデルをMicrosoftのエコシステムの中で活用する設計になっている。また、Enterprise向けのCopilot Coworkソリューションにはクロードの技術が使われているとも報じられている。 競合しながら協業するという複雑な関係が、業界の常態になりつつある。 実務への影響——日本のエンジニア・IT管理者に何が起きるか Copilotと外部AIの「使い分け」が前提になる 今後のM365環境では、Copilotだけを使うか、外部AIを使うかという二択ではなく、両者を目的に応じて使い分けることが現実的な運用になる。Teamsの議事録作成やOutlookの返信候補生成はCopilotが引き続き強い。一方、複数ドキュメントの横断分析、高度な要約・考察、技術文書のレビューなど、より創造的・分析的なタスクでは外部AIとM365の接続が有効なシナリオになりえる。 データガバナンスの整理が先決 外部AIにM365データへのアクセスを許可するには、情報セキュリティポリシーの整備が前提となる。特に日本の大企業では、どのデータを外部AIに渡してよいか、個人情報・機密情報の扱いをどう管理するかを先に社内で整理しなければならない。「便利だから使う」前に「使っていいものを分類する」ステップが必要だ。Microsoftの機密度ラベル（Sensitivity Labels）と組み合わせたアクセス制御の設計が、ここでも重要になってくる。 個人利用では今すぐ試せる 一方で、個人のMicrosoftアカウント、もしくは業務環境でIT部門が許可している範囲であれば、今すぐ試せる状態にある。自分のOneDriveにあるドキュメントを読み込ませてみる、Outlookのスレッドを整理させてみる——こうした小さな実験を通じて「どう使えば価値があるか」を自分の手で確かめることが、いまもっとも大事な投資だ。 筆者の見解 M365のデータに外部AIが直接つながれる——これは「まだ先の話」だと思っていた人も多いかもしれないが、すでに現実になっている。 正直なところ、この動きを見てMicrosoftには「もったいない」と感じる。M365というプラットフォームそのものの価値は本物だし、業務データとAIをシームレスに統合するポテンシャルはMicrosoftが最もよく持っているはずだ。なのに、そのホームグラウンドに外部のAIが無料で入ってこられる状況を作ってしまっているのは、Copilotの競争力という観点では課題を認めざるを得ない。 ただ、Microsoftが自社エコシステムに複数のAIを取り込む戦略（Copilot Council）を進めているのは、現実的な判断だと思う。ひとつのモデルに全賭けせず、プラットフォームとしての価値を高める方向性は正しい。Copilot自体も進化し続けており、いつかこの批評が「古い批評」になる日が来ることを期待している。 日本のIT現場で大事なのは、「どのAIが勝つか」を見極めることではなく、「手元にある道具をどう組み合わせて成果を出すか」を考えることだ。M365の接続性という強みと、外部AIの能力を組み合わせて使いこなせる人材・組織が、これからの競争力の源泉になる。情報を追い続けるよりも、小さくても実際に使ってみることを強くすすめたい。 出典: この記事は Claude Opens Microsoft 365 Integration to Free Users in Major AI Push の内容をもとに、筆者の見解を加えて独自に執筆したものです。

CopilotはAIの「入口」だった 2026年のMicrosoft 365コミュニティカンファレンスで、Microsoftは企業向けAI戦略の大きな転換点を示した。これまでの「Copilot」は、ユーザーが問いかけたことに答える「アシスタント型AI」だった。しかし今回発表された「Agent 365」は、指示を待たずに自ら行動を起こし、複数のアプリケーションをまたいで複雑なワークフローを自律実行する「エージェント型AI」だ。 この変化は、表面上のUI改善や機能追加ではない。AIとビジネスオペレーションの関係そのものが変わる、構造的な転換点である。 Agent 365の3本柱 1. ガバナンスフレームワーク 自律型エージェントの最大のリスクは「何をやっているかわからない」ことだ。Microsoftはこの懸念に正面から向き合い、包括的なガバナンス機構を発表した。具体的には、エージェントの権限定義・監査ログ・リアルタイム監視の3層構造で、IT管理者がエージェントの「行動範囲」と「意思決定の根拠」を把握できる仕組みを提供する。 エージェントが「なぜその判断をしたか」を後から確認できることは、企業コンプライアンスの観点から非常に重要だ。これがないまま自律化だけを進めると、内部統制の観点で大きなリスクになる。 2. Frontier ProgramによるCoworkエージェント MicrosoftはFrontier Programを通じて「Coworkエージェント」を提供する方針も明らかにした。これは特定業務に特化したエージェントをパッケージ化して提供するアプローチであり、企業が個別にエージェントをゼロから開発するコストと難易度を大幅に下げることが期待される。 3. マルチモデル対応 今回の発表で特に注目したいのが、マルチモデル対応の明示だ。OpenAI製モデルだけでなく、他社モデルも組み合わせて利用できる構成がMicrosoft Foundry経由で提供される。これは、単一モデルへの依存を避けたいエンタープライズのニーズに応える動きであり、「タスクごとに最適なモデルを選択できる柔軟性」をインフラとして整備しようとする意図が読み取れる。 実務での活用ポイント 段階的な自律化設計が鍵 Agent 365の概念が示すのは「完全自律」ではなく「段階的な自律化」だ。カンファレンスで紹介されたユースケースを見ると、次のような段階設計が現実的だ： 第1フェーズ（現在）: Copilotによる補助・提案。人間が最終判断 第2フェーズ（近未来）: 定型業務の自律実行。例外のみ人間にエスカレーション 第3フェーズ（本格展開）: 複数エージェントが連携し、部門横断プロセスを自律で回す 日本の現場では、第2フェーズに入れている組織がほとんどないのが実態だ。まずはガバナンスポリシーの整備と、エスカレーション設計から着手することを強く推奨する。 IT管理者が今すぐやるべきこと エージェントへの権限設計を先行させる: 「エージェントに何をさせてよいか」のポリシーがなければ、ツールだけ入ってもガバナンス不在で動かすことになる 既存のデータ品質を棚卸しする: 自律型エージェントは、参照するデータが正確であることを前提に動く。ゴミデータを参照させれば、ゴミな判断を量産する 監査ログ基盤を確認する: Agent 365のガバナンス機能を活かすには、組織側のログ収集・分析基盤も最低限整備されている必要がある 「Teamsで議事録」から「Agentで完結」へ HR部門のオンボーディングや、経費精算の定型承認フローは、エージェントが最も力を発揮しやすい領域だ。ここは早期に実験環境を用意し、自社業務でのフィット感を測るのが最善手だ。 筆者の見解 Microsoftが「マルチモデル対応」を公式に打ち出したことは、率直に言って「やっと」という気持ちだ。企業の現場では、単一モデルですべてを賄えるという幻想はとっくに崩れている。タスクの性質によって適切なモデルは異なり、それを選択できる柔軟性こそが、本当の意味での生産性向上につながる。Microsoftがそこに踏み込んだことは評価したい。 Agent 365のガバナンス設計についても、方向性は正しい。自律型AIを企業に持ち込む上で最大の障壁は「制御できないかもしれない」という不安だ。権限設計・監査ログ・リアルタイム監視の3層で応えようとする姿勢は、エンタープライズのリアルな懸念を理解した上での設計だと感じる。 ただ、懸念が一つある。発表が先行し、実装が追いついていないのがMicrosoftの慢性的な課題だ。「ガバナンスフレームワークがある」と言うのは簡単だが、それが日本語環境・日本の業務プロセス・レガシーシステムとの連携でどれだけ実用に耐えるかは、実際に触るまでわからない。Microsoftには、発表したことを着実に動くものとして届けてほしい。それができる技術力と組織規模があることは、誰よりも自分が信じている。 「自律型エージェントの時代」は確実に来る。問題は「いつ来るか」ではなく「準備ができている組織がどれだけあるか」だ。今回の発表を機に、自社のAI活用が「アシスタントに聞く」段階から「プロセスを任せる」段階へ進むための準備を始めるべきタイミングだと思う。 出典: この記事は Microsoft 2026 M365 Conference Reveals AI Evolution: From Copilot Assistants to Governed Autonomous Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがIgnite 2025で発表した「Agent 365」がいよいよ正式リリースを迎えようとしている。2026年5月1日のGA（一般提供開始）に向け、価格・ライセンス・機能の詳細がFrontier Transformationイベントでようやく公開された。単なる管理ツールの追加にとどまらず、企業内でAIエージェントをどう「市民権」を持った存在として扱うかという、組織としての姿勢が問われる転換点だ。 Agent 365とは何か Agent 365は、企業のAIエージェントにディレクトリIDを与え、ライフサイクル管理・可観測性・アクセス制御・ポリシー適用を一元的に実行するコントロールプレーンだ。Microsoftの表現を借りれば「AIエージェントのためのEntra ID管理ペイン」になる。 Microsoft Entra、Purview、Defenderと並ぶ形で、M365のAI基盤スタックの中核に位置付けられる。各AIエージェントはMicrosoft Entra Agent IDを取得し、M365管理センターから人間のユーザーと同様に管理できる。1st Party（Microsoft製）・自社開発・サードパーティ製の3種類すべてのエージェントに対応する点が特徴だ。 ガバナンスの三原則 Agent 365のガバナンスモデルは以下の3軸で構成される。 最小権限（Least Privilege）: エージェントが業務に必要な最低限の権限のみ保持 継続的検証（Continuous Verification）: アクセスを常時再評価し、信頼を前提としない 自動レスポンス（Automated Response）: 異常を検知した際の自動的なアクセス停止・警告 これはゼロトラストの考え方をそのままAIエージェントに適用したものだ。 ライセンスと価格 GA時点での価格はユーザー1人あたり月額$15。新たに発表されたMicrosoft 365 E7スイートにも包含される。 ライセンス体系で注目すべきは「エージェント自体にはライセンスが不要」という点だ。ライセンス済みユーザーの代理で動作するエージェントは、ユーザーのAgent 365ライセンスでカバーされる。 ただし記事執筆時点で未解決の問題がある——人間の監督なしに自律的に動作するエージェント（ユーザーに紐付かない完全自律型）のライセンス扱いが未明確だ。この点はGA後の続報を注視したい。 Frontierプログラム参加組織は現在、GAまで25ライセンスを無料取得できる（有効期限2026年12月）。エージェント活用を検討中の組織はいまのうちに確保しておく価値がある。 実務への影響——日本のIT管理者に何が変わるか NHI管理がようやく「制度化」される 今まで多くの組織でAIエージェントは「野良スクリプト」「仮のサービスアカウント」的な存在だった。権限は広めに取り、管理台帳にも載らず、誰が何の目的で作ったかも不明——そんな状態の組織は少なくないはずだ。 Agent 365はNon-Human Identity（NHI）であるエージェントに対して、人間と同等の管理フローを強制的に適用する仕組みだ。これはガバナンス上の大きな前進であり、特にJTC1対応・ISO27001・ISMS対応を進めている企業にとって、エージェントの棚卸しと管理が「やらなければならない課題」から「仕組みで対応できる課題」へと変わる転機になる。 実務での即戦力ポイント Frontierプログラムへの参加を急ぐ: 無料の25ライセンスはGA前までの取得が前提。M365管理センターで有効化するだけなので、エージェント活用検討中の組織はすぐ動いた方がいい。 既存の「野良エージェント」を棚卸しする: Agent 365の導入前後に、社内で稼働しているPower AutomateフロやCopilot Studioのエージェントを一覧化しておく。GA後に一気に適用する際の基盤になる。 ゼロトラスト設計の延長として計画する: エージェントへの権限付与はConditional AccessやPIMと整合させた設計が求められる。Just-In-Timeのアクセス付与がエージェント管理にも標準的な手段として使えるか、早期に検証を進めたい。 サードパーティエージェントの棚卸し: Agent 365は自社開発以外のサードパーティ製エージェントも管理対象になる。ベンダー製SaaSのAIエージェント機能がどこまでAgent 365に対応してくるかをベンダーに確認しておくと、移行計画が立てやすい。 筆者の見解 率直に言って、Agent 365の方向性は正しいと思う。 これまでAIエージェントの議論はどうしても「何ができるか」ばかりに偏り、「どう管理するか」が後回しにされてきた。特に日本のエンタープライズ環境では、ガバナンスが整備されていない状態でエージェントが増殖し、気づいたら誰も全体像を把握できない——というパターンが容易に想像できる。Agent 365はその構造問題に正面から手を打つ試みだ。 結局のところ、自動化の最大のボトルネックは「人間の関与が必要な認可・管理プロセス」にある。NHIであるエージェントを人間と同じ管理フレームワークに乗せることで、そのボトルネックを解消しながらガバナンスを担保できる——この設計思想は評価したい。 一方で、ライセンス体系にまだ曖昧さが残っている点は正直気になる。完全自律型エージェントの扱いが未確定なまま5月1日を迎えることになれば、導入計画を立てたIT部門が現場で混乱するケースが出てくるだろう。GAまでの残り期間で明確にしてほしい。 MicrosoftにはAIエージェントの世界においても統合プラットフォームとしての強みを発揮できる土台がある。Agent 365がその一角を担う存在として機能することを期待している。 出典: この記事は Agent 365: Microsoft’s Enterprise AI Control Plane explained – Governance, Licensing and Strategic impact の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotに、Anthropicが開発するClaude Sonnetモデルが正式に追加された。これまでOpenAIのGPTシリーズのみだったAIモデルの選択肢が広がり、Copilot Chatのモデルセレクターから用途に応じたモデルを選べるようになる。「Copilot＝GPTだけ」という構図が変わりつつある今、管理者とエンジニアが押さえておくべきポイントを整理する。 何が変わったか Microsoft 365 Copilotライセンスを持つユーザーは、Copilot Chat内のモデルセレクターからClaude Sonnetを選択できるようになった。まずFrontierプログラム参加者向けに先行提供が開始されており、一般展開は2026年4月初旬完了予定（以前の予定から若干遅延）。Frontierプログラムでは上位モデルのClaude Opus 4.7も利用可能だ。 AnthropicはMicrosoftのサブプロセッサとして位置づけられており、Microsoft Data Protection AddendumおよびProduct Termsの適用範囲内で動作する。既存のEnterprise Data Protectionは引き続き有効で、Copilot利用時のデータ保護の基本的な枠組みに変更はない。 管理者が必ず確認すべき地域要件 この機能を一律に展開できるわけではない。以下の点を必ず確認してほしい。 利用不可の環境 政府クラウド（Government Cloud）および主権クラウド（Sovereign Cloud）：Anthropicモデルは提供されず、モデルセレクター上にも表示されない オプトインが必要な環境 EU/EFTA諸国・英国に所在するテナント：Anthropicはデフォルトオフ。管理者がサブプロセッサ設定を確認し、明示的にオプトインしなければユーザーには表示されない データ処理の注意点 AnthropicモデルはEUデータ境界（EU Data Boundary）および国内処理コミットメントの対象外。データが欧州域内で処理されることを要件とする組織は、この点を慎重に評価する必要がある 日本のテナントについては、デフォルトで有効化される見込みだが、自組織のデータ処理ポリシーとサブプロセッサ設定を今一度確認しておくことを勧める。 実務での活用ポイント 「モデルが増えた」で終わらせず、使い分けの設計まで踏み込んでほしい。 タスクに応じたモデル使い分けを組織内でガイドライン化する：議事録要約・メール返信といった定型業務と、複雑な分析・長文の文書作成では、最適なモデルが異なる場合がある。ユーザーが試行錯誤しやすい環境を整えつつ、組織としての推奨パターンを整備するとよい EU/EFTAテナントの管理者はオプトイン手順を今すぐ確認：Anthropicをサブプロセッサとして有効化するには管理センターからの設定変更が必要。ユーザーからの「使えない」問い合わせが来る前に準備しておこう 政府系・公共系組織は現時点では選択肢なし：無理に試みず、将来対応を注視する姿勢で問題ない Frontierプログラム参加者は上位モデルも積極的に評価を：新しいモデルの特性をいち早く把握しておくことは、組織のAI活用戦略を精緻化するうえで有益だ 筆者の見解 この動きをどう受け取るか。筆者の率直な印象は「ようやく」だ。 Copilotが登場して以来、「OpenAIのモデルしか選べない」という制約は、ユーザーから繰り返し指摘されてきた課題だった。業務の内容によっては別のモデルの方が適しているケースがあることは、実際に使い込んできた人ならば体感として理解していることだろう。その意味で、モデルセレクターの実装とサードパーティモデルの統合は、方向性として正しい。 Microsoftには統合プラットフォームとしての底力がある。TeamsやOutlookなど業務アプリケーションとの深い連携、企業グレードのデータ保護と管理機能——これらはどんなスタンドアロンAIツールにも真似できない強みだ。今回の選択肢拡張はその強みをより活かせる仕組みへの一歩であり、こういうことを積み重ねていけばCopilotはまだ十分に本領を発揮できると信じている。 一方で、モデルの追加はあくまで手段であって目的ではない。「何のモデルが使えるか」より「どのタスクにどう使えばユーザーの生産性が上がるか」という体験設計の方が、長期的な価値を決める。選べるモデルが増えることで「どれを使えばいいかわからない」という混乱を生まないよう、UIとガイダンスの充実にも引き続き力を注いでほしい。 AI活用の現場では「1つのモデルに賭ける」より「状況に応じて最適な選択ができる」環境の方が確実に強い。今回の統合は、その環境を企業のメインワークスペースで実現する試みだ。EU圏のデータ処理制約など課題も残るが、日本の企業にとっては今すぐ活用を検討できる選択肢が増えた——その事実は素直に評価していい。 出典: この記事は Anthropic Claude Sonnet is now available in Microsoft 365 Copilot (MC1247880.2) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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

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

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