Tech-News

Microsoftは「Microsoft 365 Copilot Wave 3」を発表し、AIアシスタントの役割を**「補助（Assistance）」から「自律（Agency）」**へと明確に転換させる新機能群を公開した。 Wave 3の主な新機能 ドキュメント内での直接生成・編集 これまでCopilotはサイドパネルやチャット経由でしか操作できなかったが、Wave 3ではWordやExcelなどのドキュメント内でコンテンツを直接生成・編集・改善できるようになる。ユーザーが文書を開いたまま、Copilotがその場でドラフトを書き換えたり、表を整形したりといった操作が可能になる。 カスタムエージェントのキャンバス構築 注目の新機能が「エージェントビルダー」だ。ユーザーはコードを書かずに、自分専用のAIエージェントをキャンバス上で構築できる。繰り返し発生する業務フロー——たとえば週次レポートの集計や、問い合わせメールの仕分け・返信——をエージェントとして定義しておけば、Copilotが自律的に処理を進める。 「つまらない仕事」からの解放 Microsoftが今回のWave 3で強調しているのは、日常業務の中で最も退屈な作業をCopilotに委ねるというコンセプトだ。単なる質問応答ツールではなく、タスクを「任せきれる」エージェントとして機能させることで、ナレッジワーカーの生産性を底上げすることを目指している。 「Wave」戦略で段階的に進化 MicrosoftはCopilotの機能強化を「Wave」と呼ばれるフェーズ単位でリリースしてきた。Wave 1でCopilotをMicrosoft 365アプリに統合し、Wave 2でプラグインやGraph Connectorによる外部データ連携を強化。そして今回のWave 3ではエージェント化が中心テーマとなる。 日本企業においても、Microsoft 365のCopilotライセンスを導入済みの組織は増加傾向にある。Wave 3の機能が一般提供（GA）されれば、業務自動化の文脈で活用する企業が加速するとみられる。 今後の展開 Wave 3の各機能は順次ロールアウト予定とされており、詳細なリリーススケジュールはMicrosoft 365管理センターのメッセージセンターを通じて通知される。エージェント機能はまず一部のテナントへのプレビュー提供から始まる見込みだ。 AIが「答える」だけでなく「動く」存在へと進化するCopilotの今後に、引き続き注目したい。 元記事: Microsoft 365 Copilot “Wave 3” expands with more agentic AI control, eager to offload your most boring workloads

Microsoft、AIエージェント統合の最上位プラン「Microsoft 365 E7 Frontier Suite」を発表 Microsoftは2026年3月9日、エンタープライズ向けの新たな最上位ライセンスプラン「Microsoft 365 E7 Frontier Suite」を発表した。2026年5月1日より、月額**$99/ユーザー**（年間契約）での提供が開始される予定だ。 何が含まれるのか Frontier Suiteは、これまで個別に契約・管理する必要があった複数の主要プロダクトを一つのSKU（製品単位）にまとめたものだ。具体的には以下が含まれる。 Microsoft 365 E5 — エンタープライズ向けOfficeアプリ・セキュリティ・コンプライアンス機能のフル構成 Microsoft 365 Copilot — Word、Excel、Teams等に統合されたAIアシスタント機能 Agent 365 — 自律型AIエージェントをエンタープライズ環境で展開・管理するための新プラットフォーム Microsoft Entra Suite — ID管理・ゼロトラストアクセス・権限管理の統合スイート これらを個別に契約した場合の合計コストと比較すると、Frontier Suiteは企業にとってコスト効率の高い選択肢となる可能性が高い。 「Intelligence + Trust」というコンセプト 製品名のサブタイトルにある「Intelligence + Trust（インテリジェンスと信頼）」は、Microsoftが強調する2つの柱を象徴している。AIによる業務効率化（Intelligence）と、エンタープライズが求めるセキュリティ・コンプライアンス・ガバナンス（Trust）を両立させることが、このスイートの設計思想だ。 特にAgent 365の組み込みは今回の目玉であり、AIエージェントが単なる「チャットボット」を超えて業務プロセスを自律的に実行する時代への本格移行を示している。承認フローの自動化、データ分析の自動実行、クロスシステムの連携など、企業内の反復的なタスクをエージェントに委任できる環境が整う。 日本企業への影響 日本のMicrosoft 365ユーザー企業にとっても、このプランは無関係ではない。現在M365 E3やE5を利用している企業が、CopilotやEntra Suiteを追加導入しようとしている場合、Frontier Suiteへの移行がコスト・管理面で合理的な選択となりうる。 ただし、月額$99（日本円換算で約15,000円前後）は相応のコストであり、特に中小規模の企業には導入ハードルが高い面もある。Microsoftがどのような移行支援策を打ち出すかも今後の注目点だ。 今後のスケジュール 提供開始は2026年5月1日。現在のM365契約からの移行パスや詳細な価格体系については、Microsoftの公式ドキュメントおよびパートナー経由での確認が推奨される。AIエージェントの本格活用を検討している企業は、このタイミングでライセンス戦略を見直す価値がありそうだ。 元記事: Introducing the First Frontier Suite built on Intelligence + Trust

Hugging Face、Hub全体をGit LFSからXetへ——20PBの静かな大移行 AIモデルのホスティングプラットフォームとして世界最大規模を誇るHugging Faceが、Hubのストレージ基盤を従来のGit LFS（Large File Storage）から自社開発のXetへと移行完了したことを発表した。 移行の規模感 2025年1月に始まった移行プロジェクトは、わずか6ヶ月で以下の規模に達した。 移行済みリポジトリ数: 50万件超 移行データ量: 約20PB（ペタバイト） 利用ユーザー数: 100万人以上 報告されたGitHub Issue・フォーラム投稿: 数十件程度 これほどの規模の移行にもかかわらず、ユーザーからの問い合わせがほとんどなかったことは注目に値する。2025年5月には新規ユーザーおよび組織に対してXetがデフォルトストレージとして採用されている。 なぜGit LFSでは限界だったのか Git LFSはもともとソフトウェア開発用に設計されたファイルサイズ拡張の仕組みであり、数百GBから数TB級のAIモデルファイルを大量に扱うユースケースには設計思想が合わなかった。Xetはこれに対して**コンテンツアドレス型ストレージ（CAS: Content Addressed Store）**を採用し、ファイルをチャンク単位で管理することで重複排除・高速転送・並列ダウンロードを実現している。 無停止移行を支えた2つの仕組み 移行の成功を支えたのは、以下の2つの内部コンポーネントだ。 1. Git LFS Bridge 旧来のhuggingface_hubやhuggingface.jsなど、Xet非対応のクライアントが既存のAPIエンドポイント（/resolve）にアクセスした際、BridgeがXet側のチャンクデータをS3から再構成し、通常のLFSプロトコルと同じ形式のプリサインドURLとして返す。つまり、クライアント側でアップデートなしにシームレスにXet対応リポジトリのファイルへアクセスできる。 2. バックグラウンドコンテンツ移行 非対応クライアントがファイルをアップロードすると、まずLFSストレージに保存され、その後バックグラウンドで自動的にXetへ移行される。この仕組みにより、「一斉切り替え（ハードカットオーバー）」を避け、既存ワークフローを壊さずに段階的移行が実現できた。 設計の哲学 チームが最初に定めた原則は明快だった。 ハードカットオーバーは行わない XetとLFSファイルが1つのリポジトリに混在してよい 移行中もダウンロード・アップロードをロックしない これはユーザーへの影響ゼロを最優先にした判断であり、結果として多くのユーザーが移行に気づかないまま恩恵を受けることになった。 技術スタックの補足 XetのクライアントライブラリはRust製で実装されており、hf-xetとして提供されている。Xet対応クライアントはファイルを**コンテンツ定義チャンキング（Content Defined Chunking）**で分割してアップロードし、ダウンロード時はCASからチャンク範囲情報を取得してS3から直接再構成する。ファイルメタデータの管理にはDynamoDBが使われている。 今後の展開 Hugging Faceはこの移行をまだ「始まり」と位置づけており、今後数週間・数ヶ月でさらに積極的な移行を進めるとしている。日本のAI開発コミュニティにも広く普及しているHugging Face Hubだけに、大規模モデルのダウンロード速度改善など実質的なメリットが今後より顕著になってくるだろう。 元記事: Migrating the Hub from Git LFS to Xet

HuggingFaceが開発するオープンソースのAI Webアプリフレームワーク「Gradio」が、バージョン5.38.0においてMCP（Model Context Protocol）サーバー機能を大幅に強化した。GradioはHugging Face Spaces上で数千ものMCPサーバーをホストしており、LLMエージェントとの連携基盤として急速に普及しつつある。今回のアップデートで追加された5つの主要改善点を紹介する。 1. ローカルファイルのシームレスな対応 リモートのGradio MCPサーバーに画像・動画・音声ファイルを渡す際、従来はファイルを公開URLでアクセスできる場所にホストする必要があり、手間のかかる手動作業が発生していた。 Gradio 5.38.0では「File Upload MCPサーバー」が新たに追加され、エージェントがファイルを直接Gradioアプリにアップロードできるようになった。ファイル入力を必要とするツールがある場合、接続ドキュメントに自動でファイルアップロードサーバーの起動方法が表示される。 2. リアルタイムの進捗通知 画像生成や動画処理など、処理に時間がかかるAIタスクでは、完了まで待ち続けるしかなかった。新バージョンではGradioがMCPクライアントへ進捗通知をストリーミング配信するようになり、処理状況をリアルタイムに確認できる。MCPツール開発者向けのガイドも提供されており、独自ツールへの実装も容易だ。 3. OpenAPI仕様を1行でMCPに変換 既存のバックエンドAPIをLLMと連携させる際、これまでは各エンドポイントをMCPツールに手動でマッピングする必要があり、時間と手間がかかっていた。 新機能「gr.load_openapi」を使えば、OpenAPI（REST APIの機械可読仕様標準）のスキーマを指定するだけで、Gradioアプリが自動生成される。さらにmcp_server=Trueを指定して起動するだけで、既存APIがMCPサーバーに早変わりする。 元記事: Five Big Improvements to Gradio MCP Servers

Hugging Face CLIが「hf」に生まれ変わった Hugging Faceは、同社のコマンドラインツール（CLI）を正式に huggingface-cli から hf へ改名したと発表した。長年にわたって開発者から待望されていたこの変更は、単なる名前の短縮にとどまらず、コマンド体系全体の整理・再設計を伴うものだ。 なぜ改名されたのか huggingface-cli というコマンド名は、日常的に打ち込むには冗長すぎるという不満が根強かった。それ以上に大きな問題は、アップロード、ダウンロード、キャッシュ管理、リポジトリ管理など機能が追加されるにつれ、コマンド体系が雑然としてしまっていた点にある。 新しいCLIは hf <resource> <action> という構文を採用。この「リソース → アクション」という予測可能な文法は、GitやDockerなど多くの開発者が慣れ親しんだパターンに倣ったものだ。コマンドの発見性が高まり、ヘルプを確認しながら直感的に操作を進められる。 インストールと基本的な使い方 最新版の huggingface_hub をインストールするだけで hf コマンドが使えるようになる。 元記事: Say hello to hf: a faster, friendlier Hugging Face CLI ✨

GradioのMCP統合でLLMに「超能力」を与える Python開発者にとって、LLM（大規模言語モデル）に外部ツールを持たせる方法の選択肢が増えてきた。Hugging Faceが公開したブログ記事では、オープンソースライブラリ「Gradio」のMCP（Model Context Protocol）統合を活用し、LLMからHugging Face Hub上の何千ものAIモデルを直接呼び出せるようにする仕組みが紹介されている。 MCPサーバーをGradioで簡単に実装 GradioのMCP統合が注目される理由の一つは、その実装のシンプルさだ。主な特徴として以下が挙げられる。 Python関数の自動変換: Gradioアプリの各APIエンドポイントは、MCPツールとして自動的に変換される。関数のdocstringがツールの説明文やパラメータ定義として活用される リアルタイム進捗通知: 処理状況をMCPクライアントへストリーミング通知する機能が組み込み済みで、開発者側での実装が不要 ファイルアップロードの自動処理: 公開URLや複数のファイル形式に対応したアップロード処理もサポート 実装例：AIスタイリストで洋服を試着 ブログ記事では具体的なユースケースとして「AIショッピングアシスタント」が紹介されている。オンラインショッピングで服を選ぶ際の「試着の手間」をAIが代替するという発想だ。 このシステムは3つのコンポーネントで構成される。 IDM-VTON（拡散モデル）: 既存の人物写真に対して、別の衣服を着ているように見せるバーチャル試着AIモデル。Hugging Face Spaceで公開されている Gradio: MCPサーバーとして機能し、LLMとIDM-VTONモデルをつなぐブリッジ役 VS Code AIチャット: 任意のMCPサーバーを追加できるVS Codeの組み込みAIチャットをUIとして利用 中核となるGradio MCPサーバーでは、vton_generationという関数を1つ定義するだけでよい。この関数は人物モデルの画像と衣服の画像を受け取り、IDM-VTONモデルを呼び出して試着結果の画像を生成する。 元記事: Implementing MCP Servers in Python: An AI Shopping Assistant with Gradio

OpenAI、待望のオープンソースモデル「GPT OSS」をリリース OpenAIが、オープンウェイト（重みを公開）のモデルファミリー「GPT OSS」を公開した。Hugging Faceのブログで発表されたこのリリースは、OpenAIがオープンソースエコシステムへ本格参入するという観点から、AI業界で大きな注目を集めている。 2種類のモデル構成 GPT OSSは以下の2モデルで構成される。 gpt-oss-120b：総パラメータ数117B（約1,170億）、アクティブパラメータ5.1B gpt-oss-20b：総パラメータ数21B（約210億）、アクティブパラメータ3.6B どちらも混合エキスパート（Mixture-of-Experts、MoE）アーキテクチャを採用しており、推論時に全パラメータを使用しないため、計算効率が高い。さらにMXFP4形式の4ビット量子化を適用することで、メモリ使用量を大幅に削減している。 大型モデルのgpt-oss-120bはNVIDIA H100（80GB VRAM）1枚に収まり、小型のgpt-oss-20bは16GBのメモリで動作する。これはコンシューマー向けGPUや、エッジ・オンデバイスでの活用を強く意識した設計だ。日本国内でも手元のGPUサーバーや開発用PCで動かせる可能性が広がる。 アーキテクチャの特徴 Token-choice MoEにSwiGLU活性化関数を組み合わせた構造 各アテンション層にRoPE（回転位置エンコーディング）を採用、コンテキスト長は128K フルコンテキストとスライディングウィンドウ（128トークン）のアテンション層を交互に配置 GPT-4oと同じトークナイザーを使用（Responses API互換の新トークンも追加） 推論能力（Chain-of-Thought）と推論努力レベルの調整に対応 Apache 2.0ライセンスと利用ポリシー ライセンスはApache 2.0を採用しており、商用利用・改変・再配布が原則として自由に行える。付随する利用ポリシーは「適用法規の遵守」を求めるにとどまり、Meta LlamaシリーズのようなユーザーカウントによるTierや、Mistralの各種制限と比べてもシンプルな内容となっている。 OpenAIは「AIの恩恵を広く利用可能にする」というミッションに沿ったリリースと位置づけており、プライベートデプロイや社内ローカル環境での活用ニーズに応える狙いがある。 推論・ファインチューニング環境 主要な推論フレームワークはすでに対応済みだ。 transformers（Hugging Face） vLLM llama.cpp ollama Hugging FaceのInference Providers経由でAPIアクセスも可能で、CerebrasなどのプロバイダーをPython・JavaScriptから利用できる。また、Azure・DellなどのパートナーへのデプロイメントもHugging Faceプラットフォーム上でサポートされている。 オープンソースAIの競争激化 Meta（Llama）、Mistral AI、Google（Gemma）などが先行するオープンソースモデル市場にOpenAIが参入したことで、競争はさらに活発化する見込みだ。特にApache 2.0という最も制約の少ないライセンスを選択した点は、企業・研究機関の双方にとって利用しやすい環境を整えるという強いメッセージとなっている。 モデルは現在Hugging Face Hub上で公開されており、すぐに試せる状態にある。 元記事: Welcome GPT OSS, the new open-source model family from OpenAI!

大規模モデル訓練の複雑さを一気に解消 Hugging Faceは、マルチGPU環境での大規模モデル訓練を抜本的に簡略化する「Accelerate ND-Parallel」を発表した。データ並列（DP）、テンソル並列（TP）、コンテキスト並列（CP）、完全シャーディングデータ並列（FSDP）といった複数の並列化戦略を、わずか数行のコードで自由に組み合わせられる。 従来の課題：並列化戦略の組み合わせは職人技だった 数十億〜数百億パラメータ規模のLLM（大規模言語モデル）を複数GPUで訓練する場合、単一の並列化手法では対応しきれないケースが多い。たとえばデータ並列だけではGPUメモリの壁を突破できず、モデル並列だけでは通信オーバーヘッドが増大する。これらを効率よく組み合わせるには、高度な分散システムの知識が必要だった。 ParallelismConfig で並列度を宣言的に設定 ND-Parallelの核心は ParallelismConfig クラスだ。以下のように各並列化戦略の「次元数（degree）」を宣言するだけで、Accelerateが内部のデバイスメッシュを自動構築する。 元記事: Accelerate ND-Parallel: A guide to Efficient Multi-GPU Training

Hugging Face、ノーコードAIデータ処理ツール「AI Sheets」を公開 Hugging Faceは2025年8月8日、データセットの構築・変換・エンリッチメントをコードなしで実行できるオープンソースツール「AI Sheets」を公開した。スプレッドシートライクなUIで、Hugging Face Hub上の数千のオープンモデルやOpenAIのgpt-ossなどを活用したデータ処理パイプラインを手軽に構築できる。 スプレッドシート感覚でAIを活用 AI Sheetsの操作感はExcelやGoogle スプレッドシートに近い。新しい列を追加するとき、数式の代わりにプロンプトを書くだけでAIが処理を実行する。たとえば{{text}}のようにカラム名をテンプレート変数として埋め込むことで、各行のデータを参照した動的な処理が可能だ。 処理結果のセルを手動で編集・承認することで、その編集内容がプロンプトのFew-shotサンプルとして自動的に追加される仕組みも備える。いわばプロンプトを対話的にチューニングしながらデータセット全体に適用していく、という開発体験を提供する。 主なユースケース Hugging Faceが想定するユースケースは幅広い。 モデル比較（Vibe Test）: 複数モデルの出力列を並べてLLM-as-a-Judgeで自動評価 プロンプト改善: 顧客リクエスト処理など実務シナリオのプロンプトを実データで反復改善 データ変換・クレンジング: 余分な句読点を除去する、フォーマットを統一するなど 分類・分析: テキストのカテゴリ分類や主要アイデアの抽出 データエンリッチメント: 住所から郵便番号を補完するなど（Webサーチ連携も可） 合成データ生成: プライバシー上の理由で実データが使えない場合の代替データ作成 ローカル実行とHub上での利用の両方に対応 インストール不要でブラウザから即試せるHugging Face Spaces版に加え、GitHubリポジトリからローカル環境にデプロイすることも可能だ。モデルはHugging Face Hub経由のInference Providersか、ローカルモデルを選択できる。 日本語データセット開発への応用も 日本国内でも、LLMの評価ベンチマーク作成や日本語コーパスのクリーニング、社内向け合成データ生成など、機械学習エンジニアやデータサイエンティストが直面する「データ準備」の工程を大幅に省力化できるツールとして注目される。コードを書かずにAIを活用したデータパイプラインを組めるため、MLエンジニア以外のドメイン専門家でも扱いやすい点が特徴だ。 ソースコードはGitHubで公開されており、オープンソースコミュニティからの貢献も受け付けている。 元記事: Introducing AI Sheets: a tool to work with datasets using open AI models!

「最新フラッグシップだけのもの」という常識が崩れる スマートフォン上でLLM（大規模言語モデル）を動かすと聞けば、最新ハイエンド機の強力なCPU・GPU・NPUを思い浮かべるのが自然だろう。しかし、Armと Meta が共同で進める ExecuTorch 0.7 の登場により、その前提が大きく揺らいでいる。発売から3〜5年が経過したAndroidデバイスや、シングルボードコンピュータの定番 Raspberry Pi 5 でさえ、Llama 3.2を実用的な速度で動かせるようになってきたのだ。 カギを握る「SDOT命令」――2015年から静かに普及していた技術 今回の躍進を支えるのが、SDOT（Signed Dot Product）命令だ。Armv8.2アーキテクチャで導入されたこの命令は、8ビット整数ベクトルのドット積演算を効率よく実行できる。LLMの推論処理の大半を占める行列乗算は、内部的に膨大なドット積の繰り返しで成り立っており、SDOTはまさにその中核を加速する。 SDOTは実は2015年から順次Arm CPUに搭載されており、現時点で 約30億台のArmベースデバイス が対応済み。全デバイスの72%がすでにこの命令をサポートしている計算になる。「最新チップ専用の機能」ではなく、手元にある大多数のスマートフォンに眠っていた能力だ。 KleidiAI × ExecuTorchで「設定不要の高速化」を実現 ArmのAIアクセラレーション層である KleidiAI は、XNNPack・MediaPipe・MNN・ONNX Runtime・llama.cppといった広く使われるEdge AIフレームワークに組み込まれ、開発者がコードを変更することなく性能向上を届けてきた。 そのKleidiAIが、次期 ExecuTorch 0.7ベータ版でデフォルト有効化 される。AndroidおよびクロスプラットフォームのアプリはExecuTorchとXNNPack経由でKleidiAIの最適化を自動的に享受でき、モデルの起動高速化・低レイテンシー・メモリフットプリント削減が「箱から出してすぐ」手に入る。 昨年公開の量子化Llama 3.2 1Bでは、I8MM機能（Armv8.6以降）を活用したInt4行列乗算の最適化により、Galaxy S24+においてKleidiAI非適用比で プリフィル性能が20%以上向上 した実績がある。数値に換算すると、プリフィル時に毎秒350トークン超、デコード時に毎秒40トークン超という水準で、未読メッセージの要約といったオンデバイスタスクをスムーズにこなせる性能だ。 日本市場への示唆 日本でも中古スマートフォン市場は拡大しており、数年前のAndroidデバイスを使い続けるユーザーは少なくない。ExecuTorch 0.7の登場は、こうしたデバイスでもプライバシー保護・オフライン動作・低遅延というオンデバイスAIの恩恵を受けられる可能性を広げる。IoT・産業機器向けにRaspberry Piを活用している現場にとっても、クラウドAPI不要で動くLLMの実装コストが大幅に下がることを意味する。 まとめ ArmのKleidiAIとExecuTorchの統合は、ジェネレーティブAIの「動作する土台」を一気に広げる可能性を秘めている。性能競争が続くハイエンド端末だけでなく、すでに世界中に出回っている数十億台のデバイスをAIの活用フィールドに変える動き——その第一歩として、ExecuTorch 0.7のリリースは注目に値する。 元記事: Arm & ExecuTorch 0.7: Bringing Generative AI to the masses

研究者の「プラットフォーム渡り歩き」問題をAIが解決 学術研究では、論文を探すだけでなく、その実装コードやデータセット、関連モデルを複数のプラットフォームで横断的に調べる作業が欠かせない。arXivで論文を見つけ、GitHubで実装を探し、Hugging Faceで学習済みモデルを確認する——この繰り返しが研究者の時間を大量に奪っていた。 Hugging Faceが2025年8月に公開したブログ記事では、**Model Context Protocol（MCP）**を使ってAIをこれらの研究ツールに接続し、自然言語だけで横断的な文献調査を自動化するアプローチが紹介されている。 3段階の抽象レイヤー：手作業→スクリプト→MCP ブログでは、研究発見（Research Discovery）の自動化を3段階の抽象レイヤーとして整理している。 第1層：手動リサーチ 最も原始的な方法。論文をarXivで探し、著者名でGitHubを検索し、引用文献を手でたどる。体系的な文献調査には向かず、複数の研究スレッドを同時追跡するのはほぼ不可能だ。 第2層：スクリプト自動化 PythonスクリプトでAPIを叩き、メタデータを収集・整理する。手動よりはるかに速いが、API仕様の変更やレートリミット、パースエラーで無音のまま失敗しやすく、人間の監視が必須だ。 第3層：MCP統合 MCPは同じPythonツールをAIシステムから自然言語経由で呼び出せるプロトコル。たとえば「過去6カ月に公開されたTransformerアーキテクチャ論文で、実装コードと学習済みモデルが公開されているものを探して」と指示するだけで、AIが複数ツールを組み合わせて情報を収集・統合・評価してくれる。 この第3層は「ソフトウェア3.0」的な発想とも言え、自然言語が実装言語になる世界を体現している。 セットアップ方法 Hugging Faceは「Research Tracker MCP」を公式に提供しており、設定は簡単だ。 huggingface.co/settings/mcp にアクセス 「research-tracker-mcp」を検索して追加 Claude Desktop、Cursor、Claude Code、VS Codeなど使用するクライアントに合わせてセットアップ 注意点：万能ではない MCPによる自動化にも限界はある。スクリプト自動化と同様、人間の監視なしではエラーが起きやすく、実装品質によって結果の精度が大きく変わる。手動→スクリプト→MCPという下層の仕組みを理解しているほど、より良い活用ができると著者は強調している。 なお、MCPはAnthropicが策定したオープン標準で、日本でもClaude CodeやCursorユーザーを中心に急速に普及しつつある。研究者だけでなく、情報収集を日常的に行うエンジニアやアナリストにとっても実用性の高い仕組みだ。 元記事: MCP for Research: How to Connect AI to Research Tools

Hugging Face、本番対応CUDAカーネル構築ライブラリ「kernel-builder」を公開 Hugging Faceは2025年8月、カスタムCUDAカーネルを効率よく開発・配布するためのライブラリkernel-builderのガイドを公開した。AIモデルのパフォーマンスを最大限に引き出すには独自のGPUカーネルが有効だが、実際の本番環境向けに整備するのは難しい。kernel-builderはその課題を解決するために設計されている。 kernel-builderとは kernel-builderを使うと、ローカルで開発したカスタムカーネルを複数のGPUアーキテクチャ向けにビルドし、Hugging Face Hub上に公開できる。公開後は以下のように、誰でも簡単にカーネルを利用できる。 元記事: From Zero to GPU: A Guide to Building and Scaling Production-Ready CUDA Kernels

NVIDIAが600万件の多言語推論データセットを公開 NVIDIAは2025年8月20日、**600万件規模の多言語推論データセット「Nemotron Post-Training Dataset V2」**を公開した。フランス語・スペイン語・ドイツ語・イタリア語・日本語の5言語に対応しており、オープンウェイトモデルの発展を支援することを目的としている。 データセットの特徴と構築手法 今回のデータセットは、既存の英語推論データをベースに5言語へ翻訳したものだ。注目すべきは翻訳アプローチで、ユーザーのプロンプトとモデルの回答は対象言語に翻訳しつつ、推論チェーン（Chain-of-Thought）は英語のまま保持するという設計を採用している。英語の事前学習で蓄積された知識を最大限に活かすための工夫だ。 大規模言語モデル（LLM）による機械翻訳は近年めざましい進歩を遂げているが、合成データ生成においては独自の課題があることも明らかになった。NVIDIAの研究チームは以下の問題を指摘している。 LLMは一般的な機械翻訳テストセット（FLORESなど）と比べ、SFT（教師ありファインチューニング）データセットの翻訳においてハルシネーション（誤情報生成）が起きやすい オープンソースLLMの翻訳品質とハルシネーション率は、入力の長さが増すにつれて著しく低下する これらの問題に対処するため、いくつかの品質管理メカニズムを導入した。テキストを改行単位で分割して1行ずつ翻訳すること、コードブロックや翻訳不要な行はスキップすること、特殊な括弧記号「〘〙」で翻訳結果を囲むフォーマットを強制して抽出精度を高めること、そしてfastTextによる言語識別でオフターゲットデータを除去することなどが実施されている。これらの結果、約55,567件（全多言語サンプルの約1.1%）が除外された。 同時公開：Nemotron Nano 2 9B データセットと合わせて、新モデル**「NVIDIA Nemotron Nano 2 9B」**も発表された。エッジデバイスやRTX環境での動作を想定した小型・高効率モデルで、以下の特徴を持つ。 項目 詳細 パラメータ数 90億（9B） アーキテクチャ ハイブリッド Transformer–Mamba（Mamba-2 + 少数のアテンション層） スループット 同クラスの主要モデル比で最大6倍の高速トークン生成 コスト削減 「思考バジェット」の調整により推論コストを最大60%削減 対象用途 カスタマーサービス、サポートチャットボット、分析コパイロット、エッジデプロイ ライセンス nvidia-open-model-license ハイブリッドTransformer–Mambaアーキテクチャは、純粋なTransformerモデルと同等の精度を保ちながら高いスループットを実現できる点が特徴だ。モデルの重みはHugging Faceで公開されており、build.nvidia.comでAPIエンドポイントのデモも試用可能。NVIDIA NIMとしても近く提供される予定だ。 日本語コミュニティへの意義 日本語が対応言語に含まれた点は、国内の研究者や開発者にとって朗報だ。600万件規模の推論データセットが日本語で利用可能になることで、日本語対応の高性能推論モデルのファインチューニングがより容易になると期待される。NVIDIAはモデル重み・学習ツール・学習データをともに公開することで、オープンウェイトモデルエコシステム全体の底上げを図っている。 元記事: NVIDIA Releases 6 Million Multi-Lingual Reasoning Dataset

GoogleがオンデバイスRAG向け埋め込みモデル「EmbeddingGemma」を公開 Googleは2025年9月4日、新しい多言語テキスト埋め込みモデル「EmbeddingGemma」を公開した。わずか308Mパラメータながら100以上の言語に対応し、モバイルデバイスでのRAG（検索拡張生成）パイプラインやAIエージェントへの組み込みを念頭に設計されている。 特徴と性能 EmbeddingGemmaは、テキストの意味・感情・意図を高密度ベクトルに変換する埋め込みモデルの新世代だ。Hugging Face上での埋め込みモデルの月間ダウンロード数は2億回を超えており、セマンティック検索や推薦システム、コード検索など多様な用途で広く活用されている。 本モデルの主な仕様は以下のとおり： パラメータ数：308M（量子化時のRAM消費は200MB以下） コンテキストウィンドウ：2,048トークン 対応言語：100言語以上 出力次元：768次元（512/256/128次元へのMatryoshka截断対応） ライセンス：オープンソース Massive Text Embedding Benchmark（MTEB）の多言語版であるMMTEBでは、500M以下のテキスト専用多言語モデルとして最高スコアを記録している。 アーキテクチャ：デコーダをエンコーダに転換 技術面での最大の特徴は、Gemma3のトランスフォーマーバックボーンをベースに双方向アテンション（Bidirectional Attention）を採用した点だ。従来のGemmaは因果的（一方向）アテンションを用いるデコーダ型LLMだが、EmbeddingGemmaは双方向アテンションによりエンコーダ型に転換されている。これにより、系列内の前後トークンを相互参照でき、埋め込みタスクでLLMを上回る性能を発揮する。 トークン埋め込みはMean Poolingにより文章単位のベクトルに集約され、さらに2層の全結合層を通じて768次元の最終埋め込みが生成される。 また、**Matryoshka Representation Learning（MRL）**で学習されており、768次元の出力を用途に応じて512・256・128次元に切り詰めることができる。ストレージやメモリの制約が厳しいエッジ環境での活用に有利だ。 主要フレームワークとの対応 EmbeddingGemmaは以下の主要フレームワークからすぐに利用可能だ： Sentence Transformers（検索・分類・クラスタリング） LangChain / LlamaIndex / Haystack（RAGパイプライン構築） Transformers.js（ブラウザ・Node.js上でのオンデバイス推論） ONNX Runtime（クロスプラットフォーム推論） Text Embeddings Inference（高スループットサービング） ファインチューニングで専門分野での性能をさらに強化 医療分野向けにMIRIAD（Medical Instruction and Retrieval Dataset）でファインチューニングしたsentence-transformers/embeddinggemma-300m-medicalは、医療論文からの関連パッセージ検索タスクにおいて、2倍規模のモデルをも上回る性能を示した。ドメイン特化型のファインチューニングと組み合わせることで、コンパクトなサイズ以上の実用価値を引き出せることが証明された形だ。 日本語対応への期待 100言語対応を謳う本モデルには当然日本語も含まれており、オンプレミス環境やエッジデバイスでの日本語セマンティック検索や多言語ドキュメント検索への応用が期待される。200MB以下で動作するため、クラウドAPIのコストや遅延を避けたいエンタープライズ用途にも有望な選択肢となりそうだ。 元記事: Welcome EmbeddingGemma, Google’s new efficient embedding model

mmBERT：1800言語以上に対応した最先端多言語エンコーダモデル Johns Hopkins大学のCLSP（Center for Language and Speech Processing）チームが、新しい多言語エンコーダモデル「mmBERT」を発表した。ModernBERTアーキテクチャをベースに、1800言語以上のテキスト3兆トークン以上で学習した本モデルは、従来の多言語モデルの中でも特に普及しているXLM-Rを初めて性能・速度の両面で上回る成果を達成している。 膨大な多言語学習データと革新的なサンプリング戦略 mmBERTの学習データは、3つの主要なオープンソースWebクロールデータセットを中心に構成されている。 DCLM / Filtered DCLM：高品質な英語コンテンツ。従来の多言語モデルより高い割合（最大18%）で英語データを使用し、英語性能の基盤とした。 FineWeb2：1800言語以上の多言語Webコンテンツ。幅広い言語族・文字体系をカバーする。 FineWeb2-HQ：FineWeb2から高リソース言語20言語を絞り込んだ高品質サブセット。 さらに、コードリポジトリ（StarCoder）、学術コンテンツ（ArXiv）、参照資料（Wikipedia）、コミュニティフォーラム（StackExchange）など多様な専門コーパスも組み込まれている。 データ設計の最大の革新は「プログレッシブ言語インクルージョン戦略」だ。学習を3フェーズに分け、フェーズが進むごとに言語間のサンプリング分布をより均一に近づけながら対応言語を段階的に拡大する。事前学習では60言語、中間学習で110言語、最終フェーズでFineWeb2に収録された全1833言語をカバーする。これにより、低リソース言語データを無駄なく効果的に活用できる。 アーキテクチャと3段階学習レシピ モデルアーキテクチャはModernBERT-baseと同じく22層・中間次元1152を採用しているが、多言語テキストの処理精度を高めるためにトークナイザをGemma 2のものに変更している。パラメータ数はベースモデルが非埋め込みパラメータ1.1億（語彙サイズ拡大により合計3.07億）、スモールモデルが非埋め込み4,200万（合計1.4億）。 学習は3フェーズで構成されており、2.3兆トークンの事前学習から始まり、中間学習・減衰フェーズへと進む過程でデータ品質と言語多様性のバランスを最適化している。 XLM-Rを超えた性能と日本語を含む多言語対応 BERT系の多言語エンコーダとして長らく業界標準だったXLM-Rを、性能・推論速度の両方で上回った点は注目に値する。低リソース言語への対応強化は、日本語以外の東アジア・東南アジア諸言語や少数言語コミュニティにとっても恩恵が大きい。 日本の開発者・研究者にとっても、多言語テキスト分類、情報検索（RAG）、クロスリンガルNLPタスクへの応用が期待できる。モデルはHugging Faceで公開されており、すぐに試せるサンプルコードも提供されている。 元記事: mmBERT: ModernBERT goes Multilingual

軽量VLMがGUI操作AIに進化——Hugging Faceが「Smol2Operator」の訓練レシピを全公開 Hugging Faceは、ビジョン言語モデル（VLM）をGUI自動操作エージェントへと段階的に育て上げる手法「Smol2Operator」を発表し、訓練コード・データセット・モデルをすべてオープンソースとして公開した。 GUIエージェントとは何か GUI（グラフィカルユーザーインターフェース）自動化とは、AIがスクリーンショットを「見て」、ボタンのクリックやテキスト入力といった操作を自律的に行う技術だ。モバイル・デスクトップ・Webの各プラットフォームをまたいで動作できれば、RPA（ロボティック・プロセス・オートメーション）の次世代形態として業務効率化に大きく貢献すると期待されている。国内でも業務自動化ニーズは高く、この分野の進展は注目に値する。 ベースモデルはたった2.2B 今回のアプローチでは、GUIへの接地（グラウンディング）能力をまったく持たないSmolVLM2-2.2B-Instructをベースモデルとして採用した。パラメータ数が2.2Bと小規模であるにもかかわらず、2段階の教師あり微調整（SFT）により、高レベルの指示を低レベルのGUI操作に変換できるエージェントへと成長させることに成功した。 2段階訓練プロセス 訓練は以下の2フェーズで構成される。 フェーズ1：知覚能力の習得 スクリーンショット内のUI要素を正確に認識・位置特定する「グラウンディング」能力を獲得させる段階。評価指標にはGUI理解ベンチマーク「ScreenSpot-v2」を用い、画像解像度や座標系の影響も詳細に分析した。 フェーズ2：認知・推論能力の向上 UI要素の認識にとどまらず、タスクの意図を理解して一連の操作を計画・実行できる「エージェント的推論」を付与する段階。AGUVISの研究成果とデータセットを活用し、段階的にモデルを強化した。 異種データ統合の課題を解決 複数のGUI自動化データセットを横断して学習させる際の大きな障壁が、アクション表現の非統一性だ。データセットごとに関数名・パラメータ名・操作の分類体系が異なるため、そのままでは統合的な訓練ができない。Smol2Operatorはこの問題を統一アクションスペースへの変換ツール（Action Space Converter）で解決し、高品質な訓練データを生成するパイプラインも合わせて公開している。 再現性を重視したフルオープンソース公開 Hugging Faceが今回特に強調しているのが、「最先端性能を目指すのではなく、プロセス全体を再現可能な形で示すこと」という姿勢だ。訓練レシピ・データ処理ツール・変換済みデータセット（smolagents/aguvis-stage-1、smolagents/aguvis-stage-2）・最終モデルがすべて公開されており、研究者や開発者が独自のGUIエージェント開発の出発点として活用できる。 ソースコードはGitHub（huggingface/smol2operator）で公開中。 元記事: Smol2Operator: Post-Training GUI Agents for Computer Use

Swift Transformers がバージョン1.0に到達 Hugging Faceは、Apple Silicon向けローカルLLM統合ライブラリ「swift-transformers」のバージョン1.0を正式リリースした。2年前の初公開以来、Apple開発者コミュニティで広く活用されてきた同ライブラリが、初のメジャーバージョンとして安定版を迎えた。 swift-transformersとは swift-transformers は、iPhoneを含むApple Siliconプラットフォーム上でローカルモデルを扱う際の摩擦を減らすことを目的としたSwiftライブラリだ。Core MLやMLX単独では補えない、ローカル推論に必要なコンポーネントを提供している。 主な構成要素は以下の3つ。 Tokenizers — 言語モデルへの入力準備を担うモジュール。チャットテンプレートやエージェント向けユースケースにも対応。PythonやRust向けの同名ライブラリで培ったノウハウをSwiftに移植したもの。 Hub — Hugging Face Hubとのインターフェース。モデルのダウンロード・キャッシュ・バックグラウンドでの再開可能ダウンロード・オフラインモードなどに対応する。 Models / Generation — Core ML形式に変換済みのLLMを扱うラッパー。変換済みモデルの推論実行を簡単にするためのモジュール。 v1.0の主な変更点 バージョン1.0では、Tokenizers と Hub が独立したトップレベルモジュールとして分離された。これまではパッケージ全体に依存する必要があったが、今後は必要なモジュールだけを選んでインポートできる。 また、Swift向けJinjaライブラリの新バージョンもリリースされた。開発者のJohn Mai氏との共同作業で実現したもので、チャットテンプレート処理の速度が数桁単位で向上したとされる。 コミュニティでの活用事例 同ライブラリはすでに著名なプロジェクトで採用されている。 mlx-swift-examples（Apple提供）— LLMやVLM（ビジョン言語モデル）をMLXで動かすためのライブラリ群 WhisperKit（argmax）— Apple Silicon向けに高度に最適化されたオープンソースの音声認識フレームワーク FastVLM（Apple）および各種アプリデモ 今後の方向性 Hugging Faceは今後、MLX対応とエージェント用途に注力する方針を示している。iOSやmacOS上でのローカルAIエージェント構築が現実的になりつつある中、日本のApple開発者にとっても注目度の高い動向といえる。 v1.0のリリースノートおよびマイグレーションガイドはGitHubリポジトリで公開されている。 元記事: Swift Transformers Reaches 1.0 – and Looks to the Future

NVIDIAが日本特化の合成ペルソナデータセットを公開 NVIDIAは、日本の人口統計・地理的分布・文化的特性を反映した合成データセット「Nemotron-Personas-Japan」をHugging Face上で公開した。CC BY 4.0ライセンスで提供されており、商用・非商用を問わず自由に利用できる。 なぜ今、日本語の合成ペルソナデータが必要なのか LLM（大規模言語モデル）の学習データの大半は英語であり、日本語をはじめとする非英語圏の開発者は、高品質なデータ確保に長年悩まされてきた。また、実在の個人データを利用する場合、日本の**個人情報保護法（PIPA）**への対応が複雑なハードルとなる。 Nemotron-Personas-Japanはこれらの課題を同時に解決する。合成データであるため個人を特定できる情報（PII）を一切含まず、かつ国勢調査や労働統計といった公的データに基づいて生成されているため、日本社会の実態を忠実に反映している。 データセットの規模と内容 600万件のペルソナ（100万レコード × 6ペルソナ） 1レコードあたり22項目（ペルソナ関連6項目＋統計ベースのコンテキスト16項目） 総トークン数約14億（うちペルソナ関連が約8.5億） 約95万件の固有名（合成データとして前例のない多様性） 1,500以上の職種カテゴリー 職業・スポーツ・芸術・旅行・料理などの多様なペルソナタイプ 生成には、NVIDIAのエンタープライズ向け合成データ生成マイクロサービス「NeMo Data Designer」を使用。Jinja2テンプレート、Pydanticによる検証、構造化出力、自動リトライなどの仕組みを組み合わせた複合AIパイプラインで構築されている。 日本文化への細かな配慮 単なる統計の機械的反映に留まらず、AIトレーニング上の課題を意識した設計がなされている点が特徴だ。 教育歴：国の統計では一括分類される学歴区分を細分化し、多様な教育経路を表現 職業：統計上の分類に加え、事業主や専門職などの追加カテゴリーを収録 ライフステージ：学生・退職者・失業者など、統計では目立ちにくい層も明示的にモデル化 デジタルデバイド：年齢層ごとのデジタルリテラシー格差を反映 文化的特性：日本社会固有の規範や慣習を組み込み、地域文化への理解を高める 利用シーン データセットはNemotronをはじめとするオープンソースLLMとシームレスに連携するよう設計されており、以下のような用途への活用が想定される。 マルチターン会話データの合成生成 文化的配慮が可能なドメイン特化型AIアシスタントの開発 地方・都市間、年齢層間、教育水準間でのモデル公平性検証 日本語対応チャットボットやAIエージェントのファインチューニング ソブリンAIへの布石 本データセットは、NVIDIAが推進する「ソブリンAI（Sovereign AI）」——各国・地域が自国文化と言語に根ざしたAIを自律的に開発・運用できる体制の構築——を支援するグローバルコレクションの第一弾と位置付けられている。米国向けの「US Personas」データセットに続く取り組みであり、今後も各地域向けの展開が予定されている。 データセットはHugging Faceから以下のコードで即座に取得できる。 元記事: Nemotron-Personas-Japan: ソブリン AI のための合成データセット

Intel、ローカルAIエージェント向けQwen3-8Bを最大1.4倍高速化 Intelのエンジニアチームは、Hugging Faceのブログにて、Intel® Core™ Ultra（開発コード名：Lunar Lake）の内蔵GPUを使ってQwen3-8Bの推論を最大1.4倍高速化する手法を発表した。OpenVINO.GenAIを基盤に、推測デコーディング（Speculative Decoding）と独自のレイヤー刈り込み（深度プルーニング）技術を組み合わせた成果だ。 Qwen3-8Bとエージェント用途 Qwen3-8Bは、Alibaba Cloudが開発したQwenファミリーの最新モデルで、ツール呼び出し・多段階推論・長文コンテキスト処理などエージェント向けの能力を標準で備える。Hugging Faceのsmolagents、QwenAgent、AutoGenといったフレームワークと組み合わせることで、幅広いAIエージェントアプリケーションを構築できる。 チャットボットと異なり、エージェントアプリケーションはモデルが「思考過程」をトークンとして出力しながら動作するため、トークン消費量が多く、推論速度がユーザー体験に直結するという特性がある。ローカルPC（AIPC）で高品質なエージェントを動かすには、いかに推論を高速化するかが課題だ。 推測デコーディングによる1.3倍高速化 まず基盤として、4ビット量子化されたQwen3-8BのOpenVINOモデルをLunar Lake内蔵GPUで動作させ、ベースラインを測定した。 その上で適用したのが推測デコーディングだ。この手法では、軽量な「ドラフトモデル」が複数のトークン候補を一度に生成し、それを大型の「ターゲットモデル」が一括検証することで、自己回帰的な生成ループのオーバーヘッドを削減できる。今回はQwen3-0.6Bをドラフトモデル、Qwen3-8Bをターゲットモデルとして組み合わせ、平均1.3倍の高速化を達成した。 コードはopenvino_genaiのLLMPipelineにdraft_model引数を渡すだけで利用できるシンプルな実装だ。 深度プルーニングでさらに1.4倍へ 推測デコーディングの高速化率は、ドラフトモデルの速度と精度のバランスに依存する。そこでIntelは、ドラフトモデルそのものを軽量化するアプローチを採用した。 具体的には、各レイヤーブロックの出力を角距離（Angular Distance）で評価し、モデルの精度への寄与が小さいブロックを特定して除去する。プルーニング後はファインチューニングで精度を回復させる。この手法により、Qwen3-0.6Bをさらに小型化しつつ品質を維持することに成功し、最終的に1.4倍の高速化を実現した。 smolagentsでのローカルエージェント実装 高速化された推論パイプラインは、Hugging Faceのsmolagentsと組み合わせることで、インターネット接続不要のローカルAIエージェントとして動作する。プライバシーを重視するユースケースや、クラウドAPIのレイテンシが問題になるシナリオでの活用が期待される。 日本への示唆 国内でもAIPC向けのローカルLLM活用は注目されており、Intel Core Ultra搭載機は多数流通している。今回の手法はOSSとして公開されており、OpenVINOモデルのダウンロードリンクも提供されているため、既存のハードウェアで今すぐ試せるのが大きな利点だ。エンタープライズ向けのオンプレミスAIエージェント構築にも応用できる技術として注目したい。 元記事: Accelerating Qwen3-8B Agent on Intel® Core™ Ultra with Depth-Pruned Draft Models

Starlette 1.0、ついにリリース Python非同期Webフレームワーク「Starlette」がついにバージョン1.0に到達した。FastAPIの土台として広く使われながらも、その存在が陰に隠れがちだったStarletteにとって、これは大きなマイルストーンだ。 StarletteはKim Christieが2018年に開発を開始し、Python ASGIフレームワークの新世代を代表する存在となった。FlaskとDjangoを非同期ネイティブで融合させたような設計で、KimはDjango REST Frameworkの作者でもあることから、その親しみやすさも納得できる。多くのアプリをFlask風に単一のPythonファイルで書けるのが特徴だ。 2025年9月には、長年貢献してきたMarcelo Trylesinkiにリポジトリの管理が移管され、スポンサーシップを受けやすい体制が整えられた。 主な破壊的変更：lifespanの採用 0.x系からの主な変更点は、起動・終了処理の仕組みだ。従来の on_startup / on_shutdown パラメーターが廃止され、非同期コンテキストマネージャを使った lifespan 機構に置き換わった。 元記事: Experimenting with Starlette 1.0 with Claude skills