Garakとは？NVIDIA製LLM脆弱性スキャナーの使い方や他ツールとの違いを解説

Garak（ガラック）は、NVIDIAが開発するオープンソースのLLM脆弱性スキャナーで、プロンプトインジェクション・ジェイルブレイク・情報漏えい・ハルシネーションなど生成AIのリスクを自動検出します。
「LLM版のnmap」とも呼ばれ、PyRIT・Promptfoo・DeepTeamと並ぶ4大OSS red-teamingツールとして、本番投入前の脆弱性スキャンに広く使われています。

本記事では、構成要素と代表プローブ、インストール・使い方、結果の読み方、他ツールとの違い、NeMo Guardrailsとの攻防セット運用、実運用事例、料金、導入で詰まる論点までを解説します。

Garakとは？NVIDIAが提供するオープンソースのLLM脆弱性スキャナー

Garak（ガラック）とは、NVIDIAが開発・提供するオープンソースの大規模言語モデル(LLM)向け脆弱性スキャナーで、「Generative AI Red-teaming & Assessment Kit」の略称です。

プロンプトインジェクション・ジェイルブレイク・学習データ漏えい・ハルシネーション・有害出力など、生成AIが本番環境で起こしやすい失敗モードを自動で検出します。

Garakは「LLM版のnmap」や「LLMのMetasploit」と比較されることが多く、スキャン対象のLLMエンドポイントに大量の攻撃プロンプトを打ち込み、応答を内蔵の検出器で採点してレポートを吐き出す構造です。

大学研究発プロジェクトからNVIDIA公式スキャナーへ

もともとはIT University of CopenhagenのLeon Derczynski教授が2023年春にワシントン大学のサバティカル中に開発したツールですが、2024年にNVIDIAへ移管され、現在はNVIDIAの研究チームが保守・機能拡張を担っています。

MicrosoftもPyRIT発表時のブログでGarakを先行するOSSプロジェクトとして紹介するなど、クラウド大手・セキュリティベンダー・OSSコミュニティの垣根を越えて認知が広がっています。

Garakの構成要素と代表プローブ

Garakが「どの弱点をどう調べるか」を理解するには、内部の5層アーキテクチャと、各層に積まれたプラグインを押さえるのが近道です。

Garakの基本動作フロー：ProbesがLLMエンドポイントに攻撃プロンプトを送信し、応答をDetectorsが評価する（出典：Databricks Blog）

Databricksが整理した概観図は、Garakが外部LLMエンドポイントに対して「接続→プロンプト送信→応答評価」の3工程をどう回すかを一望する構成です。実際のGarakはこの3層に加えてBuffs（プロンプト変異）とHarness（実行管理）が組み合わさり、本文で解説する5層構成に広がっていきます。

本セクションでは、Garakを支える5つのコンポーネントと、代表的な攻撃プローブ、そしてOWASP LLM Top 10・EU AI Actといった規制フレームワークへのマッピング機能を順に整理します。

Garakを構成する5層アーキテクチャ

Garakは、以下の5層のプラグインが組み合わさって動作します。各層が独立しているため、スキャン対象のモデルや攻撃手法を自由に差し替えられる設計です。

Garak原論文 Figure 1：ProbesがBuffsで変異を加えられたうえでGeneratorsに送られ、応答をDetectorsが採点する流れ（出典：arXiv 2406.11036）

原論文の図は、Probes・Buffs・Generators・Detectorsの4要素がどう連携するかを明示しています。

Buffsは「May be amplified by」と添えられているとおり、既存プローブに符号化や言い換えを挟んで攻撃強度を増幅する役割を担います。本文で解説する5層のうち、Harnessはこの図では省略されており、全プラグインを束ねて実行する管理役として裏側で動きます。

• Generator（ジェネレーター）
  攻撃対象のLLMとの接続を担うコンポーネント。OpenAI API・Anthropic API・Hugging Face・Amazon Bedrock・Replicate・Cohere・Groq・NVIDIA NIM・llama.cpp・LiteLLM・任意のREST APIなど23種以上のバックエンドをサポートします。
  
  

• Probe（プローブ）
  攻撃プロンプトを生成する本体で、脆弱性カテゴリごとに約50種類のモジュールが用意されています。encoding・dan・promptinject・glitch・atkgen・agent-breakerなどが代表例です。
  
  

• Detector（ディテクター）
  生成器の応答を見て「攻撃が成功したか」を判定する層。キーワードマッチ・分類器・LLM-as-judge・ModernBERTベースのrefusal detectorなどを使い分けます。
  
  

• Buff（バフ）
  プロンプトを変異させて攻撃強度を高めるフィルタで、翻訳・パラフレーズ・符号化などを挟んで同じプローブの効果を増幅させます。
  
  

• Harness（ハーネス）
  スキャン実行のオーケストレーター。どのプローブをどのジェネレーターに流すか、並列度や早期終了条件を制御します。

この5層分離の最大の利点は、新しい攻撃手法が報告されたときに「Probeだけ追加すれば残りはそのまま動く」点にあります。実際、v0.15.0でAgent-breakerやGOATが追加された際も、既存のGenerator・Harness側の設定を変える必要はありませんでした。

代表プローブとそれぞれが調べる弱点

Garakには50以上のプローブが登録されており、代表的なものはRed Hatの実践記事でも引用されています。以下の表で、本番運用で特に意識すべきプローブを整理しました。

特に注目したいのは、v0.15.0以降に追加されたagent_breaker・goat・sysprompt_extractionの3つです。

これらはLLM単体の脆弱性だけでなく、AIエージェントのセキュリティで問題になる「ツール使用の乗っ取り」や「多ターン対話での段階突破」を検査できるため、エージェント型アプリを本番投入する前のスキャンに位置づけられます。

v0.16以降のCAS（Context Aware Scanning）とIntentProbe

v0.16.0で導入された**Context Aware Scanning（CAS）**は、プローブに「技術タグ（technique）」と「意図（intent）」を付与して、「攻撃技術のレイヤー」と「達成したい目的」の2軸でフィルタできる仕組みです。

IntentProbeを使えば、たとえば「ジェイルブレイク目的の攻撃だけ流す」「情報抽出目的の攻撃だけ流す」といった選択的スキャンが可能になります。

CAS以前は「カテゴリに紐づくプローブを丸ごと走らせる」運用でしたが、CAS以降は自社のポリシー（禁止意図のリスト）に沿って攻撃面を選べるようになり、実運用のCI/CDに載せやすくなりました。

OWASP LLM Top 10・EU AI Actへのマッピング

v0.17.0では、EU AI Actのリスクカテゴリに紐づく参照タグがGarakに追加されました。これはAI Actが扱うリスク領域（差別・PII・敵対的攻撃等）に対応する参照タグをプローブに付与する機能で、スキャン結果をリスク領域別に集計できます。法令上の「高リスクAI」該当性を機械的に判定するものではない点に注意してください。

OWASP Top 10 for LLMについても、各プローブがどのOWASPカテゴリに対応するかがタグで管理されています。

ただしGarak v0.17.1のタグ付けはOWASP旧版（例：LLM02をInsecure Output Handlingとする等）に合わせた分類で、OWASP公式の2025版（LLM02 Sensitive Information Disclosure 等）とはカテゴリ名が一致していません。
Garak側のタグをそのまま監査資料に貼れるのは旧版準拠の社内フレームの場合で、2025版をベースにするなら対応表を自作する必要があります。

Garakのインストールと基本コマンド

ここからは、実際にGarakをローカル環境に入れて初回スキャンを走らせるまでの手順を整理します。

本セクションでは、インストール・動作要件、基本コマンドの構造、接続先別のGenerator指定方法、そして初回スキャンでハマらないためのfast configの使い方を順に見ていきます。

Garakのインストールと動作要件

GarakはPython 3.11以上で動作します（v0.17.1時点）。基本のインストールはpip一発です。

python -m pip install -U garak

最新の開発版を試したい場合はGitHubのmainブランチを直接指定します。

python -m pip install -U git+https://github.com/NVIDIA/garak.git@main

公式ドキュメントは「Linux・macOSが推奨」としていますが、WindowsでもPowerShell環境で動作します。Qiitaの検証記事では、Windows + Ollama環境でGarakを含む3ツールを比較しており、文字コードまわりでやや注意が必要と報告されています。

インストール後は「python -m garak --version」でバージョン確認、「python -m garak --list_probes」でプローブ一覧を取得できます。

基本コマンドの構造

Garakの基本コマンドは、「どのモデルを対象にするか」と「どのプローブを走らせるか」の2つを指定するだけです。

garak --target_type <モデルファミリー> --target_name <モデル名> --spec <プローブ指定>

モデル指定名の「--target_type」・「--target_name」はv0.13.1時点ですでに利用可能で、プローブ指定の「--spec」（旧「--probes」から統一）はv0.16.0のbreaking changeで入りました。旧オプション名も互換性のため動作しますが、新規に書くコマンドは新表記で揃えておくのが安全です。

接続先別のGenerator指定

接続先ごとに「--target_type」に入れる値が変わります。代表的な接続先をまとめました。

REST Generatorを使うと、Databricksのサービングエンドポイントや自社APIなど「標準バックエンドに該当しない任意のLLM」を叩けます。

認証ヘッダ・リクエスト整形・レスポンスからの応答抽出をJSON設定ファイルで指定するだけで、Garakのプローブをそのまま流せる設計です。

初回スキャンではfast configを使う

初回スキャンで指定なしに全プローブを流すと、デフォルトで数時間〜十数時間かかります。公式FAQは、初回は「--config fast」で短縮することを推奨しています。

garak --target_type openai --target_name gpt-4o-mini --config fast --spec probes.encoding

このコマンドは「OpenAIのgpt-4o-miniに対して、encodingカテゴリのプローブだけをfast設定で流す」という意味です。

初回で感触を掴んでから、「--spec」で対象プローブを広げ、「--parallel_attempts」で並列度を上げる、という段階的なスキャンがCI/CDに乗せやすい進め方になります。

Garakスキャン実行中のCLI出力例：プローブごとに判定結果が逐次ターミナルに流れる（出典：GitHub NVIDIA/garak）

ターミナルには、プローブ名ごとに実行プログレスと成功/失敗判定が逐次出力されます。
公式READMEに掲載されているこの実行例を見ると、1プローブ内で複数のアテンプトが並列実行され、「pass」「FAIL」が右側に流れていく様子が確認できます。

CI/CDに組み込む際は、この出力を直接見るのではなくJSONLログを機械的にパースする運用に切り替えるのが実務的です。

Garakのスキャン結果の読み方

Garakは、スキャンが終わると複数の出力ファイルを吐き出します。ここで注意したいのは「レポートの数字をそのまま信じるのではなく、どのレイヤーの指標なのかを見分ける」点です。

本セクションでは、Garakが出力するファイルの種類、合格率・DEFCON・Zスコア・hit@kといった指標の意味、そしてレポートを社内に共有する際のポイントを整理します。

出力ファイルの種類

Garakは、スキャン1回につき以下のファイル群を生成します。

• report.jsonl
  全プローブ・全アテンプトのメタデータが入ったJSONL形式のログ。digestエントリに最終集計が入ります。
  
  

• hitlog.jsonl
  攻撃が成功した応答だけを抽出したログ。レビュー対象を絞り込むのに使います。
  
  

• report.html
  人間が読む用のHTMLレポート。プローブ別・検出器別の表が自動生成されます。

CI/CDに組み込むときはJSONLをパースして「DEFCON 1〜2が1件でもあればデプロイをブロック」といったゲートを作るのが定番です。HTMLレポートはそのまま社内監査・経営報告に流用できます。

DEFCON等級——5段階で深刻度を揃える

Garakは、各プローブ・検出器ペアの結果を5段階のDEFCON等級で表現します。これは軍事用語の「DEFense readiness CONdition」を借りた指標で、数字が小さいほど深刻です。公式のラベルは1から順にCritical・Very High・Elevated・Medium・Low Riskです。

DEFCON等級は複数のスキャン対象を同じ軸で比較できる点が実務上の利点です。モデルを更新するたびにレポートを並べれば、「新バージョンでDEFCON 2の項目が1件増えた」といった差分レビューが即座にできます。右列の対応方針はGarak公式の規定ではなく、本記事が提示するCI/CD運用案です。

Zスコアで校正用モデル群と比較する

Garakは、各プローブの結果をZスコアでも表示します。これはGarakが校正用に選定したモデル群（オープンウェイト優先など選定条件あり）の同じプローブ・検出器ペアの結果を分布として扱い、現在のモデルがその平均からどれだけ離れているかを標準偏差で示す指標です。

Zスコアがマイナス寄りなら「校正用モデル群の平均より合格率が低い」、プラス寄りなら「校正用モデル群の平均より合格率が高い」と読めます。

社内モデルと商用LLMを比較する際、絶対値ではなく相対位置で評価できるため、PoC段階の意思決定資料として扱いやすくなります。

hit@k Attack Success Rateで突破のしやすさを測る

v0.17.1で追加されたのがhit@k Attack Success Rateです。これは「同じプロンプトをk回試したときに少なくとも1回成功する確率」をプロンプトごとに推定し、それをプローブ・検出器ペア単位で平均した値で、report.jsonlのdigestエントリに出力されます。

たとえば1プロンプトを5回試して1回成功した場合、hit@1は20%、hit@5は100%です。

従来の攻撃成功率は「全アテンプト中で成功と判定された割合」ですが、hit@kは「少ない試行回数でも突破できるか」を測る指標です。

「1回目で突破できる確率」が高いモデルは、攻撃者にとって低コストで狙えることを意味します。CI/CDでhit@1の閾値をゲートに置くと、再現性の高い攻撃だけに絞ってブロックできます。

レポートを社内共有する際の注意点

Garakは「このモデルは脆弱だ」と断定するツールではなく、「このプローブで、この検出器が、この応答を攻撃成功と判定した」という事実を記録するツールです。レポート共有時は、以下の点を意識すると認識齟齬を減らせます。

• false positive（誤検知）の扱い
  Detectorはキーワードマッチや分類器ベースなので、文脈上は無害な応答を「成功」と誤判定する場合があります。重要な判定は人の目で見直すプロセスを挟みます。
  
  

• プローブ範囲の明示
  「--config fast」で絞ったレポートと、全プローブ版のレポートでは、同じモデルでも結果が大きく変わります。レポートの冒頭にスキャン条件を記載しておきます。
  
  

• アテンプト数の明示
  「--generations」で試行回数を増やすと、たまたまの失敗が拾われる可能性が上がります。CI用レポートはアテンプト数を固定し、再実行時の比較性を担保します。

こうした「レポートの読み方の作法」を社内で統一しておくと、Garakのレポートが開発・セキュリティ・経営の各レイヤーで共通言語として機能します。

Garakと他のLLM脆弱性スキャナーとの違い

Garakは単独で全てをカバーする万能ツールではありません。2026年現在、OSS系のLLM red-teamingツールは「4大」と「隣接商用プラットフォーム」という構図になっており、Garakの立ち位置を知ったうえで補完設計を組むのが実務的な使い方です。

本セクションでは、Garak・PyRIT・Promptfoo・DeepTeam・Giskardの違いを整理し、Garakが得意な領域と苦手な領域を切り分けます。

4大OSS LLM red-teamingツールの役割分担

複数の比較レビューで、2026年のOSS LLM red-teamingは以下の4つが代表格として挙げられます。

この表で押さえたいのは、4ツールは置き換え関係ではなく補完関係という点です。Garakは「幅広いプローブで一発スキャンする」用途に強く、PyRITは「多ターンの攻撃シナリオをPythonで組み立てる」用途に強い、という得意領域の違いがあります。

Garakの立ち位置——model endpointスキャンが中心

AI Red Teaming Toolsの2026年比較などの第三者レビューでは、Garakはプローブの幅広さと保守コミュニティの活発さが評価される一方、スキャンの主眼はmodel endpointへの単発的な攻撃プロンプト投入にあると整理されています。

agent_breakerのようにアプリケーション層を狙うプローブも導入されていますが、エージェント連鎖やRAGパイプライン全体をカバーする設計ではない、というのが共通の見方です。

具体的には、以下のような構図です。

• Garakが強い場面
  LLMをAPIエンドポイントとして公開した直後、「このモデル単体を外部から叩いたら何が起きるか」を網羅的に調べる用途。モデル差し替え時のレグレッションチェックにも向いています。
  
  

• Garakが相対的に手薄な場面
  RAGパイプライン全体・エージェントのツール連鎖・外部データソース含めた「アプリケーション層」としての深い脆弱性評価。agent_breakerで一部カバーできますが、より深くはGiskardのようなRAG・エージェント特化ツールや、商用のLakera Red・Mindgardが得意です。

この違いを前提にすると、「Garakでモデル単体を押さえ、PyRIT・Promptfooで多ターン・CI組込みを押さえ、商用製品で連続スキャン運用を押さえる」という3層構成が、現実的な補完設計になります。

PyRITとの違い——探索プローブ vs 多ターンorchestration

GarakとPyRITの棲み分けは、「用意された攻撃を流す」か「攻撃シナリオを組み立てる」かにあります。

Garakは、プローブという「ある程度完成した攻撃プロンプト集」をデフォルトで持ち、それを対象モデルに流して検出器で採点する流れです。一方PyRITは、Crescendo・Tree of Attacks等の多ターン攻撃フレームワークを「building block」として提供し、ユーザーがPythonで独自の攻撃シーケンスを組み立てる前提の設計です。

実務では、GarakをCI/CDの定期スキャンに、PyRITを「このユースケース特有の攻撃を再現したい」という場面に使い分けるケースが多く見られます。

Promptfoo・DeepTeamとの違い——評価基盤 vs 専門特化

PromptfooはCI/CDに統合しやすい評価フレームワークで、350,000以上の開発者が使っています。2026年3月にOpenAIに買収されたことで、OSS red-teaming領域にメジャー企業の資本が入りました。Garakが「脆弱性スキャン特化」なのに対し、Promptfooは「LLMアプリ全体のプロンプト評価＋red teamプラグイン」という位置づけです。

DeepTeamは1,690以上のGitHubスターを集めるred-teamingフレームワークで、エージェント・RAG・チャットボット・LLMアプリ全般を対象に50以上の脆弱性カテゴリと20以上の攻撃ベクトルを備えます。

Garakが「モデルエンドポイントの振る舞い」を中心にスキャンするのに対し、DeepTeamは「アプリケーション全体の挙動」を評価する設計です。

これらを一枚絵でまとめると、Garak = モデルエンドポイント中心のスキャナー / PyRIT = 多ターン攻撃の実験基盤 / Promptfoo = 評価＋CI組込み / DeepTeam = エージェント・RAG含むアプリ全般という切り分けになります。

自社のアーキテクチャ（モデル単体 or RAG or エージェント or 全部）に応じて組み合わせるのが、2026年現在のベストプラクティスです。

NeMo GuardrailsとGarakの攻防セット運用

Garakは「攻める側」のツールで、単独では防御を実装できません。NVIDIAは、Garakで検出した脆弱性をNeMo Guardrailsなどのガードレール実装に戻すことで、攻→防の検査サイクルを同じスタックで回せる構成を提示しています。

本セクションでは、NeMo Guardrailsの位置づけ、Garak由来のjailbreakデータで訓練されたNemoGuard JailbreakDetect、そして4段階保護構成でのスキャン実測結果を順に見ていきます。

NeMo GuardrailsとGarakの位置関係

NeMo Guardrailsは、NVIDIAが提供するオープンソースのLLMガードレール実装で、LLMアプリの入出力に「対話レール」「取得レール」「実行レール」といった複数のレイヤーを挟む設計です。GarakがLLMエンドポイントを外から叩くのに対し、NeMo GuardrailsはLLMとユーザーの間に立って不正な入出力をブロックします。

NVIDIAはこの2つを明示的に対として扱っており、公式ドキュメントにはNeMo Guardrailsの設定を4段階（bare_llm → with_gi → with_gi_dr → with_gi_dr_mo）で変化させながらGarakを走らせた比較評価が掲載されています。

NemoGuard JailbreakDetect——Garak由来の17,000jailbreakで訓練

NVIDIAが提供するNemoGuard JailbreakDetectは、ユーザー入力がジェイルブレイク攻撃に該当するかを判定する分類器モデルです。NVIDIAの開発者ブログによれば、このモデルは17,000件の既知の難易度の高いjailbreakデータセットで訓練されており、そのデータの一部はGarakによる赤チーミングを使って生成されています。

NemoGuard JailbreakDetectを含むNeMo Guardrails統合アーキテクチャ例：Content Moderation・Jailbreak Detection・PII Detectionなどの保護層とRAG・NIM LLMが組み合わさる（出典：NVIDIA Developer Blog）

アーキ図を見ると、NemoGuard JailbreakDetectはNeMo Guardrailsの中でContent Moderation・Off-Topic Detection・PII Detection・RAG Enforcementといった他の保護層と並列に動く構成が確認できます。入力プロンプトはこれらのレーンを順に通過することで、ジェイルブレイクだけでなく、ポリシー違反やPII混入など複合的な攻撃面に対応する設計です。

ここが実務的に重要です。NemoGuard JailbreakDetectの訓練には既存の17,000件のjailbreakデータセットが使われ、その一部はGarakで生成されたと公表されています。

Garak自体を継続的な学習パイプラインに接続する運用までは公開情報からは確認できないものの、少なくとも「業界で検出された攻撃パターンがGuardrailsの防御モデルに取り込まれた実績」を、Guardrails採用側は間接的に享受できる構造です。

4段階保護構成の実測——どこまで守れるのか

NVIDIA公式のLLM Vulnerability Scanning評価では、ABC-botというサンプルアプリに対して以下の4段階でGarakスキャンを実行し、保護率がどう上がるかを比較しています。

• bare_llm: 保護なし
• with_gi: 一般的な指示レール（general instructions）のみ
• with_gi_dr: 一般指示＋対話レール（dialog rails）
• with_gi_dr_mo: 一般指示＋対話レール＋モデレーション（moderation rails）の組み合わせ

結果は、脆弱性カテゴリによって保護率の上がり方が異なります。公式評価表に掲載されているDAN系・符号化回避・学習データ再生成などのカテゴリでは、一般指示レールの時点で改善が見えるものと、対話レールやモデレーションを足して初めて効き始めるものに分かれる傾向です。

この手の「ガードレールのレイヤーをどこまで積むべきか」という判断は、社内議論だけでは根拠が持てません。Garak + NeMo Guardrailsのペアで実測を取ることで、「対話レールまでで十分」「モデレーションまで入れる価値がある」といった判断材料を数字で持てるようになります。

Red HatのOpenShift AI向けハンズオン

NVIDIA公式スタック以外でも、Red Hatが2026年10月に公開したOpenShift AI向けラーニングパスが、GarakをKubernetes環境で動かすハンズオンとして公開されています。IBM Granite 3.1 8Bを対象にencoding.InjectBase64 probeで実測する流れで、検出された脆弱性に対する次のステップとしてNeMo Guardrailsによる防御実装が候補として紹介されています。

Red HatはこのパイプラインをEvalHub（Kubernetesネイティブの評価コントロールプレーン）と組み合わせることで、「モデル更新のたびに自動でGarakが走り、閾値を超えたらデプロイをブロックする」構成に拡張できると紹介しています。

Garakの実運用事例

公式スタック・ハンズオンだけでなく、実際にGarakを紹介・研究利用・評価している企業・組織の事例も複数公開されています。

本セクションでは、Databricks・NVIDIA・Microsoft・Trend Micro・Fujitsu Researchの5つを順に取り上げます。

【Databricks】REST Generator経由でホストモデルをスキャン

Databricksが2025年7月に公開した公式ブログは、Databricksホストのサービングエンドポイントに対してGarakを統合する手順を示しています。

• Python仮想環境にGarakをインストール
• Databricks REST API用のJSON設定ファイルを作成
• GarakのREST Generator経由でサービングエンドポイントにクエリ

Databricksブログは、Garakが備える150種類以上の攻撃手法のうち、DAN系15種類をDatabricksホストモデルに流した実行例を掲載しています。

例としてAntiDAN probeがジェイルブレイクを5回中5回成功させた結果が記録されており、Databricksはこの結果をダッシュボードで継続追跡する運用を推奨し、自社のAI Security Frameworkと組み合わせた継続的脆弱性管理の形を示しました。

Databricks上で生成AIアプリを運用している企業にとって、「REST Generatorの設定を1本書けば自社エンドポイントをGarakでスキャンできる」ことは、CI/CD統合のハードルを大きく下げる要素です。

【NVIDIA】NeMo Guardrailsの効果検証でGarakを併用

NVIDIA本体の公式ブログでは、エージェント型AI向けのNIM Microservices群としてNeMo Guardrails関連サービスがリリースされたと発表されています。

同ブログはGarakについて、Guardrailsによる防御効果を検査するツールとして併用できる位置づけで紹介しており、NIM経由で提供されるNemotron系モデルの脆弱性検査にもGarakを使える前提になっています。公式のデプロイ必須プロセスではないものの、NVIDIAスタックで一貫して攻防の検査・防御を回したい企業にとっては自然な採用パスです。

NVIDIAがAgentic AI保護スタックとして展開するNeMo Guardrails + NIM Microservicesのキービジュアル（出典：NVIDIA Blog）

【Microsoft】PyRIT発表ブログで先行OSSとして言及

Microsoftは、生成AIレッドチーミング用OSS「PyRIT」の公式発表ブログで、Garakを「LLMセキュリティの脆弱性スキャナーとして機能する先行プロジェクト」として明示的に紹介しています。

PyRITはGarakと競合する多ターン攻撃オーケストレーターとして位置づけられており、Garak自体をMicrosoftのフレームワークに取り込んでいるわけではありませんが、Microsoftが参照する業界レベルのOSSリストにGarakが入っていることは認知の広さを示しています。

【Trend Micro・Cisco】セキュリティ研究と検知での利用

Trend Microは言語モデル脆弱性のセキュリティ研究でGarakを研究基盤として使い、Ciscoは外部に露出したLLMサーバーの検出に関する公式記事で、Garakによる検査可能性に言及しています。両社ともGarakを「自社製品に組み込んで本番運用する」用途ではなく、研究・調査プロセスの中で参照する形で言及・活用しています。

【Fujitsu Research】独立レビューで広範な攻撃網羅と実装の堅牢さを評価

富士通研究所が2024年10月に公表した独立レビューでは、比較対象の中でGarakの攻撃プローブ範囲の広さと実装の堅牢さが特筆されています（原論文 IV-B・VI-A）。

NVIDIA公式スタックの一部としてだけでなく、第三者研究機関からも実装品質を評価されている事実は、社内でGarakを採用する際の説得材料として使えます。

こうした複数業界・複数国での紹介・研究利用・評価の積み上がりは、Garakを社内導入する際に「他社事例がない」という懸念を払拭する材料として使えます。

Garakの料金と実運用コスト

Garakは本体がオープンソースのため、ツール自体のライセンス費はかかりません。
ただし「実運用コスト」は、ツール単体ではなく複数のレイヤーで発生します。

本セクションでは、本体の料金・スキャン対象APIの従量課金・実行時間・CI/CD組込みの計算コストに分けて整理します。

Garak本体——Apache 2.0ライセンスで無料

GarakはApache License 2.0で公開されており、商用利用・改変・再配布に料金は発生しません。

独自プローブや独自検出器を社内で開発して非公開のまま運用することも、ライセンス上は問題ありません。

スキャン対象APIの従量課金が実質コスト

実運用で効いてくるのは、Garakがスキャン中に対象LLMに大量のリクエストを投げるため、対象側のAPI従量課金です。たとえばOpenAI APIを対象にすると、encodingプローブ1つで数百〜数千回のリクエストが発生することがあります。

• 1プローブあたり数百〜数千アテンプト
• 50プローブ全部走らせると数万〜十数万リクエスト
• 「--generations」で試行回数を増やせばさらに増加

本番モデルを対象にする前に、まずは安価なプロキシモデル（gpt-4o-miniやHaiku軽量モデル）で動作を確認し、本番モデルは「--spec」で絞ったプローブだけ走らせる、という段階的な運用がコスト面でも現実的です。

実行時間——デフォルトで数時間、fast configで短縮

公式FAQは、「プローブを指定せずに走らせた場合、完了まで数時間かかる」と明記しています。初回スキャンや探索的な実行では「--config fast」を使い、CI/CDに組み込む定期スキャンではプローブを事前に絞り込んで時間を数十分に収める運用が標準です。

CI/CDに組み込んだときの計算コスト設計

CI/CD（GitHub Actions等）に組み込む場合、Garakを走らせるランナー側の計算リソースと、対象API側の課金が重なります。以下の設計で収まるケースが多く見られます。

• PR単位の軽量スキャン: 1プローブ×少アテンプトで数分
• 夜間バッチの中規模スキャン: 代表5プローブ×中規模アテンプトで30分前後
• 週次フルスキャン: 全プローブ×フルアテンプトで数時間

この3層のスキャンを組み合わせると、「開発者の体感を悪化させずに」継続的な脆弱性スキャンを回せます。GitHub Advanced Securityと並走させれば、コード側の脆弱性とモデル側の脆弱性を同じPRフローで扱えるようになります。

Garak導入で詰まる論点

Garakは強力ですが、導入時に「どのスコープで使うか」「どこまで内製するか」で迷いやすいツールでもあります。本セクションでは、支援現場で実際に相談を受けやすい4つの論点に、AI総合研究所の実務観点から答えを示します。

endpoint scan vs application scanのスコープ判断

Garakで迷いやすい最初の論点が「モデルを単体でスキャンすればいいのか、RAGやエージェントまで含めてスキャンすべきなのか」です。

実務的な使い分けとしては、以下の分担が成立します。

• モデル単体をスキャンすべきケース
  商用LLMを採用する前の選定フェーズ、社内モデルを本番公開する直前のレグレッションチェック、モデル差し替え時の比較。Garakが最も効く領域です。
  
  

• RAG・エージェントまで含めてスキャンすべきケース
  社内文書を取り込んだRAG、ツール使用を伴うエージェント型アプリ。Garakのagent-breaker probeで一部カバーできますが、より深いアプリケーション層のスキャンはGiskardやDeepTeamの併用を検討する価値があります。

導入初期は「まずGarakでモデル単体を押さえ、必要になったらapplication層のツールを足す」という順序が、工数と効果のバランスで現実的です。

日本語LLMのスキャンでどこまで実用的か

Garakのプローブは英語ベースのものが多く、日本語LLMをスキャンすると「英語の攻撃プロンプトに対する応答」を評価する形になりがちです。「それって日本語での実運用を反映してるの？」という疑問が出てきます。

対策としては、以下の2段構えが有効です。

• 英語プローブで基礎的な脆弱性を押さえる
  符号化回避・プロンプトインジェクションのパターンは英語でもモデルの弱点として現れるため、Garak標準のプローブはそのまま有益です。
  
  

• 標準の翻訳機能で既存プローブを日本語化する
  Garakには実行時にプローブを翻訳する機能が標準で用意されており、設定で「target_lang: ja」と翻訳プロバイダーを指定すれば、既存の英語プローブを日本語で流せます。自作ゼロで英語プローブ資産を日本語環境に転用できる最初の選択肢です。
  
  

• 日本語の追加プローブを自作する
  Garakはカスタムプローブを追加できる設計です。翻訳では拾いきれない日本語固有のジェイルブレイクパターンを扱いたい場合、自社の日本語ユースケースに合わせた「日本語版dan」「日本語版promptinject」を数十個追加するだけで、国内運用の実態に近いスキャンが可能になります。

Garakは「英語しか扱えないツール」ではなく、「英語プローブが同梱され翻訳機能とカスタムプローブで日本語に拡張できるフレームワーク」と捉えると、日本語LLM運用でも十分活用できます。

内製Garakと商用プラットフォームの選び分け

Garakを内製で回すか、Lakera・Mindgard・HiddenLayerなどの商用プラットフォームを採用するかも、よくある相談ポイントです。

この表から分かる使い分けは、「自社のセキュリティ組織が成熟していて、スキャン運用を内製できる」ならGarak + Guardrailsで十分、「連続スキャンと新脅威への自動追従を外部に委ねたい」なら商用製品、という構図です。

中堅規模の企業であれば、Garakで基礎を押さえてから「社内の脆弱性トリアージ運用が回り始めたタイミング」で商用製品を検討する、という段階的な拡張が自然です。

CI/CDゲートの閾値設計

Garakをデプロイパイプラインのゲートに置くとき、「どのDEFCON以上でデプロイをブロックするか」「hit@1の閾値をいくつに設定するか」が運用上の分岐点になります。

経験上、以下の初期設定が実務でハマりにくい値です。

• DEFCON 1・2の検出で即ブロック: 重大・高リスクは原則通さない
• DEFCON 3は要レビュー: 自動ブロックせず、プロンプトレビューをPRに紐付ける
• hit@1 ≥ 50%でブロック: 1回目で突破できる攻撃は本番公開前に是正

この閾値は、ドメイン・利用シナリオによって上下に動かすべき値です。

社内公開のPoCでは緩め、顧客対話に使う本番システムでは厳しめ、という使い分けを前提にしつつ、初期値としてはこの3段で始めるとレポートの読み方と閾値の意味が揃ってきます。

Garakでモデルを確かめたあと、エージェントの動きは基盤の側で押さえる

Garakの主眼はモデルのエンドポイントに攻撃プロンプトを送って応答を採点することにあり、agent_breakerのようなプローブはあるものの、エージェントのツール連鎖まで深く見る設計ではありません。検査を終えたモデルを業務エージェントに載せるなら、エージェントそのものの確認と、影響の大きい処理の前で人が止める段階を、モデルの検査とは別に持っておく必要があります。

その確認と人の判断を、配る前から配ったあとまで受け持つのが、業務エージェントをまとめて管理する基盤です。AI総合研究所のAI Agent Hubは、社員がTeamsから使うAgentを、管理画面に登録してから動かします。

• モデルに加えてAgentも検査する
  Agentは管理画面への登録時にセキュリティスキャンを受けるため、Garakで調べたモデルとは別に、Agentそのものを確かめてから業務に出せます。
  
  
• 業務システムへの書き込みは人が通す
  基幹システムへの入力や申請の確定の前に、Teamsで担当者が承認か差し戻しを選ぶ段階を挟めるため、ツールの使用を乗っ取る指示が紛れても、Agentの判断だけでは処理が進みません。
  
  
• Agentを更新したら確かめ直す
  Agentごとにバージョンが管理されるため、モデルの差し替え時にGarakを回し直すのと同じく、更新したAgentを特定して業務での動きを確かめ直せます。

AI総合研究所の専任チームが、CI/CDのゲートでモデルを止める条件と、業務エージェントの承認で止める処理の切り分けから支援します。

エージェントの動きを本番前に確かめる

Agentを登録時と更新時に見直す

Garakでモデルを検査したあとも、業務で使うAIエージェントには、本番に出す前にエージェントとしての動きを確かめる段階が要ります。AI Agent Hubのサービスページのよくある質問では、本番のシステムに影響を与えずに、サンドボックス環境でAgentの動作を試せることをご紹介しています。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Garakについて、位置づけ・構成要素と代表プローブ・インストールと基本コマンド・スキャン結果の読み方・他ツールとの違い・NeMo Guardrailsとの攻防セット運用・実運用事例・料金・導入で詰まる論点までを、2026年10月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• Garakは、NVIDIAが提供する「LLM版のnmap」としてプロンプトインジェクション・ジェイルブレイク・情報漏えい等50以上のプローブで検査できるオープンソーススキャナー、v0.17.1でhit@k Attack Success RateとPython 3.14対応が加わっている
• Garakはmodel endpointスキャンに特化しており、PyRIT・Promptfoo・DeepTeam・Giskardといった他ツールと役割分担する前提で設計すると実運用で効く
• NeMo Guardrailsと組み合わせることで「Garakで攻撃面を検査→Guardrailsで防御層を実装」という攻防のペア運用がNVIDIAスタック内で成立する（JailbreakDetectは17,000件のうちの一部にGarak由来データを含む）
  
  

企業のセキュリティ担当にとってGarakは、「どのモデルを選ぶか」より「本番公開前のスキャン運用をどう設計するか」という問いに答えるツールです。まずはfast configで初回スキャンを走らせ、DEFCON 1〜2の項目をCI/CDゲートに固定するところから、継続的なLLM脆弱性管理を始めるのが現実的な第一歩になります。

AIサイバーセキュリティ全体の中でGarakが果たす役割は、「攻める側のベースラインを揃える」ことにあります。防御側のAIガードレール・AI SOCと組み合わせて、生成AIを安全に本番投入する体制を整えていきましょう。