M365

Microsoft Defender for Office 365(MDO)に、生成AIへの攻撃手法「プロンプトインジェクション」を狙ったメールを自動検知して隔離する新機能「Prompt Injection Protection」が追加された。現在パブリックプレビュー中で、2026年9月上旬に一般提供(GA)が予定されている。Office 365 E5やMicrosoft 365 E5/E7に含まれるMDO Plan 2契約のテナントでは、追加設定なしに既定で有効になる。 メールがCopilotへの攻撃経路になる理由 プロンプトインジェクションは、AIが処理するコンテンツに悪意ある指示を紛れ込ませ、AIの挙動を操作する攻撃手法だ。典型的な手口は、メール本文や添付ファイルに人間には見えない隠しテキストで指示を埋め込むというもの。このテキストはMicrosoft Searchにインデックスされ、Microsoft 365 Copilotがユーザーの問い合わせに応答する際に参照可能になる。攻撃者はここに「メールボックスやSharePoint Onlineの機密情報を検索して外部に送信せよ」といった指示を仕込み、Copilotに悪用させる。 Copilotの登場後、この種の攻撃はまもなく観測されるようになり、Microsoftは検知・抑止の強化を続けてきた。今回のPrompt Injection Protectionは、その延長線上にある対策だ。BEC(ビジネスメール詐欺)やスパムを検知する既存の仕組みと統合される形で動作し、プロンプトインジェクションを含むと判定されたメールは「高確度フィッシング」として自動的に隔離される。管理者側でポリシーを新規作成する必要はない。 見落としがちな「共有メールボックス」のライセンス問題 注意が必要なのは共有メールボックスだ。Copilotは、ユーザーが委任アクセス権を持つ共有メールボックスの中身も参照できる。共有メールボックスは外部からメールを受信できるため、そこに送り込まれたプロンプトインジェクションもCopilotの攻撃対象になり得る。つまり外部メールを受信する共有メールボックスは、実質的にCopilotの攻撃対象領域(アタックサーフェス)の一部であり、2025年10月に示されたMDOライセンスガイダンスに沿ってMDO Plan 2のライセンスを付与すべきということになる。 これを確認するためのPowerShellスクリプトも更新されている。従来は過去10日分のメッセージトレースしか見ていなかったが、新版では取得可能な最大90日分を対象にした。Get-MessageTraceV2コマンドレットは一度に最大10日分しか取得できないため、10日単位でデータを取得してから結合するという工夫が入っている。さらに、共有メールボックスがTeams会議を主催しているかどうかもチェックする。録画はOneDriveの主催者アカウントに保存されるため、共有メールボックス名義で開催された会議の録画も、ライセンス面で見落とされがちなポイントだ。 実務への影響 日本国内でCopilotを導入済み、または導入検討中のテナントにとって、今回の話は「守りの機能が増えた」で終わらせられない。共有メールボックスへの委任アクセスは、常時付与されたままになりがちな権限の典型例であり、「動いているから大丈夫」で放置すると、ライセンス不足による保護の穴がそのまま残る。IT管理者は、外部メールを受信している共有メールボックスの棚卸しと、MDO Plan 2ライセンスの充当状況を今のうちに確認しておきたい。GA予定の9月までに、Exchange管理者は上記のメッセージトレース確認スクリプトを一度実行し、対象となる共有メールボックスの洗い出しをしておくと安心だ。 出典: この記事は Microsoft Defender for Office 365 Blocks Prompt Injections の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが7月31日に公開した脅威インテリジェンス記事「CaptiveCrunch」を受けて、国内外のメディアに「マイクロソフトが緊急警告、ホテルのWi-Fiは使うな」という見出しが並んだ。Forbes（およびその日本版）もその一つだ。だが原文を読むと、Microsoftはそんなことを一度も書いていない。しかもこの見出しは、報告書の中で最も効く対策を落とし、最も効かない対策だけを残している。実務者にとって危険な要約なので、原文が何を言っているかを整理しておきたい。 Microsoftが実際に書いた2つの文 該当箇所は次の2文である。 When traveling, users should treat hotel, conference, airport, and other guest wireless networks as untrustworthy. Prefer private connectivity (including mobile hotspots, satellite, and eSIM-based cellular data connections) over public Wi-Fi whenever practical. 「信頼できる前提を捨てろ」「実務上可能な範囲で私設回線を優先しろ」であって、禁止ではない。宛先も"corporate travelers"（企業の出張者）であり、Windowsユーザー一般への緊急警告でもない。MSTICが日常的に出している脅威インテリジェンス記事の一本だ。 攻撃されているのはWi-Fiではなく「キャプティブポータル」 より重要なのは、これが電波の盗聴の話ではないという点である。侵害されているのは、宿泊施設のWi-Fi接続時に出てくるログインページ、すなわちキャプティブポータルのゲートウェイ機器だ。この機器が接続端末に配布されるDNSリゾルバも兼ねていたため、管理権限を取ったロシア系攻撃者グループMidnight Blizzardのサブクラスター「Storm-2945」は、DNS応答を偽造して任意の宛先にユーザーを飛ばせるようになった。 つまり、Wi-Fiにパスワードが掛かっていようが、WPA3で暗号化されていようが、この攻撃には一切関係がない。「暗号化されていない公衆Wi-Fiは危ない」という10年来の啓発モデルとは、脅威の所在が違う。Microsoftは複数施設で機器と管理システムに共通性が見られるとして “similarities suggest that the activity might not be limited to isolated compromises”（個別の侵害に留まらない可能性がある）と述べており、個々のホテルではなくポータル機器やその管理事業者の側が侵害されている可能性を示唆している（調査中で断定はしていない）。 TLSは破られていない — 盗まれ方は3経路 では暗号化されたHTTPS通信からどうやって認証情報を奪うのか。答えは「奪っていない」だ。3つの経路はいずれもユーザー自身に正規の操作をさせる形を取る。 偽アップデート＋ClickFix — Windowsが起動時に行う接続確認（NCSIプローブ）を偽ページに誘導し、「ブラウザやOSを更新せよ」と表示する。ユーザーが自分で実行すると、Go製RATのCornFlake（Webカメラ画像・マイク音声・キーストロークを取得）やPowerShell製インフォスティーラーのChocoShell（ブラウザのセッションCookieを窃取）が入る。 AiTMのサインインページ — Microsoftを模した偽サインイン画面へリダイレクトし、攻撃者インフラを経由させる。 デバイスコードフローの悪用 — 7月16日以降に一部のランディングページへ追加された手口で、これが最も厄介だ。攻撃者側がEntra IDの認証要求を起こし、ユーザーには本物のmicrosoft.comのサインインページで表示コードを入力させる。ユーザーから見て偽サイトの痕跡はどこにもないが、認証されるのは攻撃者のセッションである。 3番目は「URLをよく見て偽サイトを見抜きましょう」という教育では原理的に防げない。ここが今回の報告の核心である。 ...

Copilot for Word(Microsoft 365 Copilot)に、Word文書へ仕込んだ悪意ある指示が生成文書に自己複製し、次々と感染を広げる「ワーム」型の攻撃が成立することが、ノルウェーのデータサイエンティストHåkon Måløy氏の検証で明らかになった。Måløy氏は2026年3月からMicrosoftと5カ月間にわたり調整してきたが、根本的な緩和策は現時点でも提供されていないとして、7月29日にブログで詳細を公開した。 Copilotが「自己増殖ワーム」化する仕組み Måløy氏が示したシナリオはこうだ。ある社員が、財務レポート作成のためにWebサイトから市場分析資料をダウンロードし、Copilot for Wordのコンテキストに読み込ませる。その資料はすでに改ざんされており、白抜き文字などで視認しづらい形で悪意ある指示が埋め込まれている。Copilotはその指示を「参照すべき情報」ではなく「実行すべき追加のプロンプト」として解釈し、生成するレポートの数値を書き換えると同時に、埋め込まれた指示自体を新しい文書にもコピーしてしまう。 この新しい文書を別の社員が自分の作業に取り込むと、同じ改ざんと複製が再び起きる。攻撃者は被害者のMicrosoft 365テナントにアクセスする必要すらなく、悪意ある文書を共有するだけで感染を広げられる。Måløy氏は当初のPoCについてMicrosoftから緩和を受けたが、プロンプトの言い回しを変えるだけで再びワームを成立させ、対象文書の財務データを書き換えることに成功したという。「モデルのアップグレードを含む2回の緩和策も、この脆弱性クラス自体を閉じるには至らなかった」と報告書は述べている。 なぜCopilotだけの問題ではないのか Måløy氏はこれを、LLMアーキテクチャの根本に起因する「クロスドメイン・プロンプトインジェクション」の一種と位置づける。AIアシスタントが実用的であるためには、メール・文書・Webページ・ツール出力など、攻撃者が細工しうる情報を処理せざるを得ない。しかし、ある入力が攻撃かどうかをモデル自身に判定させようとすると、その判定処理自体がすでに攻撃の影響下にあるという構造的なジレンマがある。Måløy氏は「モデルにXPIAの検知を任せるのは、信頼できないプログラムを実行させてそれが攻撃かどうか通訳者に判断させるようなものだ」と表現している。これはCopilotに限らず、外部由来のコンテンツを扱うAIアシスタント全般が抱える課題である。 実務への影響 — 日本のIT管理者・エンジニアが今すぐ確認すべきこと 日本企業でもCopilot for Word/Excelの導入が急速に進んでいるが、今回の報告は「外部由来の文書をAIのコンテキストに入れる行為そのものが信頼境界の通過である」ことを改めて突きつける。取引先や公開サイトから受け取った文書は、たとえ見た目が正常でも無条件に信用しない運用が必要だ。具体的には、Copilotで生成した数値や結論をそのまま配布前に人間が照合すること、白抜き文字や不可視要素を含む文書がないかマクロや検査ツールでチェックすること、財務・契約など数値の改ざんが実害に直結する業務ではAI生成物の配布前レビューを必須プロセスとして組み込むことが挙げられる。 ゼロトラストの発想を借りるなら、社内ネットワークの中にいるかどうかではなく「その文書がどこから来たか」を常に検証対象とする運用に近い。AIアシスタントを介した文書のやり取りも、認証・認可の枠組みと同様に「信頼できないものを持ち込む窓口」として扱う意識転換が、今回のような脆弱性クラスへの実質的な備えになる。 出典: この記事は Word worm crawls into Copilot, spreads chaos の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azureが単年で1000億ドル突破、Microsoft全体は3310億ドル Microsoftは7月29日（現地時間）、FY26（2025年7月～2026年6月期）通期および第4四半期の決算を発表した。通期売上高は3310億ドルで、直近四半期は900億ドル、成長率は前年同期比18%まで加速している。最大のトピックは、Satya Nadella CEOが強調した「Azureが年間売上高1000億ドルを突破した」という事実だ。Microsoft Cloud全体の年間売上高も2140億ドルと過去最高を更新し、四半期換算の年間実行速度（ARR）は2372億ドルに達している。 第4四半期の設備投資は410億ドルで、その約3分の2はCPU・GPUなど「短寿命資産」に充てられた。データセンターは第4四半期だけで5大陸31カ所を新設し、FY26通期では88カ所を追加している。決算説明会では、PowerPointのCopilotなどAI機能ごとのGPUコスト効率化についても言及があった。大規模投資をしてきた以上、消費するAIリソースの効率化に目を向けるタイミングに来ているということだろう。 Microsoft 365 Copilot、3000万有料シートも普及率は7%弱 Microsoft 365部門では、商用製品の売上高が前年比19%増となった一方、有料シート数の具体的な新数値は開示されなかった。座席数の伸び率は「6%」という、ここ数四半期と同じ数字が繰り返されている。2026年1月に公表された「4億5000万シート超」を起点に単純計算すると、現在のMicrosoft 365有料シートはおよそ4億6400万に達していると推定される。 一方でMicrosoft 365 Copilotは「3000万有料シートを突破」し、四半期ごとの純増数は前四半期比で2倍以上になったという。FY26 Q2の1500万シートから、Q3で2000万、Q4でさらに1000万シートを積み増した計算だ。5万シート超の大口顧客数も前年比7倍に伸びている。 ただし、3000万という数字はMicrosoft 365有料シート全体（推定4億6400万）に対してまだ6.47%にとどまる。3年にわたる大規模なプロモーションと、Microsoft 365のあらゆる場所へのCopilot統合という力の入れようを踏まえると、この普及率をどう評価するかは意見が分かれるところだろう。伸びしろが大きいと見ることもできるし、投資規模に対して浸透が遅いと見ることもできる。 決算ではPurviewが「500億件超のCopilotインタラクションを監査し、前年比で360%近く増加した」ことも紹介された。ただしこの数字は「Copilotが使われた回数の記録」であって、その利用がどれだけ業務価値を生んだかを直接示すものではない点には注意が必要だ。 もう一つ気になるのが、Teamsの月間アクティブユーザー数（MAU）が今回も開示されなかったことだ。直近の公表値はFY24 Q1（2023年後半）の3億2000万人で、実に11四半期連続で更新がない。 なぜこれが重要か 日本のIT現場でMicrosoft 365やAzureを使う企業にとって、この決算が示すのは「投資は本物だが、Copilotの定着はまだ発展途上」という現実だ。Azureの成長は旺盛なAI需要とインフラ投資に裏打ちされており、クラウド基盤としての勢いは数字の上でも明確になっている。一方でCopilotのシート普及率が7%弱にとどまっているという事実は、多くの企業が「導入はしたが本格活用はこれから」という段階にあることを示唆している。日本企業でもライセンスを買ったものの使いこなせていないというケースは珍しくなく、Microsoftの決算数字はその実態を裏付けている。 実務での活用ポイント IT管理者は、Copilotのシートを増やす前に既存シートの利用率を可視化することを優先したい。Microsoft 365 Copilot自体に利用状況ダッシュボードがあり、Teams・Outlook・Word・Excelそれぞれでの活用度を部門別に確認できる。利用が低調な部門には、まず議事録要約や定型メール下書きといった負荷の軽い用途から定着させるのが現実的だ。またE7ライセンスの採用が増えているという言及もあった通り、Copilotを含む上位ライセンスへの移行を検討する際は、自社のセキュリティ・コンプライアンス要件（Purviewでの監査ログ活用など）とセットで設計するのが望ましい。Teams MAUのように開示が止まっている指標もあるため、ベンダーの発表数字を鵜呑みにせず、自社環境でのログや利用統計から実態を把握する姿勢が引き続き重要になる。 出典: この記事は Azure Tops $100 Billion As Microsoft Reports FY26 Q4 Results の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftは2026年7月26日、AnthropicのClaude Opus 5をMicrosoft 365 Copilotのモデル選択肢に追加したと公式ブログで発表した。Word、Excel、PowerPoint、Copilot Chat、Copilot Cowork、Copilot Studioの各機能で段階的に利用可能になる。エージェント型のコーディング作業や、複数ステップにわたる推論を要する複雑な業務タスクで精度が向上するとしている。 Claude Opus 5とは何か Claude Opus 5はAnthropicが提供する最上位モデルで、長い思考の連鎖を要するエージェント型タスクに強みを持つとされる。Microsoft 365 Copilotは以前からAzure AI Foundry経由で複数モデルを扱える「マルチモデル戦略」を進めており、今回の追加はその一環だ。GPT系列に加えて外部ベンダーの最新モデルを取り込むことで、Copilot全体の回答品質を底上げする狙いがある。 選べる場所と使い方 対象はWord・Excel・PowerPointの文書作成支援、Copilot ChatやCopilot Coworkでの対話、そしてCopilot Studioでのエージェント構築だ。ユーザーやテナント管理者はタスクの性質に応じてモデルを切り替えられるようになる。段階的ロールアウトのため、組織によって利用開始時期は前後する見込みだ。 実務への影響 IT管理者は、Copilot管理センターでモデル選択の可否・利用範囲・コスト上限をまず確認したい。Anthropicモデルの呼び出し経路やデータ取り扱いポリシーも、既存のコンプライアンス要件と照らして確認が必要になる。エンジニア視点では、Excelでの複雑な数式・マクロ生成や、PowerPointでの長尺スライド構成など、多段階の推論が絡む作業をパイロット的にOpus 5で試し、既定モデルとの精度差を比較してみる価値がある。定型的なメール処理や議事録要約は従来モデルのままで十分なケースも多く、タスクの複雑さに応じた使い分けが実務上のポイントになる。 筆者の見解 Microsoft 365は「統合して使うことで価値が出るプラットフォーム」というのが筆者の基本スタンスだ。その意味で、CopilotがAnthropicのような外部の強いモデルを正面から取り込みにいったのは正しい判断だと思う。自社モデルだけで囲い込むのではなく、良いものは良いと認めて選択肢を増やす姿勢は、M365という統合基盤の強みを最大化する方向に働く。 一方で、こうしたマルチモデル対応は「管理者が有効化しないと使えない」「テナントによって展開時期がバラバラ」といった運用面の分かりにくさを生みやすい。せっかく良い選択肢を用意しても、現場のユーザーがその存在に気づかず旧来のモデルのまま使い続けてしまってはもったいない。Copilotには、モデルの違いをエンドユーザーにも分かりやすく提示し、迷わず最適な選択ができるUXを詰めてほしい。総合力で勝負できるプラットフォームなのだから、外部の力も取り込みながら正面から評価に耐える体験を作り上げてもらいたい。 出典: この記事は Available today: Anthropic’s Claude Opus 5 in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 Appsの更新チャネルのうち「半期エンタープライズチャネル（SAEC）」と「月次エンタープライズチャネル（MEC）」を、2026年7月リリースのVersion 2606から統合すると発表した。これまでSAECで運用していた端末も、再インストールや設定変更をすることなく、自動的にMEC相当の更新を受け取るようになる。 何が変わるのか Version 2606以降、SAECに設定された端末はMECと同じ機能更新・セキュリティ更新を受け取る。更新が完了すると、「ファイル > アカウント」など管理画面の表示も「Monthly Enterprise Channel」に変わるが、ユーザーが日常使う操作フロー自体は変わらない。 注意点は初回更新のサイズだ。Version 2508からVersion 2606への更新は約1.6GBとなり、通常の月次更新より大きい。移行が完了すれば、以降は通常のMECの更新頻度・サイズに戻る見込みだ。 もう一つの実務上のポイントは、MEC移行によって「Microsoft 365 Copilot」の利用要件を満たすユーザーが増えることだ。CopilotはMECであることが前提条件の一つになっているため、これまでSAECだったために対象外だった端末が、今回の統合を機にCopilot利用対象になるケースが出てくる。 Cloud Updateと既存管理ツールへの影響 Microsoft 365 Apps admin centerの「Cloud Update」はこの変更に対応済みで、Version 2606適用後の端末を自動的にMECとして評価する。すでにCloud UpdateでMECを管理しているテナントでは、対象端末はそのまま管理対象になる。更新プロファイル、展開の段階分け、除外ウィンドウ、一時停止・ロールバック設定はそのまま引き継がれる。管理したくない端末は除外グループやプロファイル設定で対象外にできる。 Intune、Configuration Manager、グループポリシーなど従来の管理ツールを使う組織では、既存の更新ポリシーがそのまま尊重され、ポリシー移行や追加作業は基本的に不要だ。ただしCloud Updateが有効な環境では、その設定が他の管理ツールより優先される点は覚えておきたい。 猶予が必要な組織向けに、SAEC Version 2508自体は2026年9月8日までサポートが継続される。 実務への影響 SAECを選んでいた組織の多くは「半年に一度まとめて検証してから全社展開したい」という保守的な更新ポリシーを持っていたはずだ。今回の統合で、その運用は実質的に月次ペースに変わる。変更管理・検証プロセスを月次サイクルに合わせて見直す必要がある。 2026年9月8日までに、以下は済ませておきたい。 Cloud Updateの利用有無を確認し、除外すべき端末があれば除外グループを設定する Intune／Configuration Manager／グループポリシーの既存ポリシーが意図通り新チャネルに適用されるか確認する 初回更新（約1.6GB）が業務時間中の帯域を圧迫しないか、展開ウィンドウを見直す MEC移行でCopilot利用対象が増える可能性があるため、ライセンスとガバナンスを再確認する 筆者の見解 今回のチャネル統合は、Microsoftらしい「道のド真ん中」の判断だと感じる。SAECは半年単位でじっくり検証してから展開したい組織向けのチャネルだったが、実際には検証コストの高さから使われなくなっていた面が大きい。実態に合わせてMECに一本化するのは、管理の複雑さを減らすという意味で妥当な整理だ。 一方で、この統合でCopilotの利用対象が自動的に広がる点は少し気になる。Copilot自体は悪いツールではなく、Teamsの議事録やOutlookの定型作業を任せるだけでも十分価値がある。ただ、Copilotだけに閉じてしまうと物足りなさを感じる場面があるのも事実だ。MECへの移行でCopilotの選択肢が広がるこの機会に、IT管理者にはCopilotを唯一の解として全社導入するのではなく、高度な分析や創造的なタスクには他の選択肢も併用できる体制を検討してほしい。Microsoftには、その併用という選択肢を堂々と提示できるだけの実力があるはずだ。 出典: この記事は Microsoft 365 Apps Version 2606: Semi-Annual and Monthly Enterprise Channels unify の内容をもとに、筆者の見解を加えて独自に執筆したものです。

マイクロソフトは、SharePointのドキュメントライブラリのユーザーインターフェース（UI）を大幅に刷新する計画を進めている。新しい設計はOneDriveの操作感に近づける形で行われ、カスタムビューやフィルター機能が画面の前面に配置される。あわせてコマンドバーも整理され、これまで別々だった「新規」と「アップロード」のボタンが一つに統合される。パンくずリスト（現在地を示すナビゲーション表示）も改善対象に含まれる。 何がどう変わるのか 今回の刷新のポイントは大きく3つある。 1つ目は、コマンドバーの簡素化だ。「新規作成」と「アップロード」という似た用途の2つのボタンが1つに統合され、操作に迷う場面が減る。 2つ目は、カスタムビューとフィルターの位置づけの変化だ。これまでSharePointのビュー切り替えは奥まった場所にあることが多かったが、今回の刷新でOneDriveのように前面へ引き出され、使う頻度の高い機能へのアクセスが速くなる。 3つ目は、パンくずリストの改善だ。深い階層のフォルダー構造を持つSharePointサイトでは、今どこにいるのか見失いやすいという声が根強かった。ナビゲーションの視認性向上は、この課題への直接的な回答になる。 なお、承認ワークフローや詳細な権限管理といったSharePoint固有の機能は維持されたまま、見た目と基本操作だけがOneDriveに近づけられる設計になっている。 なぜOneDriveとの統一が必要だったのか SharePointのドキュメントライブラリとOneDriveは、裏側では同じSharePoint Onlineのストレージ基盤を使っている。にもかかわらず、UIも操作感も長らく別物のように扱われてきた。これは、Microsoft 365全体で見たときの「一貫性の欠如」の代表例だったと言える。 実務への影響 日本企業のIT管理者にとって、この刷新は「良いニュース」であると同時に「事前準備が必要なニュース」でもある。 まず、エンドユーザーからの問い合わせ増加に備えたい。UIが変わる直前にTeamsやメールで簡単な変更案内（スクリーンショット付き）を出しておくだけで、ヘルプデスクへの問い合わせは大きく減らせる。 次に、カスタムビューやフィルター設定をテナントで多用している組織は、展開前にテスト環境で表示崩れや設定の引き継ぎを確認しておくべきだ。特に業務システムと連携したビュー定義がある場合は、事前検証を省略しないほうがいい。 最後に、この機会にSharePointとOneDriveの使い分けルールを社内で再整理するのも有効だ。UIが揃うタイミングは、利用ガイドラインを見直す自然な区切りになる。 筆者の見解 SharePointとOneDriveの操作感の乖離は、長年MVPとして現場を見てきた身からすると「地味だが放置されてきた宿題」の一つだった。同じ基盤を使っているファイルストレージなのに、開く場所によって操作が変わるというのは、Microsoft 365を統合プラットフォームとして使う価値を自ら削いでいるようなものだ。 今回の刷新は派手な新機能ではない。しかし、こうした地道な体験統一の積み重ねこそが、部分最適の寄せ集めではなく全体最適なプラットフォームへ近づく道だと考えている。奇をてらわず、標準的な操作感を揃えることに正面から取り組む今回のアプローチは、王道であり支持したい。この調子で、他の細かな体験のズレも一つずつ潰していってほしい。 出典: この記事は SharePoint Document Libraries Set For a Major Redesign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年に投入するTeamsの新機能として、Loop連携の「会議ノート」の対応範囲を拡大する。これまで事前にスケジュールされた会議に限られていたこの機能が、「Meet now」による即席通話やチャットから発信する音声・ビデオ通話でも使えるようになる。あわせて、テナントごとに独自ブランドを設定できる会議リアクションも導入される。米Windows Reportが報じた。 Loopの会議ノートとは何か Teamsの会議ノートは、生成AIのCopilotとは別物で、Microsoft 365の共同編集基盤「Loop」のコンポーネントとして提供されている機能だ。会議のアジェンダ、ノート、アクションアイテムを参加者全員がリアルタイムで同時編集でき、会議前の準備から会議後のフォローアップまで一つのキャンバス上で完結する。すでにOutlookで予定された会議では利用できていたが、今回の拡張でカバー範囲が広がる。 何が変わるのか 主な変更点は次の3つだ。 対応範囲の拡大: 「Meet now」の即席通話や、チャットから直接開始する通話でもLoopの会議ノートが使えるようになる タスクの自動同期: 会議中に挙がったアクションアイテムが、Planner・To Doのタスクとして自動的に登録される ブランド付きリアクション: テナント管理者が社内イベントや全社会議向けに、独自デザインの会議リアクションを設定できるようになる 実務への影響 日本の職場では「ちょっといいですか」の一言で始まる即席の相談や、チャットからのクイックコールが日常的に発生する。これまではこうした非公式な打ち合わせの内容は記録に残らず、後から「言った言わない」になりがちだった。今回の拡張は、まさにこの空白を埋めるものだ。予定会議だけでなく即席の通話でもノートとアクションアイテムが自動的に残るようになれば、記録の非対称性が解消される。 IT管理者にとっては、Planner・To Doとの自動同期によってタスク管理の一元化が一歩進む点が実務上のメリットになる。会議で決まったことがそのままタスクの導線に流れ込む仕組みは、別途議事録から手動でタスクを起票する手間を省いてくれる。一方でブランド付きリアクションは、テナント管理者が設定できる項目がまた一つ増えることを意味する。全社イベントや表彰の場面での活用余地は大きいが、ガバナンスと運用ルールの整備もあわせて検討しておきたい。 筆者の見解 派手さのない機能拡張だが、Microsoft 365が本来持っている「統合されているからこそ価値が出る」という設計思想をよく体現していると感じる。LoopとTeams、Planner・To Doが会議の前後をシームレスに繋ぐ導線は、特別な設定や外部ツールなしに標準機能だけで再現性のある業務フローが手に入るという意味で、王道を行く改善だ。 AI機能で目立つことよりも、こうした地道な統合強化を積み重ねる姿勢こそがMicrosoft 365の強みであり、応援したいポイントだと思う。ブランド付きリアクションのような遊び要素も、単体では小粒に見えて、社内のエンゲージメントづくりには地味に効いてくる部分だろう。今後も基盤機能の使い勝手を落とさずに、こうした着実な拡張を続けてほしい。 出典: この記事は Microsoft Teams Will Add Loop Meeting Notes and Branded Reactions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

マイクロソフトは2026年6月、InfoComm 2026にあわせてMicrosoft Teamsの通話機能をアップデートし、部署やチーム宛の着信にAIが自動応答する「Teams Phone Agent」を発表した。あわせて、コールキューでの通話を自動録音・文字起こしし、SharePointに保存する機能が7月中旬から順次利用可能になるほか、会議中に発言者の映像を優先表示する新しいレイアウトも追加される。 Teams Phone Agentは何を自動化するのか Teams Phoneにはこれまでも、着信を担当者や部署へ振り分ける「自動応答（Auto Attendant）」や「コールキュー」といった機能があった。ただしその実体は番号選択が中心のIVR（音声応答システム）で、利用者が番号を押したり定型的な発話をしたりして初めて処理が進む仕組みだった。 今回のTeams Phone Agentは、この一次対応の窓口そのものにAIエージェントを立たせる発想に近い。着信内容を理解したうえで簡単な質問に答えたり、適切な担当者へつないだりする役割をAIが担う。ヘルプデスクや代表電話、店舗・拠点の問い合わせ窓口のように、定型的なやり取りが多いが人手を割きたい業務との相性がよい。 コールキューの録音・文字起こしがSharePoint保存に対応 もう一つの目玉が、コールキューでの通話を自動的に録音・文字起こしし、SharePointに保存する機能だ。7月中旬から段階的に提供される。これまで通話記録の保存・検索は個別設定や外部ツールに頼る場面も多かったが、Teams標準機能として文字起こしまで一貫して行われることで、応対品質のレビューやトラブル発生時の経緯確認がしやすくなる。 発表者映像を優先する新レイアウト 会議中のレイアウトにも変更が入り、発言中の参加者の映像を大きく優先表示するモードが追加された。画面共有中心の会議でも「誰が話しているか」が視覚的にわかりやすくなる。 実務への影響 日本企業の情シスやコンタクトセンター運用担当にとって、この発表は「Teams PhoneをPBX代替として本格運用する」判断材料が一つ増えたことを意味する。代表電話やコールセンターの一次対応をAIに任せられるなら、Teams Phone Systemの導入・拡張を検討する動機になるはずだ。 一方で注意したいのは、通話録音がSharePointに保存されるという点だ。個人情報や商談内容を含む録音がドキュメントライブラリに蓄積されることになるため、保持ラベル（保持ポリシー）、アクセス権限、外部共有設定を事前に設計しておく必要がある。「録音機能が使えるようになった」ことと「安全に運用できる状態にある」ことは別問題であり、導入前にコンプライアンス部門と権限設計を詰めておきたい。 筆者の見解 電話応答という反復性の高い定型業務にAIを充てるという方向性は、素直に正しい打ち手だと思う。人間が対応すべきは例外処理や高度な相談であり、一次対応をAIに任せて人手を空けるという設計思想は、これまでもMicrosoft 365全体で語られてきた「定型業務はAI、判断業務は人間」という流れに沿っている。 ただし、Copilotを含むMicrosoft製AI機能全般については、ここ数年、期待したほどの体験に届かない場面が少なくなかったのも正直なところだ。そこはもったいないと感じている。だからこそ、Teams Phone Agentのような「業務プロセスに埋め込まれた定型AI」は、Microsoftが本来強みを発揮できるはずの領域だと思っている。統合プラットフォームとしての厚みと企業導入実績があるMicrosoftには、正面から勝負できる力があるのだから、応答品質やエスカレーション設計を丁寧に磨き込み、コールセンター品質のAI対応として恥じない水準まで仕上げてほしい。 もう一点付け加えるなら、こうした音声AIエージェントは「Copilotだけに閉じない」設計を意識すべきだと考えている。定型応対はTeams Phone Agentに任せつつ、より複雑な問い合わせ分析やナレッジ整備には外部の生成AIを組み合わせる併用構成も選択肢に入れておくと、将来の要件変化にも柔軟に対応できるはずだ。 出典: この記事は What’s New in Microsoft Teams | June 2026 – InfoComm Edition の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか Microsoftは2026年7月、Microsoft 365 Copilotに存在した権限昇格の脆弱性「CVE-2026-41106」を公開した。深刻度はCVSS 9.3と緊急対応レベルの一歩手前まで達する高さで、原因はCopilotが処理するURLリダイレクトの検証不備にあった。悪用されると、未認証の第三者が本来到達できないはずのテナント境界を越え、他組織のCopilotが扱うデータにアクセスできてしまう可能性があった。 Microsoft 365 CopilotはSharePoint、Exchange、Teamsなど組織内のあらゆるデータを横断して要約・検索・生成を行うことが強みだが、裏を返せばそのアクセス範囲の広さがそのままリスクの大きさになる。今回の脆弱性はCopilot自体のクラウド側処理に存在していたため、Microsoftはサーバー側で修正を完了させ、利用者側での追加対応は不要としている。 テナント境界を越えるとはどういうことか M365は、テナントという単位で顧客企業ごとにデータを完全に分離するマルチテナント設計が前提になっている。今回のCVEは、この「壁」をURLリダイレクトの不備を突くことで越えられてしまう構造だった。認証すら不要だったという点が深刻度を押し上げている。パッチはクラウド側で完結しているため実害の有無は公表情報からは分からないが、CVSS 9.3という数字は、Microsoft自身がこの脆弱性を相当に重く見ていたことを示している。 実務への影響 利用者側の追加パッチ作業は不要だが、IT管理者がやるべきことがゼロになったわけではない。 Copilotの権限棚卸し: Copilotがアクセスできるデータ範囲（SharePointサイト、メールボックス、Teamsチャネルなど）を、業務上必要な最小限に絞れているか再確認する 監査ログの確認: Purview監査ログやEntra IDのサインインログで、該当期間に不審なアクセスパターンがなかったかを遡って確認する コネクタの棚卸し: Copilot Studioで作成した独自エージェントやコネクタが、同様のURLリダイレクト依存の設計になっていないか点検する クラウドサービス側の脆弱性は「気づいたときには直っている」ことが多いが、それに安心しきってCopilotの権限設計を放置するのは危険だ。 筆者の見解 Copilotは実質的に、人間の代わりに組織内の広範なデータへ自動的にアクセスする「Non-Human Identity（NHI）」だ。今回の脆弱性が突いたのは、まさにこのNHIが常時どこまでアクセスできる状態になっているかという設計そのものだった。長年ゼロトラストを推進してきた立場から見ると、AIエージェントに対しても「常時アクセス権」ではなく、必要なときだけ必要な範囲にアクセスするJust-In-Timeの発想を徹底すべき局面に来ている。 Microsoftがクラウド側で迅速にパッチを適用し、利用者に追加対応を求めなかった点は率直に評価したい。ただし、Copilotが業務の中心に食い込めば食い込むほど、この種の脆弱性のインパクトは大きくなる。せっかくM365という強力な統合プラットフォームを持っているのだから、Copilotの権限管理やNHIガバナンスの領域でも他社の一歩先を行く姿勢を見せてほしい。応援しているからこそ、ここは正面から取り組んでもらいたいテーマだ。 出典: この記事は CVE-2026-41106 - Microsoft 365 Copilot Elevation of Privilege Vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Microsoft 365 Copilotに複数の新機能を追加したと発表した。カメラ越しに画面や実物を見せながら質問できる「Vision」機能、Copilot Pagesでの提案編集機能、AI生成の音声・動画に対する電子透かしポリシー、そしてAgent Builderで作成したエージェントを管理者承認フローを経てAgent Storeに公開できる仕組みが新たに加わった。 Vision機能 ― カメラ越しに「見せて聞く」 Visionは、スマートフォンやPCのカメラ、あるいは画面共有を通じて「今見ているもの」をCopilotに見せながら質問できる機能だ。ホワイトボードの図、機器のパネル、紙の資料など、テキスト化されていない情報についてもその場でCopilotに解説や次の一手を尋ねられる。これはGPT-4VやGeminiのライブ機能で先行してきたマルチモーダル対話の流れをM365 Copilotにも本格的に取り込んだものと言える。 Copilot Pagesに提案編集機能 Copilot Pagesは、これまでCopilotが文章を直接書き換える形が中心だったが、今回の更新でWordの「変更履歴」やGoogle Docsの「提案モード」に近い、人間がAccept/Rejectを選べる提案編集が可能になった。AIが生成した変更点を人間が必ず確認してから確定させる、というワンクッションが入る点は地味だが実務上は重要な改善だ。 AI生成コンテンツへの電子透かしポリシー Copilotが生成した音声・動画に対して、AI生成であることを示す電子透かしを付与するポリシーも導入された。C2PA(Content Credentials)のような業界標準の流れに沿ったもので、ディープフェイクやAI生成コンテンツの真正性が問題視される中、企業がAI生成物と人間が作成したものを区別・監査できる仕組みを標準機能として持たせる意義は大きい。 Agent BuilderからAgent Storeへ ― 管理者承認フローの追加 Agent Builderで作成した独自エージェントを、社内のAgent Store(エージェントストア)に公開する際に、管理者の承認を経るワークフローが新設された。これまでは個人やチーム単位でエージェントを作成・利用できても、全社公開の手前でIT管理者がレビューする標準的な仕組みが弱かった。今回の更新でエージェントのライフサイクル管理に「審査ゲート」が組み込まれたことになる。 実務への影響 日本の現場への影響は主に2つある。まずVisionと提案編集は、サービスデスクや現場作業の記録・報告といった「テキスト化しにくい業務」でのCopilot活用の幅を広げる。カメラ越しの質問はヘルプデスクの一次対応や、紙の伝票・現物確認が残る業務プロセスとの相性が良い。 もう一つ、より重要なのがAgent Storeの承認フローだ。日本企業の多くは「誰が何のエージェントを作り、誰が公開を許可したか」を追跡する仕組みをまだ持っていない。野良エージェントが社内に増えていく状況は、野良の特権アカウントが増えていくのと本質的に同じリスクを抱える。今回の承認フローは、エージェントというNon-Human Identity(非人間ID)のガバナンスを標準機能として提供する第一歩であり、IT管理者は「使わせない」ではなく「承認して安全に使わせる」運用を設計する好機だ。 筆者の見解 エージェントの数が増えるほど、それを人間がいちいちチェックする体制はいずれ破綻する。今回Agent Storeに管理者承認フローが入ったのは、エージェントというNon-Human Identityのライフサイクルを組織としてどう管理するかという、本質的な課題にMicrosoftがようやく手を付けた形で、方向性としては正しい。ゼロトラストの文脈で言えば、常時全公開ではなく審査ゲートを挟む設計は理にかなっている。 Visionや提案編集のような機能追加自体も着実な改善で、Copilotの実務適用範囲は確実に広がっている。ただ、せっかくここまでの実力があるのだから、Copilotだけに閉じた使い方を前提にするのではなく、Teamsの議事録やOutlookの定型業務のような日常タスクはCopilotに任せつつ、より踏み込んだ分析や創造的なタスクではAzure AI Foundry経由で別の選択肢も併用できる、という設計を組織側で用意しておくのが現実的だ。Microsoft 365は統合してこそ価値が出るプラットフォームであり、Copilotがその中心で正面から勝負できる存在であり続けてほしいというのが率直な期待だ。 出典: この記事は What’s New in Microsoft 365 Copilot | June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、OpenAIの最新モデル「GPT-5.6」をMicrosoft 365 Copilotの既定モデルとして展開を開始したと発表した。対象はWord、Excel、PowerPoint、Copilot Chat、そして複数アプリをまたいで自律的に作業を進める新機能「Copilot Cowork」。ユーザー側で特別な設定をしなくても、これらのアプリで動くCopilotのバックエンドが自動的にGPT-5.6へ切り替わる。 GPT-5.6で何が変わるのか 今回のアップデートの核心は、単発の質問応答ではなく「複数ステップにまたがるエージェント的な作業」への対応力強化にある。たとえばExcelで大量データの整形・分析を数段階に分けて実行させたり、PowerPointで骨子から仕上げまで複数回のやり取りを重ねて資料を作らせたりする場面で、Copilotが途中の文脈を見失わずに一貫したタスク遂行ができるようになったとされる。生成AIの価値がチャットボットから「エージェント」へと軸足を移している大きな流れの延長線上にある更新だ。 Sol・Terra・Lunaという3系統 GPT-5.6はSol・Terra・Lunaという3つの系統で構成され、それぞれ推論力とコストのバランスが異なる。重い推論が必要な処理には高精度な系統を、定型的な処理には軽量・低コストな系統をあてるといった使い分けが可能になっている。1つのモデルに一括りにせず用途別に最適化するという発想自体は、クラウドのVMサイズ選定などでもおなじみの考え方で、目新しさよりも「実務で使える現実解」を志向した設計だと感じる。 実務への影響 日本企業のIT管理者にとって重要なのは、このモデル切り替えがテナント側の追加設定なしに行われる点だ。裏側のモデルが変わることで出力の傾向や挙動が微妙に変わる可能性があるため、業務で重要なCopilot連携（Excelマクロ生成、PowerPoint自動作成など）を行っている部署には、更新後の出力を軽くチェックしてもらうよう周知しておくとよい。 エンジニア視点では、「Copilot Cowork」のような複数ステップ・複数アプリ横断のエージェント機能をどこまで信頼して任せられるかを見極める好機でもある。まずは議事録要約や定型レポート作成など、失敗しても実害の小さい業務から任せて、挙動のクセをつかんでから徐々に対象を広げるのが安全な進め方だ。 筆者の見解 Microsoft 365は本来、Word・Excel・Teams・Outlookが連携してこそ価値が出る統合プラットフォームだ。その中核であるCopilotが、自社開発に固執せずOpenAIの最新モデルを素早く取り込んで既定モデルに据えたのは、応援する立場から見て前向きな動きだと思う。ここ数年のCopilotの進化ペースには正直物足りなさを感じてきたが、今回のような基盤刷新のスピード感が続くなら、実務での信頼回復につながる可能性は十分にある。 ただし、Copilot経由で使う限りはMicrosoftのUIやガバナンスポリシーの制約を受ける。高度な分析や創造的なタスクでは、Azure AI Foundry経由で同系統のモデルに直接アクセスできる選択肢もあわせて用意し、Copilotと使い分けられる体制を整えておくのが現実的だ。Teamsの議事録やOutlookの定型返信はCopilotに任せ、腰を据えた分析はFoundry経由の環境で、という役割分担を組んでおけば、今回のモデル刷新の恩恵を最大限に引き出せるはずだ。 出典: この記事は Available today: OpenAI’s GPT-5.6 in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月13日、Entra ID(旧Azure AD)の多要素認証(MFA)において、SMSワンタイムコードと音声通話による認証方式を2027年2月1日をもって提供終了すると発表した。管理者向けメッセージセンター通知(MC1426371)で明らかにしたもので、Microsoft自身がホストするSMS・音声認証サービスが姿を消し、以降はパスキーが既定の認証方式となる。 何が終了し、何が変わるのか 現在Entra IDでは、MFAチャレンジの選択肢としてMicrosoftが無償でSMSワンタイムコードや音声通話の確認コードを送信している。この仕組みが2027年2月1日で終了する。それでもSMS・音声認証を続けたいテナントは、2026年9月18日から提供されるMicrosoft Security Store経由でテレコムプロバイダーのサービスを別途購入する必要がある。「無料でついてくる」認証方式ではなくなるわけだ。Microsoft Authenticatorアプリやパスキーは対象外で、引き続き無償で使える。 なぜ電話認証を切り捨てるのか SMS・音声によるMFAは、共有シークレットと公衆電話網に依存する認証方式で、SIMスワッピング(攻撃者が携帯キャリアを騙して被害者の番号を自分のSIMに移す手口)やメッセージ傍受、番号の再割り当て、ソーシャルエンジニアリングによる突破が以前から知られていた。パスキーは公開鍵暗号方式のため、こうした攻撃への耐性が格段に高い。 Microsoftは2024年時点でMFA応答の44%がSMS・音声経由であり、SMSはAuthenticatorアプリより突破される確率が40%高いというデータを示している。管理者向けMFA必須化以来、段階的に電話認証からの移行を促してきたMicrosoftだが、今回はいよいよ「終了日」を明示した格好だ。 移行スケジュールとテナントの準備 2026年9月からEntra IDはSMS・音声利用者に対して自動的にパスキーを有効化し、登録キャンペーンを「Microsoft managed」に設定してパスキー作成を促す。ユーザーは一時的にスキップできるが、最終的には登録が必要になる。2027年2月1日以降、準備が整っていないユーザーはMFAチャレンジに応答できずサインインできなくなる可能性があり、ヘルプデスクへの問い合わせ増加は避けられないだろう。対象ユーザーの洗い出しには、Microsoftが提供する「passwords and authentication methods report」PowerShellスクリプトが使える。 実務への影響 日本企業のEntra ID管理者にとって、これは対岸の火事ではない。現場作業員や非デスクワーカー向けにSMS認証を採用している企業、取引先・協力会社アカウントでSMSを既定にしている企業、古い条件付きアクセスポリシーのままMFA方式を限定していないテナントは要注意だ。まずは前述のPowerShellレポートで対象アカウントを棚卸しし、パスキー対応デバイス(Windows Hello、iOS/AndroidのFIDO2対応、セキュリティキー等)の可用性を確認したい。17か月の猶予は十分に見えるが、非デスクワーカーへのデバイス展開や取引先への周知には想像以上に時間がかかる。年内に移行計画を立てて動き出すのが賢明だ。 筆者の見解 今回の発表は、素直に評価できる判断だと思う。SMSや音声通話は仕組み上どうしても攻撃の余地が残る認証方式で、SIMスワップ被害のニュースは以前から後を絶たない。ゼロトラストの観点でも認証層の強度を底上げする今回の動きは筋が通っている。 好感が持てるのは、いきなり「禁止」にするのではなく、自動でパスキーを有効化しつつ登録キャンペーンで気づかせ、猶予期間を設けて段階的に移行させる設計になっている点だ。ユーザーが一番使いやすいと感じる方式が結果的に一番安全な方式になる——これがセキュリティ施策の理想形で、Microsoftはこの手の「使ってもらう工夫」に関しては昔から強い。応援したくなる部分だ。 一方で、日本の大企業の現場を見ていると、SMS認証に頼っているアカウントが今でも相当数残っているのが実情だ。昔ながらのセキュリティ運用と中途半端なゼロトラスト導入が混在したテナントでは、今回のような「土台からの変更」に対応しきれず、2027年2月に駆け込みで慌てる組織が出てくるのは目に見えている。今のうちから対象アカウントを洗い出し、パスキー移行を粛々と進めておくことをお勧めしたい。正面から準備すれば怖くない変更のはずだ。 出典: この記事は Microsoft to Stop Providing Telephony-Based Authentication Methods for MFA in February 2027 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米Microsoftは2026年7月13日、Office 2019および一部の古いバージョンのOffice 2021・Microsoft 365アプリについて、Mac版とiOS版を「機能制限モード」へ移行させた。対象デバイスではファイルの閲覧・印刷は引き続きできるが、編集・保存・新規作成は一切できなくなる。Windows版・Android版は今回の対象外だ。 何が起きているのか 対象はWord、Excel、PowerPoint、Outlook、OneNoteといった主要アプリ。Microsoftのサポートページによれば、ライセンス認証に使っている証明書が期限切れを迎えることが理由とされている。証明書が失効するとアプリ側でライセンスの正当性を確認できなくなり、安全側に倒して編集機能を止める、という理屈だ。 ただし証明書は本来更新できるものでもある。Microsoft 365サブスクリプションおよびOffice 2021のユーザーは、アプリをバージョン16.83以降に更新すれば影響を回避できる。macOS 11以前を使っている場合は、先にmacOS Monterey（12）以降へアップデートする必要がある。 問題は買い切り版のOffice 2019だ。こちらにはMicrosoftから救済アップデートが提供されない。つまり「一度購入したソフトウェアの機能が、ベンダー側の判断で止まる」形になる。Microsoftは2023年10月にOffice 2019 for Macのサポートを終了した際、「Office 2019アプリは引き続き機能する」と案内していた経緯があり、今回の措置はその説明とかみ合っていない。 対象かどうかの確認方法 Wordを開き「Word」>「Wordについて」からバージョン番号とライセンス種別を確認する。バージョンが16.83以上であれば当面は問題ない。16.82以下でライセンス種別が「Retail License 2019」の場合、Microsoft 365への切り替え、Office 2024の購入、あるいはPagesやGoogle Docsなど代替アプリへの移行が現実的な選択肢になる。 実務への影響 日本のIT現場でまず点検すべきは「個人所有Mac・iPadでの業務利用」だ。BYOD環境や、経費精算の隙間で私物Macに古いOfficeを入れっぱなしにしているケースは珍しくない。情報システム部門が把握していない「野良Office 2019」は、7月13日を境に編集不能になり、現場からの問い合わせが集中する可能性がある。 対応の勘所は3つ。第一に、社内のMacデバイス台帳とOfficeライセンス種別を突き合わせ、Retail License 2019の残存を洗い出すこと。第二に、Microsoft 365サブスクリプションへの統合を優先すること。買い切り版は今回のように予告なく機能が止まるリスクを内包しており、サブスクリプション型に寄せておいた方が長期的な運用コストは低い。第三に、Windows/Android端末は今回影響を受けないため、対応範囲をMac/iOSに絞ってよい。 筆者の見解 証明書の期限切れという技術的な理由づけ自体は理解できる。だが、買い切りライセンスで購入したソフトウェアの編集機能を、ユーザー側に非のない形で止めてしまうやり方には正直、賛成しがたい。2023年には「引き続き機能する」と案内していたのだから、なおさらだ。 筆者はMicrosoft製品を長年使い、応援する立場のMVPとして書いているからこそ言いたいのだが、これは「やらなくていいこと」だと思う。買い切り版というライセンス形態を選んだユーザーは、そこに「一度払えば安心して使い続けられる」という価値を見出していたはずだ。その前提を後から崩すやり方は、サブスクリプションへの移行を促す近道に見えても、長期的にはブランドへの信頼を削ってしまう。Microsoftほどの技術力と顧客基盤があるのだから、正面から「Microsoft 365の方がこれだけお得です」と価値で選んでもらう戦略の方が、よほど筋が良いはずだ。 日本企業にとっての教訓はむしろ別のところにある。資産管理台帳とライセンス実態が一致していない組織は、今回のような「静かな仕様変更」のたびに現場が混乱する。サブスクリプション統合と資産の可視化を平時から進めておくことが、この手のニュースに振り回されない一番の予防策だ。 出典: この記事は Microsoft is disabling Office 2019 for Mac on July 13, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotの公式コミュニティブログで、Copilot Studioで構築したAIエージェントをMicrosoft Teams上に公開し、社内のユーザーと共有するための手順を解説する記事が取り上げられた。エージェントを作るところまでは多くの解説があるが、今回は実際に現場の従業員が使える状態にするまでの「公開」フェーズに焦点を当てている。 Copilot Studioエージェントを「作る」から「使わせる」へ Copilot Studioで作成したエージェントは、作っただけでは開発者本人の環境でしか動かない。Teamsチャネルとして有効化し、組織のTeams環境に配布して初めて、現場の従業員が実際にチャットから呼び出せるようになる。この配布プロセスにはいくつかの段階がある。 まずテストキャンバスでエージェントの応答が意図通りかを検証する。次に「チャネル」設定でMicrosoft Teamsを有効化し、エージェントをTeamsアプリとしてパッケージ化する。ここまでは基本的に開発者個人の作業だ。 その先の組織展開が今回の記事の本題になる。パッケージ化したエージェントは、個別ユーザーへの直接共有、特定チームへの限定公開、組織のアプリカタログへの登録という段階を踏んで配布できる。特にアプリカタログへの登録を選ぶ場合は、Teams管理センターでのテナント管理者による承認が必須になる。誰でも自由に全社公開できるわけではなく、管理者の統制を経由する設計になっている点が実務上のポイントだ。 実務への影響 日本企業のIT管理者にとって重要なのは、「管理者承認を経由した公開」という仕組みそのものだ。Copilot Studioのようなローコードツールは現場主導でエージェントがどんどん作られていく一方、野良エージェントが無秩序に全社展開されると、情報漏洩や誤動作のリスクが一気に高まる。Teams管理センターのカスタムアプリポリシーを使えば、公開範囲を「特定チームのみ」「承認制」などに制御でき、禁止一辺倒ではなく安全に使わせる仕組みとして機能する。 エージェント自体も一種の非人間アイデンティティ(NHI)であり、誰が・どの権限で・どこまで自動実行してよいかを最初から設計しておく必要がある。IT管理者は、まずTeams管理センターの「アプリの管理」でカスタムアプリの提出ポリシーと承認フローが有効になっているかを点検し、全社公開の前に特定チームでの限定公開期間を設ける段階的な運用を検討するとよい。 筆者の見解 CopilotやCopilot Studioは、この数年でMicrosoftが最も力を入れてきた領域であり、率直に言えばこれまでの体験には物足りなさを感じることも多かった。ただ、今回のように「エージェントの作成と公開を分離し、管理者の統制を挟む」という設計思想自体は正しい方向だと思う。 Teamsは既に多くの日本企業で日常業務のハブになっている。そこにエージェントを安全に流通させる仕組みが整うなら、Copilotひとつに閉じず、Teams上で複数のAIエージェントを併用していく未来にもつながっていく。ガバナンスの土台はできつつあるので、あとはエージェントそのものの実力をどこまで引き上げられるかが問われる。正面から勝負できる力があるはずのプラットフォームだからこそ、この仕組みを活かしきれる中身を伴わせてほしい。 出典: この記事は Publishing and Sharing Your Agent Across Microsoft Teams: A Complete Step-by-Step Guide の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365上でAIが生成・加工した動画および音声コンテンツに「透かし（ウォーターマーク）」を付与する新しいクラウドポリシーを発表した。対象となるのは、動画編集ツールClipchampで生成したAI動画や、Copilotが自動生成する音声概要（Audio Overview）などのコンテンツだ。ポリシーは既定で無効になっており、テナント管理者がMicrosoft 365管理センターから明示的に有効化する必要がある。 何が変わるのか 今回追加されたのは、AIによって生成・加工されたことを示す情報を、動画・音声ファイルに埋め込む仕組みだ。コンテンツの来歴（プロブナンス）を示すという発想自体は目新しいものではなく、業界全体で進むC2PA（Coalition for Content Provenance and Authenticity）のContent Credentialsのような取り組みと軌を一にする。Microsoftも以前からBing Image CreatorやDesignerが生成した画像にC2PAベースの来歴情報を付与しており、今回はその考え方を動画・音声というメディアにも広げた形になる。 管理はテナント単位のクラウドポリシーで行う。管理者がポリシーを有効化すると、対象アプリで生成・加工されたコンテンツに自動的に透かしが付与されるようになる。個々のユーザーが都度オン・オフを選ぶ機能ではなく、組織のガバナンス方針として一括適用する設計だ。 画像の透かしとは別管理 注意したいのは、画像コンテンツにはこのポリシーとは別に、ユーザーが個別に制御できる透かし機能が既に存在する点だ。今回のクラウドポリシーはあくまで動画・音声を対象としており、画像側の仕組みとは管理経路も適用範囲も異なる。両者を混同して「画像も含めて一括で制御できる」と誤解しないよう、社内周知の際は対象範囲を明確にしておく必要がある。 実務への影響 日本企業のIT管理者にとって、この機能は「AI生成コンテンツであることをどう開示するか」という、今後避けて通れない課題への一つの答えになる。生成AIで作った紹介動画や、Copilotが要約した音声資料が社外に出ていく機会は今後確実に増える。透かしという形で来歴を残しておけば、フェイクコンテンツ対策や、受け手への誠実な情報開示という観点で組織を守ることにつながる。特に金融・メディア・広報部門など、対外的な説明責任が重い部署では、開示ルールが法制度で求められる前に自主的に整備しておく価値は大きい。 実務的には、まず自社でClipchampやCopilotの音声概要機能をどの部署がどの程度使っているかを棚卸しし、有効化した場合の影響範囲を確認するところから始めたい。既定が無効のため今すぐ何かが変わるわけではないが、コンプライアンス要件がある組織ほど早めに評価しておく価値がある。 筆者の見解 生成AIコンテンツの透明性確保は、今後あらゆるプラットフォームが避けて通れないテーマだ。MicrosoftがMicrosoft 365という統合プラットフォームの中に、動画・音声の透かしをテナント単位のポリシーとして組み込んだこと自体は、地に足のついた前進だと感じる。派手な新機能ではないが、こうした地道なガバナンス機能の積み重ねこそが、企業がAIを本格的に業務へ組み込んでいくための土台になる。 一方で、今回の仕組みはあくまで「管理者が有効化して初めて動く」オプトイン方式であり、既定オフという設計にはやや物足りなさも残る。Copilotの音声概要のような機能は今後さらに使われる場面が増えていくはずで、AI生成物であることの開示は本来もっと当たり前の標準機能になっていてよいはずだ。透明性確保の仕組みをせっかく作ったのだから、デフォルトで有効にしても違和感がないくらいの立ち位置に、Microsoftには早めに踏み込んでほしい。AIガバナンスの領域で正面から勝負できるだけの力は十分にあるはずなので、そこは素直に期待している。 出典: この記事は Bringing transparency to AI-generated content with watermarks in Microsoft 365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teams meetingsに、外部AIボットを自動検知してロビー（待機室）に留め置く新しい保護機能が追加される。Microsoftが2026年7月9日(米国時間)に公式ブログで発表したもので、Otter.aiやFireflies、Read.aiといった外部の会議録音・文字起こしボットが会議に参加しようとした際、既定で待機室に足止めし、ホストが明示的に許可するまで参加させない仕組みになる。管理者は「外部ボット管理」ポリシーをユーザー単位・グループ単位で個別に割り当てられる。 何が起きるのか これまでTeams会議は、リンクさえ知っていれば外部の録音・文字起こしボットが会議室に「参加者」として入り込むことができた。会議主催者が気づかないまま、社外のAIサービスに会議内容が送信され、要約・保存されるケースも珍しくない。今回の機能は、こうした外部ボットを自動的に識別し、既定で「ロビー」に足止めする。人間の参加者と同様に、ホストが個別に入室を許可しない限り会議には参加できない。 管理者向けにはTeams管理センターに新しい「外部ボット管理」ポリシーが追加される。既存の会議ポリシーと同様、テナント全体・特定グループ・特定ユーザー単位で挙動を変更できるため、たとえば営業部門には特定の議事録ボットの利用を許可しつつ、それ以外の部門では原則ブロックする、といった柔軟な運用が可能になる。 展開スケジュール 2026年7月にロールアウトが始まり、8月に一般提供(GA)、9月にはポリシー未設定のテナントにも既定で適用される。つまり管理者が何もしなければ、9月以降は自動的に外部ボットがロビー待機の対象になる。 実務への影響 日本企業でも、AI議事録ツールは会議の生産性を大きく高める一方、統制のかからない形で普及していることが多い。会議参加者の一人が個人契約のAIボットを招待し、社外秘の会議内容が海外のクラウドサービスに送信されているケースは、情報漏えいのリスクとして見過ごせない。今回の機能は、こうした「野良ボット」の混入を防ぐ最初の一歩になる。 IT管理者は9月の既定適用を待たず、まず社内でどの議事録ボットが実際に使われているかを棚卸しすることをお勧めする。そのうえで、業務上必要なツールだけをグループ単位で許可リストに載せ、それ以外は原則ブロックする設計にすれば、利便性を損なわずに統制を効かせられる。会議主催者にも、ロビーに知らないボットが現れたときの対応方針(安易に許可しない)を周知しておく必要がある。 筆者の見解 この機能は、ゼロトラストの発想を会議室という身近な場所に持ち込んだ好例だと感じる。ボットやAIエージェントのような「人間ではない身分(Non-Human Identity)」に常時アクセス権を与えるのではなく、既定は拒否、必要なときだけ明示的に許可するというJust-In-Time的な設計は、筆者が普段から重要だと考えている考え方そのものだ。 なにより評価したいのは、「外部ボットを一律禁止」にしなかった点だ。禁止だけのアプローチは必ずどこかで抜け道が生まれ、結局はシャドーIT化する。今回のように、既定は安全側に倒しつつ、管理者が業務に必要なツールを個別に許可できる仕組みにしたことで、現場の利便性を落とさずに統制できる。Microsoftのセキュリティ機能は地味に映ることも多いが、こうした「安全に使える仕組み」を丁寧に積み上げていく姿勢は、もっと評価されてよいと思う。 出典: この記事は Introducing smarter bot protection in Microsoft Teams meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365 CopilotがPower BIのレポートやセマンティックモデルを直接参照し、そのデータに基づいた「根拠のある回答」を返せる機能を提供し始めた。レポートのリンクをチャットに貼り付けたり、レポート名を言及するだけでCopilotが該当データに接続できるほか、何も指定しなくてもCopilotが質問内容から適切なレポートを自動的に探し出して参照する。ポイントは、この機能がユーザー自身が本来持っているPower BIの権限の範囲内でしか動作しない設計になっていることだ。現時点ではFrontierプログラムのテナント向けにCopilot Premiumライセンスが必要とされている。 Work IQを基盤にした「根拠ある回答」の仕組み この機能は、Microsoftが進める「Work IQ」という基盤技術の上に成り立っている。Work IQは、ユーザーが日々やり取りするメール・Teams・SharePoint・Power BIなど組織内のデータをCopilotが横断的に理解し、文脈に応じて適切な情報源から回答を組み立てるための仕組みだ。今回のアップデートで、そのデータソースにPower BIのレポートとセマンティックモデルが加わったことになる。ユーザーが特定のレポートを共有していればそれを根拠にし、共有がなくても質問の内容からCopilotが自動的に該当レポートを見つけて参照する点が特徴だ。 ユーザー本来の権限モデルを変えない設計 注目すべきは、この機能がCopilot専用の特権的なアクセス経路を新設するものではなく、ユーザーが元々見られる範囲のPower BIデータしか回答に使わない設計になっている点だ。Copilotが裏側で万能のサービスアカウントを使ってテナント内のあらゆるレポートを読めてしまう、という仕組みではない。ユーザーの権限がそのまま回答の範囲を決める。 管理者側の設定は二段階 有効化は管理者側で2段階の作業になる。まずMicrosoft 365管理センターのCopilot設定から「Fabric data in Microsoft 365 Copilot」を開き、対象ユーザーを「なし」「全員」「特定のグループ」から選ぶ。次に、Fabric管理者がFabric管理ポータルのテナント設定で「Share Fabric data with your Microsoft 365 services」を有効にする必要がある。この設定を入れない限り、CopilotからFabric側のデータを検索・参照することはできない。なお、この設定を有効にすると、Copilot側のクエリデータがFabricに共有される点は明記されている。FabricはM365 Copilotとは別のコミットメントで運用されており、そこで処理されるデータはFabric Product Termsの適用を受ける。 実務への影響 日本のエンタープライズでPower BIを使い込んでいる企業は多いが、目的のレポートを探し出し、該当シートを開き、数値を拾って会議資料に転記するという作業は今も人手に依存しがちだ。この機能が定着すれば「このレポートのこの数字の背景を説明して」とCopilotに聞くだけで済むようになる可能性がある。ただし、いきなり「全員」で有効化するのではなく、まず「特定のグループ」で限定的に試し、意図しないレポートまで拾ってきていないか、権限設計に想定外の穴がないかを確認してから段階的に広げるのが安全だ。また、Fabric管理者とM365管理者は別部門・別担当者であることも多いため、この2段階設定を誰がいつ有効にするのかを事前にすり合わせておく必要がある。 筆者の見解 この数年、Copilot関連の新機能発表に以前ほど手放しでは反応できなくなっていたのが正直なところだ。期待した完成度に届かない発表が続いたのも事実である。ただ、セキュリティを専門領域のひとつとして見ている筆者から見ると、今回のPower BI連携は方向性としてかなり筋が良い。AIエージェントが業務データにアクセスする際、専用の特権サービスアカウントを新設してあらゆるデータへの常時アクセス権を持たせてしまう、というやり方が最も危ういパターンだ。今回の実装はそうではなく、あくまでユーザー本人の権限の範囲内でCopilotが動く。「禁止するのではなく、安全に使える形で便利さを提供する」という、AI活用のセキュリティ設計として本来あるべき姿に近い。Non-Human Identityの管理がこれからの業務効率化のボトルネックになっていく中で、こうした「権限を昇格させない」設計をきちんと作り込んでくることには素直に期待したい。Power BIというデータ資産とCopilotという対話インターフェースを両方持っているのだから、この強みを正面から活かしてほしい。あとは実際にどれだけ精度の高い回答を返せるかどうかにかかっている。そこが伴って初めて、今回の設計の良さが本当の意味で活きてくる。 出典: この記事は Use Power BI data in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Excel上のAIアシスタント「Copilot in Excel」に、業務手順を再利用できる「スキル」機能と、ワークブックごとのルールを定義する「Rulesシート」、さらに財務データコネクタを追加した。いずれもOneDrive上にファイルとして保存でき、毎回同じ指示をチャットに書き込まなくても、Copilotが定型業務を一貫した手順で実行できるようにする狙いだ。 SKILL.mdファイルによる「再利用可能スキル」とは何か 今回追加された目玉機能が、SKILL.mdというテキストファイルの形で保存できる「再利用可能スキル」だ。たとえば「月次売上レポートのフォーマットに整形する」「特定の集計ロジックでピボットを作る」といった一連の作業手順を一度SKILL.mdに書いておけば、以降はそのスキルを呼び出すだけでCopilotが同じ手順を再現してくれる。OneDriveに置いておけばチーム内で共有もできるため、属人化しがちだったExcel作業の「暗黙知」を明文化・資産化できる点が大きい。 手順やルールをMarkdown形式のファイルとして定義し、AIエージェントに読み込ませるという設計自体は、近年のAIエージェント界隈で広がりつつある考え方で、Microsoftもこの流れに追随した形だ。 Rulesシートで書式・命名規則・数式の「お作法」を固定化 もう一つの新機能「Rulesシート」は、ワークブック単位で書式ルール・セルの命名規則・数式の書き方の慣習をあらかじめ定義しておける仕組みだ。「金額セルは常に3桁区切りでカンマ表示」「シート名はプロジェクトコード_年月の形式」といった社内ルールをRulesシートに書いておけば、Copilotがそのワークブックを編集する際に自動的にルールを守るようになる。これまでのように毎回チャットで細かい書式指定をし直す手間が減る。 加えて、財務データを直接取り込める新しいデータコネクタも追加された。会計・財務系のデータソースとExcelの間の橋渡しをCopilotが担うことで、レポート作成のためのデータ収集・整形作業そのものを短縮できる。 実務への影響 日本企業のバックオフィス、特に経理・財務部門にとっては地味だが効きそうな機能強化だ。月次・四半期決算のレポート作成は「同じフォーマットに同じ手順で整える」という反復作業の塊であり、SKILL.mdとRulesシートはまさにこの反復を仕組み化するための道具になる。IT管理者の視点では、誰がどんなスキルをOneDriveに公開しているのか、部門をまたいで共有していいスキルなのかというガバナンス設計が新たな検討課題になるだろう。野良のSKILL.mdが乱立すると、かえって「どのルールが正なのか」が分からなくなる恐れもあるため、テンプレートの管理者を決めて配布する運用ルールを早めに整備しておきたい。 筆者の見解 Copilotについては、これまで機能の割に実務での「効く感」が乏しいという印象を持ってきたが、今回の追加は方向性として素直に評価したい。ルールや手順をファイルとして明文化し、AIに毎回同じ指示を繰り返させない設計は、「禁止ではなく安全に使える仕組みを作る」という考え方そのものだ。属人化した業務ノウハウを個人の頭の中に閉じ込めるのではなく、SKILL.mdやRulesシートという形でチームの資産にできるなら、それはCopilotが「その場しのぎのチャットボット」から「業務基盤の一部」へと一歩進んだことを意味する。 一方で、こうした仕組みは作って終わりではなく、実際に現場で使われて初めて価値が出る。Microsoft 365は本来、統合して使うことで真価を発揮するプラットフォームであり、今回のような地道な機能強化を着実に積み重ねてこそ、Copilotが名実ともに現場の主力ツールになっていく。正面から勝負できるだけの土台は十分にあるはずなので、この路線を粘り強く伸ばしていってほしいというのが率直なところだ。 出典: この記事は Microsoft adds reusable skills and finance data connectors to Copilot in Excel の内容をもとに、筆者の見解を加えて独自に執筆したものです。