AWSデータガバナンスVol3｜Glue Data Quality/DQDL/品質モニタリング

1. Vol3概要 — Glue Data Quality本番実装に特化

1-1. シリーズにおけるVol3の位置づけ

AWSデータガバナンス本番運用シリーズは、エンタープライズデータ基盤に必要なガバナンスの全レイヤを3巻で体系化している。Vol1（DataZone/Lake Formation/Clean Rooms）はデータカタログの統制・組織横断のデータ共有・アクセス境界の設計を担う。Vol2（LF-Tag/セルレベルセキュリティ/データメッシュ/Macie）は属性ベースの細粒度アクセス制御と機密データの自動検出を担う。本Vol3（Glue Data Quality）は品質保証レイヤとして第3の柱を形成し、「誰が何にアクセスできるか」に加えて「そのデータが信頼できる品質か」を自動的に保証する仕組みを提供する。

3巻が揃うことで、AWSデータ基盤はカタログ統制・アクセス制御・品質保証の三位一体となり、コンプライアンス要件を満たす本番データガバナンス体制が完成する。Vol1 §6-1でGlue Data QualityのDQDL基礎（ルールセット概念・DQDLとは何か）を解説済みであるため、本Vol3ではその基礎の再説明を行わず、本番環境での実装手順・チューニング・運用監視に即座に入る。

→ Vol1 (基礎編): AWSデータガバナンス本番運用 Vol1｜DataZone×Lake Formation×Clean Rooms
→ Vol2 (アクセス制御編): AWSデータガバナンス本番運用 Vol2｜LF-Tag/セルレベル/データメッシュ/Macie

1-2. 読者像と前提知識

本Vol3の想定読者はGlue ETLジョブの開発・運用経験を持つデータエンジニアと、GlueデータカタログのテーブルメタデータやETLパイプラインを管理するデータカタログ管理者である。AWSサービスとしてはGlue、S3、CloudWatch、EventBridgeの基本的な操作経験を前提とする。

Vol1/Vol2を既読であり、Lake Formation権限モデル・LF-Tagアクセス制御の概念を理解していることを前提とする。DQDLとルールセットの基礎概念はVol1 §6-1で解説済みのため、本Vol3では概念説明を最小限とし、即座に実装コードと設定値の解説に移る。

本Vol3を通じて習得するスキルは、データエンジニアが日常業務でGlue Data Qualityを本番運用できるレベルを目標とする。具体的には、DQDLルールセットの設計・推奨ルール自動生成の活用・品質スコアのCloudWatch連携・SLA違反時のアラート設定・品質トレンドの可視化まで一気通貫で実装できることを目指す。初めてGlue Data Qualityに触れる場合は、Vol1 §6-1を先に参照することを推奨する。

本Vol3で使用するサービスは、AWS Glue（Data QualityとETL）・Amazon S3・Amazon CloudWatch・Amazon EventBridge・Amazon SNS・Amazon Athenaである。いずれもap-northeast-1（東京リージョン）での動作を前提とするが、Data Quality機能は全商用リージョンで利用可能である（2024年時点）。

1-3. 本番実装特化の宣言

本Vol3はVol1 §6-1で解説したDQ基礎の上に、Glue Data Quality本番実装に特化した実践ガイドである。「概念説明は最小限・コード例と設定値を主体とする」を本Vol3の基本方針とし、読んだその日から本番環境に適用できる具体的な実装手順を提供する。Vol1/Vol2既読を前提とし、基礎知識の再説明は行わない。

品質スコアは0.0〜1.0のdecimal値として算出される（パーセント値ではない）。本番SLA設計では「スコア0.95未満でアラート」「スコア0.80未満でパイプライン停止」のように複数閾値を段階設定することを推奨する。

本Vol3を完読することで得られる実装成果物は以下の5項目である。第1に、DQDL全ルールタイプの正式名称・構文・適用例を網羅したルールセット設計テンプレート。第2に、StartDataQualityRuleRecommendationRun + GetDataQualityRuleRecommendationRun APIペアを使った推奨ルール自動生成と閾値チューニングの手順（推奨ルール実行結果は90日後に自動削除される点に注意）。第3に、ETL組込みモードとData Catalog評価モードの選択基準と各モードのPythonコード実装例（AnalyzersとDynamicRulesはETLモードのみ対応）。第4に、EventBridgeイベントとglue.data.quality.rules.passed / glue.data.quality.rules.failedのCloudWatchメトリクス・SNSアラートを組み合わせた品質SLAモニタリング設定（メトリクス送出にはコンソール「Publish metrics to CloudWatch」オプションの有効化が必須）。第5に、品質スコア（0.0〜1.0のdecimal値）をS3蓄積・Athenaクエリ・QuickSight可視化するトレンドダッシュボードの構築手順。

本記事の構成: §2で環境準備と権限設計を行い、§3でDQDL全ルールタイプを網羅する。§4で推奨ルール自動生成・チューニングを実践し、§5でETL組込みモードとData Catalog評価モードの両実装を示す。§6でEventBridge/CloudWatch連携モニタリングを構築し、§7で品質トレンド可視化とガバナンスサイクルを確立する。§8はコスト試算とシリーズ総括である。

Vol1: DataZone×Lake Formationの基礎はこちら

2. 前提環境と準備

2-1. 必要なAWSサービス・権限

Glue Data Quality本番運用に必要なIAM権限を以下の表に示す。ETL組込みモード（GlueジョブロールにアタッチするポリシーA）とData Catalog評価モード専用ロール（スケジュール実行用ポリシーB）で最小権限を分離することを推奨する。

ポリシーA: GlueJobRole追加ポリシー（ETL組込みモード用）

ポリシーB: DataQualityCatalogRole（Data Catalog評価モード専用）

AWS CLIバージョン要件

AWS CLI 2.x（2.13.0以降を推奨）が必要である。Data Quality関連のサブコマンド（start-data-quality-ruleset-evaluation-run等）はCLI 2.xで正式サポートされている。CLI 1.x環境ではコマンドが存在しない場合があるため、aws --versionで確認のうえアップグレードすること。

# バージョン確認
aws --version
# aws-cli/2.x.x Python/3.x.x Darwin/... 以上であること

# IAM権限の事前確認 (dry-run相当)
aws glue list-data-quality-rulesets --region ap-northeast-1 --max-results 1

2-2. Glue Data Qualityの有効化

AWSコンソールでの有効化手順

1. AWS Management Console → Glue サービスを開く
2. 左側ナビゲーションの「Data Quality」セクションを選択する
3. 初回アクセス時はサービス利用確認画面が表示されるので「Enable Data Quality」をクリックする
4. 有効化後、「Rulesets」「Runs」「Results」の各タブが利用可能になる
5. 「Rulesets」→「Create ruleset」でルールセット作成画面に遷移できることを確認する

CLIでのGlue Data Quality有効化確認

コンソールでの有効化後、以下のCLIコマンドで正常に利用可能かを確認する。

# Data Qualityが有効かどうか確認（エラーなしで空リストが返れば有効）
aws glue list-data-quality-rulesets \
  --region ap-northeast-1 \
  --max-results 5

# 既存Glueカタログのデータベース一覧確認
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws glue get-databases \
  --catalog-id "${ACCOUNT_ID}" \
  --region ap-northeast-1 \
  --query 'DatabaseList[*].Name' \
  --output table

# 対象データベースのテーブル一覧と格納場所確認
aws glue get-tables \
  --database-name YOUR_DATABASE \
  --region ap-northeast-1 \
  --query 'TableList[*].{Name:Name,Location:StorageDescriptor.Location,Columns:StorageDescriptor.Columns[*].Name}' \
  --output json

既存ルールセットの一覧と詳細確認

# 既存ルールセット一覧（作成済みの場合）
aws glue list-data-quality-rulesets \
  --region ap-northeast-1

# 特定ルールセットの詳細確認（DQDLルール内容の確認）
aws glue get-data-quality-ruleset \
  --name YOUR_RULESET_NAME \
  --region ap-northeast-1 \
  --query '{Name:Name,Rules:Rules,TargetTable:TargetTable}'

Glue IAMロールへの権限アタッチ

既存のGlue実行ロール（GlueJobRole）に§2-1のポリシーAをアタッチする。インラインポリシーとして直接追加する場合は以下の手順を実行する。

# ポリシードキュメントをローカルに保存（glue-dq-policy.json）
cat > /tmp/glue-dq-policy.json << 'POLICY'
{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "glue:StartDataQualityRulesetEvaluationRun",
  "glue:GetDataQualityResult",
  "glue:GetDataQualityRulesetEvaluationRun",
  "glue:ListDataQualityResults",
  "glue:BatchGetDataQualityResult",
  "cloudwatch:PutMetricData",
  "logs:CreateLogGroup",
  "logs:CreateLogStream",
  "logs:PutLogEvents"
],
"Resource": "*"
 },
 {
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::YOUR-BUCKET/*"
 }
  ]
}
POLICY

# インラインポリシーとしてアタッチ
aws iam put-role-policy \
  --role-name GlueJobRole \
  --policy-name GlueDataQualityPolicy \
  --policy-document file:///tmp/glue-dq-policy.json

2-3. サンプルデータセットの準備

以降の §3〜§6 の実装手順を動作確認するため、品質問題（NULL・重複・異常値）を意図的に含むテストデータを準備する。NULL率15%・重複10件・範囲外値5件を含む25行のCSVを用いることで、DQDLルールが期待通りに機能するかを確認できる。

テストCSVの内容

order_id,customer_id,product_code,amount,order_date,status
1001,CUST001,PROD-A,15000,2024-01-05,completed
1002,CUST002,PROD-B,3200,2024-01-06,completed
1003,CUST003,PROD-A,87500,2024-01-07,completed
1004,CUST001,PROD-C,1200,2024-01-08,pending
1005,CUST004,,2800,2024-01-09,completed
1006,CUST005,PROD-B,4100,2024-01-10,completed
1007,CUST002,PROD-A,,2024-01-11,completed
1008,CUST006,PROD-D,9800,2024-01-12,shipped
1009,CUST007,PROD-B,2200,2024-01-13,completed
1010,CUST003,PROD-A,1500000,2024-01-14,completed
1001,CUST001,PROD-A,15000,2024-01-05,completed
1011,CUST008,PROD-C,,2024-01-15,pending
1012,,PROD-A,6700,2024-01-16,completed
1013,CUST009,PROD-B,4300,2024-01-17,completed
1014,CUST010,PROD-D,8900,2024-01-18,shipped
1002,CUST002,PROD-B,3200,2024-01-06,completed
1015,CUST011,PROD-A,11000,2024-01-19,completed
1016,CUST012,PROD-C,5600,2024-01-20,completed
1017,CUST013,,3700,2024-01-21,completed
1018,CUST014,PROD-B,-500,2024-01-22,completed
1019,CUST015,PROD-A,7800,2024-01-23,completed
1003,CUST003,PROD-A,87500,2024-01-07,completed
1020,CUST016,PROD-D,23000,2024-01-24,shipped
1021,CUST017,PROD-B,,2024-01-25,pending
1022,CUST018,PROD-A,9200,2024-01-26,invalid_status

このテストデータには以下の品質問題が意図的に含まれている。

S3へのアップロード

# テストデータをローカルに保存
cat > /tmp/orders_test.csv << 'CSV'
order_id,customer_id,product_code,amount,order_date,status
1001,CUST001,PROD-A,15000,2024-01-05,completed
... (上記CSVの内容)
CSV

# S3バケットへアップロード
BUCKET_NAME="your-dq-test-bucket"
aws s3 cp /tmp/orders_test.csv s3://${BUCKET_NAME}/raw/orders/orders_test.csv \
  --region ap-northeast-1

# アップロード確認
aws s3 ls s3://${BUCKET_NAME}/raw/orders/ --human-readable

Glueテーブルの作成

# Glueデータベース作成（既存の場合はスキップ）
aws glue create-database \
  --database-input '{"Name":"dq_test_db","Description":"Data Quality テスト用データベース"}' \
  --region ap-northeast-1

# Glueテーブル作成（テストCSVのスキーマ定義）
aws glue create-table \
  --database-name dq_test_db \
  --table-input '{
 "Name": "orders_raw",
 "Description": "DQテスト用受注データ",
 "StorageDescriptor": {
"Columns": [
  {"Name": "order_id", "Type": "int"},
  {"Name": "customer_id", "Type": "string"},
  {"Name": "product_code", "Type": "string"},
  {"Name": "amount", "Type": "int"},
  {"Name": "order_date", "Type": "string"},
  {"Name": "status", "Type": "string"}
],
"Location": "s3://your-dq-test-bucket/raw/orders/",
"InputFormat": "org.apache.hadoop.mapred.TextInputFormat",
"OutputFormat": "org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat",
"SerdeInfo": {
  "SerializationLibrary": "org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe",
  "Parameters": {
 "field.delim": ",",
 "skip.header.line.count": "1"
  }
}
 },
 "TableType": "EXTERNAL_TABLE",
 "Parameters": {"classification": "csv"}
  }' \
  --region ap-northeast-1

# テーブル作成確認
aws glue get-table \
  --database-name dq_test_db \
  --name orders_raw \
  --region ap-northeast-1 \
  --query 'Table.{Name:Name,Location:StorageDescriptor.Location,Columns:StorageDescriptor.Columns[*].Name}'

テーブル作成が確認できたら、§3のDQDL全ルールタイプの実装に進む。このテストテーブルを評価対象として使用することで、各ルールタイプがどのようにNULL・重複・異常値を検出するかを実機確認できる。

3. DQDL完全ガイド — 全ルールタイプとルールセット設計

3-1. DQDLの構文と基本構造

DQDLのルールセットは Rules = [...] 形式で記述する。角括弧内に1つ以上のルールをカンマ区切りで並べることでルールセットを構成する。

基本構文

Rules = [
  RuleType "column_name" 比較演算子 値,
  RuleType "column_name" 比較演算子 値
]

コメント記法
行末コメントはサポートされていない。ルールセット内にコメントを記述したい場合は、別途ドキュメント管理で対応する（公式ドキュメント参照）。

文字列リテラルのクォート規則
カラム名や文字列値はダブルクォート（"）で囲む。値リストは ["val1", "val2"] のように角括弧内にカンマ区切りで指定する。正規表現パターンも同様にダブルクォートで囲む。

制限事項
– 1つのルールセットに定義できるルール数の上限については公式ドキュメントを参照のこと。
– ルールは上から順に評価され、個別に PASS / FAIL 判定が下される。
– ルールセット全体のスコア（0.0〜1.0 の decimal 値）は PASS ルール数 / 全ルール数で算出される（×パーセント表記ではない）。

3-2. 全ルールタイプリファレンス

以下の表では、AWS Glue Data Quality が提供する全ルールタイプを網羅する。「ETL」列はGlue ETLジョブでの対応可否、「DC」列はData Catalog（データカタログ評価タスク）での対応可否を示す。

⚠️ 精度の罠⑤: Analyzers（Mean, StandardDeviation 等）および DynamicRules は ETLモードのみ対応。Data Catalogの評価タスク（DCモード）では使用不可。DCモードで記述してもエラーまたはスキップされる。

3-3. 本番ルールセット設計 — 段階的導入戦略

本番環境へのDQDL適用は段階的に行うことが推奨される。一度にすべてのルールを FAIL 閾値で設定すると、データパイプラインが過剰に停止するリスクがある。

フェーズ1: 基礎ルール（WARN運用で動作確認）

まず RowCount・Completeness・Uniqueness の3種を低閾値の WARN として設定し、実データの品質分布を把握する。

フェーズ2: 高度ルール追加（WARN → FAIL 昇格）

フェーズ1で収集した実績スコアを基に閾値を精緻化し、ReferentialIntegrity・DataFreshness・ColumnValues を追加する。基礎ルールの閾値も本番水準に引き上げて FAIL 化する。

フェーズ3: カスタムSQL・統計ルール（ETLモードのみ）

ビジネスロジック固有の検証は CustomSql で対応する。ETLジョブであれば Analyzers による統計値検証も追加できる。

WARN / FAIL 閾値の段階設定例

本番ルールセットテンプレート

Rules = [
  # ── フェーズ1: 基礎ルール ──
  RowCount > 1000,
  Completeness "order_id" >= 0.99,
  Completeness "customer_id" >= 0.95,
  Uniqueness "transaction_id" = 1.0,
  IsComplete "order_id",
  IsUnique "transaction_id",
  IsPrimaryKey "order_id",

  # ── フェーズ2: 高度ルール ──
  ColumnValues "status" in ["pending", "confirmed", "shipped", "cancelled"],
  ColumnValues "amount" >= 0,
  DataFreshness "created_at" <= 24 hours,
  ReferentialIntegrity "orders.customer_id" "customers.id" >= 0.99,
  ColumnExists "order_id",
  ColumnExists "created_at",
  ColumnCount >= 10,

  # ── フェーズ3: カスタム検証（ETLモード） ──
  CustomSql "SELECT count(*) FROM primary WHERE amount < 0" = 0,
  CustomSql "SELECT count(*) FROM primary WHERE order_id IS NULL AND status != 'draft'" = 0
]

このテンプレートをベースに、実際のスキーマ・ビジネスルールに合わせてカラム名と閾値を調整する。Analyzers や DynamicRules を使う場合は ETLモード専用タスクとして別途ルールセットを定義すること（DC評価タスクへの混在は非対応・精度の罠⑤）。

4. 推奨ルール自動生成とルールチューニング

4-1. 推奨ルール自動生成の仕組み

AWS Glue Data Qualityの推奨ルール自動生成機能は、AWSの機械学習モデルがデータプロファイリング結果を解析し、対象テーブルに統計的に適合したDQDLルールを自動で提案する機能である。手書きでルールセットをゼロから作成する手間を削減し、統計的な初期ルールセットを素早く得られることが最大の価値である。

AWSコンソールでの操作手順

1. AWSマネジメントコンソール → AWS Glue → 左メニュー「Data Quality」を選択
2. 対象データベース・テーブルを選択し、「Data quality rules」タブを開く
3. 「Recommend rules」ボタンをクリック
4. 実行に使用するIAMロールを指定し、「Start run」を実行
5. ステータスが「SUCCEEDED」になったら「View recommended rules」で結果を確認
6. 必要に応じてルールセットとして保存し、§4-3のチューニングを行う

コンソールの「Recommend rules」は内部的に StartDataQualityRuleRecommendationRun APIを呼び出し、非同期でプロファイリング→ルール推定を実行する。

CLI操作 — 推奨ルール生成の開始

# 推奨ルール生成ジョブを開始 (正式API: StartDataQualityRuleRecommendationRun)
aws glue start-data-quality-rule-recommendation-run \
  --data-source '{"GlueTable": {"DatabaseName": "sales_db", "TableName": "orders"}}' \
  --role "arn:aws:iam::123456789012:role/GlueDataQualityRole" \
  --number-of-workers 5 \
  --timeout 2880 \
  --created-ruleset-name "orders_recommended_v1"
# レスポンス: {"RunId": "dqrun-xxxxxxxxxxxxxxxxxxxx"}

主要パラメータの説明:

CLI操作 — 実行状態と結果の取得

# 実行状態の確認と推奨ルール取得 (正式API: GetDataQualityRuleRecommendationRun)
aws glue get-data-quality-rule-recommendation-run \
  --run-id "dqrun-xxxxxxxxxxxxxxxxxxxx"

レスポンスの RecommendedRuleset フィールドにDQDLフォーマットの推奨ルールが直接返される。Status が SUCCEEDED になってから結果を取得すること（取り得る値: STARTING | RUNNING | STOPPING | STOPPED | SUCCEEDED | FAILED | TIMEOUT）。

精度の罠①: 推奨ルール取得APIの正式名称は GetDataQualityRuleRecommendationRun（単数形・Run付き）。GetDataQualityRuleRecommendations という名称のAPIはAWS Glue APIリファレンスに存在しない。混同すると実装時にエラーになるため注意。

90日後自動削除の制約

精度の罠②: 推奨ルール実行結果（RunIdに紐づくデータ）は90日後に自動削除される（公式ドキュメントに明記: “Recommendation runs are automatically deleted after 90 days.”）。RunIdが失効すると GetDataQualityRuleRecommendationRun はエラーを返す。長期保存が必要な場合は RecommendedRuleset の内容をS3に書き出すか、CreatedRulesetName でルールセットとして永続化しておく必要がある。§4-3に保存スクリプト例を掲載する。

4-2. データプロファイリング結果の解釈

推奨ルール生成はデータプロファイリング結果を入力として動作する。プロファイリングで収集される統計量を理解することで、提案されるルールの根拠と適切な閾値を判断できる。

プロファイリングで収集されるカラム統計

生成されるルール例と閾値の計算根拠

プロファイリングで「order_id カラムのNULL率が0%、ユニーク値数がレコード数と一致」と検出された場合、以下のルールが提案される:

Rules = [
 Completeness "order_id" >= 1.0,
 IsPrimaryKey "order_id",
 Uniqueness "order_id" >= 0.99
]

閾値の計算根拠は「プロファイリング時の実測値 × 余裕率」である。order_id のNULL率が実測0%なら Completeness >= 1.0、ユニーク率が実測99.9%なら Uniqueness >= 0.99 が自動設定される。余裕率は統計値の安定度に応じてAWSのモデルが調整するが、チューニング時に手動で上書きする。

提案されるルールタイプのパターン

• Completeness: NULL率が低いカラム（業務キー・必須フィールド）に対して自動生成
• Uniqueness / IsPrimaryKey: ユニーク率が高いカラム（ID列・主キー候補）に対して生成
• ColumnValues（IN句）: 値域が限定される列挙型カラム（ステータスコード・区分値）に対して生成
• ColumnDataType: 数値・日付型カラムの型整合性チェックとして生成
• Mean / StandardDeviation: 数値カラムの統計的範囲チェックとして生成

4-3. ルールチューニング

推奨ルールはデータの現状を基準にした初期提案であり、そのまま本番適用すると変動の許容範囲がなく誤検知が発生しやすい。実データ統計にバッファ率を加えたチューニングが品質ゲートの信頼性を左右する。

閾値最適化のアプローチ

基本方針は「実データ統計 ± バッファ率(5〜10%)」で閾値を設定することである。

優先度付け: FAIL vs WARN の使い分け

業務への影響度でルールをFAIL（パイプラインブロック）とWARN（通知のみ）に分類する:

• FAIL（業務クリティカル）: 主キー欠損・NULL禁止フィールドの欠損・参照整合性違反。データを下流に渡すと業務損害が生じるもの
• WARN（補助指標）: 平均値の軽微な変動・補助フィールドの欠損・将来追加予定の項目。モニタリング目的で記録するが処理は継続する

段階ロールアウト: WARN → FAIL の2段階移行

新規ルールを即FAIL設定すると予期しない品質違反でパイプラインが停止するリスクがある。段階移行で安全に本番適用する:

• 第1段階（警告期間: 2〜4週間）: 全ルールをWARN閾値で設定。CloudWatch/EventBridgeで違反をモニタリングし、誤検知を洗い出す
• 第2段階（本番適用）: 誤検知ゼロを確認した業務クリティカルルールのみFAIL閾値に昇格させ、補助指標はWARNのまま継続

チューニング後のDQDLルールセット実装例

Rules = [
 # 業務クリティカル: FAIL設定（パイプラインをブロック）
 Completeness "order_id" >= 1.0,
 IsPrimaryKey "order_id",
 Completeness "customer_id" >= 1.0,
 ReferentialIntegrity "customer_id" "customers.customer_id" >= 0.99,
 Completeness "order_date" >= 1.0,
 ColumnDataType "order_date" = "DATE",
 ColumnValues "status" in ["PENDING", "SHIPPED", "DELIVERED", "CANCELLED"],
 ColumnValues "order_amount" > 0,

 # 補助指標: WARN設定（段階ロールアウト — 誤検知確認後にFAIL昇格）
 Completeness "shipping_address" >= 0.85,
 Mean "order_amount" between 3000 and 80000,
 Uniqueness "order_id" >= 0.995
]

長期運用: 推奨ルール結果の定期保存 (90日制限対策)

推奨ルール実行結果は90日で自動削除されるため、RunIdを長期保管するだけでは不十分である。以下のスクリプトで RecommendedRuleset の内容をS3に定期保存し、将来のルール見直し時の根拠データとして活用する:

#!/bin/bash
# 推奨ルール結果をS3にバックアップ (90日自動削除対策)
RUN_ID="dqrun-xxxxxxxxxxxxxxxxxxxx"
S3_BUCKET="s3://my-data-quality-archive"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

RESULT=$(aws glue get-data-quality-rule-recommendation-run \
  --run-id "${RUN_ID}" \
  --output json)

echo "${RESULT}" | python3 -c \
  "import sys, json; print(json.load(sys.stdin).get('RecommendedRuleset', ''))" \
  > /tmp/recommended_rules_${TIMESTAMP}.dqdl

aws s3 cp /tmp/recommended_rules_${TIMESTAMP}.dqdl \
  "${S3_BUCKET}/recommended-rules/${RUN_ID}_${TIMESTAMP}.dqdl"

echo "Saved to ${S3_BUCKET}/recommended-rules/${RUN_ID}_${TIMESTAMP}.dqdl"

このスクリプトをEventBridgeスケジュール（月次等）またはStep Functionsのタスクとして呼び出すことで、推奨ルールの履歴管理と将来のルール再チューニング根拠として活用できる。CreatedRulesetName でルールセット保存した場合も、S3への二重バックアップを推奨する（ルールセット削除時の消失リスク対策）。

5. 2モード本番実装 — ETL組込み vs Data Catalog評価

5-1. ETL組込みモードの仕組みと実装

ETL組込みモードは、Glueジョブのデータ変換パイプライン内にData Quality評価を直接埋め込む方式だ。EvaluateDataQuality変換ステップがETLジョブ実行中にリアルタイムでルールを評価し、その結果に応じてジョブの継続・停止を制御できる。変換後のデータに対してインラインで品質ゲートを設けられるため、不良データを後続の書き込み処理や下流ジョブに流さない設計が実現できる。

EvaluateDataQuality と EvaluateDataQualityMultiFrame の違い

EvaluateDataQualityMultiFrameは複数のGlue DynamicFrameを入力として受け取り、クロステーブルの整合性チェックやJOIN後のデータ品質評価が可能だ。トランザクションテーブルとマスターテーブルを結合した後の参照整合性を一括評価するケースなどで活用できる。

結果出力先の設定

ETL組込みモードの評価結果は2か所に出力される。

1. S3（詳細ログ）: 各ルールのPASS/FAIL判定・スコア・対象レコード数を含む詳細JSONがS3バケットに保存される。Athenaでの事後分析に活用できる。
2. CloudWatch Metrics（スコア）: glue.data.quality.rules.passed / glue.data.quality.rules.failedメトリクスが送出される。アラーム設定で閾値超過時のSNS通知が可能だ。

どちらの出力もpublishing_optionsのenableDataQualityResultsPublishingおよびenableDataQualityCloudWatchMetricsフラグで明示的に有効化する必要がある。デフォルトはどちらも無効のため注意されたい。

ETL組込みモード実装例（Glue ETL Pythonスクリプト）

以下はGlue ETLジョブ（Glue Studioスクリプトモード）でのData Quality変換ステップの実装例だ。

import sys
from awsglue.transforms import EvaluateDataQuality, SelectFromCollection
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ["JOB_NAME"])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args["JOB_NAME"], args)

# ソースデータ読み込み
source_df = glueContext.create_dynamic_frame.from_catalog(
 database="sales_db",
 table_name="orders",
 transformation_ctx="source_df"
)

# DQDLルールセット定義
ruleset = """
 Rules = [
  IsComplete "order_id",
  IsComplete "customer_id",
  ColumnValues "amount" > 0,
  ColumnValues "status" in ["pending", "completed", "cancelled"],
  IsPrimaryKey "order_id"
 ]
 Analyzers = [
  RowCount,
  Completeness "customer_id"
 ]
"""

# EvaluateDataQuality 変換ステップ（S3 + CloudWatch 両方に出力）
dq_results = EvaluateDataQuality().process_rows(
 frame=source_df,
 ruleset=ruleset,
 publishing_options={
  "dataQualityEvaluationContext": "orders_quality_check",
  "enableDataQualityResultsPublishing": True,
  "resultsS3Prefix": "s3://my-datalake/dq-results/orders/",
  "enableDataQualityCloudWatchMetrics": True,
 },
 additional_options={"performanceTuning.caching": "CACHE_NOTHING"},
)

# ルール評価結果を取得（ruleOutcomes / rowLevelOutcomes の2種）
rule_outcomes = SelectFromCollection.apply(
 dfc=dq_results,
 key="ruleOutcomes",
 transformation_ctx="rule_outcomes"
)

# 品質ゲート: FAILルールがあればジョブを強制停止
failed_rules = rule_outcomes.toDF().filter("Outcome = 'Failed'")
if failed_rules.count() > 0:
 raise Exception(
  f"Data quality gate failed: {failed_rules.count()} rule(s) did not pass. "
  "Check S3 results and CloudWatch metrics for details."
 )

# 品質通過後の書き込み処理
glueContext.write_dynamic_frame.from_options(
 frame=source_df,
 connection_type="s3",
 connection_options={"path": "s3://my-datalake/cleaned/orders/"},
 format="parquet",
 transformation_ctx="sink"
)

job.commit()

5-2. Data Catalog評価モードの仕組みと実装

Data Catalog評価モードは、ETLジョブとは独立してGlueカタログに登録済みのテーブルを直接評価する方式だ。ETLパイプラインを持たない既存のS3テーブルや外部データソースへの定期品質チェックに適している。評価はスタンドアローンのジョブとして実行されるため、ETLジョブのスケジュールに縛られることなく品質チェックのみを独立して運用できる。

コンソールでの評価設定手順

1. AWSコンソール → AWS Glue → Data Quality → ルールセット選択
2. 「アクション」→「評価の実行」をクリック
3. 実行対象として対象データベース・テーブルを指定（Data Catalogに登録済みのもの）
4. IAMロール・ワーカータイプ・ワーカー数を設定
5. 「スケジュール追加」でCron式を入力（定期実行の場合）

CLIでの評価実行

aws glue start-data-quality-ruleset-evaluation-runコマンドでの実行パラメータは以下の通りだ。

aws glue start-data-quality-ruleset-evaluation-run \
  --data-source '{
 "GlueTable": {
"DatabaseName": "sales_db",
"TableName": "orders"
 }
  }' \
  --role "arn:aws:iam::123456789012:role/GlueDataQualityRole" \
  --ruleset-names '["orders_catalog_ruleset"]' \
  --number-of-workers 5 \
  --worker-type "G.1X" \
  --region ap-northeast-1

実行IDを取得したらaws glue get-data-quality-ruleset-evaluation-runでステータスを確認する。

aws glue get-data-quality-ruleset-evaluation-run \
  --run-id "dqrun-xxxxxxxxxxxxxxxxxxxx"

レスポンスのStatusフィールドがSUCCEEDEDになれば評価完了だ。ResultIdsに含まれるIDを使ってget-data-quality-resultで詳細スコアを取得できる。

スケジュール実行設定（EventBridge Scheduler）

定期実行にはEventBridge Schedulerを使用するのが推奨だ。Glue Data QualityのコンソールからSchedulerを直接設定することもできるが、CLIでの設定例を示す。

aws scheduler create-schedule \
  --name "orders-daily-dq-catalog-check" \
  --schedule-expression "cron(0 3 * * ? *)" \
  --flexible-time-window '{"Mode": "FLEXIBLE", "MaximumWindowInMinutes": 30}' \
  --target '{
 "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:TriggerGlueDQEvaluation",
 "RoleArn": "arn:aws:iam::123456789012:role/SchedulerInvokeLambdaRole",
 "Input": "{\"databaseName\": \"sales_db\", \"tableName\": \"orders\", \"rulesetName\": \"orders_catalog_ruleset\"}"
  }'

Lambda関数内でstart-data-quality-ruleset-evaluation-runを呼び出す構成が一般的だ。Lambda経由にすることで、評価完了後のSNS通知や結果の自動判定ロジックを組み込める。

Data Catalogモードの制約

5-3. モード選択基準と使い分け

2つのモードの選択はユースケースによって明確に分かれる。以下の比較表を判断の基準として使用されたい。

ユースケース別の選択基準:

• ETLパイプラインの品質ゲート（不良データを後続処理に流さない）→ ETL組込みモード一択
• AnalyzersまたはDynamicRulesを使いたい→ ETL組込みモード必須（Data Catalogモード非対応）
• 既存S3テーブルの定期品質チェック（ETLジョブを持たないデータ）→ Data Catalog評価モード
• 複数テーブル間の整合性チェック→ ETL組込みモード（EvaluateDataQualityMultiFrame）
• コスト最適化（ETLジョブがなく品質チェックのみ実行したい）→ Data Catalog評価モードで評価ジョブのみ独立実行

6. 品質スコアの継続モニタリング

6-1. EventBridgeイベント連携

Glue Data Qualityはルールセット評価完了後にAmazon EventBridgeへイベントを自動Publishする。このイベントを捕捉することで、品質スコアのPASS/FAIL情報をリアルタイムで下流システムへ伝搬できる。

必須前提条件: “Publish metrics to CloudWatch”オプションの有効確認

PublishingOptions = {
 "EvaluationContext": "PRIMARY",
 "ResultsS3Prefix": "s3://my-bucket/dq-results/",
 "CloudWatchMetricsEnabled": True,# これが有効でないとEventBridgeイベントが発火しない
 "ResultsPublishingEnabled": True
}

EventBridgeイベントの正式名称とスキーマ

Glue Data Qualityがパブリッシュするイベントの正式名称は “Glue Data Quality Evaluation Results Available” である。このイベントはデフォルトイベントバス（default）に配信される。

イベントの基本属性:

detailオブジェクトの主要フィールド:

ルールごとのPASS/FAIL情報取得: GetDataQualityResult API連携

EventBridgeイベントのdetail.resultIdsを使ってGetDataQualityResult APIを呼び出すことで、ルールごとの詳細PASS/FAIL情報を取得できる:

import boto3

glue_client = boto3.client('glue', region_name='ap-northeast-1')

def get_rule_level_results(result_id: str) -> dict:
 response = glue_client.get_data_quality_result(ResultId=result_id)
 rule_results = response.get('RuleResults', [])
 return {
  'score': response.get('Score', 0.0),
  'rules': [
{
 'name': r.get('Name'),
 'result': r.get('Result'), # 'PASS' or 'FAIL'
 'description': r.get('Description'),
 'evaluationMessage': r.get('EvaluationMessage')
}
for r in rule_results
  ]
 }

EventBridge Ruleの設定手順（コンソール）:

1. [Amazon EventBridge] → [ルール] → [ルールを作成]
2. イベントソース: AWS のイベントまたはEventBridgeパートナーのイベント
3. イベントパターン（JSON）— 品質評価FAILED時のみ発火する設定:

{
  "source": ["aws.glue"],
  "detail-type": ["Glue Data Quality Evaluation Results Available"],
  "detail": {
 "state": ["FAILED"]
  }
}

1. ターゲット: Lambda関数（インシデント処理）またはSNSトピック（即時通知）を指定

上記パターンはFAILED（1件以上のルールFAIL）の場合のみ発火する。すべての評価結果を受信したい場合は"state"フィルタを省略する。CLIでのルール登録はaws events put-rule --event-patternコマンドで行い、aws events put-targetsでターゲットを紐付ける。

6-2. CloudWatchメトリクスとアラーム設定

正式メトリクス名（精度の罠③）

Glue Data QualityがCloudWatchへ送出するメトリクスの正式名称は以下の2つである:

これらはルール数を示す指標であり、品質スコア（0.0〜1.0のdecimal値）そのものとは別の指標である点を必ず理解したうえで運用すること（精度の罠③）。品質スコアは評価結果JSONとEventBridgeイベントdetail.scoreフィールドから取得する。

メトリクスのディメンション:

品質スコアをCloudWatchグラフで確認する際の注意点（精度の罠④）:

品質スコアは0.0〜1.0のdecimal値として送出される。CloudWatchグラフで可視化する際は以下に注意する:
– Y軸の範囲を0.0〜1.0に固定設定する（自動スケールではrules.passedルール数と混在して判読不能になる）
– glue.data.quality.rules.passed / glue.data.quality.rules.failedのルール数グラフとは別ウィジェットにスコアを配置することを推奨

ルールFAIL件数アラームの設定（CLIコマンド）:

aws cloudwatch put-metric-alarm \
  --alarm-name "GlueDataQuality-RulesFailed-Alert" \
  --alarm-description "Glue Data Qualityでルール失敗が1件以上発生" \
  --namespace "Glue" \
  --metric-name "glue.data.quality.rules.failed" \
  --dimensions "Name=DataSource,Value=sales_db.daily_sales" \
"Name=RulesetName,Value=sales-quality-ruleset" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:data-quality-alerts" \
  --treat-missing-data notBreaching

SNS通知連携 — AlarmAction設定:

# SNSトピック作成
aws sns create-topic --name data-quality-alerts --region ap-northeast-1

# メール通知サブスクリプション追加
aws sns subscribe \
  --topic-arn "arn:aws:sns:ap-northeast-1:123456789012:data-quality-alerts" \
  --protocol email \
  --notification-endpoint "data-team@example.com"

# サブスクリプション確認メールの承認後、アラームからのSNS送信が有効化される

品質SLA閾値アラームの設定例（スコアベース）:

# Lambda経由でカスタムメトリクスとして品質スコアをPutする場合のアラーム設定例
aws cloudwatch put-metric-alarm \
  --alarm-name "GlueDataQuality-Score-SLA-Breach" \
  --alarm-description "品質スコアがSLA閾値(0.95)を下回りました" \
  --namespace "GlueDataQuality/Custom" \
  --metric-name "QualityScore" \
  --dimensions "Name=DataSource,Value=sales_db.daily_sales" \
  --statistic Average \
  --period 300 \
  --threshold 0.95 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:data-quality-alerts" \
  --treat-missing-data notBreaching

CloudWatchダッシュボードには「ルール数ウィジェット（rules.passed/failed）」と「スコアウィジェット（カスタムメトリクス）」を分けて配置し、品質の多角的な可視化を実現する。

6-3. 異常検知とインシデント対応フロー

CloudWatch Anomaly Detectionは過去のメトリクスデータから機械学習モデルを構築し、統計的な正常範囲（バンド）を動的に定義する。品質スコアに日次・週次のサイクル変動がある場合、静的閾値より高精度で真の異常を検知できる。

静的閾値 vs CloudWatch Anomaly Detection の比較:

Anomaly Detection型アラームのCLI設定:

# Anomaly Detection用モデル作成（2週間以上のデータ蓄積後に実行推奨）
aws cloudwatch put-anomaly-detector \
  --namespace "Glue" \
  --metric-name "glue.data.quality.rules.failed" \
  --dimensions "Name=DataSource,Value=sales_db.daily_sales" \
  --stat Sum

# Anomaly Detection型アラームの作成
aws cloudwatch put-metric-alarm \
  --alarm-name "GlueDataQuality-AnomalyDetection" \
  --alarm-description "Glue Data Quality異常値検知（動的閾値）" \
  --metrics '[
 {"Id":"q1","Expression":"ANOMALY_DETECTION_BAND(m1,2)","Label":"AnomalyBand"},
 {"Id":"m1","MetricStat":{"Metric":{"Namespace":"Glue","MetricName":"glue.data.quality.rules.failed","Dimensions":[{"Name":"DataSource","Value":"sales_db.daily_sales"}]},"Period":300,"Stat":"Sum"}}
  ]' \
  --comparison-operator GreaterThanUpperThreshold \
  --threshold-metric-id q1 \
  --evaluation-periods 1 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:data-quality-alerts"

品質スコア急落検知フロー:

① EventBridge受信 (Glue Data Quality Evaluation Results Available)
 ↓ detail.state == "FAILED" または detail.score < 0.9
② Lambdaトリガー: GetDataQualityResult → FAILルール特定
 ↓
③ Slack通知 (担当チャンネル) + 夜間はPagerDuty/OpsGenie
 ↓
④ 担当者確認: どのルールがFAILか・上流データ変更有無
 ↓ 原因確定
⑤ 対応分岐:
A) 上流データ問題 → ETL一時停止 → データ修正 → 再実行
B) 閾値設定問題  → DQDLルール閾値見直し → 再評価
 ↓
⑥ 品質スコア改善確認 → インシデントクローズ → S3ログ記録

Lambda経由Slack通知の実装例:

import boto3
import urllib.request
import json

SLACK_WEBHOOK = "https://hooks.slack.com/services/T000/B000/XXXX"

def lambda_handler(event, context):
 detail = event.get('detail', {})
 score = detail.get('score', 'N/A')
 state = detail.get('state', 'UNKNOWN')
 result_ids = detail.get('resultIds', [])

 glue = boto3.client('glue')
 failed_rules = []
 for rid in result_ids:
  result = glue.get_data_quality_result(ResultId=rid)
  for rule in result.get('RuleResults', []):
if rule.get('Result') == 'FAIL':
 failed_rules.append(f"{rule.get('Name')}: {rule.get('EvaluationMessage', '')}")

 message = {
  "text": (
f":warning: *Glue Data Quality Alert*\n"
f"*State:* {state} | *Score:* {score}\n"
f"*Failed Rules ({len(failed_rules)}件):*\n"
+ "\n".join(f"  • {r}" for r in failed_rules)
  )
 }
 req = urllib.request.Request(
  SLACK_WEBHOOK,
  data=json.dumps(message).encode(),
  headers={"Content-Type": "application/json"}
 )
 urllib.request.urlopen(req)
 return {"status": "notified", "failed_rule_count": len(failed_rules)}

インシデントログのS3保存:

インシデントログをS3に蓄積することで、長期的なパターン分析（特定ルールの再発傾向・季節性）や監査対応が可能になる。Lambdaハンドラ末尾に以下を追加する:

import boto3
import json
from datetime import datetime, timezone

s3 = boto3.client('s3')
INCIDENT_BUCKET = "my-data-quality-incidents"

def save_incident_log(event_detail: dict, failed_rules: list):
 now = datetime.now(timezone.utc)
 incident = {
  "timestamp": now.isoformat(),
  "event_detail": event_detail,
  "failed_rules": failed_rules,
  "resolution": "pending"
 }
 key = f"incidents/{now.strftime('%Y/%m/%d/%H%M%S')}.json"
 s3.put_object(
  Bucket=INCIDENT_BUCKET,
  Key=key,
  Body=json.dumps(incident, ensure_ascii=False),
  ContentType="application/json"
 )

S3に蓄積したインシデントログはAthenaでクエリ可能であり、§7-1で設計するトレンド可視化ダッシュボードと統合することで、品質ガバナンスの全体像を一元管理できる。

7. 品質トレンド可視化とデータ品質駆動ガバナンス

7-1. 品質スコアのS3蓄積とAthena可視化

Data Quality評価結果はS3へ自動出力される。この出力先を統一されたS3パスに集約し、Athenaで外部テーブルとして定義することで、品質スコアの時系列分析が可能になる。

S3出力パスの設定:

ETL組込みモードではPublishingOptions.ResultsS3Prefixで出力先を指定する。複数ジョブの結果を集約するために、パスを以下の構造に統一することを推奨する:

s3://my-data-quality-bucket/
  results/
 year=2026/month=06/day=28/
dqrun-abc123.json
dqrun-def456.json

評価結果JSONのスキーマ説明:

{
  "evaluationContext": "PRIMARY",
  "score": 0.923,
  "rulesetEvaluationRunId": "dqrun-abc123",
  "startedOn": "2026-06-28T10:00:00Z",
  "completedOn": "2026-06-28T10:05:00Z",
  "dataSource": {
 "glueTable": {
"databaseName": "sales_db",
"tableName": "daily_sales"
 }
  },
  "rulesetName": "sales-quality-ruleset",
  "ruleResults": [
 {
"name": "Rule_1",
"description": "Completeness \"customer_id\" >= 0.99",
"result": "PASS",
"evaluationMessage": "Completeness check passed with value 0.997"
 },
 {
"name": "Rule_2",
"description": "Uniqueness \"order_id\" >= 0.999",
"result": "FAIL",
"evaluationMessage": "Uniqueness check failed with value 0.985"
 }
  ]
}

Athena外部テーブルDDL（評価結果JSONに対するEXTERNAL TABLE定義）:

CREATE EXTERNAL TABLE data_quality_results (
  evaluationContextSTRING,
  scoreDOUBLE,
  rulesetEvaluationRunId STRING,
  startedOn  STRING,
  completedOnSTRING,
  dataSource STRUCT<
 glueTable: STRUCT<
databaseName: STRING,
tableName: STRING
 >
  >,
  rulesetNameSTRING,
  ruleResultsARRAY<
 STRUCT<
name: STRING,
description: STRING,
result: STRING,
evaluationMessage: STRING
 >
  >
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES ('serialization.format' = '1')
LOCATION 's3://my-data-quality-bucket/results/'
TBLPROPERTIES ('has_encrypted_data'='false');

サンプルAthenaクエリ — 週次品質劣化ワーストTOP5:

SELECT
  dataSource.glueTable.databaseName || '.' ||
 dataSource.glueTable.tableName AS table_name,
  rulesetName,
  DATE_FORMAT(
 CAST(FROM_ISO8601_TIMESTAMP(completedOn) AS DATE),
 '%Y-W%v'
  ) AS week,
  ROUND(AVG(score), 4)  AS avg_score,
  MIN(score)AS min_score,
  COUNT(*)  AS eval_count
FROM data_quality_results
WHERE score < 0.95
  AND completedOn >= DATE_FORMAT(
  DATE_ADD('week', -4, CURRENT_DATE),
  '%Y-%m-%dT00:00:00Z'
)
GROUP BY 1, 2, 3
ORDER BY avg_score ASC
LIMIT 5;

QuickSightダッシュボード構成:

品質モニタリングダッシュボードは以下3ウィジェットで構成することを推奨する:

QuickSightからAthenaへの接続はデータソース設定で「Amazon Athena」を選択し、対象データベース・テーブルを指定するだけでデータセット作成が完了する。リアルタイム性が必要な場合はSPICEではなくDirect Queryモードを選択し、Athenaクエリコストと更新頻度のバランスを考慮して運用設計を行う。

7-2. 品質SLAとビジネス指標の連動

部門・データドメイン別のSLA定義テンプレート:

SLAはドメイン責任者（データオーナー）と合意のうえで設定し、YAMLやTerraformで管理してGitでバージョン管理することを推奨する。

品質スコアとデータ使用可否判定の3段階ルール:

Glue Data Qualityの品質スコア（0.0〜1.0）に基づく使用可否判定を以下のように定義する:

下流分析ジョブの品質ゲート実装（Lambda）:

import boto3

glue_client = boto3.client('glue', region_name='ap-northeast-1')
sfn_client = boto3.client('stepfunctions', region_name='ap-northeast-1')

QUALITY_GATE_THRESHOLD = 0.95
DOWNSTREAM_STATE_MACHINE_ARN = (
 "arn:aws:states:ap-northeast-1:123456789012:stateMachine:DownstreamETL"
)

def lambda_handler(event, context):
 ruleset_name = event['rulesetName']

 # 最新の評価結果を取得
 runs = glue_client.list_data_quality_results(
  Filter={'RulesetName': ruleset_name},
  MaxResults=1
 )
 if not runs.get('Results'):
  raise ValueError(f"No quality results found for: {ruleset_name}")

 latest_score = runs['Results'][0].get('Score', 0.0)

 if latest_score >= QUALITY_GATE_THRESHOLD:
  # 品質ゲートPASS → 下流ジョブ起動
  sfn_client.start_execution(
stateMachineArn=DOWNSTREAM_STATE_MACHINE_ARN,
input=f'{{"source":"quality_gate","score":{latest_score}}}'
  )
  return {"status": "LAUNCHED", "score": latest_score}
 else:
  raise Exception(
f"Quality gate FAILED: score={latest_score} < threshold={QUALITY_GATE_THRESHOLD}"
  )

Step Functionsによる品質ゲート統合（ステートマシン定義の骨格）:

{
  "StartAt": "CheckDataQuality",
  "States": {
 "CheckDataQuality": {
"Type": "Task",
"Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:QualityGateChecker",
"Next": "LaunchDownstreamETL",
"Catch": [{
  "ErrorEquals": ["QualityGateFailed"],
  "Next": "NotifyFailure"
}]
 },
 "LaunchDownstreamETL": {
"Type": "Task",
"Resource": "arn:aws:states:::glue:startJobRun",
"Parameters": {"JobName": "downstream-analytics-etl"},
"End": true
 },
 "NotifyFailure": {
"Type": "Task",
"Resource": "arn:aws:states:::sns:publish",
"Parameters": {
  "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:data-quality-alerts",
  "Message": "品質ゲートFAIL: 下流ETLを停止しました"
},
"End": true
 }
  }
}

Step Functionsを利用することで、品質ゲート確認・条件分岐・通知を宣言的なワークフローとして管理でき、コードの複雑化を防ぐことができる。

7-3. データ品質駆動ガバナンスサイクル

品質スコアの継続改善には、計測→検知→分析→改善→再評価のPDCAサイクルを実装する。このサイクルを自動化することで、品質劣化を早期発見してデータ信頼性を継続的に向上させられる。

PDCAサイクルの実装フロー:

① 品質スコア計測 (Plan)
Glue Data Quality評価実行 → S3出力 + CloudWatchメトリクス送出

② 閾値違反検知 (Do)
CloudWatchアラーム発火 → EventBridge → Lambdaトリガー
GetDataQualityResult APIでFAILルール特定

③ 原因分析 (Check)
FAILルールのevaluationMessageを確認
例: "Completeness check failed with value 0.85, expected >= 0.99"
パターンA: 上流データ品質問題（NULLデータ増加・スキーマ変更等）
パターンB: DQDLルール閾値が実データ統計と乖離している

④ DQDLルール改善または上流修正 (Act)
パターンA → データエンジニアに上流修正依頼・ETL一時停止
パターンB → 閾値を実データ統計ベースに再設定
改善後はルールセットをGit管理してバージョン記録を残す

⑤ 再評価・スコア確認
Glue Data Quality再実行 → スコア改善を確認
改善不足の場合はステップ③に戻る

⑥ ルールセット確定・承認フロー
承認済みルールセットをTerraform/CloudFormationでコード化
本番環境への反映はPull Request + レビュー経由で実施

Before/Afterルールセット比較（閾値最適化の実例）:

品質改善の成功パターンとして、閾値を実データ統計から算出する例を示す。

Before（初期設定 — 過度に厳格な閾値でFAIL多発）:

Rules = [
 Completeness "email" >= 0.99,
 Uniqueness "user_id" >= 0.999
]

評価結果: Completeness "email" FAILが毎日発生（実際の完全率は0.94前後）

After（実データ統計に基づく現実的な閾値）:

Rules = [
 Completeness "email" >= 0.92,
 Uniqueness "user_id" >= 0.999,
 ColumnValues "email" matches "^[a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,}$" >= 0.85
]

評価結果: 実際の問題（形式不正メール）のみ検知し、NULL許容フィールドでの誤アラートが解消。閾値0.92はデータサンプリング調査の結果（完全率平均0.94 – 2σ ≈ 0.92）から算出した。

データリネージの補足的活用:

品質スコアが急落した際の原因追跡において、データリネージ（AWS Glue Data Catalog の依存グラフ・Amazon DataZone のリネージビュー）は補助ツールとして有用である。上流テーブルとの依存関係を確認し、「どのETLジョブが品質劣化を持ち込んだか」を特定する際の参考情報として活用できる。ただし本Vol3ではリネージを主軸にはせず、あくまでDQDLルールのFAIL分析が品質ガバナンスの中心軸である。

品質改善指標のKPIトラッキング:

PDCA効果を定量評価するために、以下の指標を週次でAthenaクエリして記録することを推奨する:

これらのKPIを経営層向けダッシュボード（QuickSight）に組み込むことで、データ品質への投資対効果（ROI）を可視化し、ガバナンス施策への継続的なリソース確保につなげられる。§7-1のAthena外部テーブルとKPIクエリを組み合わせることで、品質スコアの長期トレンドと改善速度の両方を一元管理できる。

8. まとめ・DQコストと Vol1/Vol2 双方向クロスリンク

8-1. Vol3 実装チェックリスト

Vol3で解説した本番実装を確実に展開するためのチェックリストです。全項目を確認してから本番運用を開始してください。

IAM・権限設定

• [ ] IAM権限 glue:StartDataQualityRulesetEvaluationRun、glue:GetDataQualityResult、glue:BatchGetDataQualityResult をGlue実行ロールに付与済み
• [ ] 推奨ルール生成権限 glue:StartDataQualityRuleRecommendationRun、glue:GetDataQualityRuleRecommendationRun を付与済み
• [ ] CloudWatchメトリクス書き込み権限 cloudwatch:PutMetricData をGlue実行ロールに付与済み
• [ ] S3評価結果出力バケット書き込み権限 s3:PutObject を付与済み

DQDLルールセット設計

• [ ] DQDLルールセット作成完了（Completeness / Uniqueness / ColumnValues / ColumnLength 等の本番ルールを含む）
• [ ] 推奨ルール自動生成（StartDataQualityRuleRecommendationRun）を実行し、生成ルールの統計値を確認済み
• [ ] 生成ルールの閾値チューニング（±10〜20%バッファ追加）と不要ルール削除済み
• [ ] ETL組込みモード または Data Catalog評価モード の適切なモードを選択済み

モニタリング設定

• [ ] "Publish metrics to CloudWatch" オプションを有効化済み（EventBridgeイベント発火の前提条件）
• [ ] EventBridge Rule: "Glue Data Quality Evaluation Results Available" イベントの受信ルール設定済み
• [ ] CloudWatchアラーム: glue.data.quality.rules.failed メトリクスの閾値アラーム設定済み
• [ ] SNS通知連携確認済み（アラーム → SNS → 担当者通知）

結果の可視化・分析

• [ ] S3評価結果出力先バケット・パスを設定し、評価結果JSONの出力確認済み
• [ ] Athenaテーブル作成・評価結果クエリ確認済み（品質スコアの時系列集計）
• [ ] QuickSightダッシュボード設定済み（データセット接続・KPIビジュアル作成）

運用体制

• [ ] 品質SLA閾値（例: スコア0.9以上）定義済み
• [ ] インシデント対応手順（品質ゲート停止 → 原因分析 → 修正 → 再評価フロー）整備済み
• [ ] 推奨ルール実行結果90日自動削除対策（実行結果をS3またはDynamoDBに保存するスクリプト）設定済み
• [ ] Vol1/Vol2との双方向クロスリンク設置確認済み

8-2. Glue Data Quality コスト試算

Glue Data Qualityの料金はGlue ETLと同様に DPU時間（Data Processing Unit-Hour） ベースで課金されます。

料金体系の基本

月額コスト試算例（テーブル10件×1日1回評価）

前提条件:
– 評価対象テーブル: 10件
– 評価実行時間: 1回あたり平均5分（最低10分単位切り上げ）
– DPU数: 2 DPU（最小構成）
– 評価頻度: 1日1回（月30日稼働）

計算式:

月間評価回数 = 10テーブル × 30日 = 300回
DPU-hour  = 300回 × (10分 ÷ 60分) × 2 DPU = 100 DPU-hour
評価コスト= 100 DPU-hour × $0.44 = $44/月

推奨ルール生成コスト（月1回の場合）:
– プロファイリング＋ルール生成: 平均20分 × 2 DPU × 10テーブル = 66.7 DPU-hour
– コスト: 66.7 × $0.44 ≈ $29（毎月定期実行する場合）
– 初回のみ or 大幅なデータ変化時のみの実行に限定するとコスト削減効果が大きい

月額合計（概算）:

コスト最適化ポイント

1. 評価頻度の最適化: 重要テーブルは毎日評価、低重要テーブルは週次評価に変更するだけで50%以上削減可能
2. 対象テーブルの優先順位付け: 下流への影響が大きいマスタデータ・KPIテーブルを最優先に選定し、全テーブル一律評価は避ける
3. サンプリング活用: 大規模テーブルはサンプリング（例: 1,000万件中100万件）で評価精度を維持しながら実行時間を短縮
4. 推奨ルール生成の頻度制御: 月1回または四半期1回に限定し、定常評価とコスト管理を分離する

最新の料金は AWS Glue 料金ページ で確認してください。DPU単価・最低課金時間は変更される場合があります。

8-3. シリーズまとめ — 3巻で完成するデータガバナンス体制

Vol1からVol3にかけて、AWSデータガバナンスの三層を段階的に積み上げてきました。

Vol1（カタログ・統制基盤）: DataZone によるデータポータルとビジネスデータカタログ、Lake Formation による統制基盤、Clean Rooms による安全なデータコラボレーションを確立しました。データを「見つけられる・管理できる」状態の実現が第一の柱です。

Vol2（きめ細かいアクセス制御）: LF-Tag ベースの属性型アクセス制御、行・セルレベルのきめ細かいフィルタリング、データメッシュアーキテクチャ、Macie による機密データ自動検出を実装しました。データを「適切な人だけが・適切な粒度で」利用できる体制が第二の柱です。

Vol3（品質保証・モニタリング）: DQDL によるルールセット定義、推奨ルール自動生成、ETL組込み/Data Catalog評価の2モード選択、EventBridge/CloudWatch連携による品質スコア継続モニタリングと品質ゲート実装を完成させました。データを「信頼できる品質で」提供するサイクルの確立が第三の柱です。

3巻を通じて「発見性（Vol1）→ アクセス制御（Vol2）→ 品質保証（Vol3）」の層を順に積み上げることで、本番データレイクに必要な完全なガバナンス体制が完成します。Vol1の統制基盤の上にVol2のアクセス制御が成り立ち、その上でVol3の品質保証サイクルが継続的に機能するという三層構造が、AWS データガバナンスの設計原則です。品質スコアの劣化検知 → 原因分析 → DQDLルール改善 → 再評価のPDCAサイクルを継続することで、データ基盤全体の信頼性を長期的に維持できます。

8-4. 次のステップ

Vol3でAWS Glue Data Quality を中心とした品質保証レイヤを構築しましたが、データ品質管理のエコシステムはさらに広がりを持っています。

他のデータ品質ツールとの比較・補完

• Amazon Deequ: Apache Spark ベースのオープンソースデータ品質ライブラリで、AWS Glue ETL ジョブ内から直接呼び出せます。DQDL で表現しにくい複雑なカスタム検証ロジックを Scala/Python で記述したい場合の補完ツールとして有効です。

• Great Expectations: Python エコシステムで広く使われる汎用データ品質フレームワークです。AWS 外のデータソースやマルチクラウド環境との品質管理統合が必要な場合の選択肢になります。

• AWS Glue Data Quality の位置づけ: IAM / CloudWatch / EventBridge / Lake Formation との統合が最もシンプルで、AWS 中心のデータ基盤では第一選択です。マネージドサービスとして運用コストが低い点も本番環境での優位点です。

データカタログとの統合強化

Vol1で構築した DataZone データカタログに品質スコアを連携することで、データポータル上でデータの鮮度・品質状態をコンシューマが直接確認できる体制を構築できます。AWS Glue Data Quality の評価結果を Glue Data Catalog のテーブルメタデータとして記録し、DataZone のビジネスカタログに反映するアーキテクチャが推奨される次の拡張です。

品質駆動のデータメッシュ高度化

Vol2で構築したデータメッシュアーキテクチャとVol3の品質評価を組み合わせることで、ドメインごとの品質SLAを自動で検証し、品質基準を満たさないデータプロダクトをメッシュから切り離す自律型ガバナンスの実現が可能になります。各ドメインの Data Product オーナーが品質ルールを自律管理しながら、中央の統制基盤がSLAコンプライアンスを自動監視する体制が次の進化形です。