絵に描いた100点より「今動く30点」が現場を変える　日立「FDE」がOPEX最適化とデータ融合に挑む工場インフラ革新

ITとOTをつなぎ「真のDX」の推進役として期待されるFDE

多くの現場でDXやAI活用が推進されていますが、PoC（概念検証）で想定どおりの結果が得られるケースは多くありません。特に設計や生産、物流などのOT（制御・運用技術）現場では、IT領域では直面しなかった予期せぬリスクやトラブルに遭遇しやすいという課題があります。

そうした中、ITとOTをつなぎ、現場におけるDX・AI活用の推進役として期待されているのがFDE（Forward Deployed Engineer）です。本セッションでは、FDEの取り組みを軸として、日立グループ4社のデータを融合させた工場インフラ改革の事例を紹介しました。

浅倉はまず、OT現場が直面している課題と背景について次のように語りました。

「設備の老朽化や熟練者の定年退職、電力コスト高騰などを背景に、工場インフラの維持は、現場の苦労にとどまらない『経営の最重要課題』になってきています。一方、従来の工場は設備ごとに個別最適で管理され、全体でOPEX（運用コスト）を最適化できていません。この課題に対して日立が打ち出したのが、ユーティリティー設備全体のDX・GX支援を通じてOPEX削減と安定稼働をめざすサービス構想『Energy & Facility management as a Service』（EFaaS）です」

EFaaS構想の実現に向けて集結したのが、受変電（電力）の「日立パワーソリューションズ」、空気圧縮機の「日立産機システム」、空調の「日立グローバルライフソリューションズ」、水処理の「日立プラントサービス」の4社です。「One Hitachi」としてこの4社が連携する意義について、浅倉は「エアコンプレッサーが動けば電力を消費して発熱し、それを冷却するために空調や水設備が動きます」と例を挙げ、「従来は縦割りの個別最適でしたが、お客さまの工場を主語にすれば一連の流れで連動しています。だからこそ4社のデータを融合させ、『全体最適』で価値を出す必要があったのです」と狙いを強調しました。

この取り組みを最前線で推進したのがFDEです。日立はFDEを「ITとOTの言語を通訳し、動くプロトタイプで会話のプロトコルを合わせるエンジニア」と定義しています。グループ4社はそれぞれITソリューションを提供しており、各領域にOTの熟練者がいます。しかし、AIを取り巻く環境は技術的な前提が日々塗り替わるほど変化が激しく、OT現場だけでAI導入を推進するのは容易ではありません。そこでFDEが4社の現場に飛び込み、動くものを最速で形にしながらEFaaSの具現化に挑む――ここに、本プロジェクトにおけるFDEの真骨頂があります。

4社のデータ融合で直面した3つの障壁と解決アプローチ

FDEが立脚するのは先端技術よりも現場のリアルな声です。それを基にプロトタイプを作成し、フィードバックを得ながら価値を証明して事業化に導くことがミッションでした。しかし、その取り組みは平たんなものではなく、特にデータに関して3つの技術的な障壁に直面し、試行錯誤を重ねて解決していきました。

1つ目はシステムの分断です。現場には20年以上稼働するシステムが残り、データの二次利用を想定したAPIなどが存在しませんでした。浅倉は「理想にこだわらず、力業で対応しました」と振り返ります。

「APIがないものはCSVで抽出し、自作プログラムでAIに読み込ませました。アーキテクチャーの美しさより、最速でインサイトを引き出すことを優先したのです。また型番やエラーコードが厳密な現場では、ベクトルDBの意味的検索がノイズになるため、古典的な部分一致検索（GREP）やディレクトリ検索をファイルシステムエージェントと組み合わせる手法を採用しました」

2つ目はデータの欠落です。AI処理に必要なデータ自体が存在しないケースも多くありました。例えば、大規模なシステム停止（通称、ドカ停）の前に発生する微小停止（通称、チョコ停）をAIで検知する仮説を立てたものの、現場では5分未満の停止データが取得されていなかったといった具合です。

そこで浅倉たちプロジェクトチームは、データの取得手法そのものを新たに整備しました。「稼働歴30年の工作機械にはネットワーク接続機能がないため、物理的な後付けセンサーやノギスを使った計測でデータ化しました。さらに、ベテラン作業者が機械の異常を五感で判断していることに着目し、高精細ビジョンや音響・サーマルセンサーを搭載した自走型ロボットによる現場計測にも取り組んでいます」

3つ目はAIエージェントの限界です。ベテランの暗黙知継承に向けて活用を試みましたが、当初は4社にまたがる複雑な設備構造をAIが理解できませんでした。

「RAGでは複雑な設備構造を理解できず、回答精度に限界がありました。そこで設備の相関関係を体系化する『オントロジー（知識構造化）』を構築したところ、精度は大幅に向上しました。しかし、構築に多大な時間と労力がかかり、短期間で成果を出すには不向きです。そこで、既存テキストに見出しや表を加える『構造化Markdown』を採用して、短期間でオントロジーに匹敵する精度を確保する現実解にたどり着きました。現在は先を見据え、Human-in-the-Loopの下、データ保存や応答についてAIが自己分析・再設計する『再帰的自己改善（RSI）』にも挑戦しています」

FDEが現場に入り込み、3カ月という短期間で実際に動くプロトタイプを作成

EFaaS構想の下、グループ4社による協働プロジェクトがスタートしたのは2026年5月。FDEが現場に入り込み、わずか3カ月という短期間で動くプロトタイプを作成しました。これにより、現場の担当者自身も気づいていなかった「本当にやりたいこと」を引き出し、目に見える成果を最速で出すことができました。呉は開発したプロトタイプの概要について次のように語りました。

「ユーティリティー設備の管理を効率化する補助アプリケーションを開発しました。工場の高圧受電設備や空気圧縮機、エアタンク、エアドライヤーなどの接続関係を可視化するほか、トラブル時には異常が発生した設備や、その際の吐出温度・圧力、吸い込み温度、モーター電流などをリアルタイムに表示します。画面で診断を指示すれば、AIエージェントが蓄積ナレッジを検索して、発生状況や解決策を提示する仕組みです。現場で動くものを見せ、フィードバックを取り入れながら機能や品質の改善を重ねました」

このアプリケーションは、工場の地図上で自走型ロボットを操作し、トラブルが発生した設備を高精細ビジョンやサーマルセンサーでセンシングさせる機能を備えています。センシング結果の解析が難しい場合でも、AIエージェントに質問すれば熟練者のナレッジを反映した回答を得られる仕組みです。さらに、アラートからの根本原因推定や、チョコ停データと保守履歴を掛け合わせた機器メンテナンスのアドバイスも可能となっています。

呉は、ITとOTが交差する共創プロジェクトにおいて、FDEの必要性が一層高まっていると指摘します。

「AIの進化で『やってみないと分からない』タスクが急増しています。モデルの頻繁なアップデートで昨日不可能だったことが今日可能になるケースも増え、コーディングエージェントの台頭でスクラッチ＆ビルドのコストも大幅に低下しました。そうした中、最前線で即座に手を動かすFDEの存在は不可欠です。ただし、FDEに求められるのはAIの知識だけではありません。お客さまが言葉にした要望をそのまま受け取るのではなく、その裏にある真の課題を見抜くことこそがFDEのスタートラインです」

現場のフロントで「変換」「実装」「改善」のループを高速に回すエンジン

呉は、お客さまの要望を言葉通りに受け取るのではなく、その裏にある真の課題を見抜く姿勢について、自動車の大量生産を実現したヘンリー・フォードの言葉になぞらえて次のように語りました。

「『速い馬がほしい』という声だけを聞いていたら、もっと速い馬を（交配や訓練などで）作るだけで自動車は生まれなかったはずです。われわれも『RAGを作りたい』『オントロジーを作りたい』という言葉をそのまま受け取っていたら、単に『進化した馬』を提供するだけに終わってしまいます。お客さまの声の裏にある『より速く移動したい』という本質的な課題に応える姿勢が欠かせません」

そこで求められるのが、「変換」「実装」「改善」の3つのループを高速に回すことです。言葉をソリューションに落とし込む「変換」、最速で形にする「実装」、即座にフィードバックを得て修正する「改善」。FDEは現場のフロントでこのループを高速回転させるエンジンになります。

その上で呉は、FDEに求められるアプローチやマインドセットとして以下の4点を挙げました。

1つ目は「完璧主義を捨て引き算の思想を持つこと」です。100点をめざして3カ月かけるのではなく、「30点でも目の前で動くものを1週間で作る」スピード感を重視します。動くプロトタイプこそが現場の納得と説得力に直結するからです。

2つ目は「技術の基礎体力を固めること」です。AIを活用するにはインフラやミドルウェアの知識が不可欠であり、FDEにはVM、コンテナ、DB、認証機構、アーキテクチャーの整合性、非機能要件、運用設計といった総合的な技術力が求められます。

3つ目は「環境がそろうのを待たず、野生の精神で挑むこと」です。データが存在しない場合でもダミーデータを作成して稼働させるなど、今あるリソースで最も早く形にする泥臭さが鍵を握ります。

4つ目は「プロトタイプで指摘を受けること」です。100点になるまで抱え込むのではなく、早期に現場へ持ち込んでフィードバックを受け、高速で修正します。お客さまの下で重ねた失敗の数こそが価値につながっていきます。

呉は最後に「プロジェクト発足当初は、4社の設備データを1つの画面に一元化しさえすれば喜んでもらえるという思い込みがありました」と振り返り、本プロジェクトの最大の学びを次のようにまとめました。

「しかし、実際には統合画面を見せるだけでは他社設備への影響や相関関係が判別できず、現場では意味を成さないと痛感しました。そこからが本当のスタートであり、現場での泥臭い挑戦と試行錯誤の多さこそが、プロジェクトを成功に導いた最大のポイントでした」

今回ご紹介したOne Hitachiの取り組みは、FDEが現場課題を解決した事例の一つに過ぎません。ここで得られた「真の課題を引き出すメソッド」は、企業や業種の壁を越えて広く適用できるものです。設備の老朽化やOPEX最適化に悩む多くの工場にとっても、日立のアプローチは課題解決の一つのヒントになるのではないでしょうか。