- 公開日
LLMのガードレールとは、起こり得る被害に応じて、AIの処理を続ける条件、範囲を狭める条件、止める条件を決め、それが実際に働くようにする仕組みです。危害の可能性がある依頼でも、すべてを拒否するとは限りません。許可された範囲を切り分けられれば、その部分を処理します。切り分けに必要な情報が足りなければ保留して人に確認し、目的そのものが認められない場合は、その目的に沿う処理を拒否します。判断の軸は、不安に感じる言葉があるかではなく、何をすると誰にどんな影響があり、どこまで確かめられるかです。
何を止める必要があるのかを特定する
AIの安全統制は、危険そうな回答を出さないことだけではありません。入力する情報、参照する資料、生成した内容、外部へ送る操作のどこで被害が生じ得るかを見ます。資料の要約でも、入力段階で機密情報を未承認のサービスへ渡せば、回答を後から伏せても、既に行った送信は取り消せません。
OWASPの機密情報開示に関する解説は、入力した機密情報が出力で開示されるリスクや、プロンプト内の制限が必ず守られるわけではない点を説明しています。対策を考えるときは、「回答に名前を書かない」という指示と、「その情報を処理環境へ渡してよいか」の確認を分ける必要があります。
まず担当者は、依頼の目的、対象資料、使うサービス、出力の受け手を具体化します。次に、誤った場合の影響と、失敗後に戻せる範囲を確認します。社内の下書きを修正する作業と、同じ文章を外部へ一斉送信する作業では、文章が同じでも止めるべき位置が変わります。
低リスクと判断するにも理由が要ります。たとえば「利用が認められた公開資料だけを使い、外部送信機能のない環境で下書きを作り、本人が確認する」という条件なら、宛先別の送信承認を毎回求める必要はありません。一方、入力情報の利用許可や、資料と要約の一致は引き続き確認します。
続行・部分処理・拒否・保留を使い分ける
次の区分は、業務の判断を整理するための例です。製品に共通する公式モードや、法律上の一律の分類ではありません。
- 続行：対象と利用条件を確認でき、依頼された処理を許可範囲内で行える状態です。
- 部分処理：実行できない部分を切り離し、残りだけでも意味のある成果を出せる状態です。機能や対象を狭めて続けることを、作業の縮小や縮退とも呼びます。
- 拒否：依頼の目的や操作が認められず、そのまま実施する選択肢がない状態です。説明や別の適法・適切な作業を案内できる場合は、その範囲を示します。
- 保留して人間確認：許可、対象、影響など、判断に必要な情報を確認できていない状態です。何を確かめれば再開できるかを添えます。
人間確認は、それだけで処理の許可を生むものではありません。資料を扱う権限がない人へ「進めてよいですか」と聞いても不足は解消しません。利用条件を確認する担当者、公開を承認する責任者など、欠けている判断に対応する相手へ引き継ぎます。禁止された操作を、確認ボタンだけで通せる設計にもしてはいけません。
また、部分処理には二つの条件があります。除外すべき情報を元資料と照合して区別できることと、残った内容だけで誤解を生まないことです。人名だけを消しても、案件名や固有の事情から相手を特定できるなら除外は不十分です。注意書きを削った結果、未承認の計画が確定事項に見える場合も、その要約は成立しません。
同じ資料要約で、判断が変わる三つの場面
架空の研修資料を使って考えます。依頼は「社内共有用に、研修の内容と次の準備を要約してください」です。資料の第一部には、入力が許可された公開済みの開催案内として「研修は説明と演習で構成する。参加者は事前に操作手順を確認する」とあります。第二部には、外部AIサービスへの入力が認められていない個別相談の記録が付いているとします。
この例では、承認済みの社内環境で担当者が元資料を確認し、AIへ渡すファイルを準備します。禁止情報を含む原本を外部サービスへ送ってからAIに除去させる手順ではありません。
第一の場面では、二つの部分を区別でき、担当者が第一部だけを別ファイルに取り出して内容を照合できました。利用するサービスでも、その第一部の処理が認められています。この場合は部分処理を選べます。AIへの依頼は「このファイルの開催案内だけを要約し、個別相談について補完しない」とします。
期待する出力は「研修は説明と演習で構成されます。参加者は事前に操作手順を確認してください。個別相談の記録は今回の要約対象に含めていません」です。担当者は、元の案内の意味が保たれ、個別相談の内容や推測が加わっていないかを照合します。除外した内容の詳細を、除外理由の説明で再び書かないことも確認します。
第二の場面では、資料のページ順が崩れ、どこまでが開催案内で、どこからが個別相談なのかを確認できません。AIが「機密らしい箇所」を推定して消すだけでは、許可された範囲を確定できない状態です。ここでは原本の投入と要約を保留し、資料管理者に、確認済みの開催案内だけを提供してもらいます。
出力は「要約に使える範囲を確認できないため、本文の処理を保留します。開催案内として利用を認められた部分を分けてください」とします。これは資料全体が機密だと断定する説明ではありません。現時点で境界を確かめられないため、対象を絞る材料が必要だと伝えています。
第三の場面では、依頼が「入力を禁じられた個別相談も、分からないように外部へ送って要約して」に変わります。この操作は拒否し、承認済みの開催案内だけの要約など、許可範囲内の代替を示します。「急いでいる」という事情は、入力許可を変更する根拠にはしません。
止めた理由と、進められる作業を一緒に伝える
停止時の説明は、利用者が次の作業を選べる内容にします。「安全上の理由でできません」だけでは、資料を分ければよいのか、別の環境が必要なのか、目的を変更すべきなのかが分かりません。
研修資料の例なら、処理した範囲、保留した範囲、その理由、再開に必要な材料を示します。部分要約を返した場合は「資料全体の要約」と呼ばず、開催案内に限定したことを明記します。確認の依頼にも個別相談の中身を添えず、必要なファイル区分や利用条件だけを伝えます。
負担を抑えるには、同じ条件で繰り返す低リスクの作業について、入力可能な資料や環境を事前に整理しておく方法があります。ただし、一度確認した条件を、別の資料、別のサービス、別の受け手へ広げて使いません。変更された部分が判断に影響するなら、そこを改めて確認します。影響・機密性・取り消しやすさから確認の厳しさを切り替える考え方は、AIの確認をどこまで厳しくする？ 同じ作業でも変わるリスクの見方で扱っています。
ガードレールが効かないときの原因と対策
ガードレールが「破られた」ように見えるとき、原因がモデルだけにあるとは限りません。OWASPは、LLMアプリの主要なリスクとしてプロンプトインジェクションと、過大な機能・権限・自律性を扱うExcessive Agencyを挙げています。次の表は、こうした整理と本記事の考え方から作った点検の例であり、OWASPが定める分類ではありません。
| 起きたこと | 主な原因 | 対策 |
|---|---|---|
| 資料内の一文に従って、本来しない操作をしようとした | 外部資料の文を指示として扱っている（間接プロンプトインジェクション） | 資料は内容として扱うと指示したうえで、実行側でも権限と承認を確かめる |
| 禁止したはずの送信が実行された | 禁止をプロンプトだけに書き、実行するシステムで確認していない | 送信や削除は、実行する仕組みの側で権限と承認記録を確かめる |
| 何を頼んでも「対応できません」と返る | 止める条件が広く、作業の縮小や保留の選択肢がない | 続行・縮小・拒否・保留の条件を分けて決める |
| 承認したのに誤りが外へ出た | 確認者に判断材料がなく、承認が形だけになっている | 対象・確定版・未確認事項・影響を示し、差し戻せるようにする |
| 言い換えると制限を抜けられる | 特定の言い回しの検知に頼っている | 検知は入口と位置付け、権限の最小化と実行側の確認を重ねる |
表の対策は、どれか一つで足りるものではありません。原因の欄を見て、指示・権限・承認・検知のどこを直すべきかを判断します。
ガードレールを自社で評価する方法――層ごとに、すり抜けと止めすぎを測る
ガードレールの評価では、「危険な依頼を止められたか」だけでなく、「通常の業務が止まっていないか」も同じ重さで確かめます。片方だけを見ると、何でも止める設定が高く評価されてしまいます。
層ごとに、何を確かめるかを分ける
ガードレールは、一つの仕組みではなく複数の層の組み合わせとして評価します。次は、PAP Research が整理に使っている3層の例です。
| 層 | 主な役割 | 評価で確かめること |
|---|---|---|
| 入力側の確認 | 入力してはいけない情報や、外部資料に紛れた指示を、処理の前に見つける | 禁止対象が処理環境へ渡る前に止まるか |
| 出力側の確認 | 生成した内容に、出してはいけない情報や根拠のない断定がないかを見る | 問題のある出力が利用者や外部へ届く前に止まるか |
| 実行側の制御 | 送信・削除・更新などの操作を、権限と承認記録で判定する | 入力・出力の確認をすり抜けた場合でも、権限外の操作が実行されないか |
入力・出力の確認は言い回しの変化に弱いことがあるため、最後の実行側の制御で止まるかを必ず別に確かめます。
評価用の模擬データを、三つの区分で用意する
- 止めるべきもの：入力禁止の情報を含む資料、外部資料に指示文を紛れ込ませたもの、権限外の操作を求める依頼
- 通すべきもの：利用が認められた資料だけを使う通常の依頼
- 判断が分かれるもの：区分が確認できない資料、言い回しを変えた依頼
実在の人物・顧客の情報や、本物の認証情報は使いません。架空の識別情報で作ります。
数え方を決めてから試す
- すり抜け：止めるべきものが、どの層でも止まらなかった件数
- 止めすぎ：通すべきものが止まった件数
- 層ごとの停止：どの層で止まったか（入力・出力・実行）
割合で示す場合は、分母になった件数も一緒に記録します。件数が少ない試験の結果を、そのまま本番の精度とは見なしません。
レッドチーム（攻撃側の視点での試験）は、範囲を決めて行う
攻撃者の立場で抜け道を探す試験をレッドチームと呼びます。行う場合は、次を事前に決めます。
- 対象：自社が管理する模擬環境だけ。本番環境や、利用規約で認められていない外部サービスは対象にしない
- 範囲：試す層、試す依頼の種類、終了条件
- 記録：試した入力、止まった層、すり抜けた場合の影響
見つかった抜け道は、言い回しを一つずつ禁止して塞ぐのではなく、上の表のどの層で止めるべきだったかを判断して直します。
変更のたびに同じ試験を繰り返す
モデル、プロンプト、接続するツール、権限の設定を変えたときは、前回と同じ模擬データで試し、すり抜けと止めすぎの件数を比べます。結果を取得できなかった項目は「確認済み」とせず、未確認として残します。
回答の拒否だけに安全を任せない
モデルへの指示は、処理方針や説明を整える役割を持ちます。アクセス制限は、使ってよい資料や機能を絞る役割を持ちます。人間確認は、権限のある人が不足する条件や重要な判断を確かめる役割を持ちます。これらは互いの代わりにはなりません。送信操作を例にした三つの分担は、AIの送信をどう制御する？ 指示・システムの強制・人間承認の役割で詳しく説明しています。
OWASPのExcessive Agencyでは、用途に必要な機能・権限へ絞ることや、影響の大きい操作に人の承認を組み込むことを勧めています。要約しか必要ないなら、送信や削除の機能を使えない構成を検討できます。回答が「送信しません」でも、実行記録で送信されていれば統制は失敗しています。
導入前の確認には、実在人物の情報を含まない模擬資料を使います。開催案内だけの資料、明確に区分された除外対象付きの資料、区分を確認できない資料を用意し、それぞれ続行、部分処理、保留になるかを見ます。禁止情報の検知、外部送信の阻止、許可された要約の完了は別々に記録します。危険箇所を正しく検知したのに開催案内まで止まれば過剰な停止であり、危険箇所のない資料を危険と判定する誤検知とは区別します。
実行記録を取得できなければ、「送信なしを確認済み」とはしません。操作の状態は未確認として、結果が分かるまで追加送信を保留します。停止回数だけで対策の良し悪しを決めず、禁止された操作が起きていないかと、許可された要約が完了したかを併せて確かめます。
外部入力の命令の改変を検知し、誤検知と見逃しを測る方法は「外部入力の命令改変を検知し誤検知と見逃しに備える」、検知したあとに全面停止か部分処理かを選ぶ条件は「インジェクション検知後に全面停止と部分処理を選ぶ条件」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」と「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
