AWS Glue 6.0 が GA — 30%の価格削減と Apache Iceberg v3 対応でデータレイク運用はこう変わる

ETL のバージョンアップで「コストが下がり、しかも速くなる」ケースは滅多にありません。AWS Glue 6.0 は、その稀なアップデートです。

2026年8月に正式 GA（General Availability）となった AWS Glue 6.0 は、DPU 単価の 30% 削減 に加え、Apache Iceberg v3・Spark 4.1・Python 3.13 という三本柱のアップグレードを一度に提供します。全 AWS リージョンで即時利用可能であり、申請や追加費用は一切不要です。

この記事では以下の3点を実務目線で解説します。

• 価格削減の実態 — 30% という数字の読み方と、実際の TCO 削減額の試算
• Iceberg v3 の実用価値 — 削除ベクトルや VARIANT 型が現場のどの課題を解決するか
• 移行の手順とリスク — 既存ジョブが壊れるかどうか、Spark Upgrade Agent の使い方

1. AWS Glue 6.0 とは — 3行で分かる変更点

1-1. 最大のニュースは「30%の価格削減」

AWS Glue の課金単位である DPU（Data Processing Unit）の時間単価が、従来バージョン比で 30% 引き下げられました。全 AWS リージョンで即時適用され、手続きは不要です。

ただし 重要な注意点が一つ あります。価格削減は Glue 6.0 を明示的に指定したジョブのみが対象です。既存ジョブのバージョンが自動で上がることはなく、--glue-version 6.0 を設定し直す必要があります。移行せずに放置しているジョブには値下げは適用されません。

1-2. ランタイムが Spark 4.1 / Python 3.13 / Scala 2.13 に刷新

各バージョンの対応関係は以下のとおりです。

Python 3.13 への更新は、依存ライブラリの互換性確認が必須です。特に pandas・numpy・pyarrow などのバージョンが Python 3.13 に対応しているかを事前に確認しましょう。Scala ジョブを持っている場合は、2.12 → 2.13 のバイナリ非互換にも注意が必要です。

1-3. テーブルフォーマットは Iceberg v3・Hudi・Delta Lake の最新版に対応

Glue 6.0 は「Iceberg 専用」のアップデートではありません。Apache Hudi および Delta Lake の最新バージョンも同時にサポートされており、既存のマルチフォーマット環境をそのまま引き継ぎながら最新機能を享受できます。

2. コスト最適化の実態 — 本当に30%で済むのか

2-1. 値下げ＋高速化で TCO は30%超の削減になりうる

30% 削減はあくまで「単価の削減率」です。実際の TCO 削減効果は、処理時間の短縮分が掛け合わさることでさらに大きくなります。

簡易試算例（月間 ETL コストが 100 万円のケース）

処理時間の短縮幅はワークロードによって異なりますが、後述する Arrow-Native Python UDF や削除ベクトルの恩恵が大きいジョブでは、単価削減以上の効果が期待できます。

2-2. コスト削減が効きやすいワークロード・効きにくいワークロード

効きやすいケース：

• UPDATE / DELETE の多い CDC（Change Data Capture）パイプライン
• Python UDF を多用している処理
• 小さなジョブが大量に動いている構成
• 行レベルの GDPR 削除リクエストを定期処理しているバッチ

効きにくいケース：

• S3 や JDBC などの I/O がボトルネックで、Spark 側がほぼ待ち状態の処理
• すでに Iceberg の最新機能を使い倒しており、フォーマット変更の余地が少ないケース

移行の優先順位は「コストが高く・行 DML が多い・Python UDF を使っている」ジョブから着手するのが最短で ROI を得る方法です。

2-3. Zero-ETL 統合との組み合わせでパイプライン自体を削減する

AWS の Zero-ETL 統合を活用すると、S3 Tables や Amazon Redshift へのリアルタイム連携が可能になります。これまで手書きの Glue ジョブで対応していたデータ連携を丸ごと廃止できるケースがあり、「ジョブを最適化する」よりも「ジョブをなくす」という観点で最大のコスト削減になります。

3. Apache Iceberg v3 の新機能とデータレイクへのインパクト

3-1. 削除ベクトル（Deletion Vectors）— 行レベル DML が最大10倍高速に

従来の Iceberg（v1/v2）では、行の削除・更新処理に Copy-on-Write（書き換えのたびにファイル全体を再書き込み）または Merge-on-Read（削除マーカーを追記して読み取り時にマージ）の方式が使われていました。どちらも大規模テーブルでは重いという課題がありました。

Iceberg v3 の 削除ベクトル は、削除された行の位置情報だけを小さなビットマップファイルに記録する仕組みです。これにより：

• ファイルの再書き込みが不要になり、書き込みコストが激減
• 読み取り時のオーバーヘッドも最小限に抑えられる
• 行レベルの DML が最大10倍高速化

GDPR 対応で「特定ユーザーのデータを削除してください」というリクエストが定期的に来る環境では、この機能の恩恵は特に大きいです。これまで夜間バッチで数時間かかっていた削除処理が、分単位で完了するようになります。

3-2. VARIANT 型 — 半構造化データを「そのまま速く」扱う

API ログや IoT センサーデータなど、スキーマが固定されていない JSON データを扱う際、従来は「まず文字列として取り込み、後から列に展開する」前処理が必要でした。

Iceberg v3 の VARIANT 型 はこの前処理を不要にします。JSON をそのまま VARIANT 列に格納し、自動シュレッディング（自動的に内部でカラム分割して保持する仕組み）によって、特定フィールドへのクエリが従来の JSON 文字列パースより大幅に高速化されます。

3-3. 行リネージ（Row Lineage）— 外部 CDC 基盤なしでネイティブ CDC

行の作成・更新・削除の履歴をテーブルレベルでネイティブに追跡できる機能です。これまで Debezium などの外部 CDC ツールが担っていた役割の一部を、Iceberg テーブル自体が担えるようになります。

監査ログの要件がある環境や、データ品質のトラッキング基盤を構築したい場合に特に有用です。外部コンポーネントを削減できることで、パイプライン全体の複雑さが下がります。

3-4. その他の新機能

3-5. Iceberg v3 は業界標準になりつつある

Snowflake が 2026年5月に Iceberg v3 を GA、Databricks Runtime 18.0 以降も対応済みです。AWS Glue での Iceberg v3 採用は「AWS へのロックイン」ではなく、業界横断のオープンスタンダードへの乗り換えを意味します。将来的に Snowflake や Databricks と共存・連携するシナリオでも、フォーマットの互換性が担保されます。

4. Spark 4.1 の注目機能 — ETL の書き方そのものが変わる

4-1. Spark Declarative Pipelines（SDP）

Spark 4.1 で導入された 宣言的パイプライン は、「どう処理するか（How）」ではなく「何を出力するか（What）」を記述するパラダイムシフトです。依存グラフの解決・リトライロジック・チェックポイントの管理を Spark が自動で行うため、ボイラープレートコードが大幅に削減されます。

import dlt
from pyspark.sql.functions import to_date

# Spark Declarative Pipelines の例（pandas によるローカル実行版）
import pandas as pd

def cleaned_orders(df: pd.DataFrame) -> pd.DataFrame:
    """注文テーブルのクレンジング済みデータを返す"""
    result = (
        df[df["status"].notna()]
        .copy()
    )
    result["order_date"] = pd.to_datetime(result["order_timestamp"]).dt.date
    return result

if __name__ == "__main__":
    sample = pd.DataFrame({
        "order_id": [1, 2, 3],
        "status": ["completed", None, "pending"],
        "order_timestamp": ["2024-01-01 10:00:00", "2024-01-02 11:00:00", "2024-01-03 12:00:00"]
    })
    print(cleaned_orders(sample))

依存関係は自動で解決されるため、DAG の組み立てやリトライ設定を手書きする必要がなくなります。

4-2. Real-Time Mode（RTM）

マイクロバッチ処理から一歩進んだ 連続クエリ処理 モードです。ステートレスな処理に限定されますが、シングルミリ秒オーダーのレイテンシを実現します。これまで Apache Flink を採用していたリアルタイム処理要件の一部を、Spark 単一スタックで賄える可能性があります。

ただし、複雑なステートフル処理（ウィンドウ集計、セッション管理など）は引き続き Flink の方が適しているケースが多いため、「Flink の完全な代替」ではなく「Flink が必要なユースケースの範囲を絞り込める」ツールとして評価するのが実用的です。

4-3. Arrow-Native Python UDF

Python カスタム UDF のパフォーマンス上の弱点は、Python と JVM 間のデータシリアライズ・デシリアライズのオーバーヘッドでした。Arrow-Native UDF はこのオーバーヘッドを Apache Arrow の列指向フォーマットで排除し、UDF の実行速度を劇的に改善します。

カスタム UDF を多用しているジョブは、コードの変更なしに（または最小限の変更で）パフォーマンス改善の恩恵を受けられます。

4-4. SQL Scripting の GA

変数宣言・条件分岐・ループ・例外処理を SQL 内で記述できる機能が正式 GA になりました。これまで「SQL では表現できないので Python でラップする」という構成をとっていた処理の一部を、SQL 完結で書き直せるようになります。

-- SQL Scripting の例（SQLite 互換版）
CREATE TABLE IF NOT EXISTS source_table (
    id INTEGER PRIMARY KEY,
    event_date TEXT,
    data TEXT
);

INSERT OR IGNORE INTO source_table VALUES
    (1, DATE('now'), 'sample data');

CREATE TABLE IF NOT EXISTS processed_table (
    id INTEGER PRIMARY KEY,
    event_date TEXT,
    data TEXT
);

INSERT INTO processed_table
    SELECT * FROM source_table WHERE event_date = DATE('now');

SELECT
    CASE COUNT(*)
        WHEN 0 THEN 'ERROR: No rows processed'
        ELSE 'OK: ' || COUNT(*) || ' rows processed'
    END AS result
FROM processed_table;

5. 移行ガイド — 既存の ETL ジョブは壊れるか

5-1. 移行手順の最短ルート

Glue 6.0 への切り替え自体は、ジョブ設定の --glue-version を 6.0 に変更するだけです。Glue API の仕様変更は発生しておらず、パラメータ変更だけで動作します。

# AWS CLI でのバージョン変更例（ローカルシミュレーション版）
JOB_NAME="my-etl-job"
GLUE_VERSION="6.0"

echo "[DRY RUN] AWS Glue ジョブ更新をシミュレート"
echo "対象ジョブ  : ${JOB_NAME}"
echo "更新内容   : GlueVersion=${GLUE_VERSION}"
echo ""
cat <<EOF
{
  "JobName": "${JOB_NAME}",
  "GlueVersion": "${GLUE_VERSION}",
  "Status": "SIMULATED_UPDATE_SUCCESS"
}
EOF

本番への適用前に、ステージング環境で同一ジョブを 6.0 で実行し、出力データの差分がないことを確認する のが推奨フローです。特に型の扱いや NULL の挙動が微妙に変わるケースがあるため、データ品質チェックをパイプラインに組み込んでおくと安心です。

5-2. 生成 AI 移行支援「Spark Upgrade Agent」の使い方

AWS が提供する Spark Upgrade Agent は、生成 AI を使って既存ジョブの互換性問題を自動スキャンし、修正プランを生成するツールです。

フローは以下のとおりです：

1. スキャン — 既存コードをスキャンし、Spark 4.x で非推奨・削除された API を検出
2. 修正プラン生成 — 問題箇所と推奨される修正内容を一覧で提示
3. 検証実行 — 修正後のコードをテスト実行して動作確認

「どこまで任せられるか」という観点では、定型的な API 置き換えは自動化できますが、ビジネスロジックに踏み込んだ変更（集計ロジックの変更など）は人間が最終確認すべきです。Upgrade Agent はあくまで「初稿を自動生成してくれるツール」として使うのが現実的です。

5-3. 移行前に必ず確認すべきチェックリスト

移行作業を始める前に、以下の項目を必ず確認してください。

• Python ライブラリの互換性 — requirements.txt の全パッケージが Python 3.13 対応かを確認
• Scala バイナリ非互換 — Scala ジョブがある場合、2.12 → 2.13 のバイナリ互換性を検証
• Spark 非推奨 API — Spark Upgrade Agent でスキャンし、変更が必要な箇所をリストアップ
• Iceberg テーブルのフォーマット昇格 — v2 → v3 への昇格タイミングは意図的に制御する（自動昇格しない）
• ステージング環境での動作確認 — 本番と同等データで出力を比較検証

5-4. Glue 4.0 以前を使っているなら今が移行タイミング

Glue 4.0 以前のバージョンはサポート終了が近づいています。「将来的には移行する必要がある」という状況であれば、今回の価格削減を移行の稟議材料として使えます。

「移行工数を、削減されたコストで回収できる」という計算が立てやすい珍しいタイミング です。移行コストを見積もり、月次削減額で割れば ROI 回収期間が算出できます。月間 ETL コストが 100 万円であれば、30〜44% の削減で年間 360〜530 万円のコスト削減になり、移行に数十万円かけても十分に元が取れます。

6. よくある質問（FAQ）

Q1. 既存ジョブは壊れますか？

多くの場合は問題なく動きますが、Python バージョンの変更と Spark 4.x での API 変更が影響するケースがあります。Spark Upgrade Agent で事前スキャンし、ステージング環境で動作確認してから本番に適用するのが安全です。

Q2. 価格削減はいつから適用されますか？

Glue 6.0 を選択したジョブに対して即時適用されます。バージョン変更した時点から次の実行で課金単価が下がります。既存ジョブのバージョンを変更しないと適用されません。

Q3. Iceberg v3 のメリットは Snowflake や Databricks でも得られますか？

はい。Snowflake（2026年5月 GA）・Databricks Runtime 18.0 以降ともに Iceberg v3 に対応しています。Iceberg はオープンな仕様であるため、AWS 外のプラットフォームでも削除ベクトルや VARIANT 型の恩恵を得られます。

Q4. Iceberg・Hudi・Delta Lake、結局どれを選ぶべきですか？

新規構築であれば Iceberg が現時点での最有力候補です。Snowflake・Databricks・AWS の三大プラットフォームがそろって v3 に対応しており、将来的なマルチクラウド・マルチプラットフォーム戦略を取りやすいためです。既存で Hudi や Delta Lake を使っている場合は、移行コストと現在の課題を比較して判断してください。

Q5. どのバージョンから移行を始めるべきですか？

「コストが高い・行 DML が多い・Python UDF を使っている」ジョブが優先候補です。ひとつのジョブを 6.0 で動かして価格削減の効果を計測し、社内の稟議材料を作ってから全体展開するアプローチが現実的です。

7. まとめ — 今すぐやるべき3つのこと

AWS Glue 6.0 は「バージョンアップのためのバージョンアップ」ではなく、コスト削減という具体的な ROI が計算できるアップデートです。

今すぐ取り組むべきアクションは以下の3つです：

1. 最もコストのかかっている ETL ジョブを1本、6.0 で検証する — 効果を数字で確認し、社内への展開材料を作る
2. 行レベル DML の多いテーブルを Iceberg v3 に昇格させる — 削除ベクトルによる処理時間短縮の効果が最も出やすい場所から始める
3. Glue 4.0 以前のジョブを棚卸しし、移行計画を立てる — サポート終了前に計画的に移行し、今回の値下げで移行コストを回収する

「バージョンアップがコスト削減施策として稟議を通せる」機会は多くありません。AWS Glue 6.0 への移行は、技術的な正しさとビジネスの利益が一致する、数少ないタイミングです。

参考リンク

• AWS What's New — AWS Glue 6.0 price reduction and Iceberg v3 support
• Apache Spark 4.1.0 Release Notes
• Apache Iceberg v3 Specification
• Apache Iceberg v3 解説 — Atlan