M365

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

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

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

Microsoft 365 Copilotのモバイルアプリが大きく生まれ変わった。UIをチャットファーストに一新し、「Liquid Glass」スタイリングを採用。プロンプトへのテキスト書式対応、引用付き回答レイアウトの改善、音声会話時の新ビジュアライゼーションなど、見た目だけでなく使い勝手にも手が入った。 チャットファーストUIとはどういうことか 従来のM365 Copilotモバイルアプリは、アプリ一覧やショートカットが前面に出た構成だった。今回のリデザインでは、画面を開いた瞬間にチャット入力欄が主役に来る「チャットファースト」レイアウトに切り替わった。AIアシスタントとして「まず話しかけることが自然な行動」という設計思想の反映だ。 スマートフォンでAIと対話するシーンを考えると、この方向性は合理的だ。移動中や隙間時間にCopilotへ質問したいとき、ホーム画面を探し回るより、すぐにプロンプトを打てる状態になっている方が価値が高い。 Liquid Glassスタイリングとは 「Liquid Glass」は、透明感・光の屈折・流体的な動きを組み合わせたビジュアルスタイルで、Appleが2025年のWWDCで発表したiOS 26のデザイン言語として注目を浴びた。Microsoftがこのスタイリングを採用したことは、モバイルOSのデザイン言語と調和することでネイティブ感と親しみやすさを獲得しようとする意図の表れだろう。企業向けアプリにありがちな「業務ツールっぽい重さ」を取り除き、日常的に手が伸びるアプリへと脱皮しようとしている。 プロンプト書式対応と引用レイアウト改善 プロンプト入力でテキスト書式（太字・箇条書き等）が使えるようになり、長い指示や複雑な条件を整理してCopilotに渡しやすくなった。地味に見えるが、複雑な業務指示をモバイルから出す場面では大きな差になる。 引用付き回答のレイアウト改善も重要だ。Copilotが回答の根拠としてドキュメントやWebソースを示す際、どのソースのどの部分から来たのかが視覚的に把握しやすくなれば、AIの回答を鵜呑みにせず検証しながら使う「適切なAI活用」が促進される。 音声会話時のビジュアライゼーションも刷新され、「話しかけている・応答中・待機中」といった状態がひと目でわかる表現になった。音声でCopilotを使う場面、たとえば車の移動中や手がふさがっている状況での利便性が上がる。 実務への影響──日本のエンジニア・IT管理者にとっての意味 隙間時間のCopilot活用シーンが広がる 日本の職場では、Teams会議の議事録確認やメールの要約確認をスマートフォンで行うケースが増えている。チャットファーストUIとモバイル最適化が進めば、「PCを開くほどではないが確認したい」という隙間時間での利用が自然になる。往復の移動時間や休憩時間にサッと確認して判断を下すといったスタイルとの相性が良い。 M365 Copilotライセンスのコスト回収効率を上げる M365 Copilotライセンスを導入済みの組織なら、追加コストなしにこのモバイルアプリ改善の恩恵を受けられる。会議前の資料チェック、メール下書きの確認、Teams投稿の要約といった定型的な確認作業をモバイルでもスムーズに処理できれば、ライセンスコストの回収効率が上がる。組織全体での活用促進策として、モバイルアプリの配布と案内を組み合わせることも一手だ。 ライセンス条件の確認を忘れずに 今回の機能群はCopilot ProおよびMicrosoft 365 Copilotライセンス保有者向けだ。無料のCopilotには適用されない。導入済みライセンスの範囲を事前に確認した上で展開計画を立てたい。 筆者の見解 UIの刷新そのものは好意的に評価したい。チャットファーストへの転換はモバイルというフォームファクターに対する正直な向き合い方だし、洗練されたビジュアルの採用も「どこでも日常的に使いたいアプリ」へのポジショニングを意識したものだと読める。方向性は正しい。 ただ、デザインの刷新は出発点であって、ゴールではない。モバイルアプリが美しくなっても、AIアシスタントとしてのコア体験──回答精度・文脈理解・長い会話での一貫性──が伴わなければ、ユーザーの評価は「見た目は良くなったが…」で止まる。 MicrosoftはAI統合プラットフォームとして、本来なら誰よりも有利なポジションにいる。仕事で使うメール・会議・ドキュメント・スプレッドシート・チャット、そのすべてのデータにアクセスできる企業内AIはMicrosoftにしか作れない。このポテンシャルをフルに引き出す力があるのだから、フロントエンドの改善と並行してコアのAI性能も着実に引き上げてほしい。今回のリデザインがユーザー体験全体の底上げへの入り口となることを期待している。 出典: この記事は Microsoft 365 Copilot mobile app redesign – chat-first UI with liquid glass styling の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがOneDriveの2026年ロードマップを公開した。Copilot AIとの深い統合、ネイティブMarkdownサポート、そして共有・アクセシビリティ・デスクトップワークフローの全面刷新が予告されている。単なるクラウドストレージという位置付けを超え、「AI駆動のナレッジハブ」へと脱皮しようとするMicrosoftの明確な意図が見える。 Copilot AIによるドキュメント理解の深化 今回のロードマップで最も注目されるのが、OneDrive内でのCopilot AI活用の拡充だ。主に3つの機能が計画されている。 ドキュメント要約は、Word・PowerPoint・PDFといったファイルを開かずにプレビュー画面から直接Copilotが要約を生成する機能だ。受信ファイルの重要度を素早く判断し、本当に読む必要があるものだけに集中できるようになる。日本の職場でよく見られる「とりあえず全部開いて確認する」フローを、根本から変える可能性を持つ。 PDF比較機能は、2つのPDF文書の差分をAIが自動抽出・解説するものだ。契約書・仕様書・RFPのバージョン管理は多くの現場で「人力での読み合わせ」に頼ってきた鬼門だが、この機能が精度高く実装されれば、法務・調達・品質管理部門での業務効率は一気に上がる。 ファイル内検索の強化では、従来のキーワードマッチを超えたセマンティック検索（意味的検索）がOneDriveネイティブで実現される。「先月の予算に関するスプレッドシート」「北米市場の競合分析レポート」のような自然言語クエリでファイルを探せるようになる。ファイル名依存の検索から脱却できることで、命名規則が統一されていない現場でも活用しやすくなる。 ネイティブMarkdownサポート——開発者・テクニカルライターへの朗報 静かに見えて実は大きなアップデートが、ネイティブMarkdownサポートだ。 .mdファイルをOneDrive上で直接プレビュー・編集できるようになる。これまでMarkdownを活用するエンジニアやテクニカルライターにとって、OneDriveはあくまで「ファイル置き場」にすぎなかった。今後はMarkdownコンテンツのライブ編集・共有・コメントがOneDriveのエコシステム内で完結する。 ADR（アーキテクチャ決定記録）や技術ドキュメントをMarkdownで管理しているチームは、SharePoint + OneDriveを文書ハブとして再評価するタイミングになるかもしれない。 共有・アクセシビリティ・デスクトップワークフローの刷新 ロードマップにはUXレベルの改善も含まれている。共有フローの再設計では、アクセス許可設定がより直感的になり、組織外共有の誤操作リスク軽減も期待される。アクセシビリティ強化ではスクリーンリーダー対応やキーボードナビゲーションの改善が図られる。デスクトップワークフローについては、同期パフォーマンスの向上とPower Automateとの連携深化が示唆されており、日常の自動化フローとOneDriveをより密に結びつけられるようになりそうだ。 実務への影響 「まず要約して判断する」が新しいデフォルトに 日本のビジネス現場では、受信ファイルを逐一開いて確認する作業が今でも根強く残っている。OneDriveでのAI要約が実用レベルに達すれば、「ファイルを開かずに重要度を判断し、必要なものだけ精読する」というフローが組織の標準になっていく。承認フローの迅速化、レビューサイクルの短縮——地味に見えて、積み重なると大きな時間節約になる。 Markdownチームはストレージ選定を見直す価値あり 技術ドキュメントをMarkdownで管理しているチームにとって、今回の対応はOneDriveの選択肢としての優先度を引き上げる。特にM365ライセンスをすでに保有している組織であれば、追加コストなしでMarkdownドキュメント基盤を整備できる。 PDF比較は法務・調達現場のボトルネックを直撃 契約書改版のチェックや仕様変更の追跡は、精度が求められるうえに現状は人的コストが高い作業だ。AIによる差分抽出の精度次第では、この領域の業務負荷を大幅に圧縮できる可能性がある。 筆者の見解 今回のOneDriveロードマップ、素直に「いい方向を向いている」と評価したい。特にPDF比較とMarkdownサポートは、ずっと「あったらよかったのに」と思っていた機能が、ようやく具体的なロードマップとして形になったものだ。 Copilot周りについては、正直「まだ見届けたい」というスタンスだ。要約や検索の質が実際どこまで実用に耐えるかは、使ってみなければ分からない。期待しながら、しかし盲目的には信じない——これが今の立ち位置。 MicrosoftがOneDriveを単体プロダクトとしてではなく、Teams・SharePoint・Power Automateと統合したエコシステムの核として再定義しようとしていることは、今回のロードマップからも読み取れる。「OneDriveをナレッジ基盤として整備した上でAIを乗せる」というアーキテクチャ的な発想で取り組む組織が、2026年以降の恩恵を最大化できるはずだ。Copilotへの期待と現実のギャップを個別機能で埋めながら、プラットフォームとして全体最適を追求していく——Microsoftが本来得意とするその戦略が、OneDriveを通じて改めて機能し始めるかどうか、注目して見ていきたい。 出典: この記事は Microsoft details 2026 OneDrive upgrades with Copilot AI tools の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SharePointといえば、長年「ファイル置き場」「イントラネット」として定着してきたプラットフォームだ。しかし2026年春のアップデートで、その立ち位置が大きく変わろうとしている。SharePoint OnlineにカスタムAIスキル機能が追加され、Markdownファイルで構造化されたAIタスクをAgent Assetsライブラリに保存・再利用できる仕組みが整った。 カスタムAIスキルとAgent Assetsの概要 Agent AssetsはSharePoint Online上に設置された「AIエージェントの資産ライブラリ」だ。ここにMarkdownファイルとして保存されたスキル定義をCopilotエージェントが参照し、定型業務や繰り返し作業を自動化できる。 注目すべきは記述言語としてMarkdownを採用した点だ。JSONやYAMLのような厳密な構文を必要とせず、自然言語に近い表現でAIの振る舞いを定義できる。プログラミング経験の薄い業務担当者でも参加できるローコードアプローチと一致しており、現場活用の敷居が下がった点は素直に評価したい。 同時期のMicrosoft 365大型アップデート群 このタイミングは偶然ではない。Microsoft 365は2026年春、複数のアップデートが重なっている。 GPT-5.4 Thinking / GPT-5.3 Instantの一般提供開始：複雑なマルチステップ推論と高速レスポンスを使い分けられる Copilot Cowork：長期・多段階タスクを自律実行する新エクスペリエンス Researcherのマルチモデル対応：「Critique」で別モデルに回答を批評させ、「Council」で複数モデルの回答を並べて比較できる Microsoft 365 E7（ME7）Frontier Suite：E5・Copilot・Agent 365を統合した新ライセンス体系 カスタムAIスキルはこれらと連動して機能する設計だ。Markdownで定義したスキルをCoworkエージェントが実行し、その結果をResearcherで検証する——「AIを組み合わせた仕事の流れ」の基盤として位置づけられている。 実務への影響 IT管理者・情報システム部門の視点 従来、SharePoint上の業務自動化はPower AutomateやSPFx（SharePoint Framework）開発が主流だった。カスタムAIスキルにより、Markdownを書ける業務担当者が直接AIの振る舞いを定義できるようになる。 ただし、これはガバナンス面でのリスクでもある。「誰でも書ける」は「誰でもAI定義を量産できる」と同義だ。Agent Assetsライブラリの管理ポリシーとアクセス権設計を早めに整備することを強く勧める。特に機密情報を扱うサイトコレクションでのスキル定義は慎重に扱う必要がある。 エンジニアの視点 カスタムAIスキルのMarkdownファイルは、事実上プロンプトエンジニアリングをコンテンツとして管理できる仕組みだ。GitリポジトリとSharePoint間の同期パイプラインを設計すれば、AIスキルのバージョン管理・テスト・デプロイを体系化できる可能性がある。「AIの設定はUIでポチポチ」から脱却し、コード資産として管理するアプローチへの布石として捉えたい。 日本企業特有の文脈 日本では「AI活用の業務自動化」の議論がなかなか現場に降りてこない実態がある。カスタムAIスキルは既存のSharePointサイトに追加できる機能なので、新規システム導入の稟議なしにPoC（概念実証）を始められるケースが多い。小さな成功実績を積み上げてから正式展開する——という日本式の進め方と相性が良く、入口としての導入ハードルは比較的低い。 筆者の見解 SharePoint Custom AI Skillsは、地味に見えて本質的なアップデートだと思っている。 ファイル共有とドキュメント管理に特化してきたSharePointが、「AIスキルの配信基盤」へと役割を拡張する。これはMicrosoftが長年かけて磨いてきたコンテンツ管理基盤の強みを、AI時代に接続しようとする試みだ。この方向性自体は正しく評価している。 ただ、Copilot周りの機能はここ1〜2年で急速に拡張されてきた。機能が充実すること自体は歓迎だが、「Copilot Studioとカスタムスキルはどう違うのか」「Power Automateのフローとどう使い分けるか」という問いに現場はすぐ直面するはずだ。機能を増やすことと同じくらい、「この業務にはこのルート」というシンプルで明快なガイドラインを示してほしい。 Microsoftが持つM365というエコシステムの統合力は本物で、全体最適を実現できるポジションに誰よりも近い存在だ。それだけに、ユーザーを選択肢の迷路に迷い込ませるのはもったいない。整理された一本道を示してくれれば、現場の行動速度は劇的に変わる。カスタムAIスキルがM365自動化の「標準ルート」として定着することを、期待を込めて見守っていきたい。 出典: この記事は SharePoint Online introduces Custom AI Skills with Markdown-based Agent Assets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotに「GPT-5.4 Thinking」と「GPT-5.3 Instant」の2モデルが正式に追加された。これまで「1つのCopilot」として扱われていたモデルが、用途別に最適化されたバリアントへと分化しつつある。M365の統合プラットフォームとしての価値を生かせるか——この問いへの一つの答えが、ようやく出始めた。 2つのモデルが担う役割の違い GPT-5.4 Thinking は、複雑な多段階タスクに特化したモデルだ。財務分析・法的文書のレビュー・複数ステップを経るワークフローの設計など、「一回聞いてもすぐ答えが出ない」類の仕事を正面から受け止める。従来のCopilotが苦手としていた「やり取りを何往復も繰り返さないといけない」問題——これが実務ユーザーの最大の不満だった——への本質的な回答が期待されている。 GPT-5.3 Instant は逆の方向性だ。高速かつ高精度を両立させ、メール返信の下書き・議事録の要約・定型的なドキュメント整形といった「毎日何十回と繰り返す」業務を一気に片付けるために設計されている。Outlookの改善も同じ文脈にある——今読んでいるメールにCopilotが文脈を正しく紐付けることで、的外れな返答が減る。 どちらのモデルもCopilot Studioで利用可能になる点も重要だ。カスタムエージェントを構築している企業は、実装コストを変えずに性能の底上げを受けられる。 2026年のCopilot全体像：チャットからオペレーティングレイヤーへ 今回のモデル追加は単体機能強化にとどまらない。2026年のCopilot更新を俯瞰すると、次の大きな方向性が見えてくる。 エージェントモードの拡張: Word・Excel・PowerPointでCopilotが「下書き生成」から「ガイド付き編集」へ踏み込む。ユーザーが指示を出しながら文書を共同編集する形に近づく Copilot Notebookグラウンディング: 参照資料や作業中のメモに沿ってエージェントが動くため、的外れな提案が減る Purviewとの統合強化: 過剰共有（Oversharing）リスクの検出とDLP（データ損失防止）ポリシーがCopilotの出力と連動する Copilotダッシュボード: 部門・アプリ単位での採用状況を数値で可視化し、ライセンスコストの費用対効果を追えるようになる これらを合わせると、Copilotが「チャット補助ツール」から「Microsoft 365全体を動かすオペレーティングレイヤー」へ変わろうとしていることがわかる。 実務への影響——M365管理者が今すぐ確認すべきこと 1. モデルの切り替え挙動を把握する どちらのモデルがいつ適用されるのかを確認する。特にCopilot Studio経由でエージェントを構築している場合、既存のプロンプト設計に影響が出る可能性がある。本番環境への展開前に、主要フローの再テストを強く推奨する。 2. Purviewのガバナンス設定を先に整備する モデルが賢くなっても、組織内の過剰共有リスクは変わらない。DLPポリシーとCopilotの連携を今のうちに見直しておくことで、高性能モデルが「余計な情報を流暢に引き出す」事態を防げる。 3. ダッシュボードで採用状況を数値化する 「なんとなく使っている」状態から脱するには、誰がどの機能をどれだけ使っているかを可視化するのが第一歩。Copilotダッシュボードを活用して、部門ごとの導入効果を経営層に示せる形にしておく。 4. 外部AIとの「併用」アーキテクチャを検討する Teamsの議事録やOutlookの定型業務はCopilotに任せながら、高度な分析・創造タスクにはAzure AI Foundry経由の外部モデルを組み合わせる構成が、現時点では多くの企業に合った現実解だ。Copilotを閉じた世界に縛るのではなく、M365の統合力を入口にしながら最前線のモデルを柔軟に活用する——この「全体最適」の視点が2026年のM365 AI活用の本筋になる。 筆者の見解 この数年、CopilotはMicrosoftが持つ最大の資産——OfficeアプリケーションとのOSレベルの統合、長年積み上げたエンタープライズ信頼性——を活かしきれていないと感じてきた。「何往復もしないと使えない」という実務ユーザーの声に、もっと早く応えられるポテンシャルがあったはずで、もったいないと思い続けてきた。 だからこそ、今回の「用途別モデル分化」という方向性には素直に期待している。複雑な推論は考えてから答える、日常業務は速くさばく——この当たり前のことがモデルレベルで実装されれば、Copilotへの評価は変わりうる。 ただし、現時点では「モデルが変わった」という発表にとどまる。実際にどう変わったかは、使い込んで初めてわかる。Microsoftにはブランドもユーザーベースも技術力も、間違いなく揃っている。正面から勝負できる力がある組織だ。エンタープライズAI競争のど真ん中で、その力を存分に発揮する姿を見たいと、MVP歴のある立場から率直に期待を伝えたい。この批評が「古い話」になる日を、心から待っている。 出典: この記事は GPT-5.4 Thinking and GPT-5.3 Instant now generally available in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Purviewのデータセキュリティ調査（Data Security Investigations、以下DSI）に、2026年5月中旬から「カスタム検査フォーカスエリア」機能が追加される。AIが調査対象データをどう優先分析するかを管理者が明示的に制御できるようにする機能で、コンプライアンス部門の作業効率と調査精度の両面に直接影響する変更として注目したい。 カスタムフォーカスエリアとは何か 従来のDSIでは、テナント全体のデータに対してAIが一律に深度コンテンツ分析（Deep Content Analysis）を実行していた。マイナンバー、クレジットカード番号、医療記録など、機密情報の種類を問わず同じ優先度で処理されていた。 今回追加されるカスタム検査フォーカスエリアにより、管理者は「今回の調査ではこの種類の情報を優先的に調べてほしい」と指定できるようになる。内部調査であれば「給与・人事情報」を、顧客情報漏洩の疑いがあれば「個人識別情報と金融情報」を優先させる、といった使い方が典型例になるだろう。 ロールアウトスケジュールは以下の通り： パブリックプレビュー: 2026年5月中旬〜6月中旬 一般提供（全世界）: 2026年6月中旬〜6月末 既存のPurviewのパーミッションおよびポリシーはそのまま適用される。管理者が明示的にカスタムフォーカスを設定した調査以外、既存のユーザーワークフローへの影響はない。 日本企業における具体的な活用シナリオ 日本のエンタープライズ環境では、業界ごとに固有の機密情報カテゴリが存在する。金融機関なら顧客の口座情報や取引履歴、医療機関なら診療記録や処方データ、製造業なら設計図や原価情報がそれに相当する。これまでDSIは業界固有の文脈に合わせた調整が難しく、調査担当者から「ノイズが多い」という声が上がりやすかった。 カスタムフォーカスの登場により、「自社にとっての最重要機密」にAIの解析リソースを集中させることができる。本当に重要なリスク信号が浮かび上がりやすくなり、インシデント対応の初動スピードにも効いてくるはずだ。 今から準備しておくべきこと Microsoft自身は「事前の対応は不要」としているが、実務観点では以下の準備を推奨する。 組織の機密情報分類を棚卸しする — カスタムフォーカスを効果的に使うには、組織としてどの情報が最も重要かを事前に整理しておく必要がある。情報保護ポリシーの見直しと合わせて進めると効率が良い 調査プレイブックにフォーカス設定の手順を追記する — セキュリティインシデント対応手順に「DSI実行時のカスタムフォーカス選択基準」を組み込んでおく。担当者が変わっても一貫した調査品質を維持できる コンプライアンスチームへの周知 — IT管理者だけでなく、法務・コンプライアンス担当者にも機能の存在と活用方法を案内しておく。調査の設計段階から関与してもらうことで、フォーカス設定の精度が上がる 筆者の見解 データセキュリティ調査においてAIが「何を重視して調べるか」を管理者が指定できるようになる。地味に聞こえるかもしれないが、実際のインシデント対応現場では大きな変化だ。 これまでのAI分析は「AI任せ」の側面が強く、調査担当者からすると「なぜこれが優先されてこっちが後回しなのか」という不満が出やすかった。カスタムフォーカスエリアはその齟齬を埋める機能として、方向性は正しいと思う。 ただ、本当に意味のある機能になるかどうかは、フォーカスエリアの設定粒度と、AIが実際にどう優先度を変えるかの透明性にかかっている。「設定できる」と「効果が出る」の間には距離があることを、過去の経験から痛感している。パブリックプレビューの段階で実際の調査シナリオで試し、体感としての効果を早めに検証しておきたい。 セキュリティとコンプライアンスの領域こそ、PurviewがMicrosoft 365の中で真価を発揮できる場所だ。AI分析の精度向上と管理者コントロールの両立というこの方向性はぜひ継続的に発展させてほしい。Microsoftが本気でコンプライアンスプラットフォームとして磨いていくのであれば、こういう地道な機能強化こそが長期的な競争力になると信じている。 出典: この記事は Microsoft Purview Data Security Investigations: Introducing new custom examination focus areas の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが業務システムに次々と組み込まれる今、「誰がどのエージェントを動かしているのか」を正確に把握できている組織はどれほどあるだろうか。Microsoftは2026年5月のAgent 365アップデートで、この問題に正面から取り組んだ。全テナントへのダッシュボード展開と、AWS・Google Cloud上のエージェントまで対象に含むマルチクラウド自動検出機能のパブリックプレビュー開始は、AI時代のガバナンス基盤として注目に値する内容だ。 Agent 365ダッシュボードが全テナントへ 今回の大きなアップデートの一つは、Agent 365ダッシュボードの全テナントへの展開だ。これまで限定公開だった管理画面が、ついてすべてのMicrosoft 365テナントで利用可能になる。 ダッシュボードでリアルタイムに確認できる情報は以下の3点だ。 登録済みエージェント数: 組織内で稼働するAIエージェントの全体像 アクティブユーザー数: 実際にエージェントを利用しているユーザーの動向 リスクシグナル: 不審な動作や権限の逸脱など、セキュリティ上の懸念点 この可視化は単なる「管理ツールの追加」ではない。AIエージェントがNon-Human Identity（NHI）として組織内のシステムにアクセスし、タスクを自動実行する時代において、その活動状況を把握することはゼロトラストセキュリティの根幹に関わる問題だ。 マルチクラウドエージェントの自動検出——AWS BedrockとGoogle Cloudも対象に 今回のアップデートでとりわけ注目したいのが、レジストリ同期機能のパブリックプレビューだ。 これはMicrosoft 365テナントの外側、すなわちAWS BedrockやGoogle Cloud上で動作するAIエージェントを自動的に検出し、Microsoft側のインベントリに取り込む機能だ。エンタープライズ環境では、複数のクラウドプラットフォームにまたがってAIエージェントが乱立するケースが増えている。これを一箇所から管理できるようになる意味は大きい。 ライフサイクルガバナンスの観点でも重要だ。エージェントの作成・変更・廃止といった一連のライフサイクルを、自組織内外を問わずMicrosoftのガバナンス基盤で追跡できるようになる。これにより、「どのエージェントが、いつ、誰の権限で動き続けているか」を一元的に管理する体制が整う。 実務への影響 IT管理者にとって 日本の多くのエンタープライズ企業では、AI活用の主導権が各部門に分散しつつある。情報システム部門が把握していないところで、営業や企画部門が独自にAIエージェントを構築・運用しているケースは珍しくない。Agent 365のダッシュボードと自動検出機能は、こうした「シャドーAI」を可視化する第一歩として機能する。 ゼロトラストアーキテクチャを推進する立場から言えば、NHI（人間ではなくシステムやエージェントのアカウント）の管理はこれまで見落とされがちなリスク領域だった。Agent 365がこの領域に正式に踏み込んできたことは、セキュリティ担当者にとっても前向きに受け取れる動きだ。 エンジニアにとって AWS BedrockやGoogle Cloud上でエージェントを開発しているエンジニアも、今後はMicrosoftの管理基盤に接続される可能性を意識した設計が求められる。特にM365環境と連携する業務システムを構築している場合、Agent 365のレジストリ同期が組織のガバナンスポリシーに影響を与えうる点を頭に入れておきたい。 パブリックプレビューの段階から実際に触れておくことで、正式リリース時のポリシー策定や移行計画をスムーズに進められる。今のうちに自組織のエージェントインベントリを棚卸しし、どこに何が動いているかを整理しておくことを勧めたい。 筆者の見解 AIエージェントの乱立は、かつてのSaaSスプロール問題と構造がよく似ている。部門単位で便利なエージェントが増えることそれ自体は悪いことではないが、統制されないまま進むと、最終的にはコスト・セキュリティ・コンプライアンスの三重苦に陥る。Agent 365が目指しているのは、まさにこの問題に対するプラットフォームレベルの答えだ。 NHIの管理を業務効率化の文脈で考えると、エージェントが自律的に動くためには「信頼できるアイデンティティ管理基盤」が不可欠だ。今回のアップデートはその方向に確実に進んでいる。こういった地道な基盤整備こそが、長期的なAI活用の土台になる。 マルチクラウド対応については、Microsoftが自社エコシステムの外側まで視野を広げてきたことを素直に評価したい。M365を使っている組織が必ずしもAzureだけで完結していない現実を受け入れた上での機能設計は、実態に即している。 課題があるとすれば、このガバナンス基盤を実際に機能させるには、組織内での合意形成と運用プロセスの整備が伴わなければならない点だ。ツールの展開だけが先行して、運用文化が追いつかないという状況は避けたい。AIエージェント管理のガバナンス設計を真剣に考えるなら、今がその着手のタイミングだ。 出典: この記事は What’s New in Agent 365: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Teams会議の議事録やチャット、共有ファイルをCopilot Notebooksのコンテキストとして直接取り込める機能が、2026年5月からロールアウトを開始した。「あの会議で何を決めたか」をAIに把握させた上でドキュメントや提案書を生成できるようになり、会議後の情報整理という長年の非効率が、仕組みとして解消される可能性がある。 何が変わるのか Copilot Notebooksは、ドキュメント・メモ・Webページなどを「知識ソース」として登録し、それをもとにCopilotが回答や文書を生成するワークスペースだ。今回の機能追加により、Teamsの会議トランスクリプト（文字起こし）・チャット履歴・会議中に共有されたファイルもその知識ソースに加えられるようになった。 たとえば、月次定例会議のトランスクリプトをNotebookに参照登録しておけば、「先月の会議で合意した要件をもとにプロジェクト計画を作成して」というプロンプトが自然に機能する。これまでは議事録をテキストファイルに貼り直したり、要点を手動でまとめ直してから添付するといった下準備が必要だった。Teams上で完結した会議コンテキストをそのままAIの「文脈」として活用できる点が、本質的な変化だ。 ロールアウトスケジュールと対象 フェーズ 期間 パブリックプレビュー（全世界） 2026年4月下旬〜5月中旬 一般提供（GA・全世界） 2026年5月中旬〜5月末 利用には Microsoft 365 Copilot（Premium）ライセンスが必要。機能はCopilot Notebooksが利用できるユーザーに対してデフォルトで有効になる。管理者側での追加設定は不要だが、Teamsのトランスクリプション・録画ポリシーおよび会議アクセス権限が適切に構成されていることが前提となる。 アクセス制御・ガバナンスの取り扱い 情報管理の観点で重要な点として、この機能は既存のアクセス権限設定を尊重する設計になっている。ユーザーが参照権限を持つ会議コンテンツのみがNotebookに取り込まれるため、「参加していない会議の議事録が自分のNotebookに流れ込む」ようなことは起きない。 Teams会議のリテンションポリシーや組織のデータガバナンス設定もそのまま反映される。AIがアクセス権を無視して情報をまとめてしまうという懸念に対して、Microsoft 365プラットフォームとしての整合性を維持しようとしている姿勢は評価できる。 実務への影響 IT管理者がいま確認すべきこと 1. Teamsのトランスクリプションポリシーの確認 トランスクリプションが無効になっている組織では、この機能の恩恵を受けられない。まずはポリシーを確認し、必要に応じて有効化を検討する。Teams管理センターの「会議ポリシー」から設定可能だ。 2. 会議コンテンツへのアクセス権限の棚卸し 部門間で権限設定が混在している場合、Notebookから参照できる範囲に影響する。このタイミングで整理しておくと、後々のトラブルを防げる。 3. ユーザー・ヘルプデスクへの事前周知 デフォルトで有効になる機能のため、「会議がNotebookに出てきた」と困惑する問い合わせが発生しうる。簡単な利用ガイドを準備しておくと対応コストを下げられる。 エンジニア・現場ユーザーが使えるシナリオ 週次スタンドアップ → 週報自動生成: 週内の会議トランスクリプトをNotebookに登録し、「今週の進捗と課題をまとめて」とプロンプトするだけで週報ドラフトが完成 仕様議論 → 設計書起こし: 設計会議の議事録と既存仕様書をNotebookに共存させ、「会議での合意事項を反映した設計書を更新して」という使い方が自然にできる 顧客打ち合わせ → 提案書作成: 商談の録音をトランスクリプト化し、提案資料作成のコンテキストとして活用する 筆者の見解 「会議でこんな話をしたが、それを反映した資料を作るのに結局また手作業で整理する」——この非効率さに心当たりのある人は多いはずだ。Copilot Notebooksへの会議コンテキスト統合は、その課題に正面から向き合った機能拡張だと思う。方向性は正しい。 ただ、実際に価値が出るかどうかはいくつかの条件にかかっている。第一に、Teamsのトランスクリプションがきちんと使われていること。日本語認識の精度や、「録音・文字起こしが走るとわかったとたん発言が減る」という文化的な問題は、まだ組織によっては障壁になる。第二に、会議参加者の権限管理が整っていること。雑然とした権限設定のまま運用している組織では、Notebookへの参照追加時に想定外の制限が発生する可能性がある。 Microsoft 365の本来の強みは、メール・チャット・会議・ドキュメントが一つのプラットフォームで完結するという「統合性」にある。その文脈で見れば、今回の機能は「本来あるべき姿」に近づく一歩だ。Teamsで会議をし、Notebooksで資料を作り、SharePointで共有する——このサイクルが自然につながり始めた。 もちろん課題はある。だからこそ現場での「使えた・使えなかった」という生の声を積み重ねることが重要だ。統合の深化は歓迎しながら、実際の精度と使い勝手が期待に応えられるかを、これからも注視していきたい。 出典: この記事は Microsoft 365 Copilot (Premium): Teams meetings as a reference in Copilot Notebooks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365の2026年5月ロードマップが公開された。今月は「2026年で最もセキュリティが充実したリリース」と位置づけられるほどPurviewの更新が大規模で、DSPM（Data Security Posture Management）の全面刷新から内部リスク管理の進化まで、AIが業務に浸透した時代のデータガバナンス基盤が一気に強化される。CopilotはExcelに「プランモード」を獲得し、SharePoint・Teams・Outlookにも着実な改善が届いた。 今年最大：Purviewのセキュリティ更新を読み解く 今月のロードマップで最も存在感があるのは Microsoft Purview の更新群だ。 DSPMの全面刷新 DSPM（Data Security Posture Management） が統合体験として大きく生まれ変わる。組織全体のデータセキュリティリスクを一元可視化する新UIに加え、AIの利用状況を追跡する「AI Observability」機能、ポスチャレポート、そしてSecurity Copilotエージェントとの統合が実現する。 注目すべきは サードパーティ統合 だ。BigID、Cyera、OneTrust、Varonis といった外部データセキュリティベンダーのシグナルを取り込めるようになり、すでに自社セキュリティツールへ投資している大企業でも違和感なく活用できる設計になっている。 エンドポイントDLPの強化 Windowsのデフォルトファイルパス除外制御の追加に加え、Copilot+ PCのRecallスナップショットへの保護拡張が加わる。AI機能がエンドポイントで本格稼働し始めた今、DLPのカバレッジをAI生成コンテンツにまで広げるのは当然の進化といえる。 内部リスク管理（IRM）の進化 クラウドストレージやMicrosoft Fabricをリスクトリガーの検知源として追加し、Generative AIインジケーターの設定もAIアプリ単位で細かく制御できるようになる。IRMアラートがMicrosoft Defender XDRに統合される点も、SOCチームの運用効率に直結する改善だ。AIの業務利用に伴う内部リスクを正面から捉えた設計になっており、ここは評価したい。 CopilotのAI機能強化 長文ファイルのナビゲーション改善 Copilot Chatが文書構造を理解し、回答に必要なセクションへ自動ナビゲートできるようになった。長い仕様書や契約書に対する精度と引用の明確さが向上し、「どこから答えを拾ったか」がわかりやすくなる。 埋め込み画像・スキャンPDFの解釈 チャート、図、スクリーンショット、スキャンPDFをCopilot Chatが直接解釈できるようになる。紙ベースの資料をスキャンして活用している現場では、実務的な価値が大きい。 ExcelのCopilot「プランモード」 今月の更新で個人的に着目しているのがこれだ。Copilotがブックへの変更を加える前にステップバイステップの計画を提示し、ユーザーが確認・修正できるようになる。「気づいたらCopilotがシートを書き換えていた」という不安感が解消され、ユーザーがAIの挙動を把握したうえで活用できる基盤になる。 SharePoint・Teams・Outlookの実用的な改善 SharePointでは Authoritative Sites（権威あるサイト） の概念が導入され、AI検索時に「この情報は公式情報源」と明示できるようになる。AI生成ワークフローやDocGen自動化も追加され、SharePointをAI業務自動化の起点にする構想が実装レベルで進んできた。 Teamsはツールバー再設計・非同期アップロード・セキュリティ検出レポートなど利便性向上が中心。Outlookも検索・カレンダー・モバイル体験が改善される。 実務への影響 情報セキュリティ担当者・管理者へ Purviewの今月の更新は、段階的に導入している組織でも改めて機能一覧を精査する価値がある。特にDSPMの統合強化は、「AIが組織内のどのデータにアクセスし、何を生成したか」を可視化する基盤になる。AIの業務利用が広がるにつれ、こうしたガバナンス基盤の整備は後回しにできなくなる。 DLPのCopilot+ PC Recall対応も見落とせない。現時点でRecallを展開している組織は限定的かもしれないが、AI PC普及を見据えてDLPポリシーの準備を今から進めておきたい。 エンジニア・開発者へ ExcelのCopilotプランモードは「変更前に計画を提示する」という設計思想として学ぶべき点が多い。AIエージェントを自社システムに組み込む際も、実行前の計画提示と確認ステップの設計は信頼性向上に直結する。 M365管理者へ AdminセンターからPurviewのDLPを直接有効化できる機能追加は地味だが実用的。Microsoft Foundryアプリへのインラインも、Foundry活用が広がる局面で重要な制御ポイントになる。 筆者の見解 今月の更新を俯瞰すると、Purviewがようやく本来あるべき姿に近づいてきたと感じる。DSPMの統合強化、サードパーティシグナルの取り込み、AIの業務利用を前提にしたリスク管理——これらはゼロトラスト時代のデータセキュリティに必要な要素だ。 AIが業務に深く入り込んだ今、「AIがどのデータに触れ、何を出力したか」を組織として追跡・管理できる仕組みは選択肢ではなくなった。この領域はMicrosoftが統合プラットフォームとしての強みを活かせる場所であり、今月の更新はその方向性を正しく歩んでいる。 Copilotについては、ExcelのプランモードのようなUX改善の積み重ねを評価したい。「何をするか見せてから実行する」というアプローチは、AIへの信頼を育てるために欠かせない。M365という強力なプラットフォームを持っているのだから、こうした地道な改善を続けることで信頼できるAI体験を実現できるはずだ。正面から勝負できる力はある。その力を、使い勝手と透明性の向上に注ぎ込んでほしい。 SharePointのAI機能進化は「SharePoint再評価」のきっかけになるかもしれない。長年「難しい・重い」というイメージが付きまとってきたが、AIによる自動化の起点として再設計が進めば、組織の知識管理に大きな変革をもたらす可能性がある。こちらの進化も継続して追っていきたい。 出典: この記事は Microsoft 365 Roadmap Updates May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

エンドポイントに静かに潜み込むAIエージェントを「見える化」し、組織として制御する——。MicrosoftはAgent 365を2026年5月1日に正式一般提供（GA）へ移行させた。Ignite 2025でのデモから半年、クラウドエージェント管理の枠組みは今回、ローカルAIエージェント対応・他社クラウド連携・専用Cloud PCクラスという3方向に一気に拡張された。「エージェントスプロール」という言葉が現場に浸透しつつある今、この動きは無視できない。 3本柱：Observe・Govern・Secure Agent 365の設計思想は「観察（Observe）・ガバナンス（Govern）・セキュリティ（Secure）」に整理できる。 Observe（可視化）: Microsoft Defenderを通じ、Windows端末上で動作しているローカルAIエージェントのインベントリを管理者が取得できる。今回のGAではOpenCLawプラットフォームへの対応から開始し、今後はGitHub Copilot CLIやClaude Codeなど複数の開発者向けエージェントへの対応拡張が予告されている。 Govern（ガバナンス）: Microsoft Intuneのポリシー配布機能を活用し、未管理エージェントを検出・隔離・ブロックする。社員がサードパーティのストアからインストールしたエージェントも、既存のエンドポイント管理スタックの外に逃げることなく制御対象に入る。 Secure（セキュリティ）: AWS BedrockやGoogle Gemini Enterpriseで動作するエージェントも一元インベントリにインポートできるようになった。自社のクラウド選択に関係なく、AIエージェントの所在をMicrosoft 365ガバナンス基盤の上に集約する設計だ。 Windows 365 for Agents：人とエージェントを分離する専用Cloud PC 合わせてパブリックプレビューに入ったWindows 365 for Agentsは、エージェントワークロード専用のCloud PCクラスだ。エージェントの動作を人間のユーザーセッションから切り離すことで、セキュリティアラートのトリガー元が誰（何）か明確になり、インシデント対応が大幅にシンプルになる。 ただし、このCloud PCの利用にはAgent 365ライセンスに加えてIntuneライセンスとAzureサブスクリプションが必要となる。既存のMicrosoft 365エンドポイント管理基盤を持つ企業にとっては自然な拡張だが、Intune未導入環境では段階的な整備が前提になる点は留意が必要だ。 実務への影響 IT管理者向け: 「エージェントスプロール」は誇張ではない。エンジニアがローカル端末にAIエージェントを独自インストールする動きはすでに加速している。まずはDefender連携でインベントリを把握するところから始めるべきだ。把握できていないエージェントは管理も統制もできない。 エンジニア向け: 開発用途で使っているエージェントツールが、近い将来にIntune管理下に入る可能性が高い。組織の承認済みリストと照合しておき、ポリシー違反による突然のブロックを避ける準備をしておきたい。 M365管理者向け: スタンドアロン価格は月額15ドル（1ユーザー）。全社員展開ではコストインパクトが大きいため、エージェント利用が集中する開発部門や情報システム部門への部分展開から始め、ROIを測定してから全社展開を判断するのが現実的なアプローチだ。 筆者の見解 AIエージェントの「Non-Human Identity（NHI）管理」は、セキュリティとオートメーション推進の両面で今後最重要課題の一つになると確信している。エージェントが組織内を自律的に動き回る時代に、「誰が何をしたか」のトレーサビリティなしに業務を委ねることはリスク管理上あり得ない。そして業務効率を本当に上げるためにはNHIを使いこなす必要があり、その管理基盤なしには自動化も進まない。 MicrosoftがDefenderとIntuneというエンドポイント管理の既存資産を活かしてこの問題に切り込んできたのは、統合プラットフォームとしての強みが最もよく発揮される領域だ。点ではなく面で管理できる仕組みは、バラバラに製品を組み合わせるアプローチでは太刀打ちできない部分であり、ここは素直に評価したい。 ただ、ライセンスを重ねるほどコストが上がる構造は、日本の中堅企業にとってまだ高いハードルだ。Agent 365を検討する前に、まず自社内でどんなエージェントが動いているかの棚卸しを先に済ませることを強く勧める。管理対象がはっきりすれば、必要なライセンス範囲も自ずと絞られる。 方向性そのものは正しい。AIエージェントを野放しにしたまま業務活用を進めるのが最もリスクが高い。管理の仕組みが整って初めて、エンタープライズでの本格的なエージェント活用が現実のものになる。 出典: この記事は Microsoft Agent 365 Hits General Availability With Local AI Agent Controls の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、Microsoftが複数のライセンス変更を同時に実施した。「Microsoft 365 E7」と「Agent 365」という新SKUの登場、Windows 365 Businessの大幅値下げ、プロモーション延長——いずれも企業のIT予算・ライセンス戦略に直結する内容だ。変更点を整理し、日本のIT担当者が押さえるべきポイントを見ていこう。 Microsoft 365 E7——「全部入り」の新最上位SKU 今回の目玉はなんといっても Microsoft 365 E7 の正式リリースだ（3月に予告済み）。E7は以下の4要素をバンドルしている。 コンポーネント 主な内容 Microsoft 365 E5 生産性アプリ＋高度なコンプライアンス・セキュリティ（Defender/Purview） Microsoft 365 Copilot (Premium) Outlook/Word/Excel/Teams等への AI アシスタント埋め込み Agent 365 AIエージェントのガバナンス・統制レイヤー Microsoft Entra Suite ゼロトラスト／SASE対応のID・ネットワークセキュリティ ※ Intune Suite の機能統合は 2026年7月予定。 SKUは複数用意されており、Teams有無の選択肢に加え、500席以上・3年契約向けの特別SKUも提供される。製品IDは CFQ7TTBZZR6H。 E7は既存のE5からのステップアップとして設計されており、「Copilotを本格活用したい」「ゼロトラストを推進したい」という企業にとって、個別購入よりバンドルのほうが割安になるケースを狙った設計だ。 Agent 365——AIエージェント時代のガバナンス基盤 もう一つの注目点が Agent 365 だ。CopilotをはじめとするファーストパーティのMicrosoftエージェント、さらにサードパーティのエコシステムエージェントを一元管理するためのガバナンスレイヤーとして機能する。 ライセンス体系の特徴： ユーザー単位課金（エージェントの数ではない） 1ライセンスで、そのユーザーが「利用・管理・スポンサー」するすべてのエージェントをカバー 基本機能（エージェントレジストリ・基本管理）は追加費用なしで全サブスクリプション顧客に提供 高度機能（詳細分析、セキュリティポスチャ管理、脅威検知、データセキュリティ制御）には Agent 365ライセンスが必要 技術的な統合先はDefender・Entra・Purviewの3本柱。Entraでエージェントにアイデンティティを付与し、Defenderで脅威を監視、Purviewでコンプライアンスを担保する構成だ。 注意点：ライセンスを付与していないユーザーはAgent 365の保護対象外となり、コンプライアンスギャップが生じる。AIエージェントを業務利用するユーザーの範囲を早期に棚卸しし、ライセンス設計に反映する必要がある。製品IDは CFQ7TTBZZR6G。 Windows 365 Business——20%値下げ＋休止機能で導入障壁が下がる 地味に実務インパクトが大きいのがWindows 365 Businessの変更だ。 全SKU一律20%値下げ（2026年5月1日から新規注文・更新に適用） 1時間非活動でCloud PCが自動休止（未使用分のコスト圧縮に直結） プロモーション（値下げ後からさらに20%引き）を2026年6月30日まで延長 価格の参考としてCHFベースの変更幅を見ると、たとえば「2 vCPU / 8 GB / 256 GB」構成では年間約102CHFの削減。プロモーション適用でさらに安くなる。 ...