LLMジェイルブレイク、日本語は英語より通りやすい

LLMジェイルブレイク、日本語は英語より通りやすい 研究・論文

生成AIの安全対策（ガードレール）は、英語で検証しただけでは自社の実態を保証しません。2026年7月11日にarXivで公開された査読前の研究「Minionese」は、18言語・3モデルを横断して検証し、英語では約8%しか通らない有害な要求が、言語や表記を変えるだけで大幅に通ってしまうことを示しました。日本語は「安全な高リソース言語」ではなく、崩壊が始まる境界のすぐ内側にあります。

社内で生成AIを導入・評価する立場なら、「ベンダーが安全性テストをしています」という説明を、そのまま日本語環境の保証として受け取ってよいのかを考え直す材料になります。

この記事でわかること

  • LLMの安全対策が「言語をまたぐと効かなくなる」仕組み
  • 日本語がどの位置にあり、どの攻撃手法に弱いのか
  • ローマ字表記（音韻転写）という、見落とされがちな抜け道
  • 情シスが社内AI利用のリスク評価で確認すべき観点
  • この研究の限界と、鵜呑みにしてはいけない点

本記事が扱うのは査読前（プレプリント）の研究です。結果は今後の査読・追試で変わりうるため、断定的な結論としてではなく「検証すべき仮説」として扱ってください。

どんな研究か

Minioneseは、多言語でのジェイルブレイク（安全対策の回避）耐性を体系的に測るベンチマークであり、同時に「なぜ回避できてしまうのか」をモデル内部の表現から分析した研究です。

項目 内容
論文 Minionese: Comprehensive Benchmark and Mechanistic Study of Multilingual LLM Safety
著者 Chigozirim Ifebi、Brent Kong、Ayushi Mehrotra
公開 2026年7月11日（arXiv、査読前）
対象言語 18言語（学習データ量に応じて4段階のティアに分類）
対象モデル Llama-3.1-8B-Instruct、Qwen2.5-7B-Instruct、Aya-Expanse-8B
攻撃手法 4種類（標準翻訳／コードスイッチ／音韻転写／翻訳体）

日本語はどのティアに入るのか

研究は、学習データの豊富さで言語を4ティアに分けています。日本語はティア2です。

  • ティア1（最も豊富）：英語、スペイン語、中国語、ドイツ語、フランス語
  • ティア2：日本語、韓国語、アラビア語、ロシア語
  • ティア3：トルコ語、インドネシア語、ヒンディー語、スワヒリ語
  • ティア4（最も乏しい）：ヨルバ語、ズールー語、スコットランド・ゲール語、グアラニー語、ジャワ語

重要なのは、研究がティア2とティア3のあいだで安全性が急激に崩れる「閾値効果」を全モデルで一貫して観測した点です。日本語は崩壊の手前にありますが、余裕のある位置ではありません。

何が新しく分かったのか

低リソース言語では安全対策がほぼ機能しない

Llama-3.1の場合、英語をはじめとするティア1の攻撃成功率（ASR）は約8%にとどまります。ところがティア3〜4になると70%超に跳ね上がり、標準的な翻訳だけでヨルバ語100%、スコットランド・ゲール語98%、ズールー語97%という数値が報告されています。単に有害な要求をその言語へ翻訳するだけで、拒否がほぼ働かなくなるということです。

非ラテン文字のローマ字化が特に効いてしまう

情シスとして最も注目すべきはここです。音韻転写——発音を保ったまま本来の文字（漢字・かな・ハングルなど）を捨ててラテン文字に置き換える手法——は、非ラテン文字の言語に対して極端に有効でした。論文は韓国語で98〜99%、中国語で97%という成功率を報告しています。日本語も同じ非ラテン文字圏であり、論文の図表を見る限り同様に高い水準を示しています（個別の数値はヒートマップからの読み取りであり、正確な値は論文の付録を直接ご確認ください）。

平たく言えば、「危険な指示を日本語で書いて、それをローマ字に直す」だけで拒否をすり抜けられる可能性がある、ということです。暗号でも高度な攻撃技術でもありません。

拒否機能は「壊れて」いない、ただ「発動しない」

研究の中核は、線形プローブと部分空間解析による内部メカニズムの分析です。結論は直感に反します。

  • ティア3レベル：モデルの拒否メカニズム自体は保たれているが、有害性が拒否を発動させる方向に十分に投影されない（閾値以下の活性化）。門番は立っているのに、危険信号が届かない状態です。
  • ティア4レベル：有害性の表現そのものが崩壊し、有害かどうかの検出精度が偶然と変わらなくなる（意味的回復の失敗）。危険信号がそもそも生成されません。
  • 英語の拒否は多次元的に働くが、言語をまたいで転移するのは第1の方向だけだった。安全対策の「厚み」が翻訳で失われるということです。

つまり、安全対策の弱さは「その言語の学習データが少ないから雑になる」という単純な話ではなく、有害性の認識と拒否の発動が、言語ごとに別の場所で切れている構造的な問題だと示唆されます。

現場目線の課題

正直に言えば、この研究の指摘は情シスにとって扱いづらいものです。

社内で生成AIを導入するとき、安全性の担保はほぼ全面的にベンダー側に依存しています。モデルの内部表現を我々が検査できるわけもなく、「安全性評価を実施済み」というベンダーの言葉を信じる以外に現実的な選択肢がない。ところがその評価が英語中心であれば、日本語で使う我々の環境は、実は評価されていない領域に置かれている可能性がある——これが本研究の含意です。

さらに厄介なのは、この抜け道が技術的に高度ではない点です。ローマ字化も、日本語と英語を混ぜるコードスイッチも、悪意ある外部の攻撃者どころか、社内の従業員が興味本位で試せてしまう水準です。ガードレールを「越えられない壁」として社内説明してきた場合、その説明は修正が必要かもしれません。

加えて、社内AIの利用ログを監視していても、ローマ字や言語混在のプロンプトは、日本語のキーワードベースのフィルタをそのまま通過します。禁止語リストで入力を弾く設計をしているなら、その前提は疑ってかかるべきです。

情シスはどうすべきか

この1本の査読前論文を根拠に、社内AIの利用を止めるべきではありません。過剰反応も同じくらい有害です。現実的には、次の観点を評価プロセスに追加するところから始めるのが妥当でしょう。

  • ベンダーへの確認：安全性評価は日本語でも実施されているか。英語のベンチマーク結果のみを提示されていないか。
  • 入力フィルタの前提の見直し：日本語の禁止語リストだけに依存していないか。ローマ字表記や言語混在の入力をどう扱うか。
  • 出力側での防御：入力の拒否だけに頼らず、出力の監査・ログ記録・人による確認を組み合わせる（多層防御）。
  • 利用者への啓発：ガードレールは「回避できてしまう」ものであり、業務利用のルールは技術ではなく運用と教育で支える必要があることを伝える。

生成AIの業務利用ルールづくりや、従業員への啓発の進め方については、自前でチェックリストを作り込む前に公的な指針を土台にするのが確実です。IPAの中小企業の情報セキュリティ対策ガイドラインは、技術対策と運用ルールの両輪をどう回すかの基本形として、規模を問わず参考になります。従業員向けの啓発資料としては対策のしおりが使いやすく、こうした地道な啓発の積み重ねが、結局のところ技術的な抜け道を補う最後の砦になります。

この研究の限界

鵜呑みにしないための留保も明確にしておきます。

  • 査読前のプレプリントであり、結果は追試で変わりうる。
  • 検証されたのは8Bクラスのオープンモデル3種のみ。より大規模な商用モデルに同じ傾向が当てはまるかは未確認です。
  • 著者自身が、翻訳品質のばらつきが結果に混入している可能性（特に音韻転写）を限界として認めています。

裏を返せば、「自社が使っている大規模な商用モデルは大丈夫」とも「危ない」とも、この研究だけでは言えません。だからこそ、ベンダーに日本語での評価結果を求める行動に意味があります。

まとめ

  1. 査読前の研究「Minionese」は、LLMの安全対策が言語をまたぐと崩れ、英語で約8%の攻撃成功率が低リソース言語では70%超に達することを示しました。
  2. 日本語はティア2で、安全性が急落する境界のすぐ手前にあります。特にローマ字化（音韻転写）は非ラテン文字の言語に対して極端に有効で、韓国語98〜99%・中国語97%という成功率が報告されています。
  3. 拒否機能は壊れているのではなく「発動しない」だけ。英語のみの安全性評価では不十分であり、情シスはベンダーに日本語での評価を確認しつつ、入力フィルタへの過信をやめ、出力監査と利用者教育による多層防御に軸足を移すべきです。

関連記事

出典

タイトルとURLをコピーしました