SE：深夜のシンセウェーブ、ゆったりしたビート
DJミオ：
こんばんは、未来と現実のあいだをグルーヴする、Midnight AI Groove。ナビゲーターのDJミオです。
DJレン：
そして相方はDJレン。今夜もAI界隈の出来事を、ノリは軽やかに、でも中身はしっかり教育番組としてお届けしていきます。
DJミオ：
今日の中心テーマは、かなり異色です。画像生成の会社として知られるMidjourneyが、なんと医療用スキャナーを発表した、という話題からスタートします。
DJレン：
しかも単なるイメージや研究構想じゃなくて、実機デモに触れた人までいた、というのがポイントなんだよね。
加えて今回はその周辺で語られていた、AI研究、オープンモデル、推論最適化、コーディングエージェント、セキュリティ、そして業界人事まで、かなり広い範囲を一気に見ていく回です。
DJミオ：
じゃあまずは、今夜のトップストーリー。
「Midjourney Medical: scan your organs like you step on a scale」。
“体重計に乗るみたいに、臓器をスキャンする”という、かなり印象的な見出しです。
1. Midjourney Medicalとは何か
DJレン：
今回起きたことを整理すると、Midjourneyが**“Midjourney Scanner”と呼ばれる医療画像・医療スキャン系システムを公開し、さらにそのtechnical dive**、つまり技術的な解説まで出した、という流れです。
DJミオ：
この発表が面白かったのは、みんなの反応が「すごい！」だけじゃなくて、
驚き、好奇心、懐疑、戦略的な見方まで混ざっていたところですね。
「AIラボが医療ハードウェアに行くの？」という、領域の越境そのものが話題になった。
DJレン：
そう。Midjourneyって普通は画像生成サービスの会社として知られてるから、いきなりスキャナー、しかも医療寄り、というのはかなり非連続に見える。
だからこそ、単なる新製品発表以上に「AI企業って今どこまで物理世界に踏み込むのか」という象徴的なニュースとして受け取られたんだ。
2. まず事実として何がわかっているのか
DJミオ：
ここ大事なので、まず事実ベースで整理します。本文中で明示されている要素は、だいたいこんな感じです。
- Midjourneyが**“Midjourney Scanner”**の技術的な紹介を公開した。
- そのスキャナーは、少なくとも紹介上は
- 放射線を使わない
- 磁石を使わない
- 高速
-
低コスト
とされている。
- 一方で、
- 水に浸かるタンクが必要
-
解像度はCTやMRIより粗い
という制約もある。
- そして実際に、ある人が手をデモ機に入れて試したと語っていて、概念図だけではなく現物プロトタイプらしきものが存在していた。
DJレン：
つまり、「夢の万能スキャナーができました」という話ではなくて、
明確なトレードオフを伴う新規モダリティっぽいものとして出てきたわけだね。
DJミオ：
はい。しかもこの段階では、本文にある情報から言う限り、
CTやMRIを全部置き換えるなんて主張はしていない。
むしろ逆に、「解像度はCT/MRIより低い」と書かれているのが重要です。
3. 技術的にどんな方式っぽいのか
DJレン：
ここからは、本文が示す範囲での推定や技術的読み解きだね。
まず「放射線を使わない」ので、X線CT系ではなさそう。
そして「磁石を使わない」から、MRIでもない。
DJミオ：
さらに大きなヒントが、水に浸かるタンクです。
これは波動系、特に音響イメージングとか、何らかの波の伝播を使う計測を連想させます。
水は、発信器・人体組織・受信器のあいだの結合をよくする用途で使われることがあるので、この点がかなり強い手がかりになっている。
DJレン：
本文中でも、確定はされていないけど、acoustic imagingとかwave propagationっぽい文脈が前面に出てる。
要するに、光、超音波、電流、その他の波を使う計測では、X線のように“ほぼ直進するものを撮る”よりも、再構成問題が難しいことが多い。
DJミオ：
そう。John Whitakerの技術的コメントとして紹介されていたのが、
光や超音波や電流などを使う方式は、X線より逆問題が難しいという点。
信号が単純な直線経路で進まないので、内部構造を画像として復元するのがかなり複雑になるんです。
DJレン：
この「逆問題」って、教育番組として一言でいうと、
観測された信号から、元の内部構造を推定する問題だね。
見えている結果から、見えていない原因を推理する。
医療画像ではこれが中核。
DJミオ：
そしてこの種の装置では、ハードそのものだけじゃなく、
再構成アルゴリズム、ノイズ除去、超解像、さらには解釈支援まで、AIや機械学習が大きな役割を持ちうる。
Midjourneyのブランドが「学習された視覚システム」に結びついているからこそ、みんながそこに期待を投影した、という文脈も本文で指摘されていました。
4. このスキャナーの売りは何か
DJレン：
現時点での本文の読みからすると、この装置の売りは、
最高画質ではなく、アクセス性と運用性の改善にある可能性が高い。
DJミオ：
具体的には、
-
放射線がない
-
磁場も使わない
-
速い
-
安い
という条件ですね。
これが本当なら、医療現場での用途は“最高精度の精密検査”ではなく、むしろ -
スクリーニング
-
トリアージ
-
CT/MRIが使いにくい環境での代替的手段
-
繰り返し撮像が必要で、放射線を避けたい場面
-
水槽方式でも許容される特定部位・特定ワークフロー
みたいなところが候補になる。
DJレン：
本文にも、これは「すべての軸でMRI/CTより良い」ではなく、
高級指標では負けるけど、コストや可搬性やアクセス性で勝つタイプの破壊的イノベーション路線かもしれない、とあった。
そこがすごく現実的な見方だよね。
5. でも課題もかなり大きい
DJミオ：
もちろん、懐疑的な見方も強いです。本文にある論点を整理すると、まず第一に、
解像度がCT/MRIより粗い。
これは医療ではかなり大きい。画像の質は診断能力に直結することがあるので、「ちょっと粗いです」は軽い欠点ではありません。
DJレン：
次に、水のタンクに入る必要がある。
これも現場導入ではかなり大きな制約だね。
一部の用途なら許容されても、日常診療や一般消費者向けに広げるには、人間工学的にも運用上もハードルがある。
DJミオ：
そして三つ目が、さっきのモダリティの難しさ。
波がまっすぐ飛ばない、複雑に散乱する、境界条件の影響も受ける、そういう信号から安定して臨床的に信頼できる画像を再構成できるのか、という問題があります。
DJレン：
つまり、派手なデモがそのまま臨床の頑丈さを意味するわけではない。
医療機器って、見た目が面白いだけじゃ全然足りないんだよね。
6. 反応の3つの系統：楽観・技術好奇心・慎重論
DJミオ：
本文では、このニュースへの反応をいくつかの立場に分けていました。
まずは支持・楽観派。
DJレン：
この層は、「まさにこういう変なことをやる創業者が必要なんだ」と見る。
チャットUIや小さな改善じゃなくて、非連続な、非コンセンサスな発明に挑んでいること自体を評価している。
「let inventors invent」みたいな空気だね。
DJミオ：
しかも、実機に触れた人がいるということで、
「論文を読んだ」「PVを見た」ではなく、本当に触れる変な装置がそこにあるという身体感覚のインパクトも強かった。
DJレン：
次が中立・技術好奇心派。
この立場は一番地に足がついていて、
「放射線なし・磁石なし・速い・安い、でも水タンクが必要で解像度は低い」
という、まさに長所短所の要約を冷静に見る。
DJミオ：
さらに、
- どんな送受信器配置なのか
- 機械的に動かして走査しているのか
- 将来的には散在した検出器・エミッタを多数置いてリアルタイム化できるのか
といった、設計の方向性への好奇心が語られていた。
DJレン：
そして三つ目が慎重派・懐疑派。
露骨な敵意は少ないけれど、
- 解像度不足
- 水槽という実用制約
- 逆問題の難しさ
- “見栄えのよいデモ”と“堅牢な臨床性能”の間の距離
を考えると、簡単には信用できない、というわけだ。
7. なぜこの話がそんなに重要なのか
DJミオ：
このニュースが注目された最大の理由は、装置単体の性能より、
Midjourneyがそこにいること自体にあります。
DJレン：
そうだね。Midjourneyは本来、画像生成の会社として有名。
そこから現実世界のセンシング・ハードウェア・医療装置へ来る。
これは単なる事業多角化じゃなくて、AI企業の自己定義が変わってきている兆候と読める。
DJミオ：
本文でも、「モデルベンダー」ではなく、
物理世界への新しいインターフェースを作る会社としてAI隣接企業が自分を再定義し始めている、という2025年以降の流れに位置づけられていました。
DJレン：
しかも医療画像は、単なるソフトウェアとは違って、
- 物理計測
- 信号処理
- 画像再構成
- MLベースの解釈
が全部絡む深い領域。
AI会社がここに来るなら、かなり本気のフルスタック応用発明なんだよね。
8. まだわからないこと、開かれた問い
DJミオ：
ただし、本文が強調していたように、重要なのにまだ不明な点が多いです。
DJレン：
まず規制と承認の道筋。
医療機器として使うなら、承認、検証試験、臨床バリデーションが必要。
でも本文の範囲では、研究用なのか、臨床展開を本気で目指しているのか、そこは不明。
DJミオ：
次に再構成スタックの中身。
technical diveと言いつつ、ここで引用されている投稿群だけからは、アルゴリズムの本丸は見えない。
制約の大きいセンシング条件から、どこまで有用な画像を引き出せるのか。そこが勝負です。
DJレン：
さらにユースケースの特定。
解像度がCT/MRIより低くても、狭い用途で“十分役立つ”なら勝てる可能性はある。
でも「どの疾患」「どの部位」「どのワークフロー」を狙っているのかは、この本文でははっきりしない。
DJミオ：
フォームファクターも大問題。
水槽は試作機ゆえの仮の形なのか、それともこの方式に本質的に必要なのか。
そこが違うだけで未来像は大きく変わります。
DJレン：
あとはコストとスループットの現実性。
“速い”“安い”と言っても、
- 実際の撮影時間
- 装置価格
- 消耗品
- オペレーター負荷
- 画像読影や後処理の手間
みたいな数字がないと、比較できない。
DJミオ：
そして最後に、AIの役割はどこにあるのか。
- ハード設計なのか
- 逆問題の解法なのか
- ノイズ除去や超解像なのか
- 自動診断支援なのか
- あるいはそれらを統合したスタック全体なのか
ここも今後の核心ですね。
9. 競争戦略としてどう見られたか
DJレン：
本文では、Midjourney Scanner自体だけじゃなく、
他のAI企業との比較も語られていた。
ある反応では、もっと地味なウェアラブルカメラ系のAIハードウェアより、Midjourneyのほうが圧倒的に大胆だ、という競争的 framing が出ていた。
DJミオ：
つまり、「他社がラペルカメラみたいなものを作っている間に、Midjourneyは医療スキャナーを作っているのか」という見方ですね。
もちろんこれは感情的で誇張もあるけれど、
AI企業の野心の見せ方としては強烈だった、ということです。
ここからは番組後半、同じ本文に含まれていた他のAIニュースも整理していきます。
10. 研究・エージェント・オープンモデルの話題
DJミオ：
Midjourney Medicalのあと、本文はより広いAI研究とエージェントの話題に移っています。
まずメタな話として、中国のオープンソース文献は追う価値が高いというコメントが出ていましたね。
DJレン：
“alpha is insanely huge”という、要するに情報優位が大きい、という主張だね。
実際、今回の本文でも後半はGLM-5.2の話がかなり大きい。
DJミオ：
その前に研究小話を拾うと、
PapersWithCodeのトレンド論文としてVibeThinker-3Bが挙がっていました。
3Bという小さめのモデルで、検証可能な推論を探る方向性が注目され、DeepSeek V3.2やGLM-5、Gemini 3 Pro級の性能帯に食い込むと言われていた。
DJレン：
エージェント系では、PreActという論文が面白い。
成功したエージェント実行を再生可能な状態機械にコンパイルして、同じルートなら毎回LMを逐次呼ばなくて済む。
結果として8.5倍から13倍速い再生ができる、という話だね。
DJミオ：
これは実務的にすごく重要です。
エージェントは“賢さ”より、同じ成功手順を安く安定して再利用できるかが価値になることがある。
毎回フル推論だとコストも遅延も大きいですからね。
DJレン：
もうひとつ、LLM-as-Environment-Engineer。
失敗したら、次の訓練環境を自分で組み替える、という発想。
ベンチマークはMAPF-FrozenLake。
エージェントが環境設計に踏み込む、というメタ学習寄りの考え方だ。
DJミオ：
実運用の視点では、Omar Sar0の
“コーディングエージェントには検証器と堅牢なガードレールが必要で、盲目的な自律ループはだめ”
という主張も紹介されていました。
最近のトレンドとして、何でも自律に任せるより、制約されたエージェント実行のほうが評価されている。
DJレン：
David Khourshidの
“AIが書いたコードも読まなきゃいけない。読まないのはデバッグ負債を先送りしてるだけ”
という指摘も、かなり地味だけど重要だね。
11. PPO、GRPO、その周辺の理論の再検討
DJミオ：
RL理論の話もありました。John Schulmanが、
PPOがLLM時代に再評価されている理由は、元論文で予期していなかった効果が効いているからだ
と述べていた。
DJレン：
具体的には、importance ratio の目的関数が、
- 数値誤差
- 非同期学習
- forward passのノイズ
によるバイアス補正に役立っていたとか、
さらにクリッピングがエントロピーに与える影響も、後になって理解が進んだ、と。
DJミオ：
関連して、Chris Wolfeが
DAPO、Dr. GRPO、GSPO、TISのようなpost-GRPO分析論文を高く評価していました。
推論やエージェント文脈で、PPO系の目的関数をちゃんと分析する研究がもっと必要だ、という流れです。
DJレン：
あとJohn Carmackの話もあったね。
Temporal Differences for visual representation learningへの批判。
フレームエンコーダと“motion encoder”を学習し、
latent(frame1) + delta ≈ latent(frame2) になるようにする、0.25秒ストライドの方法なんだけど、
CarmackはDINOのEMA anti-collapse の選択や、delta構成の健全性に疑問を投げていた。
DJミオ：
この辺りは、いかにも研究者・実装者コミュニティらしい、かなり生の議論ですね。
12. 推論基盤・製品ロールアウトの話
DJレン：
インフラ・推論最適化の話も面白かった。
まずXenovaが、終了したFable 5プロジェクト由来のカーネルやデモを公開して、
Gemma 4をWebGPUで255 tok/sまで押し上げた、と主張していた。
DJミオ：
ブラウザ内・オンデバイス推論において、カーネル最適化がかなり効くという話ですね。
単にモデルを軽量化するだけじゃなく、エージェント的に推論カーネルを最適化する余地が大きい。
DJレン：
動画系ではFalがKling 3.0 TurboとO3のアップグレードを発表。
改善点はかなり具体的で、
- 生成高速化
- 低コスト化
- リップシンク向上
- モーション安定化
- Omniでのプロンプト・参照整合性向上
- 最大15秒クリップ
- 4K生成
- ストーリーボードとマルチショットの改善
が並んでいた。
DJミオ：
コーディング支援では、GitHub CopilotのAuto modeが、
推論深度やコード複雑性、デバッグ困難度、ツールオーケストレーションの必要性に応じて、
カスタムルーティングモデルで最適なモデルを選ぶようになった、という共有もありました。
DJレン：
これは「単一モデルに全部やらせる」から、
状況に応じて裏側でモデルを切り替える設計への移行だね。
今後のプロダクト設計の基本パターンになりそう。
13. 人材移動とラボ間競争
DJミオ：
次は業界の人材ニュース。Midjourneyの外で最も大きな話として、
Noam ShazeerがGoogleを離れてOpenAIに移るというニュースが挙がっていました。
DJレン：
これは相当大きい。Noam Shazeerは、
- Transformer
- T5
-
Switch Transformer
などの共著者で、特に疎なMoEの先駆者として非常に重要な人物。
本文でも「今年最重要のAI人材移動」と呼ぶ声があった。
DJミオ：
Sam Altmanは歓迎コメントを出し、
“OpenAI is SOTA in noams”みたいな冗談まで言っていた。
Aidan Clarkは、Noamと働けることへの興奮を示しつつ、RSIが近づいている感じにも触れていた。
DJレン：
周辺の読みとしては、
- DeepMind/Brain統合の副作用でAnthropicやOpenAIが得をしたのでは
- AnthropicはKarpathy、OpenAIはNoam
- Googleへの失望も移籍理由の一部では
みたいな見方が出ていたね。
さらに評価額でOpenAIがAnthropicを上回った、というポストも紹介されていた。
DJミオ：
ここはかなり推測も混じる領域だけど、
人材・資本・評判が相互に競争ダイナミクスを作っていることはよくわかります。
14. 信頼性・モデル品質・中国モデルの進展
DJレン：
モデル品質の話では、Blanche Minervaが、
ChatGPTとClaudeが、二本の論文の引用重複みたいな具体的な問いでさえ食い違うと不満を述べていた。
応用知識タスクでは、まだ信頼性問題が残るという話だ。
DJミオ：
そして複数の投稿が、GLMを含む中国系モデルの進歩を称賛していました。
GLMチームを“heroic”と呼ぶ声や、最新世代が以前の想定を超えてOpus級に近づいたという見方もあった。
DJレン：
能力向上の源泉として、今後は事前学習規模よりRLレシピが重要になるのでは、という推測も紹介されていた。
一方で、“Claudeらしさ”が出力に出る、みたいなミーム的・半ばステガノグラフィ的な推測もあったけど、これは本文でも明確に確立された事実ではないとされていたね。
15. 技術と社会の雑多な話題
DJミオ：
他にも、Tacit Labs参加の話題で、
AIは既知の知識の組み換えだけでなく、生物学のような領域で本当に新しい知識を見つけるべきだ
という問題意識が語られていました。
DJレン：
逆に、ホワイトハウスが停止性問題の解決を要求している、みたいなジョークもあった。
これはAI政策議論が、ときどき深い計算理論上の不可能性を、簡単な行政要件みたいに圧縮してしまうことへの皮肉だね。
DJミオ：
自動運転については、WaymoやTeslaで実現可能性が高まっているように見える一方で、
新しいAVスタートアップがあまり出てこないという観察もありました。
領域が可能に見えることと、新規参入のしやすさは別、ということですね。
後半戦：Reddit Recap
16. /r/LocalLlama系：GLM-5.2が主役
DJレン：
Reddit recapの中心も、やっぱりGLM-5.2だった。
まず大きな話として、GLM-5.2がTerminal-Bench 2.1で80%を超えた最初のopen-weights modelという評価。
DJミオ：
具体的には81.0で、open modelの中ではかなり強い。
ただしclosed modelのClaude Opus 4.8が85.0、GPT-5.5が84.0でまだ上、という位置づけです。
DJレン：
ここで大事な注意点が、Terminal-Bench 2.1は2より易しくなっている可能性があること。
タイムアウトやルールが緩和されていて、単純比較するとスコアが盛られて見えるかもしれない。
だから“初の80%超え”は事実でも、世代横断比較には慎重さが必要なんだ。
DJミオ：
さらに議論になったのが、
“open weights”は“local”を意味するのか？
ダウンロード可能ならローカルだという意見もあれば、
99%の人にはハードウェア的に実行不可能だからlocalと呼ぶのは現実離れしているという反論もあった。
17. GLM-5.2は“家庭向け”ではなく“蒸留の源泉”として重要？
DJレン：
別の投稿では、GLM-5.2は家庭で動かすというより、
蒸留や合成データ生成のソースとして大事だと整理されていた。
モデルはMITライセンスのMoEで、総パラメータ753B、トークンあたり約40B activeという巨大さ。
DJミオ：
メモリ見積もりも出ていて、FP8で744〜890GB、4bitで476〜500GB、2bitで241〜280GB、1bit dynamic quantで176〜180GB。
しかも1Mコンテキストを本当に使うならKV cacheがさらにかなり増える。
つまり“動くか”だけじゃなく、まともな速度で使えるかが別問題なんですね。
DJレン：
コメントでは、
- 512GB Mac
- GB10クラスター
- 複数のAMD AI Max 128GB機
- カスタムのマルチGPUサーバー
みたいな話が出ていた。
ある人は9,000ドル未満のサーバーで約7 TPSなら使えるかも、と言っていたけど、一般家庭向けとは言いにくい。
DJミオ：
さらに、長文コンテキストではMac Studioが50K超で実用性が落ちるという指摘もあった。
メモリ容量があっても、prompt processing と token generation の速度が悪いと、実務では厳しい。
18. GLM-5.2の実装上の特徴
DJレン：
モデルカード的な投稿では、GLM-5.2は
- 安定した1M token context
- 強化されたコーディング/エージェント性能
- reasoning effortの可変設定
- SGLang, vLLM, Transformers, KTransformers, Ascend NPU対応
などが挙げられていた。
DJミオ：
技術的には、IndexShareという疎アテンションのインデクサ再利用で、
1M context時にper-token FLOPsを2.9倍削減と主張。
さらにMTP speculative decodingの受理長が最大20%伸びたとも書かれていました。
DJレン：
自己申告ではDeepSWE 46.2というスコアもあり、
Claude Opus 4.6やSonnetを上回り、4.7の少し下という位置づけだというコメントもあった。
もちろん独立検証前提だけど、かなり強い主張だ。
DJミオ：
一方で、Hugging Face上のモデルファイルは約1.51TBという巨大さ。
だからみんなもっと小さい派生版や量子化を待っているわけですね。
GLM-5.2-Flash-32B-A4Bを望む声や、0.5Qを冗談半分で待つ声まであった。
19. Design Arena首位と、その読み方
DJレン：
さらにGLM-5.2はDesign Arenaで1位という投稿もあった。
Elo 1360で、現在利用不可のClaude Fable 5の1350を僅差で上回る。
DJミオ：
ただコメントでは、
「まだ早い、数日待って順位が安定するのを見るべき」
という慎重論が出ていた。
アリーナ系は投票が蓄積するまでブレやすいですからね。
DJレン：
加えて、テキスト専用モデルがデザインワークフローで本当に強いのかという疑問もあった。
現実のデザインは視覚確認と反復が必要だから、OCRやVisionモデルとの連携が必要では、という問題提起だ。
20. GGUF量子化とローカル実行への期待
DJミオ：
UnslothがGLM-5.2-GGUFをアップロードし始めている、という話もありました。
まだREADMEしかない段階だったけど、みんな量子化版に期待していた。
DJレン：
でもコメントの空気は、
“で、結局どれくらい量子化しないとローカルで無理？”
“1M contextのKV cacheどうするの？”
という、かなり現実的なものだった。
重みだけ収まっても、長文KV cacheで詰むという指摘はもっともだね。
21. ローカル推論最適化：WebGPUとAMD ROCm
DJレン：
次はローカル推論の最適化。
まず、ブラウザ上でのGemma 4 E2Bの話。
WebGPUカーネルをFable 5由来の最適化で使って、Apple M4 Maxで255 tok/sを出したというデモ。
DJミオ：
コメントでは、
- UIをオープンソース化してほしい
- Firefox非対応なのはWebGPUやブラウザ互換性の問題では
- llama.cppみたいなネイティブランタイムと比べてどうか
- 2GB落としてしまったモデルデータをどう消すのか
みたいな実務寄りの論点が挙がっていました。
DJレン：
別の比較として、A10GでGemma E4Bを約500 TPSまで最適化している試みも言及されていた。
もちろん環境差が大きいけど、協調エージェントによる推論最適化がテーマになっている。
DJミオ：
AMD陣営では、CUDA独占を避けたい、AMDは代替だという投稿。
RX 7800 XT 16GB上でROCm 6.4.4、llama.cpp/llama-serverを回し、
Qwopus系やQwen系GGUFを最大131072 contextで動かしていた。
DJレン：
ここで面白いのは、KV cacheの量子化。
K=q8_0、V=q4_0で、KV cacheメモリを約5.6倍削減し、
重み＋128K KV cacheをVRAMの96%程度に収めてCPU spillなしにしたという。
性能はprefill約210 tok/s、decode 11〜17 tok/s、消費電力188W程度。
長文整合性にはYaRN RoPE scalingが効いているとも書かれていた。
DJミオ：
これは、ローカル推論が単に「どのGPUを買うか」ではなく、
アテンション、KV量子化、オフロード、RoPEスケーリング、ランタイム設定の総合技術になってきていることを示しています。
22. ローカルコーディングエージェントと“蒸留”への警戒
DJレン：
次は、ローカルコーディングエージェントと蒸留モデルへの注意喚起。
まず、Qwen/Claude蒸留モデルには注意という投稿があった。
DJミオ：
主張は、最近よくあるQwenベースClaude蒸留やQwopus系の一部は、
4k〜10kサンプル程度の教師データしかなく、能力移転というより文体模倣に近い。
下手するとベースモデルより悪化する、というもの。
DJレン：
対照的に、DeepSeek-R1の公式distillは70万サンプル規模で、
それくらいあって初めてベンチマークや振る舞いに意味ある変化が出る、と。
コメントでも、能力向上するfine-tuningには10万件以上の精選データ＋GRPO的回復手段が必要では、という意見が出ていた。
DJミオ：
技術的な核心は、API由来蒸留では普通、
完全なlogitsが得られないし、Anthropicは完全なCoTも出さず要約しか見せない。
だから多くの“蒸留”は真の意味でのknowledge distillationではなく、
部分応答に対するSFTに近いという批判です。
DJレン：
ある人の実例では、18k例でGDScript特化モデルを作っても、
期待どおりの出力は安定しなかった。
結論は、fine-tuningは専門化には効いても、知能そのものは足しにくい、ということ。
23. スクリーンショット・ループでローカル30Bがゲームデバッグ
DJミオ：
面白い応用例として、ヘッドレスなスクリーンショットループを使って、
ローカル30Bエージェントが純CのレイトレFPSデモを完成させた、という話もありました。
DJレン：
ポイントは、
- キーボード/マウス入力注入
- 決定論的なフレームキャプチャ
- イベント時点の画像観察
- コード修正
- 再実行
という、視覚フィードバックつきの観察→修正ループを組んだこと。
モデル性能というより、プロンプトとツーリングの勝利だと投稿者は説明していた。
DJミオ：
コメントでは、共有ログファイルに出力を集めて、モデルにログ末尾を読ませ、内部ログも増やさせる、という
observe-debug-fixループの設計が紹介されていました。
4090上でq4_k_m量子化が実用的だった、という使用感も出ていましたね。
Less Technical AI Subreddit Recap
24. Claude Codeがマルウェアを見抜いた話
DJレン：
Less Technical側で一番強烈だったのが、
Claude Opusがrepoに仕込まれたマルウェアを検出し、逆解析までやったという報告。
DJミオ：
具体的には、next.config.jsの末尾に難読化コードが追加されていて、
CIやビルド実行前にそれを検出したという内容。
説明された攻撃チェーンはかなり本格的で、
- git credential窃取
- compromised contractor machine経由の自己伝播
- 偽装コミットメタデータ
- blockchain dead drops
- XORデコードされたインメモリの後続ステージ
- 特定C2への通信
などが含まれていました。
DJレン：
IOCやSHA-256、TRON/Aptos/BSC関連の参照先、グローバル変数名まで挙げられていて、かなり具体的。
ただ、コメント欄で強調されていた本質は、
「Claudeが見つけた」ことより、「next.config.jsのようなビルド時設定コードがCIで実行される特権点だった」ことなんだよね。
DJミオ：
つまりセキュリティ教訓は、
- build-time configは危険
- branch protectionやレビューを厳格に
- force pushを防ぐ
- 依存ライブラリや他言語も含めた供給網全体を点検
という、地味だけど重要なガバナンス面にある。
25. Claude Codeの使用枠を“自分の都合”でリセットする小技
DJレン：
もうひとつ実務的に面白いのが、Claude Codeの5時間ローリング制限を、自分の生活時間に合わせる工夫。
Haikuなどで毎日些細なプロンプトを送って、セッション開始時刻を前倒しするというハックだ。
DJミオ：
たとえば9時に本格作業したいなら、7時ごろに軽い呼び出しをしておいて、
次のリセットを昼に持ってくる。
重いモデルや高トークンのプラグインを使う人には便利、という話でした。
DJレン：
コメントでは、5時間ごとのcron的な更新でトークンを最大化する人もいれば、
Claude自身は“そんなことよりトークン無駄遣いを減らそう”と返してきた、という話もあり、ちょっと笑える。
26. Claude Code勢とチャット勢の格差問題
DJミオ：
コミュニティ論としては、
Claude Codeのパワーユーザーと、チャット専用ユーザーの間のギャップが広がっているという問題提起もありました。
DJレン：
たしかに投稿内容が、CLAUDE.md、MCP、subagents、terminal workflowsなど、
かなり“ツール接続されたCLI前提”に偏っていて、
文章作成、思考整理、学習、計画といった非コーディング用途の人が置いていかれがちという感覚だね。
DJミオ：
一方でコメントでは、Claude Codeの強みはコーディング特化ではなく、
ローカルファイルとコマンドに触れるエージェント環境にあるから、
非エンジニアでもデータをExcelやPDFに整形するなど、一般業務に使える、と主張する声もあった。
DJレン：
ただし問題は導入の摩擦。
MCPサーバーやパッケージ導入、JSON設定などは、
非技術者にとって高すぎる壁。
“それがワンクリックであるべきだ”という指摘は、かなり本質的だと思う。
DJミオ：
投資ワークフローの例も紹介されていましたね。
案件ごとのCLAUDE.md、MCP接続データソース、デューデリジェンス用subagent、財務モデル作成とスライド作成の手順化など。
これをソフト開発機能ではなく、一般的な知的労働インフラとして見るわけです。
27. Anthropic Fableをめぐる政策圧力
DJレン：
政策面では、AnthropicのFable 5に対して、
100% jailbreak-proofでないと出すなという圧力がある、という話題が出ていた。
DJミオ：
これはコメント欄でもかなり強く、
“それはOSに100%無破壊性を求めるのと同じくらい無理”
“負の証明はできない”
といった反応が中心でした。
任意入力・任意文脈に開かれた生成モデルに、絶対的な脱獄不可能性を要求するのは現実的でない、ということです。
DJレン：
一部では、それは技術要件というより、
公開を止めるための政治的ハードルではないか、という推測もあった。
ただ、そこは推測の域を出ない。
DJミオ：
加えて、AnthropicのDario AmodeiとOpenAIのSam Altmanが、
G7で世界の指導者とAI会合に参加したという話もありました。
ただ、元ソースの制約で詳細な政策内容までは確認できていない、と本文にはありましたね。
さいごにDiscordと全体の空気感
28. AI Discordsは静かな日
DJレン：
Discordについては、アクセスが停止されたという告知があって、今回は実質的に“静かな日”扱い。
新しいAINewsを今後出す予定だ、という話で締められていた。
DJミオ：
全体の空気としては、
表面的には「今日はそこまで多くない日」としながらも、
中身を見ると
- Midjourneyの医療スキャナー
- GLM-5.2の躍進
- WebGPU/ROCm最適化
- エージェント安全性
- Claude Code運用知見
- Fableをめぐる政策圧力
- Noam Shazeerの移籍
と、かなり密度が高い一日でした。
29. まとめ：今夜の重要ポイント
DJレン：
じゃあ最後に、今夜のポイントをまとめよう。
DJミオ：
はい、まず第一。
Midjourney Scannerは、本文の範囲で見る限り、
- 放射線なし
- 磁石なし
- 速い
- 低コスト
一方で - 水槽が必要
- 解像度はCT/MRI以下
という明確なトレードオフ型の医療スキャン装置として語られていた。
DJレン：
第二に、これは単なる変わり種ガジェットではなく、
AI企業が物理世界のセンシングと医療ハードウェアに入っていく象徴として注目された。
ただし、規制、再構成品質、ユースケース、フォームファクター、コスト実態など、重要な未解決点は多い。
DJミオ：
第三に、モデル・研究側では、
GLM-5.2がopen-weightsの存在感を大きく高めた。
ただし“open”と“local”は同義ではなく、巨大モデルの実運用には依然として厳しいハードウェア制約がある。
DJレン：
第四に、推論最適化やエージェント設計では、
WebGPU、ROCm、KV cache量子化、再生可能な状態機械、検証器付きエージェントなど、
性能そのものよりシステム設計で差がつく時代がより鮮明になっている。
DJミオ：
第五に、実務コミュニティでは、
Claude Codeによるセキュリティ発見、使用制限の運用ハック、CLIエージェント環境の優位など、
チャットUIの外側にある実務ノウハウがますます重要になっている。
DJレン：
そして最後に、AIをめぐる競争は、
モデル性能だけでなく、
- ハードウェアへの進出
- 推論基盤
- 人材獲得
- 政策圧力
- コミュニティ運用
までを含む、総力戦になってきている。
DJミオ：
今夜のMidnight AI Groove、いかがでしたか。
ひとつの医療スキャナーのニュースから、AIがソフトウェアの枠を超えて、現実世界の計測、制度、産業、そして社会実装の問題に入っていく姿が見えてきました。
DJレン：
画像を作るAIから、世界を測るAIへ。
でも測るとなると、精度、規制、責任、再現性が一気に重くなる。
そこがこれからの見どころだね。
DJミオ：
それではまた次回、深夜の知性とビートの交差点で。
お相手はDJミオと――
DJレン：
DJレンでした。
Midnight AI Groove, signing off.
SE：フェードアウトするシンセ、深夜ラジオのジングル
