今日の収穫、3行で。

HNでは「なぜsystem promptをモデルに焼き込まず毎回課金トークンとして送るのか」というコスト面の疑問が上がった。simonwは差分を追えるようgit commit履歴として再構築したリポジトリを共有し、Opus 4.8→Opus 5の変化を可視化している。一方で「このプロンプト自体に矛盾が複数あり、矛盾は指示範囲外の品質まで落とす」という指摘や、Pi・OpenCodeのような自称ハーネスがsystem promptを差し替えられない設計であることへの不満も出た。「簡潔に答えよと書いてあるが実感と違う」という体験談も多い。

Q. 公開されたsystem promptは自分のAPI呼び出しにも付くのか。
A. これはclaude.ai等の製品面で使われるものの記録で、API直叩きには付与されない。ただしハーネス自作時の指示設計の実例としては直接参考になる。

Q. 何を読むと差分が分かるか。
A. HNコメントで共有されたsimonwの抽出リポジトリがモデル世代ごとのcommitになっており、バージョン間diffとして読める。

HNでは「オラクルが全段にあることが本質で、資格情報や他人のダッシュボード設定が要る作業だけが失敗した」という追試コメントが説得力を持って読まれた。DeepSeek v4で半ば放置された動画コーデックに同じループを当てた報告も投稿されている。GPUカーネルやSIMDは学習データが厚い領域なのでは、という当たりの良さへの疑念や、「ループ工学は嫌われるが、モデルが知らないことを引き出す唯一の方法で、しかも実行は簡単ではない」という擁護も出た。一部の投稿がルール（bypass ban check等）を伏せている、という指摘もある。

肯定側は、検証器が自動化できる領域ではエージェントの探索が人間の試行回数を大きく超えると評価する。懐疑側は、232倍という数字が比較対象（PyTorch標準実装等）の選び方に依存し、Cholesky置換のように高速だが数値的安定性を犠牲にする変更が混ざりうる点を問題視している。

Skillはもともとリポジトリ配下の`SKILL.md`という素朴なMarkdown規約として始まったが、フロントマターのdescriptionが起動判定に使われるため、実質的には「いつ発火するか」を書く欄が本体になっている。

「プロキシとして通している以上、トラフィックやDDoSのテレメトリを取るには当然の実装では」という擁護と、「スクリプトを注入できるなら平文トラフィックの盗み見も技術的には可能」という警戒が並んだ。DNSホスティングと逆プロキシは本来切り離せる話で、注入は後者に付随するという整理も出ている。「JSフリーで作った最後のサイトでも、このCloudflareのスクリプトだけは残っていた」という体験談が複数あり、Cloudflare自身のRUM解説ブログも参照された。

Q. 止められるのか。
A. Web Analyticsの設定で無効化できるが、その設定項目自体が見つけにくいという指摘が繰り返し出ている。

Q. 1.1.1.1の話か。
A. 違う。同じCloudflareでも、パブリックDNSリゾルバではなく従来からあるDNSホスティング側の挙動である。

HNでは「YC Startup Schoolのクレジットをもらって現金化する導線が成立している」という指摘や、「勤務先のクレジットを流しているのでは」という疑いが出た。安すぎるトークンの動機として、推論トレースを蒸留用データとして回収しているのではという推測も複数あり、実際に米国モデルの提供を停止した中継業者の例も挙がっている。中国ではこの規模が桁違いだ、という声もあった。

使い切れない枠の融通は個人間では自然な行為に見える一方、いずれの経路も提供元との契約違反であり、入力が第三者に渡るプライバシー上のリスクも同時に負う。

賛成側は「LLMやエージェントから良い結果を出している人にはマネジメント経験者が多い」という観察を挙げた。反対側は「それはleadershipではなく単なるmanagement、あるいはただのコミュニケーションで、要件収集も他者への作業説明もソフトウェアエンジニアが以前からやってきたことだ」と切り返している。「自分の頭の使い方はコーディング時と全く同じで、作るものの心的モデルに深く接続している」「むしろ同僚とのホワイトボード議論に近い」という別の比喩も出た。「企業ポエム的な嘘つきを管理している感覚だが、それでも安く十分に使えるので手放せない」という辛辣な評もある。

人の管理との同型性を認めると委譲の粒度や検収の設計が流用できる一方、LLMは学習も昇進もせず信頼を蓄積しないため、人間相手の前提をそのまま持ち込むと外れる。記事自身も「LLMの管理は人間の管理とは違う」と述べており、そこが結論と矛盾するという批判を受けている。

クラウド実行は環境構築とリソースの分離が容易で並列度を上げやすい反面、巨大リポジトリではチェックアウトや依存解決の初期コストが毎回のしかかる。ローカルworktreeはキャッシュを共有できるぶん立ち上がりが速く、この初期コストの差が判断の分かれ目になる。

エージェント向けブラウザという発想はCloudflare単独のものではなく、同じ日のGitHub Trendingにもログイン済みブラウザ状態をCodexやClaude Codeと共有する`citrolabs/ego-lite`が入っている（本レポートのOSS RANKING参照）。

透かしは大量の自動生成を機械的に選り分けるには有効だが、書き直し・翻訳・別モデル通過で容易に失われるため、個別の文書に対する「AI製である」の証明には使えない。逆に「透かしが無い＝人間が書いた」とも言えず、判定材料としては非対称である。

Q. なぜ都度確認を増やすと危険なのか。
A. 確認の頻度が上がるほど中身を読まずに承認する率が上がり、本当に危険な操作だけが素通りする状態に近づくため。

常駐エージェントのコストは会話の長さに対して線形ではなく、毎ターン過去全体を送り直す実装だと二次的に効いてくる。プロンプトキャッシュが効くかどうかで請求額の桁が変わる。