00:00:00 インタビューの紹介
00:02:15 確率的予測とサプライチェーンの最適化
00:04:31 確率的最適化と意思決定
00:06:45 確率的最適化の要素：変数、制約、損失関数
00:09:00 モデリングと最適化に関する視点
00:11:15 最適化における制約と最悪のシナリオ
00:13:30 不確実性、制約、そして不十分な解
00:15:45 決定論的最適化と多様なシナリオ
00:18:00 MROオペレーションと在庫最適化
00:20:15 リードタイムと修理可能な部品における不確実性
00:22:30 部品欠品の影響と従来手法の限界
00:24:45 サプライチェーンにおける確率的要素と人為的な確率性
00:27:00 航空機エンジンの修理と部品調達
00:29:15 在庫最適化と確率的部品表
00:31:30 サプライチェーン最適化と反応性に関するポリシー
00:33:45 サプライチェーンにおけるスケーラビリティの問題と凸関数
00:36:00 サプライチェーン問題における問題の緩和と制約
00:38:15 サプライチェーンにおける局所探索ツールと実現可能な解
00:40:30 メタヒューリスティックな遺伝的アルゴリズムとスケーラビリティの課題
00:42:45 スケールの問題としての数学的最適化
00:45:00 ロコドによる確率的最適化技術の開発
00:47:15 サプライチェーンにおける相互依存性と資金による問題解決
00:49:30 棚制限の制約とヨーグルト在庫の例
00:51:45 確率的最適化と不確実性の要約
00:54:00 サプライチェーン最適化におけるソルバーの役割
00:56:15 「ソルバー」という用語の明確化と最終決定の計算
00:58:30 ソルバーの解に疑問を呈し、その潜在的な欠点を指摘
01:00:45 主なポイント：確率的最適化の重要性
01:03:00 サプライチェーンにおける不確実性の無視と優れたソルバーの利点
01:05:15 非自明なサプライチェーンにおける依存関係と相互依存関係
01:07:30 インタビュー終了
概要
ロコドのCEOであるジョアネス・ヴァーモレルと広報責任者コナー・ドハーティとの議論の中で、確率的最適化と確率的予測が供給チェーン管理において重要であることが強調されている。ヴァーモレルは、損失関数(loss function)が不確実であるという確率性の概念を説明する。これはサプライチェーンの状況でよく見られる現象である。彼は数学的最適化の三要素である変数、制約、損失関数を概説し、確率的最適化においては損失関数が決定論的ではなくランダムであることを説明する。ヴァーモレルはまた、サプライチェーン向けの数学的最適化技術のスケーラビリティの問題について、過去40年間の障害となってきたことを論じる。そして、確率的最適化がサプライチェーンの教科書でしばしば見落とされがちな重要な側面であると強調して締めくくる。
ロコドの広報責任者コナー・ドハーティとCEO兼創業者のジョアネス・ヴァーモレルとの会話では、二人はサプライチェーン管理における確率的最適化と確率的予測の複雑さについて掘り下げる。ヴァーモレルは、サプライチェーンを最適化するために不可欠な、明確で定量化された未来予測の重要性を強調する。彼は、損失関数が不確実またはノイズを含む状況、すなわち確率性の概念を紹介する。これはサプライチェーンの状況でよく見られる現象である。
ヴァーモレルは、損失関数が経済ドライバーを通して表現され、ビジネスにおけるリスク額を反映するために微調整されると説明する。彼は、効果的な確率的予測があっても、サプライチェーン管理に内在する不確実性と非線形性のために最適化が依然として必要であると主張する。彼は数学的最適化の三要素、すなわち変数、制約、損失関数を概説し、確率的最適化では損失関数が決定論的ではなくランダムであることを説明する. ヴェルモレルは、数理最適化における制約の概念についてさらに詳述し、これは受け入れられない解を表現する方法であると説明します。彼は、これらの制約がロス関数と同様にビジネス戦略と整合しているべきだと強調します。また、制約は数学的に真か偽かという問題ではなく、単に存在するものだと述べています。例えば、最大容量が100単位であるというのは、数学的に有効なものではなく、単に与えられた条件に過ぎません。彼は、確率的な世界では制約が数学的により微妙になり、納期などの要因のばらつきのために常に厳格に遵守されるとは限らなくなると説明します。
メンテナンス、修理、オーバーホール（MRO）企業の文脈では、ヴェルモレルは在庫最適化が極めて重要であると説明します。部品表は確率的なものであり、もし一つの部品が欠けていれば、そのコンポーネントは修理できません。Lokadは確率的予測を利用して、部品の到着や修理に必要な部品を予測します。部品購入に関する意思決定では、返却される部品や潜在的なスクラップ率も考慮に入れる必要があります。目的は部品購入の問題を解決することです。
ヴェルモレルは、部品を個別にではなく一体として考慮する確率的最適化アプローチの必要性を強調します。特定のユニットの組み合わせを取得する際の経済的価値は、部品を一つ一つ分析する場合とでは大きく異なる可能性があります。彼は、修理を行う人間の能力の確率性もこのモデルに組み込むことができると確認します。
ヴェルモレルはまた、サプライチェーン向けの数理最適化技術のスケーラビリティの問題について議論しており、これが過去40年間にわたって足かせとなってきたと述べます。彼は、サプライチェーンで直面する問題は必ずしも整然としておらず、これらの技術のスケーラビリティは、すべての制約が適用された後に残る余地の大きさに依存すると説明します。さらに、解空間除去手法に依拠するソルバーは、変数が千を超えると性能が著しく低下することに言及しています。
ヴェルモレルは、サプライチェーンに適した規模でこれらの問題に対処するため、Lokadが確率的最適化のための新たな技術クラスを開発する必要があったと説明します。彼は、ドハーティのまとめに同意し、確率的最適化が従来の数理最適化と比べ、より柔軟かつ反応的な意思決定の最適化手法であると述べます。また、これらの問題に対応するためには、ソフトウェアコンポーネント、すなわちソルバーが必要であると指摘します。
ヴェルモレルは、ソルバーがLokadのクライアントに提案される最終的な意思決定を生成することを確認します。彼は、ヒューリスティックを含む様々な最適化アプローチが存在するものの、ソルバーこそが予測を入力として解を生成するツールであると説明します。また、「数値的レシピ」とはデータ抽出パイプラインから結果生成までの処理連鎖を指し、「ソルバー」とはその予測を入力として最終的な意思決定を計算するプロセスを意味すると述べています。
ヴェルモレルは、確率的最適化がサプライチェーンの教科書でしばしば見過ごされがちな極めて重要な側面であると強調しつつ締めくくります。彼は、既存の大手企業が決定論的最適化問題向けのソルバーを販売し、サプライチェーン特有の不確実性を無視していることを批判します。そして、サプライチェーン全体とその相互依存性を包括的に捉えることが可能な確率的ソルバーの利点を際立たせています。
完全な文字起こし
Conor Doherty: 確率的最適化は、経済的に実現可能な意思決定を定量化し、最終的に最適化するための手段です。その重要性や動作の仕組みについて議論するために、Lokad創設者のジョアネス・ヴェルモレルがここにいます。ジョアネス、多くの人は私たちが様々な文脈で何度も最適化という用語を耳にしており、それが確率的予測と同時に語られるのを見てきたと思います。なぜなら、結局のところ、これら二つが私たちの主要なツールだからです。では、確率的最適化の数学的側面に入る前に、これら両方のツールの経営者レベルでの概要と、その重要性について教えていただけますか？
Joannes Vermorel: 確率的予測とは、未来を明確かつ定量的に予測することを意味します。つまり、サプライチェーンを最適化するには、未来に関する何らかの情報が必要です。定量化された情報を持つことが必要なのです。確率的予測は、未来を知ると同時に、知らない部分を認識し、不確実性を定量化することでもあります。これにより、先に何が起こるかを理解し、より情報に基づいた意思決定が可能になるのです。
次に、より良い意思決定を行うことが求められます。それはどういう意味でしょうか？何に基づいて「より良い」と言えるのでしょうか？ここでの最適化は、単に物事を改善するというゆるやかな意味での最適化もあれば、数学的な意味での最適化もあります。数学的意味での最適化とは、与えられた問題に対して、数値基準に従い損失をより小さくする解を見つけることを意味します。ここでは、損失を最小化するという視点に立って話を進めましょう。
この意味での最適化は、純粋に数学的な操作であり、つまり、与えられた問題に対して自ら設定した損失関数を最小化する解を見つけることに尽きます。
Conor Doherty: 例えば、この意思決定の結果であまり多くのお金を失わないようにする、ということですね。
Joannes Vermorel: つまり、サプライチェーンの場合、基本的な意思決定は何単位注文するかということです。そして、選んだ数量ごとに、保管コストや品切れのペナルティが生じます。当然、製品を利益を得て販売することによって得られる利益もあり、これは一種のマイナス損失として扱われ、実際に製品を販売することでさらに損失を最小化することが可能です。
Conor Doherty: なるほど、制約について話すときは大体の人は納得すると思います。しかし、確率性はどこにあるのでしょうか？最適化はできるのに、さっきの説明には確率性が見受けられませんが。
Joannes Vermorel: ここでいう確率性とは、損失関数が不確実でノイズを伴う問題のことを指します。例えば、非常に古典的な在庫補充の問題において、今日再注文する数量を決めたとしても、その決定から得られるスコアや損失は後になって初めて明らかになるのです。現時点では最終的な損失がどうなるかは不確実なままです。したがって、損失関数が事前に確実に知られていない状況では、すべてが完全に把握されている古典的な決定論的最適化問題とは異なり、確率的最適化問題が発生するのです。
もしコンポーネントの配置を行う場合、例えば、箱の中に異なるコンポーネントを収める際に各コンポーネントの物理的寸法をすべて考慮するのであれば、これらはすべて完全に既知であり、不確実性は存在しません。完全な組み合わせを見つけるのは非常に困難な場合もありますが、サプライチェーンの状況とは異なり、不確実性はありません。サプライチェーンの状況は、むしろ極めて確率的であり、何らかの不確実性が伴う状況であると言えます。
確率的予測は実際にこの不確実性を内包していますが、何かを解決するものではありません。ただ、これが未来であり、不確実性がこれであると示しているだけです。これは意思決定プロセスや、いかなる意思決定生成プロセスでもありません。その部分が最適化、特に確率的最適化に該当します。
Conor Doherty: では、そのような不確実性を踏まえた上で、どのようにしてその損失関数を微調整するのでしょうか？
Joannes Vermorel: 損失関数は非常にシンプルです。Lokadでは、経済的ドライバーを通じてこれを表現しており、すなわち誤差のドル額を最小化することに他なりません。この損失関数をビジネスに十分適合させ、実際のリスク（ドル額）を反映させるためには、多くのノウハウが必要となります。私たちは二つの独立した側面を持っています。一つは、ビジネス戦略に完全に忠実な損失関数を見つけることであり、これは特別な数値最適化の技能を必要とせず、単にビジネスを反映するものがあるかどうか、基本的な算術演算によって十分なのです。それは特別なものではありません。もう一つは、与えられた損失関数に対して必要な確率的最適化を実行することです。
Conor Doherty: ところで、非常に優れた、または効果的な確率的予測を行った場合、最適化の部分を完全に省略できるのではないでしょうか？もし、何をすべきかや需要がどれほどあるかをより正確に把握できていれば、他の要素をバランスさせる必要はないのでは？予測された量、あるいはもっとも可能性の高い結果の量をただ注文すれば良いのではないでしょうか？
Joannes Vermorel: もし未来を完全に把握できていたなら、確かに意思決定の部分はそれほど複雑にはならなかったでしょう。しかし、そのような状況下でも、最小発注量や定額の注文コスト、定額の輸送コストなどに対処しなければならず、未来を完璧に知っていたとしても、すぐに単純な解が得られるような非線形性が数多く存在するのです。
しかし実際には、未来についての知識が非常に不完全であるため、状況はそれどころかはるかに悪化しています。不確実性を完全に排除する予測が得られるという評価は全くもって不合理です。不確実性はある程度低減できるものの、大部分は解消不可能です。したがって、この不確実性とともに生きるしかなく、明らかな解決策は存在しません。得られる明確な解決策はありません。
Conor Doherty: では、少し話を戻して確率的最適化についてですが、あなたは構成要素について語りました。損失関数を挙げましたが、損失関数だけが確率的最適化に必要な唯一の要素ではありません。では、これに必要な要素はどのようなものなのでしょうか？
Joannes Vermorel: 数学的最適化に取り組む際、基本的に3種類の要素があります。第一は変数です。変数とは、基本的にあなたが選ぶことができるものです。これが解決策を定義し、あなたの解は変数の特定の組み合わせとなります。
例えば、南京錠の正しい組み合わせを見つけるという離散的な問題を考えると、仮に4つの変数があり、各変数は10通りの位置を持ち、すべての組み合わせが潜在的な解を定義します。あなたは、ロックがカチッと開く一つの正しい解を見つけたいのです。
最初の要素は変数です。サプライチェーンでは、変数が整数であるため、しばしば離散的な問題が扱われます。0ユニット、1ユニット、2ユニット、3ユニットの発注は可能ですが、通常0.5ユニットの発注はできません。この離散性が問題を難しくしており、ある解から別の解へ容易に移行できず、非常に非線形なパターンが多く発生します。
例えば、0から1ユニットへの変化は、微小な分数単位の変化とは全く異なります。また、MOQ（最小発注量）のような制約があり、解にたどり着くためには、仮に100ユニット先にジャンプしなければならない場合もあります。
Conor Doherty: それは制約ですね。
Joannes Vermorel: そして次に、第二の要素である制約についてです。通常、変数とともに制約が提示されます。制約は、解が受け入れ可能かどうか、実現可能かどうかを示すための変数に対する数学的表現の集合です。
つまり、補充のケースでは、希望するユニット数を再発注することはできますが、棚には有限の容量しかありません。棚に置けるユニット数には限りがあり、1日に店舗で受け取られ、処理される、または倉庫に取り込まれる商品の最大受入能力が設定されている場合もありますし、サプライチェーン内の他の場所に対しても同様です。
そして、そのような制約は山ほどあります。例えば、見栄えの良い棚を提供するために、最低限これこれという制約が課される場合があり、これは店舗におけるマーチャンダイジング上の制約などと呼ばれるでしょう。
このように、変数、制約、そして第三の要素である損失関数が存在します。損失関数は、すべての制約を満たす任意の解に対して、その損失を与え、それを最小化するように設計されています。これはあくまで慣習です。
これら3つの要素が組み合わさることで、一般的な数学的最適化フレームワークが定義されます。過去100年間、数学者がこのフレームワークを使ってきた理由は、その汎用性にあります。
そしてここで、確率性というひねりが加わり、損失関数が決定論的でないという、非常に特殊な変更が試みられています。すなわち、クラシックな数学的関数のように入力に対して必ずしも決まった出力が得られるわけではなく、入力に対してランダムな出力が返されるのです。
Conor Doherty: 制約の話に戻ると、私の理解が間違っていたら訂正してください。これらの制約は細分化できるのです。例えば、あなたは棚や倉庫の容量、1日に処理できる量について述べました。処理能力は多少向上させることができるかもしれませんが、棚の容量は有限です。すぐには変わりません。しかし、MOQは変更可能です。再交渉もできるわけです。つまり、これらの制約の中には流動性があるということでしょうか？それが、あなたが言う確率性であり、意思決定に組み込まれているのでしょうか？
Joannes Vermorel: そうではありません。制約は、単にある解が受け入れられないという概念を数学的に表現したものにすぎません。ビジネス戦略における損失関数の適切性の深い問題と同様に、制約に関しても同じことが言えます。つまり、本当にこの制約は必要なのか、この制約を取り除くために投資できるのか、あるいはビジネスの見方を変えるべきなのか、という問いが伴うのです。
改めて言えば、二つの異なる視点が存在します。一つは、ビジネスに忠実な変数、損失関数、制約を持ちたいというモデリングのアプローチです。これは根本的に数学的でもアルゴリズム的でもなく、これらの要素がビジネスに対して真実であるかどうかを理解するということです。
しかし、これは数学的な意味での真・偽を問うものではありません。制約は、数学的には真でも偽でもなく、単に「最大容量が100ユニットである」という前提に過ぎません。この記述に数学的な妥当性はなく、それはただ与えられたものです。数学者は「ええ、あなたは100を選んだ」と言うかもしれませんが、数学的には100が良い数字かどうかは判断できず、例えば「100未満でなければならない」という制約と「100より厳密に大きくなければならない」という制約が同時に存在すれば、解は存在しないとしか言えません。
数学は与えられた入力に対して判断を下すことはなく、内部の一貫性のみを求めます。しかし、確率的な世界では、制約が数学的に非常に微妙なものになるという面白い点があります。
では、確率的な問題とは何を意味するのでしょうか。従来の非確率的最適化の視点では、制約によりその解が成立するか否かが明確に区別され、損失は考慮されませんでした。しかし、損失関数が確率的である世界では、それはどういう意味になるのでしょうか。例えば、倉庫があり、補充発注が可能で、倉庫には1日の受入能力があるとしましょう。
つまり、毎日、仕入先から処理できるユニット数には限界があります。そのため、通常この倉庫では、仕入先のリードタイムを考慮して補充発注を分散させ、全ての仕入先が同日に全ての商品を納入して倉庫の受入日次能力を超えるのを防いでいるのです。
確率的最適化の観点から見ると、発注数量を選択した後、納品時刻のばらつきが生じます。つまり、非常に不運な場合、補充発注は分散されているにもかかわらず、初回の発注が遅れ、後続の発注が早すぎる結果となり、偶然にもすべてが同日に集中してしまい、その結果、倉庫が過負荷状態、つまり定められた受入能力を超えてしまう可能性があるのです。
完璧に実現可能な解が得られなくなる状況は数多く存在します。つまり、制約が守られない可能性が常に存在する状況に直面するということです。これが現実であり、私が述べる数学的な主張でもあります。損失関数の性質や、決定が非決定論的な結果（例えば、数量は決定しても納品日には完全にコントロールできない等）をもたらすためです。
たとえ最善の判断を下したとしても、在庫数量が重なってしまう可能性は残ります。これが絶対に起こらないと保証する唯一の方法は、すべての保留中の注文のパイプラインにおいて、最悪のシナリオ―すべての保留中の注文が同日に納品される場合―を考慮して、いかなる日も受入可能な量を超えないようにすることですが、これは明らかに極端な方法です。
企業は、1万分の1の確率で自社の容量を超過してしまう状況に直面せざるを得ません。しかし実際には、制約が絶対的であるという考えは、数学的な概念に過ぎず、実際に容量を超えた場合にはコストが発生します。
確率的最適化の視点に立つと、基本的に制約は損失関数の一部として取り扱われる必要があります。もしくは、低い確率で制約違反が発生することを一定の許容範囲として受け入れるアプローチをとることになります。ほとんどの興味深いサプライチェーンの確率的最適化問題においては、制約違反の残留確率が微小ながら存在するのです。
Conor Doherty: その許容という話ですが、つまり実行可能性のことを指しているのでしょうか？そして、それは何によって測定されるのでしょうか？
Joannes Vermorel: それは、問題に設定した容量に基づいて測定されます。例えば、店舗を補充したいと決めた場合、その店舗の容量に合致するように判断を下します。しかし、もしその店舗が何らかの偶然で特定の日に全く売れなかった場合はどうでしょう。例えば生鮮食品を扱っている場合、今日は牛乳を補充するという決定を、当日の売上を考慮せずに下すとします。しかし、依然として一定数が販売されることを前提としています。そして、通常は毎日在庫の80%が売れる店舗で、偶然にも今日は全く売れなかった場合、結果として補充を行い制約を超過してしまう可能性があるのです。
重要な洞察は、不確実性のある状況に陥ると、損失関数だけではなく制約の充足状況も変動するという点です。多くの興味深い状況では、制約が完璧に守られることはありません。「制約が確実に守られる状況のみを追求すべきだ」と考えるのは誤りです。なぜなら、数学的には解は得られるものの、それは非常に劣悪なもの―例えば何も発注しない、何もしない、といった解になり、制約違反はなかったとしても利益は生まれないからです。
Conor Doherty: 発注の受領、発注の分散、そして経済的に最も実行可能な方法で行うという、あなたが挙げた例に戻りたいと思います。これは、いわば確率的アプローチということでしょうか。従来の、確率的側面を欠いた数学的最適化に基づくモデルは、あなたが述べた問題にどのように対処していたのでしょうか？
Joannes Vermorel: 彼らはその問題を完全に無視していました。古典的な決定論的数学的最適化では、そもそもその問題自体が存在していなかったのです。あなたの決定によるさまざまな結果は考慮されず、存在しなかったのです。
このケースを緩和する方法はいくつかあります。一つの単純な方法として、「1回の最適化を見るのではなく、問題の定義をマクロ的に拡張して、例えば100の異なるシナリオを共同で最適化する。そして、あらゆる未来に対して共通の決定を下し、すべての変動するシナリオにおいて、全ての制約が守られることを確認する」という方法があります。
では、どのようにして決定論的なケースに戻るのでしょうか。単に「状況を100通り、すなわち100の軌跡を表す形で複製し、100のインスタンスを同時に含むマクロ拡張問題を最適化する」と言えばよいのです。
そして、これは古典的なソルバーを使って実行可能ですが、すでに今日のサプライチェーン実務者が数学的最適化ツールを使用できない原因となっている問題、すなわちスケーラビリティの問題をさらに悪化させるだけなのです。
Conor Doherty: では、具体的な業界に適用してみると、理論が実際の複雑性、実際の制約、実際の変数とどのように相互作用するかという、三次元的な理解が得られると思います。例えば、MRO企業を考えてみましょう。典型的な規模で、通常サイズの艦隊、例えば10機の航空機があり、それぞれが25万個の部品を持っている場合、これら3つの要素は、あなたが言う確率的最適化と従来の数学的最適化のどちらにおいてどのようにフィットするのでしょうか？
Joannes Vermorel: MROの場合、どのような問題があるか見てみましょう。修理を行うために在庫を最適化する必要があります。部品が入荷し、それが使用不能で修理を開始すると、必要な部品が判明します。すなわち、部品表（BOM）が存在しますが、これは確率的で不確実なものです。ここには確率性が働いており、修理用の部品が揃うかどうかという需要の変動という不確実性があるのです。しかし、実際に部品が到着すると、そのコンポーネントを修理するために本当に必要なものが明らかになるのです。
問題は、一つの部品が欠けていると、そのコンポーネントの修理ができなくなる点にあります。部品の90%が揃っていても解決にはならず、修理のためにはすべての部品が必要であり、1部品でも欠ければ修理は不可能なのです。
Lokadでは、こうした状況に対して数年前から確率的な予測を行ってきました。確率的予測とは、修理すべき部品の到着や、必要な部品の確率分布を適切な確率で予測することであり、これが確率的部品表となります。そして、次に何を再発注し、どの部品をどの数量で在庫化するかを決定しなければなりません。その上で、これらの部品にはリードタイムの不確実性が存在し、さらに一部の部品は修理可能であるということもあります。
一部の部品については、コンポーネントから部品を取り出すことでターンアラウンドタイムが発生するだけでなく、その部品自体が修理可能であるという不確実性があります。ですから、その部品を修理して戻すこともできますし、あるいは、部品を取り出して修理させるものの、修理が完了するまで待たずに別の部品をコンポーネントに取り付ける可能性が高いです。
しかし、これは、追加の部品が必要かどうかを判断する際に、すでに修理プロセス中で戻ってくる部品も考慮に入れなければならないことを意味します。つまり、手元にある部品だけでなく、戻ってくる部品も含めて判断する必要があるのです。そして、修理を試みても修理できない廃棄率のような他の要因も存在します。たとえば、10個の部品が戻ってくると思っていたのに、修理不可能で2個が廃棄され、結果として8個しか得られなかったということです。
それは予測の一部であり、あらゆる不確実性を含んでいます。さて、最終的に下したい決定は、部品購入の問題を解決することに関するものです。問題は、戻ってくる全ての部品やその他の要因を考慮に入れて、より多くの部品ユニットを購入すべきかどうかということです。
部品は、修理に寄与すれば経済的な価値を持ちます。しかし、先ほど述べた南京錠の例のように、全ての部品が揃えば修理が可能となり、それぞれの部品に価値が生まれます。しかし、部品が欠けていれば、それらはただの無駄な重りに過ぎません。手元の部品は、完全な組み合わせが揃って初めて役に立ち、もし一部が欠ければお客様に遅延が発生します。
いずれにしても、在庫は全てが揃って初めてその役割を果たします。そして、全てが揃っていない場合には、「何かが欠けていることに最後の瞬間で気づいたとき、その部品を入手するまでにどれほどの時間がかかるのか、あるいは非常に遅れて発注した場合、その部品が利用可能になるまでにどれだけの時間が必要なのか」という疑問が生じます。
もし、私の全てのSKUが厳密に独立しており、顧客もすべて異なるという単純な状況であれば、各在庫ポジションに対して経済スコアを計算し、その確率から在庫として保有した場合の期待収益（ドル換算）を算出することが可能です。
しかし、MROの場合は部品番号間に依存関係があるため、このアプローチは通用しません。たとえば、1ユニットだけ購入しても単体では価値がないかもしれませんが、もう1ユニットを購入すれば修理が完了し、両方の部品に大きな価値が生じるのです。
確率的な部品構成に必要な全ての部品が揃うまでは、手元の部品は基本的に役に立ちません。部品の経済的価値は、一緒にあるときに初めて発揮され、別々では価値を持たないのです。したがって、この確率的最適化問題を解く際は、部品を1つずつ購入したり、個別に評価したりするのではなく、組み合わせとしての意思決定を検証できる必要があります。取得すべき特定のユニットの組み合わせは、単独で各部品だけを見る場合と比べて、はるかに異なる経済価値を持つことがあります。
Conor Doherty: この考えに沿って理解しようと努めますのでお付き合いください。しかし、これらの確率的要素を説明すると、例えば部品のターンアラウンドタイムが1日、半日、3日、4日と変動するということになり、さらに、部品を受け取ってから実際に修理を行うまでの所要時間のように、人による修理能力という別の確率要素も存在するということになります。このような、人に基づく確率性も考慮に入れることは可能でしょうか？
Joannes Vermorel: はい、人間は遅延要因の一つに過ぎず、その能力も様々です。たとえば、あるオペレーターは他の者よりも才能があるため、より少ない部品で修理を完了できるかもしれません。才能ある者は、修理に失敗して部品を無駄にしてしまう才能の乏しい従業員よりも、消費する部品数を減らして修理を行うことができるのです。
aviation MROにおいては、部品は非常にモジュラー化されており、部品はさらに部品から構成され、その部品もまた細分化されます。したがって、修理方法が分からない場合、故障している一部分だけを交換するのではなく、サブモジュール全体を廃棄して、全く新しい部品に置き換える選択肢が常に存在するのです。
もし何を交換すべきかを的確に診断できれば、必要な部分だけを交換するでしょう。しかし、診断が不十分であれば、結局はより多くの部品を交換せざるを得なくなるかもしれません。
しかし本題に戻ると、ここでのひとつのポイントは、解決策を定義する際にポリシーの視点から検討しなければならないということです。つまり、解決策とは単に今下す決定ではなく、あなたの意思決定を導く基本原則そのものを意味します。ポリシーは在庫として保持する部品を規定するだけでなく、確率的な部品表の発見に対してどのように反応するかという点も考慮に入れる必要があります。
なぜこれが重要なのでしょうか？たとえば、航空機エンジンの修理を行うとします。エンジン外部の部品は、最初に診断される部品となります。エンジンを受け取り修理を開始すると、分解時に最初に触れる部分であるため、エンジン外部に必要な部品が明らかになるのです。エンジンは、複数の層を持つマトリョーシカのように、中心部に向かって構造が重なっています。
もしエンジン外部の部品が必要であると判明した場合、エンジンを中心部まで分解するのに数日、そして中心部から外部へと再組立てする時間があるため、その部品を調達するための十分な時間が確保できる可能性が高いのです。
つまり、この部品は在庫として保持する必要すらなく、必要になる日に初めて発注すれば、供給業者のリードタイムがたとえば20日であった場合、実際に部品が必要となる60日目には、部品がすぐに入手可能となるのです。
部品の在庫最適化を検討する際は、すぐに取り扱えるべき部品が何か、またこの確率的部品表の発見に直面した際の典型的な対応策というポリシーも考慮に入れる必要があります。
もし、航空機の分解を担当する者が部品の在庫有無に関する情報を全く持たないという別のポリシーを仮定すると、話は全く異なります。なぜなら、その場合、航空機エンジンを分解・再組立てした後でも、60日経過してから特定の部品が欠如していることに気づいてしまうからです。
ご覧の通り、ポリシーは一連の意思決定状況、すなわちどのような決定が下され、状況の進展に伴い最終的な経済的結果がどのように形成されるかを表現するものです。
ここでは2つのポリシーが考えられます。一つは、情報を得次第早急に反応して発注を行う賢明な方法。もう一つは、部品を実際に組み立てる必要が出てから、その部品が必要であることに気付いて発注を行う方法です。もし後者のポリシーを採用している場合、欠如した部品が原因で航空機エンジンの最終工程で遅延を招かないために、在庫として部品を保持することの経済的価値は非常に高くなることを意味します。
一方、賢明な最初のポリシーが採用されている場合、エンジン外部の部品を在庫として保持することに経済的価値はなくなります。なぜなら、そのポリシーにより早期に発注が行われ、部品が欠如することがなくなるからです。
Conor Doherty: あなたが説明しているような反応性に伴う技術的オーバーヘッドにはどのようなものがあるのでしょうか？つまり、エンジン内部に進入して部品が必要と判明した場合、修理全体の予定タイムラインが完全に再構成されることになるのですが。
Joannes Vermorel: 非常に興味深い質問です。スケーラビリティは大きな懸念事項となっています。ここで言うスケーラビリティとは、サプライチェーン向け数学的最適化技術のスケーラビリティを意味し、これは実質的に40年以上にわたる障害となっているのです。
数学的最適化は非常に確立された研究分野とされ、いわゆるソルバーと呼ばれるソフトウェアを提供する確立企業も存在します。ソルバーは数学的最適化問題に対処するために設計されたソフトウェアで、通常は独自のプログラミング言語が付属しており、変数、損失関数、制約条件などを表現するための数学的プログラミング言語となっています。
興味深いのは、これらのソルバーは40年前に市場に登場し、現在ではオープンソースのソルバーも存在するにもかかわらず、サプライチェーン分野ではほとんど見かけられないという点です。私は、スケーラビリティが大きな問題であると考えています。
市場に存在する手法を分解すると、基本的には好条件な損失関数、すなわち凸関数に分類されます。凸関数とは、関数の曲線が緩やかで、解を選ぶ際に勾配に沿って自然に最適解へ収束できることを意味します。線形関数や二次関数のような好条件な関数は、スケーラビリティの問題がほとんどなく、実際に何十億という変数を扱うことも可能です。しかし、サプライチェーンで直面する問題は、そのような好条件とは言えません。
次に、ブランチ・アンド・バウンズ、ブランチ・アンド・カットといった第二のクラスのソルバーがあります。これらは、制約条件が支配的で、実現可能な解が非常に少ないという前提に基づいています。制約が非常に多いため、解空間のハイパープレーン全体を排除でき、解の集合を半分に切り分け、その半分は捨てるべきだと判断します。文字通り、解の半分を排除し、そのプロセスを何度も繰り返して最終的に非常に狭い解空間に絞り込み、そこを徹底的に調査するのです。
また、問題の緩和（リラクゼーション）と呼ばれる手法も多く存在します。これは、制約なしで問題を見ることで理想的な解を見つけ、その後に制約を再適用する方法です。しかし、非常に厳しい制約がない場合、これらの問題はスケールしにくいのです。したがって、これらの手法のスケーラビリティは、すべての制約が適用された後にどれだけの余裕が残るかに大きく依存します。そして、サプライチェーンで考慮する問題は、多くの制約があるものの、それほど厳しくはないのです。
南京錠を例に考えてみてください。南京錠は10,000通りの組み合わせがある中で、正しい組み合わせは1つだけです。しかし、サプライチェーンにおいては、制約条件は存在するものの、それほど厳しくはありません。例えば、棚の容量という制約内でも、依然として膨大な数の解が存在し、これらの製品をさらに多く配置することが可能です。つまり、解空間を数個に縮小するような厳しい制約ではなく、依然として非常に多くの解が残っているのです。
このような解空間削減手法、つまりブランチ・アンド・カットやブランチ・アンド・バウンドなどのソルバーは、1,000変数を超えると通常非常に低速に動作します。場合によっては10,000変数でも動作するかもしれませんが、それは既に限界に近い状況です。何十ギガバイトのRAM、数十のCPU、そして数時間の計算時間を要する非常に大規模なマシンが必要となり、非常に遅くなります。10,000変数というと「多い」と感じるかもしれませんが、実際にはまだ小さな問題なのです。
例えば、ミニマーケットの場合、商品数は5,000品目となるでしょう。しかし、これは単純に5,000変数というわけではなく、実際には各商品について0ユニット、1ユニット、2ユニット、3ユニット･･･といった選択が問われます。たとえば、10ユニットまでとすれば十分かもしれませんが、すでに50,000変数に達し、さらに各ミニマーケットごとのロケーションなども考慮に入れる必要があるため、実際には非常に多くの変数が発生するのです。つまり、ミニマーケットのような上位の問題でも、既に50,000変数に達しており、これは現実的に扱える範囲を大きく超えてしまいます。
そして、第三の手法としてローカルサーチがあります。ローカルサーチは、実行可能な解が見つかるという前提に立つ手法で、サプライチェーンの場合、この前提は非常に合理的です。つまり、どの制約も破らない解を見つけることは通常かなり容易です。たとえば、棚が溢れないようにという制約であれば、単に発注量を減らせばよいのです。難しい問題ではなく、制約を満たすまでユニット数を減らすだけです。もし最小発注数量がある場合も、制約を満たすまでその製品の発注量を1ユニットずつ増やしていけばよいのです。
つまり、制約を満たす解を見つけるのはそれほど困難ではありません。まるで、正確に数十もの変数を揃えなければならない暗号のパズルのようなことはありません。サプライチェーンにおいて「問題が簡単だ」と言うのは、通常、1つの変数を調整するだけで解が得られるという意味です。棚に収まるまで数量を減らす、または最小数量を得るために数量を増やすなど、半ば自明な方法で制約を満たす解を得ることができるのです。ただし、ここで述べているのは解の質ではなく、単に解が見つかるという点です。
本質的に、ローカルサーチは、一度制約を満たす解が得られたら、その解をランダムに変異させ、もし変異後の解が何らかの制約を破る場合は破棄します。そして、変異した解が問題を満たし、かつ損失関数によってその解がより良いと評価された場合、その新しい解に移行し、このプロセスを繰り返すのです。
つまり、すでにある程度有効な解が存在する状態で、その解をランダムに修正し、運良く損失関数によってより良いと判断された解が得られ、かつその解が全ての制約を満たしている場合、その新たな解にジャンプして繰り返すということです。
これにはさまざまなバリアントがあり、通常はメタヒューリスティクス、遺伝的アルゴリズム、タブーサーチなどと呼ばれます。これらはすべて、解から始め、ランダムな変異を繰り返すことでスケーラビリティを向上させるという前提に基づいています。このような手法を用いれば、もしかすると100万個の変数にまで拡張できるかもしれません。しかし、それでも非常に遅いのです。
そして、Lokadでは試みたものの、サプライチェーンにおけるスケーラビリティのテストに依然として合格しませんでした。つまり、古典的な手法とは一線を画しており、より良いものではあるものの、急速に増加する何百万もの変数にスケールさせ、迅速な収束を求めるような問題にはあまりにも弱いのです。
また、問題の確率的側面も考慮する必要があります。ご覧の通り、私が5万個の変数を持つミニマーケットの問題に言及した際、可能な未来を想定して100の軌跡でマクロ展開すると、変数は500万に達します。つまり、急速に膨張し、やはり十分ではないのです。
Conor Doherty: 元の質問に少し補足したいです。ここまでを要約すると、古い数学的最適化の問題は決定論的であったことです。物事が既知で、正しいか間違っているかがはっきりしている、つまり正しい決定か間違った決定しかできないのです。
その後、私はMROの複雑さについて尋ねたところ、あなたはその複雑さについて非常に明確な洞察を示してくださいました。では、あなたが示したこの僅かな複雑性に対する確率的最適化の技術的オーバーヘッドは何でしょうか？ 明らかに常軌を逸していますが、私が実際に尋ねたいのは、これを実装するための完璧な方法ではなく、確率的最適化を用いるためのより良い方法は何か、ということです。完璧ではないかもしれませんが、あなたが述べたすべてに違反しない、機能的または実現可能な実装方法は何でしょうか？
Joannes Vermorel: 数学的最適化の問題は、実際にはスケーラビリティに関するものです。確率的問題を決定論的問題として再表現することで、決定論的問題に戻すこともできます。しかし、もともと私たちが使っていた数学的最適化技術は、すでに深刻なスケーラビリティの問題に悩まされていました。
今、私たちは確率的問題を決定論的問題として再表現するために問題を膨張させていますが、これによりスケーラビリティの問題はさらに悪化します。確率的最適化に対処する単純な方法としては、100万回変動する損失関数を実行し、その結果を平均すればよいのです。それは確かに機能するでしょうが、計算上のオーバーヘッドが非常に大きいのです。
つまり、私が言いたいのは、これらの数学的最適化ツールは何十年も利用できる状態にありながら、スケールせず、確率性すら扱えないということです。確率性――すなわち確率予測から生じる不確実性――を考慮する前から、すでにスケーラブルではなかったのです。もし確率性を積み上げれば、桁違いに問題が拡大してしまいます。だからこそ、Lokadはサプライチェーンにとって意味のあるスケールでこれらの問題に対処するため、確率的最適化の技術を根本的に再開発する必要があったのです。
そして、本当にそれが必要な理由に戻ると、答えは、Lokadが2012年に確率予測を導入した際、私たちはすぐに大きな問題に直面したということです。不確実性の下での最適化は非常に、非常に困難なのです。
長年にわたり、私たちは状況を応急処置的にでも対処するため、賢いヒューリスティクスを工夫してきました。つまり、賢いヒューリスティクスに頼れば何とかなるということです。ヒューリスティクスとは、非常に限定された状況下で何とか機能する巧妙な方法を意味します。いわばズルであり、狭い状況でしか通用しません。しかし、そのヒューリスティクスは脆弱になりがちなのです。
さらに、クロスプロダクト制約やクロススキュー制約、つまりサプライチェーン内の相互依存する要素が関与すると、それらのヒューリスティクスは崩れやすくなります。だからこそ、確率的最適化が必要になるのです。
もしそれがなければ、企業にとってどういう意味になるでしょうか？ つまり、非常に保守的な人間の判断に依存することになるのです。なんとか機能はするかもしれませんが、制約を満たすために極めて安全な方法を取る傾向が生じるのです。サプライチェーンでは、すべての問題が単により多くの資金投入によって解決できるものとなってしまいます。
航空MROの例に戻ると、明白な解決策があります。それは「空が限界だ」と宣言することです。つまり、必要な部品は好きなだけ確保できるため、在庫を大量に持ち、それによって高いサービスレベルを実現するのです。問題にただ資金を注げば、確かに何とか問題は解決するかもしれませんが、これは厳密な解決策ではなく、非常に緩い解決策なのです。
棚の制限についても同様です。店舗を非常に狭い制約で区切ると決めることができます。例えば、これら2～3の商品にはこれだけのスペースしか与えず、別の商品にはこれ以上のスペースを与えないといった具合です。そうすることで、店舗内の構成の変動が制限されてしまいます。
たとえば、ヨーグルト全体で200個以内と決めたとしましょう。それで問題なければともかく、この制約が誤っている場合はどうでしょうか？ もし現地で需要が急増し、ヨーグルト全体の数量に対するこの制約が低すぎると、毎週土曜日の終わりにはミニマーケットにヨーグルトが一つも残らなくなってしまうのです。
実際、確率的最適化装置、すなわち確率的ソルバーが利用できない場合、企業は通常、解空間を狭めるために多くの制約を追加する傾向にあります。こうすることで、解を選び意思決定する人々またはソフトウェアが、はるかに狭い解空間で動作し、クロスクエの依存関係やクロスクエの懸念を軽減するのです。
しかし、これは狭い意味でのズル行為であり、実際にははるかに優れた解が存在する可能性があるのに、多くの偽の制約を積み重ねることでそれらの解を排除してしまうのです。
Conor Doherty: ここまでかなり多くの点を網羅しましたね。つまり、数学的な知識が必ずしもあるとは限らない人々にも理解しやすくまとめると、確率的最適化は従来の数学的最適化と比較して、意思決定の最適化においてはるかに柔軟で反応的な方法である、ということですか？
Joannes Vermorel: はい、より表現力豊かな方法です。決定論的な問題として表現できるものは何でも、確率的な問題としても表現することができます。しかし、ある意味で確率的最適化ははるかに一般的です。なぜなら、決定論的というのは、単にあなたの関数が全く変動しないことを意味するだけです。もし変動する関数があるなら、常に変動しない関数を選ぶこともでき、それでも機能するでしょう。ですから、まずはどの種類の問題にアプローチできるかという枠組みを定義することが重要なのです。
もし問題に不確実性が含まれるなら、確率的最適化が必要です。まさにあなたの状況が属する問題のクラスなのです。そして理想的には、それに対処するソフトウェアコンポーネントが必要となります。確率予測は、不確実性を評価するための基本的な予測を生成するツールです。
意思決定そのものに関しても、ソフトウェアコンポーネントが必要です。数学的最適化における典型的なアプローチは、任意の問題定式、決定論的な損失関数、変数、制約を取り込み、損失関数を最小化する変数の組み合わせ―つまり解―を提供する汎用のソフトウェアであるソルバーを用いるというものです。同じ仕組みを、確率的ソルバーとして利用することもでき、求める変数の組み合わせを出力として提供してくれます。
では、なぜソルバーが必要なのでしょうか。利益や損失を表すあなたの損失関数は変動する可能性があります。もしかすると、その関数を再調整して戦略的なビジョンに適応させたいかもしれません。解を提供するための数値レシピ全体のソフトウェア的解決策を一から再実装したくはないのです。
つまり、「ここに新しい損失関数があるので、この更新された損失関数に対して改めて解決策を適用してほしい」とするだけでよいのです。そして、それがソルバーがあなたに提供できるものであり、損失関数、制約、変数の定義を受け取り、解を提示するパッケージ化されたソフトウェアコンポーネントなのです。
Conor Doherty: つまり、あなたが話しているソフトウェアツール、すなわち最適化や解を自動的に再生成するソルバーソフトウェアツールは、従来のサプライチェーン実務者が行う作業量を大幅に減らす、ということですね？
Joannes Vermorel: 実際、これにより意思決定プロセスは完全に自動化されるのです。ソルバーこそが、Lokadがクライアントに提案する最終的な決定を生成するものです。最適化にアプローチする方法はさまざまです。非常に優れたヒューリスティクスを用いることも可能ですし、状況によってはそれだけで十分機能するため、必ずしもソルバーが必要というわけではなく、ヒューリスティクスがソルバーの役割を果たすこともありえます。しかし、要点としては、ソルバーが予測を受け取り、解を生成するという点にあります。
Conor Doherty: 確認ですが、あなたが「ソルバー」というとき、例えば在庫補充における推奨決定を生成する「数値レシピ」と同じ意味で使っているのでしょうか？
Joannes Vermorel: 私が「数値レシピ」という用語を使うとき、通常はデータの準備から結果の生成までの一連の処理全体を指しています。この数値レシピは通常、データ準備、予測生成、最適化、そして結果提示という一連のステージに分解されます。本日は、その中で予測を入力として最終決定を計算する部分だけを議論しています。
Conor Doherty: もしサプライチェーン実務者が、ソルバーによって生成されたサプライチェーンの決定に異議を唱えた場合、どのような対処が可能なのでしょうか？ 何百万もの変数が稼働する、いわば人間の能力をはるかに超えたスケールで動作しているのであれば、実務者としてその正誤をどのように評価できるのでしょうか？
Joannes Vermorel: ソルバーは非常に簡単に検証を行えます。単に「こちらに私のより良い解があります。この解を損失関数に対して検証してみましょう」と主張すればよいのです。つまり、ソルバーが提示した解よりも優れた解を示すだけで、そのソルバーが十分でないことが証明できるのです。
つまり、ソルバーはある変数の組み合わせを提示し、通常、解が与えられた後に、損失関数や制約が存在します。「これは暫定的な解です。まず制約が満たされているか確認しましょう。はい、確認できました。次に、損失（ドル単位）を算出する損失関数を適用してみましょう。これが損失であり、これがソルバーによって提示された解です」といった流れになります。
もし、私が自ら変数を選び出してこの解を手動で調整し、損失関数による評価よりも良い結果を得られたなら、すなわち人間としてソルバーよりも優れた解を生み出すことが可能であると証明されたことになります。この場合、そのソルバーはあまり優秀ではないということになるのです。これは十分に起こり得る状況です。
市場に出回っている既製のソルバーの問題点は、解を見つけられないのではなく、非常に質の低い解を見つける点にあります。サプライチェーン実務者が、購入量を手動で再調整しても、すべての制約を満たし、さらに損失関数の評価においてより良い結果が得られるような解になる場合が多いのです。したがって、ソルバーに対して異議を唱えるのは、確率予測モデルに対して異議を唱えるよりもはるかに容易です。必要なのは、損失関数の評価でより良い解を提示することだけなのです。
もしあなたがその問題に関して特別な洞察を持っているなら、手動でソルバーを上回る解を作り出すことも可能でしょう。サプライチェーンの分野で市販されているほとんどのソルバー、つまり全ての商用ソルバーについても、手動で上回るのは比較的容易です。確率的な問題に対しては、本当に優れておらず、スケーラビリティもひどいです。例えば、ソルバーを30分間稼働させたとして、その解が全く役に立たなかった場合、しばしば人間がより良い解を提示できるのです。
Conor Doherty: では、これを聞いた人々にとっての重要なポイントは何だと言えますか？
Joannes Vermorel: 重要なポイントは、確率的最適化がサプライチェーンの教科書ではほとんど取り上げられていない非常に重要な視点であるということです。大半の著者は、そもそもその問題の存在すら認めていません。確立された大手企業が販売しているソルバーは、決定論的最適化問題向けのものです。確かにそれらは優れたソルバーですが、サプライチェーンにおける不確実性が原因の問題群を解決するものではなく、ただ不確実性を無視しているのです。
このようなソルバーを持つ利点は、存在するすべての相互依存関係を真に考慮した方法でサプライチェーンを改善できる点にあります。各要素を孤立して見るのではなく、サプライチェーン全体を、すべてがシステムに寄与する一つのシステムとして捉え、その依存関係を把握する必要があるのです。
これらの依存関係はさまざまな形を取ります。航空業界では、修理に必要な部品リストであったり、ファッション業界では、店舗が魅力的であるためにあらゆる色の衣料品を揃える必要があるという事実であったりします。これは製品レベルでは表現できないものです。大型スーパーマーケットにおいては、人々が実際に何を買いたいのか、つまり買い物リストを考慮する必要があります。人々は単一の商品だけを買いに来るのではなく、全体のリストを求めています。あるいは、料理のレシピに必要なすべての材料を求めているかもしれません。ほとんどすべての自明でないサプライチェーンには、あらゆる場所に相互依存関係が存在し、確率的ソルバーや確率的解決手法がなければ、問題に満足のいく形でアプローチすることすらできないのです。
Conor Doherty: では、Joannes、本日はありがとうございました。これ以上質問はありません。そして、ご覧いただいた皆さんにも感謝します。では、また次回お会いしましょう。
