製造データとAI：製品バリューチェーンをつなぐ

製造上の欠陥が1つのシステムだけに起因することはめったにありません。廃棄（スクラップ）の急増は、マシンの設定、サプライヤーのバッチ、物流イベント、または品質システムに記録された繰り返しの問題に関連している可能性があります。しかし、原因究明に必要なデータは、通常、工場、部門、システムの境界を越えて分散しています。

50年以上前、ジョセフ・ハリントン博士が提唱したコンピュータ統合生産（CIM）のビジョンは、製造業が部門を超えた情報のつながった流れに依存していることを認識していました。今日、データとAIが製品バリューチェーンの各段階をつなぐことで、そのビジョンが現実のものとなりつつあります。

製造業における最も困難な問いは、複数の段階にまたがる問いです。

• どのサプライヤーのロットが、影響を受けた製品に届いたのか？
• この欠陥は以前にも発生したことがあるか？ 是正処置は維持されているか？
• どの顧客やサービス案件が影響を受ける可能性があるか？

これらの問いに答えるには、本来連携するように設計されていないシステム同士のデータを結合する必要があります。製造業者に必要なのは、これ以上孤立したレポートを増やすことではありません。必要なのは、情報を実用的なものにするためのガバナンスとビジネスコンテキストを備えた、製品バリューチェーン全体にわたる情報のつながった流れです。これこそが、モダンなデータ＆AIプラットフォームが果たすべき役割です。

製造業の製品バリューチェーンとは？

製品バリューチェーンとは、原材料やアイデアを製品へと変換し、顧客に届け、現場でサポートするまでの一連のエンドツーエンドの機能（プロセス）のことです。研究開発（R&D）と設計、調達、生産と品質、営業とマーケティング、そしてアフターサービスとフィールドサービスをつなぎます。各段階には、それぞれの目標、チーム、運用システムが存在します。

• 研究開発（R&D）と設計は、製品ライフサイクル管理（PLM）、コンピュータ支援設計（CAD）、コンピュータ支援エンジニアリング（CAE）とシミュレーション、テストデータ、要件、および設計部品表（BOM）を使用します。
• 調達は、企業資源計画（ERP）の購買、ソース・ツー・ペイ（調達から支払いまで）、契約、サプライヤーリスク、サプライヤーポータルを使用します。
• 生産と品質は、製造実行システム（MES）、監視制御・データ収集（SCADA）/プログラマブルロジックコントローラ（PLC）データ、プロセスヒストリアン、品質管理システム（QMS）/ラボ情報管理システム（LIMS）、および保全システムを使用します。
• 物流とサプライチェーンは、企業資源計画（ERP）、倉庫管理システム（WMS）、輸配送管理システム（TMS）、計画システム、電子データ交換（EDI）、およびテレマティクスを使用します。
• 営業とマーケティングは、顧客関係管理（CRM）、見積構成・価格設定（CPQ）、価格設定、ディーラー管理、マーケティングオートメーション、およびEコマースを使用します。
• アフターサービスとフィールドサービスは、サービス管理、保証、サービスパーツ計画、コネクテッドプロダクトデータ、診断、およびチケットを使用します。

各段階では、貴重な運用データが生成されます。より大きなチャンスは、バリューチェーンのある部分での気づきを、別の部分での行動へとつなげることから生まれます。例えば、生産現場で見つかった品質問題を物流やサプライヤーの記録から調査したり、サプライヤーからのアラートを追跡して、影響を受ける原材料が使用されたすべての製品を特定したりすることです。

システムの境界が真の問題である理由

バリューチェーンの各段階が孤立している場合、複数の段階にまたがる問いに答えるには、チケットの発行、データのエクスポート、データの照合といった手動の作業が必要になります。しかし、データがガバナンスの効いた1つのシステムとしてアクセス可能であれば、同じ問いがシンプルなクエリへと変わります。

例1：工場の品質エンジニアが3つの問いに答える必要がある場合：

1. 廃棄（スクラップ）の急増は、バッチ、マシン、またはセットアップのどれが原因なのか、そしてそれは現在も発生しているのか？
2. この欠陥は以前にも発生したことがあるか、またその際の対策は維持されているか？
3. なぜ、ある工場は別の工場よりも同じ部品をはるかに多く廃棄しているのか？

それぞれの問いは、製造実行システム（MES）の記録、プロセスヒストリアンデータ、サプライヤーおよびサプライヤー品質管理（SQM）データ、品質管理システム（QMS）の履歴、8D（Eight Disciplines）レポート、そして多くの場合、複数の工場のインスタンスなど、複数のシステムにまたがっています。現在、これら一つひとつに答えるには、チケットを発行し、手動でデータをエクスポートし、少数の専門家に頼る必要があります。

例2：調達アナリストが3つの問いに答える必要がある場合：

• 現在、納期遅延リスクありとフラグが立てられている単一のサプライヤーに依存している重要な部品はどれか？
• 最近の注文において、サプライヤーの納期遵守率や品質パフォーマンスは低下しているか？
• 1社のサプライヤーが機能しなくなった場合、どの製品、工場、未処理の注文が影響を受けるか？

それぞれの問いは、企業資源計画（ERP）の購買およびソース・ツー・ペイの記録、契約、サプライヤーリスクのフィード、サプライヤーポータルなど、複数のシステムにまたがっています。現在、これら一つひとつに答えることは、チケットの発行、専門知識、手動でのエクスポートを伴う、ちょっとしたプロジェクトになりかねません。

これらの運用データソースを統合することで、そうした摩擦が解消されます。バリューチェーンを一度統合し、一度ガバナンスを適用し、シリアル番号、ロット番号、部品番号などの共通の識別子を結合キーとして使用すれば、トレーサビリティはクエリを実行するだけで実現できます。6つの問い、1つの根本的なニーズ：本来連携するように設計されていないシステム間でデータを結合し、その結果を信頼すること。これを可能にするのが、4つのプラットフォーム機能です。

Databricksが製造データをどのようにつなぐか

業務を中断させるような移行は不要

バリューチェーンの連携において、すべてのソースシステムを一度に移行するような、業務を中断させる大規模な移行は必要ありません。適切な選択であればデータをコピーすることもできますし、元の場所に置いたままクエリを実行することもできます。

ゼロコピーの Open Sharingと Lakehouse Federationを使用すると、ユースケースごとに新たなETLパイプラインやコピーを作成することなく、ソースシステム内のデータにアクセスできます。ミラーリングが適している場合は、コネクタとクラウドオブジェクトストレージを使用して、データをレイクハウスに取り込むためのスケーラブルな経路が提供されます。

The Databricks Data and AI Platformは、この柔軟性と、製造チームが必要とする機能（生産、品質、供給データにわたる履歴分析、マシンや車両のテレメトリに対する低遅延処理、個々のレコードを迅速に読み書きできるアプリケーションなど）を統合します。

例で示された4つの機能

業務を中断させる移行なしで、ソースデータを統合またはフェデレーションする：品質エンジニアの問いは、工場インスタンス全体のMES、プロセスヒストリアン、サプライヤーおよびSQM、QMS、8Dの記録にまたがっています。調達アナリストの問いは、ERPの購買、契約、サプライヤーリスクのフィードにまたがっています。ゼロコピーのOpen SharingとLakehouse Federationを使用すれば、これらのデータを元の場所でクエリでき、コピーする方が適している場合はコネクタを介してミラーリングできます。いずれの場合も、問いごとに新しいETLコピーを作成する必要はありません。

オーケストレーションとリファインメント（洗練）：どちらの例も、未加工の抽出データではなく、ガバナンスが適用されたゴールドテーブルに対して結合を行います。Lakeflowは、未加工のインプットを、一般的にブロンズ、シルバー、ゴールドのレイヤーを通じて、信頼性の高い分析可能なデータへと変換するパイプラインの構築、スケジューリング、監視を支援します。

データとAIのガバナンス： Unity Catalogは、ミラーリングされたデータとフェデレーションされたデータ全体を管理する単一のコントロールプレーンです。1つの権限モデル、完全なリネージ、そしてデータ、モデル、AIエージェントにわたる検出を提供するため、両方の例に対して同じガバナンスが適用された環境で対応できます。Unity Gatewayを使用すると、エージェント、ツール、モデル、MCP全体にわたるAIアクセス、コスト、オブザーバビリティを制御できます。

自律型（エージェント）機能：このガバナンスが適用された基盤の上に構築されたGenie Oneは、データに接続するAIの同僚です。Agent Bricksは、エンタープライズデータに基づいたAIエージェントの構築を支援し、Genie App Builderを使用すれば、誰でも自然言語でエージェントやアプリケーションを作成できます。エンジニアやアナリストは、日常の言葉で質問し、ビジネスで認識されている定義に基づいた回答を得ることができます。これについては、次の2つのセクションで詳しく説明します。

実用的な設計原則はシンプルです。価値を生み出す場所でデータを統合し、コピーが合理的でない場所ではフェデレーションを行い、その両方を同じコントロールプレーンで管理することです。その結果、分析やAIのユースケースごとに新しいサイロを作成することなく、製造データの種類や段階を越えて作業できるようになります。

データリテラシーの向上 – 専門家以外にもデータを役立つものにする

プラットフォームの価値は、それを活用できる人々によって決まります。多くの製造企業では、工場固有のシステムを理解しているのは少数の専門家グループのみであり、ビジネスユーザーはレポートやエクスポートを待つしかありません。

データリテラシーは、関連データの検索、信頼できる定義の理解、分析、自然言語での質問、ガバナンスの効いたエージェントやアプリケーションの構築、そしてそれらのアセットの他者との共有という、実践的なプロセスを進むことで向上します。誰もがデータエンジニアになる必要はありません。この成長は、以下に示す6つのステップに沿って進みます。

テクノロジーは変化の一部にすぎません。トレーニング、実践コミュニティ、およびチャンピオンネットワークが、各部門が自信を持ち、再利用可能なパターンを共有できるよう支援します。共通のガバナンスが効いたデータ基盤は、共有された定義、共通の語彙、チーム間で再利用できる回答など、これらのコミュニティが具体的に取り組むための土台を提供します。

製造業における「データとの対話（Talk to Data）」の仕組み（および、なぜガバナンスの効いたセマンティクスが必要なのか）

データリテラシーを向上させる最も簡単な方法は、人々がデータと対話できるようにすることです。クエリ言語を学ぶ必要も、チケットを発行する必要も、レポートを待つ必要もありません。自然言語による分析はデータへの障壁を下げることができますが、会話型インターフェースだけでは不十分です。回答は、ビジネスが認識している定義に基づいている必要があります。

例：購買

「現在、配送リスクのフラグが立っている単一のサプライヤーに依存している重要な部品はどれか？」といった質問には、SAP固有のテーブルヘッダー、結合、ビジネスルールの知識が必要になる場合があります。購買アナリストがこれを調査するために、データ専門家になる必要はありません。

Purchasing Genieデモは、このパターンを具体化したものです。この実行可能なプロジェクトは、ガバナンスの効いたデータの準備、専門家エージェントの構築、そしてそれらをスーパーバイザーのもとで構成して1つのガバナンスの効いたアプリとして共有するという3つのステップに従います。

このパターンは、データの準備やガバナンスといった技術的な専門知識を必要とする作業と、質問、回答の確認、アクションの実行といったビジネスユーザーが自身で行えるべき作業を分離します。

例：KPIレポート

同じパターンが日常のレポート作成にも適用されます。KPI定義がガバナンスの効いたセマンティックレイヤーに存在する場合、BIツールとAIの両方が同じビジネスロジックに基づいて動作します。Genieエージェントは、それらの信頼できる定義を使用して部門内の質問に回答し、Agent Bricksはそれらを部門横断で機能するペルソナベースのエージェントに構成します。その結果、複雑なスキーマやバラバラのレポートから推測されるのではなく、ビジネスが認識している定義に基づいた、同じ質問に対して常に同じ回答が得られます。

メルセデス・ベンツ韓国（Mercedes-Benz Korea）は、このパターンを実際に適用しています。詳細はこちらをご覧ください。

実践的な進むべき道

50年以上前、ジョセフ・ハリントン博士（Dr. Joseph Harrington）が提唱したコンピュータ統合生産（Computer Integrated Manufacturing）のビジョンは、製造業を情報の流れによって統合された1つのまとまりのあるシステムとして描写しました。そのビジョンが、今や大規模に実現可能となっています。

導入のレシピには3つのステップがあります。

1. ミラーリングされたデータソースとフェデレーションされたデータソースの両方をカバーする、単一のコントロールプレーンとしてのUnity Catalogを使用して、データを一度プールし、一度にガバナンスを適用します。
2. バリューチェーンの一方のセクションでの発見が他方のセクションでのアクションを促し、クエリとしてエンドツーエンドのトレーサビリティを実現できるように、シリアル番号、ロット番号、または部品番号などの共有識別子を結合キーにします。どの識別子が適しているかはドメインによって異なります。一部のドメインではシリアル化されたユニットやVIN、プロセス製造ではロット番号やバッチ番号などです。
3. ガバナンスの効いたビジネスセマンティクスに自然言語アクセスを基づかせることで、人々がデータと対話できるようにします。

ビジネスユーザーが平易な言葉で質問し、信頼できる回答を受け取ることができるようになると、データリテラシーは一部の専門家だけの特権ではなくなり、組織全体の能力になります。その成果は、単なるもう一つのダッシュボードではありません。バリューチェーン全体の何千人もの人々が、信頼できるデータを見つけ、理解し、それに基づいて行動できるようになることです。

よくある質問（FAQ）

バリューチェーン全体で製造データを接続することの最大のメリットは何ですか？

バリューチェーン全体で製造データを接続することの最大のメリットは、ある段階で発生し、別の段階でのアクションを必要とする質問に回答できることです。製造上の欠陥を物流経由で追跡して原因となったサプライヤーのバッチを特定したり、疑わしいサプライヤーのロットを追跡してそれが届いたすべての製品を特定したりできます。データが接続されていなければ、これらの調査にはそれぞれ数日間の手作業が必要になります。接続されたレイクハウスがあれば、同じ質問がシンプルなクエリになります。

製造業者はすべてのソースデータをDatabricksに移行する必要がありますか？

製造業者がすべてのソースデータをDatabricksに移行する必要はありません。必要に応じてデータをコピーすることもできますが、ゼロコピーのOpen SharingとLakehouse Federationを使用すれば、データをソースシステムに残したまま、その場でクエリを実行できます。Unity Catalogは、フェデレーションされたデータとミラーリングされたデータの両方にガバナンスを適用できます。

トレーサビリティとは何ですか？

トレーサビリティとは、製造プロセスのステップ、製品、資材、および操業記録をリンクさせることで、チームが影響を受けた製品から遡って追跡（バックワードトレース）したり、疑わしい資材から追跡（フォワードトレース）したりできるようにすることです。これにより、迅速な問題解決や、より正確なリコール分析がサポートされます。一例として、製造された製品のシリアル番号やロット番号を追跡することが挙げられます。

LTAPとは何ですか？なぜ製造業者にそれが必要なのですか？

LTAPとは、Lake Transactional/Analytical Processing（レイク・トランザクショナル／アナリティカル・プロセッシング）の略です。これは、ガバナンスの効いた1つのプラットフォーム上で分析ワークロードとトランザクションワークロードを実行することを指します。製造業では、履歴データの大規模な分析と、操業記録の読み書きを行う応答性の高いアプリケーションの両方が必要です。歴史的に、これらはデータがコピーされる2つの別々のスタックに分かれて存在していましたが、LTAPはガバナンスの効いた1つのデータコピー上で両方を実行します。

プラットフォームの機能以外で、データリテラシーを向上させるものは何ですか？

機能だけでは十分ではありません。トレーニング、実践コミュニティ、および各部門のチャンピオンが、人々が自信を持ち、パターンを共有し、共通のガバナンスが効いたデータ基盤を使用できるよう支援します。プラットフォームは基盤を提供し、活発なコミュニティがそれを幅広い能力へと変えていきます。

「データとの対話（Talk to Data）」はどのようにして信頼性を確保するのですか？

自然言語によるアクセスは、文書化されたメジャー、ディメンション、結合、定義など、ガバナンスの効いたビジネスセマンティクスに基づいている必要があります。これにより、Genieは複雑なスキーマやバラバラのレポートから意味を推測するのではなく、同じ信頼できるコンテキストを使用して質問に回答できます。

Lakehouse Federationとは何ですか？

Lakehouse Federationは、データをソースシステムに残したまま、Databricksを通じてクエリを実行できるようにするDatabricksの機能です。これにより、追加のETLパイプラインやデータのコピーを作成する必要がなくなります。ソースデータは、ミラーリングされたデータとともにUnity Catalogを通じて管理され、データが物理的にどこにあるかに関係なく、統合されたガバナンスレイヤーを提供します。

製造データにおけるUnity Catalogとは何ですか？

Unity Catalogは、データ、モデル、およびAIエージェントのためのDatabricksの統合ガバナンスレイヤーです。データ環境全体にわたって、単一の権限モデル、完全なデータリネージ、および検出機能を提供します。製造業においては、データがレイクハウスにあるか、ソースシステムからフェデレーションされているかに関係なく、生産データ、品質記録、サプライヤーデータ、およびAIエージェントを管理する単一のコントロールプレーンを意味します。

このプラットフォームは、大量のマシンや車両のテレメトリを処理できますか？

はい。このプラットフォームはバッチ処理とストリーミング処理を組み合わせています。大量のマシンや車両のテレメトリを、非常に低遅延の継続的なストリームとして取り込み、高い信頼性で処理できるため、途中でイベントがドロップすることはありません。

データはどのようにしてDatabricksに取り込まれますか？

インジェスト（取り込み）は簡単にできるように設計されています。Zerobus Ingestはガバナンスの効いたテーブルへのプッシュ型ストリーミングを直接サポートし、Lakeflow Connectはビジネスシステム向けのマネージドコネクタと変更データキャプチャ（CDC）を提供し、Auto LoaderとStructured Streamingがファイルとイベントを処理します。

このプラットフォームはオープンでマルチクラウドに対応していますか？

はい。Deltaテーブルはクラウドオブジェクトストレージに保存され、ストレージとコンピューティングは独立してスケーリングします。DatabricksはAWS、Azure、Google Cloud上で動作し、データはDelta LakeやIcebergなどのオープンフォーマットで保存されます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事