Amazon Bedrock で agentic なチャットアプリを作る場合、最初に悩むのがモデル選定です。

この記事は、厳密な benchmark や eval ではありません。個人開発中の agentic chat アプリで Bedrock 上の複数モデルを触ったときの選定メモです。価格、対応機能、リージョンごとの挙動は変わるため、最終判断前には公式ドキュメントと自分の workload で再確認してください。

今回作っているのは、Slack から呼び出される serverless agent です。ユーザー発話を受け、必要に応じて memory、task、calendar、web extract、skill などの tool を呼びながら応答します。

つまり単純なチャットではありません。

user message
  -> model decides tool usage
  -> tool execution
  -> model observes result
  -> sometimes replans
  -> final Slack response

この構成では、モデル単価だけでなく、tool call の安定性、日本語 UX、再試行率、fallback 率、出力 token 量がかなり効きます。

結論から書くと、今回は Moonshot AI の Kimi K2.5 を main model として使う方針にしました。

Sonnet は高い

まず基準になるのは Claude Sonnet です。

Claude Sonnet 4.5 の API 価格は $3 / 1M input tokens、$15 / 1M output tokens です。Claude Haiku 4.5 は $1 / $5 なので、Sonnet は品質面では安心できる一方、出力 token が増えやすい agentic chat ではコストが重くなります。

agentic chat は、1ユーザー発話に対して複数回モデルを呼ぶことがあります。tool schema、tool result、会話履歴、system prompt も入りやすく、単純な Q&A より token cost が膨らみがちです。

そのため、最初から Sonnet はこういう位置づけにしました。

Claude Sonnet:
  失敗時の fallback
  高価値ユーザー向けの escalator
  難しい multi-step reasoning 用

main model には、Sonnet より安く、かつ軽量モデルより agentic な振る舞いが安定するものを探す必要がありました。

Haiku は安いが少し弱い

Claude Haiku 4.5 は価格面では魅力的です。さらに prompt caching が効く構成なら、巨大な system prompt や tool schema を繰り返し使うアプリではかなり安くなる可能性があります。

Bedrock の prompt caching は、対応モデルで繰り返し使う prompt prefix を cache checkpoint として扱い、input token cost と latency を下げる仕組みです。

ただ、今回のアプリでは Haiku は main としては少し弱い印象でした。

単純な分類、軽い抽出、短い要約には使えます。一方で、tool 選択、再計画、日本語での説明品質、複数ステップの安定性には不安がありました。

なので Haiku は main ではなく、補助モデルとして見るのが良さそうです。

Claude Haiku:
  routing
  短い分類
  軽い抽出
  first pass

MiniMax M2.5 は安くて agent 向き。ただし日本語 UX が惜しい

次にかなり有力だったのが MiniMax M2.5 です。

Bedrock のモデルカードでは、MiniMax M2.5 は agent-native frontier model と説明されています。効率的な reasoning、タスク分解、複雑な workflow、agentic scaffold での意思決定を意識したモデルです。Context window は 196K tokens、max output は 8K tokens です。

価格もかなり強いです。Bedrock Pricing の東京リージョンでは、MiniMax M2.5 は $0.36 / 1M input tokens、$1.44 / 1M output tokens です。

たとえば 1 LLM call あたり input 8k + output 1k とすると、1,000 calls の概算はこうなります。

モデル 東京リージョン価格 1,000 calls 概算
MiniMax M2.5 $0.36 input / $1.44 output 約 $4.32
Mistral Large 3 $0.61 input / $1.82 output 約 $6.70
Kimi K2.5 $0.72 input / $3.60 output 約 $9.36

価格だけ見ると MiniMax M2.5 はかなり魅力的です。Bedrock Runtime の Agents、Flows、Structured outputs などにも対応しています。

ただ、実際に触ると、日本語の自然さや customer-facing な会話 UX が少し合いませんでした。内部処理や planning には使えそうですが、Slack 上でユーザーに直接見せる main chat model としては不安が残りました。

MiniMax はコスパ最強候補ではありますが、今回は main から外しました。

Gemma は激安だが、main agent というより first pass 向き

Gemma 3 系も候補に入りました。

Bedrock の東京リージョン価格では、Gemma 3 27B が $0.28 / 1M input tokens、$0.46 / 1M output tokens、Gemma 3 12B が $0.11 / $0.35、Gemma 3 4B が $0.05 / $0.10 と非常に安いです。

この価格なら、分類、簡単な RAG 回答、短い要約、routing、first pass の回答生成には使いやすいです。

ただし、今回求めていたのは agentic chat の main model です。Haiku でも少し弱いと感じる用途だったので、Gemma を主役にするのは厳しいと判断しました。

Nemotron 3 Super 120B

途中で NVIDIA Nemotron 3 Super 120B も候補に入れました。

Bedrock のモデルカードでは、Nemotron 3 Super は 120B parameter の open hybrid MoE model で、12B parameters を active にする構成です。複雑な multi-agent applications 向けで、context window は 256K tokens、max output は 32K tokens です。

価格もかなり安く、東京リージョンでは $0.18 / 1M input tokens、$0.78 / 1M output tokens です。

価格も MiniMax よりさらに安い。スペックだけ見るとかなり良い候補でした。

ただし、今回の手元の確認では、東京リージョンの on-demand 呼び出しがかなり遅く、短い応答でも timeout するケースがありました。一方で us-east-1 では、最小応答や強制 tool call が約 2〜3 秒で返りました。

つまり、Nemotron そのものが遅いと言い切るより、リージョンやその時点の on-demand 経路の影響も大きそうです。

今回は東京リージョン前提の customer-facing chat なので、main model にはしませんでした。

Nemotron 3 Super:
  価格とスペックは強い
  tool use 自体は動く
  ただし ap-northeast-1 の実測 latency が不安

Mistral Large 3 は悪くない。だが決め手には欠けた

Mistral Large 3 もかなり現実的な候補でした。

Bedrock のモデルカードでは、Mistral Large 3 は 675B parameter model で、coding、reasoning、multilingual tasks に強いとされています。Context window は 256K tokens、max output は 32K tokens です。Bedrock Runtime では Agents、Flows、Structured outputs、Prompt caching 対応と表示されています。

価格は東京リージョンで $0.61 / 1M input tokens、$1.82 / 1M output tokens。Kimi K2.5 よりかなり安く、出力単価の差も大きいです。

実際に触った印象も悪くありませんでした。ただ、今回の agentic chat では Kimi K2.5 のほうが安定していました。

また、Mistral Large 3 は公式モデルカード上では prompt caching 対応と表示されていますが、手元の構成で cachePoint を付けて試すと Bedrock 側から拒否されるケースがありました。

Mistral はコストと性能のバランスが良いですが、今回は Kimi K2.5 を上に置きました。

最終的に Kimi K2.5

最終的には moonshotai.kimi-k2.5 を main model として使うことにしました。

理由はシンプルで、今回試した中では agentic chat と日本語 UX の安定感が一番良かったからです。

Bedrock の Kimi K2.5 モデルカードでは、Kimi K2.5 は improved reasoning、coding、multilingual capabilities を持つ multimodal model と説明されています。Context window は 256K tokens、max output は 16K tokens、画像入力にも対応しています。

Bedrock Runtime では Response streaming、Guardrails、Prompt management、Flows、Agents、Structured outputs に対応しています。

価格は東京リージョンで $0.72 / 1M input tokens、$3.60 / 1M output tokens です。MiniMax や Mistral より高いですが、Sonnet よりはかなり安い。

モデル選定では、単価だけでなく失敗率も重要です。

安いモデルを使っても、tool 選択ミス、JSON 崩れ、再試行、Sonnet fallback が増えると、結局トータルコストは高くなります。agentic chat では特に、モデルが一度判断を間違えると、その後の tool call や再計画全体に影響します。

その意味で、Kimi K2.5 は「最安ではないが、main model としての安定感がある」という評価になりました。

Bedrock の Kimi K2.5 に prompt cache なし

Kimi K2.5 に固定するうえで惜しいのが prompt caching です。

Bedrock の Kimi K2.5 モデルカードを見る限り、対応機能として Agents、Flows、Structured outputs などは載っていますが、Prompt caching は載っていません。

Bedrock の prompt caching ドキュメントでは、対応モデルごとに最低 token 数、最大 checkpoint 数、system / messages / tools のどこに cache checkpoint を置けるかが明示されます。Claude 系や一部モデルはこの表に載っていますが、Kimi K2.5 を Bedrock 上で prompt cache 前提にする材料は現時点では弱いです。

一方で、Moonshot の直接 API 側では Kimi K2.5 に cache hit 料金が表示されています。

ただし、これは Moonshot 直接 API の話です。Bedrock 経由で同じキャッシュ仕様や料金が使えるわけではありません。

コスト削減は payload slimming と Flex tier で詰める

Kimi K2.5 を main にすると、次の課題はコストです。

東京リージョン価格は $0.72 input / $3.60 output なので、特に output token が効きます。

まず効かせるべきなのは payload slimming です。

具体的には、モデルに渡す system prompt、tool schema、tool result、会話履歴、RAG 抜粋を必要最小限にすることです。agentic chat では、tool schema と tool result が input token を膨らませやすく、さらに最終応答が長くなると output token のコストも効いてきます。

- maxTokens を用途別に絞る
- agent の中間 reasoning を長く出さない
- tool result をそのまま全部渡さず、必要なフィールドだけ渡す
- 全 tool schema を常時投入せず、候補 tool だけ渡す
- 同一 FAQ / 同一検索結果 / 同一 tool result はアプリ側で cache する

このあたりはモデル選定とは別に、どのモデルを使っても効く基本的なコスト対策です。

そのうえで、今回は Flex tier も試すことにしました。

Amazon Bedrock には Standard、Flex、Priority、Reserved などの service tier があります。Flex tier は、処理時間に余裕がある workload 向けの低コスト tier です。AWS のドキュメントでは、model evaluations、content summarization、agentic workflows のような用途例が挙げられています。

Bedrock pricing では、Moonshot AI の Flex tier は Standard から 50% discount とされています。つまり東京リージョンの Kimi K2.5 は、ざっくり次のように見られます。

Kimi K2.5 Tokyo input / 1M output / 1M
Standard $0.72 $3.60
Flex 約 $0.36 約 $1.80

1 LLM call あたり input 8k + output 1k の例では、1,000 calls あたり Standard が約 $9.36、Flex が約 $4.68 です。

Flex は低コストな代わりに、latency や availability の面で Standard より読みづらくなる可能性があります。なので当初は、ユーザーが待っている対話本体は Standard のままにし、内部処理や非同期処理、評価、長めの要約、再処理のような待てる workload から Flex を試すつもりでした。

ただ、実際に Kimi K2.5 を Flex で軽く呼んでみると、少なくとも短い direct invoke や Slack 経由の軽い確認では、体感としては思ったほど遅くありませんでした。もちろん、これは厳密な latency benchmark ではありません。混雑時や長い tool loop、長文出力では挙動が変わる可能性があります。

それでも、個人利用や小規模な serverless agent なら、まず main 応答も Flex で試してみて、厳しければ Standard に戻す、という進め方は現実的だと感じました。

今回の main 応答:
  moonshotai.kimi-k2.5 / Flex

非同期処理・内部要約・評価・コスト重視処理:
  moonshotai.kimi-k2.5 / Flex

失敗時・高価値ユーザー・複雑 reasoning:
  Claude Sonnet fallback

軽い分類・tool候補選択・短い抽出:
  安い helper model

中国系モデルへのセキュリティ懸念はどう説明するか

Kimi K2.5 や MiniMax M2.5 のような中国系モデルを使う場合、社内で懸念が出ることがあります。

このとき重要なのは、「中国系モデルだから安全です」と説得することではありません。そうではなく、直接 API に送る場合と、Amazon Bedrock 経由で使う場合を分けて説明することです。

Amazon Bedrock の data protection ドキュメントでは、モデルプロバイダーは Bedrock のログや customer prompts / completions にアクセスできないと説明されています。

つまり Bedrock 経由で使う場合は、Moonshot や MiniMax の API に直接プロンプトを送る構成とはリスクの性質が違います。

説明としては、こう整理すると通しやすいです。

中国系モデルの直接 API を使うのではなく、Amazon Bedrock のマネージド環境で実行する。

Bedrock 経由では、モデルプロバイダーに顧客プロンプトや completion が共有される構成ではない。

したがって主な管理対象は、モデル提供企業へのデータ送信ではなく、AWS アカウント内の IAM、ログ、Guardrails、RAG アクセス制御、tool call 制御である。

最終構成

今回の結論はこうです。

main model:
  moonshotai.kimi-k2.5

interactive tier:
  Flex を試用中
  latency が厳しければ Standard に戻す

cost-sensitive tier:
  Flex

fallback:
  Claude Sonnet

helper models:
  MiniMax / Gemma / Nemotron などを用途限定で利用

モデルごとの役割は以下のように整理しました。

モデル 評価 採用判断
Claude Sonnet 品質はいいが高い fallback / escalator
Claude Haiku 安いが少し弱い routing / 抽出 / 短い処理
MiniMax M2.5 安い、agent 向き 日本語が微妙なので main は見送り
Gemma 3 激安 first pass / 軽い分類向け
Nemotron 3 Super 安い、非中国系、tool use 可能 東京リージョンの latency が不安
Mistral Large 3 バランス良い 悪くないが Kimi より安定感で劣る
Kimi K2.5 日本語 UX と tool use の安定感が良い main model

まとめ

最初は「Sonnet は高いので、もっと安い main model がほしい」というところから始まりました。

MiniMax M2.5 はかなり安く、agent 向けという意味でも魅力的でした。しかし、日本語の customer-facing UX が少し合いませんでした。

Mistral Large 3 はかなり良いバランスでしたが、最終的には Kimi K2.5 のほうが安定していました。

Nemotron 3 Super 120B は価格とスペックだけ見ると非常に面白い候補でしたが、東京リージョン前提では latency に不安がありました。

Haiku は cache が効く構成ならコスト面で強いものの、今回の main agent には少し弱い。

その結果、今回は Kimi K2.5 を main に固定し、Sonnet を fallback、Flex tier と payload slimming でコストを詰めるという構成にしました。

今回の用途では、Kimi K2.5 は最安ではありませんが、失敗率と UX を含めた実効コストでは一番納得感がある、という結論になりました。

今後は、もう少し eval を整えながらモデル選定を続けるつもりです。代表的な 会話、tool call、scheduled reminder、web extract、skill 作成のようなケースを小さな test set にして、latency、tool call 成功率、retry 率、日本語 UX、token cost を見ていく。モデル候補を増やし続けるというより、用途ごとに「これは残す」「これは外す」を決めながら、運用しやすい形に剪定していきたいです。

参考リンク

この記事は Zenn にも転載しています。