8月23日のAIニュースまとめ。今回は、OpenAI幹部によるサイバー攻撃への警告、Qwen向けチャットテンプレートの改良でコーディングを速くする試み、手元のMacとGPUでローカルLLMを使い倒す3つの最適化事例、中間層ループを個人で再現した実験、そして国内のLLM運用記事2本をまとめてお届けする。

OpenAI幹部が「持続的」AIサイバー攻撃の脅威を警告

OpenAIのChris Lehane氏が、AIによる「持続的（persistent）」サイバー攻撃の脅威について言及したと、英ガーディアンが報じた。Hacker Newsでも話題に取り上げられている。

今回収集できたのは見出しレベルの情報で、発言の詳細な文脈は現時点では確認できていない。ただ「持続的」という表現が示すのは、単発ではなく継続的に仕掛けられる攻撃の姿だ。生成AIで攻撃準備のコストが下がれば、防御側は都度対応ではなく常時の監視を強いられる。攻撃と防御の非対称性がさらに広がる可能性を指摘した報道と読める。続報を待ちたい。

Qwen向けチャットテンプレート「Sharp」──余計な思考を削り、実タスクで中央値2.5倍速

Qwen 3.5／3.6／3.8向けのチャットテンプレート改良版「Qwen-Sharp-Chat-Templates」がHugging Faceで公開され、トレンド入りしている。ベースはfroggeric氏による修正テンプレート（v22.3）で、そこに「簡潔に答える」ことを求めるシステムプロンプトを強制付加したものだ。

工夫の中心は、前置きや質問の復唱、つなぎの冗長な文を禁止しつつ、必要な手順・注意点・不確実性は落とさない指示設計にある。Qwen3.8-27B（medium effort）では、より少ない思考トークンで精度を維持でき、実際のリポジトリ修正タスクでは在来テンプレートと同程度のissueを解決しながら、中央値で約2.5倍速くなったという。

面白いのは副次効果だ。前ターンの思考を捨てずに保持することで、2ターン目以降のプロンプトキャッシュが確実にヒットするようになり、最初のトークンが出るまでの時間も短縮される。簡潔指示はv22.3.2でリクエスト単位のオン／オフが可能になり、GGUF形式のモデルも再量子化なしでテンプレートだけ書き換えられる。

ただし個人リポジトリであり、効果の数値は27Bモデルでの測定で、モデルによって効き方が違うと作者自身が注意を促している。導入するなら自分のモデルとタスクで計測するのが筋だろう。

ローカルLLMの実機最適化はさらに加速──M2 Ultraのロスレス141GiB、RTX 5090の45万トークンキャッシュ、AMD系フォークでPP2倍

手元のハードウェアでどこまで大型モデルを動かせるか。3つの事例が相次いで報告された。

1つ目はM2 Ultra（60コア／192GB）でDeepSeek V4 Flashを動かす試み。llama.cppのフォークで重みを141GiBにロスレス再パックし、バイト単位で同一のまま、公開のQ4量子化版より小さく収めた。KVキャッシュの量子化を行わない状態で平均25.8トークン／秒（ピーク42）、M3 Ultraで報告されていた16トークン／秒を上回る。KVキャッシュをSSDに置き、動的なレーン割り当てと組み合わせることで、合計約100万トークンのコンテキストを8レーンで扱えるという。

2つ目はRTX 5090（400Wに電力制限）1枚でQwen3.8-27Bを回す構成。モデルとKVキャッシュの双方をNVFP4量子化し、vLLMでセッションあたり約19.6万トークン、グローバルで約45.1万トークンのKVキャッシュを確保、3セッションの並列利用も見込む。画像入力（ビジョン）にも対応し、平均120トークン／秒を維持。実際のコーディングセッションでもベンチマーク通りの数字が出たと報告している。

3つ目はAMDのGPUユーザー向け。AMDが公開しているllama.cppフォーク（AMD-Ecosystem）のパッチで、Strix Halo環境のdenseモデルでプロンプト処理（PP）が最大2倍以上——14Bモデルで約550トークン／秒（従来約230）——に伸びたという報告だ。ただし生成速度（TG）はVulkan利用時より15%ほど遅く、MoEモデルでは差がない。パッチは後から本家へマージされる運用のため、Radeon環境では試す価値がありそうだ。

ハイエンドGPUの調達が難しい今、手持ちのMacや1枚のゲーミングGPUで「実用に足る速度とコンテキスト長」を両立させる知見の蓄積が続いている。

Qwen3.5-9BにNanbeige風「トリプルループ」──個人実験でも数学+20%

小型モデルで好成績を残しているNanbeigeの要因の1つとされる「中間層のループ構造」（同社4.5世代では三重）を、Qwen3.5-9Bに移植した個人の実験がRedditで公開された。

作者はまず学びを明かしている。ループ部分に専用の低い学習率スケジュールを割り当てるまでは、ループは「答えを磨くだけ」の存在で、直して初めて「答えの生成に不可欠な部品」になったという。構造だけ真似ても訓練設計が噛み合わないと効かない、という実感は興味深い。

訓練はRLではなく、Qwen3.8-27Bの出力（logits）からの蒸留で行い、クラウドの無料GPUクレジット30ドル分で約1,500万トークン、1,129ステップで資金切れ。学習率の減衰スケジュールも未実施のまま終わっている。それでも非公開の評価ながら、数学+20%、長文脈+14%、指示追従+20%、質問の言い換えへの堅牢さ+62%と、ベースモデルを上回る項目が並んだ。一方で推論-10%、翻訳-15%と下がった項目もあり、作者自身「証明概念であり、このままの利用は推奨しない」と断っている。

とはいえ、Nanbeige 4.5の設計が自社実験より大きい9B規模でも収束することを示せた点は、今後の追試を促す結果と言える。

国内: AIツール別に10本あった監査プロンプトを3本に統合した設計

Qiitaで、監査用プロンプトの運用設計をまとめ直した記事が公開された。docs配下にAIツール別に10本あった監査プロンプトは、中身の9割が同じで、違うのは冒頭数行と想定ツールだけだったという。

見直しの軸は「どのファイルを対象にするか」「対象別3本それぞれの安全境界」「ツール名の代わりに何を申告させるか」の3点。ツール名ではなく監査対象の性質で分類し直した点は、AIツールが次々登場する状況での保守性を考えると筋がよさそうに見える。

国内: Spring AIでLLMの出力品質をテスト──回帰検知と自動リトライ

同じくQiitaで、LLMを組み込んだアプリケーションの出力品質をテストする実践記事が公開された。同じプロンプトでも毎回違う文章が返る非決定的な相手に対して、従来の「入力Xに対して出力はYと等しい」というアサーションは通用しない、という問題設定から始まる。

記事では品質の回帰検知と、基準を満たさなかった場合の自動リトライの設計を扱う。LLMアプリを本番に載せる際に必ずぶつかる問題だけに、Spring AIを使う開発者以外も視点の参考になりそうだ。