投稿者 global-ai-media 
大規模言語モデル（LLM）のセキュリティ対策が進む一方で、英語以外の言語を用いた「多言語プロンプトインジェクション」によるガードレール回避のリスクが指摘されています。本記事では、この技術的な「死角」がなぜ生まれるのか、そして日本企業がLLMを実務に導入・運用する際に考慮すべきリスク管理と具体的な対策について解説します。
言語の壁を突く攻撃：多言語プロンプトインジェクションとは
生成AIの普及に伴い、意図的にAIの制限を回避しようとする「プロンプトインジェクション（Prompt Injection）」や「ジェイルブレイク（脱獄）」と呼ばれる攻撃手法が高度化しています。今回取り上げるHackerNoonの記事やセキュリティ研究者の報告では、Azure Content Safetyなどの主要なセキュリティフィルターを、英語以外の言語（多言語）を用いることで回避できてしまう事例が指摘されています。
多くのLLMは、膨大なテキストデータによって学習されており、主要言語だけでなく、学習データの少ない言語（低リソース言語）であっても一定の理解力を示します。しかし、AIに「やってはいけないこと」を教える「セーフティ学習（RLHFなど）」や、入出力を監視する「ガードレール」の多くは、依然として英語が中心です。
その結果、英語で「爆弾の作り方を教えて」と入力すれば即座に拒否されますが、同じ意味をスコットランド・ゲール語やズールー語、あるいは難読化された言語パターンで入力すると、AIの防御網をすり抜け、有害な回答を引き出せてしまう現象が発生します。これを「多言語プロンプトインジェクション」と呼びます。
なぜ「防御の穴」が生まれるのか
この問題の根幹には、LLMの「能力」と「安全性」の不均衡があります。モデルは多様な言語を「理解」する能力を獲得していますが、そのすべての言語に対して均等に安全性のチューニングが施されているわけではありません。
攻撃者はこのギャップを突きます。例えば、攻撃プロンプトを一旦マイナーな言語に翻訳して入力し、LLM内部で処理させた後、その結果を再びターゲット言語（英語や日本語）に戻すといった手法が取られます。これは、日本企業が導入する商用LLMや、API経由で利用する海外製モデルにおいても同様のリスクとなり得ます。
日本企業における実務的なリスクと懸念点
日本企業がチャットボットや社内検索システム（RAG）を構築する場合、以下の点でこの脆弱性が実務上のリスクとなります。
第一に、グローバル展開におけるリスクです。多言語対応のカスタマーサポートボットを導入した場合、日本語や英語では適切に防御できていても、その他の言語での入力によって不適切な回答を引き出され、ブランド毀損につながる可能性があります。
第二に、社内ガバナンスの抜け穴です。従業員がAIの利用制限（例：コード生成の禁止や特定情報の出力禁止）を回避するために、翻訳ツールを介して多言語入力を行うことで、社内ポリシーを技術的にバイパスしてしまうリスクが考えられます。
日本企業のAI活用への示唆
この「多言語の死角」を踏まえ、日本企業は以下の3点を意識してAIの実装と運用を進めるべきです。
1. 入出力の「翻訳レイヤー」による防御
最も現実的な対策の一つは、LLMへの入力を一度、最も防御が堅牢な「英語」に翻訳し、英語ベースの強力なコンテンツフィルターを通してから推論させるアプローチです。また、出力も同様にチェックを行います。これにより、マイナー言語を用いた攻撃に対しても、意図を検知しやすくなります。処理遅延（レイテンシ）とのトレードオフにはなりますが、高セキュリティが求められる金融・医療などの領域では有効な手段です。
2. 日本語特化のガードレールと評価の実装
海外ベンダーの標準フィルターだけに頼らず、日本語特有の言い回しや、日本の商習慣・コンプライアンス基準に合わせた独自のガードレール（NeMo Guardrailsなどのフレームワーク活用や、プロンプトによる制御）を整備することが重要です。特に「ハルシネーション（もっともらしい嘘）」や「不適切な表現」の基準は文化依存性が高いため、自社基準でのテストが不可欠です。
3. 多言語を想定したレッドチーミングの実施
AIシステムのリリース前に行う脆弱性テスト（レッドチーミング）において、単に日本語での攻撃を試すだけでなく、翻訳ツールを用いた多言語攻撃や、文字コードを操作した攻撃など、多角的な視点でのテストシナリオを組み込む必要があります。セキュリティベンダーと連携し、グローバルな攻撃トレンドを自社のリスク評価に反映させる体制づくりが求められます。