AIガードレールとは？仕組み・種類とFDEが現場で実装する手順
- 1. ユースケースとリスクの棚卸し利用者・扱うデータ・AIが実行できる操作を一覧にし、OWASP Top 10 for LLMなどを参照して想定リスクを洗い出す
- 2. 止める基準の合意「出してはいけない」「人間の確認が必要」「許容する」の3段階に分け、業務責任者と合意する
- 3. 層ごとの対策を配置入力・出力・行動・運用の各層に、ルールベースの検査とモデル判定の検査を割り当てる
- 4. 評価データセットの作成通すべき正常な依頼と止めるべき攻撃・逸脱の例を用意し、自動テストとして回せる形にする
- 5. 段階的なリリース最初は検知してログに残すだけのモードで動かし、誤検知の傾向を確認してからブロックを有効にする
- 6. 運用と更新ブロックされた事例とすり抜けた事例を定期的に見直し、ルールと評価データを更新する
- 顧客の業務ルール・禁止事項・例外を聞き取って言語化する
- 顧客固有のデータ権限と承認者をガードレールに反映する
- 現場での誤検知・見逃しを収集し、判定基準を調整する
- 導入後の運用担当者に監視と改善の手順を引き継ぐ
- 全顧客に共通する入力・出力検査の仕組みを製品に組み込む
- ガードレールの設定項目やポリシー定義の機能を提供する
- FDEが現場で得た共通課題を製品機能として汎用化する
- モデル更新時にガードレールの回帰テストを実施する
AIガードレールとは何か？
AIガードレールは、生成AIへの入力と生成AIの出力を検査し、危険な内容・誤り・想定外の動作を業務に届く前に止める仕組みです。
生成AIをチャット画面で試していた段階では、誤った回答が出ても人間が読んで捨てれば済みました。いまの生成AIは社内データベースの検索、メールの下書き、チケットの起票、外部APIの呼び出しまで担います。誤った出力がそのまま業務の動作になり得るため、モデルの外側に検査とルールの層を置く考え方が標準になりつつあります。
定義：モデルの外側に置く「安全柵」
AIガードレールはモデル自体を作り変えず、モデルの前後に検査とルールを挟んで振る舞いの範囲を制限する外付けの層です。
道路のガードレールが車の性能を変えずに転落だけを防ぐのと同じで、AIガードレールもLLMの能力はそのまま使い、逸脱だけを止めます。モデル提供企業が学習段階で行う安全性対策（RLHFなど）とは役割が異なります。
| 観点 | モデル側の安全性学習 | AIガードレール |
|---|---|---|
| 実施者 | モデル提供企業（OpenAI、Anthropic、Googleなど） | 利用企業・導入担当のエンジニア |
| 対象 | 一般的な有害性（暴力、違法行為など） | 自社固有の業務ルール・権限・機密情報 |
| 変更のしやすさ | 利用者からは変更できない | 業務に合わせて随時更新できる |
| 典型例 | 危険な依頼への拒否応答 | 個人情報のマスキング、社外秘文書の出力禁止 |
現場の感覚でいうと、モデル側の安全性は「一般常識」、ガードレールは「この会社のルール」にあたります。後者は導入する側が設計しない限り存在しません。
なぜ今AIガードレールが必要なのか
LLMが業務システムやツール実行に接続されたことで、誤った出力がそのまま実害につながるようになりました。そのため、ガードレールは欠かせない層になっています。
OWASPが公開する「OWASP Top 10 for LLM Applications 2025」は、LLM01にプロンプトインジェクション、LLM02に機密情報の漏えい、LLM06に過剰な権限（Excessive Agency）、LLM09に誤情報を挙げています。どれも、モデルの賢さだけでは防げず、システム設計で対処すべきリスクです。
制度面でも、米国NISTが2023年1月に「AI Risk Management Framework（AI RMF 1.0）」を、2024年7月に生成AI向けプロファイル（NIST AI 600-1）を公開しました。日本では総務省と経済産業省が2024年4月に「AI事業者ガイドライン」を公表しています。AIのリスクを利用者側で管理する責任ははっきりしてきており、ガードレールはその具体的な実装手段の一つです。
AIガードレールにはどんな種類がある？
AIガードレールは、入力・出力・行動（ツール実行）・運用監視の4層に分けて設計すると漏れを防ぎやすくなります。
どこか一か所で全部を止めようとすると、検査が重くなるか、抜け穴が残ります。層ごとに役割を分けておくのが実務上の定石です。
層別の4分類
入力ではユーザーの依頼を、出力ではAIの回答を、行動ではAIが実行する操作を、運用では全体の傾向をそれぞれ検査します。
| 層 | 何を検査するか | 代表的な対策 |
|---|---|---|
| 入力ガードレール | ユーザーの依頼、取り込む文書・Webページ | プロンプトインジェクション検知、話題の範囲制限、個人情報の除去 |
| 出力ガードレール | LLMが生成した回答 | 有害表現フィルタ、機密情報の検出、根拠のない断定の検出、出力形式（JSONスキーマ）の検証 |
| 行動ガードレール | ツール呼び出し・API実行 | 権限の最小化、実行前の人間承認（HITL）、金額・件数の上限設定 |
| 運用ガードレール | ログ全体、利用傾向 | 監査ログ、ブロック率の監視、インシデント時の停止手順 |
FDEの現場で見落とされやすいのは行動ガードレールです。回答の文面には気を配っていても、「AIが実行できる操作の範囲」が担当者の想定より広いままになっていることがあります。
代表的なツール・サービス
ガードレールは自作もできますが、オープンソースのフレームワークやクラウドのマネージドサービスを組み合わせるのが一般的です。
| 名称 | 提供元 | 形態 | 特徴 |
|---|---|---|---|
| NeMo Guardrails | NVIDIA | オープンソース | Colangという記述言語で会話の流れと禁止事項を定義できる |
| Guardrails AI | Guardrails AI | オープンソース | 出力の検証ルール（Validator）を組み合わせて使う |
| Llama Guard | Meta | 公開モデル | 入出力の安全性を分類する判定用LLM |
| Amazon Bedrock Guardrails | AWS | マネージド | 禁止トピック、単語フィルタ、機密情報フィルタをまとめて設定できる |
| Azure AI Content Safety | Microsoft | マネージド | 有害コンテンツ判定とPrompt Shields（インジェクション対策）を提供 |
どれを選ぶかは、顧客企業がすでに使っているクラウド、データを外部に出せるかどうか、日本語での判定精度によって変わります。日本語の判定精度は公開情報だけでは判断しにくいので、自社データで小さく検証してから採用を決めるのが無難です。
AIガードレールはどう実装する？
まずリスクを洗い出し、層ごとに検査を置きます。次に評価データで効果を測り、運用しながら更新していく順で進めます。
実装の6ステップ
ガードレールの実装は「何を止めるか」を決める段階が半分以上を占め、コードを書くのは後半の作業になります。
- ユースケースとリスクの棚卸し：利用者、扱うデータ、AIが実行できる操作を一覧にし、OWASP Top 10 for LLMなどを参照して想定リスクを洗い出す。
- 止める基準の合意：「絶対に出してはいけないもの」「人間の確認が必要なもの」「許容するもの」の3段階に分け、業務責任者と合意する。
- 層ごとの対策を配置：入力・出力・行動・運用の各層に、ルールベースの検査とモデル判定の検査を割り当てる。
- 評価データセットの作成：通すべき正常な依頼と止めるべき攻撃・逸脱の例を用意し、自動テストとして回せる形にする。
- 段階的なリリース：最初は検知してログに残すだけのモードで動かし、誤検知の傾向を確認してからブロックを有効にする。
- 運用と更新：ブロックされた事例と、すり抜けた事例を定期的に見直し、ルールと評価データを更新する。
5番目の「最初は記録だけ」の段階を飛ばすと、リリース当日に正当な業務まで止まり、現場の信頼を失いがちです。
ルールベースとモデル判定の使い分け
確実に止めたいものはルールベースで、文脈の判断が必要なものはモデル判定で検査し、両方を組み合わせます。
| 方式 | 向いている対象 | 長所 | 短所 |
|---|---|---|---|
| ルールベース（正規表現・辞書・スキーマ） | マイナンバー・カード番号の形式、出力形式、禁止語 | 速く、結果が予測でき、説明しやすい | 言い換えや文脈に弱い |
| モデル判定（分類モデル・判定用LLM） | 有害性、話題の逸脱、インジェクションの意図 | 文脈を理解できる | 遅延とコストが増え、判定がぶれる |
| 人間の承認（HITL） | 送金、外部送信、顧客への確定回答 | 責任の所在がはっきりする | 処理量が増えると回らなくなる |
効果をどう測るか
ガードレールの良し悪しは、止めるべきものを止めた割合と、通すべきものを誤って止めた割合の両方で評価します。
見るべき指標は主に3つです。危険な入出力を見逃した割合（偽陰性）、正当な依頼を誤ってブロックした割合（偽陽性）、検査によって増えた応答時間です。目標値は業務によって大きく変わるため、一律の基準はありません。金融取引に近い業務なら偽陰性の低さを優先し、社内の問い合わせ対応なら偽陽性の低さを優先する、というように、業務責任者と優先順位を決めておく必要があります。
FDEはAIガードレールにどう関わる？
FDEは顧客の現場で業務ルールを読み解き、「どこで何を止めるか」をガードレールとして実装し、運用まで支える役割を担います。
FDE（Forward Deployed Engineer）は、Palantirが顧客の現場にエンジニアを送り込む職種として広めた働き方です。製品を渡して終わりにせず、顧客の業務に入り込んで実装まで担います。生成AIの導入では、この「現場に入る」性質がガードレール設計と特に相性が良いといえます。
業務ルールをガードレールに翻訳する
ガードレールの中身は顧客ごとの業務ルールそのものです。現場で暗黙のルールを聞き出し、検査条件に落とし込む作業がFDEの中心的な仕事になります。
たとえば「この取引先の情報は営業部以外に見せない」「見積金額は課長承認なしに外部へ出さない」といったルールは、規程集に書かれていないことも多くあります。FDEは現場担当者へのヒアリングや業務の観察を通じてこうした暗黙のルールを見つけ、権限設定・出力フィルタ・承認フローに変換します。本社のプロダクトチームからは見えにくい部分であり、FDEが現場にいる価値が最も出やすい領域だと考えています。
意思決定者との合意形成
「どこまで止めるか」はリスク許容度の判断なので、FDEが技術的な選択肢を示し、顧客の意思決定者が決める形が健全です。
FDEがガードレールの厳しさを独断で決めてしまうと、事故が起きたときの責任の所在があいまいになります。前述の3段階（禁止・要承認・許容）の表を叩き台にして、業務責任者・情報システム部門・法務と合意し、合意内容を記録に残しておくことをおすすめします。
FDEに求められるスキル
ガードレール実装には、LLMの技術知識に加えて、セキュリティの基礎、評価設計、業務理解を横断する力が求められます。
| スキル領域 | 具体的な内容 |
|---|---|
| LLMアプリ開発 | RAG、ツール呼び出し、出力のスキーマ検証 |
| セキュリティ基礎 | 最小権限、認証認可、プロンプトインジェクションの手口の理解 |
| 評価設計 | テストケースの作成、偽陽性・偽陰性の計測 |
| 業務理解・対話 | 暗黙のルールの聞き出し、リスク許容度の言語化 |
| ガバナンス知識 | NIST AI RMF、AI事業者ガイドラインなどの枠組みの理解 |
FDEを目指すエンジニアにとって、ガードレールは「技術と業務の両方がわかる」ことを示しやすいテーマです。ポートフォリオで扱う題材としても有力です。
AIガードレール導入でよくある失敗は？
失敗の多くは技術力の不足ではなく、止めすぎ・止めなさすぎの調整が誰にも任されていないことと、導入後に更新が止まることから起きます。
止めすぎて使われなくなる
検査を厳しくしすぎると、正当な業務までブロックされます。利用者がAIを避けて個人契約の外部サービスに流れると、かえってリスクが高まります。
ブロックされたときに「なぜ止まったか」「どうすれば通るか」が利用者に伝わらないと、不満は一気に増えます。ブロック時のメッセージと、確認や例外を申請できる窓口を最初から用意しておくのが効果的です。
システムプロンプトだけで守ろうとする
「機密情報を出力しないでください」とシステムプロンプトに書くだけでは、プロンプトインジェクションで簡単に破られます。防御はシステムの外側に置く必要があります。
OWASP Top 10 for LLM Applications 2025でも、システムプロンプトの漏えい（LLM07）が独立した項目になっています。システムプロンプトは秘密にも防壁にもならない、という前提で設計するのが安全です。権限の制御はLLMではなく、アプリケーション側の認可の仕組みで行います。
導入後に放置する
攻撃の手口も業務ルールも変わり続けるため、ガードレールは一度作れば終わりではなく、継続的に更新する運用の仕組みとして扱う必要があります。
| 失敗パターン | 起きること | 対策 |
|---|---|---|
| 止めすぎ | 利用率が下がり、外部サービスに流れる | 記録のみモードで誤検知を確認してからブロックする |
| プロンプト頼み | インジェクションで突破される | 権限制御と出力検査をアプリケーション側に実装する |
| 行動層の見落とし | AIが想定外の操作を実行する | 最小権限と、重要操作での人間承認を設ける |
| 導入後の放置 | 新しい手口や業務変更に追いつけない | 定期レビューと評価データの更新を運用に組み込む |
| 責任者が不在 | 誤検知の判断が滞る | 業務側にガードレールのオーナーを置く |
FDEが顧客のもとを離れたあとも回り続ける運用体制を作れるかどうかが、ガードレール導入が成功したかを分けるポイントだと考えています。
主な参考資料
- OWASP「OWASP Top 10 for LLM Applications 2025」
- NIST「AI Risk Management Framework（AI RMF 1.0）」2023年1月
- NIST「AI 600-1: Generative Artificial Intelligence Profile」2024年7月
- 総務省・経済産業省「AI事業者ガイドライン（第1.0版）」2024年4月
- NVIDIA NeMo Guardrails、Guardrails AI、Meta Llama Guard、Amazon Bedrock Guardrails、Azure AI Content Safety 各公式ドキュメント
