【セッションレポート】生成 AI のためのデータ活用実践ガイド（AWS-08） #AWSSummit

コーヒーが好きな emi です。

本記事は 2025 年 6 月 25 - 26 日の 2 日間幕張メッセで開催中の AWS Summit Japan 2025 のセッションレポートとなります。
私が行った時は土砂降りで大変足元が悪かったのですが、帰りは雨がやんでいました。

セッション概要

• セッションタイトル: 生成 AI のためのデータ活用実践ガイド
• 日時: 2025年6月25日（水）12:50 - 13:30
• レベル: Level 300（中級者向け）
• テーマ: AI
  • データベース、機械学習・生成AI
• 登壇者: 高野 翔史（アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 自動車・製造グループ ソリューションアーキテクト）

生成 AI におけるデータの適切な活用は企業の競争力を左右する重要な要素となっています。本セッションでは、Retrieval Augmented Generation (RAG) の実践的な実装方法と、効果的なデータ基盤の構築について掘り下げていきます。システムが適切な回答を提供するために、ユーザーの状況を理解し、関連する情報を正確に取得する手法を解説します。また、データの前処理から分割手法、ベクトルデータベースの選択基準まで、実装に必要な具体的な手順を、実際のユースケースを用いて解説していきます。さらに、データの品質管理とガバナンスの重要性にも触れ、RAG システムを本番環境で運用する際の実践的なアプローチについても共有します。基本的な実装から高度な手法まで解説することで、参加者の皆様は生成 AI システムにおけるデータ戦略の重要性と実践的な実装方法について理解いただくことができます。

RAGで重要なコンテキストとは

実例：自動車保険の相談シナリオ

自動車保険を検討している顧客（Pat さん）を例に、RAG の重要性が説明されました。

• 車を購入済み
• 3台目の車両、古い車は売却済み
• 自動車保険の料金と補償内容を知りたい

例えばここで生成 AI のチャットアプリで Pat さんが 「自動車保険について知りたいです」 と聞いたとしても、単純なチャットアプリでは一般的な保険の定義しか返せません。
しかし、運転履歴、事故情報、保険会社の情報などのナレッジベースがあることで、詳細な見積もりを提示できるようになります。

コンテキストの種類

1. 状況コンテキスト（事実）

   • 車のスペック等の具体的な情報
   • データベースに格納されていることが多い

2. セマンティックコンテキスト

   • 類似性や意味を与える情報
   • 法律、請求条項等
   • ベクトル検索による取得が必要

応答精度を高めるテクニック

RAGの発展段階

1. Naive RAG（ナイーブラグ）

• 基本的な実装パターン
• 例えば PDF をチャンク分割し、埋め込みモデルでベクトル化してベクトル DB に格納
• ユーザーの質問をベクトル変換して類似検索
• 多くのケースでこれで十分だが、パーソナライズされた回答には限界がある

2. Advanced RAG

• 前処理・後処理を追加
• ハイブリッド検索（全文検索とベクトル検索の組み合わせ）
• Graph RAG（複雑な関連性がある場合に効果的）
• 追加のガードレールとリランキング

3. Modular RAG

• より高いユーザー体験を目指す
• 複数の DB を呼び出す際に Bedrock Agent でオーケストレーション
• 様々なステップを自動で実行・提案

データ基盤の構築

チャンキング方法の選択肢

1. Fixed chunking（固定長）

   • 実装が容易、コンテキストを失いやすい

2. Schema 定義

   • コンテキストは保たれるがスキーマ定義が必要で実装が大変

3. Hierarchical chunking（階層的）

   • 親チャンクと子チャンクで階層構造、ドメイン知識が必要

4. Semantic chunking（セマンティック）

   • 文章の関係性を抽出、LLM 使用のため時間とリソースが必要

• チャンクサイズ大 → トークン数多 → コスト高・時間長
• チャンクサイズ小 → 呼び出し回数多 → 総コスト増の可能性
• 補足
  • チャンク：テキストを分割した単位（文章や段落レベル）
  • トークン：AI が処理する最小単位（単語の一部〜数単語）

それぞれメリット・デメリットがあるので用途に応じた適切なバランスを見極める必要があります。

ベクトルデータベースの選択基準

• 慣れているもの
• 実装しやすいもの
• Naive RAG か Advanced RAG かの用途
• スケーラビリティとパフォーマンス要件

データの関連性が複雑なものは Neputune などを選択する必要があります。
まずは馴染みやすく近づきやすいものから始めることが推奨されていました。

効率的なデータ収集のコツ

ビッグデータ基盤アーキテクチャのベストプラクティス

1. 疎結合に作る

   • 蓄積と加工は別にして再利用しやすくする

2. 適切なツールを選ぶ

   • 鮮度、レイテンシー、スループット、アクセスパターンを考慮

3. マネージドサービスを活用

   • クラスタ管理など、顧客ビジネスの仕組みに関わらないインフラ部分の負担は積極的に軽減

4. ログ中心のデザインパターン

   • イミュータブルなデータ保存で元データを残す

5. コスト最適化

   • 不要な機能は使わない

RAGに適したアーキテクチャ

フロントエンド

• ユーザーアクセス、同時アクセス数、画面、レイテンシー要件を考慮
• 会話の状態・履歴保存（DynamoDB 等）

バックエンド

• データ収集・管理
• S3 をデータレイクとして活用
  • 昨今は OTF（Open Table Format）も利用可能（S3 Tables）
• データ頻度が重要な場合は直接投入機能を使用
• データガバナンス、品質、リネージの管理

データガバナンス

• サイロ化を防ぐ
• アクセス制御とガバナンスの両立
• Glue Data Quality でルールを宣言的に記述
• 複雑なルールも対応可能

まとめ

• Naive RAG から始めて段階的に発展させるのが良い
• 全てをベクトル化する必要はない。用途に応じて適切な手法を選択する
• パイプラインの自動化を積極的に推進
  • 顧客への価値提供に関係ない部分は積極的に自動化する

生成AIにおけるデータ活用の実践的なアプローチを具体的な実例と技術的な詳細とともに解説されました。一口で RAG と言ってもナイーブ RAG からモジュラー RAG まで種類があるのを知らなかったので勉強になりました。自動車保険の例も分かりやすく、イメージが湧きやすかったです。