シミュレーションモデルのデータ：出所と必要な品質

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-11

シミュレーションモデルのデータは、システム、計測、そして専門家から得られます。データの出所、よくある品質上のギャップ、そしてシミュレーションの入力データにどの程度の品質が求められるのかを解説します。

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

シミュレーションモデル構築のデータは、業務・現場システム、直接測定、そしてラインを熟知している人々の三つから得られます。どの程度の品質が必要かは一般的な基準ではなく、解決したい問いによって決まります。本ガイドは、工場シミュレーションのデータ提供を求められる継続的改善マネージャーを対象としています。モデルに必要なもの、各項目の出所、よくある問題点、数値を使った具体例、そして十分な品質のデータを得るための6つのステップを紹介します。

重要なポイント

• シミュレーションモデルには、製品と工程順序、工程時間、リソース、停止、受注、そして人員配置のルールが必要です。各項目は、システム、測定、または専門家のいずれかから得られます。
• データは、ストップウォッチによる測定や観察といった一次データと、ERP、MES、CADなどのシステムや需要予測といった二次データから得られます。
• よくあるギャップは、ERPの初期設定時間と実績時間の乖離、重複レコード、実態に遅れたデータ、そしてばらつきの欠落です。
• 入力は問いに対して十分な品質であれば足ります。結果を最も大きく左右する入力を確認し、労力をそこに集中させてください。
• 平均値だけでなく、分布と実績記録を使用してください。検証したい待ち時間は、ばらつきから生まれるからです。

シミュレーションモデル構築のデータ：モデルに必要なもの

ラインの流れモデルには、6種類の入力が必要です。このリストは一般的な実務をもとに当社がまとめたもので、標準ではありません。

• 製品と工程順序。どの製品がどの工程を、どの順序で通るか。
• 時間。製品と工程ごとの加工時間、段取り時間、およびその両方のばらつき。
• リソース。設備、工具、人員とその能力、そして故障や計画停止を含む稼働可能性。
• 受注と需要。受注ロット、構成比、到着パターン。受注残または需要予測から取得します。
• ルール。交代勤務モデル、休憩時間、投入順序とバッチのルール、オペレーターの工程間移動の方法。
• 品質。スクラップおよび手直しの比率、欠陥が発見される工程。

工場のすべての数値が必要なわけではありません。問いの答えを左右する数値が必要であり、シミュレーションで検証したい待ち時間を生むばらつきも必要です。モデルは、データが許す範囲のことしか予測できません。

シミュレーションの入力データの出所：実務におけるデータ収集

Maja Bärring氏らによる論文（2018 Winter Simulation Conference）は、Anders Skoogh氏らの先行研究に基づき、データの出所を二つのグループに分けて説明しています。

• 一次データは、調査のために収集されるものです。測定、ストップウォッチによる時間測定、ラインでの観察などが該当します。
• 二次データは、すでに存在するものです。産業標準や分野の専門家といった外部の参考情報、ERP、MES、PDM、CADなどの企業の業務システム、そして生産量予測などのプロジェクト固有のデータが含まれます。

継続的改善マネージャーにとって、データ収集は実際には次のようになります。製造実行システムには、ステーションごとの実際のサイクルタイム、停止イベント、数量が保存されています。ERPには、受注、工程順序、計画時間が保存されています。CADまたはPDMシステムには、製品構成が保存されています。シフト計画は、計画部門または人事部門が管理していることが多いです。段取り替え時間や、オペレーターが実際にどのように作業しているかは、多くの場合、観察とシフトリーダーへの聞き取りによってしか分かりません。

データが十分でないことが多い理由

Bärring らは、2社のケーススタディを行い、5名の回答者に話を聞いています。そのため、結果は傾向を示すものであり、一般化はできません。手作業でERPやスプレッドシートからデータを収集していたケースでは、多くの工場に心当たりがあるはずの問題が報告されています。

• 実際の時間の代わりに、ERPに設定された初期値が使われており、どの時間を使うべきか不明確だった。
• 同じ品目が、ERPシステムとスプレッドシートの両方に登録されていた。
• ラベルの表記が統一されておらず、部門ごとに違っていた。
• 現場の実態は変わっていたが、システムは更新されていなかった。

著者らはまた、ERPシステムは確率的な値よりも決定論的な値を重視するため、シミュレーションに必要なばらつきが欠けることが多いと指摘しています。2つ目のケースでは、自動取得により、著者らが挙げた8つの課題のうち5つを回避できました。この論文では、とりわけ、データの管理責任を社内の各部門に割り当てることを推奨しています。Skoogh、Perera、Johansson による調査（Simulation Modelling Practice and Theory 掲載）では、シミュレーション利用者の約80パーセントが、入力データの作成に依然として手作業の多い手順に頼っていることがわかりました。

シミュレーションにおけるルーティングとBOM

問題になりやすいマスターデータは2種類あります。ルーティングは、製品に必要な工程、その順序、使用するリソース、所要時間を定義します。BOM（部品表）は、製品にどの部品が使われるかを定義します。フローモデルでは、通常ルーティングが基幹となります。部品が欠品する場合や、ステーションが組立品の到着を待つ場合には、BOMが重要になります。

ERP上のルーティングは、多くの場合、一度設定されてほとんど更新されない計画値です。これは Bärring らが指摘している問題です。ルーティングをモデルに読み込む前に、同じ製品と同じステーションについて、その時間をMESの実績時間と比較してください。工程の順序が現場の実態と一致しているか、またBOMに実際に製造しているバリエーションが反映されているかを確認してください。ギャップを埋めるために、シミュレーションで生成したデータ（合成データとも呼ばれます）を使い、そのラベル付けを忘れることはしないでください。

シミュレーションデータの品質はどの程度必要か？

答えは、「意思決定に十分な品質であること」です。Averill Law は、シミュレーションモデリングの落とし穴に関する論文（pitfalls in simulation modelling）で、入力分布の記録と検証を求めており、可能であればシステムのランダム性のすべての発生源についてデータを収集することを推奨しています。彼は2つの誤りについて警告しています。1つは、ランダムな入力をその平均値に置き換えることです。彼の例では、これによって待ち行列が完全に消えてしまいます。もう1つは、慣習的に正規分布を選ぶことです。彼の例の1つでは、これにより39パーセントの出力誤差が生じました。

どの程度の労力をかけるかを判断する実践的な方法は、各入力を、その影響度と各パラメータの不確実性によってランク付けすることです。Law は、どの要因が性能指標に最も影響するかを見るために、感度分析も推奨しています。以下の等級づけは、標準ではなく、私たちが計画を立てるための補助的な目安です。

1. 等級A：測定済みかつ検証済み。結果を最も大きく動かす入力に使います。たとえば、ボトルネックのサイクルタイムや、その前工程の停止パターンなどです。
2. 等級B：システムから取得し、サンプルで検証済み。影響度が中程度の入力に使います。
3. 等級C：専門家の判断。影響が小さい入力に使います。その際は前提条件を必ず記録してください。

最後に、モデル全体を検証してください。モデルは実際のラインの出力を再現できるでしょうか。再現できない場合は、まず等級Aの入力を確認してください。

例：ルーティング時間と実際の時間の比較

これは想定値を用いた例示であり、実測による事例ではありません。あるラインでは1種類の製品を生産しています。ERPのルーティングでは、ボトルネックのステーションでの1個あたりの時間は42秒です。MESでは、4週間にわたる実際のサイクルタイムの中央値が47秒と示されています。

• ルーティング時間による1時間あたりの生産数：3,600 ÷ 42 = 85.7個。
• 実際の時間による1時間あたりの生産数：3,600 ÷ 47 = 76.6個。
• ルーティングでは、レートを 85.7 ÷ 76.6 ≒ 12% 過大に見積もっています。8時間のシフトでは、約686個に対して実績は613個となり、差は73個です。

ルーティングを入力したモデルは、ラインが一度も到達したことのない予測を出してしまいます。そのモデルを基準に改善効果を測ると、実際より悪く見えてしまいます。

同じ考え方は停止にも当てはまります。MESに、2分、3分、3分、4分、5分、6分、40分の7回の停止が記録されているとしましょう。合計は63分なので平均は9分ですが、中央値は4分です。停止時間を一定の9分とするモデルでは、バッファを空にしてしまう40分の停止が現れず、実際のラインよりも中程度の停止が多く表れてしまいます。記録された停止時間をプロットしてばらつきを計算し、そのまま使うか、記録に適合させた統計分布を使ってください。その際、パラメーターは記録から推定します。

データを適切に活用するための6つのステップ

1. 質問を明確にする。 質問によって必要な入力データが決まります。
2. 上の6つのグループの項目を挙げ、どの項目が質問の答えに最も大きく影響するかを印付けします。
3. 各項目の情報源と担当者を特定します。 例えば、停止はMES、受注はERP、段取り替えは観測者といった具合です。
4. 情報源を比較する。 ルーティングの時間をMESと照合し、システム間で識別子と単位が一致しているかを確認します。
5. ギャップを測定する。 重要な入力データにはグレードAの方法で測定し、それ以外は前提条件を記録します。
6. 検証し、データを維持する。 モデルを実際のラインと比較し、データセットを日付付きで保存し、更新を担当する担当者を決めます。

よくある間違い

• ERPのルーティングを確認せずに読み込む。 計画値は実績値ではありません。
• 平均値だけを使う。 各入力データは単一の数値ではなく、ばらつきを持つ変数です。待ち時間を生むのはばらつきであり、平均値はそれを消し去ってしまいます。
• 何でも集める。 質問がないまま作業を重ねても、プロジェクトに余裕のない時間を浪費するだけで、膨大な量のデータが本当に重要なものを隠してしまいます。
• 定義を混在させる。 停止、段取り替え、サイクルといった言葉の意味は、システムによって異なる場合があります。
• 担当者がいない。 誰も管理していない数値は、次の変更時にはすでに古くなっています。
• 検証を省く。 実際のラインとの比較がなければ、入力データが十分に良いものかどうかはわかりません。

ソフトウェアはどのように役立つか

製品、工程の手順、リソースを結び付けるナレッジグラフを使うと、各事実が一度だけ保存されるため、重複や矛盾したデータを減らせます。iFAKTのPolaris Designerは、iFAKT Polarisのモジュールで、製品、工程の手順、リソースについての唯一の信頼できる情報源として、製品・工程・リソース（PPR）のナレッジグラフを構築します。ただし、実際の時間との照合、担当者の設定、モデルの検証に代わるものではありません。どのツールを使う場合でも、ERPやMESからどのようにデータを取り込むか、また変更がどのように追跡されるかを確認してください。

次のステップ

1つのラインのボトルネック工程を選び、過去4週間について、ERPのルーティング時間とMESの実際のサイクルタイムを比較してください。両者に差があれば、シミュレーションモデル構築に向けたデータの最初のギャップが見つかったことになり、どこから着手すべきかもわかります。