9月1日夜のAIニュースからは、VLM(視覚言語モデル)の空間知能をそのままロボット制御に転用する汎用ナビゲーションモデル「LightNav-0」と、エージェントが書いた複数アプリの共通部分をライブラリとして育てる「Super Library Agent」が目を引いた。llama.cppではQwen向け修正のマージラッシュとApple Silicon向けのMetal最適化が進む。日本語圏からは、Claude Codeのトークン消費を実測した記事と、開発半ばのアプリを生成AIに「数秒で」再現されたという体験記を取り上げる。
VLMの空間知能でロボットを誘導する「LightNav-0」
Hugging Face Daily Papersに掲載されたLightNav-0は、事前学習済みVLMがすでに持つ空間的な事前知識──視覚的グラウンディング、空間推論、ポインティング──を、タスク固有の予測ヘッドを追加せずにナビゲーションへと転用するコンパクトな汎用モデルだ。
仕組みの核は統一されたトークンインターフェースにある。タスク・シーン・ロボットの身体構成に依存しない空間的な意図を2チャネルのポインティングで表現し、残差ベクトル量子化のアクショントークナイザで身体固有の軌道へ変換する。時間を考慮した視覚履歴の圧縮、ERミッドトレーニング、教師ありファインチューニング、強化学習を組み合わせた訓練により、指示追従からオープンボキャブラリの物体ナビゲーション、視覚追跡までを単一モデルでこなすという。
訓練コーパスは2,000シーン超・4,000時間超の身体性ナビゲーションデータに及ぶ。中間チェックポイントのLightNav-ERは8つのembodied-reasoningベンチマークで完全セットの最高平均を達成し、LightNav-0自身は10の公開ナビゲーションシミュレーション設定すべてで単眼カメラのみの成功率が最先端となったとしている。実機評価でも、異なるロボット身体や多様なシーン、静止・動的の両方のターゲットに対してゼロショットで汎化したという。
これまでのナビゲーション系システムは、タスク別・身体別の専用コンポーネントを積み上げる設計が主流で、汎化が利きにくいという課題があった。コンパクトなVLMを統一バックボーンとして使い回せる可能性を示した点で、身体性AIの設計思想に影響を与えそうな研究だ。
エージェントが複数アプリを書くときはライブラリを育てる──「Super Library Agent」
同じくDaily Papersに登場したSuper Library Agent(SLA)は、エージェントが複数の関連アプリを順に書く場面を対象にする。各アプリが同じ部品を再実装していく代わりに、共通部分をライブラリとして抽出し、ライブラリの成長に合わせて過去のアプリを順次移行していくというアプローチだ。
WebGen-Benchでの比較では、同じ8つのアプリを独立に生成した場合に対して、冗長なコードが38%減、総行数が9%減。すべてのアプリに新しい要件が降ってきたときのパッチは3.7倍小さくて済み、精度は変わらなかったという。PaperBenchでも同じ傾向が確認されたが、差は小さめだったとしている。
人間のソフトウェア開発では当たり前の「共通化とライブラリ管理」を、エージェントによる継続的なアプリケーション開発に持ち込んだ点が面白い。生成コードの保守コストが問題になり始めている今、エージェント評価の軸としても参照されそうだ。
llama.cppはQwen修正のマージラッシュとMetal MoE最適化
ローカルLLMランタイムのllama.cppでは、ここ数日で複数の動きが重なっている。
1つはQwen Flash Next(qwen4exp)向けの修正群だ。RedditのLocalLLaMAに投稿されたまとめによると、同モデルの利用者はビルドをこまめに更新すべき状態が続いており、多数の修正プルリクエストがすでにマージ済み。PR #28032は0cc4m氏がマージした一方、unslothのDaniel Han氏(danielhanchen)による#27941や、MTP対応とみられる#27836などは現在進行中という。
もう1つはApple Silicon向けのMetal最適化。別のReddit投稿によると、MoEモデルのIQ3_XXS量子化におけるデコードを高速化するPR #28086が提案され、投稿者のテストワークロード(35B総パラメータ・活性化3Bクラスのコーディングモデル)では約65.6トークン/秒から73.9トークン/秒へと1割強の改善があったという。prefillを改善するフォローアップも予定しているとのことだ。
Claude Codeのトークン消費は1ターン23万──効いた節約は「セッションを切る」
Qiitaでは、Claude Codeを3日間動かしてトークン消費を実測した記事が注目を集めている。投稿者はデータ収集・分析・検証を複数のエージェントに分担させ、24時間稼働の構成で運用。そのなかでいちばん高くついたのはエージェントの数ではなかったという。1ターンあたり23万トークンに達する消費が記録され、節約に効いたのは意外と単純な「セッションを切る」ことだったそうだ。
長く続いた会話の履歴がそのままコンテキストとして積み上がり課金に響く構造だけに、エージェント運用のコスト管理は並列数よりもコンテキストの寿命をどう設計するかが鍵になりそうだ。
数日かけて育てたiOSアプリを、Googleの最新AIに「数秒で」作られた話
同じくQiitaの体験記では、開発半ばのiOSアプリをGoogleの最新AIに「たった数秒」で再現された経験が綴られている。UIはほぼ完成し、コア機能も動き、残すは細かい調整と書き出しロジックだけだったプロジェクト。その完成形が目の前で数秒で組み立てられた瞬間、投稿者はしばらく放心状態だったという。どのモデルを指すのかは記事の趣旨ではなく割愛するが、開発側に積み上がりつつあるこの種の実感は、ツールの性能評価以上に重い一次記録になりそうだ。
その他──自社製品の改名を知らないAIアシスタント、レムの「予言」
小ネタが2つ。Atlassianのコミュニティフォーラムでは、Jiraが「Projects」を「Spaces」に改名したのに自社のAIアシスタントがその事実を知らない、という指摘がHacker Newsで話題になっている。学習データの陳腐化を地でいく事例だ。また、SF作家スタニスワフ・レムが1964年の著作に現在のLLMブームを予言する記述を残していたとするブログ記事も注目を集めた。60年以上前にこの手の熱狂を見抜いていたとすれば、それはそれで読み応えがありそうだ。
