ETO Manufacturing Customer Value OS v7.0 を支える技術スタック全解説 ─ なぜその技術を選んだのか、どう繋がるのか

この記事の読み方

前回の記事「顧客価値最大化統合DXオペレーティングシステム v7.0 ─ 完全論証」では、なぜこのフレームワークが設定前提において絶対最適かを論証した。

本稿はその技術的裏側だ。「理念はわかった。で、実際に何のシステムを使うのか、どう繋げるのか」という問いに答える。

各技術について以下の観点で解説する：

何をするシステムか（機能の本質）
なぜこの製品を選んだか（選定理由・競合比較）
どのモジュールに対応するか（フレームワークとの接続）
実装の急所（見落としがちな重要ポイント）

技術スタック全体マップ

┌─────────────────────────────────────────────────────────────────┐
│                    顧客・経営層への価値提示                          │
│          TCOダッシュボード / 顧客ポータル / 提案書生成                │
└─────────────────────────┬───────────────────────────────────────┘
                           │ Power BI / Tableau / Web UI
┌─────────────────────────▼───────────────────────────────────────┐
│                   アプリケーション層                                 │
│  PLM: Teamcenter 14 │ ERP: SAP S/4HANA │ MES: Opcenter           │
│  APS: Asprova       │ QMS: Veeva eQMS  │ FSM: Field Service Mgmt │
└──────┬──────────────┬──────────────────┬──────────────────────────┘
       │              │                  │
┌──────▼──────────────▼──────────────────▼──────────────────────────┐
│                    統合層（Integration Layer）                      │
│  API Gateway: Kong │ Event Bus: Kafka │ iPaaS: MuleSoft           │
└──────┬──────────────────────────────────────────────────────────┘
       │
┌──────▼──────────────────────────────────────────────────────────┐
│                   プラットフォーム層                                 │
│  Cloud: Azure（主）+ AWS（DR）│ Edge: Kubernetes + Jetson Orin    │
│  Data: Snowflake + Delta Lake  │ ML: MLflow + Azure ML           │
└──────┬──────────────────────────────────────────────────────────┘
       │ OPC UA / MQTT / HTTPS
┌──────▼──────────────────────────────────────────────────────────┐
│                   製造現場・フィールド層                              │
│  工作機械（CNC/PLC）│ 組立ライン │ 試運転設備 │ 出荷後納入機          │
│  センサー群 │ クレーンIoT │ AR（HoloLens 2）│ UWB測位システム        │
└─────────────────────────────────────────────────────────────────┘

         ▲ セキュリティ（IEC 62443 / Entra ID / Claroty）が全層を横断 ▲
         ▲ MDM / デジタルスレッド（UUID）が全層を貫通                  ▲

第一層：製造現場・フィールド層の技術

OPC UA ─ 工場内データ収集の神経系

何をするシステムか： OPC UA（OPC Unified Architecture）は、工作機械・PLC・センサーからデータを収集するための業界標準プロトコルだ。特定のメーカーや機器に依存しない「共通の言語」として機能する。

なぜ選んだか： 製造現場には数十年前から稼働し続けている設備が混在する。シーメンス、ファナック、三菱、マキノ、各社のCNCが同一フロアに存在する。各機器には独自の通信プロトコルがある。これを全て個別対応するとドライバの維持管理が爆発する。

OPC UAはISO 16526規格として国際標準化されており、主要な機器メーカー全てがOPC UAコンバーターを提供している。「OPC UA対応」であれば、設備メーカーを問わず同一のAPIでデータを取得できる。

v7.0では特にOPC UA Companion Specification（Machinery + Compressor）を採用する。これは産業機械・圧縮機分野に特化した拡張仕様で、「振動の値」「回転数」「吐出圧」といった機器固有のデータポイントの命名規則が標準化されている。これにより、異なるメーカーの機器から取得したデータを、同一の構造で処理できる。

実装の急所： OPC UA通信にはセキュリティ設定が必須だ。Basic256Sha256（推奨暗号化）+ X.509証明書（年次更新）の設定なしで稼働させているシステムを、国内のETO型工場でも多く見かける。これはIEC 62443準拠の観点で完全に非準拠だ。証明書の期限切れを検知する監視設定を最初から組み込むこと。

Asset Administration Shell（AAS）─ 設備の「デジタル住民票」

何をするシステムか： AAS（Asset Administration Shell）は、物理的な設備（Asset）に紐付いた標準化されたデジタルデータ管理の仕組みだ。設備の仕様、稼働データ、保全履歴、カーボンフットプリントを、標準化されたサブモデル構造で保持する。

v7.0では4サブモデルを定義している：

Nameplate（設備の基本情報：製番・型式・製造年月）
TechnicalData（仕様値：定格出力・設計圧力・材質）
Documentation（図面・取説・保全手順書）
CarbonFootprint（製造時CO₂・稼働時CO₂算定）

なぜ選んだか： Industrie 4.0（ドイツ政府主導の製造業デジタル化イニシアチブ）が標準化した仕組みであり、欧州の主要顧客（シーメンス、ABB等）がAAS対応を調達要件に含め始めている。ETO型の特注機器は、出荷後数十年にわたって顧客工場で稼働する。その期間中、設備のデジタルデータが標準形式で参照できることは、保全・アップグレード・廃棄計画において重要な価値を持つ。

実装の急所： CarbonFootprint サブモデルへの対応が遅れているケースが多い。しかし欧州のCBAM（炭素国境調整メカニズム）が2026年以降に本格運用されると、製品ごとのCO₂データ提出が義務化される。今から構造を作っておかないと後手に回る。

Jetson Orin + Azure IoT Edge ─ 工場エッジの判断脳

何をするシステムか： NVIDIAのJetson Orinは、工場内のエッジコンピューターとして機能するAIアクセラレーター内蔵のコンピュートモジュールだ。Azure IoT Edgeは、クラウドのAIモデルをエッジデバイスに展開・管理するフレームワークだ。

なぜ選んだか： ETO型製造業の現場には、通信品質が安定しない環境が存在する。大型試運転設備のある工場棟では、高周波機器による電磁ノイズでWi-Fiが不安定になることがある。クラウド接続が前提のエッジシステムは、通信断の瞬間に全機能が停止する。

Jetson Orin + Azure IoT Edgeの組み合わせは「オフライン3日間単独稼働、クラウド復旧後に自動同期」を実現する。これは単なる「バックアップ機能」ではなく、工場の基本設計として「クラウドなしでも製造を続けられる」という自律性だ。

推論速度の仕様（<50ms）は、安全用途（クレーン衝突回避、機械異常検知）に使用するため要求される値だ。人間の反応速度（150〜300ms）より高速に判断を下し、自動停止指令を出せる。

実装の急所： OTAアップデート（Over The Air：遠隔からのソフトウェア更新）の設計を最初から組み込むこと。工場内に100台のエッジノードが分散している状況で、物理的にアクセスしてアップデートすることは現実的でない。しかしOTAが適切に設計されていないと、アップデート中のノードが本番稼働中の機器を誤停止させるリスクがある。ロールバック機能付きの段階的展開（カナリアリリース）が必須だ。

UWB測位システム ─ 工場内の「GPS」

何をするシステムか： UWB（Ultra-Wideband）は、広帯域無線通信を使った高精度屋内測位技術だ。製番が付いた重量物・工具・治具・作業者の位置を、工場内で±30cmの精度でリアルタイム追跡する。

なぜ選んだか： 一品一様のETO型工場では、製造中の大型構成品がどこにあるかの把握が難しい。「あの部品どこ行った」という事象が日常的に発生し、探索時間が積み重なる。また、重量物の工場内移動経路の最適化なしに、クレーン稼働率の向上は困難だ。

GPSは屋内では使えない。Wi-Fiベースの測位は精度が1〜3mで製造現場には不十分。Bluetooth BLEは障害物に弱い。UWBは金属構造物の多い工場環境でも±30cmの精度を維持できる唯一の実用技術だ。

v7.0では「重要物100%追跡」と定義している。「重要物」の定義は工場ごとに異なるが、一般的に「紛失・損傷した場合に案件の納期・品質に直接影響する物品」だ。

実装の急所： UWBアンカー（基地局）の配置設計が最大の難所だ。工場内の鉄骨構造・天井クレーン・大型設備がUWB信号を遮蔽する。アンカー配置は専門家による電波シミュレーションが必要で、「とりあえず均等に配置する」設計は精度の大幅な劣化を招く。

HoloLens 2 ─ 工場現場の「神の手」

何をするシステムか： Microsoft HoloLens 2は、現実空間に3D映像（ホログラム）を重ね合わせて表示する複合現実（MR）デバイスだ。作業者はヘルメットを被るように装着し、両手を自由にした状態で作業しながら、手順書・寸法・警告を視野内に表示できる。

なぜ選んだか： ETO型の保全・組立作業では、「片手に手順書、片手に工具」という状況が常態化している。この時、手順書を確認するために作業を止める。再開する。また止める。この反復が作業時間を増加させ、集中力の分断が誤組立を引き起こす。

HoloLens 2はハンズフリー・音声操作で手順を進められる。「次へ」と言えば次の手順が表示される。作業者の手の位置を認識し「このボルトを締めろ」と3D矢印で指示できる。トルク値はリアルタイムでBluetoothトルクレンチから取得し、正常範囲内なら緑、逸脱なら赤で表示する。

v7.0で「誤組立 -70%」という目標値は、先行導入事例のベンチマークから設定している。

実装の急所： コンテンツ制作コストの過小評価が最大の失敗パターンだ。「HoloLens 2を買えばすぐ使える」は誤りで、3D手順コンテンツの制作が必要だ。v7.0では「CADから自動変換・更新SLA 24h」と定義している。これはCADデータ（NXモデル）から半自動でAR手順コンテンツを生成するパイプラインを意味する。このパイプラインを最初に構築しないと、コンテンツ更新が手作業になり、設計変更が発生するたびに数日遅延が生じる。

第二層：プラットフォーム層の技術

Snowflake + Azure Data Lake Gen2 + Delta Lake ─ データの「図書館」

何をするシステムか： 三つは役割が違う。

Azure Data Lake Gen2：生の製造データを大量に格納する「倉庫」。IoTセンサーデータ・ログ・CSV等、形式を問わず全て受け入れる
Delta Lake：倉庫内のデータに「バージョン管理」を加える仕組み。「昨日の段階ではどの値だったか」を遡れる。データ品質管理（ACID準拠）
Snowflake：整理されたデータを高速にクエリする「閲覧室」。BI（Power BI・Tableau）や分析ツールが参照する

なぜ3層構造か： v7.0では「Bronze（生データ）/ Silver（クレンジング済み）/ Gold（分析用）」の3層を明示している。この分離には明確な理由がある。

IoTセンサーデータは1秒に何千件も流れ込む。このデータには異常値・欠損・重複が混在する。これをそのまま分析用DBに入れると、AIモデルの学習精度が落ち、ダッシュボードが誤った数値を表示する。3層に分けることで「生データは全部保持（Bronze）、使える状態に整理（Silver）、分析に最適化（Gold）」という責務の分離が実現する。

試運転データの「10年保持」という要件は、Delta Lakeの圧縮機能（≥90%圧縮率）なしには現実的なストレージコストにならない。

実装の急所： データカタログ（何のデータがどこにあるか）を最初に構築しないと、3層構造が「データの迷宮」になる。v7.0の「データ辞書200用語」は、このカタログの核心だ。「このカラムの”稼働率”は製造部定義か保全部定義か」が辞書なしには判断できない。

MLflow + Azure Machine Learning ─ AI の「品質管理システム」

何をするシステムか： MLflow はAIモデルのライフサイクル管理ツールだ。「どのデータで」「どのパラメータで」「何の精度が出たモデルを」「いつ本番に出したか」を全て記録する。Azure Machine Learning はそのクラウド実行環境だ。

なぜ必要か、なぜ軽視されがちか： 「AIモデルを作る」と「AIモデルを安全に運用する」は全く違う技術領域だ。多くのDXプロジェクトでAIが「使われなくなる」理由は、モデルの精度が時間とともに劣化することへの対処ができないからだ。

この問題をモデルドリフトと呼ぶ。製造条件が変わる、季節が変わる、設備が老化する。AIモデルは過去データで学習しているため、現実が変化すると予測精度が落ちる。これを検知する仕組みがなければ「精度が落ちていることに気付かない」状態が続く。

v7.0では二種類のドリフト検知を定義している：

データドリフト（PSI > 0.2で警告、> 0.25で再訓練）：入力データの分布が変化した
コンセプトドリフト（CUSUM法、5σ逸脱でレビュー）：入力と出力の関係が変化した

PSI（Population Stability Index）は統計的な分布の変化を測る指標で、信用スコアリング業界が長年使ってきた実績ある方法だ。

AUC ≥ 0.85というゲート条件の意味： 本番環境にモデルを昇格させる前に、評価指標AUC（Area Under the Curve）が0.85以上であることを確認する。0.5はランダムと同等、1.0は完全予測。0.85は「十分に実用的」の閾値として製造業AIで広く採用されている水準だ。この条件を設けないと、精度不十分なモデルが本番に出てしまい、「AIが使えない」という現場の不信感を醸成する。

実装の急所： シャドーデプロイ（2週間）を必ず設けること。新しいモデルを本番データで並列稼働させ、旧モデルの判断と比較した上で切り替える。これなしに切り替えると、現場が気付かないうちに判断ロジックが変わり、原因不明のトラブルが発生する。

第三層：アプリケーション層の技術

Teamcenter 14 ─ 設計情報の「司令塔」

何をするシステムか： Teamcenter（シーメンス製）はPLM（Product Lifecycle Management）システムの代表格だ。設計図面・3Dモデル・BOM（部品表）・ECN（設計変更通知）・プロジェクト管理を一元管理する。

なぜTeamcenterがETO型に適しているか： PLM市場の主要製品は他にPTC Windchill、Dassault Enovia、Oracle Agile PLMがある。ETO型製造業でTeamcenterが優位な理由を具体的に説明する。

まずNXとの統合深度だ。NX（シーメンス製CADソフト）とTeamcenterはネイティブ統合であり、3DモデルをNXで設計した瞬間にTeamcenter上でバージョン管理が開始される。他社CADとの連携では「保存のたびに手動コミット」という手順が必要で、設計者の作業負荷が増える。

次にSAP PLMとの連携実績だ。v7.0ではTeamcenter → SAP S/4HANAの設計情報連携（BOM同期・ECN連動）が要件だが、SAP PLMモジュールとTeamcenterの統合は業界標準として確立されている。

EBOMとMBOMの分離管理： v7.0では「as-designed（設計通り）/ as-built（実際に作った）/ as-maintained（保全後の現状）」の3系統のBOMを管理する。

EBOM（Engineering BOM）：設計部門が管理。設計意図通りの構成
MBOM（Manufacturing BOM）：製造部門が管理。実際に製造するための工程別構成
SBOM（Service BOM）：保全部門が管理。アフターサービスに必要な交換可能部品の構成

一品一様のETO型では、設計通りに作れない場合の「偏差管理」が頻繁に発生する。「部品Aが手配困難で部品Bで代替した」という情報がas-builtに記録され、将来の保全時に「設計はAだが実際にはBが付いている」という情報として活用される。

実装の急所： 設計確定度レベル（Lv0〜Lv4）の概念をTeamcenter上でどう実装するかが最初の難関だ。Teamcenterの標準機能にはLvの概念がないため、カスタムワークフロー（BPMエンジン）を使った実装が必要になる。この設計を最初の6ヶ月で完成させないと、後続の「Lv到達時の自動BOM展開」が全てブロックされる。

SAP S/4HANA ─ 経営の「循環器系」

何をするシステムか： SAP S/4HANAは世界最大のERPシステムだ。購買・在庫・製造指示・財務会計・原価計算を一元管理する。

RISE with SAPの選択理由： v7.0ではSAP S/4HANAを「RISE with SAP（Public Cloud）」で採用する。これはSAPが管理するクラウド環境での運用だ。

オンプレミスSAPとの最大の違いはメンテナンス負荷だ。オンプレミスでは、SAPのバージョンアップを自社IT部門が管理する。カスタマイズが多いほどバージョンアップのテスト工数が膨大になり、結果として「10年前のバージョンを使い続けている」という状況が起きる。旧バージョンはAI機能への対応が遅れ、DXの足を引っ張る。

RISE with SAPでは、バージョン管理はSAPが行い、カスタマイズを「標準機能＋拡張アドオン」の形に制約することでバージョンアップの負荷を下げる。

設計確定度マネジメントとの接続： Lv1〜Lv3の各ステージで、SAP上の購買オーダーに「確定度フラグ」が付与される。Lv4（正式出図）に到達した時、フラグが解除されてMRPが正式実行される。この「条件付きMRP実行」の実装がv7.0のモジュール[2]の技術的核心だ。

実装の急所： SAP標準の「プロジェクト系モジュール（PS: Project System）」と「一品生産系モジュール（PP-PI）」のどちらを使うかの選択が最重要だ。ETO型には両方の特性があるが、混在させると原価集計ロジックが複雑になる。導入初年度にここを誤ると、後から修正するために全モジュールを再設計することになる。

Opcenter（旧Camstar）─ 製造指示の「神経系」

何をするシステムか： Siemens OpCenterはMES（Manufacturing Execution System）だ。SAP S/4HANAからの製造指示を受けて、「いつ、どの設備で、誰が、どの手順で、何を作るか」を現場レベルで管理・記録する。

ISA-95 L3の意味： v7.0では「ISA-95 L3」という規格への準拠を明示している。ISA-95はERP（L4）とMES（L3）と現場制御系（L2/L1/L0）の役割分担を定義した国際標準だ。

L4: ERP（SAP S/4HANA）── 経営・計画層
L3: MES（Opcenter）── 製造実行層  ← ここ
L2: SCADA          ── 監視制御層
L1: PLC            ── 制御層
L0: センサー         ── 物理層

この役割分担を守らないと「ERPが直接PLCに指令を出す」「MESが財務データを持つ」という設計上の混乱が生じる。各層の責務を明確にすることで、システムの保守性と拡張性が保たれる。

SPCとOEEの自動集計： Opcenterには品質管理モジュール（SPC管理図）と生産性管理モジュール（OEE自動集計）が内包されている。これを別システムで構築した場合と比較すると、MESとのデータ連携コストがゼロになる。製造実績データがそのまま品質・生産性分析に使われる。

実装の急所： ETO型では「標準工順が存在しない」案件を処理するためのフレキシブルルーティング機能の設定が難しい。量産型設定（固定工順）でOpCenterを実装すると、一品一様案件で毎回手動工順作成が発生し、導入メリットが消える。「ルート生成AIとの連携」か「類似案件ベースのルートコピー機能」のどちらかを最初に設計すること。

Asprova ─ ETO型スケジューリングの「チェスの名人」

何をするシステムか： AsprovAはAPS（Advanced Planning and Scheduling）システムだ。工場内の全設備・人員・材料の制約条件を考慮しながら、最短納期・最大稼働率・最低コストを目的関数として、製造スケジュールを自動生成・最適化する。

なぜ一品一様にAPSが難しいか： スケジューリングの難しさは組み合わせの数に依存する。10工程×10案件の場合、理論上は10!（362万通り）のスケジュールが存在する。その中から最適解を探索するのがAPSだ。

ETO型では、各案件の工程数が異なり、設備の使用可否が案件固有の仕様に依存し、設計確定度によって着手可能工程が変わる。この動的制約をリアルタイムに処理できるAPSが必要だ。

Asprovは国産APSとして、日本のETO型製造業（特に重電・産業機械分野）での導入実績が豊富だ。SAP PP・MES・PLMとのコネクタが整備されており、「四者統合（PLM/ERP/MES/APS）」の要件を実績ベースで満たせる。

設計確定度との連携： Lv2（詳細設計進行中）では、確定した工程のみAsprovに登録し、未確定工程は「TBD（To Be Determined）枠」として保持する。Lv4（正式出図）到達で全工程が確定し、Asprovが本番スケジュールを一斉生成する。この「部分的スケジュール確定→全体最適化」の流れがv7.0のモジュール[2]×[7-1-4]の接続点だ。

実装の急所： 「最適化<10分」という性能要件は、対象設備と案件数の規模設定が適切である必要がある。全工場の全設備・全案件を一つのモデルに入れると計算時間が数時間になる可能性がある。「クリティカルパスに関わる設備群のみを最適化対象とし、非クリティカルはルールベースで計画する」というスコープ設計が現実的だ。

第四層：統合層の技術

Kong API Gateway ─ システム間通信の「関所」

何をするシステムか： API GatewayはAPIへの全てのリクエストを一元的に受け付け、認証・認可・レート制限・ロギングを行う。企業内の全システムが直接互いに通信するのではなく、全てAPI Gatewayを経由する。

なぜKongか： Kongはオープンソースベースの商用製品で、他の主要Gateway（AWS API Gateway、Azure API Management、MuleSoft API Manager）と比較して「マルチクラウド・オンプレミス混在環境での一元管理」に強い。ETO型工場ではAzure・AWS・オンプレミスが混在するため、特定クラウドベンダーのGatewayでは対応しにくい。

v7.0では「OAuth 2.0認証・Rate limit 1,000req/min・Developer Portal」を定義している。Developer Portalは「どのAPIが存在するか」を社内外の開発者に公開するカタログだ。これなしにAPIを横展開しようとすると「そのAPIどこにある？どう使う？」という問い合わせが止まらなくなる。

実装の急所： 全API呼び出しの日次監査ログを最初から設定すること。「誰がいつどのAPIを呼んだか」は、セキュリティインシデント発生時の必須情報だ。後から追加しようとすると、パフォーマンス影響とストレージ設計の変更が発生する。

Apache Kafka ─ データの「高速道路」

何をするシステムか： Kafkaは高スループットの分散メッセージングシステムだ。工場内で発生する大量のイベント（センサー値、アラーム、ステータス変化、トランザクション完了）をリアルタイムで配信する。

なぜKafkaが必要か： ETO型工場で「設計確定度がLv2に上がった」というイベントが発生した時、複数のシステムに同時通知が必要だ：

ERPに「長納期材料の先行手配候補リストを生成せよ」
APSに「先行着手可能工程のスケジュール計算を開始せよ」
担当者のスマートフォンに「Lv2到達の通知を送れ」
ダッシュボードに「案件ステータスを更新せよ」

これを全て直接API呼び出しで実装すると、各システムが互いに依存するスパゲッティ構造になる。Kafkaを介在させると、「イベントを発行する側（PLM）」と「イベントを受け取って処理する側（ERP・APS・通知サービス・ダッシュボード）」が疎結合になる。新しいシステムを追加しても、既存システムの変更なしに「このイベントを聞く」設定を追加するだけで対応できる。

3-AZ冗長の意味： v7.0では「Kafka 3-AZ（Availability Zone）冗長」を定義している。クラウドの1つのデータセンターが障害になっても、残り2つで継続稼働できる構成だ。製造中の案件データが流れるメッセージバスが停止することは、工場全体の情報フローが止まることを意味する。

実装の急所： Schema Registryを最初から導入すること。Kafkaのメッセージは自由な形式で送れる反面、メッセージの構造（スキーマ）を管理しないと「あのシステムが送るメッセージの形式が変わったら、受け取り側が全て壊れた」という事態が起きる。Schema Registryは「このトピックのメッセージはこの形式でなければ受け付けない」という契約として機能する。

MuleSoft ─ 既存システムを繋ぐ「翻訳者」

何をするシステムか： MuleSoftは「API-led Connectivity」という考え方でシステム統合を行うiPaaSプラットフォームだ。KafkaがイベントドリブンのリアルタイムデータフローならMuleSoftは「Aシステムから取得したデータをBシステムの形式に変換してCシステムに送る」というオーケストレーション役だ。

API-led 3層アーキテクチャ： v7.0では「System API / Process API / Experience API」の3層を定義している。

System API：各システム（SAP、Teamcenter、Opcenter等）への直接接続API。システム固有のプロトコル・認証を吸収する
Process API：ビジネスプロセスを実装するAPI（「設計確定度Lv2到達時の先行手配候補生成」等）
Experience API：各チャンネル（モバイルアプリ、Web、AR端末）向けに最適化されたAPI

この3層分離により、「SAP SIDが変わった」「SAP APIの仕様が変わった」という変更がSystem APIの修正のみで吸収され、上位のProcess API・Experience APIに影響しない。

実装の急所： 「再利用率≥40%」という目標は意識的に管理しないと達成されない。Process APIを開発するたびに「似たような機能が既存のAPIにないか」を確認し、重複を作らない文化と、そのためのAnypoint Exchange（APIカタログ）の整備が必要だ。

第五層：AI/ML層の技術

Azure OpenAI + RAG ─ 製造業の「知識エンジン」

何をするシステムか： Azure OpenAIはMicrosoftのクラウドでOpenAIのGPT-4o等のモデルを利用する企業向けサービスだ。RAG（Retrieval Augmented Generation）は、AIが回答を生成する前に、社内の知識ベースから関連情報を検索して参照させる仕組みだ。

なぜRAGが製造業AIの核心か： 汎用AIモデルは「一般的な知識」は持っているが「この工場のこの設備の過去の故障事例」は知らない。RAGは「ユーザーが質問した時、まず社内KB（ナレッジベース）を検索し、関連情報を取得してからAIが回答を生成する」というプロセスを実現する。

v7.0では「社内KB 20万件・出典必須・事実性≥95%」を定義している。出典が必須というのは、AIが回答する時に「この情報はどの文書の何頁から取得した」という根拠を示すことを意味する。製造現場での意思決定支援に使うAIが、根拠なしに回答すると危険だ。

ハルシネーション対策の設計： 「AIが事実ではないことを自信満々に言う」というハルシネーション問題は、製造業AIでは重大リスクだ。誤った保全手順をAIが指示すると、設備の損傷・作業者の負傷につながる。

v7.0では「ゴールデンテスト100問（月次評価）」を定義している。これは「正解がわかっている100問」を毎月AIに答えさせ、正答率が下がっていないことを確認するシステムテストだ。モデルが変わった・KBが更新された・プロンプトが変更されたタイミングで正答率が下がることがある。これを月次でモニタリングすることで、「いつの間にか質が下がっていた」を防ぐ。

CFD・FEA代理モデル（Surrogate Model）─ 解析の「1000倍速AI」

何をするシステムか： CFD（Computational Fluid Dynamics：流体解析）とFEA（Finite Element Analysis：有限要素解析）は、製品の設計段階でシミュレーションを行う技術だ。しかし本計算は大型計算機で数時間〜数日かかる。

代理モデル（Surrogate Model）は、大量の解析計算の結果をAI（ガウス過程＋ニューラルネットワーク）に学習させ、本計算を実行せずに「この設計パラメータならこの性能になる」を秒単位で予測するモデルだ。

なぜETO型に重要か： 一品一様の設計では、毎案件で設計パラメータの最適化が必要だ。「圧力容器の板厚を何mmにすれば重量を最小化しつつ強度要件を満たすか」という最適化問題を、1回の本計算で答えを出すことは不可能だ。設計変数が多いほど、探索空間は広い。

代理モデルを使うと、探索の速度が100〜1000倍になる。「1万通りの設計案を1秒で評価し、最適解の候補を絞り込んでから本計算で確認する」というワークフローが実現する。v7.0では「重量-15%、剛性維持」というジェネレーティブデザインの目標値は、この代理モデル+ジェネレーティブデザイン組み合わせによって達成される。

実装の急所： 代理モデルの適用範囲外の入力に対して、モデルが「それらしい（しかし間違った）」値を返すことがある。これを「外挿問題」と呼ぶ。v7.0では「予測誤差<5%」を要件としているが、この誤差保証が有効なのは学習データの範囲内だ。設計者が「これはAIの予測可能な範囲か」を判断できる訓練と、範囲外検知の自動アラートが必要だ。

第六層：セキュリティ層の技術

IEC 62443 ─ 工場の「鎧」

何をするシステムか： IEC 62443は製造自動化・制御システム（IACS）のサイバーセキュリティに関する国際標準群だ。工場ネットワークを「ゾーン（区域）」と「コンジット（区域間の接続経路）」に分割し、各ゾーンに適切なセキュリティレベル（SL: Security Level）を設定する。

v7.0の4ゾーン構成：

Enterprise Zone（SL-3）：ERP・PLM・クラウド接続
     ↕ 厳格なファイアウォール
DMZ Zone（SL-2）：外部との接触面（サプライヤーポータル等）
     ↕ 一方向データフロー（DMZからのみ下位ゾーンへ）
Manufacturing Zone（SL-3）：MES・SCADA・工場サーバー
     ↕ 最小権限アクセス
Cell/Area Zone（SL-4）：PLC・センサー・NC工作機械

SL-4の意味： Cell/Area ZoneのSL（Security Level）-4は「国家レベルの攻撃者でも侵害が困難」な水準だ。大型特注機器の製造では、制御系への攻撃で生産を妨害しようとする産業スパイ・競合他社のリスクが存在する。SL-4は「物理的な侵入なしには制御系に到達できない」を目標とする。

実装の急所： 「リモート保全のためにVPNを設けた結果、外注業者が全工場ネットワークにアクセスできるようになっていた」というケースが国内でも多発している。v7.0ではJIT（ジャストインタイム）権限付与（CyberArk、15分SLA、セッション4時間上限・録画90日）を定義している。「必要な人が必要な時間だけ必要な箇所にアクセスできる」という最小権限の原則だ。

Claroty ─ OT環境の「X線装置」

何をするシステムか： ClarotyはOT（Operational Technology：制御技術）環境に特化したサイバーセキュリティ製品だ。工場ネットワーク上の全デバイスを自動検出し、通信パターンを学習して異常な通信を検知する。

なぜOT専門製品が必要か： IT（情報技術）セキュリティの常識はOTには通用しない部分がある。ITセキュリティでは「不審なプロセスは直ちに停止」が基本だ。OTでは稼働中の制御プロセスを「不審だ」という理由で停止すると、物理的なプロセス（化学反応・圧力・温度）が制御不能になり、爆発・火災・設備損傷のリスクがある。

Clarotyは「検知するが、自動停止しない」というOT向けの動作原則で設計されている。異常を検知したら管理者に通知し、人間が状況を確認した上で対処する。この「人間の判断を挟む」設計が、工場の安全を担保する。

月次で脆弱性レポートを出力し、「この機器はX年前に発見された脆弱性CVE-xxxx-xxxxに未対処だ」を可視化する。これをCSIRT（サイバーセキュリティインシデント対応チーム）に月次レポートとして提出することが、v7.0のセキュリティガバナンスの実務的な運用体制だ。

技術間の接続：全体として機能するために

個々の技術を紹介してきたが、最も重要なのはこれらが正しく接続されることだ。

顧客が「安定稼働の改善を求める」
    │
    ▼
Teamcenter上の設計確定度がLv2に更新される
    │ Kafkaイベント発行
    ▼
MuleSoft Process APIが「Lv2到達アクション」を実行
    │
    ├→ SAP S/4HANAに長納期材料先行手配オーダーを起票
    ├→ Asprovに「先行着手可能工程のスケジュール計算」指令
    ├→ Opcenterに「先行着手工程の製造指示」生成
    └→ HoloLens向け「先行着手工程の手順AR」の配信準備
    
作業者がHoloLens 2で先行着手工程を実施
    │
    ▼
OPC UAでOpcenterに実績記録
    │
    ▼
Delta Lake（Silver層）でデータ品質チェック
    │
    ▼
MLflowの刃具寿命モデルが「次の交換予測」を更新
    │
    ▼
Azure IoT EdgeのJetson Orinが次の工程を準備
    │
    ▼
試運転完了：500ch・1kHzでSnowflakeへ10年保持
    │
    ▼
アフターサービス：このデータを基に遠隔診断が高精度化

この一連のデータフローが途切れなく動くことが、「統合DXオペレーティングシステム」の意味だ。

単一の技術がどれだけ優れていても、接続が壊れていればシステムは機能しない。本稿で紹介した各技術の「実装の急所」のほとんどは、実は「他の技術との接続点をどう設計するか」という問題だ。

まとめ ─ 技術は手段、目的は顧客価値

これだけの技術スタックを列挙すると「技術を使うことが目的になっていないか」という正当な疑問が生まれる。

答えは明快だ。全ての技術は、一つの問いに答えるために存在する。

一品一様・長納期・設計未確定期間という制約の下で、顧客に安定稼働・エネルギー効率・CO₂削減・保全性・TCO最適化という価値を最大化して届けるには、どんな仕組みが必要か

この問いに答えるために、OPC UAが必要になり、設計確定度管理が必要になり、Kafkaが必要になる。技術が先にあって問いを探しているのではない。

技術を選ぶ判断基準は常に「この技術がなければ、どの顧客価値が届かなくなるか」だ。この基準で選択されていない技術は、どれだけ先進的でも本ツリーには不要だ。

逆に言えば、本稿で紹介した技術の全ては「これがなければ、この顧客価値が届かない」という根拠がある。それが技術選定における「絶対最適」の意味だ。