その pip install、信用していい？未監査の LLM 圧縮ツールをゼロトラスト隔離で実測した

こんにちは。窓を開けにくい季節になると、家の中に「知らないうちに入り込むもの」がかえって気になってきますね。

「トークンを50〜90%削る」とうたう圧縮ツール Headroom（headroom-ai / Apache 2.0）を、本番には一切つながない隔離箱の中で試しました。中身を先に読み、使い捨ての鍵だけを渡し、通信を1宛先に絞ったうえで動かした結果、悪さをする兆候は見つかりませんでした。ただ、私の測り方では削減はほぼ0%。本当に削れていたのは、別の道具 RTK による「ロスのある要約」のほうで、こちらは93%でした。「再現できなかった」と「効果がない」は別物です。

この記事では、その手順を「素性の知れないツールを安全に試すための型」として残します。検証は自宅ラボの GPU サーバー上に作った隔離コンテナで行いました（検証日 2026-06-06）。ファイアウォールのルールや認証情報の取り方のような、攻撃の再現に使える具体的な手順はあえて載せず、原理と結果だけを書いています。

• 便利そうな OSS ほど、いきなり本番に入れたくない
• 4つの「信用しない」を同時にかける
• 中身を読んだ結果、悪質な兆候はなし。グレーは2点
• 箱を何重にも固め、「遮断したつもり」を実地で潰した
• 鍵は、盗まれても困らない使い捨てを1本だけ
• 本体の削減は、私の測り方ではほぼ0%だった
• 削れていたのは別の層、RTK の「ロスのある要約」で93%
• Headroom は見送り、RTK は少しずつ取り入れる
• 残った一番の資産は「試す前の型」
• この記事を書いた人
  • 出典

見つけたのは、LLMLLM（大規模言語モデル）大量の文章で学習し、人のように文章を読み書きできる大きな AI のモデル。詳しく → にリクエストを送る前に、ツールの出力やログ、JSON、会話履歴を自動で縮めてトークンを50〜90%削減するという中継ソフト（プロキシ）でした。LLM の料金はトークン量に比例しますから、本当なら請求額が半分以下になる計算です。飛びつきたくなる話でした。

ただ、このツールが座るのは自前の LLM ゲートウェイ（AI への窓口をまとめる仕組み）の前段です。こちらが送る全リクエストが、必ずここを通ります。便利さと引き換えに、いちばん信頼が要る場所を素性のわからないソフトに明け渡すことになる。便利な宅配ロッカーだからといって、玄関の合鍵まで渡してよいか、という話に近いと思います。

そこで「評価してから信用する」に切り替えました。Apache 2.0 で配られている OSS なら、中身を読み、改変し、隔離環境で自由に試すことはライセンス上まったく正当です。その代わり無保証なので、安全は自分で確かめるしかありません。

この出発点には前段があります。便利そうなツールをそのまま信用してしまった失敗の反省は「危険なツールを薦めた Claude Code が、5分後にセキュリティ講座を開いた」に書きました。自宅のセキュリティ監視でつまずいた話「RasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録」とも地続きの話です。

ゼロトラストは、ひとことで言えば「最初から誰も何も信用しない」という構えです。社内ネットワークの中だから安全、有名な OSS だから安全、という暗黙の信頼を置きません。今回はこれを4つの原則にしました。

• 実行する前に、まず中身を読む（コードを動かさずに監査する）
• 認証は使い捨てで渡す（盗まれても被害が極小になる鍵だけ持たせる）
• 通信は必要最小限に絞る（許可した宛先以外へは一切出られない箱に入れる）
• 壊れても本番に届かない（隔離が破れても、本番の鍵やデータには手が届かない）

肝は、これを全部同時にかけることです。一つでも穴があれば、そこから抜けられてしまいます。逆に全部かけておけば、中身が悪意あるソフトだったとしても、観測しながら安全に走らせて性能だけを測り取れます。

最初の関門は、一行も実行せずにソースを読むことです。実はここに、見落としやすい罠があります。パッケージを「取ってくる」操作そのものです。素朴な取得手段の中には、パッケージの情報を解決する途中でパッケージ側のコードを実行してしまうものがあり、それでは「実行前に読む」という前提が崩れます。そこで配布元から固まったファイルだけを取り寄せ、ハッシュ値（ファイルの指紋のような値）で同一性を固定してから展開して読みました。展開そのものは何も実行しません。

一人で読むと盲点が出るので、人間の目に加えて複数の AI アシスタントにそれぞれ独立してソースを読ませ、4つの視点でクロスチェックしました。狙って探したのは、バックドア・認証情報の窃取・実行時の動的コード実行・難読化したデータ持ち出し、の4類型です。

どれも検出されませんでした。むしろ、ログに書き込む前に API キーやトークンらしき文字列を伏字に置き換える保護コードまで入っていました。一方で、評価を保留した「グレー」な点が2つあります。ひとつは、集計用のテレメトリ（利用状況の送信）が初期状態で有効なこと。停止フラグがあり、リクエスト本文や鍵そのものは送られません。もうひとつは、匿名キーを分割して保持していること。どちらも是非は断じず、確かめられる事実として置いておきます。判断は読む方にお任せします。

それでも、ソースだけでは判断しきれない部分が残りました。Rust 製のネイティブ拡張、つまりコンパイル済みのバイナリです。ソースを読んで確かめられない、いわばブラックボックス。だからこそ、次の隔離で安全を担保することにしました。

読めない部分が残った以上、走らせる場所は徹底的に固めます。コンテナ（Docker）を使い、いくつもの制限を重ねがけしました。余計な権限はすべて剥奪し、途中で権限を上げられなくし、ファイルシステムは書き込み禁止にして、必要な作業領域だけを揮発性のメモリに逃がす。使えるメモリ量とプロセス数にも上限をかけました。一つひとつは小さな制約でも、重なると「悪さをしようにも、手段が残っていない」状態になります。

山場は外向きの通信を絞ることでした。出てよい宛先を業務に必要な一つだけにして、ほかはすべて遮断する設計です。ところが、絞ったあとで「本当に他へ出られないか」を実地で確かめると、名前解決（DNS、宛先の名前を住所に変える仕組み）の経路だけが檻をすり抜けていました。事前に複数の AI が「ここから漏れうる」と警告していた箇所で、まさにその通りでした。ここを塞ぎ、許可した宛先には届いて、それ以外（外部の公開 DNS や他の機器）には一切届かないことを一つずつ確かめてから、本番のテストに入っています。

教訓は単純です。「遮断したつもり」を信用しない。実際に漏れないと確認できて、初めて遮断と呼べます。

箱の中で性能を測るには、ツールを本物の LLM につなぐ必要があります。普段使いの鍵は渡せません。そこで、短命・低予算・1モデル限定の使い捨ての鍵を一本だけ発行しました。仮に隔離をすり抜けて盗まれても、数日で失効し、使える上限額はわずかで、指定した一つのモデル以外は呼べません。

実際に「許可したモデルは通り、許可していないモデルは弾かれる」ことも動かして確かめました。こうした鍵を発行する権限自体は強いので、その扱いは信頼境界の内側で完結させ、隔離する側のツールには一切触れさせていません。大事なものほど、最小の権限で、使い捨てで渡す。ここがゼロトラストの肝だと考えています。

この使い捨ての鍵を発行できるゲートウェイを自宅に建てた経緯は「まだ .env で疲弊してませんか？私も同じでした、LiteLLMを導入するまでは。」に書いています。

準備が整ったので、効果を測りました。条件はできるだけ本気にしています。圧縮用のモデルを起動時に焼き込んだ版を使い、会話を5ターン積み重ねて6万トークン超まで育てた、実運用に近いセッションです。

結果は削減ほぼ0%でした。トークン量は減らず、そのかわり回答の品質も落ちませんでした。「悪さはしないが、この使い方では効きもしない」という状態です。

ただ、これを「謳い文句が嘘」と読むのは早いと思います。ソースを二度読み返して圧縮が働く条件を確かめると、効果が出るのは特定の経路でした。たとえばツールを CLI（コマンドで動かす形）として包む使い方や、プロンプトの先頭部分のキャッシュ割引が効く構成です。私の測り方、つまり API を直接叩いて合成ログで計る方法では、その効果は原理的に見えません。同じツールでも、置く場所と測り方が違えば結果は変わります。導入を考えるなら、自分の構成が効果の出る経路と噛み合うかを、先に隔離環境で測るのがおすすめです。

ここで判断の助けにしたのが「スペック表は盛れても、口コミは嘘になりにくい」という考え方です。実際に削減できたという声が一定数ある以上、効く経路がどこかにあるはずだと考え、ツールを包む使い方の経路を辿り直しました。

すると本当の削減は、測っていた本体プロキシではなく、別の独立したバイナリにありました。RTK（Rust Token Killer）という、コマンドの出力をその場で要約・圧縮する道具です。ログ表示やテスト結果、検索結果のような「人が読むには長すぎる出力」を、LLM に渡す前にぎゅっと縮めます。

ネットワークを完全に遮断した状態で測ると、効果は本物でした。長大なログや JSON はほぼ消し込まれ、合計で93%の削減です。ただし大事な但し書きがあります。これは元に戻せる圧縮ではなく、ロスのある要約です。ログを縮めた版は「エラーが何件あったか」のような判断に必要な情報を残していましたが、JSON を縮めた版は個々の具体的な値が落ちていて、「特定の項目の値は？」という問いには答えられませんでした。何を残し何を捨てるかを分かったうえで、捨ててよい用途に限って使う道具です。なお RTK にも独自のテレメトリがありますが、こちらも環境変数で止められます。

本体の圧縮プロキシは、今の私の使い方では見送りにしました。効果が出る経路と、こちらの構成が噛み合っていないからです。一方、副産物として見つかった RTK は、ロスを許せる用途（ログ・テスト・ビルド出力の要約）に絞れば十分に役立つので、これから実務へ少しずつ導入していくつもりです。

それに、導入前の評価の題材として、Headroom はとても良い相手でした。悪質な兆候はなく、保護コードを備え、効果の主張にも（経路は違えど）裏付けがある。安心して中身を確かめられる OSS だったからこそ、評価の手順を最後まで通せました。実務へ本格的に入れたときの削減の実数値は、続編であらためてご報告します。

ツールの採否より価値があったのは、未監査のものを安全に試すための型のほうでした。次に「便利そうだけど素性の知れないツール」に出会ったら、そのまま使えます。

1. 実行する前に中身を読む
2. 使い捨ての認証だけ渡す
3. 通信を絞った隔離箱に入れる
4. 遮断できていることを実証する
5. 効果を実測する
6. 終わったら痕跡を残さず片付ける

便利さに飛びつく前の、ほんの少しの慎重さ。それが自分の環境を長く健全に保ついちばんの近道だと、私は考えています。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

出典

• Headroom（headroom-ai, Apache License 2.0）— GitHub: chopratejas/headroom
• RTK / Rust Token Killer — GitHub: rtk-ai/rtk
• Apache License 2.0 全文

この記事は、自宅ラボの GPU サーバー（Ubuntu / Docker）上に構築した隔離コンテナでの実機検証（検証方法：静的監査＋多層ハードニング隔離＋使い捨て仮想キーでの実測／検証日 2026-06-06）をもとに執筆しています。LLM 接続はセルフホストの LLM ゲートウェイ経由（使い捨て仮想キー・1モデル限定・短期失効）。監査方式は人手＋複数 LLM アシスタントによる独立クロスチェック（4視点）です。