Shieldstral（シールドストラル）とは？Mistralの3B安全性分類モデル｜Apache 2.0・16GB GPUで動く・日本語対応・使い方と競合比較【2026年8月最新】

Shieldstral（シールドストラル）は、「このテキストや画像は自社のルールに違反しているか」を Yes/No で判定する、30億パラメータ（3B）の安全性分類モデルです。Mistral AI が2026年8月4日に公開し、Apache 2.0ライセンスのオープンウェイトとして Hugging Face から誰でもダウンロードできます。

最大の特徴は、判定ルール（ポリシー）を再学習なしで差し替えられる点です。Llama Guard などの従来型ガードモデルは学習時に固定されたカテゴリ体系でしか分類できませんでしたが、Shieldstral は「あなたのルールを平文で書いて、推論時に一緒に渡してください」という設計になっています。

対応言語12言語には日本語が含まれ、必要なGPUは16GBが1枚。一方で判定理由は返さず、扱えるのはテキストと画像のみです。自社サービスに入出力フィルタを組み込みたい開発者、コンテンツモデレーション基盤の刷新を検討している事業者、データを外部に出せない制約下でAIガードレールを構築したい情報システム・セキュリティ担当者にとっては、選択肢の前提が変わる発表といえます。

Shieldstralの基本スペック

出典: Mistral AI 公式ブログ「Introducing Shieldstral」

押さえるべき3点

1. これは「喋るAI」ではなく「門番」。Shieldstral 自体は文章を書いたり要約したりしません。他のAIの入力と出力に対して、赤／青の判定を付けるためだけのモデルです。
2. ポリシーがコードではなくプロンプト側にある。「暴力を助長していますか？」という質問文を書き換えるだけで判定基準が変わります。カテゴリを増やすたびに再学習していた従来の運用が不要になります。
3. 無料だが、タダではない。ウェイトはApache 2.0で無料ですが、GPUを自前で用意し、閾値を調整し、ポリシーを保守する責任は導入側に移ります。ここが OpenAI Moderation API との決定的な違いです。

Shieldstralとは — AIの入出力に判定を付ける「門番」モデル

出典: Mistral AI 公式ブログ「Introducing Shieldstral」

Shieldstral は、Mistral AI が開発した安全性分類（セーフティ分類）専用のマルチモーダルモデルです。公式モデルカードでは「policy-adaptive multimodal safety classifier（ポリシー適応型マルチモーダル安全性分類器）」と位置づけられています。

役割を具体的に言うと、生成AIサービスにおける次の3つの地点に置かれます。

• 入口：ユーザーが送ってきたプロンプトが有害／違反していないか
• 出口：AIが返した応答が有害／違反していないか
• 拒否の妥当性：AIが断るべきでない質問を過剰に断っていないか（拒否検出）

これは、AIエージェントのセキュリティ対策で語られる「入出力ガードレール」の実装そのものです。従来はここに Llama Guard や商用モデレーションAPIを置いていましたが、Shieldstral はその選択肢に「自己ホストできる小型・高精度・マルチモーダル」という新しい枠を持ち込みました。

開発元の Mistral AI は、Apache 2.0でのモデル公開とEU拠点のデータ主権を武器にしてきた企業です。同社の全体像は Mistral AIとは で、主力の言語モデルについては Mistral Medium 3.5とは で整理しています。

従来のガードモデルとの決定的な違い

ここが Shieldstral の本質です。

Mistral は、モデレーションを「Yes/Noの質問応答タスク」に再定義しました。「暴力を助長しているか？」「未成年に不適切か？」「自社の広告規約に違反しているか？」といった問いを、その場で日本語や英語の平文で渡せます。

この設計の直接的な恩恵は、サービスの利用規約を改定したときにモデルを触らなくてよいことです。規約文書を更新したら、対応する質問文を更新してデプロイするだけで済みます。

Shieldstralでできること

出典: Mistral AI 公式ブログ「Introducing Shieldstral」

Shieldstral が判定できる対象は、現時点で以下の5種類です。

このうち拒否検出は見落とされがちですが、実務価値が高い機能です。生成AIサービスの品質クレームの多くは「有害な出力をした」ではなく「無害な質問を断られた」に由来します。ガードレールを締めすぎた結果ユーザーが離れる問題は、Claude Fable 5 のガードレール謝罪事件のような形で表面化しました。Shieldstral は XSTest（過剰拒否の評価ベンチマーク）で94.6%のF1を出しており、「断りすぎていないか」を機械的に監視する用途にも使えます。

入力フォーマット：3つのブロック

Shieldstral のプロンプトは、固定のシステムプロンプトと、3つのタグで構成されたユーザーメッセージからなります。

システムプロンプト（固定）：

Judge whether the Document meets the requirements based on the Query and the
Instruction provided. Note that the answer can only be "yes" or "no".

ユーザーメッセージ側（ここを差し替えてポリシーを変える）：

出力：文字列ではなくスコアを読む

Shieldstral は「yes」か「no」を生成しますが、実運用で読むべきは生成された文字列ではありません。1回のフォワードパスで得られる「yes」トークンと「no」トークンのlogitを取り出し、softmaxで正規化した0〜1の連続スコアを使います。

デフォルトの閾値は0.5ですが、公式は自社データでキャリブレーションしてから本番投入することを推奨しています。連続値で受け取れるからこそ、「0.9以上は自動拒否、0.4〜0.9は人間レビュー、0.4未満は自動通過」といった段階的な運用が組めます。

日本語対応の実態 ―「12言語対応」と「日本語で高精度」は別物

日本語は公式が明記する対応12言語に含まれています。これは日本企業にとって最重要の事実ですが、そのまま「日本語でも英語並みの精度が出る」と読むのは早計です。

理由は2つあります。

1. 日本語単体のベンチマークスコアは公開されていない。公式が出しているF1値はすべて英語中心のベンチマーク（WildGuardTest、ToxicChat、HarmBench等）に基づくものです。
2. 公式自身が「カバレッジは不均一」と認めている。技術レポートの付録では、アラビア語とインドネシア語で複数のベースラインに劣ることを自己申告しています。日本語がどの位置にあるかは公表されていません。

したがって実務上の結論は、「日本語で使えるが、日本語データでの独自評価は必須」です。導入前に自社の日本語コンテンツ数百件に人手でラベルを付け、閾値を決める工程を省略しないでください。

日本語での <Query> の書き方例

Shieldstral は判定ルールを平文で受け取れるため、日本語の質問文をそのまま渡せます。粒度の設計が精度を左右するので、悪い例と良い例を並べます。

ポイントは3つです。（1）必ず疑問文にする（ラベル名や単語の羅列にしない）、（2）1つの質問に1つのポリシーだけ入れる、（3）「実行可能な水準で」「具体的に」など判定の閾値になる修飾を入れる。

複数カテゴリをまとめて見たい場合は、<Instruct> にカテゴリを列挙したうえで <Query> を「この内容は安全ではないものに該当しますか？」という広い問いにする、というのが公式の案内です。ただし、この方法はどのカテゴリで落ちたのかがわからなくなるため、精密な運用では1カテゴリ1コールが基本になります。

ベンチマーク：3Bで20B級に並ぶ実力

出典: Mistral AI 公式ブログ「Introducing Shieldstral」

Mistral 公表の測定値では、Shieldstral-3B はテキスト安全性の平均F1で84.9%と、パラメータ数が約7倍の gpt-oss-safeguard-20B と同水準に並びます。マルチモーダルでは既存モデルを大きく引き離しています。

総合スコア

注目すべきは3行目です。 「未知のポリシーにどこまで追随できるか」を測るポリシー適応性では、Shieldstral は gpt-oss-safeguard-20B に負けています。Shieldstral の売りは「ポリシーを自由に書ける」ことですが、その一点だけで最強というわけではありません。

個別ベンチマーク（F1％／公式モデルカード）

プロンプト分類：

応答分類：

マルチモーダル：

画像を含む判定では差が明確です。UnsafeBench で LlamaGuard-4-12B が30.8にとどまるのに対し、Shieldstral は81.8。UGCの画像審査を機械化したい事業者にとっては、ここが導入理由になります。

注意点として、これらはすべて Mistral 自身による測定値です。 第三者による独立検証に Shieldstral が含まれているかは、現時点では確認できていません。自社ドメインで再測定する前提で読むべき数字です。

なぜ3Bで大型モデルに並べるのか

技術レポートによると、鍵はコントラスティブ・ポリシーペアという学習データの作り方にあります。

LLMに「あるポリシーには違反するが、隣接する非常に似たポリシーには違反しない」という文章のペアを大量に生成させ、カテゴリ名を丸暗記するのではなく、ルールとルールの境界線を識別する能力を学習させました。学習データは約5,410万件（公開テキスト安全データ4,520万＋合成コントラスティブ440万＋マルチモーダル450万）です。

アブレーション実験の数字が説得力を持ちます。公開データのみで学習した場合のF1は61.1%。そこに合成タクソノミーデータを加えると84.4%（+23.3ポイント）まで跳ね上がりました。しかも評価用のタクソノミーは、学習用とカテゴリ名・粒度・グルーピングを意図的にずらして設計されており、暗記ではなく汎化であることを示す作りになっています。

最終的なチェックポイントは、3本のLoRA微調整（公開データでキャリブレーションしたもの／生成データで細粒度識別を学んだもの／ベースのinstructモデル）を SLERP（球面線形補間）でマージしたものです。学習基盤には Mistral の Forge プラットフォームが使われています。

料金：ウェイトは無料、コストはGPU側に移る

コスト構造の本質は「APIトークン課金 → GPU時間課金」への置き換えです。

判断の考え方はシンプルです。

• 月間のモデレーション件数が少ない → GPUを常時起動する固定費が重くのしかかる。外部APIのほうが安い
• 月間の件数が多い／トラフィックが安定している → GPU1枚の固定費で処理し放題になるため、件数が増えるほど有利
• そもそもデータを外部に出せない → 件数に関係なく自己ホスト一択

必要なのはBF16精度で単一の16GB NVIDIA GPUです。メディアの実機報告では RTX 4080 / A4000 クラスが挙げられており、量子化すればさらに軽い環境でも動くとされていますが、量子化時の必要VRAMは公式が明記していません。BF16での16GBが公式に確認できる唯一の線です。

同じ16GB級で動くモデルの選択肢としては、Gemma 4 12B のような軽量LLMもあります。ただし用途が違い、Shieldstral は生成ではなく判定に特化している点を混同しないでください。

使い方：起動から判定まで

実行環境の選択肢

ローカルでのモデル実行環境を整える一般的な手順は Ollamaとは でも扱っています。ただし Shieldstral の公式手順は vLLM が中心で、スループットを求める本番運用では vLLM か SGLang が現実的です。

スコアの取り出し方

最も重要な実装ポイントは、生成されたテキストを文字列としてパースしないことです。

OpenAI互換エンドポイントに対して max_tokens=1、logprobs=True、top_logprobs=20 を指定し、返ってきたlogprobsから「yes」「no」トークンの確率を取り出してsoftmax正規化します。文字列で "yes" を判定してしまうと、せっかくの連続値シグナルを二値に潰すことになり、閾値調整もトリアージ設計もできなくなります。

導入の実務手順

1. 判定したいポリシーを日本語で棚卸しする（利用規約・ガイドラインを質問文に分解する）
2. 1ポリシー＝1つの <Query> に落とし込む
3. 自社データ数百件に人手でラベルを付け、正解セットを作る
4. スコア分布を見て、自動拒否／人間レビュー／自動通過の2つの閾値を決める
5. 敵対的な入力（言い換え、伏せ字、丁寧語での言い換え）でテストする
6. ポリシー質問文をバージョン管理された形でデプロイし、判定ログにバージョンIDを残す

最後のバージョン管理は運用が始まってから追加するのが難しい部分なので、最初から入れておくことを強く推奨します。

実装でつまずきやすい落とし穴

公式のLimitationsと、公開直後の技術検証・開発者コミュニティから挙がっている論点を整理します。

こうした「フィルタをどうすり抜けられるか」という観点は、AIジェイルブレイクの深刻度評価フレームワークやChatGPT Lockdown Modeのような入力側防御の議論とセットで押さえておくと設計しやすくなります。

できないこと・制約

導入前に必ず確認すべき制約です。

• 理由を返さない。出力は0〜1のスコアのみで、なぜフラグが立ったのかの説明（reasoning trace）はありません。ユーザーからの異議申し立て対応や、監査での説明責任が求められる場面では致命的になり得ます。ここは gpt-oss-safeguard が理由を出力する点で明確に優位です。
• 音声・動画は未対応。扱えるのはテキストと画像のみです。公式ロードマップ上の今後の課題として挙げられています。
• 生成用途には使えない。会話・要約・書き換えはできません。判定専用モデルです。
• 多言語カバレッジが不均一。現状12言語で、言語によって信頼性がばらつくと公式が認めています。
• 長文での頑健性。学習は32kトークンまでで、理論上256kまで対応するものの32k運用が推奨されています。極端に長い文書では信頼性が低下します。
• ライセンス上の注意。Apache 2.0ですが、モデルカードには第三者の権利（知的財産権を含む）を侵害する形で利用してはならない旨の記載があります。

競合ガードモデルとの比較

出典: Mistral AI 公式ブログ「Introducing Shieldstral」

比較ポイントごとの評価

ポリシーの柔軟性：Shieldstral と gpt-oss-safeguard の2択です。ただしポリシー適応性のF1では gpt-oss-safeguard-20B（94.1）が Shieldstral（91.3）を上回ります。

説明可能性：gpt-oss-safeguard の一択です。理由を出力できることは、ユーザー対応と監査対応の両面で強い武器になります。ただし中間推論が長い分、推論コストは重くなります。

マルチモーダル：Shieldstral が明確に優位です。VLGuard 97.7、UnsafeBench 81.8 という数字は他の公開ガードモデルと差があります。

ハードウェア効率：Shieldstral（3B・16GB）が最軽量クラスです。20Bのモデルを常時走らせるコストとは桁が違います。

多言語：純粋な言語数では Qwen3Guard の119言語が圧倒的です。日本語を含む主要12言語で足りるなら Shieldstral、それ以外の言語が必要なら Qwen3Guard という整理になります。

導入の手軽さ：OpenAI Moderation API が圧倒的です。無料でGPU不要、APIを叩くだけ。開発者コミュニティでも「無料で非常に過小評価されている」という評価があります。

なお Llama Guard は、複数の第三者評価で他モデルに劣後する結果が出ています（LlamaGuard-4-12B のテキスト平均F1 69.1%）。開発元の最新モデル動向は Llama 4 Scoutとは で扱っています。

どれを選ぶべきか

自己ホストで発生するガバナンス上の宿題

Shieldstral を選ぶということは、モデレーション判断の責任をベンダーから自社に移すということです。 これは技術的な話ではなく、組織の話です。

推論時にポリシーを自由に変えられる設計は柔軟である一方、「いつ、どのポリシー質問が有効だったか」を記録していないと、事故調査や規制当局のレビューの際に当時の安全基準を再構成できないというリスクを生みます。AIガバナンスの専門機関からも同様の指摘が出ています。

実装すべき運用ガード

• オープンソースモデルの受け入れ審査プロセスに乗せる（ライセンス確認、脆弱性確認、供給元の妥当性）
• デプロイ文脈ごとにバージョン管理されたポリシー質問レジストリを作る。判定ログには「どのバージョンの質問文で、どのスコアが出たか」を必ず残す
• 自社ポリシーに対する敵対的テストを定期実施する（言い換え・伏せ字・多言語混在）
• タクソノミー保守のオーナーを明示的に決める。誰も持ち主がいないポリシー定義は必ず腐ります
• 閾値の変更履歴を残す。閾値は事実上のポリシーです

EU AI法との接続

EU AI法は2026年8月2日に全面適用されました。 欧州市場向けにサービスを提供する日本企業にとっては、まさに現在進行形の論点です。

ここで問題になるのが、自己設定型・推論時のモデレーション制御が、高リスクAIシステムに課される文書化・透明性要件を満たすと言えるかという点です。現時点では当局のガイダンス待ちの領域であり、確定した答えはありません。実務的には「監査に耐えられる記録を残しておく」以外に安全な打ち手はない、というのが妥当な判断です。規制の全体像は EU AI規制法 完全施行ガイド で整理しています。

また、Apache 2.0でのモデル公開そのものに対する業界内の議論（オープンウェイトは安全か）については、Anthropicのオープンウェイトモデルに対する立場やOpen Secure AI Allianceの動向も参考になります。

実務での運用パターン：3段階トリアージ

Shieldstral が0〜1の連続スコアを返すことを活かした、現実的な運用設計を示します。二値判定で自動ブロックするだけの設計は、誤検知でユーザーを失うか、見逃しで炎上するかのどちらかに寄りがちです。

閾値の具体値は自社データで決めるものであり、上の数値はあくまで設計の形を示す例です。

この構成には副次効果があります。中間帯に流れた案件の人間判断ログが、そのまま閾値の再調整とポリシー質問文の改善に使える教師データになります。運用しながら精度が上がる仕組みを最初から組み込めるかどうかが、モデレーション基盤の寿命を決めます。

生成AI全般のセキュリティ設計における位置づけは 生成AIのセキュリティリスクと対策 も併せて確認してください。

こんな企業・チームにおすすめ

• データを外部に出せない制約がある組織。金融、医療、官公庁、法務、機微な個人情報を扱う事業者。GDPR・個人情報保護法の観点で外部API送信を避けたい場合、自己ホストできる高精度ガードモデルは強い選択肢になります
• UGC（ユーザー投稿コンテンツ）で画像を扱っている事業者。マルチモーダル判定の精度差が最も効く領域です
• 自社独自の細かいポリシーを多数運用している組織。広告審査基準、コミュニティガイドライン、業界固有の規制など、汎用カテゴリでは表現できないルールが多いほど価値が出ます
• モデレーション件数が多く、API課金が積み上がっている事業者。GPU固定費への置き換えで単価が下がります
• GPUリソースとMLOps体制を既に持っている開発チーム。追加投資なしで試せます
• 生成AIサービスの過剰拒否に悩んでいるチーム。拒否検出を品質指標として使えます

おすすめしない企業・チーム

• GPUを持っていない／用意できない組織。16GB GPUの調達と常時運用が前提です。月間件数が少ないなら、外部APIのほうが確実に安く済みます
• 判定理由の説明責任が厳しい領域。金融規制下のコンテンツ審査や、ユーザーからの異議申し立てに個別回答する必要がある事業では、理由を返さない設計は運用に耐えません
• 音声・動画のモデレーションが主目的の事業者。現時点で対象外です
• モデレーション基盤の保守担当を置けない組織。ポリシー定義・閾値調整・敵対的テスト・継続保守はすべて自社の負担になります。「入れて終わり」にはできません
• 12言語以外の言語が主戦場のサービス。対応言語を確認してください
• まずは最小コストで有害コンテンツ対策を始めたい段階のチーム。無料の外部APIから始め、件数と要件が育ってから移行するほうが合理的です

よくある質問

Q. Shieldstral は ChatGPT や Claude のように会話できますか？
できません。Shieldstral は判定専用のモデルで、文章生成・要約・翻訳などの用途には使えません。会話用のAIについては 生成AIとは や 生成AIツールおすすめ比較 を参照してください。

Q. Mistral の公式APIから使えますか？
2026年8月6日時点で、Mistral の公式価格ページに Shieldstral の記載を確認できていません。現時点では Hugging Face からウェイトを取得して自己ホストする形が前提と見るのが妥当です。なお、Mistral には別系統の Mistral Moderation API（mistral-moderation-2603、テキスト専用・日本語対応）があり、これは Shieldstral とは異なるモデルです。

Q. 既存の Llama Guard から乗り換える価値はありますか？
テキストのみの用途でも平均F1で大きな差（84.9% vs 69.1%）があり、画像を扱うなら差はさらに広がります。加えて12Bから3Bへの軽量化でGPUコストも下がります。乗り換えの技術的な合理性は高いといえます。ただし、既存のS1〜S14カテゴリ前提のログや運用フローを、質問文ベースの設計に作り直す移行コストは見積もっておく必要があります。

Q. 日本語のポリシーを日本語で書いても動きますか？
日本語は対応12言語に含まれるため、日本語の <Instruct> と <Query> を渡すことは可能です。ただし日本語単体の性能は公表されていないため、英語で質問文を書いた場合との精度差を自社データで比較してから決めることをおすすめします。

Q. GPUの推論速度やスループットはどのくらいですか？
公式・第三者ともに公開された実測値を確認できていません。3Bかつ1トークンのみを生成する構成なので軽量なはずですが、具体的な数値は自社環境での測定が必要です。

Q. 量子化すればもっと小さいGPUで動きますか？
llama.cpp向けに Q8_0 / Q5_K_M / Q4_K_M への量子化が可能とされています。ただし、公式が明記しているのは「BF16で16GBに収まる」までで、量子化時の必要VRAMや精度低下の程度は公表されていません。

Q. Mistral の他のモデルとどう組み合わせますか？
Mistral は用途特化型モデルを並べる戦略を取っており、文書処理の Mistral OCR 4、ロボティクスの Robostral Navigate、業務自動化の Mistral Studio Workflows などがあります。Shieldstral はこれらの入出力に共通の安全レイヤーとして挟む位置づけになります。

まとめ

Shieldstral は、「ポリシーを再学習なしで差し替えられる」という一点で、ガードモデルの運用コストを構造的に変えたモデルです。3Bで20B級に並ぶテキスト性能、画像判定での明確な優位、16GB GPU 1枚で動く軽さ、Apache 2.0という条件が揃っており、自己ホスト型のモデレーション基盤としては現時点で有力な選択肢です。

一方で、判定理由を返さないこと、日本語単体の性能が未公表であること、ポリシー保守と閾値調整の責任が完全に自社へ移ることは、導入前に組織として合意しておくべき論点です。特に、ポリシー質問文のバージョン管理と判定ログの保存は、EU AI法の全面適用後の環境では後付けが難しくなります。

導入判断の目安はシンプルです。データを外に出せない／画像を扱う／独自ポリシーが多い／件数が多い のいずれかに当てはまるなら試す価値があり、GPUがない／説明責任が厳しい／音声動画が主戦場 ならば別の選択肢を検討すべきです。

次に読むべき記事

• Mistral AIとは — 開発元の全体像とモデルラインアップ
• EU AI規制法 完全施行ガイド — 2026年8月2日全面適用後の実務要件
• AIエージェント セキュリティ 対策 — 入出力ガードレールを含む防御設計
• 生成AIのセキュリティリスクと対策 — 企業導入時のリスク全体像
• AIエージェントとは — ガードレールが必要になる背景

参照した公式情報

• Introducing Shieldstral | Mistral AI
• mistralai/Shieldstral-1.0-3B（Hugging Face モデルカード）
• Shieldstral 技術レポート（arXiv:2607.25857）
• Mistral API Pricing（公式）
• Mistral Docs: Guardrailing / Moderation