サイトにレビュー機能を足した。あるいは会員同士が投稿できるコミュニティを開いた。そこまではよかったのに、半年後には「投稿を毎朝ざっと見る」のが特定の1人の仕事になっている。
この状態は、担当者が休むと止まります。そして本人以外は判断基準を知らないので、代わりも立てられません。通報が来たときの対応履歴も、その人のメールボックスの中にしかない。投稿機能を持つサイトを運用している会社で、かなりの割合で発生している詰まり方です。
自動化しようとして市販のモデレーションAPIを調べると、次の壁に当たります。判定カテゴリが提供側で決まっているという壁です。暴力的表現、性的表現、ヘイト。どれも必要ですが、実際に困っているのはそこではないことが多い。「他社の商品名を出した比較投稿」「業界の資格制度に関する誤った断定」「自演レビューっぽい文面」。これらを止めたいのに、既製のカテゴリには存在しません。
判定基準を平文で書いて渡す形
Mistral が2026年8月4日に公開した Shieldstral は、ここに別のやり方を持ち込んでいます（Introducing Shieldstral — Mistral AI）。
30億パラメータ（3B）の多モーダル安全性分類モデルで、ライセンスは Apache 2.0。重みは Hugging Face で配布されています。特徴は規模ではなく、分類の枠組みそのものにあります。
従来のガードレールモデルが「固定カテゴリへの分類問題」として設計されているのに対し、Shieldstral は推論時に平文で書いたポリシーを受け取る形を取ります。開発者が渡すのは、評価の文脈と、はい/いいえで答えられるポリシーの質問文と、判定対象のコンテンツです。対象はプロンプト単体、応答単体、両者の組、あるいはテキスト付きの画像でも構いません。
モデルは「はい」と「いいえ」のロジットを読み取り、連続値の安全性スコアに変換します。アプリケーション側でしきい値を決められるということです。厳しく倒すのか、確信度の高いものだけ止めて残りは人が見るのか、運用しながら調整できます。
性能面では、テキストの安全性判定で最大7倍のサイズのモデルに匹敵し、多モーダルのモデレーションでは新しい水準を示したとされています。動作要件は16GBのNVIDIA GPU 1枚。
「カテゴリ固定」と「ポリシー可変」の差が効く場面
この違いが実務でどう効くのかを整理すると、次のようになります。
| カテゴリ固定型 | ポリシー可変型 | |
|---|---|---|
| 判定軸の変更 | 提供側の対応待ち | 質問文を書き換えるだけ |
| 業界固有のNG | 表現できないことが多い | 平文で記述できる |
| 判定理由の説明 | カテゴリ名のみ | 渡したポリシーがそのまま根拠になる |
3行目は運用で地味に効きます。投稿者から「なぜ削除されたのか」と問われたとき、「ヘイトスピーチに分類されました」より「当サイトでは資格の有無を断定する記述を禁止しています」のほうが説明として成立するからです。判定基準がそのまま利用規約の文言と揃えられる、という言い方もできます。
全部を機械に任せる前提で考えない
ここで一度、期待値を下げておく必要があります。モデレーションを完全自動化しようとすると、たいてい失敗します。誤判定でまともな投稿を消せば利用者が離れ、緩めれば意味がない。
現実的に効くのは、人が見る量を減らす使い方です。
- 全投稿にスコアを付け、明らかに安全な帯は自動で通す。ここが投稿量の大半を占めます
- 明らかに危険な帯は自動で保留にし、公開前に止める
- 残った中間の帯だけを人が見る
この形にすると、毎朝の目視は「全部」から「判断が割れるものだけ」に変わります。担当者1人の属人業務だったものが、しきい値という数字で管理できる工程になる、という点がいちばんの変化です。
小さなモデルを自社側で動かす構成そのものの利点と注意点はGemma 4 でローカルLLM環境を作るやMicrosoft Foundry Local 入門で扱っています。生成物の出自をどう記録するかという隣接した論点はAI生成コンテンツの来歴管理にまとめました。
自社で動かすか、APIで済ませるか
重みが公開されていることは、必ずしも「自前で動かすべき」を意味しません。判断は主に2点で決まります。
1つめは、投稿を外部に出してよいかどうか。会員限定コミュニティの投稿や、社内システムへの入力を判定する用途では、外部APIに本文を送ること自体が承認を取りにくい。この場合、自社環境で完結する構成の価値が出ます。
2つめは、量と波の大きさ。投稿がキャンペーン期間だけ跳ねるような形なら、GPUを常時抱えるより従量課金のほうが安く付きます。逆に一定量が毎日流れるなら、自前のほうが読みやすくなります。
どちらにせよ、先に決めるべきはインフラではなくポリシーの文面です。何を止めたいのかを平文で書き出す作業は、モデルを使うかどうかに関係なく必要で、しかもそこが一番時間がかかります。既存の利用規約とカスタマーサポートの対応履歴を突き合わせて、実際に止めてきたものを言語化するところから始めるのが早道です。
手を付けるなら
いま投稿の目視確認が属人化しているなら、直近1か月分の対応履歴を並べて、止めた理由を分類してみるのが最初の一歩です。この分類がそのままポリシーの下書きになります。分類してみると、実際には3〜5種類の理由しか出てこないことがほとんどで、その時点で「機械に振れる範囲」が見えます。
投稿機能を持つサイトの運用設計や、判定の自動化をどこまで組み込むかといった相談は、グリームハブの開発・AI・自動化のご相談で承っています。投稿量や扱う情報によって適切な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
