9月15日、AWSが「The generative AI customization spectrum: From prompt engineering to custom models on AWS」と題した記事を公開した。プロンプトエンジニアリングからカスタムモデル構築まで、生成AIのカスタマイズ手法を8ステップで選ぶ意思決定フレームワーク「生成AIカスタマイズスペクトラム」の詳細が紹介されている。
「とりあえずファインチューニング」が失敗する理由
生成AIの実装を進める際、チームが陥りがちな罠が2つある。一方は「ちゃんとしたプロンプトを書けば解決できるのに、すぐファインチューニングに飛びつく」ケース。もう一方は「明らかにドメイン固有の学習データが必要な問題に、何週間もプロンプト調整を続ける」ケースだ。どちらも計算コスト・リリース遅延・ステークホルダーへの信頼損失という形で実害が出る。
AWSはこの問題に対し、「簡単な方法から始めて、必要なときだけ次のステップに進む」という原則を軸にした8段階のフレームワークを提示した。
8ステップの全体像：3つのカテゴリ
スペクトラムは以下の3カテゴリに分かれる。
USE（モデルをそのまま使う）
- Step 1: 既存モデルをAPI経由でそのまま呼び出す
- Step 2: プロンプトエンジニアリング（システムプロンプト、few-shot例示、Chain-of-Thoughtなど）
ENHANCE（モデルの周囲を強化する）
- Step 3: RAG（Retrieval-Augmented Generation）による外部知識の付与
- Step 4: プロンプトキャッシュによるレイテンシ・コスト削減
- Step 5: モデル蒸留（大きなモデルの知識を小さなモデルに転移）
TRAIN（モデル自体を変える）
- Step 6: ファインチューニング（ラベル付きデータで重みを更新）
- Step 7: 継続事前学習（大量の非ラベルドメインデータで基礎知識を拡張）
- Step 8: Amazon Nova Forgeによるカスタムモデルのゼロからの構築
ほとんどのユースケースはStep 3を超える必要がない、というのがAWSの主張だ。
最も重要な判断軸：「いつ次のステップに進むか」
各ステップには「エスカレーションシグナル」が定義されている。判断に迷いやすいステップを中心に整理する。
Step 2 → Step 3へ進む条件
プロンプトが約2,000トークンを超える、モデルが持っていない知識が必要、ドメイン固有のファクトでハルシネーションが続く場合。
Step 4 プロンプトキャッシュ：繰り返しコンテキストのコストを削る
同一または類似のシステムプロンプト・コンテキストを繰り返し送信するユースケースで効果を発揮する。エスカレーションシグナルは「リクエスト間でコンテキストの大部分が変わらないにもかかわらず、レイテンシやコストがネックになっている」状況だ。逆に、リクエストごとにコンテキストが大きく変わる場合はキャッシュヒット率が低く、恩恵は限定的になる。Step 5（モデル蒸留）との使い分けは「コンテキストの再利用性があるかどうか」が一つの判断基準となる。
Step 5 モデル蒸留：品質を保ちながら小型化する
大きな教師モデルで品質を検証済みだが、コスト・レイテンシがネックという状況で使う。Amazon Bedrock Model Distillationは、教師モデルと比べて最大500%高速、最大75%コスト削減を実現し、精度ロスは2%未満とされている（なお、これらの数値は2025年5月のGA発表時に公表されたものであり、本記事執筆時点での最新値についてはAmazon Bedrockの公式ドキュメントを確認されたい）。
エスカレーションシグナルは「教師モデルの出力品質は十分だが、本番環境では推論コストまたはレイテンシの制約がある」場合だ。料理人の比喩で説明するなら「ヘッドシェフのコース料理は完璧だが1皿45分かかる。人気の3品だけをラインクックに教えて、10分・3分の1のコストで出す」という構図になる。
Step 6 ファインチューニング：RFTが実用的になった
従来のSFT（Supervised Fine-Tuning：正解の入出力ペアを用いた教師あり微調整）は、望む挙動ごとにゴールドスタンダードの入出力ペアを用意しなければならない。コード生成や多段階推論では、正解例を手作業で作るコストが高い。
RFT（Reinforcement Fine-Tuning：強化学習を用いた微調整）はこれを解決する。報酬関数でスコアを定義し、モデルがその指標を最適化するよう学習する。正解を「示す」より「検証する」方がはるかに安いタスクに向く。Amazon Bedrockでは1ジョブあたり最大20,000プロンプトと採点関数を渡すだけで、RLパイプライン全体を管理不要で実行できる。
なお、記事ではRFTがサポートするモデルの拡張経緯にも触れられている。Amazon Novaモデルへの対応（2025年12月）、OpenAI GPT OSS 20BおよびQwen 3 32Bへの拡張（2026年2月）は、いずれも本記事公開（2026年9月15日）時点では既にリリース済みの機能として紹介されている。
ファインチューニングのデータ要件は以下のとおりだ。
| 手法 | 必要データ量 |
|---|---|
| PEFT（LoRAなど） | 数千件のラベル付き例 |
| フルファインチューニング | 数万件のラベル付き例 |
| DPO（Direct Preference Optimization：好ましい/好ましくない応答ペアから学習する手法） | 好ましい/好ましくない応答のペア |
Step 7 継続事前学習の落とし穴
ドメインデータで学習すると汎用推論・指示追従・安全性が劣化する「破滅的忘却（catastrophic forgetting）」が従来の課題だった。Amazon Nova ForgeはAWSがキュレーションした学習データをドメインデータと混合することでこれに対処する。
実際の採用事例
記事内で紹介されている導入例を抜粋する。
- Fractal Analytics：RAGを使ったコールセンター向け統合知識ベースを構築。通話処理時間10〜15%削減、30%の問い合わせ削減、月間20万件超のクエリを処理。
- EXL：RAGベースの保険引受バーチャルアシスタントでコストを80%削減。
- Trellix（サイバーセキュリティ）：ファインチューニングにより、セキュリティ統合ごとの開発工数を40時間以上削減、新規統合のTime-to-Marketを90%短縮。
- DoorDash：プロンプトエンジニアリングのみで音声対応AIコンタクトセンターを2ヶ月でライブテスト可能な状態に。
まとめ
このフレームワークが実務上で持つ意義は、「どこから手をつけるか」の出発点を揃えることより、「どこで止まるか」の判断基準を組織として共有できる点にある。各ステップにエスカレーションシグナルが明示されているため、アーキテクチャ選定の根拠をドキュメント化しやすく、後工程での手戻りコストを抑えられる。特にStep 4・5のENHANCEカテゴリはTRAINへ進む前の「最後の砦」として機能しており、コスト・レイテンシの問題をモデル変更なしに解消できるかどうかをここで見極めることが重要だ。
詳細はThe generative AI customization spectrum: From prompt engineering to custom models on AWSを参照していただきたい。
