はじめに：防御における「魔法の杖」は存在しない
第1部で「確率論的脆弱性」、第2部で「攻撃手法」を学びました。ここで突き当たる現実は、「プロンプトを完璧に書けば安全」という幻想が通用しないことです。
LLMアプリケーションのセキュリティは、静的な設定ではなく、**「ゼロトラスト」**の原則――つまり「すべての入力を信頼しない」という設計思想に切り替える必要があります。
1. 多層防御（Defense-in-Depth）のアーキテクチャ
攻撃手法が多様化する現在、一つの検知ロジックですべてを防ぐことは不可能です。防御レイヤーを多層的に配置することで、仮に一つの壁が突破されても、システム全体への被害を最小限に抑える設計が求められます。
| 防御レイヤー | 手法 | 役割 |
|---|---|---|
| 入力検知層 | 入力フィルタリング (Guardrails) | 有害クエリや敵対的サフィックス（GCG）の事前排除 |
| 指示層 | システムプロンプトの堅牢化 | ユーザー入力と命令の厳格な分離（区切り文字の活用） |
| 実行層 | 最小権限の原則 (Least Privilege) | AIに渡すAPIやDBアクセスの認可範囲を最小化 |
| 出力検査層 | 出力フィルタリング | PII漏洩、有害生成物の事後検知 |
| 開発運用層 | レッドチーミング (CI/CD) | 自動化された脆弱性診断による継続的改善 |
2. ガードレールの導入：ライブラリの活用
ゼロから防御を実装するのではなく、既存のフレームワークを活用するのが2026年現在のベストプラクティスです。
NeMo Guardrails
対話フローを制御し、意図しないトピックへの遷移をブロックします。
- 利用シーン: ユーザーが「AIの役割」を逸脱しようとした際、ガードレールが割り込み、対話を元の文脈へ強制的に引き戻します。
Llama Guard (Input/Output Filtering)
専用のセーフティモデルを用いて、入出力の有害性をスコアリングします。
- 実装のポイント: LLMにクエリを投げる直前と、回答を受け取った直後の2段階でLlama Guardを通すことで、攻撃的なプロンプトの遮断と、有害な回答の隠蔽が可能です。
3. 【プロセス】自動化されたレッドチーミングの導入
脆弱性はリリース後に発見されるものです。CI/CDパイプラインに「防御のテスト」を組み込むことが不可欠です。
-
自動化された敵対的テスト:
JailbreakBenchなどのデータセットを用いて、デプロイ前に常に最新の攻撃手法（GCGなど）によるストレステストを自動実行します。 -
LLMによるLLMの攻撃 (Red Teaming LLM):
攻撃側専用のLLMを構築し、自社のアプリケーションに対して24時間体制でJailbreakingを試みさせます。そこで成功した攻撃パターンを即座に防御層へ反映させる、いわゆる「AIによるAIの防御」サイクルを構築します。
4. 観測可能性（Observability）の確保
「何が起きているか分からない」状態が最大の脆弱性です。
- 攻撃兆候の特定: フィルタリングを複数回通過しようとしたIPや、特定の難読化パターンを含むクエリをログから検出し、アラートを上げる仕組みを構築してください。
- メトリクス: 「ガードレールによる遮断率」を重要な監視指標（KPI）に置くことが、現在のLLM運用におけるセキュリティの指針となります。
結論：AI時代のセキュリティ・エンジニアリング
本シリーズを通じてお伝えしたかったのは、「脆弱性はゼロにはできない」 という事実です。
Jailbreakingはモデルの特性そのものに起因するため、完全な排除は極めて困難です。だからこそ、エンジニアに求められるのは「侵入されないこと」以上に、「侵入を即座に検知し、被害を最小化し、防御ロジックを即座にアップデートする」 という、動的なエコシステムの構築です。