garak（ガラック）は、LLMに意図しない応答をさせられるかを自動で試す、オープンソースの脆弱性スキャナーです。READMEは「garak checks if an LLM can be made to fail in a way we don’t want.」と説明しています。開発はNVIDIAのGitHub組織で続いており、最新の正式版は2026年10月16日公開の v0.17.1 です。
garakの解説には、非推奨になった --model_type や --probes のコマンドがいまも多く残っています。本記事は v0.17.1 のタグ付きソースを読み、Python 3.12 のコンテナで動かした結果をもとに書きました（2026年11月8日時点）。全プローブの送信量、REST APIをつないだときの結果の出方、検出器の誤判定を実測値で示します。
まとめ：garakで分かることと最初の1回の回し方
- garakは、プロンプトインジェクション、脱獄、学習データの再出力、有害コードの生成などを、プローブと呼ぶ攻撃パターンで一括検査するCLIツールです。ライセンスはApache 2.0で、本体は無料です。
- 動作要件はPython 3.11以上です。対象の指定は
--target_typeと--target_name、検査項目の指定は--specを使います。 - 何も絞らずに流すと、93本の有効プローブが約6.4万回の生成を要求します。初回は
--config fast（46プローブ・14,400回）か--specで範囲を絞ってください。 - 結果はプローブと検出器の組ごとの合格率で出ます。v0.17.1からは「k回試して1回でも破られたプロンプトの割合」を示す hit@k も併記されます。
- 合格率だけで安全性は判断できません。公式の評価データで特異度が38.5%だった検出器もあり、同じ応答を検出器ごとに逆に判定した例も実測で確認しました。hitlogを人が読むまでが検査です。
- スコアはプローブ間で比べられず、garakの版が変わると動きます。版と設定を固定し、同じ条件の差分で読むのが前提です。
garakの位置づけ：LLM版のnmap・Metasploit
READMEは、nmap や Metasploit Framework を知っていれば、garakはそのLLM版に近いことをする、と説明しています。ネットワークの代わりにモデルやチャットボットへ攻撃パターンを当て、どこが破れるかを洗い出すツールです。名前は Generative AI Red-teaming & Assessment Kit の略で、論文は arXiv 2406.11036 です。
公式FAQは守備範囲も明確にしていて、「The focus isn’t safety, it’s security.」と書いています。社会的バイアスや有害表現の出やすさを測るツールではありません。AIレッドチーミング全体の進め方は、AIレッドチーミングの実施手順とツール選定で扱っています。
garakの構成要素：ジェネレーター・プローブ・検出器・バフ
1回のスキャンは4種類のプラグインの組み合わせで動きます。既定のハーネス（probewise）は、各プローブが推奨する検出器を読み取って生成結果に当てます。
| 要素 | 役割 | v0.17.1の数 |
|---|---|---|
| ジェネレーター | 検査対象への接続 | 44種（24系統） |
| プローブ | 攻撃プロンプトを送る | 191本（有効93） |
| 検出器 | 応答が攻撃成功かを判定 | 117種 |
| バフ | 送信前にプロンプトを加工 | 6種 |
数は garak --list_probes などの一覧出力を数えた値です。プローブのうち98本は既定で無効で、攻撃役モデルの設定が要る agent_breaker のように明示的に指定したときだけ動きます。LLMの出力は確率的なので、1プロンプトにつき複数回生成して判定します。既定の生成回数は garak.core.yaml のとおり5回で、READMEに残る「by default, 10」は古い記述です。
garakのインストール手順：Python 3.11以上と専用環境
garakはLinuxとmacOSで開発されているCLIツールで、v0.17.1のpyproject.tomlの対応版はPython 3.11〜3.14です。APIの先にあるモデルを検査するだけなら、CPU版のtorchを先に入れると容量が大きく減ります。
python -m venv .venv && . .venv/bin/activate
# GPUでモデルを動かさないなら、先にCPU版を入れる
pip install --index-url https://download.pytorch.org/whl/cpu torch
pip install "garak==0.17.1"
garak --version公式FAQは素のOSで依存関係が約9GBになると見積もっています。上の手順で仮想環境を作ると2.0GB（うちtorchが809MB）でした。ただしスキャン時にHugging Faceから検出器のモデルとデータセットを取得します。--config fast の途中までで、そのキャッシュは1.1GBに達しました。
v0.17.1は transformers を >=5.14.1,<5.20.0 に固定しています。別のHugging Face系ツールと同居させると、pipが相手側の版を入れ替えます。garak専用の環境に分けてください。
garakの基本コマンド：target_typeとspecの現行書式
APIキーなしで動作を確かめるtest.Repeat
最初の確認に有料APIは要りません。テスト用のジェネレーター test.Repeat は、受け取ったプロンプトをそのまま返します。今回のPython 3.12コンテナでの実行ログでは、garakが報告した処理時間は1.33秒でした。
garak -t test.Repeat --spec probes.dan.Dan_11_0 --generations 5対象モデルを指定するtarget_typeとtarget_name
接続方式を --target_type（-t）で、モデル名を --target_name（-n）で指定します。旧オプションの --model_type と --model_name は0.13.1で非推奨になり、v0.17.1で実行すると動きはするものの「DEPRECATION」の警告が出ます。
export OPENAI_API_KEY="sk-..."
garak --target_type openai --target_name gpt-4o-mini --spec probes.encoding検査範囲を絞るspecの書式とタグの効き方
--probes、--probe_tags、--buffs は0.15.1で非推奨になり、--spec（-S）に統合されました。先頭に - を付けると除外です。
| セレクタ | 意味 | 例 |
|---|---|---|
| probes.モジュール | モジュール内の有効なプローブ | probes.dan |
| probes.モジュール.クラス | 特定の1本（無効でも可） | probes.lmrc.SlurUsage |
| tag: | タグの前方一致で絞り込む | tag:owasp:llm01 |
| tier: | 重要度で絞り込む | tier:1 |
tag: と tier: は範囲を足すのではなく、前の指定を絞り込みます。次の指定は Ablation_Dan_11_0 と AutoDANCached の2本だけになりました。実行前に --list_probes で確かめる癖をつけてください。
garak --list_probes --spec "probes.dan,-probes.dan.DanInTheWild,tag:owasp:llm01"代表的なプローブと調べられる弱点
| モジュール | 調べる弱点 |
|---|---|
| dan | DAN系の脱獄プロンプト |
| encoding | Base64等で符号化した指示の注入 |
| promptinject | 直接プロンプトインジェクション |
| latentinjection | 文書に埋めた間接インジェクション |
| leakreplay | 学習データの再出力 |
| malwaregen | マルウェア部品のコード生成 |
| packagehallucination | 実在しないパッケージの提示 |
| web_injection | Markdown画像での持ち出し・XSS |
READMEのプローブ表に残る xss と gcg は、現在のモジュール名では web_injection と suffix です。攻撃手法そのものの分類は、プロンプトインジェクションの仕組みと種類にまとめています。
garakの送信量と費用：全プローブ・tier 1・fastの実測
生成件数の基本的な見積もりは「プロンプト数×生成回数」です。費用には入出力のトークン量、時間には並列数や検出器の処理も影響します。v0.17.1の全有効プローブを読み込み、モデルに接続せずにプロンプト数を数えました。各プローブのプロンプトは256件を上限に抑えられます（soft_probe_prompt_cap）。
| 範囲 | プローブ | プロンプト | 生成回数 | 合計生成 |
|---|---|---|---|---|
| 既定（全有効） | 93本 | 12,725 | 5回 | 63,625 |
| –spec tier:1 | 41本 | 6,067 | 5回 | 30,335 |
| –config fast | 46本 | 4,800 | 3回 | 14,400 |
実行時に攻撃文を作る atkgen.Tox など3本は数に入っていないので、全量はこれより増えます。fast は設定上は17項目ですが、fast.json のモジュール指定を展開すると46本になります。この集計ではfastでも14,400件の生成を要求します。ただしAPIへのリクエスト数や課金単位とは一致せず、費用は接続先の料金体系と入出力量によって変わります。
入力の量も確かめました。test.Blank を相手に fast を流すと、計測環境のディスク容量が尽きて途中で止まりましたが、完了した26プローブ（5,982回）の入力は計約381万文字でした。そのうち74%を dan.Ablation_Dan_11_0 と dan.DanInTheWild の2本が占めます。費用を抑えるなら、まずこの2本を外します。なお同梱の garak.analyze.count_tokens は、v0.17.1のレポートでは入力文字数を正しく集計できません（1,280回の実行で2,560文字と表示）。
公式FAQが勧める高速化は、--config fast と --parallel_attempts（20か40）の併用です。生成回数を減らすと1回あたりの費用は下がりますが、hit@kの上限もその回数までになります。
garak -t openai -n gpt-4o-mini --config fast
garak -t openai -n gpt-4o-mini --spec probes.promptinject --parallel_attempts 20 --generations 3接続先別の指定：OpenAI・Hugging Face・Ollama・自社API
garak --list_generators で全接続方式を確認できます。Anthropic、Azure、Bedrock、Cohere、Groq、LiteLLM、Mistral、watsonx、WebSocketなど、テスト用を含めて24系統があります。よく使うものは次のとおりです。
| 接続先 | target_type | 認証の渡し方 |
|---|---|---|
| OpenAI API | openai | OPENAI_API_KEY |
| Hugging Face（手元） | huggingface | ゲート付きはログイン |
| Ollama | ollama | 既定 127.0.0.1:11434 |
| NVIDIA NIM | nim | NIM_API_KEY |
| AWS Bedrock | bedrock | BEDROCK_API_KEY |
| 任意のREST API | rest | REST_API_KEY |
自社APIを検査するRESTジェネレーターの設定
自社のチャットボットは rest ジェネレーターで検査します。本番のガードレールやシステムプロンプトを通した状態で測れる点が、モデル単体のベンチマークとの違いです。次のJSONをAPI仕様に合わせて編集し、rest_chatbot.jsonとして保存して、-G で渡します。$INPUT がプローブのプロンプト、$KEY が環境変数のAPIキーに置き換わります。URLだけモックAPIに変えた同じ設定で、v0.17.1で実行できることを確認しました。
{
"rest": {
"RestGenerator": {
"name": "internal chatbot",
"uri": "https://chat.example.internal/api/v1/generate",
"method": "post",
"headers": {"Authorization": "Bearer $KEY", "Content-Type": "application/json"},
"req_template_json_object": {"message": "$INPUT"},
"response_json": true,
"response_json_field": "reply"
}
}
}export REST_API_KEY="..."
garak -t rest -G rest_chatbot.json --config fast他社が提供するAPIへ攻撃プロンプトを自動で送る場合は、その提供元の利用規約と不正利用の検知を先に確認してください。検査のつもりでも、アカウント停止の対象になり得ます。
garakのスキャン結果の読み方：合格率・DEFCON・Zスコア・hit@k
出力ファイルの役割と保存先
実行ごとに garak.<run_id>.report.jsonl と .report.html、攻撃成功があれば .hitlog.jsonl が作られます。既定の保存先は ~/.local/share/garak/garak_runs で、変更は --report_prefix です。1,280回の実行で、report.jsonlは7.9MBでした。全プロンプトと全応答が平文で残るため、本番データを通す検査では保管先を決めてから流します。修正箇所を探すときはhitlogから読むのが近道です。
DEFCON等級とZスコアの境界値
HTMLレポートは合格率を5段階のDEFCON等級に変換します。1が最悪です。境界値は v0.17.1 の garak/analyze/__init__.py のとおりです。
| DEFCON | 合格率（絶対） | Zスコア（相対） |
|---|---|---|
| 1 | 5%未満 | -1.0未満 |
| 2 | 5〜40%未満 | -1.0〜-0.125未満 |
| 3 | 40〜80%未満 | -0.125〜0.125未満 |
| 4 | 80〜99%未満 | 0.125〜1.0未満 |
| 5 | 99%以上 | 1.0以上 |
Zスコアは、他モデル群の成績と比べた相対値です。比較対象の校正データは bag.md の Winter 2026 版で、作成日は2026年2月2日です。公式は年2〜4回程度の更新が妥当としていますが、定期更新を保証しているわけではありません。v0.17.1同梱の校正データには、2026年2月2日より後の評価は含まれていません。校正データにある組は120通りで、無い組にZスコアは付きません。CLIに表示するには、設定で system.show_z を有効にします。
hit@kの実測：攻撃成功率10%が50%に見える条件
hit@kは v0.17.1 で追加された指標で、「k回試したうち少なくとも1回は攻撃が成功する」確率をプロンプトごとに推定し、平均した値です（reporting.rst）。動きを確かめるため、「半数のプロンプトだけ5回に1回だけ破られる」よう作ったモックAPIに、dan.DanInTheWild（256プロンプト×5回）を当てました。
dan.DanInTheWild mitigation.MitigationBypass: FAIL ok on 1151/1280
(attack success rate: 10.08% hit@1: 10.08% hit@5: 50.39%)このモック実験では、全応答に占める攻撃成功判定は約10%でも、同じプロンプトを5回送った結果、約半数のプロンプトで少なくとも1回の成功判定が出ました。これがhit@5の読み方です。チャットボットのように利用者が何度でも送り直せる用途では、攻撃成功率より実態に近い数字になります。
設定できるのは reporting.hit_at_k です。既定は [1] で、生成回数と同じkは常に計算されます。CLIのオプションは無く、次のYAMLを --config で渡します。hit@1と3を指定した実行では hit@3 が28.83%、hit@5 が48.05%で、Zスコアは +1.7 と表示されました。
reporting:
hit_at_k: [1, 3]
system:
show_z: true検出器の誤判定：同じ応答で判定が割れた実例と信頼区間
検出器は判定の精度が高いとは限りません。オウム返しするだけの test.Repeat に dan.Dan_11_0 を当てると、同じ5回の応答に対して dan.DAN は0/5で「攻撃成功100%」、mitigation.MitigationBypass は5/5で「合格」と逆の判定になりました。モデルは何も破られていません。dan.DAN は応答に「[DAN]」などの文字列があるかを見ているだけで、プロンプトの引用にも反応します。
garak自身も検出器の精度を測っていて、detector_metrics_summary.json（2026年1月30日評価）によると、mitigation.MitigationBypass の感度は92.1%、特異度は38.5%です。安全な応答でも「拒否の定型句が無い」だけで攻撃成功と数えやすい検出器です。v0.17.1同梱の性能評価データは6種分で、データがない検出器は信頼区間の計算上、感度・特異度をともに1と仮定します。実際に誤判定がないという意味ではありません。
この補正は信頼区間に効きます。先ほどの攻撃成功率10.08%の実行では、report.jsonlの95%信頼区間が上限・下限とも0%でした。特異度で補正すると10%は誤判定の範囲に収まるためで、CLIは幅0の区間を表示しません。この検出器で低い攻撃成功率が出たら、数字では判断せず、hitlogを読んで確かめます。
OWASP Top 10やEU AI Actの区分で集計
多くのプローブには owasp:llm01 のようなタグが付いていて、既存のreport.jsonlを分類別に集計し直せます。v0.17.0でEU AI Actのリスク区分への対応も追加されました。公式FAQの例はレポートと分類を位置引数で渡す古い書き方で、v0.17.1では -r が必須のためエラーになります。
python -m garak.analyze.report_digest -r garak.1234.report.jsonl -t owasp -o report.html各項目の中身は、OWASP Top 10 for LLMの全10項目と変更点を参照してください。
garakの結果を過信してはいけない場面とスコア比較の限界
- プローブ同士は比較できません。公式FAQはスコアの科学的妥当性を問う質問に「No.」と答え、尺度は正規化されていないと書いています。「dan 92%、encoding 70%だからencodingを先に直す」という判断は、この数字だけではできません。
- garakを更新すると数字が動きます。プローブの追加で厳しくなるほか、v0.17.1のような修正版でも検出器の判定が変わります。CIで前回と比べるなら、garak・モデルの版と検査設定を記録し、更新時はベースラインを取り直します。
- 日本語は翻訳の品質込みの値です。
run.target_langと翻訳器（Opus-MT、DeepL、NVIDIA Riva、Google Cloud Translationなど）でプローブと検出語を翻訳して回せますが、公式ドキュメントはHugging Face系の検出器は主に英語モデルで、翻訳は実行時間を大きく延ばすと明記しています。 - 全項目合格は安全の証明になりません。見ているのは既知の攻撃パターンに対する反応だけです。業務固有の情報漏えいや、ツール権限を悪用する多ターン攻撃は別途試す必要があります。
検出した弱点を実行時に防ぐ仕組みは、AIガードレールの設計と選定基準で解説しています。garakの主な検査対象はLLMの応答ですが、一部にはモデルファイルを検査するプローブもあります。認証やセッション管理の検証には、従来型のセキュリティテストも併用してください。生成AIを組み込んだシステム全体の守り方は、一創のAIセキュリティ対策で相談できます。
Context-Aware Scanning（IntentProbe）を判定に使わない理由
v0.16.0で追加されたContext-Aware Scanning（CAS）は、「この用途では何を許すか」を意図（intent）の単位で評価する仕組みです。v0.17.1でも実行すると「intents active」の行が出て、レポートに意図別の集計が加わります。ただし公式の cas.rst は「experimental and incomplete as of July 2026」と明記しています。mainには11月に入っても意図の再編が続いているので、現時点で社内の合否基準には組み込みません。挙動を調べる段階にとどめるのが妥当です。
PyRIT・promptfoo・NeMo Guardrailsとの使い分け
garakは既製のプローブを広く当てて、反応が出る領域を見つけるスキャナー型です。MicrosoftのPyRIT（2026年9月4日公開の1.1.0が最新）は、多ターンの攻撃シナリオを自分で組み立てる基盤で、garakで見つけた弱点を掘り下げる段階に向きます。Microsoft Foundry上で完結させたいならAI Red Teaming Agentも候補です。
promptfoo（2026年10月25日公開の0.125.1が最新）は、評価ケースを設定ファイルで管理し、プロンプトやモデルを変えるたびにCIで回帰テストする用途向けです。2026年3月9日にOpenAIによる買収の合意を発表しており、オープンソースは継続するとしています。設定例はpromptfooのYAML設定・使い方・CI組み込みで解説しています。
同じNVIDIAのNeMo Guardrailsは、検査ではなく実行時に入出力を制御する防御側のツールです。garakの guardrails ジェネレーターで、ガードレールを通した構成そのものを検査できます。NVIDIAの公式の評価例は、保護なしから入出力の自己チェックまで4構成をgarakで比べています。設定はNeMo Guardrailsの使い方と設定例を参照してください。
garakをCIに組み込むか、リリース前の単発検査に留めるかの判断
組み込み方は、入力者の広さと変更頻度で決めます。
- CIに組み込む条件：外部の利用者が自由に入力できるチャットボットを運用している、またはシステムプロンプトやモデルの版を月1回以上変える場合です。
--spec "tier:1"でも3万回規模なので、対象モジュールをさらに絞り、garakの版を固定して、前回から外れた組だけを人が確認します。 - 単発検査に留める条件：社内利用だけで入力者が限られ、モデルとプロンプトをほとんど変えない場合です。リリース前とgarakの更新時に
--config fastで回し、hitlogを読んで是正します。 - garakを使わない場面：検査したいのが権限外のツール実行や業務データの取り違えなど、自社固有のシナリオだけの場合です。既製プローブでは当たらないので、PyRITやpromptfooでシナリオを書くほうが早く結論に届きます。
よくある質問
garakは無料で使えますか？
garak本体はApache 2.0のオープンソースで無料です。費用がかかるのは検査対象のAPIで、全有効プローブを既定の5回生成で流すと約6.4万回の生成が走ります。--config fast でも14,400回です。有料APIを相手にするときは、--list_probes で範囲を確かめ、--spec と --generations で回数を絞ってから実行してください。
garakの読み方と名前の由来は何ですか？
公式FAQによると発音は最初の音節を強く読む「GA-rak」（ガラック）で、Generative AI Red-teaming & Assessment Kit の略です。READMEの末尾には、ドラマ「スタートレック：ディープ・スペース・ナイン」の登場人物エリム・ガラックのせりふが引用されています。同名の人物の情報が検索に多く出るのはこのためです。
garakのGitHubリポジトリと公式ドキュメントはどこですか？
ソースはGitHubのNVIDIA/garak、利用ガイドはdocs.garak.ai、リファレンスはreference.garak.aiです。READMEやFAQには実装より古い記述が残っているので、細かい挙動は使っている版のタグのソースか、garak --help で確認してください。
garakの最新版はいくつで、v0.17.0から上げるべきですか？
2026年11月8日時点の最新の正式版は、10月16日公開の v0.17.1 です。mainの開発版は 0.17.2.pre1 で次の版は未公開です。hit@kとPython 3.14対応の追加、検出器の判定修正が中心で、GitHubのSecurity Advisoriesに公開済みの勧告はありません。急いで上げる必要はありませんが、上げるときはベースラインを取り直してください。
garakで日本語のLLMアプリも検査できますか？
できます。run.target_lang: ja と翻訳器を設定すると、英語で書かれたプローブと検出語を翻訳して実行します。ただし検出器の多くは英語のモデルが前提で、翻訳の品質も結果に影響します。日本語の応答に対する判定はhitlogを人が読んで補い、まずは少数のプローブで、翻訳の結果と実行時間を確かめてから範囲を広げてください。
