Tech News JP

Windows Defenderに深刻なゼロデイ脆弱性「BlueHammer（CVE-2026-33825）」が4月7日に公開された。非特権ユーザーがSYSTEM権限を取得できるローカル特権昇格（LPE）の脆弱性であり、完全にパッチを当てたWindows 10・Windows 11の両方が対象になる。さらに今回は孤立した1件ではなく、13日間で3つの関連エクスプロイトが連続公開されるという、これまでにない展開を見せている。 CVE-2026-33825「BlueHammer」の技術的な仕組み 脆弱性の根本原因は、Windows Defenderの脅威対処エンジン（Threat Remediation Engine）に存在するTOCTOU（Time-of-Check To Time-of-Use）競合状態だ。 Defenderがマルウェアを検出してファイルを削除・修復する際、ファイルパスを「チェックしたタイミング」と「実際に書き込むタイミング」の間に微妙なギャップがある。BlueHammerはこのギャップをついて、Defenderが高い特権で操作しようとしていたファイルパスをシンボリックリンクやジャンクションポイントで差し替え、任意のファイルを上書きさせる。結果として非特権プロセスからSYSTEMレベルのコード実行が可能になる。 CVSSスコアは7.8（High）。ローカルでの実行が前提なので「リモートコード実行に比べればまし」と思いたいところだが、社内不正アクセス・フィッシング成功後の権限昇格・サプライチェーン経由のコード実行など、現実のインシデントシナリオでは十分に悪用される攻撃ベクターだ。 「13日間・3エクスプロイト」が示す構造的リスク 今回の最大の論点は、BlueHammer単体ではなく、同時期に公開された3つのエクスプロイトの連鎖にある。 名称 内容 BlueHammer Defenderファイル修復ロジックを悪用したLPE UnDefend Defenderの更新機構を妨害し、保護能力を徐々に低下させる RedSun クラウドタグ付きファイルの処理を悪用した別経路のLPE 攻撃者がBlueHammerで昇格してUnDefendで防御を骨抜きにし、パッチ適用後でもRedSunで再昇格を狙える——というチェーンが成立する。3件をまとめてみると「Defender自体の設計に構造的な問題がある」と指摘せざるを得ない部分がある。セキュリティ製品のコアロジックに競合状態があるという事実は、修正パッチで完全に解消できる類の話ではないからだ。 影響範囲と対処方法 影響を受けるプロダクトは広い。 Windows 10（サポート中の全バージョン） Windows 11（サポート中の全バージョン） Windows Server 2016 / 2019 / 2022 / 2025 Microsoft Defender Antivirus（2026年4月更新以前） Microsoftは4月のPatch Tuesdayで修正パッチをリリース済みだ。優先度を「即時適用」に設定することを強く推奨する。 実務への影響 IT管理者がすぐ確認すべきこと Windows Updateの適用状況を確認する。Defender定義ファイルの更新とは別に、OS本体の4月Patch Tuesdayが必要。WUFBやWSUSで管理している場合、遅延設定が入っていないかチェックしよう。 PoCが公開済みである点を重視する。BlueHammerはコードが出回っており、ツールに組み込まれるまでの時間はそれほどかからない。「うちは内部ネットワークだから大丈夫」という判断は避けたい。内部でのLPEは、BECや内部犯行のシナリオで特に脅威度が上がる。 Defenderだけに依存しない多層防御を確認する。UnDefendの存在が示すように、エンドポイント保護が徐々に無効化されるシナリオが現実的になっている。EDR/XDRの死活監視や、Defender以外のセキュリティレイヤーが機能しているかを今一度点検する価値がある。 特権アカウントのアクセス制御を見直す。LPEが有効な状況では、非特権で動作しているプロセスや自動化スクリプトもSYSTEMに昇格できてしまう。常時付与された特権アカウントがある場合、Just-In-Time（JIT）アクセスへの移行を検討したい。 Windows Updateを「様子見してから当てる」は今回は有効ではない。PoCが出回っているゼロデイである以上、パッチリスクよりも未適用リスクの方がはるかに高い。 筆者の見解 Windowsのセキュリティ改善は、ここ数年で着実に前進してきた。Smart App ControlやカーネルドライバーのPKI要件強化など、アーキテクチャレベルで攻撃面を削る取り組みは正しい方向性だと思っている。 それだけに、今回の「13日間・3エクスプロイト連鎖」という事態は、もったいないと率直に感じる。Defenderは10億台以上のデバイスで動くセキュリティの要であり、そのコアロジックにTOCTOUという古典的な競合状態が存在していたという事実は、品質管理の観点から真剣に受け止めてほしい。 MicrosoftにはDefenderを本物の「プラットフォーム型セキュリティ基盤」として育てる力がある。Sentinelやエンドポイント管理との深い統合、リアルタイムな異常検知のインテリジェンス——そういう方向に本気で投資すれば、「Defenderだから安心」と言えるエコシステムが作れるはずだ。 今回の件を一過性のバグ修正で終わらせず、Defender全体の脅威対処エンジンを見直す契機にしてほしい。それができる組織力があると信じているからこそ、注目し続けている。 とにかくまず、4月Patch Tuesdayを当てよう。それが今できる最善の一手だ。 出典: この記事は BlueHammer & RedSun: Windows Defender CVE-2026-33825 Zero-day Vulnerability Explained の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Kubernetesクラスターのバックアップ設定に、これまで何ステップもかかっていた——そんな運用の煩わしさを、Azureが一気に解消しようとしている。2026年4月16日に公開されたAzureアップデートは、現場のエンジニアにとってすぐに役立つ改善が揃っている。 AKSバックアップがワンコマンドに 最大のトピックは、Azure BackupによるAKS（Azure Kubernetes Service）クラスターのワンコマンドセットアップだ。これまで、AKSクラスターのバックアップを有効化するには複数のリソース設定・権限付与・拡張機能のインストールを順番に実施する必要があり、手順の抜け漏れによる設定ドリフトがしばしば問題になっていた。 今回の更新により、クラスター状態・永続ボリューム・設定情報を一括でキャプチャするバックアップを、単一コマンドで有効化できるようになった。Azure Governmentを含む環境でも対応しており、規制業界や省庁系クラウドを利用している組織にとっても朗報だ。 SRE AgentとAzure Lighthouseで多テナント管理を効率化 マルチテナント環境を管理するMSPやエンタープライズSREチームには、SRE AgentとAzure Lighthouseの組み合わせが注目ポイントだ。テナントをまたいだアクセス委任と運用の一元可視化が可能になり、ポリシー適用の一貫性も向上する。複数の顧客環境を並行管理している運用チームにとっては、管理コストの削減に直結する機能だ。 Smart Tier GAと暗号化制御の独立化 BlobストレージおよびAzure Data Lake Storageのスマート階層化（Smart Tier）が一般提供（GA）に到達した。アクセスパターンを自動分析してデータを適切なストレージ層に移動させることで、コスト削減とレスポンス性の両立を自動で行う。手動ライフサイクルポリシーの管理から解放される効果は大きい。 また、Azure Filesが転送中暗号化設定をプロトコルごとに独立して管理できるようになった。これにより、特定のプロトコルだけ暗号化設定を強化したい場合に、サービス全体の設定を変更せずに対応できる。セキュリティ要件の厳しい環境での柔軟な運用に役立つ。 NVMeディスクのSite RecoveryとAKSネットワーク拡張 NVMeディスクを搭載した高パフォーマンスVMのSite Recovery対応が追加された。AI/MLワークロードや高スループットが求められるシステムのディザスタリカバリ計画を検討している組織には見逃せない対応だ。 AKSのネットワーク面では、StandardV2 NATゲートウェイのサポートとCNI オーバーレイCIDR拡張がプレビューで登場。大規模クラスターにおけるアウトバウンド通信のスケーラビリティ課題に対応するものだ。 実務への影響——日本のエンジニア・IT管理者へ AKSバックアップのワンコマンド化は、今日から使える改善だ。本番AKSクラスターにバックアップを設定できていない、あるいは設定手順が属人化している環境では、この機会に標準化を進めるべきだろう。CI/CDパイプラインにバックアップ有効化を組み込む際のハードルも大きく下がった。 Smart TierのGAについては、ストレージコストの最適化施策として改めて棚卸しの価値がある。アクセス頻度が不明確な大量データを抱えている場合、ライフサイクル設定を手動で維持するよりも自動化された方が長期的なコスト予測が立てやすい。 暗号化の独立設定は、コンプライアンス要件が細かく定義されている金融・医療・公共系の環境で特に重要だ。「全体の設定を変えるとリスクがある」という理由で後回しにされていたセキュリティ強化を、局所的に推進できるようになる。 筆者の見解 Azureはこのアップデートで、「使うのが大変」という運用上の摩擦を着実に減らしている。AKSバックアップのワンコマンド化ひとつとっても、現場のエンジニアが抱えていた手順の煩雑さを正面から解決しようとする姿勢が見える。 Kubernetesは「使いこなせれば強力だが、運用コストが高い」という認識が日本のIT現場ではまだ根強い。しかし今回のような改善が積み重なっていくことで、その認識は確実に変わっていく。AKSを本番に踏み切れていない組織の担当者が、「バックアップがこんなに簡単に設定できるなら」と判断する一押しになり得る。 Azureの強みはプラットフォームとしての総合力だ。Kubernetes管理、ストレージ最適化、ディザスタリカバリ、マルチテナント管理——それらを一貫した基盤の上で扱えることに、今回のアップデートは改めて意味を与えている。個別機能の充実が、全体最適につながる構造だ。 コスト最適化とセキュリティ強化は、どの組織でも永続的なテーマだ。Smart TierとFile Syncの暗号化独立設定はその両方に応えるもので、地味ながら現場インパクトは大きい。「知らなかった」ではなく、今すぐ設計に取り込む価値がある。 出典: この記事は Azure Backup single-command setup for AKS clusters (April 16 Update) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure AI Fundamentals認定資格の中核である試験を、AI-900からAI-901へ刷新すると発表した。2026年6月30日にAI-900は廃止され、それ以降は新試験AI-901の合格が認定取得の要件となる。これは単なる試験更新ではなく、資格体系そのものの方向性を問い直す大きな転換点だ。 AI-900とAI-901、何が変わったのか 最も目を引く変更はPythonコーディング知識が必須になった点だ。AI-900は非技術者も含む「AIを概念として理解したい人」向けに設計されており、コーディングスキルは一切不要だった。新しいAI-901は「AIソリューションを実際に構築したい技術者の入門」へと対象を絞り込んでいる。 比較項目 AI-900（旧） AI-901（新） 対象者 非技術者・技術者初級 実装を目指す技術者初級 コーディング要件 不要 Python基礎構文・プログラミング概念 主な焦点 AIとは何か Foundryを使ってどうAIアプリを作るか 評価スキル Azure AIサービスの概念理解 Microsoft FoundryによるAIソリューション実装 AI-901では、Microsoft Foundryを軸にした生成AIアプリやエージェントの実装、テキスト・音声・コンピュータービジョン・情報抽出といったAIワークロードへの実践的な対応が問われる。Azureリソースのプロビジョニング経験も前提として求められる。 なぜこれが重要か 「AIについて説明できる人」は日本の職場にも急増している。しかし企業が本当に必要としているのは、AIを使って実際に何かを動かせる人だ。今回の資格刷新は、そのギャップを認定体系の側から埋めようとする動きと読める。 とりわけ注目すべきはMicrosoft Foundryへの集中だ。FoundryはAzure上でAIモデルのプロビジョニングからエージェント開発まで一気通貫で行えるプラットフォームで、Microsoftが「AIプラットフォームとしてのAzure」の核に据えた存在だ。この認定資格がFoundryを全面に押し出したことは、今後のAzure AI開発のメインルートがFoundryに集約されていくことを示唆している。 実務への影響——エンジニア・IT管理者が今押さえるべきこと 既存のAI-900保有者への影響はない。 認定資格そのものは継続するため、再取得や更新手続きは不要だ。ただし「より広いスキルセットをアピールしたい」場合はAI-901を任意で受験できる。 実務上の具体的なアクションとして以下を提案したい。 Foundry未経験なら今が学び時: AI-901に向けた学習コンテンツはMicrosoft Learnで整備が進んでいる。ベータ試験期間中は受験料が割引される場合が多く、コスト面でも取り組みやすい。 チームのAI人材育成基準を見直す: AI-900で「AIの概念を理解している」ことを証明していたエンジニアに、AI-901相当のFoundry実装スキルを追加習得させるロードマップを引くタイミングだ。 Python入門を後回しにしない: AI-901ではPython基礎が前提となる。Azure寄りのバックグラウンドを持つエンジニアでもPythonを避けられない時代になったと考えたほうがいい。 筆者の見解 正直なところ、この方向転換は歓迎したい。AI-900は「AIを怖がらせないための入り口」として機能していたが、資格を取っても実務では何もできないという状況が続いていた。そこへ「実装できることを証明する」試験を入門レベルでも要求するようにしたのは、資格の形骸化を防ぐ正しい判断だ。 Microsoft Foundryへの集中も戦略的に筋が通っている。企業がAzureを使い続ける理由のひとつは「Microsoftのプラットフォームに統合された形でAIを安全に動かせる」ことにある。AIモデルの選択肢は複数あれど、それを管理・運用するプラットフォームとしてFoundryが成熟すれば、Azure全体の価値は高まる。 一方で少し気になるのは難易度の急上昇だ。AI-900は「AIを概念として知りたいビジネス職」にも広く門戸を開いていた。AI-901は明確に技術者向けにシフトしたことで、非エンジニアが「Azureで認定を取る最初の一歩」として選べる試験が事実上なくなる。Microsoftがこの層向けに別途の入口を用意するかどうかは引き続き注目したい。 いずれにせよ、「概念を知っている」ではなく「実際に動かせる」を評価軸にしたこの変化は、日本のIT現場においても意味が大きい。資格体系がそこに追いついてきたことを、素直に前進と評価したい。 出典: この記事は Evolving the Microsoft Certified: Azure AI Fundamentals Certification の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SOCの「情報過多問題」に、AIアシスタントが本格参戦 Microsoftが2026年4月のDefender XDR月次アップデートで、SOC（セキュリティオペレーションセンター）チームの業務を根本から変えうる機能群を一挙に投入した。単なる機能追加ではなく、「脅威分析の起点をどこに置くか」というアーキテクチャレベルの転換を示す内容だ。特に注目したいのは、Security Copilotの会話型インターフェースのDefenderポータルへの組み込みと、非人間アイデンティティ（NHI）管理の本格強化という2つの軸である。 Security Copilotがポータルに「住み込む」 これまでSecurity Copilotは、Defenderのサイドバーや独立したページから呼び出すスタイルだった。今回のアップデートでは、Defenderポータルに完全に埋め込まれたチャット体験が提供され、アナリストが調査コンテキストを保持したまま会話形式で脅威を追える設計になった。 具体的には、アラート・アイデンティティ・デバイス・IPアドレスといった調査対象に対して、会話の流れの中で「この挙動は正常範囲か？」「このIPは過去に悪用された実績があるか？」のように問いかけながら深掘りできる。CopilotはDefenderのテレメトリをグラウンドとして使うため、一般的なLLMへの問いかけと異なり、自社環境のデータと紐づいた回答が返ってくる。 あわせて、Security Alert Triage Agentという「エージェント型トリアージ」機能が拡張された。フィッシング・ID・クラウドのアラートを単一のエージェントが統合処理し、それが本物の脅威か誤検知かを自然言語で説明しながら判断を示す。ステップバイステップの根拠も提示されるため、アナリストが結果を鵜呑みにせず検証できる設計になっているのは好感が持てる。 IDセキュリティが「見えるもの」になる もう一つの大きな柱が、Identity Security Dashboard（パブリックプレビュー） の登場だ。これまで断片的だったIDリスクの全体像が、ひとつのダッシュボードに集約される。 主な内容： IDプロバイダー・オンプレID・SaaS ID・PAM/IGA統合・NHIの概要カード 特権アカウント・リスクユーザー・弱い設定のドメインのウィジェット 0〜100スコアのIDリスクスコア（侵害の可能性と影響度を複合評価） 成熟度マッピングページ：Connected → Protected → Fortified → Resilient の段階ごとのカバレッジスコアと優先タスク 特に目を引くのが、非人間アイデンティティ（NHI）専用タブの追加だ。Microsoft Entra IDのアプリ、ADサービスアカウント、Google WorkspaceアプリやSalesforceアプリまで対象に含まれ、リスクあり・過剰権限・未使用・外部公開といった分類で一覧表示できるようになった。 実務への影響：日本のIT管理者が今押さえるべき点 1. SOCがない組織でもトリアージの「補助輪」として使えるか試す価値あり Security Alert Triage AgentはSOCアナリスト向けと説明されているが、専任SOCを持たない中堅企業でも、アラートの一次判断にかかる工数削減の効果は期待できる。まずはパブリックプレビュー環境で動作を確認したい。 2. NHIの棚卸しを今すぐ始める 自動化・AI活用が進むほど、ワークロードIDやサービスアカウントの数は増え続ける。「誰が何にアクセスできるか」が把握できていない組織では、自動化の恩恵を受ける前にリスクが先に育つ。NHI専用タブはその棚卸しの起点として非常に使いやすい構成になっている。 3. Just-In-Timeアクセス検討のトリガーに 特権アカウントの可視化が進んだ今こそ、常時アクセス権を見直す機会だ。IDリスクスコアが高い特権アカウントを洗い出し、JITアクセスへの移行を段階的に進めることを推奨したい。 筆者の見解 Defender XDRがこの方向性に向かっていることは、正しいと思う。特にNHIの可視化強化は、業務自動化を本気で進めようとする組織が必ず直面する「IDのカオス」に正面から向き合う施策で、地味だが実質的に重要な前進だ。 Security Copilotの会話型統合については、「ツールを行き来しなくていい」というUXの改善は間違いなく価値があるし、テレメトリと紐づいた回答という設計思想は正しい。ただ、こういった機能の真価はデプロイしてから半年後に問われる。「使ってみたら結局アナリストが素通りする」にならないよう、UIの磨き込みと誤検知率の継続的な改善をしっかり続けてほしい。 Microsoftのセキュリティポートフォリオは、M365・Azure・Entra IDを統合的に使える環境にいる組織に対して、他では代替しづらいプラットフォームとしての強みを持っている。エージェントの管制塔としてEntra IDを中心に据え、NHIの安全な自動化基盤を作り込む方向は長期的に筋が通った戦略だ。この軸をぶらさずに磨き続けることを期待したい。 セキュリティを「禁止で守る」から「仕組みで守る」へ。そのシフトを加速するツールとして、今回のアップデートは評価に値する内容だ。 出典: この記事は Microsoft Defender XDR April 2026 Update Supercharges SOCs with Copilot Chat, Identity Risk Scoring, and New Threat Defenses の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが新たなエンタープライズ向けSKU「Microsoft 365 E7」を発表した。既存のM365 E5とMicrosoft 365 Copilot、そして新たに登場する「Agent 365」を一つのライセンス体系に統合するという、かなり大胆な動きだ。AIをどう組織に根付かせるかという問いへの、Microsoftなりの現時点での回答といえる。 Agent 365とは何か Agent 365は、Microsoft 365エコシステム上で動作するAIエージェントの「コントロールプレーン」として位置づけられる新製品だ。単なるCopilotの延長線上ではなく、複数のAIエージェントをオーケストレーションし、業務プロセスへの組み込みをガバナンスと一体で管理するための基盤という理解が正確だろう。 具体的には以下の要素が含まれる。 AIエージェントのライフサイクル管理 — デプロイ・監視・廃止をIT管理者が一元管理できる Work IQ（ワーク・インテリジェンス） — 組織内の業務パターンや生産性をAIが分析・可視化する機能。Viva Insightsを発展させたイメージ セキュリティスタックとの統合 — Purview・Defender・Entraと連携し、エージェントの行動をゼロトラスト原則のもとで制御する これらをM365 E5の既存セキュリティ・コンプライアンス機能と組み合わせてパッケージ化したのが、E7というわけだ。 E5→E7という価格体系の意味 現在M365 E5を契約している企業にとって、E7はアップグレードの選択肢になる。M365 Copilotのライセンスを別途購入している場合は、E7に統合することでコスト最適化を図れる可能性がある。 ただし、ここは慎重に読む必要がある。「統合してお得」という構造は、実際には利用状況に依存する。Copilotを全社展開している大企業にとっては合理的な選択だが、一部部門だけに展開している企業では、逆にコストが増える可能性もある。ライセンスの棚卸しと利用実態の把握が、判断の前提として必要になる。 実務への影響——日本のIT管理者が押さえるべきポイント 短期的に動くべきこと 現行ライセンス構成の把握 — E5 + Copilotを別々に持っているなら、E7への移行コスト試算を今から始める。特に大手SIer経由で契約している場合は、見積もりのタイムラグがあるため早めに動くこと。 AIエージェント利用計画の棚卸し — Copilot Studioで作成したカスタムエージェント、あるいは今後作る予定のエージェントがあれば、Agent 365の管理フレームワークの対象になりうる。どのエージェントが何にアクセスしているかを整理しておく。 Work IQのプライバシーポリシー確認 — 業務インテリジェンス分析は、個人の行動データを扱う性質上、社内プライバシーポリシーや労使協定との整合確認が必須になる。技術評価と並行して法務・人事との連携を早めに始めること。 中長期の視点 Agent 365が「コントロールプレーン」として機能するなら、今後のMicrosoft 365上のAI活用は「個別ツールの導入」から「エージェントのポートフォリオ管理」へとパラダイムシフトする。IT部門の役割が「インフラ管理」から「エージェント・ガバナンス」へと変化していく流れは、すでに始まりつつある。 筆者の見解 この発表を見て、率直に「方向性は正しい」と思った。Microsoftのこういう動きは、実際に評価したい。 AIエージェントが増殖するにつれて、「誰が何にアクセスできるのか」「どのエージェントが今何をしているのか」が見えなくなるという問題は、現場でも実感としてある。Agent 365がそのコントロールプレーンとして機能するなら、ゼロトラストの観点からも意義は大きい。Non-Human Identities（NHI）の管理問題——つまりエージェントやサービスアカウントのアイデンティティ統制——は業務自動化の最大のボトルネックの一つだ。そこにMicrosoftがプラットフォームレベルで応答しようとしているのは、歓迎すべき動きだと思っている。 Work IQについても、「業務の可視化」という切り口は組織改革の文脈で使い道がある。ただ、日本企業においては「社員を監視されているように感じる」という心理的ハードルが高い傾向があるため、導入時のコミュニケーション設計が成否を分けるだろう。 一方で、気になるのはE7という統合パッケージ戦略の現実的な定着速度だ。日本の大企業では、M365のライセンス体系変更が実際の現場に浸透するまでに相当な時間を要することが多い。「発表された」と「使われている」の間にある距離を、Microsoftはもう少し丁寧に埋めるための支援策——ドキュメント・パートナー教育・パイロット支援——に力を入れてほしい。これだけの構想力がある会社なのだから、展開力でも同等の本気度を見せてほしい、というのが正直なところだ。 Microsoft 365というプラットフォームは、統合して使うことで初めて価値が最大化される。E7の構想はその方向性に沿っている。あとは、実装と展開のクオリティがこの構想に追いつくかどうか。それを見届けたい。 出典: この記事は Microsoft to introduce Agent 365 as M365 E7 unified suite の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2022年以来最大規模の価格改定が始まる Microsoftは2026年7月1日より、法人向けMicrosoft 365（M365）の主要SKUの価格を一斉に引き上げる。2022年の価格改定以来、最大規模となる今回の変更は、エンタープライズ・ビジネス・フロントラインの全カテゴリが対象で、値上げ幅は5〜43%と幅広い。既存顧客は更新タイミングまで旧価格が維持されるが、2026年7月以降の更新には新価格が適用される。 SKU別の主な価格変更（USD） エンタープライズスイート（Teams込み） SKU 旧価格 新価格 変化率 Microsoft 365 E3 $36.00 $39.00 +8% Microsoft 365 E5 $57.00 $60.00 +5% Office 365 E3 $23.00 $26.00 +13% Office 365 E5 $38.00 $41.00 +8% ビジネススイート（Teams込み） SKU 旧価格 新価格 変化率 Business Basic $6.00 $7.00 +16% Business Standard $12.50 $14.00 +12% フロントラインスイート（最大の値上げ幅） SKU 旧価格 新価格 変化率 M365 F1 $2.25 $3.00 +33% M365 F3 $8.00 $10.00 +25% スタンドアロンコンポーネントも軒並み値上がりしており、Entra Plan 1は+16%（$6→$7）、EMS E3は+13%（$10.60→$12.00）、Microsoft 365 Appsは+17%（$12→$14）となる。 価格転嫁の名目——何が追加されるのか Microsoftは今回の価格改定と合わせ、2026年夏から以下の機能をパッケージに追加すると発表している。 ...

会議室に「見えない参加者」が紛れ込んでいる——そんな状況に終止符を打つ機能が、Microsoft Teamsに追加される。2026年5月中旬から順次展開が始まる「外部ボットのロビーでのラベル表示」機能は、録音・文字起こしツールなどの自動化ボットが人間の参加者に混じって承認されてしまうリスクを根本から解消する、地味ながら実務への影響が大きいアップデートだ。 何が変わるのか 従来のTeams会議では、外部から参加しようとするボットが、見た目上は一般の参加者と区別がつかない状態でロビーに並んでいた。主催者がロビーを一括承認する際に、意図せずボットを入室させてしまうケースが実際に発生していた。 今回の変更では、外部の第三者製ボット（3P Bot）がロビーに来た際、明確なラベルが付与されて表示される。さらに、ボットの入室承認は人間の参加者とは別操作で、明示的に行う必要がある。うっかり全員まとめて承認、という事故がシステム的に防止される設計だ。 対応プラットフォームはWindows・macOS・Android・iOSの全プラットフォーム。対象テナントはWorldwideの標準マルチテナントおよびGCC環境。 なぜこれが重要か この機能が登場した背景には、AIノートテイクツールの急速な普及がある。Otter.ai・Fireflies・Notionなど、会議の録音・文字起こし・要約を自動化するサービスは今や数え切れないほど存在し、ビジネス現場での利用も珍しくなくなった。 問題は、こうしたツールが会議内容をどこかのサーバーに送信していることだ。日本企業にとっては、個人情報保護法への適合、社内規程との整合性、機密情報の漏洩リスクが現実の懸念として浮上する。特に、医療・金融・法務・官公庁系の組織では、外部サービスへのデータ転送自体が許可されていないケースも多い。 さらにセキュリティ観点では、悪意ある攻撃者がボットを会議に紛れ込ませるシナリオも現実的だ。Teamsを悪用したソーシャルエンジニアリング攻撃はすでに観測されており（ランサムウェアグループによる事例も含む）、Microsoftは昨年末から段階的に詐欺対策機能を強化してきた。今回の機能はその流れに沿った追加策と位置づけられる。 実務での活用ポイント IT管理者・セキュリティ担当者向け まず確認すべきは、自組織のTeams利用ポリシーに「外部ボットの参加可否」が明記されているかどうかだ。この機能が展開されると、主催者個人の判断に委ねられる部分が増える。組織全体として「外部ボットは原則拒否」「事前申請したツールのみ許可」などの方針を定め、主催者に周知しておく必要がある。 Teams管理センターからボットの参加自体をポリシーで制御できるかも、この機能と合わせて確認しておきたい。 会議主催者・一般ユーザー向け ロビー画面に「Bot」とラベルされた参加者が表示されたら、それは自動化ツールだ。承認前に「誰がこのボットを招待したのか」「このツールの利用は自社ポリシーに適合しているか」を必ず確認する習慣をつけたい。参加者の誰かが便利ツールのつもりで招待していても、会議内容の録音・クラウド送信が発生することへの認識共有が不可欠だ。 ゼロトラスト設計との整合性 この機能は「デフォルト拒否、明示的許可」という原則に則っており、ゼロトラストセキュリティの考え方と自然に整合する。ネットワーク・認証・認可の各層で防御を重ねるアーキテクチャにおいて、会議参加者の可視化と明示的承認の義務付けは、アイデンティティ管理の観点でも正しいアプローチだ。 筆者の見解 この機能、率直に言って「やっと来たか」という感想だ。AIノートテイクツールが会議に参加することへの違和感は以前から指摘されていたが、Teamsがプラットフォームとして対応策を提供するまでに時間がかかりすぎた感はある。 とはいえ、方向性は間違いなく正しい。「禁止する」のではなく「可視化と明示的承認を義務付ける」というアプローチは、現場の実態に即している。録音・文字起こしツール自体には正当なユースケースが多い。全面禁止すれば現場は非公式なツールに流れるだけで、かえってガバナンスが崩れる。公式の仕組みで安全に使える環境を整える——この発想は評価したい。 Teamsは会議体験において確実に機能を積み上げてきている。詐欺通話の報告機能、外部ユーザーのブロック機能、そして今回のボット検出——セキュリティ文脈での機能拡充は地道だが着実だ。M365を統合プラットフォームとして活用している組織にとって、こうした基盤整備は長期的な資産になる。 5月の展開後は、管理者・ユーザー双方へのアナウンスをセットで行うことを強く勧める。機能があっても使い方を知らなければ意味がない。この変更を機に、自組織の「会議ポリシー」を見直す良い機会にしてほしい。 出典: この記事は Microsoft Teams will tag third-party bots in meeting lobbies の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft FoundryおよびMicrosoft 365 Copilotにおいて、AnthropicのClaudeモデルが利用可能になったと発表された。CopilotチャットでOpenAIモデルと並んでサードパーティ製AIを選択できるようになり、さらにExcelの「Agent Mode」でも外部AIを活用したスプレッドシート操作が可能となった。単なる「別のAIが使えます」という話ではなく、Microsoftエコシステムの枠組みの中でマルチAI戦略が現実的な選択肢として企業に開かれたという意味で、注目に値するアップデートだ。 Microsoft Foundryによる統合：調達コストの壁を崩す これまでエンタープライズ企業がMicrosoftエコシステムの外からAIサービスを調達しようとすると、別途ベンダー契約・請求系統・セキュリティ審査が必要となり、導入に数週間から数か月かかることも珍しくなかった。 Microsoft Foundryへの統合で変わるのは、まさにこの調達の壁だ。FoundryのAPIやワークフローを通じてモデルを利用でき、既存のAzure契約（MACC：Microsoft Azure Consumption Commitment）の消費枠で課金が完結する。Microsoft Entra認証との連携も確保されており、Python・TypeScript・C#の各SDKから利用できる。 別途PoC申請・契約交渉・コスト配分の説明資料を用意しなくても、Azureの延長線上でモデルの評価と本番適用ができる。これは現場のエンジニアや調達担当にとって、地味だが実質的に大きい変化だ。 M365 Copilot側の変化：Researcherと「デュアルモデル方式」 Copilot側の変化も見ておきたい。M365 CopilotのResearcher機能では、複数のAIモデルを役割分担させる構成が採用されている。具体的には、一方のモデルが草稿を生成し、もう一方がその内容の精度検証を行うという二段構えの仕組みだ。 さらにExcelのAgent Modeでは、外部AIによるスプレッドシートの直接操作がプレビューとして提供開始された。数式の生成・データ分析・エラー検出・反復改善をAIに任せられる機能で、業務効率化の観点から注目に値する。 実務への影響：IT管理者・エンジニアが押さえるべきこと Azure利用企業のエンジニアへ Microsoft Foundryカタログからモデルをデプロイできる。既存のMACCに乗せられるか確認した上で、まずスモールスタートで評価を進めることをお勧めする サーバーレスデプロイのため、インフラ管理不要で即スタートできる点は評価できる モデルごとの特性（速度重視 / 高精度重視）を用途別に使い分けることが、コスト最適化につながる M365管理者・IT部門へ CopilotのResearcher機能はすでに業務利用されている組織もあるはず。その処理フローが今後マルチモデル構成に変化する点を把握しておくこと ExcelのAgent Modeはプレビュー段階。業務利用の前にデータガバナンスポリシーとの整合を確認しておくことが必要 Copilot Studio経由のカスタムエージェントにFoundryモデルを組み込む構成も可能になっており、エージェント開発の選択肢が広がった 筆者の見解 ここ数年、「M365のAI活用はCopilotだけで考える」という前提でIT戦略を立ててきた企業は少なくない。しかし現場の実感として、Copilotが全業務に対してベストな選択肢であるとは言いきれない局面も出てきている。 その意味で、今回の発表が意味しているのは「Copilot一択からの解放」だ。Teamsの議事録やOutlookの定型業務はCopilotに任せ、より高度な分析・推論・創造的なタスクには用途に応じた別のモデルを使う——こうした使い分けが、Microsoftの正規の枠組みの中で行えるようになった。 MicrosoftがAzureを通じてサードパーティAIをファーストクラスで扱う姿勢を示したことは、プラットフォームとしての「懐の深さ」を示すものだ。これはMicrosoftの強みである統合プラットフォームとしての価値を高める方向性であり、素直に評価したい動きである。 Copilotそのものがこの先どこまで進化するかは引き続き注目しているが、エコシステムとして多様な選択肢を束ねていく方向性は、これまでMicrosoftが得意としてきたことだ。このアーキテクチャの方向性が、AI時代においても真価を発揮することを期待したい。 「とりあえずCopilotを入れたが活用が進んでいない」という状況に直面している企業にとって、今こそFoundryを起点にしたマルチAI戦略を再設計するタイミングかもしれない。 出典: この記事は Claude now available in Microsoft Foundry and Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングツールが普及するにつれ、「どれだけトークンを使ったか」を生産性の指標にする風潮が広まりつつある。シリコンバレーでは「大きなトークン予算を持つ開発者は生産的だ」という空気さえ生まれているが、本当にそうなのだろうか。最新の調査データは、その前提に鋭い疑問を突きつけている。 「受け入れ率80%」の裏側にある現実 エンジニアリング分析プラットフォームを提供するWaydevのCEO、アレックス・チルセイ氏によれば、同社の顧客（50社・エンジニア1万人超）では、AIが生成したコードの受け入れ率が80〜90%に達しているという。一見すると目覚ましい数字だ。 しかし問題はその後に起きる。受け入れたコードを数週間のうちに書き直す「コードチャーン（code churn）」が急増しており、実際の定着率は10〜30%にまで下がるという。つまり、最初に「OK」を押したコードの7〜9割が後でひっくり返されているわけだ。 GitClearが今年1月に公開したレポートも同様の傾向を示している。AIツールの頻繁な利用者は非利用者と比べてコードチャーンが平均9.4倍に達しており、ツールが提供する生産性向上効果の2倍以上を相殺しているとしている。エンジニアリング分析のFaros AIが2年間のデータをもとにまとめた2026年3月のレポートも、同じ結論に近い結果を示している。 「何を測るか」が生産性を定義する この問題の本質は、指標の設計にある。 トークン消費量は「AIの使用量」というインプットの指標に過ぎない。本来問われるべきはアウトカム——つまり「どれだけ価値あるコードが本番に届いたか」「バグが減ったか」「ユーザーへの価値提供速度が上がったか」だ。 管理職にとって見えやすい「コード受け入れ率」や「生成コード行数」は、短期的には増加を示す。しかし、見えにくいコードチャーンのコストが積み重なると、チーム全体のスループットは実質的に低下しかねない。何を測るかが、現場の行動を規定する——古典的な管理論の教訓が、AI時代に再び鋭さを取り戻している。 実務での活用ポイント 1. コードチャーン率を可視化する Git履歴を解析し、「承認後に書き直されたコードの割合」を定期的に計測する仕組みを作ろう。GitClear、Waydev、Faros AIのようなエンジニアリングインテリジェンスツールが選択肢になる。AtlassianがDXを1,000億円規模で買収したことからも、この市場の注目度がわかる。 2. AIツールの使い方自体を見直す 「とりあえずAIに書かせて後で直す」という使い方は、チャーンを増やす典型パターンだ。仕様・制約・既存コードのコンテキストをプロンプトに十分盛り込み、一発で使えるコードを引き出す「問い方の設計」に投資する価値がある。 3. レビュー文化を変える AI生成コードに対して「とりあえず承認」するレビュー習慣は危険だ。「このコードが3週間後も生きているか」という視点でレビューする文化と、それを支えるガイドラインの整備が急務になっている。 4. チームごとのROIを測定する AIツールのコスト（トークン料金）と、チャーンによる手戻りコストを合算してROIを算出してみる。トークン予算が大きいチームほど生産性が高いとは限らない、という事実が見えてくるはずだ。 筆者の見解 正直に言えば、この話には「そうだよな」という感覚がある。 AIコーディングツールを使い始めた当初、「こんなにコードが出てくる」という興奮は確かにあった。しかし実際に価値が出ているのは、ツールとのやり取りをきちんと設計できているとき——つまり、何を作るかを自分の中で整理した上でAIに問いかけているときだ。逆に「なんとなく聞いてみる」使い方は、コードは出てくるが後始末が増える。 トークン予算を競い合う「トークンマキシング」は、かつての「コード行数競争」と本質的に同じ過ちを繰り返している。インプット指標にフォーカスすると、人間の行動がそこに引き寄せられてしまう。 AIエージェントの本当の価値は「コードをたくさん生成すること」ではない。人間の認知負荷を下げ、判断と検証にフォーカスできる環境を作ること——そのための道具として正しく使うことが、これからのエンジニアに求められるスキルだ。 「どれだけ使ったか」ではなく「何を作れたか」。ここに立ち返ることが、AIツール活用の次のステージに進む鍵になると思っている。 出典: この記事は ‘Tokenmaxxing’ is making developers less productive than they think の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングスタートアップ「Cursor」が、少なくとも20億ドル（約3,000億円）の新規調達に向けた交渉を進めている。評価額は500億ドル（約7.5兆円）に達する見込みだ。これはわずか半年前の前回ラウンドにおける293億ドルから約1.7倍の跳ね上がりであり、AIコーディングツール市場が投資家から見てどれほど魅力的に映っているかを如実に示している。 資金調達の詳細 リターン投資家として、ベンチャーキャピタル大手のAndreessen Horowitz（a16z）とThriveがラウンドをリードする見込み。Battery Venturesが新規投資家として参加の可能性があり、NvidiaもStrategic Investorとして出資する見通しだという。すでにラウンドは超過申し込み状態とされているが、最終的な条件は変更の可能性がある。 CursorはMITの学生4名（Michael Truell、Sualeh Asif、Arvid Lunnemark、Aman Sanger）が2022年に設立した企業で、元の社名は「Anysphere」。設立わずか4年でユニコーンどころかデカコーン（時価総額100億ドル超）をはるかに超える規模に達した。 驚異の収益成長——2026年末に60億ドルARR目標 より注目すべきは収益の軌跡だ。2026年2月時点で年率換算売上高（ARR）が20億ドルに達していたと報じられており、同社は2026年末に60億ドルを超えるARRを目指しているという。これは今後10ヶ月で売上を3倍以上にするという野心的な計画だ。 ただし、収益構造には興味深い非対称性がある。大企業向けエンタープライズ販売では粗利益がプラスになっている一方、個人開発者向けのアカウントでは依然として損失が続いている。AIサービスのコスト構造を考えれば自然な帰結だが、長期的な持続可能性を語る上で重要なポイントだ。 サードパーティ依存からの脱却——プロプライエタリモデルの戦略的意味 AIコーディングツール企業にとって最大のリスクのひとつが、モデル提供元（APIサプライヤー）への依存だ。Cursorも従来は外部の大規模言語モデルに依存しており、ネガティブな粗利益構造に悩まされていた——つまり、製品を動かすコストが収益を上回っていたのだ。 この課題への回答として、昨年11月に独自の「Composerモデル」を導入。加えて、中国のKimiのような低コストモデルを選択的に活用できる仕組みを整えた結果、粗利益がわずかながらプラスに転換したという。 この動きは単なるコスト最適化ではない。自社モデルを持つことで、AIサービスを提供する側からの競合リスク——いわば「サプライヤー競合」——を軽減するという構造的な防衛戦略でもある。自社製品の主要競合となりうる立場のAPIプロバイダーに依存し続けることの危うさを、Cursorは明確に認識して手を打っている。 実務への影響——日本のエンジニア・IT管理者が知るべきこと エンタープライズ採用の加速 Cursorの成長の主軸がエンタープライズ向けにシフトしていることは、日本企業にとっても無視できない動向だ。大規模組織がAIコーディングツールを本格的に業務導入するフェーズに入りつつある。セキュリティポリシーやデータガバナンスの観点からエンタープライズプランの評価を今のうちに進めておくことが現実的な対応となる。 コスト構造の理解が導入判断の鍵 個人開発者向けと法人向けで採算構造が異なるという事実は、サービスの価格改定リスクとも表裏一体だ。現在の個人プランが安価なのは、一種の「顧客獲得投資」の側面もある。将来的な価格変動を織り込んだ上でツール選定を行うことが望ましい。 AI費用の把握と最適化 Kimiのような低コストモデルの活用が粗利改善に貢献したという事実は、AIサービスを運用するすべての組織へのヒントでもある。高性能モデルが必要なタスクと、低コストモデルで十分なタスクを分けて設計することで、大幅なコスト削減が可能になる。タスクの特性に応じたモデルの使い分けは、今後の開発組織における必須スキルになりつつある。 筆者の見解 Cursorの今回の評価額跳ね上がりは、「AIコーディングツール市場はまだバブルか？」という問いを改めて提起する。しかし、個人的には単純なバブルとは見ていない。 エンタープライズ向けで粗利益がプラスに転換したという事実は重要だ。ツールとして本当に価値があるなら、企業は対価を払う。逆に言えば、エンタープライズが金を出し続ける限り、この評価額には一定の根拠がある。 より興味深いのは「プロプライエタリモデル化」という戦略だ。外部APIに依存した状態では、サプライヤーがいつでも競合に転じうる構造的リスクを抱え続ける。自社モデルを持ちながらも低コストの選択肢を組み合わせる柔軟な設計は、AIスタートアップが生き残るための現実的な解答のひとつだと思う。 AIコーディングツールの競争は今が最も激しいフェーズにある。この競争は最終的に、開発者にとってのツールの選択肢を増やし、品質を高める方向に働くはずだ。乱立するプレイヤーの中から何が残るかは2〜3年後に明らかになるが、少なくとも「AIが開発者の生産性を変える」という大きな流れ自体は、もはや後戻りしない。日本のエンジニアとIT組織にとっても、今この変化の波に乗るか乗らないかの判断が、数年後の競争力に直結する局面だ。 出典: この記事は Sources: Cursor in talks to raise $2B+ at $50B valuation as enterprise growth surges の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが、同社の最も野心的なプロジェクトを牽引してきた二人の幹部の退社を発表した。AIビデオ生成ツール「Sora」の開発者として知られるBill Peebles氏と、科学研究イニシアチブ「OpenAI for Science」を率いてきたKevin Weil氏だ。この人事は単なる退職ではなく、OpenAIが進める戦略的な「選択と集中」の象徴として読むべきだろう。 相次ぐ「サイドクエスト」の終焉 OpenAIはここ数ヶ月、社内で「サイドクエスト（寄り道）」と呼ばれていた取り組みを次々と縮小・終了している。その筆頭がSoraだ。動画生成AIとして2024年に鮮烈なデビューを飾り世界中の注目を集めたが、実態は1日あたり推定100万ドル（約1億5000万円）の計算コストを消費し続けており、先月正式にサービス停止となった。 OpenAI for Scienceも同様の運命をたどった。2025年10月に正式発表されたこの研究グループは、AIを使って科学的発見を加速する「Prism」プラットフォームを開発していた。しかし、立ち上げ直後にはGPT-5が数学の未解決問題を解いたという主張が専門家から即座に否定されるなど、スムーズな船出とはほど遠い状況が続いていた。このチームは現在、他の研究チームに吸収統合される方向となっている。 加えて、エンタープライズアプリケーション担当CTOのSrinivas Narayanan氏も「家族との時間を大切にするため」として退社を表明しており、エグゼクティブ層の離脱が相次いでいる。 エンタープライズへの集中と「スーパーアプリ」構想 これらの動きが示すのは、OpenAIが企業向けAIビジネスと「スーパーアプリ」構想に経営資源を集中させていくという明確な方針だ。ChatGPTのコンシューマー向け展開で培ったブランドを活かしつつ、収益性の高い法人契約とプラットフォーム統合に軸足を移していくと見られる。 Bill Peebles氏は退社にあたり「Soraは業界全体のビデオAI投資を触発した」と述べ、「研究室が長期的に繁栄するためには、メインロードマップから距離を置いて研究できる空間が必要だ」と語った。この言葉は、研究と商業化の緊張関係をそのまま示したものとして興味深い。 日本のエンタープライズAI導入への影響 OpenAIのこの転換は、日本のIT現場にとっても無関係ではない。 エンタープライズ向け機能が加速する: Azure OpenAI Service経由でOpenAIのモデルを業務利用している企業にとっては、法人向け機能の充実が期待できる。セキュリティ、コンプライアンス、SLAといった企業要件への投資が増えるはずだ。 AI動画・科学研究ツールの展望は不透明: Soraのような消費者向け・研究向けの実験的サービスへの期待は、少なくとも短中期では薄まった。「AIで何ができるか試してみたい」という探索的用途については、他社プレイヤーの動向も注視が必要だ。 意思決定のスピードが上がる可能性: サイドクエストを整理することで、OpenAIの中核プロダクト（ChatGPT Enterprise、API、Azure連携）の改善サイクルが速まる可能性がある。企業システムへの統合を検討しているIT管理者は、今後のロードマップを改めて確認する価値がある。 実務での活用ポイントとして、ChatGPT EnterpriseやAPIを利用している企業は、OpenAIのエンタープライズ向けアップデートの公式ページやリリースノートを定期的に確認する習慣をつけておきたい。戦略集中により、法人向け機能が今後数ヶ月で充実していく可能性が高い。 筆者の見解 OpenAIの今回の判断は、ある意味で「正しい経営判断」だと思う。1日1億円超のコストを垂れ流しながら収益化の見通しが立たないサービスを続けることは、持続可能なビジネスとは言えない。Soraが示した技術的インパクトは本物だったが、それを事業として成立させるには相応の時間と環境が必要だった。 ただ、気になるのはAI研究における「余白」の喪失だ。Peebles氏が退社コメントで述べた「エントロピーを育てることが研究室が長期的に繁栄する唯一の道」という言葉は示唆に富む。短期的な収益最大化に向けて最適化を進めれば進めるほど、予想外のブレークスルーが生まれる土壌が失われていく。OpenAIはかつて「AGIのための研究機関」として出発したが、その原点との距離がまた少し広がった気がしてならない。 エンタープライズ戦略への集中自体は正しい方向性だと思う。ただ、本来の研究力を活かせる構造を維持しながら商業化できるはずなのに、そこを両立できないのはもったいない。OpenAIには「エンタープライズAIの真っ当な競争者」として正面から勝負できる力がある。そのポテンシャルを、短期的な収益圧力の前に縮小してほしくないというのが率直なところだ。 今後のAI業界の主戦場が「いかに企業の業務に深く統合されるか」にシフトしていくことは間違いない。その競争において、OpenAIがエンタープライズ特化で真価を発揮できるかどうか、引き続き注目していきたい。 出典: この記事は Kevin Weil and Bill Peebles exit OpenAI as company continues to shed ‘side quests’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファストフード大手のDairy Queenが、AIチャットボットをドライブスルーに本格展開する。米国とカナダの複数のフランチャイズ店舗から順次ロールアウトを始め、注文速度の向上と「アップセル（追加購入の促進）」を狙う。チェーン単体の取り組みに見えるが、その背後にある流れは、産業現場におけるAI実装の現実を鋭く映し出している。 Prestoが担うファストフードAIの基盤 今回の主役は、AIドライブスルーシステムを提供するスタートアップ「Presto」だ。すでにCarl’s Jr.、Hardee’s、Taco John’s、Fazoli’sなど複数のチェーンと取引実績がある。Dairy Queenとの契約は昨年の試験運用を経てのもので、注文の正答率は約**90%**と報告されている。 ただし、2023年にBloombergが報じた内容には注意が必要だ。Prestoのシステムは純粋な自律AIではなく、フィリピンなど海外拠点の人間オペレーターが遠隔でバックアップに入る「人間補助型AI」の構造になっている可能性が指摘されていた。完全自律のAI接客ではなく、AIと人間のハイブリッド構成——この点は、現時点のAI音声認識の限界を正直に示している。 ファストフード業界のAI競争 Dairy Queenの動きは孤立した事例ではない。業界全体のトレンドとして見る必要がある。 Wendy’s：2023年からGoogleのAI技術を活用したドライブスルーを試験導入 McDonald’s：チャットボット型ドライブスルーをパイロット展開（現在は縮小） Taco Bell：一部顧客からの不満と「チャットボットをわざと困らせる」悪戯投稿を受け、展開地域を見直し中 Burger King：ドライブスルーではなく、店員のイヤホンにAIを組み込み「接客態度の評価」と調理補助に活用 各社がそれぞれの文脈でAIを試しており、正解はまだ出ていない。 実務への影響——日本の小売・飲食業界はどう読むか Dairy QueenはあくまでUS・カナダの話だが、日本の小売・飲食業界にとっても他人事ではない。 音声AIによる注文受付の精度問題は日本でも同じ。英語よりも多様なイントネーションと方言を持つ日本語での精度確保は、英語より難しい課題になる。「90%の精度」でも10件に1件はエラーが起きることを意味し、混雑するランチタイムに頻繁にリカバリーが必要になれば、かえって現場負担が増す可能性がある。 人間補助型ハイブリッド構成は参考になる設計思想だ。「AIに全部任せる」ではなく、AIが一次対応し、難易度が高いケースを人間がカバーする構造は、日本企業がAI導入を検討するときの現実的な出発点になる。「完全自動化」にこだわりすぎると導入が止まる。まず部分的な自動化から始めることが重要だ。 アップセル機能の実装は慎重に。「AIが積極的に追加注文を勧める」設計は、顧客体験によっては押しつけがましさにつながる。Taco Bellが経験したような炎上リスクを避けるためにも、推薦の頻度とタイミングの設計が重要になる。 IT管理者・エンジニアとして押さえておきたい実務ポイント： PoC→段階展開の設計：Dairy Queenも昨年の試験運用から本格展開へ。小規模で精度・オペレーション影響を測ってから拡大するプロセスが現実的 エラーハンドリングの設計を先に決める：90%が成功するということは10%は失敗する。その失敗時のUX（ユーザー体験）をどう設計するかが実は最も重要 ハイブリッド構成の透明性：「AIが対応します」と言いながら裏では人間が介在する構成は、開示方針を事前に整理しないとブランドリスクになる 筆者の見解 Dairy Queenのニュースを読んで最初に感じたのは、「産業AIの現実はやはりこうなるよな」という納得感だ。 音声認識AIのドライブスルー応用は技術的に面白いが、現場で動かしてみると「90%精度＋人間バックアップ」という構成に落ち着くのはある意味必然だ。AIが自律的に判断・実行・検証を繰り返すループを回せるほど、現在の音声AIはまだ安定していない。特に注文という、金銭が絡みミスが直接クレームに直結する場面では、完全自律にする怖さは理解できる。 だからこそ、次のステップとして注目したいのは「どこまで人間介在を減らせるか」の試行錯誤だ。PrestoのようなプレイヤーがDairy Queenという大きな実証環境を得たことで、精度改善のフィードバックループが回り始める。今後数年で精度が95%、98%と上がっていけば、人間補助の必要性は急速に低下する。そのタイミングで「AI不在のドライブスルー」がコストで圧倒的に有利になる。 日本の外食・小売業界がこのトレンドをどう受け取るか、少し心配している。「海外の話」として様子見をしている間に、テクノロジーの実装コストが大幅に下がり、気づいたら導入ノウハウで大きな差がついていた——そういう展開を、IT産業全体でここ数年繰り返してきた。 注文精度90%という数字は、批判的に見るか前向きに見るかで評価が変わる。「まだ10%も失敗する」と見るか、「初期展開でこの精度ならスケールしたら十分使える」と見るか。筆者は後者の見方をしている。PoC段階でこの精度が出ているなら、本格展開と改善サイクルを回せば現場で十分機能するレベルに到達できる。 産業AIの実装は、理想の完全自律ではなく、現実的なハイブリッドから始まる。それが今、ファストフードのドライブスルーで実証されつつある。 出典: この記事は Dairy Queen is putting an AI chatbot in its drive-thrus の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIと政府の関係は、テクノロジー業界において今後のAI利活用の枠組みを決定づける重要な変数だ。その最前線で、AnthropicとトランプPolitics政権の間で注目すべき動きがあった。 何が起きたか 2026年2月末以降、Anthropicとトランプ政権の関係は急激に冷え込んでいた。発端は、AnthropicがDoD（米国防総省）との協議において「国内の大規模監視への技術転用」と「人間の関与なき完全自律型致死兵器」の2点を明確に拒否したことだ。これにより米政府はAnthropicをサプライチェーンリスクに分類し、Anthropic側も法的対抗措置に出るという泥沼状態になっていた。 そこに投じられた一石が、Claude Mythos Previewだ。Anthropicが「これまでで最も強力なモデル」と位置づけるこのモデルは、主要なWebブラウザやOSに潜む脆弱性をほぼ自動で発見できるとされる。現在はプライベートアクセスのみで、Apple・Nvidia・JPMorgan Chaseがすでに利用を表明している。 このモデル発表後、Anthropic CEOのDario Amodei氏はホワイトハウスで政府高官と会合を持ったことが確認された。Anthropicの広報は「サイバーセキュリティ、AI競争における米国のリーダーシップ、AI安全性という共通の優先事項について生産的な議論ができた」と述べており、関係修復に向けた動きが本格化しつつある。 Claude Mythos Previewの技術的インパクト このモデルが注目を集める最大の理由は、ホワイトハット（防御的）サイバーセキュリティへのAI適用を本格実装している点にある。 従来の脆弱性スキャンツールはパターンマッチングや静的解析が中心だったが、大規模言語モデルベースのアプローチは、コードの文脈理解・論理的推論・複雑な依存関係の追跡において質的に異なる能力を持つ。GoogleのProject Zeroのような専門チームが何週間もかけて発見するような脆弱性を、AIが短時間でフラグアップできる可能性がある。 発表によれば、対象はChrome・Firefox・Safari等の主要ブラウザ、Windows・macOS・Linux等のOSにまで及ぶ。Anthropicは米政府高官にもその能力を事前ブリーフィングしており、このモデルが「攻撃的・防御的サイバー能力の両面」を持つとして紹介している点も重要だ。 実務への影響——日本のIT管理者・セキュリティエンジニアへ 日本企業の多くはChrome・Windows・macOSを主力環境として使っている。Claude Mythos Previewが商用展開された場合、以下のような活用シナリオが現実的に考えられる。 脆弱性管理の自動化: 従来は専門スキルが必要だったゼロデイ脆弱性の検出・分類作業を、AIが一次スクリーニングする形で人間の負荷を大幅に下げられる可能性がある。 OSS依存関係の監査: 大規模なOSSライブラリを利用するシステムでは、依存関係に潜む脆弱性の追跡は困難だ。コード文脈を理解するAIの活用は、この領域での実用性が特に高い。 インシデントレスポンスの初動: 攻撃パターンの分析や影響範囲の特定に、サイバーセキュリティ特化モデルを活用できれば、インシデント対応のスピードが変わる。 現時点では企業向けのアクセスは限定的だが、Apple・Nvidia・JPMorganが採用している事実は、エンタープライズ向け展開を見越した布石と捉えるべきだ。日本のセキュリティ担当者は今から活用前提でウォッチしておく価値がある。 筆者の見解 AIと国家安全保障の交差点は、2026年を通じて最も注目すべき領域のひとつだ。今回のAnthropicと米政府の関係修復の経緯を見ると、テクノロジー企業が「倫理上の譲れないライン」を持ちながらも政府との関係を維持しようとする構図が鮮明に見える。Anthropicが自律型致死兵器への転用を拒否した点は、AI企業として誠実な態度だと評価したい。 より本質的な論点は、サイバーセキュリティ特化AIが既存の防衛・セキュリティの構造をどう変えるかだ。高度な脆弱性発見能力を持つAIが普及すると、攻撃側と防御側の双方がこれを使う軍拡競争になる。防御側がAIを活用して先手を打てる仕組みを作れるかどうかが、今後数年のセキュリティの根幹になる。 AIを「副操縦士として横に置く」ではなく、「インフラに組み込んで自律的に動かす」という設計思想が、サイバーセキュリティ領域では特にリターンが大きいはずだ。攻撃者は休まない。防御が人間のシフトに縛られている限り、構造的に不利だ。自律的に動き続けるAIエージェントをセキュリティの中枢に据える——この方向への移行を、Claude Mythos Previewは一つ加速させるかもしれない。 日本においてはサイバーセキュリティ人材の不足が長年の課題だ。高度な専門家が足りないという現実を「採用で解決する」のではなく、「AIで仕組みを作って解決する」方向に舵を切る企業が、今後の差別化につながっていくと筆者は見ている。 出典: この記事は Anthropic’s new cybersecurity model could get it back in the government’s good graces の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソースのAIエージェントフレームワーク「Gas Town（gastown）」が、ユーザーの知らないうちにLLMクレジットとGitHubアカウントを消費・使用していたとする問題が、GitHub Issuesに投稿されて注目を集めている。スター数14,000を超える人気ツールだけに、その影響は小さくない。 何が起きたのか Gas Townはインストール時に、gastown-release.formula.tomlとbeads-release.formula.tomlという2つのフォーミュラをデフォルトで同梱している。これらのフォーミュラがユーザーのgit認証情報を使ってメンテナのリポジトリにリリースやタグをプッシュする設計になっていたことが問題として報告された。 さらに深刻なのは、ユーザーのAIエージェントがGas Town自身のIssueトラッカーを監視し、バグを自律的に修正してPRをメンテナのリポジトリに提出するという動作も確認された点だ。つまり、ユーザーが支払ったLLMのクレジットや使用量が、ツール自身のバグ修正のために消費されていたということになる。 この動作についてREADMEやドキュメントには一切記載がなく、オプトイン・オプトアウトの仕組みも存在しない。問題を発見したユーザーがAIに調査させたところ、内部のテンプレートファイル（mayor.md）にIssue種別ごとの対応フローが定義されており、意図的な設計である可能性が高いことが確認されている。 なぜこれが重要か 同意なき資源消費というエージェント設計の問題 これは単なるバグではなく、自律型エージェントの設計倫理に関わる問題だ。エージェントが「ハーネスループ（自律的に判断・実行・検証を繰り返す仕組み）」で動き続ける構造を持つ場合、その影響範囲は開発者が想定した以上に広がりやすい。 従来のソフトウェアであれば、コードを読めば何をするかが概ね把握できた。しかしAIエージェントはプロンプト・フォーミュラ・ロール定義の組み合わせで動作が決まるため、インストール時点での動作全容を把握するのが難しい。「エージェントは誰のために・何を実行しているのか」という問いを常に意識する必要がある。 日本のエンタープライズ環境への示唆 日本企業でもAIエージェントツールの導入が急ピッチで進んでいるが、特にセキュリティ・コンプライアンス観点から注意が必要だ。今回のように、ツールがデフォルトで外部リポジトリへの書き込みを行う動作を持つ場合、それが企業の情報セキュリティポリシーに抵触する可能性がある。API利用コストの管理責任という観点でも、無断での消費は見過ごせない問題だ。 実務での活用ポイント AIエージェントツール導入時のチェックリストとして、以下を押さえておきたい。 デフォルト動作の確認: インストール直後に有効になっている自律動作を把握する。特に外部への送信・コミット・API呼び出しが含まれないか確認する LLMコストのモニタリング: API利用量を定期的に監視し、意図しない消費がないか確認する体制を整える 権限の最小化: エージェントに与えるGitHub・クラウドサービスの権限は最小限にとどめる。書き込みが不要なら読み取り専用に制限する 設定ファイルの精査: フォーミュラ・テンプレート・ロール定義など、エージェントの動作を規定するファイルは目を通してからデプロイする 定期的なChangelog確認: オープンソースのエージェントツールは機能追加が速く、バージョンアップで動作が変わることがある 筆者の見解 今回の件は、AIエージェントの設計者が向き合うべき問題を正面から突きつけている。 自律エージェントは「目的を伝えれば自律的にタスクを遂行する」からこそ価値がある——それはそのとおりだ。しかし、その自律性はあくまでユーザーが委任した範囲の中で発揮されるべきものだ。ユーザーの認知の外で、ユーザーのリソースを消費して、別の誰かのプロジェクトを前進させる——これは自律性の本質的な逸脱だと思う。 エージェントに「ループで動き続ける力」を持たせることは、同時に「暴走したときの影響範囲の大きさ」を意味する。だからこそ、何をしていいか・してはいけないかのスコープを明示的に設計することが、エージェント開発者の最低限の責任ではないか。 「禁止ではなく安全に使える仕組みを」というのは私が一貫して言ってきたことだが、安全な仕組みを作る責任はツールの作者側にもある。「デフォルトオープン（デフォルトで何でもあり）」な設計を持つツールは、AIエージェントが普及する中でじわじわと信頼を失っていくだろう。「デフォルトで安全、必要なら明示的に拡張」という設計原則を守るツールが、長期的に選ばれていくはずだ。今回の騒動がその方向への議論を加速させてくれることを期待している。 出典: この記事は Does Gas Town ‘steal’ usage from users’ LLM credits to improve itself? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

デザインとAIの関係が、また一段階変わろうとしている。Anthropicが2026年4月17日に発表した「Claude Design」は、画像生成AIとも、テキストベースの指示ツールとも異なる、チームのデザインシステムを軸にした共同制作プラットフォームだ。研究プレビューとして、Pro・Max・Team・Enterprise サブスクライバーに順次展開されている。 Claude Designとは何か Claude DesignはAnthropicの最新ビジョンモデル「Claude Opus 4.7」を搭載し、テキストで指示するだけでデザイン・プロトタイプ・スライド・ワンペーパーなどビジュアル成果物を生成・反復改善できるツールだ。 特徴的なのは「オンボーディング時にコードベースとデザインファイルを読み込み、チームのカラー・タイポグラフィ・コンポーネントを自動抽出してデザインシステムを構築する」点。以降のすべてのプロジェクトに、そのシステムが自動的に適用される。部門ごとに複数のデザインシステムを持つことも可能だ。 主な使われ方 インタラクティブプロトタイプ: 静的モックアップを共有可能なインタラクティブ版に変換。コードレビューやPRなしで完結 プロダクトワイヤーフレーム: PMがフィーチャーフローをスケッチして、そのままエンジニアへハンドオフ ピッチデック・プレゼン: ラフなアウトラインからブランドに沿ったスライドを生成し、PPTXやCanvaへエクスポート マーケティング素材: ランディングページやSNS用ビジュアルをその場で作成 フロンティアプロトタイプ: 音声・映像・3D・シェーダーを組み込んだコード駆動の体験を誰でも構築可能 操作フロー テキストプロンプトで初版を生成 → インラインコメントや直接テキスト編集、スペーシング/カラー/レイアウトの調整ノブでリファイン → 「全体に適用」を指示 → CanvaやPDF・PPTX・スタンドアロンHTMLへエクスポート、という流れが基本だ。組織内URLでの共有や、複数人が同時にチャットしながら編集するコラボレーション機能も備える。 最終的に完成したデザインは「ハンドオフバンドル」としてパッケージ化され、コード実装ツールへワンステップで引き渡せる設計になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 「デザインできないPM・エンジニア問題」への解答 日本の中小規模チームでは、専任デザイナーが不在のままPMやエンジニアが資料を作り続ける現場が少なくない。Claude Designは「デザインセンスがなくてもブランドに沿ったアウトプットが出せる」を現実にする。会議前夜にワイヤーフレームを整えたいとき、投資家向けデックをたたき台から仕上げたいときに、インフラとして機能しうる。 デザインシステム管理の自動化 チームのデザインシステムを一度読み込ませれば以降は自動適用される仕組みは、デザイン一貫性の維持コストを大幅に下げる。大企業のブランドガイドライン管理でも、スタートアップの「なんとなく合わせる」問題の解消でも使える。 注意すべき点 コードベースやデザインファイルを読み込む機能は、機密情報の取り扱いポリシーを事前に確認する必要がある。Enterprise契約であればデータ処理のスコープが明確になるが、Teamプランで社外秘の設計資料を投入する前には利用規約・データ保持ポリシーの精読を推奨する。 筆者の見解 デザインツール市場にAIが本格参入するのは時間の問題だったが、今回の発表で注目したいのは「デザインシステムの自動インポート→全プロジェクトへの自動適用」という設計思想だ。 これは「AIに都度指示して出力を得る」副操縦士型のアプローチではなく、一度文脈を与えれば以降は自律的に文脈を維持し続けるアーキテクチャだ。繰り返しの確認や承認を人間に要求し続ける設計では、本来の効率化が半減する。その意味でClaude Designの設計方針は、AIが実務の流れに自然に溶け込むための正しい方向を向いている。 実務家として「情報を追うより自分で使って成果を出す」を徹底している立場から言えば、まずプロトタイプひとつ作ってみることを強く勧めたい。「ビジュアル制作にこれだけ使えるなら、テキスト・コード・データ・デザインが一気通貫でつながる未来は近い」というのが率直な印象だ。 Design→コード実装へのハンドオフ機能も含め、今後の機能拡張次第ではノーデザイナーでもプロトタイプからプロダクション品質のUIまで一気に仕上げるワークフローが現実になる。日本のIT現場でも、まず「小さく試して体感する」フェーズを早めに踏んでおくことが、次の半年で差をつけるポイントになるだろう。 出典: この記事は Claude Design の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Opus 4.7のリリースにともない、Anthropicは新しいトークナイザーを導入した。公式移行ガイドには「おおよそ1.0〜1.35倍のトークン数」と記載されているが、実際にAPIで計測したところ、英語技術文書では1.47倍、Claude Codeユーザーが日常的に送信するCLAUDE.mdファイルでは1.45倍という結果が出た。上限ではなく、それを超えた数字だ。 同じ料金体系のまま、トークン消費が増える。これが実務にどう響くのかを整理しておきたい。 実測データが示すもの 計測に使われたのはAnthropicが提供する無料のトークンカウントAPI（POST /v1/messages/count_tokens）。同じコンテンツをOpus 4.6と4.7に投げて差分を見るシンプルな手法で、推論コストはかからない。 コンテンツ種別ごとの実測比率（4.7 / 4.6）は以下のとおり。 コンテンツ種別 比率 英語技術文書 1.47x シェルスクリプト 1.39x TypeScriptコード 1.36x Markdownコードブロック混じり 1.34x Pythonコード 1.29x 英語散文 1.20x 一方で、日本語・中国語テキストは1.01倍とほぼ変化なし。CJK文字やJSON、CSVなどの構造データも影響が小さい（1.01〜1.13倍）。 なぜ英語・コードだけが膨らむのか トークナイザーはByte-Pair Encoding（BPE）という手法を使っており、「頻繁に出現する文字の組み合わせをひとつのトークンとして学習する」仕組みだ。4.7ではこのマージが英語やコードに対してより細粒度になった——つまり、以前は1トークンで表現していた単語やキーワードが複数トークンに分解されるようになっている。 英語1文字あたりのトークン効率は4.6の「4.33文字/トークン」から4.7では「3.60文字/トークン」に低下。TypeScriptに至っては3.66→2.69と大幅な悪化だ。 CJKはそもそも1文字が1〜2トークン相当の表現を取ることが多く、BPEのマージ効率の変動を受けにくい。これが非対称性の構造的な理由と考えられる。 実務への影響 Claude Codeユーザーへ Claude Codeのプロンプトには英語のコードやMarkdown、設定ファイルが大量に含まれる。実測で7種のリアルファイルの加重平均は1.325倍。Maxプランの利用枠が同じなら、実質的な処理量は約25%減ると考えてよい。コンテキストウィンドウの消費ペースも速くなる。 具体的には、 長いシステムプロンプトやCLAUDE.mdを使っている場合、キャッシュプレフィックスのコストが上昇 レートリミットに到達するタイミングが早まる 1回のセッションで扱えるコンテキスト量が減る 日本語中心のワークロードは影響軽微 日本語のドキュメント作成、日本語コメント付きコード、日本語プロンプトを主に使う場合は、比率がほぼ1.0のため実質的な変化はない。これは日本のユーザーにとって重要な朗報だ。 APIを直接使うエンジニアへ count_tokens エンドポイントは無料で使えるため、既存のプロンプトをOpus 4.7で事前計測しておくことを強く勧める。想定より早くコスト上限に達するケースが出てくる可能性がある。 なぜAnthropic はトークン数を増やしたのか 公式の説明では「より細粒度のトークン表現により、モデルの推論精度が向上する」とされている。細かく分割したほうが複雑なパターンを学習しやすいという設計上の判断だ。 ただし、今回の計測はあくまで「コストの変化」を示すものであり、「性能向上が本当にコスト増に見合うか」については別途検証が必要だ。 筆者の見解 正直に言えば、トークナイザーの変更は地味に見えて実は大きな話だ。ユーザーが意識しないところで消費量が増え、体感として「なんか遅くなった」「上限に当たりやすくなった」という形で現れる。これは透明性の問題でもある。 一点、データとして非常に興味深いのが日本語・中国語がほぼ影響を受けていないという事実だ。英語・コード中心のユーザーと、日本語・アジア系言語中心のユーザーとで、実質的なコスト構造が違うモデルになっている。日本のエンジニアは「日本語で書けば節約できる」という逆説的なインセンティブを得たとも言える。 とはいえ、実務では英語コードベースを扱う場面が多い。その前提で考えると、プロンプト設計のスリム化——不要なコンテキストを削る、キャッシュを適切に活用する——が以前より重要になってくる。これは良い設計習慣の後押しとも取れるし、余計な負担とも取れる。どちらに転ぶかは、使い方次第だ。 今後のモデルアップデートのたびにトークナイザーが変わるなら、コスト見積もりの前提を毎回見直す必要が生じる。この種の実計測を習慣化しておくことが、APIを本番利用するチームには不可欠になっていくだろう。 出典: この記事は Claude Opus 4.7 costs 20–30% more per session の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは今週、Windows 11のDevチャンネルおよびBetaチャンネル向けにプレビュービルドを配信した。今回の更新はWindows Helloの改善、プライバシーコントロールの強化、設定アプリやファイルエクスプローラーの使い勝手向上が中心となっている。地味に聞こえるかもしれないが、実務に直結する変更が含まれており、IT管理者は要注目だ。 Windows Helloの改善——認証体験がより洗練される Windows Helloは、パスワードレス認証の中核を担うMicrosoftの生体認証フレームワークだ。今回のビルドではそのエクスペリエンスが改善されており、顔認証・PIN認証の安定性や設定フローの見直しが含まれているとされる。 Windows Helloはもともと正しい方向性の技術だが、企業導入においては「互換性のあるカメラを別途調達する必要がある」「古いPCでは顔認証が使えない」といったハードルもあった。ソフトウェア側が成熟するにつれ、こうした体験の差が埋まっていくのは歓迎すべきことだ。 プライバシーコントロールの強化——設定が探しやすくなる 設定アプリのプライバシー関連セクションが整理・強化された。Windows 11はリリース当初からプライバシー設定の項目が多く、どこで何を制御できるのか分かりにくいという批判があった。今回の改善はその問題に正面から向き合った変更とみられる。 IT管理者の視点では、エンドユーザーがプライバシー設定を自分で変更できてしまう範囲と、MDM（Intuneなど）で組織管理できる範囲のバランスが常に課題となる。設定UIが整理されることでユーザーの「誤操作」や「意図しない設定変更」が減るなら、管理側にも恩恵がある。 ファイルエクスプローラーの改善 ファイルエクスプローラーも継続的に改善が続いている。Windows 11世代でタブ機能やモダンUIが導入されて以来、細かい挙動の安定化と機能追加が続いている状況だ。具体的な変更内容はビルドノートで確認が必要だが、日常的に使うツールだけに小さな改善でも積み重ねの効果は大きい。 実務への影響 DevチャンネルとBetaチャンネルの違いを意識する Devチャンネルは最新の実験的機能が入るが安定性は保証されない。Betaチャンネルは次期安定版に向けた機能検証が主で、エンタープライズパイロット用途に向いている。今回の変更がいつ安定版（GAチャンネル）に降りてくるかを見極めながら、自社の展開計画に組み込む判断が必要だ。 Windows Updateのタイミング判断 ここ最近、Windows Updateを即時適用したら問題が出た、という報告が散見されるようになっている。数日様子を見てからパッチを当てる判断も、リスク管理の観点では十分に合理的だ。ただし「様子を見る」と「永遠に当てない」は別物。期間を決めて判断する運用フローを整えておきたい。 パスワードレス移行の機会として捉える Windows Helloの改善は、まだパスワードレス移行を進めていない組織にとって好機だ。Microsoft Entra IDとの組み合わせでパスワードレス認証を段階的に導入する際の第一歩として、まず対応ハードウェアの棚卸しから始めるとよいだろう。 筆者の見解 Windowsの細かいビルドを毎回深追いする意義は、正直なところ薄れてきていると感じている。リリースペースが上がった分、各ビルドの「重み」が下がっているからだ。 その中で今回のアップデートが評価できるのは、Windows Helloの改善やプライバシー設定の整理が「正しい方向への地道な積み上げ」だからだ。派手さはないが、こういう地道な改善こそがWindowsをエンタープライズで長く使い続けられるプラットフォームたらしめている。 パスワードレス認証の普及は、セキュリティの文脈でもユーザー体験の文脈でも避けて通れない流れだ。Microsoftにはこの分野で実績があるし、Windows Hello + Entra IDの組み合わせは実用上も十分な水準に達している。この方向性をさらに磨き込んでほしいと思う。エンドポイントのアイデンティティ管理は、ゼロトラストアーキテクチャの入り口に位置する最重要要素だからだ。 Windowsの更新は今後も続く。すべてを追うのではなく、自分の組織に影響のある変更を選び取る目を持つことが、これからのIT管理者には求められている。 出典: この記事は Windows 11 gets improved privacy controls, better Windows Hello, and more in new builds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のサイバーセキュリティ機関CISAが、Apache ActiveMQに存在する高深刻度の脆弱性（CVE-2026-34197）が実際の攻撃で悪用されていることを確認した。この脆弱性の最大の特徴は、13年間にわたって見過ごされてきたという点にある。パッチは2026年3月30日に提供されたが、既に攻撃者に悪用されている以上、対象システムを運用する組織は一刻も早い対応が求められる。 Apache ActiveMQとは——「縁の下の力持ち」が狙われた Apache ActiveMQはJavaベースのオープンソースメッセージブローカーで、アプリケーション間の非同期通信を担う。マイクロサービスアーキテクチャや企業内SOA基盤に広く使われており、日本の大企業でも「気づいたら使っていた」という形で稼働しているケースが少なくない。 今回のCVE-2026-34197は入力検証の不備に起因する。認証済みの攻撃者がインジェクション攻撃を通じて任意のコードをリモート実行できる。発見したHorizon3の研究者は、AIを活用した解析ツールを使ってこの欠陥を掘り起こした——人間の目が13年間見落としてきたものを、AIが別の角度から発見したというわけだ。 パッチ済みバージョンはActiveMQ Classic 6.2.3 および 5.19.4。これ以前のバージョンを使用しているシステムは即時アップデート対象と考えてほしい。 CISAがKEVカタログに追加、政府機関に4月30日までの対応を命令 CISAは今回の脆弱性を「既知の悪用済み脆弱性（KEV: Known Exploited Vulnerabilities）カタログ」に追加し、連邦政府の民間機関（FCEB）に対して4月30日までのパッチ適用を義務付けた。 脅威監視サービスShadowServerの調査では、インターネットに公開されたActiveMQサーバーが現時点で7,500台超確認されている。これらはすべて潜在的な攻撃対象だ。 Horizon3はログによる侵害確認方法も公開している。ActiveMQブローカーのログで以下のシグネチャを探すとよい： brokerConfig=xbean:http:// クエリパラメータを含む不審な接続 内部トランスポートプロトコル VM を使用した異常なブローカー接続 ActiveMQは繰り返し狙われてきた「常連ターゲット」 ActiveMQに対する大規模攻撃は今回が初めてではない： CVE-2023-46604: TellYouThePassランサムウェアグループがゼロデイとして悪用 CVE-2016-3088: これも実際の攻撃で確認済み Horizon3が指摘するように、「ActiveMQに対する攻撃手法とポスト・エクスプロイテーションの技術は攻撃者の間で広く知られている」。過去の悪用実績があるということは、攻撃のTTP（戦術・技術・手順）が体系化されているということでもある。今回の新たな脆弱性情報は、既存の攻撃ツールキットに組み込まれるのが早い。 実務への影響——日本の現場で今すぐ確認すべきこと 1. バージョン確認と即時更新 ActiveMQ Classic 6.2.3 / 5.19.4 未満のバージョンは即時更新対象。まず環境内のActiveMQインスタンスを洗い出すことから始めよう。コンテナや古いオンプレサーバーで「存在を忘れていた」インスタンスが潜んでいないか確認する。 2. インターネット露出の排除 7,500台超がインターネットに公開されているという数字は衝撃的だ。ActiveMQブローカーはそもそも外部から直接アクセスさせるべきではない。VPCやプライベートサブネット、ファイアウォールで外部からのアクセスを遮断しているか確認する。 3. ログ監視と侵害確認 上述のシグネチャを使った侵害確認を今すぐ実施してほしい。パッチ適用前に既に侵害されていた場合、パッチだけでは不十分だ。 4. 認証強化 「認証済み攻撃者」が前提の脆弱性だが、認証情報の漏洩（フィッシング、クレデンシャルスタッフィング等）と組み合わせると実質的に誰でも悪用できる。ActiveMQの認証設定を見直し、最小権限の原則が守られているか確認する。 筆者の見解 「13年間見過ごされていた」という事実に、私は正直ゾッとした。 ActiveMQのような枯れたミドルウェアは、「長く使われてきた＝安定している＝安全」という誤解が生まれやすい。しかし実態は逆で、「長く使われてきた＝長い間、潜在的な脆弱性が眠っていた可能性がある」だ。今動いているから大丈夫、という思考が最も危険な盲点になる。 興味深いのは、この欠陥がAIによる解析で発見されたという点だ。人間の研究者が13年間見落としてきたものを、AIが別の視点から引っ張り出した。これは防御側にとっての朗報だが、同時に攻撃側が同じアプローチで「まだ誰も気づいていない脆弱性」を大量発掘する時代が来ることを示唆している。セキュリティチームにもAIを活用した継続的な脆弱性スキャンの仕組みが必要になる。 ゼロトラストの文脈で言えば、今回の件はまさに「境界型セキュリティの限界」の典型例だ。ネットワーク境界で守っている気になっていても、内部の古いミドルウェアが足元を崩す。ネットワーク層・認証層・認可層の多層防御と継続的なアセット管理——「存在すら忘れていたActiveMQサーバー」を減らすことが、実は最も効果的な対策になる。 レガシー基盤と向き合い続けている日本の現場にとって、今回の件は「明日は我が身」の警告として受け止めてほしい。 出典: この記事は CISA flags Apache ActiveMQ flaw as actively exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンドポイント保護ツールを導入していれば安心——そんな前提が今また崩されつつある。セキュリティ企業Sophosが最近公開したレポートで、「Payouts King」と呼ばれるランサムウェアグループがQEMUという正規のオープンソース仮想化ツールを悪用し、感染端末の上に隠し仮想マシン（VM）を展開することでエンドポイントセキュリティを完全に回避している実態が明らかになった。 QEMUを「隠れ蓑」にする攻撃の仕組み QEMUはLinuxやWindowsの開発者に広く使われているCPUエミュレータ・システム仮想化ツールだ。その特性上、ホスト側のセキュリティソリューションはVM内部をスキャンできない。これを逆手に取ったのが今回の手口である。 攻撃者は感染端末に侵入後、TPMProfiler という名前のスケジュールタスクを作成し、SYSTEMユーザー権限でQEMU VMをひっそりと起動する。仮想ディスクはデータベースファイルやDLLファイルに偽装されており、一見すると正規ファイルと区別がつかない。 VM内部ではAlpine Linux 3.22.0が動作しており、以下のような攻撃ツール一式が搭載されている。 AdaptixC2 — コマンド＆コントロール（C2）フレームワーク Chisel — リバースSSHトンネリングツール BusyBox — 軽量Unixコマンドセット Rclone — クラウドストレージへのデータ持ち出しツール リバースSSHトンネルを通じてVM内から外部C2サーバーへの通信が確立されるため、ホスト側のネットワーク監視をも回避できる。QEMUによるVM悪用の手口は3AMランサムウェアやLoudMinerなど過去の事例にも見られるが、Payouts Kingはそれをより洗練させた形で組み込んでいる。 多彩な初期侵入経路——VPNからTeamsまで Sophosが追跡するSTAC4713キャンペーン（2025年11月以降観測）では、初期アクセスにさらされた状態のSonicWall VPN、およびSolarWinds Web Help Desk脆弱性（CVE-2025-26399）が悪用されている。 注目すべきは、より新しい攻撃手法としてMicrosoft Teamsを使ったソーシャルエンジニアリングが確認されていることだ。攻撃者はITスタッフを装って従業員に接触し、QuickAssist（Windowsに標準搭載のリモートサポートツール）をダウンロード・実行させる。これはかつてBlackBastaグループが多用した手口と一致しており、ZscalerのレポートによればPayouts KingはBlackBastaの元アフィリエイトメンバーによって運営されている可能性が高い。 侵入後はvssuirun.exeでVSSシャドウコピーを作成し、NTDS.dit・SAM・SYSTEMハイブといったドメイン認証情報の宝庫を抜き取る。暗号化にはAES-256（CTR）＋RSA-4096を採用し、大容量ファイルには断続暗号化（intermittent encryption）を使うことで処理速度を確保しながら検出を困難にしている。 実務への影響——日本のIT管理者が今すぐ見直すべきこと 1. 正規ツールの実行制御を強化する QEMU、Rclone、Chiselはいずれも正規の業務ツールとして使われることがある。これらを一律に禁止するのではなく、「誰が・どのマシンで・いつ」実行するかを管理する仕組みが必要だ。Windows Defender Application Control（WDAC）やAppLockerによるアプリケーション許可リスト管理を改めて見直してほしい。 2. Teams経由のソーシャルエンジニアリングに備える 「ITサポートからTeamsでメッセージが来たのでQuickAssistを起動した」という経路での侵害は、技術的な脆弱性ではなく運用上の隙を突いている。ヘルプデスクが正規の手順でどこからアクセス要求するかをユーザー教育として徹底しておく必要がある。 3. エンドポイントだけに頼らない多層防御の再確認 VM内部はエンドポイントセキュリティの視野外になる。ネットワーク層でのC2通信の検知（不審な外向きSSHトンネル等）、認証層でのドメイン認証情報の異常利用検知、そして認可層でのJust-In-Time特権管理を組み合わせることが、このような迂回攻撃への現実的な対抗手段になる。 4. VPNの露出面を縮小する STAC4713もSTAC3725もVPN装置の脆弱性を初期アクセスに使っている。SonicWall、Citrix NetScalerともにパッチの適用状況と公開ポートの棚卸しを早急に行ってほしい。 筆者の見解 この手口が示しているのは、「エンドポイントにエージェントを入れれば守れる」というモデルの限界だ。QEMUのような正規ツールをVM起動に使われると、プロセス監視ベースのEDRはその中身を見ることができない。攻撃者は常に「セキュリティツールが見ていない場所」を探しており、今回はそれが仮想化レイヤーだった。 ゼロトラストアーキテクチャの本質は「ネットワーク内にいるから信頼する」を廃止することにある。今回の攻撃でも、VM内からリバースSSHトンネルが外向きに張られた時点でネットワーク異常として検知できた可能性がある。ホスト側のEDRが無力化されても、ネットワークトラフィック分析・Identity保護・SIEM連携の組み合わせが機能していれば早期発見の余地はあった。 Teams経由のQuickAssist悪用については、正直なところMicrosoftには引き続き改善を期待したい。Quick Assistはエンタープライズ向けのセキュリティ制御オプションが強化されてきているが、「見知らぬ相手からのセッション要求を普通のユーザーがどう判断するか」という設計上の課題はまだ残っている。ユーザーが公式に提供された手段を最も安全に使える状況を整えてこそ、禁止に頼らない現実的なセキュリティが実現する。Microsoftがその方向でさらに踏み込むことを期待している。 エンドポイント一点に賭けるのは、もはや通用しない。多層防御の見直しを今すぐ始めてほしい。 出典: この記事は Payouts King ransomware uses QEMU VMs to bypass endpoint security の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が Microsoft Entra ID に待望のバックアップ・リカバリ機能を追加した。Entra 管理センター上でパブリックプレビューとして公開されたこの機能は、ディレクトリオブジェクトの自動バックアップと復元を標準で提供するものだ。「いつか必要になる」と分かっていながら、これまでサードパーティ製品や自前スクリプトで賄ってきた組織には、シンプルに朗報である。 何ができるようになったのか Microsoft Entra Backup and Recovery は、サポート対象のディレクトリオブジェクトを 1日1回自動的にバックアップし、最大5日分のスナップショットを保持する。管理者は Entra 管理センターから GUI 操作で過去のバックアップを参照し、誤って削除または変更されたオブジェクトを復元できる。 特に有効なシナリオとして想定されているのは以下の通りだ。 運用ミスによる誤削除: ユーザーアカウント・グループ・ロール割り当てなど、「消してから気づく」パターン セキュリティインシデント後の復旧: 攻撃者による不正変更や、条件付きアクセスポリシーの改ざん後の原状回復 構成変更の切り戻し: 設定変更が思わぬ副作用を生んだときのロールバック 現時点ではパブリックプレビューのため、対象オブジェクトの種類や復元の粒度に制限がある可能性がある。GA（一般提供）に向けてスコープが広がることが期待される。 なぜこれが重要か Entra ID（旧 Azure AD）は、Microsoft 365・Azure・Intune など多くのサービスの認証・認可の起点となるアイデンティティ基盤だ。ここに格納されるオブジェクトは「すべてのサービスへの鍵」に等しく、誤削除や不正変更のインパクトは計り知れない。 従来、Microsoft が提供する標準機能としては「ごみ箱（Recycle Bin）」があり、削除から30日以内であれば一部のオブジェクトは復元可能だった。しかし、削除以外の変更（たとえば条件付きアクセスポリシーの書き換えやグループメンバーシップの変更）には対応しておらず、タイムトラベル的な「変更前の状態への復元」は難しかった。 そこを補完するために、Entra Exporter のようなコミュニティツールや、Microsoft Graph API を叩く自前スクリプトで定期バックアップを実装している組織は少なくない。今回の機能はそれを ネイティブ機能として提供する点で価値がある。 実務への影響——日本の IT 管理者が押さえるべきポイント 1. 既存のサードパーティ製バックアップ製品との関係を整理する すでに Entra ID バックアップ目的でサードパーティ製品（例：IDFIX, Semperis DSP, AvePoint 等）を導入している組織は多い。今回の標準機能は「5日間保持・1日1回」というシンプルな仕様であり、監査ログとの突合、変更履歴の可視化、長期保持といった要件は引き続きサードパーティが担う場面が残るだろう。ただし「とりあえずバックアップがあれば十分」なレベルの用途では、コスト削減の検討材料になり得る。 2. バックアップの存在を「セキュリティインシデント対応手順書」に組み込む インシデントが起きてから「どこで何を復元できるか」を調べるのでは遅すぎる。今回の機能の存在をインシデントレスポンス手順書に明記し、Entra 管理センターの操作を事前に演習しておくことを推奨する。特に、条件付きアクセスポリシーが攻撃者に書き換えられた場合の復旧シナリオは一度通しで確認しておくべきだ。 3. Just-In-Time アクセスと組み合わせて多層防御を バックアップはあくまで「事後対応」の手段だ。「誤削除・改ざんをそもそも減らす」という観点では、Entra PIM（Privileged Identity Management） によるロール割り当ての時限化（Just-In-Time）や、重要な変更に対する多要素認証・承認フローの整備が先行すべき対策である。「常時アクセス権の付与は最大のリスク」という原則は、どれだけ優れたバックアップがあっても変わらない。 筆者の見解 正直に言えば、「なぜこれを5年前に作らなかったのか」 という気持ちを抑えることが難しい。Entra ID はすでに世界中の何十万という組織のアイデンティット基盤として稼働している。「バックアップはサードパーティで」という状況がこれだけ長く続いてきたことは、プラットフォームの信頼性という観点でもったいなかったと思う。 ...