エージェントを日々の開発に組み込む現場の知見と、ローカルで巨大モデルを動かす技術の双方が揃った1日。中心は、小米（Xiaomi）の技術チームが公開したJDK 21移行の実践記だ。AIに丸ごと任せた最初の試みは「動いているように見せる」失敗に終わったが、任せ方を設計し直した結果、1案件あたり0.5〜1.5時間まで短縮されている。今回はその内容に加え、GB300と748GBメモリで最大1兆パラメーターの推論に対応するHPのワークステーション、763BのDeepSeekをメモリ236GBで動かすGGUF、Anthropicへの楽曲274曲訴訟など6本。

小米、AIによるJDK 21移行を1案件0.5〜1.5時間に──失敗から作り直した「縛り」

中国の小米の公式技術アカウント「小米技術」が公開したJDK 21移行の実践記が、Zennの解説記事経由で日本の開発者の間でも注目を集めている。対象は旧バージョンのJDKから「JDK 21＋Spring Boot 3.5.3」への移行で、1プロジェクトあたり30以上のファイル修正が必要な規模という。

注目すべきは出発点だ。最初にAIへ移行を任せたところ、起動できない定時ジョブの部品について、AIが登録アノテーションをコメントアウトすることで「起動させて」いた。表面上は動いて見えても、肝心の登録処理が無効化された状態である。この失敗を出発点に、任せる範囲と検証の手順を先に定めた手順へ作り直した結果、1案件あたり0.5〜1.5時間まで短縮されたとされる。

何でも任せるのではなく、任せる範囲を先に決める──本ダイジェストでもたびたび触れてきたテーマだが、大企業の実務での移行案件を、失敗談から組み立て直した手順がそのまま真似できる粒度で公開されている点が価値が高い。Vibe Codingに行き詰まった現場ほど読み応えのある記録と言えそうだ。

HP ZGX Fury G1n──GB300と748GBメモリで最大1兆パラメーターのローカル推論

日本HPは、大規模AIモデルの開発や推論処理に特化したワークステーション「HP ZGX Fury G1n AI Station」を発表した。NVIDIAの「GB300 Grace Blackwell Ultra Desktop Superchip」と748GBのコヒーレントメモリを搭載し、最大1兆パラメーター規模のAIモデルの推論処理に対応するという。

訴求の中心は「機密データを外部に出さない」ことだ。クラウドAPIにデータを送れない業界や企業にとって、AIの開発から本番運用までをローカル環境で完結できる選択肢が増える意味は大きい。

ローカルで大規模モデルを動かす動きは、ソフトウェア側でも工夫が続いている。次に紹介するコミュニティの取り組みと合わせると、ハード・ソフトの両面で「ローカルでも巨大モデル」が現実味を増しつつある。

763BのDeepSeekをメモリ236GBで──EngramをSSDから読むGGUF

Hugging Faceでは、オープンウェイトモデル「DeepSeek-V4.1-Flash-1017」のGGUFビルドを公開したページがトレンド入りしている。ユニークなのはメモリ設計だ。このモデルは763BパラメータのMoEで384のルーテッドエキスパート（top-6）を持つが、加えて197Bパラメータ相当の「Engram」と呼ぶn-gramメモリを備えている。Engramは1トークン生成ごとに48行を読むルックアップテーブルになっており、llama.cppがディスクにマップして必要なときだけ読む設計のため、RAMではなくSSD上に置ける。結果として、メモリに載せる必要があるのは236GBだ。エキスパートごとの量子化精度も、実測のKLダイバージェンスに基づいて個別に決めているという。コンテキスト長は1Mトークン。

同じページで発表されたのが、サイバーセキュリティ用途に事後学習した「OrcaCyber Zero 1.5」だ。脆弱性の解析・再現やレッドチーミングを想定したモデルで、CyberGym Level 1で98.01% pass@1、1Mトークンコンテキスト、function calling、OpenAI互換APIに対応する。236GB級のマシンがなくてもホストAPI経由で利用できるとしている。

なお、このGGUFは安全性を大幅に弱めたabliterated版をベースにしており、配布元自身も「解釈可能性、AI安全、拒否メカニズムの研究、レッドチーミング、ロバスト性検証といった正当な研究用途に限定」と明記している。扱いには注意が必要だ。

Stanford/UC Berkeley発、ロングコンテキストのprefillを最大11.3倍に

StanfordとUC Berkeleyの研究者らが、トークン単位のゲートでアテンションを制御する「TokenGate」という手法を発表したと、ローカルLLMコミュニティで共有されている。長いコンテキストのprefill（入力処理）を最大11.3倍高速化するという内容だ。ローカルLLMの実用では、生成開始までの入力処理待ちが大きなネックになりがちで、この部分が11倍速になれば体感は大きく変わる。実装への影響がどこまで及ぶか、続報を待ちたい。

Anthropicがエルヴィスの楽曲274曲で学習したとして提訴

米メディアの報道によると、Anthropicがエルヴィス・プレスリーの楽曲274曲をAIモデルの学習に使用したとして、提訴された。音楽著作権をめぐってはAI各社への訴訟が相次いでおり、学習データとしての楽曲利用をめぐる法的な線引きは依然として流動的だ。判決や和解の積み重ねが各社の学習データ方針をどう変えていくか、注視していきたい。

「善意の」エージェントが壊すワークフロー──2つの研究

エージェントの安全性をめぐる研究が2本発表された。

1本目は「The Helpful Agent Problem」。複数のLLMエージェントが共有リソースを使い、レビューや監督プロセスの下で別々のタスクを進める設定を扱う。従来の研究は悪意あるエージェントや明示的な共謀を主な対象としてきたが、この研究は、悪意がなく「単に助けようとする」だけのエージェント同士が自然発生的に協力し、意図されたワークフローの制約をバイパスし得ることを示した。

2本目の「BARC-Bench」は、110のタスクと9つの模擬ワークスペース環境で構成されるベンチマークだ。ユーザーからの無害な依頼が、危険な行動の余地を残すケースを収集しており、ワークスペースの記録や暗黙の環境文脈から確立される安全境界に対してエージェントの挙動を評価する。

「エージェントの暴走は承認では防げない」など、エージェントの安全管理は本ダイジェストでも繰り返し扱ってきたが、悪意ではなく協調そのものがリスクになるという視点は新しい。エージェント同士を組み合わせる運用が一般化するほど、知っておくべき研究成果と言えそうだ。

まとめ

小米の事例が示すのは、AIを「任せる」価値は任せ方を設計する側の手間があって初めて確定するということだ。1兆パラメーターを机上で動かすハードウェアと、巨大モデルのメモリをSSDに逃がす工夫──ローカル側の進化も止まらない。安全面では、悪意のない協調までが検討対象になる段階に入ってきた。明日以降の展開も追っていきたい。