クラウドの安全フィルターに頼らず、手元のマシンだけで本物の脆弱性を掘り当てる——その実例が2026年7月に報告されました。
サイバーセキュリティ研究チームHacker House（@hackerfantastic）は、ローカルLLMと「recursive prompting（再帰プロンプト）」を組み合わせ、複雑なFOSS（フリーオープンソースソフトウェア）のコードベースから高リスクのRCE（リモートコード実行）0dayを1件発見したと発表しています（参考）。対象プロジェクト名やCVE番号は未公開ですが、使ったハードウェアとソフトウェアの構成は明示されています。
この記事では、発表内容を軸に、再帰プロンプトの考え方と、NVIDIA DGX Spark・Qwen 3.6 heretic・llama.cpp・LiteLLM・OpenClawがそれぞれ担う役割を整理します。
この記事でわかること
- Hacker Houseが報告した0day探索の成果と前提条件
- recursive promptingがコード監査で機能する理由
- DGX Spark上でローカルLLM agentを組む5層構成
- クラウドAPIとローカル構成を使い分ける際の注意点
クラウド不要の0day探索が現実味を帯びた
従来、LLMを脆弱性発見に使う事例は、クラウド上の大規模モデルと専用プログラム（AnthropicのCyber Verification Programなど）に依存するケースが目立ちました。今回の報告は、すべてをローカル環境で完結させた点が新しいです。
投稿本文は次のとおりです。「How to find 0day using local LLM’s and “recursive prompting”. I used this approach on a NVIDIA DGX Spark using Qwen 3.6 heretic and LLAMA.cpp with LiteLLM and Openclaw. It successfully analyzed a complex FOSS code base and found a single high-risk RCE 0day.」
成果は「1件の高リスクRCE 0day」に限定されています。数を誇る話ではなく、ローカルLLMだけで実在する深刻な脆弱性に到達できた、という事実が核心です。Hacker HouseはiscsicplのUACバイパス0dayなど、過去にもWindows向けの脆弱性研究で実績を持つチームです（参考）。
recursive promptingとは何か
recursive prompting（再帰プロンプト）は、LLMが複雑な問題を小さなサブタスクに分割し、各サブタスク用の新しいプロンプトを生成して処理を繰り返す手法です。Chain of Thought（CoT）が1本の推論チェーンを伸ばすのに対し、再帰型は「問題が複雑すぎるなら分解し、単純になるまで繰り返す」という構造を取ります。
学術研究では、Prompt Recursive Search（PRS）という枠組みが提案されています。LLMが問題の複雑さを評価し、閾値を超える場合はサブ問題へ分割して再帰的に解く設計で、単純な問題に過剰な推論ステップを使わない点が特徴です（参考）。
脆弱性発見の文脈では、別の研究「VSP（Vulnerability Semantics Prompting）」が近い示唆を与えます。データフローや制御フローを段階的に追うCoT型プロンプトで、GPT-3.5-Turbo-0301が公開後のCVEから22件の真の0dayを検出したと報告されています（参考）。Hacker Houseの「recursive prompting」は、この系譜の実務応用と読めます。巨大なコードベースを一度に読み込むのではなく、関心領域を絞り込みながら深掘りする、という発想が共通しています。
5層スタックの全体像
報告された構成は、推論エンジン・モデル・APIゲートウェイ・agentフレームワーク・ハードウェアの5層に分解できます。下から順に見ていきます。
ハードウェア：NVIDIA DGX Spark
DGX Sparkは、GB10 Grace Blackwell Superchipを搭載した卓上型AIスーパーコンピュータです。CPUとGPUが128GBの統合メモリを共有するため、大規模LLMをクラウドに送らずローカル推論できます。NVIDIA公式では最大2000億パラメータ規模のモデル推論や、700億パラメータ規模までのファインチューニングを想定した製品と位置づけられています。
0day探索のような長時間・大コンテキストのagent処理では、メモリ容量がボトルネックになりやすい場面でDGX Sparkの統合メモリが活きます。ただし128GBはCPUとGPUで共有されるため、OSやキャッシュとの競合でOOM（メモリ不足）が起きる点は設計上の制約です。
推論エンジン：llama.cpp
llama.cppは、GGUF形式の量子化モデルをCPU/GPU上で動かすオープンソース推論エンジンです。Qwen 3.6のような新アーキテクチャは、llama-serverの--jinjaフラグやenable_thinkingの制御が必要になるなど、モデル世代の変化に追従しやすい点が選定理由と考えられます（参考）。
DGX Spark向けの公開構成例では、llama.cppをCUDA（sm_121）向けにビルドし、llama-serverをsystemdで常駐させる手順が共有されています（参考）。
モデル：Qwen 3.6 heretic
Qwen 3.6はAlibabaのQwenチームが公開する最新世代のLLMファミリーです。「heretic」と付くバリアントは、Hereticライブラリによる拒否応答（refusal）の除去処理を施したモデルを指します。Magnitude-Preserving Orthogonal Ablation（MPOA）で特定の重みを直交化し、有害プロンプトへの拒否パターンを弱める手法で、ベースモデルとのKLダイバージェンスを低く保ちながらガードレールを外します（参考）。
セキュリティ研究では、脆弱性の説明やPoC（概念実証）コードの生成をモデルが拒否すると調査が止まります。heretic版を選ぶのは、クラウドAPIのサイバー向け検証プログラムの代替として、ローカルで同等の自由度を確保するためと読めます。利用には倫理・法務上の責任が伴う点は明記しておく必要があります。
APIゲートウェイ：LiteLLM
LiteLLMは、100以上のLLMプロバイダーをOpenAI互換APIに統一するオープンソースのAIゲートウェイです。Python SDKとして直接使う方法と、プロキシサーバーとしてチーム全体に提供する方法があります。
ローカル構成では、llama-serverが吐き出す非標準な応答形式をOpenAI互換に揃え、上位のagentフレームワークが同じクライアントコードで接続できるようにする中継点として機能します。仮想キー管理やレート制限などの運用機能も備えています。
なお、LiteLLM自体にも2026年に権限昇格からRCEにつながる脆弱性が報告されています（CVE-2026-47101ほか、CVSS 9.9）（参考）。0day探索用の閉じた環境でも、ゲートウェイのバージョン管理とアクセス制御は必須です。
agentフレームワーク：OpenClaw
OpenClawは、自分のマシン上で動かすパーソナルAIアシスタントです。Gatewayがセッション管理とツール実行を担い、ファイル操作・シェルコマンド・Web取得などをagentが自律的に呼び出せます。再帰プロンプトの「次に何を調べるか」を決め、実際にコードを読んだりコマンドを走らせたりする実行層として使われたと考えられます。
Qwen 3.5系の推論モデルは、思考トークンを消費して応答が空になる問題があり、OpenClawとllama-serverの間にプロキシを挟んでenable_thinkingを制御する構成が公開されています（参考）。Qwen 3.6でも同様の調整が必要になる可能性があります。
OpenClawは2026年初頭に複数の重大な脆弱性（ClawJacked／CVE-2026-25253など）が報告されており、ローカルagentに高権限を与える運用ではGatewayのバインド先（127.0.0.1限定）、認証、最新版への更新が前提になります（参考）。
データの流れと再帰プロンプトの実働イメージ
全体の処理フローは次のようになります。
- OpenClawがFOSSリポジトリをワークスペースに展開する
- 再帰プロンプトに従い、まず広い範囲（エントリポイント、ネットワーク境界、権限チェック）をスキャンする
- 疑わしい箇所が見つかると、サブタスク（特定関数のデータフロー追跡、入力検証の欠落確認など）用の新プロンプトを生成する
- LiteLLM経由でQwen 3.6 hereticに推論を依頼し、llama.cppがDGX Spark上で応答を返す
- agentがファイル読み取りや静的解析コマンドで仮説を検証し、深刻度が高い候補を絞り込む
「complex FOSS code base」という表現から、単一ファイルではなく複数モジュールにまたがる解析が必要だったことがうかがえます。再帰プロンプトは、コンテキストウィンドウの限界を「今回はこのディレクトリだけ深掘りする」という分割で補う役割を果たします。
クラウドAPIとの違いと限界
今回の構成が示すのは、推論そのものをローカルに閉じ込められることです。ソースコードを外部APIに送らないため、未公開の0day調査や顧客コードの監査で情報漏えいリスクを下げられます。hereticモデルで拒否応答を抑え、OpenClawでツール実行まで自動化するのは、クラウドの安全フィルターに依存しない設計です。
一方で限界も明確です。発見数は「1件」であり、再現性や他のコードベースへの汎用性は未検証です。学術研究でも、VSPは真陽性40%にとどまり、誤検知との戦いは続きます（参考）。ローカル7BモデルでASAN（AddressSanitizer）をオラクルにした自動パイプラインのような検証ループを組む研究もありますが、今回の投稿にその詳細が含まれているわけではありません（参考）。
また、発見された0dayの責任ある開示プロセス（ベンダーへの連絡、CVE付与、パッチ確認）は、ツール構成とは別の専門領域です。技術スタックが整っても、最終的な品質は人間の検証と倫理的判断に依存します。
読者が持ち帰れるポイント
Hacker Houseの報告は、ローカルLLMエコシステムが「雑談相手」から「本番のセキュリティ調査ツール」に近づいた一例です。DGX Sparkの大容量統合メモリ、llama.cppによる高速ローカル推論、LiteLLMによるAPI統一、OpenClawによる自律的なコード調査——この組み合わせは、再現可能な設計パターンとして参考になります。
再帰プロンプトは、巨大なコードベースを人間が手作業で追う負荷を下げる発想です。完全自動化の魔法ではなく、調査の切り口を動的に生成する仕組みと捉えると現実的です。ローカルで同様の環境を組む場合は、hereticモデルの取り扱い、LiteLLMとOpenClawの既知脆弱性へのパッチ適用、対象コードの持ち込み方針を先に決めてから始めるのが安全です。