源内AIを1週間運用した実測コスト——2,187回のAPI呼び出しで$2.24だった

「源内、コスト試算では月$10〜40って言ってたけど、実際どうなの？」

前回の記事では、源内（GENAI）をAWSで動かした場合の月額コストを、公式の料金表をもとに構成別で試算しました。ただ、試算はあくまで試算です。実際にAWSの請求書を見た人の話のほうが、当然ながら信頼できます。

この記事では、実際にPoC環境として運用している源内のAWS環境を対象に、CloudTrailとCost Explorerで実測しました。知りたかったのは「本当に何回APIが呼ばれて、実際にいくらかかったのか」です。あわせて、この実測値をもとに、より現実的な本番規模（データ1GB・利用者100人という仮定）まで試算を延ばしています。

この記事でわかること

• CloudTrailを使って、Bedrockの実際の呼び出し回数と呼び出し元を特定する方法
• 源内のRAG構成（S3 Vectors + Bedrock）を1週間運用した実測コストと内訳
• 実測コストを月換算した場合、前回の試算とどれだけ近かったか
• 実測値をもとにした、100人規模で使った場合の本番コスト試算

前提知識

• 源内（genai-web）をAWSにCDKでデプロイする手順とハマりやすい注意点 で、基本的なデプロイ構成を確認しておいてください
• 源内をAWSで動かすといくらかかるか——構成別コスト試算 が、この記事の「試算」パートにあたります。実測との比較対象として先に読んでおくと理解が早いです

実測の前提条件（先に断っておきます）

実測結果を見る前に、この数字がどんな条件で取れたものかを明確にしておきます。ここを飛ばすと、数字だけが独り歩きしてしまうので（実際、コスト系の記事でよくある事故です）。

• 稼働期間: フルスタック（認証・Web・Guardrail含む）が揃ったのは2026年7月上旬で、この記事の執筆時点（7月10日）まで約1週間
• 利用者: 動作確認をしている社内関係メンバー2名のみ。一般ユーザーへの公開はまだしていません
• データ規模: 税務分野の法令テキストのみ、246ファイル・約251KB

つまりこれは「本番運用の月間コスト」ではなく、「ごく小規模なPoCを1週間動かした実測サンプル」です。この実測から得られる一番の価値は、月額の絶対額そのものよりも、「1リクエストあたりの実コスト単価」を後段の試算に使えることです。

どうやって実測したか（Cost Explorerだけでは足りない）

最初にCost Explorerで期間中のコストを確認すると、Bedrock関連で合計金額は出てきます。ただ、この金額だけでは「1回あたりいくらか」も「本当にアプリ経由の呼び出しなのか」も分かりません。

金額を回数で割ろうにも、そもそも正確な回数が分からないと意味のある単価が出せないということです。開発中に手動でテストした分まで一緒くたに数えてしまうと、実際のアプリ利用より高い単価が出てしまいます。

そこで、金額を見る前に「回数」を先に押さえることにしました。使ったのはCloudTrailです。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=Converse \
  --max-results 50

CloudTrailのイベントには userIdentity.arn が記録されており、どのIAMロールがBedrockを呼び出したのかが分かります。これが実測でいちばん役に立ったポイントです。

たとえば RagLambdaFunctionServiceRole を含むarnであれば、それはRAG Lambda本体からの呼び出し、つまりアプリ経由の生成リクエストです。一方、人間のIAMユーザー名がそのまま出てくる場合は、コンソールやCLIからの手動テストであり、アプリの実利用とは区別する必要があります。

この切り分けをせずに「Bedrockの呼び出し回数」を集計すると、開発中の手動確認まで含めて水増しした数字になってしまいます。実際、今回の集計でも呼び出し元ロール名が新旧2種類混在していました。開発途中でスタック名を変更した経緯があるためで、リネーム前の古いスタックからの呼び出しは実測対象から除外しました（過去の自分の判断のツケを、未来の自分が払う羽目になります）。

呼び出し元を正確に切り分けたところで、実際の集計結果を見ていきます。

実測結果①　生成・検索の呼び出し回数と実測コスト

現行スタック（myapp-*）からの呼び出しだけをCloudTrailで数えた結果が以下です（検索・埋め込みに使われているのはAmazon Titan Text Embeddings V2で、以下では略してTitan Embedと表記します）。

項目	回数	呼び出し元
生成呼び出し（Converse: Haiku/Sonnet）	315回	RAG Lambda実行ロール
検索・埋め込み呼び出し（Titan Embed）	1,872回	Bedrock Knowledge Base実行ロール
手動テスト（ConverseStream）	4回	人間のIAMユーザー（集計対象外）

生成1回あたり、平均で検索が約6回走っている計算になります（1,872 ÷ 315 ≈ 5.9）。これは、クエリ拡張で1つの質問を複数のサブクエリに分解し、それぞれをTitan Embedで埋め込んでからKnowledge Baseを検索する構成に合致する数字です。源内のRAGパイプラインの設計通りと言えます。

各呼び出しの平均トークン数も、CloudTrailの additionalEventData から取得できました。

モデル	平均入力トークン	平均出力トークン
Claude Haiku 4.5	約3,161	約331
Claude Sonnet 4.6	約953	約282
Titan Embed v2	約28	—

Haikuのほうが入力トークンが多いのは、クエリ拡張や関連性評価のように、検索結果を丸ごとコンテキストに詰め込んで判定させる軽量タスクに使われているためだと考えられます。一方Sonnetは、最終的な回答生成という、入力は絞りつつ出力の質を重視するタスクに使われています。

肝心の実測コストですが、Cost Explorerで確認した期間中（2026年7月1日〜11日）のBedrock関連コストの合計は $2.24 でした。内訳はClaude Haiku 4.5が$1.06、Claude Sonnet 4.6が$1.17、Titan Embedなど検索まわりが$0.02です。

呼び出し回数はHaikuの方が多い（167回 vs 148回）のに、金額はSonnetの方がやや高くなっています。1回あたりの出力トークン単価の違いが効いている形です。この内訳を、後段の試算でそのまま使います。

呼び出し回数が分かったところで、もう一つの実測ポイント、実際のデータ容量を見ていきます。

実測結果②　ナレッジベースの実データ容量

コストと同じくらい気になるのが、実際にどれだけのデータ量でこの構成が成立しているかです。S3を直接確認しました。

aws s3 ls s3://myapp-storage-databucketXXXXXXXX --recursive --summarize

元データ（相続税法の条文テキスト）は246ファイル、合計257,400バイト（約251KB）でした。この元データが、S3 Vectorsのインデックスにどれだけのベクトル数として格納されているかも、aws s3vectors list-vectors で確認できます。

aws s3vectors list-vectors \
  --vector-bucket-name myapp-tax-s3v-bucket \
  --index-name myapp-tax-s3v-index

結果は460ベクトル、1024次元のfloat32でした。単純計算で1ベクトルあたり4KB（1024×4バイト）なので、ベクトル本体のデータ量は約1.84MBです。元データ251KBに対してベクトルデータが1.84MBと、ベクトル化によってデータ量が7倍程度に膨らんでいることになります（埋め込みベクトルはテキストより情報密度が低いぶん、サイズが大きくなるのは想定通りです）。

関連記事 源内AIのコードをGitHubから読む——genai-webとgenai-ai-apiのAWS構成 genai-webとgenai-ai-apiの役割分担、S3 Vectorsを採用した構成の詳細を解説しています。

これでコスト・回数・データ容量の3点セットが揃いました。次に、これらを前回の試算記事と突き合わせてみます。

前回の試算との答え合わせ

前回の試算記事では、ベクトルストアにOpenSearch Serverless（月$345〜）ではなくS3 Vectorsを採用することで、月$1未満に抑えられるという試算を示しました。

今回の実測では、S3 Vectors自体のストレージ量が1.84MBというごく小さな規模だったこともあり、ストレージコストはBedrock側の$2.24と比べても無視できる水準でした。「S3 Vectors採用でコストが劇的に下がる」という試算の方向性は、実測でも裏付けられたと言えます。

肝心の総額はどうでしょうか。実測期間の$2.24を単純に月換算（30日 ÷ 7日）すると、約$9.6になります。前回の試算で示した「$10〜40/月」というレンジの下限に近い数字です。PoC規模の軽い利用であれば、試算はそこまで外れていなかったことになります。

ただし前回の試算は本番想定のRAG構成込みの数字なので、単純比較はできません。あくまで参考値として捉えてください。次のセクションでは、この実測単価をもとに、より現実的な利用規模（データ1GB・ユーザー100人）まで試算を延ばしてみます。

本番規模だったらどうなるか（データ1GB・ユーザー100人の試算）

ここからは実測ではなく、明示的な仮定に基づく試算です。実測で得られた「1リクエストあたりの実コスト単価」を、想定した利用規模に掛け合わせて計算しています。

前提とする仮定

• 元データ: 1GB（現在の251KBから約4,000倍）
• 利用者: 100人（現在の2名から50倍）
• 利用頻度: 1人あたり1日5回の問い合わせ（実測時の開発者の利用頻度よりは抑えめに設定）

データ量の試算

現在の実測比率（251KBのテキストから460ベクトル）をそのまま延ばすと、1GBの元データでは約192万ベクトルになる計算です。

1,073,741,824 バイト ÷ 559.6 バイト/ベクトル ≈ 192万ベクトル
192万ベクトル × 4KB（1024次元 × float32） ≈ 7.9GB

S3 Vectorsのストレージ単価（$0.06/GB/月）で計算すると、ストレージコストは月額約0.47ドルです。データ投入時のPUT料金（$0.20/GB）を含めても、初回投入コストは約1.57ドルにとどまります。データ量が1GBに増えても、ストレージまわりのコストはほとんど気にならない水準です。

生成・検索コストの試算

実測で得られた1回あたりの単価は、Haiku呼び出しが約$0.0063、Sonnet呼び出しが約$0.0079、Titan Embedによる検索が約$0.000011でした。それぞれの実測コストを呼び出し回数で割った単純平均です。

100人が1日5回問い合わせると仮定すると、月間の問い合わせ回数は次の通りです。

100人 × 5回/日 × 30日 = 月15,000回の問い合わせ

実測での生成:検索の比率（1:約6）をそのまま当てはめると、月間で生成呼び出しが15,000回（Haiku:Sonnet ≈ 53:47で按分すると約7,960回・7,040回）、検索呼び出しが約89,100回になります。実測単価を掛け合わせると、月額のBedrockコストはおおよそ次の通りです。

Haiku:  7,960回 × $0.0063 ≈ $50
Sonnet: 7,040回 × $0.0079 ≈ $56
検索:   89,100回 × $0.000011 ≈ $1
合計: 約$107/月

S3 Vectors側のストレージコスト（月$0.47）を足しても、合計は月$107〜108程度です。コストの大部分が生成呼び出し（Bedrockの推論コスト）に集中し、S3 Vectors側のストレージ・検索コストはほぼ無視できる規模になる、という構造は実測からも試算からも一貫しています。

この試算の限界

この試算には、正直に言っておくべき前提の粗さがいくつかあります。

• 1GBへのデータ量の延ばし方は、現在のチャンク粒度が同じ比率で保たれる前提です。文書の種類によってチャンクの粒度は変わるため、実際の分野の文書で改めて確認が必要です
• 「1人1日5回」という利用頻度は、実際のユーザー行動データではなく、試算のためのあくまで一つの仮定です。ヘビーユーザーが多い運用では、これより大きく上振れする可能性があります
• 実測単価（Haiku約$0.0063/回など）は、この1週間のトークン使用パターンに基づく単純平均です。質問の長さやRAGの検索結果量が変われば、実際の単価も変わります

これらの限界を踏まえたうえでも、結論は変わりません。「S3 Vectorsのストレージ・検索コストは、データ量が増えてもほぼ気にならない」「コストの大部分は生成呼び出しに集中する」という構造は、実測と試算の両方から一貫して得られています。

まとめ

源内AIのAWS環境を実際に1週間運用し、CloudTrailで呼び出し回数を、Cost Explorerで実測コストを確認しました。315回の生成呼び出しと1,872回の検索呼び出しで、実測コストは$2.24でした。月換算すると約$9.6となり、前回の試算で示した「$10〜40/月」の下限に近い数字で、試算の方向性は実測でも裏付けられました。

データ1GB・ユーザー100人という本番規模を仮定した試算では、実測単価をもとに月額約$107という数字が出ました。コストの大部分は生成呼び出しに集中し、ストレージ・検索コストはほぼ無視できる規模だという結論です。

同じようにPoC環境のコストを実測したい方は、まずCost Explorerの金額だけで判断せず、CloudTrailで実際の呼び出し回数を数えるところから始めてみてください。

参考文献

• Amazon Bedrock pricing — Bedrockの料金体系（従量課金・固定最低月額なし）
• Amazon S3 pricing — S3 Vectorsのストレージ・PUT・クエリ単価
• S3 Vectors — S3 VectorsとBedrock Knowledge Basesの統合について
• Amazon S3 Vectors now generally available — S3 Vectors GA時のAWS公式ブログ
• AWS CloudTrail lookup-events — 本記事で使用したCloudTrailイベント検索コマンド
• 源内をAWSで動かすといくらかかるか——構成別コスト試算 — 本記事の試算部分の元になった記事
• 源内（genai-web）をAWSにCDKでデプロイする手順とハマりやすい注意点 — 基本的なデプロイ構成