AWS Certified Generative AI Developer - Professional
最終確認：2026年5月
AIP-C01 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
ユースケースに合ったBedrock基盤モデルを選択します。
長文コンテキストの推論 + ツール利用 → Claude (Sonnet/Opus)。コスト最適化されたチャット → Claude HaikuまたはTitan Text Lite。コード → ClaudeまたはLlama。埋め込み → Titan Embeddings V2またはCohere Embed。画像生成 → Titan Image、Stable Diffusion、またはNova Canvas。自己ホスト制御が可能なオープンウェイトモデル → Llama、Mistral、またはCustom Model Import。
理由: コスト、レイテンシー、能力、ライセンス条件の全てにおいて最適な単一モデルはありません。モデルの種類をボトルネックに合わせてください。
KBのソースが短く、自己完結型のFAQや製品紹介文（それぞれ約100～500語）である。
デフォルトのトークンサイズ (300) とオーバーラップ (20%) で固定サイズチャンキング。
理由: 自己完結型のユニットは、境界を意識したチャンキングの恩恵を受けません。固定サイズは最もシンプルで安価です。
ドキュメントには段落内に自然なトピックの転換があり、固定サイズ分割では文が途中で途切れてしまう。
セマンティックチャンキング。Bedrock Knowledge Basesは埋め込みが近い連続した文をグループ化し、意味の境界で分割します。
理由: チャンク内の整合性のあるアイデアを保持する → よりクリーンな検索、より高い回答品質。
セクション間に相互参照がある長い技術マニュアル。ドキュメント全体からの統合が必要な質問。
階層型チャンキング。Bedrockは親（大）+子（小）チャンクを作成し、子チャンクの埋め込みで検索し、親コンテキストを返します。
理由: 小さいチャンクは正確な検索を提供し、親コンテキストは相互参照と周囲の詳細を保持します。
ソースファイルが事前にチャンク化されているか、各ファイルが意図的に1つの論理ユニットである。
チャンキング戦略なし。各ファイルがKBの1つのチャンクになります。
PDFソースにテキストと図が含まれており、ユーザーは図の理解を必要とする質問をする。
基盤モデル (Claude/Nova) をパーサーとして使用して、Bedrock KBの高度な解析を有効にします。図と表はビジョンによって記述され、その後埋め込まれます。
理由: デフォルトの解析はテキストのみです。マルチモーダル解析は、視覚コンテンツを埋め込み前に記述テキストに変換します。
Titan Embeddings G1とV2のどちらを選択するか。
V2は設定可能な次元 (256/512/1024) をサポートし、多言語ベンチマークでG1を上回ります。G1は1536に固定されています。ストレージ制約のあるユースケースや非英語のユースケースにはV2を選択し、レガシー互換性のみG1を選択します。
50万点の製品カタログ：短いタイトル（50語）+長い仕様（500語）。検索品質とコストを最適化したい。
各アイテムを一度埋め込み（結合または別々のフィールド）。コストのために次元を減らした (256または512) Titan Embeddings V2を使用し、クエリとドキュメントを同じモデルで埋め込みます。
理由: 埋め込みモデルを混ぜたり正規化をスキップしたりすると、類似性検索が壊れます。低次元化は、わずかな品質の損失でストレージとクエリのコストを削減します。
Bedrock Knowledge Bases用のベクターストアを選択します。
デフォルト/最速のセットアップ → Amazon OpenSearch Serverless (自動管理)。サブミリ秒で頻繁なスキーマ更新 + リレーショナル結合 → pgvectorを備えたAurora PostgreSQL。既存のPinecone / MongoDB Atlas / Redis顧客 → それらを維持。小規模KB (<1万ドキュメント) コスト最適化 → Aurora pgvectorまたはNeptune Analytics。
理由: OpenSearch Serverlessは最も簡単なデフォルトの選択肢です。Aurora pgvectorは、メタデータに対するトランザクションや結合が必要な場合に優れています。
KBが意味的に関連するドキュメントを返しますが、それらが古い/間違ったリージョンのバージョンである。
ソースファイルにメタデータ (`version`, `region`, `effective_date`) を追加し、クエリ時に`retrievalConfiguration.vectorSearchConfiguration.filter`を介してメタデータフィルターを適用します。
理由: 純粋なベクトル類似性は新しさや権威を無視します。メタデータフィルタリングは、ランキング前に候補プールを絞り込みます。
RAGが、正確な識別子（SKU、エラーコード、規制番号）を含むクエリを見逃すことがあります。セマンティック検索が類似の意味のテキストを過度に重視するためです。
KBでハイブリッド検索 (セマンティック + キーワード/BM25) を有効にします。ベクトル類似性と、ID、コード、固有名詞の語彙マッチを組み合わせます。
Top-k=5で5つのチャンクが検索されるが、最も関連性の高いものが3番目または4番目にランクされることが多い。
`numberOfResults`を20に増やし、その後、元のクエリとの関連性に基づいて並べ替えるためにrerankingモデル (Cohere RerankまたはAmazon Rerank) を有効にします。
理由: 埋め込みの類似性 ≠ タスクの関連性。クロスエンコーダーのrerankerはクエリとチャンクを一緒に見て、正確にスコアを付けます。
ユーザーの質問が会話形式、複数パート、または代名詞/追跡を含んでおり、KB検索の品質が低下する。
Bedrock KBのクエリ再定式化を有効にします。モデルは複雑なクエリを、検索前に複数の焦点を絞ったサブクエリに書き換えます。
S3ソースドキュメントが頻繁に更新され、KBは手動同期なしで常に最新バージョンを反映する必要がある。
S3イベント通知 → EventBridge → StartIngestionJob を介した自動同期、またはKBのスケジュールされた同期のためにKBデータソースを設定します。手動コンソールの「Sync」ボタンに頼るのは避けてください。
長文QAモデルが、文書の中央にある質問の答えについて幻覚を起こす。
プロンプトに完全なドキュメントを渡さないでください。RAGを介してチャンク化+検索し、関連するチャンクのみがモデルに到達するようにします。もし完全なドキュメントが必須の場合、強力な長文コンテキスト想起能力を持つモデル (Claude Sonnet 200K) を使用し、ドキュメントの後に質問を配置します。
理由: ほとんどのLLMは「途中で失われる」想起能力の低下を示します。RAGはそれを回避します。RAGが利用できない場合、配置が役立ちます。
品質基準を満たす最も安価なカスタマイズを選択します。
順に試してください： (1) プロンプトエンジニアリング、(2) KBとRAG、(3) ファインチューニング、(4) 継続的な事前学習、(5) Custom Model Import。基準を満たした時点で停止します。
理由: 各ステップで労力と継続的なコストが増加します。ファインチューニングとProvisioned ThroughputはRAGよりもはるかに高価です。
ラベル付けされたタスクの例を使用してBedrockモデルをファインチューニングする。
S3にJSONLファイルを用意し、1行につき1つの例を記述します：`{"prompt": "...", "completion": "..."}`（またはモデルファミリーのチャット形式の同等物）。
理由: 各モデルファミリー (Titan, Claude, Llama) には特定のスキーマがあります。フォーマットする前にモデルのファインチューニングドキュメントを確認してください。
大量のラベルなしドメインテキストを使用して、基盤モデルを専門用語（法律、医療、科学）に適応させる。
ラベルなしドメインコーパスに対する継続的な事前学習。命令ファインチューニング（プロンプトと完了のペアが必要）とは異なります。
理由: 継続的な事前学習は言語理解を更新し、命令ファインチューニングはタスクの振る舞いを教えます。データ形状と目標が異なります。
ファインチューニング用の顧客インタラクションデータに、氏名、メールアドレス、電話番号が含まれている。
トレーニングデータセットをS3にアップロードする前に、PIIをスクラブまたはトークン化します。一度ウェイトがPIIを吸収すると、出力フィルタリングでは確実にマスクできません。
理由: ファインチューニングされたモデルがトレーニングデータの断片を再現する可能性があります。データ層でのスクラブが唯一の持続的な緩和策です。
自己ファインチューニングしたLlamaまたはMistralモデルを持ち込み、Bedrockの統合APIを通じて提供する。
Custom Model Import。ウェイトをS3にアップロードし、Bedrockに登録し、統合されたIAMとロギングを備えたBedrockランタイムを介して呼び出します。
理由: SageMakerエンドポイントを立てることなく、持ち込みウェイトでBedrock Guardrails、KB、Agentsを再利用できます。
ファインチューニングされたBedrockモデルを本番環境で提供する。
Provisioned Throughputを購入します。カスタムモデル（ファインチューニングされたモデル、継続的に事前学習されたモデル、インポートされたモデル）はオンデマンドで呼び出すことはできません。
高トラフィックのClaudeアプリケーションがピーク時にリージョンごとのクォータに達し、Provisioned Throughputを購入せずにスループットを上げる必要がある。
クロスリージョン推論プロファイル。Bedrockは複数のリージョン間で透過的に呼び出しをルーティングし、実効的なTPM/RPMクォータを向上させます。
理由: 単一リージョンのオンデマンドクォータはスパイク時に上限に達します。クロスリージョンプロファイルは、推論プロファイルのARNを使用する以外のアプリケーションコードの変更なしに、クォータをほぼ倍増させます。
us-east-1にデプロイされたBedrockアプリで、APACユーザーがUS/EUユーザーよりも著しく高いレイテンシーを経験している。
ap-northeast-1 / ap-southeast-1 / ap-south-1 (モデルがGAであるリージョン) にリージョン別Bedrockエンドポイントをデプロイします。Route 53のレイテンシーまたは地理位置情報ポリシーを介してユーザーをルーティングします。
理由: 長文コンテキストではLLMの往復時間が支配的であり、太平洋横断のRTTだけでも150～250msかかります。
HIPAA規制下のアプリがBedrockでPHIを要約する必要がある。
HIPAA対象サービスリストに記載されているHIPAA対象基盤モデルのみを使用します。AWSとBAAを締結します。プロンプト/応答を顧客管理KMSキーで暗号化します。モデル呼び出しロギングを無効にするか、アクセス制限されたプライベートS3バケットにスコープします。
機密性（公開/機密/制限）に基づいて、Bedrockに流すことができるデータを決定する。
公開 → 制限なし。機密 → VPCエンドポイント + CMK + プライベートバケットでの呼び出しロギングのみを介して。制限付き（企業秘密、規制対象PHI/PCI）→ Bedrockから完全にブロックするか、Bedrock対象のコンプライアンス体制を使用し、呼び出し前に編集します。
マルチアカウント組織で、アカウントAがウェイトをコピーすることなく、カスタムBedrockモデルをアカウントBと共有したい。
AWS RAMを介したカスタムモデル共有。所有者がカスタムモデルARNを共有し、消費アカウントはリソースポリシー上のクロスアカウントIAMプリンシパルで標準のBedrockランタイムを通じてそれを呼び出します。
理由: 冗長なファインチューニングコストを回避し、モデルライフサイクルを一元化します。RAMは、共有リソースを誰が利用できるかを制御します。
標準のBedrockカタログにないニッチなサードパーティモデル（例：ヘルスケアに特化したLLM）が必要である。
Amazon Bedrock Marketplace。Marketplaceカタログからモデルをサブスクライブし、Bedrockエンドポイントにデプロイし、標準のランタイムAPIを介して呼び出します。
理由: サードパーティの請求、IAM、KMS、オブザーバビリティをファーストパーティのBedrockモデルと統一します。
高ボリューム検索アプリが、クエリを更新するたびに同じドキュメントを再埋め込みしており、埋め込みコストが支配的である。
ドキュメント取り込み時に埋め込みを事前に計算し、ドキュメントID + コンテンツハッシュをキーとしてDynamoDBまたはOpenSearchにベクトルを保存します。コンテンツハッシュが変更された場合にのみ再埋め込みします。
理由: 同じテキストを繰り返し埋め込むことは、最も一般的で回避可能なコストです。ハッシュをキーとするキャッシュはO(1)のスキップです。
ファインチューニングされたモデルに対するGDPRの忘れられる権利：ユーザーがトレーニングデータからのPIIの削除を要求する。
トレーニングコーパスからレコードを削除し、その後、新しいベースモデルをゼロからファインチューニングします。既存のウェイトからデータを確実にスクラブすることはできません。出力フィルタリングでは不十分です。
理由: 一度ウェイトがトレーニングデータを吸収すると、推論時のマスキングは信頼できません。防御可能な方法は、影響を受けるレコードなしでの完全な再トレーニングです。
共有KBが複数のチームにサービスを提供しており、各チームは自社のドキュメントのみを参照できる必要がある。
取り込み時にすべてのチャンクに`tenant_id` / `team_id` / `clearance`メタデータをタグ付けします。クエリ時に`retrievalConfiguration.vectorSearchConfiguration.filter`を呼び出し元のIAMセッションまたはアプリコンテキストからの許可された値に設定します。
理由: ベクトル類似性はアクセス制御を無視します。メタデータフィルタリングは、共有KBにおけるテナントごとの唯一の耐久性のある分離手段です。
EUの顧客は、プロンプトとKBの埋め込みがeu-west-1から決して離れないことを要求している。
Bedrock + KB + S3ソースバケットをeu-west-1にデプロイします。eu-west-1にスコープされた推論プロファイルARNを介して呼び出しを固定し、`bedrock:*`に対して他のリージョンでのSCP `aws:RequestedRegion` denyを適用します。
複数ステップのワークフローで、LLM推論、外部API/データベースへの呼び出し、および統合が必要である。
Amazon Bedrock Agent。指示、アクショングループ（Lambda + OpenAPIスキーマ）、およびオプションのKBを定義します。エージェントは計画を立て、ツールを呼び出し、結果を統合します。
理由: オーケストレーションループを自分で書く手間を省きます。組み込みのトレース、セッションメモリ、およびReturn-of-controlフックがあります。
Bedrock Agentが3つの内部API (CRM、在庫、支払い) を呼び出す必要がある。
APIごとに1つのアクショングループを定義します。各アクショングループには、操作を記述するOpenAPIスキーマと、呼び出しを実行するLambda関数（またはReturn-of-controlエンドポイント）があります。
エージェントは、人間/ビジネスの確認後にのみ、高リスクの操作（アカウント削除、多額の払い戻し）を実行する必要がある。
Return of Control (RoC) でアクショングループを設定します。Bedrockは提案されたアクションを呼び出す代わりにアプリケーションに返し、アプリケーションは承認の背後に実行をゲートし、結果を再送信します。
理由: 高リスクのステップをエージェントランタイムの外部に保持し、実行される前に監査または人間による確認を可能にします。
エージェントは、単一ユーザーセッション内のターン間でコンテキストを記憶する必要がある。
エージェントの組み込みセッション属性とプロンプトセッション属性を使用します。`sessionId`をInvokeAgentに渡すと、Bedrockは設定されたアイドルタイムアウトまで会話状態を保持します。
エージェントは、セッションをまたいで再訪するユーザーに関する事実（好み、履歴）を想起し、古いやり取りを要約する必要がある。
Bedrock Agentのメモリを有効にします。エージェントは`memoryId`ごとに要約されたセッション履歴を永続化し、将来の呼び出し時にコンテキストとして再生します。
ワークフローで、トップレベルのプランナーによって調整される専門エージェント（研究、コード、請求）が必要である。
Bedrock Agentsのマルチエージェント連携：1つのスーパーバイザーエージェントと複数のコラボレーターエージェントを定義します。スーパーバイザーはコラボレーターの記述に基づいてサブタスクを委任し、結果を統合します。
抽出 → 分類 → ルーティング → 要約という複数ステップのパイプラインで、条件分岐も必要である。
Amazon Bedrock Prompt Flows。プロンプトノード、条件ノード、KBノード、Lambdaノードを含むビジュアルワークフロー。バージョン管理され、単一のAPIとして呼び出し可能です。
理由: プロンプトパイプラインの手作業のStep Functionsを置き換え、単一のエントリポイントを公開します。
マルチテナントSaaS：テナントごとのシステムプロンプト、モデルの好み、およびバージョン管理。
Amazon Bedrock Prompt Management。プロンプトをバージョン管理され、パラメータ化されたアセットとして保存し、ランタイム時にARNで参照し、テナントごとに異なるバージョンをA/Bテストします。
アプリがClaude、Llama、Titan、Cohereを1つのチャットスタイルのAPIで動作させる必要がある。
Bedrock Converse APIを使用します。モデルファミリー全体で統一されたメッセージリスト形式、ツール利用、システムプロンプト。ポータビリティが重要な場合は、モデル固有のInvokeModel JSONを避けてください。
チャットボットが知覚されるレイテンシーを削減するために、応答をトークンごとに表示する必要がある。
ConverseStream (またはInvokeModelWithResponseStream) を使用します。API Gateway WebSocketまたはAppSyncサブスクリプションと組み合わせて、トークンをブラウザにファンアウトします。
リアルタイムの顧客サポートチャット：応答ストリーミング、500人の同時ユーザー、会話履歴。
ブラウザ ↔ API Gateway WebSocket ↔ Lambda ↔ Bedrock ConverseStream。会話を`sessionId`でキー付けされたDynamoDBに永続化し、各ターンで再ロードします。
理由: WebSocketはHTTPポーリングを回避します。DynamoDBセッションストアはLambdaのステートレス性を乗り越えます。
モデルに、いつ関数を呼び出すか（データベース検索、計算機、API）を決定させる必要がある。
Converse APIのツール利用 (`toolConfig`) を使用します。名前とJSONスキーマでツールを宣言します。モデルは`toolUse`ブロックを出力し、アプリが実行して`toolResult`を返します。Claude、Llama、Mistral、Cohere Command Rで動作します。
サードパーティシステムでの新規チケット → Bedrockによる自動分析（感情、緊急度、カテゴリ） → ルーティング。
Webhook → API Gateway → EventBridge → Lambdaターゲット → Bedrock。EventBridgeはプロデューサーとコンシューマーを分離し、無料で再試行とDLQを提供します。
複数のマイクロサービスがBedrock生成リクエストを送信し、コンシューマーはすぐに結果を必要としない。
プロデューサー → SQS → Lambda (またはECS) コンシューマー → Bedrock InvokeModel → 結果をS3/DynamoDBに保存。SQSはスパイクを平滑化し、サービスクォータ内の失敗を再試行します。
毎晩100,000のSKUの記述を生成する。レイテンシー許容で、最低コストを目指す。
Amazon Bedrock Batch Inference。S3にJSONL入力を提出すると、Bedrockがオンデマンドと比較してトークンあたりのコストを最大50%削減してジョブを実行し、JSONL出力を書き込みます。
理由: バッチはレイテンシーとコストを交換します。リアルタイムで結果が必要ない場合は常にこれを使用します。
Lambda + Bedrockの前にあるAPI Gatewayが、長時間の生成で504 Gateway Timeoutを返す。
API Gateway REST統合タイムアウトは29秒で制限されます。非同期パターン（ジョブIDを返し、2番目のエンドポイントを介してポーリング）に切り替えるか、API Gateway WebSocket + ConverseStreamに切り替えて、タイムアウトウィンドウの前に部分的なトークンが流れるようにします。
製品画像と短いテキストから製品説明を生成する。
Converse APIを介して、Bedrockでビジョン対応モデル（Claude 3+ Sonnet、Nova）を使用し、テキストとともに`image`コンテンツブロックを使用します。
サブ秒で高品質な英語へのメッセージ翻訳が必要。
ニュアンスにはBedrockを介した基盤モデル（Claude HaikuまたはLlama small）、または文字通りの翻訳で十分な場合はAmazon Translateを速度/コストのために使用します。コンテキストを意識した翻訳にはBedrock、トランザクションにはTranslate。
キルスイッチ機能を用いて、本番トラフィックをモデルAからモデルBに段階的に移行したい。
アクティブモデル識別子とトラフィックスプリットを保持するAWS AppConfig機能フラグを使用します。Lambdaは呼び出しごとにフラグを読み取り、それに応じてルーティングします。AppConfigのデプロイロールバックを介して即座にロールバックします。
基盤モデルをホストするためにBedrockとSageMaker JumpStartのどちらを選択するか。
マネージド推論、統合API、KB/Agents/Guardrailsが必要な場合はBedrock。完全なネットワーク/IAM制御を備えたプライベートVPCホスト型エンドポイントが必要な場合、またはBedrockにないオープンウェイトモデルが必要な場合はSageMaker JumpStart。
アクショングループの定義スタイル：OpenAPI 3.0仕様と関数スキーマのどちらを選択するか。
基盤となるAPIが既にOpenAPI 3.0仕様を持っている場合、または完全なHTTPセマンティクス（パス、メソッド、パラメータータイプ）が必要な場合はOpenAPI。シンプルなJSONプロパティ宣言によって定義されるインライン/軽量アクションの場合は関数スキーマ。
理由: 既存のREST APIにはOpenAPIが標準的です。関数スキーマは、新しいエージェント内部ヘルパーに対してより高速です。
エージェントが正確な数学、統計分析、または小さなPythonスニペットを実行して質問に答える必要がある。
Bedrock Agentsのコードインタープリターを有効にします。エージェントはマネージドサンドボックスでPythonを実行し、結果は応答合成にフィードバックされます。
理由: LLMは正確な数学には信頼できません。サンドボックス化されたランタイムは、カスタムアクショングループを書くことなく確定的な数値結果を提供します。
デフォルトのエージェントプロンプトが冗長な応答を生成し、本番環境向けにオーケストレーションプロンプトを厳しくする必要がある。
各ステップ（前処理、オーケストレーション、KB応答生成、後処理）のエージェントでプロンプトテンプレートオーバーライドを設定します。オーバーライドはエージェントと共にバージョン管理されます。
本番トラフィックを安定バージョンに維持しながら、開発環境でエージェントを反復したい。
エージェントのバージョンとエイリアスを使用します。アクティブな編集には`DRAFT`を使用し、番号付きバージョンを公開し、エイリアス（`prod` → バージョン7、`dev` → DRAFT）を介してルーティングします。エイリアスを更新して昇格させます。
エージェントが間違ったアクショングループを選択し、推論ステップをデバッグする必要がある。
InvokeAgentでトレースを有効にします (`enableTrace: true`)。応答ストリームには、モデルの根拠、ツール選択、および入力を示す`preProcessingTrace`、`orchestrationTrace`、`postProcessingTrace`、および`failureTrace`ブロックが含まれます。
"エンティティ抽出 → KBで検索 → 要約 → メール送信" のBedrock Flowを構築する。
ノードを構成します：プロンプトノード（抽出）、ナレッジベースノード（検索）、プロンプトノード（要約）、Lambdaノード（SES経由でメール送信）。バッチフローにはS3入出力ノードを、分岐には条件ノードを使用します。
複数ステップのGenAIパイプラインにBedrock FlowsとStep Functionsのどちらを選択するか。
ステップのほとんどがBedrockプリミティブ（プロンプト、KB、エージェント）である場合はBedrock Flows — 単一API呼び出し、余分なIAM結合なし。ワークフローが多くのAWSサービスにまたがり、再試行、並列分岐、複雑なエラー処理、または長時間実行される待機が必要な場合はStep Functions。
モデルがツールを繰り返し呼び出し、その後最終的な回答を組み立てるチャットループを実装する。
パターン：ユーザーメッセージを送信 → モデルが`toolUse`を返す → アプリがツールを実行 → アプリが`toolResult`をConverse経由で返す → モデルが最終テキストを返すまでループ。暴走を防ぐために反復回数を制限します。
理由: モデルは情報が十分であると判断したときに停止します。アプリはループを駆動し、最大ステップ数を強制する必要があります。
モデルが顧客 + 注文 + 在庫を検索する必要があり、連続したツール呼び出しによってレイテンシーが3倍になる。
並列ツール使用をサポートするモデル（Claude 3+、Nova）は、一度に複数の`toolUse`ブロックを出力します。アプリでそれらを同時に実行し、次の推論の前にすべての`toolResult`を返します。
ステートレスなLambda呼び出し間で、期限切れセッションの自動クリーンアップ機能付きで複数ターンのチャット状態を永続化する。
`sessionId`をキーとし、`messages` + `lastActivity`を保存するDynamoDBテーブル。TTL属性 (`expiresAt`) を設定し、24時間以上前のセッションを自動削除します。Lambdaはターンごとに読み書きします。
チャットで約1000 QPSが発生し、セッション履歴に対するターンごとのDynamoDB読み取りがホットスポットになっている。
DynamoDBをElastiCache for Redisで前面に配置します。セッションごとに最後のN個のメッセージをRedisハッシュにキャッシュし、永続性のためにDynamoDBにライトスルーします。メモリを制限するためにRedisキーにTTLを設定します。
Bedrock InvokeModel呼び出しのリトライにより、同じ論理リクエストに対して2重に課金されるリスクがある。
論理リクエストごとに冪等性キー（例：入力 + ユーザーのUUID v5）を生成します。DynamoDBまたはElastiCacheに冪等性キーで応答をキャッシュし、リトライ時にキャッシュされた応答を返します。
理由: Bedrock自体は冪等ではありません。同じ入力はすべての呼び出しで課金されます。アプリ層のキャッシングが唯一の冪等性対策です。
すべてのユーザーを一度に切り替えることなく、移行中に2つの本番モデルバージョンを実行する。
ユーザーIDをN個のバケットにハッシュし、機能フラグ（AppConfig / Parameter Store）に基づいてバケットiをモデルAまたはモデルBにルーティングします。並行メトリクスを監視し、バケット割り当てをシフトしてロールフォワードまたはロールバックします。
顧客向けチャットボットが、有害なコンテンツ、禁止されたトピック、PII漏洩をブロックする必要がある。
Amazon Bedrock Guardrails。禁止されたトピック、コンテンツフィルター（ヘイト、暴力、性的、侮辱、不正行為）、ワードフィルター、機密情報フィルター（PII編集）、およびコンテキスト接地チェックを設定します。InvokeModelの入力と出力に適用します。
理由: Guardrailsはモデルに依存せず、両方向に適用されます。単一のモデルを交換しても機能し続けます。
Guardrailが、ドル金額を言及する正当な財務応答をブロックする。
影響を受けるコンテンツフィルターの感度ティアを下げ（例：`MEDIUM` → `LOW`）、かつ/または過度に広範な禁止トピックの表現を削除します。再デプロイする前に、ベンチマークプロンプトセットに対して再テストします。
医療要約アプリが、ソースドキュメントを超えて事実を捏造してはならない。
高い関連性 + 接地しきい値でBedrock Guardrailsのコンテキスト接地チェックを有効にします。しきい値を下回る応答はブロックされるか、安全なデフォルトメッセージに置き換えられます。
理由: 純粋なRAGでも、モデルが取得したチャンクから過度に一般化すると幻覚を起こすことがあります。コンテキスト接地は、応答ごとの回答とソースの整合性をスコアリングします。
Bedrockアプリが顧客PIIを含むプロンプトを受け取り、ロギングまたは下流での使用前に自動マスキングが必要である。
PIIエンティティタイプ（SSN、メール、電話、住所）に対して、`BLOCK`または`ANONYMIZE`アクションでGuardrails PIIフィルターを設定します。フィルタリングは入力と出力で独立して行われます。
公開アプリがユーザー入力をシステムプロンプトに連結しており、プロンプトインジェクションに耐える必要がある。
多層防御：(1) Guardrails (拒否トピック + ジェイルブレイク検出)、(2) ユーザー入力をデータとしてフレーム化し、メタ指示を拒否する強化されたシステムプロンプト、(3) 期待されるスキーマに対する出力検証、(4) 最小権限のツール権限により、侵害されたプロンプトが破壊的なアクションをトリガーできないようにする。
理由: 単一の緩和策では不十分です。多層防御は影響範囲を制限します。
レッドチームが、ロールプレイのフレーミング（「制限のないAIであるかのように振る舞う」）を介して、モデルが有害な出力を生成するよう強制できることを発見した。
Guardrailsのジェイルブレイク検出コンテンツフィルターを有効にします。ロールプレイの試みに対して明示的な拒否トピックを追加します。変更後、同じレッドチームプロンプトセットで再テストします。
すべてのBedrockデータは、転送中および保存時に顧客管理キーで暗号化する必要がある。
転送中はTLS 1.2+が強制されます。保存時：Bedrockモデルのカスタマイズ、KB埋め込み+S3ソースデータ、呼び出しログの保存先に対して顧客管理KMSキーを設定します。AWS管理キーを防止するSCPを介して強制します。
マルチチーム組織：各チームは特定の基盤モデルのみにアクセスできる必要がある。
許可されたモデルIDにスコープされたリソースARN上の`bedrock:InvokeModel`を許可するIAMアイデンティティベースのポリシー。リージョンをロックするために`aws:RequestedRegion`条件と組み合わせます。
理由: `arn:aws:bedrock:*::foundation-model/<id>`に対するリソースレベルの許可は、モデルレベルのアクセスを強制する唯一の耐久性のある方法です。アプリケーション層でのゲートに頼らないでください。
Lambdaはus-east-1のClaude 3.5 Sonnetのみを呼び出す。
`Resource: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-*`と`Condition: aws:RequestedRegion = us-east-1`を使用して`bedrock:InvokeModel`を許可します。他のすべてのモデルとリージョンを拒否します。
Bedrockアプリがパブリックインターネットに流出しないようにする必要がある。
ランタイムAPI用にVPCインターフェースエンドポイント (PrivateLink) を備えたBedrockを使用します。SCPを介してパブリックBedrockエンドポイントをブロックします。承認されたセットにアクションを制限するエンドポイントポリシーを追加します。
規制当局が、すべてのBedrockモデル呼び出しの完全な監査証跡（プロンプト、応答、モデルバージョン、タイムスタンプ）を要求している。
Bedrockモデル呼び出しロギングをCloudWatch LogsまたはS3に有効にします。完全なプロンプト + 応答 + モデルID + タイムスタンプをキャプチャします。API呼び出しメタデータ層（誰が/いつ/どこから）についてはCloudTrailと組み合わせます。
理由: CloudTrailはメタデータのみをキャプチャし、呼び出しロギングはコンテンツをキャプチャします。コンプライアンスには通常、両方が必要です。
Bedrockデプロイメントにおける会社のセキュリティ責任範囲を決定する。
AWS生成AIセキュリティスコープマトリックスを使用します。スコープ1（消費者SaaS）→ スコープ5（プライベートデータ上の自己学習モデル）。オンデマンド基盤モデルを備えたBedrockは通常スコープ2です。KB/Agent + RAGはスコープ3に近づき、ファインチューニングはスコープ4、Custom Model Importはスコープ5です。
API Gatewayの背後にあるGenAI APIエンドポイントを悪用から保護する。
AWS WAFをレートベースのルール（IPごと）、ボット制御マネージドルールセット、および疑わしいジェイルブレイクフレーズに対するカスタム文字列マッチルールとともに使用します。一般的なLLM-DDoSパターン（長文プロンプトの洪水）をブロックします。
KBやファインチューニングジョブに入る前に、S3ソースコーパス内のPIIやその他の機密データを検出する。
関連するS3バケットでAmazon Macieのスケジュールされた検出ジョブを実行します。検出結果はSecurity Hub / EventBridgeに送信され、その後の編集が行われます。
コンテンツの出所を確認するために、ダウンストリームでAI生成画像を検出する。
Titan Image Generator（またはNova Canvas）を使用します。出力には目に見えないウォーターマークが含まれます。Bedrockウォーターマーク検出APIで検証します。
マーケティングチャットボットは競合他社の名前を出してはならず、根拠のない主張をしてはならない。
Guardrailsの禁止トピック：競合他社の明示的なリスト + トピックレベルの「未検証の製品主張」。絶対的な主張（「保証付き」、「最高」、「100%」）には単語フィルターを追加します。
Bedrock Guardrailを非Bedrockモデル（例：自己ホスト型SageMakerエンドポイント）からの出力に適用する。
スタンドアロンの`ApplyGuardrail` APIをテキスト + Guardrail ID + バージョンで呼び出します。コンテンツがブロックまたは変更されたかどうか、どのフィルターが作動したかを返します。
理由: Guardrailsをモデルから切り離します。ユーザー入力の事前チェックとして、またはあらゆるモデル出力の事後チェックとして使用します。
単一のGuardrailポリシーをus-east-1、eu-west-1、ap-southeast-1にわたって適用する必要がある。
各リージョンで同じGuardrail（同じ設定）を再作成します。Guardrailsはリージョンリソースです。設定を同期させるためにIaC（CloudFormation / CDK / Terraform）を使用します。
理由: Guardrailsのマネージドなクロスリージョンレプリケーションはありません。IaCが唯一の耐久性のある一貫性対策です。
攻撃者が公開KBのドキュメントを汚染し、それらを検索する際にエージェントがシステムプロンプトやデータを漏洩させる。
取得したKBコンテンツを信頼できないものとして扱います：入力と出力の両方でGuardrailsを有効にし、プロンプトインジェクション検出またはパターンマッチングを介して取得したチャンクをサニタイズし、侵害されたプロンプトが昇格できないようにエージェントアクショングループに最小権限を強制します。
理由: 間接インジェクションは入力フィルタリングをバイパスします。悪意のあるプロンプトはユーザーメッセージではなく、取得されたコンテキストを介して到達します。
単一のバックエンドロールを持つマルチテナントアプリで、ユーザーごとのモデルアクセスが必要。
AssumeRole中にユーザー属性をセッションタグとして渡します。Bedrockアイデンティティポリシーの`aws:PrincipalTag/<key>`条件でそれらを参照し、ユーザーごとに`bedrock:InvokeModel`をゲートします。
Bedrock呼び出しロギングの保存先を選択します。
短いプロンプト/応答、高速なLogs Insightsクエリ、小規模なアプリにはCloudWatch Logs。高ボリューム、大規模なペイロード（KB + エージェントトレース）、長期保持、ダウンストリームのAthena/Glue分析にはS3。単一の応答が256 KBを超える可能性がある場合はS3を使用します。
理由: CloudWatch Logsにはイベントごとのサイズ制限がありますが、S3にはありません。ペイロードサイズと分析パターンで選択します。
パブリックチャットAPIをDDoS攻撃や大規模なトークン洪水攻撃から保護する。
AWS Shield Standardはデフォルトでオンになっています。L7保護と24時間年中無休のSRTサポートのために、重要なエンドポイントでShield Advancedを有効にします。WAFレートベースルールとCloudFrontを組み合わせてエッジで吸収します。
画像生成アプリが、性的、暴力的、または憎悪的な画像をブロックする必要がある。
Bedrock Guardrailsの画像コンテンツフィルターを入力（アップロードされた画像）と出力（生成された画像）に適用します。フィルターはHIGH/MEDIUM/LOWのしきい値で視覚コンテンツを分類します。
カスタマーサポートのトランスクリプトでBedrockモデルをファインチューニングする前のワークフロー。
パイプライン：S3ソース → PIIを特定するMacie検出ジョブ → Comprehend PII検出 + 編集（または正規表現を使用したGlue）→ クリーンアップされたデータセットを別のS3プレフィックスへ → Bedrockファインチューニング。Macieの失敗はEventBridge → SNSをトリガーしてセキュリティ担当者に通知します。
理由: 一度データが重みに取り込まれると、削除には再トレーニングが必要です。事前編集は、インシデント後の再トレーニングよりもはるかに安価です。
オンデマンドとProvisioned Throughputのどちらを選択するか。
可変/不明なトラフィック → オンデマンド。保証されたスループットSLAを持つ安定した高ボリューム → Provisioned Throughput（モデルユニット、1ヶ月または6ヶ月コミット）。カスタム（ファインチューニング、インポート済み）モデル → Provisioned Throughputが必須。
理由: オンデマンドはトークンごとで、コミットなしです。PTは時間ごとで、専用容量があり、高利用率ではトークンあたりのコストが約50%安くなります。
アプリがすべてのユーザーインタラクションで同じ4,000トークンのシステムプロンプトを再利用しており、ユーザーメッセージのみが変更される。
Bedrockのプロンプトキャッシュを有効にします。静的プレフィックスをキャッシュ可能としてマークします。その後の呼び出しでは、約5分間のキャッシュTTLの間、再処理をスキップし、キャッシュされたトークンあたりのコストを約90%削減します。
多くのユーザーが類似しているが同一ではない質問をしており、言い換えをまたいで回答をキャッシュしたい。
ユーザーのクエリを埋め込み、類似度閾値を超えてベクトルキャッシュ（DynamoDB + ElastiCache、またはOpenSearch）で最近傍を検索します。キャッシュヒットの場合 → 保存された応答を返します。キャッシュミスの場合 → Bedrockを呼び出し、書き戻します。
理由: 標準的なキーバリューキャッシュでは言い換えを見逃します。セマンティック類似性は意図を捉えます。
Bedrockアプリの呼び出しごとのコストを削減する。
システムプロンプトを厳しくし、冗長なFew-shotの例を削除し、出力に明示的な`maxTokens`を設定し、ストップシーケンスを使用して早期に終了します。品質が許す場合は、より小さなモデルを選択します。
理由: コストは処理された総トークン数にほぼ比例します。出力トークンは通常、入力トークンよりも高価であるため、出力の制限は高いレバレッジです。
コード補完：サブ秒のレイテンシー、バランスの取れたコスト、高いリクエストボリューム。
Bedrock上のClaude Haiku (またはNova Micro / Llama small)。レイテンシーに敏感なトークン補完パスには、Opusや大規模なLlamaを避けてください。
KBに50万のドキュメントがあるが、1日あたり約200クエリしかない。コストを最小限に抑えたい。
pgvectorを備えたAurora PostgreSQL Serverless v2。アイドル時にはほぼゼロACUにスケールし、低QPSでは常にオンのOpenSearch Serverless OCUフロアを上回る従量課金モデルです。
OpenSearch Serverless KBのクエリレイテンシーが800msあり、200ms未満にする必要がある。
検索コレクションのOCUフロアを増やし（より多くのコンピューティング = より多くのキャッシュされたベクトル）、埋め込み次元を減らし、top-kを厳密に上げ、メタデータを剪定し、アプリケーション層で結果キャッシュを有効にします。
中断を許容する長時間のファインチューニングジョブ。コストを最小限に抑えたい。
SageMakerのファインチューニングにはManaged Spot Training（最大90%オフ）を使用します。Bedrockのネイティブファインチューニングはオンデマンドのみです。予算が最も重要な場合は、スポット対応のカスタムトレーニングのためにSageMaker JumpStartを選択します。
チームまたは製品ライン間でBedrockの費用を割り当てる。
Bedrockリソース（Provisioned Throughput、カスタムモデル、アプリケーションスタック）にコスト配分タグを適用します。請求 → コスト配分タグでタグを有効にします。レポートはタグごとに内訳を表示します。
Bedrockの呼び出しレイテンシー、トークン量、エラーを監視する。
`AWS/Bedrock`下のCloudWatchメトリクス：`InvocationLatency`、`InputTokenCount`、`OutputTokenCount`、`Invocations`、`InvocationClientErrors`、`InvocationServerErrors`、`InvocationThrottles`。p95レイテンシーとエラー率にアラームを設定します。
1日あたり約100会話、シンプルなFAQ。コストを最小限に抑えたい。
最も有能な最小モデル（Titan Text Lite、Claude Haiku、またはNova Micro）を備えたBedrockオンデマンド。Lambda + API Gateway HTTP API。FAQがシステムプロンプトに収まるならKBは不要。必要ならAurora pgvector上の小さなKB。
定常状態のBedrockワークロードに対してProvisioned Throughputのサイズを決定する。
シャドウトランザクションでピーク時の入力 + 出力トークン/秒を測定します。Bedrockはモデルごとのユニットスループットを公開しています。`ceil(ピークTPS / ユニットあたりTPS)`のユニットをプロビジョニングします。コミットする前にシャドウトランザクションで検証します。
理由: プロビジョニング不足はスロットリングを引き起こし、過剰なプロビジョニングは時間ごとのコミットを浪費します。シャドウトランザクションでの経験的なサイジングが唯一信頼できるアプローチです。
共有アカウントで、アプリケーションまたはチームごとにBedrockコストを割り当てる。
アプリケーションごとに推論プロファイルを作成し、コスト配分タグ（例：`application=chatbot-X`、`team=marketing`）を付与します。各呼び出しはプロファイルARNを参照し、Cost Explorerはタグごとに費用を内訳します。
要約タスクで3つの基盤モデルを比較したい。自動化され、再現可能な評価が必要。
Amazon Bedrockモデル評価ジョブ（自動）。プロンプトデータセットを提供し、Bedrockは各モデルを実行し、BLEU、ROUGE、BERTScoreに加えて、該当する場合は毒性/精度をレポートします。
ROUGEスコアは高いように見えるが、人間の読者は要約が要点を見逃していると言う。
カスタムメトリクス（関連性、完全性、忠実性）を備えたBedrockの人間ベースの評価に切り替えます。ルーブリックを定義し、サンプルをワークフォースにルーティングし、スコアを集計します。
理由: 語彙の重複メトリクス（BLEU、ROUGE）はセマンティックな忠実性を見逃します。人間による評価は、主観的なタスクの真実です。
スケーラブルで再現性のある評価が必要だが、人間によるレビューだけでは遅すぎる/高すぎる。
Bedrock LLM-as-a-judge評価。強力なモデルがルーブリックに対して応答を採点し、結果は人間のレビューアとよく相関し、数日ではなく数分で実行されます。
生成されたポートフォリオの要約が、ソースドキュメントの数値と完全に一致する必要がある。
生成を制約します：低温度 (0–0.2)、厳密なプロンプト指示（「ソースから数値をそのまま引用する」）、出力に対するGuardrailsのコンテキスト接地チェック、生成後の数値とソースを検証する正規表現/パーサー。
理由: 接地されたRAGであっても、モデルは数値を言い換えます。複数の層（プロンプト + 接地 + パーサー）が残りのケースを捕捉します。
RAGがKBでカバーされているトピックでも「情報が不足しています」と返すことが多い。
検索トレースを調査します：チャンクスコア、取得されたチャンク数、クエリとチャンクの整合性。一般的な修正点：ハイブリッド検索を有効にする、top-kを増やす、チャンクサイズを調整する、セマンティックチャンキングに切り替える、クエリ再定式化を有効にする、関連性しきい値を下げる。
最近KBが同期された後でもエージェントが古い価格情報を返す。データソースはバージョン管理されたS3である。
最新のIngestionJobの`status: COMPLETE`と`documentsModified`が新しいオブジェクトを反映していることを確認します。バージョン管理とは、データソースが現在のバージョンのみにスコープされていない場合、非現行バージョンもインデックスされる可能性があることを意味します。データソースフィルターを検証し、再同期します。
HRエージェントが、巧妙に質問されると、他の従業員の給与情報を時々漏洩する。
エージェントの指示を厳しくします（「要求しているユーザー自身のデータについてのみ回答する」）、ユーザーIDを含むセッション属性を介してアクショングループをゲートし、アクショングループをバックアップするLambdaのIAMをユーザー自身のレコードのみをクエリするようにスコープし、クロスユーザーの給与クエリに対してGuardrailsの禁止トピックを追加します。
Bedrockの呼び出しで断続的にp95のレイテンシースパイクが発生する。
CloudWatchの`InvocationThrottles`（レート制限ヒット）と`ModelLatency`を確認し、呼び出し元のLambdaでAWS X-Rayトレースを有効にし、CloudWatch Logs Insightsで遅いツール呼び出しやKB検索を調べます。クロスリージョン推論、より小さなモデル、プロンプトキャッシング、またはバッチ処理によって緩和します。
回帰なしでClaude v2からClaude 3.5 Sonnetに移行する。
代表的なプロンプトセットで両者を比較するBedrock評価ジョブを実行します。次に、本番環境でシャドウトランザクションを実行します。同じ入力を両方に送信し、オフラインで出力を比較します。AppConfig機能フラグで10% → 50% → 100%に昇格させます。
モデル設定の変更ごとにCI/CDの一部としてBedrockモデル評価を実行する。
`CreateEvaluationJob` APIを使用します。S3にデータセット、評価者（組み込みまたはカスタム）、およびターゲットモデルを定義します。ジョブステータスをポーリングし、メトリクスが閾値を超えたら`COMPLETED`で昇格させます。
理由: Studio UIは一時的なものですが、APIは自動化され、再現可能な評価ゲートへの唯一のパスです。
本番環境で基盤モデルをアップグレードする際に品質の回帰を回避する。
キュレーションされた回帰テストセットを維持します：期待される出力（またはルーブリック）を持つ100〜500個の代表的なプロンプト。モデル交換ごとにBedrockモデル評価を介して実行します。スコアが定義された閾値よりも低下した場合は昇格をブロックします。
ツール利用チャットで、モデルが正しい引数で正しいツールを選択するかどうかを測定する。
ラベル付きセットを構築します：プロンプト + 期待される`toolUse`ブロック。実際のツール名とJSON引数を期待値と比較するカスタム評価者を通じて実行します。ツールごとの適合率/再現率を追跡します。
理由: 語彙メトリクス（BLEU）はエージェントが正しいアクションを呼び出したかどうかを見逃します。ツール使用の精度は、エージェントワークロードに適したメトリクスです。
