エージェント間メッセージングが一気に現実に

Latent Spaceは今週の動向を整理する中で、ソフトウェア界の有名な格言をもじった「Zawinskiのマルチエージェントの法則」という言葉を半ば冗談で紹介した。「すべてのエージェントは、他のエージェントとメッセージを交換できるようになるまで膨張し続ける。そうできないエージェントは、できるものに置き換えられる」という命題だ。背景にあるのは、複数のエージェントを束ねる階層構造ではなく、スレッド同士が自由に通信するパターンへの関心が急速に高まっていること。Black Hatで話題になった事例でも、モデルが社内のパッケージ管理を「伝言板」代わりに使って複数回の実行をまたいで連携したと報告されており、マルチエージェントの相互作用や隠れた調整チャネルがもはや例外的な問題ではなく、中心的な研究テーマになりつつある。

その流れに呼応するように、インフラ側も揃いつつある。LangChainは「Managed Deep Agents」をパブリックベータで公開し、プロトタイプから本番スケールまでを支えるとしている。次のボトルネックは「エージェントにツールとUIを与えること」ではなく、アイデンティティ・メモリ・権限・資格情報の管理、ユーザーサービスとの統合だという指摘も出ている。Prime Intellectも自社のRLスタックにマルチエージェント対応を追加し、エージェント間の任意の相互作用、エージェントによる評価、自己対局、ユーザーシミュレーションなどを可能にした。安全性の議論が「エージェント群の創発的振る舞い」に向かう一方で、製品チームはまさにそのシステムを訓練・展開するインフラを競って作っている。

Claude Codeが「autoモード」をデフォルト化、危険コマンドを89%検出

AnthropicはClaude Codeにセッション間メッセージングを導入した。あるセッションが別のマシン上の別セッションに要約を送れる仕組みで、ファイルや履歴を丸ごと転送せずに済む。併せて、Pro/Max/Teamのユーザーでは「autoモード」がデフォルトの権限モードになる。シェルコマンドや操作を別の分類器で審査する仕組みで、社内テストでは危険なコマンドの**89%**を捕捉したという（手動承認のみでは14%）。さらにセッションごとの予算設定、リポジトリのスキル自動読み込み、セッション途中で呼べる「advisor」モデルなど、マネージドなエージェント運用に向けた機能が相次いで追加された。エージェントを安全に本番で動かすための制御層が、製品として整備され始めた形だ。

コーディングエージェントでは「ハーネス選び」がモデル選びより効く

SWE-bench Proを用いた比較で興味深い結果が出た。モデルを替えるよりも、エージェントを囲む**ハーネス（足場）**を替える方がpass@1に大きな影響を与えたというのだ。引用された実行結果では、GLM-5.2で23%〜52%、Gemma 4 26Bで15%〜36%と、ハーネス次第で大きくブレた。しかもモデル間でハーネスの優劣ランキングはほとんど転移せず、順位相関は-0.05だった。実用的な含意は大きい。「適切な足場に乗った26Bモデル」が「不適切な足場に乗った744Bモデル」に迫り得るということだ。また入力トークンの97%が繰り返し会話の前置きだったとも指摘されており、プロンプトキャッシュの重要性も浮き彫りになった。最適なのは単一の旗艦モデルではなく、ルーティングとハーネスと予算管理の組み合わせだ、との見方が強まっている。

Qwen3.8-Max（2.4T-A95B）が来週、オープンウェットで公開へ

コミュニティの注目を集めるQwen3.8-Maxのオープンウェット版が、来週中に公開される見通しとなった。ModelScopeに「Qwen3.8-2.4T-A95B」のページが用意されたもので、Qwen-Maxクラスでは初のオープンウェットモデルとされる。「A95B」はアクティブパラメータ約950億を示唆し、コーディングや研究、長期タスクの改善を掲げている。より小型のQwen3.8-27Bなどは後日、別ページで順次公開される見込み。なお、一部で「Agentic IndexでQwen3.8-Maxが1位」との声が上がったが、リンク先の画像ではClaude Opus 5が59.2、Qwen 3.8 Maxが58.4と逆転しており、順位の主張には疑義が出されている。ローカル実行を想定すると、2.4Tクラスの重みを支えるストレージ帯域の壁も話題になった。

動画生成モデルの高速化競争: MiniMaxは4日で蒸留LoRA、Seedance 2.5は30秒生成

動画生成の反復速度も目を見張る。MiniMaxは、オープンウェット化して間もなくコミュニティが4日でサンプリングを20ステップから4〜8ステップに減らす蒸留LoRAを作ったと報告。これぞオープン化の意義だとしている。一方、Seedance 2.5がfal、Krea、Runwayなどを通じて展開され、30秒の連続生成やマルチショット、最大50件の参照画像、指示への追従と一貫性の改善が打ち出された。生成品質だけでなく「いかに速く、いかに長く」という軸で、実用的な編集ワークフローへの組み込みを狙う動きが際立つ。

推論インフラ最前線: 66 MiBのvllm.cpp、9倍圧縮のQdrant、25K tok/sのvLLM

モデル本体よりも、それをどう動かすかというシステム側の工夫が差別化になりつつある。三つの動きが並ぶ。第一に、vLLMのサービングスタックをC++20に移植した「vllm.cpp」が注目を集めた。推論時にPythonを含まず66 MiBのバイナリで動き、継続バッチングやページングKVキャッシュ、推測デコード、CUDA/Metal/CPU対応、OpenAI互換サーバーを維持したまま、出力をvLLMとトークン単位で照合したという。10GB近くになるvLLM環境と比べ、デプロイの軽量化が狙いだ。第二に、ベクトルDBのQdrant 1.19は「Turbo4」を導入。4bitのベクトル表現だけを保存し、float32と比べて9倍のストレージ削減を実現した（再スコアリングはトレードオフ）。第三に、vLLMとNVIDIAはQwen 3.5のサービングをGB200上で1GPUあたり25Kトークン/秒まで最適化した事例を公開。Blackwell向けカーネル、ハイブリッドキャッシュ、レースフリーの非同期スケジューリングなどの組み合わせによる。