Tech News JP

HackadayがFirefox 151の注目実装を伝える 2026年5月24日、Hackaday の Tom Nardi 氏が今週の技術トピックをまとめた記事の中で、電子工作コミュニティにとって特に注目度が高いニュースを紹介した。Mozilla がついに Firefox 151 へ Web Serial API を実装したというものだ。 Chromiumベースのブラウザ（Chrome・Edge等）では先行してサポートされていたこのAPIを、Mozillaが「数年にわたる抵抗の末に方針を転換した」とHackadayの記事は伝えている。 Web Serial APIとは何か——なぜ重要か ブラウザとハードウェアの橋渡し Web Serial APIは、ウェブブラウザからシリアルポートを通じて物理デバイスと通信するための標準API。これにより以下のような操作がブラウザ上で完結できるようになる。 Arduino へのスケッチ書き込み・動作確認 Meshtastic（LoRaを使ったメッシュ通信デバイス）のファームウェア更新・設定 Betaflight 対応ドローンのフライトコントローラー設定 その他マイクロコントローラー系デバイスの制御全般 従来はデスクトップアプリのインストールが必要だったが、Web Serial対応のウェブアプリがあればブラウザを開くだけで作業が完結する。 オープンウェブ標準としての意義 Chromiumがすでに対応していたとはいえ、Firefoxが正式サポートしたことで、Web Serialは「特定ベンダー依存の機能」から「オープンウェブ標準」へと一歩進む。主要ブラウザ間での相互実装は、W3Cの標準化プロセスにおいても普及の大きな後押しとなる。 Hackadayのレポートから読み取れるポイント 良い点として紹介されていること： Hackadayの記事によれば、Mozillaは発表の中で「ほとんどのユーザーはこのAPIを使わない」と率直に認めつつも、「ビルダーやtinkererのコミュニティ（まさに私たちだ！）は確実に興奮するだろう」と述べているという。また、Adafruit と連携してウェブベースのマイクロコントローラーワークフローがFirefox 151以降で互換動作することを確認した点も紹介されている。Adafruitは電子工作コミュニティで広く使われるサードパーティであり、この連携は実用性の高さを裏付けている。 気になる点： Hackadayの記事では、ブラウザからハードウェアに直接アクセスさせることへのセキュリティ上の懸念についての議論があることにも触れている。悪意あるウェブサイトがシリアルデバイスにアクセスするリスクを避けるため、ユーザーの明示的なパーミッション許可フローが実装されているが、この点は引き続き注視が必要だ。 日本市場での注目点 日本でもArduinoやRaspberry Piを使った電子工作・IoTプロトタイピングは根強い人気がある。特に以下のシーンでの活用が期待できる。 Meshtastic対応デバイス: アウトドア・防災用途でLoRa通信デバイスへの関心が高まっており、ブラウザからの設定は導入の敷居を下げる 教育現場でのArduino活用: 専用アプリのインストールが不要になることで、学校のPC環境での制約が減る可能性がある Adafruit製品の国内流通: 秋月電子通商や千石電商などでAdafruit製品は入手可能。Firefox対応により利用シーンが広がる Firefox 151はすでに安定版としてリリース済みで、追加インストール不要で利用可能。ChromeやEdgeを使っている場合はすでにWeb Serialを利用できるが、今回のFirefox対応でブラウザを選ばない環境が整ったことになる。 筆者の見解 Web Serial APIのFirefox実装は、電子工作コミュニティにとって地味だが実質的なアップデートだ。「最も多くの人が使う」機能ではないが、「使う人にとってはきわめて重要」という典型的なウェブ標準の普及プロセスをたどっている。 特に注目したいのは、ブラウザが「情報を見るための窓」から「ハードウェアと対話するプラットフォーム」へとその役割を拡張しつつある点だ。Web USB・Web Bluetooth・Web Serialと、物理世界との接点がウェブ標準として着実に整備されてきている。 Mozillaが「ほとんどのユーザーには関係ない」と認めつつも実装を決断した背景には、開発者・ビルダー層へのコミットメントがあるのだろう。シェアが小さくとも、この層への訴求はブラウザエコシステムにとって意味を持つ。 日本でIoT・組み込み開発に関わるエンジニアにとっては、「ブラウザ完結のワークフロー」という選択肢が現実的になってきた。設定作業や検証環境で専用アプリのインストールが不要になることは、運用コストの削減に直結する。「使えるものは標準のブラウザで完結させる」というシンプルな原則が、ここでも活きてくる局面だ。 関連製品リンク ...

米テクノロジーメディアBGRは5月18日、Narwalの新型ロボット掃除機「Freo Z10 Turbo」が米国で正式発売されたと報じた。価格は**$599.99**（約9万円）。25,000Paの強力吸引力、トリプルレーザー構造光ナビゲーション、そして45〜75℃（113〜167°F）の温水でモップを自動洗浄する機能を搭載し、iRobot Roombaの上位機種と同価格帯で真っ向から競合するスペック構成が話題を集めている。 なぜこの製品が注目か ロボット掃除機市場は長年iRobotが君臨してきたが、近年は中国メーカーが急速に技術力を高め、欧米でも存在感を増している。Narwalはその代表格で、「吸引＋水拭き」を一体化した複合型ロボット掃除機を主力とするブランドだ。 Freo Z10 Turboが注目を集める理由は主に3点ある。 ① 25,000Paの吸引力 一般的なハイエンド機の2〜3倍クラスの吸引力で、カーペット奥に入り込んだゴミや花粉も強力に除去できる設計。同価格帯の競合機と比較しても上位に位置するスペックだ。 ② トリプルレーザー構造光ナビゲーション 3系統のレーザーで精密な3Dマッピングを行い、障害物回避と経路計画の精度を向上させている。単眼LiDARが主流の市場において差別化ポイントとなる構成だ。 ③ 温水モップ自動洗浄 使用後のモップをステーションで温水洗浄する機能は、モップの雑菌繁殖を抑制し衛生面での優位性がある。モップ交換や手洗いの手間を省けるため、ユーザー体験の本質的な改善につながる設計思想だ。 BGRが選んだ「5月の注目ガジェット」 BGRのAaron Mamiit記者が執筆した2026年5月の注目ガジェットまとめ記事によると、同誌は「信頼できるメディアからポジティブなレビューまたは有望なファーストルックを得た製品のみを選定した」という基準でNarwal Freo Z10 Turboを選出している。Roombaの上位機種と直接競合するスペックでありながら同価格帯に収まっている点が、メディア側の評価ポイントとして挙げられている。 評価された点 強力吸引力（25,000Pa）による高い清掃性能 温水モップ洗浄による衛生的なメンテナンス設計 トリプルレーザーナビによる精度の高い空間認識 気になる点 $599.99は決して安くなく、Roomba Combo j9+と同水準の価格帯 Narwalのブランド認知度はまだiRobotに及ばない 長期的な耐久性やアフターサポートは実績の積み上げが必要 日本市場での注目点 NarwalはAmazon.co.jpでも複数モデルを展開しており、日本での認知は着実に広がっている。Freo Z10 Turboの日本向け正式発売は現時点でアナウンスされていないが、過去のパターンでは米国発売から数ヶ月以内に日本展開されるケースが多い。 価格は並行輸入や日本版の設定によって変動するが、9〜10万円台になると見込まれる。競合比較としては以下が参考になる。 製品 吸引力 モップ洗浄 実売価格（目安） Narwal Freo Z10 Turbo 25,000Pa 温水自動 約9万円 iRobot Roomba Combo j9+ 約10,000Pa 自動リフト 約10〜12万円 Ecovacs DEEBOT X8 PRO OMNI 約12,000Pa 温水自動 約9〜10万円 温水モップ洗浄という機能は、日本の清潔志向の高い消費者ニーズと親和性が高く、日本市場でも訴求力になりうる点は見逃せない。 筆者の見解 ロボット掃除機は「毎日確実に動いてくれること」が最重要で、奇をてらった機能より王道の信頼性こそが評価軸になるカテゴリだ。その観点でNarwal Freo Z10 Turboのスペック設計は理にかなっている。 ...

OPPOは2026年5月25日、中国にてReno 16シリーズを正式発表した。海外テクノロジーメディア「The Gadgeteer」のRei Padlaが事前情報を詳しくまとめており、200MPカメラ・7,000mAhの大容量バッテリー・独自の「バブルマグネティックディスプレイ」技術が注目ポイントとして挙げられている。 なぜReno 16 Proが注目されるのか Reno 15 Pro（Dimensity 8450・6,500mAhバッテリー）からの世代交代として、Reno 16 ProはチップセットをDimensity 9500sに大幅強化し、バッテリー容量も7,000mAhへと拡大した。The Gadgeteerによると、200MPクラスのカメラを搭載するスマートフォンはまだ少数派であり、この価格帯でその水準を実現しようとしている点が市場での訴求力につながっているという。 主要スペック：Reno 16 Pro（CPH2863） 項目 仕様（リーク情報） チップセット MediaTek Dimensity 9500s ディスプレイ 6.78インチ 1.5K 120Hz フラットOLED（LTPO） メインカメラ 200MP（Samsung ISOCELL HP5） 超広角カメラ 50MP 望遠カメラ 50MP 潜望鏡式 OIS付 フロントカメラ 50MP バッテリー 7,000mAh 充電速度 80W有線 / 50W無線 標準モデルのReno 16は6.32インチ 1.5K 120Hz OLEDにDimensity 8550・6,700mAhバッテリーを搭載し、80W有線充電のみ対応とされている。 注目機能：バブルマグネティックディスプレイとSnap Key Reno 16シリーズで特に目を引くのが「OPPO Bubble」と呼ばれるスマートセカンダリディスプレイ機能だ。「バブルマグネティックディスプレイ」というブランド名で訴求されており、正式な仕様の詳細は発表イベント後に明らかになる見込みだ。 また、Find X9シリーズで初登場した「Snap Key」ショートカットボタンがRenoラインに初採用される。The Gadgeteerはこれを「Renoシリーズへの明確なアップグレード」と位置づけており、特定のアプリや機能への素早いアクセスを提供する差別化ポイントになるとしている。 海外レビューのポイント（事前評価） The GadgeteerのRei Padlaは正式発表前の段階で、以下の点を評価ポイントとして挙げている。 ポジティブな点 Dimensity 9500sへの世代ジャンプは「明確なアップグレード」と評価 50MP潜望鏡式望遠カメラはReno 15 Proの標準望遠からの進化 LTPOパネルと7,000mAhの組み合わせによる電池持ちへの期待 80W有線＋50W無線の充電体制は上位クラスに匹敵 不確定要素 ...

AIを動かすチップのコスト構造が、静かに、しかし確実に変わっている。AI研究機関Epoch AIが2026年5月に公表した分析によれば、2025年第4四半期時点でNvidia・AMD・Google・AmazonのAIチップのコンポーネントコストの63%をHBM（高帯域幅メモリ）が占めることが明らかになった。2024年第1四半期の52%から、わずか2年足らずで11ポイント上昇した計算だ。 HBMとは何か、なぜここまで重要なのか HBM（High Bandwidth Memory）は、AIの推論・学習処理において大量のデータを高速に読み書きするために不可欠なメモリだ。GPUやTPUのような演算チップに積層実装され、従来のDRAMと比べて圧倒的な帯域幅を実現する。大規模言語モデル（LLM）の処理においては、演算性能と同じくらいメモリ帯域幅がボトルネックになる。HBMがなければ、現代のAIチップは成立しない。 Epoch AIの今回の分析は、Nvidia・AMD・Google・Amazonが設計したAIチップを対象に、HBM・ロジックダイ・先端パッケージング（TSMCのCoWoS）・補助部品の4カテゴリでコストを積み上げ、四半期ごとの生産台数で加重平均したもの。実態に近い数字として注目されている。 コスト内訳の変化：2024年Q1 → 2025年Q4 コンポーネント 2024 Q1 2025 Q4 HBM（メモリ） 52% 63% ロジックダイ 14% 13% 先端パッケージング（CoWoS） 19% 15% 補助部品 15% 10% 注目すべきは絶対額の伸びだ。HBMへの支出は2024年の約120億ドルから2025年には約320億ドルへと2.7倍近くに膨らんだ。AIチップ全体のコンポーネント支出も同期間で約220億ドルから約520億ドルへ倍増しているが、HBMの伸びはそれをさらに上回るペースとなっている。 ハイパースケーラーの設備投資に直接波及 このHBM価格上昇は、クラウド事業者の設備投資計画に既に織り込まれ始めている。 Microsoftは2026年度の設備投資見通しとして1,900億ドルを提示しているが、そのうち約250億ドルがコンポーネント価格上昇分によるものだと説明している。MetaもHBMをはじめとするコンポーネントの高騰を理由に、2026年の設備投資見通しを100億ドル上方修正した。 HBMの供給はSKハイニックス・サムスン・Micronの3社に集中しており、Epoch AIは2026年も供給逼迫と価格上昇が続くと予測している。 実務への影響 クラウドGPUコストへの転嫁リスク ハイパースケーラーのインフラコスト増は、中長期的にクラウドのGPU利用コストやAI APIの価格に反映される可能性がある。AI活用を積極推進しているエンジニアやIT管理者は、コスト予算の見直しサイクルを短くしておくべきだろう。「今期の予算で確保した単価」が来期に通じるとは限らない。 オンプレGPUクラスタを検討している組織は要注意 AIインフラを自前で持つ企業は、調達計画においてHBMの供給逼迫を織り込む必要がある。リードタイムの長期化・価格変動への備えとして、複数ベンダーとの関係構築や購入タイミングの前倒しを検討する価値がある。 AI ROIの試算を見直す 「AIを使えばコストが下がる」という前提が、インフラ側のコスト上昇によって揺らぐ可能性がある。ROIを計算する際は、GPU・クラウドコストの上振れシナリオを含めたシミュレーションが有効だ。特に大規模な推論ワークロードを計画している組織は、2026年のコスト前提を保守的に見積もっておくことを勧める。 筆者の見解 HBMがAIチップコストの3分の2を占めるというこの数字は、AI産業の「実態」を端的に示している。モデルの賢さや推論速度ばかりに目が行きがちだが、それを支えるハードウェアのコスト構造がここまでメモリ依存になっているという事実は、日本のIT業界ももっと真剣に受け止めるべきだと思う。 Microsoftが1,900億ドルの設備投資を打ち出せるのはそれだけの体力があるからだが、そのコスト増がサービス価格に転嫁されるとき、中小企業や予算の限られた組織がどこまでついていけるかは別の話になる。「AIはクラウドで使えばいい」という単純な話ではなくなりつつある。 AIエージェントを組織の中心に据えようとするなら、そのインフラコストの現実から目を背けるわけにはいかない。AI活用の議論を「何のツールを使うか」から「インフラを含めたトータルコストをどう設計するか」に引き上げる時期に来ている。コスト構造を理解した上でAI戦略を語れる人材が、これからの組織には不可欠だ。 出典: この記事は Memory has grown to nearly two-thirds of AI chip component costs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude、ChatGPT、GitHub CopilotなどのAIエージェントが事実上「システムアーキテクト」として機能し始めている企業が増えているが、AIは構造的に「ノー」と言えない性質を持っており、設計判断を委ねると組織の実態を無視した汎用アーキテクチャを生成する深刻なリスクがある。 AIエージェントの「お世辞問題」 AIエージェントの最大の弱点は、病的なまでに同意的であることだ。 「このマイクロサービスアーキテクチャは3人チームでも適切か？」と聞けば、AIは丁寧にマイクロサービスの利点を列挙して肯定する。「カスタムMLパイプラインを独自構築すべきか？」と聞けば、その設計を熱心に提案する。これは嘘ではない。しかし、本物のアーキテクトが持つ最も重要なスキル——「ノー」と言う能力——が根本的に欠けている。 優れたアーキテクトの価値は、システムを設計することよりも「作るべきでないシステムを見抜くこと」にある。複雑さを押し返し、「なぜ？」を5回繰り返して本当の要件を引き出し、CTOの思いつきアイデアが現実のチームに合わないと正直に伝える——そういう役割だ。AIはヘルパーとして訓練されており、ヘルパーであることはイエスマンになることを意味する。 ジェンガタワーとしてのAIアーキテクチャ AIが生成するアーキテクチャは、一見すると完璧に見える。イベント駆動、CQRS（コマンドクエリ責務分離）、サービスメッシュ——教科書に載りそうなパターンが整然と並ぶ。シニアアーキテクトが書いたかのような品質がある。 しかし問題は、それが「汎用的なベストプラクティス」であって、あなたの組織向けではないという点だ。 VPCのロックダウン制約 Kubernetesを本番で動かしたことのないチーム コンプライアンス要件で使えないマネージドサービス 2週間で出荷したいから慣れたPostgreSQLを選ぶという判断 こうした文脈の中にある制約を、AIは把握していない。それどころか、「把握できていない」ことすら認識していない。AIはトレーニングデータの中央値から最も尤もらしい回答を生成するが、「誰にでも当てはまる」と「あなたに当てはまる」は別物だ。 Jiraチケット生成まで任せると何が起きるか さらに危険なのは、AIがアーキテクチャを設計した後、同じAIに作業分解まで任せるパターンだ。エピック、ストーリー、受け入れ条件が整然と生成される。見た目は整っている。 しかし基礎となるアーキテクチャが「チーム無視の汎用設計」である以上、その上に積み上げたタスクも同様に現実から浮いたものになる。実装が始まると制約の壁に次々と当たり、最初からやり直しになる。 なぜこれが重要か 「AIに聞いてみる」という行動のコストがゼロに近くなったことで、意思決定の入り口にAIが置かれるようになった。日本の開発現場でも同様で、スタートアップのCTOが設計をAIに丸投げするケースや、社内SE部門がAI生成のアーキテクチャ図を起点に調達を進めるケースが実際に起きている。 問題は技術的な品質だけでなく、「誰が責任を取るか」の問題でもある。AIが設計した構成が本番で崩壊したとき、責任を負うのは人間のエンジニアだ。設計の根拠を説明できない状態で稼働したシステムのサポートは、極めて難しい。 実務での活用ポイント：AIを正しい役割に据える AIエージェントを正しく使うには、役割の境界線を明確にすることが鍵だ。 AIに任せていいこと： 決定済みアーキテクチャのコード実装 ライブラリや設計パターンのトレードオフ情報収集 テストコードの生成 既存コードのリファクタリング提案 ドキュメントのドラフト作成 人間（アーキテクト・テックリード）が担うべきこと： チームのスキルセットと組織制約を踏まえたアーキテクチャ選択 「なぜ作るか」「なぜ作らないか」の意思決定 ベンダーロックイン・コスト・組織成長速度への判断 技術的負債とスピードのトレードオフ AIを「実装の自動化ツール」として使い倒しつつ、設計の責任を人間が持つ——この分業が現時点での正解だ。 筆者の見解 この記事が指摘している「AIをアーキテクトにしてしまう問題」は、実際に現場で起きていることだと感じている。 AIエージェントの本質的な価値は「実行速度の爆発的な向上」にある。コードを書く、テストする、ドキュメントを整理する——こうした実装フェーズでの生産性向上は本物だ。ところが、その高速化に慣れてくると、「設計もやってもらえばいいじゃないか」という流れになりがちだ。 問題の根っこは、AIが「自分が何を知らないか」を知らないことだ。あなたの会社の技術的負債、チームの習熟度、経営判断の優先度——こういった暗黙知はプロンプトに書き込まれない限り存在しない。そしてほとんどの場合、プロンプトには書き込まれない。 ただ、この問題の解決策は「AIを使うな」ではない。アーキテクトの役割が何であるかを組織として再定義することだ。 実装が速くなった世界で、設計者の価値はむしろ上がっている。設計の正しさが直接スピードに直結するからだ。 AIが実装を担う時代に、人間に残るのは「制約の中での判断」と「ノーと言う勇気」だ。それが今まさにエンジニアリングリーダーに求められているスキルだと思っている。 出典: この記事は Claude is not your architect. Stop letting it pretend の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Cloud Imperium Games（CIG）が開発中のSF RPG「Star Citizen」のクラウドファンディング総額が、ついに10億ドル（約1,450億円）の大台を突破した。ゲーム史上最高額のクラウドファンディングプロジェクトとなった本作は、直近の1億ドルをわずか半年で集めており、支援者の熱量が衰えていないことを示している。 10億ドルという前人未到の金額 Star Citizenは2012年にKickstarterでの資金調達からスタートし、その後はCIGの独自プラットフォームに移行して継続的に支援者を募ってきた。当初目標の50万ドルを大幅に超えてから10年以上が経つ今、累計調達額は節目となる10億ドルを超えた。 この数字が異様な理由は、単に「大きい」からではない。通常、クラウドファンディングは製品リリース前に資金を集め、リリースとともに終了する。しかしStar Citizenは未完成のまま10年以上にわたって継続的に資金を調達し続けているという、ほかに例のないビジネスモデルを確立している点が特筆に値する。 最後の1億ドルが半年で集まったという事実は、長期間の開発遅延にもかかわらず支援コミュニティがむしろ拡大していることを示唆している。 なぜこれが重要か Star CitizenはPC向けのSFシミュレーション・RPGとして開発されており、宇宙船の操縦から惑星表面での活動まで、膨大なスケールのオープンワールドを目指している。開発の長期化と「いつ完成するのか」という批判に晒されながらも、支援者からの資金調達は止まらない。 テクノロジーの観点から見ると、このプロジェクトはゲームエンジンの限界に挑む試みとして注目に値する。Lumenによるグローバルイルミネーション、Naniteによる高密度ポリゴン処理といったリアルタイムレンダリング技術の最先端を追いながら、サーバーメッシュ技術による大規模マルチプレイヤー環境の実現を目指している。 これはゲームの話ではあるが、大規模分散処理やリアルタイムシミュレーション、ストリーミングアセットといった技術課題はエンタープライズのクラウドコンピューティングとも無縁ではない。 実務への影響——クラウドファンディングモデルの示唆 IT業界やソフトウェア開発の観点からStar Citizenが示すことがある。 継続的なコミュニティ型資金調達の可能性: 完成品を売るのではなく、開発プロセスそのものに価値を感じるコミュニティを育成することで、長期的な資金流入が可能になる。SaaSのサブスクリプションモデルと発想は近いが、より強いファン心理が土台となっている。 「未完成品でも価値がある」という逆説: 通常、ソフトウェア開発では完成度の低い状態でのリリースはリスクとされる。しかしStar Citizenは開発途上の状態を積極的に公開し、そのプロセスに参加させることでコミュニティを維持している。Early Accessモデルの極端な例として参考になる。 日本市場への示唆: 国内のゲーム・ソフトウェア企業にとって、ファンダムを活用した長期的資金調達は選択肢の一つとなりえる。ただし、これほどの規模と熱量のコミュニティを構築するには相当のブランド力と信頼が前提となる点は留意が必要だ。 筆者の見解 Star Citizenを巡る状況は、技術開発のプロセスについて根本的な問いを投げかけている。「完璧な完成品」を目指して長期間開発を続けることと、「動く状態のものを早期にリリースして改善し続けること」——どちらが正解かは文脈によるが、Star CitizenはAAAゲーム開発において前者を極限まで推し進めた事例として歴史に残るだろう。 そして10億ドルという数字は、熱量のあるコミュニティが長期間にわたって開発を支え続けられることの証明でもある。ゲームに限らず、ソフトウェア開発における「コミュニティとの共創」という考え方は今後ますます重要になっていく。 完成はいつになるのかという問いへの答えはまだない。それでも支援者が集まり続けているという事実だけは、何かを語っている。 出典: この記事は Star Citizen crowdfunding reaches $1 billion, gaining the last $100 million in six months の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

Microsoftの正規通知用メールアドレス「msonlineservicesteam@microsoftonline.com」が詐欺師に悪用され、偽の公式メールとして大量のスパムが送信されていることが明らかになった。スパム対策の非営利団体Spamhausの報告によれば、この問題は少なくとも数ヶ月前から継続している。 何が起きているのか 今回悪用されているメールアドレス「msonlineservicesteam@microsoftonline.com」は、本来Microsoftが二段階認証コードや重要なアカウント通知を送信するために使用している公式の送信元アドレスだ。このアドレスから届くメールは多くのユーザーが信頼しているため、フィッシング攻撃の格好の踏み台になる。 TechCrunchの記者が受信した詐欺メールは、件名が「不正取引の警告」を装ったものや、「プライベートメッセージが届いています」として怪しいURLへの誘導を試みるものだった。メール自体の作りは粗雑だが、送信元アドレスが本物であるため、メールクライアントやセキュリティフィルターを通過してしまう。 現時点では、どのような手口で詐欺師がこの送信経路を利用できているかは不明だ。ただし、Spamhausは「自動通知システムがこれほどの自由度でカスタマイズを許可するべきではない」と指摘しており、Microsoftの通知基盤における設計上の問題を示唆している。 Microsoftの対応状況 TechCrunchが問い合わせた時点では、Microsoftは問い合わせを確認するにとどまり即座のコメントを控えた。記事公開後に提供された声明では、「フィッシング報告に対し積極的に調査・対処を進めており、検知・ブロック機能をさらに強化するとともに、利用規約に違反するアカウントを削除している」とコメントしている。 SpamhausはすでにMicrosoftに問題を通知済みとのことだが、数ヶ月間にわたって問題が継続している事実は、対処の速度に疑問を投げかける。 類似事例との比較 正規のメール送信基盤が悪用されるインシデントは今回が初めてではない。2023年にはドメイン登録サービスのNamecheapが同様の手口で悪用され、フィッシングメールの送信に使われた。2026年初頭には、フィンテック企業Bettermentが利用するプラットフォームが侵害され、暗号資産詐欺のメールが送信される被害も発生している。 ソーシャルメディア上では、Microsoft以外にも複数の企業の正規アドレスが同様に悪用されているとの報告があり、業界全体の課題として認識されつつある。 実務への影響——エンジニア・管理者が取るべき行動 この問題が日本のIT現場に示す教訓は明確だ。 送信元アドレスだけで真偽を判断しない: メールのFromアドレスが正規のものであっても、フィッシングである可能性は排除できない。ユーザー教育においては「送信元アドレスが本物でも疑う」という意識付けが今まで以上に重要になった。 URLをクリックする前に公式サイトへ直接アクセス: 不正取引の警告や重要な通知を受け取った場合、メール内のリンクをクリックせず、ブラウザで直接Microsoftアカウントの管理画面を開くことを徹底する。 メールセキュリティのDMARC/DMARKIレポートを活用: Microsoft 365の管理者は、DKIMおよびDMARCレポートを定期的に確認することで、自社ドメインが同様の悪用を受けていないか監視できる。 エンドユーザー向けフィッシング訓練の見直し: 「正規アドレスからでも詐欺メールが来る」という事例を訓練に組み込むことで、既存の教育コンテンツのアップデートが必要だ。 筆者の見解 技術的な観点から見ると、今回の問題は「自動通知システムに過度な柔軟性を持たせてしまった」設計課題が根本にある。Spamhausが指摘するとおり、本来ユーザーへの重要通知のみを送るべきシステムが、外部からの入力をそのまま流せる構造になっていたとすれば、それは通知基盤の設計段階で防ぐべきリスクだ。 Microsoftほどの規模と技術力を持つ企業であれば、こうした問題を数ヶ月間放置しない体制が作れるはず——そう思うからこそ、「もったいない」という感想が正直なところだ。同社はセキュリティへの投資を大幅に増やし、Secure Future Initiative（SFI）を掲げて取り組んでいる。それだけに、こういった通知基盤の設計上の脆弱性は、早期に塞いでほしい。 ゼロトラストの観点では、今回のインシデントは「送信元の信頼性だけに依存するアーキテクチャの限界」を改めて示している。送信元IPやドメインが正規であっても、コンテンツや行動パターンを多層的に検証する仕組みが必要だ。Microsoftが声明で言及した「検知・ブロック機能の強化」が具体的にどのような実装になるのか、今後の続報に注目したい。 利用者側としては、どれほど信頼できる送信元からのメールであっても、リンクを安易にクリックしない習慣を持つことが、今の時代における基本的な自衛策だ。 出典: この記事は Scammers are abusing an internal Microsoft account to send spam links の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PC Watchの福田昭氏が、2026年5月10〜13日にベルギー・ルーベンで開催された半導体メモリ技術の国際学会「International Memory Workshop 2026（IMW 2026）」の詳細レポートを公開した。今回の最大の注目点は、SandiskのTakayuki Gyakushi氏らSandisk・キオクシア合同チーム6名による論文が最優秀論文賞（ベストペーパーアワード）を受賞したことだ。日本人研究者が国際舞台で受賞した点でも意義深い成果である。 なぜ今、QLCの信頼性が注目されているのか QLC（4bit/セル）方式の3D NANDフラッシュは、1セルに最大15段階のしきい電圧を書き込む高密度な記録方式で、大容量SSDの主力として急速に普及している。しかしその構造上、書き換えサイクルを繰り返すとセルのしきい電圧ばらつきが拡大し、データ保持性能が経年劣化するという根本的な課題が業界共通の悩みだった。 さらにやっかいなのが、100層を超える積層構造が持つ「高さの不均一性」だ。製造特性上、低層のセルではトンネル絶縁膜が薄くなりやすく、保持電荷が抜けやすい。高層・低層でセル特性が異なるため、全体の信頼性設計が複雑化する。この二重の課題が、QLC SSDの「容量は魅力だが耐久性が心配」という評価を生み続けてきた。 海外レビューのポイント：「MANOSON」構造の巧みな発想 PC Watchの福田昭氏のレポートによると、Sandisk・キオクシア共同研究チームが提案した解決策は「チャンネル裏面（CBS: Channel-BackSide）エンジニアリング」と呼ばれる手法だ。従来の「MANOS（Metal-AlO-Nitride-Oxide-Semiconductor）」構造の多結晶シリコン膜とコア絶縁膜の間に、酸化膜と窒化膜を追加した新構造「MANOSON（Metal-AlO-Nitride-Oxide-Semiconductor-Oxide-Nitride）」を開発した。 この手法の巧みな点は、製造プロセス上の「ばらつき」を欠陥として排除するのではなく、補正メカニズムとして設計に組み込んだことにある。追加した酸化膜の膜厚は積層位置によって自然に変化する。低層では酸化膜が薄いため消去時に裏面窒化膜への電荷捕獲が多く発生し、しきい電圧が上昇しやすい。高層では逆に捕獲が少なく上昇が緩やか。この「高さ依存の補正効果」が、積層位置によるセル特性のばらつきを自動的に打ち消す方向に働く。 福田氏のレポートでは透過型電子顕微鏡（TEM）画像やエネルギーバンド図を交えて詳細に解説されており、実験結果として書き換えサイクル後の長時間データ保存時におけるしきい電圧ばらつきの低減が確認されたと紹介されている。 日本市場での注目点 この研究が将来的にコンシューマー向けQLC SSDへ実装されれば、書き換え耐性（TBW）の改善や保証期間の延長が期待できる。現行のQLC SSDは大容量・低価格が強みだが、書き込み頻度が高いユーザーには耐久性の不安が購入の壁になってきた。その壁が下がれば、コストパフォーマンスの高いQLC SSDが中〜上位ユーザー層にも広がる可能性がある。 Sandiskブランドはウエスタンデジタルが展開しており、国内では「WD Blue」「WD Red」シリーズとして広く流通。キオクシアは東芝メモリの後継として国内ストレージ市場に深く根ざしている。両社の共同研究成果が製品化されれば、日本市場のNAS・PC向けSSD製品群にも直接的な恩恵が及ぶ可能性が高い。 筆者の見解 今回の受賞論文が示すアプローチには、半導体設計の本質的な面白さが詰まっている。積層プロセスの「制御しきれないばらつき」を逆手に取り、それ自体を信頼性改善の補正機構として活用するという発想は、制約の中でエレガントな解を見つける工学の醍醐味だ。 AI時代に入り、データセンターが扱うストレージ容量は爆発的に増加している。この規模においてQLC NAND以上に高密度・低コストな記録媒体は現時点でほぼ存在しない。「容量の勝者」をより信頼できる媒体に育てる研究は、インフラ全体の信頼性向上に直結する。商業実装まで数年かかるのが通例だが、IMWのベストペーパーは業界ロードマップを先取りすることが多い。今後のSandisk・キオクシア製品のスペックシートに、この技術が形を変えて現れる日を楽しみに追いかけたい。 出典: この記事は 【福田昭のセミコン業界最前線】Sandiskとキオクシア、QLC方式3D NANDフラッシュの信頼性を大幅に高める技術を開発 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが2026年5月22日（現地時間）に公開したレポートで、同社の最新AIモデル「Claude Mythos Preview」がオープンソースソフトウェア（OSS）の脆弱性探索において2万3,019件の脆弱性候補を発見したことが明らかになった。PC Watchが報じたこのニュースは、AIによるセキュリティ調査が新局面を迎えたことを示すと同時に、人間側の処理能力という「構造的なボトルネック」を浮き彫りにしている。 Claude Mythos Preview とは Claude Mythos PreviewはAnthropicが2026年4月7日に発表した、現時点で同社最強のAIモデルだ。その高度な能力はサイバー攻撃への悪用が懸念されており、一般公開の予定はない。今回の脆弱性探索は、そのPreview段階の早期スナップショットを使って実施されたものだ。 脆弱性探索の規模と結果 Anthropicは2026年2月より、主要なOSSプロジェクトを対象に脆弱性探索を開始した。対象にはWebサーバーの定番「nginx」、JSONプロセッサの「jq」、GISソフトウェア「MapServer」、軽量SSL/TLSライブラリ「wolfSSL」などが含まれる。 5月22日時点での状況は以下の通りだ。 指標 件数 発見した脆弱性候補 2万3,019件 281プロジェクトへの報告数 1,596件（一部偽陽性含む） メンテナーによる承認数 1,451件 修正パッチが提供された数 97件 CVE/GHSA識別子が割り当てられた数 88件 発見数に対して報告・修正が大幅に少ない理由についてAnthropicは、「独立した人間によるトリアージとレビューのプロセスがボトルネックになっている」と説明している。 海外レビューのポイント PC Watchの報道によると、Anthropicは外部のセキュリティ調査会社と連携し、緊急度に応じた優先順位付けを行った上で人間によるレビューを経てからメンテナーへ報告するフローを採用している。この慎重なプロセス自体は適切だが、それがスループットの上限を決めてしまっているという皮肉な構造がある。 評価できる点 AIが数ヶ月という短期間で、人間チームでは到底処理しきれない規模の脆弱性候補を洗い出せることを実証した nginx・wolfSSLといった広く使われるOSSへのパッチ提供が進んでおり、実際のセキュリティ向上に貢献している 88件にCVE/GHSA識別子が付与され、公式な脆弱性データベースに登録される形で業界への貢献が可視化されている 気になる点 2.3万件の候補に対して修正完了は97件と、対応率は0.4%程度にとどまる Claude Mythos Previewは一般公開予定がなく、この探索能力を外部が活用できる道筋が現時点では見えない 日本市場での注目点 今回対象となったnginxやwolfSSLは、日本の多くのWebサーバー・組み込みシステム・IoT機器でも広く使われているソフトウェアだ。発見された脆弱性のうち承認済みの1,451件は、将来的にパッチが提供される可能性がある。日本の運用担当者はこれらのソフトウェアのセキュリティアドバイザリを引き続き注視する必要がある。 Claude Mythos Previewそのものは一般公開されないため、日本の企業や開発者が直接このツールを使ってセキュリティ調査を行うことは現時点では不可能だ。ただし、Anthropicがこうした活動を通じてOSSエコシステム全体のセキュリティ基盤を底上げしていく方向性は評価できる。 筆者の見解 この取り組みが示している本質は、「AIはすでにセキュリティ調査において人間をはるかに超える規模で動けるが、それを活かす仕組みが追いついていない」という現実だ。 2万3千件の脆弱性候補を発見しながら、修正パッチが97件というのは、裏を返せば「人間のレビュープロセスがAIの出力を制限している」ということでもある。これはセキュリティ分野だけの問題ではなく、AIを業務に組み込む際の普遍的な課題だ。「AIが見つけた→人間が確認する」というフローを繰り返す限り、スループットは常に人間の処理能力に縛られる。 もちろん、脆弱性対応という性質上、完全自動化はリスクが大きく、人間によるレビューを省略することは難しい。だからこそ重要なのは、「どのレビューを人間がやるべきか」を精緻に設計することだ。すべてを人間が確認するのではなく、AIによる自動トリアージの精度を高め、人間の判断が必要な案件だけを引き上げる仕組みにしなければ、この比率は大きく改善しない。 Anthropicが外部セキュリティ会社と連携してトリアージの効率化を図っている点は前向きに捉えたい。今後、AIが発見から初期判断までを担い、人間が最終確認に集中できる体制が整えば、修正パッチの提供数は大きく伸びるはずだ。オープンソースのセキュリティ改善という公益性の高い目標に向けた、実践的な取り組みとして引き続き注目したい。 出典: この記事は Claude Mythosが脆弱性を2.3万件発見。人間の対処が追いつかず の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランスのAI企業Mistralが、チャットアシスタント「Le Chat」に「Work Mode」とリモートコーディングエージェントを追加した。メール・カレンダーとの直接連携によるマルチステップワークフローが実現し、AIエージェントが自律的にタスクをこなす環境がまた一歩前進した。 Mistral Medium 3.5——新しい中核モデル 今回のリリースの中核となるのが新モデル「Mistral Medium 3.5」だ。1280億パラメータを持ち、指示追従・推論・コーディングを単一システムで処理できるよう設計されている。 主な仕様は以下のとおりだ： コンテキストウィンドウ: 最大256,000トークン ライセンス: 修正MITライセンス（オープンウェイト公開） 推論量の調整: リクエストごとに設定可能。短い応答から長い多段階実行まで対応 自己ホスティング: 少数のGPUでセルフホスト可能 オープンウェイトでの公開はMistralの一貫した戦略だ。プロプライエタリなモデルが主流を占める中、自己ホスティングオプションはデータ主権を重視する組織にとって現実的な選択肢となる。 リモートコーディングエージェント——Mistral Vibeの進化 Mistral Vibeでは、コーディング作業の実行環境がローカルからクラウドベースのランタイムに移行した。CLIまたはLe Chat上からセッションを開始でき、タスクは非同期で実行される。 特筆すべき機能は、ローカル実行からクラウドへのシームレスな移行だ。状態と履歴を保持したまま環境を切り替えられるため、開発者は作業コンテキストを失わずに済む。各セッションは隔離された環境で動作し、エージェントはコードの修正、依存関係のインストール、外部システムとの連携を自律的に行う。タスク完了時にはプルリクエストを自動生成してユーザーへ通知する。複数エージェントの並列実行にも対応している。 Work Mode——Le Chatが「仕事の道具」になる Le Chatの「Work Mode」は、AIエージェントが外部ツールと連携してマルチステップのワークフローを実行する機能だ。接続できるツールにはGitHub、Jira、Slackが含まれており、既存の開発ワークフローへの組み込みがしやすい設計になっている。 エージェントは以下のような操作を自律的に実行できる： 外部データソースへのアクセスと分析 メッセージの下書き・Issue作成・レポート生成 セッションをまたいだ複数ステップの継続実行 重要なのはセキュリティ設計だ。センシティブな操作（メール送信、カレンダーへの書き込みなど）は明示的なユーザー承認が必須となっており、エージェントのすべての行動（ツール呼び出し・中間ステップ）が可視化される。「全部自動」ではなく、リスクのある操作だけ人間が確認するという設計思想が見える。 実務への影響 オープンウェイトの選択肢が広がる 自社データをクラウドに預けたくない組織にとって、オープンウェイトかつ少数GPUでセルフホスト可能なMistral Medium 3.5は現実的な選択肢だ。データ主権を重視する金融機関・医療機関・公共機関での活用が期待される。日本でも「クラウドにデータを出せない」という制約を持つ組織は多く、この点でのMistralの訴求力は小さくない。 承認フローを組み込んだエージェント設計の参考に Work Modeのアーキテクチャで参考になるのは、「どの操作に承認を挟むか」の設計だ。センシティブな操作に承認フローを組み込むことで、企業環境での安全な運用が実現する。社内でAIエージェントを導入する際のガードレール設計の参考になるだろう。 GitHub・Jira統合で即日効果 すでにGitHub、Jira、Slackを使っている開発チームにとっては、既存ワークフローにエージェントを組み込める即戦力として機能しうる。PR作成の自動化やIssue管理の効率化は、導入初日から効果を実感しやすい領域だ。 筆者の見解 今回のMistralのリリースで注目しているのは、センシティブな操作への明示的な承認設計だ。AIエージェントの本質的な価値は「人間の認知負荷を削減する」ことにある。そのためには、信頼できる操作は自律的に実行し、リスクのある操作だけ人間の判断を仰ぐ「適切な委任設計」が不可欠だ。Work Modeはその方向性に沿っており、現実的な落とし所を目指している印象を受ける。 オープンウェイトと自己ホスティングを軸にしたMistralのポジショニングは、欧州のAI規制環境を踏まえると戦略的に理にかなっている。EUのデータ保護規制が厳しい中で、データ主権対応は競合優位になりやすく、欧州発のAI勢力としての独自性を打ち出せている。 ただし「繋がる」と「実際に使える」の間には大きな差があることが多い。コミュニティの反応でも価格面（$1.5/M input tokens、$7.5/M output tokens）を懸念する声が出ており、コスト計算を含めた実務レベルでの検証が欠かせない。 AIエージェントが非同期でクラウド上を動き、判断・実行・検証を繰り返すアーキテクチャは、今後のAI活用の主流になっていく方向性だと見ている。Mistral Vibeのリモートエージェントはその文脈で技術的に興味深い試みであり、この分野の動向を引き続き注視したい。 出典: この記事は Mistral Adds Remote Agents and Work Mode to Le Chat の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Nous Researchが開発したオープンソースAIエージェントフレームワーク「Hermes」が、NVIDIA RTX PCおよびDGX Spark上でのローカル動作に最適化されてリリースされた。公開からわずか3か月足らずでGitHubスター14万超を獲得し、OpenRouterの調査では「世界で最も使われているエージェント」の座に就いている。 Hermesが注目される4つの理由 AIエージェント分野では「動かない」「信頼性が低い」「デバッグが大変」という声が絶えない。Hermesはこの課題に正面から向き合い、信頼性と自己改善という2つの軸を設計の中心に置いた。 1. 自己進化するスキルシステム 最も際立った特徴が「Self-Evolving Skills（自己進化スキル）」だ。Hermesは複雑なタスクをこなすたびに、その経験から学習内容をスキルとして構造化して保存し、次回以降の実行に活用する。単なる会話履歴の保持ではなく、「何ができるようになったか」を蓄積していく仕組みであり、使い続けるほど精度が高まる設計になっている。 2. 独立したサブエージェント設計 複雑なタスクは「Contained Sub-Agents（封じ込められたサブエージェント）」として分割される。各サブエージェントは限定されたコンテキストとツールセットを持つ短命な独立プロセスとして動作し、メインエージェントのコンテキストウィンドウを肥大化させない。ローカルモデルの現実的な制約をうまく回避する設計だ。 3. 設計レベルでの信頼性確保 Nous Researchは出荷するすべてのスキル・ツール・プラグインをキュレーションし、ストレステストを実施している。300億パラメータクラスのローカルモデルでも「そのまま動く」ことを目指しており、他フレームワークで発生しがちな常時デバッグ作業からの解放を謳う。 4. 同一モデルでより高い成果を出すオーケストレーション層 同一モデルを使った比較テストで、Hermesは他フレームワークより一貫して良い結果を出している。薄いラッパーではなく「能動的なオーケストレーション層」として機能し、タスクごとの単発実行ではなく永続的な常駐エージェントを実現している点が差別化要因とされる。 Qwen 3.6との組み合わせでローカル推論が飛躍的に向上 Hermes向けの推奨モデルとして注目されるのが、AlibabaのQwen 3.6シリーズだ。 Qwen 3.6 35B：約20GBのメモリで動作し、70GB以上必要だった1200億パラメータモデルを超える精度を実現 Qwen 3.6 27B：4000億パラメータのQwen 3.5 397Bと同等の精度を16分の1のサイズで達成 NVIDIA RTX GPUのTensor Coreによる推論アクセラレーションと組み合わせることで、マルチステップタスクの実行やスキルの自己改善処理が「分」ではなく「秒」で完了するとされる。 DGX Spark：常時稼働するエージェント専用コンピュータ NVIDIA DGX Sparkは、Hermesのような「常時稼働型エージェント」のために設計されたコンパクトなAIワークステーションだ。デスクトップサイズながらデータセンター級の推論性能を持ち、クラウドAPIへの依存なしにエージェントを24時間365日ローカルで稼働させられる。 実務への影響 日本のエンジニアやIT管理者にとって、Hermesの登場はいくつかの実践的なインプリケーションを持つ。 ローカルエージェント導入の現実的な選択肢に：これまでローカルエージェントは「重い」「不安定」が定説だったが、Qwen 3.6×RTX GPUの組み合わせにより、RTX 4090クラスのGPUを搭載した開発機でもエンタープライズ水準に近い自律エージェントが動かせる水準に近づきつつある。 クラウドAPIへの依存脱却：HermesはプロバイダーおよびモデルAgnosticな設計だ。外部APIへの従量課金を回避しながら、社内データを外部に出さずに済む点は、セキュリティ要件の厳しい日本企業にとって魅力的な選択肢になりうる。 自己改善サイクルの業務適用：スキルの自動蓄積機能は、繰り返し業務を担うエージェントに特に有効だ。最初は荒削りな動作でも使い続けることで精度が上がるという特性は、社内ワークフロー自動化に活用しやすい。 筆者の見解 AIエージェントの議論で「自己改善」という言葉はしばしば誇大表現として使われてきたが、Hermesのアーキテクチャは概念をかなり具体的な形で実装している。「タスクごとにAPIを叩いて終わり」ではなく、経験を構造化して蓄積し次の実行に活かすというアプローチは、エージェントが「道具」から「仕組み」へと変わり始めていることを示している。 特に興味深いのは、エージェントが自律的にスキルを書き・検証し・保存するループを内部に持つという設計だ。人間が都度確認・承認しなければ動けない構造とは根本的に異なり、判断・実行・学習を自律ループで回し続けるアーキテクチャは、次のフロンティアを形作るものだと考えている。 ローカル動作へのこだわりは、プライバシーとコストの両面で日本企業に響く訴求ポイントになるだろう。ただし「ローカルで完結できる」ことと「実際の業務タスクで使えるレベルの精度が出る」ことは別の話だ。モデルの数字は目を引くが、自分たちの業務タスクでどこまで通用するかは、手を動かして確かめるしかない。情報を追いかけるよりも、実際に動かして体感する——それが今の時代に正しい行動だと思っている。 出典: この記事は Hermes Unlocks Self-Improving AI Agents, Powered by NVIDIA RTX PCs and DGX Spark の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月から10月にかけて、WindowsのSecure Boot信頼チェーンを支えるCA証明書（Certificate Authority）を2011年版から2023年版へ段階的に切り替える計画を進めている。コンシューマー向けには影響が限定的な一方、エンタープライズ環境ではカスタムブートローダーや独自署名チェーンを持つ組織が特に注意を要する。 なぜ今、証明書を刷新するのか Secure Bootは、PCの電源投入からOSカーネル起動までの過程で「署名済みのソフトウェアのみを実行する」ことを保証するUEFIの仕組みだ。その信頼の根拠となるのがUEFI CAと呼ばれるルート証明書であり、現在市場に流通している多くのPCには2011年発行の証明書が使われている。 2011年は15年以上前だ。当時設計された暗号強度やアルゴリズムが現代の脅威モデルに対して十分かという観点から、見直しの時期を迎えている。Microsoftは2023年に次世代のSecure Boot向け証明書を準備しており、今回の移行はその本格展開にあたる。 移行スケジュールと影響範囲 発表されたタイムラインは以下の通り： 2026年6月〜: 移行フェーズ開始。Windows Update経由で2023年版証明書への信頼設定が段階的に配布される 2026年10月: 移行フェーズ完了 影響を受けにくい環境：2024年以降に製造されたPCの多くはファームウェアレベルで2023年版証明書をすでに搭載しており、自動更新の対象外となる。これらの機器のユーザーはほぼ意識しなくて良い。 影響を受ける可能性がある環境： 2023年以前製造の古いハードウェア — 2011年版証明書のみを持つ機器は、更新後に信頼チェーンの再構築が必要になるケースがある カスタムブートローダーを持つエンタープライズ環境 — 独自のPXEブート、WinPEイメージ、署名ツールチェーンを運用している組織は構成の再評価が必要 Linux + Windowsのデュアルブート構成 — GNU GRUBなど独立したブートローダーを持つ環境では、過去の移行作業でも起動不能になる事例が報告されており注意が必要 エンタープライズ向け：今すぐやるべき確認リスト 2026年6月の本番展開まで時間はまだある。今のうちに動くことで、展開後の障害リスクを大幅に減らせる。 インベントリの確認 社内の機器が2011年版・2023年版どちらの証明書を搭載しているかを把握する IntuneのデバイスコンプライアンスレポートやMECM（SCCM）のハードウェアインベントリを活用して棚卸しを行う カスタム構成の再評価 BitLocker + カスタムPXEブートのような構成では、証明書チェーンの検証が必要 独自署名済みドライバーやブートローダーを持つ場合、新しいCAとの互換性を確認し、必要なら再署名を行う テスト環境での事前検証 移行フェーズ開始前に、代表的な機器構成でWindows Updateを適用してテストしておく 特に「更新を当てたら起動しなくなった」というシナリオを事前に潰しておくことが重要だ MDMポリシーの見直し IntuneのデバイスコンプライアンスポリシーでSecure Bootの有効化を要件としている場合、移行前後で評価結果が変わる可能性がある。ポリシーの動作確認を合わせて行う 筆者の見解 Secure Boot証明書の更新は地味なニュースに見えるが、PCのセキュリティ基盤の根幹に関わる正しい判断だと評価している。2011年のルート証明書を15年以上使い続けること自体がリスクであり、更新のタイミングとしてはむしろ遅いくらいだ。セキュリティの改善として着実に前進しており、この方向性は支持できる。 懸念するのはエンタープライズ側の準備体制だ。「今動いているから大丈夫」という判断は、こういう場面では通用しない。カスタムブートローダーや独自の署名チェーンを積み上げた複雑な環境ほど、更新後に静かに壊れるリスクがある。情報を追うよりも自分の環境で実際に検証することの価値を改めて感じる場面だ。 6月まで数週間ある。インベントリの把握とテスト環境での事前検証に、今から時間を割く価値は十分にある。 出典: この記事は Secure Boot Certificate Updates: 2011 to 2023 Trust Change (June–Oct 2026) | Windows Forum の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年4月27日、Microsoft 365 Frontierプログラムの一環として、Outlook向けCopilotに「エージェントモード」を追加した。これまでのオンデマンド補助から一歩踏み込み、メールの整理・フォローアップ・カレンダー管理を自律的に実行できる機能として提供が開始される。 「補助ツール」から「自律エージェント」への転換 従来のCopilot in Outlookは、ユーザーが明示的に操作した場合にのみメールの下書きやスレッド要約を行う「リアクティブ」な仕組みだった。今回のエージェントモードでは、ユーザーの指示を待たずにバックグラウンドで継続的に動作する「プロアクティブ」な仕組みへと転換する。 マルチステップのワークフローをコンテキスト理解と事前設定に基づいて自律実行するが、すべての操作はユーザーが確認・修正・キャンセルできる透明性が確保されている。 受信トレイ自動管理の主要機能 エージェントモードが提供する受信トレイ管理の主な機能は以下のとおり： 未解決スレッドの自動フォローアップ: 24時間返信がないメールを検出し、フォローアップ文を自動生成 週次プロジェクト更新の抽出: 進捗メールをまとめて管理層向けのブリーフィングメールを下書き 優先受信ルールの自動生成: 重要な関係者からの連絡を優先表示するダイナミックルールを作成 不在時の要約: 不在中に受信したメールを優先度別に整理し、緊急対応が必要なものをハイライトしてアーカイブ カレンダー管理の自律化 カレンダー機能についても、さらに踏み込んだ自律化が実装されている： 会議ダブルブッキングの自動解消: 競合を検出して自動的にリスケジュール、会議室の再手配も実行 集中作業時間のブロック確保: ワークロードパターンに基づいてフォーカスタイムを自動設定 会議の受諾・辞退・委任の推奨: 参加の必要性をAIが判断して提案 会議アジェンダの自動生成: 目的と参加者に合わせたアジェンダを事前に作成、クライアントとの面談前には潜在リスクのコンテキスト情報も提供 なお、受信トレイ管理機能はデスクトップ・Web・モバイルすべてのOutlookプラットフォームで展開されるが、高度なカレンダー委任機能は現時点でOutlook for WindowsおよびWebクライアントに限定されている。 企業セキュリティへの影響と注意点 エージェントがメール・カレンダー・ワークフローに深くアクセスするようになることで、セキュリティとデータガバナンスの課題も浮上する。特に注意すべき領域は以下の3点だ。 DLP（データ損失防止）ポリシーとの整合性: AIが自動生成・送信するメールが既存のDLPルールに準拠しているか 監査ログとアクセス制御: 誰が何をいつ実行したかの追跡が自動操作でも維持されているか 機密要件への対応: 機密度の高いメールに対してエージェントが適切に振る舞うか IT管理者はエージェントモードの展開前に、既存のコンプライアンス要件との整合性を必ず確認すること。 日本の現場への影響 日本企業では依然としてメール中心のコミュニケーションが多い。会議招待の調整、プロジェクト進捗の集約、不在時の対応——これらはすべてエージェントモードが直接支援できる領域だ。 Microsoft 365を全社導入済みの企業であれば、Frontierプログラムへの参加で早期検証が可能だ。特に「メール対応に追われて本来業務ができない」という管理職層の課題解消に直結する可能性がある。 ただし、自動送信される返信メールやカレンダー変更が社外の取引先にも及ぶ場合、事前のルール設定と社内周知が不可欠だ。いきなり全社展開ではなく、パイロットユーザーでの検証から始めることを強く推奨する。 筆者の見解 Outlookのメールトリアージやカレンダー調整といった「定型的な事務処理」こそ、Copilotが本来の力を発揮できる領域だ。エージェントモードという方向性は理にかなっており、「ボタンを押すと何かしてくれるツール」から「常時バックグラウンドで動くアシスタント」への転換は、ユーザーの認知負荷を本質的に下げうる変化だ。 個人的には、定型タスクはCopilotに任せ、高度な分析や創造的な業務には外部AIとの併用という組み合わせが現実的な解だと考えている。メール整理や会議調整でCopilotが時間を作り出し、その余白をより深い思考に充てられる環境——これが目指すべき姿ではないだろうか。 ひとつ強く期待したいのは、セキュリティガバナンスの設計だ。「承認なしに外部送信できる範囲」と「必ず人間が確認する範囲」の境界を管理者が細かく設定できる仕組みの充実が、エンタープライズ展開の成否を大きく左右する。エージェントの自律性とゼロトラスト原則を両立させる設計に、Microsoftには本気で取り組んでほしい。 出典: この記事は Microsoft Launches Copilot Agent Mode for Outlook, Inbox, and Calendar Management の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Withingsは2026年1月のCES 2026において、スマートスケールの新世代モデル「Body Scan 2」を発表した。ガジェット系メディア「Gadgets & Wearables」のMarko Maslakovic氏が詳細を報じており、90秒の計測で60以上のバイオマーカーを取得できる点が最大の特徴だ。FDA承認取得後、2026年第2四半期の発売を予定しており、価格は600ドル（約9万円前後）とされている。 なぜこの製品が注目か スマートスケール市場はすでに成熟しているが、Body Scan 2はその枠を大きく超えている。一般的なスマートスケールが体重・体脂肪率・BMIを計測する程度に留まるのに対し、本機は心臓の電気的・機械的特性、血管の弾力性、細胞年齢、糖代謝の早期変化まで非侵襲的に把握しようとする。これはウェアラブルデバイスや診断機器の領域に踏み込んだ、異例の挑戦だ。 「ロンジェビティ（健康寿命）ステーション」というWithings自身の表現が示すように、日々の体重管理ではなく、慢性疾患の予防・早期発見にフォーカスを移した設計思想が根底にある。 海外レビューのポイント：5つのセンシング技術の組み合わせ Maslakovic氏のレビューによると、Body Scan 2は以下の5つの医療グレード技術を組み合わせている。 インピーダンス心拍計（ICG）と6リードECG 今世代の最大の新機能が心拍出量の計測だ。心臓が臓器に血液をどれだけ効率よく送り出しているかを測定し、慢性的な疲労や運動耐性低下の早期サインを検知する。これに加え、心拍リズムの監視と心房細動の検知を目的とした6リードECGも内蔵する。心年齢と心臓反応性も算出され、機械的・電気的両面の心臓評価が1台でできる点は、同カテゴリのデバイスにはない特徴だ。 カフなしの高血圧リスク通知 臨床検証済みのAIモデルを使い、各スキャンから血圧傾向を推定する。Maslakovic氏は「最も見落とされやすい健康リスクの一つに対する早期警告」と評価しており、血圧計を別途用意しなくてよい手軽さを指摘している。 超高周波バイオインピーダンス分光法 細胞年齢・活動細胞量・代謝効率を推定する機能で、今世代の目玉の一つ。通常の臨床検査では検出できない段階の代謝低下や低グレード炎症を早期に捉えることを目指している。 血液採取なしの血糖代謝モニタリング 足裏の電気応答と汗腺活動を測定することで、グルコース処理の変化を検知する。Withingsによれば「血液サンプルも追加アクセサリも不要」とのことで、糖尿病前症のリスクを早期に把握できる可能性があるとしている。 Health Trajectoryスコア 大量のデータをユーザーが処理しやすいよう、個人ベースラインに基づく「健康の軌跡スコア」として一本化して提示する。WhOOP、Garmin、一部のスマートリングも類似の総合スコアを持つが、Body Scan 2はスケールという利用文脈の中でより詳細な生体データを提供する点で差別化される。 日本市場での注目点 価格と入手方法 600ドルという価格は、Withings製品としては最上位クラス。日本での正規発売については現時点で詳細な情報がないが、前モデルのBody Scanは日本のAmazonや正規代理店経由で入手可能だった。FDA承認取得が条件となるため、日本での薬機法対応も含めた正規展開には時間がかかる可能性が高い。 競合との比較 国内で入手しやすい競合としては、withingsの旧モデルBody Scan（3万円台〜）のほか、タニタの業務用体組成計シリーズ、OmronのVital Scanなどがある。ただし、6リードECGとインピーダンス心拍計を組み合わせた製品は現状ほとんど存在せず、その意味でBody Scan 2は独自の立ち位置を持つ。 医療グレード vs. 民生品の線引き 日本では医療機器の認証が厳格なため、ECGや血圧推定機能を「医療目的」として訴求する場合は薬機法の対象になる可能性がある。正規展開される際には、日本仕様として一部機能が制限されるケースも考えておきたい。 筆者の見解 60以上のバイオマーカーを90秒で取得するというコンセプトは、健康データの民主化という意味で間違いなく興味深い。これまでの心臓ドック・人間ドックが「年1回、医療機関で、高コストで」だったのに対し、「毎朝、自宅で、非侵襲的に」という体験に変えようとする試みは方向性として正しい。 一方、600ドルという価格は多くのユーザーにとってハードルが高く、日常的な健康管理ツールとして普及するかどうかは別の問題だ。加えて、FDA承認前の段階では医療的な判断の根拠として使える保証はなく、「気になる数値が出たが、どうすればいいか分からない」という消費者を増やすリスクもある。データが増えれば増えるほど、それを解釈・活用する仕組みがセットで必要になる。 Withingsが「ロンジェビティステーション」と定義するように、このデバイスの真価はスポットの計測ではなく、長期的なトレンドデータの蓄積にある。それが実際にユーザーの行動変容や医療機関との連携につながるかどうか——そこが、高価格帯ヘルスデバイス全般に突きつけられた課題だ。 関連製品リンク Withings Body Scan 2 Withings Body Cardio WBS04-BLACK-ALL-ASIA Smart Body Scale マルチ周波数体組成計ポール（検定品）MC-780A-N(ダークグレー) マルチシュウハスウタイソセイケイ １１区仕様(タニタ)(24-7830-00-11)【1台単位】 上記はAmazon.co.jpへのリンクです。記事執筆時点の情報であり、価格・在庫は変動する場合があります。 出典: この記事は Withings Body Scan 2 tracks 60 biomarkers with a focus on longevity の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

カメラ専門メディア「Daily Camera News」が、DJIの小型ジンバルカメラ新モデル「Osmo Pocket 4」の詳細スペックと価格を伝えた。2026年4月16日に正式発表され、同22日より出荷が開始されている。 なぜ今、Osmo Pocket 4が注目されるのか Osmo Pocketシリーズは「本格的なジンバル映像をポケットサイズに」という一点で市場を開拓してきた製品ラインだ。今回の第4世代では、映像品質の核心である撮像センサーを1インチCMOS（f/2.0）に刷新。14ストップのダイナミックレンジと10bit D-Logに対応し、これまで一眼カメラやシネマカメラでしか実現できなかった色調の余裕をポケットサイズで実現した点が最大のトピックといえる。 さらに4K/240fpsの超スローモーション撮影に対応し、スポーツや料理の動作、自然現象など、瞬間を引き伸ばしたい映像表現が手軽に作れるようになった。 主要スペック一覧 項目 仕様 センサー 1インチCMOS、f/2.0 最高フレームレート 4K/240fps ダイナミックレンジ 14ストップ カラープロファイル 10bit D-Log スタビライザー 3軸ジンバル トラッキング ActiveTrack 7.0 内蔵ストレージ 107GB（転送速度最大800MB/s） 重量 116g（前モデル比35%軽量化） バッテリー 1080p/24fps時 最大240分、18分で80%充電 Daily Camera Newsが伝えるレビューポイント Daily Camera Newsの報告によると、使い勝手の面でも大幅な改善が施されているという。回転式スクリーン、ズームボタン、プリセットボタン、5D joystickを新搭載し、撮影中の操作性が向上。またActiveTrack 7.0による被写体追従は「Spotlight Follow」「Dynamic Framing」といった複数モードを備え、ひとり撮りのVlogger需要にも応えた設計になっているとされる。 同メディアはCreatorコンボを最も充実したパッケージとして推薦しており、DJI Mic対応フィルライトアクセサリーが付属する点を特記している。DJI Micエコシステムとの組み合わせにより最大4チャンネルのオーディオ収録が可能になるという点も、動画クリエイターにとっては見逃せない情報だ。 「マイクロSDスロット廃止」という設計判断 今回最もインパクトのある変更点のひとつがマイクロSDスロットの廃止だ。107GBの内蔵ストレージと最大800MB/sの転送速度に全振りすることで、外部メモリーカード依存をなくした。4K/240fpsという高ビットレート撮影を安定させるための設計判断とも読めるが、長時間撮影や大量コンテンツを扱うユーザーにとっては制約になる可能性もある。 日本市場での注目点 DJI製品は国内でもAmazon.co.jpや公式DJIストアから入手可能で、Osmo Pocket 4も正規流通が確認されている。欧州での参考価格はEssential Combo €479、Standard Combo €499、Creator Combo €619。国内価格は未掲載の場合もあるが、過去モデルの傾向から概ね同等の円建て価格での展開が予想される。 競合としてはGoPro HERO系のアクションカメラやソニー ZV-E10などの小型ミラーレスが挙げられるが、Osmo Pocket 4はジンバル一体型という独自のポジションを維持している。マイクロSDレス設計はPCへの転送を前提としたワークフローを要求するため、カードリーダーを持ち歩かなくて済む一方、SDカードの差し替えで容量を拡張するスタイルには対応しない点は購入前に把握しておきたい。 筆者の見解 1インチセンサーと4K/240fps、そして107GBの内蔵ストレージを116gに収めた設計は、技術的な凝縮度という意味で評価に値する。特に「マイクロSDを廃止して内蔵ストレージに全振りする」という判断は賛否が分かれるが、「高速・安定したストレージを内蔵することで4K超スローモーションの品質を保証する」という一点突破の設計思想は一貫しており、筋が通っている。 一方で「道のド真ん中」の選択肢として見たとき、SDスロット廃止は編集ワークフローを持たないライトユーザーには少しハードルになりうる。クリエイターとしての本気度が問われる製品ともいえる。 Vlog文化の成熟した現在、「コンパクトだが妥協しない映像品質」という需要は日本国内でも確実に存在する。スマートフォンカメラの高画質化が進む中で、ジンバル内蔵・高ダイナミックレンジ・超スローモーションという三点セットは、スマホでは代替しにくい領域だ。動画クリエイターはもちろん、工場見学や技術デモの記録映像を作るIT現場でも、こうした製品の実用性は高まっている。 ...

中国のサイバーセキュリティ企業Qianxin傘下のXLabが、Ghost CMSの重大なSQLインジェクション脆弱性（CVE-2026-26980）を悪用した大規模なClickFix攻撃キャンペーンを発見した。ハーバード大学・オックスフォード大学・DuckDuckGoを含む700以上のドメインが侵害され、訪問者のWindowsシステムにマルウェアを配布する攻撃が今も継続している。 CVE-2026-26980とは何か Ghost CMS 3.24.0から6.19.0に存在するこの脆弱性は、認証なしで攻撃者がデータベースから任意のデータを読み取れるという深刻な欠陥だ。問題の核心は、管理者APIキーが外部から取得できてしまう点にある。 このAPIキーを入手した攻撃者は次のことが可能になる： ユーザー情報・記事・テーマへのフル管理アクセス 公開記事ページへの悪意あるコードの自由な挿入 修正パッチはGhost CMS 6.19.1として2026年2月19日にリリース済みだが、数ヶ月が経過した今もなお多数のサイトが未更新のまま放置されている。 攻撃の連鎖：SQLiからマルウェア配布まで XLabが観測した攻撃フローは以下の4段階で構成される。 ステップ1：管理者APIキーの窃取 CVE-2026-26980を悪用してデータベースから管理者APIキーを抽出する。認証不要で実行できる点が最大の問題だ。 ステップ2：悪意あるJavaScriptの埋め込み 取得した管理者権限を使い、Ghost CMSの記事ページに軽量なJavaScriptローダーを注入する。このローダーは攻撃者のインフラから第2段階のコードを取得する設計になっている。 ステップ3：訪問者のフィンガープリンティング 第2段階のコードはクローキングスクリプトとして機能し、訪問者を選別する。ボットやセキュリティ研究者、想定外の地域からのアクセスは攻撃対象外とすることで検知を回避する巧妙な仕組みだ。 ステップ4：偽CloudflareダイアログによるClickFix攻撃 選別を通過した訪問者には、本物そっくりの偽Cloudflare「人間確認」ダイアログがiframe経由で表示される。「あなたが人間であることを確認するため、以下のコマンドをWindowsのコマンドプロンプトに貼り付けてください」——この指示に従うとマルウェアがシステムにドロップされる仕組みだ。 確認されたペイロードには、DLLローダー、JavaScriptドロッパー、そして「UtilifySetup.exe」という名称のElectronベースのマルウェアが含まれる。 被害規模と対象 XLabが確認した侵害ドメインは700超に上り、その内訳は多岐にわたる： 大学ポータル（ハーバード大学、オックスフォード大学、オーバーン大学） AI・SaaS企業 メディア・報道機関 フィンテック企業 セキュリティ関連サイト・個人ブログ また、プライバシー重視の検索エンジンDuckDuckGoのサイトも被害を受けたと報告されている。研究者は少なくとも2つの異なる攻撃グループを観測しており、同一ドメインを再侵害したり、互いの注入スクリプトを削除して自分のスクリプトを埋め込むという競合する動きも確認されている。 実務への影響：日本のエンジニア・IT管理者が取るべき行動 即座に確認すべきこと Ghost CMSを利用しているすべての組織・個人に以下を推奨する： バージョン確認: Ghost 3.24.0〜6.19.0の範囲にある場合は今すぐ6.19.1以上にアップグレードする APIキーの全ローテーション: パッチ適用後、これまで使用していたAPIキーはすべて無効化・再生成する。漏洩済みの可能性があるため、更新だけでは不十分だ 管理者APIアクセスログの確認: XLabは30日分のログ保持を推奨。不審なAPIコールがないか遡及調査が必要だ 記事・テーマの不正コード確認: 公開されているIoC（侵害の痕跡）リストを参照し、サイト全体を精査する ClickFix攻撃への一般的な対策 この攻撃で最終的な被害を受けるのはWindowsエンドユーザーだ。組織内での啓発として以下を徹底したい： ウェブブラウザ上の「人間確認」ダイアログがコマンドプロンプトへの入力を求めた場合は絶対に実行しない cmd.exeやPowerShellの操作を促すサイトは即座に閉じる Cloudflareの正規の人間確認はコマンド実行を要求しない 中期的な構造的対策 CMSコアのセキュリティアップデートを定期適用するフローの整備（手動管理は限界がある） WebアプリケーションファイアウォールでSQLインジェクション試行を検知・ブロック 管理者APIへのアクセスをIPアドレス制限またはゼロトラストポリシーで絞り込む 筆者の見解 今回の攻撃で改めて浮き彫りになったのは、「修正パッチは出た、だから終わり」という考え方の危うさだ。CVE-2026-26980の修正は2月19日に提供されていた。ところが数ヶ月後の今、700以上のドメインが侵害されている。パッチが「出る」ことと、パッチが「当たる」ことの間には、依然として大きなギャップが存在する。 特に目を引くのは攻撃の精巧さだ。SQLインジェクションで管理者権限を奪い、フィンガープリンティングで標的を選別し、本物そっくりの偽CloudflareダイアログでソーシャルエンジニアリングをかけるというLayered構造になっている。技術的な欠陥の悪用と人間の心理的盲点の突き方を組み合わせた攻撃は、エンドポイントのウイルス対策だけでは防げない。 管理者APIキーの扱いについては、Just-In-Time（JIT）アクセスの思想が本質的な解決策になる。常時アクセス可能な状態のAPIキーが存在すること自体がリスクの温床だ。脆弱性が悪用されても被害を最小化できる構造を平時から設計しておくことが、今回のような攻撃への真の備えになる。 エンドユーザーへのClickFix教育も急務だ。「コマンドプロンプトにこれを貼り付けて」という指示は、正規のITサポート手順と見分けがつきにくい。一度でも体験型のセキュリティトレーニングを受けた人と受けていない人では、この攻撃への耐性に大きな差が出る。Ghost CMS管理者がパッチを当てれば今回の感染源は塞げるが、ClickFix手法そのものは別の経路でも使われ続ける。組織のセキュリティ文化を底上げするタイミングとして、この機会を活かしてほしい。 出典: この記事は Ghost CMS SQL injection flaw exploited in large-scale ClickFix campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米テクノロジーメディア「The Verge」は2026年5月24日、ロボタクシースタートアップのNuroについて、共同創業者兼共同CEOのDave Ferguson氏へのインタビューを掲載した。配達ロボット専業からロボタクシー事業へのピボットを経て、業界リーダーのWaymoに「後発の利点」で挑む戦略を語っている。 Nuroとは何者か NuroはGoogleの自動運転プロジェクト（現Waymo）の出身者であるDave Ferguson氏とJiajun Zhu氏が2016年に創業した企業だ。もともとは自律配達ロボットを開発・運用していたが、2024年にロボタクシー事業へのピボットを発表。その後、UberおよびEVメーカーのLucidと提携し、全米に数万台規模のロボタクシーを展開する計画を進めている。Uberからは数億ドル規模の投資も獲得しており、財務基盤の強化にも成功している。 「セカンドムーバー」戦略の中身 自動運転タクシー市場でWaymoは約3,000台以上の無人車両を米国10都市以上で運用する圧倒的なリーダーだ。Tesla、Zoox、Avride、Motionalといった企業もWaymoを追走しているが、The VergeのAndrew J. Hawkins記者によるインタビューでは、Ferguson氏がこの状況を「後発の有利さ」として前向きに捉えていることが明らかになった。 「セカンドムーバーという視点には大きな価値がある。Waymoへのリスペクトは非常に大きい。稀に彼らが課題に直面しているケースでは、私たちはそれを自社システムの検証の機会として活用している」とFerguson氏はThe Vergeに語っている。 Waymoがゼロから試行錯誤しながら積み上げてきた運用上の知見——難しい交差点の処理、悪天候下での挙動、ライダーとのUX——は、後発企業にとって参照できる「実地事例集」でもある。Nuroはこれを活用して、Waymoが経験した失敗を繰り返さない設計を目指しているという。 Uberとの連携・年内のサンフランシスコ展開 NuroはUberプラットフォームを通じた配車サービスとして展開する計画で、2026年内にサンフランシスコでの商業サービス開始を目標に掲げている。すでに当地でのサービスに必要な許認可の第一号を取得しており、実現に向けた具体的な準備が進んでいる。 The Vergeのインタビューでは、Ferguson氏が初日から「幅広いシナリオに対応できる実用的なサービス」として立ち上げる方針を示した。「保護された交差点のみから始めて段階的に追加していく」という超インクリメンタルな戦略は取らないとしており、高速道路走行などの一部機能は後日追加になる可能性はあるものの、サービス開始時点で十分な実用性を持たせる考えだという。 また、自動運転技術のライセンス提供も事業の柱として位置付けており、先進運転支援システム（ADAS）や個人所有の自律走行車向けに技術を外部販売していく方針も示されている。 日本市場での注目点 現時点でNuroは米国市場に注力しており、日本での展開は発表されていない。ただし、日本においても自動運転タクシーへの関心は高まっており、トヨタやホンダが参入を検討しているほか、ティアフォーなどが国内での実証実験を進めている。 NuroのUber連携モデルは、既存の配車プラットフォームを活用して素早く利用者基盤を拡大するアプローチとして注目に値する。日本でも同様のモデルが展開される可能性は否定できず、配車プラットフォームがどのようにロボタクシーサービスを組み込むかは今後の重要な動向となるだろう。 自動運転技術のライセンスビジネスという観点では、国内自動車メーカーとの提携可能性もある。Waymoとは異なりNuroはまだ新興プレイヤーだが、Googleの自動運転プロジェクト出身者が率いる技術企業として、業界内での技術力への評価は高い。 筆者の見解 Nuroの「セカンドムーバー戦略」は、自動化・AI領域における現実的なキャッチアップ手法として興味深い。フロントランナーが膨大なコストとリスクを負いながら切り開いた道を、後発が参照できるという構造は、技術の成熟局面ではしばしば有効に機能する。 ただし、「後発の優位性」が実際に機能するかどうかは、Nuroが観察した知見をシステムにどれだけ深く組み込めるかにかかっている。Waymoが積み重ねた実走データの絶対量は圧倒的であり、「観察して学ぶ」だけでその差を埋めることは容易ではない。 むしろ筆者が注目するのは、Uberという既存プラットフォームを活用して需要側のハードルを下げた点だ。自前でライダーを獲得するコストをUberに委ねることで、事業の立ち上げ速度と初期の利用者基盤を同時に確保できる。この「統合プラットフォーム活用」の発想は、部分最適を積み重ねるよりも全体として合理的な戦略と言える。 年内のサンフランシスコ展開が予定通り進むかどうか、そして「後発の利点」がWaymoとの差を本当に縮められるかが、2026年後半の自動運転業界を占う上での重要な観察ポイントになるだろう。 出典: この記事は Why Nuro thinks being a robotaxi ‘second mover’ gives it an advantage の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Engadgetが2026年5月24日に報じたところによると、トランプ政権は行政府に支給される全スマートフォンにホワイトハウス公式アプリを強制インストールする計画を進めている。情報源はGovernment Executive（以下、Gov Exec）が入手した内部メールで、少なくとも1つの省庁では翌週にも展開が始まる見込みだという。対象は「行政府の全政府支給モバイル端末」とされており、影響範囲は相当広い。 ホワイトハウス公式アプリとは このアプリは約2ヶ月前にリリースされ、「情報源から直接届く、フィルタリングなしのリアルタイム更新」を提供することを謳っている。コンテンツとしてはプレスリリース、公式メディア映像、厳選されたニュース記事や統計データが含まれる。また「トランプ大統領にテキストを送る」機能も用意されているが、Gov Execの報道によると実際にはマーケティングメールのサインアップに誘導される仕組みになっているという。 Gov Execが確認した内部メールによれば、政府職員のデバイスに導入されるのは一般公開版と同一のアプリであり、連邦政府職員向けの追加機能は提供されない見通しだ。ホワイトハウスの広報担当Olivia Wales氏は同メディアに対し、「政府デバイスには通常、職員の日常業務に価値をもたらすプレインストールアプリが含まれる」とコメントしている。 専門家が指摘するプライバシー・セキュリティリスク Engadgetの報道では、複数のサイバーセキュリティ専門家がこのアプリに潜むリスクを指摘している。3月のリリース直後から、アプリが位置情報のトラッキングを実施していること、および第三者へのデータ共有の可能性についての懸念が複数の早期報告で指摘されていた。今回、政府支給デバイス全体への展開が現実となれば、セキュリティ上の攻撃面（アタックサーフェス）がさらに拡大するリスクがあると専門家は警戒している。 日本市場での注目点 このニュースは日本国内の特定製品に直接関係するものではないが、政府・企業のITガバナンスとエンドポイントセキュリティという観点で重要な示唆を含んでいる。日本の中央省庁や自治体でも、職員デバイスのMDM（モバイルデバイス管理）運用やアプリ審査プロセスは継続的な課題だ。「特定アプリの組織的な強制インストール」をめぐるポリシー設計の問題は、IT担当者・セキュリティエンジニアにとって参考となるケーススタディとして注目に値する。 筆者の見解 エンタープライズITの常識から見ると、今回の展開判断にはいくつかの疑問符がつく。業務デバイスへのアプリ展開は通常、MDMポリシーによる精査、データ取り扱い審査、セキュリティ評価というプロセスを経る。位置情報トラッキングやデータ共有のリスクがリリース直後から複数の専門家に指摘されているアプリを、十分な審査なく全行政府に展開するのは、技術的な根拠よりも政治的な動機が先行しているように見える。 Engadgetが「ダウンロード数を増やす方法の一つ」と皮肉交じりに伝えているのは的を射ているが、笑い飛ばせる話ではない。組織が管理するデバイス上で何が収集・送信されているかは、セキュリティエンジニアリングとプライバシー保護の両面で真剣に扱われるべきテーマだ。アプリの機能そのものよりも、「リスク評価を経ない強制展開」というプロセスこそが問題の核心であり、自組織のデバイス管理ポリシーを見直す際の反面教師として記憶しておきたい事例である。 出典: この記事は The White House is reportedly forcing its official app onto all government employee phones の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年3月、Microsoft Entra IDにおいてOpenID Connect（OIDC）標準に基づく外部MFA（External MFA）を一般提供（GA）として正式リリースした。これにより、組織が使用するサードパーティのMFAソリューションをConditional Access（条件付きアクセス）ポリシーと統合できるようになった。 外部MFAとは何か 従来のMicrosoft Entra IDでは、「Custom Controls」という機能でサードパーティ連携は可能だったものの、Conditional Accessポリシーとの統合が限定的で、細かなポリシー制御に制約があった。 外部MFAはこの制約を解消する。OIDCを通じてサードパーティのMFAプロバイダーと認証フローを統合し、Entra IDが認証要求を評価したうえでユーザーを外部プロバイダーに誘導する。検証後はEntra ID側で最終的なアクセス判断を下す——つまりポリシー制御の中枢はあくまでEntra IDに集約される設計だ。 設定と運用の仕組み 設定後、外部MFAはテナントの認証メソッドポリシーに「外部認証メソッド設定」として追加される。管理者は特定のユーザーグループへの適用・除外を柔軟に制御でき、組み込みの認証オプションと並べて管理できる。 外部プロバイダーが認証中にユーザー情報にアクセスするには、管理者の同意（Admin Consent）の付与が必要だ。この点はセキュリティ上の重要なポイントであり、実装前に社内ポリシーのレビューを行っておきたい。 MicrosoftのPrincipal Product Lead、Swaroop Krishnamurthy氏は「サインイン頻度とセッション制御を適切に調整すれば、再認証とユーザー生産性のバランスを取れる」とコメントしている。一方で「過剰な再認証はフィッシングリスクを高める可能性がある」とも警告しており、ポリシーの適切なチューニングが不可欠だ。 主なユースケース 外部MFAが特に力を発揮するのは以下のシナリオだ： M&A（合併・買収）シナリオ: 買収先企業が既存のMFAインフラを持っている場合、完全移行前の過渡期でもシームレスな認証統合が実現できる 規制・コンプライアンス要件: 特定のMFAソリューション使用を義務付けるセクター規制（金融・医療等）への対応 既存MFAインフラの維持: オンプレミスやSaaSで稼働中のMFAソリューションをEntra IDに統合し、ユーザー体験を統一する 【重要】2026年9月30日 Custom Controls廃止——移行は今すぐ着手を 既存のCustom Controls機能は2026年9月30日に廃止予定。現在使用中の設定は移行期間中は動作し続けるが、移行ガイダンスは廃止日前にMicrosoftが公開予定だ。 Custom Controlsを利用中の組織は早急に移行計画を立てることを強く推奨する。特に規模の大きい組織ではテスト・パイロット運用に相応の時間が必要になるため、「そのうちやる」は危険な先送りになる。 日本のエンジニア・IT管理者への実務インパクト 移行チェックリスト（Custom Controls利用中の場合） 現状把握: Entra IDの認証メソッドポリシーからCustom Controls設定を洗い出す 外部プロバイダーの対応確認: 利用中のサードパーティMFAベンダーが外部MFA（OIDC）に対応しているか確認 テスト環境での検証: パイロットグループを設定して動作検証を実施 ポリシーチューニング: サインイン頻度・セッション制御の再調整 本番移行と監視: ログ・サインインレポートで異常を早期検知 ゼロトラスト戦略との整合性 外部MFAはConditional Accessによる中央集権的なポリシー管理を維持したまま外部ソリューションと統合できる点で、ゼロトラストアーキテクチャとの相性が非常に良い。「認証はどのプロバイダーでも、ポリシー判断はEntra IDで一元化」という分離は、ネットワーク境界に依存しないIDベースのアクセス制御原則と自然に整合する。 筆者の見解 外部MFAのGA化は、Entra IDが企業のIDプラットフォームとして成熟していることを示す好例だと感じている。MFAの選択肢を外部に開きながらもポリシー制御をEntra IDに集約する設計は、M&Aや業界規制が絡む現実の企業IT環境をよく理解した実装だ。 ゼロトラスト推進の観点から言えば、「どのMFAを使うか」よりも「ポリシー評価と認可判断がどこで行われるか」のほうが本質的に重要だ。その中枢をEntra IDに置いたまま選択肢を広げられるのは理にかなっている。 ひとつ実務的な注意点を加えると、Admin Consentの管理とConditional Accessポリシーの再設計には相応の工数が伴う。Custom Controls廃止まで6ヶ月を切っているいま、日本の大規模エンタープライズが先送りするリスクは小さくない。廃止日という明確な締め切りがある以上、今月中に着手計画を立てることを強くすすめたい。Entra IDには正面から勝負できる実力が備わっている。その力を使いこなせるかどうかは、運用側の準備次第だ。 ...