AWS Certified Generative AI Developer - Professional 資格対策コース

モデル切替を可能にする抽象化アーキテクチャ

編集 LuaGate編集部公開 2026/05/30

このレッスンで学ぶこと 対応試験ドメイン D1 タスク 1.2.2（モデル切替を可能にする抽象化の設計）。AWS Lambda・Amazon API Gateway・AWS AppConfig と Amazon Bedrock の Converse API を組み合わせ、アプリのデプロイなしにモデルを差し替えられるアーキテクチャ判断を身につけます。

解説

基盤モデルは進化が速く、より良いモデルへ乗り換える場面が頻繁にあります。資格試験では、モデルを差し替えてもアプリ本体に手を入れなくて済む抽象化アーキテクチャの設計が問われます。モデル ID を直書きせず、外から切り替えられる構造にするのが核心です。

Converse API がモデル差を吸収する

抽象化の土台が Amazon Bedrock の Converse API です。modelId を差し替えるだけで、リクエストボディの形式差を意識せず複数モデルを同一コードで呼べます。InvokeModel はモデルごとにボディ形式が異なるため、差し替えに弱く抽象化の足を引っ張ります。

AWS AppConfig で「どのモデルを使うか」を外出しする

「今どのモデルを使うか」をコードから切り離して管理するのが AWS AppConfig です。モデル ID や推論パラメータを設定として保持し、検証・段階的デプロイ・ロールバックを伴って動的に配信できます。アプリは起動中に最新設定を取得して切り替えられるため、再デプロイなしでモデルを切り替えられます。環境変数だけだと変更のたびに再デプロイが必要で、段階的ロールアウトもできません。

Python

import boto3, json

appconfig = boto3.client("appconfigdata")
bedrock = boto3.client("bedrock-runtime")

# AppConfig から「現在使うモデル ID」を動的取得（再デプロイ不要）
def current_model_id(token: str) -> str:
    resp = appconfig.get_latest_configuration(ConfigurationToken=token)
    cfg = json.loads(resp["Configuration"].read())
    return cfg["modelId"]


def ask(model_id: str, prompt: str) -> str:
    resp = bedrock.converse(
        modelId=model_id,
        messages=[{"role": "user", "content": [{"text": prompt}]}],
        inferenceConfig={"maxTokens": 512},
    )
    return resp["output"]["message"]["content"][0]["text"]

Lambda + API Gateway で呼び出し口を一本化する

抽象化レイヤー自体は AWS Lambda に置き、Amazon API Gateway で統一エンドポイントを公開します。クライアントは「どのモデルか」を知らずに 1 つの API を叩くだけです。モデル選定・パラメータ・ガードレール適用は Lambda 内に閉じ込め、AppConfig で外から制御します。これにより、フロントエンドや他サービスを一切変えずにバックエンドのモデルを切り替えられます。

試験で問われるポイント

「アプリを再デプロイせずにモデルを切り替えたい」と来たら、AWS AppConfig で設定を動的配信するのが正解。環境変数のハードコードや定数埋め込みは再デプロイが必要でひっかけ
AWS AppConfig と AWS Systems Manager Parameter Store / Secrets Manager は似て非なるもの。動的フラグ・段階的デプロイ・自動ロールバック付きで「設定を安全に切り替える」のは AppConfig。単なる値の保存は Parameter Store、機密の保存は Secrets Manager
モデル差を吸収する統一インターフェースは Converse API。InvokeModel はモデル別ボディで差し替えに弱い
試験で問われるのは AWS のどの仕組みで抽象化・動的切替を実現するかであり、一般的な依存性注入論ではない

サービスの使い分け早見表

やりたいこと	使うもの	混同しやすいもの
モデル ID を再デプロイなしで動的切替	AWS AppConfig	環境変数（変更に再デプロイが必要）
モデル差を吸収する統一呼び出し	Amazon Bedrock Converse API	InvokeModel（モデル別ボディで差し替えに弱い）
呼び出し口を 1 本に集約	AWS Lambda + Amazon API Gateway	クライアントから直接 Bedrock を叩く（分散して切替困難）

まとめ

モデル切替の抽象化は、Converse API でモデル差を吸収し、AWS Lambda と Amazon API Gateway で呼び出し口を一本化し、AWS AppConfig でどのモデルを使うかを再デプロイなしに動的配信することが核心です。アプリ本体を変えずにモデルを乗り換えられる構造が試験で問われます。

次のステップ

次のクイズレッスンで、本番形式のシナリオ問題に挑戦してモデル抽象化アーキテクチャの判断力を確認しましょう。