今日の収穫、3行で。

大作型は「毎回同じ説明を繰り返さずに済む」利点がある一方、全エージェントの全ターンに載る固定コストであり、内容が古びたときに誤った前提を配り続けるリスクを負う。最小型は陳腐化に強く読み飛ばされにくいが、プロジェクト固有の不変則をどこに置くかという受け皿を別に用意する必要がある。分量そのものより「毎ターン読ませる価値があるか」で線を引くのが両記事の共通した含意になっている。

Q. CLAUDE.mdに書いた内容は毎回のリクエストでコストになるのか。
A. システムプロンプト相当として毎ターン投入されるため、記述量はそのまま入力トークンとして継続的に効いてくる。ただしプロンプトキャッシュが効く範囲では2回目以降の単価が大きく下がるので、頻繁に書き換えるほど不利になる。

Q. 書くべきものと書かなくてよいものの境界はどこか。
A. リポジトリを読めば分かること（ディレクトリ構成、既存の実装パターン）は重複であり、読んでも分からない不変則（触ってはいけない領域、確認が必要な操作、プロジェクト固有の禁則）が本来の対象になる。

解説が対応するv2.1.220の1つ前、v2.1.219でClaude Opus 5（claude-opus-5）が既定のOpusモデルになり、1Mコンテキストとfast modeに対応した。同じリリースでsandbox.network.strictAllowlist（許可リスト外のホストを確認なしで拒否）とDirectoryAddedフック（/add-dirで作業ディレクトリが増えたときに発火）も追加されている。設定解説を読むときは、対象バージョンがこの前後どちらかを確認する価値がある。

コメントの大半が「herdrやagent-deckと何が違うのか」という既存実装との比較要求に費やされた。自前のエージェントサンドボックスを作った参加者は、類似する36のプロジェクトを一覧するサイトまで作ったと述べており、この領域が完全に飽和していることを示している。一方で「Claudeにはhook APIがあるので、承認待ちになったらtmuxウィンドウを点滅させたり前面に出したりする通知は自分で書ける」という、専用ツールを入れずに済ませる指摘も出た。

束ねる側のツールは、状態の可視化（どれが待っているか）と衝突の防止（同じファイルを同時に触らせない）という別々の問題を扱っている。TUI系は前者だけを解き、マージキュー系は後者だけを解くため、両方必要なら組み合わせるか、hookで自作するかの判断になる。乱立の裏返しとして、どれもまだ標準になっていない以上、乗り換えコストの低い薄い層を選ぶのが無難といえる。

Q. MCPサーバーがステートレスだと何が嬉しいのか。
A. セッション状態をサーバー側に持たないほど、複数インスタンスへの水平展開やサーバーレス環境への配置が容易になる。接続が切れても状態復元の手当てが要らないぶん、エッジやWorkers系のランタイムに載せやすくなる。

Q. 既存のMCPサーバーはすぐ移行が必要か。
A. 仕様更新から日が浅く、記事も検証段階のものなので、まずは自分のサーバーがステートフルな前提に依存しているか（セッションIDに紐づく状態を持つか）を確認するのが先になる。

状態を外部ファイルに置く方式は、コンテキスト消失に強い代わりに「ファイルが真実である」ことを維持する責任が生まれる。エージェントが更新を忘れた瞬間に、次の実行は古い前提で走り出すため、更新を仕組みで強制する（終了時フックで書かせる、更新のないまま次の実行を始めさせない）ところまで含めて初めて機能する。失敗パターン側の記事は、まさにこの「書いたつもりで書かれていない」系の事故が中心になる。

実務上の被害として最も多く挙がったのはプロンプトキャッシュの喪失で、「みんなのキャッシュが飛んだ」という嘆きが上位に並んだ。復旧手段としては「Opus 5で529が頻発したのでFable 5に切り替えたら動いた」というモデル単位のフォールバック報告があり、同一プロバイダ内でも切り替えが効く場合があることを示している。「モデルは優れているが稼働率は競合中で最低」という評価や、サブスクリプションを他社と分割する検討も出た。

エージェント運用ではキャッシュヒットを前提にコストを見積もるため、障害の実費は「止まった時間」より「温まったキャッシュを失った再構築コスト」に出る。複数プロバイダを並べる冗長化はコストと設定の複雑さを招くが、この日のように数時間単位で作業が止まる事象が続くなら、少なくとも切り替え手順だけは用意しておく価値がある。

rulesyncのようなツールが必要になる背景には、AIコーディングツールごとに設定ファイルの名前と置き場所が違うという事情がある。同じ「このプロジェクトの規約」を伝えるだけでも、ツールを3つ併用すれば3か所に同じ内容を置くことになり、片方だけ更新して食い違うのが典型的な事故になる。生成元を一つにして各ツール向けに配布する発想は、dotfiles管理でおなじみの手法をAIツール設定に持ち込んだものといえる。

planモードは「実装前に合意を取る」ための仕組みだが、合意の対象が曖昧なまま計画だけ長くなると、承認の儀式に変わってしまう。モードを外す判断が成立するのは、受け入れ条件と検証手段が先に決まっている場合に限られ、そこが曖昧なまま外すと単に確認なしで走るだけになる。記事の主張を採るかどうかは、自分の作業で「何をもって完了とするか」が事前に書けているかで決まる。

「unhobbling」はもともと、モデルの素の能力に対して足枷（hobble）を外すだけで大きな性能向上が得られる、という議論で使われてきた語にあたる。ツール提供、長い思考時間、外部メモリのような足回りの整備が該当し、モデル自体を作り直さなくても実効性能が上がる領域を指す。エージェントハーネスの仕事の大半がここに属すると考えると、機能追加より制約の除去を優先する主張は一貫している。

最も強い反論は「複数モデルに同時に投げる時点で入力トークンを重複して払っており、入力が支配的な用途では逆に高くつく」というもの。モデルが軌道に乗ったと判定できる時点で入力はすでに送信済みだ、という指摘が繰り返された。ベンチマーク結果の読み方についても、優位なのは一部のタスクだけで、他は「安いが精度が低い」か「高精度だが高価」に落ち着いているのではという疑問が出た。新モデルが出るたびにルーティング規則を再学習する必要があるのでは、という運用面の質問もある。

モデル選択によるコスト最適化は、キャッシュ設計と競合する。キャッシュヒットを最大化する戦略は「同じモデルに同じ前置きで投げ続ける」ことなので、動的な切り替えとは原理的に相性が悪い。長い連続作業ならモデル固定＋キャッシュ、単発で重い推論なら切り替え、と用途で分けるのが妥当な落としどころになる。

Q. プロンプトキャッシュはどれくらい効くのか。
A. 議論の前提として、キャッシュヒット時の入力コストは約9割減として扱われている。エージェントのように同じ文脈を積み上げて何十回もツールを呼ぶ形式では、総コストのうち入力側の比重が大きいため影響が大きい。

Q. コストを測るとき何を単位にすべきか。
A. コメントでも指摘されたとおり、リクエスト単価ではなく「完了したタスクあたりの費用」で見る必要がある。安いモデルが失敗してやり直す分やエラー再送を含めなければ、比較として成立しない。

生成と評価を分ける効果は、モデルが自分の出力に引きずられる傾向を断ち切れる点にある。ただし分離のコストは無料ではなく、評価役に十分な文脈を渡す手間と、往復ぶんのトークンが増える。全工程で分けるのではなく、間違いが後段まで波及する箇所（設計判断、完了判定）に絞って分離するのが現実的な落とし所になる。

コメントの多くは作品として楽しむ反応で、実際に自分のClaudeやChatGPTに読ませた結果の共有リンクが並んだ。「ChatGPTでは特に何も起きなかった」という報告もあり、モデルや経路によって効き方が違うことが観測されている。上位コメントには、ページ内の指示に素直に従いかけたエージェントの出力そのものが引用されており、指示と情報の区別がついていない様子が見て取れる。

この種の攻撃が成立するのは、LLMにとって「システムからの指示」と「取ってきたページの本文」が同じテキスト列として届くからにあたる。防御側の基本は、外部から取得した内容を指示として解釈させない枠組み（取得結果を明示的にデータとして囲む、ツール実行の権限を分ける）を用意することで、モデルの賢さに期待して解決する種類の問題ではない。

テキストのやり取りだけでレビューを回すと、指摘の対象箇所が曖昧になり往復が増える。HTMLとして描画したうえで該当箇所にコメントを刺せる形式は、この曖昧さを消す代わりに、成果物を常にレンダリングして配る手間を足すことになる。図表や画面を含む成果物では前者の利得が大きく、短い差分では素のテキストで足りる、という使い分けになる。

レビューをやめる判断は、検証を捨てることと同義ではない。人間が全差分を読む方式から、テストと型と静的検査が落とす方式へ重心を移すという話であり、移す先が用意されていない状態で読むのをやめれば単に無検査になる。CodeGraphの記事が示すのは、道具を入れる前に「何に時間を使っているのか」を測らないと、効く場所を外すという一段手前の問題になる。

Q. 全部読まないとして、何を読むべきか。
A. 元に戻しにくい変更（データ移行、外部への公開、権限や課金に触る箇所）と、テストで落ちない種類の欠陥（設計の妥当性、仕様の取り違え）にあたる。機械が判定できる部分は機械に任せ、人間は判断が要る箇所に集中する形になる。

Q. レビューの時間がどこに消えているかはどう測るのか。
A. CodeGraphの記事の教訓がまさにこれで、指摘の種類別に件数と所要時間を記録するところから始める。見落とし対策の道具を入れても、実際の遅延要因が仕様確認の往復なら短縮しない。

「フロンティアラボはすべてをAPI呼び出しに変換する方向を推している（Claude Coworkが必須とするChrome拡張がその例）のに対し、記事は人間と同じ画面操作を鍛える方向を主張している」と論点を整理するコメントが支持を集めた。「10年ごとに誰かがボトルネックはモデルではなくマウスだったと再発見する。APIはまさにこの問題を避けるために作ったのに、AIにはそれを無視してインターンのようにボタンを押させている」という皮肉も上位に入った。ベンチマークのサンドボックスが甘く、エージェントが本来遮断されるべき経路で近道しているのではという指摘もある。

API方式は速く確実だが、APIのない画面には手が出ず、提供側の都合で壊れる。画面操作方式はどこでも動く代わりに遅く不安定で、UIの些細な変更で崩れる。実務では業務システムのようにAPIが存在しない領域が残り続けるため、どちらかが勝つというより、対象ごとに使い分ける形に落ち着く見込みが強い。

CHERIは capability（能力）をポインタに埋め込む方式で、ポインタが指せる範囲と操作の種類をハードウェアが検査する。CやC++のコードをほぼそのまま使いながら、境界外アクセスや解放後利用をハードウェアが弾けるのが利点にあたる。CHERIoTはこれをマイクロコントローラ級に縮めた版で、Rustのように言語を移行できない組み込み領域での対策として位置づけられている。

創始者の人柄を規範の根拠にする方式は、立ち上げ期には強力に働く。ただしその人がいなくなったとき、あるいはその人自身が問題を起こしたときに、規範ごと崩れる脆さを抱えることになる。明文化された行動規範と運用体制へ移す作業は地味で摩擦も大きいが、コミュニティが個人より長く続くことを前提にするなら避けて通れない。