AIガードレールは日本語の攻撃をどこまで止められるか｜主要6製品の検証で見えたこと

IPAが2026年1月に公表した「情報セキュリティ10大脅威 2026（組織編）」では、「AIの利用をめぐるサイバーリスク」が初選出ながら3位に入りました。生成AIの業務利用が広がるにつれ、そのリスクへの備えが企業にとって具体的な課題になっていることを示す結果です。

過去の記事「LLMガードレールとはAI時代の新たな脅威と守り方‐続編」で、プロンプトインジェクションや情報漏えいを防ぐ仕組みとしてガードレールの必要性と技術を解説しました。

https://www.ctc-g.co.jp/keys/blog/detail/llm-guardrail-security

※過去の記事では「LLMガードレール」と表記していましたが、昨今「AIガードレール」という呼称が用いられるようになっています。本記事でも、以降この呼称を用います。

既に各ベンダーからAIガードレール製品が市場にリリースされており、公開された情報を読み解くと一見どの製品も同じような特長を備えているように見えます。しかし、日本語で書かれたプロンプトを実際どこまで検知できるのでしょうか。

本記事では、主要ベンダー6社の AI ガードレール製品に共通の日本語プロンプトを入力し、その検知結果を比較しました。あわせて、検証を通じて確認できた各社製品の特長をご紹介します。

なお、製品の優劣を決めることが目的ではないため、製品名は伏せてA社〜F社と表記しています。また、本記事で紹介する検証結果は、いずれもCTCが独自に実施した検証によるものです。各製品は継続的にアップデート、機能改善されているため、検証実施時期や検証方法によって、本記事の内容とは異なる結果となる場合がありますので、ご留意ください。

検証の概要

今回の6製品は、守る対象によって2つのタイプに分かれます。自社で開発したAIアプリケーションの入力と出力を検査する「API型」と、従業員が外部の生成AIサービスを使う際の通信を端末のエージェント経由でSASE基盤が検査する「SASE型」です。API型には、アプリから検査用のAPIを呼び出す方式と、アプリとLLMの間の通信経路に検査を挟む方式がありますが、本記事ではまとめてAPI型と呼びます。また、AIガードレールにはこのほか、クラウド基盤に組み込まれたものやブラウザ上で動作するもの、AIゲートウェイ上で動作するものも登場していますが、今回は上記の2タイプに絞って検証しています。

検証対象は表1のとおりです。

表1　検証対象

API型は、AWS上に構築したチャットボット（LLMはAmazon Bedrock経由）に組み込んで検証し、SASE型は、エージェントを導入した端末からChatGPTを利用する形で検証しました。

検証には、CTCが独自に作成した試験プロンプトを用いました。OWASPが公開する「OWASP Top 10 for LLM Applications 2025」の10カテゴリに沿った日本語の不正プロンプト209件に加えて、氏名・住所・マイナンバーなどを含むものや、表記を崩して難読化したもの、情報を聞き出そうとする誘導型のものなど、個人情報に関する15項目・103件も用意しました。どちらにも、本来は止めてはいけない通常の業務質問（それぞれ13件、11件）を混ぜ、過検知の有無も確認できるようにしています。

※OWASP Top 10 for LLM Applicationsは2026年8月に2026年版が公開されていますが、試験プロンプト作成時点で公開前であったため、2025年版をもとにしています。

図1　試験プロンプトの例

※記事掲載用に書き起こした例であり、実際の試験プロンプトとは文面が異なります。

①は、攻撃命令をユーザーが直接打ち込むのではなく、要約を頼んだメール文中に紛れ込ませたものです。文面そのものは問題のない内容ですが、ガードレールには中身まで読んで判断することが求められます。②は、プロンプト中に、氏名や電話番号、メールアドレスを記号、全角文字で崩して書いたものです。故意過失問わず、個人情報が再学習や保存に使われることのないよう、入力段階で防げるか、さらに決まった書式に当てはまらない日本語表記を見抜けるかを確かめる狙いがあります。③は①②とは逆に、「暗証番号」という言葉を含むものの、止めてはならない例です。正当なプロンプトを妨げないことも、ガードレールに求められる機能です。

検知の判定条件は全製品でそろえ、各製品のガードレール機能をすべて有効にした状態で試験プロンプトを実行し、いずれかのガードレール機能が反応した場合を「検知」と判定しました。

検証結果

不正プロンプトの検知

図2　OWASP Top 10 for LLM Applications 2025 カテゴリ別の検知率（単位：%）

上述の試験プロンプトを全製品で試したところ、平均検知率ではD社製品が83%を超える結果となり、SASE型のE社、F社は低い数値となりました。

一方、カテゴリ別に見ると、平均値とは異なる傾向が表れています。C社は平均こそ58.1%ですが、プロンプトインジェクション（LLM01）を見ると83%で、D社の87%とほぼ同じ水準です。図1の①のような、文書の中に命令を紛れ込ませる手口もこのカテゴリに含まれます。E社も、システムプロンプトの漏えい（LLM07）では86%と、6製品中で最も高い値でした。

個人情報の検知

図3　PIIに関する検知率結果抜粋（単位：%）

※禁止キーワード：事前登録した語句を含むプロンプトで検証。F社は登録できる語句が英単語のみ、E社は今回の構成で語句登録による検知を設定できず判定不能のため0%として集計。

個人情報でも、平均の首位はD社（84.5%）でした。2番目は、不正プロンプトでは低い値にとどまったE社で、61.1%とA社（59.5%）をわずかに上回っています。今回の検証では、不正プロンプトへの強さと個人情報の検知性能は必ずしも一致しませんでした。

全製品を通じて検知率が低かったのが住所です。最も高い製品でも56%、2製品は0%でした。日本の住所は「２丁目８ー１」「2-8-1」のように表記が統一されておらず、半角カナが混在することもあります。一定の書式を前提とした検出方法では捉えにくいことが、要因の一つと考えられます。

図1の②に当たる難読化したPIIでは、E社が75%で最も高く、A社とD社が63%で続いた一方、F社は1件も検知できませんでした。

各社製品の特長

検証では、検知率とあわせて機能網羅性や管理画面の操作性といった定性的な内容も確認しました。以下、各社製品の特長を筆者視点でご紹介します。

A社（API型）―運用面の作り込みが最も進んでいた製品

日本語の不正プロンプトの検知率が高く、実装機能も最も充実していました。検知しなかったものも含めて、すべてのプロンプトとレスポンスがログに残り個別のログ詳細も確認可能でした。検知した個人情報はマスキングや別の文字列への置き換えができ、遮断以外の対応を選べる点も実運用で有用です。ポリシー作成を支援するAIアシスタントも備えており、総じて高機能と使いやすさを両立した製品という印象です。

留意点は、制御できるトピックがあらかじめ用意されたものに限られることです。たとえば「金融アドバイスには答えさせない」といった独自のトピックを、自然言語で追加することはできませんでした。

B社（API型）―文脈を読む検知に強い製品

日本語入力に特化したポリシーをメーカーが提供している点が特長で、不正プロンプトの平均検知率は76.6%、過剰なエージェンシー（LLM06）では95%と6製品中で最も高い値でした。独自のポリシーを自然言語で記述し、細かなニュアンスまで指定できたのは6製品中この製品のみでした。電話番号や氏名といった個々の個人情報の検知は15%にとどまった一方、個人情報を聞き出そうとするプロンプトは85%、誘導型は83%を検知しており、文面の意図を読み取る検知に強みがあります。

一方、今回の方式では、検知・未検知を問わず判定結果を管理画面で確認できず、どのルールで検知したのかはAPIの応答を個別に見て調べる必要があり、運用面での留意点です。

C社（API型）―管理機能が充実し、キーワード制御が確実な製品

ポリシー、APIキー、カスタムルールを一つの管理画面で扱え、画面が整理されていて操作性にも優れています。ログはアプリケーション単位・セッション単位で詳細確認することができ、アプリごとのトークン消費量も見られます。

留意点は、プロンプトの内容を確認できるのが検知したものに限られる点です。本製品単体では許可されたプロンプトをログから確認できないため、見逃しを探して設定を改善するのは事実上不可能でした。また、氏名や電話番号のように表記が多様な個人情報は22%、住所は0%と、キーワードとして指定しにくい情報の検知は不得手でした。

D社（API型）―検知率トップ、ただし過検知に注意

不正プロンプトと個人情報の両方で、平均の検知率が最も高かった製品です。検知しなかったものも含めて、すべてのプロンプトとレスポンスをログで確認でき、トークン数の管理にも対応しています。

一方、今回の検証では図1の③のような通常の業務質問について過検知が多い傾向が確認されました。設定の中で調整できるのは3段階の閾値と、既定カテゴリ判定のオン・オフに限られ、チューニング自由度が不足している印象となり、これが過検知の要因とも考えられます。また、検知した個人情報のマスキングに対応していない点も留意すべき項目でした。

E社（SASE型）―個人情報の検知に強みを持つ製品

個人情報の検知は平均61.1%で、6製品中2番目でした。図1の②のように記号や読み仮名で崩した個人情報も75%を検知しており、システムプロンプトの漏えい（LLM07）も86%と高めです。複数の単語を組み合わせてトピックを指定することもできます。

一方で、プロンプトの中身をログで確認できるのは検知したものに限られ、検知の強度を細かく調整する手段も限られているなど留意すべき点が散見されました。また、今回の検証では、本来ブロックされるはずの文章が検知されない、ログが出力されないといった状態が断続的に確認され、動作不安定さが非常に気がかりな印象となりました。

F社（SASE型）―既存環境へ手軽に導入できる製品

F社製品を導入済みの環境であれば、設定追加のみで利用開始が可能で、導入容易性は6製品中もっとも優れていました。一方、今回の日本語プロンプトに対する検知率は、総じて低い結果となりました。管理者が追加できる検知キーワードは英単語のみで、単語の一致による判定が基本です。また、ログで確認できるプロンプトはポリシーで検知したものに限られ、実利用において留意すべき項目が多い印象となりました。

検証結果からの考察

守る対象の違いが生んだ検知率の差

今回の検証結果からはタイプによる差がはっきり表れました。日本語の不正プロンプトに対する平均検知率は、API型の4製品が58.1〜83.2%だったのに対し、SASE型の2製品は12.4%と32.3%にとどまっています。API型が守るのは自社のAIアプリそのものであり、アプリの指示を乗っ取ろうとするプロンプトインジェクションへの対策が中心になります。一方、SASE型が守るのは従業員と外部のAIサービスの間です。従業員が外部のAIサービスに攻撃を仕掛ける場面よりも、顧客情報や個人情報をうっかり入力して社外に持ち出してしまうリスクのほうが現実的です。実際、E社製品では、氏名・住所・電話番号・クレジットカード番号など18種類の個人情報の検出項目が用意されており、DLPやアクセス制御との組み合わせにより情報漏えいの防止を重視した作りであることがうかがえます。

全てのプロンプトを追えるか

次に、検知率以上に差が大きかったのが、ガードレールに検知されないプロンプトもログに残るかという点です。検知したものしかログに残らない製品では、見逃しの発生そのものを把握できません。今回の6製品のうち、未検知分も含めてすべての入出力を管理画面のログで確認できたのはA社とD社でした。B社は管理画面では判定結果を確認できず、C社・E社・F社は検知したものに限られていました。

何を手がかりに検知しているか

また、今回の検証では、製品ごとに「何を手がかりに検知しているか」の違いも見えてきました。C社は禁止キーワードを100%検知した一方、氏名や電話番号などの個人情報は22%にとどまっています。逆にB社は、個々の個人情報の検知は15%でしたが、個人情報を聞き出そうとするプロンプトは85%を検知しました。前者は決められた語句や書式を確実に捉える検知、後者は文面の意図を読み取る検知に強みがあると考えられます。実際の業務では、マイナンバーのように書式の決まった情報と、遠回しに情報を引き出そうとする会話の両方が入力されます。どちらか一方の方式だけで守りきるのは難しく、両方の性質を備えているか、あるいは場面に応じて複数の対策を組み合わせられるかが問われるといえるでしょう。

日本語で自社独自のルールを書けるか

さらに、日本語で自社独自のルールを書けるかどうかも各社で明確な差がありました。実際の業務シーンでは、「採用や退職に関する相談には答えない」「特定の取引先の情報は扱わせない」といった、組織ごとの禁止事項がつきものです。今回の検証では、独自のポリシーを自然言語で細かく指定できたのはB社のみでした。A社は用意されたトピックの制御にとどまり、D社は独自のトピックを英語で定義する方式、F社は追加できる検知キーワードは英単語のみでした。日本語への対応の深さは、製品を選ぶうえで見落とせない差といえるでしょう。

まとめ

いかがでしょうか？

今回の検証では、日本語の攻撃に対して75%を超える検知率を出す製品が複数ありました。その一方で、住所への対応や、運用を支えるログの残り方には、製品によってかなりの差がありました。また、守る対象によってAPI型とSASE型の位置づけが分かれることも、今回の比較で明らかになった点です。

AIガードレールは、生成AIの活用を制限するためのものではなく、安全に使い続けるための仕組みです。製品間にはカタログ上の機能比較では見えない差があるため、自社の業務に近い環境で十分に検証し選定することが重要となるでしょう。

※本記事の検証結果は、CTCが独自に実施した検証によるものであり、CTCの検証環境および検証時点のバージョンにおける結果です。各製品の性能を保証または否定するものではありません。また、製品のアップデートや新機能の実装により、本記事の内容はこの限りではありません。

出典・参考情報

独立行政法人 情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」　https://www.ipa.go.jp/security/10threats/10threats2026.html

OWASP GenAI Security Project「OWASP Top 10 for LLM Applications 2025」　https://genai.owasp.org/llm-top-10/

OWASP「OWASP Top 10 for Large Language Model Applications」（2026年版の公開情報）　https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/