AIモデルカスタマイズ最前線：ParcelPerformとAWS Forgeが語る「大規模運用とビジネス価値」の真実

現代のビジネス環境において、AIはもはや単なる流行語ではありません。顧客体験の向上、業務効率化、新たな価値創造の基盤として、その導入と活用は企業にとって喫緊の課題となっています。しかし、次々と登場する「フロンティアモデル」と呼ばれる高性能な汎用AIモデルを、いかにして自社の特定のビジネス課題に最適化し、最大のビジネス価値を引き出すかという問いに、多くの企業が直面しています。

本記事では、AWS for AIポッドキャストの特別なエピソード「EP12: Forge & Parcel.ai | Model Customization at Scale」の内容を深く掘り下げ、この複雑な問いに対する実践的な洞察を提供します。ゲストとして登場するのは、年間数十億件もの配送データを処理するグローバルEコマース物流プラットフォームであるParcelPerformのデータ・インサイト部門責任者であるオリバー・グレイザー氏と、AWSでForgeおよびモデルカスタマイズを担当するプリンシパル・プロダクトマネージャーのカラン・バンダルカー氏です。彼らの経験と知見を通じて、AIモデルのカスタマイズがなぜ必要なのか、どのように行うべきか、そしてそれがビジネスにどのような変革をもたらすのかを詳細に解説します。

導入：AIの進化とカスタマイズの必要性

AI技術の進歩は目覚ましく、数週間おきに新たなフロンティアモデルが発表され、その汎用性と能力の高さには目を見張るものがあります。しかし、こうした最先端の巨大モデルが、必ずしもすべてのビジネスユースケースに最適な解を提供するわけではありません。特に、独自のデータ、特定の専門領域、あるいは厳格なビジネス要件を持つ企業にとっては、モデルの「カスタマイズ」が不可欠な戦略となります。

本エピソードでは、AIを大規模に運用するチームが必ず直面する「モデルをカスタマイズすべきか、それとも既存の最新モデルをツールとして使うべきか」という根本的な問いに挑みます。この議論の中心には、ParcelPerformがAmazon Novaをファインチューニングすることで、より小さいモデルでありながら、精度、コスト、速度の面で大規模モデルを凌駕したという、直感に反する驚くべき成果があります。

オリバー・グレイザー氏は、香港中文大学で理論物理学の博士号を取得後、金融リスクモデリングを経て物流とAIの世界へ。TensorFlowのリリース当初から本番環境でのAI導入を経験し、現在はParcelPerformのデータ部門を統括しています。一方、カラン・バンダルカー氏は、電気工学のバックグラウンドを持ち、金融サービス業界でAIシステム開発に携わった後、AmazonのAlexaチームを経て、現在はAWSのモデルカスタマイズ製品を担当しています。企業が基盤モデルを特定の用途に合わせて評価・最適化するためのフレームワークを構築し、厳格な評価に基づく意思決定と、専門知識の異なるチームでも高度な技術を利用可能にすることを目指しています。

彼らの対話を通じて、ParcelPerformがなぜプロンプトエンジニアリングではなくファインチューニングを選んだのか、なぜ小さいモデルが巨大な汎用モデルを上回ったのか、そしてプロダクションでのファインチューニングにおけるデータと評価の現実、さらにカラン氏がForgeの顧客から見ている広範なパターンについて深く掘り下げていきます。

モデルカスタマイズの「なぜ」：フロンティアモデルでは不十分な理由

「なぜ、わざわざモデルをカスタマイズする必要があるのか？」これは、フロンティアモデルが次々と登場する現代において、多くの企業が抱く疑問でしょう。オリバー氏とカラン氏は、この疑問に対し、経済性、精度、速度、そして特定のビジネス要件への適合という多角的な視点から、カスタマイズの必要性を明確に論じています。

フロンティアモデルの限界とビジネスユースケース

オリバー氏はまず、フロンティアモデル（例えばGPT SoulやOpus 5のようなモデル）を直接ファインチューニングすることは、現実的ではないと指摘します。これらのモデルは非常に巨大であり、多くの場合、非常に正確な指示（プロンプト）を与えるだけで、望ましい動作を実現できます。不必要なカスタマイズは、膨大なコストとデータ処理を伴うため、経済的合理性に欠けることが多いのです。

しかし、ビジネスユースケースを深く掘り下げると、汎用モデルだけでは対応しきれない課題が見えてきます。オリバー氏が例に挙げるのは、「ログの読み取り」や「チャットログの追跡」といったタスクです。人間にとっては退屈で非効率的、あるいは不可能に近いこれらのタスクこそ、AIが真価を発揮する領域です。

ParcelPerformの場合、年間数十億件、時には1秒間に1,000件以上の配送データ更新を処理する中で、非構造化データソース（フリーテキスト、HTMLをテキスト化したもの）から構造化された情報を抽出するという具体的な課題に直面していました。当初、ChatGPT3.5 Turboのようなモデルを試しましたが、すぐにその「高コスト」と「スケーラビリティの欠如」が明らかになりました。

そして、最も深刻な問題の一つが「ハルシネーション（幻覚）」です。LLM（大規模言語モデル）は、どんな質問に対しても何らかの回答を返そうとする傾向があります。しかし、その回答がデータに基づかない「作り話」である場合、データ抽出の信頼性が根本から揺らぎます。「嘘をつかないで」と指示しても、モデルはパターンに陥りがちで、誤った情報を生成してしまうのです。このハルシネーションを抑制し、信頼性の高い情報抽出を実現するためには、モデルのカスタマイズが不可欠であると、ParcelPerformは結論付けました。

AWSが顧客から見るカスタマイズの動機：品質、スピード、コスト

カラン氏は、世界中のAWS顧客との対話から、モデルカスタマイズの動機を三つの主要な要素に集約します。それは「品質（精度）」「スピード（レイテンシ）」「コスト」です。

品質（精度）: 基盤モデルは素晴らしい進化を遂げていますが、特定のユースケースやタスクに対して、顧客の厳格なニーズを満たすだけの精度を提供できるとは限りません。オリバー氏のビジネスにおける「ハルシネーションの抑制」のように、特定の品質要件がビジネスとして妥協できないレベルにある場合、カスタマイズは必須となります。特定の分類タスクなど、汎用モデルでは十分なパフォーマンスが得られない場合に、そのタスクに特化した小型モデルをカスタマイズすることで、精度を飛躍的に向上させることが可能です。
スピード（レイテンシ）: 大規模モデルは、その複雑な処理ゆえに、応答に数秒を要することがあります。しかし、すべてのユースケースがその「思考時間」を待てるわけではありません。迅速な応答時間が求められるタスクやユースケース（例えばリアルタイムの顧客対応や、システム連携）においては、数百ミリ秒以内の応答が必要となることがあります。カスタマイズによって、このインテリジェンスをより小さなモデルに組み込むことで、レイテンシを大幅に短縮し、ビジネス要件を満たすことができます。
コスト: 今年、トークン数とそれに伴うコストの重要性はかつてないほど高まっています。大規模な汎用モデルを使用するたびに発生するトークンコストは、大規模な本番環境での展開においては莫大なものとなり得ます。カスタマイズは、費やすトークンコストに対して得られるインテリジェンスを最適化する手段です。特定のタスクに特化させ、より効率的に動作する小型モデルを使用することで、運用コストを劇的に削減することが可能になります。

さらにカラン氏は、カスタマイズが企業に「独自のプロプライエタリデータや専門知識を活用する機会」を与え、競争上の優位性を確立する道を開くと強調します。汎用モデルには存在しない、自社独自のニッチな領域における知識をモデルに組み込むことで、市場での差別化を図ることができるのです。

これらの側面は、顧客がAIを本番環境へ導入する際、あるいは検討する際に重要視する本質的なポイントであり、精度、レイテンシ、コストのいずれか、あるいはそれらの組み合わせが、汎用モデルではうまくいかない場合にカスタマイズの検討が始まります。

モデルカスタマイズの経済合理性：ROIと意思決定

モデルのカスタマイズを検討する際、最も重要な要素の一つが「経済合理性」、すなわちROI（投資対効果）です。小さなモデルの利用はトークンあたりのコストを抑えることができますが、モデルのカスタマイズ自体にもコストが発生します。このバランスをどのように評価し、意思決定を下すべきでしょうか。

カスタマイズコストと推論コストのバランス

カラン氏は、カスタマイズのROIが最終的な判断基準であると明言します。「カスタマイズすべきか否か」という問いへの答えは、ビジネスシナリオ、ユースケースの特性、運用規模、そしてモデルの精度が低下したりハルシネーションが発生したりした場合のビジネスリスクによって異なります。

まず、堅牢な評価フレームワークを構築し、精度、レイテンシ、コストという三つの成功基準を明確に定義することが不可欠です。それができたら、ROIの計算に取りかかります。例えば、モデルのファインチューニングにかかる費用は数十ドルから数百ドル程度かもしれません。しかし、もしモデルがハルシネーションを起こしたり、間違った結果を出したりした場合、ビジネスにどのような損失が発生するでしょうか？顧客の信頼失墜、オペレーションのやり直し、コンプライアンス違反など、そのコストはファインチューニングの費用をはるかに上回る可能性があります。

オリバー氏も、ファインチューニング自体のコストは「かなり微々たるもの」だと強調します。それよりも大きな問題は、「ファインチューニングしたフルモデルをデプロイするために専用のハードウェアが必要になるかどうか」という点でした。ビジネスニーズが常に一定ではない場合、専用インスタンスのデプロイはCFOを説得するのが困難です。この点において、LoRA（Low-Rank Adaptation）のようなパラメータ効率の良いファインチューニング手法は、大きなメリットをもたらします。これにより、専用ハードウェアが不要になり、変動の激しいワークロードでも、基盤モデルの従量課金制を維持しながらカスタマイズモデルを利用できるため、経済合理性が格段に向上します。

ROI算出の開始点とAWS Bedrockの貢献

カスタマイズをまだ開始していない企業にとって、具体的なROIをどのように算出し始めればよいのでしょうか。オリバー氏は、そのアプローチは比較的単純であると述べます。

まず、フロンティアモデルが現在のビジネス課題を解決できるか、そしてそれによってROIが得られるか、あるいは最初から見込みがないかを検討します。もしフロンティアモデルでROIが見込めるなら、「もっと安価なモデルで対応できるはずだ」という仮説が生まれます。

かつて、GPT-3.5 Turboのようなモデルを微調整できる場所や、その費用を事前に確認できる場所は限られており、「設定は難しいだろうし、よく分からない」という答えが返ってくるのが常でした。しかし、AWS Bedrockのようなサービスは、この状況を大きく変えました。Bedrockを使えば、カスタマイズに必要な大規模なインスタンスが1時間あたりいくらかかるのか、3日間利用する場合の総費用はいくらになるのかを、明確に把握できます。金額の多寡ではなく、「最終的にいくらかかるのか」を知る術があることが重要なのです。この透明性があれば、企業は具体的な数値を基に「これくらいのコストがかかるだろう」と予測し、大局的に「これくらい節約できるだろう」という議論を進めることができます。

カスタマイズすべきではないユースケース

一方で、カラン氏は「カスタマイズすべきではないユースケース」についても明確な見解を示します。それは「特定のユースケース」というよりは、「評価基準にかかっている」という普遍的な原則です。

カラン氏は「直感で判断すべきではない。証拠に基づいて判断すべきだ」と強調します。もしフロンティアモデルが、必要な精度、レイテンシ、コストの要件をすでに満たしている、あるいはそれに近いのであれば、カスタマイズは不要です。多くの場合、プロンプトエンジニアリング、RAG（Retrieval Augmented Generation）、適切なコンテキスト設定、そしてモデルを補完する適切な仕組み（エージェント型フレームワークなど）を通じて、十分なパフォーマンスに到達可能です。カスタマイズは、既存の有効なソリューションに代わるものではありません。

カスタマイズが真に価値を発揮するのは、汎用モデルには存在しない「独自のプロプライエタリなデータや専門知識」がある場合です。これにより企業は独自のニッチを切り開き、自社の情報やデータを競争上の優位性として活用できます。つまり、「これらはカスタマイズすべきではないユースケースだ」と一括りにすることはできません。金融サービスでもヘルスケアでも、カスタマイズすべき場合とそうでない場合があります。最終的には、「自分にとって何が『良い状態』なのか」を明確に定義し、利用可能なあらゆるモデルを評価し、最も近いものを見極めることが重要です。

まとめると、モデルのカスタマイズは意識的な判断に基づき、コスト、精度、速度、そして実際のビジネスニーズを総合的に考慮して行うべき戦略的選択であると言えます。

ParcelPerformの具体的な成功事例：ハルシネーションの克服とデータ戦略

ParcelPerformのオリバー・グレイザー氏は、モデルカスタマイズが具体的なビジネス課題にいかに貢献したかについて、その詳細を語ってくれました。彼らの最初の、そして最も成功したケースは、「非構造化データからの構造化情報抽出」でした。

非構造化データからの情報抽出とハルシネーションの克服

ParcelPerformが直面していた課題は、フリーテキスト、特にHTMLをテキスト化したデータから、具体的な情報を抽出することでした。元々HTMLに含まれていた情報がテキスト化の過程で失われることもあり、AIモデルはしばしば情報を「でっち上げる」、すなわちハルシネーションを引き起こしていました。これは、モデルが期待に応えようと必死になるあまり、情報が存在しない場合でも何らかの回答を生成してしまう傾向があるためです。

オリバー氏はこの問題を「ファインチューニングに適した問題」と捉えました。なぜなら、何かを改善したか悪化したかを非常に正確に測定できるからです。抽出された要素の重要度を把握していたため、簡単にスコアを算出し、ファインチューニングによってそのスコアがどう変化するかを客観的に評価できました。Amazon Novaのmicro、light、proといった異なるモデルサイズで試した結果、より小さいモデルをLoRA（Low-Rank Adaptation）でファインチューニングした後、以前見られたハルシネーションの問題が「完全に解消された」とオリバー氏は述べています。

以前は、抽出されたフィールドの値がテキストの全く別の場所にあったり、モデルが記憶から引き出したと思われるようなケースが頻繁に見られました。しかし、ファインチューニング後は、これらの問題はほとんどなくなり、モデルは情報が存在しない場合には空の文字列を返すようになりました。これは、モデルが「嘘をつかない」ことを学習したことを意味し、データ抽出の信頼性を飛躍的に向上させました。

一方で、オリバー氏は別のケース、約250種類のクラスへのテキスト分類タスクについても言及しています。このケースではファインチューニングを試みましたが、フロンティアモデルの性能には到達できませんでした。ここでの重要な教訓は、ファインチューニングが常に最適な解決策であるとは限らないということです。問題の性質と、ファインチューニングによって測定可能な影響があるかどうかが、その選択を決定する上で最も重要な部分となります。

データセットの量と質：驚くべき少量のデータで実現

ファインチューニングの成功には、しばしば膨大な量のデータが必要だと考えられがちです。しかし、ParcelPerformの事例は、この常識を覆します。彼らが情報抽出のユースケースに使用したデータ量は、全部合わせて「1万サンプル程度」でした。オリバー氏自身もその少なさに驚いたと語っています。

彼らが観測したところ、損失関数は一直線に下がり、用意したデータの約20％を学習した時点で、モデルはすでに必要なことを理解し、損失関数は非常に低い値になっていたそうです。それ以上のデータを与えても、損失関数の減少はほとんど見られず、ノイズしか残らなかったとのこと。これは、モデルが単にサンプルから「このトークンを見たらこう出力してはいけない」と学ぶのではなく、「作り話をしてはいけない」というより高次元の抽象化されたルールを理解したことを示しています。

この成功の鍵は、データ量の少なさだけでなく、「データの品質」にありました。オリバー氏は「データの品質は非常に高かった」と評価しています。彼らは人間による手作業のラベル付けではなく、生成的な設定で高品質なデータを生成しました。具体的には、最高レベルの基盤モデルにまずデータを処理させ、その出力結果を同じモデルの別のエージェントに評価させるというプロセスを採用しました。このエージェントループにより、モデルが「回答したい」という意欲から「間違った回答はしない」という姿勢へと変わるよう促し、情報が存在しない場合には空の文字列を返すようなデータを十分に生成できました。

カラン氏も、この点についてオリバー氏の意見に同意し、「カスタマイズは魔法ではない。ゴミを入れればゴミが出てくるだけだ」と強調します。モデルに何をさせたいかを反映したデータ品質が不可欠であり、品質は間違いなく量よりもはるかに重要であると述べています。データ量については、モデルが実行すべきタスクからどれだけ離れているかによって変わります。タスクに近いのであれば少量の高品質なサンプルで十分ですが、全く新しいタスクを教える必要がある場合は、より多くのサンプルが必要になる可能性があります。

ParcelPerformの事例は、高品質なデータと適切なファインチューニング手法（LoRA）を組み合わせることで、少量のデータでも既存のフロンティアモデルの性能を上回り、ビジネスに直接的な価値をもたらすモデルを構築できることを明確に示しています。これは、限られたリソースの中でAI活用を進めたい企業にとって、非常に重要な示唆を与えるものです。

モデルカスタマイズの技術的アプローチ：学習フェーズと課題

AIモデルのカスタマイズには、いくつかの異なる学習フェーズが存在します。カラン・バンダルカー氏は、基盤モデルが開発されるプロセスになぞらえて、これらのフェーズを事前学習、中間学習、ファインチューニング、そして強化学習として説明し、それぞれの役割とカスタマイズにおける適用方法を解説しています。

学習フェーズの構造と役割

事前学習（Pre-training）: これは、モデルに汎用的なドメイン知識を詰め込む段階です。例えるなら、言語を学ぶ人に辞書や百科事典を与えるようなものです。モデルは、後に続くあらゆるタスクに必要な、膨大な量のテキストデータから言語の構造、事実、一般的な概念などを学習します。
中間学習（Intermediate-training）: この段階では、特定の領域で推論する方法をモデルに教え込みます。事前学習で辞書を学んだ後、中間学習ではその言語を使って思考する方法、例えば文章の構成方法などを学び始める段階です。これにより、モデルは特定のドメインの専門知識や推論パターンを獲得します。
ファインチューニング（Fine-tuning）: 中間学習の後、ファインチューニングは、その言語を使って特定のタスクを実際に成し遂げる方法を学ぶ段階です。モデルはすでに言語を習得し、思考できる状態ですが、特定の質問（例: 「XYZビルはどこにありますか？」）に答えるなど、具体的なタスクを実行する方法を学びます。オリバー氏のParcelPerformの事例は、このファインチューニングの典型です。
強化学習（Reinforcement Learning - RLHFなど）: 強化学習の段階では、モデルは知識を持ち、タスクのやり方もわかっています。ここから、自分のニーズや好みに合わせて、モデルの精度や振る舞いをさらに磨き上げていきます。例えば、特定の地域で言語を使う際、どのように依頼すれば最も効果的か、といったニュアンスを学ぶ段階です。モデルがドメインやタスクを理解していても、望ましい動作をしない場合に強化学習が適用されます。

カラン氏によると、私たちが接するほとんどの顧客は、現在の基盤モデルが進化を続けており、多くの分野で必要とされる一般的な知識はすでに備わっているため、「ポストトレーニング」（ファインチューニングや強化学習）の段階から始めることが多いとのことです。つまり、モデルにはタスクの内容と、そのタスクの望ましいやり方の両方を教えているのです。もし問題がより大きく、モデルがドメインそのものを知らない場合は、事前学習から始める必要があり、その後、ファインチューニングでタスクを教え、強化学習で望ましい振る舞いを最適化していきます。

破滅的忘却とその対策

モデルカスタマイズ、特にファインチューニングの初期段階で懸念されるのが「破滅的忘却（Catastrophic Forgetting）」です。これは、新しいタスクやデータに学習させることで、モデルが元々持っていた汎用的な能力や知識を忘れてしまう現象を指します。

AWS Forgeでは、この問題に対処するため、顧客が独自のデータと組み合わせて使えるよう、Amazonがキュレートした汎用データを提供しています。新しい能力やドメイン情報を学習する際に、この汎用データを混合することで、モデルが忘却しないよう、その汎用的な知識を補完していきます。これは、教えている内容に過度に最適化しすぎず、モデルが他の重要なことも覚えておく必要があるという考え方に基づいています。

破滅的忘却は事前学習だけの問題ではありません。大規模なファインチューニング、特に複数のタスクを学習させようとするマルチタスクモデルのシナリオでも見られます。例えば、4～6種類の関連するタスクを学習させることで、基盤モデルが本来備えている「指示追従」のような汎用的な能力が低下してしまうケースがあります。そのため、AWSはファインチューニング用の汎用データも提供し、マルチタスクモデルの訓練時にこれらを混ぜることで、汎用能力の低下を防いでいます。

汎用データを混ぜるメリットは、破滅的忘却を防ぐだけでなく、モデルが学習させているタスクに対してもより良く汎化するようになるという点にもあります。ファインチューニングのデータセットで考慮していなかったようなエッジケースに直面しても、モデルが以前見たものと関連付けて適切に推論できるようになるのです。

PEFT (LoRA) の技術的メリット

オリバー氏がParcelPerformの事例で採用したLoRA（Low-Rank Adaptation）は、PEFT（Parameter-Efficient Fine-Tuning）と呼ばれるパラメータ効率の良いファインチューニング手法の一つです。カラン氏は、この手法の主な違いについて詳しく解説しています。

LoRAのようなPEFT手法は、モデルの重み（パラメーター）を直接調整するわけではありません。代わりに、学習に使用したデータに合わせてカスタマイズされた「アダプター」を構築し、それを既存のモデルの上に乗せる形になります。推論時には、このアダプターを経由してモデルに要求が送られ、結果が返ってきます。

このアプローチの最大のメリットは、推論フェーズでのコスト削減と柔軟なスケーラビリティにあります。フルファインチューニングを行うと、モデル全体の重みが変更されるため、そのモデルをホスティングするには、そのモデル全体をメモリにロードし、専用のリソースを確保する必要があります。これは、大規模で一貫したスループットが必要な場合には有効ですが、ワークロードにスパイクがあったり、バッチ処理のように長期間にわたって大規模な推論が不要なシナリオでは非効率的です。

LoRAでは、アダプターは元のモデルよりもはるかに小さいため、複数のアダプターを同じ基盤モデルインスタンス上で共有してホスティングできます。これにより、必要に応じてコストをスケールアップ・ダウンできるため、大幅な運用コスト削減につながります。つまり、PEFT手法を選択するか、フルファインチューニングを選択するかは、本質的に推論の提供における「正確なプロファイル」が何かによって決まります。カスタマイズのコストだけでなく、全ライフサイクルを通じて本番環境での実行コストを最適化できるかが重要な判断基準となります。

評価フレームワークの重要性：成功を定義する

モデルのカスタマイズが成功したかどうかを判断するためには、厳密で効果的な「評価フレームワーク」が不可欠です。オリバー氏とカラン氏は、それぞれ異なる視点からこの評価の重要性とその複雑性について語っています。

「良い状態」の定義とビジネスニーズへの合致

カラン氏は、カスタマイズのプロセス全体を通じて「何が良質か」を定義することの重要性を繰り返し強調します。これは単に技術的な指標を追うだけでなく、ビジネスニーズに実際に合致した評価指標を定義することに他なりません。一度「良い状態」が明確に定義されれば、モデルの選択、カスタマイズの是非、そしてその効果を判断するための具体的な指針となります。

オリバー氏のParcelPerformのユースケースでは、この評価が比較的単純で信頼性の高いものでした。彼らは非構造化データから構造化情報を抽出するタスクに取り組んでおり、自身が正解を知っているため、モデルの出力が正解とどれだけ一致するかを明確に測定できました。この「測定可能であること」が、ファインチューニングの選択とその効果を信頼する大きな理由となりました。モデルがハルシネーションを起こさないよう学習した結果、以前は存在したエラーが解消されたことを明確に確認できたのです。彼の場合、モデルが他のすべてを忘れてしまっても、この特定のタスクを正確に実行できれば問題なかったため、評価範囲外の性能低下を気にする必要はありませんでした。

複雑なユースケースにおける評価の課題とエージェント的アプローチ

しかし、すべてのユースケースがParcelPerformのように明確な評価基準を持てるわけではありません。オリバー氏は、エア・カナダのチャットボットが顧客に言いくるめられて規定外の返金を約束してしまった事例を挙げ、カスタマーサービスのような複雑な文脈では、モデルの行動を予測し、適切に評価することが格段に難しいと指摘します。

このような状況では、「入力したテキストに対して正しい回答をしてほしい」と願っても、モデルが参照する膨大なテキストデータ全体を制御することは不可能です。オリバー氏は、このようなケースをファインチューニングで解決しようとするのではなく、「エージェント的なアプローチ」で解決すべきだと提案します。つまり、モデルを単体で使うのではなく、複数のAIエージェントやツールを組み合わせたフレームワークの中で、モデルをコントロールするという考え方です。

例えば、「カスタマーサービス担当者と顧客の対話を見て、これがまだ正気と言えるか？」「カスタマーサービス担当者の発言をまだ信頼できるか？」といった問いをエージェントに投げかけ、エージェント自身が介入して別の対応をとる必要があると判断させるのです。このようなビジネスの文脈では予測不可能な要素が多すぎるため、ファインチューニングだけでは不十分であり、より洗練された制御メカニズムが必要になります。

カラン氏も、プロンプトエンジニアリング、RAG、カスタマイズ、エージェント型フレームワークは、二者択一の関係ではなく、いくつかの要素の組み合わせ（and/or）であると強調します。たとえカスタムモデルを使用しても、どのように制御するかというプロンプトは依然として必要であり、適切なツールセットを備えたハーネスで補完し、モデルにどのツールが利用可能で、どのツールが利用できないかを認識させる必要があります。結局のところ、求める結果に応じて、プロンプト、コンテキスト、トレーニング、推論ハーネスにはそれぞれの役割があるのです。

AWS Forgeを活用したカスタマイズプロセス

AWSは、これらのモデルカスタマイズと評価の複雑性を解消し、企業が容易にAIを本番環境へ導入できるようにするための製品として「Forge」を提供しています。カラン氏の説明によると、AWSにおけるモデルカスタマイズのプラットフォームは主にSageMakerであり、カスタマイズされたモデルは、必要なインスタンス環境に応じてSageMakerまたはAmazon Bedrockにデプロイされます。

SageMakerは、深いAI/MLの専門知識がないユーザーでも簡単にカスタマイズできるように設計されています。SDKベースの体験とUIベースの体験の両方を提供しており、ユーザーはウィンドウを開いて必要なモデルとテクニック（例えばLoRAなどのPEFT手法）を選択し、データを指定して実行ボタンを押すだけでトレーニングを開始できます。もちろん、S3バケットで適切な形式にデータを準備し処理しておく必要はありますが、このようなトレーニングの実行は、以前と比べて格段に容易になっています。

オリバー氏も、顧客の立場からAWSが提供するプラットフォームの使いやすさを高く評価しています。「データサイエンティストやAIの専門家ではない場合どうするのか」という疑問の多くが解消されたと述べており、好みのAIと十分なドキュメントがあれば、基盤となる仕組みや手順を一通り進めることは可能だと考えています。

しかし、最も重要なのは、始める前に「成功の定義」ができているかどうかです。ホールドアウトデータでうまくいくという結果が出たとしても、それが現実のビジネスで通用するという自信を持てるかどうかが、解決すべき核心部分であり、現時点ではどんなAIも代わりにやってはくれません。その先、製品を本番環境へ移行するプロセスは、AWSのモデルレジストリなどを利用することで比較的スムーズに行えるとのことです。

結論として、効果的なモデルカスタマイズには、技術的な手法だけでなく、ビジネス目標に合致した明確な評価フレームワークの確立が不可欠です。AWSのようなプラットフォームは、このプロセスを技術的に容易にしますが、ビジネス的な成功を定義し、その評価を継続的に行うのは、あくまで企業の責任であり、その投資がROIの鍵を握っています。

CTOへの提言：AI戦略の確立

ポッドキャストの終盤で、オリバー氏とカラン氏は、異なる制約を抱えたプロジェクトが持ち込まれる中でAIモデルのカスタマイズについて意思決定を下すCTOに向けて、それぞれの経験から得た最終的な洞察と提言を述べました。

オリバー・グレイザー氏の提言：「タスクをこなせるならモデルは小さいほどいい」

オリバー氏のCTOへの最も重要なメッセージは、**「哲学として言えば、タスクをこなせるならモデルは小さいほどいい」**というものです。彼はこの考え方を、制御性、コスト、そして将来性の観点から支持します。

制御性: 小さいモデルは、その動作をより制御しやすくなります。大規模で汎用的なモデルはブラックボックス性が高く、予期せぬ振る舞いやハルシネーションを完全に排除するのが困難です。しかし、特定のタスクに特化してファインチューニングされた小型モデルは、そのタスクに最適化されているため、より予測可能で信頼性の高い結果を生成します。
コスト: 小さいモデルは、推論にかかるトークンコストが低く、ハードウェアリソースも少なくて済みます。これは、大規模なAIワークロードを本番環境で運用する上で、持続可能な経済性を実現するために不可欠です。ParcelPerformの事例が示すように、ファインチューニングの初期コストは微々たるものであり、長期的な運用コスト削減効果がはるかに大きいのです。
将来性: オリバー氏は、小さなモデルであれば「いずれ自分たちでホストできるようになるかもしれない」という可能性に言及します。これは、特定のクラウドプロバイダーやモデル提供者のロードマップ、価格設定、ポリシーに依存せず、自社のAI資産を完全に制御できるという究極の目標を示唆しています。誰も突然サービスを打ち切ってAIを使えなくさせるような事態は、ビジネスにおいてはあり得ません。自社でモデルをコントロールできれば、そうしたリスクを回避し、ビジネスの継続性を確保できます。

オリバー氏は、この取り組みから得た最大の収穫は、たとえ今回のユースケースが比較的単純であったとしても、「AIを完全に制御下に置いて、自分の思い通りに動かせる段階に来ている」という確信だと述べます。最近登場しているAlibabaの270億パラメータのモデルが1年前なら最先端だったように、小型モデルの性能は飛躍的に向上しており、カスタマイズによって大きな価値を生み出すことが十分に可能であると強調しています。

カラン・バンダルカー氏の提言：「評価に投資せよ」

カラン氏のCTOへの核心的なアドバイスは、**「評価に投資せよ」**というものです。彼は、モデルカスタマイズが企業にとって「独自の最先端AIモデルを所有するチャンス」であり、それによって「独自のロードマップと運命を自分でコントロールできる」道筋であると述べます。そして、独自のデータと専門知識を活用することで、常に進化する市場で差別化を図ることが可能になると強調します。

しかし、多くのCTOは「それはAWSの立場ならそう言うだろう」「カスタマイズすべきかどうかの判断基準は？どのモデルを選ぶべきか？」と疑問を抱くでしょう。カラン氏は、これらの問いに対する唯一の答えが「評価への投資」にあると断言します。

「何が良質か」の定義: 評価に投資することで、企業は「何が自分にとって良質なモデルのパフォーマンスであるか」を明確に定義できます。この定義がなければ、どのモデルを選ぶべきか、カスタマイズが本当に必要か、そしてその効果がどれほどあったかを客観的に判断する材料がありません。ビジネス目標に合致した具体的な評価指標を確立し、それを継続的に追跡することが、AI戦略の成功の土台となります。
モデル選択と効果測定の基準: 厳密な評価基準があれば、複数のフロンティアモデルやカスタマイズモデルを比較検討し、自社のニーズに最も合致する最適なモデルを選択できます。また、カスタマイズを行った場合に、それがビジネスにどのようなポジティブな影響を与えたか（精度向上、レイテンシ短縮、コスト削減など）を定量的に測定し、ROIを明確に示すことが可能になります。

カラン氏は、「とにかく、評価に投資することだ。その過程で、我々（AWS）がカスタマイズを最高に簡単にしてみせる」と締めくくります。つまり、AWSは技術的な障壁を取り除き、カスタマイズの実行を容易にしますが、そのカスタマイズがビジネスに価値をもたらすかどうかを判断する責任は企業側にある、というメッセージです。

まとめと今後の展望

本ポッドキャストのエピソードは、AIモデルのカスタマイズが、技術的な問題である以前に、経済的かつ戦略的な問題であることを明確に示しています。一日数百万もの推論呼び出しを行う企業にとって、汎用モデルと特化型カスタマイズモデルの差は、単なる精度の違いにとどまりません。それは、持続可能なスケーリングとビジネスの競争優位性を実現できるかどうかの違いなのです。

オリバー・グレイザー氏は、ParcelPerformの事例を通じて、本番環境での成功に必ずしも膨大なデータセットや巨大なモデルは必要ないことを実証しました。良質なデータセット（たとえ少量であっても）、小型のモデル、そして厳密な評価があれば、驚くべき結果がもたらされます。特に、ハルシネーションの抑制という具体的な課題を、少量の高品質データとLoRAによるファインチューニングで解決した事例は、多くの企業にとって勇気を与えるものです。

カラン・バンダルカー氏は、より広い視点から、プロンプトエンジニアリングからカスタマイズへ移行しようとするあらゆるチームが直面するパターンとアンチパターン、そして利用可能なツール（AWS Forge、SageMaker、Bedrock）を提示してくれました。彼のメッセージは、カスタマイズが単なる技術的選択肢ではなく、企業が独自のロードマップと運命をコントロールし、他者のロードマップや価格設定、方針に依存せずにフロンティアモデルを構築するための手段であるということです。

AIワークロードを大規模に運用し、まだモデルのカスタマイズを検討していない企業にとって、このエピソードは確実な第一歩となるはずです。AIの未来は、少数の巨大モデルと、特定のニッチなニーズに対応する多数の特化型小型モデルが共存する世界へと向かっているというカラン氏の展望は、今後のAI戦略を考える上で重要な指針となります。

最終的に、AIを活用してビジネス価値を最大化するには、意識的な意思決定が不可欠です。それは、コスト、精度、速度といった要素を考慮し、最も重要な「ビジネスニーズに合致した評価指標」を確立し、それに継続的に投資することから始まります。この原則を遵守することで、企業はAIの真の可能性を引き出し、競争の激しい市場で優位性を確立できるでしょう。