今日の収穫、3行で。

肯定側の中心は「独自プロトコルを持ち込んだのは初期MCPの最大の失策だった。ただのHTTPになるのは良い」「v1のステートフル設計はデプロイに永続化層を要求する不親切なものだった」という、ステートレス化への安堵。progressive discoveryには「遅すぎる。自分は既に複数ハーネスでMCPの遅延ロードを実装し、今は全部code modeに移行中だ」という先行者の声もある。懐疑側は「REST+skills.mdよりMCPが楽な理由が未だに分からない」「HTTPの全機能をMCPに再実装する必要はない。最小限しか使わない」と根強く、セキュリティ製品の開発者は「URLを渡すだけで自己記述・認証込みで動く夢を見たが、初日から仕様が転々とし、コンテキストを食う機能になった」と失望を語る。認可の再設計については「これを全部実装するMCPサーバーがどれだけあるのか」という実装コストへの疑問と、「購入はできるが決済だけ人間承認のゲートに置く、のような特権操作の承認は可能か」という具体的な要望が出た。廃止されるsamplingには「Claude Codeのような囲い込み環境で持ち込み推論に使えたはず。面白さが実用性を上回った機能だったのかもしれない」という惜しむ声がある。

Q. 自分のMCPサーバーは何を変える必要があるか？
A. ステートフルなセッション前提の実装を持っているなら、HTTPワークロードとして水平スケール可能な形（セッション状態を外部化するか持たない）へ寄せる方向がロードマップの意図。samplingに依存していれば代替が必要。

Q. progressive discoveryはツール定義がコンテキストを食う問題への答えか？
A. そう位置づけられている。全ツールを最初に列挙せず、会話の流れに応じてカタログを段階開示する。HNには既にハーネス側で遅延ロードを自前実装している人がおり、仕様側が追いついた格好。

検証派は「証拠はモデルにeffortを訊いた回答だが、モデルがそれをどう知るのか」「推論トークン予算の設定はハーネス側なので、エージェントは自分がどのモードかを見えていない。答えが間違うのは当然」と、主張の根拠そのものを疑う。体験談派は「設定ファイルを更新するだけの指示で、4.6なら2分の仕事をOpus 5は43分かけてコンテナを引きテストスイートを作った」「サブエージェントが些細なタスクに異常なトークンを使う」と、むしろ過剰努力の方を問題にする。実利派からは「Opus対Sonnetのコスト差の大半はOpusが饒舌なせいなので、Sonnetに落とす代わりにOpusのLow reasoningを使ったら同等コストで品質が上がった」という設定の知見。構造批判として「なぜ運営者が完全に制御する曖昧な単位（トークン）で課金を許しているのか。入力を渡した時にいくらかかるか分からない」という指摘が支持を集めた。

疑惑を支持する側は「使用上限のラバーバンドやバックエンドでのモデル切替を含め、最適化のインセンティブが強すぎる」と見る。反対側は「単純なタスクでthinkingをextra highに置きっぱなしにするのは利用者の誤りで、それを運営側が直そうとしているだけ」と解釈する。どちらの立場でも共通するのは、effortが誰の手でいつ決まるかが利用者から見えないという不満で、A/Bの真偽より可視化の欠如が本質的な論点になっている。

Q. AGENTS.mdは無視されるということか？
A. この実測ではAGENTS.mdを置いただけでは入力トークンが増えていないので、少なくとも自動読み込みの対象にはなっていない。CLAUDE.mdから明示的に参照させるなどの経路が別途必要になる。

Q. 7110トークンは大きいのか？
A. 指示書の分量そのものに比例するので絶対値は環境次第だが、毎ターンの入力に乗り続ける固定費である点が重要。CLAUDE.mdは短く保ち、詳細はskillやメモリに逃がす設計の裏付けになる。

入門記事は「まず1つ書いて、使いながら直す」という育成型の立場で、最初から体系を作らないことを勧める。一方pdlc-skillsは複数スキルの噛み合わせを先に設計する体系型で、スキル間の入出力と責務の境界を決めてから書く。前者は立ち上がりが速いがスキルが増えると重複や矛盾が出やすく、後者は初期コストが高いがスキル間の依存を追いやすい。数が10を超えるあたりで前者から後者へ移行する必要が出るのが実務上の落としどころになる。

Q. 確認ポイントを4つに絞る根拠は？
A. 無人運用で実際に起きた取り違えのうち、後から取り返しがつかないものだけを残す方針。可逆な判断は止めずに事後レポートで見る、という線引きが前提になっている。

Q. 意図確認レイヤーとガードレールの違いは？
A. ガードレールが「してはいけない操作」を機械的に弾くのに対し、意図確認レイヤーは「ユーザーがそれを本当に望んでいるか」を人間に問い返す層。前者は禁止、後者は要件の曖昧さの解消を担う。

一括置換による大量削除は、置換対象の文字列が意図より広くマッチするか、空文字列への置換が意図せず走ったときに起きやすい。Claude CodeのEditツールがold_stringの一意性を要求するのは、まさにこの種の事故を構造的に防ぐための設計で、`replace_all` を明示しない限り複数箇所には触れない。

按分する側の言い分は「合計は合うし、ダッシュボードに空白ができない」。按分しない側は「曖昧な部分を曖昧なまま残す方が、後で『どのタスクが高いか』を問い直したときに嘘をつかない」と見る。前者は報告向き、後者は改善向きで、目的が集計か原因特定かで選択が変わる。前日のダイジェストで扱った「ハニーポットのコストが5倍に跳ねた77日間」の実測記事と同じく、金額を綺麗に見せるより構造が見える形で残す流れにある。

Q. Harness EngineeringとLoop Engineeringは何が違うのか？
A. Harnessはモデルの外側に置く道具立て（ツール定義・権限・メモリ・フック）の設計、Loopはモデルが行動→観測→修正を回す1周の構造と停止条件の設計。前者が静的な環境、後者が動的な制御に対応する。

Q. RAGはエージェント設計の中でどこに位置づくのか？
A. ツールの一種として扱われる。エージェントが必要なときに検索を呼び、結果をコンテキストに入れる形で、初期の「全部RAGで解く」構図からは後退している。

最も具体的なのは「セルフホストのCursorを探して数週間、Proliferate・OpenHands・Opencode Manager・Paseoを試した。ProliferateはPCで動かしてMac/iPhoneから操作するのが上手くいかず、ドキュメントも分かりにくかった。Paseoは簡単に動いた」という比較レビュー。「各ハーネスは自分の認証とサブスクリプションを保つのか、それとも最終的にリクエストがあなたのサーバーを経由するのか」という、課金経路への質問も鋭い。「opencodeは既にほぼ全モデル・全プロバイダを扱える。その上に層を足す意味は」という根本的な問いと、「コーディングエージェントのツール／ハーネスを網羅する索引が欲しい。awesome listはどれも不完全」という嘆きが並ぶ。Workflows機能には「いただき」と好意的な反応があった。

Q. ConnectはgRPCの代替なのか？
A. gRPCのサービス定義（protobuf）とワイヤ互換を保ちながら、HTTP/1.1やプレーンなJSONでも呼べるようにしたプロトコル群。gRPCサーバーと相互運用でき、ブラウザやCloudflare WorkersのようにHTTP/2のトレーラーを扱いにくい環境で利点がある。

Q. HTTP/2が必須なのはgRPCのどの部分か？
A. ストリーミングとトレーラー（レスポンス末尾のステータス伝達）。単項RPCだけならHTTP/1.1でも成立するが、gRPC本来の実装はトレーラーに依存しているため、プロキシやブラウザで詰まりやすい。

最も支持されたのは「ローカルモデルが馬鹿に感じるとき、原因は量子化ではなくチャットテンプレートであることが多い。GGUFの多くがメタデータからテンプレートを落としており、ランタイムが黙ってchatmlにフォールバックする。モデルは普通に喋るので誰も気づかないが、明らかに馬鹿になる」という実務者の指摘。KVキャッシュの量子化にも「q8_0なら大丈夫だと思っていた」と驚く声があり、「KVキャッシュは量子化しない、重みは入手できる最良のQ8以上しか使わない。遅くても正確さを取る」というルールを掲げる人もいる。ツール呼び出しについては「NVFP4とAWQ W4A16はツール呼び出しを正しく閉じられなかったという記事の指摘は、llama.cppなら文法強制があるので起きない」という補足がある。Qwenのリバースエンジニアリング記事には「最初の鍵は署名チェックを通ったがハッシュが合わなかった。多くのモデルはそこで完了宣言するが、Qwenは不一致を自分で指摘して続けた」という点を評価する声と、「真偽が明確に判定できるタスクは『最も難しい実タスク』ではない。AI支援で最も伸びるのがそういうタスクだ」という冷静な反論が並んだ。「今後はフロンティアモデルがスキルや入力を生成し、『十分良い』ローカルモデルが日常の問題を解く構図になる」という見立ても出ている。

Q. Claude Codeからローカルモデルを使うと何が変わるか？
A. トークン課金と使用上限から解放される代わりに、ツール呼び出しの信頼性とコンテキスト長が下がる。Zennの手順記事はOllama経由の接続を扱っており、HNでは「Anthropicが品質を勝手に落とすより自分で制御できる方がいい」という動機が語られている。

懐疑側の代表は「各リポジトリにreports・plans・code-reviewsフォルダを置いてmdを入れておけば、gitと一緒にクラウドに上がる。ローカルのエージェントがgrepで探す。MCPも専用サーバーも要らない」という自前運用と、「Obsidianのvaultと番号体系（Johnny.Decimal）で『23.16にある』と言えばClaudeが即座に見つける。`cd 23.16 && claude` でコンテキストも分離できる」という実例。技術的な問いとしては「複数エージェントが同じ文書を同時に触るのをどう防ぐか」「LLMが生成した文章を大量に圧縮すると精度が落ちる問題に解はあるか。SOTAでも要約で意味を歪める」が核心を突いている。「ランディングページを開いた瞬間『AI製ページで中身はない』モードに入った」という辛辣な感想もあった。肯定側は「自分でつぎはぎしていたものが全部入っている。市場適合性には+1」「エージェントの出力の継続性に真面目に取り組む試みは重要な層になる」と評価する。

共有知識を専用サービスに置く立場は、複数エージェント・複数人が同時に使う場面での一貫性と検索を売りにする。対してリポジトリ内のmdに置く立場は、gitの履歴・レビュー・権限をそのまま使えることと、依存を増やさないことを重視する。前者は組織横断の再利用で効き、後者は単一リポジトリの範囲では十分に機能する。分かれ目は、知識がリポジトリをまたぐかどうかにある。

Q. なぜAIコーディングでファイルシステム性能が問題になるのか？
A. エージェントは人間より桁違いに多くのファイル走査・grep・git worktreeの作成を短時間に行う。小さなファイルの大量アクセスはAPFSが不得意とする領域で、並列エージェントではそれが積み上がる。

Q. ストレージが3分の1になった理由は？
A. 記事タイトルからは詳細が読み取れない。Linux側でnode_modulesや依存キャッシュの共有・重複排除が効いた可能性が高いが、これは推測で、記事本文での確認が必要。

Q. なぜエラーが出ないのか？
A. エージェントはツール呼び出しが失敗しても言語で言い繕って次に進める。プロセスとしては正常終了なので、exit codeやログにも痕跡が残らない。失敗が「発生」ではなく「不在」として現れる。

Q. 対策の基本形は？
A. エージェントの自己申告を信用せず、成果物（ファイル・コミット・レスポンス）の存在と内容を外側のスクリプトで検証する。winnowのvalidate.mjsやfinalizeのように、機械的なチェックを工程に固定するのが同じ発想。

Linuxカーネルのコミットには、AI支援を使った場合にその旨を明記する慣行が議論されてきた。Torvalds自身のコミットにAI利用が書かれたことで、「使うこと」ではなく「使ったことを記録すること」が上流の作法として定着しつつある。

Kagiは広告を載せず利用者の月額課金だけで運営しており、検索結果のドメインごとに「上げる／下げる／除外」を利用者が設定できる。ペイウォール除外はそのドメイン単位の制御を、ペイウォールという属性単位に広げた形になる。

Q. 普通のRust入門記事と何が違うのか？
A. 入門記事は人間が読む前提で章立てされるが、このファイルはAIに渡して対話的に教えさせる前提で書かれていると推測される。読者の理解度に合わせて説明の深さを変えられる点が、静的な記事との違いになる。