投稿日：2026.08.01

データ基盤を選ぶ・設計する

製造

WHITE PAPER · 2026.08

業務との接続と組織のガバナンスから逆算する

発行: taiziii Research
本文: 22ページ

このページで読む PDFを別画面で開く PDFを保存オフライン保存

全文を読む

PDFを読み込んでいます…

このページのテキストを表示

全文テキストを読む

W H I T E P A P E R

2 0 2 6 年8 月データ基盤を選ぶ・設計する業務との接続と組織のガバナンスから逆算する Selecting and Designing a Data Infrastructure: Reverse-Engineering from Business Connectivity and Organizational Governance

P U B L I S H E D B Y

taiziii Research Manufacturing DX Desk

本書の位置付け

本書は、製造業のDX担当者（事業部のDX推進・経営企画・IT部門・製造本部の部長・課長クラス）を読者に想定した、データ基盤の選択論に関する実務レポートである。「データ基盤を入れましょう」という掛け声ではなく、どの技術アーキテクチャを、どんな業務と意思決定のために、どう設計し、どう組織のガバナンスとつなぐかという技術的・実務的な具体に踏み込む。

近年、製造業の現場では、DXへの投資が累積してきた。DWHを導入し、データレイクを構築し、IoTでセンサーデータを集め、生成AIを試す ―各社が次々と最新の技術を取り入れている。しかし、その投資が業務の意思決定にどれだけ届いているかという問いに対しては、答えに窮する企業が多い。「データ基盤は入れたが、PoCで止まり、本番運用に至らない」「データはあるが、現場の意思決定に使えていない」「全社統一DWHを構築したが、各部門の業務に馴染まない」 ―これらは多くの製造業に共通する症状である。

本書が一貫して主張するのは、データ基盤の選択論の成否は「最新の技術スタック（DWHかレイクハウスか等）を選ぶこと」ではなく「自社の業務と意思決定の構造に合わせて段階的に拡張できる基盤を作り、OTとITの統合と組織のガバナンスまで設計すること」で決まるという点である。技術選択は本書の核心ではない。それは「自社の業務にどう使うか」という問いに従属する手段である。重要なのは、(1) 5階層の構成要素を理解し、(2) 業務と意思決定の活用層から逆算して設計し、(3) 製造業固有のOT×IT統合に踏み込み、(4) 組織のガバナンスを技術と一体で設計することだ。

本書は経済産業省「DXレポート」「ものづくり白書」等の公開情報および一般的な実装知見に基づく。記載する技術選択肢は2026年時点のもので、急速に進化する領域のため定期的な再評価を推奨する。

1 なぜいまデータ基盤の選択論か DX投資は累積するが、業務との接続が課題に 2 データ基盤の5階層収集・蓄藏・処理・カタログ・活用 3 技術スタックの主要選択肢クラウドDWH・レイクハウス・データメッシュの対比 4 「データ基盤を入れただけ」の罠 PoC止まり・データ沼化・業務未接続・統治の組織問題 5 製造業固有の論点 ―OTとITの統合技術の壁・組織の壁・セキュリティの壁 6 データ基盤の3類型全社統一型・ドメイン型・ハイブリッド型 7 導入ロードマップと落とし穴

ユースケース選定から始める順序、定着のコツ、つまずき

エグゼクティブ・サマリー

5つのキーメッセージデータ基盤の選択論の成否は、最新の技術スタックを選ぶことではなく、業務との接続と組織のガバナンスを設計することで決まる。本書の要点を5つにまとめる。

1 DX投資は累積するが、業務との接続が問われる時代に入った多くの製造業がDWH、データレイク、IoT基盤、生成AIへの投資を進めてきた。しかし、そうした基盤投資が「PoCで止まり本番運用に至らない」「データはあるが意思決定に使えない」という症状を生んでいる。経済産業省「DXレポート」も、IT予算の80%が既存維持に使われている現状を指摘する。基盤を入れただけでは業務は変わらない。業務との接続を最初から設計する時代に入った。

2 データ基盤は「5階層」で捉える。下から積むが、上の活用層から逆算する収集（センサー・ERP等から実績を集める）→蓄藏（DWH・データレイク・レイクハウス）→処理（ELT/ETL・dbt）→カタログ・ガバナンス（メタデータ・品質・権限）→活用（BI・AI/ML・業務システム）。この5階層を構成要素として理解する。実装は下から積み上げるが、設計は上の活用層 ―どんな業務でどんな意思決定をするか ―から逆算するのが本質的に正しい順序である。

3 主要選択肢は3つ。クラウドDWH・レイクハウス・データメッシュ。優劣でなく適合性で選ぶクラウドDWH（Snowflake、BigQuery等）はSQL中心の構造化分析に強い。レイクハウス（Databricks、Microsoft Fabric等）は構造化と非構造化を統合しAI/MLにも対応する。データメッシュは技術というより組織パターンで、ドメイン別の分散管理を可能にする。「どれが優れているか」ではなく「自社の業務とデータと組織にどれが合うか」で選ぶ。一つに統一せずハイブリッドにする選択肢もある。

4 製造業特有の最大の難所は、OT（運用技術）とIT（情報技術）の統合 OT（センサー・PLC・MES・現場制御）は高信頼性とリアルタイム性が必須で「止めないこと」が最優先。IT（ERP・SCM・CRM等）は柔軟性と変化対応が重視される。両者の統合には、技術の壁（プロトコル違い）、組織の壁（製造本部とIT部門が別、文化も予算も別）、セキュリティの壁（OTへのサイバー攻撃リスク）がある。データ基盤設計の最大の難所は技術論よりこの組織と文化の問題にある。

5 大手製造業はハイブリッド型に収斂しつつある。段階的拡張が現実解全社統一型（一つのDWHに集約）は統制が強いが規模拡大で破綻も多い。ドメイン型（事業部別管理）は柔軟だが統制が難しい。両者の中間を取るハイブリッド型（共通基盤＋ドメイン別運用）が、大手製造業の主流アプローチになっている。導入は「ユースケースを絞る→基盤設計→ガバナンス整備→段階的拡張」の4段階で、一斉ではなく積み上げで進める。

01 なぜいまデータ基盤の選択

論か DX投資は累積するが、業務との接続が課題に

K E Y F I N D I N G S

製造業のDX投資はDWH、データレイク、IoT、生成AIと累積しているしかし、PoCで止まり本番運用に至らない、業務の意思決定に使えないという症状が多い経済産業省「DXレポート」は、IT予算の80%がレガシー維持に消える「2025年の崖」を警告してきた「基盤を入れる」から「業務と接続する」「組織のガバナンスを設計する」へと論点がシフトしている

1.1 DX投資の累積と業務接続のギャップ

過去数年、日本の製造業はDXへの投資を加速させてきた。クラウドDWHやデータレイクの導入、IoTセンサー基盤の構築、生成AI・分析ツールの試験導入 ―各社が次々と最新の技術を取り入れている。経営層は「DXに投資している」という認識を持つ。

出所：経済産業省「DXレポート」および taiziii Research による考察しかし、現場の実感はそれと食い違うことが多い。「データ基盤は入れたが、PoCで止まり、本番運用に至らない」「データはあるが、現場の意思決定に使えていない」「ダッシュボードは作ったが、見るだけで終わる」 ―これらは多くの製造業に共通する症状である。経済産業省「DXレポート」「ものづくり白書」は、こうした課題を早くから指摘してきた。IT予算の80%がレガシーシステムの維持・運用（ラン・ザ・ビジネス）に充てられ、新規価値創造に回らない現実。「2025年の崖」と呼ばれた状況は、いまも各企業の課題として残る。

1.2 業務テーマの「土台」としての位置付け

データ基盤は、製造業DXにおける個別業務テーマ ―需要予測、設計資産活用、OEE、予知保全、歩留まり改善、外観検査AI、サプライチェーン可視化、調達・在庫最適化、製造原価リアルタイム化など ―のすべてに共通する「土台」である。各業務テーマは独立して取り組めるが、いずれもデータ基盤の上に成り立つ。基盤が崩れれば、業務テーマもすべて崩れる。

逆に言えば、データ基盤を業務テーマと切り離して論じる意味は薄い。各業務でどう使うか ―どんなデータを、どんな粒度で、どんなスピードで、どこに届けるか ―を起点に基盤を設計するべきである。本書ではこの思想に沿って、「技術選択論」よりも「業務と組織との接続論」を中核に据える。

1.3 論点の中心は「技術」から「組織と接続」へ

データ基盤の議論はかつて、「どの製品（DWH／データレイク／レイクハウス）を選ぶか」という技術論が中心だった。しかしいまや、技術選択肢は十分に成熟し、機能差は縮まりつつある。代わりに前面に出てきたのが、業務とのつなぎ方、データのガバナンス、組織の責任の所在、そして製造業特有のOT （運用技術）とIT（情報技術）の統合といった、「技術より一段上の設計」の論点である。本書はこの論点を扱う。

ただし、論点は技術より一段上（組織）だけにあるのではない。もう一つ、技術より一段下にも決定的な論点がある。現場の業務とデータ構造そのものを、正確に写し取れるかだ。どんな製品を選ぶかの手前で、自社のデータが実際どう生まれ、どう流れているかを描けなければ、基盤は立ち上がらない。本書は、この「一段上」と「一段下」の両方を扱う。

本書の立場：基盤を入れるだけでは業務は変わらない技術選択の良し悪しはもちろん重要だ。しかし、それだけでは業務の意思決定は変わらない。業務との接続をどう設計し、組織のガバナンスをどう整え、現場と経営が同じデータを見られる体制をどう作るか。本書はこれらすべてを射程に入れる。データ基盤は技術投資であると同時に、業務改革と組織改革への投資である。

そして忘れてはならないのが一段下の前提だ。現場のデータの流れ（後述するDFD）を写し取れなければ、組織をどれだけ整えても、基盤はデータの実態と噛み合わないまま立ち上がらない。

02 データ基盤の5階層

収集・蓄藏・処理・カタログ・活用

K E Y F I N D I N G S

データ基盤は5階層 ―収集・蓄藏・処理・カタログ/ガバナンス・活用 ―で捉えると論点が整理される上位ほど業務に近い。下位ほど技術インフラとしての性格が強い実装は下から積み上げるが、設計は上の活用層から逆算するのが正しい 5階層のうち一つでも欠けると基盤は機能しない。階層別に責任者を置くのが現実的

2.1 5階層モデルで構成要素を整理する

「データ基盤」と一言で言っても、その中身は多層的である。本書ではこれを5階層に分解して扱う。それぞれの階層は独立した役割を持ち、別の技術・別の責任者で運用される。これを混在させたまま議論するから、設計判断が定まらない。

出所：データ基盤アーキテクチャの一般的な整理に基づき taiziii Research 作成

2.2 各階層の役割

① 収集は、すべての起点となる階層である。製造業の場合、データの出所は多岐にわたる ―センサー、 PLC、MES、ERP、SCM、CRM、販売管理、購買管理、品質管理、設計CAD。これらの実績データを発生時点で取り込む仕組みが要る。製造業の特殊性として、後述するOT系（センサー・PLC・MES）とIT系（ERP・SCM・CRM）が別系統で発展してきたため、ここの統合が最大の難所になる（第5章）。

もう一つ、収集段階で見落とされがちな落とし穴がある。用語そのものが、社内で共有されていないことだ。密度の濃い現場ほど、用語は内部で独自に進化し、外部の共通語から離れていく。同じ「ワーク」「ロット」という言葉でも、部署によって指す範囲が違う。この状態でマスターを統合しようとすると、同じ名前の別物、別の名前の同一物が混ざり、データの意味が合わなくなる。技術で解く前に、まず言葉を揃える作業が要る。

② 蓄藏は、集めたデータを置く場所である。クラウドDWH（Snowflake、BigQuery等）、データレイク、レイクハウス（Databricks、Microsoft Fabric等）が代表的選択肢。「どこにどう置くか」の選択は第3章で詳しく扱う。

③ 処理・変換は、蓄藏されたデータを使える形に整える階層。ELT／ETLツール（dbt、Fivetran等）、 DWH内部の処理機能、データ前処理が含まれる。データクレンジング、マスター統合（MDM）、フォーマット変換などを行う。

④ カタログ・ガバナンスは、本書が特に重視する階層である。「どんなデータがどこにあるか」を探せること、「そのデータが信頼できるか」を担保すること。データカタログ（Collibra、Alationなど）、メタデータ管理、データ品質、アクセス権限、データオーナーシップが含まれる。この階層が欠けると、データレイクは「データ沼」と化す（誰も使えないデータの集積所）。後述する4つの罠の中核にこの問題がある（第4章）。

⑤ 活用は、業務の意思決定にデータを使う階層。BIツール（Tableau、Power BI、Looker等）、AI/MLモデル、業務システムへの組み込み、生成AIの活用が含まれる。本書の中心テーマである「業務との接続」が問われるのはこの階層である。

2.3 設計は上の活用層から逆算する

5階層を理解した上で、最も重要な原則がある。実装は下（収集）から積み上げるが、設計は上（活用）から逆算するのが正しい順序である。

多くの企業が陥る罠は、「とにかくデータを集めよう」「DWHを入れよう」と下から積み上げることに終始する点である。だがその場合、何のためにこのデータを集めたのか、どう使うのかが曖昧なまま、データだけが膨大に溜まる。そして第4章で論じる「PoC止まり」「データ沼」「業務未接続」が発生する。

逆に、「どんな業務で、どんな意思決定をしたいか」を最初に定義し、そこから必要なデータと階層を逆算すると、無駄な投資が減り、業務とのつながりが最初から組み込まれる。本書のロードマップ（第7 章）も、ユースケース選定（活用層から）を起点にしている。

2.4 逆算の、さらに手前 ―「データフロー図」が描けるか

ただし、この「活用層から逆算する」にも、さらに手前の前提がある。現場のデータが実際にどう流れているかを、正確に写し取れるかだ。そして、そのために要るのは、多くの企業が持っている業務フロー図（誰が何をするかの線）ではない。データフロー図（DFD） ―どのデータがどこで生まれ、どう形を変え、どこへ流れるか ―である。

ある精密加工の現場で、一枚の図面データがたどる道を追うと、こうなっていた。CADデータ → NCプログラム → Accessの管理データ → 機械への制御信号。データは形を変えながら、複数のシステムと複数

の機械の間を、一方向ではなく多方向に行き来する。業務フロー図をいくら綺麗に描いても、この変換と多方向の流れは見えない。だからDB設計が止まる。実際、工程を管理するテーブルに「面ID」という外部キーが要ると気づくまで、テーブル構造の作り直しだけで数年がかりになった。ツールが足りなかったのではない。現場のデータの流れが言語化されていなかったからだ。

ここが本章のいちばんの勘所である。どのDWHやレイクハウスを選ぶかの前に、このDFDを自社で写し取れるかどうかで、基盤の成否はすでに決まっている。製品を乗り換えても、データの流れが言語化されていなければ、同じ場所で止まる。

03 技術スタックの主要選

択肢クラウドDWH・レイクハウス・データメッシュの対比

K E Y F I N D I N G S

蓄藏・処理階層の主要選択肢は、クラウドDWH／レイクハウス／データメッシュの3つに整理できるクラウドDWHはSQL中心の構造化分析に強く、シンプル・ガバナンス容易レイクハウスは構造化と非構造化を統合し、AI/MLにも対応、ただし運用負荷が大きいデータメッシュは技術ではなく組織パターン。ドメイン別の分散管理を可能にする

3.1 3つの主要選択肢

蓄藏・処理階層（第2章の②③）の主要選択肢は、現在3つに整理できる。クラウドDWH、レイクハウス、データメッシュである。それぞれ思想と得意領域が異なり、優劣で比較するより「自社の業務とデータ・組織にどれが合うか」で選ぶ。

出所：各製品の公開情報および業界一般の比較に基づき taiziii Research 作成

3.2 クラウドDWH ―成熟した構造化分析の中心

クラウドDWH（Snowflake、BigQuery、Redshift等）は、SQL中心の構造化データ分析を得意とする。

データのスキーマを事前に決めて整理し、SQLで分析する伝統的なアプローチを、クラウドのスケーラビ

リティと組み合わせたもの。シンプルで、ガバナンスが効きやすく、BIツール（Tableau、Power BI 等）との連携も成熟している。中小〜中堅製造業や、データの大半が構造化されている企業には最適である。

弱みは、画像・音声・PDF・センサーログ等の半構造・非構造データに弱いこと。これらを扱おうとすると、データレイクとの併用が必要になる。AI/ML用途への対応も伝統的には弱かったが、近年は各製品が機能を拡張している。

3.3 レイクハウス ―構造化と非構造化を統合

レイクハウス（Databricks、Microsoft Fabric等）は、データレイクとDWHの二重構造を一つに統合した新しいアーキテクチャ。構造化データ（売上、生産実績等）と非構造化データ（センサーログ、画像、ドキュメント等）を一つの基盤で扱い、SQL分析もAI/MLも両方できる。AI/ML用途や、IoTセンサーデータと業務データを統合したい場合に強みを発揮する。

弱みは、構成要素が多く運用負荷が大きいこと。SQLだけでなくPython等のコードベース作業も日常的に行う組織でないと、活用しきれない可能性がある。「DWHを入れるだけ」より高い習熟が要る。

3.4 データメッシュ ―組織パターンとしての分散管理

データメッシュは技術ではなく組織パターンである。ここを誤解すると話が噛み合わない。中央集権的な単一のDWH／レイクハウスにすべてのデータを集めるのではなく、事業部・領域（ドメイン）ごとにデータを管理し、ドメイン間で連携する分散型のアプローチである。実装には任意のDWH／レイクハウス製品とデータカタログを組み合わせて使う。

強みは、組織のスケールに対応できること。大企業で、事業部が複数あり、各事業部が独自のデータ要件を持つ場合、中央集権では破綻する。データメッシュなら各ドメインが自律的にデータ管理を進められる。弱みは、統制の難易度が高いこと。ドメインを横断する標準化やガバナンス設計に高度な組織設計が要る。

3.5 「どれが優れているか」より「どれが自社に合うか」

技術比較記事を読むと「Snowflake vs Databricks」のような対立構図で語られがちだが、実務的には排他的に選ぶ必要はない。多くの大手製造業はクラウドDWHとレイクハウスをハイブリッドで使い、その上にデータメッシュ的なドメイン管理を組み合わせている。技術選択は手段であり、「自社の業務と組織の構造に何が合うか」を起点に判断するのが本筋である。

そして、製品比較よりもっと手前に、意思決定を止める厄介な要因がある。発注者自身の思い込みだ。

比較表より手前で ―「一枚の表で全部管理できる」という思い込みある製造現場では、発注者（経営層）が「一枚の横持ちテーブルで全部管理できる」と確信していた。

長年、Excelやシンプルな台帳1枚で回してきた成功体験が背景にある。だが現場の実態は、工具と機械、工具と治具、工程と加工面が、すべて多対多で絡み合う構造だった。横持ち1枚には収まらず、リレーショナルな設計と中間テーブルがなければ、そもそも動かない。

これは個社の能力の問題ではない。過去の成功が、新しい問題領域での意思決定を縛るという、製造現場に一般的な構造の問題である。やっかいなのは、データ構造を可視化しようとすると発注者の"自分の解"と衝突し、「そんな図を描いても変わらない」と土台からズレてしまうことだ。だから丁寧に説明しても噛み合わない。どの製品を選ぶかの前に、この土台のズレを越えられるか ―比較表のどこにも、その答えは書かれていない。

ベンダー比較表は意思決定に役立たない製品ベンダーやアナリストが出すベンダー比較表（機能チェックリスト）は、判断材料として過大評価されがちである。機能の有無や性能ベンチマークの差は、自社の業務要件に対して本当に意味があるかどうか分からない。むしろ「責任分界をどう置くか」「運用チームの習熟度」「既存システムとの統合性」「コスト構造の長期予見性」のほうが、選定の決め手になることが多い。

04 「データ基盤を入れただ

け」の罠 PoC止まり・データ沼化・業務未接続・統治の組織問題

K E Y F I N D I N G S

データ基盤を入れただけでは業務は変わらない。4つの典型的な罠がある PoC止まり：本番運用に上がらず形骸化するデータ沼化：ガバナンス不在で誰も使えないデータの集積になる業務未接続：BIで眺めるだけで意思決定が変わらない／統治の組織問題：データオーナー不在

4.1 4つの典型的な罠

製造業のデータ基盤プロジェクトで繰り返し見られる失敗パターンを整理すると、4つの典型的な罠に集約される。これらは技術選択の良し悪しを超えた、より構造的な問題である。

出所：データ基盤プロジェクトの一般的な失敗パターンに基づき taiziii Research 作成

4.2 ① PoC止まり ―本番運用に上がらない

最も多いのがPoC止まりである。データ基盤を導入し、ある業務領域で概念実証（PoC）を行い、技術的に動くことを確認する。しかし、そこから本番運用への展開が進まない。半年経っても、PoCで作ったダッシュボードや分析モデルが現場で使われない、あるいは導入チームが解散すると共に消えていく。

原因は、PoCの設計時点で業務との接続が組み込まれていないことにある。「技術的に可能か」だけを検証し、「現場の誰が、どの業務で、どんな判断に使うか」が決まっていない。処方箋は、PoCの段階から業務側のオーナーを立て、本番展開の道筋を最初から設計することである。

4.3 ② データ沼化 ―ガバナンス不在で使えないデータの集積

データ沼（Data Swamp）とは、データレイクが適切なガバナンスなしで運用された結果、誰も使えないデータの集積所と化した状態を指す。データは入っているが、どこに何があるか分からず、データの意味（カラムが何を表すか）も誰が責任者か分からない。検索しても出てこない、出てきても信頼できない。

処方箋は、第2章で論じたカタログ・ガバナンス階層を最初から仕組み化すること。データカタログツール（Collibra、Alation等）の導入、メタデータの強制入力ルール、データオーナーシップの設定。これらは技術というより運用ルールの問題が大きい。

ただし先回りしておくと、カタログ製品を入れれば沼が埋まる、というものでもない。根はもっと手前にある。データがどこで生まれ、どう変換され、現場で何を指すか（第2章のDFDと用語）が言語化されていないかぎり、カタログの入力欄は埋まらないか、埋まっても信頼できない。製品より先に、この言語化に手をつける必要がある。

4.4 ③ 業務未接続 ―BIで眺めるだけで意思決定変わらず

ダッシュボードは構築されたが、業務の意思決定が変わらない、というケースも多い。経営層や現場リーダーがダッシュボードを「見る」ことはあっても、その数字から具体的な行動に結びつかない。見える化が目的化し、見えた先のアクションが設計されていない。

処方箋は、活用層から逆算した設計に立ち返ること。「この数字がこうなったら、誰が、どんなアクションを取るか」を業務プロセスとして埋め込む。差異分析のアラート、自動発注、再学習トリガー等、データから自動的にアクションが起動する仕組みを組み込む。これは原価リアルタイム化や予知保全と同じ思想である。

ただし、ダッシュボードや自動化で埋め込めるのは「何をするか（What to do）」までだ。同じ数字を見て「これは動くべきか、様子見か」というどう判断するか（How to decide）は、ルールに落ちきらず、ベテランの中に残る。基盤の外に残るこの判断こそ、最後の論点になる（第7章）。

4.5 ④ 統治の組織問題 ―データオーナー不在、責任が曖昧

最も深く、最も解決が難しいのが組織問題である。データガバナンスは技術ではなく組織の問題だ。「このデータの正しさを担保するのは誰か」「データに誤りがあった場合、誰が修正の責任を持つか」「データ定義の変更を誰が承認するか」 ―こうした責任の所在が曖昧なまま運用すると、データの品質は劣化していく。

製造業では特に、データの発生源（OT系、製造現場）と利用者（IT系、経営企画）が別部門であることが多く、両者の間でデータ品質の責任が宙に浮きがちである。処方箋はデータオーナーシップを組織として正式に定義すること。マスターデータマネジメント（MDM）の体制を構築し、データオーナー、データスチュワード、データ利用者の役割を明確化する。これは次章で扱うOT×IT統合の論点とも深くつながる。

05 製造業固有の論点 ―OTとITの

統合技術の壁・組織の壁・セキュリティの壁

K E Y F I N D I N G S

製造業のデータ基盤設計の最大の難所は、OT（運用技術）とIT（情報技術）の統合である OTは高信頼性・リアルタイム性が必須で「止めないこと」が最優先、IT は柔軟性と変化対応を重視両者の統合には、技術の壁・組織の壁・セキュリティの壁の3つがある技術論より組織と文化の問題が大きい。経営レベルでの体制設計が要る

5.1 OTとITは別の世界として発展してきた

製造業のデータ基盤を語る上で避けられないのがOT（運用技術、Operational Technology）とIT（情報技術、Information Technology）の統合という論点である。これは他業界にはあまり無い、製造業特有の固有問題である。

出所：製造業の組織構造とOT/IT分断の一般的な整理に基づき taiziii Research 作成 OTとは、製造現場で機器・プロセスを直接制御する技術を指す。センサー、PLC（プログラマブル・ロジック・コントローラ）、SCADA、MES（製造実行システム）、現場制御システムなど。「止めないこと」が最優先で、高信頼性とリアルタイム性が必須。多くの場合、製造本部・各工場の生産技術部門が所管する。

ITとは、企業の情報処理を支える技術。ERP（基幹システム）、SCM、CRM、財務会計、人事システム等。柔軟性と変化対応が重視され、ビジネス要件の変化に合わせてシステムを更新する。本社のIT部門・情報システム部門が所管する。

5.2 3つの壁

OTとITを統合してデータ基盤に取り込もうとすると、3つの壁にぶつかる。

技術の壁：OT系の機器は古い独自プロトコル（OPC UA、Modbus、各社独自）で通信しており、IT系（HTTPS、REST API等）と直接つながらない。間に変換装置（ゲートウェイ）が要る。さらに、OT系は高頻度・高信頼性のリアルタイム通信が要件で、IT系の柔軟さとはアーキテクチャ要件が違う。

組織の壁：これが最大の難所である。OT系は製造本部・現場が所管し、IT系は本社のIT部門が所管している。両者は文化も、人材も、評価基準も、予算の出し方も違う。OT系は「現場の安定運転」が最優先で、IT部門が「データを集めたい」と言っても、現場は「下手に触らないでくれ」と感じることが多い。

逆にIT部門から見ると、OT系は技術的に古く感じられ、現場の保守的な文化が「DXの障害」に見える。

両者の橋渡しは、技術ではなく組織設計の問題である。

セキュリティの壁：OT系がインターネットにつながると、サイバー攻撃のリスクが急増する。製造現場が攻撃を受ければ、生産停止だけでなく、人命や設備に関わる事故にも直結する。実際、Tier1サプライヤーへのサイバー攻撃を起点にOTが侵害され、自動車OEMの全工場停止に至った事案も近年起きている。OT×IT統合は、セキュリティ設計と一体で進める必要がある。

5.3 統合を進める組織設計

3つの壁の中で、技術の壁とセキュリティの壁は、相応の投資と専門家を投じれば解ける。本当に難しいのは組織の壁である。

多くの大手製造業がこの組織の壁に対処するため、DX推進室や経営直轄の横断組織を作っている。製造本部とIT部門の上に立ち、両者を橋渡しする部隊である。ダイキンの「オールコネクテッド戦略」、パナソニックの「PX（Panasonic Transformation）」のような大規模なグループ横断プロジェクトは、まさにこの組織設計の典型例である。経営主導で推進することが大企業DXの大前提であり、データ基盤の選択と統合は、この経営判断の一部として位置付けられる必要がある。

技術導入の前に、組織と文化への投資が要る OT×IT統合は、「データ基盤を選ぶ」より遥かに難しい問題である。技術導入の前に、製造本部とIT部門の橋渡しをする組織を作り、両者の文化の違いを認め、共通の言語と目標を共有する努力が要る。データ基盤プロジェクトの初期に「経営直下の推進体制」「OT/IT両方の出身者をメンバーに置く」といった組織設計を済ませておくと、後の技術的議論が格段に進めやすくなる。

06 データ基盤の3類型

全社統一型・ドメイン型・ハイブリッド型

K E Y F I N D I N G S

製造業のデータ基盤は、全社統一型・ドメイン型・ハイブリッド型の3類型で整理できる全社統一型は統制が強いが、規模拡大で破綻するケースも多い。中小〜中堅向きドメイン型は柔軟だが、統制の難易度が高い。大企業・事業多角化している企業向き大手製造業はハイブリッド型に収斂しつつある。共通基盤＋ドメイン別運用が現実解

6.1 3つの類型

製造業のデータ基盤を実装パターンで整理すると、3つの類型が見えてくる。全社統一型、ドメイン型、ハイブリッド型である。どの類型が「最良」というわけではなく、自社の規模、組織構造、事業構成によって適合性が異なる。

出所：データ基盤アーキテクチャパターンの一般的な整理に基づき taiziii Research 作成

6.2 全社統一型 ―一つのDWHに集約

全社統一型（Centralized）は、全社のデータを一つのDWHに集約するパターン。データの形式、定義、運用ルールが全社で標準化され、ガバナンスが効きやすい。中央のデータチームが一元的に管理する。

強みは統制と標準化。中央でデータ品質を担保しやすく、ガバナンスも一元化できる。中小〜中堅の製造業や、データ量がそれほど多くない企業には最適である。ダイキンの「工場IoTプラットフォーム」も、

ある程度この発想に近い構造を持つ ―製造現場のすべての設備をネットワークでつなぎ、データを一元化する設計である。

弱みは柔軟性の低さ。事業部や領域ごとに異なる要件があると、中央の標準が制約になり、業務側のスピード感が出ない。さらに、規模拡大に伴いデータ量・利用者・ユースケースが爆発的に増えると、中央チームがボトルネックになり、運用が破綻するケースも多い。

6.3 ドメイン型 ―事業部・領域ごとに管理

ドメイン型（Domain-Oriented）は、事業部・領域（ドメイン）ごとにデータを管理するパターン。各ドメインがデータの所有権・運用責任を持ち、独自に基盤を構築・運用する。先述のデータメッシュの組織パターンに近い発想である。

強みは柔軟性と自律性。各ドメインが自社のスピードで意思決定でき、ドメイン固有の要件にも対応できる。大企業で事業が多角化している場合、特に有効である。弱みは統制の難易度。ドメインを横断したデータ品質の標準化、メタデータ管理、セキュリティ統制が難しい。「各ドメインで似たような分析を別々に開発する」といった重複も発生しやすい。

6.4 ハイブリッド型 ―共通基盤＋ドメイン別運用

ハイブリッド型（Hybrid）は、両者の中間を取るパターン。基盤（蓄藏層・カタログ層）は共通化し、運用は各ドメインに委ねる。トヨタの「工場IoT」（部署間にまたがる情報共有基盤）、デンソーの「ダントツ工場」（製造現場のデータ統合と各工場の自律性の両立）、ダイキンの「オールコネクテッド戦略」（全社プロジェクト化しつつ事業領域別の運用を許す）、パナソニックの「PX」（グループ横断＋事業別）など、大手製造業の取り組みはおおむねこのハイブリッド型に分類できる。

強みはバランスと段階的拡張可能性。共通基盤で統制を効かせつつ、ドメイン別の自律性も確保できる。

中小から始めて、事業成長に応じて拡張していくこともできる。弱みは設計の難易度。「何を共通化し、何をドメインに委ねるか」の線引きが難しく、適切なバランス設計には経験と組織理解が要る。

6.5 大手製造業はハイブリッド型に収斂

大手製造業の実例を観察すると、ハイブリッド型に収斂している傾向が見える。全社統一型では事業の多様性に対応できず、ドメイン型では統制が効かない。両者の良いとこ取りができるハイブリッド型が、規模が大きく事業が複雑な製造業の現実解となっている。

ただし、自社がどの類型を選ぶかは、規模と組織構造で決まる。中小製造業で全社統一型から始めるのは合理的だし、創業期のスタートアップがいきなりハイブリッドを構築する必要もない。「事業の成長段階に応じて類型を進化させる」視点で考えるべきである。最初から完璧な基盤を作ろうとせず、段階的に拡張する設計が、長期的には最も健全な姿になる。

07 導入ロードマップと落とし穴

ユースケース選定から始める順序、定着のコツ、つまずき

K E Y F I N D I N G S

導入は「ユースケース選定→基盤設計→ガバナンス整備→段階的拡張」の4段階で進める全社一斉に最新技術を入れるのではなく、ユースケースから逆算して段階的に拡張する定着の鍵は、データオーナーシップの組織設計とハイブリッド型への段階的進化典型的なつまずきは、技術選定先行、ガバナンス後回し、OT×IT統合の組織問題軽視、PoC固定化

7.1 4段階のロードマップ

データ基盤の導入は、最初から全社一斉ではなく、段階的に積み上げる。

出所：taiziii Research 作成 Phase 1：ユースケース選定。業務側で「データで解きたい問題」を絞り込む。需要予測、予知保全、原価リアルタイム化、Tier2-3可視化など、明確に効果が見える1〜2件のユースケースを選ぶ。第2章で論じた「活用層から逆算」を実践する段階である。Phase 2：基盤設計。5階層のアーキテクチャを設計し、 DWH/レイクハウス等の技術選択を行う。OT×IT統合の方針も決める。Phase 3：ガバナンス整備。データカタログ、データオーナーシップ、品質基準、アクセス権限を整える。技術と組織の両方を設計する。

Phase 4：段階的拡張。初期ユースケースから他領域へ横展開する。必要に応じてハイブリッド型へ進化させる。継続的に改善ループを回す。

7.2 定着のコツ ―「業務とつなぐ」を最優先する

データ基盤が定着するかどうかは、「業務とつなぐ」を最優先できるかにかかっている。技術部門の関心は「最新のアーキテクチャを採用すること」に向きがちだが、それだけでは業務は変わらない。第4章で述べた4つの罠（PoC止まり・データ沼化・業務未接続・統治の組織問題）はすべて、業務との接続が弱い結果として発生する。

定着のための実務的な打ち手をいくつか挙げる：第一に、業務側の責任者をプロジェクトに巻き込む。技術部門だけで進めると、業務との接続が後回しになる。需要予測なら営業・サプライチェーン部門、原価リアルタイム化なら経理・経営企画部門の責任者が、データ基盤プロジェクトのオーナーとして並列に立つ体制を作る。

第二に、データオーナーを正式に任命する。データの正確性、定義、変更承認を担う「データオーナー」を業務領域ごとに任命する。これは技術部門ではなく業務部門の責任者が担うのが原則。MDM（マスターデータマネジメント）の体制を整備する。

第三に、ガバナンスを後回しにしない。「まず基盤を作って、ガバナンスは後で」というアプローチは、ほぼ必ずデータ沼を生む。最初から、最小限でいいのでカタログとデータ品質ルールを設計する。

第四に、段階的拡張を許容する経営判断。「全社一斉に最新技術を入れる」という壮大なプロジェクトは、ほぼ必ず失敗する。「1ユースケースで成果を出してから次へ」というスモールスタートを、経営層が許容する文化を作る。

典型的な4つのつまずき ① 技術選定先行：「Snowflakeにすべきか、Databricksにすべきか」を業務要件より先に議論する。先に決めるべきは活用ユースケースである（第2章・第3章）。② ガバナンス後回し：基盤構築を急ぎ、データカタログ・オーナーシップ設計を後回しにする。データ沼の原因（第4章）。③ OT×IT統合の組織問題軽視：技術論ばかりで、製造本部とIT部門の組織設計を進めない。最大の難所を放置することになる（第5章）。④ PoC固定化：PoCで「動いた」ことに満足し、本番運用への展開を設計しない。投資が回収されない（第4章）。

7.3 まとめ ―業務テーマの土台として

本書を通じた主張は一貫している。データ基盤の選択論の成否は、最新の技術スタックを選ぶことではなく、(1) 業務と意思決定の活用層から逆算して設計すること、(2) 製造業特有のOT×IT統合を組織設計と一体で進めること、そして(3) ガバナンスを技術と一体で段階的に拡張することという、技術以前の3点で決まる。そして、この3つすべての前提として、(4) 現場の業務とデータの流れ（DFD）を、そもそも写し取れることがある。ここが描けなければ、上の3つは空回りする。

さらにその先、ツールもデータも標準も整えた後に、最後まで残る層がある。「なぜこの数字なら動くのか」「この兆候は放置してよいのか」という、図面にもデータにも製品スペックにも載らない判断の層だ。データ基盤は、この判断を速く確かに下すための器にすぎない。器を立派にしても、中で下される判断がベテランの頭の中にあるままなら、基盤は宝の持ち腐れになる。最後に問われるのは、この判断をどう引き出し、どう次へ継ぐかである。

需要予測、予知保全、原価管理、品質管理、サプライチェーン管理 ―製造業DXの個別業務テーマはすべて、このデータ基盤の上に成り立つ。着手にあたっては、全社一斉ではなく、最も効果が見えやすい1ユースケースでスモールスタートすることを推奨する。明日からの一歩は二つ。一つは「いま、どんな意思決定がデータ不足で滞っているか」を3つ書き出すこと。もう一つは、その滞りの裏で、どんな判断が、いま誰か一人の頭の中だけにあるかを問うてみることである。

taiziii が提供する判断力の継承サービス SkillRelay（スキルリレー）は、データ基盤を整えてもなお現場に残る「なぜこの数字なら動くのか」「この兆候は放置してよいのか」という熟練者の判断を、なぜそう判断したのかという理由ごとAIで引き出し、帰属を保ったまま構造化し、組織の判断知として継承します。判断を平均したり、一本の正解に統合したりはしません。AIは判断を代行せず、引き出し、分類し、問い返し、継承を助ける裏方に徹します。基盤という器づくりから、その中で下される判断の継承までを、ひと続きで扱える点に強みを持ちます。

詳細：https://taiziii.com/skillrelay/

SNSでシェアする