10月12日昼のまとめ。前回はエージェントの多人数編成が品質をほとんど引き上げないという調査結果や、AmazonによるDecart買収交渉の報道が中心だった。この時間帯の収集では、LLMの能力をめぐる認識のずれを指摘する投稿が大きな反響を呼び、Microsoftからは判断特化モデルの詳細続報と、規制をめぐる痛烈な発言が届いた。ローカルLLMではAMDのゲーミングGPUで50万トークンをさばく検証が注目を集めている。

Karpathy氏「LLM能力をめぐる共有理解のギャップは拡大している」

Andrej Karpathy氏がXに「The gap in shared understanding of LLM capability is widening」（LLMの能力をめぐる共有理解のギャップが拡大している）と投稿し、Hacker Newsで大きな反響を集めた。260ポイントに対してコメントは427件と、ポイント数をコメント数が上回る活発な議論になっている。

収集データに投稿の全文は含まれていないため詳細は割愛するが、見出しとしては「LLMが何をできて何ができないかについての認識が、開発側と利用側のあいだ、あるいは利用者同士のあいだでも共有されなくなってきている」という指摘と読める。実際、同じモデル・同じベンチマークを見ていても、日々の実務で「できる」と感じることと測定値のあいだに開きがあるという経験則的な話は各所で聞かれる。AIの導入判断が現場に広まる段階で、この理解のギャップをどう埋めるかは差がつくポイントになりそうだ。

Microsoft社長「AIは牛乳より規制が少ない」

BBCの報道としてHacker Newsに届いたのが、Microsoftの社長（President）による「AIは牛乳よりも規制が少ない」という発言だ。こちらも収集データに本文が含まれていないため、発言の文脈や求められた対応の詳細は今後の報道を待ちたい。

日常の食品である牛乳との比較は、食品ですら安全性の基準と検査を通っているのに、社会の広い層に使われるAIには同等の枠組みがないという対比を際立たせる言い方だ。大手ベンダーのトップからこうした発言が出てくること自体、規制の不在が業界内でも共有された課題になりつつあることをうかがわせる。

前回の続報：Microsoftの判断特化モデル「Decision-1」はQwen3.5-9Bベース──GPT-6 Solの35倍速度、Jevと同価格

当ブログでは10月10日に、TypeSafeの「Jev」を起点に各社が一斉に「意思決定モデル」を投入する状況を紹介した。その中でMicrosoftの「Microsoft-Decision-1」にも触れたが、ITmedia AI+が詳細を伝えている。

それによると、Microsoft-Decision-1は文章を生成する代わりに、選択肢ごとの確率を返す判断特化のAIモデル。「Qwen3.5-9B」を追加学習したもので、OpenAIの「GPT-6 Sol」と比べて35倍の速度を実現しているという。価格はTypeSafeの「Jev」と同じ入力100万トークンあたり0.042ドルで、分類やエージェントの行動判定向けに提供される。

前回伝えた「初期評価者によれば一貫性と複雑な意思決定ではまだ課題が残る」という評価はそのままに、ベースモデル・速度・価格という具体的な中身が見えてきた形だ。判断特化モデルのカテゴリが価格と性能の両面で競争段階に入りつつある。

ローカルLLM：AMD 7900 XTXで50万トークンの「Strata」──日本語圏でも検証ラッシュ

ローカルLLMコミュニティでは、RedditのLocalLLaMAに、AMDのゲーミングGPU「Radeon 7900 XTX」でQwen3.8-Flash-Next（Strata）を日常環境として運用しているという詳細な報告が上がった。

構成は、総パラメータ176B・1トークンあたり6Bが活性化するMoEモデルについて、重み66.4GBのうち23.8GiBをVRAMに常駐させ、エキスパート重み31.6GBとPLEテーブル28.8GBをシステムRAMに置くというもの。生成速度（decode）は105〜160 tok/s、コンテキストは50万トークンに設定し、実測でも506,849トークンを保持できたという。品質は4k・64k・256kの各コンテキストで、思考機能オフ時に81〜84%、オン時に88〜94%を維持。コンテキストが深くなると生成速度は18%落ちるものの、品質は落ちないとしている。

投稿にはトラブルシューティングの記録も含まれる。以前の稼働で、モデルが自分の以前の推論をそのまま反復する「エコー」が約13,000ターン中266回発生したが、原因はモデルではなくpreserve_thinking: true設定が毎回のプロンプトに過去の推論を差し戻していたためと特定され、設定を外したことで問題は消えたという。ゲーミングリグ1台で50万トークンの文脈を保持できる時代になりつつある。

日本語圏でも同系統の検証が相次いだ。Zennの記事は、VRAM 6GBの古いゲーミングカードRTX 2060と64GBのシステムRAMで、同じくStrata経由のQwen3.8-Flash-Next（125B・Q2_0量子化）が動くかを約9,000字で検証した。Strataの新版v0.1.42でも測り直し、結果はほぼ同じだったと追記している。同じくZennではM5 Pro・64GBのMacBook Proでllama.cppとMac向けMLX系エンジン（MTPLX）の速度・メモリ使いを比較した記録が、QiitaではEVO-X2（Ryzen AI Max+ 395・128GB）でllama-benchとllama-cliのプロンプト処理速度がなぜ違うのかを突き詰めた記事が公開された。

さらにZennでは、オープンソースのエージェント基盤「Hermes Agent」を16GB VRAMのローカルLLMだけで動かし、tool-callingで詰まった3点を記録した記事も公開されている。「チャットが得意なモデルと、ツールを呼べるモデルは別物」といった実測に基づく知見が並んでおり、ローカルでエージェントを回す最初の壁を越える助けになりそうだ。

日本の現場から：エージェントに見せるツールは「170個→15個」──Postmanの本番設計

AIエージェントの実務設計では、Postmanの事例を紹介するZenn記事が示唆に富む。API開発ツールのPostmanは、エージェントに社内システムを操作させるにあたり、MCPサーバーを追加しAPIごとにツールを作って170個まで増やしたところ、様子がおかしくなったという。「承認して」と頼んだのに中身を表示するだけのツールを呼ぶ、存在しない名前のツールを呼ぶ、引数の形が微妙に違う──ツールを増やしたのに、かえって仕事ができなくなるのだ。

その結果、本番ではツールを15個に絞り込んだという。「できることを増やす」ことから「確実に動く形に絞る」ことへの転換で、エージェント設計の勘所を突いた事例だ。

同じくZennでは、Claudeのサブエージェント設計を扱った記事も公開された。多数の論文PDFを1つのチャットで順に読ませると、読み終えた内容がコンテキストに溜まり続けて後半ほど不利になるため、サブエージェントに1本ずつ処理させる構成と、その指示文の設計を整理している。内容を「公式確認・経験・推測」に区別して書く姿勢も可信性を高めている。さらに、常駐エージェントの応答生成を安全に中断する設計では、生成中にユーザーから新しいメッセージが届いたとき、無視して続けると的外れな長文が後から届き、逆に強制終了すると発火済みのツール呼び出し（メール送信やチケット更新）だけが宙に浮くという問題と、その解決設計が整理されている。

小ネタ：6Mパラメータで画像を生成する「AuroraIMG-6M」

LocalLLaMAでは、総パラメータ6Mのテキスト→画像モデル「AuroraIMG-6M」が公開された。6MにはテキストエンコーダもVAEもすべて含まれており、64×64ピクセルながら認識可能な画像を生成できるという。モデルの小型化の極北のような作品で、アーキテクチャや学習の詳細はHugging Faceのモデルカードで公開されている。