変更要約: 初版: ドメイン1（FM統合・データ管理・コンプラ）の5節を作成
1.2FM 消費のためのデータ検証・処理パイプライン
FM に渡すデータの品質を担保するパイプラインを学びます。AWS Glue Data Quality、SageMaker Data Wrangler／Processing、マルチモーダル処理（Transcribe・Textract）、Bedrock API 向けの 入力フォーマット整形、Comprehend によるエンティティ抽出を扱います。
GenAI の出力品質は入力データの品質で決まります（garbage in, garbage out）。FM に渡す前に、検証・整形・正規化を行うパイプラインを設計します。特徴量エンジニアリングそのものは範囲外ですが、FM 消費向けのデータ準備は問われます。
1.2.1検証と多様なデータ型の処理
- AWS Glue Data Quality：データセットに品質ルールを定義し、欠損/異常を検出してからインジェストする。
- SageMaker Data Wrangler / Processing：前処理・変換ジョブを実行し、FM 入力に適した形へ整える。
- マルチモーダル前処理：音声は Amazon Transcribe、文書/画像は Amazon Textract でテキスト化してから FM へ渡す。
- 入力フォーマット整形：Bedrock API 向けに JSON 構造化、対話形式の整形、Comprehend でのエンティティ抽出・正規化を行う。
「インジェスト前の品質チェック＝Glue Data Quality」「音声→テキスト＝Transcribe」「文書/画像→テキスト＝Textract」「エンティティ抽出/PII 検出＝Comprehend」「FM 入力の構造化＝JSON 整形」 は AIP-C01 で頻出です。
RAG や FM 推論の前段では、ソースの多様なデータ型を正規化されたテキストに落とし込みます。スキャン文書や PDF は Amazon Textract（レイアウト/表/フォーム抽出）、通話やメディアは Amazon Transcribe（必要に応じて話者分離）、自由文からの構造抽出は Amazon Comprehend（エンティティ・キーフレーズ・PII）を使います。検証は AWS Glue Data Quality の DQDL ルールや Lambda カスタム検証、メトリクスは CloudWatch で監視します。大規模変換は SageMaker Processing/Data Wrangler、ストリーミング取り込みは Kinesis、バッチは Glue ジョブ。最後に Bedrock API が期待する JSON ペイロード（システムプロンプト・メッセージ配列・パラメータ）へ整形します。低品質な入力は Bedrock 自体で言い換え/要約して整える前処理も有効です。
| 入力 | 使うもの | 目的 |
|---|---|---|
| スキャン文書/PDF | Amazon Textract | レイアウト/表/フォーム抽出 |
| 音声/通話 | Amazon Transcribe | 音声→テキスト |
| 自由文の構造抽出 | Amazon Comprehend | エンティティ/PII/キーフレーズ |
| 品質ゲート | Glue Data Quality | インジェスト前の検証 |
ひっかけ： 「PDF の文字起こしに Transcribe を使う」は誤りです。Transcribe は音声用で、文書/画像は Textract。サービスのモダリティ（音声 vs 文書）を取り違えないこと。
1.2.2この節のまとめ
- 品質ゲート＝Glue Data Quality／文書＝Textract／音声＝Transcribe／抽出＝Comprehend
- FM 入力はJSON 構造化して渡す（低品質入力は Bedrock で整える前処理も可）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. コールセンターの通話音声を RAG のソースにしたい。FM に渡す前段で音声をテキスト化するのに最適なサービスは？
Q2. 取り込むデータセットに欠損や異常値が混じっており、FM へ渡す前に品質ルールで検証・ブロックしたい。何を使う？
Q3. 大量のスキャン PDF 請求書から表とフォーム項目を抽出し、構造化テキストとして FM に渡したい。最適なサービスは？