※本記事は、Daniel Zagyva氏(AWS、Sr. Delivery Consultant - AI/ML)、Laurens van der Maas氏(AWS、Delivery Consultant AI/ML)、Aleksandra Dokic氏(AWS、Sr. Delivery Consultant AI/ML)、Mark Andrews氏(AWS、Senior Principal, Product Management)による講演セッション「AWS AI and Data Conference 2026 - LLM Customization」の内容を基に作成されています。本セッションは、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された、第5回AWS AI and Data Conference 2026にて収録されました。AWSのイベントに関する詳細情報は https://go.aws/events でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演映像をご視聴いただくことをお勧めいたします。
1. イントロダクションとLLMカスタマイズの必要性
1.1 登壇者紹介とセッション概要
Daniel： こんにちは、皆さん。これから45分間で、AWS上でどのようにLLMをカスタマイズしていくかについて、皆さんと一緒に見ていきたいと思います。うまくいく方法と、本当に難しい部分の両方をしっかりお伝えするつもりです。私はDanielと申します。本日は、AWSプロフェッショナルサービスチームのAlexandra Lawrenceと、そしてサンフランシスコからはるばる来てくれたMark Andrewsと一緒に登壇します。
Daniel： Markは、Amazon Novaチームのシニアプリンシパルプロダクトマネージャーを務めています。セッション終了後に質問がある方は、ぜひ彼をつかまえてみてください。
Daniel： 本題に入る前に、一つ引用をご紹介したいと思います。2027年までに、エンタープライズのお客様が利用する生成AIモデルの半数以上がドメイン特化型になるという予測があります。2024年時点ではわずか1%だったことを考えると、非常に大きな変化です。これはつまり、汎用的なAIから特化型のAIへと主役が移り変わっていくということを意味しています。皆さんの業界を理解し、皆さんの顧客を理解し、皆さんの組織そのものを理解するAIへ、です。もはや「カスタマイズすべきかどうか」ではなく、「どうやって、どれだけ効率的にそれを実現するか」が問われる時代になっています。
Daniel： 本日の構成としては、まずなぜLLMをカスタマイズする必要があるのかをお話しします。次に、それぞれのカスタマイズ手法について詳しく掘り下げていきます。そのうえで、それらがAmazon SageMaker AI上で実際にどう組み合わさって動くのかをお見せします。最後に、Amazon Novaを使って自分たちのフロンティアモデルを構築できる新しいサービス、Nova Forgeをご紹介して締めくくりたいと思います。
1.2 基盤モデルと組織固有知識の「壊れた橋」、カスタマイズがもたらす価値
Daniel： ここで少し、この図をご覧いただきたいと思います。一方には基盤モデルがあります。非常に高性能で強力なモデルです。もう一方には、皆さんの組織が持つ知識の中核があります。そして、その間には壊れた橋があります。今日お話ししたいのは、まさにこのギャップについてです。どれほど基盤モデルが強力であっても、皆さんの組織固有の知識とつながれなければ、そのモデルが皆さんにもたらせる価値には限界があるからです。
Daniel： 基盤モデルは強力ではありますが、同時に汎用的でもあります。誰にでも使えるように作られているぶん、特定の誰かのために最適化されているわけではありません。自分たちのデータ、自分たちのワークフローに合わせてモデルをカスタマイズすることで、初めて差別化された価値を引き出すことができます。さらに一歩踏み込んでモデルカスタマイズそのものを行えば、本当の意味での競争優位性を得ることができます。なぜなら、モデルカスタマイズはプロンプトエンジニアリングやRAGのソリューションではたどり着けない領域まで、ドメインの専門知識をモデルの中にエンコードできるからです。
Daniel： 誤解のないように申し上げておくと、RAGは非常に強力な手法です。特に、データベースからリアルタイムで知識を検索し、頻繁に更新される知識を扱いたい場合には、RAGは大いに役立ちます。ただ、私たちがこれまで見てきた中には、モデル自体を独自の知識に深く根ざした状態にする必要がある、特定のケースが存在します。
Daniel： 例えば、数十年分の創薬データを持つ製薬会社を考えてみてください。そのデータはインターネット上のどこにも存在しません。こうしたデータをモデルに埋め込むことで、モデルからより深い洞察を引き出し、新しい薬の発見につなげることができます。また、小売業の組織であれば、数万件におよぶ商品説明や顧客対応のデータを持っています。こうしたデータを使ってモデルをトレーニングすれば、大掛かりなプロンプトエンジニアリングを行わなくても、ブランドボイスやコミュニケーションの基準にモデルの応答を合わせることができます。
Daniel： さらに、多くのお客様の事例から分かってきたこととして、モデルカスタマイズを行うことでドメイン固有のタスクにおける精度を高め、プロンプトエンジニアリングだけのアプローチを上回る結果を出すことができるケースが多くあります。そして、カスタマイズしたモデルを小型化できれば、レイテンシーを大幅に下げることも可能です。その結果として、ユーザー体験も格段に向上します。
Daniel： 総じて言えることは、一度自分たちの組織のためにモデルをカスタマイズしてしまえば、その知見を再利用し、別のユースケースに向けて再トレーニングすることができるという、長期的なメリットが得られるということです。あるいは、事業の成長とともに進化し続ける、自社専用のドメイン特化モデルを一つ持ち続けることもできるようになります。
2. カスタマイズのスペクトラムと各手法の概観
2.1 プロンプトエンジニアリングからフルモデルカスタマイズまでの全体像
Daniel： さて、ここまでお話ししてきたカスタマイズというのは、決して一つのものを指しているわけではありません。むしろこれは一つのスペクトラム、連続体として捉えるべきものです。もっとも軽量な端にあるのが、先ほど触れたプロンプトエンジニアリングです。高速で、効率的で、コスト効果も高く、ほとんどのエンタープライズユーザーにとって非常に良い出発点になります。
Daniel： その次にあるのが、RAGを使ったコンテキストエンジニアリングです。ここでは、推論の実行時にリアルタイムで知識をモデルに注入します。この段階でも、まだトレーニングは必要ありません。そして、さらに深いところまで踏み込んでいくと、モデルカスタマイズという領域に入っていきます。具体的には、教師ありファインチューニング(SFT)、Direct Preference Optimization(DPO)、強化学習ファインチューニング、そして蒸留といった手法が該当します。Amazon BedrockとSageMaker AIの両方で、LoRAアダプタを使った特定のバージョンを利用できるようになっており、これは計算効率が非常に良く、少ないデータ量でも活用できるという特徴があります。
Daniel： そして、もっとも複雑なアプローチが、これらすべての手法を組み合わせて、モデルの重みをすべて更新するというやり方です。これはつまりフルモデルカスタマイズを行うということであり、これはAmazon SageMaker AIで利用可能です。それでは、ここからはAlexにバトンタッチして、これらの手法について具体的に深掘りしてもらいたいと思います。
Alexandra： ありがとう、Danny。それでは、カスタマイズの選択肢について学んできたところですが、いろいろな用語が飛び交っていたと思いますので、もう少し詳しくお話ししていきたいと思います。本日取り上げる4つの手法をスライドに示していますが、これらは左から右に並んでいる順番が、実際に皆さんのビジネスユースケースに適用する際の複雑さの順番にもなっています。
3. 各カスタマイズ手法の詳細(Alexandra Lawrenceパート)
3.1 教師ありファインチューニング(SFT)と選好アライメント(Preference Alignment)
Alexandra： まず一つ目の手法である、SFT、教師ありファインチューニングについてお話しします。これは、モデルに何か特定の新しいタスクを教えたい場合や、モデルに新しい能力を追加したい場合に使うべき手法です。多くの場合、まずはプロンプトエンジニアリングから始めることになると思います。指示を与えて、モデルに何らかのタスクをやらせてみるわけです。しかし、それがうまくいかなかったり、結果が一貫しなかったりする場合には、入力と出力のペア、つまりモデルに模倣してほしい例の集合を与えることで、モデルをさらに助けてあげることができます。
Alexandra： サンプルデータを見てみましょう。ここにはシステムプロンプトがあります。これはプロンプトエンジニアリングで行うこととよく似ていますが、ここではそこまで複雑にしたり、細かい詳細を盛り込んだりする必要はありません。なぜなら、モデルに与えるもう一つの要素として、ユーザーメッセージによるチャット形式のメッセージ、つまり実質的な入力と、それに対するアシスタントの回答があるからです。この回答こそが、モデルに実際にやってほしいことになります。こうした入力と出力のペアをたくさんモデルに与えることで、モデルはこのタスクをより上手にこなす方法を、これらの例をもとに学習していきます。
Alexandra： 二つ目の手法は、選好アライメントです。これは、モデルの回答を特定のトーンや口調にしたい場合に検討すべき手法です。ここでは、モデルがすでにある程度そのタスクをこなせることを前提としています。ただ、特定の言い回しで答えてほしいという場合です。データの例を見ると、ここでもユーザーの入力は与えられますが、今回は一つの正解、一つのラベルだけを与えるわけではありません。実際には、モデルに二つの例を提示します。
Alexandra： 一つは、採用したい回答、つまりモデルにこう答えてほしいという方向性を示す回答です。トレーニングの過程で、モデルはこの方向にロジットを調整するように学習していきます。もう一つは、却下したい回答です。これは、トレーニングを通じてモデルに避けてほしい方向を示すものです。ここでも、こうした例をたくさんモデルに提示していくことになります。ここでの例で見ていただくと分かるように、モデルはレストランがどれくらい良いかという質問には、いずれにせよ答えているのですが、私たちが求めているのは、もう少しプロフェッショナルな、あまりカジュアルすぎない答え方をしてほしいということです。
3.2 強化学習ファインチューニングと継続事前学習(CPT)
Alexandra： 続いて、強化学習ファインチューニングについてです。この手法は最近かなり注目を集めていますが、それはモデルがかなり複雑な推論タスクに取り組む際の助けになるからです。この手法がどのように機能するかというと、トレーニングの過程でモデルが応答を生成し、その応答が特定の報酬関数によって送られ、評価されます。そして、この報酬に基づいて、モデルは自分の答えが良かったのか、推論が適切だったのか、あるいは改善が必要なのかを学習していきます。このようにして、トレーニングシステム全体を通じて能力を獲得していくわけです。
Alexandra： ここでもサンプルデータをお見せしていますが、これをあまり文字通りに受け取らないでください。私たちが本当にお伝えしたいのは、ここでは最終的な答えが一つだけあるのではなく、それに加えて、リファレンスとなる回答の中に、推論のステップも含める必要があるということです。そうすることで、モデルは特定の答えにたどり着くために、どのように考えを進めていけばよいかを理解できるようになります。もちろん、これはあくまで一つのやり方に過ぎません。
Alexandra： この報酬関数についてお話しすると、報酬関数そのものは、皆さんのユースケースに合ったシンプルなプログラム的な回答から、実際に別に用意された報酬モデルまで、幅広い形を取り得ます。この報酬モデルは、人間が作った例や人間からのフィードバックに基づいてトレーニングされることもありますし、最近人気が高まっているのは、AIからのフィードバックを使う方法です。こちらの方が高速にフィードバックを得られるため、実際のトレーニング時にリアルタイムで報酬を返せるモデルを構築できるからです。
Alexandra： 最後に、継続事前学習、CPTについてです。この手法は興味深いもので、モデルにまったく新しいドメインを学習させる助けになります。例えば、新しい言語をモデルに学習させたり、これまでモデルが扱ったことのなかった特定の業界や文脈における概念を理解させたりすることができます。ここでのデータは、完全にラベルなしのものになります。JSON形式に惑わされないでいただきたいのですが、最終的にこれは、データをモデルのトレーニングに渡す際のフォーマットに過ぎません。私たちが本当に活用したいのは、このtextというキーの下にある部分です。その値として入っている長いテキストの情報こそが、モデルに学習させたい内容になります。
Alexandra： CPTは興味深い手法ですが、一つ注意点が伴います。トレーニングの過程で、モデルの指示追従能力、いわゆるinstruction followingの能力が劣化してしまうことが、決して珍しくないのです。これがなぜ重要かと言いますと、instruction followingこそが、私たちがモデルに望む作業を実際にやらせるための土台になるからです。これはプロンプトエンジニアリングにおける私たちの強みでもあります。ですので、CPTを実施した場合には、その上に、先ほどお話ししたSFTのような別の手法を重ねて適用し、instruction followingの能力を取り戻し、実際のビジネスユースケースで使えるモデルに仕上げる必要が出てくることが非常に多いです。この点は、ぜひ考慮に入れておいていただきたいと思います。
4. 投資規模の比較と実践的なアドバイス
4.1 各手法における開発期間・データ量の比較と組み合わせ方
Alexandra： ここまで、それぞれの手法が何であるか、そしてどのような場面で使うべきかを見てきました。ここからは、実際にこうしたカスタマイズを行う際に、どれくらいの投資が必要になるのかについても、少し共有しておきたいと思います。SFTについて言うと、会場にデータサイエンティストやエンジニアの方がいらっしゃれば分かると思うのですが、労力の大部分はトレーニングデータの準備、つまり自分たちのモデルに使える形式にデータを整える作業に費やされます。SFTの場合であれば、これは入力と出力のペアという形式になります。データを正しいフォーマットに整えて、実際にトレーニングを始められる段階になったとしても、SFTのタスクであれば、実験に数日から数週間程度の期間を見込んでおく必要があります。選好アライメントについても、これと似たような期間感になります。
Alexandra： 強化学習について言うと、ここではもう少し多めの投資を覚悟していただく必要があります。というのも、実装したい報酬関数がどれくらい複雑かにもよりますが、トレーニングを立ち上げて、実際に価値のある結果を得られるようになるまでには、もう少し時間がかかるからです。そして、この尺度でCPTを見てみると、こちらはさらに多くの投資を覚悟していただく必要があります。CPTでは、有効なモデルを得るまでに数週間から数ヶ月単位の開発期間を見込むことになります。そして先ほど申し上げた通り、これを他の手法と組み合わせる必要が出てくることも多いです。
Alexandra： データ量についても見ておきましょう。SFTについて言うと、データ量としてはおおよそ1万件から1000万件程度の範囲を準備する心づもりをしておくとよいと思います。SFTについては、先ほどDannyが触れたPEFTやLoRAといった手法を適用することで、このデータ量を減らすことができます。こうした手法を使えば、より少ないデータでも良い結果を得ることが可能になりますが、それでもトレーニングを行う際にはこの点を計画に入れておくべきです。選好アライメントについては、1000件から100万件程度と、少し少なめの規模になります。そして、これをCPTと比較すると、CPTの場合にはトレーニングデータとして最大10億トークン程度を用意しておくべきという話になります。これくらいの規模がないと、モデルが以前は知らなかった追加の知識を実際に習得できるだけの、知識の針を動かすことは難しいということです。
Alexandra： ここで申し上げておきたいのは、こうした手法は互いに排他的なものではないということです。むしろ、これらをかなりうまく組み合わせることができます。一般的には、まずSFTから始めることをお勧めしています。投資が少なくて済みますし、自分たちの取り組みの成果をより早く目にすることができ、モデルのカスタマイズにどれくらい役立つのかを見極めることができるからです。その結果が良ければ、そして他の手法にも本格的に投資したいということであれば、これらをかなり順序立てて組み合わせていくことができます。例えば、まずCPTモデルを開発し、次にSFTモデルを開発し、さらにその上に選好アライメントを適用する、といった形です。こうした手法を組み合わせることで、自分たちのユースケースにおいて非常に高い品質を達成することができます。
4.2 カスタマイズを検討する際の3つの観点
Alexandra： もう一点、私たちが実際にこうした手法のいくつかを試し、特定のユースケース向けに開発してきた経験から、皆さんがこの方法でカスタマイズを検討する際に考えていただきたいポイントをいくつか共有したいと思います。一つ目は、プレゼンテーションを通じてすでに何度か触れてきたことですが、自分たちのデータについて考えるということです。皆さんのデータは、本当にオンライン上のリソースでは手に入らないものでしょうか。もしそれがすでにどこかに存在しているのであれば、そうした基盤モデルを構築するために多くの時間と労力を投じている企業がたくさんありますので、モデルがすでにその情報を知っている可能性は決して低くありません。カスタマイズに時間と労力を投資する前に、まずはプロンプトエンジニアリングを試し、モデルがすでにその情報を認識しているかどうかを確かめてみてください。
Alexandra： 二つ目は、当然ながら時間と労力です。このカスタマイズを構築するには、それなりの時間とコストがかかります。ですので、自分たちが取り組みたい正しいユースケース、正しいタスクを選ぶようにしてください。それは、品質の何パーセントかの改善が、実際に皆さんのビジネスにとって大きな意味を持つようなものであるべきです。これはおそらく、どんな場面にも当てはまる良いアドバイスだと思います。
Alexandra： そして最後のポイントが、レイテンシーです。これについてはすでに少し触れましたが、モデルをカスタマイズすることで、レイテンシーの制約にも対処できる可能性があります。これがどのように機能するかというと、カスタマイズされたモデルであれば、カスタマイズされていない大きなモデルと同じ、あるいは似たような品質の応答を、より小さなモデルで得られる可能性があるということです。モデルサイズを小さくする方向に動くことで、応答速度は格段に速くなります。さらに、モデルがすでに学習すべきパターンを持っているため、これほど複雑な入力コンテキストを扱う必要がなくなり、詳細な指示をそこまで細かく与える必要もなくなります。そして、タスクが特化したものであれば、常に長い出力や長い推論が出力されるとは限らず、むしろ非常に特化した短い出力トークンで済むことも多くなります。こうした点も、応答のレイテンシーにかなり影響を与える要素になります。
Alexandra： さて、理論的な話は今日のところは十分だと思います。それでは、Amazon SageMakerを使ってこうした内容を実際にどのように実装していくのか、Lawrenceにバトンタッチして説明してもらいたいと思います。ありがとうございました。
5. なぜLLMカスタマイズが浸透しないのか、8つの課題(Lawrenceパート)
5.1 挙手アンケートとインフラ・ツール・ガバナンスの課題
Lawrence： それでは、なぜ皆さんはLLMのカスタマイズをしていないのでしょうか。これほど素晴らしくて、役に立ちそうな話なのに、です。実は私、ぜひ知りたいことがあります。この会場で、これまでにLLMをカスタマイズしたことがある方はいらっしゃいますか。挙手をお願いできますか。一人いらっしゃいますね。
Lawrence： それは素晴らしいですね。では、なぜ皆さんはやっていないのでしょうか。理由はたくさんあります。現実として、これは本当にかなり難しいことなのです。私が挙げられる理由だけでも8つありますし、それぞれについてもっと長く語ることもできます。
Lawrence： まず一つ目は、インフラの課題です。現実として、皆さんのオンプレミス環境の計算基盤には、関連するトレーニングフレームワークがすべて揃っているとは限りません。インフラで頻繁に障害が起きることもありますし、私がある顧客のところで実際に見たケースでは、環境全体がSparkベースになっていることもありました。Sparkの上でLLMをトレーニングしようとするのは、率直に言って相当な苦労を伴います。
Lawrence： 二つ目はツールです。データの準備、モデルのトレーニング、モデルの評価、そしてデプロイといった、MLOpsのライフサイクル全体には、非常に多くの異なるツールが関わってきます。多くの場合、これらは断片化していて、互いにうまく連携しません。しかし本来は、特にチームで作業をしている場合には、誰が何をしていて、まだ何が終わっていないのかを把握できる状態が必要なのです。
Lawrence： 三つ目はバージョン管理です。これ自体は、コードについて考える場合には、実はそれほど難しい問題ではありません。しかし、機械学習について考えると、話はまったく別の種類の問題になります。トレーニングしているモデルについて、どのデータを使ってトレーニングしたのか、どのコードを使ったのか、どのコンテナを使ってトレーニングしたのかを、きちんと把握しておきたいはずです。必要であれば再現性を担保できる状態にしておきたいわけですが、これはガバナンスの問題にもつながってきます。どのデータに誰がアクセスできるのか、ガバナンスは適切に整備されているのか。これもまた、簡単には構築できないものです。
5.2 運用負荷・スキルアップ・データ・ROIの課題とまとめ
Lawrence： 四つ目は、運用と保守のオーバーヘッドです。自前でGPUクラスタを維持管理するのは、決して楽しい作業ではありません。パッチ適用を自分たちでやりたくないという方も多いでしょうし、それが理由でこれを自分たちでやることを躊躇するケースもあると思います。
Lawrence： 五つ目は、チームのスキルアップです。LLMとそのカスタマイズというのは、かなり最近になって出てきたものです。私たちは数十億パラメータ規模のモデルをトレーニングしているわけですが、自然言語処理について詳しいエンジニアの方はたくさんいらっしゃると思います。そういう方にとってはその部分はやりやすいかもしれませんが、それに加えて突然、GPUのプロファイリングについても考えなければならなくなります。
Lawrence： そして、この種のLLMカスタマイズを行う際に直面するボトルネックを、どうやって解消していくのかという課題もあります。さらにデータの課題もあります。先ほどAlexが見せてくれたような、さまざまなデータ形式があり、それを集めて、正しい課題のためにキュレーションしていくことは決して簡単ではありません。これはビジネスケースやROIの問題ともつながってきます。どのユースケースを選ぶのか、そしてどのユースケースであれば、自分たちのチームが正しいデータを集め、実際に役立つモデルを構築できると自信を持てるのか、という問題です。
Lawrence： その結果として何が起きるかというと、ほとんどのチームは、LLMをカスタマイズしようとしても、プロトタイプの段階を実際には抜け出せないままになってしまいます。だからこそ私は今日、こうした8つの課題のうち、少なくとも最初の5つについて皆さんを支援するサービスであるSageMakerについて、数分間お話ししたいと思っています。それによって、皆さんは残りの3つに集中していただけるようになります。
6. Amazon SageMakerによる解決アプローチとデモンストレーション
6.1 トレーニングジョブとサーバーレスモデルカスタマイズの概要
Lawrence： SageMakerは、かなり包括的なサービスです。機械学習モデルのビルド、トレーニング、デプロイを支援するサービスとなっています。今日は、その中でもトレーニングの部分に絞ってお話ししたいと思います。SageMakerは、主要なトレーニングフレームワークにそのままアクセスできるようになっており、自分たちでコンテナを構築する必要はありません。GPUクラスタへのアクセスも提供されており、これは皆さんが必ず必要になるものですので、非常に便利です。そして、バージョン管理、ガバナンス、デプロイといった課題も解決してくれます。
Lawrence： このトレーニングを行うには、大きく二つの方法があります。一つは、トレーニングジョブと呼ばれる考え方です。これは直感的な仕組みで、私たちが用意しているディープラーニングコンテナを利用します。自分たちで構築する必要はなく、用意されているものから一つを選ぶだけです。そして、使用したいコンピュートを指定します。多くの種類のGPUの中から選ぶことができ、コンピュートリソースの選択肢も豊富にあります。典型的なやり方としては、オープンソースのモデルを選び、例えばHugging Faceなどを見て、そのライセンスを確認し、自分たちにとって許容できるものを選んだうえで、自分たちでトレーニングコードを書いていくことになります。参考にできるサンプルも数多く用意されており、後ほどそのリンクもご紹介します。
Lawrence： ただ、もしこのトレーニングコードを自分たちですべて書きたくないという場合、確かにこれはかなり手間のかかる作業で、同時にとても面白い作業でもあるのですが、その場合に注目していただきたいのが、最近私たちがローンチしたサービスです。これは昨年12月のre:Invent以降に登場したもので、サーバーレスモデルカスタマイズと呼んでいます。私たちがこれをローンチした背景には、LLMをカスタマイズしたいと思っているものの、自分たちでファインチューニングのコードを書けるだけの専門知識を持たない、データサイエンティストではない多くのペルソナが存在するという考えがありました。
Lawrence： このサービスは、フルマネージドなトレーニングと評価の機能を提供します。トレーニングコードや評価コードを自分たちで書く必要はありません。モデルの選択肢も幅広く、GPT-OSS、Llamaファミリー、Qwenファミリー、DeepSeek、そして私たち自身の独自モデルであるNovaを選んでファインチューニングすることも可能です。これは本当に魅力的なポイントだと思います。そして、先ほどAlexandraが紹介してくれた各手法のファインチューニングコードについても、標準で対応しており、自分たちでそのコードを書く必要はありません。
Lawrence： この結果として、先ほどのスライドと同じことが言えるのですが、開発者はインフラの課題に頭を悩ませるのではなく、自分たちのドメインの専門知識を活かすことに集中できるようになります。SageMakerのサーバーレスモデルカスタマイズには、三つの利用経路があります。一つ目はSageMaker Studioを使う方法です。これはMLOpsのライフサイクル全体を一つの画面で管理できる、もう一つのサービスです。後ほど実際の画面をお見せします。とても直感的な作りになっています。私たちはまた、AIエージェントによるガイド付き体験もローンチしており、自然言語を通じてトレーニングジョブやLLMカスタマイズを操作、起動することができます。これはもしかすると、将来的にこうした作業を行っていく上での主流のやり方になるかもしれません。そして、コードベースのSDKという選択肢もあります。もちろん、コードを通じてこうした仕組みを操作したいという開発者の方々もいらっしゃいますので、そのための手段です。
Lawrence： お客様からよく聞かれるのは、こうしたサービスの裏側で実際に何が起きているのかということです。こちらは、サーバーレスモデルカスタマイズ、そして通常のトレーニングジョブについても当てはまる、高レベルの構成図とお考えください。実際の流れとしては、皆さんが図の左側にいる人になります。SageMaker Studio、あるいはIDEを使って、モデルカスタマイズのジョブを投入します。すると、そのために必要なコンピュート、つまりGPUがプロビジョニングされます。ここでは複数のGPUが登場していますが、これは素晴らしいことで、理論的には、こうした分散処理は自分たちで書いて構築するのが非常に大変な部分です。ここではそれが管理された状態で提供されます。そして、トレーニングが開始され、障害が発生した場合にはそれが処理され、ジョブが構築されては解体されていきます。
Lawrence： データはS3から読み込まれます。モデルはチェックポイント、つまり事前学習済みのモデルがジョブに読み込まれる形になります。ECR、Elastic Container Registryにはトレーニング用のイメージがあり、これはDockerコンテナのことです。ここでも、自分たちでそれを構築する必要はありません。もし非常に特殊な要件がある場合には、自分で構築することも可能です。そして、ML Flowも登場します。これは、トレーニングジョブに対する可視性を持ちたいからです。ハイパーパラメータが何だったのか、それが時間とともにどう変化したのか、例えば学習率のスケジュールがある場合にそれがどう推移したのか、あるいは重要なトレーニングメトリクスが時間とともにどう発展していくのかを見たい、といった場面で役立ちます。
6.2 SageMaker Studioでのデモと参加者向け案内
Lawrence： それでは、お約束していた通り、SageMaker Studioの画面がどのようなものか、実際にお見せします。ここではモデルを選択する画面になっており、いくつかの注目モデルが表示されています。Nova、Llamaなどです。今回は、Llamaの8Bモデルで、ベースモデルではなく、すでにInstructチューニングが施されているモデルを選んでみたいと思います。そして、これをカスタマイズするための三つの選択肢のうち一つを選びます。レーザーポインターも持ってきていますので、それも使いながらご説明します。
Lawrence： ご覧の通り、UI、AIエージェント、あるいはコードのいずれかでカスタマイズすることができます。今回はUIでカスタマイズしてみましょう。すると、このようなポップアップが表示されます。ここでは、上から順に、カスタマイズ手法を選択できます。対応している手法の一つが、RLVR、つまり検証可能な報酬を用いた強化学習(Reinforcement Learning with Verifiable Rewards)です。
Lawrence： 昨年、文献を少し読んでいた方であれば、この手法が話題になっていたことをご存知かもしれません。そして今でも注目され続けています。というのも、私たちが分かってきたこととして、強化学習では報酬モデルが必要になりますが、報酬モデルをトレーニングしたり、現在のモデルを報酬モデルとして使ったりする代わりに、決定論的な回答が存在する問題が数多く存在するということです。これは主に数学とコーディングの領域です。
Lawrence： そして、この手法は非常に幅広いモデルファミリーに適用され、数学とコーディングだけでなく、推論の能力についても実際にモデルを大きく改善することが分かってきました。ここでは、データセットをアップロードし、報酬関数を選びます。ここでは人間の選好アライメントが選ばれていますが、他にもさまざまな選択肢が用意されています。この報酬関数が実際にどのようなコードになっているのか、その例も画面に表示されています。
Lawrence： さらに、自分で報酬関数を構築して実験したいという場合には、独自のコードを持ち込むという選択肢もあります。あるいは、すでに用意しているLambda関数を選ぶこともでき、そのままクリックするだけで済みます。
Lawrence： それでは、SageMakerに関するパートの最後として、皆さんにぜひスマートフォンを取り出していただいて、これから表示する二つのQRコードのどちらかをスキャンしていただきたいと思います。より気に入った方をズームして、クリックしてみてください。左側は、より高度なモデルカスタマイズのワークショップです。こちらは、自分でインフラを立ち上げてテストしてみることができるもので、すでにトレーニングコードを書いた経験があり、ある程度の専門知識をお持ちの方向けの内容です。
Lawrence： そしてもう一つが、サーバーレス版です。こちらは、私が今お見せしてきた内容そのものになります。ぜひ触ってみて、これが皆さんにとってどんな意味を持つのか、感触をつかんでみてください。それでは、SageMakerに関する部分はここまでとして、サンフランシスコからの時差ぼけがひどくないことを祈りつつ、Nova Forgeについて話してもらうために、Markにバトンタッチしたいと思います。ありがとうございました。
7. Amazon Nova Forgeの紹介(Mark Andrewsパート)
7.1 Nova Forgeの概要とAIの特化(Specialization)という思想
Mark： ありがとうございます。Lawrence、ありがとう。それでは始めていきましょう。先ほどお見せしたように、皆さんの持つドメインの専門知識をモデルに吹き込むことのメリットの一つは、こちらの右側にあるように、皆さんの知的財産に関する理解を数多く備えたモデルを作り出せるという点にあります。
Mark： これが、モデルカスタマイズという考え方の全体像です。皆さんは皆、それぞれのドメインスペシャリストとしての専門知識をお持ちだと思いますが、その専門知識をモデルに吹き込む最良の方法は、モデルを深くカスタマイズすることです。そして実は、今日Novaを活用してこれを実現するための主要な手段の一つが、Nova Forgeと呼ばれるものです。
Mark： Nova Forgeを使うことで、Amazon Novaを使って自分たち独自のフロンティアモデルを構築することができます。先ほど申し上げた通り、自分たちの知的財産をデフォルトでモデルに吹き込むことができるようになるわけです。これによって、モデルは皆さんのドメインの専門知識について推論できるようになります。それが生化学であっても、金融サービスであっても、どんな分野であっても構いません。
Mark： 実は今日、興味深い論文を読みました。Yann LeCunは、AIの生みの親の一人として知られている人物です。彼が強調していることの一つに、AIは特化(specialization)を受け入れるべきだというものがあります。これは、主要なモデルプロバイダー、OpenAIであれ、Anthropicであれ、Geminiであれ、そしてNovaでさえも、Nova Forgeという例外を除けば、あまり見られない考え方です。
Mark： 興味深いのは、この特化という考え方です。人間について考えてみると分かりやすいのですが、私たちはよく汎用人工知能、いわゆるAGIについて耳にします。しかし、Yann LeCunたちは、それこそがモデルの知能について、より広く考える際の正しい捉え方ではないと、実は反論しているのです。
Mark： 人間の知能というのは、めったに汎用的なものではありません。むしろ非常に専門特化したものです。この会場にいる皆さん一人ひとりも、おそらく自分が集中して取り組み、得意としているドメインの専門知識をお持ちだと思います。誰もがすべてに秀でているわけではありません。医師が必ずしもコンピュータサイエンスに秀でているわけではありませんし、コンピュータサイエンティストが必ずしも生体医工学に秀でているわけでもありません。
Mark： そして、Yann LeCunたちは、これを非常に見事な言い回しで表現しています。タンパク質を折りたたむAIは、私たちの洗濯物を折りたたむAIであるべきではない、というものです。これはちょっとした冗談めいた表現だと思いますが、専門知識というものはすべて同じではないという事実を強調する上で、かなり重要な指摘だと思います。生化学の分野におけるタンパク質folding のドメイン知能と、ロボティクスによる洗濯物folding のドメイン知能とでは、非常に異なるドメインの知能が存在するのです。
Mark： これは、Mixture of Expertsモデルにおいても見て取ることができます。今日、主要なモデルプロバイダーが提供しているモデルのほとんどは、Mixture of Expertsの構造を採用しています。例えば、1兆パラメータ規模のモデルがあったとしても、そのすべての重みが毎回呼び出されているわけではありません。実際には、与えられた質問やプロンプトに応じて、専門特化した重みの集合だけが呼び出されているのです。
Mark： そして、私たちはこの方向に物事が進んでいくと考えています。もしGartnerの予測を信じるのであれば、先ほど私の同僚たちが触れていた通り、彼らが強調していた重要なポイントの一つは、2027年末までにほとんどのモデルがドメインスペシャリストになっているだろうということです。
7.2 基盤モデル構築プロセス(事前学習・中間学習・ファインチューニング)
Mark： それでは、基盤モデルを構築するということが、具体的にどのように行われるのかを見ていきましょう。私たちはまず、空のモデルから始めます。これは単なる骨組み、モデルの基礎となるアーキテクチャに過ぎません。ベースモデルは、二つの段階を経て作られます。一つ目が事前学習(pre-training)、二つ目が中間学習(mid-training)です。事前学習については、また例え話を使ってみたいと思います。今回は医療の分野の例えです。
Mark： 事前学習を、『グレイの解剖学』、つまりあのテレビ番組ではなく、医学書のグレイの解剖学だと考えてみてください。この医学書はおよそ1500ページに及ぶもので、世界でもっとも権威のある医学書の一つです。今日でも医学を学ぶ学生たちに使われ続けています。これは、モデルに非常に一般的で優れた世界知識を与えるものです。次に、中間学習について見てみましょう。
Mark： 例えば私たちが皮膚科のスタートアップだとします。この段階が重要になるのは、まさにここでモデルの知能と推論能力を、皮膚科というドメインに向けて特化させ、磨き上げ始めるからです。治療のレジメンなど、そうした細かい内容をすべて追加していくのが、この中間学習のフェーズです。そして、一番右側にあるのが、ファインチューニング済みのモデルです。これは、いわば最後の仕上げにあたる部分で、自分たちのビジネスが話してほしいような話し方をモデルにさせる、といったことを行います。
Mark： もう一度、これをもう少し詳しく見てみましょう。モデル構築の最初のフェーズである事前学習では、例えば一般的な世界知識、つまり膨大で多様なWebコンテンツを扱います。先ほどのグレイの解剖学のような長文のテキスト、コードリポジトリ、画像、そして動画も含まれます。基本的には、こうしたものを通じて、モデルの世界レベルの理解を作り出していくわけです。そして中間学習の段階では、モデルの推論能力を強化し始めます。これによって、皆さんが特化させようとしているドメインにおいて、正確にタスクを完遂するために、モデルが考え、推論できるようになっていきます。
Mark： そして、先ほどAlexが触れていた、もう二つの手法があります。一つはSFT、教師ありファインチューニングです。ここでは犬のしつけの例えが役に立つと思います。SFTは、いわば服従訓練の教室のようなもので、犬が基本的なテクニックを学ぶ場です。一方、強化学習は、初めて犬を公園に連れて行ったときのようなものです。良い行動を実際に強化していきたいわけですが、公園にはたくさんの気を散らすものがあります。ですので、おやつのようなご褒美を使いながら、たくさんの気を散らすものがある中でも正しく振る舞うように犬に教えていく必要があります。これが、強化学習がどのように働くかというイメージに近いものです。そして最終的な結果として得られるのが、完全にトレーニングされた事後学習済みのモデルです。
7.3 破滅的忘却への対策とNova Forgeの提供価値
Mark： Nova Forgeのメリットの一つとして、これはAlexも先ほど少し触れていたと思いますが、特に継続事前学習、CPTを使う場合に起こりうる、破滅的忘却(catastrophic forgetting)という問題があります。自分たちのドメイン知識を追加しすぎると、モデルの重みに影響が及び、その結果、指示追従能力(instruction following)のような重要な部分において、モデルが忠実性を失ってしまうことがあります。モデルが砕けてしまう、いわばバラバラになってしまうのです。私たちはこれに対応するために、事前学習、中間学習、事後学習の各段階で、複数のモデルチェックポイントへのアクセスを提供する仕組みを導入しました。
Mark： ただ、それ以外にも私たちが行っていることがあります。これは次のスライドの内容かもしれませんが、ここで触れておきたいと思います。もしかしたら後のスライドの内容かもしれませんが、時差ぼけのせいにしておきます。それは、データミキシングと呼ばれる仕組みです。データミキシングが重要なのは、私たちがAmazonの基盤モデルのトレーニングデータへのアクセスを提供し、それを皆さん自身のトレーニングデータと混ぜ合わせることができるようにしているという点です。
Mark： なぜ両方のデータセットを混ぜ合わせたいかというと、それが破滅的忘却を防ぐのに実際に役立つからです。このスライドでお伝えしたいのは、なぜ、より早い段階の学習チェックポイントで、自分たちのデータを追加すべきなのかということです。その理由は、継続事前学習や中間学習のフェーズでは、モデルが焼きなまし(アニーリング)フェーズに入る前よりも、はるかに高い学習率で動いているからです。
Mark： そして実際のところ、多くの方はこの事後学習のフェーズからトレーニングを始めます。ここが、SFTや強化学習、少なくとも強化学習の初期のステップが入ってくる場所です。しかし、もしモデルの一般的な能力そのものに影響を与えたいのであれば、実際には事前学習や中間学習のフェーズにまで遡って手を加える必要があります。この段階でこそ、モデルの重みにはるかに大きな影響を与えることができるからです。これが、データミキシングについてお話ししたかった内容です。まさに今申し上げた通りの仕組みになっています。
Mark： そして最後に、モデル開発に関して重要な点として、モデル開発というのはかなり複雑な作業だということです。私たちが12月にNova Forgeをローンチして以来分かってきたことの一つに、おそらくこの会場にいる多くの方も含めて、今日これを行うだけの科学的なノウハウを持ち合わせていない方が多い、ということがあります。だからこそ、AWSのGenAI Innovation Centerでは、体系立てられたアプローチを提供しており、実際にサイエンティストにハンズオンでアクセスしていただき、モデル開発のプロセスを通じてガイドしてもらえるようになっています。
Mark： それでは、今日はここまでとさせていただきます。皆さん、本当にありがとうございました。ご質問があれば、この後ぜひお気軽にお聞きください。