生成AIへの指示と回答の危険や脱獄を一度に見分ける小型モデル「GLiGuard」とは

「社内向けのチャットAIに、変な指示や危ない回答を見張る仕組みを入れたい」「見張り役にも大きなAIを使うと、費用も待ち時間も倍になるのでは」——生成AIを業務に組み込み始めた企業の情報システム部門から、よく聞かれる声です。見張り役のAI、いわゆるガードレール（生成AIの入出力を検査して危険なものを止める仕組み）は、これまで数十億の部品（パラメータ）を持つ大きな判定用モデルが中心でした。そこに、米国の Fastino が2026年5月に公開した小型の判定用モデル GLiGuard が加わり、海外の開発者の間で注目を集めています。ただし、問われているのはモデルの賢さではありません。本当は、判定結果を誰がどう扱うかという運用の設計です。この記事では、GLiGuard が何を見分けるモデルなのか、公表された性能をどう読むか、安全性の精査結果と、企業が導入を考えるときに確かめる点を、防御の立場から整理します。

GLiGuardとは何か。2026年10月時点で確かめられる事実

GLiGuard は、米国のAI企業 Fastino が Hugging Face（AIモデルの公開・共有サイト）で公開している、生成AI向けのガードレール用モデルです。モデルカード（モデルの説明書きにあたるページ）によると、公開名の末尾には規模を示す「300M」が付いており、約3億（0.3B）パラメータの小型モデルとされています。文章を生成するモデルではなく、入力された文章がどの種類に当てはまるかを判定する分類用のモデルです。

当ラインの精査で確認した Hugging Face 上の記録では、作成日は2026年5月9日、最終更新は2026年9月28日です。ライセンスは Apache-2.0（商用利用も認める代表的なオープンソースのライセンス）で、利用の前に申請や同意を求める制限（ゲート）は付いていません。確認時点で「いいね」は92、直近1か月のダウンロード数は6,963でした。土台となったのは、同じ Fastino が公開している情報抽出用の基盤モデル GLiNER2 で、GLiGuard はそれを安全性の判定向けに追加学習したものと記録されています。

あわせて、GitHub に同名の公開場所があり、2026年5月8日には論文が arXiv（研究論文の公開サイト）に投稿されています。論文の著者は Fastino の4人です。なお、確認時点の GitHub の公開場所には、ライセンスと説明書き（README）と図版だけが置かれており、学習用や評価用のプログラムは見当たりませんでした。日本語での紹介記事は、調べた範囲ではほとんど見つかっていません。

なぜ今、小型のガードレール用モデルが注目されるのか

企業が生成AIを社内チャットや問い合わせ対応、AIエージェント（AIが自分で手順を考えて道具を使う仕組み）に組み込むほど、二つの心配が大きくなります。一つは、利用者の入力に紛れ込んだ悪意のある指示で、AIの決まりごとを破らせようとする「脱獄」や「プロンプトインジェクション（AIへの指示を外から書き換える攻撃）」です。もう一つは、AIの回答に差別的な表現や個人情報、危険な助言が含まれてしまうことです。

これを防ぐ見張り役として、入力と回答を別のAIで検査する方法が広がってきました。ところが、従来の判定用モデルの多くは数十億パラメータ規模の文章生成型で、判定の結果も文章として一語ずつ生成します。1回の会話ごとに大きなモデルをもう一つ動かすため、費用と応答の遅れが増えることが導入の壁になってきました。

GLiGuard の提供元は、この壁に対して「小さく、速く、まとめて判定する」という方向で答えようとしています。モデルカードでは CPU（一般的なパソコンやサーバーの演算装置）での利用を前提にした設計で、手元の環境で速く判定できることを特徴に挙げています。外部のサービスに会話を送らず、自社の環境の中で検査できる選択肢が増えることは、機密情報を扱う企業にとって意味があります。

一度の処理で複数の判定を返す「スキーマ条件付き」の考え方

論文の題名にある「スキーマ条件付き分類」は、GLiGuard の中心となる考え方です。スキーマとは、ここでは「どの項目を、どの選択肢の中から判定してほしいか」という問いの一覧を指します。使う側が判定してほしい項目と候補の分類名を渡すと、モデルはそれらを一度の読み込みでまとめて採点します。

文章生成型の判定用モデルは、答えを一語ずつ順番に書き出すため、確かめたい項目が増えるほど時間がかかります。これに対して GLiGuard は、文章を前後両方向から一度に読む「エンコーダー」と呼ばれる型のモデルで、答えを生成せずに各分類の当てはまり具合を点数で返します。論文の要旨では、これを一回の処理（非自己回帰的な処理）で行うと説明しています。

この仕組みには、運用面の利点と注意点の両方があります。利点は、判定項目を組み合わせても処理の回数が増えにくいことです。注意点は、結果が点数で返り、どこから先を「該当」とみなすかの境目（しきい値）を使う側が決めることです。モデルカードも、複数の分類を同時に返す判定ではしきい値の調整が必要になりうると明記しています。

入力側で見分けるもの：安全性・有害の種類・脱獄の手口

モデルカードによると、GLiGuard の判定は「入力側」と「出力側」に分かれています。入力側、つまり利用者が生成AIに送る指示に対しては、三つの判定を用意しています。一つ目は、指示全体が安全か危険かの二択の判定です。二つ目は、有害な内容の種類の判定で、複数の種類に同時に当てはまることもあります。三つ目が、脱獄やプロンプトへの攻撃の手口の判定です。

有害の種類は、論文の要旨では14分類とされています。モデルカードに並ぶ分類名を日本語にすると、暴力と武器、暴力を伴わない犯罪、性的な内容、憎悪と差別、自傷と自殺、個人を特定できる情報の露出、誤情報、著作権の侵害、子どもの安全、政治的な操作、倫理に反する行為、専門家の判断が必要な助言、プライバシーの侵害、その他です（これに「無害」を加えた候補が用意されています）。

脱獄の手口は11分類で、プロンプトインジェクション、脱獄の試み、決まりごとの回避、指示の上書き、システムへの指示文の持ち出し、データの持ち出し、役を演じさせる回避、仮定の話を装う回避、文字を崩して隠す攻撃、複数の段階に分けた攻撃、人の心理を突く働きかけ、が挙げられています。単に「危ない」と知らせるだけでなく、どの手口に近いかを名前付きで返すため、記録を後から分析するときの手がかりになります。

出力側で見分けるもの：回答の安全性と、断ったかどうか

出力側、つまり生成AIが返した回答に対しても、三つの判定があります。回答が安全か危険かの二択、回答に含まれる有害な内容の種類（入力側と同じ分類）、そして回答が依頼を「断った」のか「応じた」のかの判定です。モデルカードでは、回答だけを渡す方法と、元の指示と回答を組にして渡す方法の両方が説明されています。

「断ったかどうか」の判定は、見落とされがちですが実務では役に立ちます。たとえば、危険な指示が来たときに生成AIが正しく断っていれば、それは守りが働いた記録です。逆に、危険な指示に対して回答が「応じた」と判定された組み合わせは、最優先で人が確認すべき事例になります。入力の判定と出力の判定を突き合わせることで、どこで守りが破られたかを切り分けやすくなります。

一方でモデルカードは、評価の決まり方によっては「断った」という判定が「危険」という判定より優先される扱いになると注記しています。つまり、評価の数字は集計の約束ごとに左右されます。自社で使う場合は、断った回答の中に危険な一部が混ざっていないかを、集計の約束とは別に見る必要があります。

公表されている性能と、その読み方

モデルカードと論文では、九つの安全性ベンチマーク（性能を比べるための共通の試験問題）で評価した結果を示しています。成績は F1値（見逃しの少なさと誤検知の少なさを合わせた指標で、100に近いほど良い）で表されています。主な数字は次のとおりです。

評価の対象	公表されたF1値	ベンチマーク
入力の有害性	87.7	複数の平均
入力の有害性	85.2	Aegis 2.0
入力の有害性	99.0	HarmBench
入力の有害性	87.5	WildGuardTest
回答の有害性	82.7	複数の平均
回答の有害性	91.0	HarmBench
回答の有害性	84.5	SafeRLHF

比べる相手として、LlamaGuard、WildGuard、ShieldGemma、NemoGuard、PolyGuard、Qwen3Guard といった、ほかの組織が公開している判定用モデルが挙げられています。論文の要旨は、70億から270億パラメータ規模の文章生成型の判定用モデルと同程度のF1値を、23分の1から90分の1の大きさで出したとしています。速さについては、処理量が最大で約16倍、応答の遅れが最大で約17分の1になったと報告しています。

ただし、これらはすべて提供元と論文著者による自己申告で、第三者による検証は確認できていません。また評価に使われたのは英語のベンチマークです。数字は「英語の試験問題での成績」であり、自社の日本語の業務文章での成績ではないと読むのが妥当です。速さの倍率も、比べた機材や条件によって変わるため、そのまま自社の見積もりには使えません。

大きな判定用モデルや他の手段との違い

ガードレールの作り方は一つではありません。GLiGuard の位置づけを、ほかの代表的な手段と並べると次のようになります。表の内容は一般的な傾向で、個々の製品によって異なります。

観点	小型の分類型（GLiGuard）	大型の文章生成型の判定用モデル	単語やルールによる検査
判定の速さ・費用	軽い。CPUでの利用を想定	重い。専用の演算装置が必要になりやすい	非常に軽い
判定の細かさ	有害の種類と手口を分類名で返す	理由を文章で説明できるものもある	決めた語句に当たったかどうかだけ
新しい手口への対応	学習した範囲に依存	比較的広く対応できるとされる	ルールを足さない限り対応できない
日本語	公表されていない	製品による	自社で語句を用意すれば可能
社外への送信	自社環境で動かせる	提供形態による	不要

この比較から分かるのは、GLiGuard が「何でも一台で済む道具」ではなく、軽さと分類の細かさに強みを持つ部品だということです。単語やルールによる検査のように確実に止めたいものは止め、大型モデルのように理由の説明が欲しい場面では別の手段を使う、という組み合わせが現実的です。

また、提供元のモデルカードの冒頭には、自社の有料サービスで GLiGuard を追加学習したり配備したりする案内が載っています。モデル本体は Apache-2.0 で公開されていますが、提供元のサービスを使う場合は、会話のデータがどこへ送られるかをモデル本体とは別に契約と規約で確かめる必要があります。

想定される使い方・使う場面

モデルカードの説明から考えると、GLiGuard の使いどころは大きく三つです。一つ目は、社内チャットAIや問い合わせ対応AIの「入口の見張り」です。利用者の指示を生成AIに渡す前に判定し、危険度の高いものは止めたり、担当者の確認に回したりします。

二つ目は「出口の見張り」です。生成AIの回答を利用者に返す前に判定し、個人情報の露出や差別的な表現などの分類が付いたものを差し止めます。三つ目は、AIエージェントが外部の文書やウェブページを読み込む場面での検査です。読み込んだ文章に、AIへの指示の上書きを狙った文が紛れていないかを点検する用途が考えられます。ただし、この三つ目は提供元が性能を示している範囲ではないため、効果は自社での検証が前提の推測にとどまります。

どの場面でも、判定結果は記録として残しておく価値があります。脱獄の手口が分類名で返るため、どの手口が多く試されているか、どの部署の利用で危険な判定が増えているかを集計できます。これは、社内の利用ルールの見直しや、利用者への注意喚起の材料になります。

安全性の評価：紹介可とした根拠

当ラインでは、記事で取り上げる前に公開情報だけで安全性を精査しています。モデルを取得したり動かしたりはしていません。GLiGuard は次の事実から「紹介可」と判定しました。

• ライセンスは Apache-2.0 で、商用を含む利用条件が明確
• 公開されている重み（学習済みの数値）のファイルは safetensors 形式のみで、読み込むだけでプログラムが動くおそれのある Python の Pickle 形式のファイルは無い
• モデルと一緒に動かす独自のプログラムのファイルは置かれていない
• 利用に申請を求める制限（ゲート）は無い
• 確認した範囲で、このモデルに対するセキュリティ上の勧告や問題の報告は見当たらない

重みのファイル形式は、モデルの安全性を見るうえで基本的な確認点です。Pickle 形式は、ファイルを読み込んだ時点で中に仕込まれたプログラムが動く可能性があり、過去にも悪用の手口として知られてきました。safetensors 形式はこの心配が小さい形式です。

ただし、問題が見つからなかったことは、安全の保証ではありません。精査は公開情報を読んだ範囲のもので、モデルが学習した内容の偏りや、判定のすり抜けやすさまでは確かめていません。導入する場合は、配布元が提供元の正式な公開場所であることを確かめ、業務の機密情報に触れない環境で試すことをおすすめします。

ライセンス・学習データ・公開範囲で確かめておきたい点

ライセンスの面では、Apache-2.0 は商用利用・改変・再配布を認めるため、企業が使ううえでの制約は比較的少ないといえます。ただし、改変して配布する場合の表示義務などは残るため、法務部門と条文を確認しておくと安心です。

学習データについて、モデルカードは、安全性と「断ったかどうか」の判定の中心に WildGuardTrain という公開データを使い、有害の種類と脱獄の手口の分類は危険な例に自動で付けた分類名で補ったと説明しています。さらに、提供元の Pioneer という仕組みで合成し分類名を付けたデータも加えたとしています。自動で付けた分類名には誤りが混ざる可能性があり、細かな分類の精度は大まかな安全か危険かの判定より揺れやすいと考えておくのが無難です（これは当ラインの推測です）。

公開範囲にも注意が要ります。先に触れたとおり、確認時点の GitHub の公開場所には学習や評価のプログラムが置かれていませんでした。そのため、公表された数字を第三者が同じ条件で再現することは、現時点では難しい状況です。また Hugging Face のページでは、説明文の「0.3B」とは別に、ファイルの情報欄に「0.2B」という表示も見られました。どちらが正しいかの説明は確認できておらず、細かな数字は変わりうるものとして扱うのが適切です。

悪用されうるリスクと、判定をすり抜けられる可能性

GLiGuard は守るための道具で、それ自体が攻撃に直接使われる性質のものではありません。ただし、公開された判定用モデルには一般的な注意点があります。誰でも手元で動かせるということは、攻撃者も同じモデルで判定結果を確かめながら、判定をすり抜ける言い回しを探せる可能性があるということです。これは GLiGuard に限らず、公開されたガードレール全般に言える構造上の弱点です。

モデルカード自身も、文脈に依存する微妙な攻撃、多言語の攻撃、まったく新しい手口は見逃す可能性があると認めています。とくに日本企業にとって重いのは多言語の点です。モデルの言語の表示は英語だけで、日本語や、日本語と英語が混ざった文章での精度は公表されていません。日本語で書かれた脱獄の試みに対して、英語と同じ精度が出る根拠は現時点ではありません。

もう一つのリスクは、守る側の過信です。見張り役を置いたことで安心し、生成AIに渡す権限や情報の範囲を広げすぎると、すり抜けた一件の被害が大きくなります。ガードレールは何重にも重ねる守りの一枚であり、生成AIに与える権限を最小限にする、重要な操作には人の承認を挟む、といった基本の対策の代わりにはなりません。

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

GLiGuard のような判定用モデルを試すときは、いきなり本番の会話に組み込まず、段階を踏んで確かめます。次の5段階が一つの目安です。

この順番で進めると、モデルの成績ではなく自社の業務での成績をもとに判断できます。どの段階で導入をやめるかの基準も、最初に決めておくと議論が長引きません。

企業が取るべき対策

GLiGuard を使うかどうかにかかわらず、生成AIのガードレールについて企業が整えておきたい対策は次の四つです。

一つ目は、見張りを一枚にしないことです。判定用モデル、単語やルールによる検査、生成AIに与える権限の制限、重要な操作への人の承認を重ねて、どれか一枚がすり抜けられても被害が広がらないようにします。二つ目は、判定の記録を残し、定期的に人が見直すことです。どの分類で何件止めたか、誤検知の苦情が何件あったかを月ごとに確かめ、しきい値や運用を調整します。

三つ目は、調達時の確認項目に判定用モデルの事情を加えることです。学習データの言語、評価が自己申告か第三者によるものか、重みのファイル形式、ライセンス、提供元のサービスに会話を送るかどうかを、社内の調達の確認表に固定の項目として入れると、担当者が替わっても判断がぶれません。四つ目は、利用者への周知です。社内の生成AIに見張り役があること、記録が残ることを利用規程に明記すると、不正な使い方の抑止にもなります。

これらの対策は、MITRE ATLAS（AIへの攻撃手口を整理した知識体系）や OWASP（ウェブの安全性に取り組む国際的なコミュニティ）が示す生成AIの主なリスクとも重なります。ガードレールは、そうした枠組みのうち入力と出力の検査を担う一部分だと位置づけると、他の対策との抜け漏れを点検しやすくなります。

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

判定用モデルを入れると、判定結果をそのまま「正解」として扱いたくなります。しかし GLiGuard が返すのは、各分類への当てはまり具合の点数です。AIに判断させず、点数を材料に人が決めた基準で動かすという線引きを、導入の前に文書にしておくことが大切です。次のような運用は避けます。

• 英語のベンチマークの成績を根拠に、日本語の業務で検証せずに本番の会話を自動で止める
• モデルが「安全」と判定した回答は、人が一度も見ないまま外部の顧客に送る
• 止めた理由を記録せず、利用者からの問い合わせに説明できない
• しきい値を担当者の感覚で変え、変更した日と理由を残さない
• 見張り役を入れたことを理由に、生成AIに渡す社内情報や操作権限を広げる

人が決めるべきなのは、何を止めるかの基準、どの分類を人の確認に回すか、誤検知で止まった利用者への対応、そして基準を見直す時期です。AIに任せてよいのは、決めた基準に沿った一次的な仕分けまでです。判定のたびに、どの分類にどの点数が付いたかという根拠を記録に書き残させるようにすると、人が後から確かめられます。また、人が必ず確認する範囲を先に決めておくと、判定の件数が増えても確認が追いつかなくなる事態を防げます。

よくある質問

日本語の社内チャットにそのまま使えますか

モデルカードの言語の表示は英語だけで、日本語での精度は公表されていません。使えるかどうかは、自社の日本語の例文で精度を測ってから判断する必要があります。日本語の判定が不十分だった場合は、単語やルールによる検査と組み合わせるなどの補い方を考えます。

無料で使えるなら、すぐに入れたほうがよいですか

ライセンス上は商用でも無償で使えますが、検証と運用には人手がかかります。誤検知への対応や記録の見直しを担う担当者を決められない段階では、まず記録だけの運用で様子を見るほうが安全です。

大きな判定用モデルより優れているのですか

論文では、英語のベンチマークで同程度のF1値をより小さなモデルで出したと報告しています。ただし自己申告で、得意不得意は分類や言語によって異なりえます。「優れている」というより「軽さに強みがある別の選択肢」と捉えるのが妥当です。

• 本記事の内容は、2026年10月28日に確認した Hugging Face のモデルカード、GitHub の公開場所、arXiv の論文要旨に基づきます。数値やファイル構成、ライセンスは今後の更新で変わる可能性があります
• 性能の数字はすべて提供元と論文著者による公表値で、当ラインでは検証していません

まとめ

GLiGuard は、生成AIへの指示と回答を、安全か危険か、有害の種類、脱獄の手口、断ったかどうかまで一度に分類する約3億パラメータの小型の判定用モデルです。Apache-2.0 で公開され、重みは safetensors 形式のみと、公開情報から見た安全面の懸念は見当たらず、当ラインでは「紹介可」と判定しました。ただし、問題が見つからなかったことは安全の保証ではありません。

一方で、公表された性能は英語のベンチマークでの自己申告で、日本語での精度は分かっていません。導入を考える企業は、自社の日本語の例文で精度を測り、記録だけの運用から始め、止める基準と人が確認する範囲を先に決めておくことが大切です。判定用モデルは見張りの一枚であり、生成AIに与える権限を絞る、重要な操作に人の承認を挟むといった基本の守りと重ねて使うことで、初めて効果を発揮します。

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