[AWS]BedrockでAgents未使用時のSQL修正・管理方法

TIPS

Agents for Amazon Bedrockを使用しない場合に、SQLを修正・管理する方法について、この場合SQLの生成・修正・実行の責任はアプリケーション側に移ります。Bedrockの役割は、Agentのような「自律的な司令塔」ではなく、アプリケーションから呼び出される「特定の機能を提供する部品」に変わります。

大きく分けて2つのパターンが考えられます。

パターン1：アプリケーションがSQLを完全に管理・実行する (最も一般的で推奨)

これは、BedrockのLLMをSQLの実行に一切介在させない、伝統的かつ堅牢な方法です。

処理フロー

[ユーザー操作 (ボタンクリックなど)]
      ↓
[アプリケーション (Web/Backendサーバー)]  (操作に応じて、あらかじめ用意されたSQLを選択・構築する)
      ↓
[★SQLを修正・管理する場所]          (アプリケーションのソースコード内でSQLを直接編集する)
      ↓
[データベース]                          (構築されたSQLを実行し、結果を返す)
      ↓
[アプリケーション]                      (結果を画面に表示する)

SQLの修正手段

SQLの修正は、アプリケーションのソースコード内で行います。

例えば、Webアプリケーションのバックエンド（Python, Java, PHP, Goなどで記述）に、データベースへ接続しクエリを実行するロジックがあります。そのコード内のSQL文を直接書き換えます。

(例) Python (Flask) のバックエンドコード

Python

from flask import Flask, jsonify
import psycopg2

app = Flask(__name__)

# ... (DB接続情報) ...

@app.route('/get_active_users')
def get_active_users():
    # ★★★ SQLを修正したい場合は、この文字列を直接編集してデプロイします ★★★
    sql = """
        SELECT COUNT(DISTINCT riyo_no) as user_count
        FROM user_tbl
        WHERE 
            (user_flg = '1' OR user_match_flg = '1')
        AND status = '0';
    """
    conn = psycopg2.connect(...)
    cur = conn.cursor()
    cur.execute(sql)
    result = cur.fetchone()
    user_count = result[0]
    cur.close()
    conn.close()

    return jsonify({'user_count': user_count})

この方法では、Bedrockは一切関与しません。

メリット

  • 高いセキュリティ: 実行されるSQLが固定またはプログラムで安全に構築されるため、SQLインジェクションのリスクを最小限に抑えられます。
  • 安定したパフォーマンス: 事前にチューニング・テストされた最適なSQLを実行できます。
  • 予測可能性と信頼性: 意図しないSQLが実行されることがなく、システムの動作が安定します。

パターン2：BedrockのLLMを「SQL生成アシスタント」として利用する (高度な利用法)

このパターンでは、ユーザーからの自然言語入力を元に、Bedrockの基盤モデル（Claudeなど）を使ってSQL文を文字列として生成させ、そのSQLをアプリケーションが受け取ってから実行します。

処理フロー

[ユーザーの自然言語入力 (例: 「先月の利用者数」)]
      ↓
[アプリケーション]
      ↓
[1. Bedrock APIを呼び出し]
   (プロンプトと共に自然言語を送信。「以下のスキーマを参考にSQLを生成してください：...」)
      ↓
[2. Bedrock LLMがSQL文(文字列)を生成]
   (例: "SELECT COUNT(...) FROM ... WHERE ...")
      ↓
[3. アプリケーションがSQL(文字列)を受信]
      ↓
[4. ★SQLの検証・修正・サニタイズを行う場所]
   (アプリケーションコード内で、危険なコマンドがないかチェックしたり、条件を追加・変更したりする)
      ↓
[5. データベース]
   (検証済みのSQLを実行)

SQLの修正手段

この場合、SQLの制御は2段階で行われます。

  1. プロンプトエンジニアリング: Bedrockに送るプロンプトを調整することで、生成されるSQLの形式や内容をコントロールします。例えば、「DELETEやDROPは絶対に使用しないでください」といった制約をプロンプトに含めることで、危険なSQLが生成されるのを防ぎます。
  2. アプリケーションコードでの事後処理: Bedrockから返ってきたSQL文字列を、アプリケーション側で正規表現やルールベースでチェックします。特定のキーワードが含まれていたら実行を拒否したり、固定のWHERE句を追加したりするなど、プログラムによる修正を加えます。

課題とリスク

このパターンは柔軟性が高い反面、本番環境での利用には非常に高度な注意と対策が必要です。

  • セキュリティリスク: 悪意のある入力によって、意図しないSQL（個人情報の全件取得、データ削除など）が生成・実行されるSQLインジェクションの危険性が非常に高いです。
  • パフォーマンス: LLMが生成するSQLは、必ずしもインデックスを利用した効率的なものであるとは限りません。
  • 正確性: データベースのスキーマやデータの意味をLLMが誤解し、間違った結果を返すSQLを生成する可能性があります。

まとめと推奨

結論として、Agentを使用しない場合、パターン1（アプリケーションがSQLを完全に管理する方式）が、セキュリティ、パフォーマンス、信頼性の観点から強く推奨される方法です。 SQLの修正は、開発者が直接アプリケーションのソースコードを編集することで行います。

比較項目パターン1：アプリケーション管理 (Agentなし)パターン2：LLMがSQL生成 (Agentなし)(参考) Agent利用
SQL修正場所アプリケーションのソースコードプロンプト + アプリの検証コードLambda関数のソースコード
セキュリティ非常に高い非常に低い (対策が必須)高い
パフォーマンス高い (最適化可能)不安定高い (最適化可能)
柔軟性低い (決められたSQLのみ)非常に高い (自然言語で指示)高い (自然言語で指示)
推奨度★★★★★ (本番環境の標準)★☆☆☆☆ (プロトタイプや厳重管理下のツール向け)★★★★★ (安全かつ柔軟)

コメント

タイトルとURLをコピーしました