M365

Microsoft 365 の標準タスク管理ツール「Planner」に、AIエージェント機能が本格的に統合された。2026年3月、「Project Manager agent」として一部ユーザーに限定提供されていた機能が「Planner agent」と改称され、Microsoft 365 Copilot ライセンスを持つユーザーなら Planner の基本プランでも利用できるようになった。早ければ2026年5月初旬に一般提供（GA）が完了する見込みだ。 Planner Agent とは何か Planner Agent の役割は、タスクの「実行方法を提案する」ことだ。ユーザーは通常通りタスクを作成し、そこに Planner Agent をアサインするだけでよい。エージェントはバックグラウンドでタスクの詳細情報を解析し、数分後に「このタスクをどう進めるか」のステップバイステップな提案を生成して返す。 提案内容は Microsoft Loop コンポーネントとして格納される。これにより、プランのメンバー全員がリアルタイムで同時編集できる。Teams アプリまたはブラウザクライアントから確認・修正が可能で（現時点でモバイルクライアントは非対応）、情報が不十分だと感じたら何度でも再生成をリクエストできる。 処理の流れは以下のように進む: Queued（待機中） → タスクを AI 処理キューに投入 In Progress（処理中） → バックグラウンドで分析・提案生成 Ready（完了） → 担当者にメール通知＆Loop コンポーネントに提案が表示 タスクに付随する Task Chat 機能を使えば、生成された提案をチームで議論しながら精度を高めることもできる。 ライセンス変更の実務インパクト 今回の変更で重要なのは「ライセンス要件の緩和」だ。従来は Planner Premium（Project Plan 相当）が必要だったが、M365 Copilot ライセンスさえあれば Planner Basic でも利用可能になった。 日本企業では Planner を Teams と組み合わせて軽量なタスク管理として使っているケースが多い。Premium を契約せず Basic のまま運用している組織でも、M365 Copilot ライセンスを持つユーザーに AI 支援が届くようになったのは、実務上のインパクトが小さくない。 IT 管理者が確認すべきポイント: テナントのロールアウト状況を確認する: ターゲット リリーステナントでは 2026年3月末に展開済み。標準テナントは 5月初旬を目安に確認を Planner Agent の利用状況はアクティビティ タブで可視化: プランメンバー全員が AI 提案を参照できる設計なのでガバナンス上も把握しやすい Loop との連携を理解しておく: 提案は Loop コンポーネントとして保存される。Loop のアクセス権設定が Planner Agent の利用体験に影響する点に注意 実務での活用ポイント Planner Agent を有効活用するカギは「タスクの記述品質を上げること」に尽きる。「〇〇を対応する」のような曖昧な記述では、エージェントが生成できる提案も当然ぼんやりしたものになる。 ...

Microsoft 365の新たな最上位SKU「Microsoft 365 E7」がついに正式発表された。長らく噂されていた構成がついに確定し、2026年5月1日に一般提供（GA）が開始される。単なるバンドルの拡充ではなく、「人間が意思決定し、AIエージェントが実行する企業」への移行を見据えた構造転換と捉えるべき発表だ。 E7の構成——4つの柱と「Work IQ」 E7は以下の4コンポーネントを統合したスイートとして設計されている。 Microsoft 365 E5 Defender・Intune・Entra・Purviewを含むセキュリティ・コンプライアンス基盤。E7の土台となるレイヤー。 Microsoft 365 Copilot（Wave 3） Word・Excel・PowerPoint・Outlook・Teamsに直接組み込まれたAIアシスタント機能。Wave 3では文書生成・データ分析・コラボレーション支援がさらに強化された。Copilotは複数の基盤モデルを活用するマルチモデル設計となっており、企業ワークロードに応じた柔軟性を持つ。 Microsoft Entra Suite ユーザー・デバイス・AIエージェントを横断するID保護とアクセスガバナンスを提供。「シャドーAIボット」の不正アクセスを防ぐ仕組みを含む。Non-Human Identities（NHI）——サービスプリンシパルやマネージドIDを含むAIエージェントのID——を適切に管理するための基盤として機能する。 Microsoft Agent 365 組織内に展開された複数のAIエージェントを一元的に可視化・管理・セキュア化するコントロールプレーン。IT部門・セキュリティチームがエージェントの動作を監査・制御できる。 これら4つの柱の下に流れる共通インテリジェンス層がWork IQだ。組織固有のデータと知識を使ってすべてのアクションを導く仕組みで、「人間の意図とAIの行動を信頼でつなぐ」という設計思想を体現している。 価格——$99/ユーザー/月の意味 E7の価格は月額$99/ユーザー。構成要素を単品で購入した場合との比較は以下のとおりだ。 コンポーネント 単品価格 Microsoft 365 E5 $60/ユーザー/月 Microsoft 365 Copilot $30/ユーザー/月 Microsoft Agent 365 $15/ユーザー/月 合計（Entra Suite除く） $105/ユーザー/月 Microsoftは「最大15%の節約」と訴求するが、Entra Suiteが実質タダで付いてくる計算になる。Entra Suiteを既存ライセンスで別途調達している組織や、Copilotの追加購入を検討中だった組織にとっては、E7への統合移行が合理的なシナリオになりうる。 ただし、ベースラインがE5（$60）の組織にとっては$39/ユーザーの追加投資となる。「AIエージェントをどれだけ本気で動かすか」という組織の覚悟によって、この差額の評価は大きく変わる。 日本IT現場への影響 AIエージェントのガバナンス問題が顕在化する 日本でもAIエージェントの試験的な利用が増えつつある。問題は「動かす」ことではなく「管理する」ことだ。E7が提供するAgent 365は、エージェントのIDをEntraで管理し、Defender/Purviewでセキュリティ監査を通すという一連の流れを統合する。コンプライアンス要件が厳しい金融・医療・製造分野ほど、この「エージェントの可視化と制御」は欠かせない。 NHI管理が自動化推進のカギ AI活用の本丸はNHI（Non-Human Identities）の整備にある。人間の承認フローを挟むたびに自動化の恩恵は薄れる。Entra SuiteによるNHIの適切な権限管理・Just-In-Timeアクセス制御が実装されてはじめて、AIエージェントによる業務実行が安全かつスムーズに回る。この観点で、Entra Suiteがバンドルされたことの意義は大きい。 ライセンス設計の見直しタイミング E3からE5への移行を済ませていない組織も多い日本では、E7の導入は当面「検討フェーズ」になるだろう。ただ、AIエージェント管理の基盤整備を真剣に考えるなら、E7の構成をリファレンスとして自社のロードマップに組み込む価値はある。 筆者の見解 E7は「統合プラットフォームとしてのMicrosoft 365」の論理的な到達点だ。バラバラに買い足してきたCopilot・EntraをひとつのSKUに収め、AIエージェントの管理基盤まで一体化した構成は、方向性として正しい。 特に評価したいのはAgent 365の存在だ。AIエージェントの乱立と管理不全は、今後の企業AI展開における最大のリスクのひとつになる。そのコントロールプレーンをセキュリティ・ID管理と統合して提供するというアプローチは、ベンダーロックインの批判を受けながらも、実務的な価値を持つ。 一方で、正直に言えば、Copilotへの期待がこれまで十分に満たされてこなかった経験を持つ組織は少なくない。「Wave 3でどこまで変わるか」——その問いに答えを出せるのは、実際に使い込んだ結果だけだ。ただ、Microsoftにはこれだけの統合基盤を持つ底力がある。そのポテンシャルを存分に発揮してほしいと、率直に思う。 月額$99という価格は安くない。しかし「AIエージェントをガバナンス付きで全社展開する」という目的に対するコストとして見れば、個別調達より筋の良い選択になりうる。5月1日のGA以降、具体的な機能の動作検証を積み重ねながら、導入判断を冷静に行っていきたい。 ...

Microsoft 365のコンテンツをAIクエリのコンテキストとして活用する「Copilot Retrieval API」が、Microsoft Graph PowerShell SDKから利用できるようになっている。このAPIはRAG（Retrieval Augmented Generation）の仕組みでSharePoint OnlineやOneDrive for Businessを検索し、生成AI処理前のグラウンディングを担う。単なる検索ではなく、アプリケーションがどのようにCopilotと連携しているかを理解する上でも重要なAPIだ。 Copilot Retrieval APIとは何か Microsoft Graph上に公開されているCopilot Retrieval APIは、アプリケーションがユーザーのプロンプトを送信する前に、M365上の関連情報を取得してコンテキストを補完するための仕組みだ。このプロセスが「グラウンディング」と呼ばれる。 よく似た名前のCopilot Search APIも存在するが、両者には明確な違いがある。 API 検索方式 用途 Copilot Search API セマンティック検索 キーワード・意味的類似性 Copilot Retrieval API RAG検索 AIプロンプトのグラウンディング WordやExcel、PowerPointにCopilotが統合されている際に裏側で行っている処理がまさにこのRetrieval APIを通じた情報取得だ。APIを触ることで、Copilotの統合がどのように機能しているかを実感できる。 利用条件と認証の仕組み 利用にはM365 Copilotライセンスが必要だが、従量課金（Pay-as-you-go）モデルでも利用可能だ。重要なのは、このAPIが委任アクセス許可（Delegated Permissions）のみをサポートしている点で、アプリケーション権限（App-only）では動作しない。 必要なスコープは以下の通り： Files.Read.All — OneDrive for Businessのファイルアクセス Sites.Read.All — SharePoint Onlineのサイトアクセス ExternalItem.Read.All — Copilotコネクタ経由の外部データ（オプション） サインインしているユーザーの権限範囲でのみ検索できる設計は、情報漏洩リスクを最小化するという観点で適切な設計だ。 PowerShellでの実装 Graph PowerShell SDK v2.35.1を使った基本的な実装は以下の通りだ。 出典: この記事は Running Copilot Retrieval Searches with the Microsoft Graph PowerShell SDK の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

サービスアカウント、APIキー、マネージドID、そしてAIエージェント——企業のシステムには今、人間のユーザーをはるかに超える数の「非人間ID（Non-Human Identities / NHI）」が存在している。SANS Instituteが2026年に実施した「State of Identity Threats & Defenses」調査によれば、こうしたNHIがサイバー攻撃者の主要ターゲットになりつつあることが改めて浮き彫りになった。 NHIとは何か、なぜ今問題なのか NHIとは、人間ではなくシステムやアプリケーション、自動化スクリプト、AIエージェントが使用するIDのことだ。具体的には以下が該当する。 サービスプリンシパル（Azure AD / Entra IDに登録されたアプリID） マネージドID（Azure VMやFunctionsに付与されるID） サービスアカウント（Active Directoryの従来型） APIキー・OAuthトークン CI/CDパイプラインのシークレット AIエージェントに付与された権限 問題の核心は「数の爆発」と「管理の放置」が同時進行していることだ。デジタル化・自動化の加速で、エンタープライズ環境のNHI数は人間アカウントの数十倍に達していることも珍しくない。しかし人間のアカウントと違い、NHIには多要素認証（MFA）が使えず、パスワードローテーションは手作業で後回しにされがちで、誰が何の目的で作ったかすら不明になっているケースも多い。 攻撃者はどう悪用するのか 攻撃者が好むのは「不正侵入」よりも「正規ログイン」だ。漏洩したAPIキーや長期有効なサービスアカウントのクレデンシャルを入手すれば、侵入検知をすり抜けながら長期間にわたって環境内を横移動できる。NHIは往々にして過剰な権限（必要以上のロール割り当て）を持ち、アクセスログの監視も甘いため、侵害されても発見が遅れやすい。 さらにAIエージェントの台頭が新たなリスクを生んでいる。自律的にAPIを呼び出し、データにアクセスし、外部サービスと連携するAIエージェントは、正しく管理されなければ攻撃者にとって「特権を持つ踏み台」になりうる。エージェントに付与した権限の棚卸しは、多くの組織でまだ手つかずだ。 実務での対策ポイント 1. 棚卸しから始める まず自社のNHIを把握せずして対策はできない。Entra IDの「エンタープライズアプリケーション」と「アプリ登録」の一覧、Active Directoryのサービスアカウント、各クラウドサービスのAPIキー発行履歴を洗い出し、「誰が・何のために・いつ作ったか」を記録する。 2. 最小権限の徹底 既存のNHIが必要以上のロールを持っていないか確認する。Azure環境であればMicrosoft Entra ID Governanceのアクセスレビュー機能を活用し、定期的に権限を見直す仕組みを作ることが重要だ。 3. Just-In-Time（JIT）アクセスの導入 常時アクセス権を付与するのではなく、必要なときだけ一時的に権限を昇格させるJITモデルへの移行を検討する。Microsoft Entra Privileged Identity Management（PIM）はNHIにも対応範囲が広がっており、サービスプリンシパルへの適用も進めるべきだ。 4. シークレットの自動ローテーション APIキーやクライアントシークレットの有効期限を短く設定し、Azure Key VaultやGitHub Actionsのシークレット管理機能を使った自動ローテーションを実装する。「手動でやるから後回し」が最大の脆弱性になる。 5. 異常検知の設定 NHIの通常の行動パターンを把握し、異常なAPIコール・深夜アクセス・普段と異なるリソースへのアクセスをMicrosoft Sentinel等でアラートする。 日本のIT現場への影響 日本の大手エンタープライズ環境では、オンプレミスのActive Directoryにサービスアカウントが山のように積み重なっている光景がいまだに珍しくない。クラウド移行の文脈でNHI管理のモダン化を後回しにした結果、ハイブリッド環境の「悪魔合体」状態が生まれ、攻撃サーフェスが見えにくくなっている。特にCI/CDパイプラインの普及で、GitHubリポジトリやAzure DevOpsに長期有効なシークレットが埋め込まれたままのケースは要注意だ。 筆者の見解 NHIの重要性は、単なるセキュリティリスクの話ではないと筆者は考えている。これは業務自動化の根幹に関わる問題だ。 ボトルネックは常に「人間」にある。承認フローが人間依存である限り、どれだけAIや自動化ツールを導入しても処理速度には限界がある。NHIをきちんと管理し、サービスプリンシパルやマネージドIDに適切な権限を与えて自律的に動かせる環境を作ることが、真の業務効率化の前提条件になる。NHI管理ができない組織は、自動化も進まない。 一方でセキュリティの観点から言えば、「今動いているから大丈夫」という発想は通用しない。10年前に作ったサービスアカウントが今もフルアクセス権限で生きていることは珍しくなく、それが侵害の入り口になる。ゼロトラストの文脈では、NHIも人間アカウントと同じレベルの「検証・最小権限・継続監視」が求められる。 AIエージェントに権限を与えてビジネスプロセスを動かすことへの期待は今後さらに高まる。だからこそ、今のうちにNHI管理の基盤を整えておくことが、次の自動化フェーズへの最短経路になる。「セキュリティ対策」ではなく「自動化投資」として取り組む視点が、組織の動き方を変えるはずだ。 出典: この記事は Non‑Human Identities Are Becoming a Prime Target in Identity Attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがWindows 365 Cloud PCの監視・レポート基盤を刷新し、パブリックプレビューとして公開した。これまで複数の場所に散らばっていた健全性・パフォーマンス・構成情報を、Microsoft Intuneの単一画面に集約する取り組みだ。 これまでの課題：情報が「バラバラ」だった Windows 365 Cloud PCの管理をしている管理者なら、この悩みには身に覚えがあるはずだ。パフォーマンスの問題を調査しようとすると、Intuneのデバイス詳細、Windows 365管理センター、Endpoint Analyticsと、いくつものポータルを行き来しなければならなかった。情報は存在しているが、一か所で見られないという非効率さが現場の管理工数を押し上げていた。 この状況を解消するのが今回のアップデートの狙いだ。健全性（Health）・パフォーマンス（Performance）・構成（Configuration）の3軸のデータをIntuneの統合ビューで確認できるようにすることで、トラブルシュートから定期レポートまでをワンストップで完結させる設計になっている。 何が変わるのか：統合ダッシュボードの概要 新しいモニタリングプラットフォームでは、主に以下の情報が一元管理される。 Cloud PCの健全性スコア: 接続成功率・セッション品質などの指標 パフォーマンスメトリクス: CPU/メモリ使用率、ユーザー体験に影響する遅延指標 構成の整合性確認: ポリシー適用状況や設定の逸脱検知 レポートは管理者向けの集計ビューと、個別デバイスへのドリルダウンの両方をサポートする見通しだ。 実務への影響：IT管理者が得られるメリット 日本の現場において、Windows 365 Cloud PCを導入している組織はまだ少数派だが、テレワーク対応や拠点統廃合の文脈でCloud PC採用を検討している企業にとっては、このタイミングで管理基盤の成熟度を確認しておく価値がある。 明日から使える実務ポイント： パブリックプレビュー段階での評価を推奨: 現在はプレビューのため本番環境への影響を気にせず機能を試せる。POC（概念実証）環境があるなら積極的に有効化してみよう 既存のEndpoint Analyticsとの役割分担を整理: 重複する情報と新規追加情報を把握しておくと、将来的な移行やダッシュボード統廃合の判断が楽になる レポートをコンプライアンス根拠に活用: Cloud PCの利用状況をレポートとして自動取得できるようになれば、ライセンス最適化やセキュリティ監査の説明資料として再利用できる 筆者の見解 Microsoftのエンタープライズ製品に長く関わってきた立場から言うと、「統合して管理する」という方向性そのものは正しいし、今回の取り組みはその路線上にある。Microsoft 365はバラバラに使っても意味がなく、統合して初めて価値が出るプラットフォームだ。監視・レポートの一元化はその思想の体現であり、評価できる。 ただし、こういった基盤整備がもう少し早ければよかったというのが率直な思いだ。Windows 365は2021年のローンチから数年が経過しており、「管理データが散在していて使いづらい」という声は現場から初期から上がっていた。ようやく腰を上げた、という印象は否めない。 とはいえ、やらないよりはるかにいい。プラットフォームとしての底力はMicrosoftには間違いなくある。IntuneというIT管理の中枢にCloud PC監視を統合するという判断は正しく、ここをしっかり作り込んでいけば現場の運用負荷は確実に下がる。今後GAに向けてどこまで機能が充実するか、引き続き注目していきたい。 Cloud PCの導入を検討している組織は、このタイミングで管理基盤の成熟度を改めて確認してみるといいだろう。 出典: この記事は Microsoft Previews New Windows 365 Monitoring and Reporting Platform の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Security Copilotが「現場でどう使われているか」を伝える実践レポートが注目を集めている。M365 E5/E7ライセンスを持つ組織を対象に、SCU（Security Compute Units）の最適な割り当て方法からDefenderおよびPurviewとの連携設定まで、実際の展開経験に基づく知見がまとめられた。日本語圏ではほぼ報じられていないレベルの実務情報であり、国内のセキュリティ担当者にとっても無視できない内容だ。 Security Copilotとは何者か Security Copilotは、MicrosoftのDefenderやSentinel、Purviewといったセキュリティ製品群にAIアシスタントを組み込んだサービスだ。インシデント調査のサマリー生成、スクリプト解析、脅威ハンティングの効率化などを目的として設計されており、E5/E7ライセンス保有組織には特に親和性が高い。 利用にあたっては「SCU」と呼ばれるコンピューティングリソース単位を購入・割り当てる必要がある。このSCUをどの製品ワークロードにどれだけ割り当てるかが、導入効果を左右する最初のハードルとなる。 SCU割り当ての現場知見 現場レポートが強調するのは、SCUは一律に分散させるのではなく、最も利用頻度の高いワークロードに集中させるという原則だ。DefenderとSentinelを中心に運用しているSOCチームであれば、まずそこへの割り当てを手厚くし、Purviewへの展開は利用状況を見ながら段階的に拡大する戦略が現実的とされる。 初期に過剰なSCUを確保してしまうと、使われないリソースにコストが発生する。逆に不足すると応答品質が下がりAIが使い物にならない印象を組織に与えてしまうため、スモールスタートと段階的スケールが推奨される。 Defender/Purview連携の設定ポイント Defender XDRとの連携では、インシデントのAIサマリー機能が実用的な評価を受けている。アラートの優先順位付けや初動対応のドラフト生成において、SOCアナリストの作業負荷を軽減できるという報告がある。 一方でPurviewとの連携は設定の複雑さが増す。データ分類ラベルや情報保護ポリシーと連動させるには、テナントのコンプライアンス設定が一定の完成度に達している必要があり、Purview側の下地が不十分なまま連携しようとすると機能が中途半端にしか動かないという点は現場でも繰り返し指摘されている。 また、マルチテナント環境では権限分離の設計に注意が必要だ。Security Copilotは組織全体の情報へのアクセスを前提とした設計になっているため、アクセス権の最小化（最小特権の原則）との整合性を設計段階から意識しておくことが欠かせない。 実務への影響——日本のIT現場で何が変わるか 国内のM365 E5導入組織、特に金融・製造・医療といった規制業種では、Defender for Cloud AppsやPurview Information Protectionをフル活用しているケースが増えている。そうした環境では、Security CopilotのAI機能が既存のワークフローと噛み合う可能性がある。 実務で明日から意識すべきポイントを整理しておく。 現状把握から始める: 自組織のSentinel/Defender活用度を棚卸しし、AIが介在できる作業（アラートトリアージ、インシデントレポート作成）を特定する Purview先行整備: Security Copilotを入れる前に、Purviewのラベル体系とポリシーを整理しておく。AIが「整理されていない情報」を前提に動くと効果が薄い SCUは最小構成から: まず1〜2SCUで試験運用し、実際の問い合わせ量と応答品質を計測してからスケールを判断する Just-In-Timeアクセスの設計: Security Copilot自体が広い権限を要求するため、Privileged Identity Management（PIM）と組み合わせた運用設計を必須とすること 筆者の見解 Security Copilotというプロダクトについては、正直に言えばまだ「使えるかどうか」の評価が分かれる段階だと見ている。 ただ、今回のようなフィールドレポートが示す方向性は正しい。機能の良し悪しを語る前に、基盤となるDefenderやPurviewが正しく設定されているかどうか——この順番を守ることは、AIツールに限らずセキュリティ製品全般に言えることだ。AIが優秀であっても、食わせるデータが整理されていなければ価値は出ない。これはシステム設計の基本であり、「AIを入れれば改善される」という幻想を持たないことが肝心だ。 ゼロトラストの観点から見ると、Security Copilotが要求する広範なアクセス権はアーキテクチャとの緊張関係を生む。「SOCに必要な情報へのアクセス」と「最小特権の原則」をどう両立させるか——ここが設計の核心になる。常時アクセス権を渡すのではなく、PIMと組み合わせた一時的な昇格アクセスを前提とした設計を推奨したい。 Microsoftがセキュリティ製品群をAIで束ねるという方向性そのものは、統合プラットフォームとしての強みを活かす正しい戦略だと思う。個別ツールを寄せ集めるより、Defender・Sentinel・Purviewを同一エコシステムで扱える強みは本物だ。このアーキテクチャの優位性を、AIの実力でちゃんと証明してほしい。そのポテンシャルは確かにある。 出典: この記事は Microsoft Security Copilot for M365 E5/E7 recommendations from the field の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「待ったなし」の近代化月間——2026年4月M365アップデート総まとめ 2026年4月のMicrosoft 365は、機能追加と同じくらい「廃止」が目立つ月だ。SharePointのクラシック機能群がいよいよ完全終了し、パスワードレス化の推進も管理者側に強い権限が与えられた。さらにAIがセキュリティ・コンプライアンス領域にも本格的に組み込まれてきた。Message Centerの通知を読み飛ばしていた担当者にとっては、今月こそ「後で読む」が許されない月になる。 廃止ラッシュ：SharePointレガシーとの決別 今月最大のインパクトは、SharePoint旧機能の一斉終了だ。 4月2日に完全終了した主な機能： SharePoint 2013ワークフロー — 延長なし、例外なし。Power Automateへの移行一択 SharePoint アドイン — 既存テナントも含め動作停止。Microsoft 365 Assessment Toolでスキャンし、SPFx（SharePoint Framework）への移行が必要 Azure ACS（Access Control Service） — ACS認証を使っているアプリはそのまま壊れる。Microsoft Entra IDへの移行が急務 ドメイン分離SPFx Webパーツ — 描画時にエラーが発生する。通常のSPFxへの変換が必要 さらに情報管理ポリシー・インプレースレコード管理・削除専用ポリシーも廃止済み。これらはMicrosoft Purview データライフサイクル管理＆レコード管理への移行が求められる。 Teams関連ではViva Engage ライブイベント（旧Teams Live Events）が4月15日で新規作成不可に。Teams Town Hallsへの切り替えが必要だ。 新機能ハイライト：アイデンティティとAIの前進 廃止の陰に隠れがちだが、新機能も充実している。 パスキー登録キャンペーン（Entra ID） これは注目度が高い。管理者が「パスキー登録キャンペーン」を起動することで、ユーザーにパスキー登録を促す（強制も可能）ようになった。これまでMicrosoft Authenticatorアプリへの誘導が中心だったが、パスキーへの直接誘導が選択できるようになった。Microsoftは条件が整ったテナントに対して自動切り替えを行う可能性も示唆している。 クロステナントIntune MAM（Edge） 外部委託先やパートナー企業の端末に対して、デバイス登録なしで企業データを保護できる。M&Aやアウトソーシングが多い日本の大企業環境で特に効いてくる機能だ。 Teams Phoneの複数電話番号対応（最大10番号/ユーザー） コンタクトセンターや複数拠点をまたぐ担当者、エグゼクティブ秘書業務への活用が想定される。 AI搭載DLPアラートサマリー（Defender XDR） Purview Triage AgentがDLPアラートを自動要約する機能が入った。大量のアラートに埋もれているSOCチームにとって、トリアージ工数の削減につながる可能性がある。 実務への影響：今月動かなければ本番障害になる SharePoint関連の廃止は「予告通り来た」ものだが、見落としているケースが驚くほど多い。特に気をつけたいのは以下の3点。 ACS認証の残存チェック — 古いカスタムアプリや外部ベンダー提供のアドインがACSを使っていることがある。Microsoft 365 Assessment Toolを今すぐ走らせ、残存リスクを可視化すること 2013ワークフローのPower Automateへの移行 — 「誰が作ったかわからない」古いワークフローが最も危険。IT部門だけでなく業務部門への確認も必要 パスキー展開の計画策定 — 管理者主導のパスキー登録が可能になった今、パスワードレス化のロードマップを持っていないテナントは遅れを取り始める 筆者の見解 ゼロトラスト推進の観点から言うと、今月のEntraパスキーキャンペーン機能は評価に値する。VPNや従来型パスワード認証の延命に腐心している国内企業が多い中、管理者が「プッシュ」できる仕組みは実際の展開加速に直結する。「ユーザーが自分で登録しない問題」を組織的に解決できるアプローチは、現場で長年詰まってきたボトルネックへの現実的な答えだ。 ...

SharePointを業務の中核に置いている組織にとって、2026年春は「静かな地雷原」になりつつある。レガシー認証方式であるIDCRL（Identity Claims-based authentication Runtime Library）が2026年5月1日をもって完全廃止される。すでにSharePoint Add-InとAzure ACSは4月2日に廃止済みであり、猶予期間は事実上ほぼ残っていない。 何が廃止されるのか 今回の廃止は三段階で構成されている。 第一弾（完了済み）: SharePoint Add-InおよびAzure ACS（Access Control Service）が2026年4月2日に廃止。古いアドイン型の連携ソリューションは、この時点でアクセスが停止している可能性がある。 第二弾（4月中）: 情報管理ポリシー（Information Management Policy）、インプレース・レコード管理（In-Place Records Management）などのコンプライアンス機能が順次廃止。これらはMicrosoft Purviewへの移行が必須となる。 第三弾（5月1日）: IDCRL認証自体が完全廃止。IDCRLはSharePoint Onlineに対してユーザー名とパスワードで認証するレガシーな仕組みで、古いPowerShellスクリプト、カスタムアプリ、サードパーティ連携ツールの多くがこれに依存している。 なぜ今これが重要か IDCRLの廃止が特に日本のIT現場に響く理由は、「動いているから問題ない」という思い込みで長年放置されてきたスクリプト群が多数存在するからだ。SharePoint Onlineと連携するPowerShellの自動化、社内ポータルからのドキュメント取得処理、外部ベンダーが数年前に納品したカスタムソリューション——これらのどこかにIDCRLが潜んでいないか、今すぐ棚卸しが必要だ。 セキュリティの観点からも、IDCRLはゼロトラスト・アーキテクチャとは相容れない旧世代の認証モデルだ。常時アクセス権の付与や単純なパスワード認証への依存は、現代のセキュリティ要件では許容できない。廃止は「終わり」ではなく、正しい方向への押し出しと捉えるべきだろう。 移行先と対処方法 認証まわりの移行 IDCRLに依存している連携処理は、Entra ID（Azure AD）のOAuth 2.0 / OpenID Connectベースの認証に切り替える必要がある。具体的には以下のいずれかを選択する。 PnP PowerShell: Connect-PnPOnline でEntra IDアプリ登録を使ったモダン認証に対応している。古いSPO管理シェルでユーザー名・パスワードを直打ちしているスクリプトは全滅と考えてよい Microsoft Graph API: SharePointのデータにアクセスするなら、今後はGraph APIが標準経路。アプリケーション権限（クライアントクレデンシャル）またはデリゲート権限（ユーザー代理）のどちらを使うか、要件に合わせて設計する SharePoint REST API / CSOM: モダン認証トークン（Bearer Token）と組み合わせれば引き続き使用可能 コンプライアンス機能の移行 In-Place Records ManagementやInformation Management Policyを使っていた場合は、Microsoft Purviewのレコード管理に移行する。保持ラベル（Retention Labels）と保持ポリシー（Retention Policies）を使うことで、より細かい制御と監査ログが得られる。 実務への影響と確認ポイント 移行対応の優先度を決めるために、以下を今週中に確認してほしい。 Entra IDのサインインログを確認: KindOfTokenUsed = Legacy や ClientAppUsed = IDCRL でフィルタリングすると、まだIDCRL認証を使っているアプリが特定できる PowerShellスクリプトの棚卸し: -Credential パラメーターでユーザー名・パスワードを直接渡しているスクリプトは要注意 サードパーティ製品のバージョン確認: SharePoint連携を持つ製品（DMS、ワークフローツール等）のベンダーにモダン認証対応状況を確認する Azure ACS連携の確認: 4月2日廃止分が既に影響していないか、実際に動作確認を行う 筆者の見解 IDCRL廃止は、正直「なぜ今まで残っていたのか」と思うくらい遅すぎた決断だ。OAuth/OIDCが業界標準になって久しい中で、レガシー認証の延命措置が長年続いてきた。 ...

外部AIがMicrosoft 365のデータに直接アクセスできる時代が、静かに始まっている。Anthropicは2026年4月、同社のAIアシスタント「Claude」向けのMicrosoft 365コネクターを、無料プランを含む全ユーザーに開放した。SharePoint、OneDrive、Outlook、Teamsのデータを自然言語で横断検索できる——これが何を意味するか、M365管理者の視点で丁寧に読み解いていく。 MCPサーバーという選択肢 今回のコネクターは、近年急速に普及しつつあるMCP（Model Context Protocol）を採用している。MCPはAIモデルが外部ツールやデータソースと連携するための標準的なプロトコルであり、AnthropicはこれをMicrosoft Graph APIへのブリッジとして活用した。 インストールすると、Entra ID上に2つのエンタープライズアプリが登録される。 M365 MCP Server for Claude（アプリID: 07c030f6-5743-41b7-ba00-0a6e85f37c17） M365 MCP Client for Claude（アプリID: 08ad6f98-a4f8-4635-bb8d-f1a3044760f0） サーバーアプリがGraph APIへの各種権限を持ち、クライアントアプリがサーバーアプリに対してaccess_as_userカスタム権限を通じて認証を担う構造だ。ClaudeはMCPクライアントとして動作し、サーバーが公開するツール（SharePoint検索、Teamsチャット読み取りなど）を呼び出す形になる。 権限の実態——「委任」であることの意味 パーミッションの一覧を見た瞬間、セキュリティ担当者は目を疑うかもしれない。Sites.Read.All、Mail.Read、Chat.Read……かなり広い範囲に見える。 しかし重要なのは、これらがアプリケーション権限ではなく委任権限（Delegated Permissions）である点だ。つまり、Claudeがアクセスできるのは「サインインしているユーザーが本来アクセスできる範囲」に限定される。Claudeが独自に他ユーザーのデータを閲覧したり、管理者権限で全社データを参照したりすることはできない。 また、アクセスは読み取り専用だ。Claudeはドキュメントの作成・編集・削除はできない。これは重要な制約であり、万一の場合のリスクを大幅に限定している。 加えて、特定の権限はコネクターの管理画面から無効化することも可能だ（その機能は使えなくなるが）。テナント管理者がリスク評価に応じて絞り込める余地がある点は評価に値する。 RCD（コンテンツ探索制限）との相性 実際の動作で興味深い挙動が報告されている。Microsoft 365 Copilotのインデックスから除外するために設定されたRCD（Restricted Content Discovery）が、Claudeの検索結果にも同様に作用したというのだ。 これはSharePoint Searchに依存しているからこその挙動であり、「CopilotのアクセスをRCDで制限したから安全」と考えていた運用担当者にとっては朗報だ。ただし逆に言えば、RCDを設定していないサイトのデータは外部AIにも到達しうることを意味する。既存のアクセス制御が正しく機能しているかを改めて点検する良い機会でもある。 実務での活用ポイント テナント管理者がまず確認すべきこと Entra IDのエンタープライズアプリ一覧を確認する: ユーザーが勝手にインストールしていないか定期的にチェックする仕組みを設けること。アプリIDは上記の通り公開されている。 ユーザーによるアプリ同意を制限しているか確認する: テナントの「ユーザー同意設定」が「管理者承認なしで同意可能」になっている場合、知らぬ間に広まる可能性がある。 RCDの設定状況を棚卸しする: 機密情報を含むサイトに適切なアクセス制御が設定されているか確認する。 積極活用を検討したいシーン 社内のSharePointに散在するドキュメントを横断的に検索・整理したい場合 Teamsの過去のチャット履歴や会議記録を自然言語で振り返りたい場合 Outlookのメール情報を元に定型的な作業（返信下書き、情報集約など）を補助したい場合 高度な分析や創造タスクに外部AIを活用し、日常的な議事録整理や定型業務にはCopilotを使うという「使い分け」の文脈で、このコネクターは一つの現実解になりうる。 筆者の見解 このコネクターの登場は、M365管理者にとって「そのうち来るとは思っていたが」という出来事だろう。OpenAIがChatGPT向けにM365連携を展開し、それに続く形で複数のAIサービスがMicrosoft 365のデータに触手を伸ばす——これは今後の標準的な流れになっていくはずだ。 個人的に注目しているのは、MCP（Model Context Protocol）という標準が着実に普及しつつある点だ。特定のベンダーに依存しない標準プロトコルを通じた連携が増えることは、長期的にはエコシステム全体の健全な発展につながる。 Microsoft側から見ると、これは複雑な局面でもある。M365という強力なデータプラットフォームを他社AIが活用しやすくなる一方、Copilot自身の価値をどう示していくかが問われる。Microsoftはプラットフォームとしての優位性を活かしながら、その上で動くAIの質でも正面から競争できるポジションにある。その実力を存分に発揮してほしい、というのが正直なところだ。 セキュリティの観点では、委任権限・読み取り専用・RCD対応という三つの制約が「最低限の安全網」として機能していることは確認できた。ただし「現在動いているから大丈夫」という判断は危険だ。Entra IDのアプリ管理やユーザー同意ポリシーの見直しを、この機会に必ず行うことを強くお勧めしたい。 外部AIがM365データに接続できる時代において、「禁止」を選ぶ組織は必ず抜け道を使われる。公式の管理された経路で安全に使える仕組みを整える——それがこれからのIT管理者に求められるスタンスだ。 出典: この記事は Using the Microsoft 365 Connector for Claude の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilotに、AnthropicのAIモデルが正式に統合された。Word・Excel・PowerPoint・Outlookといった日常業務の中核アプリから、複数の大規模言語モデル（LLM）を使い分けられる環境が整いつつある。「Copilot = GPT-4o」という時代は、静かに終わりを告げようとしている。 何が起きたのか Microsoftが展開中の「Wave 3 Copilot」アップデートの一環として、AnthropicのClaude 3.5 SonnetおよびClaude 4 Opusが、Microsoft 365 Copilot内から利用可能になった。組織がAnthropicコネクターを有効にすることで、既存のCopilotインターフェースからGPT-4oの代替として、あるいは並列で利用できるようになる。 注目すべきは「Researcher Council」と呼ばれる機能だ。GPTが初稿を生成し、Claudeがその正確性・完全性・引用整合性をレビューするというデュアルモデルアプローチを採用している。AIが互いに検証し合う仕組みは、品質担保の観点で興味深い設計だ。 技術的なポイントを整理する 長文コンテキスト処理の強み Anthropicのモデルは、大量のテキストを一度に処理する能力に定評がある。長文の契約書・仕様書・レポートなど、文書全体を把握した上で回答や要約を生成するユースケースでは、この特性が活きる。文書が長くなるほど、文脈の切り落としが発生しやすい小さなコンテキストウィンドウのモデルとの差が出やすい。 デュアルモデルの「ジュニア・シニア」構造 Researcher Councilの設計は、法律事務所の業務フローに例えると分かりやすい。ジュニアが下書きを作り、シニアがレビューする。AIの世界ではこれをモデル間で再現しているわけだ。ただし、このレビューがどこまで信頼に足るかは、実運用での検証が必要だ。AIによるAIのレビューは、万能な品質保証ではない。 利用上の制限事項（過信は禁物） 今回の統合は「CopilotというUIの中に別のモデルが入った」ものであり、用途によって重要な制限がある。 セッション間の文脈は引き継がれない: ドキュメントを閉じると前回の会話履歴はリセットされる リアルタイムのデータベースアクセスはない: 法令・判例データベース等への接続は別途必要 ハルシネーションのリスクはゼロではない: 引用や事実確認には人間の最終確認が必須 データの流れ: コンテンツはMicrosoftとAnthropicの双方のインフラを経由する。機密性の高い情報を扱う組織は、データガバナンスポリシーの確認が必要 実務への影響——日本のエンジニア・IT管理者は何をすべきか 今すぐ確認すべきこと Anthropicコネクターの有効化ポリシー: M365テナント管理者は、自社のデータ分類ポリシーに照らしてコネクター有効化の可否を判断する。機密データをAIに渡す際のデータ処理契約（DPA）の確認は必須だ ユーザー教育の更新: 「CopilotはGPT」という認識がある現場では、モデルが複数になったことを明示的に伝える必要がある。AIの使い分けが始まると、出力品質のバラつきに気づかないまま業務に使う社員が増えるリスクがある 用途別のAI設計: Teamsの議事録・Outlookの定型メールは自動処理で十分。一方、複雑なレポート分析や法務ドキュメントレビューには、より高度な推論能力を持つモデルを意識的に選択する設計が有効だ 「禁止」より「使い分けの仕組み」を作れ 「AIの使用を禁止する」アプローチは、現実的に機能しない。Copilotが標準装備になっている以上、何らかのAIは必ず使われる。IT管理者がやるべきことは禁止ではなく、「どのモデルをどの業務に使うか」のガイドラインを作り、組織として安全に活用できる仕組みを整えることだ。 筆者の見解 MicrosoftがCopilotに他社モデルを組み込むという判断は、率直に言って「正しい方向への一歩」だと思う。 この数年、Copilotの品質には正直なところ歯がゆさを感じてきた。Microsoft 365という強力なプラットフォームを持ちながら、そのAI機能が十分に力を発揮できていない場面が多かった。だからこそ、自社モデルに固執せず、外部の優れたモデルをエコシステムに取り込む判断は、プラットフォームとしての成熟を示すものとして評価したい。 Researcher Councilのデュアルモデルアプローチも興味深い。「モデルを組み合わせて品質を高める」という発想は、単一モデルへの依存から脱却する設計思想であり、これは長期的に正しい方向だ。 一方で、「Copilotの中にモデルが増えた」だけでは、真の意味での「AI活用の深化」にはならない。今後求められるのは、業務プロセスに応じてモデルを自動的に選択・切り替えるオーケストレーション層の充実だ。そのための基盤として、今回の統合が活きてくることを期待したい。 Microsoftには、統合プラットフォームとしての全体最適を実現できる力がある。バラバラに使えば意味がない。Word・Excel・Teams・Entraが一体となって動いてこそ、M365の本当の価値が出る。今回の動きが、そのエコシステム強化への布石であってほしい——そう思いながら、引き続き注目している。 出典: この記事は Claude AI in Microsoft 365 Copilot: Anthropic Models Now Available in Word, Excel, PowerPoint, and Outlook の内容をもとに、筆者の見解を加えて独自に執筆したものです。

多要素認証（MFA）を導入しているから安心、という認識が今まさに崩されようとしている。「EvilTokens」と名付けられた新型フィッシングキットは、MicrosoftのデバイスコードAuthentication Flowという正規の認証メカニズムそのものを武器に変え、AIと自動化を組み合わせて大規模な標的型攻撃を可能にしている。MFAを入れた企業が「対策済み」と油断するなかで、静かに侵害が広がっている点が最も深刻だ。 デバイスコード認証の仕組みと悪用の構造 Microsoftのデバイスコードフロー（Device Authorization Grant）は、ブラウザやキーボードを持たないデバイス——スマートTVやIoT機器、プリンター等——向けに設計された認証方式だ。ユーザーは別のデバイスから microsoft.com/devicelogin にアクセスし、表示されたコードを入力することで認証を完了させる。 EvilTokensはこの仕組みを逆手に取る。攻撃者があらかじめデバイスコードを生成し、それをフィッシングメールやTeamsメッセージなどに埋め込んで標的に送りつける。被害者が「正規のサインインページ」だと思ってコードを入力した瞬間、攻撃者側のセッションに有効なアクセストークンとリフレッシュトークンが払い出される。 ここが重要なポイントだ。 被害者は自分のパスワードとMFAを正しく使って認証を完了している。だからこそMFAが役に立たない。払い出されたトークンは長期有効であることも多く、攻撃者はパスワードを知らなくても長期間にわたって企業メールや各種M365サービスに侵入し続けられる。 さらにEvilTokensはAIによるフィッシング文面の自動生成と、攻撃フロー全体の自動化を組み込んでいる。従来の手動攻撃より大幅にスケールアップが可能で、一人の攻撃者が多数の標的を同時並行で狙える構造になっている。 狙われる情報と被害のシナリオ 主たる標的はExchange Online上の企業メールアカウントだ。侵害に成功した後、攻撃者は受信トレイを監視し、財務情報や契約書、社内決裁フローなどを収集する。BEC（ビジネスメール詐欺）への転用や、他社への横展開も容易に行える。 日本企業においても、M365を全社展開しているケースは珍しくなく、Teamsを業務連絡の主軸に置く組織ではフィッシングメッセージが社内連絡に見せかけて届くリスクがある。 実務での対策ポイント 1. デバイスコードフローを条件付きアクセスでブロックする 最も直接的な対策は、必要のない場面でデバイスコードフローそのものを無効化することだ。Microsoft Entra IDの条件付きアクセスポリシーで、デバイスコードフローを使用できる対象を管理デバイスや特定のIPレンジに限定する、もしくは原則ブロックする設定を適用する。多くの一般従業員にとって、このフローを使う正当な理由はほぼない。 2. 継続的アクセス評価（CAE）とトークン有効期間の見直し アクセストークンのデフォルト有効期間を短縮し、Continuous Access Evaluation（CAE）を有効にする。これにより、不審なセッション変化を検出した際にトークンをリアルタイムで失効させられる。 3. Microsoft Defender for Cloud Apps（MCAS）でトークン利用を監視 異常な地域からのトークン利用や、短時間での大量メール参照などの行動を検出するルールを設定しておく。侵害されていても早期に検知できる体制が欠かせない。 4. 社員教育でデバイスコードフィッシングを周知する 「MFAをきちんと使ったのに侵害された」という事例を共有し、「見覚えのないページにコードを入力しない」という習慣を根付かせる。ITリテラシー研修にこのシナリオを追加することを強く推奨する。 筆者の見解 セキュリティの話題は細かい議論になりがちで、正直あまり得意なジャンルではない——とはいえ、このトピックには技術的に強い関心を持っている。 EvilTokensが突いているのは、Microsoftが「利便性のために設計した正規機能」だ。悪意あるコードが混入したわけでも、脆弱性を突かれたわけでもない。ゼロトラストの観点からすれば、これは「デフォルトで過剰な信頼を与えてしまっているフロー」の問題に他ならない。必要な人だけが、必要なときだけ使える——そのJust-In-Timeの思想が徹底されていれば、攻撃面を大幅に削れる。 MicrosoftはEntra IDに条件付きアクセスやCAEといった強力な制御手段を持っている。問題は、それらの設定が「やろうと思えばできる」状態に留まっていて、多くの組織でデフォルトのまま放置されている点だ。「今動いているから大丈夫」という空気がある限り、こうした攻撃は静かに成功し続ける。 Microsoftにはゼロトラストの理念をより積極的に「デフォルト設定」へ組み込んでいってほしい。設定しなければセキュアにならないのではなく、設定しなくてもある程度セキュアである——そのベースラインを引き上げる力は、Microsoftには十分にあるはずだ。 出典: この記事は EvilTokens Phishing Kit Uses Microsoft Device Codes to Bypass MFA の内容をもとに、筆者の見解を加えて独自に執筆したものです。

M365 Community Conference 2026（4月下旬開催）の直前、SharePointチームが「AI引用の可視化と制御」に関わる新機能群を4月中にロールアウトすると発表した。Copilotが何を根拠に回答しているか見えづらかった状況に、ようやく管理者が踏み込める仕組みが整いつつある。 4月ロールアウト予定の3つの新機能 1. AI引用ランキング表示 SharePointサイト上で、Copilotが実際にどのページを「回答の根拠」として引用しているかをランキング形式で確認できるようになる。これまで、どの社内ドキュメントが使われているかは管理者にとってほぼブラックボックスだった。この機能で「頻繁に引用される高品質コンテンツ」と「引用されていないコンテンツ」が一目でわかるようになる。 2. サイト利用統計へのAI引用メトリクス追加 SharePointのサイト分析ダッシュボードに「Copilotに何回引用されたか」という新指標が加わる。従来のページビューやユニークユーザー数に並ぶ形で、AIの文脈でのコンテンツ価値が計測できるようになる。 3. Copilot検索の権威ソース（Authoritative Source）管理機能 3つの中でもっとも実務インパクトが大きい機能だ。管理者が「この種の質問にはこのSharePointサイトを優先して参照せよ」と明示的に設定できるようになる。Copilotの回答精度を、組織の意図として制御できる仕組みだ。 なぜこれが重要か Copilotを導入した多くの組織が「回答の品質にばらつきがある」「どこから引っ張ってきた情報なのかわからない」という課題を抱えてきた。その根本原因の一つは、SharePointに蓄積されたコンテンツの品質や信頼性にばらつきがあるにもかかわらず、Copilotがそれを区別できていなかった点にある。 権威ソース管理機能は、この問題に組織的に対処するための仕組みだ。「Copilotを野放しにするのではなく、組織が責任を持ってナレッジを管理する」というアプローチは、コンプライアンス要件が厳しい日本のエンタープライズにとっても重要な考え方になる。 またAI引用メトリクスは、コンテンツガバナンスに新しい評価軸をもたらす。「人が読んでいるか」だけでなく「AIが引用しているか」が文書の価値指標に加わることで、ナレッジマネジメント全体の設計が変わってくる。 実務への影響——日本のIT担当者が今すぐやるべきこと SharePoint管理者・情報システム担当者向け: 権威ソースの棚卸しを先に: 権威ソース管理機能を活用するには「どのサイトが公式情報源か」を組織で整理しておく必要がある。機能ロールアウト前に、古くなったコンテンツや重複情報の整理を進めておきたい AI引用ランキングを品質改善の起点に: 引用されているページの特徴（見出し構造・更新頻度・情報の正確性）を分析することで、「Copilotに正確に使ってもらえるコンテンツ」の書き方が見えてくる AI引用数をコンテンツKPIに加える検討を: 社内ポータルや部門Wikiの品質向上活動において、AI引用数を評価指標の一つとして組み込むことを検討する価値がある コンテンツ作成者向け: Copilotに「信頼できるソース」として認識されるには、情報の鮮度・正確性・構造化が重要だ。定期的なコンテンツレビューを習慣化し、陳腐化した情報を積極的に更新する体制を今から整えておくと、この機能が最大限に機能する。 筆者の見解 正直に言えば、「あって当然の機能がようやく来た」という印象は否めない。Copilotが何を参照しているか見えない状態でロールアウトを続けてきたことを考えると、管理者がブラックボックス感を抱えたのも無理はなかった。 とはいえ、今回のアップデートの方向性は評価したい。「Copilotの精度を組織側のガバナンスで高めていける」という設計思想は、これまでの「おまかせ」スタイルからの大きな転換だ。特に権威ソース管理機能は、真剣に活用すれば回答品質を劇的に改善できるポテンシャルを持っている。 SharePointは長年、組織の知識インフラとして地道に進化を続けてきた。ナレッジ管理に真剣に取り組んできた組織ほど、これらの機能のメリットを享受できる構造になっている。「ちゃんと使いこなしてきた組織が報われる」時代がようやく来るかもしれない——そう感じさせてくれるアップデートだ。 M365 Community Conference 2026の場でさらなる詳細が明らかになることを期待している。SharePointへの地道な投資が、AI時代に花開く局面が来ることを願いたい。 出典: この記事は Your Frontier Transformation Starts at the Door with SharePoint at M365 Community Conference 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 CopilotにPurview DLP（データ損失防止）ポリシーの直接適用と、新しい利用分析機能が追加された。組織がAI駆動のワークフロー全体を可視化・統制できるこの機能強化は、エンタープライズ展開を本気で考えるなら見逃せないアップデートだ。 Purview DLPがCopilotの出力に直接介入できるようになった 今回の目玉は、Microsoft PurviewのDLPポリシーがCopilotの出力フェーズに直接作用するようになった点だ。 従来、CopilotはExchangeやSharePointのようなDLP適用対象と別扱いになっており、Copilotのチャット応答に機密データが含まれていても制御が効かないケースがあった。今回の更新で、特定の機密ラベルが付与されたコンテンツを含む出力をブロックしたり、ユーザーに警告を表示したりといった制御が統合管理下に入る。 PurviewはすでにExchange・SharePoint・Teams・OneDriveなど広範なサービスに展開されており、Copilotがその管理体系に組み込まれることで、「AIだけ別ルール」という隙間を塞ぐ形になる。 分析機能の強化——利用実態が初めて見えてくる 新しいアナリティクス機能では、管理者コンソールからCopilotの利用状況をより粒度細かく把握できる。どのMicrosoft 365アプリでCopilotが活用されているか、プロンプトのカテゴリ分布、ユーザーの活用パターンといったデータが可視化される。 これは単なるレポート機能ではない。ライセンスコストに見合った活用がされているかを客観的に評価する「ROI測定の基盤」として機能する。経営層への説明責任を果たす材料としても使えるし、活用が伸び悩んでいる部署を特定してピンポイントで教育投資する判断にも役立つ。 実務での活用ポイント 情報システム部門・IT管理者へ：既存のPurviewポリシーをCopilotへ拡張適用する準備を今から進めておこう。機密ラベルの整理とDLPポリシーの棚卸しは、Copilot展開前にやっておくと後が楽になる。後から整備しようとすると現場との摩擦が大きくなりがちだ。 コンプライアンス・法務チームへ：Copilotの利用ログが取れる環境が整ってきた。「AIを使ってよい業務・使ってはいけない業務」の社内規程を明文化するタイミングとして、今がちょうどいい。監査対応への備えとしても有効だ。 経営層・予算承認者へ：アナリティクスで利用実態が可視化されると、使われていないライセンスの存在が明確になる。単純な削減ではなく、「なぜ使われていないか」を掘り下げ、本当に価値を生む使い方への転換に投資する判断軸として活用してほしい。 筆者の見解 率直に言えば、「やっと来た」という印象だ。 CopilotをエンタープライズAIとして本格展開するなら、DLP統合は最低限の前提条件のはずだった。ExchangeやSharePointで何年も前から実績のあるDLPが、Copilotには後追いで適用される形になったのは正直もったいない。ガバナンス機能が早期に揃っていれば、導入をためらっていた組織はもっと早く動けていただろう。 ただし、方向性は正しいし、Microsoftらしい強みを活かしたアプローチだと思う。Purviewという既存の統合管理資産をCopilotにも接続していく姿勢は、「バラバラなツールを寄せ集めた」競合との明確な差別化になりうる。この統合ガバナンスの路線を徹底的に磨き続けてほしい。それこそがMicrosoftに期待する正面勝負の姿だ。 一方で、アナリティクスが整備されると「思ったほど使われていない」という現実が浮き彫りになる組織が出てくるはずだ。数字を見てライセンスを削るのではなく、活用が伸び悩む根本原因——UIの使いにくさなのか、適切なユースケースの未整理なのか、研修不足なのか——を特定することが次のステップになる。ツールが揃い始めた今こそ、AI活用戦略を腰を据えて見直す好機だ。 出典: この記事は Microsoft 365 Copilot Gets Purview DLP Controls and New Analytics の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Backup に待望の機能追加が迫っている。2026年4月末から5月初旬にかけて、SharePoint サイトおよび OneDrive に対する「細粒度復元（Granular Restore）」が一般提供される予定だ。これまでは「復元ポイント全体に巻き戻す」しか選択肢がなかったが、今後は管理者が特定のファイルやフォルダを検索・選択して単体で取り戻せるようになる。 これまでの課題：「1ファイルのためにサイト全体を戻す」という現実 Microsoft 365 Backup は 2023 年に登場した比較的新しいサービスで、Exchange・SharePoint・OneDrive のデータを Microsoft のインフラ上でネイティブにバックアップする仕組みだ。サードパーティのバックアップ製品を別途契約しなくても M365 のライセンス体系の中でデータ保護を完結できる点が評価されてきた。 しかしこれまでの復元機能には大きな制約があった。復元の単位が「サイト全体」または「OneDrive 全体」に限られており、誤って削除したファイルを 1 本だけ戻したい場合でも、サイト全体を過去のある時点に巻き戻すしかなかった。当然ながら、その間に行われた他の更新も一緒に失われるリスクがある。現場の管理者からすれば「やっと使えるバックアップが来た」と思ったら実運用では二の足を踏む、という状況が続いていた。 何が変わるのか：アイテム単位での検索・選択・復元 今回の「Granular Restore」対応により、管理者は復元ポイントの中から目的のファイルやフォルダをピンポイントで検索し、選択した上で復元先を指定して取り戻せるようになる。全体ロールバックは不要だ。 主なシナリオとして想定されるのは以下のようなケースだ： 誤削除・誤上書き：ユーザーが重要な Excel ファイルを削除・上書きしてしまったが、直前の状態に戻したい ランサムウェア被害の部分回復：暗号化されたファイルだけを選んで復元し、被害を受けていない部分には手を触れない 意図的な変更の取り消し：特定のドキュメントライブラリに加えられた変更だけを元に戻したい いずれも「サイト全体を巻き戻す」前提では対応が難しかった典型例だ。 実務への影響：管理者・エンドユーザー双方に恩恵 IT 管理者へのインパクト これまで M365 Backup を「いざという時のための保険」として契約しつつも、実際に使うと副作用が大きすぎると判断し、サードパーティ製品を併用していた組織は多い。今回の対応により、M365 Backup 単体での運用が現実的な選択肢になってくる。ライセンスコストの見直し余地が生まれるかもしれない。 管理者が意識すべき実践ポイントは次のとおりだ： 復元ポイントの保持期間と頻度を見直す：細粒度復元が使えるようになっても、復元ポイント自体が少なければ意味がない。バックアップポリシーを改めて精査する機会にしよう 権限設計を確認する：誰が復元操作を実行できるかを明確にしておく。SharePoint 管理者と情報保護担当者の役割分担を整理する テスト復元を定期的に実施する：復元機能が使えることと、実際に期待どおりに動くことは別物。本番稼働前の検証習慣をつける エンドユーザーへのインパクト ユーザー側からは直接見えない機能ではあるが、「ファイルを誰かが消したかもしれない」「昨日の版に戻したい」といった問い合わせに管理者がより迅速かつ低リスクで対応できるようになる。結果としてビジネス継続性が向上する。 筆者の見解 M365 Backup が登場した当初から、「全体ロールバックしかできないのでは実用性に欠ける」という声は絶えなかった。この改善は方向性として正しいし、遅すぎたくらいだと思う。 Microsoft 365 のプラットフォームとしての強みは、バックアップ・コンプライアンス・セキュリティ・コラボレーションが一つの管理体系の中に収まっていることだ。その統合価値をフルに活かすためには、個々の機能が「実際に使えるもの」になっている必要がある。今回の Granular Restore はその一歩として素直に評価できる。 一方で、M365 Backup の認知度はまだ高くない。特に中堅・中小の日本企業では、データ保護の仕組みをサードパーティに丸投げしているか、あるいは「ごみ箱と過去バージョン履歴で何とかなる」という認識のままの組織も多い。今回のアップデートを機に、自社のデータ保護方針を一度棚卸しする価値はある。 Microsoft には、こうした地道な機能の完成度向上を今後も着実に積み重ねてほしい。プラットフォームとしての総合力はまだ他の追随を許さないものがある。その力をしっかり発揮したサービスが増えれば、現場の信頼はさらに厚くなるはずだ。 出典: この記事は Microsoft 365 Backup: Granular restore for SharePoint and OneDrive coming late April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ライセンス失効と同時にアクセス停止——「猶予」はもう存在しない 2026年4月1日付けで、Microsoft 365をCSP（クラウドソリューションプロバイダー）経由で契約している企業に対し、これまで提供されていた30日間の猶予期間（グレース期間）が廃止された。 これまでは、ライセンスが失効しても30日間はサービスが継続していた。言い換えれば「うっかり更新を忘れても翌月末まで大丈夫」というバッファが存在していた。このバッファが4月1日をもって消滅した。 代わりに登場した「Extended Service Term（延長サービス期間）」 廃止された猶予期間の代替として導入されたのが Extended Service Term（延長サービス期間） だ。自動更新が無効になっていて、かつ失効前に更新注文が入らなかった場合、サブスクリプションは自動的にこの状態に移行する。 サービスは継続されるが、料金は月次換算レート（年額プランの約20%割高）＋さらに3%のアップリフトが適用される。すなわち、更新忘れは実質的なコスト増に直結する。 ただし、Extended Service Termはいつでもキャンセル可能で、日割り課金となる点は柔軟性があると言えよう。 実務でのリスク：「気づいたらアクセス停止」は十分に起こりうる 日本の企業では、ライセンス管理を経理部門・購買部門・IT部門が三者で分担しているケースが多い。更新手続きの連絡が途切れたり、担当者の異動・退職があったりすると、更新漏れが起きる。これまでは猶予期間が事故を防いでいたが、今後はそのセーフティネットがない。 今すぐ確認すべき項目： テナントの自動更新設定の有効/無効状態 ライセンス更新フローの担当者と手順の文書化 更新期限の社内カレンダーへの登録と複数担当者への通知設定 Microsoft 365 E7——AIを「オプション」ではなく「基盤」として組み込んだ次世代SKU 2026年5月1日、Microsoftはエンタープライズ向け最上位ライセンスとして Microsoft 365 E7 を投入する。長年にわたってフラグシップの座にあったE5の後継に相当する位置づけだ。 E7の構成はE5のすべての機能に加え、以下が追加される： Microsoft 365 Copilot（月額従量課金のアドオンではなく包含） Entra Suite（旧Azure AD Premium含む包括的なID管理） Agent 365（組織内エージェントの統合管理・ガバナンス基盤） 何が変わるのか：AIが「使うもの」から「働くもの」へ E7の設計思想は明確だ。AIをユーザーがオプションで追加するツールではなく、組織のワークフローに深く組み込まれた実働基盤として位置づけることにある。 Agent 365を通じて、AIエージェントが個々のユーザーを補助するだけでなく、組織横断でタスクを実行・自動化し、かつそのガバナンス（権限管理・データ過剰共有リスクの監視）をプラットフォーム側で担う構成になる。 Agent 365の単独提供も開始 Agent 365はE7に包含されるだけでなく、単独ライセンスとしても5月1日から提供開始される。自社テナント内のすべてのマネージドエージェントを一元把握し、パフォーマンス・挙動・リスクシグナル（データ過剰共有の可能性など）に対して素早く対処できる仕組みだ。 Windows 10 Enterprise LTSB——2026年10月にサポート終了、ESU費用は毎年倍増 Windows 10 Enterprise LTSB（Long Term Servicing Branch）が2026年10月にサポート終了を迎える。 移行が難しい環境向けに延長セキュリティ更新プログラム（ESU）の購入は可能だが、費用は毎年倍増するモデルだ： 年 費用（1デバイスあたり） Year 1（2026年10月〜） 約65ユーロ Year 2（2027年10月〜） 約130ユーロ Year 3（2028年10月〜） 約260ユーロ ...

2026年5月1日、Microsoftが約10年ぶりとなる最上位エンタープライズライセンス「Microsoft 365 E7」と、新たなエージェント管理基盤「Agent 365」を一般提供開始する。AIエージェントが組織のあちこちに乱立しはじめた今、この発表は単なるライセンス体系の刷新ではなく、企業ITガバナンスの根本的な再設計を求める問いかけだ。 Agent 365とE7、何が変わるのか Agent 365はスタンドアロンで月額約15ドル（1ユーザー）から利用できる。提供する機能はシンプルだが本質的だ。 テナント全体のエージェントレジストリ：誰がどんなエージェントを動かしているかを一元把握 Microsoft管理センターで適用されるセキュリティポリシーテンプレート：属人化していたエージェント設定を標準化 エージェントのパフォーマンスと利用状況のレポーティング：ブラックボックスだったエージェント挙動を可視化 Entra、Defender、Purviewとの深い統合：既存のセキュリティスタックとシームレスに連携 一方、E7（「Frontier Suite」と位置づけられる）は月額約99ドル（Teamsを含む）で、M365 E5、Entra Suite、M365 Copilot、Agent 365、Work IQを統合したバンドルだ。個別に購入するより割安になるよう設計されている。 Microsoft自身がAgent 365を使って社内の50万超のエージェントを管理しており、プレビュー顧客はすでに数千万規模のエージェントをレジストリに登録済みだという。この数字は驚異的だが、同時に「管理されていないエージェントが今どれだけ野放しになっているか」の裏返しでもある。 セキュリティとガバナンス：問うべき3つの問い Agent 365の導入を検討するにあたって、セキュリティ・ID管理チームが先に答えておくべき問いがある。 1. エージェントのトラッキング体制は整っているか Agent 365はレジストリとポリシー層を提供するが、「どのチームがエージェントを作成できるか」「誰がレビューし、誰が承認するか」というプロセスは組織が定義する必要がある。ツールを入れれば自動的にガバナンスが生まれるわけではない。 2. エージェントへのID・アクセスポリシーは設計済みか Entraを使えばユーザーだけでなくエージェントにも固有IDと条件付きアクセス（CA）を付与できる。「人の代理で動作するエージェント」と「限定スコープに閉じるエージェント」のパターン設計が事前に必要だ。ゼロトラストの文脈では、エージェントへの常時広域権限付与こそが最大のリスクになる。 3. ランタイムリスクの監視プレイブックはあるか DefenderとPurviewはエージェントの挙動を監視できるが、「エージェントが誤作動したとき」「機密データに触れ始めたとき」の対応手順を事前に用意していないと、可視化だけして手が打てないという事態になる。 実務への影響：日本のIT管理者が今すべきこと ライセンス刷新のタイミングに合わせた3つのアクションを提案する。 現状棚卸し：E3・E5・Copilot・各種セキュリティアドオンの現状マッピングと、すでに動いているカスタムエージェント・自動化の把握から始める。「把握できていない自動化」がある組織は要注意だ ロールベースの精査：E5セキュリティ、Entra Suite、Copilot、エージェントガバナンスのフルセットが必要な役割と、一部だけで十分な役割を分けること。全社一律E7は多くの組織でオーバースペックになりうる 更新タイミングの把握：MicrosoftはE3・E5の価格改定を控えている。更新時期が近い組織は、E7への移行コストと現状維持コストを3年スパンで試算しておくべきだ。価格改定の圧力をかけられた更新交渉はこちらが不利。交渉前に自社のポジションを決めておく 筆者の見解 Agent 365の発表を見て、率直に「これはやるべきだった」と思った。AIエージェントが企業のあちこちに乱立する現状は、かつてShadow ITが横行した時代と本質的に同じ問題構造だ。見えないところで何かが動いていて、誰も全体を把握できていない。 Microsoftが「コントロールプレーン」という切り口でエージェント管理を標準化しようとしているのは、プラットフォームベンダーとしての責任ある判断だと思う。個別のエージェントツールが乱立する状況では、どこかが全体を束ねる役割を担わなければならない。その立場でMicrosoftが動いたことは、Entra・Defender・Purviewとの統合という文脈で見れば説得力がある。 ただ、気になる点が一つある。このE7という「フルバンドル」の設計が、Copilotの利用実態と噛み合うかどうかだ。M365 Copilotを含むバンドルである以上、Copilotの価値が組織に届いていないと、E7は割高な選択に見えてしまう。Microsoftには、Copilotが「買って終わり」にならないよう、実際の業務改善につながるユースケースの深掘りを続けてほしい。それができれば、E7という統合プランは本来の意味で強力な武器になる。 エージェントの時代はすでに始まっている。「いつか整理しよう」と先送りにしている間に、管理されていないエージェントがデータや権限に触れ続ける。Agent 365の$15は、そのリスクに対する先行投資として見れば決して高くない。まずは現状把握から始めることを強く勧める。 出典: この記事は Microsoft Agent 365: A Practical Guide to the New Standalone License の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI活用が当たり前になってきた今、ドキュメントのフォーマットとして「Markdown」を使う機会は急激に増えている。開発者だけでなく、AIアシスタントが吐き出す成果物の多くがMarkdown形式だ。そんな中、OneDriveとSharePointがMarkdown（.md）ファイルのブラウザ内直接編集・プレビュー表示に対応する。2026年4月中旬からのロールアウト開始、5月末には世界展開完了予定だ。地味に見えて、実は現場への影響が大きい変化である。 何が変わるのか 今まで、SharePointやOneDriveに.mdファイルを保存しても「ダウンロードして別ツールで開く」しかなかった。今回の対応により、ブラウザ上でそのままサイドバイサイド表示——左にRawのMarkdownエディタ、右にリアルタイムレンダリングされたプレビュー——が可能になる。 対応しているMarkdown要素も実用的だ。テーブル、画像、コードブロック、リンクがFluent 2デザインで美しくレンダリングされる。書式設定ツールバーも内蔵されているため、Markdown記法に慣れていないユーザーでも操作できる。管理者側の作業は不要で、既存のアクセス制御もそのまま有効になる。 なぜ今このタイミングか この機能追加の背景には、AIアシスタントの普及がある。Microsoftも元記事で「AIアシスタントが生成したMarkdownファイルの管理」を明示的にユースケースとして挙げている。AIに資料まとめや手順書の下書きを依頼すると、大抵Markdown形式で返ってくる。それをSharePointのドキュメントライブラリで管理したい——という需要が顕在化したのは自然な流れだ。 Markdownはエンジニアの文化圏で長らく使われてきたが、M365の世界はWordやPowerPointが中心だった。この二つの世界が接続されることで、「GitHubのREADMEをSharePointで共有・編集する」「AIが生成した構造化ドキュメントをそのままTeamsで共有する」といったワークフローが現実的になる。 実務への影響——IT管理者・エンジニアへのヒント 開発チームとビジネス側の文書共有が楽になる。READMEや技術仕様書をSharePointに置いても、非エンジニアが「開けない」という問題がなくなる。外部エディタのライセンス管理や導入も不要だ。 AIワークフローとの連携ポイント。AIが生成したMarkdownドキュメントをそのままSharePointライブラリに保存・共有・共同編集するフローを組める。OneNoteやWordへの変換ステップを省略できるため、ドキュメント管理の摩擦が一段階下がる。 ヘルプデスク・研修資料の整備を。エンドユーザーにとって「.mdファイルがブラウザで開けるようになった」は驚きを与える変化だ。特にSharePointに技術系ドキュメントを保存している組織では、事前に周知しておくと混乱を避けられる。管理者側の設定変更は不要だが、ユーザー向けの案内は準備しておきたい。 筆者の見解 この機能は「地味だけどちゃんと価値がある」アップデートの典型だと思う。OneDriveやSharePointの強みは、ファイルの種類を問わずアクセス制御・バージョン管理・共有フローを一元化できることだ。そこにMarkdownが加わったことで、「M365で完結できる範囲」が実質的に広がった。 AI活用が進むほど、Markdownは「エンジニア専用フォーマット」ではなくなっていく。AIが生成するコンテンツの多くがMarkdownで返ってくる以上、それをそのまま組織のファイル管理基盤で扱えるようにするのは当然の進化だ。Microsoft 365が「統合プラットフォームとして使ってこそ価値が出る」という原則で考えれば、この対応は正しい方向性を向いている。 小さな一歩に見えるが、こういった「現場の実際のワークフローに寄り添う改善」を積み重ねることがプラットフォームの底力を作る。Microsoftにはこういう仕事を引き続き丁寧にやり続けてほしい。 出典: この記事は View and edit Markdown files in OneDrive and SharePoint の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotの診断ログ送信機能に、ユーザーのプライバシーを脅かしかねない設計上の問題が明らかになった。管理者が「サポート目的」でログを送信する際、ユーザーが入力したプロンプトと、Copilotが生成した応答のすべてが平文（JSON形式）で管理者自身にも丸見えになっている。これは、多くのユーザーが想定しているであろう「プライバシーの範囲」を大きく逸脱している可能性がある。 何が問題なのか Microsoft 365管理センターのCopilotセクションには、「ユーザーに代わって診断ログをMicrosoftに送信する」機能が存在する。公式の説明によれば、これはユーザー自身がフィードバックを提供できない場合でも、組織がCopilotの品質改善に貢献できるようにするためのものだ。 具体的には、特定のアプリケーション（たとえばCopilot Chat / BizChat）を対象として、過去30日以内の最大30件のインタラクションをログとして収集できる。収集されたデータはJSONファイルとして生成され、リンクをクリックするとブラウザで即座に中身が確認できる。 そしてここが問題の核心だ——そのJSONには、ユーザーが入力したプロンプトと、Copilotが返した応答がそのまま記録されている。 サポートエンジニアが読み解きやすいように平文にしているという設計意図は理解できる。しかし、管理者がユーザーの同意なく、あるいは最低限の監査証跡もなく、その内容を閲覧できてしまう点は問題だ。現時点では、管理者がこのログをエクスポートしても監査ログに記録が残らないという指摘もあり、「誰がいつ誰のプロンプトを見たか」すら追跡できない状態になっている。 なぜこれが重要か AIツールの使われ方を考えると、この問題の深刻さが見えてくる。ユーザーはCopilotに対して、HR上の相談、戦略的な方向性の検討、個人的な業務上の悩みなど、対外的には共有したくない内容を入力することも少なくない。AIへの問いかけが「考えの鏡」のような役割を担っている以上、そこには相応の秘密保持が前提として存在する。 そうした前提のもとで、管理者がユーザーの知らないところでプロンプト履歴を参照できる——これは、組織のコンプライアンス担当者や法務部門にとっても、看過できないリスクだ。GDPRや日本の個人情報保護法の観点からも、「業務利用のAIインタラクションをどう扱うか」という議論に直結する問題である。 実務への影響 IT管理者・情報セキュリティ担当者が今すぐ確認すべきポイントを整理する。 1. 診断ログ機能の利用ポリシーを策定する 管理センターの「Copilot診断ログの送信」機能は、利用できる状態になっているか確認しておく必要がある。既存のポリシーにこの機能の取り扱いが含まれていなければ、早急に追記すべきだ。 2. ユーザーへの周知 「管理者があなたの代わりにCopilot診断ログを送信することがある」という事実は、利用規約や社内ガイドラインとしてユーザーに明示しておくことが求められる。特に、機微な情報をCopilotに入力しないよう促すコミュニケーションが重要になる。 3. 監査ログの空白を意識する 現時点ではログエクスポートの監査記録が残らない。この空白を認識したうえで、「誰がこの機能を使えるか」をロールベースで制限する運用を検討する。 4. Microsoftの対応をウォッチする この問題はすでにMicrosoft 365 Copilotのフィードバックフォーラムに報告されており、改善を求める声が集まっている。Microsoftが難読化や監査記録の整備といった対応を取るかどうか、今後のアップデートに注目しておきたい。 筆者の見解 MicrosoftがCopilotのプロンプトと応答を平文でログに保持し、管理者が容易に閲覧できる設計を選んだことは、「もったいない」の一言に尽きる。 Microsoftはエンタープライズセキュリティとコンプライアンスのノウハウを世界トップレベルで持っている。使用状況レポートの匿名化オプションを既に備えているように、「ユーザーデータをどう守るか」という設計思想を実装する力は十分にある。それだけに、Copilotの診断ログがここまで無防備な形で提供されていることは、正直なところ驚きだった。 「デバッグのために平文が必要」という要件と「管理者からプロンプトを守る」という要件は、技術的には両立できるはずだ。暗号化されたログをMicrosoftのサポートエンジニアだけが復号できる設計にするなど、選択肢は複数ある。今の設計はあくまで「開発フェーズの利便性優先」が残ったまま本番リリースされた印象を受ける。 Copilotを組織全体へ展開していく上で、この種のプライバシーリスクは「信頼の土台」に関わる問題だ。Microsoftにはその土台をしっかり固めてほしい。CopilotがエンタープライズAIの本命として進化していく姿を期待しているからこそ、こういった部分を丁寧に直していってほしいと思う。 Microsoftのフィードバックフォーラムへの投票で改善を求めることが、今できる最善のアクションだ。こうしたコミュニティからの声がプロダクトを動かした実績は十分にある。 出典: この記事は The Open Nature of Microsoft 365 Copilot Diagnostic Logs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが矢継ぎ早にMicrosoft 365のセキュリティ強化策を打ち出している。M365 Appsのセキュリティベースライン公開、Teams管理センターへのTrust機能追加、そしてDefender for Office 365 Plan 1のE3プランへの標準搭載——これらが同時に展開され始めた。日本のIT現場にとっても他人事ではない動きだ。 セキュリティベースラインとは何か 「セキュリティベースライン」とは、Microsoftが推奨するセキュリティ設定の基準値をまとめたものだ。今回のM365 Apps向けベースラインは、Word・Excel・PowerPoint・Outlookといったアプリ群に対して、どのポリシーをどの値に設定すべきかを明示した公式ガイダンスとなる。 これまでも非公式の推奨設定はあったが、今回は明確に「ベースライン」として整理された。つまり、「このポリシー設定を下回るのはリスクがある」という公式のラインが引かれたことを意味する。グループポリシーやIntune経由で展開できるため、大規模環境でも適用しやすい。 Teams管理センターのTrust機能 Teams管理センターに追加されたTrust機能は、外部ユーザーや外部テナントとのコラボレーション時の信頼レベルを細かく制御するものだ。どのテナントを「信頼する」か、どの操作を許可するかをきめ細かく管理できるようになる。 ゼロトラストのコンセプトである「すべてを検証し、最小権限を付与する」に沿った機能拡張であり、特にマルチテナント環境を持つ企業や、顧客・パートナーと頻繁にTeamsを使ってコラボする組織にとって重要な管理ポイントとなる。 E3にDefender for Office 365 Plan 1が標準搭載 今回の施策の中で最も実務的なインパクトが大きいのが、Defender for Office 365 Plan 1のE3プランへの標準搭載だ。これにより、Safe Links（URLの動的検証）やSafe Attachments（添付ファイルのサンドボックス検査）などの機能が、E3ライセンスのユーザーも追加コストなしで利用できるようになる。 これまでこれらの機能はE5ライセンスまたは別途アドオン購入が必要だった。E3止まりで運用している中堅企業にとっては、実質的なセキュリティ機能の引き上げが無償で行われることになる。 Security Copilotは2026年4月〜6月にE5向け段階展開 AIを活用したセキュリティ分析機能であるSecurity CopilotについてはE5ライセンス向けに、2026年4月20日から6月30日にかけて段階的に展開される予定だ。セキュリティインシデントの要約・分析、脅威の自動調査などを支援する機能群であり、セキュリティオペレーションチームの負担軽減に貢献することが期待される。 実務への影響——日本のIT管理者が今すぐすべきこと 1. ベースラインの把握と現状ギャップの確認 公開されたM365 Appsセキュリティベースラインを入手し、現在の組織ポリシーとの差分を確認する。特にIntuneやグループポリシーを使ってM365アプリを管理している場合、どの設定がベースラインを下回っているかを可視化することが第一歩だ。 2. E3環境ではDefender機能の有効化を確認 E3ライセンスを使っている場合、Safe LinksやSafe AttachmentsがテナントでONになっているか確認する。ライセンス上使えるようになっても、管理者が明示的に有効化しなければ機能しない設定も多い。 3. Teamsの外部連携ポリシーの棚卸し Trust機能が追加されたこのタイミングで、外部テナントとの共有設定を一度見直す良い機会だ。「なんとなく許可になっている」設定が残っていないか確認する。 筆者の見解 セキュリティは正直、細かい話が多くて食指が動きにくいジャンルではある。が、今回の一連の施策はその「細かさ」の中でも骨太な方向性が見えるものだと思う。 E3へのDefender標準搭載は、現場への影響という意味では地味に大きい。これまで「E5は高くて買えないので、Safe Linksは諦めている」という組織が日本にも相当数存在する。その現実に対してMicrosoftがアンサーを出したと読むことができる。セキュリティ機能を「上位プランだけの特権」にし続けることのリスクを、Microsoftが認識したということでもある。 セキュリティベースラインの公式化も評価できる。「ベンダーの推奨には理由がある」と常々思っているが、その推奨が公式ドキュメントとして整理されることで、管理者がステークホルダーに説明するための根拠が得られる。「MicrosoftがこのポリシーをONにしろと言っている」という文書は、現場でのセキュリティ施策の推進力になる。 Zero Trustを本気でやろうとすると、ネットワーク・認証・認可の3層すべてに手を入れる必要がある。今回のTrust機能や設定ベースラインの整備は、「認可層」の管理をより精緻にするための布石として機能する。道のりはまだ長いが、プラットフォームとして必要な仕組みを着実に積み上げているのは確かだ。MicrosoftにはMicrosoft 365という強力なプラットフォームがある。この方向で積み上げ続ければ、エンタープライズのセキュリティ基盤として揺るぎない地位を確立できる力は十分にある。 出典: この記事は Microsoft Rolls Out Security Baseline for Microsoft 365 Apps, Teams Admin Center Trust Features の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが5月1日より、クラウドPC サービス「Windows 365」の価格を一律20%引き下げると、チャネルパートナーへの通知を通じて明らかにした。主なターゲットは中小企業（SMB）であり、クラウドベースのデスクトップ環境をより多くの組織に届けようという意図が透けて見える。 Windows 365とは何か——改めて整理する Windows 365はフル機能のWindowsデスクトップをクラウド上に展開し、任意のデバイスからブラウザ経由でストリーミングできるサービスだ。Azure Virtual Desktop（AVD）と混同されることが多いが、AVDが仮想化基盤の構築・管理を伴うエンタープライズ向けであるのに対し、Windows 365はPC1台分のリソースをそのままクラウドに置き換えるイメージに近い。ライセンス体系もシンプルで、ユーザー単位の固定月額という分かりやすさが特徴だ。 なぜ今、20%値下げなのか ここ数年でクラウドデスクトップ市場には競合が増えた。AWSのWorkSpaces、Google ChromeOSの企業展開など、選択肢が広がる中でMicrosoftが価格競争力を高める動きは自然な流れといえる。特にSMBセグメントは、初期投資の少なさと運用の簡便さを重視する傾向が強く、月額コストの20%削減はIT担当者の稟議を通りやすくする上で十分な効果がある。 一方で、この値下げには別の文脈もある。端末更新サイクルと絡めた提案だ。Windows 10のサポートが2025年10月に終了を迎え、多くの中小企業が端末リプレースの判断を迫られている。老朽化したハードウェアをそのまま使いながらWindows 11のクラウド環境へ移行するシナリオは、CapExを削減したい企業にとって魅力的な選択肢になりうる。 実務への影響——日本の中小企業IT担当者へのヒント 今が見直しのタイミングとして押さえておきたいポイントを整理する。 Windows 10 EOS対応と組み合わせる: ハードウェアの買い替えコストとWindows 365の月額を5年総コストで比較すると、特に少数台数（10〜50台程度）の環境ではクラウドPC移行が有利になるケースが増える。5月1日の価格改定後の試算を必ず行うこと。 ゼロトラスト推進と相性が良い: Windows 365はデータがエンドポイントに残らない構造であるため、デバイス紛失・盗難時のデータ漏洩リスクが大幅に下がる。ゼロトラスト移行を検討している組織には特に有効な一手となる。 ライセンス体系の整理を忘れずに: Microsoft 365との組み合わせ次第でEntitlementが変わることがある。CSP経由の購入であれば、パートナーに最新の価格表と推奨構成を確認してほしい。 AVDとの使い分けを明確に: ユーザー数が増えるほどAVDの方がコスト効率が上がる場合がある。50名を超える規模なら、両者の比較検討が必要だ。 筆者の見解 この価格改定を見て、正直「やっとここに踏み込んだか」という感想を持った。Windows 365は技術的には完成度の高いサービスだが、価格のせいで中小企業への訴求力が弱かった。ハードウェアの買い替えコストとの比較試算で「高い」と弾かれてきた案件が、この値下げによって再評価されるケースは少なくないはずだ。 Microsoftの総合力——Azure、Entra ID、Intune、Microsoft 365との統合——は他のクラウドデスクトップサービスにはない強みだ。この「プラットフォームの一部として機能するクラウドPC」という価値は、バラバラなポイント製品を組み合わせるコストを考えると、十分に競争力がある。その強さを、もっと多くの企業に届けられる価格帯になったことは素直に評価したい。 あとはパートナーエコシステムが適切な提案活動を行えるかどうか。技術的な優位性があっても、現場に届く言葉で伝えられなければ選ばれない。日本のIT企業・SIerがこの価格改定を機に、クラウドPC移行提案を本格的に始動させる契機になることを期待している。 出典: この記事は Microsoft Cuts Windows 365 Prices by 20% to Attract SMBs の内容をもとに、筆者の見解を加えて独自に執筆したものです。