M365

GensparkがMicrosoftとグローバル戦略パートナーシップを締結し、同社のAIエージェントをMicrosoft 365へ直接統合すると発表した。PowerPoint・Excel・WordといったM365の日常業務アプリがエージェント対応へと進化し、新たなソフトウェアのインストールもログインも不要。エンタープライズ向けAIの競争が、プラットフォームの「外側」から「内側」へと主戦場を移してきた。 GensparkのAIエージェントがM365アプリの中に住む 今回の提携の核心は「AIエージェントがアプリの外側に存在するのではなく、アプリの中に組み込まれる」という設計思想にある。 Gensparkが提供するのは3つのエージェント機能だ。 PowerPoint向け: シンプルなプロンプトからプレゼン資料を生成する。自社テンプレートの活用、既存スライドデッキの再編集、ディープリサーチからアウトライン生成まで、PowerPoint内で完結できる。 Excel向け: データに対して自然言語で質問できる。数式を一切書かずに分析結果やグラフ、インサイトを得られる機能は、Excelの非エキスパートにとって特に価値が高い。 Word向け: 文書の文脈を理解した上での下書き生成・編集。単なるテキスト補完ではなく、文書全体の意図を把握した知的な編集支援を実現するとされている。 GensparkのエージェントはすべてMicrosoft Azureインフラ上で構築・デプロイされており、エンタープライズグレードのセキュリティとスケーラビリティが担保されている。今後はAgent 365への統合拡張と、Microsoft Marketplaceでの提供も計画されている。 なぜこれが重要か 「AIツールを使いたいが、既存のワークフローを変えたくない」——これは多くの日本企業でよく耳にする声だ。新しいSaaSを導入するたびに発生するシングルサインオンの整備、情報セキュリティ審査、利用規約の確認、社員へのID払い出し……この摩擦コストが、AI活用の普及スピードを著しく低下させてきた。 今回の提携はその摩擦を根本から取り除く試みだ。M365テナントにすでに存在するユーザーが、追加手続きなしにエージェント機能を利用できるモデルは、IT管理者にとっても業務管理者にとっても導入障壁が低い。 さらに重要なのは、Microsoft Marketplaceを通じた展開という設計方針だ。これはGenspark単体の話にとどまらず、「Microsoftが自社プラットフォームを外部AIエージェントに開放した」という方向性の表れでもある。エコシステムとして機能し始めれば、今後さらに多くのエージェントがM365内に統合されてくることが見込まれる。 実務での活用ポイント IT管理者へ: まずMicrosoft Marketplaceでのアプリ管理ポリシーを見直す機会として捉えたい。今後Marketplace経由のエージェント統合が増えるにつれ、管理コンソールでの可視性と承認フローの整備が重要になる。組織ごとに「許可するエージェントのホワイトリスト管理」の設計を今から考えておくとよい。 エンジニア・プロセスオーナーへ: Excel連携は特に注目したい。「データに自然言語で質問できる」体験が社内に広まると、BIツールへのアクセス要求や分析作業への依頼のあり方が変質する可能性がある。ユーザーが自己解決できる範囲が広がれば、開発者へのアドホックなデータ依頼も減るかもしれない。 セキュリティ担当へ: Azure上での構築・デプロイというアーキテクチャは、既存のMicrosoft Purviewや条件付きアクセスポリシーとの親和性を示唆している。ただし、正式な統合仕様の公開を待って、データ境界の確認は必ず行うこと。プレスリリースの文言だけで導入判断しないよう注意が必要だ。 筆者の見解 M365エコシステムが外部AIエージェントに開かれていく方向性は、歓迎したい動きだ。 これまで「M365の中で完結する」というのは、選択肢が限られることを意味していた。しかし現実には、用途や求める精度・スタイルによって複数のAI選択肢を使い分けたいというニーズは企業に確実に存在する。TeamsやOutlookといった定型業務を担うAIと、文書作成・データ分析などの知的労働を担うエージェントが、同一のワークスペース内に共存できる環境になるなら、それは選択肢の広がりとして素直に評価できる。 Microsoftが外部パートナーをプラットフォームに取り込む戦略を加速させていることは、長期的な競争力の観点からも合理的だ。AIモデルの差異化よりも、エコシステムとしての統合力で価値を提供するアプローチは、Microsoftが最も得意としてきた戦い方でもある。この方向性は正しい。 一方で、実際の機能クオリティと運用成熟度については、プレスリリース時点では判断できない。Agent 365への統合やMarketplace展開が具体化したタイミングで、実際に自社環境で試してみるのが正しいアプローチだろう。「エンタープライズグレード」という言葉の中身を、自分たちの手で検証することを怠ってはいけない。 M365は統合して使うことで初めて真の価値を発揮するプラットフォームだ。エコシステムが豊かになればなるほど、その恩恵は利用者全体に広がる。今回の提携が、その確かな一歩になることを期待している。 出典: この記事は Genspark Announces Global Strategic Partnership with Microsoft to Embed AI Agents Across Microsoft 365 and Agent 365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Purviewの2026年4月アップデートが公開された。データガバナンス、データ損失防止（DLP）、データセキュリティ調査の各領域にわたって実務直結の機能強化が並んでいる。特に「大量データ資産の一括操作」と「Just-In-Time（JIT）保護の整備」は、Purviewを本格運用しているチームには見逃せないポイントだ。 データガバナンス：バルク操作でカタログ運用の手間を大幅削減 Unified Catalogにバルクインポート・編集・移動機能が追加された（プレビュー）。具体的には以下が一括操作可能になる。 データプロダクトの一括作成 クリティカルデータエレメントの一括作成 用語集（Glossary）の一括作成・編集 用語集のガバナンスドメイン間の一括移動 これまで数百〜数千のデータ資産を持つ企業では、カタログ構築作業が「手作業の泥沼」になるケースが多かった。バルク操作の提供は地味ながら、現場への影響は大きい。 あわせて、クラシックなMicrosoft Purviewデータガバナンス経験から用語集をUnified Catalogへ一括移行するプロセスがプレビュー公開された。レガシー環境からの移行を進めている組織には朗報だ。 アドバンスドリソースセット機能はGA（一般提供）となり、全顧客に展開中。価格は既存のクラシックデータガバナンスの料金体系に準拠する。 オンプレミスのOracle/SQL Serverもデータ品質評価対象に Data Quality機能がオンプレミスのOracleおよびSQL Serverに対応（プレビュー）。Kubernetesクラスターをホストとしてオンプレランタイムを構成することで、データが組織外に出ることなくスキャンが実行できる。クラウド移行の途上にある日本の大手企業にとって現実的な選択肢が増えた。 データ品質しきい値アラートも追加（プレビュー）。ルール単位・データ資産単位でスコアが基準を下回った際に通知を受け取れるようになった。品質管理の自動化に向けた基盤が着実に整ってきている。 DLP：JIT保護の整備とモバイル対応拡充 Just-In-Timeドキュメントが再構成 JIT（Just-In-Time）保護のドキュメントが整理・再構成された。「はじめに」記事がデプロイメントと設定手順に特化し、別途「JITとは何か」を扱う概念解説記事が新設された。ドキュメントの改善は地味に見えるが、設計・運用担当者が全体像を把握しやすくなるという意味で実務上の価値は高い。 非管理クラウドアプリ向けDLPに「URL条件」が追加 管理対象外のクラウドアプリに対するDLPポリシーで、「URLに指定テキストを含む」条件が利用可能になった（プレビュー）。特定のサービスや部署向けURLにのみポリシーを適用したり、逆に除外したりといった細かいスコーピングができるようになる。 ブラウザ・ネットワークDLPにメール通知機能 DLPポリシーによってアクティビティがブロックされた際、エンドユーザーにメールで通知する機能が追加（プレビュー）。10分間のバッチウィンドウで通知をまとめて送ることで、過剰なメール送信を防ぐ設計になっている。ユーザーへの即時フィードバックは行動変容を促す上で重要で、「気づかずにブロックされ続ける」状況の解消に直結する。 Outlookモバイル・macOS向けポリシーヒント対応 Outlook for Android、iOS、macOSでのDLPポリシーヒントについて、対応条件・過剰共有ダイアログ・オーバーライド機能を網羅したリファレンス記事が公開された。モバイルワークが標準となった今、PC以外のデバイスでの一貫したDLP体験は必須要件だ。 Collection Policiesに秘密度ラベル条件が追加 コレクションポリシーが秘密度ラベルを条件としてサポートするようになった（プレビュー）。ブラウザおよびネットワーククラウドアプリの検出をラベル単位でスコープできる。機密ラベルを軸にした統合的なデータセキュリティ設計が一歩進んだ。 実務への影響 日本のエンジニア・IT管理者が注目すべき点を整理する。 ① カタログ構築を後回しにしている組織は今がやり時 バルク操作の追加によって、「構築コストが高すぎて手が出せない」という言い訳が薄くなった。一括インポートが使えるなら、まずスコープを絞って試験導入することを検討したい。 ② オンプレOracleが対象に入ったことの意味は大きい 日本の金融・製造・公共セクターにはOracle依存が根強い。クラウドファーストの文脈から外れていると感じていた組織でも、Purviewのデータ品質管理の恩恵を受けられる環境が整いつつある。 ③ JIT保護はゼロトラスト設計の文脈で再評価を JITのドキュメント整備は、「実装できていない」「どこから手をつければいいかわからない」という声への応答だ。これを機にゼロトラストアーキテクチャ全体の中でのJITの位置づけを改めて検討してほしい。 ④ エンドユーザー通知の設計はポリシー効果に直結する DLPの「ブロックしたが誰も知らない」状態は、セキュリティとしての機能を果たしていない。メール通知機能をうまく使い、ポリシーの存在をユーザーに認識させることで、組織全体のセキュリティ成熟度が上がる。 筆者の見解 Purviewはここ1〜2年で「ようやく使えるレベルになってきた」というのが率直な評価だ。バルク操作やオンプレ対応は、長らく現場から寄せられてきた要望に対する真っ当な回答だと思う。 とりわけJIT保護のドキュメント整備は、機能そのものより意味があると捉えている。JITは「正しいアクセス管理の考え方」であり、常時アクセス権を付与し続けることは特権管理における最大のリスクだ。機能が存在しても使われなければ意味がない。ドキュメントを丁寧に整えてデプロイのハードルを下げようとする姿勢は、正しい方向だ。 ただ、これらの機能がプラットフォーム全体として統合されて初めて価値が出る、という点は強調しておきたい。Purviewを単体ツールとして部分的に使うだけでは、コストに見合った効果は得られない。Entra IDの条件付きアクセスや秘密度ラベルの設計と一体で考えてこそ、「データを保護する仕組み」として機能する。 日本のエンタープライズには、クラウドセキュリティのレイヤーが混在していて全体として整合が取れていない環境がまだ多い。Purviewのアップデートを追いかけるだけでなく、それを組み込む「設計のアップデート」を並行して進めることが、今最も重要な取り組みだと考えている。 出典: この記事は What’s new in Microsoft Purview | Microsoft Learn の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 CopilotのResearcherエージェントが、AnthropicのClaudeモデルを選択できるようになった。「とりあえずCopilotに聞く」という単一モデル前提の運用から、用途に応じてモデルを使い分ける時代への移行が、Microsoft自身のプラットフォームの中で始まりつつある。 ResearcherエージェントとClaude統合の概要 ResearcherはMicrosoft 365 Copilotに内蔵されたエージェント型アシスタントで、ウェブ上の情報と社内ドキュメントを横断して情報収集・分析・要約を行う機能を持つ。今回のアップデートでは、この処理エンジンとしてAnthropicのClaudeモデル（Claude Sonnetを含む）が選択肢に加わった。 利用方法はシンプルだ。 Microsoft 365 Copilotアプリ（デスクトップ版またはWeb版）にサインイン チャット画面の「Agents」からResearcherを選択 モデル選択でClaudeを指定 ただし注意点がある。Claudeが有効なのはアクティブセッション中のみで、セッションを閉じるかアプリを終了すると自動的にデフォルトモデルに戻る。モバイルアプリはサポート対象外となっている点も覚えておきたい。 IT管理者が確認すべき設定 この機能を組織内で解放するには、管理者側でいくつかの設定が必要だ。 AnthropicのサブプロセッサーとしてのOnboarding 最も重要なのが、Microsoft 365管理センターでAnthropicをサブプロセッサーとして許可する設定だ。デフォルトでは無効になっているため、管理者が明示的に有効化しない限りエンドユーザーはClaudeを選択できない。 データガバナンスの観点では、Microsoft Purviewのコンプライアンスフレームワークとの統合およびCopilot採用ダッシュボードが機能し、データの取り扱いや利用状況を管理者が継続的に監視できる仕組みが整備されている。「使わせる前にガバナンスの枠を作れ」という原則に沿った設計だ。 段階的ロールアウトへの対応 Microsoftのアナウンスによれば、この機能は段階的にロールアウト中であり、現時点ではすべての組織で利用可能ではない。自組織への展開状況は管理センターで確認するのが確実だ。 実務への影響：「Copilot一択」からの脱却 この変更がIT現場にもたらす最大の意味は、単一モデルへの依存からの脱却だ。 Teamsの議事録整理やOutlookの定型メール対応はデフォルトモデルに任せつつ、より深い調査や複雑な情報分析が必要なリサーチタスクには別モデルを活用するという使い分けが、公式にサポートされる方向に動き始めた。 管理者にとっては「何がどこで動いているか」を把握するガバナンス負荷が上がる面もあるが、Purview統合によって可視化できる部分は増える。まずは管理センターの設定を整え、ガバナンスの仕組みを先に作ってから展開するのが堅実な進め方だ。 筆者の見解 Microsoftがプラットフォームとしての強みを活かしながら、複数のAIモデルを取り込む方向に舵を切ったことは、評価に値する動きだ。 AI領域において「自社モデルだけ」という選択は、もはやユーザーの信頼を得にくい時代になっている。Microsoftにはブランド・インフラ・エコシステムという圧倒的な強みがある。それを活かして複数のモデルを柔軟に使い分けられる「プラットフォーム」としての地位を確立できれば、個別モデルの性能差を超えた価値を提供できるはずだ。 この数年でCopilotに対するユーザーの期待値は大きく揺れ動いた。「標準機能では物足りない」という声は現場でよく耳にする。だからこそ今回の取り組みには注目している。重要なのは利用できるモデルの幅が広がることそのものより、「選べる自由をユーザーに与える」設計思想にMicrosoftが踏み込んだという点だ。Microsoftには正面からこの変革で勝負できる力がある。その力を存分に発揮してほしい。 日本企業の多くはまだM365の統合的な活用に至っていない。この機能を活かすためにも、管理センターの設定確認とPurviewによるガバナンス確立を先に進めておくことをお勧めしたい。機能が増えるほど、制御の仕組みを先手で作っておくことが重要になる。 出典: この記事は Use Claude with Researcher in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

気づかれずに会議室に座り続けるAI 先月のプロジェクトキックオフ会議を思い出してほしい。参加者欄に「Meeting Notetaker」という名前のアカウントが表示されていなかっただろうか。それがRead.aiなどのサードパーティAIボットだったとしたら——見積もり金額も、NDA関連の話も、すべて外部クラウドに送られている可能性がある。 誰も「AIに議事録を取らせる」とは決めていない。ただ、誰も「取らせない」とも決めていなかった。だから、それが起きた。 Microsoftは2026年5月、この状況を変える機能を展開する。IT管理者が今すぐポリシーを決めなければならない理由がここにある。 何が変わるのか——MC1251206の概要 Message Center通知 MC1251206 として告知されたこの新機能は、Teamsミーティングへ参加しようとするサードパーティAIボットを検出するポリシーだ。展開スケジュールは以下の通り。 Targeted Releaseテナント: 2026年5月中旬 Worldwide GA・GCC: 2026年6月上旬〜中旬 動作の仕組み サードパーティボットがTeams会議への参加を試みると、ロビー画面に 「Suspected threats（疑わしい脅威）」 セクションが現れ、「Unverified trust（未確認の信頼性）」 インジケーターとともに表示される。ボットは人間の参加者とは別に区分けされ、主催者が明示的に「許可・拒否・削除」を選択しなければ入室できない。 Teams管理センターからはテナント全体のポリシーを設定でき、デフォルトは「検出されたボットは主催者の承認が必要」となる。重要な点として、検出機能はすべてのテナントでデフォルト有効——管理者が何もしなくても有効になる。 ただし、Microsoftも認めているように、ボットの挙動によっては検出をすり抜けるケースがある。これは「完璧なシールド」ではなく、「ガバナンスの起点」と理解するのが正しい。 なぜこれが「ただの技術設定」ではないのか AIミーティングボットの本質的なリスクを整理する。 Read.aiのようなツールは、単に文字起こしをするだけではない。要約・アクションアイテム抽出・話者識別・センチメント分析——これらすべてを行い、Microsoft 365テナントの外部にあるクラウドプラットフォームへ同期する。 そのデータは： ボット運営者のプライバシーポリシーに従って管理される（自社ポリシーではない） 自組織が承認していない法域のサーバーに保存される可能性がある ボットを設定した人物（自社社員かもしれないし、外部参加者かもしれない）がアクセスできる Teamsの会議では何が話されているか。契約前の暫定見積もり、人事評価の議論、役員の戦略セッション、法務レビュー——これらがすべて「外部クラウドの議事録」として存在することになる。 実務での活用ポイント——管理者が5月前にやるべきこと 技術設定は30分で終わる。問題はその前の「ポリシー決定」だ。以下の5つの問いに答えてからTeams管理センターを開くこと。 ① 自組織は会議録音・文字起こしについて何を決めているか すでに社内規定があれば、AIボットもその延長として扱える。なければ今が整備の機会だ。 ② サードパーティAIツールの利用を完全禁止するか、条件付きで認めるか 禁止一択は必ず抜け穴を生む。「認可済みツールリスト方式」で合法的な使用経路を確保しつつ、非認可ボットをブロックする構造が現実的だ。 ③ 主催者の判断に任せるのか、テナント全体で統一するのか 機密度の高い会議と日常的な進捗会議では要件が異なる。会議の種別・部門別のポリシー設計を検討する。 ④ 外部参加者が持ち込むボットはどう扱うか ゲストリンク経由で外部から参加したボットが最もリスクが高い。ゲスト参加者のボット持ち込みを制限する設定を優先的に検討する。 ⑤ インシデント発生時の対応手順は決まっているか 「未承認ボットが入室していた」と後から発覚したとき、誰が何を確認してどこへ報告するかを事前に決めておく。 筆者の見解 この機能は、Teamsに長らく必要とされていたものだ。「気づいたら録音されていた」という状況は、ガバナンス不在の典型であり、コンプライアンス的にも見過ごせない。Microsoftが検出機能をデフォルト有効で展開する判断は評価したい。 一方で、この機能の価値はポリシー決定の質に依存するという点を強調したい。「とにかく全部ブロック」でも「とにかく全部許可」でも、どちらもガバナンスではなく「当て推量」に過ぎない。技術設定の前に組織としての意思決定がある——この順番が守れる組織とそうでない組織の差が、5月以降に可視化されるだろう。 日本企業の現場では、「禁止すれば安全」という発想が根強い。しかし禁止アプローチは必ず失敗する。禁止されたユーザーは抜け道を探し、管理されないシャドーITが増えるだけだ。正しいアプローチは「公式に安全な使用経路を提供し、非公式経路を検出・制限する」こと。今回の機能はまさにその後者を担う。前者——つまり承認済みのAI活用パスを社内に整備する——はIT部門の宿題として残る。 AIが会議に参加することの是非ではなく、誰が、どのAIを、どの条件で使うかを組織が決める——その当たり前の問いに向き合う機会として、この展開を活用してほしい。 出典: この記事は Teams Bot Detection Policy Playbook: Prepare for May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年、Microsoftはここ10年で最大規模のライセンス体系の見直しを実施する。新SKU「Microsoft 365 E7 Frontier Suite」の登場、AIエージェント管理の中枢「Agent 365」の正式提供開始、そして7月1日からのグローバル価格改定――これらが同時に押し寄せる年だ。何をどう準備すればよいか、順を追って整理する。 M365 E7「Frontier Suite」が登場する意味 2026年5月に正式提供が始まるM365 E7は、Microsoft 365 E5・Copilot・Agent 365を単一SKUにまとめた最上位スイートだ。「Work IQ」と呼ばれる統合エンジンを基盤に、Entra Suite・Defender・Intune・Purviewとの深い連携が特徴とされている。 これまでE5を使っている企業がCopilotやAgent 365を追加しようとすると、ライセンス管理が煩雑になりがちだった。E7への統合はその整理という意味では合理的な方向性だ。ただし「E3→E5→E7への移行コスト試算」が必要になるため、次回更新前に現行ライセンス構成の棚卸しは必須となる。 Agent 365 GAとAIエージェントのガバナンス Agent 365はMicrosoftおよびエコシステムパートナーが提供するAIエージェントを横断的に管理するコントロールプレーンとして2026年5月に正式提供が始まる。スタンドアロンでは月額$15/ユーザーでも提供予定だ。 注目すべきは「ガバナンス・可観測性・セキュリティ」の3点が明示されていることだ。AIエージェントが実際の業務データに触れる範囲が広がる中、どのエージェントが何にアクセスできるかを明示的に管理する仕組みは本質的に重要になっている。Non-Human Identity（NHI）の管理という観点から見ると、Agent 365はいわば「エージェント向けIDガバナンス基盤」として機能する可能性がある。AIエージェントを展開済みまたは検討中の企業は、Agent 365の管理スコープを早めに確認しておきたい。 7月値上げ：更新タイミングを今すぐ確認 2026年7月1日より、M365商用サブスクリプションの価格がグローバルで引き上げられる（国内市場向けの調整も行われる予定）。重要なのは7月1日より前に更新を完了させた契約は現行価格を維持できる点だ。 契約更新が7月以降に到来する企業は、前倒し更新が経済的かどうかを今すぐ試算すべきだ。数%の値上げでも、大規模テナントでは無視できないインパクトになる。 サポート終了（EOS）の波 2026年は複数の主要製品がEOSを迎える。実務への影響が大きいものを挙げる： SQL Server 2016：2026年7月15日に延長サポートが終了。以降は有料ESU（Extended Security Updates）の購入か、SQL Server 2019/2022への移行が必要 Azure Application Gateway v1：2026年4月28日で廃止済み。まだ稼働中の環境は即座にv2/WAF v2への移行対応が必要 Windows Server 2012 R2 ESU：ESU期間終了。オンプレミスで稼働中のサーバーは優先的に対処が必要 Office LTSC 2021：サポート終了が近づいており、クラウド移行の検討が必要 特にSQL Server 2016は多くの基幹システムや業務パッケージが依存しているため、インベントリの洗い出しとESUコスト対移行コストの試算を急ぎたい。 セキュリティ関連の変更：見落とし厳禁 2026年3月にはセキュリティ面でも重要な変更が実施された： Entra IDのサービスプリンシパルレス認証の廃止：レガシー認証が終わり、正式なサービスプリンシパル登録が必須化。CMDBへの登録と修正計画が必要になる 条件付きアクセス「承認済みクライアントアプリを要求」コントロールの廃止：IntuneのApp Protection（MAM/MDM）との整合を前提とした再設計が必要 どちらも「今動いているから大丈夫」では通らなくなるタイプの変更だ。ゼロトラスト移行を進めている組織では、これらを機に古い認証構成を一掃するよい機会でもある。 実務への影響 日本のIT管理者・SAMチームが今月中に動くべき優先タスクを整理する： 契約更新日の確認：7月以前に更新できるなら、前倒し更新のコスト試算を今すぐ実施 SQL Server 2016のインベントリ取得：ESU購入 vs. バージョンアップのコスト比較を急ぐ Azure Application Gateway v1の残存確認：廃止日（4月28日）は既に到来。まだ稼働中ならすぐ移行を Agent 365の管理対象エージェント棚卸し：どのエージェントが何のデータにアクセスしているかを明示化する準備 E3→E5→E7の移行コストシミュレーション：次回更新タイミングに向けた費用対効果の試算 筆者の見解 E7という形でE5・Copilot・Agent 365をひとつのSKUにまとめる動きは、Microsoft 365を「統合プラットフォームとして使う」という本来のコンセプトに沿った判断だと感じる。バラバラに追加ライセンスを積み上げるより、統合SKUで全機能を活かしきる方が、特に大規模テナントでは結果的に合理的なケースが多い。 ...

SharePoint Framework（SPFx）の開発チームから、2026年4月のロードマップ更新が発表された。バージョン1.23がリリース候補（RC）に到達し、5月上旬の正式リリース（GA）が見えてきた。さらに次のバージョン1.24ではAI機能の追加が予告されており、SPFxを活用する日本の開発現場にとっても注目すべきアップデートが続いている。 SPFx 1.23 RC の主な新機能 リストビューのコマンドセットにグルーピング機能追加 SharePointリストやドキュメントライブラリのコマンドセット（コマンドバーに表示されるカスタムボタン等）に、グルーピング機能が追加される。複数のコマンドをグループとして整理・表示できるようになり、UIの整理やユーザー体験の向上に直結する改善だ。 SPFx CLI のプレビューと OSS 化 注目度が高いのが、既存のYeomanジェネレーターに代わる新しいSPFx CLIのプレビュー公開と、テンプレートのオープンソース化だ。 これまでSPFxプロジェクトの雛形生成はYeomanに依存していたが、新CLIでは企業独自のテンプレートやカスタマイズを組み込める仕組みになる。開発標準のガバナンスを保ちながら、自社に最適化されたプロジェクト構造を一発生成できる点は、エンタープライズ開発において大きな意義がある。テンプレートがOSSとして公開されることで、コミュニティによる改善や日本語対応のカスタマイズも現実的になってくる。 npm 脆弱性への対応 今回のリリースは当初の予定より遅れたが、理由は「npm auditで報告された脆弱性への対処」を優先したためとのこと。セキュリティ品質を担保してからリリースする判断は、エンタープライズ製品として正しい姿勢だ。 1.24 では AI 機能が登場予定 先を見据えると、SPFx 1.24（パブリックプレビュー予定）ではAI を活用した新しい開発者向け機能が搭載される見込みだ。詳細はまだ明かされていないが、SharePointやMicrosoft 365ソリューション内で「インテリジェントで支援的な体験」を構築するための機能と説明されている。 React 18サポートも2026年6月を目標に計画されており、モダンな開発スタック全体が着実に整備されつつある。 四半期リリースサイクルへの移行 もう一つ見逃せないのが、リリースサイクルの四半期化だ。今後は四半期ごとに計画的なリリースを行う方針へ移行する。 開発現場にとって、フレームワークのアップデート時期が読めることは非常に重要だ。プロジェクト計画、検証期間の確保、デプロイタイミングの調整——これらすべてが「いつリリースが来るか分からない」状態では立てにくい。四半期サイクルへの移行は、現場の予測可能性を大幅に高める判断として評価できる。 実務への影響 SPFxで社内ツールや業務アプリを開発・保守しているチームは、以下の点を今すぐ確認してほしい。 1.23 RC の検証: 既存ソリューションが1.23で問題なく動作するか確認する良いタイミング。GA前に検証しておくことで、本番リリース後の移行がスムーズになる Yeoman からの移行計画: 新SPFx CLIはプレビューだが、先行して評価しておくことで、GA後の移行コストを下げられる 1.24 の AI 機能: 詳細公開後すぐに評価できるよう、自社のSharePoint活用シナリオの棚卸しをしておくと動きやすい 筆者の見解 SPFxのロードマップを見て感じるのは、Microsoftがエンタープライズ開発者との対話を着実に続けているということだ。四半期リリースサイクルへの移行は、開発者コミュニティから長年求められていたものであり、今回ようやくその方向に踏み出した。 CLIのOSS化も評価できる。テンプレートの標準化は「道のド真ん中を歩く」ための基盤になるし、企業独自の要件を反映したカスタマイズも可能になる——この両立は現実的で筋のいいアプローチだ。 1.24で予告されているAI機能は、まだ詳細不明ゆえ過大な期待は禁物だが、SharePointの文脈でAI支援をネイティブに組み込める仕組みができるなら、自社開発ポータルや業務ツールの可能性は広がる。追うべきアップデートになるだろう。 日本のIT現場では「SPFxは難しい」「Yeomanが辛い」という声をよく聞く。新しいCLIとテンプレートのOSS化は、そのハードルを下げる可能性を持っている。実際に試して、現場に合うかどうか検証する価値は十分にある。 出典: この記事は SharePoint Framework (SPFx) roadmap update – April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Intuneの「April 2026 In Development」リストが更新された。今回の目玉はマルチアカウントMAM（Mobile Application Management）の追加だ。複数のIntuneテナントを横断したモバイルガバナンスが可能になるこの機能は、グループ企業や多拠点を持つ日本の大企業にとって無視できない変化となる。早ければ来月から順次展開が始まる予定だ。 Intune「In Development」ページとは Microsoftは毎月、Intuneに今後追加される機能の一覧を「In Development」ページで先行公開している。単なる予告にとどまらず、IT管理者がヘルプデスクへの事前周知や社内ガイダンスの更新タイミングを計るための重要な情報源だ。このページを定期チェックする文化を組織に根付かせることが、Intuneを使いこなす第一歩といえる。 マルチアカウントMAMとは何か MAMは、デバイス全体を管理するMDM（Mobile Device Management）とは異なり、アプリ単位でポリシーを適用するアプローチだ。BYODシナリオで特に力を発揮し、個人所有のスマートフォン上でも業務データを安全に分離できる。 今回のマルチアカウントMAM対応が意味するのは、「複数のIntuneテナントにまたがったアプリ保護ポリシーの適用」だ。M&Aで複数テナントを抱えた組織や、グループ会社間でモバイル端末を融通している環境で、これまで個別対処していたポリシー管理が一元化に近づく。 実務への影響 IT管理者がすぐ動くべきポイントを整理する。 今週やること: 公式「In development」ページをブックマークし、毎月の更新を定期チェックする体制を作る ヘルプデスクチームへの変更通知フローを事前に確立しておく マルチテナント環境の組織は特に注目: 現行のMAMポリシーを棚卸しし、統合・簡素化できる箇所を洗い出す M&A後の統合プロセス中であれば、このタイミングでモバイル管理設計を見直すと後々の運用コストを大きく削減できる BYOD推進中の企業にとっても、マルチアカウント対応はユーザー体験の改善につながる。一台の端末で複数の組織アカウントを使い分けながら、それぞれのポリシーが適切に適用されるシナリオが現実的になる。 筆者の見解 IntuneはM365スイートの中でも着実に進化しているコンポーネントの一つだと感じている。今回のマルチアカウントMAM対応は、現実のエンタープライズ環境が複数テナントを持つという実態をようやく正面から受け止めた機能だ。「現場の複雑さに追いついてきた」という印象がある。 M365は統合して使うことで初めてその価値が発揮されるプラットフォームだ。Intuneをデバイス管理ツールとして単体で捉えるのではなく、Entra IDの条件付きアクセスやMicrosoft Defender for Endpointと組み合わせたゼロトラストアーキテクチャの文脈で設計することが、今後ますます重要になる。 機能追加のペースが速い分、「知らないと損をする」状況が続いているのも事実だ。In Developmentページを毎月チェックし、変更を先取りして備える体制を組織として持っているかどうかが、Intuneの活用度を大きく左右する。この情報を追いかける仕組みを作ることこそが、IT管理部門の競争力になる時代だと思っている。 出典: この記事は Microsoft Intune In Development for April 2026 is now available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

企業のセキュリティ運用において、DLP（Data Loss Prevention）アラートの「アラート疲れ」は長年の課題だ。毎日大量に飛んでくるアラートを一つひとつ確認し、本物のインシデントかどうかを判断する作業は、熟練のセキュリティアナリストでさえ消耗する。Microsoft は今回、この課題にAIエージェントで正面から向き合った。 Data Security Triage Agentとは Microsoft Purview の Data Security Triage Agent は、DLPアラートを受け取ると自動的にその内容を分析し、AI生成のサマリーと分類（カテゴリ）を付与するエージェントだ。今回の更新で、このエージェントの出力が Microsoft Defender XDR ポータルのDLPアラート画面に直接表示されるようになる。 セキュリティアナリストはこれまで、アラートの詳細を手作業で掘り下げ、どのユーザーが何を・どこへ・どのように送信しようとしたかを読み解く必要があった。Triage Agentはこのプロセスを自動化し、「このアラートはどういう事象か」「どの程度深刻か」を即座に把握できる形で提示する。 Defender XDRとPurviewの役割分担 注目すべきは、管理の場所が明確に分離されている点だ。 Defender XDR: アラートの確認とエージェントの初期デプロイ Microsoft Purview: エージェントの詳細設定（カスタム指示）、一時停止・無効化、利用状況モニタリング エージェントをまだデプロイしていないアナリストは、Defender XDR のDLPアラート画面からそのままデプロイを開始できる。既存のDLPポリシーや enforcement には一切変更がなく、エンドユーザーへの影響もない。 展開スケジュール フェーズ 時期 パブリックプレビュー 2026年4月初旬〜中旬（展開中） 一般提供（全世界） 2026年8月中旬〜下旬 プレビューは既に開始されているため、Purview ライセンスを持つ組織は今すぐ試せる状況にある。 実務への影響 セキュリティ運用チーム（SOC）向けの実務ポイントを整理する。 即座に試せる準備チェックリスト： ロール確認: DLPアラートをトリアージするアナリストが適切な権限を持っているか見直す（Purview + Defender XDR 両方の権限が必要） エージェントデプロイ: Defender XDR のDLPアラート画面、または Purview ポータルからエージェントを有効化する カスタム指示の設定: Purview 側でエージェントへのカスタム指示を設定し、自組織のポリシーや業務文脈を反映させると精度が上がる 内部手順書の更新: トリアージフローに「AI生成サマリーの確認」ステップを組み込む 日本の企業では、DLP運用を少人数のチームが担っているケースも多い。AIサマリーが「一次スクリーニング」を担ってくれることで、人間のアナリストはより高度な判断に集中できる。アラートを全件手作業で確認するという非効率なフローを改める絶好のタイミングだ。 筆者の見解 セキュリティ運用は正直に言えば「好き」な領域ではない。細かい設定と終わりのないアラート対応の繰り返し——しかし技術的な興味は尽きない。そういう立場から見ると、今回の取り組みは方向性として非常に正しい。 DLPアラートのトリアージは、典型的な「人間がやらなくていい作業」の筆頭だ。パターンを読んで、文脈を整理して、重要度を判断する——これはAIが得意とするタスクそのものである。セキュリティの本質的な判断（何をポリシーとするか、インシデントにどう対応するか）は人間が担い、一次処理はAIに任せる。この分業が実現するだけで、限られたセキュリティ人材の生産性は大きく変わる。 一方で、AIサマリーへの過信は禁物だ。エージェントはあくまで「整理してくれる補助役」であり、最終的な判断は人間が行う必要がある。特にプレビュー段階では、サマリーの正確性を自分の目で検証しながら使うことを強くすすめる。「AIが問題なしと言ったから見なかった」という事態は絶対に避けなければならない。 ...

リモートワークが定着して数年が経つが、「テレワーク中の生産性をどう担保するか」という問いはいまも管理職を悩ませ続けている。今回取り上げるのは少し特殊なケースだ。「自分だけが参加している会議を意図的にスケジュールし、在席しているように見せかけているのではないか」——そんな疑念を持つ経営層からの依頼に応えるべく、PowerShellを使ってTeamsのオンライン会議レポートを生成し、一人参加の会議を特定する方法が紹介された。 なぜTeamsの会議データが取れるのか Microsoft 365の管理者は、Teams会議のメタデータ——開催者、参加者数、開始・終了時刻、会議の種別——をMicrosoft Graph APIやExchange Online PowerShellモジュールを通じて取得できる。会議カレンダーアイテムに紐づく情報と、実際に参加したユーザーのテレメトリを組み合わせることで、「スケジュールされていたが誰も参加しなかった会議」「主催者のみが参加した会議」を分類することが可能になる。 PowerShellによる実装の流れ おおまかな実装ステップは以下の通りだ。 Exchange Online PowerShellへの接続: Connect-ExchangeOnline でテナントに接続する 会議レポートの取得: Unified Audit Log または Graph API の /communications/callRecords エンドポイントを利用して、指定期間内のTeams会議ログを抽出する 参加者数でフィルタリング: 参加者が1名（主催者のみ）の会議を抽出するフィルタを適用する 結果のエクスポート: Export-Csv でスプレッドシートに出力し、管理者や人事部門が確認できる形にする 注意点として、Graph APIの callRecords は一定の保持期間（通常60日）があり、組織のデータポリシーによってアクセス可否が異なる。テナントの監査ログが有効になっているかを事前に確認しておく必要がある。 実務での活用ポイント 日本のIT管理者がこのスクリプトを導入する際にポイントとなる点をまとめる。 監査ログの有効化を最初に確認: 多くの中小テナントでは監査ログがデフォルトで無効になっているケースがある。Microsoft 365コンプライアンスセンターで Set-AdminAuditLogConfig を確認しよう 一人会議が必ずしも「サボり」ではない: 1対1の練習、録画目的、テスト配信など、正当な理由の一人会議も存在する。単純な件数で判断せず、開催時間帯・頻度・当該ユーザーの業務内容と照らし合わせた文脈判断が必要 Human Resourcesと連携した運用プロセスを先に決める: ツールだけ作って「さあ使おう」では意味がない。どの閾値を超えたら誰に報告し、どう対処するかを事前に人事・法務と合意しておくこと 従業員へのクリアな開示: 日本の労働法的観点からも、業務用デバイス・サービスの利用状況を監視している旨を就業規則や利用ポリシーに明記することが前提となる 「在席偽装」問題の本質 テクニカルな話を少し離れると、「一人会議スキャナー」が必要になる状況そのものが、マネジメントの設計ミスを示唆している。アウトプットで評価できていれば、会議の在籍状況を見張る必要はない。ツールの整備と並行して、成果ベースの評価体系を見直す契機にしてほしい。 筆者の見解 技術的には非常にシンプルに実装できる内容だが、「この問いが立てられること自体」に注目したい。 TeamsをはじめとするMicrosoft 365の管理ツールは、管理者が組織の利用状況を可視化するための優れたAPIエコシステムを持っている。その点はしっかり評価したい。PowerShell一本で会議ログを引き出してCSVに落とせる——これはM365の統合プラットフォームとしての強みが生きている場面だ。 一方、「在席確認のための一人会議」という問題が経営課題として上がってくること自体、リモートワーク運用の設計にほころびがあるサインだ。テクノロジーで監視を強化するよりも先に、何をアウトプットとして評価するかを明確にする方が根本的な解決になる。ツールは問題を「見える化」するが、「解決」はしない。 Microsoft 365はこういった分析・可視化の基盤として使い倒せる余地がまだまだある。組織の生産性可視化という文脈でPowerShellとGraphを組み合わせた管理施策を整備しているIT管理者は、引き続きこの方向性を深掘りする価値がある。 出典: この記事は How to Report Specific Teams Online Meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが企業システムへ次々と展開される時代が到来した。Microsoft社内では「Agent 365」を中核に据えたAIエージェント管理基盤を構築し、EntraによるID統合とDefenderによるセキュリティ監視、そして統合ダッシュボードによる可観測性確保という三位一体のアプローチを実践している。この社内実装事例は、エンタープライズでのAIエージェント展開を検討する日本のIT組織にとって、具体的な設計指針となるはずだ。 Agent 365とは何か Agent 365は、Microsoft 365エコシステム上で動作するAIエージェントを統合管理するためのガバナンスプレーンだ。個々のエージェントにIDを付与し、アクセス権限を制御し、動作ログを記録する。単なるCopilot機能の延長ではなく、「エージェントをNon-Human Identity（NHI）として扱う」という考え方が根底にある。 これは重要な設計思想の転換だ。これまで企業のID管理といえばユーザーアカウントと一部のサービスアカウントが主役だったが、自律的に動作するAIエージェントが増えるにつれ、それらを人間のユーザーと同等の厳密さで管理しなければセキュリティが成立しなくなる。 EntraとDefenderによるID・セキュリティ統合 Microsoft Entraとの統合により、エージェントは通常のユーザーやサービスプリンシパルと同じアイデンティティ管理フレームワーク上に乗る。条件付きアクセスポリシーの適用、アクセスレビューの実施、Privileged Identity Management（PIM）によるJust-In-Timeアクセスなど、既存の制御メカニズムをそのままエージェントに適用できるのは大きな強みだ。 Microsoft Defender for Cloud Appsとの連携では、エージェントの通信パターンや操作ログを継続的に分析し、異常な振る舞いを検出する。エージェントが想定外のデータにアクセスしたり、不審な処理を実行した場合に即座にアラートを発報できる体制であり、インサイダーリスク管理と同じ品質基準をAIエージェントにも適用する姿勢は評価に値する。 統合ダッシュボードによるエージェント可観測性 管理者が全エージェントの状態を一覧できる統合ダッシュボードは、運用現場で特に価値が大きい。どのエージェントがどのユーザーに利用されているか、どのデータソースにアクセスしているか、直近でエラーが発生していないかをリアルタイムで把握できる。 クラウドネイティブシステムでは「可観測性（Observability）」の確保が当たり前になっているが、AIエージェントに対しても同じ品質基準を適用するこの設計は、エージェントを「ブラックボックスとして野放しにしない」という明確なコンセプトの表れだ。 実務への影響 日本のエンタープライズ環境でAIエージェントを展開する際、今すぐ検討すべきポイントが3つある。 1. NHIの棚卸しを今すぐ始める すでに組織内には多数のサービスアカウント、APIキー、自動化スクリプトが存在するはずだ。AIエージェント導入前に現状のNHI全体を把握し、管理台帳を整備しておくことが、後のガバナンス設計を大幅に楽にする。「あとで整理しよう」と後回しにすると、エージェントが増えてから収拾がつかなくなる。 2. Entraへの一元化が前提条件 Agent 365のID統合はEntraを前提とする。オンプレミスのADやサードパーティのIDプロバイダーをそのまま使い続ける環境では、統合管理の恩恵を受けにくい。M365移行の優先度を上げる理由がまた一つ増えたといえる。 3. 「最小権限」を設計段階から組み込む エージェントに広めの権限を与えておいて後から絞るのではなく、設計時点から必要最小限のスコープでロールを定義する。後から権限を絞ることは組織的な摩擦が大きく、現場の反発も生みやすい。最初から絞っておくのがはるかに楽だ。 筆者の見解 今回のAgent 365ガバナンス基盤は、Microsoftが自社の課題をそのまま製品設計に反映させた「社内ユースケース駆動型」の好事例だと思う。エンタープライズ向けプラットフォームを展開する企業が自ら最大の実験場になるのは、技術の信頼性を高める上で非常に効果的なアプローチだ。 特にNon-Human IdentityをEntraのフレームワークに統合した点は理にかなっている。AIエージェントが業務自動化の主役になるほど、そのIDと権限を人間と同じ厳密さで管理する必要が増す。ボトルネックは常に「人間の関与」であり、NHIとしてのエージェントを適切に管理できて初めて、本当の意味での業務自動化が実現する。その現実に正面から向き合った設計だ。 一方で、ガバナンス基盤がどれだけ整っても、エージェント自体が業務の現場で実際に役立つ体験を提供できなければ「形だけの整備」で終わる。管理の仕組みと、エージェントが日々の業務に定着する体験の両方を同時に磨いていく必要がある。その両輪がかみ合ったとき、M365は統合プラットフォームとしての本来の価値を発揮できるはずだ。Microsoftにはその実力が十分にある。今後の展開を期待を込めて注目したい。 出典: この記事は Shaping AI management at Microsoft with Agent 365 and Copilot controls の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アクセンチュアがMicrosoft 365 Copilotを全従業員74万3,000人に展開したと発表した。ロールアウトを開始した2023年8月から約3年で、グローバル120カ国に展開するコンサルティング大手の全社員がAIアシスタントを使う環境が整ったことになる。Microsoftが公式に認めた史上最大規模のCopilot企業導入事例だ。 驚異の数字——何が本当に起きたのか 発表された数値は印象的だ。 月次アクティブ利用率：89%（約20万人の調査ベース） 97%の従業員が定型業務を最大15倍速く完了できると回答 53%増加した「生産性に顕著な改善を感じた」という回答割合 **84%**が「ツールが消えたら深刻に困る」と回答 数字だけ見ると理想的な展開事例だ。ただし注目すべきは、この数値が「ライセンスを配布しただけ」で得られたものではないという点だ。 成功の鍵は「段階的展開」と「役割別カスタマイズ」 アクセンチュアのCIOであるトニー・ルラリス氏が強調したのは、展開プロセスへの徹底的な投資だ。 まず2023年8月に数百名のシニアリーダーへの限定テストから始め、数カ月で2万人規模に拡大。全社展開にあたっては以下の仕組みを構築した。 シニアリーダー向け1on1トレーニング: 「どう使うか」ではなく「どう価値を出すか」を具体的に示す Viva Engageを活用した社内ナレッジシェア: 成功事例を横展開し、自己実験を促進 部門ごとの活用ブループリント作成: 一律の使い方を押し付けず、職種ごとの最適解を定義 特に注目すべきは「一律メッセージは通用しない」という教訓だ。マーケティング部門ではブランドコンシステンシーチェックと新コンセプトのドラフト作成に活用。営業部門では、MicrosoftとのJV「Avanade」が開発したD3ツールを通じてCopilotが8-K・10-Kレポートを集約分析し、平均43%多くの商談機会創出に貢献したという。 日本企業にとっての現実的な教訓 このスケールのロールアウトを、日本企業がそのまま真似できるかというと、正直難しい。アクセンチュアは自社がコンサル会社であることを活かし、チェンジマネジメントを自前で設計・実行できた。変革管理の専門家が社内にいる強みだ。 とはいえ、以下の教訓は規模を問わず活用できる。 ライセンス配布≠AI活用: 購入した翌日から成果が出るツールではない。使い方を教える仕組みが必要 成功事例の横展開が最大の推進力: 研修よりも「隣の人が使ってうまくいった」という体験の共有が効く リーダーが使っていないと広まらない: シニアリーダーへの先行展開は必須。リーダーが使わないツールは現場も使わない 部門別のユースケースを作れ: 「便利そう」ではなく「この業務のこの部分に使う」まで落とし込まないと定着しない 筆者の見解 74万人への展開という数字は確かにインパクトがある。ただ、この事例を「Copilotはすごい」という文脈だけで読むのは少しもったいない。 注目すべきは、これだけの成果を出すために、アクセンチュアがどれほど巨大な投資をしたかという点だ。チェンジマネジメント、データガバナンスの再設計、アクセス制御の整備、部門別のブループリント作成——これらすべてがセットになって初めてあの数字が出た。 「ライセンスさえ買えばDX完了」という発想が今も日本のIT現場に根強くある中で、アクセンチュアの事例はむしろ正反対のメッセージを発信している。ツールの価値は、それを使いこなすための仕組みへの投資に比例する。 CopilotはTeams議事録、Outlookの要約、会議の文字起こしといった定型業務において安定した価値を提供できる領域で実績を積み始めている。一方で、より高度な分析・創造的タスクには、M365エコシステムの内側だけに閉じないアーキテクチャを並行して検討する価値もある。アクセンチュアの事例はCopilotの可能性を示すと同時に、AI活用の本質が「ライセンス管理ではなく業務変革」であることを改めて教えてくれる。 Copilotが今後どんな進化を見せるか。実力はある。あとはその実力に見合った、ユーザーが「使い続けたい」と感じられるプロダクトへの磨き込みに期待したい。 出典: この記事は Accenture to roll out Copilot to all 743,000 employees in boost for Microsoft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月、OneDriveの同期クライアントが静かに、しかし確実に変わる。削除されたクラウドファイルがPCのごみ箱に自動コピーされる現在の挙動が廃止され、サイトのごみ箱のみで管理されるシンプルな仕組みへ移行する。強制ロールアウトなので管理者の選択肢はないが、これは「知らずに困る」より「知っていれば得をする」変更だ。 現状の問題：ごみ箱が2か所存在するカオス SharePoint OnlineやOneDrive for Businessのドキュメントライブラリからファイルが削除されると、現在の同期クライアントはローカルに同期されていたコピーをPCのごみ箱（macOSではTrash）に移動する。つまり、削除されたファイルは「サイトのごみ箱」と「PCのごみ箱」の2か所に存在するという、直感に反した状態になっていた。 さらに問題をこじらせるのが、サイトのごみ箱からファイルを復元しても、PC側のコピーはそのまま孤立した状態で残り続けること。サーバーとの接続が切れた「幽霊ファイル」として残り、ユーザーを混乱させてきた。ヘルプデスクに「ファイルが消えた」と問い合わせが来て、調べてみたらサイトのごみ箱には存在するのにPCのごみ箱にも別コピーがある——こういう事例に心当たりのある管理者も多いだろう。 5月以降の新しい動作 Microsoftのメッセージセンター（MC1269861、2026年4月3日告知）に記載された変更は明快だ。クラウド側でファイルが削除されたとき、OneDrive同期クライアントはローカルコピーをPCのごみ箱に移動する処理をやめる。代わりに、ローカルフォルダから単純に削除するだけになる。 削除されたファイルの「権威あるコピー」はサイトのごみ箱のみに一本化される。復元が必要なときは、SharePoint/OneDriveのサイトのごみ箱だけを確認すればいい。シンプルだ。 混乱しやすい2つの例外 この変更で影響を受けない重要なケースが2つある。 Files On-Demand（オンデマンドファイル）は対象外。 ローカルに実体を持たず、アクセス時にダウンロードする方式のため、同期クライアントが処理するローカルコピー自体が存在しない。この変更は無関係だ。 ユーザーがローカルコピーを手動削除する場合は従来通り。 ユーザーがローカルファイルをごみ箱に送ると、OSがPCのごみ箱に移動し、OneDrive同期クライアントがサーバー側をサイトのごみ箱に移動する。この動作は変わらない。 今回変わるのは「クラウド側でファイルが削除されたとき、ローカルコピーをどう処理するか」という点だけだ。 実務への影響 IT管理者へ： この変更はテナント設定でブロックできない。展開は2026年5月初旬から始まり、5月末までに全テナントへ完了予定だ。事前に社内ユーザーへのアナウンスを検討してほしい。特に「削除したファイルをPCのごみ箱で探す」習慣が定着しているユーザーがいる環境では、説明なしに「ファイルが消えた」問い合わせが増える恐れがある。 ヘルプデスク・エンジニアへ： ファイル復元の問い合わせ対応がシンプルになる。今後は「SharePointサイトのごみ箱を確認してください」の一言で完結する。PCのごみ箱とサイトのごみ箱の両方を確認させる二度手間がなくなるため、サポートフローの見直しを検討する好機だ。 大規模ドキュメントライブラリを抱える組織へ： Microsoftは同期パフォーマンスの向上も明言している。ファイル数が多いライブラリほど削除オペレーションの頻度が高く、ローカルコピーの移動処理が不要になることで同期クライアントの負荷が軽減される。体感できる改善があるかは環境次第だが、期待していい変更だ。 筆者の見解 OneDrive同期クライアントは、Microsoft 365の中で「本当に地道に良くなった」プロダクトのひとつだと評価している。2020年の差分同期（Differential Sync）導入以降、着実に改善を重ねてきた実績がある。今回の変更もその延長線上にあり、方向性は正しい。 「ごみ箱が2か所に分散する」という挙動は、技術的な経緯はわかっても、エンドユーザー視点では混乱の種にしかならなかった。「正しいコピーはどこか」という問いに対して「1か所だけ」と言い切れる設計に移行することは、シンプルに正解だ。 管理者がブロックできない強制ロールアウトである点は賛否あるかもしれないが、ユーザーの混乱を生む根本的な問題を直す変更であれば、設定オプションを増やすより「デフォルトで正しく動く」ほうがずっといい。設定項目が増えるほど、知らない管理者が損をする世界になる。 「禁止で対処するより、正しく安全に使える仕組みを整える」――IT管理の本筋はそこにある。今回の変更はその哲学と一致している。OneDriveがこういう地道な改善を続けている点は、素直に評価したい。 出典: この記事は OneDrive Sync Client Changes How It Processes Deleted Files の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365（M365）のテナントを適切に設定できている組織は全体のわずか2割——。米ITコンサルティング企業EPCグループがこんな衝撃的な数字を公表し、Copilot & Microsoft 365 Tenant Security Reviewサービスをリリースした。AI活用が加速するなか、設定不備のままCopilotを展開することはデータアクセスリスクを大きく広げる。「AIを入れる前に、まず家の鍵を締めろ」というメッセージは、日本のIT現場にとっても決して他人事ではない。 調査が示す「設定不備」の実態 EPCグループが複数組織のM365テナントを監査した結果、約80%で何らかのセキュリティ設定ミスが確認された。具体的に問題となりやすい領域は以下のとおりだ。 条件付きアクセス（Conditional Access）の設定漏れ: 多要素認証（MFA）が特定ユーザーやアプリに適用されていない SharePoint・OneDriveの共有設定の緩さ: 外部共有が過剰に許可され、データが意図せず外部へ漏れるリスク Microsoft Purviewの未設定: 機密ラベルや情報保護ポリシーが形骸化している 特権IDの常時アクセス状態: グローバル管理者権限の常時付与や、PIMの未活用 これらはどれも「知っていれば設定できる」ものだ。しかしM365の機能は膨大で、設定は日々更新される。運用担当者が追いきれていないケースが大半であることも、この数字の背景にある。 CopilotがリスクをAI規模で増幅する ここで問題になるのが、Copilotの展開だ。Copilotは「ユーザーがアクセスできる情報の範囲で答える」という設計になっている。つまり、テナントの設定が緩いままCopilotを使うと、本来見えてはいけないドキュメントや会話履歴まで検索・要約の対象になるリスクがある。 Security Copilotの自動展開が組織内で進む状況ではこの問題がさらに顕在化する。従来はITリテラシーの高いユーザーしか到達できなかった情報の宝庫に、Copilotが「親切なガイド」として全員を案内してしまう——そういう事態が現実に起き得る。 EPCグループのサービスは、こうした設定不備をCopilot展開前に可視化・修正することを目的としており、Entra ID・SharePoint・Exchange・Teams・Purviewを横断した包括的な審査を提供するという。 日本のIT現場への実務的な影響 日本企業では、M365ライセンスを保有しながら機能の全貌を把握できていないケースが非常に多い。「OutlookとTeamsとOneDriveは使っている」という状態で、セキュリティ設定はほぼ初期値のまま——というのは珍しくない。Copilot展開を検討する前に、以下の3点を必ず確認してほしい。 ① PIM（Privileged Identity Management）でJITアクセスを導入する 特権IDの常時付与は、特権アカウント管理における最大のリスクだ。Microsoft Entra PIMによるJust-In-Time（JIT）アクセスは、Entra P2ライセンスがあれば追加コストなしで導入できる。やっていない理由はない。 ② Purviewで機密ラベルを整備する Copilotは「ラベルが付いたドキュメントのルールを遵守して回答する」。つまり機密ラベルの整備は、CopilotによるAIアクセス範囲の制御にも直結する。展開前の整備が必須だ。 ③ Non-Human Identity（NHI）の権限スコープを最小化する サービスアカウントやアプリ登録（App Registration）の過剰な権限は、自動化やAIエージェントの展開を進める際に大きなリスク要因になる。NHI管理ができなければ業務自動化も進まない。最小権限の原則を徹底することが、効率化への近道でもある。 筆者の見解 「テナント設定ができていない」という問題は今に始まった話ではない。しかしCopilotというアクセラレーターが加わることで、設定不備の影響が指数関数的に拡大する点が今回の本質だと思っている。AIは道具の使い勝手を上げるが、それは悪意ある使い方の効率も同様に上げる——この非対称性をもっと真剣に議論すべき段階に来ている。 Microsoftのセキュリティプラットフォームは、EntraもPurviewも機能として十分に揃っている。問題は「機能がないこと」ではなく、「その機能を使いこなせていないこと」だ。Copilot展開を急ぐあまり、土台のセキュリティ整備を後回しにする組織が出てくることが正直心配だ。家の窓を全開にしたまま金庫を置いても、守るべきものは守れない。 日本のIT管理者にまず勧めたいのは「テナントの棚卸し」だ。Microsoft Defender for Cloud（Secure Score）やEntra ID Identity Secure Scoreは、現状の設定状態を無料で点数化してくれる。Copilot展開の是非を議論する前に、まずこの数字を見てほしい。Microsoftには、この問題を解決するだけの技術とプラットフォームが揃っている。あとは使いきるだけだ。 出典: この記事は EPC Group Launches Copilot & Microsoft 365 Tenant Security Review as 80% of Tenants Found Misconfigured の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月20日より、Microsoft 365 E5契約テナントへのSecurity Copilot自動プロビジョニングが順次開始された。6月30日まで展開が続くこの変更は、追加コストなしでセキュリティAI機能が利用できる点で歓迎すべき動きだ。ただし「何もしなくてもテナントで有効になる」という展開方式には注意が必要で、特に日本のエンタープライズ環境ではデータ所在地（Data Residency）とデフォルトでオンになっているデータ共有設定を事前に把握しておきたい。 何が変わったのか M365 E5テナントには、1,000ユーザーあたり月400 SCU（Security Compute Unit）が自動付与される。上限は月1万SCUで、未使用分は翌月に繰り越されない。3,000ユーザーの組織なら1,200 SCU、1万5,000ユーザー以上の組織は上限の1万SCUに頭打ちになる計算だ。 対象となる機能は、Security Copilotのスタンドアローンポータル、Defender・Intune・Entra・Purview内の埋め込みチャット、プロンプトブック、フィッシングトリアージエージェントなどのエージェントシナリオ。開発者向けのAgent BuilderやGraph APIも含まれる。 一方で含まれないものもある。Microsoft Sentinelのデータレイクコンピュートとストレージは今回の対象外で、Sentinelを常用しているSOCチームはAzure側のコストが別途発生する点に注意が必要だ。 自動展開の仕組みと確認すべき設定 テナントでSecurity Copilotが有効化される7日前に通知が届き、当日にも改めて通知が来る。管理者側での操作は不要だが、有効化直後に最低でも2つの設定を確認してほしい。 ① データ保存場所（Data Storage Location） Security Copilotが生成するログやインタラクションデータをどのリージョンに保存するかを制御する設定だ。日本のエンタープライズではデータレジデンシー要件を持つ企業が少なくない。デフォルト設定が社内ポリシーと合致しているか、有効化当日に確認せよ。 ② データ共有設定（Data Sharing） デフォルトで有効になっている。インタラクションデータがMicrosoftの製品改善に使われる設定で、変更にはCapacity Contributorロールが必要だ。セキュリティポリシー上問題がある場合はすぐにオフにする必要がある。 RBACモデルを整理しておく Security CopilotはEntra IDの上に独自のロールモデルを持つ。 ロール 権限 Security Copilot Owner ワークスペース管理・設定変更・ロール割り当て Security Copilot Contributor プロンプト実行・エージェント操作・プロンプトブック作成 Global AdministratorとSecurity AdministratorはOwnerロールを自動的に取得できる。推奨パターンはEntra IDセキュリティグループを作成し、個人ではなくグループ単位でロールを割り当てること。既存のIAMモデルと一貫性が取れ、定期的なアクセスレビューもやりやすくなる。 重要なのはSecurity Copilotが各統合製品のアクセス制御を引き継ぐ点だ。Defenderの特定ワークスペースへのアクセス権がないアナリストは、Security Copilot経由でもそのデータにアクセスできない。権限の境界線はきちんと機能する設計になっている。 実務への影響 日本のSOCチームおよびIT管理者にとって、今回の変更で直ちに対応が必要な事項をまとめる。 Message Center（MC1261596）を確認する — テナントの展開予定日を把握する データ共有設定の確認・変更 — コンプライアンス要件に応じてオン/オフを判断 データ保存リージョンの確認 — 日本リージョンに設定されているか確認 Sentinelコストの予算計上 — SCUには含まれないため、既存のAzure請求と分けて確認 Entraグループ設計 — OwnerとContributorのグループを事前に設計し、個人割り当てを避ける SCU消費の監視設定 — 管理ポータルの使用量ダッシュボードを定期的にモニタリング フィッシングトリアージエージェントのような機能は、アラート疲れを抱えるSOCにとって即戦力になりえる。ただしSCUはリセット式なので、使い方の「計画」をしておかないと月末に上限に達してサービスが止まる事態も起こりうる。 ...

SamsungのAndroid 2026年4月セキュリティアップデートを適用したGalaxy端末で、Microsoft Teams・Authenticator・Outlook・OneDriveなどのM365アプリが突然機能しなくなる障害が多数報告されている。原因はAndroid WebViewのリグレッションバグと見られており、スマートフォンで業務を行うエンジニアやIT管理者にとって看過できない問題だ。 何が起きているのか Samsungは2026年4月8日以降、Galaxy端末向けに2026年4月のAndroidセキュリティアップデートを順次配布している。このアップデートはExynos CPUを搭載したGalaxy端末の47件の脆弱性（うち14件がCritical）を修正する重要なものだ。 しかしその副作用として、M365アプリが断続的にあるいは完全に機能しなくなる事例が続出している。Samsung公式フォーラムには7ページを超えるスレッドが立ち、4月17日以降マイクロソフトのQ&Aフォーラムにも同様の報告が集まっている。 影響を受けるアプリと症状 Microsoft Teams: 他ユーザーのステータス表示が消え、メッセージが送信できなくなる Microsoft Authenticator: MFA通知が届かなくなり、場合によってはアプリ自体が起動不能になる Outlook: メールが更新されなくなり、画面が黒くなって何も表示されなくなる OneDrive: 接続障害が報告されている 端末の再起動で一時的に回復することがあるが、しばらくすると再発するケースが多い。PC・ノートPCでは問題が生じていない点も特徴的だ。 技術的な原因：WebViewへの依存が仇に M365アプリの多くは、認証フローや一部コンテンツ表示にAndroid WebViewを利用している。特にMSAL（Microsoft Authentication Library）を通じた認証処理はWebViewに強く依存しており、WebViewに問題が生じると認証そのものが崩壊する。 今回のSamsungアップデートはWebViewコンポーネントにリグレッションを引き起こしたと考えられており、特定のDNS処理やネットワーク接続時にWebViewが正常動作しなくなるケースがある模様だ。 暫定的な回避策 根本的な解決はSamsungによる修正パッチ配布を待つしかないが、現時点で有効とされる回避策は以下の通りだ。 Private DNSを無効化する（最もシンプル） 設定 → 接続 → 詳細接続設定 → プライベートDNS → オフ に変更し、再起動する。多くのユーザーがこれで復旧を確認している。 2. Google Play ServicesのWebViewを再インストールする Play StoreからAndroid System WebViewの更新を一度削除し、再起動後に再インストールする。ただし、次回のWebView更新後に再発する可能性がある。 3. 端末の再起動 断続的な障害の場合、再起動で一時的に回復する。恒久対処ではないが急場しのぎとして有効だ。 実務への影響と対応 IT管理者が今すぐすべきこと Microsoft Authenticatorが機能しなくなるということは、MFAが機能しなくなることを意味する。条件付きアクセスポリシーでMFAを強制している組織では、Galaxy端末ユーザーがM365にログインできなくなる事態が起こりうる。 優先度の高い対応として以下を推奨する。 Galaxy端末ユーザーへの注意喚起: 2026年4月パッチ適用済みの端末ユーザーに周知し、回避策の手順を共有する 代替認証手段の一時開放: TOTP（Authenticatorのワンタイムコード機能）やFIDO2キーなど、Authenticatorのプッシュ通知に依存しない認証方式を一時的に有効化することも検討する Samsung修正パッチの監視: Samsungが修正アップデートを配布した際には迅速に適用できるよう、MDM側でアップデート通知体制を整えておく モバイルアプリ開発者への教訓 WebViewへの依存は「OSアップデートの余波」を受けやすいことを今回改めて示した。エンタープライズ向けAndroidアプリを開発・運用する場合、WebViewのバージョン依存を考慮し、回帰テストにWebViewバージョンを明示的に含めることが重要になる。 筆者の見解 「セキュリティパッチが別のセキュリティリスクを生む」——今回の問題にはそういう皮肉な構造がある。47件もの脆弱性を修正する重要なパッチが、業務の要であるMFAを機能不全に陥らせてしまった。 Microsoftの立場から見れば、自社アプリが他社のOSアップデートで突然壊れる状況はコントロールしにくい面もある。一方で、MSALを含む認証レイヤーの実装においてWebViewへの依存度を下げる設計や、より堅牢なフォールバック機構を持てないかという点は、今後の課題として向き合ってほしいと思う。Microsoftの技術力をもってすれば、対応できないはずはない。 IT管理者の視点では、今回の事案は認証の冗長性を見直す良い機会だ。Authenticatorが唯一のMFA手段になっていると、このような外部要因のトラブルで業務が止まる。ゼロトラストの文脈でいえば「Single Point of Failureを排除する」は基本中の基本であり、平時に気づけるうちに複数の認証手段を整備しておくことを強くお勧めしたい。 ...

Microsoft 365 Copilotに大きな機能追加が入った。Adobe Express、Figma、Optimizely、Dynamics 365など、現場で日常的に使われているビジネスアプリをCopilot Chat内でエージェント経由で直接操作できる新機能だ。「会話の流れを止めずに業務を完結させる」という思想が、プラットフォームとしての姿かたちを変えつつある。 エージェントが「コンテキストの橋」になる これまでのCopilot連携は、あくまでMicrosoft製品の枠内にとどまっていた。SharePointのドキュメントを要約する、Outlookのメール文面を生成する——便利ではあるが、それはあくまで「Microsoftの中で完結する便利さ」だった。 今回の発表は、その壁を外部アプリとの連携まで広げるものだ。たとえばマーケティング担当者がCopilot Chatでキャンペーンの方向性を議論しながら、その場でAdobe Express上のアセット生成を指示し、同じ会話の中でOptimizelyのA/Bテスト設定まで完結させる——という使い方が想定されている。Figma連携ではデザインコンテキストを保ったままフィードバックや変更依頼ができるようになる。 Dynamics 365との連携は特に営業・CRM系の業務で効果が大きいだろう。商談状況の更新や顧客レコードの参照を、TeamsやOutlook上の会話フローを離れずに行えるようになる。 「ツールの切り替え」が生産性を奪っていた 業務効率が上がらない原因の一つに「コンテキストスイッチング」がある。メールを書いていてCRMを開き、データを確認してチャットに貼り、デザインツールに切り替えて……というサイクルは、実は非常に高コストだ。認知負荷のみならず、ツール間での情報の断絶が「抜け漏れ」や「整合性の崩れ」を生む。 今回のエージェント連携は、この問題に正面から向き合う設計思想を持っている。Copilot Chatを「中心軸」として、そこから各アプリへの操作を統合することで、ユーザーが意識するコンテキストを一本化しようとしている。 実務への影響──日本のエンジニア・IT管理者へ まず確認すべき点は「ライセンスとロールアウトのタイミング」だ。 現時点ではMicrosoft 365 Copilotライセンスが前提で、各アプリ連携はMicrosoft AppSource経由で展開される。日本テナントへの展開スケジュールは公式ドキュメントを必ず確認してほしい。 エージェントの「信頼境界」設計も重要だ。 外部アプリとCopilot Chatをエージェントでつなぐということは、データの流れも外部に及ぶことを意味する。特にDynamics 365のような顧客データを扱うケースでは、どのデータがCopilotのコンテキストに渡るかを情報セキュリティの観点でレビューすることが必須になる。管理者向けのポリシー制御が十分に用意されているかも確認しておきたい。 Power Platformとの住み分けも整理が必要だ。 すでにPower AutomateやPower Appsで業務フローを構築している企業では、「Copilotエージェント連携」と「既存の自動化フロー」が重複するシナリオが出てくる可能性がある。二重管理にならないよう、事前に整合性を計画したい。 筆者の見解 M365がバラバラに使われる現場を多く見てきた立場から言うと、この方向性は正しい。Microsoft 365はそもそも「統合して使うことで価値が出るプラットフォーム」であり、チームによってツールの使い方が完全にバラバラという状況は、コスト対効果として見ると本来の価値をまったく引き出せていない。 今回のエージェント連携は、その「統合のご利益」を外部アプリにまで広げる試みとして、理念としては評価できる。Adobe ExpressやFigmaといった現場でのデファクト級ツールをCopilotから操作できるようになれば、「Copilotを開く動機」が確実に増える。ここ数年のCopilotをめぐる議論では「結局、単独で使う価値をどこで示せるか」という問いが繰り返されてきた。外部エコシステムとの連携強化は、その回答の一つになりうる。 ただ、正直に言えば「機能の発表」から「現場で当たり前に使われる状態」までにはまだ距離がある。エージェントの設定のしやすさ、動作の安定性、管理者からのガバナンス制御——この辺りが実運用の鍵を握る。素材は揃ってきた。それをどれだけ洗練された体験に磨き上げられるか、今後の実装に期待したい。 M365の統合プラットフォームとしての底力は本物だ。この方向性を着実に進化させてほしいと思う。 出典: この記事は Bring your everyday business apps into the flow of work with agents in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365の中核アプリであるWord・Excel・PowerPointにおいて、Copilotのエージェント機能（Agentic Capabilities）が正式にGA（General Availability）となった。単に「文章を補完する」「数式を提案する」という段階を超え、複数ステップの操作をドキュメント内で自律的に実行できるようになったことは、Officeの使い方そのものを問い直すターニングポイントだ。Word週次利用52%増、Excel67%増という数字も、単なるバズワードではなく実際の職場での受け入れを示している。 エージェント機能とは何か これまでのCopilotはどちらかといえば「サジェスト型」だった。ユーザーが指示を出し、AIが結果を返し、ユーザーが確認してOKを出す——この一往復を繰り返す構造だ。エージェント機能はここが根本的に違う。 アプリネイティブな操作を、複数ステップにわたって自律的に実行する。たとえばWordなら、「この報告書のすべての数字を最新データに更新して、エグゼクティブサマリーを書き直して、目次も整えて」という指示を一度出せば、Copilotが順番にそれをこなしていく。Excelなら「このデータを分析して傾向を特定し、グラフを作成して、ピボットテーブルを更新して」といった一連の作業フローを自律実行できる。 実務への影響 反復作業からの解放 日本のOfficeユーザーが日常的に行っている「テンプレートへの転記」「月次レポートの数字更新」「プレゼン資料のフォーマット統一」といった作業は、エージェント機能の主戦場だ。技術的には難しくないが時間がかかり、ミスも生じやすい——まさにAIが得意とする領域だ。 IT管理者が押さえるべきポイント エンタープライズ環境では、Copilotのエージェント機能にどこまでの権限を与えるかが重要な管理ポイントになる。エージェントが「自律的に動く」ということは、それだけアクセス権設計が重要になるということでもある。Microsoft Purviewとの連携でデータ保護は担保されているが、最小権限の原則（Principle of Least Privilege）の再確認と、機密ラベルの適切な設定を改めて確認しておくことを強くお勧めする。 アプリ別・活用のヒント Word: 定型報告書の自動更新・リサーチ情報の統合に最適。スタイルや書式の統一作業を丸ごと委ねると効果が出やすい Excel: データクレンジングと分析の組み合わせ、ダッシュボード更新の自動化が狙い目。手作業で繰り返していたVBA的な処理を自然言語で代替できるケースが増える PowerPoint: ブランドガイドラインに沿ったスライドの再フォーマットは、人手でやる必然性がほぼなくなりつつある 筆者の見解 エージェント機能という方向性そのものは、正しいと思っている。「一言指示して、あとは任せる」——これがAI活用の本来の姿であり、Copilotがその路線に舵を切ったことは素直に評価したい。 ただ、率直に言うと「これがCopilotの真の実力の発揮場所なのか」という問いは残る。WordとExcelとPowerPointというMicrosoftが20年以上かけて構築した牙城で動くのは、当然といえば当然の話だ。もったいないのはその先——TeamsのミーティングデータとOutlookのコミュニケーション履歴とSharePointのドキュメントが有機的に連携し、ビジネスの文脈を理解した上で提案・実行できる状態——にまだ十分に踏み込めていないことだ。 Microsoft 365は個別アプリの集合体ではなく、統合プラットフォームとして使ってこそ真価を発揮する。エージェント機能がOfficeアプリ内で完結するだけでなく、TeamsやOutlookとシームレスに連携し、M365全体を跨いだ業務自律化につながる日が来れば、「Copilotで業務が変わった」と心から言えるようになるだろう。 Microsoftにはその力が確かにある。だからこそ、まずはWord・Excel・PowerPointで確実にエージェントを使い倒しながら、次のフェーズを期待を込めて待ちたいと思っている。 出典: この記事は Copilot’s agentic capabilities in Word, Excel, and PowerPoint are generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月末、Microsoft 365 CopilotのAPIエンドポイントがoffice.comからcloud.microsoftドメインへ静かに切り替わる。ユーザーには何も見えない変更だが、ファイアウォールやプロキシを管理している担当者には看過できない話だ。設定の対応漏れが接続障害に直結するため、今週中に確認を済ませておきたい。 何が変わるか——インフラ層での静かな移行 MicrosoftはM365全体で「cloud.microsoft」への統一ドメイン移行を段階的に進めており、今回のCopilot APIエンドポイント変更はその一環だ。変更点を整理すると次のとおりになる。 CopilotのAPI通信先が office.com → cloud.microsoft に変更 ユーザー画面・ワークフローへの変更は一切なし デフォルト有効化で、無効化オプションなし WebSocket（WSS）接続を使用する点が重要 サービス基盤レベルの変更なのでエンドユーザーは何も気づかないが、ネットワーク制御を持つ組織では対応が必要になる。 管理者が今週中にやること 対応が求められるのは「独自のファイアウォール・プロキシ・エンドポイントフィルタリング設定を持つ組織」だ。Microsoft 365のネットワーク要件に既に準拠していれば追加対応は不要とされているが、念のため以下のチェックリストで確認しておくことを強く推奨する。 対応チェックリスト *.cloud.microsoft をエンドポイント許可リストに追加する *.cloud.microsoft 宛のWSS（WebSocket）接続が遮断・干渉されていないか確認する 以下の処理を cloud.microsoft トラフィックから除外する TLS復号（SSL Inspection） パケットインスペクション ネットワーク層のDLP ネットワーク担当チームとヘルプデスクへ事前に周知する Microsoftが提供するCopilotネットワーク接続テストツールで検証する 日本の現場への影響——見落としやすい落とし穴 日本の大企業・官公庁系では、UTMやプロキシによるSSL Inspectionを全トラフィックに対して適用している環境がいまだに多い。「cloud.microsoft宛ての通信もTLS復号対象に含まれていた」というケースは決して珍しくないはずだ。 Copilotが突然応答しなくなった、極端に遅くなったという障害報告が4月末前後に増えた場合、真っ先にこのネットワーク設定を疑うべきだ。ヘルプデスクには「Copilotの動作不良はネットワーク設定が原因である可能性がある」と事前に情報共有しておくだけで、トリアージのスピードが格段に変わる。 実務での活用ポイント 今すぐ確認: *.cloud.microsoft のエンドポイントをMicrosoftの最新公開リストと照合する ゼロトラスト環境: Conditional Accessのポリシーがcloud.microsoftドメインを考慮しているか再確認する SASEやCASB製品利用組織: ベンダーに「cloud.microsoft対応状況」を問い合わせておく 移行後のモニタリング: Copilotの利用ログやネットワーク監視で、4月末前後の異常を検知できる体制を整える 構成ドキュメントの更新: 許可リストを変更したら、必ずネットワーク構成ドキュメントに反映しておく 筆者の見解 ドメイン統一自体は正しい方向性だ。office.com、microsoft.com、microsoftonline.com と分散していたエンドポイントが cloud.microsoft に集約されていくことで、ネットワーク管理の見通しは確実に良くなる。長期的には管理者の負担軽減につながる流れであり、この取り組みは歓迎したい。 ただし「デフォルト有効、無効化不可」という実装スタイルは、現場の管理者に一方的な変更コストを押しつける形になっている点はもったいない。Microsoftほどのプラットフォームであれば、こういった基盤移行を「段階的推奨」から「完全切替」に持っていくまでの猶予とサポートをより手厚くできるはずで、その部分をぜひ改善してほしいところだ。 今回のような変更は今後も続く。M365のメッセージセンター（Message Center）を定期的にウォッチする運用体制の有無が、安定稼働とトラブル多発の分かれ目になってくる。cloud.microsoftへの統合が完成したとき、Copilotを含むM365サービス全体のパフォーマンスと信頼性が向上し、このプラットフォームが本来持つポテンシャルをきちんと発揮できる基盤になることを期待している。 出典: この記事は Microsoft 365 Copilot transition to the cloud.microsoft domain の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 のメッセージセンター通知（MC1269241）が静かに、しかし重要な変更を告げている。2026年5月4日から、EU・EFTA・UK 域内のテナントで Word・Excel・PowerPoint の Copilot に Anthropic 製 AI モデルがデフォルトで有効になる。 管理者が何も操作しなければ、ユーザーはすでに Anthropic モデルで動く Copilot を使い始める——そういう変更だ。 変更の概要 マイクロソフトは「Copilot in M365 apps with Anthropic models」という新しい管理者設定を導入する。 対象アプリ：Excel・PowerPoint（即時）、Word（2026年夏） 適用日：2026年5月4日 対象テナント：EU・EFTA・UK デフォルトがオンである点がポイントだ。「Anthropic をサブプロセッサとして有効にするグローバルトグル」とは別の設定であることにも注意が必要で、両方を把握しておかなければならない。 EU Data Boundary（EUDB）の問題 この変更で最も注意すべきは、データ処理の場所だ。Anthropic モデルを使った場合、処理は EU Data Boundary の外側で行われる。ただし、マイクロソフトは以下の点を保証している： 項目 内容 データ処理場所 EUDB 外（Anthropic モデル使用時） データ保存 EUDB 外には保存しない 暗号化 転送中は完全に暗号化 責任体制 Anthropic はマイクロソフトのサブプロセッサとして製品条件・DPA に拘束 「保存はしない、暗号化はしている」とは言われても、GDPR や業界固有のデータ規制（金融・医療・公共など）への準拠を求められている組織にとっては、処理の段階で EUDB 外に出ること自体がアウトになりうる。コンプライアンス担当者との事前確認は必須だ。 IT管理者がすぐやること 対応のステップは明快だ： Microsoft 365 管理センターを開く 設定 → すべて表示 → AI プロバイダー（Microsoftサブプロセッサとして稼働） に移動 「Copilot in M365 apps with Anthropic models」の設定を確認 組織のデータ居住ポリシーおよびコンプライアンス要件と照らし合わせる 必要であればトグルをオフにする 5月4日までに動けば間に合う。逆に言えば、5月4日を過ぎてから気づいた場合は、それまでの期間にすでに Anthropic モデルで処理されていたことになる。 ...

Microsoft 365 Copilotが、2026年5月4日よりExcelおよびPowerPointで外部AIモデルをデフォルト利用するように変わる。EU・EFTA・英国リージョンのテナントを対象とした変更だが、データ処理の仕様に見落とせない注意点がある。グローバル展開している日本企業の管理者も、この変更の意味を正確に理解しておく必要がある。 何が変わるのか Microsoft 365 管理センターに新たに「CopilotでAnthropicモデルを使用する」という設定が追加される。この設定が有効になると、ExcelおよびPowerPoint上のCopilot体験において、コンテンツ生成や編集の場面でAnthropicのモデルが使用されるようになる。 対応アプリとスケジュール: Excel: 2026年5月4日より対応 PowerPoint: 2026年5月4日より対応 Word: 2026年夏対応予定 2026年3月25日以降に作成されたEU・EFTA・UKテナントでは、この設定がデフォルトで有効になっている。それ以前から存在するテナントは、メッセージセンターで自テナントのデフォルト設定を確認する必要がある。 データ処理と欧州データ境界の関係 この変更で最も注意が必要なのは、データ処理がMicrosoftの欧州データ境界（EU Data Boundary: EUDB）の外で実施されるという点だ。 AnthropicはMicrosoftのサブプロセッサーとして、Microsoftの製品条件およびデータ保護補足契約（DPA）に従って運用される。つまりコンプライアンス上の責任はMicrosoftが負う枠組みではあるが、物理的なデータ処理はEUDB外で行われることになる。 EUDBへの厳格な準拠を求められる組織（金融・医療・公共セクターなど）は、この点を特に慎重に評価する必要がある。 管理者がすぐに行うべきこと 設定はMicrosoft 365 管理センターから確認・変更できる。 Microsoft 365 管理センターに「AI Administrator」ロールでサインイン Copilot → 設定 → すべて表示 → Microsoftサブプロセッサーとして運用するAIプロバイダー へ移動 自組織のポリシーに合った設定を確認・調整する なお、グローバルのサブプロセッサー設定が「全ユーザー」または「特定のユーザーとグループ」で有効化されている場合、アプリ内のAnthropicモデル設定は変更不可になる。この依存関係は見落としやすいので要注意だ。 実務への影響 日本法人がEUリージョンのM365テナントを持っている場合、または海外拠点のテナントを管理している場合は、この変更の影響範囲を確認する必要がある。 確認すべきテナント: EU・EFTA・UK所在のテナント リスクが高い業種: 金融・医療・公共機関（EUDB準拠が求められる場合） アクションタイミング: 2026年5月4日より前に設定確認を完了させる 日本国内のみで運用しているテナントは現時点では直接の影響を受けないが、将来的に類似の設定が他リージョンにも展開される可能性はある。今のうちから設定管理の仕組みを整えておくのが賢明だ。 筆者の見解 今回の変更は、Microsoft 365 Copilotが「単一モデルに固執しない」方向へ明確に舵を切ったことを示している。Microsoftが自社モデルだけでなく、外部モデルとのオーケストレーションをプラットフォーム戦略の柱に組み込んできた——そう読むのが自然だろう。 筆者はかねてより、Microsoft 365の真価は統合プラットフォームとしての全体最適にあると考えてきた。各タスクに最適なモデルを使い分けられる構造になるなら、それ自体は正しい方向性だ。Copilotが多様なモデルを束ねるオーケストレーターとして進化していくなら、筆者が長年理想としてきた「統合プラットフォームとしてのMicrosoft 365」に近づく可能性がある。 ただ、今回の設定変更でEU組織のデータ処理がEUDB外になる点は素直に引っかかる。「Copilotを使うためにEUDB準拠を妥協せざるを得ない」状況になりかねないからだ。これだけの技術力があるのだから、データ主権の問題も正面から解決できるはずだと思っている。 管理者の立場から一点だけ言うと、「デフォルト有効」という設計は少し乱暴に感じる。セキュリティポリシーやコンプライアンス要件は企業ごとに異なるのだから、重要な変更はオプトインが基本であるべきだ。プラットフォームとしての信頼は機能の良さだけでなく、展開の丁寧さからも生まれる。 出典: この記事は Copilot in Microsoft 365 apps with Anthropic models の内容をもとに、筆者の見解を加えて独自に執筆したものです。