今日の収穫、3行で。

賛同側は「評価器を進化ループの外に置く」という原則を実務経験から支持した。ある投稿者は、弱い評価器より危険だったのは「検査が不完全なまま成功を報告する」状態だったとして、必要な検査が揃っていなければ何も出荷しないfail-closedに切り替えたと報告している。懐疑側の中心はreward hackingで、gpt5.5に収束性の改善を頼んだところ「バイトを直接出力して丸ごと保存する」抜け道で満点を取ったという例が挙がり、改善の方向が既知なら現行モデルでも到達できるが、どの方向が正しいかの判断までは任せられない、という線引きが示された。ほかに、ハーネスこそがフロンティアモデル各社の参入障壁（moat）になるのではという指摘や、自作ハーネスをEmacs LispやCommon Lispで書いているという実践報告も並んだ。

Q. ここで言う「ハーネス」とは具体的に何を指すのか。
A. モデルの重み以外の、モデルを動かすための周辺一式を指す。システムプロンプト、ツール定義、コンテキストの組み立て方、実行結果の検査やリトライの制御といった、推論の外側にあるコードと設定のこと。

Q. なぜ評価器を改善ループの外に置くのか。
A. 評価器そのものを最適化の対象に含めると、エージェントは課題を解く代わりに評価を緩める方向へ「改善」してしまうため。外に固定された評価器だけが、改善が本物かどうかを判定できる。

Q. プロンプトキャッシュはどういう条件で効くのか。
A. リクエストの先頭から連続して一致した範囲だけがキャッシュヒットになる。したがってシステムプロンプトや固定文書を先頭に置き、毎回変わる部分を末尾へ寄せるほど、再利用される範囲が伸びる。

Q. 利用ログを解析すると何がわかるのか。
A. どのツールが何回呼ばれ、どのセッションでトークンを使ったかの内訳が出る。体感では気づかない繰り返し（同じファイルの再読み込み、失敗して再試行しているコマンド）が偏りとして見える。

分離を強く推す側は、親の文脈を汚さずに調査や検証を並行させられる点と、失敗したサブエージェントを捨てても本流が壊れない点を利点に挙げる。慎重派は、サブエージェントが親の文脈を引き継がない以上、前提を毎回書き直すコストが乗り、往復が増えるだけになる場合があるとする。16GB機の報告は後者の実例にあたり、状態を厳密に分離する設計をやめたら動くようになったという結果は、適切な分離の粒度がハードウェア資源とタスクの性質に依存することを示している。

Q. `.claude/agents` の設計でよくある失敗とは何か。
A. 記事が挙げるのは、責務の重なったagentを並べる、親と同じツール権限を丸ごと与える、呼び出し条件をdescriptionに書かないために発火しない、といった型。どのagentが呼ばれるかはdescriptionの記述で決まるため、そこが曖昧だと定義しても使われない。

賛否はほぼ「規約をエージェント側に厚く積む方式が効くのか」に集中した。否定側は、この構成はトークン消費・レビュー面積・1タスクあたりの時間を増やすだけではないかと疑い、別の投稿者は「コンテキストを詰めるほどエージェントは忘れて守らなくなる」として、ArchUnitのような静的解析でリポジトリ側に強制するほうが確実だと主張した。READMEへの批判も多く、Factor III / Factor IX といった独自のローマ数字体系が何を指すか本文から追えないため、良い手法かどうか以前に理解できないという指摘が支持を集めている。

Q. なぜCLIのforkではなくskillにしたのか。
A. プロンプト的なワークフローを配るためだけにCLI本体のforkを維持すると、上流の更新のたびにマージ負債が生じるため。SKILL.mdは各リポジトリへ入れるファイルなので、CLI側は素のまま使える。

コスト最適化の入口は2つに分かれる。1つは課金体系そのものを読む方向で、実行単位のクレジット制ではツール呼び出しや検索の回数が費用に効くため、プロンプトの短縮よりワークフローの削減が利く。もう1つは実測でモデルを振り分ける方向で、単価表だけを見て安いモデルへ寄せると、レイテンシと再試行が増えて総コストが悪化しうる。どちらも「トークン単価×文字数」という直感的な見積もりが実態から外れる点で一致している。

Q. skillとサブエージェントはどう使い分けるのか。
A. skillは「手順」を渡すもので、実行するのは呼び出した本人のコンテキスト。サブエージェントは「別のコンテキスト」を立てて任せるもの。手順を固定したいだけならskill、文脈を分けたいならサブエージェントになる。

SKILL.mdはYAMLのフロントマター（nameとdescription）と本文のMarkdownだけでできている。このうちdescriptionは、モデルがそのskillを呼ぶかどうかを判断する事実上唯一の手がかりになるため、本文をいくら丁寧に書いてもdescriptionが曖昧だと呼ばれずに終わる。

HNのコメントは少数だが実需寄りで、「TCP/UDPしか話さない安価な車両追跡IoT機器が多く、これを待っていた」という反応が最上位に来た。既にWorkersを業務で使っている層からの歓迎が続き、否定的な論点は挙がっていない。

Workersはこれまで受信をHTTPとWebSocketに限っていたため、独自のTCPを話す機器や、HTTP/2の下位機能に依存するgRPCを受けるには前段にプロキシを立てる必要があった。今回の対応は、その前段を1つ減らす種類の変更にあたる。

push型（毎回コンテキストへ規約を載せる）は確実に目に入る代わりにトークンを恒常的に消費し、量が増えるほど無視される項目が出る。pull型（必要になった時にエージェント自身が取りに行く）は文脈を軽く保てるが、取りに行かせる引き金——hookやskillのdescription——が壊れると誰も気づかないまま素通りする。hookのfail-closed設計はその弱点への回答にあたり、検査が動かなかった場合に黙って通すのではなく止めることで、沈黙した失敗を可視化する。

Q. fail-closedとfail-openの違いは何か。
A. 検査が実行できなかったときに、通す（fail-open）か止める（fail-closed）かの選択。fail-openは日常の邪魔にならない代わりに、検査が死んでいても気づけない。

Q. hookに契約テストを書くとは具体的にどうするのか。
A. hookが受け取る入力と返すべき出力の形（終了コード、JSONのキー）を固定し、その形が満たされるかをテストで検証する。ホスト側の仕様が変わればテストが落ちるので、静かに無効化される事態を防げる。

Q. 「直列待ち」はどう見分けるのか。
A. ログ上で、あるサブエージェントの完了時刻と次の起動時刻がほぼ一致していれば逐次実行になっている。並列に投げられていれば、複数の起動時刻が重なって現れる。

Q. 並列化すれば常に速くなるのか。
A. 後段が前段の結果に依存する処理は並列化できない。効くのは、互いに独立した調査や検証を同時に走らせられる場合に限られる。

CLI側の利点は、エージェントと人間が同じインターフェースを共有できること、標準出力とexit codeという既存の契約に乗れること、サーバープロセスを常駐させずに済むことにある。MCP側の利点は、ツール定義がスキーマとしてモデルに渡るため引数の当て推量が減ること、認証や接続の状態をサーバー側に持てること、複数のホストから同じツール群を再利用できることにある。判断は「そのツールを他のホストへも配るのか」「引数が複雑でスキーマ提示の価値があるのか」で分かれる。

評価が集まったのは「1スレッド＝1VM」と「各サンドボックスがライブURLを持つ」点で、あるコメントはCursorのクラウドエージェントにこれがないためローカル開発環境を捨てきれない、と価値を言い当てている。同じ投稿者は、ClickHouseやlocalstack、PostgreSQLをdocker composeで束ねている開発環境をクラウド側で再現できるのかを質問した。価格については「業務なら$99/席/月は妥当だが個人利用には重い」として従量課金の追加を求める声、ランディングページのAI生成アニメーションが実物のスクリーンショットより信頼を損ねているという指摘、hoplite.ggとの名前衝突の指摘が続いた。

最も支持を集めたのは緩和策の具体案で、「公開直後のバージョンをCIが採用しない」クールダウン（RenovateのminimumReleaseAge）を入れるだけで、数時間で広がるワームを「N日の公衆の目に耐えてから届く」問題へ変えられる、という指摘だった。仕組み側への批判も強く、これまで存在しなかったpre-install/post-installフックを新たに追加するパッケージは原則拒否すべき、そもそもインストールフック自体を廃止すべきという意見が並んだ。一方で記事の書き方への反発もあり、「月間20億インストール」という数字は大半がCIでの実行であり実害の規模とは対応しない、という指摘が出ている。

Q. 自分の環境が汚染バージョンを取り込んでいるかはどう確認するのか。
A. コメントでも同じ質問が出ており、決定版の手順は共有されていない。実務的にはロックファイルと node_modules／pnpmストアを対象に、影響を受けたパッケージ名とバージョンの一覧（Aikidoおよびflatt.techの記事が掲載）を突き合わせることになる。

「モデルがXで動いた」という見出しは通常「何を諦めたか」の一覧に読み替えるべき、という前提でコメントが検証を進めた。量子化は落としていない、速度も150 tok/s超で問題ない、諦めたのはコンテキスト長（1M→256k）だけで実用上は妥当な取引だ、という整理が支持を集めている。ハードウェア側の指摘も多く、MI300XはOAMモジュールのため単体購入が難しくPCIe版のMI350P（144GB）が現実的な選択肢だが、256エキスパートがネイティブMXFP4量子化なので144GBでも載る、という補足が付いた。性能面では、DeepSeek自身がH800で15k tok/s/GPUを報告しているため、まだ最適化の余地は大きいという指摘も出ている。

Q. `Access-Control-Allow-Origin: *` にするとCookieが送れないのはなぜか。
A. 認証情報つき（`credentials: 'include'`）のリクエストでは、ワイルドカードのオリジン指定は許可されない。具体的なオリジンを返し、あわせて `Access-Control-Allow-Credentials: true` が必要になる。

Q. プリフライトはいつ飛ぶのか。
A. メソッドやヘッダが「単純リクエスト」の条件を外れたときに、本番のリクエストの前にOPTIONSが送られる。`Content-Type: application/json` を付けるだけでも条件を外れる。

SQLiteの内部テストスイートは本体のコード量に対して桁違いの規模を持ち、分岐網羅の一種であるMC/DCで100%のカバレッジを維持していることが公式に明記されている。MC/DCは航空機搭載ソフトウェアの認証基準（DO-178B）で要求される水準で、データベースエンジンが自主的に採っている例は珍しい。

デザインへの評価が正面から割れた。「1990年代のUIにしか見えない」「余白を直すだけで済むはず」という否定側に対し、「装飾より実用と情報密度を優先しており、端末UIをWebへ移植したBloomberg端末のようだ」と評価する側が並んだ。技術面では、JavaScript側にテール呼び出し最適化がないためユーザーランドのトランポリンが必要という指摘、同じくOCamlをフロントに使うMelangeとの比較、Reactやgraphqlといった既存JSエコシステムをどこまで捨てることになるのかという質問が出ている。最上位に来たのは、低レイテンシにはOCaml、ハードウェアにはHardCaml、Web UIにはBonsaiと、Jane Streetがすべてを Caml で揃える姿勢そのものを面白がるコメントだった。

歓迎と警戒が並んだ。歓迎側は、不動型がないために導入されたPinは穴を塞ぐハックであり、ようやく言語側で埋まると評価する。警戒側の代表的な整理は、Rustの「moveは必ず自明で破壊的」という前提が、デストラクタを呼ばずに有効なオブジェクトの場所を無効化できる事態（leakpocalypse）を許してしまい、その後始末が今回の変更につながっている、というもので、これをRustが漸進的にC++のモデルへ寄る過程だと見る。実務面では、参照循環でも安全に値をリークできる以上 `mem::forget` だけを塞いでも足りないのではという疑問が出た。なお最上位のコメントは、これは受理された言語変更ではなくプロジェクトゴール（着手が認められた段階）であり、設計は大きく変わりうると注意している。