Amazon Bedrockで実現する堅牢なデータエンジニアリング

Transcript

1. AWS活用 AI/ML/LLM #5 機械学習/大規模言語モデル データエンジニアリング Amazon Bedrockで実現する 堅牢なデータエンジニアリング 株式会社BLUEISH 代表取締役CEO兼CTO 為藤アキラ @AkiraTameto
2. 為藤 アキラ (Akira Tameto) 株式会社BLUEISH 代表取締役 CEO兼CTO ・AWS歴12年 ・直近のAIプロジェクト マルチAIエージェントサービス 「BLUEISH Agents」の開発 自己紹介
3. データエンジニアリングとは？ データエンジニアリングの定義 大規模データを収集 / 加工 / 保管 / 配信するためのシステムやインフラを設計 / 開発 / 運用し、 組織の意思決定やデータ活用を支える基盤を構築する分野
 データエンジニアリングの目2 1 大規模データを扱い、後続（分析・AI活用など）で使いやすい形にす“ 1 データ品質・セキュリティ・パフォーマンスを担保する
4. AI / ML観点でのデータエンジニアリングとは？ 基本的なデータエンジニアリングのプロセス 生データの収集 ① 変換 ② 提供 ④ 保存 ③
5. データ分析観点でのデータエンジニアリングとは？ データ分析観点でのデータエンジニアリングのプロセス 生データの収集 ① 変換
 (ETL/ELT処理) ② 提供 ④ 保存
 (データウェアハウス/ データレイク) ③
6. データ分析観点でのデータエンジニアリングをAWS運用で当てはめると データ分析観点でのデータエンジニアリングのプロセス (AWS) 生データの収集 ① 変換
 (ETL/ELT処理) ② 提供 ④ 保存
 (データウェアハウス/ データレイク) ③ { Amazon Kinesij { AWS Data Migration Servics { AWS IoT Core { AWS Glus { EMƒ { Data Pipelins { Athena { Amazon S¢ { Amazon Redshifš { AWS Lake Formation { Amazon QuickSighš { API Gatewaº { AWS Glue Data Catalog
7. AI / ML観点でのデータエンジニアリングをAWS運用で当てはめると AI / ML観点でのデータエンジニアリングのプロセス 生データの収集 ① 変換 → 前処理
 (特徴量抽出 / 
 ラベリング) ② 提供
 (推論エンドポイント) ④ 保存
 (学習用データセット) ③
8. AI / ML観点でのデータエンジニアリングをAWS運用で当てはめると AI / ML観点でのデータエンジニアリングのプロセス (AWS) 生データの収集 ① 変換
 (ETL/ELT処理) ② 提供 ④ 保存
 (データウェアハウス/ データレイク) ③ € Amazon Kinesio € AWS Data Migration Servicx € S3 € AWS Glux € EMŠ € SageMaker Processing € S3 + SageMaker Ground Truth € SageMaker Endpoint
9. LLM観点でのデータエンジニアリングとは？ LLM観点でのデータエンジニアリングのプロセス + LLM特有の工程非構造化データが多い! 生データの収集 ① 変換 → 前処理
 (PIIマスキング/ 
 トークナイゼーション) ② 提供
 (LLM推論エンドポイント / チャットサービス) ④ 保存
 (データレイク/
 ベクトル系のDB) ③
10. LLM観点でのデータエンジニアリングをAWS運用で当てはめると LLM観点でのデータエンジニアリングのプロセス (AWS) 生データの収集 ① 変換
 (ETL/ELT処理) ② 提供 ④ 保存
 (データウェアハウス/ データレイク) ③ x Kinesis Firehosm x Glue Crawler x S3 x AWS Glum x EM x Amazon Comprehend x S3š x Amazon OpenSearch x Amazon Bedrock
11. 生成AI時代のデータ課題やデータエンジニアリングの重要性 • 大規模言語モデル(LLM)の活用が企業で急増 • 不適切コンテンツ / 機密漏洩リスクが企業が抱える大きな課題 • 監視 / アラート / ポリシー管理が必須 • インシデントが起きると信用問題 / 法的リスクに直結
12. Amazon Bedrock ガードレールとは？ • Amazon Bedrock のエンタープライズ向け機能の一つ • 生成AIの不適切な入力・出力を制御し、企業ポリシーに合わせてフィルタリングする仕組み • モデル種類にかかわらず一貫した安全対策を適用可能 アプリケーション ユーザー ガードレール Amazon Bedrock LLMモデル 不適切な入力をブロック フィルタ 出力 入力
13. ガードレールの4つのフィルター 1. Denied topics 　 → 回答してはいけないトピックを自然言語ベースで設定 2. Content filters 　 → ヘイト・差別・暴力などを検知し自動遮断 3. Sensitive information filters (PIIフィルター) 　 → 個人情報・機密情報が出力されそうになったらブロック／マスク 4. Word filters 　 → 特定の単語やフレーズを指定してフィルタリング
14. LLMに関する、データパイプラインにおける主要課題 生データからのデータパイプラインは様々な課題がある

 (1) 機密情報を含む生データの扱い
 ↓
 (2) 不適切コンテンツ混入
 ↓ (3) マルチモデル運用のポリシー管理負担 ↓ (4) インシデント対応の難しさ
15. データパイプラインにおける主要課題 生データからのデータパイプラインは様々な課題がある

 (1) 機密情報を含む生データの扱い
 　 → 「 」 で個人情報を自動マスキング
 (2) 不適切コンテンツ混入
 　 → 「 」 でリアルタイムでヘイト・差別・暴力を検出 (3) マルチモデル運用のポリシー管理負担 　 → 「 」 で回答禁止領域をシステム的にブロック (4) インシデント対応の難しさ
 　 → 「 」で解決！ Sensitive information filters Content filters Denied topics 安全なAI Ops
16. Amazon Bedrock ガードレールの強みは「事前防御」 Amazon Bedrockのガードレールは、この「 」を複数モデルに対して統一ポリシーで実 行できるのが強みです。
 「 」とは、LLMに不適切な回答を渡す前に、不適切なやり取りや危険な内容が存在しな いかを自動的にフィルタリング・ブロックする仕組みを指します。 事前防御 事前防御 アプリケーション ユーザー カードレール Amazon Bedrock LLMモデル 不適切な入力をブロック フィルタ 出力 入力 事前防御！
17. Amazon Bedrock ガードレールによる保護体制の比較 vs 事前防御（Proactive Defense） 事後防御（Reactive Defense） 入力ガードレール 出力ガードレール LLMモデル 安全な応答 事前防御の特‰  ユーザーに不適切なコンテンツが届く前に遮x  入出力の両方でフィルタリングを実m  問題が発生する前にリスクを低‘  レビュテーションと信頼の保護に効果的 事後防御の課Ú  不適切なコンテンツが既にユーザーに届いた後の対¹  肥大が発生した後の修復は信頼回復が困º  問題検出までのタイムラグが発生する可能¤  レビュテーションリスクと法的リスクが高い 応答(未フィルタ）
 潜在的リスクあり インシデント対応 LLMモデル 問題への対応タイミングが 異なる モニタリングで問題検出!
18. AI Opsとしての設計から運用までの流れ ガードレールをきちんと生かすには設計から運用まで多層的に考えるのが重要。 e` 初期設計で安全策を組み込む y` 多層防御と継続モニタリング  Bedrock Guardrails＋ IAM/ネットワーク 制御＋定期アセスメンo  CloudWatchなどでコンテンツブロック数 を監視、異常値を即発見 ™` ハルシネーション対策・PII保護  RAG（検索拡張型）との併用や幻覚検出設 定、PIIマスク設定のテスト Ç` インシデント対応計画  もし不適切回答が漏れた場合、どのように 修正・ユーザー通知・再発防止するかまで ルール化 ú` 権限管理と変更管理の徹底  ガードレールの設定変更には承認フローを 導入し、CloudTrailでログを追跡  システム全体でガードレールの導入を
 前提にし、セキュリティ要件を明確化
19. AI Opsとしての設計から運用までの流れ (データエンジニアリング観点) ガードレールをきちんと生かすには設計から運用まで多層的に考えるのが重要。 yt 初期設計で安全策を組み込む “t 多層防御と継続モニタリング  Bedrock Guardrails＋ IAM/ネットワーク 制御＋定期アセスメン}  CloudWatchなどでコンテンツブロック数 を監視、異常値を即発見 §t ハルシネーション対策・PII保護  RAG（検索拡張型）との併用や幻覚検出設 定、PIIマスク設定のテスト Õt インシデント対応計画  もし不適切回答が漏れた場合、どのように 修正・ユーザー通知・再発防止するかまで ルール化 t 権限管理と変更管理の徹底  ガードレールの設定変更には承認フローを 導入し、CloudTrailでログを追跡  システム全体でガードレールの導入を
 前提にし、セキュリティ要件を明確化
20. まとめ fg データ分析 / ML / LLM でのデータエンジニアリングのアプローチの違G 2g Amazon Bedrock ガードレール + 他サービスで安全なLLMのデータ運 g AI OpsにおけるデータエンジニアリングでのAI運用成功の為のサイクル
21. Thank You!