師走の恒例となっているQiitaの『株式会社日立システムズ Advent Calendar 2022』。
今年も記事を書いてみようと思います。
なお、記載内容は個人的なものであり、
所属する企業や組織、団体を代表する見解その他ではありませんので、
ご承知おきください。
さて、何を記載しようかと考えたのですが、
せっかくなので、日頃は使っていないサービスを検証してみたいと思いました。
その結果、「Amazon Kendra」にしてみました。
なぜ、「Amazon Kendra」にしたかというと、先日開催された「AWS re:Invent 2022」で、2つのアップデートが発表されて気になっていたからです。
発表１：セマンティック検索の言語サポートを拡張
Kendra のセマンティック検索の言語サポートを拡張し、スペイン語、フランス語、ドイツ語、ポルトガル語、日本語、韓国語、中国語の 7 言語を新しく追加しました。
これらの言語のコンテンツにおいて、よくある質問のマッチング、ドキュメントランキング、質問に対する回答を含む Kendra の幅広いセマンティック機能をご利用いただけるようになりました。新しい言語の機能はデフォルトで有効となっており、特別な設定や構成をしなくてもすぐにご利用いただけます。
発表２：HTML ドキュメントの表形式検索が利用可能に
Kendra で、HTML ページの埋め込みテーブルから、より直感的かつ効率的に検索できる、表形式検索がサポートされました。
Amazon Kendra で HTML の表形式検索を使用して、「ビジネスクレジットカードの APR」や「年会費が最も安いクレジットカード」のように検索すると、質問の回答を含むクレジットカード比較表がマーケティングウェブページに表示されます。表形式検索は、幅広い HTML 表形式やドメインにデフォルトで対応しているため、特別な設定や構成は必要ありません。
特に気になったのは「セマンティック検索に日本語が対応した」という発表です。
これでかなり日本語での利便性も向上するのでは？と思い、実際に確認してみる事にした訳です。
また、Amazon Kendra自体のサービス内容についても、今回十分に確認してみたいと思いました。
ですので、今回の記事の内容は、以下の2点がポイントとなります。
ポイント１：「Amazon Kendra」の日本語対応の状況について
ポイント２：「Amazon Kendra」システムの利便性について
１．そもそもAmazon Kendraとは？
そもそも「Amazon Kendra」とは何かについてご説明します。
知っている方は、「１.」はまるまる飛ばして「２.」にお進みください。
読み方は「ケンドラ」です。
公式の説明は以下の通りです。
Amazon Kendra は、ユーザーが自然言語処理と高度な検索アルゴリズムを使用して非構造化データと構造化データを検索できるようにする、非常に正確でインテリジェントな検索サービスです。質問に対する具体的な回答を返し、人間の専門家との対話に近いエクスペリエンスをユーザーに提供します。スケーラビリティが高く、パフォーマンスの要求を満たすことができ、 Amazon S3やAmazon Lexなどの他の AWS サービスと緊密に統合され、エンタープライズ レベルのセキュリティを提供します。
単的に表現すると、S3などに格納されているデータから情報を抽出し、検索可能な状態にして提供してくれるサービスです。
利用上の利点として「精度」「シンプルさ」「接続性」「ユーザアクセス制御」という『4つの利点』があげられています。このうち「精度」には「質問の文脈を理解する」との記載があり、これが今回「日本語対応」された「セマンティック検索」を指しています。
ちなみに「ケンドラ」の名前の由来はちょっと気になっています。
普通に考えると女性の名前なのですが……。なぜ「ケンドラ」なのか？？？？
もし、ご存じの方がいれば教えてください。
なお、「Amazon Kendra」の詳細は以下のドキュメントがありますので、もう少し詳しく知りたい方はご確認ください。
| 資料名 | 説明内容 |
|---|---|
| Developer Guide | Amazon Kendra の概念的な概要を提供します。Amazon Kendra の機能について学び、コンソール、AWS CLI、および API を使用してドキュメントのインデックス作成を開始します。 |
| API Reference | Amazon Kendra の API オペレーションについて説明します。これには、各 API の要求パラメーターと応答要素、および一般的なエラーが含まれます。 |
２．アップデートの内容について
「Amazon Kendra」について理解できたところで、今回のアップデートの内容を確認します。
発表１：セマンティック検索の言語サポートを拡張
Kendra のセマンティック検索の言語サポートを拡張し、スペイン語、フランス語、ドイツ語、ポルトガル語、日本語、韓国語、中国語の 7 言語を新しく追加しました。
これらの言語のコンテンツにおいて、よくある質問のマッチング、ドキュメントランキング、質問に対する回答を含む Kendra の幅広いセマンティック機能をご利用いただけるようになりました。新しい言語の機能はデフォルトで有効となっており、特別な設定や構成をしなくてもすぐにご利用いただけます。
『セマンティック検索に日本語が対応した』という部分が重要です。
そもそもセマンティック検索は、以下の通りです。
セマンティック検索とは、ユーザーが検索エンジンに入力する語句（検索クエリ）が会話文のようにあいまいな場合であっても、ユーザーの検索意図（目的）を検索エンジンが理解し、ユーザーの求めるものに適合した検索結果を提供する技術・概念のことです。
そして、「Amazon Kendra」でセマンティック検索のサポート有無による機能の違いは以下の通りです。
| サポート有無 | 内容 |
|---|---|
| 無し | ドキュメントの関連性と FAQ に対して単純なキーワードマッチングがサポートされています。 |
| 有り | 次の機能がサポートされています。 ・単純なキーワード マッチングを超えたドキュメントの関連性。 ・単純なキーワード マッチングを超えたFAQ。 ・Amazon Kendra の読解力に基づいて、ドキュメントから回答を抽出。 ・検索結果の信頼度バケット (非常に高い、高い、中、低い)。 |
曖昧な表現が多いですが、サポートの有無でかなりの機能差がありことは確かです。
今回のアップデートで日本語が含まれたことで、かなり検索結果に期待が持てるようになりました。
ただ、注意点があります。
シノニム (カスタム シノニムを含む)、増分学習とフィードバック、およびクエリの提案は、英語 (既定の言語) でのみサポートされています。
やはり、まだ「英語」でないと利用できない機能も多い訳です。
記載されている機能の内容は以下の通りです。
| 区分 | 内容 |
|---|---|
|
シノニム ※カスタムシノニム含む |
同義語のデータをインポートして、検索結果を改善する機能です。 |
| 増分学習とフィードバック | Amazon Kendra増分学習を使用して検索結果を改善します。クエリからのフィードバックを使用して、増分学習によってランク付けアルゴリズムが改善され、検索結果が最適化され、精度が向上します。 |
| クエリの提案 | Amazon Kendraクエリ履歴でユーザーに関連するクエリを提案します。Amazon Kendraは、ユーザーが検索し、これらのクエリから学習したすべてのクエリを使用して、ユーザーに提案を行います。 |
結構価値のある機能が「日本語」では使えていないような気がしますね。
まだまだ「英語」と「日本語」の機能には大きな差があります。
発表２：HTML ドキュメントの表形式検索が利用可能に
Kendra で、HTML ページの埋め込みテーブルから、より直感的かつ効率的に検索できる、表形式検索がサポートされました。
Amazon Kendra で HTML の表形式検索を使用して、「ビジネスクレジットカードの APR」や「年会費が最も安いクレジットカード」のように検索すると、質問の回答を含むクレジットカード比較表がマーケティングウェブページに表示されます。表形式検索は、幅広い HTML 表形式やドメインにデフォルトで対応しているため、特別な設定や構成は必要ありません。
この機能もあれば嬉しい機能なのですが、よく見ると注意書きがあります。
Amazon Kendra は、table タグ内にある HTML テーブルを含む英語のドキュメントのみをサポートします。
そうです。こちらの機能も残念ながら「日本語」では利用できないのです。
アップデートの内容を受けて
アップデートの内容を元に確認しましたが、「日本語」対応についてはまだまだ対応中の内容が多いのが実態のようです。
ただ、「セマンティック検索」機能が「日本語対応」したのは事実です。
この機会にサービスを実際に利用してみて、検証してみたいと思います。
「Amazon Kendra」サービスの利便性については、とても気になるところです。
３．～４．はその内容を記載します。
３．Amazon Kendraサービスの検証
実際の動作について検証するために、「Amazon Kendra」サービスを利用してみます。
今回の環境に関しては、以下の状態が最終系になります。
今回は、データソースとして「S3」から「PDFファイル」や「FAQファイル」を「Amazon Kendra」に連携し、その結果を検索サービスとして「AWSアクセスポータル」経由で公開するところまで進めます。流れが分かるように、随時で上記の図を元に作業箇所を示すようにします。
まず、3章では以下の赤枠の部分が作業範囲となります。
3章は、データソースとして「S3」から「PDF」ファイルや「FAQ」ファイルを「Amazon Kendra」に連携し検索テストを実施するところまでの対応になります。
３．１ リージョンの選定
「Amazon Kendra」が利用できるリージョンは以下の通りです。
「セマンティック検索」は「日本語対応」したけれど、まだ「東京リージョン」「大阪リージョン」では利用できません。
他にも機能によっては利用リージョンが制限されるものがあります。例えばVPC で構成されたデータベースデータソースの場合は、サブネットが次のアベイラビリティー ゾーン ID のいずれかにある必要があるようです。本番利用される際には、自分の利用したい機能が利用可能なリージョンなのかを確認の上、選定してください。
・米国西部 (オレゴン) — usw2-az1、usw2-az2、usw2-az3
・米国東部 (バージニア北部) — use1-az1、use1-az2、use1-az4
・EU (アイルランド) — euw1-az1、uew1-az2、euw1-az3
今回は「米国東部(バージニア北部 us-east-1」で実施します。
３．２ インデックスの作成
続いて「インデックスを作成」します。
作業範囲は以下となります。
「Amazon Kendra」ではまず最初にインデックスを作成する必要があります。この作成した「インデックス」領域でデータソースとの連携や検索サービスの公開を実施します。
「Amazon Kendra」のコンソール画面はまだ日本語化されていません。ですので以降のコンソール画面操作が英語になっていますのでご了承ください。こちらも日本語化してほしいところです。
まずは「Create an Index」を選択します。
「Index name」を入力し、「IAM role」を新規作成します。
「Use an AWS KMS managed encryption key」を選択すると保存データの暗号化が可能です。AWS Key Management Service (AWS KMS) でアカウント内にあるキーを指定します。KMS キーを指定しない場合、Amazon Kendra はデフォルトのキーを使用してインデックス内の情報を暗号化します。
「Configure user access control」画面が表示されるので、ここでは特に設定せずに、「NEXT」で処理を進めます。
「Specify provisioning」画面が表示されます。ここは費用や性能に関わるところなので重要です。「Developer Edition」と「Enterprise Edition」の2つのエディションが準備されています。以下は簡単な差異の情報ですが、詳細を知りたい方は「料金表」をご確認ください。
| 機能 | Developer Edition | Enterprise Edition |
|---|---|---|
| データソース | それぞれ最大 5 つのデータ ソースを持つ最大 5 つのインデックス | それぞれ最大 50 のデータ ソースを持つ最大 5 つのインデックス |
| ストレージ | 10,000 ドキュメントまたは 3 GB の抽出テキスト | 100,000 ドキュメントまたは 30 GB の抽出テキスト |
| 処理能力 | 1 日あたり約 4,000 クエリ、または 1 秒あたり約 0.05 クエリ | 1 日あたり約 8,000 クエリ、または 1 秒あたり約 0.1 クエリ |
| AZ | 1 つのアベイラビリティ ゾーン (AZ) で実行 | 3 つのアベイラビリティ ゾーン (AZ) で実行 |
| 用途 | 主に開発用 | 主に本番用 |
| 料金 | 安価 | 標準 |
ここは検証目的なので「Developer edition」で進めます。そのまま「Create]を選択します。
「Amazon Kendra」は基本的に従量課金制です。「Developer edition」が安価とはいえ、そのまま環境を残していると着実に課金されます。検証目的の場合は一定のめどがついた段階で「インデックスとデータソースの削除」を実施して環境を削除することをお勧めします。
インデックスの作成が開始されます。
「30 分かかる場合があります。」と表示されます。
正直、30分はかかっていません。15分以内には終わっていたと思います。
３．３ データソースの作成
続いて「データソースの作成」をします。
作業範囲は以下となります。
データソースは、「Amazon Kendra」が接続してドキュメントまたはコンテンツのインデックスを作成するデータリポジトリまたは場所です。「Amazon Kendra」を設定して、このソースに保存されているドキュメントをクロールしてインデックス化する手順になります。
登録できるドキュメントの種類があります。
今回は「非構造化テキスト」の取り込み手順で、「PDF」ファイルを登録します。
また、データソースを選択する必要があります。AWSサービスなら「S3」や「RDS」、「FSx」などを選択することができます。他者サービスなら「box」や「GoogleDrive」、「OneDrive」などと連携することができます。また、「Web Crawler」という機能をりようして、Webサイトの情報を収集することも可能です。
基本的に、各データソースとの連携方法や前提条件は「データソース」に記載されています。連携したいデータソースの情報を確認すれば、対応が可能かと思います。
今回は「S3を利用する手順」で実施します。
「S3」には事前に「バケット」を作成し、「PDFファイル」を格納しています。
今回は検証という事もあり、10ファイル程の保存としています。
「Add connector」を選択します。
「Specify data source details」画面で「Data souce name」を入力します。
そして「language」を「Japanese(ja)」にします。ドキュメントをインデックス用にフィルター処理するための言語設定です。
入力が完了したら「Next」を選択します。
「Define access and spcurity」画面で「IAM role」を新規作成します。
「Configure sync settings」画面に遷移します。
「Sync scope」では事前に準備した「PDFファイル」を格納した「S3」の「バケット」を指定します。
そして「Sync run schedule」でデータの同期タイミングを設定します。
「Next」を選択します。
「Set field mappings - optional」画面が表示されるので、「Next」を選択します。
「Review and create」画面が表示されるので「Add data souce」を選択します。
これでデータソースの追加処理が開始します。
状態が「Data souce state」が「Active」になったら作成完了です。
次に対象のデータソースを選択して、「Sync Now」で同期処理を開始します。
今回は10個のPDFファイルでしたので、5分以内に終了しました。
データ ソースを同期処理の中では以下の2つの処理が実施されます。そして、同期速度は、リモート リポジトリのスループットとスロットリング、ネットワーク帯域幅、ドキュメントのサイズなどの要因によって制限されます。数分で終わることもあれば数時間かかることもあります。
・ドキュメントがクロールされ、インデックスを作成するドキュメントが決定されます。
・選択したドキュメントが索引付けされます。
３．４ 動作確認
同期が完了したら「Search indexed content」で動作確認を実施できます。
作業範囲は以下の通りです。
「Amazon Kendra」のコンソール画面内にある「Search indexed content」画面で検索テストを実施できます。ここではその確認を実施します。
「Search indexed content」を選択すると、検索画面が表示されます。
まず、「Settings」で「Langage」を「Japanese(ja)」に変更します。
これを忘れると、何も検索結果にヒットしません。
その上で「Enter a text query」に検索条件を入力します。
対象の文言を含んだ資料が表示されます。
ここで思い出してほしいのが、アップデートの内容である「セマンティック検索」です。
Kendra のセマンティック検索の言語サポートを拡張し、スペイン語、フランス語、ドイツ語、ポルトガル語、日本語、韓国語、中国語の 7 言語を新しく追加しました。
これらの言語のコンテンツにおいて、よくある質問のマッチング、ドキュメントランキング、質問に対する回答を含む Kendra の幅広いセマンティック機能をご利用いただけるようになりました。新しい言語の機能はデフォルトで有効となっており、特別な設定や構成をしなくてもすぐにご利用いただけます。
ということで、色々検索してみました。
色々検索………。
という形で、色々と検索を試してみましたが、「セマンティック検索」の効果がなかなか判断しにくいところです。このアップデート前後での比較がしたかったところです。今回関心を持った方がおられましたら、是非自分のデータを同期させて、その性能を確認してみてください。
なお、データソースに関して補足です。
データソースは1つのインデックスに対して複数登録することが可能です。データソース単位で同期タイミングなどを設定可能です。データソース自体の更新頻度などを加味して、登録を分割するなど、運用面を考慮した設定ができます。
幾つかのデータソースを連携してみましたが、「WebCrawler」は利用頻度が高いと感じました。この連携ではウェブページのクロールとインデックス作成を行うことができます。一般公開されているWebサイトと、安全な通信プロトコルである Hypertext Transfer Protocol Secure (HTTPS) を使用する Web サイトのみをクロール対象となります。
S3や他のデータソースと同様に登録が可能で、定期的に同期することが可能です。
「Amazon Kendra」を利用される際には、是非その動作を試してみてください。
３．５ FQA（よくある質問と回答）の追加
先ほどは「非構造化テキスト」である「PDF」ファイルの登録を実施しました。
登録できるドキュメントの種類には「非構造化テキスト」である「よくある質問と回答（FAQ）」があります。他のデータと異なり登録方法が異なるため、こちらも登録してみます。
作業範囲は以下の通りです。
「よくある質問と回答 (FAQ)」をインデックスに直接追加する作業でです。インデックスへの「FAQ」の追加は、非同期操作なので、先ほど実施したデータソースのように同期タイミングを設定できません。FAQ のデータは、「S3」の「バケット」に「CSVファイル」として保存して登録します。
このFAQの登録をするためには、まずは様式に従った「CSVファイル」を作成する必要があります。「基本CSVファイル」を作成します。こちらのフォーマットは「質問、回答、および詳細情報を含むドキュメントを指すオプションのソースURI 」の3つのフィールドからなります。
今回は「基本CSVファイル」を作成しますが、「カスタムCSVファイル」を作成して項目を追加・編集することも可能です。
FAQ用の「基本CSV」が作成出来たら「S3」の「バケット」に格納します。これはFAQ用に個別の「バケット」を作成してください。
「FAQｓ」の「Add FAQ」を選択します。
「Add FAQ」画面で、「FAQ name」を入力します。
そして「language」を「Japanese(ja)」にします。ドキュメントをインデックス用にフィルター処理するための言語設定です。
「FAQ file format」では「基本CSVファイル」を指す「.csv file -Basic」を選択してください。
「S3」では先ほど登録した「CSVファイル」を指定します。
「IAM role」は「Create new role」で新規作成してください。
入力が完了したら「Add」を選択します。
FAQsの作成が開始されます。
無事登録が完了すると「Status」が「Active」になります。
「Search indexed content」で動作確認を実施すると、以下の「VPCの操作方法は？」のように表示されます。通常のデータソースの検索結果の上部に表示するような形です。
以上がFAQの登録方法でした。
４．検索サービスの公開
さて、検索環境が整ったところで、この検索サービスの公開方法になります。
本来はフロントエンドの環境を構築する必要があり準備には時間がかかります。しかし「Amazon Kendra」では「Amazon Kendra Experience Builder」というサービスを提供しており、これを利用すればノーコードで外部公開することが可能です。
この環境を準備する為には「AWS IAM Identity Center (AWS Single Sign-On の後継) 」との連携が必要になります。
4章では以下の赤枠の部分が作業範囲となります。
４章は、「Amazon Kendra Experience Builder」を活用して、「AWS IAM Identity Center」と連携を行い、検索サイトを外部公開する手順です。
なお、「AWS IAM Identity Center」は複数のAWSアカウントおよびビジネスアプリケーションへのアクセスの一元管理を実現するサービスです。今回利用する「Amazon Kendra Experience Builder」を利用する場合は、「AWS IAM Identity Center」の利用が必須です。
４．１ AWS IAM Identity Center (AWS Single Sign-On の後継) の事前設定
「AWS IAM Identity Center」でユーザの準備を実施します。
この作業範囲は以下の通りです。
「AWS IAM Identity Center」画面で「IAM Identity Centerを有効化」で「有効にする」を選択してください。
「ユーザー」で「ユーザの追加」を選択してユーザ情報を登録します。
ユーザの作成が完了します。今回は「テスト太郎」というユーザを作成しました。
ユーザ登録の際に登録したメールアドレスに確認のメールが届くので「Accept Invitation」を選択します。
新規パスワードを設定して「新しいパスワードを設定」を選択します。
正常に登録が完了すると、以下のメッセージが表示されます。
ログイン画面が表示されるので、「ユーザー名」を入力して「次へ」を選択します。
先ほど設定した「パスワード」を入力して「サイトイン」を選択します。
ログインに成功します。この際に開いているのはテスト太郎の「AWSアクセスポータル」画面になります。
現在サービスが登録されていないので、何も表示されていません。
これで「AWS IAM Identity Center」の準備は整いました。
４．２ Amazon Kendra Experience Builder の設定
「AWS IAM Identity Center」でユーザの準備ができたら、「Amazon Kendra Experience Builder」の設定を進めます。
この作業範囲は以下の通りです。
まずは「Experience」を選択します。
「Experience Builder」画面で「Create experience」を選択します。
「Configure experience」画面で「Experience name」に名前を入力します。
そして「Content sources」で公開する対象のデータソースを選択します。
「Experience name」は後程各ユーザがコンソールからログインする際に、以下のように表示されます。
「IAM role」を「Create a new role」で新規に作成します。
「Confirm your identity from an AWS IAM Identity Center directory」画面が表示されます。
ここでは「AWS IAM Identity Center」で登録しているユーザが表示されます。
今回は先ほど登録した「テスト太郎」を選択して「Next」を選択します。
「Review to open in Experience Builder」画面で「Create Experience and open Experience Builder」を選択します。
「Experience Builder」の作成が開始されます。
「検索エクスペリエンスを作成しています!ちょっと待って。これには数分かかる場合があります。」と表示されます。
作成が完了します。
作成が完了すると、対象のエクスペリエンスの詳細画面が表示されるので、そこで「Experience URL」をコピーします。
４．３ 実際の外部接続確認
上記の「Experience URL」を利用してログインすると、ログイン後は直接「Experience」の検索サービス画面が表示されます。「IAM Identity Center」の「AWSアクセスポータル」からログインすると、サービスを選択する画面が表示されてから「Experience」の検索サービス画面が表示されます。今回の手順は「IAM Identity Center」のアクセスポータルからのログイン手順とします。
なお、「IAM Identity Center」の「AWS アクセスポータルの URL」は以下の画面で確認できます。
この作業範囲は以下の通りです。
「AWS アクセスポータルの URL」でアクセスを実施します。ログインが画面が表示されます。
「ユーザー名」に先ほど作成した名前を入力して、「次へ」を選択します。
「パスワード」に対象ユーザのパスワードを入力します。
以下の画面が表示されると「AWS アクセスポータル」へのログインが完了となります。
画面に表示されている「Experience Builder」のサービスを選択します。
「AWSアクセスポータル」にはMFA（多要素認証）を追加することが可能です。追加したい場合は、画面右上の「MFA devices」から登録してください。設定後は以下の画面が表示されるようになります。
「Experience」は作成した単位で表示されます。以下は2つの「Experience」を登録した場合の表示となります。
検索サービスの画面が表示されます。
ただ、このままでは標準の「English」検索になっており、変更が必要です。
「Switch to build mode」を選択します。
「Settings」で「Langage」を「Japanese(ja)」に変更します。
これを忘れると、何も検索結果にヒットしません。
「Swich to Live view」を選択します。
検索画面に戻ります。
文字列を入力して検索を実施し、問題なく検索できることを確認します。
これで、以下の環境が準備できました。
５．まとめ
今回利用した上で、以下に感想をまとめます。
５．１ 日本語対応状況について
今回のアップデートで「セマンティック検索の言語サポート」により「日本語」対応がされて、利便性は向上しました。ただし、「シノニム (カスタム シノニムを含む)」、「増分学習とフィードバック」、「クエリの提案」といった機能は「英語」対応しかされておらず、まだ「Amazon Kendra」における多くの機能面でのメリットを「日本語」では享受できないのが実態です。また、今回アップデートされた「HTML ドキュメントの表形式検索」も「英語」対応のみです。
また、「Amazon Kendra」のAWSコンソール画面も日本語対応していません。
こちらも合わせて日本語化対応されると嬉しいところです。
「日本語」において「Amazon Kendra」の真価を体感するには、もう少し時間が必要になりそうです。
５．２ システムの利便性について
多くのデータソースと連携が可能となっているのと、パラメータの設定も分かりやすく、利便性は高いと感じました。外部公開に関しては複雑な環境構築が本来は必要ですが、「Amazon Kendra Experience Builder」を利用することで、高いセキュリティを確保しながら簡易に外部への公開をすることも可能になっています。スピーディーに検索サービスを開始したい場合には、非常に価値があるサービスだと思います。
なお、途中でも触れましたが利用料は従量制ですが、金額を見る限り個人ではなく組織で利用することが前提になるかと思います。金額は「料金表」をご確認ください。この金額に見合う利用方法を検討することが重要かと思います。
５．３ 「Amazon Kendra」の今後の日本での利用について
もちろん現状でも十分に日本での利用が可能です。
ただ、先述の「日本語」に対する対応が進めば進むほど、導入価値が高まるかと思います。また、利用リージョンが拡大され、東京リージョンや大阪リージョンでも利用可能になることも利用促進に繋がるかと思います。少しずつ日本語化対応が進んでおり、近い将来に上記のアップデートがあるかもしれないと期待させられます。今後もアップデートに注目していきたいと思います。
今回の記事は以上になります。
なお、この記事は2022年12月時点の内容になりますので、ご承知おきください。
この記事が皆さんが「Amazon Kendra」のサービスを知るうえで、良いきっかけになってくれたのであれば幸いです。
