Amazon Bedrock ベストプラクティス

Amazon Bedrock で生成 AI アプリケーションを設計・運用するときの実践的な指針をまとめたものです。モデルの一覧、料金、リージョン対応は頻繁に変わるため、具体的な数値は必ず AWS 公式ドキュメントと料金ページで確認してください。

---

目次

• 1. モデル選定
• 2. プロンプト設計
• 3. コスト最適化
• 4. 可用性・スケーラビリティ
• 5. セキュリティ
• 6. 責任ある AI（Guardrails）
• 7. RAG（Knowledge Bases）
• 8. エージェント（Bedrock Agents / AgentCore）
• 9. モデルカスタマイズ
• 10. 監視・運用
• 11. 開発プロセス
• チェックリスト

---

1. モデル選定

• ユースケース起点で選ぶ: 精度・レイテンシ・コストの3軸で要件を決め、複数モデルを比較してから決定する。「最も高性能なモデル」を最初から使う必要はない。
• 小さいモデルから試す: 分類・抽出・要約などの定型タスクは、軽量モデル（Claude Haiku 系、Amazon Nova Micro / Lite など）で十分な場合が多い。
• タスクごとにモデルを使い分ける: ルーティング、要約、最終回答生成など処理ステップ単位で最適なモデルを割り当てる。
• Intelligent Prompt Routing の活用: 同一モデルファミリー内で、プロンプトの難易度に応じて自動的にモデルを振り分けられる。対応モデル・言語の制約は事前に確認する。
• Model Evaluation で定量評価: 自社データの評価セットを用意し、Bedrock の評価機能（自動評価・LLM-as-a-Judge・人手評価）で比較する。感覚ではなくスコアで判断する。
• モデルアクセスとリージョンを事前確認: 利用したいモデルが対象リージョンで有効か、モデルアクセスが許可されているかを確認する。

2. プロンプト設計

• Converse API を標準にする: モデル間で統一されたインターフェースのため、モデル切り替えが容易になる。ツール使用（Function Calling）やストリーミングにも対応。
• システムプロンプトで役割・制約・出力形式を明示する。
• 出力形式を構造化する: JSON スキーマやツール定義を使い、後続処理でパースしやすくする。
• Few-shot 例を入れる: 良い例・悪い例を示すと出力の安定性が上がる。
• Prompt Management でバージョン管理: プロンプトをコードに直書きせず、バージョン付きで管理し、変更履歴と比較を可能にする。
• 静的な部分を先頭に置く: プロンプトキャッシュを効かせるため、システムプロンプトや参照文書など変化しない部分を前に、ユーザー入力など変化する部分を後ろに配置する。

3. コスト最適化

その他のポイント:

• 出力トークンを制御する: maxTokens を適切に設定し、プロンプトで簡潔な回答を指示する。出力トークンは入力より高単価なことが多い。
• 不要なコンテキストを送らない: RAG で取得するチャンク数や会話履歴の長さを見直す。
• プロンプトキャッシュの注意点: キャッシュ対象の接頭部分が少しでも変わるとキャッシュミスになる。オンデマンド推論でのみ対応（バッチ推論は非対応）。キャッシュの最小トークン数や TTL はモデルごとに異なる。
• コスト配分タグ・Application Inference Profile: アプリケーションやチーム単位で利用量を把握し、コストを配分できるようにする。
• AWS Budgets と Cost Anomaly Detection で想定外の請求を早期検知する。

4. 可用性・スケーラビリティ

• クロスリージョン推論（Inference Profile）を使う: 同一地域（geography）内の複数リージョンにリクエストを分散し、スループットと可用性を高める。追加料金なし。
  • データが送信元リージョン外で処理される可能性があるため、データ所在地の要件を確認する。
  • グローバル推論プロファイルと地域限定プロファイルの違いを理解して選ぶ。
• クォータを把握し、事前に引き上げ申請する: RPM（リクエスト数/分）・TPM（トークン数/分）の上限を Service Quotas で確認する。
• スロットリング対策: ThrottlingException に対して指数バックオフ＋ジッターでリトライする（AWS SDK のリトライ設定を活用）。
• フォールバック設計: 主モデルが利用できない場合に代替モデルへ切り替える仕組みを用意する。
• ストリーミング応答: ConverseStream を使い、体感レイテンシを下げる。
• タイムアウトを適切に設定: 長い出力を生成する場合、クライアント側の読み取りタイムアウトを十分に長くする。

5. セキュリティ

アクセス制御

• 最小権限の IAM ポリシー: bedrock:InvokeModel などのアクションを、使用するモデル ARN や Inference Profile に限定する。
• サービスロールの権限を絞る: エージェントやナレッジベースのサービスロールは必要なリソースのみに限定し、aws:SourceAccount / aws:SourceArn 条件で Confused Deputy を防ぐ。
• API キーは短期キーを優先: 長期 API キーは漏えいリスクが高い。本番では IAM ロールによる一時認証情報を基本とする。
• SCP でモデル利用を統制: 組織として許可するモデルやリージョンを Service Control Policy で制限する。

ネットワーク・暗号化

• VPC エンドポイント（AWS PrivateLink） でインターネットを経由せずに Bedrock へ接続する。
• カスタマー管理キー（KMS CMK） でカスタムモデル、エージェントのセッション、ナレッジベース、Guardrails などを暗号化する。
• モデルカスタマイズジョブは VPC 内で実行し、学習データへのアクセス経路を保護する。

データ保護

• Bedrock は入力・出力をモデルの学習に使用せず、モデルプロバイダーとも共有しない。この点を社内のセキュリティ審査資料に明記しておくとスムーズ。
• 機密情報を含むデータを扱う場合は、Guardrails の機密情報フィルターでマスキングする。

6. 責任ある AI（Guardrails）

• Amazon Bedrock Guardrails を必ず設定する:
  • コンテンツフィルター（有害カテゴリ）
  • プロンプト攻撃フィルター（プロンプトインジェクション・ジェイルブレイク対策）。強度は HIGH を推奨
  • 拒否トピック（業務範囲外の話題）
  • ワードフィルター
  • 機密情報フィルター（PII の検出・マスキング）
  • コンテキストグラウンディングチェック（RAG 回答のハルシネーション検出）
  • Automated Reasoning チェック（ポリシーに対する論理的な検証）
• 入力と出力の両方に適用する。
• ApplyGuardrail API で、Bedrock 以外のモデルや任意のテキストにも同じガードレールを適用できる。
• 誤検知とのバランスを調整: テストセットで過剰ブロックと見逃しを確認し、しきい値を調整する。
• ガードレールもバージョン管理し、変更を段階的にリリースする。

7. RAG（Knowledge Bases）

• チャンク戦略を検証する: 固定長・階層・セマンティックチャンキングなどを、実データで比較して選ぶ。
• メタデータを付与してフィルタリング: 部署・文書種別・日付などで検索範囲を絞り、精度とセキュリティを高める。
• ハイブリッド検索（ベクトル＋キーワード）を検討する。固有名詞や型番の検索に強い。
• リランキングモデルで検索結果の上位精度を改善する。
• パーサーを選ぶ: 表や図を含む PDF は、基盤モデルによるパースや Bedrock Data Automation を検討する。
• データソースの同期を自動化し、情報の鮮度を保つ。
• データ削除時の挙動を確認: データソース削除時にベクトルストアのデータを保持するか削除するかを明示的に設定する。
• 引用（citations）を返す: 回答の根拠をユーザーに示し、信頼性を高める。
• RAG 評価: 検索の関連性と回答の忠実性を、Bedrock の RAG 評価機能などで定期的に測定する。

8. エージェント（Bedrock Agents / AgentCore）

• 用途で使い分ける: シンプルなタスク自動化はマネージドな Bedrock Agents、任意のフレームワーク（Strands Agents、LangGraph など）で本格的なエージェントを本番運用するなら Amazon Bedrock AgentCore を検討する。
• ツールは小さく明確に: 各ツール（Action Group）の説明・入力スキーマを具体的に書く。曖昧な説明は誤ったツール呼び出しにつながる。
• ツールの権限を最小化: エージェントが実行できる操作を限定し、更新・削除系の操作には人間の確認（Return of Control / 承認ステップ）を挟む。
• セッション分離と認証: AgentCore Identity などでユーザーごとに認証情報を分離し、他ユーザーのデータにアクセスできないようにする。
• メモリ設計: 短期（セッション内）と長期（ユーザーの嗜好など）を分け、保持期間と個人情報の扱いを決める。
• トレースで挙動を可視化: 推論ステップ、ツール呼び出し、エラーを記録し、デバッグと改善に使う（AgentCore Observability など）。
• エージェント評価: タスク完了率、ツール選択の正確さ、ステップ数などを評価セットで継続的に測る。
• ループ・暴走対策: 最大ステップ数やタイムアウトを設定する。

9. モデルカスタマイズ

• まずプロンプトと RAG で解決を試みる: ファインチューニングはコストと運用負荷が大きい。知識の追加は RAG、振る舞いや形式の調整はファインチューニング、と役割を分ける。
• データ品質を最優先: 少量でも高品質で一貫したデータが重要。評価用データは学習データと分ける。
• 蒸留を検討する: 大きいモデルの出力を教師として小さいモデルを最適化し、コストとレイテンシを下げる。
• カスタムモデルは CMK で暗号化し、学習ジョブは VPC 内で実行する。
• ベースモデルとの比較評価を必ず行い、改善が確認できてから本番投入する。

10. 監視・運用

• モデル呼び出しログを有効化する: アカウントレベルで Model Invocation Logging を有効にし、S3 / CloudWatch Logs に入出力を記録する（機密情報の扱いとログの保持期間に注意）。
• CloudWatch メトリクスを監視: 呼び出し回数、レイテンシ、スロットリング、エラー、入出力トークン数にアラームを設定する。
• CloudTrail で API 操作を監査する。
• 品質の継続モニタリング: 本番の入出力をサンプリングして評価し、品質の劣化を検知する。ユーザーフィードバック（👍/👎）を収集する。
• モデルのライフサイクル管理: モデルには提供終了（Legacy / EOL）がある。ライフサイクル情報を定期的に確認し、移行計画を立てておく。
• AWS Audit Manager の生成 AI ベストプラクティスフレームワークでガバナンス状況を確認する。

11. 開発プロセス

• IaC で管理: Guardrails、ナレッジベース、エージェント、IAM などを CloudFormation / CDK / Terraform で定義する。
• 環境を分離: 開発・ステージング・本番でアカウントを分け、本番データの扱いを統制する。
• 評価を CI/CD に組み込む: プロンプトやモデルを変更したら、評価セットで回帰テストを自動実行する。
• 段階的リリース: 新しいモデルやプロンプトは一部トラフィックで A/B テストしてから全体に展開する。

---

チェックリスト

セキュリティ

• IAM ポリシーは最小権限でモデル ARN を限定している
• 長期 API キーを本番で使っていない
• VPC エンドポイント経由で接続している
• 必要なリソースを KMS CMK で暗号化している
• サービスロールに Confused Deputy 対策の条件を付けている

責任ある AI

• Guardrails を入力・出力の両方に適用している
• プロンプト攻撃フィルターを HIGH に設定している
• 機密情報フィルターを設定している

コスト

• タスクに対して過剰なモデルを使っていない
• プロンプトキャッシュが効くプロンプト構成になっている
• 非リアルタイム処理はバッチ推論を使っている
• コスト配分タグと予算アラートを設定している

可用性

• クロスリージョン推論を使っている（データ所在地の要件を確認済み）
• クォータを確認し、必要なら引き上げ済み
• リトライ（指数バックオフ）とフォールバックを実装している

運用

• モデル呼び出しログを有効化している
• CloudWatch アラームを設定している
• 評価セットを用意し、変更時に回帰テストしている
• 利用モデルのライフサイクル（提供終了予定）を把握している

---

参考リンク

• Amazon Bedrock ユーザーガイド
• プロンプトキャッシュ
• Amazon Bedrock AgentCore 開発者ガイド
• Amazon Bedrock 料金
• AWS Audit Manager 生成 AI ベストプラクティスフレームワーク