Amazon Nova 2 本番運用【reasoning/Sonic/組込ツール】

1. この記事について — 第2世代 Amazon Nova 2 を本番で使い分ける

1-1. 本記事のゴール

本記事を読み終えると、2025年12月に発表された第2世代 Amazon Nova 2(Nova 2 Lite・Nova 2 Sonic、および Preview 段階の Nova 2 Pro)を本番ワークロードで使い分けられるようになります。第1世代 Nova との最大の違いは、調整可能な extended thinking による reasoning 精度と応答速度・コストのトレードオフ設計、100万トークンという長大なコンテキストウィンドウの活用、そして外部連携なしで agentic な振る舞いを実現する組込ツール群です。本記事は GA 済みの Nova 2 Lite・Nova 2 Sonic を主軸に据え、Preview 段階の Nova 2 Pro は将来展望として位置づけたうえで、これらの新機能を本番運用の観点から解説します。第1世代の基礎知識(モデル選定・マルチモーダル生成・Guardrails 等)は既存 Vol への委譲とし、第2世代固有の差分に集中します。

第1世代 Nova と第2世代 Nova 2 の主な違い

1-2. 読者像

想定読者は、Amazon Bedrock 上で第1世代 Nova(Micro/Lite/Pro/Premier)や他の基盤モデルを用いたワークロードを既に本番運用しており、Vol1〜Vol3 で扱った Flows・Evaluations・Guardrails・Prompt management・Nova Canvas/Reel の基礎を理解している方を想定します。そのうえで、reasoning モデルの導入によるタスク精度改善、長文書・大規模コードベースを一度に処理できる長コンテキストの活用、そして code interpreter や web grounding・remote MCP tools を用いた agentic なワークフローの構築を新たに検討している開発者・アーキテクトに向けた内容です。第1世代 Nova や Bedrock の基本操作から学びたい場合は、先に Vol1 を参照することを推奨します。

具体的には、以下のいずれかに該当する方を想定しています。

• 第1世代 Nova で構築した本番ワークロードに reasoning モデルを追加導入したい
• 大規模文書・コードベース全体を一度に処理する長コンテキストのユースケースを検討している
• 外部システム連携なしで code interpreter・web grounding・MCP ツールを使った agentic な機能を実装したい
• 音声対話エージェントを Nova 2 Sonic で構築・刷新したい

1-3. 本シリーズの位置づけと既存記事との棲み分け

Amazon Bedrock 本番運用シリーズは、Vol1(Flows・Evaluations・第1世代 Nova モデル選定・CRIS)、Vol2(Amazon Q連携・Data Automation・カスタムモデル)、Vol3(Guardrails 高度化・Prompt management・Nova Canvas/Reel のマルチモーダル生成)と積み上げてきました。本 Vol4 はこれらの基礎の上に立ち、2025年12月発表の第2世代 Nova 2 が追加した固有機能——調整可能な reasoning、100万トークンコンテキスト、組込ツール、Nova 2 Sonic の speech-to-speech——に対象を限定します。第1世代の基礎解説は重複させず、各 Vol への生 HTML クロスリンクで委譲する方針を貫きます。なお、自律型エージェント基盤である Amazon Bedrock AgentCore は本シリーズとは別に AgentCore Vol1〜3 で完結済みのため、本記事のスコープには含みません。

本記事の構成

• §2: Nova 2 モデルラインナップ・提供リージョン・料金体系(前提)
• §3: 調整可能な extended thinking の本番運用
• §4: 100万トークンコンテキストの活用と設計
• §5: 組込ツール(code interpreter/web grounding/remote MCP tools)の本番運用
• §6: Nova 2 Sonic — speech-to-speech の本番運用
• §7: 実戦統合パターン(Vol1/Vol3 機能との連携)
• §8: 詰まりポイント・アンチパターン・まとめ

関連：Bedrock Vol1 (第1世代 Nova モデル選定・CRIS) を読む

2. 前提 — Nova 2 モデルラインナップ・提供リージョン・料金

2-1. Nova 2 モデルラインナップと提供ステータス

Amazon Nova 2 は 2025年12月2日に発表された第2世代の Nova ファミリーです。公式ドキュメントのモデル一覧に掲載されているのは Nova 2 Lite・Nova 2 Sonic・Nova Multimodal Embeddings の3モデルであり、GA(一般提供)しているのはこのうち Nova 2 Lite と Nova 2 Sonic です。

モデル比較一覧

• Nova 2 Lite: 高速・低コスト志向の reasoning モデルです。高頻度呼び出しが必要な本番アプリケーション向けに最適化されており、調整可能な extended thinking(§3 で詳述)に対応する唯一のモデルでもあります。
• Nova 2 Pro: 最も高度な多段タスク向けと位置づけられていますが、本記事執筆時点では GA しておらず公式モデル一覧にも掲載されていません。Amazon Nova Forge という「独自のフロンティアモデルを構築するためのサービス」の早期アクセスを通じてのみ利用できます。本番運用記事の主軸には据えず、GA 済みの Lite/Sonic を軸とし、Pro は将来展望として §8 で触れるに留めます。
• Nova 2 Sonic: speech(音声)と text の両方を入出力できる speech-to-speech モデルです。第1世代 Nova Sonic からの進化点(多言語対応・turn-taking 制御の強化等)は §6 で詳述します。
• Nova Multimodal Embeddings: text/image/document/video/audio を統一的な埋め込み空間へ変換するモデルです。agentic RAG やマルチモーダル検索向けですが、本記事のスコープ外のため言及のみに留めます。

全モデルに共通して、最大100万トークンのコンテキストウィンドウと、1回の応答で最大65,536トークンの出力に対応します(reasoning effort を high に設定した場合、応答が65,536トークンを超えるケースもあり得る点は §3-2 で扱います)。

アクセス方法

Nova 2 モデルは以下の方法で呼び出せます。

• Amazon Bedrock の Converse API または InvokeModel API(プログラムからの呼び出し)
• Amazon Bedrock の Chat/Text playground(Nova 2 Lite・Nova 2 Sonic のみ対応。Preview の Nova 2 Pro は playground 非対応)

Converse API 経由で Nova 2 Lite を呼び出す最小構成は以下の通りです(reasoning 設定を伴わない基本呼び出し。extended thinking の有効化は §3 で扱います)。

import boto3

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

response = bedrock.converse(
 modelId="us.amazon.nova-2-lite-v1:0",
 messages=[
  {
"role": "user",
"content": [{"text": "Nova 2 Lite の基本的な呼び出し例です。"}],
  }
 ],
 inferenceConfig={"maxTokens": 1000, "temperature": 0.7},
)

print(response["output"]["message"]["content"][0]["text"])

modelId に指定している us. プレフィックス付きの ID は、後述の global cross-region inference(CRIS)向けの推論プロファイル ID です。単一リージョン固定のモデル ID とは別に管理されるため、既存 Vol1 のワークロードから移行する際は ID 体系の違いに注意してください。

用途別のモデル選定の目安

• テキスト・画像・動画・文書を扱う高頻度な reasoning タスク → Nova 2 Lite(GA・本記事の主軸)
• 音声入力から音声出力までを1モデルで完結させたい対話エージェント → Nova 2 Sonic(GA・§6 で詳述)
• 最も高度な多段タスクを検討しているが、まずは設計だけ先行させたい → Nova 2 Pro の Preview 動向を注視しつつ、本番実装は Lite/Sonic を軸に進める
• テキスト・画像等の埋め込みによる検索・レコメンド用途 → Nova Multimodal Embeddings(本記事スコープ外・別途公式ドキュメントを参照)

いずれのモデルを選定する場合も、Preview 段階の Nova 2 Pro を除き GA 済みモデルのみを本番採用の対象とし、Preview モデルへの依存を本番設計に組み込まないことが重要です。

2-2. 提供リージョンとデータレジデンシ

Amazon Nova 2 は Amazon Bedrock 上で global cross-region inference(CRIS)経由により複数ロケーションで提供されます。本記事執筆時点で公式情報が明示しているのは「global CRIS 経由で利用可能」という事実までであり、東京(ap-northeast-1)への個別提供有無は公式一次情報から確認できませんでした。そのため本記事では「東京 GA」等の断定は行わず、global CRIS 経由での利用を前提に設計を進めます。

CRIS 自体の仕組み(推論リクエストがどのリージョン群を経由し得るか)とデータレジデンシ設計(契約・コンプライアンス上の考慮点)は Vol1 §5-3 で解説済みのため、詳細はそちらへ委譲します。本節では Nova 2 固有の設計観点のみを整理します。

• レイテンシ設計: global CRIS はリクエストを複数リージョンへ動的にルーティングするため、単一リージョン固定より平均レイテンシが安定しやすい一方、リクエストごとの経由リージョンが変動し得る点を前提に、タイムアウト・リトライを設計する必要があります。
• コンプライアンス確認: 金融・医療等、データの越境移転に制約がある業界では、global CRIS が許容範囲内かを事前にコンプライアンス部門と確認してください。
• 東京個別提供の継続確認: 本記事執筆時点で未確認の東京個別提供の状況は変わり得るため、本番導入前に AWS リージョン別サービス一覧 で最新状況を確認してください。
• 既存ワークロードとの併用: Vol1 で導入済みの第1世代 Nova(geographic CRIS 利用)と Nova 2(global CRIS 利用)を併用する場合、レジデンシ要件が異なる点を踏まえてルーティング設計を分離してください。
• フェイルオーバー設計: global CRIS は複数リージョンへの分散が前提のため、単一リージョン障害時の切り替えを意識したアプリケーション側のリトライ設計は不要になる一方、Bedrock サービス自体の広域障害時の代替手段(他モデルへのフォールバック等)は別途検討してください。

第1世代 Nova(Vol1)と Nova 2(本記事)の CRIS 対応比較

重要: 最新の対応モデル・リージョン一覧は inference-profiles-support.html を本番設計時に必ず確認してください。Nova 2 は発表直後のモデルであり、対応 CRIS の種類は今後拡張される可能性があります。

2-3. 料金体系とコスト設計の考え方

Amazon Nova 2 の料金は、他の Bedrock モデルと同様に入力トークン・出力トークンの処理量に応じた従量課金であり、モデルごとに異なる価格ティアが設定されています。公式ドキュメントでは Nova 2 Lite が「コスト効率の高い高頻度処理向け」、Nova 2 Sonic が「音声対応アプリケーション向けのバランス型価格」と位置づけられていますが、正確な単価は変動するため、実装前に必ず Amazon Bedrock の公式料金ページ で最新値を確認してください。

本番導入前のコスト設計チェックリスト

さらに、トークン使用量は CloudWatch のモデル呼び出しメトリクス(入力/出力トークン数、呼び出し回数)で継続的にモニタリングし、想定外のコスト増加(extended thinking の意図しない常時 ON 化や、長コンテキストの濫用等)を早期検知できる体制を整えることを推奨します。Converse API のレスポンスには usage フィールドが含まれており、呼び出し単位でも入出力トークン数を取得できます。

response = bedrock.converse(
 modelId="us.amazon.nova-2-lite-v1:0",
 messages=[{"role": "user", "content": [{"text": "コスト監視のサンプル呼び出しです。"}]}],
)

usage = response["usage"]
print(f"inputTokens={usage['inputTokens']} outputTokens={usage['outputTokens']} totalTokens={usage['totalTokens']}")

この usage を呼び出しログへ記録し、日次・週次で集計することで、extended thinking の ON/OFF や reasoning effort の変更がコストに与える影響を実測ベースで把握できます。

本番リリース前には、この usage ログを用いた小規模な負荷試験で想定コストを事前に見積もっておくことを推奨します。extended thinking のコスト最適化は §3、長コンテキスト活用の設計指針は §4 で詳しく扱います。

3. Extended thinking (調整可能 reasoning) の本番運用

3-1. ハイブリッド reasoning — 既定 OFF と明示的な ON 切り替え

Amazon Nova 2 の extended thinking は、Nova 2 Lite のみが対応するハイブリッドな reasoning 機能です。第1世代 Nova にはこの概念自体が存在せず、標準的な推論のみを提供していました。第2世代では以下の2モードを明示的に切り替えられます。

• Extended thinking OFF(既定): 効率的な latent reasoning で動作し、日常的なタスクや高頻度呼び出しのアプリケーション向けに最適化されています。
• Extended thinking ON: 明示的で段階的な reasoning を行い、深い分析を要する複雑な問題に適しています。

既定が OFF のため、既存の Nova 2 Lite 呼び出しをそのまま流用しても速度・コストへの影響はありません。extended thinking が必要なワークロードにのみ、明示的に reasoningConfig を付与して ON にする設計が基本方針になります。

3-2. reasoning effort 3段階の選定基準

extended thinking を ON にする場合、maxReasoningEffort パラメータで reasoning の深さを low / medium / high の3段階から選択します。

high を指定する場合は temperature・topP・maxTokens を明示的に指定できず、これらを同時に指定するとエラーになります。この制約は、high effort 時にモデル自身が必要な出力長を動的に判断する挙動と対応しています(詳細は §4-2 で扱います)。

3-3. Converse API での実装

extended thinking は additionalModelRequestFields 内の reasoningConfig パラメータで制御します。

import boto3

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

response = bedrock.converse(
 modelId="us.amazon.nova-2-lite-v1:0",
 system=[{"text": "You are a highly capable personal assistant"}],
 messages=[
  {
"role": "user",
"content": [{"text": "在庫最適化のための多段階の計画を立ててください。"}],
  }
 ],
 inferenceConfig={"maxTokens": 10000},
 additionalModelRequestFields={
  "reasoningConfig": {
"type": "enabled",
"maxReasoningEffort": "medium",
  }
 },
)

for item in response["output"]["message"]["content"]:
 if "reasoningContent" in item:
  print("=== REASONING ===")
  print(item["reasoningContent"]["reasoningText"]["text"])
 elif "text" in item:
  print("=== ANSWER ===")
  print(item["text"])

type は enabled / disabled の2値で、既定値は disabled です。ON にした応答には reasoningContent ブロックが追加されますが、その中身は "[REDACTED]" という固定文字列で返却されます。AWS は将来的に reasoning の中身を可視化する選択肢を残すためにこのフィールドを用意しているとしており、本記事執筆時点ではモデルの思考過程そのものを確認する手段はありません。

3-4. 速度・知性・コストのトレードオフ設計

extended thinking の運用設計では、ワークロードの性質に応じて OFF / low / medium / high を動的に切り替えることが重要です。

コスト面では、[REDACTED] 表示される reasoning トークンも通常の出力トークンと同じ単価で課金される点に注意が必要です。§2-3 のコスト設計チェックリストで触れた通り、extended thinking を必要なタスクに限定せず常時 ON で運用すると、reasoning トークン分の出力課金が積み上がり続けます。high effort では出力が65,536トークンを超えるケースもあり、意図せず ON のまま高頻度呼び出しを継続するとコストが急激に膨張するリスクがあります。具体的な検知・防止策は §8 の詰まりポイントで扱います。

4. 100万トークンコンテキストの活用と設計

4-1. 1Mトークンコンテキストで実現できる本番ユースケース

Nova 2 の全モデルは最大100万トークンのコンテキストウィンドウに対応しており、以下のような本番ユースケースを1回のリクエストで処理できます。

• 大規模文書処理: 複数年分の財務報告書や大部の技術文書など、これまで分割処理が必要だった文書をまとめて入力し、横断的な質問応答や洞察抽出を行えます。
• コードベース全体解析: リポジトリ全体をコンテキストに含めた上でのコード理解・レビュー・デバッグ支援が可能です。
• 長時間会話保持: 会話履歴を要約・切り詰めせずに長時間のセッションを継続できるため、コンテキストの欠落による回答品質の劣化を避けやすくなります。
• 動画解析パイプライン: Nova 2 Lite ではマルチモーダル入力を活かし、大量の動画コンテンツから洞察抽出・要約・重要シーン特定をスケールさせる用途も想定されています。

4-2. 最大出力65,536トークンの制約

Nova 2 の全モデルは、1回の応答で最大65,536トークンまで出力できます。Converse API の maxTokens パラメータで明示的に指定しない場合は、リクエスト内容に応じた動的な既定値が使用されます。

ただし §3-2 で触れた通り、extended thinking を high effort で ON にした場合、この上限を超える出力を生成することがあり、AWS はケースによって最大128,000トークン程度まで観測されているとしています。これは reasoning の過程を完了させ、途中で打ち切られた不完全な結果を返さないための挙動です。high effort を採用する際は、この出力トークン超過分もコスト試算に含めて見積もる必要があります。

4-3. コンテキスト長とコスト・レイテンシのトレードオフ

コンテキストが長くなるほど、以下2点がトレードオフとして発生します。

• 入力トークン課金の線形増加: §2-3 で整理した通り、コンテキストの長さに比例して入力トークン課金が増加します。100万トークン近くまでコンテキストを積み上げる設計では、1回あたりの入力コストが無視できない水準になり得ます。
• 応答品質・レイテンシへの影響: 公式ドキュメントでは、コンテキストサイズが大きくなるほどシステムプロンプトへの追従性やツール利用を含む性能がわずかに低下し得るとされています。あわせて処理対象トークン数が増えるほど応答生成までのレイテンシも伸びる傾向があるため、リアルタイム性が求められる用途では不要な情報をコンテキストに含めない設計が重要です。

長文コンテキストを扱う際は、長文データをプロンプトの先頭に、指示文を末尾に配置し、複数文書を扱う場合は文書ごとに開始・終了マーカーを付与する構成が公式に推奨されています。この構成により、モデルが指示内容を見失いにくくなり、長コンテキストでの性能低下を緩和できます。

4-4. RAGとの使い分け設計

100万トークンのコンテキストウィンドウは強力ですが、あらゆる場面で長文をそのまま流し込む設計が最適とは限りません。RAG(Retrieval-Augmented Generation)は、モデルの応答に自社データソースを組み合わせて回答の正確性を高める技術であり、Nova 2 のコンテキスト活用と対立する選択肢ではなく、組み合わせて使う設計が公式にも想定されています。

大規模文書に対する質問応答のように、1Mコンテキストと RAG を組み合わせる設計も有効です。関連文書をまとめてコンテキストに投入したうえで、引用マーカー(%[1]% 等)を使って回答の根拠箇所を明示させることで、単純な長文投入よりも根拠の追跡可能性を高められます。

5. 組込ツール (built-in tools) の本番運用

5-1. 3種の組込ツール概要 — 外部連携なしで agentic 動作を実現

Nova 2 Lite は、code interpreter・web grounding・remote MCP tools という3種の組込ツールに対応しています。いずれも Converse API の toolConfig に systemTool を指定するだけで有効化できるフルマネージド機能であり、外部の実行環境やインフラを別途用意することなく agentic な振る舞いを実現できます。

いずれもユーザー定義の toolSpec(§2-1のConverse API解説やVol1の基本呼び出しと同様の function calling)とは別枠の「組込済みシステムツール」として扱われる点が特徴です。

5-2. code interpreter — サンドボックスでの Python 実行

code interpreter は、隔離されたサンドボックス環境でPythonコードを安全に実行する機能です。数式計算・論理演算・反復的なアルゴリズムなど、モデル単体では精度が出にくい処理をコード実行によって補完する用途に向いています。

import boto3

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

tool_config = {
 "tools": [{
  "systemTool": {"name": "nova_code_interpreter"}
 }]
}

response = bedrock.converse(
 modelId="us.amazon.nova-2-lite-v1:0",
 messages=[{
  "role": "user",
  "content": [{"text": "10, 24, 2, 3, 43, 52, 13, 68, 6, 7, 902, 82 の平均値を求めてください。"}],
 }],
 toolConfig=tool_config,
 inferenceConfig={"maxTokens": 10000, "temperature": 0},
)

for block in response["output"]["message"]["content"]:
 if "toolUse" in block:
  print("=== 実行コード ===")
  print(block["toolUse"]["input"]["snippet"])
 elif "toolResult" in block:
  result = block["toolResult"]["content"][0]["json"]
  print(f"stdOut={result['stdOut']} exitCode={result['exitCode']}")
 elif "text" in block:
  print("=== 最終回答 ===")
  print(block["text"])

実行結果は stdOut / stdErr / exitCode / isError という標準スキーマで返却され、アプリケーション側でエラー判定を統一的に扱えます。本番運用上の注意点として、code interpreter は執筆時点で IAD・PDX・NRT の3リージョンでのみ提供されており、Global CRIS(§2-2)経由でのルーティングを前提に設計する必要があります。また Bedrock API キー経由で呼び出す場合、デフォルトの Bedrock ロールには InvokeTool アクションが含まれないため、IAMポリシーへ明示的な追加が必要です。

5-3. web grounding — 引用付きのリアルタイム情報取得

web grounding は、モデルの学習データ以降に発生した最新情報が必要なクエリに対し、Web検索結果を根拠とした引用(citation)付きの応答を生成する機能です。有効化すると、モデルは検索要否を自律判断し、必要に応じて複数回検索したうえで、検索結果を統合した最終応答を生成します。

tool_config = {
 "tools": [{
  "systemTool": {"name": "nova_grounding"}
 }]
}

response = bedrock.converse(
 modelId="us.amazon.nova-2-lite-v1:0",
 messages=[{"role": "user", "content": [{"text": "量子コンピューティングの最新動向を教えてください。"}]}],
 toolConfig=tool_config,
)

for content in response["output"]["message"]["content"]:
 if "text" in content:
  print(content["text"])
 elif "citationsContent" in content:
  for citation in content["citationsContent"]["citations"]:
print(f"出典: {citation['location']['web']['url']}")

応答は本文テキストと citationsContent(引用元URL・ドメイン)が分離して返却されるため、アプリケーション側でテキストと出典を組み立て直す実装が必要です。公式ドキュメントは、web groundingを有効化した出力に含まれる引用・リンクをエンドユーザー向け出力に保持・表示する責任が利用者側にあると明記しており、本番実装では引用の非表示・欠落を防ぐUI設計が必須になります。なお本記事執筆時点で web grounding は US リージョンおよび US CRIS プロファイルでのみ提供されており、他リージョンのアプリケーションから利用する場合はルーティング設計に注意が必要です。web groundingは追加コストが発生する機能のため、§2-3のコスト監視の枠組みに組み込むことを推奨します。

5-4. remote MCP tools — MCP経由の外部ツール接続

Model Context Protocol(MCP)は、データソースとAIツール間の安全な双方向接続を実現するオープン標準です。remote MCP tools対応により、API・サービスごとに個別のアダプタを実装する代わりに、MCPサーバーを起動しておくだけでNova 2がクライアントブリッジ経由でツールを自動検出し、通常の外部ツール連携と同様に呼び出し・結果統合まで行います。Strands Agents SDK と組み合わせる場合は、組込の MCPClient がツールの検出・接続・結果マッピングを自動的に処理するため、実装負荷をさらに下げられます。

5-5. セキュリティ・権限設計

組込ツールを本番導入する際は、以下の観点でセキュリティ・権限設計を検討してください。

5-6. AgentCoreとの責務分界

組込ツールは、単発のConverse API呼び出しの中で完結するフルマネージドの機能であり、コードの実行・Web検索・MCPツール接続といった「1回の応答生成を補助するagentic機能」を提供します。これに対し、永続的なエージェント実行基盤・長期記憶・複数エージェントの編成・ガバナンスといった「本格的なエージェントシステムの基盤」を担うのが Amazon Bedrock AgentCore です。AgentCoreのRuntime・Memory・Gateway・Identityや、Strands Agents SDKによるマルチエージェント構成、Observability・Governanceといった機能は既に AgentCore Vol1〜3 で扱っており、本記事では再解説しません。Nova 2の組込ツールとAgentCoreを組み合わせる統合パターンの詳細も、AgentCore側の記事へ委譲します。

関連：AWS Bedrock AgentCore本番運用 Vol1 (Runtime・Memory・Gateway・Identity) を読む

6. Nova 2 Sonic — speech-to-speech の本番運用

6-1. 第1世代 Nova Sonic からの進化点

Nova 2 Sonicは、音声入力から音声出力までを1モデルで完結させるspeech-to-speechモデルです。第1世代のNova Sonicと比較して、以下の点が強化されています。

いずれも音声対話における「間」の自然さと多言語対応の実用性を底上げする進化であり、コールセンター自動化や多言語対応の音声アシスタントといった本番ユースケースに直結します。

6-2. bidirectional streaming API の実装パターン

Nova 2 Sonicは、双方向ストリーミングAPIによってリアルタイム・低レイテンシのマルチターン会話を実現します。音声入力ストリームを送信しながら、モデルが生成する音声出力ストリームを同時に受信する構成のため、リクエスト・レスポンスが1往復で完結する通常のConverse API呼び出しとは実装パターンが異なります。

本番実装では、以下の設計を前提にしてください。

• セッション継続設計: 1接続あたりの利用時間には8分の上限があります。8分を超えるセッションが想定される用途(長時間のカスタマーサポート対話等)では、接続の再確立とセッション状態の引き継ぎを行う「コネクション更新」パターンをあらかじめ実装しておく必要があります。
• 音声チャンクの送受信: 双方向ストリームでは音声データを小さなチャンク単位で送受信するため、ネットワーク遅延・パケットロスを見込んだバッファリング・再送設計が求められます。
• エラー時のリカバリ: ストリーム切断で会話コンテキストを失わないよう、直近の会話状態をクライアント側でも保持しておき、再接続後に復元できる仕組みを用意しておきます。

6-3. turn-taking・割り込み処理の設計

Nova 2 Sonicのintelligent turn-takingは、ユーザーの発話終了とアシスタントの応答開始タイミングをモデル側で検出し、自然な会話のリズムを作り出します。あわせて、ユーザーがアシスタントの発話中に割り込んだ場合も会話コンテキストを維持したまま処理できます。本番運用では、この挙動をアプリケーション側で阻害しないよう、以下を意識した設計が必要です。

• クライアント側で独自のVAD(Voice Activity Detection)による発話区切り判定を重複実装しない(モデル側のturn-taking判定と競合し、不自然な間が生じる原因になる)
• 割り込みが発生したら、クライアント側の音声出力バッファをただちに停止・破棄できる仕組みを用意しておく(モデル側がコンテキストを維持していても、クライアント側で古い音声の再生が続くと体験を損なう)
• 背景雑音や訛りへの頑健性はモデル側で考慮されているものの、マイク入力のノイズ除去処理はアプリケーション側の音響設計として別途必要になる場合がある

6-4. 非同期ツール呼び出しの設計

Nova 2 Sonicの非同期ツール呼び出しは、ツールの処理中もアシスタントが会話を継続できる(相槌や「確認しています」といった応答を挟みながらツール結果を待てる)点が特徴です。これにより、在庫確認や外部APIの呼び出しなど、応答に数秒以上かかる処理を挟んでも、無音状態でユーザーを待たせずに済みます。本番設計では、ツール呼び出しが長時間化した場合のタイムアウト・フォールバック応答(「少々お待ちください」等)をあらかじめ用意し、ツール処理の遅延がユーザー体験の劣化へ直結しないようにしてください。

6-5. レイテンシ設計と本番運用チェックリスト

音声対話エージェントではテキスト対話以上にレイテンシがユーザー体験に直結するため、以下の観点を本番導入前に確認してください。

7. 実戦統合パターン — 既存 Bedrock 機能との連携

7-1. Vol1(Flows・Evaluations)との統合 — reasoning を品質ループへ組み込む

Bedrock Flows(Vol1 §3)のPromptノードにNova 2 Liteを差し込み、additionalModelRequestFieldsでreasoningConfigを有効化すると、Flowの特定ノードだけをextended thinking対応に切り替えられます。全ノードを一律medium/highにする必要はなく、複雑な判断を要するノードだけをreasoning対応にし、単純な変換ノードはOFFのまま高速に処理する設計が効果的です。

# FlowsのPromptノードにNova 2のreasoningConfigを組み込む定義例
prompt_node_config = {
 "name": "RootCauseAnalysisNode",
 "type": "Prompt",
 "configuration": {
  "prompt": {
"sourceConfiguration": {
 "inline": {
  "modelId": "us.amazon.nova-2-lite-v1:0",
  "inferenceConfiguration": {
"text": {"maxTokens": 10000}
  },
  "additionalModelRequestFields": {
"reasoningConfig": {
 "type": "enabled",
 "maxReasoningEffort": "medium",
}
  },
 }
}
  }
 },
}

品質評価の面では、Vol1 §4のEvaluations(LLM-as-Judge)を使い、reasoning ON/OFFそれぞれの出力をバッチ評価することで、reasoning effort を上げた際の精度改善幅とコスト増分を定量的に比較できます。extended thinkingは「常にONにする機能」ではなく「Evaluationsで効果を実測してから対象タスクを絞り込む機能」として運用するのが本番設計の基本です。

また、§4で扱った100万トークンコンテキストは、Vol1 §3-2のDoWhileループで会話履歴やツール実行結果を蓄積し続けても、途中で要約・切り詰めを挟まずにループを継続できる利点があります。ループ回数が多いFlowでは、コンテキストが伸び続ける前提でトークン使用量をモニタリングし、§2-3で解説したコスト監視の枠組みに組み込んでください。

7-2. Vol3(Guardrails・Prompt management)との統合 — 統制下での Nova 2 運用

Nova 2もConverse APIのapply_guardrail・guardrailConfigを通じて、他のBedrockモデルと同じ方法でGuardrails(Vol3 §2-3)による入出力統制を適用できます。extended thinkingをONにした場合でも、Guardrailsの検査対象は最終的な応答テキストであり、reasoningContentは§3-3で触れた通り[REDACTED]として返却されるため、reasoning過程そのものはGuardrailsの検査対象にはなり得ません。統制設計上は、reasoningの中身ではなく最終出力とツール実行結果(code interpreterのstdOut、web groundingのcitation本文)を検査対象に含めることが重要です。

import boto3

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


def invoke_nova2_with_governance(prompt_id: str, prompt_version: str, user_input: str,
 guardrail_id: str, guardrail_version: str) -> dict:
 """Prompt management + Guardrails + Nova 2 reasoning の統合呼び出し例"""

 # Step1: Prompt managementからバージョン管理済みプロンプトを取得(Vol3 §4)
 prompt_resp = bedrock_agent.get_prompt(promptIdentifier=prompt_id, promptVersion=prompt_version)
 template = prompt_resp["variants"][0]["templateConfiguration"]["text"]["text"]
 final_prompt = template.replace("{{user_input}}", user_input)

 # Step2: Guardrailsで入力を事前検査(Vol3 §2-3)
 input_check = bedrock.apply_guardrail(
  guardrailIdentifier=guardrail_id, guardrailVersion=guardrail_version,
  source="INPUT", content=[{"text": {"text": final_prompt}}],
 )
 if input_check["action"] == "GUARDRAIL_INTERVENED":
  return {"status": "blocked", "reason": input_check["outputs"][0]["text"]}

 # Step3: Nova 2 Liteをextended thinking ONで呼び出す
 response = bedrock.converse(
  modelId="us.amazon.nova-2-lite-v1:0",
  messages=[{"role": "user", "content": [{"text": final_prompt}]}],
  inferenceConfig={"maxTokens": 10000},
  additionalModelRequestFields={
"reasoningConfig": {"type": "enabled", "maxReasoningEffort": "medium"}
  },
 )
 answer = next(b["text"] for b in response["output"]["message"]["content"] if "text" in b)

 # Step4: Guardrailsで最終出力を事後検査
 output_check = bedrock.apply_guardrail(
  guardrailIdentifier=guardrail_id, guardrailVersion=guardrail_version,
  source="OUTPUT", content=[{"text": {"text": answer}}],
 )
 if output_check["action"] == "GUARDRAIL_INTERVENED":
  return {"status": "output_blocked", "reason": "生成物が統制ポリシーに抵触しました"}

 return {"status": "success", "answer": answer, "prompt_id": prompt_id, "prompt_version": prompt_version}

web grounding(§5-3)を有効化する場合は、citation付き応答の本文だけでなく引用元URLの内容も間接的にユーザーへ提示することになるため、出力Guardrailsの検査対象にcitation本文を含める設計を推奨します。§5-5で触れた通り、非英語言語での間接的なプロンプトインジェクション対策には限界があるとされており、Guardrailsによる事後検査は組込ツール併用時こそ重要性が増します。

7-3. 第1世代からの移行設計 — 既存パイプラインへの差し込み

第1世代Nova(Vol1)で構築済みの本番ワークロードにNova 2を差し込む際は、全面切り替えではなく段階的な移行が安全です。

第1世代のCRIS(geographic CRIS、Vol1 §5-3)とNova 2のglobal CRIS(§2-2)はデータレジデンシ要件が異なるため、移行後も両者を並行運用する場合はルーティング設計を分離し、コンプライアンス要件の異なるワークロードを混在させないよう注意してください。

Flows・評価の深掘り：Bedrock Vol1 を読む
統制・プロンプト管理の深掘り：Bedrock Vol3 を読む

8. 詰まりポイント・アンチパターン・まとめ

8-1. 詰まりポイント(6 選)

本番運用で遭遇しやすいNova 2固有の詰まりポイントを解説します。

詰まり① Nova 2 ProをPreviewと気づかず本番採用してしまう

公式モデル一覧(§2-1)に掲載されているのはNova 2 Lite・Nova 2 Sonic・Nova Multimodal Embeddingsの3モデルのみで、Nova 2 Proは含まれていません。Nova Forgeの早期アクセス経由でNova 2 Proを試した開発者が、その体験のまま本番設計に組み込んでしまうケースが起こり得ます。本番採用前には必ずBedrockの対応モデル一覧でGA状態を確認し、Preview段階のモデルへの依存を本番設計に組み込まないでください。

詰まり② extended thinking常時ONによるコスト膨張

§3-4で触れた通り、reasoningContentは[REDACTED]表示でも通常の出力トークンと同額で課金されます。開発時に精度検証のためextended thinkingをONにしたまま、OFFへ戻し忘れて本番リリースすると、reasoningトークン分の出力課金が高頻度呼び出しの分だけ積み上がり続けます。§2-3のusageログをリクエスト単位で記録し、reasoningConfigの設定状態と出力トークン数を突き合わせるアラートを用意しておくと早期検知できます。

詰まり③ 1Mコンテキストの濫用によるコスト・レイテンシ悪化

「使えるから」という理由でコンテキストに不要な情報まで詰め込むと、§4-3で触れた入力トークン課金の線形増加とレイテンシ悪化が同時に発生します。特に長時間会話をトリミングせず全履歴を毎回コンテキストに含める設計では、セッションが進むほど1リクエストあたりのコストとレイテンシが増大します。§4-4のRAGとの使い分け基準に沿って、コーパスの更新頻度・データ量を定期的に見直してください。

詰まり④ 組込ツールのリージョン制限を見落とす

code interpreterはIAD・PDX・NRTの3リージョンのみ、web groundingはUSリージョンおよびUS CRISプロファイルのみで提供されています(§5-2、§5-3)。global CRIS経由でNova 2本体を呼び出せることと、組込ツールが利用可能であることは別条件であり、ツールによってリージョン提供状況が異なるため(code interpreterはNRTを含む3リージョンで提供される一方、web groundingはUSリージョン限定)、想定リージョン次第で組込ツールを有効化すると呼び出しエラーになるケースがあります。組込ツールを使う機能は、対応リージョンへのルーティングを個別に確認したうえで設計してください。

詰まり⑤ Nova 2 Sonicの8分接続上限を見落として長時間対話が切断される

§6-2で触れた通り、双方向ストリーミング接続には8分の利用時間上限があります。コネクション更新パターンを実装しないまま長時間のカスタマーサポート対話に投入すると、対話の途中で接続が切断され、会話コンテキストを失ってユーザー体験を損ないます。8分を超える可能性があるユースケースでは、設計初期段階からセッション継続の仕組みを組み込んでください。

詰まり⑥ reasoningContentから思考過程を取得しようとして設計が無駄になる

extended thinking ONの応答に含まれるreasoningContentは、本記事執筆時点では中身が常に[REDACTED]として返却されます(§3-3)。デバッグやログ監査のためにreasoningの中身を可視化する設計を先行して作り込むと、実際には利用できない機能に工数を投じることになります。reasoning過程の可視化が必要な場合は、AWSの公式アップデートを継続的に確認してください。

8-2. アンチパターン → 正解変換(5 選)

アンチパターン① 全リクエストにextended thinking highを適用する

アンチパターン: 精度を最大化しようとして、全リクエストでmaxReasoningEffort: "high"を既定にする。

問題点: high effortでは出力が65,536トークンを超える場合があり(§4-2)、temperature・topP・maxTokensを明示指定できない制約(§3-2)もあるため、レイテンシとコストが顧客対面アプリケーションの要件から外れます。

正解: §3-4の設計指針に沿い、ワークロードの性質に応じてOFF/low/medium/highを動的に切り替えます。高頻度・低レイテンシが求められる箇所はOFFのまま、正確性が最優先される単発タスクにのみhighを適用します。

アンチパターン② Nova 2 Proを設計の前提に組み込む

アンチパターン: 「将来Nova 2 ProがGAしたら使う」前提でアーキテクチャの中核にNova 2 Proを据えて設計を進める。

問題点: Preview仕様は変更され得るため、GA時に非公開だったAPI形式やモダリティ対応の変更によって、設計を手戻りさせるリスクがあります。

正解: GA済みのNova 2 Lite・Nova 2 Sonicを主軸に据え、Nova 2 Proは§8のような将来展望としてのみ言及します。Nova 2 ProがGAした時点で改めて採用を検討する設計にします。

アンチパターン③ 1Mコンテキストに何でも詰め込む

アンチパターン: RAGの実装コストを避けるため、あらゆるユースケースでコーパス全体を1Mコンテキストへ直接投入する。

問題点: コーパスが継続的に増加する場合や、同種の質問を高頻度に繰り返す場合、コンテキスト再送コストが累積し、RAGを使うより高コストになります。

正解: §4-4の判断基準表に沿い、データ量・更新頻度・コスト特性・精度要件を評価してから1Mコンテキスト直接投入とRAG併用のどちらを採用するか決定します。

アンチパターン④ 組込ツールをGuardrails無しで有効化する

アンチパターン: code interpreterやweb groundingを、Guardrailsの出力検査を経由せずそのままユーザーへ返却する。

問題点: code interpreterの実行結果に機密情報が含まれるリスクや、web groundingで取得した外部情報がプロンプトインジェクションの経路になるリスク(§5-5)を統制できません。

正解: §7-2のように、組込ツールの実行結果を含む最終応答に対して必ずGuardrailsの出力検査を通し、citationの表示義務も含めてUI設計に組み込みます。

アンチパターン⑤ Nova 2 Sonicでクライアント側の独自VADを重複実装する

アンチパターン: モデル側のturn-taking判定に加えて、クライアント側でも独自のVoice Activity Detectionによる発話区切り判定を実装する。

問題点: §6-3で触れた通り、2つの判定ロジックが競合し、不自然な間や誤った割り込み検知が発生してユーザー体験を損ないます。

正解: turn-taking判定はモデル側に一任し、クライアント側は割り込み発生時の音声出力バッファ停止・破棄など、モデル側では担えない処理に責務を限定します。

8-3. 本番運用監視チェックリスト

Vol4で扱ったNova 2固有機能を本番運用する際に確認すべき監視項目を整理します。

8-4. まとめと次巻予告

本記事では、2025年12月に発表された第2世代Amazon Nova 2の本番運用を、GA済みのNova 2 Lite・Nova 2 Sonicを主軸に解説しました。

Vol4で習得した主要スキルは以下のとおりです。

• Extended thinking: 既定OFF・reasoning effort(low/medium/high)の動的切り替えによる速度・知性・コストのトレードオフ設計
• 100万トークンコンテキスト: 大規模文書・コードベース解析・長時間会話保持への活用と、RAGとの使い分け判断
• 組込ツール: code interpreter・web grounding・remote MCP toolsによる、外部連携なしのagentic機能実装とセキュリティ設計
• Nova 2 Sonic: speech-to-speechの本番運用、8分接続上限を前提としたセッション継続設計、turn-taking・割り込み処理
• 実戦統合: Vol1(Flows・Evaluations)・Vol3(Guardrails・Prompt management)との連携による、第2世代モデルの既存パイプラインへの差し込み設計

Amazon Bedrock本番運用シリーズは、Vol1のFlows・Evaluations・第1世代Novaモデル選定から始まり、Vol2のAmazon Q連携・Data Automation、Vol3のGuardrails高度化・Prompt management・マルチモーダル生成、そして本Vol4の第2世代Nova 2固有機能まで、本番グレードの生成AIシステム構築に必要な要素を積み上げてきました。本シリーズはVol4をもって一区切りとし、自律型エージェント基盤の詳細はAgentCore Vol1〜3(§5-6で紹介済み)へ、横断的な評価・可観測性・コスト統制の考え方は生成AIアプリ本番運用LLMOps統合編シリーズへ、それぞれ委譲します。

関連：Bedrock Vol3 (Guardrails・Nova Canvas/Reel) を読む