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

関連記事として「Blog危険なツールを薦めたAI執事が5分後にセキュリティ講座を開いたAIの推薦を安全承認と勘違いすると危ない。実体験の後日談から、推薦・検証・判断を分ける運用とdry-runの使い方を整理します。→」もあわせて読むと、「便利そうなツールをそのまま信用しない」という今回の出発点が、どんな失敗の反省から来ているかが地続きで掴めます。

この記事は、自宅ラボの GPU サーバー上に構築した隔離コンテナでの実機検証（検証日 2026-06-06）をもとに執筆しています。方針は実名・中立公平。評価語は使わず、検証可能な事実のみを記載します。なお、攻撃の再現に使える具体的な手順（ファイアウォールのルールや認証情報の取得手順など）は意図的に載せず、原理と結果のみを記述しています。

TL;DR: 先に結論——トークン50〜90%削減を謳う未監査の圧縮プロキシ Headroom（headroom-ai / Apache 2.0）を、①実行前の静的監査（人＋複数 AI の4視点クロスチェック）、②使い捨ての認証キー、③通信を1宛先に絞った多層ハードニング隔離、の全部がけで実測しました。結果、悪質な兆候はなし。ただし我々の計測経路では削減はほぼ0%で、真の削減（93%）は別バイナリ RTK のロスあり要約層にありました。「再現できなかった」と「効果がない」は別物——未監査ツールを安全に試すための再利用可能な型を、一次情報で記録します。

• 便利そうな OSS ほど、いきなり本番に入れたくない
• 「信用しない」を出発点にする — ゼロトラストという構え
• まず中身を読む：静的監査の4つの目
• 壊れても本番に届かない箱を作る — 多層ハードニング
• 鍵は使い捨てで渡す
• いざ実測：謳い文句50〜90% vs 我々の環境での0%
• どんでん返し：効果は別の層にあった
• 結論と、未監査ツールを安全に試すための型
• よくある質問（FAQ）
• この記事を書いた人
  • 出典

ある日、こんなツールを見つけました。LLM にリクエストを送る前に、ツールの出力やログ、JSON、会話履歴を自動で圧縮して、トークンを50〜90%削減するというプロキシです。名前は Headroom（パッケージ名は headroom-ai、ライセンスは Apache 2.0）。LLM のコストはトークン量に比例しますから、もし本当なら請求額が半分以下になる計算で、思わず飛びつきたくなります。

ただ、ここで一度立ち止まりました。このツールが置かれる場所は「自前の LLM ゲートウェイの前段」です。つまり、こちらが送る全リクエストが必ずこのツールを通る位置に座ります。便利さと引き換えに、最も信頼が必要な場所を、まだ素性のわからないソフトに明け渡すことになる。これは、便利な宅配ロッカーだからといって、玄関の合鍵を渡してよいかという話に似ています。

そこで方針を「評価してから信用する」に切り替えました。OSS が Apache 2.0 で配布されているということは、中身を読み、改変し、隔離環境で自由に試すことがライセンス上まったく正当だということでもあります（その代わり「無保証」ですから、安全は自分で確かめるしかありません）。本記事は、未監査のパッケージを本番に晒さずに、安全性と効果を一度に測るためにやったことの記録です。

ゼロトラストとは、ひとことで言えば「最初から誰も何も信用しない」という構えです。社内ネットワークの中だから安全、有名な OSS だから安全、といった暗黙の信頼を一切置かず、すべてを疑ってかかる。今回の評価は、この考え方を4つの原則に落とし込みました。

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

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

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

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

結果は良好でした。これらの悪質な兆候は検出されず、むしろログに書き込む前に API キーやトークンらしき文字列を伏字へ置き換える保護コードまで備わっていました。一方で、評価を保留にした「グレー」な点も2つ、事実として記録しました。ひとつは集計用のテレメトリが初期状態で有効なこと（停止フラグがあり、リクエスト本文や鍵そのものは送られません）。もうひとつは匿名キーを分割して保持していること。これらは是非を断じず、検証可能な事実として読者の判断に委ねます。

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

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

最大の山場は外向きの通信を絞ることでした。このツールが外に出てよい宛先を、業務に必要な一つだけに限定し、それ以外への通信はすべて遮断する設計にしました。ここで一つ、教科書には載っていない発見がありました。通信を絞ったうえで「本当に他へ出られないか」を実地に確認したところ、名前解決（DNS）の経路だけが、用意した檻をすり抜けていたのです。事前に複数の AI も「ここから漏れうる」と警告していた箇所で、まさにその通りでした。これを塞ぎ、許可した宛先には届き・それ以外（外部の公開 DNS や他の機器）には一切届かないことを一つずつ実証してから、本番テストに入りました。

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

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

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

ちなみに、この使い捨ての仮想キーを発行できるゲートウェイを自宅に建てた経緯は「Blogまだ .env で疲弊してませんか？私も同じでした、LiteLLMを導入するまでは。複数プロジェクトに散乱するAPIキーの管理問題を、LiteLLM自己ホスティングで構造ごと解決。仮想キー集約・ハード予算上限・OpenAI互換エンドポイントの3本柱で変わったこと。→」に書いています。

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

結果は、正直に書きます。**削減はほぼ0%**でした。トークン量は減らず、しかし回答の品質も劣化しませんでした。つまり「悪さはしないが、我々の使い方では効きもしない」という状態です。

ここで踏みとどまって考えました。これは「謳い文句が嘘」という意味ではありません。ソースを二度読み返して圧縮の発火条件を確認したところ、効果が出るのは特定の経路（たとえばツールを CLI として包む使い方や、プロンプトの先頭キャッシュ割引が効く構成）で、こちらの測り方＝API を直接叩く合成ログの計測では、その効果が原理的に見えないことがわかりました。同じツールでも、置く場所と測り方が違えば結果は変わる。「再現できなかった」と「効果がない」は別物だということです。

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

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

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

今回の評価の結論です。本体の圧縮プロキシは、我々の現在の使い方では見送りとしました。効果が出る経路と、こちらの構成が噛み合っていないためです。一方で副産物として見つかった RTK は、ロスを許容できる用途（ログ・テスト・ビルド出力の要約）に絞れば十分に有用で、こちらは今後、実務へ少しずつ導入していく価値があると判断しました。

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

最後に、この検証から残った一番の資産は、特定のツールの採否そのものよりも、**「未監査のものを安全に試すための型」**です。すなわち——①実行する前に中身を読む、②使い捨ての認証だけ渡す、③通信を絞った隔離箱に入れる、④遮断できていることを実証する、⑤効果を実測する、⑥終わったら痕跡を残さず片付ける。この型は、次に出会う「便利そうだけど素性の知れないツール」すべてに、そのまま再利用できます。便利さに飛びつく前の、ほんの少しの慎重さ。それが、自分のスタックを長く健全に保つ一番の近道だと考えています。

Q. 結局、Headroom は危険なツールだったの？ A. いいえ。静的監査（人＋複数 AI の4視点クロスチェック）でバックドア・認証情報の窃取・動的コード実行・難読化したデータ持ち出しのいずれも検出されず、むしろログ書き込み前に API キー類を伏字化する保護コードを備えていました。グレーとして記録したのは「テレメトリが初期状態で有効（停止フラグあり）」「匿名キーの分割保持」の2点の事実のみで、評価は読者の判断に委ねています。

Q. 削減0%だったなら、導入を検討する意味はない？ A. 「我々の計測経路では0%」であって「効果がない」ではありません。圧縮が効くのは特定の経路（CLI として包む使い方や、プロンプト先頭のキャッシュ割引が効く構成）で、API を直接叩く合成ログの計測ではその効果が原理的に見えませんでした。自分の構成が効果の出る経路と噛み合うかを、導入前に隔離環境で測るのが本記事の提案です。

Q. RTK の93%削減はそのまま鵜呑みにしていい？ A. 但し書き付きです。RTK は可逆圧縮ではなく「ロスのある要約」で、判断に必要な情報（エラー件数など）は残る一方、個別の具体的な値は失われます。ログ・テスト・ビルド出力のような「捨ててよい用途」に絞って使うのが前提で、独自テレメトリも環境変数で停止できます。

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

出典

• 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視点）です。