光ファイバー通信機器が設置されたデータセンターラック

[製造AIシリーズ — アーキテクチャ編] 279TB収集のためのMDEアーキテクチャ設計 — 8工場のEdge-to-Cloudパイプライン構築記

250以上の産業プロトコル対応 · Edge-to-Cloudパイプライン · 物理レベルのプロジェクト分離 セキュリティとコストのトレードオフを考慮したManufacturing Data Engine実践構築記 Cloud Tech Unit · GCP Delivery SA 3 Yoon Sung-jae | 2026-02-23 事業背景 — PINNモデル基盤の融合データプラットフォーム 製造業のデジタルトランスフォーメーション(DX)における最大のハードルは、現場のITとOTデータをクラウドへ安全かつシームレスに移行する「ラストマイル(Last Mile)」にあります。 本記事は、韓国政府主導で進められた「2025年PINN(Physics-Informed Neural Networks)モデル製造融合データ収集・実証事業」のクラウドインフラパートナーとして、8つの製造企業の異種データをGoogle Cloud Manufacturing Data Engine(MDE)基盤で統合構築した事例を紹介します。 当初の事業計画書における収集目標は185TBでしたが、250以上の産業プロトコルに対応する高性能パイプラインを構築し、目標比150%を超える合計279TBの製造データ(時系列センサー、画像、映像など)の収集に成功しました。本記事では、その巨大なデータダムを構築するために徹底的に議論したアーキテクチャ意思決定(ADR)を共有します。 問題定義 — OT-IT融合の3つのジレンマ PINNモデルの学習を成功させるには、高品質の生データ(Raw Data)が不可欠です。しかしプロジェクトの核心である**「IT-OT融合」**を実現するには、まず両領域のデータが持つ性質と違いを理解する必要がありました。 IT(情報技術)データ: ERP、MESなど業務を支援する経営システムから生成されるデータ OT(運用技術)データ: PLC、SCADAなど物理的な設備を制御し生産を担う現場技術から生成されるデータ この2つの領域を統合する過程で、以下の現実的な障壁に直面しました。 断片化された設備環境とプロトコル(Heterogeneous Environment) 8つの工場はそれぞれ異なる機器を使用していました。IT領域ではERP、MESなどのシステムごとに使用中のデータベースが異なり、OT領域も工場ごとに導入した設備メーカーが異なっていました。さらに収集対象のデータフォーマットも、CSV、JSON、Parquetなどの構造化データから画像(JPG、PNG、BMP)、映像(MPG、MP4)などの非構造化データまで混在しており、これらを網羅する標準化された収集体系の策定は非常に困難でした。 ネットワーク帯域幅の限界とデータ欠損リスク(Network Reliability) 製造現場のネットワーク環境は、大容量データをクラウドに転送するには不十分でした。外部インターネット接続は回線の冗長化が行われておらず、既存の内部業務ネットワークと回線を共有していたため、慢性的な帯域幅不足が発生していました。ネットワーク遅延や切断が発生した場合でも、データはエッジ側で安全にバッファリングされ、ネットワーク復旧時に欠損なく順序通りクラウドに転送できる堅牢なアーキテクチャが必要でした。 厳格な企業間データ分離(Strict Multi-Tenancy) 参加する8つの製造企業は潜在的な競合関係にある可能性があります。クラウドという「共有リソース」を使用しながらも、企業間のデータ混入懸念を完全に払拭する物理レベルの論理的分離(Isolation)がプロジェクト成功の鍵でした。 全体アーキテクチャ — Edge-to-Cloud Pipeline 上記の問題を解決するため、Google Cloudの特化ソリューションであるMDE(Manufacturing Data Engine)とMC(Manufacturing Connect)をコアとして採用しました。全体アーキテクチャは「現場設備に影響を与えない」という大原則の下、4つのLayerで設計されました。 Layer コンポーネント 主な役割 Edge MCe(Manufacturing Connect Edge) 現場ネットワーク内に配置。250以上のプロトコルに対応。ネットワーク切断時はInfluxDBを活用したエッジローカルバッファリングを実行 Transport Cloud Pub/Sub 毎秒数百万件のイベントを処理する大容量非同期ストリーミング。トラフィックスパイク時のシステムダウンを防ぐバッファーゾーンとして機能 Processing Cloud Dataflow リアルタイムデータ正規化(Normalization)。センサー値に設備名・ライン位置などのメタデータを結合(Contextualization)してビジネス価値を付与 Storage BigQuery / Bigtable / GCS ラムダアーキテクチャ(Lambda Architecture)を採用。大規模分析用BQ、リアルタイムクエリ用BT、大容量ファイル用Cloud Storageに分散格納 核心的意思決定 — セキュリティとコストのトレードオフ クラウドアーキテクトとして最も悩んだのは「マルチテナンシー(Multi-tenancy)環境をどう設計するか」でした。収集対象が8つの異なる(しかも潜在的競合関係にある)企業だったため、データ分離レベルに関するアーキテクチャ上の決定が必要でした。 ...

2026年2月25日 · 1 分 · Yoon Sung-jae