[アップデート] AWS Glue Data Quality の新しい FIXED モードによる異常検知を試してみました

クラウド事業統括本部の石川です。AWS Glue Data Quality の ETL ジョブにおける異常検知(Anomaly Detection)が追加料金なしで利用可能になり、誤検知を減らす新しい観測モード(FIXED)が追加されましたので、マネジメントコンソールから試してみました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/08/aws-glue-data-quality-anomaly-detection-free/

AWS Glue Data Quality の異常検知は、ルールやアナライザーが収集した統計値(行数や完全性など)を機械学習モデルが時系列で学習し、予測範囲から外れた値を異常として検出する機能です。従来、ETL ジョブでの異常検知は統計 1 つあたり 1 DPU の追加課金が発生していましたが、今回のアップデートで追加料金なしで利用できるようになりました。

あわせて、新しい観測モードが導入されました。従来の予測(LINEAR モード)は線形トレンドを外挿するため、実行間隔が不規則な場合や明確なトレンドがないデータでは誤検知(False Anomaly)が発生しやすいという課題がありました。新しい FIXED モードは定数ベースラインで予測することでこの課題に対応します。

https://docs.aws.amazon.com/glue/latest/dg/data-quality-anomaly-detection.html

AWS Glue Data Quality の異常検知とは

AWS Glue Data Quality は、サーバーレスでデータ品質の測定・監視・改善を行える機能です。ルールベースのチェックに加えて、機械学習を活用した異常検知を提供しています。

異常検知は、過去の実行から行数(RowCount)などの統計値のパターンを学習し、季節性やトレンドを考慮して逸脱を検出します。固定の閾値を使ったルールでは捉えられない「いつもと違う」データの変化を、コードを書かずに検出できる点が特徴です。

アップデート内容

今回のアップデートの主な変更点は以下のとおりです。

• ETL ジョブにおける異常検知が追加料金なしで利用可能に: 料金を気にすることなく、すべての AWS Glue パイプラインでデータ品質の異常を監視できるようになりました
• 新しい観測モードの導入: 誤検知(False Anomaly)の検出を削減する新しい観測モードが追加されました
• 予測方式の改善: 線形トレンドの代わりに定数ベースライン(Constant Baseline)を使用することでトレンドの過剰な外挿を回避し、より正確なアラートとノイズの削減を実現します
• 不規則なデータ到着間隔への対応改善: ノートブックベースや探索的なワークフローでも、データの到着間隔が不規則なケースを適切に扱えるようになりました

新しい観測モードは、特に以下のようなケースで有用とされています。

• 探索的データ分析
• フラットまたはランダムなパターンを持つデータセット
• 予測可能なトレンドを持たないワークロード
• 実行スケジュールが一定でないデータ品質チェックや、ノートブックのようなインタラクティブ環境での実行

従来の異常検知は過去のトレンドから将来値を予測する仕組みのため、実行間隔が不規則な場合や明確なトレンドがないデータでは、実際には問題のない変化を異常として検出してしまうことがありました。今回の改善により、こうしたノイズが減り、本当に対処すべき異常に集中しやすくなります。

異常検知の観測モード(LINEAR / FIXED)とは

公式ドキュメントによると、異常検知の観測モードは次の 2 つから選択できます。

• LINEAR(デフォルト): データのトレンドや季節性を学習し、将来値を外挿して予測します。定期スケジュールで実行し、データに一貫した増減トレンドや週次・日次の周期性がある場合に適しています
• FIXED: 実行間隔にかかわらず全データポイントを等間隔として扱い、観測値から定数ベースラインを確立して予測します。フラットまたはランダムに変動するデータ、不規則な間隔での実行、ノートブックでの探索的分析に適しています

異常検知には最低 3 データポイントが必要で、それ以降のランから予測値と実際値の比較が行われます。

ETL ジョブでは EvaluateDataQuality の additional_options に observations.mode を指定します。AWS Glue Data Catalog のテーブルに対する評価ランでは AdditionalRunOptions の ObservationMode フィールドで指定します。未指定の場合は LINEAR モードで動作します。

AWS Glue Studio のビジュアルエディタでは、Evaluate Data Quality ノードの「Anomaly detection」タブから異常検知の有効化とアナライザーの追加ができますが、観測モードの指定はスクリプト側のオプションで行います。そのため今回は Script editor でジョブを作成します。

https://docs.aws.amazon.com/glue/latest/dg/data-quality-configuring-anomaly-detection-etl-jobs.html

やってみた

前提条件

• Glue ジョブ実行用の IAM ロール(S3 への読み取りアクセスを含む Glue サービスロール)
• 検証環境: ap-northeast-1、AWS Glue 5.1(G.1X ワーカー × 2)

テストデータの準備

行数だけが変化する売上データ風の CSV を 5 世代用意します。1〜4 世代目は 100 行前後(100 → 102 → 97 → 101 行)でランダムに変動させ、5 世代目だけ 30 行と大きく減らして「異常」を仕込みます。

import csv
import random

random.seed(42)
products = ["apple", "banana", "cherry", "grape", "orange"]
row_counts = {1: 100, 2: 102, 3: 97, 4: 101, 5: 30}

for gen, n in row_counts.items():
    with open(f"sales_gen{gen}.csv", "w", newline="") as f:
        w = csv.writer(f)
        w.writerow(["order_id", "product", "quantity", "price"])
        for i in range(1, n + 1):
            w.writerow([
                f"G{gen}-{i:04d}",
                random.choice(products),
                random.randint(1, 9),
                random.randint(100, 2000),
            ])

生成された CSV は以下のような内容です。

order_id,product,quantity,price
G1-0001,apple,1,1618
G1-0002,cherry,4,557
G1-0003,banana,2,1485
G1-0004,orange,2,1309
G1-0005,grape,1,161

Amazon S3 コンソールを開き、「バケットを作成」から検証用のバケットを作成します。今回は blog-tryit-20260810 という名前で、リージョンは ap-northeast-1 としました。

作成したバケットを開き、「フォルダの作成」で input フォルダを作成します。さらに input の中に gen1 〜 gen5 のフォルダを作成し、それぞれに対応する世代の CSV を sales.csv という名前でアップロードします。

アップロード後のオブジェクト一覧は以下のようになります。5 世代目だけファイルサイズが小さいことが分かります。

FIXED モードを指定した Glue ジョブの作成

AWS Glue コンソールの左側ナビゲーションから「ETL jobs」を開き、「Script editor」を選択します。Engine は「Spark」、Options は「Start fresh」を選んだ状態で「Create script」をクリックします。

スクリプトエディタに以下の PySpark スクリプトを貼り付けます。EvaluateDataQuality の additional_options に observations.mode: FIXED を指定するのがポイントです。アナライザーで RowCount(行数)と product 列の Completeness(完全性)を収集します。

まず、データ品質のルールセットは DQDL(Data Quality Definition Language)で記述します。今回指定したのは以下の内容です。

ruleset = """
Rules = [
    IsComplete "order_id"
]
Analyzers = [
    RowCount,
    Completeness "product"
]
"""

Rules と Analyzers は役割が異なります。

今回指定した内容は以下のとおりです。

異常検知は、ここで収集された統計の時系列に対して働きます。今回は行数の急減を検出したいので、RowCount をアナライザーに指定している点がポイントです。アナライザーで指定できる統計には、ほかにも Completeness、Uniqueness、Mean、Sum、StandardDeviation、Entropy、DistinctValuesCount、UniqueValueRatio などがあります。閾値を決められる列がない場合は、Rules を空にして Analyzers だけを書くこともできます。

なお、公式ドキュメントによると、同じ列に対して Rule と Analyzer の両方を指定しても、統計の収集は 1 回だけです。

このルールセットで収集される統計は、IsComplete "order_id" による Column.order_id.Completeness、アナライザーによる Dataset.*.RowCount と Column.product.Completeness の 3 つです。あとで「Data quality」タブに Statistics gathered が 3 と表示されるのは、この 3 つを指しています。

異常検知の設定は EvaluateDataQuality の呼び出し部分に集約されています。該当箇所を抜き出すと以下のとおりです。

result = EvaluateDataQuality().process_rows(
    frame=dyf,
    ruleset=ruleset,
    publishing_options={
        "dataQualityEvaluationContext": "dq_fixed_mode_context",
        "enableDataQualityCloudWatchMetrics": True,
        "enableDataQualityResultsPublishing": True,
    },
    additional_options={
        "observations.scope": "ALL",
        "observations.mode": "FIXED",
    },
)

各引数の役割は以下のとおりです。

publishing_options の各キーは、API の DQResultsPublishingOptions のフィールドに対応します。

dataQualityEvaluationContext に指定した名前は、あとで確認するコンソール画面にそのまま現れます。今回は dq_fixed_mode_context を指定したため、「Data quality」タブのルールセット選択が dq_fixed_mode_context、統計名が dq_fixed_mode_context.RowCount と表示されます。結果を追いやすいよう、ジョブやデータセットが分かる名前を付けておくとよさそうです。

そして今回の主役が additional_options です。

なお、戻り値の result は今回使用していません。評価結果は「Data quality」タブから確認します。上記の通り、具体的なしきい値は設定していません。

続いて「Job details」タブを開き、以下のとおり設定します。

同じ「Job details」タブの「Advanced properties」を展開し、「Job parameters」に入力パスのパラメータを追加します。

設定できたら画面右上の「Save」でジョブを保存します。

データを差し替えながら 5 回実行

画面右上の「Run」をクリックしてジョブを実行します。「Runs」タブに切り替えると、実行中のランが表示されます。Run status が「Succeeded」になるのを待ちます。

1 回目が完了したら、「Job details」タブに戻って Job parameters の --input_path の値を s3://blog-tryit-20260810/input/gen2/ に書き換え、「Save」してから再度「Run」します。これを gen5 まで繰り返し、合計 5 回実行します。

5 回の実行結果は「Runs」タブで一覧できます。今回の結果は以下のとおり、すべて成功しました。

異常検知結果の確認

ジョブの「Data quality」タブを開くと、選択したランのデータ品質結果が表示されます。画面右上の「Selected run」で確認したいランを切り替えられます。ここでは 5 回目(30 行)のランを選択しました。

サマリーは以下のとおりです。

ルール IsComplete "order_id" は「Rule passed」で、評価メトリクスは Column.order_id.Completeness: 1.00 でした。異常が 1 件検出されている一方で DQ score は 100% のままです。公式ドキュメントに記載のとおり、異常が生成されてもデータ品質スコアには影響しません。

画面下部には「Rules (1)」「Statistics (3)」「Anomalies (1)」の 3 つのタブが並びます。Statistics と Anomalies を順に見ていきます。

Statistics タブで統計の推移を確認する

「Statistics」タブで RowCount を選ぶと、収集された統計値の推移がグラフ表示されます。実際値(RowCount values)に加えて、モデルが算出した予測トレンド(Prediction trend)と予測の上限・下限(Prediction upper bound / Prediction lower bound)が重ねて描画されます。

記録された統計値は以下のとおりです。5 回分の実行がすべて学習対象(Included statistic)になっています。

予測トレンドと上下限のバンドは 100 前後でほぼ水平に推移しており、線形トレンドを外挿しない FIXED モードの動作をグラフからも確認できます。最後の 1 点(30)だけが下限を大きく割り込んでいます。

Anomalies タブで異常の詳細を確認する

「Anomalies」タブには、選択中のランで生成された Observation が一覧表示されます。

検出された異常は以下の 1 件でした。

期待どおり、30 行への急減が異常として検出されました。予測値は 100、予測範囲は 96〜103 で、実際値の 30 は下限を大きく下回っています。

右側の「Rule Recommendations」には、この異常を今後ルールとして検出するための推奨ルールが提示されます。

RowCount between 95.0 and 104.0

「Apply copied rules」から、推奨ルールをそのままルールセットへ取り込めます。また「Edit training inputs」で特定の統計値を学習対象から除外し、「Save and retrain」でモデルを再学習させることもできます。今回の異常は Training input が「Accepted anomaly」、Retrain status が「Retrained」となっており、検出された 30 という値を学習対象に含めたままモデルが再学習された状態です。真の異常として扱いたい場合は、ここから学習対象を編集して再学習させます。

FIXED モードの予測(定数ベースライン)を確認

ここまでの結果から、FIXED モードの予測がどのように振る舞ったのかを整理します。

入力データの行数は 100 → 102 → 97 → 101 と上下に変動していましたが、Statistics タブのグラフでは予測トレンド(Prediction trend)がほぼ水平のまま推移していました。異常が検出された 5 回目の時点でも予測値は 100、予測範囲は 96〜103 です。直近の増減を将来に外挿せず、観測値の平均近傍を定数ベースラインとして予測する FIXED モードの挙動を確認できます。

また、今回の 5 回のランは統計の Run date を見ると実行間隔がばらついています。

FIXED モードは実行間隔にかかわらず全データポイントを等間隔として扱うため、このように間隔が不規則でも予測が引っ張られません。予測範囲は 96〜103 と幅が狭いまま安定しており、30 行への急減が明確に下限を割り込む形で検出できました。

公式ドキュメントによると、LINEAR モードはトレンドや季節性を学習して将来値を外挿します。今回のようにトレンドを持たないデータや、実行間隔が一定でないワークロード、ノートブックでの探索的な実行では、FIXED モードが適しているとされています。

考察

実際に試して得られた知見を整理します。

• FIXED モードの予測値はほぼ一定(定数ベースライン)で、行数がランダムに上下するデータでもノイズの少ない予測範囲が得られました。日次バッチのような等間隔実行でなくても使いやすい挙動です
• 異常検知には最低 3 データポイントが必要なため、1〜3 回目のランは実質的に学習用のベースライン作りになります。データポイントが少ないうちは予測範囲が安定しないので、本運用に入る前に数回分のデータを流しておくのがよさそうです
• 検知された異常値は、そのままだと正常値としてモデルに学習されます。今回も Training input が「Accepted anomaly」となっていました。真の異常として扱いたい場合は、Anomalies タブの「Edit training inputs」で学習対象から外し、「Save and retrain」で再学習させる必要があります
• 今回の検証でのジョブ実行は 5 回合計 955 DPU 秒(約 0.27 DPU-hour)でした。従来はこれに加えて異常検知の統計ごとに 1 DPU の課金が発生していましたが、今回のアップデートで ETL ジョブの異常検知は追加料金なしになったため、気軽に有効化できます

観測モードの指定は現時点ではスクリプト内の additional_options で行うため、今後は AWS Glue Studio のビジュアルエディタから観測モードを切り替えられるようになることや、モード選択の自動推奨などにも期待したいところです。

最後に

AWS Glue Data Quality の ETL 異常検知が追加料金なしになり、新しい FIXED モードとあわせてマネジメントコンソールから動作を確認できました。行数の急減という典型的なデータ品質問題を、閾値の設定なしで検出し、推奨ルールまで自動生成してくれるのは実用的です。

これまで料金を理由に異常検知の導入を見送っていた方は、既存の Glue パイプラインの EvaluateDataQuality にアナライザーを追加するところから試してみてはいかがでしょうか。この記事がどなたかのお役に立てば幸いです。