目次を表示する

Bedrockで Production Ready な AI 機能を作る ── 設計・運用・現場の知恵

モデルを選ぶ ── Claude / Nova / Llama / Mistral / Cohere を使い分ける

モデルを選ぶ ── Claude / Nova / Llama / Mistral / Cohere を使い分ける

対象読者：「結局どのモデルを使えばいいのか」で止まっている、選定軸が欲しい読者 難易度：★★☆☆☆（Tips） 想定読了時間：約 25 分 関連章：第 6 章（Converse API での呼び出し）/ 第 15 章（コスト最適化と Prompt Routing）

全部を覚えなくていい、判断軸を持つ

2026 年 6 月時点で、Bedrock には 16 プロバイダー・100 を超える Foundation Model が並んでいる1。Anthropic の Claude、Amazon の Nova、Meta の Llama、Mistral、Cohere、AI21、DeepSeek、Google Gemma、Moonshot、MiniMax、NVIDIA Nemotron、OpenAI GPT、Qwen、TwelveLabs、Writer、Z.AI ── マネジメントコンソールの「Model catalog」を初めて開いた人は、ここでブラウザを閉じたくなるはずだ。

そのまま閉じていい。全部を覚える必要はない。重要なのは「自分のユースケースに対して、どのモデルファミリーを、どの世代で、いつ使うか」を決められる判断軸を持つことだ。世代が上がってバージョン番号が 4.5 から 4.6 に変わっても、判断軸が同じならモデル ID を 1 行差し替えるだけで済む。

この章の目的は 3 つ。

  1. 実務でほぼ全部の用途をカバーできる 5 つのモデルファミリー を世代単位で頭に入れる
  2. ユースケース別の 「第一候補・コスト最適化候補」 の対応表を持ち帰る
  3. 単一モデル運用・階層運用・自動ルーティング という 3 つの使い分けパターンから、自分の現場に合うものを選ぶ

具体的なバージョン番号（Claude Opus 4.7 か 4.8 か、Sonnet 4.5 か 4.6 か）は本文では追わない。世代単位でとらえれば十分で、最新版は AWS の model-cards ページで都度確認するのが正しい運用だ。

5 つのモデルファミリーを世代単位で押さえる

100+ モデルのうち、実務で第一候補にあがるのは Anthropic Claude・Amazon Nova・Meta Llama・Mistral・Cohere の 5 ファミリーで、ほぼすべての用途がカバーできる。それ以外（DeepSeek・GPT-OSS・Qwen・Z.AI など）は「特定の文脈で強い駒」として後から検討する位置付けで構わない。

ファミリーごとの特徴を、世代単位で整理する。

Anthropic Claude ── Opus / Sonnet / Haiku の 3 階層

Claude は Opus（最上位）・Sonnet（中位）・Haiku（軽量） の 3 階層2で提供されている。3 階層という事実そのものが、Anthropic からの「使い分けてください」というメッセージだ。

graph TD
  subgraph "Claude 4 系（2026年6月時点）"
    O[Opus 系<br/>最高難度の推論・コーディング<br/>価格：高]
    S[Sonnet 系<br/>汎用 / agent planning / 1M context<br/>価格：中]
    H[Haiku 系<br/>低レイテンシ / 高スループット / ワーカー<br/>価格：低]
  end
  O -. 一段安い .-> S
  S -. 一段安い .-> H
  • Opus 系：最高難度の推論・コーディング・長文処理。価格は最も高い。「ここぞ」の意思決定や、長文の難しい要約・分析で第一候補
  • Sonnet 系：汎用チャット・コーディング・エージェントの「主役」。1M トークンの長文も扱える。価格と性能のバランスが取れていて、多くのプロダクションシステムの中核を担う
  • Haiku 系：低レイテンシ・高スループット・低価格。マルチエージェントのワーカー役として、また分類・要約・抽出のような 「数を捌く」タスク の第一候補

Claude 4 系は Cross-Region Inference Profile（後述）と Prompt Caching・Computer Use に対応しており、Bedrock の本番運用機能との相性が良い。本シリーズの架空アプリ helpdesk-ai も、中核モデルとして Sonnet 系を採用し、軽量タスクは Haiku 系に振る構成で進めていく。

Amazon Nova ── Understanding / Creative / Speech の 7 種

Amazon 純正の Nova は、3 カテゴリ・7 モデル の構成になっている3。

graph LR
  subgraph "Understanding（理解）"
    NP[Nova Premier<br/>1M context]
    NPr[Nova Pro<br/>300K context]
    NL[Nova Lite<br/>300K context・低価格]
    NM[Nova Micro<br/>テキストのみ・最安]
  end
  subgraph "Creative（生成）"
    NC[Nova Canvas<br/>画像生成]
    NR[Nova Reel<br/>動画生成]
  end
  subgraph "Speech（音声）"
    NS[Nova Sonic<br/>双方向音声]
  end
  • Understanding（4 種）：Premier / Pro / Lite / Micro。テキスト・画像・動画入力に対応（Micro はテキストのみ）。価格は Claude より一段安く、特に Lite と Micro はトークン単価で圧倒的に安い
  • Creative（2 種）：Canvas で画像生成、Reel で動画生成
  • Speech（1 種）：Sonic は双方向ストリーミング専用の音声会話モデル。電話オペレーターや IVR の置き換えで強い

Nova の強みは 「Amazon 純正であること」 から来る統合の良さで、Knowledge Bases・Agents・Guardrails・Evaluations のすべてに対応している。Provisioned Throughput と Fine-tuning は Pro / Lite / Micro で利用可能（Premier は対象外）で、Model Distillation で Premier から Pro/Lite/Micro へ蒸留もできる。

Meta Llama ── OSS で持ち込み可能

Llama は OSS（オープンウェイト）で配布されているため、Bedrock では マネージドな On-Demand 利用（Llama 3.x / 4 系）に加えて、Custom Model Import で自分でファインチューンしたモデルを Bedrock 上に持ち込める選択肢がある4。

Llama を採用する典型的な動機は次の 3 つ。

  • OSS 互換性：他社環境（オンプレ・Azure・GCP）と同じモデルを Bedrock 上でも動かしたい
  • ファインチューン済みモデルの持ち込み：自社データで継続学習したモデルを、推論基盤だけ Bedrock に任せたい
  • コスト：mid-tier 価格帯で、Claude Sonnet 系の代替を探したい

逆に「ただ性能が高いものを使いたい」だけなら、Bedrock 上では Claude Sonnet 系または Nova Pro が最初の候補になることが多い。Llama は 「持ち込みやポータビリティを重視する場面」 で本領を発揮する。

Mistral ── 言語・コード・推論・マルチモーダル・音声の専門家集団

Mistral は 領域特化モデルの引き出しが豊富 なファミリーだ。

領域代表モデル系統想定用途
汎用言語Mistral Large 系・Ministral 系mid-tier の汎用チャット・要約
コードDevstral 系コーディングアシスタント
推論特化Magistral 系数学・論理推論
マルチモーダルPixtral 系画像入力
音声Voxtral 系音声書き起こし・理解

「特定領域に強いモデルを ピンポイントで 採用したい」場合の選択肢として有力で、特に コード生成や音声理解 の領域では Mistral のラインナップが厚い。汎用チャットの中核に据えるよりは、特定タスクの裏側で使うイメージが合っている。

Cohere ── Command + Embed + Rerank の RAG 3 点セット

Cohere は RAG の文脈で最も使われる モデルファミリーだ。

  • Command R / R+：チャット・RAG 用途。R+ は 128K context で、長文の引用ベース回答に強い
  • Embed：埋め込みモデル。多言語版（Embed Multilingual / Embed v4）は日本語の検索精度に直結する
  • Rerank 3.5：検索結果の再ランキング専用モデル。「ベクトル検索の上位 100 件を、ユーザークエリとの関連度で並べ直す」用途で 1000 クエリあたり数ドルの定額課金

Cohere の Embed と Rerank は、Knowledge Bases で RAG を組むときの 「検索品質を一段引き上げるための専門コンポーネント」 として登場する場面が多い。8 章の Knowledge Bases 編で、Bedrock 標準の埋め込みモデルと並んで具体的に検討する。

5 ファミリーを 1 枚にまとめる

quadrantChart
  title モデルファミリーのざっくり位置取り
  x-axis "汎用" --> "特化"
  y-axis "コスト重視" --> "性能重視"
  quadrant-1 "性能・特化"
  quadrant-2 "性能・汎用"
  quadrant-3 "コスト・汎用"
  quadrant-4 "コスト・特化"
  "Claude Opus": [0.3, 0.95]
  "Claude Sonnet": [0.25, 0.7]
  "Claude Haiku": [0.2, 0.35]
  "Nova Pro": [0.35, 0.55]
  "Nova Lite/Micro": [0.3, 0.2]
  "Llama 系": [0.45, 0.5]
  "Mistral 領域特化": [0.75, 0.55]
  "Cohere Embed/Rerank": [0.85, 0.4]

このマップが頭に入っていれば、要件を聞いた瞬間に「Sonnet を中核、Haiku をワーカー、Embed/Rerank で RAG 品質を底上げ」のような構成が即座に組み立てられるようになる。

ユースケース別の指針表

ファミリーごとの特徴を抽象的に押さえたうえで、実務で頻出するユースケースに対しての 「第一候補・コスト最適化候補」 を表にまとめる。research 02 §3.8 のサマリをベースにしている。

ユースケース第一候補コスト最適化候補
汎用チャット / カスタマーサポートClaude Sonnet 系 / Nova ProClaude Haiku 系 / Nova Lite
コーディング / Agent / Computer UseClaude Sonnet 系 / Opus 系—
大規模・長文ドキュメント要約Claude Sonnet 系（1M）/ AI21 Jamba—
高スループット・低レイテンシClaude Haiku 系 / Nova MicroNova Micro
画像入力理解Claude Sonnet 系 / Nova Pro / LiteNova Lite
動画理解Nova Pro / Lite / PremierNova Lite
音声会話（双方向）Nova Sonic—
画像生成Nova Canvas / Stability SD3—
動画生成Nova Reel—
マルチエージェントのワーカーClaude Haiku 系 / Nova Micro—
RAG の埋め込みCohere Embed / Amazon Titan Embeddings—
RAG の再ランキングCohere Rerank 3.5—

この表の使い方は素直で、「自分のユースケースの行を見て、第一候補から PoC を始める」だけで構わない。第一候補で動いたら、コスト最適化候補に置き換えてベンチマーク ── という順序を取れば、性能と価格の両面から納得して採用判断ができる。

表の読み方の補足

3 つだけ、表の裏側にある考え方を補足しておく。

  1. 「第一候補」は性能が最も高いものではなく、価格と性能のバランスが取れたもの を選んでいる。Opus 系は「コーディング・Agent」の行にだけ登場することに注意。汎用チャットを Opus で回すのは、ほとんどの場合オーバースペック
  2. 「コスト最適化候補」は精度を測ってから入れ替える ことが前提。Haiku に下げてユースケースの精度要件を満たさないなら、Sonnet に戻す。後述の Intelligent Prompt Routing はこの「両方を動的に使う」発想の自動化版
  3. 画像生成・動画生成・音声会話は専用モデル が必要。Sonnet や Nova Pro は画像「入力」は理解できるが、画像「生成」はできない

モデル ID は Cross-Region Inference Profile（CRIS）で書く

採用するモデルが決まったら、コードに書くモデル ID には注意点がひとつある。素のリージョン単独 ID ではなく、Cross-Region Inference Profile（CRIS）の ID を使う5。

// ❌ 悪い例：素のリージョン単独 ID（一部の最新モデルは In-region 提供が限定的）
const MODEL_ID = "anthropic.claude-sonnet-4-5";

// ✅ 良い例：CRIS ID を使う（US Geo 推論プロファイル）
const MODEL_ID = "us.anthropic.claude-sonnet-4-5";

// ✅ さらに：データ主権制約が緩いなら Global CRIS（最大スループット）
const MODEL_ID = "global.anthropic.claude-sonnet-4-5";

CRIS を使う実利は次の 3 つ。

  • スロットリング耐性：複数リージョンに自動で振り分けられるため、TPM クォータ枯渇に強い
  • 新世代モデルの提供範囲：Claude 4 系のような最新世代は、In-region 直叩きが限定リージョンのみで、CRIS 経由でしか呼べないケースがある
  • 追加料金なし：Cross-Region Inference の料金はソースリージョン基準で、CRIS 利用そのものに追加料金は発生しない。Global CRIS は Geographic（us. eu. au. jp.）よりさらに約 10% 安価

CRIS の Prefix の意味は次のとおり。

Prefix意味データ主権
us.US 内のリージョンで負荷分散US データ主権
eu.EU 内のリージョンで負荷分散EU データ主権
jp.日本国内のリージョンで負荷分散国内主権
global.全世界の最適リージョンへ制約緩い・最安

本シリーズの spec.md §2.2 でも、モデル ID は CRIS 形式で統一する規約にしている。素のリージョン単独 ID は ch17 のアンチパターン章で「Cross-Region Inference を理解せずに使う／使わない」として再登場する。

使い分けパターンは 3 つから選ぶ

モデルファミリーと表が決まったら、次は 「単一モデルで回すか、複数モデルを使い分けるか」 という運用設計の話になる。実務でよく見るパターンは 3 つに収まる。

パターン 1：単一モデル運用（シンプル）

PoC や、小〜中規模システムでは、Sonnet 系または Nova Pro の 1 モデルで全部やる のがいちばん運用が楽だ。

graph LR
  Req[リクエスト] --> M[Claude Sonnet 系<br/>または Nova Pro]
  M --> Res[レスポンス]

メリットは 複雑度ゼロ。デメリットは コスト効率が中途半端 ── 「分類するだけ」のような軽いタスクにも Sonnet を使うのは、コスト視点では明らかに過剰だ。

PoC から本番初期まではこれで十分。次のパターンに進むかどうかは、月次コスト（ch15）と SLA（ch12 評価章）を見ながら決めればよい。

パターン 2：階層運用（Haiku ワーカー + Sonnet 最終判断）

中〜大規模の本番システムでは、軽量モデルがワーカーとして数を捌き、中位モデルが最終判断する という階層構造を取ることが多い。

graph TD
  Req[リクエスト] --> R[ルーター<br/>難易度判定]
  R -->|簡単・大量| H[Haiku 系<br/>分類・抽出・要約]
  R -->|難しい・少数| S[Sonnet 系<br/>最終判断・複雑推論]
  H --> Agg[集約]
  S --> Agg
  Agg --> Res[レスポンス]

国内では 住信 SBI ネット銀行 が NEOBANK ai でこの階層パターンを採用している、ということが AWS 公式日本ブログで触れられている。マルチエージェント構成で、Haiku 系のワーカーが個別タスクを処理し、Sonnet 系が最終判断を担う、というような構成だ。詳しくは ch16 の事例章で具体的なアーキテクチャ図と合わせて扱う。

このパターンのメリットは コスト効率と性能の両立、デメリットは アプリケーションコードの複雑度が上がること（ルーター実装・モデル別エラーハンドリング・観測のモデル分離）。コスト削減効果が複雑度を上回るかを、必ず実測で確かめてから採用する。

パターン 3：Intelligent Prompt Routing で自動ルーティング

階層運用を Bedrock 側のマネージドサービスに任せる のが Intelligent Prompt Routing（2025-04 GA）だ。

graph TD
  Req[リクエスト] --> IPR[Intelligent Prompt Routing<br/>マネージドルーター]
  IPR -->|品質要件低| H[Haiku 系]
  IPR -->|品質要件高| S[Sonnet 系]
  H --> Res[レスポンス]
  S --> Res

AWS の実測値では、RAG ユースケースで 平均 63.6% のコスト削減、リクエストの 87% が Haiku 系にルーティングされた、と公式ブログで報告されている。階層運用と違ってアプリケーションコード側にルーター実装が不要なため、「最小限のコード変更で階層運用の恩恵を受けたい」 ケースで有力な選択肢になる。

詳しくは ch15 のコスト章で具体的な設定方法と、Prompt Caching・Provisioned Throughput との組み合わせ判断まで踏み込む。

3 パターンの選択ガイド

flowchart TD
  Start[モデル使い分けを決める] --> Q1{月次<br/>呼び出し数は？}
  Q1 -->|少ない<br/>PoC〜小規模| P1[パターン 1<br/>単一モデル運用]
  Q1 -->|多い| Q2{タスクの<br/>難易度幅は？}
  Q2 -->|均質| P1
  Q2 -->|広い<br/>簡単〜難しい混在| Q3{ルーターを<br/>自前実装する？}
  Q3 -->|Yes<br/>細かく制御したい| P2[パターン 2<br/>階層運用]
  Q3 -->|No<br/>マネージドに任せたい| P3[パターン 3<br/>Intelligent Prompt Routing]

まずパターン 1 から始めて、コストが見過ごせなくなったタイミングでパターン 2 / 3 に進む ── という順序が現実的だ。「最初から階層運用」は、複雑度の代償が大きく、PoC を遅らせる原因になりやすい。

章の地図と次章への接続

ここまでで、Bedrock のモデル選定に必要な道具は揃った。整理するとこうなる。

  1. 5 ファミリー を世代単位で頭に入れる：Claude（Opus/Sonnet/Haiku）/ Nova（Understanding/Creative/Speech）/ Llama（OSS 持ち込み）/ Mistral（領域特化）/ Cohere（RAG 3 点セット）
  2. ユースケース別の指針表 から第一候補を選び、PoC を回す
  3. モデル ID は CRIS 形式 で書く（us.anthropic.claude-sonnet-4-5 のように Prefix 付き）
  4. 使い分けパターン は単一モデル→階層→自動ルーティングの順で段階的に進む

ここまでが Part 1「Bedrock を理解する」の最終章だ。位置付け・他社比較・機能カタログ・モデル選定の 4 つの概念地図を手にしたところで、いよいよ Part 2「動くものを作る」 に入る。

次章から、シリーズを貫く架空アプリ helpdesk-ai を実際に組み上げていく。ch06 で Converse API による最初のリクエスト（10 行から始める）、ch07 でストリーミングと Tool Use、ch08 で Knowledge Bases による RAG、ch09 で Bedrock Agents、ch10 で AgentCore ── と段階的に機能を増築していく構成だ。中核モデルには本章で第一候補に挙げた Claude Sonnet 系 を採用し、us.anthropic.claude-sonnet-4-5 を BEDROCK_MODEL_ID 環境変数に置く。準備ができたら、エディタを開いてもらおう。

章末まとめ

  • 2026 年現在、Bedrock には 16 プロバイダー・100+ モデルがある。全部覚えるのではなく 判断軸を持つ ことが重要
  • 実務でカバーすべきモデルファミリーは Claude / Nova / Llama / Mistral / Cohere の 5 つ。世代単位（Opus / Sonnet / Haiku など）でとらえれば十分
  • ユースケース別の 「第一候補・コスト最適化候補」指針表 から PoC を始め、精度を測ってから入れ替えるのが現実的
  • モデル ID は素のリージョン単独 ID ではなく Cross-Region Inference Profile（CRIS） 形式（us.anthropic.claude-sonnet-4-5 など）で書く
  • 使い分けは 単一モデル → 階層運用 → Intelligent Prompt Routing の 3 段階で段階的に複雑化する。階層運用の実例は ch16（住信 SBI 等）、自動ルーティングの実装と数値は ch15 で詳説
  • 次章から Part 2 に入り、helpdesk-ai を Converse API から段階的に組み上げる

Footnotes

  1. 厳密なモデル数は週単位で増減する。本稿では公式 model-cards.html 掲載分を基準とする。 ↩

  2. 2026 年 6 月時点で Bedrock に出ている世代は Claude 4 系（Opus / Sonnet / Haiku）。具体的なマイナーバージョン（4.5 / 4.6 / 4.7 / 4.8 など）は流動的なため、本文では世代単位で扱う。最新は AWS 公式 model-cards を参照。 ↩

  3. ここでは Nova v1（2024 リリース）の構成を示す。2026 年 6 月時点で Nova 2 系（Lite / Sonic など）が別ユーザーガイドで提供開始されているが、詳細仕様は本書のスコープ外とする。最新は公式 docs を参照。 ↩

  4. 本シリーズでは Custom Model Import の詳細は扱わない。Llama 4 系の context window や価格は流動的なため、最新は公式 docs を参照のこと。 ↩

  5. CRIS の詳細は付録 A「マルチリージョン設計を Cross-Region Inference Profile で実装する」で扱う。 ↩