---
title: "AIガードレールとは？入力・出力を検査する実装層の設計と選定基準【2026年版】"
url: "https://www.issoh.co.jp/tech/details/15939/"
published: 2026-07-31
updated: 2026-08-03
categories: ["AI"]
publisher: "株式会社一創"
---

# AIガードレールとは？入力・出力を検査する実装層の設計と選定基準【2026年版】

AIガードレールとは、大規模言語モデル（LLM）の推論の前後に置き、入力と出力を検査して逸脱した内容を止める実装層のことです。モデルそのものを賢くする話でも、社内規程を整える話でもありません。アプリケーションのコードとして書かれ、リクエストごとに判定を返す独立した処理として動きます。

この層の設計を後回しにすると、プロンプトの書き方で押さえ込もうとして破綻します。システムプロンプトに「個人情報は答えないでください」と書いても、指示の上書きを狙う入力が来れば通ってしまう。生成AIの受託開発では、この検査層をどこに置き、何を検査し、どこまでの誤検知を許すかが、そのまま本番稼働の可否を決めます。

本記事では、AIガードレールの定義と守備範囲を整理したうえで、入力レールと出力レールに何を並べるか、ルールベースから形式検証までの実装方式をどう使い分けるか、Amazon Bedrock GuardrailsやNeMo Guardrailsといった既製品と自前実装をどの基準で選ぶかを、実装者の解像度で書きます。レイテンシとコストの見積もり、そして「厚くする場面と薄くしてよい場面」の判断まで踏み込みます。

## まとめ：AIガードレールは推論の外側に置く独立した検査層

先に結論を並べます。AIガードレールは、モデルの内部挙動を調整する手段ではなく、モデルの外側で入出力を検査して止める処理です。プロンプト設計やファインチューニングと同じ土俵で語ると設計を誤ります。

- **置き場所は3つ**：入力レール（モデルに渡す前）、出力レール（ユーザーに返す前）、実行レール（ツール呼び出しやDB更新の直前）。エージェント構成では3つ目が事故の主戦場になります。
- **検査項目はOWASP Top 10 for LLM Applications 2025に紐づける**：プロンプトインジェクション、機微情報の露出、不適切な出力処理、過剰な代理権限あたりが、コードで止められる範囲です。
- **実装方式は4系統**：ルールベース、専用分類器、LLM-as-a-judge、形式検証。応答時間と精度のトレードオフが方式ごとに異なり、1本に統一すると必ずどこかが破綻します。
- **既製品は「単独APIとして呼べるか」で選ぶ**：Amazon Bedrock Guardrails は ApplyGuardrail API によりモデル呼び出しと切り離して評価でき、他基盤のモデルにも同じ検査を当てられます。
- **厚さは一律に決めない**：社内向け閉域の要約ツールと、社外公開のチャットで同じ段数を積むのは設計の怠慢です。判断基準は本記事の最後に条件付きで示します。

以降で、それぞれの根拠と設計手順を順に説明していきます。

## AIガードレールの定義｜プロンプト設計やモデル側の安全化との違い

AIガードレールは、生成AIアプリケーションにおいて、ユーザー入力とモデル出力を所定の基準で検査し、基準を外れた場合にブロック・書き換え・差し替えのいずれかを実行する仕組みを指します。要点は「独立して動く」ことです。モデルへの依頼文の中に混ぜ込むのではなく、呼び出し側のコードが明示的に検査関数を通し、その戻り値で分岐します。

この違いが実務でどう効くかを、よくある3つの対策と並べて整理します。

| 手段               | 効く層          | 限界                       |
| ---------------- | ------------ | ------------------------ |
| システムプロンプトでの禁止指示  | モデルの推論内      | 指示の上書きを狙う入力で無効化される       |
| ファインチューニング・整合性学習 | モデルの重み       | 更新に時間と費用がかかり、要件変更に追随しにくい |
| 社内規程・利用ガイドライン    | 人の運用         | 操作ミスや例外運用を機械的には止められない    |
| ガードレール（本記事の主題）   | アプリケーションのコード | 検査そのものに遅延と費用が発生する        |

4つは競合しません。禁止指示は一次防御として残し、規程は組織の意思決定として残し、そのうえで機械的に止める層を足す、という重ね方になります。組織側の枠組みをどう組むかは[AIガバナンスとは？企業に求められる統制の枠組みと最新ガイドライン対応を解説【2026年版】](https://www.issoh.co.jp/column/details/13377/)で扱っているため、本記事は実装側に絞ります。

### 検査層を置く3つのポイント｜入力・出力・実行の境界を分ける設計

実装位置は、リクエストの流れに沿って3つに分かれます。

1. **入力レール**：ユーザー入力をモデルへ渡す前に検査します。プロンプトインジェクションの検出、個人情報の混入検知、対象外トピックの拒否がここに入ります。RAG構成では、検索してきた文書の中に注入文が埋まっているケースがあるため、取得結果に対する検査（検索レール）も同じ位置づけで必要になります。
2. **出力レール**：生成結果をユーザーへ返す前に検査します。有害表現、機微情報の漏れ、根拠のない断定（ハルシネーション）の検出が中心です。RAGでは、取得済み文書に対して回答が接地しているかを見る接地性チェックが効きます。
3. **実行レール**：モデルが決めたツール呼び出しやSQL発行を実行する直前に検査します。エージェント構成ではここが最後の砦で、削除系APIの呼び出しや外部送信を条件付きで止めます。エージェント全体の制御構造は[AIエージェントの制御基盤となるハーネス設計の全体像と構成要素](https://www.issoh.co.jp/tech/details/11616/)に整理してあります。

3つのうち、実装が漏れやすいのは実行レールです。チャットの見た目だけを検査していると、裏側でツールが動く構成に移行した瞬間に穴が開きます。

## 入力レールと出力レールの検査項目｜OWASP LLM Top 10との対応

「何を検査するか」を自前で列挙すると抜けが出ます。OWASP Top 10 for LLM Applications の2025年版を土台にして、コードで止められる項目と止められない項目を仕分けるのが早道です。2025年版はLLM01からLLM10までを次のように定義しています。

| ID    | 項目                       | ガードレールでの扱い              |
| ----- | ------------------------ | ----------------------- |
| LLM01 | Prompt Injection         | 入力レールで検出。検索結果にも同じ検査を当てる |
| LLM02 | 機密情報の漏えい                 | 入力でマスク、出力で再検査の二段構え      |
| LLM03 | Supply Chain             | 依存管理の領域。ガードレールでは止まらない   |
| LLM04 | Data and Model Poisoning | 学習データ側の管理。実行時の検査対象外     |
| LLM05 | Improper Output Handling | 出力レールで構造検証とエスケープを実施     |
| LLM06 | Excessive Agency         | 実行レールで権限と操作範囲を制限        |
| LLM07 | System Prompt Leakage    | 出力レールで内部指示の文字列を検知       |
| LLM08 | ベクトル・埋め込みの脆弱性            | 検索レールとアクセス権の分離で対処       |
| LLM09 | Misinformation           | 出力レールで接地性を判定            |
| LLM10 | Unbounded Consumption    | 流量制御とトークン上限。周辺の実装で対処    |

この表の使い方は単純です。担当する案件の要件を10項目に当てて、実行時の検査で扱う行だけを抜き出し、それぞれに判定関数を割り当てます。LLM03とLLM04のように実行時の検査では触れない項目を、無理にガードレールへ押し込む設計は費用対効果が合いません。

### 入力レールに並べる典型的な判定｜モデルへ渡す前に遮断する対象

入力側は、通す・止める・書き換えるの3値で設計します。個人情報が混じった問い合わせを一律に止めると業務が回らないため、マスクして通す判定を用意しておくと現場の反発が減ります。

- 指示上書きの検出（「前の指示を無視」「システムプロンプトを出力」等の意図判定）
- 個人情報・カード番号・マイナンバー等のパターン検出とマスキング
- 対象外トピックの拒否（法務相談、投資助言、医療判断など案件ごとに定義）
- 入力長とトークン数の上限、添付ファイルの形式検査
- 言語判定（想定言語以外の入力を別経路に回す）

### 出力レールに並べる典型的な判定｜利用者へ返す前に検査する対象

出力側は、返す・止める・差し替えるの3値です。ブロックした際に何を返すかを決めておかないと、利用者には「壊れている」としか見えません。定型の代替文と問い合わせ導線をセットで用意します。

- 有害表現・差別表現のカテゴリ判定と強度しきい値
- 機微情報の再検査（入力で漏れた分を出口で拾う）
- 接地性の判定（RAGの取得文書に含まれない主張を検出）
- 構造検証（JSON Schema適合、想定外フィールドの除去）
- 内部指示や社内固有名の露出検知

## 実装方式の比較｜ルール・分類器・LLM判定・形式検証の選択基準

判定ロジックの実装方式は大きく4系統あります。応答時間、判定精度、運用の手間がそれぞれ違うため、検査項目ごとに割り当てを変えるのが実務的な解です。

| 方式              | 追加遅延の目安  | 向く検査              | 弱点                |
| --------------- | -------- | ----------------- | ----------------- |
| ルールベース（正規表現・辞書） | ミリ秒未満    | カード番号、禁止語、社名の直接一致 | 言い換えや表記ゆれに弱い      |
| 専用分類器（小型モデル）    | 数十ミリ秒台   | 有害表現、注入意図、トピック判定  | 学習データ次第で日本語精度が落ちる |
| LLM-as-a-judge  | 数百ミリ秒〜秒台 | 接地性、文脈依存の妥当性判断    | 費用が積み上がり、判定自体も揺れる |
| 形式検証（論理規則との照合）  | 実装依存     | 規程やポリシーとの矛盾検出     | 規則の定義コストが高い       |

設計の原則は「安いものから順に落とす」です。正規表現で確実に落とせる入力にLLM判定を掛けるのは費用の無駄になります。段数を組むときは、ルールベース→分類器→LLM判定の順に並べ、前段で結論が出たら後段を呼ばない短絡評価にします。

4つ目の形式検証は、AWSがAutomated Reasoning checksとしてBedrock Guardrailsに載せている方式です。想定される規則を論理として定義し、モデル出力がその規則と矛盾しないかを検証します。就業規則や保険約款のように、記述が確定していて誤答の代償が大きい領域で効きます。定義の初期コストが高い代わりに、判定結果が揺れないのが利点です。

## 主要実装の選び分け｜Bedrock・NeMo・chakoshi・自前実装

既製のガードレール製品は、いずれも入力と出力の検査という枠は同じで、差が出るのは「どこから呼べるか」と「日本語の精度」です。

### Amazon Bedrock Guardrails｜単独APIで検査する構成

AWS公式ユーザーガイド（2026年7月時点）では、コンテンツフィルター、拒否トピック、ワードフィルター、機微情報フィルター、接地性チェック、Automated Reasoning checks の各ポリシーが提供中です。設計上の要点は ApplyGuardrail API の存在で、基盤モデルの呼び出しを伴わずに検査だけを実行できます。つまりBedrock上のモデルに限らず、自己ホストのモデルや他社APIを使っている構成にも同じ検査を適用可能です。マネージドで済ませたい案件では第一候補になります。ポリシーごとの設定手順は[ガードレール for Amazon Bedrock の概要とその目的について](https://www.issoh.co.jp/tech/details/4265/)で個別に解説しています。

### NVIDIA NeMo Guardrails｜対話フローを宣言する構成

オープンソースのフレームワークで、対話フローを宣言的に定義し、入力・出力・検索・実行の各レールを組み立てる仕組みです。0.23系（2026年7月時点で確認）では、Hugging Faceの分類器を使う軽量なレール、入出力検証を単独で呼べるエンドポイント、OpenTelemetryによる計装の拡充などが入っています。自社ポリシーを細かくコードで書きたい場合や、クラウド事業者に依存したくない場合の選択肢です。導入手順とレールの書き方は[NeMo Guardrailsとは何か？AIモデルの制御と安全性確保のためのフレームワークを詳しく解説](https://www.issoh.co.jp/tech/details/9475/)にまとめてあります。

### chakoshi（NTT）｜日本語向け13項目を検知する構成

日本語のLLMガードレールとして提供され、標準で13項目の検知に対応し、カスタム項目を足せます。判定はAPI経由で呼ぶ形式のため、既存アプリへの組み込みが軽量です。国内案件で日本語特有の言い回しや業界用語を扱う場合、海外製の分類器より当たりが良いことがあります。検知項目とAPIの呼び出し方は[chakoshiとは？NTTの日本語LLMガードレールの仕組み・検知項目・API連携【2026年】](https://www.issoh.co.jp/tech/details/5918/)で確認できます。

### 自前実装をどこまで持つか｜既製品と分担する範囲の判断基準を決める

既製品を入れても、案件固有の判定は必ず自前で書くことになります。取引先名の露出禁止、社内用語の言い換え、業務フロー上の禁止操作といった要件は、汎用の分類器では表現できません。実務では「汎用の有害表現・機微情報は既製品、案件固有のルールは自前」の二層構成に落ち着きます。自前部分は判定関数の入出力を統一し、後から製品を差し替えられるようインタフェース側で吸収しておくと、乗り換え時の改修が小さく収まります。

## レイテンシとコストの見積もり｜検査段数と応答体験の全体設計方針

ガードレールの議論で抜けやすいのが、検査そのものの代償です。入力と出力の両方にLLM判定を置けば、体感の応答時間はモデル本体の推論とほぼ同じだけ延びます。ストリーミング表示をしている画面で出力レールを同期的に挟むと、逐次表示の利点が消えて「全文が出来上がるまで無音」の体験に変わります。

見積もりは次の式で押さえます。

**体感応答時間 ＝ 入力検査の合計 ＋ 初回トークンまでの時間 ＋ 出力検査の合計**

ここで入力検査は直列に積み上がりますが、独立した判定は並列実行にできます。指示上書きの検出と個人情報の検出は互いに依存しないため、同時に走らせて結果を待ち合わせれば、合計ではなく最大値で済みます。逆に、マスキングしてから分類器に掛ける、のように前段の結果を使う判定は直列にせざるを得ません。

出力側は3つの構えがあります。

- **全文検査**：生成完了後にまとめて検査します。精度は出ますが、ストリーミングを諦めることになります。
- **チャンク検査**：一定文字数ごとに検査して逐次表示を続けます。表示済みの文字を取り消す設計が要るため、UI側の作り込みが増えます。
- **事後検査**：表示は先行させ、違反検知時に警告を出して記録します。社内向けの限定利用でのみ許容できる構えです。

費用面では、LLM-as-a-judgeの単価が効いてきます。判定用に小型モデルを使い、入力は要約ではなく原文をそのまま渡す構成が一般的なため、判定1回あたりのトークン量は本体の入力とほぼ同じ規模になります。入力・出力の両方でLLM判定を掛ける設計は、素朴に見積もっても推論費用が数割増える計算です。1日あたりのリクエスト数を置いて、判定にかかる分を先に試算しておくと、稟議の段階で揉めずに済みます。

## 評価と運用｜誤検知率の決定基準とレッドチーミングの運用設計方針

ガードレールは入れて終わりにはなりません。しきい値を動かせば、見逃しと過剰ブロックのどちらかが必ず増えます。運用に乗せる前に、評価データセットと合格基準を先に作ります。

### 評価データセットの作り方｜正常系と攻撃系を同じ比率で管理する

用意するのは3種類です。

1. **陽性例**：止めたい入力・出力の実例。攻撃文だけでなく、業務上の誤操作で起きる機微情報の混入も入れます。
2. **陰性例**：通すべき正常な業務入力。ここを軽視すると、過剰ブロックの多さに気づかないまま本番に出ます。
3. **境界例**：判断が割れる入力。人間の担当者でも意見が分かれるものを集め、判定の期待値を合議で決めておきます。

件数は各50件程度から始めれば、しきい値の調整には足ります。重要なのは、実際の業務ログから採ることです。合成した攻撃文だけで調整すると、現場の入力分布とずれた設定になります。

### どちらの誤りを許すかを先に決める｜見逃しと過剰遮断の判断基準

見逃し（False Negative）と過剰ブロック（False Positive）は同時には減りません。案件ごとに、どちらを許すかの明文化が必要です。社外公開のチャットで有害表現を1件でも通すと事業影響が大きい場合は、過剰ブロックを受け入れてしきい値を下げます。社内の調査支援ツールで業務が止まる方が損失が大きい場合は、見逃しを許して事後の記録で担保します。この判断を開発側だけで決めず、事業責任者の合意として残しておくと、後から起きた事故の扱いが揉めません。

### レッドチーミングと再評価の間隔｜変更時と定期実施を組み合わせる

攻撃の手口は入れ替わります。四半期に一度、社内の別チームが攻撃側に回って突破を試み、通った入力を陽性例に追加して再調整する、という周期が現実的です。あわせて、ブロック件数と種別の推移をダッシュボードで見えるようにします。ブロック率が急に跳ねたときは、攻撃が増えたのか、業務側の使い方が変わったのかを切り分ける材料になります。

## 導入判断｜ガードレールを厚く積む場面と薄くできる場面の判定基準

ここが本記事の結論です。段数を積むほど安全になる代わりに、応答は遅く、費用は増え、過剰ブロックの苦情も増えます。一律の正解はないため、条件で切り分けます。

### 厚く積むべき条件（3段以上を推奨）｜事業影響とデータ機密性で判断

- **不特定の社外利用者が直接入力する**：攻撃者が試行を繰り返せる環境では、ルール・分類器・LLM判定の3系統を入力側に置きます。
- **モデルが書き込み系の操作を実行する**：削除・送信・決済に触れる構成では、実行レールで承認を挟みます。自動実行を許すのは読み取り系だけに限ります。
- **回答が意思決定の根拠になる**：契約条件や規程の解釈を返す用途では、接地性チェックを必須にし、確定した規則がある領域では形式検証まで検討します。
- **機微情報を扱う権限で動く**：人事や医療の情報に触れるなら、入力と出力の両方で機微情報の検査を二重に置きます。

### 薄くてよい条件（1〜2段で足りる）｜利用範囲と復旧可能性で判断

- **社内の限定メンバーだけが使い、出力を人が読んで判断する**：議事録の要約や下書き生成であれば、機微情報の検査と記録で足ります。LLM判定を両側に置く必要はありません。
- **出力が構造化データで、後段がプログラム**：JSON Schemaによる構造検証と値域チェックが実質のガードレールとして機能します。有害表現の分類器を足しても効果は薄いです。
- **読み取り専用で、参照範囲が権限で閉じている**：アクセス制御側で情報が絞られているなら、出力側の機微情報検査は簡易な検査で構いません。

### 見送ってよい判断｜本番設計まで実装を持ち越せる条件を明示する

検証段階のプロトタイプで、利用者が開発メンバーだけ、扱うデータが公開情報だけ、という条件が揃うなら、ガードレールの実装は本番設計まで持ち越して構いません。ただしその場合は、本番移行の条件に「ガードレール設計の完了」を明記しておきます。プロトタイプがそのまま社内公開へ流れるのが、この領域で最も多い事故の入口です。ガードレールを入れたあとに効き目を確かめる工程は[AIレッドチーミングの実施手順とツール選定](https://www.issoh.co.jp/tech/details/16071/)で扱っています。

設計から実装、評価データの整備までを内製で回すには、生成AIアプリの実装経験と、業務要件を検査条件へ翻訳する作業の両方が必要になります。一創では[生成AI導入支援](https://www.issoh.co.jp/service/ai/genai/)として、要件の切り分けからガードレールを含む本番構成の実装まで対応しています。どの段数で始めるかの判断からご相談ください。

## よくある質問

### Q1\. ガードレールとAIガバナンスは何が違いますか｜技術と組織の役割

ガードレールは実行時にコードで止める仕組み、AIガバナンスは組織として意思決定と責任分担を定める枠組みです。層が違うため、片方だけでは成立しません。規程で「機微情報を入力しない」と決めても操作ミスは起きるため、コードで止める層が要ります。逆に、コードで止めた案件をどう扱うかの手順は組織側で決める必要があります。

### Q2\. システムプロンプトに禁止事項を書くだけでは不十分ですか

不十分です。システムプロンプトはモデルへの依頼文であり、入力側から指示の上書きを試みる文章が入ると、依頼の優先度が崩れる可能性があります。禁止指示は一次防御として残す価値がありますが、それだけを頼りにする設計は避けてください。判定を外側の独立した処理として持つのが基本形です。

### Q3\. 既製品と自前実装のどちらから始めるべきですか｜選定の順序

既製品から始めることをおすすめします。汎用の有害表現や機微情報の検査は、自前で精度を出すのに相応の工数がかかるためです。まず既製のポリシーで運用を始め、案件固有の禁止事項が固まってきた段階で自前の判定を足す順序が、手戻りの少ない進め方になります。

### Q4\. ガードレールを入れると応答はどれくらい遅くなりますか

方式によって幅があります。正規表現や辞書による検査ならミリ秒未満で、体感の差は出ません。小型の分類器で数十ミリ秒台、LLMによる判定を挟むと数百ミリ秒から秒単位まで延びます。入力と出力の両方にLLM判定を置くと、本体の推論時間に近い分が上乗せされる想定で見積もってください。独立した判定は並列実行にすると合計を抑えられます。

### Q5\. RAG構成で特に注意すべき点はありますか｜検索前後の検査範囲

検索してきた文書そのものを検査対象に含めることです。社内文書やWebから取得したテキストに指示文が埋め込まれていると、利用者の入力を検査していても素通りします。取得結果に対する検査を入力レールと同格で置き、あわせて出力側で接地性を判定し、取得文書に根拠がない主張を検出する構えにしてください。ベクトル検索の権限分離も同時に設計します。

## 関連記事

- [ガードレール for Amazon Bedrock の概要とその目的について](https://www.issoh.co.jp/tech/details/4265/)
- [NeMo Guardrailsとは何か？AIモデルの制御と安全性確保のためのフレームワークを詳しく解説](https://www.issoh.co.jp/tech/details/9475/)
- [chakoshiとは？NTTの日本語LLMガードレールの仕組み・検知項目・API連携【2026年】](https://www.issoh.co.jp/tech/details/5918/)
- [AIエージェントの制御基盤となるハーネス設計の全体像と構成要素](https://www.issoh.co.jp/tech/details/11616/)
- [AIガバナンスとは？企業に求められる統制の枠組みと最新ガイドライン対応を解説【2026年版】](https://www.issoh.co.jp/column/details/13377/)

---

出典: [AIガードレールとは？入力・出力を検査する実装層の設計と選定基準【2026年版】](<https://www.issoh.co.jp/tech/details/15939/>)（株式会社一創）