Amazon QLDBとは？台帳データベースの仕組みとサービス終了・移行先を実装者目線で解説

Amazon QLDB（Quantum Ledger Database）は、変更履歴が改ざんできない形で残り、その完全性を暗号学的に検証できるフルマネージドの台帳データベースです。ただし現在は前提が変わっています。QLDBは2024年7月に新規の受け付けを終え、2025年7月31日にサポートが終了しました。この記事では、追記専用ジャーナルとダイジェスト・ハッシュチェーンで変更履歴を証明する仕組み、PartiQLとAmazon Ionによるアクセス、ブロックチェーンとの違いを整理したうえで、サービス終了という現状と、Amazon Aurora PostgreSQLを中心とした移行先の選び分けを実装者目線でまとめます。さらに、今から改ざん耐性や監査証跡が求められるシステムを設計する際に、何を選び、どこで見送るのかという判断基準まで具体的に示します。

まとめ：Amazon QLDBの仕組みとサービス終了・移行の要点

Amazon QLDBは、単一の信頼できる所有者が管理する台帳データベースで、すべての変更を追記専用のジャーナルに記録し、後から書き換えられない履歴を残します。各変更はSHA-256ベースのハッシュチェーンでつながり、ダイジェストと呼ばれる要約値と突き合わせることで、履歴が改ざんされていないことを暗号学的に証明できる設計です。データはドキュメント指向のAmazon Ion形式で保持し、SQLに近いPartiQLで問い合わせます。同じ「台帳」でも、非中央集権で合意形成を行うブロックチェーンとは異なり、QLDBは中央集権の前提に立つ点が最大の違いです。

一方で運用上の結論ははっきりしています。QLDBは2024年7月25日に新規顧客の受け付けを終了し、2025年7月31日にサポートが終了したため、2026年時点では新しい台帳を作れません。既存の台帳性の要件を今後どう満たすかがテーマになり、AWSはAmazon Aurora PostgreSQLへの移行を主軸として案内しています。移行では、Ionのドキュメント構造をリレーショナルに置き換え、PartiQLを標準SQLへ書き換え、QLDBが担っていた暗号学的検証をpgAuditやアプリケーション層、あるいはScalarDLのようなパートナー製品で代替する設計が必要です。改ざん耐性の要件が本当に必要かを見極め、必要なら代替手段の検証レイヤーを明示的に設計する——この記事後半の判断基準を自社の要件に当てはめてください。

Amazon QLDBとは何か：台帳データベースの定義と位置づけ

QLDBを理解する起点は、通常のリレーショナルデータベースと何が違うのかを押さえることです。ここを曖昧にすると、監査証跡のために台帳データベースを選ぶべき場面と、通常のデータベースで足りる場面を取り違えます。リレーショナルデータベースやNoSQLといった選択肢全体の前提は、データベースの種類とRDB・NoSQLの選び方を整理した記事で確認できます。

追記専用ジャーナルが変更履歴の完全性を担保するという基本の考え方

QLDBの中核は、すべての変更を時系列に記録する追記専用（append-only）のジャーナルです。通常のデータベースがレコードを上書きや削除で更新するのに対し、QLDBは過去の状態を消さず、変更を新しいエントリとして積み重ねます。現在のデータはこのジャーナルから導かれる派生ビューという位置づけで、いつ・どの順序で・どう変わったのかという履歴そのものが一次データとして残ります。この構造により、あるレコードがいつ作られ、誰がどの値に変えたのかを後から完全にたどれる点が、監査証跡を求めるシステムに向いていました。

ダイジェストとハッシュチェーンによる暗号学的な改ざん検証の仕組み

QLDBが単なる履歴付きデータベースと違うのは、その履歴が改ざんされていないことを数学的に証明できる点です。ジャーナルの各エントリはSHA-256のハッシュで前後がつながり、全体をたどると1つの要約値（ダイジェスト）に収束します。ダイジェストを保存しておけば、後日ジャーナルを再計算して同じ値になるかを照合するだけで、途中の履歴が書き換えられていないことを検証できる仕組みです。特定の1件が確かに含まれていることを示す証明も取得でき、外部の監査人や規制当局に対して「記録が改ざんされていない」と示す根拠になります。この検証の仕組みが、QLDBを一般的なデータベースと分ける決定的な特徴でした。

PartiQLとAmazon Ionによるデータアクセスの仕組みと特徴

QLDBのデータはAmazon Ion形式で保持されます。IonはJSONを拡張したドキュメント指向のフォーマットで、入れ子構造や型情報を扱えるため、変化するスキーマを柔軟に格納できます。問い合わせにはPartiQLというSQL互換のクエリ言語を用い、SELECTやINSERTといった見慣れた構文でドキュメントを操作できました。リレーショナルデータベースのテーブルやインデックスに似た操作感を保ちつつ、内部では台帳としての追記構造を維持する——この二層の設計が、既存の開発者が学習コストを抑えて台帳を扱えるようにしていた点です。

Amazon QLDBとブロックチェーンの違いと想定ユースケース

QLDBを検討する際に最も混同されやすいのが、ブロックチェーンとの違いです。どちらも「改ざんできない台帳」と表現されますが、信頼の置き方が根本的に異なります。ここを取り違えると、要件に合わない技術を選んでしまいます。

中央集権の台帳と分散台帳であるブロックチェーンの信頼モデルの違い

QLDBは、単一の信頼できる所有者が台帳を管理する中央集権のモデルです。データの正しさは所有者（例えば自社）が保証し、その前提のうえで履歴の改ざん耐性を暗号学的に担保します。対してブロックチェーンは、互いを信頼しない複数の参加者が合意形成の仕組みで台帳を共有する分散モデルで、単一の所有者を置かない点に価値を置く仕組みです。したがって、相互に信頼しない当事者間で台帳を共有する必要があるならブロックチェーン、自社が信頼される所有者として一元的に履歴を管理し検証可能性だけを担保したいならQLDBのような中央集権の台帳、という切り分けになります。多くの業務システムでは後者で足りるため、QLDBはそこを埋める選択肢でした。

QLDBが向いていた監査証跡や取引履歴を扱うユースケースの具体像

QLDBが想定していた用途は、履歴の完全性と検証可能性が業務価値に直結する領域です。具体的には、金融取引の記録、保険金請求の処理履歴、サプライチェーンでの所有権や状態の追跡、車両や資産の登録履歴、システムの構成変更ログなどが挙げられます。いずれも「後から履歴を書き換えていないことを第三者に示せる」ことが要件で、通常のデータベースでは監査ログを別途組み、その監査ログ自体の改ざん耐性を作り込む必要がありました。QLDBはその改ざん耐性を土台として提供する点に存在意義がありました。逆に、履歴の証明が要らない一般的な業務データでは、通常のリレーショナルデータベースやNoSQLで十分だった点も、選定時の重要な線引きです。

Amazon QLDBのサービス終了：新規受付終了とサポート終了の現状

ここまでの仕組みを踏まえたうえで、運用面の現状を正確に押さえます。QLDBは提供が終了しており、これから新規に採用する対象ではありません。

2024年新規受付終了・2025年7月31日サポート終了のスケジュール

AWSは、Amazon QLDBについて2024年7月25日に新規顧客の受け付けを終了し、2025年7月31日にサービスのサポートを終了すると公式にアナウンスしました。この日付をもって、QLDBの台帳を新たに作成することはできず、既存利用者もサポート終了に向けて移行を進める前提に置かれました。2026年7月時点ではサポート終了日を過ぎているため、新規構築の選択肢からは外れ、実装者にとっての論点は「既存台帳をどこへ移すか」と「今後、台帳性の要件をどの技術で満たすか」に移っています。日付や条件は変更される可能性があるため、実際の対応時はAWS公式のアナウンスで最新の状況を確認してください。

サービス終了が実装者の設計に与える影響とこれからの検討の起点

提供終了が確定したサービスを設計に組み込むことはできないため、これから改ざん耐性のある記録基盤が必要になった場合、QLDBそのものは候補になりません。代わりに、QLDBが担っていた2つの価値——変更履歴の完全な保持と、その履歴の暗号学的な検証——を、別の構成でどう再現するかを検討の起点に置きます。多くのケースでは、AWSが案内する移行先を軸に、要件のうち「本当に暗号学的検証まで必要な部分」と「履歴が残れば足りる部分」を切り分けることが、過剰な作り込みを避ける鍵です。次章で移行先の選択肢を整理します。

Amazon QLDBの移行先とQLDBの機能を代替する選択肢

移行では、QLDBの台帳性をそのまま置き換える単一のサービスがない点を先に理解しておく必要があります。データの保持先と、暗号学的検証を担うレイヤーを分けて設計するのが実務的な進め方です。

Amazon Aurora PostgreSQLへの移行と検証機能の代替

AWSが移行先の主軸として案内しているのがAmazon Aurora PostgreSQLです。Ion形式のドキュメントをリレーショナルなテーブル設計へ置き換え、PartiQLのクエリを標準SQLへ書き換えて移します。ここで注意すべきなのは、Auroraへ移した時点でQLDBが標準提供していた暗号学的検証はそのままでは引き継がれないという点です。監査要件は、PostgreSQLの監査拡張であるpgAuditで操作ログを残す、変更履歴テーブルを設けてアプリケーション層でハッシュチェーンを組む、といった方法で代替します。Aurora自体の分散ストレージや可用性・料金モデルの詳細は、Amazon Auroraの仕組みと採用判断を解説した記事で確認してください。マネージドなリレーショナルデータベースの選択肢としてAurora以外のエンジンも含めて比較したい場合は、Amazon RDSの対応エンジンと料金モデルを解説した記事が入り口になります。

ScalarDLやDynamoDBを組み合わせる改ざん検知の選択肢

暗号学的な改ざん検知を移行後も保ちたい場合は、パートナーソリューションのScalarDL（株式会社Scalar）が候補になります。ScalarDLはAmazon DynamoDBやAuroraと組み合わせて、改ざん検知を伴う台帳機能を提供する製品です。ただしQLDBがリレーショナルに近いデータモデルとPartiQLを備えていたのに対し、ScalarDLはキー・バリューに近いフラットな構造とコントラクト（Javaで記述する処理）を前提とするため、データモデルとアクセス方法の設計をあらためて見直す必要があります。要件が「履歴を残しつつ、必要時に改ざんされていないことを証明できること」であれば、まずどこまでの検証強度が要るのかを定義し、Aurora＋アプリ層検証で足りるのか、専用の台帳機能まで要るのかを段階的に判断すると、過剰投資を避けられます。

データモデルとクエリの移行で実装者が事前に押さえておく注意点

移行作業でつまずきやすいのが、データモデルとクエリの2点です。Ionは入れ子構造を持つドキュメント形式のため、リレーショナルへ移す際には正規化の設計判断が要り、機械的な変換だけでは済みません。クエリもPartiQLから標準SQLへ書き換えるため、アプリケーション側のデータアクセス層に手が入ります。加えて、QLDB特有のジャーナルからの履歴取得やダイジェスト検証に依存していた処理は、移行先では別の仕組みへ置き換える設計が必要です。これらは影響範囲が広いため、移行対象の台帳ごとに、履歴の保持要件・検証要件・クエリの依存を洗い出してから着手する順序が安全です。

今から改ざん耐性や監査証跡が必要になった実装者が押さえる判断基準

ここでは判断を言い切ります。QLDBは新規に選べないため、論点は「台帳性の要件を、今あるサービスでどう満たすか」です。要件の強度に応じて、条件付きで構成を見極めてください。

台帳性や暗号学的検証が本当に必要になる要件かどうかの見極め方

暗号学的検証まで作り込む価値があるのは、履歴が改ざんされていないことを、自社の外部——監査法人や規制当局、取引相手——に対して証明する必要が明確にあるときです。金融・保険・サプライチェーンのように、記録の正しさが法令や契約上の要件として問われる領域が当てはまります。こうした要件なら、Aurora PostgreSQLへ移したうえで変更履歴テーブルとハッシュチェーンをアプリ層で組む、あるいはScalarDLのような専用の台帳機能を採る設計が見合います。AWS上でこうした移行や台帳基盤の設計を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、QLDBからの移行方針や検証レイヤーの設計、Auroraの構成の妥当性を相談するとよいでしょう。

通常のデータベースで足りる場面と過剰な設計を避けるための判断

一方で見送るべきなのは、「念のため履歴を残したい」程度の要件に、暗号学的検証まで組み込もうとする場面です。外部への証明が不要で、社内で変更履歴を追えれば足りるなら、通常のリレーショナルデータベースに監査ログやトリガーで履歴テーブルを設ける構成で十分で、検証の作り込みはかえって運用の重荷になります。要件を「履歴が残れば足りる」層と「改ざんされていないことを証明する必要がある」層に切り分け、後者に限って検証レイヤーを設計するのが、コストを抑える現実的な進め方です。QLDBが提供終了した今、単一のサービスで完結する台帳の選択肢は乏しいからこそ、要件の強度を先に定義してから技術を選ぶ——この順序を守れば、過剰な作り込みも要件の取りこぼしも避けられます。

よくある質問

Amazon QLDBとその移行について、実装者から多く挙がる質問を一次情報に基づいて簡潔に整理します。

Amazon QLDBは今も使えますか？

使えません。AWSは2024年7月25日にQLDBの新規顧客受け付けを終了し、2025年7月31日にサポートを終了しました。2026年時点ではサポート終了日を過ぎているため、新しい台帳を作成することはできず、既存利用者も移行を前提とした状態です。これから改ざん耐性のある記録基盤が必要なら、QLDBではなくAmazon Aurora PostgreSQLなどの移行先を検討することになります。

Amazon QLDBとブロックチェーンは何が違いますか？

信頼の置き方が異なります。QLDBは単一の信頼できる所有者が台帳を一元管理する中央集権のモデルで、その所有者を前提に履歴の改ざん耐性を担保します。ブロックチェーンは互いを信頼しない複数の参加者が合意形成で台帳を共有する分散モデルです。相互不信の当事者間で台帳を共有するならブロックチェーン、自社が所有者として履歴を管理し検証可能性だけ担保したいなら中央集権の台帳、という切り分けになります。

Amazon QLDBの移行先は何が推奨されていますか？

AWSはAmazon Aurora PostgreSQLへの移行を主軸として案内しています。Ion形式のドキュメントをリレーショナルへ置き換え、PartiQLを標準SQLへ書き換えて移す流れです。QLDBが備えていた暗号学的検証はそのままでは引き継がれないため、pgAuditやアプリケーション層での完全性検証で代替する形です。改ざん検知を保ちたい場合は、パートナー製品のScalarDLをDynamoDBやAuroraと組み合わせる選択肢もあります。

QLDBから移行するとき何に注意すればよいですか？

データモデルとクエリ、そして検証機能の3点です。Ionのドキュメント構造はリレーショナルへの正規化設計が要り、機械的な変換では済みません。クエリはPartiQLから標準SQLへ書き換えるため、アプリのデータアクセス層に手が入ります。さらにQLDBのジャーナルやダイジェスト検証に依存していた処理は、移行先で別の仕組みへ置き換える必要があります。台帳ごとに履歴・検証・クエリの依存を洗い出してから着手すると安全です。

監査証跡が必要なら必ず台帳データベースが要りますか？

いいえ、要件の強度で分かれます。履歴が改ざんされていないことを外部に証明する必要が明確にある場合は、暗号学的検証を伴う構成が見合います。一方、社内で変更履歴を追えれば足りるなら、通常のリレーショナルデータベースに監査ログや履歴テーブルを設ける構成で十分です。要件を「履歴が残れば足りる」層と「証明が必要な」層に切り分け、後者に限って検証レイヤーを設計するのが過剰投資を避ける進め方です。

関連記事

• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：QLDBの移行先として本命になるAurora PostgreSQLの仕組みと料金・採用判断を確認できる記事
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説：Auroraを含むマネージドRDBの対応エンジン全体と選び分けを整理した記事
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：台帳データベースを位置づける前提となるデータベースの種類と選び方を解説した記事