プロンプトインジェクション防御：生成型ジャッジを決定モデルに置き換える

StackOneは、プロンプトインジェクション対策である「Defender」を更新し、生成型大規模言語モデル（LLM）を専門的な決定モデルに置き換えました。2026年10月15日に公開されたエンジニアリング記事で詳細が説明されているこの変更により、防御システムの最終段階がテキスト生成を行うジャッジから、完全にローカルインフラ内で動作する確率的分類器へとシフトしました。

何が起きたか

Defenderは、外部ツールから返されるすべての結果を検査することで、ツール呼び出しエージェントを保護します。このシステムは、速度と精度のバランスを取るために3層構造のアプローチを採用しています。Tier 1は約1ミリ秒で迅速なパターンマッチングを実行します。Tier 2はCPU上で動作する22MBの分類器を使用し、数十ミリ秒で文字列をスコアリングします。従来、Tier 3では、Tier 2によってエスカレーションされた曖昧なケースを確認するために、小規模な生成型LLMに依存していました。攻撃の検出には効果的でしたが、この生成型ジャッジはGPUリソースを必要とし、1回の呼び出しあたり数百ミリ秒かかるため、コストが高く遅延も大きいという問題がありました。これらの制約のため、結果の一部しか処理できませんでした。

エンジニアリングチームは、不確実なケースだけでなく、Tier 2とともにすべてのツール結果を評価できる可能性のある、Tier 3向けのより安価で高速な代替手段を探していました。彼らは生成型ジャッジを「System One」決定モデルに置き換えました。この種のモデルは、最近TypeSafeやJevによって普及したもので、テキストを生成せずに意思決定を行います。新しい実装では、ModernBERTバックボーン上に構築された決定モデルを使用しており、これは単一の小型GPUに収まり、ローカルでホストできます。この転換により、データプライバシーを維持しながら、レイテンシとコストを削減することが可能になりました。

仕組み

System Oneモデルは、ダニエル・カーネマンの「速い直感的思考」という概念にちなんで名付けられました。オープンエンドなテキストを生成する生成型モデルとは異なり、これらのモデルはテキストやJSONなどの状態と、型付き質問セットを受け入れます。出力は厳密に事前定義されたオプションに限定されます。具体的には、多肢選択式の選択肢、数値スコア、または「ヌール（nouls）」と呼ばれる二値確率です。出力空間が閉じているため、モデルはプロンプトインジェクションを通じて長文を生成したり、拒否したり、不正な形式のテキストを作成したりするように騙すことができません。開発者が提供したオプションに対して確率を割り当てることしかできないのです。

このアーキテクチャは、セキュリティガードにとって2つの主要な利点を提供します。第一に、閉じた出力空間により、モデルが予期しない挙動へハイジャックされるのを防ぎます。第二に、出力は生成された単語ではなく、生の確率です。生成型ジャッジは「ブロック」や「許可」などの単語を選択する際に暗黙的に0.5の閾値を使用しますが、再学習中にこの閾値は予測不可能に変動します。決定モデルは明示的な確率を提供するため、エンジニアは各デプロイメントにおける許容誤検知率に基づいてカスタム閾値を設定できます。StackOneはJevのようなホスト型APIをテストしましたが、ツール結果には機密性の高い従業員記録が含まれることが多く、データプライバシー上の懸念から採用を見送りました。代わりに、自社データでオープンウェイトモデルをファインチューニングしました。

主要な詳細

• Tier 1のパターンマッチングは約1ミリ秒で完了します。
• Tier 2は、CPU上で数十ミリ秒以内に文字列をスコアリングする22MBの分類器を使用します。
• 新しいTier 3モデルはModernBERTバックボーンに基づいており、単一の小型GPUに収まります。
• 未訓練の決定モデルのゼロショット性能は、保持されたテストデータにおいて54.5%の精度でした。
• モデルは、指示、データ持ち出し要求、アイデンティティ主張に関する具体的な質問に回答します。
• Jevを用いたホスト型APIのテストでは、1回あたりのコストは$0.000025でしたが、ツールペイロードへの汎化性能は良好ではありませんでした。

なぜ重要なのか

エージェント型システムを構築するエンジニアにとって、セキュリティチェックのコストとレイテンシは重大なボトルネックです。生成型ジャッジは柔軟性がありますが、GPUを必要とし大量のテキストを解析するため、可変的なレイテンシと高い計算コストをもたらします。決定モデルに移行することで、StackOneは高リスクな分類タスクにオープンエンドな生成が必要ないことを示しました。このアプローチにより、モデル挙動に対するより厳しい制御と、より予測可能なパフォーマンス特性が可能になります。また、サンプリングまたはエスカレーションされたサブセットだけでなく、すべてのツール結果をスキャンする可能性も開かれ、コストの比例増加なしに全体的なセキュリティ体制を改善します。

データプライバシーは、エンタープライズAIアプリケーションにとって重要な制約であり続けています。多くの組織では、CRMノートやメールなどの内部データを分類のためにサードパーティAPIに送信することはできません。ローカルでオープンウェイトの決定モデルへの移行は、すべての処理を既存のインフラ内に留めることでこれに対応します。このパターンは、AIセキュリティツールにおけるより広範なシフトを示唆しています。あらゆるタスクでフロンティアモデルに依存することから、特定の意思決定境界用にファインチューニングされた専門的で小さなモデルへと向かう流れです。これにより、外部プロバイダーへの依存度が低下し、運用リスクが軽減されます。

実行できること

• 現在のプロンプトインジェクション防御を監査し、単純な分類タスクに生成型モデルが使用されている箇所を特定してください。
• パイプライン内のバイナリまたはマルチクラスセキュリティ判定に対して、System Oneまたは決定モデルを評価してください。
• 「これは安全ですか？」といったオープンエンドな質問をする代わりに、セキュリティチェック用の具体的で型付きの質問を定義してください。
• レイテンシおよびプライバシー要件を満たしていることを確認するために、ローカルハードウェアでオープンウェイト決定モデルをテストしてください。
• 許容誤検知率に基づいて、アクションをブロックするための明示的な確率閾値を設定してください。
• ゼロショット能力を超えて精度を向上させるために、自社の履歴データでモデルをファインチューニングしてください。