00:00:00 Lokadの創業物語と初期の歩み
00:02:31 サプライチェーン最適化に関する誤解
00:04:31 従来のサプライチェーン理論は通用しなかった
00:06:32 予測の失敗という逆説
00:08:33 「何も予測しない」ことが競合を打ち負かした方法
00:10:25 既存の考えを否定するという挑戦
00:12:00 確率的予測への転換
00:14:07 極端な需要シナリオの重要性
00:16:32 企業データ統合の複雑性
00:20:55 理論上のサプライチェーンモデルが失敗する理由
00:27:30 企業のAI導入における技術的課題
00:35:00 COVID-19がサプライチェーンに与えた影響
00:42:49 LLMは数学的ではなくテキストベースである
00:50:25 金融業界の並行進化
01:09:00 質疑応答と最終コメント
要約
LokadのCEO兼創設者であるJoannes Vermorelは、フランス語で講演を行い、その中で供給チェーン管理における自身の歩みを共有しました。Vermorelは、École Normale Supérieureを卒業した後にLokadを創業し、バイオインフォマティクスからサプライチェーンの課題へとシフトした経緯を振り返りました。彼は、Lokadのプログラミング言語であるEnvisionの開発や、2007年以来の会社の進化について議論しました。また、伝統的なサプライチェーン理論を占星術に例え、コンセンサスに挑戦する重要性を強調しました。さらに、確率的手法によるLokadの成功と、COVID-19が供給チェーンのロボット化に与えた影響を強調し、従来の役割が陳腐化することを予測、学生たちに業界の革新を牽引するよう呼びかけました。
拡張要約
フランス語で学生向けに行われた講演で、LokadのCEO兼創設者であるJoannes Vermorelは、サプライチェーン管理の世界と自社の進化に関する自身の歩みや洞察を共有しました。Vermorelはまず自己紹介を行い、École Normale Supérieureを卒業後すぐに創業したLokadの起源について語りました。当初、Vermorelはバイオインフォマティクスでの博士論文を試みましたが、その分野にはすでに才能ある人材が溢れていることに気づきました。偶然にも、サプライチェーン管理の課題に出会い、それが新たな焦点となったのです.
Vermorelは、Centraleの学生たちが、彼自身がサプライチェーン最適化のために作ったプログラミング言語Envisionを使用しているのを見て、驚きと喜びを表明しました。彼はEnvisionの開発経緯を振り返り、自ら書いた最初のコンパイラがすぐにLokadのCTOであるVictor Nicoletによって、より優れたバージョンに置き換えられたことを述べました。それ以来、Envisionは大きく進化し、現在ではバージョン6のリリースが目前に迫っています.
Lokadの歩みは2007年に始まり、正式な創業は2008年でした。しかし、Envisionが導入されたのは、創業から5年後の2013年のことです。Vermorelは、新たなプログラミング言語を開発する決断が、他のすべての手段を尽くした後に下されたものであると説明しました。当初、彼はサプライチェーンが何十年にも及ぶ文献と、SAP、Oracle、IBM、Microsoftといった数多くの競合企業を擁する確立された分野だと信じていました。成功の鍵は、既存のサプライチェーン理論をウェブアプリケーションに再パッケージ化すること、つまりクライアントサーバー型からクラウドベースへのシフトを活用することだと考えていたのです.
当初の自信にもかかわらず、Vermorelはすぐに、確立された理論やモデルが期待通りに機能しないことに気づきました。彼は、2011年にLokadが全くのゼロ予測を提出することで実施されたベンチマークで、競合よりも20%高い精度を達成したという、特に荒唐無稽な経験を振り返りました。この経験は、伝統的なサプライチェーン理論の妥当性に疑問を投げかけ、天文学ではなく占星術に例える結果となりました.
Vermorelは、科学においてコンセンサスに挑戦する重要性を強調し、歴史上には広く受け入れられながらも最終的には誤っていた信念の例が数多く存在することに言及しました。彼は、サプライチェーン自体は正当な分野であるものの、その基盤となる古典的理論には欠陥があると結論づけました。この認識が、バイアスのかかった予測や分位点予測といった、より効果的な代替手法の探求へと駆り立てたのです.
Lokadのアプローチは、実世界のサプライチェーン問題の複雑性に対処できなかった従来のモデルから脱却し、確率的かつプログラム的な手法を取り入れる方向へと進化しました。Vermorelは、これらの課題に特化した堅牢なプログラミング言語を持つことの重要性を強調し、一般目的の言語であるPythonの使用がさまざまな技術的問題により多くの試みを失敗に導いたことを批判しました.
講演では、COVID-19パンデミックがサプライチェーンのロボット化を加速させた影響にも触れられました。Vermorelは、Lokadのソリューションが数十億ユーロ相当の在庫を最小限の人手で管理するなど、大規模な運用において効果を発揮していると述べました。この変化は、取引の大半がアルゴリズムに依拠するようになった金融業界の変革と呼応しています.
Vermorelは、サプライチェーン管理の未来について議論し、在庫管理者や需要プランナーなど、従来の役割が、より多くの企業が自動化された意思決定プロセスを採用するにつれて陳腐化していくと予測しました。彼は、学生たちにただ見守るだけではなく、積極的にこの革命を推進するよう呼びかけました.
学生からの質問に対し、Vermorelは、技術に強みを持つ企業はLokadのソリューションを内製化する可能性がある一方で、他の企業はこれらのサービスを引き続きアウトソーシングするだろうと説明しました。また、ChatGPTのような大規模言語モデル（LLM）の学習能力や記憶力の欠如という限界にも触れました.
Vermorelは、マーケットの非合理性とサプライチェーン業界における失敗プロジェクトの持続について振り返りながら講演を締めくくりました。彼は、過去の失敗にもかかわらず何度も多額の資金を調達した競合他社の逸話を共有し、市場の混沌とした性質を浮き彫りにしました。これらの困難にもかかわらず、VermorelはLokadの実績と、Centraleのような名門機関の学生たちの間で思いがけずEnvisionが成功したことに誇りを示し、学生たちにLokadへの参加を検討するよう呼びかけ、同社の継続的な採用活動を強調しました.
完全な文字起こし
フランス語の原文講演が英語に翻訳されました.
Joannes Vermorel: 自己紹介させてください。私はJoannes Vermorel、Lokadの創設者です。学校を卒業した後にこの会社を立ち上げました。私が在籍していたのはÉcole Normale Supérieureで、バイオインフォマティクスの博士課程を始めましたが、結局のところその分野では非常に多くの人々が面白い取り組みを行っていたため、私の存在はもはや必要とされていなかったようです。そして偶然にも、私はサプライチェーンの諸問題に出会いました。今日、皆さんがEnvisionを使用しているのを見て非常に嬉しく思います。中央の学生たちの前でこの言語について語ることになるとは、私が約12年前にEnvisionを作成した当時には想像もしていなかったことです.
私は最初のEnvisionコンパイラを書き、その後、LokadのCTOであるVictor Nicoletがそれを破棄し、すぐにはるかに優れた第二のコンパイラを書きました。そして現在、皆さんは基本的にバージョン5を使用しており、バージョン6がまさにリリースされようとしています。この言語は大きく進化しました。しかし、皆さんが目にした部分は、決してLokadの出発点ではありませんでした。実際、それはかなり遅れて登場したもので、Lokadは2007年に始まり2008年に法人化されたのに対し、Envisionは2013年頃のものです。つまり、Envisionが登場した時には、会社はすでに約5年の歴史を持っていたというわけです.
他のすべての選択肢を尽くした後に、言語を作るという発想が生まれました。それは、最初から先見の明のある創業者の計画というわけではなく、単に他の全てが失敗した結果でした.
サプライチェーンの驚くべき点を例え話として挙げると、2008年にLokadを立ち上げた当時、サプライチェーンは確立された分野だと考えていました。何しろ、この分野には60、70年分の文献があり、文字通り何百万もの論文が存在します。Amazonで「supply chain management」と検索すれば—私が調べたところ—現在約1万冊の書籍が販売されています。数十年にわたり、多くの書籍が出版されましたが、その1万冊が今もなお市販されているのです。非常に多くの文献に裏打ちされた分野です.
私が始めた当初、大手競合企業としてSAP、Oracle、IBM、さらにはMicrosoftといった有名な名前が見受けられました。競合企業の総収益を合計すれば、5,000億ドルにも達します。これは非常に大きな数字です。私の当初の直感は—結果として全く誤っていたのですが—、確立されたサプライチェーン理論をそのままウェブアプリに再パッケージすれば良いというものでした。2008年、すべてのエンタープライズソフトウェアは、PCにインストールするいわゆる「リッチクライアント」アプリから「シンクライアント」、すなわちウェブアプリへと移行しつつありました。したがって、クラウドホスティングを活用してサプライチェーンソフトウェアをウェブアプリとして再構築する機会があったのです。Lokadは非常に早い段階でクラウドへ移行しました。これによって、大手企業が依然として従来の重いクライアントベースのシステムを使用している中で、私たちは一歩先んじることができたかもしれません。そして、MITマニュアル、スタンフォードマニュアル、カルテックマニュアルのようにサプライチェーン最適化の方法を丸ごと説明する書籍が実際に存在するので、私はそれら—2、3人の教授によって書かれた1,000ページに及ぶ書籍—をすべて読み込みました.
その後、私はこれらのアプローチをコード化しましたが、何も機能しませんでした。興味深いことに、そのせいでLokadの成長や顧客獲得が阻まれたわけではありません。スタートアップが利益を上げるためには、実際に機能する製品が必要だと思われがちですが、エンタープライズソフトウェアの場合、全く機能しないものを販売しても顧客を見つけることができるのです。奇妙に聞こえるかもしれませんが、現実はそういうものです。企業が大きな問題を解決しようとする場合、そのための予算が存在します。その予算は、製品が実際に機能しない場合は大きくないかもしれませんが、スタートアップにとっては非常に大きな数字に映るのです。例えば、Carrefourのような大企業が試しに10万ユーロを投入するのなら、Carrefourにとってはごく僅かな金額ですが、小さな会社にとっては大きな額です.
そのため、その非対称性を活かして、私は次のような標準的なサプライチェーン理論、すなわち時系列予測、安全在庫算出、サービスレベルの最適化などの実装に取り組みました。しかし、どれも機能しなかったのです。クライアントとの間では、むしろ統合失調症的とも言える議論が繰り広thれました。彼らは「安全在庫の計算式のコードに誤りがあるに違いない」と指摘し、私たちは教科書の表からその値を実際に取り出し、パラメーターを再確認した結果、全く教科書通りであることが分かりました。つまり、理論自体は正確に実装されていたが、結果は全くのナンセンスだったのです.
ナンセンスの極致は2011年夏に訪れたと思います。私たちは、ヨーロッパとアメリカをそれぞれ半数ずつ含む半ダースほどのソフトウェアベンダーとの大規模なRFPに参加しました。Lokadはヨーロッパ側として参加しました。私の記憶では、このケースは、スーパーマーケット10店舗、各店舗あたり5,000のSKUが対象で、これらのスーパーマーケットが週に2、3回補充されるため、数日先の需要予測が必要とされるものでした。クライアントは、各店舗の日次製品レベルの予測に対して、実績との絶対誤差というバックテストの誤差基準を使用していました。結果として、Lokadはそのベンチマークで約20%高い精度を達成し、競合を完全に打ち負かしました。私の秘密の手法は？ 全てゼロを返すことでした。何も予測しないのです。私の「ゼロ予測」により、計算速度でも他社を凌駕しました。ゼロを返すのは非常に速いのです。そして、他社よりも20%高い予測精度を達成しました。さらに、需要がゼロと予測すれば、店舗の補充が行われず、2週間後には店舗が空になり、予測と完全に一致するのです。私は統計学の王者でした.
明らかに、それは完全なナンセンスでした。しかし、すべてのサプライチェーンの教科書やクライアントの標準プロセスが推奨するアプローチを考慮すると、全くの不合理に至ったのです。そこから導かれた結論は非常に不穏なものでした。私たちは利益を上げ、成長を続ける会社を抱えていたにもかかわらず、自分が単なる策略に偶然遭遇してしまったのかもしれないと痛感せざるを得なかったのです。何かを始めれば、それは利益を生むかもしれませんが、実際は全くのナンセンスなのです。最初は単に未熟で気づかなかったのかもしれませんが、一度気づいてしまったら、そのまま続けるのでしょうか？ 卒業して、自分がやっていることがナンセンスだと分かったら、続けますか？ それが深い疑問を引き起こしたのです。サプライチェーンは単なる占星術—つまり、未来を占うタイプの占いであって、天文学ではないのではないかと.
最終的に、私はサプライチェーンという分野自体は実在するが、標準的なサプライチェーン理論は基本的に占星術に過ぎないと結論づけました。これが問題点でした。70年にわたる研究、100万以上の論文、数千人の教授がすべて間違っていると受け入れるのは非常に困難です。どれほどの知的傲慢さが必要か想像してみてください。もし4人の異なる医師が、全員同じ診断を下すとしたら、いつになったら「全員が間違っている」と言えるのでしょうか？ しかし、科学はコンセンサスによって進むものではありません。千人があることに同意しても、それが間違っている可能性は常にあります。科学史は、極めて広範なコンセンサスが最終的には狂気と判明した事例に満ちています。科学の歴史を研究する人々の中には、ある社会がある時点で信じていることの半分が間違っているとまで言う者もおり、問題はどちらの半分が間違っているかを見極めることなのです.
それでロカドはベンチマークから、その結論に至りました：主流のやり方はナンセンスだった。私たちは別の何かを探さなければなりませんでした。2012年初頭に、大きな突破口として、quantile forecastsと呼ばれる手法でバイアスのある予測に取り組み始めました。当時、私のクライアントはバイアス除去のために50人のフルタイム従業員を雇っていました。そこで彼らは「なぜ、バイアスを取り除くために人を雇っているのに、敢えてバイアスのある予測が必要なのか？」と尋ねました。新しい手法はあまりにも多くのバイアスを追加するため、手動で取り除くことは到底不可能だと彼らは非常に驚いていました。しかし、「quantile forecasting」と呼べば、「biased forecasting」よりも科学的に聞こえるのです。実際、quantile forecastは単なるバイアスのある予測に過ぎません。
この手法を最初のeコマースクライアントで試した結果、一晩で、すべてに対してゼロを予測するような馬鹿げた結果から、少なくともある程度は理にかなった平凡な結果へと移行できました。それは驚くべきことには聞こえないかもしれませんが、完全な非常識状態から単なる平凡状態への改善は大きな前進でした。
その結果、教科書に記されているあらゆるサプライチェーンの前提を再検証することになり、その土台すべてに疑問を呈すると、実はそれらは非常に不安定で基本的に誤っていることがわかりました。Quantile forecastingはそのシンプルなバージョンにすぎません。これは極端な値に注目するための統計ツールです。サプライチェーンにおいて経済的な損失は、予期せぬ高需要によるstockout、予期せぬ低需要による在庫過剰、計画を台無しにする予期せぬ長いlead timesなど、極端な状況で発生します。問題を引き起こすのは分布の中央部ではなく、尾部なのです。Quantile forecastは、これらの極端な状況に焦点を当てたツールです。さらに高度なバージョンとして、完全な確率分布が得られる確率的予測があり、これは皆さんが取り組んでいるものです。2012年当時、数学、統計、計算の観点からシンプルだったため、私たちはquantile forecastsからスタートしました。SKUごとにひとつの予測値を生成するより、millions of SKUsにまたがる確率分布を扱うのは格段に重い作業です。
一方で、Envisionは元々全く異なる目的、つまりプライシングのための内部プロジェクト「Priceforge」として開発されたものでしたが、新しいアプローチに取り組むには完璧なものであることが判明しました。それ以前は、ロカドは典型的なエンタープライズソフトウェアのように、メニュー、ボタン、オプションを備えた標準のサプライチェーンソフトウェアを構築するという考えでした。しかし、ソフトウェアパブリッシャーの立場からは、機能を追加すればするほど、クライアントの環境から自社のデータ構造へのデータマッピングがエンジニアリング上の悪夢となり、混沌を極めたのです。
なぜでしょうか？それは、クライアントのデータアーキテクチャが常にユニークだからです。あるクライアントのERPには10,000ものテーブルがあり、それぞれ50のフィールドが存在し、その多くは文書化されず、通常と異なる使われ方をしています。実際、彼らは2つか3つのERPを持っている場合もあり、さらにWMSやeコマースプラットフォームも併せ持っています…エコシステムは非常に複雑です。同じデータ定義を持つ企業は二つとありません。「order date」といった一見単純な項目でさえ、記録が作成された日、顧客が注文を確認した日、あなたが確認した日、決済プロバイダが承認した日、注文が出荷された日など、20通りもの定義が存在する可能性があります。さらに、これに千もの他の潜在的なデータフィールドが加わるのです。
もし、製品、SKU、バリアント、サプライヤー、ロケーションなどの定義が固定された「クラシックな」ソフトウェアを作った場合、その定義はクライアントの実情とほとんど一致しません。例えば、アパレル業界では、ある会社はバリアントを単に色とサイズだけで定義するかもしれませんが、別の会社では生地の組成も含むかもしれません。また、食料品業界では「expiration date」が、絶対に販売できない日を意味する場合もあれば、店舗内に陳列できない日を意味する場合もあります。こうした微妙な違いは無限に存在します。
したがって、従来のサプライチェーン理論は不十分であることが明らかになりました。私たちは新しい何か、すなわちプログラム的なアプローチを必要としていました。これはサプライチェーンの教科書では決して扱われないテーマです。既製モデルでは実世界に完全には適合せず、最低注文数量、期限制約、出荷スケジュールの制約など、常に何かしらの例外が存在します。各企業の制約がユニークであるため、解決策は静的な公式ではなく、プログラム的なものにあると私たちは気づきました。そして次に問われたのは、サプライチェーンに適したprogramming paradigmは何か、ということでした。
2012年には、「なぜ単にPythonを使わないのか？」という声も上がったでしょう。実際、当時、私のアメリカのeコマースクライアントは皆それを実践していました。ほとんどのデータサイエンスの試みは、Python（あるいはJava、C#、後のJuliaでも同様）のために失敗しました。パターンとしては、データサイエンスチームが3週間でサプライチェーンに関する印象的なプロトタイプを構築し、その後、本番環境に投入しようとするものの、1年後になっても本番稼働に至らず、経営陣が我慢できずにプロジェクトを打ち切る、という流れでした。
なぜ失敗したのでしょうか？それは千の小さな問題の積み重ね、すなわちNullReferenceException、OutOfQuotaException、同時実行の問題、互換性のないパッケージ、セキュリティ侵害、環境でのランサムウェア攻撃などによるものでした。これらはどれもサプライチェーンの問題そのものに直接関係しているわけではありません。根本的な問題は、大規模な本番環境で汎用言語を使用する場合、問題が発生する攻撃対象面が非常に広くなることにあるのです。たとえば、コードからファイルシステムに書き込むことができると、ギガバイト単位のデータを並列処理しているときに、ホスト環境を思わぬ形で破損してしまう可能性があります。あるプロセスがファイルをロックしていたり、ディスク容量が不足していたりするかもしれません。こうしたことは必然的に夜中に発生し、その場で修正できる人がいないのです。そして朝になると、クライアントはシステムが午前2時に完了すると思っていたのに、真夜中にクラッシュしたとして激怒するのです。
データサイエンスのデモでは、通常、スクリプトを起動するベビーシッターがいるため、クラッシュしてもすぐに修正されます。しかし、現実のサプライチェーン自動化は、毎日無監督で稼働しなければなりません。実行時間さえも20分から2時間に変動し、本番運用を壊してしまいます。これが2012年の問題でした：サプライチェーンロジックそのものではなく、汎用言語の持つ複雑さゆえに、これらのデータサイエンスの試みは本番環境で失敗したのです。
これらすべてから、ロカドは、壊れやすいベビーシッティングに頼らず、かつ大規模な日次運用を扱える、安全で専門化されたプログラム的環境が必要だと認識しました。さらに、高度な予測（確率的、quantileなど）も必要であると気づいたため、Envisionはそれらのワークフローをファーストクラスの市民として扱えるように設計されました。たとえば、機械学習のために微分可能なプログラミングが欲しい場合、汎用言語ではPyTorchのような別の「ミニ言語」を埋め込む必要があります。すると、Pythonに加えてPyTorchコードの塊となり、PyTorchコードは実質的に未コンパイルの文字列なので、ミスが起こりやすくなります。Pythonコード内にSQLクエリを混ぜ込む場合も同じです。すべてが文字列であるため、実行時にタイプミスに気づくのです。一方、Envisionは、これらの機能を組み込み機能として、コンパイル時のチェック付きで扱うことができるのです。
ロカドのアプローチは、ディープラーニングの進歩と並行して進化しました。今では、事前にパッケージ化されたモデルのライブラリに頼るのではなく、自分でプログラム的にモデルを構築できるようになったのです。TensorFlowは、本質的に計算グラフを構築するための言語です。「カタログ」的なモデルに縛られることなく、構造を自ら作り上げるのです。Envisionもまた、これらのアイデアをネイティブに取り入れることができます。たとえば、私たちは最近、確率的最適化に取り組みました。皆さん、確率的最適化が何であるかご存知でしょうか？それは、結果が不確実な関数の数学的最適化、すなわちfuture demandが不明なときにいくつのユニットを購入するかを決定する、というクラシックなサプライチェーンの課題です。より制約の少ない簡単なバージョンは見たことがあるかもしれませんが、実際のビジネスでは、注文最小数量、コンテナのfill rates、カテゴリの制約、複雑なカレンダーなど、多くの制約が山積みです。さらに、コスト／ベネフィットの関数も不確実なのです。これらはすべて、高度なプログラム的概念であると言えます。
総じて、Envisionは機能を次々と追加してきました。今日、私たちはさらにもう一つの革命、すなわち大規模言語モデル（LLMs）の瀬戸際に立っています。皆さんはChatGPTに馴染みがあるでしょう。もしかすると、宿題に使っている人もいるかもしれません。（採点はしませんので、素直に認めてください！）あるいは、プロ版の利用料を払っているかもしれません。興味深いのは、ロカドがサプライチェーン企業としては珍しい「文章文化」を持っていることです。私たちは文章に二段階で依存しています。まず、Envisionのコード自体が、文字通り「何を」しているかをエンコードしています。エクセルで推奨注文を生成し、誰かが手動でそれを修正するようなプロセスは望んでいません。最終的な数字が手動変更なしに自動生成されることを目指しているのです。そして、変更が必要な場合――初めはそうなることもありますが――その変更はワークフローに記録され、クライアントと「なぜ生成されたものを修正したのか？どうすれば手動修正が不要になるのか？」と議論するための材料となるのです。あるいは、修正が実際には有益でなかったと判断された場合、その知見を取り入れることも可能です。
次に、JPMまたはJoint Process Manualという第二の文章成果物があり、これは「なぜ」を説明しています。これは、引き継ぎ時のリファレンスドキュメントであり、クライアントにEnvisionのコードを直接読ませることなく、平易な言葉でイニシアチブの全体像を提供するためのものです。つまり、「何を」を記述するコード層と、「なぜ」を説明する別の文書層が存在するのです。
これはLLMsとの相性が非常に良いのです。なぜなら、LLMsはテキストを処理するからです。生の数値データに対しては万能ではありません。巨大な表をChatGPTに投入しても、意味のある回帰分析は得られないでしょう。ChatGPTは、回帰分析を行うPythonコードの一片しか生成できません。LLMs自体は、巨大な次トークン予測モデルに過ぎず、算術演算のために作られているわけではありません。だからこそ、ChatGPTが基本的な数学に失敗するという冗談があるのです。しかし、コードやテキストベースの指示を与えれば、操作や生成は非常に得意とします。
というわけで、ロカドの立ち位置はこうです。私たちは、2020年～2021年のロックダウン時に実証されたように、何ヶ月も人間の介入ゼロで稼働できる先進的なサプライチェーン自動化システムを持っています。その一方で、倉庫やtrucksで働くブルーカラー労働者は依然として活動していたため、サプライチェーンは止められなかったのです。ロカドはすでに大部分がリモートで機能していたので、サプライチェーンの専門家たちは在宅で作業を継続できました。これが本当のストレステストであり、日々の監視なしで私たちのレシピがどのように動作するかを見極めるものでした。場合によっては、大手クライアントで何百人ものプランナー、マネージャー、またはアナリストが突然不在になっても、サプライチェーンは運営を続けなければならなかったのです。
そして、私たちにとって、その結果は驚くほど良好でした。クライアントがこれによって機能不全に陥ったり、誰かが失踪したりすることはなかったのです。これにより疑問が浮上します。もし500人のホワイトカラーのスタッフなしで12〜14ヶ月間サプライチェーンを運用できるのなら、彼らを再び迎え入れる必要は一体あるのでしょうか？通常、企業は自動化システムを完全に信頼することを恐れますが、ロックダウンは自動化に頼ることを余儀なくさせ、我々が最小限、または全く手動介入なしで大規模なサプライチェーンを運用できることを証明しました。当然、数値レシピを改善するための議論は続いていますが、毎日各店舗の各SKUに対してExcelで微調整を行う大規模なチームを見ることはなくなったのです。
そこで、サプライチェーンの未来を考えると、20年前に取引が電子化されたときに金融業界で起こった変革に似ていると私は感じます。かつては、朝刊を読んで手動で株を売買していたトレーダーが、大規模に自動化されたポートフォリオを扱うクオンツに取って代わられたのです。サプライチェーンにおいても同じ機械化が進むと私は考え、退職するずっと前に標準的な手法となると信じています。もちろん、古い手法に固執する企業に出くわすことはあるでしょうが、その革命はすでに進行中です。
今日、私たちのクライアントの中には、システムを完全に自動運用させているところも多くあります。たとえば、大手フランスのeコマース小売業者であるCdiscountを挙げることができます。私たちは彼らの店舗在庫を完全自動で管理しており、手動介入は一切ありません。これは、レシピの改善に向けた継続的な議論を阻むものではありませんが、毎日の「増減単位」アプローチは終わりました。これは2020年に終息し、現在もその効力を保っています。
結果として、私は、世界中で約500万人もの人々が、毎日Excelで1000のSKUをチェックし、order moreすべきか、生産すべきか、在庫を移動すべきか、価格を変えるべきかを判断するという時代の終焉が訪れると考えています。在庫マネージャー、需要プランナー、供給プランナー、カテゴリーマネージャー、S&OPアナリストなど、あらゆる職種が結局は同じ日常業務、すなわち大量のSKUをチェックする作業に帰着するのです。予算が潤沢であれば、一人あたり100 SKU程度かもしれませんし、予算が限られていれば、一人あたり5000 SKUに及ぶかもしれません。どちらにしても、その時代は終わろうとしていると私は信じています。
なぜ今なのでしょうか？何十年もの間、あらゆる意思決定の自動化は実現できなかったからです。しかし、一定数の企業がそれを実現できることを示せば、他の企業も追随するでしょう。大規模な手動プランニングチームを維持するのは非常にコストがかかり、複数の国で20年以上同じスプレッドシート業務をこなしてきた何百人ものプランナーを再訓練するのは戦略的な転換を図る上でも困難です。これを変えるのは非常に時間がかかります。しかし、完全にプログラム的な手法に移行できれば、迅速に方向転換することが可能です。
これから起こるのは、銀行業界で見られたのと同じ変革です。かつては、人々が一日中手動で取引を行っていましたが、今ではほとんどが自動化されています。私はサプライチェーンにおいても同様の機械化が進むと考えており、たとえあなたが61年働いた後に退職するとしても、その標準が確立されると信じています。古い手法に固執する企業に出会うことはあるでしょうが、その革命はすでに進行中です。
ですから、私のメッセージは、この変革の推進者になるか、ただの傍観者でいるかはあなた次第だということです。あなた方Centralの学生であれば、単なる観察者ではなく、積極的な推進者になる可能性を十分に秘めているはずです。
さて、質問に移りましょうか。50分に及ぶ私の一方的な講義をお聞かせしたので、この内容について何か質問があればどうぞ。
Student: はい、つまり、これらの企業はLokadのようなソリューションに依存するようになるのか、それとも内部で同様の技術を開発できるのでしょうか？
Joannes Vermorel: どちらの可能性もあります。もし技術に精通した企業、たとえば非常に大規模なeコマース企業であれば、時にはその手法を内部化するために、我々のもとで訓練を受けるチームを派遣することもあります。企業が強い技術文化を持ち、すでに多くの開発を内部で行っているならば、確かにそれは可能です。しかし、「難しいことはすべて外部委託する」という文化であれば、おそらく外部委託に頼ることになるでしょう。全体として、ほとんどの企業はLokadを含めた専門のプロバイダーを利用すると思います。もちろん、私自身に偏りはありますが、Lokadがその中に入ると信じたいのです。しかし、いずれにせよ、革命は何らかの形で起こっていると確信しています。
Student: LLMはエンジニアを置き換えない、あくまでLLMを使わないエンジニアを置き換えるだけだと言いましたが、どの要因がAIを制限し、LLMを使用するエンジニアを置き換えられなくしているのでしょうか？換言すれば、AI自身を使うエンジニアに対して、AIが追い越すことを防いでいるのは何ですか？
Joannes Vermorel: もし決定的な答えが分かっていれば、その価値は1兆ドルに匹敵するでしょう。ここ数十年の間に、人工知能の分野では数多くのブレイクスルーがあり、そのたびに私たちが十分に理解していなかった知能の側面が明らかになりました。何度も繰り返されるのは、私たちが「本当の」知能とは何かについて誤解していたという事実です。
例えば、1940年に「優れた知能を示すものは何か」と問われたら、「行列を対角化できる人」と答えるかもしれません。エコール・ポリテクニークには、行列の対角化を専門とする学科があり、それは知的な達成の頂点とされていました。しかし今や、単純なコンピュータアルゴリズムでも行列を対角化できるのですから、私たちはそれを知能とは見なしていません。
AIの歴史の中で、同様のエピソードはこれまでに20回もあり、そのたびに私たちは、かつて「知能」と考えていたものが実際にはそうではなかったことを発見してきました。大規模言語モデル（LLM）には、現在いくつかの顕著な欠点があります――例えば、使用中に実際に何も学習しないことです。彼らは静的なモデルです。プロンプトを与えると、その続きのテキストを返すだけです。同じプロンプトを再度与えれば、同じ続きが返ってくるのです。会話から学ぶことはありません。もちろんファインチューニングは可能ですが、それは外部のプロセスに過ぎません。日々の運用では、記憶や持続的な改善は見られません。演習を通じて人間が何かを学ぶのに対し、LLMはそうではありません。同じシナリオを200回繰り返しても、知識は蓄積されないのです。
もう一つの奇妙な点は、LLMが必要とする膨大なデータ量です。子供はせいぜい1000時間の聴取で、約3年かけて言葉を覚えます。一方で、LLMはインターネット全体、つまり何十億ものトークンを読み込む必要があるようです。あるいは自動運転車を考えてみてください。自動運転車は、20時間のレッスンで人間が習得することを学ぶために、何百万マイルもの（仮想あるいは実際の）走行距離を必要とします。では、なぜ「知能」にこれほどまでのデータが必要なのでしょうか？
このように、私たちは何か根本的な欠陥が存在することを感じ取っていますが、それが正確に何かは分かっていません。もしかすると、次世代のLLMや全く新しいアプローチがこれらの欠点を解消するかもしれませんが、それが明日なのか、20年後なのか、50年後なのかは定かではありません。ヤン・ルカンのように、LLMのアプローチ全体を捨て去るべきだという意見もありますが、私はそうは思いません；おそらく、LLMを微調整することで問題に対処できるのではないかと考えています。誰一人として解決策を持っていない今、私たちはただ分からないのです。
いずれにしても、これらの深刻な制約が、LLMが比較的シンプルな業務であっても完全に人間を代替することを阻んでいます。従って、LLMは使用しないエンジニアを置き換えるでしょうが、使用するエンジニアを必ずしも置き換えるわけではなく、そうした人々は引き続き不可欠な存在であり続けるのです。
Student: 以前、製品が初めは機能しなかったにもかかわらず、Lokadが黒字を維持していたとおっしゃっていました。それはどうして可能だったのでしょうか？資金調達や補助金を受けたのですか？それとも他のサービスを提供していたのですか？
Joannes Vermorel: いいえ、補助金や外部資金は一切ありません。説明しましょう：サプライチェーン市場はやや狂気じみています。1980年代以降、競合他社の典型的なビジネスプランはこうです。ステップ1：莫大な資金、数千万ドルを調達する。ステップ2：例えば航空のような特定の分野に注力して、2～3年間で市場シェアを獲得する。ステップ3：200人の営業担当を雇い、市場の20%をつかみ、やがては崩壊する。そしてこれを繰り返すのです。
このような現象は常に見受けられます。Nikeのような大手企業でさえ、2004年に競合他社の有名なサプライチェーンソフトウェアの失敗により、ほぼ破産状態に陥ったことがあります。『Nikeの大失敗』はWikipediaにも記録されています。実質的に、Nikeの生産の9ヶ月分を台無しにしてしまいました。一方、同じベンダーは多くの顧客にも混乱をもたらし、その後買収され、買収者は最終的に2億5千万ドルの損害賠償を支払う羽目になりました。私の経験では、企業向けソフトウェアでは、たとえ凡庸であっても通常は訴えられることはないので、これらの企業は本当に酷かったに違いありません。しかし、それにもかかわらず、彼らは単に新たな会社を立ち上げ（同じメンバーで）さらに5億ドルを調達したのです。市場は決して学ばないのです。
多くの顧客は、異なるベンダーとのサプライチェーンプロジェクトで数回の惨事を経験した後に、実際に我々のもとを訪れます。サプライチェーンの自動化は古くからの夢であり、その根底にあるデータは1980年代または1990年代からデジタル化されているため、何十年にもわたって挑戦が続けられてきたのです。大企業が失敗プロジェクトを山ほど抱えているのは当然のことです。
これが我々が活動している環境です。巨大な慣性が働き、人々は物事を忘れてしまいます。しかし需要は依然として存在するため、何度も挑戦が繰り返されるのです。一見すると市場は合理的に見えるかもしれませんが、特に企業向けソフトウェアのような不透明な分野では、こうした問題の解決は遅々として進みません。場合によっては、壊滅的な実装が行われても、製品を選んだマネージャーが責任を回避するために、顧客がそれを賞賛するケーススタディを提供することさえあります。皮肉なことに、失敗がマーケティングの物語の中で成功として描かれることもあるのです。これほど混沌とすることもあり得るのです。
Joannes Vermorel: 他に質問はありますか？私が説明したことは、ビジネス界において普通で合理的なもの、つまり皆さんが期待していたものでしょうか？
さて、とにかく、Envisionスクリプトのコーディングに費やした皆さんの時間に心から感謝します。Centralの学生たちが意欲的にEnvisionを使っているのを見ると、とても誇りに思います。十数年前に初めてコンパイラを書いたとき、Centralの学生たちがいつの日かこれを使いこなす姿を見るとは思いもしませんでした。当時はかなりのリスクを伴う賭けでしたし、私たちのビジネスプランには皆さんをEnvisionの前に立たせる計画は含まれていなかったのですが、それが実現したことを大変嬉しく思います。そして、もしRémiやBasilからまだ聞いていなければお伝えしておきますが、Lokadは現在採用中ですので、どうぞご参考にしてください！
