LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

生成AIのガードレールとは、入力・出力・権限を守る安全対策の総称

生成AIのガードレールとは、業務にLLM(大規模言語モデル。文章生成・要約・対話を行うAIモデル)を組み込む際に、入力・出力・権限の各段階に設ける安全対策の総称です。具体的にはプロンプトインジェクション対策、出力フィルタリング、権限・データ境界の設定、監査ログ、人的レビューという複数の層で構成されます。この記事は、AIモデル自体を賢く動かす話ではなく、動かした結果を安全に運用する側面を扱います。

この5層は独立して機能するのではなく、互いを補い合う関係にあります。入力側の対策だけでは、モデルの学習内容に起因する誤情報までは防げません。出力側のチェックだけでは、そもそも不適切な指示が入力された経緯が記録に残りません。

OWASP(Open Worldwide Application Security Project。Webアプリケーションセキュリティを扱う国際的な非営利団体)は、生成AIアプリケーション特有のリスクを体系化した「Top 10 for LLM Applications」を公開しています^*1。次章から、この分類に沿って各層の対策を具体的に見ていきます。

プロンプトインジェクション・ジェイルブレイク——入力を乗っ取る攻撃手口

直接型と間接型——攻撃者が指示を混入させる2つの経路

プロンプトインジェクション(利用者やコンテンツ内に埋め込まれた指示で、AIに開発者の意図しない動作をさせる攻撃)は、OWASPのTop 10で2版連続してLLM01として掲載されているリスクです^*1。LLMは指示とデータを同じ入力チャネルで処理するため、攻撃者が作り込んだ入力を新しい指示として解釈してしまう場合があります^*1。

直接型はチャット欄に「これまでの指示を無視して」のような文言を利用者が直接入力するケースです^*1。間接型はより見つけにくく、AIが要約・処理する外部の文書やWebページに攻撃者が指示を埋め込む手口です^*1。モデルが隠された指示を正規の内容と区別できず、そのまま実行してしまうことがあります^*1。

ジェイルブレイクとシステムプロンプト漏えい——防御を回避・無効化する試み

ジェイルブレイク(あらかじめ設定された制約や安全対策を回避させる入力手法)は、プロンプトインジェクションの一種として扱われることが多い攻撃です。安全対策を無効化する言い回しを重ねて、本来拒否すべき出力を引き出そうとします。

OWASPは、システムプロンプト(AIの振る舞いを定める非公開の初期指示)自体が漏えいするリスクも別項目として挙げています^*1。システムプロンプトの内容が漏れると、それを踏まえた新たな攻撃を組み立てやすくなるためです。

クラウド側の防御機能——コンテンツフィルタとプロンプトシールド

OWASPはこれらのリスクへの対策として、入力の検証と出力のフィルタリング、権限の制限、機微な操作への人的レビューを組み合わせる多層防御を推奨しています^*1。主要クラウドはこの多層防御を製品機能として提供しています。

Amazon Bedrock Guardrailsのコンテンツフィルタは、有害なテキスト・画像コンテンツのブロックに加え、プロンプトインジェクションやジェイルブレイクの試みへの対応も含む機能として案内されています^*3。Azure AI Content SafetyのPrompt Shieldsは、大規模言語モデルへの入力攻撃のリスクをテキストから検出する機能です^*4。

入出力フィルタリング——機密情報・PIIの検出とマスキング

入出力フィルタリングは、利用者からの入力とAIからの応答の両方を検査し、有害な内容や機密情報を通過させない仕組みです。OWASPは、意図しない機密情報の開示を独立したリスク項目として位置づけています^*1。

PII検出とマスキング——Bedrockの機密情報フィルタ

Amazon Bedrock Guardrailsには機密情報フィルタがあり、PII(氏名・連絡先など個人を特定できる情報)やカスタムの正規表現パターンを検出してマスクまたはブロックできます^*3。あわせて拒否トピック機能で、業務上扱わせたくない話題自体を利用者の質問・モデルの応答の両方で遮断できます^*3。単語フィルタでは、冒涜的な語や特定の固有名詞を完全一致でブロックする設定も可能です^*3。

有害コンテンツの検出——Azure・Googleのハームカテゴリ

Azure AI Content Safetyの分析APIは、性的コンテンツ・暴力・ヘイト・自傷行為の4カテゴリについて、複数段階の深刻度でテキスト・画像を検査します^*4。Google Gemini APIの安全設定も、ハラスメント・ヘイトスピーチ・性的表現・危険なコンテンツの4カテゴリに対して、5段階のブロックしきい値を利用者側で選べる仕組みです^*5。子どもの安全に関わるコンテンツなど一部の保護は、しきい値の調整対象外として常に有効になっています^*5。

3つのサービスが対象とするカテゴリや検出の粒度は一致していません。導入時は、自社が扱う業務データの性質に合わせて、どのカテゴリ・どの粒度のフィルタが必要かを個別に洗い出す作業が欠かせません。

ハルシネーション抑制——根拠チェックで事実誤りを検知する仕組み

ハルシネーション(AIが根拠のない内容を事実のように生成する現象)は、業務利用における代表的な懸念点です。OWASPは、誤った情報を過度に信頼してしまう問題を「誤情報」というリスク項目として整理しています^*1。

根拠に基づく検証——コンテキスト接地チェックと根拠性検出

Amazon Bedrock Guardrailsのコンテキスト接地チェックは、参照元の資料とモデルの応答を比較し、根拠に基づかない内容や利用者の質問との関連性が低い内容を検出・フィルタリングする機能です^*3。Azure AI Content Safetyの根拠性検出(プレビュー機能)も同様に、LLMの応答が利用者から提供された参照資料に基づいているかどうかを判定します^*4。

形式論理による検証——自動推論チェックの位置づけ

Amazon Bedrock Guardrailsにはもう一段進んだ機能として、形式論理を用いて応答の事実誤りを検証する自動推論チェックがあります^*3。統計的な言語生成とは異なる論理検証の手段を組み合わせている点が特徴です。

これらの機能は、いずれも参照元の資料が用意されている前提で動作します。参照資料を持たない自由回答形式の利用では、根拠チェックの効果が限定されるため、業務での使い方自体を設計段階から見直す必要があります。

権限境界とHITL——AIエージェントの過剰な自律性を抑える設計

過剰な代理行為——ツール実行権限を絞る発想

OWASPは、AIエージェントに過剰な機能・権限・自律性を与えることで生じるリスクを「過剰な代理行為」として挙げています^*1。外部システムを操作するツールをAIに持たせる場合、そのツールが実行できる範囲を業務上必要な最小限に絞る設計が前提になります。

Azure AI Content SafetyのTask adherence API(プレビュー)は、AIエージェントによるツールの使用が、利用者とのやり取りの中で意図から外れていたり時期尚早だったりする状態を検出する機能です^*4。エージェントが計画から外れた操作に進む前に、異常を検知する用途に位置づけられます。

人的レビュー(HITL)——最終判断を人に残す境界線

HITL(Human In The Loop。最終的な意思決定や承認を人が担う運用設計)は、権限境界を補完する仕組みです。データの削除・送信・契約に関わる操作など、誤りが業務に大きく響く処理は、AIに完結させず人の承認を経る設計にします。

権限境界とHITLをどこに置くかは、業務ごとに判断が変わってくるでしょう。読み取り専用の照会業務であればAIの自律性を高めやすく、書き込みや外部送信を伴う業務では承認ステップを厚くする、という切り分けが実務的な出発点になります。

OWASP Top 10とNIST AI RMF——リスクの分類と管理プロセスの違い

ここまで見た対策は個別の機能単位のものですが、企業として体系的に管理するには、リスクの分類とマネジメントプロセスの両方を押さえる必要があります。

OWASP Top 10——リスクを10項目に分類したカタログ

OWASPのTop 10 for LLM Applicationsは、プロンプトインジェクションを筆頭に、機密情報の開示・サプライチェーンの脆弱性・データとモデルの汚染・不適切な出力処理・過剰な代理行為・システムプロンプト漏えい・ベクトルと埋め込みの弱点・誤情報・無制限な消費という10項目で構成されています^*1。いわば「何が危険か」を整理したチェックリストです。

NIST AI RMF——4つの機能で回すマネジメントプロセス

これに対しNIST(米国国立標準技術研究所)のAI Risk Management Framework(AI RMF)は、2023年1月に公表された自主利用のフレームワークで、Govern(統治)・Map(状況把握)・Measure(測定)・Manage(対応)という4つの機能でリスク管理のプロセスを回します^*2。2024年7月には生成AI固有のリスクを補うプロファイルも追加公表されています^*2。

OWASPが「何を防ぐか」というリスクの内容を示し、NIST AI RMFが「どう継続的に管理するか」というプロセスを示す、という役割の違いがあります。外注先を選ぶ際は、この2つの枠組みのどちらか一方だけでなく、両方を踏まえた提案ができるかどうかも確認材料になります。

内製と外注の分かれ目——ガードレール実装に必要な知識と工数

内製に必要な知識——複数領域をまたぐ専門性

ガードレールを内製で構築するには、複数の専門知識が要ります。OWASPのリスク分類とNIST AI RMFのプロセスに関する理解、利用するクラウドのガードレール機能(Bedrock Guardrails・Azure AI Content Safety等)の設定方法、そしてプロンプトインジェクションへの耐性を検証するレッドチーミング(攻撃者視点での疑似攻撃によるテスト)の実施スキルです^*1*3*4。これらを1人の担当者が兼務するのは負荷が大きく、システム開発チームとセキュリティ担当の連携体制が前提になります。

対策不足の代償——防御層を欠いた場合の影響

ガードレールの層を欠いたまま生成AIを業務に組み込むと、意図しない機密情報の応答への混入や、外部から埋め込まれた指示に従った誤動作につながるおそれがあります^*1。これらはOWASPが独立したリスク項目として挙げている事象であり、事後の対応コストは検知の遅れに比例して増えていきます^*1。

専門家に依頼する場合との差分——監査ログとレッドチーミングの範囲

内製では、ガードレール機能の初期設定までは対応できても、継続的なレッドチーミングや監査ログの分析まで手が回らない場合があります。専門パートナーに委託する場合は、初期設定・攻撃耐性の検証・監査ログの継続的な監視という3つの領域を、どこまで一括で依頼できるかが選定の分かれ目です。

。対象業務の範囲や既存のクラウド利用状況によって、必要な工数は変わってきます。現状の生成AI活用計画を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：生成AIガードレール実装で押さえる3つの判断軸

本稿では生成AIのガードレール・安全対策について、OWASPとNISTの公式情報、主要クラウドのガードレール機能をもとに整理しました。要点は3つに集約できます。第一に、ガードレールは入力防御・出力防御・権限境界・監査ログ・人的レビューという層の組み合わせであり、単一の機能で完結しません^*1。第二に、Amazon Bedrock・Azure・Googleは対応範囲の異なる機能を提供しており、自社の業務要件に合わせた組み合わせの検討が欠かせません^*3*4*5。第三に、OWASP Top 10がリスクの分類を示し、NIST AI RMFが管理プロセスを示すという役割の違いを理解したうえで、内製と外注の工数を見積もる必要があります^*1*2。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OWASP GenAI Security Project「OWASP Top 10 for LLM Applications 2025」（https://genai.owasp.org/llm-top-10/）
2. *2　出典：NIST「AI Risk Management Framework」（2023年1月公表）（https://www.nist.gov/itl/ai-risk-management-framework）
3. *3　出典：AWS「Amazon Bedrock Guardrails」（https://aws.amazon.com/bedrock/guardrails/）
4. *4　出典：Microsoft「Azure AI Content Safety とは」（Azure AI services ドキュメント）（https://learn.microsoft.com/en-us/azure/ai-services/content-safety/overview）
5. *5　出典：Google「Gemini API 安全設定（Safety settings）」（https://ai.google.dev/gemini-api/docs/safety-settings）

Tweet