7月30日、InfoWorldが「New Databricks tool uses AI agents to rewrite legacy SQL at scale」と題した記事を公開した。Databricksが発表したAIエージェントベースの新ツールは、レガシーSQL移行プロジェクトで長年「最後の壁」とされてきた再帰CTE・動的SQL・カーソルといった複雑なコードを、意味的な理解をもとに自動変換する。単純な構文置換にとどまる従来のトランスパイラでは歯が立たなかった領域に、AIエージェントが踏み込んだ形だ。
レガシーSQL移行の「最後の10%」をAIが担う
データ基盤の移行プロジェクトにおいて、SQLの書き換えは長年にわたってエンジニアを悩ませてきた。T-SQL（SQL Server）、Teradata、OracleといったレガシーDBのSQLをDatabricks環境へ移行する際、単純な構文変換は既存の「トランスパイラ」でも処理できる。しかし問題は残りの**10〜15%**だ。
ITコンサルティング企業KanerikaのチーフアナリティクスオフィサーであるAmit Chandak氏はこう指摘する。
「決定論的なトランスパイラは、日付関数やJOIN構文、パターン対パターンの単純な変換には強い。しかし、制御フローの推論、カーソル、実行時に動的に組み立てられるSQL、T-SQL・Teradata・Oracleでそれぞれ異なる実装の再帰CTE——こういったものには途端に脆くなる」
さらにChandak氏は「これは私が関わってきたすべての移行案件で、手作業による修正時間の大半を食っている、例の10〜15%と全く同じ問題だ」と続ける。まさにこの「最後の壁」に対して、Databricksが新たなアプローチを打ち出した。
決定論的トランスパイラとAIエージェントの違い
従来のトランスパイラは、構文ルールをあらかじめ定義しておき、パターンマッチングで変換を行う決定論的なアプローチだ。シンプルなSQLには有効だが、動的SQLや再帰CTE（Common Table Expression：共通テーブル式）のようにロジックが複雑に絡み合うコードには対応しきれない。カーソルを使ったループ処理や、実行時に文字列として組み立てられる動的SQLも同様で、静的なパターン定義では変換ルールを網羅しきれないためだ。
Databricksが発表した新ツールは、AIエージェントを用いて変換を行う。エージェントベースのアプローチでは、単なるパターン置換ではなく、コードの意味的な理解をもとに変換処理を実行できる点が大きな差となる。元記事によれば、ツールの固有名称は明示されていないが、AIエージェントが変換フローを自律的に判断・実行する構成をとっているとされる。アナリストらによれば、この違いが企業の大規模移行プロジェクトにおいて実質的なコスト削減につながる可能性を持つという。
なぜ今このツールが注目されるのか
背景にあるのは、多くの大企業がいまだにTeradata、Oracle、SQL Serverなどのレガシーデータウェアハウスを抱えているという現実だ。クラウドネイティブなデータレイクハウス基盤への移行需要は高まっているが、移行コストの大部分を占めるのがSQL資産の書き換え作業である。
既存の決定論的トランスパイラは、変換可能な部分を高速・低コストで処理できる一方、残る複雑なコードには人手が必要だった。なお、元記事ではMorpheusへの言及もあるが、Databricksのデータ移行関連製品ページとの対応関係は元記事の記述のみに基づいて判断されたい（※編集部の考察：MorpheusはDatabricksが提供するSQLトランスパイラとして知られており、今回の新ツールはその補完的な位置づけにある可能性がある）。AIエージェントによる自動化がこのギャップを埋められるなら、移行プロジェクト全体のコストと期間に直結する話になる。
Databricksをめぐっては、2025年の新機能発表が相次いでおり、AIエージェント活用はデータエンジニアリング領域でも加速しつつある。レガシー移行の自動化はその流れの中でも、現場の痛点に直接刺さる用途として注目度が高い。
ツールの動作と対応するSQL構文
元記事が言及する変換対象の「難所」は以下の通りだ。
- 再帰CTE——T-SQL、Teradata、Oracleでそれぞれ実装が異なり、パターンマッチングで網羅するのが困難
- 動的SQL——実行時に文字列として組み立てられるため、静的解析では変換ルールを適用できない
- カーソル——行単位の反復処理であり、セット指向のSpark SQLへの意味的な読み替えが必要
- 制御フローの推論——IF/WHILE/EXECなどの手続き型ロジックをSpark環境に対応した形へ変換する
これらはいずれも「構文を置き換える」のではなく「ロジックを理解して書き直す」必要があるコードだ。AIエージェントが意味的な理解をもとに変換できるとすれば、従来は人手に頼るしかなかったこれらのケースを自動化できることになる。
エンジニアが押さえるべきポイント
- 変換対象の「難所」は再帰CTE、動的SQL、カーソル——これらは既存ツールで自動化できず、手作業対応が常態化していた
- AIエージェントは構文ではなくロジックを理解して変換する——決定論的ツールとの本質的な違いはここにある
- 10〜15%の難所が移行コストの大半を占める——Chandak氏の指摘は、現場経験に基づいた数字として重い
- ツールの固有名称は元記事に明示されていない——続報や公式アナウンスを待つ必要がある
詳細はNew Databricks tool uses AI agents to rewrite legacy SQL at scaleを参照していただきたい。
