Amazon QLDB 完全ガイド 2026

初心者から実務者向けの包括的解説 - 終了予定機能

⚠️ CRITICAL: Amazon QLDB は 2025 年 7 月 31 日にサポート終了予定です。新規採用は非推奨。既存ユーザーは Aurora PostgreSQL Ledger 機能への移行を検討してください。

Amazon QLDB（Quantum Ledger Database）は、改ざん検証可能な不変ジャーナルを持つ中央管理型台帳データベース です。すべてのデータ変更は暗号学的に検証可能なジャーナルに記録され、削除・変更が不可能。金融取引・サプライチェーン・医療記録など「誰が・いつ・何を変更したか」を改ざん不可能・証明可能な形で保持する必要があるユースケースに特化していました。

ただし AWS は 2024 年 7 月に QLDB の段階的廃止を発表。理由は 「Aurora PostgreSQL + Ledger 機能で同等の監査証跡が実現でき、より柔軟な SQL 機能を提供できるから」 です。

ドキュメントの目的と警告

本ガイドは以下を対象としています。

• 既存 QLDB ユーザー向け： 2025 年 7 月 31 日までの終了期限・移行戦略・代替手段の理解
• 新規検討者向け： QLDB は選ばないこと。Aurora PostgreSQL Ledger や他の代替手段を検討
• 学習向け： ブロックチェーン・台帳データベースの概念理解（歴史的価値）

2025-2026 年の QLDB エコシステム

• End-of-Support: 2025 年 7 月 31 日（公式発表）
• 推奨移行先：
  • Aurora PostgreSQL with Ledger（AWS 推奨）
  • Microsoft Azure SQL Ledger
  • ImmuDB（オープンソース）
  • TerminusDB / Dolt（分散台帳）

目次

1. ⚠️ 重要: 終了予定通知
2. 概要
3. QLDB が解決していた課題
4. 主な特徴
5. コアコンセプト
6. ジャーナル・ダイジェスト
7. PartiQL クエリ言語
8. データ検証メカニズム
9. アーキテクチャ
10. セキュリティ
11. ユースケース
12. Hyperledger Fabric との比較
13. DynamoDB との比較
14. 設定・操作の具体例
15. トレーニングリソース
16. 緊急: 移行戦略
17. 代替手段の詳細比較
18. ベストプラクティス（過去のみ適用）
19. 2024-2025 終了通知
20. まとめ

⚠️ 重要: 終了予定通知

Amazon QLDB は以下の日程で廃止されます：

既存ユーザーがすべき対応

1. 緊急度の確認

   • 本番環境で QLDB を使用しているか
   • どの程度のデータボリュームか
   • RPO/RTO 要件は何か

2. 移行先の選定

   • Aurora PostgreSQL Ledger（AWS 推奨） ← ほとんどのユースケース
   • Azure SQL Ledger（Azure エコシステムの場合）
   • ImmuDB（オープンソース・独立系）

3. 移行スケジュール

   • 即座に計画開始（2025 年 7 月が迫っている）
   • 2024 年中に移行テスト完了
   • 2025 年 6 月までに本番環境移行

概要

初心者向けメモ： QLDB は「改ざんできないデータベース」というコンセプト。例えば銀行が「この口座の残高変化は正当な取引の積み重ねで発生した」ことを数学的に証明したい時に使う。ブロックチェーンに似ているが、単一の信頼できる機関（銀行・企業）が管理する「プライベートな台帳」として設計されている。

QLDB は以下を実現していました（過去形）：

• 改ざん不可能な監査証跡：すべての変更が暗号学的にチェーン化
• 暗号学的検証：特定レコードが改ざんされていないことを第三者に証明可能
• PartiQL クエリ：SQL 類似の柔軟なクエリ
• Streams 統合：Kinesis へリアルタイムイベント送信

ただし、これらの機能は Aurora PostgreSQL Ledger でも実現でき、さらに SQL の完全性とリレーショナル機能が使える ため、QLDB は廃止に至った。

QLDB が解決していた課題

課題 1: 監査証跡の改ざん不可証明

状況： 金融機関が「この残高変化は改ざんされていない」ことを規制当局に証明したい

QLDB の解決：

• すべての取引を SHA-256 ハッシュチェーンで記録
• 過去のジャーナル状態を メルクルツリーで再現可能
• 改ざん有無を暗号学的に証明

代替手段（Aurora PostgreSQL Ledger）：

• 同等の監査証跡機能
• SQL での柔軟なクエリ
• より低いコスト

課題 2: 単一信頼機関の台帳

状況： 企業内で「所有権の変更履歴を改ざん不可能に保持する」必要

QLDB の解決：

• ブロックチェーン的な不変性（複雑さなし）
• 中央管理型で設定シンプル

代替手段（Hyperledger Fabric）：

• 複数組織間の分散型台帳
• より複雑だが、トラストレス環境向け

主な特徴

graph TD
    A["QLDB Ledger<br/>中央管理型台帳"] --> B["PartiQL<br/>SQL 風クエリ"]
    A --> C["ジャーナル<br/>追記専用ハッシュチェーン"]
    A --> D["ダイジェスト<br/>メルクルツリー"]
    
    C --> E["INSERT = ブロック追加"]
    C --> F["UPDATE = 新ブロック追加"]
    C --> G["DELETE = ソフト削除<br/>ジャーナルに削除記録"]
    
    D --> H["暗号学的検証"]
    D --> I["過去状態の復元"]
    
    J["セキュリティ"] --> K["IAM 統制"]
    J --> L["KMS 暗号化"]
    J --> M["VPC 隔離"]

特徴の詳細

1. 不変ジャーナル

   • すべての変更を SHA-256 ハッシュで追跡
   • ハッシュチェーンで過去改ざん検出
   • 削除不可（AWS すら削除不可）

2. PartiQL クエリ

   • SQL ライク（ただし、ACID の完全性は限定的）
   • history() 関数で過去バージョン取得
   • ドキュメント型データ

3. 暗号学的検証

   • GetDigest()：ジャーナル全体のハッシュ取得
   • GetRevision()：特定ドキュメントの証明パス取得
   • VerifyDigest()：クライアント側で検証可能

4. Streams 統合

   • Amazon QLDB Streams で Kinesis へイベント送信
   • リアルタイム監査ログ・分析が可能

コアコンセプト

ジャーナル（Journal）

時系列のすべての操作を記録：

ブロック 0（ジェネシスブロック）
  ハッシュ: 0000...

ブロック 1（INSERT user_001）
  ハッシュ: H1 = hash(ブロック 0 ハッシュ + INSERT データ)

ブロック 2（INSERT order_001）
  ハッシュ: H2 = hash(H1 + INSERT データ)

ブロック 3（UPDATE user_001）
  ハッシュ: H3 = hash(H2 + UPDATE データ)

ブロック 4（DELETE order_001）
  ハッシュ: H4 = hash(H3 + DELETE マーク)

...

各ブロックが前ブロックのハッシュを含む = 改ざん検出

ダイジェスト（Digest）

ジャーナル全体の最終ハッシュ値：

Digest(時刻 T) = Merkle Tree Root Hash

用途：
  - 「この時刻のジャーナルが改ざんされていない」ことを証明
  - 規制当局に提出可能な「真実の証拠」

例：
  GetDigest() → "abc123def456..."
  
  この Digest を計算時刻とともに保存すれば、
  後で「この Digest は本当だったのか？」を検証可能

PartiQL クエリ言語

PartiQL は SQL と Ion（Amazon の半構造化データ形式）を組み合わせた言語。

-- テーブル作成
CREATE TABLE Vehicles

-- インデックス作成
CREATE INDEX ON Vehicles (VIN)

-- ドキュメント挿入（Ion 形式）
INSERT INTO Vehicles VALUE {
  'VIN': 'ABC123XYZ',
  'Color': 'Red',
  'Owner': 'Alice',
  'Year': 2023
}

-- 複数行挿入
INSERT INTO Vehicles VALUE {
  'VIN': 'DEF456UVW',
  'Color': 'Blue',
  'Owner': 'Bob'
}

-- クエリ（現在データ）
SELECT * FROM Vehicles WHERE VIN = 'ABC123XYZ'

-- 条件付きクエリ
SELECT * FROM Vehicles WHERE Color = 'Red' AND Year > 2020

-- 履歴クエリ（すべての過去バージョン）
SELECT * FROM history(Vehicles)
WHERE metadata.id = 'ABC123XYZ'
ORDER BY metadata.version ASC

-- 改ざん検証
GetRevision(Vehicles, 'ABC123XYZ', 3)  -- バージョン 3 の証明パス取得

データ検証メカニズム

検証フロー

1. 過去時刻のジャーナル状態を取得
   GetDigest(timestamp) → Digest A

2. 特定ドキュメントの証明パス取得
   GetRevision(table, documentId, version) → Proof

3. クライアント側で暗号検証
   VerifyDigest(Digest A, Proof) → 改ざんなし/あり

結果：
  "このドキュメントは、この時刻の Digest の下で、改ざんされていなかった"
  を数学的に証明可能

API 例（AWS SDK）

import boto3

qldb_client = boto3.client('qldb')

# ジャーナル情報取得
ledger_info = qldb_client.describe_ledger(Name='my-ledger')

# 過去時刻のダイジェスト取得
import time
timestamp = int(time.time() * 1000) - 3600000  # 1 時間前

# QLDB には GetDigest API がないため、
# AWS SDK では直接 API 呼び出しできず、
# PartiQL で history() クエリを使用する必要がある

アーキテクチャ

┌────────────────────────────────────┐
│     アプリケーション                 │
│  - PartiQL クエリ                  │
│  - DocumentClient（Node.js など）   │
└─────────────────┬──────────────────┘
                  │
┌─────────────────────────────────────┐
│   QLDB レジャー（Ledger）            │
│  ├── ジャーナル（Journal）           │
│  │   └── 全ブロック（ハッシュチェーン） │
│  │       └── 改ざん不可            │
│  │                               │
│  └── インデックス付きビュー         │
│      └── PartiQL クエリ用          │
└──────────────────────────────────────┘

High Availability：
  └── 3 AZ レプリケーション（自動）
  └── マルチ AZ フェイルオーバー < 30 秒
  └── 99.99% SLA

キーポイント

• サーバーレス：インスタンス管理不要
• 自動スケール：スループット無制限
• マルチ AZ：自動 3 AZ レプリケーション
• ACID トランザクション：標準サポート

セキュリティ

IAM 統制

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "qldb:GetBlock",
        "qldb:GetDigest",
        "qldb:SendCommand"
      ],
      "Resource": "arn:aws:qldb:*:123456789012:ledger/my-ledger"
    },
    {
      "Effect": "Deny",
      "Action": "qldb:DeleteLedger",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:username": "admin"
        }
      }
    }
  ]
}

KMS 暗号化

# KMS キーで暗号化して Ledger 作成
aws qldb create-ledger \
  --name "my-ledger" \
  --permissions-mode "ALLOW_ALL" \
  --kms-key "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"

不変性

AWS すら削除不可のセキュリティ特性：

Ledger 作成 → 削除不可
  └─ 必ず AWS Backup・エクスポート後に削除

ジャーナル → 削除・変更不可（数学的に保証）
  └─ 規制要件に完全準拠

ユースケース

想定用途（2025 年 7 月まで）

Hyperledger Fabric との比較

DynamoDB との比較

設定・操作の具体例

警告：新規での実装は非推奨。既存ユーザーのみ参考。

Ledger 作成（AWS CLI）

# Ledger 作成
aws qldb create-ledger \
  --name "audit-ledger" \
  --permissions-mode "ALLOW_ALL" \
  --tags "Environment=production,Owner=Finance"

# Ledger 確認
aws qldb describe-ledger \
  --name "audit-ledger"

# Ledger リスト
aws qldb list-ledgers

テーブル・クエリ（PartiQL）

import boto3
from pyqldb.driver.pooled_driver import PooledDriver

# ドライバー接続
driver = PooledDriver(ledger_name="audit-ledger")

def create_tables():
    with driver.execute_lambda(lambda executor: executor.execute_statement("CREATE TABLE Transactions")) as session:
        pass

def insert_transaction(transaction_id, amount, status):
    with driver.execute_lambda(lambda executor: executor.execute_statement(
        "INSERT INTO Transactions VALUE {'TransactionID': ?, 'Amount': ?, 'Status': ?, 'Timestamp': ?}",
        [transaction_id, amount, status, int(time.time() * 1000)]
    )) as session:
        pass

def verify_transaction(transaction_id):
    # 過去の変更履歴を全件取得
    with driver.execute_lambda(lambda executor: result = executor.execute_statement(
        "SELECT * FROM history(Transactions) WHERE metadata.id = ?",
        [transaction_id]
    )) as session:
        for row in result:
            print(f"Version {row['metadata']['version']}: {row}")

トレーニングリソース

QLDB 学習リソース（参考のみ）

• AWS QLDB Developer Guide（既存ユーザーの移行ガイドとして参照）
• PartiQL Tutorial

代替手段の学習

Aurora PostgreSQL Ledger（推奨）

• Aurora PostgreSQL Documentation
• Database Ledger Tables

ImmuDB（オープンソース代替）

• ImmuDB Official Docs
• GitHub: codenotary/immudb

緊急: 移行戦略

段階 1: 移行先決定（即座に実施）

意思決定フロー：

QLDB 使用中
  ↓
1. AWS エコシステム内に留まる？
  YES → Aurora PostgreSQL Ledger（推奨）
  NO  → 以下を検討：

2. オープンソース希望？
  YES → ImmuDB / Dolt
  NO  → Azure SQL Ledger（Azure 環境）

3. 複数組織間のトラストレス取引？
  YES → Hyperledger Fabric / Ethereum
  NO  → 単一企業の監査台帳なので Aurora Ledger で十分

段階 2: Aurora PostgreSQL Ledger への移行（推奨）

ステップ 1：スキーマ変換
  QLDB PartiQL テーブル
    ↓ (Ion → JSON 変換)
  Aurora PostgreSQL テーブル
    ↓ (新規 Ledger 化)

ステップ 2：データ移行
  QLDB ジャーナルエクスポート（S3）
    ↓ (AWS Glue / Lambda で変換)
  Aurora PostgreSQL へロード

ステップ 3：検証
  QLDB ジャーナル の改ざん検証結果
    ↓ (Aurora Ledger の history で再現)
  検証成功 → Aurora へ本番切り替え

ステップ 4：アプリケーション切り替え
  QLDB PartiQL ドライバー
    ↓ (SQL に書き換え)
  Aurora PostgreSQL ドライバー

段階 3: 運用移行（2025 年 6 月まで）

代替手段の詳細比較

Aurora PostgreSQL Ledger

強み：

• AWS ネイティブ（IAM・KMS・VPC 統合）
• SQL の完全性・JOIN 対応
• より低いコスト
• Ledger テーブルで改ざん検証対応

弱み：

• QLDB ほどの完全な不変性保証ではない
• 歴史的に QLDB より新しい機能

移行難易度： 中程度（PartiQL → SQL 書き換え）

-- Aurora PostgreSQL Ledger テーブル
CREATE TABLE Transactions (
  TransactionID UUID PRIMARY KEY,
  Amount DECIMAL,
  Status TEXT,
  Timestamp TIMESTAMP
) WITH (enable_ledger = true);

-- Ledger テーブルの変更履歴確認
SELECT * FROM Transactions_ledger
WHERE TransactionID = 'abc-123'
ORDER BY ledger_transaction_id DESC;

ImmuDB（オープンソース）

強み：

• 完全なオープンソース（Apache 2.0）
• QLDB と同等の不変性・検証機能
• 独立した DBaaS（Immu Cloud）利用可能

弱み：

• AWS 外での運用・管理（EC2 ホスティング推奨）
• AWS ネイティブ統合なし
• ドキュメント・コミュニティが QLDB より小さい

移行難易度： 低〜中程度（概念は QLDB と類似）

// Go での ImmuDB 使用例
immudb, err := client.NewImmuClient()
defer immudb.Disconnect(ctx)

// トランザクション挿入
_, err = immudb.Set(ctx, []byte("transaction_id"), 
  []byte(`{"amount": 1000, "status": "completed"}`))

// 履歴確認
history, err := immudb.History(ctx, []byte("transaction_id"))

Azure SQL Ledger

強み：

• Microsoft SQL Server ベース
• Azure エコシステム統合
• SQL Server の強力なサポート

弱み：

• Azure 環境必須
• AWS 統合なし

推奨シナリオ： Azure メインの組織

ベストプラクティス（過去のみ適用）

⚠️ 注記：2025 年 7 月廃止予定のため、以下は「既存 QLDB ユーザーの運用」に限定

✅ 推奨パターン（廃止まで）

• 定期的なジャーナルエクスポート（S3）
• Streams 統合による監査ログ の外部保存
• PITR テストの定期実施
• 移行計画の早期開始

❌ アンチパターン

• 新規ワークロードでの QLDB 採用（非推奨）
• 改ざん検証機能への過度な依存
• 移行計画の先延ばし

トラブルシューティング

2024-2025 終了通知

公式発表内容

AWS が 2024 年 7 月に以下を発表：

“AWS is discontinuing Amazon Quantum Ledger Database (QLDB) and recommends customers migrate to Aurora PostgreSQL with Ledger.”

既知の課題・制限

1. 正式なマイグレーションツール がない

   • AWS は移行ツール提供なし
   • 顧客が手動で PartiQL → SQL 変換
   • AWS プロフェッショナルサービスの利用推奨

2. QLDB の完全な不変性を Aurora では保証しない

   • Aurora Ledger は「歴史を追跡可能」程度
   • QLDB の「改ざん不可証明」ほどではない

3. 移行コスト

   • 大規模ワークロード：数百万円の追加コスト
   • スキーマ変換・テスト・本番切り替え

まとめ

Amazon QLDB は 2025 年 7 月 31 日廃止予定です。新規採用は絶対避けてください。

既存ユーザーの対応

1. 即座に移行計画開始 → 2025 年 6 月までに本番切り替え
2. 移行先を選定 → Aurora PostgreSQL Ledger（AWS 推奨）
3. テスト・検証実施 → 改ざん検証ロジックの移植確認
4. 段階的移行 → 並行運用で安全に切り替え

新規検討者の対応

QLDB は選ばないでください。 代わりに以下を検討：

• AWS メイン → Aurora PostgreSQL Ledger
• Azure メイン → Azure SQL Ledger
• 独立系 → ImmuDB（オープンソース）
• 複数組織 → Hyperledger Fabric

QLDB は「不変台帳」の素晴らしい概念を示しましたが、Aurora Ledger でより柔軟かつ安価に実現可能となったため、廃止されることになりました。AWS エコシステムの進化を受け、適切な選択肢を活用してください。

最終更新：2026-04-26 バージョン：v2.0 - END-OF-LIFE ガイド