👀 概要
パーソルホールディングス エンジニアリング部 Technical Alliance 室の武田です。
音声対話 AI プロダクトの月額コスト試算について、全 3 回に分けてご紹介します。
今回は、シリーズの第 3 回として、RAG(Azure AI Search) の Search Unit・Embedding の積み上げ方と、STT・TTS・LLM・RAG の合算について記載します。
👨👩👧👦 対象者(Who)
- 音声対話 AI を構成する各サービスのコスト体系について理解したい方
📌 関連リンク
- Azure AI Search の価格
- Azure AI Search の信頼性
- Azure AI 検索で価格モデルとサービス レベルを選択する
- 検索サービスの容量を見積もって管理する
- Azure OpenAI Service の価格
🗒️ 目次
- 本シリーズについて
- はじめに
- 本記事の前提
- 利用条件
- RAG コスト試算
- Azure AI Search 課金体系
- Search Unit とは
- Embedding とは
- Search Unit コスト試算
- インデックス検索負荷試算
- インデックス更新負荷試算
- インデックス登録データ量試算
- SKU 選定
- Search Unit 構成検討
- Search Unit コスト合計
- Embedding コスト試算
- インデックス登録トークン数
- インデックス検索トークン数
- インデックス更新トークン数
- Embedding コスト合計
- RAG コスト合計
- Azure AI Search 課金体系
- 音声対話 AI コスト合計
- まとめ
- おわりに
📝 内容
本シリーズについて
本記事は、音声対話 AI の月額コストを STT、TTS、LLM、RAG に分解して試算する全 3 回シリーズの第 3 回です。
利用条件の定義は 第 1 回 にあります。
本記事では、RAG の計算に必要な条件だけを再掲し、これまでの回の小計を引用して全体を合算します。
はじめに
第 1 回 では共通の利用条件を定義し、STT・TTS のコストを、第 2 回 では LLM のコストを求めました。
第 3 回では、RAG のコストを求めたうえで、合算します。
RAG は検索基盤の固定費用と Embedding の従量費用が混在します。
本記事では Azure AI Search を前提に、Search Unit と Embedding を分けて積み上げ、音声対話 AI プロダクトの月額コストを求めます。
本記事の前提
本シリーズの前提サービスは 第 1 回 と同じです。
本記事の試算対象は RAG(Azure AI Search および Embedding)と、合計コストです。
| 項目 | 値 |
|---|---|
| RAG | Azure AI Search(Japan East) |
| Embedding | Azure OpenAI Service(text-embedding-3-small) |
| 通貨 | 米ドル |
| 料金調査日 | 2026年9月16日 |
| 本記事の試算対象 | RAG、合計コスト |
本記事(第 3 回)で記載しない範囲は、以下です。
利用条件
利用条件の定義は 第 1 回 にあります。
以下は、本記事の計算で直接使う条件の再掲です。
| 項目 | 値 |
|---|---|
| 月間利用(会話)数 | 2,000 回 |
| 営業日数 | 20 日 |
| 稼働時間 | 12 時間 |
| 会話ターン数 | 16 ターン |
| ユーザー平均発話トークン数 | 60 トークン |
| RAG 発動率 | 30 % |
| RAG 取得件数 | 上位 5 件 |
| チャンクサイズ | 500 トークン |
| 要約トークン数 | 300 トークン |
また、合算では 第 1 回、第 2 回 の小計を次のとおり引用します(詳細な導出は各回を参照)。
| 回 | 項目 | 小計 |
|---|---|---|
| 第 1 回 | STT・TTS | $210.13/月 |
| 第 2 回 | LLM | $135.84/月 |
RAG コスト試算
RAG については、どのサービスを使うかによって課金体系が異なるため、本シリーズでは Azure AI Search を使う前提で記載します。
Azure AI Search 課金体系
Azure AI Search を使うに当たり、主に以下の料金が発生します。
(その他にもネットワーク転送や Private Link、Semantic Ranker などの課金要素があったり、サーバーレスを使うという選択肢もあったりしますが、プロジェクトに大きく依存するため本記事では割愛します。)
- Search Unit
- Embedding
Search Unit とは
Search Unit は Azure AI Search においてサービスを利用する際のリソース、課金の基本単位で、SKU(Stock Keeping Unit)によって料金が異なります。
各 SKU の CPU コア数やメモリサイズは公開されていませんが、高性能であるほど料金が高くなります。
また、Search Unit はパーティション数およびレプリカ数のかけ合わせによって決まります。
Search Unit = パーティション数 × レプリカ数
レプリカは検索エンジンのコピーで、追加することによりクエリを同時に処理できる数が増え、スループットが向上することに加え、可用性も上がります。
パーティションはデータを分割して格納するストレージの単位で、追加することにより保存容量が増え、インデックスへのデータ登録やデータ更新を並行して処理できるため性能が向上します。
Embedding とは
Embedding(埋め込み表現)は、テキストや画像などのデータを数値ベクトルに変換する技術です。
今回は主に以下の処理で Embedding を利用すると仮定します。
- インデックス登録:各種ドキュメントからテキスト情報を取得し、数値ベクトルに変換して、RAG に数値ベクトルを投入する
- インデックス更新:会話終了後、会話内容の要約テキストを数値ベクトルに変換して、RAG に数値ベクトルを投入する
- インデックス検索:検索クエリを数値ベクトルに変換し、RAG に対してベクトル検索をする
コストについてですが、Embedding で利用するモデルの料金は Azure AI Search の料金には含まれません。
Search Unit コスト試算
まず、どの SKU を採用するか決めます。
各 SKU の CPU コア数やメモリサイズが公開されていないため、どれくらいの負荷がかかるかを試算したうえで、SKU を選定します。
インデックス検索負荷試算
RAG への検索負荷を確認します。
月間利用(会話)数を 2,000 回、1 会話当たりのターン数を 16 ターン、RAG 発動率を 30 % としているため、月当たりの検索回数は 9,600 回となります。
検索回数
= 月間利用(会話)数 × 会話ターン数 × RAG 発動率
= 2,000 × 16 × 0.30
= 9,600 回/月
営業日数を 20 日、稼働時間を 12 時間としているため、1 分当たりの検索回数は 0.67 回となり、今回のケースでは検索負荷が高くないことがわかりました。
| 項目 | 値 |
|---|---|
| 月間利用(会話)数 | 2,000 回 |
| 会話ターン数 | 16 ターン |
| RAG 発動率 | 30 % |
| 検索回数(月) | 9,600 回/月 |
| 検索回数(日) | 480 回/日 |
| 検索回数(時) | 40 回/時 |
| 検索回数(分) | 0.67 回/分 |
インデックス更新負荷試算
RAG への更新負荷を確認します。
本記事では、会話終了後に長期記憶として、会話内容の要約を RAG に投入するとします。
月間利用(会話)数を 2,000 回としているため、月当たりの更新回数も 2,000 回となります。
営業日数を 20 日、稼働時間を 12 時間としているため、1 分当たりの更新回数は 0.14 回となり、今回のケースでは更新負荷も高くないことがわかりました。
| 項目 | 値 |
|---|---|
| 月間利用(会話)数 | 2,000 回 |
| 更新回数(月) | 2,000 回/月 |
| 更新回数(日) | 100 回/日 |
| 更新回数(時) | 8.3 回/時 |
| 更新回数(分) | 0.14 回/分 |
インデックス登録データ量試算
RAG に投入するデータ量を確認します。
データとしては、ベクトルデータ、本文データ、メタデータが挙げられます。
まず、どれくらいのファイルを RAG に投入するかを決めます。
今回は、ファイル数 1,000、各ファイル 20 ページ、各ページ 1,000 文字とします。
合計ページ数は 20,000 ページとなります。
また、チャンクサイズ 500 トークン、オーバーラップ 20 % とすると、1 チャンク当たり 400 トークンずつとなり、1 ページ 1,500 トークンは約 4 チャンクとなります。
合計チャンク数は 80,000 チャンクとなります。
合計チャンク数
= 合計ページ数 × 1 ページ当たりのチャンク数
= 20,000 × 4
= 80,000 チャンク
| 項目 | 値 |
|---|---|
| ファイル数 | 1,000 ファイル |
| ページ数 | 20 ページ/ファイル |
| 合計ページ数 | 20,000 ページ |
| 文字数 | 1,000 文字/ページ |
| 日本語 1 文字のトークン数 | 1.5 トークン |
| 1 ページのトークン数 | 1,500 トークン/ページ |
| チャンクサイズ | 500 トークン |
| オーバーラップ | 20 % |
| チャンク数 | 4 チャンク/ページ |
| 合計チャンク数 | 80,000 チャンク |
投入するデータの合計チャンク数がわかったので、ベクトルデータにした場合のデータ量を試算します。
Embedding で使うモデルを text-embedding-3-small、1,536 次元とすると、1 次元当たりのサイズは Float 32 の 4 B で、ベクトルのデータサイズは 6 KB となります。
ベクトルサイズ
= 次元数 × 1 次元当たりのサイズ
= 1,536 × 4
= 6 KB
よって、RAG に投入するデータのベクトルデータ量は 480 MB となります。
ベクトルデータ量
= 合計チャンク数 × ベクトルサイズ
= 80,000 × 6
= 480 MB
次に本文のデータ量を試算します。
チャンク当たりの本文のデータサイズを求めます。
チャンク当たりの本文データサイズ
= チャンクサイズ [トークン] / 日本語 1 文字のトークン数 [トークン/文字] × 日本語 1 文字のサイズ [B]
= 500 / 1.5 × 3
= 1 KB
よって、本文データ量は 80 MB となります。
本文データ量
= 合計チャンク数 × 本文データサイズ
= 80,000 × 1
= 80 MB
ファイル名や閲覧範囲などの付加情報、メタデータを仮に 10 MB とすると、合計データ量は 570 MB となり、1 GB 未満とデータ量としてもそこまで多くないことがわかりました。
(試算した数値はローデータのデータ量で、実際のインデックスサイズではなく、概算値となります。)
合計データ量
= ベクトルデータ量 + 本文データ量 + メタデータ量
= 480 + 80 + 10
= 570 MB
| 項目 | 値 |
|---|---|
| Embedding モデル | text-embedding-3-small |
| 次元 | 1,536 |
| 1 次元当たりのサイズ | 4 B |
| ベクトルサイズ | 6 KB |
| 合計チャンク数 | 80,000 チャンク |
| ベクトルデータ量 | 480 MB |
| UTF-8 | 3 B |
| 本文サイズ | 1 KB |
| 本文データ量 | 80 MB |
| メタデータ量 | 10 MB |
| 合計データ量 | 570 MB |
SKU 選定
Azure AI Search では SKU が Free、Basic、S1、S2 ... の順にスペックおよび単価が上がっていきます。
Free は主に開発や検証向けで、ストレージが小さい、SLA がない、スケールアウトに対応していないなど、本番環境への利用に適さないため、今回は選択肢から外します。
Basic は小規模な本番環境向け、S1 は一般的な本番環境向け、S2 以降は大規模な本番環境向けとなります。
試算結果より、検索負荷が高くなく、RAG に投入するデータ量もそこまで多くないことから、本記事では Basic とします。
(実際に SKU を選定する際は、ユースケースに基づき、実データで検証したうえで選定することを推奨します。)
Search Unit 構成検討
パーティション数については、更新負荷が高くないことから、複数作成せず、1 とします。
レプリカ数については、検索負荷が高くなく、RAG に投入するデータ量もそこまで多くありませんが、本記事では、読取について 99.9 % の SLA を求めるとし、今回は 2 とします。
(書込についても 99.9 % の SLA を求める場合はレプリカ数が 3 以上必要となります。)
AI Search では、可用性 SLA は次の検索サービスに適用されます。
・請求可能なサービス レベルを使用するように構成されます。
・読み取り専用ワークロード (クエリ) 用に少なくとも 2 つの レプリカがあります。
・読み取り/書き込みワークロード (クエリとインデックス作成) 用に少なくとも 3 つのレプリカがあります。
https://learn.microsoft.com/ja-jp/azure/reliability/reliability-ai-search#service-level-agreement
Search Unit はレプリカ数とパーティション数より 2 となりました。
Search Unit
= パーティション数 × レプリカ数
= 1 × 2
= 2
Search Unit コスト合計
SKU を Basic、パーティション数を 1、レプリカ数を 2、Search Unit を 2 とした場合の Search Unit コスト合計は $194.18/月 となりました。
| 項目 | 値 |
|---|---|
| SKU | Basic |
| パーティション数 | 1 |
| レプリカ数 | 2 |
| Search Unit | 2 SU |
| Search Unit 単価 | $97.09/月 |
| Search Unit コスト合計 | $194.18/月 |
Dedicated pricing
Free Basic Standard S1 Standard S2
\$0/月 \$97.09/月 \$324.12/月 $1,295.02/月
https://azure.microsoft.com/ja-jp/pricing/details/search/
Embedding コスト試算
以下の各処理のトークン数を計算し、Embedding の合計コストを試算します。
- インデックス登録:各種形式のドキュメントからテキスト情報を取得し、数値ベクトルに変換して、RAG に数値ベクトルを投入する
- インデックス更新:会話内容の要約などのテキスト情報を数値ベクトルに変換して、RAG に数値ベクトルを投入する
- インデックス検索:検索クエリを数値ベクトルに変換し、RAG に対してベクトル検索をする
インデックス登録は初回のみの費用、インデックス更新とインデックス検索は毎月かかる費用となります。
インデックス登録トークン数
インデックスに登録するベクトルデータの合計トークン数を確認します。
インデックスに登録するデータ量(合計チャンク数)については計算済みのため、合計トークン数を試算します。
合計トークン数
= 合計チャンク数 × チャンクサイズ
= 80,000 × 500
= 40,000,000 トークン
| 項目 | 値 |
|---|---|
| ファイル数 | 1,000 ファイル |
| ページ数 | 20 ページ/ファイル |
| 合計ページ数 | 20,000 ページ |
| 文字数 | 1,000 文字/ページ |
| 日本語 1 文字のトークン数 | 1.5 トークン |
| 1 ページのトークン数 | 1,500 トークン/ページ |
| チャンクサイズ | 500 トークン |
| オーバーラップ | 20 % |
| チャンク数 | 4 チャンク/ページ |
| 合計チャンク数 | 80,000 チャンク |
| 合計トークン数 | 4,000万 トークン |
インデックス検索トークン数
インデックスを検索するクエリのベクトルデータの合計トークン数を試算します。
合計トークン数
= 検索回数 × ユーザー発話トークン数
= 9,600 × 60
= 576,000 トークン
| 項目 | 値 |
|---|---|
| 検索回数(月) | 9,600 回 |
| ユーザー発話文字数 | 40 文字/発話 |
| ユーザー発話トークン数 | 60 トークン/発話 |
| 合計トークン数 | 57.6万 トークン |
インデックス更新トークン数
インデックスを更新するベクトルデータの合計トークン数を確認します。
本記事では、会話終了後に長期記憶として、会話内容の要約を RAG に投入するとします。
要約トークン数を 300 トークンとすると、合計トークン数は 60万 トークンとなりました。
合計トークン数
= 更新回数(月) × 要約トークン数
= 2,000 × 300
= 600,000 トークン
| 項目 | 値 |
|---|---|
| 月間利用(会話)数 | 2,000 回 |
| 更新回数(月) | 2,000 回/月 |
| 合計トークン数 | 60万 トークン |
Embedding コスト合計
インデックス登録トークン数、インデックス検索トークン数、インデックス更新トークン数がわかったので、初回費用および月額費用を試算します。
初回費用
= インデックス登録トークン数 × Embedding モデル単価
= 40,000 kトークン × $0.000025/kトークン
= $1.00
月額費用
= (インデックス検索トークン数 + インデックス更新トークン数) × Embedding モデル単価
= (576 kトークン + 600 kトークン) × $0.000025/kトークン
= $0.0294/月
| 項目 | 値 |
|---|---|
| インデックス登録トークン数 | 4,000万 トークン |
| インデックス検索トークン数 | 57.6万 トークン |
| インデックス更新トークン数 | 60万 トークン |
| Embedding モデル | text-embedding-3-small |
| Embedding モデル単価 | $0.000025/kトークン |
| 初回費用 | $1.0000 |
| 月額費用 | $0.0294/月 |
Embedding models
Models Per 1,000 tokens
text-embedding-3-small $0.000025
https://azure.microsoft.com/ja-jp/pricing/details/azure-openai/
RAG コスト合計
Search Unit、Embedding のコスト試算結果より、RAG のコストは約 $194/月 であることがわかりました。
(Embedding の初回費用は月額費用からは除いています。)
試算結果より、Search Unit のコストが支配的で、Azure AI Search では、どの SKU を採用するか、レプリカ数およびパーティション数をどうするかがコストを左右すると言えそうです。
| 項目 | 値 |
|---|---|
| Search Unit | $194.18/月 |
| Embedding | $0.03/月 |
| 合計 | $194.21/月 |
音声対話 AI コスト合計
第 1 回 の STT・TTS、第 2 回 の LLM、本記事の RAG を合算すると、今回のケースにおける音声対話 AI のコストは約 $540/月 です。
$210.13/月 + $135.84/月 + $194.21/月 = $540.18/月
| 項目 | 値 |
|---|---|
| STT・TTS | $210.13/月 |
| LLM | $135.84/月 |
| RAG | $194.21/月 |
| 合計 | $540.18/月 |
Embedding の初回費用 $1.00 は月額合計には含めていません。
まとめ
音声対話 AI のコストは、会話時間だけでは見積もれません。
STT、TTS、LLM、RAG で課金単位が異なるため、共通の利用条件を決めてから、各サービスの利用量を積み上げていく必要があります。
本シリーズで試算するときのポイントは、次のとおりです。
- STT
- ユーザーがどれくらいの時間発話するのかを整理する
- TTS
- AI が 1 会話でどれだけの文字を発話するのかを整理する
- LLM
- どのような処理を、何回実行するのかを整理する
- 各処理にどのモデルを割り当てるのかを整理する
- 各処理でどのような情報を入力し、どのような出力が得られるのかを整理する
- RAG
- 検索負荷、更新負荷、データ量を整理し、必要なスペックを見積もる
今回のケースでは、STT・TTS が約 $210/月、LLM が約 $135/月、RAG が約 $194/月 となり、3 つのサービスがおおむね同じ規模になりました。
内訳を見ると、LLM では回答生成が、RAG では Search Unit が費用の大半を占め、Embedding の費用は約 $0.03/月 と全体の中でごくわずかに収まりました。
なかでも LLM は、試算の精度を上げたり費用を抑えたりする余地が大きい要素です。
次のような設計判断がコストに直接効いてきます。
- 会話履歴を全件渡さず、直近 n 件に絞る、または要約して圧縮する
- プロンプトキャッシュを利用し、システムプロンプトの入力トークンを減らす
- 出力検証後の再生成や、障害時のリトライの発生を見込む
また、RAG(Azure AI Search)では、SKU や レプリカ数、パーティション数が費用を左右します。
おわりに
本シリーズでは、音声対話 AI プロダクトを例に、STT、TTS、LLM、RAG の月額コストを、共通の利用条件から積み上げる手順を紹介しました。
コスト試算は一見複雑に見えますが、課金単位ごとに分解すれば、一つずつ見積もることができます。
試算を進める過程で、どのユースケースで、どのサービスが、どれだけ使われるのかが具体的になります。
その結果、費用の見積もりだけでなく、どこを設計で工夫すれば費用を抑えられるのかも見えてきます。
このシリーズが、音声対話 AI のコスト試算に取り組む一助になれば幸いです。