M365

Microsoft Teams の会議 Recap ページに、主催者が録画・トランスクリプト・AI 生成サマリー・会議メモを直接削除できる機能が追加された。機密性の高い会議後のコンテンツ管理が格段に楽になる、実践的なアップデートだ。 何が変わったのか 従来の Teams では、会議終了後に生成される録画・トランスクリプト・Copilot による AI サマリーを削除するには、SharePoint や OneDrive などの保存先に個別にアクセスする必要があった。コンテンツが複数の場所に分散して保存されるため、「削除したつもりなのに一部が残っていた」というリスクも抱えていた。 今回の更新により、会議の Recap ページという一箇所から以下のすべてを削除できるようになる： 会議録画 トランスクリプト（文字起こし） AI 生成サマリー（Copilot による要約・アクションアイテム等） 会議メモ また今後のアップデートとして、録画やトランスクリプトを保存せずに AI 会議レキャップのみを生成するオプションも導入予定だ。サマリーだけ残してローデータは保存しない、というコンプライアンス要件にも対応できる形になる。 なぜこれが重要か 日本企業の Teams 利用において、会議コンテンツの取り扱いは常に悩ましい問題だ。特に以下のシナリオでは、コンテンツの削除操作が煩雑であることがリスクにつながっていた： 役員会・取締役会などの機密性の高い会議 人事評価・採用面接など個人情報を含む会議 M&A 関連の協議など法的機密性のある会議 外部参加者が含まれる顧客提案・パートナー商談 これらの会議では、録画やトランスクリプトが自動生成されることへの懸念から、そもそも録音・文字起こし機能をオフにする対応を取っている企業も少なくない。今回の機能追加により、「必要なものだけ保持し、不要なものはすぐ削除する」という柔軟な運用が可能になる。 実務での活用ポイント IT 管理者向け： 会議ポリシーで「録画・トランスクリプトの保存先」を明確に定義しておくと、Recap ページからの削除がより一貫して機能する 主催者に削除権限があることを全社周知しておく（知らないと活用されない） 部門ごとに録画ポリシーを分けて設定することも検討の余地あり エンジニア・利用者向け： 機密会議後は Recap ページを習慣的にチェックし、不要なコンテンツを整理する運用フローを確立する 「AI サマリーのみ残して録画は削除」という中間的な選択肢が今後使えるようになる Recap 機能を活用しながら、ガバナンスの観点でコンテンツを管理するアプローチが現実解 筆者の見解 Teams の Recap 機能は、使えば確かに便利だ。会議後のフォローアップが楽になり、欠席者へのキャッチアップも効率化される。ただそのぶん、「気づいたら録画が残っていた」「AI サマリーが想定外の範囲に共有されていた」といった問題が発生しやすい側面もある。 今回の削除機能の追加は、その痛点への誠実な回答だと思う。運用の実態に即した改善であり、歓迎できる方向性だ。 ただ一点付け加えると、情報ガバナンスとしての本来の姿は「作ってから消す」ではなく「最初から適切な範囲にしか保存しない」設計だ。Teams にはまだ、会議コンテンツの保存先・共有範囲・保持期間を事前にきめ細かく制御するための設定が十分とは言えない面もある。削除機能の充実とあわせて、ポリシー設定の分かりやすさやデフォルト値の見直しも進めてほしい。使いやすさとガバナンスを両立できる力が Teams にはあるはずで、その完成形を引き続き期待している。 出典: この記事は Teams Meeting Recap: Organizers Can Now Delete Recordings and AI Summaries の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Entra IDの条件付きアクセス（Conditional Access）ポリシーの適用範囲を拡大し、「ベースラインスコープのみ」を要求するアプリにもポリシーが一貫して適用されるよう動作を変更する。2026年6月15日からロールアウトが始まっており、8月中旬には全世界のテナントへ展開が完了する予定だ。メッセージセンターではMC1223829として公開されている。 ベースラインスコープとは OpenID Connect（OIDC）の標準スコープである openid・email・profile に、Entra IDのディレクトリスコープ（User.Read・People.Read・GroupMember.Read.All など）を加えた一群が「ベースラインスコープ」と呼ばれる。これらは限定的な権限として低リスクに分類されており、ユーザー同意設定においても特別扱いされてきた。 何が変わるのか 従来の動作では、アプリが「ベースラインスコープのみ」を要求し、かつ条件付きアクセスポリシーに1つ以上のリソース除外が設定されている場合、そのポリシーが適用されないケースがあった。ポリシーを設定した管理者の意図と、実際の動作に乖離が生じていたわけだ。 変更後は、要求するスコープの種類にかかわらず、条件付きアクセスポリシーが一貫して適用される。Microsoftが例として挙げるのが Visual Studio Code のデスクトップクライアントだ。VS Code は User.Read のみを要求するため、現在は条件付きアクセスの対象外となっているが、変更後はポリシー評価の対象に含まれる。 影響を受けるシナリオ 多くのテナントでは影響は軽微だ。Mail.Send や User.Read.All のような Graph API アクセス許可を1つでも要求するアプリは、すでに条件付きアクセスの対象となっているためだ。人気の AI コネクター（例：Microsoft 365 Connector for Claude）も Graph 権限を複数要求するため、今回の変更には該当しない。 リスクがあるのは、ベースラインスコープのみに依存しつつ、MFA や準拠デバイス要件を満たせないアプリだ。独自の認証フローを持つレガシーアプリや、長年手が入っていない社内開発の簡易ツールがこれに当てはまる可能性がある。 今すぐ確認すべきこと MC1223829 を確認し、自テナントへの展開時期を把握する（Microsoftは変更2週間前と完了後に通知を送付する） Entra 管理センターの「条件付きアクセス」→「ベースラインスコープ設定」ページで現在の構成を確認する（現時点では特殊 URL が必要） サービスプリンシパル分析レポートを実行し、ベースラインスコープのみを使用しているアプリを洗い出す 該当アプリが存在する場合、MFA 対応の可否を開発チームまたはベンダーに確認する 実務への影響 日本のエンタープライズ環境では、長年かけて積み上げた条件付きアクセスポリシーと古い認証フローを持つ業務アプリが混在しているケースが珍しくない。今回の変更は短期的には一部アプリの認証失敗を引き起こす可能性があるが、逆に言えば「ポリシーが効いていなかったアプリ」を発見する機会でもある。展開完了後の8月中旬に向けて、今のうちにサービスプリンシパルの棚卸しを済ませておくことを強く勧める。 筆者の見解 ゼロトラスト推進の立場から見れば、今回の変更は「やっと」という気持ちが正直なところだ。「条件付きアクセスを設定したから安全」という思い込みの裏で、実はスコープの抜け穴からポリシーをすり抜けていたアプリが存在していた——これはゼロトラストの根幹である「明示的に確認する（Verify Explicitly）」の原則に反する状態だった。 Microsoftがこうした地道な基盤の穴埋めを着実に進めていることは素直に評価したい。AI 機能の話題が先行しがちな昨今だが、プラットフォームの信頼性を支えるこういった修正こそが、長期的な安心感の源泉になる。テナント管理者にとっては棚卸し作業の手間が増えるが、ゼロトラスト移行を進める上でどうせ通らなければならない道だ。今回の変更を、アクセス権限の全体的な見直しを始めるきっかけにしてほしい。 出典: この記事は Entra ID Tightens Conditional Access Processing for Baseline Scopes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Defender Security Research チームが2026年6月18日、AIブラウジングエージェントを悪用した新たな攻撃チェーン「AutoJack」の詳細を公開した。悪意ある1枚のWebページを閲覧させるだけで、AIエージェントを実行しているホストPCで任意コードが実行（RCE）されるという、AIエージェント時代ならではの脅威だ。 AutoJackとは何か AutoJackは、AIブラウジングエージェントが「信頼できないWebコンテンツを閲覧する」という動作そのものを攻撃ベクターに変える、複数の脆弱点を連鎖させたエクスプロイトチェーンだ。標的は特定のソフトウェアの既知のバグではなく、「AIエージェントがlocalhostにアクセスできる」という設計上の前提そのものを突いている。 研究で具体的に示されたのは、AutoGen Studio（MicrosoftのマルチエージェントフレームワークのUI）のMCP（Model Context Protocol）WebSocketを経由した攻撃経路だ。 攻撃チェーンの仕組み：3つの前提が崩れる 1. localhostへの「盲目的な信頼」 従来のセキュリティモデルでは、localhostは「信頼できるローカル環境」として扱われてきた。しかしAIエージェントがWebを閲覧し、その閲覧結果をもとにlocalhostのサービスと通信できる構成では、この前提は崩壊する。悪意あるWebページがAIエージェントを「使って」localhostにリクエストを送れるからだ。 2. AutoGen StudioのMCP WebSocket認証欠如 AutoGen StudioがローカルにホストするMCP WebSocketエンドポイントには、デフォルト状態で認証機構が存在しない。つまり、エージェントが到達できる範囲にあれば、認証なしにプロセス実行を含む操作を呼び出せる。 3. 安全でないパラメータ処理 MCP経由でツールを呼び出す際のパラメータが適切に検証・サニタイズされていないため、攻撃者が用意した悪意あるWebページ上の内容が、そのままホストOSで実行するコマンドに組み込まれる。プロンプトインジェクションとシステム操作が繋がる瞬間だ。 攻撃の流れ（概要） 攻撃者が細工した悪意あるWebページを用意する AIブラウジングエージェントがそのページを閲覧する（ユーザー指示または自律動作） ページに埋め込まれたプロンプトインジェクションがエージェントの動作を乗っ取る エージェントがlocalhost上のAutoGen Studio MCP WebSocketに細工したリクエストを送信 ホストOSで任意のプロセスが実行される（RCE成立） 日本のIT現場への影響 AIエージェント活用を検討中の組織に直撃する問題 「AIエージェントにWebリサーチをさせよう」「ブラウザを自動操作して業務効率化しよう」という取り組みは、国内でも急速に広がっている。AutoJackが示すのは、そのユースケース自体に根本的なリスクが内在しているという事実だ。エージェントが閲覧するすべてのページが、実質的な攻撃面（アタックサーフェス）になりうる。 開発・検証環境こそ狙われやすい AutoGen StudioのようなAI開発ツールは、開発者のローカルマシンや検証環境で動かすことが多い。「本番じゃないから」という油断が最も危ない。開発者のマシンが侵害されれば、ソースコード・シークレット・クラウド認証情報がまとめて流出するリスクがある。 即座に取れる対策 AIエージェントに閲覧させるURLを許可リストで制限する（無制限のWebブラウジングは最もリスクが高い） ローカルホスト上のMCPサーバーには必ず認証を実装する（トークンベース認証 or ソケットレベルの制限） エージェントの実行プロセスに最小権限原則を適用する（Rootや管理者権限で動かさない） AIフレームワークのアップデートを迅速に適用する（AutoGen Studioも含め、今後パッチが展開される見込み） プロンプトインジェクション対策のレイヤーを設ける（入力コンテンツの検証・サニタイズ） 筆者の見解 セキュリティの話はどちらかというと得意分野ではないが、AutoJackには純粋に技術的な興味を引かれた。これは「AIが新しい攻撃面を生む」という抽象論ではなく、「なぜlocalhostが信頼できるという前提が崩れるのか」を具体的なコードレベルで示した優れた研究だと思う。 ゼロトラストの文脈で言えば、AutoJackはまさに「ネットワーク境界への信頼」の終わりを象徴している。localhostだから安全、という考え方はもはや通用しない。AIエージェントという「代理人」がいる環境では、その代理人が辿り着ける場所はすべて攻撃面になる。認証・認可はリソースの種類に関わらず一貫して実装しなければならない。 もう一点気になるのは、Non-Human Identity（NHI）管理との関係だ。AIエージェントは人間の代わりに動くが、そのIDと権限管理は多くの現場でまだ整備されていない。エージェントが「誰として」「何の権限で」動くかを管理できていなければ、AutoJackのような攻撃が成功したときの被害範囲を限定できない。自動化を進めるほど、NHI管理の整備は急務になる。 Microsoftがこのような攻撃研究を自ら公開し、AI時代のセキュリティリスクを業界全体に示そうとしていることは評価したい。研究を研究で終わらせず、AutoGen StudioをはじめとするMicrosoftのAI開発ツールへの実際の修正と、開発者向けのガイドラインとして結実させることを期待している。 出典: この記事は AutoJack: How a single page can RCE the host running your AI agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月末を目標に、Microsoft Teamsの会議中UIを全面刷新する。マイク・カメラ・画面共有などの主要コントロールが画面中央に集約されたシンプルなレイアウトに変更され、共有パネルにはライブプレビューと誤共有防止の確認ステップが追加される予定だ。 主要コントロールが中央に集約される 現在のTeams会議画面は、コントロールが分散していて操作性に課題があった。今回の刷新では、ミュート・カメラのオン/オフ・画面共有といった主要ボタンが画面下部中央にまとまったシンプルなレイアウトに統合される。会議中に「ミュートボタンがどこだったか」と焦るような場面が減ることが期待される。 共有パネルの再設計——ライブプレビューと誤共有防止 特に注目したいのが共有パネルの改善だ。新しい共有パネルでは、共有しようとしているウィンドウやアプリケーションのライブプレビューがその場で表示される。さらに共有を開始する前に確認ステップが追加される設計になっている。 これは地味に見えて実は重大な改善だ。「画面共有したつもりが別のウィンドウを映していた」「機密情報が映り込んだ状態で共有してしまった」といった誤操作は、日本のエンタープライズ環境でも頻繁に発生している。確認ステップの追加によって、このリスクを構造的に下げることができる。 同時期にM365 Copilotアプリも刷新 同じ時期に、Microsoft 365 CopilotアプリのUIも大幅に再設計される。MicrosoftのチーフデザインオフィサーJon Friedmanが掲げるデザイン思想のキーワードは次の3点だ。 プログレッシブディスクロージャー：最初はシンプルに表示し、必要に応じて機能を展開 アウトプットこそがUI：AI時代において最も重要な体験は、応答の質・トーン・読みやすさ Work IQ：メール・ファイル・チャット・会議の文脈を理解して適応するインテリジェンスレイヤー プロンプト入力欄が「タスク認識型ワークスペース」に進化し、Word・Excel・PowerPoint・Outlookをまたいだ一貫した体験を目指している。 そのほかの注目アップデート Microsoft Admin Center（MAC）のMessage Centerには、さらに多くの更新が含まれている。 Power BIのM365 Copilot統合：Copilot画面からPower BIレポートへアクセス可能になる Plannerエージェントの一般提供（GA）：プロジェクト管理のAIエージェントが正式リリース リアルタイム画面・カメラ共有（Copilot音声）：Vision機能として、音声会話中に画面やカメラ映像をCopilotと共有できるように Copilot in PowerPoint：「質問に備える」「プレゼンを確認する」「スライドをビジュアル化する」の3機能追加 SRT（Secure Reliable Transport）：Teams Town HallおよびLive Eventsの配信安定性が向上 実務への影響 展開時期の見極めを 2026年6月末のロールアウト目標とあるが、Microsoftの機能展開は地域・テナント規模・ライセンスによって時間差が生じる。MACのMessage Centerを定期チェックし、自テナントへの展開タイミングを事前に把握しておきたい。 UI変更はユーザーへの事前周知が必須 UIが変わると「突然変わった」と感じたユーザーからのヘルプデスク問い合わせが急増する。IT管理者は展開前に「何が変わるか」を簡単な社内向けガイドとして準備しておくとよい。共有パネルの確認ステップは特に、慣れたユーザーが「なんか増えた」と戸惑う可能性が高い。 誤共有インシデントの棚卸しのチャンス 新しい確認ステップが追加されるタイミングで、これまでの誤共有インシデントの記録を棚卸しし、セキュリティポリシーの見直しに活かすと良い。 筆者の見解 Teams UIの刷新は、率直に言って「ようやく」という印象だ。会議中の主要コントロールが中央集約されるのは、競合する会議ツールでは数年前から当たり前の設計だった。それが今回整理されるという事実は、UIデザインへの投資優先度がこれまで必ずしも高くなかったことを示しているかもしれない。Microsoftには統合プラットフォームとしての総合力があるのだから、こうした基本的な使い勝手の部分こそ先んじてほしかったというのが正直なところだ。 ただ、誤共有防止の確認ステップの追加は素直に評価したい。派手な機能追加より、「ミスを構造的に防ぐ設計」の方が、日本のエンタープライズ環境では遥かに価値がある。情報漏洩インシデントの多くは悪意ある攻撃ではなく操作ミスから生まれる。UIレベルでそのリスクを下げる仕組みは、セキュリティポリシーの実効性を高める。 M365 Copilotアプリの「プログレッシブディスクロージャー」というデザイン思想も方向性は正しい。AIツールは高機能になるほど、多くのユーザーにとって「何ができるのかわからない」という壁が高くなる。最初はシンプルに、必要な人には深い機能を——この設計原則が実際の利用率向上につながることを期待したい。今回のような積み重ねが、使い続けたいと思えるプラットフォームへの道になるはずだ。 出典: この記事は Microsoft Teams In-Meeting Experience Redesign and Sharing Panel Overhaul の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

MicrosoftはMicrosoft EntraとMicrosoft Defenderの連携を大幅に強化し、AIによって加速するサイバー攻撃への対抗策として「統合IDリスクスコア」「新しいEntra ID Protectionエクスペリエンス」「セキュリティアラートトリアージエージェント」を発表した。攻撃者がAIを使って攻撃を自動化・高速化するなか、防御側も同じ速度で動ける仕組みを整えることが急務になっている。 AIが変えたサイバー攻撃の様相 従来の攻撃は人手に依存する部分が多く、偵察・フィッシング文章の作成・認証情報の分析・権限昇格の試みといった各フェーズに時間がかかっていた。しかしAIの登場により、この状況は一変した。 攻撃者はAIを使って、ターゲットに合わせたソーシャルエンジニアリングを大規模に実施し、漏洩した認証情報を瞬時に分析して特権ユーザーを特定し、露出しているシステムを自動的に探索する。攻撃チェーン全体が高速化・自動化されているわけだ。 攻撃手法がいくら進化しても、エントリーポイントとして狙われ続けるのは変わらず「アイデンティティ」だ。ユーザーアカウント、管理者アカウント、ワークロードID、アプリケーション、Non-Human Identity（NHI）、AIエージェント——これらすべてが、適切に保護されなければ重要データへの侵入経路になり得る。 Microsoft Entraの新機能：3つの重点強化 1. 統合IDリスクスコアで「今どこが危ないか」を一目で把握 RSA 2026で発表された「統合IDリスクスコア（Unified Identity Risk Score）」は、関連アカウント・セッション・ワークロード・アプリケーション全体のシグナルを横断的に分析し、一つの包括的なリスク評価値として表示する機能だ。 このスコアはリアルタイムのアクセス判断に直結し、条件付きアクセス（Conditional Access）ポリシーのなかでリスクベースの動的な応答を実現する。単なるダッシュボードの数値ではなく、「このユーザーへのアクセスを今すぐブロックする」という実際のポリシー執行と連動する点が重要だ。 新しいEntra ID Protectionエクスペリエンスでは、リスクの高いユーザー・サインイン・ワークロード・関連する検出情報を一画面で確認できるようになった。これまではバラバラなビューからシグナルを手動でつなぎ合わせる必要があったが、その手間が大幅に削減される。管理者はリスクスコアの計算根拠、関連アカウントへの波及状況、攻撃タイムラインまでを一つの画面で把握し、対処の優先度判断を下せる。 2. 最小権限を守りながら対応速度を上げる新RBACロール セキュリティインシデント対応で長年の課題になっているのが、SOCチームとIAMチームの分断だ。SOCチームは脅威を検出しても対処する権限がなく、IAMチームの対応を待つ間に被害が広がる——こうした状況が多くの組織で実際に起きている。 かといって、SOCチームに広範な管理者権限を付与すれば、そのアカウント自体が侵害された場合の被害が拡大する。「解決策がリスクを生む」という典型的なジレンマだ。 Microsoftはこれに対し、「IDに特化したRBACロール」（パブリックプレビュー予定）で応答する。SOCチームが必要なIDレスポンスアクションだけ実行できる権限を与え、広範な管理者権限は不要にする。さらにMicrosoft Entraの特権IDマネジメント（PIM）と組み合わせることで、Just-In-Time（JIT）アクセスポリシーを適用可能にする。必要なときだけ権限を昇格させ、通常時は最小権限を保つ——ゼロトラストの原則に忠実な設計だ。 3. Conditional Access最適化エージェントとアラートトリアージの自動化 「Conditional Access最適化エージェント」は、IDシグナル・使用パターン・新興脅威を継続的に分析し、適切なポリシー変更を推奨する機能だ。新たに「Block risky user agent」ポリシーの推奨が追加され、AIエージェントの悪用や自動アクセス試行といった新しい攻撃ベクターへの対応が強化されている。 まもなく、Defenderの脅威検出情報がEntraのConditional Access最適化推奨に自動フィードされる連携も実現する予定だ。管理者は「なぜこの変更が必要か」「誰が影響を受けるか」「何をすればよいか」が明示された推奨を受け取れるため、事後対応から予防的対応へとシフトできる。 「Security Alert Triage Agent」もIDシナリオに拡張され、自動攻撃妨害・予測的シールディングと組み合わせることで、エンド・ツー・エンドの自動化ループが完成する。 日本のIT現場への影響 SOCとIAMの分断は日本でも深刻 大規模な日本企業では、SOCチームとIAMチームが別組織になっているケースが多く、インシデント発生時の連絡・対応フローが複雑で対応が遅れる原因になっている。新しいRBACロールとJIT昇格の仕組みは、この分断を組織改編なしに緩和できる可能性がある。組織の壁を動かす前に、権限設計で改善できる部分がある点は現実的だ。 NHIの管理が次のボトルネックに アプリケーションやAIエージェントが増えるにつれ、Non-Human Identity（NHI）の数と複雑さが急増している。「サービスアカウントのパスワードを誰が管理しているかわからない」「古いAPIキーが放置されている」といった状況は珍しくない。統合IDリスクスコアにNHIのシグナルが含まれることで、人間のアカウントだけでなく機械的なIDのリスクも可視化できるようになる。業務の自動化を進めるほど、NHI管理の重要性は増す。 実務アクション 今すぐ: Entra ID ProtectionでConditional Accessポリシーの最適化推奨を確認し、放置されているギャップを特定する 近い将来: 新RBACロールのパブリックプレビュー開始後、SOCチームの権限設計を見直す 継続的に: NHIの棚卸しを実施し、不要なサービスアカウントや放置APIキーを整理する 筆者の見解 Microsoft EntraとDefenderが統合されてきた流れは、「ようやくここまで来たか」という感想が正直なところだ。IAMとSOCが別ツール・別ワークフローで動いている状況は攻撃者にとって明らかに有利であり、防御側がその構造を自ら維持していること自体がリスクだった。 JIT昇格とRBACの組み合わせでSOCとIAMの分断を解消しようとするアプローチは、ゼロトラストの文脈で真っ当な方向性だ。「常時アクセス権の付与は特権管理における最大のリスク」——この原則を製品の機能設計に落とし込もうとしていることは評価したい。Microsoftはこの領域で正しい問いを立てている。 一方で、統合IDリスクスコアの精度と誤検知率については、実運用でどう出るかを見ていく必要がある。シグナルが多くなればなるほどスコアは複雑になり、「なぜこのスコアになったか」の説明可能性が重要になる。Microsoftが「rationale（理由）の説明」を強調している点は、現場のニーズを理解している証左だろう。その約束をきちんと果たせるか、ここが肝だ。 日本の大きな組織では、古いセキュリティモデルにゼロトラストを中途半端に追加した複雑な構成が多い。こういった統合ソリューションを活用するためには、まずその複雑さを整理する段階が必要になる。ツールがいくら進化しても、組織の構造と意識が追いつかなければ宝の持ち腐れだ。Microsoftには機能の発表と同じくらい、移行パスの支援に力を入れてほしいところだ。その力は十分にあるはずなのだから。 出典: この記事は AI is accelerating cyberattacks—here’s how to stay ahead の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがAnthropicと共同開発したエンタープライズ向けAIエージェント「Copilot Cowork」が正式一般提供（GA）となった。従来のCopilot機能とは一線を画す「タスク全体を自律実行するデジタルチームメイト」として設計されており、すでにFortune 500企業の半数以上への導入実績を持つ。 Copilot Coworkとは何か Copilot Coworkは2026年3月に発表されたAI搭載の生産性エージェントだ。従来のAIアシスタントが「提案を行う」スタイルだったのに対し、Coworkはユーザーが依頼した業務を最初から最後まで自律的にこなす点が本質的な違いとなる。 必要なデータを収集し、関連ツールを使いこなし、完成した成果物を届けるまでを一気に処理する。マルチステップのワークフロー自動化という観点では、単なるチャットボットの延長ではなく、エージェント型AIの本格実装といえる。Accenture、Avanade、Advance LocalなどのFortune 500企業で広く導入されており、Microsoftのフロンティアプログラムにおける最速普及機能となっている。 正式版の新機能 プラグイン統合とエンタープライズWebブラウジング 正式版ではサードパーティプラグインのサポートが追加された。Miro（ホワイトボードツール）、Monday.com（プロジェクト管理）、金融データプラットフォームなどとの統合が可能になり、M365の境界を超えた業務自動化が現実的になった。また、Microsoft Edgeを経由したエンタープライズコントロール下でのWeb閲覧機能も導入され、外部情報を取り込みながらタスクを実行するシナリオが広がる。 モデル選択の柔軟性 Copilot CoworkはAnthropicとの「緊密な協業」のもとで開発されており、現時点ではAnthropicのOpus 4.8およびSonnet 4.6を搭載している。フロンティアプログラムの参加企業はGPT-5.5へのアクセスも可能だ。今後はMicrosoftが独自開発する「Cowork 1」モデルのリリースも予定されており、性能向上とコスト削減の両立を目指しているという。 使用量ベースの課金モデル 料金体系は固定費用ではなく「Copilotクレジット」を消費する使用量ベースとなっている。選択するAIモデル・取得データ量・使用ツール・タスク実行時間によって費用が変動する仕組みだ。IT管理者はユーザー・グループ・組織単位でのコスト可視化や予算上限の設定が可能で、利用状況の詳細レポートも取得できる。 実務への影響 コスト管理の観点から、使用量ベース課金は諸刃の剣だ。固定費用に慣れた日本企業の会計管理では、月次の変動費用が予算策定を複雑にする可能性がある。加えて、M365 Copilotのライセンス料金は2026年7月1日から最大16%の値上げが予定されており、Coworkの使用量ベース課金と合わせると総コストの見積もりが例年より難しくなる。今のうちに試算しておくことを強く勧める。 プラグイン連携については、日本企業でよく使われるBacklogやkintoneへの直接対応は現時点では期待しにくい。ただしM365 Copilot全体のプラグインエコシステムが拡張されつつあるため、今後の対応状況を継続的に追うことが重要だ。 実務的なヒント： 最初は定型業務（会議の議事録整理・レポート集計）から着手し、クレジット消費のコスト感覚をつかむ IT管理者は予算上限の設定と利用レポートの定期確認をルーティン化する モデルを使い分けることでコスト最適化が可能なため、タスクの複雑さに応じた選択ルールを事前に決めておく 筆者の見解 Copilot CoworkがFortune 500に急速に浸透したという事実は、素直に注目に値する。エージェント型AIが「提案→実行の代行」という段階に進化したことを、市場が明確に受け入れ始めている証左だ。 Anthropicとの協業でOpus 4.8とSonnet 4.6を搭載したというのも興味深い判断で、モデル選択の柔軟性という観点ではエンタープライズ向けとして現実的な設計といえる。 一方で「使いこなせるか」という問いは依然として重要だ。エージェント型AIが業務を自律実行するためには、タスク定義の精緻化・データアクセス権限の整備・既存のセキュリティポリシーとの整合など、導入前に解決すべき組織的な課題が多い。ツールが優秀でも、受け入れ態勢が整っていなければ効果は出ない。 「Cowork 1」という独自モデルの開発計画は、中長期で見ると重要な布石だ。サードパーティモデルへの依存を減らしながらエンタープライズ特化の最適化を進める方向性は筋が通っている。Microsoftには、その独自モデルで実力をしっかり示してほしいと思う——それができるポテンシャルは確かにある。 日本企業の多くはまだ「AIで何ができるか」を探っている段階にある。まずは小さく始めて、実際のコストと効果を自社で体感することが先決だ。 出典: この記事は Microsoft Releases Copilot Cowork to Automate Enterprise Workflows Across Microsoft 365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年7月1日、MicrosoftはMicrosoft 365をはじめとする複数のライセンスについて月額料金を一斉に引き上げる。Office 365 E3が$23→$26（約13%増）、Entra P1が最大16%増など、大規模テナントほど年間コストへの影響が無視できない規模に達する。事前に自テナントの影響額を把握するには、PowerShellによる試算が有効だ。 値上げは「M365だけ」ではない 今回の価格改定で特に見落とされがちなのが、Microsoft 365以外のライセンスにも値上げが及んでいる点だ。 ライセンス 旧価格 新価格 値上げ幅 Office 365 E3 $23.00 $26.00 +13% Microsoft 365 E5 without Teams $48.45 $51.45 +6% Office 365 E5 without Teams $29.45 $32.45 +10% Microsoft 365 Business Standard $12.50 $14.00 +12% EMS E3 — — +13% EMS E5 — — +10% Entra P1 — — +16% Entra P2 — — +11% ※上記は米国価格。実際の請求額は国・地域の税制や個別の割引契約によって異なる。 条件付きアクセスポリシーなどゼロトラスト施策に不可欠なEntra P1が最大16%の値上げというのは、セキュリティ投資を進めている企業にとって見過ごせない数字だ。セキュリティ強化のコストが上がるからといって導入を後回しにする選択は、リスクの観点からは本末転倒になりかねない。 PowerShellで影響額を試算する Microsoft Graph PowerShell SDKを使えば、自テナントの契約状況を取得して値上げ影響額を算出できる。必要な権限は User.Read.All と LicenseAssignment.Read.All の2つだ。 ...

Microsoftは2026年5月29日、Microsoft 365 CopilotのCopilot Chat・Excel・PowerPoint・Copilot StudioにAnthropicの最新AIモデル「Claude Opus 4.8」を統合したと発表した。Copilotのモデルセレクターから選択できる形で提供され、複雑なマルチステップ作業や長期間にわたるエージェント的ワークフローへの活用が可能になる。 Claude Opus 4.8——何が強化されたのか Claude Opus 4.8はOpus 4.7から進化したモデルで、前バージョンの強みを継承しつつ以下の点が改善されている。 ツール選択精度の向上: 複数のツールを組み合わせる場面でより適切な判断が可能に 指示への忠実性（Instruction Adherence）: ユーザーや管理者の指示をより忠実に守る マルチターンワークフローの一貫性: 複数ステップにわたる作業でも途中で崩れにくい また、文書作成・データ分析・プレゼンテーション生成においても改善が見られる。Microsoft 365の「Work IQ」と組み合わせることで、組織内のコンテキスト（社内データや業務情報）に基づいた出力が可能になる点も注目だ。 マルチモデル戦略とは何か 今回の展開は、Microsoftが掲げる「マルチモデル戦略」の具体的な一歩だ。従来のCopilotは主にOpenAI系モデルで動作していたが、ユーザーが目的に応じてAIモデルを切り替えられる設計へのシフトが進んでいる。 背景には「すべてのタスクに最適なモデルは一つではない」という現実認識がある。コーディングと文書作成、データ分析とプレゼンテーション生成では必要とされる特性が異なる。モデルセレクターはその差を吸収する仕組みだ。 セキュリティ・コンプライアンス面では、MicrosoftのEnterpriseグレードの管理下でAnthropicモデルが提供される。追加的な外部契約や審査なしに、Microsoft 365のガバナンスポリシーの枠内でClaude Opus 4.8を業務利用できる経路が整ったことを意味する。 実務での活用ポイント 利用開始の条件を確認する Claude Opus 4.8を使うには、Microsoft 365 Copilotライセンスが必要だ。まず「Copilot Cowork（Frontier）」で先行提供され、その後Copilot Chat・Excel・PowerPoint・Copilot StudioのEarlyリリースサイクル環境へ展開される。管理者はMicrosoft 365管理センターで対象ユーザーへの早期展開設定を検討する価値がある。 タスクごとのモデル使い分けを設計する 「使えるようになった」は出発点に過ぎない。どのタスクにどのモデルを使うかを整理することが実務価値を生む。たとえば： 長い仕様書の読み込みと要約 → Opus 4.8の長コンテキスト処理が有効 Excel上での複雑な数式・マクロ生成 → コーディング精度の高さが活きる 日常的なメール返信・議事録 → Copilotの標準モデルで十分 Copilot Studio活用時のガバナンス見直し Copilot Studio経由での展開も含まれるため、社内向けAgentやプラグインを構築する際に使用モデルを指定できる可能性が出てくる。利用可能モデルの管理ポリシーも合わせて見直しておくと後手に回らずに済む。 筆者の見解 「Copilot内で外部AIモデルを選べる」という構造は、筆者が以前から重要だと考えてきたマルチモデル・マルチプラットフォームの考え方と重なる。TeamsやOutlookの定型業務はCopilot標準モデルに任せ、高度な分析や複雑な作業には目的に合ったモデルを選ぶ——という使い分けが、Microsoft 365の枠組みの中で実現しつつある点は評価したい。 ただし、「モデルが増えたこと」と「使いやすくなったこと」は別の話だ。モデルセレクターが存在しても、多くのビジネスユーザーはどれを選べばいいか判断できない。Copilotが真に「Microsoft 365の統合知性」として機能するためには、モデル選択そのものをAIが補助する仕組み——つまり「このタスクにはこのモデルが最適」と自動で提案できる層——が次のステップになると思う。Microsoftにはその素地があるのだから、ぜひ正面から取り組んでほしい。 出典: この記事は Available today: Anthropic Claude Opus 4.8 in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが2026年6月、Microsoft 365（M365）の重要なセキュリティ関連アップデートを複数リリースした。MSP（マネージドサービスプロバイダー）視点で整理すると、IntuneのEdge向けセキュリティベースライン更新、Windows 11 25H2向けセキュリティベースラインの新規追加、そしてDefender for Office 365 Plan 1の標準組み込みという3点が今月のハイライトだ。管理する顧客テナント数が多いMSPほど、対応優先度を早めに判断する必要がある。 IntuneのEdgeセキュリティベースラインが更新 Microsoft Intuneが管理するMicrosoft Edge向けのセキュリティベースラインが新バージョンに更新された。セキュリティベースラインとは、Microsoftが推奨する設定値のパッケージで、エンタープライズ環境でのブラウザセキュリティを一括適用するための基準定義だ。 旧バージョンのベースラインを適用中のテナントは、Intuneコンソール上に「新しいベースラインへの更新が利用可能」という通知が表示される。ただし、自動更新はされないため管理者が明示的に操作する必要がある。変更点の差分を必ず確認し、既存カスタムポリシーとの競合がないかをテスト環境で事前検証してから本番展開するのが鉄則だ。 セキュリティベースラインは「Microsoftが検証した推奨値」であり、これをそのまま使うことが「道のド真ん中を歩く」最も再現性の高い選択だ。独自設定を足し算してカスタマイズし続けると、ベースライン更新のたびに差分管理が煩雑になる。シンプルに保つことが長期的な管理コストを下げる。 Windows 11 25H2向けセキュリティベースラインが新規追加 次世代アップデートとなるWindows 11 25H2向けのセキュリティベースラインが新たにリリースされた。25H2では新機能の追加に伴い、対応するセキュリティポリシー項目も拡張されている。 MSP各社にとっては、顧客環境が25H2へアップグレードされるタイミングに合わせた事前準備が重要だ。特に大規模テナントでは、展開ロードマップを立てる段階からこのベースラインの内容を織り込んでおくと、展開後の設定漏れや後追い対応を防げる。Windows Update for Business（WUfB）やUpdate Complianceと組み合わせて、アップグレードとベースライン適用をセットで計画するのが効率的だ。 Defender for Office 365 Plan 1が標準組み込みに 今月最大の変更点がこれだ。Defender for Office 365 Plan 1が、M365の一部ライセンスに標準搭載される形に変更された。 これまで個別にPlan 1を契約していた組織は、ライセンス構成の重複が生じる可能性がある。まず現在のライセンス棚卸しを行い、余剰が発生していないか確認することを強く推奨する。一方でDefender for Office 365を導入していなかった組織にとっては、フィッシング対策・マルウェア対策・Safe Links・Safe Attachmentsといった機能が自動的に利用可能になるという意味で、セキュリティレベルの底上げとなる。 注意点は「標準搭載＝即座に有効化」ではない点だ。テナントへの展開タイミングや、自動有効化される設定がある場合に既存のメールフローや他のセキュリティ製品との競合が生じないかをMicrosoft 365管理センターで事前確認する必要がある。 実務への影響——MSP・IT管理者がやること 今週中に確認すべきチェックリスト： Intuneコンソールでセキュリティベースラインのバージョン確認：Edgeベースラインの新バージョンが適用可能になっているか確認し、変更差分をレビューする。テスト環境→本番の順で展開 25H2展開計画へのセキュリティベースライン適用を組み込む：顧客のWindows 11展開ロードマップに25H2ベースラインの適用ステップを追加する Defender for Office 365の有効状態を確認：標準組み込みにより自動有効化される機能がないか管理センターで確認。既存のExchange Online Protection（EOP）設定との整合を取る ライセンス棚卸し：Plan 1を別途契約していた場合、重複コストが発生していないか確認しMicrosoftアカウントチームへ相談 筆者の見解 M365のセキュリティ機能が着実に底上げされていることは、率直に評価したい。Defender for Office 365 Plan 1の標準組み込みは、コスト面から導入を見送っていた中小規模組織にも基本的なメール脅威防御が届くことを意味する。MSPにとっては管理対象テナント間の均一化が進むという観点でも歓迎できる変更だ。 セキュリティベースラインの定期更新も、Microsoftがベストプラクティスを継続的に更新し続けているという姿勢の表れだ。「現状維持」を選びがちな現場が多いが、ベースラインに乗り続けることがコストパフォーマンスの高いセキュリティ投資になる。 ただし、個々のセキュリティ機能を並べただけでは本当の価値は出ない。Microsoft Defender、Intune、Microsoft Entra ID、そしてDefender for Office 365が連携し、認証・デバイス・メール・エンドポイントを統合的に守る設計になって初めてM365の真価が発揮される。今月の更新を機に、顧客環境のセキュリティアーキテクチャ全体を見直すきっかけにしてほしい。「Defender入れたから大丈夫」ではなく、「Entra IDのゼロトラストポリシーと合わせてどう機能させるか」という視点で設計することが、MSPとしての本質的な付加価値を生む。 ...

Microsoftが「Microsoft Teams Live Events」を2026年6月30日付けで正式廃止することを確認した。社内放送・全社総会・ウェビナーといった大規模配信を担ってきた同機能は「Teams Town Halls」へ切り替えが必要となり、日本企業のIT管理者には早急な対応が求められる。 何が、いつまでに廃止されるのか Microsoftは段階的なスケジュールを公開している。 日付 変更内容 2026年2月3日（実施済み） 廃止日以降の新規Live Events作成が不可に 2026年6月30日 Teams Live Events 完全廃止 同時期 Microsoft Graph APIの関連エンドポイントも廃止 廃止の対象はTeams Live Eventsの機能本体だけでなく、Graph APIを通じたイベント管理・自動化のエンドポイントも含まれる。社内ツールやPower Automateフローで組み込んでいる場合は特に注意が必要だ。 後継機能「Teams Town Halls」とは Microsoftが移行先として正式に指定しているのが「Teams Town Halls」（タウンホール）だ。大規模仮想イベント向けに設計されており、以下のような用途に対応する。 全社員向け経営アナウンス・CEO講話 社内研修・トレーニングセッション 顧客向けウェビナー・製品発表 定期的な全社ミーティング（All-Hands） Town HallsはLive Eventsと比較してUI・UXが刷新されており、主催者・参加者双方の操作性が向上している。また、Microsoftはイベント管理自動化向けの代替Graph APIも提供しているため、既存の連携をそのまま移植することもできる。 移行前に確認すべき5つのポイント 移行プロジェクトが「突然急ぎ」になる典型例がこのタイプの廃止だ。早めに以下を棚卸しておきたい。 1. 6月30日以降の予定イベント 組織カレンダーを確認し、Live Events形式で登録されているものをすべて洗い出す。年次総会・四半期報告など定例化しているものを見落としがちなので注意。 2. 社内コミュニケーション施策との統合 広報・人事・経営企画が「Live Eventsを使う」と想定している施策がないか確認。IT部門だけで完結する話ではない。 3. ウェビナープロセスの棚卸し 外部向けウェビナーをLive Eventsで運用していた場合、参加登録フォームや招待メールのテンプレートごと切り替えが必要になる。 4. Graph APIを使った自動化・連携の有無 Power Automate、Logic Apps、カスタムアプリからLive Events APIを呼んでいるフローが存在しないか確認し、代替APIへの移行を計画する。 5. ユーザートレーニング 主催者（司会担当・IT担当者）は Town Hallsの操作を事前に習得しておく必要がある。本番直前の初見操作は禁物。 あわせて確認——SharePoint/OneDriveのスタンドアロンプラン廃止 Teams Live Events以外にも、同時期に重要な変更がある。MicrosoftはSharePoint OnlineとOneDrive for Businessのスタンドアロン（単体）プランを段階的に廃止する予定だ。 ...

Microsoftは2026年6月1日をもって、SharePoint Online（Plan 1/2）とOneDrive for Business（Plan 1/2）のスタンドアロンプランの新規販売を終了した。既存ユーザーは現行契約の範囲でサービスを継続できるが、2029年12月の完全廃止に向けてMicrosoft 365スイートへの移行が求められる。 廃止されるプランの概要 SharePoint Online Plan 1/2は、Microsoft 365スイートを購入せずにSharePointだけを契約できる選択肢として提供されてきた。Plan 1は基本的なドキュメント管理・共有・バージョン管理、Plan 2はエンタープライズ検索やコンプライアンス機能を備える上位プランだ。 OneDrive for Business Plan 1/2も同様に、クラウドストレージと同期機能を単独で利用できるプランで、ライセンスコストを抑えたい中小企業や特定部門での採用が多かった。 段階的な廃止タイムライン 時期 内容 2026年5月31日 新規販売・新テナント購入終了 2027年1月 End of Life（契約期間終了まで利用継続可） 2029年12月 完全廃止・アクセス終了 現時点（2026年6月）では既存顧客は引き続きサービスを利用できるが、新規契約・テナントへの追加購入はすでに不可となっている。 なぜMicrosoftはこの決断をしたのか Microsoftは公式に「スタンドアロンプランへの需要低迷」「意図しない・非標準的な利用ケースの増加」「運用コストの上昇」の3点を理由として挙げている。 本音を読み解けば、SharePointやOneDriveを単体で使うだけではMicrosoft 365という統合プラットフォームの真価を発揮できない、という判断だ。TeamsとのシームレスなファイルリンクやCopilotとの連携、E3/E5レベルのコンプライアンス機能——これらはすべてM365バンドルあっての話。単体プランのユーザーがそのまま利用を続けても、Microsoftにとって付加価値を訴求しにくい契約になっていた面は否めない。 実務への影響：日本のIT管理者がとるべき行動 主に3つのシナリオで影響が出る。 1. スタンドアロンプランで運用中の組織 2029年12月まで猶予はあるが、早めに移行計画を立てることが重要だ。移行先の筆頭候補はMicrosoft 365 Business BasicまたはE3。ライセンス単価は上がるが、TeamsやExchange、Outlookなどが付帯するため実質的には機能増のケースが多い。 2. コスト最適化のためにスタンドアロン採用を検討していた組織 すでに選択肢はない。Microsoft 365 E1やBusiness Basicとのコスト比較を改めて行い、必要最小限のスイートを選ぶ判断が現実的だ。 3. パートナー/SIerのエンジニア・営業担当者 顧客テナントのライセンス棚卸しを急ぎ、影響を受けるアカウントを今のうちに特定することが急務。Microsoftも「パートナーは顧客ベースをレビューし、適切なM365プランへの移行を支援するよう」と明示している。 筆者の見解 M365は統合して使うことで価値が出るプラットフォームであり、バラバラに使っても意味がない——これは以前から変わらない考えだ。その観点からは、今回のスタンドアロンプラン廃止はMicrosoftの方向性として理解できる部分がある。 ただし、ストレージ機能だけを必要としているユーザーに対して「フルスイートを購入せよ」というメッセージになることは、率直に言って惜しい。廃止を「コスト都合の押しつけ」と受け取られないためには、統合プラットフォームとして使うことで何がどれだけ良くなるかを、移行期間中に丁寧に示す必要がある。 2029年まで3年以上の猶予がある。この期間をただの「移行猶予」と捉えるのではなく、M365全体の活用を深めるための投資期間と位置づけられれば、組織にとってむしろプラスに転じる可能性は十分にある。Microsoftには、廃止ありきでなく「使って良かった」と感じさせる統合体験を先に届けることに力を注いでほしいと思う。 出典: この記事は Microsoft Retires Standalone SharePoint and OneDrive Plans の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界4大会計事務所のひとつであるKPMGが、MicrosoftのAgent 365とCopilotを全社的に採用し、AIエージェントの管理・監視・セキュリティを一元化する「Trusted AI」フレームワークをグローバル規模で展開すると発表した。Power AutomateフローやServiceNowチケット処理など、実業務での「エージェント型自動化」を段階的にスケールさせていく計画だ。 Agent 365とは何か Agent 365は、Microsoft 365環境内でAIエージェントを展開・管理するためのプラットフォームだ。単体のCopilotとは異なり、複数のエージェントをオーケストレーションし、Power Automate・ServiceNowなど既存の業務システムと連携して「エージェント型」の業務自動化を実現する。Copilot Studioで作成されたエージェントも管理傘下に置けるため、既存のCopilot活用を維持しながら統合管理体制を整備できる。 KPMGの「Trusted AI」フレームワーク KPMGが構築するTrusted AIフレームワークの核心は、AIエージェントに対するガバナンスの実装にある。具体的には以下の3本柱で構成される。 管理（Management）: どのエージェントが、誰に、何の目的で使われているかを可視化する 監視（Monitoring）: エージェントの動作をリアルタイムで追跡し、異常を検知する セキュリティ（Security）: エージェントが扱うデータと権限を適切にスコープする 業務自動化の具体例として、Power Automateを活用したワークフロー自動化や、ServiceNowチケットの自動生成・処理が挙げられている。これらはいずれも、従来人手で処理していた定型業務をAIエージェントが代替する典型的なユースケースだ。 なぜこれが注目されるのか AIエージェントの普及が加速する中、最大の課題は「誰が、何をするエージェントを、どう管理するか」という問いだ。Copilot Studioで誰でもエージェントを作れる時代になった今、管理されていないエージェントが増殖することは、セキュリティリスクと業務混乱の温床になりかねない。 KPMGのアプローチが評価されるのは、単に「AIを導入した」ではなく、エンタープライズ規模でAIエージェントのライフサイクルを管理する仕組みを先行整備した点にある。世界中の大企業クライアントを持つ会計事務所が採用したことで、同様のガバナンスモデルが業界標準として波及する可能性がある。 実務への影響 日本のエンジニア・IT管理者が今すぐ取り組むべき点を3つ挙げる。 1. エージェントの棚卸し 組織内でどんなCopilotエージェントやPower Automateフローが稼働しているか、正確に把握できているだろうか。「気づいたら誰かが勝手に作っていた」状態は管理上の盲点だ。Agent 365の管理画面を活用し、まず現状の可視化から着手するべきだ。 2. 権限設計の見直し エージェントが持つアクセス権限は最小限に絞れているか。Entra IDとの統合を活用し、エージェントに対してもJust-In-Timeアクセスの概念を適用することが望ましい。常時フルアクセスを持ったエージェントは、人間の特権アカウントと同等のリスクを持つ。 3. ServiceNow連携の実用化検討 日本でもITSMツールとしてServiceNowを採用する大企業が増えている。チケット処理の自動化は工数削減効果が大きく、KPMGの事例はPOC設計の参考になる。まず限定的なスコープで効果測定することを勧めたい。 筆者の見解 KPMGのこの取り組みで評価したいのは、「まずガバナンスありき」という設計思想だ。エージェントを使いたいから導入するのではなく、どう管理し、どう監視し、どう責任を持つかを先に定義してからスケールする——この順序が正しい。多くの組織が「とにかく導入してから考える」という逆順で動きがちな中、対照的なアプローチだ。 Microsoft 365という基盤の上に乗ることで、Entra ID・Purview・Defender for Cloud Appsといった既存のセキュリティ・コンプライアンス機能と連携できる点は、Microsoftの統合プラットフォームとしての強みが素直に出るポイントだ。ここは正面から評価したい。 ただし、「Trusted」な運用を実現できるかどうかは、ツールの機能だけでなく、組織のガバナンス体制と人材に大きく依存する。KPMGのようなコンサルティングファームが自社で実践し、そのノウハウをクライアントに提供するモデルは理にかなっている。日本企業が参考にすべき最大の教訓は、「展開前にガバナンスの設計図を描く」という優先順位だろう。 エージェント時代のIT管理は、従来のソフトウェア管理とは質的に異なる。エージェントは「動くプログラム」ではなく「判断するアクター」だ。この認識の転換が、日本のIT部門にも急務として求められている。 出典: この記事は KPMG and Microsoft scale trusted, enterprise AI agents globally through deployment of Agent 365 and Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teams が、会議ロビーで外部ミーティングアシスタントボット（Otter.ai や Fireflies などのサードパーティ製 AI 議事録ツール）を自動検出・ラベル表示する機能を一般提供（GA）として正式リリースした。主催者はリアルタイムでボットの参加を制御でき、IT 管理者は組織全体のポリシーで一括管理できる。 「見えない参加者」問題に正面から向き合う オンライン会議が当たり前になった今、サードパーティ製 AI 議事録ツールはエンジニアや営業担当者を中心に急速に普及している。これらのツールはボットとして会議に参加し、音声を録音・文字起こしする。問題は、招待した覚えのないボットが静かに参加していても主催者が気づきにくいことだ。 取引先との商談や社内の重要な意思決定会議に、相手側が使っている AI 議事録ボットが紛れ込んでいたとする。機密情報が第三者のクラウドサーバーに送られていても、確認手段がなければ防ぎようがない。 自動検出機能の仕組み 今回 GA になった機能では、Teams が会議ロビーの時点で外部ボットを自動識別し、「ミーティングアシスタント」というラベルを付けて明示する。主催者はこのラベルを見て次の3つのアクションを取れる。 承認: 参加を認める ブロック: 参加を拒否する 退出: すでに参加中のボットを退出させる IT 管理者にとって重要なのは、Teams 管理センターから組織全体のポリシーで制御できる点だ。「外部ボットは事前承認必須」「特定ツールは自動ブロック」といった設定が組織単位で適用できる。 実務への影響 IT 管理者・セキュリティ担当者向け まず優先すべきは、自組織でのポリシー設計だ。業種・部門によって以下のように分ける運用が現実的だろう。 経営会議・M&A 関連: 外部ボット一切ブロック 社内プロジェクト会議: 承認制（主催者判断） 外部パートナーとの技術定例: 相手ツールを把握した上で承認 情報セキュリティポリシーや情報取扱規程にこの観点を盛り込むタイミングでもある。 エンジニア・開発チーム向け 社内で AI 議事録ツールを活用しているチームは、まず利用ツールの棚卸しをしておきたい。Microsoft 側の選択肢として、Copilot の Intelligent Recap（Teams Premium の機能）は組織内で完結するため、セキュリティポリシー上の扱いが外部ボットと根本的に異なる点も押さえておきたい。 日本企業に刺さる理由 日本のエンタープライズでは議事録文化が根強く、「誰が議事録を取るか」問題は慢性的な課題だ。このギャップを埋めようとサードパーティツールを使い始めた組織も多いが、情報管理上グレーゾーンになっているケースが少なくない。今回の機能は、「禁止か野放しか」の二択から抜け出す仕組みを提供する。可視化と制御の手段を持った上でルールを整備するきっかけになる。 筆者の見解 この機能のアプローチはゼロトラストの文脈で素直に評価できる。「信頼するな、確認せよ」の原則を会議空間にも拡張した形だ。 長年日本のエンタープライズを見てきた経験から言うと、「禁止によるセキュリティ」には限界がある。サードパーティの AI 議事録ツールを禁止しても、抜け道を探す人は必ず出る。むしろ「見える化して管理する」仕組みを用意した方が実態に即したセキュリティになる。 Non-Human Identity（NHI）管理の観点でも重要な一歩だ。ボットもIDを持つ存在として扱い、Just-In-Time の承認フローと組み合わせれば、会議セキュリティはかなり厳密に制御できる。 一点だけ気になるのは、検出の精度と対象範囲だ。既知のボットだけが対象なのか、未知のツールも含めてふるまいで判定できるのか——ここが曖昧なまま「検出できます」だけで終わると、管理者が過信するリスクがある。Microsoftには、検出の仕組みと対象範囲を透明に開示してほしい。それだけの実力はあるはずなので、正面から説明してもらいたい。 出典: この記事は Microsoft Teams: External Meeting Assistant Bots Now Auto-Detected の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Teamsは2026年6月30日、パンデミック期に一世を風靡した会議レイアウト機能「Together Mode（一緒モード）」を正式に廃止する。カスタムシーンや座席割り当て機能も含めて完全削除され、マルチ参加者会議のレイアウトはギャラリービューに一本化される。 Together Modeとは何だったか Together Modeは2020年7月、新型コロナウイルス禍でリモートワークが急拡大した時期にリリースされた。AIが参加者の頭部と肩を背景から切り抜き、「会議室」「講堂」「カスタムブランド空間」などの共有仮想シーンに合成して表示する機能だ。 当時の印象は強烈だった。「同じ空間にいる感覚」を演出する仮想会議室は、ビデオ疲れが社会問題化しつつある中で心理的な効果を謳い、企業のオールハンズミーティングやイベントでブランデッドシーンとして活用されるケースも多かった。 なぜ今廃止されるのか MicrosoftはMicrosoft 365 Insider投稿の中で廃止の理由を「会議レイアウトの簡素化、バックエンド複雑性の削減、ビデオ品質・安定性・パフォーマンス向上への開発リソース集中」と説明している。 率直に言えば、Together Modeはリモートワークの新鮮さがあった2020〜2021年に最もフィットした機能だ。ハイブリッドワークが定着した現在、会議での「見た目の演出」よりも「会議の実質的な効率化」が求められるようになっている。AI要約、インタラクティブな会議エージェント、スマートリキャップといった機能開発に注力している現状を踏まえると、Together Modeへのリソース投入を継続する理由がなくなっていたとも読み取れる。 廃止後の代替手段 6月30日以降、Together Modeのトグルはビューメニューから削除される。シーン・座席割り当て機能も同時に消える。 残る主な選択肢は以下の通りだ： 用途 代替手段 注意点 マルチ参加者表示 ギャラリービュー 共有シーンなし、個別タイル表示 特定話者の前面表示 スポットライト シーン合成なし 背景を統一したい 仮想背景（個人設定） 全員が同一シーンには見えない ブランデッドイベント空間 代替手段なし（要検討） Together Modeでのみ実現可能だった 特に企業のブランデッドシーンを構築していた組織には直接の代替手段がなく、別のアプローチを模索する必要がある。 管理者が今すぐやるべきこと 棚卸し（今すぐ実施） Together Modeを使用しているカスタムシーンの一覧を作成する Together Modeが設定された定期会議・テンプレートを特定する イベント担当者・総務部門にTogether Mode廃止を通知する ドキュメント更新（6月30日まで） 社内ドキュメント・イベントランブックからTogether Modeの記述を削除する Teams研修資料を更新する 定期会議・Webinarテンプレートの設定を確認・修正する Together Modeを一度も使っていない組織は特段の対応は不要だ。影響を受けるのは主に、カスタムブランドシーンを作り込んでいた組織や、オールハンズ・大規模社内イベントで活用していた組織に限られる。 日本のIT現場への影響 日本の現場では、Together Modeを本格活用していた組織は多くないというのが実感だ。ビデオ会議の定番レイアウトはギャラリービューのままで、Together Modeはデモや一時的なイベントで試した程度という組織が大半だろう。 注意が必要なのは、オールハンズや社内全社会議でカスタムシーンを作り込んでいた場合だ。こうした組織が6月30日の締め切りを見落とすと、定例の全社会議当日にレイアウトが突然切り替わる混乱が起きる可能性がある。Teamsの管理者は今月中に設定を確認し、関係者への周知を済ませておくことを強く推奨する。 筆者の見解 Together Modeは、パンデミック期の閉塞感の中で「一緒にいる感覚」を演出する試みとして、当時は評価されるべき機能だった。ただ、ハイブリッドワークが当たり前になった今、グラフィカルなシーン合成よりも「会議の中身の効率化」に需要は完全にシフトしている。廃止のタイミングとしては理にかなっている。 その上で注目したいのは、削除されたリソースがどこに向かうかだ。Microsoftが説明するとおり「ビデオ品質・安定性・パフォーマンス」への投資に充てられるのであれば、これは正しい選択だ。Teams会議のビデオ品質や接続安定性はまだ改善の余地があり、派手な機能追加と並行して基盤品質の地道な積み上げを続けることこそが、Teamsをビジネスの基盤として使い続けられる根拠になる。 AI会議アシスタントをはじめとした付加価値機能の充実も歓迎だが、まずは「普通の会議が快適に動く」という土台があってこそだ。Microsoftにはその両輪をしっかり回し続けてほしいと思っている。 出典: この記事は Microsoft Teams Retires Together Mode in June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft 365 Copilot Notebooksが2026年6月中旬より、これまでより広いCopilot Chatライセンスのユーザーにも展開を開始した。OneNoteとのクロスプラットフォーム同期、Word・PowerPoint・Excel・Outlookファイルの取り込みによるAI質問、マインドマップ生成など、実用性の高い機能群が管理者操作不要で順次有効化される。 Copilot Notebooksとは何か Copilot Notebooksは、Microsoft 365上でドキュメント・メール・会議録などの情報をまとめて「ノートブック」として管理し、そのコンテキストを踏まえてCopilotに質問できる機能だ。単発のチャットと異なり、複数ファイルを横断した継続的な文脈を保持できる点が特徴となっている。 6月アップデートの主な変更点 Copilot Chatユーザーへの拡大 これまでCopilot Notebooksは主にMicrosoft 365 Copilotのフルライセンス向けに提供されていたが、6月中旬以降はCopilot Chat（旧称Microsoft Copilot、基本ライセンス相当）のユーザーにも段階的に開放される。組織内のライセンス構成によって展開タイミングは異なるが、管理者が特別な設定変更を行う必要はない。 OneNoteとのクロスプラットフォーム同期 今回の更新で最も実務的なインパクトが大きいのが、OneNoteとの双方向同期だ。OneNoteで書き留めたメモやページがCopilot Notebooksと連携され、逆方向のアクセスも可能になる。会議の場でOneNoteにメモを取りながら、後でCopilot Notebooksから「先週の全打ち合わせのサマリーを出して」といった横断的な質問ができるようになる。 Word・PowerPoint・Excel・Outlookファイルの取り込み ノートブックにOfficeドキュメントを直接追加し、その内容をコンテキストとしてAIに質問できるようになった。たとえば過去の提案書（Word）と売上データ（Excel）を同一ノートブックに入れ、「この提案の成果を数字で振り返ると？」のように跨いで質問できる。PowerPointの場合はスライド内容を解析してマインドマップの自動生成も可能になっている。 管理者操作不要の自動展開 テナント管理者がポリシーを変更したり、機能を手動で有効化したりする必要はない。ライセンスが対象であれば自動的に展開される仕組みのため、IT部門への問い合わせが増える可能性がある点は注意しておきたい。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニアの視点: プロジェクトの仕様書・議事録・タスク管理シートをノートブックにまとめておけば、「先週の決定事項は？」「この仕様の背景は？」を都度ファイルを開かずに確認できる。コードレビューや技術調査のナレッジを蓄積する用途にも有効だ。 IT管理者の視点: 自動展開のため、ユーザーから「新しい機能が使えるようになった」という問い合わせが来る可能性がある。Copilot Chatライセンスの対象範囲と、どこまでの機能が含まれるかを事前に把握し、ヘルプデスク対応の準備をしておくことを推奨する。Notebooksに取り込めるファイルは社内情報を含むため、共有設定の教育も合わせて行うとよい。 情報管理の観点: OneNote連携によって「OneNoteに書いたメモがAIに読まれる」ことになる。機密情報の取り扱いポリシーをユーザーに周知するタイミングとして活用するのが賢明だ。 筆者の見解 今回の更新は、Copilot Notebooksの実用性という点でひとつの節目になる。特にOneNote連携は「ミーティングでメモを取る場所」と「AIが参照する情報ストア」が統合されることを意味しており、地味に見えて業務フローへの影響は大きい。 Copilot Chatライセンスへの拡大も評価できる点だ。フルライセンスは1ユーザー月額の負担が大きく、全社展開に踏み切れていない企業が多い。Notebooksのような便利機能が広いライセンスで使えるようになれば、Copilotが「本当に日常業務で使えるツール」として定着するきっかけになりうる。 ただし、正直に言えば、この方向性で進んでほしいと思う一方で、もう少し速いペースを期待したい気持ちもある。ドキュメントを横断してAIに質問するというユースケースは、かなり以前から多くのユーザーが求めてきたものだ。それが今ようやく正式機能として整ってきたというのは、「遅すぎた」というよりも「ようやく実用レベルに届いた」という印象だ。Microsoftが持つOfficeエコシステムの広さは他に類を見ない強みであり、その土台の上でAI機能を積み上げていく戦略には一定の正しさがある。この路線を着実に深化させていってほしいと、応援する立場から期待している。 OneNote・Word・Excel・Outlookという「普段から使っているもの」を前提にしているのは、Microsoftらしいアプローチだ。習慣を変えずにAI活用を始められる設計は、特に現場への展開を考える企業にとって現実的な選択肢となる。 出典: この記事は What’s New in Notebooks | June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は Build 2026（6月2日）にて、Microsoft 365 Copilot Business をプロモーション限定 SKU から永続的な正式製品へ昇格させると発表した。7月1日以降は月額21ドルが定価となり、現在の18ドルというプロモーション価格は6月30日をもって終了する。 何が変わるのか——価格とパッケージの詳細 単体プランの価格変更 時期 月額（ユーザーあたり） ～2026年6月30日 $18（プロモーション価格） 2026年7月1日～ $21（正式定価） 50人チームで年間換算すると、プロモーション価格では10,800ドル、正式価格では12,600ドルと差額は1,800ドルになる。6月30日以前に契約を確定させれば18ドルが維持されるため、導入を検討中の企業にとって6月末は実質的なデッドラインだ。 新設されるバンドルプラン 7月1日以降、新規の Microsoft 365 商用顧客向けに2つのバンドルプランが追加される。 Microsoft 365 Business Standard with Copilot — 月額 $23.50／ユーザー Microsoft 365 Business Premium with Copilot — 月額 $32.00／ユーザー 既存のスタンドアロン Copilot Business プランを持つユーザーは、引き続き単体プランのまま更新可能だ。 Work IQ APIの一般提供開始——Copilotが「賢くなる」鍵 Build 2026 で合わせて発表された Work IQ API は、6月16日に一般提供（GA）へ移行する。 Work IQ は、Copilot に組織固有のコンテキストを与えるインテリジェンス層だ。メール・会議・ドキュメント・組織構造を横断的に参照することで、Copilot は単なる汎用AIから「この組織のことを知っているアシスタント」へと変わる。 たとえば「Aプロジェクトの件で返信して」と打つだけで、担当者・関連ドキュメント・過去の会議録を踏まえた下書きが生成される。Work IQ なしの Copilot はあくまで汎用補完ツールに過ぎない。 各アプリでの具体的な活用シナリオ Outlook — メールスレッドの要約、返信案の自動生成、アクション項目の抽出 Teams — 会議の文字起こしと意思決定・ネクストアクションのサマリー生成 Word — プロンプト指定によるドラフト作成、箇条書きから文章への展開 Excel — 自然言語によるデータ分析と可視化 PowerPoint — Word文書をもとにしたデッキ自動生成 さらに Copilot Studio と Cowork Skills 経由で Shopify・Xero・DocuSign・Asana など1,000以上の外部ツールと連携できる。会議後のCRM更新やテンプレートからの契約書生成など、「要約」を超えた「実行」が可能になっている点が重要だ。 ...

Microsoft CEOのSatya Nadella氏は、6月2日（現地時間）に米サンフランシスコのFort Mason Centerで開幕した「Microsoft Build 2026」において、Word・Excel・PowerPointを含むOffice 365 Copilot製品群でエージェントモード（Agentic Mode）がデフォルトモードになったことを正式に発表した。同機能はすでに4月22日に一般提供（GA）が開始されており、Buildはその本格展開を内外に宣言する場となった。 「アシスタント」から「非同期コワーカー」へ 従来のCopilotは、選択した範囲や指定した箇所に対してその場で提案を行う「同期型アシスタント」として動作していた。これに対し、エージェントモードでは文書全体を自律的に編集・処理できる「非同期コワーカー」として機能する。 Nadella氏は最近の決算発表でこの変化をこう説明している：「エージェントモードは、主要ドメインにわたって長時間にわたるタスクを自律実行できる非同期コワーカーへの移行を意味する」。 つまり、「この報告書を最新の業界トレンドを踏まえて全体的に更新して」と指示すれば、AIが文書構成の見直しから情報補完まで自律的にこなす——そういう世界への転換だ。選択範囲単位の補助から、タスク単位の実行へと役割が根本的に変わる。 Build 2026の全体像：Windows 12なし、エージェントが主役 10年ぶりのサンフランシスコ開催となったBuild 2026だが、ハードウェアやWindows 12の発表はない。「ノーフラフ（余計なものなし）」と宣言されたキーノートが示す通り、今年のテーマは一点に絞られている——エージェントAIだ。 カンファレンスのセッションは以下の4本柱で構成される： エージェントAIワークフロー — 企業向けAIエージェント管理基盤「Microsoft Agent 365」（5月1日GA）を中心とした活用事例と展開方法 GitHub Copilotの進化 — VS Code内でのマルチエージェント対応、GitHub-Azure統合の深化、Copilot CLI（3月GA）をベースとしたマルチエージェントターミナルワークフロー Azure AI Foundryの更新 — クラウドAI開発プラットフォームの最新機能と開発者向け統合 Windowsネイティブのローカル AI開発 — Foundry Localツールなど、オンデバイスモデル実行APIのトラック Windows 12については2027年以降が現実的な発表ウィンドウとされており、「Hudson Valley」「CorePC」というコード名はいずれも2023年のWindows 11計画に紐づいた内部プロジェクトであり、新OSの話とは無関係だ。 WinUI 3によるネイティブ回帰とパフォーマンス改善 Buildではネイティブアプリ開発への回帰も注目ポイントだ。MicrosoftのPartner ArchitectであるRudy Huyn氏が主導するチームが、WebView2ラッパーへの依存をやめ、WinUI 3で100%ネイティブなWindowsアプリを構築する体制を整えている。スタートメニュー自体もWinUI 3での再構築が進んでおり、ソフトウェアエンジニアBeth Pan氏のベンチマークではFile ExplorerコンポーネントでWinUI 3が25%のパフォーマンス改善、メモリ割り当て41%削減、関数呼び出し45%削減を達成したと報告されている。 エージェントとセキュリティ：見落とせない設計課題 AIエージェントにシステムアクセスを与える際のセキュリティリスクに対応するため、Buildでは「Claws on Windows: Designing Safe, Bounded Agent Actions」という専用セッションが設けられている。実際の設計上の失敗事例を分析しながら、より安全な境界設計のアーキテクチャを示す内容だ。 エージェントモードが文書全体を自律操作するということは、誤操作・誤指示・悪意ある操作に対する防御設計が不可欠であることを意味する。企業展開において、エージェントの権限スコープをどう定義し管理するかは避けて通れないテーマだ。 実務への影響 Microsoft 365ユーザーにとっての変化： Wordで「議事録を標準フォーマットに整えて」「プレゼン向けに要点を再構成して」といった指示が、より自律的かつ文書全体を対象に実行されるようになる バッチ処理的な作業（「この30件の報告書を全部同じ構成に統一して」）をCopilotに委ねる選択肢が現実的になる IT管理者として今すぐ把握すべきこと： ...

Microsoft 365 CopilotにAnthropicの最新AIモデル「Claude Fable 5」が追加された。これまでOpenAIモデルを中心に展開してきたCopilotが、Anthropicモデルの選択肢を加えることで、企業ユーザーの高度な推論・分析タスクへの活用幅が大きく広がる。 CopilotのマルチモデルAI戦略が本格化 Microsoft 365 Copilotはこれまで、主にOpenAIのGPT系モデルを基盤として展開されてきた。今回のアップデートでAnthropicのClaude Fable 5が選択可能になったことは、Microsoftが「特定モデルへの依存」から脱却し、「タスクに最適なモデルを使い分けるマルチモデル戦略」を本格推進していることを示している。 Claude Fable 5は、複雑な多段階推論・長文コンテキスト処理・コード生成などに強みを持つAnthropicの最新モデルだ。企業ユーザーはMicrosoft 365 Copilotのインターフェース上から、用途に応じてモデルを選択して利用できる。 管理者が把握すべきポリシー制御 テナント管理者は、Microsoft 365管理センターを通じて組織単位でClaude Fable 5へのアクセスを制御できる。全ユーザーへの開放、特定グループへの限定公開、完全ブロックといった粒度での管理が可能だ。 展開前に確認しておきたい主なポイント： データ処理の境界: Anthropicモデルへのプロンプトが、Microsoftの商用データ保護の枠組みでどう扱われるか コンプライアンス要件: 社内の情報管理ポリシーや業界規制（金融・医療等）との適合性の確認 コスト管理: モデルごとに処理コストが異なる場合の利用状況モニタリング体制 まずはパイロットグループに限定して展開し、利用状況とアウトプットの質を確認してから全社展開するアプローチが堅実だ。 実務への影響——日本のIT担当者にとっての意味 日常業務はそのままに、高度なタスクで使い分ける 会議の議事録要約やメールの返信案作成といった日常業務は、引き続きCopilotのベースモデルが担う。一方、複雑な要件定義書の作成・大量データの分析・多段階推論が必要な法律や財務ドキュメントの処理などでは、Claude Fable 5の特性を活かせる場面が増えるだろう。 「AIを使う」から「AIを使い分ける」フェーズへ 日本の企業IT担当者にとって、この変化は「AIツールの導入」という段階を超え、「業務プロセスとAIモデルの最適配置を設計する」段階に入ったことを意味する。モデルの特性を理解し、どの業務にどのモデルを当てるかを判断できる人材が、今後より重要になってくる。 筆者の見解 CopilotへのAnthropic Claude統合は、Microsoftが現実的なマルチモデル戦略に踏み出したという点で、評価できる動きだと思う。「Copilotだけで全部やる」ではなく、外部の優れたモデルをプラットフォームに取り込んで価値を高める方向性は、M365というエコシステムの強みを活かした正しいアプローチだ。 ただ、率直に言えば、今後の鍵は「外部モデルを取り込めた」という事実よりも、「それを企業ユーザーが実際に使いこなせる体験を提供できるか」にある。モデルの選択肢が増えるだけでは意味がなく、どのタスクにどのモデルが適しているかをユーザーが直感的に判断できるUIとガイダンスが伴ってこそ、この戦略は実を結ぶ。 M365はプラットフォームとして統合的に使うことで初めて価値が出る。バラバラなAIモデルの寄せ集めにならないよう、体験の一貫性と管理の簡便さをどう維持するかが、今後Microsoftに問われる本質的な課題だろう。Claude Fable 5の追加は出発点であって、終着点ではない。 出典: この記事は Available today: Anthropic Claude Fable 5 in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Copilotをチャット型アシスタントから自律的に動く「委任エージェント（Delegated Agent）」へと進化させる「Scout Autopilot」構想を発表した。エンタープライズIDや権限管理、記憶機能、監査証跡を持つ「常駐ソフトウェア同僚」として設計されており、ユーザーが指示を出さなくても権限の範囲内でプロアクティブにタスクを実行する新しいCopilotの姿が明らかになった。 Scout Autopilotとは何か 従来のCopilotは「聞かれたら答える」リアクティブなアシスタントだった。Scout Autopilotはこのモデルを根本から変える。ユーザーからの指示を待つのではなく、委任された権限の範囲内でプロアクティブにタスクを見つけ、実行し、報告するエージェントとして機能する。 Microsoftが描くのは、まるで新しい同僚が入社したような存在だ。「常駐ソフトウェア同僚（Resident Software Colleague）」という表現は単なる比喩ではなく、設計思想そのものを反映している。 エンタープライズ統制との統合 Scout Autopilotが注目される最大の理由は、企業が最も懸念するガバナンス面への対応だ。 エンタープライズID管理 Entra ID（旧Azure AD）と統合し、エージェントが「誰として」動作するかを明確に定義できる。これは従来のCopilotにはなかった概念だ。 権限（Permission）の明示的な委任 エージェントに付与する権限を細かく制御できる。「このエージェントにはメール閲覧と下書き作成のみ許可」のような粒度での権限設定が可能になる。 メモリ（Memory）機能 会話をまたいだ文脈の保持が可能になる。「先週議論した件を踏まえて」という形での継続的な作業支援が実現する。 監査証跡（Audit Trail） エージェントが何を実行したかをログとして残す仕組みが組み込まれており、コンプライアンス要件が厳しい金融・医療・公共セクターでも活用できる土台が整う。 日本のエンタープライズIT管理者が今押さえるべきポイント 短期的に確認・準備すべきこと： Entra IDの整備が前提: Scout Autopilotの恩恵を受けるには、Entra IDによる認証・認可の管理が整っていることが大前提。既存のAD環境からのハイブリッド移行状況を確認しておく 最小権限の原則をエージェントにも適用する: エージェントに過剰な権限を与えない。Just-In-Timeアクセスの概念をエージェント管理にも適用し、「常時アクセス権の付与」という最大のリスクを避ける 監査ログの活用計画を立てる: ただログを収集するだけでなく、Microsoft SentinelやPurviewとの連携・アラート設定まで設計しておく M365管理者がいま確認すべき設定： Purview（コンプライアンスセンター）の監査機能の現状 Microsoft 365管理センターのAIアプリポリシー設定 Copilot利用ログの取得状況 エンジニア・開発者向け： Scout AutopilotはMicrosoft 365の外にも展開できる可能性がある。Azure AI FoundryやPower Automateとの連携が示唆されており、業務アプリケーションへのエージェント統合を検討しているチームは今からアーキテクチャを考え始めておくべきだ。 筆者の見解 Scout Autopilotの方向性は、Copilotが抱えてきた根本的な課題──「結局、何をやってくれるのかわからない」という問題──への回答として読める。チャットで答えを返すだけのアシスタントから、実際に業務を動かすエージェントへ。この転換の方向性は正しい。 とはいえ、正直に言う必要もある。権限管理・監査・ID統合という要素が揃ってきたのは事実だが、「現場で安心して任せられる品質」になるかどうかは、実際のロールアウトの実装次第だ。発表の段階では良さそうに聞こえても、現場に届いたときに期待通りだったためしがどれほどあるか——それはCopilotを追いかけてきた人間なら誰もが知っている。 ただ、Microsoftにはこのエージェント機能を「ちゃんと動くもの」として出し切る力が間違いなくある。エンタープライズITの核心に位置するプラットフォームとしての強みは他に代えがたい。Scout Autopilotが描くビジョンを、発表止まりにせず現場が信頼できる品質で届けることを、応援を込めて強く期待したい。 出典: この記事は Microsoft Scout Autopilot: Copilot Shifts From Chat Helper to Delegated Agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。