1. Z.aiが100万トークンのコンテキストウィンドウを持つオープンウェイトモデル「GLM-5.2」をリリース
このモデルには、スパースアテンション層全体でインデクサーを再利用し、最大コンテキスト長での計算FLOPを2.9倍削減する「IndexShare」などのアーキテクチャ最適化が組み込まれています。また、推論中に受け入れトークン長を最大20%向上させる推論加速用のMulti-Token Prediction層も含まれています。開発者は、月額12.60ドルからの新しい「GLM Coding Plan」を通じてモデルにアクセスすることも可能です。
- • GLM-5.2は、制限のないMITライセンスでリリースされた7530億パラメータのオープンウェイトモデルです。
- • 100万トークンのコンテキストウィンドウを備え、推論の深さを調整する「Max」および「High」思考モードをサポートしています。
- • SWE-bench Proで62.1、FrontierSWEで74.4を記録し、両ベンチマークでGPT-5.5を上回りました。
- • APIアクセス料金は、入力100万トークンあたり1.40ドル、出力100万トークンあたり4.40ドルです。
- • 本モデルはHugging Face、ローカル実行用のOllama、およびZ.ai APIで即時利用可能です。
開発者は、クローズドソースのフロンティアモデルに匹敵する高性能なMITライセンスのコーディングモデルを、低コストでセルフホストまたはAPI経由で利用できるようになります。
2. SubQ 1.1 Small、サブ二次アテンションにより1200万トークンのコンテキストを実現
このモデルは、段階的なコンテキスト拡張と、それに続く約1兆トークンの長文アーティファクトを用いた継続的な事前学習によってトレーニングされました。これらのベンチマーク結果はAppenによって独立して検証されており、極端なコンテキスト長に対するサブ二次アテンションの有効性が実証されています。
- • SubQ 1.1 Smallは、Subquadratic Sparse Attention (SSA) モデルアーキテクチャの第2世代です。
- • 「needle-in-a-haystack（干し草の中の針）」テストにおいて、最大1200万トークンまでほぼ完璧な長文検索精度を達成しました。
- • 100万トークンのコンテキストにおいて、密なアテンション（dense attention）と比較して計算量を64.5倍削減し、FlashAttention-2より56倍高速に動作します。
- • RULERベンチマーク（128Kトークン）で99.12%、GPQA Diamondで85.4%を記録しました。
- • 現在一部の設計パートナー向けに展開されており、2026年後半に広くリリースされる予定です。
開発者は、計算要件を大幅に削減し、推論速度を向上させながら、膨大なコードベースやドキュメントセットをローカルで処理できるようになります。
3. Claude Fable-5から蒸留されたオープンウェイトモデル「Qwable-v1」が登場
Claude Fable-5はAPI内の思考ブロックを隠蔽するアンチ蒸留分類器を備えていましたが、研究者はクリアテキストのトレースで学習させることでこれを回避しました。結果として得られたQwable-v1モデルとそのSFTデータセットはHugging Faceで公開されており、複雑なソフトウェアエンジニアリングタスクのためのローカルな代替手段を提供します。
- • Qwable-v1はQwen3.6-35B-A3Bアーキテクチャに基づいており、AGPL-3.0ライセンスでリリースされています。
- • 米国の輸出管理指令により短期間で公開停止となったClaude Fable-5から蒸留されました。
- • Glint-Research/Fable-5-tracesコーパスから抽出された4,659件のクリアテキスト自律型コーディングトレースで学習されました。
- • NVIDIA H200 GPU 1基で約14時間のトレーニングを経て作成されました。
- • Qwable-v1は、str_replace_editorツールを含むXML形式のツール呼び出しを出力する能力を保持しています。
開発者は、高価で制限の多いAPIに頼ることなく、自律型コーディングタスクやXML形式のツール呼び出しに最適化されたローカルのオープンウェイトモデルを実行できます。
4. 3Bの推論モデル「VibeThinker-3B」がフロンティア級のコーディングスコアを達成
このモデルの未知のコーディング課題に対する高い成功率は、その小型サイズにもかかわらず強力な汎化能力があることを示しています。アーキテクチャとトレーニング手法の詳細を記した研究論文はHugging Faceで公開されています。
- • VibeThinker-3Bは、パラメータ密度の高い環境で検証可能な推論をテストするために設計された小型言語モデルです。
- • 最近の未知のLeetCodeコンテストで96.1%の成功率を達成し、128件のPython提出のうち123件を初回試行でパスしました。
- • AIME'26数学ベンチマークで94.3、LiveCodeBench v6で80.2を記録しました。
- • 評価設定にはvLLMおよびSglangを使用し、temperature 1.0、top_p 0.95で実行されました。
開発者は、ローカルでの低遅延なコーディングや数学的推論タスクのために、非常にコンパクトな30億パラメータのモデルを活用できます。
5. Microsoft、リポジトリ探索用モデル「FastContext 4B」をリリース
リポジトリ探索はコーディングエージェントにとって大きなボトルネックであり、多くの場合、巨大なコンテキストウィンドウや高価な検索クエリを必要とします。FastContextは、エージェントが大規模リポジトリからコードをナビゲートし取得する方法を効率化する、軽量で専門的な代替手段を提供します。
- • FastContextは、MicrosoftがHugging Faceで公開した40億パラメータのモデルです。
- • コーディングエージェントによる効率的なコード検索とリポジトリ探索に特化して最適化されています。
- • オープンソースのコーディングエージェントが、SWE-Bench Multilingualベンチマークでクローズドソースモデルと競合することを可能にします。
- • 本モデルは研究論文「FastContext: Training Efficient Repository Explorer for Coding Agents」に基づいています。
開発者は、この専門的な4Bモデルをコーディングエージェントのパイプラインに統合することで、高価なクローズドソースモデルに頼ることなく、リポジトリ規模のコード検索性能を向上させることができます。
6. Microsoft、2FAコードを漏洩させるCopilotの重大な脆弱性を修正
この攻撃チェーンは、サードパーティのコンテンツに埋め込まれたマークアップ言語やHTMLタグを使用して、LLMにWebリクエスト経由でデータを流出させる方法を示しています。Microsoftは先週この脆弱性を修正しましたが、この攻撃ベクトルは外部データを処理するエージェントワークフローのセキュリティにおける継続的な課題を浮き彫りにしています。
- • この脆弱性により、攻撃者はCopilotがアクセス可能なメールから2FAコードや機密データを取得することが可能でした。
- • セキュリティ企業Varonisは、URLクエリパラメータを介した「Parameter-to-Prompt Injection」を使用して攻撃チェーンを開発しました。
- • この攻撃は、出力をブロックで囲んだり、信頼できないWebサイトを制限したりするMicrosoftの既存のガードレールを回避しました。
- • 根本的な原因は、LLMがユーザーの指示と信頼できないサードパーティのコンテンツを区別できないという基本的な性質にあります。
LLMアプリケーションを構築する開発者は、サードパーティのコンテンツがモデルの指示を乗っ取り、機密ユーザーデータを流出させることを防ぐ必要があります。
7. CursorとGraphiteのエンジニアが、エージェントファーストのGit代替「Origin」を発表
Gitのような従来のバージョン管理システムは、複雑なブランチやマージ競合のため、自律型エージェントがナビゲートするのが難しい場合があります。Originは、エージェントフレンドリーなインターフェースと自動解決ツールを提供することでこれに対処し、コーディングエージェントを本番環境のCI/CDパイプラインに直接統合しやすくします。
- • Originは、AIエージェントのワークロードに対して高度にスケーラブルになるよう設計された新しいバージョン管理プラットフォームです。
- • APIおよびModel Context Protocol (MCP) を通じて完全に拡張可能です。
- • マージ競合の解決とCI/CD障害の解決のための自動化ツールが組み込まれています。
- • 本製品はCursorおよびGraphiteのエンジニアであるTomas Reimers氏によって発表されました。
開発者は、ネイティブAPI、MCPサポート、自動競合解決を使用して、バージョン管理とより確実にやり取りするエージェントワークフローを構築できます。
8. スタンフォード大学のDeLM、オーケストレーターなしでマルチエージェントのコストを50%削減
従来のマルチエージェントシステムは中央オーケストレーターに依存しており、これが重大な通信オーバーヘッドとAPIコストを発生させていました。DeLMは連携を分散化し、エージェントが共有の「gist（要点）」データベースを読み書きできるようにすることで、実行を並列化し、冗長なLLM呼び出しを排除します。
- • DeLMは、「gist」と呼ばれる要約の共有ナレッジベースとタスクキューを使用して、AIエージェントが直接連携することを可能にします。
- • このフレームワークはタスクコストを約50%削減し、SWE-bench Verifiedにおいて最強のベースラインよりも10.5%優れたパフォーマンスを発揮しました。
- • エージェントは、検証済みの発見、文書化された失敗、制約を共有し、冗長な探索を防ぎます。
- • 展開可能なシステムがデフォルトでコンパクトな要約を提供し、エージェントが必要なときにのみ詳細な証拠にアクセスできるようにします。
- • DeLMは、LongBench-v2 Multi-Doc QAベンチマークにおいて、4つの主要なモデルファミリー全体で最高の精度を達成しました。
開発者は、中央オーケストレーターの遅延や通信のボトルネックを回避し、高度に並列化された費用対効果の高いマルチエージェントアプリケーションを構築できます。
9. Databricks、リアルタイムAIエージェント向けに「Lakehouse//RT」と「LTAP」を発表
AIエージェントは、従来のETLパイプラインの遅延により、古いデータに悩まされることがよくあります。Databricksは、ストレージ層で直接トランザクション処理と分析処理を組み合わせることでデータスタックを簡素化し、エージェントがリアルタイムの運用データに基づいて意思決定を行えるようにすることを目指しています。
- • Lakehouse//RTは、DeltaおよびIcebergテーブルに対して100ミリ秒未満のクエリレイテンシを実現し、専用のリアルタイム提供層を不要にします。
- • Reyden計算エンジンは、高並列かつ低レイテンシの提供を処理し、毎秒最大12,000クエリに達します。
- • LTAP (Lake Transactional/Analytical Processing) は、書き込み時にPostgresネイティブのトランザクションデータを自動的にDeltaおよびIceberg形式で保存します。
- • このアーキテクチャは、サーバーレスのクラウドベースPostgreSQLデータベースサービスであるLakebaseを利用して、ストレージ層でデータを統合します。
- • LTAPは、ネットワークコストを最小限に抑えるために、キャッシュ層で行から列への変換を実行します。
開発者は、複雑なETLパイプラインを必要とせず、100ミリ秒未満のレイテンシでライブの運用および分析データベースを直接クエリするAIエージェントを構築できます。
10. Rust用「cuTile」が安全で高性能なGPUカーネル開発を実現
カスタムCUDAカーネルの記述は、エラーが発生しやすくデバッグが困難であることで有名です。cuTile Rustは、Rustのコンパイル時安全保証をGPUプログラミングにもたらすことでこれに対処し、Apache License 2.0の下で同期起動、非同期パイプライン、CUDAグラフのリプレイをサポートしています。
- • cuTile Rustは、プロシージャルマクロを使用して、RustのASTをCUDA Tile IR経由でGPU cubinにJITコンパイルします。
- • NVIDIA B200 GPU上でGEMMに対して2 PFlop/sを達成し、密なf16ピークパフォーマンスの92%に相当します。
- • cuTile上に構築されたGrout推論エンジンは、RTX 5090上でQwen3-4Bを毎秒171トークンで実行します。
- • このシステムは、GPU起動境界を越えてRustの所有権規律を拡張し、データ競合を防ぎます。
- • compute capability sm_80以上のNVIDIA GPU、CUDA 13.3、およびRust 1.89以降が必要です。
カスタムローカル推論エンジンを構築したり、モデル実行を最適化したりする開発者は、生のCUDAパフォーマンスを犠牲にすることなく、Rustで安全なGPUカーネルを記述できます。
11. PythonのAST解析を220倍高速化するライブラリ「Fast-Walk」
エージェントがコードを反復的に生成および検証する場合、標準のPython AST解析が大きなボトルネックになる可能性があります。標準ライブラリのast.walkをこの最適化されたRust実装に置き換えることで、開発者はコーディングエージェントの検証ループを加速できます。
- • fast-walkライブラリは、生成されたPythonコードを処理する際のReflex AIリンターのパフォーマンスボトルネックを解決するために開発されました。
- • PyO3を使用してウォーキングロジックをRustに移植したことで、初期段階で78%の累積パフォーマンス向上が得られました。
- • 直接的な辞書アクセスや2KBのテーブルでのASTサブクラス情報の事前計算などの最適化により、最終的に220倍の高速化を達成しました。
- • ソースコードはオープンソースであり、GitHubのreflex-dev/fast-walkリポジトリで入手可能です。
コード生成ツール、リンター、またはLLMエージェントを構築する開発者は、Python ASTの解析と分析のレイテンシを劇的に削減できます。
12. FireworksとLangChain、100倍安価なチャットボットトレース判定器を構築
チャットボットのやり取りを評価するには、通常、判定器として高価なフロンティアLLMが必要です。FireworksとLangChainは、特定のやり取りトレースで小型の専門モデルを微調整することで、高いAPIコストをかけずに本番グレードの評価精度を達成できることを実証しました。
- • トレース判定器はQwen-3.5-35Bモデルに基づいており、ユーザーが特定したエラーを検出するように設計されています。
- • chat-langchainデータでモデルを微調整することで、フロンティアモデルのパフォーマンスを満たすか、それを上回ることができました。
- • 微調整された判定器は、評価にフロンティアモデルを使用する場合よりも約100倍低いコストで動作します。
開発者は、トレース評価のためにフロンティアモデルを使用する場合と比較して、わずかなコストでチャットボットのパフォーマンスを評価および監視できます。
13. Artificial Analysis、エージェントワークロードに焦点を当てたIntelligence Indexを更新
更新されたGDPval-AA v2ベンチマークは、Eloを人間のパフォーマンス（1000）に再ベース化し、フロンティアモデル判定器のローテーションパネルを利用し、ターン制限を250に引き上げました。インデックス内のタスク完了時間は、Grok 4.3 (high) の1.5分からClaude Sonnet 4.6 (max) の13.5分まで幅広くなっています。
- • Intelligence Index v4.1では、タスクごとのコスト、タスクごとの時間、タスクごとのトークンという3つの新しいメトリクスが導入されました。
- • この更新により、Terminal-Bench 2.1やτ³-Bench Bankingを含むいくつかのベンチマークがアップグレードされ、飽和状態のIFBenchが削除されました。
- • Claude Opus 4.8 (max) がスコア56で利用可能なモデルをリードし、GPT-5.5 (xhigh) が55で僅差で続いています。
- • DeepSeek V4 Pro (max) とMiniMax M3がオープンウェイトカテゴリをリードしており、両者とも44を記録しています。
- • インデックスによると、DeepSeek V4 Pro (max) はタスクあたり0.04ドルですが、Claude Opus 4.8は1.78ドル、GPT-5.5 (xhigh) は0.99ドルとなっています。
開発者は、タスクごとのコストや実行時間といった具体的なエージェント重視のメトリクスを使用して、フロンティアモデルとオープンウェイトモデルを比較できます。
14. 小規模なClaude蒸留モデルのパフォーマンス問題に警告
蒸留モデルは、より小さなオープンウェイトパッケージでフロンティアレベルの能力を約束しますが、微調整データの量が少ないため、複雑な推論行動を捉えきれないことがよくあります。開発者は、蒸留されたバリアントが本質的にベースモデルよりも優れていると想定するのではなく、特定のユースケースに対して独立した評価を実行することが推奨されます。
- • 最近の蒸留では通常4,000〜10,000サンプルしか使用されておらず、モデルの品質を向上させるには少なすぎる可能性があります。
- • これらの蒸留モデルは、ベースのQwen 3.6モデルと比較して、ハルシネーションの増加やパフォーマンスの低下を示す可能性があります。
- • DeepSeek-R1のような成功した蒸留には、通常約70万サンプルというはるかに大規模なデータセットが必要です。
- • Claude Opus 4.8から蒸留されたQwopusモデルは、ハルシネーションと実行速度の低下を示すことが報告されています。
開発者は、不適切にトレーニングされた蒸留モデルをデプロイすることによって生じるアプリケーションのパフォーマンス低下やハルシネーションを回避できます。
15. ローカルエージェントコーディングのためのセットアップとベンチマーク
過去6ヶ月間でローカルモデルはプログラミングタスクにおいて大幅に能力が向上しましたが、著者はまだ本番環境のソフトウェア開発の準備はできていないと指摘しています。実行中のシステムアクセスを制限するために、推論サーバーとエージェントハーネスをDockerでサンドボックス化することが推奨されています。
- • このセットアップでは、64GBのRAMを搭載したM2 Mac上で、Gemma 4モデルファミリー（具体的にはgemma-4-26b-a4bおよびgemma-4-12b-qat）を利用しています。
- • ローカルエージェントコーディングは、クローズドソースのフロンティアモデルの精度と速度の約75%で動作すると推定されています。
- • アーキテクチャは、推論サーバーとしてLM Studioを、エージェントハーネスとしてPiを実行し、両方ともDockerコンテナ内でサンドボックス化されています。
- • 主な制限には、遅い推論速度、限られたコンテキストウィンドウ、プロンプトテンプレートの不一致が含まれます。
開発者は、この現実世界のアーキテクチャを参照してローカルのサンドボックス化されたコーディング環境をセットアップし、現在のパフォーマンスのトレードオフを理解できます。
16. Anthropic、Claude Agent SDKのトークンベース課金への移行を一時停止
5月13日に発表された当初の課金変更は、Claude Agent SDKの使用を、標準のチャットインターフェースや公式CLIの使用とは別に扱うことを目的としていました。分析によると、Claude Opusのサブスクライバーは、現在のサブスクリプションモデルの下で1日あたり2〜3通のメッセージを送信するだけで、API使用コストを節約できる可能性があります。
- • Anthropicは、6月15日に予定されていた価格変更を直前に一時停止しました。
- • Agent SDKユーザーは、個別のAPI料金を請求されるのではなく、既存のClaudeサブスクリプション制限を引き続き使用できます。
- • 一時停止されたプランでは、SDKの使用に対して標準のAPI料金を請求し、サブスクリプション価格と同等の月額クレジットで相殺する予定でした。
- • 現在のサブスクリプションティアでは、Agent SDKの使用は標準の週次上限によってのみ制限されます。
Claude Agent SDKを使用して構築する開発者は、予期しないAPI料金を回避し、エージェントワークロードに対して既存のサブスクリプション上限を引き続き活用できます。