目次を表示する

Bedrockで Production Ready な AI 機能を作る ── 設計・運用・現場の知恵

コストを設計する ── PT・Intelligent Prompt Routing・Prompt Caching を使い分ける

コストを設計する ── PT・Intelligent Prompt Routing・Prompt Caching を使い分ける

「PoC の月数千円が、本番で月数百万円」

サードパーティのコスト最適化ブログでよく見かける警句がある。少しだけ和訳すると、こうだ。

Token Rates Hide a $350/Month Trap. （トークン単価表には、月 350 ドルの罠が隠れている）

── Cloud Burn, “Amazon Bedrock Pricing: Token Rates Hide a $350/Month Trap”（サードパーティブログによる主張）

PoC では「Sonnet で何でも答えさせて」「max_tokens も適当で」「キャッシュも何もなしで」月数千円だったものが、本番でユーザーが増えた瞬間に 月数百万円規模になる ── これは Bedrock の界隈で「日常的に起きる」事象だ。原因はだいたい同じで、(1) すべて Sonnet で叩いている、(2) max_tokens 未設定で TPM クォータを無駄食いしている、(3) Knowledge Bases の S3・OpenSearch Serverless・ベクトルストアの周辺費を見落としている、(4) 「保険」で Provisioned Throughput を買って 30 % しか使っていない、のどれかに収まる。

この章では、helpdesk-ai のコストを 設計レベルで 最適化する方法を体系化する。ポイントは、「動いてから直す」のではなく、Day 1 から課金モデルを選んでおく ことだ。LLM のコストは、ある日急にスパイクするのではなく、設計判断の積み重ねでじわじわと膨らむ。だから、設計を直さないと、コードをいじっても効かない。

対象：ch14 までで helpdesk-ai が動いている読者 難易度：★★★★☆ 読了時間：約 30 分 触る AWS リソース：Bedrock 課金モデル全般、Application Inference Profile、Intelligent Prompt Routing、Prompt Caching、Batch Inference

Bedrock の課金モデル全体像

最初に、Bedrock がどんな課金モデルを提供しているのかを横並びで把握する。AWS の他サービスに比べて種類が多いので、ここを押さえずに最適化に入っても効果が出ない。

課金モデル価格水準コミット主な用途
On-Demand（Standard）基準価格なし通常の対話・API 呼び出し
Batch Inference−50 %なし24 時間以内に終わればよい非同期処理
Provisioned Throughput時間課金（Model Unit）なし / 1 ヶ月 / 6 ヶ月高稼働率な定常ワークロード
Priority Tier+75 %期間コミットレイテンシ最優先のミッションクリティカル
Flex Tier−50 %なしコスト優先・レイテンシ許容
Cross-Region Inference追加料金なし（Global で約 −10 %）なしスロットル回避・冗長化

これに加えて、ペイ・パー・コール系の周辺機能が乗る。Intelligent Prompt Routing は $1.00 / 1,000 requests、Guardrails は機能ごとに $0.10〜$0.17 / 1,000 text units、Rerank は $0.001 / request 程度だ（research 02 §4.7）。

これら全部を「とりあえず全部使ってみる」のは禁物だ。helpdesk-ai のような社内 LLM アプリでは、まずは On-Demand + Cross-Region Inference Profile で素直に動かして、トラフィックの形（ピーク時 RPM、平均トークン数、再利用されるコンテキストの有無）を観測してから、削るポイントを順番に決めていく。順番は後で「コスト最適化 4 段ロケット」として整理する。

Provisioned Throughput を「保険」で買わない

最初に潰しておくべきアンチパターンが Provisioned Throughput（PT）の無駄買い だ。これは ch17 でアンチパターン #1 として再登場するが、その伏線は今ここで張る。

PT は「Model Unit（MU）」と呼ばれる単位を 時間課金 で確保する仕組みだ。EC2 Reserved Instance に近い概念で、コミット期間で割引が乗る。具体価格は最新モデルでは「営業窓口経由」とされているものが多く（research 02 §4.4）、公表されている範囲では Cohere Command Provisioned が約 $49.50/h（コミットなし）、Llama 2 のレガシー例で 1 ヶ月コミット $21.18/h、6 ヶ月コミット $13.08/h といった水準だ。

PT を On-Demand と比べると、稼働率 80〜85 % が損益分岐 になる（research 04 §5.1）。逆に言えば、それより低い稼働率では PT のほうが必ず高くつく。

xychart-beta
    title "PT vs On-Demand 月額コスト（イメージ）"
    x-axis "平均稼働率（%）" [10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
    y-axis "相対コスト（On-Demand 100%基準）" 0 --> 200
    line "On-Demand" [10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
    line "Provisioned Throughput（1ヶ月コミット）" [85, 85, 85, 85, 85, 85, 85, 85, 85, 85]

注：上図は損益分岐 80〜85 % という事実関係を可視化した 概念図 であり、特定モデル・特定 SKU の実価格を示すものではない。実際の損益分岐点はモデル・コミット期間・割引率で変動する。

この図から読むべきは「稼働率が低いほど、PT は On-Demand より高くなる」という単純な事実だ。にもかかわらず、「将来のピーク時に備えて」「保険として」PT を買ってしまうチームが後を絶たない。日本の事例でも「高額なため何度も再トライが出来ずに実際の選択は断念した」という声が classmethod の DevelopersIO に出ている。

判断ロジックは次の通り、稼働率の見立てを 3 段階で振り分ける とよい。

flowchart TD
    A[まず On-Demand + CRIS で運用<br/>Application Inference Profile で実測]
    A --> B{平均稼働率は？}
    B -- "&lt; 60%" --> C[On-Demand のまま<br/>PT は不要]
    B -- "60% 〜 80%" --> D["On-Demand + Flex Tier<br/>もしくは Prompt Caching で吸収"]
    B -- "&gt;= 80%" --> E[1 ヶ月 PT で検証<br/>→ 安定したら 6 ヶ月 PT]
    style C fill:#e0f7e0
    style D fill:#fff4e0
    style E fill:#ffe0e0

helpdesk-ai の現実的な稼働率を考えてみよう。社員 1,000 人規模の社内ヘルプデスクで、ピーク時間帯（朝礼後・昼休み後）の RPM が 50、それ以外は 5〜10。これは「業務時間中だけ立ち上がる」典型的なパターンで、平均稼働率は 20〜30 % にも届かない ことが多い。この水準で PT を買うのは、明らかに損だ。On-Demand で済む。

逆に、SaaS としてマルチテナント運用していて、24 時間 RPM が安定して 200〜500 出ているようなプロダクトは、PT 検討の対象になる。その場合も いきなり 6 ヶ月コミットを買わない。まず 1 ヶ月コミットで稼働率の見通しが立ってから 6 ヶ月に切り替える、というのが鉄則だ。

// ❌ 悪い例：PoC 段階で「将来のピークに備えて」PT を購入
//   稼働率の見通しがないまま 1 ヶ月コミット → 30% 稼働で On-Demand 比 2 倍コスト
import {
  BedrockClient,
  CreateProvisionedModelThroughputCommand,
} from "@aws-sdk/client-bedrock";

const bedrockMgmt = new BedrockClient({ region: "us-east-1" });

await bedrockMgmt.send(
  new CreateProvisionedModelThroughputCommand({
    modelUnits: 4, // 「とりあえず」で 4 MU 確保
    provisionedModelName: "helpdesk-ai-pt",
    modelId: "anthropic.claude-sonnet-4-5-v1:0",
    commitmentDuration: "OneMonth", // 早期解約しても 1 ヶ月分は請求される
  }),
);

// ✅ 良い例：まず On-Demand + CRIS で 1〜2 ヶ月運用し、
//          Application Inference Profile で実測した稼働率が 80% を継続的に超えてから PT 検討
// （PT 購入コードは「実測のあとに書く」もの）

PT を買うべきかどうかの実測手順は 付録 B のコスト見積もりワークシート で具体的に扱う。ここでは「保険で買うな」というメッセージだけ持ち帰ってほしい。

Intelligent Prompt Routing で Haiku に振る

PT の話の次は、本番でいちばん効くテクニックである Intelligent Prompt Routing に進む。

Intelligent Prompt Routing は、Bedrock が 同じファミリー内の 2 つのモデル（例：Claude Haiku ↔ Sonnet、Llama 3 8B ↔ 70B、Nova Lite ↔ Pro）の間で、プロンプトの複雑度に応じて 動的にルーティングする マネージドな仕組みだ。Anthropic / Meta Llama / Amazon Nova の各ファミリー内で利用できる。

数値を 1 つ覚えてほしい。RAG ユースケースの AWS 実測で、平均 63.6 % のコスト削減。そして 87 % のリクエストが Haiku にルーティングされた（research 04 §3.1, §5.6）。「Sonnet が 100 % 必要だ」と思っているタスクの多くは、実は Haiku で十分な解像度で解けている、というのが Anthropic と AWS の主張だ。

ルーター自体の追加料金は $1.00 / 1,000 requests。1,000 リクエストあたり 1 ドル、つまり 1 リクエストあたり 0.001 ドル（約 0.15 円）の追加料金で、入出力の単価を Sonnet の 1/3〜1/5 にあたる Haiku 価格に落とせる可能性がある。helpdesk-ai のような「FAQ 寄り：複雑判断 = 8:2」みたいなトラフィック分布では、これは効く。

// src/handlers/chat.ts ── Intelligent Prompt Routing を使う
import {
  BedrockRuntimeClient,
  ConverseCommand,
} from "@aws-sdk/client-bedrock-runtime";

const bedrock = new BedrockRuntimeClient({
  region: "us-east-1",
  maxAttempts: 5,
  retryMode: "adaptive",
});

// ❌ 悪い例：すべての問い合わせを Sonnet 固定で叩く（`modelId` に
//   `us.anthropic.claude-sonnet-4-5` のような単一モデル ID をそのまま渡す）。
//   「経費精算の上限は？」のような FAQ も Sonnet で処理されるため、
//   月コストの 40〜60% が無駄になる。

// ✅ 良い例：Anthropic ファミリーの Prompt Router に向ける
//   Haiku で十分なクエリは Haiku、判断が必要なクエリは Sonnet に自動振り分け
const ROUTER_ID =
  "arn:aws:bedrock:us-east-1:123456789012:default-prompt-router/anthropic.claude:1";

export async function askHelpdesk(userText: string) {
  const res = await bedrock.send(
    new ConverseCommand({
      modelId: ROUTER_ID, // モデル ID の代わりに Prompt Router の ARN を渡す
      messages: [{ role: "user", content: [{ text: userText }] }],
      inferenceConfig: {
        maxTokens: 2000, // max_tokens は必ず明示（ch06 / ch13 と同じ規律）
        temperature: 0.2,
      },
    }),
  );

  // どのモデルに振られたかは trace 経由で取得できる
  // res.trace?.promptRouter?.invokedModelId に Haiku / Sonnet のどちらか
  return {
    text: res.output?.message?.content?.[0]?.text ?? "",
    invokedModel: res.trace?.promptRouter?.invokedModelId,
    usage: res.usage,
  };
}

注意点が 2 つある。(1) ファミリーをまたぐルーティングはできない。Anthropic ↔ Nova のような切り替えは別の自前ロジックを書く必要がある。(2) ストリーミング・Tool Use との組み合わせは制約がある（ConverseStream API での挙動はモデル世代によって違うので公式 docs を確認）。本番では「素直な対話チャネル」だけをルーターに通し、Tool Use を伴う Agent 系の呼び出しは Sonnet 固定にする、というハイブリッド構成が手堅い。

そして「63.6 % 削減」の数値はあくまで AWS が公表した RAG ユースケースの実測値 であって、自分のアプリで同じ効果が出ると約束されているわけではない。実測してから判断する。Application Inference Profile に tag を付けて Cost Explorer で比較するのがいちばん早い（後述）。

Prompt Caching ── ヒット率 30 % が損益分岐

3 つめの武器が Prompt Caching だ。これは Claude 4 系（Opus / Sonnet / Haiku）で対応している、「再利用される共通コンテキスト をキャッシュする」機能だ（具体的なバージョン番号は流動的なので、対応世代は最新の公式 docs を要確認）。

仕組みはシンプルで、長く再利用するブロック（システムプロンプト、Few-shot 例、長文の RAG コンテキストなど）に キャッシュポイント を打つと、次の呼び出しで一致するキャッシュがあれば、その部分の入力トークン料金が 10 % に下がる（最大 90 % オフ）。

ただし無料ではない。キャッシュ書き込みコストが、5 分 TTL で通常入力単価の 1.25 倍、1 時間 TTL で 2 倍 かかる。つまりキャッシュは「書き込んで、何度も読まれて」初めて元が取れる仕組みになっている。

この「何度も読まれて」の境目が、ヒット率 30 % 以上 と言われている水準だ（research 04 §5.7、CURATE §1.3）。ただし AWS 公式の「30 % 以上」という明示的記述は見つかっておらず、これは サードパーティブログ（Caylent、dev.to 等）の概算 として扱うべき数値だ。それでも実務的な肌感としてはおおむね正しい。ヒット率が 30 % を割ると、書き込みコストが浮いた読み込みコストを上回って 逆にコスト増 になる、という構造は変わらない。

本書の方針：本書では以降の章（第 13 章観測、第 17 章アンチパターン、第 18 章エピローグ）でも「Prompt Caching の損益分岐はヒット率 30%」を目安値として参照する。これは上記のとおりサードパーティブログ概算であり、AWS 公式の保証値ではない。実プロジェクトでは CloudWatch メトリクスで実測し、自身のワークロードでの損益分岐点を確認すること。

// src/handlers/chat.ts ── Prompt Caching を使う
import {
  BedrockRuntimeClient,
  ConverseCommand,
} from "@aws-sdk/client-bedrock-runtime";

const bedrock = new BedrockRuntimeClient({ region: "us-east-1" });

// helpdesk-ai のシステムプロンプト：会社の規程要約 + ロール定義 + Few-shot 例
// だいたい 4,000 〜 8,000 トークン。これを毎回送ると、ユーザー発話より大きい
const SYSTEM_PROMPT = `
あなたは「helpdesk-ai」、社内ヘルプデスクの AI アシスタントです。
（中略：会社規程の要約 4,000 トークンほど）
出力フォーマットは次の Few-shot 例に従ってください：
（中略：Few-shot 例 2,000 トークンほど）
`.trim();

export async function askWithCache(userText: string) {
  const res = await bedrock.send(
    new ConverseCommand({
      modelId: "us.anthropic.claude-sonnet-4-5",
      system: [
        { text: SYSTEM_PROMPT },
        // cachePoint をブロックの末尾に打つ
        // → ここまでが「再利用されるプレフィックス」として 5 分間キャッシュされる
        { cachePoint: { type: "default" } },
      ],
      messages: [{ role: "user", content: [{ text: userText }] }],
      inferenceConfig: { maxTokens: 2000, temperature: 0.2 },
    }),
  );

  // usage に cacheReadInputTokens / cacheWriteInputTokens が返るので、
  // ヒット率の計測はここから組める
  const usage = res.usage as {
    inputTokens: number;
    outputTokens: number;
    cacheReadInputTokens?: number;
    cacheWriteInputTokens?: number;
  };

  return {
    text: res.output?.message?.content?.[0]?.text ?? "",
    usage,
  };
}

helpdesk-ai でキャッシュが効きやすいのは、次のような場所だ。

  • システムプロンプト：会社規程の要約・ロール定義・出力フォーマット定義など、ユーザー横断で共通の部分
  • 長文 RAG コンテキスト：同じドキュメントを引いてくる確率が高いトピック（人気の FAQ）
  • Few-shot 例：意図分類や引用フォーマットの統一に使う数例

逆に効かないのは、ユーザーごとに完全に異なるパーソナルデータ（個人別の勤怠サマリなど）。これは毎回 cache miss するだけで終わる。

実装上の指針として：

  • ch07 で書いた Streaming + Tool Use のループの中では、システムプロンプトと共通の Tool 定義 にキャッシュポイントを打つ
  • ch08 で書いた Knowledge Bases ベースの RAG では、取得した context ブロックの先頭 にキャッシュポイントを打って、同じドキュメントが再利用されたときにヒットを狙う
  • TTL は基本 5 分。1 時間 TTL は書き込みコストが 2 倍なので、よほどヒット率に確信があるとき限定

ヒット率は Application Inference Profile + CloudWatch メトリクス で測る。これは ch13 で観測の話をしたときに触れた InputTokenCount / CacheReadInputTokens の比から逆算できる。30 % を継続的に切るようなら、その箇所のキャッシュは 外す べきだ。

Batch Inference ── 24 時間以内でいい仕事は半額で

ここまで対話系の最適化を見てきたが、helpdesk-ai のような社内 AI アプリには 「リアルタイムに返す必要がない仕事」 がそこそこある。たとえば、

  • 毎晩の問い合わせログを要約してダッシュボード化する ナイトリーサマリ
  • 新しく追加された社内規程 PDF を メタデータ付きで分類・タグ付け する（ドキュメントエンリッチメント）
  • LLM-as-a-Judge 用の 評価データセット を一括生成する
  • Knowledge Bases のベクトル DB を作り直すときの 埋め込みバックフィル
  • コンテンツモデレーションの キュー処理

これらは「24 時間以内に終われば困らない」性質の処理だ。Bedrock の Batch Inference を使えば、On-Demand の 50 % オフ で実行できる。仕組みは S3 にプロンプトの JSONL を投入してジョブを起動 → 結果が S3 に書き戻る、というシンプルな非同期パイプラインだ。SLA は「24 時間以内」。

// eval/run-batch.ts ── 評価データセット生成を Batch Inference で
import {
  BedrockClient,
  CreateModelInvocationJobCommand,
} from "@aws-sdk/client-bedrock";

const bedrockMgmt = new BedrockClient({ region: "us-east-1" });

await bedrockMgmt.send(
  new CreateModelInvocationJobCommand({
    jobName: "helpdesk-ai-eval-dataset-2026-06-04",
    modelId: "anthropic.claude-haiku-4-5-v1:0",
    roleArn: "arn:aws:iam::123456789012:role/BedrockBatchRole",
    inputDataConfig: {
      s3InputDataConfig: {
        s3Uri: "s3://helpdesk-ai-batch/in/eval-prompts.jsonl",
      },
    },
    outputDataConfig: {
      s3OutputDataConfig: {
        s3Uri: "s3://helpdesk-ai-batch/out/",
      },
    },
  }),
);

ナイトリーサマリのような定常 Batch ジョブは コスト効果がそのまま月額に乗る。helpdesk-ai でナイトリーサマリ・ドキュメントエンリッチメント・評価データセット生成を Batch に寄せるだけで、該当部分のコストが半分 になる。これは設計判断 1 つで効く類の節約だ。

Service Tiers の選び方

課金モデルの一覧表で出てきた Service Tiers にも軽く触れておく。Tier の選択は「速さとコストのトレードオフ」を一発で決めるレバーだ。

Tier価格特徴helpdesk-ai での使い所
PriorityStandard の +75 %出力 TPS が 25 % 改善（公式）「とにかく速さ最優先」の場面のみ。通常は不要
Standard通常価格一般的なワークロードhelpdesk-ai のデフォルト
FlexStandard の −50 %レイテンシは許容、コスト優先Batch にできない非対話系。例：内部ツールの定期エンリッチメント
Reserved保証スループットTPM 保証が必要高負荷 SaaS の本番枠

helpdesk-ai のような社内アプリでは、「Standard を基本、Batch に寄せられるものは Batch、レイテンシ許容できる定期実行は Flex」 という構成が現実的だ。Priority は「秒単位のレイテンシが SLA で縛られる」ような特殊ケース以外、原則使わない。+75 % は重い。

Cross-Region Inference のコスト効果

ch10 で AgentCore を組んだ時にも触れたが、Cross-Region Inference（CRIS）はコスト面でも効く。整理しておく。

  • Geographic CRIS（us. / eu. / jp. / apac. など）：データ主権を遵守したい場合に使う。追加料金なし。クォータは各リージョン独立で持つので、実質的にスロットル耐性が上がる
  • Global CRIS（global.）：全コマーシャルリージョン横断。約 10 % のコスト削減 ＋スループット最大化。データ主権制約が緩い

「約 10 % 削減 & スループット最大化」は AWS 公式の data point だ（research 04 §5.3）。helpdesk-ai が国内の社内アプリで、社員データを日本国外に出してはいけない場合は jp. Geographic CRIS 一択。海外グループ会社も含めて公開する場合や、社内データの国外流出が許容される PoC 段階では Global CRIS を試す価値がある。

ここで重要なのは「データレジデンシー要件を確認せずに Global CRIS に流す」ことが ch17 のアンチパターン #2 につながる点だ。コスト 10 % のために規制違反になっては元も子もない。設計時点でデータ分類を済ませておく。

Application Inference Profiles でコストを可視化する

ここまでの最適化は、「測れていなければ効いたかどうかわからない」 という共通の弱点を持つ。最適化の前にやることは、Application Inference Profile（AIP）でコストを分離可視化する ことだ。これは ch13 観測の章でも触れたが、コスト視点で改めて整理する。

AIP は 追加料金なし で作れる「コスト追跡用の論理プロファイル」だ。Cross-Region Inference Profile の上にラッパとして作り、tag を付与する。これによって Cost Explorer / Cost and Usage Report（CUR）で テナント別・機能別・実験ブランチ別 にコストを分離できる。

// infra/create-app-profile.ts
import {
  BedrockClient,
  CreateInferenceProfileCommand,
} from "@aws-sdk/client-bedrock";

const bedrockMgmt = new BedrockClient({ region: "us-east-1" });

// helpdesk-ai の「FAQ 応答」用プロファイル
await bedrockMgmt.send(
  new CreateInferenceProfileCommand({
    inferenceProfileName: "helpdesk-ai-faq",
    description: "FAQ-style queries for helpdesk-ai",
    modelSource: {
      // Cross-Region Inference Profile をベースに
      copyFrom: "arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-4-5",
    },
    tags: [
      { key: "App", value: "helpdesk-ai" },
      { key: "Feature", value: "faq" },
      { key: "Env", value: "prod" },
    ],
  }),
);

// 「人事 API を叩く Agent」用プロファイル
await bedrockMgmt.send(
  new CreateInferenceProfileCommand({
    inferenceProfileName: "helpdesk-ai-agent",
    description: "Tool-using agent for helpdesk-ai",
    modelSource: {
      copyFrom: "arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-4-5",
    },
    tags: [
      { key: "App", value: "helpdesk-ai" },
      { key: "Feature", value: "agent" },
      { key: "Env", value: "prod" },
    ],
  }),
);

呼び出し側は、modelId の代わりに作成した AIP の ARN を渡すだけだ。あとは CUR を Feature タグで分割集計するだけで、「FAQ がいくら、Agent がいくら」が一目でわかる。Intelligent Prompt Routing の効果測定も、Router を入れた AIP と入れていない AIP を並走させて A/B 比較するのがいちばん正確だ。

AIP の真価は、「マルチテナント・マルチアプリで誰がいくら使っているか」を WAF みたいなレベルで可視化できる こと。SaaS で複数テナント抱える場合は Tenant タグも追加する。「うちのテナントのコストが今月急に伸びてる」が即座に検知できる。

helpdesk-ai のコスト最適化 ── 4 段ロケット

ここまでの武器を、どの順番で使うか。実装現場で何度も使ってきた整理が 「コスト最適化 4 段ロケット」 だ。

flowchart TD
    Stage1[<b>第1段：モデル選定</b><br/>Haiku で済む 40-60% を<br/>Sonnet で叩かない] --> Stage2
    Stage2[<b>第2段：Prompt Caching</b><br/>システムプロンプト・Few-shot・<br/>RAG コンテキストにキャッシュ] --> Stage3
    Stage3[<b>第3段：Batch 化</b><br/>ナイトリーサマリ・エンリッチメント・<br/>評価データセット生成を Batch へ] --> Stage4
    Stage4[<b>第4段：PT or Flex Tier</b><br/>稼働率 80%+ を確認後 PT、<br/>レイテンシ許容なら Flex Tier]
    style Stage1 fill:#cce7ff
    style Stage2 fill:#cce7ff
    style Stage3 fill:#cce7ff
    style Stage4 fill:#ffd9cc

順番が大事だ。第 1 段（モデル選定）と第 2 段（キャッシュ）は、ほとんどの helpdesk-ai 規模のアプリで効く。Intelligent Prompt Routing の AWS 実測 63.6 % 削減はここに乗る数字だ。第 3 段（Batch 化）は、ナイトリージョブを抱えているなら必ずやる。第 4 段（PT / Flex）は、稼働率と SLA に確信が持てるまで触らない。第 4 段を先にやろうとして失敗するのが、PT 無駄買いの正体だ。

helpdesk-ai に当てはめると、初期構成はこうなる。

仕事の種類課金モデルモデル選択
FAQ 応答（リアルタイム）On-Demand + Cross-Region + Intelligent Prompt Routing + Prompt CachingAnthropic Router → Haiku / Sonnet
人事 API を叩く Agent（リアルタイム）On-Demand + Cross-Region + Prompt CachingSonnet 固定（Tool Use の安定性優先）
ナイトリーサマリBatch InferenceHaiku
規程 PDF のエンリッチメントBatch InferenceHaiku
評価データセット生成Batch InferenceSonnet（質優先）
ベクトル埋め込みバックフィルBatch InferenceTitan Embed v2

Application Inference Profile で各タスクに tag を付け、毎月の CUR で「想定通りの比率になっているか」を確認する。これだけで、PoC のときに気付かなかったコスト構造が見えるようになる。

実際の数値で考える

抽象論で終わらせないために、公開されている実数を 3 つだけ並べておく。

  • Pfizer（VOX）：研究者の検索時間を 年 16,000 時間削減 ＋ インフラコスト 55 % 削減。SageMaker + Bedrock の組み合わせ事例（AWS Case Study）
  • CyberAgent / ABEMA：サッカー中継のゴールシーン検出からハイライト動画と SNS 投稿を自動生成、1 人あたり業務量を大幅減（AWS 導入事例）
  • タキヒヨー：Bedrock + GenU を 4 部門展開、月 450 時間以上の工数削減、デザイン部門は 1 作品 2 時間の効率化（AWS 導入事例）

「インフラコスト 55 % 削減」のような数字は、本章で示した 4 段ロケットを順番にやれば、「夢の数字」ではなく「やった人が普通に到達する数字」 だ。逆に何もしなければ、Cloud Burn が警告したような「PoC 月数千円 → 本番月数百万円」が普通に起きる。差分は、すべて設計判断にある。

これら定量数値の中で、サードパーティブログ（doit.com、cloudburn.io 等）由来の「複合最適化で 40〜60 % 削減」や「PT 適切利用で 30〜40 % 削減」といった概算は AWS 公式の保証値ではない ので、自社で再現する前提で参考値として読んでほしい。

次の Part 4 へ

helpdesk-ai はこれで 「動く」から「Production Ready」までの設計をひととおり一周 したことになる。Converse API（ch06）から始めて、Streaming + Tool Use（ch07）、Knowledge Bases（ch08）、Bedrock Agents（ch09）、AgentCore（ch10）、Guardrails（ch11）、評価（ch12）、観測（ch13）、セキュリティ（ch14）、そして本章のコスト設計（ch15）。helpdesk-ai は完成だ。

ここから Part 4 では視点を変える。他社が実際に何をやってきて、何で失敗しているか を見ていく。

  • 第 16 章では、住信 SBI ネット銀行・セゾンテクノロジー・Toyota・Pfizer など、国内 4 社・海外 3 社の事例 を読み解く。Pfizer のインフラコスト 55 % 削減・住信 SBI の AgentCore Runtime 採用判断・Toyota の v1 RAG から v2 AgentCore への移行など、本シリーズで扱った機能がどう組み合わさったかを実例で確認する
  • 第 17 章では、9 つのアンチパターン を「症状 / 根本原因 / 脱出法」で整理する。本章で予告した PT 無駄買い・コスト見積もり失敗 はここで再登場し、ch11 で触れた Mask モード・ch13 で触れた max_tokens・ch14 で触れた VPC Endpoint 欠落と並ぶ
  • 第 18 章のエピローグでは、Production Ready の 15 の判断ポイント として全体を回収する

そして、本章で触れた コスト見積もりワークシート は付録 B で具体的な手順に落とす。CUR の SQL クエリ例、Application Inference Profile の構築 IaC、P95 ベースの月額試算スプレッドシートのテンプレートまで揃える予定だ。「PoC の請求書が本番で 10 倍になる」のを防ぐ実務テンプレートとして使ってほしい。

章末まとめ

  • Bedrock の課金モデルは 6 系統（On-Demand / Batch / PT / Priority / Flex / CRIS）。設計時点で「どの仕事をどのモデルに乗せるか」を決めるのが Production Ready の条件
  • Provisioned Throughput の損益分岐は 80〜85 % 稼働率。60 % 未満は On-Demand 一択、60〜80 % は Flex / Prompt Caching で吸収、80 %+ で初めて PT 検討。「保険」で買うのは ch17 アンチパターン #1
  • Intelligent Prompt Routing は AWS 実測で RAG 用途 63.6 % 削減、87 % が Haiku ルーティング。$1 / 1,000 requests の追加料金で、Sonnet 単価を Haiku 単価に近づけられる
  • Prompt Caching はヒット率 30 % 以上で初めて元が取れる（サードパーティブログ概算）。書き込み 1.25 倍（5 分）/ 2 倍（1 時間）のコスト構造を念頭に、システムプロンプト・Few-shot・RAG コンテキストに絞って打つ
  • Batch Inference は On-Demand の 50 % オフ、24 時間以内 SLA。ナイトリーサマリ・エンリッチメント・評価データセット生成・埋め込みバックフィルは原則 Batch
  • Application Inference Profile は追加料金なしで tag によるコスト分離可視化を実現する。マルチテナント・マルチ機能の SaaS では必須
  • コスト最適化 4 段ロケット：(1) モデル選定 → (2) Prompt Caching → (3) Batch 化 → (4) PT or Flex。順番が大事で、第 4 段を先にやると失敗する
  • 次章からは Part 4。helpdesk-ai は完成、ここからは他社事例とアンチパターンから振り返る