M365

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

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

Microsoft Teamsが2026年6月中旬の一般提供（GA）を目標に、Otter.aiやFirefliesといった外部ミーティングアシスタントボットをロビー段階で自動検出し、会議主催者がリアルタイムで制御できる新機能を追加する。 外部ボット自動検出の仕組み 現状のTeamsでは、外部の議事録AIや文字起こしボットが会議に参加する際、通常の出席者と見た目が変わらないため、主催者が気づかないケースが少なくない。新機能ではボットがロビーに入った時点で明示的にラベルが表示され、主催者は次の3つの操作をその場で選択できる。 承認: ボットの入室を許可する ブロック: ロビーで待機させたまま入室させない 除去: 参加済みのボットを会議から退出させる さらにIT管理者はテナント全体のポリシーを設定可能になる。「特定カテゴリのボットを一律ブロック」「事前承認済みのボットのみ許可」といった組織レベルの統制が実現する。 2026年のTeamsに追加される主な機能 外部ボット検出以外にも、2026年のTeamsには60以上の機能追加が計画されている。注目どころを整理する。 AI・Copilot関連 リアルタイムコンテンツ分析（2026年8月〜）: 画面共有中のドキュメントやスライドをCopilotがリアルタイムで要約・分析できるようになる 未読チャット自動要約（2026年3月〜）: 長い未読スレッドをCopilotが要点整理し、キャッチアップを効率化 SharePointエージェント連携（2026年1月〜）: チャット・チャンネル内から直接SharePointエージェントを検索・追加できる 通話品質・利便性 通訳エージェント対応（2026年1月〜）: 会議をリアルタイムで任意の言語に翻訳。多言語チームの会議体験が大きく変わる ネットワーク品質インジケーター（2026年2月〜）: 映像が乱れた際に原因と帯域節約の提案を視覚的に表示 Wi-Fi連動の作業場所自動更新: 接続中のWi-Fiネットワークに基づいて在宅/オフィスを自動認識し、プレゼンス情報を更新 実務への影響 外部ボット検出機能は、日本企業のセキュリティ・コンプライアンス担当者にとって「新たな設定作業が増える」と同時に「長く欲しかった可視化手段が手に入る」両面を持つ。 情報漏えいリスクのコントロール向上: 現状、会議参加者が外部の文字起こしサービスを無断使用していても、主催者が把握できないグレーゾーンが存在する。明示的なラベル表示で「見えない録音」が減り、組織としての統制が現実的になる。 テナントポリシー設計が重要: 管理者は「全面禁止」ではなく「承認済みボットのみ許可」という方針を検討したい。禁止一辺倒のアプローチは必ず回避策を生む。組織が承認したツールを使いやすくする設計こそが、実効性のあるガバナンスにつながる。 ユーザー教育との組み合わせ: 技術的な制御だけでは不十分だ。「なぜ外部ボットの無断利用がリスクなのか」をユーザーに説明し、納得感を持ってポリシーに従ってもらう体制を整えることで、機能の実効性が格段に高まる。 筆者の見解 外部ボット自動検出は、テナント管理者が以前から求めていた機能だ。議事録AIの急速な普及で「誰かが会議を録音しているかもしれない」状況が常態化していた現場からすれば、明示的な承認フローの導入は歓迎できる施策だ。 Copilot関連機能については、リアルタイムコンテンツ分析や通訳エージェントはいずれも実用的な追加だ。一方で、これだけの機能群がようやく2026年前後に揃ってくるというスケジュール感は、現場のニーズが先行していた状況を改めて示している。TeamsにはこれほどのユーザーベースとMicrosoftのインフラという強みがある。その力をもってすれば、もっと大きな飛躍ができるはずだ——そう期待するからこそ、正直に書いておきたい。 Teamsをどう使うかという観点では、議事録の自動化や定型業務の効率化にはCopilotを積極的に活用し、より高度な分析・創造的なタスクには状況に応じた選択肢を検討するという「使い分け」が現実解だ。プラットフォームとしての統合力はTeamsの本質的な強みであり、その部分は正しく評価した上で活用を進めたい。 2026年後半のロードマップには期待できる項目が並んでいる。この記事が数年後に「古い批評」になっていることを、心から願っている。 出典: この記事は Microsoft Teams to detect and label external meeting assistant bots automatically の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

AnthropicのAIエージェント「Claude Cowork」とMicrosoftの「Copilot Cowork」を比較した分析が話題を呼んでいる。両者の設計思想は根本的に異なり、中小企業（SMB）がどちらを選ぶべきかという議論に新たな視点を提供している。 Copilot CoworkとClaude Coworkは何が違うか 二つのエージェントの設計哲学は対極にある。 Claude Cowork はデスクトップ上で動作するローカルエージェントだ。ユーザーはフォルダをマウントし、ファイルをドロップすることで、Claudeがサンドボックス環境内でそれを処理する。このエージェントはユーザーのメールボックスも、カレンダーも、Teamsチャットも「見ない」。データをモデルに持ち込む必要がある。 Copilot Cowork は逆の発想で作られている。すでにMicrosoft 365の内側に存在しており、Outlook・Teams・SharePoint・OneDrive・カレンダーに「Work IQ」経由でグラウンディングされている。ユーザーは何もマウントしない。モデルが既にデータのある場所にいるのだ。 SMBがCopilotを選ぶ理由：「すでに持っている」強み この比較が示すのは、機能の優劣だけではなく導入コストと統合コストの問題だ。 多くのSMBはすでにMicrosoft 365のライセンスを持っている。Exchange、Teams、SharePointを使うために契約したM365には、Copilotという形でAI機能が加わる。別途連携設定をしなくても、業務データと直結したAIがすぐ使える。 「ベスト・オブ・ブリード（最良のツールの組み合わせ）」を追求するよりも、「すでに支払っているツールで十分な品質が得られる」ことを優先する経営判断は、専任のIT担当者を持たないSMBにとって現実的な合理性がある。 2026年5月のM365主要アップデート Microsoft Agent 365が一般提供（GA）開始 Microsoft Agent 365が正式にGAとなり、ローカルAIエージェントのコントロール機能が追加された。テナント内でのエージェント動作制御が可能になり、オンプレミス環境との組み合わせにも道が開ける。 Microsoft 365 CopilotにGPT-5.5 Instantが統合 OpenAIの最新モデル「GPT-5.5 Instant」がMicrosoft 365 Copilotで利用可能になった。応答速度の向上が期待されており、日常的なCopilot操作がよりスムーズになることが見込まれる。 Microsoft Legal Agentの登場 「プロンプトよりもプレイブック（Playbooks）が重要」というアプローチを取るMicrosoft Legal Agentが発表された。繰り返し発生する法務フローを定型化し、AIがそのフローを実行するという設計は、規制業種での実用性を意識したものだ。 Teamsの「Together Mode」が2026年6月に廃止 ハイブリッドワーク黎明期に導入された仮想同席機能「Together Mode」が、2026年6月に提供終了となる。利用率が伸び悩んでいたことは業界内でも指摘されており、静かな幕引きとなった。 クロステナント侵入プレイブックへの警告 クロステナントのヘルプデスクなりすましからデータ窃取に至る「人間主導型侵入プレイブック」に関する注意喚起が業界内で広まっている。テナント管理者は今一度、クロステナントアクセス設定とヘルプデスク権限の棚卸しを行うべきだ。 実務への影響 M365管理者・IT担当者へのアドバイス： Copilot Coworkの社内テストを早めに始める: 自社テナントでの試験導入を通じ、実際の業務フローとの統合度を先に把握しておく。「つながっているから便利」が本当に成立するかどうかは、使ってみないとわからない Entraエージェント権限の事前確認: Agent 365 GAに伴い、エージェントが利用するEntraアプリ登録の権限スコープを確認しておく。デプロイ前の棚卸しを怠ると後で思わぬ広権限付与が発生する クロステナント侵入対策の即時実施: なりすましヘルプデスク経由のデータ窃取は現実の脅威として報告が増えている。クロステナントアクセスポリシーのレビューを今すぐスケジュールに組み込む 筆者の見解 Copilot CoworkとClaude Coworkの比較は、AIツール選定における本質的な問いを浮き彫りにした。「最高のAIはどれか」ではなく、「自分たちのデータと業務フローにどのAIが最も近い場所にいるか」という問いだ。 この観点では、Microsoft 365に業務データが集約されている組織にとって、Copilotの統合優位は確かに無視できない。設定不要でメール・会議・文書に接続されるという体験は、IT担当者が手薄なSMBにとって現実的な価値をもたらす。 一方で、「Copilotがすでにある」という理由だけで思考を止めてしまうのはもったいない。Copilotが得意な領域（定型業務・会議要約・Outlookの処理）と、状況によって外部AIが補完できる領域（高度な分析・複雑な文書生成・創造的タスク）を整理し、両者を使い分ける設計を最初から意識しておくことが重要だ。「どちらか」ではなく「どう組み合わせるか」が問いの本質だと思っている。 Microsoftが今月打ち出したAgent 365 GA、Legal Agent、GPT-5.5 Instant統合は、プラットフォームとしての進化を着実に示している。Copilotが苦手とされてきた領域を埋める取り組みが続いており、プラットフォームの底力は本物だ。その力がユーザーの手元で実感できる形でさらに発揮されることを、応援する立場から期待している。 ...

Microsoftは2026年5月、「Microsoft 365 E7 Frontier Suite」の新設を筆頭に、3段階リリースモデルへの移行、Teams向けOffice 365 Connectorsの完全廃止、各スイートへのセキュリティ機能追加を同時に実施した。IT管理者にとって見落とせない変更が一度に押し寄せてきている。 Microsoft 365 E7 Frontier Suiteとは 2026年5月1日に正式登場した「Microsoft 365 E7 Frontier Suite」は、既存のE5をベースにCopilotとAgent 365をバンドルした最上位SKUだ。価格はユーザーあたり月額$99（約14,500円）と、E5単体（$57/月前後）の約1.7倍に設定されており、自律型AIエージェントの大規模展開を見据えた企業を主なターゲットとしている。 「Frontier」という名称は、同時に導入される新リリースモデルの最速チャネル名とも一致しており、AI主導の新機能への最速アクセス権だけでなく、高度なガバナンスとセキュリティ制御が含まれる。規制の厳しい金融・医療・公共機関や、AIエージェントをコアビジネスに組み込もうとしている企業がメインターゲットと見ていい。 Frontier / Standard / Deferred：3チャネルリリースモデルへ移行 Microsoft 365の変更管理モデルが刷新され、より明確な3チャネル制に移行する。 チャネル 特徴 Frontier 新機能を最速で受け取る。AI機能への先行アクセス Standard デフォルト。バランス重視の標準的なタイミング Deferred テスト・検証に時間を確保したい組織向け あわせてMessage Centerの投稿も刷新され、どのチャネルに何がいつ届くかが以前より把握しやすくなる。さらに「MCP Server経由のAIインサイト」が導入され、管理者がMessage Centerを手動でチェックしなくても、影響範囲と推奨アクションをAIが要約してくれる仕組みが整う。 Office 365 Connectors（Teams）が5月18日に完全廃止 長年にわたって段階的に廃止が進んでいたOffice 365 Connectorsが、2026年5月18日をもってMicrosoft Teamsから完全撤退する。 Teamsチャンネルに監視アラート、チケット通知、定期レポートをConnectors経由で流している組織は、今すぐ移行計画を立てる必要がある。代替手段は以下の3つだ。 Incoming Webhook: 最もシンプルな置き換え先。既存のWebhook URLベースの通知をそのまま移行しやすい Power Automate: Teamsへの投稿をフロー化する。複雑な条件分岐や複数チャンネルへの配信に向いている Teams App（Messaging Extension等）: より高機能な統合が必要な場合の選択肢 5月18日を過ぎると通知が「サイレント停止」する。アラートが届かなくなって初めて気づく——これが最も危険なシナリオだ。 セキュリティ機能の追加パッケージング（2026年Q3〜） 2026年7月以降のロールアウトに向けて、各スイートへのセキュリティ機能追加が公式発表されている。8月1日までに完了予定で、テナント単位の変更は30日前にMessage Center通知が届く。 エンタープライズ（E3/E5）向け追加予定機能： Microsoft Defender for Office 365 Plan 1 Microsoft Intune Remote Help / Advanced Analytics Intune Plan 2 / Privilege Management Microsoft Cloud PKI Intune Application Management Business Basic / Standard / Premium向け： ...

AnthropicがMicrosoft 365向けのClaudeアドインを大幅に拡充した。Word・Excel・PowerPoint向けアドインは一般提供（GA）を開始し、Outlookはパブリックベータとして公開された。既存のClaude有料プラン（Pro・Team・Enterprise）に含まれており、Microsoft Copilotとは独立して利用できる。 アプリをまたいでAI文脈が途切れない 今回のリリースの最大の特徴はクロスアプリ文脈継続性だ。例えば、OutlookでClaudeにプロジェクト関連メールを要約させたあと、Wordに切り替えても「さっきのプロジェクトの話」として会話が続く。さらにPowerPointに移動すれば、同じ文脈のまま資料作成ができる。 従来のAIアシスタントはアプリをまたぐたびにプロンプトを書き直す必要があった。Claudeはユーザーごとに単一の会話スレッドを維持することでこの摩擦を取り除いた。Anthropicがデモとして公開した動画では、Outlookで要約→Wordで文書作成→PowerPointでスライド化という一連のワークフローが、一切プロンプトを書き直すことなく完結する様子が確認できる。 各アプリでの具体的な機能 Excel: セルの編集・前提条件の調整が可能で、重要なのは既存の数式を保持したまま操作できる点だ。実務のExcelファイルには複雑な数式が混在しており、AIが誤って上書きするリスクを回避できるのは現場目線で大きい。 PowerPoint: 静的な画像ではなく、ネイティブなチャートをスライド内に直接生成できる。既存テンプレートのフォーマットを維持したまま作業できるため、企業のブランドガイドラインに沿ったスライドを崩さずに使える。 Word: Outlookで把握した情報をそのまま反映した文書作成を継続的に支援する。 Outlook（パブリックベータ）: メール要約・返信文生成などをM365環境内で直接実行。クロスアプリ文脈の起点となる位置づけだ。 ライセンス面の重要な違い Microsoft 365 Copilotは月額30ドル/ユーザー程度の追加ライセンスが必要になるケースが多い。ClaudeアドインはClaude Pro・Team・Enterpriseプランに含まれるため、すでにAnthropicサブスクライバーであれば追加コストなしで試せる。コスト比較を含めた導入検討が現実的になる。 実務への影響 日本のエンジニアやIT管理者にとって、このリリースが持つ意味は主に2点だ。 1. M365環境内でのAI選択肢が増えた Copilotと並んでClaudeが利用可能になったことで、企業は用途に応じてAIアシスタントを選べるようになる。定型的なメール対応はCopilot、高度な分析や長文ドキュメント生成はClaudeという「使い分け設計」が現実的になってきた。 2. 社外サービスへのコピペ問題が緩和される可能性 情報セキュリティポリシー上、外部サービスへのデータ貼り付けを制限している企業は多い。M365アドイン経由であれば適用範囲や審査軸が変わる可能性があり、導入ハードルが下がるケースも出てくる（社内ポリシーの確認は個別に必要）。 明日から試せる手順: Claude Pro/Team/Enterpriseプランへの加入を確認 Microsoft AppSourceで「Claude for Excel」「Claude for Word」「Claude for PowerPoint」を検索してインストール Outlookはパブリックベータ参加申請から 筆者の見解 Microsoft 365というプラットフォームに外部AIが本格参入したことは、M365ユーザーにとってシンプルに選択肢が広がる話だ。CopilotとClaudeを「競合」として見るより、「M365上で使えるAIが増えた」という捉え方の方が実務的だと思う。 筆者自身、定型業務にはCopilotを、より高度な文書生成や分析には別のAIを組み合わせる運用を試みており、両方がM365環境内で完結するようになることはワークフロー上のメリットになる。 ひとつ気になるのは、クロスアプリ文脈継続性の長期的な精度だ。会話スレッドがアプリをまたいで維持されるとはいえ、実務では「どこまで正確に文脈を引き継いでいるか」を確認する習慣は持っておきたい。どのAIツールを使う場合でも、出力を鵜呑みにしない姿勢は変わらない。 Microsoftの観点から見れば、自社のCopilotと外部AIが同一プラットフォーム上で競合する構図ではあるが、M365全体としての価値が上がるのであれば悪い話でもない。どのAIが選ばれても、プラットフォームを持つ側には一定の恩恵がある——そこはMicrosoftの強みが変わらないところだ。Copilotにはぜひこの競争環境を追い風に、さらに磨きをかけてほしいと思う。 出典: この記事は Claude Expands Into Microsoft 365, Bringing AI Context Across Word, Excel, Outlook and PowerPoint の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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

2026年3月9日、MicrosoftはMicrosoft 365 CopilotにAnthropicのClaude Sonnetを統合し、約4億人のOfficeユーザーがAIモデルを用途に応じて選択できるようになった。これまでOpenAIのGPT-4oに固定されていたCopilot Chatが初めてマルチモデル選択に対応した、M365の転換点といえる動きだ。 Wave 3アップデートで何が変わったのか Microsoft 365の「Wave 3」アップデートにより、Copilot ChatのFrontierプログラム参加ユーザーが、モデルセレクターからClaude Sonnetを選択できるようになった。対応プラットフォームはWeb・デスクトップ（Windows/macOS）・モバイルと幅広く、2026年3月末をめどにロールアウトが完了する予定だ。 ただし現時点ではEU/EFTA・英国・政府クラウド・ソブリンクラウド環境は対象外となっており、規制対応を段階的に進める姿勢が見てとれる。グローバル拠点を持つ日本企業のIT担当者は、地域ごとの利用可否を事前に確認しておく必要がある。 技術的な背景として、AnthropicはMicrosoftの「サブプロセッサー」として正式認定済みであり、企業データはMicrosoftのクラウドインフラ内で処理される。データプライバシーの責任主体はMicrosoftとなる構造だ。この統合は、Microsoftが約300億ドル（約4.5兆円）規模のAzureコンピュート契約をAnthropicと締結した戦略的連携の実装フェーズにあたる。 新機能「Copilot Cowork」——自律型エージェントが業務を代行 今回の統合で最も注目すべきは、モデル選択機能そのものより「Copilot Cowork」だ。Anthropicのエージェンティックモデルをベースに構築されており、単純なQ&Aを超えたマルチステップの自律タスク実行を担う。 Coworkを支える仕組みが「Work IQ」と呼ばれるコンテキスト理解エンジンだ。メール・ファイル・ドキュメント・Teams会議・チャットを横断的に取り込み、組織の業務背景を把握した上でタスクを実行する。具体的には以下のような複合ワークフローを、単一の指示で処理できる： Teams会議録から要点を抽出→Wordで議事録ドラフト→PowerPointで報告資料を自動生成 Excelの複数ブックにまたがるデータを統合・集計→条件付き計算を適用→経営層向けサマリーを出力 四半期レビュー用資料の作成において、売上データ・会議メモ・過去資料を横断参照しながら一貫した分析レポートを組み立てる 現時点では一部顧客向けのリサーチプレビューであり、Frontierプログラムを通じて2026年3月末以降に順次公開される予定だ。 日本のIT現場への影響 モデル使い分けの実践設計 Word・Excel・PowerPointでの定型業務はCopilotの既存機能で対応できるが、長文ドキュメントの整合性チェックや複雑な分析・要約にはClaude Sonnetが強みを発揮しやすい場面がある。ただし、モデルが増えるほど「どの業務にどのモデルを使うか」という設計が組織内で必要になる。現場に丸投げすると「デフォルトのまま使う」状態に陥りやすいため、利用ガイドラインの整備をIT部門が主導することが望ましい。 データガバナンスの再確認 Anthropicがサブプロセッサー認定されているとはいえ、情報セキュリティ部門・コンプライアンス担当者は自社のデータ取り扱いポリシーとの整合を確認する作業が発生する。機密度の高い文書を扱う場合は、どのモデルにデータが渡るかを明示したポリシーを先行して整備したい。 エージェント活用の事前準備 Copilot Coworkが正式公開されれば、定期的に発生するレポート作成・資料整理・データ集計の自動化が現実的な選択肢になる。今のうちから自部門の定型業務フローを棚卸しし、エージェントに委ねやすい候補を洗い出しておくことが、早期活用の近道だ。 筆者の見解 「Copilotは1モデルに縛られる」という制約が今回の統合で緩和されたことは、率直に評価できる動きだと思う。単一ベンダーのモデルだけでなく、用途に応じて選択できる環境を整えることは、エンタープライズAI活用の成熟度を上げる正しい方向性だ。 Copilot Coworkのようなエージェント機能は、M365の本来の強みである「統合プラットフォームとしての価値」を最大化する方向に動いている。Teamsで話し、Outlookでメールし、Wordで書き、Excelで分析する——その全体をシームレスにつなぐ存在としてエージェントが機能するなら、Microsoft 365の競争力は改めて際立つはずだ。Microsoftにはこのポテンシャルを生かせる力がある。 あとは「使い分けの設計」をどうユーザーに届けるかだ。モデルが増えるほど、現場は選択肢の多さに戸惑う。Microsoftには、マルチモデル環境をユーザーが自然に使いこなせるUX設計と、IT管理者がポリシーを整備しやすい管理ツールの充実に、引き続き注力してほしい。機能の豊かさを使いやすさに変換できれば、このアップデートの意義は大きく跳ね上がる。 出典: この記事は Microsoft 365 Copilot Now Runs Claude Sonnet: How 400 Million Office Users Got Access to Anthropic’s AI — Enterprise Integration Deep Dive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが SharePoint Online に新たな分析機能「AI citations analytics（AI引用分析）」を追加した。Microsoft 365 Copilot や各種AIエージェントがどの文書・ページを参照したかを可視化できるようになり、サイトオーナーやコンテンツ管理者がAI活用状況をデータで把握できる。2026年5月中旬までに全世界へのロールアウトが完了予定だ。 AI引用分析とは何か AI引用分析とは、Microsoft 365 Copilot や各種AIエージェントが SharePoint 上のコンテンツを参照（引用）した回数を集計・表示する機能だ。 従来の SharePoint サイト統計には「閲覧数（Views）」「閲覧ユーザー数（Viewers）」といった指標しかなかったが、今回の更新でAI起点のアクセスも計測対象となる。 追加される機能は大きく3つある。 1. サイト利用統計への「AI引用ランキング」 「Popular content（人気コンテンツ）」セクションに、Copilot や AIエージェントに最も多く参照された文書・ニュース投稿・ページのランキングが表示される。 2. ページ分析への「Total citations」カード 個別ページやニュース投稿の分析画面に、そのページが Copilot やエージェントの回答で何回引用されたかを示す「Total citations」カードが追加される。 3. 新設の「AI citations analytics」ページ サイト利用統計の配下に独立した分析ページが新設され、以下の情報を確認できる。 Copilot・AIエージェント経由でサイトコンテンツを利用したユーザー数 サイト全体の総引用数 最も引用回数の多い文書・ニュース投稿・ページ一覧 対応エージェントは Microsoft 365 Copilot をはじめ、Word・Excel・PowerPoint・Teams・Loop・Planner 内の Copilot、SharePoint Knowledge Agent、SharePoint カスタムエージェントと幅広い。 前提条件と管理者対応 この機能を利用するには Microsoft Copilot ライセンス が必要。管理者による設定変更は不要で、有効化はデフォルトで行われる（ロードマップID: 480725）。 実務への影響 コンテンツ管理担当者・サイトオーナー 「この文書、本当に使われているの？」という問いに対して、これまでは人間の閲覧数だけが根拠だった。しかしAIエージェントが回答生成に使う文書は、必ずしも人間がよく見るページと一致しない。 AI引用分析が入ることで、「人間にはあまり閲覧されていないが、AIが頻繁に参照している重要文書」が浮かび上がる。情報の鮮度管理や更新優先度の判断材料として活用できる。 ガバナンス・情報管理担当者 「SharePointに上げた文書がCopilotの回答にどう使われているか」を組織として把握する手段が生まれる。機密レベルの高い文書が意図せず広く引用されていないか確認するトリガーとしても使える。アクセス権ポリシーの見直し契機として活用できるだろう。 Copilot 導入推進担当者 CopilotのROI（投資対効果）を問われた際に、「何人がCopilot経由でサイトコンテンツにアクセスしたか」という具体的な数字が使えるようになる。経営層への報告資料にも組み込みやすいデータだ。 筆者の見解 AI引用分析は、Copilot活用が一定程度進んだ組織にとっては実用価値の高い機能だと思う。「AIが参照しやすい文書を整備する」という新しい視点でコンテンツ管理ができる点は面白い発想だ。 一方で率直に言えば、この機能が真に役立つためには「Copilotがまともに動いていること」が前提になる。Copilotライセンスの費用対効果にまだ確信を持てていない組織では、分析データを見る前の段階で議論が詰まっているはずだ。 ...

MicrosoftはEntra IDのパスキープロファイル機能を、2026年5月より米国政府クラウド（GCC・GCC High・DoD）向けに一般提供（GA）開始した。既存のパスキー（FIDO2）認証が有効なテナントは同年8月以降に自動移行の対象となり、管理者は事前確認と準備が求められる。 パスキープロファイルとは何か パスキープロファイルは、組織内のパスキー認証設定をグループ単位できめ細かく管理するための新しい構成単位だ。従来のFIDO2認証方法ポリシーが組織全体への一律適用しかできなかったのに対し、パスキープロファイルを使えば部署やセキュリティグループごとに異なるポリシーを適用できる。 パブリッククラウド（Worldwide）では2026年3月にGA済みであり、今回のロールアウトで政府クラウドが追いつく形となった： GCC（Government Community Cloud） GCC High DoD（Department of Defense） USNat・USSecへのロールアウトは2026年7月以降の予定だ。 端末固定型 vs 同期型：passkeyTypeプロパティの役割 今回の主要な新機能が passkeyType プロパティだ。管理者はパスキーの種類を以下の3パターンから選択して制御できる： 設定 説明 デバイスバウンド（端末固定型） 特定端末にのみ紐付け。他端末への同期は行わない 同期型（Synced Passkeys） Apple Keychain・Google Password Manager・1Passwordなどを通じてデバイス間で同期可能 両方許可 上記いずれも受け入れる セキュリティ要件の高い組織では「端末固定型のみ」を選択することで、フィッシング耐性を維持しつつパスキー盗用リスクを低減できる。一方、利便性を優先する組織では同期型を許可することで、複数デバイスでのシームレスな認証が実現する。 既存テナントへの自動移行：何が変わるか すでにパスキー（FIDO2）を有効化しているテナントは、以下のスケジュールで自動移行が実施される。 GCC / GCC High / DoD の場合： GAロールアウト：2026年5月初旬〜5月末 自動移行：2026年8月初旬〜8月末 移行後に起きること： 既存のFIDO2認証方法設定は「デフォルトパスキープロファイル」に自動変換される passkeyTypeの値は現在のAttestation設定に基づいて決定される Attestation強制が無効のテナント → 同期型パスキーが有効化 Attestation強制が有効のテナント → 端末固定型のみ 新たな認証方法が自動追加されることはない 「設定が変わっても、新機能が突然有効になるわけではない」という点は重要だ。移行はあくまでスキーマの変換であり、既存の認証フローに即時の破壊的影響は与えない。 登録キャンペーンへの影響（Microsoft管理テナント） 「Microsoft管理」状態に設定されている認証方法登録キャンペーンを持つテナントは追加の注意が必要だ。以下の条件がすべて揃う場合、ユーザーへのパスキー登録促進（ナッジ）の挙動が変わる： パスキー（FIDO2）が有効 登録キャンペーンが「Microsoft管理」状態 セルフサービスセットアップが有効 AAGUIDによる制限なし 少なくとも1人のユーザーが同期型・端末固定型の両方で有効化されている この条件を満たすテナントでは、自動移行完了後に登録キャンペーン設定が更新され、対象ユーザーはサインイン時にパスキー登録を促されるようになる。 実務への影響 GCC/DoD環境の直接利用者は限られるが、以下の観点から国内のIT管理者にも参考になる。 グローバル展開企業のIT管理者へ： 米国政府機関・国防関連とのパートナーシップを持つ組織では、パートナーテナント側の設定変更に伴う認証フローの変化に注意が必要だ。 passkeyTypeポリシーの設計はIntuneと連動させる： 「同期型を許可するか否か」の判断は、デバイス管理ポリシー（Intuneによる端末管理）や情報資産のリスク分類と連動して設計すべきだ。端末管理が整備されていない状態で同期型を解放するのはリスクが高い。 ...

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

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

Microsoft 365 Copilotに、カレンダー管理を自動化するCalendar Agent機能が追加された。自然言語でルールを定義するだけで、Copilotが会議の承認・辞退・削除を自動実行する。2026年4月下旬〜5月上旬にかけてFrontierプログラム向けにロールアウトが始まっており、既存のコンプライアンスポリシーや管理者設定をそのまま引き継ぐ形で動作する。 Calendar Agentとは何か Calendar Agentは、Copilot Chatのカレンダー関連サーフェスから利用できる新しいエージェント機能だ。ユーザーが「Copilot Chatで『Allow Actions』を選択」することで有効になり、以下のような自然言語のルールを設定できる。 「上司からの会議招待は、空き時間があれば常に承認する」 「キャンセルされた会議は自動的にカレンダーから削除する」 「勤務時間外の会議は辞退する」 ルールはCopilotが継続的に評価し、条件に合致した際に自動でアクションを実行する。操作の履歴は「承認・フォロー・辞退・削除」のカテゴリ別にまとめられたアクティビティ履歴ビューで確認でき、各アクションの理由も表示される。 対応プラットフォームと前提条件 本機能が利用できる環境は以下の通りだ。 プラットフォーム 対応状況 Outlook（クラシック版・新版） ◎ Outlook on the web ◎ Microsoft Teams ◎ Outlook モバイル（iOS / Android） ◎ 前提条件はMicrosoft 365 Copilotライセンスの保有と、既存のCopilotエージェントポリシーによる利用許可のみ。新たな管理者設定は一切不要で、テナントのコンプライアンス境界・データ保持・監査ログの動作も変わらない。 注意点として、Calendar Agentが操作できるのはサインイン中のユーザー自身のカレンダーのみであり、他のメールボックスやテナントをまたいだ操作は行われない。 IT管理者が準備すべきこと Microsoftは「追加の準備作業は不要」と説明しているが、実務上は以下の確認を推奨する。 既存のCopilotエージェントポリシーの確認: どのユーザーが「Allow Actions」を有効化できるかを把握しておく ヘルプデスクへの事前共有: ユーザーが設定を有効にすると、Copilotが自動でカレンダー操作を行うようになる。問い合わせ増加の可能性に備える 内部ガイドラインの更新: Copilot利用ポリシーやOutlook操作手順書がある組織は、Calendar Agentの動作について追記を検討する 機能はCopilotエージェントを許可されているユーザーに対してデフォルト有効となるが、ユーザー自身が「Allow Actions」を選択するまでエージェントは動作しない。誤操作リスクは低いが、自動化の動作範囲をエンドユーザーに周知しておくことが重要だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本の職場では「とりあえず招待しておく文化」によって、一人あたり週数時間がカレンダー管理に消えているケースが珍しくない。Calendar Agentが機能すれば、こうした定型判断の多くをCopilotに委譲できる。 ただし、日本特有の「断ること自体への心理的ハードル」を考えると、辞退ルールの設定はデリケートな場面がある。「上位職の会議招待を自動辞退してしまった」という状況を防ぐため、最初は「キャンセル済み会議の自動削除」のような低リスクなルールから試すのが現実的なアプローチだろう。 IT管理者の観点では、既存のExchange/Outlookガバナンスに乗っかる設計であるため、導入コストは最小限に抑えられる。Copilotエージェントの利用を全社で許可している組織であれば、追加作業なしで即日展開可能だ。 筆者の見解 Calendar Agentが目指す方向性は正しいと思う。カレンダー管理は誰もが「AIに任せたい」と感じる典型的な定型業務であり、自然言語でルールを設定できる仕組みはユーザーフレンドリーだ。 ただ、ここで正直に言っておきたい。Copilotはこれまで、こうした「使えるかもしれない」機能を何度も発表してきた。期待して試してみると、精度や動作の安定性でがっかりするサイクルが続いている。Calendar Agentについても、まずはFrontierプログラムでの実績を見極めたい。 Microsoftが持つOutlook・Exchange・Teamsとのネイティブ統合の深さは、他のどのプレイヤーにも真似できない強みだ。その基盤の上にCalendar Agentが確実に動くなら、カレンダー管理における最も自然な選択肢になりうる。その実力を、今度こそ本番環境で見せてほしいと思っている。 アクティビティ履歴ビューの実装は特に評価したい。AIが自動で操作した内容を事後確認できる透明性の確保は、信頼構築の第一歩として正しいアプローチだ。こういった地道な品質への投資が積み重なることで、Copilotへの信頼が少しずつ回復していくことを期待している。 出典: この記事は Introducing Calendar Agent capabilities in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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

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

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

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

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