第5章 — 入力検証と出力フィルタリング
『LLM Primer VII: AIセキュリティ』を章ごとに紹介していくウォークスルー、第5回。第4章で示した多層緩和アーキテクチャを運用規律へと落とし込む章 — サニタイズ段階、ガードレール類、構造化出力、レッドチーミング、そして本当に意味のある安全性メトリクスを扱う。
なぜこの章があるのか
第4章で名前を与えた4層の緩和アーキテクチャは、その各層が運用されて初めて意味を持つ。第5章はそのうちの2つを掘り下げる。ユーザー要求を検査し、通す・変換する・拒否するの判断を下す入力側と、モデルの応答がシステム外へ出る前にもう一組のゲートで再度検証される出力側だ。両者の周囲には、構造化プロンプティング、敵対的テスト、安全性計測といった規律が並ぶ。ツール群は成熟してきた — Llama Guard、NeMo Guardrails、Lakera Guard、AWS Bedrock Guardrails、Garak、PyRIT、promptfoo — そしてそれらを組み上げる運用パターンも収束してきた。
5.1 サニタイズは単発ではなく段階的なもの
「入力のサニタイズ」という言葉は、SQLインジェクション時代のニュアンスを引きずっていて誤解を招きやすい。LLMシステムにおけるサニタイズは段階的なプロセスだ — 検査し、分類し、変換し、通すか拒否するかを決める — その出力は「安全になった入力」ではなく、一連のポリシーゲートを通過し、結果が記録された入力だ。パイプラインは通常、コストの安い順に4種類のチェックを持つ。構造的チェックが最も安い。長さ制限、文字種の制約、Unicode NFKC正規化、密輸文献で頻出するゼロ幅文字や紛らわしい類似文字の除去などがここに入る。パターンベースのチェックは明示的なオーバーライドや既知の敵対的テンプレートを捕捉する。両方向にノイズが多いが、ヒットをブロックではなく記録用途として使う場合、粗いスクリーンとして役に立つ。分類チェックは専用の安全性モデル — Llama Guard、OpenAI Moderation API、Lakera や AWS Bedrock 相当品 — を使い、定義された分類体系に対して入力をスコアリングする。LLMベースのチェックは最も高コストな階層で、分類器の信頼度が中程度のときに、より小さなモデルを呼び出して意図を推論させる。各段階には偽陽性率と偽陰性率があり、本番トラフィックを預ける前に両方を計測しておく必要がある。
5.2 構造化出力は書式の便利機能ではなく防御
第4章の多層防御アーキテクチャには、本章が展開する第3の構造層がある — モデル出力を定義済みスキーマに制約することで、たとえインジェクションの影響を受けた出力であっても構造上のエンベロープから逃れられなくする、という発想だ。最も単純な形はスキーマ強制のJSONだ。モデルにはスキーマに準拠したJSONを出すよう指示し、アプリケーションがパースして検証し、非準拠出力は拒否またはリトライする。Jason Liu の instructor ライブラリは OpenAI と Anthropic のクライアントを pydantic モデルでラップする — 開発者は出力構造を記述するクラスを書き、プロンプト構築、検証、リトライはライブラリ側が担う。Microsoft Research の Guidance はさらに踏み込み、テンプレートに対してトークン単位で生成を制約し、どの位置に自由文が入りうるかを明示する。出力モデレーション側では、Meta の Llama Guard 系列 — v1 から v3、v3 でマルチモーダル対応を追加 — が 2023〜2025 年の窓においてオープンウェイト分類器の定番となり、多くの本番スタックに応答フィルタとして組み込まれている。NVIDIA NeMo Guardrails や Lakera、AWS Bedrock、Cisco AI Defense の商用製品も同じ土俵で競合している。
5.3 計測されない防御は防御ではない
レッドチーミングは、安全性の主張を計測に変える営みだ。手動レッドチーミング — 訓練された敵対的テスター、多くは外部 — はデプロイに対して通ってしまった具体的プロンプトを、攻撃パターンごとに整理して提示する。自動レッドチーミングはその手作業を入力空間全体にスケールさせる。NVIDIA Garak は 2023 年にオープンソース化され継続的に更新されている。ターゲットエンドポイントに対して一群のプローブを走らせ、どれが成功したかを報告する。プローブはプロンプトインジェクション、データ漏洩、ヘイトスピーチ誘発、エンコーディング密輸、ロールプレイ型ジェイルブレイクなどをカバーする。Microsoft PyRIT (Python Risk Identification Toolkit) は 2024 年公開で、あるモデルが別のモデルに対して攻撃を生成するエージェント型レッドチームのパターンを持ち込んだ。promptfoo は評価セットに対してプロンプトとモデルを比較する。「どの構成がより安全か」が問いなら有用だ。意味のあるメトリクスは 2 つの失敗モードから構成される。攻撃成功率は「定義された攻撃セットのうちどれだけの割合が通ったか」に答える。拒否キャリブレーションは「拒否された要求のうちどれだけが本来拒否されるべきでなかったか」に答える。攻撃成功率がゼロで拒否率が 50% のシステムは、問題を解決したのではなく、コストを「安全でない出力」から「役に立たない出力」へ移し替えただけだ。両メトリクスとも、実トラフィック分布から抽出したラベル付きサンプルを要し、また評価セット構成に条件付けられる。単一の数値だけを構成情報なしに報告するのは、安全性の主張が最も誤解を生む場所だ。
第5章が敷いたもの
第6章は検索拡張生成 (RAG) を正面から扱う。本章で展開した入力層は、ユーザーメッセージを非信頼部分として扱った。RAG システムは 2 つ目の非信頼部分を加える — 取得されたチャンクだ。その出所はユーザーメッセージほど綺麗でないことも多い。Greshake の間接プロンプトインジェクション、Liu による LLM 統合アプリケーションに対するインジェクション攻撃の性格付け、Zhong による検索コーパスの汚染、そして新しい PoisonedRAG や BadRAG の系譜が、この第2の面がどう破綻するかを描いている。第6章では RAG における信頼境界、具体的な攻撃パターン、業界が収束させたセキュア検索アーキテクチャ、そしてインシデント化する前に検索層の攻撃を浮かび上がらせる監視の実務を辿る。
次回 — 第6章: RAG のリスク。 RAG における信頼境界、悪意ある文書の混入、埋め込み経路を通じた索引汚染、そしてサニタイズをすり抜けた攻撃を検知する監視について。
