re:Invent 2025: BoeingのPLMシステムAWSクラウド移行による環境構築99%削減事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Modernizing Legacy Systems: Boeing's PLM Cloud Transformation (IND321)
この動画では、BoeingがAWS上でPLM（Product Lifecycle Management）システムのモダナイゼーションを実現した事例が紹介されています。Justin Iravani氏、Jim Gallagher氏、Dan Meyering氏が、レガシーなオンプレミスインフラの課題、特に官僚的なプロビジョニングプロセスや手動作業の多さを説明し、AWS GovCloud、EC2、RDS、EFS、Application Load Balancerなどのサービスを活用した解決策を提示しています。TerraformによるInfrastructure as CodeとAnsibleによる構成管理を導入し、環境構築時間を30日から5時間へと99%削減、手動タスクを78%削減、インフラコストを40%以上削減した具体的な成果が示されています。さらに、生成AIとエージェント型AIを活用した次世代PLMの可能性についても言及されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
PLMの現状における3つの主要課題：パフォーマンス、データフリクション、グローバルコラボレーション
私の名前はJustin Iravaniです。AWSプロフェッショナルサービスのシニアクラウドインフラストラクチャアーキテクトを務めております。本日は、PLMの現状における課題、モダナイゼーションに対する障壁の認識、そしてそれらの課題に対処するための原則についてお話しします。その後、JimとDanに引き継ぎまして、BoeingがどのようにしてAWS上でPLMオペレーションのモダナイゼーションを実現できたのか、そしてAWS上で数百の環境を運用するために何が必要なのかについてお話しします。
製品データとプロダクトライフサイクルマネジメントのユースケースに関して、お客様から提起される3つの主要な課題があります。1つ目はパフォーマンスとスケーラビリティです。3Dモデルの忠実度の向上、ビジネスインテリジェンス、メタデータやバリエーションの複雑さの増加といったことにより、製品データと分析ソリューションが拡大するにつれて、より困難になってきています。さらに、これらのソリューションやアプリケーションが地域、組織、機能に対して必要とするリーチは、より多くのデータ速度と距離を意味します。
これが2つ目の課題であるデータフリクションにつながります。データフリクションは、主にレガシーインフラストラクチャとアプリケーションに基づく歴史的なオンプレミスアーキテクチャと統合の産物となっています。これらの機能的なサイロは、セキュリティやアクセス制御といった理由で隔離された、対応するデータサイロも生み出しています。最初の2つの課題が大きな要因となり、企業が複数の地域にまたがり、世界中に広がるエンジニアリング活動に従事する中で、グローバルコラボレーションは引き続き課題となっています。さらに、企業が新しい技術やイノベーションに関する合併・買収やパートナーシップを加速し続けるにつれて、これらの接続はますます普及してきています。
モダナイゼーションへの障壁とPLMの3つのコアピラー：デジタルツイン、デジタルスレッド、デジタルファブリック
今日PLMに依存しているメーカーにとって、アップグレード、ましてやマイグレーションの見通しは非常に困難なものです。サービスの中断は最小限に抑えなければなりませんし、新しい実装は耐久性があり信頼性の高い方法で処理される必要があります。メーカーはまた、これらのシステムを使用するチームやエンジニアのトレーニングに多大な投資をしており、その知識を将来にわたって最大限に活用し続けたいと考えています。また、これらのPLMシステムの上に構築された複数のレイヤーのアプリケーションや、ERP、MES、SCMといった他の重要なシステムとの非常に緊密な統合も存在することが多いのです。
これらのレガシーシステムには大量のデータがありますが、設計の再利用には十分な機会がありますが、それを管理することはしばしば困難です。さらに、PLMに関わるマイグレーションプロジェクトは数ヶ月、場合によっては数年続くことが多く、非常に高額になることもあります。AWS上で実行されるPLMソリューションは、デジタルツイン、デジタルスレッド、そしていわゆるデジタルファブリックという、PLMの3つのコアピラーを考慮する必要があります。
AWSは、製品定義の様々な側面を表現する多様なデジタルツインの確立をお客様に支援しています。その中には3D製品表現のような分かりやすいものもありますが、製品がどのように動作すべきかという要件に関するデジタルツインも含まれます。PLMデジタルツインやエンジニアリングツインは、パートナーソリューションのホスティングに加えて、ストレージやデータベースサービスを使用してエンジニアリングデジタルツインを構築し、既存の様々なソリューションをサポートすることで確立されています。ちょっと興味深い余談ですが、Boeingはこのデジタルツイン分野のパイオニアの一つでした。2000年代初頭に、いわゆるバーチャル航空機プロジェクトから始まったもので、彼らは間違いなくこの道を進んで革新を続けています。
製品データとライフサイクル管理のスレッドは、様々なデータソース間の接続性を表しています。これらのスレッドは、意思決定のためのより豊富な情報セットを提供し、より効率的で効果的な結果を得るための全体的なプロセスを支援し、適切なコンテキストでリアルタイムに異なるデータソースとのやり取りを可能にします。製品データとライフサイクル管理の第三の柱は、いわゆるデジタルファブリックのエコシステムです。これは、開発データとデジタルツインの上に構築され、スレッドを通じた相互接続性を加え、ネットワーク全体からステークホルダーを追加します。今日のイノベーションを実現するために必要なスキルとリソースを活用し最大化するには、グローバルな接続性と可用性が重要です。
AWSのモダナイゼーションアプローチ：顧客重視、分解、自動化、スピード優先
R&Dはほとんどのメーカーの中核です。ますます複雑化する製品をより早く市場に投入するという市場からのプレッシャーにより、企業はペースを保ち新たな収益源を開拓するための新しい方法を模索しています。しかし、従来のR&Dインフラストラクチャと、そのインフラストラクチャ上に構築された複雑な統合は、既存の製品開発ワークストリームにかろうじて追いついている状況です。
このインフラストラクチャは柔軟性がなく、十分に活用されておらず、年単位のサイクルで管理される可能性があります。ますます多くのお客様が、アジャイルエンジニアリング、マルチディシプリナリー最適化、コンカレントエンジニアリング、スマート製品といった成果を実現するために、R&DITインフラストラクチャのモダナイゼーションとアプリケーションのモダナイゼーションに関するベストプラクティスを求めて、AWSとパートナーに注目しています。
モダナイゼーションに対するAWSのアプローチは、お客様がこれらの障壁を克服するのを支援できます。私たちのアプローチは、お客様に徹底的にこだわり、特定のお客様のニーズは何か、そして市場の他のお客様と協力することを理解することです。そして、これらの複雑な問題をより小さく管理しやすいコンポーネントに分解するために逆算して取り組みます。もちろん、アーキテクチャだけでなく運用の複雑さも考慮して、お客様に応じて適切にスケールするソリューションとアーキテクチャの構築に焦点を当てる必要もあります。例えば、セルフサービスのようなものを促進することです。CloudFormationやTerraformのような自動化ツールを活用することで、手動ミスの可能性を減らし、一貫性、信頼性、効率性、品質を確保できます。
最後に、私たちは完璧さよりもスピードと機敏性を優先しています。目標は、完璧なソリューションを持つことではなく、顧客価値を迅速かつ反復的に提供することです。これはしばしば、私たちのコントロールできる範囲内で何ができるかに焦点を当てることを意味します。あるいは、私がよく言うように、「これはいつでも後から複雑にできる」ということです。それでは、Jimに引き継ぎたいと思います。
BoeingにおけるPLMとThree D Experience：レガシーインフラの課題とAWS移行の決断
ありがとう、Justin。私の名前はJim Gallagherです。BoeingでのThree D Experienceのリードアーキテクトを務めています。まず、PLMとは何かについて少しお話ししましょう。PLMはProduct Lifecycle Managementの略です。業界の概念としては、製品のエンジニアリング、製造、サポートデータを管理するための、ゆりかごから墓場までのシステムです。これには、CAD、CAM、CAEシミュレーション、ツーリング、プランニング、変更管理、構成管理が含まれ、すべてのシステムについて、設計された状態、計画された状態、構築された状態、サポートされた状態というライフサイクルの各段階を表現します。機械構造、電気、油圧、HVAC、ツーリング、地上支援設備などです。
目標は、私たちが管理する各製品の、任意のライフサイクル状態におけるデジタルツインと、その状態の管理につながり、それを支えるすべてのデータと分析です。PLMシステムは、Boeingのすべての製品ラインで使用されています。Boeingにおける次世代PLMシステムは、Dassault SystemsのThree D Experienceです。Boeingは、Boeingの設計および製造プロセスを最適に実行するために、Three D Experienceの機能強化に投資しています。Three D Experienceは現在、数千人のユーザーを抱える数十の小規模プログラムで本番稼働しています。Three D Experienceは、次の新しい商用旅客機のPLMシステムとなる予定です。
Justinが冒頭で述べたように、レガシーなオンプレミスのインフラ管理には共通の課題がありました。インフラの容量は、年間予算と資本取得サイクルに基づいています。限られたリソースの管理にはプロセスが必要です。ホスティングパッケージの組み立て、リクエスト、レビュー、承認、却下、プロビジョニング。これらすべてに時間がかかり、プロジェクト間でリソースの競争が発生します。プロジェクトは、必要なときに必要なものを得られない可能性があります。サービスごとに異なるコストモデル。チャージバックモデルを開発し維持する必要があり、どのサービスをプロジェクトにチャージバックし、どのサービスを企業全体に均等に配分するかを決める必要があります。
多くの場合、引き継ぎや作業キューのために、承認からプロビジョニングまでに大きな遅延が発生します。手に入れた後も、レガシーなマネージドインフラには、プロジェクトと企業の両方にとって追加の欠点があります。プロジェクトは、再利用できる可能性があると考えた場合、リソースを返却しないという大きなインセンティブがあります。チャージバックモデルは、必ずしもインフラの実際のコストや比例したコストを反映していません。適切なサイズに調整することが難しいのです。
拡張するということは、多くの場合、リクエストの承認サイクルを意味します。縮小するということは、プロジェクトが後でそれを取り戻せない可能性があるということです。そこでPLMをAWSへ移行することにしました。
AWS移行の複雑さと成功への道筋：ProServeとの協力、優先順位の確立、段階的アプローチ
クラウドの機会。Boeingのリーダーシップは、AWSにおいて、アプリケーションチームがより速く動き、コストを削減できる機会を見出しました。 私たちはエンタープライズ内部クラウドを構築しました。エンタープライズはAWSと協力して、Boeing向けにAWS GovCloud内にネットワーク分離されたリージョンを作成しました。これはBoeingネットワーク上にあるように見えます。これによりアプリケーションアクセスとシステム統合が大幅に簡素化されました。
チームに権限を与える。AWSアカウントをオンにして、アーキテクトが設計し、運用チームが構築できるようにします。 しかし、なぜこんなに時間がかかっているのでしょうか？私たちのアプリは大規模で複雑なフットプリントを持っています。最初に思ったほど簡単ではありませんでした。
リホスティングして利益を得るには、分析、学習、反復的な実験のための時間が必要です。私たちはAWS ProServeとのエンゲージメントを確立し、PLMチームを支援し、ガイドしてもらいました。 知らない悪魔に注意してください。オンプレミスは遅く非効率でしたが、プロセスとパターンは よく知られていました。多くの分業と、ホストされたサービスがありました。
レガシーインフラストラクチャには OS管理サポート、サーバートラッキングとコンプライアンスのためのシステムインテグレーターサポート、バックアップ、ネットワーク接続ストレージ、ロードバランシング、OSのブロックポイントとパッチ適用が含まれていました。私たちの新しい責任、スキル、そしてAWSサービス。 私たちはそれらのことを自分たちで対処する必要がありました。これらのレガシーマネージドサービスの大部分は、AWSでは利用できませんでした。私たちのチームにはAWSの経験がありませんでした。
成功はDSOおよびAWS ProServeと緊密に連携することにかかっていました。DSOのインフラストラクチャアーキテクトやAWS ProServeと緊密に協力して、私たちの目標を最もよく達成するための新しいアーキテクチャパターンを確立する必要があることは明らかでした。Boeingが求めていたマイグレーションの成果は何だったのでしょうか？インフラストラクチャ運用の加速、プロビジョニングにかかる時間、廃止にかかる時間、アプリケーションのインストールとアップグレードにかかる時間です。
官僚主義の回避、承認やリクエストサイクルをなくすことです。AWSの習熟度。運用とアーキテクチャは、何ができるのか、何をすべきなのかを理解し、実行できる必要があります。依存関係の回避。すでに承認されている、または必要とされているものをプロビジョニングしたり、トラブルシューティングしたりするために、他のチームを待つ必要がないようにします。
コストの削減。エラスティックコンピュートの実現。ピークに合わせてプロビジョニングするのではなく、ベースラインに合わせてプロビジョニングします。使用されていないVMを監視してシャットダウンするためのプロセスとツールを実装します。ネットワークストレージは、プロビジョニングされた容量ではなく、消費量に応じて課金されます。Infrastructure as Codeによる構成管理の改善。サーバー間の差異を減らし、プロビジョニングを簡素化します。
次の2つの望ましい成果はAWSに特化したものではありませんでしたが、私たちはマイグレーションを強制的なイベントとして活用し、これらの追加的な成果を加速させました。フォロー・ザ・サン。AWSアカウントの分離を活用して、インドの同僚が輸出管理データを含まない環境をプロビジョニングおよび管理できるようにします。技術の刷新。AWSへのマイグレーションの一環として、OSの陳腐化に対処します。
オンプレミスでは、サポート終了となったRed Hat 7を実行していましたが、AWSで新たにプロビジョニングされたシステムはRed Hat 8になっています。最後に、Boeing 3D Experience PLMのリリースは、数百人が関わる大規模な取り組みです。私たちはリリーススケジュールに影響を与えることを避けたいと考えていました。
そこで私たちはAWS Professional Servicesと提携し、他の3D Experienceのお客様との経験と、AWSに関する深い専門知識を活用して、私たちが望む成果を実現することにしました。また、Dassault Systèmesとも協力しました。私たちはDassault Systèmesの同僚と継続的に協力していますが、このプロジェクトでは、標準の3D ExperienceアーキテクチャをAWSインフラストラクチャに最適にマッピングする方法について、いくつかの新しい優先事項を設定する必要がありました。
機能の優先順位を確立する必要がありました。私たちには、さまざまな機能について取り組むべき多くの実験的プロジェクトの長いリストがありました。infrastructure as code、ロードバランシング、データレプリケーション、ディザスタリカバリなどです。本番環境への道のりのさまざまなフェーズにおける優先順位と最小限の実用製品が決定されました。また、どのPLMリリースの一部としてどの環境を移行するかのスケジュールも確立する必要がありました。すべてを一度に移行しようとしてはいけません。
官僚主義の悪夢からの脱却：オンプレミスでのリソースリクエストの実態と課題
それでは、Dan Meyering氏にバトンタッチします。ありがとうございます、Jim。皆さん、こんにちは。私の名前はDanです。BoeingでPLMを担当するリードシステムインテグレーターです。まず、皆さんが大好きなトピック、もちろん官僚主義から始めさせていただきます。ドアはロックされているので、この時点では逃げられませんよ。だから真ん中に入れたんです。
まず状況を説明しますと、3D Experienceをサポートするためには、予測可能なスタックが必要です。 コンピュートホスト、データベース、ロードバランサー、ネットワーク接続ストレージ、ファイルシステム、DNSエイリアスなど、各環境ごとに必要です。重要なのは、リソースが割り当てられたら作業が終わるわけではないということです。パッチ適用、配信時の設定問題のトラブルシューティング、アクセス設定、コンプライアンスタスクなど、プロビジョニング後のステップはすべて不可欠です。私たちの目標は、誰もがそうであるように、常にアプリケーションを確実に実行できる再現可能なインフラストラクチャでした。
AWSを導入する前は、各コンポーネント、つまりVM、ネットワーク接続ストレージ、ファイルシステム、データベース、DNS、 これらすべてが別々のチームへのリクエストを必要としており、それらのチームはリソースのプロビジョニングだけでなく、継続的なサポートや多くの設定タスクも担当していました。このモデルは、多くの引き継ぎ、大量のメール、調整、電話、インスタントメッセージングを意味し、実際のサポートチームの好みに応じて異なっていました。書面上は、長い間うまく機能しており、構造化されているように見えました。しかし実際には、調整コストと 遅延は、特に振り返ってみると、かなり大きなものでした。
リクエストの提出は官僚的な悪夢でした。チームは特定のフォームとフォーマットを必要としていました。リクエストのミスは、潜在的に数週間の遅延を引き起こす可能性がありました。ここのスライドの右側の画像は、私のチームの内部指示書からの実際のスナップショットの例です。これらはすべて血と汗の結晶であり、すべて特定のリソースのリクエストが正しく提出され、遅延を最小限に抑えることを確実にするためのものでした。左下の長いものは、実際よりも短くなっています。そのままだと見た目が悪かったので、そこでカットしなければなりませんでした。これは、1つのリージョンで1つのネットグループにエクスポートするネットワーク接続ストレージファイルシステムの単一のリクエストです。通常、1つに2つほど入れることができましたが、それを超えると、何らかの理由で混乱する可能性が高くなります。
私たちは多くの時間を費やして、フォローアップし、要件を明確にし、一貫性のない結果に対応していました。その日々のオーバーヘッドは、明らかにエンジニアリングの時間をデリバリーから逸らし、フラストレーションと手戻りのサイクルを生み出しました。そのすべての手動モデルの頭痛に対する報酬は、一貫性のないインフラストラクチャでした：ワークロードに対してサイズが間違っているサーバー、間違ったリージョンでホストされているか、間違ったネットグループにエクスポートされているネットワーク接続ストレージファイルシステム、わずかに不適切に構成されたデータベース、そして特注の修正を必要とするシステムです。
これらの引き継ぎは運用リスクを増加させ、時には深夜の障害として表面化しました。例えば、データベースリスナーがメンテナンスウィンドウの後に自動的に起動するように完全には構成されていなかった場合などです。そして、真夜中に本番環境の電話を受けることになります。通常は本番環境ではありませんが、それでもダウンした環境をサポートするために電話を受けることになります。これらすべてが、変動性に対してヘッジするためにオーバープロビジョニングしなければならなかったため、反復や実験を行う能力を低下させました。そのような混乱を念頭に置いて、AWSに移行したときに何が起こったかを見ていきましょう。
AWSサービスによる変革：ALB、EC2、EFS、RDSがもたらした運用の劇的改善
さて、具体的な初期の勝利は、単一のApache HTTPホストをAmazonのApplication Load Balancerに置き換えたことでした。これは、ユーザーの視点から始めると、リンクにヒットしたときということになると思います。これにより、環境内にあった単一障害点を削除し、サービス全体でApacheの複雑なロードバランシング設定を維持する必要をなくすことができました。
例えば、ほとんどの場合、単一障害点とは、通常はマルチティア環境である環境全体のApacheを、環境内の単一のVM上でホストしており、そのホストは他のサービスとも共有していたということです。そのため、そのホストがダウンすると、他のサービスが正常であっても、アプリケーション全体へのアクセスが失われてしまいました。しかし、ALBは、コンソールで表示可能な集中型ヘルスチェック、EC2とAuto Scalingとの高可用性統合を提供し、3D Experienceが必要とするアプリケーションCookieとスティッキーセッション、特にAuto Scalingをサポートし、DNSとイングレスコントロールを簡素化します。
コンピュートについては、EC2 がAPI駆動の適切なサイズのインスタンスを提供してくれます。サービスごとにCPUとRAMのプロファイルを選択でき、Compute Optimizerなどを通じたAWSの推奨事項を使用して、実際にサイジングを調整することができます。さらに、EC2が構築される元となるカスタムAMIに前提条件を組み込み、特定のブートストラップにはインスタンスユーザーデータを使用することで、手動セットアップを削減し、インスタンスの準備時間を大幅に短縮しました。最後になりますが、EC2インスタンスのタグによって、オンプレミスでは持っていなかった様々なメタデータやディスカバリーも可能になりました。
AMIについて言及する価値のある追加の注意点があります。オンプレミスのインスタンスでは、プッシュ型のセキュリティパッチモデルを採用していたため、通常この強制的な待機期間がありました。つまり、ベースイメージが公開されて私たちがそれを使用するまでの時間が経過するにつれて、パッチサイクルから遠ざかるほど、インスタンスが実際に使用可能になるまでの時間が長くなり、時には最大3時間かかることもありました。これはASGにとって良くありません。実際、これによってオートスケーリングが事実上不可能になっていました。AMIはこの問題を完全に解消してくれました。
EC2と先ほど述べたスケーリング、オートスケーリングと同様に、ASG、つまりオートスケーリンググループによって、 サービスを自動的または手動でスケールインおよびスケールアウトできるようになりました。私たちのパターンでは、ユーザーデータスクリプトを使用し、すべてのホストにアタッチされているEFSからバイナリを取得します。起動用のbashスクリプトを実行し、サービスを起動し、時には少し調整やgrep処理を行い、そして起動するだけでシームレスに動作します。このアプローチは、アプリケーションメトリクスによって駆動されるスケーリングをサポートしています。CloudWatchは、Javaメトリクスまたはユーザーアカウントのいずれかでスケールイベントをトリガーでき、起動アーティファクトがEFSに保存されているため、DRリージョンにレプリケートされ、リカバリーメカニズムとしても機能します。
EFSといえば、これは私たちのレガシーなネットワークアタッチドストレージを置き換えてくれました。もう、あの長い リクエストフォームに記入する必要はありません。あれはいつも何かしら間違いが起きていました。API駆動で、自動的にスケールし、環境ごとのボリュームをサポートしているため、チームや環境が不足のために単一のファイルシステムを共有する必要がなくなり、容量ニーズを予測する必要もありません。つまり、必要になるかもしれないストレージに対して料金を支払う必要もないということです。ただ、通常それは問題ではありませんでした。私たちは大抵スペースを使い果たしていましたから。
オンプレミスでは、ネットワークアタッチドストレージのサイジングが限られていたため、これは常に頭痛の種でした。何らかの理由で、リクエストが2テラバイトを超えると、少し異なるリクエストプロセスになっていました。とにかく、これらすべてが積み重なって、ストレージをプロビジョニングするのに不合理な量のオーバーヘッドが発生していました。例えば、リクエストごとに、その目的は何か、どのリージョンに行くのか、どの環境か、どの権限か、そしてスペースが足りなくなったらどうするのか、といったことを繰り返し決定しなければなりませんでした。必然的にスペースが足りなくなったので、他の環境からスペースを奪わなければなりませんでした。しかし今では、EFSがこの頭痛の種を大幅に軽減してくれました。
ネットワークアタッチドストレージに関する懸念の影響範囲は縮小されました。蒸発して、消えてなくなりました。もう懸念はありませんし、以前行っていた反復的な意思決定もすべて取り除かれました。その上、リソースの競合も回避できていますし、不要なストレージに対して料金を支払うこともありません。
データベースについては、現在 RDSを使用しています。これは複数のアベイラビリティゾーンにわたる高可用性、自動バックアップ、ポイントインタイムリカバリ、リードレプリカ、スナップショット、何でも揃ったマネージドデータベースサービスを提供してくれます。
S3からOracleダンプファイルをインポートして、反復的なDBAの関与なしに新しいデータベースを準備することができます。DBAの時間がどれだけ節約されたかについては実際には測定していませんが、彼らとのやり取りは確実に大幅に減っているので、彼らは様々なことをする時間が確保できています。これまで依頼を送っていた様々なチームも同様です。彼らとのやり取りはほとんどなくなったので、間違いなく他の仕事に取り組んでいることでしょう。
Infrastructure as Codeの実現：Terraformによる一貫性、自動化、並行デプロイメント
では、新しいインフラストラクチャをまとめますと、プロビジョニングも削除も迅速に行えるリソースが手に入りました。各環境のインフラストラクチャは一貫性があり、特定のリソースニーズに合わせて適切なサイズになっており、EC2とRDSのタイプが実際のワークロードに合わせて調整されることでパフォーマンスベースになっていますし、スケーラブルで自動化可能でもあります。
では、これによって私たちの運用をどのように加速できたのでしょうか？まあ、明らかにAWSはAPIを通じてインフラストラクチャを公開していますし、Infrastructure as CodeはそれらのAPIを、すべてのドキュメントや手順書や手動ステップをTerraformコードベースに統合することで、明確に定義されたコードに変換します。すべてのEC2、EFS、データベース、DNS、ロードバランサー、その他の関連サービスにわたって一貫性を実現しました。メリットは、より高速なデプロイメント、信頼性の向上、一貫性、そして再現性です。
では、Infrastructure as Codeについて少し視野を広げてお話しします。私たちはTerraformを使っています。最初はCloudFormationから始めて、それも素晴らしかったんですが、企業全体がTerraformに移行していたので、彼らのモジュールを使いたいということで、Terraformを使っています。コードはGitLabに置いています。GitLab runnerがパイプラインを実行して変更予定をplanし、applyステージをトリガーする前に、承認ゲートとバリデーションを使って期待される結果を確保しています。このCI/CDアプローチによってピアレビューが強制されます。監査可能な変更履歴が作成され、あらゆる種類の手動プロビジョニングステップが自動化された反復可能なフローに置き換えられます。
もう少し詳しく見ていくと、結果を標準化するために、環境テンプレートを作成しました。 基本的にsmall、medium、largeのテンプレートがあり、それからmonolithicというのもあって、これは全てのサービスが基本的に1つのEC2上にホストされているもので、まあ基本的にはdeath boxですね。各環境テンプレートは、異なるベースラインのEC2サイジング、RDSクラス、LDAPブートストラップ設定、DNSエイリアス、ASG設定、ボリュームサイジング、ロードバランシング設定を定義しています。これらのテンプレートによって、オーバーヘッドが削減され、デプロイメントが意図したパフォーマンスとスケールプロファイルに確実に一致するようになりました。以前は調査しなければならなかったようなことです。オンプレミスでは標準化されたサイジングがありませんでした。その代わりに、以前は実質的に近い環境を見つけて、その近い環境に基づいてアーキテクチャをプロビジョニングしようとしていました。これは非常に手動で調査的なプロセスでした。その多くは、私たちが得るインフラストラクチャの一部の不整合の下流にあったようなものです。物を奪ったり、パッチを当てたりしなければなりませんでした。
では、もう少し視野を広げて、左上にsmallの例があります。 これが今お話ししていたテンプレートの一種です。これらの環境定義は、効果的な環境サイズのための最小限のパラメータセットを提供します。 そして、私たちのTerraform 3DX coreモジュールが、AWS内の全リソースの足場のようなものを形成し、例えばsmall環境の定義を反復処理して、その環境が必要とする微妙な設定を、必要な全てのリソースに対してデプロイします。そして環境のビルドレベルでは、スマートデフォルトを使用してcoreモジュールをソースし、反復的な手動入力を削除しながら、オーバーライドも可能にしています。例えば、本番環境で古いAMIを使って何か問題をテストする必要がある場合に、その古いAMIをピン留めして、それでdev boxを立ち上げるとか、あるいは環境のRoute 53 DNSエイリアスをオーバーライドする必要があるかもしれないとか、そういった小さなことです。
さて、全てのインフラストラクチャがコードで定義されるようになったので、以前見られたような順次的なボトルネックなしに、複数の環境を並行してデプロイできるようになりました。この能力によって、新しい環境を必要とするチームの待ち時間が劇的に短縮され、よりアジャイルな開発ケイデンスをサポートします。自動化だけでなく、この利点は過大評価できません。以前は、必要な手動作業と調整のために、opsチームの誰かが1つまたは少数の環境をデプロイするだけで、1日または1週間も手を取られていました。
そして、パイプラインとコードのモジュール性のおかげで、1つの環境でも 10の環境でも、あるいは概念的には数百の環境でも、わずか数時間で並行してデプロイできます。その上、その時間のほとんどは受動的なものなので、これらをデプロイしているopsチームの誰かは、ただそれが完了するのを見ているのではなく、他のもっと重要なタスクに取り組むことができます。
個人的な経験として、私は実際に限界に挑戦してみました。できるだけ大規模なマルチティア環境を構築しようとしたんですが、IPアドレスが枯渇してしまったので、規模を縮小せざるを得ませんでした。ただこれはTerraformやInfrastructure as Codeの問題ではなく、小規模なテストアカウントだったためにアカウントのIPアドレスが足りなくなったんです。それから、私たちや運用チームは、80台のdev boxを1時間程度で、しかも同時に簡単にデプロイしました。さて、それを踏まえて、最高レベルまでズームアウトしてみましょう。現在、下位レベルにAWS 3DX core Terraformコードベースがあります。
その中で、複数のAWSアカウントにまたがるPLMインフラストラクチャの関心事を分離するために、複数のリポジトリも持っています。AMIアカウントとAMIリポジトリがあり、ChefクックブックでAMIを生成して、AMIパイプラインに流し込みます。そのAMIは基本的にAWS用のAMIアカウントに投入されます。いくつかのテストと試験を経て、合格したら、他のアカウントと共有して、3DX coreインフラストラクチャの最新バージョンに固定します。もちろん3DX coreインフラストラクチャリポジトリもあります。PLM環境リポジトリもあります。実際、これがcoreインフラストラクチャです。環境ごとの定義のためのPLM環境リポジトリがあり、これがcoreを参照しています。そして前提条件リポジトリもあって、アカウント、IAMプロファイル、ロールなどを標準化しています。これはすべてのアカウントが持っているものです。基本的に一度やれば終わりで、学習しながら時々微調整する程度です。
それで、先ほども述べましたが、ズームアウトしていくと、これがパイプライン全体の広範なアーキテクチャです。エンタープライズ標準AMIが私たちのAMIパイプラインに供給されます。左下の隅にありますね。それが私たちのAMIパイプラインに読み込まれます。私たちのものは3D Experience用のものを重ねていて、それが基本的にAWS 3DX coreで参照されます。これは文字通りこの画像の中核にあります。これはまた、先ほど述べたすべてのリソースのためのTerraformのエンタープライズモジュールも参照していて、会社全体でIEC標準を維持するためのものです。
3D Experienceデプロイメントの進化：Ansibleによる構成管理とインストール時間60%削減の実現
さて、これまでずっとインフラストラクチャの話をしてきました。では3D Experienceのデプロイに移りましょう。そのために、構成管理としてAnsible構成管理を使用して3D Experienceをデプロイしています。ここにある画像は、実際に私たちの環境の1つの正規化されたインベントリドキュメントで、昔はこんな感じだったかもしれません。でも今は実際に、EC2などに付けるリソースタグによって駆動される動的インベントリを使っています。ホスト名などを手動でコピー&ペーストする必要はありません。これは明らかにあらゆる種類の問題を引き起こしていました。人間が関わるところには必ず問題が発生しますからね。
それ以外にも、余った時間で、インフラストラクチャの自動化や動的インベントリなどをかなり進めてきました。インフラストラクチャを手動で配線するための事務作業に労力を費やさなくなったので、すべてのAnsible playbookをロールにリファクタリングして、線形的なものをロールに変換し、インベントリさえも合理化することができました。今では私たちのインベントリはそれよりもさらに少なくなっていると思います。4行程度にまで減りました。これによってAnsibleスクリプトがよりシンプルになりました。デプロイメントはより信頼性が高くなり、アプリケーションデプロイメントをCI/CDにより緊密に統合できる位置に立てるようになりました。手動のタッチポイントも少なくなりました。実際、その動的インベントリファイルも今では動的に生成されるようになったので、人間の操作は1回だけです。
さて、まだデプロイメントに取り組んでいるところです。歴史的にオンプレミスで3D Experienceのデプロイメントパターンがどのようなものだったか見てみましょう。オンプレミスのリソースを節約するために、私たちは複数の3D Experienceサービスを単一のホストに割り当てていました。それによって、連続的で脆弱なインストールを強いられることになりました。
一度に一つのサービスしかホストにインストールできず、一つの問題のあるサービスが他のサービスに影響を与える可能性があり、実際によくそうなっていました。さらに、私たちのAnsible playbooksは多くのデプロイメントパターン、特殊なケース、そしてインフラリソースの変動性を考慮しなければならず、それによってメンテナンスがますます複雑になっていきました。
これらの状況により、環境間でデプロイメントに一貫性がなくなり、各環境がまるでテトリスのゲームのように感じられました。特に締め切りがあって、すぐに立ち上げて稼働させる必要がある場合はそうでした。ただピースを叩き込んでいって、一番上まで埋まる頃には、見逃した小さなブロックが全部見えて、「ああ、これは後で対処しよう」という感じでした。そして実際に対処していました、大抵は午前2時に。要するに、あるいは参考までに言うと、理想的な条件下でのアプリケーションの完全なデプロイメントは、単一の環境で約9.5時間かかっていました。それがオンプレミスでの話です。またやってしまいました。クリックしちゃいました。おっと、戻りますね。
しかし、今ではAWSで適切なサイズのホストと前提条件を組み込んだAMIを使用することで、各サービスを独自のホストにデプロイするようになりました。とても素晴らしいことです。そしてインストールを並列で実行しています。事前に準備されたAMIと並列デプロイメントパターンにより、インストール時間が60%以上短縮されました。約3.5時間まで短縮され、これは単にオンプレミスからAWSに移行したことで開かれた可能性でした。アプリケーションのデプロイメント自体が変わったわけではありません。そして、その総合的な結果は明らかに、より速く、より予測可能なデプロイメントと、よりシンプルな自動化です。私たちのplaybooksは、これらのアドホックな構成を処理するための多くの特殊なケースや、ある環境から別の環境へインフラを奪うようなことを考慮する必要がなくなりました。
しかし、AWSへの移行は課題がなかったわけではありません。もちろん、クラウドサービス全体にわたって学習曲線が生じました。Jimが言及したように、私たちはAWS、Terraformなどについて本当に経験がありませんでした。ですから、Terraform、GitOps、CI/CD、システム管理、データベース管理、コンプライアンス、これらはすべて以前は他のチームが担当していた役割でしたが、今では私たちの責任となっています。ですから、それを引き受けなければなりませんでした。私が学んだのは、それがsteep learning curveではなく、shallow learning curveだということです。私はいつもsteep learning curveと言っていましたが、少し時間がかかりました。
私たちが遭遇した大きなリスク、もう一つの課題は、pipelinesを使ったinfrastructure as codeについて学んでいた時に、いわゆるblast radiusというものがありました。これは何度も出てきました。最初は単一のメインのTerraformファイルに複数の環境を追加していました。しかし、そのコレクションの中の一つの環境を変更したい時に、Terraformは同じコミット内の他の環境についてもplanとstate fileを検証する必要があったんです。これは私たちが望んでいたことではありませんでした。そこで環境を分離して、それぞれ独自のbranchと小さなcommitに分割し始めました。
もう一つの課題は、Terraformは、まあどんなコードもそうだと思いますが、コード化したことを正確に実行するということです。つまり、適切なガードレールがなければ、重要なリソースが誤って破壊される可能性があるんです。だからこそ、Terraform planに承認ゲートを追加しました。皮肉なことに、オンプレミスでは、それらすべてのリソースを作成するハードルが、同時にそれらを誤って破壊することに対する防壁にもなっていたんです。でも、私たちは多くのことを学びました。
最後の課題は、ASG、auto scaling groupsの微妙な点でした。これは痛い目に遭って学びました。replacement processがsuspendされていない状態で、そのASG内のEC2を停止すると、おっと、ASGは設定された通りに正確に動作して、そのEC2を破壊してしまうんです。その機能は私たちがまだ準備できていなかったものでした。そこに到達する意図でデプロイはしていたんですけどね。教訓として、実際に有効にする準備ができていない特定のauto scalingプロセスはsuspendしておくべきだということを学びました。
そして、3D Experience自体がAWS上にあることによる、いわゆるbleeding edgeな頭痛の種もありました。オンプレミスではauto scalingができなかったので、3DX自体のためにcookieを特別な方法で設定する必要がなかったんです。しかし今は、application load balancer、ALBのcookie persistenceを調整して、3DXサービスのscale out動作をサポートする必要がありました。そしてdatabaseの慣行も調整する必要がありました。なぜなら、RDSはより細かい権限を強制するからです。オンプレミスで使っていたgrant allの代わりにですね。ちょっとワイルドウェストな感じでしたが、RDSはそれを許可しません。それをしないことがベストプラクティスであり、RDSはベストプラクティスに従うことを確実にしてくれます。そしてもちろん、これらすべての修正と学んだ教訓は、今ではDS 3DXのknowledge baseに文書化されています。DSはそういったものを本当に素早く入れてくれるので、他のお客様が同じ問題に遭遇しなくて済むようになっています。
測定可能な成果と未来への展望：手動タスク78%削減、環境構築99%改善、チームの変革
そしてもちろん、すべての課題には、そのコインの裏側として新しい機会があります。私たちはすでに多くのメリットを見ており、進化を続けています。3D Space Indexのようなコンポーネントのメトリクスを収集しています。これは基本的にすべての検索データをインデックス化するもので、人々が何かを入力すると結果が表示されるようになります。indexing timeとdatabaseのサイジングの間のトレードオフを洗練させるために微調整を行っており、EC2などでますます細かい最適化を可能にしています。
さらに、私たちのチームは自らのスキルセットを大幅に広げることができました。官僚主義の束縛から解放されたことで、これが実現したのです。私たちの時間は今や、反復的なタスクではなく、クリエイティブなタスクにより多く費やされるようになりました。さらに、運用面では、CI/CDパイプラインを通じてAnsible playbookを実行する方向に進んでおり、デプロイメントのパフォーマンスをさらに向上させるためにpullモデルを試してみる予定です。ディザスタリカバリについては、機会のリストを順に見ていくと、リカバリリージョンのread replicaに対してより小さなRDSクラスを評価しています。なぜなら、このreplicaは実際にはユーザートラフィックを処理していないため、どのリージョンにあろうとも、大ボスであるprimaryインスタンスに追いつくだけでよいからです。
また、開発とテストのサイクルを効率化し加速させるために、開発者がCI/CDパイプラインまたはダッシュボードから、ビルド、デプロイ、テスト、破棄というワークフローをトリガーできるようにする取り組みを進めています。同様に、私たちのチーム自身のためにも、ビルド、デプロイ、テスト、破棄のワークフローに取り組んでいます。これにより、playbookは常に失敗するまでテストされ、修正され、そしてすべての開発者が利用できるようにマージバックされます。さて、では私がこれまでお話ししてきたすべての結果はどうなったのでしょうか？こちらに棒グラフがいくつかありますが、これらは常に楽しいものですね。
すべての影響は、多くの点で測定可能であり、また測定不可能でもあります。手動タスクとタッチポイント、左側の棒グラフですが、単一環境における手動タスクとタッチポイントは78%減少しました。数週間前は75%でしたが、今は78%です。これは大きな数字で、エラーや属人的な知識の機会を減らしています。完全な環境構築についても、右側の棒グラフですが、あの巨大なタワーと下部の小さな切れ端を比較すると、インフラストラクチャのプロビジョニング、設定、アプリケーションのインストールが、今では最大30日かかっていたものが約5時間で完了します。これは単一環境で99%の改善です。
これを潜在的に数百の環境にスケールアウトすると、全体像が見えてきます。これらはすべて、人々が他の単調で反復的なタスクに行き詰まっていた時間でした。そのすべての可能性が解放されたのです。さらに、その78%に残っている数少ない手動タスク、残りの22%ですが、これらははるかにシンプルになりました。私たちは今や、単一のビルドに数日や数週間を費やす代わりに、潜在的に数百の環境を並行してデプロイできるようになりました。引き継ぎが少なくなることで、エラーが減り、価値実現までの時間が大幅に短縮されます。
いくつかのメリットについては、メトリクスを収集するのがより困難ですが、経験的に言えば、私たちは書類作業の泥沼に多くの時間を費やし、残りの時間は火消しやサポートチケットの対応に追われていた運用チームから、今では消えゆくほど少ないサポートチケット、少なくとも過去18ヶ月間の私の記憶では午前2時の火消しもなく、時間の大半を環境のデプロイやツールの開発、新しいサービスや戦略の実験に費やすようになりました。つまり、AWSには多数のサービスがありますが、私たちはまだ表面をかすった程度にすぎません。私たちの時間の大半は、今ではより価値のある形で使われています。率直に言って、私たちは2年前とはまったく異なるチームになりました。
これはロードマップと将来の話につながるんですが、いくつかの夢物語的なものが、この新たに生まれた余裕時間によって今実際に進行中になっています。私たちはダイナミックインベントリを実装し、playbookをroleにリファクタリングしています。現在の作業ストリームには、先ほど述べたようにAnsibleのpullベースの設定モデルへの移行、開発者が環境を自己プロビジョニングできるようにAnsibleをCI/CDに統合すること、Auto Scaling Groupのメトリクスの最適化、そして環境内のEC2とRDSクラスを変化させることによるデプロイメントの最適化が含まれています。これはたとえばデプロイメントのパフォーマンスに使えます。何かを素早くデプロイしたいだけなら、すべてのリソースをスケールアップして、デプロイして、その山を越えて、触媒として機能させて、それからユーザーに期待するベースラインに合わせてサイジングをダウンレギュレートするだけです。
サービスは需要に応じて自分自身をスケールアウトでき、できればデータ損失なしでAMIローテーションを可能にします。すべてのサービスがAuto Scaling Groupsでホストできるわけではなく、そうでなければAMIのローテーションが簡素化されたはずなんですが。これらの取り組みは、開発者とユーザーの体験を自己完結型またはセルフサービスで、かつレジリエントなものにすることに焦点を当てています。次のステップには、サポート負荷の改善を定量化することと、セルフサービスの拡大を継続することが含まれます。
私のパートの終わりに近づいてきましたが、follow the sunオペレーティングモデルをサポートするために、私たちは個別のアカウントとIAM境界を確立し、チームが必要な権限を持ちながら露出を制限できるようにしました。これにより、分散したチームが24時間体制で作業し、インシデントにより迅速に対応できるようになります。同様に重要なのは、開発環境が今や安価で使い捨て可能になったことです。開発者は溜め込む代わりに再構築できます。シャットダウン、起動、再起動ができ、使用していないときはコストを節約できます。このような変更により、サポートコールや深夜の呼び出しが減り、開発者の速度が向上します。
全体として、私たちはインフラストラクチャと開発環境の両方について、完全なcattle, not petsのオペレーショナルモデルに近づいています。個人的な話ですが、プロフェッショナルサービスチームがいなければ、私たちはここにいなかったでしょう。彼らが参加してくれました。Aaron Brown、Justin Iravani、彼とはこのステージを共有する特権を得ていますが、彼らがやってきて、私たちの哀れな魂を死の谷を通って導いてくれました。彼らなしでどうなっていたか想像もつきません。間違いなくもっと高コストで、もっと混乱していて、実際に今あるような高品質ではなかったでしょうし、どんどん良くなり続けています。ここで終わりにします。Jimに戻します。お時間をいただきありがとうございました。
ビジネス成果の実現とPLMの未来：コスト削減40%超、生成AIによる次世代PLMプラットフォームへ
さて。PLMオペレーションのコスト管理です。AWSサービスへの移行により、正確な使用量ベースのコストを得ることができました。今では使った分だけ支払います。コンピュート、ネットワーク、ストレージ、キャパシティではなく消費量で課金されます。運用費用については、資本予算サイクルから抜け出しました。もはや年次でインフラストラクチャを購入するのではなく、代わりにインフラストラクチャの月次請求書を受け取ります。使用していないときはインフラストラクチャを停止します。使っていなければ、ただオフにするだけで、それが同時にコストも停止させます。
チームはまた、EC2 APIを活用して、開発者がAWSの権限なしにVMを起動・停止できるセルフサービスのウェブページを開発しました。インフラストラクチャの適正サイズ化です。様々なEC2インスタンスのサイジングがあるおかげで、各アプリケーションサービスに適したEC2サイズと、環境サイズに適した数量をプロビジョニングできるようになりました。もはやピーク時に合わせてプロビジョニングするのではなく、ベースラインに合わせてプロビジョニングし、Danが話したオートスケーリングを通じてピーク時に備えるようにしています。
インフラストラクチャを手放すことができます。使っていないものを廃止するのは非常に簡単で、ただ終了させるだけです。もし再び必要になっても心配する必要はありません。なぜなら、プロビジョニングする力があるからです。最新のインフラストラクチャです。最新のEC2とRDSタイプにアップデートしていますが、これらは通常古いものより安価です。新しいタイプが利用可能になったら、シャットダウンして、タイプを変更して、再起動するだけです。
改善のための時間です。Danが話した重いプロセスから脱却し、継続的改善のためのより多くの時間を確保できるようになりました。結局のところ、実際のコスト削減は環境タイプによって異なります。すべてのサービスが1つのホスト上にあるモノリシックな開発者サンドボックスサーバーは、オンプレミスとAWSでほぼ同じコストです。これはBoeingのチャージバックモデルを考慮に入れた上でのことです。しかし、ディザスタリカバリが有効な本番環境は、適正サイズ化とオートスケーリングのおかげで、半分以下のコストになっています。
環境に関連するサーバーが多ければ多いほど、AWSへの移行でより多くのコスト削減を実現できました。では次に、これらすべての新しいテクノロジーが可能にする実際のビジネス成果についてお話しします。オペレーションの加速です。改訂と廃止にかかる時間が大幅に改善されました。官僚主義の回避です。必要なリクエストと承認が90%削減されました。一部のリクエストはまだ必要で、主にネットワーキング、サブネットのプロビジョニング、ルーティング、情報セキュリティ、マネージドファイアウォールに関するものです。
AWSの習熟度です。私たちのオペレーションチームは、AWSでインフラストラクチャを運用し自動化するスキルを習得するという素晴らしい仕事をしてくれました。Follow the sunです。ここで箇条書きの順序が少し入れ替わっていますね。これについては後で戻ってきます。依存関係の回避です。すでに承認されている、または必要なものをプロビジョニングするために他のチームを待つ必要がありません。それでも、ネットワーキングやファイアウォールなど、他のチームが担当する領域のトラブルシューティングについては、いくつかの依存関係が存在しています。
コスト削減です。私たちは大幅な節約を実現しました。 Infrastructure as Codeによる構成管理の改善。Danが説明したように、私たちはInfrastructure as Codeに完全に投資し、その恩恵を受けています。次の2つの成果はAWSに特化したものではありませんでしたが、移行を強制的なイベントとして活用しました。Follow the sunです。私たちはPLM運用のためのfollow the sunを成功裏に実現しました。
Tech insertionです。 OSとCPUの陳腐化、両方とも実現しました。そして最後に、リリーススケジュールの維持です。早い段階で、PLMのリリース日がAWS移行活動の基準となることを確立しました。私たちはPLMスケジュールに対応するのであって、その逆ではありません。この原則を維持してきましたが、これは私たちにとってうまく機能しています。それでは、Justinに戻します。
素晴らしいですね。ありがとう、Jim。それでは、いくつかの重要なポイントについてお話ししましょう。今お聞きになったように、AWSサービスを活用し、AWS ProServeと提携し、AWSの働き方を使用することで、BoeingのPLMチームは実行速度を大幅に向上させ、運用の柔軟性を高め、より多くのことを行う時間を得ることができました。アプリケーションのデプロイ時間をエンドツーエンドで99%以上削減できたと聞きましたが、これは本当に素晴らしい成果です。
一貫した環境を得ることができたので、開発者は明らかにその一貫性を気に入っています。自動化されたInfrastructure as Codeのおかげで、部族的な知識を削減することができ、新しいチームメンバーが最初のコミットを行うまでの時間は基本的に1日以内です。これらの環境をデプロイできるようになります。また、DBAチーム、ストレージチームなどの間でのチーム間の引き継ぎもなくなりました。
リソースを適切なサイズにすることで、インスタンスの起動と停止、適切なサイズ設定ができるようになりました。全体的なインフラストラクチャコストを40%以上削減することができました。皆さんのCFOもきっと喜ぶでしょうね。最新のコンピューティングとネットワーキングのAWSサービスを活用することで、3DExperience実装は、説明されたように、確実にキビキビと動作するようになり、さらに一貫性も大幅に向上しました。全体的なパフォーマンスの面では、開発者が環境に入って使用するのがはるかに安定したものになっています。
Boeingはまた、災害復旧のためのリージョン間での簡単なデータレプリケーションやオートスケーリングといったAWSサービスを有効にすることで、新しい機能を獲得しました。ある賢人が私に言ったことがあるんですが、それは3DExperienceアプリケーションにとって聖杯だと。さて、ここまでBoeingにとって近代化がいかに実際のビジネス成果につながったかについてお話ししてきましたので、次はPLMの未来がどのようなものになるかについてお話ししましょう。
PLMシステムというのは、高品質な製品を作ることが目的です。チームが細かい作業や多くのタスクに追われるのではなく、問題解決に集中することに時間を費やせば費やすほど、より良い結果が得られます。
ここで本当に重要になってくるのが、生成AIとエージェント型AIです。これらの最先端ツールを使うことで、PLMに自然言語で質問するといったことができるようになります。例えば、パーツAは何の素材でできているのか？なぜパーツBは6ミリメートルではなく5ミリメートルなのか？パーツCの承認されたサプライヤーは誰か？PLMにこうした質問ができることは、開発者にとって多くのメリットをもたらします。
さらに、エージェント型AIを日々のワークフローに統合することで、例えば公開ワークフローにエージェントを配置して互換性のない材料をチェックし、手戻りを削減するといったことができます。加えて、リアルタイムでの部品表分析を行い、リアルタイムで変更の推奨事項を提供することもできます。また、自然言語での運用アクティビティも可能です。例えば、新しいベンダーを登録する際に、重厚なプロセスを経る代わりに、Slackで「ねえ、PLM、このユーザーをこのサービスに追加して」と言うだけでいいんです。
AWS内のあるデバイスチームが、AWS BedrockやAmazon Qといったサービスを活用したAI搭載PLMプラットフォームのパイロットを実施しています。初期のフィードバックは非常に、非常に有望です。サステナビリティサイエンティストから製品設計エンジニアまで、さまざまな役割の方々からのフィードバックとして、生成型PLMプラットフォームによって、物を探すのに必要な時間が削減され、知識の発見が本当に効率化されることで、イノベーションが可能になり、それが膨大な時間の節約につながっているということです。
反復的な情報収集タスクを自動化することでワークフローを加速させます。つまり、毎日小さなエージェントを設定して、皆さんに代わって情報を集約することができるのです。これにより、チームは生産性や、先ほどお話ししたイノベーションや問題解決といった、より価値の高い活動に集中できるようになり、生産性の向上につながります。また、組織の知識に基づいた関連性のある文脈情報を提供することで、意思決定を強化し、ビジネスの目標や優先事項に沿った、より情報に基づいた意思決定を実現します。
さらに、チーム間で知識をよりアクセスしやすく、発見しやすくすることで、コラボレーションを改善します。明らかに、この情報の流れが実現することは非常に重要です。これにより、知識共有の文化が育まれ、継続的な学習と成功の成果が促進されます。AIサービスが向上するにつれて、この種のツールはより影響力を持つようになりますが、私たちはまだ始まったばかりです。
ですので、もしAWSでPLMの未来を探求することに興味がおありでしたら、ぜひアカウントチームにご連絡ください。本日はお越しいただきありがとうございました。本日ここで私たちの旅を皆さんにご紹介できたことを光栄に思います。そして、皆さんと一緒に未来を探求していくことを楽しみにしています。本当にありがとうございました。そして、セッションアンケートへのご記入をお忘れなく。そうすれば、DanとJimが来年また招待されて、彼らが何をしたのか見ることができますからね。それでは、皆さんありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion