はじめに

生成AIの解説記事は世の中に大量にありますが、「PoCは動いた。ではこれを本番に載せるには何を決めればよいのか」という問いに正面から答えてくれる資料は、意外と多くありません。

本書『AWSではじめる生成AI』（原題: Generative AI on AWS）は、まさにその隙間を埋める一冊です。プロンプトエンジニアリングから始まり、Transformerの内部構造、量子化と分散学習、微調整（ファインチューニング）、RLHF、推論最適化、RAGとエージェント、マルチモーダル、そしてAmazon Bedrockまでを、一本のライフサイクルとして通して扱っています。

本記事では、設計・アーキテクチャに関心のあるエンジニア向けに、本書の構造と、実務で効いてくる論点を整理してご紹介します。

書誌情報

項目	内容
書名	AWSではじめる生成AI ―RAGアプリケーション開発から、基盤モデルの微調整、マルチモーダルAI活用までを試して学ぶ
原題	Generative AI on AWS
著者	Chris Fregly、Antje Barth、Shelbee Eigenbrode
訳者	久富木隆一
技術監修	本橋和貴、久保隆宏
出版社	オライリー・ジャパン
刊行	2024年（原著2023年）
ISBN	978-4-8144-0072-0
サンプルコード	generative-ai-on-aws/generative-ai-on-aws

サンプルコードはJupyterノートブック（.ipynb）形式で提供されており、Amazon SageMaker StudioやVS Codeにクローンして実行できるように整備されています。

本書の全体像

本書は全12章＋日本語版オリジナルの付録という構成です。章が独立したトピック集になっているのではなく、生成AIプロジェクトのライフサイクルの順に並んでいるのが特徴です。

章	テーマ	ライフサイクル上の位置
1章	ユースケース、基礎、ライフサイクル	全体像
2章	プロンプトエンジニアリングとコンテキスト内学習	実験と選択
3章	大規模言語モデル	モデルの理解・選択
4章	メモリーと計算リソースの最適化	学習基盤
5章	微調整と評価	調整・評価
6章	パラメーター効率的微調整（PEFT）	調整
7章	RLHFを用いた微調整	人間の価値観への適合
8章	モデルのデプロイの最適化	デプロイ
9章	RAGとエージェント	アプリケーション統合
10章	マルチモーダル基盤モデル	拡張
11章	Stable Diffusionによる制御と微調整	拡張
12章	Amazon Bedrock	マネージドサービス
付録A	Amazon Q（日本語版書き下ろし）	アプリケーション層

1章：ライフサイクルという背骨

1章で提示される「生成AIプロジェクトのライフサイクル」が、そのまま本書全体の目次になっています。

ユースケースの特定 — 単一の、実績があるユースケースから始める
実験と選択 — プロンプトエンジニアリングで、モデルに手を加えずに性能を引き出す
調整、適合、拡張 — 微調整、RLHF、外部データによる拡張
評価 — メトリクスとベンチマークの確立
デプロイと統合 — 推論最適化とエンドポイント設計
監視 — CloudWatch、CloudTrail

ここで示される判断基準が、実務的で好感を持てます。たとえば「まず70億（7B）パラメーター級の実績あるモデルで反復サイクルを高速に回すところから始める」という推奨です。1750億パラメーター級を最初から扱うと、ハードウェアのコストが実験速度を殺してしまうという、当たり前ですが見落としやすい話です。

また、事前学習はほとんどの現場で選択肢に入らないという前提が明確に置かれています。ゼロからの事前学習には数百万GPU時間を要するため、既存の基盤モデルを起点にする、というのが本書の一貫した立場です。

モデルの利用者を3層に分ける整理

AWSのサービス群を説明する際、本書は利用者を3つのペルソナに分けます。

モデルプロバイダー: 基盤モデルを構築・事前学習する。EC2、SageMaker、AWS Trainium、AWS Inferentiaを使う
モデルチューナー: ドメインやタスク向けに調整・適合させる。Amazon Bedrock、SageMaker JumpStartを使う
モデルコンシューマー: アプリケーションを通じて基盤モデルを使う。Amazon Q Developerなどのアプリケーション型サービスを使う

自分たちがどの層にいるのかを決めるだけで、検討すべきサービスの範囲が一気に絞れます。アーキテクチャ設計の初手として有効な補助線だと感じました。

2章：プロンプトエンジニアリングは推論設定とセットで考える

2章は、プロンプト構造（指示・コンテキスト）とコンテキスト内学習（zero-shot / one-shot / few-shot）の解説です。

個人的に価値が高いと感じたのは、推論設定パラメーターの節です。プロンプト文面の工夫だけが語られがちですが、実際の出力品質は復号化戦略に強く依存します。

貪欲サンプリング: 確率が最も高い単語を選ぶ。短い生成では機能するが、トークンの繰り返しが起きやすい
ランダムサンプリング: 確率分布全体から重み付きで選ぶ。繰り返しは減るが、本題から外れる可能性がある
top-k: 確率上位k個のみからランダムに選ぶ。k=1 は貪欲な復号化と等価
top-p: 累積確率がpを超えない範囲からサンプリングする

Hugging Face Transformersでは do_sample=True を明示しないとランダムサンプリングが有効にならない、といった実装レベルの注意も添えられています。「創造性が必要なタスクか、決定性が必要なタスクか」を設計時に決め、それをパラメーターに落とす、という発想が身につきます。

3章：Transformerとスケーリング則

3章は、トークナイザー、埋め込みベクトル、Transformerアーキテクチャ（入力とコンテキストウィンドウ、埋め込み層、エンコーダー、自己注意、デコーダー、ソフトマックス出力）を扱います。

基盤モデルはTransformerの構成によって3種類に分けられます。

種別	別名	代表的な用途
エンコーダーのみ	自己符号化器	分類、埋め込み生成
デコーダーのみ	自己回帰	テキスト生成
エンコーダー-デコーダー	系列変換	翻訳、要約

Chinchilla則という意思決定材料

本章のハイライトは計算最適モデルの節です。Chinchilla論文が示したのは、「学習用データセットの最適な規模（トークン数）は、モデルのパラメーター数の20倍」という経験則でした。

モデル	パラメーター数	最適なトークン数	実際のトークン数
Chinchilla	70B	1.4兆	1.4兆
LLaMA-65B	65B	1.3兆	1.4兆
GPT-3	175B	3.5兆	3000億
OPT-175B	175B	3.5兆	1800億
BLOOM	176B	3.5兆	3500億
Llama 2-70B	70B	1.4兆	2.0兆

GPT-3世代の巨大モデルは、データ量に対してパラメーターが過剰だった可能性がある、という指摘です。実際、Chinchilla論文以降にリリースされたLlama 2の70Bモデルは2兆トークンで学習され、MMLUなどのベンチマークで初代LLaMAを上回りました。

「大きければ強い」という直感が、必ずしも成立しないことを数字で示してくれる章です。モデル選定時に、パラメーター数だけを見て判断しなくなります。

4章：メモリー制約とどう戦うか

4章は、GPUメモリーの制限に起因する計算上の課題への対処です。ここから本書は一気に実装寄りになります。

量子化

データ型と数値精度のトレードオフを、fp16 / bfloat16 / fp8 / int8 の順に整理しています。単に「精度を落とすとメモリーが減る」ではなく、それぞれのデータ型が持つ表現範囲と、学習の安定性への影響が説明されるため、選択の根拠を持てます。

自己注意層の最適化

FlashAttention: 注意計算のメモリーアクセスを削減する
グループ化されたクエリーによる注意（GQA）: クエリーヘッドをグループ化し、キー・バリューのキャッシュを削減する

分散コンピューティング

分散データ並列（DDP）: モデル全体を各GPUに複製する
完全シャード化データ並列（FSDP）: パラメーター、勾配、オプティマイザー状態をGPU間で分割する

FSDPとDDPの性能比較まで踏み込んでおり、どの規模からFSDPが必要になるのかの感覚がつかめます。AWS側の実装としては、SageMakerの分散ライブラリー、AWS Neuron SDK、AWS Trainiumが紹介されています。Hugging FaceのOptimum Neuronライブラリーを使えば、Trainer を NeuronTrainer に差し替えるだけでTrainium上での学習に移行できる、という具体例も示されます。

5章：微調整と、評価の難しさ

5章では、指示による微調整（instruction fine-tuning）を扱います。プロンプトテンプレートを使って、独自データセットを指示データセットへ変換する手順が丁寧です。

評価パートでは、ROUGEなどのメトリクスと、コミュニティのベンチマークが紹介されます。

ベンチマーク	特徴
GLUE	2018年導入。複数の言語タスクで性能を比較
SuperGLUE	GLUEの後継。複数文の論理的判断や読解など難易度が上昇
HELM	16のシナリオ×7メトリクス。拡張機構を持つ「生きた」ベンチマーク
MMLU	数学、歴史、科学など多様な主題で知識と問題解決能力を評価
BIG-bench	204タスク。規模が大きく、縮小版もリリースされている

有害な出力の評価にはRealToxicityPromptsやTruthfulQAが挙げられています。日本語については訳注でJGLUEが補足されており、日本語版ならではの配慮を感じます。

本書は、微調整前後のROUGEスコアを実際に比較して見せてくれます（rouge1が0.2334から0.4216へ改善する例）。数字が動く様子を見せてくれるのは、評価設計の重要性を実感させるうえで効果的です。

6章：PEFTという現実解

6章は**パラメーター効率的微調整（PEFT）**です。実務で最も出番が多い章だと思います。

LoRA

ランク分解行列を使い、元の重みを凍結したまま少数のパラメーターだけを更新する手法です。本書は以下を段階的に扱います。

ランクの選び方
対象となるモジュールと層の指定
LoRAアダプターと元モデルのマージ
別々のLoRAアダプターを維持する運用
全パラメーター微調整とLoRAの性能比較

「アダプターをマージするか、分離したまま保持するか」という論点は、そのままデプロイ設計とバージョン管理の設計に直結します。タスクごとにアダプターを差し替える構成にすれば、基盤モデルは1つで済みます。

QLoRA

量子化と nf4（Normal Float 4）という新しいデータ型を組み合わせ、Transformerの注意層以外も対象とするLoRAの派生手法です。4章の量子化の知識がここで効いてきます。

プロンプト調整とソフトプロンプト

学習可能な仮想トークン（ソフトプロンプト）を入力の前に付加する手法です。20〜100個の仮想トークンで十分な性能が出るという研究が紹介されています。

ただし本書は、限界もはっきり書いています。

学習された仮想トークンは埋め込み空間の任意の値を取るため、解釈可能性が低い
プロンプト調整は新しい知識を注入できない。あくまでプロンプトの最適化である

「何ができないか」を明示してくれる技術書は信頼できます。

7章：RLHFと報酬ハッキング

7章は、人間のフィードバックからの強化学習（RLHF）です。「有用性、誠実性、無害性（HHH）」への適合を目標に据えます。

流れは以下の通りです。

ヒューマンインザループで学習用データセットを収集する（Amazon SageMaker Ground Truthを利用）
人間の評価者向けのルールを定義する
順位付けデータを、人間が読める形式から機械が読める形式に変換する
報酬モデルを学習する
近接方策最適化（PPO）で基盤モデルを更新する

興味深いのは、既存の分類器をそのまま報酬モデルとして使う選択肢が示されている点です。Metaの有害性検出器を使えば、報酬モデルの学習を省略できます。フルスクラッチと既製品の間にある現実的な選択肢を提示してくれます。

報酬ハッキングを抑えるという節があるのも実践的です。報酬モデルのスコアだけを最大化しようとすると、モデルが不自然な出力に走ります。これを抑えるための工夫が解説されます。

評価は定性・定量の両面で行われ、有害性スコアがRLHF前後で平均15.93%改善する例が示されます。テスト用データセット（微調整中にモデルへ与えなかったデータ）で評価している点も、きちんと明記されています。

8章：デプロイ最適化は「CFOの幸福度」の話

8章は推論最適化です。3つの手法が示されます。

手法	概要
プルーニング	寄与の小さい重みを削除する
GPTQ	学習後の量子化を行う
蒸留	大きな教師モデルから小さな生徒モデルへ知識を移す

そのうえで、大規模モデル推論コンテナ、AWS Inferentia、SageMaker Endpointによるデプロイが解説されます。

デプロイ戦略として A/Bテスト と シャドウデプロイメント が扱われ、オートスケーリングポリシーの定義まで具体的なコードで示されます。SageMakerVariantInvocationsPerInstance を指標にターゲット追跡スケーリングを設定する例などです。

本章のまとめに「最終的にコストを引き下げて、CFOの幸福度を向上させるかもしれません」という一文があります。冗談めかしていますが、推論コストが事業の継続性を左右するという現実を的確に突いた表現です。

9章：RAGとエージェント、そしてFMOps

個人的に最も読み応えがあったのが9章です。分量も本書中で最大です。

まず制限から入る構成

RAGの説明に入る前に、LLMの制限を明示します。

ハルシネーション: モデルが事実でない内容を生成する
知識のカットオフ: 学習データ以降の情報を持たない

RAGは「便利な機能」ではなく「制限を緩和するための構造」として位置づけられます。この順序で説明されると、RAGを入れるべきか否かの判断がしやすくなります。

RAGのワークフロー

外部の知識ソースを用意する
ドキュメントをロードする
チャンク化する
ドキュメント検索と再順位付けを行う
プロンプトを拡張する

実装面では、埋め込みベクトルストア、検索チェーン、最大限界関連性（MMR）による再順位付けまで踏み込みます。検索結果の多様性を確保する話は、RAGの精度が頭打ちになったときに効いてくる論点です。

ベクトルストアの選択肢としては、Amazon OpenSearch Serverless のベクトルエンジン、OpenSearch Service の k-NN プラグイン、Aurora PostgreSQL / RDS for PostgreSQL の pgvector が挙げられています。

エージェント

ReAct: 推論と行動を交互に行わせるプロンプト方式
プログラム仲介プロンプト（PAL）: 計算をプログラムに委譲する方式

基盤モデルを「論理的判断エンジン」として捉え、エージェントがプロンプトエンジニアリングとシステム間通信を担当する、という整理が示されます。

FMOps

9.6節は FMOps です。生成AIプロジェクトのライフサイクルを運用可能にするための留意事項が、実験・開発・本番デプロイの3段階で語られます。

本書のスタンスは明快です。

MLOpsの中心的プラクティスは大多数が引き続き適用でき、基盤モデル特有の側面を通じてのみ要素を追加する

たとえばLoRAで調整したモデルをデプロイする場合、基盤モデル・アダプターモデル・マージ済みモデルという複数の依存が発生します。これらのメタデータをモデルレジストリーに記録し、系統（リネージ）を追跡できるようにしておくべきだ、という指摘は具体的で有用です。

「生成AIだから全部新しい」ではなく、「既存のプラクティスの上に何を足すか」で考える。この姿勢は、既存のCI/CDや監視基盤を持つチームにとって現実的な道筋になります。

10章・11章：マルチモーダルと拡散モデル

10章はマルチモーダル基盤モデルです。画像生成、画像の編集と補正、インペインティング、アウトペインティング、深度情報からの画像生成、画像キャプション、コンテンツモデレーション、視覚的質問回答（VQA）と、ユースケースを幅広く扱います。

アーキテクチャ解説では、順拡散・逆拡散・U-Netという拡散モデルの基礎から、Stable Diffusion 2（テキストエンコーダー、U-Net、テキスト条件付け、相互注意、スケジューラー、画像デコーダー）、Stable Diffusion XL（U-Netが8.65億→26億パラメーターへ、テキストエンコーダーが2つに、リファイナーの追加、画像サイズと切り取りの条件付け）へと進みます。

評価の節では、テキストと画像の適合度に加えて、レーヴン漸進的マトリックスによる非言語的な論理的判断の評価まで紹介されます。マルチモーダルモデルの評価という難問に、どうアプローチしているかが見えます。

11章はStable Diffusionの制御と微調整です。

ControlNet: 条件付き制御モデルで生成を誘導する
DreamBooth / PEFT-LoRA: 独自データで概念を学習させる
テキスト反転: 実在しない固有名詞に概念を紐づける
DDPO: ノイズ除去の各ステップを「アクション」とみなしてRLを適用する

LAION-Aestheticsの予測器（17万6千人の評価で学習）を報酬モデルに使う例や、Amazon RekognitionのContent Moderation APIの出力形式を微調整の参考にする例など、既存のサービスを部品として組み合わせる発想が随所に見られます。

12章・付録A：マネージドサービス

12章はAmazon Bedrockです。Amazon Titan、Stable Diffusion XLといった基盤モデル、推論API、SQLコード生成やテキスト要約や埋め込みといったタスク、微調整、エージェント、マルチモーダルまでを扱います。

設計上見逃せないのが、データプライバシーとネットワークセキュリティの節です。

プロンプト、応答、微調整済みモデルは自組織のAWSアカウント内でのみアクセス可能
データはサービス改善に利用されず、サードパーティのモデルプロバイダーとも共有されない
伝送中はTLS 1.2以上、保存時はKMS管理キーまたは自己管理キーでAES-256暗号化
VPC Endpoint（AWS PrivateLink）で、データが公開インターネットを通過しない構成が可能
Direct Connectと組み合わせれば、オンプレミスからの全トラフィックをAWSバックボーン内に閉じられる

ガバナンス面では、IAM連携、CloudTrailによるAPIアクティビティ記録、Model Invocation Loggingによるプロンプト・出力の記録、CloudWatchへの InputTokenCount / OutputTokenCount / InvocationLatency / Invocations の発行が説明されます。

企業内で生成AIの利用申請を通す際、この節はそのまま説明資料の材料になります。

付録Aは日本語版の書き下ろしで、Amazon Q（Q Developer、Q Business、Q Apps）を扱っています。原著執筆後の発表であるため、訳出時に補われたものです。

設計者として持ち帰った視点

訳者あとがきに、本書の価値を言い当てた整理があります。生成AIには複数種類の制約があり、それを一望できるのが本書だ、というものです。

技術に内在する制約: 性能とコスト。レイテンシーとコストの範囲内で何ができるかを模索する → 4章、8章
人間由来の外在的制約: 価値観や文化的習慣への適合（アラインメント） → 7章、11章
インターフェイスの制約: API、ライブラリー、試行錯誤を高速に回せる体制 → 2章、9章
セキュリティとガバナンスの制約: 外部攻撃への対策、各国の法的規制への対応 → 12章

生成AIの設計判断は、結局のところこれらの制約のどれを優先するかの意思決定です。本書はその選択肢とトレードオフを、章ごとに材料として並べてくれます。

もうひとつ、「ハンマーを持っていると何でもかんでも釘に見える」という認知バイアスへの警告も印象に残りました。生成AIの見通しが明るくなると、必要以上に適用したくなります。何に使うかを決める前に、それによって利用者にどういう利益があるのかを検討すべきだ、という当たり前の指摘は、繰り返し確認する価値があります。

こんな方におすすめ

PoCは動いたが、本番運用に向けた設計判断の材料が欲しい方
RAGを実装したことはあるが、チャンク化や再順位付けの選択に根拠を持ちたい方
微調整の手法（全パラメーター / LoRA / QLoRA / プロンプト調整）を比較して選びたい方
MLOpsの経験があり、生成AI固有の差分だけを効率よく把握したい方
社内で生成AI導入の技術的な説明責任を負っている方

逆に、以下の方には向かないかもしれません。

生成AIをまず触ってみたい入門段階の方（4章以降の密度が高いです）
AWS以外のクラウドでの実装を前提としている方（概念部分は転用できますが、実装例はAWSに寄っています）

注意点

原著が2023年、邦訳が2024年です。この分野の変化速度を考えると、サービス名や機能の粒度は現時点の情報で補う必要があります。

ただし、本書が扱う中核（Transformerの構造、スケーリング則、量子化、PEFTの原理、RLHFのプロセス、RAGのワークフロー、FMOpsの考え方）は、モデルが世代交代しても残る知識です。日本語版では訳注が丁寧に追加されており、原著出版後の動向もかなりの部分が補われています。

技術監修者まえがきにある通り、日本語版は原著の翻訳にとどまらず、訳注による情報補完と原著論文との照合による修正が入っています。この点は日本語で読む価値として大きいと感じました。

まとめ

『AWSではじめる生成AI』は、生成AIを「試す」段階から「運用する」段階へ移行するための地図です。

ライフサイクルという背骨に沿って章が並び、どの段階で何を決めるべきかが明確
各手法について、できることだけでなくできないことが書かれている
MLOpsの延長線上にFMOpsを位置づけ、既存の運用資産を活かす道筋を示す
セキュリティとガバナンスまで扱い、企業導入の説明材料になる

生成AIアプリケーションの設計に関わる方であれば、手元に置いて章ごとに引く使い方ができる一冊です。特に9章のRAGとFMOpsは、繰り返し読み返す価値があると感じました。

参考リンク