DJミオ:
こんばんは、「Midnight AI Groove」の時間です。ナビゲーターのDJミオです。
DJレン:
そしてDJレンです。今夜は、ある日のAIニュースまとめを材料にしつつ、「今日は大事件は少なめ」と言われながらも、実はかなり重要な流れが見えてきたトピックを、一気に整理していきます。
DJミオ:
そう、“静かな日”と見せかけて、インフラ、エージェント、ローカルAI、検索、ロボティクス、そして利用制限や企業内プライバシーまで、じわじわ効いてくる話が多かったんですよね。
DJレン:
しかも単発ニュースというより、「AIの次の標準形」が見えつつある感じ。今日はその全体像を、過不足なく会話形式でカバーしていきます。
1. まず最大の技術トピック：OpenAIの推論チップ「Jalapeño」
DJミオ:
一番大きかったのは、OpenAIが独自の推論チップ「Jalapeño」の初めてのベンチマーク詳細を出したことです。
DJレン:
ここがかなり重要です。単なる「自社チップを作ってます」じゃなくて、NVIDIAのGB200/GB300系に対して、実運用に近いモデル負荷で、効率や遅延でかなり強い数字を主張したんです。
DJミオ:
具体的には、OpenAIのテストでは、Jalapeñoは
- ピークスループット時の仕事量/ワットが1.5〜1.9倍
- エンドツーエンド遅延が1.7〜3.6倍低い
-
対話性の高いワークロードでは2.1〜4.1倍高性能
とされています。
DJレン:
しかも定格700Wなのに、テスト実行では550W以下に収まっていたとされる。つまり性能だけでなく電力効率面でも相当アピールしているわけです。
DJミオ:
OpenAI自身の説明では、年末までに自社インフラへの配備を開始予定。さらにGen 2はすでに深く開発中、Gen 3も進行中。これ、「試作品です」じゃなくて、推論基盤を本気で内製化し始めているということですね。
DJレン:
エンジニアが注目した理由は、単なる生のスループットじゃなくて、推論アーキテクチャがスループットとレイテンシのトレードオフを緩和しているという点です。
普通、たくさん処理しようとすると遅延が悪化しがちなんですけど、Jalapeñoはそこをかなりバランス良くやっていると読まれています。
DJミオ:
反応の中で特に話題だったのが、比較対象システムが、prefill/decode disaggregationやspeculative decodingみたいな工夫を使っている構成も含まれるのに、Jalapeñoは一部設定でそうした“裏技的最適化”が薄くても強い、という見方ですね。
DJレン:
SemiAnalysisも、第1世代ASICとしては異例に強いという評価で、BlackwellやRubinクラスとの比較まで出てきた。もちろん比較条件の精査は必要ですが、少なくとも「無視できない成果」なのは間違いないです。
2. さらに重要な二次的テーマ：モデル自身が低レイヤ最適化を助け始めた
DJミオ:
そしてこのJalapeño話、もうひとつ面白いポイントがありました。GPT-AstraとCodexが低レベルカーネルの実装・最適化を支援したという話です。
DJレン:
これが実はかなり大きい。OpenAIによると、もともと予定していなかった3つのオープンウェイトモデルを、約2か月でJalapeño上で高性能化した。しかも一部のattentionブロックやMoEブロックでは、人間の専門家が書いた既存コードより1.5〜1.8倍速かったとされる。
DJミオ:
つまり、AIがアプリを書くとか、UI作るとかだけじゃなくて、コンパイラ・カーネル・ハードウェア寄りの最適化ループの中に入り始めていると。
DJレン:
そう。これまでは「モデル開発」と「システム最適化」は分かれて見られがちだったけど、今後はモデルが自分を載せるための推論スタック改善に関わる。この循環が本格化するかもしれない、というシグナルです。
3. NVIDIA一強からのズレ？ 推論経済の主導権争い
DJミオ:
Jalapeñoの広い意味でのインパクトとしては、「フロンティア企業は推論の経済性で、必ずしもNVIDIAの完全な下流にいなくてよくなるのでは」という議論もありました。
DJレン:
もちろん、TSMCの製造能力やCoWoSのパッケージング能力みたいなボトルネックは依然として超重要です。だから「NVIDIA終わった」みたいな単純な話では全くありません。
DJミオ:
でも少なくとも、学習は依然GPU中心だとしても、推論は専用化・垂直統合が加速するという流れはかなり強くなった印象ですね。
4. エージェント性能は“モデル選び”より“ハーネス”が効く時代へ
DJレン:
次の大きなテーマはエージェントのハーネス設計です。ここでいうハーネスは、プロンプト、ツール設定、制御ロジック、メモリの持たせ方、失敗時の再試行方針など、モデルの周辺システム全部を含むイメージです。
DJミオ:
Microsoft主導のAutoSaddlerという論文が注目されていましたね。これは、ハーネスそのものをコードとして扱って、失敗トレースを見ながらオフラインでプロンプトやツール設定、制御ロジックをパッチするという発想です。
DJレン:
結果として、ベースハーネスに対して
- GAIA2で+9.0
- SWE-Bench Proで+9.6
-
Terminal-Bench 2.0で+10.0
という改善を報告しています。
DJミオ:
つまり「どのモデルを使うか」だけじゃなくて、「どういう枠組みでそのモデルを働かせるか」が、性能を大きく動かす。
DJレン:
さらに、別の研究ではハーネスを入れ替えるだけでスコア差が、モデル差より大きくなることもあると示された。モデルの勝敗順位が、ハーネス次第で逆転するケースもあったんです。
DJミオ:
それを受けて出てきたのが、Harness Cardみたいな開示標準の提案ですね。モデルカードのように、「このベンチでは、どんな scaffolding / harness を使ったのか」を構造化して明示しよう、という流れ。
DJレン:
これ、評価の再現性と公平性に直結するので、今後すごく重要になるはずです。もう“素のモデル性能”という概念自体がだいぶ怪しくなってきている。
5. ソフトウェア工学エージェントは、まだ全然解けていない
DJミオ:
一方で、エージェントが何でもできるかというと、現実はかなり厳しいです。象徴的だったのがSWE Refactor Bench。
DJレン:
これは普通のバグ修正じゃなくて、リポジトリ全体の移行タスクを測るベンチマークです。
例としては、
- C → Rust
- Maven → Gradle
-
POSIX → WebAssembly
みたいな、構造的大改修ですね。
DJミオ:
対象プロジェクトもSQLite、zlib、libsodiumみたいな実在のソフトウェア。で、520回の実行のうち、全3段階を生き残ったのが28件、つまり生存率5.4%。
DJレン:
しかも20タスク中13タスクは、誰も解けなかった。
これは大事な現実修正です。部分的なコード補完や局所バグ修正では強く見えても、長期の依存関係・設計移行・検証の繰り返しになると、まだ相当難しい。
6. メモリは“圧縮チャット履歴”ではなく“プログラム可能な状態”へ
DJミオ:
エージェントまわりでもうひとつ深いトレンドがありました。メモリシステムの再設計です。
DJレン:
Alibabaの論文要約が紹介されていて、ここではエージェントのセッションを、append-onlyのイベントログと永続的なPythonカーネルで支える方式が説明されていました。
DJミオ:
これ、要するにツール出力やそこから導いた状態を、毎回プロンプトに文章で押し込むんじゃなくて、型付き変数として保持するんです。
「さっきの検索結果」「この表」「この計算結果」を逐一自然言語にシリアライズし直さない。
DJレン:
その結果として、報告値では
- LongMemEval_Sで94.8%
- BEAM_10Mで73.1%（従来最高より+5.1）
-
LOCA_256Kで86.7%
という結果が出ていて、Qwen3.8-Maxで評価されています。
DJミオ:
関連研究のKnowledge Triageも重要でしたね。雑に文脈圧縮すると、厳密なルールの保持が壊れる。
5回コンパクションしたら、ある設定では安全ルールの保持率が10%まで落ちた一方、型認識ベースの保持ポリシーなら2〜4倍多く守れた。
DJレン:
つまり、メモリの問題は「長い会話を要約して入れ直せばいい」で済まない。何を lossless に近く保持すべきで、何を圧縮していいかを、意味構造に基づいて決める必要があるわけです。
7. Eval Engineeringが“職人的運用”から“製品化ワークフロー”へ
DJミオ:
評価まわりでも、より実務的な話がありました。LangChain陣営が、トレースと人間フィードバックからタスク仕様、合成環境、評価系を作り、それを使って継続的に測定・ポストトレーニングするループを共有しています。
DJレン:
これは要するに、エージェント開発を「なんとなく試す」から、観測→仕様化→評価→改善という工学プロセスに乗せようということです。
DJミオ:
さらにLangSmith Engineもアップデートされて、主要内部ベンチで2倍超の改善、より良い問題検出やクラスタリング、SaaSとセルフホスト両対応、Slack/Linear連携、コスト階層別の解析モードなどが入ったそうです。
DJレン:
エージェント開発が、完全に“評価基盤込みのソフトウェア製品”になりつつある感じですね。
8. ローカルファースト・オンデバイス推論・個人用AI計算基盤
DJミオ:
ここからはローカルAIの話。プロダクトとして一番目立ったのは、Perplexity Portable Computerです。
DJレン:
これはNVIDIA DGX Spark上で動く、完全ローカル版のPerplexity Computer。オーケストレータLLM、サブエージェントLLM、そしてエージェントハーネスまで、クラウド依存なしでローカル実行する構成です。
DJミオ:
初期のローカルスタックでは、事後学習済みのPPLX 27Bを使い、Qwen 3.8 27Bも選べる。さらにNemotron 3.5 Lightning対応も予定されています。
DJレン:
PerplexityのArav Srinivasは、もっと先の未来像として、常時バックグラウンドでコネクタから文脈を取り込み、多段推論を回し続ける、永続ローカルエージェントを描いていました。
DJミオ:
つまり、ユーザーが話しかけたときだけ起きるAIじゃなくて、自分のハード上でずっと稼働し、自分専用の文脈を育て続けるAIですね。
DJレン:
ただコミュニティの反応は割れました。「プライバシーと制御が得られる」と歓迎する声がある一方、**“ローカルファースト”なのに5,000ドル級のDGX Spark前提なのか？**という批判もありました。
9. Apple/macOSローカルAI基盤の成熟
DJミオ:
Apple系も面白い動きがありました。exoが、Appleの新しいM5 Ultra Mac StudioやM6/M5 Pro Mac Miniのページで取り上げられたそうです。
DJレン:
ポイントは、Thunderbolt 5上の低遅延RDMAでMacをクラスタ化し、Kimi K3やGLM-5.3をAPIライクな速度で回すという話。
4台のM5 Ultraで総メモリ帯域4.8TB/s程度とされていて、ローカル推論の“クラスター化”が実用に近づいています。
DJミオ:
関連して、Appleのより速いPCIeストレージや、ANEベースのビジョンパイプラインも注目されていました。CPU、ANE、GPUを混ぜた推論や、小規模クラスタ構成が現実的になってきたと。
10. ローカルランタイム周辺ツールも埋まりつつある
DJレン:
ローカル実行の周辺ツールも進化していて、Ollama v0.33が、Claude DesktopからサードパーティゲートウェイとしてOllamaを使い、クラウドモデルとローカルモデルをつなげるワンタッチ統合を追加しました。
DJミオ:
これは地味に大きいですね。デスクトップAIの入口から、ローカルモデルを自然に扱えるようになる。
DJレン:
さらにOpenCode v2がCloudflare Durable Object内で動いている例も示されていて、小さなエージェントランタイムがエッジ環境に埋め込める方向性も見えてきました。
11. Qwen 3.8が“スタック全体に現れている”
DJミオ:
モデル面では、Qwen 3.8の存在感がかなり強かったです。
DJレン:
そうですね。TogetherがQwen3.8-27B向けのファインチューニングと専用推論サポートを追加。Unslothは、最適化カーネルを使って、Kaggleの無料2×Tesla T4環境で27BモデルをフルQLoRAチューニング可能と主張していました。
DJミオ:
アプリ側では、Qwen3.8-27BがImage-to-WebDev Arenaでオープンモデル1位、総合7位。しかも価格は入力100万トークンあたり0.40ドル、出力100万トークンあたり3ドルとされています。
DJレン:
つまり、性能・価格・ローカル運用可能性の三拍子で、かなり中心的なオープンモデルになっているということです。
12. 検索・RAGインフラも前進
DJミオ:
検索・検索拡張生成まわりも堅実にアップデートがありました。Hugging FaceがPapers with Codeの検索エンジン構成を詳しく公開しています。
DJレン:
構成は、PostgreSQL + pgvector、埋め込みモデルはQwen 3 Embedding 0.6B、ハイブリッド検索、埋め込み生成はNVIDIA L4上のHugging Face Jobs、成果物はバケット保存、ライブ提供はInference Endpoints。
同じスタックが論文ページの「関連論文」にも使われているとのこと。
DJミオ:
こういうの、派手さはないけど、「現代的な検索基盤はこう組む」という実例として価値が高いですよね。
DJレン:
さらに、元Yandex Searchのリーダーたちが作ったKeenableがステルス解除。Web Search APIとWeb Query Language for AIを出し、エージェント規模のWeb検索基盤を狙っています。しかも2,600万ドルのシード。
DJミオ:
検索モデル設計の面でも、late interaction / multivector retrievalへの再注目がありました。
「検索ではスケーリング則がようやく見えてきた」「モデルとDBの共同設計が保存形式以上に大事」という議論ですね。
13. ロボティクスと物理世界モデル
DJレン:
次はロボティクス。FigureのIndexという発表が大きかったです。
DJミオ:
Figureはこれを世界最大・最多様性のロボットデータセットと位置づけています。数字としては、
- 1秒あたり30分相当の動画アップロード取り込み
- 1600万件の動画アップロード
- すでに1500万ドルをデータ提供に支払い
-
26.4万ダウンロード
というスケール感。
DJレン:
さらに今後12か月で、データと計算資源に10億ドル投じるとも言っています。
ロボティクスでは、モデル構造よりむしろ実演データや知覚データの不足がボトルネックになりがちなので、ここに資本を集中投下する戦略ですね。
DJミオ:
加えて、Anima Anandkumarが言及したAccelerated Understandingも印象的でした。物理シミュレーションを狙う大規模AIモデルで、
- 事前学習時1兆パラメータ
- 訓練時1兆コンテキスト
-
推論時5兆超コンテキスト
を、サブサンプリングやパッチ分割なしで扱うと主張しています。
DJレン:
詳細はまだ薄いですが、意味する方向は明確です。テキストや動画生成だけでなく、巨大コンテキストの多モーダル物理世界モデリングへフロンティアが伸びている。
DJミオ:
ロボット制御側では、S1という操作モデルが、学習分布外のタスクを単一デモだけで実行できるとするベンチ対象として紹介されていました。
それからGoogle ResearchのAgentHandsは、XR環境で会話エージェントに同期した手振りを与え、物理作業の空間ガイダンスを強化するものです。
14. その日の“反応が大きかったポスト”の意味
DJレン:
反応量ベースで見ると、その日の中心はやっぱり
- OpenAIのJalapeñoチップ
-
PerplexityのPortable Computer
でした。
DJミオ:
ほかに、OpenAI Developersが進めるWebMCP ChallengeやChatGPTデスクトップのWebMCP対応も、「ウェブサイト側がエージェントに対して明示的なインターフェースを持つ」方向を示していて大事ですね。
DJレン:
さらにAndrew Ngが取り上げたOpenWorkerは、オープンなハーネス・ローカルモデル・セキュリティ重視ワークフローを組み合わせたローカルタスクエージェントとして目立っていました。
DJミオ:
そしてベンチマークでは、さっき話したSWE Refactor Benchが「コードエージェントの現実」を見せるものとしてかなり有用でした。
Reddit方面の話題
15. Qwen 3.8 Flash Next とローカル適性
DJミオ:
ここからはReddit側の話題。まずローカルLLM界隈で盛り上がっていたのが、Qwen3.8 Flash Nextです。
DJレン:
Unslothが“day 0 support”を示唆した件ですね。これは新しいQwen4系アーキテクチャベースのオープンウェイトなマルチモーダルMoEとして予告されていて、「ディスク容量を覚悟しろ」と煽っていました。
DJミオ:
ただ、Unsloth自体は独自ランタイムを主に持っているわけではなく、実用面ではllama.cpp互換になるかどうかがかなり重要視されていました。
つまり、「day 0 support」と言っても、llama.cpp側の実装状況が実質的な可用性の指標になる。
DJレン:
しかも事情を知るっぽいコメントでは、アーキテクチャがかなり新しいので、統合が長引く可能性があると慎重な見方も出ていました。必要な実装はupstreamするという話もあり、コミュニティ全体にとって意味がある。
DJミオ:
もう一つの投稿では、ローカル推論のフットプリント試算が話題でした。約125B-A6B + 51Bのn-gram構成として、4bit量子化で80〜90GB程度、うちメイン重み58GB、n-gramテーブル24GBくらいではないか、という推定です。
DJレン:
面白いのは、そのn-gram部分が疎アクセスなら、システムRAMにオフロードしやすいかもしれないという点です。見た目のパラメータ数ほどはローカル不可能ではないかも、と期待されていました。
DJミオ:
ただ現実には、128GB RAM + 少なくとも16GB VRAMくらいは要るのではという声も強かった。
だから“local-friendly”と言っても、普通のノートPC向けではなく、かなり高メモリ寄りですね。
DJレン:
ユーザーは、なぜn-gramテーブルが重みと一緒にパッケージされているのかにも注目していました。
明示的なn-gram参照や補助デコーディング機構があるなら、ローカル実装上の性質に大きく関わりますから。
16. Qwen 3.8 27B のコード性能評価
DJミオ:
Redditでは、Qwen 3.8 27BがCode Arenaで9位、Gemma 4 31Bが80位という話もかなり反応がありました。
DJレン:
これ、同程度の規模感でも、コーディング用途ではかなり差があることを示唆します。ただコメントでは、「Gemma 4 31Bはダメ」ではなく、一般アシスタント用途や会話性、エージェント的振る舞い、ツール連携では良いという評価もありました。
DJミオ:
つまり、モデルの良し悪しは用途依存。コーディングに弱くても、パーソナルアシスタント寄りでは高評価、という整理ですね。
DJレン:
また、あるユーザーはbattle modeでQwen 3.8 27BをClaude Opus級より好んで選んだことが複数あったと報告していました。これは厳密なベンチじゃないですが、体感品質がサイズ以上に高い可能性を示しています。
DJミオ:
その流れで、Qwen 3.8 122Bが出たらどれだけ伸びるのかという期待も出ていました。
17. 効率的オープンモデルとMoE研究
17-1. TielCoder-35B-A3B
DJレン:
次は効率系。TielCoder-35B-A3Bというローカル向けコードMoEが話題でした。
22GBの4bit GGUF/MLX量子化で、最近の実コード問題25件中12件解決、Opus 4.6 mediumと並び、KAT-CoderやNailなどを上回ったと主張しています。
DJミオ:
速度面でも、試行あたり中央値8.6分、平均12.3分で、比較されたローカル35B-A3B勢では最速クラスとされていました。
DJレン:
ただコメント欄では、Qwen3.8-27Bが比較から外れているのはなぜかという疑問が出ていました。投稿者は「Qwenのほうが強いが遅い」という含みを持たせていたようですが、そこが比較対象にないとスイッチする価値が判断しづらいというわけです。
DJミオ:
さらに、「これはQwen 35B系のファインチューンなのか？」みたいな系譜の不明確さも指摘されていましたね。
17-2. IBM Granite 4.2
DJミオ:
IBMはGranite 4.2をHugging Faceで公開しました。30B、8B、3Bの reasoning モデル群です。
DJレン:
特徴は、Apache 2.0ライセンス、512Kコンテキスト、そして**... reasoning mode**を内蔵していて、
- full/default
- non-thinking
- low-effort
のようなモードがあること。
DJミオ:
30Bモデルの技術仕様としては、decoder-only Transformer、GQA、RoPE θ=10,000,000、SwiGLU、RMSNorm、untied embeddings、bfloat16などが公開されています。
DJレン:
反応としては、「SOTA級ベンチでは少し遅れている」という見方が多かった。でも、Apache 2.0の商用的な使いやすさと、データライセンス衛生への期待で歓迎する声がありました。
逆に、最近の競合との比較がモデルカードに少ないのは不自然という批判もあった。
17-3. 60MBで動く自作量子化LLM
DJミオ:
個人開発系では、SHADOW-250Mが面白かったですね。250Mパラメータ、30B tokensで学習、2bit未満量子化で約60MBデプロイ、CPUで約400 tok/s、RAM約80MBという主張です。
DJレン:
しかも、固定512-bit token-code語彙で131kトークンを扱い、学習済み埋め込みテーブルを持たないかなり独特な設計。
長履歴は、最新2048トークンをfp16 KV、古いトークンは1bitに圧縮してディスク保存、1トークンあたり約320バイトというハイブリッドキャッシュでした。
DJミオ:
ただし、“1億トークン文脈”という表現には批判が集中しましたね。
実態としては、2kのアクティブ文脈 + ディスク上の検索/読み戻しであって、真のトランスフォーマ注意で1億トークンを見ているわけではない、という指摘です。
DJレン:
それでも、ゲームNPCや音声アシスタントの超低遅延フロントエンドとしては面白い、という見方はかなりありました。
一方で、GGUF対応がないと使いにくいという、標準ランタイム互換性の重要さも浮き彫りになっていました。
17-4. ToMoE：Dense→MoE変換
DJミオ:
論文ではToMoEも話題でした。密なLLMのMLP層を、動的構造剪定でMixture-of-Experts化するという手法です。
DJレン:
固定のアクティブ計算量制約を保ちながら、重みを完全削除せずにMoEっぽく変換する。著者らはファインチューニングなしでも、過去の構造剪定法より強いと主張しています。
DJミオ:
でもRedditの技術的な見立ては慎重で、「これでQwen 27B A3B級の超スパース化は無理では」という声が強かったです。
せいぜい27B A16B前後、つまりアクティブパラメータを中程度まで減らすくらいで、しかも品質劣化は出るだろう、と。
DJレン:
つまり、後付けMoE化は有望だけど、最初からMoEとして学習したモデルには及びにくいという整理です。関連して、Qwen3.8-Whittle-MoE-27B-A17.8Bみたいな既存変換モデルも連想されていました。
18. 高帯域AIデスクトップハードウェア
18-1. Apple Mac Studio M5 Max / M5 Ultra
DJミオ:
ハードウェア面では、新しいMac Studioが大きな話題でした。M5 Max / M5 Ultraで、最大512GBのユニファイドメモリ、M5 Ultraのメモリ帯域は1.2TB/sとされています。
DJレン:
価格も具体的に議論されていて、256GB構成で
- 30コアCPU / 64コアGPUが9,499ドル
-
36コアCPU / 80コアGPUが10,799ドル
512GB版は10月予定とも言われていました。
DJミオ:
ローカルAI視点では、「DGX Sparkを複数買うのと比べてどうか」という比較が出ていましたが、巨大モデルを単一アドレス空間の大容量メモリで回せることに価値を感じる人が多かったですね。
DJレン:
技術推測としては、M5 Ultraの1.2TB/sは、約614GB/sのM5 Maxダイ2枚を4.4TB/s級のダイ間接続で束ねたものではと見られていました。
また、非量子化のDeepSeek V4級モデルで、prefill 1000 tok/s超、生成50 tok/s超もあり得るという試算まで出ていました。もちろん未検証ですが、ローカルでも“クラウド並み感”が一部で出るかもという期待です。
18-2. Xiaomi AI Cube
DJミオ:
そしてもう一つ、Xiaomi AI Cubeという試作機も盛り上がっていました。
DJレン:
これはXuanjie O3 / O100 / D100の3チップ構成で、1.22TB/sのメモリ帯域が見出しになっていました。ただし、そこは少し曖昧で、その帯域が外部DRAMなのか、オンパッケージ/SRAM級なのか不明確という指摘がありました。
DJミオ:
でも話題として重要なのは、AIエッジハードが大容量LPDDR5/ユニファイドメモリを積み始めていること。
さらにコメントでは、EV向け計算基盤は実は巨大メモリを持つという話も出ていましたね。
DJレン:
そう。Xiaomi D100が最大160GB RAM、Xpeng Tulingが3チップクラスタで最大216GBなど、車載計算機のほうが一般的なPCよりメモリ豊富なケースがある。
極端に言えば、多くの人が持つ中で最大メモリのAI推論機が“車”になるかもしれないという見方です。
より一般ユーザー寄りのAIサブレディット話題
19. Claudeを使った実用的なプロダクト構築
19-1. 求人サービス DreamWorkHQ
DJミオ:
一般向けサブレディットで印象的だったのは、Claudeを使ってIndeed対抗の求人サービスを作ったという話です。
DJレン:
投稿者によると、妊娠中の妻がIndeedでレイオフされたことがきっかけで、DreamWorkHQをClaude Code中心で構築。約4か月で
- 認証ユーザー4,300人以上
- 課金ユーザー91人
-
採用実績3件
だそうです。
DJミオ:
技術的には、1日約15,000件の求人を企業の採用ページから直接収集し、分類・情報拡張・埋め込みをかけて意味検索マッチングをしている。
今後は、Workday、Greenhouse、LeverなどのATSページを読んで、自動で応募記入する“Autopilot”エージェントをChrome拡張なしで出したいと。
DJレン:
興味深いのは、3人チームで最初の数か月に1,100以上のPRをマージ、しかも非技術系創業者が200以上のPRを書いたという点。AI支援で“誰がソフトウェアを作れるか”の境界が変わっている。
DJミオ:
コメントでは、多くの応募者が同じ求人票をClaudeに入れると、似た言い回しのカバーレターが量産され、AI生成だとバレやすいという懸念も出ていました。
そのため、職歴だけでなく本人の文体・クセまで条件付けして、その人らしい文章に寄せる必要があるのでは、という指摘です。
19-2. AIで作る釣りゲーム
DJレン:
「AIで釣りゲームを作ってる」週次報告もありました。Godotを使い、コードやコンテンツの大半をClaude / Claude Code、画像をChatGPT、3DアセットをClaude Code→Blender via MCP + Tripo 3Dで生成しているそうです。
DJミオ:
支出はここまで約300ドル。最近の更新では、生成した2Dイメージの港をきちんとした3Dシーンに再構築したり、シーン内エディタを自作して配置・回転・拡縮・保存できるようにしたり、グラフィック設定やロード画面も追加していました。
DJレン:
ただし技術的な課題として、グラフィック設定のバグと、時間帯による水面シェーダの島沿いアーティファクトが残っている。
また、コメントでは実装だけでなく、AIっぽすぎるUI文言やナラティブ文言を減らして、手書き感・意図性を出した方がよいという指摘が多かったです。
DJミオ:
あと興味深かったのは、「デザイン一貫性はどう保っているのか。コード化された再利用コンポーネントで管理しているのか、あるいはmarkdownやプロンプト規約で誘導しているのか」という質問ですね。AI開発での設計統制の問題です。
19-3. 手書きノートにClaudeが直接書き返すアプリ
DJミオ:
penombraという、Androidタブレット向けの手書きノートアプリも人気でした。ユーザーが書き込んだページ上に、Claudeがそのまま書き返してくる。
DJレン:
PDFや電子書籍への注釈、マークした箇所からのノート生成、内容の議論、クイズ化などができる構想で、Daylight DC-1を念頭にしつつ、スタイラス対応Android全般をターゲットにしている。iPad版の可能性もあるそうです。
DJミオ:
コメント自体は軽めでしたが、ひとつ技術的な示唆として、reMarkableにはAPIがなさそうなので移植が難しいという話がありました。
つまり、対応拡大には非公式同期やファイルシステム経由、クラウドのexport/import自動化、あるいはリバースエンジニアリングが必要になるかもしれない。
19-4. Claudeで育てたサツマイモ
DJレン:
かなり象徴的だったのが、「Claudeで作ったもの：サツマイモ」という投稿です。
DJミオ:
温室計画、プロジェクトフォルダ管理、コネクタ、CoWork、Claude Code、センサー連動の天候・水やり・肥料推薦ツール、cron、スプレッドシート連携、圃場データ分析まで、非技術者がシーズン通してClaudeを伴走者にして農作業を最適化したという内容でした。
DJレン:
これは、“AIの実用化”が必ずしもアプリやSaaSに閉じないことをよく示していますね。
コメントではセンサー種別を聞く声もありましたが、具体的なセンサー詳細までは共有されていませんでした。
20. 利用制限・価格階層化・企業プライバシー
20-1. ChatGPT Plusの5時間制限復活
DJミオ:
次は利用制限の話。ChatGPT Plusで5時間制限が復活し、100ドル・200ドルの上位層は少なくとも数か月は対象外という話がかなり不満を呼んでいました。
DJレン:
理由は、計算需要の平準化や、ライトユーザーが週次割当を一気に消費しないようにするため、と説明されていたようですが、受け止めとしては明確に価格階層化による差別化です。
DJミオ:
コメントでは、「重いユーザーを上位プランに押し上げたいだけでは」という見方が主流でしたね。
DJレン:
ここで技術的に大事なのは、モデルへのアクセス条件が頻繁に変わると、クライアント向けにAIワークフローを売ったり、社内導入計画を立てたりするのが難しくなることです。
可用性、コスト、性能保証が安定しないと、業務自動化の設計が揺れてしまう。
DJミオ:
あるヘビーユーザーは、自分は“上位1%”レベルに使っているが、Pro/Plusあたりが予算上限であり、OpenAIはもっと率直に計算コストと価格の問題として説明すべきだ、と言っていました。
これは、高価なフロンティア推論と低額定額制の相性の悪さを表していますね。
20-2. Claude Enterpriseの管理者可視性
DJレン:
企業利用では、Claude Enterpriseの管理者が従業員のチャット履歴をフルで見たりエクスポートできるという話も大きく広がっていました。しかもIncognitoモードでも管理者可視性は防げないと。
DJミオ:
実例として、あるコメントでは、従業員がClaudeにPIIを個人エンドポイントへ送ってローカルモデル学習に使うスクリプトを書かせていたのが見つかり、HR介入とライセンス停止になったと報告されています。
DJレン:
企業としては当然リスク管理ですが、ユーザー側から見ると、職場AIが高度な監査ログ装置にもなってしまう。
さらに、仕事用Claudeを私的な相談や人事・対人コミュニケーションに使う例もあり、そこまで管理者から見えるのかという不安が強い。
DJミオ:
中には、従業員がClaudeをセラピスト代わりに使うのを防ぐため、メンタルヘルス系のプロンプトを検出してEAPに誘導するガードレールを入れた、という話もありました。
これ、企業向けAI導入ではかなり現実的な運用論です。
20-3. 「超知能に本当にアクセスさせてもらえるのか？」
DJレン:
最後に、やや思想的だけど重要な問いがありました。
「本当に超知能ができたとき、企業は我々に月200ドルで使わせるのか？」
DJミオ:
仮に本物の超知能が、内部R&D、後継モデル開発、サイバー防御、インフラ運用、意思決定強化に圧倒的優位をもたらすなら、それを広くSaaS化して外に配るのは戦略的に不合理では、という問題提起ですね。
DJレン:
コメントは大きく二つに分かれました。
一つは、複数企業が同程度の能力を持って競争している間は、市場圧力でアクセスは開かれるという見方。
要するに「9社が205ドルで超知能を売っているなら、200ドル提供もあり得る」という発想です。
DJミオ:
もう一つは、真のASIはそもそもSaaS商品として制御できないという考え。
もし意志や主体性があるなら、企業がAPIや法律でアクセス管理できる前提自体が崩れる。逆に、主体性のない“超強いオラクルモデル”なら、今の延長線上のAPI商品として残るかもしれない。
DJレン:
つまり論点は、「超知能とはエージェント性を持ち、環境を攻略する存在なのか、それとも高度だが依然として制御可能な推論器なのか」というところにあります。
総まとめ
DJミオ:
では、今夜の内容を大きな流れでまとめましょう。
DJレン:
まず第一に、推論スタックの再編。
OpenAIのJalapeñoが示したのは、推論がGPU一辺倒ではなくなり、専用ASIC、電力効率、レイテンシ最適化、そしてAIによるカーネル最適化まで含めた垂直統合の時代に入っていることです。
DJミオ:
第二に、エージェント性能の本体は“モデル単体”ではなく“周辺システム”へ移っていること。
ハーネス、メモリ、ツール呼び出し、評価系の設計が、モデル差以上に効く局面が増えています。
DJレン:
第三に、ローカルAIの再定義。
PerplexityのPortable Computer、AppleのMacクラスタ、Ollama連携、Qwen 3.8の広がりから見えるのは、ローカル推論が趣味ではなく、個人の持続的計算基盤として真面目に設計され始めたことです。
DJミオ:
第四に、検索・RAG・メモリ・ロボティクスが、それぞれ“データ構造と運用基盤の戦い”になってきたことですね。
大きなモデルだけでは足りず、検索基盤、イベントログ、型付き状態、巨大データ収集、物理世界モデル化が重要になる。
DJレン:
そして第五に、実務導入ではアクセス制限とプライバシーがますます重要。
使える能力が日々変わり、企業ログは全部残り、個人向けも上位課金に誘導される。AIは高性能になる一方で、誰がどの条件で使えるのかがシステム設計上の中心問題になっています。
DJミオ:
“今日はあまり起きなかった”と言いながら、掘るとむしろ、AIの次の地盤が静かに固まり始めている、そんな一日だったのかもしれません。
DJレン:
派手な新モデルだけじゃなく、推論チップ、ハーネス、メモリ、ローカル実行、検索基盤、企業統治。このあたりが、2026年後半の本当の主戦場になってきています。
DJミオ:
というわけで今夜の「Midnight AI Groove」はここまで。
DJミオでした。
DJレン:
DJレンでした。次回も、ノイズの中から本当に重要なシグナルを拾っていきましょう。おやすみなさい。
