StrategyCore
リソース一覧へ
32/AI・機械学習 約9分

生成AIのガードレール:入口と出口で何を止めるか

不正なプロンプトをどこで止めるのか。社外秘が回答に混ざったときに何が起きるのか。セキュリティ部門が必ず問う二点について、提案を評価するための基準を整理します。

生成AIの検討が機能評価を通過すると、次はセキュリティ部門との議論になります。ここで問われるのは回答精度ではありません。悪意ある入力を受けたときの挙動と、機密情報が回答に混入したときの挙動です。日本企業ではこの論点が初回の技術会議から出ることも珍しくなく、質問者はCISO配下の部門であることが多くなります。本稿では、入口と出口それぞれで何が動いているべきかを六つの観点で整理し、提案書を読み解く基準としてご提示します。

検査が置かれる場所

SC-BD-06 · REV A · 2026.07

アプリケーションの信頼境界
要求の経路

入力側ガードレール

注入検知 · ポリシー

モデル

システムプロンプト

出力側ガードレール

個人情報 · 認証情報 · 権利処理

操作の経路

ツール実行層

権限判定はここ

プロンプトと取得文書が流入
機密は外に出さない
呼び出し元の権限で判定
信頼できない入力

利用者のプロンプト

直接入力

取得した文書

文書 · メール · 問い合わせ

入口の検査は突破される前提で設計する

境界図。アプリケーションの信頼境界の内側に、入力側ガードレール、モデル、出力側ガードレール、そして権限判定を持つツール実行層が並ぶ。外部からは利用者のプロンプトと検索で取得した文書が流入し、機密の流出は遮断され、ツール呼び出しは呼び出し元の権限に照らして検査される。
01

検査は二か所、失敗の仕方も二通り

ガードレールとは、モデルの外側で入力テキストと出力テキストを検査する仕組みです。入口側は、本来は命令ではないはずの文章が命令として解釈されることを防ぎます。出口側は、外に出てはいけない内容が回答に混ざることを防ぎます。この二つは失敗の仕方が異なり、担当も分けるべきものです。入口の対策だけを説明する提案は、出口が未検討である可能性が高いとお考えください。構成図に両方が描かれているかを最初に確認する。それだけで判別できます。

02

入口側:データのふりをして届く命令

プロンプトインジェクションは、アプリケーションがデータとして扱った文章の中に命令が紛れ込む攻撃です。検索で取得した文書、メール本文、問い合わせチケット、ファイル名。モデルはこれらを一続きのテキストとして読むため、PDFに書かれた「これまでの指示を無視せよ」の一文が、システムプロンプトと同じ重みを持ちます。ジェイルブレイクは、利用者が直接それを行う狭い事例です。分類器による検査は典型的な攻撃を捕捉しますが、言い換えられた攻撃は通します。したがって入口の検査は層のひとつであって、解決策ではありません。突破されても被害が限定される設計になっているかを確認してください。

03

出口側:回答に出てはいけないもの

出口側の検査は、そのまま送出すれば情報漏えいになる内容を探します。閲覧権限のない記録から引き出された個人情報。ログに残っていた認証情報。ライセンス管理下の文書の原文引用。日本では個人情報保護法が対象範囲を定めていますから、検査がどこで動き、検知したときに何をするのかを提案書に書かせてください。マスキングか、拒否か、人への引き継ぎか。最も避けるべきは無言の失敗です。利用者は言い換えて再試行し、いずれ通る表現を見つけてしまいます。

04

文章の境界と、操作の境界は別物

モデルが外部ツールを呼び出せる構成では、守るべき境界がもう一つ増えます。誤った文書を読むのは情報漏えいですが、誤った書き込みを実行するのは事故です。権限判定はプロンプトの中ではなく、呼び出しを実行する層に置いてください。そうしておけば、注入された命令が自分自身に権限を与えることはできません。通常のアクセス制御を一段下の層に適用しているだけの話であり、設計されていれば審査担当者はすぐ理解します。無ければ、権限判断をモデルの判断に委ねた構成だと読まれます。

05

誤検知率も同じ画面に出させる

分かりやすい指標は違反率、つまり通してはいけないものが通った割合です。しかしこの一点だけを追うと、検査は際限なく厳しくなり、製品としての実用性が失われます。もう一つの指標が、正当な要求を誤って拒否した割合です。試験導入の段階から、この二つを並べて報告させてください。違反率をゼロにする代わりに正当な質問の二割を拒否している仕組みは、単一指標のダッシュボードでは決して見えません。利用者は、測定より先に気づきます。

06

全アプリケーションが継承する場所に置く

個別のアプリケーションに実装したガードレールは、そのアプリケーションしか守りません。アプリケーション群とモデルの間に共通の層を設けてそこに実装すれば、来期に誰かが相談なく作ったサービスにも同じ検査が効きます。この層は、モデルの振り分けや費用計上を置く場所と同一です。本サイトの別稿で扱っています。発注側にとっての実利は監査性にあります。確認すべき場所が一か所、抽出すべきログが一系統、審査で提示する設定が一つで済みます。

// 要点

押さえておきたいポイント

  • 入口と出口のガードレールは守る対象が異なります。片方だけを実装して他方も安全だと考える構成が、最も多い欠落です。
  • プロンプトインジェクションはデータとして扱った文章の中に届きます。検査が突破される前提で被害範囲を設計してください。
  • 出口で違反を検知したときの動作、すなわちマスキング・拒否・人への引き継ぎのいずれかを事前に決めます。無言の失敗は再試行を誘発します。
  • ツール実行の権限判定はプロンプトではなく実行層に置き、注入された命令が自ら権限を得られない構成にします。
  • 違反率と誤検知率を並べて評価します。安全側に振り切った検査は、指標に出ないまま実用性を壊します。
  • 共通ゲートウェイ層に置いたガードレールは全アプリケーションに継承され、監査対象を一か所に集約できます。

// よくあるご質問

よくあるご質問

Q1

生成AIのガードレールとは何ですか。

モデルの外側で、入力テキストと出力テキストを検査する仕組みでございます。入口側は、命令として意図されていない文章が命令として解釈されることを防ぎます。出口側は、個人情報、認証情報、ライセンス管理下の原文が回答に現れることを止めます。この二つは別々の仕組みであり、担当も分けるべきものでございます。

Q2

プロンプトインジェクションとは何ですか。フィルタで止められますか。

アプリケーションがデータとして扱った文章、たとえば検索で取得した文書、メール本文、ファイル名などの中に命令が紛れ込む攻撃でございます。分類器は典型的な攻撃を捕捉しますが、言い換えられた攻撃は通します。フィルタは層のひとつと捉え、突破される前提でモデルが到達できる範囲を絞ることが要点でございます。

Q3

生成AIの回答から個人情報が漏れるのを、どう防ぎますか。

送出の前に出口側の検査を通し、閲覧権限のない個人情報、認証情報、ライセンス管理下の原文引用を探します。個人情報保護法(APPI)が対象範囲を定めておりますので、違反を検知したときにマスキングするのか、拒否するのか、人へ引き継ぐのかを、あらかじめ決めておく必要がございます。

Q4

ツール実行の権限判定は、どこに置くべきですか。

プロンプトの中ではなく、呼び出しを実行する層に置いてください。モデルが操作できる構成では守るべき境界がもう一つ増えます。誤った文書を読むのは情報漏えいですが、誤った書き込みを実行するのは事故でございます。権限判定を外に置けば、注入された命令が自分自身に権限を与えることはできません。

Q5

ガードレールが機能しているかは、何で測りますか。

二つの数値を同じ画面に並べます。違反率は、通してはいけないものが通った割合でございます。誤検知率は、正当な要求を誤って拒否した割合でございます。違反率をゼロにする代わりに正当な質問の二割を拒否している仕組みは、単一指標のダッシュボードでは決して見えません。

最終更新:

この領域での導入をご検討ですか

技術評価、製品選定、概念実証の設計まで、日本語で具体的にご相談いただけます。まずはお気軽にお問い合わせくださいませ。