M365

Microsoft が Anthropic との連携を強化し、Microsoft 365 Copilot において Anthropic の Claude AI がサブプロセッサとして正式に組み込まれることになった。英国テナントでは管理者が明示的にオプトインしない限り Copilot 内での Claude 機能が利用できない仕組みが2026年5月12日時点で適用されており、多くの企業が設定判断を迫られている。 何が変わったのか これまで Microsoft 365 Copilot は主に Microsoft が管理する AI モデルを使用していたが、今回の変更により Anthropic の Claude がサブプロセッサとして追加された。Microsoft の AI Foundry 経由で外部モデルを利用する流れの一環とみられる。 重要なのはデータ処理の所在だ。Anthropic がサブプロセッサになることは、一部のデータが Anthropic のインフラに渡ることを意味する。英国 GDPR（UK GDPR）の観点から、企業はデータ移転の正当性確認と処理記録の整備が求められる。 英国テナントが判断すべきポイント オプトインを検討すべき組織 生成 AI の活用を積極的に推進している GDPR コンプライアンスの整備が済んでいる データ処理者の追加を DPA（データ処理契約）に通知できる体制がある オプトインを見送るべき組織 厳格なデータ主権要件がある（金融・医療・公共機関等） 社内のデータ処理者変更審査プロセスに時間がかかる 現時点で Copilot をほとんど使用していない 管理者が確認すべき設定手順 Microsoft 365 管理センター → Copilot 設定から Anthropic へのデータ処理同意を確認 プライバシーポリシーの更新: Anthropic をサブプロセッサとして追記 ROPA（処理活動記録）の更新: 新たなデータフローを記録 DPO（データ保護責任者）への連絡: 必要に応じて GDPR 第28条に基づく合意書を更新 日本のIT管理者への示唆 日本テナントへの直接的な影響は現時点では限定的だが、英国での運用は今後の展開の先行事例になる。Microsoft が外部モデルを Copilot に組み込む方向性を明確にした以上、日本の IT 管理者も以下を準備しておくべきだ。 ...

Microsoft が 2026年5月の累積更新プログラム（CU）で、SharePoint Server の全オンプレミスバージョンに影響するリモートコード実行（RCE）脆弱性を含む計10件のセキュリティ修正を提供開始した。Critical 評価の RCE が2件含まれており、オンプレミス SharePoint を運用する組織は速やかな対応が求められる。 修正対象のバージョンと KB 番号 今月の更新は以下のバージョンに適用される。 バージョン 言語非依存 言語依存 SharePoint Server 2016 KB5002868 KB5002869 SharePoint Server 2019 KB5002870 KB5002872 SharePoint Server SE KB5002863 （CU と同一） Office Online Server KB5002871 — Microsoft はセキュリティ修正を単体で適用するのではなく、完全な CU を適用することを強く推奨している。SharePoint Server Subscription Edition（SE）については、5月 CU 自体がセキュリティ修正と同一内容となっている。 また今月の更新は Microsoft Update 経由での自動配信も実施されている。Windows Update を受け入れる設定にしているファームでは、意図せず更新が開始される可能性がある点に注意が必要だ。 今月修正された脆弱性一覧 計10件の脆弱性が修正された。Critical 評価が2件、残る8件は Important 評価の RCE または情報漏えい（Information Disclosure）だ。 CVE 影響バージョン 種別 深刻度 CVE-2026-33110 2016, 2019, SE RCE Important ...

Microsoft Edgeは2026年5月13日、これまで独立していた「Copilot Mode」を廃止し、AI支援機能をブラウザエンジン本体に直接統合する大規模アップデートを実施した。タブ横断推論、Voice and Vision（音声＋画像によるハンズフリー操作）、閲覧履歴を自動整理する「Journeys」が、デスクトップとEdgeモバイルアプリの双方で利用可能になる。 Copilotモード廃止という方向転換 「Copilot Mode」は、Edgeのサイドバーや専用UIとしてCopilotを呼び出す仕組みだった。今回のアップデートでこのモードは正式に廃止となり、同等以上の機能がブラウザ本体のUIに組み込まれる。右上のCopilotアイコンをクリックするだけで、追加設定なしにAI機能が起動する設計だ。 これは「AIをサードパーティ的に乗せる」発想から「ブラウザとAIが一体」という発想への転換であり、アーキテクチャレベルの変化といえる。 3つの主要機能 タブ横断推論（Reasoning across tabs） 開いている複数のタブをまたいでCopilotが情報を収集・比較し、ひとつの回答にまとめる機能。例えば10数件のワイナリーサイトを開いた状態で「どこが一番アクセスがいい？」と聞けば、各サイトの情報を読み取って比較結果を返す。ユーザーの明示的な許可のもとで動作し、現在のページを離れることなく回答が得られる。 Voice and Vision（ハンズフリーブラウジング） 音声とカメラ（画面共有）を組み合わせてEdgeを操作できる機能。「この画面に表示されている契約書の要点を教えて」といった使い方が可能で、Copilotが動作中は常に視覚的なインジケーターが表示されるため、どのタイミングで聴取・撮影しているかを明確に把握できる。 Journeys 閲覧履歴を「旅行計画」「購入検討中の商品」のようなトピック単位に自動整理し、サマリーと次のステップの提案を付与する機能。デスクトップでは先行提供されていたが、今回Edgeモバイルアプリでも利用可能になる。長期間にわたるリサーチや比較検討作業を「途中から再開」しやすくする仕組みだ。 実務への影響 日本のエンジニアやIT管理者にとって、今回の変更で注目すべき点は2つある。 1. ブラウザポリシー管理の見直し Copilot Modeが廃止され機能がブラウザ本体に統合されたことで、これまで「Copilot Mode」を無効化するポリシーで管理していた企業は設定の見直しが必要になる可能性がある。Microsoft Intune経由のEdge管理ポリシーを定期的にレビューする習慣がない組織は、想定外の機能が有効化されるリスクがある。 2. 閲覧履歴の取り扱い Journeysやタブ横断推論は「ユーザーの許可のもとで」閲覧データにアクセスする。社内システムや機密情報を扱うブラウザセッションにおいて、どのデータをAI機能に渡すかの意識を持つことが求められる。企業ポリシーとして「どの機能を許可するか」を明示的に定義しておくことを推奨する。 実務活用のヒント 複数の見積もりサイトや仕様書を並べてタブ横断推論で比較 → 調達・評価業務の効率化に直結 Voice and Visionでマニュアルや障害報告書を音声で要約 → ハンズオン作業中の情報収集に有効 Journeysで長期リサーチの文脈を保持 → 技術選定や要件調査の継続性確保 筆者の見解 率直に言えば、今回の方向性は評価できる。AIをサイドパネルに「乗せる」設計では、どうしても「補助ツール感」が拭えなかった。タブ横断推論のようにブラウザ本体の文脈を活かした機能は、使用感が本質的に変わる可能性を持っている。 ただ、機能の多さと実際の精度は別の話だ。タブ横断推論にしても、開いているタブの内容を正確に読み取り、的外れな回答を返さないかどうかが実運用での評価軸になる。機能名が並んでいるフェーズから、「毎日使い続けたくなる精度」を証明するフェーズへの移行が、今のEdgeに問われている。 MicrosoftにはブラウザとOSとクラウドをつなぐ資産がある。それを活かした形でのAI統合というのは、他社には簡単に真似できない勝負ができるはずだ。Journeysのような「文脈を持続させる」アプローチはその方向性と合致している。この路線を、地道に精度で証明し続けてほしい。 出典: この記事は New updates to Edge across desktop and mobile の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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

Microsoftが静かに、しかし重要な変更を発表した。SharePoint OnlineのPlan 1・Plan 2、そしてOneDrive for BusinessのPlan 1・Plan 2という4つのスタンドアロンSKUを廃止する。2026年5月31日をもって新規販売を終了し、2027年1月以降は既存契約の更新も不可となる。サービス自体は2029年12月まで継続されるため、即時の混乱はないが、今から移行計画を立てておく必要がある。 何が廃止されるのか 対象プランとその価格帯は以下のとおりだ。 SharePoint Online Plan 1: 月額約$5/ユーザー（1TBストレージ） SharePoint Online Plan 2: 月額約$10/ユーザー（無制限ストレージ＋高度機能） OneDrive for Business Plan 1: 月額約$5/ユーザー（1TBストレージ） OneDrive for Business Plan 2: 月額約$10/ユーザー（最大5TB～25TBストレージ＋DLP機能） Microsoftが廃止理由として挙げたのは「低い顧客需要」「意図しない・非標準の利用」「維持コストの高さ」の3点だ。特に「意図しない利用」という表現が興味深い。業界内では、コスト意識の高い組織や個人がM365フルスイートを契約せず、これらの低価格プランをただの安価なクラウドストレージとして使っていたケースが多かったと見られている。月額$5で1TBというのは確かに割安で、目的外利用を誘発する価格設定だったとも言える。 代替としてのM365スイート Microsoftが推奨する移行先は以下のスイートだ。 Microsoft 365 Business Basic / Standard / Premium Microsoft 365 E3 / E5 いずれもSharePointとOneDriveの機能を内包しており、TeamsやExchange Onlineも含む統合環境となる。当然ながら、スタンドアロンプランと比較すると月額コストは上昇する。Microsoft 365 Business Basicでも月額$6/ユーザー程度（2026年以降の価格改定後）からとなり、より多くの機能を持つプランはさらに高額だ。 実務への影響——日本のIT管理者が今すべきこと まず、自社テナントの契約状況を確認することが最優先だ。管理センターのライセンス一覧で対象SKUを使用しているユーザーを特定し、以下のアクションを取ろう。 1. 影響ユーザーの棚卸し 「SharePoint Online Plan 1/2」「OneDrive for Business Plan 1/2」のライセンスが割り当てられているアカウントを抽出する。PowerShell（Get-MgUserLicenseDetail）やMicrosoft 365 管理センターのライセンスレポートで確認できる。 2. 利用実態の把握 対象ユーザーが実際に何を目的で使っているかを確認する。純粋なファイルストレージ目的なのか、SharePointのサイト機能を使っているのかで、最適な移行先が変わる。 ...

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

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

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

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

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

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

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

Microsoftが「TeamsにSharePointエージェントを直接追加できる」機能を2026年6月よりロールアウト開始する。チャット画面を離れることなくSharePointのドキュメントや情報を横断検索できるこの機能は、M365がプラットフォームとして謳う「統合の価値」を実感できる、数少ない取り組みの一つだ。 SharePointエージェントをTeamsに呼び出す——何ができるのか この機能では、Teamsのチャットやチャネルに「SharePointエージェント」を直接追加できる。操作方法は2通り。 チャットのメンバーリストドロップダウンから「エージェントとボットを追加」を選択 Teamsストアの「エージェント」カテゴリから検索・追加 エージェントを追加すると、その会話の文脈の中でSharePointのコンテンツを検索・参照できるようになる。プロジェクトの議論中に「あの仕様書はどこだったか」という疑問が出たとき、SharePointエージェントに問いかければ直接回答が返ってくる——というユースケースを想定している。 ロールアウトのスケジュールは以下のとおり： Targeted Release：2026年6月中旬開始、6月末完了予定 General Availability：2026年6月末開始、7月末完了予定 管理者側の設定変更は不要で、適切なライセンスを持つユーザーが自分で追加できる。なお、利用にはE3またはE5ライセンスが必要な点は確認しておきたい。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本のエンタープライズでよく見られる光景がある。Teamsで活発に議論しながら、必要な情報を探すためにブラウザでSharePointを開き、ドキュメントのURLをコピーして貼り付ける——このコンテキストスイッチが積み重なって生産性を蝕んでいる。SharePointエージェントのTeams統合が解決しようとしているのはまさにこの問題だ。 IT管理者へのアドバイス 管理者操作は不要だが、ユーザーへの事前周知は必須。「急に新機能が増えた」状態はヘルプデスクへの問い合わせ急増を招く SharePointのアクセス権設定が適切でないと、エージェントが予期しないドキュメントを返す可能性がある。権限設計の見直しを今のうちに行うことを推奨する E3/E5が必要な点を確認し、対象外ユーザーへの対応方針をあらかじめ決めておく エンジニアへのアドバイス SharePoint側のドキュメント構造・命名規則が整っていないと、エージェントが正確な情報を返せない。情報アーキテクチャの整備が先決 チームの活用方法を標準化する簡単なガイドラインを作成しておくと、展開後の混乱を抑えられる 筆者の見解 M365のAI機能に対して、近年は手放しで喜べないケースが正直なところ続いていた。だからこそ、今回の取り組みには「これだ」と感じるものがある。 TeamsとSharePointはM365の中核を担う2大ツールだ。にもかかわらず、この2つの間でコンテキストを行き来するコストは長年ユーザーの不満の種だった。SharePointエージェントをTeams統合するという方向性は、「個別製品の機能強化」ではなく「プラットフォームとしての統合価値」を高める本質的なアプローチだと思う。 M365の強みは、Teams・SharePoint・Exchange・Entraが一つのエコシステムとして機能することにある。その観点から見れば、今回の施策は正しい方向を向いている。バラバラに使っていては意味がないプラットフォームが、少しずつ本来の姿に近づいていると感じる。 一方で、課題も残る。エージェントが「正しい答え」を返すには、SharePoint側のコンテンツが整理されていることが前提だ。ガバナンスが甘いまま機能だけ開放すると、かえって混乱を招きかねない。このロールアウトを機に、SharePointのドキュメント管理体制を見直す——そんな機会として捉えてほしい。 プラットフォームとしての底力は本物だ。だからこそ、基盤となるコンテンツ管理とガバナンスをしっかり整えた上で、この機能を最大限に活かしてほしいと思う。 出典: この記事は Microsoft Teams: Find SharePoint agents in Teams chats and Teams Store の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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

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

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

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

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