re:Invent 2024: US Foods が Generative AI 営業ツールを構築・拡張した事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How US Foods successfully built and scaled a generative AI sales tool (RCG203)
この動画では、US FoodsのMachine Learning Operations担当であるDavid Falckが、Generative AIを活用した営業支援ツールの開発と導入について解説しています。Amazon BedrockとPineconeを活用し、営業担当者の3-4時間の作業を20-30分に短縮することに成功した事例を紹介しています。特に、Claudeの異なるモデルの使い分けやキャッシング導入によるコスト最適化、モジュラーアーキテクチャの重要性など、実践的な知見が共有されています。また、AWSのRetailとCPGのBusiness Development teamを率いるAparna Galiassoからは、Generative AIプロジェクトを成功に導くための3つの重要な要素として、カスタマーオブセッション、データの重要性、スケーリングについての洞察が語られています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Generative AIの課題：Red Queenのレースと同じ場所にとどまる努力
おはようございます。re:Inventへようこそ。月曜日の朝8時30分からご参加いただき、この最初のセッションでご挨拶できることを嬉しく思います。それでは始めましょう。皆さんの後ろに映っているこの画像は、Aliceです。Aliceは不思議の国にいて、 Red Queenのレースを走っています。Aliceについて特筆すべき点は、彼女が一生懸命走れば走るほど、どこにも進んでいないように見えることです。そこでRed Queenは彼女を止めて言います。「Alice、ここでは同じ場所にとどまるためだけでも、全力で走り続けなければならないのよ」と。
さて、Generative AIについて考えるとき、もしあなたがAliceのように、ぐるぐると走り回っているのに全く前に進めていないと感じているなら、あなたは決して一人ではありません。問題は、走るのを止めることができないということです。なぜなら、もし止まってしまえば、取り残されてしまうからです。他の誰もが走り続け、周りの変化のペースは今のままのスピードで続いていくでしょう。そして、あなたは遅れを取ることになります。 そこで本当の問題は、あなたはAliceのようになるのでしょうか？今いる場所を維持するためだけに、より速く、より懸命に走り続けるのでしょうか？それとも、もっとスマートに走って、何か違うことをして先に進もうとするのでしょうか？そのためには、周りで起きている変化のペースを上回り、何か違うことをして、競争優位性を築く必要があります。
US FoodsにおけるGenerative AI導入の背景と戦略
私はAparna Galiassoと申します。AWSのRetailとCPGのBusiness Development teamを率いています。私の仕事では、多くのRetailerやBrandの皆様と、Generative AIにおけるArt of Possibleから、Proof of Concept、そして本番環境への移行までの道のりをご一緒させていただいています。まだ特効薬は見つかっていませんが、現在進行中のあらゆる実験から得られた初期の知見がいくつかあり、本日はそのいくつかをご紹介させていただきたいと思います。
2023年は、Art of Possibleに関する前例のない発散的思考の時期でした。多くの企業が、Generative AIとは何か、Foundation Modelとは何か、そしてどのように使い始めればよいのかを理解しようと試行錯誤していました。2024年では、企業にとって最も重要なユースケースが何であるかについて、収束し始める特権を得ています。企業は投資収益率を最大化する方法を模索しています。そのために、Art of PossibleからProof of Conceptに移行する第一段階として最も重要なことは、アイデアを素早く絞り込んでいくことです。問題は、ファネルの最上部にいるということです。そして私たちが知っているように、ゴミを入れればゴミが出てくるのです。ですから、スピードを重視するあまり、品質を犠牲にすることはできません。
Amazonの私たちにとって、カスタマーオブセッションは最も重要な価値観です。そこで最初のアドバイスは、常にカスタマーから始めて、そこから逆算して考えることです。ここで言う「カスタマー」は、やや広い意味で使っています。例えばUS Foodsの営業担当者のような社内のカスタマーかもしれませんし、外部のカスタマーかもしれません。US Foodsの場合であれば、レストランのオーナーかもしれませんし、あるいはレストランで食事をする私たちのような最終消費者かもしれません。
もう1つ注目すべき点は、永続的なニーズとは何かということです。これは、顧客が今日だけでなく、将来にわたって持ち続けるニーズでなければなりません。これが重要な理由は単純で、持続可能な成長のフライホイールを始動させる必要があるからです。今日だけでなく、将来にわたって顧客と企業の双方に価値を創造し続ける必要があるのです。そのため、ニーズを見極める際には、常にそれが永続的なものかどうかを自問する必要があります。よく見られる永続的なニーズには、時間の節約、利便性の向上、コスト削減などがあります。これらは時間が経過しても消えることはありません。
Generative AIプロジェクトの立ち上げと初期段階での学び
Generative AIのような普及度の高いテクノロジーでは、永続的なニーズに焦点を当てたとしても、POCを検討する際の選択肢は依然として豊富にあります。この段階で、どのようにしてより焦点を絞っていけばよいのでしょうか？多くの企業はビジネスに最も貢献するアイデアを優先しようという良い意図を持っていますが、本当に考えなければならないのは、異なるアイデアを公平に比較し、その価値を評価するメカニズムをどのように作るかということです。スケールできない多くの実験に均等に投資するのではなく、どのように優先順位をつければよいのでしょうか？ そのために、既存のフレームワークを活用することができます。イノベーションを評価するためのフレームワークは数多く存在します。私たちが顧客と一緒によく使用するのは、IDEOのBalanced Breakthrough Modelです。このフレームワークを選ぶ理由は、イノベーションの3つの側面、つまり実現性（Desirability）、事業性（Viability）、実行可能性（Feasibility）に焦点を当てているからです。
まず実現性から始めます。実現性、事業性、実行可能性が重要な検討事項であり、その中でも実現性が最も重要です。顧客や消費者がその製品やサービスを望んでいるかどうかを検証する必要があります。この場合、営業担当者が時間を節約するためのツールを必要としているかどうかが問題です。これが、アートオブポッシブルからPOCへ移行する際の焦点となります。このフレームワークは、 取り組みの過程を通じて継続的に発展していくため、イノベーションの優先順位付けに有効です。POCから本番環境への移行段階では、実行可能性のテストに重点が置かれます。 技術的には、この領域で問題を解決するソリューションを立ち上げることができるかどうかを判断する必要があります。スケールの段階に到達すると、事業性の検討、つまりビジネスとしてどのように収益を上げ、スケールでの投資をどのように最大化できるかを判断することが重要になります。これにより、異なる段階にあるアイデアを比較するためのツールとなります。
第2段階は、POCから本番環境への移行です。この段階では、 競争優位性をどのように構築し、よりスマートに運営するかを判断する必要があります。私たちのシンプルなアドバイスは、カスタマイズ、カスタマイズ、そしてカスタマイズです。これは、AIの一般的な適用を取り、ビジネスに特化したものにすることを意味します。 単純なプロンプトとモデルによる汎用的な出力という差別化されていない防御不可能なものから、ビジネス内の豊富なインサイトを活用して、他社が再現できない独自の顧客体験を生み出すものへと変換する必要があります。なぜなら、他社にはあなたのデータがないからです。データこそが差別化要因であり、競争優位性を生み出す手段となるのです。
Generative AIが解き放つデータに関する重要な側面が2つあります。1つ目は、私たちの企業に存在するものの、つながりのないサイロの中に埋もれているデータです。Generative AIは、これまで見えなかったかもしれない、より豊かで深いレベルのインサイトへのアクセスを可能にします。2つ目は、そのデータへのアクセスを民主化することです。これまでインサイトを理解したりグラフを解釈したりすることができなかった人々も、Generative AIと様々なユーザーインターフェースを通じて、データが意味するものや、それをビジネス上の意思決定にどのように活用するかをより簡単に理解できるようになります。私たちは、データこそが差別化要因であり、成功するGenerative AIアプリケーションは 氷山の一角に過ぎないと考えています。真の魔法と競争優位性は、強固なデータ基盤の構築に注力することから生まれるのです。
5年前であれば、データを資産として考えることの重要性を強調していたでしょう。今日では、ほとんどの小売業者やブランドがすでにデータを資産として捉えています。現在の課題は、そのような考え方やマインドセットを活かして、データプロダクトを開発・サポートするための人材、プロセス、テクノロジーを自社内に構築することです。これらは一時的な投資ではなく、CPG企業が自社製品をサポートしたり、小売業者が店舗やウェブサイトを資産として考えたりするのと同様に、継続的な投資が必要です。
その優位性を持続可能なものとし、長期的に維持するためには、アジャイルな実験の文化を創造し、柔軟性を重視した設計を行うことに注力する必要があります。進化に応じてコンポーネントを切り替えられるよう、モジュール式の構築を選択することが重要です。必ずしも問題解決のために最高で最速、最優れたモデルが必要というわけではありません。問題自体が変化したり、ユースケースが変わったりする可能性があるため、そうした柔軟性を念頭に置いた設計が求められます。これは社内でテクノロジーやツールの乱立を許容するという意味ではなく、ビジネスニーズの進化に応じてカスタマイズや継続的な変更が可能な設計を考えるべきということです。
方程式の3つ目の要素はスケールです。Generative AIについては、まだ初期段階にあり、スケールされた実装例はそれほど多くありませんが、着実に進展しています。AIとMLにおける私たちの豊富なイノベーションの経験から、スケールは主に2つの要素に関係していることがわかっています：測定と管理です。測定に関して言えば、ROIの測定と本番環境でのAIアプリケーションの大規模な管理が重要です。 一般的にKPIの設定方法は知られており、それ自体は比較的単純ですが、ベースラインの設定を忘れがちです。
仕事のやり方を変える可能性のあるGenerative AIアプリケーションへの期待に夢中になるあまり、人々が忘れがちなのが、このベースラインの重要性です。動く目標に対して進捗を測定するのは非常に困難です。そのため、KPIを確立し、ビジネスの観点から改善を真に測定できるベースラインを早期に設定することは、ビジネスステークホルダーに対してなぜその技術に投資するのかという大きな物語を示すために非常に重要です。
Generative AIについて考慮すべき一つの点は、これが常に進化する変数を持つ多変数最適化問題を解くようなものだということです。最も費用対効果が高いものや最速のものを求めるだけでなく、精度についても考える必要があるからです。必ずしも最も正確な出力が必要というわけではありません。例えば、Daveが話すように、人間が介在するGenerative AIアプリケーションを使用する場合、精度を数ポイント下げてコストを最適化することも可能です。これらの変数間の繊細なバランスを常に解決する必要があり、そのバランスは時間とともに進化し続ける可能性があります。
コスト面で考慮すべき3つ目のポイントは、最適化は一度きりではなく、継続的なプロセスだということです。コストを最適化していく中で、実際に最も膨らみがちなコストが変更管理です。そのコストをいかに効果的に使うかが重要になります。最近読んだMcKinseyのレポートによると、Generative AIに1ドル投資するごとに、変更管理に3ドルが投資されているという興味深いデータがあります。これは非常に大きな投資額であり、適切に管理されなければ、コストが積み重なってROIに影響を与え、企業内でのデータ分析やAIに対するマインドセットの変革という成果が見えないまま終わってしまう可能性があります。
セキュリティは最優先事項であり、アプリケーションにおけるセキュリティ、プライバシー、ガバナンスについては初日から考慮する必要があります。しかし、Generative AIアプリケーションが拡大するにつれて、リスク管理、信頼性の維持、責任ある開発はより複雑になっていきます。私たちは顧客との協業を通じて、ここに示すような責任あるAIの様々な側面を明確化してきました。これはプライバシー、セキュリティ、ガバナンスだけでなく、公平性、説明可能性、堅牢性も含まれます。企業が1つのGenerative AIアプリケーションだけでなく、複数のアプリケーションを展開する段階に達すると、通常はガバナンス組織やResponsible AI評議会への投資が増え、これらが信頼できるアドバイザーとしてコミュニティにおける変革の管理を支援することになります。
全体をまとめると、そしてこの後Daveが具体的な話をしてくれますが、Generative AIの実験的段階から本番環境への移行に関して、私たちは3つの教訓を得ました。本質的に、ただ懸命に、あるいは速く走るのではなく、よりスマートに進めることを考える必要があります。それが前進への鍵となります。ここでDaveに登場してもらい、これら3つのポイントをどのように実践したか、具体的な営業ユースケースでいかに迅速に進めたか、US Foodsの既存のアセットやデータをどのようにカスタマイズして営業担当者に提供したか、そして現在進行中のスケーリングの取り組みとそこから得られた教訓について話してもらいます。
US Foodsの事業概要とGenerative AIツール「MOXe」の開発
ありがとう、Aparna。re:Inventへようこそ。私はre:Invent 2024の2番目のスピーカーを務めさせていただきます。Aparnaの素晴らしい導入に感謝します。これからちょっとしたロールプレイをしてみましょう。皆さんは営業担当者です。すでに営業職の方がいらっしゃったら申し訳ありませんが、お付き合いください。皆さんは営業担当者として、担当地域で50、60、そうですね、70くらいの取引先を管理していて、かなり大きな事業規模を扱っています。その取引先基盤を継続的に拡大し、新規顧客を開拓し、見込み客を顧客に転換し、四半期ごとのノルマ達成や顧客対応などに取り組まなければなりません。さらに状況を難しくしましょう。営業担当者として、皆さんの顧客は独立系レストランのオーナーだけです。レストラン経営について知っている方なら分かると思いますが、これは簡単な仕事ではありません。完璧にやったとしても、利益率は依然として非常に薄いのです。その上、スタッフの無断欠勤や機器の故障など、あらゆるトラブルに対処しなければなりません。
レストランのオーナー、経営者、シェフとして助けが必要な時は、すぐに必要なのです。営業担当者を待つ余裕はありません。US Foodsの営業チームの多くは、以前レストランのオーナーやシェフだった人たちなので、この業界のことをよく理解しています。US Foodsの顧客である独立系レストランや個人経営の店舗は、営業担当者に実践的なサポートを求めており、それも即座に必要としているのです。
US Foodsでは、1年半から2年前に他の多くの企業と同様にGenerative AIに注目し始め、Aparna氏が言及したような実用的なニーズを探し始めました。その中で、営業担当者の業務、特に顧客へのオンボーディングや質問対応という業務が際立って目についたのです。これらの手作業を自動化できるだけでなく、営業担当者の経験とスキルを増幅させることができるのではないかと考えました。これが、約1年前に私たちがこの取り組みを始めたときに自分たちに課した課題でした。
これから、私たちの物語と、私たちが誰で、どのようにして今日に至ったのかをご説明します。正直に申し上げますと、私たちは本当に素晴らしいものを作り上げました。これは単なる自動化ツールではありません。私たちは営業担当者のための知能増強システムの基礎を築いたと信じています。50、60、あるいは70もの取引先を抱え、常にすべての顧客に最善を尽くそうとする営業担当者には、自分のための時間がほとんどありません。長い一日や一週間の仕事を終えて帰宅しても、本来ならスポーツ観戦や子供との時間、くつろぎの時間を過ごすべき夜や週末に、プレゼンテーションやピッチの作成、独立系レストランの顧客の問題解決に追われているのです。
US FoodsでのこのGenerative AIの取り組みでは、営業担当者の複数の課題を解決するものを作ろうとしました。まだ始まったばかりですが、すでに本番環境で稼働しています。今年の10月末に本番稼働を開始し、それ以来すでに営業担当者の12,000時間以上の時間を節約することができました。私たちはこれを本当に誇りに思っています。このトークを通じて、皆さんが私たちの経験から何か洞察やヒントを得ていただければと思います。このトークから一つでも良いものを持ち帰っていただければ、成功だと考えています。
ここまで歩いてこられた方は、おそらくUS Foodsの大きなバナーが付いたトラックを2、3台見かけたのではないでしょうか。私も来る途中で2台見かけました。 もし見かけていなければ、今週中にきっと目にすることになるでしょう。私たちは全国に6,500台以上のトラックを保有しています。私たちは個人経営のレストランだけでなく、カジノ、ホテル、病院、そして食品、化学製品、清掃用品、使い捨て製品を必要とするすべての施設に商品を提供しています。US Foodsは全米最大級のサプライヤーの一つで、年間約360億ドルの売上があり、70の物流センターを持っています。また、約3,300人の営業担当者がいます。私たちのツールは何千人もの人々の手元で日々使用されています。
私はDavid Falckです。US Foodsのマシンラーニングオペレーションチーム、エンジニアリングチームを率いており、これはより大きな分析とデータサイエンスチームの一部です。私たちはサプライチェーン、マーチャンダイジング、コマーシャル、その他の営業アプリケーション、法務、そしてLegalやHuman Resourcesなどのより企業レベルの機能に焦点を当てたデータサイエンスチームすべてをサポートしています。これらのビジネスユニットにはそれぞれ専任のデータサイエンティストがいます。私のチームは、データサイエンティストが生み出したものを本番環境に投入することを主な任務としており、営業担当者向けの本番システムはMOXeと呼ばれるツールに特化しています。
この素晴らしい受賞歴のある e コマースシステム「MOXe」は、usfoods.com にログインすると目にするツールです。実は、私の大好きなアーキテクトの一人である Tom Ingoglia によって設計されました。Tom は今日、私のスピーチを聞くために最前列に座っています。Tom、ありがとう。彼はこのツールで素晴らしい仕事をし、その開発を支援してくれました。現在、私たちの全ての業務が MOXe に統合されつつあり、まもなく全ての営業担当者が顧客との業務を一箇所で行えるようになります。
MOXeの技術的詳細とアーキテクチャの設計思想
Generative AI の導入を進めていく中で、皆さんもおそらく開発可能なアプリケーションのリストを作成し、いくつかのファシリテーション型の会話を経験されたことでしょう。Tom と私は、おそらく会社の中で Generative AI に最も熱狂している二人です。Tom と私以上に熱心な人には出会ったことがありませんが、それでも多くの人が興味を持っており、それは技術者だけではありません。現場の人々、特に営業担当者が Generative AI にとても興味を持っているのは、私にとって驚きでした。技術オタクの私は、自分だけがそう思っているのかと思っていました。しかし、ドライバーや倉庫で働く人々、営業担当者など、誰もが Generative AI に興味を持っており、皆さんと一緒にこの旅に参加したいと考えているのです。
社内外での対話を通じて最初のリストを作成していた時、私たちは多くの素晴らしいアイデアを得ましたが、その全てが Generative AI に関するものではありませんでした。それは問題ありません。企業における Generative AI の真の可能性について、教育が必要でした。US Foods のような企業では、文書や画像、メニューがあれば、それを Amazon Bedrock でホストされている Anthropic の Claude に入力して、全ての食品用語や、メニューからデイリー製品だけを抽出することができます。時には、英語を母国語としない顧客から文書を受け取ることがあり、国内の地域によっては手書きのメモが英語と中国語が半々だったりします。時にはポルトガル語やスペイン語で書かれていることもあり、Generative AI を使って書き直しや翻訳ができることは素晴らしいアプリケーションとなります。
最終的に、本当に確かな Generative AI のユースケースのリストができあがりましたが、中には従来型の AI や線形回帰のものもありました。私たちは、価値が高く比較的難易度の低いものを見つけるために象限を使用しました。ここで「難易度が低い」というのは括弧付きです。なぜなら、この旅を始めた1年前、1年半前の時点では、私たちは本当に何に取り組むことになるのか分かっていなかったからです。新しい領域だと分かっていたため、クイックウィンのユースケースに通常よりも長い6〜12ヶ月の期間を設定しました。私たちは、社内でカスタムビルドし、戦略的な差別化要因となり得るものに本当に焦点を当てようとしました。
1年前、US Foods では素晴らしいプリセールス投資と Generative AI のプロジェクトや実験を行ってくれたコンサルタントと多くの時間を過ごしました。その中には素晴らしいものもあり、多くを学びましたが、当時、彼らも私たち以上のことは知らなかったことに気付きました。1年経った今でも、この分野で特定の企業や個人が大きなアドバンテージを持っているわけではありません。このことから、私たちは前に進み、間違いを犯しながらも、最終的には何か有用なものを見つけられるという自信を得ることができました。
私のMachine Learning Operationsチームは、経験豊富な熟練のソフトウェアエンジニアとDevOpsエンジニアが中心となっています。この数年で私たちはMachine Learning Opsエンジニアへと進化を遂げ、AWS Code WhispererやGitHub Copilotを使いこなせるようになりました。
Generative AIを使って何を構築するかを検討する中で、特に印象的だったのは、ユーザーが自分の情報を入力し、レコメンデーションを受け取り、提案を承認または却下し、アプリ内でフィードバックを提供できるCopilotのようなツールを構築することがいかに価値があるかということでした。US Foodsのセラーたちにとって、そのようなツールを構築することがどれほど有益かを考えました。
私たちは最終的に、営業見込み客の発掘と新規顧客のオンボーディングに焦点を当てたツールを開発することにしました。50から70の独立系レストラン経営者と仕事をする際、彼らは口頭や手書きのメモ、写真、メニューなど、さまざまな方法で情報を提供してきます。また、すでに購入している商品に基づいて新しいメニュー項目を提案してほしいと依頼されることもあります。このように、さまざまな形式の情報、主に非構造化データが大量に入ってきます。私たちは、そうしたデータの処理時間を短縮し、これらの要望や非構造化データとUS Foodsが提供する製品やサービスとのマッチングを効率化するソリューションを見出そうとしました。
私は熱心なAWSファンで、長年AWSを使用してきました。最初にAWSを使い始めた頃は、利用可能なサービスはわずか6つほどしかなかったので、かなりの古参ユーザーです。Amazon Bedrockが登場した時、これは素晴らしいと思いました。私たちは実際に、Llama、Claude、Mistralなど、Bedrockで利用可能な半ダースものモデルを試してみました。それぞれのモデルは異なる特徴を持ち、得意分野も異なります。プロンプトを作成する際はこのことを忘れないようにする必要があります。あるプロンプトが全てのモデルで同じように機能するわけではないのです。特に法務チームやCISOとの議論において、Bedrockの主な利点は、モデルプロバイダーと何も共有する必要がないことでした。データもプロンプトも、直接的なやり取りも必要ありません。これにより、Bedrockを使ってGenerative AIの世界に進出することに、より安心感を持つことができました。
Generative AIに初めて取り組んだとき、何か馴染みのある感覚がありました。そして私たちのチームには、このプロジェクトに取り組む上で2つの大きな強みがありました。まず1つ目は、Amazon Mechanical Turkを広範に活用してきた経験です。私たちは何年もの間、MTurkを使用してウェブから外部情報を収集し、それを現場のセラーにとって有用な情報に変換してきました。MTurkは素晴らしいシステムで、約20年前から存在する最初のクラウドソーシングプラットフォームの1つです。APIを通じて実際の人間に質問を投げかけることができます。私たちは、メニューやシェフ、顧客や営業担当者がプレゼンテーションを準備する際に役立つ情報について質問していました。同じ質問を3回から5回繰り返しますが、必ずしも同じ回答が得られるわけではありません。例えば、2人がラザニアの正しい価格を答える一方で、3人目は全く関係のない回答をすることもあります。この経験があったからこそ、Generative AIの応答の非決定論的な性質にも違和感なく対応できたのです。
私たちの2番目の強みは営業チームでした。営業チームと一緒にアプリケーションを構築してきた経験が豊富だったため、Proof of Conceptやテストの実験を依頼する相手を正確に把握していました。彼らは素早く、そして非常に率直なフィードバックを提供してくれました。
この強みを活かした例として、今年の1月、2024年1月末のことですが、過去3〜4ヶ月間のGenerative AIに関する進捗を報告するため、経営陣との大きなミーティングが設定されていました。しかし、私たちには示せる進捗があまりありませんでした。私のチームメンバーの一人であるRyan Henderson（優秀なフルスタック開発者）が、休暇期間中に自主的にReactのWebアプリを構築してくれました。彼はAmazon BedrockをいくつかのAPIコールで接続し、ハイブリッドベクターデータベースのPineconeを統合しました。これについては後ほどアーキテクチャ図でお見せします。この初期バージョンは期待が持てるものでしたが、精度はあまり高くなく、おそらく50-60%程度でした。「このような状況ではどんな商品をお勧めすべきか？」といった質問をすると、半分くらいの確率で正しい答えが返ってきました。
私たちはこのアプリについて営業担当者の意見を聞いてみることにしました。驚いたことに、彼らはこれを気に入ってくれました。というのも、彼らは夜間や週末に、本来なら他のことをすべき時間に、これらの面倒な作業に3〜4時間も費やしていたからです。少しでも時間が節約できることは、彼らにとって天の恵みでした。これが今回の講演で私が伝えたい最大のポイントです。この後は聞かなくても構いません - 精度の低さを気にする必要はありません。まずはユーザーの前に出して、フィードバックを得ることです。精度は、正直なフィードバックを得ることで後から向上させることができます。営業担当者のその熱意に基づいて、経営陣レベルの投資を獲得することができました。Ryanは私たちを救い、春から6月頃に開始したパイロットプログラムへの道を開いてくれました。
MOXeの実装と最適化：TextractとLLMの使い分け
このアプリは10月の本番リリースまで継続的にテストを行いました。多くの営業担当者とテストを行い、最初はミシガン湖エリア（シカゴランドエリアとウィスコンシン）から始めました。US Foodsの本社がRosemontにあるため、そのエリアを意図的に選んだのです。私のチームはそこで営業担当者と直接対面し、アプリを使用する際の表情やボディランゲージを観察することができました。その後、パイロットを西部や南東部に拡大し、異なるチームや地域でツールがどのように使用されているかについて、貴重なフィードバックを得ることができました。本当に驚くべきことは、US Foodsに25年、30年、さらには32年も在籍している営業担当者たちがこのツールを受け入れてくれたことです。通常、新しいツールを導入すると、営業担当者は「ああ、いいね、Dave。もう行っていいよ」と言うのですが、このツールに関しては、これらのベテラン営業担当者が私たちの最高の変革推進者となり、他の営業担当者にも推薦してくれたのです。これは驚くべき、予想外の展開でした。
10月末の本番リリース時には、精度は大幅に向上していました。新規リードや顧客のオンボーディング、MOXeや全システムでの設定に必要だった3〜4時間の作業が、20〜30分で完了できるようになりました。これは営業担当者にとって大きな成果でした。私たちはUS Foodsのストラテジーチームと密接に協力しました。というのも、私たちはアプリの構築は得意ですが、ビジネスケースの構築はそれほど得意ではないからです。ストラテジーチームは、時間効率化によるコスト削減以外にも、ビジネスプランにおける収益増加を考慮する必要があることを理解させてくれました。時間が節約できることで、営業担当者は顧客との関係をより強化し、より多くのリードを顧客に転換し、彼らが本当に好きな仕事に集中できるようになりました。これは私にとって興味深い気づきでした。私はUS Foodsに8年間在籍していますが、買収後に入社し、通常は自分のチームと独立して活動し、面白いソリューションを構築してきました。
しかし、このプロジェクトは異なっていました。私たちはTomとDigitalチーム、CSOオフィス、Legalチーム、そしてStrategyチームと緊密に連携して取り組みました。Generative AIとこのツールの展開方法、そして社内の他のユースケースへの適用可能性について、私たち全員が本当にワクワクしています。
技術的な詳細について、あまり専門的になりすぎないように説明させていただきますと、私たちはシンプルなReactウェブアプリを使用しています。これは現在、セールス担当者が2つのプラットフォームではなく1つの場所で作業できるように、MOXeプラットフォームのタブに変換されているところです。Amazon Bedrockには複数回のコールを行っていますが、その理由については後ほど説明します。このシステムの中核となっているのが、Pineconeというハイブリッドベクターデータベースです。これは私たちにとって非常に重要な技術でした。様々なVector DBをテストしましたが、セマンティック検索と類似性検索の両方を考慮した真のハイブリッドベクターデータベースを持つ機能が、私たちにとって非常に重要だったのです。
例えば、お客様からこんな質問を受けたとします：「ランチとディナーのメニューは充実していますが、朝食はどうでしょうか？私のレストランに来るお客様は、Orangetheoryでの運動を終えたばかりのスポーツウェア姿で、健康的で高タンパクな朝食オプションを提供すべきだと思います。」このような簡単な質問に対して、システムはギリシャヨーグルトなどの提案を返してきます。ギリシャヨーグルトと相性の良い他の商品を探したい場合、このハイブリッドベクターデータベースの機能により、それらの属性や類似アイテムをすべて考慮に入れることができます。ギリシャヨーグルトが品切れの場合でも、アイスランドヨーグルトが在庫にあったり、あるいはカッテージチーズが朝食用の健康的な高タンパクオプションとしてリストに含まれているかもしれません。
このハイブリッドベクターデータベースは、レストラン経営者が商品を説明する方法と、私たちのSKU、製品、技術仕様とのマッピングにおける複数のギャップを埋めてくれます。Fine-tuningループや、Embeddingモデル、キーワードモデルに関連するすべてのオーケストレーション、そしてPinecone Vector DBへのデータ投入は、すべてDagster上で実行されています。Airflowをご存知の方には分かりやすいと思いますが、この数年間、Dagsterは私たちにとって本当に救世主となっています。
TextractとLLMの比較について、これは私たちがパイロット開発を進める中で最初に目が開かされた点の1つでした。Claudeと様々なバージョンのClaudeを使用していた際、新しいバージョンではAmazon TextractによるOCR（光学文字認識）が不要であることに気づきました。すべてをClaudeで処理できたのです。1日から1日半ほど、私たちは本当に興奮してClaudeですべてを構築していました。しかし、現実が見えてきて、これが良いアーキテクチャなのかと疑問を持ち始めました。答えは「いいえ」でした。
私たちはアーキテクチャのベストプラクティスに従い、モジュール性を保つよう努めてきました。これには多くの利点があります。Amazon Textractを再び採用した理由は、これまで広く活用してきたこと、他のAWSサービスとの連携が容易であること、そしてこの特定のタスクに特化して設計されているからです。次バージョンのClaudeがOCR機能についてどのような変更を加えるかは予測できません。もしClaudeのOCRが素晴らしいツールだと信じて依存していたのに、次のバージョンで何か変更があった場合、どうしますか？このツールにとって、モジュール化と交換可能性を確保することが重要な原則なのです。 キャッシングシステムを実装した主な理由は、Bedrockは素晴らしいものの無料ではないため、コスト削減のためでした。
高価なモデルを不必要に何度も呼び出している場合は、キャッシング層の実装を検討する価値があります。私たちは会話ではなく、シンプルな質問でClaudeに小さなモジュラー的な呼び出しを行っているため、キャッシングを効果的に活用できます。例えば、ラザニアのレシピについて尋ねる場合、一度レシピを取得すれば、その回答が間違っていない限り、再度Claudeに尋ねる必要はありません。そのために下部にフィードバックループがあるのです。
コスト削減のためにキャッシングを活用できることに気付いてからは、他にも多くのメリットを発見しました。冗長性もその一つです - Bedrockやその他のサービスに問題が発生しても、キャッシュに十分なデータがあれば、APIが復旧するまでアプリケーションは正常に動作し続けることができます。また、キャッシング層はデータ分析機能も提供します。 このデータを分析し、キャッシュされた回答とClaudeの新バージョンでの回答を比較することができます。このデータを使って、必要に応じて調整を行うなど、様々なことができます。トレーニングサイクルが完了するまでの間、少し修正が必要かもしれないClaudeからの良い回答を得られるケースもありました。
しかし、シンプルな質問をすることは、LLMを使用する上で最も魅力的な側面ではないかもしれません。必然的に、素晴らしい機能を発見し、マルチターンの非常に長いプロンプトを構築して、すべてを一度に実行したくなるでしょう。特にMVPやPOCの場合はそれも可能ですが、細かく分解することで、よりモジュール性と柔軟性が得られます。Claudeへの小さな短い呼び出しを使用する場合、呼び出し間でコンテキストをどのように管理するかを考える必要があります。個人的にClaudeやChatGPTを使用する場合、会話中に自然とコンテキストを維持し、以前の情報を思い出させたり、what-ifシナリオを提示したりします。これらのLLMに複数回呼び出しを行う場合でも、プログラム的にこれを処理する必要があります。
プロンプトの数は自由に決められますが、優れたアーキテクチャのベストプラクティスに従うことをお勧めします。バックグラウンドでは様々な変更が行われており、アーキテクチャを開発する際にはそれを念頭に置く必要があります。より多くのAgent型ワークフローを探求し、バックエンドシステムと対話するAgentを構築していく中で、小さなチャンクとモジュールに分割することは特に有益となるでしょう。
私たちの人間によるフィードバックを活用したReinforcement Learningのループは、Amazon Mechanical Turkで使用したReinforcement Learningと似ています。中心にTask Assemblyという製品があります。Amazon SageMaker Ground Truthも使えますが、大規模なAIラベリング作業により適していることがわかりました。ここの2列目に座っているDave Schultzというコンサルタント - 彼の名刺をお持ちしていますので、ご連絡を取りたい方はお申し付けください - 彼とは長年一緒に仕事をしており、Task Assemblyプラットフォームを構築してくれました。Mechanical Turkを使用する際により柔軟性を提供してくれます。
このプラットフォームは本当に柔軟性が高く、Amazon Mechanical Turkを使用できるだけでなく、組織内部のクラウドも活用できます。DaveはMechanical Turkでの作業、そして現在のGenerative AIの取り組みにおいて、私たちにとって本当に心強い存在です。ありがとう、Dave。
Generative AI導入の成果と今後の展望
アプリケーションやアーキテクチャについて話してきましたが、このスライドでは、アプリケーション自体のスケーリングや最適化については触れていません。代わりに、より企業的な視点から考えています。データチームがベストプラクティスに従い、すべてのモジュールやアーキテクチャの決定事項を文書化しながら標準を守っていけば、将来これらのコンポーネントを再利用するのが容易になります。US Foodsでは、すでにいくつかのプロジェクトが私たちのモジュールを検討し、当初は想像もしなかった全く異なるユースケースへの適用を考えています。裏で動いているすべてのメトリクスを追跡することが重要です。Generative AIを使用したアプリケーションから生まれる価値をすべて評価できるようにすることで、さらなる投資を受け、Generative AIでより面白いことができるようになります。
良質なデータが必要です。Aparnaも何度か言及していましたが、良質なデータが必要です - 完璧である必要はありませんが、良質である必要があります。US Foodsで3年半前にBig DataとBIの近代化に投資していなければ、現在のGenerative AIツールでの成果は得られなかったでしょう。従来型のAIや機械学習に取り組んでいた当時でさえ、経営陣から重要な質問を受けました：この取り組みは、将来のData ScienceやMachine Learning、AIに役立つのか？答えは間違いなくイエスでした。もしデータの準備態勢やデータの近代化への取り組みに消極的な組織で働いているなら、これを活用できるでしょう。世界で最も魅力的な仕事とは言えないかもしれませんが、将来のAI、Machine Learning、Generative AIの成果と結びつけることができれば、それは本当に興味深い一歩となります。
私たちにとってステップゼロは、コードを書く前に法務チームに相談することでした。驚いたことに、法務チームは機密情報を漏らさない限り、Generative AIの実験を喜んで認めてくれました。彼らは素晴らしいパートナーでした。Chief Information Security Officerも素晴らしいパートナーで、すでに企業としてGenerative AIを使用する際の基本ルールや考慮すべき事項について取り組んでいました。私たちのデータやプロンプト、知的財産を外部に漏らさず、Amazon Bedrockを使用してそれらすべてを保護していることは、大きな意味を持ちました。
Amazon Bedrockは素晴らしいと言いましたが、無料ではありません。 キャッシングを導入できれば素晴らしいことです。また、ClaudeにはOpus、Sonnet、Haikuなど、さまざまなモデルがあり、それぞれコストが異なることも覚えておいてください。Opusが最も高価で、Haikuが最も安価です。タスクをモジュール化して構築していれば、すべてにOpusを使用する必要はありません - 多くの場合、Haikuを使用してコストを削減できます。より高い処理能力が必要で、Generative AIツールを構築して10月末にリリースする際、私は心配していました。1分あたり250回のコールしかできないのに、何千人もの人々が一度にBedrockにアクセスした場合どうすればいいのか、AWS Enterprise Teamに相談しました。彼らは「Dave、心配いりませんよ」と言ってくれました。クロスリージョン推論のような機能があり、必要な場合は別のリージョンにフェイルオーバーしてClaudeを呼び出すことができます。これには多少のレイテンシーが発生しますが、安心感があり、Claudeへの1分あたりのコール数を2倍にすることができます。本当に価値のあるユースケースがあり、投資への合意が得られれば、Provision Throughputを使用して、クラウド上で独自のClaude、Llama、またはMistralを利用することができます。
全体ではありませんが、かなりの部分を使用でき、独自にプロビジョニングされたプライベートLLMを通じて多くのトークンとプロンプトを処理することができます。非常にエキサイティングな機能です。今のところは必要ありませんでしたが、将来的にはわかりません。
Generative AIの特徴についていくつかの洞察をお伝えしましたが、モジュラーアーキテクチャが重要です。アーキテクチャのベストプラクティスに従えば、うまくいくでしょう。Generative AIの最適なユースケースを見つけるコツは、ステークホルダーや現場の営業担当者に、最も困難なタスクは何かを尋ねることでした - 最も嫌な仕事は何ですか？最も気が進まないタスクは何ですか？通常、それは時間がかかり、紙ベースで、手作業で、かなりのワーキングメモリを必要とするものです。それらを記録しておいて、思うほど正確である必要はないということを覚えておいてください。始めたばかりの頃は、Generative AIを使用して行う精度、推奨事項、予測などは完璧である必要はありません。できるだけ早くお客様や社内のステークホルダーに見てもらい、フィードバックを得ることが重要です。
これまでのスライドを通じて、私のCall to Actionをお伝えしてきました。データを整理し、実際のユースケースで実験を始めてください。Amazon Bedrockは私たちにとって救世主でした - 素晴らしいサービス群です。AWSチームは私たちの取り組みを非常にサポートしてくれました。Generative AIには特異な点や回避が必要な制限がありますが、私たちは成功を収めることができましたし、皆さんも同様に成功できると信じています。
約1年前にこの取り組みを始めた時、3,000人以上の営業担当者が夜間や週末に多くの時間を無駄にしていました。今日では、3〜4時間かかっていた作業が20〜30分で完了し、より早くお客様に対応できるようになりました。以前の3〜4時間は数週間に分散していたため、希望するほど迅速にお客様に対応することができませんでした。これは私たちのお客様にとっても、競合他社が私たちの代わりにお客様の質問に答える機会を与えてしまうという点で、ビジネスにとっても良くありませんでした。
この変革は、私が共有した数字や指標以上のものです。大規模なオンボーディングタスクで90%の時間を節約できるということ以上のものなのです。Generative AIは単なる自動化ではなく、増強なのだということを認識することが重要です。ユーザーの生活を向上させ、困難な部分を自動化するシステムを構築することなのです。これらはすべて、将来ではなく、今日のAmazon Bedrockで実現可能です。US Foodsが数ヶ月で組織の働き方を劇的に変えることができたように、皆さんにもできるはずです。これらは私たちが今年歩んできた道のりのハイライトであり、皆さんが少なくとも1つの気づきを得ていただけたことを願っています。お時間をいただき、ありがとうございます。re:Inventをお楽しみください。
月曜の朝から1週間の予定が控えていますので、特にRetailとCPGに興味がある方向けに、追加のセッションをご紹介したいと思います。これらのセッションはアプリで確認できます。 また、Industries Pavilionに立ち寄っていただければ、私たちのGenerative AIのデモをご覧いただけます。質問にもお答えしますので、ぜひお立ち寄りください。最後に、皆様のフィードバックを大切にしていますので、アプリを開いてセッションのアンケートにご協力いただければ幸いです。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion