今日の収穫、3行で。

推進側は『判定専用にすることで爆速・爆安（あるベンチ記事は約2.8万リクエストで精度・速度・コストを検証したと報告）』と主張する。一方で懐疑的に見れば、これらの数値・比較はいずれも同日投稿の解説記事や提供元由来で、独立した再現はまだない。lobstersでは2048を解かせて手触りを試す検証も出ており、評価はこれから固まる段階。

Q. 普通のLLMと何が違う？
A. 自由記述を生成せず、定義済みの選択肢・真偽・数値に対する確信度だけを返す点。分類・判定タスクに絞ることで軽量・低コストを狙う設計だと説明されている。

Q. 既存の分類モデルやtabular foundation modelとの差は？
A. ユースケースは重なる。何を学習しているか・説明可能性がどうかはまだ論点で、記事群でも明確な答えは出ていない。

特筆すべきは出方そのもの。Jev関連の解説がZenn・Qiita・はてブ・lobstersに同日十数本、しかもZenn記事はほぼquality_score=50（エンゲージメント未計測）で一斉に並んだ。技術の当否とは別に、こうした『バースト』は宣伝的な波及の可能性も含めて割り引いて読む必要がある。

Q. CLAUDE.mdとAGENTS.mdは両方置ける？
A. Claude CodeはCLAUDE.mdが無い場合にAGENTS.mdへフォールバックする挙動。両方の優先順位や併用は/configのProject instructionsで制御する。

Q. なぜ1回目で読まれない？
A. 記事が報告する観測挙動で、初回セッションでは反映されず2回目以降で効くという指摘。恒久仕様かは要追跡。

この挙動は憶測ではなく本体の変更に対応する。claude-code v2.1.277のリリースノートに『CLAUDE.mdの無いプロジェクトでAGENTS.mdを読む（/configのProject instructionsで変更、Bedrock/Vertex/Foundryは未対応）』と明記されている。

利点は、危険操作の遮断や規定監査といった『判定』を高速・安価な専用モデルに逃がせること。一方で数値（1.4秒など）は各記事の自己申告で、審査モデルの誤判定（見逃し・過剰ブロック）のコストはまだ検証されていない。ガードレールを外部モデルに委ねる構成そのものの信頼性評価が今後の論点。

HNでは『DB各社が相次いでFTSを出すのはAIコーディングの生産性が実世界に現れた例』との見方（ParadeDB/pg_search、Timescaleのpg_textsearch、Neon/DatabricksのLakebase Searchが列挙された）。一方で『SQL内FTSはリレーショナルな関心とドキュメント格納の間にインピーダンスミスマッチがあり、SQLを記録系にして外部Lucene索引を持つハイブリッドを好む』という慎重論も根強い。またローカル版は性能特性が異なる点への注意喚起があった。

統合型FTSは運用がシンプルになる反面、カスタマイズ性と可搬性（クラウド依存）がトレードオフになる。

コメントでは『このプロジェクトはまさに1年前のjevアーキテクチャ研究の上に立っている』という指摘や、『Jevで一部ワークロードが10倍安く2倍速くなった、CPUで動くかインファレンス業者から買いたい、GPU運用は非自明』といった実運用の声、『tabular foundation modelと何が違い、結局何を学習しているのか』という説明可能性への問いが並んだ。オープンソース化を歓迎しつつ、学習内容の中身を問う姿勢が目立つ。

賛否は割れた。『AIを一律に拒否するのは赤子を湯ごと流すこと』と実験を支持する声がある一方、『十数のバリエーションも結局は同じAI的均一性と匂いを持ち、核心は技術でなくビジョンと想像力の欠如』という根本的批判が上位に来た。『そもそも大量の凡庸さは、手間をかけられない/かけたくない人が生む』というAI以前からの構造を指摘する意見も。デザイナー視点では『Designers RepublicとMemphis調だけはAI生成と即断できなかった（既存デザイン言語の忠実な模倣ゆえ）』という具体評があった。

『十分に熱心な人間のアナリストでも同じことはできた。ただ誰もやらなかっただけ』という冷静な整理が支持を集めた。一方で『これを自律エージェントの手柄のように書くのは、人間の関与・問いかけ・前提知識を無視している。今後は“LLMがXの解決を助けた”と書くべき』というフレーミング批判、さらに『データセット内に既存の解を見つけて流用しただけでは』という懐疑も出た。