Tech-News

「なぜ誰も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

同期RLの「壁」——GPUが60%の時間アイドル状態になる問題 LLM（大規模言語モデル）のポストトレーニングに強化学習（RL）を活用する手法が急速に普及しているが、従来の同期型RL訓練には深刻なボトルネックが存在する。 32Bパラメータのモデルで32Kトークンのロールアウト（モデルの出力生成）を1バッチ処理すると、推論だけで数時間かかることがある。その間、学習用GPUは完全にアイドル状態だ。日本語でいえば「データが来るのをひたすら待っている状態」である。 この非効率を解消するために生まれたのが非同期RLアーキテクチャだ。 解決策：推論と学習を分離する 非同期RLの核心的なアイデアはシンプルだ。 推論専用GPUプールと学習専用GPUプールを分離する 両者をロールアウトバッファ（モデル出力の一時保管領域）で接続する モデルの重みを非同期に転送することで、どちらの側も相手を待たないようにする この設計により、推論と学習が並行して動き続け、GPU稼働率が大幅に改善される。 16ライブラリを7軸で徹底比較 Hugging Faceのチームは、この非同期RLパターンを実装した16のオープンソースライブラリを以下の7軸で調査・比較した。 比較軸 内容 オーケストレーション 分散処理の制御方式 ロールアウトバッファ 出力データの保管設計 重み同期プロトコル モデルパラメータの転送方法 ステールネス管理 古いデータサンプルの扱い方 部分ロールアウト対応 未完了出力の処理 LoRAサポート 軽量ファインチューニングへの対応 分散学習バックエンド 並列化方式 主要な調査結果 オーケストレーションはRayが独占：調査した16ライブラリのうち8つがRayを採用。分散MLの事実上の標準となっている。 重み転送はNCCLブロードキャストが主流：NVIDIA Collective Communications Library（NCCL）のブロードキャスト方式がデフォルトとして広く使われている。 ステールネス管理の多様性：古いデータをシンプルに破棄するものから、重要度サンプリング補正（importance-sampling correction）という高度な手法まで、各ライブラリの対応はまちまちだ。 LoRAサポートはまだ限定的：LoRA（Low-Rank Adaptation）による効率的なファインチューニングへの対応は、現状では少数のライブラリにとどまる。 MoEサポートが次の差別化要因：Mixture of Experts（MoE）アーキテクチャの分散学習対応が、今後のライブラリ選定における重要な判断軸になりつつある。DeepSeek v3のようなMoEモデルの台頭がこのトレンドを加速している。 今後の課題：推論と学習のミスマッチ 報告書では今後の設計課題も挙げられている。特に注目されるのが訓練・推論ミスマッチ問題だ。MoEモデルでは、学習時に使うレイヤーと推論時に使うレイヤーが異なるため、重み同期の設計が複雑になる。 また、マルチエージェント協調進化やプロセス報酬モデル（推論の途中ステップに報酬を与える手法）の台頭により、同期のタイミング設計がさらに困難になっている。 TRL（Transformer Reinforcement Learning）の設計方針 Hugging FaceはTRLの非同期トレーナーに以下の原則を採用すると発表した。 オーケストレーションの軽量化：複雑な依存関係を避けシンプルに保つ トークン単位のバージョン管理付き有界キュー：ダブルバッファリングなし NCCLパック転送による重み同期：転送効率を最大化 エージェント型ワークロード向けの部分ロールアウトサポート LLMの推論能力強化（いわゆる「思考するAI」）がトレンドとなる中、非同期RLアーキテクチャの設計は今後のAI開発の基盤技術として重要性を増している。フルの比較表は原文で公開されており、ライブラリ選定の参考になるだろう。 元記事: Keep the Tokens Flowing: Lessons from 16 Open-Source RL Libraries

H CompanyがHolotron-12Bを公開——高スループット推論を実現したコンピューターユースエージェントモデル フランスのAIスタートアップH Companyは2026年3月17日、マルチモーダルコンピューターユースモデル「Holotron-12B」をHugging Faceで公開した。NVIDIAが公開したオープンモデル「Nemotron-Nano-2 VL」をベースに、H Company独自のデータセットでポストトレーニングを施した本モデルは、エージェント向けの高スループット推論を主目的として設計されている。 なぜ作ったのか——エージェント特化の思想 現在主流のマルチモーダルモデルの多くは、静的な画像認識や指示への追従を最適化対象としている。これに対してHolotron-12Bは、コンピューターを実際に操作するAIエージェント（コンピューターユースエージェント）のポリシーモデルとして機能することを目指している。エージェントは「知覚→判断→行動」を繰り返しながらインタラクティブな環境で動作するため、長いコンテキストや複数画像を効率よく処理できる能力が求められる。 ハイブリッドSSMアーキテクチャが鍵 本モデルの推論効率を支えるのが、NemotronアーキテクチャのハイブリッドSSM（State-Space Model）と注意機構の組み合わせだ。 純粋なTransformerベースのモデルでは、トークン数が増えるにつれてKVキャッシュが線形に増大し、長文脈処理がVRAMのボトルネックとなる。これに対しSSMはシーケンス長に依存しない定数サイズの状態を保持するだけでよいため、メモリフットプリントが大幅に削減される。この特性がマルチ画像・長文脈のエージェントワークロードに特に効果的に働く。 ベンチマーク結果——スループット2倍超 WebVoyagerベンチマーク（並列ワーカー100件）での評価では、**単一H100 GPU + vLLM（v0.14.1）**の構成で以下の結果が得られた。 モデル 最大トークンスループット Holo2-8B（従来モデル） 5,100 tokens/s Holotron-12B 8,900 tokens/s 並列リクエスト数が増加するにつれてHolo2-8Bのスループットが頭打ちになるのに対し、Holotron-12Bは安定してスケールし続ける。同じハードウェア上でより大きな実効バッチサイズを処理できることが、この差を生んでいる。 用途と今後の展開 H Companyは、高スループットが求められるデータ生成・アノテーション・オンライン強化学習などのワークロードでの活用を想定している。また同社はNVIDIA Inceptionプログラムのメンバーであり、NVIDIAとの協業が本モデルの実現を後押しした。 モデルの重みとドキュメントはHugging Faceで公開されており、vLLMを通じて推論可能だ。コンピューターユースエージェントの実用化に向けた重要な一歩となる本モデルに、今後も注目したい。 元記事: Holotron-12B - High Throughput Computer Use Agent

オープンソースAIエコシステムが急拡大――ユーザー・モデル・データセットが軒並み倍増 Hugging Faceは2026年3月17日、プラットフォーム上のオープンソースAIエコシステムの現状をまとめたレポート「State of Open Source on Hugging Face: Spring 2026」を公開した。同レポートは競争環境、地理的分布、技術トレンド、新興コミュニティの動向を多角的に分析したもので、2025年中頃に発表された前回レポートの続編にあたる。 2025年を通じて、Hugging Faceのユーザー数は1300万人に到達。公開モデル数は200万件超、公開データセット数は50万件超と、いずれも前年比で約2倍の伸びを記録した。特に注目すべきは、単にモデルを「使う」だけでなく、ファインチューニング済みモデルやアダプター、ベンチマーク、アプリケーションといった派生成果物を「作る」ユーザーが増えている点だ。オープンソースAIへの関与が消費から能動的な参加へとシフトしている。 エコシステムは集中構造――上位0.01%が全ダウンロードの約半数を占める 一方、エコシステムの内部は高度に集中している。Hugging Face上のモデルの約半数は累計ダウンロード数が200件未満にとどまる。対照的に、最もダウンロードされた上位200モデル（全体の0.01%）が全ダウンロード数の**49.6%**を占めるという実態が明らかになった。 ただし、特定の言語・ドメイン・課題領域に特化したコミュニティは、全体的なダウンロード数が少なくても継続的な活用が見られる。オープンソースAIは「単一の市場」ではなく、重なり合う複数のサブエコシステムの集合体として理解するべきだとレポートは指摘する。 Fortune 500の30%超が参入――大企業・スタートアップともにオープンモデルを活用 企業の参入も著しい。Fortune 500企業の30%以上がHugging Faceに認証済みアカウントを持つようになった。スタートアップ企業はオープンウェイトモデルをデフォルトコンポーネントとして採用するケースが増えており、たとえばThinking MachinesはTinkerモデルをオープンウェイトのみで構築。VS CodeやCursorといった人気IDEもオープン・クローズド双方のモデルをサポートしている。 Airbnbなど米国の老舗企業もオープンエコシステムへの関与を深めており、2025年を通じて組織向けサブスクリプションへのアップグレードも増加した。Big Tech各社の中ではNVIDIAが最も積極的な貢献者として突出している。 オープンソースソフトウェア全般の研究では、オープン成果物が生み出す下流の経済価値はその制作コストを大きく上回るとされており、AIの領域でも同様の力学が生じつつある。クローズドシステムのみに依存する組織はコスト増とデプロイ・カスタマイズの柔軟性低下に直面するリスクがある。 地理的分布――米中二強体制が続くなか、中国モデルの存在感が急上昇 過去4年間の総ダウンロード数を地域別に見ると、米国と中国が上位を占め、英国・ドイツ・フランスがそれに続く。ただしモデル全ダウンロードの約半数は、明確な地理的拠点を持たない個人ユーザーや分散型組織によるものだ。 DeepSeekをはじめとする中国発モデルの急台頭は、オープンソースAI開発の地政学的な多極化を示す象徴的な出来事として世界から注目されており、日本のAI開発者・研究者にとっても選択肢の広がりとして恩恵をもたらす可能性がある。 今回のレポートは、オープンソースAIが「技術的選択肢のひとつ」から「産業インフラの基盤」へと変貌しつつあることを改めて示している。 元記事: State of Open Source on Hugging Face: Spring 2026

RAGシステムの「あるある」な落とし穴を解消する RAG（Retrieval-Augmented Generation）システムを構築した経験があれば、誰もが一度はこの壁にぶつかる。汎用の埋め込みモデル（Embedding Model）は「インターネット全般」を理解するように訓練されているため、契約書、製造ログ、独自の化学式、社内分類体系といったドメイン固有の文書では微妙なニュアンスを捉えきれない。 NVIDIAは2026年3月、この問題を解決する完全なオープンソースパイプラインをHugging Face Blogにて公開した。シングルGPU・1日以内のトレーニング時間で、汎用埋め込みモデルをドメイン特化モデルへと変換できる。しかも手動ラベリングは一切不要だ。 合成データ生成で学習コストを劇的に削減 埋め込みモデルのファインチューニングには、通常、数千件の「（クエリ、関連文書）ペア」が必要となる。しかしこのデータを手動で作成するのは高コストで時間がかかり、アノテーターの主観バイアスも入り込みやすい。 NVIDIAのアプローチでは、LLM（nvidia/nemotron-3-nano-30b-a3b）を活用して自社ドキュメントから自動的に高品質な合成QAペアを生成する。NeMo Data Designerが四段階のSDG（Synthetic Data Generation）パイプラインを実行し、以下を含む学習データセットを自動構築する： ハードネガティブマイニング：対照学習（Contrastive Learning）の精度を高めるために、単純な「無関係文書」ではなく、紛らわしいが不正解の文書を負例として活用 マルチホップクエリ：複数ドキュメントをまたぐ推論が必要なクエリを生成し、埋め込みの質を向上 実証済みの性能改善 NVIDIA自身の公開ドキュメントで検証した結果、Recall@10とNDCG@10の両指標で10%以上の改善が確認された。 また、AtlassianはこのレシピをJIRAデータセットに適用し、Recall@60を0.751から0.951へ、26%改善することに成功した。いずれもシングルGPUでの実行結果だ。 使用するOSSコンポーネント コンポーネント 役割 NeMo Data Designer 合成データ生成 NeMo Automodel 埋め込みモデルトレーニング BEIR 情報検索評価 NeMo Export-Deploy ONNX/TensorRT変換 NVIDIA NIM 本番推論サービング 前提条件と動作環境 ベースモデルにはLlama-Nemotron-Embed-1B-v2（パラメータ数10億）を使用。品質と推論コストのバランスを重視した選定だ。動作には以下が必要となる： ドメイン文書のディレクトリ（.txt、.md等） 有効なNVIDIA APIキー（build.nvidia.comで無料取得可能） NVIDIA Ampere世代以降のGPU、VRAM 80GB以上（A100/H100で検証済み） VRAM 80GBというハードルはやや高めだが、クラウド環境（AWS、Azure、GCPのA100/H100インスタンス）を使えば手軽に試せる。日本企業でも、社内ナレッジベースや製造データを活用したRAGシステムの精度向上に直接応用できる技術だ。 NVIDIAの公開ドキュメントから生成した合成トレーニングデータセットもHugging Face上で公開されており、すぐに試せる状態になっている。 元記事: Build a Domain-Specific Embedding Model in Under a Day

量子コンピュータが医療の難問に挑む——500万ドルコンペが最終局面へ 英国オックスフォード郊外にある国立量子コンピューティングセンター（NQCC）の実験室に、ルービックキューブほどの小さな装置が置かれている。その中では、100個のセシウム原子がレーザー光によってグリッド状に浮遊している。原子と光だけで構築されたこの量子コンピュータを所有するのは、米コロラド州のスタートアップ「Infleqtion」。同社は来週、この装置の能力で500万ドル（約7億5000万円）の賞金をつかみ取ろうとしている。 「Quantum for Bio」コンペとは このコンペは、非営利組織「Wellcome Leap」が主催する「Quantum for Bio（Q4Bio）」だ。30ヶ月にわたる量子アルゴリズム開発競争の末、6チームが最終ステージへ進出した。目的はシンプルかつ野心的——現在の量子コンピュータが、エラーが多く大規模化も途上にある現状でも、実際の医療・健康課題に貢献できることを証明することだ。 賞金は2段階構造になっている。 200万ドル賞: 50量子ビット（qubit）以上のマシンで、医療上有意義なアルゴリズムを実行したすべてのチームに授与 500万ドル グランプリ: 100量子ビット以上を使い、従来の古典コンピュータでは解けない実世界の医療問題を解決したチームに授与 量子ビット（qubit）とは量子コンピュータの基本処理単位で、古典的なビットと異なり重ね合わせ状態を利用できる。 参加チームの手応え ノッティンガム大学の計算化学者Jonathan D. Hirst氏は「200万ドル賞は十分射程内にある」と自信を見せる。スタンフォード大学のGrant Rotskoff氏のチームは、生体細胞のエネルギー源であるATP分子の量子特性を研究しており、同賞の基準を「明確にクリアしている」と語る。 一方でグランプリについては、「本当にギリギリの挑戦」（Rotskoff氏）と慎重な見方が多い。量子コンピューティングの現状を踏まえると、賞金がWellcome Leapの口座に残り続ける可能性も否定できないと、内部関係者は指摘する。 注目される「量子×古典ハイブリッド」アプローチ 量子コンピュータの真価は、原子や光子といった量子力学に従う微小な物質を使い、古典コンピュータでは到底モデル化できない複雑な現実世界のプロセスをシミュレートすることにある。新材料の開発、創薬、肥料生産などの化学プロセス改善への応用が期待されている。 しかし現実はまだ険しい。量子的な物体（原子など）を制御することは極めて難しく、大規模で安定したマシンの実現には膨大な技術的ハードルが残る。今回のコンペを通じて浮かび上がってきた現実解は、量子コンピュータと古典コンピュータを組み合わせた量子古典ハイブリッドだ。単独の古典コンピュータを上回る性能を、ハイブリッドで実現するというアプローチが主流になりつつある。 日本への示唆 日本でも量子コンピュータの研究開発は国家プロジェクトとして推進されており、理化学研究所や富士通、東芝などが独自マシンの開発を進めている。今回のQ4Bioコンペの結果は、「量子コンピュータは何ができて何ができないのか」という問いに対する、世界初の厳格な実証データとなる。その意味で、日本の研究者・企業にとっても重要なベンチマークになり得る。 審査は来週、米カリフォルニア州マリナデルレイで実施される予定。多くのコンペ作業は未公開でNDA（秘密保持契約）に守られており、真の実力判定は審査員のみが下せる状況だ。量子コンピューティング分野が「過大評価」と「過小評価」の間で揺れ続けるなか、この結果は業界全体の方向性を左右する一石になるかもしれない。 元記事: Can quantum computers now solve health care problems? We’ll soon find out.