フィンテック企業が Amazon Bedrock を使ったマルチモデル AI プラットフォームを構築しています。Claude 3、Llama 3、Amazon Titan Text を対象とし、運用チームがコード変更なしに設定ファイルのみでモデルを切り替えられる必要があります。各モデルはリクエスト/レスポンスのフォーマットが異なります。コードの複雑さを最小限に抑えるために使用すべき Amazon Bedrock API はどれですか？
A
モデル ID を設定パラメータとして渡す Converse API
✓ 正解
Converse API はモデルごとのリクエスト/レスポンス形式の差異を内部で吸収し、Claude・Llama・Titan など異なるモデルをモデル ID の変更だけで切り替えられる統一インターフェースを提供する。コード変更不要で設定ファイルのみのモデル切り替えを実現できる。
B
各基盤モデル専用のリクエストアダプターを実装した InvokeModel API
InvokeModel API はモデルごとに異なる JSON リクエストボディ形式を使用するため、モデルを切り替えるたびに専用アダプターのコード変更が必要となる。コードの複雑さを最小化するという要件を満たさず、設定ファイルのみでの切り替えも実現できない。
C
カスタムレスポンス正規化ツールを組み合わせた InvokeModelWithResponseStream API
InvokeModelWithResponseStream API はストリーミングレスポンス専用であり、モデル間のリクエスト/レスポンス形式の差異を吸収する統一インターフェース機能を持たない。モデル切り替え時にはコード変更が依然として必要となり、要件を満たさない。
Converse API は複数の基盤モデルに対して統一されたインターフェースを提供する会話型 AI 向け API です。Claude、Llama、Titan など異なるモデルのリクエスト/レスポンス形式の差異を内部で吸収するため、アプリケーションコードを変更せずモデル ID を変えるだけでモデルを切り替えられます。Converse API はメッセージ配列形式（system/user/assistant）を統一インターフェースとして提供し、ストリーミング版の ConverseStream API も同様の抽象化を提供します。
選択肢Bの InvokeModel API はモデルごとに異なる JSON リクエストボディ形式を使用するため、モデルを切り替えるたびにアダプターのコード変更が必要です。
選択肢Cの InvokeModelWithResponseStream API はストリーミングレスポンス専用の API で、各モデル固有のフォーマット差異を解消する機能はありません。
選択肢Dのバッチ推論 API（CreateModelInvocationJob）は非同期の大量一括推論向けであり、リアルタイムの会話型ユースケースには適していません。