M365

Microsoft が2026年にMicrosoft 365の主要セキュリティ機能を標準化すると発表した。Defender for Office 365 Plan 1・URLタイムオブクリック保護・Intuneの機能強化が新たに標準装備となり、8月1日までに展開完了予定。同年7月1日には全世界で価格改定も実施される。 何が変わるのか Microsoftは今回の変更を「プラットフォームの進化」と位置づけており、主に以下の3軸で機能が拡充される。 1. セキュリティ機能の標準化 これまでアドオン扱いだったプレミアムセキュリティ機能が、より多くのライセンスに組み込まれる。 Microsoft Defender for Office 365 Plan 1 がE3を含む多くのライセンスに標準搭載 Safe Links（URLタイムオブクリック保護）・Safe Attachments による自動適用ポリシーが全ユーザーへ フィッシング対策、マルウェアスキャン、脅威検出が標準機能に Security Copilot エージェントがDefender・Intune・コンプライアンスツールに統合され、検出・調査・対応を自動化 Safe Linksは、メールやTeams内のURLをクリックした瞬間に最終遷移先を検査する機能だ。従来は別途ライセンスが必要だったが、2026年8月以降は追加費用なしで有効になる。 2. デバイス管理の強化 Intuneの機能もライセンス階層を超えて拡充される。 Intune Remote Help・Advanced Analytics・Intune Plan 2の一部がより多くのライセンスに含まれる E5限定だった特権管理・アプリガバナンス・Cloud PKIが下位プランにも展開 ハイブリッドワーク・リモートワーク環境でエンドポイント管理に苦労しているIT部門にとっては、追加投資なしで管理能力が向上する点が大きい。 3. AI機能のコア化とCopilot Chat Microsoft 365 Copilot ChatがWord・Excel・PowerPoint・Outlook・Teamsなど主要アプリに組み込まれる。メール下書き支援・文書生成・データ分析・会議準備支援が標準的に利用できる形に近づく。 4. 価格改定（2026年7月1日〜） Business・Enterprise（E3/E5）・Government・Nonprofitの各プランで価格が改定される。Microsoftは「拡充した機能の価値を反映したもの」としているが、具体的な改定幅は地域・契約形態によって異なる。 実務への影響――日本のIT管理者が今すぐ動くべきこと ライセンスの棚卸しを急げ 7月の価格改定より前に契約更新が控えている組織は、今が最大の判断ポイントだ。E3からE5へのアップグレードが割安になるケースがある一方、すでにE5相当のアドオンを積み上げている組織は、今後の標準機能との重複を整理する好機でもある。 Safe Links・Safe Attachmentsは自動適用に備えよ 組み込み保護ポリシーが自動的に有効化されると、一部の既存ポリシーや業務フローと干渉する可能性がある。URLリライト動作の変更が社内の業務システムやSSOフローに影響しないか、事前の確認が必要だ。展開完了は8月1日予定なので、6〜7月中にテスト環境での検証を進めておきたい。 Intuneの未使用機能を掘り起こせ 「Intuneはとりあえず入っているが使っていない」という組織は多い。今回の拡充で、追加費用なしでAdvanced Analyticsや一部のリモートヘルプ機能が使えるようになる。エンドポイント管理のモダン化を後回しにしてきた組織には、動くきっかけになる。 ポイントソリューションの見直し サードパーティのメールセキュリティ・URLフィルタリング・デバイス管理ツールを個別に契約している場合、M365標準機能と重複する部分を精査することでコスト削減の余地がある。「標準機能で十分か」を評価する際は、機能の深さと自社のリスク要件を照らし合わせること。 筆者の見解 セキュリティ機能の標準化という方向性は、正しい。ライセンスを買っただけで使われていないセキュリティ機能が山積みになっている組織を何十社も見てきた。Safe LinksやDefender Plan 1が自動的に有効になれば、「設定しなかったから保護されていなかった」という事故が減る。インフラとして当然備わっているべきものが、ようやく「デフォルトオン」に近づいている。 ...

Microsoft 365の2026年5月アップデートは、AIエージェント機能の実用化という観点でひとつの節目になる月かもしれない。カレンダーを自律管理する新機能を筆頭に、TeamsやSharePointに及ぶ実務直結の改善が一斉展開された。ただし中には「静かに変わっているもの」もあり、IT管理者は今すぐ内容を確認しておきたい。 Copilot Calendar Agent：AIが「代理行動」する時代へ 今月最大のトピックは Copilot Calendar Agent の正式展開だ。「ダイレクトレポートとの1on1はすべて承認する」「24時間前を切った招集は辞退する」——こうした自然言語の指示を与えると、Copilotが以降のカレンダー管理を自動で引き受けてくれる。 従来のCopilotはあくまで「提案して人間が承認する」流れだった。Calendar Agentはルールに基づいてCopilotが実際にアクションを起こす。これはMicrosoft 365のAIが真の「エージェント」機能を持ち始めたことを意味する。すべての処理は後から確認・修正できるため、突然予定が狂うリスクも自分でコントロールできる。 Outlookでも同月に強化が入っており、長いメールスレッドの要約、フォローアップの提案、会話の全文脈を踏まえた返信草稿生成が追加されている。モバイルの日程調整アシスタントも強化され、スマートフォンから直接会議の提案・仮承認の管理ができるようになった。 Teams：地道だが効く5つの改善 TeamsのMay 2026アップデートは「なぜ今まで動いていなかったのか」という機能が並ぶ。 リアルタイム言語翻訳 は話者の言語を自動検出してライブキャプションに翻訳を表示する。言語や時差をまたぐチームには即戦力になる機能だ。 DND/フォーカスモードでの通知抑制 はWindows 11のDND設定に連動してTeamsの通知を止める。集中作業中にTeamsの通知が割り込む問題はユーザーの長年の不満だったが、ようやく正式対応された。 「Transcribe only」オプション は録画を一切作らずに文字起こしだけを取得できる機能だ。映像の保存をコンプライアンス上避けたい企業にとっては待望の機能になる。 ほかにも、ミュート会話と会議チャットのサイドバー分離表示、ミニウィンドウ状態でのリアクション操作といった細かいUX改善が含まれる。5月中旬には会議参加前にマイク・スピーカーを事前チェックする機能も追加予定で、「聞こえますか？」確認の時代が終わるかもしれない。 SharePoint：全面リデザインとAI補助ページ作成 UIの刷新とナビゲーション簡素化に加え、ページ作成にCopilotが入った。「こういうページを作りたい」と説明するとCopilotが草稿を生成してくれる。SharePointは長年「使いにくい」と敬遠されがちなプラットフォームだったが、このアプローチは入口の障壁を下げる意味で正しい方向だ。段階的ロールアウト中のため、組織内での展開状況を随時確認しながら社内ドキュメントの更新計画を立てるのがよい。 OneDriveの挙動変更：チームへの周知を急げ 5月初旬から適用されているこの変更は目立たないが影響が大きい。Webブラウザ経由でOneDriveファイルを削除した場合、従来はローカルのゴミ箱にも入っていたが、今後はそうならない。削除したファイルはOneDriveのクラウド側ゴミ箱のみに入る形に変わった。 ストレージ消費と同期負荷を削減するための変更ではあるが、「ローカルのゴミ箱から復元できると思っていた」という誤解からデータ紛失が起きやすい。エンドユーザーへの周知を今すぐ行っておきたい。 実務への影響 Calendar Agentのルールは最初は限定的に: 「全員からの招集を承認する」のような包括的ルールは予定の詰め込みに繋がりやすい。特定の相手や条件に絞った設定から始めるのが安全だ DND連動はiOS/Android端末での動作を別途確認: Windows 11連動は明記されているが、モバイル端末での挙動は環境によって異なる可能性がある OneDriveの削除ポリシーをヘルプデスク向けに文書化: 問い合わせが増える前に、利用者向けガイドとFAQを更新しておく 「Transcribe only」の利用ポリシーを整備: 録画なしの文字起こしが使えるようになると、会議の記録方針を改めて整理する機会になる。組織のコンプライアンス要件と照らして利用ガイドラインを作っておきたい 筆者の見解 Copilot Calendar Agentは、ここ数年のCopilotアップデートの中で「使える」と素直に感じた機能のひとつだ。OutlookとCalendarという「毎日必ず触れる場所」にAIを組み込む設計は、Microsoftが持つプラットフォームの強みをきちんと活かしている。こういう方向でのアップデートをぜひ続けてほしい。 MicrosoftはOutlookやTeamsに圧倒的なユーザーベースを持っており、AIが日常業務の中に自然に溶け込む場所として、これほど条件が揃ったプラットフォームは他にない。Calendar Agentはその強みを正確に活かした設計だと感じる。実力は十分にある。その実力が製品の形で届き続けることを期待している。 一方で、OneDriveのゴミ箱挙動変更のような「サイレントな破壊的変更」はもったいない。機能価値そのものに問題はなく、変更の意図も理にかなっているだけに、ユーザーへの事前コミュニケーションが薄いのが惜しい。こうした積み重ねが現場の「アップデート不信」に繋がる。変更内容の丁寧な告知体制を整えることは、Microsoftの規模と体制を考えれば十分に実現できるはずだ。 SharePointのリデザインは、長年の課題だった「ちゃんと使われるプラットフォームにする」という方向に踏み込んだ点を評価したい。Copilotによるページ生成はその出発点に過ぎないが、今後の進化に期待したい取り組みだ。 出典: この記事は Explore Exciting Enhancements In Microsoft 365 Updates May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、MicrosoftはSharePointのホームサイト機能を大幅にアップデートする。新しいWebパーツの追加、管理センターからの設定簡略化、そしてTeams内に展開する「Viva Connections」アプリのリブランドが柱だ。既存環境への影響はほぼないが、組織のイントラネット戦略を見直す良いタイミングと捉えるべきだろう。 Viva ConnectionsがSharePointアプリに改名される 最も目立つ変更は名称変更だ。Teams内で動作していた「Viva Connections」アプリが、「SharePoint app in Teams」として改名される。 既存の構成を持つ組織では、設定済みのアプリ名・ロゴ・体験はそのまま維持される。データのアクセス制御やパーミッションにも変更はない。つまり現時点で動いている環境は、何もしなくてもそのまま動き続ける。 なぜこの改名が重要か。「Viva」ブランドのもとに分散していた機能群を整理し、「SharePoint」というすでに浸透したブランドに集約することで、ユーザーが自分の使っているものを把握しやすくなる。MicrosoftがTeams + SharePointのシームレスな体験として長年積み上げてきた方針に、一貫した動きだ。 ホームサイト専用の新Webパーツが2つ登場 SharePointホームサイト（組織のトップページとして指定されたサイト）に特化した新機能として、以下の2つのWebパーツが追加される。 Resourcesウェブパーツ 組織内のよく使うリンク、ツール、ポータルへのアクセスを視覚的に整理して提示できる。社内ツールへのランチャー的な役割を担わせるのに最適だ。 Announcementsウェブパーツ お知らせ・周知事項を整理して掲示できる専用Webパーツ。既存のNewsウェブパーツとは役割が異なり、掲示板的な用途向けと見られる。 いずれも指定されたホームサイトのみに適用される機能であり、一般のSharePointサイトには提供されない点に注意が必要だ。 管理センターからの設定が大幅に簡略化 従来、SharePointホームサイトの指定と設定は手順が煩雑だったが、今回の更新でSharePoint管理センターから直接ホームサイトの指定・設定が完結するようになる。 特に管理者が複数の拠点・部門向けにホームサイトを管理する大規模組織では、運用コストの削減につながる地味に大きな改善だ。 さらに、SharePoint app in Teamsのカスタマイズ体験が刷新され、デスクトップ・モバイルそれぞれのTeams体験を管理者が細かく調整できるようになる。 展開スケジュールと準備 フェーズ 開始 完了予定 ターゲットリリース（全世界） 2026年5月初旬 2026年5月末 一般提供（全世界・GCC・GCCH） 2026年6月初旬 2026年6月末 Microsoftは「対応必須の作業はない」としているが、実務上は以下の対応を推奨する。 ヘルプデスクへの事前周知: 「Viva ConnectionsがSharePointに変わった」という問い合わせが来る前に、担当者にブリーフィングしておく エンドユーザーへのコミュニケーション: アプリ名が変わると混乱するユーザーは必ず出る。簡単な案内を事前に準備しておきたい 内部ドキュメントの更新: 運用手順書や管理マニュアルに「Viva Connections」と記載があれば順次修正する 筆者の見解 「Viva」ブランドの整理は評価したい。Vivaシリーズが登場した当初から「ブランドが散漫で、現場ユーザーが自分の使っているものを認識しにくい」という声は絶えなかった。SharePointという長年にわたって浸透した名称に集約することで、エンドユーザーの認知コストは確実に下がる。 ホームサイトの管理体験改善も、地道だが正しい方向だ。大企業のイントラネット担当者が「SharePointは難しい」と感じる理由の一つが、管理機能の分散と複雑さにある。管理センターへの集約はその解消に向けた着実な一手といえる。 一方、ResourcesウェブパーツとAnnouncementsウェブパーツが「ホームサイト限定」である点については、一般サイトでも使いたいという需要は確実に存在する。まず実績を積んでから展開するMicrosoftのアプローチは理解できるが、なるべく早期に一般提供してほしいというのが現場担当者の本音だろう。 SharePointはM365の中で、地味に着実に改善が積み重なっているプロダクトの一つだ。派手な発表こそないが、使う側の体験は確実に良くなっている。今回の更新もその積み上げの一部として、現場のイントラネット担当者はしっかりキャッチアップしておきたい。 出典: この記事は Updates to SharePoint Home Sites の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月は、Microsoftのライセンス体系にとって「一気に動いた月」だ。Windows 365 Businessの値下げ、待望のMicrosoft 365 E7 Frontierスイートの一般提供開始、CSP猶予期間の廃止と新Extended Term構造への移行、そしてSoftwareサブスクリプション特典のSA統合——これだけの変更が同時期に重なるのは珍しい。順番に整理していこう。 Microsoft 365 E7 Frontierスイートが正式登場 2026年5月1日より、Microsoft 365 E7 Frontier Suiteが購入可能になった。このスイートはCopilot・Agent 365・Entra Suiteの3製品を一つのSKUにまとめたものだ。月払い・年払い・3年払いのいずれにも対応し、CSPチャネル経由で提供される。また、Agent 365は単独製品としてもこの日から一般提供が開始された。 すでにMicrosoft 365 E5＋Copilotを運用している組織にとっては、「エージェントベースの生産性」への最初の乗り換え先として位置づけられる。ただし注意点がある。スイートの価格が割安かどうかは、現在のEntraライセンスのカバレッジとCopilot採用率によって大きく変わる。構成パーツを個別に積み上げた場合のコストと必ず比較してほしい。 CSP猶予期間廃止——デフォルト動作が「コスト増」になる 実務上、最も注意が必要な変更がこれだ。2026年5月4日をもって、CSPプログラムのフリー猶予期間が廃止された。代わりに導入されたのがExtended Term（延長期間）という仕組みだ。 Extended Termの料金は月払いレート（年払いの約1.2倍）に加えて3%のアップリフトが上乗せされる。更新保留中の一時的なブリッジ用途を想定した設計だが、問題は何も操作しないと自動的にこのExtended Termへ移行する点だ。更新サイクルを能動的に管理していなければ、気づかないうちに割高な料金を払い続けることになる。 CSP契約の終了時には今後、(1)停止・(2)更新・(3)Extended Termへ移行、の3択を明示的に選択する必要がある。更新カレンダーの管理が甘い組織ではコスト漏れが発生しやすい構造変更だ。 Windows 365 Businessが20%値下げ 2026年5月1日から、Windows 365 BusinessのSKU価格が最大20%引き下げられた。バックエンドのCloud PC再接続エクスペリエンスの最適化によりリソース効率が向上した結果、とMicrosoftは説明している。新規顧客には即日適用、既存顧客は次の更新日から新価格が反映される。 クラウドPCの価格は長らくSMBには割高感があったが、今回の値下げは中小企業への普及を加速させる可能性がある。競合クラウドデスクトップサービスの台頭を意識した価格調整とみるのが自然だろう。既存契約の更新日と新価格の反映タイミングを自社のカレンダーで確認しておきたい。 SoftwareサブスクリプションとSAの特典が統合 地味だが長年の「ずれ」が解消された変更もある。2026年4月1日より、CSP経由で購入したSoftwareサブスクリプションの特典が、Software Assurance（SA）の特典と同等になった。主な変更点は以下の2点だ。 AzureまたはAuthorized Mobility Partner共有ハードウェアへのデプロイに対するライセンス使用権の向上 SQL ServerのアウトソーシングオプションがSoftwareサブスクリプションでも利用可能に CSPでのSoftware購入を検討していた組織には追い風になる変更だ。 実務への影響 即確認すべきアクション CSP更新日を棚卸し: 現在保有するCSPサブスクリプションの満了日を確認し、Extended Termへのデフォルト移行を防ぐプロセスを整備する Windows 365 Business契約の更新日確認: 既存顧客は次回更新で20%安の新価格が適用されるため、更新日を把握しておく E7 Frontierスイートのコスト試算: M365 E5＋Copilot運用中の組織は、個別SKU積み上げとスイート価格を試算する。特にEntraライセンスの重複が鍵になる 筆者の見解 今回の変更の中で、筆者が最も注目しているのはWindows 365 Businessの値下げだ。クラウドPCというコンセプト自体はSMBにとって非常に合理的で、端末管理コストの削減・セキュリティの均質化・BCP対策の一石三鳥を期待できる。価格が現実的になってきたことで、中小企業での評価案件が動き始めるだろう。 E7 Frontierスイートについては、本質的に重要なものになっていると考えている。エージェントが実務で役に立つこと、そしてそれをきちんと管理・監視する仕組みが組織に不可欠であること——特に企業利用においてはこの両輪が揃っている必要がある。自分が管理者ならば導入する。Microsoftが統合プラットフォームとしてエージェント機能を本格的に組み込んできた方向性は正しい。 ただし、課題も明確だ。現時点でM365のエージェント動作は、Claude CodeやCodexといった開発者向けツールと比較すると数ヶ月遅れのクオリティにある。個人で腰を据えて使う分にはClaude CodeやCodexのほうが圧倒的に性能が高く、成果も出る。しかし、複数人の組織で使う、データがSharePointライブラリにある、といった企業の現実を考えると、それらのツールでは対応しにくい。E7のように全社員が同じ基盤で使える仕組みには大きな価値がある。 一方で、全従業員がE7を使いこなせるかというと、まったくそんなことはない。E7を全社員が効率よく活用できている組織は、おそらく世界中を探してもほとんど存在しないだろう。仕組みとしては素晴らしいが、性能面の課題と「多くの人が使いこなし方を知らない」という現実の壁は大きい。ポジショニングが難しい製品だが、だからこそ今後の進化に注目している。 ...

企業内でAIエージェントの導入が加速する中、Microsoft 365プラットフォームがその「管理基盤」として本腰を入れ始めた。2026年5月のAgent 365アップデートでは、観察・ガバナンス・セキュリティという3つの軸でAIエージェントの管理機能が大幅に拡充された。これまで「とりあえず動かしてみた」段階にあったエンタープライズAI導入を、本格的な運用フェーズへ押し上げる内容だ。 AIエージェント管理の「3軸」とは 観察（Observability） は、エージェントが何をしているかを可視化する機能だ。どのエージェントがどのリソースにアクセスし、何のアクションを実行したかを追跡できるようになる。AIが「なんとなく動いている」状態から脱却し、IT管理者がその挙動を継続的にモニタリングできる環境が整う。 ガバナンス（Governance） は、エージェントの動作範囲をポリシーで制御すること。今回のアップデートで注目すべき点は、Intuneとの統合アプローチだ。デバイス管理で広く普及しているIntuneの仕組みをAIエージェントのポリシー管理に応用することで、管理者が新たなコンソールや概念を学ぶことなく、既知のツールでエージェントを制御できる。既存投資を活かせるという意味で、エンタープライズにとって現実的な選択肢だ。 セキュリティ（Security） の目玉が、ランタイムブロック機能のパブリックプレビュー開始だ。実行中のエージェントが不審な動作を行った際、Defenderの脅威検知機能と連動してリアルタイムでブロックできる。EDR（エンドポイント検出・対応）の概念をAIエージェントにまで拡張した新しいセキュリティモデルと言えるだろう。 Non-Human Identity管理としての本質 この機能群が重要なのは、単なる「便利になった」という話ではない。企業内のAIエージェントは実質的に Non-Human Identity（NHI） として機能する。人間の代わりにメールを送り、ファイルにアクセスし、外部APIを叩く。そのエージェントが「常時フルアクセス権を持ったまま動き続ける」状態は、セキュリティ上の最大リスクだ。 IntuneおよびDefenderとの統合は、AIエージェントを「もう一つのエンドポイント」として既存のセキュリティフレームワークに組み込む試みだ。ゼロトラストの原則に照らせば、エージェントに対しても最小権限・Just-In-Timeアクセスを適用することが正しい姿であり、今回の機能拡充はその方向性と一致している。 実務への影響——日本のIT管理者がいま考えるべきこと 「動かすこと」から「管理すること」へ AIエージェントをPoC（概念実証）で試した企業は多いが、本番運用への移行時に壁となるのが「何をしているかわからない」問題だ。今回の可観測性機能はこの不安を直接解消する。まずログを取り、監査証跡を確保することから始めるのが現実的なアプローチだ。 Intune未導入企業は検討の好機 Agent 365のガバナンス機能を最大限活用するには、Intuneが前提となるケースが多い。まだデバイス管理をオンプレADとグループポリシーで行っている組織は、この機会にIntune移行を検討してほしい。AIエージェント管理だけでなく、全体的なセキュリティ態勢の向上にも直結する。 ランタイムブロックは段階的に適用する パブリックプレビューの機能はまず検証環境で動作確認すること。ランタイムブロックは設定を誤ると正規のエージェント動作まで遮断してしまうリスクがある。監視モードからスタートし、ルールを段階的に厳格化する進め方を強く推奨する。 筆者の見解 AIエージェントの管理基盤として、Microsoft 365プラットフォームの統合力が発揮されつつあると感じる内容だ。IntuneやDefenderという既存資産を活用できる点は、エンタープライズが追加投資なしに恩恵を受けられるという意味で、本来のMicrosoftらしい強みだと思う。 ただ正直に言えば、こうした基盤整備が「使いたくなるエージェント体験」とセットになっているかどうかは、引き続き注視が必要だ。管理機能がいくら充実しても、エージェントそのものが業務で継続的に使われなければ意味がない。体験と管理の両輪が揃ってこそ、エンタープライズAIの本格普及につながる。 Microsoftには、それだけのプラットフォーム力と顧客基盤がある。このガバナンス強化の取り組みが、エージェント体験の向上とともに加速していく流れに期待したい。今回のアップデートは、その意味で確実に正しい一手だ。 出典: この記事は What’s New in Agent 365: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のプロファイルカードに、ユーザーの受賞歴や資格情報を表示できる新機能が一般公開（GA）された。Message Center通知 MC1250272（2026年3月24日最終更新）で案内されており、日本のM365テナントにも順次展開中だ。 HRシステムなどと連携してCopilotコネクターから取り込む方法が「正規ルート」として紹介されているが、実はMicrosoft Graph PowerShell SDKを使えばCSVや外部DBから直接更新することも可能だ。本記事では、その具体的な手順と日本のIT現場への活用ポイントを解説する。 プロファイルカードに何が追加されたのか TeamsやOutlookなどのアプリでユーザー名にホバーしたときに表示されるプロファイルカード。これまでは氏名・役職・部署・連絡先程度の情報しか表示できなかったが、今回の更新で以下の情報も追加できるようになった。 personAward（受賞歴）: 表彰名・発行機関・受賞日・Web URL・サムネイル画像 personCertification（資格情報）: 資格名・取得日・有効期限・発行機関 これらはMicrosoft Graph上のリソースとして定義されており、複数のリソースを組み合わせてプロファイルカードが構築される仕組みだ。 2つのデータ投入経路 ① Copilotコネクター（推奨経路） HRシステムや外部データベースと継続的に同期する場合は、「Copilot connectors for people data」カテゴリのコネクターを使うのが正規ルートだ。定期的なデータ同期が必要な大規模テナントにはこちらが向く。 ② Microsoft Graph PowerShell SDK（手動・スクリプト経由） Copilotコネクターの構成が整っていない環境では、Graph PowerShell SDKのNew-MgBetaUserProfileAwardおよびNew-MgBetaUserProfileCertificationコマンドレットで直接更新できる。CSVファイルや既存の社内システムからデータを読み込んでバッチ処理することも容易だ。 実装に必要な権限とコマンド例 必要な権限 委任セッション（対話型）: Entra IDの「User Administrator」ロール以上 アプリのみのセッション: User.ReadWrite.All スコープへの管理者同意 受賞歴の追加例 出典: この記事は Using the Microsoft Graph PowerShell SDK to Update User Profiles の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotが2026年4月に注目すべきアップデートを迎えた。最大のトピックは外部AIモデルの標準統合だ。Anthropicが開発したClaudeモデルが、一部の有効テナント（eligible tenants）でデフォルトオンとして展開され、Word・Excel・PowerPointでも利用できるようになった。あわせて管理者向けに「Power Users Insights」がCopilot Dashboardに追加され、社内の活用状況を4段階で可視化できるようになった。 外部AIモデルのデフォルト統合が意味するもの これまでMicrosoft 365 CopilotはMicrosoftが独自に構築・調整したモデルを中心に動作してきた。今回のアップデートで外部モデルを「デフォルトオン」として取り込んだことは、Microsoftの戦略的な方向転換を示している。 ユーザーは意識しなくても、バックグラウンドで複数のAIモデルが処理を分担するようになる。Wordでの長文要約、Excelでのデータ分析、PowerPointのスライド生成など、作業の種類に応じて最適なモデルが選ばれる仕組みだ。 「有効テナント」という条件が付いているため、現時点で全テナントに一斉展開されるわけではない。テナント管理者はMicrosoft 365管理センターで適用状況を確認し、必要に応じてモデル設定をコントロールできる。 Power Users Insights：管理者が待ち望んでいた機能 Copilot Dashboardに追加された「Power Users Insights」は、ユーザーをCopilot活用度に応じて4段階に分類する機能だ。 Power Users：高頻度・積極的に活用 Habitual Users：定期的だが活用幅は限定的 Novice Users：使い始めたばかり、または散発的 Non-Copilot Users：ほぼ未使用 この分類により、管理者は「誰が使っているか」だけでなく「どのように使っているか」を定量的に把握し、ROIの可視化やトレーニング計画の立案に役立てられる。 実務への影響 テナント管理者はまず確認を 有効テナントでのClaudeモデル自動展開後、ユーザー側に特段の操作は不要だが、管理者は以下を確認しておきたい。 データ処理のコンプライアンス確認：外部モデル統合後もMicrosoftのデータ処理規約（DPA）が適用される。金融・医療・官公庁など規制のある業種は、情報部門・法務との連携を先に済ませておく Power Users Insightsをコスト説明に活用：ライセンス費用対効果を説明する際の根拠として使える。Non-Copilot Usersへの働きかけを体系化するきっかけにもなる 社内ヘルプデスクへの事前周知：Copilotの応答品質や挙動が変わる可能性があるため、ユーザーサポート担当への共有を推奨する エンジニア・情報システム担当にとっての意味 外部モデルが統合されても、Microsoft 365の管理インターフェースや権限モデルは変わらない。Graph APIやMicrosoft 365 Defenderとの連携も引き続き機能する。現時点では管理者がモデルを細かく制御する手段は限定的だが、将来的なポリシー制御の拡充を期待したいところだ。 筆者の見解 今回のアップデートで最も注目すべきは、Microsoftがプラットフォームとして「外部AIモデルを受け入れる」方向に踏み出したことだ。 率直に言えば、M365 Copilotはこの数年、「統合されていることの価値」を十分に発揮できていなかった。それでもMicrosoftが選ばれ続けてきたのは、Teams・Exchange・SharePoint・セキュリティ機能が一体化した「統合プラットフォームとしての強さ」があったからだ。 今回の動きはその強みをさらに活かす方向への前進だと見ている。Copilotが自社モデルだけに閉じるのではなく、優れたモデルを柔軟に組み込める「オーケストレーション層」へと進化するなら、M365プラットフォームの価値はむしろ上がる。Microsoftはその力を持っているのだから、この方向性は正しい。 日本の企業にとって現実的な使い分けは、Teamsの議事録要約やOutlookの定型業務はCopilotに任せ、複雑な分析や創造的な作業には最適なモデルを選ぶという形だろう。今回の統合は、そのアーキテクチャをMicrosoft自身が公式に取り込みにきたと解釈できる。 Power Users Insightsはシンプルながら待望の機能だ。ライセンスコストの正当化に苦労しているIT管理者にとって、活用状況を定量的に示せるツールは率直にありがたい。 Copilotが真の意味で「最前線に並ぶ」ための条件は整いつつある。あとは、ユーザーが「使い続けたいと思える体験」を積み上げることだ。統合プラットフォームとしての底力があるのだから、それは十分に実現できると思っている。 出典: この記事は What’s New in Microsoft 365 Copilot | April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

条件付きアクセス（Conditional Access、以下CA）は、Microsoft Entra ID（旧Azure AD）が提供するゼロトラストセキュリティの中核機能だ。その中でも「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」テンプレートは、一見シンプルに見えて、適用した瞬間から想定外の問題を引き起こしやすいことで知られている。 Petri.comが指摘したのは、より本質的な問題だ。Microsoftは「ポリシー」ではなく「デフォルト値」という形で、組織のセキュリティ上の重要な判断を代わりに下している──という構造的な問題である。 「準拠済みデバイス必須」とは何か CAテンプレートの「準拠済みデバイスまたはハイブリッド参加デバイスを必要とする」とは、端的に言えば「IntuneなどのMDMで管理・コンプライアンス確認ができたデバイスからのみアクセスを許可する」というポリシーだ。 ゼロトラストの観点から見れば、これは理にかなっている。OSのパッチ状態・ディスク暗号化・ウイルス対策の有効性を確認してからリソースへのアクセスを許可する。紙の上では完璧なゼロトラストアーキテクチャだ。 「シンプル」が「複雑」に変わる瞬間 このポリシーを組織全体に適用すると、以下のようなケースで即座に問題が噴出する。 ゲストユーザー・外部パートナー 取引先のユーザーは、自社Intuneに登録されていない。当然「準拠済み」判定は不可能。ゲストアクセスが一切できなくなるケースが頻発する。 BYOD（個人所有デバイス） 国内でも増えているBYOD環境では、個人所有PCやスマートフォンはIntuneに登録されていないことが多い。登録しようとすれば、プライバシー上の問題も生じる。 自動化・サービスアカウント バッチ処理やRPA、スクリプト実行に使うサービスアカウントは、特定のデバイスから動かない場合がある。デバイスベースの条件を適用すると、既存の自動化処理が軒並み止まる。 緊急アクセス（Break Glass）アカウント 障害時に使う緊急管理アカウントは、このポリシーの例外設定を忘れると、本当に必要なときに使えなくなる。 Microsoftが「ルールブック」を書いている問題 記事が本質的に指摘しているのは、Microsoftがデフォルト設定や推奨テンプレートを通じて、組織のセキュリティポリシーを事実上「代筆」しているという構造だ。 Microsoftの推奨テンプレートは「ベストプラクティス」として提示される。IT担当者はその信頼性を前提に適用しがちだ。しかしそのテンプレートは、あらゆる組織の個別事情を考慮していない。エンタープライズのオンプレミス資産との連携、ゲストユーザーの比率、BYODポリシー、規制対応要件──これらはすべて組織ごとに異なる。 「Microsoftが推奨しているから安全」は正確ではない。「Microsoftの想定する組織に当てはまる場合に限り安全」が正確な表現だ。 実務への影響：IT管理者が今すぐ確認すべき5点 日本のエンタープライズ環境には固有の事情もある。国内の多くの大企業では、レガシーなオンプレミスADとAzure ADのハイブリッド構成が混在している。「ハイブリッド参加デバイス」の条件が正しく機能するかどうかは、ADのドメイン構成やDevice Writeback設定次第であり、一筋縄ではいかない。 以下の点を即座に確認したい。 ゲストユーザー向けの例外ポリシーが存在するか ─ ゲスト向けに別のCAポリシーを用意し、準拠済みデバイス要件を免除または緩和する設計になっているか 緊急アクセスアカウントがCAの対象外になっているか ─ Break Glassアカウントを例外グループに確実に含める サービスプリンシパル・マネージドIDへの影響確認 ─ ユーザーIDとワークロードIDのCAポリシーは別々に設計する Report-onlyモードでの事前検証 ─ いきなり適用せず、まずReport-onlyで影響範囲をシミュレーションする Named Locationsとの組み合わせ ─ 社内IPからのアクセスに条件を緩和するポリシー設計の検討 筆者の見解 条件付きアクセスはゼロトラスト実装の王道であり、「準拠済みデバイス必須」はその中でも特に効果的な制御だ。方向性としては正しい。だからこそ、中途半端な適用が危ない。 Microsoftがテンプレートを提供すること自体は歓迎する。セキュリティ上の「最低水準」を組織全体で引き上げる効果があるからだ。しかし、テンプレートはあくまで「出発点」であり「答え」ではない。 日本のエンタープライズ現場を見ていると、レガシーなセキュリティモデルと最新のゼロトラスト設定が混在した状態が多い。「Microsoft推奨テンプレートを適用したら、翌朝から数百人がTeamsに入れなくなった」という話は珍しくない。それは技術の問題ではなく、自組織のアーキテクチャを理解せずにテンプレートを信じきったことへの代償だ。 Microsoftには、テンプレートの前提条件と対象外ケースをもっと明確にドキュメント化してほしい。「このポリシーはどういう組織には適用できないか」を明示することが、本当の意味でのユーザー支援になる。Microsoftが持つ技術力とエコシステムの強さを考えれば、それは十分できるはずだ──だからこそ「もったいない」と感じる。 ゼロトラストの文脈でこのCAポリシーを使う場合、「適用する・しない」の二択ではなく、「どのユーザー・デバイス・アプリ・リスクレベルの組み合わせに適用するか」という設計思考が不可欠だ。Microsoftのテンプレートはその思考の起点として活用し、自組織の実情に合わせてカスタマイズする──これが正しい付き合い方だ。 出典: この記事は Microsoft Security Without a Rulebook: The Problem with “Require Compliant Device” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年7月1日からMicrosoft 365商用プランが最大43%値上げとなるが、同時にDefender for Office 365やIntuneの主要機能が上位プランへ標準バンドルされる。追加ライセンスを購入していた組織にとっては実質的なコスト最適化になり得る一方、何も準備しないまま迎えるとセキュリティ設定が自動変更されるリスクもある。ライセンス棚卸しと設定確認を今のうちに済ませておきたい。 何が変わるのか：機能バンドルの全容 2026年6月中旬から8月1日にかけて、Microsoft 365 / Office 365 / EMSの各スイートに以下の機能が標準組み込みとなる（対象プランはライセンスブログで確認）。 セキュリティ系（Defender） Microsoft Defender for Office 365 Plan 1：フィッシング・マルウェアへの高度な防御 URLタイムオブクリック保護：メール内URLをクリック時点でスキャンし、悪意あるサイトへのアクセスをブロック デバイス管理系（Intune） Intune Remote Help：デバイスへのセキュアなリモートサポート Intune Advanced Analytics：ユーザーエクスペリエンス改善のためのインサイト Intune Plan 2：MAM（モバイルアプリ管理）向けトンネル、FOTA（ファームウェアOTA更新）、特殊デバイス管理 Intune Endpoint Privilege Management（EPM）：最小権限アクセスの実現 Microsoft Cloud PKI：クラウドベースの証明書ライフサイクル管理 Intune Enterprise Application Management：Win32アプリのエンタープライズカタログ ストレージ Exchange Online：+50GBのメールストレージ追加 管理者が今すぐ注意すべき「自動適用」の罠 特に注意が必要なのは、Defenderの機能は自動で有効化・適用されるという点だ。 Safe Links・Safe Attachmentsの組み込み保護ポリシー、フィッシング対策、URLタイムオブクリック保護がすべてのユーザーにデフォルトで適用される。この「Built-in Protection Policy（組み込み保護ポリシー）」は無効化できない。必要に応じて特定のユーザー・グループ・ドメインへの除外設定は可能だが、完全にオフにする選択肢はない。 さらに、Microsoft Defenderポータルに新しいアラートが出現する可能性がある。運用チームが「見慣れないアラートが大量発生した」と慌てるケースは容易に想像できる。 一方、Intuneの機能はデフォルトでは未設定のまま。こちらは自分で構成する必要があるため、「いつの間にか動いていた」という混乱は起きにくい。 実務への影響：日本のIT管理者にとっての意味 プラス面：アドオンの重複費用を削減できる可能性 Defender for Office 365 Plan 1、Intune Advanced Analytics、Cloud PKIなどをアドオンとして個別購入していた組織では、バンドル後に重複費用が発生することになる。ライセンスの棚卸しを行い、不要なアドオンをキャンセルできれば、実質的に値上げ分を相殺できるケースもある。 注意点：サードパーティゲートウェイとの干渉 ProofpointやMimecastなどサードパーティのメールゲートウェイを運用している場合、Defenderの新しいスキャンポリシーとの干渉が起きうる。メールフローの見直しと「Enhanced Filtering（拡張フィルタリング）」の設定確認を早めに行うことを強く勧める。 ...

Microsoft 365 Copilot の Agent Builder に、ついにスケジュール実行機能が追加された。2026年5月中旬から世界展開が始まっており、月末には完了する見込みだ。毎朝のレポート収集、週次サマリーの自動生成など、「定型だが手を動かすのが面倒」な作業をエージェントに丸投げできる仕組みが整いつつある。 何ができるようになったのか Agent Builder で作成した Copilot エージェントに対して、「いつ・どのくらいの頻度でプロンプトを実行するか」を事前に設定できるようになった。サポートされる実行間隔は以下の通り。 毎時（Hourly） 毎日（Daily） 毎週（Weekly） 毎月（Monthly） 毎年（Yearly） スケジュールにはプロンプト本文・トリガー条件・日時・タイムゾーンを指定できる。設定はユーザーごとに独立しており、エージェントを他のユーザーと共有してもワークフローは共有されない点は注意が必要だ。また、下書きや未公開状態のエージェントではスケジュールは動作しない。 管理者側の対応は不要。既存のテナントポリシーおよび Copilot ポリシーが自動的に適用される設計になっている。 技術的な背景——「人が押す」から「時間が押す」へ これまでの Copilot エージェントは基本的に「ユーザーがプロンプトを入力して初めて動く」リアクティブ（受動的）な存在だった。今回の変更で、エージェントはプロアクティブ（能動的）に動く存在へと変わる。 これはエージェント設計の考え方を根本から変えるアップデートだ。たとえば： 毎朝9時に前日のプロジェクト進捗をまとめてチャットに送る 毎週金曜の夕方に週次レポートのドラフトを作成しておく 月初に先月のコスト分析を自動実行してサマリーを出す こうしたシナリオが、追加の開発なしに実現できるようになる。Power Automate のフローを組んだり、Azure Logic Apps を使ったりしなくても、Agent Builder の UI だけで完結する点は現場にとって大きい。 実務への影響——IT担当者・エンジニアへのヒント まず試すべきユースケース: 朝のダッシュボード代わり: 毎朝決まった時刻にSharePointやTeamsの更新情報をまとめさせる。Copilotが苦手なこともあるが、定型的なまとめ作業なら十分機能する 週次レポートの自動起草: マネージャーが毎週手で書いているサマリーを、エージェントに下書きさせてから編集する運用に切り替える コンプライアンスチェックの定期実行: ポリシー遵守の確認プロンプトを週次で流し、異常があれば通知する仕組みを作る 注意すべき点: スケジュール実行は「ユーザーに代わって自動でデータにアクセスする」ことを意味する。データアクセス権限が既存のまま適用されるため、権限の棚卸しを先にしておくべきだ ワークフローはユーザーごとに独立して動く。組織横断で同じ処理を走らせたい場合は、各ユーザーが個別に設定する必要があり、管理が煩雑になりうる Premium ライセンスが必要。M365 Business Basic や E3 だけでは使えないため、ライセンス構成を確認しておこう 筆者の見解 正直に言えば、この機能は「ようやく」という感想だ。定型業務の自動化は Copilot に最も期待していた領域のひとつであり、それがユーザーの手でノーコードで設定できるようになった意味は大きい。 ただし、ここで冷静になる必要もある。スケジュール実行で動かすのはあくまで「Copilot エージェント」だ。複雑な判断や深い分析を伴うタスクには、まだ得意・不得意がある。Teamsの議事録まとめやOutlookの定型返信候補、週次サマリーの起草といった「繰り返しが明確で、正確性よりスピードが優先される」業務にフォーカスして使うのが現実解だろう。 一方で、この機能がエージェント設計の幅を大きく広げるのは間違いない。「プロンプトを人が毎回打たなくていい」という体験は、AIに慣れていないユーザーにとって大きな心理的ハードルを下げる。組織全体のCopilot活用率が上がるきっかけになりうる。 Agent Builder がこうした実用的な機能を着実に積み上げてきていること自体は評価したい。Copilotが「本当に現場の仕事を変えるツール」になるための地道な進化が、ここにある。その方向性に期待しながら、引き続き使い込んでいきたい。 出典: この記事は Microsoft 365 Copilot: Schedule prompts in Agent Builder の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Entraの2026年5月アップデートが公開され、パスキー運用の柔軟性向上と、レガシー認証の完全廃止という2つの重要な変更が同時に動き始めた。特に後者は「いつかやらなきゃ」と先送りしてきた組織に対する事実上の強制終了通知だ。認証基盤の刷新を後回しにしてきた日本のIT部門にとって、今月は明確な転換点となる。 パスキープロファイルとグループベース管理の導入 今回の目玉機能のひとつが「パスキープロファイル」だ。これまでEntra IDのパスキー設定はテナント全体で一律に適用されていたが、今後はプロファイル単位で設定を定義し、グループに割り当てる形で管理できるようになる。 具体的には、デバイスの種別やリスクレベル、職種に応じて異なるパスキーポリシーを設定できる。たとえば特権ユーザーグループには厳格なFIDO2キー要件を、一般ユーザーグループにはスマートフォンのパスキーを許可する、といった細粒度の制御が可能になる。大規模組織や多様なデバイス環境を持つ企業にとって、これは運用負荷を大きく下げる改善だ。 全認証手段を失ったユーザーのアカウント復旧 あまり注目されていないが、実務的に重要な機能も追加予定だ。登録済みの認証方法をすべて失ったユーザー（デバイス紛失・故障など）に対する、管理者介在型のアカウント復旧フローが整備される。 これまで「全MFA手段を失ったユーザーの救済」はヘルプデスク業務の中でも工数がかかるケースのひとつだった。専用フローが標準化されることで、対応品質のばらつきを減らせる。 レガシー認証の永久ブロック開始（2026年5月〜） 今回の変更の中で最もインパクトが大きいのは、Basic認証をはじめとするレガシー認証プロトコルの永久ブロックだ。これまでも段階的な非推奨化が進んでいたが、2026年5月をもって完全に遮断される。対象はExchange Online、SharePoint Online、Entra IDに対するレガシープロトコルへの接続全般だ。 移行先はOpenID Connect（OIDC）とOAuth 2.0。モダン認証へ移行できていないアプリケーション、とりわけ古い業務システムや自動化スクリプトが接続を試みている場合、今月から突然エラーになる可能性がある。 実務への影響——日本のIT管理者が確認すべきこと 1. レガシー認証の利用状況を今すぐ確認する Entraの「サインインログ」でクライアントアプリのフィルターを使えば、レガシープロトコルを使っている接続元を特定できる。Entra IDのサインインログ > フィルター「クライアントアプリ」> レガシー認証クライアントで絞り込みが可能だ。気づかずに動いているバッチ処理や監視ツールが意外に多い。 2. パスキープロファイルの設計を先回りしておく 現時点でパスキー展開を検討している組織は、グループ設計と合わせてプロファイル設計を行う絶好のタイミングだ。後から分割するより、最初から役割別に整理した方が運用が楽になる。 3. アカウント復旧フローをヘルプデスクに展開する 復旧機能が正式リリースされたら、マニュアル更新とヘルプデスクへの周知を早めに行いたい。特に人事異動や入退社が集中する時期の直前に整備しておくと効果的だ。 筆者の見解 正直に言えば、セキュリティ系の話題は細かい仕様が多くて得意分野ではない。だが今回のレガシー認証ブロックについては、方向性として完全に正しいと思っている。 ゼロトラストを本当に実現しようとするなら、「誰でもどこからでも接続できてしまう古いプロトコル」を残しておくことは根本矛盾だ。VPNで境界を作って「内側は安全」と思い込む時代はとっくに終わっている。レガシー認証の存在はその典型例で、廃止は遅すぎたくらいだ。 一方で日本の大企業の現場を見ていると、ゼロトラストへの移行を進めながら、古いセキュリティモデルのシステムが隅に残り続けている状況が少なくない。パッチワーク的な移行が積み重なって、全体として非常に複雑な構成になっているケースも多い。今回の強制ブロックが、そういった積み残しに向き合うきっかけになるなら、むしろ歓迎だ。 パスキープロファイルのグループ管理については、Non-Human Identities（NHI）の管理体制を整える流れとも親和性が高い。自動化を推進するには、人間と機械が使う認証をきちんと分けて管理できる基盤が不可欠で、その基盤が少しずつ整備されてきていると感じる。Entraがこの方向で機能を積み重ねてくれていることは、素直に評価したい。 出典: この記事は What’s New in Microsoft Entra: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Outlook Classicを開こうとしたら突然起動しなくなった——そんな問い合わせが増えている場合、原因はMicrosoft 365の現在進行中の障害かもしれない。Teams Meeting Add-in（Teams会議アドイン）を有効にした環境で、特定ビルドのOutlook Classicが起動不能になる問題が確認されている。Exchange Onlineに起因するサービス低下であり、Microsoftは修正展開を試みたものの、予期しない遅延が生じていると発表した。 何が起きているのか 障害の概要は以下の通りだ。 影響範囲: Teams Meeting Add-inが有効な状態かつ古いOutlookビルドを使用しているユーザー 現象: Microsoft Outlook Classic（旧来のデスクトップクライアント）が起動できない 根本原因: 古いOutlookビルドとTeams Meeting Add-inの組み合わせが競合を引き起こしている 障害識別子: EX1254044（Microsoftトラッキング番号） 注目すべきは「Exchange Onlineに起因する」という分類だ。一見するとデスクトップアプリの問題に見えるが、クラウド側のサービスと連携するAdd-inの仕組みが絡んでいるため、ローカルだけで完結しない。Microsoft 365の統合アーキテクチャならではの複雑さが出た格好だ。 今すぐ使える回避策3選 Microsoftが案内している回避策は複数ある。組織の環境に合わせて選択してほしい。 1. Teams Meeting Add-inを一時的に無効化する 最も即効性が高い。アドインを無効にすればOutlook Classicは通常通り起動する。Teamsからのカレンダー招待作成機能が一時的に使えなくなるが、会議招待はTeamsアプリやWebから送ることで代替できる。 2. Outlookをオンライン修復する Windowsの「アプリと機能」からOfficeを選択し、「変更」→「オンライン修復」を実行する。インターネット接続が必要だが、ファイルの破損や不整合を一括修正できる。所要時間は環境によって異なるが20〜40分程度を見込んでおこう。 3. Outlookを最新ビルドに更新する 根本原因が「古いビルド」にあるため、最新版へのアップデートで解消する可能性が高い。Outlook上部メニューの「ファイル」→「Officeアカウント」→「更新オプション」→「今すぐ更新」から実行できる。Monthly Enterprise Channel（MEC）環境では更新タイミングに注意が必要だ。 実務への影響——IT管理者が確認すべきこと エンドユーザーからの問い合わせが来る前に、以下を確認しておきたい。 テナント全体のOutlookビルド状況を把握する Microsoft 365管理センターのHealth → Service healthで障害状況を確認できる。EX1254044を検索すれば詳細と影響スコープが確認できる。 更新チャネルを見直す機会にする MECやSemi-Annual Enterprise Channelを使っている組織では、今回のように修正が遅れるリスクがある。セキュリティパッチの観点からも、Current Channelへの段階的移行を検討する価値がある。 回避策の一括展開を検討する Intune（Microsoft Endpoint Manager）を使っている環境であれば、アドインの有効・無効をポリシーで一括制御できる。個別対応より効率的だ。 新しいOutlook（One Outlook）への移行タイミングを見極める MicrosoftはClassicから「新しいOutlook」への移行を推進している。今回のようにClassic固有の障害が頻発するようであれば、移行の優先度を上げるサインかもしれない。ただし新しいOutlookにもアドイン互換性の制約があるため、現場での検証は必須だ。 筆者の見解 Teams Meeting Add-inとOutlookの組み合わせ問題は、実は今回が初めてではない。この2つのコンポーネントは長年にわたってトラブルが報告されてきた経緯がある。根本的な原因は、Teamsが独自のアドインとして後からOutlookに統合された設計の複雑さにある。 MicrosoftにはOutlookとTeamsを深く統合するための技術力が十分にある。だからこそ「また同じところで」と感じてしまうのが正直なところだ。新しいOutlookではTeams機能がよりネイティブに統合される方向に進んでいるとは聞く。その完成形に期待している。 一方で、エンドユーザーにとっては「突然Outlookが開かなくなった」という体験は、理由がどこにあれ信頼を損ねる出来事だ。修正展開の遅延が重なっているのも気になる点ではある。IT管理者としては、今回の件をきっかけに更新チャネルの見直しや新しいOutlookへの移行計画を具体化するのが建設的な対応だろう。 障害は起きるものだ。大切なのは、組織がそこから素早く立て直せる仕組みを日頃から持っているかどうかだ。 出典: この記事は Microsoft 365 Alert – Exchange Online Service Degradation – Outlook Classic with Teams Meeting Add-in の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は2026年5月1日、SharePoint Online における旧来の認証方式「IDCRL（Identity Client Run Time Library）」を正式に廃止した。セキュリティ近代化の観点からは正しい一手だ。しかし廃止の「後始末」として、統合監査ログ（Unified Audit Log）に大量の謎のイベントが発生している。IT管理者にとっては、セキュリティ強化の恩恵より先に、ノイズとの戦いが始まった格好だ。 IDCRL廃止とは何か IDCRLとは、SharePointが長年使ってきたMicrosoft独自の認証ライブラリで、モダン認証（OAuth/OpenID Connect）が普及する以前の設計に基づく仕組みだ。Microsoftは段階的な廃止スケジュールを経て、2026年5月1日にIDCRLを完全に停止した。 ここまでは良い話だ。 監査ログに何が起きているのか 問題はここからだ。廃止の約6日前、4月25日16:00 UTC頃から、統合監査ログに IDCRLBlockedDueToSoftEnforcement というイベントが爆発的に記録され始めた。 このイベントは「クライアントまたはアプリがIDCRLを使おうとしたが、SharePointにブロックされた」という意味だ。ところが、ブロックされているのは Microsoft Office Word や Microsoft Office Core Storage Infrastructure といったMicrosoft自身のOfficeアプリであり、なんと Microsoft Office Word 2014 というクライアント名まで現れている。 さらに奇妙なのは、イベントのペイロードを詳しく見ると、実際の認証はOAuthで行われているにもかかわらず、IDCRLイベントとして記録されている点だ。OAuthで認証が完結しているなら、IDCRLブロックイベントを出す理由がない。 もう一つの問題は、ユーザーが Unknown User として記録されることだ。これでは監査ログとして本来の役割——誰がいつ何をしたか——を果たせない。他のイベントとの相関分析も困難になる。 Wordを開くだけで最大6件のイベント 調査によれば、Wordでファイルを開くたびに最大6件のIDCRLイベントが記録され、保存のたびにさらに追加される。Office系アプリを日常的に使う組織では、1日に数千件から数万件のノイズイベントが生成される計算になる。 統合監査ログの「問題歴」 統合監査ログは2016年の登場以来、データの消失、イベントペイロードの切り詰め、検索精度の問題と、幾度となく信頼性の問題を抱えてきた歴史がある。Microsoftは高完全性検索（High Completeness Search）や監査向けGraph APIで改善を試みてきたが、いずれも完全な解決には至っていない。 ログの仕組み自体がExchangeの特殊な監査メールボックスをストレージとして使う設計で、2016年当時としては合理的な選択だったが、2026年の今日、データ量・保持期間・検索負荷のすべてが当時の想定を大きく超えている。 日本のIT管理者への実務的影響 今すぐ確認すべきこと 監査ログのノイズ量を確認する: IDCRLBlockedDueToSoftEnforcement で絞り込み検索をかけてイベント件数を把握する。数千件単位で出ているなら要注意 SIEMへの連携設定を見直す: Microsoft Sentinel などにM365監査ログを取り込んでいる場合、このイベントがアラートルールを誤作動させる可能性がある。フィルタリングルールの追加を検討する コンプライアンス担当者への説明を準備する: 監査レポートに大量の Unknown User イベントが出てきた場合、監査人・コンプライアンス担当者からの問い合わせに備えた説明資料を用意しておくとよい 対応の優先度 現時点でMicrosoftから公式の修正情報は出ていない。緊急対応は不要だが、ログ分析やアラートに影響が出ている組織は、上記のフィルタリング対応を早めに実施したい。 筆者の見解 IDCRLの廃止そのものは正しい方向性だ。レガシー認証の排除はゼロトラストへの移行において欠かせないステップであり、むしろもっと早く進めてほしかったくらいだ。 ただ、こうした「廃止の副作用」への対応が粗い点は、率直に言って惜しい。OAuthで正常に認証されているにもかかわらずIDCRLブロックイベントが発生し、しかも Unknown User として記録されるのは、設計レビューで防げた問題のはずだ。 ...

SharePoint上でのフロー管理が、ようやく使いやすくなる。Microsoftは2026年4月〜5月にかけて、SharePointに新しいWorkflows体験をロールアウトすると発表した。Teams向けに先行発表されていた新ワークフローUIと同一の体験をSharePointにも持ち込む形で、M365プラットフォーム全体での自動化統一が進む。 何が変わるのか 新しい「Workflows」ボタンの登場 これまでSharePointのリストやドキュメントライブラリには「Automate」と「Integrate」という2つのメニューが分散して存在していた。新UIではこれらが 「Integrate」 という単一メニューに統合され、さらにコマンドバーに新設された 「Workflows」ボタン から、ワークフローの一覧・新規作成・テンプレート選択がワンストップで操作できるようになる。 テンプレートライブラリと直感的な編集 Workflowsボタンを押すと表示されるのは次の3つだ： テンプレートライブラリ: よく使われる自動化パターンをすぐに選べる 既存ワークフロー一覧: 現在稼働中のフローを一覧管理 スクラッチからの新規作成: ゼロから自由に構築 フローの設定・編集画面もシンプルに再設計されており、Power Automateの複雑さを意識させない構成になっている。 Power Automateがエンジンとして継続 重要なのは、バックエンドは引き続き Power Automate が担うという点だ。エンタープライズグレードの信頼性・セキュリティ・拡張性はそのまま維持される。また既存のワークフローやコンプライアンスプロセスには影響を与えないとMicrosoftは明言しており、移行リスクは低い。 日本のIT現場への影響 日本の多くの企業では、SharePoint上のリスト管理・承認フロー・通知自動化などをPower Automateで構築しているが、UIが複数に分散していたため「どこから作れば良いのかわからない」という声が現場エンドユーザーから頻繁に上がっていた。 新UIでの テンプレートから始められる体験 は、Power Automateの習熟度が低いビジネスユーザーにとって大きな改善となる。 実務での活用ポイント 既存フローは変更不要: 現在稼働中のPower Automateフローはそのまま継続する。移行作業は発生しない テンプレートを積極活用: まずテンプレートから試し、そこからカスタマイズするアプローチを推奨。Power Automateの全機能を理解していなくても始められる Teams連携を意識する: Teams側でも同等のWorkflows体験が提供される。SharePointとTeamsのフローを横断して一元管理する運用が現実的になる 展開タイミングを把握する: 本機能は管理者が制御するロールアウトではなく、Microsoftによる段階的展開だ。テナント管理者はMessage CenterのMC1138798とロードマップID 491632を追跡しておくことを勧める 筆者の見解 正直に言えば、このアップデート自体は地味だ。Power Automateの中身が変わるわけではなく、あくまでSharePointへの入り口をシンプルにするUIの刷新に過ぎない。それでも注目するのは、Microsoft 365全体での一貫した体験の構築という方向性 が、ここにも確実に現れているからだ。 Teams・SharePoint・Outlook——それぞれバラバラだった自動化の導線を、M365という統合プラットフォームの文脈で揃えていく。この積み重ねが、最終的にはプラットフォームとしての全体最適につながる。バラバラに使うと意味がない、統合して使うから価値が出る——それがM365というプラットフォームの本質であり、今回の変更はその方向への小さくも確かな一歩だ。 一方で、このロールアウトスケジュールを見ると思わず苦笑いが浮かぶ。当初2025年10〜11月予定だったものが、5回延期されて2026年4〜5月となった。UIのリデザインでここまで時間がかかるのは、もったいないとしか言いようがない。Microsoftにはこのくらいの規模の変更をもっとすばやく実行に移せる体制を整えてほしい。プラットフォームとしての競争力は、機能の質だけでなく リリースの速度 でも問われる時代だ。M365は本来、それができる力を持っているはずなのだから。 これが前進の一歩であることは間違いない。その歩みが、もう少し力強くなることを期待している。 出典: この記事は SharePoint introduces a new Workflows experience の内容をもとに、筆者の見解を加えて独自に執筆したものです。

スマートフォンからAIに仕事を頼める——そんな体験がいよいよ現実に近づいてきた。MicrosoftはCopilot CoworkのiOS・Android対応を発表し、マルチステップの自律タスクをモバイルから委任できる機能を展開している。デスクトップとのシームレスな引き継ぎ機能も提供される。AIエージェントがどこでも仕事の相棒になる日が、着実に歩み寄っている。 Copilot Coworkとは何か Copilot Coworkは、単発の質問応答に留まらず、複数ステップからなる複雑なタスクをCopilotに「委任」する機能だ。「来週の会議資料をまとめてTeamsに投稿しておいて」といった指示に対して、Copilotがメール確認・ドキュメント作成・投稿まで自律的にこなす——いわゆるAIエージェントとしての動作がCopilotに組み込まれている。 今回の発表の核心は、このCowork体験がiOS・Androidにも届くようになった点だ。移動中にスマートフォンからタスクを委任し、デスクトップに戻ったときにシームレスに引き継いで作業を継続できる。マルチデバイスでのコンテキスト保持は、これまでのAIアシスタントが苦手としてきた領域だけに、実装の完成度が注目される。 スキル・インテグレーションの拡張 スマートフォン対応と並行して、スキルや外部インテグレーションへの接続強化も発表された。Microsoft 365のアプリ群にとどまらず、サードパーティサービスとの連携も設計に含まれている。エコシステムの広がりが実用性を大きく左右するため、今後どのようなスキルが追加されていくかが鍵になる。 技術的な注目点 内部実装として外部のエージェント技術が採用されているという点は、技術者として興味深い。Microsoftが自社開発のみにこだわらず、実用性を優先して外部の技術スタックを組み込む判断をしているのは、「使えるものを使う」という現実的な姿勢の表れだ。こうした実利的な判断が、製品の完成度に直結してくることを期待したい。 実務への影響 日本のエンジニア・IT管理者にとって、注目ポイントを整理する。 スマートフォンからのタスク委任が変えるワークスタイル 「外出中だからAIに任せられない」という状況が変わる可能性がある。承認フローや定型報告を移動中に処理できれば、オフィスへの縛りがさらに薄まる。モバイルワーカーにとっては特に恩恵が大きい機能だ。 デバイス間引き継ぎの実用性 スマホで始めてPCで続けるワークフローが自然になれば、働き方の選択肢が広がる。ただし、このシームレスさが実際の業務でどこまで機能するかは、自社のユースケースで検証しながら判断したい。 権限委任の設計を必ず確認せよ エージェントへの権限委任が広がるほど、誤操作や意図しないアクセスのリスクも高まる。展開前にJust-In-Time的な権限設計やアクティビティログの整備を確認すること。監査ログが残るかどうかも重要な確認項目だ。エージェントに「何でも任せる」ではなく、委任の範囲を明示的に設計する姿勢が必要だ。 筆者の見解 Copilot Coworkのモバイル展開は、方向性として正しい。AIエージェントをデスクトップ専用ツールに留めておく理由はなく、スマートフォンから委任できる体験は多くのビジネスパーソンにとって実用的な価値がある。 正直に言えば、Copilotはここ数年「機能発表の積み重ね」が続いてきた。発表のたびに期待値が上がりながら、日常業務の中で「本当に使えた」という手応えがどこまで積み上がっているか——ユーザーとして気になるところだ。Microsoftには、技術資産もユーザーベースも、他が羨む土台がある。それだけに、発表の勢いを実際の完成度にまで貫いてほしい、ともったいなく感じることがある。 今回注目したいのは、外部技術を実利的に取り込んでいる姿勢だ。自社技術への固執よりも「使える体験を届けること」を優先しているなら、それは正しい判断だと思う。その姿勢が機能の磨き込みにも反映されれば、Copilot Coworkは本物のワークスタイル変革ツールになれるポテンシャルを持っている。 モバイルCoworkが「発表止まり」ではなく、日常のワークフローに溶け込む機能として育っていくことを期待したい。応援しているからこそ、使えるものを作り続けてほしい——それだけだ。 出典: この記事は Copilot Cowork: From conversation to action across skills, integrations, and devices の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilot Chatが、Teamsのチャット・チャンネル・通話・会議のすべてに統合展開される。モバイルアプリはチャットファーストのデザインに刷新され、プロンプトのテキスト書式設定や引用ナビゲーションといった実用的な機能も加わった。さらに管理者向けには、Copilotの利用状況をユーザー単位で4段階に分類するインサイト機能が提供される。機能の量よりも、組織全体への「浸透度」を可視化しようとする今回のアップデートは、企業導入の次のフェーズを見据えたものだ。 Teams全体への展開と体験の一貫性 今回の主な変更点は、Copilot Chatのスコープが大きく広がったことだ。これまでTeamsの特定の場所でしか利用できなかったCopilotが、チャット・チャンネル・通話・会議と、Teamsのほぼすべての場面に対応するようになる。 モバイルアプリの「チャットファースト」デザインへの刷新も注目に値する。現場の営業職や移動中の管理職など、デスクに座らないユーザー層への訴求を意識した変更だ。「あの機能はデスクトップ版にしかない」という状況がなくなれば、組織全体での活用が進みやすくなる。 プロンプトへのテキスト書式設定（太字・リスト等）対応も地味ながら重要だ。複雑な指示を整理しながら入力できるため、Copilotへの指示の質が上がりやすくなる。引用ナビゲーション機能は、Copilotが参照した元のメッセージや会議発言に直接ジャンプできる仕組みで、AIの回答の根拠を追跡できる点でエンタープライズ利用の信頼性向上に直結する。 管理者向け：ユーザー採用インサイトの4段階分類 今回のアップデートで管理者にとって特に価値があるのが、Copilotユーザーの活用状況を「Power / Habitual / Novice / Non-Copilot」の4段階で分類するインサイト機能だ。 Power: Copilotを日常業務の中核に置くヘビーユーザー Habitual: 定期的に利用しているが、活用の幅をさらに広げられる層 Novice: 導入済みだが活用しきれていない初心者層 Non-Copilot: Copilotをほとんど使っていないユーザー この分類が提供されると、IT管理者は「ライセンスを払っているのに使われていない」という状況を定量的に把握できるようになる。Novice層やNon-Copilot層への研修投資やプロンプトガイドの提供など、次の施策に落とし込みやすくなる点が実務上の大きなメリットだ。 その他の注目アップデート Edge for Businessでは、開いているWebページをCopilot Chatで要約するための「コンテキストナッジ」が追加された。長いドキュメントをブラウザで開きながら、サイドパネルに「このページを要約して」と聞くだけで済む。情報収集・調査業務の効率化に直結する機能だ。 Viva Glintでは、従業員サーベイの結果をAIが自動集約し、スコアの変化や業界ベンチマーク比較などのインサイトを生成するようになった。多言語対応も追加され、日本語でのインサイト生成にも対応する見込みで、日本の人事・HR担当者にとっても実用的になりそうだ。 実務への影響 IT管理者向け 採用インサイト機能は、Copilotのライセンス投資対効果（ROI）を経営層に説明する際の根拠データとして活用できる。Non-Copilot層が多い部門を特定し、業務フロー別のプロンプトガイドやハンズオントレーニングを優先的に実施するといった具体的なアクションに繋げやすい。 エンジニア・開発者向け 引用ナビゲーション機能を活用することで、AIが生成した回答の根拠となるメッセージや発言をトレースできるようになる。情報の信頼性検証が求められる業務シーンでの活用が広がりそうだ。 一般ユーザー・業務担当者向け テキスト書式設定機能を使いこなすことで、Copilotへの指示精度が上がる。「以下の3点を踏まえて議事録を整理して」と箇条書きでコンテキストを渡すといった使い方が自然にできるようになり、Teams上での情報整理の起点が一本化される。 筆者の見解 今回のアップデートで個人的に最も評価しているのは「採用インサイトの4段階分類」だ。Copilotの導入支援をしていると、「ライセンスは買ったけど誰も使っていない」という状況に何度も直面してきた。その問題の可視化に踏み込んできたのは、現場感覚に即した判断だと思う。 Teamsへの全面展開も、方向性としては正しい。会議室でも移動中でもチャット中でも、同じCopilotが使えるという体験の一貫性は、ユーザーの学習コストを下げる。 ただ、機能を広げることと、ユーザーが実際に価値を感じることは別の話だ。Microsoftにはこれだけ豊かな製品群とユーザーベースがある。「ライセンスを買ったけど使っていない」という層が依然として多いという現実に正面から向き合い、ひとつひとつの体験をしっかり磨き込んでいくことが、今の最優先課題ではないか。その力は十分にあるのだから、広げた機能をきちんと「使われるもの」に育てていくことに期待したい。 出典: この記事は Microsoft 365 Copilot Chat expands to Teams chats, channels, and meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

金融業界向けのAI自動化が、いよいよ「実験」から「実務導入」の段階へと踏み込んできた。Anthropicが今回発表したのは2つの独立した機能群だ。ひとつはMicrosoft 365の主要アプリケーション（Excel・PowerPoint・Word）で動作するAIアドインの一般公開。もうひとつは、Claude CoworkやManaged AgentsなどAnthropic自身のプラットフォーム上で動く金融サービス特化のエージェントテンプレート10種の提供開始である。M365アドインとエージェント群は動作環境が異なる別プロダクトだが、同じ「金融実務のAI化」というテーマのもとに同時発表された。 何が変わったのか Microsoft 365アドイン（一般提供開始） Excel・PowerPoint・Wordのアドインが正式リリースされた（Outlookは近日対応予定）。 Excelでは、財務申告書やデータフィードからモデルを自動構築し、感度分析の実行や複数ワークブックにまたがる数式の監査が行える。PowerPointでは、元データが更新されると資料が自動追従する。Wordでは、社内テンプレートに沿ったクレジットメモの編集を支援する。 特筆すべきはアプリケーション間のコンテキスト継続だ。Excelで組んだ財務モデルをPowerPointに展開する際、改めて前提条件を説明し直す必要がない。統合プラットフォームとしての利点を最大化する設計思想が見える。 金融特化エージェントテンプレート10種（Claude Cowork / Managed Agents向け） こちらはM365アドインとは別に、Anthropicのプラットフォーム（Claude Cowork・Claude Code・Managed Agents）上で動作する。テンプレートは2グループに分類される。 リサーチ・クライアント対応系：ピッチブック作成、ミーティング準備、決算レビュー、財務モデル構築、市場リサーチ 財務・オペレーション系：バリュエーションレビュー、総勘定元帳照合、月次決算クローズ、財務諸表監査、KYCスクリーニング 各テンプレートは「スキル（指示とドメイン知識）」「コネクター（ガバナンス付きデータアクセス）」「サブエージェント（比較対象選定・手法チェックなど特化処理）」の3層で構成されている。 データエコシステムの充実 既存のFactSet・S&P Capital IQ・MSCI・PitchBook・Morningstarに加え、Moody’s（6億社以上の格付けデータ）、Dun & Bradstreet（企業識別）、SS&C IntraLinks（ディールルーム）、Verisk（保険引受）など新コネクターが追加された。金融実務で日常的に参照するデータソースがほぼ横断的に接続可能になった形だ。 実務への影響——日本の金融エンジニア・IT管理者に向けて M365経由の展開は「調達摩擦」を大幅に下げる M365の既存アドイン配布インフラを利用するため、新規ソフトウェアの社内調達プロセスをほぼバイパスできる。「承認済みのM365環境内に収まっている」という説明がIT部門・コンプライアンス部門に通しやすく、金融機関特有のネットワーク分離ポリシーとの整合性も取りやすい。 監査ログと権限管理がガバナンス要件に対応 Claudeプラットフォーム上でのManaged Agent動作時は、ツールごとのパーミッション設定・資格情報ボールト・全操作の監査ログが確認できる。AML/KYCの証跡確保やSOC監査への対応を意識した構成だ。日本でも金融庁のシステムリスク管理態勢の文脈でAIの操作記録を求める動きが出てきており、この設計思想は参考になる。 「毎日開いているツールの中」に統合される意味 アナリストが毎日使うExcel・Wordの中に直接AIが統合されることで、別アプリへの切り替えコストがなくなる。AI活用の現場定着率に最も効く変数が「ツールの切り替え回数」であることを考えると、この「住んでいる場所に来てもらう」アーキテクチャの選択は理にかなっている。 筆者の見解 今回の発表で最も興味深いのは、M365という土俵の上で競合AIが本格的に動き始めたという事実そのものだ。特にOutlookへの対応が「近日公開」とされた点は注目したい。Outlookのトリアージ・会議調整・下書き生成はM365ユーザーが最も時間を費やす領域であり、ここに外部AIが参入してくることは、Microsoftにとって正念場になる。 Microsoftには統合プラットフォームとしての圧倒的な強みがある。M365のデータグラフ、Teamsとの連携、Entraによるアイデンティティ管理——これらを組み合わせた体験は他が簡単に再現できるものではない。その強みを活かした答えを、ぜひ正面から打ち出してほしい。実力は十分にあるはずだ。 金融業務のAI導入を検討している組織にとっては、今回のM365アドイン経由のルートは即座に評価に値する選択肢だ。既契約のデータプロバイダーとの接続コストが低く、ガバナンス要件への対応が組み込み済みという条件は、日本の金融機関にとっても現実的な出発点になりうる。まずExcelでの財務モデル構築補助から試してみることをお勧めしたい。 出典: この記事は Anthropic ships ten finance AI agents and Microsoft 365 add-ins の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Backupのグラニュラーリストア（ファイル・フォルダ単位の個別復元）が、2026年4月29日にGeneral Availability（正式提供）に到達した。SharePoint OnlineおよびOneDrive for Businessのバックアップから、サイト全体を復元することなく特定のファイルやフォルダだけを取り出せるようになった。5月初旬には世界規模での展開が完了する予定だ。 サイト全体復元からの脱却 Microsoft 365 Backupは2024年7月31日にGAとなった製品だが、発売当初からSharePoint・OneDriveの復元には大きな制約があった。サイト全体またはOneDriveアカウント全体を丸ごと戻すしかなかったのだ。Exchange Onlineのメールボックスでは差出人・件名・日付などでフィルタリングできたのに対し、SharePointとOneDriveには同等の粒度がなかった。 今回のグラニュラーリストアでは、SharePoint Backup Administrator権限を持つ管理者がバックアップのスナップショットを開き、内容をブラウズ・検索して特定のファイルやフォルダだけを選択して復元できるようになった。 知っておくべき技術的詳細 復元ポイントの粒度: 直近14日間は日次、それ以降は週次のスナップショットが利用可能。なお、サイト全体復元は直近14日間について10分RPOが適用されるが、グラニュラーリストアにはこの細かいRPOは適用されない点に注意が必要 必要なロール: SharePoint Backup AdministratorロールはSharePoint Administratorとは別ロールだ。サイト全体復元と同じロールが引き続き管理する 料金: 既存通り、Azure Syntex課金プロファイル経由でUS$0.15/復元可能GB/月の従量課金モデル 保存期間: 引き続き12ヶ月固定 重要な注意点：復元先は「新規場所」 現時点では、復元したファイルはもとの場所に上書きされるのではなく、新しい場所（新規サイト等）に配置される。ユーザーが誤って削除したファイルを元のフォルダに戻したい場合は、復元後に手動でコピー・移動する手間が残る。 In-placeリストア（元の場所への直接復元。競合時はFail・Rename・Replaceのポリシーも選択可）はロードマップのItem 464991として予告済みだが、現時点では未提供だ。 実務への影響 サードパーティバックアップとの比較軸が変わる これまで「M365 BackupはSharePoint/OneDriveがサイト単位でしか戻せない」ことが、Veeam・AvePoint・Draviaなどのサードパーティ製品を継続採用する大きな根拠の一つだった。グラニュラーリストアのGA到達でその差は大きく縮まった。 とはいえ、製品選定の見直しにあたっては以下の観点で引き続き比較することを勧める。 RPO/RTO要件: グラニュラーリストアの復元ポイントは日次スタート。より細かい粒度（数時間単位など）が要件なら、サードパーティ製品が依然有利 In-placeリストア: ロードマップ予告のみでまだ未提供。運用フローへの影響を事前に文書化しておくこと 保存期間ポリシー: 12ヶ月固定が法規制や社内ポリシーと合致するか確認 管理者が今すぐやること SharePoint Backup Administratorロールの棚卸し: 誰がこのロールを持つか、適切な権限分離がされているか確認する 復元手順の更新: 「個別ファイルを戻す際は新規場所経由で手動移動が必要」という前提をRunbookに明記する コスト比較の再実施: 現行のバックアップツールの月額実績とMicrosoft 365 Backupの従量課金の試算を改めて比較し、移行可否を判断する 筆者の見解 率直に言えば「ようやく」という感想だ。グラニュラーリストアはサードパーティ製品が何年も前から当たり前に備えていた機能であり、GA当初から「当然ある」と思っていた管理者も多かったはずだ。18カ月かかったのは、正直もったいないと思う。 ただし、ここからが重要な視点だ。Microsoftはバックアップデータをテナントのリージョン外に一切出さない設計を徹底している。この「データが国境を越えない」安心感は、グローバルデータセンターを活用するサードパーティ製品では担保しにくい部分であり、日本の特定業種では決定的な差になりうる。 In-placeリストアが実装されれば、中小規模テナントの多くにとって「Microsoft 365 Backupだけで十分」という判断が現実味を持ってくる。Microsoftにはその「最後の一手」を速やかに届けてほしい。この分野で正面から勝負できる力は十分に持っているのだから、あとは実行のスピードだ。 出典: この記事は Granular Restore for Microsoft 365 Backup Reaches General Availability の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

グローバルチームとのオンライン会議で、発言者が別の言語に切り替えるたびに手動で言語設定を変更していた——そんな手間が、いよいよ不要になる。Microsoftは2026年5月、Microsoft Teamsの多言語会議（マルチリンガルミーティング）において、話者の言語をリアルタイムで自動検出する機能の展開を開始した。通訳機能（Interpreter）、ライブキャプション、文字起こしが言語の切り替えに自動追従するようになる。 何が変わったか：手動操作から自動検出へ これまでのTeamsの多言語イベントでは、主催者やプレゼンターが「今から英語で話します」「スペイン語に切り替えます」と都度、手動で言語を設定し直す必要があった。複数の言語話者が入り交じるタウンホールやウェビナーでは、この操作が進行の妨げになるケースが少なくなかった。 新機能では、以下のいずれかの条件を満たすと自動言語検出が有効になる： 主催者がマルチリンガル音声認識をイベントオプションで有効化（要：Teams PremiumまたはMicrosoft 365 Copilotライセンス） 参加者がInterpreterエージェントを有効化（要：Microsoft 365 Copilotライセンス） 自動言語検出が有効な場合、手動の言語選択UIは非表示になる。検出された言語に合わせてライブキャプションと文字起こしがリアルタイムで切り替わり、翻訳先の言語は各参加者が言語設定から個別に指定できる。 対応言語とカスタム辞書の強化 マルチリンガル音声認識が対応する言語は現在10言語。英語・スペイン語・ポルトガル語・日本語・簡体字中国語・イタリア語・ドイツ語・フランス語・韓国語に加え、今回新たに繁体字中国語が追加された。 あわせて、InterpreterエージェントがMicrosoft 365管理センターで設定した組織のカスタム辞書を参照するようになった。固有名詞や組織内専門用語の認識精度が向上するこの改善は、カタカナ語や社内用語が多い日本語環境での実用性を大きく高めてくれる。 なお本変更が適用されるのはMultilingual Speech Recognitionが有効な会議のみ。単一言語での会議には一切影響しない。 実務への影響：IT管理者が今すぐ押さえるべき3点 グローバル企業・外資系企業のIT部門にとっては、即座に恩恵を感じられるアップデートだ。日英混在の会議や、日英中3言語が飛び交うアジア太平洋地域のタウンホールなどで、運営コストが大幅に下がる。 1. ライセンス確認が先決 主催者側にTeams PremiumかMicrosoft 365 Copilotライセンスが必要。参加者は主催者が機能を有効化していれば基本的にライセンス不要。まずは既存ライセンスの棚卸しを行い、会議の主催者を担うユーザーに適切なライセンスが付与されているか確認しよう。 2. カスタム辞書は今すぐ整備を Microsoft 365管理センターから設定できる組織のカスタム辞書に、製品名・プロジェクト名・部門名などを登録しておくと文字起こし精度が格段に向上する。日本語固有のカタカナ語や略称に悩んでいた方には特に有効な手段だ。 3. イベント開始前の有効化を運用ルールに マルチリンガル音声認識はイベント開始前に有効化する必要がある。会議の準備チェックリストや社内テンプレートに追加しておくと、うっかり忘れを防げる。 筆者の見解 Teamsの会議・文字起こし周りは、ここ1〜2年で着実に実力をつけてきている。自動言語検出はその中でも「なぜこれがなかったのか」と思えるほど自然な進化で、素直に歓迎したい。 繁体字中国語の追加もタイムリーだ。台湾・香港との連携が多い企業や、アジア拠点を持つグローバル企業にとっては実践的な拡充で、対応言語の着実な広がりを感じる。 カスタム辞書の活用については、もっと積極的に案内してほしいというのが正直なところだ。組織固有のナレッジをシステムに学習させる仕組みとして非常に有効なのに、その存在自体を知らない管理者がまだ多い。TeamsのAI活用を語る前に、まずこの設定から始めることを強くお勧めする。 ライセンス要件についてはやや慎重に評価が必要だ。主催者側にPremiumかCopilotライセンスが必要という設計は、ライセンスを一部のユーザーに絞っている組織では、誰が会議を主催するかという運用設計まで見直す契機になりうる。M365の価値はプラットフォーム全体で最大化されるものだが、その恩恵を受けるための前提条件を段階的に下げていくことも、今後に期待したい部分だ。 多言語コミュニケーションの壁を技術で下げるというこの方向性は間違いなく正しい。実際に使い込んで検証していきたいと思う。 出典: この記事は Automatic spoken language detection in multilingual Teams Meetings, Town halls, and Webinars の内容をもとに、筆者の見解を加えて独自に執筆したものです。

チャットで「確認した」と絵文字リアクションを押した瞬間、JiraにIssueが起票され、GitHub Actionsが走り始める——そんな世界が、コードを一行も書かずに実現できるようになった。Microsoftは2026年3月のTeamsアップデートで「AI-powered Workflows」を大幅に強化し、GitHub・Azure DevOps（ADO）・Jira・Asanaとのネイティブ連携を実現した。 AI-powered Workflowsとは何か AI-powered Workflowsは、Teamsのチャンネルエージェントに組み込まれた自動化機能だ。従来のPower Automateフローとは異なり、チャットのメッセージ内容や絵文字リアクションをトリガーとして使えるのが最大の特徴。たとえば以下のような自動化がノーコードで設定できる。 チャンネルに「デプロイOK 🚀」と投稿 → Azure DevOpsのパイプラインが起動 メッセージに「👍」リアクション → Jiraのバックログに自動起票 特定キーワードを含む発言 → GitHubにIssueを作成 Asanaタスクの完了通知をTeamsチャンネルに流す 連携先として現時点でサポートされているのは、Azure DevOps・GitHub・GitHub Copilot（Copilot Workspace含む）・Jira・Asanaの各サービス。エンジニア向けの主要ツールが一通り揃った形だ。 なぜこれが重要か 日本の開発現場では「コミュニケーションツールと作業ツールが分離している」という問題が長年解消されていない。Teamsで議論して、別ウィンドウでJiraを開いて、またTeamsに戻る——この文脈スイッチの積み重ねが生産性を確実に削っている。 AI-powered Workflowsが刺さるのは、まさにこの断絶だ。チャットでの意思決定がそのまま作業ツールに反映されることで「言った・言わない」問題も減り、作業のトレーサビリティも向上する。 また「コーディング不要」という点は見逃せない。Power Automateをフル活用できるのはある程度習熟した人間に限られていたが、AI-powered WorkflowsはチャンネルエージェントのUI上で自然言語的に設定できる。ITリテラシーの高くないチームメンバーでも自動化の恩恵を受けられる設計だ。 実務での活用ポイント 開発チームでの活用 まず試してほしいのは、障害報告チャンネルへの適用だ。「P1」「緊急」「本番障害」などのキーワードをトリガーとして、自動的にADOやJiraにバグチケットを作成し、担当チームに通知を飛ばす。初動対応の数分間を機械に任せるだけで、エスカレーションフローが劇的にスムーズになる。 次に、プルリクエストのレビュー依頼フロー自動化。「レビューお願いします」という投稿に特定の絵文字を反応させてGitHubのレビュアー割り当てを自動化するといった使い方は、Teamsをコミュニケーションの中心に据えているチームへの即効性が高い。 IT管理者向けの注意点 Teamsチャンネルエージェントの権限設定には注意が必要だ。AIワークフローが外部サービスのAPIを呼び出す際の認証情報管理と、誰がワークフローを作成・編集できるかのガバナンスを事前に整備しておかないと、意図しない操作が走るリスクがある。Microsoft 365管理センターからのポリシー設定を確認してから展開することを強くおすすめする。 筆者の見解 TeamsのAI機能については評価が分かれるものも多い中で、今回のAI-powered Workflowsは方向性として素直に評価したい。 MicrosoftがTeamsで本当にやるべきことは「AIが賢い」を証明することではなく、「Teamsを起点にして仕事が回る仕組みをつくること」だと私は思っている。その意味で、チャットと作業ツールをノーコードでつなぐこの機能は、統合プラットフォームとしてのMicrosoft 365が本来目指すべき姿に一歩近づいている。 日本の現場でよく耳にするのは、ツールは増えるが統合されないという疲弊感だ。GitHub・Jira・ADOを使いながらTeamsでコミュニケーションするチームは多い。それらが分離したままなのは、Microsoft 365が持つ統合プラットフォームとしてのポテンシャルをみずから活かしきれていない状態だった。 今後の課題は精度と信頼性だ。絵文字トリガーのような曖昧な入力をどこまで正確に処理できるか、実運用での誤発火をどう防ぐかは実際に使ってみないとわからない部分が残る。それでも「コミュニケーションが作業になる」世界を実現するプラットフォームとして、Microsoftにはこの路線をぜひ磨き続けてほしい。正面から勝負できる力はあるのだから、統合の深さでこそ差別化してほしいと心から思う。 出典: この記事は Microsoft Teams: AI-powered Workflows trigger GitHub, Jira, ADO from chat の内容をもとに、筆者の見解を加えて独自に執筆したものです。