re:Invent 2024: トヨタが語るGen AIによる革新と効率化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Toyota drives innovation & enhances operational efficiency with gen AI (AUT201)
この動画では、Toyotaが取り組むGenerative AIの活用事例について、複数のスピーカーが詳しく解説しています。自動車のダッシュボードに表示される不可解な記号の意味を説明するAIアシスタントや、製造ラインでの機械故障時の修理時間短縮を実現する「GearPal」、バッテリー製造の専門知識を共有する「Battery Brain」など、具体的なユースケースが紹介されています。また、MainframeのCOBOLコードを現代的な言語に変換する取り組みでは、Amazon QとHugging Face Transformersを活用し、90%以上の精度を達成した事例も共有されています。Amazon BedrockやRAGなどの技術を活用しながら、Toyotaが自動車製造会社からモビリティカンパニーへと変革を進める様子が詳しく語られています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
自動車産業におけるGenerative AIの可能性と課題
皆さんの中で、通勤やレジャーで車を運転される方はどのくらいいらっしゃいますか？この数週間、数ヶ月、あるいは数年の間に、ダッシュボードに何か不可解な記号が表示されたことはありませんか？例えば、感嘆符の付いた円や、蛇行している車のマーク、三角形の横にPという文字など。そのような経験をお持ちの方は手を挙げていただけますか？10～15%くらいの方が手を挙げていますね。そして、そのような記号を見たとき、その意味や、その時点で運転を続けても安全かどうかを正確に理解できた方はどのくらいいますか？数人ですね。もし、そのような記号が表示されたときに、より詳しい説明や、その時点で運転を続けても安全かどうかの情報が一緒に表示されたら素晴らしいと思いませんか？そして、もし運転が安全でない場合は、最寄りのディーラーの場所を教えてくれたり、さらには車を安全にディーラーまで運転して整備を受けられるよう、予約まで取ってくれたりしたら？
これは、Generative AIで実現可能なユースケースの一つに過ぎません。私はSandeep Kulkarniです。本日は素晴らしい機会をいただき、大変光栄です。これから3人のスピーカー - Kordel France、Paul Greenberg、そしてStephen Ellis - が、Toyotaがイノベーションの推進と業務効率の向上のために取り組んできたGenerative AIの様々なユースケースについてお話しします。 アジェンダはシンプルです。まず私が自動車産業におけるGenerative AIと、その可能性についてお話しします。その後、Stephen Ellisに引き継ぎ、ToyotaのモビリティビジョンとGenerative AIビジョンについて説明します。また、Knowledge Retentionと呼ばれるユースケースについても触れます。その後、Kordelが登壇し、GearPalとBattery Brainという2つの追加ユースケースについて説明します。最後に、Paulが締めくくりとして、コードモダナイゼーション、メインフレームモダナイゼーション、そしてToyotaが描く自動車産業におけるGenerative AIの未来像についてお話しします。
ToyotaのGenerative AI活用事例：知識保持からBattery Brainまで
それでは、自動車産業におけるGenerative AIについて、もう少し掘り下げてみましょう。 自動車産業では、新製品開発に通常数年間で10億ドル以上を費やします。イノベーションに関して行う投資判断の中には、必ずしも成功しないものもあるため、この投資が常に報われるわけではありません。データ分析、パターン認識、異常検知、合成データ生成に優れたGenerative AIのような機能を活用できれば、設計時間と開発時間を数週間から数ヶ月短縮できる可能性があります。ForbesなどによるStudyでは、設計・開発フェーズで数週間から数ヶ月の時間短縮が容易に達成できることが示されています。
自動車産業におけるGenerative AIの可能性を示すため、ここでは4つの領域について高レベルなサンプルをご紹介します。もっと多くの領域がありますが、それらは休憩後にお話しできればと思います。まず左上の製品設計と品質 - Generative AIは革新的なデザインとスタイリングの推奨を生成するのに使用できます。しかしそれだけではありません。車両の空力特性の観点からそれらのスタイリングと推奨事項の評価も得ることができます。つまり、生成されたスタイルの空力特性の評価が悪い場合、実際にそのスタイリングを試作して走行試験を行うような多額の投資をする前に、そのアイデアを却下することができます。右上の車内体験に移りますと、個人的には、基本的な質問や、先ほどの不可解な記号が表示されて困ってしまうような場面で、リアルタイムで会話しながら案内してくれるアシスタントがあれば素晴らしいと思います。以前、レンタカーを借りた時に
給油口のラッチが見つからなかったことがありました。ラッチが不要なタイプかと思いましたが、実はフロアマットの近くに隠れていて、両方とも黒かったため見つけるのに1分ほどかかりました。このような質問に答えてくれたり、最適なルートを案内してくれたりするのです。新しい土地を訪れた時には、観光スポットなどの推薦もしてくれます。
車両には時折、ディーラーやサービスショップでのメンテナンスを必要とする問題が発生します。この観点から、Generative AIを活用することで、サービス技術者向けのガイド付きトラブルシューティング手順を提供することができます。技術者はガイド付きメニューを通じて特定の推奨アクションを選択し、診断プロセスを簡素化し、正確な診断を行い、車両を修理することができます。左下には最後になりますが、自動運転があります。自動運転における課題の1つは、エッジケースと呼ばれるものです。これは起こり得るけれども実際には起こったことがないシナリオで、モデルのトレーニングが難しいものです。エッジケースでは、実際に起きたことを基に合成データを生成し、これらのエッジ要素を導入することで、モデルの改善を可能にします。
これは高レベルなサンプリングに過ぎません。製造、サプライチェーン、サステナビリティ、電気自動車、バッテリー最適化など、他にも多くの領域があります。しかし、自動車産業におけるGenerative AIの力をご理解いただけたと思います。 AWSの観点からは、私たちはお客様のGenerative AIの取り組みの段階に応じて対応しています。お客様が非常に高度な知識をお持ちで、AWS TrainiumのGPUチップを使用したい場合や、ネットワークコンピューティングストレージを使用したい場合は、それが最下層になります。Amazon SageMakerを使用しますが、環境を完全にコントロールすることができます。
多くのお客様は、細かいことは気にせず、単にFoundation Modelsへのアクセスが欲しいと言います。それが中間層のAmazon Bedrockです。30以上のFoundation Modelsが提供され、すべてが単一のAPIを通じて利用可能です。セキュリティは最優先事項であり、この中間層には多くのセキュリティガードレール、コンテンツフィルタリング、会話から特定のトピックを除外する機能が組み込まれています。そして、Foundation Modelsのことは気にせず、ビジネス上の問題を解決したいというお客様もいます。そういったお客様向けには、最上位層のAmazon Qがあり、Foundation Modelsに関する重い作業を気にすることなく、ビジネス上の問題解決に取り組むことができます。
先ほど述べたように、Amazon Bedrockは単一のAPIを通じて主要なFoundation Modelsの選択肢を提供し、モデルのカスタマイズも可能です。これはモデルプロバイダーがカスタマイズを許可するかどうかの判断によります。TitanモデルなどのAmazonのモデルはカスタマイズ可能で、一部のAnthropicのモデルもカスタマイズ可能です。モデルをデータでカスタマイズした場合、そのアクセス権はお客様だけにあり、お客様のデータが元のモデルのトレーニングに使用されることはありません。セキュリティとデータプライバシーの観点から、これらすべてが考慮されています。主要なユースケースの1つは、既存のモデルの重みを変更することなく、独自のデータソースでモデルを補強するRetrieval Augmented Generation（RAG）です。複雑なタスクに取り組む際には、Foundation Modelsをカスタマイズする複数のアプローチを実行できるエージェントがあります。最も単純なアプローチはPrompt engineeringで、その後により複雑な方法が続きます。
これらの方法には、Retrieval Augmented Generation（RAG）、そしてさらに複雑なFine-tuningや継続的な事前トレーニングが含まれます。Bedrockは単一のAPIを提供しますが、より重要なのは、有害なコンテンツをフィルタリングするためのしきい値を設定できることです。許可するトピックを定義し、特定のタイプのトピックを禁止することができ、それらのトピックに関する質問は決して行えないようにすることができます。これは組織全体のレベルで設定可能です。これらのガードレールを事前に設定することで、人々は自由にイノベーションを起こすことができ、最上位層がAmazon Qとなります。
Amazon Qを活用できる異なるペルソナについてご説明します。左側にはビジネスペルソナがあります - これはコーディングには関わりたくないユーザーです。最初のブロックのビジネスアナリストの視点では、要約作成やコンテンツ作成、インサイトの抽出といったことは、すべてAmazon Q for Businessプロダクトで実現できます。すでにQuickSightをご利用の方もいらっしゃるかもしれません。これは私たちの分析・クエリツールで、現在は生成AIの機能が組み込まれています。データの理解、ビジュアルの作成と改善、計算の実行、エグゼクティブサマリーの作成など、さまざまなタスクを実行できます。
右側に移ると、開発者向けのQはソフトウェア開発ライフサイクル全体をカバーしています。これにはコード生成、ユニットテスト、セキュリティスキャン、コード修正、コード移行、トラブルシューティングが含まれます。今後、より多くのAmazonプロダクトにQ型の機能が組み込まれていくことになります。右側には特殊な機能が示されています。例えば、コールセンター向けプロダクトであるAmazon Connectに組み込まれたQ機能です。Amazon Connectを使用してお客様が電話をかけてきた際、通話の録音、要約作成、ネガティブな顧客体験のある通話の特定などを行い、それをトレーニングやその他の用途に活用できます。
数年前に立ち上げた新しいサプライチェーンサービスにも同様にQが組み込まれています。ボトルネックが発生した場合の影響や、生産への影響、様々なシナリオに対する計画など、因果関係のシナリオを実行できます。製品の在庫状況における異常を自動的に特定することもできます。今後数日間で、さらに多くのプロダクトにAmazon Qと生成AI機能が組み込まれていく話を聞くことになるでしょう。プロダクトに慣れてくると、これらのプロダクトを使い始めることで、追加のヘルプ、より多くの機能、より効率的な作業が可能になります。
ToyotaのモビリティビジョンとKnowledge Retentionの実現
多くの方が、自動車業界が自動車製造会社からモビリティカンパニーへと変革しているという考えを耳にしたことがあるでしょう。Toyotaにとって、これはユニークな機会と課題の両方を提示しています。機会の一つは、世界中で多くの人々がベストプラクティスとして使用している製造プロセスの多くがToyotaで開発されたものであり、新しいパラダイムを確立するための豊富な知識を持っているということです。モビリティ空間で利用可能な機会は、単に車載ソフトウェアだけでなく、複数の異なるモダリティにおけるソフトウェアも含まれます。これは、新しいユーザーのユースケースや企業に適用される製造ユースケースを迅速にプロトタイプ化し、反復する際にユニークな課題をもたらします。
この変革をサポートするため、私たちのEnterprise AIチームは様々な取り組みを同時に進めるために設立されました。
チームの目的は、ビジネスユーザーが機能を理解し、ユースケースを迅速に評価し、標準を確立するのを支援する卓越した中核組織を作ることです。これらの標準を確立する主要なメリットの1つは、すべての開発と実践を1つの組織に集中させるのではなく、複数のチームと迅速に反復できることです。私たちのチームは小規模でスリムながらも強力なグループで、最良の情報を収集し、それを企業に持ち帰って、管理された効率的な環境の中で、今日実験すべき要素と将来進むべき方向性を特定します。
AWSのようなパートナーがいることは非常に有益です。彼らはこれらのニーズに応じたフレームワークを作成し、安全な実験の場を提供してくれます。このフレームワークを使用して、当社が従来の製造業からモビリティカンパニーの視点へと移行する中で、経験レベルの異なるチームメンバー間の知識ギャップという重要な課題を特定しました。これにより、異なるチームメンバーが情報を入力し、新規参入メンバーや異なる言語を使用する地域全体に情報を効率的に展開できる知識保持プラットフォームを作成するというアイデアが生まれました。
Generative AIの登場により最も役立つ要素の1つは、物語形式での言語に焦点を当てていることです。これを効果的に活用するために、Generative AIがどこで私たちを加速させるのかを特定できるよう、この知識保持の仕組みを人間が作る場合のプロセスを検討しました。基本的な人間のプロセスには、Subject Matter Expertと対話して情報を記録し、関連文書を確認し、2つのソースを比較して、その情報が最新なのか、古いのか、あるいは将来を見据えたものなのかを検証することが含まれます。その後、文書が作成され、組織全体に配布されます。
これを整理した結果、Amazonチームと協力してGenerative AIプロセスを使用し、組織全体でこれらのタスクを非同期的に実行するシステムを作成できることに気づきました。これを実装する際、RAGベースのシステムの初期コンテキストを作成するアーキテクチャを開発しました。ユースケースを概説する文書をアップロードすると、システムは人間の知識移転と同様に、そのトピックに関する質問に答えるインタビューを実施します。システムは提出された情報に対して文書を分析し、他のチームメンバーが情報を照会し理解できるデジタルミラーを作成します。
Amazonのサービスを使用することで、異なる言語への翻訳や文字起こしのコンテキストを提供できます。人間との会話では、自然に推測できるコンテキストを省略したり、不完全な文や単純な肯定語を使用したりすることがよくあります。Generative AIシステムを使用することで、トピックを取り上げ、関連する質問を提案し、異なるチームメンバーに伝える必要のある知識ギャップを埋めるために、概念をさらに掘り下げることができます。このシステムは、Amazon SageMakerやAmazon Bedrockで構築されたパイプラインを通じて、異なる対象者向けに質問を作成し、複数のユースケースに対応できます。ユーザーがインタビューを通じて情報を提出すると、システムは各対象者に関連するチャンクを分類し、チャットボットは非常に高度な内容に限定されることなく、ユーザーの専門知識レベルと視点に基づいて情報を取得し、伝達することができます。
私たちが学んだことの1つは、Large Language Modelsに入力する情報は、複数のシステムで使用できるように質問と回答のペアという形式で構造化する必要があるということです。これがGenerative AIの利点です。データセットをLLMsが消費できる形式で用意すれば、それをAIネイティブなデータに変換でき、すべてのモデルが同じTransformerアーキテクチャに基づいているため、複数のモデルで活用することができます。
特定のモデルやLLM向けに設計するのではなく、データを移植可能な形にすることで、将来のデータニーズに備え、企業全体の知識を獲得することができます。将来新しいモデルが登場したり、独自のモデルを改良したり、トレーニングしたりする際には、統一されたデータセットから作業を進め、継続的に改善することができます。将来的な展開として私たちが想定しているのは、ビデオなどのコンテンツ内で複数の検索を実行し、ユーザーの発言に関連する動画の特定のコンテキスト部分にディープリンクで飛び、それを図表やビジュアル要素などの他のドキュメントに追加して、トピックの文脈をさらに説明し補強できるようになることです。
GearPalとBattery Brain：製造ラインを支えるAIアプリケーション
ここでGearPalについて、Kordelに引き継ぎたいと思います。皆さん、こんにちは。Kordel Franceです。本日は、Toyotaの車両製造において私たちが構築しているGenerative AIのユースケースをいくつかご紹介させていただきます。最初のユースケースがGearPalです。GearPalの基本的な目的は、製造ライン上で機械が停止した際の平均修理時間を効果的に短縮することです。これを考案した私の同僚たちは、Kentuckyプラントのパワートレイン製造ラインで機械が停止した際の問題をより迅速にトリアージできるツールを求めていました。
GearPalが実現するのは、製造ライン上のチームメンバーが機械の前に立ち、「なぜ故障したのか、どうやって修理すればいいのか」と尋ねることができる機能です。パワートレインを組み立てるには、何百もの機械と何千もの部品が必要です。これらの機械にはそれぞれ数千ページにも及ぶマニュアル、部品在庫リスト、そして機械の故障原因に関連する可能性のある複数の文書があります。機械が停止した時、それを復旧させる方法を知っている専門家は限られています。マニュアルが異なる言語で書かれている場合もあるため、翻訳者が必要になることもあります。適任者が休暇中である可能性もあり、機械を復旧させるまでに文字通り何時間も、時には何日もかかることがあります。製造ライン上で機械が1時間停止するごとに、Toyotaは数千ドル、場合によっては停止時間や機械の種類によって数万ドル以上のコストが発生します。
私たちがGearPalで構築したのは、これらすべての機械に関するすべての文書を1つのデータベースに集約し、ユーザーが機械を復旧させる方法について質問し検索できるようにする機能です。画面の図をご覧いただくと、RAGに詳しい方やRAGアプリケーションを構築したことがある方なら、特に目新しいものは見当たらないかもしれません。これは非常に基本的なハイレベルアーキテクチャですが、それこそが美しさの一つです。複雑さの大部分はデータ取り込みの部分にありました。文書の中には異なる言語で書かれているものがあるため、必要な形に微調整するまでに何度か試行錯誤が必要でした。機械の中には日本製、ドイツ製、アメリカ製のものがあり、それぞれのマニュアルは各国の言語で書かれています。マニュアルはすべて複雑で、図面、表、画像、そして表の中に表が入れ子になっているものもあります。各文書から知識を実際に抽出するのは困難な作業でした。そのため、この取り込みパイプラインを最初に構築した際は、1つのデータタイプから始めて、徐々に他のタイプに拡張していきました。私たちが扱っていたのは、それ自体が複雑なPDFのマニュアルだけでなく、Excelデータ、PowerPointデータ、動画、画像なども含まれていました。
これらの動画を文字起こしする必要があり、このパイプラインを構築する際にデータに依存しない設計を目指しました。最初に言語翻訳なしで構築した時、各言語を個別に検索する必要があり、検索が直列的に行われることでユーザーにとって高いレイテンシーが発生することに気付きました。
この問題を解決するため、すべてのデータを英語に変換することにしました。すべてを英語に標準化し、英語でベクトルを作成することで、取り込み可能な共通言語を得ることができました。これはデータ取り込みの段階で行われるため取り込みに時間がかかりますが、一つの言語で検索できるためレイテンシーは低下しました。日本人チームメンバーや他の言語を話すメンバーに対して回答を翻訳する必要がある場合は、クエリの後で行います。ユーザーがクエリを入力し、回答を受け取った後、必要に応じてその場で翻訳を行います。
このChatbotアプリケーションには多くの複雑な要素がありましたが、基本的なRAGの原則はここでも当てはまります。これを拡張可能にし、あまり特殊なことをせず、基本的なAWSサービスに依存したことが、このアプリケーションの成功を可能にしました。 GearPalのRAGフレームワークの成功に貢献したもう一つの要因は、ゴールデンクエリセットを構築できたことです。言語モデルが現実に即していて、誤った情報を生成せず、正確な回答を提供していることを確認するため、ChatGPTのような親指を上げる/下げるというフィードバックシステムを実装しました。
親指を上げる/下げる評価には3つの要素があります。回答に親指を上げる場合、正しい回答である必要がありますが、私たちは回答の中で文書も引用しています。単に「これが見つかりました」というだけでなく、「どこで見つけたか」、そしてExcelシートの具体的なページやタブまで示します。親指を上げるには、正しい回答、正しい文書、正しいページの3つが必要です。これらすべてが当てはまる場合、そのクエリをゴールデンクエリとして使用し、Large Language Modelの微調整に活用できます。これにより、データ取り込み方法を調整したり、将来別のLarge Language Modelに切り替えたりしても、ユーザーに正確な回答を提供し続けられることを確認できます。
データに依存しない取り込みは予想以上に困難でしたが、このアプリケーションを構築する上で最も重要な課題の一つでした。これは後にBattery Brainと呼ばれる別のアプリケーションにも再利用することができました。 Battery BrainはGearPalに似ていますが、いくつかの点で異なります。製造業に携わった人なら誰でも知っているように、良い部品を生産するには多くの変数があります。自動車製造では、化学プロセスのバランスを取る必要があり、さまざまな材料の純度を評価する必要があるため、そのプロセスはさらに繊細です。
現在、バッテリーに関する専門知識への需要は供給をはるかに上回っています。Toyotaは社内トレーニングを実施し、他のチームメンバーにバッテリー製造の専門知識を提供することを自ら決定しました。博士レベルの化学知識とバッテリー製造の知識が、Toyota内の他のチームメンバーに展開・共有され、製造プロセスの問題点を発見し最適化する能力を高めています。これは特に重要です。なぜなら、North Carolinaに新しい製造工場を立ち上げており、新工場では部品の不良率が高くなりがちで、特にバッテリーではその傾向が顕著だからです。この不良率を下げるため、製造工場の全チームメンバーが様々な問題の診断や調整に必要な知識を可能な限り持てるようにしています。これにより効率を高め、不良率を下げることができます。これがBattery Brainの基本的な前提であり、製造ライン上でのバッテリーの不良率を低減することを目指しています。
この考えを発展させ、製造ライン上では非常に似たアーキテクチャで、GearPalと非常に似たアプリケーションとなっています。これは特定のプロセスについて質問できるチャットボットで、必ずしも機械に限定されません。GearPalのように機械に関することもありますが、例えば「カソードのテスト結果が最適値に達していないことに気付きました。これをどう修正すればよいですか？何が問題かもしれませんか？材料特性を確認する必要がありますか？」といった質問も可能です。Battery Brainの目的は、必ずしも正解を提供することではなく、正解にたどり着くために何をチェックすべきかというアイデアをユーザーに提供することです。つまり、材料特性をチェックしましたか？機械のキャリブレーションは確認しましたか？といった具合に、結果を確認し、問題をより適切に診断するためのチェックリストを提供することで、大きな助けとなっています。
Battery Brainで最も困難だったことの1つは、インターネット検索結果で補完することでした。この製品の要件を出したビジネスユニットは、最先端のバッテリーの知識を回答に組み込むことを求めていました。そのために、バッテリー製造、バッテリー技術、固体電池、液体電解質バッテリーに関する信頼できるサイトにアクセスし、その情報を検索結果に組み込む必要がありましたが、これには独自の課題がありました。私たちが採用したプロセスは、ユーザーが質問をした際に、与えられたデータの中で適切な結果が見つからない場合、コサイン類似度をしきい値として使用します。コサイン類似度が特定のしきい値を下回った場合、インターネット上の選択されたサイトにアクセスして回答を探します。それが見つかった場合、ユーザーに対して、文書内では見つからなかったがオンラインで情報が見つかったことを伝えながら回答を提供します。このようなハイブリッド検索の実現には、バランスと相関関係の調整に時間がかかりました。
GearPalと同様に、Battery Brainのもう1つの複雑な点は、Toyotaのバッテリー製造知識トレーニングから生まれた大量のMicrosoft OneNoteドキュメントの存在でした。すべてのユーザーがMicrosoft OneNoteでメモを取っており、ご存知の方もいると思いますが、これは大変な課題です。OneNoteには様々な形式の情報を入れることができるからです。各自が独自のメモの取り方をしており、手書きや略語、定義なしで使用される様々な頭字語、キャプション付きの画像、キャプション無しの画像などがあり、標準化や取り込みが非常に困難でした。私たちは再び工夫を凝らし、構造化されていないドキュメントに遭遇した際にも文脈から推論を導き出せる、データに依存しない取り込みパイプラインを確立する必要がありました。
Battery BrainとGearPalから得られた学びの1つは、共通のRAGフレームワーク、共通のRAGパイプラインを使用できたことです。これにより、異なる機能で分岐が必要になるポイントまで、基本的にアプリケーションを共同でコーディングすることができました。多くのコードを再利用でき、データに依存しない取り込みパイプラインやプロセスを強化することができ、先ほどStephenが言及したように、他のアプリケーションでも再利用できるようになりました。Large Language Modelにトヨタ生産方式を組み込むことができました。Toyotaの車両生産方式をご存じの方もいると思いますが、非常に特殊な方法で行われており、これにより追加の品質管理レベルを実現できます。GearPalで使用したフィードバックメカニズムをBattery Brainでも使用してGolden Queriesを確立し、より多くのデータをより迅速に理解できるようになりました。
Mainframe modernizationとToyotaの未来展望
この2つのアプリケーションを構築することで、今後Toyotaグループ内の他のGenerative AIアプリケーションへと展開できる基盤を確立することができました。次のユースケースについてお話しするために、同僚のPaulに引き継ぎたいと思います。ありがとうございます。Kordelと私の仲間たちに拍手をお願いします。さて、クイズの準備はできていますか？ Mainframe modernizationは、私がToyotaで携わったプロジェクトの中で最も興味深いものの1つです。なぜかというと、一見シンプルな課題に見えて、実際にはとても複雑だからです。
私たちが直面した課題は、最初は単純に見えました - あるタイプのコードを別のタイプに変換するというものでした。しかし、Mainframeは複数のプログラムがアプリケーションとして実行され、ネットワーク接続を介して相互に通信する複雑な共有システムです。現代のアプリケーションアーキテクチャでは、API、Webサーバー、エンドポイントがあるため、ネットワーク接続とアプリケーション層の間のギャップを埋めることが重要になります。数年前、ToyotaはAWS以外のハイパースケーラーを雇って、MainframeコードをJavaなどの現代的な言語に変換しようとしましたが、この試みは失敗に終わりました。
この失敗は、Toyota内の複数の部門が同じ共有環境で作業していたことが原因でした。課題は、コンサルティング会社やベンダーが、本番環境に影響を与えることなく、そのコードを変換してMainframeシステムとクラウドの間でホットスワップできるという信頼を得ることでした。下流システムへの影響は、車両生産を停止させる可能性があり、ビジネスに直接影響を与える可能性がありました。しかし、これは最終的にパートナーシップの成功事例となりました - AWSとToyotaの間、Toyotaの車両サプライチェーンチームなどの社内チームの間、そして人間とAIの間のパートナーシップです。
さらに詳しく見ていきましょう。Hugging Face Transformersについて読んだことがある方なら、Pipelineという用語をご存知でしょう。これはテキスト要約やテキスト生成に使用できますが、このケースではテキスト分類のためのPipelineです。会場の皆さんに、このコードがCOBOLなのかJCLなのかを判別できる人は手を挙げてくださいと言っても、多くの方は判別できないでしょう。幸いなことに、Amazon Qはその機能によってCOBOLで書かれたコードを理解し、ルールを導き出すことができます。特定のプログラムに適用されるルールセットとビジネスルールを判断することに非常に長けています。
現代のコード変換には2段階のプロセスが必要です。最初のステップは、コンテンツについて推論できるようにコードをテキストに変換することです - プログラムのどの部分がデータの消費者または提供者なのか、どのような変数、テーブル、データベース、エンティティがコード内に存在するのかを特定します。これにより信頼性と理解が得られ、AIがコードを読みやすいテキストに正しく変換したかどうかを人間が検証できるようになります。 Generative AIとソースコード分析用のKnowledge Graphsを使用して、AWSとの協力により3ページの出力を生成し、プログラムの高レベルな概要、ビジネスロジックと機能、および関連するデータフローを示すことができました。
このスライドで私が取り上げたいのは、単純な略語「SSN」についてです。多くの人はこれをSocial Security Numberと解釈するでしょうが、車両生産においては全く異なる意味を持ちます。実際、Toyotaには恐らく5000以上の異なる略語が存在しており、コード変換を行うシステムはそれらすべてを認識している必要があります。
AWSで仕事をしていると、フロントラインチームとサービスチームの連携を間近で見ることができます。私は、コード変換に関連するAmazon Qのバックエンドを直接目にする機会がありました。そこで私が見たのは、ナレッジグラフ、つまり十分に理解された信頼できるシステムでした。これは実際に機能するという確信を私に与えてくれました。
人間のフィードバックループは、このプロジェクトの成功に不可欠でした。最初の生成時は約80%の精度でしたが、複数回の反復を経て完了する頃には、コードからテキストへの変換の精度は90%以上に達しました。まず第一に、私たちのCOBOLコードを分析するために構築されたシステムには組織的な知識がなく、それを提供するのが人間なのです。Generative AIは支援技術であり、人間に取って代わるものではありません。また、システムが完璧に処理してくれると信じて、Generative AIシステムの結果を盲目的に受け入れようとする人はいません。そのため、結果を素早く、確実に、簡単に検証できるツールを提供することが非常に重要です。
車両サプライチェーンチームは、問題に関する文脈的な理解を持って精度評価に参加しました。これにより、移行における依存関係を把握し、Toyotaの生産に影響を与えることなく移行できる独立した部分を特定することができました。また、プログラムセット内の各プログラムの複雑さとサイズ、そしてビジネスへの影響を徹底的に理解することができました。最終的に、AmazonチームはUIを提供してくれました。そこでCOBOLプログラムをロードすると、データフロー、エンティティ、データベースなどが生成され、それらをダウンロード、検証、使用することができました。
では、未来についてお話ししましょう。私たちはAIを時間の観点から考えています。これは一つのアプローチです。タスクには5秒で終わるもの、5分かかるもの、5時間かかるものがあります。Generative AIは5秒から5分のタスクにおいては非常に優れた性能を発揮します。では、5時間のタスクと未来はどうでしょうか？私たちが考える未来は、推論エンジンとLLMの入出力に対する形式論理の適用にあります。
現在、Toyotaは消費者向けおよびエンタープライズ向けの両方でAIへの投資を行っています。会場の皆様の多くはToyotaやLexusのオーナーだと思います。皆様には、これからも私たちのお客様として、そして共に未来のモビリティを創造していく仲間として期待しています。本日はご来場いただき、ありがとうございました。アンケートへのご協力をお願いいたします。皆様からのフィードバックは、今後のプレゼンテーションや全体的なコンテンツの改善に活かさせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion