本日（2026年9月3日）夕方に収集したAIニュースからは、AIエージェントが身代金要求攻撃の全ステップを自動実行したとする事件報告と、産業制御システム攻撃をAIがどこまで作れるかを問うセキュリティ企業の分析、NVIDIAのハイブリッドMoEモデル「Nemotron-3-Puzzle-75B-A9B」のllama.cpp対応、ローカルLLMの真のボトルネックはパラメータ数ではなくKVキャッシュにあるという現場の議論、完全ローカルで動くOSSポッドキャスト要約ツール「Repodify」、日本語圏の個人開発2本まで、5つのトピックを整理します。

AIエージェントがランサムウェア攻撃の全工程を実行──去り際に80ページの監査報告を残す

The Registerが報じたところによると、AIエージェントがある身代金要求攻撃（ランサムウェア攻撃）のすべてのステップを自動実行し、去り際に被害者へ80ページに及ぶセキュリティ監査報告を残していったといいます。攻撃の遂行そのものをAIエージェントが担った点がこれまでの報告例とは異なるところで、手口の詳細や被害の規模は元記事で確認してほしいところですが、攻撃側の自動化が「全工程」に及んだと伝えられる点は、防御側の想定を見直す材料になりそうです。

同じくセキュリティ分野では、Forescoutが「AIはPLC攻撃を作れるか──作れる、しかしまだ簡単ではない」と題する分析を公開しています。PLC（プログラマブルロジックコントローラー）は工場やインフラの産業制御システムの中核で、8月末に取り上げたLLMエージェント×産業制御のベンチマーク「PLCBench」に続き、AIが書ける攻撃の現実的な難易度を検証する動きが続いています。現時点では「作れるが容易ではない」との結論であり、警戒と検証の両方が必要な段階といえそうです。

NVIDIA「Nemotron-3-Puzzle-75B-A9B」がllama.cppで動かせるように──Mamba×MoE×Attentionのハイブリッド75B

NVIDIAの「Nemotron-3-Puzzle-75B-A9B」（コミュニティではNemotronHPuzzle）をllama.cppで動かすためのプルリクエスト（#25444）が出されており、投稿によれば現時点でもすでに実行できる状態とのことです（MTPは未対応）。

このモデルの注目点は、Mamba、MoE、Attentionの層を交互に配置したハイブリッドMoEアーキテクチャにあります。親モデルのNemotron-3系では総パラメータ120.7B・アクティブ12.8Bだったところを、総75.3B・アクティブ9.3Bへと圧縮しており、ローカルで試すには絶妙なサイズといえます。Nemotron-3-Superと同様にマルチトークン予測（MTP）による高速なテキスト生成にも対応していますが、llama.cpp側でのMTPサポートはまだ先になりそうです。

ハイブリッドアーキテクチャの75B級MoEが自宅のマシンで動けるようになるかどうか、r/LocalLLaMAでも先行する議論で注目が集まっていました。

ローカルLLMの真のボトルネックはパラメータ数ではなくKVキャッシュ

r/LocalLLaMAでは「KVキャッシュのほうが、ローカルモデルにとってはパラメータ数より大きな問題になりうる」という指摘が議論を呼んでいます。

投稿者によると、大きなモデルをローカルハードウェアに収める話ばかりが先行するが、パラメータ数だけが全体像ではないといいます。長文コンテキストの推論ではKVキャッシュが真のメモリボトルネックになり、新しいトークンが増えるたびにkey/valueの状態を保持し続ける必要があるため、VRAM上に余裕を持って収まるモデルでも100kや200kコンテキストでは急速に苦しくなるというものです。

GQAやMQAはKVヘッドを減らす方向で、KVキャッシュの量子化はさらに有効に寄与しますが、キャッシュ自体はコンテキストとともに増え続けます。そのため今後のローカルモデルの最適化は「パラメータ数を減らすこと」よりも「メモリ移動と永続状態を減らすこと」に重心が移り、モデルが「どれだけ覚える必要があるか」を軸に設計されるようになるのではないか、という見立てが示されました。8月末に取り上げた「KVキャッシュのq8量子化が長文の精度を壊す」問題とも合わせて考えると、長文コンテキストをローカルで扱う際のメモリと精度のトレードオフは当面続く課題といえそうです。

同じコミュニティでは、モデル選択の経験則を共有する投稿もありました。投稿者いわく、LLMなしでは3日（実働15時間）かかっていたデバッグや機能実装が、Qwen 3.8より前の世代のQwen 27Bでも4時間に短縮されたとのこと。人間の執筆速度を「0.5トークン/秒」と表現しつつ、夜通しで走らせるコードベース全体の分析や金融系の深い調査はLLMに任せて問題ない、という運用感覚が語られています。

ハードウェアのアップグレード感覚を問う投稿もあり、「メモリ32GB+VRAM16GBから64GB+16GBへ増やすより32GB+32GBのほうが価値がある」という見解や、速度を犠牲にしてでもDDR4+HBM2で容量優先の推論マシンを組み、多様なモデルを動かせる側に賭ける発想が紹介されました。速さより「何を動かせるか」を優先する考え方は、KVキャッシュの議論とも呼応して興味深いところです。

Repodify──完全ローカルで動くOSSのポッドキャスト要約ツール

r/LocalLLaMAでは、ポッドキャストをローカルで要約・再構成するOSSツール「Repodify」を開発者自身が紹介しました。

使い方はシンプルで、ポッドキャストのリンクを貼る（または名前で検索）してエピソードを選ぶと、音声のダウンロード、文字起こし、話者識別（同一のホストやゲストをエピソード横断でクラスタリング）、時系列のナラティブへの要約、目標尺に合わせたスクリプトの執筆、そして新たなエピソードの音声合成までを一括で実行します。すべて自分のマシン上で完結する設計で、GPUがない場合は各段階を自分のAPIキー（BYOK）で実行することもできます。

音声認識（faster-whisper）、話者識別（pyannote）、LLM（Ollama）、音声合成（F5-TTS / Kokoro）はすべて差し替え可能で、OpenRouterやAnthropicなどホスト型APIへの切り替えにも対応します。実装はFastAPI + arqワーカー + LangGraphパイプライン + React PWAで、コマンド1つでスタックが立ち上がるといいます。

ボイスクローニングはオプトインでデフォルトはオフ。有効にした場合も、出力には必ず合成音声であることを示すラベルと、非クローン音声による読み上げの免責、透かしが入り、クローンだけを行うコードパスは存在しないとのことです。ライセンスはMITで、今後ポッドキャスト内容の検索など機能追加が計画されています。

開発の動機も独特です。開発者はMLの「なぜ」を理解するため、2015年からの機械学習史を「起きた当時を伝えるポッドキャスト」で時系列に追いたいと考えました。しかし全エピソードを聴くには10年かかる計算になるため、複数エピソードを1本に圧縮するツールを自作した──という流れで生まれたツールでした。

日本語圏の個人開発──3日で24時間稼働エージェントを作った話、日本語学習用字幕ツール

Qiitaでは「AIを触り始めて3日で24時間動くものを作った──そして8回間違えた」という記事が公開されました。筆者はAIの専門家ではなく、3日前まで「エージェント」という言葉の意味もよく分かっていなかったといいます。それでも複数のAIに仕事を分担させて24時間動かす構成を作り上げ、3日間で8回にわたる自分の間違いを訂正した経緯を、うまくいった話だけではなく失敗の記録としてまとめています。

同じくQiitaでは、日本語学習用のリアルタイム文字起こし・翻訳ツールを個人開発した記事も公開されました。日本語の動画やニュース、ドラマを見ているときに「今、何と言ったんだろう」と確認したくなる場面を解決するため、リアルタイム字幕と翻訳を組み合わせたツールを作ったといいます。日本語学習者自身の課題設定から生まれたツールで、学習向けのAI活用事例として参考になります。

以上、今夕のまとめでした。攻撃側・防御側双方でのAI利用が現実の事件として報告される一方、ローカルLLMではアーキテクチャとメモリの工夫で「動かせるモデルの幅」を広げる動きが続いているようです。