M365

Microsoftは、Microsoft PlacesおよびMicrosoft Teamsにおいて、社内Wi-Fiネットワークへの接続を利用してオフィスへの出社を自動検知する「Wi-Fiチェックイン」機能を発表した。従業員が手動でワークプレイスロケーションを更新しなくても、ノートPCが社内ネットワークに接続した瞬間にTeamsが検知し、勤務場所を自動更新する。 「今日、誰がオフィスにいるか」を自動で可視化 ハイブリッドワークが定着した現在、チームメンバーの物理的な居場所を把握するのは意外と手間だ。Outlookのカレンダーを見ても「在宅か出社か」までは分からないことが多く、Teamsのプレゼンスは「オンライン中」かどうかは示しても「今日どこから働いているか」は示さない。 Microsoft Placesのワークプレイスプレゼンスはこのギャップを埋める機能だ。そして今回の「Wi-Fiチェックイン」は、その情報を手動入力なしで常に最新状態に保つ仕組みである。 技術的な仕組みはシンプルだ。各オフィスのWi-FiアクセスポイントのBSSID（基地局識別子）をMicrosoft Placesのディレクトリに登録しておくと、従業員のノートPCがそのネットワークに接続したタイミングでTeamsクライアントがそれを検知し、その日の勤務場所を「オフィス」に自動更新する。既存の「周辺機器チェックイン」（ディスプレイやドックへの接続で検知）と同じコンセプトをWi-Fiに拡張したものと考えると理解しやすい。 プライバシーへの配慮：3層の同意モデル こうした「位置検知」機能には、常に監視懸念がつきまとう。Microsoftはその点を意識してか、3層の同意モデルを設計している。 第1層：組織レベルの有効化 テナント管理者が機能そのものを有効にするかどうかを決める。有効にしない限り、従業員のデバイスでは機能しない。 第2層：設定方式の選択 組織がオプトイン（従業員が明示的に有効化）かオプトアウト（デフォルト有効だが個人が無効化可）かを選択できる。 第3層：個人レベルの制御 最終的には個人がいつでも設定を変更でき、手動でロケーションを上書きすることも可能。デバイスの位置情報設定がオフであれば、組織が有効にしていても機能しない。 また、過去の行動履歴は保存されない。「現時点でどこにいるか」だけを示す現在進行形のシグナルであり、「いつ何時間オフィスにいたか」のような追跡には利用されない点は明記されている。 実務への影響 IT管理者の準備事項 今年後半のロールアウトに備えて、以下の準備が求められる。 Microsoft Placesのセットアップ確認: Placesディレクトリにビルディング情報が登録されているかを確認する BSSIDの収集と登録: 対象オフィスのWi-FiアクセスポイントすべてのBSSIDを収集し、Placesディレクトリに登録する Teamsの作業場所検出ポリシーの有効化: 管理センターで該当ポリシーを設定する 従業員への周知: 機能の概要・できないこと（履歴は保存されないなど）・個人での制御方法を事前に説明する BSSIDの収集は、フロアごとに多数のアクセスポイントが存在する大規模オフィスでは一定の手間がかかる。ネットワーク担当部門と連携して、AP一覧のエクスポート方法を事前に確認しておくとスムーズだ。また、オフィスの移転・増設・Wi-Fiリプレイス時には「Placesのディレクトリも更新が必要」という新たな運用タスクが発生することを、ネットワーク管理のライフサイクルに組み込んでおく必要がある。 エンジニア・ビジネスユーザーへの恩恵 Teamsやカレンダーから「今日誰がオフィスにいるか」がリアルタイムで確認できる 「せっかく出社したのに全員リモートだった」という状況を事前に回避できる フリーアドレスのデスク予約と連携し、チームメンバーの近くに席を取りやすくなる 筆者の見解 Microsoft Placesは、ハイブリッドワーク時代の「コラボレーション基盤」として地道に機能を積み上げている印象だ。カレンダーの空き状況・Teamsのアクティビティプレゼンス・ワークプレイスプレゼンスを組み合わせた多層的な可視化は、M365を統合プラットフォームとして活用することの具体的な価値を示している。バラバラに導入していては得られないメリットだ。 プライバシー設計については、オプトイン/オプトアウトを組織が選択できる構造は実際的だと思う。日本企業の文化的な背景を考えると、「オプトイン」から始めて従業員の理解を得ながら段階的に展開するアプローチが現実的だろう。 一方で、BSSIDベースの設定管理は運用負荷の観点でやや気になる。Wi-Fiインフラの更新サイクルとPlaces管理のサイクルを意識的に連携させなければ、気づかないうちにチェックインが機能しなくなるケースが出てくるかもしれない。Microsoftには、ネットワーク管理ツールとの統合や自動同期の仕組みを将来的に検討してほしいところだ。 とはいえ、M365エコシステムをフル活用できている組織にとっては、すぐに「あって当然」の機能になるポテンシャルがある。まだMicrosoft Placesを導入していない組織にとっては、今回の機能を評価のきっかけにしてみる価値は十分あるだろう。 出典: この記事は Workplace presence, made effortless: Workplace check-in via Wi-Fi for Microsoft Places and Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月11日、Power Platformの大型月次アップデートを公開し、AIエージェントの「クローズドループ学習」機能をはじめ、コネクタガバナンスの強化、インベントリAPI、RPAデバッガーのバージョン比較対応など、エンタープライズ向けの機能が一挙に追加された。 今回のアップデートの主要機能 クローズドループエージェント学習 今回の目玉機能が「クローズドループエージェント学習（Closed-loop Agent Learning）」だ。AIエージェントが実行した処理の結果をフィードバックとして取り込み、次回以降の意思決定に反映させる仕組みである。 従来のPower Automateフローは「設計者が明示的に定義したロジックを実行する」だけだったが、クローズドループ学習を組み込んだエージェントは実行結果を自分で評価して改善していく。受注データの分類精度を自ら向上させたり、異常検知のしきい値をビジネスの実態に合わせて動的に調整したりするユースケースが想定される。 コネクタガバナンスとインベントリAPI Power Platformではサードパーティ製「コネクタ」を通じて数百のサービスと連携できるが、企業IT管理者の長年の悩みは「どのコネクタが使われているか把握できない」「未承認のコネクタがセキュリティリスクになる」という点だった。 今回追加されたコネクタガバナンス機能とインベントリAPIにより、テナント内で使用中のコネクタを一覧化し、承認・禁止のポリシーをAPIレベルで制御できるようになった。さらにCMDB（構成管理データベース）との連携により、コネクタの使用状況を既存の資産管理ツールに統合できる。ServiceNowやその他のITSMツールと組み合わせれば、Power Platform全体のガバナンスを一元管理する基盤になりえる。 RPAデバッガーのバージョン比較対応 Desktop Flow（デスクトップ自動化）のデバッガーが強化され、フローの異なるバージョン間での差分をビジュアルに比較できるようになった。更新後に挙動が変わった際の原因特定が大幅に効率化される。 実務では「誰かが修正したフローで別の担当者のワークフローが動かなくなった」というトラブルが頻繁に発生する。バージョン比較機能はそうした現場課題を直接解決する実践的な強化だ。 実務への影響 IT管理者へ: コネクタガバナンスのAPIとCMDB連携は、ゼロトラスト戦略の観点でも重要だ。使用中のコネクタが把握できていない状態は、認可されていない接続経路が存在するリスクと同義である。今回の機能を活用して、まず「現状の棚卸し」から着手することを強く推奨する。 開発者・市民開発者へ: クローズドループ学習を活用するには、エージェントに「何を正解とするか」を明確に定義するフィードバックループの設計が不可欠だ。「なんとなくAIに任せる」ではなく、ビジネスロジックの評価軸を先に定義してからエージェントを構築する順番が重要になる。 全社展開を検討している企業へ: インベントリAPIはPower Platformガバナンスの「見える化」に直結する。CISOや情報システム部門が全社展開に慎重なケースの多くは「何が動いているかわからない」という不安からきている。このAPIがその心理的障壁を下げる可能性がある。 筆者の見解 Power Platformのアップデートサイクルは一貫して速く、今月も企業が実際に困っているポイントを正面から突いた機能が揃った印象だ。特にコネクタガバナンスとCMDB連携は「自動化を広げたいが統制が怖い」というIT部門の典型的なジレンマに対する、現実的な回答になりえる。 クローズドループ学習については、「エージェントが自ら学習する」という言葉のインパクトに対して、実際の運用設計は丁寧に行う必要がある。学習の方向性を定義するのは結局人間であり、フィードバックループの品質がエージェントの品質を決める。「AIに任せたら勝手に良くなる」という期待値のズレは、現場でしっかり管理しなければならない。 もったいないと感じるのは、これだけ実用的な機能が揃っているにもかかわらず、日本の大企業では「Power Platform＝市民開発のおもちゃ」という認識がまだ残っているケースがあることだ。エンタープライズグレードのガバナンス機能が整ってきた今、その認識をアップデートする絶好のタイミングに来ている。Microsoftはこの領域できちんとした実力を持っているのだから、現場がその実力を正当に評価できる環境を作っていくことが重要だ。 出典: この記事は What’s New in Power Platform: June 2026 Feature Update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月5日（9日更新）、メッセージセンター通知MC1381110を通じて、ライセンスが割り当てられていないOneDrive for Businessアカウントのデータを、未払い状態が365日を超えた時点で削除すると発表した。保持ポリシーやeDiscovery保留が存在していても削除対象となるという点が、これまでの運用との決定的な違いだ。 何が変わるのか——従来との決定的な違い これまでのMicrosoft 365では、退職・異動でライセンスを剥奪されたOneDrive for Businessアカウントは、Microsoft 365アーカイブに移行したうえで、保持ポリシーや訴訟ホールド（eDiscovery保留）が存在する限り削除されずに残り続けた。 今回の変更はその前提を覆すものだ。2026年7月以降、未ライセンス状態が365日を経過したOneDrive for Businessアカウントのデータは、保持ポリシー・保持ラベル・eDiscovery保留・プリザベーションロックの有無にかかわらず削除される可能性がある。 Microsoftの公式ドキュメントには「12カ月の未払いアーカイブ後、OneDriveデータは保持設定・保持ポリシー・eDiscovery・すべての保留にかかわらず削除される可能性がある（might be deleted）」と記載されている。「might be deleted（削除される可能性がある）」という表現にとどまっているが、実際には「will be deleted（削除される）」に近い運用を想定すべきだろう。 スケジュールと対象テナント 有効開始: 2026年7月上旬（テナントごとに段階展開） 対象外: 教育機関・政府機関テナント 猶予期間: ライセンス削除後365日間 展開はテナントによって段階的に行われるため、正確な削除日はテナントごとに異なる。ただし、2025年6月以前にライセンスを剥奪されたアカウントは、7月のロールアウト後すぐに削除対象となる可能性があることを念頭に置いておきたい。 影響範囲を確認する方法 SharePoint管理センターには「ライセンスのないOneDrive for Businessアカウントレポート」が提供されており、未ライセンスアカウントの一覧と、そのアカウントがアーカイブに残っている理由（保持ポリシー、訴訟ホールド等）を確認できる。 「retention policy, active lock（保持ポリシー、アクティブロック）」と表示されているアカウントも、今後は保護対象外となる点に注意が必要だ。 管理者が取るべき対応は大きく3つだ： SharePoint管理センターで未ライセンスアカウントを棚卸し — レポートで全件確認し、未ライセンス化からの経過日数を把握する 保全が必要なデータの特定 — コンプライアンス担当・法務部門と連携して、どのアカウントのデータを継続保存すべきか判断する Azureサブスクリプション経由での保存継続か削除受け入れかを判断 — 本当に保全が必要なアカウントはMicrosoft 365アーカイブの課金を開始し、それ以外は削除を受け入れる方針を明確化する 実務への影響——日本のIT管理者が今すぐやること コンプライアンスや情報ガバナンスを重視する組織にとって、今回の変更は見過ごせない。特に以下のシナリオに該当する場合は即座の対応が必要だ： 訴訟・調査中のケースでeDiscovery保留をかけているアカウントがある 退職者のOneDriveデータに未処理の保持ポリシーがかかっている 定期的なライセンス棚卸しを実施していない、または担当者が曖昧な状態になっている Microsoft 365ではライセンス管理と情報ガバナンスが別々の担当者・チームに分かれていることが多い。今後はライセンス担当とコンプライアンス担当が連携して、アカウントのライフサイクル管理を一体で回す体制が不可欠になる。 特に重要なのは、「保持ポリシーがかかっているから大丈夫」という思い込みを今すぐ捨てることだ。2026年7月以降は、ライセンスの有無が保持ポリシーより上位の条件として機能する。これは従来の情報ガバナンス設計の根幹に関わる変更であり、既存の運用ドキュメントやポリシーの見直しも必要になる。 筆者の見解 15年にわたるOffice 365の歴史の中で、未ライセンスアカウントが大量に蓄積されてきたことは事実であり、今回の方針変更はMicrosoftにとっても管理者にとっても、合理的な整理の機会といえる。放置されたままのデータは、ストレージコストとセキュリティリスクの両面で組織にじわじわと負担をかける。「必要なデータは払って保存する、不要なものは削除する」というシンプルな原則への回帰自体は、正しい方向性だ。 一方で、保持ポリシーやeDiscovery保留を「強制的に無効化して削除する」という判断は、コンプライアンス管理者にとって相当なインパクトがある。これまで「保持ポリシーをかけておけば安全」という前提で運用設計をしてきた組織は少なくないはずだ。その前提を実質1カ月足らずの猶予で変えるのは、真面目にガバナンスを構築してきた組織ほど困る、という皮肉な構造になりかねない。 M365は統合プラットフォームとして正しく活用されているほど、ライセンス管理・保持ポリシー・eDiscoveryが複雑に絡み合う。このようなガバナンスの根幹に関わる変更には、本来であればもう少し長い移行期間と、組織の法務・コンプライアンス担当者が腰を据えて対応できる準備期間を設けてほしかった。こうした点については、Microsoftにはより丁寧なコミュニケーションを期待したい。 今回の変更を、ライセンス管理・保持ポリシー・eDiscoveryの三者を統合的に見直す機会として活用してほしい。M365は「バラバラに使うと意味がない」プラットフォームだ。アカウントのライフサイクル管理を起点に、情報ガバナンス全体の設計を一度点検する絶好のタイミングである。 出典: この記事は Microsoft to Delete Unlicensed OneDrive for Business Accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が 2026年6月4日、Microsoft 365 Copilot のリモートコード実行（RCE）脆弱性 CVE-2026-45497（CVSS 7.7）と、Exchange Online の情報漏洩脆弱性 CVE-2026-48579（CVSS 9.1）を開示した。両脆弱性とも開示時点ですでにサービス側での修正が完了しており、ユーザー側でのパッチ適用は不要だ。 今回開示された脆弱性の内容 今回公開されたのは「June 2026 Early Security Updates」と呼ばれる、月例 Patch Tuesday に先行するクラウドサービス向けの早期セキュリティ更新パッケージだ。9件の CVE が含まれ、うち以下の2件が金融機関にとって特に注目すべき内容だった。 CVE-2026-45497（CVSS 7.7 / 重要） Microsoft 365 Copilot のリモートコード実行脆弱性。根本原因はコマンドインジェクションで、公開されたベクターには「S:C（スコープ変更）」フラグが含まれている。これは、攻撃に成功した場合に Copilot サービスの境界を越えて Microsoft 365 の他のコンポーネントへ影響が及びうることを意味する。単体サービスの誤動作にとどまらない、より広範な影響を持つ欠陥だった。 CVE-2026-48579（CVSS 9.1 / 緊急） Microsoft Exchange Online の情報漏洩脆弱性。CVSS 9.1 という高いスコアが示すように、悪用された場合の影響は深刻だ。メールや添付文書など機密性の高い情報が対象となりうる。 両脆弱性とも、Microsoft 側のサービス修正はすでに完了しており、テナント管理者や IT 部門が個別に適用するパッチは存在しない。 「パッチ不要」はゴールではなく出発点 クラウドサービスの脆弱性対応は、オンプレミスのそれとは構造が根本的に異なる。Microsoft はクラウドサービスを自社で運営しているため、CVE を公開する前に修正をサービス側に適用し、後から透明性のために CVE として記録する。これが「Early Security Updates」という名称の意味するところだ。 比較として、2026年5月の Patch Tuesday では Netlogon や DNS の修正を実際のサーバーに手動で適用する必要があった。今回はその逆で「修正はすでに終わっている。CVE はその記録だ」という性質のものだ。 しかし銀行・信用金庫・住宅ローン会社など規制対象の金融機関にとって、「パッチ不要」は会話の終わりではなく始まりに過ぎない。 金融機関が直視すべき3つの問い 1. どの業務でCopilotが使われているか把握できているか Copilot はすでに融資担当者・引受担当者・コンプライアンスチームの日常業務に入り込んでいる。メール要約、社内メモ作成、ローン書類の整理といった業務がその代表例だ。この「業務の中心にいるアシスタント」に RCE 脆弱性が存在していたという事実は、規制当局への説明責任の観点からも看過できない。 ...

MicrosoftがMicrosoft TeamsとOutlookに対し、会議UIの刷新・大規模イベント対応強化・モバイルの日程調整改善など複数のアップデートを近日中に順次展開することを明らかにした。 Teams会議ツールバーが刷新——ボタンの固定・並べ替えが自由に 今回のアップデートの目玉のひとつが、Teams会議中に表示されるツールバーの再設計だ。現状はボタン配置が固定されており、「よく使う機能にすぐ手が届かない」と感じるユーザーが多かった。新しいデザインでは、ボタンを任意に固定・並べ替えできるようになる。 一見地味に見えるが、会議中の操作ストレスを減らす効果は体感で大きい。「画面共有」「チャット」「挙手」など自分のワークスタイルに合わせて最前面に配置し直すだけで、会議中に「あのボタンどこだっけ」と画面をさまよう時間がなくなる。 Efficiency Mode——非力なデバイスでも快適な会議を 注目すべき新機能が「Efficiency Mode」だ。企業内には古いPCや性能の低いデバイスが一定数存在する。Teams会議でCPUやメモリが圧迫されると会議中に他の作業ができなくなるケースが多く、「Teamsが重い」はIT管理者にとって定番の苦情だった。 Efficiency Modeはリソース制約デバイス向けにTeamsの処理負荷を意図的に抑える機能で、映像品質を若干落とす代わりに他のアプリへのCPU割り当てを確保する。ハードウェア更新の予算が取りにくい組織では、展開するだけで現場の不満が一定数解消される可能性がある。 最大1,000人のブレークアウトルームが解禁 グループワークや研修での活用が広がっているブレークアウトルーム機能について、参加者上限が最大1,000人規模まで大幅に引き上げられる予定だ。 大企業の全社研修、ハイブリッド型の大規模カンファレンス、パートナーイベントなど、これまでZoomやWebExを使わざるを得なかったシナリオが、Teamsだけで完結できるようになる。外部ツールの管理コスト・ライセンスコスト・セキュリティポリシー統一の観点から、Teamsへの一本化を進めたい組織には大きな後押しだ。 Outlookモバイルの日程調整が大幅強化 Outlookモバイルにも実務直結の改善が加わる。 Decline & Propose New Time対応：PCのOutlookでは以前から「辞退して別の時間を提案」ができたが、モバイルでは未対応だった。外出先で会議招待を受けることが増えた現代のビジネス環境では、これが使えないモバイルからわざわざPCを開いて操作するという非効率が生まれていた。待望の機能がようやく揃う。 スキップ時のフォロー通知：会議をスキップした際にフォローアップを促す通知が届くようになる。急なスケジュール変更で欠席した会議をそのまま忘れてしまう——よくある失敗を防ぐ仕組みだ。 日本のIT現場への実務的影響 今回のアップデート群で、日本の現場が特に恩恵を受けそうなシナリオを整理すると以下のようになる。 大規模ハイブリッド研修の主幹ツール化: 1,000人ブレークアウトルーム対応により、全社研修や大型イベントをTeams1本で運用できる可能性が高まる PCスペック問題の一時的な緩和: Efficiency Modeを活用することでハードウェア更新コストを先送りにできるケースが増える モバイルファーストな日程管理: OutlookモバイルのDecline & Propose対応で、PCを開かずにスケジュール調整が完結する Teamsを核にM365を統合運用している組織ほど、今回のアップデートの恩恵は大きい。逆に「Teamsだけ使ってあとはバラバラ」という運用では、プラットフォーム全体の価値が半減する点は変わらない。 筆者の見解 正直に言えば、TeamsとOutlookまわりの「使い勝手の改善」はここ数年ずっと後追い感が否めなかった。競合がとっくに当たり前にしていた機能が、ようやくMicrosoft 365にも来た——という話が続いていたのは事実だ。 ただ今回のアップデートは、「ユーザーが実際に困っている場所に手を入れた」という印象がある。ツールバーのカスタマイズもEfficiency Modeも、現場から長年声が上がり続けていた要望だ。積み残してきた宿題をようやく片付けた感はあるが、それでも前進は前進だ。 TeamsはM365統合プラットフォームの核であり、会議体験の質は周辺機能の使われ方にも直結する。個別機能の比較ではなく、「日程調整→会議→タスク→ドキュメント共有」が一気通貫で動くというプラットフォームとしての総合体験を磨いていく方向性は正しい。Microsoftが持っているユーザーベースとインフラの規模を考えれば、この方向性を愚直に磨き続けることで、十分に勝負できる力があるはずだ。今後のアップデートでその蓄積が加速することを期待している。 出典: この記事は Microsoft Teams and Outlook are getting significant changes soon | Neowin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teams Rooms on Windowsに、国際会議や多言語イベント向けの新機能「Human Interpreter Listening Mode（通訳者リスニングモード）」が追加される。参加者それぞれが会議中に任意の通訳者チャンネルを選択して音声を受聴できる仕組みで、グローバル会議のアクセシビリティを大きく引き上げる施策だ。 何が変わるのか これまでの Teams 会議では、多言語対応は主にキャプションや字幕機能、あるいはサードパーティのハイブリッド通訳サービスに頼る形が一般的だった。今回の「Human Interpreter Listening Mode」は、生身の通訳者が担当する音声チャンネルをプラットフォームに直接統合する。 具体的には以下のような動作になる： 通訳者チャンネルの個別選択: 参加者は会議 UI から通訳者ごとのチャンネルを選び、オリジナル音声と切り替えて聴取できる Teams Rooms on Windows 対応: 会議室デバイス側での操作が可能で、大型スクリーンやスピーカーシステムと連携した多言語体験が実現する インクルーシブな会議設計: AIによる自動翻訳・機械通訳とは別に、人間通訳者の品質を活かしたチャンネルを正式サポートする位置付け 国際的なカンファレンスや株主総会、グローバル全社ミーティングなど、機械翻訳の精度では対応しきれない高精度通訳が求められるシーンを明確にターゲットにしている。 AI機械翻訳との棲み分け 近年、Copilotを含む各種AIサービスが「リアルタイム翻訳」機能を強化してきた。しかしビジネスの現場では、法律・金融・医療分野の用語や微妙なニュアンス、文化的な背景を含む発言を正確に伝えるためには、依然として人間通訳者の専門性が欠かせない。 Microsoftがこのタイミングで「Human Interpreter Listening Mode」をロードマップに載せてきた背景には、AIが得意な「大量・高速・低コスト」とは別の領域——高精度・高信頼が必須のシナリオ——をプラットフォームとしてカバーしていく意図が読み取れる。 実務への影響—日本のIT管理者・エンジニアが備えるべきこと この機能が実稼働する前に、以下の準備を進めておくとスムーズだ。 1. 対象シナリオの洗い出し 自社でグローバル会議・多言語イベントをどの頻度・規模で実施しているか棚卸しする。年数回の株主総会や全社 Town Hall が対象になるか、それとも日常的な国際会議が主戦場かで、導入優先度が変わる。 2. Teams Rooms on Windows 環境の確認 本機能は Teams Rooms on Windows が前提。macOS 版やモバイルクライアントでの対応範囲はアップデートを追う必要がある。既存の会議室デバイスが Windows ベースかどうか、ファームウェアのアップデートポリシーとともに確認しておく。 3. 通訳者のオンボーディング設計 生通訳者が Teams のチャンネルに参加する運用フロー（招待方法・権限設計・通訳者用デバイス要件）を事前に整備しておく。外部通訳ベンダーとの契約条件に Teams 対応が含まれているか確認することも忘れずに。 4. 参加者向けの事前周知 会議 UI に新しい選択肢が追加されるため、特にリテラシーが多様な参加者層（役員層・社外ゲスト等）への事前説明があると会議中の混乱を防げる。 ...

Anthropicが提供するAIコーディング支援ツール「Claude Code」のGitHub Actionに、プロンプトインジェクションによってCI/CDワークフローのシークレットへアクセスできる脆弱性が存在していた。MicrosoftのThreat Intelligence（脅威インテリジェンス）チームがこの経路を発見し、Anthropicへの責任ある開示（Responsible Disclosure）を経て修正が完了している。 何が起きたのか：プロンプトインジェクションとCI/CDの交差点 Claude Code GitHub Actionは、GitHub Actionsのワークフロー内でClaudeを直接呼び出し、コードレビュー・テスト生成・ドキュメント作成などを自動化するためのOSSコンポーネントだ。AIエージェントをCI/CDパイプラインに組み込む取り組みとして注目を集めており、多くのプロジェクトで採用が広がっていた。 Microsoftが発見した脆弱性は「プロンプトインジェクション」と呼ばれる攻撃手法を利用する。攻撃者が悪意のある指示をプルリクエストのコメント、コミットメッセージ、またはリポジトリ内のファイルに埋め込むと、それをClaude Codeが解釈・実行してしまう可能性があった。 具体的な攻撃チェーンは以下のような流れだ： 悪意のある入力の埋め込み：攻撃者がプルリクエスト等に、Claudeへの命令を模した文字列を含める AIによる指示の誤認識：Claude Code GitHub Actionがその内容を処理する際、埋め込まれた指示を正規の命令と誤認する シークレットへのアクセス：特定の条件が揃うと、ワークフロー内で利用可能なシークレット（APIキー、認証情報など）が漏洩するリスクがあった この攻撃が成立するには「特定の条件」が必要であり、すべての環境で無条件に発火するものではなかった。しかしオープンなリポジトリや、外部からプルリクエストを受け付けている環境では現実的な脅威となりうる。 Anthropicの対応：責任ある開示プロセスが機能 Microsoftは発見後、Anthropicに責任ある開示を行った。Anthropicはこれを受けて、Claude Code GitHub Actionに対する緩和策（ミティゲーション）を実施し、修正済みバージョンをリリースしている。 AIエージェントのセキュリティ問題に対する業界の対応速度はまだ成熟途上にある中で、今回のケースでは責任ある開示のプロセスが適切に機能した。MicrosoftとAnthropicの双方がセキュリティコミュニティの標準的なルールに従ったことは、業界全体にとって良い前例となる。 AIエージェント時代のCI/CDセキュリティ：何を対策すべきか このインシデントが示す本質的な課題は、「AIエージェントをパイプラインに組み込む際の権限設計」だ。CI/CDでAIを使う場合のベストプラクティスをまとめると以下になる。 最小権限の徹底 GitHub ActionsでClaude Code等のAIアクションを使用する際は、ワークフローに必要最小限の権限のみを付与する。GITHUB_TOKENのスコープを可能な限り絞り、シークレットへのアクセス権も必要なもののみに限定する。 出典: この記事は Securing CI/CD in an agentic world: Claude Code Github action case の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、エンタープライズ向けエージェントがMicrosoft 365のコンテキストやツール、Copilotの知性を安全に利用するための「Work IQ API」を、2026年6月16日（月）に一般提供（GA）開始すると発表した。エージェント開発者がM365データへの独自のRAGスタックやガバナンス基盤を自前で構築せずとも、テナント境界・監査・権限制御を備えた形でM365全体の情報にアクセスできる仕組みが整う。 Work IQ APIとは何か Work IQ APIは、Chat・Context・Tools・Workspacesの4つのAPIドメインで構成される、エージェント向けM365インテリジェンスレイヤーだ。 Chat API: M365 Copilotが持つ応答能力全体へのプログラムアクセスを提供する。エージェントからCopilotの回答生成能力を呼び出せる Context API: メール・カレンダー・Teams・ファイル・SharePoint・OneDriveといった職場データを、エージェントが消費しやすい最適化された形式で返却する Tools API: ファイル操作・メール送信・会議スケジュールなどのM365アクションをエージェントから実行できる Workspaces API: エージェントが中間状態を保存・参照するための作業領域を提供する これら4つのAPIを組み合わせることで、エージェントはM365テナントの情報を読み書きしながら、人間の代わりに業務フローを自律実行できるようになる。 GAで提供される主要機能 GA時点で利用可能になる機能として、Microsoftの開発者ブログは以下を明記している。 エージェント間通信（A2A） Agent-to-Agent（A2A）プロトコルのサポートにより、Work IQ APIを呼び出すエージェント同士が委譲・連携できる。複数のスペシャリストエージェントをオーケストレーターが束ねるマルチエージェント構成で活用しやすい。 リモートMCPサーバー（再設計版） Model Context Protocol（MCP）向けのリモートサーバーが刷新される。MCPはローカルとリモートの2形態があるが、GAではリモートMCPが整備され、ツールスタイルでWork IQ機能にアクセスできる。 REST API 標準的なREST APIアクセスにより、既存のアプリケーションやサードパーティエージェントからWork IQを呼び出せる。Microsoftはサードパーティエージェントからの呼び出しも正式にサポートすると明言している。 ライセンスとコスト構造 Work IQ APIの利用料金は、Copilot Creditsによる従量課金モデルを採用する。Work IQ API専用のSKU・サブスクリプション・ユーザーライセンスは存在せず、既存のCopilotクレジット枠から消費される形になる。 この構造が意味するのは、利用量をコントロールしやすい反面、エージェントが想定外のツール呼び出しを繰り返すとクレジット消費が膨らむという点だ。Microsoft自身も管理者向けのコストコントロール機能の整備を強調しており、事前に使用量を試算した上で予算キャップをかけることを推奨している。 セキュリティとガバナンス Work IQ APIがエンタープライズ環境に向けて特に強調するのがガバナンス面だ。 テナント境界の厳格な管理: 他テナントのデータへのアクセスは設計上できない パーミッション・トリミング: 委任ユーザーコンテキストに基づき、呼び出しエージェントが本来アクセスできない範囲のデータは返却されない 監査ログ: エージェントがどのAPIを何回呼び出したかが記録される 管理者によるコストコントロール: テナント管理者がCopilotクレジット消費に上限を設けられる エージェントがメール送信・会議作成・ファイル操作といった破壊的アクションを取れる以上、権限設計と監査体制の整備は必須だ。 実務への影響――日本のエンジニア・IT管理者へ エージェント構築者へ 自前でM365データ連携のRAGレイヤーを構築していた開発者は、Work IQ APIへの移行を検討する価値がある。特に以下のケースでは効果が高い： 社内エンタープライズアシスタントが「社員の予定・メール・ファイル」を横断して回答する必要がある Copilot Studioで構築したエージェントを、社外のPythonやNode.jsアプリから呼び出したい マルチエージェント構成で、専門化されたエージェント同士に業務を委譲させたい まず検証すべき3点 必要なプロトコルの確認: A2A（エージェント委譲）・REST（アプリ統合）・MCP（ツールアクセス）のどれが自分のユースケースに合うかを先に絞る 認証・権限の事前テスト: Microsoft Learnには委任ユーザーコンテキストへの言及があるが、実テナントでの挙動確認が不可欠。本番前に検証環境で試す Copilotクレジット消費の試算: 「ツール呼び出し1回あたりのクレジット消費×想定呼び出し数」を算出し、月間コストの上限を管理者と合意してから開発を進める 6月16日以降に確認すること 現時点でMicrosoft Learnにはプレビュー時点の記述が残っているため、GA後のドキュメントで最終的なエンドポイントと制約事項を必ず再確認する必要がある。プレビューと仕様が変わっているケースは珍しくない。 ...

Microsoftのセキュリティ部門が、12ヶ月にわたるエージェントAIシステムへのレッドチーミングを通じて新たに7つの失敗モードを特定し、実環境での攻撃急増を受けてリスク分類体系を大幅に更新した。 エージェントAIへの攻撃が「実害」のステージへ これまでエージェントAIのセキュリティリスクは「将来の懸念」として扱われることが多かったが、状況は変わった。Microsoftのレッドチームによれば、実環境においてエージェントAIを標的にした攻撃が急増しており、もはや理論的なシナリオではない。 エージェントAIとは、目標を設定されると自律的にツールを呼び出し、複数のステップを踏んで課題を解決するシステムだ。Microsoft 365 CopilotやAzure AI Foundryで構築されるカスタムエージェントがその代表例で、メール処理・ドキュメント生成・コード実行・外部API呼び出しなど広範な操作を自律的にこなす。その「自律性」こそが新たな攻撃面を生んでいる。 新たに特定された7つの失敗モード 1. サプライチェーン侵害（Supply Chain Compromise） エージェントが参照する外部ツール・ライブラリ・モデルが改ざんされるリスク。人間のコードと同様に、AIが呼び出すコンポーネントも検証が必要になった。 2. ゴールハイジャック（Goal Hijacking） エージェントが処理中のデータや環境内の悪意ある入力によって、本来の目標から逸脱した行動を取らされる攻撃。プロンプトインジェクションの進化形と捉えるとわかりやすい。 3. 記憶の汚染（Memory Poisoning） エージェントが参照する長期記憶やベクターデータベースに偽情報を埋め込み、将来の判断を歪める手法。RAG（Retrieval-Augmented Generation）を活用するシステムで特に危険。 4. クロスエージェント攻撃（Cross-Agent Attacks） マルチエージェント構成において、あるエージェントを経由して別のエージェントを操作する攻撃。エージェント間の信頼モデルを悪用する。 5. 権限の過剰付与（Excessive Agency） エージェントに必要以上の権限が与えられることで、誤動作や攻撃時の被害が拡大する。最小権限原則の適用がここでも必須になる。 6. ツールの誤用誘発（Tool Misuse Induction） エージェントが持つツール（メール送信・ファイル操作・APIコールなど）を悪意ある入力によって不正に実行させる攻撃。 7. 観測回避（Observability Evasion） エージェントの動作ログや監査証跡を意図的に回避・改ざんし、攻撃の痕跡を消す手法。 Microsoftが示す実践的な緩和策 レッドチームの知見をもとに、Microsoftはいくつかの具体的な対策を提示している： 入力検証の厳格化：エージェントが処理するすべての外部入力（ユーザー入力・ツール出力・外部API応答）を信頼しない設計 最小権限の徹底：エージェントへの権限付与はタスクに必要な最小限に留め、Just-In-Time（JIT）アクセスを活用する エージェント間の信頼境界の明示：マルチエージェント環境では、エージェント同士が無制限に信頼し合わない設計にする 可観測性の確保：すべてのエージェント動作を詳細にロギングし、異常行動を検知できる仕組みを入れる サプライチェーン検証：エージェントが呼び出すツール・モデル・ライブラリの整合性を定期的に確認する 日本のエンジニア・IT管理者への影響 このレポートが示すリスクは、「エージェントAIを本番導入しているなら今すぐ対応が必要」というレベルの話だ。 日本企業でも、M365 Copilotのカスタムエージェントや、Azure AI Foundryを使った業務自動化の導入事例が急速に増えている。特に注意すべきは以下の点だ： Non-Human Identities（NHI）の管理が急務：エージェントAIはサービスプリンシパルやマネージドIDとして動作する。これらの権限管理が甘いと、エージェントが侵害された際の被害が組織全体に及ぶ。Entra IDでのJITアクセス設定と定期的な権限棚卸しを実施すること。 社内RAGシステムの汚染対策：SharePointや社内ドキュメントをベースにしたRAG構成を持つ場合、そのナレッジベースへの不正書き込みが記憶汚染攻撃の起点になりうる。ドキュメントの書き込み権限と読み取り権限を分離し、変更監査ログを有効にする。 マルチエージェント設計時の信頼境界定義：複数エージェントを連携させるフローでは、各エージェントが受け取る入力の信頼レベルを設計段階で明示する。「上位エージェントからの指示だから信頼する」という設計は危険だ。 筆者の見解 このレポートは、Microsoftのセキュリティ組織が1年間の実戦的なレッドチーミングから得た知見をまとめたもので、内容の質は高い。エージェントAIのリスクを「ベンダーがよく言う将来の脅威」ではなく「今起きている問題」として体系化した点は、現場にとって価値がある。 私がここで強調したいのは、このリスクはCopilotだけの話ではないということだ。Azure AI FoundryでカスタムエージェントをPythonで実装していても、LangChainや他のフレームワークを使っていても、エージェントが外部ツールを呼び出す構造を持っている時点で同じリスクを抱えている。 とりわけ気になるのはNHIの権限管理だ。「エージェントを動かすためにグローバル管理者権限のサービスプリンシパルを使う」という実装を、今もゼロにはなっていないと思う。エージェントAIの登場で、Non-Human Identitiesの数は今後さらに爆発的に増える。ここを甘く見ていると、エージェントが侵害された際の被害範囲がそのまま組織全体になる。 Microsoftにはこのような知見を、ドキュメントだけでなく製品側の「デフォルト設定」に反映してほしい。最小権限でエージェントを動かすのが「難しい選択肢」ではなく「一番簡単な選択肢」になるような設計を、Foundryやその周辺ツールで実現できるはずだ。力があるからこそ、そこまで踏み込んでほしいと思う。 出典: この記事は Updating the taxonomy of failure modes in agentic AI systems: What a year of red teaming taught us の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月20日、PowerShell開発者に対してモジュールの取得元をMicrosoft Artifact Registry（MAR）へ移行するよう求めるブログ記事を公開した。長年にわたってコミュニティの中心地であったPowerShell Galleryのセキュリティリスクを直視し、Microsoft公式モジュールの配布を自社管理の信頼済みリポジトリに一本化する方針を明示したものだ。 Microsoft Artifact Registry（MAR）とは何か MARは、Dockerイメージなどのコンテナアーティファクトに加え、PowerShellモジュールを含む各種ソフトウェアパッケージをMicrosoftが一元管理する公式レジストリだ。その最大の特徴は「Microsoft管理の公開パイプライン」という点にある。つまり、誰でも公開・更新できるPowerShell Galleryとは異なり、MARに登録されているMicrosoftモジュールは出所が明確で、改ざんや悪意ある模倣モジュールのリスクを排除できる。 Microsoftが示す主な優位性は以下の3点だ： 強固なプロビナンス（出所保証）と所有者保証：誰が何を公開したか追跡可能 PowerShell Galleryと比べて高い可用性：SLA観点での安定供給 コミュニティミラーへの依存排除：ファーストパーティモジュールをコミュニティ経由で取得する必要がなくなる 新しいモジュール管理ツール「PSResourceGet」 合わせてMicrosoftが推奨するのがPSResourceGet（旧PowerShellGet v3）の採用だ。このツールは「パッケージの探索（discovery）」と「インストール（consumption）」を明確に分離して設計されており、複数リポジトリを管理しながら本番環境ではMAR等の信頼済みソースからのみインストールする、という運用が可能になる。 MARをPSResourceGetに登録する基本コマンドは次のとおりだ： 出典: この記事は Microsoft Wants PowerShell Developers to Change How They Download Microsoft Modules の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Build 2026（6月2日）で発表した「Scout」は、Microsoft 365に常時稼働するAIエージェントとして、ユーザーの指示を待たずにメール整理・会議要約・スケジュール調整を自動実行する新しいワークエージェントだ。しかし、その基盤となる「OpenClaw」フレームワークのガバナンス課題が、当初の2026年3月リリース計画を遅延させていたことが内部文書で明らかになった。 Scout とは何か Scout は従来の Copilot とは根本的に異なる設計思想を持つ。Copilot がユーザーの質問・指示に応答する「リアクティブ型」であるのに対し、Scout は「プロアクティブ型」だ。ユーザーが会議中でも、バックグラウンドでプロジェクト提案書を下書きし、レビュー送付まで完了する——Build のデモで披露されたのはそういうシナリオだ。 Scout は Microsoft Graph 全体（メール・チャット・ファイル・カレンダー等）にアクセスし、ユーザーの業務パターンを学習する。この「常時稼働＋自律行動」という組み合わせが、従来の AI アシスタントとの最大の差異点だ。 OpenClaw：エージェントを動かすフレームワーク Scout のエンジンが OpenClaw だ。2025年末に初公開されたこのフレームワークは、エージェントが「ステートフル」に動作できる点が革新的だ。従来のチャットボットが1回の会話で状態をリセットするのに対し、OpenClaw エージェントは数時間〜数日にわたって文脈を保持し続ける。 Microsoft Graph への接続管理、認証トークンの制御、コンプライアンス境界の強制、すべてのアクションの監査ログ生成——これらを OpenClaw が担う。金融・医療・法務など規制業界での利用を想定した設計だ。 ガバナンスと権限管理の課題 問題は権限モデルだ。内部文書によると、OpenClaw の初期バージョンは細粒度の権限モデルが欠如しており、エージェントがユーザーの意図以上のデータにアクセスできる状態だったという。さらに、Scout の初期ビルドがコンテンツ要約時にユーザー設定の機密ラベルを上書きできる不具合も報告されている。 現在のガバナンス設計は3層構造だ： ユーザーレベル：個人の境界設定（例：外部メール送信は確認必須） チーム管理者レベル：部門ポリシーの定義 グローバル管理者レベル：テナント全体のルール強制 この階層型アプローチは適切な方向性だが、IT 管理者にとっては新たな管理負荷を意味する。 実務への影響 日本の IT 管理者・エンジニアが今すぐ考えるべきポイントは以下の3点だ。 1. 条件付きアクセスポリシーの見直し Scout は Microsoft Entra ID の条件付きアクセスと統合される。既存ポリシーが Scout のバックグラウンド動作を想定していない場合、予期しないブロックや逆に意図しない許可が発生するリスクがある。 2. 情報保護ラベルの整備 機密ラベルの上書き問題が修正されたとしても、そもそもラベル付けが不完全なテナントでは Scout の自動処理が誤った範囲で動作する。Microsoft Purview による情報分類の整備を今から進めるべきだ。 3. Non-Human Identity（NHI）管理 Scout はエージェントとして独立した ID を持つ。これは NHI 管理の文脈そのものだ。Scout に割り当てられた権限スコープ、アクセス履歴の監査、不要になった際の権限剥奪——これらのライフサイクル管理が新たに必要になる。NHI 管理の仕組みが整っていないテナントでは、Scout の導入自体がリスクになりかねない。 ...

Microsoftは2026年6月から、Microsoft 365 Copilotアプリを対象商用WindowsデバイスへWindows Update経由で自動インストールする施策を再開すると発表した。2025年初頭に管理者の反発を受けて一時中断された経緯があり、今回は新たな管理コントロールが追加されての「再挑戦」となる。 2025年の教訓—なぜ一度中断されたのか 2025年の最初の試みでは、IT管理者が「気づいたらタスクバーにCopilotが固定されていた」という事態が多発した。事前テストや承認プロセスなしに1万台規模のエンドポイントへ突然現れるAIアシスタントは、特にコンプライアンス要件の厳しい金融・医療・官公庁系の組織において深刻な問題となった。ソフトウェア管理ワークフローへの影響も小さくなく、Microsoftは数週間で展開を停止することを余儀なくされた。 今回のアナウンスでは「フィードバックを受けて詳細な制御機能を追加した」とMicrosoftが説明しており、その言葉通り管理コントロールは前回より整備されている。 インストール対象デバイスの3条件 自動インストールが実行されるのは、以下の3条件をすべて満たすデバイスに限られる。 OS: Windows 11、またはWindows 10 22H2（サポート対象バージョン） M365アプリのバージョン: Microsoft 365 Appsのバージョン2308以降がインストール済み 更新チャネル: Current ChannelまたはMonthly Enterprise Channel 逆に言えば、Semi-Annual Enterprise Channel（SAEC）やLTSCリリースのデバイスは対象外となる。日本の大企業では安定性を重視してSAECを採用しているケースが多いため、即座に影響を受けるのは現在のチャネルに沿った環境に限られる。 アプリ本体は約12MBと軽量だが、機能を実際に使用するにはMicrosoft 365 CopilotライセンスまたはCopilot for Microsoft 365アドオンが別途必要となる点も押さえておきたい。 IT管理者が使える制御手段 今回の展開で最も重要なのが管理コントロールの充実だ。主な手段を整理する。 Microsoft 365管理センター 管理センターに新設されたポリシー 「AutoInstall M365 Copilot App」 がデフォルトで有効（Enabled）になっている。テナント全体でオフにするには、このポリシーを手動で無効化する必要がある。 グループポリシー / Intune CSP 従来の管理ツールでも制御可能だ。 グループポリシー: Administrative Templates > Microsoft 365 Copilot > 「Prevent automatic installation of the Microsoft 365 Copilot app」を有効化 Intune CSP: 同等の設定をCSP経由で展開可能 M365 Appsサービシングプロファイル: 管理センター内のサービシングプロファイルにオプトアウトチェックボックスが追加 Windows Update for Businessリングとの連動 インストールはWindows品質更新プログラムに同梱されて配信される。既存のWUfBリングによる更新延期が設定されていれば、Copilotアプリも同じ期間インストールが遅延する。ただし注意点がある。60日を超えて延期すると、後続の累積更新プログラムにアプリが同梱され、リング制御外でインストールされる可能性があるとMicrosoftは警告している。 ...

ユニファイドAPI企業のMergeが、Microsoft Agent StoreにAgent Handlerを公開した。Model Context Protocol（MCP）を活用し、M365 CopilotエージェントからSalesforce・Workday・SAPなどの外部業務システムへ、ガバナンスを維持したまま直接アクセスできる仕組みを提供する。 Merge Agent Handlerとは何か Mergeは人事・給与・会計・CRM・ATS（採用管理）など180以上の業務システムを一本のAPIで束ねる「ユニファイドAPI」プラットフォームを提供する企業だ。今回、そのプラットフォームをMicrosoft Agent StoreにAgent Handlerとして登録した。M365 Copilotのエージェントは、MCPツールとして定義されたMergeのAPIを呼び出すことで、外部の業務システムにアクセスできるようになる。 MCPがM365エコシステムに入ってきた意味 MCP（Model Context Protocol）はAnthropicが提唱したオープンプロトコルで、AIがツールやデータソースを呼び出す際の標準仕様だ。Microsoftはこのプロトコルを採用し、M365 CopilotのAgent Frameworkに組み込んでいる。 Microsoft Agent StoreにMCPサーバーを登録すれば、Copilotエージェントから呼び出せる仕組みが整う。今回のMergeの登録はその最初の大型ケースのひとつと言え、他のSaaS企業がMCPベースのAgent Handlerを展開する際のリファレンスにもなりうる。 ガバナンスを保ちながらの外部連携 今回の仕組みの核心は「ガバナンスつき」という点にある。 認証の一元管理: Mergeが各外部システムへの認証を代理で管理し、M365のIT管理者が個別のAPIキーを直接持つ必要がなくなる アクセスログの可視化: どのエージェントがどのデータにアクセスしたかを記録する スコープ制限: 必要最小限の権限に絞ったAPIアクセスが可能 M365と外部システムの間に「信頼できるブローカー」を挟む構成は、ゼロトラストアーキテクチャの考え方とも親和性が高い。 連携可能な主な業務システム MergeのユニファイドAPIが対応する代表的なシステムは以下の通りだ。 人事・給与: Workday、BambooHR、SAP SuccessFactors CRM: Salesforce、HubSpot 会計: QuickBooks、Xero、NetSuite ATS（採用管理）: Greenhouse、Lever Teamsの会話画面やOutlookのメール作成中に、これらのシステムのデータをCopilotが参照・操作できるようになる。 実務への影響——日本のIT現場での活用ポイント 今すぐ検討できる活用例 M365 Copilot + Mergeを組み合わせた「Copilot for HR」「Copilot for Sales」のような用途特化エージェントの構築 TeamsやOutlookから自然言語でWorkdayやSalesforceのデータを照会するインターフェースの実装 IT管理者がAPIキーを直接管理しない安全な外部連携基盤の構築 日本市場特有の注意点 勘定奉行・SmartHRなど国産システムへの対応状況は別途確認が必要 Mergeは外部SaaSであるため、データの流れを設計段階でしっかり把握しておくこと 現時点では英語圏向けのリリースが先行しており、日本語UIや日本企業向けサポートの展開タイムラインは不明 筆者の見解 M365 Copilotが「外」に開きはじめた。この流れは率直に歓迎したい。 これまでCopilotが企業現場で使いにくかった理由のひとつは、M365エコシステムの内側で完結しようとする傾向にあった。SharePointのドキュメントやTeamsの履歴は参照できても、SalesforceやWorkdayとの連携になった途端に壁が立ちはだかる——多くの企業が感じてきたジレンマだ。 MCPという標準プロトコルを通じてMicrosoft Agent Storeがサードパーティに開かれていくのは、プラットフォームとして正しい方向性だと思う。MicrosoftはAzureや.NETの時代から「エコシステムを育てる」ことが得意な会社だ。AI分野でも同じ戦略が機能すれば、統合プラットフォームとしての強みが活きてくる。 ただし、外部連携の口が広がるほど「誰がどのデータにアクセスできるか」の管理は複雑になる。ガバナンス機能をMergeに丸投げするのではなく、Entra IDやMicrosoft Purviewと組み合わせてM365側でも可視化・制御できる構成を検討するのが賢明だ。正面から向き合うべきはそこだろう。 ...

Microsoft は2026年6月のBuildにおいて、Copilotとは一線を画す新しいAIエージェントカテゴリ「Autopilot」を発表した。第1弾として提供される「Scout」は、ユーザーが指示を出すたびに応答する従来型AIとは異なり、バックグラウンドで常時稼働し、業務を自律的に前進させることを目的として設計されている。 AutopilotとCopilotは何が違うのか これまでのCopilotは「ユーザーが指示を出すと動く」反応型AIだった。Autopilotはその一歩先を行くプロアクティブ型エージェントだ。Microsoftは公式発表の中で「prompted each time without needing」——つまり「都度指示しなくても動く」という特性を強調している。 Scoutの具体的な能力として発表されているのは以下の通りだ： 会議スケジューリングの自動調整：タイムゾーンを考慮しつつ日程を調整し、重要度の高い会議をユーザーにフラグ表示 事前準備資料の自動生成：会議前に必要と判断したドキュメントをあらかじめ用意 締め切り管理とカレンダーブロック：迫る期限を検出してフォーカス時間を自動確保 リスク検知：意思決定が止まっているタスクの「停滞」を検知して通知 統合先はTeams、Outlook、OneDrive、SharePoint。メール・カレンダー・チャット・連絡先を横断的に参照しながら動作する。 Entra IDとの連携——エージェントに「アイデンティティ」を持たせる意味 注目すべき点は、ScoutがEntra IDと統合された独自のアイデンティティを持つという設計だ。組織内でのScoutの行動は特定のユーザーのScoutエージェントに紐付けられ、監査ログにも記録される。 これはエンタープライズ観点では重要なアーキテクチャ上の決断だ。AIが「誰の代理で何をしたか」を追跡可能にする仕組みは、コンプライアンス要件を持つ日本の大企業にとって最低限の前提条件となる。アクセス制御は組織側で設定できるとされているが、その粒度や具体的な実装については現時点では詳細が公開されていない。 セキュリティ面での懸念——見えていないリスクをどう扱うか Scoutの動力源はOpenAIのモデルだ。Microsoftは「エンタープライズグレードのセキュリティ」を謳うが、自律型エージェントに固有のリスクについては具体的な防御策が明示されていない。 特に懸念されるのは以下の2点だ： プロンプトインジェクション攻撃：悪意ある外部ページや添付ファイルに埋め込まれた指示をエージェントが実行してしまう攻撃。ユーザーの直接操作なしに機密情報を漏洩させる経路となりうる エージェント操作：正規の操作に見せかけた誘導によって意図しない行動を引き起こすリスク。常時稼働のエージェントはその攻撃面が従来比で格段に広い The Registerの記事によれば、Microsoftはこれらの詳細についての取材に締め切りまでに回答していない。 日本のIT現場への影響 IT管理者が今すぐ考えるべきこと 条件付きアクセスポリシーの見直し：エージェントIDを持つAIが組織リソースにアクセスする想定で、Entra IDのポリシーを再評価する必要がある データ分類ポリシーの強化：ScoutがアクセスできるSharePoint・OneDriveのコンテンツ範囲を事前に整理しておくこと。「見せていいデータ」と「見せてはいけないデータ」の境界をいま引いておかないと後手に回る ライセンス確認：AutopilotがどのMicrosoft 365ライセンス階層に含まれるかは現時点未確定。一般提供時には別途コストが発生する可能性が高い エンジニアが注目すべき点 Entra IDベースのエージェントアイデンティティという設計は、今後のNon-Human Identity（NHI）管理の標準パターンになる可能性がある。Service PrincipalやManaged Identityの運用経験があるエンジニアにとっては親しみやすい概念だが、AIエージェント特有のアクセスパターン（長時間・広範囲・自律的）に対応したモニタリング体制は別途構築が必要だ。 筆者の見解 MicrosoftがCopilotの「補佐役」という位置づけを超え、自律的に行動するエージェント層を定義しようとしている方向性自体は、業務自動化という観点から理にかなっている。スケジュール調整や締め切り管理のような反復業務をAIに委ねることで、人間が本来注力すべき判断業務に集中できる環境を作ることは、組織の生産性向上に直結する。 ただし、「常時稼働・自律行動」というアーキテクチャはセキュリティ設計の緻密さと表裏一体だ。プロンプトインジェクションへの対策、エージェントの権限スコープの明示、監査ログの粒度——これらが曖昧なまま「エンタープライズグレード」を標榜するのは、もったいないと言わざるを得ない。Microsoftには組織向けセキュリティ設計で培った知見があるのだから、そこを正面から見せてほしかった。 Entra IDとの統合という設計判断は正しい。エージェントにアイデンティティを持たせ、組織のガバナンス体系に組み込むという発想はMicrosoftらしいアプローチだ。あとはその「体系の中身」が実際に機能するかどうか——GAに向けての追加情報開示を注視したい。 Copilotに対してこの数年で積み重なった懐疑的な目線があることは否定しない。だからこそ、Autopilot / Scoutは実力で信頼を取り戻す機会にしてほしい。実際に使えるものを出してきたとき、改めて評価したい。 出典: この記事は No longer just a Copilot, Microsoft’s AI wants to take the wheel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWork IQ MCPをCopilot Studioに統合し、Microsoft 365 Copilotが内部で利用する組織文脈エンジン「Work IQ」をMCPサーバー経由で自社エージェントから呼び出せる機能をプレビュー公開した。 Work IQとは何か Work IQはMicrosoft 365 Copilotの「知性の土台」とも言えるインテリジェンスレイヤーだ。ファイル・メール・会議・チャット・業務システムからシグナルを横断的に集約し、組織内の「誰が・何を・どのように進めているか」をリアルタイムに把握する。今回のMCP統合により、この文脈理解エンジンをCopilot Studio上で構築する自社エージェントから呼び出せるようになった。 3層アーキテクチャの解剖 Work IQは以下の3層構造で動作する。 Data（データ層） M365全体のシグナルを統合する基盤。Teams・Outlook・OneDriveのファイル・メール・会議・チャットから業務システムまで横断収集し、「組織の仕事の流れ」をリアルタイムに把握する。 Memory（記憶層） チームの作業パターンを継続的に学習する層。Agent 365管理エージェントがプロジェクトの優先事項を把握し、タスク・アプリ・セッションをまたいで一貫した対応を実現する。 Inference（推論層） モデル・スキル・ツールを統合し、エージェントがWork IQ MCPツールを使って実際に推論・行動できるようにする層。Agent 365コントロールプレーンが操作の可観測性・ガバナンス・コンプライアンスを担保する。 エンタープライズグレードのセキュリティ設計 大規模組織での利用を前提に、ガバナンスが設計の中心に据えられている点は重要だ。 集中管理: Microsoft 365管理センターでMCPサーバーの許可・ブロックを組織全体で一元管理 スコープ制限アクセス（Least Privilege）: エージェントに必要最小限の権限のみ付与 完全なトレーサビリティ: ツール呼び出しの全履歴を可観測化し、コンプライアンス対応を支援 継続的な評価フレームワークも組み込まれており、精度・レイテンシ・信頼性の3軸で本番品質を継続検証する仕組みが整備されている。 利用要件 Work IQ MCPを使用するにはMicrosoft 365 Copilotライセンスが必要。接続経路はCopilot StudioまたはMicrosoft Foundry（Agent 365 SDK/CLI）の2系統。現時点ではプレビュー段階であり、本番環境への適用は非推奨とされている。 実務への影響 エージェント開発者・アーキテクト向け これまでCopilot Studioで構築するエージェントは、M365の組織文脈（誰がどのドキュメントを最近編集したか、どの会議でどんな議論があったか）を直接参照する手段が限られていた。Work IQ MCP統合により、組織の「作業文脈」をリアルタイムに読み込むエージェントが構築できるようになる。 具体的な活用シナリオ： 最新の会議議事録・メール文脈を踏まえた業務Q&Aエージェント プロジェクトの最新状況を参照しながら次アクションを提案するPMアシスタント 承認フローや進捗管理に組織文脈を組み込んだワークフロー自動化 IT管理者向け MCPサーバーの許可・ブロック制御がM365管理センターから行える点は、セキュリティポリシーの観点で実務上重要だ。AIエージェントが参照できる情報スコープを組織ポリシーで制御できるため、情報漏洩リスクを懸念してAIエージェント活用を躊躇していた企業でも、導入判断のハードルが下がる可能性がある。 筆者の見解 Work IQ MCPの方向性は正しいと思う。「Copilotが持っている組織文脈をエージェントでも利用できるようにする」のは、当然あるべき機能だ。 MicrosoftにはM365という、これだけの組織データと文脈が集積したプラットフォームがある。「組織文脈の深さ」はMicrosoftが他のAIプラットフォームに対して正真正銘の強みを持てる領域であり、Work IQのようなインテリジェンスレイヤーをMCP標準化して開発者に開放するのは、その強みを正面から活かした戦略だと評価できる。ここに本気で投資するなら、面白い競争になる。 ただし現状はプレビューの域を出ていない。精度・レイテンシ・信頼性の継続評価フレームワークが謳われているが、実際の本番環境でどこまで機能するかは、自分の手で動かして確かめるしかない。Teamsの議事録やOutlookの文脈と組み合わせ、自社業務エージェントに「組織の記憶」を持たせる実践的な構成で、GAになったら真っ先に試してみたい機能だ。 出典: この記事は Work IQ MCP: Microsoft 365 Copilot Integration with Copilot Studio の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が、Microsoft 365 テナントにおける退職者のユーザー所有 Loop ワークスペースを引き継ぐワークフローを全テナントに展開完了した。2024年11月の予告から約1年半を経て、IT 管理者はいよいよ対応手順を整備する必要がある。 Loop ワークスペースの「3種類」を理解する まず前提として、Microsoft Loop には3種類のワークスペースが存在する。 ユーザー所有ワークスペース: 各ユーザーが持つ SharePoint Embedded コンテナ。Copilot Pages・Copilot Notebooks・「マイワークスペース」で作成したコンテンツが格納される テナント所有ワークスペース: ユーザーが作成した共有ワークスペース グループ所有ワークスペース: Teams チャンネルなど Microsoft 365 グループに紐づくワークスペース テナント所有・グループ所有の場合は SharePoint 管理者がメンバーシップを制御できるため、退職者対応も比較的容易に行える。問題となるのはユーザー所有ワークスペースだ。これまでは退職者が去ったあとに適切な引き継ぎ手段がなく、コンテンツが宙に浮いた状態になっていた。 退職者対応フローに追加された新しい手順 従来の退職者処理フローは概ね以下の流れで実施されてきた。 アカウントの無効化・パスワード変更・デバイス切断 メールボックスの非アクティブ化（または共有メールボックスへの変換） OneDrive for Business コンテンツの引き継ぎ アカウント削除・ライセンス再割り当て 今回の展開により、このリストに「ユーザー所有 Loop ワークスペースの引き継ぎ」が正式に加わった形だ。 手順は完全に手作業——PowerShell・Graph API は未対応 管理者が実施すべき手順は以下の通りだ。 SharePoint Online 管理センターの「SharePoint Embedded」セクションで退職者のワークスペースを特定する 新しいオーナー（Microsoft は「カストディアン」と呼ぶ）を追加する。退職者の直属マネージャーが適任 コンテナのリダイレクト URL をコピーし、カストディアンにメールまたは Teams チャットで送付する カストディアンがその URL でワークスペースを開き、「ワークスペースにコピー」オプションを使って別のワークスペースへコンテンツを移行する Copilot Notebook が含まれる場合は手順がさらに複雑になる点も要注意だ。ノートブックには多様な情報が含まれることがあり、個別の対応が必要となる。 ここで強調しておきたいのは、この一連の作業を自動化する手段が現時点では存在しないことだ。PowerShell コマンドレットも Graph API エンドポイントも未提供であり、すべてが管理者の手作業になる。 実務への影響——IT 管理者が今すぐやるべきこと 退職者対応チェックリストを更新する 既存の退職者対応手順書に Loop ワークスペースの引き継ぎ項目を追加しよう。手順が標準化されていないまま退職者が出ると、対応漏れが発生するリスクがある。 ...

Microsoft 365の膨大な業務データをAIエージェントが直接活用できる時代が、ついに現実のものとなった。Microsoftは2026年6月2日、「Work IQ APIs」を正式発表した。メール・カレンダー・会議・チャット・ファイルといったM365の各種データを意味的にインデックス化し、企業のAIエージェントへ超低レイテンシで提供する新しいAPI群だ。発表はExecutive Vice President of Copilot, Agents, and PlatformであるCharles Lamanna氏が行った。 Work IQ APIsの全体像 Work IQ APIsは、Microsoft 365に蓄積された業務データをAIエージェントが「理解できる形」で取り出すための基盤APIだ。単純なデータ取得ではなく、意味的なインデックス化（Semantic Index）を経由することで、エージェントは「このメールはどのプロジェクトに関連するか」「誰が誰と頻繁に協働しているか」といった組織のコンテキストまで把握できる。 主な対応データソース： メール（Exchange Online）: 会話スレッド・送受信パターン・関係性 カレンダー: 会議の頻度・参加者・優先度 Teams会議・チャット: 発言内容・意思決定の流れ SharePoint・OneDriveファイル: ドキュメントの内容・共同編集パターン 技術的なポイント Work IQ APIsの特徴は3点に絞れる。 1. 超低レイテンシ: 従来のMicrosoft Graph APIと比較して、エージェントワークロード向けに最適化されたレスポンスタイムを実現。エージェントが「今すぐ判断する」ために必要なデータを待ち時間なく供給する。 2. 組織コンテキストの提供: 単なるデータではなく、「人物・役割・コラボレーションパターン」まで含めたリッチなコンテキストを提供。エージェントは「この部門の意思決定者は誰か」「このチームは週次定例で何を決めているか」といった業務ノウハウを自律的に活用できる。 3. Microsoft 365の統合的な活用: バラバラに存在していたExchange・SharePoint・Teamsのデータを統合コンテキストとしてエージェントに渡せる。これまで「それぞれのAPIを叩いてデータをつなぎ合わせる」必要があった実装が大幅にシンプルになる。 実務への影響 エージェント開発者・アーキテクト向け Work IQ APIsはMicrosoft Copilot StudioやAzure AI Foundryから利用可能になる予定だ。従来のMicrosoft Graph API開発経験があれば習得コストは低く、以下の点で実装が変わる。 コンテキスト構築が容易になる: RAGの知識ソースとしてM365データを使う際、データ収集ロジックを自前で書く必要がなくなる パーミッションモデルの継承: M365の既存アクセス権限がAPIレベルでそのまま適用されるため、セキュリティ設計が既存の延長線上で済む エージェントの「物知り度」が上がる: ユーザーの業務パターンや組織関係を把握したエージェントが構築できる IT管理者・M365管理者向け エージェントのデータアクセス範囲がWork IQ APIsを経由して明示化されるため、監査・ガバナンスの把握がしやすくなる テナント全体のエージェント利用状況がMicrosoft Purviewから可視化できる方向性が示されている 既存のM365ライセンスとアクセス権設計がそのまま活きるため、新たなID管理の複雑化は最小限に抑えられる見込み 筆者の見解 Work IQ APIsの発表は、Microsoftが「M365を単なるSaaSの集合体ではなく、AIエージェントのための知識インフラとして再定義する」という方向性を明確に示したものだと受け取っている。 ...

Microsoftは2026年7月1日より、Microsoft 365の商用ライセンス価格を大幅に引き上げる。値上げ幅はFrontlineプラン（Teams非同梱）で最大43%、Windows Enterprise（デバイス単位）で31%に達するなど、近年最大規模の価格改定となる。既存顧客は次回更新日まで現行価格が維持されるため、今すぐ対応を始める必要がある。 全SKU値上げ一覧 エンタープライズスイート（Teams込み） プラン 現行価格 新価格（7/1〜） 変化率 Office 365 E1 $10.00 $10.00 0% Office 365 E3 $23.00 $26.00 +13% Office 365 E5 $38.00 $41.00 +8% Microsoft 365 E3 $36.00 $39.00 +8% Microsoft 365 E5 $57.00 $60.00 +5% Businessスイート（Teams込み） プラン 現行価格 新価格 変化率 M365 Business Basic $6.00 $7.00 +16% M365 Business Standard $12.50 $14.00 +12% M365 Business Premium $22.00 $22.00 0% Frontlineスイート（最大値上げゾーン） プラン 現行価格 新価格 変化率 M365 F1（Teams込み） $2.25 $3.00 +33% ...

Microsoftは2026年6月のMicrosoft 365ロードマップを公開し、Copilot AgentがSharePointリスト（最大20,000件）へのアクセスに対応したほか、Teams会議録の統合・デスクトップ画面やカメラ映像のリアルタイム解析まで、CopilotのコンテキストAI機能を大幅に拡張する。あわせてDLPのGA・eDiscovery対応など、エンタープライズ向けのガバナンス整備も同時に進む。 今月のアップデートを一言で 「CopilotをAI実験から業務基盤へ移行させるための、コンテキスト拡張とガバナンス整備の同時着手」。これが2026年6月のM365ロードマップを貫くテーマだ。 Copilot/AI体験の主要アップデート SharePointリストへのエージェントアクセス（最大20,000件） Copilot Agent Builderで、SharePointリストを構造化データソースとして活用できるようになる。在庫管理、申請フロー、タスクボードといった「ドキュメントではないが業務の核心にあるデータ」が初めてCopilotの射程に入る。 注意点は、データ品質とパーミッション設定が直接AIの応答精度に影響することだ。「とりあえず作ってあるSharePointリスト」をそのままエージェントに渡すと、意図しないデータが応答に使われるリスクがある。今から権限設計を見直しておきたい。 Copilot Notebooksに会議録・チャットを統合 Teams会議のトランスクリプト、チャット履歴、共有コンテンツをCopilot Notebooksに組み込める。プロジェクトの意思決定コンテキストをセッションをまたいで保持する「プロジェクト脳」として機能するようになる。 Vision：画面・カメラのリアルタイム解析 共有デスクトップ画面やモバイルカメラのライブフィードをCopilotが解析できるようになる。ヘルプデスク対応（ユーザーの画面を見ながらAIがガイド）、現場確認、書類の読み取りといったシナリオが現実的になる。 動的ツール発見（Dynamic Tool Discovery） エージェントを再デプロイせずに新ツールを追加できる機能。開発サイクルは速くなるが、「知らない間にエージェントの能力が変わっていた」というガバナンスリスクを生む。変更管理プロセスの整備が先決だ。 Copilot Studio／エージェントプラットフォーム Work IQ（統合RESTエンドポイント）：エージェントが組織データへ統一的にアクセスするシングルAPIエンドポイント。エージェント間データ統合が標準化される。 リモートMCPサーバーサポート：Copilot StudioエージェントをModel Context Protocol経由で外部AIバックエンドや外部サービスに接続できる。Copilotを「M365テナントのAIエコシステムハブ」として使う設計思想が明確になってきた。 Microsoft Purview（セキュリティ・コンプライアンス） SharePoint DLPのGA：長らくプレビューだったSharePoint向けDLPポリシーがついに一般提供へ。 CopilotとLoopコンテンツへのeDiscovery対応：Copilot会話やLoopコンテンツが電子情報開示の対象になる。金融・医療・法務系企業の法的要件への対応として待望されていた機能だ。 感度ラベルによる接続エクスペリエンスのブロック：感度ラベルで特定のCopilot/AI機能を制限できる。機密データをCopilotから保護する直接的な手段になる。 Outlook／Exchange 外部タグの受信トレイルール対応：外部送信者からのメールに付いた「外部」タグをルール条件として使えるようになる。フィッシング対策の自動仕分けが格段に構築しやすくなる。 実務への影響：日本のIT管理者が今月やること 1. SharePointのデータ品質とパーミッション棚卸し Copilotエージェントはパーミッションがある情報はすべて使う。「見えちゃいけないものが見える」リスクを今すぐ洗い出すこと。リストのカラム定義・権限グループの整理を6月中に始めたい。 2. DLPポリシーとeDiscovery対応の本番設計 SharePoint DLPのGA、CopilotコンテンツへのeDiscovery対応は、コンプライアンス部門を巻き込んだポリシー設計が急務。特に金融・医療・法務・上場企業は対応スケジュールを引くタイミングだ。 3. エージェントガバナンスの枠組みを先に作る Dynamic Tool Discoveryが本番環境に来る前に、エージェントの変更管理プロセスを定義する。「動いているから大丈夫」は通用しない。 筆者の見解 今月のロードマップを眺めると、MicrosoftがCopilotを「AI実験」から「業務基盤」へ移行させるフェーズに入ったことは明確に見て取れる。SharePointリストへのアクセス、DLPのGA、eDiscovery対応——これらは全部「本番環境でCopilotを運用できる状態にするための基盤整備」だ。方向性は正しい。 ここ数年、Copilotに対して「期待ほどの使い勝手ではない」という声が現場から多く上がっていた。その原因の多くは「コンテキスト不足」と「ガバナンス未整備」の2点にあった。今月はその両方に同時に手を入れている。 リモートMCPサポートやWork IQのような「外部AIとの統合基盤」を積極的に整備しているのも注目に値する。これは「CopilotだけでAIを完結させる」方針ではなく、「Microsoft 365をAIエコシステムのハブにする」という設計思想だ。Foundry経由で外部モデルをM365テナントに接続するアプローチが現実解として浮上してきた背景と一致する。 Microsoftはエンタープライズ向け統合プラットフォームとしての強みを持っている。SharePoint・Teams・Outlookが同一テナントで動き、コンプライアンスが一元管理できる——その設計思想が、今ようやくCopilotを通じて活きてきた印象がある。もっとも、基盤が整ったからといって現場の運用がついてくるかどうかは別の話だ。管理者側の準備こそが、今後のCopilot活用の差を生む。 出典: この記事は Microsoft 365 Roadmap Updates June 2026 – Level Up M365 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Build 2026（2026年6月2〜3日）で、Microsoftはエージェント戦略の大転換を正式発表した。CopilotをアシスタントからAI自律エージェント基盤へと全面再定義し、「Microsoft IQ」「Microsoft Foundry」「Agent 365」「Copilot Credits」の4本柱に加え、全く新しいカテゴリ「Autopilots」の第一弾製品Microsoft Scoutを一斉公開した。 4つの核心発表 1. Microsoft IQ — 統合インテリジェンス層 Microsoft IQはエージェントにコンテキストを供給する「頭脳」となる統合インテリジェンス層だ。4つのコンポーネントで構成される。 Work IQ: 職場データのコンテキスト Foundry IQ: ナレッジベース（本日GA） Fabric IQ Ontology: ビジネスセマンティクス Web IQ（新登場）: リアルタイムWebグラウンディング GitHub Copilot・Microsoft Foundry・Copilot Studioをまたいで利用可能となり、エージェントが「何を知っているか」を組織のあらゆる情報源から引き出せる仕組みが整った。 2. Microsoft Foundry — エージェント実行基盤 Microsoft Foundryはエージェントを構築・実行するプロダクション層として大幅強化された。 Hosted Agents: 2026年6月末にGA予定。ハイパーバイザー分離サンドボックス、エージェントごとのEntra ID、azdによるソースコードデプロイ、コンテンツセーフティ内蔵 Microsoft Agent Framework 1.0: Python・.NET対応で本日GA モデルカタログ: 1万1,000以上のモデルが収録。OpenAI GPT-5.5は翌日GA、Claude Opus 4.8はプレビュー提供開始 Agent Control Specification: プレビュー提供 Adaptive Evaluationsと手続き記憶（Procedural Memory）も追加 3. Copilot Credits — 消費量課金モデル エージェントの仕事量を計測する「メーター」としてCopilot Creditsが導入された。 従量課金: $0.01/クレジット プリペイドパックも選択可能 人間向けのCopilot（ユーザーライセンス）は従来のユーザーごと課金を維持 4. Agent 365 — ガバナンス傘 Agent 365はエージェントを統制・管理するフレームワークだ。 ...