10月30日、AWSが「How BMW builds toward Industry AI on Amazon SageMaker AI」と題した記事を公開した。BMWグループがAmazon SageMaker AI上でLoRAアダプターを活用し、製造業向けのドメイン特化型AIを構築した実装事例が詳しく紹介されている。8Bの小型モデルが4倍のサイズを持つプロンプトベースモデルにほぼ匹敵し、特定指標ではそれを上回った結果は、製造業LLM実装の設計指針として注目に値する。
「プロンプトだけでは制御できない」——BMWが直面した壁
製造業でLLMを実用化しようとすると、すぐに壁にぶつかる。社内の固有プロセス、独自の分類体系、品質基準といったものは公開学習データには含まれていない。プロンプトに詳細なルールを書き込んでも、複数の制約が同時に課されると、モデルはそれらを「守るべきハード制約」ではなく「参考程度のソフト制約」として扱ってしまう。
BMWグループがAWSのForward Deployed Engineering（FDE）チームと12週間かけて取り組んだのは、この問題を構造的に解決することだった。なお、FDEとはAWSが顧客の現場に技術者を常駐させ、実装を伴走支援する専門チームを指す。
対象ユースケース：インシデント管理ワークフロー
証明の場として選ばれたのは、BMW社内のエンジニアリングインシデント管理ワークフローだ。車両開発中に発生する設計上の問題をトラッキングするシステムで、データは英語とドイツ語の約半々という二言語構成になっている。
スコープは以下の2タスクに絞られた。
- チケット品質保証（生成タスク）: インシデントチケットのタイトル・説明文の標準構造への書き換え、および不足情報を引き出すための確認質問の生成
- インシデントマッチング（判別タスク）: 新規インシデントに対して1〜8件の過去インシデント候補を提示し、同一根本原因を持つものを特定する
2つのタスクをあえて「生成」と「判別」で分けているのは、同一インフラで両タイプが動くことを示すためだ。
アーキテクチャ：1つのエンドポイント、複数のアダプター
技術構成のポイントは「1ベースモデル＋複数LoRAアダプター」を単一エンドポイントで提供する設計にある。
LoRA（Low-Rank Adaptation）はベースモデルの重みを変更せず、数十MB程度の差分アダプターを付け替えることでタスク特化の挙動を実現する手法だ。ベースモデルが数十GBであるのに対し、アダプターは数十MB。これを活かして、複数タスクのアダプターをGPUメモリを共有しながら単一エンドポイントで捌く構成を取っている。
実装には以下のコンポーネントが使われている。
- トレーニング: SageMaker Training Jobs + Unsloth + Hugging Face TRL、QLoRA（4-bit NF4）で学習
- データキュレーション・評価: Amazon Bedrock（EUリージョン）でジェネレーターモデルとジャッジモデルを実行
- 実験管理: Amazon SageMaker AI with MLflow で学習データ→ハイパーパラメーター→評価指標のリネージを記録
- サービング: vLLM + DJL-LMIコンテナをBYOC（Bring Your Own Container）形式でデプロイ、アダプターはGPU・CPU・ディスクからミリ秒単位でロード
- 成果物管理: Amazon S3にアーティファクトを保存
データキュレーションとモデル評価はBedrock（EUリージョン）で処理し、GPUリソースをトレーニングに集中させる設計になっている点も実用的だ。
結果：コンプライアンス違反を大幅削減
チケット品質保証
プロンプトのみで動かした31Bのベースラインモデルは、以下の問題を起こした。
- タイトル書き換えの約**19%**でルーティングコードのハルシネーション
- 確認質問の約**13%**で言語不一致（英独混在）
ファインチューニング後の8Bモデルはこれを大幅に改善し、タイトル書き換えで**+8ポイント、確認質問で+13ポイントのコンプライアンス向上を達成。1〜5のルーブリック評価では、タイトル品質が3.74→4.71、説明文品質が2.84→3.87**へ向上し、4倍のサイズを持つプロンプトベース31Bモデル（タイトル4.75、説明文3.77）にほぼ匹敵、説明文ではそれを上回った。
インシデントマッチング
プロンプトベースのモデルは「マッチなし」の判断が苦手で、候補に同一根本原因がない場合でも無理にマッチを見つけようとするバイアスがあった。No-match F1スコアは、31Bプロンプトベースが47%、同サイズプロンプトベースが25%だったのに対し、ファインチューニング済み8Bアダプターは70%を記録。候補数が増えるほどNo-match F1が向上するという特徴的な挙動も確認された。全候補セットサイズにおいてF1ベースで9.6〜14.7ポイントのリードを維持した。
再利用可能なフレームワーク
この取り組みで確立されたフレームワークは4ステップに整理されている。各ステップは独立した作業ではなく、前ステップの成果物を次ステップが引き継ぐパイプラインとして設計されている点が重要だ。
- ユースケースのマッピング: 手元のデータと現モデルの能力ギャップを棚卸しする。ここで対象タスクを「生成」か「判別」かに分類し、評価基準を先に定義することが後続ステップの精度を左右する
- タスクごとの実装: 評価基準とオフザシェルフのベースラインを定義し、コンプライアンスゲートを通過したデータのみでトレーニングデータをキュレーション、小規模アダプターを学習する。データ品質の「門番」を設けることで、学習データの汚染を防ぐ
- コンポーズ: 構造が近いタスクはジョイントアダプターで1エンドポイントから提供する。単一エンドポイント化により、推論コストとオペレーション負荷を同時に下げられる
- 残差ギャップから次の投資を決める: SFT/RFTで埋まらないギャップが、事前学習やアーキテクチャ改善への投資判断の根拠になる。「何をやっても改善しない領域」を可視化することで、無駄な反復を避けられる
再利用資産として、評価ハーネス、データキュレーションテンプレート、学習パイプライン、アダプターレジストリ、マルチアダプターサービング基盤が揃う。「2ユースケース目以降は初回より大幅に安い」という点が、スケールする上でのポイントになる。
BMW Innovation and Emerging Technologies部門のAndre Luckow氏はこの取り組みについて次のようにコメントしている。
「8Bパラメーターの小型タスク特化モデルが、31Bのプロンプトベースモデルと概ね同等の品質を達成し、説明文の評価スコアでは25%以上上回った。SageMaker AI Training Jobsがインフラを管理することで、私たちはAIエンジニアリングに集中でき、データはAWS環境内に安全に保てた。」
巨大な事前学習モデルから始めるのではなく、評価インフラとデータ品質の規律を先に整え、小さなアダプターで価値を積み上げていくアプローチは、製造業に限らずMLOpsの実装設計として参考になる。
詳細はHow BMW builds toward Industry AI on Amazon SageMaker AIを参照していただきたい。
