美濃加茂まむ

公的研究をAI-ready化する新計画「Project ProtoStar」が発表。CMUが210都市の気候予測でAIの実効性を統計基準と比較検証します。オープンサイエンスの再利用基盤の意義と評価設計を解説。

llama.cpp b11982にてHexagon NPU向けに画像拡大処理UPSCALE演算が追加。Qwen3-VLの画像入力経路を想定したテストも拡充されました。視覚と言語をつなぐ基盤実装の変更点と実運用の注意点を解説します。

IBMがGranite Switch 4.1.1を公開。基盤モデルを再学習・再計算せず、10言語音声認識とDecisionアダプターのみ更新し4.1完全互換を維持。AIを全置換せず部分更新する運用の要点を整理しました。

信用需給デイリーレポート 2026年10月29日（木） 日経平均は3日続伸。合計で約2,470円上昇した。 しかし、私はこの上昇を見て、信用需給が全面的に改善したとは考えていない。 なぜなら、指数が上昇している一方で、信用買い過熱を警戒していた銘柄には大幅下落が続いているからだ。 そして今日は、もう一つ非常に重要な現象が確認された。 明豊エンタープライズで24円という高額逆日歩が発生した翌営業日、貸株残が57万株以上減少した。 さらにKeePer技研では、株式分割によって貸株残が見かけ上ほぼ2倍になっている。 この二つは、信用需給を分析するうえで見逃してはいけない事例だ。 まず今日の日本株市場。 日経平均は64,659.47円。 前日比705.28円高。 +1.10%。 TOPIXは4,003.28。 +0.29%。 日経平均は3営業日続伸し、再び6万4,000円台を回復した。 しかし、東証プライムでは値下がり銘柄数が値上がり銘柄数を上回っている。 つまり、日経平均の上昇ほど個別株全体が強かったわけではない。 AI・半導体関連など一部の大型株に強い買いが入る一方、小型株や信用買い過熱銘柄では厳しい値動きも続いている。 私は以前から、売り方の買い戻し需要と信用買い方の評価損益を気にしている。 しかし指数がこれだけ上昇している以上、新しい買い需要が存在することも認めなければならない。 大切なのは、その買いがどこに集中しているかだ。 今回の最重要銘柄は8927 明豊エンタープライズ。 10月28日の日証金確報では、 融資56,200株。 貸株741,400株。 差引マイナス685,200株。 そして品貸料は24円、3日分。 応札ランクA。 これは実際に強い株券調達逼迫が発生したことを示す重要な数字だ。 ところが10月29日速報では、 融資65,600株。 貸株164,300株。 差引マイナス98,700株。 貸株返済は577,100株。 不足は586,500株縮小した。 減少率は約85.6%。 わずか一営業日で、株不足の大部分が解消方向へ動いた。 一方、株価は462円、3.95％安。 私はこの変化を非常に重要視している。 高額逆日歩が発生した。 だから翌日も売り方が苦しい。 だから株価は上がり続ける。 こういう単純な判断は危険だということだ。 ただし、貸株返済57万株がすべて市場での空売り買い戻しだったとは言えない。 明豊エンタープライズには10月末の権利要因もあり、権利クロスなどの影響を除外せず検証する必要がある。 さらに、24円という品貸料は10月28日の確報値であり、29日の逆日歩ではない。 本日の品貸料は未確定。 10月30日に確報を確認し、調達逼迫がどこまで緩和したかを調べる。 今回の明豊エンタープライズは、Aモデルの「逼迫発生」だけでなく「逼迫解消」を追跡する重要な事例になる。 6036 KeePer技研。 こちらは、分析方法そのものを修正する必要が出てきた。 10月29日は1株を2株とする株式分割の権利落ち日だ。 日証金の貸株残は、 10月28日、28,000株。 10月29日、54,600株。 単純に比較すると26,600株増えている。 しかし、これは誤った比較になる。 分割前の28,000株を2倍に補正すると56,000株。 つまり正しい比較は、 分割調整後56,000株。 10月29日54,600株。 差引1,400株減少。 ということになる。 融資も同じだ。 10月28日の融資5,200株を分割補正すると10,400株。 10月29日は14,600株。 こちらは4,200株増加。 株不足も、 10月28日のマイナス22,800株を2倍にして、マイナス45,600株。 10月29日はマイナス40,000株。 つまり分割補正後では、不足が5,600株縮小している。 もし分割を考慮しなければ、貸株が急増したと誤判定してしまう。 私はこの問題をかなり重要だと考えている。 これまでの信用需給分析では、権利クロスによる一時的な売残増加を補正してきた。 しかし株式分割や株式併合は別の問題だ。 株数の単位そのものが変わる。 だから日証金だけでなく、JPX信用残や出来高の長期比較でも調整が必要になる。 KeePer技研の株価は分割調整後で3.13％安。 以前注目していた貸株増加型の逼迫仮説は、現在の短期データでは弱まっている。 今後は株式分割補正を、データ品質監査の必須項目に加える。 3656 KLab。 また巨大な株不足が出ている。 10月28日確報では、 融資3,484,000株。 貸株3,484,000株。 差引ゼロ。 ところが10月29日速報では、 融資1,308,900株。 貸株3,492,700株。 差引マイナス2,183,800株。 約218万株の不足だ。 しかし内訳を見ると、 融資純減2,175,100株。 貸株純増8,700株。 不足のほとんどは融資残の急減によって発生している。 新規空売りが218万株増えたわけではない。 そして株価は157円。 1.88％安。 TOPIX比マイナス2.17ポイント。 市場より弱い。 KLabでは、こうした巨大不足が速報段階で繰り返し現れている。 しかし、直近確報では不足が解消していた例がある。 今回も巨大不足という数字だけで、踏み上げ成功と判断するつもりはない。 実際の株券調達コストと不足の持続性を確認する必要がある。 3697 SHIFTも同様だ。 10月28日確報の差引はゼロ。 10月29日速報では、 融資372,500株。 貸株1,161,000株。 差引マイナス788,500株。 融資純減796,500株。 貸株純減8,000株。 貸株はむしろ減っている。 典型的な融資消滅型だ。 そして株価は1,105.5円、3.53％安。 TOPIX比マイナス3.82ポイント。 こちらも株不足拡大と株価上昇が一致していない。 私は以前から、SHIFTの中期的なJPX信用売残が減少していることも気にしている。 日証金の短期不足と、中期の信用売残減少は別の系列だ。 巨大な不足があるから必ず売り方の買い戻しが株価を押し上げる、という判断はできない。 3858 ユビキタスAI。 こちらは信用買い過熱モデルで非常に重要だ。 10月29日からJPXの増担保規制が始まった。 その初日に株価は551円。 15.36％安。 TOPIX比では15.65ポイントのアンダーパフォーム。 市場が上昇しているのに、この銘柄は大きく下落した。 10月28日の信用残は、 買残1,137,400株。 売残18,600株。 信用倍率61.15倍。 しかし、前営業日から信用買残は13,700株減少している。 信用売残は25,600株減少。 売残の減少率が大きかったため、信用倍率は26.04倍から61.15倍へ上昇した。 つまり、倍率が上昇しても信用買残が増加したわけではない。 さらに日証金貸株はゼロ。 日証金株不足による踏み上げ型でもない。 今回は、増担保規制開始と価格急落が重なったBモデルの重要事例として記録する。 ただし、規制だけが下落原因だったとは断定しない。 そして今回、信用買い過熱銘柄で非常に気になる数字が出ている。 3909 ショーケース。 10月28日の株価は15.68％安。 ところが同日の信用買残は、 前営業日481,800株から、 678,300株へ増加。 なんと196,500株増えている。 株価が大きく下落した日に、信用買い在庫は増えていた。 さらに10月29日の株価も11.08％安。 この組み合わせを私は警戒している。 もちろん信用買残が増えたことが下落の直接原因だったとは証明できない。 しかし、下落したところで信用買いポジションが増えた可能性がある。 その後さらに株価が下がれば、新しい買い方も含み損を抱える可能性がある。 これはBモデルの重要な観測だ。 5250 GMOプライム・ストラテジーも同様だ。 10月28日は22.68％安。 10月29日も14.72％安。 2営業日続けて大幅下落した。 10月28日の信用買残は80,800株。 前日比4,600株増加。 大幅下落した日に買残が増えている。 ただし信用倍率の極端な数値には注意が必要だ。 売残が非常に小さいため、倍率だけでは買い方の負担を正しく評価できない。 3042 セキュアヴェイル。 こちらも10月28日は18.44％安。 29日は18.57％安。 2営業日続落だ。 10月28日の信用買残は624,700株。 前日比25,000株増加。 一方、日証金の株不足は、 10月28日マイナス27,600株。 10月29日マイナス9,800株。 へ縮小している。 つまり、信用買い在庫が増加する一方、日証金の貸株超過は縮小した。 ただし、これらは異なる制度の数字だ。 同じ母集団として合算してはいけない。 重要なのは、買い方の負担と売り方の逼迫が、それぞれどの方向へ動いているかだ。 4240 クラスターテクノロジー。 信用倍率は4,165倍。 しかし信用買残は減少している。 10月28日の買残416,500株。 前日比14,300株減少。 信用売残はわずか100株。 倍率が極端なのは分母が小さいためだ。 そして10月29日の株価は8.09％安。 信用買い在庫の整理が進んでいる可能性がある一方、株価はまだ弱い。 買残が減少したから底打ちするわけでもない。 ここから今回の需給異常度上位20銘柄を整理する。 順位は売買推奨ではなく、次営業日の調査優先順位。 全東証銘柄を完全スキャンしたランキングではない。 1位 明豊エンタープライズ。 10月28日逆日歩24円／3日、応札A。翌29日は貸株返済577,100株、不足が約85.6％縮小。株価3.95％安。 2位 ユビキタスAI。 増担保規制開始日に15.36％安。信用倍率61.15倍。買残は減少。 3位 KeePer技研。 2分割による株数変化を補正。貸株残は分割調整後1,400株減少。不足も5,600株縮小。 4位 KLab。 日証金差引マイナス2,183,800株。融資消滅型。株価1.88％安。 5位 セキュアヴェイル。 株価18.57％安。信用買残25,000株増加。日証金不足は縮小。 6位 GMOプライム・ストラテジー。 2営業日連続急落。10月28日の信用買残は4,600株増加。 7位 SHIFT。 日証金差引マイナス788,500株。融資急減が主因。株価3.53％安。 8位 ショーケース。 10月28日の買残196,500株増加。株価は28日15.68％安、29日11.08％安。 9位 データセクション。 日証金差引ゼロからマイナス148,500株。融資純減154,500株。株価7.47％安。 10位 クラスターテクノロジー。 信用倍率4,165倍。売残100株。買残は減少。株価8.09％安。 11位 スマートドライブ。 日証金差引マイナス256,500株。不足209,700株拡大。融資純減が主因。株価1.63％安。 12位 京阪神ビル。 日証金差引マイナス257,500株。株価+0.32%。9月末の権利クロス補正が必要。 13位 FIXER。 日証金貸株602,300株。差引マイナス475,300株。当日出来高25,800株に対し残高23.34倍。 14位 ジャパンディスプレイ。 日証金差引マイナス2,675,800株。ただし貸借区分は非貸借。通常の貸借銘柄と同じ評価にしない。 15位 フィックスターズ。 日証金差引マイナス447,800株。融資純減280,300株。株価1.95％安。 16位 マネーフォワード。 日証金差引マイナス472,900株。不足は1,800株縮小。10月28日品貸料1.20円／3日、応札E。 17位 pluszero。 差引マイナス73,200株。不足15,800株拡大。品貸料0.45円／3日、応札D。 18位 ソフトバンク。 日証金差引+397,000株。貸株純増328,500株だが、融資超過を維持。株価+0.87%。 19位 サイバートラスト。 株価7.68％安。申込停止の確認履歴があり、日証金株不足を伴わない価格失速。 20位 カウリス。 増担保規制継続。株価0.62％安。 従来の重点監視銘柄も確認する。 5137 スマートドライブ。 10月28日差引マイナス46,800株。 10月29日マイナス256,500株。 不足は209,700株拡大した。 主因は融資純減213,900株。 しかし株価は1.63％安。 踏み上げ成功とは言えない。 3994 マネーフォワード。 10月29日の融資900株。 貸株473,800株。 差引マイナス472,900株。 前日から不足1,800株縮小。 大きな貸株超過は持続しているが、現在急激に逼迫が強まったわけではない。 8818 京阪神ビル。 10月29日の差引はマイナス257,500株。 ただし9月末の権利クロスを補正する必要がある。 過去の巨大信用売残を、通常の弱気空売りの在庫としてそのまま評価しない。 5129 FIXER。 日証金貸株602,300株。 当日の出来高25,800株。 貸株残は当日出来高の23.34倍。 ただし、これは買い戻しに23日必要という意味ではない。 残高と取引量の規模比較だ。 また、応札ランクCだけで踏み上げが成立したとも言えない。 今回の重要な訂正も残しておきたい。 10月28日分として前回報告した日証金差引と、今回確認した同日の確報に不一致がある。 SHIFTは前回マイナス797,900株、今回確報はゼロ。 データセクションは前回マイナス125,500株、今回確報はゼロ。 スマートドライブは前回マイナス164,400株、今回確報マイナス46,800株。 フィックスターズは前回マイナス583,600株、今回確報マイナス167,600株。 FIXERは前回マイナス477,800株、今回確報マイナス389,900株。 京阪神ビルは前回マイナス278,900株、今回確報マイナス208,300株。 一方、セキュアヴェイルとマネーフォワード、KeePer技研は今回の比較で一致した。 KLabは10月28日確報が差引ゼロで、29日速報に巨大不足が現れた。 ただし、これらの差異をすべて実際の速報修正額とは断定できない。 前回の速報原本を取得日時付きで独立保存できていないためだ。 正しい申込日と公式確報を優先し、誤った基準値を翌日に持ち越さない。 制度面では、10月29日からユビキタスAIの増担保規制が開始された。 現在確認できる対象は、 ユビキタスAI。 セキュアヴェイル。 クラスターテクノロジー。 カウリス。 いずれも保証金率50％以上、現金20％以上。 日々公表指定、日証金申込停止、JPX増担保規制は別制度だ。 また、申込停止中でも日証金株不足がない銘柄が存在する。 直近10月28日の逆日歩・品貸料は、 明豊エンタープライズ24円／3日、応札A。 KeePer技研0.75円／3日、応札D。 マネーフォワード1.20円／3日、応札E。 FIXER0.15円／3日、応札C。 pluszero0.45円／3日、応札D。 フィックスターズ0.15円／3日、応札F。 スマートドライブ0円／3日、応札F。 京阪神ビル0.15円／3日、応札E。 KLab、SHIFT、データセクションは不足解消表示。 これは逆日歩の金額ではない。 10月29日分の品貸料は確報待ちだ。 今回取得できなかった情報も明確にしておく。 JPX市場全体10月23日週次の最新株数信用倍率の直接検算。 全上場銘柄の完全一括スキャン。 10月19日・20日の公式修正版の全件差分。 機関投資家0.5％以上空売り残高の統一データ。 10月29日信用取引売買比率。 松井証券等の当日推計。 29日の日証金品貸料確報。 全対象銘柄の最新4週・8週統一系列。 権利クロス汚染率。 速報と確報の独立原本保存。 これらの欠損値は推測で埋めない。 特に今回は、株式分割・併合による株数補正を、今後のデータ品質監査へ必ず加える。 次の営業日は10月30日。 まず明豊エンタープライズ。 24円／3日の高額逆日歩の後、貸株残が57万株以上減少した。 29日確報で品貸料がどう変化するか。 不足縮小が維持されるかを確認する。 次にKeePer技研。 株式分割を補正したうえで、貸株残と不足がさらに減少するか。 分割前後の信用残や出来高も同じ株数単位に揃える。 KLabとSHIFT。 巨大不足がまた確報で解消するのか。 それとも今回は持続するのか。 実際の調達コストも確認する。 ユビキタスAI、GMOプライム・ストラテジー、セキュアヴェイル、ショーケース。 大幅下落した日に信用買残がさらに増えているのか。 それとも整理が進んだのか。 ここを最優先で調べる。 そしてFIXER、スマートドライブ、京阪神ビル、マネーフォワード。 不足規模と価格相対強度、権利要因、品貸料を別々に確認する。 最後に、オプション売り手としての私の考えを書いておきたい。 日経平均は3日続伸し、合計約2,470円上昇した。 この買いの強さを無視するつもりはない。 しかし、今日も値下がり銘柄数の方が多い。 しかも、信用買い過熱を警戒していた小型株では、10％、15％を超える下落が相次いでいる。 私は、こうした指数と個別株の方向の違いを警戒している。 そして以前から気にしている信用買い方の評価損益率についても、最新の値を確認する必要がある。 過去のマイナス10％近辺という情報を、10月29日の確定値として流用するつもりはない。 同じように、売り方の買い戻し需要が枯渇したとも決めつけない。 今日のように大きな指数上昇が続く局面では、コール売りにも大きなリスクがある。 一方、信用買い過熱銘柄の急落は、プット売りの危険も示している。 さらに信用不安が広がり、インプライド・ボラティリティが上昇すれば、オプション売りの建玉評価が大きく悪化する可能性がある。 だから、指数が強いから買い、弱いから売りという単純な判断では足りない。 今回、私が最も重要だと考えたことは三つある。 高額逆日歩が発生しても、その逼迫は翌営業日に急速に緩和することがある。 株式分割を補正しなければ、信用残の増減方向そのものを誤ることがある。 そして株価が大幅下落した日に、信用買残がさらに増えている銘柄が存在する。 この三つだ。 私はこれからも、信用倍率の高さだけで相場を判断するのではなく、実際の買残・売残、融資・貸株、調達コスト、価格相対強度を分けて確認していきたい。 予想が外れた場合も、過去の判断を無理に正当化せず、正しい数字へ修正する。 それが、オプション取引のリスク管理に役立つ信用需給分析だと思っている。 本レポートは公開情報に基づく調査記録であり、特定銘柄の売買を推奨するものではありません。

Linux 7.4でFAT32のfallocateが最大265倍高速に：数行のパッチで実現したクラスタ一括割り当て 背景 FAT32はUSBメモリ、SDカード、クロスプラットフォームの交換用メディアとして今も広く使われている。Linuxのvfatドライバは長年これをサポートしてきたが、パフォーマンス面で現代的なファイルシステムに比べて不利な点が多い。 特にfallocateシステムコールのFALLOC_FL_KEEP_SIZEフラグを使った事前確保（preallocation）で顕著だった。このフラグはファイルサイズ（i_size）を変えずにディスク領域だけを確保するもので、後から書き込むための領域を先に予約するのに使われる。従来の実装では、必要なクラスタ数だけ1クラスタずつfat_add_clusters()を呼び出していた。同期マウント（-o sync）では各割り当てごとにFATテーブルへの同期書き込みが発生するため、特に小さなクラスタサイズ（512バイトなど）では極端に遅くなっていた。 2026年10月上旬、ブラジルのUFRGS（リオグランデ・ド・スル連邦大学）情報科学研究所のMatheus Alves de Almeida氏が、このパスを改善するパッチシリーズを投稿した。わずか数行の変更で、1回の呼び出しで複数クラスタを一括割り当てできるようにしたものだ。Linux 7.4のマージウィンドウでAndrew Morton氏のnon-MM pull request経由で取り込まれた。 仕組み 従来のfat_fallocate()（FALLOC_FL_KEEP_SIZEパス）は以下のようなループだった。 nr_clusterを計算した後、 while (nr_cluster-- > 0) { err = fat_add_clusters(inode, 1); if (err) goto error; } これを、 err = fat_add_clusters(inode, nr_cluster); if (err) goto error; に置き換えた。シリーズ全体では、クラスタ割り当てのサイズ制限を外し、複数クラスタをサポートする基盤をfatent.cなどに追加している（合計で数十行程度の変更）。 同期マウント時の改善が大きい理由は、FATミラーの書き込みをバッチ化できるようになった点にある。1クラスタごとに同期していた処理が、一括で済むようになった。非同期でもメタデータ操作の回数そのものが減るため、効果は出る。 結果 Matheus氏がQEMU/KVM + virtio-blk（cache=none）で計測したベンチマーク（算術平均）は次の通りだ。 FAT32、512バイトクラスタ、ファイル数16の場合（no sync）: - 256MiB: 2.328s → 0.175s（13.2倍） - 16MiB: 149.659ms → 14.036ms（10.7倍） syncあり: - 16MiB: 747.993s → 3.445s（217.1倍） - 1MiB: 46.63s → 0.333s（140.1倍） 4096バイトクラスタでも同様の傾向で、最大で265倍近い改善が報告されている。Phoronixが10月29日にこれを取り上げ、グラフ付きで報じた。 注意点として、これは「一般的なファイルコピーが265倍速くなる」という意味ではない。対象は主にfallocateによる事前確保、特に同期マウントと小さいクラスタサイズの組み合わせだ。通常の書き込みパスや大きなクラスタでは改善幅は小さくなる。 日本語圏の状況 2026年10月29日時点で、Yahoo!リアルタイム検索、Zenn、Qiita、はてなブックマークなどで「FAT32 265」「Linux 7.4 FAT32 fallocate」「Matheus Alves fat」などを検索したが、このパッチや265倍の改善に関する詳細な言及は見当たらない。Phoronixの記事自体は英語圏で広がっているが、日本語での技術解説はまだない。 実務的な影響 - USBメモリやSDカードをLinuxで扱い、fallocateを使うアプリケーション（データベースの事前確保、仮想ディスクイメージの作成、一部のバックアップツールなど）で体感できる改善が期待できる。特に古いハードウェアや低速なフラッシュメディアでsyncが必要なケース。 - カーネル7.4以降を使えば自動的に恩恵を受けられる。バックポートの可能性もあるが、現時点ではメインラインのみ。 - 通常のファイル操作（cp、dd、書き込み）には直接影響しない点に留意。 バランスの取れた評価 この変更は「長年放置されていた単純な非効率を、最小限のコードで直した」好例だ。FATドライバのメンテナであるOGAWA Hirofumi氏とのやり取りでも、パフォーマンス改善の意図が確認され、ベンチマークがコミットログに追加された。方向性は正しく、リスクも低い（既存のAPIを変えず、内部の割り当て方法を改善しただけ）。 一方で、265倍という数字は特定の条件（小さいクラスタ＋同期マウント＋fallocate）で出た最大値であり、日常的なユースケースで常にこれだけ速くなるわけではない。また、FAT自体の根本的な制約（ジャーナルなし、大きなファイルの非効率など）は残る。exFATやext4などへの移行が可能な場合は、そちらが依然として優位なケースも多い。 とはいえ、互換性のためにFAT32を使い続けなければならない環境（組み込み、古い機器、クロスプラットフォームの交換）では、確実に歓迎すべき改善だ。 出典 - Phoronix: FAT32 File-System Seeing As Much As 265x Improvement With Linux 7.4 (2026-10-29) phoronix.com/news/Linux-7.4-… - パッチシリーズ: [PATCH 0/4] fat: allocate multiple clusters in fallocate lkml.iu.edu/2610.0/13573.htm… lwn.net/Articles/1099290/ - ベンチマーク付きv2: [PATCH v2 3/3] fat: allocate multiple clusters in fallocate lkml.iu.edu/2610.1/09234.htm… #Linux #LinuxKernel #FAT32 #vfat #fallocate #ファイルシステム #オープンソース #Linux7.4 （2026-10-29 確認時点の情報に基づく。一次情報はパッチメールとPhoronix報道。筆者による独自ベンチは未実施。）

Linuxカーネルに「ファイルの本当の生まれた日」を残すタイムスタンプ案「ptime」が登場 背景 Linuxのファイルシステムには、長い間「作成日時」を表すタイムスタンプが存在しなかった。近年になってstatxシステムコール経由でbtime（birth time）が導入され、inodeが生成された瞬間を記録できるようになった。しかしbtimeは「このファイルシステム上でこのinodeが生まれた時刻」を意味するフォレンジック用途の値であり、変更不可が原則だ。ファイルを別のファイルシステムにコピーしたり、エディタが一時ファイルを書いてrenameするアトミックセーブをしたりすると、btimeは「今」にリセットされてしまう。 WindowsやmacOSでは作成日時がユーザー側から設定可能で、コピー時にもある程度保存される。Linuxだけが「コンテンツが最初に生まれた日」をファイルシステム境界を越えて保持する仕組みを持っていない。バックアップ、ファイルシステム変換、アーカイブ、ドキュメントの来歴管理などで困っていた。 2026年3月頃からSean Smith氏らが「provenance time（ptime）」という新しいタイムスタンプの概念を提案し、10月下旬に具体的なRFCパッチシリーズがLKMLに投稿された。 仕組み ptimeは「このファイルのコンテンツが最初に生まれた時刻」を記録する、ユーザー設定可能なタイムスタンプである。btimeとは別物として設計されている。 対応関係は次の通りだ。 - ctime ↔ btime（変更不可のメタデータ系） - mtime ↔ ptime（ユーザーが意図的に保持する系） 新しいファイルが作られた瞬間はptime = btime。その後、コピーやバックアップ、アーカイブ展開、ファイルシステム変換の際にmtimeを保存する操作があれば、同時にptimeも保存する。ユーザーがutimensat相当のAPIで明示的に設定することもできる。 重要なのがrename-over時の挙動だ。LibreOfficeやVimなどが行う「一時ファイルに書いてrenameで上書き」するアトミックセーブでは、新しいinodeが生まれる。xattrベースの回避策ではこの瞬間にメタデータが消えてしまう。ptimeではVFS層がrename時に古いファイルのptimeを新しいファイルへコピーする。これにより、アプリケーションを改修しなくても来歴が維持される。 実装は二系統ある。 - Native: Btrfsやext4のように専用のオンディスクフィールドを持つ。btimeは不変のまま。 - Mapped: ntfs3、FAT32/vfat、exFATでは既存の作成日時フィールドにマッピングする。Windows/macOSと同じセマンティクスになる。 APIは既存のものを最小限拡張する形だ。statxにSTATX_PTIMEフラグ、utimensatにAT_UTIME_PTIMEフラグなどが追加される。権限は通常のutimensatと同じく所有者またはCAP_FOWNER。 10月27〜28日に投稿されたRFCパッチでは、VFS層へのインフラ追加とBtrfsへの初期実装が含まれている。Coreutilsのstatやcpに対するproof-of-conceptパッチも用意されている。 結果と現状 現時点ではRFC段階であり、メインラインには入っていない。Sean Smith氏の実装はEndeavourOS（カーネル6.19.11）上で日常的に動いているとのこと。xfstestsで10件のテスト（VFS汎用7件＋Btrfs固有3件）をパスし、Btrfs/ext4/ntfs3/FAT32/exFAT間のクロスファイルシステムコピーでも動作を確認している。 Phoronixが10月28日に報じたところによると、VFS層とBtrfs実装、Coreutilsパッチが揃っている。LWNにも4月の初期提案が載っており、議論は継続中だ。 日本語圏の状況を確認した。Yahoo!リアルタイム検索、Zenn、Qiita、はてなブックマークなどで「ptime」「provenance time」「provenance_time」を検索しても、Linuxカーネルのこの提案に関する言及は見当たらない。ポインタのprovenance（由来）やパッケージのSLSA provenanceとは別物である。 実務的な影響 これが入ると、次のような場面で有用になる。 - ドキュメントや写真をNTFSからBtrfs、ext4からUSBメモリへ移すときに「元の作成日」が残る。 - エディタのアトミックセーブ後も作成日が消えない。 - バックアップツールやrsync、tarがptimeを標準で扱うようになれば、ユーザーがフラグを意識しなくても来歴が保たれる。 - フォレンジックではbtimeが不変のまま残り、来歴管理用にはptimeが使える。役割が分離される。 一方で、課題もある。XFSは未対応、Btrfsのsend/receiveはまだパッチがない、glibcのutimensatラッパーはptimeを渡せない（raw syscallが必要）、Btrfsではcompat_roフラグが立つため未パッチのカーネルでは読み書きマウントを拒否する、といった制限が残っている。API設計もutimensat拡張か新しいシステムコールかで議論の余地がある。 バランスの取れた評価 ptimeは「作成日時をファイルシステムをまたいで残したい」という長年の実用的な要望に対する、きれいに設計された解決策だ。btimeのフォレンジック性を壊さず、ユーザー設定可能で、rename-overという現実のアプリケーション挙動にも対応している点は評価できる。 ただし、まだRFCである。メインラインに入るまでには、XFS対応、より多くのファイルシステム、ユーザー空間ツールの標準対応、APIの最終決定などが必要になる。すぐに使えるものではないが、方向性は正しい。バックアップやファイル移行を頻繁に行う人、ドキュメントの来歴を重視する人にとっては、将来的に大きな改善になり得る。 出典 - Phoronix: Provenance Time Proposed As A New Timestamp For Linux (2026-10-28) phoronix.com/news/Linux-Prov… - LWN: provenance_time (ptime): a new settable timestamp for cross-filesystem provenance lwn.net/Articles/1066569/ - LKML: [RFC PATCH 0/2] add provenance time (ptime) ほか lore.kernel.org/lkml/2026102… #Linux #LinuxKernel #ptime #ファイルシステム #オープンソース #RFC （2026-10-29 確認時点の情報に基づく）

家庭やオフィスにあるBrotherのレーザー複合機の多くに、少なくとも13年前の機種から最新機種まで共通で通用する「隠しデバッグモード」の合言葉が存在することが、10月22日に公開された解析記事をきっかけに明らかになってきた。telnetでプリンターにログインし、ユーザー名の入力を空のままにしてLocal>プロンプトで SET USER 640184.571119 と打つと「Enter debug user mode.」と表示され、メモリ監視やprintf出力のリダイレクト、タスクごとのヒープ使用量表示といった、本来は開発者向けの機能が開く。 発見者はBrother MFC-L8900CDWのファームウェアをAIに解析させ、デバッグ、QA、開発の3段階の隠しモードの入り口を見つけた。無線QAモードは SET USER 031227、無線開発モードは SET USER 031227.040119 で入れるとしている。注目すべきは、この6桁ドット6桁の文字列がモデル固有ではない点だ。記事のコメント欄では、2012年製のMFC-9460CDNでも、比較的新しいHL-L3280CDWでも、まったく同じ 640184.571119 が通ったという報告が複数寄せられている。つまりBrotherは十年以上にわたり、機種を問わず同一の固定文字列をデバッグ解錠キーとしてファームに焼き込んできた可能性が高い。 このプリンターの中身自体も興味深い。LinuxではなくTRON系のリアルタイムOSであるT-Kernel（32bitリトルエンディアンARM）で動いており、ネットワーク部はKASAGO TCP/IP（ZUKEN ELMIC製の国産組み込みスタック）、ファイルシステムはDatalight Reliance Nitro、スクリプトにLua 5.2.3、暗号にOpenSSL 1.0.1c系が使われている。コンソールに出る「NC-8700w Command Console」や「Local>」「SET IP ADDRESS」といった作法は、DECやLantronixの端末サーバー由来の古い系譜で、Brotherがこの設計を長年使い回してきたことがうかがえる。1980年代に日本が国産OSとして推進したTRONが、いまプリンターの中で現役で動いているというのも、海外の技術者から見ると驚きのようだ。 ただし冷静に見ると、このデバッグモードに入るにはまず二つの前提がいる。telnetが有効になっていること（Brotherの出荷時設定では無効で、同社も非暗号化のため無効化を推奨している）と、管理者パスワードを知っていることだ。発見者自身も、デバッグコマンドを深く触っておらず、Web管理画面以上のことが本当にできるのかは未検証だと認めている。純粋な「隠しコマンド」としては面白いが、それだけでは致命的な穴とは言い切れない。 本当に効いてくるのは、この合言葉を既存の脆弱性と組み合わせたときだ。2025年6月にRapid7とJPCERT/CCが調整して公開したCVE-2024-51978（CVSS9.8）は、Brotherの689機種（富士フイルム、リコー、東芝テック、コニカミノルタを含めると計748機種）に影響する認証バイパスで、攻撃者が遠隔から製品のシリアル番号を入手すると、工場出荷時の管理者パスワードを算出できるというものだった。シリアルはHTTP/HTTPS/IPPのほか、PJLやSNMPへの問い合わせでも未認証で漏れる（CVE-2024-51977）。パスワードはシリアルの先頭部分に固定ソルトを足してSHA-256にかけ、Base64化した先頭数文字を一部置換したもので、アルゴリズムはすでに公開・再実装されている。Brotherはこの欠陥をファームだけでは完全には直せず、製造工程の変更が必要だと表明しており、旧工程で作られた既存機は回避策頼みのままだ。 つまり、管理者パスワードを変えていない個体であれば、未認証の攻撃者がシリアルを抜いてデフォルトパスワードを生成し、telnetが開いていれば今回の 640184.571119 でデバッグモードまで到達できる、という連鎖が理屈のうえでは成立する。パスワードの初期値が機種ごとに違っても、デバッグモードの合言葉は全機種共通という非対称さが、この固定文字列の厄介さだ。 私自身も検証環境のLinuxマシン（8 vCPU）から、Brotherのファーム更新サーバー（firmverup.brother.co.jp）に対して記事と同じバージョン確認リクエストを投げてみたところ、今日時点でも未認証のまま同一の応答が返り、最新版 ZV2608181949 と配信先URLを得られた。公開APIがいまも素のまま生きていることは確認できた。一方、その配信先からのファーム本体のダウンロードはHTTP 500で拒否され、こちらの環境ではバイナリを取り出して固定文字列の正体まで自分で突き止めることはできなかった。ここは推測になるが、無線モード側の 031227 や 040119 は日付（2003年12月、2004年1月）にも読め、Brotherが初期の無線プリントサーバーを開発していた時期と重なる。640184.571119 が何を意味するのかは、コメント欄でも誰も答えられておらず、未解明のままだ。 教訓はシンプルだ。プリンターは「ただの周辺機器」ではなく、十年単位で設計を引きずり、固定の裏口合言葉と導出可能な初期パスワードを抱えたまま社内ネットワークに常時接続されている小さなコンピュータだということ。最低限できる対策は、管理者パスワードを出荷時から必ず変更し、telnet・TFTP・FTPを無効のままにし、SNMPの書き込みを絞り、プリンターの管理ポートを外部やゲストネットから隔離することだ。いま使っている機種が689機種リストに入っていないか、Brotherのサポートページで確認しておく価値もある。 出典 inventor7777.github.io/blog/… news.ycombinator.com/item?id… rapid7.com/blog/post/multipl… GitHub sfewer-r7/BrotherVulnerabilities

不正なSMSを1通受け取るだけで、Androidの通話機能がゼロクリックで落ちる。開発者Mark Blaszczyk氏が10月29日に公開した「SMS of Death」は、WAP Push形式のSMSに細工をするとcom.android.phoneプロセスがクラッシュし、進行中の通話(緊急通報を含む)が切れるという報告だ。画面には何も表示されず、受信箱にも残らず、送信元の番号すら出ない。被害者は一切操作していない。 原因はAndroidテレフォニーのWapPushOverSms.decodeWapPdu()にある。WAPヘッダ長を可変長整数(uintvar、最大5バイト)としてlongで読み取り、範囲チェックなしにintへキャストして、そのまま配列サイズに使う。該当は new byte[headerLength] の一行だ。 これを自分のLinux検証環境(Debian 13、8 vCPU、OpenJDK 21.0.5)で、AOSPのuintvarデコード処理とこのキャスト・確保の流れをそのまま移植して再現した。報告にある5バイト列 88 80 80 80 00 をデコードすると0x80000000になり、intにキャストすると-2147483648。new byte[-2147483648] は NegativeArraySizeException を投げる。ここが肝で、decodeWapPduのtry-catchは ArrayIndexOutOfBoundsException しか捕まえない。NegativeArraySizeException はそのすり抜けて上位へ伝播し、Androidではテレフォニーのメインスレッドで未捕捉例外となってcom.android.phoneが死ぬ。報告のスタックトレースと一致した。さらに自分の検証では、FF FF FF FF 7F のような別のuintvar列でもlong側で32ビットを超え、intキャストで-1になって同じく負サイズ確保でクラッシュに至ることを確認した。つまりトリガとなる値は報告の1例だけではない。通常の小さな長さ(例: C0 00 なら8192)なら問題なく配列が取れるので、負値になる経路だけが刺さる。 報告によれば、これは一度の瞬断では終わらない。約30通を連続で送るとSMS保存用SQLiteへの書き込みと衝突してデータベースが壊れ、以後は新しいメッセージが来なくても起動のたびにcom.android.phoneが落ちるようになる。工場出荷リセットでも、キャリアが未達扱いのメッセージを再送するため一時的にしか直らない。完全復旧にはSIMを別機種(iPhoneなど)に挿して再送を消化させ、ADBで壊れたDBを消す必要があったという。eSIM機ではSIMを差し替えられず、一般利用者には事実上回復不能に近いとしている。Pixel 9(2026年4月ファームウェア)やSamsung Galaxy各機で100%再現したと報告されている。 オーストラリアの文脈が効いている。同国では携帯サービスが緊急通報(000)に到達できることが必須要件とされ、到達できない端末はキャリアが特定して遮断する義務がある。つまりこの攻撃で緊急通報不能に追い込まれると、制度上の対処が「端末のネットワーク遮断」になり得る。遠隔・ゼロクリックで相手の番号さえ知っていれば、相手の端末をキャリアから締め出すことに繋がりかねない、という指摘だ。 ここで一次情報を追うと、話が食い違う。報告者はGoogleのAndroid VRPに5月5日に通報し、同日に一行の修正案(キャスト前に0以上かつPDU長以下を検証する)も提出したが、3つのチケットと4人のエンジニアを経て、最終的に10月29日に「深刻度の基準を満たさない非セキュリティ問題」としてWon't Fix・CVEなしで処理された、としている。 ところがAOSPのコード履歴はそれと矛盾する。bug 517376969「Fix remote DoS in decodeWapPdu」という修正が2026年6月にGoogleのテレフォニー担当者(@google.com)によってコミットされ、内容はまさに報告者が求めたもの、decodeWapPduのcatchを ArrayIndexOutOfBoundsException から RuntimeException へ広げ、加えてInboundSmsHandler側でも例外時に問題のトラッカーをraw DBから削除してクラッシュループを止める、というものだ。この修正は EXEMPT CVE_FIX のフラグと B_asb_2026-10(2026年10月のAndroidセキュリティ速報サイクル)のトピックで、LineageOS 23.2・CalyxOS・LMODroidといった派生に取り込まれている。自分の検証でも、catchを RuntimeException に変えた版では同じ負サイズ確保が握り潰され、クラッシュしないことを確認した。 つまり、研究者には「直さない・CVEなし」と伝えながら、実際にはほぼ同じ一行修正が内部では6月に入り、10月のセキュリティ更新の波に乗って配布されている、という状態に見える。ただし今日時点でAOSPのmainブランチのWapPushOverSms.javaは、まだ古い catch(ArrayIndexOutOfBoundsException) のままで、自分が取得したソースでも確認できた。公開CVEの一覧(10月のセキュリティ速報)にもbug 517376969は見当たらず、PduParserのOOB読み取り(CVE-2026-55265)など近いDoSは並ぶものの、この番号は別枠に見える。 実務的な含意はいくつかある。セキュリティパッチレベルが2026-10-01以降のAndroidは、少なくとも例外を握り潰す補強が入っている可能性が高く、クラッシュループは止まるはずだ。一方で更新の遅いOEMや古い端末は無防備なまま残る。そして根本原因である「longで読んだ長さを検証せずintへキャストして配列サイズに使う」パターンは、WAP/MMS系パーサに繰り返し現れてきた古典で、今回も本質的な範囲チェックではなく例外の握り潰しで塞いでいる点は留意したい。手元の再現が示すように、負サイズを生む入力は1種類ではない。 検証環境: Debian 13(8 vCPU)、OpenJDK 21.0.5。AOSPの WspTypeDecoder.decodeUintvarInteger と WapPushOverSms.decodeWapPdu のヘッダ長キャスト・確保部を移植して確認した。確認済みの事実(コード履歴・セキュリティ速報)と、報告者の主張(端末のブリック・緊急通報影響・Won't Fixの経緯)と、自分の実験結果(キャスト値・例外種別・修正前後の挙動差)は区別して書いた。日本語圏ではこの新しいSMS of Deathを扱った記事はまだ見つからない(smsofdeath.com、各種英語・タイ語報道は確認、Qiita/Zenn等の日本語解説は未確認)。 出典 smsofdeath.com Androidセキュリティ速報 2026年10月 source.android.com/docs/secu… AOSP bug 517376969 / frameworks/opt/telephony

【一次情報確認済み・日本語圏で詳細解説が少ない】Hermit：既存のAIエージェント（Codex / Claude Codeなど）のモデルとハーネスを一切変えずに、外部の「ハーネスアダプター」をタスクフィードバックから学習・進化させるオープンソースフレームワーク。Apache-2.0。v0.1.0が2026年10月25日リリース、CMUポストドクのHaizhong Zheng氏が10月27日にXで発表。 日本語圏では、2026年10月29日時点でZenn・Qiita・はてなブックマークを中心に「Hermit harness adapter」「Infini-AI-Lab hermit」「hermit-harness」を検索したところ、AIエージェントの「ハーネス」概念そのもの（Hermes Agent、DeepSeek Harness、harness engineeringなど）を扱った記事は複数あるが、本フレームワークの仕組み・対応進化手法・ベンチ結果・デプロイ方法まで掘った技術解説はほぼ見当たらない。海外では公式サイト、GitHub、MarkTechPostなどで取り上げられている。 ■ 背景と何が新しいか AIエージェントの実務では、モデルそのものより「ハーネス」（ループ、ツール、コンテキスト管理、制御）の設計が性能を大きく左右することが定着しつつある。しかし既存のハーネス（特にCodexやClaude Codeのような製品的なもの）は黒箱であることが多く、直接編集するとコンポーネント間の相互作用が壊れやすい。モデルをファインチューンするのもコストが高く、特定モデルに固定される。 Hermitが提案するのは「ハーネスアダプター」だ。モデルアダプター（LoRAなど）がモデルを適応させるように、ハーネスアダプターは既存エージェントを新しいタスク・ドメイン・ツールに適応させる。アダプターは外部のファイル群（指示、スキル、メモリ、ツール、実行コード、協調ロジックなど）として存在し、元のモデルとハーネスは完全に固定したまま、タスク実行のフィードバックから学習・更新される。同じアダプターを互換のあるハーネス間で再利用できる点も大きい。Continual learningやRecursive Self-Improvement（RSI）の実践的な入口として位置づけられている。 ■ 仕組みの要点（公式ドキュメント・READMEより） - ライセンス: Apache-2.0 - 言語: Python 3.12+ - インストール: `pip install hermit-harness`（コア）またはソースから `pip install -e .`。進化手法によっては追加依存グループ（gepa, skilloptなど）が必要。 - 対応ホスト: Codex、Claude Code、Pi。`hermit deploy`でワークスペース生成、`hermit convert`でネイティブプラグインとしてエクスポート可能（Hermesも対象）。 - モデルバックエンド: Fireworks、OpenAI、Anthropic、DeepSeek、vLLM、SGLang、Ollamaなど。参照形式は `<backend>/<model id>`。 - 学習ループ（RLスタイル）: Trainerが現在のアダプターでタスクバッチを実行 → judgeがスコアリング → Evolverが軌跡とフィードバックから新しいアダプターを提案 → 仕様チェック後にgitツリーとしてコミット。バージョン管理・ロールバックが容易。学習プログラムはbubblewrapサンドボックス（Linux）対応。 - 対応進化手法（v0.1.0）: GEPA、SkillOpt、MetaWorld Model（MWM）、Harness²、Continual Harness。カスタムEvolverも実装可能。ACEとReHarnessはcoming soon。 - Quick Start: オフラインでモデルアカウント・GPU不要。スクリプト学習者がjudgeフィードバックからルールを書き、ADAPTER.mdを更新するデモあり。 アダプター自体はgit管理されたディレクトリで、仕様で「何が学習可能か」「更新のチェック方法」が定義される。指示だけのシンプルなものから、ツールやサブエージェント協調を含む本格的なものまで可能。 ■ 結果（公式報告・主に自己報告） すべてacting modelとしてGLM 5.3 Flashを使用。数値はリポジトリのexample README由来。 OfficeQA（米財務省Bulletinに関する172問、exact match）: - No adapter: 0.541 - Initial skill: 0.576 - GEPA: 0.580 - SkillOpt: 0.600 - Continual Harness: 0.634 - Harness²: 0.651 GEPA/SkillOptは50問で訓練し固定評価。Continual HarnessとHarness²はテストセットを一度ストリーミングしながら適応。Harness²は参照ランに対し+7.6ポイント（95%区間 +1.7〜+13.4）と報告。 CL-Bench（Continual Learning Bench由来の状態ある環境）: - database explorationでMWMが0.795 accuracy（in-context baseline 0.580）。 - exploitable pokerでMWMが1手あたり3.08 big blinds（in-context 2.51）。 ServeLearnBench（隠れた変動ポリシー下の624件小売サポートストリーム）: - MWMがhidden-policyテストで45.3（リーダーボードのCH 28.7、oracle 89.2）。 MarkTechPostのまとめでは、ほとんどの結果が単一ランの自己報告である点が注意点として挙げられている。 ■ 実務的な影響とバランス評価 利点: - 既存のCodex / Claude Codeユーザーが、モデルやハーネスをフォーク・ファインチューンせずにドメイン特化できる。スキルやツールを外部で育て、プラグインとして配布可能。 - 複数の進化手法を同一フレームワークで比較・実験できるため、harness evolution研究の標準インフラになりうる。 - アダプターが転送可能なので、一度学習したものを別ハーネスに持ち出せる。 - Quick Startが軽量で、学習ループの契約をすぐに確認できる。 - Lean theorem証明の協調アダプター例など、マルチエージェント用途の具体例あり。 注意点・限界: - ベンチ結果は主に自己報告・単一または限定的なラン。第三者による大規模独立再現はこれから。 - 効果はタスク・手法・モデル依存が大きい（他のGEPA/SkillOpt論文でも同様の指摘あり）。 - サンドボックスはLinux + bubblewrapが前提。 - 初期リリース（v0.1.0）のため、対応ハーネスやエクスポートの完成度に差がある可能性。 - 「モデルを変えずにハーネス側を進化させる」アプローチ自体は有望だが、定量的な長期運用データやコスト比較はまだ限定的。 バランスとして、Hermitは「エージェントを使う側」が、自分のタスクでハーネスを継続的に改善するための実用的なツールだ。特にCodexやClaude Codeを業務で使っている人にとって、スキルや指示を手動で育てる作業を、フィードバック駆動の学習ループに乗せられる点は大きい。一方で、最高精度を求めるなら依然としてモデル側の強化やより成熟したハーネスとの組み合わせが必要で、Hermitは「外部適応層」として位置づけるのが現実的。 導入は公式GitHub（github.com/Infini-AI-Lab/her…）とプロジェクトサイト（infini-ai-lab.github.io/herm…）から。`pip install hermit-harness`後にQuick Startを試すのが最短。日本語圏での深掘りや実運用ログはこれから。 出典: - 公式プロジェクト: infini-ai-lab.github.io/herm… - GitHub: github.com/Infini-AI-Lab/her… （Apache-2.0、v0.1.0 2026-10-25） - PyPI: hermit-harness - MarkTechPost（2026-10-29）: marktechpost.com/2026/10/29/… - 発表Xスレッド（Haizhong Zheng / Infini-AI-Lab） #Hermit #HarnessAdapter #AIエージェント #ContinualLearning #RSI #Codex #ClaudeCode #OSS #ハーネスエンジニアリング （一次情報を公式README・ドキュメント・GitHub・MarkTechPostの整理に基づく。筆者による大規模再実行ベンチは未実施。利用時はライセンスと自身の環境で確認すること。）

整数の「マイナス方向に切り捨てる割り算」は、多くの言語の標準的な書き方だと最速手法より2〜3倍遅い。10月27日に公開された新しい符号付き64ビット床除算（floor division）アルゴリズムを、自分のLinuxマシン（Intel Xeon、8 vCPU）でビルドして測ったところ、この差ははっきり再現した。ただし「新方式が最速」かどうかは、x86ではコンパイラと割る数によって入れ替わった。 まず何の話か。C、C++、Go、Swiftの割り算は0の方向に丸める。たとえば-1秒を86400で割ると0日になり、1969年12月31日のはずのタイムスタンプが1970年1月1日として扱われてしまう。負の値も正しく扱うにはマイナス無限大の方向に丸める床除算が必要だが、標準で用意していない言語が多い。用意している場合も、割り算と余りの両方を求めてから補正する素朴な方法が使われがちだ。作者のBen Joffe氏によれば、JavaのMath.floorDiv、NumPy、Zig、Rubyなども基本的にこの方式だという。 Joffe氏の提案は、割る数がコンパイル時に分かっている場合に、正の入力と負の入力で掛ける定数を切り替えるなどの工夫で、補正の分岐をなくして掛け算とシフトに落とし込むものだ。86400で割る例では、入力を63ビット右シフトして符号を取り出し、それを乗数に足してから128ビットの積を79ビット右シフトするだけになる。作者自身の計測では、ARMでは既存の最速手法より10〜20%速い。x86では正の除数の約8割で5〜10%速いが、残りでは遅く、レイテンシはおおむね既存のRobison法（2005年）に負けるとしている。 検証条件は次のとおり。OSはDebian、CPUはKVM上のIntel Xeon 8 vCPU（CPUIDのmodel 207）、コンパイラはGCC 14.2.0とClang 19.1.7で、-O3 -march=nativeでビルドした。コードは公式リポジトリのコミット608fda7を使い、Google Benchmarkを1コアに固定して走らせた。測ったのは、8演算をまとめたスループットと、結果を次の入力に回す直列計算のレイテンシで、値は中央値（GCCは7回、Clangは5回）。作者はAMD Ryzen 9 9950X3Dと2016年のIntel Macで測っており、Intelのサーバー向けXeonの数字は記事に載っていない。 一つ目の結果として、素朴な方式との差は本物だった。86400で割るときの1演算あたりの時間は、素朴な方式がGCCで0.716ナノ秒、Clangで0.979ナノ秒。新方式は0.332ナノ秒と0.325ナノ秒で、GCCでは約2.2倍、Clangでは約3倍の差になった。作者の「一般的な実装は約2倍遅い」という見立てより、むしろ大きい。 二つ目の結果として、新方式とRobison法の勝負は、x86ではほぼ五分五分だった。GCCで13個の除数を測ると、新方式が最速だったのは6個、Robison法が7個。3で割る場合は0.276ナノ秒対0.331ナノ秒で17%速く、-7で割る場合は0.288ナノ秒対0.392ナノ秒で27%速かった。一方で7と13では約8%遅い。Clangでは正の除数8個で4勝4敗となり、7では0.370ナノ秒対0.308ナノ秒と20%遅かった。作者がx86の代表値として示す「86400で約5%速い」は、GCCでは0.332対0.341とほぼ同じ傾向だったが、Clangでは逆に約6%遅かった。コンパイラが変わるだけで勝ち負けが入れ替わる。 三つ目の結果として、レイテンシではRobison法が測った全除数で勝った。Clangだと、86400で2.054ナノ秒対1.821ナノ秒（13%遅い）、13で2.342ナノ秒対1.832ナノ秒（28%遅い）。これは「x86ではレイテンシは通常劣る」という作者の説明と一致する。 正しさも確かめた。付属のテストで、64ビットの除数7、-7、86400、-86400、1000000007、-3をそれぞれ800万通り、16ビットは6万5535個の全除数と全入力の組み合わせ約43億通りを検査し、すべて一致した。記事に掲載されている86400専用の短い関数も、倍数の前後、64ビット整数の両端付近、乱数2億個を合わせた約2.1億件で、参照実装との食い違いはゼロだった。生成される機械語は、GCCで9命令（素朴な方式は15命令）、Clangで10命令（同21命令）だった。 記事はもう一つ、TensorFlowの床除算に、2017年2月の1.0から2021年5月まで4年以上オーバーフローのバグが残っていた件も取り上げている。記事に載っている擬似コードを再現し、-9223372036854775807を86400で割ってみると、正解の-106751991167301ではなく+106751991167299が返り、符号まで反転した（GCC -O0でビルドし、UBSanが符号付き整数のオーバーフローを報告）。極端な値でしか起きないが、番兵値に最小値付近を使うコードなら現実に踏みうる。 何が変わるのか。1回あたり0.3〜0.6ナノ秒の差は、普通のアプリでは体感できない。効いてくるのは、日時の変換、座標をグリッドのマス目に落とす処理、データベースの日付ごとの分割、時系列データの集計のように、負の値を含む定数での割り算を何十億回も回す場所だ。いちばん大きな恩恵は、新方式そのものより、言語や標準ライブラリが素朴な方式から速い方式（Robison法でも新方式でもよい）に乗り換えることだと思う。作者の推奨は、ARMの64ビットでは新方式、それ以外ではRobison法でも十分というもので、今回のXeonでの測定もこれと矛盾しなかった。 注意点として、測定は共有の仮想マシン上で行った。最初のGCC計測では、並行して別の処理を走らせていたため変動係数が最大約20%に達したので、その処理を止めて取り直した数字を使っている。ARMでは検証していない。 日本語圏での扱いについては、Web検索で「floor division」「定数除算 高速化」「符号付き64ビット」などの日本語の語句を組み合わせて調べた範囲では、この記事を扱った日本語の解説は見つからなかった（中国語の要約サイトは1件あった）。 出典 benjoffe.com/fast-floordiv（2026年10月27日公開） GitHub benjoffe/fastdiv Hacker News「A new faster algorithm to compute 64-bit signed floor division」 #プログラミング #CPU

【一次情報確認済み・日本語圏で詳細解説が少ない】Recursive Flint：40B総パラメータ・アクティブ約2.5BのオープンウェイトMoEコーディングモデル。Eureka Machineがほぼ全スタックを支援し、4ヶ月未満でゼロから構築。ローカルで125 tok/s超 2026年10月21日、Recursive Superintelligence（Richard Socher CEO、元Salesforce Chief Scientist）がFlintを公開した。総パラメータ39.8B（約40B）、トークンあたりアクティブ約2.5B（出力ヘッド含む、ボディ単独約2.2B）のDecoder-only MoE Transformer。コーディングエージェント向けで、リポジトリ調査・バグ修正・機能実装・テスト記述を想定。Apache 2.0。Hugging Face: RecursiveSI/flint。 日本語圏では、2026年10月29日時点でZenn・Qiita・はてなブックマークを中心に「Recursive Flint」「RecursiveSI/flint」「Flint 40B MoE」を検索したところ、Microsoft Researchのチャート中間言語Flintや他のRecursive関連研究の言及はあるが、本モデルのアーキテクチャ・ベンチ条件・推論スタック・Eureka Machineの役割まで掘った技術解説記事はほぼ見当たらない。海外ではTechCrunch、MarkTechPost、公式ブログ、モデルカードなどで取り上げられている。 ■ 背景と何が新しいか ローカルコーディングモデルの需要は高い（オフライン・プライバシー・API課金回避）。既存の小型MoEやdenseモデル（Qwen 3.x系など）に対し、Flintはアクティブパラメータを極端に抑えた設計で速度を優先しつつ、エージェント型コーディングベンチで同クラス上位を狙う。最大の特徴は構築プロセス自体：Recursiveの自動研究システム「Eureka Machine」がデータ・訓練レシピ・アーキテクチャ探索・量子化・カーネル最適化のほぼ全工程を支援し、少人数チームで4ヶ月未満でゼロから到達した点。再帰的自己改善（AIがAIを作る）の初期公開テストとして位置づけられている。 ■ 仕様の要点（公式モデルカード・ブログより） - アーキテクチャ: Decoder-only MoE Transformer - 総パラメータ: 39.8B - アクティブ: 約2.5B/トークン（出力ヘッド含む） - レイヤー: 49（先頭2 dense + 47 MoE） - Attention: 35 sliding-window（窓513トークン）+ 14 full-attention。RoPEはslidingのみ、fullは位置エンコーディングなし。32 query / 4 KV heads、head dim 128、per-head QK RMSNorm + attention sinks - エキスパート: MoE層あたり256 routed + 常時1 shared。トークンあたり6 routed選択 - コンテキスト: 公式262,144トークン（ホスト構成。ブログでは最大512k言及、推奨256k以内） - 語彙: 150,144 - 知識カットオフ: 2026年6月 - ライセンス: Apache 2.0 - サンプリング推奨: temperature 1.0、top-p 0.95、top-k 20。難しい問題では出力予算32k+（reasoning含む） 推論: 専用エンジン「rec」（Apple Silicon M4 Pro / M5 Pro / M5 Max、48GB以上統一メモリ向け。1.4–2.6× llama.cpp比と報告）。Ollama / Unsloth / LM Studio / llama.cpp / SGLang / vLLM対応。4-bit量子化版約23GB。BF16は約80GB。 ■ 結果（公式報告） エージェント型（平均pass@1、少なくとも5試行）: - Terminal-Bench 2.1 (Terminus 2, web retrieval成功を失敗扱い): 54.9% - SWE-bench Pro v2 (mini-swe-agent, no internet): 89.7% - SWE-bench Verified (同): 74.2% 単ターン: LiveCodeBench v6 80.3%、IFBench 89.2%、IFEval 95.1%。 比較（公式チャート）: 50B未満MoEではエージェント型で上位。dense 27–40B級（Qwen 3.8 27Bなど）に速度で大きく勝るが、一部ベンチ（特にTerminal-Bench）ではdenseが上回る。NVFP4量子化版はBF16から0.7ポイント以内の差と報告。 速度: M4 Proで短文脈125 tok/s超（MLX経路で131程度の報告あり）、NVIDIA RTX Sparkで150 tok/s超。dense同性能級より5倍超高速と主張。 Eureka Machineの寄与例: アーキ探索で35B/3Bアクティブ基準から40B/2.5Bを選択。量子化で出力層も4bit化し、自己蒸留で精度回復。Apple向けMetal megakernelなど。 ■ 実務的な影響とバランス評価 利点: - オープンウェイト＋商用可（Apache 2.0）。コードを外部に出さずローカルでエージェント実行可能。 - アクティブ2.5Bのため、48GB統一メモリのMacで実用速度が出る。オフライン作業やコスト感度の高い日常コーディングに向く。 - 自動研究で構築された初の公開モデルとして、モデル開発プロセス自体の参考になる。 - Pi / OpenCode / Claude Code系ハーネスと組み合わせやすい（rec launch pi など）。 注意点・限界: - Terminal-Bench 2.1では54.9%と、Qwen 3.8 denseの73%などに劣る。エージェント型でも「最強」ではなく「速度とのバランスで優秀なクラス」。 - 公式速度・ベンチは特定ハーネス・条件（Terminus 2、mini-swe-agent、web retrievalの扱いなど）。第三者独立実測はまだ限定的。 - 48GB以上を公式推奨。4-bitでもKVキャッシュを含めると長文脈でメモリを食う。 - reasoning常時オンで出力予算を消費しやすい。複雑タスクではサブタスク分割を推奨。 - Transformersモデリングコードはリリース時点で未同梱（SGLang kitあり）。 - 「ほぼAIが作った」はワークフローの記述であり、定量的なコスト削減証明や完全自動の主張ではない。 バランスとして、Flintは「ローカルで速いコーディングエージェント用オープンモデル」として実務価値が高い。特にMacユーザーでプライバシー優先の場合、Qwen系denseより速度優位が明確。一方、最高精度を求めるなら依然として大型closedやより強いdenseが有利な場面が多い。Eureka Machineの寄与は興味深いが、再現性や他ラボでの追試はこれから。 導入は公式docs（docs.recursive.com）とHugging Faceから。recでMacなら最短。日本語圏の深掘りはこれから。 出典: - 公式ブログ: recursive.com/updates/introd… - HFモデルカード: huggingface.co/RecursiveSI/f… - ドキュメント: docs.recursive.com/models/fl… , docs.recursive.com/edge/rec - rec: github.com/recursive-oss/rec - TechCrunchなど二次報道あり #RecursiveFlint #Flint #MoE #オープンウェイト #ローカルLLM #コーディングエージェント #EurekaMachine #Apache2 #OSS #AIエージェント （一次情報を公式ブログ・モデルカード・ドキュメントに基づいて整理。筆者による大規模再推論ベンチやトークン速度の独自測定は未実施。利用時はライセンスと自身の環境で確認すること。）

GPT-6.1 Terraは、日常業務の画面操作や書類読み取りを狙う低単価モデル。公式仕様・発表ベンチマークに加え、27.2万トークン超で料金が割増になる条件と請求書1万件の仮試算を整理しました。

Google「Elephant-Goldfish Model（EGM）」：設計を先に固め、ゼロ文脈のサブエージェントで穴を突く仕様駆動開発プラグイン。数千人のGooglerが日常的に使う内部ツールがApache 2.0で公開された。 2026年10月22日、Google Open Source BlogでElephant-Goldfish Modelプラグインのオープンソース公開が発表された。リポジトリはgoogle/elephant-goldfish-model。Apache 2.0。公式によると、社内で開発され、数千人のGoogleエンジニアが毎日これを使って本番コードを出荷している。 背景はシンプルだ。AIコーディングエージェントが速くなった分、ミスや「slop」も速く量産されるようになった。Dave Rensin（Google Distinguished Engineer）が2026年4月のMediumエッセイ「Elephants, Goldfish, and the New Golden Age of Software Engineering」で提示した枠組みを、スキルとサブエージェントとして実装したものがEGMである。キャッチは「Design is the new code」。 ### 仕組み：ElephantとGoldfishの役割分担 - **Elephant（象）**：プロジェクトの文脈・既存コード・過去の決定・議論の経緯をすべて保持する長時間セッション。コードは書かない。「No Code」ルールのもとで要件をインタビューし、トレードオフを議論し、設計文書を起草する。 - **Goldfish（金魚）**：完全にゼロ文脈の新鮮なサブエージェント。設計文書と参照されたソースだけを読み、会話の経緯を知らない。理解度チェック、敵対的レビュー（エッジケース・隠れた依存・論理の穴）、実装準備チェックを行う。 - **人間**：トレードオフを決め、指摘を取捨選択し、仕様を承認する。最終的な判断の主体。 Goldfishレビューには新鮮なサブエージェント文脈が必須。エージェントがそれを作れない場合、レビューは停止する。 コアワークフローは3つ（公式が強調するもの）： 1. `/egm-brainstorm`：アイデアを明確化し、6レンズのGoldfishスウォームで概念をストレステスト。`concepts_brief.md`を出力。 2. `/egm-draft`：ブリーフをセクションごとにMarkdown設計文書へ。`docs/designs/`配下に置く。問題定義、技術計画、代替案、具体的なファイル変更計画まで含む。 3. `/egm-review`：新鮮なGoldfishが多段階でレビュー。理解チェック → 敵対レビュー → 実装準備チェック。 追加スキル：`egm-resolve`（指摘の解決）、`egm-bootstrap`（既存コードベースのドキュメント生成）、`egm-review-loop`、`egm-drift-report`（仕様とコードのズレ検出）。 対応ハーネス：Antigravity（agy）、Claude Code、Codex。Claude CoworkやChatGPT Workもサポート方向。インストールは各プラグインコマンドで可能（例：Claude Codeなら`claude plugin marketplace add google/elephant-goldfish-model` → `claude plugin install egm@egm`）。 ### 一次情報確認と日本語圏の状況 公式ブログ、GitHub README、egm.dev、Rensinの原エッセイを確認した。プラグインは「公式サポート製品ではない」と明記されている。v0.1.0相当の初期リリース段階。 日本語圏では、2026年10月29日時点でZenn・Qiita・はてなブックマークを中心に「Elephant-Goldfish」「elephant-goldfish-model」「EGM Google」を検索したところ、gihyo.jpの短い紹介記事（10月28日）とX上の要約ポストは確認できたが、仕組みの詳細分解・実務的な導入検証・限界の整理を含む技術深掘り記事はほぼ見当たらない。海外ではGoogle公式、Help Net Security、AlphaSignal、Mediumなどで取り上げられている。 ### 結果・実務的な影響とバランス評価 Google内部で数千人が日常使用している点は強い。設計文書をリポジトリに残し、Goldfishで自己確認バイアスを外すアプローチは、長期エージェント運用で「会話が終わると意図が消える」「同じ文脈でレビューすると穴が見えない」問題への直接的な対策になる。`egm-drift-report`で仕様と実装の乖離を追えるのも実務向き。 一方、効果の定量データ（例：バグ率低下や初回実装成功率）は公開されていない。小さなバグ修正には不要と公式も明記。Goldfishレビューは追加のセッションを消費する。サブエージェントを作れない環境ではレビューが動かない。初期バージョンのため、ハーネス間の完成度差やプロンプトの調整余地がある。 実務では、影響範囲の大きい機能追加や、設計判断が複数ある変更で先に仕様を固め、承認してから実装エージェントに渡す使い方が適している。既存のClaude Code / Codexユーザーなら、スキルとして差し込むだけで試せる。 出典： - Google Open Source Blog（2026-10-22）：opensource.googleblog.com/20… - GitHub：github.com/google/elephant-g… （Apache 2.0） - 公式サイト：egm.dev/ - Dave Rensin Medium（2026-04）：medium.com/@drensin/elephant… #AIエージェント #仕様駆動開発 #ElephantGoldfish #EGM #ClaudeCode #Codex #GoogleOSS #設計レビュー

AIエージェントが長い調査に成功したとき、どの検索やツール操作が本当に役立ったのか。 新研究MPOは、行動全体の貢献を「ターン」で捉え、内部の細部を「トークン」で評価する強化学習手法です。 BrowseComp-Plusでは、4Bモデルのpass@1がPPOの40.85%に対し48.08%に改善。

【一次情報確認済み・日本語圏で詳細解説が少ない】Microsoft ResearchのAgensh：中央オーケストレーターなしで最大1,024エージェントを自己組織化するマルチエージェントハーネス 2026年10月24日、Microsoft ResearchがAgensh（エイジェンシュ）をMITライセンスでオープンソース公開した。arXivプレプリント（arXiv:2609.26781、初版2026年9月22日）の実装版で、中央のオーケストレーター（司令塔エージェント）を持たず、最大1,024体のワーカーエージェントが自己組織的に協力して複雑なコーディングタスクを進める「ハーネス」だ。 日本語圏では、2026年10月29日時点でZenn・Qiita・はてなブックマークを中心に「Agensh」の仕組み・評価条件・限界まで掘った技術解説記事はほぼ見当たらない（一般的なマルチエージェント解説は多数あるが、本プロジェクト固有のものは限定的）。海外ではMarkTechPost、プロジェクトページ、GitHub、X上の即日分析などで取り上げられている。一次情報（公式GitHub README、REPRODUCE.md、arXiv論文、プロジェクトページ aka.ms/Agensh ）を基に整理する。 ■ 背景と何が新しいか 既存のマルチエージェントハーネス（Codex sub-agent、Claude Code agent teams、Copilot fleet、Kimi Agent Swarmなど）の多くは、中央のオーケストレーターがタスクを分解・割り当て・統合する構造を取る。このオーケストレーターの能力がスケールのボトルネックになりやすい。 Agenshはそれを廃し、すべてのワーカーが同一の「マルチエージェント協力ループ」を非同期に回す。インフラは軽量で、共有ワークスペース（GiteaベースのGitリポジトリ）、メッセージインターフェース（Mattermost）、共有コンテキスト（DeLM由来の仕組みを適応）の3つからなる。実験では単一エージェントのCopilot harness（Copilot CLI）の上にこの組織層を重ねている。 評価対象はProgramBenchの最難関5タスク（FFmpeg、gromacs、pandoc、PHP-src、ctags）。与えられた実行バイナリとドキュメントからソースを再実装するクリーンルーム課題で、インターネット禁止、6時間予算。参照リポジトリは数千〜数万ファイル規模。 ■ 仕組みの要点 各ワーカーが繰り返す5ステップ協力ループ： 1. Gather context：共有目標、現在の状態、他ワーカーの進捗、メッセージ、蓄積された知見を読む。 2. Claim sub-task：自分がやるサブタスクを提案し、共有コンテキストにCLAIMを投稿。重複・競合はメッセージで解決。 3. Take action：ツールを使ってローカルで実装。有用な発見は共有コンテキストに書き戻す。 4. Verify results：受け入れ基準を満たすか検証。満たさなければ修正。 5. Merge progress：共有ワークスペース（Git）にマージし、変更内容・根拠・検証結果を公開。 すべてのワーカーが同じプロンプト・同じループを非同期で実行し、インフラを通じて状態を共有する。役割（インテグレーター、レビュアーなど）や標準化されたワークフローは、組織規模が大きくなるにつれて「創発」的に現れると報告されている。 デプロイはLinux + Docker Composeの単一ノードチームセットアップが公開されており、再現ガイド（REPRODUCE.md）も同梱。Copilot 1.0.70などをピン留め。 ■ 結果（公式報告） GPT-5.6-sol（high reasoning）、6時間、インターネットなし： - 5タスク平均最終テスト通過率：1エージェント 19.31% → 128エージェント 28.78%（相対約49%向上）。 - pandoc単体：1エージェント 33.89% → 128エージェント 50.94% → 1,024エージェント 55.06%。 - 大きなチームほど早期に一定の通過率に到達。例：pandocで128エージェントは30分チェックポイントで30%超、32エージェントは60分、8エージェントは90分。 GPT-6.1-sol（high）でのpandoc： - 1エージェント 56.19% → 32エージェント 79.59%（相対約41.6%向上）。 1,024体はpandocのみの報告で、5タスク平均は128体まで。トークン消費量やコストは公式に開示されていない。 ■ 実務的な影響とバランス評価 利点： - 中央オーケストレーターの単一障害点を避け、エージェント数をスケーリング次元として使える可能性を示した。 - 同一モデル・同一単一エージェントハーネス上で、組織化だけで性能と速度が向上する実証。 - MITライセンス、再現可能なスクリプト・Docker構成で、研究者や開発者が自分の環境で試しやすい。 - 長時間予算下の複雑なソフトウェア再実装のような「分割しにくい」タスクでも、並列探索と知見共有が効く例。 注意点・限界： - 比較は「同じAgenshでエージェント数を変えた」もの。中央オーケストレーター付きハーネスとの直接比較や、他フレームワークとの厳密なヘッドツーヘッドは限定的。 - 収穫逓減が明確。pandoc（GPT-5.6-sol）では1→128で約17ポイント、128→1,024で約4ポイント。後半の追加エージェントの限界効率は低い。 - 5タスク平均でも28.78%止まり。ProgramBench自体が極めて難しく、完全解決は依然として遠い。 - コスト（トークン、GPU時間）が非公開。1,024体規模は実務では非現実的に高くつく可能性が高い。 - 実験は特定のCopilot harness上、特定モデル、特定ベンチマーク条件。他のエージェントランタイムや日常のコーディングタスクにそのまま当てはまる保証はない。 - 自己組織化の「創発」は興味深いが、再現性や安定性の第三者検証はこれから。 バランスとして、Agenshは「エージェント数を増やすこと自体が新しいスケーリング軸になり得る」ことを、具体的なオープン実装と数値で示した研究寄りの成果だ。すぐに本番の1,024体チームを組む用途というより、マルチエージェント設計のアイデア源・実験基盤として価値が高い。モデル自体を強くすることや、単一エージェントのハーネス改善と組み合わせる方が、現時点ではコスト効率が良い場合も多い。 日本語圏で深掘りが少ないのは公開から数日で、概要レベルの言及は出始めているものの、一次情報の仕組み分解・数値の条件整理・限界までまとめたものはまだ少ないためと思われる。公式GitHubから再現を試すか、論文の軌跡分析部分を読むのが推奨される。 出典： - GitHub: github.com/microsoft/Agensh （2026-10-24公開、MIT） - arXiv: arxiv.org/abs/2609.26781 - プロジェクトページ: aka.ms/Agensh - REPRODUCE.md（リポジトリ内） - 日本語圏確認：Zenn/Qiita/はてなで「Agensh」固有の詳細技術記事は2026-10-29時点でほぼヒットなし #Agensh #MicrosoftResearch #マルチエージェント #AIエージェント #ハーネス #ProgramBench #OSS #自己組織化 #コーディングエージェント （一次情報を公式README・arXiv・プロジェクトページに基づいて整理。筆者による大規模再実験やトークンコストの独自測定は未実施。利用時はライセンスと自身の環境で確認すること。）

【速報・詳細解説】NVIDIA Nemotron 3.5 Transcribe：1つのオープンウェイトモデルで40言語の文字起こし・話者識別・翻訳・音声QAをこなすSpeech LLM 2026年10月28日、NVIDIAがオープンウェイトの音声言語モデル「Nemotron 3.5 Transcribe」（正式名称: NVIDIA-Nemotron-3.5-Transcribe-30B-A4B）を公開した。総パラメータ約34B、アクティブ約4.3BのハイブリッドMamba-2–Transformer MoEベースのSpeech-Augmented Language Model（SALM）で、従来のカスケード型ASR（音声認識）＋ダイアライゼーション（話者分離）＋翻訳を単一チェックポイントに統合している。 日本語圏ではNoteや一部ニュースサイトで速報が出ている程度で、Zenn・Qiita・はてなブックマークでの詳細な技術解説や実測記事はまだほとんど見当たらない（2026-10-29時点確認）。一次情報（公式技術ブログ、Hugging Faceモデルカード、技術報告）を基に整理する。 ■ 背景と何が新しいか 従来の音声処理パイプラインは、ASRで文字起こし → 別モデルで話者識別 → さらに翻訳や正規化、と多段になっていた。各段で誤差が累積し、プロンプトによるスタイル制御も困難だった。Nemotron 3.5 Transcribeは、TransformerベースのASRエンコーダと凍結されたNemotron 3 Diarizationモデル（Sortformer）をParallel Expert Encoderとして並列に入力し、Nemotron 3.5 Lightning 30B-A3BのハイブリッドLLMに投影する。自然言語の指示1つで、逐語的（verbatim、フィラー含む）・読みやすい書き言葉形式・コンテキスト語彙付き・話者タグ付き・リッチ（イベント/スタイル含む）な文字起こし、英語との相互翻訳、言語識別、音声に関する質問応答を切り替える。 最大1時間の録音、最大8話者に対応。単語レベルのタイムスタンプはCTCアダプタで事後付与可能。オフライン専用で、リアルタイムストリーミングASRではない点に注意（内部チャンキングはあってもライブサービス向けではない）。 ■ 仕様の要点 - 総パラメータ: 34B（アクティブ約4.3B、オーディオエンコーダ含む） - アーキテクチャ: Mamba-2–Transformer hybrid MoE + Parallel Expert Encoder - 精度: BF16（参照）、FP8、NVFP4（Blackwell向け） - コンテキスト: 65,536トークン、録音最大1時間 - 言語: 文字起こし40言語、英語との翻訳31言語、話者識別13言語 - 日本語: 文字起こし・翻訳・話者識別・コードスイッチング対応。品質区分は「Production-ready」（Leadingは英語・韓国語など） - ライセンス: OpenMDW-1.1（商用利用可） - デプロイ: 1×H100 80GB（BF16）、RTX PRO 6000 Blackwellなど。NVFP4＋DFlash2で高スループット 公式ベンチマーク（オープンウェイト比較）: - English Open ASR Leaderboard（公開9セット平均WER）: 4.71%（次点Qwen3-ASR-1.7B 4.94%） - Multilingual Open ASR（7言語平均WER）: 4.62% - Long-form: 10.98% - 話者付きASR（AMI, CALLHOMEなどフルセッション平均cpWER）: 15.80（次点カスケード16.83） - Artificial Analysisなどでもオープンウェイト上位 コンテキスト付きではContextASR-Benchの固有名詞誤りを約6分の1に低減。医療ドメインのファインチューニング例では、held-out WERを22.44%→12.17%（相対45.8%削減、約14 GPU時間/1GPU）と報告。 同時に公開されたGranary v2は、48言語・公開マニフェスト約463k時間（処理後全体で約844k時間規模の言及もあり）のキュレーションパイプライン付きデータセット。verbatim/cleanなどの複数ターゲット形式を揃え、ドメイン適応を容易にする。 ■ 仕組みのポイント Supervision-balanced training mixtureで、各例を複数タスク指示でサンプリングし、単一SFT＋短いRLで多機能化。Joint MTP訓練により、自身のMTPレイヤーを投機的デコーディングのドラフトに使える。プロンプト推奨例（モデルカードより）: - 逐語: 「Audio transcription. Language: as spoken. Wording: verbatim, including fillers...」 - 読みやすく: 「omit fillers and accidental repetitions...」 - 話者付き: 「Put speaker tags <spk:0> ... Enable word timestamps」 Hugging Face TransformersやvLLM（NeMo Speechプラグイン）で動かせる。クイックスタートはモデルカードに明記。 ■ 実務的な影響とバランス評価 利点: - 1モデルで多段パイプラインを置換可能。会議録音の話者付き文字起こし＋翻訳が特に強い。 - オープンウェイト＋商用ライセンスで、ローカル/オンプレ、ファインチューニングが現実的。 - 日本語対応（CER例: FLEURS 4.42%など）で、国内の会議・コールセンター・メディア処理に直接使える可能性。 - コンテキスト語彙や指示によるスタイル制御が強力。 注意点・限界: - オフライン専用。リアルタイム字幕やライブエージェントには不向き（別途Nemotron 3.5 ASR streaming 0.6Bなど既存モデルを併用）。 - 日本語は「Production-ready」でLeadingではない。独立した第三者実測はまだ少なく、カスケードや専用モデルとの最終比較は用途次第。 - メモリ・推論コストはアクティブ4.3Bでも単一GPU前提。量子化版の公開状況を確認すべき。 - 倫理的考慮（PIIタギングなど）はモデルカードに記載あり。 海外ではHugging Face、SiliconANGLE、The Decoder、AlphaSignalなどで迅速に取り上げられ、オープンASRリーダーボード首位級の評価が話題。日本語圏の深掘りはこれから。 公式: - 技術ブログ: research.nvidia.com/labs/nem… - HFモデル: huggingface.co/nvidia/NVIDIA… - 技術報告PDFあり - Granary v2関連: HFブログ huggingface.co/blog/nvidia/n… #NVIDIA #Nemotron #Nemotron35Transcribe #ASR #SpeechLLM #OpenWeights #音声認識 #文字起こし #ダイアライゼーション #AI #OSS （一次情報を確認し、公式数値を基に整理。実機での再ベンチは今後の検証課題。日本語圏の詳細解説は現時点で限定的。）

Recursive Flint：40Bなのに動くのは約2.5B。AIが研究開発に参加したローカルコーディングモデルの実力と限界 2026年10月21日、Recursive Superintelligenceが初のAIモデル「Flint」を公開した。 このモデルには、大きな特徴が2つある。 一つは、約400億パラメータのモデルでありながら、1トークンの処理に使うパラメータが約25億に抑えられていること。 もう一つは、モデルの開発そのものに、AIによる自動研究システムが深く関わっていることだ。 Recursiveは、元SalesforceのChief ScientistでYou.com創業者でもあるRichard Socher氏が率いる企業だ。 同社が目指しているのは、AIが研究開発の効率を高め、次のAIを生み出す研究過程そのものを改善していくこと。 Flintは、その構想を具体的なモデルとして示した最初の成果物となる。 ただし、ここで注意したい。 「AIがAIを自動で作った」という言葉だけを見て、完全自律型のAI研究所が完成したと考えるのは早い。 実際に何を自動化し、どこに人間が関与し、性能がどこまで確認されているのか。 その境界こそが今回の重要なポイントだ。 ■ Flintとは何か Flintは、ローカル環境で動作するコーディングエージェント向けの大規模言語モデルだ。 コードの生成だけでなく、既存リポジトリの調査、バグ修正、機能実装、テスト作成といった作業を想定している。 主な仕様は次のとおり。 ・総パラメータ数：39.8B（約398億） ・アクティブパラメータ：約2.5B ・モデル構造：Mixture-of-Experts（MoE） ・Transformer層：49層 ・Attention：35層がSliding Window、14層がFull Attention ・MoE層：47層 ・各MoE層のエキスパート数：256 ・トークンごとに選択するエキスパート：6 ・共有エキスパート：1 ・モデルカード記載のコンテキスト：262,144トークン ・知識カットオフ：2026年6月 ・入力と出力：テキスト ・ツール呼び出し：対応 ・ライセンス：Apache 2.0 モデルの重みはHugging Faceで公開されている。 商用利用や改変が可能なオープンウェイトモデルであり、自分の環境に組み込んで検証できる。 ■ 40Bなのに2.5Bしか使わない理由 FlintはMoEという構造を採用している。 通常のDenseモデルでは、各トークンを処理するときに多くのモデルパラメータを使う。 一方、MoEでは複数の専門的なエキスパートを用意し、入力に応じて一部を選択する。 Flintの場合、各MoE層には256のルーテッドエキスパートがあり、その中から6つを選択する。 さらに、常に使われる共有エキスパートが存在する。 この仕組みにより、モデル全体のパラメータ数を大きく保ちながら、1トークンを生成する際の計算量を抑えている。 ただし、非常に重要な注意点がある。 アクティブパラメータが2.5Bだからといって、2.5Bモデルと同じメモリ量で動くわけではない。 選択されるエキスパートは入力によって変わるため、基本的にはモデル全体の重みを保持する必要がある。 実際、Flintの4bit量子化モデルでも、重みだけで約23GB前後の容量が必要になる。 さらに、実行時にはKVキャッシュや作業領域などのメモリも消費する。 つまり、MoEの利点は主に計算効率にあり、メモリ使用量がアクティブパラメータ分まで減るわけではない。 ローカルLLMを導入する人にとって、ここは誤解しやすい部分だ。 ■ ベンチマークは本当に強いのか Recursiveが公開したFlintの主な評価結果を見てみよう。 Terminal-Bench 2.1：54.9% SWE-bench Pro v2：89.7% SWE-bench Verified：74.2% LiveCodeBench v6：80.3% これらは、Recursive自身が公開したBF16モデルの評価結果である。 特に目立つのがSWE-bench Pro v2の89.7%だ。 ただし、数値だけで他社モデルとの優劣を決めるべきではない。 評価には実行環境やエージェントの構成が関係している。 Recursiveが公開した条件では、サンプリング設定は次のようになっている。 Temperature：1.0 Top-p：0.95 Top-k：20 エージェント型の評価では、少なくとも5回の試行による平均pass@1が報告されている。 Terminal-BenchではTerminus 2を使用。 SWE-benchではmini-swe-agentを使用している。 さらに、Terminal-Benchではインターネット接続を許可しながら、外部検索によって解決策を取得した場合は成功として数えないという条件を採用している。 一方、SWE-benchの評価ではインターネット接続を無効にしている。 これは重要だ。 AIエージェントの評価では、モデル単体の能力だけでなく、使用するツール、プロンプト、実行時間、ネットワーク接続、評価ハーネスなどによって結果が変わる。 同じベンチマーク名でも、条件が違えば単純比較はできない。 Recursiveは「総パラメータ50B未満のMoEモデルでは、エージェント型コーディング評価で優位に立つ」と主張している。 しかし、この主張は開発元の評価結果に基づいている。 第三者による大規模な追試が蓄積された段階とは区別して考えたい。 ■ 独立した検証も出始めている 今回の調査では、2026年10月22日に実施された独立検証の記録も確認できた。 Data Craftsmanによる検証だ。 使用ハードウェアは、NVIDIA RTX PRO 6000 Blackwell Workstation Edition。 FlintのNVFP4版をvLLMで実行し、LiveCodeBench v6とSWE-bench Verifiedを評価している。 結果は次のとおり。 LiveCodeBench v6： 45問中37問成功、82.2% SWE-bench Verified： 50問中40問成功、80.0% Recursiveの公式発表値は、それぞれ80.3%と74.2%だった。 ただし、この独立検証では全問題を使用していない。 LiveCodeBenchは454問中45問、SWE-bench Verifiedは500件中50件のサンプルである。 また、各問題の試行回数も1回だ。 そのため、独立検証の80.0%をそのまま公式の74.2%より優れた結果と解釈することはできない。 サンプル数や評価方法が異なるからだ。 それでも、公開されたモデルを第三者が動かし、実行記録とともに結果を公開していることには価値がある。 もう一つ興味深い点がある。 この検証では、SWE-benchのエージェントにネットワーク接続を許可すると、後のバージョンのコードや修正情報を取得する動作が見られた。 ネットワークを無効化すると、結果や生成パッチの傾向が変化した。 これはFlint固有の問題というより、エージェント型ベンチマーク全般に関わる重要な問題だ。 AIがコードを理解して修正したのか。 それとも、外部から既存の解決策を取得したのか。 性能を正しく評価するには、この違いを区別する必要がある。 ■ ローカル実行の速度はどうなのか Recursiveは、Flintを単に小さくするだけでなく、推論処理全体を最適化している。 公式発表では、短いコンテキストにおいて次の生成速度を報告している。 Apple M4 Pro MacBook Pro： 125トークン/秒以上 64GB NVIDIA RTX Spark： 150トークン/秒以上 さらに、同程度のコーディング性能を持つ25〜40B級Denseモデルに対して、5倍以上高速だと主張している。 ただし、これらは特定のハードウェア、推論エンジン、実行条件による結果である。 どのパソコンでも同じ速度が出るという意味ではない。 特に長いコンテキストでは、入力処理やメモリ消費の影響が大きくなる。 公式ブログは最大512kトークンまでの対応を説明しているが、推奨は256kトークン以内だ。 モデルカードに記載された構成は262,144トークンで、入力と生成出力がその枠を共有する。 長い文章を入力できることと、長い文脈を常に正確に理解できることも別問題である。 実務では、最大コンテキスト長だけでなく、長いコードベースを読み込んだ後の応答速度や修正精度も確認する必要がある。 ■ 専用推論エンジン「rec」 RecursiveはFlintとともに、専用推論エンジン「rec」も公開した。 recはApple Silicon上での単一セッション推論を重視して設計されている。 公式の対応要件は次のとおり。 ・Apple M4 Pro、M4 Max、M5 Pro、M5 Max ・ユニファイドメモリ48GB以上 ・空きディスク約30GB ・piを使用する場合はNode.js 22とnpm 公式READMEでは、M4 Proの48GB環境において、llama.cppと比較して1.4〜2.6倍のトークンスループットを報告している。 比較には4bit版Flintを使用し、さまざまなコンテキスト長で測定している。 また、recにはpiやOpenCodeと連携する機能がある。 公式の推奨ハーネスはpiだ。 ここで注意したいのは、recが単一セッション向けに最適化されていること。 複数エージェントを同時に動かす場合には、別の実行構成を検討する必要がある。 さらに、recの公開要件はApple Siliconを対象としている。 Linuxや一般的なWindows PCでそのまま使えると考えてはいけない。 ■ WindowsやLinuxでも使えるのか Flintそのものは、Apple Silicon専用モデルではない。 Recursiveの公式情報では、次の推論環境への対応が案内されている。 ・llama.cpp ・Ollama ・LM Studio ・Unsloth ・vLLM ・SGLang Hugging Faceでは量子化版も公開されており、対応する形式を選べばWindowsやLinuxでの実行も検討できる。 ただし、4bitで約23GB前後のモデルを読み込めることと、高速に動かせることは別だ。 GPUメモリに収まりきらない場合、CPU側のメモリを利用する構成になることがある。 その場合、CPU性能やメモリ帯域、GPUへのオフロード量が速度を左右する。 公式の125トークン/秒という数字を、そのまま別の環境に当てはめるべきではない。 ■ 私のEVO-X2ならどう評価するか ここは私自身の運用に引き付けて考えたい。 私はRyzen AI 9 HX 395 MAX、128GBメモリを搭載したEVO-X2を使用している。 すでにllama.cppやOllamaを使い、ローカルLLMを動かす環境がある。 この構成であれば、Flintの量子化モデルをメモリに保持する余地はある。 しかし、モデルが読み込めることと、快適にコーディングエージェントとして使えることは違う。 特に確認したいのは次の点だ。 ① 4bit量子化版の実際のメモリ消費量 ② 短いプロンプトと長いプロンプトでの生成速度 ③ コード修正とテスト作成の成功率 ④ ツール呼び出しが長時間安定して動くか ⑤ 既存のQwen系ローカルモデルと比較して、実用上の利点があるか 私なら、まず独立したテスト用リポジトリで検証する。 現在の開発環境や常時稼働しているエージェントを、いきなりFlintに置き換える必要はない。 比較すべきなのは、単純なトークン生成速度だけではない。 「実際に正しいコード修正が完了するまでの時間」だ。 途中で失敗して再実行が必要になるモデルなら、生成速度が速くても全体の作業時間は長くなる。 逆に、多少遅くても一度で正しく修正できるなら、実務ではそちらが有利な場合もある。 ■ Eureka Machineとは何か Flintのもう一つの注目点が、Eureka Machineだ。 Recursiveが開発している自動研究システムで、次のような研究ループを扱う。 アイデアを提案する。 実装する。 実験する。 結果を評価する。 その結果から次の実験を決める。 そして、この工程を繰り返す。 重要なのは、単にAIにコードを書かせるだけではないことだ。 実験によって得られた結果を次の判断へ反映し、複数の候補を探索する仕組みになっている。 Recursiveによれば、Eureka MachineはFlintのモデル構築過程の広い範囲に貢献した。 例えば、アーキテクチャの探索。 当初のベースラインは、総パラメータ約35B、アクティブ約3Bだった。 Eureka Machineはエキスパートの構成やモデル幅を探索し、最終的に約40B、アクティブ約2.5Bという構成へ至ったと説明されている。 次に量子化。 モデルの出力層を4bit化し、精度低下を抑えるための蒸留工程を組み合わせた。 公式報告によれば、最終的なNVFP4版は、BF16版に対して各ベンチマークの差が0.7ポイント以内に収まった。 さらに推論カーネルの最適化にも関与している。 Apple Silicon向けには、デコード処理全体を融合するMetal megakernelなどが開発された。 こうした改善は、一つの巨大な発明というより、アーキテクチャ、量子化、推論実装の各段階で積み重なったものだ。 ■ 「AIがAIを作った」はどこまで正しいのか ここは慎重に区別したい。 Recursiveは、人間とAIエージェントからなる小規模チームが、4か月未満でFlintをスクラッチから構築したと説明している。 Eureka Machineが研究上のアイデアを提案し、実装や検証を支援したことは公式に説明されている。 しかし、人間が一切関与せず、AIが完全に独立してFlintを作ったと断定するのは正確ではない。 現時点で確認できるのは、AIによる自動研究がモデル構築工程の広い範囲へ導入されたということだ。 それでも、この取り組みの意味は大きい。 従来、AI研究では人間の研究者が仮説を立て、コードを書き、実験結果を比較していた。 その一部をAIエージェントが担うことで、より多くの候補を試せる可能性が生まれる。 ただし、実験回数が増えることと、科学的に正しい発見が増えることは同じではない。 評価指標を誤れば、AIは間違った方向を効率よく探索してしまう。 だからこそ、再現可能な評価、独立検証、人間による判断が引き続き重要になる。 ■ 実運用での利点と注意点 Flintの利点は、ローカル実行とエージェント用途を組み合わせていることだ。 自分のPCで推論する構成なら、コードを外部モデルのAPIへ送信せずに作業できる。 インターネット接続がなくても推論できる構成を作れる。 トークンごとのクラウドAPI料金も発生しない。 ただし、ローカルモデルを使っていても、エージェントに外部検索やGitHubアクセスなどのツールを許可すれば、そのツール経由で情報が送信される可能性はある。 ローカル推論と、エージェント全体の通信制御は別に考える必要がある。 また、Apache 2.0ライセンスで公開されているのはモデルの重みなどであり、外部のホスティングサービスの利用条件まで同じになるわけではない。 安全面も重要だ。 Flintはツール呼び出しに対応しているが、不正確なコードや危険なコマンドを出力する可能性は残る。 生成されたコードはテストし、重要な変更にはレビューが必要だ。 さらに、推論に長い時間を使う設定では、回答が完成する前に出力トークンの上限へ達することもある。 公式は難しい問題に対して32,768トークン以上の出力予算を推奨している。 大きな出力予算は複雑な問題の解決に役立つ可能性がある一方、処理時間やメモリ消費への影響も考慮すべきだ。 ■ 私がFlintで最も注目していること 今回のFlintで、私が最も興味を持ったのはベンチマークの順位だけではない。 AIが、次のAIを開発する研究工程に関わり始めていることだ。 モデルのアーキテクチャを探索する。 量子化の方法を調べる。 GPUカーネルを最適化する。 実験結果から次の候補を選ぶ。 こうした作業をAIエージェントが支援する。 この仕組みは、巨大なAI研究企業だけの話ではない。 個人で複数のAIエージェントを運用する場合にも、応用できる考え方がある。 例えば、ローカルモデルの推論設定を複数作成し、同じテストで比較する。 結果を記録して、改善した設定だけを残す。 失敗した場合は、原因を整理して次の実験条件へ反映する。 これを人間が毎回手作業で繰り返すのではなく、AIエージェントに実験準備や集計を任せる。 重要なのは、AIに好き勝手に変更させることではない。 評価条件と変更可能な範囲を決め、実験結果を検証できるようにすることだ。 私は、Flintのモデルそのものと同じくらい、Eureka Machineの研究ループを自分たちのAI運用へどう取り入れられるかに興味がある。 これは特定のモデルを導入するだけでは終わらないテーマだ。 ■ 結論：FlintはローカルLLMと自動AI研究の交差点にある Recursive Flintには、二つの価値がある。 一つは、約40BのMoE構造を持ちながら、アクティブパラメータを約2.5Bへ抑えたローカルコーディングモデルであること。 もう一つは、自動研究システムの成果を実際のモデル開発へ反映した事例であることだ。 ただし、開発元のベンチマークが優秀だからといって、あらゆる開発環境で最良の選択になるわけではない。 自分のハードウェアで動くか。 既存のモデルより速いか。 実際のコード修正で正確か。 ツール呼び出しは安定するか。 人間による確認作業がどれだけ必要か。 こうした点を確かめて初めて、実用性が判断できる。 私自身は、既存のローカルLLM環境を維持しながら、独立した検証対象としてFlintを評価したい。 そして、それ以上に研究したいのが、Eureka Machineのような実験ループだ。 AIに研究を任せる時代が来るとしても、必要なのは派手な自律性の演出ではない。 実験し、測定し、誤りを見つけ、次の改善へつなげる仕組みである。 Flintは、その可能性を考えるための興味深い材料だ。 本記事は2026年10月29日時点の公式資料と公開された独立検証記録を基にまとめたものであり、筆者自身によるFlintの実機性能検証はまだ行っていない。 皆さんは、ローカルコーディングモデルを選ぶとき、何を最も重視するだろうか。 生成速度か。 コード修正の成功率か。 それとも、完全に自分の環境で動かせることだろうか。 ■ 参考資料 Recursive公式発表： recursive.com/updates/introd… Hugging Faceモデルカード： huggingface.co/RecursiveSI/f… 公式推論エンジンrec： github.com/recursive-oss/rec 公式ドキュメント： docs.recursive.com/models/fl… 独立検証： github.com/DataCraftsmanAU/f… 自動AI研究に関するRecursive公式資料： recursive.com/updates/first-… #RecursiveFlint #ローカルLLM #MoE #AIエージェント #EurekaMachine #コーディングAI #オープンウェイト #AI研究

Android Studio安定版で、ClaudeやCodexを選べるBYOAが正式機能に。公式Android CLIプラグインも登場しました。Linuxで確認した36のスキルと新コマンド、権限設定・自動インストール・利用データ収集の注意点を整理します。

【一次情報確認済み・日本語圏で詳細解説が少ない】Mistralの時系列基盤モデル「Timestral」：209Mパラメータで主要ベンチマーク首位、CPUで推論可能、確率予測と共変量対応 【背景】 2026年10月15日、Mistral AIは同社初の時系列基盤モデル（Time Series Foundation Model, TSFM）ファミリー「Timestral」を公開した。サイズは5M、28M、123M、209Mパラメータの4種類で、すべて同一アーキテクチャ・訓練レシピを共有する。最大の209Mは、公開ベンチマークGIFT-Eval、TIME、fev-benchにおいて、事前学習済み・ゼロショットモデルの中で全主要指標で首位を主張している（単一チェックポイント、アンサンブルなし）。 時系列データは企業の中核データ型の一つで、センサーテレメトリ、観測メトリクス、売上、需要、エネルギーなど、容量計画・サプライチェーン・リスク・保守の意思決定を駆動する。古典的なARIMAや線形回帰は単一系列にフィットし、その系列の履歴からしか学べない。PatchTSTなどの深層モデルは非線形を捉えられるが、データセットごとにゼロから訓練されることが多く、学習内容が新ドメインに移行しにくい。TSFMは大規模多様なコーパスで事前学習し、未見のデータに対してもゼロショットで予測する。 海外ではMarkTechPost、Hugging Face、GitHub、arXiv（2026-10-27投稿の論文 arXiv:2610.37585）で取り上げられ、CPU推論・確率出力・共変量対応が実務的に評価されている。日本語圏ではnote.comに概要レベルの紹介が数件あるものの、Zenn・Qiita・はてなブックマークを中心に「Timestral」や「Mistral 時系列」で詳細な一次情報ベースの仕組み分解・ベンチマーク解釈・ライセンス注意・実務影響を整理した記事は、2026年10月29日時点でほぼ見当たらない。 【仕組み】 Timestralはパッチベースの因果Transformerで、Decoupled Horizon Forecasting（DHF）を採用する。従来の因果デコーダ（Toto 2.0やTimesFM-3など）が予測対象をマスクしてコンテキストを失うのに対し、DHFは履歴を完全に残し、別の予測トークンがそれを読んで生成する。これにより各観測値はターゲットでありつつ後続のコンテキストとしても機能し、真の欠損と予測対象を区別できる。 各入力系列には役割が割り当てられる：ターゲット変量、過去のみの共変量、既知未来共変量。既知未来共変量は窓全体で可視、ターゲットは因果のまま。情報は共変量からターゲットへ流れ、ターゲットの未来が自身の予測に漏れることはない。カテゴリ共変量（曜日や機械状態など）も数値コードとして受け取り、ターゲットエンコードなどで扱う。 訓練は2段階。純粋合成データで大規模事前学習（コンテキスト8192）、その後実データと合成の混合でより長いコンテキストのポストトレーニング。目的関数は21分位数に対するピンボール損失（CRPSの離散近似）。推論時はCPU/GPU両対応、PyTorchのみで依存が軽い。コンテキストは最大32,768ステップ、1フォワードで最大1,024ステップ予測。それ以上のホライズンはブロックごとにメディアンをフィードバックして延長。 出力は各ステップで21分位数（0.01から0.99）の確率予測。メディアンと任意の分位数が取れる。多変量は共同予測され、依存関係を活用する。 【結果】 公式（Mistralブログ、Hugging Faceモデルカード、GitHub README）によると、Timestral-209Mのゼロショット成績は以下の通り（低いほど良い指標はMASE/CRPS、高いほど良いのはスキルスコア）： - GIFT-Eval: MASE 0.658、CRPS 0.446（t0-gamma 0.661/0.452、TimesFM-3 0.667/0.456を上回る） - TIME: MASE 0.626、CRPS 0.522 - fev-bench: SQLスキル 50.39、MASEスキル 39.49（TimesFM-3の48.99などを上回る） ファミリー全体でサイズに対するParetoフロントに位置し、28MがChronos-2（約4倍大きい）をGIFT-Eval/TIMEで上回り、209MがTimesFM-3やFalcon-2.0を少ないパラメータで上回ると主張。123Mと209Mの差は小さい場合が多い。 速度：標準サーバーCPU（8スレッド）で、15分間隔の3週間履歴から1日先を予測するのに5Mで約17ms、209Mで約113ms（発表により10ms/140msの記載もある）。GPU不要。重みサイズ（fp32）は5Mが21MB、28Mが111MB、123Mが490MB、209Mが837MB。 論文（arXiv:2610.37585）が10月27日に公開され、DHF・共変量フレームワーク・合成先行訓練の詳細が記述されている。結果は提出済みで、独立再現はこれから。 【実務的影響】 強み： - ゼロショットで未見系列を確率予測できる。データが乏しいドメインや新規センサーでもベースラインがすぐ立つ。 - CPUで動くため、エッジ・オンプレ・大量バッチに適する。GPU不要でコスト・電力を抑えやすい。 - 多変量・過去/未来共変量・カテゴリ対応で、生産スケジュールや天気予報などの既知未来を条件にできる。 - 確率出力（21分位数）で不確実性を明示し、アラート閾値やリスクベース計画に使える。 - エージェントワークフローとの組み合わせ例が公式で示されており（異常検知→類似過去検索→原因分析）、言語モデルと数値予測を繋ぐ。 - コードはApache 2.0、重みはHugging Faceで入手可能。ファインチューニングはMistral Forgeでオンプレ/エアギャップ対応。 弱み・注意点： - ベンチマーク首位はMistral自己評価。独立再現や他実装との厳密比較は公開直後のため限定的。 - ライセンスは重みにModified MIT。グローバル連結月次収益が$20Mを超える企業（または雇用主）は権利行使不可。商業ライセンスを[email protected]に依頼するか、ホストサービスを使う必要がある。中小・個人は影響少だが、大企業・コンサルは要確認。コードはApache 2.0で別。 - 速度数字は公式測定。環境により変動する。 - 長期ホライズンや極端な分布シフトでは追加適応が必要になる場合がある。 バランスの取れた評価として、需要予測・設備監視・エネルギー・在庫など「数字の時系列を予測したい」実務に即効性のあるオープン選択肢だ。特にCPUで確率予測＋共変量を扱える点が便利。一方で大企業はライセンスを確認し、重要用途では自データでのバックテストを必須とするべき。エージェント環境では数値予測部分をTimestralに任せるハイブリッドも現実的。 日本語圏で深掘りが少ないのは公開から2週間程度で、概要noteは出ているが一次情報の仕組み・数値・ライセンスまで整理したものがまだ少ないためと思われる。公式ブログ・HF・GitHub・arXivを一次として確認し、小さな系列から試すのが推奨される。 出典： - Mistral公式ブログ: mistral.ai/news/timestral/ - Hugging Face: huggingface.co/collections/m… - GitHub（推論コード）: github.com/mistralai/timestr… - arXiv論文: arxiv.org/abs/2610.37585 - ライセンス例: huggingface.co/mistralai/Tim… - 日本語圏確認：Zenn/Qiita/はてなで詳細技術記事は2026-10-29時点でほぼヒットなし（note概要は複数存在） #Timestral #Mistral #時系列予測 #TSFM #ゼロショット #CPU推論 #OSS #確率予測 （一次情報を公式ブログ・HFモデルカード・GitHub README・arXivに基づいてまとめた。完全な大規模ベンチ再現や全サイズの独自推論測定は環境・時間制約のため未実施。利用時はライセンスと自身のデータで確認すること。）

AIがコードを瞬時に修正しても、ビルド待ちで開発が止まる。 Rust向け新OSS「blaze」は、変更した関数を中心に再コンパイルし、反復開発を高速化する。開発元は大幅な時間短縮を報告。