【セッションレポート】 AI エージェントで切り拓く次世代の Amazon Aurora への移行 ― コード変更の実践とお客様検証事例[DAT302]

はじめに

こんにちは。
クラウド事業本部コンサルティング部の阿部です。

AWS Summit 2026に参加してきました！人生初です。
今までこんなに大きな技術イベントに参加したことがなかったため、規模の大きさにびっくりしました。同時に、濃厚で有意義な2日間でした。

今回の記事では、Summit1日目に開催されたAWSのセッション「AI エージェントで切り拓く次世代の Amazon Aurora への移行 ― コード変更の実践とお客様検証事例」に参加したので、紹介したいと思います。

セッション概要（AWS Summit Japan公式サイトより）

セッションタイトル：AI エージェントで切り拓く次世代の Amazon Aurora への移行 ― コード変更の実践とお客様検証事例
スピーカー：長久保 武, ソリューションアーキテクト, AWS

商用データベースから Amazon Aurora への移行において、従来から多くのお客様にて SQL コード変換がブロッカーになってきました。数千行におよぶストアドプロシージャや、動的 SQL を含むアプリケーション SQL 等の手動変換に膨大な工数を要するために、エンジン変更を伴う移行を諦めるケースもございました。 そこで本セッションでは、AWS DMS によるルールベース変換と AI エージェントによる変換を組み合わせたアプローチを解説します。変換ルールやコーディング規約を自然言語で指示し、変換・テスト・突合を自動で繰り返すワークフローにより、従来ツールでは変換困難だったコードをどこまで自動化できるのかを具体的にお伝えします。 さらに、2 社のお客様検証事例を通じて、生成 AI 活用の効果を実際の数値結果と共にお話しし、セッション後すぐに PoCを始められるワークショップやサンプルスクリプトもご案内します。コード変換に対する新たなアプローチとして、ぜひご参加ください。

https://summitjapan.awslivestream.com/jpn-dat302/live/

セッション内容

本セッションは、OracleからPostgreSQLへのDB移行を題材としています。（OracleからのDB移行の問い合わせが多いらしいです）

DB移行の背景

データベースを移行する背景・理由の整理から、セッションが始まりました。
個人的には「ライセンス費用の削減」のイメージが強かったのですが、それ以外にもビジネス成長、セキュリティ面など、様々な背景があることを整理できました。

DB移行におけるブロッカー

本セッションは、4つの代表的なブロッカーのうち、技術面のブロッカーに焦点を当てた内容でした。

コード変換対象と変換アプローチについて

主な技術面の課題であるSQLコード変換について、変換対象と変換アプローチを提唱しています。

コード変換対象は2つに大別され、それぞれにあった変換アプローチをとるべきというのが上の図になります。

DMS（AWS Database Migration Service）による評価

DMSの「DB移行評価」についての機能が紹介されていました。

主に、以下を評価できるみたいです。

• DB移行先のDBエンジンごとの、自動変換率・移行難易度
• DB移行時の想定工数

オブジェクトタイプ毎の難易度も詳細に確認でき、DB移行の計画段階でこういった評価ができるのはとても有効だと思いました。

生成AIを活用したコード変換

ここからが、このセッションの本題になります。
DMSでは、プロシージャ等のコードオブジェクトは変換が難しいケースが多いです。ここで生成AI（KiroとStrands Agents）の登場です。

本セッションでは、Kiroを活用したコード変換イメージを取り上げていました。

SQLコード変換イメージ

こちらは、Oracle特有のNVL関数、(+) で表現される外部結合が含まれたサンプルSQLになります。

Kiroを活用して、SQL変換を行うと・・・

以下のように変換をしてくれます。

• NVL 関数 → SQL標準の**COALESCE 関数**に変換
• (+) で表現される外部結合 → LEFT JOIN に変換

変換時は、変換ポイントとその理由まで併せて提示してくれるみたいです！
（私はOracle詳しくないので（+）の外部結合すら知らなかった・・・）

動的SQLの変換イメージ

次に、動的SQL（アプリケーションのプログラムコードの中でSQLを動的に組み立てるSQL）のコード変換イメージです。
こちらは、アプリケーションコード（Java）のとある関数の中で、SQL文を条件分岐によって組み立てているサンプルです。

Kiroを活用して、SQL変換を行うと・・・

静的なSQLと同じように変換してくれるようです！

動的SQLは、完成形のSQLはアプリを実行してみないと確定しないため、従来のルールベースのコード変換（SCT）では変換が難しいです。これが理由で、DBエンジン変更を断念するケースも多いみたいです。

生成AIを活用することで、アプリケーションコードの文脈を理解できるため、動的SQLでも変換が可能になるという訳です。ここは、生成AIのメリットを大いに生かせるポイントだと感じました！

コード変換時の「基本指針プロンプト」

変換精度を上げるために、以下のようなプロンプトであらかじめ指針を与えるのが効果的とのことでした。

大量コードは「自動一括変換フロー」で

上記で紹介されたコード変換はあくまで対話形式なので、数千ものコードに対しては変換しきれないのでは？と思うところですが、そこで紹介されたのが、6ステップの自動化された変換フローです（DBオブジェクトの例）。

この変換フロー自体を自然言語のプロンプトで指示するということろがポイントでした。

テストのやり方も、自然言語で指示することができます。

アプリケーションSQLの自動変換フローについても、DBオブジェクトとほぼ同様です。
（最初のDDL抽出がSQL抽出に変わるだけ）

ただ、ソースコードが大量になり過ぎると、コンテキストあふれによってSQL抽出が難しくなる場合があるとのことです。その対策として、コードの静的解析ツールを使って「SQLがどのファイルの何行目にあるか」を特定して、その情報を生成AIに渡すのが有効だそうです！

お客様検証事例

Oracle→Aurora PostgreSQLのDB移行について、お客様事例がいくつか紹介されていました。
どの事例にも、従来のルールベースでの変換（SCT）が困難なDBオブジェクトやアプリSQLがあるという共通の技術課題を持っていました。これに対し、生成AIを活用することで、どの程度工数削減ができたか？どれくらいのコード変換率を達成できたか？が定量的に語られていました。

ハルシネーションのリスク

本セッションのDB移行に限った話ではないと思いますが、生成AIを使う以上、ハルシネーションのリスクがあることは念押ししていました。

まとめ（聴いてみての感想）

• そもそもですが、DB移行においてどのような技術課題があるのか？イメージできてなかったので、まずそこが理解ができて良かったです。
• 生成AIを活用することで、完全に100%コード変換できるわけではないけど、かなりの工数削減は狙えるのでは？と思いました。
• アプリケーションSQL（動的SQL）は、完成形のSQLではなくプログラムコードそのものを渡すことでSQLコード変換ができるのは、生成AIを活用するかなりのメリットだと感じました。
• 一方、ハルシネーションのリスクも考えると、コード変換後はそれなりの動作検証が必要がありそうだなと感じました。
• とはいえ、テスト含めた自動一括変換フローも組み込むことで、全体的な工数削減は大幅に達成できそうな印象を持ちました。
• セッションの最後に紹介していたコード変換の公開サンプルスクリプト、是非試してみたいなと思います。