Manufacturing

Artificial Intelligence | Internet of Things
0
AIに任せているのは「判断」ではなく、「判断材料づくり」である

これまでの連載では、同じデータ、同じ定義を使うことの大切さを書いてきました。今回の話は、その延長にあります。AIが作る判断材料の質は、元のデータと、「何を異常と呼ぶか」という定義の質で決まります。データがばらばらで、定義が人によって違えば、AIは速く、大量に、間違った判断材料を作ります。どこまで任せるかを考える前に、判断材料の質を揃えておく必要があります。 ※第1回:「経営KGIと現場KPIをつなぐ」、第2回:「同じデータ・同じ定義」を誰がつくるのか、第3回:「同じ判断材料の共有」についてお話ししました。 「AIが判断したので」は会議で通るか 「それはAIが判断したことなので」。この言葉を、経営会議で口にできる人はいないはずです。 AIが賢くなるほど、「どこまで任せるか」は技術の問いではなく、経営の問いになります。今回は、弊社が製造業のお客様と取り組む中で見えてきた、「判断の仕分け」の考え方をお話しします。 結論を先に述べます。公開されている事例を見る限り、AIに任されているのは「判断」ではなく、「判断材料づくり」です。 判断を3つに分ける 「AIに任せるか」と問われると、判断を1つの塊として考えがちです。しかし判断は、少なくとも3つに分けられます(図1)。 判断材料づくり:見る、集める、整える、比べる 決める:選択肢から選び、結果に責任を負う 実行:決めたことを現場で行う 設備保全で言えば、センサーを見て異常を見つけ、マニュアルや過去の記録を集め、対策案を比べるのが材料づくりです。どの対策をいつ実施するかを決め、実際に作業するのが、その先の2つです。 図1.判断は3つに分けられる 判断材料づくりは、量が多く、速さが求められ、人には負担の重い仕事です。一方で「決める」には、結果への責任がついてきます。責任を負えるのは人だけです。ここに、仕分けの出発点があります。 4つの事例に見る共通点 弊社の公開事例を見ると、共通する構図があります。 弊社の公開事例 AIが担う部分(材料づくり) 人が決める部分 Georgia-Pacific社 150超の拠点で約85,000個の振動センサーを監視 異常予兆検出をするAIモデルは30,000個超 運転員・監督者が、修理を計画保全にまとめて日程を決める ロッキード・マーティン社 飛行データからの部品故障の予測 データ整形の約85%を自動化 SASとの協業では、症状データと整備記録から診断し、マニュアルの該当手順を参照元付きで提示する仕組みを検証 任務の中止は乗員、運航機と予備部品の選択は顧客、整備作業は整備士 Wienerberger社 分断データの統合 エネルギー消費の監視 洞察と推奨の生成 デジタルツインでの事前検証 現場知識を持つ技術者がモデルを改善し、変更は検証後に実施 SAS×NSW様のOEE改善デモ 経営KGI、現場KPIダッシュボード 異常予兆検出のしきい値の自動設定 要因候補のパラメータ表示 生成AIによる対策案の提示 対応方法の決定   何をAIに任せてよいか:2つの軸 では、どの判断ならAIに任せてよいのでしょうか。2つの軸で考えます。 1つ目は、判断の基準がどこまで明文化されているかです。「この値を一定回数続けて超えたら異常」と言えるなら、機械に任せられます。弊社の事例でも、異常を知らせるしきい値は、担当者の経験則ではなく、統計の考え方(管理図)で自動的に設定し、基準を標準化しています。基準は人が決め、適用は機械が行う。この分担です。 2つ目は、間違えたときの影響と、元に戻せるかです。データ整形や異常アラートは、間違えても戻せます。任務の中止や部品の交換は、戻せません。 図2.基準の明文化度 × 誤りの影響 この2軸で、4つの領域に分かれます。 基準が明確で影響が小さければ、AIに任せる。

Analytics | Internet of Things
0
同じデータを見ても、なぜ判断は割れるのか: 共有すべきは「結論」ではなく「判断材料」

第1回では経営KGIと現場KPIをどうつなぐかを、第2回では「同じデータ、同じ定義」を誰がつくるのかを書きました。では、同じデータを同じ定義で見られるようになれば、企業の意思決定はうまくいくのでしょうか。私は、その先にもう一つ問題があると考えています。同じデータを見ても、人によって判断が違うことです。今回は、製造現場の「判断」を考えます。 設備に異常の兆候が出た。さて、止めるべきか? ある工場の生産設備で、センサーの振動や温度に通常と異なる傾向が現れたとします。今すぐ故障するとは限りませんが、何かが起こり始めている可能性があります。オペレーター、保全担当、生産管理、工場長は、この設備を止めるべきかどうかを、図1のように考えるかもしれません。 図1. 設備停止をめぐる4者の判断 誰か一人が間違っているわけではありません。守るべきKPIと負っている責任が違うため、同じデータを同じ定義で見ていても判断は割れます。それぞれが自分の責任を果たすことを考えた結果だからです。 「予測できること」と「判断できること」は違う AIやアナリティクスで、「この設備は近い将来、故障する可能性が高い」と高い確度で予測できるようになったとしましょう。これは大きな進歩です。しかし、そこで問題が解決するわけではありません。今止めるのか、今日の生産を終えてから止めるのか。部品はすぐ手配できるのか。誰が決めるのか。予測を受け取ったところから、次の問いが始まります。「何が起きそうか」を予測することと、「では何をするか」を判断することは、別の問題です。予測精度を高めても、後者が自然に解決するわけではありません。 ベテランが持っているのは、「答え」だけではない 経験豊富な保全担当者は、センサーの値が通常と違うからといって、機械的に「停止」と判断しているわけではありません。ベテランが本当に持っているのは答えそのものより、答えにたどり着くまでのプロセスです。 どの情報を見るのか 何と何を比較するのか 何をリスクと捉えるのか どの条件になったら他の人に相談するのか 経験やノウハウと呼ばれているものの中には、こうした「判断の仕方」が含まれているはずです。自社のベテランに「この異常を見たとき、最初に何を確認するか」を聞いてみてはいかがでしょうか。 目指すのは、同じ結論ではなく、同じ判断材料 全員に同じ結論を求めると、立場の違いが無視され、責任範囲が曖昧になり、例外に対応しにくくなります。目指すのは、同じ判断材料を共有した上で、それぞれの責任に基づいて判断できる状態です。設備異常の例でいえば、何が起きているか、想定される原因、類似事例、継続運転のリスク、生産計画への影響、対応方法の選択肢です。共有するのは結論ではなく、判断の根拠です。 図2.共有するのは結論ではなく判断材料 データ基盤の次に、「判断基盤」を考える データを集め、整え、定義を揃え、分析する。ここまでは多くの企業で議論されています。しかし、分析できるようになっても、意思決定の速さや質が自動的に変わるとは限りません。そこで、データ基盤の次に「判断基盤」を考えることを提案します。新しいITシステムの名前ではなく、意思決定プロセスの整理と言い換えても構いません。必要なデータ、判断材料、判断基準、責任者、そしてアクションまでをつなぐ仕組みを、ここでは「判断基盤」と呼ぶことにします。 自社の現在地は、図3の5つの問いで確認できます。 図3.判断基盤を確認する5つの問い 5つすべてに即答できるかどうかが、判断基盤がどこまで整っているかの目安になります。答えに詰まる問いがあれば、そこが次に手をつける箇所です。 おわりに データを集める。定義を統一する。分析できるようにする。ここまで整えても、判断が自動的に良くなるわけではありません。最後に残るのは、「この情報から、私たちはどう判断するのか」という問題です。その答えは、全員が同じ結論を出すことではありません。同じデータを同じ定義で見て、判断に必要な材料を共有した上で、それぞれの責任に基づいて意思決定できる状態をつくることです。 次回は、この判断のどこまでをAIに任せ、どこからを人が持つのかを考えます。 皆さんの会社では、同じデータを見たとき、誰もが同じ「判断材料」を手にしているでしょうか。

Analytics | Data Management | Internet of Things
0
同じデータ、同じ定義の次に来る問題 :「誰が」統一データソースをつくるのか

前回の記事では、GT-Rの開発者が「同じ条件・同じ指標で測ること」を譲らなかった話から、データ分析には同じデータ、同じ指標定義が欠かせないという結論に至りました。では、それを製造業の現場で実現するにはどうすればよいのでしょうか。今回は、そのために必要なデータの置き場と層構造、そして意外と見落とされがちな「誰がつくるのか」を取り上げます。 製造業でよく起きる「同じ用語、違う数字」 たとえば「設備稼働率」です。 生産部門は、計画稼働時間に対する実稼働時間で見ている 保全部門は、故障停止だけを引いて計算している 経営層向けの月次資料では、段取り替えや待機時間の扱いが資料ごと・部門ごとに異なる 誰も間違っていません。ただ、定義が揃っていないだけです。この状態では、OEE(設備総合効率)を改善しようとしても、予知保全モデルをつくろうとしても、議論が「その数字は何を指しているのか」から始まってしまいます。これを解消する土台が、統一されたデータソースです。 データの層構造を整理する 近年、製造業では、構造化データに加えて、IoTや機械から生成されるセンサーデータ、テキストなど、多種多様なデータが生まれています。これらを一元的に管理・活用できる新しい技術と概念が、データレイクハウスとメダリオンアーキテクチャです(出典1・2)。 データレイクハウス:従来のデータウェアハウスとデータレイクそれぞれの制限を克服し、両者の長所を併せ持つデータアーキテクチャです。低コストなストレージ上のデータに対して、ACIDトランザクション(データの整合性を保つ仕組み)やガバナンス、高速なクエリ性能を実現する統合データプラットフォームです。 メダリオンアーキテクチャ:データレイクハウスに蓄積されるデータを、品質や加工度合いに応じて段階的に整理・洗練させていくマルチレイヤーのパイプライン構造です。 このメダリオンアーキテクチャは、次の3層で整理されます。 ブロンズからシルバー、ゴールドへと進むほど、「生データ」から「使えるデータ」へ磨かれていきます。 この3層は、従来のデータ基盤の用語では、おおむね、 データレイク → ブロンズ層 データウェアハウス → シルバー層 データマート → ゴールド層 に対応します。厳密には一対一で対応するわけではありませんが、本記事では説明のしやすさのためのイメージとして捉えていただき、以降はブロンズ層・シルバー層・ゴールド層の呼び方で話を進めます。 いちばん難しいのは、実はシルバー層 3層のうち、技術的に最も手間がかかりそうに見えるのはデータ量の多いブロンズ層ですが、実際に難しいのはシルバー層です。理由は2つあります。 1.やりたい分析を意識して設計する必要がある シルバー層は「きれいに整える」だけでは終わりません。OEEを出したいのか、故障予兆を見たいのか、不良の要因を追いたいのかによって、必要な粒度(秒単位か、ロット単位か)や、どのデータを紐づけるかが変わります。分析目的を知らないまま整えると、「整ってはいるが使えないデータ」ができあがります。 2.現場の専門知識が不可欠 この停止コードは「故障」なのか「段取り替え」なのか 設備の時刻と、MESの時刻がずれているのはなぜか このセンサー値が突然ゼロになるのは、異常か、単なる停止中か ロットIDと設備IDは、どのタイミングで紐づくのか これらはデータを眺めるだけでは分かりません。現場を知る人にしか答えられない問いです。 ITチームだけでは、シルバー層はつくれない データ基盤というとIT部門の仕事と考えがちですが、シルバー層の構築にはIT部門だけでは足りません。 必要なのは次のような多彩なメンバーです。 現場のオペレーター・ライン長:データが実際の動きをどう反映しているかを知っている 生産技術・設備保全:設備の構造や停止の意味、センサーの癖を理解している 品質保証:不良の定義や検査データの意味づけを決められる データサイエンティスト/アナリスト:分析で何が必要かを示せる データエンジニア/IT:その要件を実際に実装し、運用に乗せる 業務オーナー(工場長・部門責任者):部門間で割れた定義に決着をつける 最後の「定義の決着をつける人」が特に重要です。指標定義の統一は技術の問題ではなく、部門間の合意形成の問題だからです。この点は、計画段階で十分に考慮されていないケースが少なくありません。 ヨーロッパの建築資材の製造企業様での事例 SASはヨーロッパの建築資材の製造大手、Wienerberger社にて同様の経験をしています(出典3・4)。生産ラインからのデータ収集を行いブロンズ層を構築するまではITベンダーが実施できましたが、データ分析目的であった「製造品質を維持したまま、消費エネルギーを最小化する」という経営KGIを達成しようとしたところ、必要なデータの選定やクレンジングがうまく行えずデータ分析が実施できないという問題が発生しました。そこで弊社が参画しました。 データ分析の知見が、シルバー層/ゴールド層の設計の手がかりになる ここで、分析の出口から逆算するというアプローチが生きてきます。 SASはアナリティクスのリーディングカンパニーとして50年にわたる経験を有しています。そのため、「このデータ分析を実現するには、どんなデータ項目が、どの粒度・どの関係性で必要か」という、分析が要求するデータ構造についての知見を持っています。例えば、生産設備の状態監視や品質改善といったデータ分析用途ごとに、その構造を整理した専用のデータマートを、ノウハウとして保有しています。これはメダリオンアーキテクチャでいえば、ゴールド層に相当するものです。 この知見があれば、

1 2 3 … 117