garak.aiと生成AIの「安全性評価」――レッドチーミングが法にもたらすもの雑感

0　はじめに

　年越しに書き溜めたAIに関して役立つ資料について雑感を付して7点掲載する。今年も皆さんにとっていい年であることを心より祈念する。

　生成AI、とりわけ大規模言語モデル（LLM）の実装が企業の実験室から社会の実働環境へと移行するにつれ、その議論の重心は「性能（Performance）」から「安全性（Safety）」、そして「信頼性（Trustworthiness）」へと急速にシフトしている。かつてはモデルがどれほど流暢に詩を詠めるかが問われたが、現在はモデルがどれほど確実に差別的言動を抑制し、プロンプトインジェクションに耐えうるかが問われている。現場の実感としても、モデルが賢くなる速度より、ガバナンス文書が増殖する速度の方が遥かに速い。

　もちろん、説明責任を果たす上で文書は必要である。しかし、分厚い規定が積み上がるほど、現場には「結局、テスト結果のスクリーンショットがあれば安心なのか」という、素朴だが極めて厄介な問いが澱（おり）のように溜まっていく。

　今回は、その問いを解きほぐすための具体的な材料として、LLM向けの脆弱性スキャナである「garak」を取り上げる。garakは「Generative AI Red-teaming & Assessment Kit」を標榜し、モデルやシステムのセキュリティ評価に用いることを想定したオープンソースのツールである。1)　NVIDIAとコミュニティによって活発にメンテナンスされているこのツールは、技術的な脆弱性診断の文脈のみならず、法的な説明責任の所在を考える上でも示唆に富む。

　法学研究者、企業のAI担当者、そして一般の読者にとっても、レッドチーミング（攻撃的な試験）という営みが、単なる「技術的なデバッグ」から、法的な「注意義務の履行証明」へと変貌しつつある現状を理解することは、極めて重要である。

1　問題の所在

　AIの安全性評価において、我々はしばしば「単一指標化」の強烈な誘惑に駆られる。リスクを定量的な数値に落とし込み、明確な合格ラインを引き、チェックボックスを埋める。それによって組織は安心感を得られ、規制当局への説明も容易になるからである。しかし、生成AIが内包するリスクは、①内容（有害表現、誤情報、幻覚）、②情報セキュリティ（個人情報の漏えい、学習データの再識別）、③行為の誘発（プロンプトインジェクションによる権限昇格、不正なツール呼び出し）、④社会的影響（バイアス、差別、世論操作）といった、性質の全く異なる領域に無秩序に散らばっている。これらを単一の「安全性スコア」として平均化することは、実態を見誤らせる危険性を孕んでいる。

　ここで法的に重要となるのは、この「平均化」が、しばしば「法的評価の失敗」と直結するという点である。不法行為法における過失の有無であれ、契約法上の善管注意義務であれ、法は常に具体的な状況（コンテクスト）に即して評価を行う。「どのリスクを、どのような利用文脈で、どの程度のコストをかけて管理したか」こそが問われるのであり、文脈を剥ぎ取った「95点」というスコア自体には、法的な免責力はほとんどない。

　加えて、生成AIによる事故の多くは、モデル単体の欠陥ではなく、プロンプトエンジニアリング、RAG（検索拡張生成）による外部知識の参照、外部ツールの呼出し権限、ログ監視体制などが複雑に結合した「システム」としての挙動において発生する。このシステム全体の相互作用を捨象してモデル単体の性能だけを評価しても、ガバナンスとしては空転する。

　とりわけ、欧州AI規則（EU AI Act）をはじめとする規制対応の現場では、スコアが「説明の省略」の口実として機能しがちである。しかし、ひとたび事故が発生すれば、「なぜそのスコアを信頼に足ると判断したのか」「なぜそのテスト範囲で十分だと考えたのか」というプロセスそのものが遡及的に問われることになる。評価とは、組織にとって安心の道具である前に、将来の紛争に備えた責任の履歴として機能しなければならない。

2　garakという道具の位置づけと「スキャン」の含意

　garakというツールの興味深さは、それが万能の安全証明書を発行するものではなく、むしろ「失敗のさせ方」を体系化しようとしている点にある。GitHub上のREADMEドキュメントは、garakが幻覚（hallucination）、データ漏えい、プロンプトインジェクション、誤情報、毒性生成、脱獄（jailbreak）等、LLMが抱える多種多様な弱点をプローブ（probe）することを明示している。2)

　さらに開発者が、ネットワークセキュリティの分野で著名な「nmap」や「Metasploit」といったツールに言及し、LLMに対する探索的なスキャンに近い作法を示している点は示唆的である。2)　また、特定のベンダーに依存しない設計として、Hugging Face上のモデルや各種商用API、あるいはPythonスクリプトやREST経由で到達できる「だいたい何でも」を評価対象にしうる柔軟性も確保されている。2)　ベンダーロックインを回避し、マルチモデル運用が一般化しつつある現在の企業実務において、評価手法の移植性（Portability）が高いことは、コンプライアンスコストの観点からも重要である。

　garakは、静的・動的・適応的（adaptive）なプローブを組み合わせ、対話システムの失敗を探索する。2)　ここには、攻撃手法が固定的なテストケースの羅列ではなく、相手の応答に応じて動的に形を変えるという、LLM特有の性質への適応が見て取れる。法的な観点から見れば、この「相互作用性」こそが、予見可能性（Foreseeability）や管理可能性の判断を難しくしている主因である。固定されたプログラムに対するバグ出しとは異なり、確率的に振る舞うAIに対しては、「あらゆる入力に対して安全である」と断言することは論理的に不可能に近い。

　この文脈において、「スキャン」という比喩は極めて的確である。セキュリティの世界において、ポートスキャンは「侵入可能な穴」を探す行為であり、「侵入が不可能であること」を証明する行為ではない。同様に、garakのレポートが示すのは「特定の条件下において、モデルが防御壁を突破された」という事実の記録（Falsification）であって、「あらゆる条件下で安全である」という保証（Verification）ではない。

　ここに、ガバナンス上の二つの落とし穴が生じる。第一に、スキャン結果において「検出なし」と出たことが過剰に一般化され、安全の免罪符として流通する危険である。第二に、逆にスキャン結果の悪さが過剰に恐怖を煽り、本来許容可能なリスクまで遮断して実務を硬直化させる危険である。どちらも、評価という営みを、思考を停止させるためのトリガーに変えてしまう点で共通している。

3　断片化する安全と規制の設計

　他方で、これまで研究者やハッカーのコミュニティ主導で行われてきたレッドチーミングが、規制の枠組みの中に正式に吸収されつつあるのも事実である。EU AI Actは、汎用目的AI（GPAI）モデルのうち「システミック・リスク（systemic risk）」を伴うものについて、標準化されたプロトコルや最先端のツールを用いたモデル評価、敵対的テスト（adversarial testing）の実施と文書化、重大インシデントの追跡・報告、適切なサイバーセキュリティの確保等を義務付けている。3)4)

　ここで規制当局が要求しているのは、結果としての完全無欠な安全ではなく、プロセスとしての評価能力とリスク管理能力である点に強く留意すべきである。

　この法規制の設計は、ある意味で技術的限界に対して正直である。生成AIの安全性は、開発段階ですべて予見できるものではなく、事後的に、あるいは運用の中でしか判明しないことが多い。しかも事故は、モデルの内部パラメータだけでなく、その周辺にあるプロンプト設計、権限管理、ログデータの扱い、そして利用者の予期せぬ行動によって引き起こされる。

　したがって、法律が現実的に事業者に要求できるのは、(a) 何を危険と見なすかの地図を描き、(b) それを客観的なツールで測り、(c) 状況の変化に応じて管理し続ける仕組みを持て、ということになる。EU AI Actが、具体的な安全基準の数値を法律に書き込むのではなく、コード・オブ・プラクティス（行動規範）や調和規格への準拠によって適合性を示しうるとするアプローチを採っているのも、技術の進歩に合わせて手続の外形を整えさせる意図の表れであろう。4)

　これを裏返せば、単に評価ツールを回して「実施しました」という既成事実を作るだけでは足りず、その結果を文書化（説明可能性の確保）し、具体的な改善（リスク低減措置）につなげることがセットで求められるのである。

　加えて、評価結果の取り扱いは、透明性の要求と鋭く衝突しうる。EU AI Actは、システミック・リスクを伴うモデルに関する情報や文書（営業秘密を含む）について、提供を受けた機関や専門家が秘密保持義務の下で扱う旨を定めている。4)　これは、レッドチーミングの結果が「公表すれば安全になる」という単純なオープンソース・ソフトウェアの物語とは異なる力学で動いていることを示唆している。AIの脆弱性情報は、共有されなければ是正が進まない一方で、無防備に共有されすぎれば攻撃のヒント（Attack Surface）を広げることにもなる。法は現在、このジレンマを、一般公開ではなく「当局への提供＋秘密保持」という閉じた回路の中で処理しようと試みている。企業実務においては、この点が契約条項（監査権限、報告範囲、守秘義務、インシデント通知のトリガー）として具体化されることになる。

4　評価をガバナンスへ接続する枠組み

　garakのようなツールによる評価を、単なる道具から組織の統治（Governance）へと接続する際に、参照枠組みとして有用なのがNIST（米国国立標準技術研究所）のAIリスク管理フレームワーク（AI RMF）である。AI RMFは、GOVERN（統治）、MAP（特定）、MEASURE（測定）、MANAGE（管理）という四つの相互に関連する機能を提示し、コンテクストを踏まえたリスク管理の反復を促している。5)　また、生成AI向けに特化したプロファイル（NIST AI 600-1）においては、ガバナンス、コンテンツの来歴（provenance）、デプロイ前のテスト、インシデント開示といった論点を軸に、より具体的な行動例を提示している。6)

　この文脈において、テストツールを選定・運用する際の論点は、単なる脆弱性の検出率の高さだけではない。再現可能性（同じ入力で同じ失敗を再現できるか）、説明可能性（どのプローブが何を狙った攻撃であり、なぜ防御に失敗したか）、そして記録可能性（誰がいつ、どの設定・バージョンでテストを回したか）が極めて重要になる。

　将来的に訴訟や行政調査の対象となった場合、問われるのは「テストを実施したか」というバイナリな事実よりも、「どのような前提条件で、どう実施し、その結果をどう評価したか」という判断の合理性だからである。

　garakのようなスキャナは、AI RMFの枠組みにおいては主に「MEASURE」の領域に位置づけられる。測定は不可欠であるが、測定だけではリスクは減らない。測定結果を受けて、(1)誰の意思決定プロセスを、(2)どのタイミングで停止あるいは変更し、(3)どの権限でモデルの更新やガードレールの強化を行うのか、があらかじめ決まっていなければ、測定は単にリスクを観測して満足する儀式に堕する。

　逆に、「GOVERN」の機能と強固に接続された測定は、組織内部での説明責任を果たし、さらに外部（規制当局、取引先、利用者）への信頼醸成にも転用可能となる。要するに、レッドチーミングを「リリース前の年一回のイベント」として扱うか、「継続な運用の一部（DevSecOps）」に落とし込めるかが、法的リスク管理の分水嶺となるのである。

5　雑感

　garakを実際に動かしてみると、「安全性評価の民主化」という言葉が頭をよぎる。これまでは大手AIベンダーの内部や一部の専門家集団に閉じていたレッドチーミングのプロセスが、オープンソースツールによって可視化され、誰もが手元で一定の脆弱性探索を行えるようになるからである。1)

　しかし他方で、この民主化は同時に「乱用可能性の民主化」でもあり、「誤解の民主化」でもある。出力されたレポートのグラフが独り歩きし、実態を伴わないコンプライアンスの飾りとして利用される。あるいは、断片的なレッドチームの結果が切り貼りされ、SNS上で特定のベンダーを攻撃する材料として消費される。そのような光景は容易に想像できる。

　法の側が目指すべきは、特定のツールの有無を形式的に問うことではなく、その評価の位置づけを誤らないよう導くことであろう。テストは「安全の証明」ではなく「危険の探索」であり、探索の実施は責任の免除ではなく、発見されたリスクに対する「責任の開始」を意味する。

　生成AIに関する法的規律は、当面の間、厳格な結果責任よりも、適切なリスク管理体制を求めるプロセス規制に軸足を置くであろう。EU AI ActやNISTの文書が示す方向性は、まさにその兆候である。3)5)　そのとき、レッドチーミングは「実施したか否か」という形式ではなく、「実施結果が組織の統治（ガバナンス）に実質的に接続されているか」という実態が問われることになる。

　garakは、その評価の入り口としては十分に魅力的かつ強力なツールである。しかし、入り口が広くなり、誰でも容易に入れるようになるほど、その出口、すなわち具体的な改善と対外的な説明の設計が重要になる。世界はいつも入口ばかりを増やし、出口の設計を忘れる傾向にあるが、AIと法の世界もその例外ではないようである。

（マガジン）「AIと法-雑感」

　※目次は以下を参照

note総則規約3条2項前段
3.2 クリエイターが制作したデジタルコンテンツの著作権は、クリエイターに帰属します。