はじめに
本記事では、Data + AI Summit 2026（DAIS2026）で行われたBridgestone Americasのセッション「How Databricks Apps Facilitated Model Retraining」の内容を紹介します。
製造現場で収集した画像を使うコンピュータビジョンモデルに対して、現場の専門家であるSME（Subject Matter Expert）からフィードバックを集め、モデルの再学習につなげる仕組みをDatabricks Appsで構築した事例です。
わずか3週間で画像ラベリングアプリの初版を立ち上げ、1,500本超のタイヤについての20,000枚超の画像をラベル付けし、モデル性能を20％超改善しました。
その後は、Lakebaseと生成AIを活用してアーキテクチャを発展させ、平均ラベリング時間も50％超短縮しています。
セッション概要
| 項目 | 内容 |
|---|---|
| セッション名 | How Databricks Apps Facilitated Model Retraining |
| サブタイトル | Leveraging SME Feedback to Train Better Models |
| 登壇者 | Tim Hanchin氏（Director, Digital Service Platforms, Data & Integrations）、Greg Islas氏（Lead Data Scientist） |
| 所属 | Bridgestone／Bridgestone Americas, Mobility Technology Stack |
| 日時・会場 | 2026年6月18日 11:30～12:10（PDT）、South Level 3, Room 308 |
| 種別・レベル | Breakout、Intermediate |
| トラック | Application Development |
| 主な技術 | Databricks Apps、Unity Catalog、Lakebase、Delta Lake、MLflow |
BridgestoneのBandag Retread Solutionsは、65年以上にわたり、タイヤのリトレッド（更生）技術を手掛けています。
本セッションで紹介されたのは、リトレッド工程の意思決定を支援するコンピュータビジョンモデルと、その改善に必要な専門家のフィードバックを効率的に集めるアプリです。
モデル改善の鍵は、SMEの知識を学習データに戻すこと
セッションの冒頭では、データサイエンスチームとSMEの協働を、次の5段階で整理していました。
- フィードバックを収集する
- SMEがモデルの予測やラベルを検証する
- 専門家の知見を教師データとして蓄積する
- 検証済みのデータで継続的にモデルを再学習する
- 適合率、再現率、F1スコアなどで効果を測定する
モデルを一度作って終わりにするのではなく、現場で得た知見を学習データへ戻し続けるループが重要です。
一方、このループを回すには、専門家が無理なく利用できるフィードバックの入口が必要になります。
SMEとは、製品や製造工程など、特定の業務領域に関する専門知識を持つ担当者を指します。本事例では、タイヤやリトレッド工程に精通し、モデルの予測結果が正しいかを判断できる現場の専門家が該当します。
これまでの経緯：データとアプリを近づける
Bridgestoneでは以前から、タイヤ空気圧の機械学習モデル向けに、「Tagger」と呼ばれるラベリングツールを運用していました。
当初はAzure Web AppとAzure SQL Serverを組み合わせ、DatabricksのDelta Tableにある推論結果をSQL Serverへ同期し、アプリから利用していました。
この構成は動作していたものの、次のような負担がありました。
- DatabricksからSQL ServerへデータをコピーするETLが必要
- 同期処理の分だけデータの鮮度が落ちる
- 二つのシステムを監視・保守・保護する必要がある
そこで2023年に、データバックエンドをDelta TableとDatabricks SQL Warehouseへ移行し、その後Unity Catalogにも対応しました。
これにより、モデル出力とユーザーが付与したラベルを同じプラットフォームで扱い、Unity Catalogで管理するデータについて、アクセス制御やデータリネージを集約できるようになりました。
この「データのある場所でアプリも動かす」という考え方が、今回のコンピュータビジョン事例にもつながっています。
5年前に作られた画像分類モデルをどう再始動するか
今回の対象は、2020年にAzure Custom Visionで構築された画像分類モデルです。
製造拠点で収集したタイヤ画像をクラウドストレージへ転送し、ラベル付けしたデータでモデルを学習する構成でした。
しかし、大企業ではPoCがいったん停止し、数年後に再開されることも珍しくありません。
このモデルも約5年を経て再び活用することになりましたが、開発当時の担当者はすでにチームを離れていました。新しいチームには、モデルのデプロイ、監視、再学習を改めて成立させる必要がありました。
ここで、従来の仕組みには三つの課題が見つかりました。
1. Azure Custom VisionとDatabricks間の同期
モデルの学習・管理はDatabricksとMLflowへ寄せたい一方、画像とラベルはAzure Custom Vision側にありました。
そのため、二つのサービス間で画像、ラベル、メタデータを同期する処理が新たに必要でした。
2. ラベリング画面を業務に合わせて変更できない
このユースケースでは、1枚の画像だけでなく、同じタイヤを複数方向から撮影した画像をまとめて確認しなければ判断できません。
複数画像の対応関係を保ち、同じ画面に並べる必要がありましたが、既存の汎用画面では十分に対応できませんでした。
3. すべての工場が同じ推論方式に対応できるわけではない
工場ごとにシステム環境や利用条件が異なるため、単一の外部サービスを前提とした構成では、複数拠点への展開が難しいという課題がありました。
つまり、必要だったのは単なる画像ラベリングツールではありません。
Bridgestone固有の判断プロセスに合わせられるUIと、Databricksの学習・管理基盤へ自然につながる仕組みが求められていました。
なぜDatabricks Appsだったのか
チームは、既存のAzure Custom Visionを使い続ける案、オープンソースまたは外部のラベリング製品を導入する案、Databricks Appsで構築する案を比較しました。
| 選択肢 | メリット | 課題 |
|---|---|---|
| Azure Custom Vision | すでに利用しており、短期間・低コストで展開できる | UIのカスタマイズとDatabricks連携が難しい |
| OSS／外部製品 | 比較的低コストで、一定のカスタマイズが可能 | 導入審査、セキュリティ確認、ID連携、データ連携に時間がかかる |
| Databricks Apps | データ基盤と統合済みで、UIを自由に構築できる | 自分たちでアプリを実装する必要があり、開発期間が当初は未知数 |
Databricks Appsを選ぶ決め手は、次の三点でした。
- 必要なデータがすでにDatabricksにあり、追加の同期基盤を作らずに済む
- 既存のDatabricks環境が社内IT部門の承認を得ており、既存のセキュリティ基準とガバナンスを利用できる
- 1本のタイヤにひもづく複数画像をまとめて表示するなど、SME向けの画面を自由に設計できる
外部のサードパーティー製ソフトウェアを新たに導入しないことで、数千ドル規模の費用も回避できたと説明されていました。
Part 1：Streamlitで3週間の初期リリース
登壇したGreg Islas氏はデータサイエンティストであり、フロントエンドやインフラストラクチャの専門家ではありません。
そこで、Pythonで素早くUIを作れるStreamlitを採用し、Databricks Appsへデプロイしました。
完成までにかかった期間は、わずか3週間です。
初版では、次の機能を実装しました。
- Streamlitによる一通りのラベリング機能
- Databricks Appsへのデプロイ
- Unity Catalogとの統合
- 1本のタイヤにひもづく複数画像の一覧表示
- 画像単位での異常ラベル付与
製造拠点から送られた画像はAzure Storageへ格納され、Unity CatalogのExternal Volumeを介してアプリから参照します。
ラベルも同じDatabricks環境へ書き戻せるため、別の同期処理は不要です。
また、アプリのためにKubernetesクラスターを用意・運用したり、独自の認証基盤を構築したりする必要もありませんでした。
初期リリースの成果
初版のアプリでは、次の成果を得ています。
- 1,500本超のタイヤについて、20,000枚超の画像を確認・ラベル付け
- 新たなラベルデータによってモデル性能が20％超向上
- SMEによる数カ月分の手作業を削減
なお、セッションでは「モデル性能が20％超向上」と示されていましたが、対象となる評価指標の詳細までは説明されていませんでした。
そのため、本記事でも、適合率や再現率など、特定の指標が20％改善したとは断定していません。
Part 2：初版で見えた課題をLakebaseと生成AIで改善
3週間で業務に使えるものを作れた一方、利用を拡大すると、初版の限界も見えてきました。
課題1：Webアプリに必要な書き込みレイテンシ
初版ではラベルをUnity Catalog配下のテーブルへ直接保存しており、1回の保存に約3～4秒かかっていました。
1拠点で少量のデータを扱う間は許容できても、対象工場や画像数を増やすには改善が必要です。
そこで、Webアプリのトランザクション処理を担うデータベースとしてLakebaseを採用しました。
PostgreSQL互換のデータベースによって低レイテンシな読み書きを行い、Lakebaseへ保存したデータをレイクハウス側へ連携することで、既存のモデル監視やダッシュボードへつなげます。
また、アプリを使っていない時間はLakebaseのコンピュートを停止し、未使用時のコンピュート分の課金を抑えられる点も、利用者の多くない社内アプリと相性が良かったと語られていました。
課題2：StreamlitでのUI拡張
Streamlitは初版を短期間で作るうえで有効でしたが、ホバー操作やキーボードナビゲーションなど、細かな操作性を追加しようとすると実装が複雑になりました。
そこで、アプリをFastAPI（PythonベースのAPI開発フレームワーク）のバックエンドと、JavaScriptのフロントエンドに分離しました。
フロントエンド開発の経験が豊富ではないチームは、Claudeを開発支援に使い、新しいアーキテクチャとUIの実装を進めました。
最終アーキテクチャ
改善後の全体像は次のとおりです。
- 製造拠点から画像をAzure Storageへ送信する
- Azure Storageにデータ格納する
- Unity Catalogで画像データを管理する
- Lakebaseでアプリの低レイテンシな読み書きを処理する
- Databricks Apps上でFastAPIのバックエンドとJavaScriptのフロントエンドを動かす
- SMEが複数のタイヤ画像を確認し、ラベルを付与する
- 収集したラベルをモデル監視と次回の再学習へつなげる
最初からこの構成を作り込んだのではありません。
まずStreamlitで業務価値を確認し、実利用で見つかったボトルネックに合わせて構成を発展させた点が印象的でした。
改善版の成果
改善後のアプリでは、平均ラベリング時間を50％超短縮し、15,000枚超の画像を従来の半分の時間でラベル付けできました。
一方、改善版で収集したデータを使う次のモデル再学習は、セッション時点ではまだ完了していません。
セッションでは、追加のモデル性能向上は「期待される成果」として示されていました。
初版で実測された20％超の改善と、改善版に対する今後の期待は、分けて捉える必要があります。
Databricks Appsが向いているユースケース
セッションの最後には、実際の開発を通して見えたDatabricks Appsの適用条件が共有されました。
特に適しているのは、次のようなケースです。
- Databricksへアクセスできる社内ユーザー向けのアプリ
- 利用するデータがすでにDatabricksにある
- 数百万人規模のユーザーへの水平スケールを必要としない
- まず短期間でプロトタイプを作り、価値があればその先まで育てたい
- 主な開発者がインフラストラクチャの専門家ではない
認可については、アプリのサービスプリンシパルに必要な権限を付与する方式に加え、アプリ利用者本人の権限でデータへアクセスするOn-Behalf-Of方式も利用できると、質疑応答で説明されていました。
どちらを選ぶかは、アプリの利用者とデータの機密性に合わせて設計する必要があります。
一方、登壇者は「何にでもDatabricks Appsを使うべき」とは述べていません。
数百万人規模のユーザーを想定するサービスや、高負荷のアプリでは、別のホスティング方式や追加のエンジニアリング支援も検討すべきです。
この現実的な線引きも参考になりました。
この事例から得た学び
1. モデル再学習のボトルネックは、アルゴリズムとは限らない
今回の課題は、新しいモデルを作ることよりも、SMEの判断を高品質な教師データとして回収することにありました。
モデル開発の手前にある業務UIを整えることが、結果としてモデル性能の改善につながっています。
2. データとアプリを同じガバナンス境界に置く効果は大きい
外部ツールを増やすと、データ同期、認証、セキュリティ審査、監視、コスト管理の対象も増えます。
既存のDatabricks環境にアプリを載せたことで、チームはそれらの作業を抑え、ラベリング体験の設計に集中できました。
3. 「3週間のプロトタイプ」を使い捨てにしない
Streamlit版は完璧ではありませんでしたが、実際のデータと利用者で価値を検証するには十分でした。
その後、Lakebase、FastAPI、JavaScriptへ段階的に移行し、同じDatabricks Apps上で継続利用しています。
プロトタイプから本格運用へ、学びながら構成を育てた好例だと感じました。
4. 生成AIは、少人数チームの専門領域を補完できる
データサイエンティストが、使いやすい初版をPythonで作り、より高度なUIが必要になった段階で生成AIを活用する。
この進め方により、チームはフロントエンド開発の経験不足を補いながら、アプリを次の段階へ進めました。
ただし、生成AIがフロントエンドの専門性を完全に代替したわけではありません。生成されたコードの確認や、アーキテクチャの判断は引き続き必要です。
まとめ
Bridgestoneの事例は、Databricks Appsの価値が「Databricks上でWebアプリを公開できること」だけではないと示しています。
本質的な価値は、データ、ガバナンス、モデル、業務UIを近い場所に置き、現場の知識をモデル改善へ戻すループを短期間で作れることです。
3週間で構築した初版は、1,500本超のタイヤについての20,000枚超の画像をラベル付けし、モデル性能を20％超改善しました。
さらに、実運用で判明した課題をLakebaseと新しいフロントエンド構成で解消し、平均ラベリング時間を50％超短縮しています。
特に印象に残ったのは、インフラストラクチャやフロントエンドを専門としないデータサイエンティストが、まず自分たちで業務価値を形にできた点です。
モデルを現場で育て続けるためには、MLOps基盤だけでなく、SMEが参加しやすい「最後の1マイル」のアプリケーションが欠かせません。
そのことがよく分かるセッションでした。
※本記事は、Data + AI Summit 2026のセッション内容と、当日の文字起こしをもとに構成しています。数値や製品構成は、セッション発表時点の内容です。
関連コラム
・サンフランシスコ開催「DAIS2026」現地レポート【概要編】
https://www.newson.co.jp/column/2026080301/
・DAIS2026の複数セッションでのAI活用事例の共通点
～複数セッション事例から読み解く「本番で使われるAI」の条件～
https://www.newson.co.jp/column/2026080302/
・初海外出張でDatabricks「DAIS2026」に参加してきました【体験記】
～事前準備から現地参加、Waymo体験までのリアルな記録～
https://www.newson.co.jp/column/2026080304/
関連ニュースレター＆コラム
初海外出張でDatabricks「DAIS2026」に参加してきました【体験記】
DAIS2026の会場で感じた熱気やイベントの雰囲気、多くの参加者との交流、Waymo体験まで。現地だからこそ味わえた発見や気づきを、リアルな視点でお届けします。
DAIS2026の複数セッションでのAI活用事例の共通点
DAIS2026で聴講した複数のセッションから見えてきたのは、「AIを業務に定着させる」ための共通した考え方でした。本記事では、各社事例を通じてそのポイントをご紹介します。
サンフランシスコ開催「DAIS2026」現地レポート【概要編】
サンフランシスコで開催されたDAIS2026には、世界150カ国以上から3万人超が参加。本記事では、イベント全体の概要と、Databricksが示したAI時代の最新動向をご紹介します。
関連サービス
Databricksプロフェッショナルサービス
Databricks の統合プラットフォームと当社の豊富なビッグデータ経験を活かし、BIとAIを一体で迅速に価値へつなぐサービスをご提供します。
関連事例
データスチュワードが導くDatabricksへの処理統合と最適化。効率化と統制を両立する、将来につながるデータ基盤へ。
- 導入事例のタグ
- Databricks、ビッグデータ、先進ソリューション
- 導入事例のピックアップ用タグ
- TOPのピックアップエリアに表示、事例一覧ページのスライダーに表示