AWS Certified Generative AI Developer - Professional 資格対策コース
プロンプトメンテナンスとオブザーバビリティ診断
このレッスンで学ぶこと 対応試験ドメイン D5 タスク 5.2.5。プロンプトの継続的メンテナンスサイクル、Amazon CloudWatch と AWS X-Ray を使った FM システムのオブザーバビリティ設計、検索レイテンシの診断手法、そして Agent ツール呼び出しのスキーマ検証エラーの対処法を理解します。
解説
FM システムは一度デプロイして終わりではなく、データ・モデル・ユーザー行動の変化に応じて継続的に診断・調整する必要があります。試験では「どの状況でどのオブザーバビリティツールを選ぶか」の設計判断、およびプロンプトのライフサイクル管理が問われます。
プロンプトの継続的メンテナンスサイクル
プロンプトは書いたら終わりではなく、次のサイクルで管理します。
| フェーズ | 内容 | AWS での実装例 |
|---|---|---|
| バージョン管理 | プロンプトを変更するたびにバージョンを記録し、どのバージョンがどの出力を生んだか追跡する | Amazon Bedrock Prompt Management / AWS SSM Parameter Store |
| ドリフト検出 | 定期的な評価スコアの計測で、スコアが閾値を下回ったら警告を出す | CloudWatch Alarm + Bedrock Model Evaluation の定期ジョブ |
| 回帰テスト | 新バージョンのプロンプトを golden dataset に通し、旧バージョンより悪化していないか確認する | CI/CD パイプライン(CodePipeline)+ 評価スクリプト |
| ロールバック | 本番スコアが悪化した場合、前バージョンのプロンプトへ即時差し戻す | SSM Parameter Store の旧バージョン参照 / Bedrock Prompt の旧バージョン起動 |
CloudWatch を使ったオブザーバビリティ
Amazon CloudWatch は FM システムのオブザーバビリティの中心です。活用ポイントは次のとおりです。
CloudWatch Metrics では、Bedrock から自動送信される InvocationLatency・InputTokenCount・OutputTokenCount・InvocationClientErrors・InvocationServerErrors を監視します。これらのメトリクスに対してアラームを設定することで、レイテンシ急増やエラー率上昇を即時検知できます。
CloudWatch Logs Insights では、ログに残った応答内容・トークン数・エラーの詳細を SQL 風クエリで掘り下げます。Bedrock の呼び出しログを有効化する方法は次のとおりです。
Python
import boto3, json
bedrock_client = boto3.client("bedrock", region_name="us-east-1")
# モデル呼び出しログを CloudWatch Logs に送る設定を有効化
bedrock_client.put_model_invocation_logging_configuration(
loggingConfig={
"cloudWatchConfig": {
"logGroupName": "/aws/bedrock/modelinvocations",
"roleArn": "arn:aws:iam::123456789012:role/BedrockLoggingRole",
},
"textDataDeliveryEnabled": True,
"imageDataDeliveryEnabled": False,
}
)CloudWatch Dashboard を作成して InvocationLatency・エラー率・トークン消費量をひとつの画面にまとめると、異常を視覚的に即時把握できます。
AWS X-Ray によるサービス間トレース
AWS X-Ray は、複数のマイクロサービスにまたがるリクエストの流れをサービスマップとして可視化します。FM システムにおける X-Ray の典型的な活用シーンは次のとおりです。
- API Gateway → Lambda → Bedrock SDK 呼び出しの経路でどのコンポーネントがレイテンシのボトルネックになっているかを特定する
- Bedrock Agents の内部ステップ(FM 推論・ツール呼び出し・Knowledge Base 検索)ごとの所要時間を可視化する
X-Ray と CloudWatch Logs Insights の使い分けは次のとおりです。X-Ray は「どのサービスが遅いか」を可視化するトレース用途、CloudWatch Logs Insights は「どのログエントリで何が起きたか」を集計する分析用途です。両方を組み合わせることで、「X-Ray で Lambda が遅いと判明した → Logs Insights でその Lambda のログを掘り下げる」という診断フローが完成します。
検索レイテンシの診断
RAG システムで検索レイテンシが高い場合の主な原因と対策は次のとおりです。
| 原因 | 対策 |
|---|---|
| ベクトルインデックスのサイズが大きすぎる | 不要なドキュメントを削除し、インデックスを再構築する |
| 上位 K 値が高すぎる | numberOfResults を下げ、再ランキングで品質を補う |
| ネットワーク・リージョンの遅延 | Knowledge Base と推論エンドポイントを同一リージョンに配置する |
| 埋め込み生成のレイテンシ | 検索クエリの埋め込みをキャッシュする(同一クエリの反復時) |
CloudWatch Logs Insights で fields @duration | stats avg(@duration) by bin(5m) のようなクエリを実行すると、時系列でレイテンシのトレンドが把握できます。
Agent ツール呼び出しのスキーマ検証エラー
Amazon Bedrock Agents はツール(アクショングループ)の仕様を OpenAPI スキーマで宣言します。スキーマ検証エラーの典型的な原因と診断手順は以下のとおりです。
- スキーマと Lambda の入出力の不一致 ― OpenAPI スキーマに定義されたフィールド名・型と Lambda 関数が実際に返す JSON のキー・型が異なる場合に発生します。CloudWatch Logs で Lambda のエラーログを確認します
- 必須フィールドの欠落 ― FM がスキーマ上で
required指定されたパラメータを渡さない場合、Agent が再試行ループに入ります。プロンプトに Few-shot 例を追加して FM の出力を誘導します - バージョン不一致 ― OpenAPI スキーマを更新したが Agent エイリアスが古いバージョンを参照したままの場合に発生します。エイリアスを最新バージョンに向け直します
試験で問われるポイント
- CloudWatch Logs Insights vs AWS X-Ray の使い分けは繰り返し問われます。「Bedrock の呼び出しエラーをクエリで集計したい」→ Logs Insights、「API Gateway から Bedrock までのレイテンシ分布をサービスマップで可視化したい」→ X-Ray というパターンを確実に押さえてください
- プロンプトのロールバックは SSM Parameter Store または Bedrock Prompt Management のバージョン機能で実現します。「プロンプトを Git で管理する」は実装としてはあり得ますが、試験の正答は AWS マネージドサービスによる管理を指します
- スキーマ検証エラーの根本原因は OpenAPI スキーマと Lambda の不一致です。CloudWatch Logs で Lambda の実行ログを確認することが診断の第一歩であり、X-Ray はその後の広域トレースに使います
サービスの使い分け早見表
| やりたいこと | 使うもの | 混同しやすいもの |
|---|---|---|
| Bedrock 呼び出しの平均レイテンシをグラフ化したい | CloudWatch Metrics + CloudWatch Dashboard | X-Ray(サービス間分散トレースが目的) |
| 複数サービスをまたいだボトルネックを特定したい | AWS X-Ray(サービスマップ) | CloudWatch Logs Insights(ログ集計が目的) |
| プロンプトの過去バージョンにロールバックしたい | Amazon Bedrock Prompt Management / SSM Parameter Store バージョン機能 | CloudWatch(ログ・メトリクス監視が目的) |
まとめ
プロンプトメンテナンスはバージョン管理・ドリフト検出・回帰テスト・ロールバックの 4 フェーズで運用します。CloudWatch Metrics と Logs Insights は Bedrock 単体の監視に使い、X-Ray はサービス間のトレースに使います。検索レイテンシは K 値・インデックスサイズ・リージョン配置の観点で診断し、スキーマ検証エラーは OpenAPI スキーマと Lambda の整合性確認を起点にします。この 4 つのオブザーバビリティ軸を組み合わせることで、本番 FM システムの継続的な品質維持が実現します。
次のステップ
次のクイズレッスンで、本番形式のシナリオ問題に挑戦して理解度を確認しましょう。
関連レッスン
- FM 評価フレームワーク・golden dataset・合成ワークフロー(pro-eval-framework-aws)
- RAG 評価・Agent 評価・タスク完了率・レポーティング(pro-eval-rag-agent)
- FM 統合・コンテキストウィンドウ・プロンプト・検索の診断(pro-troubleshoot-integration)