Oracle Database から Amazon Aurora PostgreSQL への移行を加速する生成 AI エージェント

本ブログは三菱電機ビルソリューションズ株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。

多数のシステム群のクラウド移行を検討されている三菱電機ビルソリューションズ様の実際の課題と、生成 AI を活用した解決策を共有することで、同様の課題に直面している企業の皆様にとって参考となれば幸いです。

三菱電機ビルソリューションズが直面したDB移行の課題

企業のデジタルトランスフォーメーションが加速する中、三菱電機ビルソリューションズでもクラウド化に向けた活動を推進しています。その取組みの一つとして、オンプレミスの Oracle Database からクラウドネイティブな Amazon Aurora PostgreSQL への移行を検討しています。

データベース移行には、スキーマ変換、データ移行、アプリケーションコードの修正など、多岐にわたる作業が必要になります。 このうち、スキーマ変換については、AWS Database Migration Service Schema Conversion (AWS DMS SC) や AWS Schema Conversion Tool (AWS SCT) が強力な支援ツールとして機能します。これらのサービスはテーブル定義、インデックス、ビューなどの多くのデータベースオブジェクトを自動的に PostgreSQL の形式に変換でき、移行プロジェクトの効率化に大きく貢献しています。

しかし、すべてのデータベースオブジェクトが自動変換できるわけではありません。特に、複雑なビジネスロジックを含む PL/SQL で書かれたストアドプロシージャやファンクション、パッケージなどは、Oracle Database 固有の機能や構文を多用しているため、AWS SCT でも完全な自動変換が困難なケースが存在します。

三菱電機ビルソリューションズにおける今回の取組みでは、AWS SCT で自動変換できないオブジェクトの変換だけで約200人月の工数が必要と見積もられており、移行プロジェクトのボトルネックとなっていました。 そこで三菱電機ビルソリューションズと AWS 生成 AI イノベーションセンターは共同で、Amazon Bedrockを活用した生成 AI エージェントによるコード変換ソリューションの検証を実施しました。

検証の過程で複数のソリューションを開発しましたが、その中で本ブログでは汎用性の高い Amazon Bedrock と Strands Agents を活用した生成 AI エージェントによる変換ソリューションをご紹介します。このソリューションにより、PL/SQL オブジェクトの自動変換を実現し、移行プロジェクトを大幅に効率化できました。

Strands Agents + 専用ツール群による包括的アプローチ

今回私たちが開発したソリューションでは、Strands Agents に実際のデータベース操作や変換作業に必要な具体的なツール群を提供することで、生成 AI によるデータベースオブジェクトの変換を可能にしています。また、コード変換だけでなく、基本的なテストケースの自動生成と結果比較の機能も組み込むことで、変換品質の向上を図っています。

従来の「コード生成のみ」のアプローチと異なり、このソリューションはテスト用のデータベース環境での基本的な動作確認まで自動化しています。これにより、単なる構文変換レベルを超えた「基本動作確認済みの変換」を実現し、移行後の品質リスクを軽減しています（ただし、これらの自動テストは網羅的ではなく、本番環境への適用前には人間の専門家による追加検証が必要です）。

次に、具体的なエージェントの仕組みを説明します。

提供ツール群の詳細

AI エージェントには主に下記の３種類のツール（MCP サーバー）を与えています。エージェントはプロンプトで指示された作業フローと、実際の作業状況を踏まえて、いつどのツールを利用するか柔軟に判断します。

1. データベース接続・操作ツール

• Oracle Database 接続ツール: 対象オブジェクトの DDL 取得、依存関係確認、テスト実行
• PostgreSQL 接続ツール: 変換後 DDL の投入、構文チェック、テスト実行

2. ファイル操作ツール

• ファイル読み書きツール: DDL、テストコード、実行結果の保存・読み込み

3. システム実行ツール

• シェルスクリプト実行ツール: 複雑なデータベース操作やバッチ処理の実行

こちらは Strands Agents によるエージェント実装のサンプルコードです。ファイル操作ツールは Strands Agents Tools ライブラリで提供されています。また、データベース接続・操作ツールとシステム実行ツールは自作の MCP サーバーを利用しています。

import json
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
from strands import Agent
from strands.tools.mcp import MCPClient
from strands_tools import file_read, file_write

from utils.callbacks import AgentCallbackHandler
from prompts.prompts import get_system_prompt


def load_mcp_config():
    """MCP設定ファイルを読み込み"""
    with open("mcp.json", "r") as f:
        return json.load(f)


def create_mcp_client():
    """MCP クライアントを作成"""
    config = load_mcp_config()
    server_config = config["mcpServers"]["sql-converter"]

    return MCPClient(
        lambda: stdio_client(
            StdioServerParameters(
                command=server_config["command"],
                args=server_config["args"],
                env=server_config.get("env", {}),
            )
        )
    )


def create_agent(mode="db_object"):
    """エージェントとMCPクライアントを初期化"""

    system_prompt = get_system_prompt(mode)

    mcp_client = create_mcp_client()

    with mcp_client:
        mcp_tools = mcp_client.list_tools_sync()
        all_tools = [file_read, file_write] + mcp_tools

        agent = Agent(
            system_prompt=system_prompt,
            tools=all_tools,
            callback_handler=AgentCallbackHandler()
        )

        return mcp_client, agent

こちらは Oracle Database に接続するツールを提供する MCP サーバーのサンプルコードです。 FastMCP で MCP サーバーを作成し、@mcp.tool() で定義した run_ora_sql 関数を Strands Agents から呼び出せるツールとして公開しています。 内部では python-oracledb ドライバを使って Oracle Database に接続し、SQL クエリを実行、結果を取得しています。

from mcp.server.fastmcp import FastMCP
import oracledb

mcp = FastMCP("sql-converter")


@mcp.tool()
def run_ora_sql(sql):
    """
    Execute SQL query on Oracle database.

    Args:
        sql (str): SQL query to execute on the Oracle database.

    Returns:
        list: Query execution results from the Oracle database.
    """
    return oracle_execute(sql)


def oracle_execute(sql):
    """
    Execute SQL query on Oracle database.

    Args:
        sql (str): SQL query to execute on the Oracle database.

    Returns:
        list: Query execution results from the Oracle database.
    """
    logger.info(f"Executing: {sql}")
    response = execute_query(sql)
    logger.info("Query completed")
    return response


def execute_query(sql):
    """
    Execute SQL query on Oracle database.

    Args:
        sql (str): SQL query to execute

    Returns:
        list: Query execution results

    Raises:
        Exception: If query execution fails
    """
    credentials = get_db_credentials()
    connection = None
    cursor = None
    try:
        connection = oracledb.connect(
            user=credentials["user"],
            password=credentials["password"],
            dsn=credentials["dsn"],
        )
        cursor = connection.cursor()
        cursor.execute(sql)
        (以下省略)   

変換・検証の流れ

これらのツールを用いて、エージェントは以下の包括的な処理を自動実行できます。

Phase 1: Oracle Database 環境での分析・テスト

1. Oracle Database に接続し、対象オブジェクトのDDLを取得
2. 依存関係（パッケージ、関数、型など）を確認
3. Oracle Database でのテストデータ作成とテストコード生成
4. Oracle Database 環境でテスト実行し、結果を記録

Phase 2: PostgreSQL 変換・検証

1. PostgreSQL に依存関係が定義されているか確認
2. Oracle Database のDDLを PostgreSQL に変換
3. PostgreSQL 環境で構文チェックとオブジェクト作成

Phase 3: 品質確保・結果比較

1. PostgreSQL 環境でのテストデータ・コード生成
2. 同一テストケースでの PostgreSQL 実行
3. Oracle Database 実行結果との詳細比較・検証
4. 差異分析と最終的な成功/失敗判定

技術的工夫ポイント

1. AWS DMS SC による変換結果利用

生成AIは強力なツールですが、すべてのタスクを任せる必要はありません。PostgreSQL にテーブルが定義されていない場合でも類推してテーブルを作成することも可能ですが、 AWS DMS SC により Oracle Database から PostgreSQL にテーブルを事前に変換・定義しておくと、より効率よくオブジェクトの変換を進めることができます。

2.マルチエージェントでの責務分割

シンプルなデータベースオブジェクトであれば1つのエージェントですべての手順を正しく実行できますが、より複雑で長いコードになると単一エージェントでは処理能力の限界が見られました。具体的には、一部の実装を簡略化したり、無意味なテストを作成してしまうなどの問題が見られました。

この問題を解決するため、以下の3つのエージェントによる分業体制を検討しました。

1. Oracle 検証エージェント：Oracle Database でのテスト作成と実行を担当
2. PostgreSQL 変換エージェント：Oracle DDL から PostgreSQL への変換とシンタックスチェックを担当
3. PostgreSQL 検証エージェント：変換後の PostgreSQL コードに対するテスト作成・実行とテスト結果の比較を担当

この分業アプローチにより、各エージェントが専門領域に集中できるようになり、変換の精度と効率を改善することができました。

3.段階的な変換

移行対象のオブジェクトの中にはコード行数が数千行にも及ぶ巨大なプロシージャやパッケージも含まれました。 このようなオブジェクトについては、全体をまとめて変換するのではなく、機能的なまとまり（内部プロシージャ・関数など）ごとに変換することで、変換の精度を改善することができました。

別のアプローチ

プロジェクト初期段階では、生成 AI にコード変換やテスト生成を担わせつつ、全体のワークフローは決定的に定義するアプローチも検討しました。固定ワークフローは、特定のデータベース環境や移行パターンに最適化すれば、処理速度や動作の確実性の面でエージェントより優れた結果が得られる可能性があります。

一方で、依存関係の処理、コード変換、テスト生成・実行、エラー発生時のリトライといった複雑なフローを正確に作り込むには多くの開発工数がかかります。また、プログラムが複雑化するとメンテナンス性の課題も生じます。

検討の結果、三菱電機ビルソリューションズのプロジェクトでは多様なデータベースオブジェクトへの対応力と将来的な拡張性を重視し、エージェント型アーキテクチャを活用していく方針となりました。

生成AIによる変換結果

私たちが開発した生成 AI による変換ソリューションにより、AWS SCT による自動変換が不可だったオブジェクトのうち約90％を AI エージェントにより自動変換できました。また、簡易的にではありますが、Oracle Database と PostgreSQL においてテストを実行し結果の合致を確認することで、一定の動作確認もできました。AI エージェントの利用により、データベースオブジェクトの変換が大幅に効率化できることを示しています。

ただし、生成 AI を活用したコード変換に際しては、ハルシネーションのリスクに留意した上で、従来の手動変換と同様、十分なテスト期間を設けた網羅的なテスト実施が重要です。全てのプロシージャや SQL 等が生成 AI で変換できる訳ではないことを念頭に、生成 AI で変換された SQL で正しい結果が得られるか、性能面で要件を満たせるか別途確認する必要があります。

今回の検証結果を受けて、三菱電機ビルソリューションズでは今後の移行プロジェクトにおいても、AIエージェントの活用を検討しています。

なお、今回ご紹介したエージェントのサンプルコードはこちらのGitHubリポジトリで公開しているので、ぜひ試してみてください。

著者について