Amazon Bedrock 2024-2025新機能本番運用ガイド【Flows/Nova/Evaluations】

1. この記事について

Amazon Bedrock は 2024〜2025 年にかけて Flows・Evaluations・Nova モデル群・Cross-Region Inference・Prompt Caching・Agents メモリといった大型機能を次々と GA リリースしました。本記事ではこれらの新機能を 本番運用の視点 で横断的に解説します。

既存記事（Agents 基礎・Action Group・Guardrails・RAG チャンキング）との棲み分けを明確にし、重複する内容はクロスリンクで参照します。本稿は 2024-2025 新機能特化 の実装ガイドです。

各機能の GA 状況を整理すると、Bedrock Evaluations の LLM-as-Judge / RAG evaluation が 2025-03-20 GA、custom metrics が 2025-04 GA、Nova Premier が 2025 Q1 提供開始、Prompt Caching が 2025-04 GA（Claude 系・Nova 系対応）、Bedrock Agents Memory が 2024-12 preview を経て本番化と、主要機能がほぼ出揃いました。本記事はこれらの機能が実際の本番ワークロードで「組み合わせて使える」状態になったタイミングで、実用的な設計パターンを提供します。

Bedrock の本番導入事例が増えるにつれ、「個別機能は動くが複数機能を組み合わせた設計パターンが分からない」「Evaluations の品質ゲートと Flows の DoWhile を組み合わせるにはどうするか」といった疑問が増えています。本記事はこれらの具体的な組み合わせパターンに正面から答えます。Flows の品質ループ設計（§2）と Evaluations の自動評価（§3）を連携させるパターンや、Nova モデル選定（§4）と Prompt Caching（§5）を組み合わせたコスト最適化の実例を含め、実装レベルで解説します。

1-1. 本記事のゴール

Bedrock の 2024-2025 新機能を個別に試験導入している段階から、複数機能を組み合わせた本番運用へステップアップすることを目標とします。各機能の設定値・制限値・コスト試算の実例を示し、「設定は済んでいるが本番に踏み切れない」という状況を解消します。

本記事を完走した時点で、以下の成果物・状態が手に入ります。

• Bedrock Flows: Condition node の優先順位設計・DoWhile 無限ループ防止の 3 原則・バージョニング管理を本番設計に適用できる
• Bedrock Evaluations: LLM-as-Judge ジョブを CI/CD パイプラインに統合し、プルリクエスト時に自動品質ゲートが実行される
• Nova + CRIS: Micro/Lite/Pro/Premier 選定フローと Geographic/Global CRIS の使い分け基準を自組織の標準として文書化できる
• Prompt Caching: cachePoint の位置設計と CloudWatch によるヒット率モニタリングが設定済みの状態
• Agents Memory: sessionId / memoryId の設計パターンと storageDays の適切な設定値が決まっている
• ガバナンス: Model access SCP 制限・IAM ロール分離・CloudTrail 設定・Cost Anomaly Detection が本番環境に整備されている

1-2. 読者像

この記事は以下のプロフィールの読者を主な対象としています。

• AWS 上で LLM ワークロードを構築・運用している開発者・ML エンジニア
• Bedrock の基本操作（モデル呼び出し・Knowledge Bases・Agents 基礎）は習得済み
• Flows・Evaluations・Nova など 2024-2025 新機能の本番活用方法を探している
• コスト最適化（Prompt Caching・Cross-Region）と品質保証（Evaluations）を同時に進めたい

Bedrock の基礎から学ぶ場合は「既存記事との棲み分け」に記載の関連記事を先に確認してください。本記事は 2024-2025 新機能の本番実装に特化しており、基礎知識（Agents 設定・Action Group・Knowledge Bases 構築）の解説は省略しています。

1-3. なぜ今これを書くか

Bedrock Evaluations (LLM-as-Judge) が 2025-03-20 に GA、Nova Premier が 2025 Q1 に提供開始、Agents Memory が 2024-12 preview → 2025 本番化と、機能の成熟が急速に進んでいます。各機能の公式ドキュメントは充実していますが、複数機能を組み合わせた本番設計パターン を横断的に扱う日本語コンテンツはまだ少ない状況です。本記事はその空白を埋めます。

2024-2025 年の新機能は Bedrock Agents や Knowledge Bases（既存記事で解説済み）とは異なる学習コストが伴います。Flows のビジュアルビルダー・Evaluations のジョブ管理・Prompt Caching の cachePoint 設計など、従来の Bedrock と作法が異なる部分を整理し、本番移行時の「つまずきポイント」を事前に解消することも本記事の目的です。

1-4. 生成 AI 本番運用の 3 大課題と Bedrock 新機能の対応

LLM ワークフローを本番環境へ移行すると、開発フェーズでは顕在化しなかった 3 つの課題が浮かび上がります。Bedrock 2024-2025 新機能はこれらに対する実用的な解決手段を提供します。

課題①: ハルシネーション（事実誤認）の継続的管理

LLM は事実に基づかない回答を生成することがあります。PoC 段階では人手によるサンプリング検査でカバーできていても、本番でのリクエスト数拡大に伴い検査コストが線形増加します。モデルバージョン更新やプロンプト変更のたびに品質劣化が生じる可能性があり、リリースのたびに手動確認する体制は持続不可能です。

RAG システムの場合、ハルシネーションはさらに複雑で、取得したコンテキストを無視して生成する「faithfulness の低下」と、取得自体が不適切な「retrieval の品質問題」の 2 種類に分類されます。それぞれを切り分けて対処しないと、場当たり的なプロンプト改善に陥ります。

Bedrock Evaluations（§3） の LLM-as-Judge は評価対象とは別の judge model が品質を自動判定します。Faithfulness・Correctness・CitationPrecision などのメトリクスでハルシネーションを定量評価し、CI/CD パイプラインの品質ゲートとして組み込むことで、リリースのたびに自動チェックが実行されます。judge model に Nova Micro や Claude Haiku を使用することで評価コストを最大 98% 削減しながら継続的な品質監視が実現します。

課題②: LLM コストの予測困難とスケール時の予算超過

利用量が増えるほどモデル呼び出しコストは比例して増加し、同一のシステムプロンプト・RAG コンテキストを毎回計算し直す非効率が積み重なります。高性能モデルを全ワークロードに適用する設計は、コスト感応性の高い用途ではすぐに予算上限に達します。Provisioned Throughput（PT）を早期に契約してしまい、利用率が低いまま固定費だけ積み上がるケースも多く見られます。

Prompt Caching（§5） は繰り返し利用するプレフィックスをキャッシュし、cache read 時の課金を約 10%（90% 削減）に抑えます。Cross-Region Inference（§4） の Global CRIS はさらに約 10% の入出力トークンコスト削減を実現します。Nova モデル選定（§4） でテキスト専用ワークロードに Nova Micro を適用するなど、用途別モデル最適化も重要です。cachePoint 1 個の追加で Nova Pro の月額コスト試算が約半減した実例があります（§5 参照）。これら 3 手法を組み合わせることで、スケール時のコスト増加を大幅に抑制できます。

課題③: ガバナンスと可観測性の欠如

複数チームが同一 AWS アカウントで Bedrock を利用するようになると、誰がどのモデルを何のために呼び出しているかの把握が難しくなります。モデルバージョンの廃止告知見落としによるサービス断リスク、異常なコスト急増への気づきの遅れも現実の問題です。また、新機能（Flows / Evaluations）の IAM 権限は既存の bedrock:InvokeModel とは異なる権限が必要なため、権限不足によるデプロイ失敗も本番化の障壁になります。

§7 のガバナンス設計 では Model access の SCP 制限・IAM 最小権限ロール分離・CloudTrail + Invocation Logging の 2 層監査・Cost Anomaly Detection による自動アラートを体系的に解説します。これらを本番設計の初期から組み込むことで、後付け対応のコストを大幅に削減できます。特に Flows と Evaluations の実行には bedrock:InvokeFlow・bedrock:CreateEvaluationJob など追加の IAM 権限が必要なため、ロール設計を早期に整備することが重要です。

これら 3 つの課題への対処が、Bedrock 新機能を「試用」から「本番運用」へ昇格させる鍵です。各セクションでは機能の使い方だけでなく、本番特有の制約・コスト試算・チェックリストも含めて解説します。

3 つの課題は独立しておらず、相互に関連しています。Evaluations（課題①）で品質ゲートを設けつつ、Prompt Caching（課題②）でコストを抑え、その両方をガバナンス（課題③）で統合管理するという全体像を意識すると、各機能の位置づけが明確になります。

1-5. この記事の読み進め方（ユースケース別ガイド）

本記事はすべてのセクションを通読することを推奨しますが、優先課題が明確な場合は以下の読み方も有効です。

各セクション末尾の チェックリスト（ep-box） は本番導入時の確認事項をまとめています。実装後のレビュー資料としても活用してください。本番移行前に §8 の「詰まりポイント 7 選」と「アンチパターン→正解 5 選」を確認すると、よくある失敗を事前に回避できます。

コードサンプルはすべて動作確認可能な Python (Boto3) および Terraform で記述しています。AWS アカウントへの適用前に IAM 権限（bedrock:InvokeModel・bedrock-agent:InvokeFlow・bedrock:CreateEvaluationJob 等）が付与されているか確認してください。各機能の対応リージョン・モデル ID・API パラメータは変動するため、実装時に公式ドキュメントを参照する箇所を明示しています。

Bedrock 新機能の仕様変更が速いため、本記事の内容は執筆時点（2025 年）の情報に基づいています。特に Nova Premier の対応リージョン・Prompt Caching の TTL オプション・Agents Memory の storageDays 上限は変動する可能性があります。本番実装前に各機能の公式ドキュメントで最新情報を確認することを強く推奨します。本記事では変動が多い項目に「注意」ブロックを設けて参照先を明示しています。

Bedrock Agents 本番運用ガイドを読む

2. 前提・環境・準備

2-1. 前提環境

• AWS アカウント（Bedrock model access 有効化済み）
• AWS CLI v2 / Boto3 最新版
• 対象リージョン: us-east-1 / ap-northeast-1（本記事の例）
• IAM 権限: bedrock:*・bedrock-agent:*・bedrock-runtime:*

2-2. 使用するサービス・機能

2-3. ゴール状態の定義

本記事を読み終えた時点で、以下の状態が整います。

各機能の「動作確認」の定義は各セクション末尾のチェックリスト（ep-box）を参照してください。

3. Bedrock Flows 本番運用

Bedrock Flows はビジュアルビルダーで Prompts・Agents・Knowledge Bases・Guardrails・Lambda・Lex などを ドラッグ&ドロップで連結し、ノーコードで LLM ワークフローを構築できるサービスです。

3-1. Condition node の設計

Condition node は入力を関係/論理演算子で比較し、条件を順次評価して最初にマッチした分岐へ遷移します。先の条件が優先されるため、より具体的な条件を先に配置 することが設計原則です。

# Condition node 例: 利益判定
条件1: profit > expenses  → 黒字分岐
条件2: profit <= 1000  → 損益分岐
Default → その他分岐

3-2. DoWhile ループの本番設計

DoWhile ループは条件を満たすまで処理を繰り返す反復ノードです。本番運用では 無限ループ防止 が最重要課題です。

本番設計の 3 原則:
1. 明確な exit 条件: 数値比較・フラグ評価など機械的に判定できる条件を設定
2. 測定可能な閾値: ループ回数上限・タイムアウト秒数を明示
3. 相互排他状態: 各分岐が重複しない状態遷移を保証

DoWhile ループの Condition node — exit 条件設計の 3 要素

DoWhile の Condition node には以下の 3 要素を OR 結合で設定することで、必ずループを抜ける設計を保証します。

「品質基準達成 OR 最大回数到達 OR エラー発生」のいずれかで必ずループを終了できます。Condition node の設計において、これら 3 条件のうち 1 つでも欠けると無限ループのリスクが残ります。

Python (Boto3) による Flows 呼び出しと DoWhile 動作確認

import boto3
import json

bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

def invoke_flow(flow_id: str, flow_alias_id: str, input_text: str) -> dict:
 response = bedrock_agent_runtime.invoke_flow(
  flowIdentifier=flow_id,
  flowAliasIdentifier=flow_alias_id,
  inputs=[
{
 'nodeName': 'FlowInputNode',
 'nodeOutputName': 'document',
 'content': {'document': input_text}
}
  ]
 )

 result = {}
 for event in response['responseStream']:
  if 'flowOutputEvent' in event:
output = event['flowOutputEvent']
result['output'] = output.get('content', {}).get('document', '')
  if 'flowCompletionEvent' in event:
result['status'] = event['flowCompletionEvent']['completionReason']

 return result

# DoWhile フロー（コンテンツ反復改善）の呼び出し例
flow_result = invoke_flow(
 flow_id='YOUR_FLOW_ID',
 flow_alias_id='TSTALIASID',
 input_text='このコンテンツの品質を改善してください: ...'
)
print(f"完了状態: {flow_result.get('status')}")
print(f"出力: {flow_result.get('output', '')[:200]}")

DoWhile の代表的ユースケース: 動的コンテンツ精緻化

Prompt ノードで LLM にコンテンツ生成 → Lambda ノードで品質スコア計算 → Condition node でスコア判定 → 閾値未達なら再生成のサイクルを繰り返すパターンです。

設計時の注意点:
– 各イテレーションで前回の出力を次のプロンプトに含めることで改善が積み重なる
– 品質スコアの計算は軽量なルールベースまたは Bedrock Evaluations の軽量 judge（Nova Micro 等）で実施する
– 生成コスト × 最大ループ回数 = 最大課金額として事前見積もりを行う

DoWhile フロー構造（ビジュアルビルダー上）

入力ノード
  ↓
[Prompt ノード: メイン処理 (LLM 呼び出し)]
  ↓
[Lambda ノード: 品質スコア計算]
  ↓
[Condition node: exit 条件評価]
  ├─ exit 条件 TRUE  → 出力ノードへ（ループ終了）
  └─ exit 条件 FALSE → Prompt ノードへ戻る（ループ継続）

Lambda ノードが iteration_count をインクリメントして Condition node に渡す設計が、最も確実な無限ループ防止策です。

3-3. バージョニングと A/B テスト

Flows はバージョニングに対応しており、CreateFlowVersion API で現在の Flow 定義を不変のスナップショットとして保存できます。バージョンごとに Alias を設定し、アプリケーションコードを変更せずに本番 Alias を切り替えることで、ロールバック・A/B テストが実現します。

バージョン作成とエイリアス切り替え（Boto3）

import boto3

bedrock_agent = boto3.client('bedrock-agent', region_name='us-east-1')

# 現在の Flow 定義をバージョンとして保存
create_ver_resp = bedrock_agent.create_flow_version(
 flowIdentifier='YOUR_FLOW_ID',
 description='プロンプト v2.0 — Condition node の exit 条件を最適化'
)
version_id = create_ver_resp['id']
print(f"バージョン作成: {version_id}")

# 本番エイリアスを新バージョンに向ける（本番切り替え）
bedrock_agent.update_flow_alias(
 flowIdentifier='YOUR_FLOW_ID',
 aliasIdentifier='YOUR_ALIAS_ID',
 name='production',
 description='本番エイリアス',
 routingConfiguration=[
  {'flowVersion': version_id}
 ]
)
print("本番エイリアスを新バージョンに切り替えました")

A/B テストの設定（トラフィック分割）

Alias のルーティング設定でトラフィックを複数バージョンに分割できます。

# 旧バージョン 70%・新バージョン 30% の A/B テスト
bedrock_agent.update_flow_alias(
 flowIdentifier='YOUR_FLOW_ID',
 aliasIdentifier='YOUR_ALIAS_ID',
 name='production-ab-test',
 description='A/B テスト: v1.0(70%) vs v2.0(30%)',
 routingConfiguration=[
  {'flowVersion': 'VERSION_V1_ID', 'flowVersionWeight': 0.7},
  {'flowVersion': 'VERSION_V2_ID', 'flowVersionWeight': 0.3},
 ]
)

A/B テストの実施期間は 1〜2 週間を目安とし、Bedrock Evaluations で両バージョンの品質スコアを比較してから全量切り替えを判断します。Flows の A/B テストはエイリアスの設定変更のみで完了するため、インフラ（EC2・Lambda のデプロイ）は不要です。

ロールバック手順

本番障害時は安定バージョンの ID を確認し、エイリアスを差し戻すだけです。

# ロールバック: 前の安定バージョンに戻す
bedrock_agent.update_flow_alias(
 flowIdentifier='YOUR_FLOW_ID',
 aliasIdentifier='YOUR_ALIAS_ID',
 name='production',
 description='ロールバック済み',
 routingConfiguration=[
  {'flowVersion': 'STABLE_VERSION_ID'}
 ]
)

バージョン管理のベストプラクティス

• 各バージョンの description に変更内容を詳細に記録する（Git コミットメッセージと同様の運用）
• 本番適用前に staging 環境の別エイリアスで同一バージョンをテストする
• A/B テストの品質比較には Bedrock Evaluations の Correctness / Helpfulness を活用する（§3 参照）
• 古いバージョンは定期的に削除してコストを抑える

3-4. Terraform / CDK 実装例

Flows の本番展開はコンソール手動作業ではなく IaC（Infrastructure as Code）で管理します。環境差分の排除・コードレビュー・CI/CD による自動適用が実現し、ヒューマンエラーによる設定ミスを防止できます。

Terraform による Bedrock Flows 管理

# main.tf — Bedrock Flows と IAM ロールの Terraform 実装
terraform {
  required_providers {
 aws = {
source  = "hashicorp/aws"
version = ">= 5.50.0"
 }
  }
}

provider "aws" {
  region = "us-east-1"
}

# Flows 実行用 IAM ロール
resource "aws_iam_role" "bedrock_flows_role" {
  name = "bedrock-flows-execution-role"

  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "bedrock.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy" "bedrock_flows_policy" {
  name = "bedrock-flows-invoke-policy"
  role = aws_iam_role.bedrock_flows_role.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect= "Allow"
Action= ["bedrock:InvokeModel"]
Resource = [
  "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0",
  "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-lite-v1:0"
]
 }]
  })
}

# Bedrock Flow 定義
resource "aws_bedrockagent_flow" "content_refinement_flow" {
  name  = "content-refinement-dowhile"
  description = "DoWhile ループで品質を反復改善する Flow"
  role_arn = aws_iam_role.bedrock_flows_role.arn

  definition = jsonencode({
 nodes = [
{
  name = "FlowInputNode"
  type = "Input"
  outputs = [{ name = "document", type = "String" }]
},
{
  name = "PromptNode"
  type = "Prompt"
  configuration = {
 prompt = {
sourceConfiguration = {
  inline = {
 modelId= "amazon.nova-pro-v1:0"
 templateType = "TEXT"
 templateConfiguration = {
text = {
  text = "次のコンテンツの品質を改善してください:\n\n{{document}}\n\n改善されたコンテンツを出力してください。"
}
 }
  }
}
 }
  }
  inputs  = [{ name = "document", type = "String", expression = "$.data" }]
  outputs = [{ name = "modelCompletion", type = "String" }]
},
{
  name = "ConditionNode"
  type = "Condition"
  configuration = {
 condition = {
conditions = [
  {
 name = "ExitCondition"
 expression = "$.data.iteration >= 3"
  }
]
 }
  }
  inputs  = [{ name = "iteration", type = "Number", expression = "$.data" }]
  outputs = [{ name = "ExitCondition", type = "Boolean" }]
},
{
  name= "FlowOutputNode"
  type= "Output"
  inputs = [{ name = "document", type = "String", expression = "$.data" }]
}
 ]
 connections = [
{
  name= "input-to-prompt"
  source = "FlowInputNode"
  target = "PromptNode"
  type= "Data"
  configuration = {
 data = {
sourceOutput = "document"
targetInput  = "document"
 }
  }
},
{
  name= "prompt-to-condition"
  source = "PromptNode"
  target = "ConditionNode"
  type= "Data"
  configuration = {
 data = {
sourceOutput = "modelCompletion"
targetInput  = "iteration"
 }
  }
},
{
  name = "condition-exit-to-output"
  source  = "ConditionNode"
  target  = "FlowOutputNode"
  type = "Conditional"
  configuration = {
 conditional = { condition = "ExitCondition" }
  }
}
 ]
  })
}

# バージョン管理
resource "aws_bedrockagent_flow_version" "v1" {
  flow_id  = aws_bedrockagent_flow.content_refinement_flow.id
  description = "初期本番バージョン"
}

# 本番エイリアス
resource "aws_bedrockagent_flow_alias" "production" {
  flow_id  = aws_bedrockagent_flow.content_refinement_flow.id
  name  = "production"
  description = "本番用エイリアス"

  routing_configuration {
 flow_version = aws_bedrockagent_flow_version.v1.id
  }
}

注意: aws_bedrockagent_flow リソースの definition スキーマは AWS Provider バージョンによって変動します。実装前に Terraform Registry: aws_bedrockagent_flow で最新スキーマを確認してください。

AWS CDK (Python) による実装

CDK で Flows を管理する場合は CfnFlow（L1 Construct）を使用します。

from aws_cdk import Stack, aws_iam as iam
from aws_cdk import aws_bedrock as bedrock
from constructs import Construct

class BedrockFlowsStack(Stack):
 def __init__(self, scope: Construct, construct_id: str, **kwargs):
  super().__init__(scope, construct_id, **kwargs)

  flows_role = iam.Role(
self, 'BedrockFlowsRole',
assumed_by=iam.ServicePrincipal('bedrock.amazonaws.com'),
inline_policies={
 'BedrockInvoke': iam.PolicyDocument(
  statements=[
iam.PolicyStatement(
 actions=['bedrock:InvokeModel'],
 resources=[
  'arn:aws:bedrock:*::foundation-model/amazon.nova-pro-v1:0'
 ],
)
  ]
 )
}
  )

  # L2 Construct (aws_bedrock) の実装状況は変動します
  # L1 Construct (CfnFlow) を使用する場合は以下を参照
  flow = bedrock.CfnFlow(
self, 'ContentRefinementFlow',
name='content-refinement-dowhile',
execution_role_arn=flows_role.role_arn,
description='DoWhile ループで品質を反復改善する Flow',
# definition は CloudFormation スキーマに従い設定
  )

注意: CDK の aws_bedrock L2 Construct の Flows サポート状況は変動します。実装前に CDK API Reference: aws-cdk-lib.aws_bedrock で確認してください。L2 未実装の場合は CfnFlow（L1）を使用します。

3-5. Flows 対応ノード一覧と使い分け

Bedrock Flows で使用できるノード種別と本番での推奨用途を整理します。

設計指針:

• Prompt → Condition → Prompt の構造で DoWhile ループを実現する
• Knowledge Base → Prompt の連結で RAG フローを Flows 上で視覚化する
• Iterator → [Prompt × N] → Collector でドキュメントリストの並列変換を実現する
• Lambda は外部 API 呼び出しやスコア計算など Flows ネイティブでは難しい処理に限定する（Lambda を多用すると Flows の可視性メリットが薄れる）
• Flows が価値を発揮するのは「複数ノードのオーケストレーション + 条件分岐 + ループ」が必要なケース。シンプルな Lambda → Prompt → 結果返却の 3 ステップには Flows を使わず Lambda 直接呼び出しを検討する

3-6. Flows 本番運用チェックリスト

4. Bedrock Evaluations — LLM-as-Judge & RAG 品質評価

2025年3月20日、Amazon Bedrock Evaluations の LLM-as-a-Judge と RAG evaluation が GA しました。評価ジョブ自体は追加課金なし（使用した推論トークン分のみ課金）で実行でき、小型の judge model を活用することで最大 98% のコスト削減が可能です。本節では評価設計から CI/CD 統合まで、本番で即使えるパターンを解説します。

4-1. LLM-as-Judge の基本設計

LLM-as-Judge は人間によるアノテーションを LLM が代替する評価手法です。Bedrock Evaluations では評価対象モデル（被評価）とは別に judge model を 1 つ以上指定します。Bedrock で利用可能なモデル（Claude・Nova 等）を judge として指定でき、複数 judge の多数決で評価精度を向上させることもできます。

評価ジョブの作成（Python / Boto3）

import boto3

bedrock = boto3.client('bedrock', region_name='us-east-1')

response = bedrock.create_evaluation_job(
 jobName='rag-quality-eval-2025',
 roleArn='arn:aws:iam::111122223333:role/BedrockEvalRole',
 applicationType='ModelEvaluation',
 evaluationConfig={
  'automated': {
'datasetMetricConfigs': [
 {
  'taskType': 'QuestionAndAnswer',
  'dataset': {
'name': 'eval-dataset-v1',
's3Uri': 's3://my-eval-bucket/datasets/'
  },
  'metricNames': [
'Builtin.Correctness',
'Builtin.Completeness',
'Builtin.Faithfulness',
  ]
 }
]
  }
 },
 inferenceConfig={
  'models': [
{
 'bedrockModel': {
  'modelIdentifier': 'anthropic.claude-sonnet-4-5',
  'inferenceParams': '{"maxTokens": 1024, "temperature": 0}'
 }
}
  ]
 },
 outputDataConfig={
  's3Uri': 's3://my-eval-bucket/results/'
 }
)
print('Job ARN:', response['jobArn'])

Bring-Your-Own-Inference（BYOI）

Bedrock 上のモデルだけでなく、外部の RAG パイプラインやカスタムエンドポイントも評価対象にできます。既存の推論基盤を変更せずに評価を追加できるため、段階的な品質保証体制の構築に適しています。

# BYOI: 外部 RAG パイプラインを評価対象に指定
inferenceConfig={
 'externalSources': [
  {
'externalSourcesConfig': {
 'byoEndpoint': {
  'endpointUrl': 'https://your-rag-endpoint.example.com/invoke'
 }
}
  }
 ]
}

judge model のコスト戦略

judge model に小型モデルを使用することでコストを大幅削減できます。評価ジョブ自体は追加課金なし（推論トークン分のみ）なので、judge の選択がコストを左右します。

4-2. 評価メトリクス 4 領域

Bedrock Evaluations は 4 つの評価領域にわたる組み込みメトリクスを提供します。

品質メトリクス

UX メトリクス

指示遵守メトリクス

ユーザーが与えた制約（フォーマット・語調・文字数・箇条書き指定など）に従っているかを評価します。プロンプトで「3 点で箇条書き」と指定した場合に実際に 3 点で返しているかを自動判定します。プロダクション環境で出力フォーマットの一貫性が重要なケース（API レスポンスの JSON 生成など）に特に有効です。

安全性メトリクス

4-3. RAG evaluation の実践

RAG パイプライン固有のメトリクスは retrieval 品質 と end-to-end 品質 の 2 段階で評価します。段階を分けることで「取得が悪いのか、生成が悪いのか」を切り分けられます。

Retrieval メトリクス

End-to-End メトリクス

RAG パイプライン全体（取得 → 生成）の品質を評価します。Correctness / Completeness / Faithfulness の 3 メトリクスが end-to-end で適用されます。End-to-End の Faithfulness が低い場合は、取得したコンテキストを無視して生成している（ハルシネーション）可能性があります。

Citation メトリクス（2025-03 追加）

RAG のハルシネーションは Faithfulness + Citation Precision の組み合わせで最も正確に検出できます。「引用はあるが根拠と主張が食い違う」というケースは Citation Precision のみで検出可能です。

# RAG 評価ジョブのメトリクス設定例（フル構成）
'metricNames': [
 'Builtin.Correctness',
 'Builtin.Faithfulness',
 'Builtin.ContextRelevance',
 'Builtin.ContextCoverage',
 'Builtin.CitationCoverage',
 'Builtin.CitationPrecision',
]

4-4. Custom Metrics — 2025-04 GA

2025年4月に custom metrics が GA し、自前の judge prompt を使って独自の評価軸を定義できるようになりました。

スケール種別

• Categorical: PASS / FAIL や LOW / MEDIUM / HIGH などの離散ラベルで判定
• Numerical: 1〜5 のような数値スコアで評価（平均・分布分析に使いやすい）

Custom metrics 定義例（JSON 設定）

{
  "customMetrics": [
 {
"name": "TechnicalAccuracy",
"description": "AWS技術的正確性の評価",
"ratingScale": "NUMERICAL",
"judgeModelIdentifier": "anthropic.claude-sonnet-4-5",
"judgePromptTemplate": "あなたはAWSの専門家です。次の回答の技術的正確性を1（不正確）から5（完全に正確）で評価してください。\n\n質問: {{prompt}}\n回答: {{response}}\n\n評点（数字のみ）:"
 },
 {
"name": "ToneCompliance",
"description": "ブランドトーンガイドライン準拠チェック",
"ratingScale": "CATEGORICAL",
"categories": ["COMPLIANT", "PARTIALLY_COMPLIANT", "NON_COMPLIANT"],
"judgeModelIdentifier": "amazon.nova-lite-v1:0",
"judgePromptTemplate": "次の回答がブランドトーン（丁寧・専門的・具体的）に準拠しているか判定してください。\n\n回答: {{response}}\n\n判定（COMPLIANT / PARTIALLY_COMPLIANT / NON_COMPLIANT のいずれか）:"
 }
  ]
}

Custom metrics の活用場面

• ドメイン固有の専門知識チェック（医療・法律・金融など）
• 自社スタイルガイド・ブランドトーンへの準拠確認
• A/B モデル比較：独自採点基準でモデル切り替えの意思決定を行う

4-5. CI/CD への組み込み

本番品質保証の核心は 評価の自動化 です。モデル更新・プロンプト変更・Knowledge Base 更新のたびに評価を自動実行し、品質劣化をプルリクエストの段階で検出します。

GitHub Actions による自動評価パイプライン

# .github/workflows/bedrock-eval.yml
name: Bedrock Evaluation Gate

on:
  pull_request:
 paths:
- 'prompts/**'
- 'knowledge_base/**'
- 'models/**'

jobs:
  evaluate:
 runs-on: ubuntu-latest
 permissions:
id-token: write
contents: read

 steps:
- uses: actions/checkout@v4

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
 role-to-assume: ${{ secrets.AWS_EVAL_ROLE_ARN }}
 aws-region: us-east-1

- name: Setup Python
  uses: actions/setup-python@v5
  with:
 python-version: '3.12'

- name: Install dependencies
  run: pip install boto3

- name: Run Bedrock Evaluation Job
  run: |
 python scripts/run_evaluation.py \
--dataset s3://my-eval-bucket/datasets/latest.jsonl \
--output-prefix s3://my-eval-bucket/results/${{ github.sha }}/

- name: Check Quality Gate
  run: |
 python scripts/check_eval_threshold.py \
--results-prefix s3://my-eval-bucket/results/${{ github.sha }}/ \
--min-correctness 0.80 \
--min-faithfulness 0.85 \
--fail-on-miss

評価ジョブのポーリングと閾値チェック

import boto3
import time

def run_and_wait(bedrock_client, job_config: dict, timeout_sec: int = 1800) -> dict:
 resp = bedrock_client.create_evaluation_job(**job_config)
 job_arn = resp['jobArn']

 deadline = time.time() + timeout_sec
 while time.time() < deadline:
  status = bedrock_client.get_evaluation_job(jobIdentifier=job_arn)
  if status['status'] == 'Completed':
return status
  if status['status'] in ('Failed', 'Stopped'):
raise RuntimeError(f"Evaluation job {status['status']}: {job_arn}")
  time.sleep(30)

 raise TimeoutError(f"Job did not complete within {timeout_sec}s")

def assert_thresholds(results: dict, thresholds: dict) -> None:
 failures = []
 for metric, min_score in thresholds.items():
  actual = results['evaluationResults'].get(metric, {}).get('score', 0)
  if actual < min_score:
failures.append(f"{metric}: {actual:.3f} < {min_score}")
 if failures:
  raise AssertionError("Quality gate failed:\n" + "\n".join(failures))

評価コスト最適化

評価ジョブ自体は追加課金なし（推論トークンのみ課金）なので、judge model の選択がコストを直接左右します。

5. Nova モデル選定 + Cross-Region Inference

Amazon Nova は Bedrock で利用できる Amazon 独自の基盤モデルファミリーです。Micro・Lite・Pro・Premier の 4 モデルがコスト・性能・マルチモーダル対応の軸で明確に差別化されており、用途に合わせて選択することで大幅なコスト最適化が可能です。本節では各モデルの特性と Cross-Region Inference（CRIS）を組み合わせた本番設計パターンを解説します。

5-1. Nova モデル 4 種の特性と選定

モデル比較一覧

全 Nova モデルは文書・チャート・画像・動画の理解、multi-turn 会話・RAG・agentic workflow に対応しています。

Nova Micro — 高頻度テキスト処理に最適

テキストのみのモデルで、Nova 4 モデル中最低のレイテンシと最低コストを実現します。コスト感応性の高いユースケース（分類・短文生成・大量バッチ処理）に適しています。画像・動画を使わない純テキストのワークロードであれば Nova Micro が第一候補です。

import boto3
import json

bedrock_rt = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock_rt.invoke_model(
 modelId='amazon.nova-micro-v1:0',
 body=json.dumps({
  'messages': [
{
 'role': 'user',
 'content': [
  {'text': '次のテキストをポジティブ/ネガティブ/ニュートラルに分類してください: 商品は期待通りでした。'}
 ]
}
  ],
  'inferenceConfig': {
'maxTokens': 50,
'temperature': 0
  }
 })
)
result = json.loads(response['body'].read())
print(result['output']['message']['content'][0]['text'])

Nova Lite — コスト効率の高いマルチモーダル処理

画像・動画・テキストを低コストで処理できるマルチモーダルモデルです。画像解析・動画サムネイル分析・文書 OCR といった軽量マルチモーダルタスクに適しています。Nova Pro より安価でありながら基本的なマルチモーダルタスクを十分にこなせるため、コスト重視の multimodal ワークロードの第一選択です。

Nova Pro — 複雑なマルチモーダルタスクの主力

精度・速度・コストのバランスが最も優れたモデルです。複雑な推論・長文生成・高精度なマルチモーダル分析が必要な本番ワークロードの主力として設計されています。Nova Lite で品質が不足する場面で Nova Pro に昇格させるというアプローチが効果的です。

Nova Premier — 最高精度と Distillation Teacher

Nova ファミリー最高性能のモデルで、2025 Q1 に提供が開始されました。複雑なタスクや高い精度が求められる場面に加え、distillation teacher としての役割も持ちます。Nova Premier で生成した高品質な出力を使って Nova Lite / Micro を fine-tuning（知識蒸留）することで、低コストモデルの精度を向上させることができます。

5-2. モデル選定判断フロー

用途の判定
│
├─ テキストのみ（分類・要約・バッチ処理）
│└─ Nova Micro（最低コスト・最低レイテンシ）
│
├─ 画像・動画・文書を含む
│├─ 軽量解析（OCR・サムネイル・簡易分類）
││└─ Nova Lite（低コスト multimodal）
││
│└─ 複雑な推論・高精度要件
│ ├─ バランス重視  → Nova Pro
│ └─ 最高精度 / distillation teacher  → Nova Premier
│
└─ コスト削減オプション
 ├─ Prompt Caching 併用（§5 参照: 最大 90% コスト削減）
 └─ CRIS 併用（global CRIS で約 10% 削減）

マルチモーダル入力例（Nova Lite）

import base64

# 画像ファイルを base64 エンコード
with open('product-image.jpg', 'rb') as f:
 image_b64 = base64.b64encode(f.read()).decode()

response = bedrock_rt.invoke_model(
 modelId='amazon.nova-lite-v1:0',
 body=json.dumps({
  'messages': [
{
 'role': 'user',
 'content': [
  {
'image': {
 'format': 'jpeg',
 'source': {'bytes': image_b64}
}
  },
  {
'text': 'この商品画像のカテゴリと特徴を JSON で出力してください。'
  }
 ]
}
  ],
  'inferenceConfig': {'maxTokens': 512, 'temperature': 0}
 })
)
result = json.loads(response['body'].read())
print(result['output']['message']['content'][0]['text'])

5-3. Cross-Region Inference（CRIS）の 2 種

Bedrock の Cross-Region Inference は geographic と global の 2 種類があり、データレジデンシ要件とコスト要件に応じて使い分けます。

Geographic CRIS — データレジデンシ対応

地理的境界（US / EU / Australia / Japan 等）の内部で最適なリージョンへ自動ルーティングします。データが指定した地域内に留まるため、個人情報保護規制への準拠が必要なワークロードに適しています。

Japan CRIS は東京・大阪間でルーティングされ、データが日本国内に留まります。

Global CRIS — 高スループット・コスト最適化

20 以上の source リージョンから商用リージョン全体へルーティングします。geographic CRIS より 約 10% 入出力トークンコストが安く（Claude Sonnet 4.5 の場合）、高スループットが求められるワークロードやデータレジデンシ制約がない場面に有効です。

CRIS 比較

重要: 最新の対応モデル・リージョン一覧は inference-profiles-support.html を執筆時・設計時に必ず確認してください。対応モデルは継続的に追加されています。

5-4. CRIS の設定と使用

CRIS は通常の Bedrock 呼び出しとほぼ同じ形で使用できます。モデル ID の代わりに クロスリージョン推論プロファイル ID を指定するだけです。

Japan Geographic CRIS の設定例（Nova Pro）

import boto3
import json

# Japan geographic CRIS（Tokyo/Osaka 間ルーティング）
bedrock_rt = boto3.client('bedrock-runtime', region_name='ap-northeast-1')

# クロスリージョン推論プロファイル ID
# 実際の ID は AWS Console または inference-profiles-support.html で確認してください
cris_profile_id = 'apac.amazon.nova-pro-v1:0'

response = bedrock_rt.invoke_model(
 modelId=cris_profile_id,
 body=json.dumps({
  'messages': [
{
 'role': 'user',
 'content': [
  {'text': 'サーバーレスアーキテクチャの主なメリットを 3 点教えてください。'}
 ]
}
  ],
  'inferenceConfig': {
'maxTokens': 512,
'temperature': 0.7
  }
 })
)
result = json.loads(response['body'].read())
print(result['output']['message']['content'][0]['text'])

Global CRIS でのコスト最適化（Nova Pro）

# Global CRIS（約 10% コスト削減・高スループット向け）
bedrock_rt_global = boto3.client('bedrock-runtime', region_name='us-east-1')

# Global CRIS プロファイル ID（実際の ID はドキュメントで確認）
global_profile_id = 'us.amazon.nova-pro-v1:0'

response = bedrock_rt_global.invoke_model(
 modelId=global_profile_id,
 body=json.dumps({
  'messages': [
{
 'role': 'user',
 'content': [
  {'text': 'Summarize the key benefits of serverless architecture in 3 points.'}
 ]
}
  ],
  'inferenceConfig': {'maxTokens': 512}
 })
)
result = json.loads(response['body'].read())
print(result['output']['message']['content'][0]['text'])

5-5. データレジデンシ設計

CRIS を本番環境で使用する際の要件別の選択基準を整理します。

要件別の CRIS 選択

Nova + CRIS のコスト積算例

Nova Pro を Japan CRIS で使用している場合、§5 で解説する Prompt Caching と組み合わせることでさらにコスト削減できます。cachePoint 1 個追加で Nova Pro の月額コストが約半減した実例があります（§5 参照）。CRIS の約 10% 削減と Prompt Caching の最大 90% 削減を組み合わせることで、高スループットワークロードでの大幅なコスト最適化が実現できます。

注意: コストは変動するため、本番設計前に Bedrock pricing ページ で最新値を確認してください。

5-6. Nova Premier の知識蒸留（Distillation）パターン

Nova Premier は distillation teacher として機能し、Nova Micro / Lite / Pro の精度向上に活用できます。Nova Premier で生成した高品質な応答をデータセットとして収集し、小型モデルの fine-tuning に使用することで、低コストモデルで高精度な応答を実現します。

蒸留データ収集の基本フロー

import boto3
import json
import jsonlines  # pip install jsonlines

bedrock_rt = boto3.client('bedrock-runtime', region_name='us-east-1')

def collect_distillation_samples(prompts: list, output_path: str) -> None:
 samples = []
 for prompt in prompts:
  resp = bedrock_rt.invoke_model(
modelId='amazon.nova-premier-v1:0',
body=json.dumps({
 'messages': [{'role': 'user', 'content': [{'text': prompt}]}],
 'inferenceConfig': {'maxTokens': 1024, 'temperature': 0}
})
  )
  result = json.loads(resp['body'].read())
  answer = result['output']['message']['content'][0]['text']
  samples.append({'prompt': prompt, 'completion': answer})

 with jsonlines.open(output_path, mode='w') as writer:
  writer.write_all(samples)

# 収集したサンプルを S3 にアップロードして fine-tuning ジョブへ

蒸留の費用対効果

Nova Premier で収集したデータで Nova Micro を fine-tuning することで、推論コストを大幅削減しながら特定ドメインの精度を維持できます。

6. Prompt Caching + Provisioned Throughput 最適化

Prompt Caching は 2025-04 に GA した機能で、繰り返し利用するプレフィックス（システムプロンプト・RAG コンテキスト・Few-shot 例など）をキャッシュし、最大 90% のコスト削減・最大 85% のレイテンシ削減 を実現します。LLM コストの大半を占める「毎回同じプレフィックスを再計算する非効率」を排除する、本番運用における最重要コスト最適化手法のひとつです。

6-1. Prompt Caching の仕組みと cachePoint

Prompt Caching では cachePoint (checkpoint) でプレフィックスをマークします。cachePoint より前のトークン列をキャッシュし、次の呼び出しで同一プレフィックスが検出されるとキャッシュヒットが発生します。

呼び出し1:
  [システムプロンプト + RAGコンテキスト] ← cachePoint ← cache write（通常より高め）
  [ユーザー入力: 50 トークン]
  → cachePoint 前のトークンは cache write 課金

呼び出し2 (TTL 内・同一プレフィックス):
  [システムプロンプト + RAGコンテキスト] ← cachePoint ← cache read（ヒット）
  [ユーザー入力: 50 トークン]
  → キャッシュ部分は約 10% 課金（90% 削減）

キャッシュヒットの 3 条件:
1. 同一プレフィックス: cachePoint より前のトークン列が完全一致していること
2. TTL 内: 前回呼び出しから TTL（5 分または 1 時間）以内であること
3. 同一モデル: モデルバージョンが変わるとキャッシュは無効化される

cachePoint の配置原則は「変わらない部分と変わる部分の境界」です。システムプロンプトや RAG コンテキストなど固定されたプレフィックスの末尾に置きます。

基本的な Python 実装:

import boto3

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

response = client.converse(
 modelId='amazon.nova-pro-v1:0',
 messages=[
  {
"role": "user",
"content": [
 {
  "text": system_context + "\n\n" + rag_document,
 },
 {
  "cachePoint": {"type": "default"},
 },
 {
  "text": user_question,
 }
],
  }
 ],
)

cachePoint ブロックをキャッシュしたいコンテンツブロックの直後に置くだけで有効化されます。

6-2. TTL の種類と使い分け

TTL = 5 分: チャットボットや API リアルタイム応答など、ユーザーが短い間隔で連続して問い合わせるユースケースに最適です。TTL 内に次のリクエストが来なければキャッシュは自動削除されます。

TTL = 1 時間: Claude 4.5 系のみ選択可能な拡張オプションです。ドキュメント要約バッチ・数時間かけて処理するデータパイプラインなど、リクエスト間隔が 5 分を超えるワークロードで効果を発揮します。

# TTL 1 時間を指定（Claude 4.5 系のみ）
{
 "cachePoint": {
  "type": "default",
  "ttl": 3600
 }
}

注意: TTL オプションの可否・設定方法はモデルバージョンによって異なります。実装前に prompt-caching.html で最新仕様を確認してください。

6-3. 対応モデルとキャッシュ制限値

Nova の最小トークン制限（1024）: Nova は 1024 トークン未満のプレフィックスにはキャッシュが適用されません。短いシステムプロンプトのみのキャッシュ狙いは効果がありません。RAG コンテキストや Few-shot 例を合わせてプレフィックスに含め、1024 トークン超えを確保する設計が必要です。

複数 cachePoint の活用（最大 4 個）:

# 3 段階の cachePoint 設計例（Nova Pro）
messages = [
 {
  "role": "user",
  "content": [
{"text": system_prompt},
{"cachePoint": {"type": "default"}}, # cachePoint 1
{"text": rag_context},
{"cachePoint": {"type": "default"}}, # cachePoint 2
{"text": few_shot_examples},
{"cachePoint": {"type": "default"}}, # cachePoint 3
{"text": user_question}, # 毎回変わる部分
  ]
 }
]

変更頻度の異なるコンテンツを段階的にキャッシュすることで、部分的なキャッシュヒットも活用できます。

6-4. 課金モデルの詳細

キャッシュミスが連続するとコストが増加する: cache write のたびに通常より高い課金が発生します。プレフィックスが毎回変わる設計だと「cache write ばかりで read がゼロ」という最悪パターンになります。ヒット率の監視は必須です。

CloudWatch でヒット率を監視:

import boto3
import datetime

cw = boto3.client('cloudwatch', region_name='us-east-1')

response = cw.get_metric_statistics(
 Namespace='AWS/Bedrock',
 MetricName='CacheReadInputTokenCount',
 Dimensions=[{'Name': 'ModelId', 'Value': 'amazon.nova-pro-v1:0'}],
 StartTime=datetime.datetime.utcnow() - datetime.timedelta(hours=24),
 EndTime=datetime.datetime.utcnow(),
 Period=3600,
 Statistics=['Sum'],
)
print(response['Datapoints'])

CacheReadInputTokenCount と CacheWriteInputTokenCount の比率を定期的に確認し、ヒット率が低い場合はプレフィックス設計を見直します。

注意: 具体的な課金単価は aws.amazon.com/bedrock/pricing/ で確認してください。料金は変動します。

6-5. Nova Pro 月額コスト半減の実例

cachePoint 1 個を追加するだけで Nova Pro の月額コスト試算が 約半減 した実例があります。

構成概要:
– ワークロード: 社内ドキュメント Q&A チャットボット
– 固定プレフィックス: システムプロンプト + FAQ コンテキスト 約 8000 トークン（Nova 20k 上限以内）
– 1 日のリクエスト数: 数百件（バースト型・TTL 5 分以内に連続リクエスト多数）

cachePoint 追加前は毎リクエストで 8000 トークンの推論コストが発生していました。cachePoint 追加後はリクエストの大半がキャッシュヒットとなり、8000 トークン分が約 10% の課金（90% 削減）となったことで月額コストが大幅に削減されました。

キャッシュヒット率を高める 4 原則:

1. プレフィックスの固定化: システムプロンプトや RAG コンテキストをセッション内で変更しない
2. cachePoint の位置を変えない: 毎回同じ位置に cachePoint を置く（位置が変わるとキャッシュ無効）
3. TTL を超えない呼び出し間隔設計: TTL 5 分を超える間隔しかないなら 1 時間 TTL（Claude 4.5 系）を検討
4. Nova 1024 トークン制限の回避: RAG コンテキストを追加して制限を超えるよう設計

6-6. Provisioned Throughput との使い分け

Prompt Caching でコストを削減しつつ、スパイクトラフィックでスロットリングが発生するケースでは Provisioned Throughput (PT) の検討が必要です。

PT 移行の判断フロー:

① 月間リクエスト数 × トークン数 → On-Demand 月額コスト算出
↓
② 必要モデルユニット数 × PT 時間単価 × 720 時間 → PT 月額コスト算出
↓
③ On-Demand < PT → On-Demand 継続 + Prompt Caching 最大化
On-Demand ≧ PT かつスループット保証が必要 → PT 移行を検討
On-Demand ≧ PT かつスループット保証が不要 → Prompt Caching 強化でOn-Demand維持

PT 契約後も Prompt Caching を有効化することで、モデルユニットあたりの処理リクエスト数を高め、固定コスト（PT）と推論コストの両方を最適化できます。

注意: PT の対応モデル・料金体系は変動します。本番導入前に aws.amazon.com/bedrock/pricing/ の Provisioned Throughput セクションで最新情報を確認してください。

6-7. よくあるキャッシュ設計のミス

6-8. ヒット率モニタリングと継続改善

Prompt Caching の効果は設定後も CacheReadInputTokenCount と CacheWriteInputTokenCount を継続監視して確認します。設定しただけで安心せず、実際にキャッシュが機能しているかをメトリクスで追跡することが本番運用の基本です。

CloudWatch でヒット率を算出する Python スニペット:

import boto3, datetime

def get_cache_hit_rate(model_id: str, hours: int = 24) -> float:
 cw = boto3.client('cloudwatch', region_name='us-east-1')
 end = datetime.datetime.utcnow()
 start = end - datetime.timedelta(hours=hours)
 dims = [{'Name': 'ModelId', 'Value': model_id}]

 def fetch(metric: str) -> float:
  resp = cw.get_metric_statistics(
Namespace='AWS/Bedrock',
MetricName=metric,
Dimensions=dims,
StartTime=start,
EndTime=end,
Period=hours * 3600,
Statistics=['Sum'],
  )
  pts = resp.get('Datapoints', [])
  return pts[0]['Sum'] if pts else 0.0

 reads = fetch('CacheReadInputTokenCount')
 writes = fetch('CacheWriteInputTokenCount')
 total = reads + writes
 return reads / total if total > 0 else 0.0

hit_rate = get_cache_hit_rate('amazon.nova-pro-v1:0')
print(f"Cache hit rate (last 24h): {hit_rate:.1%}")

ヒット率の評価基準と改善アクション:

ヒット率低下が検知された場合のチェック手順:
1. cachePoint の位置がリクエストごとに変動していないか確認
2. Nova の場合、プレフィックスが 1024 トークンを超えているか確認
3. リクエスト間隔が TTL（5 分）を超えていないか確認（超える場合は Claude 4.5 系 1 時間 TTL を検討）
4. モデルバージョンが変更されていないか確認（バージョン変更でキャッシュは無効化される）

コスト削減額の試算（簡易計算式）:

月間削減額 ≈ 月間リクエスト数 × プレフィックストークン数 × ヒット率 × (1 - cache_read_比率) × トークン単価

Nova Pro で月 10,000 リクエスト・プレフィックス 8,000 トークン・ヒット率 80% の場合: cache read（約 10%）の割合が大きくなるため、キャッシュなし比で大幅削減が見込めます。cachePoint 追加前後で InputTokenCount の CloudWatch メトリクスを比較すると、削減効果を直接数値で確認できます。§5-5 の Nova Pro 月額半減実例もこの計算式に基づくものです。

7. Bedrock Agents 高度活用 — 永続メモリ・暴走防止・トレース

本セクションでは Bedrock Agents の高度活用として 永続メモリ（Memory 機能） ・暴走防止設計 ・トレース・監視 の 3 テーマを解説します。特に「Bedrock Agents Memory」と「AgentCore Memory」の混同は設計ミスにつながる重要ポイントです。

7-1. Bedrock Agents Memory の概要

Bedrock Agents Memory は 2024-12 preview 起点で提供が始まった機能で、セッション横断で会話コンテキストを保持 します。sessionId を指定することで同一ユーザーの過去の会話を参照した応答が可能になります。

通常の Bedrock Agents は各セッションが独立しており、前のセッションで話した内容を引き継げません。Memory 機能を有効化すると、セッション終了時に session summary が自動生成され、次回セッション開始時に Agent がその要約を参照できます。

セッション1: ユーザー「東京オフィスの会議室予約について教えて」
  → セッション終了 → session summary 自動生成 → memoryId に保存

セッション2（数日後）: ユーザー「先日の件、続きを教えて」
  → Agent が memoryId から session summary を取得 → 前回コンテキストを踏まえて応答

7-2. sessionId と memoryId の設定

Bedrock Agents Memory の設定は invoke_agent の呼び出し時に sessionId と memoryId を指定します。

import boto3

bedrock_agent_runtime = boto3.client(
 'bedrock-agent-runtime',
 region_name='us-east-1'
)

response = bedrock_agent_runtime.invoke_agent(
 agentId='YOUR_AGENT_ID',
 agentAliasId='YOUR_ALIAS_ID',
 sessionId='user-session-001',
 inputText='東京オフィスの会議室予約のルールを教えてください',
 memoryId='user-memory-001',
 enableTrace=True,
)

for event in response['completion']:
 if 'chunk' in event:
  chunk = event['chunk']
  print(chunk['bytes'].decode('utf-8'), end='')

パラメータの設計指針:

sessionId はセッション単位でユニークな値を、memoryId はユーザー単位で固定した値を使うのが一般的な設計パターンです。

7-3. storageDays の設定と選択基準

memoryConfiguration の storageDays で session summary の保持期間を設定します（1〜365 日）。

bedrock_agent = boto3.client('bedrock-agent', region_name='us-east-1')

response = bedrock_agent.update_agent(
 agentId='YOUR_AGENT_ID',
 agentName='MyAgent',
 foundationModel='amazon.nova-pro-v1:0',
 instruction='あなたは社内情報アシスタントです。',
 memoryConfiguration={
  'enabledMemoryTypes': ['SESSION_SUMMARY'],
  'storageDays': 30,
 },
)

storageDays の選択基準:

storageDays が長いほどストレージコストが増加します。実際の利用パターンに合わせた値の設定が重要です。

7-4. session summary の仕組みと取得

セッション終了時に Bedrock が自動で session summary を生成します。

response = bedrock_agent_runtime.get_agent_memory(
 agentId='YOUR_AGENT_ID',
 agentAliasId='YOUR_ALIAS_ID',
 memoryId='user-memory-001',
 memoryType='SESSION_SUMMARY',
)

for memory_item in response.get('memoryContents', []):
 print(f"Session: {memory_item['sessionSummary']['sessionId']}")
 print(f"Summary: {memory_item['sessionSummary']['summaryText']}")

セッションを明示的に終了する場合は endSession=True を指定します:

response = bedrock_agent_runtime.invoke_agent(
 agentId='YOUR_AGENT_ID',
 agentAliasId='YOUR_ALIAS_ID',
 sessionId='user-session-001',
 inputText='ありがとうございました。',
 memoryId='user-memory-001',
 endSession=True,
)

endSession=True を指定すると、そのセッションの summary が生成されて memoryId に保存されます。

注意: Bedrock Agents Memory の仕様は変動します。実装前に agents-memory.html で最新仕様を確認してください。

7-5. Bedrock Agents Memory vs AgentCore Memory（重要な区別）

この 2 つのサービスを混同しないことが最重要ポイントです。

使い分けの判断基準:

• Bedrock Agents をすでに使っている → Bedrock Agents Memory を有効化するだけで OK
• 新規にカスタムエージェントを構築する → AgentCore Memory を含む AgentCore の採用を検討
• 複雑な記憶管理が必要（例: 長期ユーザー好み + 直前会話の短期保存） → AgentCore Memory

7-6. Agents 暴走防止の設計

Bedrock Agents は LLM が自律的にアクションを実行するため、停止しない無限ループ・意図しない大量 API 呼び出し・コスト爆発 のリスクがあります。本番運用では暴走防止設計が不可欠です。

暴走防止 3 原則:
1. 明確な exit 条件の定義
2. 最大反復回数（max iterations）の設定
3. タイムアウト設計

原則1: 明確な exit 条件

Agent の instruction に exit 条件を明示します:

# 良い例: 明確な exit 条件
instruction = """
あなたはデータ収集エージェントです。
以下の条件が満たされたら必ず終了してください:
- 必要な情報がすべて収集された場合
- 3 回以上エラーが発生した場合
- ユーザーから「終了」「完了」という指示があった場合
条件が満たされたら、それ以上アクションを実行せずに結果を返してください。
"""

# 悪い例: exit 条件が曖昧
instruction = """
できるだけ多くの情報を収集してください。
"""

Flows の DoWhile ループでも同様に、明確な exit 条件・測定可能な閾値・相互排他状態の 3 原則を適用します（§2 参照）。

原則2: 最大ステップ数の設定

Bedrock Agents では Agent レベルで最大ステップ数を制御できます。Agent の設定で最大ステップ数を指定することで、N ステップを超えた時点で強制終了させます。設定値は公式ドキュメントで確認してください。

原則3: Lambda タイムアウト設計

Lambda Action Group でタイムアウトを設定します:

from aws_cdk import aws_lambda as lambda_, Duration

action_function = lambda_.Function(
 self, 'AgentActionFunction',
 runtime=lambda_.Runtime.PYTHON_3_12,
 timeout=Duration.seconds(29),
 handler='handler.main',
 code=lambda_.Code.from_asset('lambda'),
)

Lambda のタイムアウトを短めに設定することで、Agent が長時間処理に依存して停止しないよう制御できます。29 秒は API Gateway の 30 秒制限を意識した値です。

7-7. トレース・監視の設定

Agent トレースの取得:

enableTrace=True を指定すると Agent の思考プロセス・アクション実行ログが取得できます:

response = bedrock_agent_runtime.invoke_agent(
 agentId='YOUR_AGENT_ID',
 agentAliasId='YOUR_ALIAS_ID',
 sessionId='session-001',
 inputText=user_input,
 enableTrace=True,
)

for event in response['completion']:
 if 'trace' in event:
  trace = event['trace']['trace']
  if 'orchestrationTrace' in trace:
orch = trace['orchestrationTrace']
if 'rationale' in orch:
 print(f"思考: {orch['rationale']['text']}")
if 'invocationInput' in orch:
 print(f"アクション: {orch['invocationInput']}")

Bedrock runtime logging の有効化:

bedrock = boto3.client('bedrock', region_name='us-east-1')

bedrock.put_model_invocation_logging_configuration(
 loggingConfig={
  'cloudWatchConfig': {
'logGroupName': '/aws/bedrock/agent-invocations',
'roleArn': 'arn:aws:iam::ACCOUNT_ID:role/BedrockLoggingRole',
'largeDataDeliveryS3Config': {
 'bucketName': 'my-bedrock-logs',
 'keyPrefix': 'agent-logs/',
},
  },
  'textDataDeliveryEnabled': True,
  'imageDataDeliveryEnabled': False,
  'embeddingDataDeliveryEnabled': False,
 }
)

CloudTrail との連携:

Bedrock Agents の API 呼び出し（InvokeAgent・InvokeFlow など）は CloudTrail に自動記録されます。

# CloudWatch Logs Insights クエリ例
fields @timestamp, @message
| filter eventSource = "bedrock-agent.amazonaws.com"
| filter eventName = "InvokeAgent"
| stats count() by bin(1h)
| sort @timestamp desc

コスト異常の早期検知:

cw = boto3.client('cloudwatch', region_name='us-east-1')

cw.put_metric_alarm(
 AlarmName='BedrockAgentInvocationSpike',
 Namespace='AWS/Bedrock',
 MetricName='InvocationCount',
 Dimensions=[{'Name': 'ModelId', 'Value': 'amazon.nova-pro-v1:0'}],
 Statistic='Sum',
 Period=300,
 EvaluationPeriods=2,
 Threshold=500,
 ComparisonOperator='GreaterThanThreshold',
 AlarmActions=['arn:aws:sns:us-east-1:ACCOUNT_ID:bedrock-alerts'],
)

Agent が暴走して InvocationCount が急増した場合に SNS でアラートを受け取れます。

8. ガバナンス・監視・モデル廃止移行

Bedrock の新機能を本番展開する際、ガバナンス・コスト可視化・モデルバージョン管理の 3 軸を整備しておかないと、予算超過やモデル廃止時のサービス断といったリスクに直面します。本セクションでは Bedrock 固有の監視・統制手段を体系的に解説します。

8-1. Model access 管理 — モデルの有効化・無効化

Bedrock コンソールの Model access 画面では、AWS アカウントで使用するモデルをリージョン単位で有効化・無効化できます。

有効化の手順:
1. AWS コンソール → Amazon Bedrock → Model access
2. 対象モデルを選択し「Request model access」
3. 利用規約への同意 → 即時または数分後に有効化

有効化後の確認方法:

import boto3

bedrock = boto3.client('bedrock', region_name='us-east-1')
response = bedrock.list_foundation_models()
for model in response['modelSummaries']:
 lifecycle = model.get('modelLifecycle', {})
 print(f"{model['modelId']}: {lifecycle.get('status', 'ACTIVE')}")

本番運用での管理ポイント:
– 使用しないモデルは無効化してコスト事故を防止
– 新モデルの有効化は staging 環境で先行検証してから本番へ反映
– マルチアカウント構成では AWS Organizations + SCP でモデルアクセスを統制

Model access と SCP の組み合わせ:

SCP (Service Control Policy) で bedrock:InvokeModel の Action を特定 modelId に限定すると、承認済みモデル以外の呼び出しをアカウントレベルで遮断できます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AllowOnlyApprovedBedrockModels",
"Effect": "Deny",
"Action": "bedrock:InvokeModel",
"Resource": "*",
"Condition": {
  "StringNotLike": {
 "bedrock:ModelId": [
"arn:aws:bedrock:*::foundation-model/amazon.nova-pro-v1:0",
"arn:aws:bedrock:*::foundation-model/amazon.nova-lite-v1:0",
"arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"
 ]
  }
}
 }
  ]
}

設計原則: SCP は最後の砦として機能します。アプリケーション層でも呼び出し可能モデルを限定し、SCP は逸脱を防ぐ二重防護として位置づけます。

8-2. コスト可視化 — Cost Explorer タグ / Bedrock usage metrics

Bedrock の費用は 推論コスト と 追加機能コスト に分かれます。Cost Explorer でリソースタグを使った細粒度のコスト分析が可能です。

推奨タグ設計:

Cost Explorer でのフィルタリング:
1. AWS コンソール → Cost Explorer → Explore costs
2. Service: Amazon Bedrock でフィルタ
3. Group by: Tag → bedrock:project で内訳を確認

Bedrock Usage Metrics (CloudWatch):

Bedrock は以下の CloudWatch メトリクスを標準で出力します。

CloudWatch アラーム設定例:

import boto3

cloudwatch = boto3.client('cloudwatch', region_name='us-east-1')

cloudwatch.put_metric_alarm(
 AlarmName='bedrock-monthly-token-limit',
 MetricName='InputTokenCount',
 Namespace='AWS/Bedrock',
 Statistic='Sum',
 Period=2592000,  # 30日
 EvaluationPeriods=1,
 Threshold=100_000_000,  # 1億トークン
 ComparisonOperator='GreaterThanThreshold',
 AlarmActions=['arn:aws:sns:us-east-1:123456789012:bedrock-alerts'],
 Dimensions=[
  {'Name': 'ModelId', 'Value': 'amazon.nova-pro-v1:0'}
 ]
)

Provisioned Throughput のコスト監視:

PT (Provisioned Throughput) は時間課金のため、未使用時間のコストが積み上がります。購入 MCU × 使用時間 vs 実際の InvocationCount を CloudWatch で比較し、利用率が 60% を下回る場合は On-Demand への切り替えを検討してください。

コスト異常検知の設定:

AWS Cost Anomaly Detection を Bedrock サービスに設定すると、前日比 20% 以上のコスト急増時にアラートが届きます。

1. Cost Management → Cost Anomaly Detection → Create monitor
2. Monitor type: AWS services → Amazon Bedrock を選択
3. Alert threshold: Absolute dollar amount または percentage change を設定
4. 通知先: SNS Topic → メール / Slack 連携

8-3. モデルバージョン廃止対応

AWS は廃止予定モデルを公式ドキュメント (Bedrock model lifecycle) で事前告知します。本番運用では廃止アナウンスを検知し、計画的に移行する体制が必要です。

廃止ライフサイクルの 3 フェーズ:

廃止アナウンスの検知方法:

1. AWS Health Dashboard: 廃止予告は AWS Health イベントで届く
2. What’s New RSS 購読: Bedrock What’s New ページの RSS を監視ツールで購読
3. ListFoundationModels の定期確認: modelLifecycle.status が LEGACY に変わったら移行開始

import boto3

def check_deprecated_models(region='us-east-1'):
 bedrock = boto3.client('bedrock', region_name=region)
 response = bedrock.list_foundation_models()
 deprecated = []
 for model in response['modelSummaries']:
  lifecycle = model.get('modelLifecycle', {})
  if lifecycle.get('status') in ('LEGACY', 'EOL'):
deprecated.append({
 'modelId': model['modelId'],
 'status': lifecycle['status'],
 'eolDate': lifecycle.get('eolDate', 'N/A')
})
 return deprecated

# Lambda や EventBridge で週次実行してアラートを飛ばす設計が有効

モデルエイリアス活用による無停止移行:

Bedrock の inference profile や model alias を使うと、アプリケーションコードを変更せずにバックエンドモデルを切り替えられます。

import boto3, json

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

# alias の向き先を変えるだけでアプリ側の変更は不要
response = bedrock_runtime.invoke_model(
 modelId='arn:aws:bedrock:us-east-1:123456789012:inference-profile/your-alias',
 body=json.dumps({
  'messages': [{'role': 'user', 'content': 'Hello'}]
 }),
 contentType='application/json',
 accept='application/json'
)

移行テストのチェックリスト:

移行テスト必須項目:
  □ 移行先モデルの入出力形式が現行モデルと互換か確認
  □ プロンプトテンプレートの動作差分をテストセットで評価
  □ Bedrock Evaluations で旧モデル vs 新モデルの品質比較レポート生成
  □ レイテンシ・スループット要件を満たすか負荷テスト実施
  □ コスト差異をシミュレーション (トークン単価の変化を考慮)
  □ ロールバック手順をドキュメント化 (エイリアスを元に戻すだけ)

8-4. IAM によるアクセス制御設計

最小権限原則の適用:

Bedrock のアクセス制御は IAM ポリシーで行います。アプリケーションロールに付与する権限は用途に応じて絞り込みます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "BedrockRuntimeAccess",
"Effect": "Allow",
"Action": [
  "bedrock:InvokeModel",
  "bedrock:InvokeModelWithResponseStream"
],
"Resource": [
  "arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.nova-pro-v1:0",
  "arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.nova-lite-v1:0"
]
 },
 {
"Sid": "BedrockAgentsAccess",
"Effect": "Allow",
"Action": [
  "bedrock-agent:InvokeAgent"
],
"Resource": "arn:aws:bedrock:ap-northeast-1:123456789012:agent-alias/*"
 }
  ]
}

Flows / Evaluations 専用ポリシー:

Flows の呼び出しには bedrock:InvokeFlow が必要です。Evaluations の実行には bedrock:CreateEvaluationJob などの管理権限が別途必要なため、評価専用ロールをアプリ実行ロールから分離することを推奨します。

クロスアカウント呼び出しの設定:

Bedrock Agent や Knowledge Base にクロスアカウントでアクセスする場合は、リソースベースポリシーで呼び出し元アカウントの IAM ロールを明示的に許可します。

8-5. CloudTrail / Bedrock 呼び出しログの設定

CloudTrail による API 監査:

Bedrock の管理 API 操作（モデルアクセス変更・Flows 作成・Evaluations 実行等）は CloudTrail に自動記録されます。データイベントである InvokeModel のログ取得には追加設定が必要です。

import boto3

cloudtrail = boto3.client('cloudtrail', region_name='us-east-1')

cloudtrail.put_event_selectors(
 TrailName='your-trail-name',
 AdvancedEventSelectors=[
  {
'Name': 'BedrockInvokeModel',
'FieldSelectors': [
 {'Field': 'eventCategory', 'Equals': ['Data']},
 {
  'Field': 'resources.type',
  'Equals': ['AWS::Bedrock::ModelInvocationLog']
 }
]
  }
 ]
)

Bedrock Model Invocation Logging:

CloudTrail とは別に、Bedrock 固有の Invocation Logging をコンソールまたは API で有効化すると、入出力内容を S3 / CloudWatch Logs に保存できます。

有効化手順:
1. Amazon Bedrock → Settings → Model invocation logging
2. Logging destination: S3 bucket / CloudWatch Logs を選択
3. ログ対象: Text / Image / Embedding を選択（コスト・容量要件で調整）

注意: 入力プロンプト・出力テキストをログに含める場合は、個人情報・機密情報の取り扱いポリシーとの整合性を確認してください。

ログを活用したコスト診断パターン:

S3 に出力された Bedrock Invocation Log を Amazon Athena でクエリすると、モデル別のトークン消費量・レイテンシを把握できます。

SELECT
 model_id,
 COUNT(*) AS invocation_count,
 SUM(input_token_count) AS total_input_tokens,
 SUM(output_token_count) AS total_output_tokens,
 AVG(latency_ms) AS avg_latency_ms
FROM invocation_logs
WHERE year='2025' AND month='05'
GROUP BY model_id
ORDER BY total_input_tokens DESC

このクエリでコスト最適化の優先順位付けを行い、高コストモデルへの依存度を把握します。

9. 詰まりポイント・アンチパターン・まとめ

本番導入時に多くの開発者が直面する落とし穴とその解決策を体系化しました。詰まりポイント 7 選とアンチパターン→正解 5 選を頭に入れておくだけで、トラブルシューティングの時間を大幅に短縮できます。

9-1. 詰まりポイント 7 選

詰まり① Flows の無限ループ — exit 条件未定義で DoWhile 脱出不能

DoWhile ノードに exit 条件を適切に設定しないと、ループが永続的に実行されタイムアウトまで課金が継続します。

症状: Flows の実行が数分後にタイムアウトエラーで終了する
原因: DoWhile の condition node が常に true を返す設計になっている

解決策:
– DoWhile の exit 条件には数値比較など機械的に判定できる条件を設定
– iteration_count >= max_iterations のようなカウンタ上限を必ず追加
– Flows のビジュアルビルダーで各分岐先に向き先ノードが存在することを確認
– テスト時は max_iterations を小さい値 (5〜10) に設定してから検証
– 本番 DoWhile は「明確な exit 条件 + 測定可能な閾値 + 相互排他状態」の 3 原則を満たすこと

詰まり② Evaluations GA 前の設定ミス — 旧 API 仕様の混入

Bedrock Evaluations の LLM-as-Judge は 2025-03-20 GA 前は限定プレビューでした。GA 前の SDK バージョンや旧ドキュメントを参照している場合、エンドポイント・パラメータ名が異なるため ValidationException が発生します。

# Boto3 バージョン確認
import boto3
print(boto3.__version__)  # 1.38.x 以降を推奨
# 更新: pip install --upgrade boto3

解決策:
– Boto3 / AWS CLI を最新バージョンに更新してから実装
– bedrock.create_evaluation_job() の引数を AWS SDK ドキュメントの最新仕様で確認
– 旧プレビュー期間の実装コードは全面的に見直す（エンドポイント・リクエスト形式が変更済み）
– ドキュメントは model-evaluation-llm-as-a-judge を参照

詰まり③ Nova Premier — 未対応リージョンへのデプロイ

Nova Premier は Nova Micro / Lite / Pro と比較してリージョン対応状況が異なります。未対応リージョンでデプロイしようとすると ResourceNotFoundException または AccessDeniedException が発生します。

# 呼び出し前に対応モデルを確認
bedrock = boto3.client('bedrock', region_name='ap-northeast-1')
response = bedrock.list_foundation_models(
 byProvider='Amazon',
 byOutputModality='TEXT'
)
model_ids = [m['modelId'] for m in response['modelSummaries']]
# nova-premier が一覧になければそのリージョンでは未対応

解決策:
– list_foundation_models() でモデル ID の存在を確認してから呼び出し
– 未対応リージョンの場合は Cross-Region Inference (geographic/global CRIS) 経由でアクセス
– Nova Premier 対応状況は変動するため Amazon Nova models ページ で最新情報を確認

詰まり④ Cross-Region Inference の地理制約違反 — EU 規制データを US ルーティングに通す

Geographic CRIS は EU データを EU 境界内でルーティングしますが、Global CRIS を使うと US リージョンへルーティングされる可能性があります。GDPR 等のデータレジデンシ要件がある EU 規制データに Global CRIS を適用すると規制違反になります。

誤: EU 規制データに Global CRIS を適用 (us-east-1/us-west-2 へのルーティングあり)
正: EU 規制データには Geographic CRIS を使用 (EU 境界内ルーティング保証)

解決策:
– EU 規制データには必ず Geographic CRIS を選択
– inference profile の Region 制約を事前に確認: geographic-cross-region-inference.html
– データクラシフィケーション（規制対象 / 非対象）をタグで管理し、アプリ側でルーティング戦略を切り替える設計にする
– Japan CRIS は Tokyo / Osaka 間ルーティングで国内データレジデンシを確保

詰まり⑤ Prompt Caching 不適用 — キャッシュ最小トークン未満の短いプロンプト

Nova の Prompt Caching は最初の cachePoint 配置時に 1024 トークン以上のプレフィックスが必要です。この条件を満たさないプロンプトにはキャッシュが適用されず、cache write コストだけが発生します。

# キャッシュが効いているか確認する方法
response = bedrock_runtime.invoke_model(...)
body = json.loads(response['body'].read())
usage = body.get('usage', {})
print(f"Cache write tokens: {usage.get('cacheWriteInputTokens', 0)}")
print(f"Cache read tokens: {usage.get('cacheReadInputTokens', 0)}")
# cacheReadInputTokens = 0 の場合、キャッシュが効いていない

解決策:
– システムプロンプトを 1024 トークン以上にするか、コンテキスト・ドキュメントを cachePoint より前に配置してトークン数を確保
– Claude 系の最小トークン制限は公式ドキュメントで別途確認
– usage.cacheReadInputTokens > 0 をログに記録してキャッシュ効果を継続モニタリング
– キャッシュが効かない場合はシステムプロンプト + 固定コンテキストを前置して 1024 トークンを確保する

詰まり⑥ Agents Memory と AgentCore Memory の混同 — API・設定が別物

「Bedrock Agents Memory」と「AgentCore Memory」は名前が似ていますが別サービスです。混同すると設定が無効になるか、存在しないパラメータに対して ValidationException が発生します。

解決策:
– 既存の Bedrock Agents に session 記憶を追加したい → Bedrock Agents Memory を使用
– 独立した記憶管理サービスが必要な新規設計 → AgentCore Memory を検討
– 公式ドキュメントは agents-memory.html と AgentCore ドキュメントを別々に参照

詰まり⑦ PT の誤選択によるコスト爆発 — On-Demand 適用シーンで PT を契約

Provisioned Throughput (PT) は時間課金のため、リクエスト数が少ない場合は On-Demand より割高になります。PT 契約後に使用率が低いことに気づいても、契約期間（1 か月 / 6 か月）は解約できません。

PT が適している条件 (すべて満たすこと):
  ✓ 安定して高いスループット (MCU の 70% 以上を継続利用)
  ✓ 低レイテンシ要件が厳しい (On-Demand のスロットリングを避けたい)
  ✓ コスト予測可能性が重要 (固定費として管理したい)

On-Demand が適している条件:
  ✓ リクエストが散発的・予測困難
  ✓ PoC・検証フェーズ
  ✓ ピーク時のみ高負荷 (平均利用率が低い)

解決策:
– PT 契約前に 2〜4 週間の実際のトークン消費量を CloudWatch で計測
– 月間必要 MCU を計算し、On-Demand 換算コストと比較してから契約判断
– 不確実な場合は 1 か月契約でまず検証し、6 か月契約は確信を得てから
– Prompt Caching や Cross-Region Inference でまず On-Demand コストを下げてから PT 必要性を再評価

9-2. アンチパターン → 正解 5 選

① Flows をシンプルなワークフローに適用

② Evaluations を全リクエスト毎に実行

③ Nova Pro と Nova Premier を同用途で使う

Nova 選定フロー:
入力がテキストのみ? → Yes → Nova Micro (最低コスト・最低レイテンシ)
  → No  → 低コスト multimodal で十分? → Yes → Nova Lite
複雑・高精度が必要?  → No  → Nova Pro
最高精度 or 蒸留用?  → Yes → Nova Premier

④ Prompt Caching の TTL を考慮せず長い会話

⑤ Agents Memory に機密情報を無制限保持

9-3. まとめ

本記事では Amazon Bedrock 2024-2025 年の主要新機能を本番運用の視点で横断的に解説しました。

Bedrock Flows は複雑なマルチコンポーネント LLM ワークフローを可視化・管理するための強力なツールです。DoWhile ループの無限ループ防止・Condition node の優先順位設計・バージョニングによる A/B テストを組み合わせることで、信頼性の高い本番運用が実現します。シンプルな処理には適用せず、Flows の価値が最大化される複雑なオーケストレーションに絞って活用してください。

Bedrock Evaluations は LLM 品質保証のゲートキーパーです。2025-03-20 GA となった LLM-as-Judge と RAG evaluation を CI/CD パイプラインに組み込み、モデル切り替えやプロンプト変更時の品質劣化を自動検出する体制を構築してください。全リクエスト評価は不要で、PR マージ前・週次の回帰テスト・モデル変更時の 3 つのタイミングに絞った運用が現実的です。custom metrics (2025-04 対応) を活用すると自社固有の品質基準でモデルを評価できます。

Nova モデル群 は用途に応じた選定が最重要です。Micro / Lite / Pro / Premier を無差別に使わず、コスト・レイテンシ・精度の要件に合わせた選定フローを組織内で標準化してください。Cross-Region Inference は地理制約（特に EU データのレジデンシ）を正しく理解した上で Geographic / Global を使い分けます。Japan CRIS（Tokyo / Osaka 間）を活用することで国内データレジデンシを確保しつつ可用性を向上できます。

Prompt Caching は設定するだけでなく usage.cacheReadInputTokens をモニタリングして実際にキャッシュが機能していることを継続確認してください。Nova の 1024 トークン以上プレフィックス確保と 5 分以内のリクエスト間隔という 2 条件を満たす用途に適用することで最大 90% のコスト削減が実現します。cachePoint 1 個の追加だけで Nova Pro の月額コスト試算が約半減した実例があります。

Bedrock Agents Memory と AgentCore Memory は別サービスです。既存 Agents へのセッション記憶追加は前者、高度な記憶管理が必要な新規設計は後者を検討してください。storageDays 設定と機密情報マスキングは必須の運用項目です。2025-10-13 GA の AgentCore Memory は短期 working + 長期 long-term の 2 層構造で、より高度な記憶管理が必要なケースで活用してください。

ガバナンス面 では、Model access の SCP 制限・コスト可視化のリソースタグ設計・廃止モデルの移行手順・CloudTrail + Invocation Logging の 2 層監査を最初から設計に組み込んでください。後付けで導入しようとすると既存システムの変更コストが膨らみます。Cost Anomaly Detection を Bedrock サービスに設定し、コスト急増を自動検知する体制も早期に整えることを推奨します。

本記事の内容を起点に、ご自身のユースケースに合わせた本番設計パターンを構築してください。各機能の最新動向（特に Nova の対応リージョン・Prompt Caching の TTL・Agents Memory の仕様）は変化が速いため、定期的に公式ドキュメントを確認することを推奨します。

9-4. 関連記事

本記事は「Bedrock 2024-2025 新機能」特化ガイドです。基礎的な機能については以下の関連記事を参照してください。