※本記事は、AWS re:Invent 2024で開催されたセッション「Improve enterprise business productivity using generative AI [Korean] (GBL202)」の内容を基に作成されています。セッションの詳細情報はAWS re:Invent(https://go.aws/reinvent )でご覧いただけます。本記事では、セッションの内容を要約・構造化しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画(https://www.youtube.com/watch?v=sj_C58AYaR4 )をご視聴いただくことをお勧めいたします。
登壇者紹介:
- パク・ヘヨン:AWSソリューションアーキテクト。本セッションのモデレーターを務め、LGエレクトロニクスの生成AI活用事例について、技術的な観点から議論を展開。
- イ・ジョンウォン:LGエレクトロニクスB&S事業本部。Product 360プラットフォームの開発責任者として、RAGシステムの実装と運用を主導。
- イ・セフン:LGエレクトロニクス韓国営業部デジタルトランスフォーメーション担当。CDPシステムへの生成AI実装を統括し、データ民主化を推進。
本セッションは韓国語で行われ、LGエレクトロニクスにおけるAmazon Bedrockを活用した生成AI導入の実践的な知見が共有されました。
1. LGエレクトロニクス B&S事業本部の事例
1.1 B2B事業における生成AIの活用事例の概要
イ・ジョンウォン(LG電子B&S事業本部)※以下イ: 私たちB&S(Business Solutions)事業本部にとって、B2B事業は非常に重要な領域です。2023年に生成AI関連で実施した主要なプロジェクトについて説明させていただきます。
まず、公共入札案件に関してですが、これは非常に規模の大きな事業機会です。毎日6,000件以上の入札情報が検索されますが、各案件には数十から数百ページの文書が含まれています。人手で全ての文書を読んで、重要な内容、予算規模、締切日、連絡先などを把握するのは事実上不可能でした。そこで私たちは、大規模言語モデル(LLM)を活用して入札情報を要約し、重要な入札情報を抽出して、該当する営業担当者に自動的にアサインするシステムを構築しました。
パク・ヘヨン:それは素晴らしい取り組みですね。入札情報の自動化により、営業担当者の負担が大幅に軽減されたのではないでしょ:それは素晴らしい取り組みですね。入札情報の自動化により、営業担当者の負担が大幅に軽減されたのではないでしょうか。
イ:はい。また、顧客フィードバックの分析も重要な課題でした。BS事業本部の製品に関して、1日あたり1万件以上の顧客フィードバックが蓄積されています。これらを迅速に要約し、製品ごとの課題を自動的にカテゴリ分類する機能を実装しました。これもLLMを活用して解決しています。
さらに、B2B営業では顧客企業ごとに最適化された提案書の作成が必要です。ホテルチェーンごとに異なる提案書を作成する必要があり、営業担当者の大きな負担となっていました。そこで、PPTの自動生成機能を開発しました。単なる大学生レポートレベルではなく、プロフェッショナルが作成したような質の高い提案書を自動生成できるよう、画像生成や検索、PPT制御機能なども含めて多くの工夫を重ねました。
パク:各システムの導入効果はいかがでしたか?
イ:はい、特に営業現場からの反応が非常に良好です。これまで1週間以上かかっていた業務が大幅に効率化され、より多くの案件に対応できるようになりました。また、提案書の質も向上し、顧客満足度の向上にも貢献しています。
この3つのシステムの中でも、本日は特にProduct 360について詳しくご説明させていただきたいと思います。これは自然言語による製品情報検索システムで、RAG(Retrieval-Augmented Generation)ベースのチャットサービスとして実装しています。
1.2 Product 360システムの開発背景と課題
イ・ジョンウォン:Product 360の開発は、海外営業現場での深刻な課題から始まりました。具体的な例を挙げると、海外の営業担当者が顧客から特定の条件の製品について問い合わせを受けた際、製品の詳細を完全に把握していないため、適切な製品を迅速に提案することができませんでした。
パク:時差の問題も大きな課題だったのではないでしょうか?
イ:その通りです。時差があるため、部門間での連絡に時間がかかり、さらに適切な部署が不明な場合は別の部署に転送する必要があるなど、営業担当者の話では回答まで1週間以上かかることも珍しくありませんでした。
商品企画担当者の立場からも大きな課題がありました。新製品の企画時には、自社モデルと競合モデルの詳細な比較が必要です。このために最低でも4つ以上の社内システムにアクセスして情報を収集する必要があり、この作業だけでも膨大な時間を要していました。
パク朴:そのような非効率な作業を自動化することで、かなりの業務改善が期待できそうですね。
イ:はい。このような背景から、私たちはProduct 360という自然言語による製品検索サービスの開発を決定しました。目標は、製品の仕様や性能について自然な対話形式で質問でき、さらに競合製品との比較や過去モデルとの改善点なども即座に確認できるシステムの構築です。特に注力したのは、単なる情報検索だけでなく、複数製品の比較や分析も可能な高度な機能の実装です。
この開発により、営業担当者は顧客からの問い合わせにリアルタイムで対応できるようになり、また商品企画担当者も効率的に情報収集を行えるようになることを目指しました。実際、後ほど詳しくご説明しますが、営業部門からは特に製品比較機能について非常に好評を得ています。
1.3 自然言語クエリシステムの実装における技術的課題
イ・ジョンウォン:Product 360の開発過程で、私たちは4つの主要な技術的課題に直面しました。第一に、データベース形式のデータがほとんどなく、ほぼすべての情報が文書形式で存在していたことです。これにより、単純なSQLクエリによる情報検索が困難でした。
パク:その課題にはどのように対応されたのでしょうか?
イ:まず、各製品に関する文書の形式が大きな問題でした。ページごとに画像、表、テキストが混在しており、さらに各ページで異容が異なっていました。例えば、PowerPointドキュメントでは、図表とテキストが混在した形で情報が存在していました。
パク:OCRソリューションの活用は検討されましたか?
イ:はい。市販のOCRソリューションも検討しましたが、高性能なものは非常に高額で、また性能面でも課題がありました。特に、表形式のデータ抽出が難しく、例えば6-7行4列程度の表でも、罫線が明確でない場合、構造化された情報として抽出することが困難でした。
2023年4月の開発開始時点では、この問題の解決に苦心していました。しかし、転機が訪れたのは5月中旬でした。GPT-4の登場です。それまでGPT-3.5では適切な情報抽出ができなかったのですが、GPT-4では正確な情報抽出が可能になりました。
パク:それは興味深い進展ですね。具体的にどのように活用されたのですか?
イ:はい。私たちは従来のOCRアプローチを見直し、GPT-4を活用して文書から情報を抽出し、構造化されたXMLデータとして変換する方法を採用しました。例えば、表形式のデータであっても、GPT-4を使用することで、適切にタグ付けされた構造化データとして抽出できるようになりました。
オフィス文書はまずPDFに変換し、そこから画像とテキストを抽出して、GPT-3.5にかけ、構造化されたXMLメタデータを生成するというプロセスを確立しました。これにより、約1,000製品を対象に、4万件の文書から約120万件のXMLファイルを生成することができました。
この成果は、単にデータ抽出の効率化だけでなく、後続の検索システムの精度向上にも大きく貢献しました。特に、製品スペックの比較や分析において、構造化されたデータが大きな価値を発揮しています。
1.4 ベクターDBの構築とデータ構造化プロセス
イ・ジョンウォン:ベクターDBの構築にあたって、私たちは体系的なアプローチを採用しました。まず、非構造化文書の収集から始め、S3に保存し、そこから画像、テキスト、メタデータ情報を抽出してGPT-3.5 Sonnetに送信します。その後、GPT-3.5が構造化XMLデータを生成し、トークン化とパッディングを行ってOpenSearchにインデックスを作成する流れを確立しました。
パク:データの正確性はどのように担保されているのでしょうか?
イ:重要な指摘ですね。製品情報の正確性は最重要課題でした。統計ベースの言語モデルでは必然的にハルシネーション(幻覚)が発生するため、100%正確な回答を得るために、私たちはハイブリッドアーキテクチャを採用しました。具体的には、Amazon RDSと組み合わせて使用し、RAGのための入力データとして活用しています。
パク:外部データの取り扱いについてはいかがでしょうか?
イ:外部の競合製品データなども扱う必要がありましたので、WebURLを通じて構造化情報を抽出し、Pydanticを使用してデータを検証してから蓄積するプロセスを構築しました。これにより、約1,000製品を対象に、4万件の文書から120万件のXMLファイルを生成し、適切にベクターDBを構築することができました。
パク:Amazon Redshiftの役割について、もう少し詳しく説明していただけますか?
イ:はい。様々なソースからデータを収集し、それらをAmazon Redshiftに集約しています。サービスレイヤーでは、CDPエクスプロラトリアムサービスレイヤーがAmazon Redshiftとデータシェアリングする形で構成されています。全てのデータは最終的にAmazon Auroraに保存される、シンプルながら効率的な構成を採用しています。このアーキテクチャにより、RAGシステムが必要とする高精度な情報検索と応答生成が可能になりました。
このように、データの収集から構造化、保存、検索までの一連のプロセスを、精度と効率性を両立する形で実現することができました。特に、製品情報の正確性を担保しながら、柔軟な検索と応答が可能なシステムを構築できたことは、大きな成果だと考えています。
1.5 クエリ精度向上のための工夫と実装方法
イ・ジョンウォン:クエリ精度の向上は私たちの最大の課題の一つでした。約4万件の文書でベクターDBを構成する中で、特に問題となったのは、類似キーワードが多数の文書に存在することでした。例えば、「WiFi 6対応の有無」について質問すると、「WiFi 6」という単語が仕様書、部品承認書、試験評価書など、多くの文書に含まれているため、検索段階で膨大な数のドキュメントが返されてしまいました。
パク:その問題をどのように解決されましたか?
イ:サイズベースのチャンキングではなく、コンテキストベースのチャンキングを採用しました。XMLで構造化された情報を活用し、セクションタイトルなどのコンテキストの原本を保持することで、より文脈に即した検索が可能になりました。
さらに、メタデータによるフィルタリングも導入しました。例えば、「Aモデルのワイファイ機能対応の有無」という質問に対して、まずAモデルの文書を検索し、その中からWiFiキーワードを含む文書、さらに機能対応に関連性の高い文書というように、段階的に絞り込みを行うことで、検索段階での精度を大幅に向上させることができました。
パク:複雑なクエリの処理はどのように対応されていますか?
イ:はい、それが三つ目の重要な施策です。例えば、単純な質問「Aモデルの解像度関連スペックを教えて」であれば正確に回答できます。また、「競合製品は何があり、解像度関連スペックはどうか」という質問にも対応できます。しかし、「Bモデルはどうか」という質問になると、文脈を理解して適切な回答を生成する必要があります。
これに対応するため、クエリリライト処理を導入しました。「Bモデルはどうか」という質問を、「Bモデルの解像度と、Bモデルの競合製品の解像度を教えて、比較もして」というように書き換えるLLMを実装しました。このクエリリライターには、Claude 3.5 Sonnetを使用しています。
パク:具体的な効果はいかがでしたか?
イ:質問を適切に分解することで、検索精度が大幅に向上しました。例えば、長い質問は複数の小さな質問に分割し、さらにOpenSearchが検索しやすい形式に変換することで、より正確な回答が得られるようになりました。結果として、現場で実用に耐えうるレベルまで精度を向上させることができました。これらの改善により、ユーザーからの複雑な質問にも適切に対応できるシステムを実現することができました。
1.6 システムアーキテクチャの詳細
イ・ジョンウォン:私たちのシステムアーキテクチャは、フロントエンド、バックエンド、そしてRAGシステムの3つの主要コンポーネントで構成されています。フロントエンドはNginxウェブサーバー上でReactを使用して実装し、直感的なユーザーインターフェースを実現しました。
パク:双方向のリアルタイム通信は、どのように実装されているのでしょうか?
イ:バックエンドでは、チャットサービスのリアルタイム双方向通信を実現するため、WebSocket API Gatewayを採用しています。これにより、ユーザーからの問い合わせに対して、スムーズな対話型の応答が可能になりました。
パク:RAGシステムの具体的な構成について、もう少し詳しく説明していただけますか?
イ:はい。RAGアーキテクチャは以下のような流れで動作します。まずクエリが入力されると、ルーターを経由してクエリリライトが行われます。その後、パースを行い、クエリデコンポーズを経て、OpenSearchとRDSを活用して回答を生成します。この過程でエラーが発生した場合は、継続的にリトライを行う仕組みも実装しています。
特に注目すべき点は、OpenSearchとRDSの組み合わせです。OpenSearchは柔軟な検索を可能にし、RDSは正確な製品情報の管理を担当します。この二つを適切に組み合わせることで、検索の柔軟性と情報の正確性を両立しています。
パク:各コンポーネント間の連携はスムーズに行われていますか?
イ:はい。全体のシステムは、フロントエンドのリクエストをWebSocket経由でバックエンドが受け取り、RAGシステムで処理した結果を再びWebSocketを通じてフロントエンドに返す、というシンプルながら効率的な構成になっています。特に、リアルタイムな対話性を重視したため、WebSocketの採用は非常に効果的でした。また、各コンポーネントはモジュール化されており、将来の拡張や保守性も考慮した設計となっています。
これらのアーキテクチャにより、ユーザーは複雑なシステムを意識することなく、自然な対話形式で製品情報にアクセスすることが可能になりました。
1.7 プロンプトエンジニアリングの重要性と実践
イ・ジョンウォン:私は長年の開発経験を持つ立場から、プロンプトエンジニアリングの重要性について特に強調したいと思います。当初、テキストによるエンジニアリングという概念は非常に違和感がありました。しかし、プロンプトの質がLLMの回答品質に大きな影響を与えることが分かり、現在では最も重要な要素の一つとして認識しています。
パク:具体的にはどのような工夫をされているのでしょうか?
イ:はい。まず、Product 360システムの目的と対象データについて明確な説明をプロンプトに含めています。例えば、「このシステムは製品情報の検索と比較を目的としており、内部文書を主な情報源としている」といった具体的な説明を入れています。
また、社内で使用される専門用語の定義も重要です。同じ製品でも、開発段階では「MyView」という別称で呼ばれることがありますが、これは販売後に付けられる名称であるため、ベクターDBには存在しません。このような用語の特性を考慮し、シノニム辞書を準備して対応しています。
パク:情報ソースの扱いについても工夫されているとお聞きしましたが。
イ:その通りです。特に重要なのは、複数のデータソースを使用する際の情報の優先順位付けです。たとえば、製品仕様に関する情報は内部文書を優先し、市場動向などの情報は外部ソースも参照するといった具体的なガイドラインをプロンプトに組み込んでいます。
データの特性についても詳細に説明を行っています。各データのメタデータ情報も含めて、どのような形式でどのように保存されているかを明確に示すことで、より適切な情報抽出が可能になりました。
パク:かなり長いプロンプトになりそうですが、管理は大変ではないですか?
イ:はい、プロンプトは長くなりますが、これは避けられません。プロンプトエンジニアリングは、応答品質の核心的な部分であり、ここでの工夫が全体のシステムパフォーマンスを大きく左右します。そのため、私たちは継続的にプロンプトの改善と最適化を行っています。特に実際のユースケースから得られたフィードバックを基に、定期的な見直しと更新を行っています。
1.8 サービス導入後の効果と今後の展望
イ・ジョンウォン:Product 360は2023年9月23日にサービスを開始し、約1ヶ月が経過した時点での分析結果について共有させていただきます。私たちの主な目的は、ユーザーが適切な質問を行い、正確な回答を得られているかを確認することでした。ログを分析した結果、「電子黒板の主力モデルは何か」「LGサイネージのゲームリスプレイバック機能について教えて」といった、私たちが想定していた形式での質問が多く行われていることが確認できました。
パク:今後の改善点については、どのようなことをお考えでしょうか?
イ:はい。現在、特に注目しているのは専門家レベルの回答の実現です。例えば、室外型サイネージの推奨に関する質問があった場合、単純に製品を推奨するのではなく、「屋外用であれば輝度は700nit以上を考慮する必要があり、防水機能も必要です」といった専門的な制約条件を先に提示してから回答するような機能を検討しています。
パク:それは非常に興味深いアプローチですね。具体的な開発計画はありますか?
イ:はい。今年は4つのプロジェクトを実施し、公共入札情報の自動化は7月に、Product 360は9月末に、顧客反応センシングは5月に、営業提案書の自動生成は10月にそれぞれオープンしました。現場部門との協力が非常に重要で、要件定義から実際の利用まで、現場の声を積極的に取り入れています。
特筆すべきは、現場のユーザーが私たちの期待以上にシステムを活用していることです。その結果、高度化プロジェクトのアイデアが現場から多く上がってきており、来年度のプロジェクト設定も11月初めには完了するほど、非常に好調な状況です。
パク:開発生産性の面ではいかがでしょうか?
イ:私自身、機械学習や深層学習のプロジェクトを多く経験してきましたが、生成AIによる開発生産性の向上は驚異的です。10名に満たないチーム規模で、AWSのサポートも得ながら、企画から開発、運用までを短期間で実現できました。これは、現在のClaudeのような高性能なLLMがなければ、非常に多くの開発工数とコードが必要だったと考えています。
このように、技術の進歩と現場のニーズが上手く噛み合い、今後さらなる発展が期待できる状況です。私たちは引き続き、ユーザーの声に耳を傾けながら、システムの改善と拡張を進めていく予定です。
2. LGエレクトロニクス韓国営業部のCDP活用事例
2.1 家電産業におけるデータ活用の現状
イ・セフン(LG電子韓国営業部DX担当):韓国市場におけるLG電子の現状について説明させていただきます。一般的に家電は10年に一度程度購入する製品だと考えられていますが、最近は状況が大きく変化してきています。
パク:具体的にはどのような変化が起きているのでしょうか?
イ:はい。例えば、従来のTV、冷蔵庫、洗濯機、エアコンといった製品カテゴリーに加えて、プレミアムブランドの登場や、「3代イモニム(お母様方の生活の質向上)」といった新しい価値提案が生まれています。また、利便性家電や趣味家電といった形で、製品が細分化されてきています。
具体例として、浄水器プラス空気清浄機プラス加湿器や、家具のような外観の空気清浄機、バッグに入るTVなど、今年のヒット商品として多く販売されました。
データの観点から見ると、2024年1月時点で、LG電子の識別可能な会員数は2,000万人を突破し、年間の購買顧客数は約400万人に達しています。特筆すべき点として、従来の一括払いから定期購入型のビジネスモデルへの移行が進んでおり、定期購入による販売比率が20%以上に増加しています。
パク:そのような変化に対して、DX部門としてはどのような取り組みを行っているのでしょうか?
イ:私たちのDXミッションは、まず社員が顧客をよく理解し、サービスレベルを向上させ、センスのある顧客とのコミュニケーションを通じて良い印象を残すことです。これを実現するために、データとAIを効果的に活用することを目指しています。
特に注目しているのは、家電産業における三つの大きな変革です。第一に、趣味性が重要な家電への変化、第二に家電のサブスクリプション化によるサービス業への転換、そして第三にダイレクトチャネルの重要性の増加です。これらの変化に対応するため、データとAIを活用した新しいアプローチが不可欠となっています。
2.2 データ民主化におけるジェネレーティブAIの役割
イ・セフン:データ民主化の歴史を振り返ると、大きな変遷がありました。ビッグデータの初期段階では、SQLやPythonを使用したデータ分析は、データサイエンティストだけが行えるものでした。一般の社員は「このデータを抽出してください」とメールでデータサイエンティストに依頼する形でした。
パク:その後、GUIベースのツールが登場しましたね。
イ:はい。その後、ドラッグ&ドロップでフィルターを組み合わせるようなGUIベースのツールが登場し、SQLを知らない一般社員でも利用できるようになりました。しかし、SaaSベースのCDPを導入した際、機能が多すぎて「複雑で使えない」という声が多く上がりました。
パク:インハウスCDPへの移行はその課題を解決したのでしょうか?
イ:インハウスCDPの導入により、より最適化されたコンパクトな機能を実現できましたが、それでも「どこから始めればいいのかわからない」というフィードバックが最も多かったです。この時点で、ジェネレーティブAIが大きな転換点となりました。
一般社員が最も使いやすいコーディング言語である「自然言語」で増強分析ができるようになったことが、最大の変革点です。従来は「データを知ってからツールを使う」というプロセスでしたが、生成AIのチャットUIを通じて対話することで、「ツールを使いながらデータを理解していく」という新しい学習方法が可能になりました。
パク:それは分析の民主化という意味で画期的な変化ですね。
イ:その通りです。これにより、データサイエンティストが独占していた分析インサイトの主導権が、一般社員に移行する大きな変化が起きています。ただし、この変化を実現するためには、生成AIによる回答の正確性を担保する必要があります。特に、ビジネスデータを扱う場合、「おおよそ正しいかもしれません」といった曖昧な回答は許容されません。そのため、私たちは次のステップとしてエージェントシステムの導入を決定しました。
この進化により、データ民主化は新しい段階に入ったと考えています。一般社員がデータを理解し、意思決定に活用できる環境が整いつつあります。
2.3 CDPシステムの進化とエージェントシステムの実装
イ・セフン:CDPシステムは、顧客データを統合し安全に管理・分析する基盤として進化してきました。基本構成として、顧客データの統合、標準化、分析、予測モデルの運用、そしてマーケティングプラットフォームへのデータ連携という5つの主要コンポーネントを持っています。特に重要なのは、一般社員がデータを分析できるセルフデータディスカバリー機能です。これはデータ民主化の核心的な役割を果たしています。
パク:エージェントシステムの導入にあたって、どのような設計思想を持って臨まれましたか?
イ:自動化エージェントとしての役割を重視しました。具体的には、全体プロセスをタスクとして設定し、自然言語クエリの正規化と標準化、結果の自己検証と修正、そして推定される意図に基づく代替案の提示といった機能を実装しています。目標は、「賢く、きれいに、センスよく抽出してくれるCDP」の実現です。
パク:具体的な実装における考慮点はありましたか?
イ:はい。主に3つのキーワードを重視しました。「目標」「自律」「適応」です。これはまさに強化学習のAGIの概念と一致します。目標は、テキストToSQLやスキーマ・コードマッピングをベクターストアで管理すること。自律は、RAGのワークフローを自動化すること。そして適応は、RAG管理ツールとユーザーインタラクションを通じて継続的に方向性を調整していくことです。
CDPアーキテクチャは、データレイヤーとサービスレイヤーで構成されています。様々なソースからのデータはAmazon Redshiftに集約され、CDPエクスプロラトリアムサービスレイヤーがデータシェアリングする形で構成されています。すべてのデータはAmazon Auroraに保存され、シンプルながら効率的な構造を実現しています。
このような実装により、ユーザーは複雑なシステムを意識することなく、データにアクセスし分析を行うことが可能になりました。特に、エージェントシステムによる自動化と適応的な改善機能により、継続的なシステムの進化を実現できています。
パク:それは非常に効果的なアプローチですね。システムの特徴と利点について、もう少し具体的に説明していただけますか?
イ:最大の利点は、ユーザーが自然な形でデータにアクセスし、分析できるようになったことです。従来のような複雑な操作手順を学ぶ必要がなく、対話形式でデータ分析が可能になりました。また、システムが継続的に学習・改善されることで、より正確で有用な分析結果を提供できるようになっています。
2.4 Chat Insightサービスの開発と機能
イ・セフン:私たちのChat Insightサービスは、主に二つの主要機能を実装しています。一つ目はテキストtoSQLで、自然言語で質問すると、それを適切なクエリに変換して実行し、結果を再び自然言語で返す機能です。
パク:もう一つの機能について説明していただけますか?
イ:二つ目はテキストtoチャート機能です。ダッシュボードを閲覧する際に、自然言語で質問すると、データの要約を提供したり、適切なチャートを生成して返すことができます。これにより、ユーザーは複雑なデータ可視化ツールを使いこなす必要なく、必要な分析結果を得ることができます。
パク:対話型インターフェースの設計にあたって、特に気を付けた点はありますか?
イ:はい。最も重視したのは、ユーザーとの自然な対話の流れです。例えば、セグメントの分析を行う際、ユーザーが自然な形で質問を投げかけ、システムがそれを解釈してセグメントを作成し、その結果について分析を行い、さらにマルチターンで検索を続けられるような流れを実現しています。
実際のデモでお見せしたように、ユーザーからの質問に対して、システムは段階的に処理を行います。まず文章を分解して要件を特定し、クエリを生成してセグメントを作成し、そのセグメントを分析して自然言語で返答します。さらに、チャートの生成や、継続的な対話を促すための追加質問の提案なども行います。
パク:ユーザー体験の最適化についてはどのような工夫をされていますか?
イ・セフン:ユーザー体験の最適化において特に注力したのは、複雑な分析プロセスを意識させないことです。例えば、フィルターの推奨やマルチターンの質問誘導、分析結果に対する追加質問の提案など、ユーザーが自然に対話を続けられる仕組みを実装しています。また、既存のダッシュボード機能との連携も重視し、必要に応じて詳細な分析ツールへの誘導も行っています。これにより、ユーザーは自然な対話の中で、高度なデータ分析を実現できるようになっています。
2.5 レガシーデータの活用とサンプルクエリ収集
イ・セフン:サンプルクエリの収集は、システムの精度向上における重要な課題でした。良質な学習データを大量に用意する必要がありましたが、これを一から作成することは非常に手間のかかる作業です。
パク:その課題をどのように解決されたのでしょうか?
イ:幸いなことに、私たちには以前から運用していたGUIベースのツールがありました。このツールでは、ユーザーがドラッグ&ドロップで操作を行う際に、内部的にSQLクエリが自動生成されていました。このデータは、ユーザーには見えない形で蓄積されていました。
パク:既存データの活用方法について、具体的に教えていただけますか?
イ:はい。既存システムのAuroraデータベースからJSON形式でデータを抽出し、それを活用することにしました。ここで興味深い発想の転換を行いました。通常のテキストtoSQLではなく、SQLtoテキストという逆方向の変換を実施したのです。既存のクエリを自然言語に変換することで、より豊富なクエリと質問のセットを構築することができました。
パク:データの品質管理はどのように行われましたか?
イ:自然言語生成の段階でもハルシネーション(幻覚)が発生する可能性があるため、人間による確認プロセスを導入しました。生成されたデータセットを手動でチェックし、品質を確保しています。その後、Bedrock Embeddingを通じて埋め込みを行い、OpenSearchにインデックスを作成する流れを確立しました。
これにより、既存のシステムで蓄積された知見を効果的に活用し、新しいシステムの基盤として活用することができました。既存資産を最大限に活用することが、効率的なシステム構築の鍵となったと考えています。このアプローチにより、短期間で十分な量の高品質なトレーニングデータを確保することができました。
2.6 RAGワークフローの自動化プロセス
イ・セフン:RAGワークフローの自動化において、最大の課題は人間による検証プロセスの存在でした。これは完全な自動化を妨げる要因となりますが、システムのスケーラビリティを損なわない程度であれば、現在のLLMの技術レベルでは手動検査のステップは必要不可欠だと考えています。
パク:完全自動化は難しいとのことですが、どのように折り合いをつけられたのでしょうか?
イ:私たちは自動検査の仕組みを導入することで、この課題に対応しました。具体的には、既存のクエリを実行して得られる正解の顧客数と、自然言語に変換して再度クエリを生成して実行した結果の顧客数を比較する方法を採用しました。例えば、ある新規クエリを実行すると8万人強の顧客数が得られます。これをSQLtoテキストで自然言語に変換し、その自然言語を再度クエリに変換して実行した結果と比較します。
パク:結果が一致しない場合はどのように対処されているのでしょうか?
イ:不一致が発生した場合、通常はその質問に対応する適切なサンプルクエリが存在しないことが原因です。そのような場合、類似のサンプルクエリと質問のセットを手動で入力して補完する方法を採用しています。
アーキテクチャとしては、自動検査段階で回答数(Answer Count)を計算し、その回答を自然言語に変換したものから再度クエリを生成して実行し、テスト用の回答数(Test Count)を得ます。これらを比較して、不一致の場合は手動検査に回すワークフローを確立しています。
パク:手動検査の工数は許容できる範囲なのでしょうか?
イ:はい。現在の仕組みでは、拡張性に影響を与えない程度に手動検査の範囲を抑えることができています。また、昨日のキーノートで発表されたBedrock新機能の「Automatic Reasoning Check」を見て、今後はより効率的な検証プロセスが実現できると期待しています。このような新技術を活用することで、手動検査の範囲をさらに最適化していけると考えています。
このように、完全な自動化は目指さず、人間の判断が必要な部分は残しつつ、可能な限り効率化を図るアプローチを採用しています。これにより、品質を担保しながら、スケーラブルなシステムを実現できています。
2.7 システム性能の最適化と検証方法
イ・セフン:システム性能の最適化において、プロンプトの設計は特に重要な要素です。基本的なテンプレートとして、精緻化された(Refined)プロンプト、スキーマ情報、顧客カウント、データセットなどの情報をすべてプロンプトとして投入し、要約と可視化を行うアプローチを採用しています。
パク:具体的にはどのような形でプロンプトを構成されているのでしょうか?
イ:例えば、可視化のためのコード生成では、Plotlyを活用して特定のテンプレートに従って生成するよう指示します。これにより、一貫性のある視覚化出力を得ることができます。ただし、このようなプロンプト設計は、実際にはかなりの試行錯誤が必要で、生成AIの開発における重要なノウハウとなっています。
パク:結果の検証方法についてはいかがでしょうか?
イ:はい。検証においては、まず要約の生成を行い、その後Plotlyを使用してコードを実行し、グラフを生成します。生成されたグラフは必ずしも見栄えの良いものではありませんが、データの可視化という目的は達成しています。
ここで重要なのは、このプロセス全体が継続的な改善サイクルの一部となっていることです。生成AIの開発は、単純な実装だけでなく、多くの試行錯誤を重ねながら最適な方法を見つけていく必要があります。プロンプトの微調整、出力結果の評価、システムの改善という一連のサイクルを確立することで、徐々にシステムの性能を向上させることができています。
パク:パフォーマンス指標の設定については何か工夫されていることはありますか?
イ:各ステップでの成功率や応答時間、ユーザーフィードバックなどを総合的に評価しています。特に重視しているのは、ユーザーが求める情報に対して適切な回答が得られているかという点です。これらの指標を継続的にモニタリングし、システムの改善に活用しています。今後も実際の使用データに基づいて、最適化を進めていく予定です。
2.8 マーケティング施策への展開と今後の課題
イ・セフン:現在のシステムはインサイトレベルに留まっていますが、これを現実世界でより意味のある結果に結びつけるためには、「見る目」と「動く手」が同時に成長する必要があると考えています。
パク:具体的にはどのような展開をお考えですか?
イ・セフン:次のステップとして、マーケティングシステムとの統合を計画しています。例えば、30-40代女性というセグメントをさらに10個に分割したとしても、それぞれに対応するキャンペーンを作成するのは困難で、結局1つのキャンペーンにまとめられてしまいます。これでは分析の意味が失われてしまいます。
パク:マーケターの工数の制約が課題というわけですね。
イ・セフン:はい。そこで、次のフェーズでは自動生成の範囲を拡大したいと考えています。特に注力したいのは画像とスクリプトの領域です。Adobe Lightroomのような新技術も登場しますので、商品説明とそれに合った画像やメッセージのバリエーションを自動生成する「Auto-Gen CRM」という構想を進めています。
期待される効果としては、まずユーザー数の増加があります。データ分析の日常化を促進し、誰もがこれらのツールを活用できるようにすることを目指しています。具体的な目標として、データ抽出要請を60%削減すること、そしてキャンペーンの多様化により、現在の接点数から240%増の1,200万人の顧客接点の創出を目指しています。
パク:かなり意欲的な目標設定ですね。実現に向けての課題は?
イ・セフン:はい。特にクリエイティブの自動生成については、品質の確保が大きな課題です。しかし、生成AIの急速な進化を考えると、近い将来には実現可能になると考えています。我々の役割は、この技術をビジネスの文脈で効果的に活用し、実際の価値創出につなげることだと考えています。
3. 主要な知見と教訓
3.1 ユーザー中心のサービス設計の重要性
イ・セフン:CDP実装を通じて学んだ最も重要な教訓の一つは、ユーザーが「何を知らないのかを知らない」という点です。これは決してユーザーの無知を指摘するものではなく、データ分析を始めようとする際の一般的な心理状態を表しています。
パク:その課題にどのように対応されたのでしょうか?
イ・セフン:生成AIチャットの価値は、対話を通じて質問を継続的に展開できる点にあります。これが通常の検索と生成AIチャットの決定的な違いです。ユーザーが新しい発見をできるよう支援することこそが、生成AIの最も重要な価値だと考えています。
パク:具体的な実装面での工夫はありましたか?
イ・セフン:はい。重要なのは、ユーザーに「必要な情報を抽出してください」と依頼させるのではなく、自ら能動的に情報を引き出せるようにすることです。これが組織全体のデータ活用能力向上に大きな影響を与えると考えています。
実際の導入プロセスでは、継続的なフィードバックループの確立が重要でした。例えば、ユーザーの質問パターンを分析し、よく使用される機能をメニューとして整理したり、製品比較機能のように一見シンプルでも営業担当者から高い評価を得た機能を重点的に改善したりしています。
パク:システムの改善サイクルについてはいかがでしょうか?
イ・セフン:私たちは、ユーザーの実際の使用状況を常にモニタリングし、システムの改善に活かしています。例えば、「電子黒板の主力モデルは何か」「LGサイネージのゲームリプレイバック機能について教えて」といった質問が、想定通りの形で行われているかを確認し、必要に応じて機能の調整を行っています。
このように、ユーザー中心の設計思想を徹底することで、技術的に優れているだけでなく、実際の業務で本当に役立つシステムを実現することができました。これは今後の開発においても最も重要な指針となると考えています。
3.2 情報フロー最適化の必要性
イ・セフン:AIプロジェクトの実装において、非常に残念なことに、サンドボックス内での開発に留まり、実際の適用段階で情報部門との調整などの問題で頓挫してしまうケースを数多く見てきました。この経験から、情報フローの全体最適化の視点が極めて重要だと実感しています。
パク:具体的にはどのような対策を取られましたか?
イ・セフン:最も重要なのは、開発の初期段階から情報の流れを考慮することです。私たちの場合、最終的にマーケティングプラットフォームまでデータが流れる必要があることを念頭に置いて、システムを設計しました。単にデータを分析できるというだけでなく、その分析結果が実際のマーケティングアクションにつながるまでの一連の流れを考慮する必要があったのです。
パク:システム間の連携についてはどのような工夫をされましたか?
イ・セフン:開発初期の段階から、既存のシステムとの接続性を重視しました。例えば、CDPシステムとマーケティング実行システムとの連携において、データの形式や転送方法などを事前に検討し、システムの設計に組み込みました。また、将来的な拡張性も考慮し、モジュール化された設計を採用しています。
特に注意したのは、情報セキュリティの観点です。顧客データを扱う以上、セキュリティは妥協できない要素でした。そのため、データの流れの各段階で適切なセキュリティ対策を実装し、かつ業務効率を損なわないバランスを取ることに注力しました。
パク:実装における具体的な注意点はありましたか?
イ・セフン:はい。例えば、データの流れが途切れないよう、各システム間のインターフェースの標準化や、エラー発生時の対応手順の明確化などを徹底しました。また、システム全体のパフォーマンスを考慮し、必要な箇所でのキャッシュの活用や、非同期処理の導入なども行いました。重要なのは、これらの技術的な実装を行う前に、まず全体の情報フローを明確に設計し、関係者間で合意を形成することでした。
3.3 生成AIの補助的役割とユーザー体験の優先
イ・セフン:生成AIプロジェクトを進める中で、AIは主役ではなく、あくまでも脇役であるべきだという重要な気づきを得ました。特に重要なのは、ユーザー中心のサービス企画です。ユーザーがどのように望むインサイトを素早く見つけられるかという経路設計が核心であり、そのために適材適所で生成AIを費用対効果の高い形で活用することが私たちの役割だと考えています。
パク:それは興味深い視点ですね。具体的にはどのような形で実践されましたか?
イ・セフン:例えば、単にナイーブなRAGシステムを実装するのではなく、ユーザーの意図を理解し、適切な情報源を選択し、正確な回答を生成するまでの一連のプロセスを設計しました。ここでは、生成AIはあくまでもツールとして活用され、主体はユーザーの情報探索プロセスにあります。
パク:コスト効率の観点からはどのような工夫をされましたか?
イ・セフン:生成AIの利用コストは決して安くありません。そのため、例えば単純な製品スペックの問い合わせには直接データベースを参照し、より複雑な比較や分析が必要な場合にのみ生成AIを活用するなど、適切な使い分けを行っています。また、キャッシング機能の活用なども含めて、コストを最適化するための工夫を重ねています。
特に実用的な価値の創出という観点では、私自身、機械学習や深層学習のプロジェクトを多く経験してきましたが、現在のClaudeのような高性能なLLMを活用することで、開発生産性が劇的に向上しました。10名にも満たないチーム規模で、企画から開発、運用までを短期間で実現できたのは、まさにこのアプローチの成果だと考えています。
パク:今後の展望についてはいかがでしょうか?
イ・セフン:はい。現在は主にインサイト抽出のレベルですが、今後はより実践的な価値創出を目指しています。例えば、マーケティング施策の自動生成など、より直接的なビジネス価値につながる領域への展開を計画しています。ただし、ここでも生成AIは補助的な役割に徹し、最終的な判断や意思決定はあくまでも人間が行うという原則は変わりません。
この考え方は、私たちのプロジェクトの成功に大きく貢献したと確信しています。技術に振り回されるのではなく、実用的な価値の創出を常に念頭に置いた開発アプローチが、今後も重要になってくると考えています。