文脈がなければ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 Web Services

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

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

しかし、そのデータからは、機械が正しい製品を製造しているか、適切なプロセスパラメータに従っているか、あるいはその特定の作業における性能の期待値を満たしているかといったことは分かりません。データは、その資産自体に限定されたものだからです。

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

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

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

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

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

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

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

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

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

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

ここでは、単なる機械の修理にとどまらない判断が求められます。チームは、より広範な影響を把握し、特定の部署内だけでなく、部門をまたいで行動することができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「結局のところ、人間が関与する形で、意図的かつ計画的な設計がなされなければなりません」— ZS プリンシパル、スラージ・パイ

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

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

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

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