LLM/AIエージェントの安全運用：Tool Calling権限設計とPydanticによるガードレール実装

Posted at 2026-11-03

読者が抱える課題

AIエージェントにFunction Calling（Tool Calling）を実装し自律的な処理を任せるケースが増加しています。しかし、制御設計が不十分な場合、プロンプトインジェクションやモデルの誤認識によって意図しないAPI呼び出し、データベースの破壊的更新、機密データの外部送信といったセキュリティリスクが発生します。

この記事で分かること

最小権限原則に基づくAIエージェントの権限分離アーキテクチャ
LangChainやOpenAI SDKを活用した入力Validationおよび実行前ガードレール（Human-in-the-Loop）の実装パターン
実用的なガードレール検証チェックリスト

対象読者・前提条件

Pythonを使用したLLMアプリケーション（AIエージェント）の開発経験があるエンジニア
Open AI SDKまたはLangChain等のフレームワークを用いたTool Callingの実装基礎知識を有していること

AIエージェントのセキュリティアーキテクチャ

AIエージェントの安全性を担保するためには、プロンプトによる指示（ソフトガードレール）だけに頼らず、システム層での制限（ハードガードレール）を設ける「多層防御」が不可欠です。

[ユーザー入力 / 外部データ]
       │
       ▼
┌──────────────┐
│ 入力ガードレール │  (プロンプトインジェクション検知・スキーマ検証)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  LLM Agent   │  (Tool Callingの決定)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ 出力ガードレール │  (実行前権限チェック / Human-in-the-Loop)
└──────┬───────┘
       │
       ▼
┌──────────────┐
│  Target API  │  (最小権限スコープのサービスアカウント実行)
└──────────────┘

1. 権限分離の原則

読取専用と書き込み用のAPIキーを分離: 検索系Toolと変更系Toolで利用する認証情報やサービスアカウントを明確に分けます。
最小限のスコープ設定: システム全体の管理者権限を持つ単一の認証情報（データベース接続文字など）をエージェントへ与えないでください。

Pythonによるガードレール実装例

Pydanticを用いた引数の型・値制限と、危険性の高い操作に対する人間による承認（Human-in-the-Loop）の実行フロー例です。

python loss-prevention.py

from typing import Literal
from pydantic import BaseModel, Field, EmailStr

# --- 1. Pydanticによるパラメータバリデーションガードレール ---
class SendEmailInput(BaseModel):
    """メール送信ツールの引数定義"""
    # 宛先ドメインを制限するための独自検証などを層として設定
    to_email: EmailStr = Field(description="送信先のメールアドレス")
    subject: str = Field(max_length=100, description="件名(100文字以内)")
    body: str = Field(max_length=1000, description="本文(1000文字以内)")
    priority: Literal["low", "medium"] = Field(
        default="low", 
        description="優先度。highの指定は不可"
    )

class DatabaseQueryInput(BaseModel):
    """DB検索ツールの引数定義 (読取専用のみ許可)"""
    query_type: Literal["SELECT"] = Field(description="SQL操作タイプ。SELECTのみ許可")
    table_name: Literal["users", "orders"] = Field(description="参照許可テーブル")
    limit: int = Field(default=10, le=100, description="最大取得件数(100件以下)")

# --- 2. Tool実行インターセプター (Human-in-the-Loop) ---
def execute_tool_safely(tool_name: str, arguments: dict):
    """
    Tool実行前に介入し、危険性の高い操作についてはユーザー承認を求めるガードレール関数
    """
    # 破滅的な操作が含まれるToolのリスト
    CRITICAL_TOOLS = ["delete_user_account", "execute_data_migration"]
    
    if tool_name in CRITICAL_TOOLS:
        print(f"[SECURITY ALERT] 影響度の高い操作が呼び出されました: {tool_name}")
        print(f"引数: {arguments}")
        
        # 実際の運用ではCLI入力ではなく承認Web UIやSlackインタラクション等に置き換えます
        approval = input("この操作の実行を許可しますか？ (yes/no): ")
        if approval.lower() != "yes":
            raise PermissionError(f"Tool '{tool_name}' の実行がユーザーによって拒否されました。")
            
    # 実際のTool処理呼び出し
    return f"Tool {tool_name} executed successfully."

※ 本コードは挙動の概念を示す例です。実際の環境ではプロダクション用のフレームワークや環境構成に合わせて適切に修正してください。

権限設計・ガードレール評価チェックリスト

実務で本番環境へ配置する前に確認すべきチェックリストです。

チェック項目	設計区分	内容	判定
最小権限API	認証・認可	エージェント用APIキーに不要な削除・更新権限が付与されていないか	[ ]
スキーマ制限	引数検証	Pydantic等のスキーマで、文字列長や数値の上限（`le`, `max_length`）が定義されているか	[ ]
Enum/Literal限定	引数検証	操作対象（テーブル名やコマンド種別）が固定値リストで制限されているか	[ ]
副作用の人間承認	ガードレール	削除・送信・決済系処理を実行する前にHuman-in-the-Loopの承認フローがあるか	[ ]
構造化エラー応答	システム保護	Tool呼び出し失敗時のスタックトレースがLLMに渡らないようマスクされているか	[ ]
レートリミット	運用制限	1セッションあたりのTool呼び出し回数およびトークン消費上限が指定されているか	[ ]

導入時・運用上の注意点とよくある失敗

プロンプトのみによる制御への完全依存
- 「削除コマンドは絶対に実行しないでください」といったプロンプト指示のみでガードレールを組むのは危険です。プロンプトインジェクション攻撃によって容易に迂回される可能性があります。必ずコードベース（APIプロキシやバリデータ）で物理的に制限してください。
過剰な承認フローによるユーザー体験の低下
- すべてのTool実行に人間の承認を挟むと利便性が損なわれます。「Read（参照）」系の処理は自動実行を許容し、「Write/Delete（変更・削除）」系の処理に絞って承認を求める設計が推奨されます。
仕様変更への追従
- LLMフレームワークやSDKのセキュリティ仕様、関数のインターフェースは変更されることがあります。導入時は必ず該当ライブラリの最新の公式ドキュメントを参照してください。

まとめ

AIエージェントの安全な運用には、プロンプト指示による補正と、コードレベルでのアクセス制御（入力制限・型検証・実行前承認）を組み合わせた多層的な設計が不可欠です。本記事のインターセプター構造や評価チェックリストを参考に、システムに応じた保護機能を組み込んでください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up