ある金融機関が、自社データセンターでホストするオープンソースLLMと、Amazon Bedrock 上のモデルを併用するハイブリッド生成AI基盤を構築しています。コンプライアンス部門は「Bedrock モデルだけでなく、

Question

ある金融機関が、自社データセンターでホストするオープンソースLLMと、Amazon Bedrock 上のモデルを併用するハイブリッド生成AI基盤を構築しています。コンプライアンス部門は「Bedrock モデルだけでなく、自社ホストLLMの入出力にも、Bedrock で定義したのと同一のコンテンツポリシー・拒否トピック・PIIマスキングを一貫して適用したい。さらに将来の他社モデルにも同じポリシーを再利用したい」と要求しています。最小の追加開発でこの要件を満たす方法はどれですか。

Accepted Answer

正解: Bedrock Guardrails を作成し、各モデル呼び出しの前後で ApplyGuardrail API を独立して呼び出し、入力と出力を評価する。Amazon Bedrock Guardrails の ApplyGuardrail API は、基盤モデルの呼び出しから切り離して任意のテキストを評価できる独立APIである。これにより、Bedrock 上のモデルだけでなく、オンプレミスの自社ホストLLMや将来の他社モデルの入出力にも、同一の Guardrail（コンテンツポリシー・拒否トピック・PIIマスキング）を一貫して適用でき、ポリシーを再利用できる。アプリ側はモデル呼び出し前後で ApplyGuardrail を呼ぶだけでよく追加開発が最小。

選択肢BのWAFは通信レイヤの保護であり、生成テキストのコンテンツポリシーや拒否トピック評価はできず、ポリシーも二重管理になる。
選択肢CのKnowledge Bases はRAG用途で、外部LLM応答にGuardrailを適用する仕組みではない。
選択肢Dのカスタムモデルインポートは特定アーキテクチャ・形式の制約があり、オンプレ運用を維持したいという前提に反し、他社モデルの再利用も保証されない。

Answer

自社ホストLLM用に Bedrock Guardrails とは別のWAFルールを作成し、Bedrock 側のみ Guardrails を InvokeModel に紐付ける — WAFはHTTPリクエストレベルの防御であり、生成テキストの拒否トピックやPIIマスキングといったコンテンツポリシー評価はできず、Bedrock側と二重管理になり一貫適用の要件を満たさないため誤り。

Answer

Bedrock Guardrails を作成し、Knowledge Bases 経由でのみ自社LLMの応答を再入力してフィルタリングする — Knowledge Bases はRAGのための検索・グラウンディング機能であり、外部LLMの出力にGuardrailポリシーを適用する仕組みではないため、要件のポリシー一貫適用には使えず誤りである。

Answer

Bedrock のカスタムモデルインポートで自社LLMを取り込み、Guardrails を関連付けて Bedrock 経由で推論させる — カスタムモデルインポートは対応アーキテクチャやフォーマットの制約があり、自社データセンターでのホスト継続という前提に反するうえ、将来の他社モデルへのポリシー再利用も保証されないため不適切。

解説

解説