あるSaaS企業が、Amazon BedrockでClaude 3.5 Sonnet・Meta Llama 3 70B・Amazon Nova Proを使い分ける多機能チャットボットを開発しています。現在の実装ではモデルごとに異なるリクエスト／レスポンス構造を解析するアダプタークラスをInvokeModel APIで個別に実装しており、新モデル追加のたびにアダプター実装が必要となり保守コストが増大しています。モデル追加時のコード変更を最小化しながら、マルチターン会話・ツール使用・ストリーミングをすべてサポートする実装に変更するには何をすべきですか？
Amazon Bedrock Converse APIは、サポートされる全基盤モデルに対して統一されたインターフェースを提供します。InvokeModel APIではモデルごとに異なるリクエスト／レスポンス形式（例：ClaudeはAnthropic形式、LlamaはMeta形式）を個別にパースする必要がありますが、Converse APIでは単一の標準化されたmessages配列・role形式が使用でき、新モデル追加時もAPIコール部分の変更は不要です。マルチターン会話（messages履歴）、ツール使用（toolConfig）、ストリーミング（ConverseStream API）もネイティブサポートしています。 選択肢Aの AWS SDKのラッパーライブラリ自社開発は、Converse APIと同等の抽象化を独自に実装することになり、開発・保守コストが高止まります。 選択肢Cの AWS Lambdaレイヤーへのパーサー移動は、コードの場所を変えるだけで、モデル別パーサーの保守負担は変わりません。 選択肢Dの Amazon Bedrock Batch Inference は、リアルタイム応答が不要な大量非同期処理向けであり、インタラクティブなチャットボット用途には不適切です。