Amazon Kendra

解決する課題

社内マニュアル、規程、FAQ、ナレッジベース、設計書などは複数のシステムに散在し、必要な情報を探すのに時間がかかります。従来のキーワード検索は語句の完全一致に依存するため、表現の揺れや言い換えに弱く、欲しい答えにたどり着けないことがよくあります。Amazon Kendra を使うと、自然言語の質問から関連する文書や箇所を機械学習で見つけられます。

• 「経費精算の締め日はいつか」のように話し言葉に近い質問で検索できる
• 散在する文書を横断的に索引化し、一つの検索窓からまとめて探せる
• 単なる一致だけでなく意味的に関連する箇所を抽出し、根拠の文書へ案内する

検索エンジンの構築や言語モデルの運用を自分で抱えずに、社内向けの高度な検索体験を用意できる点が中心的な価値です。

主要概念と用語

• エンタープライズ検索: 社内に分散した文書群を横断して探すための検索。Kendra の主目的
• インデックス（索引）: 文書を取り込み、検索可能な状態で保持する中核リソース。検索はこのインデックスに対して行う
• データソース: 文書の供給元。S3 などのストレージや SaaS が該当する
• コネクタ: 各データソースとインデックスをつなぎ、文書を自動で取り込む仕組み
• 同期（クロール）: コネクタがデータソースを巡回し、新規・更新・削除を索引へ反映する処理
• ドキュメント検索: 質問に関連する文書の一覧を関連度順に返す基本機能
• パッセージ（抜粋）検索: 文書中の該当しそうな箇所そのものを抜き出して返す機能
• FAQ: あらかじめ用意した質問と回答の対を登録し、想定問答に即答させる機能
• ファセット: 部署や文書種別などの属性で検索結果を絞り込む仕組み
• 関連性チューニング: 特定フィールドの重みや鮮度を調整し、結果の並びを最適化する操作
• アクセスコントロールリスト（ACL）: 元システムの権限情報を取り込み、ユーザーごとに見える文書を制限する仕組み

仕様・制限・クォータ

• 検索の対象は事前に作成したインデックスで、まずインデックスを用意してからデータソースを接続する
• ストレージや SaaS など複数種類のデータソース用コネクタが提供され、対応範囲は拡張されていく
• 取り込める文書にはサイズや件数の上限があり、エディション（提供プラン）によって索引の容量や能力が異なる
• 複数の言語に対応し、日本語を含む言語で質問・検索ができる
• 文書には**属性（メタデータ）**を付与でき、絞り込みや関連性調整、アクセス制御に利用する
• 同期の頻度はスケジュール設定でき、変更分だけを反映する増分同期にも対応する

具体的な対応コネクタ・文書サイズ上限・クォータ値・エディションの違いは更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、データソースを接続して索引を作り、自然言語の質問を投げると関連文書や抜粋が返るマネージドな仕組みとして扱えます。

• 取り込み（インジェスト）: コネクタがデータソースを巡回し、文書本文とメタデータ、元システムのアクセス権限を読み取ってインデックスへ取り込む
• 索引化: 取り込んだ文書を機械学習モデルで処理し、語句の一致だけでなく意味的な近さでも検索できる形に整理する
• クエリ処理: 質問を受け取ると、関連する文書一覧、文書中の抜粋、登録済み FAQ の回答などを関連度付きで返す
• アクセス制御の反映: 取り込んだ権限情報を使い、検索したユーザーが本来見られない文書を結果から除外する

モデルの学習基盤やスケーリング、ハードウェアの管理はすべて AWS 側が担います。利用者は文書の供給と関連性の調整に集中できます。

設計パターン / ベストプラクティス

• コネクタで自動取り込み: 文書を手動投入せず、S3 や SaaS のコネクタを設定し、スケジュール同期で最新状態を保つ
• メタデータを充実させる: 部署・文書種別・更新日などの属性を付けると、ファセット絞り込みと関連性調整が効きやすくなる
• FAQ で頻出質問に即答: 問い合わせの多い定型質問は FAQ として登録し、検索結果より優先して回答させる
• 権限を元システムから引き継ぐ: ACL を取り込んでユーザーごとに結果を制御し、機密文書の漏えいを防ぐ
• 生成 AI と組み合わせる: Kendra で関連箇所を取得し、その内容を根拠に Amazon Bedrock などの言語モデルで回答文を生成する、いわゆる検索拡張生成（RAG）の情報源として使う

運用・監視

• 検索リクエスト数や同期ジョブの状況は CloudWatch のメトリクス・ログで監視する
• データソースの同期が失敗した場合は、エラー理由（権限不足、到達不能、非対応形式など）を確認し、接続設定と IAM を見直す
• どの質問でヒットが少ないか、クリックされない結果は何かを分析し、関連性チューニングや FAQ 追加で改善を回す
• API 操作の監査証跡は CloudTrail に記録される
• 利用しないインデックスは費用が継続するため、不要になったら削除して費用を抑える

コスト

• 課金は主にインデックスの稼働時間に基づき、検索リクエストや文書量がない時間帯でも索引が起動している限り費用が発生する
• エディション（提供プラン）によって索引の容量・能力と単価が異なり、扱える文書数や検索数の規模が変わる
• コネクタによる同期や追加機能に応じて費用が加わる場合がある

具体的な単価は変動するため、料金は公式の料金ページで確認してください。インデックスは常時起動で課金される性質のため、検証用に作ったものを使い終えたら削除するのが安全です。

セキュリティ

• アクセス制御は IAM で行い、データソースへの読み取りや索引操作に必要な最小権限のみを付与する
• 保存データは暗号化（KMS 管理鍵を利用可能）され、転送は TLS で保護される
• 元システムの ACL を取り込み、検索ユーザーごとに閲覧可能な文書だけを返すように制御できる
• ユーザー認証情報は IAM Identity Center などの ID 基盤と連携し、誰がどの文書を見られるかを判定する
• VPC 内のデータソースへプライベートに到達したい場合は、VPC 経由の接続構成を検討する

Well-Architected の観点

• 運用上の優秀性: マネージドサービスにより検索基盤の運用負荷を下げ、コネクタとスケジュール同期で文書の最新化を自動化できる
• セキュリティ: IAM の最小権限、保存・転送時の暗号化、ACL の引き継ぎにより、機密文書への不正な閲覧を防ぐ
• コスト最適化: インデックスは常時課金のため、規模に合うエディションを選び、不要な索引は削除する
• 信頼性: 同期失敗を監視・再試行し、データソース障害時にも検索が古い状態で止まり続けないようにする

試験で問われるポイント

関連サービス・比較

検索という点で近い Amazon OpenSearch Service とは目的が異なるため比較します。Kendra は自然言語による社内文書検索に特化し、OpenSearch は柔軟な全文検索やログ分析の基盤として使われます。

ハンズオン / CLI例

# インデックスの一覧を確認する
aws kendra list-indices \
  --query "IndexConfigurationSummaryItems[].{Name:Name,Id:Id,Status:Status}"

# 自然言語の質問でインデックスを検索する
aws kendra query \
  --index-id <インデックスID> \
  --query-text "経費精算の締め日はいつですか"