MiasmaのAIスクレイパー汚染戦略、TurboQuantのKVキャッシュ圧縮、LinkedInの2.4GB問題 (2026-03-29)
AIスクレイパーを「拒否」ではなく「汚染」で迎え撃つMiasma
AIスクレイパーへの対抗手段が、ブロックから汚染へと進化した。
robots.txtやIP拒否は「来るな」と伝える。Miasmaは「来い、ただし毒を食わせる」という戦略を取る。display: noneで隠したリンクをHTMLに仕込み、スクレイパーがそこを踏んだ瞬間にNginxがMiasmaへプロキシする。Miasmaは汚染データと自己参照リンクを返す。スクレイパーはそのリンクをまた踏む。これが無限に続く。
<a href="/bots" style="display: none;" aria-hidden="true" tabindex="1">
Amazing high quality data here!
</a>
location ~ ^/bots($|/.*)$ {
proxy_pass http://localhost:9855;
}
miasma --link-prefix '/bots' -p 9855 -c 50
防衛側のコストは極めて小さい。同時接続50本で50〜60MBのメモリ使用量だ。Rustで実装されているため速度とメモリ効率が高く、既存サーバーへの負荷増加を心配する必要がない。スクレイパー側は自己参照リンクを辿り続けるため、計算リソースとネットワーク帯域を消費する。非対称な消耗戦を意図的に設計している点が重要だ。
このアプローチには訓練データ汚染という側面もある。大量の低品質・矛盾したデータをモデルに食わせることで、そのモデルの品質を意図的に下げる可能性がある。効果の検証は難しいが、理論上は成立する。
実用上の注意点がある。robots.txtでGooglebotなど善良なボットを除外する設定を必ず先に行うべきだ。Disallow: /botsを設定してからMiasmaを起動する順序を守らないと、検索インデックスが壊れる。
【注意】一部の法域では、意図的にボットを誘導して計算リソースを消費させる行為が、コンピュータ不正アクセス関連法（米国のCFAAなど）の解釈上グレーゾーンとなる可能性が指摘されている。商用サービスへの導入前に法務確認を推奨する。ただしrobots.txtを無視するスクレイパーが増えている現状では、この除外設定が確実に機能する保証はない。
導入コストはほぼゼロに近い。cargo install miasma一発でインストールでき、Nginxの設定変更は5行以内で完結する。Miasmaのセットアップより先に、HTMLに隠しリンクを1行追加するだけでハニーポットの入り口だけ作っておくこともできる。後からMiasmaを接続すればよい。
LinkedInの2.4GBが示すWebアプリ設計の構造的劣化
LinkedInが2タブで2.4GBのRAMを消費している。「重いサイトだな」で済む話ではなく、Webアプリ全体の設計思想が壊れてきているサインだ。
HNのスレッドを読むと、LinkedInだけの話ではないことがすぐわかる。DeepLのページを開いたまま離席したら、動画要素がSEEKINGループに入り、NextJS/ReactのイベントチェーンがCPUを食い続けてラップトップが熱くなった、という報告がある。Redditの新UIは22fps相当の重さで描画される。Claude/OpenAIのWebコンソールは、ストリーミングレスポンスの更新のたびに会話履歴全体を再レンダリングしていた。
これらに共通する構造的な原因がある。
LLMによるコード生成が「ユニットテストが通る・見た目が動く」を完成の基準にしてしまっている。開発者のハイスペックマシンでは問題が表面化しない。メモリリークも無限ループも、32GBのM3 Maxなら「少し重いかな」で終わる。CIも通る。デプロイされる。
大規模サービスでは複数チームが独立したWebアプリを積み重ねる構成になっており、同じライブラリが複数回ロードされる。LinkedInのような組織規模になると、これが構造的に避けにくい。
さらに根本的な問題として、Core Web Vitalsが「初期ロード速度」と「視覚的安定性」に偏っており、継続的なメモリ消費やCPU使用率を測定対象にしていない。Googleが検索順位に反映しない限り、改善のインセンティブが働かない。
Firefoxがメモリ不足でクラッシュせずシステムをフリーズさせ続けるという報告も興味深い。「安全に失敗する」設計が、ユーザー体験上は「より悪い失敗」を引き起こしている。
構造的な原因は明確だ。React.memoやuseMemoで防げる全履歴の再レンダリングをLLMが生成したコードは省略しがちで、Page Visibility APIによるリソース解放も同様に抜け落ちる。DeepLの事例はSEEKINGイベントのループだが、document.addEventListener('visibilitychange', ...)でvideo.pause()するだけで防げた可能性が高い。
【実装例】document.addEventListener('visibilitychange', () => { if (document.hidden) { video.pause(); } }); — タブが非表示になった瞬間にメディア要素を停止する最小実装。同様のパターンでWebSocketの再接続ループやポーリング処理も抑制できる。Chrome DevToolsのPerformanceタブでメモリタイムラインを30分録画する、CPUを4倍スロットリングした状態でテストする——こうした工程が標準化されていれば、「動く」と「長時間使っても壊れない」の乖離は早期に検出できた。
TurboQuantがKVキャッシュ問題をハードウェアではなく数学で解く
AIのメモリ問題はハードウェアで解くものだと思われていたが、GoogleのTurboQuantはそれを数学で解けることを示している。
KVキャッシュはトークン数に比例して膨張する。Llama 3.1 70Bでは、長いコンテキスト1件のKVキャッシュがモデルの重みそのものより大きくなる。
【具体例】Llama 3.1 70BをBF16で保持するとモデル重みは約140GB。128Kトークンのコンテキストを処理する場合、KVキャッシュは単純計算で160GB超に達し得る（レイヤー数×ヘッド数×次元×トークン数×2（K+V）×2バイト）。これがH100 80GB×2枚構成でも収まらない理由だ。
TurboQuantはここに2段階の数学的アプローチで切り込む。
第1段階のPolarQuantは、ベクトルの表現方法を変える。通常はデカルト座標（x, y, z）で格納するが、これを極座標（半径と角度）に変換する。高次元のTransformerのKey空間では、角度の分布が高度に集中して予測可能であることが観察されている。この予測可能性を利用すると、音声や画像の圧縮で使われる固定量子化グリッドにきれいに当てはめられる。モデル固有のファインチューニングもキャリブレーションも不要で、どのモデルにもそのまま適用できる。
第2段階のQJL（Quantised Johnson-Lindenstrauss）は、次元削減によって量子化の効率を高める役割を担う。
【前提知識】Johnson-Lindenstrauss補題とは、高次元空間のベクトル集合を低次元空間にランダム射影しても、ベクトル間の距離（内積）がほぼ保存されるという数学的定理。QJLはこの性質を利用し、KVベクトルを低次元に射影してから量子化することで、メタデータのオーバーヘッドを削減する。従来の量子化手法は、値を4ビットや3ビットに丸めるとき、メタデータとして1〜2ビットのオーバーヘッドを付加する。これが圧縮の恩恵を部分的に相殺していた。TurboQuantはこのオーバーヘッドを構造的に排除する設計になっている。
この話が面白いのは、「精度を犠牲にせずに圧縮できる」という主張の根拠が、モデルのアーキテクチャではなくベクトル空間の幾何学的性質にある点だ。高次元空間では角度分布が集中するという観察は、高次元になるほどランダムなベクトルは互いにほぼ直交するという性質があり、Key空間でも類似した構造的規則性が生まれやすい。
【補足】この現象は「次元の呪い」の裏面とも言える。高次元では距離が均質化する一方、角度（方向）の分布は特定のパターンに収束しやすい。TransformerのKey空間では、学習によってさらにこの集中が強化されることが実験的に確認されている。TurboQuantはこの性質を「圧縮の手がかり」として使っている。
重要なのは、この性質がモデルの種類に依存しないという点だ。GPT系でもLLaMA系でも、Transformerのアテンション機構を使っている限り、同じ幾何学的性質が現れる。だからキャリブレーション不要で汎用的に適用できる。
もし精度劣化なしに2〜3ビットまで圧縮できるなら、KVキャッシュのメモリ使用量は理論上4〜8分の1になる。これはHBM容量の制約を数学で緩和することを意味する。HBM市場の成長前提の一部が、ソフトウェアレイヤーで崩れる可能性がある。
キャリブレーション不要という特性は、本番環境への導入障壁が低いことを意味する。「コンテキスト長の上限はGPUメモリ」という前提が、ソフトウェアレイヤーで崩れ始めている。インフラコストの見積もりが、アルゴリズムの進化によって数ヶ月単位で変わる局面に入っている。
総括
MiasmaはRustで実装された50〜60MBのプロセスで、AIスクレイパーを無限ループに引き込む。防衛側のコストが極めて小さい一方、スクレイパー側の計算リソースを消費させる非対称設計だ。robots.txtを無視するスクレイパーが増えている現状では、IP拒否やrobots.txtだけでは対抗できなくなっており、Miasmaのような「汚染」戦略が実用的な選択肢として浮上している。
LinkedInの2タブ2.4GB問題は、DeepLのSEEKINGループやRedditの22fps描画、Claude/OpenAIの全履歴再レンダリングと同じ構造的原因を持つ。LLMが生成したコードは「CIが通る・初期表示が速い」を最適化するため、長時間使用時のリソース解放（Page Visibility API）や再レンダリング抑制（React.memo）が省略される。Core Web VitalsがクライアントサイドのRAM消費をランキング指標に含めていない限り、LinkedInのような大規模サービスに改善のインセンティブは働かない。
GoogleのTurboQuantは、Llama 3.1 70Bでモデルの重みを超えるまで膨張するKVキャッシュを、PolarQuantとQJLの2段階で2〜3ビットに圧縮する。HBMの増設ではなく、TransformerのKey空間における角度分布の集中という幾何学的性質を利用するため、GPT系・LLaMA系を問わずキャリブレーション不要で適用できる。KVキャッシュが4〜8分の1になるなら、HBM市場の成長前提の一部がソフトウェアレイヤーで崩れる。