「How Generative AI Improves Supply Chain Management」のレビュー

Joannes Vermorel

ハーバード・ビジネス・レビューは、2025年1月-2月号の一環として、Ishai Menache（Microsoft）、Jeevan Pathuri（Microsoft）、David Simchi-Levi（MIT教授）、Tom Linton（McKinsey）による「How Generative AI Improves Supply Chain Management」¹を発表しました。タイトルからもわかるように、この記事では、LLM（大規模言語モデル）が供給チェーン管理にどのように貢献できるかを示す一連の例が提供されています。この記事の公開に関与しているエリート組織（Microsoft、McKinsey、MIT、そしてハーバードさえも）のリストを考慮すると、優れたテクノロジーであるLLMがどのように供給チェーンの改善に貢献するかを慎重に説明するような深い洞察を期待するでしょう。

しかし、私たちは平凡な貢献を得るだけです。より具体的には、この記事は手抜きで誇張され、深刻に誤ったものであり、技術の流行語に乗ったものです。この記事の全体的な前提は、「LLMは供給チェーンに関連するコードを生成し説明することができる」というものです。著者たちは、私が通常「ガジェット型」と呼ぶアプローチを取っています。ガジェット型のアプローチは、新しいテクノロジーを発見したときに、既存のシステムに急いでその部分を取り付けることで行われます。これは、その部分の制約やシステムにもたらされる変更について何の考慮もなく行われることが一般的です。その結果、このアプローチはいつもガジェットを生み出し、限られた関心を持つ面白いツールを生み出し、ビジネス価値はまったく生み出しません。

関与しているさまざまな組織に対して：

• Microsoft：優れたエンジニアが多数在籍しています。より高い基準を持つ必要があります。

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

• MITとハーバード：理性の声であり、テクノロジーベンダーのくだらないことを増幅させるべきではありません。

まずはっきりさせておきましょう。LLMは供給チェーンの改善に使われることはできますが、アプローチ次第では完全に気を散らす要素にもなり得ます。このポイントは、レビュー対象のハーバードの記事に悩まされている根本的な問題です。Microsoftによる関連する論文²も同様の問題を抱えていますが、明確さのために、私のレビューはハーバードの記事に焦点を当てます。

核心となる技術的な無意味に取り組む前に、注目すべき倫理的な問題を指摘しましょう。この記事は、Microsoft Cloud Supply Chainの宣伝記事に過ぎません。Microsoftは自社のサービスを自由に宣伝することができますが、ハーバード（公開を通じて）とMIT（共同執筆を通じて）を宣伝記事に巻き込むことは私には違和感があります。少なくとも、共著者が明らかな利益相反を抱えていることを記事で指摘すべきです。学術界は、どんなに大きく影響力があるテクノロジーベンダーであっても、秘密の宣伝活動を是認すべきではありません。

免責事項：注意深い読者は、私も利益相反があることに気づいているでしょう。はい、私はサプライチェーンソフトウェア会社を運営しており、したがって、Microsoft、McKinsey、MIT、およびハーバードが広めている無意味なことに反論することに利害関係があります。私のカードは今、テーブルの上にあります。

さて、記事で述べられている主張のレビューに進みましょう。

プランナーは、需要計画の変更（需要の変動）を月次で監視し、修正された計画がすべての顧客要件を満たし、予算ガイドライン内に収まることを確認します… LLMベースの技術はこれをすべて行います。変更を行った人とその理由を詳細に記載した電子メールレポートを自動的に生成します。

要するに、LLMは従業員の煩雑な作業を自動化することができます。ただし、明らかな2つの異議があります。まず、このような役割ベースのポリシーを実行するには、LLMは完全に不要です。単純なプログラミング言語といくつかの命令文で十分です。さらに、データにアクセスしてメールを送信するためには、プログラムの設定が必要です。そのような状況では、LLMは具体的な利益をもたらさない大規模なエンジニアリングの複雑さをもたらすことが保証されています。実際に、LLMは非常に遅く、非常に高価です。ルールの短いリストよりも10の桁で悪いです。これは、他のすべてが失敗した場合に使用されるべきツールですが、今回の場合は明らかにそうではありません。

さらに、上記で指摘された煩雑な作業は完全に不要です。企業はこのような無意味なタスク³を排除すべきです。官僚主義は十分に悪いですが、技術主義はさらに悪いです。複雑で高価な技術を持ち込むことで、官僚主義はその機能不全の方法により一層強固になることが保証されます。私の会社であるLokadは、この種の煩雑な作業を10年以上も排除するためにリファクタリングしており、LLMのような複雑で高価なものは必要ありません。

これらの契約では、OEMが支払う価格の詳細、品質要件、リードタイム、およびサプライヤが供給を確保するために取るべき回復策が指定されています。数千の契約からLLMにデータを供給した後、あるOEMは、あるボリュームのしきい値を超えたために自分たちが権利を持っている価格削減を特定することができました。

サプライヤとの契約条項の一部を適用することに企業が通常失敗することは事実ですが、関連する契約条件を特定することは課題のごく一部です。おそらく1%以下です。さらに、準備なしでChatGPTのようなツールを使用してこれを解決することができます。クエリを作成し、ユーザーインターフェースを介してすべてのPDFを繰り返し送信するだけです。このような些細なことは、LinkedInの投稿「今日ChatGPTでやった10のこと」というタイトルの投稿に属しており、ハーバード-MITの出版物には属していません。

さて、実際の課題は2つの側面を持っています：計測と関係です。計測の側面では、注文と支払いの手続きは、ほとんどの「サプライチェーン」を運営する企業では大部分が自動化されています。したがって、周辺のエッジケースに対処するには、十分なサポートの計測がなければ、すべてが複雑化し、遅延します。

さらに、関係の側面では、何年も無視されてきた契約条項を活性化できると考えるのは単純すぎます。ほとんどの場合、サプライヤは既にクライアントのこの緩い行動を価格に組み込んでおり、周辺の契約条件についての細かいことを言われると同じように応えるか、おそらく価格の引き上げを通じて応えるでしょう。

一般的に、割引や価格の変更は通常のトランザクションビジネスシステムの一部として管理されるべきです。これはロケット工学ではありませんが、単なる古いCRUD⁴です。再び、いくつかの命令ルールで十分な場所にLLMを持ち込むことは技術的に無意味です。

LLMを使用すると、プランナーは詳細な質問をすることができます。以下にいくつかの例を示します。「製品の総需要が15％増加した場合の追加輸送コストはいくらですか？」…こうした質問にLLMが正確かつ効率的に答える方法を説明します。多くの最適化タスクは数学的なプログラムの形式で書かれています… LLMは人間のクエリを数学的なコードに変換し、計画を作成するために使用された元の数学モデルに対する小さな変更となります。

これは甘い考えです。現在までに、「統一された一体型のコードベース」を利用して彼らのサプライチェーンの意思決定を導出している企業の割合はほぼゼロです（以下で詳しく説明します）。代わりに、企業は無数のスプレッドシートを持っています。著者たちが描いている美しい絵とは異なり、LLMに対話するための「数学的なプログラム」はありません。LLMは、概念的には、散らかった半時代遅れのスプレッドシートを編集して改善することができますが、それ以外の証拠が示されるまでは、これは純粋な推測です。最新のLLMでさえ、1つの大きなスプレッドシートを編集するのは困難です。スプレッドシートに伴う受動的なコードの重複は、LLMにとっては全く好ましくありませんが、数百、もしくは数千のシートを理解することは、現時点ではまったくの空想です。

さて、実際にサプライチェーンの意思決定プロセスを管理する統一された一体型のコードベースを利益を得ている企業は、実際にはいくつかあります。具体的には、_Lokad_のクライアントです。もし著者たちが私たちと同じように実際に経験を持っていたならば、彼らはそのコードベースがかなりの規模であることを知っていたでしょう。通常、数万行のコードです。ただし、私たちはサプライチェーンに特化したDSL（ドメイン固有言語）⁵を使用しているにもかかわらず、このDSLはこの種のタスクにおいてPythonやJavaよりも約10倍短くなっています。残念ながら、ショートカットはありません。興味のあるどんな意思決定にも、数十のテーブルが関与し、数百のフィールドをカバーしています。私たちのDSLがさらなる改善によってコードの行数をさらに減らすことができる可能性は考えられますが、それらのコードベースは決して「小さく」はなりません。

再び、LLMは概念的には、非技術的な貢献者の指示に従って複雑なコードベースを編集して改善することができます。しかし、これは再びSFの領域です。LLMは既に、_能力のあるプログラマ_にとって素晴らしい生産性ツールとして証明されています。言い換えれば、プログラムの作成を早くするためにLLMを使用することができます。しかし、これは記事の著者が言っていることではありません。彼らの提案は、LLMを使用して非技術的な貢献者が技術的な貢献を行うことができるというものです。現在のLLMの最先端を考えると、この提案は、現実のサプライチェーンの複雑さを反映していない小さな砂場の中でのみ真実ではないかと思われます。

プランナーは、LLMの技術を使用してサプライチェーンの構造とビジネス要件の数学モデルを現在のビジネス環境に合わせて更新することができます。さらに、LLMはプランナーにビジネス状況の変化を通知することができます。

著者たちはSFを強調しています。この主張は、「LLMが非技術的なユーザーが提出したチケットに基づいてGitHubのコードリポジトリにパッチを発行することができる」と技術的に区別できません。これが可能であれば素晴らしいニュースですが、現在のLLMは、真剣な要求に対してこのような偉業を確実に達成することからは程遠いです。 新しい技術のユースケースを提示する際には、その技術の限界を正確に伝えることが重要です。4人の共著者は、現在のLLMの最先端について全く無知のようですが、私は彼らがそうではないことをほのめかしています。代わりに、彼らがやっていることを熟知している人々によるインフォマーシャルのくだらない話を聞かされます。これはおそらくはるかに悪いことです。

サプライプランを変更する必要性は、LLMベースの技術によっても引き起こされる場合があります。たとえば、特定のサプライヤーからの出荷データを分析した後、サプライヤーからのリードタイムが過去数か月間で大幅に増加したことを示す警告を生成する場合があります。

リードタイムが異常であるかどうかを検出することは、LLMができることではありません。ただし、LLMには、この分析を実行するためのコードの一部を書くように促すことはできます。LinkedInの投稿「今日ChatGPTでやったトップ10のこと」に戻っています。なぜそこで止まって、リードタイム情報が消費される注文ロジックを直接更新しないのでしょうか？これは、著者たちが記事の後半で提案していることです。

私たちは、将来数年間において、LLMベースの技術がエンドツーエンドの意思決定シナリオをサポートすると予想しています。

もし著者が「サポート」という言葉で「プログラマーをより生産的にする」と述べているのであれば、それはすでに可能です。実際、Lokadは長い間それを行ってきました。ただし、もし人間のプログラマーを絵から取り除くと、この声明は「将来数年間においてLLMベースの技術がAGI（人工汎用知能）を達成する」というものに近づきます。

著者たちは、「Gen AI」という言葉に乗っかって、LLM自体に制約がある可能性を完全に無視しています。彼らが「障壁の克服」という結論のセクションで提案していることは次のとおりです：

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

いいえ、これは完全に間違っています。ただし、「非常に正確な言語」とは「プログラミング言語」として理解される場合（それらは実際に非常に正確です）、LLMを使用してサプライチェーンを最適化するには、より遅くなるかもしれませんが、完全に自分自身でコーディングできる人間のエンジニアが必要です。将来的には、プログラミングに熟練する以外に、トレーニングの量はユーザーがLLMのサポートを受けながらサプライチェーンの最適化を行うことができるようにすることはありません。

CEOやサプライチェーンディレクターに対して、「正確な言語」を使うためにチームをトレーニングするだけで済むと言うのは完全に誤解を招くものです。この考え方から生まれるトレーニングワークショップは、関係するすべての当事者にとって完全な時間の無駄になることが保証されています。

検証。LLM技術は時折誤った出力を生成する場合があります。したがって、一般的な課題は、技術を「レールの内側」に保つこと、つまり、間違いを特定し、それから回復することです。

LLMは設計上確率的ですが、これはサプライチェーンシステム全体に渡る意味的な不確実性に比べれば微々たるものです。言い換えれば、LLMは間違った問題に対して正しい答えを与える可能性が非常に高いです。Lokadの経験からは、特定の実装（サプライチェーンの意思決定を駆動する）が正しいかどうかを確認する唯一の方法は、限定的な実験テストを行うことです⁶。現実世界のフィードバックは選択肢にありません。知識は空気から生み出すことはできません。たとえAGIレベルのLLMであっても、この障壁に直面することになります。

ここで、著者たちは「埋める」ことになります。彼らはLLMの性質について正しいが些細な声明をしており、その問題が中心的な関心事であるかどうかを調べることさえ試みていません。もし著者たちが実際にLLMを使用して実世界のサプライチェーンを管理していたのであれば、私たちと同様に、この懸念はより大きな問題のリストの中で小さな問題であることに気づいたはずです。

結論として、Brandoliniの法則がここに当てはまります。「バカなことを論破するために必要なエネルギーは、それを生み出すために必要なエネルギーよりも桁違いに大きい」。この記事はひどいものであり、ChatGPTによって書かれたかもしれません（実際、私が知る限りでは毎日同じようなひどい記事が数十本書かれています）。著者の悪名が私をこのレビューをまとめることに駆り立てました。一歩引いて考えると、ベンダーが何の実質的な提案もなくドメインを革新することを約束するのは初めてではありません。ただし、同じベンダーが同じドメインで2年連続でそれを行うのはやりすぎかもしれません⁷。それでも、学界はブームに乗ることなく批判的思考を少なくとも試みるべきです。