1 日 500 万打点を AI で全数評価。Audi の溶接検査セッションで語られたクラウド推論とエッジ推論の使い分け #AWSreInvent
こんにちは、製造ビジネステクノロジー部の若槻です。
製造業で AI の話をするとき、検査は最初に候補に挙がる領域です。判定基準がはっきりしていて、人がやると時間がかかり、しかも人によって結果がぶれる。絵に描いたような適用先です。
ただ実際に工場に入れようとすると、モデルの精度より前に別の壁が出てきます。そもそも装置からデータを取り出せるのか、現場と IT で言葉が通じるのか、動いている生産設備に手を入れられるのか。この辺りが片付かないまま PoC で止まる、という話もよく聞きます。
AWS re:Invent 2025 のセッション Revolutionizing Audi's Welding Inspection System through AI (IND367) は、そこを越えてすでに生産ラインで動いているものの話でした。しかもアーキテクチャの変遷と、うまくいかなかったことまで含めて説明されています。現地で聞いてきたので、少々遅くなってしまいましたが、今回はこのセッションをレポートします。
セッション概要
タイトル
Revolutionizing Audi's Welding Inspection System through AI (IND367)
登壇者
- Mathias Mayer, Manufacturing Planning Expert, Audi AG
- Fabrizio Manfredi, Pr. PS Cloud Architect, Amazon Web Services
- Verena Koutsovagelis, Customer Solutions Manager, Amazon Web Services
AWS の Verena Koutsovagelis 氏による導入パート
日時
2025/12/1
セッション概要原文
Learn how Audi implemented an AI-powered quality control system, transforming a traditional welding inspection processes. The system analyzes 1.5 million weld points across 300 vehicles per shift, expanding upon previous manual ultrasound inspections that covered only 5,000 points per vehicle. This AI integration enables production staff to focus on addressing potential anomalies, significantly enhancing quality monitoring efficiency. Following its success, Volkswagen Group is expanding this technology across multiple sites, including Audi Brussels, VW Emden, and Audi Ingolstadt. The implementation process includes site-specific AI model retraining to accommodate varying welding parameters, demonstrating a scalable approach to manufacturing quality control optimization.
登壇は 3 名で、AWS の Verena Koutsovagelis 氏が導入と VW グループ全体の取り組み、Audi AG の Mathias Mayer 氏がユースケースと現場の事情、AWS の Fabrizio Manfredi 氏がアーキテクチャの詳細、という分担でした。Mayer 氏は自動車業界 20 年以上、うち Audi に 15 年、直近 6 年は Audi の OT 技術と AI 開発を担当しているとのことです。Koutsovagelis 氏は後述する DPP プログラムのアライアンスマネージャーも兼ねています。
動画
レポート
前提となる Digital Production Platform（DPP）
Audi の話に入る前に、AWS 側から DPP（Digital Production Platform） の説明がありました。この後に出てくる 2 つのユースケースは、いずれもこの基盤の上に載っています。
ここで前提になるのが、Audi がフォルクスワーゲン・グループのブランドであることです。ランボルギーニ・ドゥカティ・ベントレーと同じ括りに属し、その中の主要ブランドという位置づけになります。DPP はグループ全体の生産基盤として作られているもので、Audi 単独の取り組みではありません。
- そのフォルクスワーゲン・グループと AWS が、5 年前から進めている共同プロジェクト
- 当時 VW が抱えていたのは複雑性の増大・効率の低下・生産コストの増加・生産システムの断片化
- そこから出てきたのが、全工場をクラウドにつなぎ、データを一元管理して、その上にユースケースを載せるという構想
セッション中では「120 以上の工場をクラウドにつなぐ」という言い方をしていました。ここは構想であって現在地ではない点に注意が必要で、AWS の導入事例ページでは欧州・北米・南米の 43 拠点が接続済み、グループ全体の生産拠点は 114 と書かれています（2026 年 8 月 15 日取得）。
DPP の MLOps 側は AWS の公式ブログにも記事があり、こちらではアカウントを 6 つに分けた構成（Data / 実験 / リソース / 開発 / 統合 / 本番）と、5 工場・8 ユースケース・データサイエンティスト 16 名という規模感が書かれています。
面白いのは、この MLOps ブログで例に挙げられているユースケースも溶接ガン（複数工場にまたがる数千本のロボット溶接ガンの予知保全）だということです。
溶接は、同じ装置が 1 つの工場に何百本もあり、その全部が毎日同じ動作を繰り返す工程です。つまり学習データが放っておいても大量に貯まるうえ、モデルを 1 つ作れば、効果が装置の本数と工場の数だけ掛け算で効いてくる。VW グループが AI の適用先としてまず溶接に手を付けているのは、この性質が理由なのだと思います。
Koutsovagelis 氏は、5 年間で共通の原則を作り、互いの文化をすり合わせてきたとも話していました。「ご想像の通り、AWS と VW はまったく同じ文化を持っているわけではない」とのことで、この点は後半の学びのパートで具体的に出てきます。
舞台はネッカーズルム工場 — 1 日 500 万打点
Audi AG の Mathias Mayer 氏。ここから Audi の会社紹介と工場の話に入る
Audi の工場のうち、今回の舞台は ネッカーズルム（Neckarsulm）。Mayer 氏の勤務地です。
日本ではあまり馴染みのない地名だと思うので補足すると、ドイツ南西部にある町です。Audi のドイツ国内の完成車工場は、本社のあるインゴルシュタット（バイエルン州）とこのネッカーズルムの 2 か所で、ネッカーズルムは上位モデルを担当する側です。
| 項目 | 数値 |
|---|---|
| 生産車種 | A5 / A6 / A7 / A8 / e-tron GT |
| 従業員 | 5,500 人以上 |
| 生産台数 | 1 日あたり約 1,000 台 |
| 車体工場のロボット | 約 1,200 台 |
| 溶接ガン | 800 本 |
| 1 台あたりの打点数 | 約 5,500 打点 |
| 1 日あたりの打点数 | 500 万打点以上 |
ここで何度も出てくる打点というのは、スポット溶接で 1 か所を接合したときの、その 1 点のことです。抵抗スポット溶接は、重ねた鋼板を電極で挟んで大電流を流し、接触部分が発熱して溶けたところを圧着するという方式で、溶接線を引くのではなく、点で留めていきます。車体はこの点を数千か所打つことで形になるので、1 台あたり 5,500 打点は「1 台の車体に接合点が 5,500 個ある」という意味です。
セッション中に、車体パネルを拡大した写真が出てきます。丸い跡が規則的に並んでいるのが見えると思いますが、これが打点です。
並んでいる丸い跡が、1 つ 1 つが打点。これがネッカーズルムでは 1 台あたり 5,500 個ある。動画 30:57 のスライドより
つまり 1 日 500 万打点とは、検査の対象になりうる箇所が毎日 500 万個生まれるということです。この数字がセッション全体の前提になります。
なお Audi 全体では 2024 年に 160 万台以上を納車、従業員 8 万 8,000 人以上、という紹介もありました。同じグループのランボルギーニとベントレーはそれぞれ 1 万台以上、ドゥカティは 5 万台以上（二輪）とのことなので、グループ内での Audi の台数規模の大きさが分かります。
ユースケース①：抵抗スポット溶接アナリティクス（WPS）
1 つ目は溶接データそのものを解析するユースケースです。スライド上の略称は WPS（ドイツ語の Widerstandspunktschweißen ＝抵抗スポット溶接）でした。
抜き取り検査には構造的な穴がある
導入前の検査は、超音波探傷器を使った抜き取りでした。1 日あたり約 1 万打点、台数にすると実質 1 台分です。
ここで Mayer 氏が挙げた問題が、言われてみればその通りだと思いました。
良品と不良品が混ざっている場合、私たちは良品のほうを選んでしまう。だから工場の中で欠陥が見つからない。全部が不良なら、それは必ず見つかるのですが。
抜き取り検査は「不良が一定以上あれば引っかかる」仕組みであって、「不良を見つける」仕組みではない、という話です。サンプリングである以上どうしようもない、構造的な穴だと言えます。
500 万打点を AI で全数評価する
そこで、1 日 1 万打点の抜き取りから、1 日 500 万打点の全数評価に切り替えます。
データは溶接コントローラから来ます。1 打点あたりの内訳はこうなっています。
- 抵抗・電圧・圧力の 3 つの曲線を 1 ミリ秒刻みで収集
- 溶接時間が 5 秒を超えるものもあり、1 曲線あたり 5,000 点、1 打点で最大 5 万データポイント
- ドメイン知識として「打点や抵抗曲線はどういう形であるべきか」を専門家から引き出してモデルに与える
モデルは 2 本立てです。
| モデル | 種類 | 学習データ |
|---|---|---|
| 品質推定 | 回帰モデル | 従来の超音波検査の結果。AI が超音波検査の結果を出すイメージ |
| 異常検知 | ニューラルネットワーク | 曲線・データ上の異常を検出する |
既存の検査手法の結果を教師データにして、その検査手法を全数に広げたという構図になっています。移行のさせ方として素直で、真似しやすい形だと感じました。
3 つの経路に振り分けるアーキテクチャ
「The WPS architecture is designed for flexibility」。工場側とクラウド側、およびアカウントの分割。動画 23:53 のスライドより
工場のフロアは非常に大きな建物で、そもそもインターネットに出られない。ここをどうつなぐかをセキュリティ部門と詰めるところから始まったそうです。ダッシュボードを現場に返す経路も同じ問題を抱えていました。
エッジ側は AWS IoT Greengrass で、データを3 つの経路に振り分けています。
| 経路 | 用途 | 実装 |
|---|---|---|
| リアルタイム | 制御・アラームなど、即座の対応が要るもの | Greengrass 内の MQTT ブローカー → AWS IoT Core |
| テレメトリ | 溶接の測定データ本体 | Greengrass の Stream manager → Amazon Kinesis Data Streams → Amazon Data Firehose |
| ファイル | 材料情報など、変化が少ないもの | 専用コンポーネントがバッチでアップロード |
クラウド側はアカウントを役割で分ける構成です。Ingestion アカウントで受けて、Data domain アカウントの S3 に置き、Data Science アカウントの SageMaker からデータサイエンティストが触る。学習は自動化されていて週次で回し、より良いモデルが出たらアプリケーションアカウントへデプロイします。
推論結果は Amazon Timestream に入り、フロントエンドの可視化に使われます。異常を検知すると Lambda が現場に直接アラートを上げ、作業者はプロキシ経由でクラウド上のダッシュボードを見る、という流れです。インフラはすべて IaC で、複数工場への展開を前提にしているとのことでした。
テレメトリを MQTT で送ろうとして失敗した
ここが個人的にいちばん実務的だと思った部分です。
当初はテレメトリも MQTT で送ろうとして、うまくいきませんでした。
すぐに分かったのは、この数十億のデータポイントを MQTT で転送するのは、おそらく良い考えではなかったということです。
MQTT は制御・アラーム・リアルタイム処理が必要なものに限定し、テレメトリはストリーミングに移す。そのうえで、Greengrass 側でマイクロバッチ、Firehose 側でもバッチと二段構えにして、呼び出し回数とパケット数を削っています。この結果、20〜30 秒の遅延でデータを転送・投入できる状態になったとのことでした。
リアルタイム性が要らない場所を見極めて、そこを捨てるという判断です。実際、①は 1 ステーションあたり 60 秒あるので、推論にミリ秒以下の応答は要りません。だから推論はすべてクラウドに置けた、と明言していました。
ユースケース②：溶接スパッタ検出（WSD）
2 つ目は同じスポット溶接でも画像を見るユースケースです。スライド上の略称は WSD（Weld Spatter Detection）でした。
20 秒で 500 打点を目視する現場
金属板が毎回ぴったり合うわけではないので、溶接時にスパッタ（溶けた金属の飛散）が起きます。動画では車体まわりで火花が激しく飛ぶ映像が流れ、Mayer 氏が「これは花火でも大晦日でもない、工場のフロアです」と言っていたのが印象的でした。
スパッタは車体表面の欠陥になるので、人がグラインダーで削って落とします。ここが問題でした。
- サイクルタイムは 60 秒。車体が回転して作業者の前に提示され、検査に使えるのは 20 秒
- その 20 秒で約 500 打点を目視し、必要な箇所を削ってボタンを押す
- A6 のような大きな車では、作業者が車体の反対側まで走って確認する
- 車体の上と下、両方を削る必要があり人間工学的にも良くないうえ、非常に汚れる作業
- 誰が担当するかで結果が揃わない
現場のボトルネックであり、品質のばらつき要因でもあったわけです。
ちなみに、打点の説明で先に出した写真は、このセッションでの「スパッタはどこにあるでしょう」というクイズのスライドでした。答えがこちらです。
オレンジの枠が付いているところがスパッタ。動画 31:10 のスライドより
20 秒のあいだに、これを 500 か所ぶん探すというのが導入前の作業です。
ライトで指示し、次はロボットへ
導入したのは「光で拾って、光で削る」仕組みです。
- 2,000 万画素のカメラ 8 台で車体を撮影（1 枚あたり約 50MB）
- モデルの推論結果を PLC に返し、削るべき場所にライトを当てる
- 作業者は500 打点ではなく、100〜200 打点だけを見ればよくなった
そして次の段階として、ライトで人を誘導するのではなく、ロボットを誘導する方向に進んでいます。セッション時点ではシミュレーション段階で、「クリスマスの頃に部品が揃い、来年の初めには車体表面を自動で研削する」と話していました。ロボットのアーム制御まで含めるため、目標レイテンシは 1 秒未満とのことです。
①と②で推論の置き場所が分かれる
ここからは、ここまで見てきた 2 つのユースケースを並べて比べます。番号は前の 2 節に対応していて、内訳はこうです。
- ① 抵抗スポット溶接アナリティクス（WPS）＝ 溶接コントローラの数値を解析するもの
- ② 溶接スパッタ検出（WSD）＝ カメラの画像を見るもの
セッションの終盤では、この 2 つを 1 枚にまとめた図が出てきました。
「The architecture of WPS & WSD brought together」。工場側に描かれているのは②の機器で、クラウド側は①と②で共有される部分。動画 37:18 のスライドより
この図の読み方を先に補足しておきます。 タイトルの通り①と②を 1 枚にまとめた図なのですが、左の工場側に描かれているのは②の機器だけです（カメラ 8 台と PLC。枠のラベルも WSD になっています）。①の溶接ステーションは 1 枚前の図に譲る形で、この図では②を足したときに何が変わったかが分かるように描かれています。
そのうえで、どこが共有でどこが分かれるのかは次の通りです。
| 範囲 | ①と②の関係 |
|---|---|
| Ingestion アカウント | 共有。工場から受ける入口 |
| データハブ（S3） | 共有。②で撮った画像もここに入るので、他のユースケースから使える |
| Data Science アカウント | 共有。ツールもデプロイの手順も①のときから変えていない |
| アプリケーションアカウント | ユースケースごとに分ける。理由は影響範囲（blast radius）を小さくするため |
| 工場側のエッジ | ②で作り替えた（産業用 PC → Kubernetes クラスタ） |
Manfredi 氏は「以前に構築したインフラの大半は再利用され、一部は拡張されたが、コンポーザブルなアーキテクチャのままだ」と説明していました。②は①の作り直しではなく、①が敷いた土台への追加だということです。
その前提で見ると、①と②の決定的な違いはリアルタイム性の要否で、そこから構成が分岐しています。
| ① WPS（溶接アナリティクス） | ② WSD（スパッタ検出） | |
|---|---|---|
| データ | 溶接コントローラの数値 | 2,000 万画素の画像 8 枚 |
| 応答時間の要求 | ステーションあたり 60 秒。猶予がある | 20 秒、自動研削では1 秒未満 |
| 推論の場所 | クラウド | 現場の産業用 PC（GPU 搭載） |
| 学習の場所 | クラウド | クラウド（ここは同じ） |
| エッジの実体 | 産業用 PC 上の Greengrass | Kubernetes クラスタ |
学習はどちらもクラウド、推論だけが要求時間に応じて分かれるという切り分けです。②ではモデルをパッケージングしてオンプレにデプロイし、その成否まで MQTT で確認する仕組みが追加されています。
エッジゲートウェイを産業用 PC 1 台から Kubernetes クラスタに移した理由も、この文脈で説明されていました。クラウド側でサーバーレスによって「必要なコンポーネントだけスケールさせる」ことをやっていたので、同じ性質を工場の中にも持ち込みたかった、というものです。
なお②でも、撮った画像はすべて S3 へ上げています。推論をローカルでやることと、データをクラウドに集めることは別の話で、モデルを学習し続けるために画像は集めなければならないからです。エッジに寄せたのはあくまで推論だけ、ということになります。
設計原則 — copy once / composable / keep improving
「We have learned a lot」のスライド。左が Mathias Mayer 氏、右が Fabrizio Manfredi 氏
終盤は DPP 全体で共有している原則の話でした。スライドは「We have learned a lot」と題して、Design for scale・Start small and go fast・Data quality is the foundation の 3 つを挙げています。話の中身は次の通りです。
copy once（データは一度だけ取りに行く）
工場の装置はたいてい既に過負荷で、そこからデータを抜くこと自体が難しい。複数のユースケースがそれぞれ装置を叩きに行けば、現場の担当者に止められます。だから一度だけ吸い上げてデータハブに置き、以降はそこから読む。コストの話ではなく現場に嫌われないための設計、という説明が現実的でした。
composable（差し替えられること）
他のコンポーネントに影響を与えずに、追加・削除・リファクタリングができること。 実際、②のアーキテクチャは①で作ったものの大半を再利用し、必要な部分だけ拡張しています。
keep improving（作り直し前提）
ここが製造業のマインドセットと正面からぶつかるという話でした。
製造業の考え方では、一度設計したら 10 年動かし、触らない。すでに動いている生産設備を変更するという発想は、あまり一般的ではありません。
作り直しは設計が間違っていた証拠だと受け取られがちだが、そうではない。小さく始めたなら、どこかで必ず作り直しが要る。実際、①のテレメトリ転送を MQTT からストリーミングに替えたのがまさにそれで、「最終的には置き換わると分かっていたが、検証段階ではあれで十分だった」と振り返っています。
完璧な解より、速さのほうが重要な場面がある。知らない問いには答えられないし、知らない問題は解けないのだから。
一方で、IT 側が製造の制約を分かっていないという逆方向の指摘もありました。
本番に大きな変更を入れられるのは年に 2 回だけ。工場を止めなければならないので、ライン停止による数百万規模の損失リスクを誰も負えません。
現場と IT で言葉が違う、という話も Mayer 氏から出ています。「うちの現場の人間は、Fabrizio やクラウド開発者と同じ言葉を話さない」「たいてい同じことを意味しているのに、違う言語で言っている」。そして現場の KPI は明快で、60 秒に 1 台、1 日 1,000 台。999 台になったら、なぜ 1,000 台でないのかを報告しなければならないとのことでした。
すべての土台はデータ品質
すべての AI ユースケースの土台はデータ品質だと繰り返していました。挙がった具体例が生々しいので、そのまま紹介します。ユースケース①の話・②の話・両方に共通する話の 3 つがありました。
① WPS（溶接アナリティクス）：数値の意味を、現場が説明しないといけない
溶接コントローラから出てくるのは、1 打点につき約 400 個の数値が並んだデータです。これをそのまま渡されても、データサイエンティストにはどれが何を表しているのか分かりません。
- 各値が溶接工程のどの瞬間の何なのか
- そもそも抵抗スポット溶接では何が起きているのか
- どういう波形なら欠陥で、どういう波形ならそうでないのか
これらを現場の専門家が説明していく必要があり、Mayer 氏はこれを「hard work（大変な作業）」と表現していました。データはあっても、意味は付いてこないわけです。
② WSD（スパッタ検出）：専門家どうしで判断が割れる
②はもっと直接的で、現場の専門家が同じ画像を見ても、人によって違うところを指すという問題でした。6 通りの意味でラベル付けされたデータで学習させるとモデルは混乱し、精度は 30% 程度にしかならないとのことです。
正解を作る側が揃っていなければ、モデルの精度以前の話になります。
①②に共通：呼び名も単位も揃っていない
さらに素朴な問題として、次のようなことも挙げられていました。
- 同じ対象物が、工場ごとに違う名前で呼ばれている
- 測定値の単位が違う
- 多くの作業を人間が管理していて、紙の上で手作業でラベルを付けるため、毎回表記が違う
これらの突き合わせも課題だった、とのことです。モデルの前に、言葉を揃えるところからという話で、ここは AI 案件全般に通じると思います。
また「小さく始めて速く進む」については、溶接ガン 1 本から始めたという説明がありました。「1 本つなぐのも 1,000 本つなぐのも、かかる時間はほとんど同じ。一度きちんとやれば、1,000 本は問題にならない」とのことです。
数字の読み方に注意
最後に、公表されている数字が資料によって違う点に触れておきます。
2023 年のプレスリリースがこちらです。ネッカーズルムでのパイロットを終えて、Audi ブリュッセル・VW エムデン・Audi インゴルシュタットへ展開を始めるという内容で、re:Invent 2025 のセッションは、その 2 年半後の現在地という位置づけになります。
おわりに
このセッションで持ち帰りたいと思ったのは、次の 3 点です。
- 既存の検査手法の結果を教師データにして、その検査手法を全数に広げる。 ①は超音波検査を置き換えたのではなく、超音波検査を学習して桁を上げたものです
- リアルタイム性の要否でアーキテクチャを分ける。 同じ工場・同じ溶接工程でも、60 秒の猶予がある①はクラウド推論、20 秒しかない②はエッジ推論。学習だけは両方クラウドで揃えている
- モデルより先にデータ品質と語彙。 6 人の専門家が別々の意味でラベルを付ければ、精度は 30% で止まる
「AI で全数検査」という結果だけを見ると華やかですが、実際にやっているのは、装置からデータを取り出す許可を取り、専門家の頭の中を引き出し、工場ごとに違う名前を揃える作業でした。そこが一番参考になった気がします。
締めは Audi のスローガン「Vorsprung durch Technik（技術による先進）」で、手元のデータを活かして賢いソリューションを作り、競合の先を行ってほしいという言葉でした。
参考
本記事のステージ写真 3 枚は現地で撮影したものです。スライドを拡大した画像 4 枚はセッション動画からの引用です（2026 年 8 月 15 日取得）。
同じ re:Invent / AWS Summit まわりのセッション・ブースレポートとして、以下も書いています。
以上
