このテーマを取り上げる理由
生成AIの業務組み込みが加速するなか、「LLMに対してどのようなセキュリティテストを実施すればよいか」を体系的に整理できている組織はまだ少数です。ペネトレーションテストのように成熟したフレームワークがなく、ツール選定の判断基準も十分に共有されていません。2026年に入り、PyRIT・Garak・Promptfooといった自動化ツールが実用段階に達したことで、何を使って何を測るかを整理する好機が来ています。
基本：何を解決するツールか
AIモデルに対するred teaming1（レッドチーミング）とは、攻撃者視点でモデルの振る舞いを検証する手法です。具体的には、プロンプトインジェクション2・ジェイルブレイク3・有害コンテンツ生成・機密情報漏洩などのリスクを、組織的・反復的に検査します。
従来の脆弱性スキャナはコードやインフラを対象としていましたが、LLMのリスクは「出力の内容・傾向」に現れます。そのため、専用ツールが必要です。red teamingツールの主な役割は3点です。
- 攻撃シナリオを自動生成し、大量のテストケースをモデルに送信する
- 応答をルールベースまたはLLMジャッジで評価し、失敗を記録する
- テスト結果をレポート化し、修正前後の比較を可能にする
主な機能要素／構成要素
代表的なツールの特徴を整理します。
- PyRIT（Microsoft製オープンソース、LLM向けred teamingフレームワーク）: オーケストレーター4とスコアラーを分離した設計で、攻撃シナリオをPythonコードで記述します。Azure OpenAIとの親和性が高く、既存のMLOpsパイプラインに組み込みやすい構造です。
- Garak（コミュニティ主導オープンソース、LLM脆弱性スキャナ）: プラグイン形式でプローブ（攻撃）とデテクター（判定）を組み合わせます。CLIで実行でき、100種類以上のプローブが収録されています。
- Promptfoo（オープンソース、LLMテスト・評価フレームワーク）: YAMLでテストケースとプロバイダを定義し、複数モデルの応答を横断比較できます。red teamingモードでは攻撃シナリオの自動生成にも対応しています。
導入を検討する際の評価観点
- 対応するリスクカテゴリの範囲: OWASP LLM Top 10（LLMアプリケーションの主要リスクを10カテゴリに整理したガイドライン）やMITRE ATLASの分類と照合し、自社の脅威モデルに必要なプローブが揃っているかを確認します。
- モデルの接続方式: OpenAI互換API・Azure OpenAI・HuggingFaceのローカルモデルなど、自社の推論環境に対応しているかを確かめます。オンプレミスモデルが必要な場合は接続アーキテクチャを先に設計します。
- 判定ロジックの透明性: スコアラーがルールベースか、別のLLMをジャッジとして使うかで精度とコストが変わります。誤検知・見逃しの許容基準を先に決めておくことが重要です。
- CI/CDへの統合可否: GitHub ActionsやJenkinsからライブラリとして呼び出せるかを確認します。モデルの更新・プロンプト変更のたびに手動実行では運用が続きません。
- ライセンスと商用利用条件: オープンソースでもMIT・Apache 2.0・AGPLで商用可否が異なります。ジャッジ用LLMとして使うAPIの利用規約も別途確認が必要です。
- コミュニティ・更新頻度: LLM攻撃手法は急速に進化するため、プローブの追加速度とメンテナンス体制がツールの寿命に直結します。GitHubのコミット頻度とIssue対応状況を選定基準の一つにします。
- 多ターン攻撃への対応: Garakのプローブは基本的にシングルターン前提です。会話の序盤で無害な前提を積み上げ、後半で安全制約を崩す多ターン攻撃を評価したい場合は、PyRITのオーケストレーターや専用シナリオを併用する必要があります。
- テスト結果の失効条件: red teamingのスコアはモデルバージョン・システムプロンプト・RLHF更新に紐づくスナップショットです。プロバイダ側のモデル更新（OpenAIのDeprecation通知、Azure OpenAIのバージョン通知等）を購読し、更新トリガーでCIが再実行される構成を前提に設計します。
- 業種別の追加考慮: 金融機関はモデルリスク管理（米 SR 11-7 は FRB の監督指針 supervisory guidance であり拘束力のある規制ではない。LLM への直接適用は当局解釈を要するため 2021 年以降の 5 機関共同 RFI 等の最新当局見解を参照、国内では金融庁の有識者会議の議論）との整合、医療では検査用プロンプトに患者情報を含める場合の HIPAA・個情法の扱いを事前に確認します。EU 向けサービスを展開する場合は EU AI Act の高リスク AI（Annex III）該当性も確認し、該当する場合は Article 9（リスク管理）・Article 15（精度・堅牢性・セキュリティ）・Article 72（市販後監視）の対応として red teaming 結果を位置付けます（高リスク AI 義務の本格適用は 2026 年 8 月 2 日、GPAI Title VIII は 2025 年 8 月適用済み）。
よくある落とし穴
- 「ツールを動かした＝テストした」で終わる: red teamingツールはシナリオの実行を自動化するものであり、脅威モデルの設計はユーザー側の責任です。全プローブを実行しても、自社アプリ固有の攻撃面（システムプロンプトの内容・外部ツール連携の範囲等）が未定義であれば有意な結果は得られません。
- ジャッジにLLMを使う構成のコスト見積もり不足: LLMジャッジは精度が高い反面、1テストあたりのAPI呼び出しが2〜3倍になります。1,000件のプローブを実行すると予想外のAPIコストになるため、事前にサンプル実行でコストを試算します。
- スコアをそのまま経営報告に使う: red teamingのスコアは「このモデルはプロンプトインジェクション試行の◯%でバイパスされた」という相対値であり、絶対的なリスク量ではありません。報告時はスコアの意味と測定範囲の限界を必ず明示します。
- 標準プローブが間接プロンプトインジェクションをカバーしないことを見落とす: RAGや関数呼び出し（Function Calling）を使う環境では、外部から取得したドキュメント・メール・Webページに埋め込まれた指示がモデルを乗っ取る「間接プロンプトインジェクション」が主要な攻撃経路になります。PyRIT・Garakの標準プローブは直接インジェクション中心であり、この経路を評価するにはRAGパイプラインに外部データを注入するシナリオを自作するか、PyRITのオーケストレーターで模擬する必要があります。
一枚要約
LLMの業務組み込みが進むなか、コードや設定ではなく「モデルの出力傾向」を対象とした専用のred teamingツールが実用段階に入っています。PyRIT・Garak・Promptfooはそれぞれ設計思想と得意な接続環境が異なるため、自社の推論環境・CI/CD構成・脅威モデルと照合してから選定する必要があります。情シス・セキュリティチームは、まずGarakをローカルで試験実行し、自社モデルの出力がどのカテゴリのプローブに反応するかを把握することが最初の一手です。
今日着手できる3アクション
- Garakの試験実行:
pip install garakでインストール後、python -m garak --helpでまず現行のオプション名を確認してから単一プローブで試します（バージョンにより--model_type/--model_nameと--target_type/--target_nameの双方が存在しうるため、コピー実行前に--help出力で確認すること）。実行ごとに.report.jsonl形式でログが出力されるので、`jq` での解析や公式ダッシュボード UI でカテゴリ別の失敗を確認します。最新のオプション一覧と対応モデルはNVIDIA/garak のREADMEで確認してください。 - PyRITのデモnotebook実行: microsoft/PyRIT リポジトリを
git cloneし、doc/code/またはdoc/getting_started/配下に収録されているプロンプトインジェクション・オーケストレーターのデモnotebookをJupyterで開きます。自社のAzure OpenAIエンドポイントとAPIキーを設定し、オーケストレーターとスコアラーの動作を手元で確認します。 - OWASP LLM Top 10（2025年版）との照合: OWASP Top 10 for LLM Applications 2025 を開き、自社アプリが該当するカテゴリを特定します（LLM01: Prompt Injection・LLM02: Sensitive Information Disclosure・LLM06: Excessive Agency 等。2024年11月公開の2025年版で項目構成と番号が再編されているため、社内で過去資料を参照している組織は突き合わせ確認が必要です）。採用候補ツールのGitHubで
grep -r "prompt_injection" ./probes/やgrep -r "sensitive_information" ./probes/のようにカテゴリ名で検索し、対応プローブの有無をスプレッドシートに記録します。
AI×セキュリティの観点
攻撃者がLLMを使って高品質なフィッシング文章や悪意あるコードを生成するだけでなく、red teaming自体にLLMを組み込む手法も普及しつつあります。PyRITのオーケストレーターはLLMを攻撃生成エンジンとして活用し、前のターンの応答を踏まえて次の攻撃を動的に変化させます。これは静的なルールベーススキャナでは実現できなかったアプローチです。防御側が同じ仕組みを取り入れることで実態に近いリスク評価が可能になりますが、ジャッジ用LLM自体も誤判定を起こすため、red teamingの精度保証がLLMの信頼性問題と不可分になっている点は意識しておく必要があります。
もう一段踏み込んだ論点として、LLMがコード実行・ファイル操作・外部API呼び出しの権限を持つエージェント構成では、プロンプトインジェクション成功時の影響範囲がモデル出力にとどまらず、インフラ操作やデータ窃取まで拡大します。エージェント環境のred teamingでは、エージェントの権限スコープを明示的にシナリオに組み込み、ツール乗っ取りや権限昇格まで含めた評価設計が求められます。OWASP が整備中の「Top 10 for Agentic Applications」（草案段階、最新ステータスは genai.owasp.org で確認）がこの領域の脅威モデルとして整理を進めており、自律エージェントを業務に組み込む組織はこのフレームワークと併せて評価観点を更新する必要があります。
用語ミニ解説
- red teaming（レッドチーミング） — 攻撃者役のチームが対象システムを実際に攻撃し、弱点を探す手法。AIモデルでは、プロンプトインジェクションやジェイルブレイクなどを組織的・反復的に試験する行為を指します。 ↩
- プロンプトインジェクション — 悪意ある入力をプロンプトに埋め込み、モデルの指示や安全制約を書き換える攻撃手法。入力の検証とシステムプロンプトの保護が主な対策です。 ↩
- ジェイルブレイク — モデルの安全フィルタや利用規約に反する出力を誘導するための攻撃的プロンプト手法。「キャラクターを演じさせる」「仮定の話として話せ」などの迂回策が代表例です。 ↩
- オーケストレーター — red teamingツールにおいて攻撃シナリオの流れを制御する層。前の応答内容を参照して次のプロンプトを動的に生成する役割を担います。 ↩
コメント