生成AI LLMOps本番運用 Vol1｜評価・可観測性・コスト・ガードレール

1. この記事について

生成AIアプリのPoC（概念実証）は終わりました。Amazon Bedrockで推論APIを呼び出し、Knowledge BasesでRAGパイプラインを構築し、Agentsでエージェントを動かすことができた——ここまでは多くのチームが到達しています。しかし本番リリース後に直面するのは全く別の問いです。「動かすこと」と「安定して回し続けること」の間には、埋めなければならない設計のギャップがあります。

本番環境では次のような課題が次々と発生します。モデルの出力品質は時間の経過とともに静かに劣化します（モデルアップデートやプロンプトドリフトによる品質回帰）。トークンコストは予算を超えて膨らんでも気づけません（可観測性とアラートの欠如）。ガードレールのポリシーは法規制・社内規定の変更に追随して継続更新が必要です（バージョン管理と監査証跡の不在）。プロンプトを変更したが、どのバージョンが品質改善に貢献したか追跡できなくなります（ライフサイクル管理の欠如）。

これらを個別に対処するのではなく、評価・可観測性・コスト・ガバナンス・ライフサイクルを横断して設計・運用するのがLLMOps（Large Language Model Operations）です。本記事ではAmazon Bedrockを中心としたAWS環境で、生成AIアプリを本番で安定的に回し続けるための横断運用設計を解説します。

本記事が扱うのは「機能の使い方」ではなく「運用ループの設計」です。BedrockのEvaluationsやGuardrailsの詳細な使い方は既存Volで解説済みです。本記事はそれらを「どう組み合わせ、誰が何を担い、いつどう実行するか」という実践設計に特化します。

「LLMOps」という言葉は、MLOps（Machine Learning Operations）から派生した概念です。従来のMLOpsは自社でモデルをトレーニングすることを前提に、データパイプライン・Feature Store・学習実験管理・モデルデプロイを扱います。一方、LLMOpsはすでに高性能な基盤モデルが存在することを前提に、そのモデルをプロンプトで操作・評価・制御・コスト管理することに重心を置きます。つまりLLMOpsとMLOpsは共存する概念であり、「生成AIを使うならMLOpsは不要」ということではありません。SageMaker MLOpsとLLMOps両方を適切な場面で使い分けることが、AWS上での包括的なAIシステム運用の姿です（詳細な比較は§1-3）。

1-1. 本記事のゴール

本記事を読み終えた後、以下の状態になることを目指します。

• LLMOps全体像の把握: 評価・可観測性・コスト統制・ガードレール・ライフサイクルの5領域が、どのような運用ループを形成するかを理解できる
• 各運用領域の設計判断: 自社の生成AIアプリに対してどの運用要素を優先的に組み込むべきかを判断できる
• 担当の明確化: 開発者・SRE・ガバナンス担当がそれぞれ何を責任として持つべきかを整理できる
• 機能と運用の分離: Bedrockの個別機能（Evaluations・Guardrails・Prompt managementなど）と、それらを組み合わせた横断運用設計の違いを理解できる
• 落とし穴の把握: cross-region inferenceとProvisioned Throughputの非互換、評価をリリース前だけで終わらせる失敗パターンなど本番固有の注意点を知っている
• 実装の出発点: 各領域のPythonコード例・CLIコマンドをそのまま自社環境へのLLMOps導入のたたき台として使える
• 参照先の整理: 機能の詳細が必要なときにどの既存Volへ進むべきかを知っている
• 段階的な導入計画: 一度にすべてを実装するのではなく、優先度の高い領域から順に導入するロードマップを描ける
• LLMOpsとMLOpsの使い分け: どのユースケースでLLMOpsのみが必要で、どのケースでSageMaker MLOpsと組み合わせるべきかを判断できる

本記事の構成と読み方

各章は独立して読めます。すでに一部の運用が整っている場合は、課題に対応する章から読み始めることを推奨します。

1-2. 読者像

本記事は以下の読者を想定しています。

• フェーズ: 生成AIアプリのPoCを終えて本番運用フェーズに移行した、またはこれから移行しようとしているチーム
• 役割: 生成AIアプリを担当する開発者・SRE・MLエンジニア。Bedrockの基本的な推論APIは触ったことがある
• 課題感: 「動くものは作れたが、本番での品質維持・コスト管理・ガバナンスをどう設計・運用するかの指針が欲しい」
• 前提知識: AWSのIAM・CloudWatchの基礎を理解している。BedrockのInvokeModel APIを1度以上呼び出したことがある
• 除外読者: Bedrockの機能を一から学びたい方（→本節末尾の関連記事ナビへ）。SageMakerの学習パイプラインを詳しく知りたい方（→ML-AI本番運用Vol3へ）

本番運用に入る前のPoCフェーズであっても、LLMOps設計は早期に検討することを推奨します。評価基盤・可観測性・ガードレールは後から導入すると改修コストが大きいため、設計段階でのアーキテクチャ考慮が効果的です。

本記事はチーム横断で参照されることを想定して書いています。開発者はコード例とプロンプト管理章を、SREはコスト・可観測性章を、ガバナンス担当はガードレール章を中心に読み、必要に応じて§2の責務分界表で全体の連携を確認することを推奨します。

本記事の対象外

本記事は横断的な運用設計に特化するため、以下は対象外です。

• Bedrockの個別機能の設定方法・API呼び出し手順（→既存Volへ参照誘導）
• SageMaker MLOpsのフル解説（Pipelines・Feature Store・Model Monitor）（→ML-AI本番運用Vol3へ）
• エージェント（Bedrock Agents・AgentCore）の構築手順（→AgentCore Vol1-2へ）
• RAGシステムの構築手順（Knowledge Basesの設定等）（→ML-AI本番運用Vol2へ）

1-3. 従来MLOpsとLLMOpsの違い

生成AI以前のML運用（MLOps）とLLMOpsには、目的・技術スタック・運用上の関心事において本質的な違いがあります。SageMakerを中心とした従来MLOpsはデータエンジニアリング・学習パイプライン・Feature Storeが核心でしたが、基盤モデルを前提とするLLMOpsではプロンプト設計・継続評価・ガードレール・トークンコストが主要関心事に変わります。両者を混同すると、従来MLOpsの設計をそのまま生成AIに適用してしまい、プロンプトバージョン管理やトークンコスト監視が抜け落ちる設計ミスが生まれます。

SageMaker MLOpsの詳細（Pipelines・Feature Store・Model Monitor・Autopilot）はML-AI本番運用Vol3で解説しています。本記事ではLLMOps固有の課題に絞って解説します。

MLOpsとLLMOpsをどう使い分けるか

実際のAWSシステムでは、両者を組み合わせて使うケースが大半です。たとえば以下のパターンが典型的です。

• 純粋なLLMOps: Bedrockのマネージドモデル（Claude・Nova等）を推論API経由で利用する生成AIアプリ。トレーニング不要・Feature Store不要。本記事が対象とするケースです。
• MLOpsとLLMOpsの共存: SageMakerで学習した推薦モデルと、Bedrockで動くLLMが同一システム内に共存するケース。推薦はSageMaker MLOps、LLM部分はLLMOpsで管理します。
• ファインチューニング込みのLLMOps: BedrockのCustom Model Importやファインチューニングを使う場合は、学習パイプライン管理という従来MLOps要素が一部必要になります。

本記事は「Bedrockのマネージドモデルを推論APIで利用する」前提のLLMOps設計に絞ります。ファインチューニングや推薦システムとの組み合わせは対象外です。

Bedrock本番運用シリーズを読む

2. LLMOps運用基盤の前提と全体設計

LLMOpsを実際に設計・導入するには、まず運用基盤となるAWS環境の前提を整理する必要があります。本節では必要なAWSサービス・権限・リージョン対応状況を確認した上で、LLMOps全体の運用ループ（設計→デプロイ→監視→評価→改善の継続サイクル）を概説します。そして開発者・SRE・ガバナンス担当それぞれが担うべき責務の分界を明確にします。

2-1. 前提環境

LLMOps基盤を構築する前に、以下の前提条件を確認してください。

AWSアカウントとBedrockモデルアクセス

Amazon Bedrockは使用するモデルごとにアクセスリクエストが必要です。AWS Management Consoleの「Amazon Bedrock」→「モデルアクセス」から申請します。以下のモデルは本記事のコード例で使用します。

CLIバージョン確認

# AWS CLIバージョン確認（2.x以上推奨）
aws --version
# aws-cli/2.17.x 以上

# Bedrockモデルアクセス確認（東京リージョン）
aws bedrock list-foundation-models \
  --region ap-northeast-1 \
  --query 'modelSummaries[?contains(modelId, `claude-3-5-sonnet`)].{id:modelId,status:modelLifecycle.status}' \
  --output table

必要なIAM権限の一覧

LLMOps各領域の操作には以下のIAM権限が必要です。最小権限の原則に従い、ロール別に分割することを推奨します。

東京リージョン（ap-northeast-1）のGA状況

注意: GA状況はAWSのアップデートにより変わります。本番導入前にAWSコンソールおよびAmazon Bedrockの公式ドキュメントで最新状況を確認してください。

2-2. LLMOps運用ループの全体像

LLMOpsは一度設定すれば終わりではなく、継続的なループとして運用します。以下の5フェーズで構成される運用サイクルが基本形です。

[プロンプト/モデル設計] → [デプロイ] → [監視・可観測性] → [評価] → [改善]
↑___________________________________________________________↓

各フェーズと本記事の対応章は以下の通りです。

運用ループの設計原則

運用ループを回し続けるにあたり、以下の設計原則を適用することを推奨します。

1. 評価は二層で設計する: リリース前のオフライン評価（Bedrock Evaluations）と、本番のオンライン監視（CloudWatch + Model invocation logging）を独立して設計します。オフライン評価だけでは本番ドリフトを検知できず、オンライン監視だけでは品質回帰の原因特定が困難です
2. 変更は不変バージョンで管理する: プロンプト・Guardrailはともに番号付き不変バージョンを作成し、アプリケーションは番号を参照します。DRAFT版は開発中のみ使用します。これにより「どのバージョンが本番で動いているか」を常に追跡できます
3. コストアラートはデプロイ前に設定する: トークンコストの急増はアラートなしでは気づけません。CloudWatchアラームとAWS Budgetsをデプロイと同時に設定します（§5で詳述）
4. ガードレールはポリシーの継続更新を前提に設計する: 初回設定で完成するものではありません。法規制・社内規定・新たな攻撃パターンへの追随が継続的に発生します。バージョン管理なしに運用すると、どのポリシー変更がいつ行われたか追跡不能になります
5. 監査証跡は最初から記録する: Model invocation loggingを初期デプロイから有効化します。後から有効化しようとすると、既存の問題事例のログが残っておらず原因調査が困難になります

2-3. 責務分界 — どの運用要素を誰が持つか

LLMOpsを組織として運用するには、3つのロール（開発者・SRE・ガバナンス担当）の責務を明確に分界する必要があります。責務が曖昧なままだと「誰かがやるはず」でプロンプトバージョン管理やコストアラート設定が抜け落ちます。

◎ = 主担当（意思決定権を持つ）/ ○ = 協力・レビュー / — = 関与なし

IAMポリシー最小権限サンプル — 開発者ロール

各ロールの責務に対応するIAMポリシーを最小権限で定義します。以下は開発者ロール（推論実行・プロンプト管理・評価実行）のサンプルです。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "BedrockInvokeModel",
"Effect": "Allow",
"Action": [
  "bedrock:InvokeModel",
  "bedrock:InvokeModelWithResponseStream"
],
"Resource": [
  "arn:aws:bedrock:ap-northeast-1::foundation-model/*"
]
 },
 {
"Sid": "BedrockPromptManagement",
"Effect": "Allow",
"Action": [
  "bedrock:CreatePrompt",
  "bedrock:CreatePromptVersion",
  "bedrock:GetPrompt",
  "bedrock:ListPrompts",
  "bedrock:UpdatePrompt"
],
"Resource": "arn:aws:bedrock:ap-northeast-1:*:prompt/*"
 },
 {
"Sid": "BedrockEvaluations",
"Effect": "Allow",
"Action": [
  "bedrock:CreateEvaluationJob",
  "bedrock:GetEvaluationJob",
  "bedrock:ListEvaluationJobs",
  "bedrock:StopEvaluationJob"
],
"Resource": "*"
 }
  ]
}

CLIでポリシーを作成しロールにアタッチします。

# ポリシーJSONをファイルに保存後、IAMポリシーを作成
aws iam create-policy \
  --policy-name LLMOps-Developer-Policy \
  --policy-document file://developer-policy.json \
  --region ap-northeast-1

# 作成したポリシーをロールにアタッチ
aws iam attach-role-policy \
  --role-name LLMOps-Developer-Role \
  --policy-arn arn:aws:iam::YOUR_ACCOUNT_ID:policy/LLMOps-Developer-Policy

S3権限の追加: 評価ジョブは入力データと結果をS3バケットに格納します。s3:GetObject / s3:PutObject の権限を評価用バケットARN（arn:aws:s3:::your-llmops-bucket/*）に限定して追加してください。バケット名を具体的に指定して権限範囲を最小化することを推奨します。

Guardrail適用権限: アプリケーションロールがGuardrailを適用してInvokeModelを呼び出す場合は、bedrock:ApplyGuardrail の権限も必要です。Guardrail ARNをResourceに限定して付与します（arn:aws:bedrock:ap-northeast-1:*:guardrail/GUARDRAIL_ID）。

IAMポリシーサンプル — SREロール（可観測性・コスト監視）

SREロールは評価実行よりもCloudWatch設定・ログ管理・コストアラームに重心を置きます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "CloudWatchObservability",
"Effect": "Allow",
"Action": [
  "cloudwatch:PutMetricAlarm",
  "cloudwatch:PutMetricData",
  "cloudwatch:GetMetricStatistics",
  "cloudwatch:DescribeAlarms",
  "logs:CreateLogGroup",
  "logs:CreateLogDelivery",
  "logs:PutLogEvents",
  "logs:DescribeLogGroups",
  "logs:StartQuery",
  "logs:GetQueryResults"
],
"Resource": "*"
 },
 {
"Sid": "BedrockLoggingConfig",
"Effect": "Allow",
"Action": [
  "bedrock:PutModelInvocationLoggingConfiguration",
  "bedrock:GetModelInvocationLoggingConfiguration"
],
"Resource": "*"
 },
 {
"Sid": "BudgetsManagement",
"Effect": "Allow",
"Action": [
  "budgets:CreateBudget",
  "budgets:UpdateBudget",
  "budgets:ViewBudget",
  "budgets:PutBudgetAction"
],
"Resource": "arn:aws:budgets::*:budget/*"
 }
  ]
}

IAMロール設計のまとめと運用指針

LLMOpsの責務分界をIAMで実現する際の推奨パターンをまとめます。

3. 評価の継続運用 — オフライン評価とオンライン監視

生成AIアプリを本番で運用し続けるには、「作って終わり」の一点検証ではなく、リリース前のオフライン評価とリリース後のオンライン監視を組み合わせた継続的な評価ループが不可欠です。Amazon Bedrock Evaluationsはこの二層構成を一つのサービスで実現し、評価結果をCI/CDや本番監視と連携させることで、品質劣化（ドリフト）の早期検知と回帰防止を可能にします。

3-1. Bedrock Model Evaluation の3方式

Bedrock Model Evaluations（東京リージョン含む多リージョンでGA）は、用途に応じて3つの評価方式を使い分けられます。

自動指標 (Automatic Metrics)

自動指標はモデルが生成したテキストと参照回答を比較し、ROUGE-L・METEOR・BERTScoreなどの指標を自動算出します。大量のテストケースを低コスト・高速に処理できるため、CI/CDパイプラインへの組み込みに適しています。ただし意味的な正確さよりも表面的な文字列類似度を測るため、RAGや創造的タスクには補助的に使うのが適切です。

人間評価 (Human Evaluation)

AWS Managed Work Teamまたは自社の社内ランカーを指定し、生成テキストの品質を人間が評点する方式です。「この回答はビジネス文脈で適切か」のような主観的・ドメイン固有の品質基準を評価できます。コストと時間がかかるため、本番前の最終検証や規制要件が厳しいユースケースで活用します。

LLM-as-a-judge（GA: 2025年3月）

大規模LLMを評価者として使い、生成テキストの品質を0–10スケールで評点させる方式です。2025年3月にGAとなり、東京リージョンでも利用可能です。人間評価と高い相関を持ちながらコストと時間を大幅に削減できるため、毎日の品質チェックや大量バッチ評価に適しています。

import boto3

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

# LLM-as-a-judgeによる評価ジョブ作成
response = bedrock.create_evaluation_job(
 jobName="daily-quality-check-2025",
 roleArn="arn:aws:iam::123456789012:role/BedrockEvaluationRole",
 evaluatorConfig={
  "automatedEvaluationConfig": {
"evaluatorModelConfig": {
 "bedrockEvaluatorModels": [
  {
"modelIdentifier": (
 "anthropic.claude-3-5-sonnet-20241022-v2:0"
)
  }
 ]
}
  }
 },
 inferenceConfig={
  "models": [
{
 "bedrockModel": {
  "modelIdentifier": (
"anthropic.claude-3-haiku-20240307-v1:0"
  ),
  "inferenceParams": (
'{"maxTokens": 512, "temperature": 0}'
  ),
 }
}
  ]
 },
 outputDataConfig={
  "s3Uri": "s3://my-eval-results/daily-check/"
 },
)
print(f"Evaluation job ARN: {response['jobArn']}")

3-2. RAG Evaluation の指標体系（GA: 2025年3月20日）

RAGシステム（Amazon Bedrock Knowledge Bases等）の評価は、通常のモデル評価とは異なる指標体系が必要です。2025年3月20日にGAとなったBedrock RAG Evaluationでは、以下3カテゴリーの指標を使い分けます。

検索指標（Retrieval Metrics）

• Context Relevance: 検索されたドキュメントチャンクがユーザーの質問にどれだけ関連しているかを0–1で評点します。低スコアはインデックス設計や検索戦略の問題を示します。
• Context Coverage: 回答に必要な情報がチャンク全体にどれだけカバーされているかを評価します。不足している場合はチャンクサイズやオーバーラップ設定の見直しを検討してください。

生成指標（Generation Metrics）

• Correctness: 生成回答が参照回答と事実として一致しているかを評点します（LLM-as-a-judge方式）。
• Completeness: 参照回答のキー情報が生成回答にすべて含まれているかを評点します。
• Faithfulness: 生成回答が検索コンテキスト（取得されたドキュメント）にのみ基づいているかを評点します。スコアが低ければハルシネーション（事実ではない情報の生成）のリスクを示し、RAG運用における最重要指標の一つです。

責任あるAI指標（Responsible AI Metrics）

• Harmfulness: 有害・攻撃的・差別的なコンテンツが含まれているかを評点します。
• Answer Refusal: 拒否が本当に必要なケースで正しく拒否し、不要な拒否をしていないかを評価します。
• Stereotyping: 性別・人種・文化に関するステレオタイプを含む回答を検出します。

# RAG Evaluationジョブの作成（AWS CLI）
aws bedrock create-evaluation-job \
  --job-name "rag-daily-check-$(date +%Y%m%d)" \
  --role-arn "arn:aws:iam::123456789012:role/BedrockEvaluationRole" \
  --evaluation-config '{
 "automated": {
"datasetMetricConfigs": [
  {
 "taskType": "QuestionAndAnswer",
 "dataset": {"name": "rag-test-dataset"},
 "metricNames": [
"Builtin.ContextRelevance",
"Builtin.ContextCoverage",
"Builtin.Correctness",
"Builtin.Faithfulness",
"Builtin.Harmfulness"
 ]
  }
]
 }
  }' \
  --inference-config '{
 "ragConfigs": [
{
  "knowledgeBaseConfig": {
 "retrieveAndGenerateConfig": {
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
  "knowledgeBaseId": "ABCDEFGHIJ",
  "modelArn": "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0"
}
 }
  }
}
 ]
  }' \
  --output-data-config '{"s3Uri": "s3://my-eval-results/rag-check/"}'

3-3. カスタム評価指標と bring-your-own-inference

カスタム評価指標（2025年4月〜）

LLM-as-a-judgeを使って、ドメイン固有の評価基準を独自指標として定義・再利用できます。「金融規制への準拠度」「医療ガイドラインとの整合性」「ブランドトーンの一貫性」といった業界固有の品質軸を0–10スケールで評点するプロンプトを定義し、プロジェクト横断で再利用します。

# カスタム評価指標の定義（ジョブ作成時にevaluatorConfigへ渡す）
custom_metric_instructions = (
 "あなたは当社ブランドガイドラインの専門家です。"
 "以下の回答が「プロフェッショナルかつ親しみやすい」トーン指針に"
 "どれだけ沿っているかを0から10で評点してください。"
 "10=完全に一致、5=部分的に一致、0=全く一致しない。"
 "評点のみを返してください。"
)

# evaluatorConfigのcustomMetricsフィールドに定義を追加する
custom_metric_config = {
 "name": "BrandToneConsistency",
 "instructions": custom_metric_instructions,
 "ratingScale": [
  {"value": 0, "definition": "ブランドトーンと全く合わない"},
  {"value": 5, "definition": "部分的に合う"},
  {"value": 10, "definition": "ブランドトーンと完全に一致"},
 ],
}

bring-your-own-inference

Bedrock Evaluationsは「Bedrockのモデルだけを評価する」サービスではありません。inferenceConfigにカスタムエンドポイント（SageMakerエンドポイントや任意のHTTP API）を指定することで、外部モデルやRAGシステムの出力を同じ評価フレームワークで評価できます。既存の自社モデルやサードパーティLLMとのベンチマーク比較にも活用できます。

# SageMakerエンドポイントをbring-your-own-inferenceとして評価する例
inference_config_byoi = {
 "models": [
  {
"sageMakerModel": {
 "executionRoleArn": (
  "arn:aws:iam::123456789012:role/BedrockEvaluationRole"
 ),
 "endpoints": [
  {"endpointName": "my-custom-llm-endpoint"}
 ],
}
  }
 ]
}

3-4. オフライン評価 × オンライン監視の二層設計と回帰検知

二層設計の基本構成

オフライン評価の運用フロー

1. プロンプトやモデルを変更するたびにCI/CDパイプラインから評価ジョブを自動起動します。
2. 主要指標（Faithfulnessなど）がベースラインを下回ったらデプロイをブロックします。
3. 評価結果をS3に蓄積し、時系列でトレンドを追跡します。

オンライン監視と回帰検知

本番トラフィックから定期的にサンプリングした入出力ペアをLLM-as-a-judgeで評価し、品質スコアをCloudWatchカスタムメトリクスとして送出します。スコアが閾値を下回ったらアラームを起動し、プロンプトの劣化・データドリフト・モデルの挙動変化を早期検知します。

import boto3

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


def publish_quality_score(job_name: str, faithfulness_score: float) -> None:
 """評価スコアをCloudWatchカスタムメトリクスとして送出する"""
 cloudwatch.put_metric_data(
  Namespace="LLMOps/Quality",
  MetricData=[
{
 "MetricName": "FaithfulnessScore",
 "Dimensions": [{"Name": "JobName", "Value": job_name}],
 "Value": faithfulness_score,
 "Unit": "None",
}
  ],
 )


# CloudWatchアラーム: FaithfulnessScoreが0.7を下回ったら通知
cloudwatch.put_metric_alarm(
 AlarmName="LLMOps-FaithfulnessDropAlert",
 Namespace="LLMOps/Quality",
 MetricName="FaithfulnessScore",
 Dimensions=[{"Name": "JobName", "Value": "rag-daily-check"}],
 Statistic="Average",
 Period=86400,
 EvaluationPeriods=1,
 Threshold=0.7,
 ComparisonOperator="LessThanThreshold",
 AlarmActions=[
  "arn:aws:sns:ap-northeast-1:123456789012:LLMOpsAlert"
 ],
)

EventBridgeスケジューラと組み合わせることで、毎日深夜にRAG評価ジョブを自動起動し、朝一番に品質スコアレポートを確認する運用を構築できます。Bedrock Model EvaluationsはCI/CDとオンライン監視の両方から呼び出せるため、リリース前後を一貫した評価フレームワークで管理できます。

評価機能そのものの詳細な設定方法（評価データセットの作成・指標のカスタマイズ等）については、Bedrock本番運用 — 新機能活用編（評価機能詳解）を参照してください。本章は継続運用設計の観点から評価ループの組み方に絞って解説しました。

4. 可観測性 — トークン・レイテンシ・品質メトリクスとトレース

生成AIアプリの健全性を本番で保つには、従来のAPM（レイテンシ・エラーレート）に加えて、トークン消費・品質スコアという生成AI特有の可観測性軸が必要です。Amazon CloudWatchは「生成AI可観測性」として、Bedrockの詳細メトリクスとモデル呼び出しログを追加コストなしで提供します。

4-1. CloudWatch生成AI可観測性 — AWS/Bedrock 名前空間のメトリクス

Bedrockの推論呼び出しは、AWS/Bedrock名前空間に以下のメトリクスを自動emitします（追加設定不要）。

追加メトリクス（追加コストなしで自動emit）

DimensionとしてModelIdが使えるため、モデルごとにフィルタリングして監視できます。

4-2. TTFT / EstimatedTPMQuotaUsage の本番活用

TimeToFirstToken (TTFT) の活用

チャットUIでは最初のトークン到着までの時間がユーザーの体感速度を決定します。InvocationLatency（全体完了まで）とTTFTを分けて監視することで、「生成が遅い」のか「最初の応答が遅い」のかを切り分けられます。p99アラームを設定し、2秒超えを検知したらモデル選択やプロンプト長の見直しにつなげます。

import boto3

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

# TTFTのp99アラーム: 2秒超えでアラート
cloudwatch.put_metric_alarm(
 AlarmName="Bedrock-TTFT-P99-High",
 Namespace="AWS/Bedrock",
 MetricName="TimeToFirstToken",
 Dimensions=[
  {
"Name": "ModelId",
"Value": "anthropic.claude-3-haiku-20240307-v1:0",
  }
 ],
 ExtendedStatistic="p99",
 Period=300,
 EvaluationPeriods=2,
 Threshold=2000,
 ComparisonOperator="GreaterThanThreshold",
 AlarmActions=[
  "arn:aws:sns:ap-northeast-1:123456789012:BedrockAlert"
 ],
)

EstimatedTPMQuotaUsage の活用

クォータに対するTPM使用率（0–1）を監視し、0.8（80%）超えでアラームを設定します。スロットリング（InvocationThrottles増加）が起きる前に事前検知し、cross-region inferenceへの自動ルーティングやリクエストキューイングで対応できます。§5で解説するコスト・スループット統制と連動させることで、スロットリング→遅延のエスカレーションを防止します。

4-3. Model Invocation Logging — 入出力の完全記録

Model invocation loggingを有効にすると、Bedrockへの全推論呼び出しの入力プロンプトと出力テキストをCloudWatch LogsまたはS3に記録します。ログ本文は最大100KB（100KB超は切り捨て）で、デバッグ・品質確認・コンプライアンス対応に使います。

CloudWatch Logs Insightsでのクエリ例

-- 直近1時間の特定モデルの入出力を確認（Faithfulness低下時のデバッグ用）
fields @timestamp, input.inputBodyJson.messages[0].content, output.outputBodyJson.content
| filter modelId = "anthropic.claude-3-haiku-20240307-v1:0"
| filter @timestamp > ago(1h)
| sort @timestamp desc
| limit 50

CLI/CloudFormationでのinvocation logging有効化

# AWS CLIでinvocation loggingをCloudWatch Logs+S3に設定
aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
 "cloudWatchConfig": {
"logGroupName": "/aws/bedrock/model-invocations",
"roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole",
"largeDataDeliveryS3Config": {
  "bucketName": "my-bedrock-logs",
  "keyPrefix": "large-payloads/"
}
 },
 "s3Config": {
"bucketName": "my-bedrock-logs",
"keyPrefix": "invocations/",
"encryptionKeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/xxx"
 },
 "textDataDeliveryEnabled": true,
 "imageDataDeliveryEnabled": false,
 "embeddingDataDeliveryEnabled": false
  }'

CloudFormationでの設定:

BedrockLoggingConfig:
  Type: AWS::Bedrock::ModelInvocationLoggingConfiguration
  Properties:
 LoggingConfig:
CloudWatchConfig:
  LogGroupName: /aws/bedrock/model-invocations
  RoleArn: !GetAtt BedrockLoggingRole.Arn
S3Config:
  BucketName: !Ref BedrockLogsBucket
  KeyPrefix: invocations/
TextDataDeliveryEnabled: true
ImageDataDeliveryEnabled: false

4-4. プロンプト・レスポンスのロギングとプライバシ配慮

invocation loggingでは入力プロンプトがそのまま記録されるため、PII（個人識別情報）や機密データの取り扱いに注意が必要です。

推奨プラクティス

• S3バケット暗号化: KMSキーを必ず指定し、ログデータを保護します（上記CLI例のencryptionKeyIdを省略しないでください）。
• CloudWatch Logsのリソースポリシー: 評価担当・SRE・セキュリティ担当のみにアクセスを絞ります。
• textDataDeliveryEnabled: falseの選択: コンプライアンス要件が厳しい場合は、テキスト本文のロギングを無効化し、メタデータ（モデルID・トークン数・レイテンシ）のみ記録します。
• S3ライフサイクルポリシー: デバッグ用途のログは30日で自動削除するなどのデータ保持期間を設定します。
• CloudWatch Logs Insights のクエリ権限: 本番ログへのクエリは本番アカウントのロールに限定し、開発アカウントと分離します。

4-5. 汎用APM可観測性との棲み分け

AWS Application Signals等の汎用APMはアプリケーション全体のレイテンシ・エラーレート・依存関係を監視します。本章で解説した生成AI特化メトリクスはそれを補完するレイヤーです。

エージェント（Bedrock Agents / AgentCore）を使う場合は、エージェント呼び出しのトレースや分岐履歴を可視化するAgentCore Observabilityを別途参照してください。汎用CloudWatchメトリクスとの組み合わせで、エージェントのどのステップでレイテンシが発生しているかまで掘り下げられます。

可観測性のより詳細な設計（X-Rayトレーシング・Application Signals統合・ダッシュボード構成）については、ML-AI本番運用 Vol3 — 可観測性設計で詳しく解説しています。本章は生成AI特化メトリクスに集中し、LLMOps運用ループの「見える化」層を担います。

5. コスト・スループット統制

5-1. オンデマンド vs プロビジョンドスループットの選択基準

Amazon Bedrockのスループット選択肢は、「オンデマンド」と「プロビジョンドスループット（Provisioned Throughput）」の2種類です。選択は使用量の予測可能性と必要な応答安定性で決まります。

オンデマンドは共有環境のためInvocationThrottlesが発生しやすいです。スパイク対応が必要な本番サービスや、秒間リクエスト数が安定して高い場合はProvisioned Throughputを検討してください。モデルユニット（MU）は1単位あたりの処理能力を示し、ピークトラフィックを元に必要台数を事前見積もりする必要があります。

5-2. Cross-region inference — ルーティングとコスト特性

Cross-region inference（クロスリージョン推論）はAmazon Bedrockのinference profile機能で、利用可能なリージョン間でリクエストを自動ルーティングする仕組みです。

主な特性:

• 追加コストなし: ルーティング自体に追加料金は発生しません
• 呼び出し元リージョン基準の価格: 実際の処理リージョンに関わらず、呼び出し元リージョンのモデル単価が適用されます
• スループット向上: 単一リージョンの共有クォータ上限を超えて処理できるため、実効スループットが向上します

Cross-region inferenceを使うには、リージョンプレフィックス（us./eu./ap.）が付いたinference profile IDを指定します。

import boto3

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

# us.プレフィックスがcross-region inference profileを示す
response = bedrock_runtime.converse(
 modelId="us.anthropic.claude-3-5-sonnet-20241022-v2:0",
 messages=[{"role": "user", "content": [{"text": "コスト最適化の設計を教えてください"}]}],
)
print(response["output"]["message"]["content"][0]["text"])
print(
 f"input={response['usage']['inputTokens']},"
 f" output={response['usage']['outputTokens']}"
)

5-3. Global cross-region inferenceの選択肢

Bedrockは米国（US）・欧州（EU）・アジア太平洋（AP）の3エリアにまたがるGlobal cross-region inferenceをサポートしています。特定リージョンへの依存を減らしつつ、グローバルなスループット確保が求められる場合に有効です。

各inference profileの対応リージョンはBedrockコンソールの「Cross-region inference → Inference profiles」で確認できます。利用可能なprofile一覧はCLIでも取得できます。

aws bedrock list-inference-profiles \
  --type-equals SYSTEM_DEFINED \
  --region ap-northeast-1 \
  --query 'inferenceProfileSummaries[*].{Name:inferenceProfileName,Id:inferenceProfileId}' \
  --output table

5-4. モデル選択によるコスト最適化

本番LLMOpsではタスクの複雑度に応じてモデルを使い分けることが、コスト削減の最も直接的な手段です。

用途別モデル選択の考え方:

最初のリクエストを軽量モデルで処理し、品質が閾値を下回った場合のみ大規模モデルにエスカレートする「段階的カスケード」パターンが有効です。

import boto3

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

def cascade_invoke(prompt: str) -> dict:
 """コスト最適化のための段階的モデルカスケード"""
 lite_resp = bedrock.converse(
  modelId="amazon.nova-lite-v1:0",
  messages=[{"role": "user", "content": [{"text": prompt}]}],
 )
 lite_text = lite_resp["output"]["message"]["content"][0]["text"]

 # 品質チェック（本番ではLLM-as-a-judgeや信頼スコアで判定）
 if len(lite_text.strip()) >= 80:
  return {"model": "nova-lite", "response": lite_text, "usage": lite_resp["usage"]}

 pro_resp = bedrock.converse(
  modelId="amazon.nova-pro-v1:0",
  messages=[{"role": "user", "content": [{"text": prompt}]}],
 )
 return {
  "model": "nova-pro",
  "response": pro_resp["output"]["message"]["content"][0]["text"],
  "usage": pro_resp["usage"],
 }

result = cascade_invoke("LLMOpsの可観測性設計について説明してください")
print(f"使用モデル: {result['model']}")
print(f"input={result['usage']['inputTokens']}, output={result['usage']['outputTokens']}")

5-5. 予算・アラート運用 — トークンメトリクスとCloudWatchの連携

コスト急増をリアルタイムで検知するには、Bedrockのトークンメトリクスを活用したCloudWatchアラームとAWS Budgetsの組み合わせが推奨です。

主なメトリクス（AWS/Bedrock名前空間）:

CloudWatchアラーム設定（AWS CLI）:

# 1時間あたりの合計OutputTokenCountに対するアラームを設定
aws cloudwatch put-metric-alarm \
  --alarm-name "bedrock-output-token-spike" \
  --alarm-description "Bedrock output token count exceeds threshold" \
  --metric-name OutputTokenCount \
  --namespace AWS/Bedrock \
  --statistic Sum \
  --period 3600 \
  --threshold 1000000 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:bedrock-cost-alert" \
  --dimensions Name=ModelId,Value=anthropic.claude-3-5-sonnet-20241022-v2:0 \
  --region ap-northeast-1

AWS Budgetsによるコスト上限アラート（CloudFormation）:

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  BedrockMonthlyCostBudget:
 Type: AWS::Budgets::Budget
 Properties:
Budget:
  BudgetName: bedrock-monthly-cost
  BudgetType: COST
  TimeUnit: MONTHLY
  BudgetLimit:
 Amount: 500
 Unit: USD
  CostFilters:
 Service:
- Amazon Bedrock
NotificationsWithSubscribers:
  - Notification:
NotificationType: ACTUAL
ComparisonOperator: GREATER_THAN
Threshold: 80
ThresholdType: PERCENTAGE
 Subscribers:
- SubscriptionType: EMAIL
  Address: ops-team@example.com
  - Notification:
NotificationType: FORECASTED
ComparisonOperator: GREATER_THAN
Threshold: 100
ThresholdType: PERCENTAGE
 Subscribers:
- SubscriptionType: EMAIL
  Address: ops-team@example.com

ACTUALが予算の80%超でアラート、FORECASTEDが100%超になると予測された時点でも通知します。月末前にコスト超過を事前に検知できます。

Python SDKでのトークンコスト推計:

import boto3

# モデル単価（例示値 — 必ず最新のAWS料金ページで確認してください）
PRICE_PER_1K_INPUT = 0.003# USD / 1K input tokens
PRICE_PER_1K_OUTPUT = 0.015  # USD / 1K output tokens

def estimate_cost(usage: dict) -> float:
 input_tokens = usage.get("inputTokens", 0)
 output_tokens = usage.get("outputTokens", 0)
 return (input_tokens / 1000 * PRICE_PER_1K_INPUT
+ output_tokens / 1000 * PRICE_PER_1K_OUTPUT)

bedrock = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
response = bedrock.converse(
 modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
 messages=[{"role": "user", "content": [{"text": "LLMOpsとは何ですか？"}]}],
)
usage = response["usage"]
print(f"推定コスト: ${estimate_cost(usage):.6f}")
print(f"input={usage['inputTokens']} tokens, output={usage['outputTokens']} tokens")

コスト分析を深めるには、AWS Cost Explorerでのタグ戦略（例: project: my-app, env: prod）が有効です。Bedrockの呼び出しにリソースタグを付与することで、サービス別・モデル別・環境別のコストを詳細に把握できます。

6. ガードレール運用とガバナンス

6-1. ガードレールのバージョン管理戦略

Amazon Bedrock Guardrailsは、有害コンテンツの遮断・PII保護・トピック制限・グラウンディング確認などを担う安全レイヤーです。本番運用では「どのバージョンのガードレールが稼働中か」を厳密に管理することが不可欠です。

Guardrailsには2種類のバージョン状態があります。

DRAFT版はいつでも変更できますが、番号付きバージョンは作成後に変更できません（削除のみ可能）。これにより、本番アプリが参照するガードレールは意図せず変わらないことが保証されます。

運用フロー:

DRAFT編集・テスト → バージョン作成（例: v3）→ アプリの参照バージョンを更新 → 古バージョン廃止

# GuardrailのDRAFT版を確認
aws bedrock get-guardrail \
  --guardrail-identifier grb-xxxxxxxxxxxxxxxx \
  --guardrail-version DRAFT \
  --region ap-northeast-1

# 新しい番号付きバージョンを作成
aws bedrock create-guardrail-version \
  --guardrail-identifier grb-xxxxxxxxxxxxxxxx \
  --description "v3: Automated Reasoning checks有効化" \
  --region ap-northeast-1

6-2. アプリからのバージョン参照とDRAFT安全更新

本番アプリは番号付きバージョン（例: 3）を明示的に指定することで、DRAFTへの変更が本番に波及しないようにします。

import boto3

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

GUARDRAIL_ID = "grb-xxxxxxxxxxxxxxxx"
GUARDRAIL_VERSION = "3"  # 不変バージョンを明示指定（DRAFTは本番では使わない）

response = bedrock.converse(
 modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
 messages=[{"role": "user", "content": [{"text": "こんにちは"}]}],
 guardrailConfig={
  "guardrailIdentifier": GUARDRAIL_ID,
  "guardrailVersion": GUARDRAIL_VERSION,
 },
)
print(response["output"]["message"]["content"][0]["text"])

DRAFTを指定するにはguardrailVersion="DRAFT"とします。テスト環境ではDRAFT、本番では番号付きバージョンを使うことで、安全に並行開発が可能です。

6-3. Automated Reasoning checks（2025年8月 提供開始）

Automated Reasoning checks（AR checks）は、形式論理（First-Order Logic）を使ってモデル応答のファクト整合性を検証する機能です。LLM出力のハルシネーション検知に特化しており、最大99%の精度を謳っています（AWS公式発表）。2025年8月にGA（一般提供開始）されました。

動作原理:

1. ポリシーとして「真でなければならないルール（ファクトセット）」を定義する
2. モデルの出力がルールに矛盾しないか形式論理エンジンが検証する
3. 矛盾を検知した場合、Guardrailsがその出力をブロックまたはフラグとして記録する

ユースケース例:

東京リージョン（ap-northeast-1）でのAR checks提供状況はBedrockコンソールで最新状況を確認してください。個別ポリシーの設定方法はBedrock本番運用Vol3（Guardrails・Prompt management）で解説しています。

6-4. Natural language test Q&A生成（2025年11月追加）

2025年11月に追加されたNatural language test Q&A生成機能は、ガードレールのポリシーから自動的にテストケース（Q&Aペア）を生成します。

• ポリシー文書から想定される質問・回答ペアを自動生成します
• 生成されたテストケースでGuardrailsの動作を事前検証できます
• 「ポリシーを書いたが実際にどんな入力でブロックされるか不明」という問題を解消します

手動でテストケースを作成する工数が大幅に削減でき、ポリシーの本番化サイクルを加速します。この機能はBedrockコンソールのGuardrails → Testから利用できます。

6-5. 監査証跡の運用

本番ガードレールの監査証跡は、コンプライアンスや障害調査において不可欠です。Guardrails呼び出し結果はModel invocation loggingと組み合わせてCloudWatch LogsまたはS3に記録されます。

監査ログに含まれる主要フィールド:

import boto3

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

query = """
fields @timestamp, requestId, action, assessments
| filter action = "GUARDRAIL_INTERVENED"
| sort @timestamp desc
| limit 100
"""

response = logs.start_query(
 logGroupName="/aws/bedrock/modelinvocations",
 startTime=1748736000,
 endTime=1748822400,
 queryString=query,
)
query_id = response["queryId"]
print(f"クエリID: {query_id}")
# logs.get_query_results(queryId=query_id) でポーリング取得

6-6. コンプライアンス・ガバナンス — 責任あるAI指標との連携

Guardrailsの運用はAWSの責任あるAI（Responsible AI）フレームワークと統合されています。本番環境では以下の指標を継続的に追跡することが推奨されます。

誤ブロック（False Positive）が高い場合はポリシーの閾値見直しが必要です。Guardrails介入ログをCloudWatch Logs Insightsで定期集計し、週次でポリシーの有効性レビューを行うことがベストプラクティスです。

CloudFormationによるGuardrailの定義:

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  ProductionGuardrail:
 Type: AWS::Bedrock::Guardrail
 Properties:
Name: production-guardrail
Description: "本番用ガードレール - コンプライアンス要件対応"
ContentPolicyConfig:
  FiltersConfig:
 - Type: SEXUAL
InputStrength: HIGH
OutputStrength: HIGH
 - Type: HATE
InputStrength: HIGH
OutputStrength: HIGH
 - Type: VIOLENCE
InputStrength: MEDIUM
OutputStrength: MEDIUM
SensitiveInformationPolicyConfig:
  PiiEntitiesConfig:
 - Type: EMAIL
Action: ANONYMIZE
 - Type: PHONE
Action: BLOCK
BlockedInputMessaging: "このリクエストはポリシーに基づきブロックされました。"
BlockedOutputsMessaging: "この回答はポリシーに基づきブロックされました。"

7. プロンプト・モデルのライフサイクル運用と実戦統合

生成AIアプリを本番運用するうえで、プロンプトとモデルは「どちらも変化する管理対象」です。モデルは定期的に新バージョンがGA（一般公開）となり、プロンプトは品質改善のたびに変更されます。この2軸を安全かつ再現性高く運用するためのライフサイクル設計が本章のテーマです。

機能の詳細な設定方法はBedrock Vol3（Guardrails/Prompt management）に委ねます。本章では「本番運用設計としてどう使うか」に専念します。

7-1. Prompt management — バージョン管理と評価の連携

Bedrock Prompt managementはGA済み（東京リージョン含む多リージョン対応）です。プロンプトをコードと同様に作成・バージョニング・共有できます。主な機能：

• バージョン管理: プロンプトを作成すると自動的にDRAFTが生成され、任意のタイミングで不変バージョン（v1, v2, …）に昇格できます
• 評価連携: 各プロンプトバージョンをBedrock Evaluationsと紐付け、品質指標（正確性・一貫性・有害性スコア）をバージョン横断で追跡できます
• 共有と再利用: プロンプトARNをIAMポリシーで制御し、開発/本番環境でのバージョン切り替えを安全に実施できます

運用上の鍵は「プロンプトをアプリケーションコードから外部化する」点にあります。ハードコードされたプロンプトはデプロイなしに変更できませんが、Prompt managementを使えばプロンプトのみを無停止で切り替えられます。

import boto3

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

# プロンプトバージョン一覧を取得
response = bedrock.list_prompt_versions(
 promptIdentifier="arn:aws:bedrock:ap-northeast-1:123456789012:prompt/PROMPT_ID"
)
for v in response["promptSummaries"]:
 print(f"Version: {v['version']} | Created: {v['createdAt']}")

# 特定バージョンのプロンプトを取得して利用
prompt = bedrock.get_prompt(
 promptIdentifier="arn:aws:bedrock:ap-northeast-1:123456789012:prompt/PROMPT_ID",
 promptVersion="3"
)
template_text = prompt["variants"][0]["templateConfiguration"]["text"]["text"]
print(template_text)

Prompt managementの詳細な設定方法はBedrock Vol3を参照してください。

7-2. Prompt Optimization — 自動最適化でプロンプト品質を引き上げる

Prompt Optimization（2025年4月 GA）は、既存のプロンプトをモデルが理解しやすい形式に自動変換する機能です。Anthropic Claude / Llama / Amazon Nova / DeepSeek / Mistral / Amazon Titanの各モデルファミリーに対応しています。

手動でのプロンプトエンジニアリングは試行錯誤コストが高いです。Prompt Optimizationを活用することで：

• 指示の曖昧さを排除した明確な構造に変換されます
• 対象モデルのアーキテクチャ特性を踏まえた最適な指示形式に調整されます
• 最適化前後の品質比較をBedrock Evaluationsで自動計測できます

import boto3

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

response = bedrock_runtime.optimize_prompt(
 input={
  "textPrompt": {
"text": "以下の顧客レビューを要約してください: {{input}}"
  }
 },
 targetModelId="anthropic.claude-3-5-sonnet-20241022-v2:0"
)

for event in response["optimizedPrompt"]["stream"]:
 if "optimizedPromptEvent" in event:
  optimized = event["optimizedPromptEvent"]["optimizedPrompt"]
  print("最適化済みプロンプト:")
  print(optimized["textPrompt"]["text"])

最適化後のプロンプトはそのままPrompt managementの新バージョンとして保存し、評価→A/Bテストのサイクルに乗せます。

7-3. Advanced Prompt Optimization — 最大5モデル同時比較（2026年5月）

Advanced Prompt Optimization（2026年5月提供開始）は、Prompt Optimizationの拡張機能で最大5モデルを同時に比較最適化できます。マルチモデル戦略を採る組織（コスト最適化のためのモデルルーティング等）で特に有効です。

主なユースケース：

• Claude 3.5 Sonnet（高精度）と Claude 3 Haiku（低コスト）の2モデルで品質とコストのトレードオフを同時評価
• Nova Pro / Nova Lite / Nova Micro の3モデルで用途別の最適モデルを選定
• モデル更新時（例：Sonnet v2→v3）の移行前後を並列比較

Advanced Prompt Optimizationの利用可能リージョンは執筆時点でAWS公式ドキュメントを確認してください。

7-4. モデル更新・移行戦略

Bedrockでは定期的に新モデルがGAとなります。既存アプリがモデルIDをハードコードしている場合、新モデル移行にはアプリの変更デプロイが必要になります。安全な移行フローは次の4ステップです。

ステップ1: オフライン評価 — 新モデルで既存の評価データセットを再実行し、主要品質指標が既存モデルを下回らないことを確認します。Bedrock Evaluationsを用いて自動的に比較レポートを生成します。

ステップ2: A/Bテスト（本番トラフィックの一部） — 新旧モデルにトラフィックを重み付けルーティングします。CloudWatchメトリクス（InvocationLatency / OutputTokenCount / 品質スコア）を新旧モデル別に比較します。

ステップ3: 段階的移行 — 品質・コスト・レイテンシの全指標が基準を満たした時点で段階的にトラフィックを移行します（5%→25%→100%）。各段階でCloudWatchアラームの異常検知が走るよう設定しておきます。

ステップ4: ロールバック準備 — 移行完了後も旧バージョンのプロンプト×モデルの組み合わせをPrompt managementのバージョンとして保持します。問題発生時はモデルIDとプロンプトバージョンを旧バージョンに戻すだけで即座にロールバック可能です。

import boto3, json, random

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

def ab_invoke(prompt: str, model_a: str, model_b: str, ratio: float = 0.1) -> dict:
 model_id = model_b if random.random() < ratio else model_a
 response = bedrock_runtime.invoke_model(
  modelId=model_id,
  body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1024,
"messages": [{"role": "user", "content": prompt}],
  }),
 )
 result = json.loads(response["body"].read())
 return {"model_id": model_id, "output_tokens": result["usage"]["output_tokens"]}

# 10%を新モデルに振り分けてA/Bテスト
result = ab_invoke(
 prompt="このドキュメントを200字以内で要約してください。",
 model_a="anthropic.claude-3-5-sonnet-20241022-v2:0",
 model_b="anthropic.claude-opus-4-8-20250514-v1:0",
 ratio=0.1,
)
print(f"使用モデル: {result['model_id']} / 出力トークン: {result['output_tokens']}")

7-5. プロンプト×モデルの統合ライフサイクル

プロンプトとモデルは独立に変化しますが、本番の品質はその「組み合わせ」で決まります。統合ライフサイクル管理の3原則：

• バージョンペアの記録: プロンプトバージョンとモデルIDをセットで評価レポートに記録します。「プロンプトv3 × Claude 3.5 Sonnet v2」という組み合わせが最良スコアという追跡が可能になります
• 可観測性との紐付け: CloudWatch Model invocation logにプロンプトバージョンをカスタムメタデータとして付与し、品質劣化をバージョン粒度で特定できるようにします
• 評価の自動化: CI/CDパイプラインにBedrock Evaluationsジョブを組み込み、プロンプト変更ごとに自動評価レポートを生成します

# CLI: プロンプトバージョンを指定した評価ジョブの起動
aws bedrock create-evaluation-job \
  --job-name "prompt-v3-eval-20260606" \
  --evaluation-config '{
 "automated": {
"datasetMetricConfigs": [{
  "taskType": "QuestionAndAnswer",
  "dataset": {"name": "my-eval-dataset",
  "datasetLocation": {"s3Uri": "s3://my-bucket/eval/"}},
  "metricNames": ["Builtin.Correctness", "Builtin.Coherence"]
}]
 }
  }' \
  --inference-config '{"models": [{"bedrockModel": {"modelIdentifier": "anthropic.claude-3-5-sonnet-20241022-v2:0", "inferenceParams": "{\"max_tokens\": 1024}"}}]}' \
  --output-data-config '{"s3Uri": "s3://my-bucket/eval-results/"}' \
  --role-arn "arn:aws:iam::123456789012:role/BedrockEvaluationRole" \
  --region ap-northeast-1

7-6. 実戦統合パターン — LLMOps全体設計での使い分け

LLMOpsを本番で機能させるには、各サービスの責務を明確に分けた統合設計が必要です。主要コンポーネントの使い分けを整理します。

Bedrock機能群（評価・可観測性・コスト・ガードレール・プロンプト管理）

本Volの§2〜§7で扱う横断運用の中核です。各機能の詳細な設定方法はBedrock既存Vol群を参照してください。本Volの責務は「これらを運用ループとして統合する」設計指針にあります。

AgentCore — エージェント用の評価・ガードレール運用

複数エージェントを組み合わせたシステムでは、Bedrock Guardrailsに加えてAgentCoreの評価・ガードレール運用が必要になります。エージェントのツール呼び出し履歴・マルチホップ推論の品質評価はAgentCore固有の機能です。詳細はAgentCore本番運用Vol1-2を参照してください。

RAG（Knowledge Bases）— データ更新とRAG評価の連携

Knowledge Basesのデータ更新（ドキュメント追加・削除）はRAG評価（§3）のスコアに直接影響します。Knowledge Bases更新のたびにRAG評価ジョブを自動実行し、検索品質の劣化を検知する運用を推奨します。詳細はML-AI本番運用Vol2を参照してください。

従来MLOps（SageMaker）— 学習パイプラインとLLMOpsの責務分界

Fine-tuningや継続学習を伴うシステムでは、SageMakerによる学習パイプラインとBedrockのLLMOpsを明確に分界する必要があります。

SageMaker MLOpsの詳細はML-AI本番運用Vol3を参照してください。

8. つまずきポイント・アンチパターン・まとめ

8-1. つまずきポイント（8つ）

本番LLMOps運用で実際に直面する詰まりポイントを、症状・原因・対処の3点セットで整理します。

つまずき①：cross-region inferenceとProvisioned Throughputを同時設定しようとして構成不能になる

症状
: InferenceProfileを設定した状態でProvisioned Throughputを割り当てようとすると、コンソール/APIがエラーを返し、どちらかしか選択できない状態になります。

原因
: Bedrock inference profile（cross-region inference）とProvisioned Throughputは仕様上排他的な設定です。inference profileはオンデマンド呼び出しのルーティング機能であり、Provisioned Throughputが前提とする「特定リージョンのキャパシティ予約」と概念的に競合します。

対処
: 設計段階で利用用途を分岐させます。レイテンシの安定性・コスト確定が最優先の場合はProvisioned Throughputを選択します。マルチリージョン可用性・バーストへの柔軟対応が優先の場合はcross-region inferenceを選択します。両立は不可能であるため、アーキテクチャ設計書に選択根拠を明記し、後工程での迷走を防止します。

つまずき②：評価をリリース前だけで終わらせ、本番ドリフト・回帰を検知できない

症状
: リリース直後は品質基準を満たしていたにもかかわらず、数週間後に回答品質の低下を利用者から指摘され、いつから劣化していたか特定できない状況になります。

原因
: オフライン評価（リリース前の静的データセットによる一回性の検証）だけで運用を終えると、本番データ分布の変化（ドリフト）や、モデル更新・プロンプト変更による回帰を継続的に検知する仕組みがありません。

対処
: Bedrock Evaluationsを用いた定期評価ジョブ（週次・月次）をEventBridgeスケジューラで自動実行します。RAG構成ではcontext relevance・faithfulness・completenessの三指標を継続監視し、閾値下回りをCloudWatchアラームで通知する二層構成（オフライン評価×オンライン監視）を確立します。

つまずき③：トークンコストの急増をアラート未設定で見逃し、月次請求で初めて気づく

症状
: 月末のAWS Cost Explorerレポートで前月比200%のBedrock請求を発見しますが、急増時点の操作ログが残っておらず原因特定ができない状況に陥ります。

原因
: CloudWatchのInputTokenCount・OutputTokenCountメトリクスに対するアラームを設定していないため、トークン消費の急増を即時に検知できません。AWS Budgetsはコスト確定に数時間〜1日のラグがあり、リアルタイム検知には不向きです。

対処
: AWS/Bedrock名前空間のOutputTokenCountメトリクスに対して、1時間粒度でCloudWatchアラームを設定します。閾値は過去7日平均の150%を目安とし、SNSトピック経由でSlack通知します。Model invocation loggingをS3に保存することで、急増時の呼び出しパターンをCloudWatch Logs Insightsでさかのぼり分析できる体制を整えます。

つまずき④：GuardrailsバージョンでDRAFT版を直接アプリ参照し、テスト中の変更が本番に漏れる

症状
: GuardrailsのポリシーをDRAFTで更新してテスト中に、本番アプリの応答が突然変化し、ユーザーからの問い合わせが急増します。

原因
: アプリケーションがGuardrailのguardrailVersion: "DRAFT"を参照していると、DRAFT更新が即座に本番影響を及ぼします。DRAFTは開発用の可変バージョンであり、本番参照は設計上の誤りです。

対処
: 本番アプリは必ず番号付き不変バージョン（guardrailVersion: "1", "2"など）を参照します。CI/CDパイプラインでcreate-guardrail-version APIを呼び出して新バージョンを発行し、デプロイ設定にバージョン番号をコードとして記述します。DRAFTはローカル・ステージング環境でのみ参照を許可するポリシーを組織ルールとして定めます。

つまずき⑤：Prompt managementのバージョンと本番モデルバージョンの対応が追えず、ロールバック不能になる

症状
: 本番障害発生時に「どのプロンプトバージョンと何のモデルの組み合わせで動いているか」が把握できず、ロールバック先を特定するのに多くの時間がかかります。

原因
: Prompt managementのバージョンとモデルIDの組み合わせを記録する仕組みがなく、デプロイ記録が手作業メモのみの場合にトレーサビリティが失われます。

対処
: デプロイ時にPrompt managementのARN（バージョン番号入り）とモデルIDをパラメータとして持ち、デプロイ記録（Systems Manager Parameter StoreまたはDynamoDB）に保存します。各推論呼び出しのModel invocation logにプロンプトARNを付与することで、任意の時点の組み合わせを再現できる状態を維持します。

つまずき⑥：Model invocation loggingでプロンプトをそのままログに記録し、PII（個人情報）が漏洩する

症状
: Model invocation loggingをS3に有効化後、セキュリティレビューでプロンプトに氏名・メールアドレスが含まれていることが発覚し、S3バケットへのアクセス制御の見直しを余儀なくされます。

原因
: Model invocation loggingはプロンプト本文とレスポンス全文をログに記録するため、ユーザー入力由来のPIIを含む可能性があります。デフォルトでは暗号化されますが、アクセス制御は開発者の設定に依存します。

対処
: ログの保存先S3バケットにはSSE-KMS暗号化とバケットポリシーによる最小権限アクセスを設定します。Amazon Macieを用いてS3バケットのPIIスキャンを定期実行します。ユーザー入力のPII除去はアプリ側でGuardrailsの機密情報フィルタを活用し、ログ記録前に除去する設計を採用します。

つまずき⑦：LLM-as-a-judgeで回答者と判定者に同一モデルを使い、自己評価バイアスが生まれる

症状
: LLM-as-a-judgeによる評価スコアが常に高く、実際のユーザー満足度と乖離していますが、評価設計のどこに問題があるか気づかない状態になります。

原因
: 回答生成と評価判定で同一モデルを使うと、モデル固有の回答スタイルへの自己評価バイアス（過剰評価）が生じます。自身のトークン分布に近い出力へ高スコアを付けやすい傾向があるためです。

対処
: 判定モデルは回答生成モデルと異なるモデルファミリーを使用します（例: 回答生成はAmazon Nova Pro、判定はClaude 3.5 Haiku）。あわせて人手評価サンプル（ゴールドセット）との相関を定期的に確認し、判定モデルのバイアス傾向を定量化します。

つまずき⑧：CloudWatch GenAI可観測性メトリクスが東京リージョンで確認できないと思い込み、監視を未設定のまま運用する

症状
: 「AWS/Bedrock名前空間のメトリクスが東京で見えない」と判断してメトリクス監視を省略し、本番品質の可視化が後手に回ります。

原因
: 一部メトリクスはモデル提供リージョン（us-east-1など）に記録されるため、東京（ap-northeast-1）のCloudWatchコンソールでは確認できないケースがあります。クロスリージョンダッシュボードの設定方法が周知されていないことも原因の一つです。

対処
: CloudWatchのクロスアカウント・クロスリージョンダッシュボード機能を使い、us-east-1のAWS/Bedrockメトリクスをap-northeast-1のダッシュボードに集約表示します。inference profile（cross-region inference）を使う場合は、ルーティング先リージョンのメトリクスも含めて統合ビューを構成します。

8-2. アンチパターン → 正解（6組）

本番LLMOps運用で陥りやすいアンチパターンと、それに対応する正解パターンを対比形式で整理します。

パターン①：評価の一回性

❌ アンチパターン
: リリース前に評価ジョブを一度実行して合格し、以降は評価をスキップします。本番で回帰が発生しても検知できない状態が続きます。

✅ 正解パターン
: EventBridgeスケジューラでBedrock Evaluationsジョブを週次自動実行し、faithfulness・correctnessスコアをCloudWatchカスタムメトリクスに記録します。閾値下回り時はSNS通知を発火させ、オフライン評価とオンライン監視の二層構成で継続的な品質保証を実現します。

パターン②：cross-region inferenceとProvisioned Throughputの両立

❌ アンチパターン
: 可用性向上のためcross-region inferenceを設定しつつ、コスト確定のためProvisioned Throughputも同一システムで割り当てようとします。

✅ 正解パターン
: 両機能は排他的に設計します。予測可能な高負荷・コスト確定が必要な場面はProvisioned Throughput専用システムとして切り離し、バースト対応・マルチリージョン可用性が必要な場面はcross-region inference専用パスを使います。

パターン③：GuardrailsのDRAFT参照

❌ アンチパターン
: 開発の手間を省くためにguardrailVersion: "DRAFT"を本番アプリに設定します。DRAFTの更新が即座に本番影響を与え、テスト中の変更が利用者に漏れます。

✅ 正解パターン
: 本番アプリは必ずguardrailVersion: "1"などの番号付き不変バージョンを参照します。CI/CDパイプラインでリリース時にcreate-guardrail-versionを実行し、バージョン番号をインフラコード（CDKまたはCloudFormation）で管理します。

パターン④：プロンプトのハードコードと二重管理

❌ アンチパターン
: プロンプトをアプリケーションコード内にハードコードし、本番用とテスト用を別々のリポジトリで管理します。バージョン対応が追えなくなり、ロールバック時にどのプロンプトが正解か不明になります。

✅ 正解パターン
: Bedrock Prompt managementで全プロンプトを一元管理し、ARNとバージョン番号で本番参照します。A/Bテスト時は同一Prompt managementの異なるバージョンを使い分け、評価結果とバージョンを紐付けてトレーサビリティを維持します。

パターン⑤：ハルシネーションを目視確認のみで管理

❌ アンチパターン
: ハルシネーションの発生を定性的な目視確認と利用者フィードバックだけで把握しようとします。件数・頻度・パターンが定量化されず、改善効果の測定もできません。

✅ 正解パターン
: Bedrock EvaluationsのFaithfulness指標とLLM-as-a-judgeを組み合わせた自動検知パイプラインを構築します。GuardrailsのAutomated Reasoning checks（形式論理による検証、最大99%精度）を活用し、事実誤認の自動検出率を定量化します。

パターン⑥：コスト監視をAWS Budgetsのみに依存

❌ アンチパターン
: Bedrockのコスト監視をAWS Budgetsの月次予算アラートだけで行います。トークン単位の急増を把握できず、月末の請求書で初めて異常に気づきます。

✅ 正解パターン
: CloudWatchのOutputTokenCount・InputTokenCountメトリクスに1時間粒度のアラームを設定し、過去7日平均の150%を超えたらSNS通知します。EstimatedTPMQuotaUsageでスループット上限への接近も監視し、スロットリング発生前に対処できる体制を整えます。

8-3. まとめ

本記事では、生成AIアプリを「本番で回し続ける」ためのLLMOps横断設計を、5つの運用領域にわたって解説しました。各領域の要点を運用ループの観点から総括します。

§3：評価の継続運用

評価はリリース前のオフライン検証で終わりではありません。Bedrock Evaluationsによる定期評価ジョブ（週次・月次）をEventBridgeで自動実行し、faithfulness・correctness・context relevanceの三指標を継続監視することが本番品質保証の起点です。LLM-as-a-judgeを活用することで、評価データセットが不足する領域でも定量的な品質管理が実現します。RAG構成ではオフライン評価とオンライン監視の二層構成が必須です。

§4：可観測性

AWS/Bedrock名前空間のCloudWatchメトリクス（Invocations・InvocationLatency・InputTokenCount・OutputTokenCount・InvocationThrottles）は追加コストなしで自動出力されます。TimeToFirstToken（TTFT）はストリーミング体験を定量化する指標として特に重要です。Model invocation loggingをS3とCloudWatch Logsに並行記録することで、品質低下発生時のさかのぼり分析が可能になります。ただし、PIIを含むプロンプトのログ記録には十分な暗号化・アクセス制御が必要です。

§5：コスト・スループット統制

オンデマンド・Provisioned Throughput・cross-region inferenceの3方式は、用途別に設計段階で選択します。cross-region inferenceはProvisioned Throughputと併用できない点が最大の設計制約です。EstimatedTPMQuotaUsageメトリクスでスループット上限への接近を監視し、OutputTokenCountアラームで急増を即時検知することで、月末請求での発見という事態を防ぎます。

§6：ガードレール運用

Guardrailsは「DRAFTで開発、番号付きバージョンで本番」という原則を徹底します。CI/CDパイプラインにcreate-guardrail-versionを組み込み、バージョン番号をインフラコードで管理してデプロイの再現性を確保します。Automated Reasoning checks（2025年8月提供開始）は形式論理による高精度なハルシネーション検知を提供します。

§7：プロンプト・モデルのライフサイクル

Bedrock Prompt managementで全プロンプトをARN管理し、本番参照は必ずバージョン番号付きARNで行います。Prompt Optimization（2025年4月 GA）・Advanced Prompt Optimization（2026年5月）を活用することで、プロンプト品質の継続改善を自動化できます。モデル更新時は「評価→A/Bテスト→段階移行→ロールバック準備」の4ステップを踏み、デプロイ記録にはプロンプトARNとモデルIDの組み合わせを必ず記録します。

LLMOps運用ループの全体像

LLMOpsの5領域は独立したサービス群ではなく、一つの運用ループとして統合されます。

プロンプト/モデル設計（§7: Prompt management + Prompt Optimization）
 ↓
デプロイ（§6: Guardrails番号付きバージョン / §7: Prompt management ARN）
 ↓
監視・可観測性（§4: CloudWatch GenAI observability / Model invocation logging）
 ↓
評価（§3: Bedrock Evaluations 定期実行 / LLM-as-a-judge）
 ↓
コスト・スループット確認（§5: OutputTokenCount / TTFT / EstimatedTPMQuotaUsage）
 ↓
改善（§7: Prompt Optimization / モデル更新 / A/Bテスト）
 ↓（ループ継続）

このループを自動化する基盤として、EventBridgeスケジューラ（評価・監視の定期実行）・CloudWatch Alarms（異常検知）・Systems Manager Parameter Store（バージョン記録）が機能します。

従来MLOpsとの違い

SageMaker中心の従来ML運用（学習パイプライン・Feature Store・Model Monitor）とLLMOpsは、管理対象が「学習済みパラメータ」から「プロンプト・モデル選択・ガードレールポリシー」に移行します。学習サイクルが月次から日次以下に短縮される一方、評価の難易度は格段に上がります。faithfulnessやhallucinationのような定性的品質指標を定量化するために、LLM-as-a-judgeとBedrockの評価基盤が重要な役割を担います。

横断設計のチェックリスト

本記事で確立したLLMOps横断設計を導入する際のチェックリストとして活用してください。

85記事達成と生成AI運用軸の新起点

本記事は、当シリーズの85記事目として公開します。AWSクラウドの各サービス領域（コンピュート・ネットワーク・データベース・コンテナ・セキュリティ・データ分析・運用自動化）を横断的にカバーしてきた中で、本記事から生成AI運用軸（LLMOps）という新たなシリーズを開始します。

生成AIアプリは「作って終わり」ではなく、本番で回し続けるための継続的な運用設計が不可欠です。評価・可観測性・コスト統制・ガードレール・ライフサイクル管理の5領域を一気通貫で設計することで、PoCから本番運用への確実なステップアップを実現できます。

本記事で解説したLLMOps横断設計を自社の生成AIアプリに適用することで、品質の継続的保証とコスト統制の両立が可能になります。今後の生成AI運用軸シリーズでは、マルチエージェント運用・RAGの高度化・モデル評価の自動化など、より深いLLMOps設計を順次取り上げていく予定です。

8-4. 関連記事（クロスリンク）

エージェント基盤の運用設計：AgentCore Vol1 を読む