※本記事は、AWS re:Invent 2024のセッション「Iveco Group and AWS: A story of continuous innovation (PRO202)」の内容を基に作成されています。セッションでは、Iveco GroupがAWSを活用して仮想エンジニアリング、知識管理、生成AI駆動の自動化においてイノベーション、コラボレーション、デジタルトランスフォーメーションを推進する方法が紹介されています。セッションの詳細情報は https://www.youtube.com/watch?v=XIbwLTne2Zk でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。AWS関連のイベントについては https://go.aws/3kss9CP をご参照ください。
1. イントロダクション
1.1. セッション概要と登壇者紹介
Alessandro Ricci：皆さん、ようこそ。ご参加いただきありがとうございます。本日はIveco GroupとAWSプロフェッショナルサービスが進めてきた旅についてご紹介できることを大変嬉しく思います。私はAlessandro Ricciと申します。AWSプロフェッショナルサービスのシニアエンゲージメントマネージャーで、今日は私のスーパーチームの同僚たちと一緒にステージを共有しています。
本セッションではIveco GroupがAWSプロフェッショナルサービスと協力して内部プロセスを改善するために実施している具体的な取り組みを紹介します。今日ご紹介するユースケースをなぜ選んだのか、その理由を確認いただける機会となります。また、これらのユースケースがどのように実現されたのかを詳しく掘り下げ、皆さんのビジネスに適用できるかどうかを理解するための着想を得ていただきたいと思います。
ただ、すべてのユースケースに入る前に、まずIveco Groupがどのような企業であるかの概要と、プロフェッショナルサービスがこの旅をどのようにサポートしているかをご説明します。プレゼンテーションの最後には、Ivecoの未来ビジョンをご紹介する機会も設けています。セッション終了後は、ステージ近くに残って皆さんからのご質問にお答えする時間も用意しています。
それでは、Iveco Groupから来ていただいたPierfrancesco Rizzoさんをご紹介します。彼から会社のビジョンと背景をお話しいただきます。
Pierfrancesco Rizzo：Alessandro、ありがとうございます。皆さん、こんにちは。今日ここに立ち、私の会社を代表できることを大変嬉しく思います。このような機会を与えてくださったAWSにも感謝申し上げます。
1.2. アジェンダ説明
Alessandro Ricci：では、本日のセッションのアジェンダに直接入りましょう。Iveco GroupがAWSプロフェッショナルサービスと協力して内部プロセスを改善するための具体的な事例を通じて、今日ご紹介するユースケースを選んだ理由を確認いただける機会を提供したいと思います。また、それらのユースケースをどのように実現したかを詳しく掘り下げ、皆さんのビジネスに適用できるかどうかを理解するための着想を得ていただきたいと考えています。
しかし、すべてのユースケースに入る前に、Iveco Groupがどのような企業であるかの概要と、プロフェッショナルサービスがこの旅をどのようにサポートしているかをご説明します。プレゼンテーションの最後には、Ivecoの将来ビジョンを紹介する機会も設け、セッション終了後はステージ近くに残って皆さんからのご質問にお答えする時間も用意しています。
本日のセッションでは、内部プロセスとIvecoの従業員にフォーカスした3つの異なる事例を紹介します。これらの事例は一見すると異なる領域に属しているように見えますが、共通のパターンを持っています。私たちは、ドライバーやフリートマネージャーなどのエンドユーザーに価値を提供することに集中できるよう、Iveco従業員の業務をサポートする内部プロセスに着目しました。AIと実ハードウェアの仮想化により、繰り返し作業や効果の低いタスクの量を削減することができるのです。
2. Iveco Groupの企業紹介
2.1. 会社の歴史と事業概要
Pierfrancesco Rizzo：私はPierfrancesco Rizzoと申します。Iveco GroupのArtificial Intelligence Labを率いています。Ivecoは1970年代に誕生した会社で、Fiatホールディングの下で統合された5つの産業OEMブランドの合併によって生まれました。CNHからのスピンオフ後、Iveco Groupは2022年に独立しました。
当社はトリノを拠点とし、ミラノ証券取引所に上場しています。Ivecoは貨物と乗客の輸送向けのソリューションを設計・製造しており、エンジンも製造しています。世界中で36,000人以上の従業員を抱えています。また、イタリアの道路では、約40%の商用車、つまり3台に1台がバンやユーロカーゴ、S-Way車両などの商用車となっています。
2.2. 市場でのポジションと実績データ（接続車両数、年間売上など）
Pierfrancesco Rizzo：当社のブランドであるIveco Busについては、イタリアで44%以上の市場シェアを持つリーダー企業となっています。そして2024年には1,000台以上の電気自動車を販売しており、Iveco Busは都市部のCO2排出削減において重要な役割を果たしています。
接続性に関しては、現在14万台以上の接続車両があり、1テラバイト以上のデータを生成しています。今後数年間でこの数字は増加し、今の10年の終わりまでには50万台の車両に達すると予想しています。Iveco Groupは2023年に年間売上高160億ユーロ以上で締めくくりました。
ただ、私の過去の経験についても少しお話しさせてください。私は過去20年間自動車分野で働いてきましたが、特に過去5年間は前例のない驚異的な変化のペースを目の当たりにしてきました。これは非線形性の時代です。気候変動、新しい規制、排出規制、車両カスタマイズの複雑さ、そして私たちが直面している極端なイノベーションによる非線形性です。
例えば、過去10〜15年間、ディーゼルエンジン、つまり内燃機関が私たちの車両を動かすための主要な技術でした。しかし、直面している課題や変化により、現在トリノや世界中の工場では、電動化や水素、燃料電池など、代替推進システムを開発しています。もちろん、課題はこれらの不確実性を機会に変えることです。
2.3. 現代の自動車産業が直面する「非線形性」の時代
Pierfrancesco Rizzo：私が自動車分野で過去20年間働いてきた経験から申し上げると、特に過去5年間は前例のない驚異的な変化のペースを目の当たりにしてきました。これこそが「非線形性の時代」なのです。なぜ非線形性かというと、気候変動、新たな規制要件、排出ガス規制、車両カスタマイズの複雑さ、そして私たちが直面している極端なイノベーションのスピードによるものです。
具体例をお話しすると、過去10〜15年間、ディーゼルエンジン、つまり内燃機関が私たちの車両を動かすための主要技術でした。しかし今、私たちが直面している課題や変化により、現在トリノや世界中の工場では、電動化や水素、燃料電池など、代替推進システムを開発しています。
こうした変化の中で私たちの挑戦は、これらの不確実性を機会に変えることです。Iveco Groupのイノベーションロードマップは3つの主要な柱に基づいています。第一は持続可能性、第二は人工知能とソフトウェア定義車両、そして第三が自動運転です。第一の持続可能性については、2040年までにCO2排出量ゼロという重要な目標達成を目指しています。人工知能に関しては、これらの新技術を活用して、AIベースの製品をより多く生産に投入し、ソフトウェア定義車両によって顧客のユーザー体験を劇的に変えていきます。最後に自動運転については、レベル2+技術に取り組んでおり、今後数年以内にこれらの車両を生産に投入する予定です。
3. Iveco Groupのイノベーションロードマップ
3.1. 3つの主要な柱：持続可能性、AI/ソフトウェア定義車両、自動運転
Pierfrancesco Rizzo：Iveco Groupのイノベーションロードマップは3つの主要な柱に基づいています。第一の柱は持続可能性、第二の柱は人工知能とソフトウェア定義車両、そして第三の柱が自動運転です。
持続可能性に関しては、2040年までにCO2排出量ゼロという重要な目標達成を目指しています。これは環境への責任を持つメーカーとして、私たちが設定した明確なターゲットです。
人工知能については、これらの新技術を活用して、より多くのAIベースの製品を生産に投入していきます。また、ソフトウェア定義車両の開発も進めており、これによって顧客のユーザー体験を劇的に変革していく予定です。ソフトウェアがハードウェアよりも主導的な役割を担う時代に入っています。
最後に自動運転については、レベル2+技術に取り組んでおり、今後数年以内にこれらの車両を生産に投入する予定です。自律走行技術は商用車両においても重要な革新となり、今後の輸送産業に大きな影響を与えるでしょう。
これらの柱は、現在の事業環境におけるメガトレンドに対応するために私たちが選んだ戦略的方向性です。顧客のニーズに焦点を当てながら、これらのトレンドに応える形でビジネスを展開しています。
3.2. 2040年までにCO2排出量ゼロを目指す取り組み
Pierfrancesco Rizzo：持続可能性に関して、私たちは2040年までにCO2排出量ゼロを達成するという重要な目標を掲げています。この目標は単なる理想ではなく、具体的な行動計画に基づいたコミットメントです。
すでに電気自動車の分野では大きな進展を見せており、2024年には1,000台以上の電気自動車を販売しました。これによりIveco Busは都市部のCO2排出削減において重要な役割を果たしています。都市交通の電動化は、大気汚染の軽減に直接的な効果をもたらしており、地域社会から高い評価を得ています。
また、従来のディーゼルエンジンから脱却し、代替推進システムへの移行を加速させています。トリノの本社や世界中の工場では、電動化技術だけでなく、水素燃料電池など多様なクリーンエネルギー技術の開発に注力しています。
この目標達成には技術開発だけでなく、サプライチェーン全体での取り組みやビジネスモデルの変革も必要です。私たちは製品のライフサイクル全体を通じて環境負荷を削減するアプローチを取っており、素材選択から生産プロセス、使用段階、そして廃棄に至るまでの各ステップで持続可能性を考慮しています。
2040年という目標は挑戦的ですが、業界のリーダーとして、気候変動対策に積極的に貢献することが私たちの責任だと考えています。
3.3. クラウドをイノベーションの重要な基盤として位置付け
Pierfrancesco Rizzo：今日の事業を変革しているメガトレンドに対応するため、私たちは顧客に焦点を当てています。これらの主要なイネーブラーの一つであるクラウドに目を向けてみましょう。Ivecoはクラウドに多大な投資をしています。なぜなら、私たちはクラウドが最も革新的で、オープンで、スケーラブルなソリューションであり、私たちのビジネスと製品をサポートできると考えているからです。
このスライドでは、私たちの会社に特有の最も重要なメガトレンドのいくつかを見ることができます。しかし、今夜皆さんと共有したいのは、私たちにとって最も重要な二つの柱、すなわちAIベースのサービスと自動運転についてです。
クラウドは単なるITインフラではなく、私たちのイノベーション戦略の中核を担っています。クラウドの柔軟性と拡張性により、大量のデータ処理、AIモデルのトレーニング、そして今後増加していく50万台の接続車両からのテラバイト級データの管理が可能になります。また、新しいデジタルサービスの迅速な展開や、グローバルな規模でのビジネス展開もクラウドによって実現しています。
私たちのデジタルジャーニーにおいて、AWSがどのようにIveco Groupをサポートしてきたかについては、ここでAlessandroに説明を引き継ぎたいと思います。
4. AWS ProServesとIveco Groupの連携アプローチ
4.1. ワーキングバック手法による問題・機会の特定プロセス
Alessandro Ricci：Pierfrancescoに感謝します。数年前に協力を始めた当初、AWSはAWSアプローチに基づく処方的ガイダンスを提案しました。スライドで示すように、私たちは常にワーキングバック手法から始めて、問題または機会を特定していきます。これは顧客であるIvecoと一緒に合意していくプロセスです。
この最初のステップは非常に重要です。これが決定的な段階なのです。何を達成したいのか、そしてビジネス成果は何かを特定することは、私たちが後続のすべてのステップを進める上での道標となります。ワーキングモデルに合意したら、通常はミニマル・バイアブル・プロダクト（MVP）の実現を通じて、そこにたどり着く方法を定義します。
すでに具体的な結果が出ていれば、それをIvecoの主要なステークホルダーに提示して、次のステップである産業化に進むための賛同を得ます。産業化は、ProServeだけでなく、さまざまなIvecoのビジネスユニットやパートナーによってもサポートされます。
どのように達成するかというと、私たちが常に考慮する重要なメッセージがあります。2023年に実現された特定の再生成AIの概念実証のうち、わずか10%だけが今年生産化されたという、年初に発表されたGartnerのレポートを引用させてください。ですから、産業化へと進むためのガバナンスメカニズムを適切に定義することが非常に重要なのです。
そしてこれこそが、私たちがIvecoと共に採用したフレームワーク、スケールアジャイルアプローチが機能する場所です。実験をスケールするには、強固な組織体制が必要です。このアプローチを通じて、私たちはポートフォリオバックログと呼ばれるものを基盤レベルで定義します。これは基本的に、すべての主要な戦略的イニシアチブを透明な方法で含むリポジトリであり、Ivecoのような企業内のすべてのビジネスユニットやサプライヤーにとっての単一の真実源として機能します。
4.2. スケールアジャイルフレームワークの採用
Alessandro Ricci：実験をスケールさせるには、強固な組織体制が必要です。スケールアジャイルアプローチを通じて、私たちは基盤レベルでポートフォリオバックログを定義しています。これは基本的に、すべての主要な戦略的イニシアチブを透明な方法で含むリポジトリであり、Ivecoのような企業内のすべてのビジネスユニットやサプライヤーにとっての単一の真実源として機能しています。
この方法では、MVPの概念を強化しています。「小さく始め、大きく考える」アプローチから、エンドユーザー（社内外問わず）にとっての価値を常に提供することを念頭に置き、最終結果を達成するためのロードマップも準備します。
このアプローチにより、年間を通じて反復的に「プログラムインクリメント」を通じてバックログの優先順位付け方法を見直し、年内に発生する可能性のある変更にも対応できます。例えば、ビジネスの変化への適応、予算への対応、その他の制約条件、さらには学習して内部プロセスを変更するといったことも可能です。
つまり、実行中に課題が生じても調整できるのです。これは直感的なプロセスであり、過去に学んだことを「アンラーン」する必要があるという事実を認める謙虚さが非常に重要です。これは簡単なことではなく、当然のことでもありません。なぜなら、私たちは基本的に白紙の状態から始めるわけではないからです。
このアプローチを念頭に置いて、私たちは社内のプロセスに働きかけ、様々なビジネスユニットを巻き込んでいます。これは、ProServeが技術面だけでなくプロセス面でも活動できることを示す一例です。
4.3. ポートフォリオバックログによる透明性の確保と優先順位付け
Alessandro Ricci：ポートフォリオバックログは、すべての戦略的イニシアチブを透明な方法で含むリポジトリとして機能しています。これはIvecoのような企業内のすべてのビジネスユニットやサプライヤーにとっての単一の真実源となります。この方法ではミニマル・バイアブル・プロダクト（MVP）の概念も強化しています。「小さく始め、大きく考える」アプローチから、私たちは常にエンドユーザー（社内外問わず）にとっての価値を提供することを念頭に置いています。そして最終結果を達成するためのロードマップも準備しています。
このアプローチにより、年間を通じて反復的にプログラムインクリメントを通じてバックログの優先順位付け方法を見直すことができます。これにより、年内に発生する可能性のある変更にも対応できるようになります。例えば、ビジネスの変化への適応、予算や他の制約条件への対応、さらには学習して内部プロセスを変更するといったことも可能です。
実行中に課題が生じても調整できる柔軟性がこのアプローチの強みです。これは直感的なプロセスですが、過去に学んだことを「アンラーン」する必要があるという事実を認める謙虚さが非常に重要です。これは簡単なことではなく、当然のことでもありません。なぜなら基本的に私たちは白紙の状態から始めるわけではないからです。
このようなポートフォリオバックログによる透明性の確保と優先順位付けのアプローチを念頭に置き、社内のプロセスに働きかけ、様々なビジネスユニットを巻き込んでいます。これはProServeが技術面だけでなく、プロセス面でも活動できることを示す重要な事例です。
これから本日のセッションでより詳細を説明していきますが、今日は一見すると異なる領域に属しているように見える三つの異なる例を紹介します。しかし、これらは共通のパターンを持っています。私たちは内部プロセスとIvecoの従業員に焦点を当てることで、ドライバーやフリートマネージャーなどのエンドユーザーに価値を提供することに集中できるようにしています。AIと実ハードウェアの仮想化により、繰り返し作業や効果の低いタスクの量を削減することができるのです。
5. Virtual Engineering Workbench（VEW）の開発
5.1. 従来の自動車ソフトウェア開発における課題
5.1.1. 開発環境の一貫性の欠如
Pierfrancesco Rizzo：本日は自動車ソフトウェア開発とクラウドベースのソリューションに焦点を当てたいと思います。さらに、自動車ソフトウェア開発の複雑さを最小限に抑えるためのアジャイルアプローチの適用についても話したいと思います。
私たちの従業員が直面している主な問題の一つが、開発環境の一貫性の欠如です。これは非常に深刻な課題で、開発者それぞれが異なる環境設定で作業しているため、コードの動作が環境によって異なり、問題の特定や修正が困難になっています。ある開発者の環境では完璧に動作するコードが、別の環境では全く異なる挙動を示すことがあります。
これは単なる不便さではなく、開発プロセス全体に影響を及ぼす構造的な問題です。環境の不一致により、バグの再現が難しくなり、チーム間のコラボレーションにも支障をきたします。また、新しい開発者がプロジェクトに参加する際の障壁も高くなります。彼らは自分の環境を正確に構築するのに時間を費やし、その間は生産的な開発作業に集中できません。
この問題は私たちの組織にとって特に重要です。なぜなら自動車ソフトウェアは複数のサブシステムが複雑に絡み合い、様々なハードウェアと相互作用するためです。環境の一貫性がなければ、品質保証、テスト、そして最終的にはお客様に安全で信頼性の高い製品を届けることが困難になります。
5.1.2. 環境構築の遅さと複雑さ（6〜8週間の準備期間）
Pierfrancesco Rizzo：開発環境の一貫性の欠如に加えて、私たちは環境構築プロセスの遅さと複雑さという大きな課題に直面していました。環境構築には通常6〜8週間もの時間がかかっていたのです。これは極めて長い準備期間であり、プロジェクトの開始やチームの拡張に大きな遅延をもたらしていました。
新しい開発者が入社したり、新しいプロジェクトを開始したりする際、実際の開発作業に取り掛かるまでに2ヶ月近くを要することもありました。この期間中、貴重な人的リソースが環境セットアップという事務的な作業に縛られ、実際の製品開発や価値創造に集中できない状況でした。
この遅さは単に設定に時間がかかるという問題だけではありません。設定プロセス自体が非常に複雑で、多くの手動操作が必要とされていました。各種ツールのインストール、構成の最適化、依存関係の解決など、多くのステップでエラーが発生しやすく、それが更なる遅延を引き起こしていました。
このような状況では、迅速な市場投入やアジャイルな開発プロセスの実現が困難でした。私たちのビジネスが直面している「非線形性の時代」に適応するためには、この環境構築の遅さと複雑さを解決することが不可欠だったのです。
5.1.3. 長いフィードバックループとハードウェア依存性
Pierfrancesco Rizzo：もう一つの重大な課題は、長いフィードバックループでした。開発環境からフィードバックを受け取るまでに数週間から数ヶ月も待たなければならないことがありました。これはソフトウェア開発において致命的な遅延で、迅速な改善サイクルや問題の早期発見を阻害していました。
また、当社の従業員は50以上ものツールを扱う必要があり、それぞれにライセンスやハードウェアの問題が付随していました。これが極端にソフトウェア開発のスピードを低下させる要因となっていました。開発者は実際のコーディングよりも、ツールの設定やライセンス問題の解決に多くの時間を費やすことになります。
最後に、ハードウェアへの依存性も大きな課題でした。多くの場合、物理的なハードウェアの調達や設定が開発プロセスの開始を遅らせていました。特に特殊なハードウェアが必要な場合、その調達に時間がかかり、さらに開発開始を遅らせていました。ハードウェアの故障やメンテナンスの問題も開発速度を低下させる要因でした。
これらの課題が複合的に作用し、私たちのソフトウェア開発能力を大きく制限していたのです。次にAlessandroから、AWS ProServeがIvecoのために提供したソリューションについて説明してもらいましょう。
5.2. VEWのアーキテクチャと機能
5.2.1. 主要ユーザー（開発者、テスター、統合者など）向けの設計
Alessandro Ricci：それでは、AWS ProServeがIveco用に提案したソリューションをご紹介します。これはVirtual Engineering Workbench、略してVEWと呼ばれるものです。スライドの中央に示されているこのソリューションは、異なるビジネスユニット間の作業方法を民主化する役割を果たしています。
まずはこのソリューションのエンドユーザーについてお話ししましょう。左側から始めると、まずソフトウェア開発者がいます。彼らはコードやモデル、Ivecoが実現しているソフトウェアの基礎となるすべての技術スタックを作成する人たちです。彼らは品質チームと連携し、ソフトウェアリリースを検証します。また、製品・プロジェクトマネージャーやその関連チームとも連携して、優先順位やソフトウェアリリースサイクルなどを定義します。
スライドの右側に移ると、ソフトウェア統合者に特別な言及が必要です。これはソリューションの基盤となる方法であり、ソリューションが様々なユースケースでスケールし、特定のソフトウェアベンダーに縛られないようにします。この場合、Ivecoは現在でも将来でも、特定のニーズや特定のユースケースに応じてサードパーティツールを適応させることができます。
最後にテスターですが、彼らも重要です。彼らは基本的にあらゆるリリースに関わり、統合から品質テスト、負荷・パフォーマンステストまで、様々な段階に関与します。これらはほんの一例です。このように、VEWは開発プロセスに関わるすべての主要ユーザーを考慮した設計になっています。
5.2.2. セキュリティ設計とライフサイクル管理
Alessandro Ricci：このソリューションのセキュリティについて少し時間を割きたいと思います。セキュリティは常に最優先事項です。特に、企業内の人々の働き方を再編成するようなソリューションでは特に重要です。
このソリューションは、環境プロビジョニングのライフサイクル全体を管理していることを忘れないでください。エコシステムとの統合だけでなく、ソリューションの下で実行されているすべての環境のリリースも管理しています。先ほど見てきたように、多くのユーザーペルソナが関わっていますが、これはプロファイルに応じて、ソリューションが認証と認可のレイヤーを持ち、特定のタイプの機能のみを有効にすることを意味します。
すべてが一貫した方法で管理され、パッチ適用や更新に応じて進化できるようにスケーラブルであるべきです。Virtual Engineering Workbenchは、一貫性と拡張性を備えたセキュリティフレームワークを提供することで、これらの要件を満たしています。
セキュリティ設計の基本原則は、最小特権の原則に基づいています。つまり、各ユーザーは自分の役割を果たすために必要な最小限のアクセス権限のみを持つということです。これにより、システム全体のセキュリティリスクが大幅に軽減されます。また、すべてのアクションは監査可能であり、誰が何をいつ行ったかを追跡することができます。
このような包括的なセキュリティアプローチにより、Ivecoは安全かつ効率的な方法で開発プロセスを管理することができるのです。
5.2.3. 3つの基盤：ツール、ターゲット（ハードウェアの仮想化）、AWS基盤
Alessandro Ricci：Virtual Engineering Workbenchは3つの主要な柱に基づいています。第一の柱はツールです。これは、エンドユーザーが自分のユースケースを実現するために配置されているすべてのイネーブラーと考えてください。
真の中核となるのは、二番目の柱であるターゲットです。冒頭で述べたように、主な課題の一つは実際のハードウェアの入手可能性でした。そのため、Virtual Engineering Workbenchの主な目標は、実際のハードウェアの機能を同等に仮想化することです。ユースケースの成熟度に応じて、ほぼ100%の機能同等性を達成することができます。
そして、すべては3番目の柱であるAWSインフラの上に構築されており、マルチテナント環境でグローバルにサポートされています。
Virtual Engineering Workbenchは具体的には何なのでしょうか？これはクラウドベースのネイティブなサーバーレスウェブアプリケーションで、エンドユーザーが接続して仮想ターゲットをデプロイすることを可能にします。バックエンドがミドルレイヤーとして機能するマルチティアアプリケーションで、事前定義されたツールを通じてCI/CDパイプラインによる安全な方法で、Ivecoのすべての主要なシステムと統合します。
スライドでは、開発者、テスター、統合者などのユーザーペルソナがソリューションによってどのようにサービスを受けるかの例を示しています。彼らは基本的にシングルサインオンを通じてこのウェブクライアントに接続し、事前定義および構成済みのユースケースがすでに利用可能なAWSポートフォリオとして機能します。彼らはシステムと安全に対話することができます。
ユーザーは毎回セキュリティや繰り返しのタスクに集中する必要はなく、すべてのセキュリティ関連の設定はすでに組み込まれています。このソリューションは、例えばログイン用の既存のランディングゾーンとID連携に統合されています。
5.3. VEWの実装詳細とデモ
5.3.1. クラウドネイティブなサーバーレスWebアプリケーションとしての構築
Alessandro Ricci：Virtual Engineering WorkbenchはAWS上に構築されたクラウドネイティブなサーバーレスWebアプリケーションです。エンドユーザーがシームレスに接続し、仮想ターゲットをデプロイできるよう設計されています。このアプリケーションはマルチティア構造を採用しており、バックエンドがミドルレイヤーとして機能し、Ivecoのすべての主要システムと安全に統合します。
CI/CDパイプラインを通じて事前定義されたツールとの統合も実現しています。これにより、開発者やテスターはシステムとの安全な対話が可能になります。シングルサインオンを通じてWebクライアントに接続すると、事前定義および構成済みのユースケースが揃ったAWSポートフォリオにアクセスできます。
重要なのは、ユーザーが毎回セキュリティや繰り返しのタスクに集中する必要がないという点です。すべてのセキュリティ関連の設定は既に組み込まれています。例えば、ログイン用の既存のランディングゾーンやIDフェデレーションとも統合されています。
このクラウドネイティブアプローチの大きな利点は、インフラストラクチャの管理や保守の負担からチームを解放し、実際の開発作業に集中できることです。また、需要に応じてシームレスにスケールアップできる柔軟性も備えています。アプリケーションのすべてのコンポーネントはAWSのベストプラクティスに従って設計されており、高可用性、耐障害性、セキュリティを確保しています。
サーバーレスアーキテクチャを採用することで、使用していないリソースに対して料金を支払う必要がなくなり、コスト効率も向上しています。これはIvecoのような大規模組織にとって重要な要素です。
5.3.2. デジタルコックピット開発の仮想化（Feature Parity Level 1）
Alessandro Ricci：では、最初のMVPでVirtual Engineering Workbenchで実現した最初のユースケースを説明していきましょう。これはFeature Parity Level 1と呼ばれるものに関連しています。具体的には、デジタルコックピットについてです。
この高レベルなアーキテクチャ図では、一番下に実際のハードウェアで何が起きているかを示しています。車両に搭載されたインフォテインメントシステムとインストルメントがあり、それらはARMプロセッサーとインプロバイザー上で動作しており、そこでオペレーティングシステムと車両アプリケーションが実行されています。すべてはAndroid Autoオペレーティングシステムを示しています。
ここでAWSクラウドの仮想化された「緑色の部分」へのマッピングを見ることができます。すべてはVPC内で実行され、ユーザーが日常的に使用するツールを提供するEC2インスタンスのクラスターがあります。この問題は実際には2023年から既に解決されています。
CPU側では、すべてが仮想IOを通じて管理されています。一方、ユーザーインターフェースのレンダリングにはWebRTCプロトコルが使用されています。しかし、私たちはここで止まるつもりはありません。これは単なる最初のステップです。私たちはさらにスケールしたいと考えています。
例えば、Feature Parity Level 1+2に進む場合、ADASやハイパースケールコンピューティングに精通している方なら、CPU側はすでに利用可能です。ハードウェアに関していくつかの考慮が必要ですが、Outpostや類似のツールを通じて達成できます。Ivecoが既に実験しているLevel 2+以上に進む場合、技術は非常に速く進化しています。次の2年間でARM CPUがCorium対応で進化し、Graviton 3および4が進化すると予想しています。このre:Inventで見られるように、非常に速く進化しているので、将来的にはFeature Parity Level 2+もサポートできると期待しています。
それでは、Virtual Engineering Workbenchがどのように動作するかを示す事前録画されたデモをご覧ください。この種の管理者ユーザーが利用できるすべてのメニューの概要を示すために、スーパーユーザーとして接続しています。事前定義されたワークベンチが利用可能で、Ivecoで実現したすべての仮想ターゲットが含まれています。メニューをスクロールすると、管理タスクも表示されます。
5.3.3. 将来拡張計画（Feature Parity Level 1+、2+）
Alessandro Ricci：私たちの最初のステップはFeature Parity Level 1の実現でしたが、ここで止まるつもりはありません。今後の拡張計画について説明します。
Feature Parity Level 1+2に進む場合、ADASやハイパースケールコンピューティングに精通している方なら、CPU側はすでに対応可能であることがお分かりいただけるでしょう。ハードウェアに関していくつかの考慮点はありますが、AWS Outpostや類似のツールを通じて実現可能です。
さらに先を見ると、Ivecoが既に実験しているLevel 2+以上への進化も視野に入れています。技術の進化は非常に速く、私たちの予測では、次の2年間でARM CPUがCorium対応で大きく進化し、Graviton 3および4も急速に発展するでしょう。このre:Inventでも見られるように、これらのテクノロジーは非常に速いペースで進化しており、近い将来Feature Parity Level 2+もサポートできるようになると期待しています。
これらの拡張計画は、自動運転技術やより複雑なソフトウェア定義機能の開発をサポートするために不可欠です。技術の進化に合わせてVirtual Engineering Workbenchも進化させることで、Ivecoは常に最先端の開発環境を維持できます。
Virtual Engineering Workbenchのデモでは、開発者の視点から、Android Studioなどのツールを直接起動し、AWS基盤の上で実行できることを確認しました。テスターや開発者はコードを書き、テストし、デバッグし、最終ターゲットであるAndroid Autoオペレーティングシステムにインストールすることができます。またワークベンチから最終オペレーティングシステムシミュレータを開くためのデバッグも実行できます。
同様に、QNXハイパーバイザに関連する第二のユースケースも実現し、車両アプリケーションのインストール、実行、デバッグが可能になっています。ここで、このソリューションの成果についてPierfrancescoに説明を引き継ぎたいと思います。
6. VEWの導入による成果
6.1. 開発者のランプアップ時間95%削減
Pierfrancesco Rizzo：このソリューションは生産性と効率性に影響を与える重要なビジネス成果をもたらしています。効率性の観点では、開発者のランプアップに必要な時間を95%削減できることを確信しています。
これは極めて重要な成果です。従来のシステムでは、新しい開発者が環境を構築し、生産的な開発作業を始めるまでに6〜8週間かかっていました。Virtual Engineering Workbenchを使用することで、この時間を数日程度に短縮できるようになりました。つまり、新しいチームメンバーがプロジェクトに加わった際、ほぼ即座に価値を生み出す作業に取り組めるようになったのです。
この効率化は単に時間の短縮だけでなく、開発者のフラストレーション軽減にも寄与しています。環境構築の複雑さやトラブルシューティングに悩まされることなく、彼らの本来の専門性を発揮する仕事に集中できるようになりました。また、標準化された環境により、「自分の環境では動くのに他の環境では動かない」という問題も大幅に減少しています。
新規採用の開発者にとっては特に大きなメリットがあります。彼らは長い準備期間を経ることなく、すぐにチームの一員として貢献を始めることができます。これにより、オンボーディングプロセス全体の効率が向上し、チーム全体の生産性にも好影響を与えています。
6.2. ソフトウェア開発チームの効率30%向上
Pierfrancesco Rizzo：開発者のランプアップ時間削減に加えて、私たちはソフトウェア開発チームの効率を30%向上させることができました。この数字は単なる予測ではなく、実際の測定結果に基づいています。
この効率向上は様々な要因によるものです。まず、開発者が環境の構築やメンテナンスに費やす時間が大幅に削減されました。以前は複雑な環境設定の問題のトラブルシューティングに多くの時間を費やしていましたが、今ではその時間を実際のコーディングや問題解決、機能開発に充てることができるようになりました。
さらに、チーム全体が統一された環境で作業することで、コラボレーションが大幅に向上しました。コードの共有がスムーズになり、あるチームメンバーの環境で機能するものが、他のメンバーの環境でも同様に機能するようになりました。これにより統合の問題が減少し、開発サイクル全体が加速しています。
フィードバックループも大幅に短縮されました。以前は変更の結果を確認するまでに数週間かかることもありましたが、現在ではほぼリアルタイムでフィードバックを得ることができます。これにより反復的な開発が可能になり、品質向上とバグの早期発見につながっています。
この30%の効率向上は、より迅速な製品開発、市場投入時間の短縮、そして最終的には顧客満足度の向上に直結しています。
6.3. 統制された環境による開発プロセスの改善
Pierfrancesco Rizzo：環境のプロビジョニングに関しても大きな改善が見られます。環境がより統制されるようになり、開発者が環境のセットアップに気を配る必要がなくなったため、ソフトウェア開発に集中できるようになりました。
以前は、各開発者が自分の環境を構築し、必要なツールやフレームワークをインストールし、適切に設定する必要がありました。このプロセスは時間がかかるだけでなく、エラーが発生しやすく、環境間の微妙な違いがバグやテスト結果の不一致を引き起こしていました。
Virtual Engineering Workbenchを導入したことで、すべての開発環境が中央で管理され、標準化されるようになりました。開発者はボタン一つで事前構成された環境にアクセスでき、すべての必要なツールと設定が既に整っています。これにより、開発者は「環境の問題」に悩まされることなく、実際の価値を生み出すコード開発に集中できるようになりました。
また、標準化された環境は品質管理にも大きく貢献しています。すべての開発者とテスターが同じ条件で作業しているため、テスト結果の一貫性が格段に向上しました。「私の環境では動作する」という言い訳は過去のものとなり、問題が発見されればすべての環境で再現可能となったため、デバッグと解決が迅速になりました。
さらに、新しいツールや更新のロールアウトも一元管理されるようになり、すべての開発者が常に最新の状態で作業できるようになりました。これはセキュリティと機能の両面で重要な進歩です。
6.4. セキュリティプロセスの一元化
Pierfrancesco Rizzo：安全性に関しても、このケースでは環境が全員にとって同じになり、各従業員がIveco Groupのセキュリティプロセスを個別に管理する必要がなくなりました。
従来のシステムでは、個々の開発者がそれぞれのマシンでセキュリティ対策を実装する必要がありました。これは一貫性のない対応をもたらし、時にはセキュリティの抜け穴を生み出す原因となっていました。また、セキュリティ更新やパッチの適用も各開発者の責任となり、適用の遅れや見落としが発生することもありました。
Virtual Engineering Workbenchでは、セキュリティプロセスが完全に一元化されました。すべてのセキュリティポリシー、アクセス制御、暗号化、脆弱性管理が中央で管理され、すべての環境に一貫して適用されています。これにより、セキュリティ標準の遵守が保証され、潜在的な脆弱性のリスクが大幅に低減されました。
また、セキュリティイベントへの対応も迅速になりました。セキュリティの問題が特定された場合、すべての環境に対して一度に修正を適用できるため、対応時間が短縮されています。これは特に、重大な脆弱性が発見された場合に極めて重要です。
このセキュリティプロセスの一元化により、開発者はセキュリティの専門家である必要がなくなり、各自の専門分野に集中できるようになりました。同時に、組織全体のセキュリティ態勢が強化され、より安全な製品開発が可能になりました。
ではここで、Alessandro、ジェネレーティブAIベースのソリューションについて紹介したいと思います。その前に、Virtual Engineering Workbenchから、知識管理や技術図面といった私たちのGen AIベースのソリューションに話題を移す必要があります。Iveco Groupでは2023年半ばにGen AIの適用を始め、知識管理に関するPOCに取り組み始めました。
現在、1年間の集中的かつエキサイティングな取り組みを経て、AWS ProServeのサポートもあり、どこまで来たかをお見せします。ここでは2つのユースケースを紹介します。最初のケースは既に予告した通り知識管理について、そして二つ目は技術図面に関するものです。
7. ジェネレーティブAIソリューション：Smart Knowledge Management（ISKM）
7.1. 10万件の技術文書における情報検索の課題
Pierfrancesco Rizzo：まず最初のユースケースであるSmart Knowledge Managementについてお話ししましょう。Iveco Groupには10万件の文書があり、その情報は単純なOpenSearchでは簡単に取得できません。そのため、Gen AIの力を技術的なイネーブラーとして活用するアイデアが生まれました。
当社のすべての文書は技術文書であるため、自然言語で文書から取得した情報を検索できるツールを持つだけでなく、回答が十分な信頼性レベルを持っていることを確認したいと考えました。この課題は非常に重要です。なぜなら、技術文書には正確さが求められるからです。誤った情報や不正確な解釈は、製品開発や意思決定に悪影響を及ぼす可能性があります。
また、文書の量と複雑さも大きな課題でした。10万件もの文書には膨大な量の情報が含まれており、その中から関連する情報を迅速に見つけ出すことは従来の検索方法では困難でした。特に技術文書は専門用語や略語が多用され、コンテキストの理解が求められるため、単純なキーワード検索では不十分でした。
さらに、文書間の関連性を理解し、情報を統合する能力も必要でした。関連する情報が複数の文書に分散している場合、それらを結びつけて包括的な回答を提供することは従来のシステムでは難しい課題でした。
こうした課題に対応するため、Gen AIの能力を活用した新しいアプローチが必要だったのです。
7.2. プロジェクト目標と主要課題
7.2.1. 情報の信頼性80%以上の目標設定
Pierfrancesco Rizzo：すべての技術文書から情報を自然言語で取得できるGen AIベースのツールを構築するという目標に取り組む中で、私たちはいくつかの明確なエンジニアリング目標を設定しました。信頼性に関して、私たちは80%という目標を設定しました。
この信頼性目標は非常に重要です。なぜなら、技術文書に基づいた情報は高い精度が求められるからです。エンジニアや技術者が意思決定や製品開発のためにこのシステムを使用することを想定していますので、提供される情報が正確でなければなりません。80%という目標は、実用的なレベルでありながら、現実的な達成可能性も考慮したものです。
信頼性を測定するために、技術専門家による回答の評価、既知の事実との照合、文書ソースへのトレーサビリティなど、さまざまな評価方法を設定しました。また、システムが「わからない」と答える能力も重要視しました。不確かな情報について誤った回答をするよりも、知識の限界を認めることが信頼性の観点からは好ましいからです。
この信頼性目標を達成するためには、単に最新のAIモデルを導入するだけでなく、当社の技術領域に特化した調整やトレーニングが必要でした。また、情報源となる文書の質と構造も重要な要素となりました。信頼性は単なる技術的な問題ではなく、データ品質とAIモデルの適切な組み合わせによって実現されるものだからです。
7.2.2. 情報検索時間90%削減の目標
Pierfrancesco Rizzo：信頼性に加えて、私たちは情報検索時間を90%削減するという野心的な目標も設定しました。これは決して簡単な目標ではありませんが、従来のシステムでの情報検索の非効率性を考えると、大幅な改善の余地があると確信していました。
従来の方法では、エンジニアや技術者が必要な情報を見つけるために、複数の文書を手動で検索し、関連する部分を読み、情報を統合する必要がありました。これは非常に時間のかかるプロセスで、一つの質問に答えるために数時間、時には数日を要することもありました。
90%の時間削減とは、例えば1時間かかっていた検索作業が6分で完了することを意味します。この大幅な効率化により、技術スタッフは情報収集よりも、その情報を活用した意思決定や問題解決に多くの時間を費やすことができるようになります。
この目標を達成するためには、単に高速な検索エンジンを実装するだけでなく、自然言語の質問を正確に理解し、関連する文書から適切な情報を抽出し、それを理解しやすい形で提示する能力が必要でした。また、ユーザーインターフェースの使いやすさも重要な要素となりました。いくら処理が速くても、システムの使い方が複雑では効率化の効果は限定的になるからです。
この目標は単なる時間の節約ではなく、組織全体の生産性向上に直結する重要な指標として設定されました。
7.2.3. データ組織化の課題
Pierfrancesco Rizzo：私たちが取り組まなければならなかった主な課題は、データベース内のデータの組織化が不十分だったことです。そのため、より良い方法でデータを整理する取り組みも同時に開始しました。
このデータ組織化の問題は、ジェネレーティブAIソリューションを構築する上で予想以上に大きな障壁となりました。10万件もの技術文書が存在するものの、それらは統一された形式や構造を持たず、さまざまなフォーマット、命名規則、保存場所に散在していました。これにより、AIがデータを効果的に処理し、関連情報を取得することが困難になっていました。
具体的な課題として、まず文書の分類体系が不明確であったことが挙げられます。同じ種類の情報が異なるカテゴリーに保存されていたり、逆に異なる種類の情報が同じカテゴリーに混在していたりする状況でした。また、文書間の関連性や依存関係を示すメタデータも不足していました。
さらに、文書の更新履歴や最新性を示す情報が適切に管理されておらず、古い情報と最新情報の区別が難しい状況もありました。これは特に技術文書において重要な問題です。なぜなら、古い仕様や手順に基づいて作業を行うことで、製品品質や安全性に影響を及ぼす可能性があるからです。
このような状況に対応するため、私たちはデータガバナンスの取り組みを強化し、文書の分類、メタデータの標準化、命名規則の統一などを進めました。これは単にAIプロジェクトのためだけでなく、組織全体のデータ管理の改善にもつながる重要な取り組みでした。
それでは、Marco、AWSが準備したソリューションについて紹介をお願いします。
7.3. 技術的アプローチ：RAG（Retrieval Augmented Generation）の採用
Marco Guerriero：ありがとうございます、Pierfrancesco。こんにちは、皆さん。私はMarco Guerrieroと申します。AWSプロフェッショナルサービスのシニアマネージャーで、フランスや南ヨーロッパにまたがる開発者チームとともにデータとジェネレーティブAIに取り組んでいます。
Pierfrancescoがプロジェクトの背景を説明してくれたように、Iveco Groupは膨大な量の技術文書へのアクセスを改善するためにジェネレーティブAIを活用しようとしています。この例からわかるように、基盤モデルだけに依存していては、この特定のタスクを達成することはできません。
例えば、ISKMにIveco Groupの電子制御ユニットに関する具体的な質問をすると、ソリューションは特定の質問に答えることができません。これは単純に、基盤モデル単体ではIveco Groupの特定の知識ベースに根ざしていないからです。ここでRAG（Retrieval Augmented Generation）が役立ちます。
RAGについては過去2年間で多くの場で見てきたと思いますので、このスライドについては簡単にご説明します。今日は特にPOCから本番環境への移行に不可欠だった重要な要素に焦点を当てたいと思います。
簡単に言うと、RAGは大規模言語モデルとリアルタイム情報検索を組み合わせる方法です。このリトリーバル（検索）モジュールが事前処理されたIveco Groupのプライベートデータから関連情報を検索することで、Iveco Groupの特定の知識ベースに結びついた情報に基づいた回答を提供することが可能になります。
先ほどと同じ質問をRAGを備えたISKMに尋ねると、以前は非常に曖昧で一般的だった回答が、今回はIveco Groupの知識ベースにしっかりと根ざしたものになっていることがわかります。
このアプローチにより、従来のシステムでは数時間かかっていた検索が数秒で完了し、エンジニアの生産性が大幅に向上しました。また、情報の正確性と信頼性も向上し、Pierfrancescoが述べた80%以上の信頼性目標を達成することができました。
RAGの実装においては、ドキュメントの前処理、適切なベクトルデータベースの選択、関連性スコアリングの最適化など、多くの技術的課題に取り組みました。また、検索結果と生成された回答の品質を継続的に評価・改善するためのフィードバックループも構築しました。
8. ISKMの実装における4つの重要要素
8.1. パフォーマンス最適化
Marco Guerriero：それでは、Iveco Groupが安全で信頼性が高く、効率的なソリューションを構築し、ビジネス目標を達成してIveco Group全体の効率を向上させるために不可欠だった4つの重要な要素に移りましょう。
まずはパフォーマンス最適化レイヤーから始めます。このレイヤーでは、ISKMが必要な情報への迅速かつ効率的なアクセスを提供することを確保しています。具体的には、正確性、応答時間、データ取得、そして全体的なユーザー体験を最適化しています。
パフォーマンス最適化は単なる速度の問題ではありません。それは、システムが提供する情報の品質と関連性を確保することでもあります。私たちは、検索アルゴリズムを微調整し、関連文書の検索精度を向上させるために多くの努力を払いました。これには、文書のインデックス作成方法の最適化、ベクトル埋め込みの質の向上、そして検索パラメータの調整が含まれます。
また、応答時間の最適化も重要な焦点でした。ユーザーがクエリを入力してから答えを受け取るまでの時間を最小限に抑えるために、システムのさまざまなコンポーネントを調整しました。特に、大規模な文書コーパスを検索する際の効率性向上に重点を置きました。
さらに、システムがIveco Groupの技術分野の専門的な用語や概念を理解できるように、領域特化した最適化も実施しました。これにより、一般的な言語モデルが苦戦するような専門的なクエリにも正確に応答できるようになりました。
パフォーマンス最適化は継続的なプロセスであり、ユーザーフィードバックとシステム分析に基づいて常に改善を続けています。Iveco Groupの技術文書の性質が進化するにつれて、パフォーマンス最適化戦略も適応していく必要があります。
8.2. セキュリティとコンプライアンス
8.2.1. Amazon Cognitoとの統合
Marco Guerriero：ISKMの設計において、セキュリティとコンプライアンスは最も重要な要素です。私たちは、安全なユーザー認証とアクセス制御のために、Amazon CognitoをIveco GroupのIDP（アイデンティティプロバイダー）とシームレスに統合しました。
Amazon Cognitoの統合により、既存のIveco Groupのユーザー認証システムとの一貫性を保ちながら、強力な認証メカニズムを実現しています。これにより、ユーザーは既存の企業認証情報を使用してISKMにアクセスでき、追加の認証情報を管理する必要がありません。
この統合の重要な利点は、きめ細かなアクセス制御の実現です。Iveco Group内の様々な役割や部門に基づいて、異なるレベルのアクセス権を設定することができます。例えば、特定の技術文書は関連部門のメンバーのみがアクセスできるよう制限することが可能です。
また、Amazon Cognitoはセキュリティベストプラクティスに従った多要素認証（MFA）もサポートしており、機密性の高い技術情報へのアクセスに追加のセキュリティレイヤーを提供しています。
この統合は単にセキュリティを強化するだけでなく、ユーザー体験も向上させています。シングルサインオン（SSO）機能により、ユーザーは一度認証すれば、Iveco Groupの様々なシステムやアプリケーションにシームレスにアクセスできます。
さらに、Amazon Cognitoを通じて、ユーザーのアクティビティを監査し、不審なアクセスパターンを検出する機能も実装しています。これにより、潜在的なセキュリティ侵害を早期に特定し、対応することが可能になりました。
8.2.2. Amazon Bedrock Guardrailsの活用
Marco Guerriero：セキュリティとコンプライアンスのもう一つの重要な側面として、Amazon Bedrock Guardrailsを責任あるAI機能として活用し、ユーザープライバシーを保護しています。
Amazon Bedrock Guardrailsは、AIシステムが生成する内容に対する重要な保護層を提供します。これにより、AIの出力が常にIveco Groupのポリシーやガイドラインに準拠していることを確保しています。例えば、機密情報や個人情報が不適切に生成されることを防ぎ、また技術的に不正確な情報や誤解を招く可能性のある回答が提供されるリスクを低減しています。
私たちは、Iveco Groupの特定のニーズに合わせてこれらのガードレールをカスタマイズしました。例えば、特定の製品情報や内部プロジェクトの詳細など、公開されるべきでない情報を識別し、それらについての回答を制限するルールを設定しています。これは、知的財産の保護と企業秘密の維持に不可欠です。
また、これらのガードレールは、AIシステムが「わからない」と回答することも許可しています。つまり、情報が不十分な場合や、確信が持てない場合には、誤った情報を提供するよりも無知を認めるよう設計されています。これは特に技術文書の文脈では重要で、不正確な情報が重大な技術的エラーや安全上の問題につながる可能性があるからです。
さらに、Amazon Bedrock Guardrailsは継続的に監視・更新され、新たな脅威や課題に対応しています。これにより、時間の経過とともに変化するセキュリティ要件に対応し、システムが常に最高レベルの保護を提供できるようにしています。
8.2.3. AWS Private Linkの採用
Marco Guerriero：セキュリティ対策をさらに強化するため、すべてのトラフィックをAWSネットワーク内に保持し、パブリックインターネットへの露出を制限するために、AWS Private LinkをVPCエンドポイントと統合して使用しています。
この技術的選択は、ISKMのセキュリティ体制において極めて重要な役割を果たしています。AWS Private Linkを採用することで、Iveco GroupのVPC（Virtual Private Cloud）とAWSサービス間の通信が完全にプライベートネットワーク内で行われるようになり、インターネットを経由する必要がなくなりました。これにより、トラフィックの傍受やパブリックエンドポイントへの攻撃などの脅威から保護されています。
VPCエンドポイントとの統合により、Iveco Groupは特定のAWSサービスへのアクセスをより細かく制御することができます。たとえば、どのサービスにアクセスできるか、どのVPCからアクセスできるかを厳密に定義することができ、最小特権の原則を確実に適用できます。
また、AWS Private Linkの使用により、ネットワークレイテンシーも削減されています。トラフィックがパブリックインターネットを経由する必要がないため、より高速で信頼性の高い接続が実現し、結果としてユーザー体験も向上しています。
この技術の採用は、単にセキュリティを強化するだけでなく、規制コンプライアンスの遵守にも貢献しています。データプライバシーに関する様々な規制が厳しくなる中、AWS Private Linkの使用により、データが常にプライベートネットワーク内にとどまることが保証され、コンプライアンス要件を満たすことが容易になっています。
8.3. クラウド運用モデルと自動化
8.3.1. インフラストラクチャのコード化（AWS CDK、CloudFormation、Terraform）
Marco Guerriero：リストにある3番目の柱は、クラウド運用モデルと自動化です。このアプローチはスケーラビリティ、信頼性、効率性を確保するために非常に重要です。私たちはAWS CDK、AWS CloudFormation、Terraformなどのインフラストラクチャ・アズ・コードツールを活用して、インフラストラクチャを自動化し、バージョン管理しています。
これにより、環境間での一貫性のある繰り返し可能なデプロイメントが可能になります。インフラストラクチャをコードとして扱うこのアプローチは、多くの利点をもたらしています。まず、すべての環境設定が文書化され、バージョン管理されるため、変更の追跡が容易になります。これは大規模な組織での協力において特に重要で、複数のチームが同じインフラストラクチャ上で作業する場合の複雑さを軽減します。
また、環境の再現性も大幅に向上します。開発環境、テスト環境、本番環境が同じコードから生成されるため、「開発環境では動くが本番では動かない」といった問題が減少します。これは特に複雑なAIシステムのような場合に重要で、環境間の微妙な違いが予期せぬ動作の原因となることがあります。
さらに、障害からの回復も迅速になります。インフラストラクチャが完全にコード化されているため、問題が発生した場合でも、既知の良好な状態に迅速に復元することができます。これにより、システムのダウンタイムが最小限に抑えられ、ビジネスの継続性が確保されます。
セキュリティの観点からも、インフラストラクチャをコードとして管理することで、設定の誤りやセキュリティの欠陥を自動的に検出するツールを組み込むことができます。これにより、デプロイ前に潜在的な問題を特定し、修正することが可能になります。
8.3.2. Azure DevOpsとAWSサービスの統合
Marco Guerriero：継続的インテグレーションと継続的デプロイメントのために、Iveco Groupで長年使用されてきたAzure DevOpsとAWSサービスを統合しています。これにより、ジェネレーティブAIアプリケーションの構築、デプロイ、テストのためのシームレスなパイプラインを作成することができました。
この統合は戦略的に重要でした。なぜなら、Iveco Groupは既存のAzure DevOpsの投資と知識を活用しつつ、AWSの強力なサービスと機能を利用できるようになったからです。既存のデベロッパーワークフローを大幅に変更する必要なく、両方のプラットフォームの利点を組み合わせることができました。
具体的には、Azure DevOpsはソースコード管理、プロジェクト計画、自動化されたビルドとテストに使用され、一方でAWSサービスはインフラストラクチャのプロビジョニングと管理、そしてもちろんジェネレーティブAI機能の実行に使用されています。この2つのシステム間の統合ポイントは、デプロイメントパイプラインです。Azure DevOpsで管理されるビルドアーティファクトは、AWS環境に自動的にデプロイされます。
この自動化は構成管理にも及んでいます。ソリューションが最新かつ高パフォーマンスであることを確保するためです。例えば、セキュリティパッチや依存関係の更新は、Azure DevOpsパイプラインによって自動的に検出され、テストされ、承認されると本番環境にデプロイされます。これにより、システムの安全性と効率性が保たれます。
DevOpsの世界からのベストプラクティスをクラウドネイティブツールと組み合わせることで、単にジェネレーティブAIアプリケーションを大規模にデプロイするだけでなく、Iveco Groupのニーズに適応できる基盤的な運用モデルを提供しています。これによりイノベーションを加速させながら、運用の卓越性を維持しています。
8.4. テストとモニタリング
8.4.1. 包括的なテスト戦略（単体テストから受け入れテストまで）
Marco Guerriero：4つ目のレイヤーであるテストとモニタリングでは、ソリューションの品質、信頼性、使いやすさを確保するための包括的なテストと評価のフレームワークを確立しています。私たちは単体テストから統合テスト、そしてユーザー受け入れテストに至るまで、様々なテスト戦略を実装してシステムのパフォーマンスを検証しています。
包括的なテスト戦略の採用は、ジェネレーティブAIシステムのような複雑なソリューションでは特に重要です。単体テストでは個々のコンポーネントの機能を検証し、統合テストではこれらのコンポーネントが連携して期待通りに動作することを確認します。さらに、エンドツーエンドのテストでは、ユーザーの視点からシステム全体の機能を評価します。
ジェネレーティブAIの文脈では、さらに特別なテストも必要となります。例えば、モデルの回答が技術的に正確であることを確認するための専門家によるレビュー、異なる入力パターンに対するシステムの堅牢性をテストするためのアドバーサリアルテスト、予期しない入力に対するシステムの振る舞いを評価するためのエッジケーステストなどが含まれます。
また、テスト自動化も重要な焦点となっています。継続的インテグレーションパイプラインの一部として自動テストを実行することで、新しい変更が既存の機能を損なわないことをすぐに確認できます。これにより、開発速度を維持しながら品質を確保することができます。
テストは単なる検証プロセスではなく、システム改善のための貴重なフィードバックソースでもあります。テスト結果を分析することで、パフォーマンスのボトルネックや改善が必要な領域を特定し、継続的に品質を向上させることができます。
8.4.2. ユーザビリティテストとフィードバックの収集
Marco Guerriero：システムの技術的機能を確保するだけでなく、定期的にユーザビリティテストとユーザーフィードバック調査を実施して、ソリューションに関する洞察を収集し、改善の余地を特定しています。
ユーザビリティテストは、実際のエンドユーザーがシステムとどのように対話するかを理解するために極めて重要です。私たちは、Iveco Groupの異なる部門や役割から選ばれた実際のユーザーに、特定のタスクを完了するようシステムを使用してもらい、その過程を観察します。これにより、ユーザーインターフェースの直感性、ナビゲーションの容易さ、そして全体的なユーザー体験について貴重な洞察を得ることができます。
また、定期的なフィードバック調査も実施しています。これには定量的なメトリクス（例：満足度スコア、タスク完了率）と定性的なフィードバック（例：改善提案、困難を感じた領域）の両方が含まれます。このデータは、ユーザーのニーズと期待をよりよく理解し、それに応じてシステムを改良するために分析されます。
さらに、システム内に組み込まれたフィードバックメカニズムも実装しています。ユーザーは生成された回答に対して「良い」か「悪い」かを示し、オプションで詳細なコメントを提供することができます。このリアルタイムフィードバックは、モデルのパフォーマンスを継続的に監視し、微調整するための貴重なデータを提供します。
このユーザー中心のアプローチにより、技術的に優れているだけでなく、実際のユーザーニーズに応え、彼らの日々の業務を効果的にサポートするソリューションを確保することができます。最終的に、成功はユーザーの受け入れと採用に依存するため、このユーザビリティテストとフィードバック収集のプロセスは、ソリューションの長期的な成功において不可欠です。
8.4.3. 人間中心のアプローチによる継続的改善
Marco Guerriero：これら4つの柱全体を通じて、人間中心のアプローチが私たちの指導原則でした。これには、ユーザーのニーズとペインポイントを優先し、エンドユーザーと関わり、Iveco Groupの内部の専門家やステークホルダーを巻き込むことが含まれます。これにより、非常に結束力のあるインクルーシブなチームを構築することができました。
また、これらの人々に対してカスタマイズされた包括的なトレーニングを提供し、迅速なサポート体制を整え、組織内で継続的な学習と知識共有の文化を醸成することにも力を入れています。
人間中心のアプローチは、ただ単に最終ユーザーに焦点を当てるだけではありません。システムの開発、実装、サポートに関わるすべての人々を考慮することも意味します。これには、開発者、データサイエンティスト、ドメインエキスパート、ITサポートスタッフなど、ソリューションのライフサイクル全体に関わるすべての関係者が含まれます。
このアプローチの重要な側面は、技術的な複雑さを隠し、ユーザーがタスクを直感的に完了できるようにすることです。これは特にジェネレーティブAIのようなソリューションでは重要で、基盤となるテクノロジーが複雑であっても、ユーザーインターフェースはシンプルで使いやすいものである必要があります。
さらに、このアプローチではユーザーを単なる受動的な消費者ではなく、ソリューションの継続的な進化における積極的な参加者として位置づけています。彼らのフィードバックや洞察は、システムの改善サイクルに直接フィードバックされ、ソリューションが常にユーザーの変化するニーズと期待に応えられるようにしています。
これらすべての実践を採用することで、単に技術的に優れているだけでなく、真に価値があり、ユーザーに受け入れられ、そして最終的には実際に使用されるソリューションを構築することができました。
それでは、Pierfrancescoに戻して、このソリューションで達成できたビジネス成果を共有してもらいましょう。
9. ISKMの導入成果
9.1. 情報検索時間90%削減の実現
Pierfrancesco Rizzo：Marcoに感謝します。このスライドを見ていただければ分かるように、Iveco Groupでは、ジェネレーティブAIの力が私たちの生産性を大幅に向上させると本当に信じています。私たちは1年間の本番運用後に、情報検索時間が最大90%削減されたことを測定しました。
これは非常に印象的な成果です。従来のシステムでは、エンジニアや技術者が必要な情報を見つけるために、複数の文書を手動で検索し、関連する部分を読み、情報を統合する必要がありました。この作業に数時間、時には数日かかることもありました。例えば、特定の部品の仕様や過去のトラブルシューティング情報を見つけるのに半日以上費やすことも珍しくありませんでした。
ISKMの導入により、同じ情報を数分、場合によっては数秒で取得できるようになりました。例えば、「S-Wayモデルの排気バルブの最大直径は？」といった質問をシステムに入力するだけで、関連する技術文書から正確な情報が即座に抽出され、明確な回答として提示されます。
この時間削減は単なる便利さではなく、組織全体の生産性に直接的な影響を与えています。技術スタッフは情報検索に費やす時間を大幅に削減し、その時間を実際の問題解決や製品開発など、より価値の高い活動に充てることができるようになりました。また、意思決定のスピードも向上し、市場投入までの時間短縮にも貢献しています。
特に価値が高いのは、過去の知識やノウハウへのアクセスが容易になったことです。以前は組織内に蓄積されていたものの、実質的にアクセスが困難だった知識が、今では数秒でアクセス可能になり、組織全体の知的資産が効果的に活用されるようになりました。
9.2. 情報アクセス性の向上（従来比50%の新規検索増加）
Pierfrancesco Rizzo：情報アクセス性に関しても、私たちは現在、社員がどれだけ新しい検索を行っているかを測定しています。そして、古いシステム時代と比較して50%の新規検索増加を達成できると推定しています。
これは単なる数字の増加ではなく、システムの使いやすさと有用性を示す重要な指標です。従来のシステムでは、検索の複雑さや時間のかかる性質から、社員は必要最小限の検索しか行わない傾向がありました。つまり、「本当に必要な場合にのみ」情報検索を行い、それ以外の場合は既存の知識や経験に頼るか、同僚に尋ねるといった代替手段を選んでいました。
ISKMの導入により、情報検索のハードルが大幅に下がりました。自然言語で質問できることと、迅速な回答が得られることから、社員はより積極的に情報を探すようになりました。「ちょっと確認したい」という軽い気持ちでも、システムを利用するようになったのです。
これは組織文化における重要な変化を示しています。「確認する」ことが標準的な行動になり、推測や仮定に基づく決断が減少しました。結果として、より正確な情報に基づいた意思決定が行われるようになり、エラーの減少と品質の向上につながっています。
また、検索の多様性も拡大しています。以前は特定の種類の情報（例：製品仕様など）に限られていた検索が、今では過去のケーススタディ、トラブルシューティング事例、設計原理など、より広範な領域にまで及んでいます。これにより、組織内に蓄積された知識がより広く活用されるようになりました。
この検索増加は、システムの継続的な改善にも貢献しています。より多くの検索が行われることで、より多くのフィードバックが集まり、それに基づいてシステムの精度や応答性をさらに向上させることができます。
9.3. 文書内の矛盾による誤り40%削減
Pierfrancesco Rizzo：データの一貫性に関しては、文書内の間違いの数を40%削減できていると言えます。なぜなら、同じ情報が異なる文書に存在していても、異なる値を持っているという状況がよく発生していたからです。
これは実は重大な問題でした。技術文書間の矛盾は、混乱を招くだけでなく、設計ミスやテスト失敗など、実際のビジネス上の問題につながることがあります。例えば、ある部品の寸法が複数の文書で異なる数値として記載されていると、製造や組立ての段階で問題が生じる可能性があります。
ISKMの導入により、このような矛盾が容易に特定できるようになりました。システムが複数の文書から情報を取得する際、矛盾を検出し、それを明示的に示すことができます。例えば、「この値に関して文書A、B、Cの間に不一致があります」といった形で矛盾を指摘します。
さらに重要なのは、これらの矛盾が発見されると、文書の修正プロセスが開始されることです。最新かつ正確な情報に基づいて文書が更新され、将来的な混乱や誤りを防止します。これは単なる問題発見ではなく、積極的な品質改善のサイクルを生み出しています。
この40%の削減は、単に文書の質の向上を意味するだけではありません。それは意思決定の質の向上、製品開発の効率化、そして最終的には市場に出る製品の品質向上にもつながっています。エンジニアや技術者が正確で一貫性のある情報に基づいて作業できることの価値は計り知れません。
また、この改善は時間とともに累積的な効果を持ちます。文書が継続的に修正され改善されるため、情報の信頼性は時間とともに向上し続けます。これは長期的な知識管理の質を高める重要な要素です。
9.4. 文書作成コスト50%削減
Pierfrancesco Rizzo：最後に、非常に重要なポイントですが、文書作成のおかげで文書作成に必要な経費を50%削減することもできました。
これは大きなコスト削減効果です。従来の文書作成プロセスは時間と労力を要するものでした。技術者やエンジニアが専門知識を文書化するために、本来の業務から時間を割いて文書を作成する必要がありました。その後、編集、レビュー、承認のサイクルを経て、最終的な文書が完成します。このプロセス全体が多大なリソースを消費していました。
ISKMを活用することで、文書作成プロセスが大幅に効率化されました。既存の知識ベースから関連情報を抽出し、新しい文書の下書きを自動生成することができるようになりました。人間の専門家はこの下書きをレビューし、必要に応じて修正や追加を行うだけで済みます。これによりゼロから文書を作成する負担が大幅に軽減されました。
特に、類似した製品や部品に関する技術文書の作成において、この効率化の効果は顕著です。新しい製品が既存製品の変更や進化である場合、ISKMは既存の文書から関連する情報を識別し、新製品用に適応させることができます。これにより、同じ情報を繰り返し書く必要性が減少しました。
このコスト削減は単なる金銭的な節約だけではありません。技術スタッフがより高付加価値な活動に時間を使えるようになったことで、イノベーションの促進や問題解決能力の向上といった副次的な効果ももたらしています。また、文書作成の迅速化により、情報がより早く組織内で共有されるようになり、意思決定サイクルの短縮にも貢献しています。
しかし今、私たちは先ほど紹介した2番目のユースケース、Iveco Groupのスマート技術図面についてお話ししたいと思います。背景は最初のユースケースと非常に似ていますが、ここでは同じコンセプトを技術図面に適用しようとしています。今回のアイデアは、ジェネレーティブAIの上にコンピュータビジョンの機能も追加することです。
10. ジェネレーティブAIソリューション：Smart Technical Drawings（TEDDI）
10.1. 技術図面からの情報抽出の課題
10.1.1. 機械部品の識別と特徴抽出
Pierfrancesco Rizzo：技術図面は単なる文書ではありません。これについては後ほど詳しく説明します。このケースでも、いくつかの目標を設定しました。アイデアとしては、ピストンとコネクティングロッドなど、ある機械部品を他の機械部品と区別できるツールを実現することでした。
また、図面に含まれる情報を一定の精度で抽出することも目標としました。この課題に取り組む中で、いくつかの課題に直面しました。先ほど述べたように、最大の課題の一つは機械部品を区別することと、同じ図面にある異なる寸法を区別することでした。
機械部品の識別は簡単なタスクではありません。技術図面は複雑で、多くの情報が凝縮されています。同じカテゴリー内の部品（例えばさまざまなタイプのピストン）は視覚的によく似ており、専門知識なしでは区別が難しいことがあります。また、図面の品質や形式にもばらつきがあり、古い図面と新しい図面、手書きの図面とCADで作成された図面など、様々な形式が混在しています。
さらに、部品が組み立てられた状態を示す図面では、個々の部品を分離して識別することが特に難しくなります。部品が重なり合い、一部が隠れていることがあるためです。
特徴抽出においても多くの課題があります。技術図面には寸法、公差、材料仕様、表面処理など多くの情報が含まれています。これらの情報は図面上の様々な場所に散在しており、さらに特定の規約や略語を使って表現されていることが多いため、自動抽出が難しくなっています。
これらの課題に対応するために、高度なコンピュータビジョン技術と機械学習アプローチを組み合わせたソリューションが必要でした。
10.1.2. 同一図面内の複数寸法表記の識別
Pierfrancesco Rizzo：同一図面内の複数寸法表記の識別も大きな課題でした。1枚の図面に50種類以上の異なる寸法が含まれていることもあります。そのため、ツールは内径や直径などの異なる寸法を区別できる必要があります。
技術図面には多くの寸法表記が含まれており、それらは直径、半径、長さ、角度、公差範囲など多岐にわたります。これらの寸法はそれぞれ異なる記号や表記方法で示されています。例えば、直径記号「Ø」や半径を示す「R」などが使われます。しかし、これらの記号が常に一貫して使用されているわけではなく、図面の年代や作成者によって表記方法に違いがあります。
また、同じ部品の異なる側面や異なる視点を示す複数の図が一つの図面上に存在することも多く、それぞれの図に対応する寸法が記載されています。これにより、どの寸法がどの部分を指しているのかを正確に特定することがさらに複雑になります。
さらに、技術図面には寸法線、引出線、リーダー線などの様々な線種が使用されており、これらを適切に解釈して寸法と対応する部品の特徴を関連付ける必要があります。公差情報や特殊な条件が注記として記載されていることもあり、これらも正確に解釈する必要があります。
これらの課題に対処するためには、単純な画像認識や文字認識だけでなく、図面の構造を理解し、異なる要素間の関係を把握できる高度なアルゴリズムが必要でした。ここでMarcoに、AWSが準備したソリューションについて説明してもらいましょう。
10.2. マルチモーダルAIアプローチの採用
10.2.1. マルチモーダル埋め込みによる画像・テキスト空間の統合
Marco Guerriero：Pierfrancescoが共有してくれた課題を考慮すると、このチャレンジングな問題にマルチモーダルソリューションでアプローチすることを決定しました。マルチモーダルAIは、これらの非常に解釈が難しい図面から複雑な情報を抽出する方法を再考する上で役立ちます。
マルチモーダルAIに、マルチモーダル埋め込みのレンズを通して深く掘り下げたいと思います。私の娘はこのチャートが好きだと思います。
動物の画像コレクションから猫を検索することを想像してみてください。従来は、テキストの説明か画像分析のどちらかに頼っていましたが、マルチモーダル埋め込みでは、画像とテキストの両方を、近年「埋め込み空間」と呼ばれる共有の高次元ベクトル空間で表現することができます。この空間では、意味的に類似したアイテムが互いに近い位置にマッピングされます。
例えば、この空間では、黒猫は「小さな毛皮のある哺乳類」というテキスト記述に非常に近い位置にマッピングされます。これを私たちの機械図面のユースケースに適用してみましょう。Pierfrancescoが先ほど言及したように、複雑な図面の中から特定のコンポーネント、例えばバルブを特定する必要があることがよくあります。バルブの視覚的表現と関連するテキスト表記を共有の統合空間に埋め込むことで、検索機能を強化することができます。
このアプローチにより、ユーザーは自然言語（「排気バルブの直径は？」など）で質問でき、システムは図面を理解し、特定の部分を識別し、その測定値を返すことができます。これは単なるテキスト検索や単純な画像認識では不可能なことでした。
マルチモーダル埋め込みの美しさは、視覚的特徴とテキスト情報の間のこのシームレスな関連付けにあります。部品名、仕様、測定値などの図面上のテキストは、それらが示す視覚的要素と一緒に理解されます。これにより、システムはより洗練された処理と解釈が可能になり、エンジニアや技術者が技術図面から情報を抽出するという日常的なタスクを劇的に簡素化できます。
10.2.2. AIエージェントによる多段階処理の実現
Marco Guerriero：マルチモーダルAIは非常に強力ですが、技術図面から複雑な情報を抽出するには、しばしば多段階のアプローチが必要です。この問題を、より管理しやすいサブ問題に分解する必要があります。そして、異なる専門アルゴリズムを活用することで、これらのサブ問題に対処します。
例えば、次のスライドでは、AIエージェントがこれらのステップをどのように調整するか、光学式文字認識から画像セグメンテーション、そして人間のヒントまで、これらの非常に複雑な課題に取り組むためのより堅牢で柔軟なワークフローを作成する方法を見ていきます。
しかし、AIエージェントとは何でしょうか？過去数ヶ月間、AIによる情報検索から直接的なタスク実行へのパラダイムシフトが起きています。AIエージェントは、簡潔に言えば、環境と対話し、データを収集し、ユーザー定義の目標に従ってタスクを実行できるソフトウェアプログラムです。
このように、私たちはAIにプロンプトを委ねるだけでなく、ワークフロー全体を委ねています。エージェントは複数のモデルやツール、外部APIや外部ライブラリへの呼び出しを活用し、結果を継続的に評価してプロセスを最適化します。このアプローチは新しい価値の機会を開放し、AI技術とのユーザーエンゲージメントを強化します。
AWSではAmazon Bedrock Agentsを通じて、顧客やIveco GroupがこのようなAIエージェントを実装するのをどのように支援しているのでしょうか？Amazon Bedrock Agentsを使用すると、まず選択した基盤モデルを選択し、それに企業のエンタープライズデータシステムへのアクセスを提供することで、わずか数クリックでエージェントを作成できます。Lambda関数などの他のAWSサービスと統合することで、特定のビジネス成果を達成するために必要なさまざまなステップを組み合わせるこのエージェンティックAIワークフローを作成できます。
このようなエージェンティックAIワークフローが、この非常に難しい問題をどのように解決するのか見てみましょう。
11. TEDDIの実装フロー
11.1. 画像セグメンテーション（SAM2の活用）
Marco Guerriero：このソリューションは「吸気バルブの外径はいくつですか？」という質問に答えるように設計されています。ワークフローは完全な技術図面、つまり完全な画像から始まります。この完全な画像は、オープンソースフレームワークを使用してセグメント化されます。
この事例では、Metaが提供するオープンソースのSAM2（Segment Anything Model 2）を活用しています。このステップでは、複雑な画像をより管理しやすい部分に分解します。SAM2は最先端のセグメンテーションモデルで、画像内のオブジェクトや領域を高精度で識別できます。
技術図面の文脈では、このセグメンテーションは特に重要です。技術図面には通常、多くの異なる要素（製品の複数の部品、異なる視点からの複数のビュー、寸法線、注釈など）が含まれています。SAM2を使用することで、図面を意味のある構成要素に分解し、それぞれを個別に分析できるようになります。
例えば、バルブとその構成部品、寸法情報を含む領域、注釈テキストなどを個別のセグメントとして識別できます。この分解により、後続の処理ステップがより正確かつ効率的になります。それぞれのセグメントは、特定のタイプの情報（視覚的特徴や測定値など）に最適化された異なる分析技術を適用できるからです。
SAM2のようなオープンソースツールを活用する利点は、高度なAI機能を既存のシステムに統合できることです。専用のモデルをゼロから開発する必要はありません。このアプローチにより、開発時間が短縮され、確立されたツールの精度と堅牢性を活用できます。
セグメンテーションはワークフローの最初のステップに過ぎませんが、後続のすべての処理の基盤となる重要なステップです。適切に図面をセグメント化することで、より正確な情報抽出と質問応答が可能になります。
11.2. 関連部分の切り出しと分析
Marco Guerriero：図面の完全なセグメンテーションが完了すると、次のステップでは図面の関連部分を詳細な分析のためにクロップします。このステップは単純に見えるかもしれませんが、実際には非常に重要な処理段階です。
セグメンテーションによって特定された関連領域を正確に切り出すことで、処理するデータ量を大幅に削減し、後続の分析ステップの精度と効率を向上させることができます。例えば、「吸気バルブの外径は？」という質問に答えるためには、図面全体ではなく、吸気バルブとその寸法情報を含む部分だけに焦点を当てる必要があります。
切り出しプロセスでは、セグメンテーションから得られた空間的情報を使用して、関心領域の正確な境界を決定します。この境界は、必要なすべての情報（バルブ自体の視覚的表現、関連する寸法線、テキスト注釈など）を含みつつ、不必要な周辺情報を排除するように計算されます。
切り出された画像は、より高い解像度と詳細レベルで分析することができます。これは特に、細かい寸法のテキストや小さな図面記号などの微細な詳細を正確に解釈する必要がある場合に重要です。
また、このアプローチにより、システムは一度に1つの関連コンポーネントに集中することができ、複雑な図面全体を一度に処理しようとする場合に発生する可能性のある混乱や誤解釈を回避できます。これは特に、多くの部品や重なり合う情報が含まれる複雑な技術図面を扱う際に価値があります。
この切り出しと集中分析のアプローチは、人間のエンジニアが技術図面を読む方法を模倣しています。熟練したエンジニアは、関連する部分を素早く特定し、そこに注意を集中させ、必要な情報を抽出します。TEDDIはこの人間の認知プロセスをデジタルで再現し、複雑な図面から正確な情報を抽出する能力を強化しています。
11.3. テキスト抽出（Amazon Textract、Amazon Rekognition）
Marco Guerriero：クロップされた画像は次にテキスト抽出の段階に進みます。ここではAmazon TextractやAmazon Rekognitionなどのサービスを活用して、光学式文字認識（OCR）を行います。このステップは、解析しようとしている部品に関連する重要な測定値を抽出するために非常に重要です。
Amazon Textractは、文書からテキスト、フォーム、テーブルを自動的に抽出するように特別に設計されたAWSサービスです。TEDDIで使用する場合、このサービスは技術図面から寸法、公差、注釈などのテキスト情報を正確に識別して抽出します。Textractの強みは、複雑なレイアウトや様々なフォント、回転したテキストなど、技術図面に典型的な課題に対処できることです。
一方、Amazon Rekognitionは画像分析に特化したサービスで、テキスト抽出に加えて、オブジェクト検出や画像分類などの機能も提供します。これにより、テキスト情報と視覚的コンテキストの両方を理解できるため、図面上のどのテキストがどの部品や特徴に関連しているかを正確に判断するのに役立ちます。
技術図面からのテキスト抽出は、標準的なドキュメントからのテキスト抽出よりも複雑です。多くの場合、テキストは寸法線の近くに配置され、小さなフォントで書かれていたり、図や線と重なっていたりします。また、技術記号（直径記号「Ø」、角度記号「°」など）が頻繁に使用され、これらの特殊文字を正確に認識することは通常のOCRシステムでは難しい場合があります。
TEDDIのワークフローでは、これらのAWSサービスを使用して抽出されたテキストは、抽出された位置情報と共に保存されます。これにより、テキスト自体の内容だけでなく、図面のどの部分に関連しているかという空間的コンテキストも維持されます。この空間的関係は、次の推論段階でテキストの意味を正確に解釈するために不可欠です。
このテキスト抽出ステップの精度は、最終的な回答の質に直接影響します。そのため、TEDDIは複数の手法を組み合わせ、異なるアプローチの結果を検証し、最も信頼性の高い抽出を確保します。
11.4. 密度マッチングによる関連部分の強調表示
Marco Guerriero：また、密度マッチングを活用して、ユーザーが求めている回答が含まれている可能性が最も高い部分を整列して強調表示します。このスライドの赤い四角形で見ることができるように、この部分が最も関連性が高いと特定されています。
密度マッチングは、図面内の視覚的要素とテキスト要素の両方を考慮して、ユーザーの質問に最も関連する可能性が高い領域を特定するための重要な技術です。この手法では、セグメンテーションとテキスト抽出から得られた情報を組み合わせて、「関連性の密度」が最も高い領域を計算します。
具体的には、図面の各領域に対して、ユーザーの質問に含まれるキーワードやコンセプトとの関連性のスコアが計算されます。例えば、「吸気バルブの外径は？」という質問に対しては、「吸気」「バルブ」「径」などの用語や概念に関連する視覚的特徴やテキスト注釈を含む領域が高いスコアを受けます。
この関連性スコアは、テキストの意味的類似性だけでなく、図面上の空間的関係も考慮します。例えば、寸法情報は通常、測定対象の特徴の近くに配置されるため、バルブの視覚的表現と直径の値が近接している領域は関連性が高いと判断されます。
密度マッチングによって特定された高関連性領域は、赤い四角形などで視覚的に強調表示され、ユーザーに提示されます。これにより、ユーザーは回答の根拠となる図面の部分を視覚的に確認でき、システムの信頼性と透明性が向上します。
また、この強調表示は単なる視覚的ガイドではなく、最終的な回答生成プロセスにも不可欠な入力となります。強調表示された領域からの情報は、より高い重みが与えられ、最終的な回答の生成においてより大きな影響を与えます。
11.5. 推論層（Amazon Bedrock）による最終回答の生成
Marco Guerriero：最後に、この層から抽出された情報はAmazon Bedrockで表される推論層に供給されます。この層がデータを解釈して最終的な回答を作成します。この場合、吸気バルブの直径は33ミリメートルということになります。
しかし、この質問は複雑な図面から値を抽出するという点ではそれほど複雑に聞こえないかもしれませんが、同じ方法論を適用して、値の抽出から推論へと移行するより複雑な質問にも答えることができます。例えば、システムに「ボアピッチの値を提供してください」と質問すると、システムはボアピッチが内燃機関のシリンダーボアを表す2つの隣接する円の2つの半径の合計であることを理解します。
Amazon Bedrockは、この推論層の中核となる技術です。これは、AIモデルを簡単に選択して統合できるようにするAWSのフルマネージドサービスです。TEDDIでは、Bedrockを通じて最先端の大規模言語モデル（LLM）にアクセスし、前のステップで収集されたすべての情報を解釈し、人間が理解できる回答に統合します。
推論層の主な役割は、抽出されたテキスト、識別された視覚的特徴、空間的関係などの生データを取り、これらを意味のある洞察に変換することです。これには技術的な理解と言語能力の両方が必要です。例えば、「33 mm」という数字を単に識別するだけでなく、それが質問された特定の測定値（この場合は吸気バルブの外径）を表していることを理解する必要があります。
より複雑な質問（「ボアピッチの値は？」など）の場合、推論層はさらに高度な理解を示します。単に数値を探すのではなく、「ボアピッチ」という概念を理解し、それがシリンダーボアを表す2つの隣接する円の半径の合計として計算されることを認識します。そして、図面からこれらの値を特定し、必要な計算を実行して最終的な回答を提供します。
この推論能力は、TEDDIを単なる情報抽出ツールから、エンジニアの思考プロセスを模倣し、複雑な技術的概念を理解できる高度なアシスタントへと変えるものです。これにより、ユーザーは自然な言語で複雑な技術的質問をし、明確で正確な回答を得ることができます。
11.6. ユーザーインターフェースとフィードバック機能
Marco Guerriero：ソリューションの概要を説明した後、皆さんにTEDDIをご紹介します。TEDDIはTechnical Drawing Data Interpretationの略であり、クマではありません。このソリューションの名前です。
TEDDIはチャットのようなインターフェースを持ち、ユーザーは質問を入力できます。示された例では、誰かが「排気バルブのマッシュルームの最大直径は何ですか？」と尋ねています。TEDDIはこの質問を処理し、Iveco Groupのデジタルアーカイブから取得した情報に基づいて回答を提供します。
回答は3つのサブパートで構成されています。まず、最大直径を返す質問への具体的な回答があります。次に、関連部分を強調表示した技術図面のズームイン部分があり、さらにバルブに関連するすべての追加測定値のリストがあります。
ズーム画像をクリックすると完全な技術図面を見ることができ、元の問題の複雑さが明らかになります。これにより、バルブの設計に関わる様々なコンポーネントが示されます。
インターフェースには、ユーザーが回答に対するフィードバックを提供するためのオプションもあり、サムズアップとサムズダウンのボタンが含まれています。私の説明の冒頭で述べたように、人間中心のアプローチでユーザーフィードバックを取り入れることが非常に重要です。
このユーザーインターフェースは、複雑な技術情報への簡単なアクセスと、人間の専門家との自然なやり取りの感覚を提供するように設計されています。ユーザーは複雑な技術用語や特殊なクエリ言語を使用する必要なく、日常的な質問をすることができます。
フィードバック機能は単なるユーザー満足度の測定ツールではなく、システムの継続的な改善における重要な要素です。ユーザーからのフィードバックは、回答の品質向上、モデルの微調整、そして時間の経過とともにユーザー体験を向上させるためのインターフェース調整に使用されます。
それでは、TEDDIが達成できたビジネス成果についてPierfrancescoに話を戻しましょう。
12. TEDDIの導入成果
12.1. 図面からの情報検索時間削減
Pierfrancesco Rizzo：MarcoがTEDDIのテクニカルアーキテクチャを素晴らしく説明してくれました。この第二のユースケースでも、最初のKPIは図面から情報を取得するために必要な時間の削減に関するものです。
技術図面からの情報検索は従来、非常に時間のかかるプロセスでした。エンジニアや技術者は物理的な図面アーカイブから適切な図面を見つけ出し、複雑な技術情報の中から特定の測定値や仕様を探し出す必要がありました。多くの場合、この作業には数時間、時には数日を要することもありました。
TEDDIの導入により、この情報検索プロセスが劇的に効率化されました。エンジニアは自然言語で質問を入力するだけで、数秒以内に正確な回答を得られるようになりました。例えば、「排気バルブのマッシュルームの最大直径は何ですか？」という質問に対して、システムは関連する図面を特定し、必要な測定値を抽出して、明確な回答を提供します。
この時間削減は単なる便宜性の向上ではなく、設計プロセス全体の加速につながります。エンジニアは情報収集に費やす時間を大幅に削減し、その時間を創造的な問題解決や革新的な設計に充てることができるようになりました。また、正確な情報への迅速なアクセスにより、設計の初期段階でより多くの検証と反復が可能になり、最終製品の品質向上にも貢献しています。
さらに、TEDDIは組織内の知識の民主化にも貢献しています。以前は特定の専門家しかアクセスできなかった技術情報が、今ではより広範な従業員が簡単にアクセスできるようになりました。これにより、部門間のコラボレーションが促進され、全体的なイノベーションプロセスが強化されています。
12.2. 社員の技術図面データへのクエリー増加
Pierfrancesco Rizzo：ISKMと同様に、二つ目のKPIは従業員が技術図面データに対して行うクエリーの数を増加させることに関するものです。
TEDDIの導入により、技術図面データへのアクセス性が大幅に向上しました。従来の方法では、技術図面の検索や解釈には専門知識が必要であり、多くの従業員にとって障壁となっていました。しかし、自然言語インターフェースと直感的な視覚化機能を備えたTEDDIにより、技術知識レベルに関わらず、より多くの従業員が技術図面の情報にアクセスできるようになりました。
この改善された使いやすさにより、従業員が技術図面データにクエリーを実行する頻度が顕著に増加しました。エンジニアだけでなく、プロジェクトマネージャー、品質保証チーム、さらには営業・マーケティング部門のメンバーも、必要に応じて技術情報にアクセスするようになっています。
クエリーの増加は、より情報に基づいた意思決定と強化されたコラボレーションにつながっています。例えば、プロジェクトマネージャーは特定の部品の製造複雑性を理解するために技術詳細を確認できるようになり、営業チームは顧客の技術的質問に迅速に回答できるようになりました。
また、クエリーの多様性も増加しています。単純な寸法や仕様の検索だけでなく、複数の部品間の関係や、設計変更の影響など、より複雑な質問も増えています。これは組織全体の技術理解度の向上を示しています。
この増加したクエリー量は、システム自体の継続的な改善にも貢献しています。より多くのクエリーが処理されるほど、システムはより多くの学習データを得ることができ、回答の精度と関連性が向上します。これにより、ポジティブなフィードバックループが生まれ、ユーザー満足度とシステム性能の両方が継続的に向上しています。
12.3. 技術文書のミス削減
Pierfrancesco Rizzo：もう一つの重要なKPIは、技術文書のミス削減に関するものです。私たちの会社では、多くの技術文書が技術図面から生成されています。
従来のプロセスでは、技術図面から文書を作成する際に、人的エラーが発生するリスクが高くありました。測定値の転記ミス、単位の誤変換、図面の誤解釈などが、技術文書の正確性に影響を与えることがありました。こうしたエラーは、下流の設計プロセス、製造、そして最終的には製品品質に重大な影響を及ぼす可能性があります。
TEDDIの導入により、技術図面からの情報抽出が自動化され、人的エラーの発生率が大幅に削減されました。システムは一貫した方法で図面を解釈し、正確な値を抽出します。また、測定値の単位変換や計算も自動的に処理されるため、手動計算に伴うエラーリスクも排除されます。
特に複雑な図面や多くの寸法が含まれる図面の場合、人間が処理する際のエラー率はかなり高くなる可能性がありますが、TEDDIは一貫した精度で情報を抽出します。さらに、システムは自らの確信度を評価し、確信が低い場合には人間の確認を求めることができるため、高度な信頼性が維持されます。
技術文書のミス削減は、単に文書品質の問題ではなく、ビジネス全体に波及効果をもたらします。正確な文書は、設計の反復回数の減少、製造上の問題の減少、そして最終的には市場投入までの時間短縮につながります。また、品質問題や保証クレームのリスク低減にも貢献し、長期的なコスト削減と顧客満足度の向上を実現します。
さらに、TEDDIを通じて識別された不一致や曖昧さは、元の技術図面の改善にもフィードバックされ、情報の源泉自体の品質向上にも寄与しています。
12.4. 既存部品の再利用による設計コスト削減
Pierfrancesco Rizzo：最後に挙げたいのは、しかし重要ではないのですが、会社の節約です。新しい小さなコンポーネントを作成する必要がある場合に、アーカイブを調べる代わりに一からコンポーネントの図面を描き始めることが多いということを想像してください。同様に、新しいコンポーネントを作成するたびに生成しなければならない新しい部品番号の処理も挙げられます。
これは実際に大きな問題でした。私たちの組織では、既存の部品を見つけて再利用する代わりに、新しい部品を一から設計することが頻繁に行われていました。その主な理由は、膨大なアーカイブから適切な既存部品を見つけ出すことが非常に困難だったからです。結果として、本質的には同じか非常に類似した多くの部品が設計され、それぞれに新しい部品番号が割り当てられていました。
TEDDIの導入により、既存の技術図面への効率的なアクセスが可能になり、部品の再利用率が大幅に向上しました。エンジニアは新しい設計に取り組む際、類似の既存部品を簡単に検索できるようになりました。例えば、特定の直径と材質を持つバルブが必要な場合、それらのパラメータでTEDDIに問い合わせることで、既存の類似部品をすぐに特定できます。
この部品再利用の増加は、設計コストの大幅な削減につながっています。新しい部品の設計には、初期コンセプト、詳細設計、検証テスト、製造準備など、多くの段階があります。既存部品を再利用することで、これらのステップの多くをスキップでき、時間とリソースを節約できます。
さらに、部品数の削減により、在庫管理やサプライチェーンの複雑さも軽減されます。類似した多数の部品を管理する代わりに、標準化された部品セットを維持することで、在庫コストの削減、サプライヤー管理の簡素化、そしてスケールメリットによる調達コストの削減が実現します。
また、既存の検証済み部品を再利用することで、品質と信頼性も向上します。既に実績のある部品は、新しく設計された部品に比べて予期せぬ問題が発生するリスクが低くなります。
この既存部品の再利用によるコスト削減は、Iveco Groupの総所有コスト削減戦略の重要な部分となっており、より効率的かつ競争力のある企業体制の構築に貢献しています。
<userStyle>Normal</userStyle>
13. Iveco Groupの将来ビジョン
13.1. 顧客中心アプローチの継続
Pierfrancesco Rizzo：Iveco GroupとAWSとの協業について紹介した後、Ivecoの今後のビジョンをお話しする前に、最高技術・デジタル責任者の言葉を皆さんに紹介したいと思います。この言葉を数語で要約してみます。
Ivecoはもちろん顧客を中心に据え続け、顧客のニーズに応える柔軟性を維持するよう努めます。もちろん、AIベースの新しいサービスを導入し続けることでイノベーションを継続していきます。そして非常に重要なのは、AWSのようなパートナーとの重要なパートナーシップを引き続き活用していきたいということです。
顧客中心アプローチは私たちの戦略の核心であり続けます。技術的な進歩やイノベーションはすべて、最終的に顧客の需要と期待を満たすという目的に沿ったものでなければなりません。私たちは「技術のための技術」ではなく、常に顧客の実際のニーズに基づいたソリューションの開発を目指しています。
この顧客中心のアプローチでは、顧客からの継続的なフィードバックを収集し、それを製品開発プロセスに組み込むことが重要です。これにより、私たちの製品やサービスが市場の実際のニーズに確実に応えることができるようになります。
また、顧客の多様なニーズに対応するためには、柔軟性が不可欠です。異なる市場、異なるセグメント、異なる用途に対応するためのカスタマイズ能力を維持することが重要です。同時に、スケールメリットを活かし、コスト効率を維持するためのプラットフォームアプローチも追求していきます。
顧客中心の文化は、組織のあらゆるレベルに浸透しています。エンジニアから経営陣まで、すべての決定において「これは顧客にとってどのような価値を生み出すのか」という問いが中心にあります。このアプローチは、技術革新の時代においても変わることなく、むしろその重要性は増しています。
13.2. AIベースのサービス拡充
Pierfrancesco Rizzo：Iveco Groupでは、AIベースのサービスを継続的に導入し、拡充していくことを戦略の重要な柱としています。本日ご紹介したISKMやTEDDIのようなソリューションは、私たちのAIジャーニーの始まりに過ぎません。
私たちは2023年半ばからジェネレーティブAIの本格的な適用を始め、わずか1年という短期間で大きな成果を上げることができました。この勢いを維持し、さらに加速させていく予定です。AIの適用領域は、社内プロセスの最適化から顧客向けサービス、製品自体の機能強化まで多岐にわたります。
例えば、車両のメンテナンス予測や最適化の分野では、AIを活用して車両から収集されるテラバイト規模のデータを分析し、予防的なメンテナンス推奨や運用コスト削減のための洞察を提供するサービスを開発しています。これにより、車両のダウンタイムを最小限に抑え、総所有コストを削減することができます。
また、顧客体験の向上にもAIを活用しています。カスタマーサポートにAIチャットボットを導入したり、顧客の使用パターンに基づいてパーソナライズされた提案を行ったりするサービスを拡充しています。
さらに、車両自体にもAI機能を組み込んでいます。ドライバーアシスタンスシステムの高度化、自動運転機能の段階的導入、そして車両と環境の相互作用を最適化するインテリジェントシステムなどがその例です。
AIの倫理的で責任ある使用も私たちの優先事項です。データプライバシー、セキュリティ、透明性を確保しながら、革新的なソリューションを提供するバランスを常に意識しています。
この継続的なAIサービスの拡充により、Iveco Groupは単なる車両メーカーから、統合モビリティソリューションプロバイダーへの変革を進めています。これは私たちのビジネスモデルの進化においても重要な要素となっています。
13.3. AWSなどのパートナーシップ活用
Pierfrancesco Rizzo：もちろん、Ivecoは顧客を中心に据え続け、顧客のニーズに対応するための柔軟性を維持するよう努めていきます。もちろん、AIベースの新しいサービスを導入することで革新を続けたいと考えています。そして非常に重要なことは、AWSのようなパートナーとの重要なパートナーシップを活用し続けたいということです。
次世代の車両に関するビジョンについては、これは非常にクリエイティブなイメージですが、どのように実現されるかが想像できます。私たちは運転手の体験を中心に置き続ける車両を想定しており、もちろんAIに基づいたより多くの新しいサービスを段階的に導入していきたいと考えています。
これは特にAIの大規模な採用によって実現されます。特に、ハイパー接続された車両を想定しています。これは、醜く接続されて通信する車両のエコシステムの創造のおかげです。また、以前のスライドでも述べたように自動運転技術も考えています。もちろん、自分自身で運転できる能力を持ち、運転手が他のタスクを行えるようにする車両を開発したいと考えています。
最後に、車両同士が通信する「車車間通信」技術、そして「車両-インフラ間通信」技術により、車両が道路や周囲のインフラから情報を取得できるようになると考えています。
Alessandro Ricci：Pierfrancesco、今日はIvecoと一緒に登壇できて光栄でした。Marco、あなたのサポートにも感謝します。本日セッションに参加された皆様に感謝いたします。また、日々の熱意を持ってこれらの結果を達成するために働いている人々にも特別な感謝を捧げます。
モバイルアプリでアンケートの回答にお時間をいただければ幸いです。ここに私たちの連絡先がありますので、今後ご連絡いただければと思います。そして今、もし何かご質問がありましたら、ステージ近くでお待ちしております。ありがとうございました。また次回お会いしましょう。
13.4. 未来の車両像
13.4.1. ハイパーコネクテッド車両の実現
Pierfrancesco Rizzo: 次世代の車両に関するビジョンについては、これは非常にクリエイティブなイメージですが、どのように実現されるかが想像できます。私たちは運転手の体験を中心に置き続ける車両を想定しており、もちろんAIに基づいたより多くの新しいサービスを段階的に導入していきたいと考えています。
これは特にAIの大規模な採用によって実現されます。特に、ハイパー接続された車両を想定しています。これは、適切に接続されて通信する車両のエコシステムの創造のおかげです。また、以前のスライドでも述べたように自動運転技術も考えています。もちろん、自分自身で運転できる能力を持ち、運転手が他のタスクを行えるようにする車両を開発したいと考えています。
最後に、車両同士が通信する「車車間通信」技術、そして「車両-インフラ間通信」技術により、車両が道路や周囲のインフラから情報を取得できるようになると考えています。
Alessandro Ricci: Pierfrancesco、今日はIvecoと一緒に登壇できて光栄でした。Marco、あなたのサポートにも感謝します。本日セッションに参加された皆様に感謝いたします。また、日々の熱意を持ってこれらの結果を達成するために働いている人々にも特別な感謝を捧げます。
モバイルアプリでアンケートの回答にお時間をいただければ幸いです。ここに私たちの連絡先がありますので、今後ご連絡いただければと思います。そして今、もし何かご質問がありましたら、ステージ近くでお待ちしております。ありがとうございました。また次回お会いしましょう。
13.4.2. 自動運転技術の進化
Pierfrancesco Rizzo: もちろん、自動運転技術についても私たちは積極的に取り組んでいます。以前のスライドでも少し触れましたが、Iveco Groupでは自動運転技術、特にレベル2+の技術に取り組んでおり、今後数年以内にこれらの車両を生産に投入する予定です。
私たちのビジョンでは、自分自身で運転できる能力を持った車両を開発することで、運転手が他のタスクを行えるようにしたいと考えています。これにより、運転手の生産性が向上するだけでなく、安全性も大幅に向上すると期待しています。
自動運転技術の導入は、私たちがIveco Groupで取り組んでいる三つの主要な柱のひとつです。持続可能性、人工知能とソフトウェア定義車両、そして自動運転技術です。これらの技術を組み合わせることで、私たちの顧客に革新的なソリューションを提供し続けることができると確信しています。
13.4.3. V2V（車車間）・V2I（車両-インフラ間）通信の実現
Pierfrancesco Rizzo: 私たちが将来の車両に取り入れたいと考えている重要な技術の一つが、車両間通信技術です。車両が互いに通信する能力、つまりV2V（車車間通信）技術の実現を目指しています。これにより、車両は周囲の他の車両からリアルタイムで情報を受け取り、より安全で効率的な運転が可能になります。
また同様に重要なのが、V2I（車両-インフラ間通信）技術です。この技術により、車両は道路や周囲のインフラから情報を取得する能力を持つことになります。例えば、交通信号や道路状況、渋滞情報などをリアルタイムで受信し、それに基づいて運転を最適化することができるようになります。
これらの通信技術は、特に自動運転技術と組み合わせることで、その効果を最大限に発揮します。車両が周囲の環境と常に接続され、情報を共有することで、交通の流れの改善、事故の減少、燃費の向上など、多くのメリットをもたらすことができると考えています。Iveco Groupでは、こうした未来のコネクテッドな交通エコシステムの実現に向けて、積極的に技術開発を進めています。
14. 結論とまとめ
Alessandro Ricci: Pierfrancesco、今日はIvecoと一緒に登壇できて光栄でした。Marco、あなたのサポートにも感謝します。本日のセッションに参加された皆様に感謝いたします。また、日々の熱意を持ってこれらの結果を達成するために働いている人々にも特別な感謝を捧げます。
今日の発表では、Iveco GroupとAWS Professional Servicesがどのように協力して革新的なソリューションを構築してきたかを紹介しました。主要な成果として、まず「バーチャルエンジニアリングワークベンチ（VEW）」により、開発環境のセットアップ時間を95%削減し、ソフトウェア開発チームの効率を30%向上させることができました。
次に、「スマートナレッジマネジメント」システムでは、情報検索時間を90%削減し、新たな検索数を50%増加させることに成功しました。さらにドキュメント内のミスを40%削減し、文書作成コストを50%削減するという成果も得られました。
最後に、「TEDDI（Technical Drawing Data Interpretation）」という技術図面解析ツールでは、技術図面からの情報検索時間を大幅に削減し、検索数を増加させ、技術文書のミスを減らすと同時に、新規部品番号の管理やコンポーネント設計における大幅なコスト削減を実現しました。
これらの取り組みは、AWSとIveco Groupの継続的な協力関係の強さを示すものであり、ソフトウェア定義車両の開発、知識管理、生成AIを活用した業務自動化など、幅広い分野でのデジタルトランスフォーメーションを実現しています。