Tech-News

Epic Gamesが次世代ゲームエンジン「Unreal Engine 6（UE6）」を正式発表し、初公開となるデモ映像を世界に向けて披露した。Unreal Engine 5（UE5）のリリースから約4年——ゲームエンジン業界に再び大きな転換点が訪れた。 UE5が変えたゲーム開発の常識 UE6を正しく評価するためには、まずUE5がもたらした革命を振り返る必要がある。2022年にリリースされたUE5は、Nanite（仮想化ジオメトリシステム）とLumen（リアルタイムグローバルイルミネーション）という2つの中核技術によって、ゲーム開発の制約を根本から塗り替えた。 Naniteはポリゴン数の上限という長年の制約を事実上消滅させ、映画品質のアセットをそのままゲームエンジンに取り込むことを可能にした。Lumenはベイク済みライトマップへの依存を排し、動的に変化する照明環境をリアルタイムで表現することを実現した。これらは「改良」ではなく、開発ワークフローそのものを再設計する「変革」だった。 加えてWorld Partitionによる巨大なオープンワールドのストリーミング管理、MetaHumanによる高品質な人物キャラクター生成ツールなど、UE5はエンジン単体にとどまらないエコシステムとして進化してきた。 UE6が示す次のビジョン Epic Gamesが公開した初映像は、UE6が単なる「UE5の改良版」ではないことを強く示唆している。前バージョンで確立されたリアルタイムレンダリングの基盤の上に、さらなる没入感・物理シミュレーション精度・AIとの融合が期待される。 ゲームエンジンにおけるAIの役割は急速に拡大しており、手続き型コンテンツ生成（PCG）の精度向上、キャラクターのリアルタイム行動生成、開発者向けのコーディング支援統合など、UE6世代でのAI活用は開発生産性に直結する領域として注目される。 実務への影響——日本のゲーム・映像制作現場にとっての意味 Unreal Engineは今やゲーム開発だけでなく、テレビ・映画のバーチャルプロダクション（インカメラVFX）、建築ビジュアライゼーション、自動車・製造業のデジタルツイン分野にも広く使われている。特に日本では映像制作・イベント演出分野でのUnreal Engine採用が加速しており、UE6へのバージョンアップは直接的な業務影響をもたらす。 エンジニア・クリエイターへの実践的ヒント： UE5プロジェクトのUE6移行パスを早期に確認し、既存アセットの互換性を把握しておく UE6のシステム要件（特にGPUメモリ・ストレージ速度）は現行世代より高くなる可能性が高いため、ハードウェア計画に織り込む Nanite・Lumenのワークフローに慣れているチームはUE6への移行障壁が低い。UE5への移行を先送りにしているスタジオは今が好機 Epic GamesのFab（旧Unreal Marketplace） のアセットエコシステムがUE6対応になるタイミングを注視する またWindowsとの連携という観点では、DirectX 12 Ultimate・DirectStorage・Mesh Shaderといったマイクロソフトが推進するPC向けグラフィクスAPIとUnreal Engineの親和性は歴史的に高く、UE6世代でもWindowsプラットフォームが最適な動作環境のひとつであり続けるだろう。 筆者の見解 ゲームエンジン市場においてEpic GamesのUnreal Engineが果たしてきた役割は、単なるツール提供にとどまらない。オープンソース化されたエンジンコードの公開、無料ティアの拡充、そしてMetaHumanやFabといったエコシステムの整備は、業界全体の底上げという意味で評価できる。 興味深いのは、Unreal Engineがゲームの外側——製造業・建築・放送——に活躍の場を広げていることだ。「リアルタイム3Dレンダリングを誰でも使える技術にする」という方向性は一貫しており、UE6がその流れをさらに加速させるか否かが注目点になる。 日本のIT現場という視点では、ゲーム会社以外でのUnreal Engine採用がまだ限定的な組織も多い。UE6の発表を機に、デジタルツインや工場可視化・プレゼンテーション制作への活用を検討してみるのも一手だ。技術の民主化という波は、ゲーム業界から静かに、しかし確実に波及してきている。 出典: この記事は Epic Games unveils Unreal Engine 6, and its first footage is here の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleは2026年5月19日、ターミナル向けAIコーディングツール「Gemini CLI」を2026年6月18日をもって終了し、新プラットフォーム「Google Antigravity」の一部として提供する「Antigravity CLI」へ移行することを正式発表した。個人ユーザーは約1か月という短い猶予期間での移行を求められる。 なぜGemini CLIが終わるのか Gemini CLIは2025年に登場し、GitHubで10万スターを超え、6,000件以上のプルリクエストがマージされるなど、短期間で多くの開発者に受け入れられた。しかしGoogleは「ユーザーのワークフローが単一エージェントの対話から、複数エージェントが協調して複雑な問題を解くスタイルへ急速に進化した」と移行の理由を説明している。 単一CLIツールの枠を超え、デスクトップアプリや他のワークフローと統一されたバックエンドを共有するプラットフォームが必要だという判断から、Gemini CLIの単体進化ではなく「Google Antigravity」という新たな統合プラットフォームへの全面移行を選択した。 Antigravity CLIの主な変更点 機能 Gemini CLI Antigravity CLI 実装言語 TypeScript Go（より高速・軽量） エージェント実行 単一エージェント 非同期マルチエージェント バックエンド 独立 Antigravity 2.0と統一 拡張機能 Extensions Antigravity Plugins Antigravity CLIはGoで書き直されており、応答速度と安定性の向上が期待できる。複数エージェントを並行実行する非同期ワークフローにより、大規模なリファクタリングやリサーチ作業をターミナルセッションをブロックせずに実行できるようになった点は、実務での恩恵が大きい。 Gemini CLIの中核機能であるAgent Skills・Hooks・Subagentsは引き継がれており、ExtensionsはAntigravityプラグインとして継続する。ただし完全な機能パリティが初期から保証されているわけではない点は注意が必要だ。 移行タイムライン 個人ユーザー（コンシューマー）向け： 2026年5月19日〜：Antigravity CLI 提供開始 2026年6月18日：Gemini CLI および Gemini Code Assist IDE拡張が終了。Google AI Pro/Ultraユーザー、Gemini Code Assist for Individuals（無料）ユーザーが対象 GitHub向け Gemini Code Assist も同日以降、新規インストール不可・リクエスト停止 法人（エンタープライズ）向け： 今回は変更なし。Gemini Code Assist Standard/Enterpriseライセンスを持つ組織は継続利用可能 有料APIキー（Gemini Enterprise Agent Platform）経由でも引き続きアクセス可 Antigravity CLIを先行試用したい場合はGoogle Cloudプロジェクト経由で利用可能 実務への影響 Gemini CLIを個人利用している開発者は6月18日までに移行を完了させる必要がある。猶予は約1か月と短いため、早めの動作確認を強く推奨する。 ...

Microsoft は2026年5月21日、Microsoft Defender に存在する2件のゼロデイ脆弱性に対するセキュリティパッチの配布を開始した。いずれも実際の攻撃に悪用されていることが確認されており、米国土安全保障省傘下のCISA（サイバーセキュリティ・インフラセキュリティ庁）も同日、政府機関に対して6月3日までの緊急対応を命じている。 2件の脆弱性の概要 CVE-2026-41091：SYSTEM権限を奪取される特権昇格 1件目は Microsoft Malware Protection Engine 1.1.26030.3008 以前 に存在する特権昇格の脆弱性。「リンクフォロー（link following）」と呼ばれる、ファイルアクセス前のリンク解決処理が不適切であることに起因する。 攻撃者がこれを悪用すると、最終的に SYSTEM権限（Windowsにおける最高権限）を取得できる。ローカルユーザーとして侵入さえできれば権限昇格が成立するため、フィッシングや別の脆弱性との組み合わせで悪用されるリスクが高い。 CVE-2026-45498：サービス拒否（DoS）状態を引き起こす 2件目は Microsoft Defender Antimalware Platform 4.18.26030.3011 以前 に存在する脆弱性で、System Center Endpoint Protection（2012 R2・2012）、Security Essentials にも影響する。 悪用されると Windows デバイスを サービス拒否（DoS）状態に陥らせることができる。セキュリティ製品そのものがダウンすることで、後続の攻撃への道が開かれる危険がある。 修正バージョンと対処法 Microsoft は以下のバージョンで修正を済ませている： Malware Protection Engine: 1.1.26040.8 Antimalware Platform: 4.18.26040.7 Windows Defender のマルウェア定義とプラットフォームは既定で自動更新が有効になっているため、多くの環境では追加操作なしにパッチが適用済みのはずだ。 ただし、Microsoft は「自動更新に任せてよい」としつつも、以下の手順で適用確認を推奨している： 「Windows セキュリティ」アプリを開く 左ペインで「ウイルスと脅威の防止」を選択 「保護の更新」→「更新プログラムの確認」を実行 左ペインの「設定」→「バージョン情報」を開き、Antimalware Client Version を確認 バージョン番号が上記の修正バージョン以上であれば対応完了だ。 CISAの動きと日本への示唆 CISA は両脆弱性を 既知悪用脆弱性（KEV）カタログに追加し、連邦文民行政機関（FCEB）に対して BOD 22-01 に基づき 6月3日 までの対応を義務付けた。 「この種の脆弱性は悪意ある攻撃者にとって頻繁に使われる攻撃経路であり、連邦政府のエンタープライズに重大なリスクをもたらす」とCISAは警告している。 ...

Microsoftは、Word・Excel・PowerPointに展開していた「浮動Copilotボタン（Copilot Dynamic Action Button：DAB）」がユーザーの作業フローを妨げているとの大規模な批判を受け、ボタンをリボンに戻す選択肢の提供を開始した。 なぜ浮動ボタンを追加したのか 背景にあるのは、Copilotの採用率の低さだ。現時点でMicrosoft 365ユーザーのうちCopilot有料プランに加入しているのはわずか**3.3%**にとどまっており、Microsoftの内部期待を大きく下回っている。 この数字を改善すべく、Microsoftは2025年12月からDABのロールアウトを開始。2026年5月の展開完了を目指して段階的に拡大してきた。設計チームは「インテリジェンスが適切なタイミングで提供されなければ、パートナーではなく邪魔者に感じられる」と「探索（exploration）」「集中（focus）」を促す機能として位置づけていた。 ユーザーの反応：想定外の激怒 しかし現実は設計チームの期待とは大きく異なった。特にExcelでは、ワークシート右下に常駐するボタンがセルを覆い隠してしまう問題が続出。Microsoftのフィードバックハブには次のような声が相次いだ。 「その存在自体が腹立たしい。Excelまで全員に嫌われたいなら最高のボタンだ」 「ひどいアップグレードだ。オフにできる方法を提供してくれ」 Microsoftはロールアウト前から浮動ボタンが作業を妨げる可能性を認識していたにもかかわらず、クリックスルー率向上という内部目標を優先して展開を強行していたことが今回の件で明らかになっている。 Microsoftの対応：右クリックでリボンへ移動 批判を受けMicrosoftは、ボタンを右クリックすることでリボンへ戻せる新オプションを追加した。 「Microsoft 365をCopilotとより緊密に統合し、必要なときにいつでも役立つ思考パートナーとして利用できるようにする取り組みを進めてきました。フィードバックに耳を傾け、学び、改善し続けています」——Microsoft公式コメント ボタンの配置は現在「浮動」「ドッキング（横へ固定）」「リボン」の3択から選べる形となっている。完全な非表示は現時点では提供されていない。 実務への影響 現在このボタンが表示されているOfficeユーザーは以下の手順で即座に対処できる。 Copilotの浮動ボタンを右クリック 「リボンに移動」オプションを選択 以降は従来通りリボンからのアクセスに切り替わる IT管理者の観点では、Microsoft 365管理センターやグループポリシーを通じたテナント全体での制御オプションについても、今後の展開を注視する必要がある。Copilot関連のUI変更は今後も続く可能性が高く、エンドユーザーへの事前周知と操作説明を準備しておくことが望ましい。 筆者の見解 MicrosoftがDABのロールアウト前から「ユーザーの作業を妨げる可能性がある」と認識しながら、クリックスルー率向上という内部指標を優先して展開を強行したことは、率直に言ってもったいない判断だった。 Copilotの採用率3.3%という数字は確かに課題だが、その改善策として「UIを変えて無理やり目に触れさせる」というアプローチは、Copilotが本来訴求すべき価値——生産性の向上——と逆行する。Excelのセルを隠すボタンを「思考パートナー」と呼ぶことには無理がある。 MicrosoftにはUIの押しつけではなく、Copilotが実際に価値を生む場面を増やすことで採用率を高める力が十分にある。今回のフィードバックを真摯に受け止め、次のUI変更では「なぜこれがユーザーにとって価値あるのか」を起点に設計を組み立て直してほしい。正面から勝負できる製品を持っているのだから、焦る必要はないはずだ。 出典: この記事は Microsoft admits the floating Copilot button in Word, Excel and PowerPoint was a mistake, lets you hide it after backlash の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、企業向けコミュニケーションツール「Microsoft Teams」の大幅なUIリデザインを2026年7月より段階的に展開すると発表した。中央配置のコントロールバー、安全な画面共有機能、カスタマイズ可能な会議ツールなど、現場での使い勝手を根本から見直す変更が盛り込まれている。 何が変わるのか 今回のリデザインで注目されるのは、コントロールの中央配置だ。これまでのTeamsは会議中のコントロールバーが端に寄りがちで、大画面ディスプレイでは操作しづらいという声があった。新デザインでは画面下部の中央にコントロールをまとめることで、自然な視線の流れとクリック動線を一致させる設計になる。 安全な共有オプションの強化も見逃せない。画面共有時に意図しないウィンドウや個人情報が映り込む事故は、リモート会議を日常的に使う現場で繰り返し問題になってきた。新デザインではどのコンテンツを共有するかをより明示的に選択できる仕組みが導入され、誤共有リスクの低減が期待される。 カスタマイズ可能な会議ツールについては、チームや用途に合わせて会議中に利用するボタンや機能を整理できるようになると見られる。全員に同じUIを押し付けるのではなく、ロールや会議の種類に応じた最適な操作環境を構築しやすくなる方向性だ。 なぜこれが重要か Teamsはいまや日本の企業でも当たり前のインフラだ。大手企業から官公庁まで利用が広がっており、UIの大幅変更は「慣れ直しコスト」として現場に波及する。一方で、ZoomやGoogle Meetとの競争が続く中、Microsoftがユーザー体験の改善に継続的に投資している姿勢は評価できる。特に「安全な共有」という方向性は、情報漏洩リスクを常に意識しなければならないエンタープライズ環境にとって正しい優先順位だ。 実務への影響——IT管理者が今すぐすべきこと 展開は2026年7月開始予定だが、大規模テナントへの完全展開はそれ以降になるケースが多い。以下の点を早めに確認しておくとよいだろう。 ターゲットリリースの確認: Teams管理センターで段階的展開（ターゲットリリース）を設定しているかを確認し、先行評価の準備をしておく エンドユーザー教育の準備: 大幅UIリデザインはヘルプデスクへの問い合わせ増加要因になりやすい。FAQや簡易ガイドを事前に整備しておくことで展開後の混乱を最小化できる 会議テンプレートの見直し: カスタマイズ可能な会議ツールが導入されれば、自組織の会議運用を整理する好機となる。今のうちに「どんな会議種別があるか」を棚卸ししておくと導入がスムーズになる 共有ポリシーの明文化: 新機能に合わせて「どのコンテンツを共有してよいか」を社内ポリシーとして文書化しておくと、展開後のトラブル対応が楽になる 筆者の見解 Microsoft Teamsのリデザインは、見た目の刷新にとどまらず「意図しない情報漏洩を設計で防ぐ」という思想の変化が感じられる点で興味深い。機能追加が続いてきた分、UIの複雑さも積み上がっていたTeamsにとって、中央配置のコントロールや安全な共有機能は「引き算の設計」として正しい方向性だと思う。 ただ、リデザインに期待したいのは見た目だけではない。大規模会議でのCPU・メモリ使用率の改善や、AI機能（議事録生成・ノイズキャンセル）との自然な統合も同時に進んでほしい。UIが洗練されても、会議中に動作が重くなるようでは本末転倒だ。 Copilot for Teamsの活用がいよいよ現場に浸透し始めるタイミングと重なるだけに、このリデザインがAI機能との一体化を実現したものになるかが真の評価軸になるだろう。プラットフォームとしての底力はTeamsにある。その力を存分に引き出す方向で進化してほしいと思う。 出典: この記事は Microsoft Teams is getting a major redesign, here is a first look の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11の2026年5月累積更新プログラム（KB5089549）において、一部デバイスでインストールが35%付近で停止しエラーコード「0x800f0922」が発生することを公式に認めた。原因はEFIシステムパーティション（ESP）の空き容量不足であり、Known Issue Rollback（KIR）による自動緩和策がすでに展開済みだ。 エラー0x800f0922の原因：EFIシステムパーティションの空き容量不足 ESP（EFI System Partition）はUEFIブートに不可欠なパーティションで、Windowsの起動ファイルやブートローダーが格納されている。今回のKB5089549ではESPへの一定量の書き込みが必要となるが、空き容量が10MB以下の環境では書き込みに失敗し、インストールが35%前後で止まってエラーを返すことが確認された。 特に問題になりやすいのは以下のケースだ： 数年前のPCでESPが100MB以下に設定されているもの 累積更新を重ねるうちにESPの空き容量が少しずつ圧迫されたデバイス サードパーティ製ツールや暗号化ソフトが追加ファイルをESPに書き込んでいる環境 KIR（Known Issue Rollback）とは MicrosoftはWindows 11でKIRという仕組みを導入している。問題のあるアップデートを自動的に「なかったこと」にするロールバック機能で、Microsoftが問題を検知すると約24時間以内に自動配信される。今回のエラー0x800f0922に対しても展開済みだが、Intuneや企業GPOで管理されていない「管理対象外デバイス」は手動対応が必要な場合がある。 IT管理者が取るべき対応 1. 影響範囲の確認 IntuneやSCCM/MECMを使っている環境では、更新失敗レポートをエラーコード「0x800f0922」で絞り込むとKB5089549の適用失敗デバイスを効率よく特定できる。 2. ESPの空き容量確認 管理対象デバイスでESPの空き容量が少ない場合は、不要ファイルの削除かESPサイズの拡張が必要になる。ただしESPのサイズ変更はリスクを伴う操作のため慎重な手順が求められる。以下のコマンドでESPをマウントして空き容量を確認できる： 出典: この記事は Microsoft confirms Windows 11’s May 2026 update is failing to install with error 0x800f0922 and outlines a mitigation for affected PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがClaude Codeのライセンスの大部分をキャンセルし、社内エンジニアをGitHub Copilot CLIへ移行させていることがThe Vergeの報道で明らかになった。同社が約6か月前に数千名の開発者・プロジェクトマネージャー・デザイナーへのアクセスを開放したばかりの急転換で、エンタープライズAIのコスト問題が産業全体の共通課題として浮かび上がっている。 Claude Codeライセンス削減の背景 MicrosoftはClaude Codeのダイレクトライセンスのほとんどをキャンセルする方向で動いており、開発者はGitHub Copilot CLIへ移行することになる。ただし、この決定はMicrosoftとAnthropicの大型パートナーシップ——最大50億ドルのAnthropicへの投資や、AnthropicのAzureコンピュートへの300億ドル相当の購入コミットメント——には影響しないとされている。あくまで「社内利用コストの管理」が今回の施策の目的だ。 トークンコストの逆説：使えば使うほど高くつく構造 今回のMicrosoftの動きは単独の事象ではない。Uberは2026年のAIコーディングツール予算を4か月で使い切ったことが報じられ、MetaはAnthropicのモデル名にちなんだ「Claudeonomics」というリーダーボードでAI使用量を競わせ、AmazonはAIトークンを最大限に使う「Tokenmaxx」を従業員に奨励している。 こうした「使えば使うほどよい」という前提の施策が、コスト爆発の遠因になっている可能性がある。 重要なのは、AIトークンの単価は今後下がっても、エンタープライズ全体のAIコストは必ずしも下がらないという点だ。 Goldman Sachs予測: エージェントAIの普及により、2030年までにトークン消費量は24倍増、月間120京トークンに到達 Gartner分析: 2030年には1兆パラメータLLMの推論コストが2025年比で約90%低下する見込みだが、エージェントAIは1タスクあたりのトークン消費量がはるかに多く、消費量の増加が単価低下を上回る可能性がある Gartnerのアナリスト、Will Sommer氏はこう警告している。「CPO（最高製品責任者）は、コモディティトークンのデフレと、フロンティア推論の民主化を混同してはならない」 Nvidia副社長のBryan Catanzaro氏も「私のチームでは、コンピュートコストが従業員コストをはるかに上回っている」と語っており、AIが必ずしも人件費削減につながらないという現実を示している。 実務への影響：日本のエンジニア・IT管理者が今すぐ考えるべきこと 1. AI活用予算の設計を見直す 「AIを使えばコストが下がる」という単純な前提でROI試算を行うのは危険だ。エージェントAIを本格導入する前に、トークン消費量のシミュレーションと上限設定を組み込んだ設計が必要になる。 2. KPI設計に注意する UberやAmazonのように「使用量」をKPIにすると、価値のない用途でトークンを消費するインセンティブが生まれる。測定すべきは「AIを使ったことで何が改善されたか」であり、消費量そのものではない。 3. ツール集約を検討する MicrosoftのGitHub Copilot CLIへの移行は、統合プラットフォームへの集約という方向性とも読める。複数のAIツールを分散導入するよりも、管理・コスト・ガバナンスの観点で一元化を検討する価値がある。 筆者の見解 今回の報道で最も興味深いのは、MicrosoftがAnthropicに大規模投資しつつ、Claude Codeの社内利用コストを問題視しているという構図だ。ツールの価値とコスト管理の問題は、まったく別次元の話である。 AmazonのTokenmaxx、Uberの予算超過、そしてMicrosoftの今回の方針転換——これらに共通するのは「使用量を最大化すること」を目的化した施策の失敗だ。変なKPIを設定してその数字だけをハックする行動は、人間が組織の中で陥りがちな典型的な罠だと感じている。 AIをどこに使い、どこには使わないかを組織として定義しないまま採用を推進すると、コストだけが膨らむ。MicrosoftがGitHub Copilot CLIへの移行で管理の標準化を図ろうとしている方向性自体は理解できる。重要なのは、コストを下げるためにAIの価値まで下げないことだ。 2030年に向けてエージェントAIの普及でトークン消費量が爆発的に増加するという予測は現実的だ。それだけに今から「AIをどう使うか」ではなく「AIでどんな成果を出すか」を中心に置いた仕組みづくりが求められる。企業のAI活用が本格化するほど、この設計の巧拙が競争力の差に直結するようになるだろう。 出典: この記事は Microsoft reports AI is more expensive than paying human employees の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月19日、Azure Files SMBにおける「Entra-Only ID認証（Entra-Only identities）」の一般提供（GA）を発表した。Microsoft Entra IDをKerberos認証の主体として直接利用する仕組みで、オンプレミスのActive Directory（AD）、ハイブリッドID同期、マネージドドメインコントローラーのいずれも不要となる。追加費用は発生せず、HDD・SSD全シェア・全課金モデルで利用できる。 これまでの課題：ADが「クラウド化の壁」だった Azure Filesへの移行を検討した企業がよく口にするのが「認証をどうするか」という問題だ。SMBプロトコルを使うファイル共有では、従来からWindowsのKerberos認証が前提となっており、その鍵配布センター（KDC）としてADが必須だった。 クラウドに移行しても、ADをオンプレミスに残すか、Azure AD Domain Services（現Microsoft Entra Domain Services）を立ち上げるか、いずれかのハイブリッド構成が必要だった。インフラチームが「ほぼクラウド化できたのに、ADだけ残っている」という状況は珍しくない。今回のGA発表は、その最後のブロッカーを正面から取り除くものだ。 何が変わったのか Microsoft Entra IDがKDCになる Entra-Only IDの核心は、Microsoft Entra IDがKerberos KDCの役割を直接担う点にある。クライアントはEntra IDに対して認証要求を出し、KerberosチケットをAzure Filesへのアクセスに使う。ADドメインへの参加は不要で、Entra参加済みのデバイスがあれば動作する。 ポータルからNTFSアクセス許可を設定できるように 従来、NTFS権限の設定にはドメイン参加済みクライアントからicaclsコマンドを叩く必要があった。今回のGAでは、Azureポータルから直接、ファイル・ディレクトリのACLをEntra-Onlyユーザー・グループに対して設定できるようになった。全リージョンで利用可能だ。 RBAC対応の拡充（限定リージョン） 共有レベルのRBAC（ロールベースアクセス制御）がEntra-Onlyユーザー・グループに対しても適用できるようになった。こちらは現時点では限定リージョンのみとなっており、対象リージョンは公式ドキュメントで確認が必要だ。 macOSクライアントへの拡張（限定プレビュー） Platform SSOでEntra参加したmacOSクライアントからも、Entra-Only認証でAzure Filesにアクセスできる。クリエイティブ職や混在環境での運用を想定した機能で、現在は限定プレビューの位置づけだ。 Azure Virtual Desktop（AVD）とFSLogixへの影響 Entra-Only IDが最も直接的な価値を発揮するのがAzure Virtual Desktop（AVD）＋FSLogixの構成だ。 FSLogixはユーザーのプロファイルをAzure Filesのファイル共有に置いてセッションホストにマウントする。従来はこのマウントにAD認証が必要だったため、AVDをフルクラウド化したくても「FSLogixのためだけにADを維持する」という矛盾した構成を取らざるを得なかった。 Entra-Only IDによってこの制約が解消される。さらにB2B（ビジネス間連携）サポートが組み込まれており、外部パートナーが自社のEntraアカウントでFSLogixプロファイルを利用できる。ゲストアカウントを別途作る必要がなく、ID管理の二重化を防げる。 実務への影響：日本のIT現場で何が変わるか ADのリタイア計画を具体化できる オンプレミスADを段階的に廃止したい企業にとって、「Azure FilesがADなしで動く」という事実は計画の実現性を大きく高める。ハイブリッドID（AD + Entra ID同期）との共存もサポートされているため、移行期間中に両方を並行運用することも可能だ。 VPNを減らす正当な根拠が生まれる Entra参加済みデバイスがあれば、VPNなしでAzure Filesへのリモートアクセスが成立する。「ファイルサーバーにアクセスするためにVPNを張らなければならない」という理由がひとつ消える。VPN廃止・縮小を検討している管理者には追い風だ。 IntuneとのID ライフサイクル統合 クライアント側のInture連携が組み込まれており、デバイスのコンプライアンス状態とファイルアクセス権を統合管理できる。退職者のアカウント失効・デバイス登録解除とファイル共有アクセスの無効化を一元的に扱えるのは、ID管理の工数削減に直結する。 追加コスト不要・既存シェアに適用可能 HDD・SSD共に、トランザクション最適化・ホット・クールのすべての課金モデルで追加費用なしに利用できる。既存のAzure Filesシェアに対して機能を有効化するだけで使えるため、新規リソースの作成も不要だ。 筆者の見解 ゼロトラスト推進の観点から言えば、このGAは「正しい方向への一歩」だ。ネットワーク境界を前提とした認証モデルの残滓であるオンプレミスADへの依存を、クラウドネイティブなID基盤で置き換えること——これはアーキテクチャとして筋が通っている。 Microsoft Entra IDがKDCを担うという設計は、エージェントやサービス間のID管理を将来的にEntraで一元化していく流れとも一致する。人間のアカウントだけでなく、Non-Human Identity（NHI）——サービスプリンシパル、マネージドID、ワークロードID——を含めたすべてのIDをEntraで管理できる世界に向けて、ファイル共有というレガシーなレイヤーをクラウドネイティブ化した意義は小さくない。 ...

ソニーが開発したウェアラブル型体温調節デバイス「Reon Pocket Pro Plus」について、海外テックメディアTom’s Guideが詳細レビューを公開した。同メディアのレビュアーはこの製品を「これまでテストした中で最も未来的な製品」と表現し、高い完成度を評価している。現在はイギリスで**£199**（日本円換算で約4万円）で販売中で、米国では2026年夏の発売が予定されている。 Reon Pocket Pro Plusとは何か Reon Pocket Pro Plusは、衣服の背中側に装着するウェアラブルデバイスだ。ステンレス製のプレートが加熱・冷却を切り替えて体温を調節する仕組みで、スマートフォンアプリまたは本体ボタンで操作できる。Bluetooth 5.0対応で、iOS 16以降・Android 9以降のスマートフォンと連携する。 主なスペックは以下の通り： 項目 内容 サイズ 175 × 124 × 61 mm 重量 約258g バッテリー 10時間（充電約200分） 動作温度 5〜40℃ 接続 Bluetooth 5.0 対応OS iOS 16以降 / Android 9以降 シリーズには「Reon Pocket 5」（£149）と「Reon Pocket Pro」（£199）も存在するが、Pro Plusはパフォーマンスと装着感の両面でアップグレードが施されたモデルだ。 Tom’s Guideレビューのポイント Tom’s Guideのレビュアーは、加熱・冷却いずれの機能も「実用的なレベルに達している」と評価した。以下に主なポイントをまとめる。 評価できる点 センサーが状況を自動判断する「Smart Modes」が便利で、常時スマホを操作する手間がない アプリのレスポンスが良く、操作性が高い 10時間のバッテリーで「1日の仕事を通して使い続けられる」 個人の体感に合わせて細かく調整できる 気になる点 本体ボタンが背中側にあるため、装着中はボタン操作が難しい ただしこの点についてレビュアーは「スマートフォンをリモコン代わりに使えば問題にならない」と補足しており、実使用上の大きな障壁にはならないとしている。 Tom’s Guideは他製品との比較も行っており、冷却特化の「Shark ChillPill」（$149）や手持ち型の「Dyson HushJet Mini Cool」（$99）などを挙げつつも、「冷暖房両対応でウェアラブルなデバイスはReon Pocket Pro Plus以外に存在しない」と結論づけている。 日本市場での注目点 Reon Pocketシリーズはもともとソニーが日本発で展開してきた製品だ。「Reon Pocket 5」（NWB-RK500N）はソニーストアや家電量販店で購入可能で、日本のユーザーにも馴染みがある。 ...

Mozillaは公式ブログにて、Intel第13世代（Raptor Lake）および第14世代（Raptor Lake Refresh）搭載システムでFirefoxが突然クラッシュする事象の原因を詳細に解説した。根本原因はFirefox自体のバグではなく、Intel CPUのハードウェアレベルの安定性問題にあることが明らかになった。 Intel Raptor Lakeの「隠れた時限爆弾」 Intelの第13・14世代Core プロセッサー（開発コード名：Raptor Lake）には、製造段階に起因するとされる電圧制御の不具合が存在する。具体的には、eTVB（enhanced Thermal Velocity Boost）機能が不正な高電圧リクエストをCPUコアに送り続けるという問題で、これによりCPUが仕様外の状態で動作し、演算ミスや不意の停止を引き起こす。 Intelは2024年8月にマイクロコードアップデート（第13世代向け：0x125、第14世代向け：0x129）を公開して対処したが、アップデートを適用していないシステムでは依然として問題が発生しうる。 なぜFirefoxが特に影響を受けるのか Mozillaの調査によると、FirefoxはそのJavaScriptエンジン（SpiderMonkey）やレンダリングエンジン（Gecko）がCPUの演算処理を高頻度かつ並列的に行う設計であるため、Raptor Lakeのわずかな演算ミスが致命的なクラッシュとして表面化しやすいという。 一般的なオフィスアプリケーションでは演算ミスが気づかれないままスルーされる場合もあるが、ブラウザのJITコンパイラ（実行時コンパイル）はCPUの計算結果を厳密に使用するため、わずかなビットエラーがプロセス全体の異常終了に直結する。 Mozillaは現象を特定するため、クラッシュレポートの統計解析を実施。第13・14世代CPU搭載ユーザーから寄せられたクラッシュが異常な頻度を示しており、特定のハードウェア世代への集中が統計的に有意であることを確認した。 影響範囲と確認方法 影響を受けるのは主に以下の環境： CPU: Intel Core i-13000シリーズ（第13世代）、Core i-14000シリーズ（第14世代） 症状: Firefoxの突然のクラッシュ、特に複数タブを開いている状態やJavaScript負荷が高いサイト閲覧中 マイクロコード未適用のシステム: BIOSアップデートが行われていないPCが特に危険 自分のCPUがどの世代かは、Windowsであれば「タスクマネージャー → パフォーマンス → CPU」で確認できる。また、BIOSのバージョン確認は msinfo32.exe から「BIOSバージョン/日付」を参照する方法が簡単だ。 実務への影響——IT管理者が今すべきこと 1. マイクロコードアップデートの展開を急ぐ 企業環境で第13・14世代Intel CPUを導入済みの場合、BIOSアップデートの展開が最優先だ。各PCメーカー（Dell、HP、Lenovo等）はすでにIntelのマイクロコード修正を含むBIOSアップデートを公開済みであるため、管理コンソール（SCCM、Intune等）からのリモート展開を検討したい。 2. Firefoxを社内標準ブラウザとして利用している場合 ヘルプデスクへの「Firefoxが落ちる」という問い合わせが増えている場合、Firefoxの問題ではなくハードウェア起因である可能性を念頭に置く。安易に「Chromeに変えてください」で済ませてしまうと、根本問題が放置されたまま他のアプリケーションにも影響が波及しかねない。 3. 新規調達時の注意点 中古PC市場や既存在庫での第13・14世代CPU搭載機を調達する場合、受け入れ時にBIOSバージョンを必ず確認し、マイクロコードアップデート適用済みであることを検証する手順を導入することを推奨する。 4. 一時的な回避策 すぐにBIOSアップデートが適用できない環境では、Firefoxの設定でハードウェアアクセラレーションを無効化する（設定 → 一般 → パフォーマンス → ハードウェアアクセラレーションのチェックを外す）ことでクラッシュ頻度を下げられる場合がある。ただしこれは根本解決ではない。 筆者の見解 Mozillaの今回の対応は、ソフトウェアベンダーとして模範的だと思う。「うちのブラウザの問題です」と言いたくなるプレッシャーがある中で、きちんとハードウェア起因であることを調査・公開した誠実さは評価したい。 それよりも問題なのは、このIntel Raptor Lakeの不具合がいまだに多くの現場で放置されているという現実だ。2024年8月にマイクロコードパッチが出てからすでに相当の時間が経過しているが、BIOSアップデートが展開されていない企業PCは日本でも相当数あるはずだ。「今のところ大きなトラブルが起きていないから」という判断は、今回のFirefoxクラッシュのように突如として問題が顕在化するリスクを抱えたままにしておくことを意味する。 ゼロトラストやエンドポイントセキュリティを強化しても、CPUレベルで演算ミスが起きているハードウェアの上で動かしているのでは基盤が揺らいでいる。ファームウェア管理は地味だが、インフラの基礎体力に関わる重要な作業だ。「今動いているから大丈夫」は今後も通用しないことをあらためて思い知らされる事例だった。 出典: この記事は Mozilla explains Firefox crashes on Intel 13th, 14th Gen Raptor Lake systems の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米テクノロジーメディア・Tom’s GuideのHow-ToエディターKaycee Hill氏が2026年5月21日に公開した記事が、iPhoneユーザーの間で静かな反響を呼んでいる。Safariの設定深部に隠れた「バックグラウンドでリンクを開く」機能が、日常的なブラウジング体験を大きく変えるというものだ。 なぜこの機能が注目されているのか iPhoneでSafariを使っているとき、リンクをタップするたびに読んでいたページを離れてしまう——この挙動は多くのユーザーが長年感じてきた不満だ。商品を比較しながら調べるとき、引用元を確認しながら長文記事を読むとき、タブを行き来するたびに読書の流れが途切れる。 Kaycee Hill氏の記事によると、実はこの問題は設定画面のひとつのトグルで解決できる。Appleが積極的に宣伝することもなく搭載しているこの機能は、知っているかどうかだけで体験が大きく変わるという点で「隠れた優良機能」の筆頭格だ。 設定方法と使い方 Tom’s Guideが紹介している手順は以下の通り。 設定アプリ を開く Safari をタップ 下にスクロールして 「タブ」 セクションを探す 「リンクを開く」 をタップ 「新規タブで開く」から 「バックグラウンド」 に切り替える これだけで、リンクをタップしても現在のページから離れることなく、バックグラウンドで新しいタブが静かに読み込まれるようになる。読み終えたタイミングで画面下のタブ一覧アイコンをタップすれば、開いたタブが整然と並んで待っている。 2本指タップでさらに快適に Hill氏が紹介しているもうひとつのポイントが 2本指同時タップ のショートカットだ。設定を有効にした状態でリンクを2本指でタップすると、長押しメニューを経由せずに直接バックグラウンドタブとして開ける。リサーチ作業の速度がもう一段上がる操作だ。 海外レビューのポイント Kaycee Hill氏は、この機能が特に効果を発揮するシーンとして以下を挙げている。 評価できる点: 商品比較購入に最適。比較したい製品をバックグラウンドタブで次々と開き、準備ができたら一気に読み比べられる 引用・注釈が多い長文記事の閲覧が格段に楽になる 複数の情報源を横断しながら調査する際の集中力が維持される 2本指タップというショートカットが操作性をさらに高めている 気になる点: Tom’s Guideの記事内では特段のデメリットは挙げられていないが、バックグラウンドで多数のタブを開き続けることによるメモリ消費は実際の利用では意識する必要があるだろう 日本市場での注目点 この機能はiOS標準機能であるため、iOS 15以降を搭載したiPhone全般で追加アプリ不要・無料で利用できる。設定を一度変えるだけで即日有効になる点も敷居が低い。 注目したいのは、Androidの標準ブラウザ（Chrome）ではこのバックグラウンド挙動がデフォルトである点だ。「AndroidからiPhoneに乗り換えてSafariが使いにくくなった」と感じていたユーザーにとっては、この設定変更が乗り換えの不満を一気に解消する可能性がある。 日本の法人・ビジネスパーソン用途でも、複数資料を参照しながら作業するシーンは多い。スマートフォン単体でのリサーチを行う機会が増えている昨今、この設定の有無は作業効率に直結する。 筆者の見解 Appleはユーザー体験へのこだわりで知られているが、今回のケースは「発見性（ディスカバラビリティ）」の課題を改めて浮き彫りにしている。多くのユーザーが長年不便と感じてきた挙動が、実は設定ひとつで変えられたという事実は、機能の存在を伝える仕組みがまだ不十分であることを示している。 一方で、こうした「知っている人だけが得をする機能」は、iOSに限らずあらゆるプラットフォームに存在する。Tom’s GuideのKaycee Hill氏のような専門ライターが地道に掘り起こして可視化することの価値は小さくない。 テクノロジーの恩恵を最大限に引き出せるかどうかは、ツールの存在を「知っているか」にかかっていることが多い。基本的な操作に見えても、設定ひとつで体験が変わるこの種の情報こそ、日々の生産性に直結する実用的な知識だ。 関連製品リンク Apple iPhone 16 Pro (1 TB) - ブラックチタニウム SIMフリー 5G対応 ...

Microsoftは2026年5月19日、同社のコード署名サービス「Azure Artifact Signing」を悪用してマルウェアに正規証明書を付与する「マルウェア署名代行サービス（MSaaS）」を運営していた脅威グループ「Fox Tempest」の活動を摘発・無効化したと発表した。 Azure Artifact Signingの悪用という巧妙な手口 Azure Artifact Signing（旧称：Trusted Signing）は、Microsoftが2024年に開始したクラウドベースのコード署名サービスだ。開発者が自分のプログラムをMicrosoftのインフラ上で簡単に署名できる仕組みで、正規の開発者にとっては利便性の高いサービスである。 Fox Tempestはこのサービスを不正に利用し、マルウェアにMicrosoft由来の正規コード署名証明書を付与することで、Windowsのセキュリティ機能やエンドポイント保護を回避していた。署名されたマルウェアはMicrosoft Teams、AnyDesk、PuTTY、Webexなどの正規ソフトウェアになりすまし、被害者がダウンロード・実行するよう誘導された。 特に巧妙だったのが「有効期間72時間の短命証明書」の活用だ。長期証明書は証明書失効リストに載るリスクがあるが、72時間以内に攻撃を完結させれば証明書が有効なまま悪用できる。グループは1,000件以上の証明書と数百のAzureテナント・サブスクリプションを量産することで、大規模かつ持続的な攻撃インフラを構築していた。身元確認をくぐり抜けるため、米国・カナダの盗用されたIDが利用された疑いがあるとされている。 関連するマルウェア・ランサムウェアの全容 今回摘発された活動は、複数の悪名高いマルウェアキャンペーンと関連していることが明らかになっている。 情報窃取系: Lumma Stealer、Vidar、Oyster（ローダー） ランサムウェア: Rhysida、Akira、INC、Qilin、BlackByte 攻撃に関与した脅威グループとして、INC Ransomwareメンバーを含む「Vanilla Tempest」、Storm-0501、Storm-2561、Storm-0249が特定されている。 典型的な感染チェーンは次の通りだ：偽のMicrosoft Teamsインストーラーを実行 → 悪意のあるローダーが起動 → 署名済みOysterマルウェアがインストール → 最終的にRhysidaランサムウェアが展開される。Windowsが「正規ソフトウェア」と認識することで、通常であればブロックされるはずのマルウェアが初期段階をすり抜けるという構造だ。 Microsoftの対応措置 Microsoftは今回、以下の措置を実施した。 1,000件超のコード署名証明書を失効処理 signspace[.]cloudドメインを押収 数百台の仮想マシンをオフライン化 犯罪プラットフォームへのアクセスをブロック ニューヨーク南部地区連邦地方裁判所に法的措置（Vanilla Tempestを共謀者として名指し） 押収されたドメインはMicrosoftの公式説明ページにリダイレクトされており、摘発の内容が一般公開されている。Microsoftのデジタル犯罪対策部門（DCU）が業界パートナーと連携して実施した今回の作戦は、インフラ破壊から法的措置まで包括的な対応となっている。 実務への影響：日本のエンジニア・IT管理者が今すぐ確認すべきこと エンドポイント保護の見直し コード署名だけを信頼の根拠にしてはいけない。今回の事件は、署名証明書が比較的容易に不正取得・悪用できることを改めて示した。Windows Defender / EDR製品の振る舞い検知を有効化し、署名済みファイルであっても動的解析を通過させる設定を確認したい。また、Microsoft TeamsなどのアプリケーションはMicrosoft StoreまたはIntuneを通じた組織配布経路からのみインストールを許可するポリシーの導入を検討すべきだ。 Azure環境のガバナンス 自社テナントでAzure Artifact Signingを利用している場合、証明書発行ログを定期的に確認する習慣をつけたい。また、不審なAzureテナントやサブスクリプションの作成を検知するためのMicrosoft Defender for Cloudのアラート設定も見直す価値がある。 ユーザー啓発 「Microsoftの署名があるから安全」という思い込みは今回で完全に否定された。エンドユーザー向けのセキュリティ教育において、この点を明確に伝える必要がある。 筆者の見解 今回の件を見て、「よくやった」と「なぜここまで見逃したのか」が同時に頭をよぎった。 コード署名という信頼の根幹をなすインフラを不正利用され、1,000件超の証明書が発行されるまで検知・停止できなかった事実は軽視できない。「Microsoftの署名 ＝ 安全」という前提が攻撃者に徹底的に利用された形であり、正直なところもったいないと感じる。Azure Artifact Signingの設計には、このような大量不正発行を早期に検知するための仕組みが不十分だったということだ。 その一方で、DCUが法的措置を含む大規模な摘発に踏み切ったことは素直に評価したい。インフラ破壊だけでなく、裁判所への提訴とVanilla Tempestへの共謀者認定まで踏み込んだ姿勢は、業界全体への抑止効果をもたらすはずだ。 今回の根本的な教訓は「署名ベースの信頼モデルには限界がある」という点に尽きる。ゼロトラストアーキテクチャの観点では、コード署名はあくまで信頼判断の「ヒントの一つ」であって、それだけで実行許可を与えてはいけない。振る舞い検知、最小権限の実行環境、ネットワーク通信の監視——これらを組み合わせた多層防御が今こそ不可欠だ。 Microsoftにはぜひ、今回の経験をサービス設計にフィードバックしてほしい。「次に同様の悪用が始まったら数日以内に止められる」というレベルの検知・対応品質向上を、応援する立場として強く期待している。 ...

Microsoft（マイクロソフト）が、Teams（チームズ）サポートチームに寄せられる「最も対処が厄介な問題」のひとつについて、その原因と解決策を公式に説明した。多くのユーザーやIT管理者を長年悩ませてきたこの問題に、シンプルな修正方法があることが明らかになった。 「よくある、でも解決しにくい」Teamsの問題とは Microsoft Teamsのサポートチームが「最もフラストレーションを引き起こす」と表現する問題群の多くは、アプリのキャッシュ破損や設定ファイルの不整合に起因することが多い。具体的な症状としては： メッセージや通知が正しく表示されない プレゼンス（在席状況）が更新されない・誤った状態で表示される 会議への参加が遅くなる、または接続が不安定になる 再インストールしても問題が再現する これらの問題に共通しているのが「再起動しても直らない」という点だ。多くのユーザーがアプリを再起動しても改善せず、最終的にIT部門に問い合わせる流れになる。 Microsoftが説明する根本原因と修正手順 Microsoftのサポートチームが公式に示したのは、Teamsのキャッシュを手動でクリアするというシンプルな手順だ。ただし、単純に「キャッシュを削除」と言っても、正しい手順を踏まないと解決しない場合がある。 Windows版 Teams（新Teams）のキャッシュクリア手順 Microsoft Teamsを完全に終了する（タスクトレイのアイコンも右クリックで「終了」） Win + R でファイル名を指定して実行を開く %appdata%\Microsoft\Teams を入力してEnter フォルダ内の以下のサブフォルダを削除（フォルダ自体は残す）: Cache blob_storage databases GPUCache IndexedDB Local Storage tmp Teamsを再起動し、サインインし直す 新しいTeams（Teams 2.0）の場合は、アプリ上部の「…」メニューから設定を開き、「アプリのキャッシュをクリア」オプションを使う方法もある。 なぜ「再インストールだけでは直らない」のか 多くの場合、再インストールはアプリの実行ファイルだけを置き換えるため、ユーザープロファイルフォルダ内に残ったキャッシュや設定ファイルがそのまま引き継がれる。これがTeams問題の「再インストールしても再現する」という特性の原因だ。 特に企業環境では、複数のMicrosoftアカウントや条件付きアクセス（Conditional Access）ポリシーが絡み合うことで、キャッシュの不整合が発生しやすい。リモートワーク環境でネットワーク切り替えが頻繁に起きると、さらに問題が起きやすくなる。 IT管理者・エンジニアへの実務ポイント ヘルプデスク対応の効率化に直結する この手順をナレッジベースに登録しておくことで、一次サポートで解決できるケースが大幅に増える。「Teamsの動作がおかしい」と問い合わせが来た際に、まずキャッシュクリアを試してもらうトリアージフローを作成しておくと効果的だ。 エンドポイント管理（Intune等）での自動化 Microsoft Intuneを使って管理されている端末であれば、PowerShellスクリプトでキャッシュクリアを自動実行する仕組みを組み込むことも可能だ。問題が頻発するユーザーグループに対してスクリプトをプッシュ配布する運用も現実的な選択肢になる。 新Teamsへの移行完了を確認する 従来の「クラシックTeams（Teams 1.0）」はすでにサポートが終了している。まだ旧Teamsを使っている環境がある場合、今回のような問題以外にも多くの既知不具合を抱えたまま使い続けることになる。この機会に組織内の移行状況を確認することを勧める。 筆者の見解 Teamsは今や日本企業の多くで業務インフラの中核を担っている。その重要性が高まっているからこそ、「再起動しても直らない」「再インストールしても再現する」という問題は現場の生産性に直結するダメージを与え続けてきた。 Microsoftがこうした「サポート現場の定番問題」について公式に発信し、ナレッジを整理してくれることは、IT部門にとって素直に助かる動きだ。 とはいえ、本来であればキャッシュ破損がここまで頻繁に起きること自体、アプリの堅牢性として改善の余地がある。ユーザーが手動でキャッシュを削除しなければならない状況が「よくある問題」として定番化してしまっているのは、決して望ましい状態ではない。 MicrosoftはTeams 2.0への移行でアーキテクチャを刷新しており、この点の改善を期待している。ユーザーがアプリの内部構造を意識せずに使えるようになってこそ、真の「使いやすいコラボレーションツール」と言えるはずだ。Teamsが持つポテンシャルは本物だから、そこに見合った安定性を追求し続けてほしい。 企業のIT担当者は、今回の手順をヘルプデスクの標準フローに組み込みつつ、チケット数の推移を観察しておくと良いだろう。もしキャッシュクリアで解決しないケースが多発するようなら、ネットワーク設定や認証基盤側の問題を疑う必要がある。 出典: この記事は Microsoft explains simple fix for one of the most “frustrating” Teams issues の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は 2026年5月14日のメッセージセンター通知（MC1310672）で、Search-UnifiedAuditLog PowerShell コマンドレットの動作変更を発表した。新プロパティ AuditSearchRequestMetadata.moreRecordsAvailable が追加され、最大50,000件の監査レコードを取得する大規模検索がより正確に制御できるようになる。世界商用テナントへの展開は2026年5月末を目標に進行中で、政府クラウドは2026年6月に対応予定だ。 何が変わったのか ResultCount プロパティの仕様変更（既存スクリプトへの影響大） 従来、ResultCount プロパティは「その検索で返されるレコードの総数（見込み件数）」を示していた。今回の変更後は 「取得済みレコードの累積数（ランニングカウント）」 に意味が変わった。 ResultCount を使って「全レコードを取り終えたかどうか」を判定しているスクリプトは、今回の変更で動作が変わる。Microsoft Sentinel や Splunk への定期エクスポートなど、本番運用スクリプトを持つ環境では早急な確認が必要だ。 新プロパティ: moreRecordsAvailable 代わりに使うべき新プロパティが AuditSearchRequestMetadata.moreRecordsAvailable だ。 false → 条件に一致する追加レコードなし（取得完了） true → まだ取得すべきレコードが残っている シンプルなブール値で終了判定ができるため、ループ制御がより明示的かつ堅牢になる。 実装例：moreRecordsAvailable を使った大規模検索 出典: この記事は Search-UnifiedAuditLog Updated to Make Large Searches Easier to Manage の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Broadcomは2026年5月、macOS向け仮想化ソフトウェア「VMware Fusion Pro 26H1」をリリースした。Apple Silicon（ARM）環境でのESXiゲストOSサポートの追加、Linux系ゲストOSの互換性拡張、そして深刻なセキュリティ脆弱性の修正が今回の主な変更点だ。 ARM ESXiゲストサポートが意味すること 今回の目玉機能は、Apple Silicon Mac上でVMware ESXiをゲストOSとして動作させる「ARM ESXサポート」だ。これはvSphereやESXiを扱うインフラエンジニアにとって重大なアップデートとなる。 これまでApple SiliconのMacユーザーがESXiの検証をしようとすると、x86ベースのマシンを別途用意するか、クラウド上に環境を構築するしかなかった。ARM ESXIゲスト対応により、M1/M2/M3/M4チップを搭載したMacBook ProやMac miniの上で、直接ESXiの動作検証やラボ環境構築が可能になる。 ただし注意点がある。ARM版ESXiはIntel版と完全に同じではなく、ゲスト側のARMネイティブ対応状況やNIC・ストレージドライバーの差異が存在する。あくまで「ラボ・検証用途」として捉えるのが現実的な使い方だ。 拡充されたLinuxゲスト互換性 26H1では、Linuxゲストの互換性リストが更新された。具体的に対応が強化されたのは以下のディストリビューションだ（Fusionのリリースノートに基づく）： Ubuntu 24.04 LTS（Noble Numbat）の正式サポート強化 Debian 13（Trixie）系列の追加対応 RHEL/AlmaLinux/Rocky Linux 9.x 系の最新マイナーバージョン追従 Kubernetesやコンテナ開発用途でmacOSをメインに使いながらLinux VMを日常的に動かしているエンジニアには、アップデートの恩恵を感じやすい変更だ。 重大なセキュリティ修正 今回のリリースで特に注目すべきは「major security fix」の存在だ。BroadcomのセキュリティアドバイザリによりCVEが割り当てられている場合、VMインスタンスの隔離境界に関わるホスト側への影響（VM Escape系）の可能性もある。 Fusion Proを業務環境で使っているユーザーは、セキュリティ修正の詳細をBroadcomのリリースノートで確認し、できるだけ早期にアップデートを適用することを強く推奨する。「VMはゲストだから安全」という発想はVM Escapeの脅威を考えれば成立しない。ホストOS同様の感度でパッチ適用を習慣にしたい。 実務への影響と活用ポイント インフラ・VMwareエンジニア向け: Apple Siliconが普及した現在、開発マシンがARMアーキテクチャに移行している組織では、「Mac上でESXiをテストしたい」というニーズは確実に増えている。ARM ESXiゲスト対応はそのギャップを埋める現実的な手段になる。vSphere環境の設計検証や新機能の事前確認に活用できる。 開発者向け: Docker Desktopと比較してもVMware Fusionはネットワーク構成の自由度が高く、複数VMでのネットワークトポロジー再現が得意だ。マルチノード構成の検証や、本番に近い環境でのテストが必要な場面ではFusionが有利なシーンも多い。 IT管理者向け: Fusion Proはライセンス形態がBroadcomの再編以降に変化しており、無料化された個人利用枠と有償の商用枠が整理されている。社内への展開を検討している場合は、最新のライセンス条件を確認した上で計画を立てることを勧める。 筆者の見解 VMware FusionはmacOS上の仮想化ソリューションとして、長年の実績を持つ信頼性の高いツールだ。BroadcomによるVMware買収後、価格体系や製品ラインアップが大きく変わったことで一時は混乱もあったが、Fusion Proの継続的な機能強化は歓迎できる。 ARM ESXIゲスト対応は、Apple Siliconへの移行が進む国内のIT現場でも実用的な価値がある。ただし、VMの検証環境はあくまで「道具」であって、本番相当の構成テストは相応のハードウェアで行うという基本は変わらない。 セキュリティ修正については、多くのエンジニアが「仮想マシン環境だから」と過信しがちな点でもある。ホストとゲストの境界は完全無敵ではない。パッチ適用の優先度はホストマシンと同等に扱うべきだというのが個人的な一貫したスタンスだ。アップデートを後回しにしないこと、これに尽きる。 出典: この記事は VMware Fusion Pro 26H1 released with support for more guest OSes の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年5月のSAP Sapphireカンファレンスにて、SAPとAnthropicは戦略的提携を正式発表した。AnthropicのAIモデル「Claude」が持つエージェンティックAI機能を、SAPが新設した「SAP Business AI Platform」に組み込み、SAPの全AI製品ポートフォリオに展開する計画だ。 SAP Business AI Platformとは何か SAP Business AI Platformは、SAPがビジネスアプリケーション向けに構築するAIインフラ基盤だ。財務・人事・サプライチェーン・調達といった基幹業務領域に、AI機能を統合的に提供するためのプラットフォームとして位置づけられている。 これまでSAPは自社AIアシスタント「Joule」を中心にAIを展開してきた。今回の提携でAnthropicのClaudeを採用することで、エージェンティックAIの高度な推論・計画・実行能力をSAPのビジネスプロセス全体に活用できるようになる。 「エージェンティックAI統合」の技術的な意味 「エージェンティックAI」とは、単純な質疑応答ではなく、目的を与えられると自律的に計画を立て、複数のステップを実行し、結果を検証するAIの動作様式を指す。 従来のERP × AIの統合は「チャットボットでデータを検索する」レベルに留まることが多かった。今回の提携が目指すのはその先だ。たとえば「月次決算の異常値検知 → 関係者へのアラート → 修正仕訳の提案 → 承認ワークフローの起動」といった一連のプロセスを、AIが自律的に進める仕組みの実現だ。ERPをAIのデータソースとして使うのではなく、ERPのビジネスプロセス自体をAIが動かすという設計思想の転換である。 日本企業への実務的影響 日本の大手・中堅企業の多くがSAPを基幹システムとして利用している。今回の統合は、これらの企業にとってAI活用の入口を大きく変える可能性がある。 具体的な活用ポイント： 会計・財務自動化の高度化：月次・四半期決算プロセスにおける例外処理や仕訳確認をAIエージェントが担当し、人間は例外の最終判断に集中できる。 サプライチェーン最適化：需要予測の外れ値発生時に、AIエージェントが自動で調達計画を見直し、サプライヤーへの発注調整まで一気通貫で実行できる。 HR業務の効率化：採用・育成・異動のサイクルでデータドリブンな意思決定をAIが支援し、HRBPが戦略的な仕事に集中できる環境を作る。 BTP（SAP Business Technology Platform）との統合：既存のBTP環境を持つ企業は、追加インフラなしにClaudeベースのエージェンティック機能を試験導入できる可能性がある。 今すぐできる準備 発表を受けて、今動けるアクションを整理しておきたい。 SAP S/4HANA Cloud利用企業：Sapphireで発表された詳細なロードマップをSAPパートナーに確認し、テナントへの展開時期を把握しておく。 オンプレミスSAP利用企業：クラウド移行の優先度を再評価するタイミングかもしれない。AI統合の恩恵はクラウド版から先に届く。 IT部門・SAP管理者：エージェンティックAIが自動実行できる業務スコープの洗い出しと、必要な承認フローの設計を今のうちに始める。 筆者の見解 今回の発表で注目したいのは、「ERPをAIのデータソースにする」のではなく「ERPのビジネスプロセス自体をAIが動かす」という設計思想への転換だ。AIエージェントが自律的にループで動き続ける仕組みこそが次のフロンティアだと考えているが、それをERPという企業の基幹データと業務プロセスに組み込むという方向性は理にかなっている。 日本企業にとって現実的な課題は、「AIに何を自動化させてよいか」というガバナンスの設計だ。すべてを人間が承認し続ける設計ではエージェンティックAIの本質的なメリットを得られない。一方で、何でも自動化すれば統制が崩れる。この境界線を業務ごとに定義してドキュメント化しておくことが、今すぐ取り組むべき準備だと感じている。 SAP Sapphireでの発表は方向性を示したものであり、具体的なロードマップが出てから本評価になる。大きな方向性は正しい。日本企業の現場がこの波に乗り遅れないよう、まずは自社のSAP活用状況の棚卸しから始めることをお勧めしたい。 出典: この記事は SAP and Anthropic: Claude on SAP Business AI Platform | SAP Sapphire の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Microsoft Planner の大規模刷新を2026年に実施する。タスクへのチャット機能、カスタムテンプレート、Copilot AI統合の3つの新機能を追加する一方、iCal（iCalendar）フォーマットのサポートを廃止する予定で、カレンダー連携を利用しているユーザーは早急な移行対応が求められる。 Microsoft Planner 2026年刷新の全容 タスクチャット機能 新たに追加される「Task Chat（タスクチャット）」は、各タスクの中でメンバーと直接会話できる機能だ。これまでPlannerを使うチームは、タスクの詳細について別途Teamsのチャットやメールでやりとりしなければならず、「どのタスクについての話か」という文脈がすぐに失われる課題があった。 タスクチャットが実装されることで、タスクとコミュニケーションが一体化される。誰が何を発言したかの履歴がタスクに紐づいて残るため、後から参加したメンバーがキャッチアップしやすくなる点もメリットだ。 カスタムテンプレート 「Custom Templates（カスタムテンプレート）」機能により、組織独自のプロジェクト計画テンプレートを作成・保存・再利用できるようになる。毎回ゼロから作っていたプロジェクト計画をテンプレート化することで、スタート時のセットアップ工数を大幅に削減できる。特に繰り返し型のプロジェクト（月次業務、リリースサイクル管理など）を多く抱えるチームには即効性が高い機能だ。 Copilot AI統合 Copilot AI との統合により、タスクの提案、進捗のサマリー、次のアクション自動生成といった機能が Planner 内に統合される予定だ。プロジェクト管理の定型的な判断をCopilotが補助する形となる。 iCalサポートの廃止 特に注意が必要なのが「iCal（iCalendar）フォーマットのサポート廃止」だ。PlannerのタスクをGoogleカレンダーやAppleカレンダーへ購読するために使われてきたiCal形式のURLのサポートが終了する。既存の購読リンクは無効になるため、現在利用しているユーザーは代替手段への移行が必要になる。 日本のエンジニア・IT管理者が今すぐやるべきこと iCal廃止への対応（最優先） iCalの購読リンクを社内でどこが利用しているかを今すぐ調査してほしい。特に以下のシナリオで使われているケースが多い： 外部ツール連携: GoogleカレンダーやAppleカレンダーとPlannerを連携している 社内ダッシュボード: Power BIや社内ポータルにPlannerのタスクをカレンダー表示している サードパーティ製PMツール連携: iCalフィードを受け取るタイプのツールとの連携 廃止前に代替手段（Microsoft Graph API経由のカレンダー連携、Outlookカレンダーとの直接同期）を検証し、移行計画を立てることを強くお勧めする。 タスクチャットの活用ルールを先に決める タスクチャットはTeamsのチャットとの住み分けが鍵になる。「プロジェクトのタスクに関する会話はPlannerのタスクチャットへ」「日常的な雑談や素早い確認はTeams」という使い分けをチーム内でルール化することで、情報の散逸を防ぐことができる。機能がリリースされてから「どこに書けばいいのか」が曖昧になるよりも、事前にルールを決めておく方が定着は早い。 テンプレート整備の準備を今から カスタムテンプレート機能がリリースされた際にすぐ活用できるよう、「自チームで繰り返し使っているプロジェクト計画の型」を今のうちに洗い出しておこう。候補リストを準備しておくだけで、機能リリース直後から業務効率を引き上げるスピードが変わる。 筆者の見解 今回のPlannerの刷新は、Microsoft が「タスク管理をTeams・Outlook・Loopと統合された体験にしていく」という方向性の一環として見ている。タスクチャットはその象徴的な機能で、バラバラになりがちなコミュニケーションとタスクを一体化する方向性は正しい。 Copilot AI統合については、正直なところ「どこまで実用的になるか」を見極める段階だ。タスク管理AIに本当に必要なのは機能の網羅性よりも「現場で使い物になる精度」だと思っている。Microsoftにはその技術力があるはずで、具体的なシナリオで精度を出せるかどうかに注目したい。 iCalの廃止は移行コストが発生するのは避けられないが、長期的にはMicrosoft 365エコシステム内で一貫した連携体験に集約されていく方が全体最適につながる。「標準の仕組みで動いている前提」を崩さないよう、移行は計画的に進めてほしい。 Plannerはこれまで「軽量タスク管理ツール」として中途半端な立ち位置にあった印象があるが、今回の刷新でTeams・Outlook・Loopとの統合が深まれば、Microsoft 365の中核的なワークフロー基盤になり得る可能性を秘めている。その可能性を本当に引き出せるかどうか、今後のロードマップに注目している。 出典: この記事は Microsoft Planner 2026 Overhaul: Task Chat, Custom Templates, Copilot AI, iCal Retirement の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月14日、米テクノロジーメディア「Tom’s Guide」のUK編集長Jeff Parsonsが、GoogleがAndroidの「Quick Share」機能を通じたAirDropサポートをさらに多くの機種へ拡大すると報じた。AndroidユーザーがiPhoneやMacユーザーと直接ファイル共有できるようになるこの機能は、エコシステムの壁を越えた実用的なアップデートとして注目を集めている。 AndroidとiOSの壁を低くするQuick Shareの進化 Androidユーザーにとって、iPhoneやMacユーザーとのファイル共有は長年の悩みの種だった。Googleはこれまでにもサムスンと協力してNearby Share（後にQuick Shareに統合）を整備してきたが、今回はAppleのAirDropとの直接共有というさらに踏み込んだ対応を進めている。 すでにPixel 10やGalaxy S26シリーズなどの最新フラッグシップではこの機能が利用可能だが、今回の拡大は「1〜2世代前の端末を引き続き使っているユーザー」を救うものだ。 新たにAirDrop対応となる機種一覧 Tom’s Guideの報道によると、以下の機種が間もなく対応する見込みだ。 Samsung Galaxy Galaxy S25 / S25+ / S25 Ultra Galaxy S24 / S24+ / S24 Ultra Galaxy Z TriFold Galaxy Z Fold 7 / Z Flip 7 Galaxy Z Fold 6 / Z Flip 6 その他メーカー Oppo Find X8 / Find X8 Pro OnePlus 15 Honor Magic V6 / Magic 8 Pro 注目すべき「対応外」の機種——Pixel 8の謎 Tom’s GuideのParsonsが記事内で特に指摘しているのが、Pixel 8 / Pixel 8 Proがリストに含まれていないという点だ。Pixel 9シリーズやPixel 8aはすでに対応しているにもかかわらず、同世代に近いPixel 8系が除外されている。Parsonsは「ハードウェアは類似しているだけに、奇妙な選択だ」と評し、Googleが何らかの別の理由で除外している可能性を示唆している。 ...

Anthropicは2026年5月14日、大規模コードベースにおけるClaude Codeの動作原理とエンタープライズ向けベストプラクティスをまとめた記事を公開した。数百万行規模のモノリポ、数十年にわたって積み重なったレガシーシステム、数十のマイクロサービスにまたがる分散アーキテクチャ——そのいずれでもClaude Codeは本番運用されており、成功事例に共通するパターンが存在するという。 Claude Codeの「ナビゲーション」はエンジニアと同じ思考プロセス Claude Codeが大規模コードベースを探索する方法は、熟練エンジニアの思考プロセスに近い。ファイルシステムを走査し、ファイルを読み込み、grepで必要なものを探し、コードベース全体を横断しながら参照を追う。インデックスの事前構築も、サーバーへのアップロードも不要で、開発者のローカルマシン上で完結する。 これはRAG（Retrieval-Augmented Generation）ベースのAIコーディングツールとは根本的に異なるアプローチだ。RAGはコードベース全体を埋め込みベクトル化し、クエリ時に関連チャンクを取得する仕組みだが、アクティブな開発チームのペースには追いつけないという本質的な限界がある。 2週間前にリネームされた関数、先のスプリントで削除されたモジュール——RAGのインデックスはこうした変更を遅れて反映するため、検索結果に「すでに存在しないコード」が平然と現れる。Claude Codeのエージェント型検索はこの問題を構造的に回避する。中央集権的なインデックスがないため、数千人のエンジニアが新しいコードをコミットし続けても、各開発者のインスタンスは常にライブのコードベースと向き合える。 ただし、トレードオフもある。Claude Codeは「どこを見ればよいか」の初期コンテキストが充実しているほど精度が上がる。10億行規模のコードベースで漠然としたパターン検索を依頼すれば、作業開始前にコンテキストウィンドウの限界に到達してしまう。コードベースのセットアップへの投資が結果の質を左右する所以だ。 「ハーネス」がモデル性能を決める Claude Codeに関してよくある誤解は、その能力がモデルのスペックだけで決まるという思い込みだ。しかし実際には、モデルの周囲に構築されるエコシステム——ハーネス——がパフォーマンスを決定的に左右する。 ハーネスは5つの拡張ポイントで構成される： CLAUDE.mdファイル — コードベースやプロジェクトの文脈をClaude Codeに伝えるドキュメント フック（Hooks） — 特定のイベントをトリガーにして自動実行されるカスタム処理 スキル（Skills） — 繰り返し使う複雑なタスクを抽象化したモジュール プラグイン（Plugins） — ツールや機能を追加する拡張機能 MCPサーバー — 外部ツール・APIとの統合レイヤー これらの拡張ポイントは積み重ね型で、各レイヤーが前のレイヤーを土台にして機能する。CLAUDE.mdによるコンテキスト付与が土台となり、その上にフックやスキルが乗る設計だ。 Anthropicは今回の記事をエンタープライズ向けシリーズ「Claude Code at scale」の一環として位置づけており、C、C++、C#、Java、PHPなどのレガシー言語環境でも最近のモデルリリースにより予想以上の性能を発揮していると述べている。 実務への影響：日本のエンジニア・IT管理者へ CLAUDE.mdに投資することが最初の一手 Claude Codeを大規模環境で導入する際、最も費用対効果が高い初期投資はCLAUDE.mdの整備だ。プロジェクトのルート、各サブディレクトリ、チームのコーディング規約——これらの情報をCLAUDE.mdに記述することで、Claude Codeが「どこから探索を始めればよいか」を理解できるようになる。 インデックスレスの設計は「モノリポ問題」への有力な解答 日本の大手SIerや事業会社には、長年にわたって肥大化したモノリポや、部門ごとに乱立したリポジトリ群を抱えるケースが多い。RAGベースのツールがインデックス更新の遅延に悩む環境では、Claude Codeのエージェント型アプローチが実用的な選択肢になりうる。 ハーネスの設計はアーキテクチャの仕事 フック・スキル・MCPサーバーの組み合わせは、単なる設定ファイルではなくシステムアーキテクチャの一部だ。これらの設計をエンジニアリングチームのプロセスに組み込めるかどうかが、AI活用の成否を分ける。 筆者の見解 今回Anthropicが公開した内容で最も重要なポイントは、「モデルの賢さよりハーネスの設計が結果を決める」という事実の明示だ。これはある意味、AI活用の民主化とは逆の方向性を示している——道具が賢くなるだけでは不十分で、道具を囲む仕組みを設計できるエンジニアリング能力が問われるということだ。 特に注目すべきはハーネスループの考え方だ。CLAUDE.mdで文脈を与え、フックで自動化のトリガーを設け、スキルで複雑なタスクを抽象化する——この積み重ねが、Claude Codeを「単発の指示に応えるツール」から「自律的に判断・実行を繰り返すエージェント」へと変貌させる。自律的なループを設計できるかどうかが、AI活用の深さを決める。 日本の開発現場では、「AIツールを入れたけど思ったより使えなかった」という経験をした組織が少なくないだろう。多くの場合、それはツールの限界ではなくハーネスへの投資不足の問題だ。CLAUDE.mdを書き、フックを整備し、チームの作業パターンをスキルとして抽象化する——この地道な積み上げこそが、大規模コードベースでのAI活用の鍵になる。 エンタープライズシリーズとして今後も知見が公開される見込みで、大規模開発組織にとって参照すべき一次情報になっていくだろう。 出典: この記事は How Claude Code works in large codebases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月中旬から7月末にかけて、SharePointのユーザーインターフェースを大幅に刷新した「新SharePointエクスペリエンス」を段階的に展開する。アプリバーの全面再設計と開始ページの刷新が目玉で、AIを活用したコンテンツ作成支援機能も同時に提供される。 新アプリバーの構成：5つのアイコンで業務を整理 新しいSharePointアプリバーには、左端から以下の5つのアイコンが並ぶ。 組織のホームサイト：グローバルナビゲーションが設定されている場合のみ表示。イントラネットのトップページへのクイックアクセスとして機能する Discover：自分に関連するサイト・コンテンツ・ニュースをパーソナライズして表示するビュー Publish：組織全体に向けたコミュニケーションやページを作成・共有するための拠点 Build：サイト・リスト・ドキュメントライブラリ・エージェントを作成・管理する場所 OneDrive：個人ファイルへのクイックアクセス 現行のアプリバーと比べると、機能ごとの役割分担が明確になっている。特に「Publish」と「Build」の分離は、コンテンツを公開する人と、基盤を構築・管理するIT担当者の役割の違いを UI レベルで整理した設計と言える。 AI支援機能：自然言語でグラフ作成、Copilot引用の可視化 今回のリニューアルと同時期に展開される AI 関連機能として、以下の2点が注目される。 AIチャートWebパーツ SharePointページ上で、自然言語の指示からインタラクティブなグラフを生成できる新Webパーツが追加される。データを別ツールに持ち出してグラフ化する手間なく、ページ内で完結できる。 AI Citations Analytics（AI引用分析） 組織内のどのSharePointドキュメントが、Copilotの回答に引用されているかを可視化する機能。「どのドキュメントが実際に使われているか」「古い情報が引用されていないか」を把握するための管理者向けツールとして機能する。 なお、AI支援による作成機能の一部はCopilotプレミアムライセンスが必要となっている点は留意が必要だ。 展開スケジュールと管理者が確認すべきこと 当初は2026年5月上旬からの展開が予定されていたが、現在は2026年6月中旬〜7月末に変更されている。大規模テナントへの展開は遅い方のタイミングになる可能性が高い。 Microsoft 365管理センターのメッセージセンター（MC1240699）および365ロードマップID 547732で展開状況を確認できる。グローバルナビゲーションを設定していないテナントではホームサイトのアイコンが表示されないため、組織ナビゲーションの整備状況も事前に確認しておきたい。 実務への影響：IT管理者・エンジニアが今やるべきこと 1. グローバルナビゲーションの設定状況を確認する 新アプリバーの最初のアイコン（組織ホームサイト）は、グローバルナビゲーションが設定されていないと表示されない。展開前にSharePoint管理センターでホームサイトとグローバルナビゲーションの設定を確認・整備しておくと、ユーザーへの影響を最小化できる。 2. エンドユーザー向けのコミュニケーションを事前に準備する UIが大きく変わるため、「突然変わった」という混乱を避けるためのインターナルコミュニケーションが重要。変更時期のアナウンス、新しいナビバーの使い方説明、Yammer・Teamsでの周知など、展開前に準備を進めておきたい。 3. AI Citations Analyticsでコンテンツ品質を評価する Copilotを導入済みのテナントであれば、AI引用分析は「組織の知識資産のヘルスチェック」として活用できる。引用頻度の高いドキュメントは最新状態に保ち、古い情報が多く参照されていないかを定期的に確認するワークフローを組み込むと良い。 4. Publish/Build の役割分担をチームに周知する 「誰がどのアイコンを使うのか」を事前に整理しておくと、展開後の混乱が減る。コンテンツ編集者は主にPublish、IT管理者・サイトオーナーはBuildを使う、という役割整理をドキュメント化しておくことを勧める。 筆者の見解 SharePointのUI刷新は「ようやく」という印象だ。現行のアプリバーは機能が増えるたびに場当たり的に追加された感があり、初めてSharePointを使うユーザーには直感的ではなかった。Discover・Publish・Buildという役割ベースの整理は、情報アーキテクチャとして正しい方向性だと思う。 AI Citations Analyticsは地味に見えて、実は実用性が高い機能だ。「Copilotが何を参照して回答しているか」はブラックボックスになりがちだった。これが可視化されれば、コンテンツ管理の優先度をデータで判断できるようになる。イントラネット担当者には刺さる機能だろう。 ただ、今回の機能の多くが「Copilotプレミアム必須」という壁に阻まれている点は、正直もったいないと感じる。SharePointはM365の土台であり、AI機能をその土台に統合することはMicrosoftにしかできない強みのはずだ。ライセンスの敷居が高いと、その強みを活かせる組織が限られてしまう。SharePoint自体の競争力を高めるためにも、基礎的なAI統合はより広いライセンス層で使えるように展開を広げてほしいというのが率直な期待だ。 UIリニューアルと合わせて、今こそSharePointのコンテンツ整備・情報設計を見直す好機でもある。展開を待つだけでなく、自組織のSharepoint活用状況をこの機会に棚卸ししてみてはどうだろうか。 出典: この記事は New SharePoint experience (2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。