製造業向けデジタルツインソフトウェア：購入者のためのチェックリスト

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

製造業向けデジタルツインソフトウェアは、モデルを稼働中のデータと同期させ続けます。プラットフォーム、パッケージツール、セキュリティ、コスト、運用保守を比較するためのチェックリストです。

Automatically translated with AI from the original post. Read the English original

製造業向けデジタルツインソフトウェアは、機械、ライン、または工場のモデルを構築し、そのモデルを実際のデータに接続し続けます。これにより、稼働状況を監視したり、問題を予測したり、変更を加える前に検証したりできます。本記事は、同じ用語を使う製品を比較しなければならない工場長のための記事です。デジタルツインの基本は繰り返さず、ソフトウェア選定のためのチェックリストを提供します。必要な機能から、運用を継続するためのコストまでを取り上げます。

重要なポイント

• NISTは、デジタルツインに不可欠な3つの要素として、高頻度のセンシング、信頼性の高い産業用IoT接続、予測のためのシミュレーションモデルを挙げています。ソフトウェアはこれらをカバーするか、パートナーと連携して提供する必要があります。
• Azure Digital Twinsはツイングラフのためのプラットフォームサービスであり、既製の工場向けアプリケーションではありません。Microsoftによると、Fabricのデジタルツインビルダー（プレビュー）とは異なるサービスです。
• まず、その上に構築するためのプラットフォームが必要か、特定の課題に対するパッケージツールが必要かを決めてください。その答えによって、作業を誰が担い、どれだけのコストがかかるかが変わります。
• ISO 23247-1は、製造業におけるデジタルツインのフレームワークの概要と一般原則を示しています。ベンダーとの間で用語をそろえる際に役立ちます。
• ライセンス料だけでなく、データ統合、モデル検証、運用保守にも予算を確保してください。最初のパイロットは、1つのラインと1つの意思決定に絞りましょう。

製造業向けデジタルツインソフトウェアには、何が含まれるべきですか？

まず、ベンダーが都合よく解釈できない定義から始めましょう。NISTはデジタルツインを、物理的な対象を正確に再現し、接続し、同期させる、動的でデータ駆動型の仮想表現と説明しています。また、デジタルツインは静的なモデルではないとしたうえで、その忠実度、有用性、長期的な実現性を決める3つの不可欠な要素として、高頻度のセンシング、接続のための信頼性の高い産業用IoTインフラ、予測分析のための高度なシミュレーションモデルを挙げています。

この3つの要素を、どの製品にも使える質問に置き換えてみましょう。

1. データの取り込み。どのソースを読み取りますか。機械のコントローラー、センサー、MES、ERP、スプレッドシートなどです。データの更新頻度はどのくらいですか。各接続を構築し、保守するのは誰ですか。
2. 意味のあるモデル。工場はどのように記述されていますか。資産、ライン、プロセス、それらの関係などです。工程が変わったときに、社内の担当者が記述を修正できますか。
3. その上の分析。現在の値を表示するだけですか、それとも予測、シミュレーション、シナリオの比較ができますか。その機能は標準で組み込まれていますか、それとも別途プロジェクトが必要ですか。

さらに、2つの実務的な要件を加えてください。結果（ダッシュボード、レポート、アラート）を利用者が読み取れること、そしてアクセスをロールごとに制御できることです。製品がこの5つのうちいずれかを欠いている場合は、それを誰が提供するのかを確認してください。

デジタルツインとして販売されているソフトウェアには、どのような種類がありますか？

デジタルツインという呼び方は、非常に異なる製品を含んでいます。価格を比較する前に、提供物を4つのグループに分類してください。

• 構築の基盤となるプラットフォーム。モデルの保存、データの接続、クエリの実行に必要な構成要素を提供します。その上のソリューションは、お客様または パートナーが構築します。
• パッケージ型の本番ツイン。 生産計画、シミュレーション、工場の最適化などに使える、本番向けのデータモデルが最初から用意されています。そのため、開発の手間が少なくて済みます。
• 資産・状態ツイン。 機械の健全性に焦点を当て、センサーデータを使って摩耗や異常を検出します。
• 設計・試運転ツイン。 設備を設置する前に、レイアウトや制御ロジックを検証します。

あるグループのツールと別のグループのツールでは、答えている問いが異なります。状態ツインでは新しい交代勤務モデルでバックログが解消できるかはわかりませんし、生産シミュレーションではベアリングがいつ故障するかはわかりません。まず判断内容を書き出し、そのうえでグループを選んでください。

Azure Digital Twins のようなプラットフォームでは、何が得られるのでしょうか。

Azure Digital Twins は、Microsoft の代表的な例です。Microsoft Learn によると、建物、工場、エネルギーネットワークなどの環境のデジタルモデルに基づいてツイングラフを作成する、サービスとしてのプラットフォーム (PaaS) です。ドメインの語彙は、JSON に似た言語である Digital Twins Definition Language (DTDL) で定義し、ツインはそのモデルのインスタンスになります。ツイン同士の関係がグラフを形成し、それを最新の状態を反映したライブビューとして照会できます。IoT Hub からデバイスデータを取り込み、REST API とコネクタで業務システムのデータを取り込み、イベントルートを通じてツインのデータを Azure の他のサービスに渡して分析できます。

購入を検討する際に重要な点は2つあります。1つ目は、これが構成要素であるという点です。モデルを格納し、接続する役割を担います。キュー、段取り替え、シフトカレンダーを扱う生産シミュレーションのシナリオ分析ロジックは別のソフトウェアであり、その結果はご自身またはパートナーが開発する必要があります。2つ目は、同ページで Azure Digital Twins が Fabric digital twin builder (プレビュー) や IoT Hub のデバイスツインとは異なると明記されている点です。計画を立てる前に、同僚やベンダーが指しているのがどれなのかを確認してください。

履歴の管理は別のステップです。グラフはライブビューですが、データ履歴に関する Microsoft のページでは、インスタンスを Azure Data Explorer クラスターに接続すると、グラフの更新を時系列で記録できると説明されています。その間には Event Hubs 名前空間が入ります。また、データ履歴によって出力されるメッセージは、メッセージの価格ディメンションで課金されるとも書かれています。つまり「先月の傾向を見たい」という要望には、追加のコンポーネントとコストが伴います。どのベンダーに対しても同じ質問をしてください。履歴はどこに保存されるのか、そしてその費用はいくらか、と。

プラットフォームを基に構築すべきか、それともパッケージ化されたツールを購入すべきか。

判断には次の質問を使ってください。

• 解決したい問いはどれくらい具体的ですか。 生産能力、人員配置、製品構成など、明確な生産上の問いであれば、通常はパッケージ型ツールのほうが早く答えが得られます。多数の資産タイプにまたがる広範で長期的なデジタル基盤が必要な場合は、プラットフォームのほうが柔軟性があります。
• 作業は誰が行いますか。 プラットフォームには開発者またはパートナーが必要です。その作業時間を見積もってください。パッケージ型ツールであれば、作業は設定とデータ準備が中心になります。
• 自社のプロセスはどれくらい独自ですか。 プロセスが特殊であるほど、柔軟なモデルの重要性が高まります。標準的なフローであれば、パッケージ型ツールのほうが適しています。
• どのくらいの期間使い続ける予定ですか。 数年にわたって使うモデルには、担当者と変更に備えた予算が必要です。製品ファミリーを追加したときや、ラインを移設したときに、誰がモデルを更新するのかを確認してください。
• すでに何を保有していますか。 IT チームがクラウドプラットフォームを運用しており、データチームもあるなら、プラットフォームの構築が適しているかもしれません。どちらもない場合は、パッケージ型ツールのほうが現実的な選択肢になる可能性があります。

すべての企業に当てはまる正解はありません。多くの工場では両方を併用しています。共通のデータ基盤にはプラットフォームを、特定の判断にはパッケージ型ツールを使うという形です。両者のインターフェースは最初から計画しておきましょう。

接続性と標準への対応はどのように確認しますか。

ツインは、データが入り、結果が出てこなければ役に立ちません。年式やメーカーの異なる設備にソフトウェアがどのように接続するのかを確認してください。

一般的なルートの1つがOPC UAです。OPC Foundationは、OPC UAを工場やプロセス制御機器から企業システムへデータを届けるための仕組みとして説明しており、セキュリティ、信頼性、プラットフォームをまたいだ運用を重視しています。また、IEC 62541規格として2011年に制定されたとしています。OPC UAに対応したベンダーであれば、多くの場合、独自のドライバーを用意しなくても多数の機械からデータを読み取れます。ただし、古い設備ではゲートウェイや追加のセンサーが必要になることがあります。

フレームワークそのものについては、ISO 23247-1が規格「Digital twin framework for manufacturing」の第1部にあたります。ISOによると、2021年10月に発行されており、概要と一般原則、そしてフレームワークの用語、定義、要件が含まれています。この規格を読んだだけでデジタルツインが完成するわけではありませんが、社内チームとベンダーが同じ言葉で議論するための共通基盤になります。ベンダーのアーキテクチャがこの規格を参照しているか、そしてそれが実際に何を意味するのかを、スライド上だけでなく具体的に確認してください。

システムの境界についても確認してください。

• モデルとデータをオープンな形式でエクスポートできますか。
• ERP、MES、そしてPower BIなどのレポートツールに、レポートごとのカスタマイズなしで接続できますか。
• データの取り込みが止まったとき、どうなりますか。古い値を完全な確信を持って表示し続けるデジタルツインは、データの欠落を明示するものより有害です。

セキュリティとアクセスをどう評価しますか。

デジタルツインは、機械、製造指図、場合によってはサプライヤーのデータなど、本来は別々だったシステムを結び付けます。そのため、攻撃者が利用できる経路が広がり、プロセスを閲覧できる人の範囲も広がります。

以下の点は書面で確認してください。

• どの人が、モデルのどの部分を閲覧・編集できますか。アクセス許可はロールベースですか。工場やラインごとに制限できますか。
• データはどこに保存され、誰が運用し、契約を終了した場合にデータはどうなりますか。
• モデルへの変更はどのように記録され、ロールバックは可能ですか。
• ベンダーはどのセキュリティ認証を取得していて、その適用範囲はどこまでですか。企業としての認証が、購入する製品を自動的にカバーするわけではありません。
• アップデートやパッチはどのようにシステムへ適用され、その責任は誰が負いますか。

顧客やサプライヤーとデータを共有する場合は、何かを接続する前に、顧客側が特定のセキュリティ評価を求めていないかを確認してください。

実際のコストはいくらになり、価値はどのように測定しますか。

ライセンス料は目に見えるコストにすぎません。それ以外のコストは、あとから発生するのが一般的です。

• デジタル出力を持たない機械向けのセンサー、ゲートウェイ、ネットワーク工事。
• データ準備: クレンジング、マッピング、システム間での定義の統一。
• モデルの構築と、実際の結果に基づく検証。
• メッセージ量や履歴保存用ストレージなど、クラウドの利用料。
• 工程変更のたびにモデルを保守する担当者。
• 結果を利用する人への教育。

各ベンダーには、上記をすべて含めて1つのパイロットラインを3年間分で見積もってもらってください。比較すべきは月額のサブスクリプションではなく、総額です。

価値については、開始前に指標を決めておきます。その指標を、デジタルツインが支える意思決定に結び付けてください。例えば、パイロットラインの計画外停止時間、リードタイム、計画遵守率、段取り時間、スクラップ、保全工数などです。少なくとも数週間分のベースラインを記録し、パイロットを実施してから比較します。変化させるべき数値を挙げられないのであれば、まだ購入する準備はできていません。

仮定の例を挙げます。工場長が、組立セルに2交替目を追加すれば、繰り返し発生している受注残を解消できるかを知りたいとします。この判断に、機械のリアルタイムデータは必要ありません。工程表、サイクルタイム、稼働カレンダーから作成したシミュレーションで、直接答えを出せます。センサープログラムを伴う状態監視型のデジタルツインは、はるかに大きなプロジェクトになり、そもそもこの問いには答えられません。意思決定に答えを出せる最も安価なツールが勝ちです。

デジタルツインを時間をかけて正確に保つにはどうすればよいでしょうか。

工場は変化します。更新されないデジタルツインは、やがて現実からずれていきます。ルールは早い段階で決めておきましょう。

1. モデルごとに、代理担当者を置いたうえで、オーナーを明確に決めてください。
2. モデルをバージョン管理してください。誰が何をなぜ変更したかを記録し、ロールバックできる状態を維持します。
3. モデルの変更を工場の変更と結び付けてください。新しい製品ファミリー、機械の移設、シフトパターンの変更などが発生したら、モデルのレビューを行います。
4. 定期的に検証してください。直近の期間について、デジタルツインの出力と実際の結果を比較し、差異を書き出します。
5. 段階的に拡大してください。最初のラインにオーナー、検証済みのモデル、測定可能な成果が揃ってから、次のラインを追加します。複数工場に展開する場合は、中核となるデータ定義を標準化し、管理された範囲で現場ごとの違いを認めてください。

よくある間違い

• 何の意思決定を支えるのかを明確にする前に、ソフトウェアを購入すること。
• ライセンス価格だけを比べ、統合、検証、運用の維持コストを無視すること。
• パッケージ製品で足りる問いに対してプラットフォームを選ぶこと、またはその逆。
• ライブデータが動かしていない3Dモデルを、ツインの証明として受け入れること。
• データフィードが障害を起こした場合にどうなるかの確認を省くこと。
• プロジェクトチームが離れた後も、モデルに責任者を置かないままにすること。
• 1つのラインからではなく、工場全体から始めること。

Polaris が適するケース

最初の問いが計画やwhat-if判断に関するものであれば、iFAKT Polaris は検討に値する選択肢の一つです。iFAKT は Polaris を、生産向けのAIとデジタルツインを組み合わせたもの、つまりERPデータと製造デジタルツインを統合したものとして説明しています。Polaris Designer モジュールは、ERPデータ、工程時間、リソース構造、制約条件などの入力データを、単一の信頼できる情報源となる製品・工程・リソースのナレッジグラフに変換します。Polaris Simulator モジュールはこれを基に、生産能力、人員配置、バッファのシナリオを含めて生産システムを仮想的に検証します。対象は生産計画の判断であり、個々の機械の状態監視ではありません。そのため、まず自社の問いと合致するかを確認してください。

次に読むと役立つトピック

• 標準化と相互運用性: 機械設備が混在する環境で、OPC UA、その他のプロトコル、ISO 23247がどのように組み合わさるか。
• ミドルウェアと統合: レポートごとに個別の連携を作らず、ツインをERP、MES、SCADAに接続する方法。
• モデルのガバナンス: 変更され続けるモデルのバージョン管理、アクセスロール、レビューサイクル。
• 複数工場への展開: 中央集権型と現場ごとのモデルの比較、およびデータ定義を揃えた状態を保つ方法。
• 総コストと投資対効果: 3年間のコストの全体像と、パイロットの前後比較指標の作り方。

次のステップ

ツインに支えてほしい判断を1つ書き出し、うまくいった場合に変わるべき数値も書き添えてください。そのメモを次のベンダーとの打ち合わせに持参し、製造向けデジタルツインソフトウェアが1つのパイロットラインでその問いにどう答えるか、どのデータを使うか、3年間の総コストはいくらかを、各ベンダーに尋ねてください。