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

# 概念: メッセージ、コンテンツブロックタイプ、チェック
<a name="guardrails-use-invoke-guardrail-checks-concepts"></a>

以下の概念では、 `InvokeGuardrailChecks` API へのリクエストの構造について説明します。

## メッセージ
<a name="guardrails-use-invoke-guardrail-checks-messages"></a>

メッセージは、評価のために送信するコンテンツの基本的な単位です。各メッセージには、コンテンツを作成したユーザーを識別するロールと、1 つ以上の型付きコンテンツブロックとして実際のテキストを保持するコンテンツ配列の 2 つのフィールドがあります。

```
{
  "role": "user",
  "content": [{ "text": "Hello world" }]
}
```

これは、Amazon Bedrock の他の場所で使用されている role-plus-content-blocks 構造をミラーリングするため、モデル用に既に構築した会話は、ほとんどまたはまったく再構成`InvokeGuardrailChecks`せずに に渡すことができます。リクエストの `messages`フィールドは配列であるため、単一のメッセージまたはマルチターン交換を表すシーケンスを送信できます (たとえば、システム命令の後にユーザーがターンするなど）。メッセージは、指定した順序で評価され、その位置は重要です。一部の結果は、ゼロベースの によってメッセージを参照し`messageIndex`、そのメッセージ内のブロックを によって参照します `contentIndex` (機密情報の結果を参照）。

ロールはコンテンツのオリジンにラベルを付けます。次のロールがサポートされています。
+ `system` – モデルの動作を設定する手順。
+ `user` – エンドユーザーからの入力。
+ `assistant` – モデルによって生成される出力。

## コンテンツブロックタイプ
<a name="guardrails-use-invoke-guardrail-checks-content"></a>

`content` フィールドは、プレーン文字列ではなく型付きブロックの配列です。型付きブロックは、キー名が型である小さなオブジェクトです。この設計により、メッセージ形式はメッセージ全体の形状を変更することなく、将来的に他の種類のコンテンツ (画像やドキュメントなど) を伝送できます。現在、サポートされているブロックタイプは のみで`text`、その値はベア文字列です。

```
{ "text": "Hello world" }
```

メッセージには、最大 10 個のコンテンツブロックを含めることができます。コンテンツブロックには、最大 1 つの`text`ブロックを含めることができます。`text` は現在サポートされている唯一のタイプであるため、これは実質的にコンテンツブロックごとに 1 つのテキストブロックを意味します。1 つのロール内の複数の異なるテキストを評価するには、それらを`content`配列内の個別のコンテンツブロックとして送信します。複数のロール間で複数の異なるテキストを評価するには、それらを`messages`配列内の個別のメッセージとして送信します。

## チェック
<a name="guardrails-use-invoke-guardrail-checks-checks"></a>

*チェック*という用語は、Amazon Bedrock ガードレールによって提供される*保護*という用語と置き換え可能です。`checks` オブジェクトは、チェックタイプごとに 1 つのオプションフィールドを持つ設定オブジェクトであり、実行するチェックのみを含めます。個別の有効化/無効化フラグは設定しません。チェックは、そのフィールドが存在する場合にのみ実行され、省略されたチェックは結果も使用も生成されません。少なくとも 1 つのチェックフィールドを設定する必要があります。

```
"checks": {
  "contentFilter":         { ... },
  "promptAttack":          { ... },
  "sensitiveInformation":  { ... }
}
```

設定はリクエストごとにインラインであるため、保存されたガードレールリソースを管理することなく、安全体制を呼び出しごとに変更できます。エージェントループのステップが異なると、同じメッセージまたは異なるメッセージに対して異なるチェックの組み合わせをリクエストできます。

各チェックは独自の設定形状を保持します。フィールド名はチェックを選択します。その中のオブジェクトには、チェックが検索するものが一覧表示されます。
+ `contentFilter` – `categories`リスト (HATE、INSULTS、SEXUAL、VIOLENCE、MISCONDUCT) を取得します。
+ `promptAttack` – `categories`リスト (JAILBREAK、PROMPT\_INJECTION、PROMPT\_LEAKAGE) を取得します。
+ `sensitiveInformation` – `entities`リスト (31 個のサポートされている PII エンティティ) を取得します。

**リクエストとレスポンスは対称** – で設定したキー`checks`は、 `results`と で返されるキーと同じです`usage`。`contentFilter` と をリクエストすると`sensitiveInformation`、これら 2 つのみがレスポンスに表示されます。 `promptAttack` は実行されなかったため、存在しません。これにより、結果を生成したチェックに簡単にマッピングできます。

**すべてのチェックで検出のみ** – チェックブロック、マスク、またはコンテンツの書き換えはありません。各 はスコア (コンテンツフィルターとプロンプト攻撃`severityScore`の場合は 、機密情報の場合は`confidenceScore`プラスの位置オフセット) を返し、特定の要件に基づいてアプリケーションがどのように動作するかを決定します。