Tech News JP

数ヶ月の作業が、1回の会話に あなたが小さなEC事業者だとして、新商品を出そうと思ったとき、何から始めるだろうか。トレンド調査、競合調査、サプライヤーの比較検討、サンプル取り寄せ、価格交渉——これらをすべてこなして商品を棚に並べるまで、早くて数週間、普通は数ヶ月かかる。 Alibaba.comが2024年にリリースしたAIソーシングツール「Accio」は、この流れを根本から変えつつある。2026年3月時点で月間アクティブユーザーが1000万人を突破し、Alibabaユーザーの約5人に1人が商品調達にAIを活用するまでになった。 Accioは「ChatGPTに似た見た目」でまったく違うことをしている インターフェースはChatGPTやその他の対話型AIと見た目は似ている。テキストボックスに質問を入力し、「Fast」か「Thinking」モードを選ぶだけだ。 しかし返ってくるものが違う。テキストだけでなく、市場トレンドのグラフ、サプライヤーへのリンク、ビジュアル資料が組み合わさって返ってくる。さらにAIが追加質問をしながらニーズを絞り込み、最終的に「このサプライヤーに当たれ」という具体的な候補を提示する。 イリノイ州で小規模アウトドアブランドを運営するMike McClaryの事例が象徴的だ。彼は2017年に製造を止めた懐中電灯の復活を検討した際、まずAccioに旧モデルの設計・原価・利益率を伝えた。するとAccioはサイズの最適化、輝度調整、充電方式の変更を提案した上で、中国・寧波の製造工場を特定。製造コストを17ドルから約2.5ドルまで圧縮できる見通しを示した。 その後の交渉はMcClaryが自分で行い、1ヶ月後には新バージョンがAmazonに並んだ。 なぜこれが重要か——「調査」という認知負荷の解消 この事例で注目すべきは価格交渉の結果だけではない。「何をどこで作るか」という意思決定プロセス全体の構造が変わっている点だ。 従来、中小EC事業者が新商品を出す際のボトルネックは資金よりも「調査にかかる時間と労力」だった。情報収集・比較・絞り込みという認知負荷の高い作業が、参入障壁として機能していた。 Accioはこの部分を代替することで、「アイデアを持っているが動けない人」を「実際に動ける人」に変えている。これはAIエージェントの本質的な価値——人間の認知負荷を削減し、より本質的な判断に人間のリソースを集中させること——を実務レベルで実現した好例だ。 実務への影響——日本のEC事業者・IT管理者へのヒント EC事業者・商品企画担当者へ： 国内の小規模ECでも、海外サプライヤー探しにAccioは試す価値がある。Alibaba.com上で動作するため、既存のAlibaba.comアカウントがあればすぐ使える 「AIに丸投げ」ではなく「AIが絞り込み→人間が最終判断と交渉」という分業設計が現実的で再現性も高い 競合がAIで商品開発サイクルを圧縮し始めた今、従来の手作業プロセスを維持することは相対的な遅れを意味する IT管理者・DX推進担当者へ： Accioのアーキテクチャは参考になる。社内ツールに「質問→絞り込み→具体的候補提示」という流れをAIで設計する際のヒントが詰まっている 複数のフロンティアモデル（自社開発のQwenシリーズ含む）を組み合わせて動いている点も見逃せない。単一モデルへの依存を避け、タスクに応じてモデルを使い分ける設計は、企業AIの実装でも今後の標準になるだろう 筆者の見解 Accioの事例を見て改めて感じるのは、AIの価値が「賢い回答を返すこと」よりも「人間が実際に行動できる状態に持っていくこと」に移ってきているという実感だ。 数週間かかっていた調査を1回の会話で終わらせるというのは、単なる効率化ではない。これまでコストや時間の壁で参入できなかった人が市場に入れるようになる、構造的な変化だ。 一方で、AIが提示したサプライヤー候補の品質評価、サンプル確認、契約交渉——これらは依然として人間の目と判断が必要な部分として残っている。「AIが全部やってくれる」ではなく「AIが準備を整え、人間が意思決定する」という役割分担の明確化こそ、今のAI活用の正しい設計思想だと思う。 日本の中小企業やEC事業者にとっても、こうしたツールの存在を知っているかどうかで、今後の競争力に差が出てくる局面が近づいている。「情報を追うより実際に使って成果を出す」——この姿勢が、これから最も重要な差別化要因になるはずだ。 AIエージェントが自律的に判断・実行するループを設計できる側と、そのループを動かしてもらう側——その分岐点は、思っているよりずっと早く来ている。 出典: この記事は AI is changing how small online sellers decide what to make の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIと雇用の議論が迷走している本当の理由 シリコンバレーでは「AIによる雇用壊滅」がすでに既定路線として語られている。著名なAI企業のCEOが「5年以内にAIがすべての仕事をこなせる」と発言し、研究者が「早期キャリアラダーの崩壊」を予言する——そんな言説が飛び交う中、多くの働く人々が漠然とした不安を抱えている。 しかし、シカゴ大学の経済学者アレックス・イマス（Alex Imas）氏は、こうした議論に根本的な欠陥があると指摘する。問題は「AIと仕事の将来を予測するツールが壊滅的に貧弱」なことだ、と。 「露出度」という幻想 現在、AIと雇用の研究で広く使われているのが、米国政府が1998年に開始した職業情報データベース「O*NET」だ。数千もの職業について、それぞれが含む具体的なタスクを詳細に記録したもので、研究機関はこのデータをもとに「各職業がどれだけAIに代替される可能性があるか（露出度）」を算出してきた。 たとえばある分析では、不動産エージェントの業務の28%がAIによって処理可能と算出されている。しかしイマス氏は言う。「露出度だけでは雇用喪失を予測するまったく無意味な指標だ」と。 確かに、すべてのタスクをAIが人間の指示なしに実行でき、かつAIのコストが人件費を下回るならば、その職種は消滅しうる。だが大多数の仕事は、そこまで単純ではない。 本当に問われるべき問い：補完か代替か より重要な問いはこうだ。AIが入ることで、その労働者の生産性は上がるのか？ そして生産性が上がったとき、雇用主は人をもっと雇うのか、それとも減らすのか？ たとえばコーディングを考えてみよう。AIツールを使いこなすエンジニアが、以前は3日かかっていた実装を1日でこなせるようになったとする。同じコストでより多くのアウトプットが得られる雇用主は——同じ予算でより多く雇うだろうか、それとも人数を削減するだろうか？ その答えは産業によって、企業によって、仕事の性質によって大きく異なる。ある業界では「AIで生産性が上がったから、もっと積極的に開発を進めよう」と採用を増やすかもしれない。別の業界では「同じアウトプットが少ない人数で出るなら人件費を削れる」となるかもしれない。 この「補完性（complementarity）」のデータが今の研究には決定的に欠けている、とイマス氏は主張する。だから「マンハッタン計画レベルの努力が必要だ」と経済学者たちに呼びかけているのだ。 実務への影響——日本のエンジニア・IT管理者に向けて 日本のIT現場でも、この議論は直接的に関わってくる。特に注目すべき点がいくつかある。 「早期キャリアラダーの崩壊」リスク：研修中のジュニアエンジニアや新卒がAIで補完されてきた「入門タスク」をこなす機会が減れば、スキル習得の経路そのものが変わる。OJTの設計を根本から見直すタイミングが来ている。 生産性向上の果実をどこに再投資するか：AIで工数が削減されたとき、「コスト削減」にのみ使うのか「より高度なプロダクト開発」に使うのかで、チームの将来は大きく変わる。経営層との合意形成が今から必要だ。 露出度の高い単純タスクに頼り切っている構造の見直し：もし自分の業務の大半がAIによって高品質に処理できるタスクで占められているなら、それは「危機」ではなく「変革の好機」だ。人間にしか担えない判断・創造・調整の領域へシフトする計画を立てよう。 筆者の見解 この記事で最も重要なのは、著名なAI企業幹部たちの「5年で人類の仕事を全部やる」という発言が、単なる過剰な楽観主義（あるいは意図的なナラティブ形成）である可能性を、経済学の視点から冷静に解体している点だ。 「露出度」という単一指標に依存した議論は、確かに直感的でわかりやすい。だがイマス氏が言うように、その仕事が「消える」かどうかは補完性——つまり、そのタスクをAIが担えるようになったとき、残りの人間的部分の価値がどう変わるか——で決まる。 私が日々感じるのも、「AIが得意なことを全部AIに渡した後、自分の価値はどこにあるか」という問いこそが本質だということだ。AIが処理できるタスクはAIに渡し、人間は判断・設計・関係構築・文脈の読解に集中する。この構造を自分の職能として確立できれば、補完性は高く保たれる。 一方で、この構造転換を「自分には関係ない」と静観している企業や個人には、静かに足元が崩れるリスクがある。日本のIT業界は全体として、この変化のスピードを過小評価している傾向がある。「うちはSIerだから」「業界が特殊だから」という安心感が最も危ういかもしれない。 イマス氏が「マンハッタン計画が必要」と述べるほど危機感を持つのも、データがなければ政策も打てない、という危機感からだ。日本でも政府・学術・産業界が連携してこの実態データを収集しなければ、気づいたときには手遅れという可能性は排除できない。 単純に「AIに仕事が奪われる/奪われない」の二択で考えるのは、今すぐやめよう。問うべきは「自分の仕事の中でAIと補完関係を築けるものはどこか」だ。その問いを持って行動した人が、変化の波を乗りこなす側に立てる。 出典: この記事は The one piece of data that could actually shed light on your job and AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11がリリースされて5年近くが経とうとしているいま、Microsoftはようやく「デザイン」という問題に正面から向き合い始めた。Partner Director of DesignであるMarch Rogers氏がXで発表した内容は地味に見えるが、長年のUIの負債に手を入れようとする意思表示として受け止めるべきだ。 何が変わるのか——4月更新の具体的な内容 今回の4月更新で予告されている変更の柱は以下のとおりだ。 Settingsページの再設計: 情報が詰め込まれすぎた現行レイアウトを整理し、視認性・操作性を改善 アカウントダイアログのダークモード対応: 「その他のユーザー」追加時に表示されるダイアログが、なぜかダークモード設定を無視して白背景で表示される——誰もが一度は違和感を覚えたはずの問題が解消される ペン設定・ナレーター・音声入力の改善: ファイルエクスプローラーでのファイル名変更に音声入力が使えるようになるなど、アクセシビリティ周りの強化も含む March氏自身が「まだ多くの作業が残っている」と認めており、これはゴールではなくスタートだ。 「一貫性のなさ」という根本問題 Windows 11のUI問題の核心は、単に「見た目が古い」ことではない。一貫したUIフレームワークが存在しないことだ。Win32時代のコントロール、UWP、WinUI 3、そしてWebベースのコンポーネントが混在しており、同じOSの中に複数の「時代」が同居している。ダークモード対応のダイアログとそうでないダイアログが混在するのは、この構造的問題の症状に過ぎない。 これはアプリ開発者にも悪影響を与えている。一貫したネイティブUIフレームワークが整備されていないため、Windows向けのデスクトップアプリをElectronやWebviewベースで実装する選択を取る開発者が増えている。macOSのほうがWindows比較でずっと小さい市場シェアであるにもかかわらず、macOS向けにネイティブアプリを提供しているケースが珍しくない。 実務への影響——エンジニア・IT管理者が知っておくべきこと エンドユーザーサポートの観点: Settingsアプリのレイアウトが変わるため、社内ヘルプデスク向けのマニュアルやFAQは更新が必要になる。特にアカウント管理操作のスクリーンショットを使った手順書は要確認。 展開管理の観点: 今回の変更はWindows 11の4月オプション更新として配信される予定。Insider Previewで先行確認できるため、IT管理者はIntune/Windows Update for Businessの除外設定を活用しつつ、テスト環境での先行検証を行うことを推奨する。UIの変更は軽微でも、MDMポリシーの動作が意図通りかを確認する習慣は維持すべきだ。 開発者の観点: WinUI 3への移行が進む今、今後のWindow向けアプリ開発はWinUI 3を基準に設計するのが正しい方向性だ。Win32コントロールへの依存を減らし、テーマ対応・アクセシビリティ対応を最初から組み込む構成を検討したい。 筆者の見解 スティーブ・ジョブズが「Microsoftにはセンスがない」と言ったのは30年前だ。この言葉が今も繰り返し引用されるということは、それだけMicrosoftのデザインに対するイメージが固定されてきたということでもある。 正直に言えば、これは「もったいない」の一言に尽きる。Microsoftのマーケティング素材——製品発表のビジュアルや広告映像——を見ると、デザインセンスがないわけではないことは明らかだ。製品そのものに、そのクオリティが反映されてこなかっただけで。 今回の発表が単発で終わらないことを期待したい。Settingsアプリ一つを取っても、WinRT APIからWin32、MDMポリシーとの連携まで複雑な依存関係があり、デザインの刷新は技術的負債の整理と切り離せない。「デザインに本腰を入れる」という宣言が、組織としての優先度変更を伴うものであることを願う。 Windowsはいまもグローバルで圧倒的なデスクトップシェアを持つ。それだけの基盤とユーザーベースがあるのだから、腰を据えてUIの一貫性に取り組む余力はあるはずだ。4月の更新はその第一歩として、まずは着実に積み重ねてほしい。 出典: この記事は Microsoft says it’s finally focusing on Windows 11’s design, starting with Settings (Control Panel’s replacement) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365（M365）の更新チャネル体系が静かに、しかし確実に変わろうとしている。Microsoftはこのたび、管理外（アンマネージド）の新規デバイスに対して「Semi-Annual Enterprise Channel（半期エンタープライズチャネル）」の選択肢を廃止すると発表した。既存のデバイスへの影響はないが、これから新たにM365を展開する現場では、この変更を見落とすと思わぬ混乱を招く可能性がある。 M365の更新チャネルとは Microsoft 365 Appsには、更新頻度と安定性のバランスをコントロールするための複数の「更新チャネル」が存在する。代表的なものを整理しておこう。 チャネル名 更新頻度 主な用途 Current Channel 月複数回 最新機能を即座に使いたいユーザー Monthly Enterprise Channel 月1回（火曜日定例） 月次で安定的に更新したいエンタープライズ Semi-Annual Enterprise Channel 年2回（1月・7月） 徹底した検証が必要な大規模環境 特に「Semi-Annual Enterprise Channel（SAEC）」は、製造業や金融など、更新前に厳密な動作検証を必要とする業種・業態で長らく重宝されてきたチャネルだ。年2回しか機能更新が入らないため、安定性重視の環境では頼りになる選択肢だった。 何が変わるのか 今回の変更の核心は「管理外デバイスの新規展開時」に限定されている点だ。 既存デバイス: 影響なし。現在SAECを使っているデバイスはそのまま継続できる 新規の管理外デバイス: SAECが選択肢から消える。Current ChannelまたはMonthly Enterprise Channelのいずれかになる Intune・GPO等で管理されているデバイス: 今回の変更の対象外 「管理外（アンマネージド）」とは、MDM（Intune等）やグループポリシーによる管理が行われていない状態を指す。つまり、個人所有のPC（BYOD）や、きちんとした管理基盤が整っていない小規模環境が主な影響を受ける。 なぜこれが重要か Microsoftがこの変更に踏み切った背景には、セキュリティパッチの届きが遅いデバイスをなくしたいという意図がある。SAECは安定性に優れる反面、セキュリティ修正も年2回のサイクルに縛られてしまう側面があった（セキュリティ更新自体は月次で配信されるが、機能更新と紐付いた修正が遅延するケースがある）。 管理が行き届いていない「野良デバイス」が旧バージョンのM365 Appsを長期間使い続けるリスクを低減するという観点では、この方針は理にかなっている。 また、Microsoftとしては更新チャネルの種類を整理・簡素化し、運用コストを下げたい意図もあるだろう。チャネルの選択肢が多すぎると、エンドユーザーにとっても管理者にとっても意思決定が複雑になる。 実務への影響——日本のIT管理者が注意すべきポイント 1. 新規展開前にチャネル設計を見直す 特に中小規模の組織で「管理ツールを使わずにM365を展開している」ケースは要注意だ。これまで何となくSAECを選んでいた場合、新規PCへの展開時に同じ設定が踏襲できなくなる。 2. アンマネージド環境こそIntuneへの移行を検討する好機 逆説的ではあるが、今回の変更は「管理基盤を整えるきっかけ」として捉えられる。Intuneによる管理下に置けば、引き続きSAECを選択できる。「管理が面倒だから放置」という環境があれば、今回の変更を機に整備を進めるのが建設的だ。 3. Monthly Enterprise Channelへの移行準備 新規デバイスでSAECが使えなくなる場合、最も安定した代替はMonthly Enterprise Channelだ。月1回・定例火曜日の更新サイクルは予測可能性が高く、エンタープライズ向けとしても十分な安定性がある。更新検証のプロセスを月次サイクルに合わせて再設計しておきたい。 4. 既存デバイスの棚卸しを 今回は既存デバイスへの影響はないが、「どのデバイスがSAECで動いているか」を把握できていない環境は要注意だ。将来的なチャネル変更に備えて、今のうちに管理台帳を整備しておくべきだろう。 筆者の見解 この変更、個人的には「正しい方向への一歩」だと思っている。 管理基盤のないデバイスが半年に一度しか更新されない状態で放置されるのは、セキュリティの観点から見ると相当リスクが高い。「安定性のためにSAEC」という判断自体は理解できるのだが、それが「更新を先送りにする言い訳」として機能してしまっているケースを日本の現場でも少なくない頻度で見かける。 ただ、この変更には一つ懸念もある。「管理外デバイスを管理下に置く」という方向性は正しいのだが、それをするためのコスト・工数が日本の中小企業には決して小さくない。Intuneのライセンスコスト、設定工数、社内の理解を得るための調整——これらのハードルが高くて身動きが取れないまま、気づいたら「Current Channelで毎月バタバタ更新」という状況になるケースも出てくるだろう。 Microsoftにお願いしたいのは、こういった移行をスムーズにするためのガイダンスや、中小企業向けの移行支援を充実させることだ。変更の方向性は応援しているからこそ、ランディングをうまくやってほしいという気持ちがある。チャネル戦略を整理する力はある。あとはユーザーを連れていく伴走力の問題だ。 出典: この記事は Microsoft removes Semi-Annual Enterprise Channel option for new unmanaged M365 devices の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Solanaベースの分散型取引プラットフォーム「Drift Protocol」が2026年4月1日に受けた約2億8,000万ドル（日本円換算で約400億円超）の暗号資産窃盗事件の調査が進み、その全貌が明らかになってきた。単なるゼロデイ攻撃ではなく、半年以上にわたる周到な人間工作（ヒューマン・オペレーション）が組み合わさった、現代のサイバー攻撃の新しい教科書とも言える事案だ。 「量的取引会社」を装った6ヶ月の潜伏工作 攻撃者グループは、正規のクオンツ（量的取引）企業として偽装し、複数の国際的な暗号資産カンファレンスでDriftのコントリビューターと対面接触を繰り返した。ブロックチェーン情報企業のEllipticおよびTRM Labsの調査により、北朝鮮系のサイバー攻撃グループ「UNC4736」（AppleJeus、Labyrinth Chollimaとも呼ばれる）の関与が中高度の信頼性で示されている。 注目すべきは、カンファレンス会場で直接接触してきた人物は「非韓国系」の仲介者だったとDriftが明記している点だ。多国籍の中間者を使い、帰属追跡を困難にする手法は、同グループの典型的な手口と合致する。 対面接触後は、TelegramグループでDriftの技術仕様や取引戦略について継続的にコミュニケーションを取り、「普通のオンボーディング交渉」を演じ続けた。犯行直後にそのTelegramグループは削除されている。 開発者ツールチェーンを標的にした2つの攻撃ベクター Drift Protocolが現在調査中とする侵入経路のうち、技術的に見てとりわけ重要なのが次の2点だ。 1. 悪意あるコードリポジトリ（VSCode/Cursor脆弱性の悪用） 攻撃者はコントリビューターにコードリポジトリを共有し、VSCodeまたはCursorの脆弱性を利用してサイレント（無音）コード実行を行った可能性がある。AIコーディング支援ツールとして急速に普及したCursorが攻撃ベクターとして名指しされている点は、開発者にとって看過できない警告だ。 2. 偽TestFlightアプリ（ウォレット製品と称したiOSアプリ) AppleのTestFlightは開発者向けのベータテストプラットフォームであり、通常のApp Storeレビューを経ない。攻撃者はこれを活用し、悪意あるiOSアプリをウォレット製品として提示した。TestFlightを経由した攻撃は以前から報告されており、特に暗号資産関連コミュニティで有効な手法となっている。 SecurityCouncilの管理権限ハイジャックと12分での資産流出 侵入後、攻撃者はDriftのSecurity Council（セキュリティ評議会）の管理者権限を乗っ取り、わずか12分でユーザー資産を引き出した。現在、全機能が凍結され、侵害されたウォレットはマルチシグプロセスから除外されている。取引所やブリッジオペレーターに対して攻撃者のウォレットアドレスが共有され、資金移動の阻止が試みられている。 UNC4736は2023年の3CXサプライチェーン攻撃、2024年のRadiant暗号資産5,000万ドル窃盗、Chromeゼロデイ悪用事案など多数の大規模攻撃に関与しており、MandiantはLazarusグループとの関連性も指摘している。 実務への影響：日本のエンジニア・IT管理者が明日から取るべきアクション この事案は暗号資産業界だけの問題ではない。開発ツールチェーンと信頼関係を武器化した攻撃は、あらゆるソフトウェア開発組織に刺さる教訓を持っている。 開発環境のセキュリティ見直し VSCode/CursorなどのIDEに対する拡張機能・スクリプトの自動実行を制限する 外部から共有されたリポジトリをサンドボックス環境で開く運用ルールを策定する .vscode/settings.json や launch.json の tasks 設定を必ずレビューする習慣をつける TestFlight・ベータ配布経由のアプリへの警戒 社内外から「試してみて」と共有されるテストアプリは、必ず出所確認を行う 特に秘密鍵やシード情報を扱うウォレット系ツールは、公式ストア以外からの取得を原則禁止にする コントリビューター・管理者の権限管理 常時付与された特権アカウントをなくし、Just-In-Time（JIT）アクセスモデルに移行する 多要素認証はもちろん、Security Councilのような重要権限グループはマルチシグ構成で守る Telegramなどの非公式チャネルで技術的に機微な情報を共有しない運用ルールを徹底する カンファレンス参加時の意識 名刺を渡してきた相手がすぐにコラボ提案や「コード見せて」という流れになる場合は一度立ち止まる 特定のロールを持つ開発者は、所属・担当範囲の公開情報を最小化することも選択肢に入れてよい 筆者の見解 今回の事案が示しているのは、ゼロデイ脆弱性よりも「人の信頼」を攻撃するコストが下がっているという現実だ。6ヶ月間、複数カ国でカンファレンスに出没し、専門知識を持った人物が技術的に自然な会話を続けて侵入口を作った。このレベルの持続的な工作は、テクニカルなセキュリティ対策だけでは防ぎきれない。 特に気になるのが、VSCode/Cursorが攻撃ベクターとして挙げられていること。AIコーディングツールとして急速に普及しているエディタ環境が標的になるという構造は、開発者コミュニティ全体に対する警告だ。便利なツールが普及すれば、当然そこを狙う攻撃者も出てくる。ツールの採用と同時にそのリスクプロファイルを理解し、組織として何らかの緩和策を持つことが求められる。 日本の大手エンタープライズ環境で「外部との接触はすべて禁止」という方向に走りたくなる気持ちはわかる。だが禁止アプローチは必ず失敗する。外部リポジトリを一切cloneできない環境では開発が止まるし、TestFlightの利用を一律禁止すれば業務に支障が出る。大事なのは「安全に使える仕組みを用意する」こと。開発者が公式・安全な方法を選べる環境を作り、それが一番便利に感じる状態にすることだ。 特権アカウントの常時付与をやめ、Just-In-Timeアクセスを徹底する。これは今回の事案に限らず、あらゆる組織に適用できる原則だ。今動いているから大丈夫、という判断が一番危ない。この事案もまた、そのことを証明している。 出典: この記事は Drift $280M crypto theft linked to 6-month in-person operation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「パッチより先に来る攻撃者」という現実 Microsoftが公開したレポートは、日本のIT現場にとっても他人事では済まされない内容だ。中国を拠点とする金銭目的のサイバー犯罪グループ「Storm-1175」が、Medusaランサムウェアを用いた高速攻撃を展開しており、一部のゼロデイ脆弱性をパッチ公開の1週間前から悪用していたことが確認されている。 「パッチを当てればいい」という発想が前提にしている「パッチが先に来る」という常識が、このグループには通用しない。防御側の想定を根本から見直す必要がある。 Storm-1175の攻撃手口——速さと多様性が武器 初期侵入から被害発生まで「最短24時間」 Microsoftによれば、Storm-1175は初期アクセスを確立してからデータ窃取・ランサムウェア展開まで、数日以内、場合によっては24時間以内に完了させる。この「高い作戦テンポ」が最大の特徴だ。 攻撃チェーンは以下のように進む： 初期アクセス: ゼロデイやNデイ（既知だが未パッチ）の脆弱性を悪用して境界設備に侵入 永続化: 新規ユーザーアカウントの作成、RMM（リモート監視管理）ソフトのインストール 横展開と情報収集: 資格情報の窃取、ネットワーク内部の探索 防御の無効化: セキュリティソフトを無効化 最終目的の達成: Medusaランサムウェアの投下とデータ流出 標的にされた製品リスト 2023年以降だけで、以下を含む10製品・16以上の脆弱性が悪用されている： 製品 CVE Microsoft Exchange CVE-2023-21529 Ivanti Connect/Policy Secure CVE-2023-46805 / CVE-2024-21887 ConnectWise ScreenConnect CVE-2024-1709 / CVE-2024-1708 JetBrains TeamCity CVE-2024-27198 / CVE-2024-27199 SimpleHelp CVE-2024-57726 ほか BeyondTrust CVE-2026-1731 SmarterMail CVE-2025-52691 / CVE-2026-23760 CrushFTP CVE-2025-31161 PaperCut CVE-2023-27350 / CVE-2023-27351 GoAnywhere MFT CVE-2025-10035 注目すべきは、Microsoft Exchangeも標的製品の一つだという点だ。日本企業でオンプレミスExchangeをまだ維持しているケースは少なくなく、特に注意が必要だ。 また、BeyondTrustやSimpleHelpなどの特権アクセス管理ツールやリモート監視ツールが攻撃対象になっていることは、皮肉な構図でもある。セキュリティや運用効率化のために入れたツールが、逆に侵入経路になりうる。 医療・教育・金融が重点標的 Microsoftは最近の侵害が「医療機関」に大きな影響を与えたと強調している。CISAもFBIと共同で、Medusaグループが米国内の300以上の重要インフラ組織に被害を与えたと警告している。業種を問わず、境界に露出した資産を持つ組織はすべてターゲットになりうる。 実務への影響——日本のエンジニア・IT管理者が今すぐやるべきこと 1. インターネット公開資産の「棚卸し」を今すぐやれ Storm-1175が得意とするのは「露出した境界資産の特定」だ。攻撃者はスキャンツールで公開IPを継続的に探索しており、自組織の公開サービスが何かを把握していないことは致命的なリスクになる。Shodan的な視点で自分たちの外部からの見え方を確認する習慣をつけること。 2. RMMツールの利用実態を把握・監視する Storm-1175はScreenConnect、SimpleHelp、BeyondTrustなどのRMM/特権管理ツールを悪用している。自組織で利用しているRMMツールの認証ログ・接続元IPを定期的に監視し、未承認の接続を検知できる体制を作ること。 ...

Microsoftが長年にわたってサポート担当者やIT管理者に愛用されてきた診断ツール「Microsoft Support and Recovery Assistant（SaRA）」のコマンドライン版を、2026年3月10日以降の全Windowsアップデートから削除した。理由は「環境のセキュリティ強化とハードニング」。後継として推奨されているのは「Get Help」コマンドラインツール（GetHelpCmd.exe）だ。 SaRAとは何だったのか SaRAは、Office・Microsoft 365・Outlook・Windowsに関するよくある問題を自動診断・修復するフリーツールだ。Windows 7から11まで幅広く対応しており、IT管理者がPowerShellスクリプト経由でリモート実行するユースケースでも広く使われてきた。根本原因を特定して自動修復するか、手順ガイドを提示するか、Microsoftサポートへの連絡を支援するか——この3択で問題解決を導く設計は、ヘルプデスク業務の効率化に大きく貢献してきた。 後継ツール「Get Help」は何が違うのか Microsoftが提示した後継ツール「Get Help」は、機能面ではSaRAとほぼ同等だ。Microsoft 365アプリ（OutlookやTeams）の診断、コマンドライン実行、PowerShellからのリモート実行——いずれも対応している。 最大の違いはインフラのセキュリティ強度。Microsoftによれば、Get Helpを支えるバックエンド基盤はSaRAのものよりセキュリティが強化されているという。具体的な技術詳細は公開されていないが、診断ツール自体がセキュリティ上の弱点になりうるという認識の下、インフラを刷新したと読める。 移行手順はシンプルで、GetHelpCmd.exeをダウンロードして実行するだけ。ただし、既存のスクリプトやRMMツールからSaraCmdLine.exeを呼び出している場合は、GetHelpCmdLine.exeへの差し替えが必要になる。 実務への影響 影響を受ける可能性があるケース SaRAのコマンドライン版をPowerShellスクリプトやRMMツールから呼び出している環境 ヘルプデスク手順書にSaraCmdLine.exeの実行手順が記載されている場合 MDMやGroup Policyで配布・実行を管理している場合 移行時の確認ポイント 既存スクリプトの棚卸し — SaraCmdLine や SaRACmd で社内スクリプトを検索し、使用箇所を洗い出す GetHelpCmd.exeの動作確認 — 差し替え後に同等の診断シナリオが再現できるかテストする 手順書・ドキュメントの更新 — ヘルプデスクやサポート担当向けの運用手順書を更新する エンドユーザー向けGUIのSaRAは別物 — 今回廃止されたのはコマンドライン版。GUIのSaRAアプリについては別途確認が必要 筆者の見解 今回の廃止は、セキュリティ強化という観点からは正しい判断だと思う。診断ツールはシステムの深部にアクセスする性質上、そのインフラ自体が攻撃対象になりうる。「動いているから大丈夫」を理由に古い実装を維持し続けることの方が、長い目で見てリスクだ。 ただ、IT管理者の立場から見ると、また一つ「使い慣れたツールが変わる」対応が増えたのも事実だ。SaRA以外にも、Publisher廃止・Lens廃止・Authenticatorのパスワード自動入力廃止と、最近のMicrosoftは廃止ラッシュが続いている。個々の判断には理由があるにせよ、現場の運用担当者が追いつくのが大変になっている現実も見ておきたい。 移行先のGet Helpが、SaRAと同じくらい現場で信頼されるツールに育つかどうか——それはMicrosoftのインフラ品質と、ドキュメント整備の速度にかかっている。セキュリティを強化したバックエンドで動くなら、診断の精度も上がることを期待したい。「セキュリティのために刷新した」という言葉が、実際の改善として実感できるツールになることを願っている。 今動いているSaRAのスクリプトは早めにGet Helpへ移行を。3月10日以降のWindowsアップデートを適用済みの環境では、すでにSaRAが機能しなくなっている可能性がある。 出典: この記事は Microsoft removes Support and Recovery Assistant from Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

未パッチのWindows権限昇格脆弱性「BlueHammer」のエクスプロイトコードが、Microsoftのセキュリティ対応に不満を持つ研究者によって公開された。現時点で公式パッチは存在せず、攻撃者がSYSTEM権限を取得できる状態が続いている。脆弱性の深刻さもさることながら、開示プロセスをめぐる研究者とMicrosoftの対立という構造的な問題を改めて浮き彫りにした事案だ。 BlueHammerとは何か——技術的な詳細 BlueHammerはローカル権限昇格（LPE: Local Privilege Escalation）の脆弱性で、「TOCTOU（Time-of-Check to Time-of-Use）」と「パス混同（Path Confusion）」という2つの手法を組み合わせて悪用する。 TOCTOUとは、リソースの状態を「確認するタイミング」と「実際に使用するタイミング」の間にずれが生じることを突く古典的な競合状態攻撃だ。BlueHammerはこれにパス混同を組み合わせることで、WindowsのSAM（Security Account Manager）データベースへの読み取りアクセスを得る。SAMにはローカルアカウントのパスワードハッシュが格納されており、これを取得できればSYSTEM権限へのエスカレーションが現実のものとなる。 脆弱性の検証を行ったセキュリティ研究者のWill Dormann氏によれば、「エクスプロイトが成功すれば、攻撃者はSYSTEM権限のシェルを起動するなど、システムを事実上完全に制御できる」という。ただし、公開されたPoCコードにはバグが含まれており、動作が安定しないケースもある。Windows Serverでは完全なSYSTEM奪取ではなく、非管理者から昇格管理者への権限昇格にとどまる挙動も確認されている。 開示の経緯——研究者対MSRCの構図 「Chaotic Eclipse」「Nightmare-Eclipse」というアカウント名を使う研究者は、BlueHammerをMicrosoftに対してプライベートに報告していた。しかしMicrosoftのセキュリティ対応部門（MSRC）の対応に強い不満を抱き、2026年4月3日にGitHubでエクスプロイトコードを公開した。 公開時のコメントには「Microsoftに対してハッタリをかましているわけではない。また同じことをやる」「MSRC幹部に感謝する、こうなることを可能にしてくれた」という皮肉が込められていた。 背景として注目すべきは、MSRCが脆弱性報告の際に「エクスプロイトの動画提供」を要件としている点だ。研究者側からすれば、再現動画の作成は相応の労力を要する。このプロセスへの不満が積み重なった可能性が高い。責任ある開示（Responsible Disclosure）の精神に反する行為である一方で、報告コストの高さという制度的な問題を提起している側面もある。 実務への影響——ローカルアクセスを過小評価するな 「ローカル攻撃者が必要」という条件から、リスクを低く見る向きもあるかもしれない。しかしこの見方は危険だ。 ソーシャルエンジニアリング、メールの添付ファイル、他ソフトウェアの脆弱性、認証情報の窃取——いずれもローカルコードの実行を得るための現実的な経路だ。BlueHammerが刺さるのは、初期侵害に成功した後の「横展開・権限昇格フェーズ」だが、実際の攻撃チェーンではここが最も重要なステップになることが多い。 IT管理者が明日から取れる対策として、以下を検討したい： 最小権限の原則を徹底する: 標準ユーザー権限での業務を原則とし、管理者権限の常時付与を避ける。Just-In-Time（JIT）アクセスの仕組みが理想的だ SAMデータベースへのアクセス監視を強化する: 異常なSAMアクセスをSIEMやMDEで検出できるよう、検出ルールを見直す エンドポイント検出・応答（EDR）の精度を確認する: PoCコードはすでに公開されており、シグネチャが更新されつつある。EDRが最新状態であることを確認する Windowsのパッチ状況を継続監視する: 今後のPatch Tuesdayで修正が提供される可能性が高い。適用可否の判断体制を整えておく 筆者の見解 BlueHammerの技術的な内容そのものは、古典的な手法の組み合わせという意味で「目新しさ」はそれほど高くない。TOCTOU攻撃は十数年前から知られており、SAMデータベースを狙う手法も確立された攻撃パターンだ。 むしろ今回の件で考えさせられるのは、MSRCの開示プロセス設計の問題だ。エクスプロイト動画の提供を義務付けることで、善意の研究者に不必要な負担を強いている面がある。セキュリティ研究者のコミュニティから優秀な人材を遠ざけることになれば、長期的にMicrosoft自身にとって損失だ。 Microsoftにはセキュリティに本気で投資できるリソースがある。Secure Future Initiative（SFI）を掲げ、組織全体のセキュリティ文化変革に取り組もうとしているのは知っている。だからこそ、研究者との関係構築という「人の問題」でつまずいているのはもったいないと感じる。研究者コミュニティを味方につければ、脆弱性情報の流れ方が変わる。 パッチが出るまでの間、ユーザーとしてできることはSAMアクセス監視の強化とEDRの最新化程度だが、それを徹底するだけでもリスクは下げられる。公式修正を待ちながら、自組織の権限管理の棚卸しをするよい機会として捉えてほしい。 出典: この記事は Disgruntled researcher leaks “BlueHammer” Windows zero-day exploit の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントとツール連携の標準規格として急速に普及しつつある MCP（Model Context Protocol）。そのMCPサーバーをAzure Functions上で構築・デプロイするための公式クイックスタートが、TypeScript向けに公開された。単なるサンプルにとどまらず、エンタープライズ向けのOAuth認証やインフラコード（Bicep）まで一式揃っており、本番投入を意識した構成になっている点が注目に値する。 MCPとは何か、なぜ今注目されているのか MCPは、AIエージェント（LLMホスト）がバックエンドのツールやリソースへ標準化された方法でアクセスするためのプロトコルだ。REST APIに例えるなら「AIエージェント専用のOpenAPI仕様」とも言える。Visual Studio Code Copilot・Claude・ChatGPTといった主要なAIホストがすでに対応しており、一度MCPサーバーを作れば複数のAIクライアントから利用できる汎用性がある。 さらに今回のアップデートで注目したいのが MCP Apps という概念だ。従来のMCPがテキストベースのデータ返却に限られていたのに対し、MCP AppsではインタラクティブなHTML/JSウィジェットをAIホストのUI内に直接レンダリングできる。地図・グラフ・承認フォーム・リアルタイムダッシュボードなど、これまでチャットUIの制約上実現できなかったリッチな体験が可能になる。 Azure Functionsがもたらす3つの価値 1. プロトコル実装の複雑さを隠蔽する MCPプロトコルを自前で実装しようとすると、SSE（Server-Sent Events）の管理やJSON-RPCのフォーマット、セッション管理など覚えることが多い。Azure Functionsではapp.mcpTool()という1つの関数呼び出しでツール定義が完結する。ハンドラーを書けばプロトコルの詳細は自動で処理される。 出典: この記事は MCP Apps on Azure Functions: Quickstart with TypeScript の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure SDK for JavaScript が、2026年7月9日をもって Node.js 20.x のサポートを終了することを正式に発表した。Node.js 20.x 自体のEOL（End of Life）が2026年4月30日に到来することを受けた対応であり、Azure SDK を利用している JavaScript / TypeScript プロジェクトは、それ以前に Node.js 22.x 以降への移行を完了させる必要がある。 Node.js のリリーススケジュールとサポートポリシー Node.js は偶数バージョンのみが LTS（Long Term Support）対象となるリリースモデルを採用している。各 LTS バージョンは「Active LTS」→「Maintenance LTS」→「End-of-Life」という段階を経て廃止される。 現在のバージョン別ステータスは以下の通りだ。 バージョン ステータス EOL 20.x Maintenance LTS → EOL 2026年4月30日 22.x Active LTS 2027年4月30日 24.x 2025年後半リリース予定 — Azure SDK チームは、Maintenance フェーズを終えた Node.js バージョンについてはサポートから順次除外する方針を明確にしている。重要なのは、メジャーバージョンを上げることなく（破壊的変更なしに）このサポート除外を行えるという点だ。つまり、SDK の利用者が気づかないまま状況が変わる可能性がある。 2026年7月9日に何が起きるか 当日以降にリリースされる Azure SDK for JavaScript の各ライブラリは、package.json の engines フィールドに node: >=22.x を指定するようになる。 実際の影響は npm の設定によって異なる。 ...

Microsoftが公開した最新の「Digital Defense Report」に、見過ごせない数字が載っている。IDへの攻撃の97%は、パスワードスプレーによるものだ。 高度な解析ツールや量子コンピューターではない。ごく単純な手法——多数のアカウントに対し、ありがちなパスワードを少しずつ試し続けるだけ——が、現代のほぼすべてのID侵害を引き起こしている。これは、多くの現場が信じている「複雑なパスワードルールを設定すれば守られる」という前提そのものへの反証だ。 パスワードスプレー攻撃とは何か パスワードスプレーは、ブルートフォース攻撃の進化系だ。従来型のブルートフォースは「1つのアカウントに大量のパスワードを試す」ため、アカウントロックアウトで検知・ブロックされやすかった。これに対しスプレー攻撃は発想を逆転させる。 「多数のアカウントに対し、1〜3種類だけパスワードを試す」 たとえば Welcome2024! や Spring2026@ のような「複雑性要件を満たしつつ誰もが思いつく」文字列を、数千〜数万のアカウントに1回ずつ試すだけだ。ロックアウトのしきい値に引っかからず、ログ上でも「散発的な認証失敗」に見えるため、従来の監視体制では素通りしてしまう。 LinkedInや過去のデータ侵害から入手した実在のユーザー名リストと、「よく使われるパスワードTOP100」を組み合わせるだけで成立する、参入障壁の低い攻撃手法でもある。 従来のADパスワードポリシーが機能しない理由 Active Directoryの既定のパスワードポリシーは、こうした攻撃を想定して設計されていない。最小文字数・複雑性要件・有効期限・パスワード履歴——これらはすべて「ブルートフォース対策」や「内部からの単純な推測」を念頭に置いた設計だ。 問題は何を守れないかにある。 既知の侵害パスワードのチェック機能がない: Password1! は複雑性を満たすが、すでに数百万件の侵害リストに存在する スプレーパターンの横断検知ができない: ADは「このアカウントが何回失敗したか」は見るが、「組織全体で同じパスワードが何アカウントに試されたか」は見ない コンテキスト（場所・デバイス・時間帯）を考慮しない: 深夜に海外IPからのアクセスでも、パスワードが正しければ通ってしまう つまり、複雑なルールを設けてもスプレー攻撃には無力という構造的な問題がある。 管理者が今すぐ導入すべき対策 1. Microsoft Entra Password Protection オンプレミスのADにも展開できるMicrosoftの仕組みで、Microsoftが管理するグローバルの禁止パスワードリストと、組織独自のカスタム禁止リストを組み合わせてパスワード設定時点でブロックできる。「複雑なのに侵害済み」というパスワードを排除する最初のラインだ。 2. MFA（多要素認証）の全員展開 パスワードが漏れた前提で考える。Microsoft Authenticatorのプッシュ通知 + 番号一致（Number Matching）を有効化すれば、正しいパスワードを持っていても突破できない壁になる。「管理者だけMFA」は今や論外で、全ユーザーが対象だ。 3. Conditional Access（条件付きアクセス）による文脈評価 IP・デバイス・場所・サインインリスクスコアを組み合わせてアクセスを制御する。Entra ID Protectionのリスクベースポリシーと組み合わせれば、スプレー攻撃で正しいパスワードを入力された瞬間に「高リスクサインイン」として検知し、MFAを強制または遮断できる。 4. 特権アカウントへのJust-In-Time（JIT）アクセス ドメイン管理者やグローバル管理者の権限を「常時付与」している組織はまだ多い。常時付与は特権アカウント管理における最大のリスクだ。Microsoft Entra Privileged Identity Management（PIM）を使えば、必要なときだけ、承認ベースで一時的に昇格できる仕組みを作れる。攻撃者がパスワードを入手しても、権限が無効化された状態であれば実害は大幅に限定される。 5. パスワードレス認証への移行 根本的な解決策はパスワードをなくすことだ。FIDO2セキュリティキーやWindows Hello for Businessは、パスワード自体が存在しないためスプレー攻撃の対象にならない。段階的に高リスクユーザー（管理者・リモート接続ユーザー）から展開を始めるのが現実的だ。 日本のIT現場への影響 日本の大企業・中堅企業のオンプレAD環境では、グループポリシーによるパスワードポリシーを「セキュリティ対策済みの証拠」として扱っている現場が今でも少なくない。Entra IDへのハイブリッド移行途上で、認証周りの設定が中途半端なまま止まっているケースも多い。 「今まで大きな事故がなかった」は、「今まで攻撃者に見つかっていなかっただけ」の可能性が高い。侵害の多くは侵入から数ヶ月後に発覚する。 筆者の見解 セキュリティ全般は決して得意分野とは言えないが、認証・認可の設計には技術的な面白さを強く感じる領域でもある。 今回の「97%がパスワードスプレー」という数字は、正直に言って驚きではない。洗練された攻撃より、「普通の人が使いそうなパスワードを片っ端から試す」だけで9割以上が決まってしまうというのは、むしろ現在のID管理のあり方への問いかけだ。 MicrosoftはEntra IDにパスワードスプレー対策のための技術を揃えている。Password Protection、Entra ID Protection、Conditional Access、PIM——これらは単体ではなく組み合わせて使って初めて意味を持つ。M365やEntra IDを使いながら、パスワードポリシーだけ昔のままという状態は、道具を持っているのに使っていないのと同じだ。 ...

大規模言語モデル（LLM）というと、数千億パラメータ・数百億円のコスト・謎めいたアーキテクチャ——そんなイメージを持つエンジニアは多い。しかし「それは思い込みだ」と静かに示す教育プロジェクトが、Hacker Newsで425ポイントを集めて話題になっている。その名もGuppyLM——金魚のような小さなLLMだ。 GuppyLMとは何か GuppyLMは、約870万（8.7M）パラメータのトランスフォーマーモデルをゼロから実装したオープンソースの教育プロジェクトだ。学習データは6万件の合成会話、PyTorchのコードはわずか約130行。Google ColabのT4 GPU（無料枠）でわずか5分で学習が完了する。 生成されるのは「グッピー（熱帯魚）」というキャラクターの会話で、水温・えさ・泡などの話題で小さく応答する。これは意図的な設計で、「人間の抽象概念を理解しないモデル」という制約のなかで、トークナイザから学習ループ、推論まですべての仕組みが透明に見えるようになっている。 アーキテクチャの「飾らなさ」が価値 モデルの仕様はシンプルの一言に尽きる。 項目 値 パラメータ数 8.7M レイヤー数 6 隠れ次元 384 アテンションヘッド 6 語彙サイズ 4,096（BPE） 最大シーケンス長 128トークン GQA（Grouped-Query Attention）もRoPE（Rotary Positional Embedding）もSwiGLUも使わない。バニラトランスフォーマーそのままだ。GPT-4やClaudeが内部で使うような最適化技術は一切ない。 この「飾らなさ」こそが意図的なポイントで、最新技術のノイズを排除して「トランスフォーマーの本質的な動作」だけを学べる設計になっている。 60トピックの合成データセットで個性を作る 学習データはHuggingFaceで公開されているarman-bd/guppylm-60k-generic。挨拶・感情・温度・食べ物・光・水・孤独・夢・人生の意味など60カテゴリ、6万件の合成会話が含まれる。 データの形式は {"input": "...", "output": "...", "category": "..."} とシンプルで、自前のキャラクター設定に差し替えれば自分だけの「個性あるミニLLM」をほぼ同じ手順で作れる。 プロジェクト構造も明快だ。config.py（ハイパーパラメータ）、model.py（トランスフォーマー本体）、dataset.py（データローディング）、train.py（学習ループ）、generate_data.py（会話データ生成）に綺麗に分割されており、どのファイルがどの役割を担うか一目でわかる。 実務への影響——なぜエンジニアはLLMの内部を知るべきか LLMをAPIとしてのみ使うエンジニアにとって、内部構造の理解は「趣味の話」に見えるかもしれない。しかし実際には、構造への理解がプロンプト設計の質を根本的に変える。 たとえばコンテキストウィンドウの制約、トークン化の落とし穴、温度パラメータの意味、ファインチューニングと数ショット学習の使い分け——これらはモデルがどう動くかを知らないと、「なんとなく試行錯誤」から抜け出せない。 GuppyLMを手元で動かすことで得られる実践的なヒントをまとめる。 トークナイザを自分で実装する体験: BPE（Byte Pair Encoding）の動作を自力で追うと、なぜ日本語トークン数が英語より多くなりやすいかが腑に落ちる 学習ループの全体像を把握する: コサイン学習率スケジューリングやAMP（自動混合精度）の意味がコードレベルで見える 「どこで何が決まるか」を知る: ハイパーパラメータを変えてすぐに再学習できるため、感覚ではなくデータで設計判断できるようになる ファインチューニングの入門台として最適: 自社データで試したいが大規模モデルは難しい——という場合に、GuppyLMで手順を先に身につけると実際の作業がスムーズになる 筆者の見解 「LLMは魔法じゃない」——この一言に尽きると思っている。 AIエージェントや自律ループを設計する立場から言えば、モデルの挙動を予測できるかどうかは実装の品質に直結する。ブラックボックスとして扱い続ける限り、想定外の出力への対処は「プロンプトをいじる」という勘頼みになりがちだ。 GuppyLMのような小さなプロジェクトを一度手で動かすと、トークン化・アテンション・サンプリングのそれぞれが何を担っているかが体で理解できる。その感覚は、大規模モデルのAPIを呼ぶときも確実に活きる。 日本のIT現場では「とりあえずAPIを叩いてみる」層と「論文を読み込む」層に二極化しがちだが、GuppyLMはその間を埋める絶好の入口だ。5分で動くモデルを1本手元で作ったことがある人とそうでない人では、AI技術の議論の解像度が明らかに違ってくる。 情報を追い続けることよりも、一度手を動かして自分の感覚を作る——そのコストが「Colabで5分」まで下がったことの意義は、思っている以上に大きい。 出典: この記事は Show HN: I built a tiny LLM to demystify how language models work の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Linuxカーネルの開発を率いるLinus Torvalds氏が、Linux 7.0の正式リリースが来週に迫っていることを自ら確認した。開発サイクルは例年より長引き、一時は遅延も懸念されたが、最終的に予定通りのスケジュールで着地することになった。メジャーバージョンの番号が繰り上がるという節目のリリースとして、Linuxを支えるサーバー・クラウドインフラ全体に影響が及ぶ。 バージョン7.0に至るまで——なぜ「波乱含み」だったのか Linuxのメジャーバージョンアップは純粋な技術上の必要性ではなく、リリース候補（RC）サイクルの収束具合とLinus氏の判断による。今回の7.0は通常より多くのRC版を重ねた。これはカーネルコードの変更量そのものが通常よりも大きく、ドライバーや新ハードウェアサポートを含む変更のマージが増えた結果だ。 「バンプが大きい＝品質が低い」ではない。むしろ開発コミュニティが妥協せず、十分な検証を繰り返したことの証でもある。最終的に来週のリリースに向けてGo判断が出たということは、品質水準を満たしたとLinus氏が判断したことを意味する。 技術的な注目ポイント ハードウェアサポートの大幅拡充 今回のリリースサイズが「例年よりも大きい」とされる主な要因の一つが、ハードウェアサポートの拡充だ。最新世代のCPU・GPU・NICに向けたドライバー更新が含まれており、特にデータセンター向けのネットワークハードウェアやAIアクセラレーター対応が強化されている。クラウドプロバイダーやオンプレミスのサーバー運用担当者にとっては、新規ハードウェア導入の際の互換性検証作業が減ることが期待できる。 セキュリティ関連の改善 カーネルレベルのセキュリティ強化も毎リリースの定番だが、7.0ではメモリ安全性周りの改善やアクセス制御の精緻化が含まれているとされる。ゼロトラスト前提の環境では「カーネルが攻撃面を最小化していること」が前提条件となるため、こうした継続的な改善の積み重ねは見過ごせない。 開発ツールチェーンとの連携強化 モダンな開発環境・CI/CDパイプラインとの親和性向上も進んでいる。コンテナ・Kubernetes環境での動作最適化を含む変更が取り込まれており、DevOpsワークフロー全体に恩恵が波及する。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと アップデートの判断は「リリース直後」に焦らなくてよい。 Linuxカーネルのアップグレードは各ディストリビューション（RHEL、Ubuntu、Debian等）へのバックポートや取り込みを経て実際に現場に届く。7.0カーネルそのものをすぐ本番適用するケースは限られており、まずはディストリビューションの対応状況と自社ハードウェアの互換情報を確認するのが正しい手順だ。 新規ハードウェア導入検討のタイミングとして活用する。 最新世代のサーバーやネットワーク機器を検討している場合、7.0でのドライバーサポート状況は重要な判断材料になる。購買プロセスが長い日本の大企業こそ、今から情報収集を始めておく価値がある。 CI/CDとコンテナ環境の動作検証を早めに。 7.0ベースのイメージがクラウドプロバイダーから提供されるタイミングで、既存パイプラインへの影響を確認しておくことを推奨する。特にカーネルパラメータや名前空間・cgroup周りに変更がある場合、コンテナ運用に予期せぬ影響が出ることがある。 筆者の見解 Linux 7.0という数字は、純粋にエンジニアリング上の必要性から生まれたものではない。しかしそれがコミュニティの蓄積を可視化するマイルストーンとして機能していることは確かだ。 個人的に注目しているのは「開発サイクルが波乱含みだったにもかかわらず、最終的に粛々と収束した」という点だ。大規模なオープンソースプロジェクトがこれほど安定した意思決定プロセスを維持していること自体、現代のソフトウェア開発が学べる手本の一つだと思う。 日本のITインフラにおいてLinuxは「あって当たり前」のものになっているが、その当たり前を支えている継続的な開発努力に、現場のエンジニアが改めて目を向けるきっかけになれば、このリリースには十分な意義がある。情報を追いかけることよりも、実際に自分の環境で動かし、変化を体感することが今のエンジニアに必要なアクションだと考えている。 出典: この記事は Linus Torvalds confirms Linux 7.0 is on track for final release next week の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ubuntu 26.04 LTS（2026年4月リリース予定）で、10年間のセキュリティアップデートをインストール直後のセットアップ画面から有効化できる仕組みが導入される。地味な改善に見えて、セキュリティ運用の実態に刺さる変化だ。 Ubuntu Proと「10年サポート」の仕組み Ubuntu LTSの標準サポートは5年間。しかしUbuntu Proサブスクリプションを有効化すると、Extended Security Maintenance（ESM）によりさらに5年間延長され、合計10年のセキュリティパッチが提供される。個人・小規模利用なら最大5台まで無料で利用可能だ。 これまでは、Ubuntu Proを有効化するにはpro attachコマンドを実行するか、Webブラウザでトークンを取得する手順が必要で、インストール後に別途作業が発生していた。 Ubuntu 26.04 LTSでは、この手続きがGNOMEの初回セットアップウィザード「Welcomeツール」に統合された。個人ユーザーはメールアドレスを入力するだけ、エンタープライズユーザーはProトークンを入力することで、デスクトップを使い始める前から10年サポートが有効な状態を作れる。 なぜこれが重要か 10年というサポート期間は、Windows Serverのライフサイクルと比較しても見劣りしない。Windows Server 2022の延長サポートが2031年まで、Ubuntu 26.04 LTSのESMが2036年まで——数字だけ見ればLinux LTSの方が長い。 特にオンプレミスサーバー・産業用システム・組み込みLinux環境を運用している日本企業にとって、OSのメジャーバージョンアップに伴うリグレッションリスクや動作検証コストは現実的な経営課題だ。長期サポートを最初から確実に有効化しておくことは、そのコストを直接抑える手段になる。 また、ゼロトラストアーキテクチャを推進する文脈でも意味がある。条件付きアクセスやエンドポイント検疫の前提として「デバイスが最新パッチ状態にあること」は欠かせない要件だ。パッチ未適用のエンドポイントを信頼できるデバイスとして扱うことはできない。 実務での活用ポイント 個人・スタートアップ向け Ubuntu Proの個人ライセンスは最大5台まで無料。開発マシンやホームサーバーにUbuntu 26.04 LTSを使うなら、Welcomeツールで最初にUbuntu Proを有効化しておくべきだ。後から「あのパッケージにESMのパッチが当たっていなかった」という事態を防げる。 エンタープライズ・大規模展開向け Ansibleやキックスタートによる自動インストール環境では初回GUIセットアップを通らないケースが多い。その場合もubuntu pro attachコマンドやcloud-initとの統合で対応できるため、Welcomeツールへの統合はあくまで「敷居を下げる」施策と捉えると良い。LandscapeやMDM連携での集中管理を検討しているチームは、Ubuntu Pro Enterpriseでのデバイス管理フローを整備するタイミングかもしれない。 EOSになったバージョンを使い続けているケース 日本のインフラ現場でまだ18.04や20.04が稼働しているケースは珍しくない。今回の変更とは直接関係ないが、Ubuntu ProのESMは古いバージョンにも（有料で）提供されており、完全移行前のつなぎとして活用する選択肢もある。 筆者の見解 「今動いているから大丈夫」——この感覚が日本のITインフラに根強く残っている。しかし、サポート切れのOSは脆弱性の温床であり、ゼロトラスト推進においてパッチ未適用のエンドポイントは「信頼できないデバイス」として扱わざるを得ない。どれほど優れた認証基盤を整えても、エンドポイントが穴だらけでは全体防御が崩れる。 Ubuntu Proの10年サポートを初回セットアップ画面から有効化できるという今回の改善は、地味ではあるが方向性として正しい。技術的に高度なことではないが、「知らなかった」「手続きが面倒だった」という理由でサポートを有効化していないユーザーを確実に減らす効果がある。 セキュリティを高める最良の方法は、セキュアな選択肢を最も便利な選択肢にすることだ。禁止や強制ではなく、自然な導線で安全な状態に誘導するこの設計思想は、どのプラットフォームも見習う価値がある。UXの改善がセキュリティの改善につながる——Canonicalの今回の取り組みはその実例として評価できる。 Linuxのサーバーシェアが着実に拡大する中、こうした「運用しやすくてセキュアな基盤」への投資が、エンタープライズでの採用をさらに後押ししていくだろう。 出典: この記事は Ubuntu 26.04 LTS makes it even easier to enable 10 years of security updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIの覇権争いが新局面へ——DeepSeek V4が4月末に登場 「DeepSeekは以前からすごかったけど、今回は話の規模が違う」——そう感じさせるニュースが飛び込んできた。中国のAIラボ・DeepSeekが開発中の次世代モデル V4 が、2026年4月末に正式リリースされる見通しだ。Reuters（4月4日付）が確認した情報によれば、このモデルはNVIDIAではなく Huawei製Ascend 950PRチップ上で動作する。フロンティア級のAIモデルが、中国製半導体インフラのみで成立する——これは業界にとって明確な転換点だ。 V4のスペックを整理する 項目 詳細 パラメータ数 約1兆（MoEアーキテクチャ） 実際に動くパラメータ数 約370億（トークンごと） コンテキスト長 100万トークン マルチモーダル テキスト＋画像＋動画（ネイティブ対応） 訓練コスト 約520万ドル ライセンス Apache 2.0（オープンウェイト予定） 動作ハードウェア Huawei Ascend 950PR ＋ Cambricon MoE（Mixture of Experts）の賢さ 1兆パラメータという数字は壮大だが、実際には1レスポンスあたり約370億パラメータしか稼働しない。これが Mixture of Experts（MoE） の本質で、「必要な専門家だけを呼び出す」仕組みだ。総知識量は1兆パラメータ相当を保ちながら、処理は370億クラスのモデルと同等の速度・コストで動く。この設計思想によって、V4-Lite（軽量版）の初期テストでは推論速度が30%向上し、128Kトークンでのコンテキスト再現率が45%→94%に劇的に改善したと報告されている。 Huaweiチップが意味すること——ここが本当の核心 GPT-5もClaudeもGeminiも、すべてNVIDIA GPUで動いている。それが世界の「当たり前」だった。 DeepSeek V4はその前提を崩す。Huawei Ascend 950PRは、米国の輸出規制によってNVIDIA製品を調達できない中国企業が本気で育てた半導体だ。DeepSeekはNVIDIAへのV4早期アクセスを意図的に与えず、中国チップメーカーに独占的な開発期間を提供した。Alibaba・ByteDance・Tencentが数十万台規模でAscend 950PRを発注し、価格は数週間で20%上昇したという。 「NVIDIA依存のAI産業」という構造が、少なくとも中国国内においては変わりつつある。これは単なるモデルリリースではなく、AIインフラの地政学的再編の始まりだ。 520万ドルの訓練コストが示す非常識な効率 GPT-4の訓練コストは推定1億ドル超、主要モデルが数千万〜数億ドルを費やすなか、DeepSeek V4の520万ドルは文字通り桁が違う。2025年1月のDeepSeek R1登場時に「訓練効率の革命」と騒がれたが、V4はその延長線上にある。 オープンウェイト（Apache 2.0）での公開が予定されているため、企業は自社インフラ上で動かすことも、APIとして使うことも選べる。APIの参考価格はインプット100万トークンあたり0.30ドルという情報も出ており、主要クローズドモデルと比較してコスト競争力は非常に高い。 実務への影響——日本のエンジニアとIT管理者が今考えるべきこと 1. オープンウェイトモデルの選択肢として真剣に検討を Apache 2.0ライセンスであれば商用利用も改変も自由だ。「クラウドAPIのコストが高い」「データをベンダーに預けたくない」という要件がある企業にとって、V4はLlama系モデルに並ぶ有力候補になりうる。ただし動作確認ハードウェアの多くがHuawei製チップであり、自社オンプレ環境での動作検証は別途必要になる点は見落とさないこと。 2. 100万トークンのコンテキスト長を活かした設計を 100万トークンのコンテキストが実用レベルで機能するなら、長大なドキュメント・コードベース・会話履歴をすべて一括で渡せる。RAG（Retrieval-Augmented Generation）の構成すら不要になるシナリオが現実味を帯びる。今の設計がV4リリース後に通用するか、一度見直しておく価値はある。 3. ベンダーロックインの分散を 特定ベンダーのAPIのみに依存したシステムを本番で動かしている場合、今のうちにモデル切り替え可能なアーキテクチャへの移行を検討したい。V4の登場でモデル選択の幅が広がることは確実であり、切り替えコストが低い設計は長期的な競争力になる。 筆者の見解 正直に言えば、DeepSeekの登場シリーズには毎回「また来たか」と驚かされている。R1で「安く作れる」を証明し、V3で「使える」を示し、V4では「NVIDIAなしでも動く」を確立しようとしている。これは技術的な快挙ではあるが、それ以上に産業構造への問いだと思っている。 米国の半導体規制がここまでの逆境設計を中国に強いた結果、NVIDIA依存を断ち切ったフロンティアモデルが生まれた——というのは、規制の設計者が想定していなかった結末だろう。禁じ手にすることで、禁じ手を必要としない技術が育つ。これは技術規制の難しさを教えてくれる事例として、今後も引用されることになる。 日本のIT現場でより気になるのは、オープンウェイトでの公開だ。多くの日本企業がまだ「生成AIはSaaSで使うもの」という感覚でいるが、コスト・データ主権・カスタマイズ性を真剣に考えると、オープンウェイトモデルを自前インフラで動かす選択肢はもっと真剣に検討されていい。V4の登場はその議論を加速させるはずだ。 モデルそのものを追いかけるよりも、どう使い倒すかの仕組みを先に持っている人が有利という構図は変わらない。4月末リリースが本当に来るなら、ベンチマークを眺めるのは一瞬で済ませて、すぐに手を動かしてほしい。 出典: この記事は DeepSeek V4: Release Date, Specs, and the Huawei Chip Bombshell の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月のPatch Tuesdayが、例年以上に緊張感の高い状況で迎えられようとしている。3月に連続した品質問題、そして2011年に発行されたSecure Boot証明書の失効まで残り73日という現実が重なり、IT管理者は「速やかに適用する」と「壊れるリスクを避ける」という二律背反をこれまで以上に意識しなければならない。 3月の「前科」を忘れてはいけない 2026年3月のPatch Tuesdayは記録的な品質問題を残した。KB5079391が公開24時間以内に取り下げられ、Error 0x80073712が多発。その後の緊急帯外パッチでも、Bluetoothの切断やRemote Desktopのループ再起動、Microsoftアカウントのサインイン障害と、負の連鎖が続いた。 こうした状況を踏まえると、「パッチが出たら即適用」という従来のセオリーを少し立ち止まって考え直す必要がある。数日間、先行する企業のフィードバックを確認してから動く——これもれっきとしたセキュリティ判断だ。ただし「遅らせる=安全」ではない。あくまでリスクの比較判断として行う姿勢が求められる。 2026年Q1の脆弱性トレンド：ゼロデイが常態化 1〜3月の累計を振り返ると、攻撃者の動きが明らかに変化していることがわかる。 1月：CVE 112件（うち3件ゼロデイ、8件クリティカル） 2月：CVE 59件（うち6件ゼロデイ——過去最多水準） 3月：CVE 83件（うちOfficeクリティカル3件） ゼロデイの件数が増えているということは、パッチが公開される前から実際の攻撃が始まっているケースが増えているということだ。「パッチが出てから考える」では間に合わないシナリオが現実のものになりつつある。脆弱性情報の一次ソース（MSRC: Microsoft Security Response Center）を定期的に確認し、重大度と攻撃状況の組み合わせで優先度を自分たちで判断する運用体制が不可欠だ。 最大の時限爆弾：Secure Boot証明書の失効 今回の最重要トピックはここだ。2011年に発行された以下のSecure Boot関連証明書が、2026年6月26日に失効する。 Microsoft Corporation KEK CA 2011 Microsoft Corporation UEFI CA 2011 Microsoft Windows Production PCA 2011（こちらは2026年10月） 失効後もシステムは起動する——これが危険な罠だ。「動いているから大丈夫」に見えて、実際にはWindows Boot Managerへのセキュリティ修正が届かなくなり、ブートキットなどのファームウェアレベルの攻撃に対して無防備になる。 対応には2023年版の新証明書をUEFIに焼き込む作業が必要で、OEMのファームウェアアップデートとの連携が求められる。特に古いハードウェアやカスタムUEFI設定を持つ環境では、テスト環境での検証なしに本番展開は危険だ。4月14日の更新が証明書移行の重要なマイルストーンになるため、今月中に展開計画を確定しておく必要がある。 実務への影響：IT管理者が今月やるべきこと ①テスト環境の即時整備 3月の品質問題を受け、本番環境への即日展開は避けるべきだ。小規模なテストグループに先行適用し、少なくとも48〜72時間の動作確認を経てから展開を広げる運用フローを今すぐ設計する。 ②Secure Boot対応状況の棚卸し 管理下の全デバイスについて、2023年版Secure Boot証明書が適用済みか否かを確認する。msinfo32で確認できる「セキュアブートの状態」と、UEFI設定の証明書バージョンを照合しておこう。 ③優先度付けの仕組みを持つ すべてのCVEを同列に扱うのは非効率だ。「攻撃が確認されているか」「CVSSスコア9.0以上か」「自社の攻撃対象領域（Attack Surface）に含まれるか」の3軸で絞り込み、クリティカルなものから順に展開する体制を整える。 ④ベンダー情報の一次確認習慣 各種メディアでの解説を参考にしつつも、MSRCの公式ページを一次情報として確認する習慣を組織に根付かせる。 筆者の見解 Secure Boot証明書の問題は、Microsoftが長年かけて積み上げてきたセキュアブート設計の正統進化であり、技術的には正しい方向性だ。この種のファームウェアレベルの保護を継続的に改善してきた姿勢は、素直に評価したい。 ただ、3月の一連の品質問題には正直もったいないと感じている。品質を担保するためのテストプロセスと、月次リリースのスピードを両立させることは確かに難しい。しかし、Microsoftには技術力もリソースも十分ある。パッチ品質の揺らぎが続くと、「数日様子を見てから当てる」という合理的な判断が組織に広まり、結果として脆弱性のウィンドウが開く時間が長くなる。攻撃者はそこを狙う。 IT管理者として現実的に取れる最善手は、盲目的な即日適用でも無期限の先送りでもなく、リスクを定量的に比較しながら計画的に動くことだ。6月26日の証明書失効は待ってくれない。今月のPatch Tuesdayは、その準備を本格化させる最後のタイミングと捉えて臨んでほしい。 出典: この記事は Patch Tuesday April 2026: Security Updates & CVE Analysis の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AI生成記事が「Windows 12」誤報を拡散 「Windows 12がAIに特化した形で2026年にリリースされる」——そんなニュースが先日、複数のテック系サイトで広まった。結論から言えば、これはAIが生成した誤報記事が発端の完全なファクトエラーだ。Windows CentralやWindows Latestといった信頼性の高いMicrosoft専門メディアが即座に事実確認を行い、「そのような公式発表はない」と明言している。 実際にMicrosoftが公式に発表しているのは「Windows 11 26H2」——つまり現行のWindows 11の機能更新プログラムの延長線上にある次期アップデートだ。Windows 12という新バージョン番号のリリースについて、Microsoftはいかなる公式コミュニケーションも行っていない。 なぜこの誤報が広まったのか 背景にあるのは、生成AIを使ったコンテンツファームの急増だ。AIが「それっぽい」ニュース記事を大量生成し、SEO目的で公開するサイトが世界中で増加している。今回の件では、AIが過去の「Windows 12開発中」という憶測記事や未確認情報を学習・再構成し、まるで確定情報のように仕立てた記事が生まれた可能性が高い。 技術的に興味深いのは、この種の誤報が「完全な嘘」ではなく「もっともらしい嘘」である点だ。Microsoftが将来的にWindows 12を出さないとは誰も断言できない。AI焦点の機能強化を次期バージョンに込めるというシナリオ自体は論理的に成立しうる。だからこそ、確認を省いたメディアが「それはそうかも」と転載してしまう。 Windows 12は本当にないのか 現時点でのMicrosoftの方針は、Windows 11を継続的にアップデートしていく形だ。26H2はその流れの中にある。Windows 10から11への移行で見せた「バージョン番号を変えない大型アップデート」戦略が続いているとみるのが妥当だろう。 ただし、数年単位の先を断言するのは難しい。Microsoftの製品戦略は市場状況や競合環境によって変わりうる。「2026年にWindows 12は来ない」という事実と、「将来的にWindows 12が存在しない」という話は別物だ。今回否定されたのは今年の計画としての誤報であり、長期の製品ロードマップについての議論ではない。 実務への影響——IT管理者が今すべきこと エンタープライズのIT管理者やエンジニアにとって、このニュースから引き出すべき実務的な教訓は二つある。 1. OSアップグレード計画は公式発表のみを根拠にせよ Windows 12が2026年に来るという誤情報を信じて「来年は大型移行が必要だ」と計画を立ててしまうと、リソース配分を誤る。MicrosoftのOfficial Blogsや公式テックコミュニティ、Ignote/Buildでの発表のみを一次情報として扱うこと。Windows CentralやWindows Latestのような専門メディアの「ファクトチェック記事」も信頼できるが、あくまで二次情報として位置づける。 2. テックニュースの出典を必ず確認する習慣を 「〇〇サイトで見た」だけでは不十分な時代になっている。記事の末尾にライター名はあるか、公式プレスリリースへのリンクはあるか、他の専門メディアが同様の報道をしているか——この三点を素早く確認するだけで、今回のような誤報に振り回されるリスクを大幅に減らせる。 筆者の見解 この件で改めて感じるのは、「情報を追うことと、情報に踊らされることは紙一重」という現実だ。生成AIによるコンテンツ量産が本格化した今、テック系メディアの信頼性はますます二極化していく。Windows Centralのような「書いた記者が責任を持つ」媒体の価値は、逆説的に高まっている。 Windowsについて言えば、バージョン番号に一喜一憂する時代はもう終わっていると思っている。Windows 11がどれだけ変わっても、Windowsを細かく追い続けることに以前ほどの意味はない。本当に重要なのは、セキュリティの強化やゼロトラストへの対応、デバイス管理のモダン化といった地に足の着いた話だ。 Microsoftには、派手な新バージョン発表よりも、エンタープライズが安心して使い続けられる堅実なプラットフォームとしての進化を期待したい。AI機能の実装についても、「ブランディングのためのAI」ではなく「現場が使えるAI」を地道に積み上げてほしい。それができる技術力と基盤はMicrosoftには間違いなくある。だからこそ、誤報に振り回されるのではなく、実質的な進化を自信を持って届けてほしいと思う。 出典: この記事は No, an AI-focused “Windows 12” is not coming this year — false report gets the facts completely wrong の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティの「縦割り」がついに終わるかもしれない MicrosoftがMicrosoft Defender for CloudをDefenderポータルへ統合拡張すると発表した。これにより、Azure・AWS・GCPをまたぐマルチクラウド環境のセキュリティ管理が、単一のポータルから行えるようになる。あわせて、Kubernetes環境（AKS / EKS / GKE）を対象としたコンテナランタイムのマルウェア検知・防止機能がプレビューとして提供開始された。 「セキュリティサイロの解消」という言葉は以前から繰り返されてきたが、今回の動きはそれを本気でやろうとしているように見える。 何が変わるのか Defenderポータルへの統合 これまでMicrosoft Defender for Cloudは独自のポータル（portal.azure.com内のDefender for Cloudブレード）で管理されており、Microsoft Defender XDRとは別々のインターフェースで運用されていた。今回の統合により、クラウドセキュリティの状態管理（CSPM）・脅威防御（CWP）・コンプライアンス評価が、Microsoft Defender XDRと同一のDefenderポータル上で確認できるようになる。 SOCアナリストがインシデントを調査するとき、エンドポイント・メール・クラウドリソースのアラートがひとつの画面で関連付けられるのは、実際の運用負荷軽減に直結する。「ポータルをどれだけ開けばいいんだ」という現場の声を真剣に受け止めた結果と言える。 コンテナランタイム保護（プレビュー） Kubernetesのコンテナが実行中にマルウェアに感染・実行させられるケースへの対応として、ランタイムレベルでの検知・防止機能がAKS（Azure Kubernetes Service）・EKS（Amazon EKS）・GKE（Google Kubernetes Engine）に提供される。 コンテナセキュリティはイメージスキャン（脆弱性検査）が先行して普及したが、本番稼働中のランタイム保護はまだ導入率が低い領域だ。特にAKSだけでなくEKSやGKEもスコープに含まれている点が重要で、マルチクラウドKubernetes戦略を取る組織でも使いやすい構成になっている。 実務への影響 — 日本のエンジニア・IT管理者に伝えたいこと 今すぐ確認すべきこと： Defenderポータルへの統合状況を把握する: テナントによって展開タイミングが異なる。Defender for Cloudを使っているなら、どのビューが統合済みかをDefenderポータル（security.microsoft.com）で確認しておく。 コンテナランタイム保護はプレビュー: 本番投入前にテスト環境でのポリシー挙動を検証することを強く推奨する。特にランタイム防止（Prevention）は誤検知時のインパクトが大きい。 マルチクラウドのコネクタ設定を見直す: AWS・GCPをDefender for Cloudに接続していない場合、今回の統合メリットが半減する。まずコネクタ設定から始めると良い。 ロールとアクセス権の整理: ポータル統合により、これまでAzureポータル側だけに権限を与えていたユーザーが、Defenderポータルでどう見えるかを確認しておく必要がある。 筆者の見解 正直なところ、セキュリティ系の話題は専門的すぎて細かいと感じることも多い。だが今回の動きには、単なる機能追加ではなく「アーキテクチャとしての方向性の正しさ」を感じる。 セキュリティポータルが乱立してきた背景には、製品ごとの縦割り開発という組織的な理由があった。Defender for Endpoint、Defender for Identity、Defender for Cloud Apps、そしてDefender for Cloud——それぞれ別々のチームが別々のポータルを作ってきた結果、現場では「どこを見ればいいかわからない」という状況が続いてきた。今回の統合はその反省を真剣に実装しようとしている姿勢だと思う。 ただ、ポータル統合が完成しても、運用する人間の設計が正しくなければ意味がない。日本の大企業のセキュリティ環境を見ていると、旧来のVPNベース・境界防御と中途半端なゼロトラストが混在していて、ポータルをいくら統合しても整合性のとれない構成のままになりがちだ。ツールが良くなっても、アーキテクチャの見直しが伴わなければ「便利になった縦割り」で終わる。 コンテナランタイム保護については、今後は「デプロイ前のスキャンだけ」では不十分という認識が業界に広まっていくだろう。ランタイムで何が起きているかを可視化・制御する層は、クラウドネイティブなシステムを本番運用する上で避けられない投資になる。早めにプレビューを試して感触をつかんでおく価値は十分にある。 Microsoftにはマルチクラウドを含む広大なプラットフォームを持つ強みがある。セキュリティの一元管理という方向性は明確に正しい。あとはその実行品質と、ユーザーが実際に使いやすい体験を継続的に磨き続けることができるかどうかだ。 出典: この記事は Breaking down security silos: Microsoft Defender for Cloud Expands into the Defender Portal の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Foundry（旧Azure AI Foundry）が2026年4月のドキュメント大規模更新を公開した。単なるリリースノートの域を超え、「AIエージェントを実業務で動かす」ための機能群が一気に揃いはじめた印象だ。エージェント活用を検討しているエンジニア・IT管理者にとって、見逃せない動きである。 今回のアップデートで何が変わったか エージェントのタスク遵守（Task Adherence）— プレビュー 今回のアップデートで最も注目すべきのが Agentic Workflows の Task Adherence（タスク遵守）機能だ。エージェントが与えられた指示の範囲を逸脱しないよう制御する仕組みで、単に「何かをやらせる」段階から「安全に・意図通りに動かせる」段階への移行を示す。 エージェントを本番環境に投入する際の最大の懸念は「暴走」である。指示の意図を汲み取りすぎて余計な操作をしたり、逆に指示を曲解して誤った判断をしたりするリスクを、プラットフォームレベルで抑制しようというアプローチは正しい方向性だ。 FLUX 画像モデルのデプロイ対応 FLUX は近年注目を集めるオープンな画像生成モデルシリーズ。これが Foundry から直接デプロイできるようになった。Azure の管理・セキュリティ基盤のままで最新の画像生成 AI を扱えるのは、エンタープライズ利用において大きなアドバンテージとなる。 Azure Developer CLI によるファインチューニング azd（Azure Developer CLI）の拡張として、モデルのファインチューニングをコマンドラインから実行できるようになった。IaC（Infrastructure as Code）の延長線上でモデルカスタマイズを管理できるため、DevOps フローに組み込みやすい。 Fireworks モデル統合（プレビュー）とカスタムモデルインポート Fireworks AI のモデルを Foundry 上で利用・インポートできるようになった。これはFoundryが「Microsoftが作ったモデルだけを使うプラットフォーム」ではなく、エコシステム全体のオーケストレーション基盤として進化していることを示す。 音声ネイティブエージェント Foundry Agent Service と Voice Live API の統合により、音声を一級市民として扱うエージェントが構築可能になった。コールセンター自動化や音声アシスタント用途での活用が現実的な選択肢になってきた。 実務への影響 — 日本のエンジニア・IT管理者にとっての意味 今すぐ着手できること： Task Adherence はプレビューだが早めに評価を：本番投入の判断材料として、動作の境界値テストを今のうちに実施しておく価値がある FLUX モデルを Azure 基盤で試す：社内の画像生成ユースケース（マーケティング素材、ドキュメント図版など）で外部サービスに依存せずに動かせるか検証を azd ベースのファインチューニングパイプラインを設計する：カスタムモデルの CI/CD 化は早期に仕組みを作っておくと後が楽 Entra ID を管制塔に据える設計を今から：Govern agent infrastructure as a Microsoft Entra global administrator というドキュメントが追加されたことが象徴的。エージェントの認可管理は Entra ID 中心に設計しておくべきだ 中長期で見ておきたいこと： ...

複数ISOが1本のUSBで共存できる「Ventoy」がマイルストーン達成 USBブートメディア作成ツールとして長年定番の座を守ってきた「Rufus」に対し、独自のアプローチで差別化してきた「Ventoy」がメジャーなマイルストーンを達成した。IT現場でUSBを日々扱うエンジニアや管理者にとって、これは無視できないニュースだ。 Ventoyとは何か——Rufusとの根本的な違い Rufusは「ISOを選んでUSBに書き込む」というシンプルな1対1のモデルを採用している。一方Ventoyは、USBドライブ自体をVentoyフォーマットで一度だけ初期化し、あとはISOファイルをドラッグ＆ドロップするだけという設計思想が根本的に異なる。 具体的には、1本のUSBメモリに以下をすべて共存させることができる。 Windows 11のインストールメディア Ubuntu・Debian・Fedoraなど複数のLinuxディストリビューション システム復旧用のWinPEやClonezillaなどのユーティリティISO ブート時にメニューが表示され、使いたいISOを選択するだけで起動できる。新しいISOを追加したいときも、単にファイルをコピーするだけでよく、USBを再フォーマットする必要がない。 セキュアブートへの対応も着実に進化 Ventoyが長年課題としてきたのが、UEFI環境におけるセキュアブート（Secure Boot）との互換性だ。Microsoftがセキュアブートを強化し続ける中、サードパーティのブートローダーは署名問題に悩まされてきた。 今回のマイルストーン達成は、こうした技術的な課題への取り組みが積み重なった成果でもある。Windows 11のインストール要件としてTPMやセキュアブートが必須化された現在、ツール側もその変化に追従しなければならない。 実務への影響——IT管理者・エンジニアが明日から使えるヒント USBキット一本化で現場効率が劇的に向上 IT管理者であれば、こんな場面に心当たりがないだろうか。「OSのインストール用USB」「復旧ツール用USB」「特定ディストリビューション用USB」と何本も持ち歩いている状況だ。Ventoyを使えば、1本のUSBメモリで全部をカバーできる。 運用上の注意点 容量の大きなUSBメモリを選ぶ: Windows 11 ISOは5〜6GB、Linuxも複数入れると10GB超えは普通。32GB以上を推奨 セキュアブートの設定を事前に確認: 機種によってはBIOS設定でセキュアブートの一時無効化、またはVentoyの登録が必要なケースがある ISOの整合性検証を習慣に: Ventoyはあくまでブートローダー。ISO自体が正常かどうかはチェックサムで別途確認する 企業環境では導入前にポリシー確認: セキュリティポリシーによっては外部ブートメディア自体が制限対象になっている場合がある Rufusと使い分ける判断軸 Rufusが依然として優れているのは、「単一ISOを素早く焼きたい」「Windows To GoやFAT32での特殊フォーマットが必要」といったシナリオだ。一方、複数のOSやツールを1本にまとめたいなら、Ventoyに軍配が上がる。両者を目的別に使い分けるのが現実的な選択だ。 筆者の見解 Windowsを細かく追いかけること自体の意味が薄れてきている中で、Ventoyのようなツールの価値は逆に上がっていると感じる。OSのインストールや環境構築は「仕組みで回す」ものになってきているからこそ、その仕組みを支えるツールの品質は重要だ。 Ventoyの設計思想——「一度セットアップすればあとはファイルを置くだけ」——は、筆者が大切にしている道のど真ん中を歩く再現性重視のアプローチと相性がいい。奇をてらった構成ではなく、シンプルで理解しやすい仕組みが、長く使えるインフラを作る。 セキュリティ面では、セキュアブート対応の成熟度を継続的にチェックしておく必要がある。「今動いているから大丈夫」は通用しない世界だ。特に企業IT環境では、ブートメディアの管理ポリシーとセットで運用ルールを整備しておくことを強くすすめる。 Ventoyがここまで成長してきたのは、オープンソースコミュニティの継続的なコントリビューションの賜物でもある。こういったツールを「知っているだけ」で終わらせず、実際に使って体験を積むことが、IT現場の引き出しを増やす一番の近道だ。 出典: この記事は Rufus alternative Ventoy, a Windows 11, Linux USB install app, reaches major milestone の内容をもとに、筆者の見解を加えて独自に執筆したものです。