Fableを超えて：ローカルLLMはセキュリティコードレビューでクラウドAIを代替できるか？

サイバーセキュリティにおいて、セキュリティコードレビューは最も価値があるが、伝統的に労働集約的なサービスの一つである。大規模言語モデル（LLM）はこのプロセスで頼りになるパートナーとなっている。数千行のコードをスキャンし、CWEデータベースを相互参照し、経験豊富なレビューアでも見逃す可能性のあるパターンを表面化する。しかし、問題がある。多くのペネトレーションテストの受領者は、自社のソースコードをクラウドホスト型サービスと共有したがらない。特に金融、政府、重要インフラの分野では、独自コードをサードパーティのLLMに送信することは、機密性とデータ主権のリスクを生み出し、LLMプロバイダーとの契約上の保護だけでは完全に緩和できない。

結果として生じるジレンマは、最高のLLMはクラウドホスト型であり、セキュリティレビューを最も必要とする企業は、しばしばこれらの最先端機能を利用できないことだ。クラウドホスト型モデルのリードは実際どれほど大きいのか？私たちは実践的な質問に答えるために着手した：ローカルホストのオープンウェイトモデルは、最先端のクラウドモデルと同等のセキュリティ発見を生み出せるか？

答えは「ほぼ可能」だが、適切な枠組みが必要だ。一連の実験でローカルLLMの限界をテストしたところ、クラウドベースの最前線モデルと連携することで最も効果的に機能することがわかった。ただし、ソースコードをクラウドに開示することはない。

わずか約30億のアクティブパラメータを持つQwen3.6-35B-A3Bモデルが、Macラップトップ上で完全に実行され、ソースコードがマシン外に出ることなく、フィンテックアプリと投票アプリの両方で、最先端のクラウドモデル（GLM-5、Claude Opus 4.6）と同等のサイズの発見セットを生成し、独自の発見もいくつか含まれていた。人間の介入はゼロで、各コードベースの完了時間は90分未満だった。核心的なタスク（コードを読み、脆弱性を発見し、重大度を分類し、CVE出力をトリアージする）において、ローカルモデルは現在、最先端モデルと同じリーグにいる。

ただし、発見数の同等性は能力の同等性を意味しない。ローカルモデルはパイプラインの一部として有用であるほど競争力があり、その発見は専門家によって同等に影響力があると認識される。この研究は定量的側面に焦点を当てているが、発見の質はペネトレーションテストの専門家と開発チームの両方によって検証された。

ローカルモデルがまだ得意としないのは、レビューの設計と結果の統合である。最も効果的なパイプラインでは、これらのオーケストレーションタスクの両方をクラウド最先端モデルに委任するが、いずれの段階でもクラウドはソースコードを見ない。これを「Source-local」と呼ぶ：独自のソースコードは決してマシン外に出ない。メタデータ（ファイルツリー、スキーマ、ルート、依存関係マニフェスト、生成されたステッププロンプト）はクラウドに渡るが、これには内部名、ディレクトリ構造、アーキテクチャが含まれる可能性がある。「ソースコードは建物外に出ない」という正確な約束であり、「何も出ない」ではない。

このアプローチを機能させる枠組みは3つの部分からなる：

1. 構造化分解とプロンプト生成：クラウドモデルがレビューを集中ステップに分解し、メタデータのみ（ファイルツリー、スキーマ、ルート、ソースコードなし）からステッププロンプトを生成する。
2. ローカルツールとLLM出力：プロンプトはローカルで実行され、標準セキュリティツール（bundler-audit、npm audit、Semgrep、Brakemanなど）を実行し、そのJSON出力をローカルモデルに供給してコンテキストトリアージと追加のバグハンティングを行う。
3. レポート統合：最後のクラウドパスがステップレベルの発見を配信可能なレポートに統合する。

パート1と3はクラウドへのソースコード露出を必要とせず、パート2は完全にローカルで実行される。結果として得られるベストプラクティスは、クラウドはプロンプトエンジニアリング、ローカルは実行、クラウドは統合というものだ。クラウドモデルはソースコードを見ることはなく、レビューを設計する。ローカルモデルは広範なアーキテクチャ推論を必要とせず、バンドルされたファイルに対する集中チェックを実行する。

Fable 5の活用：クラウドベースのオーケストレーション層はモデルに依存しない。ステージ1と3のオーケストレーターは、制限のない最先端モデルである必要はなく、サイバーセキュリティガードレール付きのモデルでも十分に機能する。Claude Fable 5（2026年6月リリース）は意図的なサイバー制限を備えて出荷され、レビュープロンプトを設計し、発見を統合する際に拒否も品質低下もなく、Claude Opus 4.8と完全に一致する。これは驚くべきことではない：防御的レビューの設計と統合は知識と構造の作業であり、悪用ではなく、オーケストレーターはソースコードに一切触れない。

重要なポイント：

1. 単一モデルではすべてが見つからない。全モデルの発見の和集合は、個々のモデルの出力よりも大幅に大きい。各モデルは質的に異なる脆弱性クラスを見つけた：Claudeはアーキテクチャ推論、GLM-5はデータフロートレーシングとツール統合、Gemma4はファイルセット内の行レベルコードパターンマッチング、Qwen3.6は広範囲のカバレッジと積極的な重大度キャリブレーション。実務者への示唆：たとえはるかに小さなモデルを使用しても、「セカンドオピニオン」モデルを実行することで真にカバレッジが拡大する。
2. プロンプトエンジニアリングはモデルサイズよりも重要。構造化されたプロセスはすべてのモデルを向上させる。例えば、Gemma4（約38億のアクティブパラメータ予算で動作）は、はるかに大きな最先端モデルが見逃した3つの本物の発見を見つけた。実行コストは安く、能力は競争力があり、ここでの違いは生の能力ではなくプロンプト設計だった。準備が必要：フレームワークの準備を省略し、Gemma4にモノリシックプロンプトを与えると、不完全な結果を生成し、出力指示を見失った。同じ範囲を6つの集中したマイクロタスクに分解し、明示的なファイルパスとgrepコマンドを添えると、Gemmaは具体的な行番号とコード証拠を含む実行可能な発見を生成した。いずれの場合も幻覚はなかった。これは、ローカルモデルの品質の上限が予想よりも高いことを示唆しているが、それに到達するには検索を導くためのフレームワークの準備が必要である。この準備作業自体を自動化できることがわかった：Claudeがファイルツリーのみ（ソースコードなし）からステッププロンプトを生成し、Qwenがそれらの自動生成プロンプトを実行すると、いずれのクラウドモデルの単一プロンプトレビューよりも多くの発見が得られた。重要なのは、Claudeが小さなモデル用にプロンプトを準備すると、その小さなモデルはClaudeがテスト全体を担当する場合よりも多くの発見を得るということである。
3. レポート品質は大きく異なる。より大きく最先端のモデルのレポート品質は明らかに優れており、これはローカルモデルが実際のテストを実行する「Source-local」レビューにおいても、それらが場所を持つことを示唆している。Claude Opusのレポートは即時配信に最も洗練されていたが、最も多くの人間の介入（執筆プロセス全体で約6回のリマインダー）を必要とした。GLM-5は最も包括的な成果物セットを生成したが、時折幻覚の出力参照がレポート品質を損なった。Qwenは正しいCWEマッピングと幻覚の証拠がない、構造化されたステップごとのレポートを生成した。Gemma4の出力は最も多くの後処理を必要とした。
4. レビューオーケストレーターは任意の有能なモデルでよく、サイバー制限付きのFableでも問題ない。サイバー制限付きの最先端モデルは有能なオーケストレーターである：Fable 5は完全なプロンプトパックと厳格な統合を生成し、拒否もなく、Opus 4.8との明らかな品質ギャップもなかった。オーケストレーターの選択によって見つかるものが変わる：Fableのターゲットを絞ったプロンプトは既知の「センチネル」バグを確実に回復したが、よりタイトなセットを生成し、一方Opusのより広いプロンプトはより大きく、場所によってはより深刻なセットを表面化した。これにはFableが決して挙げなかった重大な問題（負投票ゼロコスト投票、認証されていない投票詰め込み）が含まれ、その代償として特定のターゲットとしなかったセンチネルを見逃した。実行器と同様に、和集合はいずれかのオーケストレーター単独よりも優れている：FableはOpusより「優れている」わけではなく、並列実行するのが最適である。実務者への示唆：オーケストレーションはパイプラインの大部分がモデルに依存しない部分と見なすべきである。アクセス可能な任意の有能なクラウドモデル（制限付きかどうかにかかわらず）を使用できる。そして、ローカルモデルに2つのプロンプト設計を実行することで、第2の実行器と同様にカバレッジが拡大する。最良の結果を得るために組み合わせて使用する。

実験設定：2つの本番コードベースを異なるテクノロジースタックと脅威プロファイルで使用した：Fintech Dashboard（Next.js / TypeScript / React）と投票アプリ。