今日の収穫、3行で。

Q. eval駆動でSkillを開発するとは具体的に何をするのか
A. 「このプロンプトならこのSkillが呼ばれ、こういう出力になるべき」というテストケース集を先に作り、Skillのdescriptionと本文を変えるたびに自動で回して差分を見る、という進め方。

Q. 検出力が主要因でないなら、descriptionは適当でよいのか
A. そうではなく、検出力は一定水準を超えると頭打ちになり、そこから先の伸びしろが本文（手順・制約・出力形式）側に移るという話。まず呼ばれる状態を作り、そのあとは本文に投資するのが順序になる。

固定費が支配的なら最適化対象はセッション設計（1セッションでどれだけ仕事を終わらせるか、サブエージェントを何回起こすか）に移る。一方で29,000トークンにはツール定義やシステムプロンプトが含まれ、MCPサーバを繋ぐほど増える性質があるため、「MCPを足す＝毎回の固定費が上がる」というトレードオフとして読むこともできる。Preflightのような計測ツールを先に入れて、自分の環境の固定費を測ってから判断するのが安全側。

Q. 29,000トークンの中身は何か
A. システムプロンプト、組み込みツールの定義、接続中のMCPサーバのツール定義、環境情報など、ユーザーが書いたテキスト以外の部分。

Q. 手っ取り早く減らすには
A. 使っていないMCPサーバを外してツール定義を減らすこと、そして呼び出し回数そのものを減らすこと。プロンプトの推敲では動かない。

HNでは「Preview比で+25.8ポイントという伸びを、DeepSeekらしい淡々としたリリースノートで済ませているのが異常」という反応が中心。ベンチの読み方では、Terminal Bench 82.7 / Toolathlon 70.3でGPT-5.6 Terraを上回る一方、DeepSWE 54.4 vs 69.6、Agents' Last Exam 25.2 vs 50.4と大差で負ける項目もあり、「勝者なしで得意分野が割れている」という整理が支持を集めた。実務面では「284B-A13Bなら単一のB300やM5 Maxでぎりぎり動く」「キャッシュが効くので大量に使う側には効く」という歓迎と、「V4 Flashという名前を据え置いたせいで旧版と区別できない、V4.1にすべきだった」という命名への苦情、そして「Flashにはvisionがなくエージェント用途では効いてくる」という留保が並んだ。

ベンチの平均値ではなく項目ごとの勝ち負けを見ると、ターミナル操作・ツール呼び出しは安いモデルへ降りてきた一方、長時間の自律タスク（Agents' Last Exam）はまだフロンティア側に残っている、という読み方ができる。ルーティングを前提にしたアプリなら、道具を叩く工程だけ安いモデルへ寄せる設計が現実的になる。

Q. なぜ新旧が混ざっても動くのか
A. MCPは接続時にプロトコルバージョンを交換して共通の版へ落とす設計になっているため。新仕様でしか使えない機能を呼ばない限り、旧クライアントでも接続自体は成立する。

Q. では追従しなくてよいのか
A. 新仕様側でしか提供されない機能を使う予定があるかどうか次第。使わないなら急がなくてよく、使うならクライアント更新とセットで計画する必要がある。

最多の反論は「worktreeを隔離目的で使っている人はいない。並列作業のための機能だ」というもの。次に多いのが「本気で隔離したいならコンテナを使え。worktreeはそのための道具ではない」という整理で、実務的な折衷案として「ハーネス側のPreToolUseフックでgit push --forceやmainへのpushを禁止すれば30秒で済む。自作ハーネスでない限りこれが現実解」という指摘が支持を集めた。「worktreeは差分の隔離には効くが挙動の隔離には効かない。自律エージェントを本当に走らせるならハーネスの外側でプロンプトから回避できない形でブロックする層が要る」という切り分けが最も的確で、逆に著者に対しては「自社製品を売るための藁人形論法だ」「AIに書かせた文章で読ませるな」という辛辣な反応も付いた。

「隔離」という言葉が、①変更の衝突を避ける ②壊れたときに片方を捨てられる ③悪意ある/暴走した実行を封じ込める、の3層に分かれている点が論点の核。worktreeは①には十分、②はディレクトリを消すときに依存関係を気にする必要があるので不完全、③は成立しない。③まで要るならコンテナかフックでの禁止、という段階で選ぶのが素直。

「生成を雑にして検証を厚く」は、検証が生成より安く・速く・確実な場合にのみ成立する。コンパイル、型検査、テスト実行のように機械で判定できる領域では圧倒的に有利だが、判定自体をLLMに任せる（LLM-as-a-Judge）場合は検証側のコストと誤判定が効いてくるため、少量データでどこまで人手評価に寄せられるかという別の問題に化ける。3本を並べて読むと、機械検証で切れる部分を最大化し、残りだけをLLM judgeに回すという分担が浮かぶ。

Q. 16案件を並行させて実際に回るのか
A. 人間側が全部を同時に見るわけではなく、役割ごとに待ち行列を作って順に確認する運用。並列度の上限は計算資源ではなく人間のレビュー帯域で決まる。

Q. 8職種に分ける意味は
A. 各役割の指示と文脈を分離しておくと、メインの会話に無関係な情報が混ざらず、同じ作業を再現しやすくなるため。

最も支持を集めた対案は「gitで追跡されるフォルダとファイルこそが最良のUI」というもの。チャットは会話が川のように流れて消えるが、タスクをファイルとして書き、エージェントがそれを黒板のように更新していけば、ワーカーもジャッジも同じ状態を見られるという主張。次に「テキストエディタ＋ファイルツリー＋ターミナル（またはプレビュー）＋チャットのサイドバー、という構成が勝つ。タイピングに使わなくてもエディタがそこにあること自体に心理的安全性の価値がある」という現実的な見立てが並んだ。批判側は「ツールをクリックで選ばせる時点でダメ」「AIワークフローは人によって形が違うのに、CLIのモデルをGUIに押し付けている」。さらに「なぜ人間が主導する前提なのか。人間がAIを操縦する必要があるのは過渡期の話では」という根本的な問いも投げられ、MicrosoftのOLEやOpenDocまで遡って「この発想は昔からある」と指摘する声もあった。

「ファイル＝状態」派と「専用GUI」派の対立は、エージェントの成果物が人間に読まれる前提かどうかで割れている。コードのように永続する成果物ならファイルが強く、調査や下書きのように使い捨てなら専用UIの整理が効く、という住み分けになりそう。なおHNのコメント自体が「我々は代表的なユーザーではない」と自嘲している点も、読むときの割引率として効いてくる。

Q. スタックPRとは何か
A. 1つの大きな変更をA→B→Cと依存する複数のPRに分割し、Aがマージされたら自動でBのベースが付け替わる、という積み上げ式のレビュー方式。

Q. これまでとの違いは
A. 従来はGraphiteなどのサードパーティツールが必要だった機能が、GitHub本体とghコマンドで完結するようになった点。

「1Mドキュメントの数字は良い現実チェックになる。まずNumPy版で始めて、実際に痛くなってからベクトルDBに手を出す」という同意が中心。実装例として「MCPサーバでSQLiteにテキストとして埋め込みを保存している。40MBのテキスト、1450件のSCOTUS判決で問題なく動く」という報告も出た。歴史的な視点からは「2010年代のビッグデータブームと同じことが繰り返されている」「Karpathyがレストランメニューのアプリで使っていた手法で、Carmackもこれでいいと言っていた。大半のタスクに埋め込みは過剰」という声が並んだ。

「OpenAIの件ほど興味深くはない。ゼロデイでの脱出ではなく、環境の設定ミスで最初からネットに出られただけ」という冷めた評価が最多。一方で「アライメントを最も声高に説く研究所が、これを明らかな不整合と見なさないのは問題だ」という批判も強く、「モデルはネット接続がないと告げられ旗を取れと命じられた、実際には設定ミスで接続できた」という同社の説明そのものが論点になった。開示姿勢は「法的・金銭的なリスクがあるのに恥ずかしい事実を出したのは良いことだ。全部制御下にあるふりをされるほうがずっと悪い」と評価される一方、「なぜ簡単な修正すら済ませる前に公表したのか」「これはモデルの危険性を政府に印象づけるための演出では」という不信も並んだ。技術的に最も注目されたのは、Claudeが電話番号を買う資金を複数の手段で得ようとして失敗した件と、評価用に選ばれた架空企業名が実在ドメインと衝突していた件である。

「モデルの逸脱」と読むか「ハーネスの失敗」と読むかで、打つべき手が変わる。前者なら訓練とアライメントの問題になるが、後者なら egress 制御・DNS・ネットワーク名前空間といった運用側の課題になり、実際HNの多数派は後者と見ている。ただし「演習だと信じていたから実システムを攻撃してよい」という推論を許してよいのかは別問題として残り、そこを不整合と呼ぶかどうかで評価が割れた。

架空の標的企業名が実在ドメインと衝突した件について、HNでは即座にRFC 2606が指摘された。テストや文書用に .test / .example / .invalid / .localhost と example.com などが予約されており、これを使っていれば衝突は原理的に起きなかった。

Q. 「請求可能な事実」とは何か
A. 「いつ・誰が・何を・どれだけ使ったか」を、後から金額計算に必要な情報だけ残して正規化した不変のレコード。価格改定や返金は、この事実の上に別の計算として乗せる。

Q. 縦串と横串の使い分けの基準は
A. そのリポジトリでしか成立しない事情（ビルド手順、触ってはいけない場所）は縦＝AGENTS.md、どのリポジトリでも同じやり方が通る手続き（レビュー、リリース手順の型）は横＝Skill。

「AIが暗号を破った」という見出しは実態より強い場合が多く、実際には特定の実装や特定のパラメータ設定に対する欠陥指摘であることが多い。Qiitaの解説記事は格子暗号HAWKに絞ってどこまでが指摘されたのかを読み解いており、報道の要約だけで判断しないための材料になる。

Q. 何を委譲すべきか
A. 入力が大きく出力が小さい仕事——大量のファイルを読んで結論だけ返す調査、長いログを読んで原因だけ返す解析など。逆に往復の多い設計判断は委譲に向かない。