Amazon Bedrock版GPT-5.6完全ガイド｜Sol/Terra/Lunaの違い・料金・プロンプトキャッシュ（入力コスト最大90%割引）
GPT-5.6（Sol / Terra / Luna）がAmazon Bedrockで一般提供され、AWS上でOpenAIの最新モデルを直接利用できるようになりました。本記事は「どのモデルを使うべきか」「Bedrock経由のメリットは何か」「プロンプトキャッシュで本当にコストを下げられるのか」を、実務で判断・実装できるレベルで整理した導入ガイドです。実装前には必ずAWS公式ドキュメントを確認してください。
結論（短く、導入判断の答え）
結論：
- まずはTerraを基準モデルにしてPoCを行う。汎用業務・RAG・社内QAに最適なバランスを提供する。
- 高品質・高度推論が必要ならSolを検証（コーディング支援、セキュリティ解析など）。
- 要約・分類・ログ処理など大量バッチはLunaでコストを抑える。
- プロンプトキャッシュは「システムプロンプト」「ツール定義」「固定ルール」など何度も使う入力部分に有効。入力トークンに対して読み取りで最大90%割引が効くが、出力トークンやキャッシュ対象外の入力は通常料金がかかる点に注意。
- AWS請求統合、IAM/CloudTrailによるガバナンスを重視するならBedrock経由が有力。ただし、最新機能や最速提供を重視する場合はOpenAI直利用も検討する。
目次（ガイドの流れ）
- GPT-5.6 Sol / Terra / LunaがBedrockで一般提供
- モデルの違いと料金感
- Bedrockを使うメリット
- プロンプトキャッシュとは（仕組みと注意点）
- コストシミュレーション（具体例）
- キャッシュ設計例・実装イメージ（Bedrock Responses API）
- ユースケース別のモデル選定とモデルルーティング
- 導入前チェックリストとステップ・バイ・ステップ手順
- FAQ（よくある質問）
GPT-5.6 Sol / Terra / LunaがAmazon Bedrockで一般提供開始
何が変わるのか（要点）
GPT-5.6はSol / Terra / Lunaの3モデル構成で提供され、Amazon BedrockのResponses API経由で利用可能になりました。これにより、AWS請求に統合して利用できるほか、IAMやCloudTrailと連携した監査・ガバナンス設計がしやすくなります。
この記事で扱う範囲
モデルの違い、料金感、プロンプトキャッシュの仕組みと実務的な損益分岐、Bedrockでの実装イメージ、運用・ガバナンス上の注意点まで一気通貫で解説します。
GPT-5.6 Sol / Terra / Lunaの違い（簡易早見表）
モデル | 位置づけ | 向いている用途 | コスト感（目安） |
|---|---|---|---|
Sol | 最上位 | 高度推論、コーディングエージェント、セキュリティ分析 | 高 |
Terra | バランス型 | 社内QA、RAG、文書生成、業務アシスタント | 中 |
Luna | 高速・低価格 | 要約、分類、ログ処理、大量バッチ | 低 |
運用方針の提案
まずTerraを標準ラインとしてPoC→評価、軽量処理はLunaに振る、難易度の高いケースだけSolで検証する「モデルルーティング」運用が現実的でコスト効率も良いです。
Sol / Terra / Lunaの料金比較（執筆時点の参考値）
下表は執筆時点の一般公開情報をもとに示した参考単価です。料金は変更される可能性があるため、実装前にAWS公式を必ず確認してください。
モデル | 入力料金 | 出力料金 |
|---|---|---|
Sol | $5 / 100万トークン | $30 / 100万トークン |
Terra | $2.50 / 100万トークン | $15 / 100万トークン |
Luna | $1 / 100万トークン | $6 / 100万トークン |
ポイント：出力トークン単価の差が大きく、長文生成系ワークロードでは出力コストが支配的になるため、入力キャッシュだけでは総コスト削減に限界がある場合があります。
Amazon BedrockでGPT-5.6を使うメリット
- AWS請求に統合でき、既存の予算・コミットメントと合わせられる
- AWS IAMで認証管理でき、CloudTrail/CloudWatchで監査・メトリクスを取りやすい
- Bedrock内で他モデル（ClaudeやLlama等）と併用・切替がしやすい
- 一方でBedrock固有のリージョン・クォータ・API仕様差分は要確認
プロンプトキャッシュとは（仕組みと設計の勘所）
プロンプトキャッシュは「繰り返し使う入力トークン」を明示的にキャッシュし、読み取り時に入力料金を大幅に割引する仕組みです。主な仕様（公開情報に基づく参考）:
- キャッシュ書き込みは通常入力料金の約1.25倍（初回書き込みコスト）
- キャッシュ読み取りは通常入力料金から最大約90%割引
- キャッシュ保持は最小時間（例：30分程度）が想定される（実際の保持時間は公式仕様を確認）
重要な注意：この「90%割引」はキャッシュ読み取り対象の入力トークンに対する割引です。出力トークンやキャッシュ対象外の入力は割引対象外です。アプリケーション全体の総コストが常に90%下がるわけではありません。
プロンプトキャッシュでどれくらい安くなるか（具体的シミュレーション）
前提：共通プロンプト = 100,000トークン（0.1M）を何度も使う場面（例：長いシステムプロンプト、ツール定義）。ここでは「利用回数（初回含む）」で比較します。
利用回数（初回含む） | 通常利用（相対） | キャッシュ利用（相対） | 削減率の目安 |
|---|---|---|---|
1回 | 1.00 | 1.25 | 割高（キャッシュ不要） |
2回 | 2.00 | 1.35 | 約33%削減 |
10回 | 10.00 | 2.15 | 約79%削減 |
100回 | 100.00 | 11.15 | 約89%削減 |
計算式（正規化）：キャッシュ利用（相対値） = 1.25 + (n−1)×0.1（1回分を1.0とした場合）
具体的金額例（Terraの入力$2.50/Mを想定）
- 100kトークン = $0.25（1回）
- 1回：通常 $0.25 / キャッシュ $0.3125（初回書込で高くなる）
- 10回：通常 $2.50 / キャッシュ $0.5375（約79%削減）
- 100回：通常 $25.00 / キャッシュ $2.7875（約89%削減）
要点：初回は書き込みコストがかかるため単発処理では割高。2回以上の再利用からメリットが発生し、回数が増えるほど入力トークンコストは最大で約90%小さくなります（入力トークンに限る）。
キャッシュすべきプロンプト・すべきでないプロンプト
プロンプト要素 | キャッシュ推奨度 | 理由 |
|---|---|---|
システムプロンプト | 高 | 多くのリクエストで共通化しやすい |
ツール定義（エージェント） | 高 | エージェントで何度も使われる |
固定の業務ルール／禁止事項 | 高 | 組織単位で共通化可能 |
RAGの共通説明文 | 中〜高 | ナレッジ説明などは再利用可能 |
ユーザー個別質問 | 低 | 毎回変わるためキャッシュ不向き |
最新検索結果などの鮮度要素 | 低〜中 | 更新頻度によりキャッシュ寿命に注意 |
個人情報を含む入力 | 要注意 | ガバナンス/保存ポリシーと相談が必要 |
Bedrock Responses APIでの実装イメージ（概念例）
以下はあくまで概念的な擬似コードとフローです。APIパラメータ名・モデルID・キャッシュ指定方法は実装前に必ずAWS公式ドキュメントで確認してください。
実装ステップ（ステップ・バイ・ステップ）
- 要件定義：ユースケースごとに品質要件・遅延要件・コスト目標を定める。
- キャッシュ設計：どの入力をキャッシュするか（システム/ツール/固定ルール）を分離する。
- PoC実装：Terraをベースに、キャッシュON/OFFでコスト・レイテンシ比較を実施。
- 計測設計：キャッシュヒット率、入力/出力トークン数、レイテンシ、エラー率を収集する。
- モデルルーティング：軽量処理はLuna、失敗/低信頼スコアはSolへフォールバックする仕組みを実装。
- 本番展開：SLOを定め段階的にロールアウト、監査・アラートを整備する。
概念的なリクエスト構造（擬似）
// 概念例（実際のフィールド名はAWS公式を参照）
{
modelId: "gpt-5.6-terra-bedrock",
messages: [
{ role: "system", content: "...長いシステム指示...", cacheHint: { enable: true, key: "org-v1-sys" } },
{ role: "tool_def", content: "...ツール定義...", cacheHint: { enable: true, key: "agent-v1-tools" } },
{ role: "user", content: "...ユーザーの質問..." }
],
responseMode: "non-stream" // or "stream"
}
注：上の cacheHint は概念例です。実際のキャッシュ指定方法・レスポンスメタはAWSの最新仕様に従ってください。
ユースケース別：Sol / Terra / Lunaの選び方
ユースケース | 推奨モデル | 理由 |
|---|---|---|
高度なコーディングエージェント | Sol | 複雑推論・長期タスクに強い |
セキュリティ分析 | Sol | 誤判定のリスクを下げたい場合 |
社内ナレッジQA / RAG | Terra | 品質とコストのバランスが良い |
営業メール生成 | Terra / Luna | 品質要件により使い分け |
議事録要約・大量分類 | Luna | 低コストでスループット重視 |
モデルルーティングでコスト最適化する設計パターン
- 基本ライン：Terraをデフォルト、軽量処理はLuna、難易度高や低信頼時にSolへエスカレーション。
- 2段階実行：最初にTerra/Lunaで試し、信頼スコア低下時にSolで再実行（コスト増を限定）。
- 固定部分はキャッシュ、動的部分は都度送信で分離。
OpenAI API直利用とBedrock利用の比較（判断軸）
Bedrockが向いているケース
- AWS中心の既存基盤（請求・監査・IAMを統合したい）
- Bedrock上で複数モデルを組み合わせて比較・運用したい
- AWSのコミットメントや契約条件を活用したい
OpenAI直利用が向いているケース
- 最新機能や最速提供を優先したい（Bedrock対応が遅れる可能性あり）
- AWSに依存しないマルチクラウド設計を重視する場合
BedrockでGPT-5.6を使う際の注意点（実務チェック）
- 対応リージョン：必ず利用リージョンでの提供状況を確認する。
- クォータ／レート制限：本番開始前に引上げ申請を検討する。
- コンテキスト長・マルチモーダル対応：必要な入力サイズ・画像対応などの仕様差分を確認。
- ストリーミング：クライアント側実装（バックプレッシャー、再試行）を整備。
- 出力トークンコスト：出力トークンはキャッシュ割引対象外の可能性が高いため、長文生成はコスト試算必須。
- ガバナンス：個人情報や機密データの取り扱いポリシーを運用に落とし込む。
既存Bedrockモデルから移行すべきか（判断のコツ）
移行は「置き換え」よりも「追加検証」が原則。A/Bテストで品質・速度・コストを同条件で評価し、業務ごとに最適なモデルを選定してください。
導入前チェックリスト（短縮版）
- 対応リージョンの確認
- 必要クォータの申請・引上げ
- モデル別の用途定義（Terra基準、Luna/ Solのルール）
- キャッシュ対象の分離とキー設計
- キャッシュヒット率・入力/出力トークン計測の実装
- CloudWatch/CloudTrailで監査・アラートを設定
- 個人情報・機密データの取扱いポリシー確認
- PoC → A/Bテスト → 段階的ロールアウトの計画
ステップ・バイ・ステップ（導入の流れ）
- ユースケースごとに品質とコスト目標を定義する。
- TerraでPoC（キャッシュON/OFF、ヒット率計測）。
- 計測データをもとにモデルルーティングのポリシーを設計。
- 本番前にクォータ・ログ設計・アラートを整備。
- 段階的にユーザー数を増やし、SLO確認後に全面展開。
FAQ（よくある質問）
Q1. 「90%削減」は本当に総コストが90%下がるのですか？
A1. いいえ。90%はキャッシュ読み取り対象の入力トークンに対する割引率の目安です。出力トークンやキャッシュ対象外の入力は通常料金が発生するため、アプリケーション全体の総コストが常に90%下がるわけではありません。
Q2. どのタイミングでキャッシュが有利になりますか？
A2. 初回は書き込みコスト（約1.25倍）で割高になります。2回目以降で効果が出始め、利用回数が増えるほど入力コストは大きく下がります（表参照）。エージェントやRAGの共通文言は典型的なキャッシュ候補です。
Q3. 個人情報を含む入力をキャッシュしてよいですか？
A3. 原則として慎重に。保存ポリシー、暗号化、保持期間、アクセス制御を設計し、法務・セキュリティと合意した上で行ってください。場合によってはキャッシュ対象から除外する方が安全です。
Q4. Bedrockのキャッシュヒット率はどう計測すればよいですか？
A4. 公式でヒット/ミスのメタ情報が提供されればそれを利用し、提供されない場合はアプリケーション側で「キャッシュ対象キー」「リクエスト回数」「レスポンス時間」をログに取り、ヒット推定を行います。
最後に（重要な注記）
本記事の料金・仕様・パラメータは執筆時点の公開情報をもとに整理しています。モデルID、提供リージョン、APIのパラメータ名、プロンプトキャッシュの挙動・保持時間などは変更される可能性があるため、実装前に必ずAWS公式ドキュメントおよびOpenAIの公開情報で仕様を確認してください。
まとめ
GPT-5.6（Sol / Terra / Luna）はBedrockユーザーにとって有力な追加選択肢です。実務ではTerraを基準に検証を始め、軽量処理はLuna、高難度処理はSolへルーティングするのが現実的。プロンプトキャッシュは入力トークンコストを大幅に下げる強力な手段ですが、出力トークンは別途コスト計算が必要です。PoC→A/Bテスト→段階的ロールアウトで安全に導入してください。
