FM API 統合（同期・非同期・ストリーミング）｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D2 タスク 2.4.1・2.4.2（FM API 統合パターン）。基盤モデルを呼び出す 3 方式（同期 Converse、ストリーミング ConverseStream、非同期のキュー駆動）の使い分けと、Amazon SQS・Amazon API Gateway WebSocket を使った実装パターンを判断できるようになります。

解説

FM の呼び出しは「すぐ短い応答を返す」「長い応答を少しずつ届ける」「時間のかかる処理をバックグラウンドで回す」のどれを求めるかで実装方式が変わります。試験では「ユーザー体験と処理特性に対してどの統合方式を選ぶか」が問われます。

3 つの統合方式

方式	API/構成	向いている場面
同期	Amazon Bedrock Converse	短い応答を 1 リクエストで返す。シンプルな問い合わせ
ストリーミング	Amazon Bedrock ConverseStream	生成中のトークンを逐次表示。チャット UI の体感向上
非同期	SQS/イベント + バックグラウンド処理	長文生成・バッチ・即応不要。クライアントを待たせない

同期（Converse）

Converse はリクエストを送り、応答が揃ってから一括で返す同期 API です。実装が単純で、短い応答や即時性が要る軽い処理に向きます。ただし生成完了まで接続を保持するため、長い応答ではユーザーが待つ時間が長くなります。

ストリーミング（ConverseStream）

ConverseStream は生成されたトークンを逐次ストリームで返します。チャット UI で「文字が少しずつ出てくる」体験を実現し、最初の 1 文字までの体感を大きく改善します。フロントへ届けるには、Lambda からのレスポンスストリーミングや、Amazon API Gateway の WebSocket でサーバーからクライアントへ逐次プッシュする構成を取ります。

非同期（キュー駆動）

長文レポート生成やバッチ処理など、即応が不要で時間のかかる処理は、リクエストを Amazon SQS に積んでバックグラウンドのワーカー（Lambda 等）で処理します。クライアントは「受け付けました」をすぐ受け取り、結果は後で取得（ポーリングや通知）します。これによりクライアントを長時間ブロックせず、ピーク負荷もキューで吸収できます。

コード例（ストリーミング ConverseStream）

トークンを逐次受け取る最小例です。認証は IAM ロール経由です。

Python

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

resp = bedrock.converse_stream(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role": "user", "content": [{"text": "RAG の利点を 3 つ"}]}],
)

for event in resp["stream"]:
    if "contentBlockDelta" in event:
        print(event["contentBlockDelta"]["delta"]["text"], end="")

試験で問われるポイント

同期 vs ストリーミング vs 非同期。短い即時応答は Converse（同期）、逐次表示で体感改善は ConverseStream（ストリーミング）、長時間・即応不要はキュー駆動（非同期）
長文生成でクライアントを同期待ちさせるのはアンチパターン。タイムアウトや接続切れのリスクがある。非同期（SQS）かストリーミングへ
ストリーミングのフロント配信は WebSocket（API Gateway WebSocket）や Lambda レスポンスストリーミング。通常の同期 REST では逐次プッシュできない
非同期にすると「結果の受け取り方法」（ポーリング/通知/購読）の設計が伴う。受け付け即時応答 + 後で結果取得という分離が問われる

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

やりたいこと	使うもの	混同しやすいもの
短い応答を 1 リクエストで返す	Amazon Bedrock Converse（同期）	ConverseStream（逐次が不要なら過剰）
生成トークンを逐次表示する	Amazon Bedrock ConverseStream	Converse（一括返却で逐次表示不可）
長文/バッチを非同期処理	Amazon SQS + バックグラウンドワーカー	同期 Converse（長時間ブロックで不適）
サーバーからフロントへ逐次プッシュ	Amazon API Gateway WebSocket	同期 REST（プッシュ配信できない）

まとめ

FM API 統合は処理特性で 3 方式を使い分けます。短い即時応答は Amazon Bedrock Converse（同期）、逐次表示で体感を上げるなら Amazon Bedrock ConverseStream（ストリーミング）を Amazon API Gateway WebSocket 等でフロントへ配信、長文やバッチで即応不要なら Amazon SQS によるキュー駆動の非同期です。長文を同期で待たせるのはアンチパターンで、ストリーミングか非同期に逃がすのが定石です。

次のステップ

次のクイズレッスンで、3 つの統合方式の使い分けとストリーミング配信の実装を問うシナリオ問題に挑戦しましょう。