【無料】AWS AIP-C01練習問題10問｜図解解説付き｜Udemy講師作成

正解：B、D、E

A. 他社の医薬品名を、機密情報フィルターにPIIの一種として登録して遮断します。

不正解 機密情報フィルターが検出・マスキングの対象とするのは、氏名・住所・電話番号・メールアドレス・各種識別番号といった個人を特定できる情報（PII）です。他社の医薬品名のようなブランド名・企業名はPIIではないため、このフィルターの組み込みタイプでは検出できません。任意の単語やフレーズを完全一致でブロックするには、ワードフィルター機能を使う必要があります。

B. 他社の医薬品名をワードフィルターに登録し、入力と出力の両方でブロックするアクションを設定します。

正解 ワードフィルター（Word Filters）は、カスタムの単語やフレーズを完全一致で検出してブロックする機能です。他社の医薬品名を登録し、入力・出力の双方にブロックアクションを設定すれば、利用者が他社製品を質問した場合も、モデルが他社製品に言及する回答を生成した場合も確実に遮断できます。列挙できる固有名詞の遮断は、文脈判定の拒否トピックではなく完全一致のワードフィルターが適しています。

C. 高リスクな会話パターンを、有害コンテンツとして事前定義カテゴリで判定するコンテンツフィルターで遮断します。

不正解 コンテンツフィルターが扱うのは、ヘイト・侮辱・性的・暴力・不正行為・プロンプト攻撃という事前定義されたカテゴリに限られます。治療法の推奨や診断の断定といった会社固有の業務トピックをカスタムで登録する機能はありません。業務固有のテーマを文脈で遮断するには、拒否トピック機能を使う必要があります。

D. コンテキストグラウンディングチェックの閾値を高めに設定します。

正解 コンテキストグラウンディングチェックの閾値を高く設定すると、モデル応答がソース情報（承認済み医薬品添付文書）に厳密に基づく場合だけ許可されます。閾値は0から0.99の範囲で設定でき、値を高くするほど、事実に基づかない回答やハルシネーション（AIが事実でない情報をもっともらしく生成する現象）がブロックされやすくなります。

E. 治療法の推奨や診断の断定といったテーマを、会話の文脈を基準に遮断する拒否トピックとして登録します。

正解 拒否トピック（Denied Topics）は、特定の主題について議論すること自体を禁止するガードレール機能です。トピック名、定義（最大200文字）、サンプルフレーズを設定し、個々の単語ではなく会話の文脈を理解して該当テーマを検出・ブロックします。治療法の推奨や診断の断定のように「どの単語が出たか」ではなく「何を語ろうとしているか」で判定すべき規制リスクの遮断に向いています。

F. コンテキストグラウンディングチェックの閾値を低めに設定します。

不正解 グラウンディングスコアの閾値は、モデル応答をソース情報に基づいているとみなす最低信頼度を決めるものです。閾値を低くすると、添付文書に基づかない応答も通過しやすくなります。承認済み医薬品添付文書に基づかない回答を防ぐには、閾値を高く設定して厳しく判定する必要があります。

全体的な説明

問われている要件

• 高リスク会話パターン（治療法の推奨・診断の断定など）をブロックすること
• 他社の医薬品に関するコンテンツの生成を防止すること
• 承認済み医薬品添付文書に基づかない主張を排除すること
• Amazon Bedrock Guardrailsの機能を使用して実装すること

前提知識

Amazon Bedrock Guardrailsの構成要素について

• GuardrailsはユーザーとAIモデルの間に配置される保護レイヤーで、入力プロンプトとモデル応答の両方を評価します。1つのガードレールに複数のフィルターを組み合わせて設定でき、モデルに依存しない設計のため、Amazon Bedrock上のモデルだけでなく外部モデルにも適用できます
• 各拒否トピックにはトピック名、定義（最大200文字）、最大5つのサンプルフレーズを指定できます。また、AWS Bedrock APIリファレンス（GuardrailTopicPolicyConfig）の仕様上、ガードレールごとに登録できる拒否トピックは最大30件です

拒否トピック（Denied Topics）について

• 拒否トピックは、AIが特定の主題について議論すること自体を禁止するフィルターです。個別の単語ではなく、会話の文脈を理解して判定します。たとえば、レストランの予約アシスタントが政治的な議論に応じないようにする門番のような役割を果たします
• 銀行アプリケーションでの違法投資アドバイスの防止など、規制対応が必要な業界での利用に適しています
• コンテンツフィルターが事前定義カテゴリのみを対象とするのに対し、拒否トピックはカスタムの業務固有トピックを定義できます
• 拒否トピックの定義にはエンティティや単語のキャプチャではなく、テーマや主題を記述する必要があります。個別の単語のフィルタリングにはワードフィルターを、PII（個人を特定できる情報）の検出・マスキングには機密情報フィルターを使用します

ワードフィルター（Word Filters）について

• ワードフィルターは特定の単語やフレーズを完全一致（exact match）で検出し、入力・出力のそれぞれに対してブロックアクションを設定できます
• 他社の医薬品名、不適切語、業界固有の禁止用語など、明確に定義できるキーワードのフィルタリングに適しています
• 組み込みの不適切語フィルターも利用でき、カスタムワードと組み合わせて使用できます

コンテキストグラウンディングチェックについて

• コンテキストグラウンディングチェックは、モデル応答が提供されたソース情報に基づいているか（グラウンディング）、ユーザーの質問に関連しているか（関連性）を検証します。ハルシネーション（AIが図書館にない本の内容をでっちあげるようなもの）を検出・フィルタリングする機能です
• 閾値は0から0.99の範囲で設定でき、閾値を高くするほどソース情報に忠実でない応答がブロックされやすくなります。閾値1は全コンテンツをブロックするため無効値です
• グラウンディングソースの最大文字数は100,000文字、クエリは1,000文字、レスポンスは5,000文字です
• グラウンディングチェックはモデル応答に対してのみ実行され、入力プロンプトには適用されません

コンテンツフィルターの対象範囲について

• コンテンツフィルターの対象は、ヘイト・侮辱・性的コンテンツ・暴力・不正行為・プロンプト攻撃の6カテゴリに限定されます
• 各カテゴリのフィルター強度を個別に設定できますが、カスタムのカテゴリやキーワードを追加する機能はありません

機密情報フィルターの対象範囲について

• 機密情報フィルターは、氏名・住所・電話番号・メールアドレス・各種識別番号などのPIIを確率的に検出し、ブロックまたはマスキングする機能です
• 組み込みタイプが対象とするのは個人の属性や連絡先などのPIIに限られ、ブランド名や企業名のような任意の固有名詞を登録して遮断する機能はありません。任意の単語・フレーズのブロックはワードフィルターが担います

図による解説

アーキテクチャ図

ユーザーの入力プロンプトはまず入力フィルタリングに入り、拒否トピック（Denied Topics）が治療法の推奨・診断の断定といった高リスクパターンを文脈で検出し、ワードフィルターが他社の医薬品名を完全一致で弾きます。通過したプロンプトが基盤モデルで応答生成された後、出力側でもワードフィルターとコンテキストグラウンディングチェックが順に働き、承認済み医薬品添付文書に基づかない主張を高閾値でブロックしてから検証済みレスポンスを返却します。各フィルターは「文脈で判定するか」「単語で判定するか」という役割分担が明確で、この境界を取り違えると、たとえば拒否トピックに単語を詰め込むという誤った設定になります。

アーキテクチャ図

コンテキストグラウンディングチェックでは、閾値の高低が「ソース情報に忠実な応答だけを通すか、ハルシネーションも通すか」を分けます。5つのサンプル応答を0〜0.99のスコアで評価し、低い閾値（0.30）では事実に基づかない応答も通過しますが、高い閾値（0.70）ではソース情報に厳密に基づいた応答だけが許可されます。承認済み医薬品添付文書に基づかない主張を排除するには、高い閾値を設定します。閾値を低くする選択肢は、事実に基づかない応答をわざわざ通すことになり要件を満たしません。グラウンディングチェックはモデル応答にのみ働き、入力プロンプトには適用されません。

解くための考え方

Guardrailsの各フィルターは「何を」「どういう基準で」遮断するかが異なります。3つのリスクそれぞれに、検出の基準が合うフィルターを選びます。

第一のリスク「治療法の推奨・診断の断定」は、個々の単語ではなく会話の文脈で判定すべき性質です。特定の語が出たかではなく「何を語ろうとしているか」を見る拒否トピックが適します。コンテンツフィルターは有害カテゴリの事前定義だけで、会社固有の業務トピックを登録できません。

第二のリスク「他社の医薬品名への言及」は、列挙できる固有名詞を完全一致で弾くワードフィルターが最も直接的な手段です。入力・出力の両方にブロックを設定すれば双方向を遮断できます。機密情報フィルターはPII（個人情報）の検出・マスキングが役割で、他社の医薬品名のようなブランド名を登録して遮断することはできません。なお、拒否トピックの公式ベストプラクティスでも、個別の単語やエンティティの捕捉にはワードフィルターを使うよう明記されています。

第三のリスク「添付文書に基づかない回答」は、コンテキストグラウンディングチェックで対処します。閾値を高く設定すれば、承認済み医薬品添付文書に厳密に基づく応答だけが通り、ハルシネーションをブロックできます。閾値を低くすると基準が緩み、根拠のない回答が通過してしまいます。 参考資料

• Amazon Bedrock Guardrails – ガードレールの作成
• Amazon Bedrock Guardrails – 拒否トピック
• Amazon Bedrock Guardrails – ワードフィルター
• Amazon Bedrock Guardrails – コンテンツフィルター
• Amazon Bedrock Guardrails – コンテキストグラウンディングチェック
• Amazon Bedrock Guardrails – 概要
• Amazon Bedrock Guardrails – 機密情報フィルター
• Amazon Bedrock Guardrails – 自動推論チェック
• Amazon Bedrock – クォータ

正解：D

A. Lambdaリゾルバーのタイムアウト値を延長します。加えて指数バックオフの再試行ロジックを実装し、失敗したリクエストを自動で再実行します。

不正解 タイムアウト値を延ばしても、エラーの発生を先送りするだけで根本原因には届きません。AppSync経由のクエリには30秒という上限が固定されており、Lambda側のタイムアウトをどれほど伸ばしても呼び出しは30秒で打ち切られるため、延長の効果はありません。利用者は結局、応答が全て生成されるまで待ち続けることになり、応答の遅さや体感の悪さは解消されません。再試行ロジックが行うのは失敗時の再実行に限られ、応答を速く返すことにはつながりません。

B. RetrieveAndGenerate APIをInvokeModelWithResponseStream APIへ変更します。ストリーミング応答に対応するため、アプリケーションをAmazon API Gateway WebSocket APIへ移行します。

不正解 稼働中のAppSyncとAmplifyの構成を捨ててAPI Gateway WebSocketへ全面移行するのは、再設計と開発工数が大きく、「最小限の変更で問い合わせ体験を改善する」という要件に反します。また`InvokeModelWithResponseStream`が返すのはモデルのストリーミング応答のみで、ナレッジベースの検索機能は含まれないため、検索処理と、検索結果をプロンプトへ組み込む処理を別途実装しなければなりません。RAGパイプラインのストリーミング化自体は`RetrieveAndGenerateStream` APIでも可能ですが、いずれにしてもAPI Gateway WebSocketへの全面移行は過剰な変更です。既存資産をそのまま生かせるAmplify AI Kitの方が要件に合います。

C. アプリケーションを改修し、生成済みの応答をAmazon DynamoDBへキャッシュします。AppSyncリゾルバーは同じ問い合わせにはキャッシュを優先して返し、キャッシュがない場合だけモデルを呼び出します。

不正解 DynamoDBによる応答キャッシュが速くできるのは、過去に生成済みの同一クエリを再度処理する場合だけです。複数の商品やオプションを比較するような複雑な質問は内容が毎回異なるためキャッシュにはヒットせず、初回の生成は従来どおり30秒の上限で打ち切られます。生成途中の文字列を逐次返すストリーミング配信にもならないため、問い合わせ体験の改善という要件を満たせません。

D. AWS Amplify AI Kitの会話ルートを有効化し、GraphQL APIから返る応答をストリーミングで配信します。生成中の文字列をクライアント側へ逐次表示することで、待ち時間の体感を短縮します。

正解 この構成では、会話のストリーミング配信に特化したAmplify AI Kit（Conversationルート）を既存スタックへ組み込みます。応答を生成するバックエンドのLambdaがBedrockのConverse API（`/converse`エンドポイント）を呼び、受け取った応答チャンクをAppSyncのWebSocketサブスクリプション経由でそのままクライアントへ届けるため、ユーザーは完成を待たずに文字列を読み始められます。同期型のRequestResponseリゾルバーから非同期のストリーミングへ置き換わることで、AppSyncが課す30秒のクエリ制限に縛られず、時間のかかる質問にも対応できます。ナレッジベースは`a.ai.dataTool`として定義し、AppSyncのHTTPデータソースからBedrockの`Retrieve` APIを呼ぶカスタムクエリとしてtool useで連携するため、既存のナレッジベース資産も維持したまま最小限の変更で導入できます。

全体的な説明

問われている要件

• LambdaのRequestResponse同期呼び出しに起因するタイムアウトと応答遅延を解消すること
• 複数の商品を比較するような複雑な質問の長時間処理に対応すること
• 問い合わせ体験（体感的な応答速度）を改善すること
• 既存のAmplify + AppSync + Bedrock ナレッジベース構成を維持して対応すること

前提知識

AWS Amplify AI Kitのストリーミング機能について

• Amplify AI Kitは、Amplify Gen 2アプリケーションでAmazon Bedrockとの対話をストリーミングで配信するためのツールキットです（Conversationルート）。チャットAIのように、回答全体が完成するのを待たずに生成された文字列を逐次表示する仕組みを提供します
• バックエンドのLambda関数はBedrockのConverse API（/converse エンドポイント）を呼び出し、受信したチャンクをAppSyncに送信します。クライアントはAppSyncのWebSocketサブスクリプションを通じてリアルタイムでチャンクを受信します（RetrieveAndGenerate APIやInvokeModelWithResponseStream APIを直接呼ぶ構成ではない点に注意）
• useAIConversation Reactフックにより、ストリーミング受信やメッセージ状態管理がReactの状態として抽象化されるため、開発者はWebSocket接続の管理を意識する必要がありません
• Bedrock ナレッジベースとの連携は、Converse APIのtool use機能を介して行われます。Amplifyデータスキーマでa.ai.dataToolとしてナレッジベース検索用のカスタムクエリを定義し、AppSyncのHTTPデータソースからBedrockのRetrieve API（/knowledgebases/{id}/retrieve）を呼び出すJavaScriptリゾルバーを用意することで、LLMが必要に応じてKB検索を呼び出すRAGアーキテクチャをストリーミングで実現できます

AWS AppSyncのリアルタイム機能について

• AppSyncはGraphQL APIにWebSocketベースのサブスクリプション機能を提供します。クライアントがサブスクリプションを登録すると、サーバー側のイベントをリアルタイムで受信できます
• Amplify AI Kitはこのサブスクリプション機能を活用して、LLMの応答チャンクをリアルタイムでクライアントに配信します
• 会話ルートを設定すると、AppSync API、Lambda関数、DynamoDB（会話履歴保存用）が自動的にプロビジョニングされます

Lambda RequestResponseパターンの制約について

• RequestResponse呼び出しタイプは同期的な呼び出しで、Lambda関数の実行完了まで呼び出し元が待機します。Lambda関数自体の最大タイムアウトは15分ですが、AppSyncのクエリ/ミューテーション実行には30秒のハードリミットが存在します（この値は変更不可）。Lambda側のタイムアウトをそれ以上に設定していても、AppSync経由の呼び出しは30秒で打ち切られます
• 複雑な質問はナレッジベースからの検索と応答生成に時間がかかるため、同期呼び出しでは30秒のタイムアウトを超過しやすくなります
• ストリーミングアーキテクチャに切り替えることで、応答の最初のトークン（文字の断片）が生成された時点からユーザーに表示を開始でき、体感的な待ち時間を大幅に短縮できます。また、AppSyncのサブスクリプションを利用することで、単一リクエストの30秒制約に縛られずに長時間の応答生成にも対応できます

Amazon Bedrock RetrieveAndGenerate / RetrieveAndGenerateStream APIについて

• RetrieveAndGenerate APIは、ナレッジベースからの関連ドキュメント検索と、検索結果に基づく応答生成を一括で実行する同期APIです。RAGパイプライン全体を1つのAPI呼び出しで処理できます
• RetrieveAndGenerateStream API（2024年12月にGA）は、同じRAGパイプラインをストリーミング形式で返すAPIです。検索部分を失わずにストリーミング応答が得られます
• InvokeModelWithResponseStream APIはモデル応答をストリーミング取得できますが、ナレッジベース検索を含まないため、RAGパイプラインを維持するにはRetrieve APIなどの検索ロジックを別途実装する必要があります

図による解説

アーキテクチャ図

Amplify AI Kitで同期リゾルバーをストリーミング会話へ置き換える構成です。ReactクライアントがuseAIConversationフックでAppSyncへ接続し、LambdaがBedrockのConverse APIで受けた応答チャンクをAppSyncのサブスクリプション経由で逐次配信します。ナレッジベース検索はtool useのdataTool要求から、AppSyncのHTTPデータソース経由でRetrieve APIを呼びます。同期のRequestResponse型は30秒制限で複雑な質問が打ち切られますが、ストリーミングでは最初の文字列から表示が始まり体感の待ち時間が改善します。誤りやすいのはタイムアウト延長や別API移行で、延長は30秒上限に阻まれ、全面移行は検索再実装を伴う過剰な変更です。

解くための考え方

遅延の根本には、Lambdaを同期のRequestResponse型で呼び出していることがあります。複数の商品やオプションを比較するような複雑な質問では、ナレッジベースの検索と応答の生成に時間がかかり、AppSyncが定める30秒のクエリ上限（変更不可）に達してしまいます。さらに、応答が全て完成してから返されるため、画面に結果が出るまでの体感の待ち時間も長くなります。つまり、同期呼び出しをストリーミング配信へ切り替え、生成された文字列を逐次送り返すことが解決の要になります。 Amplify AI Kitは、このAmplifyとAppSyncの組み合わせに対して会話のストリーミングを組み込みで提供する専用ツールです。LambdaがBedrockのConverse APIを呼んで受けたチャンクを、AppSyncのWebSocketサブスクリプションでクライアントへリアルタイムに配信します。ナレッジベースはdataTool経由でRetrieve APIを呼ぶカスタムクエリとしてtool useで連携するため、既存のナレッジベースもそのまま活用できます。React + Amplify + AppSync + Bedrock ナレッジベースという構成を崩さず、最小限の変更で導入できる点が利点です。 残りの選択肢を検討すると、タイムアウト延長と再試行の追加は対症療法にすぎず、30秒という上限自体を延ばせない以上、待ち時間の問題は残ります。DynamoDBによる応答キャッシュは同一クエリの再応答しか速めず、内容が毎回異なる複雑な質問のタイムアウトは解消しません。InvokeModelWithResponseStreamへの切り替えとAPI Gateway WebSocketの導入は、既存のAppSync構成を捨てる大掛かりな再設計を伴い、ナレッジベース検索の再実装まで必要になります。Amplify AI Kitは、この技術スタック全体に合わせて設計されています。 参考資料

• AWS Amplify AI Kit – ストリーミング
• AWS Amplify AI Kit – 会話機能
• AWS Amplify AI Kit – ナレッジベース連携
• Amazon Bedrock – RetrieveAndGenerate API
• Amazon Bedrock – RetrieveAndGenerateStream API
• Amazon Bedrock – Converse API
• Amazon Bedrock – ストリーミングAPIとAppSyncによるレスポンス時間の改善
• AWS AppSync – リアルタイムデータ
• AWS Lambda – 同期呼び出し
• Amazon Bedrock Knowledge Bases – 概要

正解：C

A. Amazon API Gateway REST APIのLambdaオーソライザーに、AWS AppConfigへ置いたルールの評価を任せ、その結果を認可コンテキストとして返してから、FMごとに用意した専用のLambda関数へリクエストを配ります。

不正解 Lambdaオーソライザーは認証・認可の判定に使う機能であり、ルーティングのロジックを置く場所としては設計が合いません。返却するポリシーと認可コンテキストはデフォルトTTL 300秒（最大3600秒）でキャッシュされるため、1時間おきに変わるルールを即時に反映する用途には不向きです。加えてFMごとにLambda関数を分ける構成では、FMを増やすたびにコードデプロイが必要になり、「コードデプロイなしで切り替える」という要件に反します。

B. ルーティングの判断をAmazon API Gateway REST APIのリクエスト変換テンプレートに記述し、接続先となる各FMのエンドポイントはREST APIのステージ変数に置いておきます。FMを差し替えるときは、このステージ変数を書き換えるだけにします。

不正解 リクエスト変換テンプレート（VTL: Velocity Template Language）はリクエスト／レスポンスの整形を担う仕組みであり、顧客区分・取引金額・規制地域・リアルタイムコスト指標を掛け合わせる複雑なビジネスロジックを書くには表現力が足りません。ステージ変数はupdate-stage APIで再デプロイせずに更新できますが、リクエストごとに変化する外部の値（コスト指標など）を読み取って判断を返す仕組みを持たないため、1時間おきに変わるルールでの動的なリアルタイム振り分けには向いていません。

C. Lambda関数がリクエストごとにAWS AppConfig Agentから設定を取得し、受け取ったルールを評価して最適なFMを選びます。利用者には単一のAmazon API Gateway REST APIエンドポイントだけを窓口にします。

正解 AWS AppConfigは、コードをデプロイせずにアプリケーション設定を動的に更新できるサービスです。AppConfig Agent（Lambda拡張機能）は設定をlocalhost:2772のローカルキャッシュとして配るため、取り出しに外部API呼び出しを挟まず、数千件の同時リクエストにも低レイテンシーで耐えられます。Agentはバックグラウンドのポーリング（デフォルト45秒間隔、`AWS_APPCONFIG_EXTENSION_POLL_INTERVAL_SECONDS`で変更可）で更新を監視し、差分を検知するとローカルキャッシュを差し替えます。1時間おきに変わるルールであれば、ポーリング間隔とデプロイ戦略の進行時間の範囲内で全実行環境に行き渡るため、要件を満たします。さらに分岐の判断はLambda内のコードとして自由に書けるため、新しいコードのデプロイなしにルールを変更できます。

D. ルーティングの分岐条件と各FMのIDをAWS Systems Manager Parameter Storeに保存し、Lambda関数がリクエストのたびにGetParameterで値を取得して振り分け先を決定します。受け口にはAmazon API Gateway REST APIを置きます。

不正解 Parameter Storeの標準スループットは、GetParameter・GetParameters・GetParametersByPathの取得系APIで合わせて毎秒40件に制限されています（高スループットは別途有償です）。取引時間帯の数千件の同時リクエストでリクエストごとに同期取得すると、スロットリングやレイテンシー増加を招きます。加えて、顧客区分・取引金額・規制地域・リアルタイムコスト指標を組み合わせた複雑なルールを表す設定スキーマを自前で設計する必要があり、リクエストごとの動的な評価の仕組みは得られません。

全体的な説明

問われている要件

• 複数のFM間でリクエストを動的にルーティングすること
• 新しいコードをデプロイせずにFMの切り替えやルーティングルールの変更を行うこと
• 顧客区分・取引金額・規制地域・リアルタイムコスト指標など複雑なルールに基づく判断を行うこと
• 1時間ごとに変化する設定を数千の同時リクエストに即座に反映すること

前提知識

AWS AppConfigの動的設定管理について

• AWS AppConfigは、機能フラグや動的設定により、完全なコードデプロイなしで本番環境のアプリケーション動作を調整できるサービスです。アプリケーションを停止せずに動作を切り替えられます
• AppConfig Agent（Lambda拡張機能）は設定データをローカルにキャッシュし、Lambda関数からはlocalhost:2772へのHTTP呼び出しで設定を取得します。外部APIコールが不要なため、レイテンシーが極めて低く、数千の同時リクエストにも対応できます
• AppConfig Agentはバックグラウンドでポーリング方式により設定更新を確認します。デフォルトのポーリング間隔は45秒（AWS_APPCONFIG_EXTENSION_POLL_INTERVAL_SECONDSで変更可能）で、変更検知時にローカルキャッシュを更新します
• Lambdaは同時実行ごとに独立したインスタンスを起動し、各インスタンスは独自のローカルキャッシュを保持します。そのため設定変更の反映タイミングはインスタンスごとに独立し、完全に全インスタンスへ行き渡るまでの時間はポーリング間隔とデプロイ戦略に依存します
• デプロイ戦略として段階的ロールアウトを設定でき、CloudWatchアラームと連携した自動ロールバック機能により安全に設定変更を適用できます

Amazon Bedrock基盤モデルの呼び出しについて

• Amazon BedrockではモデルIDを指定してInvokeModel APIを呼び出すことで、複数のFM（Anthropic Claude、Amazon Titan、Meta Llamaなど）を統一的なAPIで利用できます
• モデルIDをパラメータとして外部設定から動的に取得すれば、コード変更なしで呼び出し先のFMを切り替えられます
• Cross-Region Inferenceを使用することで、リージョン固有の規制要件にも対応できます

AWS Systems Manager Parameter Storeについて

• Parameter Storeは、設定値やシークレットを階層化されたキー・バリューとして保存するサービスです。GetParameterなどのAPIで値を取得できます
• 標準スループットは取得系API（GetParameter・GetParameters・GetParametersByPath）で合わせて毎秒40件に制限されています。高スループットは別途有償で有効化できますが、リクエストごとに同期取得する構成は、数千件の同時リクエスト下でスロットリングやレイテンシー増加を招きます
• 顧客区分・取引金額・規制地域・リアルタイムコスト指標といった複雑なルールを表すスキーマは自前で設計する必要があり、リクエストごとに動的な値を評価する仕組みは提供されません

API Gatewayのルーティング機能について

• API Gatewayのステージ変数はupdate-stage APIで再デプロイなしに更新できますが、単なるキーバリューであり、リクエスト毎に外部の動的値（コストメトリクスなど）を評価する仕組みはなく、動的なリアルタイムルーティングには不向きです
• Lambdaオーソライザーは認証トークンの検証と認可ポリシーの返却を目的としており、レスポンス（ポリシーとコンテキスト）はデフォルトTTL 300秒（最大3600秒）でキャッシュされます。1時間ごとに変化するルーティング判断には設計上適していません

図による解説

アーキテクチャ図

AppConfig Agentがローカルキャッシュから設定を配り、コードデプロイなしでFMを切り替えます。リクエストは単一のAPI GatewayエンドポイントからLambda関数へ届き（①②）、関数はAgentのローカルキャッシュ（localhost:2772）から設定を取得します（③）。その設定で顧客区分・取引金額・規制地域・コストを評価し、Claude・Titan・Llamaから適切なBedrock FMを選びます（④）。Agentは既定45秒間隔のポーリングで更新を追います。FMやルールの変更はコード変更を伴いません。Parameter Storeやステージ変数で持つ案は、同期取得がスループット制限に当たったりコストをリアルタイム評価できなかったりします。

解くための考え方

デプロイを伴わずにルールを変えるには、判断材料をコードの外へ置く必要があります。設定とコードの分離、そして即時性のどちらが欠けても要件は満たせません。 AWS AppConfigはこの目的に特化したサービスで、設定を安全に配布できます。対してParameter Storeは、標準スループットが取得系APIで毎秒40件に制限されるため、リクエストごとの同期取得では数千件の同時リクエストに耐えられません。加えて複雑な分岐を表すスキーマを自前で設計する必要があります。API Gatewayのステージ変数はupdate-stage APIで更新できても、リアルタイムに変わる指標を都度評価する手段を持ちません。

即時性では、AppConfig AgentはLambda拡張機能として設定をローカルにキャッシュし、バックグラウンドのポーリング（デフォルト45秒間隔）で更新を追いかけます。関数本体はlocalhost:2772へHTTPで取りに行くだけなので、リクエスト単位の外部呼び出しがなく、数千件の同時アクセスにも低レイテンシーで応じられます。全インスタンスへの浸透はポーリング間隔とデプロイ戦略に依存しますが、1時間おきの変更なら十分間に合います。

分岐の複雑さについては、Lambdaのコードとして自由に記述できます。変換テンプレート（VTL）ではリアルタイムデータを参照した条件分岐が書きにくいのに対し、Lambdaなら顧客区分・取引金額・規制地域・コスト指標をまとめて評価できます。単一のエンドポイントに集約すれば、FM追加時もコード変更なしで済みます。 参考資料

• AWS AppConfig とは
• AWS AppConfig Agent Lambda拡張機能の追加
• AWS AppConfig – 設定プロファイルの作成
• AWS AppConfig – 機能フラグと設定データのデプロイ
• Amazon Bedrock – モデル推論の実行
• Amazon Bedrock – Cross-Region Inference
• AWS Systems Manager Parameter Store – スループット
• Amazon API Gateway – REST APIステージ変数
• Amazon API Gateway – Lambda オーソライザーの使用

正解：A

A. 部門別のプロンプトバリアントと再利用テンプレートをPrompt Managementで一括管理し、カテゴリフィルターと機密用語リストを持つガードレールで禁止コンテンツをブロックします。

正解 Prompt Managementは、トーンやフォーマット指示だけを変えた部門別バリアントを一つの場所で管理し、再利用テンプレートと変数、バージョン管理まで提供するマネージド機能です。ガードレールは、ヘイト・暴力などを扱うコンテンツフィルターと、氏名・住所・各種国民健康サービス番号などのPIIやカスタム正規表現を扱う機密情報フィルターを設定画面から調整でき、追加のコードやオーケストレーションが要りません。

B. プロンプトテンプレートはDynamoDBに置き、部門別の選択と禁止コンテンツの除去をそれぞれ専用のLambda関数で実装します。除去にはComprehendを呼び出します。

不正解 DynamoDBでテンプレートを管理するには、バージョン管理やテスト機能を自前で用意しなければならず、Prompt Managementの組み込み機能に比べてメンテナンス負荷が高まります。2本のLambdaによるオーケストレーションも開発・維持のコストを伴います。さらにComprehendはヘイトスピーチなど一部カテゴリの有害性検出には対応しますが、社内規程や業務トピックのような会社固有の禁止事項までは拾えず、カスタム分類モデルの構築が必要です。設定画面から拒否トピックを調整できるガードレールの利便性には届きません。

C. 部門ごとの指示はAPI呼び出しの都度注入し、レスポンスのフォーマット規則はDynamoDBに保存します。レスポンスの検証はStep Functionsに任せ、生成後にAmazon Macieで機密情報を検出して除去します。

不正解 Amazon Macieは、Amazon S3バケットに保存されたデータを対象に機密データを検出・可視化するデータセキュリティサービスです。生成AIアシスタントがその場で返すレスポンスをリアルタイムに検査・ブロックする機能は持ちません。さらにDynamoDB、Step Functions、Macieを組み合わせる案は、複数サービスのオーケストレーションと独自コードの開発を伴い、メンテナンスの負担が膨らみます。生成後にフィルタを掛けるポスト処理も、最小化すべき対象そのものです。

D. Prompt Managementでベーステンプレートを定義し、システムプロンプト変数で部門ごとのトーンを固定します。ガードレールはオーディエンス別の閾値チューニングで運用し、その管理を内部管理APIへ集約します。

不正解 ガードレールの強度は、ヘイト・暴力・性的などのカテゴリごとにNONE、LOW、MEDIUM、HIGHで指定する仕組みであり、「オーディエンスベースの閾値チューニング」という設定項目は用意されていません。ガードレールはコンソールやAPIから直接触れるため、内部管理APIを別に立てるのはメンテナンスの手間を増やすだけです。

全体的な説明

問われている要件

• 一貫したフォーマット（要約・リスク分類・フラグ付け用語）でレスポンスを生成すること
• 部門ごとにトーンを適応させること
• ヘイトスピーチ・不適切トピック・機密情報をブロックすること
• プロンプトバリアントを部門間で一元管理すること
• メンテナンスオーバーヘッドを最小限に抑えること

前提知識

Amazon Bedrock Prompt Managementについて

• Prompt Managementは、プロンプトの作成・保存・テスト・バージョン管理を一元的に行えるマネージド機能です。料理のレシピ帳のように、事業部門ごとに異なるプロンプトの「レシピ」を一箇所で管理し、必要に応じて呼び出せます
• プロンプトバリアントとは、同じプロンプトの異なる設定（メッセージ内容、使用モデル、推論パラメータ）を保持する機能です。法務部門向けには厳格なトーン、人事部門向けには柔らかいトーンのバリアントを作成し、比較テストで最適な出力を選べます
• 変数（{{variable}}形式）をプロンプトに埋め込むことで、ランタイム時に事業部門名やドキュメント種別などの値を動的に差し替えられます
• 作成したプロンプトはバージョンとして保存し、そのARNをAmazon Bedrock Flowsのプロンプトノードから参照してアプリケーションに組み込めます

Amazon Bedrockガードレールについて

• ガードレールはFM全体に適用可能な設定ベースの保護機能であり、コンテンツフィルター・拒否トピック・ワードフィルター・機密情報フィルター・コンテキスト基盤チェック・自動推論チェックの6種類のセーフガードポリシーを組み合わせて利用します
• コンテンツフィルターは、ヘイト（Hate）・侮辱（Insults）・性的（Sexual）・暴力（Violence）・不正行為（Misconduct）・プロンプト攻撃（Prompt Attack）の6カテゴリについて、NONE/LOW/MEDIUM/HIGHの4段階でフィルタ強度を設定できます
• 機密情報フィルターでは、個人を特定できる情報（PII）として氏名・住所・電話番号・メールアドレスや各種国民健康サービス番号などを検出し、ブロックまたはマスキングできます（医療テキストに特化した保護対象保健情報（PHI）の抽出はAmazon Comprehend Medicalが別途提供します）
• ガードレールのバージョン管理により、時間の経過とともにモデレーション基準を調整し、新バージョンとして安全にデプロイできます

Amazon Comprehendとガードレールの比較について

• 標準のAmazon Comprehendは汎用的な自然言語処理サービスで、PII検出・感情分析・エンティティ抽出に加え、DetectToxicContent APIによる有害コンテンツ検出（ヘイトスピーチ・侮辱・性的表現・暴力や脅迫など）にも対応します。医療領域のPHI検出は別サービスのAmazon Comprehend Medical（DetectPHI API）が担当します。ただし検出できるのは汎用カテゴリに限られ、社内規程や業務トピックのような会社固有の禁止事項を判定するにはカスタム分類モデルの構築が必要です。加えて、検出結果を受けて応答をブロックする処理は自前で実装しなければなりません
• Bedrockガードレールは生成AIのレスポンスに対するモデレーションに特化しており、設定画面からフィルタ強度を変更するだけで運用でき、追加コードの開発が不要です

Amazon Macieについて

• Amazon Macieは、Amazon S3バケットに保存されたデータを対象に、機密データ（PII・財務情報・認証情報など）を機械学習とパターンマッチングで検出・可視化するデータセキュリティサービスです
• 対象はS3上の保存データであり、生成AIアシスタントがリアルタイムで返すレスポンスを検査・ブロックする機能はありません

図による解説

アーキテクチャ図

Prompt Managementとガードレールを組み合わせ、プロンプトの一元管理とモデレーションをマネージドに実現する構成です。各部門（法務・人事・財務）はPrompt Managementから部門固有のバリアントを選び、テンプレートに変数を埋め込んでFMへ送ります（①）。応答はガードレールのコンテンツフィルターでヘイトや暴力を検査され（②）、機密情報フィルターで氏名や健康サービス番号などのPIIがブロックされます（③）。通過した応答だけが返ります（④）。両者ともバージョン管理を備え、モデレーション基準を段階的に調整できます。誤りやすいのはDynamoDB・Lambda・Comprehend・Macieといった代替構成で、バージョン管理やPII・機密データ検出の作り込みと別サービスの組み合わせが必要です。

解くための考え方

Amazon Bedrock Prompt Managementは、プロンプトの作成・バリアント管理・テスト・バージョン管理をマネージド機能としてひと通り提供しています。対してDynamoDBでテンプレートを管理する案では、バージョン管理やテストを自前で実装する必要があり、メンテナンス負荷が増大します。 次に「コンテンツモデレーション」の要件を考えます。ヘイトスピーチ・不適切トピック・個人を特定できる情報（PII）などの機密情報をブロックする必要があります。Amazon Bedrockガードレールは、これらをコンテンツフィルター・拒否トピック・機密情報フィルターの組み合わせで設定画面から構成でき、InvokeModel APIの呼び出し時にガードレールIDを指定するだけで適用されます。ポスト処理ロジックやオーケストレーションを開発する必要はありません。 一方、MacieやComprehendを使う案では、MacieはS3上の保存データの機密データ検出が役割でリアルタイムのレスポンス検査には使えず、Comprehendは標準サービスでPII検出や有害コンテンツ検出に対応しますが、会社固有の禁止トピックの判定にはカスタム分類モデルの構築が必要で、検出結果に応じて応答をブロックする処理も自前で組む必要があります。いずれもStep FunctionsやLambda関数によるオーケストレーションが加わります。 「モデレーション基準を時間とともに調整する」要件については、ガードレールのバージョン管理機能により、フィルタ強度やトピック定義の変更を新バージョンとして安全にデプロイできます。内部管理APIを別途設ける必要はなく、メンテナンスの負担を最小限に保てます。 参考資料

• Amazon Bedrock – プロンプト管理を使用して再利用可能なプロンプトを構築して保存する
• Amazon Bedrock – プロンプト管理を使用してプロンプトを作成する
• Amazon Bedrock – プロンプト管理を使用してプロンプトをテストする
• Amazon Bedrock – プロンプト管理でバージョンを使用してプロンプトをデプロイする
• Amazon Bedrock – ガードレールを使用して有害なコンテンツを検出してフィルタリングする
• Amazon Bedrock – ガードレールのコンポーネント
• Amazon Bedrock – ガードレールの機密情報フィルター
• Amazon Bedrock – ガードレールをテストする
• Amazon Comprehend – 個人を特定できる情報（PII）の検出
• Amazon Comprehend Medical – PHI（保護対象保健情報）の検出
• Amazon Macie とは

正解：C

A. Amazon S3 Vectorsにベクトルインデックスを構築し、メタデータはフィルタリング不可のフィールドとして保持します。S3 VectorsをAmazon Bedrockと組み合わせてRAGを有効にします。

不正解 この構成はメタデータを「フィルタリング不可」のフィールドにしているため、発行日・規制機関・文書タイプで絞り込むという要件を満たせません。S3 Vectorsのフィルタリング不可メタデータは参照用として保存されるだけで、クエリ時の絞り込み条件には使えません。フィルタリング可能なフィールドにすれば検索はできますが、この構成のままでは要件に届きません。

B. Amazon Aurora PostgreSQLへpgvector拡張機能を導入し、埋め込みとメタデータを収めるテーブルを自前で定義します。SQLクエリで類似検索を行い、メタデータでの絞り込みも条件式で実装したうえで、取得した文書をAmazon Bedrockへ渡して回答を生成する一連の流れを手作業で組み立てます。

不正解 Aurora PostgreSQLとpgvectorはベクトル検索自体に対応し、Amazon Bedrock ナレッジベースのベクトルストアとしても選択できます。しかしこの選択肢はテーブル定義から類似検索・絞り込み・回答生成までを自前のSQLとアプリケーションコードで組み立てる構成であり、取り込み・チャンク化・埋め込み生成を自動化するナレッジベースの利点を捨てています。さらにDBクラスターの容量設計・バージョン管理・スケーリングが残り、1,000万件規模ではHNSWインデックスのパラメータ調整も運用者の責任になるため、運用負荷が上乗せされます。

C. Amazon OpenSearch Serverlessでベクトル検索とメタデータによる絞り込みを行い、Amazon Bedrock ナレッジベースへ接続してRAG（検索拡張生成）をClaude基盤モデル（FM）で動かします。

正解 OpenSearch Serverlessのベクトル検索コレクションはサーバーレスでインフラ管理が要らず、自動スケーリングで数十億規模のベクトル負荷まで扱えます。k-NN検索に加えて数値・キーワード・日付・ブール値などのメタデータ絞り込みを標準で備え、Bedrock ナレッジベースと直接連携できます。文書の取り込み・チャンク化・埋め込み生成・インデックス作成までが自動化されるため、運用の負担を最小限に抑えられます。

D. Amazon Comprehendのカスタム分類モデルを用意して文書を意味カテゴリへ振り分け、クエリとの類似度をカテゴリの一致で判定して関連文書を絞り込み、その結果をAmazon Bedrockへ渡して回答を生成します。

不正解 Amazon Comprehendは固有表現・キーフレーズ・感情・PIIなどを抽出する自然言語処理（NLP）サービスであり、約1,000万件の埋め込みを保存して類似度で検索するベクトルストアや、発行日・規制機関・文書タイプによるメタデータ絞り込みの機能を備えていません。カテゴリの一致ではクエリとの意味的類似性を捉えられず、低レイテンシーのセマンティック検索を実現できません。既存の埋め込みも活用できず、検索基盤の別途構築で運用負荷が増えます。

全体的な説明

問われている要件

• ユーザークエリとの意味的類似性に基づく文書検索（セマンティック検索）を実現すること
• 発行日・規制機関・文書タイプによるメタデータフィルタリングに対応すること
• 英語・スペイン語・ポルトガル語の多言語文書を検索できること
• 約1,000万件の埋め込みに対して低レイテンシーで検索できること
• 管理・メンテナンスの運用オーバーヘッドを最小限にすること

前提知識

Amazon OpenSearch Serverlessのベクトル検索について

• OpenSearch Serverlessはサーバーレスで提供されるフルマネージド検索サービスであり、インフラのプロビジョニング・パッチ適用・スケーリングが自動化されます。データ量やリクエスト量に応じて自動的にリソースが調整されます
• ベクトル検索コレクションはk-NN（k近傍法）による類似検索を提供し、ユークリッド距離・コサイン類似度・ドット積の距離メトリクスに対応しています。最大16,000次元のベクトルをサポートし、数十億規模のワークロードにも対応します
• メタデータフィルタリングとして、数値・キーワード・日付・ブール値・ジオポイントなどのフィールドをベクトルと同一インデックスに格納し、フィルター条件付きのk-NN検索を実行できます
• 多言語テキストの埋め込みベクトルによる検索が可能です。埋め込みモデル（Amazon Titan Embeddings等）が多言語をサポートしていれば、言語を問わず意味的類似性で検索できます

Amazon Bedrock ナレッジベースについて

• ナレッジベースはRAG（検索拡張生成）パターンをマネージドサービスとして提供する機能です。RAGとは、回答を生成する前に関連する資料を検索して取得し、それを文脈としてFMに渡すことで、より正確で根拠のある回答を生成する仕組みです
• データソース（S3バケット内の文書）からドキュメントを自動でチャンク分割し、埋め込みモデルでベクトル化してベクトルストアにインデックスするパイプラインを提供します
• ベクトルストアとしてOpenSearch Serverless、Aurora PostgreSQL（pgvector）、Pinecone、MongoDB Atlasなどをサポートしています
• RetrieveAndGenerate APIにより、検索と回答生成を1回のAPI呼び出しで実行でき、メタデータフィルタリングも検索時に指定できます

Amazon S3 Vectorsについて

• S3 Vectorsはベクトルデータの保存と検索に対応するS3の機能です。フィルタリング可能なメタデータとフィルタリング不可のメタデータの2種類を設定できます
• フィルタリング不可のメタデータはベクトルに付随する参照情報として保存されますが、クエリ時のフィルター条件には使用できません。検索結果の取得後に情報を確認する用途に限られます

Aurora PostgreSQLとpgvectorについて

• pgvectorはPostgreSQLの拡張機能であり、ベクトルデータ型とコサイン距離・L2距離・内積による類似検索をSQLから実行できます
• Aurora PostgreSQLはBedrock ナレッジベースのベクトルストアとしても選択できますが、DBクラスターの容量設計・バージョン管理・パッチ適用やインデックスのパラメータ調整が残るため、OpenSearch Serverlessと比較して運用負荷が高くなります

Amazon Comprehendについて

• Amazon Comprehendは自然言語処理（NLP）を使って文書から固有表現・キーフレーズ・感情・PIIなどを抽出するテキスト解析サービスです。埋め込みの保存やk-NN類似検索、メタデータによる絞り込み検索の機能は提供しません

図による解説

アーキテクチャ図

OpenSearch Serverlessのベクトル検索コレクションをナレッジベースの裏に据え、サーバーレスなセマンティック検索とメタデータフィルタを両立する構成です。クエリはRetrieveAndGenerate APIへ届き（①）、OpenSearch Serverlessへ検索とフィルタ付き問い合わせが送られます（②）。発行日・規制機関・文書種別の絞り込みは同一インデックスのメタデータで処理され、関連文書が返ります（③）。取得文書を文脈にClaudeが回答を生成します（④⑤）。破線はS3からの取り込みで、チャンク化・埋め込み・インデックス作成を自動化します。誤りやすいのはAurora＋pgvector（インスタンス管理が必要）やComprehend（類似検索を提供しない）です。

解くための考え方

運用負荷では、サーバーレスかフルマネージドで回せるかが分かれ目です。OpenSearch Serverlessはインフラ管理が不要でこの要件に合致します。Aurora PostgreSQLはインスタンス管理が残り、Comprehendは埋め込みの類似検索や絞り込みを提供しないため、そもそも検索基盤として成立しません。

メタデータの軸では、絞り込み条件をベクトルと同じインデックスで扱えるかが重要です。OpenSearch Serverlessはフィルター付きのk-NN検索を実行できます。S3 Vectorsは選択肢で「フィルタリング不可」と指定されているため、発行日・規制機関・文書タイプでの絞り込みが成立しません。

Bedrock連携の軸では、ナレッジベースがOpenSearch Serverlessをベクトルストアとして標準サポートしており、取り込みから検索・回答生成までを自動化できます。RetrieveAndGenerate APIへメタデータフィルターを渡すだけで条件付きRAGが動きます。この三つを同時に満たす組み合わせが、1,000万件規模の低レイテンシー検索と運用負荷の最小化を両立します。 参考資料

• Amazon OpenSearch Serverless – ベクトル検索コレクションの使用
• Amazon OpenSearch Serverless – コレクションの作成と管理
• Amazon Bedrock – Knowledge Bases
• Amazon Bedrock – Knowledge Basesのベクトルストア設定の前提条件
• Amazon Bedrock – Knowledge Basesのメタデータとフィルタリング
• Amazon Bedrock – RetrieveAndGenerate API
• Amazon S3 – S3 Vectorsのベクトルインデックス
• Amazon S3 – S3 Vectorsのメタデータフィルタリング
• Amazon Aurora – pgvector拡張機能によるベクトル検索
• Amazon Comprehendとは

正解：B

A. 初回のベクトル検索結果を、Amazon SageMaker AIでホストしたMLモデルでリランキングする二段構えの検索アーキテクチャを組みます。

不正解 リランキングで精度は上がるものの、SageMaker AI上でのモデルのホスト、デプロイ・スケール・監視・エンドポイント維持という運用コストがのしかかります。加えて一段目の検索がベクトルだけのままなので、用語の完全一致を取りこぼす根本問題は解消されません。

B. 用語・略語の完全一致はキーワード検索に、意味の近さはベクトル検索にそれぞれ分担させ、両者を1本のクエリでまとめて実行するハイブリッド検索へ切り替えます。

正解 OpenSearch Serviceは、BM25による字句検索とk-NNによるベクトル検索を1本のクエリへ統合するハイブリッド検索を組み込みで備えています。医療略語や専門用語の完全一致はBM25、意味的な関連性の把握はベクトル検索と役割を分け、互いの弱点を補います。サーチパイプラインの正規化プロセッサが`min_max`などの正規化方式と`arithmetic_mean`などの組み合わせ方式で両者のスコアを統合するため、追加のインフラを用意する必要がなく、運用の負担を最小限に抑えられます。

C. 埋め込みベクトルの次元数を384から1536へ引き上げ、取得後に無関係な文書を除外する後処理用のAWS Lambda関数を別途用意して検索の後段へ差し込みます。

不正解 次元数を増やせばセマンティック表現の精度は上がりますが、正確な用語一致の課題は手つかずのままです。ベクトル検索が捉えるのは意味の近さであって、「MRI」のような略語の完全一致には対応できません。Lambdaによる後処理は開発・運用のコストを上乗せしてレイテンシも伸ばし、次元数の増加そのものもインデックスサイズとクエリ時間を大きく膨らませます。

D. Amazon OpenSearch Serviceの検索はそのままにして、Amazon Comprehendでクエリと文書からキーフレーズや固有表現を抽出し、抽出結果を検索条件へ付与して略語の取りこぼしを補う構成にします。

不正解 Amazon Comprehendは固有表現・キーフレーズ・感情・PIIを抽出するテキスト解析サービスであり、OpenSearch Serviceのインデックス上でBM25とk-NNのスコアを統合する検索機能は持ちません。キーフレーズの付与では「MRI」のような略語そのものの完全一致を保証できず、意味は近いが無関係な文書の混入も解消されません。解析用のパイプラインを別途挟む分、運用の手間も増えます。

全体的な説明

問われている要件

• RAGアプリケーションにおけるベクトル検索の検索品質向上
• 正確な医療用語・略語に対するマッチング精度の改善
• 意味的に類似だが無関係なドキュメントの排除
• ドキュメント数が数百万件に増加してもレイテンシを低く維持
• 運用オーバーヘッドを最小限にする

前提知識

RAGアーキテクチャにおける検索方式について

• RAG（検索拡張生成）は、回答する前に関連する情報を検索してから回答を生成する仕組みです。図書館で調べてから質問に答える司書のように、FMが知らない最新情報や専門知識を検索して文脈に組み込みます。
• ベクトル検索（セマンティック検索）は、テキストを数値のベクトルに変換し、意味の近さで文書を検索します。「心臓発作」と「心筋梗塞」のように異なる表現でも意味が近ければマッチしますが、「MRI」のような略語の完全一致は苦手です。
• BM25は従来型のキーワード検索アルゴリズムで、文書中の単語の出現頻度と希少性に基づいてスコアリングします。正確な用語一致に優れますが、同義語や言い換えには対応できません。

Amazon OpenSearch Serviceのハイブリッド検索について

• ハイブリッド検索はオープンソースOpenSearch 2.10で正規化プロセッサ（normalization-processor）と共にGAされ、Amazon OpenSearch Serviceとしては2.11でhybrid query score normalizationがサポートされました。サーチパイプラインの正規化プロセッサを使用して、BM25とk-NNの両方のスコアを正規化・統合します。
• 正規化プロセッサは「正規化方式（normalization technique）」と「組み合わせ方式（combination technique）」を別々に指定します。正規化方式には min_max（デフォルト）や l2 が、組み合わせ方式には arithmetic_mean（デフォルト）、geometric_mean、harmonic_mean が用意されており、利用できる方式はOpenSearchのバージョンによって追加されます。さらにスコアランカープロセッサ（2.19以降）では Reciprocal Rank Fusion（RRF）によるランクベースの結果統合も利用できます。
• k-NNプラグインはベクトルの次元数を最大16,000まで対応（Faiss・Luceneなどの主要エンジン、最新のOpenSearchドキュメント基準）し、コサイン類似度やユークリッド距離、内積などによる最近傍探索を実行します。

Amazon Bedrockナレッジベースについて

• Amazon Bedrockナレッジベースは、OpenSearch Serviceをベクトルストアとして統合し、RAGアプリケーションの構築を容易にします。データソースの取り込み、チャンキング、埋め込み生成、検索、回答生成をマネージドに提供します。

Amazon Comprehendについて

• Amazon Comprehendは固有表現・キーフレーズ・感情・PIIなどを抽出するテキスト解析サービスであり、検索インデックス上でのキーワード一致やベクトル類似度の統合は提供しません

図による解説

アーキテクチャ図

BM25のキーワード検索とk-NNのベクトル検索を単一クエリで並列実行し、スコアを統合するハイブリッド検索の構成です。クエリはOpenSearch Serviceの検索パイプラインへ届き（①）、BM25検索とk-NN検索に分割して同時実行されます（②③）。BM25が医療用語や略語の完全一致を、k-NNが意味的類似性を捉えます。両者のスコアは正規化プロセッサに渡され（④⑤）、min_maxなどの正規化とarithmetic_meanなどの統合で単一の順位にまとめて基盤モデルへ送られます（⑥）。追加インフラなしの設定変更だけで検索精度を高められます。次元数増加は完全一致の欠落を解決せず、リランキングはホスト運用の負担を新たに持ち込みます。

解くための考え方

ベクトル検索だけのRAGは、略語・専門用語の取りこぼしと、意味は近いが無関係な文書の混入が起きやすいです。両方を同時に直すには、意味を捉えるベクトル検索と、正確な一致を捉えるキーワード検索を組み合わせるハイブリッド検索を使います。OpenSearch Serviceはサーチパイプラインの機能としてこれを標準搭載しており、インフラ追加や独自コードの開発なしに導入できます。

運用コストの軸で見ると、ハイブリッド検索はOpenSearch Serviceの組み込み機能なので設定変更だけで済みます。一方、Lambdaによる後処理やSageMaker AIでのリランキングは追加サービスの開発・運用を伴い、Comprehendで前処理を挟む案も略語の完全一致を保証できず別パイプラインの運用が増えます。いずれも「最小の運用オーバーヘッド」という条件から外れます。

スケールの軸では、OpenSearch Serviceはクラスターを伸ばすことで数百万件規模の文書に対応できます。次元数を増やす案はインデックスサイズとクエリ時間を膨らませるだけで、用語一致の課題も解消しません。組み込みのハイブリッド検索は、品質と運用負荷の両立を最小限の変更で実現します。 参考資料

• Amazon OpenSearch Serviceでのk-NN検索
• OpenSearch ハイブリッド検索ドキュメント
• Amazon Bedrockナレッジベースでデータを取得してAIレスポンスを生成する
• Amazon OpenSearch Serviceとは
• Amazon OpenSearch Serviceのベクトルデータベース機能（AWSブログ）
• Amazon Bedrockガードレールを使用して有害なコンテンツを検出してフィルタリングする
• Amazon Comprehendとは
• Amazon SageMaker AI推論

正解：C

A. Lambdaはプライベートサブネットに置きつつ、Amazon BedrockとデータレイクへはNATゲートウェイ経由でアクセスします。機密データの把握はAmazon Macieによる検出・分類に任せ、CloudTrailログをS3へ書き出して運用チームが毎週確認します。

不正解 NATゲートウェイを経由すると、LambdaからAmazon Bedrockへ向かうトラフィックはパブリックなインターネットを通るため、「プライベート接続のみ」という要件に反します。Amazon Macieは機密データの検出・分類と可視化が役割であり、テーブルの列単位でアクセス権限を付与する機能はないため、クロスアカウントの列レベル制御にはLake Formationが必要です。ログの毎週レビューも事後対応にとどまり、継続的な監査には届きません。

B. アプリケーションアカウントにはS3用のゲートウェイエンドポイントだけを設け、Amazon Bedrockへはパブリックエンドポイントで呼び出します。Lake Formationはデータベース単位の権限付与にとどめ、CloudTrailログをCloudWatch Logsへ送るものの、メトリクスフィルターやアラームは組みません。未承認の経路によるアクセスも、事後のログ確認に頼るだけで継続的な検知にはなりません。

不正解 Bedrockへの呼び出しがパブリックエンドポイント経由になるため、プライベート接続のみという要件を満たしません。S3のゲートウェイエンドポイントはS3へのプライベートアクセスには有効ですが、BedrockにはインターフェイスVPCエンドポイントが別途要ります。Lake Formationのデータベース単位の付与では列の粒度に届かず、アラームのない監査も継続的な検知として不十分です。

C. アプリVPCにBedrockランタイム（bedrock-runtime）のインターフェイスVPCエンドポイントを立て、Lambdaをプライベートサブネットで実行します。呼び出し元はエンドポイントポリシーとIAMポリシーで制限し、データ側はLake FormationのLFタグで列レベルのクロスアカウント権限を付与します。

正解 インターフェイスVPCエンドポイントはAWS PrivateLinkにより、VPCとAmazon Bedrockの間にインターネットを通らない専用経路を張ります。エンドポイントをプライベートサブネットに置けば、Lambdaからの呼び出しはすべてVPC内に留まります。エンドポイントへ付すポリシーはリソースベースで、その経路から実行できるアクションを絞り、IAMポリシー（アイデンティティベース）がロール単位の許可を定めるため、二層で制御できます。Lake FormationのLF-TBACは、カスタムタグを列まで付与して値に応じて許可・拒否する仕組みで、クロスアカウントの列レベル権限をマネージドに実現します。

D. Amazon BedrockとAmazon S3へのアクセスはVPCエンドポイントに寄せ、データレイクの権限はIAMパスベースのポリシーだけで管理します。CloudTrailログをCloudWatch Logsへ送り、リージョン間読み取りの準備を短縮するためパブリックフォールバックも許可します。

不正解 VPCエンドポイントでプライベート接続の要件には応じていますが、IAMパスベースのポリシーだけでは列単位のきめ細かな制御ができず、列レベルの権限にはLake Formationが要ります。パブリックフォールバックを許すのは「プライベート接続のみ」という要件と矛盾し、セキュリティ上の妥協になります。

全体的な説明

問われている要件

• アプリケーションVPCとAmazon Bedrock間のプライベート接続のみの使用
• 機密性の高い文書の安全な処理
• 複数のAWSアカウントにわたるきめ細かな列レベルのアクセス制御
• ガバナンス付きデータレイクとの連携

前提知識

Amazon BedrockのVPCエンドポイントについて

• AWS PrivateLinkを使用してインターフェイスVPCエンドポイントを作成すると、VPCとAmazon Bedrock間のプライベート接続が確立されます。インターネットゲートウェイ、NATデバイス、VPN接続を使用せずにBedrockにアクセスできます。
• Bedrockでは、コントロールプレーン（bedrock）、ランタイム（bedrock-runtime）、エージェントビルドタイム（bedrock-agent）、エージェントランタイム（bedrock-agent-runtime）などのエンドポイントが提供されており、対応するエンドポイントは順次追加されています（2026年2月にはOpenAI互換APIを提供する bedrock-mantle エンドポイントもAWS PrivateLinkに対応しました）。モデル推論の呼び出しを担うのは bedrock-runtime です。
• VPCエンドポイントにカスタムエンドポイントポリシーをアタッチすることで、特定のAPIアクション（InvokeModel等）のみを許可する制御が可能です。

AWS Lake Formationのアクセス制御について

• Lake Formationは、データレイク上のデータに対して列、行、セルレベルのきめ細かなアクセス制御を一元管理するサービスです。複雑な権限をシンプルに設定できます。
• LFタグベースのアクセス制御（LF-TBAC）は、カスタムラベル（LFタグ）をデータベース、テーブル、列にアタッチし、タグの値に基づいてアクセスを許可・拒否します。数百のリソースの権限をいくつかのタグで管理でき、スケーラブルです。
• Lake Formationのクロスアカウントデータ共有により、複数のAWSアカウント間でデータカタログとAmazon S3ロケーションへのきめ細かなアクセス制御が提供されます。

VPCネットワーキングとプライベート接続について

• インターフェイスVPCエンドポイントは、サブネット内にElastic Network Interfaceを作成し、AWSサービスへのトラフィックをVPC内部に留めます。プライベートDNSを有効にすると、既存のAPI呼び出しコードを変更せずにプライベート接続に切り替わります。
• NATゲートウェイは、プライベートサブネットのリソースからインターネットへのアウトバウンド通信を可能にしますが、トラフィックはパブリックインターネットを経由するため、プライベート接続の要件は満たしません。
• ゲートウェイエンドポイントはS3とDynamoDB用で、インターフェイスエンドポイントとは異なりルートテーブルベースで動作します。Bedrockにはインターフェイスエンドポイントが必要です。

Amazon Macieについて

• Amazon Macieは機械学習とパターンマッチングでS3内の機密データを検出・分類し、バケットのセキュリティ体制を可視化するサービスです。テーブル・列単位でアクセス権限を付与する機能は提供しません

図による解説

アーキテクチャ図

プライベート接続と列レベル権限は、マルチアカウント構成の別々の層で満たします。利用者からの要約リクエストは①API Gatewayが受け、②プライベートサブネットのLambdaへ転送されます。Lambdaは③Interface VPCエンドポイント（PrivateLink）を経由してAmazon Bedrockへ接続するため、インターネットを経由しません（④）。一方、データ側は⑤Lake Formationを通じ、Glueデータカタログのメタデータに基づいて文書へアクセスします。NATゲートウェイで代替すると通信がパブリック経路になり、Macieでは列単位の権限を付与できないため、どちらかの要件を取りこぼします。この2つは代替案ではなく、それぞれが独立して必要な層です。

解くための考え方

プライベート接続と列レベルの権限は、別々の層で満たす必要があります。ひとつはAmazon Bedrockまでの通信経路をプライベートに限定すること、もうひとつは複数アカウントへ列レベルの権限を渡すことです。 前者は、AWSサービスとVPCをインターネットを介さず結ぶ定石であるインターフェイスVPCエンドポイント（AWS PrivateLink）で満たします。NATゲートウェイやパブリックエンドポイントを経由する案はすべてトラフィックが公衆網に乗るため失格です。Bedrockにはbedrock-runtime向けのインターフェイスVPCエンドポイントが用意されており、Lambdaをプライベートサブネットに置けば呼び出しはVPCの内側だけで完結します。 後者は、S3のバケットポリシーやIAMポリシーではオブジェクト単位までしか届かず、テーブルの列単位の制御はできません。Macieも機密データの検出・分類が役割で、列レベルの権限付与は提供しません。列レベルの権限はLake Formationが担い、列・行・セルの粒度でクロスアカウントの権限を一元管理します。LFタグ（LF-TBAC）を使えば多数のテーブル・列への権限を少ないタグでまとめて扱えます。 インターフェイスVPCエンドポイントとLake FormationのLF-TBACを組み合わせた構成だけが、この2つを同時に満たします。 参考資料

• インターフェイスVPCエンドポイントを使用してVPCとAmazon Bedrock間にプライベート接続を作成する
• AWS Lake Formationとは
• Lake FormationのLFタグベースのアクセス制御
• Lake Formationでのクロスアカウントデータ共有
• Amazon VPCを使用してデータを保護する（Amazon Bedrock）
• AWS PrivateLinkを介したAWSサービスへのアクセス
• Lake Formationでのデータフィルタリングとセルレベルのセキュリティ
• Amazon Macieとは

正解：A

A. バージョン管理と変数によるパラメータ化はAmazon Bedrockのプロンプト管理へ集約します。CloudTrailで管理イベントを記録し、EventBridgeで振り分けたうえで、保留中のレビュー通知をSNSから配信し、承認できる権限はIAMポリシーで絞り込みます。

正解 Amazon Bedrockのプロンプト管理は、作成・保存・バージョン管理・変数によるパラメータ化をネイティブに備えています。ドラフトで反復し、本番向けのスナップショットをバージョンとして切り出せます（同一プロンプトのバリアントを作成し、出力を見比べて選ぶこともできます）。CloudTrailはプロンプトの作成・更新・バージョン作成・削除といった管理イベントを自動で記録し、詳細な監査証跡になります。権限面はIAMポリシーが受け持ち、通知はCloudTrailイベントをEventBridgeルールで拾ってSNSトピックへ流すことで実現します（IAMだけでは通知を送れないため、EventBridgeとSNSの組合せが要ります）。なおプロンプト管理はリージョン単位のリソースなので、複数リージョンへ展開する場合はリージョンごとの設定と同期計画が必要です。

B. Amazon SageMaker Canvasをデプロイし、Amazon S3に保存したプロンプトテンプレートを読み込ませます。バージョン管理はAWS CloudFormation、承認ポリシーの強制と監査はAWS Configにそれぞれ任せ、プロンプト固有のバージョン管理とパラメータ化は別途自前で用意します。

不正解 SageMaker Canvasはノーコードの機械学習ツールで、プロンプトテンプレートの管理を目的としたサービスではありません。CloudFormationはインフラのバージョン管理には適しますが、プロンプト本文のバージョン管理には使えません。AWS Configも設定のコンプライアンス評価が役割であり、プロンプトの承認ワークフローには不適切です。

C. 承認ゲートはAWS CodePipelineの手動承認アクションで設け、プロンプト本体はAmazon S3に保存します。バージョン管理はS3のタグで代用し、通知はAmazon EventBridgeから送ります。

不正解 AWS CodePipelineはソフトウェアのリリース手順をモデル化・自動化する継続的デリバリーサービスで、手動承認アクションは備えるものの、プロンプトのドラフト・バージョン・バリアント管理や変数によるパラメータ化を提供しません。S3のタグはオブジェクトのメタデータにすぎず、テンプレートの体系的なバージョン管理はできません。変数も用意されないため、ブランドの品質基準を全チームへ強制する一貫したテンプレート化が実現できません。この構成はプロンプト管理とIAM・CloudTrail・EventBridge・SNSで置き換えられ、手間が増えるだけです。

D. Amazon Bedrock Studioに商品説明用のテンプレートを置き、Amazon CloudWatchのダッシュボードでプロンプトの使用メトリクスを可視化します。承認の状態はAmazon DynamoDBへ記録し、AWS Lambda関数が承認を強制します。

不正解 Bedrock Studioはプロンプト管理と連携するため、バージョン管理そのものは使えます。ただしこの構成では承認ワークフローをDynamoDBとLambdaで自作することになり、開発・運用の手間が膨らみます。CloudWatchのダッシュボードはメトリクスの可視化には向きますが、プロンプト操作の「誰が・いつ・何を」まで追う監査証跡にはCloudTrailが適します。変数によるパラメータ化やバリアント比較も、プロンプト管理のネイティブ機能を直接使う方が一貫性と運用性で勝ります。

全体的な説明

問われている要件

• 数百の商品説明用プロンプトテンプレートの一元管理
• 承認ワークフロー付きのバージョン管理
• プロンプト操作の詳細な監査証跡
• 品質基準を強制するための一貫したプロンプトのパラメータ化
• 複数チーム・複数リージョンでの利用

前提知識

Amazon Bedrockプロンプト管理について

• プロンプト管理は、再利用可能なプロンプトを作成・保存・管理するAmazon Bedrockのネイティブ機能です。レストランのレシピ帳のように、一度作成したプロンプトを標準化して複数のワークフローで繰り返し使用できます。
• プロンプトには変数（プレースホルダー）を含めることができ、テスト時やランタイムで異なる値を指定できます。これにより、同じテンプレート構造で様々なユースケースに対応するパラメータ化が実現します。
• バリアント機能により、同一プロンプトの異なる設定（使用モデル、推論パラメータなど）を作成・比較・テストできます。コンソールの比較モードで出力を見比べ、最適なバリアントを選択した上でバージョンを作成してデプロイします。
• バージョン管理では、ドラフトバージョンで反復的に開発し、本番環境にデプロイする準備ができた時点でスナップショットとしてバージョンを作成します。バージョン間の切り替えが容易です。
• Amazon Bedrock Studioはプロンプト管理と統合されており、Studio上で作成したプロンプトもPrompt Managementのバージョン管理機能を利用できます。
• プロンプト管理はリージョンスコープのリソースであり、マルチリージョンで利用する場合は各リージョンで設定し、必要に応じてテンプレートやバージョンを同期する運用設計が必要です。

AWS CloudTrailによる監査について

• CloudTrailはAWSアカウント内のAPI呼び出しを記録するサービスです。オフィスビルの入退室記録システムのように、誰が・いつ・どのAPIを呼び出したかを記録します。
• Amazon Bedrockの管理イベント（プロンプトの作成・更新・バージョン作成・削除などのコントロールプレーン操作）はCloudTrailで自動的に記録されます。

承認ワークフローの通知実装について

• IAMポリシーは権限制御の仕組みであり、通知機能はIAM単体では実現できません。承認が必要な操作に対する「保留中のレビュー通知」を実装するには、CloudTrailイベントをAmazon EventBridgeルールでフィルタリングし、Amazon SNSトピックへ配信する構成が標準的なパターンです。
• IAMポリシーはバージョン作成やデプロイ権限を特定ロールのみに付与することで承認権限を制御し、EventBridgeとSNSで通知を、CloudTrailで監査証跡を、という役割分担で承認ワークフロー要件を満たします。

AWS CodePipelineについて

• AWS CodePipelineはソフトウェアのリリース手順をモデル化・視覚化・自動化する継続的デリバリーサービスです。手動承認アクションは備えますが、プロンプトのドラフト・バージョン・バリアント管理や変数によるパラメータ化は提供しません。

図による解説

アーキテクチャ図

Bedrockの標準機能と補助サービスで、プロンプトのバージョン管理・監査・承認通知を分担します。商品チームは①変数付きの商品説明テンプレートを作成し、②ドラフト版でバリアントを比較しながら反復開発した後、③承認済みの内容をバージョンスナップショットとしてデプロイします。IAM Policyがバージョン作成・デプロイ権限を絞り、CloudTrailが管理イベントを自動記録してEventBridgeへ渡し、SNSがレビュー通知を配信します。自前でS3タグやCodePipelineに承認状態を持たせると、変数によるパラメータ化とバリアント比較が欠落し、監査証跡も手作業になりがちです。Bedrock標準機能を中心に据えることで、カスタム開発なしにガバナンス要件を満たします。

解くための考え方

Amazon Bedrockプロンプト管理は、バージョン管理とパラメータ化をネイティブに備えています。ドラフトでの反復、本番向けスナップショットの切り出し、変数によるテンプレート化、バリアントの比較まで組み込み済みです。S3タグやCloudFormationではプロンプト固有のバージョン管理には足りません。 監査証跡については、CloudTrailがBedrockの管理イベントを自動で記録します。CloudWatchはメトリクス監視向きで、操作の詳細を追う監査にはCloudTrailが正解です。 承認ワークフローは、IAMポリシーでバージョン作成・デプロイ権限を絞り、通知はCloudTrailからEventBridgeを経てSNSで届けます。IAMだけでは通知を送れない点に留意し、AWSのイベントルーティング機能を組み合わせれば、CodePipelineやLambdaといった自作なしで要件を満たせます。 プロンプト管理とCloudTrail、EventBridge、SNS、IAMの組合せは、全要件をAWS標準機能だけで満たします。 参考資料

• Amazon Bedrockプロンプト管理を使用して再利用可能なプロンプトを構築して保存する
• プロンプト管理でバージョンを使用してアプリケーションにプロンプトをデプロイする
• プロンプト管理を使用してプロンプトを作成する
• プロンプト管理でサポートされているリージョンおよびモデル
• AWS CloudTrailを使用したAmazon Bedrock API呼び出しのログ記録
• Amazon Bedrockでのアイデンティティベースのポリシー例
• Amazon Bedrock Flowsを使用してプロンプトをアプリケーションに統合する
• プロンプト管理を使用してプロンプトをテストする
• Amazon EventBridgeによるCloudTrailイベントのルーティング
• Amazon SNSによる通知の送信
• AWS CodePipelineとは

正解：A

A. Amazon API GatewayのWebSocket APIをLambda統合で立て、翻訳文はAmazon BedrockのInvokeModelWithResponseStream APIから受け取り、確立したWebSocket接続を通じて生成途中のチャンクを順次クライアントへ流す構成にします。

正解 WebSocket APIは双方向の持続接続で、サーバーからクライアントへリアルタイムにデータを押し出せます。InvokeModelWithResponseStream APIはBedrockのストリーミング推論APIで、翻訳を生成しながらチャンク単位で返します。この組合せなら1文字ずつの表示、数千同時接続、15〜45秒の長時間応答での継続配信を満たせます。ただしWebSocket APIのLambda統合タイムアウトは50ミリ秒〜29秒で固定され引き上げられないため、同期統合だけで45秒の翻訳を返し切ることはできません。実装では非同期プッシュに切り替えます。まず`$connect`ルートで接続時にconnection IDを保存し、翻訳元テキストを受け取るルート（例:`$default`）ではLambdaをInvocationType=Eventで非同期起動して、統合自体は即座にACKを返します。続いて非同期Lambda（最長15分）がInvokeModelWithResponseStreamを呼び、受け取ったチャンクをAPI Gateway Management APIの`PostToConnection`（`@connections`）で該当のconnection IDへ逐次プッシュします。これで接続管理とスケーリング（接続は最長2時間、アイドルタイムアウト10分）をAPI Gatewayに任せ、長時間のストリーミング推論を安全に中継できます。

B. 中間のゲートウェイやプロキシを置かず、フロントエンドがIAMユーザーの認証情報でAmazon Bedrockへ直接つなぎ、InvokeModelWithResponseStream APIを呼び出します。レート制限とアクセス制御はアプリケーション側で実装します。

不正解 フロントエンドにIAMユーザーの認証情報を埋め込むのは重大なセキュリティリスクで、漏れるとAWSリソースへの不正アクセスにつながります。中間レイヤーがないためレート制限やアクセス制御を一元管理できず、数千の同時利用へのスケーリングやモニタリングにも対応できません。AWSのセキュリティベストプラクティスに反します。

C. Amazon API GatewayのHTTP APIをLambda統合で構成し、翻訳結果をAmazon Kinesis Data Streamsへ流します。フロントエンドはストリームから一定間隔でレコードを取得して画面へ表示する実装にします。

不正解 Kinesis Data Streamsはログやイベントなどのデータレコードをリアルタイムに取り込んで処理するストリーミング基盤であり、ブラウザ上の個々のエンドユーザーへ翻訳文を1文字ずつ双方向で届ける用途には向きません。クライアントはストリームを直接購読できず、間に別の配信層を挟む必要があります。加えて翻訳結果を完成後に流すため、生成と同時に逐次表示する要件も満たせません。

D. Amazon API GatewayのREST APIをLambda統合で構成し、Amazon Bedrockは標準のInvokeModel APIで呼び出します。フロントエンドは100ミリ秒おきにポーリングして、完成した翻訳のチャンクを受け取る実装にします。数千人が同時にポーリングすれば大量のHTTPリクエストが発生して負荷が膨らみます。

不正解 標準のInvokeModel APIは非ストリーミングのため、Bedrock側でチャンク単位の応答が生まれません。翻訳全体が完成するまでクライアントには何も届かず、「1文字ずつ表示」を満たせません。100ミリ秒間隔のポーリングは数千人が同時に使えば大量のHTTPリクエストを生み、API Gatewayとバックエンドに無駄な負荷をかけます。なお2025年11月にREST APIのレスポンスストリーミング（ResponseTransferMode=STREAM、最長15分）が追加され、REST APIとInvokeModelWithResponseStreamの構成自体は可能になりましたが、この選択肢はその構成ではないため誤りです。

全体的な説明

問われている要件

• AIが生成した翻訳文を1文字ずつリアルタイムで表示する
• Amazon Bedrockの基盤モデルを使用したストリーミング推論の実現
• 数千の同時ユーザーを最小限のレイテンシでサポートする
• 15〜45秒かかる翻訳生成中の継続的なデータ配信

前提知識

Amazon Bedrockのストリーミング推論について

• InvokeModelWithResponseStream APIは、基盤モデルのレスポンスをストリーム形式で返すAPIです。水道の蛇口のように、データが生成されるたびに少しずつ流れてくるイメージです。レスポンス全体の生成を待たず、チャンク単位で逐次的にクライアントへ送信されます。Messages API互換の会話形式で利用できるストリーミングAPIとしてConverseStream APIも提供されており、いずれも基盤モデルのストリーミング推論の代替として利用可能です。
• 標準のInvokeModel APIはレスポンス全体が生成されてから一括で返すため、長時間の推論ではユーザー体験が大幅に低下します。
• ストリーミングレスポンスはHTTPイベントストリーム形式（application/vnd.amazon.eventstream）で返されます。ストリーミング対応の有無はGetFoundationModel APIおよびConverseStream APIのドキュメントで参照されるresponseStreamingSupportedフィールドで確認できます。

API Gateway WebSocket APIについて

• WebSocket APIは双方向の永続的な接続プロトコルです。電話回線のように一度接続すれば双方向でいつでもデータを送受信でき、HTTPのようにリクエストごとに接続を確立する必要がありません。
• API Gateway WebSocket APIはLambda統合をサポートし、接続管理・メッセージルーティング・スケーリングを自動的に処理します。接続は最大2時間維持され、アイドルタイムアウトは10分です。ただしWebSocket APIのLambda統合タイムアウトは50ミリ秒〜29秒で固定され、引き上げられません。このため、15〜45秒のBedrock推論レスポンスを単一Lambdaの同期統合で返し切ることはできません。実装上は$connectルートでconnection IDを保存し、受信メッセージ処理では非同期Lambdaを起動して即時ACKを返したうえで、別LambdaがPostToConnection（@connections）APIで部分レスポンスを順次プッシュする設計が必要です。
• なお、2024年6月のアップデートによりリージョンREST APIおよびプライベートREST APIの統合タイムアウトは29秒から最大5分まで引き上げ可能になりました（アカウントのスロットル上限引き下げと引き換え、バッファモード時）。一方、WebSocket APIおよびEdge-optimized REST APIは引き上げ対象外で、29秒固定のままです。
• REST APIは2025年11月19日からレスポンスストリーミング機能（ResponseTransferMode=STREAM）をサポートしており、Regional/Edge-optimized/Privateいずれのエンドポイントでも、Lambdaプロキシ統合やHTTP/プライベート統合と組み合わせて最大15分のレスポンスストリーミングが可能です（Regional/Privateのアイドルタイムアウトは5分、Edge-optimizedは30秒）。したがってREST API + Lambda（STREAMモード）+ InvokeModelWithResponseStream の組み合わせも、本問のような15〜45秒のストリーミング推論には技術的に十分対応可能であり、WebSocketと並ぶ有効な代替アーキテクチャです。HTTP APIはレスポンスストリーミング機能をサポートしていません。
• WebSocket APIとREST APIストリーミングの使い分けは、クライアントからの追加メッセージ送信や複数クライアント間のプッシュなど双方向通信が必要な場合はWebSocket、単一のリクエスト/レスポンスで段階的に返せばよい場合はREST APIストリーミングの方がシンプルです。本問の選択肢にはREST APIストリーミング構成が含まれていないため、提示された選択肢の中ではWebSocket APIが唯一のストリーミング配信可能な構成となります。

AWSにおけるリアルタイムアーキテクチャの設計パターンについて

• セキュリティのベストプラクティスとして、フロントエンドからAWSサービスへの直接アクセスは避け、API Gatewayなどのマネージドサービスを中間レイヤーとして配置します。
• IAM認証情報はサーバーサイドで管理し、クライアント側には公開しません。フロントエンドにはAmazon Cognitoなどによる一時的な認証トークンを使用します。
• Lambda関数の最大実行時間は15分であり、15〜45秒のBedrock推論レスポンスの処理には十分な余裕があります。ただしAPI Gatewayの統合タイムアウト（WebSocket APIは29秒固定・引き上げ不可、Edge-optimized REST APIも29秒固定、Regional/Private REST APIのバッファモードはデフォルト29秒・2024年6月以降は最大5分まで引き上げ可、REST APIストリーミングモード（2025年11月〜）は最大15分）はLambdaタイムアウトとは別軸の制約である点に注意が必要です。

Amazon Kinesis Data Streamsについて

• Kinesis Data Streamsはログやイベントなどのデータレコードをリアルタイムに取り込んで処理するストリーミング基盤です。データ処理アプリケーションがレコードを読み取る構成であり、ブラウザ上の個々のエンドユーザーへ双方向でリアルタイム配信する用途には向きません。

図による解説

アーキテクチャ図

29秒固定の統合タイムアウトを避けるため、非同期プッシュで配信します。社員端末は①WebSocket接続を確立し、$connectでconnection IDを保存します。②翻訳元テキストを受け取ったLambdaはWorker Lambdaを非同期起動して即座にACKを返し、③WorkerがInvokeModelWithResponseStreamでBedrockへ翻訳を依頼します。④生成チャンクは⑤@connectionsのPostToConnectionで当該connection IDへプッシュされ、⑥端末に1文字ずつ届きます。同期統合のままでは45秒の翻訳を返し切れず、REST APIとポーリングでは完了まで何も表示されません。非同期化でLambdaの15分の実行上限を活かし、長時間ストリームを継続配信します。

解くための考え方

「1文字ずつ表示」には、全文の完成を待たず生成途中のデータを逐次送るストリーミングが前提になります。BedrockにはInvokeModelWithResponseStream APIとConverseStream APIというストリーミング対応の推論APIが用意されています。この時点で、標準InvokeModel APIとポーリングの組合せ、あるいはKinesis Data Streamsへ流す方式は、ストリーミング推論を使っていないため生成中のリアルタイム配信ができず、要件を満たしません。 続いて「数千同時利用」「最小限のレイテンシ」「15〜45秒の応答」を踏まえると、効率的な接続管理と長時間のストリーム維持が要ります。この条件を満たす代表的なAWS構成は次の2つです。

• API Gateway WebSocket API + Lambda + InvokeModelWithResponseStream: 双方向の持続接続でサーバーからデータを押し出します。WebSocket APIのLambda統合タイムアウトは29秒固定のため、$connectで保存したconnection IDへ非同期LambdaがPostToConnectionでチャンクを送る設計が要りますが、Lambdaは最長15分動くので45秒の翻訳も扱えます。
• API Gateway REST API（ResponseTransferMode=STREAM）+ Lambda + InvokeModelWithResponseStream: 2025年11月19日にGAとなった機能で、レスポンスストリーミングのタイムアウトは最長15分（Regional/Privateのアイドルタイムアウトは5分）でチャンク逐次配信に対応しており、本問の15〜45秒の翻訳にも十分応えられます。

提示された選択肢の中で、ストリーミング推論APIかつ段階的配信が可能なのはWebSocket APIの構成だけです。REST APIの選択肢は標準InvokeModel（非ストリーミング）とクライアントポーリングで、そもそもストリーミング推論を使っていない時点で要件を満たしません（REST APIのレスポンスストリーミング構成は選択肢に含まれません）。 セキュリティ面では、フロントエンドがIAM認証情報でBedrockへ直接接続する案は認証情報漏えいのリスクがあり、ベストプラクティスに反します。API Gatewayを中間レイヤーに置けば認証・認可の一元管理、レート制限、アクセスログが実現でき、エンタープライズ用途にふさわしい構成になります。提示された中ではAPI Gateway WebSocket API（非同期プッシュ）、Lambda、InvokeModelWithResponseStream APIの組合せが全要件を満たします。 参考資料

• InvokeModelWithResponseStream APIリファレンス
• ConverseStream APIリファレンス
• Amazon Bedrockでモデルの推論を実行する
• ストリーミング推論のコード例
• API Gateway WebSocket API
• WebSocket API Lambda統合のセットアップ（統合タイムアウト29秒）
• API Gateway クォータと重要な注意事項（WebSocket統合タイムアウト仕様）
• Amazon API Gateway 統合のタイムアウト制限が 29 秒から引き上げ（2024-06、リージョン/プライベートREST APIのみ対象）
• API Gateway Management API（PostToConnection / @connections）
• REST APIのレスポンスストリーミング（ResponseTransferMode=STREAM）
• Building responsive APIs with Amazon API Gateway response streaming（AWS Compute Blog）
• WebSocket API チュートリアル: Lambda、DynamoDB を使用したチャットアプリ
• AWS Lambdaの概要
• Amazon Bedrockのセキュリティベストプラクティス
• Amazon API Gatewayの概要
• Amazon Kinesis Data Streamsとは