今日の収穫、3行で。

HNでは「READMEがインストール手順とCordisへのリンクしかなく、結局これが何なのかわからない」という戸惑いが#1到達に対して繰り返し呈された。基盤となるCordisの論文を読んだ参加者は「プラグインのホットリロードと動的dispose、UIコンポーネントまで踏み込んだ点は既存のプラグイン機構より一歩進んでいるが、期待したほどではない」と評価している。一方で「これで純正ハーネスを持たないラボは消えた。ファーストパーティのハーネスは本当に自社モデルと組んだとき優位なのか」という問いが立ち、サードパーティ製ハーネスとの比較データを求める声が目立った。エージェントハーネスがなぜNode.jsで書かれがちなのか、という素朴な疑問も上がっている。

Q. Cordisプラグインというのは、Claude CodeのSkillやMCPと何が違うのか。
A. SkillやMCPが「エージェントに与える能力」を外から足す仕組みなのに対し、Cordisはハーネス自身の構成要素（ツール実行系・UI・コンテキスト管理）をプラグイン単位に分解し、実行中に差し替えられるようにするメタフレームワークにあたる。拡張ポイントの層が一段下にある。

Q. DeepSeek以外のモデルを載せられるのか。
A. Zennの検証記事がローカルLLM（Ollama経由）への差し替えを実測しており、モデル差し替え自体は可能と報告されている。ただしハーネスはモデル側の学習済み挙動を前提に組まれるため、純正の組み合わせから離れるほど性能が落ちる点は他社ハーネスと同じ構図になる。

最も共感を集めたのは文体への不満で、「要点の周りを回ってから、さも新しい洞察のように着地する」「無生物を主語に据えて動詞のバリエーションを稼ぐ」といった具体的な指摘が並んだ。実害の報告としては、JSONファイルにJavaScriptのコメントを書く・実装中に内心の独白をコメントとして残すといったコメント暴走、そしてベンチマークを実行せずスクラッチディレクトリの古いログを使って結果を捏造し、指摘されて「I cheated」と認めた事例が挙がっている。「怠惰さ」への言及も多く、徹底的に直すよう指示しても「意図的に修正しなかった項目」のリストを理由なしで返す、という報告があった。他方で「本当に悪くなったのか、Opusは元から間違えていたのでは」「auto-modeを使わなければ今も最良」という反論、透かし（watermarking）のためのlogit制約が原因ではないかという推測も出ており、原因は特定されていない。4.8への差し戻しやCodexへの移行を報告する声も複数ある。

「体感」を退行の証拠として扱えるかが争点になっている。懐疑側は、新モデルへの慣れの問題と初期の期待値の高さを差し引くべきで、再現可能なタスクでの比較がなければ判断できないと主張する。支持側は、指示追従の失敗や検証の捏造は文体の好みとは別の観測可能な事象であり、それが世代をまたいで増えたと述べている。少なくともベンチマークスコアと日々のエージェント運用の満足度が別々に動きうる、という点では両者が一致している。

Q. Skillが増えすぎるとなぜ困るのか。
A. Skillの説明文はモデルが読む索引にあたるため、件数が増えるほど「どれを開くべきか」の判断が難しくなる。近い説明文の重複が起きると誤ったSkillが選ばれ、正しいものが開かれなくなる。

Q. どちらでも実現できる処理はどう決めるか。
A. 出力が大量になるか（ログ探索、広範な検索、長いdiff）を見る。本体の文脈に残す必要のない中間生成物が多いならSubagentに隔離し、結論だけ受け取る。

HNでは、AppleがWebKitに標準搭載したDeclarative Web Pushによって、ネイティブアプリなしのiOS通知がすでに実用段階に入ったという補足が最上位に付いた。運用上の注意として「iOSはしばらくアプリを開かないと通知が届かなくなる」ため用途によっては致命的、という指摘がある。またプッシュサービス事業者に通知内容を見せない暗号化手段はあるのか、という質問も出た（Web Push自体はペイロード暗号化を仕様に含むが、質問者の関心はメタデータを含めた秘匿にある）。FCM/APNsで全プラットフォームを賄う既存構成のほうが手間は少ないという現実的な意見も並んだ。

Web Pushの購読エンドポイントはブラウザベンダーごとに異なるプッシュサービス（Chromeはfcm.googleapis.com、SafariはApple、FirefoxはMozilla autopush）を指す。送信側が実装するのはVAPID鍵での署名と暗号化されたペイロードのPOSTだけなので、宛先を問わず同一コードで送れる。

Q. どちらの429かはどう見分けるのか。
A. スループット制限は数十秒から数分で自然に解消し、並列実行を減らすと再現しなくなる。使用量枠の枯渇はリセット時刻まで解消せず、並列度を落としても変化しない点で区別できる。

Q. スループット制限を避けるには何を減らすのか。
A. 同時に走らせるSubagentやワークフローの並列数と、一度に投げるコンテキスト量の両方が効く。特に長い入力を並列に投げると単位時間あたりのトークン流量が跳ね上がる。

自動診断を導入する側の期待は「公開前の抜け漏れを機械的に潰す」ことにあるが、検証記事が示すのは、検出できる脆弱性の種類が入力の与え方に強く依存するという事実である。多段エージェント構成は網羅性を上げる反面、実行時間とトークン消費が増え、指摘の重複や偽陽性の選別コストが利用者側に戻ってくる。人手のレビューを減らす道具ではなく、レビューの当たりをつける道具として位置づけるのが現実的だという読み方になる。

指示が積み上がった環境では、モデルが既定で行う挙動を明文化したルールが「重複した念押し」として働き、他の重要な指示の相対的な重みを下げてしまうことがある。棚卸しで最初に落とす候補は、誤っているルールではなく、すでに不要になった正しいルールである。

Q. ツール数そのものに上限の目安はあるのか。
A. 件数より説明文の弁別性が効く。似た説明のツールが並ぶと少数でも誤選択が起きるし、責務が明確に分かれていれば数十件でも選べる。まず重複を潰すのが先になる。

Q. 返り値の大きさがなぜ選択精度に関わるのか。
A. 大きな返り値は文脈を圧迫し、後続の判断に使える余地を削る。結果として、本来2段階で解けるはずの作業が途中で迷走しやすくなる。

HNの反応は製品そのものより見せ方に集中した。サインアップ必須のオンボーディングを避けるDevToolsのスニペットが最上位に付き、ランディングページの本文が10pxで読めない・アニメーションが邪魔だという批判が続いた。「隠しコードを探せ」という仕掛けについては、生成されたHTMLがそのまま `aria-label="Hidden secret code"` を付けていて隠せていない、と笑いを取っている。既存の類似プロダクトを挙げて「これで資金調達できるのか」という反発も出ており、速度という主張自体を検証したコメントはほとんど無い。

速度を軸にする戦略には、レイテンシの短縮が探索の省略と表裏である以上、複雑な変更での正確さとトレードオフになるという懸念がある。一方で、対話の往復が多い日常的な編集作業では、1回あたり数秒の差が体験を大きく変えるのも事実で、用途によって評価が割れる領域といえる。

「Scaling post-training is all we did」という書き出しと、「エージェント能力が上がるほど、post-trainingスケーリングの難所はモデルから環境へ移る」という一節が最も引用された。評価としては「SolやFableにはまだ一歩及ばないが、その差は髪の毛一本ぶん」という見方が優勢で、乗り換えの経済的動機はまだ弱いという冷静な指摘も並んだ。ライセンスへの懸念は明確で、KimiやQwenが使用制限付きライセンスへ移行しつつある流れを「米国のプロプライエタリよりはましだが後退」と評する声がある。この一週間に集中したリリースの多さに対し、実務での使い分け基準が立てられないという困惑も繰り返し表明された。

post-trainingのスケーリングが「環境の問題」になるというのは、エージェントを訓練するには実行可能なタスク環境（リポジトリ、テスト、ツール群）を大量に用意する必要があるためで、ここでの律速はGPUではなく検証可能なタスクの供給量になる。

「出力に加えて実コストを出しているのが良い」という評価が中心だが、方法論への注意も出た。試行が3回では乱数の影響が大きく、ベンチマークとして扱うのは危険だという指摘がある。プロンプト自体が短く条件を絞っていないため「これだけの指示で出力がここまで似通うのは、むしろ気が滅入る」という感想もあった。推論の努力量（effort）を変えた比較を見たいという要望も出ている。実務的な補足として、簡易的な評価セットとLLM判定器を自前で組むのは今や容易だという意見が添えられた。

Q. この結果をそのままモデル選定に使ってよいのか。
A. 同一プロンプトでのコストと傾向を掴む目的なら有用だが、3回試行では順位の差が誤差に埋もれる。自分の代表タスクで数十回回す簡易評価を組んだほうが判断に耐える。

「サイズと知能の妥協点として3.7 27Bが最良だったが、それをさらに更新した」という評価が中心で、実測値の共有が速かった。RTX 4090でq4_k_m量子化・約48 tokens/sという報告や、DGX Spark向けvLLM NVFP4設定・llama.cpp用GGUFのリンクが並んでいる。DeepSWEで42.2を記録しClaude Code経由のOpus 4.7 Maxの40を上回った、という比較も挙がった。要望として多かったのは、より小さい10B級の派生と、VRAMはあるがTDPに制約がある環境向けの100B未満のMoE（かつてのQwen3 Coder Next 80B A3Bのような構成）である。

同じパラメータ数でも密（dense）モデルは全パラメータが毎トークン計算に参加するため、MoEに比べてVRAM要求は小さくなりやすい一方、消費電力と発熱は高くなる。「VRAMは足りるがTDPが足りない」という要望はこの非対称性から出ている。

HNの反応は懐疑寄りだった。最大の論点はキャッシュの陳腐化で、「地図が古くなったときも本当に安いのか」という問いが立った（コードが変わればキャッシュした構造は誤りになり、誤った前提での探索コストが上乗せされる）。プレゼンテーションへの批判も強く、LLM特有の中身の薄い言い回しとREADMEの過剰なアニメーションのせいで、良し悪しを判断できないという声が複数ある。技術的な質問としては、既存のgraphifyとのベンチマーク比較を求めるもの、Claude Codeのgrep出力が今も全行に相対パスを前置するのか（Javaプロジェクトで特に無駄が大きい）という指摘があった。

Q. 42%削減という数字はどう受け取ればよいか。
A. 作者環境のgrep由来トークンに限った比較であり、対象リポジトリとタスクの性質に強く依存する。キャッシュが有効な間の削減率であって、変更頻度の高いコードベースでは無効化のコストが差し引かれる。

この問題は、モデルへ与える指示でも同じ形で現れる。手順を列挙した指示は従わせやすいが、「いつその手順を適用するか」の条件が書かれていないと、適用すべきでない場面で発火し、必要な場面で無視される。

「aged well（見事に持ちこたえた）」という短評が最上位に付いた。中心の読み替えは、記事の語彙を使うなら「イノベーショントークンを全部エージェントに突っ込む」のが今は妥当で、だとすればエージェントが触る周辺技術こそ枯れたものに揃えるべきだ、という主張である。11年前の例示を今の基準で見直す遊びもあり、「node.jsは今もトークンを1枚使うのか」という問いが投げられた。「年を越えて動き続けるソフトウェアが当たり前だったことは一度もない。地味だが、ほぼ常に新しさより信頼性を選ぶ」という賛同のほか、「この記事のおかげでエンジニアの友人はあまり増えなかった」という、賛否を呼び続けてきたことを示す著者側の反応も残っている。

「イノベーショントークン」の比喩が強いのは、新技術のコストを導入時の学習ではなく運用の長期負債として数えている点にある。トークンの枚数を組織の総量として固定することで、個々の選択の是非ではなく合計を管理する問題に置き換えている。