今日の収穫、3行で。

HN の Ask スレッド「Why I prefer Opus 5 to Fable 5」では評価が真っ二つ。Opus 4.8 から乗り換えた層は「xhigh を Opus 5 medium に置き換えたらトークンが減って速くなった」と歓迎する一方、hardrave は「Fable は低レベルなシステム系プロジェクトを end-to-end で完成させたが、Opus はアーキテクチャで詰まった。Opus の方が誘導はしやすいが、やり切るのは Fable」と逆の経験を報告している。0xedwen のように「分析は Fable、推論は GPT Sol、実装は Opus/Sonnet」とモデルを役割で混ぜる運用も挙がった。

「指示を削る」派の根拠は、モデルが既定で検証・整理を行うようになった以上、明示指示は重複コストにしかならないという点。懐疑派は、削った結果が安定するかはコードベースとタスク依存で、リバウンド報告があるとおり一律の最適解にはならないと見る。実務的には CLAUDE.md を一度空にして計測し直す（後述の Boris Cherny インタビューと同じ主張）のが折衷案になる。

Q. Opus 5 は Claude Code でどう扱いが変わったのか。
A. v2.1.219 で `claude-opus-5` が追加され既定の Opus モデルになった。1M コンテキストで、fast mode の価格は $10/$50 per Mtok。

Q. CLAUDE.md をいきなり全部消してよいのか。
A. 記事群は削減の効果を報告する一方でリバウンド事例も併記しており、一括削除ではなく計測しながら段階的に削るのが妥当。

最大の争点は「これはモデルの問題かハーネスの問題か」。delbertty は「slop が溜まるのはエージェントが何でも触れるときで、1つの継ぎ目に制約して既存を書き換えず横に足させる方がモデル選択より効く」と harness 側の責任を主張し、ajwin も system prompt での事後整理指示で緩和できるのではと問うた。数値の読み方でも割れており、willsmith72 は「17%→24% は 41% の改善であって『大きくは伸びなかった』は悲観的すぎる」と反論。robbomacrae は「1タスクで止まらない点が SCB の価値。ただし全課題が greenfield で git init されておらず、エージェントが git diff を使えないのが弱点」と限界も挙げた。mellosouls と weiliddat は「人間の p50/p95 と比較しないと 24% という数字が独り歩きする」と指摘している。

肯定側は、決定的スコアで「保守性」を測れる点と、ラボの RL パイプラインに逆流すればモデルの傾向自体が改善しうる点を評価する。懐疑側は、ベンチマークの乱立自体が指標を無意味にしていること（tamimio）、および特定チェックポイントが仕様の曖昧さで落ちている可能性（4by4by4 は database_migration の default_value が JSON リテラルとも SQL 式とも解釈できると指摘）を挙げる。

Q. SlopCodeBench の「strict pass rate」とは何を測るのか。
A. 単発タスクの正答ではなく、複数チェックポイントを通して機能を積み増した後もコードが保守可能な状態を保てているかを決定的に採点した通過率。

Q. スコアが低いのはモデルのせいか。
A. HN では harness 側（エージェントに触らせる範囲の制約や、実装後の整理ターンの有無）の寄与が大きいという意見が優勢だが、決着はついていない。

コミットする方式は再現性が高く監査もしやすい反面、skill の更新が各リポジトリへの PR になる。実行時 install 方式は更新が一箇所で済むが、CI 実行時に外部取得が入るため供給元の可用性とバージョン固定が新たな依存になる。どちらを取るかは、skill を組織で共有するか個人で使い回すかで分かれる。

同日の Zenn 記事「直したのはバグではなく前提だった」は、汎用の記事生成スキルを Zenn 特化に作り直した記録で、skill の失敗が実装ではなく想定範囲の設定にあったと結論している。

Q. 定時タスクが承認待ちで止まるのはなぜか。
A. 記事によれば原因は settings 側ではなくタスク定義側の権限モードで、そこを1つ変えれば解決した。

Q. Claude Code Action の Agent Mode と Tag Mode は何が違うのか。
A. 同じ入力でも起動経路と応答の仕方が異なるため、CI に組み込む際は両者の挙動差を実測しておく必要がある、というのが検証記事の趣旨。

並列化を推す側は、複数エージェントの出力を突き合わせること自体が検証になり、単独実行より誤りが減ると見る。慎重派は、並列化はコンテキストの分断とコスト増を招くため、まず1エージェントが落ちない構成（再開・再実行の設計）を先に固めるべきだと考える。定点観測が示す「自己認識」への要望は、後者の立場に近い。

Claude Code v2.1.218 / v2.1.219 では、`claude mcp list` と `/mcp` が接続失敗時に HTTP ステータスとエラー本文を表示するようになり、MCP 設定値の先頭・末尾に不可視の空白があると警告するようになった。今回の記事のような「つながっているように見える」問題の切り分けは以前より容易になっている。

Claude Code v2.1.216 では、長時間セッションでメッセージ正規化のコストがターン数に対して二次関数的に増加し、数秒のストールと再開の遅さを招いていた問題が修正されている。セッションが遅い原因がフックとは限らない点に注意。

懐疑側の主張は、生成速度が上がってもレビューのスループットは上がらないため、ボトルネックが移動しただけだというもの。推進側は、レビュー負荷そのものをツール（差分の分割、レビュー用の別エージェント）で下げられると反論する。「Make Reviews Possible Again」は後者の立場から具体的な手法を提示しており、対立というより同じ問題への異なる解法として読める。

HN では「ハーネス作者が自分たちの skills.md / claude.md というギア一式を否定し始めている」ことへの戸惑いが出た。firasd は「Claude Code の本質的な洞察は『AI にツール、それも実際のラップトップを渡す』ことだった。ただしハーネスを作る人たちの他のアイデアがすべて普遍的に通用するとは思わない」と留保をつけている。iooi は別方向から、「モデルがそれほど優秀なら bun を Rust で書き直す必要すらなく、ランタイムをゼロから作れるはずだ」と Anthropic の宣伝文句に疑問を呈した。

Q. 本当に全部消してよいのか。
A. 推奨されているのは「消したまま運用する」ことではなく「一度消して素の挙動を測り直す」こと。s01 のリバウンド報告のとおり、戻す判断は計測後になる。

同期を自動化する利点は指示のドリフト防止だが、片方だけに存在する機能（フック、skill、権限モデル）は最小公倍数に丸められない。共通部分だけを生成し、エージェント固有部分は別ファイルに切る二層構成が現実的な落としどころになる。

gokohl は「他社は局所層に RoPE を残してヘッジするのに、全面 NoPE に踏み切ったのが興味深い。線形アテンション（Kimi Delta）が位置の仕事を静かに肩代わりしているのだろう。フロンティア規模でも保つかは要観察」と述べた。Ilaurens はより素朴に「なぜこれが成立するのか腑に落ちない。帰納バイアスなしで、2番目のトークンが自分は2番目だと学習で分かるほどアテンションは精密なのか」と疑問を投げている。constantlm は「Kimi は蒸留の産物にすぎないという西側ラボの主張と違い、新規手法を持ち込んでいる」と評価した。

Q. NoPE とは何か。
A. No Positional Embeddings の略で、RoPE のような明示的な位置埋め込みを持たせない構成。Kimi K3 はこれを全層で採用している。

Q. 2.8兆パラメータは自前で動かせるのか。
A. Fixstars の検証は NVIDIA B300 8基の1ノードで動くかを Day0 で試したもの。実行可否と実効速度は記事本文を参照のこと。

Claude Code のセッションはプロンプトキャッシュの TTL を前提に設計されており、キャッシュが効いている間は会話履歴を送り直すコストが大きく下がる。長い間隔を空けた再開が高くつくのはこのため。

ソフトウェア側の標準的な立場は、テストを増やして網を細かくすることで乖離を埋めるというもの。製造業側の型は、検査工程そのものを設計対象として先に定義し、合格基準を満たさない成果物を工程間で通さない。後者はエージェントによる大量生成と相性が良い一方、基準の定義コストが前倒しで発生する。

「プロンプトインジェクションは原理的に防げないので、権限とネットワーク到達範囲を絞るしかない」とする立場と、「入力の出所を分離して信頼境界を明示すれば緩和できる」とする立場が並存する。Claude Code v2.1.219 の `sandbox.network.strictAllowlist`（許可リスト外のホストを確認なしで拒否）は前者の発想に沿った機能。

共有チャットの検索露出は攻撃ではなく設定の事故だが、エージェントの出力に機密が混ざる前提で共有機能を使うと、同じ経路が情報漏洩になりうることを示している。