LLMガードレールの設計｜入力・出力・挙動の3層で安全境界をつくる実務ガイド

LLMをプロダクトやAPI連携に組み込むとき、多くのチームがまず書くのは「あなたは丁寧な業務アシスタントです。個人情報を出力してはいけません」といったシステムプロンプトです。これは有用な指示ですが、安全境界そのものではありません。システムプロンプトはモデルへの「お願い」であり、プロンプトインジェクションや巧妙な言い回しで書き換えられたり、無視されたりする余地が残ります。実務でLLMアプリを安全に運用するには、モデルの外側にプロンプトとは独立した検査・制御の仕組みを重ねる必要があります。これが「ガードレール(guardrails)」と呼ばれる設計パターンです。この記事では、特定の攻撃手法の解説ではなく、ガードレールという仕組み全体をどう設計・実装するかを、入力・出力・挙動の3層に分けてアーキテクチャの目線で整理します。

ガードレールとは何か#

ガードレールは、道路脇の物理的な柵と同じ発想の仕組みです。運転手(モデル)がどれだけ注意深くても、外側に柵があれば逸脱の被害を限定できます。LLMアプリにおけるガードレールは、モデルへの入力とモデルからの出力、そしてモデルが取ろうとする行動を、モデルとは独立したロジックでチェックし、問題があれば止める・書き換える・人に確認を求める仕組みを指します。

システムプロンプトだけに頼れない理由は単純です。システムプロンプトも、ユーザー入力も、外部から読み込んだ文書も、モデルにとっては本質的に同じ「テキストの流れ」として処理されます。開発者が書いた指示だけを特別扱いする保証はモデルの内部にはなく、巧妙な入力によって上書きされる余地が残ります。OWASPが公開する生成AIアプリ向けの脆弱性ランキングでも、プロンプトインジェクションは2版連続で最上位に位置づけられており、単一の防御では防ぎきれない前提が置かれています。ガードレールは、この「モデルの判断だけに安全性を委ねない」ための、モデル外の制御層です。

入力側のガードレール#

入力側のガードレールは、モデルに渡す前にユーザー入力や外部コンテンツを検査する層です。主に次の3種類のチェックが対象になります。

• プロンプトインジェクション検知: 「これまでの指示を無視して」といった直接注入や、外部文書・Webページに埋め込まれた間接注入の兆候を検知します。
• 機微情報・有害コンテンツのフィルタリング: 個人情報や社外秘情報がそのまま入力されていないか、ヘイトスピーチや自傷・違法行為の助長といった有害な内容が含まれていないかを分類器でチェックします。
• 脱獄(jailbreak)検知: モデルの安全対策を回避しようとする言い回し(役割演技を強制する、架空のルールを設定させる等)のパターンを検知します。

Azure AI Content SafetyのPrompt Shieldsは、この入力側チェックを専用APIとして提供する例です。ユーザーが直接入力する攻撃(User Prompt Attacks)と、外部文書に埋め込まれた攻撃(Document Attacks)の両方を検出対象にしており、日本語を含む複数言語に対応しています。入力側ガードレールは、モデルが実際にトークンを生成する前に問題を弾ける点が利点で、無駄なコストや不要な出力生成を避けられます。

出力側のガードレール#

出力側のガードレールは、モデルが生成した結果をユーザーやシステムに渡す前に検査する層です。

• コンテンツモデレーション: 生成された文章に有害な内容が含まれていないかを、入力側と同じ分類器でチェックします。OpenAIのModeration APIは、ハラスメント・ヘイト・性的コンテンツ・自傷・暴力といったカテゴリを、入力側だけでなく生成された出力側の検査にも使える設計になっています。
• フォーマット・スキーマ検証: JSONなど構造化された出力を後段のプログラムに渡す場合、決めたスキーマに沿っているかを検証します。この領域は構造化出力(Structured Outputs)の仕組みと深く関わるため、詳しくは

  あわせて読みたい

  構造化出力(Structured Outputs)とは何か｜LLMの返答をプログラムで安全に扱うための仕組み

  で扱っています。
• 事実性・トピック逸脱のチェック: 回答が与えた根拠資料の範囲を超えていないか、想定外の話題に逸れていないかを確認します。

出力側は「モデルが実際に何を言ったか」を検査できる最後の砦です。入力側をすり抜けた注入や、モデル自身の判断ミスによる問題は、出力側で捕まえるしかありません。OpenAIのAgents SDKが示す「ガードレール」の実装モデルはこの構造をよく表しており、入力ガードレールはワークフローの最初のエージェントの前で、出力ガードレールは最後のエージェントが完了した後で走り、問題を検知すると処理を即座に止める仕組み(tripwire)を備えています。入口と出口それぞれに独立した検査点を置く発想は、他のフレームワークでも共通です。

挙動面のガードレール#

エージェントのようにツールを呼び出し、実際にシステムへ作用するLLMアプリでは、文章のチェックだけでは足りません。モデルが「何をしようとしているか」という挙動そのものを制御する層が必要になります。

OWASPは、このような「LLMに与える権限や自律性が、タスクに本当に必要な範囲を超えている」状態を「過剰な代理性(Excessive Agency)」として挙げています。モデルが呼び出せる機能・アクセスできるデータ・人の判断を介さずに完結できる範囲が広いほど、注入やモデルの誤判断が実害につながりやすくなる、という考え方です。人間の承認を挟む設計は、OpenAIのAgents SDKでも「Human-in-the-loop approvals」として用意されており、副作用を伴うツール呼び出しが発生すると実行を承認待ちの状態で一時停止し、アプリ側が承認・却下したうえで同じ実行状態から再開する仕組みが示されています。

実装手段の類型#

ガードレールは単一の技術ではなく、複数の実装手段を組み合わせて構成します。代表的な類型は次のとおりです。

分類器ベースのAPIは高速で運用しやすい一方、学習データにない新しい攻撃パターンには弱くなりがちです。ルールベースは判定基準が明確で監査しやすい反面、表現のバリエーションに追従しきれません。スキーマ検証は構造の妥当性は保証しますが中身の正しさまでは保証しません。OSSフレームワークはこれらを組み合わせるパイプラインを提供しますが、導入・チューニングの工数がかかります。LLM-as-judgeは柔軟な評価ができる分、コストとレイテンシが増え、判定自体にバイアスが混じる可能性があります。単独で完結する手段はなく、用途に応じて重ねるのが基本です。

実装手段の分類は、OpenAIのModeration API・Agents SDKのガードレール機構、NVIDIA NeMo GuardrailsとGuardrails AIの公式ドキュメント、AzureのPrompt Shields、AnthropicのConstitutional Classifiersの公開情報をもとに整理しました。各サービスの提供状況・仕様は変更されうるため、導入前に最新の公式情報を確認してください。

過剰と過小のトレードオフ#

ガードレールは「入れれば入れるほど安全」という単純な話ではありません。厳しくしすぎたガードレールは、正常な入力まで誤って弾く誤検知(false positive)を増やし、ユーザー体験を損ないます。業務で使う自然な言い回しがブロックされ続ければ、利用者はツールを避けるようになり、結局は別の(検査を経ない)手段で同じ作業をしてしまう、という逆効果も起こり得ます。逆に緩すぎるガードレールは、リスクをそのまま露出させます。

この判断は、機能ごとにリスクの重さが異なることを踏まえて行います。社外に公開するチャットボットと、社内限定の下書き支援ツールでは、許容できる誤検知率も見逃しの重さも変わります。削除や送金のような不可逆な操作を伴うエージェントには厳しめの閾値と人間の承認を、下書き作成や要約のようなやり直しが利くタスクには緩めの閾値を、というように、用途別に段階を分けて設計するのが現実的な落としどころです。

評価とレッドチーミングの必要性#

ガードレールは「実装したら終わり」ではありません。分類器の閾値も、ルールのパターンも、時間が経てば新しい攻撃手法や新しい正常系の入力に対して古びていきます。継続的な評価が欠かせない理由はここにあります。

まず、ガードレール自体の性能を定量的に測ります。既知の攻撃パターンや、過去に誤検知したケースを集めたテストセットを作り、検知率と誤検知率を継続的に測定します。次に、実際の攻撃者の視点でガードレールを突破しようとするレッドチーミングを行います。AnthropicがClaudeの脱獄対策として公開している「Constitutional Classifiers」の取り組みでは、多数の参加者による長時間の攻撃試行を経て脱獄成功率を大きく引き下げたと報告されており、防御側の設計だけでなく、外部からの継続的な攻撃検証を組み込むことの重要性を示しています。

実装のステップ#

ガードレールをゼロから設計する場合、次の順序で進めると抜け漏れが出にくくなります。

よくある質問#

まとめ#

ガードレールは、システムプロンプトという「お願い」を、モデルの外側にある検査・制御の仕組みで補強する設計パターンです。入力・出力・挙動の3層で考え、分類器・ルール・スキーマ検証・OSSフレームワーク・LLM-as-judgeといった手段を用途に応じて組み合わせ、厳しさと使いやすさのバランスを取りながら、継続的な評価とレッドチーミングで穴を埋め続ける。この地道な積み重ねが、LLMを組み込んだアプリやエージェントを実務で安全に動かし続けるための現実的な土台になります。