試作の生成 AI アプリはすぐに動きます。詰まるのはその後です。「回答の正しさをどう保証するのか」「個人情報が出たら誰の責任か」「月の費用はいくらになるのか」「遅いと言われたらどこを直すのか」。レビューの場で聞かれるこれらの問いは、モデルの性能ではなく設計の問いです。
この記事は Amazon Bedrock を前提に、本番に出すときの判断の軸と、要件が変わると答えがどう変わるかを、比較表と判断の順番で示します。
この記事の結論
- 生成 AI アプリの設計は、品質・遅延・コスト・安全性の4つの要件を先に数字や基準で書き出し、そこから逆算して決めます。
- モデルは評価データで「基準を満たす最小のモデル」を選び、Converse API で後から差し替えられるようにしておきます。
- 適応の手段は、プロンプト → RAG → ファインチューニングの順に、手前で基準に届かないことを確かめてから進めます。
- RAG の品質はチャンク・埋め込み・検索・再ランクで決まり、検索だけの評価と生成まで含めた評価を分けて測ります。
- 推論の買い方は即時性と流量の安定さで選び、呼び出しログとトークン数のメトリクスで費用と失敗を見続けます。
生成 AI の本番設計とは（試作と何が違うか）
試作と本番の違いは、「うまく答えなかったときに何が起きるか」で設計することです。AWS Well-Architected の生成 AI レンズは、モデルの選定、カスタマイズ、評価、デプロイ、継続的な改善を1つのライフサイクルとして扱い、6本の柱ごとにベストプラクティスを置いています。この記事はそのうち、設計の初期に決めないと後から直しにくいものを扱います。
先に書き出す要件は4つです。
FOUR REQUIREMENTS先に書き出す要件
モデルからではなく要件と評価データから逆算する
-
1.品質 — 評価データと合格の基準
どの質問に、どの答えなら合格か。誤りの影響の大きさ
-
2.遅延 — 最初の文字と全体の時間
画面で待たせるのか、非同期で返せばよいのか
-
3.コスト — 1件のトークン数と流量
入力と出力の長さ、件数、流量の波
-
4.安全性 — 出してはいけない内容と個人情報
扱わない話題、個人情報の扱い、人の承認が要る操作
| 要件の変化 | 答えがどう変わるか |
|---|---|
| 回答の誤りが業務の損失に直結する | RAG で根拠を渡し、出典を示し、影響の大きい操作の前に人の承認を入れる |
| 画面で待たせられない | 小さいモデル・ストリーミング応答・共通部分のキャッシュを優先する |
| 即時性は要らないが量が多い | バッチ推論に回し、同期の呼び出しをやめる |
| 個人情報を含む文書を扱う | ガードレールで入出力を検査し、呼び出しログの保護まで設計に入れる |
| 知識が毎日変わる | ファインチューニングではなく RAG で鮮度を保つ |
判断の順番は、要件を書く → 評価データを作る → モデルを選ぶ → 適応の手段を選ぶ → 安全策を置く → 買い方を選ぶ → 監視するです。評価データが2番目にあるのが要点で、評価データの無いまま「どのモデルが良いか」を議論すると、声の大きい人の体感で決まります。
モデルはどう選ぶか（品質・遅延・コストの三角）
モデル選びは、品質・遅延・コストの三角形のどこに立つかを決める作業です。大きいモデルは難しい推論に強い一方、応答が遅く、トークンあたりの費用も高くなります。
「基準を満たす最小のモデル」から選ぶ
選び方の型は、評価データと合格の基準を先に決め、基準を満たすモデルのうち最も小さく速いものを選ぶ、です。分類やラベル付けのように出力が短い処理は、小型のモデルで基準に届くことが多く、出力のトークン数をラベルだけに絞ればさらに費用が下がります。
候補の比較には、Amazon Bedrock のモデル評価が使えます。自分のデータセットと指標で機械的に比べる自動評価、別のモデルに基準で採点させる LLM-as-a-judge、自社の担当者が採点する人手の評価を選べます。丁寧さや有用さのように指標にしにくい品質は LLM-as-a-judge で量をこなし、専門家の判断が要るものは人手の評価に回す、という分担になります。
差し替えられる形で呼ぶ
モデルは半年もすれば新しいものが出ます。本番の設計で大事なのは、最初に選んだモデルの良し悪しより、後から差し替えられることです。Bedrock の Converse API はモデル共通のメッセージ形式で呼び出せるので、モデルを替えてもアプリのコードの修正が小さく済みます。InvokeModel はモデルごとに本文の形式が違うため、差し替えのたびに組み立て直しが要ります。
質問の難しさがばらつく用途では、簡単なものを小型のモデル、難しいものを高性能なモデルに振り分けると、品質を保ったまま費用を下げられます。振り分けをアプリで組むほか、Bedrock のインテリジェントプロンプトルーティングが同じモデルファミリーの中で振り分けます。ただし公式ドキュメントは英語のプロンプトに最適化されていると明記しているので、日本語の用途では評価データで確かめてから採用します。
| 要件 | 寄せる頂点 | 選び方 |
|---|---|---|
| 判断の誤りが許されない（審査・診断の補助） | 品質 | 大きいモデル＋評価の基準を厳しく。遅延は非同期で吸収する |
| 画面で対話する（社内チャット・接客） | 遅延 | ストリーミング応答で最初の文字を早く出す。基準を満たす最小のモデル |
| 件数が多い定型処理（分類・抽出） | コスト | 小型のモデル、出力を短く、temperature を低くして結果を揃える |
CHECK 1ここまでの確認
社内の問い合わせ分類を生成 AI で作る。評価データで小型モデルも大型モデルも基準を超えた。本番でどちらを選ぶのが筋か?
答えと解説
答え: 2. 基準を満たすうちで、いちばん小さく速いモデルを選ぶ
モデルは「基準を満たす最小のもの」から選びます。大きいモデルは遅延とトークンの費用が増えるだけで、満たした基準以上の価値を生みません。「モデルはどう選ぶか」の章を読み直してください。
プロンプト → RAG → ファインチューニングの順に検討するのはなぜか
基盤モデルを自分の用途に合わせる手段は、手軽なものから順に、プロンプトの工夫、RAG、ファインチューニングです。この順に検討するのは、後ろほど作るもの・評価するもの・作り直す頻度が増えるからです。
ADAPT IN ORDER適応の手段の順番
手前で基準に届かないと確かめてから次へ進む
-
01
プロンプトの工夫 — 指示・例示・出力形式
変更はすぐ反映。テンプレートと版を管理して評価する
-
02
RAG — 外部の知識を検索して渡す
知識が変わる・出典が要るとき。モデルは作り直さない
-
03
ファインチューニング — 入力と出力の組で学ばせる
文体・形式・振る舞いを揃えたいとき。知識の注入には向かない
-
04
継続的な事前学習 — ラベルなしデータで領域に慣れさせる
専門用語の多い領域で全体の理解を上げたいとき
プロンプトで届くかを先に確かめる
役割と制約をシステムプロンプトに書き、出力形式を指定し、入出力の例を数件見せる（few-shot）。文書を渡すときは XML タグなどで囲んで指示と分ける。これだけで基準に届く用途は少なくありません。Bedrock のプロンプト管理でテンプレートと版を管理しておくと、プロンプトの変更も評価とリリースの対象にできます。
知識が足りないなら RAG
モデルが社内の規程や最新の在庫を知らないのは、性能の問題ではなく知識の問題です。外部のデータを検索してプロンプトに加える RAG なら、モデルを作り直さずに最新の文書を反映でき、回答に出典を添えられます。AWS Prescriptive Guidance の比較も、文書が頻繁に変わる用途や出典が要る用途では RAG を、組織の文体や形式に合わせたい用途ではファインチューニングを挙げています。
振る舞いを変えたいならファインチューニング
ファインチューニングは、入力と出力の組（ラベル付きのデータ）で、文体・形式・タスクの振る舞いを覚えさせる手段です。知識の注入には向かず、知識が変わるたびに作り直しが要ります。ラベルの無い大量の社内文書で領域の言い回しに慣れさせたいなら継続的な事前学習、大きいモデルの能力を特定の用途に絞って小さいモデルに移したいならモデル蒸留、と目的で選び分けます。
| 手段 | 何を変えるか | 向く要件 | 重さ |
|---|---|---|---|
| プロンプトの工夫 | 指示・例・出力形式 | まず全部。形式を揃えたい | 変更はすぐ反映。評価だけ回す |
| RAG | 渡す知識 | 知識が変わる・出典が要る | 取り込み・検索の部品と評価が増える |
| ファインチューニング | 振る舞い・文体 | 形式や文体をプロンプトで揃えきれない | 学習データの準備と再学習、モデルの管理 |
| 継続的な事前学習 | 領域への慣れ | 専門用語の多い領域で全体の理解を上げたい | ラベルなしの大量データと学習 |
CHECK 2ここまでの確認
毎日変わる在庫や規程をもとに答えさせたいとき、最初に検討すべき手段はどれか?
答えと解説
答え: 2. 外部のデータを検索してプロンプトに渡す RAG
変わりやすい知識は RAG で渡します。ファインチューニングは文体や出力形式のような「振る舞い」を覚えさせる手段で、知識の鮮度を保つには作り直しが要ります。「プロンプト → RAG → ファインチューニング」の章を参照してください。
RAG の品質は何で決まるか
RAG の回答の質は、生成モデルの前にある検索の部品でほぼ決まります。検索が正しい文書を取れていなければ、どんなに大きいモデルでも正しく答えられません。品質を決めるのは次の4つです。
チャンク・埋め込み・検索・再ランク
- チャンク（文書の分け方）: Amazon Bedrock Knowledge Bases は、既定・固定長・階層・セマンティック・分割しない、から選べます。条項どうしが参照し合う契約書のように文脈が長い文書は、大きいチャンクと小さいチャンクを親子で持つ階層の分け方が合いやすく、話題の切れ目で分けたいならセマンティックの分け方を試します。
- 埋め込み（ベクトル化）: 文の意味をベクトルにするモデルです。テキストと画像を同じ空間で比べたいならマルチモーダルの埋め込みモデルを選びます。埋め込みモデルを替えると取り込み直しが要るので、最初に評価してから決めます。
- 検索: ベクトルの近さで探すセマンティック検索に加え、ベクトルストアによっては原文のキーワード検索と組み合わせるハイブリッド検索を選べます。製品番号や型番のような語は、意味の近さよりキーワードの一致が効きます。メタデータでの絞り込み（部署・文書の種類・日付）も、検索の精度と権限の両方に効きます。
- 再ランク: 検索で取った候補を、質問との関連度で並べ替える再ランクのモデルを挟めます。候補を多めに取って再ランクで絞ると、プロンプトに入れる文書の質が上がります。
評価は検索と生成を分ける
RAG の評価は、Bedrock の評価機能で2種類に分けて行えます。検索だけの評価は、取れた文脈が質問に関連しているか・必要な情報を網羅しているかを見ます。検索と生成の評価は、回答が正確か・取れた文脈に忠実かを見ます。分けて測ると、「検索が外している」のか「取れているのに生成が外している」のかが分かり、直す場所が決まります。
本番では、評価用のデータセットをプロンプト・チャンクの設定・モデルの変更のたびに CI/CD の中で回し、基準を下回ったらリリースを止めます。生成 AI レンズも、評価を継続的に回すことと、変更ごとの品質の確認を運用のベストプラクティスに挙げています。
CHECK 3ここまでの確認
RAG の回答が的外れなとき、検索と生成のどちらが原因かを切り分ける評価の組み方はどれか?
答えと解説
答え: 1. 検索だけの評価と、検索と生成をまとめた評価を分けて行う
検索だけの評価で「正しい文書を取れているか」を、検索と生成の評価で「取れた文書から正しく答えたか」を見ます。分けないと、直す場所が分かりません。「RAG の品質は何で決まるか」の章に戻ってください。
ガードレールと個人情報はどこで止めるか
安全策は「モデルが賢いから大丈夫」ではなく、モデルの外側に置きます。Amazon Bedrock Guardrails は、有害な内容のフィルター、扱わない話題（拒否トピック）、禁止語、プロンプト攻撃の検出、個人情報の検出、そして回答が取れた文脈に基づいているかを見る文脈の根拠チェックを、モデルとは独立に設定できます。個人情報は、検出したらブロックするか、マスクして通すかを選べ、社員番号のような独自の形式は正規表現で足せます。
ApplyGuardrail API を使うと、モデルを呼ばずに任意の文章をガードレールで検査できます。RAG なら検索の前にユーザーの入力を検査し、生成の後に回答を検査する、という二段の置き方ができます。
個人情報で起きやすい事故の型
- ガードレールで回答はマスクしたのに、呼び出しログにプロンプトと回答の本文がそのまま残っている。ログの保存先の暗号化と閲覧権限まで設計に入れる。
- ファインチューニングの学習データに氏名や電話番号が残っている。学習データの個人情報はモデルに取り込まれうるので、Amazon Comprehend などで検出してマスクしてから学習させる。
- RAG の検索対象に、本来その利用者が読めない文書が入っている。メタデータでの絞り込みや、元の文書のアクセス制御を生かせる検索の仕組みを使う。
データの扱いについて、Bedrock はプロンプトと応答を基盤モデルの学習に使わず、モデルの提供元とも共有しないと公式に説明しています。そのうえで、利用者の側で決めることが残ります。推論の操作を IAM ポリシーで承認済みのモデルの ARN に限ること、インターフェイス VPC エンドポイントでインターネットを経由せずに呼ぶこと、カスタマーマネージドキーで暗号化の鍵を自社で管理すること、組織として使ってよいリージョンを SCP で縛ることです。
コストとスループットはどう選ぶか
推論の買い方は、即時性が要るかと、流量が安定して多いかの2軸で選びます。
HOW TO BUY INFERENCE推論の買い方を2軸で
即時性が要らないならバッチ、安定した大量なら確保
流量が安定して多い →
バッチ推論
夜間の要約・分類。S3 の入力をまとめて非同期に処理
プロビジョンドスループット
昼夜を通して大量に流れる対話。処理能力を確保する
オンデマンドで足りる
少量の定期処理。ジョブを組む手間に見合わない
オンデマンド＋キャッシュ・分散
波のある対話。共通部分のキャッシュとクロスリージョン推論
即時性が要る →
| 手段 | 何をするか | 合う要件 | 合わない要件 |
|---|---|---|---|
| オンデマンド | 使った分だけ課金して呼ぶ | 流量に波がある・少ない | 安定した大量の流量で処理能力を確保したい |
| プロビジョンドスループット | モデルユニットで処理能力を確保する | 安定して大量に流れる本番 | 利用の少ない時間が長い |
| バッチ推論 | S3 の入力を非同期にまとめて処理する | 即時性の要らない大量処理 | 画面で待たせる対話 |
| プロンプトキャッシュ | 共通の先頭部分の処理を再利用する | 長いシステムプロンプトや同じ文書を何度も渡す | 毎回プロンプトの先頭が変わる |
| クロスリージョン推論 | 推論プロファイルで複数リージョンに分散する | ピークでスロットリングが起きる | データを置いてよいリージョンが1つに限られる |
プロンプトキャッシュは対応するモデルとオンデマンドの推論で使え、遅延と入力トークンの費用を下げます。効かせるには、変わらない部分（システムプロンプト・渡す文書）をプロンプトの先頭に固定し、変わる部分を後ろに置きます。同じ質問への回答そのものを、正規化した質問をキーにして期限付きでキャッシュする手もあります。
クロスリージョン推論は、データが別のリージョンで処理されることを意味します。データの所在に規制がある用途では、範囲を先に確かめます。部署ごとに費用を分けたいなら、タグを付けたアプリケーション推論プロファイルで呼び出すと、コスト配分タグで分けられます。単価は公式の料金ページで確認してください。
CHECK 4ここまでの確認
夜間にまとめて数十万件の要約を作る。即時の応答は要らない。推論の買い方として合うのはどれか?
答えと解説
答え: 1. 入力を S3 にまとめ、バッチ推論のジョブで処理する
即時性が要らない大量の処理はバッチ推論が合います。プロビジョンドスループットは、昼夜を通して安定した大量の流量があるときに処理能力を確保する手段です。「コストとスループットはどう選ぶか」の表を見直してください。
監視と人の確認をどこに入れるか
生成 AI の失敗は、例外ではなく「もっともらしい誤り」として起きます。だから監視は、エラー率に加えて、トークン数と回答の質を見ます。
3つの記録を役割で分ける
- CloudWatch のメトリクス: Bedrock はモデルごとに呼び出し数・遅延・入力と出力のトークン数・スロットリングの数を出します。トークン数の急増にアラームを置くと、プロンプトの事故（文書を丸ごと渡し続ける等）と費用の跳ね上がりに早く気づけます。
- モデル呼び出しのログ: プロンプトと応答の本文を CloudWatch Logs か S3 に残します。既定では無効なので、本番の前に有効にするかを決めます。品質の調査と評価データ作りの材料になる一方、個人情報の置き場所にもなります。
- CloudTrail: 誰がいつどの API を呼んだかの監査です。本文は残らないので、呼び出しログとは役割が違います。
スロットリングは一時的な制限なので、アプリはジッター付きの指数バックオフで再試行します。それでも続くなら、メトリクスで実際の呼び出し量とトークン数を Service Quotas のクォータと比べ、引き上げの申請かクロスリージョン推論での分散を検討します。
人の確認は3か所に置く
人の確認を「全部の回答を人が見る」にすると、生成 AI を入れた意味が消えます。置く場所を絞ります。
| 置く場所 | 何を確かめるか | 仕組みの例 |
|---|---|---|
| リリースの前 | 評価データで基準を満たすか、専門家の採点 | 人手の評価ジョブ、CI/CD の承認ゲート |
| 影響の大きい操作の前 | 送金・契約・顧客への送信など、取り消せない操作 | Step Functions のタスクトークンで承認を待つ |
| 本番の後 | 低評価の回答・根拠チェックで止まった回答の抜き取り | 利用者の評価と呼び出しログを突き合わせ、評価データに戻す |
生成 AI が操作まで行うエージェントの設計では、権限を最小にし、取り消せない操作の前で止まる形にします。生成 AI レンズも過剰な自律（excessive agency）を抑えることを挙げています。
この記事の判断の軸は、どれも「要件が変われば答えが変わる」ものです。選んだ理由を要件の言葉で説明する型は、次の記事で扱います。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
参照ソース
- Generative AI Lens - AWS Well-Architected Framework — 生成 AI のライフサイクルと6本の柱ごとのベストプラクティス、継続的な評価・過剰な自律の抑制の根拠（2026-10 時点の記載）
- Comparing Retrieval Augmented Generation and fine-tuning - AWS Prescriptive Guidance — RAG とファインチューニングの向き不向きの比較（2026-10 時点）
- Evaluate the performance of Amazon Bedrock resources — モデル評価（自動・LLM-as-a-judge・人手）と RAG の評価（検索のみ・検索と生成）の根拠（2026-10 時点）
- How content chunking works for knowledge bases — Knowledge Bases のチャンクの分け方の種類（2026-10 時点）
- Detect and filter harmful content by using Amazon Bedrock Guardrails — ガードレールのフィルター・個人情報の検出（ブロック／マスク）・文脈の根拠チェック（2026-10 時点）
- Use the ApplyGuardrail API in your application — モデルを呼ばずにガードレールで検査する方法（2026-10 時点）
- Data protection - Amazon Bedrock — プロンプトと応答をモデルの学習に使わないこと（2026-10 時点）
- Understanding intelligent prompt routing in Amazon Bedrock — 同じモデルファミリー内の振り分けと、英語のプロンプトに最適化されている制約（2026-10 時点）
- Prompt caching for faster model inference — プロンプトキャッシュの効果と対応する推論の形（2026-10 時点）
- Batch inference - Amazon Bedrock — S3 の入力をまとめて処理するバッチ推論（2026-10 時点）
- Monitor model invocation using CloudWatch Logs and Amazon S3 — 呼び出しログの内容と配信先（2026-10 時点）
- Monitor Amazon Bedrock with Amazon CloudWatch — 呼び出し数・遅延・トークン数・スロットリングのメトリクス（2026-10 時点）
