工場・製造現場のAI活用事例

拠点のデータがばらばらで、技術者は不具合が起きてから動くしかなかった。

修理の38%が事後対応になり停止時間が費用を押し上げていた。

1. Claudeを組み込んだ現場向けアシスタントを使う
2. 設備図面とセンサーの値を読み込ませる
3. 機器の画像と稼働データから壊れる前の兆候を拾う
4. MCPで古い設備ともつなぎデータを一つにまとめた
5. 最終の判断と作業は現場の技術者が行う

停止時間が減って生産量が上がった。

通常運用に乗れば、この1拠点だけで年840万ポンドの削減になると見込んでいる。

4年前に自分で作った日報の仕組みは数量や時間の欄は問題なかったが、自由記述の表記ゆれや誤字で過去の記録が検索に引っかからなかった。

トラブルの処置や次の直への申し送りといった大事な情報が、残っているのに使えない状態になっていた。

1. 日報のテキストをClaudeのAPIに渡し決めた形に構造化させる
2. 表記ゆれの名寄せと日付や単位の統一をさせる
3. 記入漏れや矛盾は品質の指摘として出させる
4. 未記入は計算で埋めずnullにするよう指示文で禁じる
5. 整えたデータを複数日まとめて渡し繰り返しやずれを探させる

OCRの崩れや全角半角の混在を含む架空の日報14枚で試したところ、外径が一方向に増えているのに公差の記載がない点や、トラブル欄に記載があるのに時間が0.0hになっている矛盾を出せた。

申し送りの懸念が扱われず同じ損失が再び起きていることも見つかり、費用は1枚の正規化が約10円、14枚の横断分析が約30円だった。

板金塗装の修理受付は客からの申し出や店員の目視での声がけに頼っていた。

そのため傷やへこみがあっても気づかれず修理の機会を逃していた。

1. ガソリンスタンドの来店導線にゲート型スキャナーを置く
2. 洗車割引をきっかけに診断を客へ案内する
3. 通過した車を動画撮影しAIが傷やへこみを判定する
4. 診断レポートと概算見積を店員が客に説明する
5. 関心を持った客をLINEでつなぎ正式見積と修理へ渡す

来店した客はゲートを通過するだけで車の傷の診断結果と概算見積をその場で受け取れるようになった。

撮影作業に人手をかけずに済み、埋もれていた修理の需要をデータとして拾える形になった。

数千店舗ぶんのメニューや在庫のデータはあったのに、固定のレポートやダッシュボード越しでしか見られなかった。

接客している最中に必要な答えが出るまで何時間もかかっていた。

1. MCPサーバーを立ててAIモデルをTeradataへ直接つなぐ
2. 中継ソフトや書き出しを挟まずテーブルの構造ごとAIに渡す
3. 現場のスタッフが在庫や売れ筋を普通の言葉で尋ねる
4. SQLもダッシュボードも使わず数秒で答えが返る
5. 参照できる範囲はデータベース側の権限で管理した

数時間かかっていた分析が数分で終わるようになった。

接客しながら在庫や売れ筋を確かめられるようになり、おすすめの精度も上がった。

編集用の仮ナレ作りや深夜ニュースの読み上げにアナウンサーを確保する負担が重く、外国語ナレーションは人もお金も足りなかった。

1. GeminiとText-to-Speechを土台に自社の音声生成基盤を作った
2. 音声合成マークアップ言語で尺やアクセントを制御した
3. 原稿を入れて声色を選びワンクリックで音声を作る
4. アクセントを1文字ずつ直し固有名詞を手で整える
5. 報道は従来型モデル、ドラマはGemini系と使い分けた

正式公開から1年で利用者は800人を超え、作られた音声は合計500時間分を上回り、音声まわりの業務だけで20人月ほど減った。

費用の都合で読み手を立てられずにいた動画にも音声を付けられるようになり、外注した場合との差は概算で1000万円以上になった。

設計図面から構造物の名称や寸法を目で読み取り手計算でまとめる数量拾いは5〜6人のベテランに集中し、1案件あたり2〜15時間かかっていた。

図面を読む暗黙知が文書化しづらく、若手が入り込めないうえ見積書の提出が遅れて受注を逃すこともあった。

1. AIコンサル会社と組み現場の進め方を聞き取り専用アプリを共同で作った
2. 設計図面のPDFを読み込ませ構造物と寸法と数量を拾い出させた
3. 車止め8個などの一覧表をExcelで書き出した
4. 抽出箇所を図面上に色付けして表示し確認を早めた
5. AIの出力は下書きとし最後は技術者が目で確かめた

数量拾いは最大12時間から約10分になり、見積もり全体の工数も最大15時間から約4時間に減った。

専門知識のない社員でも一覧表を作れるようになり、ベテラン任せだった業務を若手や未経験者にも広げられた。

箱に入った薬のカートリッジの数を人が手で数えており時間も人手もかかっていた。

機械学習の処理も学習から機器への配布までばらばらで数を増やしにくかった。

1. ロボットアームが箱を置きカメラで上から撮る
2. エッジ機器のモデルが画像を読んで個数を数える
3. 学習画像はS3に置きSageMaker Pipelinesで学習する
4. できたモデルをIoT Greengrassでエッジ機器へ配る
5. 結果はQuickSightに出し人が見て直す

手で数えていた作業を自動にできてAWSとの6週間の試作で動く仕組みまで作れた。

同じ仕組みを最後の2週間で寒天培地の菌の検出にも作り替えられた。

50年以上使ってきた水道管は劣化が進み、破裂や漏水の元になる速い圧力の揺れを見つけられずにいた。

原因がつかめないまま、手を打つのが後手に回っていた。

1. 高速の圧力センサーを管路に付けデータを集める
2. 集めたデータをAmazon S3に貯める
3. Amazon Athenaでその場で処理する
4. Amazon SageMakerで異常を見分けるモデルを学習させた
5. 結果をダッシュボードに出しリスクの高い区間から手を入れる

圧力の異常を97.5%以上の精度で見つけられるようになった。

ストレスの蓄積と漏水や破損の間に99%の相関が確かめられ、負荷をかけていたポンプや大口の利用者も特定できた。

機器の扱い方の知識が紙の資料やデジタルのファイル、ベテランの頭の中に散らばっていた。

熟練者が辞めるたびに知識が失われ機械の停止が長引く恐れがあった。

1. 社内文書とメンテナンス記録とIoTセンサーのデータを一か所に集める
2. Amazon Bedrock経由のClaudeが質問に答える
3. 詳しい社員や退職する社員との会話を録音し要約して手順書に作り直す
4. ウェブアプリで聞くと機械の入力や調整の手順を一つずつ受け取れる
5. 拠点ごとの機器や手順に合わせて答えの中身を変える

オペレーターがほぼリアルタイムで機械を調整できるようになり品質の落ち込みと停止時間が減った。

施設全体で年間数百万ドルのコスト削減が見込めるとしている。

10の生産工場と約100の流通センターを回しているのに、在庫や配送のデータは1日1回しか更新されなかった。

24時間前の情報で判断するしかなく現場の状況が見えなかった。

1. 社内にためていたデータをAmazon S3へ移した。
2. 在庫と流通と配送を追う社内アプリを作った。
3. AWS Lambdaで集計し表と図で画面に出す。
4. 更新は15分ごとで注文ごとの状態まで追える。
5. 配達のとき客が家にいるかを予測するモデルも動かす。

注文の充足率が1%上がり欠品の頻度は0.2%減った。

未受領の注文も0.3%減り、在庫管理ユニットの数は2倍になった。

米の銘柄判定は資格を持つ検査員の目視に限られ、秋の収穫期には大量の検体が集中して負担が重かった。

現場の高齢化と人手不足も重なっていた。

1. 外部パートナーと組みAWSとAmazon SageMakerで開発の場を用意した
2. 検査皿に米粒を並べスマホで撮ると数十秒で銘柄名が出る仕組みにした
3. 1回1,000〜1,500枚の写真で学習し10サイクル繰り返した
4. 検査員の見方をエンジニアが聞き取り粒の形や輪郭の特徴に落とし込んだ

青森と秋田の産地あわせて8つの銘柄を自動で見分けられるようになり、実証実験では有資格の検査員に並ぶかそれ以上の精度が出た。

今は目視検査の前段の下調べとして社内で使い、担当者の負担を減らしている。

菓子の乾燥や炙りに使うチェーンコンベアが年に数回壊れ、生産ラインが止まっていた。

修理に3日かかる場合もあり、賞味期限のある商品を捨てることもあった。

1. 市販のマイクとマイコンボードでコンベアの音を定期的に録音する
2. 録音をAWSへ送りAmazon S3にためる
3. Amazon SageMakerで正常音を基準にした教師なし学習で異音を見つける
4. 異音検知時にAmazon SNSから担当者へメールを送る
5. 担当者が音を聞き現場で整備の要否を決める

2022年末に最初の検知モデルができ、2023年4月には全てのチェーンコンベアで異音検知ができるようになった。

放置すれば3日止まる損傷を稼働時間外の2時間の整備で直せた例があり、始業時と終業前の見回りも取りやめた。

マイナス22度の冷蔵冷凍倉庫での作業は人が集まりにくく、人手頼みのままでは事業が続かない恐れがあった。

倉庫内の物の位置を知るためにセンサーやRFIDを全部に付けるのは手間も費用も見合わなかった。

1. 食品防御用に設置済みの監視カメラ映像を活用対象にした
2. 画像・動画解析エンジンのAMY Insightを選んだ
3. Deep Learningでフォークリフトやカゴ車を追跡する仕組みを作った
4. Amazon EC2上にAWS Deep Learning AMIで土台を組んだ
5. 1対象物あたり最大3,000枚弱で学習させ5ヶ月かけて精度を確かめた

追跡成功率97%を達成し、これまで取れなかった位置と追跡のデータが手に入った。

5ヶ月のうちインフラの準備は約1週間で終わり、残りを学習とモデル調整に回せた。

業務用の冷蔵冷凍庫の故障は顧客からの連絡で知ることがほとんどで、夏に依頼が集中して作業員の確保が難しかった。

大型設備では被害額が1,000万円に達することもあり、早い対応が求められていた。

1. 顧客先の設備にセンサーを付け冷媒圧力と温度を一定間隔で取り込む
2. AWS IoT Coreを入口にS3へデータをためる
3. ためたデータをAmazon SageMakerに学習させ故障の予兆をつかむ
4. 異常検知時は作業者のスマホに通知し準備してから現場へ向かう
5. 故障箇所の候補を3程度まで絞ることを目標にする

現地に行かないと分からなかった設備の状況をリアルタイムで見られるようになり、故障前の修理対応ができるようになった。

1990年代に数百万円かけた遠隔監視システムの置き換えでは10分の1以下のコストになり、学習期間も通常約2ヶ月のところ2週間程度で済んだ。

住宅の工事工程は担当者の経験に頼って組んでおり、経験の浅い社員だと節目の日取りを正しく置けず時間もかかっていた。

1. 現場監督がGeminiのカスタム機能で工程作成の仕組みを作る
2. 着工から引き渡しまで約150日を土台に設定する
3. 木工事完了日やクリーニング日など外せない節目を登録する
4. 着工日を入れるだけで各節目の日付を逆算して並べる
5. 出てきた工程を担当者が現場の事情に合わせて手直しする

入力するのは着工日だけになり、経験の浅い担当者でも精度の高い工程を引けるようになった。

代表からはカレンダーへ全工程を自動連携する次の案も出た。

1日に100社を超える物流業者が予約無しで資材を持ち込んでいた。

到着が読めず構内が渋滞して夕方に荷が集中し残業が増えていた。

1. Oracle APEXの搬入予約の仕組みをAIデータベースへ移した。
2. Oracle Integration Cloudで作り替え無しにつないだ。
3. 納品量と資材の種類と請求書の数から枠を決める予約画面を業者へ開放した。
4. 発注や書類のデータとひも付け受け入れの上限や例外の決まりを自動で確かめる。
5. 業者が入退場や滞留時間や書類の不備を自分で確認できるようにした。

納品の順番が整い待ち時間と残業が減った。

滞留時間や生産性を細かく測るためのデータの土台もできた。

手作業の組立が決められた手順どおりかを人が見張るのは手間がかかり間違いも起きやすかった。

人の入れ替わりも多く見張りの範囲を広げられなかった。

1. カメラの映像をNVIDIA VSS Blueprintで動くエージェントへ流す。
2. エージェントが手順から外れた動きや安全の決まりに合わない点を探す。
3. ねじの付け忘れのような外れを見つけると作業者へその場で知らせる。
4. 作業者はその場で直し現場の担当者は該当の場面の短い映像を見返す。
5. 分からない点はエージェントに質問して中身を確かめる。

組立ライン1本あたりの人件費が7%下がり不良率は67%減った。

車種や部品が変わるたびに検査用のモデルを社外の会社に作ってもらっていた。

費用が重く対応も遅いので検査が生産の足かせになりかけていた。

1. IBMと組みMaximo Visual Inspectionを検査の土台にした
2. ノーコードの画面で画像にラベルを付けモデルを学習させる
3. 学習したモデルを現場へ配るまで自社の技術者が担う
4. 工場のカメラやモバイル端末をそのまま使い買い足しを抑えた
5. 設計が変われば技術者がその場でモデルを作り直す

115を超える検査モデルを作り重慶の主力工場を含む3つの工場へ広げた。

モデルの開発と展開にかかる費用は60%減った。

建物の改修需要が増え、従来の保守に加えて中小規模の建設工事にも対応するようになった。

現場担当者が確認する対象が製品仕様だけでなく建設業法や下請法、社内規定まで広がり、調べる手間が重くなっていた。

1. 取扱説明書やスペックシートをSTiVに登録した。
2. 業務標準や社内規定も入れてまとめて検索できるようにした。
3. 自席のパソコンや現場のタブレットから質問を投げる。
4. 回答と一緒に参照元の資料と該当箇所を返す。
5. まず約30名で3〜4ヶ月試し効果を確かめて広げた。

あいまいな記憶からでも目的の資料にたどり着けるようになり、情報検索にかかる時間が大きく減った。

試行後はメンテナンスサービス領域全体の約1,000名規模へ広げている。

エアコンなど機器の交換や回収の記録をパソコンからしか入力できず、後回しによる入力漏れや確認の遅れが起きていた。

在庫数が正確につかめず、回収を頼む時期を逃すこともあった。

1. 既存のクラウド環境に生成AIと自動化の流れを組み合わせた
2. 現場のスマホから操作できる専用画面を作った
3. 交換や保管、回収依頼の状態をボタン1つで登録する
4. 登録内容をその場で集計し関係者が最新状況を見られるようにした
5. 決めた台数に達すると社内チャットへ自動通知を飛ばした

入力漏れと回収依頼の遅れがなくなり、年間20時間の業務時間を減らした。

鰻の成瀬はテイクアウトの需要が高く電話注文が多いが、混み合う時間帯の着信がそのたびに調理と接客の手を止めていた。

電話に出られず注文を取り逃がすことも起きていた。

1. 店舗への電話に対話AIのアイブリーが応答する
2. テイクアウトのメニューを音声で案内し品目と数量を聞き取る
3. オプションと受け取り時間と氏名も続けて確認する
4. 聞き取った内容をテイクイーツへ連携し予約として登録する
5. スタッフは調理と接客を続け登録された注文を見て用意する

電話対応にかかる現場の手間を大きく減らせる形になり、目の前の客への対応に集中できる環境ができたとPafit側は説明する。

全店ではなく一部店舗で実証を進めている。

品質を確かめるテスト室の熱の流れを調べるのに、これまでの流体解析では準備と計算に時間がかかりすぎた。

条件を変えるたび最初からやり直しになり、生産の遅れと無駄な電力を生んでいた。

1. 工場のデジタルツインにNVIDIA PhysicsNeMoを組み込む
2. 物理の法則を学ばせたAIモデルで熱や空気の流れを解く
3. テスト室の条件を変えながらほぼその場で結果を見る
4. 生産ラインの画像をCosmosとTAOに渡し欠陥の画像を作る
5. 数千のセンサーの値をつなぎ冷却と試験の予定を調整する

品質管理の工程を調べるシミュレーションが15時間から3.6秒になり、15,000倍に速くなった。

欠陥の検出精度は5%〜20%上がり、全拠点の電力使用量はおよそ10%減った。

週報を毎回一から自分で書いていた。

同じ言い回しにならないよう調整したり上司が読みやすい形に整えるのに時間がかかっていた。

1. 1週間の作業と進み具合を箇条書きにする
2. その箇条書きをMicrosoft Copilotへ入れる
3. 週報として読みやすい文章にまとめるよう頼む
4. 硬い文になったら簡潔にと追加で指示する
5. 事実と表現を自分で確かめてから提出する

週報を書くのにかかる時間が1回あたり約10〜15分減った。

言い回しを考える時間が減り中身の確認に集中できるようになった。

取引先へ送る納期の連絡文を全部自分で考えて書いていた。

おかしな言い回しになっていないか不安で送信までに時間がかかっていた。

1. 納期の連絡文をLINE向けに自分で書く
2. その文をChatGPTへ貼り不自然な所を直してもらう
3. 丁寧かつ少し柔らかい文に訂正してと指示する
4. 出てきた文を自分で読み直してから送信する
5. 上司に聞けないときは状況と文を渡し相談の仕方も尋ねる

取引先へLINEを送るまでの時間が15分から2分になった。

手が空いたときに聞き方で悩む時間も20分から1分に減った。

何年も直していないマニュアルは文字ばかりで若手に伝わらなかった。

古いWordを開いて打ち換えるやり方なので書き直しに膨大な時間がかかっていた。

1. 古いマニュアル本文をコピーし機密の固有名詞や数値を先に消す
2. 20代の現場作業員が一読で理解できる手順書にしたいと伝える
3. 1文を短くし専門用語に説明を足す条件を指定する
4. 危ない箇所を太字にしてチェックリスト形式にさせる
5. 出てきた構成案を実際の設備に合わせて直しWordで仕上げる

マニュアル1本の作成と修正が約4時間から約1.5時間になった。

月に4本ほど作るので毎月約10時間の作業が減った。

部品の遅れや異常が起きるたび伝える内容を自分で整理して書いていた。

送り先ごとに言い回しを変える必要があり急ぐ場面ほど文を考える時間に取られていた。

1. 伝えたい要点を箇条書きで書き出す
2. 細かく伝えたい所だけ文章の形にしておく
3. 仕入先宛のメール文を件名も含めて作るよう指示する
4. 出てきた文を自分で直して仕入先や輸送会社へ送る
5. 添付つきのメールは本文と資料を読ませ要点をまとめさせる

メール1件にかかる時間が10分から5分程度になり週2.5時間の削減になった。

異常が起きた週は5時間ほど減っている。

新製品の投入が速く電池や業務用工具の需要も伸びて、工場の予定と設備が追いつかなくなっていた。

つながっていない古いシステムと表計算の計画では生産と保守の時期を合わせにくく、主要なプレス機が急に止まる不安があった。

1. 計画から出荷までをOracleの1つの土台に載せた
2. 現場にIoTで設備の状態を見る仕組みをつないだ
3. 納期と工具と作業者の制約から生産の順番を決める
4. 設備の状態から故障の兆しを見つけて作業指示の案を出す
5. 入荷の遅れや在庫の不足を例外として担当へ知らせる

現場の判断は数時間かかっていたものが数分で済むようになった。

急な故障の呼び出しが減り、予定どおりに生産が進む割合も上がった。

18の工場はDCSとSCADAが混在し、多数のセンサーから流れてくるデータを人手で分析できなかった。

排出量の上限を超えれば罰金の恐れもあり、効率を上げる手がかりが必要だった。

1. 回転窯の熱の消費量をその場で集める
2. 工程のデータとガスの排出量を突き合わせた
3. 組み合わせをDataRobotに読ませ品質に効く項目を出させる
4. 出てきた項目をもとに運転の設定を直した
5. 工程や保全の担当者にもDataRobotを渡す

分析の結果を待つ時間は28日から7日に縮み、粉砕や材料の使い方などの改善で年160万ドルほどの節約になった。

代替燃料の比率は4%から30%に上がり、1ポイント上がるごとに年150万ドルほどの節約が出ている。

世界に40か所以上ある工場で、エネルギーの使い方をつかむ手立てがなかった。

アンモニアの冷凍機は外の気温が低いときも全力で動かしていて、負荷の偏りが電気の使いすぎと整備の増加を招いていた。

1. C3 AI Process Optimizationを工場の1つに入れた。
2. 24週間で設定と立ち上げを終えた。
3. アンモニア冷凍システムへ4時間ごとに設定値の案を出す。
4. 運転する人が判断に関わる数値をまとめて見られるようにする。
5. 動かす場所はAWSにしてAmazon EKSなどを使う。

最初の本番導入で、冷凍システムのエネルギー費用を25%以上減らせることを示した。

全工場へ広げれば年間で最大900万ドルの効果になると見込む。

世界各地の拠点に膨大な設備があり、どれが壊れても大きな損失につながる状態だった。

拠点も機器も多すぎて、全社の規模に合う故障予測の仕組みを作れなかった。

1. C3 AI Platformを選び専門組織（CoE）を立ち上げた。
2. 開発チームを2つに分けて4か国で進める。
3. 効果の大きい使い道から順にアプリを作った。
4. 制御弁は故障予測とモデル管理を1つにまとめる。
5. 圧縮機は機器ごとにモデルを調整し技術者へ通知を出す。

立ち上げから数か月で全社規模の展開まで進み、初年度に2つのアプリが本番で動いて1つが実地試験に入った。

4年で15以上のアプリを出す計画になっている。

研究開発の予算の半分近くを文書づくりに使っていた。

苦情の対応づけは特に複雑で、必要な情報が取扱説明書や過去のリスク文書に散らばって仕上げに数週間かかっていた。

1. 開発者とデータ科学者と品質の担当が組んだ。
2. 苦情の分析に必要な文書の範囲と出したい形を先に決めた。
3. 決まった形になっていない書類も読めるように分割の仕組みを作る。
4. 深層学習で社内の言い回しと前後の意味を覚えさせた。
5. 出す形式と見られる人の範囲は会社の決まりに合わせる。

品質の担当は下準備なしで苦情の情報を引き当てて対応づけられるようになった。

出てくる内容は作り話が混ざらず、会社が決めた形式と閲覧の範囲も守られる。

点検の担当者は設備の記録を探すのにいくつものシステムを行き来していた。

手書きのメモや紙を読み取った数百ページ分もあって、書類の形式もそろっていなかった。

1. 現場に詳しい人と点検担当が一緒に点検データの流れを組んだ
2. クラウドの保管先と設備管理のシステムからデータを集めた
3. AIが点検データをその場で要約し過去の書類も検索できるようにした
4. 要約に元の書類へのリンクを付けて担当者が中身を確かめる形にした
5. 動かす場所はAWSにしてAmazon EKSやSageMakerを使った

点検の担当者は必要な記録をすぐ見つけられるようになった。

要約に付いた出典から元の書類を開いて確かめられる。

製油所では下流の工程が求める規格より高い品質の製品を作ってしまう余剰が利益を削っていた。

担当のエンジニアはExcelにデータを集めて手で計算するしかなく、報告は月1回か四半期に1回が限界だった。

1. 短い導入研修を受けた工程のエンジニアが処理の流れを自分で組んだ
2. OSI Piの運転データを取り込み余剰の量を計算するまでつないだ
3. 3〜7日先の余剰を予測する機械学習モデルを設定した
4. 報告はボタンを押すだけで出る形にした
5. 社内では別に18人が同じ仕組みの研修を受けた

手計算より正確な報告が1クリックで出るようになり、余剰は3〜7日先まで予測できるようになった。

4件の用途が動いていて1件は開発中で、年あたり少なくとも50万ドルの効果が見込まれている。

石油生産の副産物ガスを使うために移動式の圧縮機を入れたが、数か月で毎日の故障と1台あたり月1,500件を超える警報に追われるようになった。

多くは誤った警報で、既存の制御では故障を前もって当てることも原因をたどることもできなかった。

1. 圧縮機の信頼性を上げるためC3 AI Reliabilityを選んだ
2. 10週間で4か所に散らばるデータをつないだ
3. 5,500万行超の運転データから異常を見つける流れを作った
4. 故障の兆しを前もって出させダッシュボードに並べた
5. 人が兆しを確かめ原因を調べて手当てする

故障を前もって予測できるようになり、原因の切り分けもダッシュボードで追えるようになった。

生産性とガスの処理量が上がり保守費も下がることで、年4,000万ドル以上の効果を見込む。

設備の故障で大きな計画外の停止が起きて、保守のやり方を見直すことになった。

それまでのルール型の監視は毎日大量の警報を出すだけで、現場は誤報と本当の異常を見分けられなかった。

1. Baker HughesとC3 AIの技術者が支援に入った
2. 27拠点2,500台超の設備から2年分以上のデータを取り込んだ
3. ばらばらのデータを2週間でひとつにまとめた
4. 異常を見つける流れを組み2系統で故障を予測させた
5. 警報の質を上げ対応すべき異常だけを追う形にした

ガスコンプレッサーと水注入ポンプの2系統で稼働が伸びて保守の費用も下がった。

年間の増収と費用の削減が大きく見込めるようになった。

重要な設備が止まると原因探しに8時間を超えることがあり、そのあいだ生産が止まって大きな損失が出た。

技術者の退職がかつてない水準まで増えて、熟練者の記憶に頼る進め方が限界になった。

1. 技術者のメモや設備の手順書など1,000件を超える資料を読み込ませた。
2. SAPの作業指示と部品在庫のデータも同じ場所に集めた。
3. 文章の資料も表のデータも大規模言語モデルが横断して探せるようにする。
4. 技術者が症状を入れて原因の候補と直し方を受け取る形にする。
5. 仕組みはAWSの上で動かして社内のデータとつないだ。

設備が止まったときの平均の修理時間が最大50%短くなった。

1,000件を超える資料とSAPのデータにすぐ当たれるので、熟練の記憶に頼らず直せるようになった。

これまでの予知保全の仕組みは空軍が自分たちで持てず、データを自動で取り込む許可も無かった。

B-1Bのセンサーデータは符号化されていて、世界各地の担当者がすぐに中身を見られなかった。

1. B-1Bの過去5,000回の出撃分のセンサーデータを取り込んだ。
2. 取り込んだデータを1つのデータの形にそろえた。
3. 正常なときのデータだけでモデルを学ばせて本来の数値を当てさせる。
4. 実測と予想のずれからシステムの異常と部品の異常を切り分けた。
5. 警報を見る画面も作り技術者が根拠を確かめてから指示を出す形にする。

以前は数週間から数か月かかっていた監視モデルの開発が、数日で終わるようになった。

出撃の直後にデータを上げれば自動で読み取って警報が出るので、警報を見るまでの時間も短くなった。

需要の読みが甘く、製造コストを抑えた生産計画を組めていなかった。

データが別々の仕組みに散らばっていた点も計画作りの壁になった。

1. 需要の見込みと顧客の注文のデータを1つにまとめた。
2. 製造コストと部品の在庫のデータも同じ場所に集めた。
3. まとめたデータで需要を予測する機械学習のモデルを学習させる。
4. 最適化の計算で60日先までのコストが安くなる生産計画を出させた。
5. この仕組みを大きなポリプロピレンの工場に当てはめて動かす。

製造コストを抑えた生産計画を出せるようになり、顧客の需要予測の精度が20%上がった。

既存の制御の仕組みでは圧縮機の故障を前もって当てられず、原因を切り分ける材料も出てこなかった。

データが複雑で本物の警報と空振りの見分けもつかず計画外の停止で遅れと修理費がふくらんでいた。

1. Baker HughesとC3 AIのチームが8週間で立ち上げた
2. ばらばらの4つのデータ源から14億超のデータ点を取り込んだ
3. 異常検知のモデルを組み故障を前もって当てられるようにした
4. 画面にKPIとAIのアラートと設備の状態をまとめて出した
5. 運転する人はアラートから手を打つものだけ選んで対応する

計画外の停止のうち89%を5日前に当てられるようになった。

誤った警報は55%減った。

それまでの方法では温室ガスの排出を細かく測れず、設備ごとの効率も見え方がそろっていなかった。

運転の不具合に先回りして手を打てなかった。

1. 主要な2つの海洋プラットフォームへ16週間で設定した
2. 関係するシステムから取り出したデータをまとめて最新にした
3. 確率を使った教師あり学習で設備ごとの基準値を作る
4. 設備や全社の単位で排出量をほぼその場で見る画面を用意した
5. 実際の値と基準値を比べて減らせる場所を数字で示す

年間880CO2eトン分の減らせる余地が分かった。

排出が増える運転状態の変化を10件、排出の異常を30件つかんだ。