翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

自動推論チェックをアプリケーションに統合する

自動推論ポリシーをガードレールにデプロイした後 (「」を参照自動推論ポリシーをアプリケーションでデプロイする)、実行時にそれを使用して LLM レスポンスを検証し、フィードバックに基づいて行動できます。このページでは、検証 API を呼び出し、検出結果をプログラムで解釈し、無効なレスポンスの書き換えや明確化のための質問などの一般的な統合パターンを実装する方法について説明します。

自動推論チェックは検出モードでのみ動作し、コンテンツをブロックするのではなく検出結果とフィードバックを返します。アプリケーションは、レスポンスの提供、書き換え、明確化のリクエスト、デフォルトの動作へのフォールバックなど、検出結果の処理を決定する責任があります。

インテグレーションの概要

実行時に、統合は次のフローに従います。

User question ──► LLM generates response ──► ApplyGuardrail validates response
                                                        │
                                              ┌─────────┴─────────┐
                                              │                   │
                                            VALID              Not VALID
                                              │                   │
                                              ▼                   ▼
                                        Serve response     Inspect findings
                                        to user                  │
                                                        ┌────────┴────────┐
                                                        │                 │
                                                   OTHER FINDING     TRANSLATION_
                                                      TYPES       AMBIGUOUS / SATISFIABLE
                                                        │                 │
                                                        ▼                 ▼
                                                   Rewrite using    Ask user for
                                                   AR feedback      clarification
                                                        │                 │
                                                        ▼                 ▼
                                                   Validate again   Validate with
                                                                    clarified input
    

自動推論の検出結果は、Amazon Bedrock ガードレール設定をサポートするすべての API を通じて返されます。

このページでは ApplyGuardrail API に焦点を当てています。これは、以下で説明する書き換えと明確化のパターンを最も柔軟に実装できるからです。他の APIs」を参照してください。 https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use.html

オープンソースの書き換えチャットボットのサンプル

このページで説明されているパターンの完全な本番環境スタイルの実装については、GitHub の「自動推論チェックのチャットボットの書き換え」を参照してください。このサンプルアプリケーションでは、以下を示します。

このサンプルでは、Python/Flask バックエンドと React フロントエンドを使用し、Amazon Bedrock と通信して LLM 推論を行い、Amazon Bedrock ガードレールと通信して ApplyGuardrail API による検証を行います。

自動推論チェックを使用して ApplyGuardrail を呼び出す

ApplyGuardrail API を使用して、ガードレールに対してコンテンツを検証します。API は 1 つ以上のコンテンツブロックを受け入れ、自動推論の結果を含む評価を返します。

リクエスト構造

例: を使用して LLM レスポンスを検証する AWS CLI

aws bedrock-runtime apply-guardrail \
  --guardrail-identifier "your-guardrail-id" \
  --guardrail-version "1" \
  --source OUTPUT \
  --content '[
    {
      "text": {
        "text": "User: Am I eligible for parental leave if I have been working here for 2 years full-time?\nAssistant: Yes, you are eligible for parental leave."
      }
    }
  ]'

例: Python を使用して LLM レスポンスを検証する (boto3)

import boto3
import json

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")

response = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="your-guardrail-id",
    guardrailVersion="1",
    source="OUTPUT",
    content=[
        {
            "text": {
                "text": (
                    "User: Am I eligible for parental leave if I have been "
                    "working here for 2 years full-time?\n"
                    "Assistant: Yes, you are eligible for parental leave."
                )
            }
        }
    ],
)

# The AR findings are in the assessments
for assessment in response.get("assessments", []):
    ar_assessment = assessment.get("automatedReasoningPolicy", {})
    findings = ar_assessment.get("findings", [])
    for finding in findings:
        # Each finding is a union — exactly one key is present
        # Possible keys: valid, invalid, satisfiable, impossible,
        #                translationAmbiguous, tooComplex, noTranslations
        print(json.dumps(finding, indent=2, default=str))

応答の構造

ApplyGuardrail レスポンスには assessments配列が含まれます。各評価には、findings配列を持つautomatedReasoningPolicyオブジェクトが含まれます。各検出結果はユニオンタイプです。次のいずれかのキーがあります。

各検出結果タイプとそのフィールドの詳細な説明については、「」を参照してください結果と検証結果。

実行時に AR の検出結果を解釈する

自動推論の検出結果をプログラムで処理するには、アプリケーションが検出結果タイプ、翻訳の詳細、およびサポートルールまたは矛盾するルールを抽出する必要があります。以下のセクションでは、検出結果の各部分を解析する方法について説明します。

検出結果タイプを決定する

各検出結果は結合であり、1 つのキーのみ存在します。検出結果タイプを決定するには、どのキーが存在するかを確認します。

def get_finding_type(finding):
    """Return the finding type and its data from an AR finding union."""
    for finding_type in [
        "valid", "invalid", "satisfiable", "impossible",
        "translationAmbiguous", "tooComplex", "noTranslations"
    ]:
        if finding_type in finding:
            return finding_type, finding[finding_type]
    return None, None

翻訳を読む

ほとんどの検出結果タイプには、自動推論チェックによって自然言語入力がどのように形式ロジックに変換されたかを示すtranslationオブジェクトが含まれています。翻訳には以下が含まれます。

untranslatedPremises と をチェックuntranslatedClaimsして、検証の範囲を理解します。VALID 結果は翻訳されたクレームのみを対象とし、翻訳されていないコンテンツは検証されません。

サポートルールまたは矛盾するルールを読む

結果のタイプに応じて、結果を説明するルールが結果に含まれます。

これらのルールとシナリオは、「」で説明されている書き換えパターンの主要な入力ですAR フィードバックを使用して無効なレスポンスを書き換える。

集計結果を決定する

1 つの検証リクエストで複数の検出結果を返すことができます。全体的な結果を判断するには、結果を重要度でソートし、最も悪いものを選択します。重要度の最悪順は、TRANSLATION_AMBIGUOUS、IMPOSSIBLE、、INVALIDSATISFIABLE、、 ですVALID。

SEVERITY_ORDER = {
    "tooComplex": 0,
    "translationAmbiguous": 0,
    "impossible": 1,
    "invalid": 2,
    "satisfiable": 3,
    "valid": 4,
    "noTranslations": 5, 
}

def get_aggregate_result(findings):
    """Return the worst finding type from a list of findings."""
    worst = None
    worst_severity = float("inf")
    for finding in findings:
        finding_type, _ = get_finding_type(finding)
        severity = SEVERITY_ORDER.get(finding_type, 0)
        if severity < worst_severity:
            worst_severity = severity
            worst = finding_type
    return worst

アプリケーションでの検証結果の処理

集計結果を使用して、アプリケーションが次に何をするかを決定します。次の表は、各結果タイプに推奨されるアクションをまとめたものです。

AR フィードバックを使用して無効なレスポンスを書き換える

自動推論チェックの最も強力な統合パターンは、書き換えループです。レスポンスが invalidまたは の場合satisfiable、アプリケーションは元のレスポンス、特定の検出結果、ポリシールールを含むプロンプトを作成し、ポリシーと一致するようにレスポンスを書き換えるように LLM に要求します。書き換えられたレスポンスは再度検証され、レスポンスが validまたは最大反復回数に達するまでループが続行されます。

ループフローの書き換え

LLM generates initial response
         │
         ▼
Validate with ApplyGuardrail ◄──────────────────┐
         │                                       │
         ▼                                       │
   ┌─────┴─────┐                                 │
   │           │                                 │
 VALID     Not VALID                             │
   │           │                                 │
   ▼           ▼                                 │
 Done    Construct rewriting prompt              │
         with findings + rules                   │
              │                                  │
              ▼                                  │
         LLM rewrites response                   │
              │                                  │
              ▼                                  │
         Max iterations? ──── No ────────────────┘
              │
             Yes
              │
              ▼
         Return best response
         with warning
      

書き換えプロンプトを作成する

書き換えプロンプトには、AR の検出結果からの 3 つの情報を含める必要があります。

プロンプトテンプレートの書き換え例:

The following response was checked against our policy and found to be
{finding_type}.

Original response:
{original_response}

The validation found the following issue:
- Premises (what was understood from the input): {premises}
- Claims (what was asserted): {claims}
- Contradicting rules: {contradicting_rules}

Please rewrite the response so that it is consistent with the policy document. 
Keep the same helpful tone and answer the user's question
accurately based on the rules. If you cannot provide an accurate answer
without more information, explain what additional information is needed.

ベストプラクティスの書き換え

明確な質問をする

自動推論チェックが translationAmbiguous、satisfiable、または impossibleの結果を返す場合、LLM にはレスポンスを正確に書き換えるのに十分な情報がない可能性があります。このような場合、アプリケーションはユーザーに明確化を求め、その回答を次の検証試行に組み込むことができます。

明確化を求めるタイミング

明確化パターン

明確化フローは次のように機能します。

例: satisfiable検出結果から明確な質問を生成する

def generate_clarifying_questions(finding_data, user_question):
    """Ask the LLM to generate clarifying questions from a SATISFIABLE finding."""
    claims_true = json.dumps(
        finding_data.get("claimsTrueScenario", {}), indent=2, default=str
    )
    claims_false = json.dumps(
        finding_data.get("claimsFalseScenario", {}), indent=2, default=str
    )

    prompt = (
        f"A user asked: {user_question}\n\n"
        f"The answer is correct when these conditions hold:\n{claims_true}\n\n"
        f"But incorrect when these conditions hold:\n{claims_false}\n\n"
        f"Generate 1-3 short, specific questions to ask the user to determine "
        f"which conditions apply to their situation. Format each question on "
        f"its own line."
    )

    return generate_response(prompt, "You are a helpful assistant.")

監査証跡を構築する

自動推論の検出結果は、数学的に検証可能な有効性の証明を提供します。規制された業界やコンプライアンスシナリオでは、この証明が重要な差別化要因です。パターンマッチングや確率的に評価されるだけでなく、特定の変数割り当てを持つ特定のポリシールールに対して AI レスポンスが検証されたことを示すことができます。

効果的な監査証跡を構築するには、検証リクエストごとに次の情報をログに記録します。

例: 監査ログエントリ構造

{
  "timestamp": "2025-07-21T14:30:00Z",
  "request_id": "req-abc123",
  "guardrail_id": "your-guardrail-id",
  "guardrail_version": "1",
  "user_question": "Am I eligible for parental leave?",
  "llm_response": "Yes, you are eligible for parental leave.",
  "validation_result": "valid",
  "findings": [
    {
      "type": "valid",
      "premises": "isFullTime = true, tenureMonths = 24",
      "claims": "eligibleForParentalLeave = true",
      "supporting_rules": ["A1B2C3D4E5F6"]
    }
  ],
  "action_taken": "served_response",
  "rewrite_iterations": 0
}