FM 統合・コンテキストウィンドウ・プロンプト・検索の診断｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D5 タスク 5.2.1–5.2.4。FM 統合時に起きる代表的な障害パターン（コンテキストオーバーフロー・プロンプト劣化・検索品質低下・セマンティックドリフト）と、Amazon CloudWatch Logs Insights を使った診断アプローチを理解します。

解説

FM を本番システムに統合すると、モデル単体のベンチマーク結果と実運用の品質が乖離することがあります。試験では「症状から原因を特定し、適切な診断ツールを選択する」トラブルシューティング設計力が問われます。

コンテキストウィンドウ超過の診断

FM には処理できるトークン数の上限（コンテキストウィンドウ）があります。超過した場合の典型的な症状は次のとおりです。

入力の後半部分が無視されたような応答になる
ValidationException: Input is too long などのエラーが返る
RAG システムで多数のチャンクを詰め込みすぎると精度が急落する

診断項目	確認方法
リクエストごとのトークン数	CloudWatch Logs の Bedrock 呼び出しログから `inputTokenCount` を抽出
上位 K チャンクの合計文字数	Knowledge Base 検索の `numberOfResults` パラメータを段階的に下げてスコアを比較
エラーレート	CloudWatch Metrics の `4XXError` を用途別にフィルタリング

コンテキストウィンドウ超過への対策としては、チャンクの再ランキング（上位 K の削減）・要約挿入・会話履歴の要約圧縮が有効です。

CloudWatch Logs Insights による診断

Amazon CloudWatch Logs Insights は、大量のログを SQL 風クエリで即座に集計できるサービスです。Bedrock の呼び出しログを有効化すると、inputTokenCount・outputTokenCount・レイテンシ・エラーコードが自動的に記録されます。

Python

import boto3

logs_client = boto3.client("logs", region_name="us-east-1")

# Bedrock 呼び出しログから入力トークン数が大きいリクエストを抽出
query = """
fields @timestamp, modelId, input.inputTokenCount as inTokens, output.outputTokenCount as outTokens
| filter ispresent(inTokens)
| sort inTokens desc
| limit 20
"""

resp = logs_client.start_query(
    logGroupName="/aws/bedrock/modelinvocations",
    startTime=1700000000,
    endTime=1700003600,
    queryString=query,
)
print("queryId:", resp["queryId"])

Logs Insights のクエリはサーバーレスで即時実行でき、大量ログの集計に向いています。一方で、X-Ray はサービス間のトレース（どのマイクロサービスがどの順で呼ばれたか）を可視化するものであり、ログの全文検索には向きません。

プロンプトの劣化診断

プロンプトが意図通りに機能しているかを診断するポイントは次のとおりです。

プロンプトバージョン管理 ― Amazon Bedrock Prompt Management（または SSM Parameter Store）でプロンプトをバージョン管理し、変更前後の出力分布を比較します
出力フォーマット崩れ ― JSON 出力を期待するプロンプトでモデルが自然文を返す場合、Few-shot 例の不足またはシステムプロンプトの矛盾が原因であることが多いです
インジェクション痕跡 ― 外部コンテンツをプロンプトに組み込む RAG 構成では、チャンクに含まれる指示文字列がシステムプロンプトを上書きするプロンプトインジェクションのリスクがあります

埋め込み品質低下とセマンティックドリフトの診断

RAG の検索精度が徐々に低下する原因として埋め込み品質低下とセマンティックドリフトがあります。

原因	概要	診断手順
埋め込みモデルのミスマッチ	インデックス作成時と検索時で異なる埋め込みモデルを使っている	Knowledge Base の埋め込みモデル設定を確認。再インデックスで解消
セマンティックドリフト	業界用語・製品名の意味が時間とともに変化し、古い埋め込みが意味を正確に反映しなくなる	定期的にサンプルクエリの検索結果を人手で確認。Recall@K をモニタリング
チャンク境界の問題	文書の論理的な区切りと無関係な固定長チャンクが関連情報を分断する	チャンクサイズとオーバーラップを調整して検索スコア分布を比較

セマンティックドリフトは一度の診断では検出しにくく、定期評価スケジュール（週次・月次）と golden dataset の最新化が対策の核になります。

試験で問われるポイント

CloudWatch Logs Insights vs AWS X-Ray の使い分けは最重要です。Logs Insights はログの集計・フィルタリング、X-Ray はサービス間の分散トレースです。「Bedrock 呼び出しのエラー率を集計したい」なら Logs Insights、「どのマイクロサービスでレイテンシが発生しているか可視化したい」なら X-Ray が正答になります
セマンティックドリフトへの対応は再インデックス（re-indexing）です。埋め込みモデル自体を更新するのではなく、既存ドキュメントを最新の埋め込みモデルで再ベクトル化し、インデックスを差し替えます
プロンプトインジェクションは外部コンテンツをプロンプトに組み込む RAG 構成特有のリスクです。Amazon Bedrock Guardrails の「Denied topics」や入力サニタイズで対応します（Guardrails は別トピックですが試験では連動して問われます）

サービスの使い分け早見表

やりたいこと	使うもの	混同しやすいもの
Bedrock 呼び出しエラーをログ集計で診断したい	Amazon CloudWatch Logs Insights	AWS X-Ray（サービス間トレースが目的）
RAG の埋め込み品質が落ちた原因を調べたい	Knowledge Base の埋め込みモデル設定確認 + 再インデックス	CloudWatch Metrics（メトリクス監視が目的）
プロンプトの変更前後を比較検証したい	Bedrock Prompt Management + A/B 評価	Model Monitor（推論後のデータドリフト監視が目的）

まとめ

FM 統合のトラブルシューティングは「コンテキスト超過・プロンプト劣化・埋め込み品質・セマンティックドリフト」の 4 象限で整理できます。診断の主要ツールは Amazon CloudWatch Logs Insights であり、Bedrock の呼び出しログを有効化した上で SQL 風クエリで絞り込みます。X-Ray はサービス間トレース用であり、ログ集計には適しません。セマンティックドリフトには定期再インデックスと golden dataset の最新化が有効です。

次のステップ

次のクイズレッスンで、本番形式のシナリオ問題に挑戦して理解度を確認しましょう。