Amazon Bedrock Guardrails（ガードレール）とは｜日本語で効かせる設定・料金・実装【2026年版】

Amazon Bedrock Guardrails は、生成AIアプリの入力プロンプトとモデル応答を検査し、有害表現・禁止トピック・個人情報・ハルシネーションを遮断またはマスキングするマネージド機能です。2023年11月28日にプレビュー、2024年4月23日に一般提供が始まりました。モデルを問わず同じ検査を適用できるため、Claude から Amazon Nova へ乗り換えても安全側の実装をやり直さずに済みます。ただしガードレールの対象になるのはエンドポイント次第で、その境目はAWS Bedrockのモデル選定｜Claude・Nova・OpenAI・Gemmaの選び分けと切替判断で整理しました。

ただし日本語アプリでは、設定を1か所間違えるとフィルターが素通りします。この記事では6つのポリシーの守備範囲、日本語を検査するための必須条件、料金の計算方法、そして3種類あるAPIの使い分けを、公式ドキュメントとAWS SDKのサービスモデル実測値で整理します。

まとめ

• Guardrails のポリシーは6種類。コンテンツフィルター、拒否トピック、単語フィルター、機密情報フィルター、文脈接地チェック、Automated Reasoning チェックです。
• 日本語を検査するなら Standard tier 一択です。Classic tier の対応言語は英語・フランス語・スペイン語の3言語のみで、日本語入力は検査対象外になります。
• Standard tier はクロスリージョン推論が必須条件です。東京リージョンで作っても、プロンプトはムンバイやシドニーへ転送され得ます。
• 文脈接地チェック・単語フィルター・Automated Reasoning チェックは、2026年8月時点で日本語に対応していません。
• 料金の単位は text unit（最大1,000文字）です。コンテンツフィルターは1,000 text unit あたり0.15ドル、機密情報フィルターは0.10ドル、正規表現と単語フィルターは無料です。
• 呼び出し方は3通り。推論に紐づける Converse、単体で検査する ApplyGuardrail、ガードレールを作らずに検査する InvokeGuardrailChecks です。

Guardrailsが検査する6ポリシーと適用範囲

1つのガードレールは複数ポリシーの組み合わせです。単独でも構成でき、有効にしたポリシーの分だけ課金されます。なお推論モデルの reasoning content ブロックは検査対象から除外されます。

上限値は AWS SDK（botocore 1.43.69）に同梱される Bedrock のサービスモデル定義から取得したものです。設計時に効いてくるのは拒否トピックの30件で、業務ルールを細かく分けすぎるとすぐ枯渇します。

有害カテゴリと拒否トピックの守備範囲

コンテンツフィルターのカテゴリは Hate、Insults、Sexual、Violence、Misconduct、Prompt Attack の6つです。強度は入力側と出力側で別々に指定でき、検知時の動作は BLOCK（遮断）と NONE（遮断せず検知結果だけ返す）から選びます。本番投入前は NONE で運用してください。実トラフィックでの誤検知件数を数えてから遮断へ切り替えれば、正常な問い合わせを落とすリスクを実測で押さえられます。

拒否トピックは「金融商品の個別推奨」のように、業務上答えてはいけない話題を自然言語で定義します。定義文には指示ではなく話題の説明を書きます。「暗号資産に関する内容をすべてブロックせよ」は指示なので機能しません。定義の長さは公式ドキュメント内で記述が割れており、拒否トピックのページは200文字、ティア比較表は Standard tier で1,000文字としています。APIのモデル定義上の文字列上限は200文字なので、長い定義を使う場合は実際に作成して弾かれないか確認してください。

プロンプト攻撃フィルターが見る3類型

Prompt Attack カテゴリが検知するのは、ジェイルブレイク（DANのような安全機構の回避）、プロンプトインジェクション（開発者指示の上書き）、プロンプトリーケージ（システムプロンプトの抽出）の3つです。プロンプトリーケージの検知は Standard tier 限定で、Classic tier では動きません。

ここに実装上の落とし穴があります。開発者のシステム指示とユーザーによる上書き攻撃は文面が似ているため、タグで区別しないと正規のシステムプロンプトまで攻撃と判定されます。InvokeModel 系でタグ付けする場合、タグ接尾辞（tagSuffix）はリクエストごとにランダムな値を使ってください。固定値にすると、攻撃者がタグを閉じて後ろに任意の文字列を追加できてしまいます。Converse API では後述の guardContent ブロックで同じ制御を行います。

機密情報フィルターの31エンティティと日本固有情報の扱い

PIIエンティティは31種類が定義済みです。EMAIL、PHONE、NAME、ADDRESS のような汎用項目に加えて、AWS_ACCESS_KEY と AWS_SECRET_KEY が含まれる点は実務で効きます。エージェントが認証情報を復唱する事故を、正規表現を書かずに止められます。

一方で31種のうち10種は米国・英国・カナダの制度に紐づくエンティティ（US_SOCIAL_SECURITY_NUMBER や UK_NATIONAL_INSURANCE_NUMBER など）で、マイナンバーに相当する項目はありません。運転免許証番号は国非依存の DRIVER_ID でカバーされますが、日本の12桁形式に最適化されている保証はないため検知率は実データで確かめてください。日本固有の識別子は regexesConfig で自作するのが確実です。正規表現は各パターン500文字までで、追加料金が発生しません。件数の上限はAPIのモデル定義が10件、Service Quotas の記載が30件と食い違うので、10件を超える設計にする前に実際に登録して確認してください。

もう1つ、エージェント用途では見落とせない制限があります。この機密情報フィルターはテキスト出力のみを対象としており、モデルが tool_use（関数呼び出し）の出力パラメータとして応答した場合、その中のPIIは検出されません。ツールへ渡す引数の保護は、アプリケーション側の責務として別途実装してください。

日本語アプリでStandard tierが必須になる理由

ティア設定は、日本語アプリで最初に確認すべき箇所です。選択を誤ると、フィルターは有効なのに何も検知しないまま本番稼働します。

Classic tierの対応言語は英語・フランス語・スペイン語の3言語

公式の言語対応表を集計すると、コンテンツフィルターとプロンプト攻撃の対応言語は Standard tier が84言語（うち日本語を含む17言語は最適化済み）、Classic tier は英語・フランス語・スペイン語の3言語だけです。拒否トピックも同様で、Standard tier は100言語、Classic tier は3言語です。

公式ドキュメントは「サポート対象外の言語ではガードレールは機能しません」と明記しています。日本語のチャットボットに Classic tier のコンテンツフィルターを設定しても、検査が効きません。日本語を扱うなら tierConfig に STANDARD を明示してください。既存のガードレールを流用するときも、まずティア設定を確認するところから始めます。

Standard tier選択時に発生する東京リージョン外への転送

Standard tier にはクロスリージョン推論という条件が付きます。サービスモデルの定義文にも「このティアはガードレールでクロスリージョン推論を使うことを要求する」と書かれており、crossRegionConfig でガードレールプロファイルを指定しないと使えません。

日本から使う場合のプロファイルは apac.guardrail.v1:0 です。東京（ap-northeast-1）を起点にしたとき、検査リクエストの転送先は東京のほか、ムンバイ（ap-south-1）、大阪（ap-northeast-3）、ソウル（ap-northeast-2）、シンガポール（ap-southeast-1）、シドニー（ap-southeast-2）の6リージョンです。ガードレールの設定自体は東京に保管されますが、入力プロンプトと出力結果は日本国外へ出る可能性があります。転送は暗号化され地理的境界（この場合はAPAC）の外へは出ませんし、追加費用もかかりません。

ここで見落とされがちな非対称性があります。モデル推論側には日本専用の推論プロファイルがあり、たとえば jp.anthropic.claude-sonnet-4-5-20250929-v1:0 の転送先は東京と大阪の2リージョンだけです。ところがガードレール側に用意されたプロファイルは us、us-gov、eu、uk、au、ca、apac の7つで、日本単独のプロファイルは存在しません。モデル推論を国内に閉じても、Standard tier のガードレール評価だけはAPAC各国へ出ます。推論のリージョン設計だけを見て「国内完結」と説明すると、検査経路で前提が崩れます。

データを国内に留める要件がある案件では、この時点で判断が要ります。日本語の検査精度を取るか、データ所在地を取るかの二択です。国内保持が譲れないなら、Bedrock Guardrails 単体で解こうとせず、chakoshiとは？NTTの日本語LLMガードレールの仕組み・検知項目・API連携【2026年】のような国内事業者のガードレールや自前の検査層と組み合わせる設計に切り替えるべきです。判断の枠組みはAIガードレールとは？入力・出力を検査する実装層の設計と選定基準【2026年版】で整理しています。

日本語では機能しないポリシーと代替策

ティアを Standard にしても、日本語で動かないポリシーが残ります。単語フィルターと文脈接地チェックは英語・フランス語・スペイン語の3言語のみ、Automated Reasoning チェックは英語（米国）のみです。機密情報フィルターは17言語対応で、日本語は最適化済みに含まれます。

影響が大きいのは文脈接地チェックです。RAGの回答が検索結果から逸脱していないかを0〜0.99の閾値で判定する機能ですが、日本語のナレッジベースでは使えません。日本語RAGのハルシネーション対策は、Guardrails ではなく検索側の品質と回答生成時のプロンプト設計で担保する前提で設計してください。構成の考え方はナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】にまとめています。単語フィルターについては、日本語の禁止語は正規表現（無料）で代替するのが現実解です。

ガードレール作成の最小構成と設定上限

作成手段はマネジメントコンソール、API、CloudFormation の3通りです。CloudFormation のリソース型は AWS::Bedrock::Guardrail で、ContentPolicyConfig や CrossRegionConfig など API と同じ構造を持ちます。ここでは差分がわかりやすいAPIの形で示します。

CreateGuardrailの日本語向け最小構成

次のJSONは、日本語アプリで最低限必要な要素（Standard tier、クロスリージョン設定、有害カテゴリ、プロンプト攻撃、拒否トピック、PIIマスキング）を1つにまとめた構成です。ファイルに保存して aws bedrock create-guardrail --cli-input-json file://guardrail.json で作成します。

{
  "name": "support-bot-guardrail",
  "description": "Guardrail for the customer support chatbot",
  "blockedInputMessaging": "この質問にはお答えできません。",
  "blockedOutputsMessaging": "この内容は回答できません。",
  "crossRegionConfig": { "guardrailProfileIdentifier": "apac.guardrail.v1:0" },
  "contentPolicyConfig": {
    "filtersConfig": [
      { "type": "HATE", "inputStrength": "HIGH", "outputStrength": "HIGH",
        "inputAction": "BLOCK", "outputAction": "BLOCK" },
      { "type": "PROMPT_ATTACK", "inputStrength": "HIGH", "outputStrength": "NONE" }
    ],
    "tierConfig": { "tierName": "STANDARD" }
  },
  "topicPolicyConfig": {
    "topicsConfig": [
      { "name": "InvestmentAdvice",
        "definition": "個別の金融商品の売買を推奨する内容。",
        "examples": ["どの株を買えばいいですか"],
        "type": "DENY" }
    ],
    "tierConfig": { "tierName": "STANDARD" }
  },
  "sensitiveInformationPolicyConfig": {
    "piiEntitiesConfig": [
      { "type": "EMAIL", "action": "ANONYMIZE" },
      { "type": "AWS_SECRET_KEY", "action": "BLOCK" }
    ],
    "regexesConfig": [
      { "name": "my-number", "pattern": "[0-9]{12}", "action": "ANONYMIZE" }
    ]
  }
}

プロンプト攻撃の outputStrength を NONE にしているのは、攻撃検知が入力側の関心事だからです。出力側にも強度をかけると、モデルが攻撃を説明的に言及しただけで遮断されます。作成後は working draft が生成されるので、テストウィンドウで挙動を確認してからバージョンを切ってアプリに紐づけてください。バージョンはリソースではないためARNを持ちません。IAMポリシーはガードレール本体に対して書けば、全バージョンへそのまま効きます。

設計時に効く上限値

拒否トピック30件、カスタム単語10,000件（各100文字まで）、遮断メッセージ500文字が主な上限です。アカウントあたりのガードレールは100本、1本あたりのバージョンは20までです。Automated Reasoning ポリシーは1つのガードレールに最大2件まで紐づけられ、ポリシーの元になる文書は5MBかつ50,000文字までという制約があります。社内規程が長い場合はドメイン単位に分割してから取り込みます。

見落としやすいのは1リクエストで処理できる入力量です。Standard tier のコンテンツフィルターが受け付ける最大入力は、バージニア北部が1,000 text unit なのに対し東京は500 text unit、シドニーは400 text unit と、リージョンによって上限が違います（Service Quotas から引き上げ申請は可能）。長文を丸ごと検査に流す設計は、東京では先に上限へぶつかります。guardContent で検査範囲を絞る実装は、料金だけでなくこの上限の面でも効きます。

アプリからの3つの呼び出し方と使い分け

検査の呼び出し方は3系統あり、料金と自由度が違います。使い分けを間違えると、必要のないコストを払い続けることになります。

Converseに紐づけてguardContentで検査範囲を限定

最も一般的なのは推論APIに紐づける方法です。Converse や InvokeModel のリクエストに guardrailConfig を付けると、入力評価と出力評価が自動で挟まります。

import boto3

client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")

response = client.converse(
    modelId="jp.anthropic.claude-sonnet-4-5-20250929-v1:0",
    messages=[{
        "role": "user",
        "content": [
            {"text": "以下の問い合わせに回答してください。"},
            {"guardContent": {"text": {
                "text": "解約手数料はいくらですか",
                "qualifiers": ["guard_content"],
            }}},
        ],
    }],
    guardrailConfig={
        "guardrailIdentifier": "abcd1234efgh",
        "guardrailVersion": "1",
        "trace": "enabled",
    },
)

RAGアプリでは guardContent による範囲指定が重要になります。検索で取得した文書やシステム指示まで検査すると、text unit が膨らんで料金が上がり、東京の入力上限500 text unit にも早く到達します。事故対応マニュアルのように暴力や違法行為の記述を含む社内文書を扱う場合は、文書側が有害判定される可能性もあります。ユーザー入力だけを囲んでください。なおこの範囲指定はSDK経由でのみ可能で、マネジメントコンソールのプレイグラウンドでは使えません。Converse API 自体の実装はAmazon Bedrock Converse APIの使い方｜boto3実装・ConverseStream・Tool Use・IAM権限【2026年最新】で解説しています。

ApplyGuardrailでモデル外の入出力を検査

ApplyGuardrail はモデルを呼ばずに検査だけを行うAPIです。Bedrock 以外のモデル、社内でホストしたOSSモデル、さらには人間が入力したテキストにも同じポリシーを適用できます。

result = client.apply_guardrail(
    guardrailIdentifier="abcd1234efgh",
    guardrailVersion="1",
    source="INPUT",
    outputScope="FULL",
    content=[{"text": {"text": "検査対象のテキスト"}}],
)

print(result["action"])       # GUARDRAIL_INTERVENED など
print(result["assessments"])  # ポリシー別の検知内容

source は INPUT と OUTPUT のいずれかで、評価の観点が変わります。outputScope に FULL を指定すると検知しなかった項目のスコアまで返るため、閾値の当たりを付ける段階で使えます。既定では介入した項目だけが返ります。ただし単語フィルターと機密情報フィルターの正規表現には FULL が効きません。

InvokeGuardrailChecksによるガードレール未作成での検査

2026年6月に追加された InvokeGuardrailChecks は、ガードレールリソースを作らずにチェック内容をリクエストへ直接書く方式です。検査項目はコンテンツフィルター、プロンプト攻撃、機密情報の3つに限られますが、カテゴリ別のスコアと消費 text unit が返ります。

res = client.invoke_guardrail_checks(
    checks={
        "contentFilter": {"categories": [{"category": "HATE"}, {"category": "VIOLENCE"}]},
        "promptAttack": {"categories": [{"category": "PROMPT_INJECTION"},
                                        {"category": "PROMPT_LEAKAGE"}]},
        "sensitiveInformation": {"entities": [{"type": "EMAIL"}]},
    },
    messages=[{"role": "user", "content": [{"text": "検査対象のテキスト"}]}],
)

print(res["results"]["promptAttack"]["results"])  # category と severityScore
print(res["usage"])                               # チェック別の textUnits

カテゴリ名に注意してください。このAPIのプロンプト攻撃は PROMPT_ATTACK ではなく JAILBREAK、PROMPT_INJECTION、PROMPT_LEAKAGE の3値です。CreateGuardrail 側の命名と揃っていないため、既存コードから値をコピーすると実行時に弾かれます。

SDKの対応版にも差があります。InvokeGuardrailChecks が API 定義に入ったのは botocore 1.43.30（2026年6月15日公開）で、1つ前の 1.43.29 には存在しません。手元の SDK が古いと invoke_guardrail_checks 自体が生成されないので、動かないときはまず pip install -U boto3 を実行してください。呼び出し回数の上限は1分あたり1,500リクエストです。

料金計算の実際とコストを下げる順序

課金単位は text unit で、1ユニットは最大1,000文字です。5,600文字の入力なら6ユニットとして計算されます。有効にしたポリシーごとに個別課金され、ティアによる価格差はありません。

単価はいずれも1,000 text unit あたりです。「通常の適用」は Converse、InvokeModel、ApplyGuardrail のいずれから呼んでも同額で、ティアによる差もありません。Automated Reasoning だけはポリシー1件ごとの課金なので、2件紐づければ倍額になります。画像コンテンツのフィルターは1枚あたり0.00075ドルという別体系です。

コストを下げる順序は決まっています。第一に検査範囲を guardContent で絞ること。文脈接地チェックは参照ソース、クエリ、モデル応答の全文字数を合算して課金されるため、RAGで数千文字の検索結果を渡すと1リクエストで数ユニットを消費します。第二に、有害表現とプロンプト攻撃だけで足りる用途なら InvokeGuardrailChecks に寄せること。コンテンツフィルターの単価が0.15ドルから0.07ドルへ下がります。第三に、禁止語の管理を拒否トピック（0.15ドル）ではなく正規表現（無料）へ移せる部分がないか見直すことです。

遮断時の課金ルールも押さえておきます。入力が遮断された場合はガードレールの評価分のみが課金され、モデル推論の料金は発生しません。出力が遮断された場合は、入力と応答の両方の評価に加えて、生成済みのモデル推論分も課金されます。攻撃的な入力を早い段階で止めるほど、モデル側の費用も減る構造です。Bedrock 全体の料金体系はAmazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】で整理しています。

組織全体への強制適用とCloudWatchでの検知

アプリ単位でガードレールを付ける運用は、実装漏れを検知できません。2026年時点の Bedrock には、組織側から強制する仕組みが用意されています。

AWS Organizations経由の組織強制と優先順位

Guardrails enforcements は、AWS Organizations の Bedrock ポリシーを使って、組織全体・OU単位・アカウント単位でガードレールを強制適用する機能です。対象アカウントからのモデル呼び出しはすべて指定ガードレールを通ります。アカウント単位では、そのアカウント内の全呼び出しに特定バージョンを指定できます。

組織側とアプリ側の両方にガードレールがある場合、有効な制御は両者の和集合になり、同じ制御が重複したときは厳しい方が優先されます。開発チームが緩い設定を書いても、組織の設定を下回ることはありません。ただし強制適用に使うガードレールに Automated Reasoning ポリシーを含めてはいけません。公式ドキュメントが非対応と明記しており、実行時エラーになります。マルチアカウント統制の前提はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説を参照してください。

介入回数を追うCloudWatchメトリクス

監視は AWS/Bedrock/Guardrails 名前空間のメトリクスで行います。AWS/Bedrock は bedrock-runtime 側の別名前空間なので、そちらでダッシュボードを組んでもガードレールの数値は取れません。運用で見るべきは InvocationsIntervened（ガードレールが介入した回数）と TextUnitCount（消費 text unit）の2つです。前者は攻撃や誤検知の傾向、後者はコストの実測値になります。

ディメンションでの切り分けが有効です。GuardrailPolicyType は ContentPolicy、TopicPolicy、WordPolicy、SensitiveInformationPolicy、ContextualGroundingPolicy の値を取るため、どのポリシーが何回介入し、いくら消費したかをポリシー単位で分解できます。GuardrailContentSource を使えば入力側と出力側の内訳も出ます。介入が入力側に偏っていれば攻撃、出力側に偏っていればモデルの選定かプロンプトが原因です。ApplyGuardrail の呼び出し自体は CloudTrail のデータイベントにも記録されるため、権限エラーの追跡はそちらで行ってください。

ログ設計では逆方向の注意も要ります。モデル呼び出しログ（CloudWatch Logs／S3）の input フィールドには、ガードレールが介入したかどうかに関わらずマスキング前の元のリクエストがそのまま記録されます。Converse の trace が返す match フィールドも同様で、マスク後の値ではなく元のPII値が入ります。個人情報をマスキングする設定にしていても、ログ側は素通しです。CloudWatch Logs のデータ保護ポリシーなど、ログ側での秘匿を別に用意してください。

AgentCoreゲートウェイでのガードレール適用

2026年6月17日、Amazon Bedrock AgentCore の policy 機能が Bedrock Guardrails に対応し、一般提供されました。提供リージョンは米国東部（バージニア北部）、欧州（ロンドン）、欧州（ストックホルム）、アジアパシフィック（シドニー）、そして東京の5つです。

この統合の要点は、検査の実行場所がエージェントのコードの外側になることです。AgentCore ゲートウェイの境界で、認可された各アクションの出力と、ツール・エージェント・モデルへの各呼び出しの入力が評価されます。エージェントが自律的に振る舞いを変えても、検査は同じように効きます。エージェントのコード内で ApplyGuardrail を呼ぶ実装は、エージェントが別経路でツールを呼び出した瞬間に穴が空きますが、ゲートウェイ側で評価すればその穴は生じません。評価結果は AgentCore のオブザーバビリティに記録され、監査に使えます。

既存の AgentCore ゲートウェイをそのまま使えて新規インフラは不要なので、Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】の構成でエージェントを本番運用しているなら、アプリ内でのガードレール呼び出しはゲートウェイ側へ寄せるべきです。policy の評価は従量課金なので、アプリ側の ApplyGuardrail を残したまま移行すると同じテキストに二重で課金されます。

よくある質問

AWSの「ガードレール」はControl Towerのガードレールと同じものですか？

別物です。AWS Control Tower のガードレールは、マルチアカウント環境に予防的・発見的な統制を効かせる仕組みで、現在は「コントロール」という名称に整理されています。対象はAWSリソースの構成であり、生成AIの入出力ではありません。一方 Amazon Bedrock Guardrails が検査するのはプロンプトとモデル応答のテキストや画像です。アカウント統制の用語はAWS Control Towerの基本用語｜コントロール・ドリフト・OUの意味を整理で確認できます。

日本語の不適切な表現はブロックできますか？

コンテンツフィルターと拒否トピックについては、Standard tier を選べばブロックできます。Classic tier のままだと日本語入力は検査されないため、既存のガードレールを流用するときはティア設定から確認してください。単語フィルターと文脈接地チェックは、ティアに関係なく日本語に対応していません。

Guardrailsだけでプロンプトインジェクションを防げますか？

防ぎ切れません。Prompt Attack カテゴリはジェイルブレイク、プロンプトインジェクション、プロンプトリーケージを検知しますが、確率的な検知である以上すり抜けは残ります。Automated Reasoning チェックには、そもそもプロンプトインジェクションを検知する機能がないと公式が明記しています。ツール実行権限の最小化、出力の宛先制御、ゲートウェイ側での評価を組み合わせた多層防御が前提です。

入力がブロックされた場合も料金は発生しますか？

発生します。ガードレールの評価は、遮断したかどうかに関係なく課金されるためです。ただし入力を遮断した時点でモデル推論は実行されないので、その分の料金はかかりません。逆に出力を遮断した場合は、すでに生成が終わっているためモデル推論分も請求されます。攻撃的な入力を入口で止めるほど総額が下がる、という構造になっています。

Bedrock以外のモデルやオンプレのLLMにも使えますか？

使えます。ApplyGuardrail はモデル呼び出しを伴わない単体の検査APIなので、自社でホストしているモデルの入出力や、他社APIの応答をそのまま渡して評価できます。ガードレールを作らずに検査だけ行いたい場合は InvokeGuardrailChecks という選択肢もあります。ただしいずれも Bedrock のリージョンエンドポイントへの呼び出しなので、検査対象のテキストはAWSへ送信されます。この点は設計時に確認してください。

関連記事

• AIガードレールとは？入力・出力を検査する実装層の設計と選定基準【2026年版】
• Amazon Bedrockの使い方｜料金・モデル・APIの始め方を4ステップで解説【2026年版】
• Amazon Bedrock Converse APIの使い方｜boto3実装・ConverseStream・Tool Use・IAM権限【2026年最新】
• Amazon Bedrock AgentCore APIの使い方｜SDK・CLIでAIエージェントを本番デプロイ【2026年最新】
• chakoshiとは？NTTの日本語LLMガードレールの仕組み・検知項目・API連携【2026年】