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

9 つのアンチパターンを避ける ── PT 無駄買いから max_tokens 未設定まで

2026/06/04

9 つのアンチパターンを避ける ── PT 無駄買いから max_tokens 未設定まで

対象読者：本シリーズ全章を読んできた読者。設計判断のチェックリストとして使いたい読者難易度：★★★☆☆（Tips・アンチパターン）想定読了時間：約 50 分関連章：第 11〜15 章（各論で予告した内容の集約）/ 第 18 章（判断ポイント）

公式 docs には書かれていない「現場の失敗」

前章では、住信 SBI ネット銀行・セゾンテクノロジー・Toyota・Pfizer といった成功事例を読み解いた。だが本番運用の本当の難しさは、成功事例の裏側にある。

現場の失敗事例は、公式 docs にはほとんど書かれていない。だが、AWS Blog・コミュニティ・登壇資料・DevelopersIO・サードパーティの分析記事は、それを記録している。

「Provisioned Throughput を 1 か月コミットで買って失敗した」「max_tokens を未設定にしてスロットルが多発した」「Mask モードで PII を消したつもりが、Model Invocation Logs に原文が残っていた」── これらは公式ドキュメントを丁寧に読んでも、目立つ場所には書かれていない。書かれていても「設計者が読み解くべき性質のもの」として、警告ではなく仕様の一行に紛れ込んでいる。

本章では、第 11 章から第 15 章までで各論的に予告してきたアンチパターンを 9 個に集約する。すべて Zenn 原則 11 の「症状 / 根本原因 / 脱出法」3 段構成で整理した。読み終えた後、自分の現場で「これは #N の症状だ」と気付けるようになることがゴールだ。

なぜ集約するか。ここで挙げる 9 個は、起きてから直すことが極めて高くつく性質を共通して持っているからだ。コストの返金は効かないし、ハルシネーションで失われたユーザーの信頼は戻らない。設計段階で避けるしかない。

アンチパターン #1：必要のない Provisioned Throughput を購入する

回収する伏線：第 15 章「コストを設計する」で示した「PT 損益分岐 80〜85%」の核心数値。

症状

1 か月コミットで Provisioned Throughput（PT）を購入した
実利用率が 30〜40% しか出ない
月末に On-Demand で叩いた場合より高い請求が来る
「高額なため何度も再トライが出来ずに実際の選択は断念した」（DevelopersIO 寄稿の体験記）

根本原因

「将来のスケールに備える」「ピーク時の保険」という想像で買ってしまう。Provisioned Throughput は 稼働率 80〜85% が損益分岐で、60% を下回ると確実に損する設計になっている。さらに 1 か月コミットは早期解約しても残り期間が全期間請求される。「On-Demand より一律安くなる」訳ではなく、「常に上限近くまで使い切れるなら安くなる」のが PT だという理解が抜けている。

これは値段の問題というより、価格モデルの非対称性の問題だ。On-Demand はトークン課金で「使った分だけ」払うが、PT は時間課金で「予約した分だけ」払う。両者は同じ単位で比較できない。

脱出法

まずは On-Demand + Cross-Region Inference（CRIS）で限界を確認する。Geographic CRIS なら各リージョンのクォータが独立して使えるので、ほとんどのワークロードは On-Demand でスケールする
安定して 80% 以上の稼働率が出てから PT を検討する。Application Inference Profile に tag を付けて、Cost Explorer で実測値を週次で見る
6 か月コミットは 20〜40% 割引が乗るが、稼働率の見通しが立つまで 1 か月コミットで様子見してから移行する
PT 検討段階でも、最小 MU（Model Unit）数を AWS 営業窓口に確認する。最新モデルの MU 単価は流動的で、公開資料からだけでは判断できない

出典：Amazon Bedrock のプロビジョンドスループットにおける最小請求単位を調べてみた (DevelopersIO)、AWS Bedrock Pricing Guide (InventiveHQ)、On-Demand Tiers – Amazon Bedrock。doit.com / cloudburn.io 由来の数値はサードパーティブログによる概算で、AWS 公式の発表値ではないことに注意。

アンチパターン #2：Cross-Region Inference を理解せずに使う / 使わない

回収する伏線：第 14 章「セキュリティを設計する」で触れたデータ主権要件、第 15 章で触れた Global CRIS の 10% 割引、付録 A のマルチリージョン設計。

症状

症状 A：レイテンシ重視で同一リージョン直叩きにしたら ThrottlingException が頻発した
症状 B：規制データを Global CRIS に流してしまい、コンプライアンス担当から「データがどのリージョンに送られたのか証明できるか」と詰められた

根本原因

CRIS には性質の異なる 2 種類がある：

種別	範囲	価格	データ主権
Geographic CRIS	US 限定 / EU 限定 / APAC 限定 / JP 限定	呼び出し元リージョン価格、追加なし	遵守
Global CRIS	全コマーシャルリージョン横断	呼び出し元価格から約 10% 削減	緩い

「ルーティングコストがゼロで各リージョンのクォータが独立している」「Global は約 10% 安いが Geographic は規制対応」── この 3 つの性質を理解せず、目の前のレイテンシまたは目先のコストだけで判断してしまう。「同一リージョン直叩き = 速い」「Global = 安い」という単純な構図で動くと、両方の症状を踏む。

脱出法

データ主権要件を最初に確認する。金融・医療・公共向けなら JP-only や APAC-only といった Geographic CRIS を選ぶ
それ以外は Global CRIS を選んで 10% 削減 + スループット倍化を享受する
Application Inference Profile で「実際にどのリージョンが使われたか」を可視化する。Cost and Usage Report で region 列を必ず見る
どちらの CRIS を選んだかは IAM ポリシーで強制する（bedrock:InvocationType 等の条件キーが使える文脈では、それで縛る）

出典：Cross-Region Inference with Amazon Bedrock (AWS Builder Center)、Global cross-Region inference - Amazon Bedrock。詳細な実装は 付録 A で扱う。

アンチパターン #3：Knowledge Bases のチャンキングを Default で済ませる

回収する伏線：第 8 章「Knowledge Bases で RAG を組み立てる」で触れた「FIXED_SIZE 512 トークン・overlap 20% から始める」というスタート地点。

症状

本番投入後に「関係ない情報が混ざる」「最重要のドキュメントが Top-K に出てこない」というクレームが多発する
評価指標が PoC 時点と乖離してくる（PoC では Recall が高かったのに、本番ドキュメントが増えると落ちる）
セマンティックチャンクを試したら、技術文書で 1 MB 制限に引っかかって取り込みが失敗した

根本原因

Default の固定チャンクサイズはどの文書にも最適にはならない。API リファレンスは小さいチャンクで精密に、ストーリー性のある文書は大きいチャンクで文脈ごと、というように 文書の性質に応じて変えるべき だ。さらに「Default のまま」で何より問題なのは、評価する仕組みを先に持っていないことに気付かないまま投入してしまう点だ。チャンキングを変えても、変えた効果を測れない。

セマンティックチャンクの 1 MB 制限は公式ドキュメントの仕様欄に書かれているが、技術文書では普通に超えるサイズなので、知らずに使うと取り込み段階で失敗する。

脱出法

**「チャンキングよりまず評価」**を肝に銘じる。LLM-as-a-Judge で retrieval quality を測る基盤を先に作る（ベンチマーク結果 1 つよりも、評価基盤 1 つの方が遠くまで行ける）
FIXED_SIZE 512 トークン・overlap 20% から始めて評価しながら調整する
ハイブリッド検索（ベクトル + キーワード）+ クエリリフォーミュレーションでブーストする。セゾンテクノロジーは Knowledge Bases 単体比で +22% の精度向上 を達成している
日本語特有のトークナイズ（sudachi など）を組み込む

文書タイプ別のチャンクサイズ目安：

文書タイプ	推奨チャンクサイズ
API リファレンス	200〜500 トークン
一般ドキュメント	400〜800 トークン
ストーリー文書	700〜1,200 トークン

出典：Real Benchmark: 5 Chunking Strategies in Amazon Bedrock Knowledge Bases (Gerardo Arroyo)、Evaluate and improve performance of Amazon Bedrock Knowledge Bases、セゾンテクノロジー HULFT サポート Advanced RAG 事例。

アンチパターン #4：Guardrails を後付けする

回収する伏線：第 11 章「Guardrails で安全性を組み込む」で示した「Detect モードから段階的に有効化する」の核心。

症状

本番リリース後にプロンプトインジェクションや不適切応答事故が起きてから、ようやく Guardrails を導入する
既存ユーザー体験への影響が読めないまま Block で強制適用する → 正常な質問まで弾かれて炎上する
「Guardrails はレイテンシが増えるから後でいい」と言ってリリースまで入らなかった

根本原因

「Guardrails は精度が下がる / レイテンシが増える」という誤解で後回しにしている。実際は Detect モードという、ブロックせずトレースに結果のみ記録するモードが用意されており、本番トラフィックに対して段階導入できる設計になっている。

もう一つの根本原因は、Guardrails を 開発者ごとの実装に任せていることだ。誰かがガードレール ID を忘れて呼び出せば、その経路だけ素通りになる。これは設計の問題というより、強制機構の問題だ。

脱出法

Day 1 から Detect モードで導入する。本番トラフィックを観測しながら、誤検知のチューニングをしてから Block / Mask に切り替える
Content Policy と Prompt Attack Filter は最低限すべての本番に入れる。AWS は「すべての本番デプロイで推奨」と明記している
IAM ポリシーで Guardrails を強制する。bedrock:GuardrailIdentifier 条件キーで「Guardrails を付けない呼び出し」を一律拒否する
ApplyGuardrail API で SageMaker やサードパーティモデルにも同じ Guardrails を適用する。モデル呼び出しから Guardrails を分離できる設計を最初から取る

IAM 強制の例（第 14 章のおさらい）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "bedrock:InvokeModel",
      "Resource": "*",
      "Condition": {
        "Null": { "bedrock:GuardrailIdentifier": "true" }
      }
    }
  ]
}

出典：Build safe generative AI applications like a Pro: Best Practices with Amazon Bedrock Guardrails、Enforcing Guardrails in Amazon Bedrock using IAM (AWS Builder Center)。

アンチパターン #5：評価なしで本番投入する / Model Evaluation だけで満足する

回収する伏線：第 12 章「Day 1 から評価を組み込む」で繰り返した「Model Evaluation だけではエージェントの 3/4 が不可視」。

症状

「PoC でうまく動いたから本番出した」結果、本番でエッジケースが続発する
日付の解析ミス、略語の処理ミス、想定外の言い回しでツールを誤呼び出し
Bedrock の Model Evaluation Job を流したから「評価済み」だと考えて、運用後の継続評価をしていない
Mask モードを入れたから PII は安心だと思っていた ── しかし Model Invocation Logs を見たら入力プロンプトに原文が残っていた（Mask モード誤解：後述）

根本原因

評価を「リリース前の儀式」だと考えていることが第一の原因。LLM アプリケーションは、入力分布が変われば挙動も変わる。評価は Day 1 から運用に組み込み続けるものだ。

第二の原因は、Bedrock の Model Evaluation Job だけで完結したと考えてしまうこと。Model Evaluation はその名の通り モデル単体しか測らない。エージェントは Model + Action Group + Knowledge Base + Guardrails の 4 構成要素でできているので、Model Evaluation だけだと 3/4 は不可視のままになる。

Mask モード誤解（重要なサブパターン）

Guardrails の Sensitive information filter で Mask モードを有効にすると、応答内の PII（個人情報）は [NAME] [EMAIL] のようにマスクされる。ところが ──

Mask モードでも、Model Invocation Logs の input フィールドにはユーザーが入力した原文がそのまま残る。

応答だけを見ると PII は消えているように見えるが、ログ収集系には原文が流れている。これは Guardrails の仕様であり、バグではない。Mask モードは 応答を加工するものであって、ログを加工するものではない。

この落とし穴の脱出法は、CloudWatch Logs Data Protection で別途マスクを適用するか、Model Invocation Logging のフィルタを使ってログレベルで再処理することだ。第 11 章でも第 13 章でも繰り返し触れたが、評価チェックリストでも必ず項目化する。

脱出法

AgentCore Evaluations を Day 1 から導入する。LLM-as-a-Judge と OpenTelemetry Gen-AI セマンティクスでトレースを取る
評価軸を 3 つに分離する：(a) Action Group invocation correctness、(b) Knowledge Base retrieval quality、(c) Guardrail precision / recall（adversarial + benign の両方）
高ボリュームの本番には Lambda ベースのコード型評価器を使う。LLM 評価器は精度が高いが、連続スコアリングでは圧倒的にコストがかさむ
Mask モードを過信せず、Model Invocation Logs を別系統でレビューする

出典：Build reliable AI agents with Amazon Bedrock AgentCore Evaluations、Evaluating AWS Bedrock Agents in 2026 (Future AGI)、Bedrock AgentCore Evaluations: LLM-as-a-Judge in Production (Gerardo Arroyo)、Detect and filter harmful content by using Amazon Bedrock Guardrails (Sensitive information filters)。

アンチパターン #6：`max_tokens` を未設定にする

回収する伏線：第 6 章「Converse API で最初のリクエストを送る」で軽く触れ、第 13 章「観測を設計する」で CloudWatch メトリクスとの関係を見せ、本章 #6 で集約する。3 章またぎで繰り返してきた一番大きな伏線。

症状

通常のチャットを 500 RPM 程度で叩いていたら ThrottlingException が頻発する
実際の出力は数百トークンしかないのに、TPM クォータをすぐ食い潰す
CloudWatch メトリクスの InvocationThrottles だけが伸びていて、InputTokenCount も OutputTokenCount も低いまま

根本原因

max_tokens 未設定だと、モデル最大値が予約される。Claude Sonnet 4 系では数万トークン規模（具体的な上限は最新の公式 docs を要確認）。Bedrock の TPM（Tokens Per Minute）クォータは「入力 + 出力上限」で予約計上されるため、1 リクエストごとに「使いもしないクォータ」を数万トークン分も先取りしてしまう。

AWS 公式が 「最も多いスロットリングの原因」 と明言しているのがこのパターンだ。「動くものを書く」段階では気付きにくく、本番トラフィックが乗って初めて顕在化する。

脱出法

「悪い例 → 良い例」の対比で示す。

// ❌ 悪い例：inferenceConfig を渡さない
// → 実は max_tokens = 64K（モデル最大値）が予約され、
//   TPM クォータを毎リクエスト 64K 食い潰す
import { ConverseCommand } from "@aws-sdk/client-bedrock-runtime";
import { bedrock, MODEL_ID } from "./client.js";

const bad = await bedrock.send(
  new ConverseCommand({
    modelId: MODEL_ID,
    messages: [{ role: "user", content: [{ text: "経費精算の上限額は？" }] }],
    // ⚠ inferenceConfig が無い
  }),
);

// ✅ 良い例：用途ごとに max_tokens を明示する
import { ConverseCommand } from "@aws-sdk/client-bedrock-runtime";
import { bedrock, MODEL_ID } from "./client.js";

const good = await bedrock.send(
  new ConverseCommand({
    modelId: MODEL_ID,
    messages: [{ role: "user", content: [{ text: "経費精算の上限額は？" }] }],
    inferenceConfig: {
      maxTokens: 2000, // 対話用途の初期値。詳細は下の指針表を参照
      temperature: 0.3,
    },
  }),
);

// stopReason が "max_tokens" の場合は応答が途中で切れている可能性がある
if (good.stopReason === "max_tokens") {
  // ログに警告を出し、出力を分割するか maxTokens を上げる
}

用途別の max_tokens 設計指針：

用途	推奨 `max_tokens`	理由
短い要約・分類	500	出力が短く確定している
対話（チャット応答）	1,500〜2,500	長すぎず・短すぎない初期値
コード生成	4,000〜8,000	長文出力が必要、ただし用途別に絞る
長文ドキュメント生成	モデル最大の半分まで	切り上げで安全側に倒す

実効的な意味は次の通りだ。max_tokens をモデル最大値（数万トークン規模、Claude Sonnet 4 系では数十K）に任せると、同時実行できるリクエスト数は数本程度になる。max_tokens を 2K に絞れば 数十〜100 倍 のリクエスト数を同じ TPM クォータで捌けるようになる（具体的な上限値・クォータ値は流動的なため、最新は公式 docs / Service Quotas を要確認）。

出典：Optimize your applications for scale and reliability on Amazon Bedrock、Scaling and throughput best practices - Amazon Bedrock、Troubleshoot Amazon Bedrock on-demand resource 429 Throttling error (re:Post)。

アンチパターン #7：観測を後付けする

回収する伏線：第 13 章「観測を設計する」で示した「CloudWatch メトリクスと Model Invocation Logging を Day 1 から」。

症状

本番でエージェントが「何かおかしい」となったとき、ログを見返してもプロンプト・トークン・コストの相関が追えない
問題の再現に数日かかる
「プロンプトを少し変えたら、なぜか月のコストが 2 倍になっていた」というのが、月末請求書で初めて分かる
Mask モード関連の事故（#5 サブパターン）も、観測がないと「いつから原文がログに流れていたか」が追えない

根本原因

「観測は後で入れればいい」と考えている。気付いた頃には大量の利用ログが流れた後で、効果的なデバッグが難しい状態になっている。

アプリケーション側の標準ダッシュボード（HTTP リクエスト数・レイテンシ）だけでは、Bedrock 特有の問題 ── プロンプト変更によるトークン爆発、max_tokens 未設定によるスロットリング、Guardrails 影響、Mask モードのログ漏れ ── が見えない。LLM ワークロード固有のメトリクスは、最初から張っていなければ捕捉できない。

脱出法

CloudWatch メトリクスを Day 1 から取得する：InvocationThrottles、InputTokenCount、OutputTokenCount、InvocationLatency、InvocationsClientErrors
Application Inference Profile に tag を付けて、マルチテナント / マルチアプリでコスト・使用量を分離追跡する
AgentCore Observability で OpenTelemetry の Gen-AI セマンティクスのトレースを保存する。これがあれば「どのプロンプトでどのツールを呼び、何トークン使ったか」をリクエスト単位で追える
Model Invocation Logging で input / output 全文を保存する。ただし PII を含む場合は CloudWatch Logs Data Protection を必ず併用する（#5 Mask モード誤解の脱出経路でもある）
Datadog LLM Observability などサードパーティ連携も検討する

出典：AWS Bedrock Monitoring: Metrics, Challenges & Best Practices (groundcover)、Monitor agents built on Amazon Bedrock with Datadog LLM Observability、Tracking Amazon Bedrock usage and costs per tenant in a multi-tenant environment。

アンチパターン #8：コスト見積もりを失敗する

回収する伏線：第 15 章「コストを設計する」で示した「P95 ベース・ストレージ込み・コスト最適化 4 段ロケット」の核心。

症状

症状 A：「PoC は月数千円だったのに、本番に出したら月数百万円」
症状 B：「Provisioned Throughput を 1 か月コミットしたら、ピーク時しか使わないモデルに固定コストが乗った」（#1 とも合流する）
症状 C：「Knowledge Base が S3 と OpenSearch Serverless とベクトル DB で複合課金されているのを見落とした」
症状 D：「リージョン跨ぎのデータ転送費を計算に入れていなかった」

根本原因

3 つの落とし穴が複合している：

トークン単価だけで見積もり、入出力比率と max_tokens 設定を考慮していない
ストレージ費を忘れる（S3、OpenSearch Serverless、Vector DB、ログ保存）
リージョン跨ぎのデータ転送費を忘れる（CRIS 自体のルーティングコストはゼロだが、関連サービスのデータ転送は別）

さらに、見積もりを 「平均」で行うとスパイクで破綻する。ピーク時間帯の P95 で組まないと、実態と合わない。

脱出法

見積もりは「平均」ではなく「P95」で行う。スパイクが請求を支配する
Application Inference Profile で実測値を取得し、毎週見直す
ストレージ費は S3 Intelligent-Tiering・Glacier・Lifecycle Policy で削減する
コスト最適化 4 段ロケット：
- (a) モデル選定：Haiku で済む 40〜60% を Sonnet で叩かない（住信 SBI モデルの「意図理解＝Haiku、最終判断＝Sonnet」の使い分け）
- (b) Prompt Caching：ヒット率 30% 以上を確認してから導入
- (c) Batch Inference：ナイトリーサマリ・ドキュメントエンリッチメント・評価バッチは 50% オフ
- (d) PT or Flex Tier：稼働率が見えてから検討

数値の出典について：Pfizer のインフラコスト 55% 削減 は AWS Case Study の公式数値。Intelligent Prompt Routing の RAG 用途 63.6% 削減 / 87% Haiku ルーティング は AWS Blog の実測値。一方で 「複合最適化で 40〜60% 削減」「PT 適切利用で 30〜40% 削減」 といった数値は doit.com / cloudburn.io 由来のサードパーティ概算で、AWS 公式の発表値ではない。両者は混同しないこと。

出典：Amazon Bedrock Pricing Explained: What You Need to Know in 2026 (Cloudchipr)、Amazon Bedrock Pricing: Token Rates Hide a $350/Month Trap (Cloud Burn)、Driving Patient-Centric Innovation in Life Sciences Using Generative AI with Pfizer、Use Amazon Bedrock Intelligent Prompt Routing for cost and latency benefits。詳細な見積もりワークシートは 付録 B で扱う。

アンチパターン #9：VPC Endpoint / PrivateLink を使わない

回収する伏線：第 14 章「セキュリティを設計する」で示した「IAM 強制パターン + VPC Endpoint + KMS」の三本柱。

症状

監査で「Bedrock との通信がインターネット越し HTTPS で抜けている」と指摘される
金融・医療・公共向け案件で、ネットワーク経路の証跡を求められて答えられない
「HTTPS だから暗号化されてるし、いいでしょ」で押し切ろうとして却下される

根本原因

「HTTPS だから安全」という単純化。VPC エンドポイント（PrivateLink）を使わないと、通信は AWS のバックボーン外を経由する。暗号化されているとはいえ、経路自体は公衆インターネットを通る。

監査要件によっては「経路がプライベートであることを証明する」ことが要件になる。HTTPS の暗号性とは別の話だ。

脱出法

AWS PrivateLink で Bedrock 用 VPC エンドポイントを作成する（com.amazonaws.<region>.bedrock-runtime など）
IAM ポリシーで aws:SourceVpce 条件を付けて、VPC エンドポイント経由のリクエストのみを許可する
KMS によるカスタマー管理キー（CMK）でデータ暗号化する

IAM での VPC エンドポイント強制（悪い例 → 良い例の対比）：

// ❌ 悪い例：経路を問わず Bedrock 呼び出しを許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "*"
    }
  ]
}

// ✅ 良い例：指定 VPC エンドポイント経由でのみ許可
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

Allow だけだと「指定 VPCE なら使える」になるだけで、別経路を塞げない。**Deny を併記して「指定 VPCE 以外は全部拒否する」**形にして、初めて経路強制になる。

出典：Securing Amazon Bedrock: What Enterprises Need to Get Right (InterWorks)、Security in Amazon Bedrock、みずほ銀行 AWS Summit 登壇（PrivateLink + 大阪リージョン）。

9 アンチパターン分類まとめ

Zenn 原則 11 に従い、症状・根本原因・関連章を分類表にまとめる。

#	アンチパターン	症状	根本原因	関連章
1	必要のない Provisioned Throughput 購入	月末請求が On-Demand より高い	価格モデルの非対称性を理解せず「保険」で買う	ch15
2	Cross-Region Inference の誤用	スロットリング多発 / コンプライアンス指摘	Geographic と Global の性質差を理解していない	ch14 / 付録 A
3	チャンキング Default 放置	RAG 精度低下、評価軸も無い	文書タイプ別最適化と評価基盤の不在	ch08
4	Guardrails 後付け	事故後に Block 強制適用で炎上	Detect モード段階導入を知らない、IAM 強制が無い	ch11 / ch14
5	評価なし投入 / Model Evaluation 過信	エッジケース続発、Mask モード誤解	Model Evaluation は 4 構成のうち 1 つしか測らない	ch11 / ch12 / ch13
6	`max_tokens` 未設定	TPM クォータ即枯渇、スロットリング	未設定だとモデル最大値（64K）が予約される	ch06 / ch13
7	観測を後付け	再現不能、コスト爆発に気付けない	LLM 固有メトリクスは事後では取れない	ch13
8	コスト見積もり失敗	「PoC 月数千円→本番月数百万円」	平均で見積もり、ストレージ・転送費を忘れる	ch15 / 付録 B
9	VPC Endpoint / PrivateLink 未使用	監査で経路指摘	HTTPS と経路プライベートを混同	ch14

設計段階で防げる vs 運用段階で気付く

9 個のアンチパターンを「いつ防げるか」「いつ気付くか」の 2 軸で分類すると、構造が見えてくる。

quadrantChart
    title 9 アンチパターン × 設計で防ぐ / 運用で気付く
    x-axis "運用段階で気付く" --> "設計段階で防げる"
    y-axis "影響：限定的" --> "影響：致命的"
    quadrant-1 "設計で必ず潰す"
    quadrant-2 "運用で監視必須"
    quadrant-3 "運用で発見・是正"
    quadrant-4 "設計でカバー"
    "#1 PT 無駄買い": [0.78, 0.7]
    "#2 CRIS 誤用": [0.7, 0.85]
    "#3 チャンキング Default": [0.35, 0.55]
    "#4 Guardrails 後付け": [0.85, 0.9]
    "#5 評価なし投入": [0.6, 0.92]
    "#6 max_tokens 未設定": [0.9, 0.75]
    "#7 観測後付け": [0.88, 0.8]
    "#8 コスト見積もり失敗": [0.65, 0.78]
    "#9 PrivateLink 未使用": [0.92, 0.65]

右上の象限（設計段階で防げる + 致命的）に集まる #2 / #4 / #5 / #6 / #7 / #9 が、最優先で設計段階で潰すべき項目だ。逆に #3 のチャンキング Default は「最初は Default でもよく、評価基盤を作って徐々に最適化していく」性質のもので、運用と設計の中間に位置する。

#1（PT 無駄買い）と #8（コスト見積もり失敗）は 金銭的損失として後から発見されやすいが、発見した時点で コミット期間中の請求は止まらない性質を持つ。これも「気付く」よりは「防ぐ」側に倒すべきものだ。

ここに集約された伏線

本シリーズの第 11 章から第 15 章までで、執筆者は意図的に「これは第 17 章のアンチパターンに繋がる」という予告を散りばめてきた。改めて伏線一覧を示す：

第 6 章 → 第 13 章 → 本章 #6：max_tokens 未設定問題（3 章またぎの最大伏線）
第 11 章 → 第 13 章 → 本章 #5：Guardrails Mask モードの落とし穴
第 11 章 → 本章 #4：Detect モードでの段階導入
第 12 章 → 本章 #5：Model Evaluation だけでは不足
第 13 章 → 本章 #7：観測の Day 1 設計
第 14 章 → 本章 #4 / #9：IAM 強制パターンと PrivateLink
第 15 章 → 本章 #1 / #8：PT 損益分岐とコスト見積もり
第 14 章 / 付録 A → 本章 #2：CRIS のデータ主権

各章で「ここは後でアンチパターンとして集約する」と予告された箇所が、すべてここに集まっている。本章を読み終えた後、第 11 章から第 15 章を再読すると、伏線が回収されていく感覚を持てるはずだ。

次章への接続

ここまで 9 個のアンチパターンを「症状 / 根本原因 / 脱出法」の 3 段で整理してきた。これらに共通する性質は次の一文に集約される：

起きてから直すことが極めて高くつく。コストの返金は効かない、ユーザーの信頼は戻らない、監査指摘の証跡は残る。だから設計段階で避けるしかない。

では、Production Ready の設計段階で「何を判断し、何を確認すれば、これらのアンチパターンを未然に防げるのか」── 第 18 章（エピローグ）では、本シリーズ全体を振り返り、Production Ready の判断ポイントを 15 個に集約する。第 1 章プロローグで提示した「3 つの壁」を、15 個の具体的な判断項目として最終的に回収する。

章末まとめ

9 個のアンチパターンはすべて「症状 / 根本原因 / 脱出法」の 3 段で整理した。自分の現場で「これは #N の症状だ」と気付けることが本章のゴール

max_tokens 未設定は AWS 公式が「スロットリングの最大原因」と明言。本シリーズで 3 章またぎ（ch06 → ch13 → ch17）で繰り返し強調してきた最大伏線

Mask モード誤解：Guardrails の Mask は応答を加工するが Model Invocation Logs の input には原文が残る。CloudWatch Logs Data Protection で別途対処する

PT 損益分岐は稼働率 80〜85%。60% 以下なら必ず損する。1 か月コミットでも「保険」で買ってはいけない

設計段階で防げる #2 / #4 / #5 / #6 / #7 / #9 が最優先で潰すべき項目。運用段階で気付く頃には損失が確定している

サードパーティ概算（doit.com / cloudburn.io 等）と AWS 公式数値（Pfizer 55% 削減・Prompt Routing 63.6% 削減等）は混同せず別物として扱う

次章では Production Ready の判断ポイントを 15 個に集約し、第 1 章で提示した「3 つの壁」を最終的に回収する

9 つのアンチパターンを避ける ── PT 無駄買いから max_tokens 未設定まで

公式 docs には書かれていない「現場の失敗」

アンチパターン #1：必要のない Provisioned Throughput を購入する

症状

根本原因

脱出法

アンチパターン #2：Cross-Region Inference を理解せずに使う / 使わない

症状

根本原因

脱出法

アンチパターン #3：Knowledge Bases のチャンキングを Default で済ませる

症状

根本原因

脱出法

アンチパターン #4：Guardrails を後付けする

症状

根本原因

脱出法

アンチパターン #5：評価なしで本番投入する / Model Evaluation だけで満足する

症状

根本原因

Mask モード誤解（重要なサブパターン）

脱出法

アンチパターン #6：max_tokens を未設定にする

症状

根本原因

脱出法

アンチパターン #7：観測を後付けする

症状

根本原因

脱出法

アンチパターン #8：コスト見積もりを失敗する

症状

根本原因

脱出法

アンチパターン #9：VPC Endpoint / PrivateLink を使わない

症状

根本原因

脱出法

9 アンチパターン分類まとめ

設計段階で防げる vs 運用段階で気付く

ここに集約された伏線

次章への接続

アンチパターン #6：`max_tokens` を未設定にする