今日の収穫、3行で。

HN では論文の結論が体験と一致するという声が多数。「CLAUDE.md に強い指示（長いコメントを書くな、既存機能を使え）を明示的に置いているのに、実タスクでは驚くほど早く無視される。ところが同じことをタスク中のプロンプトで言うとちゃんと従う」という報告が上位に付いた。技術的な説明として「効率的なコンテキスト管理に最適化されたモデルが、遠くの薄まったトークンに注意を向けると期待する理由がない。playbook を渡せば、モデルは playbook と目の前のタスクのどちらに注意を割くかを選ばされる。段階的に実行させたいなら、手順は一つずつ提示するしかない」という指摘、および 2023 年の "Lost in the Middle" が今も成り立つという言及があった。運用側の回答として、メインセッションは CLAUDE.md の知識で組み立て、コメント抑制のような個別の規律は単一の関心事だけを持つサブエージェントに強制させる、という分業の報告も出ている。

「長文が効かない」の原因をどこに置くかで対処が分かれる。モデル側の限界（量子化・KV キャッシュ・サンプラー）に帰す立場は、1M コンテキストを謳っていても実際に使えるとは限らないと見て、ローカル推論による制御を主張する。設計側に帰す立場は、注意の配分は有限なのだから静的な長文ではなく現在のステップに必要な規則だけを都度提示すべきだと見る。人間の側の類推として「180 ページの就業規則を特別な訓練なしに保持できる人間もいない。賭け金が高ければ人は不作為に逃げ、低ければ規則を無視して最短経路を通る」という指摘もあり、文書量そのものが統治手段として弱いという読み方に落ち着いている。

Q. HANDBOOK.md は何を測るベンチマークなのか。
A. 企業の従業員が日々参照する社内ハンドブックを模し、金融・医療請求・保険・物流・人事の5領域で、内部ツールと外部 MCP サーバーを持つ環境の中で長文規則を守りながらタスクを完了させる能力を測る。

Q. CLAUDE.md は短くすればよいのか。
A. 論文とコメントが共通して示すのは長さではなく提示のタイミングで、現在のステップに必要な規則を都度渡す方が追従率が高い。全部消すのではなく、常時読ませる層と必要時に届ける層に分ける構成が現実的。

MCP のリードメンテナが HN のスレッドに登場し、「リモート MCP サーバーをサーバーレスホストに展開したい層にとって嬉しい変更」と位置づけた。歓迎側の論拠は明快で、「セッションを扱うためのサーバー側の複雑さは、インフラにもチームへの教育にも大きな負担だった」「実際のツール呼び出しはもともとステートレスで、get_my_todos の結果は結局コンテキストウィンドウに戻るテキストにすぎない。サーバー側で状態をいつまで RAM に置くのかという問いに答えがない」。懸念側からは「数日かかるワークフローの監視に使っているので変更が必要になる、代替はあるのか」という具体的な影響報告、および数か月前に HTTP/ステートレスへ移行済みという実践者から「信頼性は上がり問題は減った。ただしサーバーが落ちて復帰したときのタイムアウト挙動が Claude Code で問題になった。失敗時にクライアントがどう振る舞うことを期待するのかを明文化してほしい」という要望が出た。

ステートレス化はホスティングの選択肢と信頼性を得る代わりに、サーバー側で状態を持つ前提の用途（長時間ジョブの購読、チャネル的な通知）を仕様の外に押し出す。設計としては状態を外部ストアに逃がしてツール呼び出しを冪等に保つ方向が素直だが、それは各サーバー実装の宿題になる。HTTP ヘッダで method 名を運ぶ現行の形すら不要で URL に寄せられるのではないか、という更なる簡素化の提案も出ており、プロトコルの表面積を削る流れは続きそう。

Q. 何が変わったのか。
A. トランスポートがステートレスになり、サーバーがセッション状態を保持し続ける前提が外れた。結果としてサーバーレス環境や複数インスタンス構成に MCP サーバーを載せやすくなる。

Q. 既存サーバーは何を確認すべきか。
A. 接続の持続に依存した機能（長時間ジョブの進捗通知など）が仕様変更の影響を受ける。状態を外部に逃がし、失敗・再接続時の挙動を自前で定義しておく必要がある。

HN では著者本人が経緯を説明し、「公開時点でこの脆弱性クラスに対する堅牢な緩和策は存在しない」と明記した点にコメントが集中した。素朴な疑問として「なぜ Word 文書に隠し文字を置けるのか。なぜ AI がそのテキストにアクセスできるのか」「人間のユーザーに見えないものは Copilot に渡す前にフラグを立てるか除去できないのか。ましてその隠し文字を付けたのが Copilot 自身なら」という指摘が並び、モデル側の防御ではなく入力の前処理で切る発想が主流だった。「これが最初の AI ワームなのか、先行事例はあるのか」という問いも立っている。

緩和策の置き場所が論点。入力側で切る立場は、可視性（白文字・隠しテキスト・メタデータ）を基準にモデルへ渡す前にサニタイズすべきだと見る。ただし著者の主張どおり「文脈内で指示と情報を区別できない」ことが原因なら、サニタイズは既知の隠蔽手法を潰すだけで、新しい運び方が出れば同じ穴が開く。出力側で切る立場（生成物に payload を書かせない、生成文書を再検査する）と組み合わせないと伝播は止まらない。

Q. ワームと呼べる理由は何か。
A. 改変された出力文書に攻撃プロンプトが白文字で埋め込まれ、その文書を別の利用者が Copilot に読ませると同じ改変が再生産される。通常の共有・編集フローが感染経路になる。

Q. 自分のエージェントで何を確認すべきか。
A. 外部から来る文書・ページ・ツール出力を指示として解釈しうる経路の洗い出しと、生成物に指示文が混入しないかの検査。可視テキストのみを渡す前処理も有効だが、それだけでは根治しない。

skill が呼ばれない原因をトークン予算に帰す見方（説明文が長い、数が多い）と、選択の仕組みに帰す見方（description の識別性、名前の衝突、発火条件の曖昧さ）では打ち手が正反対になる。前者なら削る・短くするが解になり、後者なら数を保ったまま description を書き直すのが解になる。s01 の「長文ポリシーは効かない」と同じ構図で、量ではなく提示の仕方が効いている可能性が高い。

Q. 何ができるツールなのか。
A. 脆弱性の発見だけでなく、その検証と修正までを一連で行う CLI として公開されている。CI/CD に組み込んでパイプラインの一段として走らせる使い方が案内されている。

Q. 既存の SAST と何が違うのか。
A. 静的解析のルールマッチではなくエージェントが検証と修正案まで出す点が差になる。裏返せば結果の再現性と誤検知の扱いは自分で評価する必要がある。

通知の置き場所で設計が変わる。ローカルの音（読み上げ）は即時性が高く手元での並列作業に向くが、席を離れると届かない。Discord のような外部チャネルはどこでも届き履歴も残るが、往復に遅延があり通知が溜まると読まれなくなる。3本目の「音声から委譲する条件」は、通知を受けた後に人間が何を判断するのかを先に決めておくべきだという整理で、通知経路より判断の粒度が先だという主張として読める。

HN には著者（チームの一員）が現れ、月曜の重み公開を受けて記事を更新したこと、そして 86% が上限値であることを自ら開示した。批判として最も支持されたのは価格の欠落で、「どの箱を買うか」を実価格なしに論じるのは意味がないという指摘。量子化版との比較を求める声も強く、遊休の A6000 で Qwen3.6-35B-A3B を int4 で回している例や、LM Studio 上の gemma-4-26b-a4b が「アプリを丸ごと作れ」ではなく「X をどう進めるか」「語彙のニュアンスの説明」といった用途では驚くほど使えるという報告が並んだ。同時実行数の低下については「無人フローに切り替えて支援不要のタスクを空き時間にルーティングすれば済む。15 年前に夜間バッチで MapReduce を回していたのと同じ扱いになる」という見方も出ている。

セルフホストの是非は「同時実行数の低下をどう埋めるか」に収束する。対話的な利用が主なら 24→16 の低下は体験に直撃するが、無人実行が主ならスケジューリングで吸収できる。加えて評価値の扱いに注意が要る。著者が上限値と認めているとおり、ベンチマークのサブセットが学習データに混入している可能性があるため、+20% の解決率向上をそのまま自分のタスクに当てはめられない。

HN の関心は expert キャッシュの効き方に集まった。「トークンごとに選ばれる expert が大きく変わるなら SSD 読みが毎トークン発生して遅くなると思っていたが、そうではないらしい。expert が切り替わる頻度の統計はあるか、切り替えなしで続く最長のトークン列はどんなものか、どんな場合に頻繁に切り替わるのか」という問いが最上位に付いている。また「M2 Air の 5〜6 tok/s と M5 Pro の 31〜35 tok/s という開きは、SSD 性能差だけでは素朴には説明できない」という疑問、「RAM が十分にあってモデルを全部載せられる場合はこのエンジンを使うべきではないのか」という適用範囲の確認も出た。

MoE（Mixture of Experts）では 1 トークンの生成で全パラメータを使うわけではなく、ルーターが選んだ一部の expert だけが活性化する。だからこそ「必要な expert だけを SSD から読み、残りは載せない」という戦略が成立し、26B のモデルが 2GB の RAM に収まる。逆に密なモデルでは同じ手が使えない。