公開前のAIモデルの弱点をOSS「0DIN AI Scanner」はどう洗い出すのか

「社内で作ったAIの窓口を来月公開する。危ない受け答えをしないか、公開前に一度まとめて確かめておきたい」「外部の検査会社に頼むほどの予算はないが、手元で繰り返し測れる仕組みがほしい」——生成AIを自社の製品や業務に組み込み始めた企業の、セキュリティ担当者から出てくる声です。検査の道具を入れれば安心だ、と考えたくなりますが、要点はそこではありません。本当は、検査の道具そのものも守るべき仕組みであり、結果は「試した範囲での手がかり」にとどまるという前提で使うことです。この記事では、自社のAIモデルやAIの仕組みを公開前に攻める側の目線で検査するOSS「0DIN AI Scanner」について、一次情報で確かめられる仕組み・結果の読み方・重大度「重大」と評価された勧告と修正版・同梱の検査項目の扱い・使う前に決めることを整理します。導入や操作の手順は扱いません。

0DIN AI Scannerとは何か。2026年10月時点で確かめられる事実

0DIN AI Scanner は、GitHub上で公開されているAIの検査用のウェブの仕組みです。READMEによると、組織が自社のAIの仕組みを公開前に検査し、弱いところを見つけるためのもので、従来のソフトウェアに対する侵入テスト（攻め手の目線で弱点を確かめる検査）のAI版にあたると説明されています。画面からの操作を前提にしたウェブの仕組みとして、Ruby on Rails で作られています。

公開の時期と規模も確かめておきます。リポジトリは2026年3月19日に作られ、同じ日に最初の版1.0.0が公開されました。その後も更新が続き、2026年10月2日に公開された1.19.0まで、リリースの一覧には53の版が並んでいます。2026年10月21日時点で、スターはおよそ680、複製（フォーク）は113です。持ち主の組織のアカウントは2024年7月に作られ、公開リポジトリは91あります。

名前にある「0DIN」は、2024年8月に Mozilla が、言語モデルなどの生成AIを対象にした脆弱性報奨金制度（弱点を見つけて報告した研究者に報奨金を払う制度）として発表したものの名前です。READMEに載っている脅威の報告への案内も、この制度のサイトにつながっています。ただし、2026年10月時点の運営体制や、この OSS と Mozilla との関係は、確認した一次情報の範囲では確かめられませんでした。ライセンスは Apache-2.0 で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。

どんな問題に応えるのか：公開前のAIを攻める側の目線で確かめる

生成AIを使った窓口や業務の仕組みは、通常のソフトウェアと違い、同じ入力でも答えが揺れ、言い回しを工夫されると想定外の振る舞いをすることがあります。隠された命令に従ってしまう、答えてはいけない内容を答えてしまう、社内の情報を漏らしてしまう、といった弱さは、作り手が思いつく範囲の確認だけでは見落としやすいものです。

こうした弱さを整理した代表的な一覧が、OWASP（ウェブの安全性に関する国際的な非営利の団体）の、言語モデルを使う仕組みの主要な危険の一覧です。READMEによると、0DIN AI Scanner の検査項目はこの一覧の分類に沿って整理されています。検査の結果を、社内で共有しやすい共通の言葉で語れる点は、報告や改善の優先順位づけで役に立ちます。

もう一つの狙いは、一度きりではなく繰り返し測ることです。AIの仕組みは、モデルの入れ替えや指示文の改訂で振る舞いが変わります。READMEは、予定を組んだ定期の検査と、必要なときの随時の検査の両方に対応し、検査のたびの結果の推移を追えると説明しています。公開前の一回だけでなく、変更のたびに同じ物差しで測り直す使い方が想定されていると読み取れます。

土台はNVIDIAの検査用OSS「garak」。検査項目の出どころ

0DIN AI Scanner の検査の中心には、NVIDIA が公開している言語モデルの検査用OSS「garak」があります。garak は、モデルに多数の働きかけを送り、返ってきた答えに弱さの兆候がないかを調べる道具で、Apache-2.0で公開されています。0DIN AI Scanner は、この garak を画面から扱えるようにし、検査の予定・結果の保存・報告書の出力などを加えたものだと言えます。

公式の説明では、検査の一つひとつの項目を「プローブ」と呼びます。一つのプローブは、特定の弱さを確かめるための働きかけをモデルに送り、答えを判定役の仕組みで評価します。READMEによると、garak 由来の共同体の検査項目が35の系統にわたって179収められています。系統には、紛れ込んだ命令への耐性、出力の扱いの危うさ、過大な権限、機微な情報の開示などが含まれると説明されています。

土台が広く使われている OSS であることは、検査の中身を外から確かめやすいという利点になります。一方で、土台の道具の更新や弱点が、そのまま上に載る仕組みにも影響することも意味します。導入を考える場合は、0DIN AI Scanner 自体の版だけでなく、取り込んでいる garak の版や更新の追い方も確かめる対象に入ります。

二つの検査対象：APIでつなぐモデルと、ブラウザで使うチャット画面

公式の説明では、検査の相手を「ターゲット」と呼び、二つの種類があります。一つ目は、API（外部の仕組みから呼び出すための窓口）で直接つなぐモデルです。OpenAI、Anthropic、Azure の OpenAI のサービス、手元でモデルを動かす Ollama、Hugging Face、一般的な REST の窓口などに、garak の接続の部品を通してつなげるとされています。

二つ目は、ブラウザで使うチャット画面です。API を持たないチャットの画面に対しては、ブラウザを自動で操作する Playwright という部品を使い、人が画面に入力するのと同じ形で検査します。社内向けに作ったチャット画面や、外部のサービスに組み込まれた問い合わせ窓口など、API が公開されていない仕組みも検査の対象にできる点が特徴です。

ただし、この二つ目の仕組みは、後で触れる勧告とも関わる部分です。ブラウザを自動で操作する機能は、検査の相手の範囲を広げる代わりに、道具そのものが外の世界とやり取りする面も広げることになります。どのチャット画面を検査してよいか、検査の相手をどう登録するかを、道具を使う前に社内で決めておく理由の一つです。

結果は「攻撃成功率」で示す。数字の読み方

検査の結果は、攻撃成功率（ASR）という割合で示されます。公式の説明によると、これは検査の働きかけのうち、問題のある答えを引き出せた割合のことです。報告書には、全体の攻撃成功率、使った検査項目の数、かかった時間の要約と、系統ごと・項目ごとの成功率、そして一つひとつの働きかけと答えのやり取りが記録されます。

成功率は、0から20%の「低」から、80から100%の「深刻」まで、五つの段階に分けて表示されると説明されています。モデルや指示文を変えたあとに成功率がどう動いたかを追えば、変更の効果を測る手がかりになります。公式の説明自身も、成功率は同梱の検査項目に対する相対的な値であり、低いからといって、あらゆる攻撃に対して安全だと証明するものではないと明記しています。

ここで押さえたいのは、問題があったかどうかを決めるのも仕組みの側だという点です。リリースノートによると、2026年10月の1.19.0では、判定の得点が境目に近いものを言語モデルに判定させる機能が加わりました。判定を助ける仕組みとしては合理的ですが、判定役のAIも間違えうるため、成功率は事実そのものではなく、人が記録を読んで確かめるための入口として扱う必要があります。

定期検査と記録の残し方：報告書・ログ監視との連携・複数の組織

READMEには、検査を運用に組み込むための機能も並んでいます。検査の予定を組んで繰り返し動かす機能、検査の進み具合や実行の記録を画面で追える機能、そして項目ごと・働きかけごとに掘り下げられる報告書をPDFで出力する機能です。2026年8月の1.18.0では、報告書を機械で読みやすい形式で書き出す機能や、検査のすべての働きかけを一覧にする欄も加わっています。

検査の結果は、組織のログを集めて監視する仕組み（SIEM）に送ることもできます。READMEでは Splunk と Rsyslog への転送が挙げられています。AIの検査結果を、ほかの機器や仕組みの警告と同じ場所で見られるようにすれば、検査で弱さが見つかったときに担当者が気づきやすくなります。

さらに、一つの設置で複数の組織を分けて扱える作りで、保存するデータは暗号化されるとされています。公式の説明では、検査の相手ごとに登録する接続用の鍵や設定も暗号化して保存され、報告書の保存期間は既定で90日です。複数の組織を一つの設置に同居させる作りは、組織どうしの分離が崩れたときの影響も大きくなる点は覚えておく必要があります。これは次の勧告の内容とも関わります。

ほかの手段との違い：手作業の確認・外部の診断・この OSS

AIの弱さを確かめる手段は、この OSS のほかにもあります。作り手が自分で働きかけて確かめる手作業の確認、専門の会社に依頼する外部の診断、そして運営元が提供する有料のサービスです。READMEは、運営元に問い合わせれば、手間をかけずに使えるサービスの形でも提供できると案内しています。主な違いを、防御側に関係する観点に絞って並べます。

観点	手作業の確認	外部の専門会社の診断	0DIN AI Scanner（自社で設置）
検査の量	作り手が思いつく範囲	契約の範囲で深く	35の系統・179の項目を繰り返し
繰り返しやすさ	人手がかかり続かない	依頼のたびに費用がかかる	予定を組んで定期に動かせる
結果の解釈	作り手の判断	専門家の所見が付く	成功率と記録。解釈は自社で行う
自社で負う手間	少ない	契約と日程の調整	設置・更新・利用者の管理・鍵の保護
新しい手口への追随	担当者の知識しだい	診断する会社しだい	版の更新しだい。更新を追う体制が要る

表から分かるとおり、この OSS は「量と繰り返し」に強い一方で、結果の解釈と、道具そのものの運用を自社で引き受けることが前提になります。外部の診断を置き換えるものというより、診断と診断の間を埋める日常の物差しとして位置づけるのが現実的です。

安全性の評価：注意付きとした根拠

このラインでは、OSS を取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。0DIN AI Scanner の判定は「注意付き」です。ライセンスは OSI 承認の Apache-2.0 で、持ち主の組織のアカウントにも2024年からの活動の記録があり、スターの伸びも1日あたり3前後と不自然な急増は見られません。

それでも注意付きとした根拠は二つです。一つ目は、重大度「重大」と評価されたセキュリティ勧告（CVE-2026-41512）が公開されていることです。中身は次の見出しで扱います。勧告には修正版が示されていますが、古い版を使い続けている設置がある可能性は残ります。

二つ目は、既知の脱獄の働きかけ（AIの安全のための制限を外させる働きかけ）を、検査用にそのまま実行できる形で同梱していることです。検査には必要なものですが、扱いを誤れば攻撃の材料にもなります。なお、精査の範囲では、導入の際に自動で動く処理は見つかりませんでした。ただし、問題が見つからなかったことは安全の保証ではありません。検査の道具であっても、ほかのソフトウェアと同じ確認を行うべきです。

重大度「重大」の勧告CVE-2026-41512と、修正版の有無

GitHub上のセキュリティ勧告によると、この弱点はブラウザを自動で操作する部品にありました。利用者が入力した値が適切に処理されないまま、内部で実行される処理に組み込まれていたため、ログインできる利用者であれば、道具が動いている環境の中で任意の処理を実行できるおそれがあったとされています。重大度は「重大」、CVSS（脆弱性の深刻さを示す共通の尺度）の基本値は10点満点中9.9です。

勧告は、影響として、仕組みの秘密の鍵やデータベースへの接続情報が漏れうること、それによって保存された各組織のデータが読み解かれうること、同じ設置の中の組織どうしの分離が崩れうることを挙げています。また、問題の機能は管理者に限らずどの組織の利用者からも使える状態だったこと、そして既定の設置で作られる管理者のアカウントの初期の合言葉が広く知られたものだったことも指摘されています。

修正版の有無は、一次情報で確かめられました。勧告は影響を受ける版を1.0.0から1.4.0まで、修正された版を1.4.1としており、リリースの一覧でも1.4.1が2026年4月13日に公開されています。勧告の公開は4月16日です。確認時点の最新版は1.19.0です。ただし、この記事は修正の中身をコードで確かめたものではありません。古い版を使っている場合の扱いは、後の見出しで整理します。

勧告のあとのリリースノートを見ると、運営元が守りの面に手を入れ続けていることが読み取れます。2026年8月の1.15.2では、土台にしている Rails のファイル保存の機能で見つかった遠隔コード実行の脆弱性に対応したと記されています。道具そのものだけでなく、取り込んでいる部品の弱点も更新で塞がれるという当たり前のことを、改めて示す記録です。

同じ8月の1.17.0では、ブラウザの接続を確認用の中継を通して振り分ける、すべての接続を禁止先の一覧と照らし直す、といった変更が「セキュリティ」の項目として並んでいます。あわせて、リポジトリに同梱された仮の秘密の値のままでは起動しないようにする修正も入りました。初期設定のまま使われることへの備えだと読めます。

こうした記録からは、運営元が問題に向き合っている姿勢がうかがえます。一方で、更新が頻繁であるほど、使う側が版を追い続ける手間も大きくなることも事実です。半年余りで53の版が出ている点を踏まえ、誰がいつ版を確かめて上げるのかを決めておかないと、修正が出ていても自社の設置には届かない、という事態になりかねません。

同梱された脱獄の検査項目をどう扱うか

READMEによると、0DIN AI Scanner には、0DIN が公表した実在の脱獄の手口が、模擬ではなく実際に動く検査項目として同梱されています。そのうちいくつかは、元の働きかけに加え、相手に合わせて組み替えた多数の変形とともに収められ、公開の脅威の報告への案内が付いています。この記事では、個々の手口の名前・中身・言い回しは扱いません。防御側に必要なのは、それをどう管理するかのほうだからです。

こうした検査項目は、自社のAIが既知の手口にどれだけ耐えるかを測るうえでは価値があります。しかし同時に、社内に攻撃の材料がまとまった形で置かれることでもあります。検査の報告書にも、働きかけと答えのやり取りがそのまま残ります。報告書や記録を誰が見られるかを、通常の業務文書より厳しく絞る必要があります。

また、検査で引き出された答えの中に、本来出てはいけない有害な内容が含まれる可能性もあります。報告書を社内で共有するときは、要約と判断だけを広く伝え、やり取りの全文は担当者に限って保管するといった扱いを決めておくと安全です。報告書の保存期間の設定も、社内の文書の保存の決まりと合わせておきます。

悪用されうるリスク

検査の道具は、立場を変えれば攻撃の道具にもなりうるという二面性を持ちます。0DIN AI Scanner は自社のAIを検査する前提で作られていますが、検査の相手には外部のチャット画面も登録できるため、許可のない他者のAIの窓口に向けて使われる可能性は否定できません。これは推測であり、そうした使われ方の報告を確認したわけではありません。

もう一つのリスクは、道具そのものが狙われることです。今回の勧告が示したように、検査の道具は接続用の鍵、検査の記録、各組織のデータを一か所に抱えています。外から触れられる場所に古い版のまま置かれていれば、守るための道具が、社内のAIの接続用の鍵を抱えた入口になるおそれがあります。検査の相手ごとに登録した鍵が漏れれば、その鍵で使える外部のAIの利用料や権限にも影響が及びえます。

守る側が受け取るべき示唆は、自社のAIの窓口も、同じ種類の手口で外から試されうる前提に立つことです。既知の脱獄の手口は公開の報告として出回っており、この道具に固有の危険というより、すでにある現実の表れと見るのが妥当でしょう。なお、許可のない他者の仕組みを試す行為は法律上の問題になりうることを、社内でも共有しておくべきです。

検査の通信と保存データ：どこへ何が流れるのか

検査では、働きかけが検査の相手、つまり登録したモデルやチャット画面に送られます。相手が外部の事業者のモデルであれば、検査の働きかけと答えが、その事業者のもとを通ることになります。既知の脱獄の働きかけを大量に送ることが、事業者の利用規約に照らして問題にならないかも、事前に確かめておくべき点です。

保存されるデータについては、公式の説明で、検査の相手ごとの接続用の鍵と設定が暗号化して保存されること、報告書の保存期間が既定で90日であることが確かめられます。一方で、自社で設置した仕組みから運営元へ何かが送られるかどうかについては、確認した一次情報には記載が見当たりませんでした。送られないと確かめられたわけではなく、確認できる情報がないという状態です。

検査の相手として登録する鍵は、可能であれば検査専用のものを用意し、使える範囲と利用額の上限を絞っておくと、万一の漏えいの影響を小さくできます。機密を含む指示文や社内の情報をつないだ仕組みを検査する場合は、検査用の写しの環境を用意するかどうかも含めて決めておくと、手戻りを防げます。

導入を検討するときに確かめること

0DIN AI Scanner を社内の検査に使うかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

0DIN AI Scanner を使うかどうかにかかわらず、AIの検査の道具を社内に置く企業が取るべき対策は共通しています。第一に、検査の道具を、守るべき重要な仕組みとして台帳に載せることです。版・置き場所・利用者・登録した鍵を記録し、ほかの業務の仕組みと同じように勧告の情報を追います。

第二に、古い版を使っていた場合の後始末を決めておくことです。勧告の影響を受ける版を使っていたことが分かった場合は、修正版への更新に加え、初期の管理者の合言葉の変更、不要な利用者の削除、仕組みの秘密の鍵や接続用の鍵の取り替え、設置の環境に見覚えのないファイルや処理がないかの確認を検討します。勧告の説明にもとづく影響の範囲を考えると、更新だけで終わらせないことが大切です。

第三に、検査の道具を社外から触れられる場所に置かず、利用者を絞ることです。第四に、同梱の攻撃の材料と検査の記録の閲覧範囲を絞ることです。第五に、社内のAI利用の規程に、検査してよい相手、検査の頻度、結果を確かめる人、外部の事業者のモデルを検査するときの確認事項を書き込んでおきます。道具を入れることより、道具を回す決まりを先に作ることが、守りを続けるための要点です。

AIに任せる範囲と、人が決める範囲

0DIN AI Scanner は、多数の働きかけを自動で送り、答えを仕組みが判定し、境目の判定には言語モデルも使う道具です。効率のよい設計ですが、検査の結果を最終的な判断としてAIに委ねてはいけません。AIに任せてよいのは、大量の働きかけを試し、怪しい答えを拾い上げるところまでです。

人が決めるのは、何を検査の相手にするか、どの成功率を問題とみなすか、何を直すか、どこまで試したら十分とするかです。報告書には働きかけと答えのやり取りが残るので、問題とされた答えの根拠となるやり取りを、人が実際に読んで確かめることを手順に入れます。判定役のAIを使う場合も、判定の理由を記録に残させ、人が後から追える形にしておきます。避けたい使い方を挙げます。

• 成功率が低かったことだけを理由に、AIの窓口を安全と判断して公開する
• 判定役のAIが問題なしとした答えを、誰も読まずに合格として扱う
• 検査の道具を初期の管理者の合言葉のまま、社内の誰もが触れる場所に置く
• 勧告の影響を受ける古い版を、更新の担当を決めないまま使い続ける
• 許可を得ていない他社のチャット画面を、検査の相手として登録する

どの例も、道具の能力ではなく運用の決まりで防げる失敗です。人が確認する範囲を先に決めておくことが、検査を意味のあるものにします。

よくある質問：攻撃成功率が低ければ、AIは安全と言えるのか

答えは「同梱の検査項目の範囲では持ちこたえた、という意味にとどまる」です。公式の説明自身が、成功率は検査項目に対する相対的な値だと明記しています。検査項目の外にある新しい手口は測れず、判定の仕組みが見落とす答えもありえます。また、モデルの提供元がモデルを更新すれば、同じ設定でも結果が変わる可能性があります。

では検査に意味がないのかというと、そうではありません。同じ物差しで繰り返し測り、変更の前後で成功率がどう動いたかを見ることは、指示文の改訂やモデルの入れ替えの判断材料になります。「安全の証明」ではなく「弱いところを見つけ、変化を追う道具」として位置づけるのが現実的です。

もう一つ、「検査の道具に重大な勧告が出たなら、使わないほうがよいのか」という問いもありそうです。勧告には修正版が示されており、版を追う体制と、置き場所・利用者の制限を整えられるなら、使う判断はありえます。逆に、その体制を作れないなら、外部の診断や運営元のサービスなど、運用を他者に任せる手段と比べて検討するほうが無難です。

• 0DIN AI Scanner の機能・検査の範囲・成功率の定義・データの扱いは、GitHubのリポジトリ（README・セキュリティ勧告・リリースの一覧）と公式の説明、garak のリポジトリ、Mozilla の発表、OWASP の一覧を2026年10月21日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 勧告の修正の中身はコードで確かめていません。自社で設置した仕組みから運営元へ送られる情報の有無、現在の運営体制と Mozilla との関係は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、同梱の脱獄の手口の具体は扱いません

まとめ

0DIN AI Scanner は、NVIDIA の検査用OSS「garak」を土台に、自社のAIモデルやAIの仕組みを公開前に攻める側の目線で検査するウェブの仕組みです。APIでつなぐモデルとブラウザで使うチャット画面の両方を相手にでき、結果を攻撃成功率で示し、定期の検査や報告書の出力、ログ監視の仕組みとの連携にも対応しています。

一方で、2026年4月には重大度「重大」の勧告CVE-2026-41512が公開され、1.0.0から1.4.0までの版が影響を受けました。修正版1.4.1が出ており、確認時点の最新版は1.19.0です。既知の脱獄の手口を同梱している点も含め、道具そのものを守る運用が欠かせません。最新の版を追う担当を決め、置き場所と利用者を絞り、結果は人が記録を読んで判断することが、0DIN AI Scanner との現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。