生成AIアプリの運用コストは、放っておくとトークン課金の積み上げで膨らみ続けます。AIP-C01のTask 4.1が問うのは「品質を保ったままFMコストを下げる引き出しをいくつ持っているか」。この記事では、トークン効率化 → モデル選択 → キャッシュ → スループット設計の4つの引き出しを、公式試験ガイドとAWSドキュメントの一次情報で解説します。とくに混同しやすいプロンプトキャッシュとセマンティックキャッシュの違いは図解で整理します。
コストの正体：入力トークンが支配する
FMの課金は基本的に入力トークン＋出力トークンの従量制です。RAGやエージェントでは、システムプロンプト・ツール定義・検索で取得したコンテキストが毎回入力側に積まれるため、実は出力よりも入力コストが支配的になりがちです。だから試験ガイド（スキル4.1.1）の対策も入力側に集中しています。
- トークンの推定と追跡——まず測る。どのリクエストが何トークン使っているかを可視化する（モニタリングは分野4のTask 4.3）
- コンテキストウィンドウの最適化／コンテキストプルーニング——RAGの検索結果を関連度の高い少数に絞る（リランカーの活用はここでも効く）、古い会話履歴を要約して剪定する
- プロンプト圧縮——冗長な指示文を削り、テンプレートを簡潔に保つ
- 応答サイズのコントロール／応答制限——最大出力トークンを要件どおりに絞る。「簡潔に答えよ」の指示も立派なコスト対策
モデル選択で削る：適材適所の階層化
スキル4.1.2の核心は「全リクエストに最強モデルを使わない」です。
- 階層化されたFM——クエリの複雑さで振り分ける。定型的な分類・抽出は小型モデル、複雑な推論だけ高性能モデルへ
- モデルカスケード——まず安価なモデルに解かせ、信頼度が低いときだけ上位モデルにエスカレーションする
- 価格対性能比（price-performance）の測定——「正答率◯%をトークン単価いくらで達成できるか」で比較する。感覚ではなく計測（モデル評価は分野5と連動）
プロンプトキャッシュ——「同じ前置き」の再計算を省く
Amazon Bedrockのプロンプトキャッシュは、プロンプトの先頭部分（プレフィックス）の計算結果をキャッシュし、次のリクエストで再利用する公式機能です。長い文書を読み込ませたチャットや、巨大なシステムプロンプト＋ツール定義を持つエージェントで効きます。公式ドキュメントの仕様を正確に押さえましょう（試験で細部が問われうるポイントです）。
| 仕様 | 内容（公式ドキュメント準拠） |
|---|---|
| 仕組み | キャッシュチェックポイントを置き、そこまでの連続したプレフィックスをキャッシュ。プレフィックスはリクエスト間で不変（静的）であることが条件——変えるとキャッシュミス |
| 料金 | キャッシュから読んだトークンは割引レート。書き込みはモデルによって通常入力より高いレートの場合あり |
| TTL（有効期間） | 多くのモデルで5分、ヒットするたびリセット。対応モデルでは1時間TTLも指定可（長いTTLのエントリを短いTTLより前に置く制約あり） |
| チェックポイント | モデルごとに最小トークン数（1,024〜4,096など）と最大数（例：4個）がある。最小未満で置いても推論は成功するがキャッシュされない |
| 評価順序 | tools → system → messages の順に連鎖。前段（例：ツール定義）を変更すると後段のキャッシュも無効化される。安定した内容を前に、変動する内容を後ろに置くのが鉄則 |
| 制約ほか | オンデマンド推論のみ対応（バッチ推論API非対応）。キャッシュヒットはレート制限に算入されない＝スループット改善にも効く |
設計の勘所は「静的な部分を前に集める」。システムプロンプト・ツール定義・参照文書のような不変部分を先頭に置き、その直後にチェックポイント。ユーザーの質問など変動部分は必ずその後ろです。
セマンティックキャッシュ——「意味が同じ質問」の呼び出しを省く
プロンプトキャッシュが「同じ前置きの計算」を省くのに対し、セマンティックキャッシュはFM呼び出しそのものを省きます。仕組みは、質問を埋め込みでベクトル化し、過去の質問と類似度が閾値を超えたらキャッシュ済みの回答をそのまま返す——「営業時間は？」と「何時までやってますか？」を同じ質問として扱えます。なおこれはBedrockのマネージド機能ではなく設計パターンで、埋め込みモデル＋ベクトルストア（前回記事の技術）で実装します。試験ガイド（スキル4.1.4）は関連パターンとして決定論的リクエストハッシュ（完全一致キャッシュ）、結果フィンガープリンティング、エッジキャッシュ（CloudFront等で配信端で返す）も挙げています。
| 観点 | プロンプトキャッシュ | セマンティックキャッシュ |
|---|---|---|
| 何を省く？ | 同一プレフィックスの再計算 | 意味が同じ質問へのFM呼び出し自体 |
| 効く場面 | 長いシステムプロンプト／文書チャット／巨大なツール定義 | FAQ・ヘルプデスクなど言い換えの多い同義質問 |
| 提供形態 | Bedrockの公式機能（Converse/InvokeModel等） | 設計パターン（埋め込み＋類似度で自前実装） |
| 新規性のある回答 | 毎回生成する（変動部分は普通に推論） | キャッシュヒット時は生成しない（鮮度・正確性の管理が必要） |
スループットとリソース効率（スキル4.1.3）
- バッチ戦略——リアルタイム性が不要な大量処理はバッチ推論でまとめて安く（※前述のとおりプロンプトキャッシュはバッチAPI非対応、という組み合わせ制約に注意）
- プロビジョンドスループットの最適化——定常大量トラフィックはスループット購入でコストを予測可能に（使い分けは模試の分野2でも出題）
- 容量プランニング＋使用率モニタリング＋自動スケーリング——ピークに合わせた固定確保ではなく、実測に基づいて追従させる
確認クイズ（本番形式・3問）
Q1. 200ページの技術文書を読み込ませたチャットアプリで、ユーザーが同じ文書に対して質問を繰り返すたびに入力コストが膨らんでいる。最も直接的な削減策はどれか？
Q2. Converse APIでキャッシュチェックポイントを設定したが、レスポンスを見るとまったくキャッシュされていない。推論自体は成功している。最も可能性が高い原因はどれか？
Q3. tools・system・messagesの3箇所にキャッシュチェックポイントを設定したエージェントで、ツール定義を1つ更新したところ、次のリクエストで全キャッシュがミスになった。この挙動の説明として正しいのはどれか？
よくある質問（FAQ）
Q. プロンプトキャッシュのTTL（有効期間）はどれくらいですか？
A. 多くのモデルで5分で、キャッシュヒットのたびにリセットされます。対応モデルでは1時間TTLも指定でき、5分以上間隔が空く会話やエージェントの長時間処理に有効です。1時間と5分を同一リクエストで併用する場合は「長いTTLを先に置く」制約があります。
Q. セマンティックキャッシュはBedrockの機能ですか？
A. いいえ、設計パターンです。質問を埋め込みでベクトル化し、類似度が閾値を超えた過去質問の回答を再利用する仕組みを、埋め込みモデル＋ベクトルストア＋キャッシュ層で構成します。ヒット時はFMを呼ばないため削減効果は最大ですが、古い回答を返さない鮮度管理（TTLや無効化ルール）を自分で設計する必要があります。
Q. キャッシュヒットはレート制限（クォータ）にカウントされますか？
A. プロンプトキャッシュのキャッシュヒットはレート制限に算入されません（公式ドキュメント明記）。つまりコスト・レイテンシーに加えてスループットの実質的な引き上げにも効きます。
まとめ
- コスト最適化は4つの引き出し：①トークン効率化（圧縮・プルーニング・応答制限）②モデルの階層化・カスケード ③キャッシュ ④スループット設計
- プロンプトキャッシュ＝同じプレフィックスの再計算を省くBedrock公式機能。静的な内容を前に・チェックポイントは最小トークン以上・tools→system→messagesの連鎖無効化に注意
- セマンティックキャッシュ＝意味が同じ質問へのFM呼び出し自体を省く設計パターン。FAQ型ワークロードで効果最大
- バッチ推論とプロンプトキャッシュは併用不可、キャッシュヒットはレート制限非算入——組み合わせの可否まで覚えると盤石
出典（2026年7月11日閲覧）：AWS公式試験ガイド（AIP-C01）Task 4.1、Prompt caching for faster model inference（Amazon Bedrockユーザーガイド）。モデル別の最小トークン数・TTL対応は変更されうるため最新はドキュメントをご確認ください。
コメント