AIガードレールとは？入力・出力の検査と誤検知への対処

AIガードレールは、生成AIの入力・出力や外部システムへの操作を、決めた方針に沿って検査・制御する仕組みです。導入時には、何を止めるかに加え、検知した後にマスク・拒否・人への引き継ぎのどれを行うかを決めます。正常な質問まで止める「誤検知」と、止めるべき依頼を通す「見逃し」を分けて評価すると、設定を見直す対象が分かります。

この記事では、公開FAQ（よくある質問と回答）を案内する架空の窓口を例に、検査する場所と運用の考え方を整理します。製品の実測や、安全性を保証する手順を示すものではありません。掲載図は生成AIを用いて本記事用に作成した概念図です。

AIガードレールとは

生成AIに「個人情報を回答しないでください」と伝えるのは、プロンプト（AIへの指示文）による制御です。これに加え、質問に個人情報が含まれていないか、生成した回答が禁止事項に触れていないかを確認し、処理を分ける仕組みを組み込めます。

たとえばAmazon Bedrock Guardrailsには、扱わないトピックや特定の単語を検査する機能、個人情報などを検知して遮断・マスクする機能があります。どの対象を検査できるかは製品や設定によって異なります。Amazon Bedrock Guardrails

指示文を用意することと、違反を検知した際の処理をシステムに実装することは、役割が異なります。 AIに望む振る舞いを伝えながら、出力や操作を別の段階でも確かめる、という組み合わせで考えます。

検査を追加しても、すべての問題を検知できるとは限りません。文脈の解釈が必要な判定では、正常な利用を止める場合と、問題のある内容を通す場合の両方を評価します。

入力・出力・操作で、確認するものが違う

設計を考えるときは、「何が外へ渡る直前か」に注目すると検査場所を整理できます。

*一般的な検査箇所を独自に整理。外部操作の経路は操作機能がある場合を示し、後述の架空FAQ窓口には契約変更の権限を与えません。*

実際の分類はこれより細かくなります。NVIDIA NeMo Guardrailsは、入力・検索した資料・対話・実行・出力を区別し、実行時にはツール呼び出しの引数や結果も確認対象にしています。本記事の表は、検査場所を理解するための整理です。NVIDIA「Guardrail Types」

特に、「内容に問題がない」と「その操作をしてよい」を同じ判定にしないことが大切です。「契約を解約してください」という自然な依頼でも、別人の契約を変更する権限は生まれません。認証（誰かを確かめること）と認可（その操作を許すこと）は、外部システム側で確認します。AWSも、ツール呼び出しに適切な認証・認可を要求し、操作範囲を制限することを推奨しています。AWS「Secure development practices」

外部の文章に埋め込まれた指示へ誘導される問題は、プロンプトインジェクションの仕組みと対策で詳しく説明しています。

具体例：問い合わせ対応で4つの処理を決める

ここからは筆者が作成した架空の設計例です。窓口の役割を「公開FAQに基づく一般的な案内」に限定し、顧客データの照会や契約変更の権限は与えないことにします。

この前提なら、「解約」という単語だけで止めると、正当な手順案内までできなくなります。内容と求められている操作を分け、検知後の処理まで決めます。

*本記事の架空例。同じ単語が含まれていても、求める処理に応じて対応を分けます。*

この表では、拒否と引き継ぎを使い分けています。不適切な情報提供は拒否しますが、利用者の正当な目的に対応できる別の窓口があるなら、その手続きへ案内します。

マスクも、情報を消せば常に解決するわけではありません。注文番号を消すと問い合わせを特定できなくなる場合など、必要な意味が失われるなら、情報を扱える正式な窓口へ移します。検知漏れや残った情報からの推測もあるため、マスクを匿名性の保証とは扱いません。

また、外部サービスへ送る前の情報保護が目的なら、その送信より前に検査する必要があります。検査を外部サービスへ依頼する構成では、検査先へ何を送ってよいかも設計対象です。

ルールとAI判定をどう組み合わせるか

検査方法は、対象の性質に合わせて選びます。次の表は、方式の役割と制約を筆者が整理したものです。

Amazon Bedrockの例でも、単語の一致、機密情報の検出、トピックの判定などは別の機能です。製品名だけで選ばず、「何を検査して、結果をどの処理へ結び付けるか」を確認します。Amazon Bedrock Guardrails

問い合わせ例なら、電話番号の扱いと契約変更の許可は異なる問題です。一つの内容フィルターへ両方の責任を持たせず、不要な情報の検査と、操作権限の確認を組み合わせます。

誤検知と見逃しは、別々に数える

誤検知は、許可したい内容を誤って止めることです。見逃しは、止めるべき内容を通してしまうことです。「何件止めたか」だけでは、どちらの問題が起きているか分かりません。

以下は計算を説明するための架空の100件です。製品の実測値ではありません。事前に窓口の方針に沿って、通すべき80件と止めるべき20件を決めたとします。

誤検知率は、通すべき内容を分母にして 8÷80×100＝10% と計算します。見逃し率は、止めるべき内容を分母にして 2÷20×100＝10% です。

*計算を説明する架空例。製品の実測値や推奨する合格基準ではありません。*

全体では、期待どおりだった件数は72＋18＝90件なので、一致率は90%です。この数字だけを見ると、8件の正常な問い合わせを止め、2件の禁止内容を通したという違いが見えなくなります。

実際には、誤検知で利用者が手続きできなくなる影響と、見逃しで情報を渡してしまう影響は異なります。質問の種類ごとの件数と結果も残し、影響の大きい失敗から改善します。この100件の割合は説明用であり、本番の問い合わせ比率や将来の精度を表しません。

誤検知が多いときに見直す順序

「解約」という単語が原因で手順案内まで止まったなら、禁止するのが話題なのか、権限のない操作なのかを見直します。正常例を確認せずに検査全体を弱めると、別の依頼まで通す可能性があります。

まず誤って止めた例を読み、方針の曖昧さ、単語ルール、判定する文脈の不足などを切り分けます。そのうえで設定を変え、同じ正常例と禁止例の両方で再評価します。しきい値（判定を分ける境界値）を調整する場合も、誤検知率だけでなく見逃し率を並べて比較します。

導入時に決めることと、変更後の確認

小さな業務範囲から始める場合、次の順で記録を作ると、設定と判断を結び付けられます。これは本記事の設計提案です。

1. 許可する仕事を決める。 「公開FAQの案内は行う」「契約変更は行わない」のように、許可と対象外を具体化します。
2. 期待結果付きの例を作る。 正常例、禁止例、判断が曖昧な例を用意し、マスクや引き継ぎの後も利用目的を満たせるか確認します。
3. 処理の場所と失敗時の動きを決める。 検知後の案内文、引き継ぎ先、検査のタイムアウト時に保留する操作を定めます。
4. 同じ条件で評価する。 誤検知・見逃しに加え、待ち時間と担当者への引き継ぎ件数も見ます。通常の利用が続けられるかが判断材料になります。
5. 版と結果を残す。 モデル、検査設定、業務方針を変えたら、以前の評価例も再実行します。

Amazon Bedrockには、複数の入力を試して検知結果を確認し、設定を版として固定する仕組みがあります。試した設定と実際に使う設定を対応させるための具体例です。AWS「Test your guardrail」

記録には、どの方針で判定したか、どの処理へ進んだか、利用者への応答までにどの程度かかったかを残します。問い合わせ本文には機密情報が含まれ得るため、改善用ログへ生の内容を無条件に保存せず、保存項目・閲覧権限・保存期間も決めておきます。

よくある疑問

AIガードレールは後から追加できる？

入力・出力の検査は既存の処理へ追加できる場合があります。ただし、すでに外部へ送った情報や実行済みの操作を、後から検査しても取り消せません。守りたい対象へデータや操作が届く前に、必要な確認を置けるかを調べます。

ハルシネーションも防げる？

参照資料と回答の整合性を確認する機能はありますが、資料自体が古い・誤っている場合まで正しさを保証するものではありません。回答の根拠を確かめる方法は、ハルシネーションと回答の確認方法で説明しています。

検査サービスが止まったら、すべて通してよい？

停止時の動きは事前に決めます。この架空窓口なら、検査が完了するまでAIが生成した回答を返さず、承認済みの固定案内で正式窓口へ誘導する設計が考えられます。契約変更の権限を与えないという前提は、検査サービスの稼働状況にかかわらず維持します。可用性（利用を続けられること）と、検査せずに処理する影響を、業務ごとに比較する必要があります。

参考資料

仕様の確認日：2026年10月8日。本文の問い合わせ、判定表、100件の計算は筆者による架空例です。

• AWS：Amazon Bedrock Guardrails
• NVIDIA：Guardrail Types
• AWS：Secure development practices for agentic AI systems
• AWS：Test your guardrail