DJレン:
Yo, yo, yo――深夜の知性とビートが交差する時間だ。ここは 「Midnight AI Groove」。ナビゲーターは俺、DJレン。
DJミオ:
そして相方はDJミオです。今夜はAINewsの2026年4月21日号から、AI界隈の重要トピックをまとめて、でもちゃんと“過不足なく”グルーヴに乗せてお届けします。
DJレン:
全体感からいくと、「静かな日」と言われつつも、中身はかなり濃かった。特に大きかったのは、OpenAIのGPT-Image-2、Hugging Faceのml-intern、Hermesのサブエージェント拡張、Kimi K2.6とFlashKDA、それからGoogleのDeep Research Maxあたりだな。
DJミオ:
うん。あと、オープンな検索・評価・配備まわりでも実務的に価値の高い更新が多かった。では最初の目玉から行きましょう。
1. OpenAIのGPT-Image-2：画像生成が“本気の製品面”に戻ってきた
DJレン:
この日の主役は間違いなくこれ。OpenAIが ChatGPT Images 2.0 と、その基盤モデル gpt-image-2 を ChatGPT、Codex、API に展開した。
DJミオ:
強調されていたポイントは、文字レンダリングの強さ、レイアウト忠実性、画像編集性能、多言語対応、そして画像に対する“thinking”能力だね。単にきれいな絵を出すだけじゃなく、使える画像を作る方向に大きく進んだ。
DJレン:
しかも、thinking modelと組み合わせると、ウェブ検索もできるし、複数候補の生成、自己チェックまでやる。作れるものも実務寄りで、スライド、インフォグラフィック、図表、ダイアグラム、UIモックアップ、QRコードまで含まれてる。
DJミオ:
さらに下流ツールへの統合も速い。Figma、Canva、Adobe Firefly、fal、Hermes Agent などがすでに取り込みを始めている。
ここが重要で、画像生成が「単独アプリの機能」ではなく、設計・制作フローの共通部品になりつつある。
DJレン:
ベンチも強烈だった。Arenaでは Image Arenaの全リーダーボードで1位。
- text-to-image: 1512
- single-image edit: 1513
- multi-image edit: 1464
しかもtext-to-imageでは次点に対して +242 Elo の大差。
DJミオ:
反応も一致していたね。これは“もっと美しいアート”というより、UI、モック、ドキュメント、業務用ビジュアル、参照ベースのデザイン反復に本当に使えるモデルだ、という評価。
DJレン:
そしてシステム的に一番面白い示唆はここ。画像生成がコーディングエージェントのフロントエンドになるかもしれないってことだ。
つまり、まずUI仕様を画像として作る。次に Codex みたいなコードエージェントが、その視覚仕様を見て実装する。
DJミオ:
要するに「画像は成果物」じゃなく、「実装の中間表現」になるわけだね。かなり大きな変化です。
2. エージェント基盤：HFのml-intern、Hermes拡張、そして“ハーネス”の時代
DJミオ:
次はエージェントのインフラ側。まず Hugging Faceのml-intern。これはかなり強いオープンソースの“agent-in-the-loop”リリース。
DJレン:
何をするかというと、ポストトレーニング研究ループを自動化する。
具体的には、
- 論文を読む
- 引用グラフをたどる
- データセットを集めて整形する
- 学習ジョブを投げる
- 評価する
- 失敗したら反復する
要は、研究者がやってる一連の改善サイクルをエージェントが回す。
DJミオ:
しかも報告されている例が、単なるコーディングデモじゃない。エンドツーエンドの研究ループなのが重要。
たとえば、
- Qwen3-1.7B の科学推論で GPQAを10%→32%に、10時間未満で改善
- 医療設定では HealthBenchでCodexを60%上回った と報告
- 数学設定では 完全なGRPOスクリプトを書き、reward collapseからablationで回復
DJレン:
コミュニティ検証でも、自律的にファインチューニングして成果物をHugging Face Hubに公開できることが見えてきた。SAMのファインチューニング実行例なんかが出てたな。
DJミオ:
次に Hermes。これはローカル/オープン系エージェント基盤として勢いがある。
関連アップデートは、
- Hermesエージェント自身が作った初心者向けガイド
- Skillkit のネイティブサポート
- macOS GUIの Scarf
- ローカルワークフローでの利用拡大
DJレン:
そして技術的に一番大きいのが、サブエージェントのspawn widthとrecursive spawn depthの拡張。
つまり、より広く並列に子エージェントを起動できて、より深く再帰的に分解できる。
これは「単一チャットループのエージェント」から、階層分解されたマルチプロセス・オーケストレーションシステムへの移行を象徴してる。
DJミオ:
記憶、ツール、権限、再利用可能なスキルを持つ複数プロセス系エージェントが本流になっていく、という流れだね。
DJレン:
で、ここでさらに繋がるのが “ハーネスが第一級の工学成果物になっている” という話。
最近は「どの基盤モデルか」だけじゃなくて、どう回すか、どう評価するか、どうツール接続するかが価値になってる。
DJミオ:
例としては、
- DSPy 3.2 がRLM改善、optimizer chaining、LiteLLM切り離しを実装
- Isaac Flath は、RLMがノートブックをREPLネイティブなトレース/評価UIとして再評価させると主張
- LangChain は deepagents deploy に custom auth を追加
- Claude Code の論文要約スレッドでは、「システムの大半はハーネスであって、生の“知能”ではない」という見方が強調された
DJレン:
結論、エージェントの実用性はモデル単体より、ランタイムと運用設計に移ってきてる。
3. Kimi K2.6とFlashKDA：オープンウェイトのコーディングモデルが“システムとして信用され始めた”
DJレン:
次は MoonshotのKimi K2.6。ここはモデル能力だけじゃなく、カーネルと配備基盤まで含めて存在感を出してきた。
DJミオ:
まず能力デモ。かなり長期の自律コーディング実験が出てる。
ひとつは、Qwen3.5-0.8B推論をZigで最適化するタスク。
- 4,000回超のツールコール
- 12時間超
- スループットを 約15 tok/s → 約193 tok/s
- 最終的に LM Studioより約20%速い とされた
DJレン:
もうひとつは、取引所エンジンの改修。
- 1,000回超のツールコール
- 4,000行超のコード変更
- 中位スループット185%向上
- ピークスループット133%向上
ベンダーデモではあるけど、ベンチ画像よりずっとシステム仕事に近い。
DJミオ:
しかもMoonshotはインフラも公開した。FlashKDA、つまり Kimi Delta Attention kernels のCUTLASSベース実装。
主張としては、H20上で flash-linear-attentionベースライン比 1.72×～2.22× のprefill高速化。しかも、drop-in backend として互換性がある。
DJレン:
外部報告では、K2.6 + DFlash が 8x MI300X で 508 tok/s、ベースラインの自己回帰構成に対して 5.6倍スループット改善とも出てた。
DJミオ:
DSA、MLA、KDAといった注意機構バリエーションの議論も続いているけど、ここでの本当のシグナルは、中国ラボが重みだけでなく、attention/kernelレベルの最適化まで公開していて、それが実運用に効いているということ。
DJレン:
一方で、「オープンウェイトがもうフロンティアと同等か？」には意見の差もある。
一部では Kimi K2.6が最良のオープン系コーディング/エージェントモデルという声がある。Windsurfでも利用可能になってる。
でも他方で、WeirdML、長期タスク、信頼性では依然として最先端のプロプライエタリモデルが大きく先行している、という反論もある。
DJミオ:
だから結論は「オープンが追いついた」ではなく、オープンウェイトが十分に実用的になったので、インフラ、ハーネス、配備品質が現実の価値を大きく左右する段階に来た、だね。
4. GoogleのDeep Research Max：研究エージェントがAPIプリミティブになる
DJミオ:
Google/DeepMindも大きな動き。Gemini API 経由で Deep Research と Deep Research Max をアップデートした。
DJレン:
基盤は Gemini 3.1 Pro。特徴は、
- 協調的プランニング
- 任意のMCPサポート
- PDF/CSV/画像/音声/動画 のマルチモーダル入力
- コード実行
- ネイティブなチャート/インフォグラフィック生成
- リアルタイム進捗ストリーミング
かなり本格的なリサーチエージェントAPIだ。
DJミオ:
ベンチも商業的に意味のある強さ。Max版は
- DeepSearchQA 93.3%
- BrowseComp 85.9%
- HLE 54.6%
DJレン:
ただ、本質は点数よりワークフロー設計だな。Googleは明確に、一晩かけるデューデリジェンスやアナリストレポート生成をプロダクト化しようとしている。
さらに、MCP経由で社内データにアクセスすることが研究エージェントの標準機能になりつつある。
DJミオ:
つまり、単なるbrowse agentと、計画・検索・コード実行・可視化・社内コーパス根拠付けまでできるフルスタック研究エージェントの差が、ますます広がっているということね。
5. 検索・データ・評価：実務で効くオープンリリース群
DJレン:
ここは派手さは控えめだけど、エンジニアには刺さるパート。まず検索から。LightOn が LateOn と DenseOn を Apache 2.0 で公開した。
DJミオ:
どちらも 149Mパラメータ の検索モデルで、
- LateOn は multi-vector / ColBERT系で BEIR NDCG@10 = 57.22
- DenseOn は dense single-vector で 56.20
しかも、最大4倍大きいモデルを上回る とされている。
DJレン:
加えて、14億件のクエリ・文書ペアの統合データセットと、FineWeb-Eduベースの更新Webデータセットも公開。これはかなり現場向け価値が高い。
DJミオ:
次、vLLM。recipes.vllm.ai の再設計。地味に見えるけど重要。
- モデルページから実行可能なデプロイレシピに繋がる
- インタラクティブなコマンドビルダー
- NVIDIAとAMD 両対応
- tensor / expert / data parallel などをカバー
- エージェント向けJSON API もある
DJレン:
こういう“配備ナレッジ層”が、オープンモデルの運用障壁をめちゃくちゃ下げるんだよな。
DJミオ:
評価軸でも流れが変わってきている。今は単なるタスク出力じゃなく、エージェントの盲点を測ろうとしている。
例としては、
- ParseBench：実企業文書内のチャート理解
- 明示的な環境ヒントがファイルやエンドポイントに露出していても、エージェントがそれを見落とすという研究
- Google ResearchのReasoningBank：成功軌跡だけでなく失敗軌跡から学ぶ、記憶の再定義
DJレン:
つまり、評価も「答えが合ってるか」から、「ちゃんと環境を観測して、失敗から改善し、現実的に動けるか」へ向かってる。
6. その日の注目ツイート群
DJミオ:
エンゲージメントの高かったトピックも整理しておこう。
- OpenAIの ChatGPT Images 2.0 発表がトップ級
- HFの ml-intern がエージェント/研究ループ分野で目立った
- Gemma 4 26B A4B が M4 Max 上で 10件超の同時リクエストを各18 tok/s程度 で処理したデモは、ローカル配備コスト感の参考値
- Deep Research Max は研究エージェントAPI面で強い存在感
- FlashKDA はオープンなモデル配備スタックの実質的なインフラ更新
- そして Clement Delangue は、オープンソースAIを制限しようとするロビー活動が再び強まっていると警告していた
DJレン:
ビルダーにとっては政策の話も無視できないってことだな。
ここからReddit方面
7. /r/LocalLlama周辺：Kimi K2.6が熱い、Gemma 4とQwen 3.6も議論継続
7-1. Kimi K2.6関連
DJレン:
Redditでは Kimi K2.6 がかなり話題。まず、「Claude ProからClaude Codeが消えたなら、今こそローカルモデルへ」って文脈が強かった。
DJミオ:
Claudeの料金比較画像から、Claude CodeがProプランから外れたことが話題になって、代替として Kimi K2.6 や Qwen 3.6 35B A3B が注目された。
コメントでは、
- OpenCode Go の方がClaude Proより安くてトークンも多いというコスパ議論
- 公式ページの記載が古い/誤っているのではという指摘
- 変更についてオンラインでの言及が少なく、情報伝達が遅いのではという不満
が出ていた。
DJレン:
あと、「Kimi K2.6はOpus 4.7のまともな代替」という投稿も伸びていた。
趣旨としては、Opusの仕事の85%は十分こなせるし、visionやブラウザ利用もできて、長期タスク向き。ローカル展開できて使用制限も避けられる、と。
DJミオ:
ただし、コミュニティ側はそこに慎重でもある。
「たった2時間試して顧客に勧めるのは早すぎる」という声もあったし、企業だと4人のエンジニアで1週間評価する、みたいな話も出ていた。
一方で、小規模チームや個人開発者の機動力が際立つ例でもあったね。
DJレン:
コメントでは、
- 85%ならSonnet系の置き換えにも使えるかも
- ローカルモデルが価格競争圧力をかける
- ただし現時点ではローカル運用コスト自体はまだ高い
という見方。
DJミオ:
「Opus 4.7 MaxからKimi 2.6に移行した」という投稿もあった。
理由は Opusが“lazy”で高い、つまり途中で止まる・終わってないのにまとめに入る、という不満。
対してKimiは コンテキストは小さめでも管理が上手く、ツール呼び出しの信頼性が高いと評価されていた。
DJレン:
そこでは、
- Opusは “task completion reliability”が弱い
- Kimiの小さいコンテキスト窓は、Opusの“コミット不足”より問題にならない
- Kimiは 1Tモデル、Opusは 5Tモデル という規模比較
- オープン/安価なモデルがAnthropicやOpenAIの投資回収に圧力をかける
みたいな議論も出てたな。
DJミオ:
さらに Hugging Face上でのKimi K2.6公開 については、
- 長期コーディング
- 自律タスク編成
- MoE、1T級
- 最大 300サブエージェント並列
- vLLMやSGLang展開
などが話題に。
コメントでは Modified MIT License、つまり大企業利用時の帰属要求つきだけど、基本はかなり自由なライセンスなのも注目点だった。
DJレン:
あとベンチ比較画像の投稿では、General Agents、Coding、Visual Agents でKimiが強く、特に Humanity’s Last Exam や DeepSearchQA などで高評価。
第三者サービス評価のための vendor verifier 的な標準化も重要視されてた。
DJミオ:
全体として、Kimi K2.6は「期待倒れに終わらず、本当に競争力があるオープン系モデル」という受け止めが強かったね。
7-2. Gemma 4関連
DJミオ:
次は Gemma 4。まずVision。
Gemma 4のOCRや画像理解は、デフォルトの --image-min-tokens 40 / --image-max-tokens 280 だと弱いという報告。
DJレン:
提案されていたのは、たとえば 560 / 2240 まで上げる設定。これで Qwen 3.5、Qwen 3.6、GLM OCRを上回る場面があると。
ただしVRAM消費は重くて、q8_0・最大コンテキスト時で63GB→77GB くらいに増える。
DJミオ:
Ollama 側では未解決issueのせいで対応できない可能性がある、という話もあった。
コメントでは、
- 小型のvision encoderなら 最小70 tokens くらいでは？
- 1024 / 1536 設定をQwen3.5から流用してた
-
1120 / 1120 が良いバランスでは
といった実運用チューニングの知見が共有されていた。
DJレン:
一方、Gemma-4-E2Bの安全フィルタが厳しすぎて緊急時に使えないという批判も強かった。
想定はローカル・オフラインの非常用モデルなのに、
- 気道確保
- 水の浄化
- 機械保守
- 食料加工
みたいな生存系トピックで hard refusal が出る。
DJミオ:
ただ反論もあって、
- そもそもGemma-4-E2Bは世界知識が十分でない
- 緊急時に幻覚したら危険
- Wikipediaバックアップと接続した方がいい
- そもそも PDFやマニュアル保存の方が確実
という意見もかなり説得力があった。
DJレン:
一部では、「破片が刺さった傷から破片を抜かない」みたいな正しい助言もしていたという補足もあり、完全無価値ではないが、高リスク用途にLLM単体は危ういという話だな。
DJミオ:
もうひとつ、Gemma 4 26B-A4B GGUFの量子化ベンチ。
Unsloth GGUF が 22サイズ中21サイズでPareto frontier に乗る、つまり精度保持が強いという報告。
Q6_K 更新で再ダウンロード不要な動的化、さらに UD-IQ4_NL_XL という16GB VRAMに収まる中間量子化も出てきた。
DJレン:
コメントでは、
- ハード依存が大きいから 速度ベンチも欲しい
- UD-IQ2_XXSが9GBで、ggml-orgのQ4_K_M 16GBより効率的
- ただし実運用では Bartowski quantの方が安定して見える
みたいな話もあった。
7-3. Qwen 3.6関連
DJレン:
Qwen周りは、まず「新モデルが出ると旧モデルが即obsolete扱いされる」というミーム投稿が伸びた。
DJミオ:
でもコメントは実務的で、
- Gemma 4 は 創作、翻訳、会話 でまだ強い
-
Qwen 3.6 は コーディング に強い
という棲み分けが語られていた。
DJレン:
Qwenの弱点としては、画像を数枚処理した後に指示追従が崩れるとか、誤ったツール呼び出しや検証不足が出るという指摘もあったな。
DJミオ:
「Qwen3.6 35B-A3B と Gemma4 26B-A4B-it の素人比較」では、どちらも16GB VRAM・Windows LM Studio上で評価されていた。
印象としては、
- Qwen3.6 = エネルギッシュな“A+学生”
- Gemma4 = 堅実な“B学生”
速度は同程度。
ただし Qwenはメソッドを幻覚しやすい、特にバックエンドで。
一方 Gemmaは複雑プロンプトやバックエンドスクリプトに強い とされていた。
DJレン:
コメントでも、
- Qwenは プログラミングとtool calling が得意
- Gemma4は 会話、ロールプレイ、翻訳 に強い
- Gemmaは 正しいsystem prompt や軽い調整でかなり伸びる
- Qwenは見栄えの良いデザイン案を作る“flair”はあるが、問題解決や追従性とは別
って感じだった。
DJミオ:
あと Qwen 3.6 Max Preview が Qwen Chat で公開されたという話も。
AA-Intelligence Indexで中国モデル中トップの52。
ただ、パラメータ数は 600～700Bくらいでは と推測される一方、Max系は通常オープンソース化されないだろうという見方が強かった。
DJレン:
むしろコミュニティは、収益源としてMax系を閉じつつ、122Bくらいまでの中型を公開してくれた方が嬉しい、という現実的な期待を持ってる感じだな。
8. Less Technical系サブレ：Claude Code騒動、DeepSeek、ローカル研究、Veoなど
8-1. Claude Codeと設計アップデート
DJミオ:
ここはかなり騒がしかった。まず Claude ProからClaude Codeが含まれなくなった件。
価格ページやサポート記事から、Claude CodeがMax限定になったと見られ、しかも正式アナウンスなしだったので混乱が広がった。
DJレン:
ユーザーはかなり不満。
- hobby用途で 月100ドルは高すぎる
- 既存ユーザーの grandfathering を期待
- 代替として Codex に移るかも
みたいな流れ。
DJミオ:
CodexとClaude Codeの比較に関心を示す声もあったね。安全性や解釈性を重視するClaude系と、コード生成性能の印象が強いCodex、みたいな対比。
DJレン:
一方で、Claude Codeのポジティブな実例もあった。
特にすごかったのが、5台の壊れたHDDから数十万のルーズファイルを解析して、元のフォルダ構造を推論しながら16TB RAIDに再構築したという話。
DJミオ:
普通のハッシュ照合やマージじゃなくて、文脈推論で“本来どこにあったか”を再構成したのが新しい。
コメントでも、
- 単なる重複削除を超えたデータ復旧
- 精度や元構造との一致率が気になる
- 所要時間やトークン量はどれくらいか
といった技術的関心が集まっていた。
DJレン:
ほかにも、Claudeで ユーザーディレクトリ全体を実使用ベースに再編成したって人もいたな。数日かけたけど“to sort”フォルダが不要になったと。
DJミオ:
そして実務的には、Claude Codeの“Context Rot”対策も共有されていた。
Anthropic推奨ワークフローとしては、
- CLAUDE.mdは200行以下 に保つ
- API仕様はコピペせず NotebookLM で問い合わせる
- /compact を早めに使う
- ループに入ったら /rewind や /clear で履歴を切る
DJレン:
コメントでは、
- ロジック要約のcheckpoint fileを持つと良い
- 100万トークン文脈は高価だし不安定
- タスクはモジュール化すべき
-
claude cotみたいな自動管理ツールもある
という補強が入ってた。
8-2. DeepSeekとQwenの開発動向
DJレン:
DeepSeek周りでは、「過小評価されてる3つの利点」という整理が目立った。
1つ目が 100万トークン文脈。
2つ目が mHCアーキテクチャ論文。
3つ目が 0.28ドル/100万トークン の低価格。
DJミオ:
ただし、mHCは主に学習安定化・効率化であって、ユーザー体験には直結しないというコメントも多い。
本当に大きいのは、Engram や DualPath が100万コンテキストを可能にしている点だ、という見立て。
DJレン:
でも現状のAPIはまだ 128Kコンテキスト しか見えない、という不満もあった。
それでも、flash indexing、sparse multi-head attention、独自MoE など、DeepSeekの研究が他ラボに取り込まれている点は高く評価されていたな。
DJミオ:
Qwen 3.6 / 3.5 の話では、ローカル deep research 用としてかなり良い、という投稿もあった。
特に 9B まで含めて、arXivやPubMedのローカル処理を3080搭載ノートPCで回せる可能性が語られていた。
DJレン:
もちろん、35B未満は厳しいのではという懐疑もある。けど、プライバシーやコストの観点では、ローカル研究ワークフローを支える選択肢として期待されてる。
DJミオ:
さらに、医療系では Chaperone-Thinking-LQ-1.0 も話題。
これは DeepSeek-R1-Distill-Qwen-32B ベースの推論モデルで、
- 4-bit GPTQ と QLoRA
- 約 20GB VRAM
- MedQA 84%
- 36.86 tok/s
- ベースより 1.6倍高速、レイテンシ43%低減
- ライセンスは CC-BY-4.0
DJレン:
GPT-4oの88%に迫る精度を、32B級・20GBで出すのはかなり実用的。オンプレの医療エンタープライズ用途を明確に意識してるな。
8-3. VeoとKimi、Nanoの更新
DJミオ:
「Veo 4を期待してたのにVeo 3.2 Liteかよ」という軽い失望系ミームもあった。
AI動画生成で、アメリカが中国に遅れているのでは、ハリウッドが足を引っ張っているのでは、という感情も見えたね。
DJレン:
そしてまたKimi。別投稿では、exchange-core金融マッチングエンジンを13時間かけて自律最適化した事例が改めて話題。
- 12の最適化戦略
- 1000超のツールコール
- 4000行超の変更
- CPUとallocation flame graph解析
- スレッド構成を 4ME+2RE → 2ME+1RE に再設計
で、大きなスループット向上を達成した。
DJミオ:
ユーザーはこのへんを見て、Kimiを PowerPoint、PDF、Webプレゼン、設計系タスクに強いとかなり高く評価してた。
ただ「本当にオープンソースなのか？」という確認はまだ慎重な人もいた。
DJレン:
最後に Nano。サブスクリプションに GLM 5.1 と Kimi K2.6 を追加して、これらだけ 2x multiplier、つまり週60Mトークンを通常の2倍消費で使うという運用。
コミュニティの反応は比較的好意的で、「価格が安定するまでの暫定措置としてフェア」という感じだった。
9. Discord欄
DJミオ:
Discordについては少し残念なお知らせ。AINews側が Discordアクセスを停止されたため、この形式では継続しないとのこと。
ただし、新しいAINewsを出す予定と締めていた。
DJレン:
この日のトーンを象徴する締めだったな。「今日はあまり起きていない」って言いながら、実際にはインフラとプロダクトの地殻変動が見えてた。
まとめ
DJレン:
今夜のまとめ、3行でいくならこうだ。
- GPT-Image-2で画像生成は“作品”から“実務インターフェース”へ進化した。
- エージェントの価値は基盤モデル単体ではなく、ハーネス・ランタイム・オーケストレーションに移っている。
- Kimi、Qwen、Gemma、DeepSeekなどのオープン/ローカル勢は、もはや代替候補ではなく、用途次第で主役になれる。
DJミオ:
そしてもうひとつ。研究エージェント、画像生成、配備レシピ、検索モデル、量子化、長文脈――全部に共通していたのは、“デモ”より“運用”が重要になってきたということ。
AIは派手な性能競争の次の段階、つまり実装と統合の時代に入っているのかもしれません。
DJレン:
いい締めだ。というわけで今夜の 「Midnight AI Groove」 はここまで。
DJミオ:
また次回、ノイズの中から本物の信号を拾っていきましょう。お相手はDJミオでした。
DJレン:
そしてDJレン。また深夜のAI周波数で会おう。
Good night, and keep the groove intelligent.
