AIガードレールの作り方｜入力・出力・ツール操作を多層で制御する

AIガードレールとは、モデルへ禁止事項を指示する文章ではなく、入力受付から外部操作までの各境界で、許可・拒否・保留・人の承認を実行する統制の組み合わせです。 顧客サポートAIが注文検索と返金申請を扱う想定で、守る対象、権限、検査位置、停止時の挙動、例外申請、誤検知の測り方を具体化します。成果物は、開発・法務・セキュリティが同じ条件で確認できるガードレール判定表です。

ガードレールを置く範囲は入力・文脈・出力・操作の四つ

本稿の対象は、利用者が問い合わせを入力し、AIがFAQと注文情報を参照し、必要に応じて返金ツールを提案するアプリです。守る対象は、顧客の個人情報、注文の完全性、返金権限、回答の適法性、サービス可用性です。「不適切な回答を出さない」だけでは、権限外の注文閲覧や二重返金を防げません。

OWASP GenAI Security Projectの公式セキュリティ資料「Top 10 for LLM Applications 2025」のLLM06は、「Excessive Agency」を扱います。過剰な機能、権限、自律性によって、意図しない有害な操作が可能になるリスクです^[2]。この指摘から導けるのは、モデルの賢さではなく、ツールが実際に許された機能と権限だけを提供しているかを確認すべきだということです。

拒否文を上手に生成する機能と、危険な操作を実行不能にする制御は別物です。金銭・送信・削除に関する最終認可は、モデル出力ではなくアプリケーション側で行います。

適用要件を業務影響と取り消し可能性から決める

すべての会話へ同じ検査を重ねると、遅延と誤検知が増えます。まず操作を「参照のみ」「下書き」「可逆な更新」「取消困難な実行」に分けます。FAQ回答と5万円の返金を同じ自動化水準で扱いません。影響額、対象者数、個人情報、外部公開、取り消し可能性、検出可能性を採点し、必要な統制を割り当てます。

NIST AI 600-1は生成AIリスクを12類型に整理し、Govern、Map、Measure、Manageへ対応する200超の行動を示しています^[3]。ガードレール表を一度作って終わらせず、用途、対象データ、影響をMapし、拒否率とすり抜けをMeasureし、変更や事故に応じてManageする運用へつなげます。

認証から実行後検査まで七層を独立させる

1. 認証とセッション

会社アカウント、MFA、セッション有効期限をID基盤で扱います。会話中に利用者が名乗った部署や役職を権限根拠にしません。高影響操作の直前には再認証を要求し、長時間会話による古い権限を引き継がないようにします。

2. 入力の決定的検査

ファイル種別、容量、文字数、マルウェア、秘密鍵形式、顧客番号の大量列挙をモデルより前で検査します。正規表現だけで完全な機微情報検知はできないため、検知したら自動削除して続行するのではなく、利用者へ除去箇所を示して再提出させます。誤って業務上必要な値を消すリスクがあるためです。

3. 文脈の信頼境界

利用者の指示、システム方針、検索文書、ツール結果を別フィールドで管理します。Webページや添付資料の「前の指示を無視せよ」はデータとして扱い、命令へ昇格させません。OWASPのLLM01:2025は直接・間接のPrompt Injectionを主要リスクに挙げています^[1]。完全な検知を前提にせず、外部文書を読んだ後も権限が増えない構成にします。

4. モデルへの方針

回答可能範囲、保留条件、引用形式をシステム指示へ書きます。ただし、指示は統制の一層にすぎません。モデルが方針に反する出力を返しても、後段の検査と認可で被害を止められる必要があります。プロンプト版とモデル版をトレースへ残します。

5. 出力の型・値・根拠検査

構造化出力ではJSONスキーマに加え、金額が0以上、通貨が注文と一致、注文IDが利用者の権限内、引用箇所が原文に存在、といった値の検証を行います。検査不合格は画面へ流さず、原因を分類します。再生成は最大1回など上限を設け、同じ不合格を繰り返したら人へ渡します。

6. ツールのサーバー側認可

ツールには広い管理APIを渡さず、request_refund(order_id, amount, reason_code)のように業務単位で狭くします。実行時に利用者、注文、金額、理由、回数制限を再検証します。モデルが作った「承認済み=true」は信頼しません。取消可能な操作にも冪等キーと状態照会を付けます。

7. 実行後の整合性確認

外部サービスの受理ID、確定金額、対象注文を期待値と照合します。HTTPタイムアウトは未実行を意味しないため、再送前に状態を確認します。結果が不明なら利用者へ「失敗」と断定せず、処理保留として運用担当へ通知します。

フレームワーク固有の実行順序を仕様で確認する

ガードレールという同じ名称でも、実行時点と対象は製品ごとに違います。OpenAI Agents SDKのオンライン文書では、エージェントの入力ガードレールは連鎖の最初、出力ガードレールは最終出力を作るエージェントで動き、カスタム関数ツールには実行前後のtool guardrailを付けられると説明されています^[4]。さらに、入力検査の既定は並列実行で、検査が終わる前にモデルがトークンを消費したりツールを実行したりする可能性があります。

副作用を絶対に起こしたくない入口検査では、同SDKならblocking実行を選ぶ必要があります。並列実行は遅延を抑えたい低影響の分類に向きます。また、同文書はtool guardrailがカスタム関数ツールを対象とし、Hosted toolや組み込み実行ツールには同じパイプラインが適用されない制約も示しています。採用するSDKで「どのツールが検査対象か」を一覧にし、名称だけで安全と判断しません。

判定不能時に閉じる場所と開いたままにする場所を分ける

すべてをfail closedにすると、照会系まで停止して業務継続を損ないます。すべてをfail openにすると、検査サービス障害がそのまま越権へつながります。処理の影響に応じて、判定不能時の動作を事前に決めます。

代替経路へ切り替えるときも、元より広い権限を与えません。高性能モデルが停止したからといって、検査を省いた別モデルへ送るのは代替ではなく統制の削除です。フォールバックごとにデータ送信先、保持条件、出力品質、ツール権限を審査します。

誤検知と業務例外を期限付きで管理する

医療用語、脆弱性報告、法務相談などは、一般的な有害表現フィルターで止まりやすい領域です。利用者が回避表現を覚える運用にせず、業務目的、対象データ、利用者グループ、追加確認、終了日を付けた例外を発行します。例外は特定の検査を無効化するのではなく、専用経路へ振り分ける設計が安全です。

例外ID: GR-2026-014
対象: セキュリティ部の脆弱性報告要約
許可する入力: 攻撃手順を含む社内チケット
許可しない操作: 外部送信、コード実行、資格情報参照
追加統制: 担当者承認、隔離索引、原文7日削除
有効期限: 2026-09-30
所有者: CISO配下の製品セキュリティ責任者
再審査条件: 対象モデル、索引、ツールの変更

この記録は架空例です。期限なし例外、全社員対象、理由が「業務上必要」だけの申請は承認しません。失効前に利用件数、誤検知、すり抜け、手作業時間を確認し、通常ルールの改善で吸収できるかを判断します。例外経路の利用が0件なら延長せず閉じます。

攻撃成功率と正常業務の通過率を同じ試験で測る

拒否できた攻撃例だけを集めると、通常業務を止めるガードレールになります。試験集合を正常50件、境界30件、攻撃20件の計100件とし、各ケースに期待動作を付けます。件数は想定例で、実際の利用分布と重大シナリオへ合わせます。

上の数値は実測ではありません。攻撃ケースには、直接指示、添付文書内の間接指示、Unicodeや長文による回避、権限外ID、金額の境界値、タイムアウト後の再試行を含めます。正常ケースには、否定表現、専門語、長い顧客履歴、複数言語を入れます。モデルまたはルールを変えたら同じ100件を回帰実行します。

合格基準は総合率だけでなく、重大ケースの許容件数を0件とします。たとえば攻撃阻止率99%でも、その1%がアカウント停止や返金なら受け入れられません。逆に、低影響FAQの曖昧質問を人へ回した事象は、改善対象ではあっても直ちにサービス停止とは限りません。

所有者・変更審査・監視を運用へ落とし込む

統制ごとに所有者を置きます。入力分類はプロダクト、認証認可はID管理、個人情報はプライバシー、攻撃試験はセキュリティ、業務ルールは顧客サポート責任者が判断します。AI推進部署が全領域を承認する体制では、専門判断が形式化します。

週次では拒否件数、保留理由、誤検知、すり抜け、検査遅延を確認し、月次ではルール版と例外台帳を照合します。事故時にはモデル出力だけでなく、どの層を通過したかをトレースから特定します。ガードレール停止中に危険操作を続ける設計は認めません。

脅威シナリオを資産・攻撃経路・被害で記述する

「プロンプトインジェクション対策」のような名詞だけでは試験条件を作れません。誰が、どの入口から、何を操作し、どの資産へ影響するかを一文で書きます。顧客サポートAIでは、悪意ある顧客だけでなく、侵害されたFAQ、誤設定した運用者、権限を持つ内部者も想定します。

各シナリオへ発生可能性の数字を無理に付けず、到達可能性、必要権限、検出しやすさ、最大影響を段階評価します。根拠のない「発生率10%」より、攻撃者が公開画面だけで試せるのか、社内資格情報が必要なのかを明記する方が設計に役立ちます。

防御は少なくとも二種類を割り当てます。モデル判定とモデル判定の二重化は同じ弱点を共有し得るため、認可、型検査、上限、冪等性など決定的な統制を組み合わせます。対策後には通常業務ケースも実行し、守りを強めた結果として正当な返金を処理不能にしていないかを確認します。

競合するルールの優先順位と判定理由を機械可読にする

社内規程、顧客契約、法令、製品設定、個別例外が競合すると、モデルへ長い文章を渡すだけでは一貫した判定になりません。拒否、保留、承認必須、自動許可の順序を定め、決定的に評価できる条件はポリシーエンジンまたはアプリコードへ置きます。

decision: manual_approval
reason_code: REFUND_AMOUNT_OVER_AUTO_LIMIT
policy_version: support-refund@12
facts:
  authenticated: true
  owns_order: true
  requested_amount_jpy: 18000
  automatic_limit_jpy: 10000
  prior_refund_count_30d: 0
required_role: refund_supervisor
expires_at: 2026-07-30T09:30:00Z

このYAMLは架空の判定記録です。モデルへ返金可否を自由記述させず、モデルは理由コードの候補と根拠文を作り、最終決定は認証済み事実と版管理した規則で行います。判定不能な値、たとえば注文通貨が欠ける場合は0円として通すのではなく、missing_factで保留します。

優先順位の例は、法的・契約上の禁止、セキュリティ上の拒否、本人・権限確認、金額上限、期限付き例外、通常許可です。ただし法的判断を一般化せず、適用する規程と契約を法務が確定します。ルール変更では、旧版の代表100件を新版へ通し、決定が変わった全件へ意図した理由があるかを業務責任者が確認します。

利用者向けメッセージと内部理由も分けます。外部には「担当者の確認が必要です」と示し、権限構造や不正検知ルールの詳細を漏らしません。内部ログにはreason_code、入力事実の出所、規則版、承認者を残し、後から同じ条件で再判定できるようにします。

承認画面で対象・差分・権限・期限を同時に確認させる

「承認」ボタンだけの画面では、担当者がAIの文章を追認しがちです。返金なら、顧客、注文、申請額、自動上限、根拠規程、AIが生成した理由、元入力との差分、過去の返金、検査結果を一画面に置きます。機微情報は役割ごとにマスキングし、承認者が不要な顧客情報を見ないようにします。

承認には有効期限を設けます。承認後に注文状態、金額、規程版が変わった場合は承認を無効にし、再確認を要求します。承認者の職務権限も実行時に再評価し、画面を開いた時点の権限を長時間保持しません。

拒否理由は、入力不足、規程外、権限不足、不正疑い、技術エラーへ分類します。AI改善に使えるのは入力不足や候補理由の誤りであり、権限不足を学習例へ入れて「通しやすくする」べきではありません。監査記録には承認前後の値、担当者、時刻、理由を残します。

すり抜け・誤検知・停止時間を版ごとに監視する

運用指標は拒否件数だけでは足りません。攻撃または禁止操作を通したすり抜け、正当な処理を止めた誤検知、正しく人へ回した保留、ガードレール障害による停止時間をルール版・モデル版・経路で集計します。利用者数の増減を考慮し、件数と率を併記します。

架空の週次例として、正常要求4,800件のうち誤検知96件なら誤検知率は96÷4,800×100=2.0%です。攻撃試行40件のうち1件がツール呼び出しまで進めば阻止率は97.5%ですが、返金ツールなら重大失敗として当該版を停止します。平均点で相殺しません。

変更は5%の利用者から始め、旧版と同じケースを並行評価します。誤検知率が旧版より1ポイント超悪化、p95検査遅延が300ms超、または重大すり抜け1件で旧版へ戻す、という基準は本稿の提案例です。切り戻し時はポリシー、モデル、例外台帳、承認画面の表示版を一組で戻します。

ガードレールを無効化した時間帯は、対象要求を後から抽出できるようにします。緊急バイパスを使うなら、限定利用者、限定機能、開始・終了時刻、承認者を必須にし、外部操作は停止したままにします。恒久対応後は、その障害を回帰ケースへ追加します。

重大なすり抜けは操作停止・証拠保全・再審査の順で扱う

本番ですり抜けを見つけたとき、最初にプロンプトを直すと、影響範囲と原因を後から確認できなくなります。返金やアカウント停止のような副作用を伴う経路だけを停止し、公開FAQなど影響の小さい読み取り経路は別判断にします。停止時刻、対象ルール版、モデル版、検出者、停止したツールを事故記録へ残し、同じ版が別環境で動いていないかを検索します。

影響調査では、攻撃文面だけでなく、認証済み利用者、参照した注文、取得文書、ツール引数、実行結果を同じ相関IDでたどります。ただし不要な個人情報を新たに複製せず、閲覧者と保全期間を事故対応規程に合わせます。モデルが出した説明は証拠の一部にすぎず、実際の認可判定と外部サービスの確定状態を優先します。

社内外への通知は、ガードレールが反応したという事実だけで一斉送信しません。対象データ、外部操作の確定状態、影響した顧客、契約上の連絡期限をそろえ、事故責任者が通知先と内容を決めます。調査中の推測と確認済み事実を分け、後から訂正が必要になった場合も同じ事故IDで履歴をつなぎます。

入力やログへAPIキー、セッショントークン、共有URLが混入した場合は、閲覧履歴の確認を待たず資格情報を失効します。新しい資格情報は事故調査用の文書へ記載せず、秘密管理基盤から対象ワークロードへ再発行します。漏えいした値を伏せた回帰ケースを作り、入力境界とログ保存の両方で再発しないことを確かめます。

復旧条件は「修正版を入れた」ではありません。原因となった一件、同じ境界を狙う変形20件、正常な返金20件を隔離環境で実行し、重大すり抜け0件、正常処理の不当拒否0件、監査項目欠落0件を確認します。この件数は架空の開始例です。影響の大きい経路ではケースを増やし、セキュリティ責任者と業務所有者が別々に結果を承認します。

すでに処理された案件は、規程版と承認記録を使って再審査します。誤返金の取消可否や顧客連絡はモデルへ決めさせず、決済・法務・顧客対応の既存手順へ渡します。再公開後24時間は対象経路の全件を人が確認し、警戒期間終了の時刻と判断者を記録します。

ガードレールが向かない使い方と公開を止める条件

ガードレールを追加すれば、汎用モデルへ医療診断、法的最終判断、人事処分、無制限の送金を任せられるわけではありません。誤りを後から検出しにくく、取り消せず、個人へ重大な影響がある用途では、AIを資料整理や下書きに限定する方が合理的です。安全策の性能を検証できない言語や入力形式も、自動実行の対象外にします。

次の事象では限定公開を止めます。権限外データが1件でも表示された、承認前に副作用が発生した、監査ログが欠落した、重大攻撃ケースが回帰試験を通過した、または例外設定が期限後も有効だった場合です。低影響の誤検知増加は全面停止ではなく、対象経路を手動へ切り替えて修正します。

導入時の読後行動は、顧客サポートの五処理を前掲の判定表へ書き、各境界の所有者と失敗時動作を承認することです。統制を一度に全社展開せず、公開FAQと注文照会で100件試験を終えてから、返金案、最後に返金実行へ進めます。

次に取る行動：返金申請の一経路で判定表を通す

返金申請のうち、注文参照、返金可否の提案、承認依頼までを一経路として選びます。正常10件、権限外5件、入力改変5件、判定不能5件を通し、許可・拒否・保留・人への引継ぎが設計どおりか確認してください。誤った許可が一件でも出た場合は、モデルへの注意書きではなく、ツール権限と実行前検査を修正します。

参考文献・出典

1. OWASP GenAI Security Project「LLM01:2025 Prompt Injection」（OWASP Top 10 for LLM Applications 2025、2026年7月30日参照）
2. OWASP GenAI Security Project「LLM06:2025 Excessive Agency」（OWASP Top 10 for LLM Applications 2025、2026年7月30日参照）
3. NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（NIST AI 600-1、2024年7月26日）
4. OpenAI「OpenAI Agents SDK: Guardrails」（オンライン版、2026年7月30日確認）

参照日はすべて2026年7月30日です。オンライン仕様は公開直前にも変更履歴を確認してください。