azure-recipe-user 
生成AI（ChatGPTや社内LLMなど）を業務で使う企業が増える一方で、「情報漏えいが怖い」「不適切な出力が出たら困る」「監査で説明できない」といった不安も一気に増えました。
ここでよく出てくる解決策が ガードレール（Guardrails）製品 です。クラウド型もオンプレ型もあり、プロンプトや出力にフィルタをかけたり、NGワード・PII（個人情報）検知をしたりできます。
ただし結論から言うと、ガードレール“だけ”では生成AIセキュリティは完成しません。
なぜなら、セキュリティ事故の多くは「技術」だけでなく「運用・ルール・責任分界（ガバナンス）」の欠落から起きるからです。
この記事では、初心者向けに「ガードレールでできること／できないこと」と「ガバナンスで埋めるべき穴」を整理します。
対象読者
- 生成AIを業務導入しようとしている情シス・開発・企画担当
- ガードレール製品を検討しているが、何が足りないのか曖昧な人
- 「とりあえずツール入れれば大丈夫？」と思っている人
そもそも「ガードレール」とは？
ガードレールはざっくり言うと、LLMへの入出力の前後に“安全装置”を挟む仕組みです。
代表的な機能例：
- 入力（プロンプト）検査
- 個人情報・機密情報の検知／マスク
- 禁止事項（社内ルール違反）のブロック
- Jailbreak（脱獄）やプロンプトインジェクションの検知
- 出力（レスポンス）検査
- 有害・不適切コンテンツの抑止
- 機密っぽい出力のマスク
- “それっぽい嘘”（ハルシネーション）の兆候検知（製品により差）
クラウド／オンプレどちらでも、「安全なAI利用」を支える重要パーツです。
それでも「ガードレールだけでは不十分」な理由
ここが本題です。ガードレールは強力ですが、守れる範囲はあくまで“入出力の一部”です。現実の事故はそれ以外のところで起きます。
1) “何が機密か”が決まっていないと、検知も運用も破綻する
ガードレールにPII検知があっても、
- どの情報を「機密」と扱うか
- どの業務なら入力してよいか
- どの用途なら“要レビュー”にするか
が決まっていないと、結局こうなります：
- 厳しすぎて業務が止まる（過検知）
- 緩すぎて事故が起きる（見逃し）
- 現場が勝手に回避する（シャドー化）
これは ガバナンス（判断基準の整備） が必要な領域です。
2) 監査・説明責任（ログ/証跡）は製品単体では足りないことが多い
事故が起きたときに問われるのは「止めたか」だけでなく、
- 誰が
- いつ
- 何を入力し（どこまでマスクされ）
- 何が出力され
- どんな判断でブロック/許可したか
という説明です。
このためにはログ設計、保管期間、閲覧権限、インシデント時の手順が必要になります。
3) 役割分担がないと、止められない／止めすぎる
ガードレールのブロック判断を誰が最終責任として持つのか。
- 情シス？
- セキュリティ？
- 業務部門？
- 法務？
- プロダクト責任者？
が曖昧だと、事故のたびに意思決定が止まります。
ここもガバナンスの範囲です。
ガードレールとガバナンスの関連性
ガバナンス（ポリシー / 役割 / 監査）
────────────────
ガードレール（入出力フィルタ）
────────────────
LLM / RAG / Agent
このように
- ガードレール＝技術的制御
- ガバナンス＝組織的制御
というレイヤー構造で説明すると理解されやすくなります。
じゃあ「ガバナンス」って具体的に何をするの？
初心者向けに、最低限の“型”を紹介します。ポイントは「分厚い規程を作る」ではなく、運用できる最小セットを作ることです。
ガバナンスの最小セット（まずここから）
- 利用ポリシー（短く）
- 入力してよい情報／ダメな情報
- OKな用途／NGな用途
- 外部公開する文章の扱い（要レビュー等）
- データ分類（ざっくりでいい）
- 公開可 / 社内限定 / 機密 / 個人情報 など
- 承認フロー
- 新しいAI利用（新ツール・新プロンプト・新連携）を始める時の窓口
- ログ・監査
- 何を記録し、誰が見て、いつまで持つか
- インシデント対応（Runbook）
- “誤って入力した” “不適切出力が出た” “顧客から指摘された” などの初動
ガードレールとガバナンスの関係（超重要）
- ガードレール：技術で「止める・マスクする・検知する」
- ガバナンス：運用で「決める・回す・説明する・改善する」
ガードレールは ガバナンスを実行可能にする装置 でもあります。
逆にガバナンスがないと、ガードレールは「設定が育たない」「現場が迂回する」ものになりがちです。
具体例：よくある事故と“足りないもの”の対応表
| 事故パターン | ガードレールでできること | それでも必要なガバナンス |
|---|---|---|
| 機密をプロンプトに貼った | 検知・マスク・ブロック | 何を機密扱いするか、例外運用、教育、事故時の連絡手順 |
| 不適切回答を顧客に送った | 出力検査・要レビュー化 | “外部送信前レビュー”のルール、責任者、記録 |
| 社員が勝手に無料AIを利用 | 基本できない（通らない） | 公式ルート整備、禁止/許可の線引き、啓蒙、ネットワーク/端末統制 |
| 監査で説明できない | ログ出力はできる場合も | ログ設計・保管・アクセス制御・監査手順 |
まとめ
- 生成AIセキュリティは、ガードレール（クラウド/オンプレ）だけでは完成しない
- ガードレールは「技術」、ガバナンスは「運用・意思決定・説明責任」
- 最初から完璧を目指さず、用途を絞って最小ガバナンス＋監視モードで始めるのが現実的
