製造業のクラウド活用最適解〜AI，DXを加速するデータ基盤の作り方〜

Factory Creative Camp大阪での登壇内容。ハノーバーメッセ2026で見た世界の製造業AIの最前線と、日本の現場で今すぐ始められる段階的なデータ基盤の作り方を、ロッテ浦和工場の実践事例とともに紹介します。

Transcript

1. 製造業のクラウド活用最適解 〜AI, DXを加速するデータ基盤の作り方〜 製造ビジネステクノロジー部 スマートファクトリーチーム マネージャー 濱田孝治（ハマコー）
2. 2 濱田孝治（ハマコー）製造ビジネステクノロジー部 スマートファクトリーチーム マネージャー 製造業向けAI・クラウドソリューションの企画 導入支援 コミュニティ運営 • JAWS-UG コンテナ支部運営 • Grafana Meetup Co-organizer, Grafana Champion AWS認定関連 • SAP, DOP, DBS, SOA, SAA, DVA, SCS, CLF, AIF, MLA, MLS • AWS APN Ambassador 2020 執筆書籍 • みんなのAWS • SoftwareDesign 2022年11月号 コンテナ特集
3. 3 Xアカウント @hamako9999
4. 4 製造業関連ブログ「クラスメソッド 濱田 or ハマコー」
5. 5 最初に 製造業におけるAIやデータ活用に関する 質問をさせてください！！ 全部で3問 貴重な機会なので億劫がらずにどうぞ！！
6. 6 Q1 すでに自社で何らかのデータを クラウド上に上げ始めて居る方
7. 7 Q2 そのデータを"見える化"のさらに先 分析・予測・AIまで活用している方
8. 8 Q3 データがバラバラ・サイロ化していて どこから手をつけるか悩ましいと 感じている方
9. 9 ここまで 製造業におけるデータ活用の現在地が いくらかほの見えたのではと思います
10. 10 製造業で扱うデータは多種多様
11. 11 本日お伝えすること 私の経験 • ハノーバーメッセ2026で見た現地の情報 • 顧客と共に試行錯誤した経験 今日お伝えするのは ・教科書的な理論 → ✘ ・ハマコーの主観 → ◦
12. 12 Agenda • ハノーバーメッセ2026に見る世界の最新潮流 • 段階的なデータ基盤の作り方 • 実践事例 株式会社ロッテ 浦和工場
13. 13 ハノーバーメッセ2026に見る 世界の最新潮流
14. ハノーバーメッセ 皆さんご存知でしょうか？ 14
15. 15 4月20日〜24日、同僚の田中と行ってきました
16. 16 ハノーバーメッセとは（定量的に） 項目 概要 開催時期 2026年4月20〜24日（5日間）／ドイツ・ハノー バー 規模 世界50カ国以上から、来場者約13万人。製造業と して世界最大級の産業見本市 今年の中心テーマ Industrial AI（産業AI） — 例年の「AIもある」 から、会場全体がAIへ振り切れた
17. 17 ハノーバーメッセとは（主観的に） 製造業の 森羅万象が集まっている場所 • オープニングセレモニーの政治色の強さ • 世界を代表するプレイヤーの超大規模かつ異常 に数が多い展示 • 各国の国代表としての展示の多さ • 標準団体（Manufacturing-X、OPC Foundation、Open Data Space）の展示規模
18. 18 現地でみた製造業AIの最前線
19. 以下のカテゴリーにわけてお伝えします Opening Ceremony AWS Microsoft Siemens SAP OPC Foundation 19
20. 20 Opening Ceremony
21. 21 Opening Ceremony https://dev.classmethod.jp/articles/hm26-pressday-opening/
22. 22 Opening Ceremony 会場
23. 23 Opening Ceremony 会場 プレス入口
24. 24 インダストリー4.0の提唱者 Wolfgang Wahlster氏と
25. 25 Opening Ceremony 会場内
26. 26 Opening Ceremonyの登壇者 Friedrich Merz 氏 • ドイツ連邦共和 国首相 Luiz Inácio Lula da Silva 氏 • ブラジル連邦共 和国大統領 Dorothee Bär 氏 • ドイツ連邦研究・ 技術・宇宙大臣 Julie Sweet 氏 • Accenture 会長 兼CEO Dr. Gunther Kegel 氏 • ドイツ電気・デジ タル産業連盟 （ZVEI）会長 Belit Onay 氏 • ハノーバー市長 （開催都市ホス ト）
27. 27 Opening Ceremonyのメッセージ 産業AIのEU規制緩和（EU AI Actからの切り 出し）の推進 「Made for Germany」を掲げた8,000億ユー ロの巨額投資 事業の「Reinvention（再発明）」の必要性と グローバルな連携強化
28. 28 AWS
29. 29 AWS – ブース全体「Built for Industrial AI」
30. 30 AWS – ブース全体「Built for Industrial AI」 1,400㎡の大型ブース、25パ ートナー＋9 Amazonキオスク 会期中50以上のセッションを 連続開催 3つのソリューション領域：エ ンジニアリング／スマート製造 ／スマート製品
31. 31 AWS – AI-Powered Production Line（中央の動くライン） ブース中央に実際に動く製造 ラインを設置 ドリンクコースター製造の体 験型デモ AMR（自律移動ロボット）→ 協働ロボット → レーザー彫 刻機 → AI品質検査 → ヒュー マノイド の完全自律フロー
32. 32 AWS - The Complete Stack for Physical AI（5層） 1. Data — 現場データ取り込み 2. Training & Model Optimization — モデル学習（NVIDIA連携） 3. Simulation — Isaac Sim/Lab 4. Sim2Real & Edge Operations — IoT Greengrass + Jetson Thor 5. Agentic AI — Bedrock AgentCore + Strands Agents
33. 33 AWS - Agentic AIが既存システムを束ねる • 中央エージェントがMCP（Model Context Protocol）経由で疎結合 に接続 • MES／MOM／PDM／在庫管理を既存のまま叩く • 「置き換える」のではなく「上から束ねる」アプローチ
34. 34 Smart Products and Services — Kiroで組み込みアプリを構築 • HVAC（空調機器）のコンパ ネを想定したミニデバイス • 中身の組み込みアプリの開発 をKiroを用いて実施 • 産業機器のテスト/デバッグ は一般的なITアプリケーショ ンに比べて手間が多いが、そ れをKiroを用いて短縮化する 内容 • ワークショップも公開されて いて誰でも体験可能
35. 35 AWS - Zoomlion事例：自社製造×AWS Marketplace • Zoomlion（中聯重科）：中国の建機・産業機械メーカー • 自社製造現場でロボットを多用、AI開発環境としてAWSを採用 • 構築した製造管理システムをAWS Marketplaceで販売 • 他のお客様がワンクリックで導入・スモールスタートできる流通モ デル
36. 36 Microsoft
37. 37 Microsoft：AIが「領域の壁」を越えた
38. 38 Microsoft：AIが「領域の壁」を越えた Fabric IQ / Work IQ / Foundry IQ：データ層・現場層・AI開発 層の3層基盤 フィジカルAI：ヒューマノイド × Hexagon検査ロボの統合デモ Azure IoT Ops × Omniverse：情報AI × 物理AI × OT が一つに →情報・物理・OTという「面」をAIが 一気通貫で動作
39. 39 Microsoft - ブース全体「産業インテリジェンスの解放」 • テーマ：産業インテリジェン スの解放 • 4つのヒーローデモゾーン： 製品ライフサイクル／工場運 営／人間×エージェント／サ プライチェーン • パートナー総動員： Hexagon、Advantech、 Siemens NX、Ansys、 NVIDIA、Krones
40. 40 Microsoft - フィジカルAI（Hexagon × Siemens NX） • Siemens NXで設計 → エー ジェントがCAM展開 • ヒューマノイドがワークを CNCに運搬 • Hexagonロボットが良/不良 判定 • エッジ側にAIが入って自律 的に判断・動作（クラウド指 令なし）
41. 41 Microsoft - Microsoft IQ for Manufacturing × Copilot Studio シフト引き継ぎのデモ： • 前シフトが「歩留まり低下」 「メンテ必要」をCopilotに 引き継ぎ • 次シフトが「シフトブリー フ」を依頼 → サマリーが自 動生成 • 「振動が大きい」アラートに 対しCopilotが根本原因分析 • Copilot Studio（ローコー ド）上で動く＝現場の人が触 れる
42. 42 Microsoft - エージェント型サプライチェーン（Fractal） • Microsoft Foundry上のAIエージェ ントがシグナルを常時モニタ • 内部：POと出荷紐付け、サプライヤ ーキャパシティ • 外部：船舶位置データ・港湾混雑・ 気象・需要シグナル • アラートではなくプランA/B/Cを生 成 → 人間が選ぶ
43. 43 Microsoft - Krones × Industrial Copilot：4時間→30分 ボトリングのチェンジオーバー（段取り替え）： • 従来：4時間 → 改善後：30分 • AnsysシミュレーションをNVIDIA GPUで実行 • Copilotが裏でシミュレータを呼び出し、機械設定を自動提案
44. 44 Siemens
45. 45 Siemens：AIが「エンジニアリングチェーン」を貫通
46. 46 Siemens：AIが「エンジニアリングチェーン」を貫通 Teamcenter（PLM）＋ TIA Portal + Industrial Copilot：設計 から制御プログラミングまでをAIが支援 バーチャルコミッショニング：90%のバグを物理製造前に検出 ポップアップファクトリー：必要なときに、必要な場所で、必要なも のを作る AIが設計 → 製造 → 保守という軸を貫 通
47. 47 Siemens - ブース全体「CPGをショーケースに」 CPG（消費財）業界の3つのチ ャレンジを起点に • バリエーションの多さ（SKU 爆発） • トレンドが変わりやすい（短 サイクル） • 各国の規制対応 → データ統合 → 標準化 → ソ フトウェアディファインド → AIの4レイヤーで提案
48. 48 Siemens - データのサイロを崩す「Teamcenter」 Teamcenter：PLMのデータバ ックボーン 各部門のツール・システムを一 元化 「みんなが同じ1つのデータを 見て話す」 アイデア → 設計 → 製造要件 → 品質 → レシピを直列に積み 上げ
49. 49 Siemens -ラボから生産への加速 — デジタルツインで時間を圧縮 デジタルツインのフル活用 • レシピ完成後のプロダクショ ンライン構築のリードタイム 短縮 • ビューラーのミキサーをデジ タルツイン化し、中の環境を シミュレーション、マシンパ ラメータを最適化
50. 50 Siemens – マルチベンダーをつなぐPLC統合制御 「シーメンスのPLCがマルチ ベンダーのロボットを束ね る」 という思想 現場には様々なロボットメー カーの機器が存在 ベースになっているのは PROFINET協会が定めるロボ ットコントロール規格で、 PROFINET経由で特定のコマ ンドを叩くと、メーカーが違 っても同じ枠組みで動作可能
51. 51 Siemens - TIA Portal × Industrial Copilot PLCエンジニアリング環境のAI 支援： • PLCラダーの自動生成 • HMI画面の自動生成 • 仕様書 → プログラム雛形 → エラーをCopilotにフィード バック • バーチャルコミッショニン グ：実機なしで試運転完了
52. 52 Siemens - ポップアップファクトリー 必要なときに、必要な場所で、 必要なものを作る • ワールドカップ会場で一時的 にジュース需要が急増 • 既存工場から配送 vs スタジ アム近くにコンテナ工場 • AIが需要予測 → サプライチ ェーンスイートでコスト比較 • メタバース／デジタルツイン で設備配置を確認
53. 53 Siemens - Innovation Hub：エージェンティックAI×カスタムシューズ 来場者の足型を実演スキャン： • 足の形状・圧力分布をスキャ ン • エージェンティックAIが CADソフトNXに「ソール設 計して」と指示 • NXのCopilotが個別最適なソ ール形状を自動生成 • そのまま製造工程へ投入 → 「自律型工場」の解＝エージ ェンティックAI
54. 54 Siemens - Innovation Hub：エージェンティックAI×カスタムシューズ
55. 55 Siemens - Innovation Hub：エージェンティックAI×カスタムシューズ
56. 56 SAP
57. 57 SAP - ブース全体「Trusted Orchestration. Smarter Execution.」
58. 58 SAP - ブース全体「Trusted Orchestration. Smarter Execution.」 題材はジンジャーショット（エ ナジードリンク） • 複数の仮想企業を横断するシ ナリオ：プロセス製造／ディ スクリート製造／サプライヤ ーCNC • ブースを左から右へ歩くと、 サプライチェーンの上流から 下流を辿る動線 • ERPとMES、Business Network、PLMまで自社フル スタック
59. 59 SAP - Operations and Insights（経営の見える化） • 2拠点工場（ミキシング側／ パッケージング側）を一元監 視 • 外部シグナルを取り込みAIが アラート化 • 「Asian Shipment Delayed」が Critical に自動 スコアリング • 財務（売上・利益）と現場 KPI（OEE・在庫）が同じ画 面
60. 60 SAP - マルチエージェント基盤（Joule＋40以上のエージェント） シナリオ：原材料の輸送遅延4〜 6週間 → 経営インパクト1,800 万ドル • Inventory Balancing Agent （EWM内蔵） • Supplier Discovery Agent （Business Network内蔵） • Trade-off Analyst（全エージ ェントを統合） • → プランA／B／Cを生成 → 「Accept All Tasks」で担当 者にタスク配信
61. 61 SAP - SAP Digital Manufacturing × Uhlmann（実機） ドイツUhlmannの本物のパッケ ージング機が動いている • 「SAPはMESもやっている」 （20年前に買収、現在クラウ ドMES化） • S/4HANA → SAP Digital Manufacturing → 実機 のデ ータ連携 • 通信規格はOPC UAで標準化
62. 62 SAP - 企業を越えるオーケストレーション（DMG MORI × Business Network） 包装機の補修部品をサプライヤ ー企業のCNCで製造： • Uhlmann包装機の部品が摩耗 → センサーで予兆検知 • AAS（Asset Administration Shell）でパーツ情報をスキャン • SAP Business Network経由で サプライヤーに連携 • サプライヤー側 S/4HANA → MES → DMG MORI CNC • 企業を越えてスペアパーツが削り 出される → Factory-X／Catena-Xに対応済み
63. 63 SAP - フィジカルAI × 設備保全（4足ロボット） ミキシング設備の異常傾向シナリオ： 1. システムがデータドリブンに異常傾 向を検知 2. AIエージェントが4足ロボットに検 査指示 3. ロボットが該当設備まで物理的に移 動 4. 搭載カメラで外観検査、過去データ と照合 5. 必要に応じてメンテナンスオーダー 自動発行 → 「指示の受け手は人でもロボットで もいい」
64. 64 OPC Foundation
65. 65 もう一つのテーマ 巨大企業の根底に横たわる OPCという規格とその存在感
66. 66 最初にOPCとは？ 「製造業の機器同士・機器と ITシステムを、メーカーを問 わずに繋ぐためのオープンな 通信規格」
67. 67 なぜ今、OPC UAが「製造業の共通言語」なのか OPC = Open Platform Communications（元は OLE for Process Control） •元々はWindows COM/DCOMベースの規格 （1996年〜）→ 2008年にプラットフォーム非 依存の OPC UA に再設計 •Industry 4.0の提唱と合わせて普及が加速 現在「OPC」と言えば実質「OPC UA」を指すこ とがほとんど
68. 68 OPC Foundation：規格団体が構える巨大ブース
69. 69 OPC Foundation：詳細はこちらのブログで https://dev.classmethod.jp/articles/hm26-opc-ua/
70. 70 なぜ今、OPC UAが「製造業の共通言語」なのか 認証・暗号化・証明書管理を標準で扱えるOPC UAは、 欧州市場で必須選択肢に。 •主要ベンダーのブースで「OPC UA対応」が共通前提 •欧州での採用が加速 •EU CRA（Cyber Resilience Act）の本格適用が近い •セキュリティ非対応の製品は市場で受け入れられに くい •認証・暗号化・証明書管理を 標準仕様 で扱える
71. 71 Open Process Automation（OPA） OPA：特定ベンダーに縛られないプロ セスオートメーションシステム • 推進元：ExxonMobil（オイル＆ガ ス系の脱ベンダーロックイン） • 通信プロトコル：OPC UA を採用 横河電機が2026年4月、世界初の OPA 向け OPC UA 認証取得
72. 72 Open Process Automation（OPA） OPAブースの展示デモ： - 横河電機のコントローラー - Phoenix Contact のデバイス - メーカーバラバラでも OPC UA を共 通言語に動作 - 制御アプリケーションは コンテナ化
73. 73 OPC UA のセキュリティ Modbus（従来型） → OPC UA - 認証 ：プロトコル外 → 証明書ベース相互認証を標準装備 - 暗号化：なし → メッセージ署名・暗号化を標準装備 - 防御層：ネットワーク分離・FW頼み → プロトコルレベルで構築 クラウド連携 - MQTTSによる暗号化は可能 - OPC UA はさらに 鍵管理・体系的暗号化 を持つ → 「ネットワークを守る」から「通信そのものを守る」設計。EU CRA 時代に効くセキュリティ設計
74. 74 証明書管理の運用解＝GDS（Global Discovery Server） - 工場単位で構成可能 - ライン単位でも構成可能 - CA of CA（工場の上の親玉）階層も組める - 信頼リスト配布・有効期限更新を 一元化 → 大規模工場・複数拠点を抱える製造業の 現実解
75. 75 OPC UA for AI：情報モデルとAIの親和性 OPC UA は単なる通信プロトコルでは ない： - データ構造を 「情報モデル」として 標準化 - センサーの生データ - タグ付け・意味付けされた構造化デ ータ → 生成AIがデータの 「意味」を理解 できる
76. 76 Cloud Library / Cloud Initiative Reference Architecture クラウド時代の取り組み： - OPC UA Cloud Library - UA Cloud Initiative Reference Architecture 公開されている構成例： - MES / ERP - 時系列データベース - 可視化（Grafana 等） → ワーキンググループに 主要クラウドベン ダーが総揃い → OPC UA は「OT内で閉じる規格」ではな く、クラウドエコシステム前提で進化
77. 77 Cloud Library / Cloud Initiative Reference Architecture ワーキンググループの一覧
78. 78 OPC UA via REST：IT基盤からもそのまま叩ける OPC UA via REST（プロトタイ プ）： - REST API 経由で OPC UA データ にアクセス - AWS の API Gateway、ロードバ ランサー、認証・認可、監視と接続 可能 - IoT Core / SiteWise 以外の 一般 的なIT基盤 からも素直に扱える - 現時点ではプロトタイプ段階 → ITエンジニアにとっての OPC UA の敷居が一気に下がる可能性
79. 79 Digital Product Passport with OPC UA：トレーサビリティの規格化 Digital Product Passport（DPP）： - 欧州主導のトレーサビリティ規制 - 「どこで・誰が・どのように」作ったか - 原材料から カーボンフットプリント ま で紐付け - SAPブースでも大きく展示されていた 機器側からの情報拾い上げ： - プロトコル層に OPC UA が選択肢 - 製造記録・品質データを OPC UA で上 位に流す → そのまま DPP対応のインフラ として使 える
80. 80 OPC UA Field eXchange（FX）：コントローラーがフラット通信 OPC UA Field eXchange（FX）： - コントローラー同士が 「フラットに」OPC UA で通信 - Pub/Sub の UDP でセッション問題を解消 - 従来：階層構造（上にボスが居る） - FX：フラットネットワーク（ボスがいない 世界観） ブース展示の事実： - 三菱、オムロン、富士電機など 日本の主要 PLC ベンダーも対応 → 日本の現場で使われているPLCも、すでに FX 対応が進んでいる
81. 81 OPC UA Safety：機能安全領域への拡張 - Safety 通信を OPC UA の枠組みで扱う - 確実性・冗長性を満たす - OPC UA の情報モデル・セキュリティ機能 と統合 - 従来のベンダー固有プロトコルからの脱却 → 「製造業の通信規格を1本に統一する」野 心が Safety まで及ぶ → セキュリティ・情報モデル・クラウド・ AI・FX・Safety、全てがOPC UAの傘の下 に
82. 82 改めて俯瞰する ハノーファーメッセは どうだったのか？
83. 83 世界を代表する巨大プレイヤーが 製造業のあらゆる分野での AI実践活用に 本気で向き合い始めた
84. 84 マニュファクチャリングチェーンの全体像 引用：日本能率協会コンサルティング https://www.jmac.co.jp/glossary/ma/manufacturingchain.html
85. 85 マニュファクチャリングチェーンの全体像 引用：日本能率協会コンサルティング https://www.jmac.co.jp/glossary/ma/manufacturingchain.html 各社濃度の違いはあれど、 展示内容にはほぼ全てこ れらが含まれていた AIを基盤として
86. 86 世界を代表する巨大ベンダーが、同じ未来を向き始めた •製造業のあらゆる領域（プロダクションチェーン、 サプライチェーン、エンジニアリングチェーン）に 対して、未来を見せようとする強い意志がある •自社だけでは出来ない部分は積極的にパートナーの 機器やソフトウェアと連携 •その統合手法の核となる技術が間違いなくAIエージ ェント
87. 87 段階的なデータ基盤の作り方
88. 88 こう感じている方もいるのでは？ 巨大企業のデカい話 ばかりしてましたが 我々はどこから取組 むのが良いのか？
89. 89 結論めいたものを先に言います 「製造業データ活用の最適解」とは 高価な製品を一式そろえることでも 一気に全社展開することでもない。 現場価値を起点に、段階的にAI Readyなデ ータ基盤を育てるプロセスである。
90. 90 AWS re:Inventにおけるインダストリーブースの流れ 2024年（DWH集約・可視化） • データを全て意味づけし、物理的な一つのデータソースに集約する方 向性
91. 91 AWS re:Inventにおけるインダストリーブースの流れ データ活用のアプローチ：集約型から分散連携型へ 2024年（DWH集約・可視化） • データを全て意味づけし、物理的な一つのデータソースに集約する方 向性 2025年（エージェントによる連携） • データを必ずしも一箇所に集めるだけでなく、エージェントに「どの データがどこにあるか」を教えることで、分散したデータソース（サ イロ化されたデータ）をAIが横断的に活用するアプローチ
92. 92 AI Readyの3要素 • サイロ化されていない、必要なときにアクセスできる アクセス可能（Accessible） • 異なるソースのデータが関連付けられている 統合済み（Integrated) • 正確性・鮮度が担保、メタデータが整備されている 品質担保（Quality）: AI Ready = これら3要素がすべて揃った状態
93. 93 （改めて）AI Readyの3要素 • サイロ化されていない、必要なときにアクセスできる アクセス可能（Accessible） • 異なるソースのデータが関連付けられている 統合済み（Integrated) • 正確性・鮮度が担保、メタデータが整備されている 品質担保（Quality）: AI Ready = これら3要素がすべて揃った状態 これらの要件が満たされていれば、AI Ready。 整備された業務フローで管理されたExcel もAI Readyなデータソースとなりうる。
94. 94 段階的とは？ データ基盤構築の3フェーズ フェーズ 状態 主眼 Phase 1: 可視化 データを集めて「見える」状 態に 現場の困りごとを解消、小 さな成功体験 Phase 2: 統合・分析 複数ソースを関連付けて分 析 全体最適、相関の発見 Phase 3: 新サービス創出 / AI活用 予測・最適化・自律化、外 向きの価値 予知保全・品質予測・ナレッ ジ活用 経産省「DX推進指標」の成熟度レベル（0〜5）でいえば、多くの企業 がレベル1〜2で停滞している。自社の現在地を把握し、次の1段を明 確にすることが出発点
95. 95 どこから着手するか？ 判断軸 • 課題の緊急度 • データの取得しやすさ • 効果の見えやすさ • 経営インパクト 問いかけ • 今最も現場が困っていることはどこか • すでにデジタル化されているデータはあるか • 成果を定量的に示しやすい領域はどこか • コスト削減・売上向上に直結するのはどこか
96. 96 どこから着手するか？ 判断軸 • 課題の緊急度 • データの取得しやすさ • 効果の見えやすさ • 経営インパクト 問いかけ • 今最も現場が困っていることはどこか • すでにデジタル化されているデータはあるか • 成果を定量的に示しやすい領域はどこか • コスト削減・売上向上に直結するのはどこか 典型的な着手パターン 設備稼働データ → 可視化 → 予知保全 品質データ → 不良率改善 エネルギーデータ → カーボンニュートラル
97. 97 製造業のチェーンと関連データ チェーン 役割 主なデータ例 エンジニアリングチ ェーン 製品の企画〜設 計〜開発 CAD/CAEデータ、BOM（部品表）、技術仕 様書、試験・検証データ、設計変更履歴 サプライチェーン 調達〜物流〜販 売 発注・納期データ、在庫データ、物流・配送 データ、需要予測、サプライヤー評価 プロダクションチェ ー ン（製造） 生産計画〜製造 〜品質管理 設備稼働データ（PLC/センサー）、生産実 績、品質検査データ、作業日報、環境データ （温度・湿度）、エネルギー消費量 これら全てを一度にやるのは非現実的 → どこから着手するか？
98. 98 手段の目的化を防ぐには？
99. 99 手段の目的化を防ぐ指針 • 最初から大きなROIを求めない。 小さな成功体験を積み重ねる • 現場のフィードバックが、手段の 目的化を防ぐ羅針盤
100. 100 AI Readyなデータ基盤を作ること自体は「手段」 現場フィードバック型のアプローチ 1. スコープを絞る（1ライン・1設備から） 2. 早い段階で現場に可視化を見せる 3. 「使える/ここが足りない」の声を集める 4. 次に取るデータ・見せ方を調整 5. 成功パターンを横展開
101. 101 よくある失敗パターン 失敗 何が起きるか フィードバックがあれば 最初から全社展開 複雑すぎて頓挫 1ラインの成果が次への後 押しに ROIを先に求めすぎ 投資判断できず停滞 手触りある成果がROIの証 拠に IT部門だけで推進 現場の協力が得られない 最初から現場と組むので 分断しない
102. 102 実際の具体的な事例で ご紹介
103. 103 ロッテ浦和工場における事例
104. 104 顧客事例：株式会社ロッテ様
105. 105 ロッテ浦和工場の課題と取組後の姿
106. 106 システム構成 • PLC Data to Cloud でPLCデータをAWS 上に収集 • データベース構築、 Grafanaで数十個のダ ッシュボード • 紙帳票をデジタル化 （タイムライン型UI を新規設計） • アジャイル開発で現 場要望を迅速反映
107. 107 生産設備ダッシュボード例：設備監視 レポート例 • OEE（総合設備 効率） • サイクルタイム • 生産状況 • 時間損失内訳 • OEE構成要素ト レンド • OEE改善推奨事 項 • アクチュエータ 基準値超過 • アクチュエータ 動作時間
108. 108 生産設備ダッシュボード例：品質管理 パネル例 • 保管温度 • 温度トレンド • 原材料歩留ま り • 充填重量トレ ンド • 殺菌温度推移 • 異物検知回数 • 日別異物検知 数 • 現在製造ロッ ト情報
109. 109 ダッシュボード例
110. 110 タイムライン帳票例
111. 111 得られた成果（After） • 紙帳票の約50%を電子化 • 設備1台単位での生産性評価が可能に • 温度異常を瞬時に検知するアラーム機能 とスマホへのオンコール • 現場作業者が複数設備対応や別業務に時 間配分可能に
112. 112 成功要因 小さく始める ガーナチョコレート1ラインから開始 現場との協働 IT部門と工場担当者とオペレーターで スクラムチーム 内製化を見据える ノウハウ習得を並行で推進 迅速な意思決定 プロダクトオーナーの元不確実性を許容 完璧を求めない
113. 113 まずはミニマムな取組だったけれど AI活用の方向性が見えてきた
114. 114 AI活用への未来展望
115. 115 データ分析AIチャットボットは実装済み データがあればこのような実装は非常に楽になってきている 生産設備ダッシュボー ドに格納された全デー タを対象に、AIチャ ットボットによる分析 機能を提供
116. 116 システム構成（分析用チャットボット追加） Grafana MCP Server 既存APIの MCP化 全体分析用 チャットボット AIの機能進化と関連ツールの充 実により、応答の精度向上と共 に実装難易度が劇的にさがって いる
117. 117 まとめ みなさんへのメッセージ
118. 118 取組むときに意識しておきたい方向性 Q：日本の製造業は全体最適を意識せず各部門の個 別最適だから、結局無駄になると言われている。も のづくり白書にもそう書いてあった。やはりトップ ダウンでの改革が絶対必要なのか？
119. 119 取組むときに意識しておきたい方向性 Q：日本の製造業は全体最適を意識せず各部門の個 別最適だから、結局無駄になると言われている。も のづくり白書にもそう書いてあった。やはりトップ ダウンでの改革が絶対必要なのか？ A：全体最適だろうが個別最適だろうが、無駄にな るものは単に「現場の課題を解決していない」から。 ハードルも高くなるので別に全体最適にこだわらな くても良いのでは？
120. 120 小さく始めて大きく育てる AI Readyなデータ基盤を 作ること自体は手段。 現場が本当に価値を感じて いるかが重要であり、それ が全てのプロジェクトの推 進要素となる。 大きくなればなるほど、こ の方向性の修正が難しい。 1 スコープを 絞る 2 現場に触っ てもらう 3 フィードバ ックを得る 4 方向を修正 する 5 横展開 現場のフィ ードバック が羅針盤
121. 121 小さく始めて大きく育てる 1 スコープを 絞る 2 現場に触っ てもらう 3 フィードバ ックを得る 4 方向を修正 する 5 横展開 現場のフィ ードバック が羅針盤 ここのコストが高い（時間 がかかる、お金がかかる、 都度ベンダー見積もりが必 要、自社で対応できない） ものの導入は、将来的に足 かせになる可能性があるの で、要注意
122. 122 取組の方向性としての結論 個別最適だろうがなんだろうが それが本当に現場の役に立つものであれば ミニマムでも良いのでどんどん導入し修正を 繰り返していくのが良い それが未来のAI Readyな製造業を 作っていくと感じています