Amazon Bedrock

解決する課題

生成 AI アプリを作ろうとすると、どの基盤モデル（FM）を使うか、推論用の GPU をどう確保するか、モデルごとに異なる API をどう束ねるか、といった課題に直面します。Amazon Bedrock はこれらをまとめて引き受けます。

• 複数ベンダーの基盤モデルを単一の APIから選んで呼び出せる
• 推論用のインフラ運用やスケーリングは AWS 側が担い、自前の GPU 管理が不要
• RAG、エージェント、ガードレール、ファインチューニングといったアプリ構築の部品がそろっている

モデルを比較・切り替えしながら、API 呼び出しだけで生成 AI を組み込める点が中心的な価値です。

主要概念と用語

• 基盤モデル（FM）: 大量のデータで事前学習された汎用モデル。テキスト生成・要約・チャット・埋め込み・画像生成などに使う
• モデルプロバイダー: Bedrock 上で複数ベンダーのモデルが提供され、利用者は用途やコストで選択する
• 推論（インファレンス）: モデルにプロンプトを与えて応答を得る処理。同期的な応答とストリーミング応答の両方に対応する
• モデルアクセス: 各モデルは利用前に有効化（アクセス申請）が必要な場合がある
• プロンプト: モデルへの入力テキスト。指示・文脈・例などを含める
• トークン: モデルが処理する文字のまとまり。入力・出力トークン数が課金や上限の基準になる
• ナレッジベース: 自社データを取り込み、検索結果を文脈として与える RAG（検索拡張生成）の仕組み
• エージェント: モデルに外部 API 呼び出しや複数ステップの処理を実行させる仕組み
• ガードレール: 不適切な入出力や機微情報をフィルタ・制御する安全機構
• カスタマイズ: ファインチューニングや継続事前学習で、自社ドメインにモデルを適応させる仕組み

仕様・制限・クォータ

• テキスト生成、チャット、埋め込み（ベクトル化）、画像生成など、複数のモダリティのモデルが提供される
• 推論にはオンデマンドと、スループットを確保するプロビジョンドスループットの方式がある
• 1 リクエストあたりのトークン数や、モデルごとのリクエストレート（1 秒あたりの呼び出し数・トークン数）にクォータがあり、引き上げ申請が可能
• 利用できるモデルの種類はリージョンによって異なる
• 応答はまとめて返す方式と、逐次返すストリーミング方式を選べる

対応モデルの一覧・上限値・対応リージョンは更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、プロンプトを送ると AWS 側のマネージドなモデルが推論し、応答を返すブラックボックスとして扱えます。

• 推論: 共通の API にモデル ID とプロンプトを渡すと、対応するモデルが応答を生成する。モデルごとに推奨されるパラメータ（温度や最大トークン数など）を指定できる
• ナレッジベース（RAG）: 取り込んだドキュメントを埋め込みモデルでベクトル化してベクトルストアに保存し、質問時に関連箇所を検索してプロンプトの文脈として与える。これにより最新・自社固有の情報に基づいた回答を得る
• エージェント: モデルの判断にもとづいて、定義された外部 API（アクション）を呼び出したり、複数ステップの処理を組み立てたりする
• ガードレール: 推論の前後でポリシーに基づき入出力を検査し、禁止トピックや機微情報をブロック・マスクする
• カスタマイズ: 自社データでファインチューニングしたモデルは、専用にプロビジョニングされた容量上で推論する

モデルの学習基盤やスケーリング、ハードウェアの管理はすべて AWS 側が担います。

設計パターン / ベストプラクティス

• まずプロンプトで解く: ファインチューニングやカスタマイズの前に、プロンプト設計や少数の例示（フューショット）で要件を満たせないか試す
• 自社知識は RAG で与える: 社内文書や最新情報が必要なら、モデルを再学習せずナレッジベースで検索結果を文脈として渡す
• ストリーミングで体感を改善: チャット用途では応答をストリーミングし、ユーザーの待ち時間の体感を減らす
• モデルを用途で選ぶ: 速度・コスト・品質はモデルで異なるため、軽い処理は小さいモデル、難しい処理は高性能モデルへ振り分ける
• ガードレールを標準で組み込む: 本番では禁止トピックや個人情報のフィルタを既定で適用する

運用・監視

• API 呼び出し回数・トークン数・遅延などのメトリクスは CloudWatch で監視する
• 入出力（プロンプトと応答）のログ記録を有効化し、品質評価や監査に使う
• API 操作の監査証跡は CloudTrail に記録される
• レート上限に達した場合は再試行（バックオフ）を実装し、必要に応じてクォータ引き上げやプロビジョンドスループットを検討する

コスト

• 課金は基本的に処理した入力・出力トークン数に対する従量制で、サーバーの常時起動費用は発生しない
• 画像生成など一部のモダリティは生成数など別の単位で課金される傾向がある
• 高く安定したスループットが必要な場合は、容量を予約するプロビジョンドスループットを選べるが、予約に対して課金される
• ナレッジベースで使うベクトルストアや埋め込み処理、カスタマイズ（学習）には追加費用が伴う場合がある

具体的な単価はモデルやリージョンで異なり変動するため、料金は公式の料金ページで確認してください。小さく検証してから本番ボリュームを見積もるのが安全です。

セキュリティ

• アクセス制御は IAM で行い、利用するモデルや操作に対して最小権限のみを付与する
• 通信は TLS で保護され、保存データの暗号化には KMS 管理鍵を利用できる
• プロンプトや応答が基盤モデルの学習に使われない点はサービスの重要な前提であり、機密データの取り扱いを設計する際に押さえる
• VPC 内のリソースからプライベートに到達したい場合は、**PrivateLink（VPC エンドポイント）**経由のアクセスを検討する
• 機微情報の混入や不適切な出力を防ぐため、ガードレールを組み合わせる

Well-Architected の観点

• 運用上の優秀性: マネージドサービスにより推論基盤の運用負荷を下げ、CloudWatch・CloudTrail で利用状況と監査を可観測化できる
• セキュリティ: IAM の最小権限、暗号化、ガードレール、プライベート経路で入出力とデータを保護する
• コスト最適化: 用途に合うモデル選定と従量課金の活用、安定負荷ではプロビジョンドスループットを比較検討する
• 信頼性: スロットリングを前提にリトライを実装し、複数モデルへフォールバックできる構成にする

試験で問われるポイント

関連サービス・比較

機械学習のフルマネージド基盤である Amazon SageMaker とは目的が異なるため比較します。

ハンズオン / CLI例

# 利用可能な基盤モデルの一覧を確認
aws bedrock list-foundation-models \
  --query "modelSummaries[].{ID:modelId,Provider:providerName}"

# 基盤モデルにプロンプトを送って応答を取得（モデル ID と本文はモデル仕様に合わせる）
aws bedrock-runtime invoke-model \
  --model-id <利用するモデルID> \
  --body '{"prompt":"AWSのBedrockをCLI初学者向けに1文で説明して","max_tokens":200}' \
  --content-type application/json \
  output.json