「How Generative AI Improves Supply Chain Management」に関するレビュー

Joannes Vermorel

ハーバード・ビジネス・レビューは、2025年1月-2月号の一環として、最近、Ishai Menache（Microsoft）、Jeevan Pathuri（Microsoft）、David Simchi-Levi（Professor, MIT）、および Tom Linton（McKinsey）による How Generative AI Improves Supply Chain Management¹ を発表しました。タイトルが示す通り、この記事はLLM（大規模言語モデル）が supply chain management に寄与できる例を一連に示していると述べています。Microsoft、McKinsey、MIT、さらには Harvard といったエリート組織が本論文の発表に関与していることを考えれば、誰もが、優れた技術―LLM―がサプライチェーンの改善にどのように貢献するのかを、慎重に説明する深い洞察を期待したことでしょう。

しかし、実際に示されたのは平凡な寄与に過ぎません。より正確には、それは怠慢で誇張的、かつ根本的に誤ったものであり、ただの技術的流行語に乗っかったものです。記事の前提は、LLMはサプライチェーンに関連するコードを生成し、解説することができる というものに要約されます。著者らは、私が通常 ガジェット的 と呼ぶ見解を採っています。ガジェット的な見解とは、新たな技術が発見された際に、その技術を既存のシステムに慌てて組み込むというものです。これは、その技術の限界やシステムに与える影響を一切考慮せずに行われ、結果として、関心の薄い面白おかしいツールばかりが生み出され、ビジネス上の価値が全く提供されないのです。

関係する各組織へのメッセージ:

• Microsoft: 貴社には多くの才能あるエンジニアが在籍しています。より高い基準を自らに求める必要があります。

• McKinsey: 潜在的なクライアントを、時間とお金の無駄になる方向へ導かないでください。

• MIT と Harvard: テックベンダーの無意味な言説を増幅するのではなく、理性的な意見を発信すべきです。

ここで明確にしておきたいのは、LLMがサプライチェーンの改善に利用できることには私も同意するものの、アプローチ次第ではLLMが全くの気晴らしになり得るという点です。これこそが、今回レビュー対象となる論文の根本的な問題点です。Microsoftによる²別論文も同様の問題を抱えていますが、明確さのために、私のレビューはハーバードの記事に焦点を合わせます。

本題である技術的ナンセンスに入る前に、著しい倫理的問題を指摘しておきます。この記事は、Microsoft Cloud Supply Chain の薄っぺらい宣伝に過ぎません。Microsoftは自社サービスの宣伝方法を自由に選べるのは当然ですが、Harvard（出版を通じて）とMIT（共著を通じて）を宣伝活動に巻き込むのは、私にとって非常に不快です。少なくとも、共著者に明らかな利益相反が存在することを示すべきです。学界は、規模や影響力に関わらず、テックベンダーの秘密の宣伝活動を容認すべきではありません。

Disclaimer: 洞察力のある読者は、私にも利益相反があることにお気づきのはずです。はい、私はサプライチェーンソフトウェア企業を経営しており、したがってMicrosoft、McKinsey、MIT、Harvardが広めるナンセンスに反論する利害関係を有しています。私の手札は、すでにテーブルの上にあります。

では、この記事が主張する内容のレビューに進みましょう。

プランナーはまた、需要計画の変化、すなわち「需要ドリフト」を毎月監視し、改訂後の計画が全ての顧客要件を満たし、予算のガイドライン内に収まっていることを確認します[…] LLMベースの技術はこれらすべてを自動で行い、誰がどの変更を行ったのか、その理由まで詳細に記したメールレポートを自動生成します。

要するに、LLMは雑用をこなす従業員の業務を自動化できます。しかし、ここで二つの明白な反論があります。まず第一に、このような役割に基づくポリシーの実行にLLMは全く必要ありません。簡単なプログラミング言語といくつかの命令文で十分なのです。さらに、データにアクセスしてメールを送信するためのプログラム的な配管は、もともと必要なものであり、LLMは多大な工学的複雑性を招くだけで、目に見える利益を何ももたらしません。確かに、LLMは非常に遅く、非常に高価であり、短いルールのリストと比べて約 10 orders of magnitude 劣るのです。LLMは最終手段として使われるべきツールですが、ここでは全くそうではありません。

第二に、上述の雑用は全く不要なものです。企業はこのような無意味な業務を廃止すべきです³。官僚主義はそれ自体で十分に厄介ですが、技術官僚主義は_さらに悪い_ものです。過度に複雑な技術を導入すれば、官僚主義がその機能不全のまま固執することは必至です。私の会社であるLokadは、十年以上にわたってこのような雑用を排除するためのリファクタリングを行っており、LLMのような複雑で高価な技術は全く必要としていません。

これらの契約は、OEMが支払う価格の詳細、品質要件、リードタイム、そしてサプライを確保するためにサプライヤーが講じるべき回復措置を指定しています。数千の契約書からLLMにデータを供給した結果、あるOEMは、一定量を超えた際に受けるべき値引きを特定することができました。

企業がサプライヤーとの契約条項を適用するのに日常的に失敗しているのは事実ですが、重要な契約条件を特定することは、全体のごく一部 ― たとえば1%、あるいはそれ以下 ― にすぎません。しかも、それは準備不要のChatGPTのようなツールで十分に対応可能です。ユーザーインターフェースにPDFを次々と送り込むだけで、問い合わせを作成するだけで済むのです。このような些細な作業は、「今日ChatGPTでやった10のこと」と題されたLinkedInの投稿にふさわしく、Harvard-MITの出版物にあるものではありません。

さて、実際の課題は二つに分かれます。それは、インストゥルメンテーションとリレーションシップです。インストゥルメンテーションの面では、注文や支払いを発行する書類上の手続きは、ほとんどのサプライチェーンで自動化されています。したがって、十分な支援機構が整っていなければ、周辺的な事例に対処することで、全体が複雑化し、遅延を招くことになるのです。

さらに、リレーションシップの観点から、もし契約条項が何年にもわたって無視されてきたのであれば、企業が何の影響もなくその条項を発動できると考えるのは単純な考えです。多くの場合、サプライヤーはすでにクライアントの緩い対応を自社の価格に織り込んでおり、周辺的な契約条件を細かく問題視すれば、同様の対応――もしくは価格の引き上げ――で応じられるのです。

一般的に、割引や値引きは、通常の取引業務システムの一部として管理されるべきです。これはロケット工学ではなく、単なるCRUD⁴の問題です。改めて言えば、いくつかの命令的なルールで十分な場面にLLMを導入するのは、技術的に無意味なのです。

LLMはプランナーに詳細な質問を投げかけることを可能にします。以下はいくつかの例です: 「全体の製品需要が15%増加した場合、追加の輸送コストはどれほどになるか？」 […] このような質問に、LLMが正確かつ効率的に答える様子が示されています。多くの最適化タスクは数理プログラムの形で書かれており、LLMは人間の問いを、計画を作成するために使用される元の数理モデルに些細な変更を加える数学的コードに変換します。

これは希望的観測に過ぎません。現時点で、supply chain decisionsを導出するための「統一されたモノリシックなコードベース」を持つ企業の割合は事実上ゼロです（詳細は後述します）。その代わりに、企業は途方もない量のスプレッドシートに依存しています。著者らが描いている美しいイメージとは異なり、LLMが対話可能な「数理プログラム」は存在しません。概念的には、LLMが半ば時代遅れの乱雑なスプレッドシートの山を編集・改善できるかもしれませんが、証明されるまでは純粋な憶測に過ぎません。最新のLLMでさえ、大規模なスプレッドシートを編集するのは困難であり ― スプレッドシート特有の受動的なコード複製は、LLMにとって全く好都合ではありません ― 何百、いや何千ものシートを理解するのは、現時点では純粋なサイエンスフィクションの領域です。

さて、統一されたモノリシックなコードベースでサプライチェーンの意思決定プロセスを管理し、その恩恵を受けている企業は確かに数社存在します ― すなわち、_Lokadのクライアント_です。もし著者らが我々のように実際の経験を持っていれば、これらのコードベースが通常、何万行にもおよぶ大規模なものであり、サプライチェーン専用のDSL（Domain-Specific Language）⁵を用いているという事実に気づいていただろうでしょう。ちなみに、このDSLは、この種のタスクにおいてPythonやJavaよりも約10倍も簡潔です。残念ながら、近道は存在しません。興味深い意思決定に関わる限り、何十ものテーブル、何百ものフィールドが計算に関与するのです。仮に我々のDSLがさらに改良され、コード行数が減少したとしても、これらのコードベースが「小さい」とは決して言えないのです。

改めて、LLMは概念的には非技術者の指示を受けて複雑なコードベースを編集・改善できるかもしれません。しかし、これもまたサイエンスフィクションの域を出ません。現に、LLMは_有能なプログラマー_にとっては素晴らしい生産性向上ツールであることが証明されています。つまり、プログラミングができるのであれば、LLMはより迅速にプログラムを書く手助けとなるのです。しかし、これが著者らが主張する内容ではありません。彼らの提案は、LLMを用いて非技術的な貢献者にも技術的な貢献を行わせるというものです。しかし、現状のLLMの技術水準に基づけば、この提案は、実際のサプライチェーンの巨大な複雑性を反映しない小さなサンドボックス内でのみ当てはまる、常に誤ったものです。

プランナーは、LLM技術を用いてサプライチェーンの構造やビジネス要件を反映する数理モデルを更新し、さらにビジネス環境の変化についてプランナーに通知することができます。

著者らはサイエンスフィクションの域にまで踏み込んでいます。この主張は、技術的には「非技術ユーザーが提出したチケットに基づいて、LLMがGitHubのコードリポジトリにパッチを適用することができる」というのと変わりません。もしこれが実現可能ならば素晴らしいニュースですが、現時点のLLMは、真剣な要求に対してこのような偉業を安定して成し遂げるには程遠いのです。 新技術のユースケースを提示する際には、その技術の限界を正確に伝えることが重要です。4人の共著者は、現行のLLMの技術水準を全く認識していないかのように振る舞っていますが、実際はその逆であり、何をしているのかを十分に理解した上で行動しているという疑いがあり、これはむしろ大きな問題です。

サプライプランの変更は、LLMベースの技術によっても促される可能性があります。例えば、特定のサプライヤーの出荷データを分析した結果、ここ数カ月でそのサプライヤーのリードタイムが大幅に延長したという警告を発する場合などです。

異常なリードタイムを検出することは、LLMが行えることでは全くありません。ただし、LLMに解析を行うコードの作成を促すことは可能です。ここでまた、『今日ChatGPTでやったトップ10のこと』というLinkedInの投稿に立ち返ってしまいます。なぜそこで止まり、リードタイム情報が利用される注文ロジックを直接更新しないのでしょうか？これこそが、記事後半で著者らが提案している内容なのです。

今後数年間で、LLMベースの技術がエンドツーエンドの意思決定シナリオを支援するようになると私たちは見込んでいます。

もし「支援する」という言葉で、著者らが「プログラマーの生産性を向上させる」という意味を示しているのであれば―すなわち、プログラマーがエンドツーエンドの意思決定のためのコード作成に専念できるようになるという意味で―それは既に可能であり、実際Lokadもこれを長らく実践してきました。しかし、人間のプログラマーを排除した場合、この主張は「今後数年間で、LLMベースの技術がAGI（汎用人工知能）を達成する」という内容に近づいてしまいます。

著者らは「Gen AI」という流行語に乗じ、LLMにも何らかの限界が存在する可能性を全く軽視しています。以下は、彼らが「障壁の克服」という結論部分で提示している内容です：

採用とトレーニング。LLMを用いてサプライチェーンを最適化するには、非常に正確な言語が必要です[…] それぞれの解釈が異なる意思決定を導きます。

いいえ、これは全くの誤りです ― ただし「非常に正確な言語」を「プログラミング言語」と解釈する場合を除きます（実際、プログラミング言語は非常に正確です）。LLMを用いてサプライチェーンを最適化するためには、人間のエンジニアが、自力で完全にコードを書く必要があり、たとえその速度が遅くとも、その能力が求められます。近い将来、プログラミングの習熟以外に、どんな訓練を積んでも、LLMの支援によってサプライチェーンの最適化を実施できるユーザーにはなれないのです。

CEOやサプライチェーンディレクターに、単にチームに「正確な言語」を使えるよう訓練すればよいと伝えるのは全く誤解を招くものであり、その結果として実施されるトレーニングワークショップは、関与する全ての人にとって完全な時間の無駄になるでしょう。

検証。LLM技術は、時折誤った出力を生み出す可能性があります。したがって、技術を「レール内」に保つ、すなわち誤りを特定しそれを修正することが、一般的な課題となります。

LLMは確率的な設計であるにもかかわらず、この問題はサプライチェーンシステムに蔓延する意味的な不確実性に比べれば取るに足らないものです。言い換えれば、LLMは極めて高い確率で、_正しい_答えを_間違った_問題に対して返す可能性があるのです。Lokadの経験では、サプライチェーン意思決定を駆動する実装が正しいかを確認する唯一の方法は、限定的な実験テストを行うこと⁶であると示しています。現実のフィードバックは選択肢にありません。知識は無から生成されるものではなく、AGIレベルのLLMであってもこの障壁に直面することでしょう。

ここで、著者らは単に穴埋め的な説明に終始しています。彼らはLLMの本質について正しい――しかし些細な――主張をしているだけで、その問題が根本的な懸念に値するかどうかを検証しようとはしていません。もし著者らが実際にLLMを活用して現実のサプライチェーンを管理していたならば、この懸念が、はるかに大きく、影響度の高い問題の長いリストの中のごく小さなものに過ぎないことに気づいていただろうでしょう。

結論として、Brandoliniの法則がここに当てはまります： デタラメを否定するために必要なエネルギーは、それを生み出すために必要なエネルギーよりも桁違いに大きいのです. 本記事はあまりにも質が低いため、ChatGPTによって書かれた可能性すらあり、実際そうであったかもしれません。私のささやかな観察に基づけば、Gen-AIとSCMに関して毎日同様に質の低い記事が何十本も生産されています。著者たちの悪名が、このレビューをまとめる動機となりました。一歩引いて考えると、実質的な何も提供できないまま、あるベンダーがある分野を革新すると約束するのは初めてではありません。しかし、同じベンダーが⁷ 2年連続で _同一分野内で_それを行うのは、やや過剰かもしれません。とはいえ、学界は喜んで流行語のバンドワゴンに飛び乗るのではなく、せめて批判的思考を試みるべきです。