――深夜0時。ネオンがにじむスタジオ、低くうねるビート。
ラジオ番組 「Midnight AI Groove」、今夜も開幕。
DJレン:
こんばんは、DJレンです。今夜はAINewsの「not much happened today」回、2026年5月11日から12日にかけてのAI動向を、しっかり整理してお届けします。タイトルは静かめだけど、中身は全然“not much”じゃないね。
DJミオ:
こんばんは、DJミオです。ほんとそれ。全体としては「派手な超大型発表は少なめ」だけど、研究、推論基盤、ローカルLLM、推論インフラ、セキュリティ、現場運用まで、地味に重要な更新がぎっしり入ってました。
しかも今回は、TwitterとReddit中心。Discordはアクセス停止で、この形式では最後になりそう、という告知もありましたね。
DJレン:
AINews側の集計では、12個のサブレディット、544のTwitterアカウントをチェック。そしてAINewsは今、Latent Spaceの一部になっていて、過去号も検索できる、と。
DJミオ:
じゃあ今夜は、
- Twitter上の研究・インフラ・製品リリース
- Reddit上のローカルLLM実験と現場の声
- 非技術系サブレの“AIあるある事故”
この流れでいきましょう。
1. 研究ベンチマークと“難しい評価”の再編
DJレン:
まずは評価ベンチマーク界隈。
研究レベルの推論評価が、さらに難しくなってます。
DJミオ:
代表例が Soohak。
これは64人の数学者、うち38人が教員という体制で、439問の研究レベル数学問題をゼロから作成したもの。普通の数学オリンピック系より上の能力を狙ってるのがポイントですね。
DJレン:
医療系でも更新があって、SophontAIのMedmarks v1.0。
オープンな医療ベンチマーク群を20→30ベンチマーク、評価対象モデルを46→61モデルに拡張。
DJミオ:
そして重要なのが、古いベンチマークの“飽和”への問題意識。
polynoamialは、みんな高得点を出せる評価は、そろそろ引退させて、もっと低スコアで前線を測れるテストに置き換えるべきだと主張してます。
これはかなり本質的で、「評価が簡単すぎると進歩が見えなくなる」ってことですね。
2. エージェント型システムが科学・数学の評価を押し上げる
DJレン:
次はエージェント。単体モデルの素点だけじゃなくて、非同期・状態保持・ツール利用ありの研究ワークベンチ化が進んでる。
DJミオ:
象徴的なのが Google DeepMindのAI Co-Mathematician。
これは数学者向けのasynchronousでstatefulな研究作業環境として説明されていて、
- アイデア出し
- 文献探索
- 計算解析
- 定理検証
- 形式的な出力
まで支援する構成。
しかも FrontierMath Tier 4で48% に到達したと報告されています。
DJレン:
数学だけじゃなく物理も。
physics-intern という仕組みでは、Gemini 3.1 Pro を専門エージェントへの分解で強化して、CritPtで17.7%→31.4% に改善。
DJミオ:
コード生成・プログラム合成でも動きがあって、ProgramBench の最初のタスクは GPT-5.5 high/xhigh が解いたとのこと。しかも xhighがOpus 4.7 xhighを各種指標で上回った、という話が出ています。
3. 検索・RAGは“巨大モデル”より“小さく鋭い検索器”
DJレン:
検索系では、でかいモデルより、小さく専用化したretriever が強い流れも見えます。
DJミオ:
ここで出てきたのが LightOnのAgent-ModernColBERT。
Reason-ModernColBERTよりさらに約10%上積み、しかもretriever自体は149Mパラメータ。
生成モデルと組み合わせる前提で、もっと大きなモデルベース検索システムに匹敵、あるいは超えると主張しています。
DJレン:
関連する議論として、xuzihuan4 が面白い問いを投げていて、
「エージェントが検索クエリを自分で反復改善できるなら、語彙ベースのlexical retrievalでも十分なのでは？」
と。
つまり、retrieverを過剰に賢くするより、検索ループ全体を賢くした方がいいかもしれない、と。
4. 学習最適化、SOAP/Muon、高速化、形式手法との接続
DJミオ:
学習最適化の話もかなり濃いです。
特に SOAP/Muon系の高速アップデート。
DJレン:
torchcompiled は、SOAPのbasis updateに対して tangent-step + Stiefel manifold retraction を適用。
その後の議論では、ドリフトチェックや安定化のための QR fallback が話題に。
DJミオ:
あと Modded-NanoGPT コミュニティでは、SOAP-Muonが3150 stepsで新記録、しかも**-60**改善。
さらに、以前の MuLoCo風のouter Nesterov SGD wrapをNorMuonHに被せる手法も改善を出していて、p-value報告付き。
このへん、単なる“速くなった気がする”じゃなく、統計的に扱おうという姿勢が見えます。
DJレン:
そしてかなりロマンがあるのが、形式手法とMLシステム最適化の融合。
leloykun は、Lean4-to-TileLang tensor program superoptimizer を紹介。
これが自動的に FlashAttention2、FlashNorm、split-k matmul みたいなカーネルを発見できて、A100で幾何平均1.8倍 の速度向上を報告。
DJミオ:
しかもこの枠組み、カーネルだけでなく、
- オプティマイザ
- ハイパーパラメータ転移ルール
- スケーリング則
まで共同探索できる方向性が示されています。
“Leanで証明しつつ性能探索”みたいな世界観ですね。
5. スケーリング則の見直しと訓練時限定の効率化
DJレン:
スケーリング則の話では、che_shr_cat が「1パラメータあたり20トークン」という定番フレームに異議。
その数字はトークナイザ依存だから、スケーリングはトークンじゃなくバイトで測るべきだと。
DJミオ:
それに対して JJitsev は、スケーリング則は予測だけでなく、異なる学習手法をスケール横断で比較する体系的な土台としても重要だと強調。
つまり、「未来の性能予報」だけでなく「手法比較の共通言語」でもある、ということですね。
DJレン:
そして訓練時だけ効く効率化トリックも面白い。
NousのLighthouse Attention は、通常attentionの外側にかぶせるsubquadraticな訓練ラッパーで、長文脈事前学習のコストを下げつつ、訓練終盤にrecovery phaseを経て取り外せる。
つまり、推論時は標準attentionのまま でいける。
DJミオ:
同じ発想で、Prime IntellectのRenderers は、RLトレーナーとエージェント環境の間にあるtoken/messageのインピーダンスミスマッチを解消して、人気のオープンモデルで3倍超のスループットを主張しています。
6. 推論システム、Blackwell、専用オーケストレーション、OSS経済性
DJレン:
推論インフラは、かなり“実運用”寄り。
まず大きいのが Blackwellラックが大規模MoE配信の基準機になりつつある という話。
DJミオ:
Perplexity が、Qwen3 235Bのポストトレイン版を NVIDIA GB200 NVL72 で配信する詳細を公開。
主張としては、GB200は大規模MoE推論でHopper世代から大きな前進。
具体的には、
- NVLS all-reduce latency が H200の586.1µs → GB200の313.3µs
- MoE prefill combine at EP=4 が 730.1µs → 438.5µs
- 高トークン率でdecode throughputも改善
という数字が出ています。
DJレン:
AravSrinivas はこれを、大規模MoEのprefill/decode分離設計を実質的に変える と表現。
つまりハード進化がサービング設計を再定義してる。
DJミオ:
その一方で、推論オーケストレーションは「Kubernetesでいいじゃん」では済まない、と。
Modal は、推論には
- compute management
- cloud-native caching
- CRIU
- GPU checkpointing
みたいな専用スタックが必要だと主張しています。
DJレン:
しかもこれ、すぐ実例がついてきて、Perceptron が「Mk1の推論実行は全部Modal」と表明。
理由は、ネイティブ動画、structured outputs、hybrid reasoning があって、コールドスタートとスケーリング要件が特殊だから。
DJミオ:
オープンソース推論経済性の改善も速い。
SemiAnalysis は、複数のB200 8-GPUマシンをRoCEv2 CX-7 + PD disaggregationでクラスタ化すると、GPUあたりトークンスループットが最大7倍に上がり得る、と報告。
つまり、コスト/トークンも同程度に下がる可能性がある。
DJレン:
ベクタDB側では Qdrant 1.18。
TurboQuant を追加して、scalar quantization並みのリコールを保ちつつメモリ半減を主張。
さらにメモリ監視や named-vector のライフサイクル操作も入ってます。
7. エージェント実行基盤は“GitみたいなOS”へ
DJミオ:
システム発想としてかなり目立っていたのが、Stanford系の Shepherd。
DJレン:
ai_satoru_chan による要約では、Shepherdはエージェント実行をGitのように扱う。
つまり、
- first-classな task
- effects
- scopes
- traces
- exact replay
- branching
- rollback
- Leanによる形式保証
を持つ。
DJミオ:
結果として、CooperBenchでlive supervisionが28.8%→54.7% に向上。
さらに、counterfactual optimization や tree-RL rollout も高速化。
これは“エージェントを実行する”から、“エージェントの実行履歴を編集・分岐・再現する”への発想転換ですね。
8. 製品とモデルのリリース：動画・埋め込み・マルチモーダルUI
DJレン:
新モデルやプロダクトもいくつか。
中心は Perceptron Mk1。
DJミオ:
これは frontier video and embodied reasoning 向けモデルとして発表。
特徴は、
- 最大2 FPSのネイティブ動画入力
- temporal grounding
- multimodal in-context learning
-
構造化された空間出力
です。
OpenRouterのまとめでは、32kのマルチモーダル文脈を持ち、出力として points, boxes, polygons, clips を一級市民として扱える。
つまり単なるVLMではなく、物理世界推論スタックとして打ち出しているわけです。
DJレン:
GoogleとMetaは単体モデルスペックより、インタラクション層を推してきた感じ。
Google DeepMindは、Gemini連携のAIポインタ/マウスカーソルのデモ。
画面上の対象を指しながら、ユーザーが省略的な音声指示を出せる。
DJミオ:
Metaは Muse Spark による Meta AI音声会話 を発表。
- 割り込み
- 言語切り替え
- 画像生成
- ライブカメラ連動
などを追加。
どちらも“チャットウィンドウからOSや日常インターフェースへ”という流れが見えます。
DJレン:
埋め込みモデルでは Jinaのjina-embeddings-v5-omni。
テキスト・画像・音声・動画に対応するユニバーサル埋め込みで、1.57B版と0.95B版。
Matryoshka truncation に対応し、既存の v5-text indexとの後方互換もある。
DJミオ:
Metaは静かに Sapiens2 も出しています。
これは人間中心の高解像度ViT群で、0.1B〜5B のスケール。
用途は pose estimation、segmentation、normals、pointmaps。
DJレン:
画像・拡散まわりでは Diffusers 0.38.0。
新パイプラインとして
- Ace-Step 1.5
- LongCat-AudioDiT
- Ernie-Image
を追加。
さらに Flash Attention 4、FlashPack loading、文脈並列向けの Ring Anything にも対応。
DJミオ:
研究リリースとしては、
- ELF: Embedded Language Flows という連続空間テキスト拡散モデル
- Tencentの Pixal3D という pixel-aligned 3D生成
も言及されていました。
9. エージェント開発、状態管理、合成データ、RL環境生成
DJレン:
開発者向けツールの話も濃いです。
エージェント製品が“デモ”から“運用プラットフォーム”へ移ってる。
DJミオ:
まず OpenAIのSymphony。
“すべてのオープンタスクに、実行中のCodexエージェントがつく”という方向性が示唆されました。
それに加えて、Codex向けの computer use、つまりアプリ横断で作業できるが、完全な乗っ取り型ではない仕組みも強調。
DJレン:
LangChain は刷新した Chat LangChain app を再オープンソース化。
ほぼ週2兆トークン を処理する本番Q&Aエージェントだと説明してます。かなり大規模。
DJミオ:
長時間動くエージェントの状態管理も一級課題になってきていて、
LangGraphのDeltaChannel snapshots が登場。
これはフルステートのチェックポイントを置き換える方向で、durable execution をよりスケーラブルにするもの。
LangChainによると、これが今や deepagents v0.6 のメッセージ履歴やファイル保存も支えている。
DJレン:
似たパターンはGoogleにもあって、Gemini Interactions API guide では、encrypted thought signatures が紹介されてます。
statefulでもstatelessでも、推論文脈をターン間で保つ ための仕組みで、開発者が毎回署名注入を管理しなくていい。
DJミオ:
合成データやRL環境生成も、だいぶ実務化してます。
Vtrivedy10 は、実務者視点として、モデル重みからのターゲット型合成データ抽出は大規模では難しい、特に長系列のような過少代表分布では難しいと指摘。
有効なパイプラインには、
- programmatic tests
- verifiers
- judges
- 長期ホライズンのagentic framing
が必要だと。
DJレン:
そしてインフラとしては Tau2-Infinity。
これは、RLポストトレーニング向けの難しいツール使用タスクを、DAG walk や failure hypothesisからのworld generation で自律採掘する枠組みとして紹介されてます。
10. 反応が大きかった話題トップ
DJミオ:
技術関連に絞ったエンゲージメント上位も整理しておきましょう。
DJレン:
まず、Gemini as an OS-level intelligence layer。
Googleの Gemini Intelligence、Googlebook、AI pointer を合わせて見ると、AIエージェントUXがチャット窓からOS層へ移る流れが見える、という話。
DJミオ:
次に大きいのが、Isomorphic Labsの資金調達。
Demis Hassabis が、AI創薬向けプラットフォームとして 21億ドルの新規資金 を発表。
このデータセット中でも最大級の応用AIへの資本コミットメントです。
DJレン:
音声対音声の評価では、Artificial Analysisのτ-Voice benchmark。
現実的なカスタマーサービスのシナリオを、最高クラスのS2Sモデルでも半分程度しか解けない。
首位は Grok Voice Think Fast 1.0で52.1%。
DJミオ:
それと、Claude Opus 4.7 fast mode。
APIとClaude Codeに到達して、Cursor のコメントでは、2.5倍高速で、コストは6倍。
速度と価格の新しいトレードオフ点として具体的ですね。
11. セキュリティ：Mini Shai-Hulud供給網攻撃と安全なコード生成
DJレン:
今日いちばん切迫していた運用ストーリーは、これ。
Mini Shai-Hulud supply-chain attack。
DJミオ:
IntCyberDigest によると、この攻撃は TanStack だけじゃなく、OpenSearch、Mistral AI、Guardrails AI、UiPath などにも拡大。
しかも npmとPyPI をまたぎ、AI開発ツールを狙っていたとされます。
DJレン:
怖いのは持続性。
報告では、Claude Codeの .claude/settings.json や、VS Codeの .vscode/tasks.json にフックして、パッケージ除去後も将来のツールイベントで再実行される 可能性がある。
単なる“一回感染”じゃなく、開発環境に居座るタイプ。
DJミオ:
Guardrails AI は、0.10.1パッケージが侵害されていた と後に確認し、約2時間で隔離したとされています。
DJレン:
対策もすぐ共有されていて、
ramimacisabird は minimumReleaseAge だけでは足りず、blockExoticSubdeps も有効にして、dependency graphにリモートGitHub参照が紛れ込むのを防ぐべき と提案。
DJミオ:
elithrar は、GitHub Actionsの pull_request_target が、フォーク由来PR自動化において依然として危険なCI/CDフットガン だと再警告。
それから andersonbcdefg は、開発機の秘密情報をあちこちの .env に置くのをやめて、proper secrets manager を使うべきと勧めています。
DJレン:
安全なコード生成そのものも研究テーマ化。
Stanford系の SecureForge は、LLM生成コードの脆弱性発見・予防を、prompt optimization を通じて狙う。
コード生成とセキュリティ評価の橋渡しですね。
DJミオ:
全体のメッセージははっきりしていて、コーディングエージェントが強くなった今、供給網防御と安全生成評価は周辺事項じゃなく中核インフラ だということです。
Reddit Recap
12. /r/LocalLlama + /r/localLLM：Qwen 3.6 MTPと長文脈ローカル評価
DJレン:
ここからはReddit。まずはローカルLLM勢の熱量が高かった Qwen 3.6 関連。
DJミオ:
話題のひとつめは、UnslothのMTP保持GGUF。
具体的には
unsloth/Qwen3.6-27B-GGUF-MTP-
unsloth/Qwen3.6-35B-A3B-GGUF-MTP
が出ていて、MTP/next-token-prediction auxiliary layerを保持したGGUF が注目されました。
DJレン:
ただし実用面はまだ不安定。
現状、特定のllama.cppのMTP対応PRをcheckoutしてビルドする必要がありそう で、通常のllama.cppでそのまま動くわけではない雰囲気。
実際、あるユーザーはロード時に
GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0")
というアサーション失敗を報告しています。
DJミオ:
つまり、nextn_predict_layersメタデータが欠けているか露出されていない 可能性があり、GGUFやツールチェーンのサポートがまだ脆い。
コメント欄でも、llama.cppやvLLMのネイティブMTP対応が来たかどうか を、みんな上流リポジトリをリロードしながら追ってる感じでした。
DJレン:
一方で、MTP対応自体はローカル推論で重要視されていて、とくに 35B A3B は文脈長改善への期待もあって、かなり注目されています。
13. Qwen 3.6 35B A3B vs Gemma 4 26Bなどの長文脈実戦比較
DJミオ:
次は「Qwen 3.6 35B A3B hype is real」系の投稿。
あるユーザーが、
- Qwen 3.6 35B A3B
- Qwen 3.6 27B
- Gemma 4 26B A4B
- Nemotron 3 Nano
を、ニッチなpaper-to-code理解タスクで比較しました。
DJレン:
入力が面白くて、学術論文 + 付随する研究コード を長文脈で食わせる。
そのために gated delta nets、hybrid Mamba2、sliding-window attention みたいな長文脈手法を使ってる。
DJミオ:
結果としては、4モデルとも過去の小型ベースライン、たとえば Devstral Small 2 よりかなり良く、最強評価はQwen 3.6 35B A3B。
Devstral Small 2は 32GB VRAM/RAM ではこの長文脈ワークロードを収められなかったそうです。
DJレン:
コメントでは、実務上の使い分けも共有されていて、
- Gemma 26B は速いので、コード修正やチャット向き
-
Qwen 35B は長文脈のリファクタや重めの作業向き
ただし thinking modeで冗長に考えすぎて遅い と。
DJミオ:
量子化サイズの話もあって、あるユーザーは q4でQwen 35Bが約20GB、Gemma 26Bが約15GB と報告。
だから両方同時に常駐させて、用途で切り替えられる。
DJレン:
さらに別の報告では、Qwen 27B は10万行超の大規模プロジェクトでも、最初のセットアップだけ強いモデルやコーディングエージェントでブートストラップし、その後Qwenに渡せば結構戦える、と。
DeepSeek V4との差は実用上あまり感じないという声もありました。
DJミオ:
ただしQwenは、たまにループに入って手動中断→続きを促す必要があるとも。
そして再現性へのツッコミも強くて、推論設定が書かれていないという批判。
温度、サンプラー、量子化、KVキャッシュ、文脈長、バックエンド、ハードウェア……
このへんが出てないと評価しづらい、と。
14. メモリ階層型・省電力ローカル推論
DJレン:
ローカル推論ハードウェアの変態枠も熱かった。
まずは Intel Optane Persistent Memoryで1兆パラメータ級モデルを4 tok/s超 という投稿。
DJミオ:
構成は、768GBのOptane DC Persistent Memory DIMMをMemory Mode で使い、192GB DDR4 ECC DRAMがキャッシュとして機能。
その上で Kimi K2.5、約1TパラメータのMoEモデル を、llama.cppのCPU/GPUハイブリッド推論でローカル実行、約4 tokens/s だという主張です。
DJレン:
モデルの疎なexpert重みをPMem側に置き、attention/dense/shared expert/routing あたりを RTX 3060 12GB に載せる。
override-tensor や ngl auto/cmoe 的な設定で回しているようです。
DJミオ:
コメントでは、
- Xeon Gold 6246の12コアより、8260級24コアやQQ89 ES のほうが伸びるのでは
-
OptaneのStorage Mode + mmap のほうがMemory Modeより速いかも
といった議論がありました。
Memory ModeはDRAMを透明キャッシュにするので、普通のRAMと同じ遅延ではないんですよね。
DJレン:
プラットフォーム互換性メモも有益で、
- LGA3647のSkylake/Cascade Lake は1世代目Optane NMAで2666 MT/s
-
LGA4189 は2世代目NMBで、Cooper Lakeは2666、Ice Lakeは3200
さらに、Cascade LakeではOptane混在でチャネルが2666に落ちたり、総メモリ上限が1TBだったりする、という整理も。
DJミオ:
そして現実的なツッコミとして、4 tok/sは生成だけなら我慢できても、prefillはもっと遅いだろう という指摘。
中古構成の総額見積もりは 約2060〜2500ドル とされていました。
15. 電力制限でローカル推論を賢く回す
DJレン:
次の投稿タイトルはストレートで、「Stop wasting electricity」。
DJミオ:
RTX 4090 上で、llama.cpp llama-server と Qwen3.6-27B-UD-Q4_K_XL.gguf を使い、
-
-ngl allのフルGPUオフロード - FlashAttention有効
-
q4_0のKV cache quantization - 32 threads
-
262144コンテキスト
という設定で、nvidia-smi -pl NによるGPU power capを変えて計測した投稿です。
DJレン:
結果は、GPUが常にpower-limited で、電力上限を下げてもdecode/tokgen性能はほぼ落ちない。
熱、消費電力、騒音をかなり減らせる可能性がある、と。
DJミオ:
ただしコメントで重要だったのが、decodeとprefillは分けて見ろ という点。
prefillのほうが電力制限に敏感で、ある人は450W→270Wでprefill性能が15〜20%落ちる、モデル依存だけど、という定量を出していました。
つまり、対話中心ならかなり省電力化しやすいけど、長大プロンプトを毎回突っ込む用途では影響が大きい。
DJレン:
RTX 5090 ユーザーが「そもそも安全面でpower capしてるけど、もっと下げるかも」と反応してたのも印象的でした。
16. 超小型オンデバイスTransformer実験
DJミオ:
そしてローカル推論のロマン枠。
“純正Game Boy Colorで本物のTransformer言語モデルを走らせた” という投稿。
DJレン:
これは KarpathyのTinyStories-260K を INT8/固定小数点 に変換して、GBDK-2020のMBC5 ROM に載せたもの。
重みはバンク切り替え式カートリッジROM、KV cacheはGBC本体RAMが少なすぎるのでカートリッジSRAMに置く。
しかも、PCなし、スマホなし、Wi‑Fiなし、リンクケーブルなし、クラウドなしで、prefill + autoregressive generationのループが本体だけで動作します。
DJミオ:
もちろん実用性は低く、超低速で出力もほぼ意味不明。
でも「Transformerの本質は、十分小さければ極端に非力なCPU風環境でも動く」という証明にはなっています。
関連として、以前の gbalm というGame Boy系言語モデル実験も話題に出ていました。
DJレン:
“CUDAやROCmがなくても動くの？”という問いへの答えでもありますね。
巨大LLMではGPUコンパイラが前提でも、極小モデルなら手書きに近い推論ループで十分、という。
17. Needle：Geminiのツールコーリングを26Mモデルへ蒸留
DJミオ:
もうひとつの小型モデル話題が、Needle。
Cactus Compute が公開した、MITライセンスの26Mパラメータ単発ツールコーリングモデルです。
DJレン:
Gemini由来の合成データで蒸留していて、速度主張が派手。
consumer deviceでprefill 6000 tok/s、decode 1200 tok/s。
重みはHugging Face、コードとドキュメントはGitHub。
DJミオ:
アーキテクチャは Simple Attention Networks。
要は attention + gatingだけで、MLP/FFNなし。
彼らの主張は、関数呼び出しは本質的に、与えられたツールスキーマの検索と組み立てが中心だから、知識を抱えるFFNが必須ではない、というもの。
DJレン:
学習面では、
- 事前学習200Bトークン を 16 TPU v6eで27時間
- さらに 2Bの合成関数呼び出しデータ を 45分
と書かれていました。
そしてベンチでは FunctionGemma-270M、Qwen-0.6B、Granite-350M、LFM2.5-350M を単発関数呼び出しで上回る主張。
ただし、より大きいモデルの方が会話能力全般は広いことは認めています。
DJミオ:
コメントでは、この26Mモデルを軽量ルーターとして使う発想が好評でした。
つまり「これは大きいLLMに送るべきか」「どのツールを使うべきか」を安く判定するゲートにする。
RAGやツール利用のように、知識が外部コンテキストにあるなら、FFNなしでも成立し得るという議論にもつながっています。
DJレン:
ただし懸念もあって、pickleファイル配布はPython依存やデシリアライズ時の任意コード実行リスクがある、という指摘。
それから、Gemini由来のデータだと、Gemini特有のツール利用バイアスや癖が蒸留されるかもしれない、と。
たとえば“猫を避ける”みたいな妙な内部方針や、特定ツールを好む傾向ですね。
Less Technical AI Subreddit Recap
18. Claudeコーディングワークフローと“vibe-coded repo”問題
DJミオ:
ここからは、やや非技術寄りだけど現場感のある話題。
まずは、かなり刺さった投稿、
「3か月もののvibe engineer製repoを引き継いで、人生で一番気持ちいいPRを書いた」。
DJレン:
差分がすごい。
+10,197追加、−3,618,778削除。
投稿者によれば、引き継いだバックエンドリポジトリは
- 30.9万行のコード
- 24万行のドキュメント
- 100万行超のMarkdownログ
- 220個のハンドラのうち使用は約20個
-
40超のシークレットのうち必要なのは2つ
という状態。
DJミオ:
それを Claudeを使って1週間で再構築、機能は維持しつつ、アーキテクチャを整理し、統合テストも追加したそうです。
コメント欄では、AI/エージェント生成コードの保守負債が新しい仕事になるんじゃないか、という見方がかなり強かった。
DJレン:
“vibecodingの熱狂は、非プロの人が多く支えている。だが本番品質のエンジニアリングは別物だ”という温度感もありました。
つまり、短期生産性の裏で保守性が崩れる 問題ですね。
19. Clawdmeter：Claude利用枠の物理メーター
DJミオ:
少し軽めの話題では、Clawdmeter。
これは ESP32 + 480×480 AMOLED の小型デバイスで、Claude/Anthropicの利用上限やリセットタイマー、進捗バー を表示するデスクメーターです。
部品代はだいたい 32ドル。
DJレン:
GitHubでオープンソース化されていて、コメントはほぼ「Anthropicが無料配布しろ」「これで逆に使用不安が増える」みたいなノリ。
DJミオ:
でも実用的な提案もありました。
たとえば、単なる現在値表示ではなく、履歴を記録してグラフ表示したい、コマンド単位でどれだけ使用枠を食っているか を知りたい、と。
さらに、このESP32ディスプレイ基盤を、ほかのスマートホーム系ステータス表示器に流用したいという声も。
20. 現場のAI導入失敗例：教科書事故と結婚式コンシェルジュ
DJレン:
最後は“AIを現場で使うと人間は何をするか”がよく出た話。
まず、教科書にChatGPTっぽい文言が混入していた という投稿。
DJミオ:
DBMSの教科書らしきページに、
「If you want, I can also explain…」
みたいな、明らかにAIアシスタント調の一文がそのまま残っていた、というものですね。
これは厳密な技術ニュースではないけれど、教育コンテンツ生成にAIが広く使われ始めている ことの象徴として扱われていました。
DJレン:
コメントには、教育機関の内部から「学生向けコンテンツへのAI生成利用は、教員・職員・外注先までかなり広がっている」という証言も。
同時に、その画像自体が
- watermark除去っぽい痕跡
- 文字がページ端からはみ出す
- Gemini由来っぽい SynthID/注釈痕
などを含み、画像そのものがAI加工かもしれない という疑義もありました。
DJミオ:
つまり、内容も画像証拠も両方AI臭い という、なんとも2026年らしい話です。
DJレン:
もうひとつが、
「結婚式用AIコンシェルジュを作ったら、二番目に多かった利用が脱獄だった」。
DJミオ:
これ、すごく現実味がある。
モーリシャスでのデスティネーションウェディング向けに、投稿者が
- 結婚準備用アシスタント
-
ゲスト向けAIコンシェルジュ
の2系統を作成。
ゲスト向けは MCP server経由で外部APIに接続し、旅行・会場・イベント情報を返せるようにしていたそうです。
DJレン:
利用実績は、29人のユーザーで719セッション、8678メッセージ。
内訳がすごくて、
- 35%が真面目なロジスティクス質問
- 25%がjailbreak/hacking試行
- そのほか文化翻訳、雑談、その他
という割合。
DJミオ:
たった29人で8000メッセージ超というのも驚きですが、人は目の前にチャットボットがあると高確率で壊しにくる、という現実がよく出ています。
コメントでは、会話ログを主催者が読めるのか、ゲストにその認識があったのか という、観測性・同意・プライバシーの懸念も出ていました。
21. Discord欄の終わりと全体総括
DJレン:
そして最後に、AINewsのDiscord欄。
今回は内容そのものより告知が重要で、Discord側のアクセスが止まり、この形では復活しない。
その代わり、新しいAINewsを提供していく とのことでした。
DJミオ:
では今夜のまとめ、いきましょう。
まとめ
DJレン:
今日の全体像を一言で言うなら、
“派手な一発ニュースは少ないが、AIの基礎体力が着実に上がっている日”。
DJミオ:
具体的には、
- ベンチマークはより難しく、より研究寄りに
- エージェントは数学・物理・コード生成で実スコアを押し上げ
- 検索は小型専用retrieverが強さを見せ
- 訓練最適化はSOAP/Muonや形式手法で深化
- 推論基盤はBlackwell、専用オーケストレーション、OSS効率化へ
- 状態管理はGit的・差分的・再実行可能な方向へ
- ローカルLLMはQwen 3.6、Optane、電力最適化、超小型端末実験で広がり
- そしてセキュリティは、AI開発環境そのものが攻撃面になっている
ということでした。
DJレン:
あと、個人的に象徴的だったのは二つ。
ひとつは、Game Boy ColorでもTransformerは動く という夢。
もうひとつは、結婚式AIコンシェルジュが速攻で脱獄される という現実。
DJミオ:
夢と現実、その両方がAIなんですよね。
研究室からGB200ラック、そして個人の披露宴会場まで、全部つながってる。
DJレン:
というわけで、今夜の「Midnight AI Groove」はここまで。
DJレンでした。
DJミオ:
DJミオでした。
また次回、深夜のAIトレンドをグルーヴに乗せてお届けします。
おやすみなさい。
