混合変更と障害に対する生産シミュレーション

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は、離散事象シミュレーションについて、さまざまなシナリオや条件のもとで生産システムを分析し、スループット、生産能力、ボトルネックを測定する手法だと説明しています。同じNISTのページでは、主な障壁として、設備や工程に関するタイムリーで正確なデータの取得が難しいことも挙げています。これは、結果をどこまで信頼できるかを左右するため、念頭に置いておいてください。

シミュレーションで最も役立つのは、影響がどこに現れるかが見えることです。1台の機械が止まると、その影響がその機械だけにとどまることはほとんどありません。その前に仕掛品が溜まり、後工程は作業できなくなり、その機械を通らない受注まで遅れます。モデルを使えば、この連鎖を数週間の火消しではなく、数分で可視化できます。

また、ボトルネックが移動しうることを把握するのにも役立ちます。Lean Enterprise Instituteによる制約理論の紹介では、制約に対処した後は、制約がシステム内の別の箇所に移っていないかを再評価する必要があるとされています。障害も、そのような再評価を求めることなく同じことを引き起こします。まずはモデルで試してみてください。

どの障害をシミュレーションする価値がありますか？

すべてではありません。まずは短いリストから始め、次の2つの問いで選んでください。どのくらいの頻度で起きるか。起きたときにどれだけのコストがかかるか。

代表的な候補は次のとおりです。

• 機械の停止。停止の頻度と修理にかかる時間をモデル化しましょう。平均値では長時間の修理が見えなくなりますが、そうした修理こそが大きな影響を与えます。保全記録に実際の停止時間があるなら、平均値だけでなく、そのばらつきを使ってください。
• 人員。欠勤、シフトでの特定スキルの不足、残業時間の上限。
• 資材。納品の遅延、数量不足、入荷ロットの品質保留。
• 品質ロス。スクラップや手直しにより、部品が工程に戻ってくること。
• 緊急注文。割り込みで順番を飛ばし、追加の段取り替えを強いる緊急オーダー。
• 需要の変化。バリエーションの構成比の変化や、数量の急増。

自社の記録をもとに優先順位を付けてください。昨年の停止ログ、シフト報告書、納期遅延のリストを確認します。毎月発生している中断であればシミュレーションに組み込みます。5年に1回しか起きていないのであれば、記録にとどめて今回は除外します。

製品構成の変化はどのようにシミュレーションしますか。

製品構成とは、受注の流れにおける各バリエーションの比率のことです。バリエーションごとに共有設備を使う時間は通常同じではないため、この比率が重要になります。構成が変わると、総生産数が同じでも、各リソースの負荷が変わります。

Winter Simulation Conferenceで発表されたインタラクティブな製造シミュレーションに関する論文では、バッチ式の炉エリアでこの影響が示されています。製品は特定の組み合わせルールの下でしか同じバッチに入れられないため、投入順序が炉の稼働に影響し、構成の変化に伴ってボトルネックも移動します。古い論文であり特殊な事例ではありますが、共有リソースの多くに当てはまる教訓です。

検討の進め方は次のとおりです。

1. 基準値を固定します。現在の構成を使い、モデルが直近の生産量とリードタイムを再現することを確認します。
2. 新しい構成を定義します。「バリエーションBが少数派から注文の半数に増える」のように、数量の比率として記述します。総量が横ばいか増加かも決めます。
3. バリエーションごとのデータを確認します。各バリエーションには、それぞれの工程順序、加工時間、段取り時間が必要です。バリエーション間の段取り替えは、加工時間よりも影響が大きいことがよくあります。
4. 新しい構成で実行します。リソースごとの稼働率、待ち行列の長さ、バリエーションごとのリードタイムを比較します。
5. 構成を段階的に変えます。最終状態だけをテストしないでください。数段階に分けて移行させ、ボトルネックが別のリソースに移る地点や、リードタイムが急に伸び始める地点を見つけます。
6. 変更案を書き出します。2交替制の導入、バッファの追加、別の順序ルール、もう一台の機械へのツール配置などが考えられます。そのうえで、同じモデルで各変更案をテストします。

例：概算による検証（仮定の数値）

この例は考え方を示すために作成したものであり、実測結果ではありません。

あるセルには1台のフライス盤があります。バリエーションAは同機で6分、バリエーションBは10分かかります。現在の注文は、Aが70%、Bが30%です。1個あたりの平均時間は 0.7 × 6 + 0.3 × 10 = 7.2分になります。450分のシフトでは、フライス盤は約62個を生産できます。

ここで構成が、Aが50%、Bが50%に変わったとします。平均時間は8分になり、同じシフトでの生産量は約56個になります。停止が一度もなくても、構成の変化だけで生産量は約10%減少します。

ここに45分の停止を加えます。フライス盤の稼働時間は405分になり、シフトでの生産量は約50個になります。一見すると害のない2つの変化によって、生産量は約2割減少しました。

この計算は良い最初のチェックになるため、モデルを構築する前に行うべきです。ただし、待ち行列、段取り替え、バッチのルール、ランダムな停止、次の工程への波及効果は示せません。それらを加えるのがシミュレーションの役割です。

シナリオにはどのようなデータが必要ですか。

中断シナリオには、通常のモデルにはないものが必要になる場合があります。結果を約束する前に、次のリストを確認してください。

• 機械ごとの停止履歴：停止の頻度と各停止の所要時間を、保全または停止ログから取得します。
• 作業カレンダーとスキル：どの作業者がどの工程を担当できるか、また短縮シフトではどうなるか。
• バリエーション間の段取り時間と切り替え時間。加工時間だけでなく含めます。
• 受注と納期のデータ。何かが遅れたかどうかだけでなく、どの注文が遅れるのかを把握できます。
• 現在の生産ラインが実際に従っているルール：順序ルール、残業時間の上限、ジョブを別の機械に移す条件。

欠けている行がある場合は、シナリオの説明にその旨を明記してください。推定した停止時間に基づく結果は、見栄えの良いグラフをまとった推測にすぎません。数値は生産ラインのチームにレビューを依頼してください。どの数値が誤っているかを、多くの場合2分ほどで教えてくれます。

中断スタディはどのように実施しますか。

手順は他のシミュレーションプロジェクトと同じですが、中断の検討では特に重要になるポイントがいくつかあります。

1. 問いを書き出します。 たとえば「工場ラインが1シフト丸ごと停止した場合、どの受注が納期に間に合わなくなり、もっとも安く済む対応策は何か」のように具体的に書きます。
2. ベースラインを検証します。 モデルの出力を過去の期間の実績と比較します。差が大きい場合は、障害を1つも追加する前にデータを修正してください。
3. 少数のシナリオを定義します。 3〜5件で十分です。それぞれに名前を付け、何が変わるのか、そしてその変化がどれくらい続くのかを書き出します。
4. 各シナリオを複数回実行します。 故障は偶発的に起きるため、1回の実行結果は通常より良く見えることも悪く見えることもあります。単一の数値ではなく、結果の範囲を比較してください。
5. 対応策をテストします。 残業、別の設備への作業移管、作業順序の変更、在庫の利用などを検証します。対応策を含まない障害シミュレーションは、問題が起きることを示すだけです。
6. 判断基準を事前に合意します。 実行前に、どの結果が出たら行動するのかを決めておきます。そうしないと、数値をめぐる議論だけが続いてしまいます。

シナリオは短いリストにまとめ、プロセスが変わったときに再実行できるようにしておきます。シナリオライブラリは、個々の検証結果よりも価値があります。

Microsoftのツールはどこに位置付けられますか？

通常、ルーティング、部品構成表、稼働カレンダーはERPシステムに保管されています。そのため、モデルの基礎データの自然な供給元になります。モデル自体は、通常は別のソフトウェアです。

結果を示す用途では、Power BI がシナリオを並べて比較するのに適しています。Microsoft Learn にはwhat-if パラメーターについても解説があります。これは、レポートの閲覧者がスライサーで変更できる調整可能な変数で、変更するとレポートが再計算されます。上の例のような単純な計算、たとえば構成比を変えて能力値が動くのを確認する場合に役立ちます。Microsoft によれば、これらのパラメーターはビジュアル内の指標向けに設計されています。待ち行列はシミュレートできないため、what-if のスライダーをシミュレーションと取り違えないようにしてください。

よくある間違い

• すべてをシミュレートしようとすること。 シナリオが多すぎると、モデルの動作が遅くなり、結果も説明しにくくなります。
• 平均修理時間だけを使うこと。 大きな損害の多くは、長時間の停止によって生じます。
• 構成変更の最終状態だけをテストすること。 途中の過程でボトルネックが移動することがよくあります。
• ベースラインの確認を省略すること。 モデルが先月の状況を再現できないなら、その障害の結果は推測にすぎません。
• 1回の実行結果を信用すること。 ランダムな事象を扱う場合、1回の実行結果では誤った判断につながる可能性があります。
• 人員を考慮しないこと。 障害が人員配置に関わる場合は、欠勤、スキル、残業上限をモデルに組み込む必要があります。
• 一度きりのモデルを作ること。 次のプロセス変更後に誰も更新しないモデルは、数か月のうちに古くなります。

Polarisの位置付け

能力、人員配置、バッファー、製品構成に関する問いがある場合は、iFAKT Polaris も検討候補の1つになります。iFAKT は Polaris を、生産向けの AI とデジタルツインを組み合わせた製品と説明しており、ERP のデータと製造のデジタルツインを統合しています。Polaris Simulator モジュールは、能力、人員配置、バッファーのシナリオや、共有リソース上での動的な製品構成を含めて、生産システムを仮想的に検証します。Polaris Optimizer モジュールはボトルネックを検出し、障害が発生した場合にはその影響を分析して計画を再最適化します。適合するかどうかは、自社のデータと問いによって異なります。まずは範囲を絞った1つのケースで試してみてください。

関連して検討したいトピック

• ライブデータをモデルに供給すること。 デジタルツインは、モデルを工場と接続された状態に保ちます。判断にライブフィードが必要か、それとも優れたモデルだけで足りるかを、まず決めてください。
• 人の対応をモデル化すること。 対応の遅れや交代シフトは、障害が続く時間を変えます。人員配置が問題の一部である場合は、これらをモデルに加えてください。
• 復旧と再稼働。 障害が収束すると、滞留した作業がラインに一気に流れ込みます。残業上限を含めて、再稼働をシミュレートしてください。
• 計画との連携を閉じること。 障害が実際に発生したら、スケジュールを変更する必要があります。シミュレーションの結果が再計画にどう反映されるかを検討してください。

次のステップ

生産シミュレーションにおける障害対応は、自社の停止ログを出発点にすると最も扱いやすくなります。昨年最もコストがかかった障害を一つ選び、停止時間と影響を受けたリソースを含めて一文のシナリオとして書き出してください。そのうえで、次回の計画会議の前に、精度が粗いものでも構わないのでモデルで検証しておきましょう。