Lannerの評価：シミュレーションとデジタルツインのソフトウェアベンダー

著者：Léon Levinas-Ménard

最終更新日：2026年11月4日

現在Haskoningが開発するLannerのWitnessは、製造、物流、サービス業務のシミュレーションソフトウェアである。利用者は資源、物の流れ、待ち行列、運用ルールをモデル化し、設備、能力、配置、日程を変更した場合を比較する。Haskoningはモデル開発、コンサルティング、研修も提供する。(1, 14)

サプライチェーン総合評価：6.0/10。

評価軸	点数
サプライチェーンの理解の深さ	6.0/10
意思決定と最適化の実質	6.4/10
製品とアーキテクチャの一貫性	5.4/10
技術的透明性	6.6/10
ベンダーの真摯さ	5.8/10

Witnessには相応の技術的実質がある。顧客事例は、一見合理的な変更がなぜ性能を悪化させるのかを説明する。車両を増やすと混雑が増え、機械を高速化すると下流の搬送を過負荷にすることがある。最大の貢献は、資本を投じる前にこうした相互作用を計算可能にする点だ。弱いのは、信頼できる工程モデルから反復的な経済判断へ進む部分である。既存の業務とその非効率な計画習慣を忠実に再現できても、それを最も収益性の高い形で変える方法を見つけられるとは限らない。(3, 6, 16)

Haskoningは妥当性確認について説明し、モデル作成ツールへの継続投資を示している。それでも公開事例は、予測誤差、誤った推奨の経済的影響、モデルの有用性を保つための継続作業をほとんど定量化していない。デジタルツインを継続的な意思決定能力として提示するなら、この欠落は重要だ。(8, 9, 11)

LannerとLokadの比較

機械を追加するか、バッファを増やすか、生産の優先順位を変えるかを判断するメーカーを考える。Witnessは、待ち行列、共有資源、滞留、手直し、処理量の変化といった物理的帰結を表すのに適している。たとえばSafranの事例では、個々の部品を加工と品質検査の選択肢に沿って追跡し、リードタイムと投資判断を検討している。(4)

Lokadの方法は、何を買い、生産し、配分し、前倒しするかという反復的な判断から出発し、不確実な将来にわたる経済的帰結を評価する。比較すべきなのは、需要、供給遅延、欠品、在庫に固定された資本を含め、事業全体に関わるトレードオフを計算が金額で評価するかどうかだ。この設計思想は、サプライチェーン入門で展開されている。

Witnessには独自の経済モデルを作る大きな自由がある。その自由は、何を変更可能とするか、確率をどう与えるか、結果をどう評価するか、計算結果をどう行動につなげるかという多くの仕事をモデル作成者に残す。物理的に詳細な工場モデルと財務的な目的は補完的な要件であり、どちらも他方の代わりにはならない。Lokadでも、顧客固有のロジックの維持とサプライチェーンサイエンティストの作業が必要だ。両者は、生成する判断の質と、現実が誤りを示したときにロジックを修正する費用で評価すべきである。

技術の歴史とロードマップの一貫性

歴史からは、見せ方と展開方法を段階的に変えてきた、持続性のあるシミュレーション製品が読み取れる。

時期	文書で確認できる開発	評価
2012年	Winter Simulation ConferenceでのLannerの論文は、プログラム可能な工程要素、原価計算、ヒューリスティック最適化、Six Sigma機能、任意の3D表示を説明する。	計算の基盤はデジタルツインという宣伝より前から存在する。論文は、可視化をコミュニケーション補助と明示し、問題解決の妨げになる場合もあるとする。
2019–2020年	Haskoningが2019年にLannerを買収。2020年7月のHanford事例は、Witness.ioの並列実行と、姉妹会社Ynformedと開発した機械学習分析を説明する。	クラウド提供には、具体的な作業負荷上の利点がある。AIの主張はボトルネック分析を指し、代理モデルはなお開発中と説明される。
2023年	Twinn傘下のWitness 26が、プロパティ編集の高速化と取り消し機能の改善を追加。	モデル保守の仕事に対する具体的な改善である。
2026年	Witness 28が状態報告、実験入力、搬送制御を改善。別の醸造所デモでは、知識グラフとモデル再構築を連携。	リリースは既存のモデル作成工程を強化し、デモはよりプログラム的な保守方法を探る。

出典：(2, 10, 11, 13, 17)。

Hanfordの説明は作業を特定し、導入前後の業務指標を報告している。残る弱点は寄与の切り分けだ。公開結果はデータ準備、並列実行、分析をまとめたもので、機械学習の寄与を分離していない。現在の説明でも代理モデリングは開発作業とされ、その能力を確認する後続のベンチマークは示されない。(7, 17)

2026年1月の記事は、会話形式でシミュレーションにアクセスする方法も提案する。質問しやすくなれば時々使う人には便利だが、チャットボットが経済的に重要な実験を選び、モデルの妥当性を確認し、人間による繰り返しのシナリオ検討をなくすわけではない。技術的により有望なのは、モデルの再構築とテストの自動化であり、その価値は実際にどれだけ保守作業を減らすかにかかっている。(13)

計算が行うこと

非線形な物理的相互作用は実際の強み

Ford Valenciaでは、競合するAGVサプライヤーが大きく異なる車両台数を提案した。Witnessは実用的な構成を見つける助けとなり、その後、特定の周回路に車両を追加しても生産量は増えず、滞留だけが増えると示した。別の実験では、遊休に見える車両を再配分すると組立ラインが止まると分かった。これらはシステム全体の制約を示す実質的な例であり、局所的な稼働率や設置済み能力は投資判断を誤らせることがある。(3)

Britvicのモデルは工場内搬送と敷地内交通を結び付けた。一方通行の通路を採用する結果につながり、新しい瓶詰めラインの人員と運転費用への影響を明確にした。Safranでは一つのモデルが、品質検査、手直し、詳細なリードタイム計算を含む五つの生産ラインを扱った。こうした用途は、静的な能力表で省略されがちな物理的相互作用を扱う。(4, 5)

最適化の仕組みも特定できる。Lannerの2012年の技術論文は、利用者が定義する目的、パラメーター範囲、組合せ制約、反復実行、焼きなまし法とタブー法に基づく探索、他のアルゴリズム用のインターフェースを説明する。この探索は、工程が線形だと装うことなく、不規則なシミュレーション応答を評価できる。しかし、探索対象はモデル作成者が記述した選択肢にとどまる。経済的に重要な行動や費用が欠けていれば、探索を増やしても取り戻せない。(2)

確率的シミュレーションには信頼できる予測が必要

マレーシアの食品生産事例は、処理量の変動、故障、コンベヤーのセンサーロジックを含む。したがってWitnessは、決定論的なシナリオ間で需要値を変えるだけでなく、生産側の不確実性も表現できる。(16)

不確実な入力をサンプリングするのは容易な部分だ。難しいのは、分布、依存関係、将来への妥当性を確立することである。需要成長、機械故障、手直し、サプライヤー遅延をシミュレートするなら、投資や業務判断の価値を変える関係を保持する必要がある。独立な乱数抽出は説得力のある詳細を作りながら、相関した過負荷や供給途絶を見落とし得る。

Haskoningの2025年8月の論考は、理想化されたサイクル時間、未検証の制約、欠けた工程ロジック、古いレイアウトを誤差の原因として適切に挙げる。前提を疑い、実際の業務に照らして段階的にモデルを検証するよう勧める。2024年の方法論も、ソフトウェアの検証と現実のシステムとの比較を区別している。(8, 9)

調査した顧客事例に欠けるのは、予測の信頼性に関する数値報告である。待ち行列の長さ、生産量の変動、リードタイム分布の裾、競合する判断の相対的な性能を、その後の業務でどれほど予測できるのか。デジタルツインは高次元の将来を予測する。前提への合意、魅力的なアニメーション、追加のシミュレーション反復は、その予測が信頼できることを示さない。

この違いは設備投資で特に重要だ。予測したボトルネックの小さな誤りが、どの投資に採算があるかを逆転させることもある。精度はモデルと工場の類似度という一般的な百分率に縮約せず、その判断の境界で、誤った選択の経済的損失とともに評価すべきである。

計画工程の再現は欠陥も保存し得る

DS Smithは、段ボール製造機の計画、下流工程、計画担当者の介入を表すモデルを必要としていた。Haskoningは、紙幅の取り合わせアルゴリズムと、担当者が作業を変更し、生産ロットを分け、保管制約に対応する方法を再現したと説明する。既存組織がどう動くかを予測するには必要だ。しかし戦略上の限界も生まれる。現在の習慣を忠実に再現しても、その習慣を残すべきかどうかは分からない。(6)

次の改善には、既存のスケジュール制御をより良く探索するのではなく、注文のまとめ方、顧客案件の受け方、緊急性への価格付けを変えるなど、別の意思決定空間が必要かもしれない。これはホリミゼーションで論じる問題であり、定式化そのものが進化しなければならない。Witnessにはこのような修正を支えるプログラム能力があるが、その事業価値は単なるシミュレーション速度ではなく、技術的判断と再テストに依存する。

生産性、モデル保守、総保有費用

Hanford事例は有用な生産性指標を示す。80シナリオを扱う問いの処理が、20–25営業日から2–4日に短縮したという。Witness.ioは専用のシミュレーションコアに実行を分散し、専用アプリは入力の扱いと結果処理を減らした。これは明確に定義された分析作業の測定である。同じ説明には、利用拡大に伴ってモデル作成チームが倍増したともあるため、経過時間の短縮を根拠のない人員削減に読み替えるべきではない。(7)

顧客固有のモデル作成は相当なソフトウェア開発作業である。DS Smithのアプリケーションには数百の変数と数千行のコードがあり、その後、過去の生産に照らして一か月の調整を行った。小さな変更でも結果を大きく動かし得た。Haskoningのコンサルティングは、自社専門家による構築と顧客内部の能力育成のどちらも明示的に支援する。研修には上級コースもある。(6, 14, 15)

そのため総保有費用は、ライセンスと計算資源だけではない。業務観察、データ解釈、ルール変更、以前の較正が今も有効かの確認、当初の作者が去った後もモデルを理解可能に保つ作業が含まれる。再利用可能なモデル部品は負担を減らせる。文書化されていない例外は負担を積み上げる。

具体的な改善もある。Witness 28はData TablesからExperimenterへ直接入力できるようにし、実験実行だけのために維持する追加変数を減らす。材料の流れを調べる機能も改善した。新バージョンの利用には有効なサポート契約が必要である。こうした仕組みと義務は、モデル作成は簡単だという大まかな主張より、総保有費用の見積もりに役立つ。(11, 12)

2026年の醸造所デモは、参照工程をAzure Digital Twins上のオントロジーに対応付ける。PythonアプリがXMLモジュール経由で変更を転送し、Witnessモデルを再構築する。物理設備が変わるたびの反復編集をなくせる可能性がある。一方、維持すべき表現がもう一つ増える。グラフ、対応関係、シミュレーションが同じ意味を持ち続けなければならない。公開デモは実運用規模の保守測定も、自動的な妥当性確認の結果も示さない。(13)

ソフトウェア構成とセキュリティ

部品またはインターフェース	文書化された役割と範囲	運用への影響
Windowsデスクトップアプリ	現在のWitness要件は、Windowsのデスクトップ・サーバー版、8 GBのRAM、1 GBのインストール容量を挙げる。	公開された中核のインストール規模は控えめだが、詳細な実験には追加メモリーとコアが必要になり得る。
Witnessロジックと外部ライブラリ	現在の文書は独自ロジックと、C++、C#、VB.NET、Pythonのライブラリをサポート。	モデル拡張は実行可能な依存関係を追加し、独自の保守とアクセス制御を必要とする。
OLE DB、COM、Excel、SQL実験リポジトリー	Lannerの2012年論文は、データアクセス、外部実行、独自インターフェース、保存された実験を説明。	これらの歴史的に範囲の定まったインターフェースは、エンジンの周囲に専用アプリが構築された方法を説明する。
Witness.io	Hanfordアプリはウェブサービスを通じて並列シミュレーションを実行。	並列化は経過時間と計算資源を交換し、入力と結果の管理を必要とする。
Azure Digital Twins、Python、XML	2026年1月の醸造所デモの構成要素。	グラフとシミュレーションの橋渡しは同期作業を増やす。これは文書化されたデモ用アーキテクチャである。

出典：(1, 2, 7, 13)。

主な費用は、モデル開発、妥当性確認、周辺連携の保守である。公開資料は、現在のクラウドサービスの実行・保存アーキテクチャ全体を開示せず、現実的に変化するモデルで実行費用がどう増えるかも示していない。

より直接的なセキュリティ懸念は、実務家が持ち込む外部コードだ。現在の機能ページは拡張言語を宣伝するが、ファイル、ネットワーク接続先、認証情報、依存関係、資源消費への強制的な制限は説明しない。誤ったスクリプトや侵害されたライブラリが、業務データへの無制限のアクセスを継承すべきではない。ローカルのデスクトップ実行にも保護が必要だ。実験用認証情報と本番書き込み権限の分離、制限された実行、復旧可能なモデル状態が求められる。(1)

取り消し機能の改善は編集ミスからの復旧には役立つが、実行コードの隔離にはならない。調査したリリース資料と連携デモは、強制されたサンドボックスや、実験的な拡張を本番接続アプリへ昇格させる管理された手順を文書化していない。(10, 13)

経済成果と責任

実名の事例には、判断に関する有用な証拠がある。Fordは選定したAGV構成での運用と、不要な車両の回避を報告する。Britvicは交通の流れの変更と人員への影響を特定する。Safranは数百万ユーロの投資を支えるためにシミュレーションを使うが、これは評価対象の金額であり、ソフトウェアが生んだ測定済みのリターンではない。(3, 4, 5)

経済成果の全体については、公開証拠がはるかに少ない。導入・維持費、信頼できる代替案に対する実現利益、誤りの費用、推奨が期待を裏切った後の修正などである。詳細な工場モデルは大きな投資に影響し得るが、その投資のリターン全部を生み出すわけではない。

方法論は関係者の参加と前提への合意を重視する。仕事を定めるには有用だが、合意によって誤った前提が正しくなるわけではない。責任を持たせるには、予測、その結果としての行動、観測された結果、両者が食い違ったときに誰がモデルを修正するかの記録が必要だ。公開された方法論は妥当性確認の作業を説明するが、期待利益が実現しなかった際の救済や経済的義務を定めていない。(8, 9, 14)

サプライチェーン評価

25の評価基準はすべて同じ重みとする。

サプライチェーンの理解の深さ

評価基準	点数
経済的な問題設定	6/10
最終的に生み出す意思決定	5/10
サプライチェーンの概念的な明確さ	6/10
時代遅れの中心的教義からの脱却	7/10
KPIの見せかけに対する堅牢性	6/10

平均：6.0/10。

経済的な問題設定 — 6/10。 顧客調査には投資費用と運転費用が入るが、不確実な需要、希少な能力、代替行動の共通評価はモデル作成の課題として残る。リスク調整後の経済最適化よりも、物理的性能の方がよく裏付けられている。(4, 5)

最終的に生み出す意思決定 — 5/10。 事例は具体的な設備・工程の選択につながる。継続実行は依然として利用者が分析を行動に移すことに依存し、文書化された到達点は主に意思決定支援である。(3, 14)

サプライチェーンの概念的な明確さ — 6/10。 モデルは相互作用する流れと資源制限を扱う。主な不足は、その物理的表現を顧客需要、不確実な外部供給、より広いサプライチェーンの経済選択に結び付けることだ。(4, 16)

時代遅れの中心的教義からの脱却 — 7/10。 モデル作成環境は、標準的な在庫分類や合意形成型の計画儀式を要求せず、工程固有の推論を認める。ただし、受け継いだ計画担当者の行動を再現すると、その弱点も残り得る。(6, 8)

KPIの見せかけに対する堅牢性 — 6/10。 公開例は分析と特定可能な業務変更を結び付ける。予測精度と帰属可能な純リターンは大部分が未定量で、説得的な例示と測定された経済的信頼性の間には大きな隔たりがある。(3, 7, 16)

意思決定と最適化の実質

評価基準	点数
確率的モデリングの深さ	6/10
最適化または機械学習の独自の実質	6/10
現実の制約への対応	8/10
意思決定の自動化と労働生産性	5/10
現実の業務の複雑さへの耐性	7/10

平均：6.4/10。

確率的モデリングの深さ — 6/10。 業務上の変動はモデルの一部である。需要と供給の不確実性を共同で較正したことや、得られた判断順位が将来に対して信頼できることは、公開証拠から確認できない。(9, 16)

最適化または機械学習の独自の実質 — 6/10。 探索機構には公開された技術基盤があり、分析の処理系には具体的用途がある。どちらも、広く再利用できる経済判断方針や、独立に測定された機械学習の優位性を示すものではない。(2, 7)

現実の制約への対応 — 8/10。 滞留、品質に依存する経路、共有移動経路は、単純な能力仮定を覆し得る。顧客事例は、それらの相互作用が投資判断を変える理由を示す。(3, 4, 5)

意思決定の自動化と労働生産性 — 5/10。 定義された分析作業は速くなるが、専門家はなお実験を組み立て、結果を解釈し、モデルを維持する。新しい連携デモには総労力の測定結果がない。(7, 13)

現実の業務の複雑さへの耐性 — 7/10。 反復的な妥当性確認は、欠けた挙動を明らかにし、モデルを修正できる。方法は定式化の訂正を支えるが、導入後の失敗から再テストまでの日常的な循環は、公開証拠では確認できない。(6, 8, 9)

製品とアーキテクチャの一貫性

評価基準	点数
アーキテクチャの整合性	7/10
システム境界の明確さ	6/10
セキュリティへの真剣さ	3/10
ソフトウェアの簡素さと総保有費用	5/10
プログラムおよびエージェント支援による運用との適合性	6/10

平均：5.4/10。

アーキテクチャの整合性 — 7/10。 継続的に保守されたシミュレーション中核が、モデル編集、実験、報告を支える。追加のグラフ・クラウド表現は連携上の義務を生み、その費用はまだ定量化されていない。(10, 11, 13)

システム境界の明確さ — 6/10。 中核のモデル作成製品とコンサルティングの役割は明確だ。現在のクラウド実行の境界、顧客コードの責任、本番接続の管理は透明性が低い。(1, 7, 14)

セキュリティへの真剣さ — 3/10。 拡張能力は宣伝されるが、確認可能な隔離は示されない。実務家のコードと依存関係が何にアクセスし、何を変更できるかを強制的に制限する保護が欠けている。(1, 13)

ソフトウェアの簡素さと総保有費用 — 5/10。 比較的小さなデスクトップの資源規模よりも、モデル保守が支配的になり得る。製品は作成効率を改善するが、複雑な専用ロジック、専門家の支援、再検証は継続費用として残る。(6, 11, 12, 15)

プログラムおよびエージェント支援による運用との適合性 — 6/10。 データに基づく再構築は、手作業の編集を超える有用な道を開く。実証された本番自動化と安全なエージェントアクセスは、提案される可能性より限定的だ。(13)

技術的透明性

評価基準	点数
公開技術文書	7/10
ベンダーの仲介なしでの検証可能性	6/10
移植性とロックインの可視性	5/10
導入手法の透明性	8/10
技術的主張を支える証拠の密度	7/10

平均：6.6/10。

公開技術文書 — 7/10。 論文、リリースノート、方法論の記事は、意味のある仕組みを開示する。現在の導入セキュリティとクラウド内部の詳細は、はるかに入手しにくい。(2, 8, 11)

ベンダーの仲介なしでの検証可能性 — 6/10。 公開事例は技術的手法を評価できるだけのモデル挙動を示す。結論の再現には、公開されていない顧客入力とモデルが必要だ。(3, 6)

移植性とロックインの可視性 — 5/10。 外部インターフェースとモデル交換は連携を支える。しかし、顧客工程の実行可能な意味内容を、経済的に別のシミュレーションエンジンへ移せることは示さない。(2, 13)

導入手法の透明性 — 8/10。 対象範囲の定義、データ準備、妥当性確認、実験が、難しい顧客案件とともに説明される。購入者はソフトウェアを完成済みの解決策と見なす前に、相当な責任を把握できる。(6, 8, 9)

技術的主張を支える証拠の密度 — 7/10。 複数事例がモデル化された相互作用と、それによる業務上の選択を説明する。欠けているのは、複数導入にまたがる再現可能な予測誤差と財務的寄与の切り分けである。(3, 4, 16)

ベンダーの真摯さ

評価基準	点数
公開発信の技術的真剣さ	6/10
技術ロードマップの一貫性	7/10
概念的な明確さ	6/10
経済的責任	4/10
エージェント型ソフトウェア時代における競争力の持続性	6/10