【セッションレポート】 生成 AI を活用したデータベースのスキーマ変換で移行を加速しようAWS Database Migration Service Schema Conversion（AWS-09） #AWSSummit

みなさんこんにちは、杉金です。
本記事は、2025年6月25-26日の2日間にわたって開催された AWS Summit Japan 2025 のセッションレポートです。

セッションはオンデマンドで視聴可能です。公開期限は2025年7月11日（金）19時までとなっておりますので、視聴される場合はお早めにアクセスしてください。

https://aws.amazon.com/jp/summits/japan/

セッション概要

AWS Database Migration Service (DMS) は、データベースと分析ワークロードを AWS に迅速、安全に、最小限のダウンタイムとデータ損失なしで移行するマネージドサービス。Amazon Bedrock で生成 AI を使用して、スキーマ変換の自動化を改善しており、これにより手作業や運用負荷が軽減され、Amazon Aurora や Amazon RDS などの完全マネージド型サービスへの移行が加速されます。このセッションでは、AWS がどのように生成 AI でデータベースの移行を変革しているか、生成 AI を使ったスキーマ変換の設計を Deep Dive します。 *本セッションはタイトルの変更を行いましたが内容に変更はありません（旧：生成 AI を活用した AWS Database Migration Service スキーマ変換により移行を加速しよう）

スピーカー

アマゾン ウェブ サービス ジャパン合同会社技術統括本部 デジタルサービス技術本部 デジタルネイティブソリューション部 ソリューションアーキテクト
馬 賽 氏

セッションレポート

AWS DMSの概要

最初に、馬氏よりAWS DMSの概要について語られました。DMSは主に4つの特徴があります。

• マネージドによる移行
• 幅広いオプション
• 高可用性
• 低コスト

DMSはマネージドサービスであるためDB移行を簡単に始められ、商用DBからオープンソースDBも含めてさまざまなDBエンジンをサポートしています。マルチAZ構成や移行時などで高い可用性を発揮し、レプリケーションを利用することで移行中でもDBの利用が可能です。移行ツールのようにライセンスを購入する必要はなく、コンピューティングとストレージのリソースを使用した分だけ利用料が発生します。日本含めた世界中のユーザーでDMSを使用した移行の実績があるようです。

DMSがサポートするソースとターゲット

次にDMSがサポートするソースとターゲットの一覧を紹介されました。スライドの代わりに、ユーザーガイドのリンクを貼ります。

対応しているソースDB

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.Sources.html

対応しているターゲットDB

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.Targets.html

馬氏は、スキーマ変換を行いたい場合にはいくつかの条件が存在するが、単純なデータ移行であれば幅広い製品をサポートしていると述べ、サポート対象の例として、OracleやSQLServer、NoSQLのMongoDBやCassandra、DocumentDB、分析系のS3などを挙げました。

DB移行における重要なポイント

続いて、移行プロセスの重要なポイントとして次の3点について語られました。

• 主要コンポーネント
• 移行の種類
• ダウンタイム

主要コンポーネントは、DBの構造やスキーマ、データやプロシージャ、関数などデータベースの動作を定義するものです。移行の種類は、同じDBエンジン間で移行を行う同種DB移行なのか、それとも異種DB移行なのかの違いです。ダウンタイムは、システム停止せずに移行するオンライン移行なのか停止時間を確保したオフライン移行なのかの違いで、サービスの要件によって決まります。これらのポイントを踏まえて、とるべき移行方法が変わってきます。

異種DB移行は筆者も思い出があり、スキーマ変換せずに単純移行するとテーブル名が大文字から小文字に変換されて、大文字小文字を区別するようになってアプリケーションからアクセスできなくなったという経験があります。異なるDBエンジンの仕様や振る舞いの違いには注意すべきところです。

AWS DMS Schema Conversion

異種DB移行では、スキーマの定義が異なるため、スキーマ変換を行う必要があります。スキーマ変換は、AWS DMS Schema Conversion（DMSSC）によって自動化できるケースが多いようです。DMSSCでは、移行元DBスキーマの評価と変換を行います。評価では、メタデータを使用してスキーマ変換の難易度を分析し、問題なければ同様のプロセスでスキーマ変換を行います。

AWS SCT vs. DMSSC

類似のツールであるAWS SCTとDMSSCの違い、使い分けを紹介しました。

• AWS SCT
  • デスクトップで使う無料ツール（ツールを動作させるローカルPCやサーバのパフォーマンスに依存する）
  • 多くのDBエンジンに対応している
• DMSSC
  • マネージドサービス（インストールやバージョン管理が不要）
  • 主にリレーショナルDBをサポート

DMSSCの機能は生成AIの機能含めて無料で利用できます。分析結果がS3に保存されるため、S3でわずかに料金が発生する程度だと語られました。マネージドサービスを利用してスキーマ変換からデータ移行まで行いたい場合はDMSSCの利用検討を推奨されました。

DMSSCの内部動作について

DMSSCの一連の処理フローをイメージするために、普段は知ることができない内部の動きについて解説されました。次の順序で処理されます。

1. ソーススキーマの読み込み
2. パーサに送信し変数定義やストアドプロシージャを分析
3. Abstract syntax tree（AST）の構築（ASTはソースコードを木構造で表現するもの）
4. リゾルバで、ローカル変数や他オブジェクトへの参照を解決する
5. Resolved source ASTを生成
6. コンバーターに送信（ターゲットASTに変換）
7. プリンタに送信し、抽象的なフォーマットからターゲットDBが理解できるフォーマットに変換する
8. ターゲットコードの生成

複雑な処理に見えますが、やっていることは変換されたスキーマの作成だけであると馬氏は語られました。AWS SCTも同様のスキーマ変換方法を取り入れているようです。セッションではASTのサンプルコードも披露されました。

DMSSCのデモ披露（生成AI機能なし）

SQLServerからAurora PostgreSQLへの変換を例にデモを披露されました。

まず、移行元であるソースDBのオブジェクトを表示し、その後に移行先であるターゲットDBを表示させて中身が空であることを示しました。今回のデモでは、ソースDBとターゲットDBの接続情報や基本的なネットワーク設定などは事前定義済みとしています。

最初にマネジメントコンソールから移行プロジェクトを作成しました。接続設定やIAMロールの指定などを行った後に、プロジェクトを選択してDMSSCを起動します。左右に画面が分かれ、左側がソースDBで右側がターゲットDBをの状態を表示します。スキーマ分析や変換は複雑度によって処理時間が変わるようです。デフォルトではすべてのDBが対象となりますが、DBの絞り込みが可能で、デモでは特定のDBだけ移行するよう指定していました。

評価ボタンをクリックすると、スキーマ変換の評価結果が表示されます。DBストレージオブジェクト、DBコードオブジェクトが画面に表示されます。DMSSCで変換できない場合、手動対応の推奨事項がアクションアイテムとして表示されます。評価レポートはPDFにエクスポートでき、チームや関係者に共有ができます。評価レポートには、自動変換の結果サマリや推奨事項などの詳細な情報が記載されるようです。

生成AIの活用を試行錯誤

DMSSCに生成AI機能を組み込むまでに、いくつかのパイロットプロジェクトを実施して最も効果的なアプローチを模索したと語られました。4つの試行錯誤が紹介されました。

• スキーマ全体を生成AIで変換する
• パラメータやデータ型を生成AIで変換する
• ソースコードの意図を生成AIで理解する
• パフォーマンスの改善

スキーマ全体を生成AIで変換する方法は、いくつかの問題点がありました。まず処理に時間がかかること、大量のトークンを使用するためコストがかかること、ハルシネーションで良い結果が得られないことなどが挙げられました。パラメータやデータ型を生成AIで変換する方法では、ある列に1桁の数字しかないのにDouble型を使っている場合に、intやtinyint型に変換できます。しかし、この問題点として、アプリで障害が発生することにつながるリスクがありました。ソースコードの意図を生成AIで理解する方法では、特定の関数やプロシージャが作成した人の意図を汲み取れるかは難しいという問題点がありました。パフォーマンス改善については、サブクエリの変換やインデックス付与などが含まれます。現状採用されていませんが、将来採用するかもしれないと語られました。

DMSSCの生成AI活用

試行錯誤を経て、DMSSCではスキーマ変換プロセスの後に生成AIを導入しているということです。DMSSCによるルールベースで変換できないものを生成AIを利用して変換するというアプローチを取っています。

これにはいくつかの考慮ポイントがあります。まず、コンテキストの理解として、DBスキーマ変換の話なのか別の処理なのかの理解が重要です。次に、不正利用防止のための難読化があります。Amazon Bedrockを裏で使用しており、Bedrockに送信するときは難読化しています。その他、LLMの選定、難読化の解除、結果検証、AST埋め込みなどが考慮されています。

難読化のサンプルとして、スキーマ名やテーブル名を取り出して難読化し、値まで難読化しています。Bedrockは安全に利用できるとのことですが、より安全性を高める措置として難読化の仕組みを取り入れています。

RAGの活用についても言及されました。コンテキストの把握にRAGを使用し、クエリを投げて類似した変換例を取得します。大量の変換ルールが埋め込まれており、プロンプトを作成して結果を得たら、難読化を解除する流れとなっています。

移行コンポーネントの全体像として、データ変換ではDMSSCを作って変換し、生成AI（Bedrock）を使用しています。現在はモデルとしてClaude Sonnetを使用しているとのことです。アプリケーション変換では、Q Developer Agentを使用し、スキーマがどのように変換されたかを把握してアプリケーション変換を行います。

生成AI機能を用いたDMSSCのデモ披露

2回目のデモでは、生成AIを活用してスキーマ分析、変換からデータ移行して、アプリケーションコードの変換と動作テストまでの一連の作業が紹介されました。

スキーマ変換では、生成AI機能を利用することで変換率が8%から85%に大幅に向上しました。変換結果を確認すると、生成AIで変換した部分についてコメントが付与されることが分かります。変換結果に問題がなければターゲットDBに反映するために適用ボタンを押します。その後にテーブルや関数、ビューなどが移行されたことを確認できます。この時点ではスキーマは存在しますがデータは存在せず、中身が空の状態です。その後にDMSでデータ移行を行います。

クエリをPostgreSQL用に置き換える際に、いくつかエラーが発生しました。少量のコードであれば手動で修正すればよいですが、大規模なコードだと修正が大変になります。そこでAmazon Q Codeを使用し、チャットで質問して生成されたコードを貼り付けます。Select文を実行して処理が成功することを確認しました。

アプリケーションコード（C#）からの動作確認では、手動でコードを変更し、ビルドしてエラーがないことを確認してアプリを実行しました。正常結果が返ってくることを確認して一連のデモを終えられました。

今後について

最後に馬氏より、DMSの今後について語られました。変換の精度とパフォーマンスの改善、変換可能なデータベースを増やすこと、生成AIは日々進化しており、新しいLLMモデルを評価し、より優れたモデルに更新し続けること、最後にDMSSCやSCTとAIを活用して変換可能な範囲を拡大していくことを語られました。

今回のツールはほぼ無償で利用できるので、ぜひ試してみて欲しいと呼びかけられました。

所感

かつてDMSを利用したDB移行を何度か経験していますが、久しく触っていないため最新の進化具合を知る良いきっかけになりました。印象的だったのは2つで、SCTとDMSSCの違いと生成AIを活用した変換です。SCTとDMSSCの違いは、両者の使い分け方にも及んでいたため、リレーショナルDBの異種DB移行ならまずはDMSSCを試してみようというイメージがつきました。生成AIの活用は、DMSSCで変換できない部分を拡張するための仕組みであり、かつ無料で利用できるため、変換結果を評価して上手くいかない部分があれば手動で対処する方法が一番手間なく済みそうだと感じました。