全文書き起こし
Conor Doherty: こちらは Supply Chain Breakdown です。今後約30分間、特にサプライチェーンにおけるデジタルツインを巡る誇大宣伝について分解していきます。私の名前はコナー。Lokadのコミュニケーション・ディレクターを務めており、いつものように、左側のスタジオからは言葉を失うほどの存在、Lokadの創設者兼CEOであるJoannes Vermorelが参加しています。
今始める前に、まず下のコメント欄にご記入ください―まずはどちらからいらっしゃったのか、そして次に、デジタルツインについてどう思うかを教えてください。私たちは皆さんの関心事について話し合うためにここにいます。また、質問があればいつでも投稿してください。もしJoannesの発言に対して意見があり、突っ込みたいと思ったら、遠慮なくコメントしてください。約20分後に、私が彼にその質問を投げかけます。
これで無駄な時間はおさらばです。Joannes、デジタルツインの誇大宣伝を取り払って、本題に入りましょう。つまり、基本的かつシンプルな言葉でデジタルツインとは何かを説明してください。そして、少なくとも人々がデジタルツインに解決を期待している問題は何でしょうか？
Joannes Vermorel: デジタルツインとは何かという点についてですが、もしコンサルティングの立場―私が従うものではありませんが―から見れば、彼らはこう言うでしょう。つまり、サプライチェーンを完全なデジタルで正確に表現し、ほぼ何でも未来に予測できるもの、まるでサプライチェーン全体の完璧なシミュレーションを持っているかのようだ、と。少なくともこれがサプライチェーン向けデジタルツインの理想です。
また、デジタルツインの概念は他の領域にも存在し、他の分野では物理システムの非常に正確なシミュレーションが可能な場合もあります。しかし、実際のところ、それは何でしょうか？実際には、単に再パッケージされたモンテカルロシミュレーターに過ぎません。これらのシミュレーターは約40年ほど存在しています。一つの重要な特徴は、それらの実装が非常に容易であり、シミュレーションの精度といった点にこだわらなければ、玩具プロジェクトとしてモンテカルロシミュレーターを実装するのは比較的楽しいということです。
Conor Doherty: 興味深い点をいくつか提起していただいたので、すぐに意見を述べさせていただきます。つまり、少なくとも2つの応用例を挙げてくださいました。一つは、サプライチェーンの文脈でデジタルツインがどのように市場に出されるかというものです。それは一つのカテゴリです。しかし、あなたはより以前から存在する、またはより持続可能な応用例、すなわち物理的な製品に関しても言及されました。その区別点をもう少し詳しく説明していただけますか？
Joannes Vermorel: はい。シミュレーターという概念には主に3つの重要な視点、すなわち「ミクロ分析的」、「離散的」、そして「確率的」があります。モンテカルロシミュレーターを考えると、これら3つの側面があるのです。
ミクロ分析的とは、システムを原子のような、または非常に小さな要素に分解し、それらが単純な法則に従いシンプルな挙動を示すものとして完全に定量化できるという考え方です。これがミクロ分析的な見方です。次に離散的ですが、コンピューター上ではすべてが適切な刻みで動作するものとして仮定します―サプライチェーンの場合、時間の側面も含めてそれは理にかなっています。例えば、「日ごとに一歩ずつ動作するシミュレーターを作る」といった具合です。
そして最後に確率的な側面ですが、一部の挙動には単にランダム性を加えるだけです。これがモンテカルロシミュレーターについて語っている理由です。ある挙動にランダムや確率的な性質を付与し、シミュレーターを何度も繰り返し実行することで、サプライチェーンの将来の状態を予測する、あるいは少なくともシミュレーターを時間の中で前進させることが可能になるのです。そして、それがサプライチェーンのデジタルツインであるはずなので、サプライチェーンの未来を表現していることになります。
Conor Doherty: ありがとうございます。そして、これにより議論が分かれる重要なポイントが再び浮かび上がると思います。たとえば、製造や修理の分野でデジタルツインを使用する場合、「私はデジタルツインを持っている。これは飛行機全体の決定論的な表現である」と言えます。例えば、A320には約320,000個の部品があります。その数は既に決まっており、モデル化も可能で固定されています。これは物理的な既知の製品や資産のデジタルな複製、またはデジタルな表現です。
では、製品やトラックなどの物理的な部品だけでなく、挙動、傾向、政治といった、それらに影響を与える要素も包含する地理的に分散したネットワークであるサプライチェーンに、同じ概念をどれほど適用できるでしょうか？
Joannes Vermorel: 主な問題は、システムの基本単位である原子を支配する法則にあります。物理的な世界では、実際に電磁気学などを適用してシステムの物理的に正確な進化を実現できます。なぜなら、物体を十分に分解すれば、残る部分は非常によく知られた法則に従うと仮定できるからです。もし、様々なチューブを流れる流体を記述したいなら、ミクロ流体力学の方程式があり、有限要素法によるシミュレーションが可能です。
しかし、ここでの重要な洞察は、システムの要素を支配する法則がほぼ完全に既知であると仮定している点にあります。そして、問題となるのはシミュレーションの解像度だけであり、それが必ずしも極めて正確であるとは限らないということです。サプライチェーンにおけるデジタルツインの問題は、実際のところ解像度ではなく、これらの単純な単位―例えばサプライヤーをシミュレーションしようとする場合―の挙動について、いかなる関連する前提知識も持っているとは言いがたい点にあります。それは決して単純なことではありません。
存在しません――この供給業者の挙動について、どれだけ単純な前提を設けても、その対象について前提を捻出したからといって、それが真実になるわけではありません。そして、顧客や倉庫、サプライチェーン全体を繋ぐルートなど、あらゆるものに同じことが言えます。つまり、根本的な問題があります。システムを分解してすべての要素に対して挙動を捻出することでシミュレーターを作成することは可能ですが、その挙動が何らかの正確性を持っているかという点が大きな、非常に大きな挑戦であり、通常、サプライチェーンのデジタルツインにおいては、モデル化の正確性については議論されません。
Conor Doherty: 正確性やその他の指標については後ほど触れますが、もう少し深く掘り下げたいと思います。実際、非常に明確な定義を朗読します。賛否はあなた次第ですが、これは明確な定義であり、あなたの反応を知りたいのです。まだ出所は明かしません―後で推測していただければ―しかし、衝撃的なものです。引用します: “デジタルツインは、製品のアイデア出しと製造から倉庫保管や流通、店舗内あるいはオンラインでの購入から配送および返品に至るまで、サプライチェーン全体における物理的プロセスとデジタルプロセスの相互作用をモデル化するために利用できる。したがって、デジタルツインは最適な end-to-end サプライチェーンプロセスの明確な図を描き出す。” さて、これについてあなたはどう考えますか？どの部分に同意できませんか？
Joannes Vermorel: この定義は、意図以外の何ものも示していません。つまり、「この定義で記述された全ての事柄を最初から最後まで正確に表現するものを持つという意図」でしかなく、それがどのように実現されるかについては何も語られていません。私の主張は、方法が重要だということです。
あなたは数多くの驚くべきツールを発明したり、望んだりすることができます。私が問いたいのは――完璧なAIアシスタントとは何かということです。それは、人間よりはるかに知能が高く、人間ができることをすべて、さらに優れた方法で実行できるものです。さて、私はちょうど完璧なAIアシスタントの定義を行いました。では、それがすぐに手に入るという意味でしょうか？問題は、意図によって何かを定義すると、その実現可能性やそのものが実在するかどうかについては何も示さないという点です。
つまり、私たちは意図としては素晴らしい定義を持っているということです。しかし、私が「Monte Carlo simulator」と言うとき、私は全く正反対のアプローチを取りました。まず、企業が『デジタルツイン』という流行語を使う際、内部で何をしているのかを考察し、私の観察できる限りの答えは、Monte Carlo simulatorであると結論付けたのです。なぜなら実装が極めて簡単だからです。文字通り、初年度のコンピュータサイエンスの学生でさえ、数日で―おそらく賢い学生なら一午後で―それを実装できるでしょう。そして、シミュレーションが実世界とどれだけ関連性があるかを気にしなければ、実装は非常に容易です。
Conor Doherty: 話を戻しますが、あなたは意図について語っています。少なくとも多くの人々が提示するところでは、その目的は――議論のための材料として提示するために――多くのベンダー、コンサルタント、デジタルツインの支持者が、デジタルツインが decision-making を改善すると主張するものであり、実際、Monte Carloを通じてであっても、「もしサプライヤーが遅れたら？もしスエズ運河が封鎖されたら？」といった仮定の scenarios を試すためのサンドボックスを効果的に提供しているというのです。
Joannes Vermorel: 人工汎用知能は定義上、どの企業の収益性も向上させます。もし人間と同等の知能を持ちながら給料が発生しないものがあれば、確かに改善されるでしょう。しかし、ここで問いたいのは、この技術が実際に存在するのか、またその技術的手法は何かという点です。これらの当事者は、それを既成事実として提示します。つまり、既に存在し、すべての望ましい特性を備えていると。しかし、待ってください――内部では一体何が行われているのでしょうか？
そして私の主張は、私の知る限り、デジタルツインを推進している企業は、ほとんどが単純なMonte Carlo simulatorしか持っておらず、私の見解ではそれはおもちゃレベルの洗練度にすぎないということです。確かにそれは魅力的ですし、初年度のコンピュータサイエンスの学生に課すのに適した課題でもあります。実装は楽しく、容易ですが、問題は、再び言いますが、それが全く作り話にすぎないということです。
確かに、あなたはサプライチェーンを SKUs の一覧、顧客の一覧、サプライヤーの一覧に分解し、それぞれのエンティティに挙動を割り当て、シミュレーションを実行させることができます――全くその通りです。しかし、それが実際に正確であるのでしょうか？これは非常に大きな疑問です。一つの例えとして、古いビデオゲーム『SimCity 2000』があります。そこにはマップエディターがあり、実際にパリのように見えるマップを編集でき、パリの道路を正確に配置する（離散化の問題があるため全く同じではないにせよ、ほぼ同様に）ことが可能です。そして、「この地域は住宅地、こちらは工業地帯、もう一方は商業地域」と指定することもできます。はい、それは可能で、ゲームのシミュレーションは進行します。
それがパリの都市環境の未来を正確にシミュレーションできるでしょうか？私の答えは断じてそうではありません――特にゴジラが登場する場合は；それはゲーム内で発生する disaster です。非常に簡単に作成できるからといって、正確なシミュレーションが得られるわけではありません。改めて申し上げますが、シミュレーターの作成は非常に容易で楽しいのですが、本当に問題なのは、なぜそれが何らかの正確性を持つと考えるのかという点です。
物理科学――例えば材料科学などの他の領域では、シミュレーターはうまく機能します。なぜなら、基本的にそれらは非常によく知られ検証された物理法則に従っているからです。つまり、あなたが設定する挙動は捏造されたものではなく、物理学の教科書から電磁気学や流体力学などを適用し、それらが要素や原子を支配する挙動となるのです。しかし、サプライチェーンのデジタルツインでは、それらの挙動を発明・捻出するか、何らかの方法で発見しなければならず、これは非常に厄介な部分です。私の知る限り、サプライチェーン向けデジタルツインのベンダー―それを推進している人々―はこの点について何も語っていません。これが議論の核心なのです。
Conor Doherty: あなたは正確性と厳密性について言及しました。そして、反論させていただくと――ちなみに先ほどの定義はあなたが否定したマッキンゼーのものでした。そして次はBCGの定義ですが――あ、すみません、何か言いたいことがありますか？
Joannes Vermorel: 改めて申し上げますが、問題は彼らが意図のみを記述している点にあります。技術が存在する場合、私は「どのように」それが機能するかに注目することを好みます。達成しようとする意図をもって技術を定義するのは良いですが、それだけではその技術が優れているか否かを論じることはできません。意図そのものには反対しません――意図は良いものですが、問題は、この技術があなたのサプライチェーンにおいて、他の技術と比較して優れているかどうかを識別できる定義があるかという点です。
Conor Doherty: その点で、引用を強調しますが、ボストン・コンサルティング・グループによれば、デジタルツインを持つ企業は予測精度を20〜30%向上させたとのことです。多くの企業がこれを切望しているのではないでしょうか？彼らがこの追求を間違っているのでしょうか？
Joannes Vermorel: 私の知る限り、デジタルツインはどの forecasting competitions にも姿を現したことがありません。予測コンペティションは多数存在し、それらでより良い予測を得るための何十もの技術が採用されています。しかし、デジタルツインが予測に関して何かしらの成果を上げたという話は一度も聞いたことがありません。
ですからご覧の通り、私にとっての問題は、彼らが実際に参照している技術を定義していないため、その内容が何であれあり得るという点です。私の見解――これは実証的な見解ですが――は、デジタルツインをマーケティングしている企業は本質的にMonte Carlo simulatorを構築しており、それらは卓越した精度をもたらすものではないということです。改めて申し上げますが、これらの数値がどのように収集されたのかは不明ですが、実際には予測精度を向上させる可能性のある領域にすら入っていないのが現実です。
Conor Doherty: しかしながら、もう一つ考慮すべき点は、より高い精度が必然的に、デジタルツインを利用して達成しようとしているより良い意思決定につながるものであるかという点です。つまり、手段としての利用と、実際に達成しようとしている目標――目的――があるということです。
Joannes Vermorel: はい。本来、私たちが求めるのは投資収益率の向上を伴うより良い意思決定であるなら、概念的にはデジタルツインはこう言えます。もし方針Aがあれば、それをデジタルツインに通し、その投資収益率を評価します。そして方針Bでも同様に行い、より高い収益率をもたらす方針を選ぶのです。概念的には、問題ない ― なぜだめなのでしょう？
しかし、これらすべてはあなたのデジタルツインが正確な経済評価を提供しているという事実にかかっています。つまり、この精度の問題はドル単位で顕在化します。方針Aの投資収益率があり、方針Bの投資収益率があります。しかし、改めて問います：あなたのデジタルツインには何らかの正確性があるのでしょうか？なぜそれを信頼すべきなのでしょうか？これは非常に複雑な問題です。
SimCity 2000とパリに戻って考えてみましょう。ゲーム内では市の税率を変えてシミュレーションを進めることができます ― ゲーム内にその設定は存在します。しかし、このシステムはパリ市について非常に正確な情報を提供してくれるでしょうか？実際の大都市の進化を正確にモデル化できると考えるのは、明らかに完全に馬鹿げています。これはサプライチェーン向けデジタルツインにおける問題と同じです。多くの要素を加えなければ、単なる希望的観測に過ぎません。
はい、もしこれらすべてを非常に正確に行うシステムがあれば、とても素晴らしいでしょう。しかし、このモンテカルロシミュレーションが突破的な技術でそれを可能にすると言われても、私はそうは思いません。せいぜいそれはごく小さな要素にすぎず、非常に単純なものです。まるで「コンピューターが関与する」という程度の話です。おそらくその通りですが、コンピューターを活用するのは良い考えですし、モンテカルロシミュレーターを使うのも良い手法です。ただし、それはごく小さなもので、私もそれに反対はしません。単に非常に、非常に浅いと言うべきでしょう。ちょうど「車には金属を使う方が良い」というのと同じです。確かに金属は使われますが、それだけで車ができるわけではありません。
Conor Doherty: 長々と話している時間はありません。なぜなら聴衆からの質問もありますし、LinkedInで話題になった内容についても触れたいからです。しかし進む前に、最後にひとつ、技術的な質問をさせてください。デジタルツインが好まれ、非常に人気がある理由のひとつは、それが誇大に売られ、変動性に対処し不確実性に立ち向かう手段としてマーケティングされているからです。私たちLokadや多くの実践者にとっては、確率的予測こそがその方法になると考えています。では、大まかに言って、限界は何でしょうか？あなたの見解では、確率的予測はデジタルツインが残す隙間をどのように埋めるのでしょうか？
Joannes Vermorel: まず、サプライチェーン規模のモンテカルロシミュレーターは、事実上、確率的予測モデルに他なりません。文字通りそういうものです。私たちが「確率的予測」と言うとき、実際にどの下位モデルが使われているかについてはあまり具体的には触れていません。講義では、それらのモデルをどのように構築するかの例をいくつか示しています。しかし「確率的予測」とだけ言えば、モデル自体について何も語っていないのです。
確率的予測モデルはモンテカルロシミュレーターを用いて構築できます。シミュレーションを実行し、実証的な確率分布を収集し、シミュレーションを何千回も行えば、素晴らしい多次元ヒストグラムが得られ、そこから確率分布が得られ、これが確率的予測となります。つまり、モンテカルロシミュレーターと確率的予測には二面性があるのです。確率から偏差を生成でき、それが確率的な振る舞いを示します。しかし、もし確率的な振る舞いがあれば、それを実行して確率分布を得ることもできるのです。基本的には同じことです。
しかし、ここで重要なのは、モンテカルロシミュレーターを確率的予測エンジンとして考え始めると、その精度を評価できるようになるという点です ― これは非常に重要ですが、デジタルツインを推進するベンダーには非常に欠けていると感じています。彼らは、自分たちが持っているものが確率的予測エンジンであるという事実すら言及せず、そのため、確率的予測に関連する指標で精度を評価する必要があるのです。
Conor Doherty: わかりました。この話題は永遠に続けられるかもしれませんが、今回のテーマは特にデジタルツインでした。数日前にLinkedInで「デジタルツインにとって最大の障害は何か？」という投票を行いました。なぜなら、この映像を見ている、または後に見る多くの人々は、この技術の導入を検討しているか、すでに導入している企業だからです。
その投票では、52%の回答者が最大の障害は散らかっているまたは不完全なデータだと答えました。まず第一に ― 数年前にあなたが言っていたことを覚えていますが ― デジタルツインを導入する企業の規模を考えれば、非常に大企業の話です。おそらく彼らは高価で信頼性の高いERPを持っています。では、実装が非常にシンプルだと言われたのに、なぜ散らかっているまたは不完全なデータが障害となるのでしょうか？
Joannes Vermorel: ここで、もし欠落したデータを各エンティティの振る舞い、つまりそれらの振る舞いを特徴づけるものと定義するなら、確かにその通りと言えるでしょう。しかし、例えばERP内に、あなたのクライアントの振る舞いを特徴づけるパラメータが見つかることを期待していたわけではないと思います。ですから、それが人々の意図するところではないのは間違いないでしょう。
私の見解では、データは常にスケープゴートにされます。技術が非常に浅く、約束された成果を上げられなかったとき、必ず悪いデータのせいにされるのです。これはLokadでの我々の経験とは全く一致しません。私の経験では、年間収益が10億ドルまたはユーロを超える企業は、非常に優れたデータを持っています。彼らは何を販売しているか、何を購入しているか、在庫が何であるかをほぼ正確に把握しています。確かに事務的なミスがあったとしても、誤差は0.1%程度です。
全体として、データの正確性に関しては完璧です。商品の流れ ― 取得、輸送、変換、流通 ― すべてがほぼ確実に把握されます。このデータの品質は非常に高いのです。確かに、プロモーションプランなどに関する一部のデータは若干不明瞭かもしれませんが、基本となる取引履歴は優れています。技術的には、シミュレーターを構築するために本当に必要なものはこれだけです。時間と共に進化し取引を生み出すこれらのシステムがあれば、あなたのデジタルツインはそれらを未来に映し出し、システムの将来の状態を予測できるはずです。
しかし、現実はそうではありません。これが問題です。彼らの主張では、そうではないのでデータが非難されるのです。データの問題についての嘆きを聞くたび、私が聞くのは、基本的に不十分な技術がゴミを生成しており、「出力がゴミだ」と言われるのは、入力がゴミだから ― GIGO（Garbage In, Garbage Out）の問題 ― だということです。しかし、もし入力が全く問題なかったらどうでしょう？私の見解では、入力はほぼ完璧であり、過去20年間、大多数の大企業では問題なかったのです。
とはいえ、データに課題が全くないというわけではありません。ERPを見ると1万のテーブルがあり、各テーブルには約50のフィールドが存在します。これは非常に大きな課題ですが、その中のデータがゴミだという意味ではありません。単に、あなたのビジネスシステムが、データサイエンティストとしてのあなたの作業やモンテカルロシミュレーターの構築を容易にするように設計されていないという事実を反映しているだけなのです。これは全く異なる問題です。
Conor Doherty: 問題と言えば、投票者の21%が挙げたもう一つの問題は、脆弱またはバグの多いモデリングでした。以前、これは特に複雑ではなく、初年次のコンピューターサイエンス学生でも扱えると仰っていました。では改めて、数十億ドル規模の企業で、非常に単純なプロセスであるはずの作業なのに、なぜ回答者の5分の1がモデリングの問題を挙げるのでしょうか？
Joannes Vermorel: モンテカルロシミュレーターは概念上非常にシンプルであり、実装面でも非常に直感的です。しかし、すぐに基本的な性能問題に直面するでしょう。説明しましょう。対象となるSKUはどれくらいでしょう？10億ドル以上の企業なら、およそ100万SKUでしょう。つまり、100万SKUとします。
次に、話しているその振る舞いをシミュレートするために、1つのSKUあたり何CPUサイクル必要でしょうか？最小でも10サイクルと仮定し、これが非常に効率的な場合とします。では、何日分をシミュレーションするのでしょうか？1日ずつ実行するシミュレーターで100日間としましょう。大雑把に言えば、100万 × 1,000、すなわち10億CPU操作が、100日間のシミュレーションに必要です。
問題は、これは確率的、すなわち微視的な分析を行う離散的な確率シミュレーターであるため、シミュレーションの実行を繰り返す必要がある点です。信頼できる統計を得るには、分解能の問題から少なくとも1,000回はシミュレーションを行う必要があります。すると、計算量は1,000 × 10億、つまり1兆操作に達します。現代のコンピューターでは大きな問題ではありませんが、並列化など高度な手法を用いなければ、単純なシミュレーターを作る人たちはこのような工夫をすることはありません。ですから、単純な方法で行うと仮定しましょう ― 20分程度の計算時間は決して悪くはありません ― ただし、
しかし、今度はさまざまな選択肢を検証する必要が出てきます。例えば、「このユニットをここに置くべきか、それともあそこに置くべきか？」という具合です。探索するすべての選択肢に対して、基本シミュレーションと試行シミュレーションの両方を実行しなければならず、その計算コストを支払うことになるのです。もし非常に大雑把な懸念、例えば「運転資本のコストが変わったらどうなるか？ 結果だけ知りたい」という場合であれば、2回実行すれば差分が得られるので問題はありません。
しかし、もし「各店舗にいくつのユニットを配置すべきか？」といった詳細な問いを投げかけるなら、答えるためにシミュレーターを何千回、何万回も実行する必要があります ― それぞれの細かい問いごとに1回ずつ。すると、人々は「20分では遅すぎる。何十万回、場合によっては何百万回も実行しなければならない ― 例えばSKUごとに」と気付き、大問題となります。そこで解決策として、SKUレベルで全てをシミュレートするこの微視的な手法を、より集約的なレベルに切り替えることになるのです。
しかし、ここでまた大きな問題が生じます。これまですべては、シミュレーションの最小単位であるSKUレベルでの振る舞いが正確であるという前提に立っていました。既に、振る舞いが容易で明らかであると言うのは過大評価でした。もしこれを配送センター（DC）レベルで集約し始めた場合、配送センターの出入りを支配する正しい法則を見出せると何故思えるのでしょうか？これはあなたのネットワークの非常に複雑な部分です。単純な法則がこれを支配する理由は全くありません。同様に、B2Bのクライアント ― 非常に多様な製品を、様々なタイムテーブルで注文するクライアント ― の場合も同じです。
つまり、このシミュレーターの問題があるわけです。マイクロレベルではシミュレーターは容易ですが、すぐに性能上の問題に直面します。集約は可能ですが、集約するとシミュレーターに正確な振る舞いをさせるという問題が一層深刻になるのです。
Conor Doherty: その点について、初めて聞く人のために補足します。Lokadのもとでの意思決定は、「1ユニットあるので、そこに送るか送らないか」という限られたものではありません。意思決定には無数の組み合わせがあります。例えば、1ユニットを送るか送らないか、片方に1ユニットずつ送るか、2ユニットを一方に、1ユニットを他方に送るか、清算するか、ここで1ユニットの価格を上げるかなどです。ですから、局所的な視点は非常に詳細です。どれほど詳細かというと、顕微鏡で見るようなもの ― それほどまでに細かいのです。
ちなみに、これほどまでに詳細にする理由は、振る舞いのモデリングに戻った場合、経済的結果に信頼を持つためには最も基本的な部分でなければならないからです。ここだけが、この製品の生産コストや1ユニットあたり顧客が支払う金額などを正確に結び付けられる領域なのです。
Joannes Vermorel: その通りです。だからこそ、私たちは最も基本的なレベルに留まるのです。デジタルツインの取り組みは、モンテカルロシミュレーターで性能問題にすぐ直面し、計算しやすい上位の集約レベルに切り替えてしまいます。しかし、そうすると正確な振る舞いを保持する問題が極端に増大し、結果としてシミュレーターは大きく不正確になる可能性があるのです。最初からシミュレーターを信じる理由すら明確でなくなります。なぜなら、その振る舞いを支配する原理が全く作り話だからです。
Conor Doherty: ちなみに、この後の講演で意思決定の価値についても話します ― 最近、Adam Dejans JrとWarren Powellとも議論しました。詳細を知りたい方は最新の動画をご覧ください。続いて、あなたの聴衆が挙げた導入のもう一つの大きな障害はチェンジマネジメントでした。これはほぼすべての技術で一般的に出てくる問題です。しかし、あなたが「鏡像」を用いたと説明したように、うまく機能すれば、既存の状態の鏡像が得られるはずです。では、なぜ既存状態の鏡像が広範なチェンジマネジメントを必要とするのでしょうか？
Joannes Vermorel: もし、―正直言ってこれらの技術を推進する企業が本当に持っているかどうかは疑問ですが― 将来のサプライチェーンの状態を高次元で予測できるシステム、すなわちデジタルツインが目指す理想を手に入れたとします。すると興味深いのは、エンドツーエンドで実現されれば、もはやサイロは存在しなくなるということです。各サイロにおけるすべての政策変更の効果を文字通りシミュレーションでき、その結果、企業全体の投資収益率が得られるのです。これは非常に魅力的なものです。私はそれを否定しません。Lokadも全く同じ路線を歩んでいます。
再び考えると――従って、莫大なチェンジマネジメントが必要になる――もし会社全体のサイロを回避できる技術を持っているなら、あらゆる場面で課題が生じるでしょう。突然、「例えばこの部門で採用されている方針が、実は会社全体にとって有害である」という事実に気づくかもしれません。ある部門のKPIが改善されても、全体のパフォーマンスを犠牲にしているのです。ですから、チェンジマネジメントや抵抗にかかるコストは自然と非常に高くなると考えられます。この点は合理的だと思います。
Conor Doherty: ジョアンネス、私たちは約35分ほど話してきましたし、実際にいくつかの質問に答える必要があります。すぐに聴衆からの質問に移りますので、終了前にどしどし質問をお寄せください。しかし、このセクションの締めくくりとして、これまで議論してきた全てを踏まえ、この技術の導入を試みているか、または導入を検討しているサプライチェーンマネージャーや経営幹部への最後のアドバイスは何でしょうか？
Joannes Vermorel: エンジンルーム、つまり内側に何があるのかを真剣に見極める必要があります。私の見解では、「デマンドセンシング」と同様に、サプライチェーン界隈には他にも流行語が存在しますが、デマンドセンシングの場合は何もないのに対し、デジタルツインの場合は大抵、何か少しだけ存在します――つまり、単なるモンテカルロシミュレーターに過ぎません。しかし、本当に重要なのは、そのエンジンルームの中身を問い直すことです。
確かに、上にあらゆる魅力的なユーザーインターフェースを構築することは可能です。洗練されたグラフィックスを用いることもできますし、地図を配置してアニメーション化することも可能です。そういったのは夢を売っているにすぎません。本当に確認すべきは、その中身が何であるかです。機械への共感を働かせ、「なぜこれが機能するのか、数値的に説明してください」とベンダーに求めるべきです。そして意図と結果を混同してはいけません。多くの人は「これがあれを最適化する」と言いますが、ちょっと待ってください。あなたは利益、つまり成果そのものを最適化しているのです。私は結果について尋ねているのではなく、会社にとって非常にプラスの効果があると謳っているその背後で、数値的にどのように実現されるのかを教えてほしいのです。
調査してください。もし最終的に、これは単にハードコードされたルールが順次適用されるモンテカルロシミュレーターであると判明したならば、言わば皇帝の裸であると言えます。非常に、非常に浅薄なものに過ぎないのです。
Conor Doherty: 自分の考えを締めくくるにあたり、最初に話していたように、これは私が参加する前からのあなたとの会話でした。2022年8月、このテーマについて「デジタルツインに対する私の認識は、単なる流行語の一つであり、過大評価されたシミュレーターに過ぎない」という趣旨の発言を伺いました。では、締めくくりとして、この3年間、その言葉を守り続けていますか？
Joannes Vermorel: 「デジタルツイン」という意図そのものについては、実際に技術的な実体を伴った提案をしたベンダーを見たことがありません。意図そのものには異議を唱えません。もし明日、誰かが「私はデジタルツインを持っていますが、単なる素朴なモンテカルロシミュレーターではなく、驚くべき新技術を採用しており、その青写真もお見せします。非常に洗練され、素朴なモンテカルロ方式を凌駕する方法で動作します」と言ったならば、私は「はい、絶対に、もしかすると本当に有用かもしれません」と言うでしょう。
まるで、誰かが「AGIは非常に優れている」と言い、「はい、AGIは素晴らしい。でも実際に持っていますか？」と問い返すかのようです。ですから、私はその意図自体には異議を唱えません。しかし、基盤となる技術群には厳しく疑問を呈しています。そして現時点では、3年たってなお、私が注目すべきと考える技術を提案するベンダーを見たことがありません。
聴衆の皆さんからも何か提案があればぜひ伺いたいのですが、どのベンダーか、あるいはどなたかが「ジョアンネス、こちらの技術をご覧ください。確率シミュレーションの最先端を推進する、本当に注目に値する技術です」と言った例はありますか？私は、ぜひとも耳を傾けたいと思います。今のところ、そのような技術は見たことがありません。
Conor Doherty: これはオープンチャレンジです。もしジョアンネスに何か共有したいものがあれば、ぜひ彼に連絡してください。さて、ジョアンネス、聴衆からの質問に移ります。いくつか質問があります。長いものもあるので、注意してください。
Philipより：例えば、スエズ運河での事件を例にとりましょう。通常の交通状況を考慮して、私のモデルがオーストラリアからフランスへの商品の輸送に1か月のリードタイムを見積もったとします。しかし、以前のように突然船が運河を塞いだ場合はどうでしょうか？モデルはそのような混乱を予測できず、その結果、深刻な遅延と困難に見舞われることになります。質問です：サプライチェーンのモデリングにおいて、このような予測不可能な事象にはどのように対処すればよいのでしょうか？
Joannes Vermorel: 素晴らしい質問です。実際、ここで使われるモンテカルロシミュレーターは、決して悪くない洞察を提供しており、それはLokadが採用しているアプローチと同じものです。これはプログラム的な手法です。モンテカルロシミュレーターは本来、プログラム的なパラダイムであり、比較的一般的なプログラミング言語を用いて、振る舞いを特徴づけるルールを実装するものなのです。
Lokadでは、その実装方法として、多くの振る舞いが過去のデータから学習されます。しかし、それはプログラムであるため、そのプログラムに介入し、意図的かつプログラム的に変更を加えることが可能です。なぜ必要かというと、運河の問題で影響を受けるサプライヤーに対して、見積もりリードタイムを選択的に引き上げることが確実に行われる必要があるからです。
例えば、アジアのサプライヤーが航空輸送を行っている場合、彼らのリードタイムを引き上げる必要はありません。したがって、非常に注意深く、過去のデータから船便に該当するリードタイムを持っていたサプライヤーを確認するか、すでにその情報がある場合に、プログラム的に追加の調整を行う必要があります。ここでプログラム的なアプローチをとることは大きな利点です。デジタルツインの分野でも、Lokadと同様にプログラム的な視点から問題に取り組んでいると考えています。この点については良い方向に進んでおり、すべての状況に対応するために単にメニューやボタンを備えた非プログラム的手法と比べると、状況は実際により明確です。モデルの中核にプログラミング言語を持っていれば、予測不可能な事象に合わせたカスタムルールを常に実装できるのです。
Conor Doherty: ありがとうございます。次に、Manuelからの質問です。「理論上、この技術であるデジタルツインは、サプライチェーンにおける意思決定支援に大きな影響をもたらす可能性があります。この技術の進化とその潜在能力の実現についてどうお考えですか？」 少しは触れたかと思います。
Joannes Vermorel: サプライチェーンをエンドツーエンドでモデリングするという発想は、インスピレーションに溢れる素晴らしいアイデアです。Lokadもこの路線を追求しています。そのために必要な重要な要素は何でしょうか？要素は数多く存在します。例えば、差分可能-プログラミング、確率変数の代数、リレーショナル代数などが挙げられます。必要な要素は山ほどあります。
モンテカルロシミュレーターという考え方――ちなみに、Lokadにもモンテカルロのコンポーネントが存在します――は、非常に興味深い取り組みを可能にします。もしランダムな振る舞い（意図的にランダムなもの）がモンテカルロプロセスの一部であれば、デバッグの面で非常に微妙な問題が生じます。プログラムを実行するとクラッシュし、再実行するとクラッシュしない――このように断続的に現れるバグは、詳細に調べようとしても消えてしまうのです。Lokadではこれらの問題を「Heisenbugs」と呼んでいます。すなわち、断続的に発生し、詳しく調査すると一時的に消えてしまうバグです。
これは、古典的かつ単純なモンテカルロシミュレーターの取り扱いにおける大きな欠陥です。90年代初頭に金融業界で経験された問題でもあります。求められるのは疑似乱数ではなく、実際にモンテカルロシミュレーションを行っていても完全に決定論的な振る舞いです。これには比較的巧妙な技が必要です。また、分散コンピューティングを行う場合でも、この決定論的性質が保たれなければなりません。つまり、多くのCPUやマシンで並列に処理する場合においても、シングルCPU・シングルスレッドで起こるようなパフォーマンス問題に直面しにくくなります。問題ありません。多くのCPUやマシンにスケールアウトできるのです。しかし、それにはバグやクラッシュがあった場合でも、システム全体が完全に決定論的であるツールが必要となります。
私の考えでは、最終的にこれらのデジタルツインを実装するための技術的要素は多岐にわたります。Lokadがその多くを提供していることを期待しています。私が言いたいのは、こうしたバズワードで自らを売り出す人々は、本質的な実体をあまり伴っていない、という点です。非常に浅薄であり、実際にデモを頼んでみると、非常に単純で素朴なモンテカルロシミュレーションでしかない、という現実が見えてくるのです。それでは、これらの期待に応えることはできません。
Conor Doherty: 第三の質問への完璧な移行です。ありがとうございます。Shashankから――発音を誤っていたらすみません――「ジョアンネス、サプライチェーンネットワークにおいて、モンテカルロシミュレーターとエージェント型確率モデルのどちらについてどうお考えですか？」
Joannes Vermorel: 角度は幾通りもあります。モンテカルロは非常に有用なツールであり、数値的なトリックです。線形代数と同じように、基本的で根本的な技法であり、それ自体は非常に有用です。しかし、モンテカルロシミュレーターにおいて重要なのは、シミュレーションされる振る舞いそのものに知性が宿るという点です。基本的に、モンテカルロシミュレーターは、「100万の項目があり、まず1番目の項目を取り、振る舞いを適用して、非決定論的な偏差を得る。次に、2番目、3番目と、各項目・各期間に対してこれを繰り返す」というプロセスなのです。
重要なのは、その詳細な振る舞いであり、そこが本当に非常に複雑な部分となります。モンテカルロという数値的トリックの利点は、サプライチェーンという非常に定量的で高次元の世界にうまく適合する点にあります。一方、エージェント型AI、具体的には大規模言語モデル（LLM）は、シンボルの系列、すなわちトークンの系列を扱うものです。
保有しているデータとの適合性という面では、必ずしも明確ではありません。LLMはサプライチェーンシステムに直結するものとは言いがたく、私の見解では、将来のサプライチェーン技術においても、モンテカルロシミュレーターは10年後も存続するでしょう。なぜなら、これは基本的な構成要素だからです。まるで、システムに平方根があるかと問うのと同じです。もちろん平方根はあります。一方、LLMのようなエージェント型AIは役割があると思いますが、その役割はサプライチェーンの定量的評価そのものにはあまり現れず、顧客、サプライヤー、あるいは第三者とのテキストベースのインタラクションといった周辺部に位置するでしょう。そうしたものは、データの補完や一部の相互作用を実現する方法ではありますが、最適化の中核ではありません。
Conor Doherty: ありがとうございます。次はTaoからの質問です。「あなたの見解では、デジタルツインの本当の問題点は、現在使用されているサプライチェーンシミュレーションツールに欠陥があるという点なのか、それともサプライチェーン最適化に適した正しいツールは、そもそもデジタルツインを必要としないという点にあるのでしょうか？」
Joannes Vermorel: まさに最初の理由です。これらのツールには欠陥があり、その欠陥は非常に特定の形で現れます。これは、非常に浅薄で実装が容易なツールなのです。多くの人は、enterprise softwareの世界では、取締役会やCEOとの交渉が成立した途端、実質的には何も提供していなくても、価格が非常に高額になる誘惑があると考えがちです。奇妙に聞こえるかもしれませんが、エンタープライズソフトウェアの世界では、実際に何を売っているかに関わらず、年額100,000ドル以上で販売されるのです。
つまり、市場には「見てください、これが私の持っているものです。そして、十分な盛り上がりを作り出せれば、いくつかの企業がそれに対してお金を払うでしょう」と主張する事業者が次々と現れます。彼らの規模では、それはごく僅かなものです。もしあなたが10億ドル以上の企業で、何かのガジェットに年額100,000ドルを支払ったとしても、大した問題にはならず、収益性を脅かすこともありません。しかし、その結果、CEOや取締役会、一般のCレベル役員は、特に価格が天井知らずでない場合、自分たちが正確に何を買っているのかの詳細まで掘り下げる時間が必ずしも取れないのです。エンタープライズレベルでは、100,000ドルは決して高額ではありません。この価格帯で、10億ドル規模の企業のCEOがそれを検証するために数日を費やすことはなく、非常に迅速な意思決定が求められるのです。
その結果、残念ながら、非常に単純で実装が容易な技術を提示しつつも、そのパッケージング技術に長けた事業者が多く現れるのです。たとえば、あなたにはモンテカルロシミュレーターがありますが、率直に言えば、それは何もない、いわば無に等しいもの――しかし見た目は非常に立派です。そして、「これこれを最適化し、製造などの全てにおいて改善するものが欲しくない人がいるだろうか」という定義を付け加えます。はい。そして「我が社全体を向上させるこのウィジェットの価格はいくらか？」と。答えは「例えば、100,000ドル」。そうすると、「これは非常に安い。試してみよう」と。
しかし、私のメッセージは、エンジンルームの中身、すなわち実際に何が詰まっているのかを調査することにあります。本当に実体があるのか？ パッケージングだけでは不十分です。私が見ているのは、あるパターンです――「デジタルツイン」はパッケージで出現しました。一度、他のベンダーが同様のパッケージを用いているのを見れば、そのパッケージの模倣は容易です。なぜなら、それは文字通り外側に見えるものだからです。中身が単なるモンテカルロシミュレーターであれば、ソフトウェアエンジニアを雇えば数日で実装可能なものだからです。
これらすべての要素が組み合わさり、適切なパッケージをもって市場に出る誘惑が生まれ、全てのCレベル役員にアプローチし、運が良ければ一連の契約が成立し、ビジネスが確立されるのです。私が言いたいのは、これがエンタープライズソフトウェアの領域で見られる典型的なアンチパターンだということです。
Conor Doherty: ありがとうございます。そしてジョアンネス、これは最後の質問です――答えは予想できる気もしますが、Murthyからの質問です。「デジタルツインは、受動的なモニタリングツールから、実際のエンタープライズエコシステムにおける積極的な意思決定支援エージェントへとどのように進化していくべきだとお考えですか？」
Joannes Vermorel: まず、この定義と私がちょうど提示した技術的なレイアウトにおいて、何がデジタルツインを受動的ではなく能動的にしているのでしょうか？ 概念上は、何もありません。この超詳細でエンドツーエンドなシミュレーターを使って、サプライチェーンで実施しようとしているあらゆるポリシーに能動的に挑戦しない理由があるでしょうか？ 明らかに、この仕組みは能動的であるべきです。
So, if the way it is used in practice is not proactive, then we have to ask why. On paper, a Monte Carlo simulator: you have something that is decently accurate and representative of your supply chain and its future state; you can—because it’s programmatic—inject any kind of policy in it. Fantastic. That means you can challenge everything; obviously it’s meant to be proactive.
But it isn’t. Why is that? Analyze from a software angle: what are they doing, how is it implemented? That will give you the answer. The answer is: we are back to one million SKUs, 10 CPU cycles, 100 days, etc. You end up with: yes, this thing can give you a simulation of what will happen, but unless you make substantial engineering efforts—which those vendors do not do—you will get one answer per, let’s say, 20 minutes, or even per one hour if it’s not super well implemented.
Suddenly you realize you have a problem, because how can you pilot anything forward when you have this sort of performance issue? I’m not even talking about the modeling accuracy problem—just basic performance in terms of compute resources that you need to inject. That’s a problem that is very real. That’s why people end up with a very reactive take, because they realize the whole thing is super slow. You are essentially trying to ask millions of questions to your system, but if you need to wait 20 minutes for every single answer, it’s incredible—and you have to ask those one million questions every day.
You end up with very basic problems. If you re-aggregate the data, then suddenly you cannot ask questions that really matter, because you are at an aggregation level that does not reflect the decisions that you have to take anymore, such as: “Do I need to produce this? Do I need to move the inventory there? Should I raise the price of these products?” Suddenly, if you’re at an aggregated level—for example, if you want to reason about the pricing of a product category—it doesn’t really make sense to say, “I’m going to increase the price or decrease the price for all the products in this category.” You probably want to differentiate based on the characteristics of every single product. But again, that goes against the idea of aggregating everything.
Conor Doherty: As a quick plug, I know you cover extensively the concept of decision optionality inherent to the flow of physical goods—your definition of supply chain. That’s covered, I think, in Lecture 1.2, “Supply Chain in a Nutshell.”
That’s literally the first—okay. Well, watch the first two if nothing else, because then you get to “Quantitative Supply Chain in a Nutshell.” That’s pretty good—better than pretty good. Anyway, Joannes, we’ve been going for an hour. We’re out of questions, and now we’re out of time. As always, thank you very much for joining me and for your answers.
And to everyone else, thank you for attending. Thank you for your questions. If you don’t already, follow Lokad on LinkedIn, please. And if you aren’t connected with us, send us a connection request. We’re always happy to discuss supply chain issues. And on that note, to everyone, I say: get back to work.
