※本記事は、AWS re:Inventで発表されたBMWのケーススタディに関する動画「BMW speeds car development with a new app for defect ticket routing (PRO201)」の内容を基に作成されています。動画はYouTubeの公式AWSチャンネルでご覧いただけます（https://www.youtube.com/watch?v=ScTLkWMKfIs ）。本記事では、動画の内容を要約・構造化しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。AWS re:Inventの詳細情報はhttps://go.aws/reinvent で、その他のAWSイベント情報はhttps://go.aws/3kss9CP でご確認いただけます。
1. イントロダクション
1.1 登壇者の紹介
- Kim Robins: Generative AI Innovation Centerのシニア AI戦略専門家。BMW社との生成AI採用に関する取り組みを過去2年間にわたって主導しています。
- Oskar: Generative AI Innovation Centerのシニア Applied Scientist。技術面での専門知識を提供し、BMWの生成AIソリューション開発に携わっています。
- Jens: BMWのChief Cloud Architect。BMW社の技術戦略とクラウド基盤を担当し、同社のソフトウェア開発と生成AI導入を推進しています。
1.2 Generative AI Innovation Centerと BMW社の協力関係
Kim Robins：Generative AI Innovation Centerは、BMW社と過去2年間ほど集中的に協力してきました。私たちはBMW社の生成AI技術の採用をサポートしてきました。BMW社には革新的な企業としての長い歴史があり、それは生成AIへのアプローチにおいても同様です。今日は、チケット管理システムについてお話しますが、皆さんも経験があるかもしれませんね。チケットを提出したのに、期待通りに処理されなかったという経験はありませんか？そうした問題に生成AIがどう役立つかをお話ししたいと思います。
Jens：これからお話しする内容は、BMWが目指しているプレミアム体験の提供に関わるものです。走行体験に関しては、BMW車を運転された方なら違いがわかるでしょう。しかしデジタルサービスに関しては、少し難しい部分があります。Well-Architected Frameworkなどの基本的な要素はもちろん必要ですが、それだけでは差別化できません。私たちがどのようにして複数のサービスを組み合わせてプレミアムなデジタルサービスを構築しているのか、実例をお見せしましょう。これから説明する領域こそ、私たちが開発しているもので、そこからチケットが生成されるのです。
Kim Robins：私たちのコラボレーションでは、BMWが生成AIをどのように活用できるかを共に模索してきました。BMWは常にテクノロジーの最前線に立つ企業として知られていますが、生成AIの活用においてもその姿勢は変わりません。今回のプロジェクトでは、車両開発における欠陥チケットの処理という具体的な課題に取り組み、いかに生成AIがこのプロセスを改善できるかを実証しています。
Jens：そうですね。私たちBMWとGenerative AI Innovation Centerとの協力は非常に実りあるものでした。私たちは単に技術を導入するだけでなく、実際のビジネス価値を生み出すことに焦点を当てています。この協力関係があったからこそ、私たちの開発プロセスの中でも特に重要なチケット処理システムという領域で、生成AIの可能性を探ることができました。
1.3 BMWの革新的企業としての歴史
Jens：BMWは革新的な企業として長い歴史を持っており、生成AIへのアプローチにおいてもその伝統は変わりません。私たちは40年以上にわたり社内でソフトウェア開発を行ってきました。もちろん、現在のような規模ではありませんでしたが、運転支援システム、インジェクション、パワートレインなど、車の中核機能に関わるソフトウェアを自社で開発してきた実績があります。
Kim Robins：BMWは常に業界の最先端を走る企業として知られていますね。私が特に印象的だと感じるのは、新しい技術に対して常にオープンな姿勢を持ち、積極的に取り入れようとする企業文化です。生成AIの採用においても、他社に先駆けて可能性を模索し、実際のビジネス課題解決に活かそうとする姿勢が見られます。
Jens：そうですね。現在、BMWでは約12,000人の社内開発者が働いており、日々140,000回のビルドを実施しています。開発したソフトウェアは年間平均5台の新車に実装されるだけでなく、先ほど触れたアップグレード可能性によって、すでに販売済みの車両にも提供されています。このような大規模な開発体制とソフトウェア更新の仕組みが、私たちの革新を支える基盤となっています。
Oskar：BMWの革新性は、単に新しい技術を導入するだけでなく、それを実際のユーザー体験の向上にどう結びつけるかという点にも表れていますね。今回の生成AIプロジェクトにおいても、技術そのものよりも、それによってどのようにチケット処理プロセスを改善し、最終的に車両開発を加速できるかという実用面に焦点が当てられています。これは、革新的であると同時に実用的であるというBMWの企業姿勢を象徴していると思います。
2. BMWのプレミアムデジタルサービス
2.1 「Connected」 - クラウドと車両の連携
Jens：BMWが目指しているのは、プレミアム体験の提供です。走行体験については比較的簡単です。BMWの車を運転すれば、その違いを実感していただけるでしょう。一方、デジタルサービスについては、少し複雑です。AWSのWell-Architected Frameworkなどの基本的な要素はもちろん必須ですが、サービスの可用性確保だけでは差別化できません。ここでは、私たちがどのように複数のサービスを組み合わせてプレミアムなデジタルサービスを構築しているかをご説明します。
私たちは「Connected（接続性）」を持つサービスをプレミアムと考えています。「Connected」とは、車両がクラウドと連携して、車両単体よりも優れた体験を提供することを意味します。その規模を示す指標として、現在BMWには2300万台の完全接続された車両があり、AWSでホストされている私たちのバックエンドは毎日140億件のリクエストを処理しています。
「Connected」の具体例としては、ドライバーにリアルタイムの交通情報を表示するケースが挙げられます。例えば、渋滞の少ない道路を案内するために、バックエンドからデータを取得して車内の機能を強化しています。このように、バックエンドからデータを取得して車内の機能を拡張することで、運転体験を向上させているのです。
Kim Robins：その「Connected」機能は、単なる情報表示以上の価値をドライバーに提供していますね。リアルタイムデータと車両システムの連携によって、ドライバーは状況に応じた最適な判断ができるようになります。
Jens：そうです。「Connected」は私たちのデジタルプレミアム戦略の基盤となる要素なのです。車両とクラウドの間でシームレスな情報交換が行われることで、常に最新かつ最適な情報をドライバーに提供することができます。そして、この接続性があってこそ、次に説明する「Smart」などの他の要素も実現できるのです。
2.2 「Smart」 - ローカルハザード警告などのスマートサービス
Jens：「Smart」は私たちのプレミアムデジタルサービスの次の要素です。これもある意味で記念すべき内容なのですが、約10年前に私たちが初めてre:Inventに参加した際に紹介したサービス「Local Hazard Preview Warning（ローカルハザード予告警告）」がこの「Smart」サービスの好例です。これは、前方に危険がある場合に適切なタイミングでドライバーに警告を表示するサービスです。
これも「Connected」と同様のアプローチで実現しています。車内の機能がデータをバックエンドに送信し、それが処理された後にドライバーに戻されて「前方に霧などの危険がある」といった警告が表示されます。車両から収集された情報がクラウドで処理・分析され、その結果が他のドライバーの役に立つという循環を作ることで、単独の車両だけでは実現できない「スマート」な機能を提供しているのです。
Kim Robins：つまり、個々の車両が単なるデータの受信者ではなく、ネットワーク内での情報提供者にもなっているわけですね。車両ネットワーク全体での情報共有によって、各ドライバーがより広範な状況認識を得られる仕組みになっています。
Jens：まさにその通りです。各BMW車両が検知した危険情報をクラウドに集約し、それを他のドライバーに提供することで、BMW車両のネットワーク全体の安全性が高まります。「Smart」は単なる機能ではなく、接続された車両の集合知を活用したサービスなのです。これこそが私たちの考えるプレミアムデジタルサービスの重要な要素の一つです。
Oskar：この「Local Hazard Preview Warning」は、生成AIを活用した今回のプロジェクトとも共通する特徴を持っていますね。データを収集し、処理し、それを適切なタイミングで関連するユーザーに提供するという基本的なアプローチは、チケット処理システムの改善にも応用できる考え方です。
2.3 「Assisted」 - 運転支援機能
Jens：「Assisted（支援）」も私たちのプレミアムサービスの重要な要素です。これは運転をより便利に、より良い体験にするために役立つ多くの機能を含んでいます。特に代表的な例として「Autobahn Pilot（アウトバーンパイロット）」が挙げられます。
高速道路で高速走行が可能な国では、このサービスは非常に便利です。なぜなら、安全に追い越しを行うのを支援してくれるからです。アウトバーンのような制限速度の高い道路では、追い越しの判断が難しい場面もありますが、このシステムがドライバーの安全な判断をサポートします。
Kim Robins：その「Assisted」機能は、ドライバーの負担を軽減しながらも、彼らのコントロールを奪わないバランスが重要だと思います。完全な自動運転ではなく、ドライバーの判断を支援するというアプローチですね。
Jens：おっしゃる通りです。私たちは常に「ドライバーを支援する」という考え方を基本にしています。車両が判断を下すのではなく、ドライバーがより良い判断を下せるように必要な情報と補助を提供するというものです。運転の楽しさを維持しながら安全性と快適性を高めるために、このような支援機能は不可欠だと考えています。
Oskar：この「支援」という考え方は、私たちが開発している生成AIを使ったチケット処理システムにも共通していますね。システムがすべてを自動化するのではなく、人間の判断を支援し、より良い決定ができるようにサポートするという哲学です。
2.4 「Integrated」 - デジタルエコシステムとの統合
Jens：「Integrated（統合）」は、私たちが昨年のre:Inventでも紹介した要素です。これは、BMWの車両をお客様のデジタルエコシステムに統合するという取り組みです。例えば、あなたのSpotifyアカウントを車内で利用できるようにしたり、画像でご覧いただけるように、7シリーズでは業界で唯一Amazon Fire TVを後部座席に提供しています。
これにより、お客様は車内でも普段使用しているデジタルサービスをシームレスに利用できるようになります。車が単なる移動手段ではなく、お客様のデジタルライフの延長線上にあるよう設計しているのです。
Kim Robins：その統合アプローチは、車を単なる「移動のための機械」から「生活空間の一部」へと変える重要な転換点ですね。特に長時間車内で過ごすユーザーにとって、その価値は大きいと思います。
Jens：まさにその通りです。現代の消費者は、使い慣れたデジタルサービスをどこでも利用したいと考えています。家庭でも、オフィスでも、そして車内でも同じ体験を期待しています。BMWはそのギャップを埋めることで、より一貫性のある快適なユーザー体験を提供しています。Amazon Fire TVの統合は、その最たる例です。長距離移動中でも、お気に入りのコンテンツをお楽しみいただけます。
Oskar：この「統合」の考え方は、異なるシステム間でのデータや機能の連携を重視している点で、私たちのチケット処理システムにも通じるものがありますね。異なるソースからの情報を統合して、より価値のある視点を提供するという点では共通しています。
2.5 「Upgradeable」 - 継続的なアップデート
Jens：最後に触れたいのは「Upgradeable（アップグレード可能）」という要素です。私たちは900万台以上の車両に対して、新機能を含む継続的なアップデートを提供する能力を持ち、実際に実施しています。例えば、AIベースの機能についても同様です。
BMWから車を購入すると、新機能を含む継続的なアップデートを受け取れるのです。これらの基準をすべて組み合わせたものが、私たちが考えるデジタルプレミアムサービスです。そして、これらすべての鍵となるのは、車両内およびクラウド上でホストされるソフトウェアです。今日お話しするチケット処理に関わるのは、まさにこのソフトウェアなのです。
Kim Robins：この「Upgradeable」の概念は非常に重要ですね。従来の車は購入時の機能が固定されていましたが、BMWの場合は時間とともに進化し続けるプラットフォームを提供しているわけです。
Jens：そうです。現代の消費者は、スマートフォンやコンピュータなど他のデジタル製品と同様に、車もアップデートによって進化し続けることを期待しています。私たちはこの期待に応えています。車の寿命は一般的なデジタル製品よりも長いため、この「Upgradeable」の要素は特に重要です。購入から数年経っても、最新の機能や改善を受け取れるというのは、お客様にとって大きな価値です。
Oskar：この継続的改善のアプローチは、私たちが開発しているAIシステムにも通じるものがありますね。初期のソリューションだけでなく、使用されるにつれて学習し、進化していくシステムを設計するという点で共通しています。フィードバックループを通じて継続的に改善していくという考え方は、ソフトウェア開発の現代的なアプローチを象徴していると思います。
3. BMWのソフトウェア開発の概要
3.1 40年以上の社内ソフトウェア開発の歴史
Jens：BMWでは40年以上にわたって社内でソフトウェア開発を行ってきました。もちろん、現在のような規模ではありませんでしたが、運転支援システム、インジェクション、パワートレインなど車の基本機能に関わるソフトウェアを自社で開発してきた長い歴史があります。
私たちの社内開発の歴史は車両の電子制御が始まった初期の頃から続いています。当初は比較的シンプルなシステムでしたが、車両の電子化が進むにつれて、ソフトウェア開発の規模と複雑さも増してきました。このような長い歴史があるからこそ、現在の大規模なソフトウェア開発体制を構築することができたのです。
Kim Robins：40年という長い期間にわたってソフトウェア開発を続けてきたということは、BMWには膨大な知識と経験が蓄積されているということですね。それが今日の高度なシステム開発の基盤になっていると思います。
Jens：おっしゃる通りです。この長年の経験が、私たちの強みになっています。内製化によって培ったノウハウがあるからこそ、外部パートナーとの協業においても、何が必要で何が可能かを的確に理解し、指示することができます。また、車両のソフトウェアは単なるIT製品とは異なり、物理的な制約や安全基準など、自動車特有の要件を満たす必要があります。その点でも、長年の経験が役立っています。
Oskar：ハードウェアとソフトウェアが密接に結びついた自動車という製品において、40年にわたる社内開発の経験は非常に貴重な資産ですね。この知識の蓄積が、新しい技術の導入においても適切な判断をするための基盤になっていると感じます。
3.2 現在の開発規模（12,000人の開発者、140,000の日次ビルド）
Jens：現在のBMWのソフトウェア開発規模についていくつかの指標をご紹介します。現在、BMWでは約12,000人の社内開発者が働いています。この大規模な開発チームは日々140,000回ものビルドを実施しており、その規模の大きさがお分かりいただけると思います。
開発されたソフトウェアは平均して年間5台の新車に搭載されますが、それだけではありません。先ほど触れたアップグレード機能により、既にお客様が購入された車両にも新しいソフトウェアが提供されます。つまり、開発したソフトウェアの影響範囲は新車だけでなく、既存のフリートにも広がるのです。
Kim Robins：その規模は本当に印象的ですね。日々140,000回のビルドというのは、絶え間ない開発活動が行われていることを示しています。そして、新車だけでなく既存車両にもアップデートを提供するというモデルは、ソフトウェア開発の影響範囲を大きく拡大していますね。
Jens：その通りです。この規模でソフトウェア開発を行っているからこそ、様々な課題も出てきます。特に今日お話しするチケット処理の問題は、この大規模な開発体制の中で重要な課題となっています。多くの開発者が関わり、様々なコンポーネントが連携する中で、問題が発生したときに適切なチームに確実に伝えることが非常に重要になるのです。
Oskar：このような大規模開発環境では、コミュニケーションや調整が非常に複雑になりますね。12,000人もの開発者が関わるプロジェクトでは、効率的な情報伝達と問題解決のプロセスが不可欠です。まさにそのような環境で生成AIが力を発揮できる領域だと思います。
3.3 インフォテインメントシステムの開発フロー
Jens：チケットがどのように生成されるかを理解していただくために、特に多くのチケットが発生するインフォテインメント領域の開発フローについてご説明します。基本的には大きな漏斗のような形で考えてください。この漏斗の左側ほど、完全にスケーラブルで自動化可能なプロセスになっています。
まず、私たちの12,000人の開発者はソフトウェアの開発とテストを開始します。誰もが行うように、CI/CDの一部として単体テストと統合テストから始めます。次に「ソフトウェア・イン・ザ・ループ」と呼ばれる段階があります。これはゲーマーの方なら理解しやすいかもしれませんが、PCでスーパーファミコンなどをエミュレートするのと基本的に同じ原理です。PCやクラウド上のEC2インスタンスの中で、ソフトウェアスタック全体をエミュレートする能力を持っています。
これらのテストがすべて通過すると、初めて実際のコンポーネントに移ります。私たちが特に誇りに思っているのは「クラウド内のヘッドユニット」です。これはAWSと共同で開発し、昨年のre:Inventで発表したものですが、EC2インスタンスを使用してAndroidベースの制御ユニットをクラウド内でネイティブに実行する能力を持っています。私の知る限り、これは業界初の取り組みで、開発のスケーリングにも役立っています。
Kim Robins：それは革新的なアプローチですね。物理的なハードウェアに依存せずに開発できるということは、大きな効率化につながりますね。
Jens：その通りです。これらのテストが機能すると、初めて実際のハードウェアに移ります。写真でご覧いただけるように、インフォテインメントデバイスは多くのケーブルと機器を備えています。これが機能し、すべてのテストがパスすると、次にサブシステムに移ります。これはエンドツーエンドのテスト環境であり、クラウドと連携するインフォテインメントシステムを意味します。ここで初めて、音が正しく機能するか、車両への音声コマンドが機能するかなどをテストできます。
サブシステムがうまく機能すれば、「フルクラスター」をテストします。これはドライバーとして見る完全なインフォテインメント環境で、ステアリングホイールやコンビネーションメーターなども含まれます。そして、これらのテストが機能した後にようやく、実際の車両でのテストに進みます。
ご覧のように、左側の工程は完全に自動化可能で高度にスケーラブルですが、右側の工程は車両内での作業となるため、スケーラビリティが限られます。開発者やテスター、関係者が何か不具合、失敗、または単にお客様の期待に応えられないと判断した場合、チケットが発行されるのがこのプロセスの中なのです。
Oskar：このような複雑な開発フローにおいて、問題が発生した際に適切な情報とともにチケットを作成し、正しいチームに振り分けることの重要性がよくわかりますね。特に物理的なテストフェーズに入ると、問題の特定と適切なフィードバックがより難しくなります。
Jens：その通りです。これは私たちがなぜチケット処理の最適化が重要だと考えるかの理由の一つです。開発プロセスの各段階で発生する問題は、その性質も解決方法も大きく異なります。そのため、チケットの質と効率的な処理が、全体の開発スピードに大きな影響を与えるのです。
4. チケット処理における課題
4.1 チケット品質の一貫性の欠如
Jens：Kim が最初に質問したように、皆さんもチケットに関する問題を経験したことがあるでしょう。ここから、私たちが直面する具体的な問題についてご説明します。まず、チケットの品質に一貫性がないという問題があります。先ほどお見せした開発フローの漏斗を考えてみてください。ソフトウェア開発者は、車両でテストする人とはまったく異なる視点でコンポーネントやソフトウェアを理解しています。
これは、チケットの情報にギャップが生じる良い例です。開発の初期段階でチケットを作成する開発者は、コードレベルの詳細な情報を提供できますが、最終的な車両テスト段階でチケットを作成するテスターは、ユーザー体験の観点からの問題を報告します。この違いにより、チケットの品質と詳細さに大きな差が生じるのです。
Kim Robins：そうですね。開発プロセスのどの段階で誰がチケットを作成するかによって、提供される情報の性質が大きく異なるということですね。これは、チケット処理において最初の大きな課題となります。
Jens：まさにその通りです。もう一つの問題は、誰が責任を持つべきかという点です。問題を発見した場合、それは私が見た機能が原因なのか、それとも別の機能が原因なのか、判断が難しいケースがあります。このような責任の所在の不明確さも、チケット処理において大きな課題となっています。
Oskar：その問題は、複雑に絡み合ったソフトウェアコンポーネントが多数存在する現代の車両では特に顕著ですね。一つの表面的な問題の背後に、複数のコンポーネントの相互作用が関係している可能性があります。チケットを作成する人にとって、真の原因を特定することは非常に難しいと思います。
Jens：その通りです。これがまさに、生成AIを活用することで解決したい課題の一つなのです。AIが複雑な相互関係を理解し、表面的な症状だけでなく潜在的な原因に基づいてチケットを適切に分類し、振り分けることができれば、大きな効率化が図れると考えています。
4.2 責任の所在の不明確さ
Jens：チケット処理における次の大きな課題は、責任の所在の不明確さです。チケットを発行する際、問題の原因となっている機能や責任を持つべきチームを特定することが困難な場合があります。私が問題を発見したとき、それは私が見ていた機能によるものなのか、それとも別の機能が原因なのか、判断が難しいケースが少なくありません。
特にインフォテインメントシステムのような複雑な領域では、一つの問題が複数のコンポーネントや機能の相互作用から生じることがあります。その場合、チケットを作成する人は責任を持つべきチームを正確に特定できないため、チケットが適切でないチームに送られてしまうことがあります。
Kim Robins：これは企業環境では非常によく見られる問題ですね。責任の所在が不明確だと、チケットが複数のチーム間でたらい回しにされ、解決までに時間がかかってしまいます。また、最終的に担当チームに届いたときには、問題の詳細が十分に伝わっていないケースもあるのではないでしょうか。
Jens：まさにその通りです。特に私たちのようにソフトウェアチームが140以上もある環境では、この問題は一層複雑になります。チケットが正しいチームに届かないと、解決が遅れるだけでなく、開発者のリソースも無駄になります。適切でないチームが時間をかけて問題を調査し、結局は「これは私たちの担当ではない」という結論に至るケースが少なくないのです。
Oskar：これは生成AIが非常に役立つ領域ですね。AIはチケットの内容を深く理解し、過去の類似事例や問題解決パターンに基づいて、最も適切なチームを推奨することができます。そして、実際のチケットルーティングの分析から学習し、時間とともに精度を向上させることができるのです。
4.3 隠れた依存関係の把握の難しさ
Kim Robins：もう一つの大きな課題は、隠れた依存関係の存在です。企業環境では、エラーが発生する原因となる多くの他のデータソースや依存関係が存在しています。私たちはこれらの隠れた依存関係を明らかにして、チケット解決をより迅速に行えるようにする方法を考えたいと思いました。
例えば、あるインフォテインメント機能の問題が報告された場合、それはUI層の問題のように見えるかもしれませんが、実際にはバックエンドの通信プロトコル、ミドルウェア、あるいは全く別のサブシステムとの相互作用に起因している可能性があります。こうした依存関係はチケット作成者には見えていないため、チケット情報だけでは問題の本質を捉えられないことがあります。
Jens：そうですね。特に私たちのような大規模なシステムでは、コンポーネント間の関係が非常に複雑です。一つの機能が複数のサブシステムに依存していることも珍しくありません。しかし、各開発者やテスターは自分の担当領域についての知識は深くても、システム全体の相互関係を把握している人は限られています。
Oskar：この点が、生成AIが特に価値を発揮できる部分です。大量の履歴チケットデータやドキュメント、コードリポジトリなどの情報源から学習することで、AIはこれらの隠れた依存関係をより効率的に特定できる可能性があります。人間がすべての関係性を記憶し分析するのは困難ですが、AIならば膨大なデータから関連パターンを見出すことができます。
Kim Robins：まさにその通りです。私たちのアプローチでは、チケット情報だけでなく、ログデータ、コードドキュメント、そしてコード分析などから追加のコンテキストを提供することで、開発者が問題の全体像をより迅速に把握できるようにしています。このように、様々なデータソースからの情報を統合することで、隠れた依存関係を明らかにし、より効率的な問題解決を実現したいと考えています。
4.4 重複チケットの問題
Kim Robins：そして、すべての問題の中で最も厄介なのは重複チケットの問題です。同じ作業を2回目、3回目、あるいは4回目にもう一度行わなければならないほど、チケットシステムに問題が重複して現れてしまうことほどフラストレーションがたまることはないと思います。早い段階で重複として特定されなかったために、同じ問題に対して複数回の対応を強いられるのです。
これは開発者の時間を無駄にするだけでなく、チケット処理システム全体の効率を下げる要因となります。例えば、同じバグに対して5つの異なるチケットが作成され、それぞれ異なるチームに回された場合、5つのチームが同時に同じ問題に取り組むことになります。結果として、リソースの無駄遣いとなるだけでなく、解決策の調整も複雑になります。
Jens：そうですね。特に私たちのような大規模な開発環境では、これは大きな課題です。140以上のソフトウェアチームが存在し、開発のさまざまな段階で問題が発見される可能性があるため、同じ問題に対する重複チケットが生成されることがよくあります。
例えば、あるチームが単体テスト中に問題を発見してチケットを作成し、同時に別のチームが統合テスト中に同じ問題を発見して別のチケットを作成するというケースです。これらのチケットは異なる言葉で記述され、異なる視点から問題を説明しているため、人間の目では関連性を見つけるのが難しい場合があります。
Oskar：この重複チケットの検出こそ、私たちが生成AIを活用して最初に解決したいと考えた問題です。大規模言語モデルは、表面的な表現の違いを超えて、問題の本質的な類似性を識別する能力を持っています。さらに、多言語でのチケット比較も可能なため、国際的な開発環境でも効果を発揮します。
Kim Robins：その通りです。重複チケットを早期に特定することで、開発者が同じ問題に繰り返し取り組む無駄を省き、リソースをより効率的に活用できるようになります。また、関連するすべてのチケット情報を一箇所に集約することで、問題に関するより包括的な理解も得られます。これは私たちのソリューションで重点的に取り組んだ領域の一つです。
5. ユーザージャーニーの分析
5.1 チケット作成プロセスの課題
Kim Robins：私たちはユーザーの視点からこのジャーニーがどのように見えるかを考え、二つの領域に分けて考えました。一方ではチケット作成プロセス、もう一方ではチケットの振り分けプロセスがあります。
例えば、私自身が最近の業務の一環で非常に詳細なチケットを作成しなければならない経験をしました。異なるシステムから情報を収集し、データ品質基準を満たすために、チケット提出プロセスを5回も繰り返さなければなりませんでした。これは非常に時間がかかり、フラストレーションが溜まる体験でした。
このような体験は多くの企業環境で共通しています。チケットを作成する人は、問題を報告するためにさまざまなシステムから情報を集めなければならず、必要なフィールドをすべて正しく埋めなければなりません。さらに、データ品質の基準を満たすため、何度も提出を試みることが必要な場合もあります。
Jens：その通りです。私たちのBMWの環境では、140以上のソフトウェアチームがあり、それぞれが異なる要件や期待を持っています。チケット作成者は、どの情報が特定のチームにとって重要なのかを必ずしも理解していませんし、すべてのチームの要件を満たすために十分な詳細情報を提供することは困難です。
Oskar：また、チケット作成者の役割や専門知識によっても、提供される情報の質や詳細さが大きく異なります。例えば、開発者は技術的な詳細を多く提供できますが、テスターや品質保証チームのメンバーは、ユーザー体験の視点からの情報を提供する傾向があります。
Kim Robins：そうですね。私たちが検討したのは、チケット作成プロセスをどのように改善できるかという点です。チケット作成者の負担を軽減し、同時に必要な情報がすべて含まれるようにするにはどうすればよいか。また、チケットが解決プロセスを加速するためにどうすればよいか。これらの点について、生成AIを活用した解決策を模索しました。
5.2 チケット振り分けプロセスの課題
Kim Robins：チケット作成過程の問題に加えて、チケットが提出された後の振り分けプロセスにも課題があります。これには最終的に対応する開発者だけでなく、チケットを適切なチームに振り分ける過程全体が含まれています。チケットに正しい情報が含まれているか確認し、情報を改善する方法を考える必要があります。
チケット作成者が入力する情報と開発者が必要とする情報の間には、Jensも言及したように大きな差があります。私たちはこの差を埋め、より良い成果を得られるようにしたいと考えています。
通常のチケット処理の流れを考えてみると、多くの課題が見えてきます。まず、チケットに含まれる情報とより広いエコシステム全体に存在する情報から、より良く簡潔な情報を表示する方法はないかと考えました。またチケットの品質を高め、必要な情報を自動的に補完することも重要です。
Jens：具体的には、チケットが正しいチームに振り分けられるかどうかが大きな課題です。140以上のソフトウェアチームがある環境では、どのチームが特定の問題に対応すべきかを判断するのは簡単ではありません。間違ったチームにチケットが送られると、そのチームがチケットを分析し、「これは私たちの担当ではない」と判断するまでに時間がかかります。その後、別のチームに転送され、このプロセスが繰り返されることもあります。
Kim Robins：私たち全員が経験したことのある問題だと思います。チケットを提出したものの、間違ったチームに送られ、正しいチームに届くまでに1日かかるようなケースです。その後、フォローアップが必要になることもあります。これはチケット作成者、処理者、そして最終的に解決する人々すべてにとってフラストレーションの原因となります。
Oskar：また、チケットの振り分け担当者は、通常、知識を一歩ずつ掘り下げていくアプローチを取ります。しかし生成AIを活用すれば、すべてのデータを一度に処理し、次に何をすべきかについてより的確な推奨を行うことができます。これによりチケット処理者は、関連するチケットとその次のステップについて、より簡潔で理解しやすい情報を得ることができます。
Kim Robins：そうですね。私たちのゴールは、チケット振り分けプロセスをより効率的に、そして正確にすることです。正しい情報を持つチケットが最初から適切なチームに届けば、解決までの時間を大幅に短縮でき、開発者のリソースも効率的に活用できるようになります。
5.3 改善のための重点領域
Kim Robins：私たちはBMWと協力して、チケット処理プロセスを改善するための重点領域を特定しました。まず、チケットとそこに含まれるデータの要約を提供することが重要だと考えました。チケットに入力された情報と、より広範なエコシステムに存在する情報から、より良い簡潔な情報を提示する方法を模索しています。
また、チケットの品質を高めることと、必要な情報を自動的に補完することも重要です。皆さんも経験があると思いますが、チケット作成時にはドロップダウンボックスから追加情報を選択したり、どのチーム、部門、問題領域に関連するかを判断したりする必要があります。こうした情報をより自動的に補完できないかと考えています。
Jens：そうですね。チケットの質を向上させることは、単に形式を整えるだけではなく、内容の一貫性と完全性を確保することも意味します。例えば、テスト中に発見された問題を報告する場合、どのテスト環境で、どのソフトウェアバージョンで、どのような条件下で問題が発生したのかという情報が重要です。しかし、これらの情報が常に一貫して提供されるわけではありません。
Kim Robins：さらに、通常はチケットシステムからは隠れている他のデータソースからの追加コンテキストを提供することも重要だと考えています。BMWの場合、これにはログデータ、コードドキュメント、コード分析などが含まれます。これらの情報を統合して、開発者が最終的にチケットを受け取った際に、より有用な情報を提供できるようにします。
Oskar：また、重複チケットの検出も重要な改善領域です。同じ問題に関する複数のチケットを早期に特定することで、開発リソースの無駄を減らすことができます。生成AIの意味理解能力を活用すれば、表面的な記述の違いを超えて、本質的に同じ問題を特定することが可能になります。
Kim Robins：最終的には、これらすべての改善が、チケットを適切なチームに振り分けるというゴールにつながります。正しい情報と十分なコンテキストを持つチケットが、最初から適切なチームに届けば、解決までの時間を大幅に短縮できるのです。これらの重点領域に取り組むことで、BMWのチケット処理プロセス全体を効率化し、開発者の生産性向上につなげることを目指しています。
6. 解決策の4つの柱
6.1 チケット品質の向上
Kim Robins：BMWと協力する中で、私たちは4つの柱に焦点を当てた解決策を設計しました。最初の柱は、チケット品質の向上です。これは多くの企業にとって共通の課題だと思います。チケットの品質を高めることで、問題解決のプロセス全体が効率化されます。
具体的には、チケットの一貫性と完全性を確保することを目指しています。チケットには、問題の詳細な説明、再現手順、環境情報、影響の範囲など、問題解決に必要な情報が漏れなく含まれている必要があります。しかし、チケット作成者によって提供される情報の質と量には大きなばらつきがあります。
Jens：その通りです。例えば、開発の初期段階でチケットを作成する開発者は、コードレベルの詳細な情報を提供できますが、車両テスト段階でチケットを作成するテスターは、ユーザー体験の観点からの問題を報告します。この違いにより、チケットの品質と詳細さに大きな差が生じるのです。
Oskar：私たちのアプローチでは、生成AIを活用してチケット内容を分析し、足りない情報や矛盾点を特定します。また、過去の類似チケットから学習したパターンを基に、より完全で一貫性のあるチケット情報を生成することができます。
Kim Robins：さらに、チケットの要約生成も重要な機能です。長文の問題説明や技術的な詳細を、簡潔でわかりやすい要約に変換することで、チケット処理担当者がより迅速に問題の本質を理解できるようになります。また、専門用語や略語の説明、多言語チケットの翻訳なども、チケット品質向上に貢献します。
Jens：チケット品質の向上は、単にチケット自体の改善にとどまらず、問題解決プロセス全体の効率化にもつながります。質の高いチケットは正しいチームに振り分けられやすく、解決までの時間も短縮されるのです。
6.2 重複チケットの検出
Kim Robins：次の柱、そしてBMWにとって特に重要だったのは、重複チケットの検出です。開発者が同じ作業を繰り返し行うという無駄を減らし、彼らの時間を何度も同じ問題に費やさないようにすることが目的です。そのため、私たちはチケット処理プロセスの最初のステップとして、この問題を解決することに注力しました。
同じ問題に対して複数のチケットが作成されると、それぞれが異なるチームに割り当てられる可能性があります。これにより、複数のチームが同時に同じ問題に取り組むことになり、リソースの無駄使いとなります。また、解決策の調整も複雑になります。重複を早期に検出することで、これらの問題を防ぐことができます。
Jens：特に私たちのような大規模な開発環境では、同じ問題が開発プロセスの異なる段階で発見される可能性が高いです。例えば、単体テスト中に一つのチームが問題を発見し、別のチームが統合テスト中に同じ問題を発見するといったケースです。これらのチケットは異なる表現で記述されているため、人間の目では関連性を見つけることが難しい場合があります。
Oskar：私たちの解決策では、大規模言語モデルの意味理解能力を活用して、表面的な表現の違いを超えた本質的な類似性を特定します。チケットの内容、問題の発生状況、影響範囲などの要素を考慮して、既存のチケットとの類似性を分析します。
さらに、多言語でのチケット比較も可能です。BMWのような国際的な企業では、異なる言語でチケットが作成されることがあります。私たちのシステムは言語の違いを超えて、同じ問題を特定することができます。
Kim Robins：重複検出のプロセスでは、まず新しいチケットと過去のチケットの両方からベクトル表現を生成し、意味的な類似性に基づいて検索を行います。これにより、表現方法や使用言語が異なっていても、本質的に同じ問題を特定することができます。検出された潜在的な重複に対しては、その理由も含めて提示することで、最終判断を行う人間がより適切な決定を下せるようサポートします。
Jens：この重複チケット検出によって、開発者は同じ問題に繰り返し取り組む必要がなくなり、新たな課題に集中できるようになります。これは、私たちが最も価値を感じている改善点の一つです。
6.3 追加インサイトの発見
Kim Robins：3つ目の柱は、追加インサイトの発見です。先ほども触れましたが、企業環境では多くの場合、エラーの原因となる隠れた依存関係や関連情報が存在します。私たちはルート原因分析やログ、過去のチケットなどから追加のコンテキストを見つけ出し、それを提供することを目指しています。
チケットに記載されている情報だけでは、問題の全容を把握するのに十分でないことがよくあります。例えば、あるエラーが発生した場合、そのエラーログ、関連するシステムコンポーネント、類似の過去の問題とその解決策など、様々な追加情報が存在する可能性があります。
Oskar：私たちのアプローチでは、生成AIを活用して複数のデータソースからこれらの追加情報を抽出し、整理します。例えば、システムログからエラーパターンを識別したり、コードリポジトリから関連するコンポーネントの依存関係を抽出したり、過去の類似チケットから解決策のパターンを学習したりします。
これにより、チケット処理担当者や開発者は、より広い文脈の中で問題を理解することができます。単に「何が」起きているかだけでなく、「なぜ」それが起きているのかについての洞察も得られるのです。
Jens：これは特に複雑なシステムを扱う私たちにとって非常に価値があります。例えば、インフォテインメントシステムの問題が、実は基盤となる通信プロトコルの問題に起因しているということがあります。従来の方法では、そのような関連性を見つけるのは非常に時間がかかりましたが、AIを活用することで、そのプロセスを大幅に短縮できます。
Kim Robins：また、この追加インサイトは単に問題解決を速めるだけでなく、学習と改善のサイクルにも貢献します。同様の問題が繰り返し発生する場合、その根本原因に対処するための戦略的な改善点を特定することができます。これにより、短期的な問題解決だけでなく、長期的な品質向上にもつながるのです。
6.4 適切なチームへのチケット振り分け
Kim Robins：4つ目の柱は、チケットを適切なチームに振り分けることです。これまでに挙げた課題をすべて考慮すると、最終的には正しいチームにチケットを届けることが非常に重要になります。チケットを提出したものの、間違ったチームに送られ、正しいチームに届くまでに1日かかるようなケースを私たちは皆経験したことがあると思います。
これはチケットを作成する人にとっても、処理する人にとっても、そして最終的に解決する開発者にとってもフラストレーションの原因となります。チケットが正しいチームに最初から送られれば、解決までの時間を大幅に短縮できるのです。
Jens：特にBMWのように140以上のソフトウェアチームがある環境では、正確なチケット振り分けは大きな課題です。従来は、チケットを作成した人の判断やシステム内の基本的なルールに基づいて振り分けが行われてきましたが、それが常に正確だとは限りませんでした。
Oskar：私たちの解決策では、生成AIを活用してチケットの内容を深く理解し、過去のチケットデータから学習したパターンに基づいて、最適なチームを推奨します。チケットの説明、発生環境、関連するコンポーネントなど、複数の要素を考慮して判断を行います。
さらに、特定のキーワードや直接的な指示に依存するルールベースのシステムとは異なり、AIは文脈や意味を理解するため、表現が異なっていても同様の問題を適切に分類することができます。
Kim Robins：また、チケット振り分けのプロセスは、通常、知識を一歩ずつ掘り下げていくアプローチを取ります。しかし生成AIを活用すれば、すべてのデータを一度に処理し、次に何をすべきかについてより的確な推奨を行うことができます。これにより、どのチケットが関連しているか、次のステップは何かについて、より簡潔で理解しやすい情報を得ることができます。
Jens：この適切なチケット振り分けによって、開発者は自分の専門領域に関する問題に集中でき、「これは私の担当ではない」と判断するための時間を無駄にすることがなくなります。結果として、問題解決のスピードが上がり、全体の開発効率も向上するのです。
7. Generative AI 活用ソリューションのアーキテクチャ
7.1 データ取り込みの仕組み
Oskar：ここからは、私たちが最初の概念実証（POC）のために構築したソリューションについてお話しします。このPOCの目標は、重複チケットを特定し、ユーザーがより良い判断ができるようにすることでした。まずはアーキテクチャの概要から見ていきましょう。
このアーキテクチャは大きく2つのコンポーネントに分けることができます。まず1つ目がデータ取り込み部分で、これはアーキテクチャ図の上部2/3を占めています。このPOCでは、既存の履歴チケットデータをシステムに取り込むことが非常に重要でした。
まず最初に、チケットを抽出してS3バケットに格納するところから始めました。次のステップでは、Amazon Comprehendを使用して、チケットから個人を特定できる情報（PII）をすべて削除しました。その後、チケットを強化し、プロセス全体で使用したい形式に変換しました。この作業にはAmazon Bedrock上のAnthropic Claude 3.5を使用しました。
次のステップでは、これらのチケットをデータベースに取り込み始めました。ここでいくつかの処理を行いましたが、最初のステップはそのチケットのベクトル表現を作成することです。つまり、チケットのベクトル表現を生成し、それをOpenSearchインデックスに取り込みます。
Kim Robins：この取り込みプロセスは、過去数日間あるいは昨年にもご覧になったかもしれない何かを思い出させるかもしれませんね。これは従来のRAG（Retrieval-Augmented Generation）フレームワークで行うことと非常に似ています。RAGフレームワークをセットアップする場合も、同様にデータをシステムに取り込む必要があります。
Oskar：その通りです。これは重要な学びでもあります。他の場所で見られる概念や、他のユースケースで使用されているフレームワークをどのように活用できるか、そして既に十分にテストされているアーキテクチャをどのように再構築して新しいソリューションに取り入れることができるかを考えることが大切です。
この段階で、すべての履歴チケットがデータベースに取り込まれ、検索可能になっています。次に2つ目のコンポーネント、つまりチケットの検索部分に移ります。これはより本番環境に近い部分で、アーキテクチャの下部に表示されている検索コンポーネントです。
新しいチケットが入ってきたとき、ユーザーはルーティングを行い、必要な対応を特定する必要があります。Lambdaで強化されたバージョンのチケットを作成します。チケットの内容をよりわかりやすくまとめたり、他のソースからの情報を追加したりします。そしてその情報のベクトル埋め込みを作成し、データストアで検索します。ハイブリッド検索を行い、最初のコンポーネントを取得します。
そして、検索で取得したチケットが新しいチケットの重複かどうかを分類します。これがアーキテクチャの大まかな概要です。次に、新しいチケットに対して何が起こるのか、そのフローを詳細に見ていきましょう。
7.2 RAG (Retrieval-Augmented Generation) フレームワークの活用
Oskar：アーキテクチャを見ていただくと、これが非常に伝統的なRAG（Retrieval-Augmented Generation）フレームワークの実装に似ていることがお分かりいただけると思います。RAGは元々、生成AIに外部の知識を効果的に取り込むための手法として知られていますが、私たちはこの考え方をチケット処理システムに応用しました。
通常のRAGフレームワークでは、まず外部データを準備し、埋め込みベクトルを生成して検索可能な形式で保存します。そして、ユーザーからのクエリが来たときに、その意味に基づいて関連情報を検索し、それを基に生成AIが回答を作成します。私たちのチケット処理システムも、基本的に同じ流れに従っています。
Kim Robins：RAGフレームワークを採用することの大きな利点は、既に十分に検証された手法を活用できることです。私たちは一からすべてを設計するのではなく、すでに確立されたパターンを新しいユースケースに適用しました。また、RAGのアプローチにより、生成AIの幻覚（hallucination）問題も軽減できます。チケットの振り分けや重複検出において、具体的な過去データに基づいた判断ができるようになるのです。
Jens：実際にこのアプローチを採用したことで、システムの信頼性と説明可能性が向上しました。例えば、あるチケットが重複だとシステムが判断した場合、なぜそう判断したのかの理由も提示できます。「このチケットはXという特徴とYという特徴が類似しているため重複と判断しました」というように、透明性のある説明が可能になります。
Oskar：RAGフレームワークを活用する上で特に重要なのは、質の高い埋め込みベクトルを生成することです。私たちは初期段階ではオープンソースの埋め込みモデルを使用していましたが、後に説明するように、人間のフィードバックを取り入れることでモデルを微調整し、BMWの特定のコンテキストにより適した埋め込みを生成できるようになりました。
このRAGアプローチは、将来的には単なるチケットだけでなく、ドキュメント、コードリポジトリ、ログデータなど様々な情報源からの知識を統合するための基盤にもなります。これにより、チケット処理に関わるすべての重要情報を一元的に活用できるようになるのです。
7.3 チケット検索・振り分けプロセスの流れ
Oskar：このソリューションは全体で4つの異なるステージから構成されています。これから各ステップについて詳しく説明していきますが、まずは全体の流れを把握していただきたいと思います。
まず最初のステップでは、チケットが入力されると、そのチケットの強化（Enrichment）を行います。このプロセスでは、私たちのケースではClaude Sonnet 3.5を使用していますが、他の様々なLLMも利用可能です。
次に、重複チケットを見つける検索ステップに進みます。これはKimが言及した「知識を掘り下げていく」アプローチの代わりに、すべての情報を一度に表面化させ、特定のチケットに必要な情報だけに絞り込むステップです。この最初のポイントでは、特に他のチケットに焦点を当てています。この段階では10件の候補を表示していますが、さらに拡張も可能です。
ここでは、他のチケットだけでなく、関連する可能性のある他の情報源からのデータも表示することが考えられます。例えば、プロセスに関するドキュメントや、決定に役立つその他の関連情報などです。これが2番目のステップであり、追加情報を取得するステップです。私たちのケースでは、最初の重複候補を特定します。
Kim Robins：この部分が非常に重要です。従来のチケット処理では、担当者が手作業でデータを掘り下げていく必要がありましたが、このアプローチでは生成AIがすべての関連データを一度に処理し、最も重要な情報だけを抽出して提示します。これにより、意思決定プロセスが大幅に効率化されるのです。
Oskar：次に3番目の重要なステップでは、再びLLMに戻り、「これらのペア、つまり新しいチケットとこれらの候補をすべて比較して、これは重複なのかどうか説明してください」と依頼します。ここで分類ステップを行い、各ペアを比較してLLMに「これは重複か、そうでないか」を判断してもらいます。
このタスクを「重複かどうか、はい/いいえ」と単純化することもできますが、私たちはさらに一歩進め、「なぜこれが重複ではないのか」または「なぜこれが重複なのか」という説明ステップを追加しています。これによってエンドユーザーはその情報を適切に判断し、十分な情報に基づいた決定を下すことができます。
Jens：そして最後に、この非常に重要なステップですが、最終的な決定は人間が行います。すべての情報を入手し、検索ステップでそれを絞り込み、LLMによる強化でさらに情報を絞り込んだ後、おそらく2、3件の候補のみが残ります。人間はそれらを見て適切な決定を下すことができるのです。
これは皆さんにも共感していただけると思いますが、「重複チケットがあるかどうか」をすべてのチケットから探すのは非常に困難ですが、2つのチケットを見比べて「これは重複か」と判断するのは比較的簡単で素早くできる作業です。このプロセスによって、その労力を大幅に削減できるのです。
8. ソリューションの詳細ステップ
8.1 チケットの強化（Enrichment）
8.1.1 チケットの要約生成
Jens：Oskarが全体的な流れを説明しましたので、ここからは各ステップの詳細に入っていきます。最初のステップはチケットの強化です。これは単独でも非常に価値のある処理です。なぜなら、先ほど説明したように、チケットがワークフロー・チェーンのどこで発生したかによって、情報量が豊富な場合もあれば不足している場合もあるからです。
私たちが最初に行うのは、チケット全体を解析し、チケットの要約を作成することです。これにより、一目見ただけでチケットが実際に何に関するものなのかを素早く把握できるようになります。チケットの内容を短くまとめることで、処理担当者はすぐに問題の本質を理解できるようになります。
例えば、長くて詳細な技術的な説明があるチケットでも、「インフォテインメントシステムの起動時に音声出力が5秒遅延する問題」というような簡潔な要約に変換されます。これだけで、チケットの分類や振り分けが格段に容易になります。
Kim Robins：この要約生成は非常に効果的ですね。特にBMWのような環境では、技術的な詳細が大量に含まれるチケットも多いと思います。それらの本質を抽出して簡潔に表現することで、誰がチケットを見ても短時間で内容を把握できるようになります。
Jens：その通りです。実際に生成AIを活用した要約機能だけでも、チケット処理プロセスの効率は向上しました。特に複数のチケットを処理する担当者にとって、それぞれのチケットの内容を素早く理解できることは大きな助けになります。
要約生成におけるもう一つの重要な点は、一貫性のある形式で情報を提示できることです。チケット作成者によって記述スタイルや詳細度が異なる場合でも、要約によって標準化された形で情報を得ることができます。これは特に、チケットの分類や振り分けの自動化を進める上で非常に重要な要素です。
8.1.2 頭字語の解消と冗長性の排除
Jens：チケット強化の過程で行う重要な作業の一つが、頭字語（略語）の解消です。なぜなら、チケットを読む人が必ずしもその頭字語が何を意味するのか理解しているとは限らないからです。BMW内でも多くの専門用語や略語が使われていますが、全員がすべての略語を把握しているわけではありません。
例えば、「HU」という略語は「Head Unit（ヘッドユニット）」を意味しますが、別のコンテキストでは異なる意味を持つ可能性もあります。LLMはこのような略語を検出し、その意味を明示的に展開することができます。「HU」を「Head Unit（ヘッドユニット）」に変換することで、チケットの内容がより明確になり、誤解のリスクが減少します。
また、チケットの強化では冗長性の排除も行います。チケット作成者が同じ内容を複数回記述している場合、それを検出して一度だけの記述に整理します。これにより、チケットの読みやすさが大幅に向上します。例えば、問題の説明が複数の箇所で少しずつ表現を変えて繰り返されているようなケースでは、それを一か所にまとめて簡潔に表現します。
Kim Robins：それは非常に価値のある機能ですね。特に大規模な組織では、部門間で同じ概念に対して異なる略語が使われることもあります。それを統一的な表現に変換することで、コミュニケーションの障壁を取り除くことができます。
Oskar：さらに、この処理はLLMを使用することでかなり効果的に実行できます。私たちの実装では、Claude 3.5を使ってこれらの変換を行っていますが、既に非常に良い結果が得られています。LLMはコンテキストを理解した上で適切な展開を行い、チケットの意味を維持しながら不要な重複を削除できるのです。
Jens：この頭字語の解消と冗長性の排除によって、特に異なる部門やバックグラウンドを持つ人々がチケットを処理する際の理解度が大きく向上します。チケットの内容が明確になることで、適切なチームへの振り分けも容易になり、問題解決のプロセス全体が効率化されるのです。
8.1.3 多言語チケットの翻訳
Jens：次のステップとして、私たちは多言語チケットの翻訳に取り組みました。これはBMWのような多国籍企業にとって特に重要です。全員が英語でチケットを書くとは限らないのです。私たちは世界中に生産施設を持っています。中国、ドイツ全土、米国など様々な地域に拠点があり、それぞれの現地言語でチケットが作成されることがあります。
チケットの翻訳機能を実装することで、その言語を理解できない人でもチケットの内容を把握できるようになります。例えば、中国の施設で中国語で書かれたチケットが、ドイツの開発チームに振り分けられた場合、翻訳機能によってドイツのチームはその内容を理解することができます。
Kim Robins：これは国際的なチームで作業する際の大きな障壁を取り除く機能ですね。言語の壁があると、問題の理解だけでなく、適切なチームへの振り分けも困難になります。LLMの多言語能力を活用することで、この問題を効果的に解決できるわけですね。
Oskar：その通りです。現代のLLMは非常に強力な多言語機能を持っています。例えば、ドイツ語で書かれたチケットと英語で書かれたチケットの類似性を検出し、それらが同じ問題を指していると判断できます。これは従来のシステムでは非常に難しかった機能です。
後ほど具体例をお見せしますが、実際に私たちのシステムでは、異なる言語で書かれたチケット間の類似性を特定し、それらが重複であるかどうかを判断できるようになっています。これはグローバルな開発環境において非常に価値のある機能です。
Jens：この翻訳機能により、私たちの開発チームは言語の壁を越えて効率的に協力できるようになりました。チケットの処理速度が向上するだけでなく、国際的なチーム間のコラボレーションも促進されます。特にBMWのように世界中に拠点を持つ企業にとって、これは大きな価値を持つ機能なのです。
8.1.4 データの一貫性向上
Jens：チケットの強化において、非常に重要なステップがデータの一貫性向上です。前述したように、チケットはワークフローのさまざまな段階で作成されるため、その品質や含まれる情報のレベルにばらつきがあります。私たちが目指しているのは、このばらつきを最小限に抑え、一貫性のあるフォーマットでチケット情報を提供することです。
LLMを使ってチケット全体を処理し、より良い品質に変換するために、特定のプロンプトを使用しています。このプロンプトによってLLMはチケットの内容を理解し、必要な情報を整理して標準化されたフォーマットで提示します。例えば、再現手順、影響範囲、関連するコンポーネントなどの情報を一貫した方法で表現します。
Kim Robins：この一貫性の向上は、Kimが後ほど示すように、それ自体が非常に価値のあるものです。チケットのフォーマットが統一されることで、チケット処理担当者や開発者がどのチケットを見ても同じ場所から必要な情報を素早く見つけることができるようになります。
Oskar：また、このデータの一貫性向上は、後続の処理ステップ、特に重複検出や適切なチーム振り分けの精度向上にも大きく寄与します。標準化されたフォーマットのチケットであれば、それらの比較や分析がより正確に行えるからです。
Jens：実際、このデータの一貫性向上だけでも、チケット処理の効率は大幅に改善されました。特に複雑な問題や複数のコンポーネントにまたがる問題の場合、情報が整理されていることで問題の理解が容易になります。さらに、一貫したデータフォーマットは、私たちがこれから構築する機械学習モデルの学習データとしても質の高いものになります。
こうして一連のチケット強化プロセスを通じて、元のチケットから、より質の高い、理解しやすい、処理しやすいチケットへと変換されるのです。これがソリューションの最初のステップであり、以降のすべてのステップの基盤となります。
8.2 重複チケットの検出
8.2.1 キーワード検索
Jens：次のステップは、このプロジェクトの核心部分である重複チケットの検出です。私たちはカスタマイズされたハイブリッド検索を実装しました。まず最初の部分について説明し、その後Oskarに2つ目の部分を説明してもらいます。
最初のステップは非常にシンプルなもので、LLMや他の高度な技術を使わなくても実行できるキーワード検索です。例えば、どの組み込みデバイスが関連しているか、誰がこれを行ったか、特定のテスト中に問題が発生したかなどを検索します。これは特別なものではなく、すでに実行できる従来のワード検索です。
具体的には、チケット内の特定のキーワードやフレーズを基に検索を行います。例えば、「head unit（ヘッドユニット）」、「audio delay（音声遅延）」、「startup sequence（起動シーケンス）」などの特定の単語やフレーズが含まれるチケットを検索します。このような基本的なキーワード検索は、特に明確に定義された問題に対して効果的です。
Oskar：しかし、キーワード検索だけではいくつかの限界があります。例えば、同じ問題を異なる言葉で表現しているケースや、言語が異なるケースでは、キーワードだけでは関連性を見つけることができません。また、問題の記述が詳細でない場合や抽象的な場合も、キーワードだけでは不十分です。
Jens：そうですね。キーワード検索は基本的なフィルタリングとして機能しますが、これだけでは重複チケットの検出には不十分です。そのため、次に説明するセマンティック検索と組み合わせることで、より強力な検索機能を実現しています。
キーワード検索の利点は、処理が高速であり、明示的に言及されている要素を確実に捉えることができる点です。例えば、バージョン番号や特定のコンポーネント名などの具体的情報を基にした検索において、高い精度を提供します。これが私たちのハイブリッド検索の第一の柱となっています。
8.2.2 セマンティック検索（埋め込みベクトル活用）
Oskar：次に、従来のコンポーネントである現在利用可能なセマンティックベクトルをそのコンポーネントに追加します。ここで視覚化されているように、チケット全体、このボックス全体を取り込み、ベクトルを作成してそのベクトルでセマンティック検索を行います。ここで詳しく説明したいと思います。
埋め込みベクトルとは何か、それがどのように機能するのか、そしてなぜ情報を見つけるために重要なのかということをしっかりと理解することが重要だと思います。まず最初の質問ですが、ベクトルとは何でしょうか？埋め込みベクトルとは何でしょうか？これは基本的に単語や文章の数値表現です。
つまり、単語や文章、あるいは長いテキストがあり、その意味を表現する一つのベクトル、つまり数値のリストを作成するのです。これは、意味的に類似した単語は類似した空間にマッピングされることを意味します。つまり、ベクトルが非常に類似します。
これは長い間利用可能でしたが、本当に小さな単語や短い文章に焦点を当てていました。現在では、より大きな文章に対してこれを行うことができます。これらがよく使われるのは分類や類似性検索などです。これは以前から人々が取り組んでいた要素です。
一度、何かのベクトル表現を持っていれば、それが単語であれ他の何かであれ、これは分類や類似性検索、あるいはその方向の他のタスクの基礎となります。それはどのように機能するのでしょうか？すでにベクトルは対象物のセマンティック表現であり、高次元であると説明しました。
このスライドでは5次元か6次元を示そうとしていますが、本当に大きな次元を考えてください。現在のバージョンでは、200次元から1000次元のベクトルを扱います。つまり、これらのベクトルには1000の要素があり、1000の方向を指しているということです。
そして、類似した意味は類似した方向を指すことになります。これらは空間内の点となります。ここで視覚化されているように、類似した意味を持つ「赤」は類似した領域にクラスタリングされます。私たちの場合では、インフォテインメントコンポーネントに関する欠陥の領域があり、他のコンポーネントに関するものは他の領域にマッピングされます。
これはどんな場合でも利用できるものです。そして、新しいベクトル、新しいチケットが入ってきたときにどうするかというと、そのベクトル表現を作成し、その空間に配置します。文字通りそれを空間に配置し、このチケットに最も近い隣接点は何かを調べます。
つまり、最も意味が近いものは何かを調べ、類似性の測定を行います。その方法はいくつかありますが、詳細はあまり重要ではありません。要するに、この空間内で最も近いものを見つけることです。そして、最初の10個を取り出します。
これにより、この巨大な空間内のすべての点から、最も近い10点、最も関連性の高いものを取り出すことができます。これを先ほど説明した構造化検索と組み合わせます。これで2つの検索があり、関連するチケットをもたらしてくれます。
これらを合わせ、さらに時間やソフトウェアバージョンに基づいてチケットをフィルタリングする段階を追加します。これは再び標準的なSQLベースのフィルタリングで、皆さんがこれまでの年月で行ってきたか、行うことができたものです。
8.2.3 ハイブリッド検索の実装
Oskar：私たちの重複チケット検出システムでは、キーワード検索とセマンティック検索を組み合わせたハイブリッドアプローチを採用しています。この組み合わせにより、それぞれの検索方法の長所を活かしながら、短所を補うことができます。
キーワード検索は特定の単語やフレーズに対して高い精度を持ちますが、同義語や異なる表現方法、特に多言語環境では限界があります。一方、セマンティック検索は意味的な類似性を捉えることができますが、具体的な識別子やバージョン番号などの厳密な一致には向いていません。
この二つの検索手法を組み合わせることで、より包括的で正確な検索結果を得ることができます。例えば、「head unit freeze after startup」というチケットがあった場合、キーワード検索では「head unit」や「freeze」という単語に一致するチケットを見つけ、セマンティック検索では「ヘッドユニットが起動後に応答しなくなる」というような類似の意味を持つチケットを見つけることができます。
Jens：さらに、検索結果を時間やソフトウェアバージョンなどの要素でフィルタリングする層も追加しています。例えば、ソフトウェアの特定のバージョンに関連する問題は、同じバージョンや関連するバージョンのチケットと比較することが重要です。これを実現するために、標準的なSQLベースのフィルタリングを適用しています。
Oskar：これで私たちは入ってきた最初のチケットから始まり、強化されたバージョンを作成し、その強化されたバージョンを使って私たちの空間内の他のチケットを見つけました。次に行きたいのは、それをさらに絞り込むことです。
これは、LLMに戻り、Bedrock上の生成AIに「ここに2つのチケットがあります」と言い、すべてのペアに対してこれを行います。もっと丁寧な言い方をすると、「これら2つのチケットを見比べて、これらが重複かどうか教えてください」となります。
私たちはチケットの比較を依頼し、特に時間や、ソフトウェアバージョン、根本原因の理解などを見るよう指示し、何をする必要があるかを説明します。これにより、重複候補の数をさらに絞り込み、最終的な決定を容易にします。
Kim Robins：このハイブリッドアプローチにより、単純なキーワードマッチングでは見つけられなかったような微妙な類似性も検出できるようになりました。特に国際的な開発環境では、同じ問題が異なる言語や表現で記述されることが多いため、この機能は非常に価値があります。
9. 埋め込みベクトル技術の詳細
9.1 埋め込みベクトルの概念説明
Oskar：埋め込みベクトルについてより詳しく説明したいと思います。この概念を理解することは、私たちのソリューションがどのように機能しているかを把握する上で非常に重要です。以前にこの概念を耳にしたことがあるかもしれませんが、これらの概念を十分に理解することが重要だと思います。
まず、埋め込みベクトルとは何かについて説明します。埋め込みベクトルとは、単語や文章の数値表現です。単語や文、あるいは長いテキストがあり、それを一つのベクトル、つまり数値のリストとして表現します。このベクトルはそのテキストの意味を表します。重要なのは、意味的に類似した単語や文章は、ベクトル空間内で近い位置に配置されるということです。つまり、類似した意味を持つものは類似したベクトルを持つのです。
この技術は以前から存在していましたが、主に単語や短い文章に限定されていました。現在では、より長い文章や段落全体にも適用できるようになっています。これらの埋め込みベクトルは、分類や類似性検索などのタスクでよく使用されます。
Jens：具体的には、BMWのチケットシステムではどのように活用されているのですか？
Oskar：BMWのケースでは、チケット全体をベクトル化し、そのベクトルを使って類似したチケットを検索しています。例えば、「ヘッドユニットの起動時に音声出力が遅延する」というチケットがあった場合、このテキスト全体をベクトル化します。その結果、類似した問題を持つチケット、たとえ表現が異なっていても、あるいは別の言語で書かれていても、ベクトル空間内で近い位置に配置されることになります。
Kim Robins：これは非常に強力な技術ですね。特に多言語環境や、同じ問題が異なる表現で記述される場合に大きな価値を発揮します。従来のキーワード検索では、これらの類似性を捉えることは難しかったと思います。
Oskar：まさにその通りです。埋め込みベクトルの重要な特徴は、表面的な表現の違いを超えて、意味的な類似性を捉えられる点にあります。これにより、人間が直感的に理解できるような関連性を、機械的に検出することが可能になります。
9.2 高次元ベクトル空間における類似性検索
Oskar：埋め込みベクトルの機能について、もう少し詳しく説明しましょう。先ほど説明したように、ベクトルは対象物の意味的な表現であり、高次元を持っています。スライドでは5次元か6次元程度を図示していますが、実際にはもっと大きなスケールを考えてください。現在のバージョンでは、ベクトルは200次元から1000次元にもなります。
つまり、これらのベクトルには1000の要素があり、1000の方向を指していることになります。そして、類似した意味を持つものは類似した方向を指します。これらは空間内の点として表現されます。視覚化されているように、意味的に類似したものは、その空間内の類似した領域にクラスタリングされます。
例えば、インフォテインメントコンポーネントに関する欠陥は空間の特定の領域にマッピングされ、他のコンポーネントに関するものは別の領域にマッピングされるといった具合です。これはどのようなケースでも利用可能な手法です。
Kim Robins：この高次元空間での検索はどのように行われるのですか？
Oskar：新しいチケットが入ってきたとき、まずそのベクトル表現を作成します。そして文字通りその表現を高次元空間に配置し、最も近い隣接点を探します。つまり、意味的に最も近いものを見つけるのです。類似性の測定にはいくつかの方法がありますが、詳細はあまり重要ではありません。要するに、この空間内で最も近いものを見つけ、上位10件程度を取り出すのです。
これにより、巨大な空間内のすべての点から、最も近い点、つまり最も関連性の高いものだけを抽出することができます。BMWのケースでは、このような類似性検索によって、表面的には異なる表現をしていても、本質的に同じ問題を抱えたチケットを効率的に見つけ出すことができます。
Jens：この技術は特に、多国籍企業であるBMWにとって価値があります。世界中の拠点から様々な言語で作成されるチケットを、言語の壁を越えて比較できるからです。例えば、ドイツ語で書かれたチケットと英語で書かれたチケットが、実は同じ問題を指している場合も、この高次元ベクトル空間では近い位置に配置され、関連性を検出できるのです。
9.3 意味的に類似したチケットのクラスタリング
Oskar：高次元ベクトル空間内では、意味的に類似したチケットは自然とクラスターを形成します。これは私たちのソリューションにとって非常に重要な特性です。例えば、インフォテインメントシステムに関連する問題は、そのタイプによって異なるクラスターを形成します。音声出力の問題、画面表示の問題、起動時の問題など、それぞれが空間内の特定の領域にグループ化されるのです。
この自然なクラスタリングにより、単に個々のチケット間の類似性を見つけるだけでなく、問題のカテゴリーやパターンも識別できるようになります。例えば、特定のソフトウェアバージョンで多く発生する問題のタイプや、特定のハードウェアコンポーネントに関連する問題のグループなどを見つけることができます。
Kim Robins：このクラスタリングの機能は、単なる重複検出を超えて、より広い視点でのインサイトも提供できるということですね。例えば、特定の問題が何度も繰り返し発生していることを検出し、根本的な原因に対処するための手がかりを得ることができますね。
Oskar：まさにその通りです。実際、このクラスタリングは将来的な拡張にも役立ちます。例えば、類似した問題のクラスターが特定されれば、それに対する解決策や対処方法も類似している可能性が高いです。そのため、過去の解決策を新しいチケットに適用することも容易になります。
Jens：私たちの環境では、このクラスタリングは特に価値があります。先ほど説明したように、BMWは140以上のソフトウェアチームを持っています。この複雑な開発環境では、問題のパターンを識別することが非常に重要です。あるチームで解決された問題が、実は他のチームでも発生している可能性があります。クラスタリングを通じて、これらの関連性を自動的に検出できれば、チーム間の知識共有と問題解決の効率が大幅に向上するのです。
Oskar：さらに、時間の経過とともにチケットデータが蓄積されると、これらのクラスターはより明確になり、モデルの精度も向上します。これは、私たちのシステムが単に静的なツールではなく、使用されるにつれて継続的に学習し、改善されていくことを意味します。
10. LLMによる重複判定
10.1 チケットペアの比較プロセス
Oskar：ここまでで、入ってきた新しいチケットから始まり、その強化されたバージョンを作成し、そのバージョンを使って空間内の他のチケットを探し出すプロセスを説明しました。次に行いたいのは、検索結果をさらに絞り込むことです。
これを実現するために、私たちはLLMに戻り、Bedrock上の生成AIに「ここに2つのチケットがあります」と伝え、すべてのペアに対してこの処理を行います。より丁寧な言い方をすると、「これら2つのチケットを見比べて、これらが重複かどうか教えてください」というプロンプトを作成します。
私たちはモデルにチケットの比較を依頼し、特に時間やソフトウェアバージョン、根本原因の理解に注目するよう指示します。そして何が必要なのか、どうすべきかを説明するよう求めます。この処理によって、重複候補の数をさらに絞り込み、最終的な決定をより容易にします。
Kim Robins：このプロセスが重要なのは、単に「重複かどうか」を判断するだけでなく、その理由も説明してくれる点ですね。これにより、最終判断を行う人間が十分な情報に基づいて決定を下せるようになります。
Oskar：その通りです。私たちの実装では、シンプルに「これは重複ですか？はい/いいえ」と問うだけでなく、「思考」または「説明」のステップを追加しています。つまり、「なぜこれが重複ではないのか」または「なぜこれが重複なのか」という理由を提供するよう求めています。これによってエンドユーザーはその情報をもとに十分な情報に基づいた決定を下すことができます。
実際のプロンプトでは、モデルに対して「チケットの内容を比較し、タイミング、ソフトウェアバージョン、問題の根本原因などの要素を考慮してください」と指示しています。また、「問題の説明が異なる表現や言語で書かれていても、本質的に同じ問題を指している可能性があることを考慮してください」という指示も含めています。
Jens：私たちのようなソフトウェア開発環境では、問題の表面的な症状は似ていても、根本的な原因が異なる場合があります。LLMを活用することで、単なる表現の類似性を超えて、問題の本質を理解した判断が可能になります。これは人間が行う判断に近いアプローチであり、より精度の高い重複検出につながります。
10.2 多言語チケット間の類似性検出の例
Oskar：ここで実際の例をお見せしたいと思います。これは実際のチケットではありませんが、私たちが扱うものを非常によく表しています。ここでは2つのチケットがあります。お気づきになるかもしれませんが、これらは異なる言語で書かれています。最初は英語、2つ目はドイツ語です。
また、これらは構造も異なりますが、重要な共通部分があります。例えば、タイミングが類似しています。これは緑色で示されています。すでにこの混合があることがわかりますね。時間の書き方は何が先か、年、日、月の順序が異なりますが、同じ日を見ているのです。
そして、ソフトウェアバージョンも類似しています。これがモデルの助けとなる部分です。これら2つのチケットを一見しただけでは、同じかどうか判断するのは非常に難しいです。まず、何が書かれているのかを理解し、その情報がどこにあるのかを見つける必要があります。
モデルはここで本当に役立ちます。モデルはまず「はい、これは重複です」という判断を示し、その理由を説明します。何を探しているのかという推論を提供するのです。説明はとても類似しており、同様の問題が見られます。そして他にも重要な部分があります。同じソフトウェアであり、非常に類似した日付が見られるのです。
Kim Robins：この例は非常に興味深いですね。特に多言語環境での重複検出の難しさを示しています。人間でも異なる言語で書かれた2つのチケットを比較するのは困難ですが、LLMはこの課題を効果的に解決しています。
Jens：私たちのような国際的な企業にとって、この機能は非常に価値があります。ドイツ、中国、米国など世界各地の拠点から、それぞれの現地言語でチケットが提出されることがあります。従来のシステムでは、これらの関連性を見つけるのは非常に困難でしたが、LLMを活用することで言語の壁を超えた類似性の検出が可能になりました。
Oskar：重要なのは、モデルが単に「はい、これは重複です」と言うだけでなく、その判断理由を説明することです。「説明は非常に類似しており、同様の問題があります」「同じソフトウェアバージョンであり、日付も近いです」といった形で、判断の根拠を提示します。これにより、最終判断を行う人間は十分な情報に基づいて決定を下すことができます。
10.3 人間による最終判断
Jens：ここで、非常に重要なステップである人間による最終判断について説明します。この段階では、人間に対して「モデルはこれらが重複だと考えていますが、あなたはそれを確認できますか？」と問いかけます。なぜこのステップを設けているのかというと、ChatGPTが普及したきっかけとなったRLHF（人間のフィードバックからの強化学習）と同様の理由があります。
この人間によるフィードバックには2つの大きなメリットがあります。1つ目は、モデルに重複かどうかのフィードバックを与えることで学習させることができる点です。Oskarが後ほど説明するように、このステップによってフライホイールを作成することができます。フライホイールの大きな利点は、チケット処理プロセスをスケールできることです。
このフィードバックによって、モデルは継続的に改善され、システムがより良くなっていきます。また、開発者にとっても、システムが何をできるのかを学び、システムを継続的に改善するのに役立ちます。
Kim Robins：この人間によるフィードバックのステップは、単にシステムの精度を向上させるだけでなく、ユーザーの信頼を構築する上でも重要ですね。自動システムが完全に自律的に決定を下すのではなく、人間の判断を最終的な決定要素として組み込むことで、システム全体の信頼性が向上します。
Oskar：その通りです。また、このステップを通じて収集されるデータは非常に価値があります。「はい、これは重複です」または「いいえ、これは重複ではありません」という判断のペアを蓄積することで、将来的には埋め込みモデル自体を微調整することも可能になります。つまり、BMWの特定のコンテキストにより適したモデルを構築できるのです。
Jens：私たちのソリューションの根幹にあるのは、完全な自動化ではなく、人間とAIの協力関係です。AIは大量のデータを処理し、関連性を見つけ出すことが得意ですが、最終的な判断は人間の経験や直感に基づいて行われます。この協力関係によって、双方の強みを活かしたより効果的なシステムが実現するのです。
11. 人間のフィードバックを取り入れた継続的改善
11.1 RLHF（人間のフィードバックによる強化学習）の活用
Jens：私たちがこのシステムに人間の判断ステップを組み込んだのは、ChatGPTが普及する大きなきっかけとなったRLHF（人間のフィードバックからの強化学習）と同様の理由からです。このアプローチには私たちにとって2つの大きなメリットがあります。
まず1つ目は、モデルに学習させ、フィードバックを提供することができる点です。これにより、チケットが重複かどうかを判断する能力が向上していきます。Oskarが後ほど詳しく説明しますが、このステップによって私たちはフライホイール効果を生み出すことができます。つまり、システムの使用とフィードバックの循環によって、モデルが継続的に改善されていくのです。
このフライホイールの大きな利点は、チケット処理プロセスをスケールできることです。フィードバックが増えるほど、モデルの精度が向上し、より多くのチケットを効率的に処理できるようになります。
Kim Robins：RLHFのアプローチは、生成AIの品質向上に非常に効果的ですね。人間の判断をモデルの訓練に取り入れることで、単純なパターン認識を超えた、より洗練された判断ができるようになります。
Oskar：その通りです。特に当社のユースケースでは、「これは重複です」「これは重複ではありません」という明確なフィードバックを収集できるため、RLHFの適用が非常に効果的です。また、この判断の背後にある理由も収集することで、モデルはより深いレベルでの理解を獲得できます。
例えば、「この2つのチケットは同じソフトウェアバージョンに関するものだが、報告されている症状が異なるため重複ではない」といった判断理由も学習の対象となります。これにより、単なる表面的な類似性だけでなく、問題の本質に基づいた判断ができるようになるのです。
Jens：RLHFの活用は、単にモデルを改善するだけでなく、開発者とシステムの間の信頼関係の構築にも役立ちます。開発者がシステムの判断を確認し、フィードバックを提供することで、システムの能力と限界を理解できるようになります。同時に、システム側も開発者の判断パターンを学習し、より人間の期待に沿った判断ができるようになるのです。
11.2 フライホイール効果によるシステム改善
Kim Robins：ここで、私たちが構築した強化アプローチについて少しお話ししたいと思います。チケットの振り分けから始まり、チケットの解決を経て、最終的にチケットデータベースにフィードバックされるというサイクルを考えてみましょう。このフライホイールが回り続けることで、より質の高いデータが生まれ、より正確にチームを見つけることができるようになり、より迅速な解決と開発者の重複作業の削減につながります。しかし、もう一つ付け加えたいことがあります。その点についてはOskarから詳しく説明してもらいましょう。
Oskar：ありがとうございます、Kim。これはJensもすでに示唆していたことですが、人間による最終判断を行うたびに、私たちはデータにラベルを付けています。これは、このユースケースにおいて非常に重要なことであり、皆さんのユースケースにも当てはまることです。モデルとの対話を通じて、顧客が尋ねる質問や発生する問題、そしてその問題を解決するのに役立つ情報を収集できます。
私たちの場合、2つのチケットのペアがあり、「はい、これは実際に重複です」という肯定的な反応を得たとします。これにより、このペアがあるとき、これらは実際に一緒に属しているというラベル付きのデータが得られます。これは他のデータについても同様で、将来的に他のデータソースを導入する場合も、例えば「この文書はこの問題の解決に役立った」というようなフィードバックが得られれば、そのデータとチケットが密接に関連していることを示す重要な指標となります。
これは、プロセスを通じて、私たちが提供する情報が役立っているか、正しいチケットを持ってきているかを追跡しているということです。そして、このプロセスを通じて、より多くのラベル付きデータを蓄積していくのです。
これが意味することは、私たちはこのプロセスを通じて、提供する情報が役立つか、正しいチケットを持ってきているかを常に追跡しているということです。このプロセスによって、より多くのラベル付きデータが蓄積されていきます。
Jens：このフライホイール効果により、システムは使えば使うほど賢くなっていきます。最初は完璧でなくても、実際の使用とフィードバックを通じて継続的に改善されていくのです。これはソフトウェア開発プロセス全体の効率向上にも寄与します。
Oskar：そうです。そして埋め込みモデルをファインチューニングできるという点も重要です。LLMだけでなく、より小さな埋め込みモデルもファインチューニングできるのです。そのために必要なのは、まさにこのようなデータのペアです。「これら2つの情報は密接に関連している」という肯定的なペアが必要です。
11.3 開発者の負担軽減効果
Jens：私たちがすべてのステップを説明した後、実際の結果についてお話ししましょう。私は最初から言いましたが、要約を書くことはモデルが比較的簡単にできることです。しかし、これだけでも「すべてのデータを取得し、なおかつ要約できるのは素晴らしい」というフィードバックを得ることができました。
しかし、私たちにとって本当のメリットは、以前よりもはるかに正確にチケットを振り分けられるようになったことです。つまり、チケットを作成した人が関連していると思った人ではなく、本当に適切な人にチケットが届くようになったのです。また、すべてのチケットが見え、処理されたチケット数や重複数などを継続的に評価できるようになり、透明性も向上しました。
しかし、断然最も重要なことは、開発者の負担を軽減できたことです。ソフトウェアを開発している方なら、日々の業務でチケット、チケット、またチケットと処理していることをご存知でしょう。1つのチケットを確認するのに5分かかるとして、1日に10のチケットがあれば、それだけで1時間が費やされます。このLLMを使ってワークフローを改善するだけで、この無駄な1時間を削減することができるのです。
Kim Robins：この時間の節約は、大規模な開発チームで考えると非常に大きなインパクトがありますね。BMWには12,000人もの開発者がいるとのことでしたが、仮に各開発者が日に数件の重複チケットに費やす時間を削減できれば、組織全体では膨大な時間の節約になります。
Oskar：また、単に時間を節約するだけでなく、開発者のフラストレーションも軽減されます。同じ問題に何度も取り組まなければならないという状況は、多くの開発者にとってモチベーションを下げる要因となります。このシステムによって、開発者は本当に新しい問題や課題に集中できるようになるのです。
Jens：まさにその通りです。開発者は創造的な問題解決や新機能の開発に集中したいと思っています。重複チケットの処理のような単調な作業から解放されることで、より価値の高い作業に時間を費やすことができるようになります。これは単に効率の問題だけでなく、開発者の満足度や生産性にも大きく影響するのです。また、問題がより迅速に適切なチームに届くことで、解決までの時間も短縮されます。これはプロジェクト全体の進行速度を向上させる効果もあります。
12. 学んだ教訓と結果
12.1 ビジネス価値を重視したアプローチの重要性
Kim Robins：このプロセスを通じて学んだいくつかの教訓をお伝えしたいと思います。まず一つ目は、生成AIは確かに価値を付加しますが、私たちとBMWにとって非常に重要だったのは、価値を付加するアプローチを取り、実際に達成しようとするビジネス価値が何であるかを考え、測定可能な成果を選ぶことでした。
ビジネス価値を中心に考えることで、技術的に可能なことではなく、実際に組織にとって最も重要な課題に焦点を当てることができました。BMWの場合、開発者の時間の節約と重複作業の削減が最優先事項でした。そのため、最初から重複チケットの検出に焦点を当て、その価値を実証することができました。
Jens：その通りです。技術的な可能性に惑わされるのではなく、「これによって何が改善されるのか」「どのようなビジネス課題を解決できるのか」という視点から取り組むことが重要でした。チケット処理はソフトウェア開発プロセス全体の一部に過ぎませんが、そこでの効率化が開発全体の生産性に大きく影響することがわかっていました。
Oskar：また、明確な指標を設定することも重要でした。「重複チケットをどれだけ正確に検出できるか」「チケットの振り分け精度がどれだけ向上するか」など、測定可能な目標を設定することで、取り組みの成果を具体的に評価できました。単に「AIを導入する」ことが目的ではなく、特定のビジネス成果を達成することが目的だったのです。
Kim Robins：この経験から、生成AIプロジェクトは技術主導ではなく、ビジネス価値主導であるべきだという重要な教訓を得ました。技術はあくまで手段であり、目的はビジネス価値の創出です。この原則はどのような組織でも応用可能であり、生成AIプロジェクトの成功率を高める重要な要素だと考えています。
12.2 適切な専門家の関与
Kim Robins：私たちがこのプロジェクトで学んだもう一つの重要な教訓は、適切な専門家を関与させることの重要性です。BMWとの取り組みでは、チケットを作成する人々、チケットを処理する人々、そしてチケット処理プロセス全体のKPIと責任を持つビジネスオーナーなど、様々な専門家と深く関わりました。
これらの異なる専門家を関与させることで、問題を多角的に理解し、生成AIを最も効果的に適用する方法を見出すことができました。各専門家は独自の視点と知識を持っており、それらを組み合わせることで、より包括的なソリューションを設計することができたのです。
Oskar：専門家の関与という点では、特に実際のエンドユーザー、つまりチケットを作成する人々や処理する人々の意見を取り入れることが重要でした。彼らは日々の業務でどのような課題に直面しているのか、どのような情報があれば作業が効率化されるのかを直接知っている人たちです。このような現場の声を設計プロセスに取り入れることで、より実用的なソリューションを構築することができました。
Jens：技術チームとビジネスチームの両方を関与させることも重要でした。技術チームはソリューションの可能性と制約を理解し、ビジネスチームはそれがどのように価値を生み出すかを理解しています。この両方の視点がなければ、技術的には優れていても実際のビジネス価値を生み出せないソリューションや、ビジネス的には理想的でも技術的に実現不可能なソリューションを追求してしまう恐れがあります。
Kim Robins：私たちがよく使う枠組みとして、LLMはある意味でインターンのようなものだと考えています。つまり、プロセスを本当によく理解し、大規模言語モデルに価値を付加する方法を教えることが必要です。適切な専門家の関与により、このプロセスの理解を深め、LLMの能力を最大限に活用することができました。
12.3 技術理解とビジネスドメイン知識の融合
Kim Robins：最後の重要な教訓として、AIの技術的理解とビジネスドメインの知識の両方を持つ人材に投資することの重要性が挙げられます。このような「翻訳者」的な役割を果たせる人材は、技術チームとビジネスチームの架け橋となり、双方の言語を話すことができます。
BMWとの取り組みでは、技術的な可能性を理解しつつ、自動車開発の特有の課題やプロセスも理解している人材が重要な役割を果たしました。彼らは技術の専門家に対しては具体的なビジネス要件を説明し、ビジネス側の人間には技術的な可能性と制約を説明することができました。
Oskar：これは非常に重要なポイントです。生成AIのような先端技術を適用する際には、単に技術そのものを理解するだけでは不十分です。その技術がどのようにして特定のビジネスドメインの課題を解決できるのかを理解する必要があります。BMWの場合、自動車開発の複雑なプロセスと生成AIの能力をどう組み合わせるかという視点が不可欠でした。
Jens：私たちBMWにとって、自社のドメイン知識を持つエンジニアが生成AIの可能性を理解することで、より効果的なユースケースの特定と実装が可能になりました。例えば、チケット処理プロセスの複雑さや、多国籍チームでの協業の課題など、BMWの開発環境特有の要素を理解した上でソリューションを設計することができました。
Kim Robins：この融合は継続的なプロセスでもあります。プロジェクトを進める中で、技術チームはより深くビジネスドメインを理解するようになり、ビジネスチームも技術の可能性をより深く理解するようになりました。この相互理解が深まることで、ソリューションの質も向上していきました。最終的には、技術とビジネスの両方の言語を話せる人材の育成が、生成AIプロジェクトの成功において非常に重要な要素となるのです。
13. データフライホイールの強化
13.1 ラベル付きデータの蓄積方法
Oskar：Jensが既に言及していたことですが、この最終的な人間による判断のステップでは、データにラベルを付けています。これは私たちのユースケースにとって非常に価値のあることですが、皆さんのユースケースにも当てはまることだと思います。モデルとの対話を通じて、どのような質問が顧客から来るのか、どのような問題が存在するのか、そしてどのような情報がその問題解決に役立つのかというデータを収集できるのです。
具体的には、私たちのケースでは、2つのチケットのペアがあり、「はい、これは実際に重複です」という肯定的な反応を得たとします。これによって、このペアは実際に関連しているというラベル付きデータが生成されます。このような肯定的なペアは、モデルの訓練において非常に価値があります。
将来的に他のデータソースを導入する場合も同様です。例えば、あるドキュメントが問題解決に役立ったという情報があれば、そのドキュメントとチケットが密接に関連していることを示す良い指標となります。
Kim Robins：このプロセスを通じて、私たちは「どの情報が役立ったか」「正しいチケットを提示できたか」を継続的に追跡しています。これにより、システムの使用とともに、より多くの質の高いラベル付きデータが蓄積されていくのです。
Jens：この方法の素晴らしい点は、特別な追加作業をすることなく、通常の業務フローの中でラベル付きデータを自然に収集できることです。重複判定のプロセスで「はい/いいえ」の判断を行うたびに、貴重なラベル付きデータが生成されるのです。
Oskar：このようなラベル付きデータは、単にLLMの改善だけでなく、次に説明する埋め込みモデルのファインチューニングにも非常に重要です。「これら2つの情報は関連している」「これらは関連していない」というラベルが、より精度の高い検索システムの構築に貢献するのです。
13.2 埋め込みモデルのファインチューニング
Oskar：埋め込みモデルをファインチューニングできるということは、このプロセスでとても重要なポイントです。大規模言語モデル（LLM）だけでなく、これらのより小さな埋め込みモデルもファインチューニングすることができるのです。そのために必要なのは、データのペアです。「これら2つの情報は密接に関連している」という肯定的なペアが必要です。
埋め込みモデルをファインチューニングすることで何ができるかというと、先ほど説明した大きな空間、つまりすべてのチケットが表現されている空間において、関連するチケットをより近くに配置するようにモデルを調整できるのです。具体的には、「これらのチケットは重複である」というラベル付きペアを使って、それらのベクトル表現が空間内でより近くなるようにモデルの重みを調整します。
重複ではないという否定的なペアも追加しますが、これらは見つけるのが比較的簡単です。本当に難しいのは、これらの良質なペアを見つけることなのです。これらのデータペアを集め、基本モデルにファインチューニングを加えることで、私たちの知識、情報、プロセスを埋め込みモデルに取り込むことができます。
Kim Robins：これは前に説明したフライホイールをさらに加速させる要素ですね。私たちはすでに、データの品質が向上し、チケットの品質が向上するというプロセスのフライホイールを持っていました。しかし今、このラベル付きデータを通じて、より良い埋め込みモデルを持つことができるようになります。
Oskar：その通りです。このプロセスを通じて、ステップ2で提示するチケットの関連性がさらに向上します。つまり、提示される結果はより関連性が高く、処理しやすいものになります。これによって結果の関連性がさらに向上し、フライホイールが加速するのです。
Jens：この継続的な改善サイクルが、私たちのソリューションの長期的な価値を生み出します。最初は完璧でなくても、使用するにつれて学習し、より正確で関連性の高い結果を提供するようになるのです。これは特に、BMWのような多様で複雑なチケットが生成される環境では非常に価値があります。
13.3 プロセス改善の加速化
Oskar：これは重要なテイクホームメッセージだと思います。皆さんのプロセスについて考え、使用によって何が得られるのか、どのようなデータを収集できるのか、そしてそのデータをどのようにプロセス改善に活用できるのかを考えてみてください。これは二次的なモデルに対してもなり得ますし、RAGシステムやその他のシステムでより良いデータを見つけるのに役立つ可能性があります。
適切なポイントでそのデータを特定して収集し、プロセスに取り入れることで、フライホイールを加速し、コンポーネントを向上させることができます。この継続的な改善のサイクルは、時間とともにシステムの性能を大幅に向上させる可能性を秘めています。
Kim Robins：この加速効果は非常に重要です。従来のシステム開発では、改善は段階的で時間がかかるものでした。しかし、このデータフライホイールアプローチでは、システムの使用自体が改善をもたらします。使えば使うほど、システムは賢くなり、より価値を提供できるようになるのです。
Jens：私たちのBMWの環境では、このプロセス改善の加速化は特に価値があります。私たちは常に新しい車種、新しいソフトウェアバージョン、新しい機能を開発しています。環境が変化し続ける中で、静的なシステムではなく、継続的に学習し適応するシステムが必要なのです。
Kim Robins：また、このアプローチは社内の専門知識を保存し活用する方法としても機能します。例えば、特定のベテラン開発者が持つ「このタイプの問題はこのチームに回すべき」という暗黙知を、システムが学習することができます。これにより、個人の専門知識が組織的な資産として保存され、活用されるようになるのです。
Oskar：最終的には、単に個々のチケットを効率的に処理するだけでなく、プロセス全体の継続的な改善と最適化を実現することが目標です。最初は人間の判断が多く必要かもしれませんが、時間とともにシステムの自律性と精度が向上し、人間はより高度で創造的な問題解決に集中できるようになります。これがデータフライホイールアプローチの真の価値なのです。
14. まとめと次のステップ
14.1 Generative AI Innovation Centerとの協力継続
Kim Robins：これまでの経験から得た行動への呼びかけとして、まず適切な専門家を関与させることの重要性が挙げられます。BMWは問題を発見したと思われる領域で生成AIを活用できる場合、すぐに始めて取り組むという素晴らしいアプローチを取っています。
最後に付け加えたいのは、もしGenerative AI Innovation Centerと話をしたいという方がいらっしゃれば、私たちはVenetianのExpo Centerにある AWS Gen AIのブースに大きなエリアを設けています。そちらに来ていただければ、おそらく今日の後半にはOskarと私がいますので、ぜひお話しができればと思います。それでは、すべてをまとめるためにJensにバトンを渡します。
Jens：私も一言付け加えたいと思います。このプロジェクトでの協力関係は、この車両と同じくらい素晴らしいものでした。ご覧いただけるように、このPOC（概念実証）の段階ですでに大きな価値が得られました。実際に大きなインパクトを与えることができたことがわかりました。
また、このプロジェクトのプロダクトオーナーがこの成果にどれだけ満足しているかも確認しました。このように、Generative AI Innovation Centerとの協力は非常に実りあるものでした。単なる技術検証にとどまらず、実際のビジネス価値を生み出すことができました。
Kim Robins：私たちはBMWとの協力を続け、このソリューションをさらに発展させていく予定です。POCの成功を受けて、より広範な実装に向けた次のステップを検討しています。また、チケット処理以外の領域でも生成AIの可能性を探っており、BMWの革新的なアプローチが今後も続くことを楽しみにしています。
Oskar：私たちGenerative AI Innovation Centerは、BMWのような先進的な企業との協力を通じて、生成AIの実用的な応用を推進することを目指しています。このプロジェクトで得られた知見は、他の業界や用途にも応用可能であり、より広いコミュニティと共有していきたいと考えています。
14.2 POC（概念実証）の成果と展望
Jens：このPOC（概念実証）ではすでに実際の価値が証明されており、今回のパイロットプロジェクトでの成果に非常に満足しています。このプロジェクトの製品オーナーも結果に大変喜んでいます。このことからも、単なる技術的な実験ではなく、実際のビジネス価値を生み出せることが示されました。
具体的な成果としては、チケットの要約と強化機能によって、誰がチケットを見ても短時間で内容を把握できるようになりました。また、チケットの振り分け精度が大幅に向上し、正しいチームに最初から届くようになったことで解決までの時間が短縮されました。さらに、重複チケットの検出によって開発者の時間の無駄を削減できました。開発者一人あたり1日に約1時間の節約になるとすれば、12,000人の開発者がいるBMWでは、組織全体で非常に大きなインパクトがあります。
Oskar：このPOCの成功を受けて、今後はシステムをさらに拡張していく予定です。例えば、現在は重複チケットの検出に焦点を当てていますが、将来的にはチケットの自動分類や優先順位付け、解決策の推奨なども可能になるでしょう。また、チケット以外のデータソース、例えばコードリポジトリやドキュメント、ログデータなども統合することで、より包括的なサポートシステムを構築できると考えています。
Kim Robins：また、現在のシステムで収集されるフィードバックとラベル付きデータは、将来的なモデルの改善にとって非常に価値があります。時間とともに、BMWの特有のコンテキストに特化したモデルを構築することができるでしょう。これは単に既存のプロセスを自動化するだけでなく、人間だけでは難しい新たなインサイトやパターンの発見にもつながる可能性があります。
Jens：このプロジェクトを通じて、私たちはデータ中心のアプローチの価値も再確認しました。生成AIと既存のデータを組み合わせることで、新たな価値を生み出すことができるのです。BMWでは今後も、このようなデータ駆動型のアプローチをさらに拡大し、ソフトウェア開発だけでなく、設計、生産、アフターサービスなど様々な領域での適用を検討していきます。このPOCは私たちにとって、より大きな変革への第一歩にすぎないのです。