文脈がなければAIは機能しない理由：製造データ活用準備ガイド

メーカー各社はAIに多額の投資を行っているが、多くの取り組みは初期のパイロット段階を過ぎると停滞してしまう。モデルは洞察を生み出し、ダッシュボードは活気づくものの、チームは行動を起こすのをためらってしまう。現場や制御室では、AIによる出力結果が実際の業務運営と乖離していると感じられることが少なくない。

「Operations Callingでは、ZSとAWSのリーダーたちが一堂に会し、製造業がAI導入に向けてデータをどのように大規模に整備しているかについて議論しました。製造戦略、クラウドアーキテクチャ、現場の運用といった多角的な視点から検討した結果、ある共通の傾向が浮かび上がりました。それは、AIが機能しない原因はモデルの性能不足にあるのではなく、ITシステムとOTシステムの間で基盤となるデータに共通の運用コンテキストが欠如している場合に、システムが機能不全に陥るということです。

このブログでは、なぜ「コンテキスト」が製造AIにとって欠けていた前提条件なのかを解説します。また、組織が生のシグナルやサイロ化されたシステムから、スケーラブルで「ヒューマン・イン・ザ・ループ」型の意思決定支援を支えるAI対応アーキテクチャへと移行するための、実践的なデータ準備ガイドラインを提示します。

製造業では、すでに機械、システム、アプリケーションの至る所にデータが存在しています。課題は、そこから意味を抽出することです。文脈こそが、データが何を表しているのか、そしてなぜそれが特定の意思決定において重要なのかを説明するものです。

「AIの性能は、そのデータの質次第ですよね？ しかも、データだけではありません。データそのものを超えた、データの文脈が重要になるのです。文脈こそがすべてなのですから」— スラージ・パイ（ZS プリンシパル）

機械が稼働していることを把握することと、その機械がどのプロセスを、どの製品のために、どのような条件下で実行すべきかを把握することは別物です。資産、プロセス、製品との関連性がなければ、AIシステムは異常の兆候を検知することはできても、具体的な対応策を提案することは困難です。

コンテキストは、役割や問いかけによっても異なります。オペレーター、品質管理責任者、サプライチェーンプランナーにとって重要な点は、たとえ同じ基礎データを見ている場合でも異なります。だからこそ、コンテキストは推測したり固定化したりすることはできず、設計する必要があるのです。

最後に、文脈は機械だけで生成されるものではありません。専門家たちは、システムではカバーしきれない重要な部分を、依然として人間の判断が補っていることを強調しました。AIを実際の業務で機能させるためには、システムデータと人間の判断の両方を考慮に入れる必要があります。

製造データの活用準備とは、運用データが定義され、構造化され、連携されている状態を指し、これによりITシステムとOTシステムの双方で確実に活用できるようになることを意味します。

具体的には、以下の条件を満たした時点でデータは準備完了となります：

• 資産、プロセス、および製品は明確に定義されている。

• それらの間の関係がモデル化されている。

• 命名規則は標準化されています。

• データがシステム間を移動する際も、コンテキストはデータに紐付けられたままになります。

これにより、業務、品質管理、エンジニアリング、あるいはエンタープライズシステムなど、どこに表示されても、同じデータが同じ事象を表すことが保証されます。

ISA-95やUnified Namespaceといった標準規格は、構造的な出発点を提供します。こうした基盤が整っていれば、新しい分析やAIのユースケースにおいて、プロジェクトごとにコンテキストを再構築するのではなく、共有モデルを基盤として構築することができます。また、新しいユーザーがデータを利用するたびに、その都度手動で説明を加える必要がなくなります。コンテキストはすでに組み込まれているからです。

データが準備でき次第、新しいダッシュボードや分析ツール、AIツールはすぐにそれを活用できます。しかし、データが準備できていない場合、チームはデータの真の意味を理解するためにほとんどの時間を費やすことになります。

コンテキストは一度にすべて現れるわけではありません。それは層を成して形成されていくものであり、多くのメーカーは同時に複数の層で事業を展開しています。重要なのは、現在どこにコンテキストが存在しているのかを理解し、過剰な設計を避けつつ前進するために何が必要なのかを見極めることです。

「適切なデータがなければ、これらのエージェントはうまく機能せず、正しい情報を提供することも、より良い意思決定を行うこともできません」— ヴェンカット・グマタム、パートナー・ソリューション・アーキテクト、Amazon Services

ステージ1：資産レベルのコンテキスト
この段階では、データは個々の機械、生産ライン、またはセンサーに紐付けられています。

機器の状態（稼働中、停止中、または故障中）や、サイクルタイム、温度、生産数などの基本的な指標を確認できます。これらのデータから、その時点での資産の状況が把握できます。

しかし、そのデータからは、機械が適切な製品を生産しているか、正しい工程パラメータに従っているか、あるいはその特定の作業における性能要件を満たしているかといったことは分かりません。データは当該資産自体に限定されているからです。

ITとOTの統合は、たいていここから始まります。つまり、機械を接続し、信号を収集することです。これにより可視性は得られますが、運用上の意味を完全に把握できるわけではありません。

ステージ2：プロセスのコンテキスト
この段階では、データはマシンが実行しているプロセスステップに関連付けられます。

現在実行中の操作、ワークフローの段階、およびそのステップで定義された設定値や制限値を確認できます。パフォーマンスデータはもはや単なる機械の信号ではなく、プロセスが本来どのように動作すべきかという基準に基づいて評価されるようになりました。

これで、その操作が想定された範囲内で行われたかどうかがわかりました。

まだ完全には把握できていないのは、このパフォーマンスが特定の製品、注文、またはロットにどのような影響を与えるかという点です。このデータはプロセスの挙動を反映していますが、製品への影響の全容までは示していません。

ここで、疑問は「何が起きたのか？」から「期待通りに動作したか？」へと移る。

ステージ3：製品およびバッチのコンテキスト
この段階では、データが特定の製品、レシピ、またはバッチに関連付けられます。生産実績、逸脱、品質結果などを、その時点で生産されていた製品に遡って追跡することが可能になります。

これにより、プロセスの挙動が機械単体だけでなく、特定の注文やロットにどのような影響を与えるかを把握することが可能になります。これは、同一の設備で要件の異なるさまざまな製品を生産する、規制の厳しい環境や多品種生産環境において特に重要です。

ステージ4：部門横断的なコンテキスト
この段階では、現場のデータが品質管理、エンジニアリング、サプライチェーンの各システムと連携します。機械で発生した問題は、不良品、遅延、手直し、出荷遅延といった影響と関連付けることができます。

データはもはや、単に各ラインの稼働状況を示すだけのものではありません。データは、運用上の問題がビジネスにどのような影響を与えるかを明らかにしてくれます。

ここで、意思決定は単なる機械の修理という枠を超えます。チームは、より広範な影響を把握し、特定の部署内にとどまらず、部門をまたいで行動することができるようになります。

ステージ5：人的要素
高度な環境であっても、依然として人はプロセスの一環です。オペレーターはメモを記録し、シフト交代時に問題点を説明し、例外事態に対処し、計画通りに進まない場合には判断を下します。

システムはすべてを捉えられるわけではありません。何が起きたかだけでなく、なぜ起きたのかを説明できるのは、多くの場合、人間の知見です。優れたデータアーキテクチャでは、こうした知見を無視すべきものではなく、貴重な運用データとして扱います。

「すべての製造現場において、あらゆる側面がデジタル化されるわけではありません。依然として、データや製造プロセスの要素を収集する人間が現場に存在しています」— ZS プリンシパル、スラージ・パイ

AIの導入準備は、データが意味を失うことなくこれらの層を円滑に通過できるかどうかにかかっています。必要な背景情報が整う前にAIを導入しようとすると、問題が生じます。

AIの故障を防ぐには、まず意図的なデータ設計から始める必要があります。その目的は、完璧なモデルを作ることではなく、実用的なモデルを作ることにあります。

まずは定義の統一から始めましょう。資産、プロセス手順、製品、主要なエンティティを明確に定義し、システム間で一貫性を保ちます。運用、品質管理、およびエンタープライズツールにおいて、同じ用語が同じ意味を持つよう、共通の命名規則を採用します。

次に、重要な関係性をモデル化します。機械のイベントをプロセスステップに紐付け、プロセスステップを製品やバッチに結びつけます。また、運用上のイベントを品質管理システムやサプライチェーンシステムと連携させます。あらゆる想定されるシナリオではなく、優先度の高いユースケースに必要な関係性にのみ焦点を当ててください。

ISA-95やISA-88といった規格は、青写真としてではなく、指針として活用してください。これらの規格が提供する構造的な明快さを参考にしつつ、自社の業務の実態に合わせて適宜調整してください。

最後に、将来的な拡張を見据えた設計を心がけましょう。オントロジーを活用すれば、新しい製品、ワークフロー、またはサイトが追加された際にも拡張可能な形で、エンティティや関係を定義することができます。これにより、データを構造化しつつも、厳格な階層構造に縛られることなく柔軟性を保つことができます。

メーカーがこのアプローチを採用すれば、AIシステムはデータが境界を越えるたびにそのデータを再解釈する必要がなくなります。新しいユースケースは、並列モデルを構築するのではなく、共有された基盤の上に構築されます。こうしてコンテキストが拡張され、複雑さが増してもAIは機能し続けるのです。

製造業におけるAIの第一波の多くは、ダッシュボード、予測、推奨機能を通じたインサイトの創出に重点が置かれていました。しかし、エージェント型AIはこうした期待を一変させます。これらのシステムは単にデータを分析するだけでなく、自ら行動を起こし、ワークフローを起動させ、システム間で意思決定を調整することができます。

「今後、私たちは『アイアンマン』のような世界へと突入しようとしています。そこでは、私たちがシステムと対話し、システムもまた私たちと対話するようになるでしょう」— ヴェンカット・グマタム、Amazon Services パートナー・ソリューション・アーキテクト

こうした変化により、データ整備のハードルはさらに高まります。AIが「提案」から「実行」へと移行するにつれ、文脈の不備がリスクへと変わります。エージェントは、何が起きたかだけでなく、どこで起きたのか、なぜ重要なのか、どのような制約があるのかも理解する必要があります。こうした基盤がなければ、自動化は信頼性の高いものではなく、脆弱なものになってしまいます。

だからこそ、「ヒューマン・イン・ザ・ループ」設計が不可欠なのです。エージェント型システムは、人間が意思決定を検証し、例外処理を行い、データが不完全な場合に判断を下すことで、その真価を発揮します。これらのシステムは、オペレーターやエンジニアに取って代わるのではなく、状況を可視化し、意思決定を迅速化し、責任の所在を人間に留めることで、彼らを補完するように設計されています。

「結局のところ、人間が関与する、意図的で計画的な設計が必要不可欠です」— ZS プリンシパル、スラージ・パイ

ITおよびOTのリーダーにとって、エージェント型AIへの備えとは、単にエージェントをいち早く導入することではありません。それは、システムと人間の協働を最初から前提とした運用モデルとデータ基盤を設計することに他なりません。適切な文脈が整っていれば、エージェント型AIは業務の実用的な延長線上に位置づけられます。それがなければ、どれほど高度なモデルであっても、信頼を得るのは困難です。

Tulip 、業務が実際に遂行される現場の状況を把握することで、製造データの活用準備をTulip 。Frontline Operations として、Tulip 人的入力、機械データ、プロセスワークフローを単一の環境にTulip 、データが作成される時点で業務上の意味付けを組み込むことを可能にし、後からの再構築を不要にします。

Tulip 、現場のプロセスをデジタル化することで、資産、運用、製品の表現方法を標準化すると同時に、各現場の現実に柔軟に対応できるTulip 。エンジニアは、画一的でトップダウン型のモデルを強いることなく、広範なITおよびOTアーキテクチャと整合するワークフロー、データ収集方法、命名規則を定義することができます。

このように文脈に応じたデータは、エンタープライズシステム、分析プラットフォーム、クラウドサービスへと連携され、部門や拠点を超えて一貫した構造を必要とするAIのユースケースを支えます。その結果、実際の業務に根ざし、時間の経過とともに適応可能で、現場での実行と企業全体の意思決定の両方を支援するように設計された、「ヒューマン・イン・ザ・ループ」型AIのための拡張性の高い基盤が構築されます。