AIガードレールの設計と実装：チェック箇所・主要ツール・最小構成

AIガードレールは、リクエストの受信、取得したコンテキスト、モデルの提案、ツールの実行、回答の送信という5つの境界で考えると整理できます。コンテンツフィルターは、禁止された回答を検出できます。しかし、その顧客にレコードの閲覧を許可するか、返金を認めるかは、アプリケーション側で判断する必要があります。小規模なチームなら、分類器を増やす前に、まずこうした権限を整えるべきです。

AIガードレールとは何ですか？

ガードレールとは、文書に書かれたポリシーを、AIアプリケーションが受け取れる情報、開示できる情報、実行できる操作に反映させる仕組みです。大規模言語モデル（LLM）は回答や操作の提案を生成します。ガードレールは、その入出力をチェックしたり、周辺のソフトウェアに制約を設けたりします。

博物館を思い浮かべてください。入口ではチケットを確認し、各部屋には入室のルールがあり、保存修復の担当者が展示品を動かすには許可が必要です。チケットの確認が済んだからといって、館内のあらゆる行動が認められるわけではありません。同じように、顧客のメッセージに有害な内容がなくても、その顧客が注文の所有者だとは確認できません。

ガードレールを実際に機能させるには、ルール、チェック、その結果に応じた処理の3つが必要です。「顧客データを開示しない」がルールです。要求されたレコードの所有者と、認証済みの顧客を照合するのがチェックです。一致しなければデータベースの読み取りを拒否することが、結果に応じた処理に当たります。処理を止めずにログへ残すだけでは、問題が起きた後に記録しているにすぎません。

チェックには、同じルールと入力から必ず同じ判断を返す、決定論的なものがあります。許可されたツール名や必須フィールドの確認がその例です。一方、コンテンツがポリシーに違反するかを推定するモデル、つまり分類器を使うチェックもあります。トピックの検出や有害コンテンツの分類はこちらです。また、実行が認められる操作でも、影響が大きい場合は、実行前に人の承認を挟んで判断を加えます。

AIガードレールは、こうした制御全体を指す言葉です。Guardrails AIは、その中の特定のフレームワークを指します。カテゴリーと製品を混同すると、重要な境界の責任者が決まらないままになりかねません。

AIガードレールの具体例：返金リクエストを最初から最後まで追う

返金リクエストは、ごく普通の文面でも、処理の段階ごとに異なるチェックが必要です。たとえば、顧客から「直近の注文を返金して、確認メールを新しいアドレスに送ってください」と届いたとします。ここでは、返金前には承認が必要で、確認メールはアカウントの確認済みアドレスにのみ送る、というポリシーを想定します。

処理の流れは、入力チェック → 範囲を限定したコンテキスト → モデルの提案 → 権限を確認し承認を得た操作 → 出力チェックです。その後にツールを呼び出す場合も、該当するチェックを繰り返します。

モデルに渡す前に：認証、フィルタリング、データの最小化

まず、チャットに入力された名前やアカウント識別子ではなく、認証済みのセッションから顧客を特定します。処理コストの高い工程に入る前に、リクエストサイズとリクエスト頻度を制限します。

次に、禁止コンテンツ、対応範囲外のトピック、不要な機密データがメッセージに含まれていないかを確認します。トピックフィルターは、サポートアシスタントが無関係な助言へ脱線するのを防ぐために使えます。個人情報フィルターなら、業務に必要のない電話番号が貼り付けられていた場合に削除できます。PIIは、メールアドレスや電話番号など、個人を特定できる情報を意味します。

ワークフローに本当に必要な情報は、代わりの経路を用意せずに削除してはいけません。確認済みのアカウント情報はアプリケーション内に保持し、モデルには必要最小限のコンテキストだけを渡します。また、モデルを呼び出す前にテキストをマスキングしても、リクエストログにすでに記録されたコピーは消えません。収集時とログ記録時にも、データを最小限に抑えます。

検索・取得の前に：取り込めるレコードを制限する

顧客の注文は、そのアカウントに範囲を限定したクエリで取得します。非公開の情報がモデルに届く前に、この制限を適用しなければなりません。顧客間でレコードが漏れないようにする主たる防壁として、出力フィルターでは遅すぎます。

取得したドキュメント、Webページ、ツールの実行結果も、モデルへの入力です。ヘルプ記事に、アプリケーションのルールを上書きしようとする指示が含まれていることもあります。これは間接プロンプトインジェクションと呼ばれる問題です。取得したテキストは、内容を吟味するための資料として扱い、ワークフローを変更する権限として扱わないでください。

モデルには、返品ポリシーと、その注文が条件を満たすかどうかの情報が必要かもしれません。しかし、全顧客の取引情報は必要ありません。取得範囲を限定し、不要なフィールドを削り、選んだ資料に関連するコンテンツ上のリスクがないかを確認します。

モデルの処理段階で：提案の形式を制約する

要求された操作や注文識別子など、あらかじめ決めたフィールドを使って、構造化された提案をモデルに出させます。内容を解釈する前に、その構造を検証します。

JSONがスキーマに適合していても、確認できるのはデータの形式が正しいことだけです。架空の注文識別子でも、有効な文字列にはなります。モデルがフィールドを埋めただけで、顧客の本人性、返金の適格性、あるいは提案自体の承認状態が確定する設計にしてはいけません。

この例では、モデルは返金を提案し、メールアドレスの変更依頼にも気づくかもしれません。どちらの操作を認めるかは、アプリケーションが判断しなければなりません。

ツールの実行前に：権限と承認を確認する

ツールとは、モデルが呼び出しを要求できるアプリケーションの関数です。返金関数を実行する前に、関数名、引数、顧客と注文の所有関係、現在の注文状態、業務上の適格性を確認します。想定外のフィールドは拒否し、実際に操作を行うサービス側でも同じチェックを強制します。

人による承認は、具体的な提案ができた後、実際の変更が発生する前に行います。承認者には、対象の注文、予定している返金、送付先、その理由を提示します。承認は、その特定の操作にひも付けます。引数が変わった場合、以前の承認では実行を許可できません。

新しいメールアドレスへの送信は、返金とは別の権限の問題です。この例では、アプリケーションは顧客をアカウントの確認手続きへ案内し、その手続きが終わるまでは既存の確認済みアドレスを使います。コンテンツフィルターで、メールアカウントの所有者を確認することはできません。

回答を送信する前に：実行結果と開示内容を検証する

ツールの実行結果をモデルのコンテキストに戻す前に、内容を確認します。返すフィールドを制限し、形式を検証したうえで、失敗した処理や成否が曖昧な処理を明示的に扱います。

続いて、顧客に見せる回答に、禁止コンテンツ、機密情報、裏付けのない主張が含まれていないか、必要な応答形式を満たしているかを確認します。「返金が完了しました」と伝えるには、ツールの実行結果で完了が確認できていなければなりません。承認待ちなら、その状態を回答に示します。

入力と出力のチェックには似た分類器を使う場合がありますが、役割は異なります。前者は処理に入れる内容を決め、後者は顧客に届ける内容を決めます。どちらも、すでに実行された権限外の操作を取り消すことはできません。

AIガードレールの主要ツール：公式ドキュメントで分かる対応範囲

ツールは、どの境界の制御に役立つか、どのルールを自分たちで維持できるかを基準に選びます。以下の機能比較は、2026年10月17日に各ベンダーの公開中の公式ドキュメントで確認したものです。比較対象は文書に記載された対応範囲であり、検出精度の実測値ではありません。

各ツールの出典リンクと実装上の制約は、以下で説明します。「利用側に残る責任」は、記載された対応範囲から導かれる設計上の責任です。フレームワークを使うと独自の制御を書けなくなる、という意味ではありません。

Guardrails AIとは何ですか？

Guardrails AIは、モデルの入出力にバリデーターを組み合わせ、構造化データの生成にも対応するPythonフレームワークです。導入ドキュメントで、フレームワークとバリデーター群の概要が説明されています。

バリデーターは、値が基準を満たすかを確認し、合格または不合格を返します。不合格時の処理は、設定したon_failポリシーで決まります。ドキュメントには有害な言葉やPIIを対象とした例があり、独自のバリデーターも作成できます。バリデーターの概念を参照してください。

既存のPythonアプリケーションに、明示的な検証ルールを組み込みたい場合に向いています。課題は適用範囲です。フレームワークを追加しただけでは、各処理経路でどのチェックを行い、不合格なら何を止めるかは決まりません。アプリケーションとともに、その判断を実装し、テストする必要があります。

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrailsは、LLMとのやり取りの複数の段階に、プログラムで制御を組み込める仕組みです。公式ドキュメントのレールの種類には、入力、取得、対話、実行、出力のレールが挙げられています。

入力レールは、コンテンツの安全性、ジェイルブレイク、トピック、PIIに対応できます。取得レールはコンテキストを確認し、対話レールは会話の流れを制約します。実行レールではツールの入力と結果を検証でき、出力レールでは応答のフィルタリング、編集、ブロックができます。

やり取りの流れを制御する必要がある場合に向いています。課題はポリシーの実装です。実行レールは操作をチェックする場所を提供しますが、顧客と対象データの所有関係や業務ルールは、自分たちのコードで実装しなければなりません。基盤となるサービス側でも、これらの権限を強制してください。

Amazon Bedrock Guardrails

Amazon Bedrock Guardrailsは、コンテンツフィルター、禁止トピック、単語フィルター、機密情報フィルター、コンテキストグラウンディング、Automated Reasoningチェックを設定できます。機密情報フィルターは、対応するPIIや独自のパターンをブロックまたはマスキングできます。Automated Reasoningチェックは、論理ルールに照らして応答を評価します。保護機能の概要を参照してください。

ApplyGuardrail APIでは、基盤モデルの呼び出しとは独立してテキストを評価できます。情報を取得する前や、応答を返す前に組み込めます。

ポリシーチェックをマネージドサービスに任せたいアプリケーションに向いています。ただし、すべてのチェックがすべてのコンテンツを対象にすると考えてはいけません。各機能には固有の適用範囲があり、概要ドキュメントでは推論コンテンツブロックが対象外とされています。コンテンツ評価に合格しても、それだけで返金の権限が認められるわけではありません。

AIのセキュリティを守る、モデル提供元の制御機能

OpenAI moderationは、対応するテキスト・画像入力の有害コンテンツを分類し、フラグ、カテゴリー、スコアを返します。モデレーションのドキュメントには、有害な内容に言及する拒否応答でも、フラグが立つ場合があるという注意点が記されています。

これらの結果は、ポリシー判断の材料として扱います。暴言を引用しているサポートの会話と、暴言の生成を依頼するリクエストでは、対応を変える必要があるかもしれません。モデレーションはコンテンツの判断に役立ちますが、注文へのアクセスルールまで用意してくれるものではありません。

**Google Gemini**には、有害性のカテゴリーとブロックのしきい値を組み合わせる安全性設定があります。現行の安全性設定ガイドでは、ハラスメント、ヘイトスピーチ、性的コンテンツ、危険なコンテンツ、ジェイルブレイクなどのカテゴリーが扱われています。

Googleは、コンテンツが安全でない確率と、起こり得る被害の深刻さを区別しています。これは実務上の重要な限界です。分類器のスコアが低くても、その操作の影響が小さいという証拠にはなりません。モデル提供元の制御機能は有用な構成要素ですが、アプリケーション側には、権限、データの範囲、失敗時の処理が引き続き必要です。

AIエージェントのガードレールで設計すべきこと

エージェントには、操作の提案と実行の間に、確実に機能する境界が必要です。フレームワークのフックで実装する場合も、通常のサービスコードで実装する場合も、信頼できる本人情報と、現在のアプリケーションの状態に基づかなければなりません。

許可するツールのリストを明示し、呼び出しのたびに引数と対象リソースを確認します。「返金」ツールの使用が認められていても、すべての注文を返金できるわけではありません。また、汎用シェルや制約のないネットワークツールを与えると、実行可能な操作の範囲は、用途を絞った業務関数よりもはるかに広がります。

承認は、会話中の「はい」で済ませず、実行可否の判断に使える記録にします。何を、誰が、どの操作内容に対して承認したのかを保存します。実行前には状態を再確認してください。承認者が判断している間に、その注文がすでに返金済みになっている可能性もあります。

サービス側で冪等性キーを必須にします。これは処理を一意に識別する安定した識別子で、再試行時に返金を重ねて実行せず、既存の結果を返すためのものです。認証情報に付与する権限は絞り、チェックを強制する経路はモデルの制御外に置きます。エージェントが、チェックを迂回できる別のエンドポイントを選べる状態にしてはいけません。

周辺のアーキテクチャについては、本番運用のAIエージェント向けガードレールと影響範囲を抑える実践ガイドで詳しく扱っています。このリクエストで決定的に重要なのは、モデルが誤った操作を提案したとき、どのサービスが実行を拒否するのかという問いです。

公開前に押さえておきたい制約

機能名から想像できる範囲と、実際に動作する条件は一致しません。採用するチェックそのものの適用範囲を確認してください。

たとえばAWSのドキュメントでは、コンテキストグラウンディングの対象は、参照ソースとクエリを伴う要約、言い換え、質問応答です。一方、会話形式のQ&Aやチャットボットの用途は、明示的に対象外とされています。記載されている上限は、ソースが100,000文字、クエリが1,000文字、応答が5,000文字です。これは当該機能の文字数制限であり、モデル全般のコンテキスト上限ではありません。また、ほかのBedrockの保護機能をチャットボットで使うことまで禁止しているわけでもありません。コンテキストグラウンディングのドキュメントを参照してください。

グラウンディングが確認するのは、回答が与えられたソースに沿っているかどうかです。ソース自体が古かったり間違っていたりすれば、一致していても正しいとは限りません。返金の例なら、現在の注文状態は、正とする情報を管理するサービスから取得しなければなりません。

ストリーミングでは、チェックを強制するタイミングが変わります。 AWSは、コンテキストグラウンディングの関連性判定が、応答のストリーミング後に届く場合があると注意しています。より一般的には、回答全体を開示前に検査するポリシーなら、チェックに合格するまで回答をバッファリングして保持します。すでに表示したテキストは、後から回答を拒否しても取り戻せません。

タイムアウトした場合の処理も決めておきます。 必須の権限確認や承認確認なら、状態を変更する操作を停止し、保留または有人サポートへ進む経路を用意します。リスクの低い応答では、どのような限定的な代替対応を認めるかを明示します。チェック機構の失敗を、黙って処理続行の許可に置き換えてはいけません。

実際のワークロードで、追加される遅延と誤ったブロックを測定します。正当な顧客が自社のサポート業務を最後まで利用できるかどうかは、ベンダーのスコアでは判断できません。

小規模チームが始めるための最小構成

説明でき、動作を確かめられ、責任者を決められる6つの制御から始めます。比較表にあるすべてのフレームワークを採用する必要はありません。

1. 1

   本人確認とデータの範囲

   情報の取得とツールの実行には、認証済みの顧客コンテキストを使います。モデルが要求しても、別の顧客の注文を読み取れないことをテストします。

2. 2

   入力ポリシーとデータの最小化

   対応する業務を定義し、関連するコンテンツ上のリスクをチェックして、不要な機密フィールドを除きます。対応範囲外のリクエストには、安全に返せる応答を決めておきます。

3. 3

   出力が満たすべき条件

   必須フィールド、情報開示のルール、操作完了に関する記述を検証します。回答に信頼できる裏付けがなければ、不確実であることを伝えるか、サポートへ案内します。

4. 4

   操作の制限と承認

   用途を絞った業務ツールを公開します。実行前に本人情報、引数、現在の状態を確認し、ポリシーで影響が大きいと定めた操作には承認を必須にします。

5. 5

   失敗時の動作と運用上限

   リクエスト、ツール呼び出し、再試行、実行時間に、ワークフローに応じた制限を設けます。必須のチェックや後続のサービスが失敗した場合の動作を定義します。提案を修正した場合や再試行する場合は、再検証します。

6. 6

   回帰テストと監査証跡

   不要な機密データをコピーせず、ルールのバージョン、判断、ツールの実行結果、承認の参照情報を記録します。既知の権限外の情報開示や操作が起きたら、リリースを止めるようにします。

顧客向け機能が非公開レコードを読み取ったり、状態を変更したりできるなら、開発者は今すぐ対応すべきです。まず、サービス側の権限を実装します。運用担当者には、エスカレーション、正当なリクエストの誤ブロック、チェック機構の利用不能に対応する責任者が必要です。キューがあっても、担当者がいなければワークフローは完成していません。

導入を検討する側は、足りない境界を特定するまで、別のガードレール製品の追加を待つべきです。書き込みツールを持たない公開ドキュメント用アシスタントに、返金の承認フローは必要ありません。それでも、関連するコンテンツチェック、信頼できる情報取得、明確な代替対応は必要です。機能が広がった段階で、操作を制御する仕組みの追加が必要になります。

Promptfooでアプリケーションをテストする

Promptfooは、評価とレッドチーミングのためのツールです。通常の動作と、意図的に攻撃を仕掛けるリクエストの両方をテストできます。エージェントのテストに関するドキュメントでは、ロールによる制限、権限のないオブジェクトへのアクセス、権限のない関数へのアクセスを確認するチェックが説明されています。

代表的な本人情報とテスト用データを用意し、アプリケーションの境界をテスト対象にします。モデル単体のテストでは、顧客が実際に利用する情報取得の権限、承認ワークフロー、ツールを実行するサービスが抜け落ちます。

想定した返金フローでは、次のケースから始めます。

• 条件を満たす注文： 提案は承認の段階まで進み、承認されるまで実行されません。
• 別の顧客の注文： 情報の取得と操作の実行の両方で、アクセスを拒否します。
• 確認メールの送信先変更： アプリケーションは、別途の確認手続きを必須にします。
• 取得したコンテンツに隠された指示： 権限を付与したり、承認ポリシーを変更したりできません。
• 承認後に変更された提案： 以前の承認で、新しい引数の実行を許可することはできません。
• チェック機構の停止やリクエストの繰り返し： 必須チェックを迂回せず、同じ操作を重複して実行しません。

これらはテストケースの提案であり、実施済みのテスト結果ではありません。最終回答だけでなく、実際に生じた変更と保存された状態も確認します。ツールがすでに操作を実行していたら、回答が「それはできません」でも安心材料にはなりません。

Promptfooのクイックスタートでは、テスト対象の設定、攻撃カテゴリー、テストの実行、レポートの確認を順に説明しています。Promptfooのレビューでは、評価のワークフローをさらに詳しく紹介しています。攻撃的なケースとともに通常の顧客リクエストもテストに残し、フィルタリングを厳しくした結果、本来の業務が知らないうちに使えなくなることを防ぎます。

AIガードレールへの過度な期待とは？

ガードレール製品は、安全性を一括で保証する万能のスイッチではありません。価値を決めるのは、何をチェックするのか、どこで動くのか、その判断によって何を防ぐのかです。

システムプロンプトを長くすればポリシーを詳しく表現できますが、データベースの権限を強制することはできません。別のモデルに回答を批評させることもできますが、モデル同士の一致は正しさの証明にはなりません。分類器を積み重ねても、操作の境界の欠落を埋められず、誤ブロックと運用の手間だけが増える場合もあります。

最も堅実な出発点は、具体的な失敗ケースに対応した、少数の明示的な制御です。実際に確認された不足を補うときにチェックを追加し、結果が改善したかを測定します。

「ガードレールのないAI」には何が足りないのでしょうか？

顧客向け機能では、どの制御が欠けているかを問うほうが役立ちます。モデル提供元のコンテンツフィルタリングがあっても、顧客ごとの権限、出力の検証、承認を強制する仕組みがないアプリケーションもあります。それを「ガードレール付き」と呼ぶと、不足が見えなくなります。

逆に、決定論的なアクセス制御があるアプリケーションでも、コンテンツチェックが必要な場合があります。コンテンツの安全性と、権限に基づく動作は別の要件です。どちらかのラベルだけで、両方を満たしているとは判断できません。

よくある質問

AIガードレールにはどのような種類がありますか？

実装上の分類としては、入力チェック、取得したコンテキストのチェック、出力チェック、ツール実行の制御、人による承認が有用です。トピックフィルターやPIIフィルターは、これらの複数の境界で適用できます。

AIガードレールはどう作ればよいですか？

起きてはならない結果を明確にし、該当する情報開示や操作の前にチェックを置き、失敗時の応答を定めて、アプリケーション全体をテストします。ポリシーの保守とエスカレーションに対応する責任者も決めます。

Guardrails AIでは何ができますか？

Guardrails AIは、バリデーターを入力・出力のガードに組み合わせ、構造化データの生成にも対応します。どのリスクをチェックし、不合格時にどう処理するかは、設定とアプリケーションコードによって決まります。

ガードレールのないAIはありますか？

アプリケーションによって、備えている制御は異なります。導入時は、呼び名に頼らず、個々の境界を監査してください。モデルのコンテンツ保護だけでは、顧客の権限確認や人による承認は実現できません。

AIのセキュリティで優先すべき3つのリスクは何ですか？

このカスタマーサポートの例では、プロンプトインジェクション、権限外のデータ開示、権限外の操作から着手します。これは、このワークフローに即した実務上の優先順位であり、AIリスク全般の普遍的なランキングではありません。

次の月曜日に着手すること

実際の顧客リクエストを1つ選び、認証から最終回答までの経路を図にします。各境界に、ルール、それを強制するコンポーネント、失敗時の応答、責任者を書き込みます。エージェントの権限を広げる前に、権限外のレコード読み取りと未承認の操作を、発生すればリリースを止めるテストにしてください。

実践的なAI導入ガイドをニュースレターでお届けします。