今日の収穫、3行で。

Q. MCPは結局なにを標準化しているのか？
A. LLMアプリと外部のツール・データ源をつなぐ口を、JSON-RPCベースの共通プロトコルとして規定している。個々のクライアント向けにアダプタを書き直さずに済むことが最大の狙い。

Q. 「使ってみた」記事との違いは？
A. 設定ファイルを書いて動かす話ではなく、プロトコルの構成要素とエージェント内での責務分担を扱っている。自作サーバーの設計判断に直結する層。

Mermaidのスタイル指定はノード定義に埋め込むclassDef/styleと、テーマ変数を渡すinitディレクティブの2系統がある。変換をかけるツールが前者だけを構文木として扱うと、後者は素通りするか丸ごと落ちる。

LSPを噛ませると参照解決の精度は上がるが、言語サーバの起動コストとインデックス構築の待ち時間がセッションに乗る。Claude Code 2.1.235で「言語サーバの再接続でプロンプトキャッシュ全体が無効化される」不具合が修正されたことからも分かるとおり、統合が深いほどキャッシュ戦略との相互作用が問題になる。

cache readは新規入力より単価が低いので、割合が高いこと自体は悪ではない。問題は、キャッシュが無効化されたときに同じ量が高い単価で再計上される点で、割合ではなく無効化の回数を見るべきという読み方もできる。

プロンプトキャッシュは先頭からの連続一致で効くため、システムプロンプトやツール定義を1文字でも書き換えると以降が丸ごと再構築される。会話の末尾に足すぶんには効きが保たれるが、途中に差し込むと後続が全部落ちる。

HNのコメントは歓迎と冷ややかさが半々。「GitHubのネットワーク効果がどこまで強いか試す機会だ」という声がある一方、「プライベートリポジトリを学習に使わない保証がない」「Cursorから既にClaude Code/Codexに移った」といった拒否感も強い。技術的な指摘として面白いのは名前で、`git push origin main` の origin と衝突するため「LLMが取り違えて別のホストに push しかねない」という懸念が出ていた。GitHub障害については、COOの発言として2025年のコミット数10億件・直近で週2.75億件という数字が引かれ、AI起因の負荷増が挙げられている。

Q. GitHubの不調はAzure移行が原因なのか？
A. HN上ではAzure移行とAI起因のトラフィック増の両方が挙がっているが、いずれもコメント欄の推測とCOOのSNS発言の引用にとどまる。GitHubからの公式な事後分析は示されていない。

プロジェクト記憶に寄せるほど毎回のブリーフィングは短くなるが、記憶が古びたときに気づきにくい。逆に呼び出し側で毎回渡す設計は冗長でも鮮度が保証される。どちらが正解かは、その情報の変化速度で決まる。

スキルの説明文（description）はモデルが「今このスキルを開くべきか」を判断する唯一の手がかりになるため、本文をどれだけ丁寧に書いても description が曖昧だと発火しない。全文公開された事例では、この一行の書き方こそ比較する価値がある。

worktree分離は編集の衝突を防ぐが、依存パッケージのインストールとビルドキャッシュがツリーの数だけ増える。node_modulesを共有するかどうかで、ディスクと再現性のどちらを取るかが変わる。

無人運転は「賢く判断させる」より「止まったことに気づける」ほうが実装コストを食う。ハートビートと再開点の設計を先に決めておかないと、成功した回だけログに残って失敗が黙って消える。

試行回数が5回と3回で異なるため、0/5→3/3という比較は厳密な対照実験ではない。それでも「中身が同じで名前だけ違う」条件が揃っている点は、原因を名前に絞り込む材料になる。

公式機能は届く保証と権限管理を提供するが、何を引き継ぐかというスキーマは自分で決めるしかない。汎用のメッセージ配送と、ドメイン固有の引き継ぎフォーマットは別レイヤーだと考えると整理しやすい。

規約を長く詳しくするほど、実際に読まれる確率は下がる。「読ませる」より「破れない仕組みにする」——lintやhookで機械的に落とす——ほうが確実だが、その分だけ柔軟性は失われる。

MCPサーバーは接続時にツール定義一覧をクライアントへ渡すため、常駐しているサーバーの数だけシステムプロンプトが長くなる。常駐を減らすとメモリだけでなく、毎ターンのトークン消費も下がる。

Q. 次トークン予測だけで推論が成立するのはなぜ？
A. 学習データ中の推論過程そのものが次トークンの分布に織り込まれているため、途中の思考を出力させるとその分布に沿った続きが生成される。仕組みが単純であることと、表現できる関数が単純であることは別。

Q. 「思考しているように見える」ことの実務上の含意は？
A. 見え方が正しさを保証しないという点。もっともらしい中間ステップが出ても、それは検証済みの推論ではなく確率的に尤もらしい文字列なので、結論は外部で検証する必要がある。

HNでは期待と警戒が拮抗した。「再利用可能な関数とパイプラインがSQLにコンパイルされるのは素晴らしい」という歓迎の一方、「SQLの1行が読みにくい6行になっただけでは」という指摘もある。最も踏み込んだ批判は、直和型が独自のバイナリ表現を持つため『SQLと共存する』という主張が疑わしい、というもの。共存を掲げつつ実質はAcadiaへの全面移行を迫る構造になっていて、DBのほうがアプリコードより長生きするという前提に反する、という論だった。

uBlock Originの動的フィルタリングは、通常のフィルタリストより優先度が高い階層で動く。リストの購読を増やすのとハードモードにするのは、同じ「ブロック」でも効くレイヤーが違う。

Fabien Sanglard氏はDoomやWolfenstein 3Dのソースコード解読書で知られ、実際のバイナリとアセットを開いて当時の判断を再構成する手法を一貫して取っている。