今日の収穫、3行で。

賛否がはっきり割れている。肯定側は「アクセス制御をプラットフォーム側が全部持つ設計が良い」「Codex/Claudeアプリの正面からの競合で、Cloudflareが自社インフラを売る導線として筋が通っている」と評価。Kenton Vardaの主張は『全員が自分のコピーを動かすので、欲しい機能はその場でエージェントに足させればいい。SaaSでは原理的にできなかったことがAIで可能になった』というもの。否定側で最も多いのは命名への苛立ちで、「OSじゃないだろ」「コネクタ付きチャットボットに大げさな名前を付けるな」という声が上位を占める。実務側の懸念も鋭く、『問題はエンドユーザーが機能を足せることではなく、12人が各自カスタマイズした結果、誰も互いの出力を読めなくなること（SharePointで見た光景）』という指摘や、「Cloudflareのロックインが怖い」「共有のクラウドLLMを強制されると自分のプロンプトやスキルで差別化できなくなる」という反発がある。実際に試した人からは、Free planでは動かず Dynamic Workers（Workers有料プラン）とR2が要る、という報告も上がっている。

「セキュアなサンドボックスがあるからAIに自由にコードを書かせても致命傷にならない」という設計思想は、リモートサンドボックス論（本レポートs04）と同じ方向を向いている。一方で、Cloudflareが最近『自社インフラと密結合したOSS』を連発している（EmDash CMSに続き本件）点は、OSSの体裁を取ったロックインではないかという見方も出ている。

Q. 定着するSkillとしないSkillの違いは何か。
A. 定着側に共通するのは、①呼び出し頻度が高い、②手順が安定していて毎回ほぼ同じ、③出力の正しさをその場で判断できる、の3点。逆に「たまにしか使わない」「毎回状況判断が要る」作業は、Skillにしても結局プロンプトで書き直すことになり捨てられていく。

Q. 社内で1位になったSkillは何が効いたのか。
A. 資料によれば、特定の誰かの職人技ではなく、全員が毎日ぶつかる定型の詰まりを解いたこと。ツールとしての完成度より「配った瞬間に効果が体感できる範囲の狭さ」が普及を決めている。

HNのコメント欄は記事より辛口で、実装経験者ほど懐疑的なのが特徴。最も鋭い反論は『これはハーネスではなくエージェント的ワークフローのビルダーだ。しかも著者自身が「これが大抵のケースで機能する証明は本稿にはない」と書いている』というもの。技術的な指摘としては、①LLMは必要以上に細かくタスクを分割しがちで、木を見て森を見なくなる、②JSONを強制的に往復させるとフロンティアモデルでも精度が落ちる、③そもそもDAGに縛らずREPLループにツールを関数として注入した方が、ループも早期脱出も書けて自由度が高い、という3点が繰り返し挙がった。オーケストレーションを自作した複数の参加者が『プランナー・メモリ・ログ・サブエージェント・グラフはどれも単体では魅力的に見えるが、互いに絡み合っていて、結局すべてがメインのコンテキストウィンドウにオーバーヘッドとして乗る』と証言している点は重い。一方で建設的な派生案として、『批評役（critic）を各段階に置き、issue → plan → pull request という成果物単位でしか次に進めない設計にしている』という実装例も共有された。「ベンチマークはあるのか。効果がありそうな施策が交絡で逆効果になるのはハーネス開発ではよくある」という要求が、この分野の現状をよく表している。

ハーネスを厚くするほど賢くなるという直感に対し、コメント欄の実務者は「LLMを使わない部分をどこに置くか」と「結果の検証をどう機械化するか」の方が効くと主張している。個人の生産性が上がったハーネスをチームに配ると、暗黙の前提（ディレクトリ構成・権限・命名規則）が壊れて逆効果になりうる、というZenn側の指摘とも整合する。

ローカル実行派は「サンドボックス越しでは開発体験が落ちる」と主張し、リモート隔離派は「エージェントが読む外部コンテンツは全部が信用できない入力なのだから、権限の方を落とすしかない」と反論する。Claude Code側も v2.1.222 で worktree 隔離セッションがメインチェックアウトに破壊的gitコマンドを撃てる問題を修正しており（本レポートのRELEASE WATCH参照）、隔離の粒度はツール側でも現在進行形で詰められている。

プロンプトインジェクションの厄介さは、攻撃コードがコードとして存在しない点にある。ペイロードは単なる日本語や英語の文章であり、静的解析にも署名照合にも引っかからない。だからこそ「入力を検査する」ではなく「実行できる範囲を狭める」方向の対策が主流になりつつある。

最も繰り返された疑問は「なぜどの会社も既存エージェントと連携せず自前で作り直すのか」。課金面の指摘も具体的で、『多くの開発者がClaude CodeやCodex CLIを使う最大の理由はサブスクで従量課金を避けられるからで、Warp Agentではそれができないのでは』という声が上位に来た。差別化についても『「他にできないことをやるCLIエージェント」と書いてあるが、製品説明を読んでも独自な点が見当たらない』と手厳しい。既存ユーザーの不満は一貫していて、「ただのターミナルだった頃のWarpは好きだったが、AI寄りになるほど本体のターミナル機能がバグりだしてWezTermに戻った」「先日はlsがAIコマンドと解釈されて実行できなかった」「最近のWarpは重い」といった証言が並ぶ。cloud agent handoffについては『サードパーティのバイナリなしでSSH先に対してエージェントを走らせられると宣伝しているが、ではcloud agentはどう動くのか。自社バックエンド経由でシェルを通しているならまずいのでは』という技術的な突っ込みも出た。擁護派は「AI機能はオフにできる」「失敗したコマンドを賢く直してくれる機能は他で代替できない」と述べている。

Q. worktreeを分けるとエージェント運用の何が変わるのか。
A. 1本のブランチを共有していると、片方のエージェントがビルドやテストを走らせている間もう片方が待つか、作業ツリーを壊す。worktreeを分ければ物理的にディレクトリが別なので、同じリポジトリのまま完全並列で走らせられる。Claude Code側も v2.1.222 でworktree隔離の穴（メインチェックアウトへの破壊的git操作）を塞いでいる。

Q. 委任が偏るとなぜ困るのか。
A. 特定のサブエージェントに仕事が集中すると、そのエージェントのコンテキストだけが膨張して精度が落ち、他は遊ぶ。並列化の投資が回収できないうえ、偏った側が失敗すると全体が止まるという単一障害点にもなる。

コスト削減の打ち手は大きく3つに分かれる。①測る（cclensのように何にトークンが消えたかを可視化する）、②キャッシュの持ち方を変える（keepaliveの間隔を最適化すれば同じ効果を1/8のコストで得られるという主張）、③そもそも読ませない（全文をコンテキストに載せず検索層を挟む）。効果が大きい順は普通③→②→①だが、①をやらないと②③の効果が測れないので順番は逆になる。

プロンプトキャッシュは書き込みが読み出しより高い課金体系のため、「キャッシュを維持するために定期的に叩く」運用は、間隔を間違えると素直に毎回書き直すより高くつくことがある。8倍という数字はこの間隔設計の失敗コストを指している。

この手の「定義から目次を生成する」仕掛けは、手で書いた一覧が必ず腐るという経験則への対策である。同じ発想はSKILL.mdやAGENTS.mdの管理にも効き、frontmatterを構造化しておくほど後から機械が読める余地が増える。

非エンジニアに配る際の対立軸は「許可リストを厳しくして安全側に倒す」か「許可プロンプトを減らして体験を優先する」か。前者は使われずに終わるリスク、後者はs04で見たようなプロンプトインジェクション由来の事故リスクを負う。実際の落としどころは、読み取り系を広く許可し、書き込み・ネットワーク・破壊的コマンドだけを個別承認に残す構成になることが多い。

E2BIG（Argument list too long）はLinuxで古くからある制限で、execve に渡せる引数＋環境変数の総量にカーネル側の上限がある。`xargs` が存在する理由そのものであり、シェルスクリプトで `find ... | xargs` を書く習慣はこの制限への回避策として広まった。

Q. なぜ指示書が4日で腐るのか。
A. 指示書に書いた前提（ファイル構成、依存バージョン、未修正のバグ、他のPRの進行状況）は、自分や他のエージェントが作業するたびに変わる。書いた時点では正しかった内容が数日後には実在しないファイルを指しており、エージェントは疑わずにその前提で完走してしまう。

Q. 1問1答方式は何が違うのか。
A. まとめて質問させると、モデルは自分で埋められそうな空白を勝手に埋めて質問を省く。1ターン1問に制限すると、回答を見てから次の問いを決めるので、曖昧なまま実装に進む経路が塞がれる。

推進側は「禁止しても検出できないのだから、開示と責任の所在をルール化する方が現実的」と主張する。抵抗側の論点は品質ではなく動機で、趣味コミュニティにとってコードを書く行為そのものが目的なのに、成果物だけを差し出す参加者が増えるとレビュー負荷だけが一方的に増える、という構造を突いている。

コメント欄は同意と反論が半々。最も本質的な同意は『webhookはat-least-onceでもat-most-onceでもなく順序保証もない。データが本当に大事ならUDPのようなベストエフォート配送として扱うしかない』というもの。実害報告も具体的で、StripeやQuickBooksのAPIで「作成時にエラーが返るのに実際には作られている」ため毎回確認が必要になった、という証言が並ぶ。一方の反論は2つ。①提案されているフィード方式は要するに差分の突き合わせ（incremental reconciliation）であって新規性はない、②pushをpullに変えると「データが変わったかどうか」を知る手段が消えるので、消費側は悲観的にポーリングし続けることになる、という指摘だ。『カーソルはプロバイダから見ればどのイベントを指すのか。結局タイムスタンプへの対応表という外部状態を管理することになる』という設計上の突っ込みもある。webhook配信サービスSvixの中の人からは、FIFOエンドポイント・ポーリングエンドポイント・ストリームという3方式を用意して用途ごとに選ばせている、という実装解が共有された。

エージェントに実装させる前提だと、DDDの価値は「実装パターン集」から「意図を伝える語彙」へ移る。境界づけられたコンテキストやユビキタス言語は、人間同士の合意形成のためのものだったが、いまはエージェントへの指示の粒度を決める道具としても機能する。逆に、エンティティや値オブジェクトといった実装パターンだけを模倣させると、コード量だけが増える結果になりやすい。

HN側の批判記事（3,300語）へのコメントは擁護より反発が優勢だった。最も多い反論は『5か月前にLLM開発への態度を決めて、それ以降の現実を見ていない人の文章に読める』『フロンティアモデルを使える予算のない組織にいるのでは』というもので、記事中のMonoフレームワークの誤りの例も「今のモデルならReactでもSwiftUIでもUnityでも問題なく書ける、それで良いコードが出ないならスキルの問題だ」と切り返されている。逆に評価する声は『単純で肥大したエンドユーザーアプリを作るだけでなく、コードを掘って性能最適化まで踏み込む人だからこそ、AIが全部は書けないことに気づいている』という点を挙げる。コスト面の記述は反対派にも支持されており、『前職では月20ユーロのプロファイラのライセンス更新を毎年戦って勝ち取っていたのに、今は非プログラマまで全員がClaudeのサブスクを持っていると聞いた』という一節が「過小評価されている名言」として引用された。「自分の専門分野についてAIは常に間違ったことを言う。幸い、よく知らない分野については常に正しい」という皮肉のツイート引用も添えられている。

Poloniusという名前はハムレットの登場人物に由来し、借用チェックを「制御フローグラフ上の位置」ではなく「ライフタイムの集合」として捉え直す設計を指す。Rustの借用チェッカーはこれで3世代目にあたり、初代のAST基準、2代目のNLL、そして今回のPoloniusと、いずれも『安全なプログラムを誤って拒否する』範囲を狭める方向で進化してきた。

HTMLのパースは「壊れた入力でも必ず何らかのDOMを作る」ことが仕様で義務づけられている稀な言語仕様である。XMLがエラーで停止するのに対し、HTML5は現実のWebに存在する不正なマークアップの扱いまで含めて完全に規定した。`<p>`の自動クローズはその復旧規則の一例にすぎない。