Tech News JP

MicrosoftがコラボレーションツールのLoop（Microsoft Loop）から、Copilotが生成するAIレキャップ（recap）機能を削除することを発表した。「AIをあらゆる場所に」という同社の戦略から見ると、これは異例中の異例——方向転換というよりも、静かな撤退に近い。 Microsoft Loop のAIレキャップとは何だったのか Microsoft LoopはNotion対抗として2023年にGAとなったM365のコラボレーションスペースだ。「ページ」「コンポーネント」「ワークスペース」という概念を使い、チームがリアルタイムに共同作業できる環境を提供する。 AIレキャップ機能は、このLoopワークスペース内の活動を自動的に要約し、「前回から何が変わったか」「誰が何をしたか」をCopilotがまとめて提示するというものだった。会議に出られなかった、しばらく離れていた、という場面で「キャッチアップ」を助けるのが主な用途として想定されていた。 なぜ廃止されるのか Microsoftが公式に詳細な理由を示しているわけではないが、背景として考えられる要因はいくつかある。 利用率の問題: レキャップ機能は使われていなかった可能性が高い。Loop自体がまだユーザーベースを拡大中であり、そのうえAI要約という付加機能はニッチな使われ方にとどまっていたと推測できる。 コスト対効果: CopilotはAzure OpenAIのAPIコストを消費する。利用率が低いまま維持するのは明らかに非効率だ。 品質の問題: AI要約の精度が期待値を下回っていた可能性もある。誤った要約、文脈を無視した要約は、むしろ混乱を招く。 いずれにせよ、「AI機能を追加する」方向だけでなく「使われないAI機能を削除する」という意思決定ができるようになったこと自体は、成熟の証とも言える。 実務への影響——日本のIT現場では まず、Loop自体の普及状況を確認しておきたい。日本でLoopを積極的に導入・活用している企業はまだ少数派だ。M365 E3/E5に含まれているため「使えるが使っていない」状態の組織が多く、今回の変更を意識しているユーザーも限られるだろう。 すでにLoopを活用している組織は、レキャップ機能に依存したワークフローがあれば代替手段を検討する必要がある。Teams のミーティング要約（Intelligent Recap）やOneNoteとの連携、あるいは手動でのサマリー作成に切り替えるのが現実的だ。 これからLoopを検討している組織にとっては、AIレキャップ廃止はほぼ影響なしと考えてよい。Loopの本質的な価値はリアルタイムコラボレーションにあり、AI要約はオマケ機能に過ぎなかった。 IT管理者へのヒント: MicrosoftのM365ロードマップ（Microsoft 365 Roadmap）を定期的に確認する習慣をつけておくこと。今回のような機能廃止は、ユーザーへの事前周知なしに進むことがある。Message Centerアラートの設定は必須だ。 筆者の見解 正直に言う。「Copilotあらゆるところに刺さります！」という数年間のMicrosoftのノリには、ずっと違和感を持っていた。LoopのAIレキャップも、使って感動した人より「要らなかった」と感じた人のほうが多かったんじゃないかと思っている。 だから今回の廃止は、「残念」ではなく「まあそうだよね」という感想だ。使われない機能を削るのは正しい。むしろ遅かった。 ただ、問題はその奥にある。Microsoftはここ数年、「Copilot」という名前を至るところに貼り付けてきた。M365 Copilot、GitHub Copilot、Windows Copilot、Copilot Studio……。機能の中身より名前の統一を優先して、結果として「Copilotって何なの？」という混乱を生んでいる。今回の廃止も、ロードマップの整理というよりは「コッソリ消した」に近い。 Copilotブランドの整理は急務だ。だが、AI基盤としてのMicrosoftの価値は揺るがない。Entra ID・M365・Azureという圧倒的なエコシステムを持っている会社は他にない。だからこそ、個々のAI機能の取捨選択はもっと大胆にやってほしい。今回のように「使われない機能を削る」判断を、もっと早く・もっと広くやれるはずだ。正面から勝負できる力があるのだから、薄く広く貼るより、本当に価値のある体験に集中してほしい。 がんばれ、Microsoft。本当に。 出典: この記事は Microsoft to strip AI-generated recaps from Loop in surprising move の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11上でEdgeへのユーザー誘導を強化する新たな手法を試験導入していることが明らかになり、GoogleをはじめとするブラウザベンダーやNGOで構成されるBrowser Choice Alliance（BCA）が強く反発している。静かに進むこの施策が、ユーザーの「ブラウザを選ぶ権利」を根底から脅かすものだとして、国際的な批判の声が上がっている。 何が起きているのか BCAが問題視しているのは、Windows 11のテスト段階で確認された挙動だ。ユーザーがChromeやFirefoxなどを既定ブラウザとして設定していても、特定の操作をトリガーにEdgeが再び前面に出てくるよう設計されているという。明示的な確認なしに「静かに戻す（quiet nudge）」仕組みであり、ユーザーが気づかないうちに選択が上書きされるリスクがある。 この手法はEUのデジタル市場法（DMA）が義務付ける「真の選択肢の提供」に反する可能性があり、日本を含む非EU圏でも競争法上の観点から問題提起されかねない水準だ。 Microsoftの「Edge推し」の歴史 MicrosoftがEdgeを優遇してきた歴史は長い。Windows 10以降、既定ブラウザの変更UIをわかりにくく設計したり、「Edgeを使ってみますか？」の通知を繰り返し出したりと、ソフトな強制が続いてきた。2022年にはEUの圧力を受けてブラウザ選択画面を復活させたが、今回の「静かな誘導」はその精神を骨抜きにするものだとBCAは主張する。 BCAにはGoogleのほか、Mozilla、Opera、Vivaldi、さらには消費者保護団体も名を連ねており、単純なライバル企業の嫌がらせではなく、ブラウザエコシステム全体の問題として訴えていることがわかる。 実務への影響——IT管理者はどう動くべきか 企業のIT環境では、ブラウザの標準化はセキュリティポリシーや社内システムの動作保証と直結する。ChromeやEdgeをグループポリシーで管理している組織にとって、OSアップデートやテスト機能のロールアウトによって既定ブラウザが意図せず変更されるリスクは無視できない。 今すぐ確認・対応すべきポイント： 既定ブラウザのポリシー固定: Intune や グループポリシー（GPO）で DefaultBrowserSettingEnabled を明示的にFalseに設定し、ユーザー操作・OS側の干渉両方をブロックする Windows 11の段階的ロールアウト監視: Insiderチャネルで確認された挙動が安定版に降りてくる前に、テナントの更新リングを確認しておく ブラウザ変更の監視ログ: Microsoft Entra（Intune）のデバイスコンプライアンスレポートに既定ブラウザの変更トリガーが記録されていないか定期チェック ゼロタッチ展開の見直し: 自動プロビジョニング後のブラウザ設定が期待通りか、テスト環境で確認するステップを追加する 筆者の見解 長年Microsoftの技術を追いかけてきた立場から、率直に言いたい。Edgeは技術的に良いブラウザだ。 Chromiumベースになって以降、安定性もパフォーマンスも着実に向上した。企業向けのセキュリティ機能は充実しているし、M365との統合やIntuneでの一元管理、Entra IDとの認証連携を考えると、エンタープライズ環境でEdgeを選ぶ合理性は十分にある。 だからこそ、こういう「気づかないうちに戻す」やり方はもったいない。Edgeには正面から勝負できるだけの実力がある。それを、ユーザーの選択を静かに上書きするような手法で補おうとする必要はないはずだ。 Microsoftが本来得意としてきたのは、「禁止ではなく便利にして使わせる」アプローチだ。Microsoft Entra IDを使う仕組みを自然に選ばせる、Teamsを使いたくなる環境を整える——そういう「道のド真ん中を歩く」戦略でエコシステムを広げてきた実績がある。今回のEdge誘導は、その自社の哲学と矛盾している。ここは正直に、ダメなものはダメと言わなければいけない。 一方で、企業の現場ではEdgeを軸にした運用を組んでいる組織も多いだろう。M365との統合メリットは大きく、それ自体は正しい判断だ。重要なのは、Intuneやグループポリシーできちんと既定ブラウザを固定し、OSアップデートによる意図しない変更を防ぐ仕組みを整えておくこと。Microsoftのプラットフォームを信頼して使うことと、個別の施策を無条件に受け入れることは別の判断だ。 がんばれMicrosoft。正面から選ばれるブラウザを作る力はあるのだから、それを信じてほしい。 出典: この記事は Browser Choice Alliance slams Microsoft for latest shady Edge tactic の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード EUの最高行政機関である欧州委員会のAWSクラウド環境が、2026年3月10日に侵害された。攻撃を担ったのは「TeamPCP」と呼ばれる脅威グループ。被害はEU機関71クライアントに及び、メールアドレス・氏名・メール本文を含む約90GBのデータが闇ウェブに流出している。CERT-EU（EUサイバーセキュリティサービス）が4月3日に詳細を公表した。 この事件は単なる「大手機関のクラウド侵害」ではない。サプライチェーン攻撃 → クレデンシャル窃取 → クラウド横展開という攻撃チェーンの教科書的な実例であり、日本のIT現場にも直接刺さる話だ。 攻撃の経緯——Trivyが起点だった 攻撃の起点はDevSecOpsツールとして広く使われているコンテナ脆弱性スキャナー「Trivy」のサプライチェーン攻撃だ。TeamPCPはTrivyへの不正コード混入を通じて、欧州委員会のAWSアカウントに対する管理権限を持つAPIキーを事前に入手していた。 3月10日、このAPIキーを使って欧州委員会のAWSクラウド環境に侵入。その後、オープンソースのシークレットスキャンツール「TruffleHog」を使って環境内に残存するさらなる認証情報を探索し、既存ユーザーに新規アクセスキーをアタッチすることで検出回避を図った。 さらに巧妙なのが、この侵入が5日間検知されなかった点だ。欧州委員会のCybersecurity Operations Centerは、APIの不正利用も、アカウント侵害の兆候も、異常なネットワークトラフィックも、3月24日まで気づかなかった。侵入から一週間近くが経過してからの検知だ。 流出データの規模 CERT-EUの分析によると、盗まれたデータは以下の通り： 対象クライアント数: 欧州委員会内部42クライアント＋EU他機関29以上、合計71クライアント 流出ファイル数: 数万件（個人情報含む） メール関連ファイル: 51,992件（合計2.22GB） ダークウェブ公開: ShinyHuntersグループが90GBアーカイブ（非圧縮340GB）として公開済み メール関連ファイルの多くは自動通知メールとのことだが、「バウンスバック通知」にはユーザーが送信した元のメッセージ内容が含まれる場合があり、個人情報漏洩リスクが残る。 なお、Webサイトの改ざんや他のAWSアカウントへの横展開は確認されていない。 実務への影響——日本のIT管理者が今すぐ確認すべきこと 1. TrivyなどのDevSecOpsツールはバージョン固定で使っているか サプライチェーン攻撃の怖さは、信頼しているツールが凶器になる点だ。CIパイプラインで使うスキャナーやCLIツールのバージョンを固定し、ハッシュ検証を行う運用が必要。「最新版を自動取得」はもはや安全ではない。 2. AWSのIAMキー管理を見直せ 今回の攻撃はAWS APIキーの奪取から始まった。IAMポリシーの「最小権限の原則」は当然として、長期有効なアクセスキーの存在そのものがリスクだ。IAMロール＋一時的なクレデンシャル（STS）への移行、使われていないキーの即時削除、アクセスキーのローテーション自動化を今すぐ実施すること。 3. TruffleHogは攻撃者も使う——先に自分でスキャンしろ 皮肉な話だが、TruffleHogは防御側が「リポジトリにシークレットが埋まっていないか」を確認するためのツールでもある。攻撃者に先んじて自分の環境をスキャンし、漏洩したシークレットを先に無効化する運用を入れるべきだ。 4. 検知の遅れをどう縮めるか 5日間気づかなかったのはEUの機関でも起きうる現実だ。SIEM・CSPM（Cloud Security Posture Management）の導入と、異常なIAM操作へのアラート設定が基本中の基本。「CloudTrailは入れてる」だけでなく、アラートが実際に飛ぶ設定になっているかを今日確認してほしい。 筆者の見解 正直に言う。セキュリティは好きじゃない。細かい人が多いし、議論が不毛になりがちだ。でも今回の件は技術的に非常に興味深いし、見逃せない教訓がある。 まず、Trivyというれっきとしたセキュリティツールがサプライチェーン攻撃の入口になったという皮肉。セキュリティを強化しようとしてセキュリティ侵害される——これは「禁止アプローチ」の限界そのものだ。ツールを禁止するより、ツールを安全に使える仕組み（バージョン固定・ハッシュ検証・SBOM管理）を作ることが正解だ。禁止は必ず失敗する。 そして「5日間検知されなかった」という点。欧州委員会レベルの組織でこれが起きる。日本の大手エンタープライズの多くは、もっとひどいことになっているはずだ。「今動いているから大丈夫」は通用しない——これは過去にも何度も言ってきたが、今回はEUレベルの実例が出た。言い訳できなくなった。 IAMキー管理についても一言。「常時有効なAPIキーを発行してどこかに置いておく」という運用は、ゼロトラストの観点から言えば論外だ。Just-In-Timeアクセス、一時クレデンシャル、IAMロール——これらは「難しいからいずれやる」ではなく、今すぐやるべきことのリストの一番上に置くべきだ。 TeamPCPはGitHub・PyPI・NPM・Dockerと幅広いプラットフォームを標的にしているサプライチェーン攻撃の常習犯だ。今回の欧州委員会への侵入で終わりではなく、次のターゲットがどこかにいる。自分の組織が「よりリッチな標的」になっていないか、CIパイプラインの棚卸しを今すぐやってほしい。 出典: この記事は CERT-EU: European Commission hack exposes data of 30 EU entities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが今週から、IT部門による管理が行われていないWindows 11 24H2（HomeおよびPro）デバイスを対象に、Windows 11 25H2への強制アップグレードを開始した。「気づいたらOSバージョンが上がっていた」という体験をするユーザーが続出するタイミングだ。個人PCでMicrosoft 365を使う業務担当者や、管理外デバイスが混在する組織のIT担当者は状況を把握しておく必要がある。 何が起きているのか MicrosoftはML（機械学習）ベースの「インテリジェントロールアウト」の適用範囲を、IT管理外のWindows 11 24H2 HomeおよびPro 全台 に拡大した。 背景は明確だ。Windows 11 24H2のサポート終了日は 2026年10月13日。残り約6ヶ月。サポート終了後はセキュリティ更新、タイムゾーン更新、テクニカルサポートがすべて止まる。Microsoftの公式表現を借りれば「最新の脅威からの保護を含む月次セキュリティ更新を受け取れなくなる」。 なお、25H2は大きなメジャーアップデートではない。200KB未満の「有効化パッケージ」 で適用されるマイナーアップデートで、2025年9月から段階配信が進んでいた。 アップグレードの流れと対処法 自動更新対象: IT管理（MDM/Intune等）外のHome/Proデバイス全台 手動で先行確認: 設定 → Windows Update → Windows 11 25H2のリンクをクリック 一時停止も可: 設定 → Windows Update → 一時停止（ただし期限後は強制適用） 再起動タイミングは自分で選択可能 Microsoftはアップグレード時のトラブル対応用にサポートドキュメントとステップバイステップガイドを公開している。 背景：立て続けに起きているトラブルとの重なり タイミングが若干不安だ。2026年3月のPatch Tuesday以降、Microsoftは複数の緊急対応を余儀なくされている。 Microsoftアカウントのサインイン失敗（Teams・OneDrive等に影響）→ KB5085516で対処 Bluetoothデバイスが見えなくなる問題（ホットパッチ対応のWindows 11 Enterprise向け） RRAS（Routing and Remote Access Service）のセキュリティ脆弱性 → 帯域外更新で修正 これだけ問題が連続している中で、25H2への強制移行が始まったのが現状だ。 実務への影響 IT管理者・情報システム担当者 最大の課題は 「管理外デバイスの把握」 だ。BYODや在宅勤務者の個人PC、テスト機、来客用端末など、MDM/Intune管理外のデバイスが組織内に混在しているケースは少なくない。確認しておきたいポイントは以下： 管理外デバイスの棚卸し: 何台あり、どのバージョンが走っているか 25H2との互換性チェック: 古い業務アプリ、特にドライバー依存の周辺機器との相性 エンドユーザーへの周知: 一時停止方法を案内するか否かの組織判断 25H2適用後のサインイン問題対策: KB5085516の適用状況を確認しておく 個人・SOHOユーザー 基本的には放置で問題ないケースが大半だ。ただし業務でTeamsやOneDriveを使っている場合、サインイン失敗が起きた際の対処法（緊急更新KB5085516の適用）は頭に入れておこう。 ...

3年前、「スマートフォンで言語モデルを動かす」といえば、学会発表用のデモ映像の世界だった。それが今や、数十億パラメータのモデルがフラッグシップスマートフォン上でリアルタイム動作する時代になった。Meta AIリサーチャーのVikas Chandra・Raghuraman Krishnamoorthi両氏による「On-Device LLMs: State of the Union 2026」は、この劇的な変化の背景と現状を実践的な視点から整理した技術レポートだ。 なぜオンデバイスか——4つの根拠 クラウドLLMではなく端末内で推論する理由は4点に集約される。 レイテンシ：クラウド経由だと最初のトークンが返ってくるまでに200〜500msかかる。ARオーバーレイ、リアルタイム翻訳、音声アシスタントでは、この遅延が致命的にユーザー体験を壊す。オンデバイスなら、特に短いコンテキストでは1トークンあたり20ms以下で生成できる。 プライバシー：デバイスから出ないデータは、転送中に盗まれることもサーバーにログされることもない。医療データ、金融情報など機微情報を扱うユースケースでは、これは単なるオプションではなく、規制上の要件になりつつある。 コスト：クラウド推論はクエリ単価が積み重なる。大量のリクエストが発生するアプリケーションでは、ユーザーがすでに持っているハードウェアに推論コストをオフロードできるオンデバイスの経済合理性は圧倒的だ。 可用性：電波の届かない場所、機内、地下でも動き続ける。クラウド依存は接続信頼性への依存と同義だ。 もちろん、フロンティアレベルの推論、広範な世界知識、長い多回話話会話が必要ならクラウドが依然として正解だ。だがレイテンシ重視・プライバシー重視・大量処理が必要なユースケースでは、オンデバイスが「現実的な選択肢」に入ってきた。 技術的ボトルネックは「メモリ帯域幅」 多くの人が誤解しているが、エッジデバイスの制約は「演算性能」ではない。現代のモバイルNPUは相当な性能を持っている。 Apple A19 Pro Neural Engine：約35 TOPS Qualcomm Snapdragon 8 Elite Gen 5：約60 TOPS MediaTek Dimensity 9400+：約50 TOPS これは2017年頃のデータセンターGPU（V100で125 TOPS）に迫る水準だ。 真のボトルネックはメモリ帯域幅にある。モバイルデバイスは50〜90 GB/s、データセンターGPUは2〜3 TB/sと、30〜50倍の差がある。LLM推論のデコードフェーズはメモリバウンドな処理なので、トークンを1つ生成するたびにモデルの重み全体をメモリからロードし直す。演算ユニットはメモリ待ちで遊んでいる状態だ。 だから「量子化」の効果が絶大になる。16ビットから4ビットへの量子化は単に4倍の省ストレージではなく、トークンあたりのメモリトラフィックを4分の1に削減し、それがスループット向上に直結する。さらに「複数トークンの並列予測」も、追加レイテンシなしに実効スループットを向上させる有力な手法として実用化されている。 もう一つの制約はRAM容量だ。ハイエンド端末でも、OSやほかのアプリとの共存を考えると実質的に使えるRAMは4GB未満になる。これはMoE（Mixture of Experts）アーキテクチャの適用に制限をかける要因でもある。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと モバイルアプリ開発者：ユーザーへのAI機能提供において「クラウドAPI呼び出し一択」の時代は終わりつつある。Apple Core MLやQualcomm AI Engineのツールチェーンが成熟してきており、3B〜7Bクラスのモデルなら端末内推論が現実的なアーキテクチャ選択肢になった。ただし「TOPSが高ければ速い」は誤解。アテンション演算や動的形状のサポート、ツールチェーンの成熟度を必ず確認すること。 プライバシー・コンプライアンス担当者：医療・金融・法律など機微情報を扱うシステムで、「ユーザーのデータが端末外に出ない」という設計は規制対応の観点から非常に強力な武器になる。GDPR、個人情報保護法対応のアーキテクチャ設計でオンデバイスLLMを選択肢に加えるべきタイミングだ。 業務アプリ設計者：現場作業員向けアプリ（工場内、建設現場、医療現場）では電波が安定しないケースが多い。オンデバイスLLMによるオフライン推論は、そういった環境での音声入力・要約・分類に有力な解答になる。 コスト設計：クラウドLLMのAPI費用が高騰しているプロジェクトでは、処理をオンデバイスに移すことで劇的なコスト削減が可能な場合がある。ただし開発・デバッグのコストも考慮すること。 筆者の見解 Metaのリサーチャーによるレポートだが、内容はMeta固有の話というより、オンデバイスLLM全体の技術的な見通しをまとめたものとして読む価値がある。現状、ローカルLLMの選択肢は中国勢（Qwen、DeepSeekなど）も含めて急速に広がっており、Metaのモデルがその中でどこまで存在感を出せるかはまだ見えないが、こうした技術レポートを公開してくれること自体はありがたい。 オンデバイスLLM自体のトレンドは本物で、重要だ。 このレポートが指摘している「ボトルネックはコンピュートではなくメモリ帯域幅」という洞察は非常に鋭い。クラウドとの30〜50倍のメモリ帯域幅の差がある以上、モバイル向けLLMの最適化は「クラウドLLMの縮小版」ではなく、まったく別の設計思想が必要になる。量子化・スパース化・マルチトークン予測の組み合わせは、その設計思想の答えの一つだ。 日本のIT業界で気になるのは、「クラウドLLM API呼び出し」か「LLM禁止」の二択で思考停止している企業がまだ多いことだ。オンデバイスはその中間にある第三の選択肢で、プライバシーとコストの両面で合理的なケースが確実にある。「データを外に出したくないからAIは使えない」という理由で諦めていた組織は、今すぐ選択肢を再評価すべきだ。 AIは端末の中に入ってきた。クラウドに頼らず、オフラインで、プライベートに動くAIが現実になりつつある。この変化を「スマホのちょっとした機能向上」と見ているなら、大きく出遅れることになる。 出典: この記事は On-Device LLMs: State of the Union 2026 – Meta AI Research の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年の幕開けとともに、テクノロジー投資の世界が文字通り「別次元」に突入した。Crunchbaseのレポートによると、2026年Q1のベンチャー資金調達額は史上最高を更新し、その80%にあたる約2420億ドル（約36兆円）がAI関連企業に流れ込んだ。1四半期でこの規模というのは、かつてのドットコムバブル全盛期ですら想像できなかった数字だ。 資金はどこに集まったのか 内訳を見ると、集中ぶりが際立っている。 OpenAI: 1220億ドル（単独で全体の40%超） Anthropic: 300億ドル xAI（Elon Musk）: 200億ドル この3社だけで合計1720億ドル。残りの700億ドルがその他すべての世界中のスタートアップに分配された計算になる。フロンティアLab（先端AIモデルを開発する一握りの企業）への資本集中は「加速する勝者総取り」の構造を如実に示している。 なぜこれが重要か 単純に「すごい額だ」で終わらせてはいけない。この資金構造には2つの重要なシグナルが含まれている。 第一に、計算資源の囲い込みが本格化している。 AIモデルの性能競争は今や「誰がより多くのGPUクラスターを持てるか」というゲームになっている。OpenAIへの1220億ドルの大半はMicrosoftをはじめとする戦略的投資家からのもので、インフラへの先行投資という性格が強い。Anthropicへの300億ドルにはAmazon（AWS）からの大型コミットが含まれており、クラウドプロバイダーによる「AIモデルの抱き込み」が着々と進んでいる。 第二に、「AIを使う企業」ではなく「AIそのものを作る企業」への賭けに投資家がシフトした。 これは2021〜2022年のSaaS投資ブームとは本質的に異なる。スタートアップエコシステム全体で見れば、むしろAIインフラレイヤーへの超集中投資の裏で、一般的なスタートアップへの資金は細りつつある可能性がある。 実務での活用ポイント IT調達・戦略担当者へ: OpenAIとAnthropicの財務基盤の強化は、それぞれのAPIサービスの安定性・継続性を意味する。「スタートアップなので突然サービス終了するリスク」という懸念は、今後ますます薄れていく。ガバナンスポリシーを整備したうえで、エンタープライズ契約の交渉に動いていいタイミングだ。 開発チームへ: フロンティアLab同士の競争激化は「モデル性能の急速な向上」と「価格競争」を同時にもたらす。現時点で最適なモデルを選んで固定するより、抽象化レイヤーを設けてモデルを差し替えやすいアーキテクチャを採用することが中長期的に有利になる。 エンジニア個人へ: このスケールの投資が続く限り、「AIは一過性のブームかもしれない」という観測は完全に否定された。今から実際に手を動かして使い倒す経験を積まない人間は、2〜3年後に取り返しのつかない差をつけられる。 筆者の見解 この数字をどう受け止めるか。OpenAIに1220億ドル、Anthropicに300億ドル、xAIに200億ドル——上位3社だけで1720億ドルという集中ぶりは、AI市場が「実験フェーズ」を完全に抜けて「インフラ投資フェーズ」に入ったことを意味している。これだけの資本が動いているのは、投資家がAIの将来価値に本気で賭けている証拠だ。 各社の投資額の違いは、ブランド力・ユーザーベース・クラウドパートナーとの関係など複合的な要素を反映している。重要なのは個別の優劣ではなく、フロンティアLabが軒並み財務基盤を固めたという事実だ。APIサービスの継続性リスクが下がり、エンタープライズ契約の交渉がしやすくなるという実務的なメリットがここにある。 それより深刻なのが日本のIT業界の反応だ。この規模の資本が動いているということは、世界のAI開発スピードが今後さらに加速するということを意味する。なのに、まだ「AIを試してみようか」「社内ガイドラインを整備中」という企業が大多数を占めている。この2〜3年の立ち遅れは、もはや「遅れ」ではなく「別のゲームをやっている」と表現すべきレベルだ。大変革に気づいていない企業が多すぎる。がんばれ、日本のIT業界。 出典: この記事は Q1 2026 Shatters Venture Funding Records As AI Boom Pushes Startup Investment To $300B の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年3月、オープンソースのLLM推論エンジン「vLLM」が大型アップデート Model Runner V2（MRV2） をリリースした。単なる機能追加ではなく、エンジンのコア部分をゼロから書き直すという思い切った刷新だ。既存APIとの互換性は維持しつつ、内部アーキテクチャを根本から再設計した今回のリリースは、本番環境でLLMを運用するエンジニアにとって無視できないアップデートとなっている。 vLLMとは何か——まず押さえておく基礎 vLLMは、UCバークレーのSky Computingラボが2023年に公開したオープンソースのLLM推論エンジン。PagedAttentionという独自のメモリ管理技術によって、GPUのVRAMを効率的に使い回しながら高スループットな推論を実現した。OpenAIの推論APIと互換性のあるインターフェースを備えており、「自前でLLMサーバを立てる」ための事実上のデファクトとして広く使われている。 Hugging FaceのTransformersが「モデルを動かす」ツールだとすれば、vLLMは「モデルを本番スケールで速く動かす」ツール、という位置づけだ。 MRV2の何が変わったのか モジュール性の大幅向上 旧来のvLLMはコードが密結合しており、特定のハードウェア（NVIDIA GPU）や特定のモデルアーキテクチャに最適化するたびに、深いところまで手を入れる必要があった。MRV2ではModel Runnerのレイヤーを明確に分離・抽象化し、ハードウェアバックエンドを差し替え可能な設計に刷新された。 これにより、AMD GPU・Google TPU・各種NPUへの対応コストが大幅に下がる。AWSのTrainium/Inferentiaや、今後登場してくる国産AIチップへの対応も、従来より現実的な工数で実現できるようになった。 推論効率の改善 MRV2ではテンソルの管理方式が見直され、バッチ処理のオーバーヘッドが削減された。特に長コンテキスト推論（100K〜1Mトークン規模）や、マルチモーダルモデル（テキスト＋画像入力）での効率改善が報告されている。実際のスループット改善幅はモデルやハードウェアによって異なるが、ワークロードによっては無視できない差が出る。 既存APIとの互換性は完全維持 「書き直した」と聞くと移行コストを心配するかもしれないが、OpenAI互換API（/v1/chat/completions等）はそのまま使える。既存の呼び出しコードを変更せずにアップグレードできる点は、本番運用者にとってありがたい設計判断だ。 実務への影響——日本のエンジニアが押さえるべきポイント 1. 自前LLM基盤を持ちたい組織には追い風 API料金を気にせずLLMを内部活用したい、データをクラウドに出したくない、という組織でvLLMを使っているケースが国内でも増えている。MRV2のモジュール性向上は、独自の最適化チューニングやカスタムモデルの組み込みをしやすくする。特に金融・医療・官公庁のような情報管理が厳しい業種での採用障壁が下がる。 2. マルチモーダル対応の本番利用が現実に テキストだけでなく画像も扱えるマルチモーダルモデル（LLaVA系・Qwen-VL系等）の推論効率が上がったことで、帳票OCR・製品画像解析・マニュアル読み取りといった業務ユースケースへの本番適用が実用段階に近づいた。 3. ハードウェア選択肢が広がる NVIDIA一択だった推論基盤の選択肢が、今後は広がる可能性がある。国内でもAMD InstinctやIntel Gaudi2を検討している組織があるが、vLLMのバックエンド抽象化が進むことでエコシステム全体の成熟が加速する。 今すぐ使えるアクション pip install vllm でMRV2ベースの最新版を取得し、手持ちのモデルでパフォーマンスを比較する OpenAI SDK互換なので、既存のLangChainやLlamaIndexのコードはそのまま接続できる vllm serve <model_name> --api-key token-abc123 でローカルAPIサーバが立ち上がる。まずここから試せ 筆者の見解 vLLMのMRV2リリースは「地味だけど超重要」なアップデートだ。派手な新機能発表ではないが、コアの再設計というのは相当な決断で、それをやりきったことは素直に評価したい。 LLM推論基盤としてvLLMの地位はほぼ揺るぎない。TGI（Text Generation Inference）やTriton Inference Serverといった競合もあるが、エコシステムの厚さと開発速度ではvLLMが抜けている。今回のMRV2でその差がさらに開いた印象がある。 ただ、日本のIT現場を見ていると、「とりあえずAzure OpenAI ServiceかAWS Bedrockに頼む」という流れが圧倒的で、自前推論基盤の構築に踏み込んでいる組織はまだ少ない。コスト・制御・カスタマイズの観点から、中長期的には自前基盤を持つ価値は確実にある。vLLMはそのための現実的な選択肢として、もっと真剣に評価されるべきだ。 もうひとつ言いたいのは、「オープンソースのLLM推論エンジンがここまで成熟した」という事実の重さだ。2年前は「GPT-4に追いつくにはどれくらいかかるか」という話をしていたのが、今やオープンモデルを本番スケールで動かすインフラが当たり前のように整っている。仕組みを作れる人間が少数いれば、あとはAIが回す時代はもうすぐそこまで来ている。乗り遅れている日本企業は、本当にそろそろ本気を出してほしい。 出典: この記事は vLLM Model Runner V2 (MRV2): A Ground-Up Reimplementation of the Open Source Inference Engine の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

コード生成プラットフォームとして知られるReplitが、Agent 4を正式リリースした。従来比10倍の処理速度と、複数のAIエージェントが役割を分担して協調動作する「マルチエージェントワークフロー」が目玉だ。投資家の評価も急上昇しており、わずか半年でバリュエーションが30億ドルから90億ドルへと3倍に膨らんでいる。 Agent 4が変えること——「副操縦士」から「自律艦隊」へ これまでのAIコーディングツールの多くは、いわゆる「副操縦士（Copilot）モデル」だった。人間がコードを書き、AIがその場でサジェストする。確認のたびに人間が承認する構造だ。 Agent 4が提示するのはその先にある設計思想——目的を伝えれば複数のエージェントが自律的に分担・完遂する、という自律艦隊モデルだ。 役割分担の自動化: 設計・実装・テスト・デプロイといった工程を、専用エージェントがそれぞれ並列で担当 10倍の処理速度: 単一エージェントのボトルネックをマルチ化で解消。実際の開発時間を劇的に短縮 コンテキスト共有: エージェント間がタスク状態を共有し、手戻りや重複作業を削減 これはコード補完ツールの延長線上にある話ではない。ソフトウェア開発プロセスそのものをエージェントに委ねるパラダイムシフトだ。 なぜいまこのタイミングか マルチエージェント協調が実用レベルに達した背景には、LLMの推論コスト低下とコンテキストウィンドウの大幅拡張がある。2025年以降、各社の基盤モデルが長大なコードベースを一度に扱えるようになり、「エージェントをたくさん立ててタスクを振る」ことが経済的に成立するようになった。 Replitはその波に乗り、ブラウザベースのIDE環境という強みを活かして、インフラ構築なしに即使えるマルチエージェント環境を一般ユーザーに届けた。スタートアップや個人開発者がターゲットであることも明確だ。 実務への影響——日本のエンジニア・IT管理者は何をすべきか プロトタイピングコストが激減する Agent 4のようなツールは、アイデア検証フェーズのコストを桁違いに下げる。「ちょっと試してみる」のハードルが下がるため、社内PoC（概念実証）を量産できるチームが圧倒的に強くなる。 チーム構成の見直しを今すぐ始めよ エージェントが実装・テスト・デプロイを自動化するとなると、今までの「人数×工数」で見積もる開発モデルは崩壊する。少数の「仕組みを作れる人間」が大量のエージェントを指揮する構造が現実になりつつある。 ガバナンスの設計を先に考えろ マルチエージェントが自律的に動くということは、何をどこまで自動化するかの設計責任が人間に残るということでもある。特にセキュリティ・コンプライアンス要件が厳しい日本企業では、「エージェントがやっていい範囲」の定義を先に整備しておく必要がある。 筆者の見解 ReplitのAgent 4、方向性はド正解だと思う。「複数エージェントが協調して自律的にタスクをこなす」——これこそがAIエージェントの本質的な進化の方向だ。 AIコーディングの分野はいま各社が激しく競っていて、マルチエージェント協調という設計思想自体は他のツールでも実現されつつある。Replitが「10倍速」と言うとき、何と比べているのかは要確認だ。ベンチマークの定義次第で数字は大きくも小さくもなる。 それよりも気になるのはバリュエーションの急膨張だ。半年で3倍というのは投資家の期待値であって、製品実力ではない。生成AI界隈の資金流入は活況だが、プロダクトの実力と投資家の評価額を混同しないことが重要だ。Replitのプロダクト自体は悪くないが、90億ドルという数字は少し前のめりに見える。 日本企業へのメッセージとしては、「Replitを使え」よりも「マルチエージェントの設計思想を学べ」の方が重要だ。ツールは何でもいい。ゴールを渡したら自律的に動くエージェント群をどう設計・管理するか——この問いに答えられる組織が、3年後に圧倒的な差をつける。 AIエージェントの進化は加速している。特定のツールの体験だけで「AIはまだ使えない」と判断してしまうのはもったいない。自分に合ったツールを見つけて、実際に使って成果を出す経験を積むことが、情報を追いかけるよりもずっと価値がある。 出典: この記事は Replit Agent 4 Delivers 10x Speed with Multi-Agent Cooperative Workflows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アリババのQwenチームが2026年3月末に公開した「Qwen3.5-Omni」は、テキスト・画像・音声・動画を単一のパイプラインでネイティブ処理する「真のオムニモーダルモデル」だ。215項目の音声・視聴覚ベンチマークでSOTA（最先端）を達成し、Googleのフラッグシップ「Gemini 3.1 Pro」を音声理解の複数カテゴリで上回ったと発表された。日本のエンジニアにとっても無視できないリリースである。 Thinker-Talkerアーキテクチャとは何か 従来のマルチモーダルモデルの多くは「テキストLLMにWhisperなどの外部エンコーダをくっつけた」構成だった。要するに継ぎ接ぎだ。Qwen3.5-Omniはその設計を根本から変えている。 中核はThinkerとTalkerの2コンポーネントからなる統合アーキテクチャ。Thinkerは思考・推論を担い、Talkerはリアルタイムの音声応答を生成する。両者を結ぶのがHybrid-Attention MoE（Mixture of Experts）で、モダリティ（入力種別）ごとにどのエキスパートパラメータを使うかを動的に切り替える。 特筆すべきはAudio Transformer（AuT）エンコーダが1億時間以上の視聴覚データで事前学習されている点だ。人間の「聞いて見て理解する」感覚に近い時系列・音響的なニュアンスをモデルが持つことになる。 スペックのハイライト コンテキスト長: 256kトークン（連続音声10時間超、720p動画400秒超に対応） 音声認識対応言語: 113言語 ベンチマーク: 一般音声理解・推論・認識・翻訳でGemini 3.1 Proを超えたと発表 ラインナップ: Plus（高精度推論）/ Flash（低レイテンシ・高スループット）/ Light（軽量・省コスト）の3段構成 「Audio-Visual Vibe Coding」という新概念 今回のリリースで特に目を引いたのが「Audio-Visual Vibe Coding」という機能だ。動画を見せながら音声で「ここのUIを直して」と指示するだけで、モデルがコードを生成するというもの。テキストと動画と音声を同時に文脈として保持できるネイティブマルチモーダルだからこそ実現できるユースケースであり、従来のCopilotのような「テキスト補完の延長」とは一線を画す。 実務への影響——日本のエンジニア・IT管理者に何が変わるか 1. 議事録・会議解析の精度が跳ね上がる 音声認識で113言語対応、かつ映像も同時処理できるとなれば、Zoom・Teams録画をまるごと投げ込んで「誰がどの資料を見ながら何を言ったか」を構造化するワークフローが現実的になる。日本語対応品質の実測は必須だが、ASR系ベンチマークでの強さは期待を持たせる。 2. ローカルデプロイの選択肢として Qwenシリーズは従来からオープンウェイトモデルの公開が積極的だ。Qwen3.5-Omniも段階的にモデルウェイトの公開が見込まれる。セキュリティポリシーの都合でクラウドAPIを使えないシステムでも、ローカルで動かせる可能性がある。Lightエディションはその筆頭候補だ。 3. 競合圧力がAPIコストを下げる Geminiに対して性能で並んだあるいは超えたと主張するモデルが出てくると、OpenAI・Googleはプライシングで対抗せざるを得ない。最終的にエンドユーザー側のAPIコストが下がる恩恵は計り知れない。 筆者の見解 正直に言う。中国勢のLLMはローカルモデルのコスパで以前から群を抜いていたし、Qwen3.5-Omniはその文脈の延長線上にある。215個のSOTAとか言われても「ベンチマークは自己申告」という skepticism は必要だし、実際に日本語環境で動かして初めて評価できる話だ。 ただ、Thinker-Talkerアーキテクチャの設計思想は本物だと思う。テキストに後付けで音声エンコーダをくっつけたモデルと、最初から音声・映像・テキストを統合設計したモデルは、コンテキスト理解の質が根本から違う。「継ぎ接ぎより一体設計」という方向性は正しい。 Geminiとの比較についてはベンチマーク上の数値は確認できるが、画像生成以外の実務タスクでの性能差がどの程度なのかという点が気になる。さらに言えば、本当に評価したいのは主要なクローズドモデルとの直接比較だが、そこへの言及がないのが物足りない。 とはいえ、「アリババが本気のマルチモーダルを出してきた」という事実は重い。日本企業がまだOpenAI一辺倒で動いている間に、選択肢は急速に広がっている。情報を追い続けるより実際に使って見極めるべきフェーズだ。Flash版でもいいから動かしてみてほしい。 出典: この記事は Alibaba Qwen Team Releases Qwen3.5-Omni: A Native Multimodal Model for Text, Audio, Video, and Realtime Interaction の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GDC 2026（ゲーム開発者会議）にて、MicrosoftはWindowsおよびXboxのゲーム開発者向けに複数のツール強化を発表した。ロード時間短縮・シェーダー配信最適化・アセットパイプライン改善という3本柱で、次世代Xbox「Helix」に向けた開発者エコシステムの整備が本格化している。 発表内容：3つの柱 1. Zstandard（zstd）圧縮サポート WindowsのゲームパッケージングにZstandard圧縮が正式対応した。Zstdはオープンソースの高速圧縮アルゴリズムで、既にChromeやLinuxカーネル、Meta社内インフラ等で広く採用されている実績ある技術だ。従来のzlib系と比べてデコード速度が大幅に速く、ゲームのロード時間短縮に直結する。Xbox GDKを通じてPC・Xbox双方に適用可能なため、一度の対応で両プラットフォームの体験向上が期待できる。 2. Game Asset Conditioning Library（GACL） ゲームアセット（テクスチャ・メッシュ等）をターゲットプラットフォームに最適化された形式に変換するライブラリが提供される。ビルドパイプラインに組み込むことで、プラットフォームごとの手動最適化作業を自動化できる。特にPC/Xboxのマルチターゲット開発において、アセット変換の工数削減効果は大きい。 3. Advanced Shader Delivery の全開発者解放 これまで一部パートナー限定だったAdvanced Shader Deliveryがすべての開発者に開放された。Direct Storage APIと組み合わせることで、ゲーム起動時のシェーダーコンパイル待ちを大幅に削減できる機能だ。「最初の起動が遅い」という長年のDirectX系ゲームの課題に、ようやく本格的な解決策が普及段階に入った。 なぜこれが重要か これらの発表の真の意味は、Xbox GDKを軸としたPC/Xbox統合開発基盤の強化にある。次世代Xbox「Helix」のリリースを控え、Microsoftは「1つのコードベースで両プラットフォームに最適化されたゲームが作れる環境」の整備を急いでいる。 日本のゲーム開発会社にとっても無縁ではない。国内の中堅スタジオがPC/Xboxのマルチ展開を検討する際、これまでは「Xboxのシェアが低いから費用対効果が見えにくい」という判断が多かった。しかし、GDKによる共通化でPC対応の追加コストが下がるなら、Xbox対応のハードルも同時に下がるという構造だ。 実務への影響——エンジニア・IT管理者が押さえるべきポイント ゲームエンジニア向け Advanced Shader Deliveryは今すぐ検証すべき。既存タイトルのロード体験改善に直結するため、まず検証環境で効果を測定する価値がある GACLはCIパイプラインへの組み込みを前提に設計されている。既存のビルドフローを見直す良い機会 Zstd対応は圧縮率とデコード速度のバランスが優秀。パッケージサイズとロード時間のトレードオフを改めて検討したい 技術リード・プロデューサー向け PC版とXbox版の「別物扱い」から「同一コードの設定違い」への移行コストが下がりつつある。中長期のプラットフォーム戦略を見直す契機になる 次世代Xbox「Helix」向けの最適化は今から仕込んでおいたほうが楽になる 筆者の見解 正直に言うと、Microsoftのゲーム開発者向けの動きは久々にまともな方向性に見える。Advanced Shader Deliveryの全開放は「なんで今まで一部限定だったんだ」と言いたくなるが、それが解放されたのは素直に評価していい。 Zstandard対応も、「なぜ今さら」感はあるものの、業界標準のオープン技術をWindowsエコシステムに取り込んでいく姿勢は正しい。独自規格で囲い込むよりも、標準技術で生態系を広げるほうが長期的にはプラットフォームの競争力につながる。道のド真ん中を歩く判断だ。 ただ、冷静に見ると、これらはゲームエンジン側（UnrealやUnity）がとっくに対応してきた問題へのOS/SDK側のキャッチアップでもある。「Microsoftが先行して業界を引っ張っている」というよりは「ようやく現場の要求に追いついてきた」が正確な評価だろう。 次世代Xbox「Helix」に向けて、MicrosoftのゲームプラットフォームがWindowsと一体化していく流れは不可逆だと思う。PC Gamepassの拡大戦略と合わせて考えると、「Xboxというハードウェアブランド」より「Windowsというプラットフォームでゲームをやる体験」への移行を本気で進めているのが透けて見える。それは正しい判断だ。がんばれ、Microsoft。 出典: この記事は GDC 2026: Announcing new tools and platform updates for Windows PC game developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きているのか 2026年4月15日、MozillaとGoogle ChromeがDigiCert Global Root（G1ルート）の信頼を廃止する。これに合わせて、Azure Instance Metadata Service（IMDS）がパブリックイシュアをMicrosoft G2-XSへ切り替える予定だ。 「証明書の話なんて自分には関係ない」と思ったエンジニア、ちょっと待ってほしい。IMDSはAzure VM上で動くほぼあらゆるアプリケーションが、インスタンス情報の取得・マネージドID認証・アテスティッドデータの検証に利用している基盤APIだ。ここが壊れると、VM上のワークロードが静かに死ぬ。 Azure IMDSとは何か Azure Instance Metadata Service（IMDS）は、Azure VM内から169.254.169.254（リンクローカルアドレス）にHTTPリクエストを投げることで、VMのメタデータや認証トークンを取得できる仕組みだ。マネージドIDを使ったAzureリソースへのアクセス（Key Vault・Storage・Azure OpenAIなど）は内部的にこのエンドポイントを叩いている。 Attestedデータ（改ざん検知用の署名付きメタデータ）を使う場合、クライアント側でその署名を検証するためにルート証明書が必要になる。ここに今回の変更が直撃する。 影響を受けるシステムの条件 以下に該当するシステムは今すぐ確認が必要だ： Attesd Data APIを使っている: ?format=json&api-version=2021-01-01などでAttestedデータを取得し、署名を検証しているコード カスタム証明書ストアを持つ環境: OSのシステムストアを使わず、独自のバンドル証明書でTLS検証しているアプリ（Pythonのcertifi、Javaの独自トラストストアなど） エアギャップ環境・オフライン証明書検証: インターネットに出られないVMでルート証明書を静的にバンドルしているケース 古いOSイメージ: 長期間アップデートしていないLinuxやWindowsイメージはルート証明書ストアが古い可能性がある 逆に、最新のOSイメージを使っており、システムのルートストアに依存し、Attesd Dataを署名検証していない場合は影響を受けない可能性が高い。 対処法 ステップ1：IMDSの利用状況を棚卸しする まずコードベースを検索して、169.254.169.254へのリクエストやManagedIdentityCredentialの利用箇所を洗い出す。Azure SDK（Python・Java・.NET・Go等）を使っている場合、SDKが内部でIMDSを使っているので認識していなくても影響する可能性がある。 ステップ2：Microsoft G2-XSルート証明書を追加する カスタム証明書ストアを使っている環境では、Microsoft G2-XSルート証明書を事前に追加しておく必要がある。Microsoft PKIリポジトリから最新のルート証明書を取得し、各環境のトラストストアに追加する。 ステップ3：4月15日前にテスト環境で動作確認 ステージング環境で新しいルート証明書のみを使う設定でアプリを動かし、TLSエラーが出ないことを確認しておく。本番切り替えは段階的に。 実務への影響 この変更が日本のIT現場に与える影響は意外と大きい。特に以下のシナリオで問題が出やすい： SIer・受託開発案件: 納品後に顧客がメンテナンスしていないVMが大量にある場合、OSのルートストアが更新されていない可能性がある。4月15日以降に突然「認証が通らない」という問い合わせが来るパターンが容易に想像できる。 Pythonアプリ: certifiパッケージは独自のCA束を持っており、pipでアップデートしていない環境では古いルートセットのままだ。pip install --upgrade certifiを今すぐ実行すること。 Java・Spring Bootアプリ: JVMに埋め込まれたトラストストアを使っている場合、JDKのバージョンによってはG2-XSが含まれていない可能性がある。最新のJDK/JREへのアップデートを検討すること。 コンテナ環境: Dockerイメージのベースレイヤーが古い場合も同様。FROM ubuntu:22.04のまま何ヶ月もapt updateしていないイメージは要注意。 筆者の見解 率直に言う。この手のルート証明書ローテーションで毎回思うのは、証明書の有効期限やルートの廃止を「知らなかった」で済ませる日本のエンジニアが多すぎるということだ。 セキュリティの話は嫌いだ。細かい話が多いし、関わる人間もなんか面倒くさい人が多い。でも技術的な興味はめちゃくちゃある。特にこういうインフラレベルの変更は、知らないと本当に静かに死ぬのがタチが悪い。HTTPエラーが出るとかならまだいい。Attesd Data検証のエラーは、ログに出るかどうかもアプリの実装次第で、気づかずにセキュリティ検証をスキップしているケースもある。 Azureのプラットフォームとしての信頼性は揺るがない、と今でも思っている。ただMicrosoftが「重大な変更」をTech Communityのブログポストで告知して終わり、というコミュニケーションスタイルはもう少し改善できるんじゃないかとは思う。Azure Portalのバナーで当該サブスクリプションに直接通知するとか、Service Healthで影響リソースを特定するとか、やりようはいくらでもあるはずだ。 ...

Microsoft（マイクロソフト）は、旧称Azure AI FoundryをMicrosoft Foundryとしてリブランドし、GPT-5・GPT-5-mini・GPT-5-nanoを含む新世代モデルへの移行戦略を公式ブログで詳細に公開した。単なるモデル追加ではなく、既存デプロイの自動アップグレードポリシーやPTU（Provisioned Throughput Units）への移行パスまで踏み込んだガイドラインであり、実際にAzure OpenAIを本番運用している組織は内容を把握しておく必要がある。 モデル自動アップグレードとは何か Microsoft Foundryでは、デプロイ設定において「自動アップグレード」を有効にすると、マイクロソフトが指定したタイミングで基盤モデルが新バージョンに切り替わる。たとえばGPT-4oデプロイが自動的にGPT-4o-latestへ更新されるような仕組みだ。 これはコスト効率やパフォーマンス向上の恩恵を自動的に受けられる反面、出力の一貫性が失われるリスクがある。プロンプトとモデルの組み合わせで動作を保証している本番システムでは、意図しないモデル切り替えが品質劣化や動作変化として現れることがある。 今回の公式ガイドラインでは、GPT-5世代への移行に際しても同様のポリシーが適用されることが明示され、ピン留め（特定バージョン固定） とアップグレードのどちらを選ぶかを明確に意識して運用設計する必要があることが改めて強調されている。 PTUとは——消費課金との違いと移行パス PTU（Provisioned Throughput Units）は、一定のスループットをあらかじめ確保する予約型の課金モデルだ。消費量に応じた従量課金（Pay-as-you-go）とは異なり、レスポンス遅延のばらつきが小さく、大量リクエストを安定的に処理できる。 今回の移行戦略では、GPT-5系モデルへの移行にあたり既存のPTUデプロイをどう扱うかのパスが示されている。具体的には： 現行PTUデプロイは廃止スケジュールに従い段階的に終了 新モデルへの移行は事前通知期間を設けてガイド GPT-5-mini・GPT-5-nanoはコスト最適化向けの軽量オプションとして位置付け GPT-5本体はハイエンドタスク向け、miniとnanoはコストを抑えつつ大量処理したいユースケース向けという棲み分けが明確になっている。 実務への影響 日本のエンジニア・IT管理者へ 今すぐ確認すべきこと： 自社のデプロイが自動アップグレード設定になっているか確認する — Azure PortalまたはREST APIでデプロイ設定を確認し、意図せず自動アップグレードが有効になっていないか点検する モデルの非推奨（Retirement）スケジュールを把握する — Microsoft Foundryには各モデルのRetirementページがある。把握していないとある日突然APIが動かなくなる 本番とステージングでモデルバージョンを揃える — ピン留め運用にしているつもりでも環境間でバージョンがずれているケースがある PTU契約中の企業は移行パスを早めに確認する — 特に年間コミットメントで予約しているケースは、GPT-5世代へのPTU移行タイミングの見積もりが必要になる コスト観点での実務ヒント： GPT-5-nanoはトークン単価が大幅に安くなると予想される。分類・要約・フィルタリングなど「重い判断は不要だが大量処理したい」タスクをnanoに切り出す設計を検討する価値がある。 筆者の見解 正直に言う。GPT-5が出るのは間違いなく重要なマイルストーンだ。でも今回の発表で一番注目すべきは、モデルのスペックではなく「移行管理の複雑さが上がり続けている」という現実だと思っている。 モデルが半年〜1年周期で世代交代し、PTUの予約スキームも更新され、プロンプトの動作保証はモデルバージョンに依存する——これを全部自社でハンドリングしながら本番運用し続けるのは、正直かなりしんどい。 そして、ここが核心だが、マイクロソフトは「最も賢いAIを作る競争」では今のところ後れを取っている。GPT-5がどこまで他社の最新モデルに迫れるかはまだわからない。だから筆者が推している構成は変わらない——Microsoft Foundry基盤の上でタスクに最適なモデルを動かすというアーキテクチャだ。Foundry経由でAnthropicモデルも使えるようになっている今、Azureを捨てる必要はない。プラットフォームはMicrosoftのまま、頭脳を選ぶ自由を使えばいい。 PTU移行についてはコスト最適化の観点でガンガン活用すべきだが、特定モデルへの深い依存は避ける設計を心がけたほうがいい。今後も移行は繰り返される。モデルをすぐ交換できる疎結合なアーキテクチャが、長期的には正解だ。 がんばれマイクロソフト。GPT-5で巻き返してくれることを本当に期待している。この批評が「古い批評」になる日を待っている。 出典: この記事は Model Upgrade and Migration Strategy for Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Entra IDに新たなGAアップデートが届いた。「External Multifactor Authentication（外部MFA）」が正式リリースとなり、組織が現在使っているサードパーティMFAプロバイダーをそのまま活かしながら、Entraの条件付きアクセスポリシーに準拠できるようになった。ゼロトラスト移行を検討している日本企業にとって、これは無視できない選択肢だ。 外部MFAとは何か Microsoft Entra IDの「外部MFA（External Multifactor Authentication）」は、Entra ID内蔵のMFA（Microsoft Authenticatorなど）ではなく、DuoやOkta、RSA SecurIDといったサードパーティのMFAソリューションを使いながら、Entraの多要素認証要件を満たせる仕組みだ。 従来は「外部認証方式（External Authentication Methods）」という名称だったが、今回のGA昇格にあわせて機能が拡充・整理された。 仕組みとしては、条件付きアクセスポリシーで「MFA必須」と設定した場合でも、外部プロバイダーによる認証が完了していれば要件を満たしたものとして扱われる。Entra IDが発行するトークンに対して、外部MFAの完了を示すクレームが付与される形だ。 同時に押さえておきたい2026年3月のアップデート群 今回のリリースノートには外部MFAのGA以外にも注目すべき動きがある。 パスキー同期がGA FIDO2ベースの同期パスキー（Synced Passkeys）がGAとなった。iCloudキーチェーンや1Passwordなどのサードパーティパスキープロバイダーに保存したパスキーを、複数デバイス間で同期しながらEntra IDの認証に使えるようになった。デバイス紐付けパスキーと同期パスキーは、管理者がポリシーで使い分けを制御できる。 Entraバックアップ＆リカバリーがPublic Preview 誤操作やセキュリティインシデントによるテナント設定の破損を自動復元する「Entra Backup and Recovery」がPublic Previewに入った。ユーザー・グループ・アプリ・条件付きアクセスポリシーなどの重要オブジェクトを日次バックアップ（P1/P2ライセンスで5日間保持）し、差分レポートと復元ジョブで元に戻せる。 Entra Kerberos によるハイブリッド参加がPublic Preview Entra Connectの同期やAD FSを待たずに、プロビジョニング時点でWindowsデバイスをすぐにHybrid Entra Joinできる新機能。レガシーなフェデレーション依存から脱却する道筋が見えてきた。 実務への影響 日本の大企業・官公庁では、RSAトークンやDuoをすでに全社展開しているケースが多い。これまでは「Entra IDに完全移行しないと条件付きアクセスのMFA要件を満たせない」というハードルが移行の足かせになっていた。外部MFAのGAにより、既存のMFA基盤を維持したまま段階的なゼロトラスト移行が現実的な選択肢になる。 エンジニア・IT管理者が今すぐ確認すべきこと： 現行MFAプロバイダーが外部MFAに対応しているか確認 — Microsoftの認定外部プロバイダーリストを確認し、現用製品がサポートされているか確認する 条件付きアクセスポリシーの見直し — 外部MFAを活用するには、ポリシー側で「認証強度（Authentication Strength）」の設定を正しく構成する必要がある パスキーの試験導入 — 同期パスキーGAを機に、パスワードレス認証のPoC開始を検討する好機だ Entraバックアップの有効化確認 — Public Previewだが即日オンにしておく価値はある。テナント設定を壊した後悔をする前に 筆者の見解 正直に言う。この外部MFA対応は、Microsoftが「現実を認めた」アップデートだ。 日本の大企業が「Entraに移行したいけどDuoの契約が3年残ってる」「RSAトークンを全社員に配り直す予算がない」という現実に直面しながらゼロトラスト移行を止めていた状況は、ずっとおかしかった。認証基盤の刷新を「一気にやらなければならない」という強迫観念が、むしろセキュリティ改善を遅らせてきた。 ゼロトラストの本質はネットワーク境界への依存をやめることだ。MFAプロバイダーがどこのベンダーかは本質じゃない。条件付きアクセスが正しく動いているか、Just-In-Timeで適切な認可が下りているか——そこが問われる。外部MFAはその実現を「今持っている資産で」始めるための現実解だ。 ただし、勘違いしてほしくないのは、これが「VPNとオンプレADを延命させるための言い訳」になってはダメだということ。外部MFAを使いながらも、中長期では認証基盤をEntra IDに集約していく方向性は変えるべきではない。移行の入口として使うのか、現状維持の口実にするのかで、3年後の姿が全然違ってくる。 Entraバックアップの話は別で純粋に嬉しい。テナント設定を管理コンソールで誰かが誤操作してぶっ壊す事故、一度でも経験した人なら分かるはず。「神頼みの手動復元」から「定期スナップショットからの差分復元」に変わるのは、運用品質の話として本当に重要だ。Public Previewとはいえ今すぐ有効化しておくべきだと思う。 Microsoftへの辛口コメントも続けるが、このEntraまわりのアップデートの着実さは評価している。エージェントの管制塔としてのEntra IDという方向性は正しい。がんばれマイクロソフト。 出典: この記事は External Multifactor Authentication (External MFA) Now Generally Available in Microsoft Entra の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

音声でAIと自然にやり取りするリアルタイムアプリ開発が、ついに「本番向け」のステージに入った。MicrosoftがAzure OpenAI GPT Realtime APIの正式GA（一般提供）を発表し、これまでプレビューで試してきた開発者には移行の期限が迫っている。2026年4月30日——それがプレビュー版の廃止日だ。 GPT Realtime API GAで何が変わるのか 今回のGA移行で変わるポイントは大きく4つある。 SDKの差し替え: MicrosoftがプレビューSDKとして独自にリリースしていたものはGAプロトコル非対応。OpenAI公式のSDK（openai-node、openai-python、openai-dotnet等）への移行が必須 エンドポイントURLの変更: /openai/v1/ 形式に統一。2025-04-01-preview のようなAPIバージョン指定はもう含めない WebRTCエンドポイントの更新: ブラウザベースのリアルタイム音声を使っている場合、エフェメラルキー発行エンドポイント（POST /openai/v1/realtime/client_secrets）と接続URL（/openai/v1/realtime/calls）が変わる session.updateイベントの統合: 音声会話（realtime）とリアルタイム文字起こし（transcription）が同一イベントに統合され、typeフィールドで区別するようになった 逆に変わらないことも把握しておきたい。コア機能・音声フォーマットのサポート・モデル能力は引き継がれる。移行コストは想定より小さく、Microsoftは「ほとんどのケースで30〜60分」と明言している。 移行の前提条件を確認する 移行前に以下を確認しておくこと。 プレビュー（Beta）プロトコルを使った既存のAzure OpenAIリソースとデプロイがあること Azureポータルへのアクセス権限（OpenAIリソース管理が可能なロール） SDK依存関係を更新できる開発環境 本番デプロイ前に検証できるテスト環境 現在の実装がWebSocketかWebRTCかの把握 特に注意したいのが**.NET SDK**だ。OpenAI .NET v2.9.0以降でないとGAプロトコルに対応していない。バージョンを固定していたプロジェクトでは要確認。 日本の実務への影響 リアルタイム音声AIは、コールセンター自動化・音声インタフェース付きの業務アプリ・議事録リアルタイム生成など、日本の現場でもニーズが高い領域だ。これがGAになったことで、PoC止まりだったプロジェクトが本番検討のテーブルに乗ってくる。 エンジニア・IT管理者が明日から使える実践ポイント： 既存プレビューアプリの棚卸しをすぐやれ: 4月30日まで時間がない。社内でRealtime APIを試験導入しているチームがあれば、今週中にリストアップして移行計画を立てる 新規開発はGAのクイックスタートから始める: 移行ガイドではなく公式のRealtime API Quickstartが起点。プレビューの癖を引きずらない WebRTCを使っているプロジェクトは特に注意: エンドポイントが2か所変わるので、ブラウザ側とサーバー側で漏れなくテストすること OpenAI公式SDKのバージョン管理を見直す: MicrosoftのプレビューSDKとOpenAI公式SDKが混在しているプロジェクトは、依存関係の整理から始める 筆者の見解 Realtime APIのGAそのものは素直に評価できる。音声AIが「本番で使える」フェーズに入ったのは意義があるし、Azure基盤の上でこれが動くというのは、セキュリティ・コンプライアンス要件の厳しい日本の大企業にとってはむしろ歓迎だろう。 ただ、今回の移行で一つ気になることがある。MicrosoftのプレビューSDKはGAプロトコル非対応、つまりOpenAI公式SDKを使えという話だ。これ、地味にMicrosoftの「自社SDKのリードを取れない」状況を象徴していないか。AzureでOpenAIモデルを使うのにOpenAIのSDKを使えという構造は、Microsoftがプラットフォームとして機能しているのかAPIプロキシとして機能しているのか、少し曖昧に見える。 個人的にはMicrosoft Foundry経由でモデルを選んで動かすという方向性が正しいと思っている。Azureの基盤・認証・ガバナンスはそのまま使いながら、動かすAIモデルは状況に応じて選ぶ。Realtime APIが重要なユースケースではGPT-4oを使えばいい。ただし他のユースケースで別のモデルが優れているなら、そちらを選べばいい。Azureを捨てる必要はない。その上で動くAIを選ぶ自由を使えばいいだけだ。 とにかく今すべきことは明確で、4月30日までに移行を完了させること。30〜60分で終わる作業をギリギリまで放置して障害を起こすのは笑えない。 出典: この記事は Azure OpenAI GPT Realtime API is Now Generally Available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが音声認識の世界に大きな一石を投じた。同社は新しい音声文字起こしモデル「MAI-Transcribe-1」を公開し、多言語音声認識の標準ベンチマークであるFLEURS（Few-shot Learning Evaluation of Universal Representations of Speech）において、11の主要言語でトップの精度を達成したと発表した。OpenAIの「Whisper-large-v3」やGoogleの「Gemini 2.0 Flash」といった強力な競合を差し置いての首位は、音声AI分野の勢力図に明確な変化をもたらすものだ。 MAI-Transcribe-1とは何か 「MAI」はMicrosoft AIを意味するプレフィックスで、同社が独自に研究開発した基盤モデル群に付けられるブランドだ。MAI-Transcribe-1はその音声認識特化モデルであり、大規模な多言語音声データで訓練されている。 FLEURSベンチマークは、語族や音素体系が異なる多様な言語にわたって精度を測定するため、単一言語チューニングでは太刀打ちできない。11言語での首位は、モデルのアーキテクチャと学習データの双方において競合を凌駕していることを示している。 比較対象のWhisper-large-v3はOpenAIが公開しているオープンソースの文字起こしモデルとして業界標準的な地位を確立しており、多くの日本企業が会議録自動化や字幕生成に採用している。それを超えた精度というのは、実際の導入効果に直結する話だ。 なぜこれが重要か——日本のIT現場への影響 日本語は音声認識において特に難しい言語の一つだ。同音異義語が多く、文脈依存性が高く、敬語・専門用語・固有名詞のバリエーションも膨大にある。国内の会議録自動化ツールや医療・法務分野での音声入力システムが精度の壁に悩まされてきた背景がある。 FLEURSでの好成績が日本語を含む言語で達成されているならば、これは業務用途における文字起こし精度の底上げとして直接的なインパクトをもたらす。特にMicrosoft 365 CopilotやTeamsの会議文字起こし機能との統合が想定されることから、すでにM365環境を利用している日本企業にとっては追加投資なしで恩恵を受けられる可能性が高い。 実務での活用ポイント 1. Azure AI Speechとの連携を確認する MicrosoftはAzure AI Speech（旧Cognitive Services音声系）のバックエンドにMAI系モデルを順次統合している。現在Azure AI Speechを使って文字起こし系のAPIを呼んでいる場合、モデルバージョンのアップデートを追跡し、MAI-Transcribe-1が利用可能になった際に切り替え検証を行う価値がある。 2. Teams Premium / Copilot for M365の会議文字起こしを再評価する 会議の議事録自動生成に「精度が足りない」としてTeamsの文字起こしを使っていない組織は、今後数ヶ月以内に再評価の機会が来る。比較検証のために、代表的な会議シナリオでの文字起こし精度を定期的にスコアリングする仕組みを作っておくと良い。 3. オンプレミス要件がある場合はWhisperとの使い分けを継続検討 Whisper-large-v3はOSSであり、セキュリティポリシー上クラウドAPIを使えない環境でも自前でホスティングできる。MAI-Transcribe-1がAPIのみ提供であれば、機密性の高いデータを扱う金融・医療分野ではWhisperを内製運用するほうが現実的なケースも引き続き存在する。 筆者の見解 音声認識の精度競争は、ここ数年でOpenAIのWhisperが「実用的に使えるレベル」のハードルを一気に引き下げた。それまで専業ベンダーの独占市場だったところに汎用AIが殴り込んだ形だ。今回MicrosoftがMAI-Transcribe-1でWhisperを超えたことは、競合への対抗というよりも「Microsoft製品エコシステムの中で最高水準の音声処理を完結させる」という戦略的な意図を感じる。 特にCopilot統合の流れを見ると、会議の文字起こし→要約→タスク抽出→Plannerへの自動登録、というワークフローをMicrosoftが自社でクローズドループとして完成させようとしていることは明白だ。その基盤として最高精度の文字起こしモデルを持つことは、エコシステム全体の品質を底上げする。 一方で懸念もある。ベンチマーク上の最高精度が、実際の業務環境——騒がしい会議室、アクセントの強い話者、専門用語が飛び交う技術討議——でそのまま発揮されるかは別の話だ。FLEURSは学術的な評価軸であり、ノイズ耐性や話者適応性については別途評価が必要になる。 今後のポイントは、MAIシリーズがAzureのマネージドサービスとして一般提供されるタイミングと価格体系だ。精度がいくら高くても、Whisperの無料OSSという選択肢に対してコスト優位性を示せなければ、エンタープライズ以外での普及は限定的になる。日本市場では特に中堅・中小企業のコスト感度が高く、この点が普及速度を左右するだろう。音声AIの「次のWhisperモーメント」が来るとすれば、MAI-Transcribe-1はその有力候補だ。 出典: この記事は Microsoft releases MAI-Transcribe-1, the most accurate transcription model in the world の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ciscoのサーバー管理基盤に、認証を一切必要とせず管理者権限を乗っ取れるという非常に深刻な脆弱性が発見された。データセンターやオンプレミス環境でCiscoサーバーを運用している国内の企業・組織にとって、即座の対応が求められる案件だ。 Cisco IMCとは何か——見落とされがちな「隠れた管理経路」 Cisco IMC（Integrated Management Controller）は、Cisco UCS C-SeriesやE-SeriesサーバーのマザーボードにハードウェアとしてビルトインされているOOB（Out-of-Band）管理モジュールだ。OSがクラッシュしていても、電源が切れていても、XMLのAPI・WebUI・CLIを通じてサーバーを遠隔管理できる。 いわばサーバーの「バックドア的な管理口」であり、BMC（Baseboard Management Controller）と同様の役割を果たす。管理の利便性が高い一方、ネットワークに露出していれば攻撃の入り口にもなりうる。 脆弱性の詳細——パスワード変更処理の不具合が致命的 今回発見されたCVE-2026-20093は、Cisco IMCのパスワード変更機能における不適切な処理に起因する。攻撃者は認証なしでHTTPリクエストを細工して送信するだけで、システム上の任意ユーザー（Adminを含む）のパスワードを変更し、そのユーザーとしてシステムにアクセスできてしまう。 CVSSスコアはクリティカル評価であり、現時点でワームやランサムウェアによる実績のある悪用事例やPoCコードは確認されていないものの、Cisco PSIRTは「ワークアラウンドなし・即時アップグレードを強く推奨」と異例の表現で警告している。「ワークアラウンドなし」という点が特に重く、一時的な緩和策が存在しない以上、パッチ適用以外の選択肢がない。 同時公開された他の重大脆弱性も要注意 今回のリリースでは、IMCの問題に加え、もう一つのクリティカル脆弱性も修正されている。 CVE-2026-20160は、Cisco Smart Software Manager On-Prem（SSM On-Prem）のAPIに対して細工されたリクエストを送るだけで、権限なしの攻撃者がOSレベルのroot権限でリモートコード実行（RCE）できるというものだ。ライセンス管理サーバーとしてオンプレ環境に展開している組織は特に影響を受ける。 さらに今月初旬には、Cisco Secure Firewall Management Center（FMC）の最高深刻度RCE脆弱性（CVE-2026-20131）が「Interlockランサムウェア」によるゼロデイ攻撃で悪用されており、CISAが連邦機関に3日以内のパッチ適用を命じる事態にまで発展していた。 実務への影響——国内エンジニアが明日すべきこと 影響範囲の確認（最優先） データセンターやサーバールームでCisco UCS C-Series / E-Seriesを運用しているか確認 IMCのWebUIやAPIポートが外部ネットワークやDMZに露出していないか即座にレビュー 原則としてIMCの管理ポートは専用管理VLANに隔離し、インターネットに直接露出させない構成を徹底する パッチ適用の手順 Cisco Security Advisoryから修正済みバージョンを確認 IMCのファームウェアアップデートはOSと独立して行えるが、メンテナンス窓口の設定が必要 ネットワーク的な隔離ができていない場合は、パッチ適用までの間IMCへのアクセスをACLで制限することを検討（根本解決にはならないが被害軽減に有効） SSM On-Premの対応 CVE-2026-20160の影響を受けるSSM On-Premはエンタープライズ向けライセンス管理サーバーであり、Cisco製品を多数運用している企業ほど導入している可能性が高い。管理コンソールのURL露出状況を確認し、同様に即時パッチを適用すること。 筆者の見解 今回の一連の脆弱性で改めて浮き彫りになったのは、「インフラの管理プレーン」がいかに攻撃者に狙われやすいか、という現実だ。IMCのようなOOB管理機能はOSレイヤーより「下」に存在するため、EDR（Endpoint Detection & Response）などのセキュリティエージェントの監視対象外になることが多い。攻撃者にとっては「見えない経路」から侵入できる絶好の標的といえる。 ゼロトラストの文脈でも、「管理ネットワークの分離」と「BMC/IMC等のファームウェア管理」は優先度の高い課題として位置づけられているが、実態として後回しにされているケースが多い。今回のインシデントはその重要性を再認識させる機会だ。 また、Ciscoの開発環境がサプライチェーン攻撃（Trivyを悪用した認証情報窃取）によって侵害されたという報告も並行してなされており、単なる製品脆弱性の話にとどまらない。サプライチェーンセキュリティとインフラ管理の両面でリスク評価を見直す時期に来ている。 Ciscoを使い続けるエンジニアとしては、今後はIMCやSSM On-Premのようなインフラ管理コンポーネントのパッチ管理を、OSやアプリケーションと同列に扱う運用体制の構築が急務だと感じる。「ハードウェアは一度設定したら触らない」という古い慣習は、今の脅威環境には通用しない。 出典: この記事は Critical Cisco IMC auth bypass gives attackers Admin access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンタープライズ向けのセキュアファイル転送製品「Progress ShareFile」に、認証なしでリモートコード実行（RCE）まで到達できる深刻な脆弱性チェーンが発見された。既にPoCの詳細が公開されており、パッチ未適用環境への攻撃が現実的な脅威となっている。 何が見つかったのか オフェンシブセキュリティ企業のwatchTowrは、Progress ShareFile の Storage Zones Controller（SZC）コンポーネント（ブランチ5.x）に2つの脆弱性を発見した。 CVE-2026-2699（認証バイパス）: HTTPリダイレクトの不正な処理により、未認証のままShareFile管理インターフェースへアクセスできる。 CVE-2026-2701（リモートコード実行）: ファイルアップロード・展開機能を悪用し、アプリケーションのWebルートに悪意のあるASPX Webシェルを設置できる。 この2つを連鎖させた攻撃シナリオでは、攻撃者はまずCVE-2026-2699で管理画面に侵入し、ストレージゾーンの設定変更やパスフレーズ関連のシークレット値を制御下に置く。次にその情報を使って有効なHMAC署名を生成し、CVE-2026-2701でWebシェルを展開してサーバー上での任意コード実行を達成する。 認証なしでここまで到達できる「pre-auth RCE」という点が、このチェーンの最大の危険性だ。 なぜこれが重要か — ファイル転送製品は標的にされやすい ファイル転送・共有製品はランサムウェア集団や国家系脅威アクターが好んで狙うカテゴリだ。過去を振り返れば、Accellion FTA、GoAnywhere MFT、MOVEit Transfer、Cleo といった製品の脆弱性が相次いでClopをはじめとするランサムウェアグループに悪用され、大規模なデータ漏洩につながっている。 ShareFileも同様に、大企業・中堅企業が機密文書をやり取りするために使う製品であり、一度侵害されると内部の重要ファイルへのアクセスが容易になる。watchTowrのスキャンによれば、Storage Zone Controllerはインターネット上に約3万台が公開露出しており、ShadowServer Foundationも700台のインスタンスを観測している（多くが米国・欧州）。 日本国内での利用実態は公表されていないが、グローバルなSaaSやハイブリッドクラウド環境を持つ企業では、SZCをオンプレミスまたはプライベートクラウドに構築しているケースが存在する。自社環境でShareFile SZCを運用している場合は即刻確認が必要だ。 実務での対応ポイント 1. バージョン確認と即時パッチ適用 Progress は2026年3月10日に修正版「ShareFile 5.12.4」をリリース済みだ。SZCのバージョンが5.12.4未満であれば、最優先でアップデートする。 2. ネットワーク露出の最小化 SZCをインターネットに直接公開している場合は、VPNやプライベートネットワーク経由のアクセスに限定する。公開が必要な場合もWAF・IPホワイトリストで防御層を追加する。 3. 侵害痕跡（IoC）の確認 Webルート配下に不審なASPXファイルが存在しないか確認する。管理画面へのアクセスログや設定変更履歴を遡り、異常なアクセスがないかチェックする。 4. HMAC関連シークレットの再生成 パッチ適用後、ゾーンパスフレーズや関連シークレットを新しい値にローテーションする。攻撃者が侵害前に値を取得している可能性を考慮するためだ。 筆者の見解 今回の脆弱性は「個別の欠陥が軽微に見えても、組み合わせると壊滅的になる」という脆弱性チェーンの典型例だ。CVE-2026-2699単体では情報漏洩止まりのように見えるが、CVE-2026-2701と組み合わせることでサーバー完全掌握まで一直線に繋がる。 ファイル転送製品の脆弱性が繰り返し大規模攻撃に悪用されている現状を見ると、これらの製品に対するセキュリティ成熟度の低さが業界全体の課題として浮かび上がる。「ファイルを安全に送れればいい」というプロダクト観から、「常時攻撃にさらされている前提でハードニングする」発想への転換が求められている。 幸い今回は公開前にResponsible Disclosureが機能し、修正版が先にリリースされている。しかしwatchTowrが技術詳細を公開した以上、攻撃者がエクスプロイトを実装するのは時間の問題だ。「パッチが出ている」という安心感で対応を先送りにするのではなく、72時間以内の適用を目標に動いてほしい。 MOVEit、Cleo、そして今回のShareFile——この系譜を見るたびに、エンタープライズのファイル転送インフラがいかに攻撃面として見逃されてきたかを痛感する。次のターゲットが何かは分からないが、「自社で使っているファイル転送製品の脆弱性を定期的にトラッキングする」習慣を今すぐ組織に根付かせるべきだろう。 出典: この記事は New Progress ShareFile flaws can be chained in pre-auth RCE attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「コードは安全だった」——それでも280億円が消えた 2026年4月1日、Solanaブロックチェーン上のDeFi取引プラットフォーム「Drift Protocol」が、少なくとも約280億円（285百万ドル）もの資金流出を受けた。驚くべきは、攻撃者がスマートコントラクトの脆弱性を一切利用しなかったという点だ。プログラムに欠陥はなく、シードフレーズも漏洩していない。破られたのは「コード」ではなく「ガバナンスの信頼構造」そのものだった。 攻撃の手口——8日間かけて仕込まれた時限爆弾 攻撃は3月23日から30日にかけて入念に準備された。攻撃者はまず「Durable Nonce Account（耐久ナンスアカウント）」と呼ばれるSolanaの機能を活用した。 通常、ブロックチェーンのトランザクションにはブロックハッシュが使われるため、署名からおよそ2分以内に実行しなければ無効になる。Durable Nonceはこの制約を取り除き、署名済みトランザクションを任意のタイミングまで保持・実行できる機能だ。正規のユースケースとして設計されたこの機能が、今回は悪用された。 次に攻撃者は、Driftの「Security Council（セキュリティ評議会）」——プロトコルの管理権限を持つマルチシグ委員会——のメンバーから、必要閾値である5人中2人の署名（2/5マルチシグ）を取得した。この署名取得プロセスの詳細は公開されていないが、ソーシャルエンジニアリングや何らかの偽装が使われた可能性が高い。 4月1日、攻撃者は正規のトランザクションをひとつ実行した直後、準備していた悪意ある署名済みトランザクションを矢継ぎ早に実行。数分のうちに管理者権限を自身に移転させた。その後、悪意あるアセットの導入、出金制限の撤廃、そして資金の抜き取りへと一気に進んだ。 なぜこれが重要か——「ガバナンス攻撃」という新たな脅威 Web3セキュリティの文脈では、スマートコントラクトの脆弱性（バグ、ロジックエラー、再入攻撃など）が主要な攻撃ベクターとして語られることが多い。しかし今回のDrift事案は、ガバナンス機構そのものを標的にする「ガバナンス攻撃」が現実の脅威であることを証明した。 DeFiプロトコルの多くは、プロトコルのアップグレードや緊急停止などの権限を「マルチシグ委員会」や「DAO投票」に委ねている。これはコードの単一障害点を減らす設計だが、裏を返せば委員会メンバーへのアクセスを確保することで、コードを触らずにシステムを掌握できるということでもある。 日本のIT現場に直接影響はないと思われるかもしれないが、この攻撃手法の本質——「正規の権限委譲フローを悪用し、タイミングを計って実行する」——はブロックチェーン以外の世界でも通用する。クラウドのIAMロール委譲、Active Directoryの管理者委任、SaaSのOAuth連携など、どこにでもある「信頼ベースの権限モデル」が持つリスクとして読み替えられる。 実務への影響——エンジニア・IT管理者が今すぐ確認すべきこと 1. マルチシグ・管理者委任の閾値設計を見直す 今回の2/5という閾値が十分だったかを問い直したい。Web3に限らず、Azure AD PIMやAWS Organizations SCPなど、特権操作に必要な承認者数と承認プロセスの堅牢性を確認しよう。 2. 「事前署名」や「委任」の有効期限を管理する Durable Nonceに相当する「後から実行できる権限の付与」が自社環境にないか確認する。具体的には、長期有効なSAMLアサーション、無期限のAPIトークン、期限なしのOAuthスコープなどが該当する。 3. 異常なアクティビティの早期検知体制を整える Driftは「異常を検知してからユーザーに警告」したが、時すでに遅しだった。管理操作のログを集約し、予期しない権限変更を即座に通知するアラートを設定しておくべきだ。Azure MonitorやAWS CloudTrailを使った特権操作の監視が典型的な対策になる。 4. ゼロ信頼（Zero Trust）原則の徹底 マルチシグの署名者が「信頼できる人物」であっても、その操作内容は常に検証する仕組みが必要だ。「Verify explicitly, assume breach」の原則は、Web3のガバナンス設計にも応用できる。 筆者の見解 今回の事件が示す最も重要な教訓は、「セキュリティの最弱点は常に人間だ」という普遍的な事実だ。Driftのスマートコントラクト自体は機能通りに動いた。バグはなかった。しかし人間で構成されたガバナンス層が破られた。 ブロックチェーン業界は「コードは嘘をつかない」「信頼が不要なシステム（Trustless）」をセールスポイントとしてきたが、現実のプロトコルはどこかで「人間の信頼」に依存している。そのギャップを突かれたのが今回の攻撃だ。 より広い視点で見ると、DeFiセキュリティの成熟は、スマートコントラクト監査だけでなくガバナンス設計の監査まで含む段階に入ったと言えるだろう。タイムロック（権限変更に意図的な遅延を設ける仕組み）やオンチェーンガバナンスの透明化、あるいは2/5より高い閾値の採用など、構造的な対策が業界標準になっていくことが予想される。 日本の企業が直接DeFiに関わるケースはまだ限定的だが、Web3を活用したB2Bサービスや、NFTを使ったロイヤリティプログラムを展開しようとする企業は増えている。「スマートコントラクトが安全なら大丈夫」という過信は禁物だ。今後は「ガバナンスの堅牢性」を問われる時代が来る——Driftの事件はそのことを、280億円という代償とともに証明した。 出典: この記事は Drift loses $280 million as hackers seize Security Council powers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「漏洩コード」への好奇心を狙った巧妙な攻撃 2026年3月31日、Anthropicが開発するターミナル型AIエージェント「Claude Code」のソースコードが、npmパッケージへの誤ったファイル同梱により外部に流出した。59.8MBのJavaScriptソースマップに含まれた51万3,000行にわたる未難読化TypeScriptコードは、わずか数時間でGitHub上に拡散し、数千回フォークされるほど注目を集めた。 この事故からわずか数日後、クラウドセキュリティ企業Zscalerの研究チームが危険な動きを確認した。「idbzoomh」というユーザーがGitHub上に偽の漏洩リポジトリを作成し、「エンタープライズ機能を解除済み・使用制限なし」と謳って訪問者を引き込んでいたのだ。 攻撃の仕組み——SEO最適化からVidar投下まで 攻撃者の手口は周到だった。偽リポジトリはSEO（検索エンジン最適化）が施されており、Googleで「leaked Claude Code」などと検索すると上位に表示される仕掛けになっていた。流出コードに興味を持った開発者がリポジトリにたどり着くと、7-Zip形式の圧縮アーカイブをダウンロードするよう誘導される。 アーカイブ内にはClaudeCode_x64.exeというRust製の実行ファイルが入っており、起動するとコモディティ型の情報窃取マルウェアVidarと、ネットワークトラフィックをプロキシするGhostSocksが展開される。 VidarはStealer系マルウェアの定番ツールで、ブラウザの保存パスワード、クッキー、暗号資産ウォレット、ファイルなどを幅広く収集してC2サーバーへ送信する。GhostSocksと組み合わせることで、感染端末を踏み台にした二次攻撃への準備も整う。 Zscalerはさらに、同一の攻撃者とみられる別のリポジトリも発見している。こちらは「Download ZIP」ボタンを設置しているが調査時点では機能していなかったため、配信戦略を実験中と推測されている。悪意あるアーカイブ自体も頻繁に更新されており、将来的に別ペイロードが追加される可能性がある。 なぜこれが重要か——日本のIT現場への影響 この攻撃が示すのは、セキュリティインシデントの「情報格差」を突く手法が高度化しているという事実だ。 開発者やエンジニアは、著名ツールのソースコードが流出したと聞けば当然興味を持つ。「隠し機能があるかもしれない」「普段使えない機能が見られるかもしれない」という好奇心は、セキュリティ意識の高い人材であっても生まれ得る。攻撃者はこの心理を巧みに利用している。 日本国内でもClaude Codeの流出は広く報じられ、GitHubで公開されたコードを参照したエンジニアは多い。偽リポジトリにたどり着いてしまった人がいないとは言い切れない状況だ。 実務での活用ポイント エンジニア・開発者向け GitHubで「話題になっているコード」を検索する際は、アカウントの作成日・コントリビュート履歴・Star数の伸び方を確認する習慣を持つ。突然現れた新規アカウントの高トラフィックリポジトリは要注意。 実行ファイル（.exe）が含まれるアーカイブは、たとえ開発ツールを装っていても絶対に実行しない。公式npmパッケージや公式GitHubリリースページのみを信頼する。 EDR（Endpoint Detection and Response）やウイルス対策ツールが最新の定義ファイルに更新されているか定期確認する。 IT管理者・セキュリティ担当者向け 社内エンジニアに「Claude Code漏洩」に関するフィッシング・マルウェアキャンペーンが存在することをアナウンスする。 プロキシやEDRのログでClaudeCode_x64.exeや7-Zipアーカイブ経由の実行ファイル起動を監視する。 GhostSocksによるSocksプロキシ通信の兆候（異常な外部向けトラフィック）を検知ルールに追加する。 筆者の見解 今回の事例は、「AIツールへの高い関心」と「情報流出への好奇心」という2つの要因が重なったタイミングを巧みに狙ったものだ。攻撃者はAnthropicの事故を受けてほぼリアルタイムで偽リポジトリを立ち上げており、その対応速度には改めて脅威を感じる。 特に注目したいのは、攻撃の「入り口」がGoogle検索であるという点だ。これまでフィッシングメールやSNS広告が主流だった初期侵入経路が、SEOを悪用した検索結果汚染へとシフトしてきている。GitHubはオープンプラットフォームの性質上、こうした悪用を完全に防ぐことが難しく、エンドユーザー側のリテラシー向上が不可欠となっている。 生成AIツールへの注目度が高まるほど、関連する「偽情報・偽ツール」を使った攻撃も増加する。Claude Codeに限らず、Copilot・Gemini・Codexといったコーディングエージェントの動向に関する検索でも同様の手口が使われる可能性が高い。「公式以外からは絶対に入手しない」という原則を組織全体に徹底させることが、今後ますます重要になると確信している。 出典: この記事は Claude Code leak used to push infostealer malware on GitHub の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのOS展開ツール「Microsoft Deployment Toolkit（MDT）」がついに廃止される。長年にわたり無償で提供されてきたこのツールは、日本の多くのIT現場でも静かに、しかし確実に稼働し続けてきた。今回の廃止宣言は、単なるツールの終焉ではなく、モダンIT管理への移行が抱える「見えない前提の崩壊」を突きつけている。 MDTとは何だったのか MDT（Microsoft Deployment Toolkit）は、Windowsのクリーンインストールや企業展開を効率化するための無償ユーティリティだ。IT管理者はMDTを使ってカスタムWinPE環境を構築し、タスクシーケンスと呼ばれる自動化スクリプトでOS・アプリ・設定を一括展開していた。 特に日本の中小〜中堅企業では、高額なSCCM（Microsoft Endpoint Configuration Manager）を導入する予算がない中でも、MDTを活用することで数十〜数百台規模のPC展開を自前で回してきた現場は少なくない。ゼロコストで使えるにもかかわらず、機能の柔軟性は非常に高く、カスタムドライバーの注入、オフライン展開、WIM形式のイメージ管理など、企業ニーズに細かく対応できた。 「クラウド移行すればいい」では済まない理由 MicrosoftはMDTの後継として、Windows AutopilotとMicrosoft Intuneの組み合わせを推奨している。確かにこのモダン管理ソリューションは、インターネット経由でデバイスをゼロタッチプロビジョニングできる点で革新的だ。 しかし現実には、すべての企業がこのクラウド移行に追随できるわけではない。 オフライン・閉域環境の問題：製造業や官公庁、医療機関など、セキュリティポリシーによりインターネット接続が制限された環境では、Autopilotはそもそも動作しない。MDTはLAN内で完結する展開が得意だったが、その代替がない。 複雑なタスクシーケンスの再現：MDTは数百ステップに及ぶカスタムタスクシーケンスを組める。IntuneのWindows Autopilot + ESP（Enrollment Status Page）では同等の制御を実現するのは難しく、移行に多大な工数がかかる。 ライセンスコストの壁：AutopilotをフルActivateするにはMicrosoft Intune（旧Endpoint Manager）のライセンスが必要で、これはMicrosoft 365 Business Premiumや別途EMS E3以上のライセンスが前提となる。既存のMicrosoft 365 Business Basicユーザーには、追加コストが発生する。 実務への影響と対応策 短期的な対応 MDTは現時点でまだ利用可能だが、新機能追加はなくセキュリティ修正のみとなる。既存のMDT環境は当面動作するものの、将来のWindows更新への追随性が低下していく。今すぐ代替を探す必要はないが、ロードマップを立てておくことが急務だ。 WDS（Windows Deployment Services）との組み合わせを維持しつつ、IntuneベースのAutopilotへの段階移行を計画する Microsoft Configuration Manager（SCCM）へのアップグレードを検討する。共同管理（Co-management）機能でIntuneとの並存が可能 オープンソース代替の評価：OSDeploy、FOG Project、WindowsAutoPilot with HYBRIDなどのツールも視野に入れる 中長期的な移行戦略 2025〜2026年にかけて、日本企業のIT担当者はデバイス管理の再設計を迫られるだろう。MDTに依存した「オンプレ完結型」の展開フローから、クラウド活用を前提とした「ゼロタッチ展開」への転換は避けられない方向性だ。ただし、そのペースと深度は組織ごとに異なる。 Intuneへの移行チェックリストとして以下を推奨する： 現在のMDTタスクシーケンスの棚卸し（何がカスタム実装されているか） デバイスのAAD Join（Microsoft Entra ID参加）または Hybrid Azure AD Join の対応状況確認 アプリのWin32パッケージング（.intunewin形式）への変換作業の見積もり ネットワーク環境のAutopilot対応確認（プロキシ・ファイアウォール設定） 筆者の見解 MDTの廃止は、Microsoftが長年推進してきた「クラウドファースト」戦略の帰結であり、ある意味で予告されていた出来事だ。しかし私が懸念するのは、移行の「速度感のミスマッチ」だ。 Microsoftはモダン管理への移行を「シンプルで速い」と説明するが、現場のIT担当者——特に数人で数百台を管理している中小企業の兼任担当者——にとって、MDTで構築した展開インフラをゼロから再設計する工数は決して軽くない。ツールが廃止されても、現場の課題は消えないのだ。 一方で、Autopilot + Intuneの組み合わせが成熟しつつあることも事実だ。Windows Autopilot Device Preparationの登場や、Intune Suite（Advanced Endpoint Analyticsなど）の充実は、クラウド移行のメリットを確実に押し上げている。 ...