Bedrock Prompt Routerによりどれくらいコスト削減ができるのかを検証してみた

こんにちは。APでエンジニアインターンをしている鈴木鴻太です。

今回は、AWS Bedrock の Prompt Router を実装し、実際に複数のLLM を最適に振り分ける仕組みがどれだけのコスト削減を実現できるのかを、ベンチマーク結果を通じて検証してみました。

Bedrock Prompt Router とは？

概要

Bedrock Prompt Router は、ユーザーのクエリに基づいて複数の LLM の応答品質を自動予測し、最適なモデルを自動選択する仕組みです。これにより品質を維持しながらコストを削減できます。

AWS の公式ドキュメントはこちら：

• AWS Bedrock Prompt Router API Reference
• 詳細解説記事（AWS ブログ）

ルーティングの仕組み

興味深い点として、Prompt Router は LLM そのものではなく、AWS が独自に開発した機械学習モデル で動作しています。各プロンプトに対して、複数の候補モデルの仮想的なレスポンス品質を予測してくれます。

ざっくり言うと以下のようなイメージです：

品質指標 = f(プロンプト内容, モデル特性, 過去トレーニングデータ)

つまり、各プロンプトの複雑度やタスク種別を自動判定し、「このクエリなら安くて軽い Haiku で十分」「こっちは高品質の Sonnet が必要」という判断を予測スコアベースで行うわけです。

LLM におけるトークンとは？

コスト削減の話に入る前に、トークンという概念を整理しておきましょう。

トークンの定義

LLM が処理する最小単位がトークンです。

LLM は英語や日本語をそのまま処理するのではなく、機械語として処理しています。その最小単位を「トークン」と呼びます。

トークン化のざっくりした目安：

• 英語：1単語 ≈ 1トークン
• 日本語：1文字 ≈ 1トークン

2つの種類

LLM のトークン処理は大きく2つに分かれます：

1. 入力トークン ：ユーザーのクエリを処理するために必要
2. 出力トークン ：LLM が生成する応答に含まれる

トークン処理量が増えると、それだけ CPU や GPU の演算処理が必要になり、結果として コストが増加 します。

トークン化の体験

以下のページで、実際のテキストがどのようにトークン化されるかを体験できます：
OpenAI Tokenizer

LLM API の料金体系

LLM を API として利用する場合、多くの料金形態は 「リクエスト数」ではなく「トークン量」 で設定されていますが、トークンの概念を把握すると納得できるかと思います。そして品質を保ちながらコストを抑えることの重要性が、ここから見えてきます。

検証方針：何を測るのか？

「品質を維持しながらコストを削減できる」という Prompt Router の目的のうち、「コスト削減」 に焦点を当てます。品質は AWS が担保している前提で進めます。

今回検証しないこと

• Router を使用した時の 品質

今回検証すること

• コスト削減率

検証の全体像について

0:事前準備

TypeScript で構築し、以下の2つのモデルを用いる Prompt Router を作成しました：

• Claude 3.5 Sonnet v2（高品質・高コスト）
• Claude 3 Haiku（軽量・低コスト）

Router の作成は、AWS Bedrock コンソールから可能です。

作成後、以下のように CDK に組み込みます：

const promptRouterArn = new cdk.CfnParameter(this, 'PromptRouterArn', { type: 'String', description: 'Bedrock Prompt Router ARN', default: '作成したARNを貼り付ける'});

1:テストプロンプトの準備

100個のテストプロンプトを JSON 形式で用意しました。難易度別（easy, medium, hard）、カテゴリ別（general, customer_support, technical）に分散させています：

{"id": "001", "prompt": "今日は何曜日ですか", "category": "general", "difficulty": "easy"},{"id": "002", "prompt": "東京の天気は？", "category": "general", "difficulty": "easy"},{"id": "003", "prompt": "1+1は？", "category": "general", "difficulty": "easy"},... （略）

後半になるにつれ難易度が高くなるように設計しました。

2:メトリクスの計測

Lambda 関数内で、各プロンプトに対して以下を計測：

const result = {  id,
prompt: prompt.substring(0, 50),
category,
difficulty,
selectedModel: response.data.selectedModel,       // どのモデルが選ばれたか  
latency: response.data.metrics.latency,           // レスポンス時間（ms）  inputTokens: response.data.metrics.inputTokens,   // 入力トークン数  outputTokens: response.data.metrics.outputTokens, // 出力トークン数  totalTokens: response.data.metrics.totalTokens,   // 合計};

結果を JSON ファイルに出力：

{  "id": "001",  "prompt": "今日は何曜日ですか",  "category": "general",  "difficulty": "easy",  "selectedModel": "Haiku",  "latency": 556.494491,  "inputTokens": 32,  "outputTokens": 13,  "totalTokens": 45}... （略）

3:両ケースでの比較計算

ケース1：Router を使用
Haiku と Sonnet が自動振り分けされた結果

ケース2：Sonnet 固定
すべてのリクエストを Claude Sonnet で処理した場合

計算対象：

• 平均レイテンシ（ms）
• 入力トークン × 単価 + 出力トークン × 単価 = 総コスト

料金表：モデル別トークン単価

Claude 3.5 Sonnet

Claude 3 Haiku

4:ベンチマーク結果

100リクエストを処理した結果です。

Router 使用時（5%品質妥協）

✓ 001 [easy ] Haiku | Latency: 556ms | Tokens: 45 ✓ 002 [easy ] Haiku | Latency: 1766ms | Tokens: 185 ✓ 003 [easy ] Haiku | Latency: 585ms | Tokens: 38 ✓ 004 [easy ] Haiku | Latency: 2893ms | Tokens: 305 ✓ 005 [easy ] Haiku | Latency: 2623ms | Tokens: 278 ... （略）

集計結果

サマリー

・モデルの振り分け：Haiku 47件（47%） | Sonnet 53件（53%）
・応答速度：平均4,179ms（最速556ms〜最遅17,142ms）

タスクカテゴリ別：
├─一般: 35件 | 平均3,687ms | 平均コスト$0.0022
├─カスタマーサポート: 31件 | 平均3,870ms | 平均コスト$0.0027
└─技術系: 34件 | 平均4,966ms | 平均コスト$0.0035

タスク難易度別Haikuモデルの使用率
├─簡単: 35件 | 平均2,536ms | Haiku 69%
├─中級: 32件 | 平均4,992ms | Haiku 44%
└─困難: 33件 | 平均5,132ms | Haiku 27%

Sonnet 固定時（100%品質保証）

すべてのリクエストを Claude Sonnet 3.5 で処理した場合：

✓ 001 [easy ] Sonnet | Latency: 1913ms | Tokens: 102 ✓ 002 [easy ] Sonnet | Latency: 1935ms | Tokens: 101 ✓ 003 [easy ] Sonnet | Latency: 653ms | Tokens: 34 ... （中略）

サマリー

応答速度：平均4,516ms（最速653ms〜最遅17,405ms）

タスクカテゴリ別：
├─一般: 35件 | 平均3,977ms | 平均コスト$0.0031
├─カスタマーサポート: 31件 | 平均3,875ms | 平均コスト$0.0032
└─技術系: 34件 | 平均5,655ms | 平均コスト$0.0048

タスク難易度別：
├─簡単: 35件 | 平均2,966ms
├─中級: 32件 | 平均5,128ms
└─困難: 33件 | 平均5,567ms

上記から、Router は easy〜medium くらいのタスクをうまく Haikuモデル に逃がしつつ、全体のレイテンシとコストを抑えている一方でSonnet固定は常に安定した品質を出せるが、その分オーバースペックなケースでも高コスト・やや高レイテンシになるといった構図が、結果から読み取れました。詳しいコスト計算については下で行なっています。

考察：コスト・レイテンシの詳細分析

コスト計算

Router 使用時：

16,509 × $0.00000125 (Haiku 出力) + 16,997 × $0.000015 (Sonnet 出力) = $0.2807

Sonnet 固定時：

28,272 × $0.000015 (Sonnet 出力) = $0.4241

削減率

$0.4241 ÷ $0.2807 = 1.51倍 → コスト削減率：34% 低減

レイテンシ比較

Router の方が全体的に 7.5% 速い です。

これは Easy タスクで Haiku の利用率が高い（69%）ため、Haiku の高速性が効いているからだと思います。Haiku はモデルとして「軽い＝推論が早い」という特性を持ち、Easy 問題では Sonnet との品質差がほぼないため、この高速化が実現されています。

仮説:長期スコープでの削減額試算

自分は現在学生でエンジニアインターンとして働かせていただいているので、LLMのユースケースとしては、課題・日々の勉強・コーディング・その他諸々が考えられます。特に、コーディングエージェントのtool use系はトークン処理量が多いことを考えると、以下のようなシナリオが挙げられます。

• 1日：10万トークン消費
• 1ヶ月：300万トークン
• 1年：3600万トークン

入出力の比率を 1:1 と仮定（実際はプロンプトにより異なる）

Sonnet 固定の場合

月間コスト：150万 × $0.000015 + 150万 × $0.000003 = $27
年間コスト：$27 × 12 = $324

Router 使用時の場合

削減率：34% ⇒ $324 × 34% ≈ $110削減
年間実コスト：$324 - $110 = 約 $214

つまり、個人利用だけでも年間$110のコストが削減できます。

企業利用では、ユーザー数や従業員数 × 利用パターンが掛け算されるため、削減額はさらに膨らみます。例えば100人が同じシステムを利用すれば、年間約21400ドル（約350万円） の削減が可能になります。

結論

Router 導入のメリット

Router の方が、コストも応答速度も優位 です。

おわりに

今回の検証を通じて、AWS Bedrock の Prompt Router がいかに効果的なコスト削減手法であることが実感できました。

LLM API の利用が日常化する中、「品質を維持しながらコストを削減する」という課題に対して、このような ルーティング はこれからスタンダードになっていくと考えられます。

複数の LLM を使い分ける時代では単純にずっと性能が高いモデルを使うのではなく、「タスクに応じた最適なモデルを選択する」という戦略が重要になると思います。例えるなら現代は「燃費悪いガソリン車両で溢れかえっているが、まだ問題視されていない状況」であると思っていて、今後物理的資源の問題GPUなどが重要視されていくにつれ、このコスト削減問題はどんどん一般化していくと思っています。

Prompt Router は、その戦略を 自動化 し、かつ コスト削減と高速化 まで実現できるソリューション。ぜひ導入を検討してみてください。