re:Invent 2024: AWSがAmazon Q BusinessでMicrosoft連携を強化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Harness Amazon Q Business power with Microsoft workload data sources (XNT302)
この動画では、職場でのAIチャットアプリケーションの課題とその解決策としてのAmazon Q Businessについて解説しています。コンテキストの欠如、セキュリティ、データプライバシー、コンプライアンスといった課題に対し、Amazon Q Businessは40以上のデータソースコネクタを提供し、Microsoft SharePointやAmazon FSx for Windows File Serverなどと統合可能です。特に、Active Directoryと連携したアクセス制御や、トピック固有のガードレール設定により、企業データに基づいた安全で正確な回答を提供できます。また、Amazon Q Appsを使用することで、職務内容の作成や財務サマリーの取得など、反復的なタスクを自動化できる軽量アプリケーションを構築できることも示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
職場におけるAIチャットアプリケーションの課題
それでは始めましょう。職場におけるAIチャットアプリケーションの課題とは何でしょうか？まず第一に、コンテキストの欠如です。AIチャットアプリケーションは、あなたのビジネス、会社、顧客セグメント、業界について知りません。例えば、マーケティング担当者がAIチャットアシスタントに製品販売のためのマーケティングキャンペーンメールの作成を依頼した際、AIシステムが顧客が誰なのか、どんなビジネスなのか、どんな製品なのかを知らないまま「私たちの製品は素晴らしいので、ぜひ購入してください」と応答するようなシナリオを考えてみてください。
次は、セキュリティです。AIチャットアシスタントは、ユーザーのアクセスレベルや権限を把握していない可能性があります。例えば、AIのデータセットやトレーニングデータセットに会計情報が含まれている場合、一般ユーザーがチャットアシスタントを通じてその情報にアクセスできてしまうようなシナリオを想像してください。次にデータプライバシーの問題があります。これは、トレーニングデータセットにユーザーの財務情報や健康情報が含まれており、ユーザーがAIシステムに問い合わせた際にその情報が提供されてしまうような場合です。そして、コンプライアンスの問題があります。これらのセキュリティとプライバシーの問題により、多くのCIOが職場での一般的なAIアプリケーションの使用を禁止する事態となっています。
Amazon Q Businessの概要と機能
昨年のre:Inventで、これらの問題に対処するAmazon Q Businessを発表しました。この1時間で、私とSiavash IraniとJarod Oliverが、Amazon Q BusinessがMicrosoft SharePointやAmazon FSx for Windows File Serverなど、Microsoftベースのデータソースとどのように統合できるのか、そしてエンタープライズデータに基づいたAIアシスタントでユーザーをどのように支援できるのかについてお話しします。
始める前に、Amazon Q Businessとその提供する機能について簡単に概要を見てみましょう。Amazon Q Businessは、エンタープライズデータに基づいて安全で正確な回答を提供する、Generative AI搭載のチャットアシスタントです。ユーザーはAmazon Q Businessのプラグインを使用して、カスタマイズされた自動タスクを実行することもできます。例えば、機能リクエストの更新やサービスチケットの作成を行いたい場合、特定のツールにアクセスすることなく、チャットを使用するだけで実行できます。また、Amazon Q Businessはユーザーの権限とアクセス制御を尊重します。通常アクセスできないファイル、データベース、データリポジトリには、Qを通じてもアクセスできません。次のスライドで説明する40以上の異なるエンタープライズレベルのデータソースに接続できます。
また、Amazon Q Businessのレスポンスに対して、ガードレールを作成し、アクセス制御やトピック制御をカスタマイズすることができます。では、具体例を見てみましょう。画面に表示されているのはAmazon Q Businessのスクリーンショットです。このシナリオを考えてみてください：私は採用マネージャーで、当社のAWS Solutions Architectの求人情報を作成したいと考えています。私のリポジトリには多くの履歴書と過去の職務記述書があり、QにAWS Solutions Architectの求人情報の作成を依頼しています。ここで「当社の」という言葉に注目してください - 自社に特化した内容にしているのです。
Q Businessは、異なるデータソースからインデックス化されたデータを参照し、職務内容について回答を提供してくれます。この例では、ファクトチェック用のソースも提供されています。各段落の下に数字が表示されているのがわかりますが、"1"という数字があり、そこには複数の数字が表示されることもあります。これは基本的に、その情報がどのデータソースから得られたかを示しています。後ほどデモでお見せしますが、複数のデータソースがある場合、受け取った回答を包括的なレスポンスとして組み合わせてくれます。
会話履歴もサポートしています。この例では、上部に表示されている職務内容にC#とPythonのスキルが必要とされていますが、私はこれらのプログラミングスキルを職務内容から除外するよう依頼することができます。
Amazon Q Businessの様々なガードレールとセキュリティコントロールについて見ていきましょう。AIチャットアシスタントには、有害な言語、不適切な表現、暴言などに対する事前設定されたガードレールが必要ですが、Q Businessにはデフォルトでこれらが備わっています。レスポンスを企業データのみに制限することも、LLMにフォールバックすることも可能です。フォールバックを有効にすると、インデックス化されたデータで回答が見つからない場合に、LLMに切り替えて一般的な回答を得ることができます。
これらのデフォルトの制限で十分でない場合は、レスポンスで特定のキーワードをブロックするオプションがあります。ここでは、"Project X"という言葉を含む回答をブロックしています。次はトピック固有のコントロールですが、これはQ内の非常に興味深い機能です。企業データから問い合わせてほしくない特定のトピックがある場合があります。トピック固有のコントロールでは、そのトピックが意味することを説明文として入力するだけです。私の場合は、セキュリティアーキテクチャにおけるセキュリティギャップについての議論を禁止しています。また、ユーザーが尋ねそうな質問例も提供できます。例えば、システムのセキュリティ脆弱性などの質問です。
これを定義すると、セキュリティトピックやセキュリティ脆弱性について質問する人に対して、Qの設定で定義した事前設定メッセージで応答するように設定できます。特定のユーザーやグループには、これらの回答へのアクセスが必要な場合があります。例えば、セキュリティアーキテクチャや環境のセキュリティ脆弱性については、ITセキュリティチームにアクセスを許可したい場合、このルールから除外してアクセスを与えることができます。
組織内のユーザーがAmazon Q Businessを使い始めると、似たような問い合わせをする異なるグループの人々が出てきます。例えば、財務部門の人々が特定期間の財務サマリーをQに問い合わせたり、経理チームが従業員の給与情報を確認したりするケースが考えられます。また、先ほどの例では、採用マネージャーが職種名を入力して職務内容を取得する方法を見ました。このようにAmazon Q Business内でさまざまな類似したトレンドが見られるようになると、Amazon Q Appsを使って軽量なアプリケーションを構築することができます。その構築方法は非常にシンプルで、作りたいアプリについて説明するだけです。
例えば、先ほどの財務の例では、「期間を入力すると、その期間の財務サマリーを提供するアプリ」と指定するだけです。採用マネージャーの場合は、「職種名を入力すると、その職務内容を提供するアプリ」と指定します。このように、何千もの異なるユースケースを見つけることができます。 アプリケーションが構築されると、URLが発行され、組織のライブラリに公開して、そのグループの他のユーザーと共有することができます。これは非常に便利な機能です。Amazon Party Rockを使ったことがある方なら似た感覚かもしれませんが、こちらは企業向けに作られています。
もちろん、Q AppsはAmazon Q Businessの機能なので、 先ほど説明したセキュリティガードレールやガバナンスコントロールなどがすべて付属しています。 同様に、Q Businessの一部であるため、さまざまなデータソースやカスタムプラグインに接続でき、アプリは回答の提供やチケットの更新、機能リクエストの作成などを行うことができます。
Microsoftデータソースとの統合：FSx for WindowsとSharePoint
さて、多様なデータコネクターへの接続について話題が出ましたが、 以前Amazonで経験した話をご紹介したいと思います。数年前、あるProduct Managerと一緒に仕事をしていた時、そのプロダクトの次に開発すべき機能を、カスタマーから逆算して考えようとしていました。現場でお客様と直接やり取りしている人々からのフィードバックを確認し、何が起きているのか、次に何を作るべきかを把握したかったのです。
おそらく多くの企業では、機能リクエストを記録し、顧客の影響を追加するためのツールをお持ちだと思います。しかし、社内で調査を進めていく中で、様々な人々に連絡を取ってみると、データが第一にフォーマットが統一されていないこと、そして第二にあらゆる場所に散在していることに気づきました。 ツールを適切に使用している人々もいて、それは素晴らしいことでした - そういったケースは簡単に対応できました。しかし、シンプルなメモ帳を使って「このお客様はこれを望んでいた」といった内容を1つのファイルに記録している人もいました。また、Slackで同僚とチャットしながら「このお客様はこれを望んでいた」とか「これについて進展はある？」といったやり取りをしている人もいました。さらには、そのようなことを一切せず、顧客からの要望をメールの中にだけ残している人もいました。
当時は本当に大変でした。様々なデータソースや顧客からのフィードバックを総合的に分析して、次に何を開発すべきかを把握する必要がありました。その頃は、複数のデータ変換を行い、各担当者がどのようにデータを記録しているかを理解する必要がありました。そのトレンドを把握するのは非常に面倒な作業で、実際に数ヶ月かかりました。当時Amazon Q Businessがあれば良かったと思います。なぜなら、異なるデータソースを簡単に接続し、トレンドの全体像を把握することができたからです。
Amazon Q Businessは40以上の組み込みコネクタをサポートしています。 Adobe Experience ManagerからAtlassian Confluence、IBM DB2、Dropboxまで、様々なコネクタのリストをご覧いただけます。画面上で緑色でハイライトされているのがMicrosoft関連のものです。1つはマネージド型SMB共有ファイルサーバーであるAmazon FSx for Windows File Serverです。その他にもMicrosoft Exchange、SQL Server、Teams、SharePointなどのMicrosoft固有のコネクタもあります。 本日は特にAmazon FSx for Windows File ServerとMicrosoft SharePointの2つを取り上げ、これらのデータソースとAmazon Q Businessをどのように統合できるかをご紹介します。
ありがとうございます。これからQ BusinessとMicrosoftのデータソースの統合方法と、それらのデータソースコネクタの機能について見ていきましょう。最後にデモを実施し、Microsoftのプロダクトをデータソースとして使用する際のQ Businessの機能をご紹介します。 今日取り上げるデータソースはそれぞれ、以下の機能をサポートしており、これらを3つのセクションに分けて説明します：取り込み、権限、および機能強化です。取り込みについて、Q Businessはデータソースをスキャンしてクロールすべきドキュメントを特定することをサポートしています。これについては後ほど詳しく説明します。Q Businessがドキュメントセットをクロールすると、それらを処理してインデックスにテキストを抽出し始めます。中央の権限に関して、各ドキュメントデータソースにはメタデータが関連付けられています。このメタデータには、
どのユーザーやグループがドキュメントにアクセスできるかという情報が保存されています。Amazon Q Businessのコネクタはこれらのアイデンティティを取り込み、許可された人のみがデータにアクセスできるようにします。今日はMicrosoft固有のデータソースについて説明していますので、Active DirectoryのユーザーとグループがAmazon Q Business内で完全にサポートされていることは特筆に値します。これらのアイデンティティは、Amazon FSx for Windows File ServerのNTFSおよびローカルSharePointサーバーの権限ストア内のアクセス制御リストにマッピングされます。
すべてのドキュメントには構造的な属性やメタデータが付属しています。これらの属性には、ドキュメントのタイトル、作成者、更新日時や作成日時、タイプなどの情報が含まれます。これらのドキュメント属性をAmazon Q Businessのインデックス内のフィールドにマッピングすることができます。ドキュメント属性をマッピングすると、特定のデータソースからの結果を優先的に表示したり、エンドユーザーが特定のデータに対してチャット結果をフィルタリングしたり範囲を絞ったりすることができます。
データの安全性とセキュリティは最も重要です。Q Businessにおいて、アクセス権を付与する際にデータを過度に公開することがないよう、細心の注意を払っています。SharePointとFSx for Windowsのデータコネクターの主要な特徴の1つは、これらのプラットフォーム内のアクセス制御リストを尊重することです。先ほども申し上げましたが、データソース内のデータにアクセスする権限がない場合、Q Business内でもそのデータにアクセスすることはできません。
本日はMicrosoft製品をサポートするデータコネクターについてお話ししていますので、ユーザーやグループオブジェクトの保存にMicrosoft Active Directoryを使用している可能性が高いと考えられます。 Q Businessがユーザー権限に基づいてレスポンスをフィルタリングできるようにするため、これらのユーザーとグループをActive DirectoryからAWS IAM Identity Centerに同期します。FSx for WindowsとSharePointサーバーのデータコネクターは、ドキュメントのコンテンツだけでなく、NTFSやSharePoint固有の権限も取り込みます。ユーザーがQ Businessに質問すると、これらの権限を尊重したフィルタリング済みの回答が提供されます。
Q Businessが各データコネクターに対してクロールを実行するたびに、そのイベントはAmazon CloudWatch Logsに記録されます。ここで見ているのは、そうしたクロールの簡単な抜粋で、具体的にはFSx for Windows File Serverのデータソースのクロールです。上部のログストリームエントリには、データソースコネクターのIDと実行IDが記載されています。info欄では、クロールされたファイルの名前とファイル共有内での場所を確認できます。最も興味深いのは、下部のACLセクションで、ディレクトリからIT Departmentグループがこのファイルへのアクセスを許可されていることが分かります。isFederated equals trueという部分は、このグループがAWS IAM Identity Centerに同期されていることを示す重要な情報です。
これはSharePointサーバーのデータソースコネクターのクロール履歴からのCloudWatch Logsの抜粋です。異なるデータソースコネクターを使用しているため、ログストリームと実行IDは先ほどとは異なります。info欄の代わりに、Amazon EC2上で動作しているSharePointサーバーファーム内でクロール対象のファイルが保存されている場所を示すsource URIがあります。ACLセクションを見ると、Portal Home Ownersグループのメンバーがこのドキュメントへのアクセスを許可されていることがQ Businessによって判断されていることが分かります。これはSharePoint内にのみ存在するグループで、Active Directory内には存在しません。これは、Q Businessがアプリケーション固有のグループもサポートしていることを示しています。
Q BusinessはMarkdownやプレーンテキストのような単純なものからJSONやPowerPointのような複雑なものまで、多くの異なるファイルタイプをサポートしています。各ファイルタイプの詳細についてはAWSドキュメントに詳しく記載されているため深く掘り下げませんが、すべてのファイルタイプに共通する点は、Q Businessがそれぞれからプレーンテキストを抽出できるということです。特に注目に値する機能の1つは、PDFファイルに対する光学文字認識（OCR）のサポートです。これにより、スキャン、FAX、または写真として取り込まれた結果として画像になってしまったドキュメントからでも、Q Businessはプレーンテキストを抽出することができます。
Amazon Q Businessのデータソース設定デモ
それでは、デモを通してこの仕組みを見ていきましょう。まずはその前に、これを支えるアーキテクチャを確認してみましょう。 右側から見ていくと、すべてのユーザーとグループオブジェクトを管理するAWS Managed Microsoft Active Directoryがデプロイされています。これらのオブジェクトはAWS IAM Identity Centerと同期されており、 Amazon Q Businessのウェブエクスペリエンスへのアクセス認証に使用されます。
FSx for Windows File ServerとSharePoint Serverは、どちらも Amazon VPC内のプライベートサブネットにデプロイされています。FSx for Windowsには多数の共有フォルダを作成し、それぞれに固有のアクセス権限を設定しています。EC2上で動作するSharePoint Serverについては、同一のSharePointサイト内に異なるドキュメントライブラリを設定し、各ドキュメントライブラリに固有のアクセス権限を設定しています。
ユーザーはAmazon Q Businessのウェブエクスペリエンスにアクセスします。 AWS Managed Microsoft ADの認証情報を使用して、AWS IAM Identity Centerで認証を行います。 接続後は、FSx for Windows File ServerとSharePoint Serverの両方のデータに関する質問をQ Businessにすることができます。これは、両方のデータコネクタが同じAmazon Q Businessアプリケーション内で設定されているためです。
これからデモをお見せしますが、3つの内容を取り上げます。まず、Microsoftデータソースコネクタのセットアップ方法、次に先ほど説明したFSx for WindowsとSharePoint Serverのアクセス制御がQ Businessでどのように尊重されるかを示し、最後にビジネス内で実装できるガードレールについて先ほど触れた内容をお見せします。
ここに表示されているのがAWSコンソールです。Amazon Q Businessを見ていきましょう。先ほど説明したように、Amazon Q Business内でアプリケーションを設定することができ、ここには3つのアプリケーションがあります。作成方法については説明しませんが、作成後はこのような画面になります。今日は「reinvent-2024」に焦点を当て、Amazon FSx for Windows File Server用の新しいデータソースコネクタを追加していきます。
そのために、Data sourcesをクリックしますが、その前にお見せしたいのは、このQ Businessアプリケーションにすでに2つのデータソースが設定されているということです。 1つはEC2上のSharePoint Server用、もう1つはFSx for Windows File Server用です。新しいデータソースを追加するには、Add data sourceをクリックします。 これがデータソースコネクタの一覧です。リストを下にスクロールすると、Alfresco、Asana、Confluenceなどのサードパーティアプリケーションや、Microsoft関連のものとしては、Amazon RDS for Microsoft SQL ServerやMicrosoft Teams、Microsoft Exchangeがあることがわかります。
リストの一番上に戻ると、Amazon FSx for Windowsの部分に「1つ追加済み」と表示されているのが見えます。これは、 先ほどお見せしたように、すでに1つのデータソースコネクタを設定済みだからです。ですが、FSx用にもう1つ追加してみましょう。データソースに名前を付ける必要があるので、 作業を早めるために、ブラウザに保存しておいたものを使います。「FSx Windows reinvent 2024」という名前にします。 必要に応じて説明も追加できます。ソースについては、Q Businessにクロールさせたいファイルシステムを選択する必要があります。
ドロップダウンをクリックすると、私の環境には1つしかないので、それを選択します。認可の設定では、このコネクタでACLsが有効になっているのが分かります。これはデフォルト値で変更できません。認証の設定までスクロールしていきましょう。Amazon Q Businessがデータソースにアクセスするための適切な認証情報を持つために、AWS Secrets Managerのシークレットを設定する必要があります。ドロップダウンをクリックして、 Create and add new secretを選択し、クリップボードにコピーしておいた値を貼り付けます。これは 事前入力されたフィールドの末尾に追加されます。Microsoft Active Directoryドメインを使用し、 コンテンツへのアクセス権を持つ特権ユーザーを指定して、パスワードを保存します。これで完了です。シークレットの設定が できました。次に、このFSx Windows File ServerがAmazon Virtual Private Cloud内のどこに存在するかをAmazon Q Businessに指定する必要があります。
ドロップダウンリストから、私の環境ではVPCに設定されており、FSx for Windowsリソースが存在するサブネットを指定する必要があります。 この場合、US East 1Aのプライベートサブネットに存在しています。 基盤となるコンテンツへのアクセスを許可するセキュリティグループを設定する必要があります。私の環境ではAmazon Q-FSxという名前で、このセキュリティグループは SMBポート445へのアクセスを許可しています。これがAmazon Q Businessがコンテンツにアクセスする方法となります。
IAMロールについては、先ほどAWS Secrets Managerで作成したシークレットにアクセスできるようにするため、Amazon Q Businessにロールを付与する必要があります。ドロップダウンリストからCreate a new service roleを選択し、値を貼り付けて、 末尾に「role」を追加します。同期スコープの設定を見ると、最大ファイルサイズの値は、 デフォルト値である50メガバイトまでとなっています。データソースコネクタを設定すると、1つのファイルから最大5メガバイトのテキストを抽出できます。
同期モードについて、Amazon Q Businessに対して、実行するたびにデータソースの完全同期を実行するよう指示することができます。あるいは、増分同期を選択して、実行時に新規、変更、または削除されたコンテンツのみを処理することもできます。今回は増分同期オプションを選択します。同期スケジュールについては、オンデマンド、毎時、毎日、毎週、または毎月の実行を選択できます。カスタムを選択すると、より細かい制御のためにカスタムのcron式を入力することができます。このデモでは、毎日を選択し、デフォルトの開始時刻をそのまま使用します。
他の多くのAWSリソースと同様に、このAmazon Q Businessのデータソースにタグを追加することができます。先ほど説明したフィールドマッピング機能を使用すると、ドキュメント内の属性をAmazon Q Business内のフィールドにマッピングして、ユーザーがAmazon Q Businessと会話する際にそれらの結果を優先的に表示することができます。現在、デフォルト値はグレーアウトされており変更できませんが、データソースコネクタを追加した後で、これらの値を編集したり新しいフィールドを追加したりすることができます。データソースの追加をクリックすると、FSx for Windows File Server用のデータソースコネクタの追加は以上で完了です。完了までには30秒ほどかかりますが、先に進んで、後ほど正常に作成されたことを確認しましょう。
アクセス制御とQ Appsの実践デモ
ここにRemote Desktopで接続している Amazon EC2インスタンスがあります。これはActive Directoryドメインに参加しており、ドメイン内での操作を実行するためのBastionホストまたはジャンプボックスとして使用しています。このセクションで特に確認するのは、データソースに対するACLがAmazon Q Business内でどのように尊重されているかということです。FSx for Windowsのネットワーク共有を参照すると、各部署用に作成された複数のフォルダを持つ共有が1つ設定されているのが分かります。
各部署のフォルダには、それぞれ固有のアクセス許可が設定されています。特にHR部門のフォルダに注目してみましょう。ここには複数の履歴書がアップロードされています。このフォルダのアクセス許可を確認すると、HR Departmentグループにアクセスが許可されていることが分かります。つまり、このグループのメンバーのみがこのコンテンツにアクセスできるということです。
Active Directory Users and Computersに切り替えると、HR Departmentグループがあります。これをダブルクリックしてメンバーを確認すると、Celiaがこのグループのメンバーであることが分かります。したがって、彼女はこのコンテンツにアクセスできるはずです。デモで使用するもう一人のユーザーはJohnです。彼のグループメンバーシップを確認すると、IT Departmentグループのメンバーであることが分かります。したがって、JohnはCeliaがアクセスできるコンテンツにはアクセスできないはずです。次に、EC2上で動作しているSharePoint Serverを見てみましょう。これは私のSharePointサイトで、いくつかのドキュメントを持つシンプルなサイトです。
とてもシンプルなサイトで、いくつかのDocument Libraryが設定されています。今回はHR部門に焦点を当てているので、そちらをクリックしてみましょう。ここには求人情報のドキュメントがいくつか作成されています。これらは、おそらく私たちの会社が募集している職種です。
このDocument Libraryのアクセス権限を見てみましょう。このライブラリは継承を解除しており、独自のアクセス権限が設定されています。CeliaとSP_Adminアカウントのみがこのコンテンツにアクセスできます。SP_AdminはSharePointサーバーファーム内の基盤コンテンツにアクセスするために、Q Business内で使用している特権SharePointユーザーです。
先ほどアーキテクチャのスライドで説明したように、Amazon Q Business Web Experienceを使用して大規模言語モデルと対話し、エンタープライズデータソースからどのようにデータを取得するかを見ていきます。AWSコンソールに一旦戻ってみると、バックグラウンドで新しいFSx for Windows File Serverが作成され、アクティブになっているのが分かります。Q Business内のre:Invent 2024アプリケーションに戻ってスクロールすると、Web Experienceセクションがあり、これがユーザーがQ Business Web Experienceにアクセスするために使用するURLです。
このURLをコピーしてBastion Hostに戻ります。複数のユーザーとしてログインするので、プライベートブラウジングウィンドウを開きます。ここに表示されているのはAWS IAM Identity Centerの認証ページです。手順を簡略化するためにCeliaの認証情報をブラウザに保存していますが、これは彼女のMicrosoft Active Directoryアカウントです。読み込みに少し時間がかかります。これはAmazon Q Appsのスプラッシュ画面です。これについては後ほど説明するので、今は閉じておきましょう。
Celiaは Q Businessに質問をします。ファイルからQ Businessにコピー＆ペーストしてみましょう。彼女は「私たちが持っている履歴書の中で、この特定の求人に合う良い候補はいますか？」と尋ねます。これで彼女の時間を大幅に節約できるはずです。それではEnterを押してみましょう。Q Businessはエンタープライズデータソースの検索を開始し、応答が完了するのを待ってから上にスクロールしてみます。
上にスクロールして戻りましょう。「はい、Jane Smithはこのポジションに最適な候補者です」という回答が返ってきて、その理由が列挙されています。先ほどお見せしたように、回答の特定の部分に数字が付いていて、それがデータソースから情報を取得したことを示しています。ここでは具体的に1と2が表示されています。下までスクロールしてSourcesを見てみると、FSx for Windows File ServerからJane Smithの履歴書を取得し、SharePointサイトにある求人情報と組み合わせて分析していることがわかります。
通常の検索、特にSharePoint内での検索ではこのようなことはできません。なぜなら文脈を理解せず、キーワードだけを探すからです。しかし、先ほど申し上げたように、これらのタスクはかなり反復的なものになります。CeliaはHR部門で働いているので、おそらくこの質問を頻繁にすることになるでしょう。そこで、Amazon Q Appを作成してみましょう。会話履歴に基づいてクエリを作成し、Celiaが毎回長い文章を入力する必要がないように効率化できます。
テキストのブロックをコピー＆ペーストしながら、後で説明する用途のために待機しています。これがAmazon Q Apps Creatorです。下にスクロールすると、求人情報の説明をテキスト入力として受け取り、履歴書ファイルを入力として受け取って、それらがどの程度マッチするかを分析するアプリを作成するように指示が表示されています。少し修正を加えてみましょう。先ほどコピーした値をペーストして、ここで変更したのは、Q Appsにファイルをアップロードしたくないということです。ファイルはすでにFSx for WindowsとSharePointに保存されているので、エンタープライズデータソースを使用したいと考えています。そしてアプリには求人のタイトルだけを入力として必要とするようにしたいと思います。generateをクリックすると、Q Businessがバックグラウンドでアプリを作成します。数秒しかかかりません。
最終的に、求人タイトルを入力するだけで、Q Businessが作業を代行してくれるアプリができあがります。これが検索したい求人タイトルの入力欄です。今回は別の募集ポジション - Senior Construction Project Managerです。これをペーストしてrunをクリックします。待っている間に、上部にあるpublishボタンについて説明しますが、これはSiavashが先ほど言及した、アプリを作成してビジネス内で公開できる機能です。Celiaがこのアプリを便利だと感じれば、HR部門内で公開することで、同僚の仕事も楽にすることができます。
Q Businessが分析を実行しています。上下にスクロールする必要があるので完了するまで待ちますが、すでにJames Barrettの履歴書の分析に基づいて、このポジションに強力なマッチであることがわかります。ここにもデータソースの番号が表示されています。FSxから再びJames Barrettの履歴書を取得し、SharePointサイトから求人情報を取得しています。Jamesがこのポジションに適している理由を要約し、データソースを列挙しています。
以上が、Q Appsを使ってエンドユーザーのエクスペリエンスを向上させる方法でした。ユーザーがコンテンツにアクセスできる場合のレスポンスを見てきましたが、次はアクセス権のないユーザーの場合どうなるか確認してみましょう。まずCeliaのアカウントからログアウトして、すでにブラウザに保存してあるQ Business Web experienceに、今度はJohnのアカウントで再度ログインしてみます。覚えていらっしゃると思いますが、JohnはIT部門のメンバーでした。Johnとしてサインインしたら、先ほどCeliaが実行したのと全く同じクエリをコピーします。
レスポンスを待っている間に、Q Appのスプラッシュ画面を閉じておきましょう。Johnが「採用ポジションに適した候補者はいますか？」と尋ねると、このリクエストを完了するための関連情報が見つからないという返答が返ってきます。これは、JohnにはFSx for Windowsの履歴書やSharePoint内の求人情報文書へのアクセス権がないためです。このように、プラットフォーム内のAccess Control Listsが確実に守られていることが分かります。
ガードレールの実装とセッションのまとめ
では、Amazon Q Business内で実装できるガードレールについて見ていきましょう。メモ帳からクエリをコピーして貼り付けてみます。まだJohnとしてログインしたままですが、Johnが会社の過去3年間の財務実績について質問してみます。今度は異なるレスポンスが返ってきました。ブロックされているコンテンツが含まれているため、このリクエストを完了できない、管理者に問い合わせてくださいという内容です。
AWSコンソールに戻って、このQ Businessアプリケーションの管理者コントロールとガードレールを見てみましょう。下にスクロールすると、トピック固有のコントロールを実装できる場所があり、財務データ用のものを作成しています。それをクリックしてみましょう。ここでは、トピック固有のコントロールにサンプルのチャットメッセージを入力できます。Q BusinessとLarge Language Modelは、これらを使用してユーザーからのクエリが適切かどうかを判断します。ここでは、クエリを完全にブロックする動作を実装し、ユーザーに表示されるメッセージをカスタマイズすることができます。私はデフォルトのメッセージをそのまま使用しています。このルールは特定のグループ、つまりActive Directoryドメイン内のIT部門グループに対してスコープを設定しています。そのため、Johnは会社の財務情報へのアクセスが制限されているのです。
これでデモは終了です。お役に立てば幸いです。ここまでの内容を要約すると、Amazon Q Businessがエンタープライズデータに基づいてAIアシスタントを構築する方法について説明しました。EC2上のSharePoint Server やAmazon FSx for Windows Serverとの統合方法を示し、さらにAmazon Q Appsを使って軽量なアプリケーションを構築する方法もご紹介しました。次のステップとして、皆さんの環境を見直し、デモでお見せしたように、データソースを追加するだけでAIアシスタントを提供できるような、データサイロを探してみてください。そうすることで、ユーザーがより効率的に作業できるようになります。以上で本セッションを終了させていただきます。ご参加ありがとうございました。これからQ&Aに移りたいと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion