Tech News JP

AIエージェントが社内データに触れ、ユーザーに代わって処理を自動実行するようになった今、「誰が・何に・いつアクセスしたか」を把握できない組織はガバナンスの死角を抱えることになる。Microsoft Purviewがそこに本格的に踏み込んだ。DSPM（データセキュリティポスチャー管理）のAI ObservabilityとInsider Risk Management for agentsが、2026年5月末にGenerally Available（GA）となる。 何が変わるのか 今回GAとなるのは、Roadmap ID 516032 として登録されていた機能群だ。パブリックプレビュー自体は2025年12月から始まっており、早期採用組はすでに評価段階にある。GA展開は2026年5月初旬に開始、5月末までに完了予定。 主な機能は大きく2つに整理できる。 DSPM – AI Observability AIエージェントがエンタープライズ環境内でどのような活動をしているかをリアルタイムに近い形で可視化する機能だ。具体的には以下が可能になる。 エージェントの行動ログの収集・分析 コンプライアンス違反の疑いがある行動の特定 組織ポリシーに沿ったガバナンスポリシーの適用 Insider Risk Management for agents こちらは従来人間向けに存在したInsider Risk Managementのエージェント版だ。知的財産の窃取・データ漏洩・セキュリティ違反といったリスクシグナルを複数のソースから相関分析し、ポリシーベースで検知・対応できる。プライバシー設計として、ユーザーはデフォルトで仮名化（pseudonymize）され、RBAC（ロールベースアクセス制御）と監査ログによってユーザーレベルのプライバシーが保護される点は評価できる。 ライセンスの壁——M365 E7またはAgent 365が必須 見落とせないのがライセンス要件だ。これらの機能はMicrosoft 365 E7またはAgent 365サブスクリプションがなければ使えない。現在のM365 E3やE5ライセンスでは対象外となる。 日本企業でE7を契約しているケースはまだ少ない。Agent 365は比較的新しいSKUであり、AIエージェントの本格活用に踏み切った組織向けの位置づけだ。「うちにはまだ関係ない」と思いがちだが、Copilot Studio・Azure AI Foundry・Microsoft 365 Copilotのいずれかを使ってエージェントを動かしているなら、今すぐ準備の検討を始めるべきフェーズに入っている。 日本のIT現場にとっての意味 日本のエンタープライズでは、AIエージェントの導入がやや遅れ気味だったが、2026年に入って急速に実案件が増えている。問題は、エージェントをとりあえず動かしているものの、「それが社内でどう動いているか」を把握している管理者が少ないことだ。 AIエージェントは本質的にNon-Human Identity（NHI）——人間ではないがシステムに代わってアクセスと処理を行う主体だ。人間の社員に適用していた内部リスク管理の考え方を、AIエージェントにも同等に適用する必要がある。Microsoft Purviewが今回この領域に手を伸ばしたのは、その認識に基づいた自然な流れと言える。 実務での活用ポイント 今すぐできる準備 エージェントの棚卸しから始める: 自組織のどのエージェントが企業データにアクセスしているかをリスト化する。Copilot Studio・Azure AI Foundryで作ったカスタムエージェントも含めて把握すること ライセンス計画を見直す: E7・Agent 365へのアップグレードが必要かどうか、コストと対応の必要性を天秤にかける。「エージェントを使っていないから不要」ではなく、「近い将来使うかどうか」で判断する ガバナンスポリシーを先に整備する: 機能がGAになってからポリシーを考えるのでは遅い。今のうちにセキュリティ・コンプライアンス担当と連携して、エージェントに適用すべき行動規範を文書化しておく DSPM有効化手順を確認する: 公式Learnページ（Microsoft Agent 365 Overview）にActivationの手順が記載されている。GA後に慌てないよう、プレビュー段階から読み込んでおくことを勧める 筆者の見解 AIエージェントのガバナンスは、今後のエンタープライズIT管理における最重要テーマの一つになる。その理由はシンプルで、ボトルネックは常に人間にあるからだ。業務効率を本当に上げようとするなら、AIエージェント＝Non-Human Identityが安全に・自律的に動ける仕組みが不可欠であり、そのためにはNHIの活動を可視化・管理する仕組みが土台として必要になる。 ...

GoogleがAndroid開発者向けに新しいコマンドラインインターフェース「Android CLI」を発表した。AIエージェントとの連携を前提に設計されており、従来に比べてAndroidアプリの開発速度を最大3倍に高速化できるという。エージェントベースの開発という潮流が、ついにモバイル開発の現場にも本格的に波及してきた。 Android CLIとは何か Android CLIは、Googleが開発したコマンドラインツールで、あらゆるAIエージェントから呼び出せるよう設計されている。従来のAndroid StudioやGradleベースのワークフローを補完する形で、エージェントがビルド・テスト・デプロイのループを自律的に回せるようにすることを主眼に置いている。 「any agent（任意のエージェント）」という表現がポイントだ。特定のAIツールやIDEに縛られず、MCP（Model Context Protocol）などの標準的なインターフェースを通じて接続できる設計になっている。これにより、開発者は自分が使っているエージェント環境をそのまま活かしつつ、Android開発のループに組み込むことができる。 3倍高速化の実態 発表によれば、Android CLIを使ったエージェント連携開発では、以下のような作業が自動化される： コードの生成・修正: エージェントが要件を理解し、コードを生成 ビルドとエラー解析: ビルドエラーをエージェントが自律的に解析・修正 テスト実行と結果フィードバック: テスト結果をループで処理し、次のアクションを決定 エミュレータとの連携: アプリの動作確認もエージェントが自律実行 人間が「ビルドして、エラーを見て、直して、また試して……」という繰り返しを手動でやっていた部分を、エージェントが自律的にループで処理することで、体感の開発速度が大きく変わる。3倍という数字は単純な処理速度ではなく、エージェントが自律ループを回すことによる待ち時間・手戻りの削減から生まれる数字だろう。 「任意のエージェントで動く」設計の意味 注目すべきは、特定のツールへの依存を避けた設計哲学だ。Googleは今回、自社のAIとの統合だけを前面に出すのではなく、「どのエージェントでも使える」ことを強調した。これはMCPの普及によってエージェントのインターフェースが標準化されつつある現状を踏まえた、現実的かつオープンな判断と言える。 開発者は自分のワークフローやエージェント環境を変えることなく、Android CLIをツールとして呼び出す形で統合できる。エコシステムの分断を最小化しながらエージェント対応を進める姿勢は、実用的な選択だ。 実務への影響 Androidアプリを開発・保守しているエンジニアにとって、Android CLIは試す価値のあるツールだ。特に以下のケースで恩恵が大きい： 反復的なバグ修正サイクル: クラッシュログからの原因特定→修正→再テストのループをエージェントに任せる UIの微調整作業: レイアウト変更のビルド確認をエージェントが自律的に繰り返す レガシーコードの段階的リファクタリング: ビルドが壊れないことを確認しながら少しずつ進める IT管理者・DevOpsチームの観点では、CI/CDパイプラインへのエージェント統合という切り口で注目できる。従来はCIが「ビルドして報告して終わり」だったのに対し、エージェントが「ビルドして、失敗したら自分で直して、成功するまで回す」ループを形成できるようになる可能性がある。 現時点ではAlpha段階とみられるため、プロダクション環境への全面適用は時期尚早だが、開発環境での試験導入は今すぐ始めて良い段階だ。 筆者の見解 「エージェントに3倍速くさせる」という謳い文句は、ある意味で副操縦士パラダイムの限界を超えようとしている動きだと感じる。 AIが「提案して、人間が判断して、実行して」という流れを繰り返す設計では、人間の認知負荷はほとんど減らない。本当の高速化は、エージェントが目的を理解して自律的にループを回し、人間は結果だけを確認するという設計から生まれる。Android CLIが「任意のエージェントで動く」ことを強調した背景には、この自律ループの設計を開発者に委ねるという思想があるように見える。 この方向性は正しい。エージェントが自律的にビルド→エラー解析→修正→再ビルドのサイクルを回せるようになれば、開発者は本当に価値のある判断——何を作るか、どう設計するか——に集中できる。 ただし、エージェントに任せる範囲の設計は慎重にやる必要がある。「とりあえずエージェントに全部やらせる」では、品質や意図の乖離が積み重なる。人間がどこで介入するかをきちんと設計したうえで、ループを回す仕組みを作ることが、この種のツールを活かすカギになる。 モバイル開発の現場にもエージェントループが本格的に入ってくる流れは、もう止まらない。Android CLIはそのひとつの入口だ。日本のAndroid開発チームも、この変化をただ眺めているだけでなく、小さなプロジェクトから試し始める価値は十分にある。 出典: この記事は Android CLI: Build Android apps 3x faster using any agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ジョージ・オーウェルの『1984年』が出版されたのは1949年。冷戦前夜のディストピア小説として名高いこの作品に、現代のAI生成コンテンツ問題を予言するかのような装置が登場することは、あまり知られていない。Open Cultureの記事がその符合を改めて指摘し、Hacker Newsでも話題を集めた。テクノロジーの文脈でオーウェルを読み直すと、彼の洞察の鋭さに改めて驚かされる。 「真理省」に存在した自動コンテンツ生成機 『1984年』の主人公ウィンストン・スミスが勤める「真理省（Ministry of Truth）」の内部には、プロレタリア向けコンテンツを大量生産する部門が存在する。そこで使われる「ヴァーシフィケーター（versificator）」という装置は、人間の介入なしに楽曲・詩・小説を機械的に生成し続ける。 原文には「ゴシップ紙、センセーショナルな廉価小説、セックス描写のあふれる映画、そして特殊な万華鏡のような機械で完全に機械的手段によって作曲された感傷的な歌——これらがすべてここで生産された」と書かれている。「人間の介入なしに」という一節が、現代の生成AIによるコンテンツ自動生成と驚くほど重なる。 「AIスロップ」とは何か 「AI slop（AIスロップ）」とは、生成AIを使って大量生産された低品質コンテンツを指す俗語だ。文法的には正しく、一見それらしく見えるが、深みがなく使い回し的で、人間の思考の痕跡がほとんど感じられない——そういった記事・画像・動画がSNSやウェブを埋め尽くしつつある現象を指す。 オーウェルが鋭かったのは、こうした低品質コンテンツが「支配者の悪意によって押し付けられる」のではなく、「大衆自身が求めるから存在する」という構造を見抜いていた点だ。プロレタリアたちは真理省が作るゴシップや安っぽい歌を喜んで消費する。今日のAIスロップも、それを好むオーディエンスがいるから拡散する。プラットフォームのアルゴリズムは需要に応答しているにすぎない。 アシモフが「外れ」と断言した予言が、30年後に的中した 面白いのは、アイザック・アシモフが1980年に書いた『1984年』評だ。アシモフは「技術予測として見れば的外れ」と評した。確かに1980年時点では、機械が質の高いコンテンツを生成するなど夢物語だった。しかし2020年代の大規模言語モデル（LLM）の台頭は、アシモフの評価を逆転させた。オーウェルが「センサー目線」で描いた管理社会の道具が、テクノロジーの側から現実に追いついてきたのだ。 これはSFの「予言」というより、人間の本質的な欲求と技術の方向性を見抜いた洞察の的中だろう。オーウェルは1940年代イギリスの「使い捨てエンタメ」を観察し、それが極限まで自動化・大量化された未来を描いた。その推論の延長線上に、生成AIがあった。 実務への影響——情報の「識別力」が資産になる時代 日本のIT現場・ビジネス現場にとって、AIスロップ問題は対岸の火事ではない。 コンテンツ制作・マーケティング部門では、SEO目的のAI記事量産が既に問題化している。Googleはスパムポリシーを強化しているが、人間の目でAI生成コンテンツを見分けるのはますます難しくなっている。「作れる量」が増えた分、「選ぶ力」と「質を担保する仕組み」がより重要になる。 情報収集・意思決定の場面では、ウェブ検索の結果にAIスロップが混入するリスクが高まっている。信頼できる一次情報源（公式ドキュメント、査読済み論文、実績ある専門家のブログ）を直接参照する習慣が、エンジニアには特に求められる。 社内ナレッジ管理でも、AI生成の議事録・要約・ドキュメントが増えるにつれ、「それは本当に正確か」を検証するレビュープロセスの設計が必要になる。AIを使うこと自体が問題なのではなく、AIの出力をノーチェックで信頼する運用設計が問題だ。 具体的な対策として、以下を検討してほしい： 出典の一次確認習慣：AI要約を読んだら、元の一次情報を必ず確認する 人間レビューのゲート設計：重要なアウトプットには必ず人間の目を通すワークフローを組む 品質基準の明文化：「AIが書いたから許容する」ではなく、アウトプットの質基準を人間が設定し維持する 筆者の見解 オーウェルの予言的正確さに感心しつつも、私はこの問題を悲観的には見ていない。むしろ「淘汰の時代」の入り口だと思っている。 AIが大量の「そこそこのコンテンツ」を生成できるようになった今、逆説的に価値が上がるのは「明確に人間の思考が宿ったアウトプット」だ。独自の経験に基づく判断、文脈を読んだ意思決定、失敗から学んだ知見——こうした要素は、今の生成AIが最も苦手とする領域だ。 一方で、AIを「大量生産ツール」としてしか使わないアプローチは、確かにスロップ製造装置になってしまう。真価は「人間がやるべき判断と、AIが担うべき処理」を設計できる人間にある。ヴァーシフィケーターを運用していた真理省の問題は、機械を作ったことではなく、機械に「何を作らせるか」の設計思想にあった。 オーウェルが最後に示した「個人の識別力が今こそ最も価値ある」という結論は、2026年の私たちへのメッセージとして読める。情報を追いきれない時代だからこそ、追う量を減らし、深く使い、自分の頭で判断する。それが今求められるリテラシーだと思っている。 出典: この記事は George Orwell Predicted the Rise of “AI Slop” in Nineteen Eighty-Four の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月13日、Europolが主導する大規模なサイバー犯罪取り締まり作戦「Operation PowerOFF」の最新フェーズが実施された。21カ国が連携し、DDoS攻撃代行サービス（いわゆる「Booterサービス」）の利用者75,000人以上に警告を送るとともに、53のドメインを閉鎖。4名の逮捕と25件の家宅捜索令状の執行が確認されている。日本もこの作戦に参加しており、国際的なサイバー犯罪対策の枠組みに確実に組み込まれていることがわかる。 Booterサービスとは何か 「Booterサービス」とは、DDoS攻撃能力を月額・従量課金でレンタルできるプラットフォームのことだ。攻撃インフラの実体は、乗っ取られたルーターやIoT機器で構成されるボットネットである。利用者はターゲットのIPアドレスを入力するだけで、技術的な知識がなくても大規模なDDoS攻撃を仕掛けられる。 悪質なのは、一部のサービスが「ストレステストツール」を名乗って合法性を装っている点だ。しかし実態として、ターゲットのサーバーやネットワークの所有権確認が行われておらず、誰でも任意のサービスを標的にできる。これは事実上、攻撃ツールの販売にほかならない。 過去のOperation PowerOFFフェーズでは、主要インフラの解体と300万件以上の犯罪アカウント情報を含むデータベースの押収が行われており、今回はその蓄積データを活用した「利用者への直接警告」が大きな特徴となっている。 「予防フェーズ」への移行が重要な転換点 Europolは今回の作戦について、単なる摘発にとどまらず「予防フェーズ」への移行を明言している。具体的には以下の取り組みが進められる。 検索エンジン広告の活用: DDoSツールを探している若年層に向けて、違法性を訴える広告を表示 検索結果からの削除: 違法サービスを宣伝する100件以上のURLを検索インデックスから排除 オンチェーン警告: 違法決済に紐づくブロックチェーンアドレスへの警告メッセージ付与 この「取り締まり＋認知変容」の二段構えは、技術的なインフラ破壊だけでは再犯・模倣を防ぎきれないという現実認識から来ている。検索エンジン広告を使った啓発は特に興味深い——DDoS-for-hire を利用する層は、比較的ライトな動機（ゲームの対戦相手を落とす、元交際相手への嫌がらせ等）の若年ユーザーが多いとされており、そこへの予防的アプローチは理にかなっている。 日本のIT現場への影響 日本は今回の作戦参加国の一つとして明示されており、国内でもDDoS-for-hireの摘発・捜査が動いていることを意味する。IT管理者・セキュリティ担当者として押さえておくべきポイントを整理する。 インバウンド攻撃の変化を観察する: 今回の作戦によって既存のBooterサービスが複数閉鎖されたため、一時的に攻撃トラフィックが減少する可能性がある。ただし、残存するサービスへのトラフィック集中や、新サービスの立ち上げによる再活性化も十分ありえる。過信は禁物だ。 自社サービスのDDoS耐性を見直すタイミング: 攻撃インフラが洗い替えされるこの時期は、逆に防御側がインフラを整備する好機でもある。CDNレイヤーでの吸収、レート制限の適切な設定、クラウドプロバイダーのDDoS保護サービスの評価を今一度行っておきたい。 ログの保全期間を確認する: 今回の捜査では過去のデータベースが活用されている。自社がISPやクラウド事業者に対して、ログ保全の義務や協力体制を把握しているかどうかも確認しておくべきポイントだ。特にインシデントレスポンス計画（IRP）に「外部機関との連携フロー」が明記されていない組織は、この機会に整備を検討してほしい。 筆者の見解 セキュリティ分野は正直、細かい話が多くて得意領域とは言えない。だが今回の作戦は「技術的な摘発の次に何をするか」という問いに対して、一つの答えを示している点で注目に値する。 DDoS-for-hireの問題は、技術の民主化が持つ光と影の典型例だ。かつては国家レベルのリソースが必要だったDDoS攻撃が、月額数十ドルで誰でも実行できるサービスとして流通してしまっている。これを「禁止すれば解決する」アプローチだけで対処しようとしても限界がある。インフラを潰しても需要があれば別のサービスがすぐに生えてくる。 だからこそ、今回の「予防フェーズ」への移行は正しい方向だと思う。検索広告で「そのツール、使ったら犯罪ですよ」と先手を打つのは、禁止より使い始める前に意識を変える戦略だ。完全な解決策にはならないが、攻撃者の裾野をある程度狭める効果は期待できる。 ゼロトラストの文脈で言えば、DDoS対策もネットワーク境界の防御一本槍から、トラフィックの振る舞い分析・異常検知・自動遮断といった多層防御に移行していかなければならない。「今動いているから大丈夫」という発想でルーターのファームウェアを放置していると、気づかないうちに攻撃インフラの一部に組み込まれている——そういう時代だ。 国際的な連携が着実に深まっている点は素直に評価したい。日本が参加国として名前が挙がっていることも、数年前と比べれば大きな前進だ。ただ、こうした作戦の成果が日本国内の企業やエンジニアに届くまでの情報流通速度は、まだまだ改善の余地がある。英語メディアを追わないと情報が入ってこない状況が続いているのは、業界全体の課題として認識しておきたい。 出典: この記事は Operation PowerOFF identifies 75k DDoS users, takes down 53 domains の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Android 17の最終ベータ（Beta 4）がGoogleからリリースされた。正式リリースを目前に控えたこのバージョンには、モバイルプラットフォームの基盤を揺るがしかねない2つの重要な変更が含まれている——「積極的なメモリ管理」と「耐量子暗号（Post-Quantum Cryptography / PQC）」への対応だ。どちらも地味に見えて、実務への影響は大きい。 バックグラウンドアプリへの「退場勧告」が厳しくなる Android 17では、バックグラウンドで肥大化したアプリのプロセスをより積極的に終了させる新しいメモリ管理機構が導入された。長年のAndroidユーザーが体感してきた「なんか重くなってきた」という現象の原因のひとつ——バックグラウンドに居座り続けるアプリプロセス——への直接的なメスだ。 具体的には、端末のメモリ使用率が高まった際に、Low Memory Killer（LMK）の閾値を引き上げ、より積極的にバックグラウンドプロセスを回収する。ユーザー視点では「全体的にサクサクする」という恩恵がある一方、バックグラウンド常駐を前提に設計されたアプリは、より頻繁に再起動を余儀なくされる可能性がある。 開発者にとって重要なのは、「プロセスがいつ終了しても正しく再開できる設計」がこれまで以上に必須になるという点だ。ViewModel + SavedStateHandle の組み合わせ、あるいは WorkManager を活用した堅牢な状態管理は、もはや「できればやっておく」ではなく「やっていなければ問題が出る」レベルに引き上げられつつある。 耐量子暗号（PQC）の組み込み——「今じゃなくていい」が一番危ない もう一つの注目ポイントが、NIST標準化された耐量子暗号アルゴリズム、ML-KEM（旧称 Kyber）などのOS基盤への統合だ。 「量子コンピュータはまだ実用化されていないのに、なぜ今？」と感じる方も多いだろう。ここで理解しておきたいのが 「Harvest Now, Decrypt Later（今収穫して後で解読する）」 という攻撃手法だ。現在暗号化されたデータを大量に収集しておき、量子コンピュータが実用化された将来に一気に解読するという脅威は、すでにCISAや各国政府機関が現実の懸念として警告を発している。 医療記録、金融取引ログ、機密ビジネスデータ——「今は安全でも、将来解読されたら致命的」なデータを扱う組織にとって、PQC移行は単なる技術的好奇心ではなくリスク管理の問題だ。 AndroidがOS基盤レベルでPQCを組み込むことで、アプリ開発者はサードパーティライブラリに独自実装を頼ることなく、プラットフォーム標準のAPIを通じて耐量子暗号を利用できるようになる。これは実装の標準化・簡易化という観点でも大きな前進だ。 実務への影響 Androidアプリ開発者向け プロセス死の前提設計を徹底する: メモリ管理の積極化に備え、onSaveInstanceState や WorkManager を使った堅牢な状態保存を標準パターンとして確立しておく Beta 4でのテストを今すぐ: 最終ベータは安定版に限りなく近い。エミュレータまたは実機で自社アプリの動作確認を行う最後のチャンス PQC対応のロードマップ検討開始: 即時対応は不要でも、TLS 1.3 + ML-KEMハイブリッドモードへの移行計画を今から考え始めるタイミング エンタープライズIT管理者向け MDM（Intune / Jamf 等）の動作確認: メモリ管理の変更がMDMエージェントのバックグラウンド動作に影響する可能性がある。管理対象デバイスでの事前検証を推奨 インフラ全体のPQC移行計画を: Androidだけ先進化しても、バックエンドのTLS設定・VPN・証明書管理が古い暗号方式のままでは意味がない。エンドポイントと基幹インフラの暗号強度を整合させる観点で計画を立てる 筆者の見解 耐量子暗号への対応について言えば、「まだ先の話」と油断しているうちにリスクが積み上がる——ゼロトラストアーキテクチャへの移行と同じ構図がここにある。「今動いているから大丈夫」という安心感が最大の敵であることは、セキュリティの世界で繰り返し証明されてきた事実だ。 特に日本のエンタープライズ環境では、「基幹システムに触れたくない」という文化的な慣性が強く、PQC移行の着手が大幅に遅れるリスクがある。モバイルOSが先行してPQCを標準搭載することで、エンドポイントと基幹インフラの間に「暗号強度の不整合」が生じる可能性も出てくる。部分最適を積み重ねると全体として非効率で脆弱な状態になりかねない——全体最適の視点で、今から計画することが不可欠だ。 メモリ管理の改善については、即効性のある快適性向上という恩恵がある一方、技術的負債を抱えた「なんとなく動いていたアプリ」が炙り出される踏み絵にもなりうる。プロセスが突然終了しても正しく再開できる設計——モバイル開発の基本中の基本が、あらためて問われるタイミングだ。 Android 17の正式リリースは2026年第3四半期が予想されている。最終ベータが出た今こそ、本番対応の準備を始める「今」だ。 出典: この記事は Android 17’s final beta arrives with a killer new feature for bloated, laggy apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windowsの防御を担うはずのMicrosoft Defenderそのものに、特権昇格の脆弱性が潜んでいた——しかもそのうち2件は、この記事を書いている時点でまだパッチが提供されていない。Huntress Labsの報告により、3件のゼロデイ脆弱性が実際の攻撃に使われていることが確認された。組織のWindows環境を守る立場のエンジニアや管理者にとって、対応を急ぐべき状況だ。 何が起きているか 今回の発端は、「Chaotic Eclipse」（別名 Nightmare-Eclipse）と名乗るセキュリティ研究者による、PoC（概念実証コード）の意図的な公開だ。MicrosoftのSecurity Response Center（MSRC）との調整プロセスに不満を持ったこの研究者が、4月初旬に3件分のエクスプロイトコードを相次いで公開した。 3件の脆弱性の概要は以下のとおりだ。 BlueHammer（CVE-2026-33825）——修正済み Microsoft Defenderのローカル特権昇格（LPE）脆弱性。4月の定例セキュリティ更新（Patch Tuesday）で対処済み。ただしHuntress Labsによれば、4月10日時点ですでに実攻撃に使われており、パッチ前から悪用が始まっていた。 RedSun——未修正 Defenderがクラウドタグ付きのマルウェアファイルを検知した際に、「検出した場所にそのファイルを再書き込みする」という奇妙な動作を悪用してシステムファイルを上書きし、SYSTEM権限を奪取する手法だ。Windows 10・Windows 11・Windows Server 2019以降のすべてが対象となる。4月のPatch Tuesdayを適用済みの環境でも影響を受ける点が厄介だ。 UnDefend——未修正 標準ユーザー権限でDefenderの定義ファイル更新を止められる脆弱性。これ単体では致命的ではないが、RedSunと組み合わせることで「検知を封じてから特権昇格」という流れが成立する。SSLVPN経由での侵害事例では、この2件が同一ホストで同時に使われていることが確認されている。 なぜこれが重要か DefenderはWindowsに標準搭載されており、追加コストなしで有効なセキュリティレイヤーとして機能している。その防御機構の内部ロジックが攻撃の踏み台になるという構造は、見逃せない。 特にRedSunの仕組みが象徴的だ。「マルウェアを検知したらファイルを元の場所に再配置する」という設計が攻撃ベクターになっている。セキュリティ機能の実装ミスが権限昇格の窓口を開いてしまう——これはネットワーク境界ではなく、エンドポイントの内部で起きていることだ。 また、SSLVPN経由での侵害という報告も示唆に富んでいる。ネットワーク境界を突破された後、端末内部での権限昇格に今回のゼロデイが使われている構図は、「VPNさえあれば安全」という旧来の前提がいかに脆いかを改めて示している。 実務への影響と今すぐできる対策 1. April Patch Tuesdayの適用状況を確認する BlueHammerの修正は4月の更新に含まれている。適用済みであれば1件は封じられている。MicrosoftのMUSE（Microsoft Update Catalog）やIntune/WSUS経由で未適用端末がないか確認しよう。 2. RedSun・UnDefendは「パッチなし」と理解した上で対策を立てる 現時点ではWorkaroundが公式に示されていない。多層防御の考え方で、エンドポイントへの初期侵入そのものを防ぐ層を厚くするしかない。具体的にはMFAの徹底、条件付きアクセスポリシーの強化、EDR/MDRによる異常な権限昇格の検知設定を見直すべきだ。 3. SSLVPNとネットワーク境界への過信を見直す 今回の攻撃ではSSLVPN経由の侵害が起点になっている。「VPN接続 = 信頼済み」とみなす設計は再検討する時期だ。ゼロトラストモデルへの段階的な移行——デバイスコンプライアンスチェック、Just-In-Timeアクセス、最小特権の徹底——が正しい方向性だ。 4. 「今は大丈夫」を根拠にしない Huntress Labsが観測したのは実際に侵害された環境だ。未修正の脆弱性は「いつか悪用されるかもしれない」ではなく「すでに悪用されている」という事実を出発点にリスク評価をし直してほしい。 筆者の見解 今回の騒動で改めて問われているのは、「脆弱性の責任ある開示」（Coordinated Vulnerability Disclosure）のあり方だ。Microsoftは公式声明でこのプロセスの重要性を述べているが、研究者側が「調整が機能しなかった」と判断してPoC公開に踏み切った背景は軽視できない。 MSRCは世界規模で膨大な報告を処理する組織だ。対応品質にばらつきが出ることは理解できる。ただ、その結果として未修正のゼロデイが実攻撃に使われる状況になっているとすれば、プロセスそのものを見直す理由は十分ある。Microsoftには、セキュリティ研究コミュニティとの関係をもう少し丁寧に扱う余地があるのではないか。開発力も影響力もある会社なのだから、そこで正面から勝負してほしいと思う。 RedSunの仕組みについては、率直に言って「設計として変だ」という研究者の指摘は的を射ている。検知したマルウェアを元の場所に書き戻す動作は、それだけ聞けば奇妙に映る。ただ、その実装判断の背景には何らかの理由があるはずで、修正対応の中でその説明もあってほしいところだ。 セキュリティに興味を持つエンジニアとして付け加えると、今回のような事案が積み重なるほど「境界型防御だけでは足りない」という当たり前の結論が強化される。端末内部での特権昇格を前提に、ゼロトラストアーキテクチャで「侵入後の動きを封じる」設計を日常業務に組み込むことが、現実的かつ持続可能な防御戦略だと考えている。 出典: この記事は Recently leaked Windows zero-days now exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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? の内容をもとに、筆者の見解を加えて独自に執筆したものです。