00:00:00 インタビューの紹介
00:01:01 伝統的な仕事に対するAIの影響
00:04:36 供給チェーンにおけるAI自動化
00:09:08 2012年の統一システムの必要性
00:10:30 システムへの意思決定の再注入
00:13:08 AIにおける幻覚問題の回避
00:16:11 ITバックログによる影響と遅延
00:20:04 Lokadと他のベンダーのセットアップの比較
00:23:06 LLMの幻覚と捏造についての議論
00:30:38 AIにおける完璧さより進歩を強調
00:33:00 欠落情報の取得と注文のETA
00:36:17 供給チェーンにおける定量タスクとLLM
00:38:28 供給チェーンにおけるAIパイロットの未来
00:41:18 会話の価値と低付加価値タスクの自動化
00:44:57 AIパイロットを活用してバックログを削減
00:49:00 AIパイロット対コパイロットとロックダウンシナリオ
00:53:36 対話型AIとプロセス分析に対する懐疑論
00:57:18 ビジネス現実の理解とAIによるプロセスの代替
01:00:12 Envisionのオープンソース化の課題
01:06:21 ボトルネックと供給チェーンに対するAIのアプローチ
01:09:17 口頭指示の非効率性と注文の自動化
01:14:12 AIパイロットのコパイロットとしてのサプライチェーンサイエンティスト
01:17:32 データの正確性の確認とLLMを用いたチェックの自動化
01:20:15 EnvisionをGitに対応させる
01:21:14 Envision学習のための無料リソース
概要
LokadのCEOジョアネス・ヴェルモレルとコミュニケーション責任者コナー・ドハティとの対話の中で、彼らはAIが供給チェーン管理に与える影響について議論します。ヴェルモレルは、AIと大規模言語モデルの進歩がタスクの自動化に革命をもたらしたことを強調します。彼は、Lokadの独自プログラミング言語Envisionを用いて意思決定および事務作業を自動化するLokadの提供であるAIパイロットを紹介します。さらに、ヴェルモレルはAIがマスターデータに関連するタスクを自動化する可能性について議論し、Lokadのアプローチと競合他社のそれを対比させます。彼は、AIパイロットが供給チェーン管理の標準となり、著しい生産性向上をもたらすと予測しています。対話はQ&Aセッションで締めくくられます。
詳細な概要
最近の、Lokadのコミュニケーション責任者コナー・ドハティと創設者であるCEOジョアネス・ヴェルモレルとの対話において、両者は供給チェーン管理における人工知能（AI）の変革的役割について掘り下げました。この議論は、AIが雇用に与える影響に関する以前の対話の続編であり、AIが供給チェーンの意思決定において単独のパイロットとして機能する可能性に焦点を当てています。
ヴェルモレルは、2023年における生成的AIおよび大規模言語モデル（LLM）の画期的な成果を強調することから始めました。これらの進歩は、メールの読解や苦情の分類といったテキストに関連するタスクの自動化に革命をもたらしたと彼は説明しました。2023年は、企業における自然言語処理技術の運用コストが大幅に削減された年として特に重要でした。ヴェルモレルは、これにより多くの内部サポート機能が自動化され、供給チェーン運用がその先頭に立つと予測しました。
その後、ヴェルモレルは意思決定プロセスを自動化し、日常的な事務作業を処理するLokadの提供であるAIパイロットを紹介しました。彼は、1人のサプライチェーンサイエンティストがイニシアチブを完全に担えるという、Lokad独自のアプローチを強調しました。これは、供給チェーンの予測最適化に特化したLokad独自のプログラミング言語Envisionによって実現されています。しかし、ヴェルモレルは、これまでLokadがデータ探索やさまざまなSQL方言への対応に苦慮していたことを認めました。
ヴェルモレルによれば、GPT-4の導入はLokadにとって画期的な転機となり、同社がSQLクエリの自動作成を実現することを可能にしました。これらのクエリはその後、サプライチェーンサイエンティストによって校正され、精度が確保されるようテストされます。この進展は、安全なクラウド間接続と組み合わさることで、Lokadのサプライチェーンサイエンティストチームがクライアントのデータを自律的に追跡し、遅延を軽減することを可能にしています。
ヴェルモレルはまた、LLMが調査、監視、改善など、マスターデータに関連する多くのタスクを自動化する可能性についても強調しました。彼は、Lokadのアプローチが、通常イニシアチブに関与する人数が少なく、各担当者が全工程に精通している点で、プロジェクトマネージャー、コンサルタント、UXデザイナー、データベース管理者、ネットワークスペシャリスト、プログラマーなど多数の人員を必要とする競合他社のアプローチと大きく対照的であると述べました。
その後、会話はLLMによって生成されたスクリプトの検証および監視におけるサプライチェーンサイエンティストの役割に移りました。ヴェルモレルは、LLMが時には不正確または「幻覚」的な結果を生むことがあると認めましたが、これらの結果は通常、方向性は正しく、フィードバックループを数回繰り返すことで訂正可能であると述べました。彼は、LLMが誤りを犯すことはあっても多大な価値を提供でき、偽陽性および偽陰性の割合を測定可能であると示唆しました。
さらにヴェルモレルは、サプライチェーンサイエンティスト、AIパイロット、クライアント間の日常的な連携について説明しました。サプライチェーンサイエンティストによって作成されたAIパイロットは、供給チェーンの日々の運用を担当し、データ準備や発注決定などの細部を管理します。この仕組みにおいて、クライアントは全体的な戦略を指示するキャプテンに例えられます。
供給チェーンの実務者や経営陣への示唆として、ヴェルモレルは10年後にはAIパイロットがSCMの標準となると予測しました。これにより、従来の機能における人員が最大90%削減されるという大幅な生産性向上が実現されると考えています。彼は、供給チェーン実務者が戦略的思考やサプライヤー、クライアントとの詳細な対話により多くの時間を割くことを促しました。
対話はQ&Aセッションで締めくくられ、そこでヴェルモレルは、ITバックログ削減におけるAIパイロットの役割、AIパイロットとコパイロットの違い、AIモデル導入前のプロセス分析の重要性、Envisionのオープンソース化に関するLokadの計画、そしてランダムなボトルネックに対するAIの対応方法など、さまざまなトピックに関する質問に答えました。また、LokadがLokadコパイロットの開発に取り組んでおり、EnvisionをGitHubにより適合させる計画であることも確認しました。
完全なトランスクリプト
Conor Doherty: Lokadライブへようこそ。私の名前はコナーです。私はここLokadのコミュニケーション責任者です。そして、スタジオにはLokadの創設者であるジョアネス・ヴェルモレルが同行しています。
Conor Doherty: 本日のトピックは、AIが供給チェーンの意思決定において単独のパイロットとして機能する方法についてです。YouTubeチャットにていつでもご質問をお寄せください。30〜35分後に回答いたします。
Conor Doherty: それではジョアネス、供給チェーンにおけるAIパイロットについてですが、この対話は約4週間前に行った、AIが雇用や伝統的な仕事に与える影響と供給チェーンの未来について語った対話の延長線上にあると感じます。
Conor Doherty: では、AIパイロットの具体的な話に入る前に、それを見逃した方々のために、伝統的な仕事と供給チェーンにおけるAIについて、改めて簡単なエグゼクティブサマリーとして我々の見解を教えていただけますか？
Joannes Vermorel: 改めて申し上げると、2023年において実質的な画期的進展がありました。その進展とは生成的AI、より具体的には大規模言語モデル（LLM）のことです。純粋な研究の観点から見ると、これはほぼ40〜50年にわたる機械学習の継続的進歩の延長線上に過ぎません。研究視点から見れば、2023年は長い進歩の歴史の中の一つの年に過ぎず、過去20年ほどで比較的速いペースで進展してきました。
さて、2023年には、画像向け、そしてより重要なことにテキスト向けのパッケージ化された生成AIが市場に登場しました。そして、それを普及させた製品がひとつあります。それはOpenAIのChatGPTです。これはどういう意味かと言うと、特に大規模言語モデルにおいて、あなたは普遍的なノイズに対してレジリエンスを持つテンプレート生成マシンを手にしたことを意味します。
つまり、企業ソフトウェアにおけるホワイトカラー労働者を想定した文脈で、過去にはテキストをあらゆる形で扱わねばならなかったために自動化できなかったあらゆる工程、たとえばメールを読む、メールから参照や価格、数量を抽出する、パートナーやサプライヤー、クライアントからの苦情や依頼の種類を分類する、または製品ラベルが意味不明である（例：製品説明が欠落している場合など）といった作業は、他の手段もありましたが容易に自動化はできませんでした。
たとえば5年前に遡れば、テキストマイニングは既に存在しており、テキスト分類器や各種の自然言語処理技術を用いることは可能でしたが、それらは高コストでした。2023年は、基本的にAPIを通じたGPT-4のパッケージ化により、これらの自然言語処理技術の運用コストが100倍、場合によっては1,000倍も削減されたため、画期的な年となりました。これは、コストだけでなく、システム構築にかかる時間も大幅に短縮されたことを意味します。
つまり、私の予測としては、企業内の内部サポート機能、すなわちデータを受け取り他部門にアウトプットを提供する業務が大幅に自動化されるということです。供給チェーンは顧客向けの機能ではなく、非常に内部向けの機能であるため、大規模言語モデルが、供給チェーン内の日常的な業務をエンドツーエンドで自動化するための欠けたピースだったと言えるのです。
Lokadは過去10年間、定量分析および定量的意思決定プロセスを自動化してきましたが、その前後には多数の日常業務が存在します。そして、これらの業務は大規模言語モデルによって迅速かつ低コストで自動化可能となります。
Conor Doherty: ありがとうございます。また、この件については約1時間半にわたって話し合ったビデオも既に存在していますので、本日はそれ以上割愛しませんが、これが残りの対話の土台となります。もっと詳しく知りたい方は、前回のビデオをご覧ください。それでは、先ほどの話に沿って、AIパイロットは実際にどのような位置付けなのでしょうか？彼らは何をし、実際にはどのように機能するのですか？
Joannes Vermorel: 一般に「AI」という用語は、過去20年間、ベンダーが自社製品を包括的に表現するためのキャッチフレーズやオールインワンの概念として一貫して使用されてきました。ですから、私が言うAIパイロットは、まさにLokadの提供の一部です。それは提供内容の進化であり、ここ数年で最も大きなものと言えます。違いを説明しますと、AIパイロットとは、意思決定プロセス、すなわち供給チェーンの純粋な定量的側面（具体的には発注量の算出、在庫の配分、価格調整、生産スケジュールの全工程の策定など）を実行するだけでなく、ソフトウェア、いわゆる一連の数値的レシピとして機能するものなのです。
つまり、これまで我々が行っていたことに加え、データ分析前の主にマスターデータ管理に関する日常的な事務作業や、発注判断の実行時に、例えばサプライヤーに対して迅速な対応を依頼するメール送信、あるいは注文の延期を依頼するなど、前後の事務作業も含まれるのです。
そして、この提供の核心は、もちろんLokadが独自に発明したものではなく、私たちが14か月以上にわたって広範に使用してきた大規模言語モデルにあります。そして、Lokadの運用方法において最も重要な考えは、イニシアチブを完全に担えるのは1人のサプライチェーンサイエンティストであるべきだということです。
非常に大規模な企業では複数の担当者が関与する場合もありますが、ほとんどの競合他社とは異なり、彼らは通常専門分化していません。つまり、Mr. Database、Mr. Algorithms、Mr. UIおよびUXといった複数の専門家によるチームを組むのではなく、1人のサプライチェーンサイエンティストが最初から最後まで全てを担うのです。
そしてこれが、Lokadが自社技術をこのように設計し、供給チェーンの予測最適化に特化したドメイン固有のプログラミング言語Envisionを採用している理由のひとつです。特注のプログラミング言語を考案するのは非常に奇妙に聞こえるかもしれませんが、その核心は、2012年に私が下した決断であり、全工程を1人で一貫して行うための統一された仕組みが本当に必要であったということです。
数年前までは、実際にERPやCRM、EDI、その他のトランザクションシステムから生の取引データを取得し、それに加えて、残念ながら通常のITではなくシャドウITの一部となっている構造化データのスプレッドシート群を組み合わせ、意思決定のための数値レシピを作り上げるというものでした。そして、それらすべてを行い、ダッシュボードやレポートなどの計測ツールを自ら作り上げ、数値が正確であることを確信するとともに、私たちが行っていることの妥当性をクライアントに保証し、さらに時間の経過に伴う意思決定の質を監視するための各種ツール、そしてシステムからデータを取り出し、意思決定をシステムに再投入するための配管まで整えるのがサプライチェーンサイエンティストの役割でした。
これがLokadが担っていた範囲で、実際に手を出せなかった点が2つありました。まず第一に、私たちはデータの受取人であって、データを自ら探し出すことはできなかったのです。ここでいう「探す」とは、サプライチェーンサイエンティストがデータを要求することはできたものの、クライアントのIT部門に特別な変換処理を依頼するのではなく、テーブルをただダンプする、例えば「select * from table」という非常にシンプルな作業を1日に1回行うだけだったということです。つまり、極めて単純な抽出作業であったのですが、実際にはそれを行っていたのはほぼクライアントのIT部門でした。
サプライチェーンサイエンティストには、クライアントのアプリケーション環境内でプロジェクトに必要なデータを探し出すことは求められていませんでした。その理由は非常にシンプルで、Oracle SQL、Microsoft SQL ServerのT-SQL、MySQL、PostgreSQL、IBMのDB2など、約20種類ものSQL方言が存在するからです。数年前まで、たとえ単一のテーブルをダンプするという非常に単純な作業であっても、サプライチェーンサイエンティストはオンラインで些細なクエリを構築するために文字通り何十時間も費やさなければならず、エラーメッセージが出るたびにその人が対処せざるを得なかったため、知らないシステムごとの方言に対応するのは大きなハードルでした。
2023年、ChatGPTのおかげでこの問題は解決されました。ChatGPTはアシスタントプログラマーとして洗練されたアプリの構築には必ずしも向いていませんが、数十種類の方言でシンプルなSQLクエリを作成する際には非常に高速に動作します。サプライチェーンサイエンティストはSQLクエリの作成を依頼し、その人自身も聡明で、意図が正しく反映されているかを必ず確認します。つまり、構文の習得という障壁を取り除くことで、一度正しい構文が提示されれば、それはほぼ自明のものとなるのです。
もしご自身で試してみたいなら、ChatGPTにマシン上でgitを設定し、gitリポジトリを構築する手順を説明してもらうよう依頼してみてください。すると、どれほど高品質な回答が得られるかが実感できるはずです。
これはまさにゲームチェンジャーです。なぜなら、サプライチェーンサイエンティストの育成を行うLokadが、突如としてデータ探索の責任を自ら担えるようになるからです。そして、ChatGPTを通じて、私たちは「データを探し出す」ということに過剰に依存しないためのツール群を持っているのも事実です。これは革命的な変化であり、IT部門にデータ送信を依頼する代わりに、単にIPアドレスをホワイトリストに登録し、ごく安全なクラウド間接続を確立することで、サプライチェーンサイエンティストのチームが自らデータを追いかけることができるのです。
なぜこれがこれほどの違いを生むのでしょうか？実情として、たとえLokadが特定のプロジェクトに数日の作業しか必要としなかったとしても、必要な20～50テーブルを取得するためには、単純なテーブルダンプ作業であっても、実際には10～20日の作業が必要となります。しかし、多くのクライアントは独自のIT部門を持ち、膨大なバックログ、文字通り何年分もの未処理案件を抱えているのです。たとえLokadが10日の作業を要求しても、その10日に加えて3年分のバックログがあれば、キューの途中に位置していただけでも、そのIT作業が完了するまでに最長1年かかる可能性があります。これが、私たちが直面していた大きなフラストレーションであり、遅延の大部分がIT部門の能力不足や遅さではなく、単にバックログが多すぎるためにその10日間の作業を割り当てるのが極めて難しかったという理由です。
ここで話しているのは、10～20日の作業を依頼する代わりに、必要な数少ないシステムへの非常に安全で厳格なアクセスを確立するために、おそらく1日未満、あるいはたった数時間程度の作業で済むということです。そして、その後はサプライチェーンサイエンティスト自身がテーブルを調査し、データ抽出のロジックを構築して、本当にごくわずかな負荷でデータ抽出が行われるようにするのです。
これを実現する方法は、通常、パフォーマンスの監視によって行います。データベースのパフォーマンスが低下するたびに、それはデータベース上で多くの処理が行われていることを意味し、その場合は負荷を軽減し、データ取得プロセスを遅延させるのが通常の対応となります。なぜなら、Lokadでは通常、データは日々更新する必要があるものの、緊急性が極めて高いわけではないからです。もちろん、状況によっては非常に厳しいスケジュールもありますが、サプライチェーンに関しては、たとえばデータベースに一時的な急激な活動があったために取得を30分遅らせても、大きな問題にはならないのです。
最初のコミットメントは、自らデータを追いかけることで、遅延の最大の原因を排除し、プロジェクト全体を大幅に加速させることにあります。前述の通り、Lokadのプロジェクトが本稼働に移る際の大部分の遅延は、IT部門がその作業日数を割り当てるのを待つことによって生じていたのです。
二つ目のコミットメント要素は、マスターデータの改善です。そしてここでも、過去にはたとえば10万件の製品説明があるカタログに直面した場合、そのうちの1%程度がゴミ情報であったり、製品ラベルや説明が不正確であったり、または説明と全く矛盾する価格設定がされている場合がありました。例えば、「ネジ」と記載されているのに価格が2万ドルの場合、それは単なるネジではなく、何か別のものを示唆している可能性があります。こうした基本的な健全性チェックは、一見明白で単純な処理のように思えますが、自動化するのは非常に困難で、ひどいエントリを検出するためには結局のところ人手によるチェックが必要でした。
LLM、さらには画像も処理できるLLMを活用すれば、マスターデータに関連するすべての情報の調査、監視、および改善に関して多くのことが可能になります。具体的にLokadの場合、サプライチェーンの運用に必要なマスターデータ部分にもこれが当てはまります。
Conor Doherty: なるほど、たくさんの議論すべき点がありますね、ありがとうございます。いくつか質問をさせていただきたいのですが、少し立ち止まって整理してもよろしいでしょうか。つまり、あなたのおっしゃるところをまとめると、優れたLLMへのアクセスを持つ1人のサプライチェーンサイエンティストによって、これまで多くの時間と多数の人員を要していた膨大な作業がこなせるということでしょうか。では、もしLokad以外の体制であった場合、関わる人数はどれほど増えるのでしょうか？どれほど多くの人が関与することになるのでしょうか？そして、効率性についても語られるでしょうが、単純に人員数という観点で見た場合、LLMを活用するサプライチェーンサイエンティストと、例えばS&OPの場合ではどれほどの違いがあるのでしょうか？
Joannes Vermorel: 私たちのクライアントは、大規模なプロジェクトでさえも通常、2～3人、しかもいつも同じメンバーで構成されるという事実に驚かれます。私たちにはLokadがあり、雇用主としてLokadが長期間にわたって人材を維持できていることを非常に誇りに思っています。要するに、Lokadではプロジェクトの最初から最後まで、通常は1%の人員体制で対応しているということです。もし複数の人がいるとすれば、それは冗長性の確保のためです。ある日はあなたがパイプラインのこの部分に専念し、私は別の部分に取り組み、翌日には役割を交代する、という具合です。もちろん各人が専門性を持っているのは事実ですが、全体としては互いに代替可能な体制になっています。
競合他社は全く異なります。小規模なプロジェクトでさえ、実際には文字通り6名ほどが関与します。プロジェクトマネージャーが他のメンバーの調整役を務め、次にコンサルタント、UXデザイナー、コンフィギュレーター、データベース管理者、ネットワークスペシャリスト、そして場合によってはネイティブでないカスタマイズに対応するプログラマーやソフトウェアエンジニアが加わります。改めて申し上げると、Lokadはプログラム可能なプラットフォームですが、競合他社の多くはプログラム可能なプラットフォームではありません。したがって、プログラム的な処理が求められる場合、JavaやPythonといった汎用プログラミング言語で欠落部分を実装するための十分なスキルを持ったソフトウェアエンジニアが必要になるのです。つまり、Lokadはそういった体制ではなく、競合他社の場合は基本的に約12名の人員が必要となります。S&OPのプロジェクトでは数十名が関与することもありますが、それほど多種多様なスキルが必要なわけではなく、主に各部門から異なるメンバーが参加し、またIT主導ではないことが多いのです。
つまり、Lokadは1人で対応可能な一方で、私が比較しているのはAPS（先進的計画システム）や在庫最適化システムなどのエンタープライズソフトウェアを販売している競合他社であり、そちらは通常12名程度の体制が必要になるのです。
Conor Doherty: ありがとうございます。そして、冒頭でサプライチェーンサイエンティストについて触れられた際、異なるSQL方言の例を挙げられ、特定のクライアントの方言に精通しているかどうかにかかわらず、LLMが自動生成したスクリプトをサプライチェーンサイエンティストが検証・監視するという点に戻りたいのですが、LLMは時々幻覚を起こすとおっしゃっていましたね。
ええ、その通りです。LLMは非常によく幻覚を起こします。もちろん改善は進んでいますが、例えばテキストの一部として「この隠された単語を見つけられますか？」と依頼すると、存在しないにもかかわらず「はい」と答えてしまうことがあります。私もその単語が存在しないと知っているのですが、大規模に自動化された環境でLLMを活用する場合、どのようにセキュリティを確保し、品質管理を行えばよいのでしょうか？
Joannes Vermorel: 幻覚、もしくは私が好んで「捏造」と呼ぶ現象は、LLMをあらゆる情報の知識ベースとして利用する場合に特に起こります。すべての情報を知識ベースとしてLLMに委ねると、そのような現象は避けられません。例えば、医療論文を求めて「この病理に関する論文を一覧にして」と依頼すると、概ね正しい方向性の情報は得られます。著者は実在し、その分野で発表している研究者もいますし、似たような論文もありますが、完全に一致するわけではありません。これは、頭の中だけで物事を思い出そうとする科学者に例えることができるでしょう。
非常に難しい状況と言えるでしょうし、もしどうしても要求する場合、正しい同僚や研究者の名前、ほぼ正確なタイトルなど、半分はもっともらしい情報を生成するでしょう。これが捏造が起こる状況ですが、実際、LLMにあらゆる情報を網羅するデータベースのように振る舞ってほしいと頼む以上、この問題は避けがたいものです。
SQL方言についても同様です。試してみると、ほぼ正しい結果が得られます。たとえば「テーブルを読みたい」と依頼すると、「select * from table」といったクエリが返されます。GPT-4にテーブルを読み込むよう依頼しても、「drop table」といった危険なコマンドは返しません。多少不十分な構文が出ることはあるかもしれませんが、SQLクエリを実行してエラーメッセージを得たら、少し修正すれば正常に動作します。それでも、基本的な方向性は正しいのです。データベースの読み込みを依頼しても、テーブルを削除したり、権限を変更するようなコマンドは生成されません。
作り話の知識を依頼する場合も同様です。例えば、「20キロワットの工業用コンプレッサーがあるのですが、価格はどれくらいですか？」と尋ねると、GPTはおそらく1万ドル前後と回答するでしょう。これは単なる概算であり、事実とは異なる可能性が高いです。状況により何百ものバリエーションが存在するため、正確な回答とは言い難いのです。
結局のところ、捏造はランダムに発生するものではなく、特定のタスクでより頻繁に起こる傾向があります。したがって、あらゆる情報をデータベースのように扱う場合は、二重チェックを行うのが賢明です。非常に有用なツールであり、例えばSQL方言に関しては、使用すべきキーワードや構文のヒントを与えてくれ、多少の間違い（コンマの抜けなど）があるとしても、数回の修正で正しく仕上げることができます。特に、一度SQLクエリを得れば、実際にデータベースでテストして出力を確認し、即座にフィードバックループで検証できる点が大きなメリットです。
もし例えば、不審な商品ラベル、つまりこのように商品説明が欠落しているような、怪しげな商品ラベルを検出したいのであれば、それが明らかにおかしいということです。しかし、ありとあらゆる誤りが存在します。例えば、商品ラベルに「tournevis cruciforme」と書かれている場合、これはフランス語で表記されており、おそらくフィリップスヘッドのドライバーを意味しています。そしてまた、要求を出すことは可能ですが、ある時点で完璧ではなく、それは判断次第となります。人間も同様に間違いを犯すので、どんな質問にも常に正解する最終的な神託者のようなLLMを期待することはできません。100,000点の商品カタログのラベルの異常を調査するようなタスクを行う場合、LLMは人間と同じく偽陽性や偽陰性を出すことになるでしょう。しかし、興味深いのは、偽陽性と偽陰性の発生率を実際に測定し、その価値があるかどうかを判断できる点です。そして非常に多くの場合、多少の間違いがあっても大きな価値を提供する結果が得られるのです.
Conor Doherty: 進歩こそが大切であり、完璧ではない.
Joannes Vermorel: その通りです。非常に安価で、実際に数時間で自動再実行可能な仕組みによってマスターデータの問題を90%削減できるなら、それは非常に素晴らしいことです.
Conor Doherty: さらに、手作業でそれを行わなかったことで生まれた時間を、他の価値あることに使えるという価値もあります。つまり、価値には直接的な要因と間接的な要因の両方が存在するのです.
Joannes Vermorel: さらに現実的な面として、1時間の超反復作業ではある程度の品質を保てるかもしれませんが、100時間、特に67時間目以降になると、人間は常に一定のパフォーマンスを維持するエンジンではないため、数時間後には集中力が低下し、偽陽性や偽陰性が急増してしまう可能性が高いのです。たとえかなり勤勉な従業員であっても同様です.
Conor Doherty: ありがとうございます。そして、実は私が尋ねようと思っていた点と重なる観客からの質問もあるので、いくつかは省略しますが、観客からの質問で取り上げられるでしょう。しかし最後にひとつ、サプライチェーンサイエンティストやAIパイロットについて話されましたが、さらに後で質問でも触れますが、サプライチェーンサイエンティスト、AIパイロット、そしてクライアントは、実際の日常業務ではどのように連携しているのでしょうか？クライアントはアクセスでき、LLMと対話するのでしょうか？
Joannes Vermorel: 一般的には、サプライチェーンサイエンティストが作成する数値的レシピのすべてがAIパイロットとして機能しており、これが日々サプライチェーンを操縦しています。それは自動で動作し、意思決定を行います。さらにLLMでは、データ準備の細部や発注（PO）の決定も処理可能です。例えば、事前の意思決定としてサプライヤーにMQSの確認を依頼する必要があります。この情報を取得し、不足しているか最新でなければ修正する必要がありますが、LLMはその取得を助けてくれます。意思決定後には、EDIが無い場合やブリッジが無い場合に、注文のETA（到着予定時刻）を問い合わせるメールを送る、または注文を迅速化または延期するよう依頼する、といった細かい作業が必要になります。これは、Lokadが注文迅速化の意思決定を生成できても、メールの作成や送信といった細かい作業は行わないというものです.
これらすべてが実質的にAIパイロットであり、プロセス全体を遂行する大規模な数値的レシピです。そしてそのすべてはサプライチェーンサイエンティストによって実装されています。これは、Lokadにとって業務範囲の拡大を意味します。実際、サプライチェーンサイエンティストは副操縦士の役割を果たしているのです。私が「パイロット」と言うとき、本当に意味するのは、航空機の自動操縦のようなものです。ちなみに、現代の航空機では最も困難な操作が自動操縦で行われています。古い香港国際空港のような非常に困難な空港もあれば、構造上簡単な新空港もありますが、高層ビルの中に位置する空港のようなケースでは、これらの操作の自動操縦は必須です。つまり、全てが機械によって実行され、人々はただ監視するだけなのです.
ここでサプライチェーンサイエンティストは、数値的なレシピを設計し、副操縦士としての役割を担います。彼らは指示や航路の決定といったナビゲーションをほぼすべて担当し、その上でパイロットのための計画や航路プランを構築します。しかし本質的には、サプライチェーンサイエンティストは副操縦士として方向性を見極め、先を読んでパイロットが可能な限りスムーズに動作できるよう支援しています。ただし、高頻度の調整はすべてパイロットが行い、副操縦士はそれをサポートするに留まります。そしてクライアントは機長の役割を担うのです.
古いテレビシリーズ『スタートレック』のように、機長が指揮席に座りクルーに極めて高レベルの指示を出すようなものです。この仕組みにおいて、クライアントは戦略と全体の方向性を提示し、その実行はサプライチェーンサイエンティストが担い、パイロットはサプライチェーン全体の日々の微調整や意思決定を実行するだけなのです.
Conor Doherty: そして、念のためもう一度申し上げますが、これはすでに実施されている自動化された定量的タスクに加えたものであり、それらは長年にわたって実施されてきました。もし「それは単に定性的なタスクだけだ」と考えている方がいるなら、このシステムはエンドツーエンドで運用されるのです。例えば、経済ドライバーの要因分析、アロケーション生成、購買、価格設定など、定量的なタスクもすでにAIによって自動化されています.
つまり、サプライチェーンサイエンティストは定量的な要素と定性的な要素の両方のコンソールを管理しているということです.
Joannes Vermorel: その通りです。そして、Lokadがようやく「AI」というキーワードを取り入れ始めた理由は、LLMを新たに導入することで、まさに包括的なツールキットとなるためです。私たちはすでにdifferentiable programmingや確率的最適化を用いた機械学習を実施していましたが、今、さらにその上にLLMを組み合わせているのです.
その効果として、実際にクライアントのサプライチェーンが何週間も無人運用できるようになるのです。経済ドライバーが整えば、完全無人運用が可能な期間の長さには、人々も驚かされるでしょう。素晴らしい点は、細かな微調整を一切行う必要がなくなることです。例えば、予測の調整は大多数のクライアントにおいて全く必要とされず、また、新製品の導入、旧製品のフェーズアウト、新規サプライヤーの追加、業績不振サプライヤーのフェーズアウトといったその他の調整もすべて完全に自動で行われます.
つまり、これらすべては通常業務の延長線上にあり、レシピが正しく作成されている場合、以前から多くの介入を必要としなかったのです。しかし、LLMを含むこのAIパイロットを用いることで、新たなサプライヤーの追加などの作業において、従来よりもさらに手動介入を減らすことが可能になります.
Conor Doherty: さて、ジョアネス、ありがとうございます。約40分間続きましたが、これから質問に移りたいと思います。しかしその前に、先月から今日にかけてのより大きな議論の文脈の中で、サプライチェーンの現場担当者や、それを統括する経営陣にとっての結論、すなわち行動を促すポイントや得るべき教訓は何でしょうか？
Joannes Vermorel: 私の見解では、10年後にはこのAIパイロットというビジョン（名称が変わっていたとしても）が標準となるでしょう。つまり、人々は「サプライチェーン」と言えば、当然その中にAIパイロットが組み込まれていると認識するようになるのです。まるでコンピュータにCPUが搭載されているのは当たり前だから、改めて言及する必要がないのと同じです.
私の考えでは、10年後にはこれらの機能は大幅に自動化され、LokadはAIパイロットを含むパッケージとして、サプライチェーンサイエンティストとともにそれを実現するでしょう。クライアントにとっては、サプライチェーンの実践が根本的に変わることを意味します。すなわち、大量の帯域幅を解放するAIパイロットが導入されるのです。そしてもともと、意思決定プロセスや複雑な計算にかかっていた帯域幅を解放していたのに加え、今度はSKUやサプライヤー、クライアントのリストを監視し、マスターデータを正確かつクリーンに保つために費やしていた時間すらも解放されるのです。こうした作業に伴う、実際には定量的とは言えない手動介入の必要性がすべて解消されるのです。ラベルの修正、入力ミスの訂正、重複の削除など、そういった作業はすべて、改めて言えば、Lokadが処理してくれます.
結論としては、これは生産性の大幅な向上を意味します。実際、一部のクライアントでは、繰り返し作業に必要な人員を90%削減する成果を上げています。現実には、今やより多くの時間が生まれ、その時間を自動化が非常に難しい業務に充てることができるため、結果として大きな価値が付加されると考えています。つまり、戦略について十分に考え、選択肢を吟味し、再びスプレッドシートで時間を浪費するのではなく、探求すべき方向性に集中するべきなのです.
ですから、難しい問題についてじっくりと考えた上で、サプライヤーやクライアントと真摯な深い対話を行い、自社のサプライチェーンを整備してサプライヤーを満足させることで、彼らからより良い価格、より高い品質、そして高い信頼性を得ることが可能になります。サプライヤーのニーズに合わせて組織を整えることは、一見「サプライヤーは私に合わせるべき」という逆の考えにも聞こえるかもしれませんが、実際にサプライヤーに寄り添えば、チーム全体の努力となり、より高い信頼性と良い価格を実現できるのです.
そして、クライアントに対しても同様の努力が可能です。双方の協力体制が必要であり、多くの知的な議論が求められますが、これは現段階のLLMでは対応できない部分です。ですから、Lokadは低付加価値の細かい雑務や日常的な事務作業を自動化し、人々にはより高次な半戦略的業務に専念してもらおうという考えです。半戦略的と言うのは、クライアントと一対一で対話し、その内容を総括してビジョンを作り、サプライチェーンのリーダーシップを支援し、企業にとって非常に明確で根拠ある戦略を構築するためです.
Conor Doherty: さて、具体例を二つ挙げて概念を掴んでいただくと、例えばExcelのスプレッドシートで「ブロックの色が黒と表示されているなら黒でなければならない」といった低レベルの決定は自動訂正できるようなものです。これは些細な、単調な作業であり、時間を割く価値はありません。一方で、例えば「ハンブルクに倉庫を開設すべきか？」というのは戦略的な判断です.
Joannes Vermorel: その通りです。さらに問題は、選択肢が非常に多岐にわたる点にあります。倉庫の場合、購入すべきか賃貸すべきか、どのような契約にすべきか、機械化の度合いはどうか、機器を返却可能な契約が必要か、機器をリースすべきか否か、など何百もの質問が存在し、人々が事務作業に全体のほぼ99%の思考リソースを費やすと、大きな決断に割ける時間がなくなってしまうのです.
ご覧の通り、パーキンソンの法則を適用すれば、たとえばABCクラスのために費やされた合計時間は、毎年、何人年もの労力が投入されることになります。しかし、新規倉庫の決断には数週間しか要しないのです。このように、全く意味のないABCクラスに実際に何年もの人間の時間を費やす一方、5000万ユーロの倉庫投資はわずか数週間で決断されるという著しい不均衡が存在するのです。本来は、このバランスが逆であるべきです.
Conor Doherty: では、この点についてありがとうございました。ここで、観客からの質問に切り替えたいと思います。ご質問は、私が終了するまで自由に送ってください。では、ジョアネス、Massimoからの質問です。IT部門がどのようにAIパイロットを活用してバックログを削減できるのか、またなぜそのアプローチを提案すべきだとお考えなのか、詳しく説明していただけますか？
Joannes Vermorel: AIパイロットは、ITのバックログを削減するためのものではなく、ITが何年にもわたるバックログを抱えている現実に対処するためのものです。つまり、Lokadの計画はITのバックログを削減することではなく、Amazonが行ったようにITの在り方自体を再考することにあります。これは別のエピソードになるでしょう。AmazonのAPIに関して、2002年のJeff Bezosのメモを探してみてください。結局のところ、現代企業のすべての部門―マーケティング、財務、会計、サプライチェーン、販売―は膨大なソフトウェアを必要としており、その全てがIT部門の肩にのしかかっているのです。ITはその重圧に崩壊しかけています.
ですから、私の主張は、Lokadはサプライチェーンの専門家であり、マーケティング、販売、会計などすべてをカバーするわけではないということです。我々が言いたいのは、LLMを活用することで、ITがLokadの運用管理から解放されるという点です。結果として、定量的サプライチェーンの取り組みを始動し、パイプラインを構築するために、従来10～20日必要だったITの作業が、わずか数時間に短縮されるのです。つまり、我々はバックログそのものを解決しているわけではありません。ITはITの仕事を行います。彼らもLLMの恩恵を受けることはできますが、彼らの場合は状況がはるかに多様で、難易度も高いのです.
つまり、私の提案は、LLMが実際にIT部門のバックログを一掃するという意味ではなく、特定のケースでLokadが「バックログに20日を追加する代わりに、たった4時間を追加すれば済む」ということを示す手段にすぎないということです。これが私たちのバックログへの対処法です。そして一般的には、長年にわたるバックログの解決策は、各部門がほとんどのソフトウェア関連業務を内製化することにあるのです。つまり、企業全体がITに過剰な要求をしている状態を示しており、マーケティング、セールス、会計など、各部署ごとにデジタルプラクティスを持つべきで、すべての問題をITに丸投げすべきではありません。そしてこれこそが、2002年にJeff Bezosが（もし混同していなければ）自身のチームに宛てた、非常に有名なメモの本質を突いています。※リンク先 siloing はそのまま残しています。
そしてBezosは、「今から2週間以内に私の机に計画を提出しないマネージャーは全員解雇だ」などと結論づけたのです。
Conor Doherty: さて、ありがとうございます。次のコメントですが、これは私が質問しなかったものです。コメント欄にその内容があったため、コメントとして表現されていますが、質問として受け取ってください。これはJesseからのもので、「1人のサプライチェーンサイエンティストと1つのLLMで、それでもなおコパイロットのように聞こえる。だから、改めてAIパイロットとコパイロットの違いを明確にしてください」という内容です。
Joannes Vermorel: 私たちがこれをパイロットと呼ぶ理由は、一部のクライアントにおいて、数週間にわたりすべての意思決定が自動で生成され、その後無人で実行されているからです。そして「無人」とは、本当にその意味です。2020年のロックダウン中には、14か月間、すべてのホワイトカラー労働者が実際に自宅に留まり働かず、国からの補助金で生活していた企業さえありました。ヨーロッパのいくつかの国では、実質的に家に留まって働かないための補助金が支給されていたのです。そういった状況があったため、14か月間ほぼ無人で稼働するサプライチェーンは、コパイロットではなくパイロットと呼ぶべきだと私は考えます。システムが生成する数字を監視する者がいなければ、それはまさにパイロットなのです。
しかし当時はLLMを使っていませんでした。その時の状況は、データがクリーンで、マスターデータ管理の劇的な改善の必要性もなかったのです。また、EDI統合などにおいて非常に高い成熟度を持つクライアントであったため、従来もその後も必要とされた措置は極めて限定的でした。
さて、コパイロットの問題に戻りますが、ほとんどのLokadの競合他社は自社はコパイロットを提供していると主張しています。しかし実際、彼らのやり方は全く異なります。Lokadのサプライチェーンサイエンティストはプログラミング言語を用いており、LLMはプログラムの一部分を生成するための補助として使用されているのです。
つまり、LLMはSQL方言やその他いくつかのプログラムの断片を生成するために使用され、その後、パイロットを構築し、パイロットは無人で運用されるのです。
我々の競合他社、特に会話型AI、会話型UI（ユーザーインターフェース）を市場に投入しようとしている企業は、全く異なるアプローチを取っています。彼らが行っているのは、典型的にはリトリーバル・オーグメンテッド・ジェネレーション（RAG）です。具体的には、プロンプトを作成し、サプライチェーン分野でLLMを用いたAIを提供している全競合他社は、様々なシナリオに適合する十数個のプロンプトを用意しています。その後、プロンプトに続いて、データベースから取得した基本的な記述統計、例えば先週、先月、昨年の平均売上などの数字を数十個挿入し、ユーザーからの追加クエリを加えることでLLMが回答を完成させるのです。
ご覧の通り、これは再びLLMが単なるテキスト補完にすぎないことを示しています。テキストを構築して補完させるのです。そしてリトリーバル・オーグメンテッド・ジェネレーションにおける「リトリーバル」の部分は、単にデータベースから数字を取得して組み合わせるだけです。結局のところ、質問に対する回答を得る手段に過ぎません。しかし、実際は、知識があれば画面上に直接表示される数字を読むことができ、魔法のようなことは一切ありません。LLMはレポート上の数字をそのまま認識しているに過ぎず、基本的にはダッシュボードで既に回答可能な質問にしか応じられないのです。
ですから、各数字の定義に詳しくなければ、LLMがそれを説明してくれる場合もありますが、Lokadが行っているように、各ダッシュボード上の数字に対してワンライナーの説明（いわゆるチートシート）を用意すれば、AIを用いずとも同じ役割を果たすことができるのです。
要するに、私は会話型AI、つまりコパイロットには非常に懐疑的です。なぜなら、それらは機械学習システム、ましてLLMすら想定していない既存システムの上に重ね合わせた単なるギミックに過ぎないからです。
だからこそ、私の知る限りでは、競合他社は皆、ダッシュボード上に配置されたチャットボットのようなものでコパイロットを提供しているに過ぎず、いかなる自動化も行えず、既存のレガシーシステムの上に単なるギミックとしての層を重ねただけなのです。
Conor Doherty: さて、ありがとうございます。次はKyleからの質問です。「AIモデルを導入する前にプロセス分析の重要性について議論していただけますか？」と。サプライチェーンの文脈でお願いします。
Joannes Vermorel: 意外に思われるかもしれませんが、プロセス分析は非常に重要です。ただし、人々が考えるような手法とは必ずしも一致しません。実際、サプライチェーンにおいては、企業が40年や50年もの間に、数多くの作り物のプロセスを考案してきたのです。そして「作り物」とあえて言うのは、サプライチェーンが官僚主義のゲームであり、その核に官僚的要素があるからです。過去50年にわたるサプライチェーンは、すべてのSKU、倉庫、拠点、製品を一人で管理することが不可能なため、労働を組織する方法として、問題を分割して多数の人々に業務を分散させるための手段でした。
その結果、プロセスの90%は、実際には多数の人々に業務が分散されることから生じた偶発的な複雑さを反映しているだけで、本質的なプロセスではないのです。つまり、プロセス分析は必要ですが、既存プロセスの90%はサプライチェーンが直面する根本的な問題ではなく、むしろ10%の本質的問題を解決するために多数の人員を要するという偶発的な問題に過ぎないという点に注意が必要です。
化学処理のように、多くの流れと依存関係がある業界では非常に複雑です。たとえば、化学反応では副生成物が必ず生じ、ある化合物を生産すれば必ず別の物質も生成されます。この別の物質は販売されたり、別プロセスで利用されたりします。すべてを調整する必要があり、条約も山のようにあり、バッチ処理と連続処理のプロセスが混在するため、とても複雑なのです。
しかし実際には、ほとんどのプロセスは、プロセス産業において非常に明確に定義された具体的な入力および出力を伴う化学反応という物理的実体に着目するのではなく、AIパイロット導入時には不要となる逆仕立てのプロセスに陥ってしまうのです。
興味深いのは、AIパイロット方式を採用すれば、もはや分割統治型のアプローチは必要なくなる点です。エンドツーエンドで問題を解決する統一された数値レシピが存在するため、これまで複数のプロセスで解決してきた調整の問題はすべて解消されるのです。
私の経験では、これらのプロセスの90%は、最終的に全くなくなってしまうでしょう。だからこそ、サプライチェーンの基盤となる物理層にしっかりと焦点を当てることが非常に重要であり、単に複数のチームを調整するために存在している作り物のプロセスに依存すべきではないのです。それらはアップグレードされるのではなく、AIパイロットに取って代わられるでしょう。
Conor Doherty: ありがとうございました。そして、実は先ほどの回答例がここへの良い繋がりとなりました。さて、視聴者のDurveshからの質問です。教育目的や小規模ビジネス向けにEnvisionをオープンソース化する計画はありますか？また、手作業による入力が多い化学品のようなB2B企業に有利なルールでプログラム可能でしょうか？
Joannes Vermorel: はい、いずれEnvisionをオープンソース化する計画はあります。しかしまず、その理由を説明させてください。このエンタープライズソフトウェアの世界では、Envisionの公開ドキュメントが存在します。多くの同業者はドメイン固有言語（DSL）を持っていますが、それらは公開されていません。Dassault SystèmesはQuintiqという別の会社を買収し、DSLを導入しましたが、公開されているわけではありません。つまり、サプライチェーン分野には、DSLを持ちながらも公開されていない企業が存在するのです。Lokadでは、すべてを公開し、Envisionの無料サンドボックス環境を提供しています。さらに、無料ワークショップも用意しており、実際に演習を通じてEnvisionを学んだり教えたりできるようにしています。つまり、私たちはそれ以上の取り組みを行っているのです。
さて、言語をオープンソース化するということですが、それは計画の一部であるものの現時点では早すぎます。なぜなら、Envisionは依然として急速に進化しているからです。ご存じのように、コンパイラをオープンソース化すると、スクリプトを実行可能なコードに変換するそのコンパイラが公開され、LokadのEnvisionコードが野外で運用されることになり、Lokadはそのスクリプトを自動的にアップグレードする可能性を失ってしまうのです。実際、過去10年間でLokadはEnvisionプログラミング言語を何百回も改訂しており、この言語は未だ安定していません。私の著書『Quantitative Supply Chain』を見ると、約6年前のものでありながら、Envisionの構文が劇的に進化しており、もはや存在しない古い構文の名残が見受けられるでしょう。
そこで、構文の絶え間ない変更にどう対応するかですが、Lokadでは毎週火曜日にリリースを行い、Lokadプラットフォーム上で運用されるすべてのEnvisionスクリプトに自動書き換えを適用しています。これがEnvisionの重要な特性の一つであり、静的解析への非常に高い親和性を持つ理由でもあります。静的解析とは、プログラムを実行せずにその特性を解析する、言語設計および言語解析の一分野です。そして、静的解析を通じて、古い構文から新しい構文へと既存のスクリプトを自動的に書き換えることが可能なのです。通常、アップグレード時には数日間、旧構文と新構文が共存し、その後、旧構文が完全に廃止されたと判断されると、フィーチャーフラグを用いて新構文のみを採用するのです。
そしてLokadでは、すでに200以上の自動書き換えを展開しています。通常、毎週火曜日のリリースとして実施し、月に約2回の書き換えを行っており、これを10年間続けています。したがって、このプロセスが続く限り、現実的にEnvisionをオープンソース化することはできません。時が来れば実現するでしょうが、Pythonの大失敗、すなわちPython 2からPython 3へのアップグレードによりコミュニティが10年もの苦労を強いられたという惨事を繰り返したくはありません。企業は何年にも及ぶアップグレードに突入し、10年の悪夢となりました。
例えばPythonを見ると、オブジェクト指向プログラミングが導入された当時、その構文は不格好で、Pythonが元来オブジェクト指向を想定して設計されていなかったことが明らかです。これは90年代後半に追加されたもので、その不格好な構文は今もなお残っているのです。ちなみに、どの言語にも同様の問題があります。C#では、もはや意味をなさないvolatileキーワードが存在し、C++では多重継承という設計ミスにより複雑さが固定化されています。大きなミスを回避する唯一の方法は、LokadのようにEnvisionの設計で大きなミスを犯した後、速やかに修正を行うことなのです。そして新たなパラダイム、例えば微分可能プログラミングという大きな新パラダイムが登場した際には、言語そのものを再設計せざるを得なかったのです。
ちなみに、Appleが提案したSwift向けの大規模なメガプロポーザルがあり、微分可能プログラミングをSwiftのファーストクラス市民にしようとしています。しかし、これは近いうちに実現するものではなく、非常に大規模な改修となるでしょう。現時点で、微分可能プログラミングがファーストクラス市民として最も近い言語はJuliaですが、そこでも多くの応急処置が施されている状態です。
Conor Doherty: 改めてありがとうございました。まだ3つの質問が残っています。次はVictorからで、これは広くAIに関するものです。大規模なデータセットを用いてもっともらしいシナリオや繰り返される問題を予測する中で、AIはどのようにランダムなボトルネックに対処するのでしょうか？
Joannes Vermorel: 明確にしておきましょう。AIと言うとき、それは一連の技法の集合体を意味しています。Lokadでは通常、LLM、微分可能プログラミング、および確率的最適化を用います。微分可能プログラミングは学習のために、確率的最適化は不確実性のある状況下での制約付き最適化のために、そしてLLMはこの普遍的でノイズに強いテンプレートエンジンとして機能します。
確率的なツールを用いてサプライチェーンに取り組むと、この質問がほのめかす多くのタスクが実質的に解消されます。これが確率予測の美点です。これらの予測はより正確であるわけではなく、サプライチェーンの周囲のノイズに対して非常に強いのです。確率的予測と確率的最適化を組み合わせることで、手動介入の必要性を大幅に排除できます。そして、「大幅に」というのは、ほとんどのクライアントにおいては、完全に手動介入を不要にするという意味です。そして現在、我々が残されているのは、テキストを確認し対応する必要があるタスクであり、それがLLMの役割です。再度申し上げると、これがLokadにおける実態であり、我々には本当に自動化されたAIパイロットが存在します。もし手動介入があったとしても、それはシステムへの単なる事務入力ではなく、通常は論理そのものを根本的に修正して戦略を反映させる数値レシピの戦略的改訂として入力されるものです。些細なものではなく、実装された論理の構造自体を根本的に変えるものとなるのです。
Conor Doherty: こちらはAhsanからの質問です。具体的に、AIがどのように注文の迅速化を実現するのかご説明いただけますか？ 音声コマンドを基にERPシステムで取引を実行することは可能でしょうか？
Joannes Vermorel: 音声コマンドはこの問題に対して適切なアプローチではありません。もし求めているのがより速いデータ入力であれば、音声は非常に低帯域幅のチャネルに過ぎません。タイピングは普通、話すよりも速いものです（タイピングが非常に苦手でない限り）。したがって、この方法で得られるメリットはほとんどありません。キーボードで設計されたUIであれば、音声コマンドよりも遥かに速く操作できます。これについてはよく知っており、20年前にAT&T Labsで本格的な生産級音声認識システムの最前線で働いた経験があります。多くのアプリケーションでうまくいかなかった例があります。音声認識自体は機能していたものの、実際にはキーボードを使う手が単に速かったのです。音声を使う状況は、手が汚れている時か忙しい時に限られます。それ以外の場合は、やはりキーボードのほうが速いのです。
質問に戻りますが、まず最初に注文のフィルタリングを行う必要があります。ここでは、どの注文を迅速化すべきかという意思決定プロセスが存在します。これは典型的なLokad方式であり、純粋に定量的な意思決定プロセスです。進行中のこの注文が迅速化を要求するに値するかどうかを、YesかNoかで判断する必要があります。これを微分可能プログラミングや確率的最適化で実現するのです。これが正しい決定に至る方法です。
その判断が下されると、毎日自動的に各注文に対する決定が行われます。それは、誰かが口頭で指示を出すというものではなく、最適化された注文を計算する数値レシピの一部として組み込まれるのです。時間の経過とともに、一部の注文が過大または過小であることが判明し、それぞれ延期または迅速化のリクエストを出すことになります。LLMの役割は、この定量的な決定、例えば「迅速化をお願いします」という二値のフラグを用いて、適切な文脈を持つメールを生成し、「ご対応いただけるかご確認ください」といった内容でサプライヤーに送信することにあります。そして、サプライヤーは望むべくは「はい」「いいえ」「多分できます」または「これが提供可能です」と返答するのです。
LLMはサプライヤーとのチャットを自動化します。AI自体は注文の迅速化を決定するものではありません。それはあくまで定量的な判断であり、微分可能プログラミングや確率的最適化といった定量的ツールでアプローチすべきものです。LLMは、しばしばメールのような非構造化チャネルを介して行われるサプライヤーとの相互作用のために存在するのです。
もし音声コマンドを考えているのであれば、それはうまくいきません。速度が遅すぎるのです。20年前に初の生産級音声認識システムを市場に投入したチームで働かせていただいた経験があります。しかし、結論としては、そうしたAI技術をこの用途で使うことはないでしょう。音声コマンドは、あなたが求めることを実行する帯域幅を持っていないのです。
Conor Doherty: 関連する話題ですが、確率的最適化や微分可能プログラミングについては、これらのトピックの豊富なビデオリソースがあります。微分可能プログラミングについては三部作（パート1、パート2およびパート3）として提供されているため、ここで詳細に解説することはありませんが、無視しているわけではなく、それらでカバーされています。学びたい方はぜひご覧になり、これらのパーツを組み合わせて理解を深めていただければと思います。
最後の質問です。Isaacからです。現在Envisionを学んでいる顧客として、特にGitHubとの統合機能に興味があります。例えば、自然言語でコードブロックを説明したり、バージョン間の変更を特定したりする用途で、EnvisionがGitHub統合をサポートする可能性についてご説明いただけますか？ 最後に、近い将来Envisionのコパイロットを導入する計画はありますか？
Joannes Vermorel: 短い答えとしては、「はい、はい、そしてはい」です。どのコンポーネントについて話しているかによってタイムラインは大きく異なりますが、基本的にはGitHub Copilotのような機能、すなわちLLMを利用したEnvisionコード用のLokadコパイロットをすでに開発中です。非常に興味深いのは、これが私たちが制御できるDSLであり、学習用の資料に完全にコントロール権を持っているという点です。これは非常にクールなことで、一度このLLMを本番環境に導入することに成功すれば、シンタックスを変更するたびに更新されたシンタックスで再度トレーニングプロセスを実行し、常に最新のEnvisionシンタックスを提供するコパイロットを持つことができるということになります。対して、GitHub CopilotはPython、C#、Javaなどのシンタックスを提供します。
ご存知の通り、Javaは25年以上、Pythonは30年以上、C#もおよそ22年以上存在しています。したがって、GitHubのコンパイラーにコードを書かせようとすると、その言語の半ば最新のバージョンが提供されるものの、実際には非常に新しいバージョンではありません。そして、時には最新のバージョンを望まない場合もあるのです。なぜなら、あなたの環境がまだそれらの最新バージョンに対応していないからです。
「コードにコメントを付ける」「コードを説明する」「コードを補完する」など、一連の極めて自然な機能の開発に取り組んでいます。また、Lokad内で発生する特定のワークフローに特化した拡張コードアクションについても検討中です。例えば、データ健全性ダッシュボードの自動生成がその一例で、これは非常に一般的なタスクです。
データ健全性ダッシュボードは、取り込むデータが正常かどうかを検証するためのツールです。ERPのデータに見られる問題はほぼ同じであるため、何をチェックすべきかに関する多くの知見と経験が蓄積されています。ERPからの正確なデータを検証する際、私たちサプライチェーンサイエンティストは、何を探すべきか、何を実装し、何をチェックすべきかといった独自のトレーニング手法とレシピ（いわば人間が作ったレシピ）を持っており、これをLLMで大部分自動化できるのです。これはLokadで進行中のプロジェクトです。
現在、Lokadのコパイロットの開発を進めています。EnvisionをGitHubにより親和性のあるものにするために、すでにオープンソースのVisual Studio Code拡張機能をリリースしています。Envisionのコードをgitリポジトリに入れることは既に可能です。単に.nvnファイルを作成してコミットすれば完了です。美しいコードカラーリング付きで編集したい場合は、Visual Studio Codeの拡張機能が必要です。Envision用のLokad Visual Studio Code拡張機能を探せば、完全にオープンソースでコードカラーリングが提供されるものが見つかるはずです。
将来的には、Lokadアカウント内にあるEnvisionコードをgitリポジトリとして公開する計画です。Lokadアカウント内で保存されるEnvisionコードの方式は、ほぼgitリポジトリと同様で、バージョン管理の方法もほぼ同じです。ただし、gitと全く同じ方法で整理されているわけではありません。技術的な理由については詳しくは触れませんが、gitは言語に非常に中立的です。特定の一つの言語だけを扱う場合には、一般的にはできない巧妙な対応が可能になります。しかし、結論としては、Envisionコードは完全にバージョン管理されているのです。我々は、Lokadアカウントからすべてのコードをgitリポジトリにエクスポートし、おそらく後に双方向の同期も可能にする仕組みを公開できると考えています。gitは分散型システムであり、各リポジトリが完全なコピーを持っているため、リモートリポジトリから変更を取得し、自分の変更を送信することができます。したがって、いつの日か、まずエクスポート機能を、次に再インポート機能を導入するかもしれませんが、それには時間がかかります。我々はまだその段階には至っていません。これはロードマップの一部ですが、具体的なタイムラインは未定です。
Conor Doherty: コメント欄でEnvisionを学んでいると述べられている方もいるので、注目に値します。我々は、トロント大学などとの共同作業で制作された一連のチュートリアルも制作しており、パイプライン上にあります。無料のリソースもあり、質問に対する回答も提供できます。学びたい方のために、我々のサプライチェーンサイエンティストはこれらのワークショップに多大な努力を注いでおり、それらは当社のウェブサイトで自由にご利用いただけます。
Joannes Vermorel: 自らサプライチェーンサイエンティストになることに興味がない方には、LokadがAIパイロットの一環としてサプライチェーンサイエンティストのサービスを提供できます。
Conor Doherty: 以上で全ての質問は終わりです、Joannes。お時間をいただき、またご覧いただき本当にありがとうございました。お役に立てたなら幸いです。それでは、また次回お会いしましょう。
