結局、Bedrock のコスト削減はどうやるのか

― 4層フレームワーク、「測れない」という制約、そして品質担保という免許 ―

DELTA ｜ 2026年8月

---

 

1. エグゼクティブサマリー

● LLM のコスト削減には、プロバイダに依存しない共通の「型」がある。 可視化 → レート最適化 → トークン最適化 → 品質担保の4層に、仕事の設計そのものを変える Workload 層を加えた構造であり、前号までに論じてきた Agent FinOps の Inform / Optimize / Operate にそのまま対応する。 ● ただし Bedrock では、その型の「測る」段に固有の制約が集中している。 請求側から取れる最小粒度は「モデル × usage type × 日」であり、意思決定に必要な粒度は自前の推定系でしか作れない。しかも設定は遡及しない。計器を立てる作業は、診断より前——今日——に来る。 ● そして最も重要な論点は、最適化の前提となる変更管理の規律である。 Offline Evals → Shadow Traffic → Canary。この三段階を運用できて初めて、コスト削減は「主張できる成果」になる。そして実務者調査が示すのは、この規律を運用できている組織がほとんど存在しないという事実である。差がつくのはモデルの選定眼ではなく、ここだ。

 

2. 単価は下がったのに、総額が増える

出発点は、素朴な分解である。

Cost ＝ Σ（ 呼び出し回数 × 平均トークン数 × 単価 ）

3つの項がそのまま3つの打ち手に対応する。単価を下げる、トークンを減らす、そもそも呼ばない。ここまでは誰でも言える。問題は、この式が測っているのはトークンであって、成果ではないという点にある。前号（リターン編）で論じたとおり、エージェントは失敗した出力にも課金される「非人間の予算保有者」である。トークン単価を半分にしても、失敗してやり直す回数が倍になれば総額は変わらない。単価の最適化に成功しながら請求額が増え続ける——という一見不可解な状況は、実際に起きるし、この式の上では説明できない。

そこで、意思決定にはもう一段上の単位を使う。

cost-of-pass ＝ 総コスト ÷ 成功した成果の数

成果1つを得るのに、実際いくらかかったか。トークンは分解の単位であり、cost-of-pass が意思決定の単位である。集計軸も同じ発想で選ぶ。run 単位ではなく「チェーン内のノード（プロンプトテンプレート）× モデル」でグルーピングし、input / output / cache read を分け、リーズニングモデルでは output に乗る reasoning tokens を最初から分離しておく。分離していなければ、後段でリーズニングエフォートを下げたときに効果を測れない。

なお「1〜2ノードに総コストの7〜8割が集中する」という経験則がよく語られるが、これは出典のある数字ではない。自分のトレースで確かめる。当たっていれば工数配分が決まり、外れていれば分散しているという情報が得られる。出典を確認できない数字を意思決定に使わない——この規律は、本レターの通奏低音でもある。

3. 4層＋Workload — Agent FinOps への接続

プロバイダ非依存の基本フレームワークは、次の構造になる。

層	何をするか	Agent FinOps での位置
① 可視化	コスト方程式をトレース粒度で分解し、cost-of-pass を出す	Inform
② レート最適化	単価を下げる（カスケード／ルーティング、caching、batch、コミットメント）	Optimize ／ Rate
③ トークン最適化	量を減らす（リーズニングエフォート、プロンプト圧縮、スキーマ簡素化）	Optimize ／ Usage
★ Workload	仕事の設計そのものを変える（そのステップに LLM は要るのか）	Optimize ／ Workload
④ 品質担保	SLO 付きの変更管理（Offline Evals → Shadow → Canary）	Operate

 

②は学術的な裏づけが最も厚い層である。FrugalGPT（Chen, Zaharia, Zou 2023）がコスト削減戦略を prompt adaptation ／ LLM approximation ／ LLM cascade の3類型に整理した古典にあたり、安いモデルから順に試すカスケードで GPT-4 同等の性能を最大98%低いコストで達成したと報告した。RouteLLM は strong / weak 2モデル間のルーティングを選好データから学習し、閾値 α でコストと品質のトレードオフを制御する枠組みで、ルーター自体が OSS 化されている。

ただし、ここに実務上の落とし穴がある。RouteLLM の評価基準は会話ベンチマークである。エージェントの品質を決めるのはツールコールのスキーマ妥当性やマルチステップ推論の成否であって、会話の好ましさではない。会話の選好で学習したルーターは、エージェントタスクで性能が大きく落ちうる。自分のタスクで検証する前に入れてはいけない（検証には RouterBench が使える）。

③で現在最も動いているのはリーズニングエフォートの制御である。overthinking の研究では、精度が思考の長さに対して逆U字を描くことが示されている。つまり「長く考えさせるほど良い」ではなく、エフォートを下げても品質が落ちない——場合によっては上がる——ゾーンが存在する。前号で「Token Maxxing は乗り越えるべき閾値」と書いたのと同じ構図が、ここでは1リクエストの内側で起きている。

そして効き幅が最大になりやすいのは、4層の外にある Workload である。そのステップは本当に LLM が要るのか、決定的なコードで済まないか。リトライの設計は妥当か——失敗出力にも課金される以上、無限リトライは費用の穴である。①〜④は「いまの仕事のやり方を前提に安くする」枠組みなので、前提そのものを疑う層を必ず別に置いておく。

4. Offline Evals → Shadow → Canary — 品質担保という免許

②も③も、品質を落とすリスクを構造的に抱えている。そして「コストを30%削減した」という主張は、暗黙に「品質を落とさずに」を含意した前後比較である。つまり品質担保のパイプラインとは、単なる安全装置ではない。コスト削減という主張そのものを成立させる装置であり、これを持たない組織には、最適化に着手する免許がまだない。変更フローは三段階にする。

第一段：Offline Evals（オフライン評価） 本番トレースから代表サンプルと失敗事例を抽出してゴールデンデータセットを作り、LLM-as-a-Judge で新旧構成をペアワイズ比較する。要点は、judge 自体を人手ラベルとの一致率でキャリブレーションすること。前号で論じた「審判は誰が審判するのか」という問いの、これが実装形である。判定の分散を見込んで閾値は一致率より低めに置き、ブロッキング CI に組み込むのはキャリブレーションが済んだ後。 第二段：Shadow Traffic（シャドー実行） 本番リクエストを新構成に複製し、非同期に実行する。ユーザーには旧構成の応答を返しつつ、実分布の上で新構成の挙動を観測する。judge の差分スコアと並行して、決定的なチェック——スキーマ妥当性、ツールコールの引数——を必ず併走させる。judge だけでは「落ちたこと」は分かっても「どう落ちたか」が見えない。 第三段：Canary（段階的展開） 合格したら、実トラフィックの小さな割合から新構成に流し、ロールバック条件（評価スコア、cost-of-pass、レイテンシ）を事前に定義した上で、ルーティングの閾値 α を徐々に動かしていく。

 

この順序には意味がある。手前の段ほど安く、奥の段ほど真実に近い。オフライン評価は安いが過去の分布しか見ていない。シャドーは実分布を見るが実ユーザーの反応は見ていない。カナリアは真実だが、失敗のコストをユーザーが払う。安い段で落とせる変更を安い段で落とし、高い段には通過見込みの高い変更だけを送る——これはソフトウェア工学がテストピラミッドとして数十年かけて学んだ規律の、確率的システムへの移植である。

5. で、これができている組織はほとんどない

ここまでは教科書である。問題は現実との距離だ。CHI 2026 で発表された実務者調査（多様な業種の19名への深層インタビュー）は、LLM プロダクトの評価実践がインフォーマルな「vibe check」——出力を眺めて、なんとなく良さそうかを見る——から組織的なメタワークまでの10類型に散らばっており、多くのチームが形式化の途上にあることを示した。同研究が新たに指摘した課題がresults-actionability gap——評価データを集めても、それを具体的な改善に翻訳できない——である。評価を「やっている」ことと、評価が変更管理として「機能している」ことの間には、大きな溝がある。

実務の肌感覚も同じことを言う。プロンプト変更は「担当者がステージングで数件試して良さそうだったので」本番に入る。モデルの切り替えは「ベンダーのベンチマークが良かったので」行われる。三段階のパイプラインどころか、第一段のゴールデンデータセットすら持たない組織が大半である。なぜか。理由は三つに分解できる。

• 評価自体のコストが見えていない。evals を回すことにもトークン費用がかかる。この費用が可視化に乗っていないため、投資判断の俎上に載らず、「余裕ができたらやる」に永遠に分類される。対処は逆で、evals のコストを environment: evals 等で分離して①の可視化に最初から乗せる。分けておかないと、削減効果が evals 費用で相殺されて見えなくなるという実害もある。
• 審判が未検証のまま審判している。LLM-as-a-Judge を導入したチームでも、judge を人手ラベルでキャリブレーションしている例は少ない。検証されていない judge の合格判定は、vibe check を自動化しただけである。
• 決定的チェックとの役割分担が設計されていない。スキーマ妥当性やツールコール引数のような、確率に頼らず判定できる項目まで judge に投げてしまう。決定的に測れるものは決定的に測る。judge は決定的に測れないものにだけ使う。

ここに逆説がある。ほとんどの組織ができていないからこそ、ここが競争優位になる。パイプラインを持つ組織は、新しい安価なモデルが出るたびに、数日で「移行できるか」を判定できる。持たない組織は「新モデルが安いらしい」という情報を行動に変換できず、様子見のまま四半期が過ぎる。results-actionability gap は、そのままコスト削減の gap である。

コスト削減の実効速度は、モデルの選定眼ではなく、品質担保パイプラインの成熟度で決まる。

 

6. Bedrock 固有の制約 — 「測る」段が重い

ここまでの型を Bedrock に当てようとすると、最初の①可視化で早速つまずく。制約はすべて AWS および Anthropic の公式ドキュメントに明記されているものである。まず、コスト帰属の仕組みが並列に5つ存在する。

仕組み	対象エンドポイント	何で分けるか
Application inference profiles（AIP）	bedrock-runtime（InvokeModel / Converse）	アプリ・チーム（モデルIDをARNに差し替え）
Projects	bedrock-mantle（Responses / Chat Completions）	アプリ・ワークロード
Workspaces	bedrock-mantle（Messages API）	同上（Projects と同一リソース）
IAM principal attribution	bedrock-runtime	呼び出し元 IAM ユーザ／ロール（自動）
Per-request metadata tagging	bedrock-runtime	任意のキーバリュー（リクエスト単位）

 

どれを使うかは、まずエンドポイントで割れる。自社のコードが bedrock-runtime と bedrock-mantle のどちらを叩いているかを棚卸ししない限り、選択肢すら確定しない——これはコスト削減の作業ではなく、アプリケーション実装の調査である。象徴的なことに、AIP を解説する公式ページ自身が「Recommended: Use Projects」と別の仕組みを推奨している。

そして最重要の制約がこれである。金額が請求（Cost Explorer / CUR）に流れる経路は、どの仕組みを使っても最小粒度が「usage type × 日」——すなわちモデル1つ × 入力か出力かの別 × 1日——であり、per-request のコストは生成されない。②③の意思決定に必要だった「ノード × モデル」の粒度は、請求側からは構造的に取れない。

per-request の情報を持つ唯一の手段が metadata tagging だが、記録されるのはトークン数であって金額ではなく、出る場所も請求ではなく model invocation logs である。金額にするには、トークン数に Bedrock の料金表を掛けて自分で計算する。ドキュメントは明確に書いている——レートカードはあなたが保守する。割引、コミットメント、バッチ料金、無料枠、プロビジョンドスループットは、自分でモデル化しない限り一切反映されない。これは軽い話ではない。割引とコミットメントの反映こそがコスト削減の中身であり、それを外した推定値は社内配賦の根拠にしにくい。

では推定値を請求と突き合わせればよいか。できない。ドキュメントの一箇所は invocation logs と CUR を requestId で join せよと指示し、同じページの別の節は、CUR にも CUR 2.0 にも per-request 識別子は存在しないと明記している。join せよと指示されているキーが、join 先に存在しない。実務上の結論として、請求と突き合わせられるのはモデル × usage type の粒度までであり、それより細かい世界はログ側の推定値で持つしかない。

さらに時間の制約が重なる。model invocation logging はデフォルトで無効であり、無効のままのリクエストは成功したままメタデータだけが残らない——エラーにならないので気づかない。cost allocation tag は遡及せず、有効化した日より前のコストにはタグが付かない。両者を合わせると、設定した日より前の内訳は、後から作れない。コスト削減の診断は過去数ヶ月の請求から入るのが定石であるだけに、ここが実務上いちばん痛い。だから「まず計器を立てる」が Day 0 の作業になる。

7. 制約は衝突する — 「二重帳簿」という設計解

制約は単独で痛いだけでなく、互いに衝突する。前号（ガバナンス編）で論じた LLM ゲートウェイを挟むと、プロバイダの請求はゲートウェイの共有クレデンシャルに集約され、開発者ごとに割れなくなる——これは AWS 側と Anthropic 側の双方のドキュメントに同じ記述がある。対策は sts:AssumeRole 時の session tag だが、信頼ポリシーでの sts:TagSession 許可、STS レート上限を避けるクレデンシャルのキャッシュ、セッション単位という束縛への設計対応が要る。

ゲートウェイ側の per-user spend limit も、トークン数を USD 定価で数える推定値であり、公式ドキュメント自身が「circuit breaker であって invoice ではない」と位置づけている。つまりAWS 側もモデル提供側も「正確な金額は相手側にある」と書いており、その相手と突き合わせるキーは存在しない。極めつけは AIP との衝突である。AWS 側の帰属のために AIP を導入するとモデル ID がプロファイルの ARN に変わるが、この ARN はモデル名を含まないため、ゲートウェイ側の課金メーターからは未知モデル扱いとなり、設定でマッピングしない限りデフォルト単価（$5/$25 per million tokens）で計上される。AWS 側の可視化のための設定が、ゲートウェイ側の可視化を壊す。

以上を引き受けた設計解は、正確な単一の帳簿を諦め、性質の異なる2系統を並行して持つことである。

系統	出所	粒度	用途
A. 推定系	invocation logs のトークン数 × 自前レートカード	per-request ／ ノード単位	意思決定（どこを攻めるか）、cost-of-pass の算出
B. 権威系	CUR 2.0 ／ Cost Explorer	モデル × usage type × 日	経営報告・社内配賦（請求と一致する唯一の系統）

 

突き合わせはモデル × usage type の粒度でのみ行い、一致させようとしない。A のレートカードに自社の割引・コミットメント・バッチ料金を反映し、B との乖離を契約条件で説明できる状態を保つ。乖離が説明できずに広がり始めたら、それはレートカードが古くなったというシグナルである。この計算機——自社の契約条件を再現したレートカードと推定系——を持てるかどうかが、Bedrock のコスト削減で最も手間がかかり、最も差がつく部分である。

8. ロードマップ — Day 0 は今日である

制約の非遡及性が順序を規定する。後回しにした期間のデータは、永久に取れない。

段階	やること
Day 0：計器を立てる	全リージョンで model invocation logging を有効化。共有クライアントまたはゲートウェイに request metadata を仕込み、全リクエストに必ず乗せる。キーは低カーディナリティで安定したもの（team / environment / feature / node）——第2章の「ノード × モデル」の集計軸を、ここで metadata のキーとして設計する。cost allocation tag を有効化し、CUR 2.0 を caller identity 込みで作り直す。ゲートウェイには session tag を組み込む。
Phase 1：二系統の可視化	推定系 A と権威系 B を並行して立てる。意思決定は A、報告と配賦は B。cost-of-pass は A 側で算出し、成功判定には④の決定的チェックを流用する。パレートを取り、コストが集中しているかを自分のトレースで確認する。
Phase 2：品質担保を先に	最適化に着手する前に、Offline Evals → Shadow → Canary のパイプラインを立てる。judge は人手ラベルでキャリブレーションし、決定的チェックを併走させる。evals のコストは environment: evals で分離し、可視化に乗せる。
Phase 3：効き幅の大きい順に	Workload（そのステップに LLM は要るか、リトライ設計は妥当か）→ ③トークン最適化（caching、プロンプト圧縮、リーズニングエフォート、スキーマ簡素化）→ ②レート最適化（ルーティング、モデル階層、batch、コミットメント）。②を先に持ってこない。ルーティングは会話ベンチマーク由来の落とし穴があり検証コストが高い。caching やスキーマ簡素化のほうが低リスクで早い。
Phase 4：運用に落とす	ゲートウェイの spend limit は circuit breaker として置く（invoice ではない）。月次で A と B の乖離を確認し、広がったらレートカードを更新する。新モデル追加時は AIP のプロファイルを作り直し、ゲートウェイ側の models[].id マッピングも同時に更新する。

 

9. CxO への三つの問い

本レターの議論は、経営への問いとしては三つに凝縮される。

• 自社の LLM 支出を「ノード × モデル」で言えるか。言えなければ、まだ Inform の手前にいる。そして Bedrock 上では、この粒度は請求からは出てこない——計器を立てた日からしか作れない。着手が一日遅れれば、失われるデータも一日分増える。
• 直近のプロンプト変更・モデル変更は、どの評価を通って本番に入ったか。答えが「担当者が見て良さそうだった」なら、それは vibe check であり、コスト最適化に着手する免許がまだない。削減の主張は品質一定の前後比較であり、品質担保のパイプラインだけがそれを成立させる。
• 次に安価なモデルが登場したとき、移行判断まで何日かかるか。この日数こそが、自社のコスト削減の実効速度である。パイプラインを持つ組織は数日で答えを出し、持たない組織は情報を行動に変換できないまま様子見を続ける。

モデルの単価はこれからも下がり続けるだろう。しかし前号までに論じたとおり、単価の低下は使用量の拡大を誘発する（Jevons のパラドックス）。単価が下がる世界で総コストを制御できるのは、測る計器と、変更を安全に流す規律を持つ組織だけである。その両方が、Bedrock では自動には手に入らない——これが本レターの結論である。

DELTA では、Agent FinOps の導入支援として、Day 0 の計器設計からレートカードの構築、評価パイプラインの立ち上げまでを一貫して支援している。自社環境での適用についてはお問い合わせいただきたい。

---

 

参考文献・一次ソース

AWS 公式ユーザーガイド: Per-request metadata tagging ／ Application inference profiles ／ Projects ／ Workspaces ／ IAM principal attribution（Amazon Bedrock User Guide, Cost management 各章）; Introducing granular cost attribution for Amazon Bedrock（AWS ML Blog, 2026-04-17）

Anthropic 公式ドキュメント: Claude apps gateway ／ Claude apps gateway spend limits（code.claude.com/docs）

Chen, Zaharia, Zou. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176 (2023)

RouteLLM: Learning to Route LLMs with Preference Data. arXiv:2406.18665 ／ RouterBench: A Benchmark for Multi-LLM Routing System. arXiv:2403.12031

Reasoning on a Budget: A Survey of Adaptive and Controllable Test-Time Compute in LLMs. arXiv:2507.02076

Results-Actionability Gap: Understanding How Practitioners Evaluate LLM Products in the Wild. Proceedings of CHI 2026

丹哲郎. Agent FinOps: Applying Cloud FinOps Discipline to the Cost Governance of AI Agents (2026-07-05)