2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@DaokFrontier

LLMの予期せぬツール呼び出しを防ぐ！Guardrails AIで安全なエージェント構築

2
Posted at

LLMエージェントを開発していると、意図しないツール呼び出しや、予期せぬ挙動に直面してヒヤリとした経験はありませんか？不適切なAPIコールによるセキュリティリスク、データ漏洩、あるいは高額な利用料金の発生など、LLMの「暴走」は現実的な脅威です。この記事では、Guardrails AI を活用して、これらの課題を解決し、安全で信頼性の高いLLMエージェントを構築する実践的な方法を解説します。Guardrails AIを導入することで、LLMの出力を厳密に検証・制御し、予期せぬツール呼び出しや不適切な応答を未然に防ぎます。

LLMの予期せぬツール呼び出しが引き起こすリスク

LLMエージェントは、外部ツールを呼び出すことでその能力を飛躍的に向上させますが、この強力な機能には大きなリスクが伴います。具体的にどのような問題が起こり得るのでしょうか。

セキュリティリスクとデータ漏洩

エージェントがユーザー入力によって意図しないデータベース操作ツールを呼び出したり、機密情報を含むAPIにアクセスしたりする可能性があります。これにより、情報の不正取得や改ざん、最悪の場合はシステム全体への侵入につながる恐れがあります。

コストの増大

外部APIの呼び出しには通常、コストが発生します。LLMが不必要に高価なAPIを大量に呼び出してしまうと、予期せぬ形で運用コストが跳ね上がる可能性があります。

不適切な応答とユーザー体験の低下

LLMがハルシネーション（幻覚）を起こし、存在しないツールを呼び出そうとしたり、誤った引数でツールを呼び出したりすると、エラーが発生し、ユーザーは期待する結果を得られません。これはユーザー体験を著しく損ないます。

これらのリスクを軽減し、LLMの安全性を確保するためには、LLMの出力、特にツール呼び出しの制御が不可欠です。

Guardrails AIとは？LLMの安全性を高めるフレームワーク

Guardrails AIの概要と特徴

Guardrails AI は、LLMからのデータ検証と構造化を支援するPythonフレームワークです。LLMの入力と出力に対してガード（検証ルール）を適用することで、不適切なコンテンツの生成や、予期せぬツール呼び出しを防ぎます。任意のLLMと組み合わせて使用でき、柔軟性の高さが特徴です。

2024年6月時点の最新バージョンは guardrails-ai 0.10.2 で、Python 3.10以降をサポートしています。

他のガードレールソリューションとの比較

LLMの安全性確保のためのソリューションはGuardrails AI以外にもいくつか存在します。

  • Guardrails API (Google for Developers): Google GenAIの入力と出力に対するガードレールサービス。現在プライベートプレビュー版です。
  • Amazon Bedrock Guardrails: AWS Bedrock上で利用できるガードレール機能。コンテンツモデレーション、プロンプト攻撃検出、PIIリダクションなど、多岐にわたるセーフガードポリシーを提供します。
  • NVIDIA NeMo Guardrails: LLMの安全性に関するプログラマブルなミドルウェアを提供するオープンソースツールキット。ColangというDSLでガードレールポリシーを定義します。
  • OpenAI Guardrails SDK: OpenAIが提供するSDKで、ユーザー入力とエージェント出力のチェック、検証を可能にします。

これらのソリューションはそれぞれ異なる強みや適用範囲を持ちますが、Guardrails AIは特にフレームワークとして柔軟性が高く、カスタムバリデーターの作成や既存のLLMクライアントとの連携が容易である点がメリットです。

Guardrails AIの基本的な使い方：インストールとPII検出

このセクションでは、Guardrails AIのインストール方法と、Guardrails Hubから提供されるPII（個人特定可能情報）検出バリデーターを使った基本的な利用例を紹介します。

環境準備とインストール

まずはGuardrails AIをインストールします。Guardrails Hubのバリデーターを利用する場合は、CLIの構成も必要です。

# Guardrails AIのインストール
pip install guardrails-ai

# Guardrails CLIの構成（Guardrails Hubのバリデーターを利用する場合に必要）
# コマンド実行後、APIキーの入力が求められます。
guardrails configure

# PII検出バリデーターのインストール
# Guardrails Hubからバリデーターをダウンロードします。
guardrails hub install hub://guardrails/detect_pii

guardrails configure コマンドで設定するAPIキーは、Guardrails Hubへのアクセス権限を持つものである必要があります。

Guardオブジェクトを使ったLLM出力の検証

Guardrails AIの中心的なインターフェースは Guard オブジェクトです。これを使うことで、LLMの呼び出しをラップし、検証を適用できます。

import os
from guardrails import Guard
from guardrails.hub import DetectPII
import openai

# OpenAI APIキーを設定 (環境変数に設定することを強く推奨)
# 例: export OPENAI_API_KEY="YOUR_OPENAI_API_KEY"
# 環境変数に設定されていない場合は、以下のように直接設定も可能ですが、本番環境では非推奨です。
# os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"

# PII検出バリデーターを含むGuardを初期化
# PIIエンティティとしてメールアドレスと電話番号を検出するように設定します。
# on_fail="reask" は、検証失敗時にLLMに再生成を促すデフォルト動作です。
guard = Guard.use(DetectPII(pii_entities=["EMAIL_ADDRESS", "PHONE_NUMBER"]))

# --- GuardがLLM呼び出しをラップする例 ---
# この方法は、GuardrailsがサポートするLLMクライアント（例: OpenAI, LiteLLM）を使用する場合に便利です。
print("--- GuardがLLM呼び出しをラップする例 ---")
try:
    res = guard(
        model="gpt-3.5-turbo",
        messages=[
            {
                "role": "user",
                "content": "私のメールアドレスはtest@example.comです。電話番号は090-1234-5678です。"
            }
        ]
    )
    print("Raw LLM Output:", res.raw_llm_output)
    print("Validated Output:", res.validated_output) # PIIが検出されると、修正されたりNoneになったりする
    print("Validation Passed:", res.validation_passed)
    print("Validation Results:", res.validation_results)
except Exception as e:
    print(f"Error during guarded LLM call: {e}")

# --- LLM出力をGuard.parseで検証する例 ---
# 任意のLLMクライアントやカスタムLLMからの出力を検証する場合に柔軟に対応できます。
print("\n--- LLM出力をGuard.parseで検証する例 ---")
try:
    # まずはLLMを直接呼び出し、出力テキストを取得します
    llm_output = openai.chat.completions.create(
        model="gpt-3.5-turbo",
        messages=[
            {
                "role": "user",
                "content": "私のメールアドレスはtest@example.comです。電話番号は090-1234-5678です。"
            }
        ]
    ).choices[0].message.content

    print("Original LLM Output:", llm_output)

    # Guard.parseを使用してLLM出力を検証します
    res_parse = guard.parse(llm_output=llm_output)

    print("Parsed Validated Output:", res_parse.validated_output)
    print("Validation Passed:", res_parse.validation_passed)
    print("Validation Results:", res_parse.validation_results)

    # 検証に失敗した場合の例 (on_fail="exception" を使用)
    # on_fail="reask" はparseメソッドでは再試行しないため、ここでは例外発生で動作を確認します。
    guard_exception = Guard.use(DetectPII(pii_entities=["EMAIL_ADDRESS"], on_fail="exception"))
    try:
        print("\n--- on_fail='exception' の例 ---")
        guard_exception.parse(llm_output="私のメールはtest@example.comです。")
    except Exception as e:
        print(f"Exception caught as expected: {e}")

except Exception as e:
    print(f"Error during LLM call or parsing: {e}")

上記のコードを実行すると、DetectPII バリデーターによってメールアドレスと電話番号が検出され、validation_passed が False となるか、validated_output が修正された形式で出力されることが確認できます。

Guardrails AI APIサーバーの構築

Guardrails AIは、独自のAPIサーバーとしてデプロイすることも可能です。これにより、OpenAI互換のエンドポイントを通じて、既存のアプリケーションにガードレール機能を簡単に組み込むことができます。

サーバー起動のための準備

Guardrails APIサーバーを起動するには、guardrails-api パッケージと uvicorn が必要です。

pip install guardrails-api uvicorn

次に、ガードレールを定義するPythonファイルと、サーバー設定を記述する .env ファイルを作成します。

pii-guard.py (ガードレール定義ファイル)

from guardrails import Guard
from guardrails.hub import DetectPII

# "pii-guard" という名前のGuardオブジェクトを作成し、PII検出バリデーターを追加します。
guard = Guard(name="pii-guard")
guard.use(DetectPII(pii_entities=["EMAIL_ADDRESS", "PHONE_NUMBER"]))

.env (サーバー設定ファイル)

PORT=8000
GUARDRAILS_LOG_LEVEL=INFO
GUARDRAILS_CONFIG_PATH=./pii-guard.py # 上記で作成したガードレール定義ファイルのパス

Guardrails APIサーバーの起動

設定ファイルが準備できたら、以下のコマンドでサーバーを起動します。

guardrails-api start --env .env

または、設定ファイルを直接指定することも可能です。

guardrails-api start --config pii-guard.py

サーバーが起動すると、http://localhost:8000 で利用可能になります。
Swagger UIは http://localhost:8000/docs で、ヘルスチェックは http://localhost:8000/health-check で確認できます。

このAPIサーバーを介してLLMの出力を検証することで、アプリケーションのアーキテクチャに大きな変更を加えることなく、LLMの安全性を向上させることが可能です。

Guardrails AI導入時のハマりどころと回避策

Guardrails AIは強力なツールですが、導入時にはいくつかの課題に直面する可能性があります。ここでは、よくあるエラーとその解決策、およびパフォーマンスに関する考慮事項を解説します。

1. PromptCallableException または LLM呼び出しの失敗

原因:
APIキーの設定ミス、LLM APIへの引数エラー、LLM APIのダウン、カスタムLLMラッパーのシグネチャ不一致などが考えられます。

回避策:

  • APIキーの確認: 環境変数 OPENAI_API_KEY などが正しく設定されているか、GuardrailsがLLMにAPIキーを渡せているかを確認します。
  • LLM引数の確認: guard() メソッドに渡す引数が、使用しているLLMクライアント（例: openai.chat.completions.create）の期待する引数と一致しているか確認します。不要な引数は削除するか、LiteLLMクライエントで動作確認を行います。
  • カスタムLLMラッパー: カスタムのLLM callableを使用している場合、messages キーワード引数を受け取り、文字列を返す関数として呼び出せることを確認してください。

2. Guardrails Hubからのバリデーターインストール時の「Unauthorized」エラー

原因:
Guardrails Hubへのアクセスに使用しているAPIキーが、有効でないか、権限がない可能性があります。

回避策:

  • APIキーの再生成: Guardrails Hubのポータルで新しいAPIキーを生成します。
  • CLIの再構成: 新しいAPIキーを使って guardrails configure コマンドを再度実行し、CLIを構成し直します。

3. レイテンシの増大とリトライループ

原因:
Guardrails AIは、検証に失敗した場合にLLMに再生成を促す（on_fail="reask"）メカニズムを持っています。これにより、LLM呼び出しが複数回発生し、応答時間が大幅に増加する可能性があります。特に、最初の検証パスで失敗する応答の割合が高い場合に顕著です。

回避策:

  • 入力と出力の両方を検証: 出力だけでなく、LLMへの入力プロンプトもガードレールで検証することで、問題のあるコンテンツがLLMに到達するのを防ぎます。これにより、LLMが不適切な応答を生成する可能性自体を減らせます。
  • 高速で決定論的なプリLLMガードレール: LLM呼び出しの前に実行されるガードレールは、正規表現ベースのPII検出やルールベースのインジェクションチェックなど、高速で決定論的なものを使用します。LLMベースのチェックはレイテンシが増えるため、本当に必要な場合にのみ使用を検討します。
  • OnFailActionの適切な設定: Guardrailsはバリデーターが失敗した際の様々な OnFailAction を提供します。
    • REASK: LLMに再生成を促しますが、レイテンシが増える可能性があります。
    • EXCEPTION: 検証失敗時に例外を発生させ、アプリケーション側でエラーハンドリングを行う。
    • FIX: 検証失敗時にプログラム的に出力を修正する（例えば、PIIをマスクするなど）。
    • REFRAIN: 出力を返さない。
      状況に応じて最適なアクションを選択し、レイテンシとユーザー体験のバランスを取ります。
  • レイヤー化された防御: 単一のガードレールに依存せず、複数のガードレールを組み合わせることで、各層が異なる種類の問題を捕捉し、1つが失敗しても他の層がバックアップを提供します。

これらの対策を講じることで、Guardrails AIを効果的に活用し、LLMエージェントの安全性とパフォーマンスを両立させることが可能になります。

Guardrails AIを活用したエージェント構築のベストプラクティス

安全で信頼性の高いLLMエージェントを構築するためには、Guardrails AIの導入だけでなく、設計段階からの考慮が重要です。ここでは、設計上のトレードオフと、推奨されるベストプラクティスについて解説します。

設計上のトレードオフ

Guardrailsの導入は、常にいくつかのトレードオフを伴います。

  • カスタム可能性とパフォーマンス: 既製のガードレールは手軽ですが、特定のドメインではカスタムポリシーが必要です。カスタムポリシーは開発コストがかかる一方で、より高速で堅牢な分類器として機能する可能性があります。
  • レイテンシとポリシー準拠率: ガードレールを追加するほどポリシー準拠率は向上しますが、特にLLMベースのチェックはレイテンシを増大させます。ユーザーエクスペリエンスを損なわないよう、適切なバランスを見つける必要があります。
  • コストと精度: LLMベースのガードレールは精度が高い傾向がありますが、コストも高くなります。安価で高速なモデル（例: GPT-4o-mini、Llamaの小規模モデル）をファインチューニングすることで、精度とコストのバランスを取ることも可能です。
  • ブロッキングと修正: 違反を検出した場合にコンテンツをブロックするか、自動的に変更するかを選択できます。厳格なコンプライアンスにはブロッキングが適していますが、ユーザーエクスペリエンスを考慮すると修正が望ましい場合もあります。

ベストプラクティス：多層防御と最小権限の原則

LLMエージェントの安全性を確保する上で最も重要なのは、多層防御 (Defense in Depth) と最小権限の原則 (Principle of Least Privilege) です。

多層防御のアプローチ

  1. 入力ガードレール:
    • LLMに到達する前に、悪意のあるプロンプト、ジェイルブレイク試行、ポリシー違反の要求をブロックします。
    • PII検出と匿名化、プロンプトインジェクション検出などが含まれます。
  2. 処理ガードレール (Processing Guardrails):
    • モデルが動作する実行コンテキストを形成し、アクセスできるものや行動方法を決定します。
    • LLMが利用可能なツールを制限したり、特定のトピック以外の会話を禁止したりします。
  3. 出力ガードレール:
    • モデルの応答がユーザーに返される前に評価します。
    • ハルシネーション検出、有害なコンテンツの検出、PIIの匿名化、出力フォーマットの検証などを行います。
  4. ツールガードレール:
    • エージェントが呼び出すツールやAPIに適用され、どのツールがどの引数で呼び出されるかを許可または拒否します。
    • 例えば、データベースアクセスを持つエージェントが、削除コマンドや認証情報クエリを実行できないようにします。

最小権限の原則

  • エージェントが呼び出せるすべてのツールは、最小限の権限を持つべきです。
  • 例えば、データベースへの読み取り権限のみを持つツールと、書き込み権限を持つツールを明確に分離し、書き込み権限を持つツールは厳重なガードレールで保護します。

その他のベストプラクティス

  • 人間による承認 (Human-in-the-Loop): 破壊的な操作（データベースの削除、金融取引など）や高リスクなツール呼び出しの前に、人間による承認プロセスを挿入します。
  • 継続的な監視と評価: ガードレールのトリガー率、誤検知率、レイテンシへの影響を追跡します。新しい攻撃パターンやモデルのドリフトに合わせてガードレールを定期的に見直し、更新します。
  • 敵対的テスト (Red Teaming): 実際にガードレールを突破しようと試みることで、ギャップを特定し、防御を強化します。
  • 明確なエラーメッセージ: ガードレールがトリガーされた場合、ユーザーに「リクエストがブロックされました」のような曖昧なメッセージではなく、具体的なガイダンスを提供します。
  • システムプロンプトはガードレールではない: システムプロンプトはモデルへの「丁寧な要求」であり、意図的な敵対的入力に対しては機能しないことが多いです。真のガードレールはランタイムで制約を適用します。
  • ツール定義の明確化: ツール定義には明確な境界、エッジケース、明確な目的を持たせることで、モデルが混乱したアクション選択に陥るのを防ぎます。

これらのベストプラクティスを遵守することで、LLMのツールコーリングを安全に管理し、堅牢なAIエージェントを構築できます。

まとめ

この記事では、LLMエージェントの予期せぬツール呼び出しが引き起こすリスクを解説し、その対策としてGuardrails AIを活用する方法を具体的に示しました。

Guardrails AIを導入することで、以下のメリットが得られます。

  • LLMの出力、特にツール呼び出しを厳密に検証し、制御できる。
  • PII検出やプロンプトインジェクション対策など、多様な安全機能を実装できる。
  • APIサーバーとしてデプロイすることで、既存システムとの連携も容易になる。

導入時のハマりどころとして、APIキーの設定やレイテンシの問題、リトライループへの対策を挙げ、それぞれの回避策を提示しました。また、LLMエージェントの安全性を最大限に高めるために、多層防御や最小権限の原則といった設計上のベストプラクティスも紹介しました。

Guardrails AIは、AIエージェントの信頼性と安全性を飛躍的に向上させる強力なツールです。ぜひ本記事を参考に、あなたのプロジェクトにGuardrails AIを導入し、より堅牢なLLMエージェントを構築してみてください。

さらに深く学びたい方は、Guardrails AIの公式ドキュメント (https://docs.guardrailsai.com/) を参照することをお勧めします。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?