Amazon Q Business の匿名アクセスを試してみる

記事タイトルとURLをコピーする

こんにちは、やまぐちです。

概要

今回は、Amazon Q Business の匿名アクセスを試してみます。

Amazon Q Business の利用方法には、Identity Center による認証と、匿名アクセスの2つのパターンがあります。
企業内等の閉じた環境で利用する場合は、Identity Center で認証してユーザ管理を実施するケースが多いと考えます。
一方で、Web ページ内にチャット機能を埋め込むようなケースですと不特定多数のユーザが Amazon Q Business を利用することとなります。
そういったユースケースで、ユーザ認証ではなく匿名アクセスでの利用が考えられます。

料金について

Amazon Q Business の料金は、ユーザ認証と匿名アクセスで料金体系が変わってきます。
今回の匿名アクセスの場合、最低でも月に 200USD 発生する点を注意する必要があります。

認証方法 料金
ユーザ(Lite) ユーザごとに 3USD/月
ユーザ(Pro) ユーザごとに 20USD/月
匿名アクセス 30,000ユニットごとに 200USD/月

aws.amazon.com

匿名アクセス利用時の注意点

ユーザ認証の場合と違い、チャット履歴が確認できないなどの機能制約があります。 docs.aws.amazon.com

匿名アクセスを試す

アプリケーションの作成

それでは早速、匿名アクセスを試してみます。

Amazon Q Business へ移動して、「Create application」の画面へと遷移します。

「User access」をAnonymous accessで指定して Application を作成します。
作成が完了し、Application のメニューを確認すると、ユーザ認証の場合と比べて利用できる機能が少ないのがわかります。
注意点に記載したドキュメントにある通り、Quick Sight との統合なども利用できないようです。

ユーザ認証で作成した場合は「Deployed URL」となっている箇所が「Preview」という形で表示されています。

「Preview web experience」から Web experience にアクセスすると、ユーザ認証なしでチャット画面が開きました!

「Company knowledge」や「General knowledge」といった選択できず、データソースに基づいた回答しかできないようです。

比較用として、ユーザ認証した場合のチャット画面も載せておきます。
「Company knowledge」と「General knowledge」の選択ができます。

ユーザ認証した場合のチャット画面

データソースの設定

それでは、データソースの設定を行います。

「Data sources 」へ移動すると、設定したデータソースがユーザ認証なしにパブリックにアクセスされる旨が注意書きで記載されています。
「Add an index」からインデックスを追加します。

検証用なので「Starter」を指定して作成します。

次に「Add data source」からデータソースを追加します。

今回は、以下ブログで利用した英語版の Word ファイルをデータソースとして設定しました。 blog.serverworks.co.jp

チャットから質問してみる

それでは改めて、チャットの画面から質問してみます。

するとデータソースを基にした回答が返ってきました!

データソースに情報のないものは当然、回答が返ってきません。

Web サイトへの組み込みについて

以下ブログで、Amazon Q embedded をユーザ認証で試してみましたが、匿名アクセスでの場合について言及してみます。 blog.serverworks.co.jp

ユーザー認証時と匿名アクセス時では、Web Experience の URL の扱いに大きな違いがあります。
ドキュメントにある注意点をまとめます。

  • Web experience は作成する必要がある
  • 作成された URL は 5分以内に利用する必要がある
  • 作成された URL の利用は 1度しか利用できない
  • 一度アクセスすると、セッションは設定された期間アクティブなままになる
  • 以下のいずれか早い方に CreateAnonymousWebExperienceUrl を呼び出して新しい URL を作成する必要がある
  • 新しいアプリケーションセッションが必要になったとき
  • 1時間経過したとき

docs.aws.amazon.com

要は、ユーザ認証の時のように同じ URL を使って Web experience へはアクセスできないということになります。
ユーザが Web サイトにアクセスする毎に、都度 Web experience の URL を発行して組み込むといった処理が必要となります。

試しにチャットの画面をリロードしてみます。

リロード前

リロードすると 403 Forbidden が出てしまいました。
URL は1度きりしか使えないことがわかります。

リロード後

まとめ

今回は、Amazon Q Business の匿名アクセスを試してみました。

Web サイトに組み込む場合など、不特定多数のユーザでの利用時に採用したいオプションだと考えています。
一方で、ユーザ認証と違って以下の点については注意が必要です。

  • 料金が一定の金額発生してしまう
  • 一部機能が利用できない
  • Web experience の URL は固定ではない

それでは、またどこかで~

やまぐち まさる (記事一覧)

CS部・CS2課

AWS の構築・運用をやってます

3度の飯より野球が好き

2025 Japan AWS All Certifications Engineers