re:Invent 2024: Principal Financial GroupのAmazon Q Business活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How Principal Financial improved productivity with Amazon Q Business (AIM228)
この動画では、Principal Financial GroupにおけるAmazon Q Businessの導入事例が詳しく紹介されています。Amazon Q Businessは企業全体のデータを活用してGenerative AIアシスタントとして機能し、SharePoint、Confluence、Jiraなど40以上のOut-of-boxコネクタを持ちます。Principal Financial Groupでは、9,000ページ以上の業務マニュアルを扱う300人以上のチームで導入し、84%の精度で正しい文書を返せるようになりました。メタデータの品質向上、ユーザー教育の重要性、AIガバナンスの確立など、導入における具体的な課題と解決策が示されており、過去90日間で600人のアクティブユーザーが業務の50%削減を実感するなど、具体的な成果も報告されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q Businessの紹介と背景
皆様、こんにちは。ご参加いただき、ありがとうございます。re:Inventの木曜日の午後3時半というお時間にもかかわらず、本日は充実したコンテンツをご用意しております。具体的には、Principal Financial Groupの事例を通じて、Amazon Q Businessによって生産性をどのように向上させることができたかをご紹介いたします。私はAmazonのAmazon Q Business のワールドワイドGo-to-Marketヘッドを務めるAlicia Trentです。Amazonに入社して約4年になりますが、本日はQ Businessの機能と、Principal Financial Groupのような顧客の生産性向上にどのように貢献しているかについてご説明させていただきます。Principal Financial GroupのNickiさんと一緒にプレゼンテーションを行い、彼女から顧客事例の詳細についてお話しいただく予定です。
まず背景として、Amazon Qは皆様のGenerative AIアシスタントです。今年の4月30日にローンチされました。Amazon Q Businessの目標は、ソフトウェア開発者からエンジニア、マーケティング担当者、営業担当者まで、企業全体のアシスタントとなることです。私たちは、組織内でGenerative AIの機能を活用できるようにしたいと考えています。4月30日のローンチ以来、数万もの顧客からフィードバックをいただいています。今週初めには、Volkswagen（VW）がAmazon Qを活用してHRオンボーディングを加速させている事例や、JelがAmazon Q Businessで業務を効率化している事例についてお聞きしました。
Amazon Q Businessの機能と統合
これらの事例から、いくつかの共通のテーマが見えてきました。まず何よりも重要なのは、Generative AIがビジネスを理解する必要があるということで、それはデータから始まります。Amazon Qおよび私たちのサービスは、お客様の業務環境に対応できる必要があります。Amazon Q発売当初は、主にWebサイトやAPIを通じての利用が中心でしたが、その後、ブラウザ拡張機能やSlack、Teams など、様々な場所でAmazon Q Businessを利用できるよう機能を追加してきました。これにより、お客様にとってより多くの価値を提供できることがわかってきました。
データを理解し、業務環境で利用できるようにするだけでなく、次のステップとしてアクションを起こせることが重要です。多くのお客様から、これらのツールでどのようにROIを向上させるかについて質問を受けています。コンテキストを提供し、業務環境で機能することは素晴らしいのですが、企業全体に展開するには生産性の向上を実現する必要があります。Amazon Q Businessは、SharePoint、Confluence、Jiraに保存されているPDFファイル、Excelファイルなど、様々なファイル形式やリポジトリにまたがる組織全体のデータを活用できるシステムとして構築されています。私たちはRetrieval Augmented Generation（RAG）というシステムを活用して、これらのデータを共通のフォーマットに変換し、Amazon Q Business内でこれらの情報を活用できるようにしています。
Amazon Qは、様々な機能を持つファミリーの一部です。先ほど申し上げたように、私たちはAmazon Qを様々な機能にわたる企業のアシスタントにしたいと考えています。Amazon Q Businessは、Nickiが詳しく説明する予定ですが、ビジネスユーザーをサポートする機能です。また、ソフトウェア開発ライフサイクルを改善するAmazon Q Developerもあります。先ほど紹介されたAvailの例では、Amazon Q DeveloperとAmazon Q Businessの両方を活用して、組織全体のソフトウェアドキュメントとコーディング品質を向上させています。さらに、組織内で使用している可能性のあるBIツールであるQuickSight、Connectなどのコンタクトセンター、AWS Supply ChainなどのサプライチェーンアプリケーションにもAmazon Qの機能を組み込んでいます。
Principal Financial Groupの事例：課題と実装
Amazon Q Businessの設計における背景をご説明させていただきますと、私たちは皆様のような組織をサポートするために以下のような中核的な原則を活用しています。第一に、ユビキタス性、つまり仕事をする場所ならどこでも利用できるようにすることです。例えば、Slackがメインのコミュニケーション手段である場合、Amazon Q Businessはそこに存在し、リポジトリ全体での質疑応答やアクションの実行が可能です。ブラウザやTeams内で主に作業をする場合でも、Amazon Q Businessは作業場所に常駐し、組織全体でのイノベーションの促進を支援できます。
例として、私たちはAmazon Q BusinessをAmazon Web Services (AWS)内で最初にリリースしました。最初はWebブラウザでリリースし、素晴らしい反響を得ましたが、Slackチャンネル内で利用可能にし、ブラウザ拡張機能も活用することで、組織内でのAmazon Qの使用率を10〜15倍に増やすことができました。このように、Amazon Q Businessへのアクセスの手順を1つ減らすだけで、Generative AIの活用において大きな進歩となりました。
他の重要な領域は信頼性に関するものです。多くの組織にとって、適切な回答を提供することが重要です。Amazon Q Businessでは、これをさまざまな方法で実現しています。その一つが情報のパーソナライゼーションで、役割情報や場所情報を取り入れて、必要に応じたカスタマイズされた回答を提供します。例えば、日本のデータサイエンティストの場合、米国でマーケティングメッセージを探している担当者と比べて、より詳細で長文の回答を得ることができます。これらは、Amazon Q内で最も関連性の高い回答を確実に得るための機能です。そして最後に、プロアクティブな対応について、Amazon Qは最近ワークフローを認識する機能をリリースしました。Amazon Q内で、提案依頼書の提出やメッセージの送信など、繰り返し行うタスクがある場合、Amazon Q Businessがタスクの効率化を推奨する方法を提案できます。
Amazon Q Businessの目標は、組織全体のデータを活用して、質問に対して関連性が高く正確な回答を提供することです。まず第一に、組織内の権限や認証を継承することを確実にします。管理者は、QやLLMへのアクセス権を制御できます。さらに、Q Business内の特定のドキュメントへのアクセス権がある場合、それらのドキュメントにのみアクセスできます。つまり、私と他の人が同じ質問をAmazon Q Businessにした場合、それぞれのドキュメントへのアクセス権が異なるため、おそらく異なる回答を得ることになります。
Amazon Qでは、様々な種類のリポジトリを活用することができます。組織内で使用している40以上のOut-of-the-boxコネクタがあります。SharePoint、Confluence、Jira、ServiceNowなど、多数のコネクタがAmazon Q内でOut-of-the-boxでデータソースに接続できます。また、組織からのフィードバックに基づいて、Amazon Qにガードレールを提供する機能も追加しました。多くの組織が作成を望まないブロックワードコンテンツや、LLMを使用せず逐語的な回答が必要な機密性の高いトピックなどに対して、ガードレールを設定することができます。そして最後に、Q Business上でアプリケーションを作成する機能があります。Q Business内では、作業の効率化のための軽量アプリケーションを作成できるQ Appsをリリースしました。
エンドユーザーの視点からAmazon Q for Businessを見ると、Generative AIによるハルシネーション（誤った情報の生成）に関する懸念があることがわかります。しかし、Amazon Q Businessでは、提供される回答に対する参照情報と、その回答の文脈に関する抜粋情報も併せて提供しています。Amazon Q内では、様々なフォルダやファイルを検索し、その中から情報を見つけた箇所の抜粋を確認することができます。これにより、ユーザーはその回答が信頼できるものかどうかを即座に判断できます。画面下部には情報ソースが表示され、クリックすることで探している情報が正しいものかを確認できます。
さらに、Amazon Q Businessのもう一つの重要な機能として、Index Boostingがあります。お客様からよく聞くのは、多くの文書があり、それらが異なるフォルダや異なるリポジトリに存在する中で、複数の参照や改訂版が存在するという課題です。これにより、Generative AIが適切な文書を選択することが難しくなる可能性があります。しかし、この機能を使用することで、特定のファイルタイプ、ファイルフォルダ、設定したタグ、あるいは文書の作成時期に基づいて優先順位付けができます。例えば、2～3年前に作成された文書よりも、より最近作成された文書を優先的に選択することも可能です。 Amazon Q Businessのもう一つの重要な領域は、新しいコネクタを追加することで、新しいユースケースを継続的に開拓していることです。
データ管理とメタデータの重要性
現在、JiraやServiceNowへのコネクタがあることで様々なユースケースをサポートしており、さらにConfluenceやSharePointなどのナレッジマネジメントシステムへのコネクタも追加しています。また、今年初めに発表したSmartsheetsのような生産性向上ツールへのコネクタも追加し、Amazon Q Business内での生産性を向上させています。
Amazon Q Businessの基本原則は、企業として回答を信頼できることを確保しながら、情報にアクセスする各ユーザーが適切な権限を持っていることを保証することです。このチャートを見ていただくと、Amazon Q Businessは文書内の権限を自動的に尊重していることがわかります。Amazon Q Business内でSalesforceから文書を取得する際、それらのファイルに関連付けられたメタデータとアクセス権を取得し、各ユーザーの文書に対する権限を尊重します。これはQ Business全体の様々なリポジトリで実現できます。さらに、権限設定内で、異なるユーザーに対してパーソナライゼーションを提供するためのルールやユーザーロケーションを設定できます。
Amazon Q Businessのもう一つのオプションは、先ほど述べたガードレールを設定する機能です。多くのお客様は、給与報酬や個人の福利厚生、ニュースで取り上げられている事項など、特定のセンシティブな単語に関して懸念を持っています。Amazon Q Business内では、このようなコンテンツをブロックするための特定のルールを設定できます。さらに、特定のユースケースでは、お客様がLLMを使用したり文脈化された応答を受け取ることを望まず、逐語的な応答を求める場合があることがわかってきました。Amazon Q Business内では、特定の質問に対して逐語的な応答を受け取るか、まったく応答を受け取らないかを選択できます。これらは、Q Businessからの応答を信頼できるようにしたり、組織にとって不適切と判断される応答をブロックしたりするための優れたオプションです。
Amazon Q Businessでは、いくつかの重要な分野の可能性を開放しています。まず、Retrieval-Augmented Generationを通じたコンテンツの発見と、標準フォーマットでのドキュメント提供により、組織全体のデータを活用できるようになります。例えば、研究対象の動物に関するファイルと、その動物の計測データがあるとします。これまでは、これら2つのデータソースを組み合わせて比較することは困難か、手作業に頼らざるを得ませんでした。Amazon Q Businessは、この機能を実現し、こうした情報について質問し、発見することを可能にします。
また、組織内で処理できるデータタイプとフォーマットの数も拡大しています。Amazon Q Businessでは、表形式データを扱える機能を導入しました。これにより、以前はテキストファイルやPDFファイルしか処理できなかったところが、10-Kドキュメントのような複雑な文書も分析できるようになりました。現在では、ドキュメント内の表や画像を処理し、複数のドキュメントを比較することができます。これにより、Amazon Q Businessで情報を分析する新しい方法が可能になりました。
作成とアクションの実行に関して、Amazon Q Businessでは生産性向上をサポートする50種類のアクションを実行できます。以前のAmazon Qでは情報検索のみが可能でしたが、現在ではチケットの更新や、自分に割り当てられたJiraやServiceNowのチケットの検索、さらにそれらをAmazon Q Business内で更新することができます。これらの機能により、何らかのアクションを実行するためにAmazon Q Businessを離れる必要がなくなり、組織全体でAmazon Q Businessをより簡単かつ生産的に活用できるようになります。
Q Appsは、Amazon Q内の魅力的な機能です。Amazon Qの活用方法を理解する中で、自然言語を使用してミニアプリケーションを作成し、デスクトップに配置することができます。例えば、提案依頼書（RFP）の提出を1日に30〜40回行っている場合、そのプロセスを複製することができます。つまり、情報の検索、RFPやテンプレートの入力を行い、それをデスクトップに配置して、RFPの使用頻度に応じて毎日または毎時間ごとにそれらのRFPを繰り返し処理することができます。
Amazon Q Businessには、エンジニアリングから営業、マーケティングまで、私たちが目にする多くのユースケースがあります。コンテンツの発見、分析からアクションの実行、そしてそれらのアクションの自動化まで、私たちが共有した機能全体にわたって活用されています。皆様のご意見もぜひお聞かせいただきたいところですが、まずはPrincipalのNickiから、ベータ版以前からAmazon Q Businessをどのように始め、生産性向上のために私たちがどのように協力してきたかについて、お話しいただきたいと思います。
Principal Financial Groupの取り組みと成果
Aliciaさん、ありがとうございます。また、本日お集まりいただいた皆様にも感謝申し上げます。Amazon Q Businessについての Principal Financial Groupの取り組みと、優れた顧客体験の提供にどのように活用しているかについてお話しできることを大変嬉しく思います。まず最初に申し上げたいのですが、皆様と同様、私も今週は多くのセッションやイベントに参加してきて、声が少し出にくくなっています。お聞き苦しい点があるかもしれませんが、ご了承いただければと思います。
過去145年間で、私たちは保険、従業員福利厚生、米国での退職金サービスから、国際的な年金とグローバルな資産運用へと事業を拡大し、現在では80以上の市場で6,800万人以上のお客様にサービスを提供しています。これは、中間層の拡大や世界の高齢化といった人口動態の機会と、私たちの差別化要因を効果的に捉えることで実現してきました。145年の歴史を持つ企業を未来に向けて変革するということは、19,000人以上の従業員の経験と専門知識を、お客様のためにより良く活用することを意味します。
それは、より良い投資パフォーマンスとより良い顧客体験を提供するために、これらの差別化要因をより効果的に活用する方法を常に探求することを意味します。Principalは、人生をスタートしたばかりの方から、すでに強固な財務基盤を確立している方まで、あらゆる人々のための企業であることを誇りにしています。機械学習、人工知能、Generative AIに関して、私たちはこのテクノロジーが事業に大きな影響を与える可能性を信じており、その使用は慎重に管理される必要があり、従業員には探求が奨励され、同時に自身の行動に責任を持つことが求められると考えています。
私たちの業界では、お客様に寄り添い、サポートするために、人間的なタッチとテクノロジーの両方が重要なミックスとなっています。決定の複雑さや重要性に応じて、お客様は正しい選択をしているという確信を得るために、デジタル体験と人との対話の組み合わせを必要としています。このプレゼンテーションでは、私たちのGenAI搭載の従業員アシスタントである Principal AI Generative Experienceの重要な部分として、Amazon Q Businessをどのように活用しているかについてお話しします。ここでの私の目的は、この変革の旅がどこから始まり、どこに向かっているのか、そして課題や機会、そして最も重要な学びについて、私たちのストーリーをお伝えすることです。
始めましょう。 ChatGPTが登場して世界中を驚かせたあの時のことを、私たちは皆覚えているはずです。しかし、Retrieval Augmented Generation（RAG）という概念が生成AIと密接に結びついた時、業界は大きな転換期を迎えました。私は育児休暇から戻ってきた時のことをはっきりと覚えています。その3ヶ月間、意図的に外界との接触を断っていたのですが、ちょうどそこにいらっしゃる私の上司が、できるだけ早くRAGソリューションを実装する必要があると言ったのです。正直に言うと、その時は皿拭き用の布のことを話しているのかと思って、かなり混乱してしまいました。
当時、私たちの企業には知識リソースが散在していることは分かっていました。これらのリソース内での検索は非効率で、リソース全体を横断して検索することはほぼ不可能な状態でした。私たちは少数のユーザーを対象とした小規模なProof of Conceptから始めました。最初の大規模なユースケースに焦点を当てると、300人以上の従業員が1つのチームに所属し、大量の問い合わせに対応していました。2023年だけでも、このチームは68万件以上の個別の顧客ケースを処理しました。それぞれのケースで、9,000ページ以上の業務マニュアルを検索して、顧客に適切な回答を見つけ出さなければなりませんでした。さらに、このチームでは、役割を完全に習得して効率的に業務をこなせるようになるまでに平均1.5年かかっていました。
これらすべての知識ソースと断片化された知識ベース、そして自然言語を使って横断的に検索できないことが、明確な業務上のボトルネックを引き起こしていることが分かっていました。そしてそれは私たちが解決すべき課題でした。
プロジェクトの開始時点で、企業全体から大量の非構造化データを検索・集約するシステムが必要不可欠だと認識していました。データはAmazon S3、SharePoint、Confluence、その他多数のプラットフォームなど、様々な場所に保存されていました。ファイル形式もHTMLやASPXページ、Word文書、PDF、Excelスプレッドシート、PowerPointプレゼンテーションなど多岐にわたっていました。金融サービス業界で事業を展開している私たちには、厳格な規制とコンプライアンス要件があり、従業員が許可された情報にのみアクセスできるよう、厳密なロールベースのアクセス制御が必要でした。長期的にはプラットフォームを所有してカスタマイズできる能力を維持しながら、大規模な事前コーディングなしで迅速に展開できるソリューションが必要だと分かっていました。
私たちの取り組みは2023年9月末に始まりました。これはre:Invent 2023でのAmazon Qのパブリックプレビュー発表よりもずっと前のことです。開始当時、私たちはAmazon Qの存在すら知りませんでしたが、チームにはAWSソリューションを使用してきた実績とAWSエンジニアリングチームとの協力関係がありました。そこで、AIアシスタントのコアプラットフォームとしてQnABot on AWSを使用することにしました。QnABotはAmazonの生成AIサービスとシームレスに連携する会話型マルチチャネルインターフェースで、これにAmazon Lex Web UIソリューションを組み合わせることで、私たちの企業アイデンティティに合わせてカスタマイズしたUIを展開することができました。
この解決策の第一版は、構想から3ヶ月足らずの2023年12月初旬にデプロイされました。このスライドでご覧いただいているのは、当時稼働していたソリューションの概要図です。Amazon S3バケットからの情報検索にはAmazon Kendraを使用し、情報の要約にはAmazon Bedrockを通じてAnthropic Claudeを活用していました。これは非常にうまく機能し、AIアシスタントのProof of Conceptをテストして、貴重なユーザーフィードバックを収集することができました。
Amazon Qへの移行を決めた理由は非常に明確でした。 ハイパーパラメータのチューニングからアーキテクチャ全体、ユーザーアクセス、データ管理、Prompt Engineeringまで、すべてを管理することは私たちの小規模なチームにとって非常に大きな負担でした。ロードマップは新しいアイデアで常に拡大していました。幸運なことに、Amazon Qサービスのプライベートプレビュー前にその情報を知ることができ、すでにAmazon Qチームと連絡を取っていました。QnABotチームとの関係があったおかげで、彼らは直接Q APIへの統合を迅速にコーディングすることができました。
Amazon Q Businessの実装と課題
冗談めいた話ですが、かなりの期間、私は自分のチームよりもQチームとQnABotチームと一緒に仕事をしていました。そのおかげで、2024年1月の第1週に文字通り一晩でAmazon Qへの移行ができました。ベータプラットフォームを採用することには課題があることは承知していましたが、すぐに成果が見え始めました - レスポンスは速くなり、エンタープライズチャットボットソリューションにより適したものになりました。 最終的なソリューションは、QnABot on AWS、AWS Lex Web UI、Amazon Q for Businessを統合し続けていますが、ユーザーフィードバック、私たちのロードマップ、Amazon Q Businessのロードマップに基づいて常に進化を続けているので、「最終的」という言葉は適切ではないかもしれません。
現在も数多くのAmazonサービスを活用しています。インテント・ルーティングにはAmazon OpenSearchとLexを、認証のためのCloudFrontと連携したIDPなど、多数のLambda関数を使用しています。中央にある小さなAmazon Qのボックスが、私たちが自己管理で苦労していたAI/MLやデータ検索の統合のすべての重荷を軽減してくれました。
さらに、ユーザーが受け取った回答について、良いものも悪いものも含めてフィードバックを提供できるカスタムフィードバックワークフローを実装しました。回答の正確さや、提示された文書の関連性を評価できるようになっています。また、ユーザーが自由にテキストでフィードバックを入力できるようにしており、それらの分析も行っています。会話が発生するたびに、プロンプト、レスポンス、関連するメタデータなど、すべてをAmazon Kinesis Data Firehoseを通じてAmazon OpenSearchにログとして記録し、それをAmazon S3バケットにバックアップしています。これにより、Amazon AthenaやAmazon QuickSightなどのレポーティングツールと統合して、重要な洞察を得ることができます。
私たちは定期的に、トピック、意図、感情、プロンプトの長さと詳細性、そして考えられるあらゆる指標について分析を行っています。これにより、プラットフォームがどのように使用されているか、適切な回答とドキュメントが得られているか、そしてこのプラットフォームのロードマップ戦略をさらに改善できるかを確認しています。 では、本番環境で実行している内容の概要をご理解いただいたところで、このソリューションを実装する際に直面した課題と機会についてお話ししましょう。
最初の大規模ユースケースでは、 SharePointリスト内に保存された数千ページのASPXページをインデックス化する必要がありました。始めた当初、当時のSharePointコネクターではこのタイプのページをインデックス化できないことが分かりました。なぜなら、ASPXページは特にページ読み込み時に動的にコンテンツが生成されるため、サーバー上でレンダリングする必要があったからです。Amazon Qチームとのパートナーシップを通じて、すぐに機能リクエストを提出することができ、1ヶ月以内に実装されたことで、このユースケースを進めることができました。
この話をするのは、トラブルシューティング中に得られた洞察があったからです。皆さんもご存知の通り、トラブルシューティングを通じて、データやデータコネクター、そしてプラットフォームの仕組みについてより深く理解することができます。私たちはこの問題に対する回避策を試してみました。ユーザーに少し変わった方法をお願いしました：SharePointで必要な情報が載っているページを見つけ、PDFに印刷して、チャットに添付してクエリを実行するという方法です。これは明らかに分散検索や動的コンテンツ生成の要件は満たしていませんでしたが、ユーザーは自分のデータが準備できているかをテストし、データにアクセスするための効果的なプロンプトの書き方を学ぶことができました。現在では、データコネクターの設定を試みる前に、新しいユースケースのユーザー全員にこの方法を実践してもらっています。各ユースケースの成功に向けて小さな段階的なステップを踏むことを学び、これまでのところ、この戦略は非常に成功を収めています。
次の課題は、145年の歴史を持つ企業であることに大きく関係しています。この期間で、私たちは膨大なデータを蓄積してきました。完全に廃止された旧来のシステム、現代化された旧来のシステム、そしてその中間の状態にある旧来のシステムが存在します。多くの方々にとって、この状況は身に覚えがあるのではないでしょうか。皆さんの環境に1つ以上のレガシーシステムがあると言える方は何人いらっしゃいますか？2023年当時、これらのレガシーシステム内のデータはすべて人間が読みやすく理解しやすいように論理的に整理されていました。これは、人間がデータの主な消費者だったため、理にかなっていたのです。
Fox、CNN、あるいはレシピサイトなど、普段アクセスするWebページについて少し考えてみてください。あなたの頭の中で論理的に整理された方法で、リンクをクリックしながらネストされた関連ページを辿っていきます。しかし、同じページ群がAmazon S3やSharePoint、Confluenceなどのバケットに保存されている状態を考えてみてください。それは単に非構造化データを含むオブジェクトが平坦な形式で存在しているだけです。ページ間に参照は存在するかもしれませんが、これらのページを結びつけているのは、作成したメタデータによるリンクだけなのです。
さらに、私たちには処理しきれないほどの大量のデータがありますが、その多くが非常によく似た用語を含んでいます。 例えば、グループとメンバー、メンバーグループ、個人メンバーなど - これらはすべて明確に異なる用語なのですが、システムはこれらをすべて同一のものとして扱っていました。誰かが個人メンバーの補償追加方法を尋ねても、システムはグループメンバーの手順を返してしまうのです。経験豊富な担当者はすぐにこの不一致に気付きましたが、新入社員がこれを使用する場合を想像してみてください。彼らはこの違いに気付いたでしょうか？私自身、テスト時には気付きませんでした。その上、ユーザーが探している情報やポリシー、手順は多くの場合1ページに収まっているのに、2,358ページ分の情報を要約していたのです。
これは過度な要約、不正確なポリシー、そして不適切な手順につながりました。ユーザーは返される結果を信頼できなくなってしまいました。では、これをどのように修正したのでしょうか？
この問題に対して多くの対策を講じる必要がありましたが、まず何よりも重要だったのは、ビジネス部門と協力して使用するデータとメタデータを本当に洗練させることでした。Amazon Q Businessのドキュメント関連性チューニング機能を使用して、特定のメタデータフィールドにより重み付けを強くしたり弱くしたりすることができました。Amazon Qの機能の1つとして、SharePointコネクターからカスタムメタデータを取り込むことができますが、リスト内のページについては取り込めません。これは私たちのデータ構造そのものでした。そこで、カスタムメタデータを取り込む方法を見つける必要があることにすぐ気付きました。Amazon Qが既に取り込んでいた作成時刻などの標準メタデータに加えて、手動のタイトルも既に持っていました。
最初は、Python Lambdaを使用してSharePointサイトからカスタムメタデータを取得していました。しかし、メタデータは人間向けに作られていたため、不足していたり、不正確だったり、十分に詳細ではないことが分かり、それだけでは不十分でした。そこで、Amazon Q Businessを通じたドキュメント拡充という新しいアプローチを実装することにしました。インデックス作成時に、SharePointページのコンテンツすべてをAmazon Bedrockに送信し、キーワード、展開・省略された頭字語、カスタムサマリーなどのカスタムメタデータを生成します。これをDynamoDBテーブルに送り、メタデータチューニング時にファイルに添付します。
これにより、84%の精度を達成することができました。実際に定量的な指標を得ることができたのは、この信頼できるソースを使用して、プロンプト、出力、およびドキュメントを、メタデータチューニング機能をプログラムで変更しながら、関連性チューニングを通じてプログラム的に実行したからです。この作業を始める前は、精度はわずか67%でした。つまり、67%の確率で正しいドキュメントを返していたということです。組み合わせによっては精度が43%まで低下することもありました。これは悪い数字です。とても悪い数字です。しかし、このことを取り上げたのは、プラットフォームの正確性と信頼性を確保するために、このようなテストが非常に重要であることを示しているからです。
さらに、Amazon Q チームは top K と呼ばれる機能を実装することができました。これにより、返される文書の数を選択できるようになりました。このユースケースでは、1件を返すように設定しました。この機能と私たちのメタデータチューニングを組み合わせることで、9,000以上のASPXページのディレクトリから、約84%の確率で正しい文書を最初に返すことができるようになりました。この話題なら何日でも話せますね。私はデータサイエンスのバックグラウンドを持っているので、Q&Aセッションでもっと詳しくお話しできます。
今、みなさんは「84%しかないのか」と思っているかもしれません。しかし、その大部分は次の課題に関連していると考えています。それは、ユーザートレーニングと教育の必要性です。プラットフォームの展開を始めた時、ユーザーがAIアシスタントとしてではなく、検索エンジンとして「COBRAとは何か」といった使い方をしているという傾向に気づきました。この過程で、このAIアシスタントが企業全体でより広範な影響を与える可能性があることにすぐに気づいたため、企業データへのアクセスなしでプラットフォームを使用できる一般的なエンタイトルメントも展開することにしました。
この点を今お話しするのは、同様の相関関係に気づいたからです。より複雑で詳細な、よく練られたプロンプトの方が、ポジティブなフィードバックを得られる可能性が高かったのです。短いプロンプトや、あまり意味をなさないプロンプトは、ネガティブなフィードバックを受けるか、まったくフィードバックがない傾向にありました。AIはツールです。パワフルで素晴らしいツールですが、どんなツールでも効果的に使うにはスキルが必要です。ここから私たちの本当の旅が始まりました。ユーザーに自然言語処理やAIとの対話方法、そしてPrompt Engineeringについて多くのことを教える必要があることを認識したのです。
このユーザートレーニングと教育の必要性は、現在も直面している課題です。しかし社内では、Prompt Engineering、Generative AI、そして私たちがよく知っているような楽しい要素について、オンデマンドでユーザートレーニングと教育にアクセスできるスキル開発サイトを立ち上げました。また、デモにも力を入れました。というのも、開始当初は「可能性」を示すことをあまりしていませんでした。単に「これがアシスタントです、楽しんでください」と言うだけでした。しかし、私たちは従業員の創造性を引き出したいと考えていました。
可能性は無限大です。AIの活用は、彼らの創造性によってのみ制限されます。プラットフォームをより効果的に使用できるように、それを実証し教えるのは私たちの役割だったのです。
最後に取り上げたい課題は、ガバナンスについてです。これは私たちが直面したもう一つの大きな課題でした。Principalには非常に確立された堅牢なガバナンスプログラムがあり、当初はそれに合わせようとしました。しかし、すぐに課題に直面しました。データガバナンスはデータのライフサイクル全体を通じて、品質、整合性、セキュリティ、使用可能性に特化して対応するのに対し、AIガバナンスは企業全体でより広範な役割を担うからです。そこで私たちは、Principal内で新しいAIガバナンスプログラムの枠組みを作り始めました。これは、プラットフォームのライフサイクル全体を通じてAIガバナンスに焦点を当て、AIを倫理的かつ責任ある方法で使用し、適用されるすべての規制や、企業のバイアス、倫理、価値観に関する規制を遵守することを確実にするものです。
私たちは、イノベーションをサポートするだけでなく、潜在的なリスクからも保護するフレームワークを本当に持ちたいと考えていました。また、ユーザーのプロンプトやレスポンスをモニタリングできるのか、そして例えば業績評価のような機密情報を入力する際に、それがプラットフォームへの信頼にどのような影響を与えるのかという問題にも直面しました。AIガバナンスのリーダーたちは、このようなプロンプトのモニタリングは、観測可能性やバイアスに関する規制を満たすために不可欠だと述べています。また、このプラットフォームからの投資対効果と価値を効果的に証明するために、これらのメトリクスを持つことが重要です。重要なのは、この情報を安全に保存することであり、私たちはそれを実践しています。今日は詳しく説明する時間がありませんが、内部のAIソリューションを構築する際には、堅牢なAIガバナンスプログラムが重要であることを強調しておきたいと思います。
プラットフォームの現状と学んだ教訓
では、現在このプラットフォームは実際にどのように使われているのでしょうか？プラットフォームへのアクセス権を持つユーザーは約800人で、過去90日間のアクティブユーザーは600人です。定性的には、これらのユーザーの多くが、一部の業務で少なくとも50%の作業削減を実感していると述べており、これは素晴らしい成果です。ログには数万件のクエリが記録されており、97%以上が受け入れられるか、さらに改善されており、ネガティブなフィードバックは3%にとどまっています。AIには成長痛がつきものですが、この数字がこれほど低いことを非常に嬉しく思っています。
ユーザーたちは、基本的な分析から顧客フィードバックのマッピング、カスタマージャーニー分析、さまざまなトーンでのコミュニケーションの書き直しまで、日々の業務でこのプラットフォームを様々な目的に使用していると述べています。全体として、データが私たちのテナントから外部に出ることがないという安全性を備えたこのプラットフォームを使用することで、社内の知識と内部データに基づいて洞察を生み出すことができています。顧客からは、明確で自信のある言葉遣いでレスポンスできるため、私たちが目指している一回での解決（ワンコンタクトレゾリューション）に本当に役立っているという声が寄せられています。
この30分間で多くのことをお話ししましたが、私たちは何を学んだのでしょうか？まず第一に、レガシーシステムはまさにレガシーなのです。モダナイズされたレガシーシステムであっても、前身のシステムの問題を引き継ぐ可能性が高いのです。このようなシステムを扱う場合、成功に導くには戦略的なパートナーシップとカスタムソリューションが必要になる可能性が非常に高いと言えます。次に、RAGの実装において、メタデータの品質が絶対的に重要であることを学びました。ビジネスおよびテクノロジーのリーダーとして、正しい文書を返すために必要なメタデータを生成する際には、創造的なアプローチが必要になります。
私たちが学んだもう一つの重要な教訓は、ラベル付きデータセットやゴールデントゥルースがない状態で、検索の精度を定量的に測定することの難しさでした。最初の段階ではそのようなゴールデントゥルースを持っていませんでしたし、それを確立するのにかなりの時間がかかりました。もしあなたのデータにまだそれがない場合は、今すぐ構築を始めることを強くお勧めします。最後に、ユーザー教育が非常に重要だということを学びました。ユーザーがAIとどのように関わるべきかを理解してもらうことが、システムの効果を最大限に引き出すための鍵となります。
AIガバナンスは極めて重要です。今週、このテーマに関する多くのセッションやディスカッションを聞かれたと思いますが、特にProof of Conceptから本番環境に移行する際には、AIガバナンスチームとのパートナーシップが、ソリューションの成功とセキュリティを確保する上で非常に重要になります。
その原則とは、私たちは従業員をAIで置き換えるのではなく、彼らの能力を補強し生産性を向上させるためのAIアシスタントを提供するということです。この技術で100%の精度、100%のリコール、あるいはどの指標においても100%を達成することは不可能だと考えています。そのため、Principalでは、すべてのAIとの対話において人間が介在することを強く信じています。AIアシスタントは顧客からの問い合わせに対する従業員の対応をサポートするかもしれませんが、顧客が直接AIとやり取りすることはありません。
最後に、Q Businessを始めるための重要なポイントをお伝えします。まず何よりも、ユースケースを評価し、要件の策定を始める前にビジネス目標と指標を理解し、成功を測る定量的な指標を確保してください。あるタスクが5分短縮されたというユーザーの声は素晴らしいですが、それを定量的な形でどのように証明できるでしょうか？これらの指標が必要なのです。いくら強調してもしすぎることはありません。これらの定量的な指標こそが、ROIを証明する唯一の方法なのです。
次に、とにかくQ Businessアプリケーションをデプロイして実験を始めてください。データコネクターを設定して9000ページをインデックス化する必要はありません。アプリケーションを設定してテスト用のWeb環境にアクセスするのは文字通り数分で済みます。その数分を実験に投資してください。小規模から始めることが重要です。すべてを一度に解決しようとしないでください。自分の役割をよく理解し、実験に前向きで意欲的なユーザーのサブセットを見つけてください。彼らに実験の自由を与え、常に情報を共有することで、彼らはあなたのチャンピオンになってくれるでしょう。私たちのチャンピオンたちが各事業部門のチャンピオンへと成長してくれなかったら、今頃もっと不安定な状況になっていたことは間違いありません。
次に、強力なフィードバックのパイプラインを確立し、それを活用してユーザーの声に耳を傾けることが重要です。私たち全員がAIは素晴らしいと考えていますが、最終的な判断を下すのはユーザーです。アンケート、フォーカスグループミーティング、Qそのものの中でのフィードバックなど、複数の方法でユーザーの声を聞く体制を整えてください。なぜなら、ユーザーの声がロードマップを導き、前進するためのアイデアを与えてくれるからです。
最後に強調したいのは、可能性の探求を共有することです。私たちのように毎日Generative AIに触れているわけではないので、ほとんどのユーザーはGenerative AIが何をできるのか理解していません。彼らにとっては、単なる新しいツールの一つに過ぎないのです。デモでは創造性を発揮し、可能性を存分に共有することで、ユーザーが生産性を最大限に高めるためにこのツールをどう活用できるかを理解できるようにしましょう。先ほども申し上げたように、Generative AIの活用と成功は、あなたの創造性によってのみ制限されます。皆さんへの課題です：今日、Amazon Q Businessでどんな可能性を見出しますか？ありがとうございました。Alicia、お返しします。 はい。皆様、お時間をいただき、ありがとうございました。本当に感謝いたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion