ガードレールと評価：エージェントを安全に走らせる

横にスクロール

どんなパターンか

LLMを中核に据えたエージェントは、ツールを呼び、外部にアクションを起こす。だがLLMの出力は確率的で、同じ入力でも揺れるし、ときに誤った判断や意図しない指示に従う。読み取り専用のチャットボットなら誤りは表示だけで済むが、ファイルを消し、メールを送り、決済を実行するエージェントでは、一つの誤動作が取り返しのつかない結果になる。

ガードレールと評価は、この確率的な中核を信頼できる仕組みへ仕立てるための設計パターンだ。ガードレールはエージェントの入力・出力・行動を監視し、許容範囲を外れた動きを止める防護層である。評価は、その防護が機能しているか、エージェントが期待どおりの品質を保っているかを継続的に検証する営みだ。ガードレールが実行時に「止める」仕組みなら、評価は開発時に「測る」仕組みだと言える。

要点は、単一の対策を過信しないことにある。LLM自身に「危険なことはするな」と指示するだけでは守りにならない。プロンプトは容易に上書きされうるし、モデルの判断は保証ではないからだ。むしろ、モデルの外側に決定論的なチェックを何層も置き、どれか一枚が破られても次の層が受け止める多層防御として組むのが、この分野の基本姿勢である。ツールの呼び出し方そのものはツール利用で扱うが、本稿はその周囲に張る安全網に焦点を当てる。

仕組み

ガードレールは、エージェントのライフサイクルの各所に配置される。入口、出口、行動の直前、そして実行全体。順に見ていく。

入力と出力の検証

まず入口では、ユーザーや外部システムから受け取った入力を検証する。長すぎる入力の拒否、想定フォーマットの確認、明らかに範囲外の値の排除といった、古典的なバリデーションがそのまま効く。

出口の検証はより重要だ。LLMの出力はそのまま下流へ流さず、必ず構造と内容をチェックする。ツールに渡す引数はスキーマに沿っているか、数値は許容範囲に収まっているか、出力にAPIキーや個人情報などの機密が混入していないか。特に、モデルが生成した構造化データをそのままプログラムへ渡す設計では、スキーマ検証を通らない出力を弾き、必要なら再生成させるループが欠かせない。

プロンプトインジェクションへの備え

エージェントは、Webページやメール、ドキュメントといった外部テキストを読み込んで処理する。ここに、モデルへの指示を装った文字列が紛れ込むことがある。防御の原則はただ一つ、外部から来たテキストは指示ではなくデータとして扱うことだ。取り込んだ内容の中に命令口調の文があっても、それはあくまで処理対象の中身であって、エージェントの目標を書き換える権限を持たない。この区別を設計として貫く。

その上で、被害を前提に守りを固める。第一に権限の最小化だ。エージェントに与えるツールや認可の範囲を、目的に必要な最小限へ絞る。読み取りで足りる処理に書き込み権限を渡さない。第二に、影響の大きい操作を人間の承認の後ろに置く。仮に指示が乗っ取られても、実際に手を下す一歩手前で止められる。この主題はエージェントに限らないので、より広くはセキュリティ側の議論とあわせて押さえたい。直接上書き・偽装システムタグ・間接注入など実際の手法を「無防備 vs 対策」の応答比較で見たい場合はプロンプトインジェクション体験を参照。

ツール実行の承認ゲート

自動化と安全のバランスを取る現実的な仕組みが、承認ゲートである。すべての操作を人間が確認するのでは自動化の意味が薄れるが、逆に何もかも自動では危うい。そこで、操作を影響度で仕分ける。参照や検索のような可逆で安全な操作は自動で進め、削除・送信・決済のような不可逆で影響の大きい操作だけ、人間の確認を挟む。

暴走と無限ループの検知

エージェントは、ツール呼び出しと思考を繰り返しながらタスクを進める。この反復が終わらないことがある。同じ操作を延々と試み続けたり、二つの状態を往復したりして、ループから抜け出せない状態だ。

対策は上限を設けることだ。1タスクあたりの反復回数、消費トークン、実行時間、そして呼び出しコストに上限を置き、超えたら強制的に停止して人間へエスカレーションする。特にコスト上限は、バグや悪意ある入力による青天井の課金を防ぐ実務的な安全弁になる。

LLM-as-judgeと回帰評価

ガードレールが実行時の防御なら、評価は品質を継続的に測る仕組みだ。エージェントの出力は自由文が多く、単純な文字列一致では正誤を判定しにくい。そこで、別のLLMに評価者の役割を与え、出力が要件を満たすか、事実に反していないか、期待した口調かといった観点を採点させる手法がLLM-as-judgeである。人手のレビューより桁違いに速く、大量の出力を継続的にチェックできる。

さらに重要なのがオフライン評価、すなわち回帰テストだ。代表的な入力と期待される結果をデータセットとして蓄え、プロンプトやモデルを変更するたびに一括で流し、品質スコアの変化を測る。プロンプトの一行を直したら別のケースが壊れる、という回帰はこの分野で日常的に起きる。評価データセットは、それを出荷前に捕まえるセーフティネットになる。

使いどころと注意

ガードレールと評価は、エージェントが外部にアクションを起こすほど、また扱う操作が不可逆であるほど、価値が高まる。読み取り専用の社内向け検索アシスタントなら軽い検証で足りるが、顧客のデータを書き換えたり金銭を動かしたりするエージェントでは、多層防御と評価が前提条件になる。

注意すべきは、ガードレールを一つの万能な対策とみなさないことだ。入力検証だけ、承認ゲートだけでは守り切れない。それぞれが別種の失敗を受け止める層であり、組み合わせて初めて意味を持つ。同時に、締めすぎれば使い勝手を損なう。承認を求めすぎるエージェントは煩わしく、やがて人間が中身を見ずに承認を押す「承認疲れ」を招く。どの操作を自動で通し、どこで止めるかは、影響度に応じて調整する設計判断だ。

評価についても、LLM-as-judgeは万能ではない。評価者もまた確率的なモデルであり、判定は揺れるし、甘くも辛くもなる。判定基準を明文化し、ときに人手の評価と突き合わせて評価者自体を較正する必要がある。それでも、評価を仕組みにしておく価値は大きい。感覚ではなく数値で品質を語れるようになるからだ。ほかの設計パターンとの組み合わせはエージェント設計パターンから辿れる。

まとめ

ガードレールと評価は、確率的なLLMを信頼できるエージェントへ仕立てるための、地味だが決定的な作り込みだ。入出力の検証、外部テキストをデータとして扱う姿勢、権限の最小化、重要操作の承認ゲート、暴走を止める上限、そしてLLM-as-judgeと回帰評価。これらを多層に重ねることで、確率的な中核を抱えたまま、安全に走らせられる。派手さはないが、本番で任せられるエージェントと、デモ止まりのエージェントを分けるのは、この一段の作り込みである。