今日の収穫、3行で。

標準化の利点は明白で、SKILL.mdを一度書けばCodex・VS Code・Claude Codeのどれでも使い回せる。一方で懸念もある。規格化は最大公約数への収束を招きやすく、Claude Code固有のhooks連携やsubagent呼び出しといった踏み込んだ機能が「規格外」として扱われる可能性がある。また本家が未対応という順序は、規格の主導権がAnthropicの手を離れつつある兆候とも読める。

Q. 既存の ~/.claude/skills/ 配下の資産はそのまま使えるのか？
A. 規格はSKILL.md + frontmatterという既存の形をベースにしているため、基本構造は温存される見込み。ただし各ハーネスがどこまでのfrontmatterキーを解釈するかは実装依存で、allowed-toolsのようなClaude Code固有指定は無視される可能性が高い。

Q. MCPとSkillsはどう使い分けるのか？
A. MCPは「外部システムへの接続（ツール・リソースの提供）」、Skillsは「手順と判断基準の提供」と役割が分かれる。前者はエージェントにできることを増やし、後者はやり方を決める。

HNの論点は3つに割れた。第1に、ローカルのdev toolなのにDockerアカウントへのログインを強制する設計への強い反発（「Requires login. Garbage.」）。第2に、より本質的な指摘として「サンドボックスはエージェントの権限を制限するが、エージェントがサンドボックスの中で走ること自体は強制できない。境界を強制するには別の制御レイヤーが要る」。第3に、devcontainerやApple containerization、VibePod（podman + ローカルテレメトリ）など既存手段との差分が不明という声。一方で「Dockerが本気を出せば業界全体の採用と統合が進む」と歓迎する意見もあった。

クラウド実行は「PCを閉じても走り続ける」という利点があるが有料。ローカルサンドボックスは無料で普及しやすい。HNでは後者が主流になるという予想が優勢だった。

最も鋭い批判は「言語ごとに“同じ達成”をどう正規化したのか」という点で、Webサーバやメモ化フィボナッチのような標準的課題で出力の長さと密度を揃えないと比較が成立しないという指摘。また「構文的な密度がそのままトークンの安さにはならない。記号は英単語よりトークナイザとの相性が悪い」という技術的な補足も出た。もう一つの重要な留保は、既知のソフトウェアを再現させる評価はLLMの訓練データ検索能力を測っているだけで、言語間の能力差が消えて見えるのはそのせいではないか、というもの。逆にGleam / Lustreのような訓練データがほぼ無い言語でもLLMがうまく書けるという体験談もあり、「人間にとって良い言語（コンパイル型・強い静的型・イミュータブル・パターンマッチ）はLLMにとっても良い」という仮説が提示された。

Q. トークンが安い言語を選べばコストは下がるのか？
A. 単純にはそうならない。型情報が薄いとエージェントが誤りを起こしやすく、修正ターンが増えて結局トークンを消費する。記事とHNの議論はどちらも「正答率まで含めて評価せよ」という結論に寄っている。

Q. 人気の言語ほどエージェントに有利なのでは？
A. HNでも同じ問いが出た。訓練データ量は効くが、Gleamのようなマイナー言語でも成績が良い例があり、言語の設計そのもの（型・純粋性・パターンマッチ）が独立に効いている可能性がある。

「だからこそ環境変数へのアクセスなしのサンドボックスで走らせるべき」という反応が最初に来た。GitHubと密結合したツールで.envの除外ルールが無いことへの驚きも複数。手法面では、mitmproxyよりeBPFの方が楽だという有力な補足が付いた。証明書ピンニングやmTLSと戦う必要がなく、暗号化直前・復号直後の平文をそのまま取れるため、ほとんどのエージェントとIDEでテレメトリからプロンプトまで丸見えになるという。なおCodexクライアントはオープンソースなので傍受は不要、という訂正も入った。

エピソード記憶の実装がCopilotとCodexで異なるという指摘がコメントで出ている。Copilotはタスク完了後にメモリを書くため、途中の探索や成功／失敗の試行錯誤が失われる。Codexは各ターンの出力をエピソード記憶に積むため中間過程が残る。

HNは懐疑的だった。「nullや\nを非ASCII記号に置き換えても、どちらも元から1トークンなので意味がない」「Show Meの比較例は情報量が揃っていない」「文字数ではなくトークン数で示せ」と、削減率97%という主張への不信が並んだ。最も本質的な反論は「これはツール設計の問題だ。多くのMCPはツール選択を考えずにvibe codingで作られている」というもの。建設的な代案として、100個のツールを get_tool_schema と invoke_tool の2つに畳むMCPプロキシの実例が挙げられ、その経験から「ツール名だけでなく search_web(query) のように引数名込みで返す方が良い」という知見が共有された。

圧縮でトークンを削る方向と、そもそもツールを減らす／遅延ロードする方向はトレードオフの関係にある。前者は既存MCPをそのまま使えるが復号側でトークンを食う可能性があり、後者は設計変更が要るが根本的。

Code Modeの発想自体は理に適っている。ツール呼び出しをN往復するより、コードを1回書かせて実行する方がトークンもレイテンシも安い。しかしそれは「LLMが書いた任意コードを実行する」ことと同義で、サンドボックスの強度がそのままシステムの強度になる。V8 isolateはプロセス分離より軽いぶん境界も薄く、Spectre系のサイドチャネルを含めた前提が問い直される。

Q. Code Modeを使わなければ安全か？
A. 問題はCode Mode固有ではない。ツール呼び出し方式でも、LLMの出力がそのまま特権的な操作に流れる経路があれば同じ構造の穴が生まれる。境界をどこに引き、何を信頼しないかの設計が本体。

「通り道を支配する」構造はDurable Objectsで最も露骨に現れる。リクエストが特定のオブジェクトに必ずルーティングされるからこそ単一の実行主体で強い一貫性が保証でき、これは経路制御を持たない事業者には真似しにくい。

並列化は速いが、サブエージェントの成果を親が読んで統合するコストが乗る。定例報告方式は逆に直列だが、文脈の劣化を検出して立て直せる。どちらを取るかは「タスクが分割可能か」ではなく「途中で方向がずれたときに気づけるか」で決まる、という読み方ができる。

Q. ループエンジニアリングが同じ提案を繰り返すのはなぜか？
A. 記事の分析では、ループが参照する状態（履歴やHANDOFF）が更新されないまま次の反復に入ると、同じ入力から同じ出力が出る。反復のたびに「何が変わったか」を書き戻す仕組みが要る。

Q. セッション間メッセージの「即座には読まれない」とは？
A. 別セッションへ送ったメッセージは、受信側が次にターンを回すタイミングでしか読まれない。送信＝割り込みではないため、停止中のセッションを叩き起こす用途には使えない。

Q. CLAUDE_CONFIG_DIRを分けると何が防げるか？
A. 複数の受託先を並行して見ているとき、A社のMCPサーバー（社内DBやチケット）にB社のセッションから接続してしまう事故。direnvでディレクトリごとに切り替えれば物理的に到達できなくなる。

Q. 自動モードでフックを使う利点は？
A. 全許可か全確認かの二択ではなく、危険なコマンドだけ確認を挟める。承認疲れを避けつつ、取り返しのつかない操作にだけ人を挟むという線が引ける。

コメント欄は価格批判というより「この割引が続くうちに享受しておこう」という温度感だった。E-inkダッシュボードでClaude CodeとCodexの消費を可視化している人が、200ドル／月の契約に対し週あたり2000ドル相当を消費していると報告している。一方で「定価ベースの反実仮想」という記事側の但し書きを引いて、この種の倍率は交渉価格や実際のコミット額を無視しているという指摘もあった。

同時期のclaude-code v2.1.225では、ゲートウェイの支出上限に達したときの警告メッセージに上限額・リセット時刻・運用者からのメッセージが表示されるようになっている。組織側で消費を絞る導線が整いつつある。

Needle2には「小さいモデルにどれだけの知識が入りうるのか」という素直な関心と、Webデモに「HN」と入力したら front door を lock_door する関数呼び出しを返したという実例報告が並んだ。Anteへの批判はより厳しく、GitHubリポジトリにバイナリだけあってエージェント本体のソースが見当たらない点が複数から突かれた。技術的には「ripgrepやgitを実行ファイルに同梱する意味は？ なら何を同梱しないのか」という線引きへの疑問、そして「ハーネスは単純なループなのだから、PythonやTypeScriptで書いてもメモリはほとんど食わないはず」という反論が出ている。

ローカル実行の利点はプライバシー・オフライン・従量課金からの解放。反対側の主張は、推論品質の差が縮まらない限りフロンティアモデルへのAPI課金の方が結局安く速い、というもの。エッジ側の用途（ロボット・ウェアラブル）とコーディングエージェントでは、この損得計算がまったく異なることに注意したい。

エージェント時代のレビューは「コードが正しいか」より「検証が正しいか」に重心が移る。書かれたコードの量に対して人間のレビュー帯域は増えないため、チェックすべき対象をコードからテストとCIに移す方が費用対効果が高い、という読み方ができる。

Q. 「テストが通った」で何が保証されないのか？
A. テストが実際に実行されたか、対象のコードを本当に通っているか、そしてそのテスト自体がエージェントによって都合よく書き換えられていないか。失敗したときにどう見えるはずかを確認しないと、緑は何も証明しない。

評価用クエリを整った書き言葉で作ると、埋め込みが文書側の書き言葉と一致しやすくなり、検索の難しさが構造的に過小評価される。現場のクエリは省略・社内語・誤字を含むため、この差がそのまま正答率の差になる。

技術的な対策はサンドボックス化と権限の最小化だが、この事例が示すのはもう一段手前の問題である。「ジムを予約して」という指示には、暗黙のうちに「正規の手段で」「他人に損害を与えずに」という制約が含まれている。人間には自明なこの制約を、どこまで明示的に書き下す必要があるのか — Skillsやシステムプロンプトの設計論に直結する。

Q. 入れてしまったMCPサーバーをどう守るか？
A. バージョンをピン留めして自動更新を止める、実行をコンテナや権限を絞ったユーザーに閉じ込める、そして本当に常時必要なサーバーだけを有効にする。同時期にclaude-code v2.1.224では、HTTPS上のzipからSHA-256ピン留め付きでプラグインを入れる archive ソースが追加されている。

記事の主張はトグルの全面否定ではなく、状態が2つと決まっていて即時反映される場面に限れという線引き。3状態以上（システム設定に従う、を含むダークモード切替など）や、保存ボタンを押すまで反映されないフォームでは、ラジオボタンやチェックボックスの方が誤解を生まない。

送信専用アドレスに使うべきなのは、RFC 2606 / 6761 で予約された example.com / .invalid / .test といったドメイン、または自社が実際に保有するドメインのサブドメインである。noreply.net や noreply.com のような「それらしい」ドメインは第三者が取得できてしまう。