Tech News JP

Linux 7.0開発が最終段階へ、RC5でドライバ・コア更新が一段落 Linuxカーネルの次期メジャーバージョン「Linux 7.0」の開発が安定期に入った。開発者のLinus Torvalds氏は、第5リリース候補版（RC5）の公開にあわせてメーリングリストへのメッセージを投稿し、「今週は比較的穏やかだった」と開発状況を評価した。 ドライバとコアの大規模更新を経て落ち着き 直前のRC4までは、各種デバイスドライバやカーネルコアへの変更が集中的に取り込まれる慌ただしい時期が続いていた。RC5では新たな問題報告も減少し、主にバグ修正と細かな最適化が中心となっている。これはリリース候補サイクルとして正常な推移であり、最終リリースへのカウントダウンが始まったと見てよい。 Linux 7.0が持つ意味 Linuxカーネルのバージョン番号は、6.x系が2022年の6.0リリースから続いており、7.0への移行はメジャーバンプとして注目を集めている。ただし、Linuxのバージョン番号は純粋に「キリが良くなったから」という慣例的な理由で上がることも多く、7.0だからといって技術的な断絶があるわけではない。それでも、サーバー・組み込み・デスクトップ問わずLinuxを利用する日本企業や開発者にとって、新しいドライバサポートやパフォーマンス改善は実用上の恩恵をもたらす。 今後のスケジュール Linuxカーネルの開発サイクルは通常、RC1からRC7〜8程度を経て正式版がリリースされる。RC5が「穏やか」な状態であれば、残り数週間のうちに正式版がリリースされる見通しだ。Torvalds氏は引き続きRC6以降の進捗をメーリングリストで報告する予定。 UbuntuやFedora、Arch Linuxなど主要ディストリビューションへの搭載は、それぞれのリリーススケジュールに依存するが、Linux 7.0の動向は今後のディストリビューション選定にも影響を与えそうだ。 元記事: Linux 7.0 development stabilizes as Linus Torvalds reports calmer fifth release candidate

ChromeのABE保護を新手法で突破する「VoidStealer」が登場 セキュリティ研究機関のGen Digital（Norton・Avast・AVG・Aviraの親会社）は、情報窃取型マルウェア「VoidStealer」がGoogle ChromeのApplication-Bound Encryption（ABE）をこれまでにない手法で回避していることを報告した。 ABEとは何か Googleは2024年6月リリースのChrome 127でABEを導入した。これはCookieや認証トークンなどの機密データを保護する仕組みで、マスターキーをディスク上で暗号化したまま保持し、通常のユーザーレベルのアクセスからは復号できないようにしている。復号にはSYSTEM権限で動作する「Google Chrome Elevation Service」による検証が必要だ。 しかしABEはこれまでも複数のインフォスティーラーやオープンソースツールによって回避されてきた歴史がある。Googleは都度修正を施してきたものの、新たな手法による回避が繰り返されている。 ハードウェアブレークポイントによる新たな攻撃手法 VoidStealerのアプローチが特異なのは、特権昇格もコードインジェクションも必要としない点だ。Gen Digitalの脅威研究者ヴォイチェフ・クレイサ氏によれば、本マルウェアは「野外で観測された中で初めて、ハードウェアブレークポイントを利用してブラウザのメモリから直接v20_master_keyを抽出するデバッガーベースのABE回避技術を採用したインフォスティーラー」だという。 具体的な手順は次のとおりだ。 サスペンド状態の隠しブラウザプロセスを起動し、デバッガーとしてアタッチ 対象のDLL（chrome.dllまたはmsedge.dll）のロードを待機 DLL内の特定文字列とLEA命令を走査し、ハードウェアブレークポイントを設置 ブラウザ起動時にABE保護データが復号されるタイミングでブレークポイントが発火 ReadProcessMemoryでレジスタから平文のv20_master_keyを読み取り抽出 ブラウザ起動時は保護されたCookieを早期に読み込むためマスターキーの復号が強制的に発生する。VoidStealerはこの「一瞬だけ平文でメモリに存在する状態」を狙い撃ちにする。 オープンソースツール「ElevationKatz」との関係 Gen Digitalの分析では、この手法はChromeのCookieダンプツールセット「ChromeKatz」に含まれるオープンソースプロジェクト「ElevationKatz」をベースにしている可能性が高いとしている。ElevationKatzは1年以上前から公開されており、VoidStealerはそれを攻撃者向けに実装し直したとみられる。 MaaSとして拡散中 VoidStealerはMalware-as-a-Service（MaaS）として2025年12月中旬からダークウェブフォーラムで販売されており、バージョン2.0でこの新しいABE回避機能が追加された。 対策と今後の展望 BleepingComputerはGoogleにコメントを求めたが、本稿執筆時点では回答は得られていない。特権昇格不要・コードインジェクション不要という特性から、従来のエンドポイント検出との相性が悪く、検知が難しい攻撃手法といえる。ブラウザに保存された認証情報やCookieへの依存を減らし、ハードウェアセキュリティキーやパスキーの活用を検討することが望ましい。 元記事: VoidStealer malware steals Chrome master key via debugger trick

Microsoftは2026年3月21日、Microsoftアカウントのサインインが失敗する深刻な不具合を修正する緊急更新プログラム「KB5085516」を公開した。 不具合の概要 今月のパッチチューズデー（定例セキュリティ更新）として配信された累積更新プログラム「KB5079473」を適用後、Teams、OneDrive、Microsoft Edge、Microsoft 365 Copilot、ExcelやWordなどのOfficeアプリでサインインができなくなる事象が報告されていた。 エラーメッセージには「インターネット接続が必要です。インターネットに接続されていないようです（You’ll need the Internet for this. It doesn’t look like you’re connected to the Internet.）」と表示されるが、実際にはデバイスはインターネットに正常に接続されており、誤検知であることが判明している。 影響を受けるユーザー この問題はMicrosoftアカウント（個人・Teams無料版など）を使用している場合のみ発生する。企業環境でEntra ID（旧Azure Active Directory）を使って認証している場合は影響を受けない。 日本でも個人利用や中小企業でMicrosoftアカウントを利用しているケースは多く、特に「Teams無料版」を業務で活用しているユーザーは注意が必要だ。 修正方法 Microsoftは暫定的な回避策として「PCを再起動する」ことを案内していたが、今回のKB5085516の適用により根本的な修正が提供された。 更新プログラムはWindows 11バージョン25H2および24H2を対象としており、以下の方法で適用できる。 Windows Update：設定 → Windows Update から「更新プログラムのチェック」 Microsoft Update カタログ：手動でKB5085516を検索してダウンロード なお、今回の更新にはパッチチューズデーで配信されたすべてのセキュリティ修正も含まれている。 相次ぐ緊急パッチ 今月のパッチチューズデー以降、Microsoftは複数の緊急対応を余儀なくされている。Bluetoothデバイスの認識問題やRRAS（ルーティングとリモートアクセスサービス）のセキュリティ脆弱性に対するホットパッチ、さらに一部のSamsung製Windows 11ノートPCでCドライブにアクセスできなくなる問題への対処など、異例の頻度で修正が続いている。 Windows Updateを自動更新に設定していないユーザーは、手動での適用を強く推奨する。 元記事: New KB5085516 emergency update fixes Microsoft account sign-in

CISA、DarkSword関連のiOS脆弱性3件を「積極的に悪用されている脆弱性カタログ」に追加 米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は、iOSの脆弱性3件を「積極的に悪用されている既知の脆弱性（KEV）カタログ」に追加し、連邦文民行政府（FCEB）機関に対して2週間以内——具体的には2026年4月3日まで——のパッチ適用を義務付けた。 DarkSwordとは何か DarkSwordは、iPhoneを標的とした高度なエクスプロイト配信フレームワークだ。先週、Googleの脅威インテリジェンスグループ（GTIG）とセキュリティ企業iVerifyの研究者が詳細を公開した。このフレームワークは合計6件の脆弱性チェーン（CVE-2025-31277、CVE-2025-43529、CVE-2026-20700、CVE-2025-14174、CVE-2025-43510、CVE-2025-43520）を組み合わせて利用し、サンドボックス回避・権限昇格・リモートコード実行を可能にする。 Appleはすでに最新のiOSリリースで全脆弱性を修正済みだが、iOS 18.4〜18.7を実行しているiPhoneはいまだ影響を受けるため、迅速なアップデートが求められる。 3つのマルウェアファミリーと攻撃グループ GTIGの調査によると、DarkSwordを通じて感染端末に投下されるマルウェアは以下の3種類だ。 GhostBlade — 非常に攻撃的なJavaScriptベースの情報窃取型マルウェア GhostKnife — 大量のデータを外部に持ち出すバックドア GhostSaber — コード実行とデータ窃取を兼ねるJavaScript型マルウェア 攻撃グループとしては、トルコの商用スパイウェアベンダー「PARS Defense」の顧客とされるUNC6748と、ロシアのスパイ活動グループと疑われるUNC6353が関与していることが判明している。UNC6353はウォータリングホール攻撃を展開しており、ウクライナのECサイト・産業機器・地域サービス系のウェブサイトを侵害してiPhoneユーザーを狙っていた。 また、DarkSwordは感染後に一時ファイルを消去して終了する設計になっており、短期間の監視オペレーションと検知回避を意図した作りになっていると研究者らは指摘する。 CISAの対応と民間企業への呼びかけ CISAは今回、6件の脆弱性のうちCVE-2025-31277、CVE-2025-43510、CVE-2025-43520の3件をKEVカタログに登録。拘束的運用指令（BOD 22-01）に基づき、FCEB機関に対して「ベンダー指示に従ったパッチ適用、またはクラウドサービス向けBOD 22-01ガイダンスの遵守。緩和策が利用できない場合は製品の使用を中止すること」と警告した。 BOD 22-01の適用対象は連邦機関に限られるが、CISAは民間企業を含むすべての組織に対しても、できる限り早急にデバイスを保護するよう強く求めている。 日本のユーザーへの影響 iPhoneは日本国内でも高いシェアを持つ。iOS 18.4以降を使用しているユーザーは、設定アプリから「一般」→「ソフトウェアアップデート」を確認し、最新バージョンへのアップデートを今すぐ行うことが推奨される。特に企業のモバイルデバイス管理（MDM）担当者は、管理下にある端末のOSバージョンを速やかに確認してほしい。 元記事: CISA orders feds to patch DarkSword iOS flaws exploited attacks

FBIが緊急警告：TelegramがC2インフラに悪用されるイラン系サイバー攻撃 米連邦捜査局（FBI）は3月23日、イランの情報省（MOIS）と連携するハッカーグループが、マルウェア攻撃のコマンド＆コントロール（C2）インフラとしてメッセージングアプリ「Telegram」を悪用していると警告を発した。 攻撃の概要 FBIのフラッシュアラートによると、このTelegramを利用したC2インフラは、イラン政府を批判するジャーナリスト、イラン反体制派、および世界各地の反政府組織を標的としたWindowsマルウェアに組み込まれているという。 攻撃者はソーシャルエンジニアリングの手口で標的のデバイスにマルウェアを感染させ、スクリーンショットやファイルの窃取（exfiltration）を実行する。感染後の被害はスパイ活動による情報収集、データ漏洩、そして標的組織の評判失墜に及んでいる。 関与が疑われる脅威アクター FBIは以下の2グループを今回の攻撃に関与するとして特定した： Handalaハクティビストグループ（別名：Handala Hack Team、Hatef、Hamsa）：イランと連携する親パレスチナのハクティビスト集団 Homeland Justice：イラン・イスラム革命防衛隊（IRGC）と紐付けられた国家支援型の脅威アクター 押収されたドメインとStryker攻撃との関連 今回の警告は、FBIが4つのドメイン（handala-redwanted[.]to、handala-hack[.]to、justicehomeland[.]org、karmabelow80[.]org）を押収した翌日に公表された。これらのサイトはHandala、Homeland Justice、および「Karma Below」という第三の脅威アクターが米国内外の被害者から盗んだ機密文書やデータの漏洩に利用していた。 一連の動きの背景には、Handalaによる米国医療大手Stryker社への大規模サイバー攻撃がある。攻撃者はWindowsドメイン管理者アカウントを侵害して新たなグローバル管理者アカウントを作成、Microsoft Intuneのワイプコマンドを悪用して社員の個人PCやモバイルデバイスを含む約8万台のデバイスを工場出荷状態にリセットするという壊滅的な被害をもたらした。 ロシア系攻撃との並行性 同週、FBIはロシア情報機関と連携した脅威アクターによるSignalおよびWhatsAppユーザーを標的にしたフィッシングキャンペーンについても警告を発しており、すでに数千件のアカウント侵害が確認されている。標的は現・元米政府高官、軍関係者、政治家、ジャーナリストなど「高い諜報価値を持つ個人」とされている。 防御のポイント FBIは中東の地政学的緊張の高まりを背景に、この種の攻撃が今後も継続・拡大する可能性を示唆。ネットワーク防御担当者に対し、不審なTelegramとの通信のモニタリングや多要素認証（MFA）の徹底など、具体的な緩和策の実施を促している。 日本国内でも反政府的・政治的な活動を行う組織や研究者、ジャーナリストがターゲットになり得るため、同様の脅威インテリジェンスに注視することが求められる。 元記事: FBI warns of Handala hackers using Telegram in malware attacks

「なぜ誰もWindowsネイティブアプリを書かないのか」——現役開発者が語る混沌の実態 Chromiumの開発に携わったこともあるベテラン開発者のDomenic氏が、自作のWindowsユーティリティ「Display Blackout」を開発した経験をもとに、Windowsネイティブアプリ開発の現状を赤裸々に語ったブログ記事が、Hacker Newsで400以上のポイントを獲得し大きな反響を呼んでいる。 マルチモニター環境向けユーティリティを作ってみたら…… Display Blackoutは、3画面環境でゲームプレイ中に左右のモニターを「ブラックアウト」するシンプルなツールだ。OLEDディスプレイでは真っ黒な画面を表示することで実質的にピクセルをオフにできる。機能要件は、ディスプレイの列挙、ボーダーレスウィンドウの配置、グローバルホットキー、スタートアップ起動、設定の永続化、システムトレイアイコンの表示——いずれもシンプルに見える。 しかし開発を始めると、技術選択の段階から地獄が口を開けていた。 Windowsプログラミングの「地層」 WindowsのUI開発スタックは、歴史的な地層のように積み重なっている。 Win32 API（1990年代〜）: C言語ベースの原始的なAPI。今も現役で使われている MFC（Microsoft Foundation Classes）: C++でWin32をラップしたライブラリ Windows Forms（.NET 1.0 / 2002年）: Win32コントロールのC#ラッパー WPF（.NET 3.0 / 2006年）: XAMLによるマークアップとGPUレンダリングを導入した刷新版 UWP（Universal Windows Platform / 2015年）: Windows 10向けの「次世代」プラットフォーム WinUI 3（2021年〜）: UWPのUIレイヤーを切り出したもの 問題は、これらが互いに競合し、それぞれ異なる制限を抱えており、Microsoftが何度も「これが未来だ」と宣言しながら方針転換を繰り返してきた点だ。 UWPという「失われた10年」 特に批判が集中するのがUWP（ユニバーサルWindowsプラットフォーム）だ。Windows 10と同時に登場し、Microsoftが全力で推進したにもかかわらず、サンドボックス制限の厳しさや既存APIとの非互換性から開発者に敬遠され、事実上の失敗に終わった。Win32 APIの多くの機能がUWPサンドボックスから使えず、グローバルホットキーのような基本的な機能の実装にすら回り道が必要だった。 なぜElectronが選ばれるのか この混沌が、Electron（Webテクノロジーを使ったデスクトップアプリフレームワーク）が広く普及した理由を雄弁に物語っている。VS Code、Slack、Discord——著名なデスクトップアプリの多くがElectronを採用しているのは偶然ではない。メモリ消費が大きいという批判はあれど、単一のコードベースでクロスプラットフォーム対応でき、Web標準という安定した基盤の上に乗れるというメリットは絶大だ。 日本の開発者への示唆 Windowsデスクトップアプリを業務システムとして開発・保守している日本企業にとっても、この問題は他人事ではない。WPFで書かれた社内ツールがWinUI 3へ移行できずにいる、UWPで開発した資産が宙ぶらりんになっているといった状況は珍しくない。Microsoftが「次世代」を何度宣言しても、10年後に同じ問題に直面する可能性は十分にある。 Microsoftには、開発者が安心して長期投資できる一貫したビジョンが求められている。 元記事: Windows native app development is a mess

Microsoft Entra ID バックアップ＆リカバリー、静かにプレビュー開始 Microsoftは2026年3月19日、Entra IDオブジェクトのバックアップと復元を行う新機能「Microsoft Entra Backup and Recovery」のプレビューをテナントに展開した。Entra管理センターから利用できるが、大々的なアナウンスはなく、技術コミュニティで話題になってから翌20日にRSAカンファレンス向け発表の中でさりげなく言及されるという異例のデビューとなった。 何がバックアップされるのか 対象となるのは「コアテナントオブジェクト」と呼ばれるディレクトリの根幹部分だ。具体的には以下が含まれる： ユーザー・グループ アプリケーション・サービスプリンシパル 条件付きアクセスポリシー 認証メソッド・承認ポリシー 名前付き場所・組織設定 Exchange OnlineやSharePoint Onlineのようにメールやファイルデータを抱えるワークロードとは異なり、Entra IDはオブジェクトの構成情報が主体のため、同等の機能をより少ないストレージで実現できる。 バックアップの仕様 頻度: 1日1回自動実行（時刻はテナントごとに異なり、現時点では変更不可） 保持数: 直近5世代（最大5日分）のローリング保持 無効化: プレビュー段階では不可、すべて自動 必要ライセンス: Entra P1 または P2（一部テナントではライセンス不問でも利用可能との報告あり） 必要ロール: 新設の「Entra Backup Reader」管理ロール 差分レポートで復元判断を支援 特徴的なのが差分レポート機能だ。現在のオブジェクト状態と選択したバックアップ時点との差分をレポートとして生成し、「どのバックアップから復元すべきか」の判断材料を提供する。 例えば、エンタープライズアプリ（サービスプリンシパル）が不正に追加された場合、差分レポートにはそのオブジェクトが表示され、復元操作では「ソフトデリート（論理削除）」が実行される。誤操作を防ぐため、復元処理がハードデリートを行うことはない。 現時点での課題として、レポート生成に時間がかかる点が挙げられている。小規模テナントでも75分以上を要するケースが確認されており、GA（一般提供）に向けた改善が期待される。 日本のテナント管理者への影響 Microsoft 365を利用する日本企業にとって、Entra IDのオブジェクト保護は長年の課題だった。ランサムウェア攻撃や誤操作によるアカウント・ポリシーの破損は深刻なインシデントにつながりうるが、従来は条件付きアクセスポリシーなどの設定を手動でバックアップするか、サードパーティ製品に頼るしかなかった。 Microsoft純正の自動バックアップ機能が追加されることで、基本的な保護はプラットフォーム側が担う形になる。一方、5日間という保持期間はコンプライアンス要件によっては不十分な場合もあり、より長期の保持ニーズへの対応は今後の課題だ。 GA（一般提供）の時期や追加機能については、今後のアナウンスに注目したい。 元記事: Low-Key Debut for Entra ID Backup and Recovery

AIコード生成の評価問題を「実行」で解決 AIが生成したコードの品質を正確に評価するのは、実は非常に難しい問題だ。コードが文法的に正しく見えても、実際に動かしてみると想定外のバグが潜んでいたり、エッジケースで失敗したりすることは珍しくない。 この課題に取り組むため、Hugging FaceのBigCodeチームはBigCodeArenaを発表した。「人間参加型（Human-in-the-Loop）」のコード生成モデル評価プラットフォームとして、これが初めての試みとなる。 従来のベンチマークの限界 これまでのコード生成評価には主に2つのアプローチがあった。 HumanEval等のベンチマーク: あらかじめ用意されたテストケースでコードを採点するが、現実の多様なプログラミングタスクのごく一部しかカバーできない 人手評価: ソースコードを読んで頭の中で実行をシミュレートするのは認知負荷が高く、複雑なUIアプリや長いプログラムになるほど精度が落ちる たとえば「レスポンシブなフォトギャラリーサイトを作って」と2つのAIに頼んだとき、両方のコードが一見正しく見えても、実際にブラウザで表示して初めて違いが分かることがある。片方は美しいグリッドレイアウトを実現し、もう片方はスタイリングのバグで崩れているかもしれない。実行なしには判断できないのだ。 BigCodeArenaの仕組み BigCodeArenaはLMArena（Chatbot Arena）のフレームワークを拡張し、コード評価特有の機能を追加している。 リアルタイム実行とサンドボックス環境 生成されたコードはすべて、分離されたサンドボックス環境で自動実行される。Pythonスクリプト、ReactのWebアプリ、PyGameのゲーム、C++のアルゴリズムなど、ソースコードではなく実際の出力結果をユーザーが確認できる。 幅広い言語・フレームワーク対応 現在サポートされている言語・環境は以下の通り。 対応言語（10種）: Python、JavaScript、TypeScript、HTML、C、C++、Java、Go、Rust、Markdown Webフレームワーク: React、Vue、バニラHTML/CSS/JS Pythonフレームワーク: Streamlit、Gradio、PyGame 図表: Mermaid 汎用インタープリタ: PythonおよびJavaScriptのコードインタープリタ、コンパイル言語ランナー インタラクティブなテスト Webアプリのボタンをクリックしたり、生成されたゲームをプレイしたり、コードを直接編集して再実行したりと、静的なコード比較では不可能なインタラクティブな検証が可能だ。 マルチターン対話 現実のプログラミング作業と同様に、要件の追加や機能変更、バグ修正の依頼といったマルチターンの対話にも対応している。 5カ月で見えてきた傾向 2025年2月の公開から約5カ月間で、500人以上のユニークユーザーから14,000件以上の会話データと4,700件以上の高品質な優劣投票が集まった。最先端LLM（大規模言語モデル）10種類が評価対象となっている。 ユーザーが持ち込むタスクの内訳は多岐にわたる。 Webデザイン（36%）: レスポンシブなWebサイト、インタラクティブなダッシュボード 問題解決（23%）: アルゴリズム、データ構造、計算チャレンジ ゲーム開発（16%）: ゲームロジックやUIの実装 日本の開発者コミュニティへの示唆 BigCodeArenaは誰でも無料で利用でき、コミュニティの投票結果がリーダーボードとして公開される。GitHub CopilotやCursorといったAIコーディング支援ツールを日常的に使う開発者にとって、「どのモデルが実務で最も役立つか」を判断する際の参考資料として活用できるだろう。 日本語でのコード生成評価については今後の展開が注目されるが、まずはコード評価の新たなスタンダードとなりうる取り組みとして、その動向を追っていきたい。 元記事: BigCodeArena: Judging code generations end to end with code executions

Hugging FaceとVirusTotal、AIモデルのセキュリティ強化で連携 オープンソースAIプラットフォームのHugging Faceは、世界最大規模の脅威インテリジェンス・マルウェア分析プラットフォーム「VirusTotal」との連携を発表した。この取り組みにより、Hugging Face Hub上で共有される全ファイルのセキュリティが強化される。 220万超のモデルが継続的にスキャン対象に 現在、Hugging Face Hubには220万を超える公開モデル・データセットリポジトリが存在する。今回の連携により、これら全リポジトリのファイルがVirusTotalのデータベースと照合され、継続的にセキュリティチェックが行われる。 ユーザーがリポジトリやファイルのページを訪問すると、Hubは自動的にVirusTotalから対応ファイルの情報を取得し、結果を表示する仕組みだ。 AIモデルが持つセキュリティリスク AIモデルは強力なツールである一方、大規模なバイナリファイルやシリアライズされたデータ、依存ライブラリなどを含む複雑なデジタル成果物でもある。具体的な脅威として以下が挙げられている。 モデルファイルやアーカイブに偽装した悪意あるペイロード アップロード前にすでに改ざんされたファイル 既知のマルウェアキャンペーンに関連するバイナリ ロード時に危険なコードを実行するシリアライズオブジェクト Pickle形式など機械学習でよく使われるシリアライゼーション形式は、任意コード実行の脆弱性が以前から指摘されており、セキュリティ上の懸念は日本のAI開発現場でも共有されている課題だ。 プライバシーを守りながら脅威を検出 ファイルの検出方法はハッシュ照合方式を採用している。ファイルの内容そのものをVirusTotalに送信するのではなく、ファイルハッシュ値をデータベースと比較することで、ユーザーのプライバシーとデータ保護原則を維持しながら脅威情報を取得する。 過去にVirusTotalで解析済みのファイルであれば、そのステータス（クリーンか悪意あるか）、検出数、関連する脅威キャンペーン情報などが確認できる。 組織のCI/CDパイプラインへの統合も視野に この連携はエンドユーザーの安全確保にとどまらず、企業・組織のワークフローへの統合も想定している。CI/CDパイプラインやデプロイプロセスにVirusTotalのチェックを組み込むことで、悪意あるアセットの拡散を防ぐ仕組みが構築できる。 モデルのダウンロードや統合の前に脅威情報を確認できる透明性の向上、重複スキャンを減らす効率化、そしてオープンソースAIコミュニティ全体への信頼醸成が、この協業の主な目的となっている。 詳細や貢献については security@huggingface.co に問い合わせできる。 元記事: Hugging Face and VirusTotal collaborate to strengthen AI security

MetaとHugging Faceが共同で「OpenEnv Hub」を発表——AIエージェント時代の共通インフラへ MetaとHugging Faceは、AIエージェント開発のための共有オープンプラットフォーム「OpenEnv Hub」を共同で立ち上げると発表した。大規模言語モデル（LLM）を活用した自律型エージェントの開発・訓練・デプロイを効率化するための環境仕様を標準化し、開発者コミュニティ全体で共有できる場を目指す。 背景：エージェントに「環境」が必要な理由 現代のAIエージェントは、数千ものタスクを自律的にこなせるようになった。しかしLLMそのものだけでは不十分で、タスクを実際に実行するには適切なツールへのアクセスが欠かせない。かといって、膨大な数のツールをモデルに直接公開することは、安全性の観点からも非現実的だ。 ここで登場するのが「エージェント環境（Agentic Environment）」という概念だ。これはエージェントが特定タスクを実行するために必要なツール、API、認証情報、実行コンテキストを過不足なく定義したサンドボックスである。セマンティクスの明確化、安全な実行の保証、認証済みAPIへのシームレスなアクセスといった重要な役割を担う。 OpenEnvとは何か OpenEnvは、このエージェント環境を標準化するための仕様（Specification）だ。環境はstep()・reset()・close()といったシンプルなAPIで構成されており、Dockerベースのサンドボックスとして動作する。 Hugging Face上に設置されたEnvironment Hubでは、開発者が以下のことを行える： 仕様に準拠した環境をアップロード・共有する ブラウザ上で「ヒューマンエージェント」として環境を操作する モデルにタスクを解かせ、その挙動を観察する 環境が公開しているツールや観測定義を確認する Hub上でOpenEnv仕様に準拠した環境を公開するだけで、これらの機能が自動的に利用可能になる。本番RLトレーニングを走らせる前の検証・反復サイクルを大幅に短縮できる設計だ。 強化学習（RL）ポストトレーニングへの活用 OpenEnvは、TRL・TorchForge・VeRL・SkyRL・Unslothなど、既存のRL関連ライブラリとの統合が進められている。ポストトレーニング（SFTやRLHF後の追加訓練）において、多様な環境を横断してエージェントを訓練したり、FAIRの「Code World Model」のようなSOTA手法を再現したりするユースケースが想定されている。 日本のAI研究・開発コミュニティにとっても、標準化された環境仕様が普及すれば、エージェント研究の再現性や相互運用性が大きく向上する可能性がある。 RFC公開でコミュニティ主導の標準化へ 現在、以下の3つのRFCがレビュー中だ： RFC 001：Environment、Agent、Taskといったコアコンポーネントのアーキテクチャ定義 RFC 002：環境インターフェース、パッケージング、分離、通信方式の提案 RFC 003：MCP（Model Context Protocol）ツールの環境抽象化とカプセル化 オープンなRFCプロセスにより、仕様はコミュニティのフィードバックを受けながら進化する予定だ。AIエージェント開発の「共通語」となるOpenEnvの行方に注目したい。 元記事: Building the Open Agent Ecosystem Together: Introducing OpenEnv

本人の「同意」がなければ音声クローンは起動しない Hugging FaceのMargaret Mitchell氏とLucie-Aimée Kaffee氏は、音声クローン（Voice Cloning）技術に「ボイス同意ゲート（Voice Consent Gate）」を組み込む仕組みを提案した。これは、本人が明示的に同意フレーズを声に出して言わない限り、その人の声を模倣するモデルが起動しないという設計思想だ。 なぜ今、この提案なのか ここ数年で音声生成技術は飛躍的に進化した。わずか数秒の音声サンプルから、本人と聞き分けがつかないほど精巧なクローン音声を生成できる時代が到来している。 この技術には光と影がある。光の側面では、病気や事故で声を失った人が自分の声で再びコミュニケーションできるよう支援したり、外国語学習に活用したりといった恩恵がある。一方、影の側面では、米国でバイデン前大統領の音声が無断でロボコールに使用されるなど、「ディープフェイク音声」による情報操作リスクが現実の問題となっている。 技術的な仕組み ボイス同意ゲートは、以下の3つのコンポーネントで構成される。 ユニーク同意文の生成 — クローン対象の話者が読み上げる、その場限りの同意フレーズを動的に生成する（例：「私は〈モデル名〉の音声クローンモデルに対し、自分の声の使用に同意します」） 自動音声認識（ASR） — 話者が実際にそのフレーズを発話したかを検証する ボイスクローンTTS — 同意確認が取れた場合にのみ、入力テキストを話者の声で読み上げる 注目すべき観察として、最新の音声クローンシステムはわずか1文の音声でもクローン生成が可能なため、同意のために発話した文そのものをクローンの学習データとして兼用できるという点がある。マイクからのリアルタイム録音を必須とし、事前録音のアップロードを受け付けない設計にすることで、過去の音声流用リスクも低減している。 「同意」をシステムの前提条件にする この取り組みの本質は、音声クローンの問題解決にとどまらない。AIシステムの設計において、倫理的原則（この場合は「同意」）を抽象的なガイドラインではなく、動作の前提条件としてインフラに組み込むというアプローチの実証だ。 同意が行われたことは追跡・監査可能な形で記録されるため、透明性の確保にも寄与する。研究チームはデモと実装コードをHugging Face上で公開しており、この概念を出発点として議論を広げたいとしている。 日本でも音声ディープフェイクを悪用した詐欺被害が報告され始めており、技術と倫理の両面からの取り組みは今後ますます重要になるだろう。 元記事: Voice Cloning with Consent

IBMの超小型LLM「Granite 4.0 Nano」登場——エッジAI時代の新たな選択肢 IBMは2025年10月28日、同社のオープンLLMシリーズ「Granite 4.0」ファミリーの最小モデル群「Granite 4.0 Nano」を公開した。エッジデバイスやオンデバイスアプリケーション向けに設計されており、数百億パラメータを必要とせずに実用的な性能を発揮することを目指している。 4つのモデルバリアント Granite 4.0 Nanoは、以下の4つのInstructモデルとそれぞれのベースモデルで構成される。 Granite 4.0 H 1B：約15億パラメータ。ハイブリッドSSMアーキテクチャを採用した密なLLM Granite 4.0 H 350M：約3.5億パラメータ。同様にハイブリッドSSMベース Granite 4.0 1B / 350M：従来のTransformerアーキテクチャ版。llama.cppなどハイブリッドアーキテクチャの最適化が未対応の環境向け ハイブリッドSSM（State Space Model）アーキテクチャは、Transformerのアテンション機構とSSMを組み合わせたもので、長いコンテキスト処理において計算効率を高められると注目されている。 同規模モデルとの比較で際立つ性能 0.2B〜2Bパラメータクラスのモデルは、Alibaba（Qwen）、LiquidAI（LFM）、Google（Gemma）など多くのプレイヤーが参入する競争の激しい領域だ。IBMの発表によれば、Granite 4.0 Nanoは一般知識・数学・コード・安全性の各ベンチマークにおいて、同規模の競合モデルを上回る精度を達成したという。 さらに、AIエージェントワークフローで重要となる命令追従（IFEval）とツール呼び出し（BFCLv3）のベンチマークでも、同サイズクラスのモデルを超える結果を示しており、エッジ環境でのエージェント型AI活用が現実的な選択肢になりつつある。 Apache 2.0・ISO 42001認証で企業利用にも対応 Granite 4.0 NanoはApache 2.0ライセンスで公開されており、商用利用・改変・再配布が自由に行える。また、vLLM・llama.cpp・MLXといった主要ランタイムのネイティブサポートも備える。 IBMが取得しているISO 42001認証（AI管理システムに関する国際規格）の対象モデルでもあり、企業がガバナンスや規制要件を意識しながらAIを導入する際の信頼性向上にも寄与する。日本企業においても、AIガバナンスへの関心が高まる中で注目される点だ。 日本での活用シナリオ 350M〜1Bクラスの軽量モデルは、スマートフォンや産業用デバイス、プライバシー重視のオンプレミス環境など、クラウドAPIへの依存を避けたい場面で有力な選択肢となる。製造業や医療分野でのエッジAI活用を検討する日本企業にとっても、参照すべきモデルの一つになるだろう。 モデルの詳細はHugging Face上のモデルカードで確認できる。IBMはGranite 4.0ファミリーの拡充を継続する方針を示しており、今後の展開にも注目したい。 元記事: Granite 4.0 Nano: Just how small can you go?

AIリサーチエージェントが「知識労働の基盤」になる時代へ AI検索ツールを提供するTavilyは、同社が開発する最先端のリサーチエージェント「Deep Research」の構築プロセスで得た知見を詳細に公開した。 リサーチ（情報収集・読解・統合）は、文章作成・意思決定・コーディングに至るあらゆる知識労働の基盤となる作業だ。しかし人間によるリサーチは、記憶容量・読むスピード・時間という制約から逃れられない。一方、AIリサーチエージェントは膨大な情報を処理し、インサイトを瞬時に統合し、スケールアップも容易だ。Tavilyはこうしたエージェントが、コンテンツ生成・コーディング・営業など広範なワークフローの中核サブコンポーネントになると見ている。 「複雑さ」は罠だった——最初のアーキテクチャを全破棄した教訓 Tavilyが最初に陥った失敗は、「洗練された複雑なアーキテクチャ」への過信だった。7か月前に構築した初代システムは精巧に設計されていたが、次世代モデルが登場した際に設計上の前提がボトルネックになり、システム全体を作り直す羽目になったという。 この経験から生まれた設計原則が「将来のモデル性能向上を吸収できる柔軟な設計」だ。具体的には、オーケストレーションロジックを極力シンプルに保ち、モデルの自律性に委ねること、そしてモデルやツールが何に最適化されているかを注視しながらその新興能力を活かすことを重視するようになった。 コンテキスト管理こそが成否を分ける Tavilyが特に力を入れたのが「コンテキストエンジニアリング」だ。長時間にわたるリサーチタスクでは、コンテキストウィンドウをクリーンかつ最適な状態に保つことが最大の課題となる。これを怠ると、エージェントはほぼ確実に失敗する、とTavilyは断言する。 その解決策として同社が採用したのが、自社の「Advanced Search」機能によるコンテキスト管理済みのWeb検索だ。生のWebコンテンツを処理する複雑さを抽象化し、最も関連性の高いコンテンツのみをエージェントに返すことで、ハルシネーション（幻覚）の低減とレイテンシの改善を実現している。 ツールとモデルは「エージェントハーネスのために進化すべき」 Tavilyは、モデルとツールの双方がAIエージェント開発者の課題解決に向けて進化していくべきだと主張する。モデルに期待するのは、コンテキスト圧縮のための高再現率サマリー生成・ツール呼び出しの信頼性向上・簡潔な文章生成だ。ツール側には、関連性の高いデータのみを返す「コンテキストエンジニアリングの内包」を求める。 この思想は、エージェントを単なるモデルのラッパーとして捉えるのではなく、モデル・ツール・ハーネスが一体となってシステムとして進化するという視点に基づいている。 日本でも生成AIを活用した情報収集・調査業務の自動化への関心が高まっており、本記事で紹介されたコンテキストエンジニアリングやエージェント設計の考え方は、国内のAIシステム開発者にとっても参考になる視点を多く含んでいる。 元記事: Building Deep Research: How we Achieved State of the Art

FLUX.2とは何か Black Forest Labs（BFL）が新たにリリースした画像生成モデル「FLUX.2」が、Hugging FaceのDiffusersライブラリに対応した。前作のFLUX.1シリーズとは異なり、アーキテクチャをゼロから再設計した完全新規モデルであり、単純な後継版や置き換えとして位置付けられていない点に注意が必要だ。 FLUX.2はテキストプロンプトによる生成だけでなく、画像を参照入力として複数枚受け取りながら出力を生成する画像ガイド生成にも対応している。生成と編集の両用途をカバーする設計となっている。 アーキテクチャの主な変更点 テキストエンコーダーの刷新 FLUX.1では2つのテキストエンコーダーを使用していたが、FLUX.2ではMistral Small 3.1に一本化された。これによりプロンプト埋め込みの計算が大幅にシンプルになり、最大512トークンまでのシーケンス長をサポートする。また、単一レイヤーの出力ではなく中間レイヤーの出力を積み重ねる手法を採用しており、表現力の向上が期待される。 DiTブロック構成の変化 FLUX.2はFLUX.1と同様にマルチモーダル拡散トランスフォーマー（MM-DiT）＋並列DiTの構成を踏襲しているが、いくつかの重要な変更が加えられている。 時間・ガイダンス情報の共有化: 各トランスフォーマーブロックが個別のモジュレーションパラメータを持つFLUX.1と異なり、FLUX.2ではダブルストリーム・シングルストリームそれぞれのブロック群でこれらを共有する バイアスパラメータの完全廃止: アテンション層・フィードフォワード層を含むすべての層でbiasパラメータを使用しない設計に 完全並列トランスフォーマーブロック: シングルストリームブロックで、アテンションのQKV投影とFF入力投影を統合した完全並列構造を採用 シングルストリームブロックの割合が増大 FLUX.1[dev]-12Bがダブルストリーム19ブロック・シングルストリーム38ブロックだったのに対し、FLUX.2[dev]-32BはダブルストリームをわずかA8ブロックに絞り、シングルストリームを48ブロックに拡大している。総パラメータに占めるシングルストリームの割合はFLUX.1の約46%からFLUX.2では約73%へと大幅に増加した。 推論に必要なVRAM FLUX.2の最大の課題はそのハードウェア要件だ。大規模なDiTとMistral3 Smallの組み合わせにより、オフロードなしでの推論には80GB超のVRAMが必要となる。Diffusersのドキュメントでは、CPUオフロードや量子化を活用した一般的なGPU環境向けの推論方法も解説されており、コンシューマー向けGPUでの利用も一定程度可能とされている。 LoRAファインチューニングへの対応 Diffusersの対応によりLoRAを用いたファインチューニングも可能となった。カスタムスタイルの学習や特定ドメインへの特化といった用途に活用できる。 まとめ FLUX.2は画像生成・編集モデルとして技術的に大きな前進を示しているが、32Bという巨大なモデルサイズはリソース面でのハードルも高い。Diffusersへの統合により推論の敷居は下がったものの、実用的な活用には引き続きハイエンドなGPU環境が求められる。オープンソースの画像生成モデルとして、研究・開発コミュニティにおけるFLUX.2の動向に今後も注目したい。 元記事: Diffusers welcomes FLUX-2

CodexがHugging Face Skillsと統合——ML実験をエージェントに委任する新時代 OpenAIのAIコーディングエージェント「Codex」が、Hugging Faceのスキルリポジトリ「HF Skills」と統合され、機械学習モデルのトレーニングから評価・公開までをエンドツーエンドで自動化できるようになった。Hugging Faceが2025年12月に公式ブログで発表した。 何ができるのか HF Skillsを使うことで、Codexは以下のタスクを自律的にこなせる。 言語モデルのファインチューニングおよびRLアライメント（強化学習による調整） Trackioを通じたリアルタイムのトレーニングメトリクスの確認と対応 チェックポイントの評価と結果に基づく判断 実験レポートの自動生成 GGUFフォーマットへのエクスポートとモデルの量子化（ローカル実行向け） Hugging Face Hubへのモデル公開 例えば「Qwen3-0.6BをデータセットでファインチューニングしてHubに公開して」と一言伝えるだけで、Codexがデータセットの検証・適切なハードウェアの選択・学習スクリプトの生成・ジョブの投稿・進捗監視まで一気に処理する。 おもちゃではない、本番レベルの技術スタック この統合が注目される理由の一つは、対応する学習手法の本格度だ。教師ありファインチューニング（SFT）、直接選好最適化（DPO）、検証可能な報酬を用いた強化学習（RLVR）など、現在の生成AIの最前線で使われる手法に対応している。モデルサイズも0.5Bから7Bパラメータまでをカバーし、複数手法を組み合わせたマルチステージパイプラインも構築可能だ。 Claude CodeやGemini CLIとも互換 興味深いのは、HF Skillsが特定のエージェントに縛られていない点だ。CodexはAGENTS.mdファイルを使ってスキルを読み込む仕組みを採用しており、Claude CodeのSkillsやGemini CLIとも互換性を持つ。異なるAIエージェントが同じスキルリポジトリを共有できるという設計は、エージェント間の相互運用性を高めるうえで重要な方向性を示している。 日本のMLエンジニアへの影響 国内でもLLMのファインチューニングへの関心は高まっており、Hugging Face上での日本語モデルの開発も活発だ。今回の統合により、実験の設計から結果レポートの確認まで「エージェントに委任して、人間はレビューに集中する」というワークフローが現実的になる。Hugging Face ProまたはTeam/Enterpriseプランへの加入が必要だが、個人開発者から企業のMLチームまで活用の幅は広い。 CodexとHF Skillsを組み合わせた活用は、AIモデル開発のハードルを下げ、より多くのエンジニアが最先端のトレーニング手法を試せる環境を整えつつある。 元記事: Codex is Open Sourcing AI models

NVIDIAがCES 2026で「自分だけのAIロボット」を実現するデモを披露 NVIDIAは2026年1月5日に開催されたCES 2026において、パーソナルAIスーパーコンピューター DGX Spark と小型ロボット Reachy Mini を組み合わせたエージェントデモを公開した。CEOのジェンスン・フアン氏がキーノートで直接デモを行い、デスクに置いた小型ロボットとリアルタイムで会話・協業できる様子を見せた。 「机の上のR2-D2」というビジョン このデモのコンセプトは、クラウドに依存せず手元のハードウェアでデータをプライベートに処理しながら動作する「パーソナルAIバディ」だ。DGX Sparkのローカル処理能力を使うことで、会話内容や取り扱うデータを外部サーバーに送ることなくエージェントを動かせる点が特徴となっている。 使用されている主なコンポーネント デモで用いられた技術スタックは以下の通りだ。 推論モデル: NVIDIA Nemotron 3 Nano（ローカル動作時は約65GBのディスク容量が必要） 視覚モデル: NVIDIA Nemotron Nano 2 VL（ビジョン・ランゲージモデル、約28GB） 音声合成: ElevenLabsのTTSモデル エージェント基盤: NVIDIA NeMo Agent Toolkit ロボット: Reachy Mini（実機またはシミュレーター） NeMo Agent ToolkitはLangChain・LangGraph・CrewAIといった既存のエージェントフレームワークとも連携でき、モデルの差し替えやルーティングロジックの変更が容易な疎結合アーキテクチャが採用されている。トークン使用効率やレイテンシーのプロファイリング・自動チューニング機能も内蔵している。 完全オープンな構成が鍵 既存のクローズドなパーソナルアシスタントとの最大の違いは、モデル・プロンプト・ツール・ロボットの動作すべてをユーザーが制御できる点だ。Reachy Miniはカメラ（視覚）・スピーカー（発話）・アクチュエーター（動作）を持ち、Pythonから直接制御できるため、既存のエージェントスタックへの統合が容易となっている。 デプロイ方法も柔軟で、DGX Sparkなどのローカルハードウェアで動かす他に、NVIDIA BrevやHugging Face Inference Endpointsを使ったクラウドGPU上への展開、またはNVIDIAやHugging Faceのサーバーレスモデルエンドポイントへのリクエスト送信も選択できる。 日本のAI開発者への示唆 Reachy Miniは現在Hugging Face上でも情報が公開されており、ソースコードを参照しながら同様の構成を自前で再現できる。エッジAIとロボティクスの融合という観点では、国内でも製造・介護・教育といった分野への応用が期待されるアーキテクチャパターンといえるだろう。NVIDIAがハードウェア・モデル・フレームワークをすべてオープンに揃えてきたことで、個人や中小規模チームがフィジカルAIエージェントを開発するハードルは大きく下がっている。 元記事: NVIDIA brings agents to life with DGX Spark and Reachy Mini

NVIDIAがフィジカルAI向け推論モデルの最新版を公開 NVIDIAは、物理世界を対象とするAI（フィジカルAI）向けのオープン推論ビジョン言語モデル（VLM）最新版「Cosmos Reason 2」を公開した。前バージョンを精度面で大きく上回り、「Physical AI Bench」および「Physical Reasoning」の両ベンチマークリーダーボードでオープンモデル首位を獲得している。 ビジョン言語モデルの課題——「推論」の壁を越える ビジョン言語モデルは、画像内の物体認識やパターン検出などのタスクで急速に進化してきた。しかし、複数ステップの計画立案や不確実な状況への適応、新しい場面への対応といった、人間なら自然にこなせるタスクは依然として苦手とされてきた。 Cosmos Reasonシリーズは、こうした「推論のギャップ」を埋めることを目的として設計されている。Cosmos Reason 2は、ロボットやAIエージェントが物体の動きを時空間的に把握し、物理法則や常識・事前知識を活用しながら複雑な問題をステップごとに解決できるよう設計されている。 主な強化ポイント 時空間理解の向上：空間・時間の認識精度とタイムスタンプの精度が改善 2種類のモデルサイズ：2Bおよび8Bパラメータのモデルを用意し、エッジデバイスからクラウドまで柔軟に展開可能 視覚的空間理解の拡張：2D/3D点位置推定、バウンディングボックス座標、軌跡データ、OCR（光学文字認識）をサポート 長文コンテキストの強化：入力トークン数が前版の16Kから256Kへと大幅拡大 Cosmos Cookbookレシピ：多様なユースケースへの適応を支援するサンプルコードを提供 実際の活用シーン 動画解析AIエージェント 膨大な映像データからインサイトを抽出する用途では、Cosmos Reason 2はOCR対応に加え、2D/3D点位置推定やマーク認識などの機能を新たに提供する。Salesforceは、Cobaltロボットが撮影した映像を「Agentforce」と組み合わせて職場の安全管理・コンプライアンス確認に活用する取り組みを進めている。 自動運転向けデータアノテーション Uberは、自動運転車（AV）の訓練データ向けに、正確で検索可能な映像キャプション生成にCosmos Reason 2の活用を探っている。共同開発されたファインチューニングレシピによると、BLEU スコアが10.6%改善（0.113→0.125）、LingoQAスコアが13.8%向上（63.2%→77.0%）するなど、自動運転領域への高いドメイン適応性が示されている。 ロボットの計画・行動制御 ロボット向けビジョン言語アクション（VLA）モデルの「頭脳」として、次の行動だけでなく軌跡座標の出力にも対応。より緻密で計画的な動作制御が可能になった。 日本市場・製造業への示唆 製造ラインや物流倉庫でのロボット活用が進む日本においても、物理世界を深く理解した推論型AIは大きな可能性を持つ。特に映像による品質検査や異常検知、ロボットアームの精密制御への応用が期待される。Cosmos Reason 2はHugging Faceでオープンに公開されており、国内企業も含めた幅広い開発者がアクセス可能だ。 元記事: NVIDIA Cosmos Reason 2 Brings Advanced Reasoning To Physical AI

Microsoftが差分アテンション第2世代を発表——推論速度を標準Transformerと同等に MicrosoftのUnifiedLanguage Modelチーム（Tianzhu Ye、Li Dong、Yutao Sun、Furu Wei）は、大規模言語モデル（LLM）のアテンション機構を改良したDifferential Transformer V2（DIFF V2）を発表した。 Differential Transformerとは 差分アテンション（Differential Attention）は、Microsoftが提唱したアテンション機構で、「2つのSoftmaxアテンションの差分を取る」という独自のアプローチでノイズを打ち消し、重要なコンテキストへの集中力を高める技術だ。第1世代（DIFF V1）は精度面で優れた結果を示していたが、デコード速度の低下とカスタムアテンションカーネルの必要性という2つの課題を抱えていた。 DIFF V2の核心——KVヘッドを増やさずクエリヘッドを2倍に DIFF V2が採用した設計の要点は、クエリヘッド数を2倍にしつつ、キーバリュー（KV）ヘッド数はそのまま維持するという点にある。 LLMの推論（デコード）フェーズはメモリ帯域幅に律速されるため、KVキャッシュのサイズが速度を左右する。DIFF V2はKVヘッドを増やさないことで、標準Transformerと同等のデコード速度を実現した。DIFF V1ではバリューキャッシュを2回ロードする必要があり速度低下が生じていたが、DIFF V2ではこの問題が解消されている。 差分演算では、同じGQA（Grouped Query Attention）グループに属する2つのクエリヘッドの出力から差し引く仕組みを採用。このグループ内でキーとバリューが共有されることが、性能面で重要な役割を果たしている。 カスタムカーネル不要でFlashAttentionと完全互換 DIFF V1では差分アテンションの実装にカスタムCUDAカーネルが必要だったが、DIFF V2ではクエリ・キー・バリューのヘッド次元が揃っているため、標準的なFlashAttentionカーネルをそのまま利用できる。NVIDIAのHシリーズ・Bシリーズ（Hopper/Blackwell世代）GPUでの事前学習においても、スループット低下はほぼ無視できる水準に抑えられているという。 また、DIFF V1で採用されていたRMSNormによる後処理や複雑なλ計算を廃し、シグモイド関数を使ったシンプルなλ推定（トークンごと・ヘッドごとに入力Xから動的に射影）に置き換えた。これにより実装が大幅に簡素化された。 長文脈処理にはYOCOとの組み合わせを推奨 長シーケンスのプリフィリング（初期コンテキスト処理）については、YOCO（You Only Cache Once）と組み合わせることを研究チームは推奨している。YOCOはGemma 3nでも採用されており、シーケンス長に対するプリフィリング計算量を線形に抑える技術だ。 実装・コードの公開 コードはMicrosoftのGitHubリポジトリ（microsoft/unilm）で公開されており、Hugging Face Blogでも詳細な解説と数式が読める。差分アテンションの改良版として、実際のLLM開発への応用が現実的な選択肢となってきた。日本のAI研究者・エンジニアにとっても、標準的な開発環境でそのまま試せる実用的な技術として注目に値する。 元記事: Differential Transformer V2

AIエージェントは「なぜ」失敗するのか、ようやく答えが出た AIエージェントのベンチマーク評価は長らく「成功率」という1つの数値に集約されてきた。しかしその数値は「失敗した」という事実を伝えるだけで、「なぜ失敗したか」は教えてくれない。IBMリサーチとUCバークレーの研究チームは、このブラックボックス問題に正面から取り組み、その結果を公開した。 ITBench × MASTによる診断アプローチ 研究チームが活用したのは2つのフレームワークだ。 ITBenchはSRE（サイト信頼性エンジニアリング）、セキュリティ、FinOpsの自動化タスクを対象とした業界標準ベンチマークで、Kubernetesの障害診断やクラウドコスト最適化など、実務に近い長期タスクをエージェントに課す。 MAST（Multi-Agent System Failure Taxonomy）は、複雑なマルチエージェントシステムの失敗モードを体系的に分類するフレームワーク。1,600件超のトレースを分析して導出されたもので、単なるエラーログではなく「どの判断プロセスで何が崩壊したか」を構造化して記述できる。 今回の研究では、Gemini-3-Flash、Kimi-K2、GPT-OSS-120Bという3クラスのモデルに対して310件のITBench SREトレースをMASTで注釈付けし、失敗パターンを比較分析した。 3つの主要な発見 1. フロンティアモデルは「局所的に」失敗する Gemini-3-Flashのような最先端モデルは、1トレースあたり平均2.6の失敗モードに留まり、失敗は比較的孤立している。典型的なボトルネックは「検証フェーズ」——タスクを完了したと判断する段階での誤りだ。 2. 大規模オープンモデルは「連鎖的に」崩壊する GPT-OSS-120Bでは1トレースあたり5.3の失敗モードが観測された。初期の推論ミスがコンテキストを汚染し、その後のステップで幻覚（ハルシネーション）が雪だるま式に増加する「カスケード障害」が特徴的だ。 3. 最大の失敗予測因子は「自己採点」 モデルの種類を問わず、最も強力な失敗予測因子はFM-3.3（不正確な検証）だった。エージェントはしばしば、実際には問題が解決されていないにもかかわらず「タスク完了」を宣言してしまう。自分の宿題を自分で採点させることの危険性が数値で示された形だ。 Kimi-K2には特有の問題もあった。タスク完了の認識に問題があり、「早期終了（+46%増）」と「終了条件の未認識（+43%増）」が突出して多く、解決直前で諦めるか、逆に無限ループに陥るケースが頻発した。 実装への提言 研究チームはこれらの知見から、エージェント設計者向けの具体的な対策を提示している。 検証の外部化：LLMに自己評価させるな。終了前にツールによるハードな証拠を必須とせよ 終了制御をモデルの外に置く：ループ検出器や有限状態機械（FSM）を明示的に実装し、同一アクションの繰り返しを制御する 曖昧な入力への対処を一級市民に：入力が不明瞭な場合、「明確化を求めるか読み取り専用で進む」という分岐をエージェントグラフに組み込む エンタープライズAI開発への示唆 この研究が重要なのは、「成功したか否か」の先にある問いを提示している点だ。「何が壊れ、どこで壊れ、どの介入が最も効果的か」——これこそが本番環境でのエージェント開発に必要な評価観点であり、MASTはその答えを導き出す実践的な枠組みとして今後の標準となり得る。 ITBenchのデータセットとMASTの注釈データはHugging Faceで公開されており、GitHubでもコードが利用可能だ。エンタープライズ向けAIエージェントを設計・評価している開発者にとって、必読の研究成果といえる。 元記事: IBM and UC Berkeley Diagnose Why Enterprise Agents Fail Using IT-Bench and MAST

GGMLとHugging Faceが統合——ローカルAIの未来を共に築く ローカルLLM推論エンジンとして世界中の開発者に愛用されている「llama.cpp」の開発元であるGGMLが、AI/MLプラットフォーム大手のHugging Face（HF）にチームとして参画することが2026年2月に発表された。GGMLの創設者であるGeorgi Gerganov氏とそのチームが合流し、llama.cppの開発を継続しながら、HFのリソースと連携していく。 llama.cppとは llama.cppは、MetaのLLaMAモデルをはじめとする大規模言語モデル（LLM）をCPUやGPU上でローカル実行するためのC/C++製推論エンジンだ。量子化技術を駆使することで、一般的なPCやMacでも高性能なAI推論を可能にし、クラウドサービスに依存しないプライバシー重視の利用スタイルを実現している。日本でも個人開発者や企業のオンプレミスAI活用で広く使われている。 何が変わるのか HF側が強調するのは、「変わらないこと」の重要性だ。Gerganov氏とチームは引き続きllama.cppの開発・メンテナンスに100%の時間を注ぎ、技術的な方向性やコミュニティ運営についての完全な自律性を保つ。プロジェクトは従来通り100%オープンソースで継続される。 HFが提供するのは、長期的かつ持続可能なリソースだ。これにより、ボランティア主体のOSSプロジェクトにありがちな「メンテナーの疲弊」リスクを軽減し、指数関数的に進化するローカルAIの波に対応した継続的な開発が可能になる。 技術的なシナジー HFにはllama.cppのコアコントリビューターがすでに在籍しており、今回の統合はきわめて自然な流れだという。技術的には、HFのtransformersライブラリ（モデル定義のデファクトスタンダード）とllama.cppの連携をさらに深め、新しいモデルをllama.cppへ「ほぼワンクリック」で移植できる仕組みの整備が進む見込みだ。 さらに、GGMLベースのソフトウェア全体のパッケージングとユーザー体験の改善も重点課題として挙げられている。ローカル推論がクラウド推論の本格的な代替となりつつある今、一般ユーザーがモデルを簡単にデプロイ・実行できる環境の整備が急務とされている。 オープンソース超知能へのビジョン 両者が共有するビジョンは「オープンソースの超知能（Superintelligence）をあらゆる人がアクセスできるものにする」というものだ。デバイス上で最大限効率的に動作する推論スタックの構築を通じて、AIの民主化をさらに推し進めることが長期目標として掲げられている。 ローカルAIの普及は、データプライバシーの観点から特に医療・法務・金融などの分野で関心が高い日本市場にとっても重要な動きだ。今後のllama.cppの進化と普及加速に注目したい。 元記事: GGML and llama.cpp join HF to ensure the long-term progress of Local AI