re:Invent 2024: VWグループがAWSと進める製造業のデジタル化戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 -Volkswagen’s platform strategy enables production performance & quality (MFG207)
この動画では、Volkswagen GroupのSenior Vice President for IT Production and LogisticsのThomas Bierwirthが、製造業のデジタル化への取り組みについて解説しています。製造業の68%がデジタル化に着手する一方で、その価値を確信しているのは30%未満という現状を踏まえ、Volkswagenが5年間かけてAWSと共に進めてきた取り組みを紹介しています。特に、IRIS Coreを活用したComputer Visionのユースケースや、80件に及ぶクラウドソリューションの実装例が具体的に説明されています。さらに、Legacy systemの刷新による20%のコスト削減可能性や、GenAIを活用したコード分析など、今後の展望についても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
プレゼンテーションの開始：自己紹介と参加者への歓迎
このように多くの方々、そして懐かしい顔ぶれと新しい顔ぶれの両方にお会いできて、とても嬉しく思います。ここに立てて光栄です。Xの位置に立つように言われましたので、もし私が明るい方に行きすぎたら、このジェスチャーをしてください。赤い方に行きすぎたら、あのジェスチャーをしていただければ、Xの位置に戻ります。カメラに収まるためにここにいなければならないんです。
先ほど申し上げた通り、イベント4日目にもかかわらず、皆様にお越しいただき大変嬉しく思います。きっと既に、たくさんの興味深いセッションで頭がパンパンになっていることと思います。皆様がここにいらっしゃるということは、これから私たちがお話しするトピックに関心をお持ちだということの表れですね。この後の60分間で、皆様の今後の取り組みに活かせる情報やユースケース、エピソード、そしてデータをお持ち帰りいただけるよう努めてまいります。どうぞリラックスして、最後までお付き合いください。
本日は2名のゲストをお迎えしています。1人目は、Volkswagen GroupのSenior Vice President for IT Production and LogisticsのThomas Bierwirthです。Thomasは自動車業界とデジタル化の分野で20年以上の経験を持つベテランで、機械工学とComputer Scienceで博士号を取得しています。Volkswagen Groupでは複数のプロダクトローンチを成功させ、その前にはSAPでLogisticsとデジタル化に関する複数のプロダクトを立ち上げた経験をお持ちです。
また、Verena KoutsovagelisもAWSから参加しています。彼女はAWSに約2年在籍していますが、AWSでは面白い計算の仕方があります。私たちは在籍年数を犬年で計算するんです。最初の1年は人間の15年分、2年目は9年分とカウントします。つまり、Verenaの在籍期間は人間年齢で24年ということになりますね。彼女は今日、Customer Solutions Managerとして手がけたVolkswagenのユースケースについてお話しいただきます。
最後に、私自身の紹介をさせていただきます。私はAutomotiveとManufacturingのTech Strategyを担当しており、AWSに約2年半在籍しています。Nokia TelcoやContinental Tier Oneなど、様々な業界での経験を持つ業界人です。生活をより安全で快適にできるものすべてに情熱を持っており、本日はモデレーターを務めさせていただきます。これからの時間は主にThomasとVerenaにステージに立っていただくことになります。
Volkswagenグループの概要とデジタルトランスフォーメーションの課題
まず最初にデータをご紹介させていただきます。ご存知の通り、Amazonはデータ重視の企業です。製造業の約68%がデジタル化への取り組みを開始しているか、今後数ヶ月以内に開始する予定ですが、この変革のビジネス価値を確信しているのは30%未満に留まっています。40%以上の製造業者がPilot Purgatoryの状態で足踏みしており、統合に関する課題と格闘しています。これは簡単な変革ではありません - 簡単であれば誰でもできてしまいます。その背後には複雑さがあり、何をいつ行うかについて強い確信を持ち、慎重に進める必要があります。マネージャーのサポートも必要不可欠です。
ここで、Volkswagenグループの取り組みについてご紹介いただくため、Thomasさんをお迎えしたいと思います。Thomasさん、よろしくお願いします。わあ、ここは照明が明るいですね。 私たちのデジタルトランスフォーメーションについてお話しする際に、私たちの企業について考えました。一般的なKPIに焦点を当てるのではなく、 単に従業員が65,000人以上いる、13のブランドがある、世界に114以上の施設があり、3,200億ユーロの収益がある、といった話をするのではなく、私たちのポートフォリオをお見せしたいと思います。本日ご紹介するのは、これから発売される製品です。アメリカではAtlasやTiguanをご存知かもしれませんが、VW GolfやGTIのような魅力的な製品も展開しています。
もちろん、ID.ファミリーという完全電動化製品群もあり、アメリカでもID. Buzzの発売をご覧になったかもしれません。他にも多くの製品が控えていますが、VWの製品ロードマップ全体についてはここでは触れません。特筆すべきは、アメリカで展開予定のScoutで、ピックアップトラックとSUVの両バージョンを用意した完全電気自動車として間もなく登場します。私たちはこれにとても期待を寄せています。
このスライドを見ると、2つのポートフォリオがあります。よく見ると、これは従来型の自動車メーカーとしての私たちの一つの側面です。現在、私たちのポートフォリオは内燃機関車と完全電気自動車に分かれています。中間のハイブリッド車はなく、2種類の車を運営しなければなりません。例えば、テネシー州チャタヌーガの工場では、同じ組立ラインで内燃機関車と電気自動車の両方を製造しており、これが運営の複雑さを増しています。
少なくとも3つの技術トレンドがあります。 1つ目はDigitalization、2つ目はAutonomousとElectricです。Electricについては既にお話ししましたが、これらのトレンドは密接に結びついています。スマートフォンを例に考えてみましょう - 電気自動車のリモコンとして機能します。電気自動車のドライバーとして、私はスマートフォンで旅程を計画し、次の充電ステーションの場所を確認し、車内を冷やすなどの命令を車に送ります。これは、IoT領域のデジタル技術が製品に大きな影響を与えており、車自体がIoTデバイスになっているということを意味します。
電気自動車の複雑さは、車内に多数のIoTデバイスである電子制御ユニットが搭載されていることを考えると、さらに増します。例えば、車の温度を75度に設定するコマンドを送信すると、そのコマンドはCloudを経由して車に送られ、接続ユニットで受信され、車の温度を制御するコンピュータに伝達されます。物流や生産においては、工場の機械やロボットがインテリジェント化され、ネットワークに接続され、ソフトウェアアップデートを受けるようになったため、IoTデバイスがIoTデバイスを製造するという状況が生まれています。内燃機関車と電気自動車の両方を製造する際には、同じラインで異なるタイプの車を生産するために、サイクル内で機械をアップデートする必要があります。
これらのトレンドは必然的にデータ管理につながります。なぜなら、究極的にはデータの交換だからです。まず接続性を確立し、データの読み書き、データの消費、データの処理、データを扱うアプリケーション、そしてデータの送り返しを行う必要があります。データ、デジタル化、そして電気は密接に関連しています。そしてもう一つのトレンドが登場します：レジリエントなサプライチェーンです。COVID以降、私たちは混乱が日常生活にどのような影響を与えるかを経験してきました。一台の車は約2,000個の部品で構成され、それらが最終組み立てで一つになることを考えてみてください。何らかの理由で部品が止まった時の物流へのストレスは想像に難くありません。世界で危機や病気、中断が増える中、私たちは生産に結びつき、最終的に顧客に結びつくサプライチェーンに高い信頼性が必要です。生産は顧客とつながっており、これがスマートアプリケーションの構築方法とその対処のためのセットアップを決定する際に考慮したことです。
Sustainabilityは、私たち自動車メーカーにとって非常に重要な側面です。なぜなら、二酸化炭素の中立性を達成したいと考えており、そのフットプリントを削減するための数多くの取り組みを実施しているからです。昨日のYanとMayaのセッションに参加された方もいらっしゃると思いますが、そこではプラットフォームとパターンを使用して、電力消費、そして最終的には二酸化炭素のフットプリントをどのように削減したかについて発表しました。
Volkswagenの生産プロセスとAWSとのパートナーシップ
グローバリゼーションについては、世界中にスマートなチームがあり、多くのチームと協力関係を持っています。私たちはこの知識をグローバル製品の構築に活用したいと考えています。 では、私たちのプロセスと全体像はどのようなものでしょうか？私たちは3つの主要な次元を特定しました。1つ目はプロセス自体で、多くの方が基本的な自動車のプロセスをご存知だと思います。すべては顧客の注文から始まります。顧客の注文を受けた後、すべてのコンポーネントや部品を考慮し、どの施設で製造するかを決定する必要があります。顧客への納期を提示する必要があり、そのためにはスケジューリングが必要で、その後に基本的なプロセスが続きます。車が完成すると、組立場所は通常顧客の居住地ではないため、出荷プロセスが始まります。
オペレーションには多くのシステムが関与しています。工場を運営する際には、どの人がどのサイクルタイムで何をするのかを正確に把握する、非常に詳細な計画が必要です。生産管理システムでは柔軟性が求められます。サプライチェーンや顧客の注文順序に変更がある場合、制御システムを通じて適応する必要があります。物流においては、倉庫管理が常に重要です。レジリエントなサプライチェーンを望むなら、相当な在庫が必要ですが、管理者は倉庫の在庫は無駄なお金だと主張し、これは常にトレードオフの関係にあります。
皆さんがご存知ないかもしれない重要な点として、私たちの車両とTCSにおける主要なデバイスについてお話しします。約56個の非常に重要なデバイスがあり、それぞれが約3,000万行のコードを含んでいます。現代の車両はもはや単なる金属の塊ではなく、生産中に管理が必要なコードを持つIOデバイスなのです。つまり、生産時の車両設定のためのプロセスが必要になります。最後の要素はデータで、これがすべてを結びつけています - Logisticsから生産能力管理、車両設定から人的作業計画まで。これが、将来のアプリケーションの構築方法、モダナイゼーションの実施方法、AIの実装方法、そして運用方法を決定するための私たちの出発点でした。
AWSとともに、私たちは5年間にわたるパートナーシップを確立してきました。伝統的な自動車メーカーとして、私たちは車両の製造・生産とそれらのプロセス管理に関する知識を提供し、世界最大級のテクノロジー企業の一つとパートナーシップを組みました。ここで、Verenaが、このパートナーシップにおけるAWSの関与について説明します。Volkswagenのクラウドプロバイダーとしてクラウドサービスを提供するだけでなく、私たちは過去5年間、Volkswagenと密接に協力して、クラウドソリューションをグローバルに展開する方法を示してきました。複数の工場と協力して、いわゆるユースケースとなるクラウドソリューションを構築してきました。
そして、「大きく考える」というリーダーシップの原則に従い、私たちは常にイノベーションに突き動かされ、可能な限り迅速にイノベーションを推進しようと努めてきました。クラウドソリューションは、私たちの主要なユースケースを表しています。また、Volkswagenにクラウドを実現手段として活用する方法も示してきました。クラウドをイノベーションの推進力として活用する方法を示し、これから Thomasが過去5年間で実際に構築してきたものをお見せします。ご安心ください、また戻ってきます。
まず、クラウド戦略自体について説明させていただき、その後、技術的な基盤がどのようなものかを段階的に詳しく見ていきましょう。基本原則はこのスライドに示されています。私たちが開発した3層アーキテクチャで、最下層の基盤層には、Connectivityとデータ層があります。この形状で構築した理由は、非常に多くのプロトコルと統合要件があったためです。新しい工場もあれば古い工場もあり、新しい技術も古い技術もあることを考えると、これらの異なる要素やデバイスのための広範な統合作業が必要になります。
Shopfloorエリアにおける最初の活動は、すべてを接続し、データを抽出できるようにすべてのプロトコルを記述することです。この段階が完了すると、次の重要な問題は、それをどのように解釈するかということです。例えば、Chattanoogaの機械データを持っていて、それをWBGやMexicoにある同様または同一の機械と比較したい場合、開発者として平均修理時間や平均故障時間などの特定の値を見る際、これらの値が本当に比較可能であることを確認する必要があります。つまり、手動入力とクロスチェックに頼るのではなく、自動化するために現在も開発を続けているデータ調和のための別のレイヤーが必要になるのです。
中間層では、一般的なイネーブラーを実装しました。これらは典型的なGet関数、つまり位置情報の取得、データの取得、何かを取得するような機能です。アプリケーション開発者として、異なる場所で同じコードを何度も書かなくて済むように、最初のアプリケーションセットを使用したいと考えるでしょう。すべてのコードを書くことなく、プラットフォームの接続性と初期の実現機能を持ちたいわけです。最後に、最上位層には、それを使用するお客様に利益をもたらす付加価値アプリケーションがすべて含まれています。これらのValue Appsは、コスト効率を推進するため非常に重要です。これらのアプリケーションの1つについて詳しく説明したいと思いますので、Marinaに戻して、アプリケーションの1つをご紹介したいと思います。
IRIS Coreを活用した産業用Computer Visionのユースケース
ありがとうございます、Thomas。ユースケースをご覧いただくのを楽しみにされているのは分かりますが、その前に2021年を振り返ってみましょう。2021年にリモートで開催されたre:inventに参加された方々は覚えていらっしゃるかもしれませんが、その時私たちはDPPにおける最初の産業用Computer Visionのユースケースとして、Intelligent Sign Inspection（ISI）を発表しました。当時、ISIはVision Workbenchサービス上に構築されていました。写真にあるように、これはシンプルなユースケースで、モバイルデバイスを手に持って車両のラベルをスキャンし、ラベルやサインが正しく車両に配置されているかを確認するための情報ポイントについて、即座にフィードバックを受け取ることができます。これは特に、読みづらい外国語のラベルを扱う際に非常に価値があります。
素晴らしいユースケースだったため、私たちは他のブランドや工場にも展開したいと考えました。しかし、Vision Workbenchでは常に一からやり直す必要があり、それが課題でした。そのため、VWの別チーム、具体的にはDraysonのソフトウェア開発センターのHoverのチームが、AIモデルを使用した画像評価のための完全クラウドベースのソリューションであるIRIS Coreを構築しました。
ここでは非常にハイレベルなアーキテクチャをご覧いただけます。上部から、IRIS Coreへのリクエストがあり、基本的には画像データがAmazon SQSを通過します。Amazon SQS（Simple Queue Service）は、サーバーレスアプリケーションやマイクロサービス向けの完全マネージド型キューイングサービスです。一方で、AIモデルのアップロードがAIモデルデプロイメントAPIを通じて行われているのが分かります。それらがIRIS Coreで統合され、評価されたデータはSPSまたはAmazon S3バケットに送り返されます。2024年は、IRIS Coreを複数の工場に展開することに本当に注力しました。
この図で示されているように、IRIS Coreは2つの要素で構成されています。中央で開発・オーケストレーションされるIRIS Coreと、Shop FloorとCloudの間の接続性を確立するための統合層があります。2025年は、IRIS Coreのさらなる開発、つまり新機能の実装、他の工場へのロールアウトの継続、そしてIRIS Coreを使用した新しいユースケースの構築に焦点を当てていきます。
次に、2024年にIRIS Coreを使用して構築された実際のユースケース、すなわちホイール検出ユースケースについてお話しします。AWS Professional ServicesチームはVolkswagenのチームと協力し、特定の工場でこのユースケースを再構築しました。というのも、このシステムはすでに稼働していたものの、完全にオンプレミスで単一のサーバーで運用されており、高可用性の欠如、スケーラビリティの欠如、運用チームの負担が大きいなどの課題を抱えていたからです。そのため、チームはこのユースケースをクラウドで完全に再構築することを考えました。このプロセスは、Shopfloorに設置されたカメラでホイールの画像を撮影し、そのデータを収集してクラウド上のIRIS Coreサービスに送信し、IRIS Coreが4つのホイールが正しいリムを持ち、正しい数のボルトが装着されているかを確認して、OKまたはNot OKの応答をShopfloorに返すというものです。
アーキテクチャをより詳しく見てみると、これがあらゆる産業用Computer Visionのユースケースに再利用可能であることがわかります。このアーキテクチャは、Device、Edge、Plant、Enterpriseの4つの層に分かれています。 先ほど述べたように、Shopfloorにカメラがあるため、ShopfloorとCloudの間の接続性を確立する必要があります。これはDPP Connectivity Backboneによって実現されており、基本的にはMQTTメッセージブローカーです。DPP Connectivity Backboneサービスは、Shopfloorからクラウドにデータを送信し、この場合はData Hubサービスに送られ、画像データはS3 Bucketに保存されます。
ここではイベント駆動型のアーキテクチャを採用しており、新しい画像がS3 Bucketに配置されるたびに、Data HubサービスがPut通知を作成し、Amazon SNSを介してサブスクライブされたSQSに送信します。ご存じない方のために説明すると、Amazon SNSは、サブスクライブされたエンドポイントへのメッセージの配信と送信を管理する当社のシンプルな通知サービスです。最初のボックスの画像キャプチャでは、AWS Lambdaを使用して画像のコピーとデコードを行う小規模なワークフローが開始されます。AWS Lambdaは完全にサーバーレスでコードを実行する当社のコンピューティングサービスです。もう1つのボックスでは製造実行システムからのデータを集約し、両方のデータをワークフローチェックに送ります。
ワークフローチェックではAWS Step Functionsを使用して、Lambda関数をワークフローに組み込んでいます。ここでIRIS Coreが活躍します。アーキテクチャに示されているように、IRIS Coreは2つの部分で構成されています。画像データはIRIS Integrationを通じてIRIS Coreに送られます。IRIS Coreは特定のAIモデルを使用してその画像データを評価します。チームはこのユースケースの実装中に、Amazon SageMakerを使用してモデルをさらにトレーニングする機会を活用しました。IRIS Coreはデータを評価し、LambdaとSQSを介して結果をResults Tableに送り返します。
結果の保存には、当社のサーバーレスで完全マネージド型のNoSQLデータベースサービスであるAmazon DynamoDBを使用しています。Shopfloorレベルで結果を表示するために、Shopfloorの誰かがProxyを介してシステムにログインします。ProxyはリクエストをApplication Load Balancerに送信し、まずAmazon Cognitoに送信して、認証されたユーザーのみがデータにアクセスできるようにします。認証が成功すると、Application Load BalancerはリクエストをAmazon API Gatewayに送信し、そこからResults Tableにアクセスして、ShopfloorのディスプレイにOKまたはNot OKの結果を表示します。
また、ここには Emergency Strategy ボックスもあります。OK ではない結果が出た場合、Shopfloor のユーザーは別のボタンを押して Emergency Strategy を実行することができます。これにより、ミニワークフローを通じて Emergency テーブルが適切に更新され、ホイールの配置や取り出しが可能になります。これは、今年 IRIS Core で構築された完全な Serverless アーキテクチャの例です。このアーキテクチャは、あらゆる産業用 Computer Vision のユースケースに再利用できます。実行時のみ稼働するため、高いスケーラビリティ、高可用性、コスト効率性といった Cloud サービスのメリットをすべて活用できます。
Volkswagenの新たなデジタル戦略：プラットフォームアプローチへの転換
これが私たちの過去5年間の焦点でした。工場との協力、お客様との協働、お客様からの要望に基づいた取り組み、そしてこれらの素晴らしいユースケースの構築です。昨年、VW と共に私たちの North Star Narrative を調整しました。これから Thomas が、その調整内容と、今後期待される5年間のパートナーシップについてご説明します。Marina、ありがとうございました。もちろん、私たちが構築したのは1つのユースケースだけではありません。この数年間で構築したユースケースは約80件にも及びます。
80件ほどのユースケースが中間層や上位層、そしてアプリケーション層で展開されてきました。これで十分な成果が出たから、もう終わりにしようと言えるかもしれません。しかし、話はそう簡単ではありません。約1年前、私たちは Narrative を変更する必要があると考えました。なぜ Narrative を変更したのか、その理由についてお話しします。
第一に、自動車ビジネス、特に生産とロジスティクスの分野では、常に効率性とコストが重要です。生産を最も効率的に運営する方法を見つける必要があります。しかし、私たちは工場間の連携において、例えば Chattanooga の工場で構築したユースケースを Poznan や Wolfsburg に展開する際に、データモデルの制限、接続パターンの制限、アーキテクチャの制限に直面しました。そこで私たちは「待てよ、これは単に魅力的なユースケースを持つだけの問題ではない。既存の基幹システムはどうなのか」と考えました。そして、25年以上も運用されている古いアプリケーションが多数存在しているのです。
多くの方がご存じのように、本当に古いアプリケーションを持ちながら、その上で高度な AI パターンや Edge テクノロジーを動かそうとしても、うまく機能しないケースがほとんどです。そこで、ユースケースによってイノベーションと効率性を推進するだけでなく、主要な生産システムも同じパターンに移行し、これまでに開発した採用パターンを再利用できないか検討することにしました。今や私たちは Platform を持ち、Connectivity を持ち、これらの要素を持っています。ですから、段階的にその他の基幹アプリケーションを同じ Platform 空間に移行していくことを始めてみてはどうでしょうか。
主な理由として、冒頭でお見せした複雑なシステムとプロセスの図を覚えていらっしゃるかもしれませんが、多くのシステムが関係していることは想像に難くありません。しかし、アプリケーション間で簡単にコミュニケーションができ、データに関する優れた標準パターンを持つ、最新のMicroserviceベースのアーキテクチャを採用すれば、開発者の負担が軽減され、アプリケーション開発がより良くなります。そうなれば、従来のアプリケーションと比べて、データやAIパターンの活用もさらに容易になります。
私たちはアーキテクトと一緒に座り、アーキテクチャパターンをどのように調整できるか検討しました。これにより、特に私たちのお客様である工場にとって、アプリケーションの置き換えがより簡単になります。基本原則は、再利用性を高め、層を抽象化するという強固な原則です。つまり、開発者が生産・物流向けのアプリケーションを開発したい場合や、既存のアプリケーションから機能を切り出す場合、Shopfloorレベルや下位レベルとのやり取りやコミュニケーションについて、常に確固たる基盤があるということです。
ここで私たちは、構築すべき要素やEnablerを特定しました。これは今後のパートナーシップにおける次のステップの一つとして、強化し、確固たる基盤にしていく必要があります。市場からも多くのイノベーションが生まれています。今年のre:Inventでご覧になったと思いますが、多くのスマートなアイデアがあり、もちろん私たちはすべてのアプリケーションを自前で書く必要があるとは考えていません。市場に優れたソリューションがあるのなら、スマートなPlatformアプローチと市場のソリューションを組み合わせて使用すればいいのです。つまり、スマートなソリューションがあるなら、それを私たちがPlatformで構築したものと組み合わせ、もちろん、それらの要素を活用して、より賢く物事を前に進めていきたいと考えています。
もう一つの非常に興味深い要素は、チームの設置方法です。Sprintで作業したりAgileな手法を使用したりすることは、多くの方々にとって一般的な実践かもしれませんが、自動車業界にとっては新しいパターンです。私たちはSAFeフレームワークなどを使用してAgileな作業を開始し、現在はチームと機能を連携させ、チーム同士が相互に作用し、異なるプロダクト同士が対話するようになっています。これらのチームをより強く結びつけ、相互作用させる必要があるということも、最近の経験から学んだことです。
特に私たちの古いシステムやいわゆるLegacyの世界において、最大のコストドライバーが何であるかを調査しました。50から100の工場にまたがる生産・物流の大規模なシステムがある場合、工場1から始めてロールアウトを進めていきます。工場20や50に到達する頃には、最初の工場が再度アップデートを必要とするため、最初からやり直さなければなりません。これは非常に困難な課題となり得るため、Microserviceベースのアプローチで、より扱いやすい要素に分割するというスマートなアプローチが必要です。私たちのアイデアは、現在のシステムから機能を段階的に抽出しながら、新規構築アプリケーションを増やし、市場のアプリケーションをSaaSソリューションとして使用し、ロールアウトパターンをより容易にすることです。
600個もの機能を持つアプリケーションを実装するのではなく、10個か20個程度の機能に特化した小規模な機能を導入する方が、はるかに簡単です。大きな象を無理に通すようなことをせずに、トレーニングやロールアウトがより容易になります。私たちは様々なアプローチで取り組んできましたが、昨年特に重視したのがAgileな働き方でした。これにより、非常に良好な体制を実現できました。チームにとって、この新しい働き方は本当にうまく機能していると思います。
プラットフォーム戦略の具体的な実装と今後の展望
改めてプラットフォームの全体像に戻りますと、冒頭でお見せした3層構造の図を、今度は下から上ではなく左から右に見ていきましょう。基本的な原理をご説明します。まず工場のShopfloorレベルに物理的なハードウェアであるデバイスがあります。次にEdgeがあり、これは様々なパートナーから提供されるOT Gatewayテクノロジーで、私たちの施設や工場に導入されています。異なるタイプのデータ（ストリーミングデータ、バッチデータ、オンラインデータ）とやり取りするために、様々なテクノロジーやプロトコル、そしてこの接続のための各種サービスを構築する必要がありました。
最終的に、主にMessage BrokerテクノロジーやMQTTテクノロジーを使用してCloudにデータを送信します。その後、データレイヤー、抽象化レイヤー、正規化レイヤー、そしてそれらにアクセスするためのAPIが続きます。重要なのは、右側のビジネスアプリケーション側、つまり開発者側で、アプリケーションを書くたびにこれらの苦労を繰り返す必要がないということです。データやパターンをもっと簡単に利用できるようにすべきなのです。最後に2つのパターンが見えますが、1つはMarinaが説明した、これまで注力してきたアプリケーションの開発です。今後は、同じインフラパターンを使用して、生産計画や生産実行のための基本的なアプリケーションを同じエコシステムに組み込んでいきたいと考えています。これが私たちのスタート地点となる基本的な考え方です。
このコンセプトに取り組む中で、プラットフォームビジネスの例を見てみましょう。プラットフォームを運営している企業は、通常非常に成功している企業です。これらのプラットフォームパターンを使用すると、優れた再利用性が得られます。これは私たちが目指すものと似ています。プラットフォームレベルでより多くのテクノロジーと最新のセキュリティ機能を持つことができるため、リスク低減にもつながります。
経済的なメリットの観点から見ると、現在のLegacyシステムのコストは継続的に増加しており、イノベーションとサポートの比率が部分的に不健全な状況にあります。私たちが目指すのは、よりサポートの少なくて済む、新しい小規模なアプリケーションパターンへの置き換えです。このアプローチにより、スライドに示されているように、コストを削減できると確信しています。刷新だけで現在のアプリケーションコストを20%削減することが可能になります。
今後のユースケースを見てみると、例えばサプライチェーンがダウンして生産の再計算や再計画が必要になった場合、現在は全く異なるシステム同士がコミュニケーションを取る必要があるため、非常に困難です。しかし、同じデータパターンとプラットフォームパターンを持っていれば、対応がはるかに容易になります。サプライヤーに問題が発生した場合、生産チームに直接通知し、新しいプログラムパターンを作成して再編成し、物流にフィードバックを提供することができます。これらすべてのやり取りは、プラットフォームによって実現され、提供されています。
サプライチェーンの課題、人材不足、原材料の価格と供給の問題など、製造業者が持続可能な方法で持続可能な製品を作ることを意図的に目指す中で、様々な課題に直面しています。これらは製造業者がデジタル化の旅を開始し、継続し、加速させる理由のほんの一部です。これは段階的なプロセスであり、5年計画を立てるわけではありません。旅を始め、学び、反復し、インクリメンタルに取り組み、AWSやパートナーと協力していきます。パートナーは全てExpoエリアでご覧いただけます。これは非常に興味深い反復的な旅なのです。
私たちはすでにAIを使用したいくつかのパターンについて話しましたが、次のレベルは何かという疑問があります。現在私たちが考えているのは、古いシステムであっても、そのロジックとプロセスは優れており意味があるということです。しかし、コーディングやアーキテクチャが最適でない可能性があります。ここでGenAIの出番です - 現在のシステムのコードを分析することは可能でしょうか？GenAIを使って、システムのロジックを維持しながら、コードをより良いポーション、プロダクト、アーキテクチャに再編成する方法を見つけることができるでしょうか？現在、QとBeroを使用してコードを分析し、より良いソリューションを開発する方法を探るためのいくつかのパイロットプロジェクトを検討しています。
5年前であれば、この質問への答えは全く異なっていたでしょう。このように技術は進化しており、常に最新の動向を把握しておく必要があります。皆様のre:Inventの残りの時間が素晴らしいものになりますように。音楽を楽しみ、セッションを楽しみ、Expoエリアにもお立ち寄りください。多くのパートナーがいますし、DennisとMayaがいれば、Professional Servicesチームもいますので、質問することができます。ステージを去る前の最後の言葉として、これは私たち個人の仕事だけではありません。ここVegasにいない私たちのチームに感謝し、また、この数年間の皆様の関与と努力に感謝したいと思います。これからも前進し続けましょう。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion