本記事は 2026 年 6 月 4 日 に .NET on AWS Blog で公開された「 AWS Transform SQL Server to PostgreSQL Schema Validation in .NET Application Modernization 」を翻訳したものです。 本記事の執筆には Sayan Ghosh、Yuhao Zhang、Uday Kiran Erukulla、Srinivasa Varadan Saragur Madabhushi、Koushik Rajagopal、Khurram Khawaja、Vikas Babu Gali、Luke Huan が協力しました。 Microsoft SQL Server から Amazon Aurora PostgreSQL – Compatible Edition へのデータベース移行は、ライセンスコストの削減、スケーラビリティの向上、オープンソースデータベース技術の活用を目指す組織にとって一般的なモダナイゼーション戦略です。ただし、SQL Server データベースを Aurora PostgreSQL に移行する際、スキーマ変換はあくまで出発点に過ぎません。真の課題は、すべてのテーブル、制約、ストアドプロシージャ、トリガーが正しく移行され、移行先の PostgreSQL 環境でも同一の動作をすることを検証する点にあります。小数精度の変更をひとつ見落としたり、ストアドプロシージャの変換に誤りがあったりするだけで、本番環境でデータ破損やアプリケーション障害、ビジネスロジックの誤動作を招くおそれがあります。 手動でのスポットチェック、スモークテスト、単純な行数比較に頼る従来の移行テストでは、こうした微妙な意味の違いを捉えられません。オブジェクトが存在するかどうかだけでなく、機能的に等価であるかまで検証する体系的なアプローチが必要です。 この記事では、 AWS Transform が構造分析、意味検証、動作テストを組み合わせた 3 層の検証モデルによって、SQL Server から PostgreSQL への移行に対する包括的なスキーマ検証を実現する仕組みを紹介します。あわせて、 Amazon Bedrock を活用した AI エージェントが検証結果を分析し、根本原因ごとに問題をまとめ、重大度を判定して修正の優先順位付けを支援する流れも解説します。 ソリューション概要 AWS Transform のスキーマ検証は、移行元と移行先の両方を稼働中のデータベースエンジンにデプロイし、そこに対して直接チェックを実行することで、移行済みデータベーススキーマの検証をエンドツーエンドで自動化します。この検証は移行先スキーマの作り方に依存しません。ルールベースのツール、エージェンティックなソリューション、独自に構築した生成 AI (GenAI) 変換パイプラインのいずれで生成したスキーマにも適用できます。図 1 は、移行元と移行先のスキーマが検証ワークフローをどのように流れるかを示しています。 図 1. エンドツーエンドのスキーマ検証ワークフロー 図 1 のとおり、検証は以下の流れで進みます。 移行元の SQL Server スキーマと移行先の PostgreSQL スキーマを、それぞれ専用の Amazon Elastic Container Service (Amazon ECS) コンテナに読み込む 両方のスキーマが Tier 1 (構造的検証) に入り、検証ワークフローが各オブジェクトが移行先に存在するかをプログラムでチェックする 構造チェックを通過したオブジェクトが Tier 2 に進み、意味的な等価性を比較する 意味チェックを通過したストアドプロシージャが Tier 3 (動作検証) に進み、ランタイムでテストする 各 Tier がオブジェクトごとの判定 (PASS、FAIL、または WARNING) を出力し、スコアリング層に集約される エキスパートアセスメントエージェントがすべての判定を確認し、両方の稼働中データベースにクエリを発行してフラグの立った問題を裏付ける。その後、検出内容を根本原因ごとにまとめ、重大度を判定し、最終的な本番移行準備レポートを生成する ウォークスルー このワークフローは、内部的には以下の 5 つのステップとして実行されます。 移行元 SQL Server と PostgreSQL の検証コンテナを Amazon ECS 上で起動する 移行元と移行先のスキーマを、対応する検証用データベースに読み込む 両方のデータベースにクエリを発行してルールベースのチェックを実行する Amazon Strands Agents を使って AI エキスパートによる分析を実行する 最終的な検証レポートを生成する この検証は 2 つの原則に基づいています。 正規表現による解析ではなく、稼働中のデータベースを使う 。バリデーターは稼働中の各データベースに直接クエリを発行します。生の SQL ファイルの記述内容ではなく、エンジンが実際に解釈した内容を報告します。 決定論的な処理を先に、LLM は後に 。ルールベースのチェックを大規模言語モデル (LLM) 層より前に実行し、LLM にはフィルタリング済みの入力を渡します。これにより LLM は決定論的なシグナルを置き換えるのではなく、補強する役割を担います。 これらの原則のもと、ルールベースのチェックと AI 分析は以下のように動作します。 1. 構造的検証 (Tier-1) 目的 : 移行元スキーマのすべてのデータベースオブジェクトが移行先スキーマに存在することを検証する この Tier では、移行元と移行先の両方のデータベースに直接クエリを発行し、すべてのスキーマオブジェクトに対してルールベースの存在チェックを並行して実行します。以下の表に例を示します。 オブジェクトタイプ チェック内容 テーブル 各テーブルが移行先に存在し、列と NULL 許可のルールが一致することを確認する 制約 主キー、外部キー (カスケードルールを含む)、一意制約、CHECK 制約を検証する 構造の照合で見落としやすい課題が、名前の正規化です。SQL Server は既定で大文字小文字を区別しませんが、PostgreSQL は引用符で囲まない識別子を小文字に折りたたみ、大文字小文字を区別して扱います。さらに PostgreSQL は識別子を 63 バイトで切り詰めます。そのため、SQL Server 上では別名だった 2 つのプロシージャが PostgreSQL 上では同じ名前に統合されることがあり、正しく移行できたテーブルが単純なバイト単位の比較では不一致と判定されてしまいます。これを避けるため、構造の照合では大文字小文字の折りたたみ、切り詰め、引用符の除去という段階を踏んで名前を正規化し、各段階でレコードの正規化を適用します。 2. 意味的検証 (Tier-2) 目的 : 移行したオブジェクトが構造として存在するだけでなく、意味的に等価であることを検証する Tier 1 がオブジェクトの存在を確認するのに対し、Tier 2 はその定義が意味的に等価かどうかをチェックします。チェックはルールベースで、SQL Server と PostgreSQL の型システム間の型マッピングと精度のルールを組み込んでいます。以下に例を示します。 チェック 例 型マッピング nvarchar(100) から character varying(100) への変換は有効。integer への変換は無効 数値精度 decimal(18,2) は numeric(18,2) のままである必要があり、numeric(10,0) では不可 意味チェックが等価性を捏造することはありません。正規化できない場合 (既定値に互換性がないなど) は、黙って修正を適用するのではなく WARNING を出します。これにより、不要なアラートを増やさずに本番環境での問題を防げます。 3. 動作検証 (Tier-3) 目的 : ランタイムの動作が期待どおりであることを確認する Tier 2 で定義を検証したうえで、Tier 3 では実際のランタイム動作をテストします。2 つのルーチンが構造チェックと意味チェックの両方を通過しても、スタブ、分岐処理のバグ、変換で失われる方言固有の機能などが原因で、異なる結果を返すことがあります。こうした問題を洗い出すため、動作検証は次の 3 ステップで段階的に踏み込みます。 ステップ 1: スタブの検出 バリデーターは、PostgreSQL 側のルーチン本体が意味のある実装になっているか、それとも BEGIN RETURN 0; END のようなプレースホルダーのロジックだけかを調べます。スタブの生成は自動変換で最も起こりやすい失敗パターンのひとつなので、最初に検出しておくことで後続ステップの無駄な作業を防げます。 以下は、変換時に AI エージェントが SQL Server プロシージャから生成した PostgreSQL のスタブの例です。 SQL Server プロシージャ : --SQL Server procedure CREATE PROCEDURE BabelFish.bf_collationproperty @collation_name SYSNAME = 'Traditional_Spanish_CS_AS_KS_WS', @prop_name VARCHAR(255) = 'CodePage' AS BEGIN SELECT COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'CodePage') AS 'CodePage' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'LCID') AS 'LCID' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'ComparisonStyle') AS 'ComparisonStyle' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'Version') AS 'Version'; END; PostgreSQL のスタブプロシージャ : --PostgreSQL stub procedure CREATE OR REPLACE PROCEDURE babelfish.bf_collationproperty(IN collation_name varchar(128) DEFAULT 'Traditional_Spanish_CS_AS_KS_WS', IN prop_name varchar(255) DEFAULT 'CodePage') LANGUAGE plpgsql AS $body$ BEGIN RAISE NOTICE 'Stub: babelfish.bf_collationproperty - needs manual T-SQL to PL/pgSQL conversion'; END; $body$; ステップ 2: 構造の検証 バリデーターは両側のルーチンのシグネチャ、入出力パラメータ、戻り値の型を検査し、移行後のアプリケーションで呼び出しエラーを引き起こす構造の不一致を特定します。 ステップ 3: ミューテーションテストと LLM による評価 バリデーターはテスト入力を生成し、両方のデータベースに対して実行して結果を比較します。行レベルで 1 件でも差異があれば、それが 2 つのルーチンが等価でないことを示す具体的な反例になります。ミューテーションテストで判断がつかない場合は、Amazon Bedrock を通じた LLM による評価で機能的な等価性を判定し、最終的な結論を出します。 4. スコアリング 各チェックは、オブジェクトごとに PASS/FAIL または WARNING を出力します。レポートには 決定論的な 2 つの主要スコア が示され、同じ入力であれば実行ごとに同じ値になります。 Storage Score – データを保持するオブジェクト (テーブル、インデックス) 全体でのスキーマの一貫性を測る Code Score – 実行可能なオブジェクト (ビュー、ストアドプロシージャ、関数、トリガー) 全体での機能カバレッジを測る この 2 つの数値で移行のカバレッジを素早く把握できますが、最終的な評価を決めるのはこれらではありません。それを担うのが AI ジャッジ ( LLM-as-a-Judge )です。これは、エキスパートレビュワーとして振る舞う Amazon Strands Agents です。ルールベースのチェックが答えるのは「何が違うのか」です。これに対して AI ジャッジが答えるのは「それは重要なのか、どう直すべきか」です。 この AI ジャッジは両方の稼働中データベースに読み取り専用でアクセスでき、フラグの立った問題を裏付けたり否定したりするために自ら検証クエリを発行できます。そのうえで、この Strands Agents が検出内容を根本原因ごとのクラスターにまとめます。たとえば、スキーマがひとつ欠けていることが原因で 29 個のトリガーが欠落している場合、29 件ではなく 1 件のクラスターとして扱われます。各クラスターには次の重大度が割り当てられます。 重大度 基準 CRITICAL ユーザーデータの損失または破損 HIGH 将来的に気づきにくい障害が起きる、またはアプリケーションからの呼び出しが失敗する MEDIUM アプリケーションが意図どおりに動作しない可能性がある LOW 表示上の問題で、動作を妨げない 根本原因ごとにまとめるこのアプローチでは、影響を受けたオブジェクトを個別に列挙するのではなく、大元の問題に対処するためノイズが減ります。共通の原因を修正すれば、そこから派生したすべての症状が一度に解消します。 本番移行準備の判定ルール Critical の検出があれば、他のスコアに関わらず本番デプロイをブロックする High のクラスターがあれば条件付きの準備完了となる (追加の検証が必要) Medium と Low の問題は、Critical や High のブロッカーを上書きしない まとめ SQL Server から PostgreSQL への移行は影響範囲の大きい変更であり、テストに合格したというだけでは正しさの証明にはなりません。AWS Transform の 3 層検証ワークフローは、その主張を監査可能な成果物に変えます。Tier 1 ですべてのオブジェクトが移行できたことを確認し、Tier 2 で個々のオブジェクトが意味的に等価であることを確認し、Tier 3 でルーチンが同じ結果を返すことを実際に検証します。さらに AI ジャッジである Amazon Strands エージェントが検出内容を根本原因ごとにまとめ、重大度にもとづいた評価を出すため、主要スコアが高いだけで重大なデータ損失の問題が見過ごされることはありません。 まずは最初のスキーマ移行の検証を AWS Transform で試してみてください。詳細は以下のリソースをご覧ください。 AWS Transform Amazon Aurora PostgreSQL Amazon Bedrock Amazon Strands Agents 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Amit Kachroo Dr. Amit は、Amazon Agentic AI Science チームのシニアアプライドサイエンティストとして、コード変換のための生成 AI および LLM システムを構築しています。さまざまなプログラミング言語やデータベースに対応した変換機能を開発するサイエンスチームを率いています。詳しくは https://amitkac.github.io/ をご覧ください。 Vijay Mandadi Vijay は、AWS Migrations and Modernizations グループのエンジニアリングリーダーです。分散システム、クラウドコンピューティング、仮想化、ワークロード変換、ヘルスケアの分野で 16 年以上の経験を持ちます。AWS では、生成 AI とエージェンティック AI を活用して、お客様のアプリケーションワークロードのモダナイゼーションとクラウドネイティブ化を加速することに取り組んでいます。 Nits Jeganathan Nits は、AWS Transform のプロダクトリーダーです。IT 業界で 15 年の経験を持ち、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションの分野で 12 件の特許と 2 件の論文があります。複雑な課題の解決とカスタマーエクスペリエンスの向上に情熱を注いでおり、現在は生成 AI を使ったレガシーアプリケーションのモダナイゼーション加速に注力しています。

このブログは、2026 年 8 月 3 日に公開された「  Modernize SQL Server databases to Aurora PostgreSQL using AWS Transform  」を翻訳したものです。 はじめに SQL Server データベースの Aurora PostgreSQL へのモダナイゼーションは、始める前から停滞することがよくあります。インフラストラクチャーのセットアップ、ネットワーク構成、資格情報の共有、セキュリティレビューといった準備作業に何週間もかかり、移行の中身を評価する段階にすらたどり着けないのです。 AWS Transform フルスタック Windows モダナイゼーション  の Offline Source を使用すると、こうした障壁を飛び越えて、SQL Server データベースのスキーマファイルをアップロードするだけで Microsoft SQL Server データベースの  Amazon Aurora PostgreSQL-Compatible Edition  (Aurora PostgreSQL) へのモダナイゼーションを開始できます。 SQL Server 環境を管理していて、始めるまでの複雑さからモダナイゼーションを先送りにしてきた方に、ぜひ読んでいただきたい記事です。Offline Source がインフラストラクチャーの事前準備をどのように不要にするか、.NET アプリケーションコードのアセスメントを含む変換ワークフローがエンドツーエンドでどのように動くか、そして SQL Server スキーマの DDL エクスポートから、変換済みアプリケーションコードを伴う検証済み Aurora PostgreSQL スキーマに至るまでの流れを解説します。 課題: アセスメント前のインフラストラクチャー要件 SQL Server データベースのモダナイゼーションアセスメントには従来、以下が必要でした : ソースデータベースと変換ツール間のネットワーク接続 ソースサーバーへの資格情報の共有またはエージェントのインストール スキーマ分析のための中間環境のプロビジョニング 厳格なセキュリティポリシー、規制環境、または企業ファイアウォールの背後にあるデータベースを持つ組織にとって、アセスメント作業を始める前の段階でこれらの前提条件だけでモダナイゼーションプロジェクトが数週間から数か月遅れることもありました。 ソリューション概要 AWS Transform  の Offline Source を使用すると、標準的な Data Definition Language (DDL) エクスポートファイルからソースデータベースの構造を再現できます。稼働中の SQL Server インスタンスに接続する必要はなく、 DDL をアップロードするだけで AWS Transform がアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行します。インフラストラクチャーの事前準備は一切不要です。 図 1: AWS Transform Offline Source ワークフロー ワークフローは 5 つのステージで構成されます : データベースアセスメント : データベースオブジェクトの複雑さ、依存関係、作業量レベルを分析 スキーマ変換 : SQL Server オブジェクトの PostgreSQL への LLM ベースの変換 検証 : 3 層の検証 (構造的、意味的、機能的) デプロイ : 検証済みスキーマを Aurora PostgreSQL クラスターに適用 アプリケーションのアセスメントと変換 : .NET ソースコードを接続し、スキーマと並行してデータベース依存のアプリケーションコードをアセスメントおよび変換 前提条件 開始する前に、以下を確認してください : AWS Transform console へのアクセスを持つ AWS アカウント DDL を抽出するための SQL Server に接続する資格情報 Aurora PostgreSQL クラスターを作成する権限を持つ AWS アカウント (AWS Transform はデプロイステップの一部としてターゲットクラスターをプロビジョニングします) オプション : .NET アプリケーションアセスメント用の、 AWS CodeConnections 経由でアクセス可能な、または Amazon S3 や Personal Access Token (PAT) 経由でアップロードされたソースコードリポジトリ (GitHub、GitLab、または Bitbucket) AWS Transform for SQL Server は US East (N. Virginia) us-east-1 でのみ利用可能です。他のリージョンのデータベースの場合、変換のために us-east-1 にクローンしてください。 AWS アカウントで IAM Identity Center が有効化されていること Microsoft SQL Server バージョン 2008 R2 から 2022 (すべてのエディションがサポートされています)。SQL Server は AWS 上または AWS 外でホストできます。 オプション (.NET アセスメント用): .NET Core 6、7、8、または 10 アプリケーション。レガシーな .NET Framework 4.x 以前はサポートされていません。 ウォークスルー 以下のセクションでは、Offline Source ワークフローの各ステージを説明します。 ステップ 1: SQL Server DDL を抽出してアップロード AWS Transform は DDL を抽出するための 2 つの方法を提供します : オプション 1 (推奨): 変換ジョブを作成すると、AWS Transform は SQL Server に対して実行する抽出スクリプト ( ExtractDatabaseMetadata.ps1 ) を提供します。このスクリプトはデータベースごとに SQL Server オブジェクトタイプ (テーブル、ストアドプロシージャ、関数、トリガーなど) の DDL 定義を抽出し、複数の機能領域 (SSIS、SSRS、Service Broker、Agent Jobs など) を検出するため、アセスメントに最も完全な情報を提供します。 オプション 2 (手動): SSMS または sqlpackage を使用して SQL DDL ファイル ( CREATE TABLE 、 CREATE PROCEDURE  などのステートメント) を手動でエクスポートし、zip にしてアップロードします。各 SQL ファイルには 1 つのデータベースのステートメントのみを含める必要があります。 結果の DDL ファイル (または zip) を AWS Transform にアップロードして Offline Source を作成します。 ステップ 2: アセスメントの確認 AWS Transform はすべてのデータベースオブジェクトの複雑さと依存関係を分析します。アセスメントレポートには以下が含まれます : オブジェクト間の関連性を可視化する依存関係マップ 各オブジェクトの複雑さスコア (Simple、Moderate、Complex) 手動変換と自動変換の作業量 (LOE) の見積もり エージェントによる自動化で削減できる工数と、人的レビューが必要な部分の内訳 アセスメントでは、PostgreSQL のイベントトリガーへの置き換えが必要な DDL トリガーや、例外ブロック内でのみ有効な構文を使用している関数など、手動レビューが必要になる可能性のある項目も識別されます。これらの情報をもとに、変換開始前にチームの作業計画を立てることができます。 ステップ 3: 変換をカスタマイズ アセスメントを確認した後、AWS Transform は変換の実行方法を定義する変換プランを生成します。プランは実行戦略、フェーズの順序付け、変換ルール、インフラストラクチャー構成を単一のレビュー可能なアーティファクトに統合します。デフォルトを受け入れて進めることも、変換開始前に任意の側面をカスタマイズすることもできます。 変換プランは 4 つの領域をカバーします : 実行ウェーブ – データベースはウェーブ順に変換され、各ウェーブ内で最大 5 つのデータベースが並行して実行されます。次のウェーブは現在のウェーブのすべてのデータベースが完了した後にのみ開始されます。ウェーブ間でデータベースの順序を変更したり、完全に除外したりできます。 ジョブプラン – 変換ジョブのフェーズの順序 (スキーマ変換、ターゲットプロビジョニング、スキーマデプロイ、コード変換、およびオプションの合成テストデータ生成)。必要に応じてオプションフェーズをスキップできます。 変換およびカスタムルール – 型マッピング (例: SQL Server の MONEY から PostgreSQL の DECIMAL(19,4) )、スキーマ名マッピング (例: 単一データベース移行での dbo から public )、関数マッピング (例: GETDATE から CURRENT_TIMESTAMP )、IDENTITY 列戦略 ( GENERATED BY DEFAULT または GENERATED ALWAYS )、およびプロシージャ結果のハンドリング (refcursor または関数リターンスタイル)。適切なデフォルトが自動的に適用されるため、ユースケースに合わないものだけを変更するだけで済みます。 ターゲットプロビジョニング構成 – 新しい Aurora PostgreSQL クラスターを作成するか既存のものに接続するか、およびインスタンスクラス、ネットワーク設定、資格情報管理。 これらの設定は、コンソールでプランを直接編集するか、自然言語でプリファレンスを記述するか、JSON 構成ファイルを提供することでカスタマイズできます。例えば、「MONEY を DECIMAL(19,4) にマッピングし、dbo に public を使用し、GENERATED ALWAYS で IDENTITY 列を生成する」とリクエストすると、AWS Transform が該当するルールを適用します。 ステップ 4: LLM ベースのスキーマ変換の実行 AWS Transform では、大規模言語モデル (LLM) を使用して SQL Server スキーマオブジェクトを PostgreSQL に変換します。変換はコンテキストを考慮し、構文だけでなくビジネスロジックの意図を保持します。 変換はステージごとに進行します: 基盤オブジェクト (スキーマ、シーケンス、シノニム、ユーザー定義型) テーブルと主キー 制約とインデックス プログラマブルオブジェクト (ストアドプロシージャ、関数、ビュー、トリガー) LLM ベースのアプローチは、ルールベースのツールでは通常手動変換が必要な複雑な T-SQL パターンやプロプライエタリな SQL Server 構文を処理します。これにより、自動変換率が向上し、手動介入が減少します。 ステップ 5: 変換済みオブジェクトの検証 変換されたオブジェクトは、以下の 3 層の自動検証を通過します : 構造的検証 は、変換された PostgreSQL スキーマが構文的に正しくデプロイ可能であることを確認します。 意味的検証 は、変換されたオブジェクトがソースの論理的な意味と動作を保持していることを検証します。 機能的検証 は、ソースとターゲット間のクエリ動作を比較し、本番環境に影響する前に差異を検出します。 各検証パスでは分離されたサンドボックスが起動し、ソースとターゲット両方のスキーマをロードした上で、型マッピング、制約、ルーチンを検査する AI エキスパートレビュワーが実行されます。AWS Transform はストレージオブジェクトの変換後とコードオブジェクトの変換後にそれぞれ検証レポートを生成します。各レポートでは、カテゴリごと (テーブル、列、制約、インデックス、ビュー、プロシージャ、関数) に Pass、Warning、Fail の結果が示されます。 検証完了後、エキスパートアセスメントが全体の変換を評価します : Ready: オブジェクトが完全に変換および検証済み Conditional: オブジェクトが変換済みで、レビュー用にマイナーな問題がフラグ付けされている Not Ready: 手動介入が必要なオブジェクト ステップ 6: 残りの問題への対応 Conditional または Not Ready と評価されたオブジェクトについて、AWS Transform は具体的な次のステップを含む Schema Conversion Report を提供します。2 つのオプションがあります : 組み込みの AWS Transform Web コンソールを使用して、ローカル IDE のインストールなしにブラウザで直接変換の問題を確認して修正する。 または、Kiro や他のローカル AI コーディングアシスタントと  AWS Transform MCP Server  を使用して、好みの IDE にアーティファクトを取得する。 修正を加えた後に検証を再実行し、スキーマ全体が検証に合格するまで繰り返しデプロイできます。 Web コンソールでは、変換レポートの確認、SQL の編集、検証の再実行、変更のデプロイまでをブラウザ上で一貫して行えます。ローカル開発を好むチームには、MCP Server を使って IDE から AWS Transform ワークスペースに接続して普段の開発ワークフローのまま、同じアーティファクトとデプロイ機能を利用できます。 ステップ 7: Aurora PostgreSQL にデプロイ 検証が完了したら、AWS Transform に AWS アカウントへのアクセスを付与するデータベースコネクタを設定します。AWS Transform はターゲットの Aurora PostgreSQL クラスターをプロビジョニングし、変換済みスキーマをデプロイします : 既存のクラスターを選択するか、AWS Transform に新しいクラスターを作成させます。 AWS Transform が変換済みオブジェクトをターゲットに適用します。 データベース資格情報が生成され、AWS Secrets Manager に保存されます。 問題がないかデプロイレポートを確認します。 デプロイ後、継続的な運用に不要な場合は、オプションで RDS Data API を無効にできます。 ステップ 8: .NET アプリケーションコードのアセスメントおよび変換 スキーマのデプロイが完了すると、コード変換が実行可能になります。アプリケーションのアセスメントと変換を行うために、.NET Core (6、7、8、または 10) のソースコードリポジトリを接続します。アプリケーションのデータベースアクセスには ADO.NET または Entity Framework (6.3-6.5、または EF Core 1.0-8.0) を使用している必要があります。なお、アセスメントはスキーマデプロイ前でも開始できますが、コード変換にはスキーマが先にデプロイされている必要があります。 ソースコードへの接続には、以下を使用できます :   AWS CodeConnections (GitHub、GitLab、または Bitbucket リポジトリ用) ソースコードの直接アップロード用の Amazon S3 AWS Secrets Manager  に保存する Personal Access Token (PAT) 接続すると、AWS Transform は : コネクタを通じて利用可能なリポジトリを検出します。 ソースコードをダウンロードして分析し、データベース参照、Entity Framework モデル、接続文字列、SQL クエリパターンを識別します。 モダナイゼーションの複雑さ (Low、Medium、High) と具体的な変換レコメンデーションを含むアプリケーションアセスメントレポートを生成します。 アセスメント完了後、コード変換を開始して .NET アプリケーションコードを Aurora PostgreSQL をターゲットとするように更新できます。コード変換はスキーマ変換の結果を使用して、アプリケーション内の接続文字列、ORM マッピング、インライン SQL クエリを更新します。 ステップ 9: テストデータで検証する (オプション) AWS Transform は本番データを公開することなく、ターゲットクラスターに検証用のテストデータを生成できます。テストデータ生成レポートには何が作成されたかが記載され、代表的なデータボリュームに対してストアドプロシージャ、ビュー、アプリケーションクエリの徹底的なテストが可能になります。 クリーンアップ このウォークスルー中にテスト目的で新しい Aurora PostgreSQL クラスターを作成した場合 : Amazon RDS console に移動します。 作成したクラスターを選択します。 Actions > Delete を選択します。 削除を確認します。 AWS Transform ワークスペースは追加料金なしでそのまま残しておけるため、後から参照することができます。 まとめ AWS Transform for SQL Server の Offline Source を使うことで、SQL Server モダナイゼーションにおける 2 つの大きな障害、すなわち「始めるまでのハードル」と「スキーマ変換の精度・検証」を解消できます。稼働中のデータベースへの接続設定は不要で、DDL ファイルをアップロードするだけで始められます。インフラストラクチャーのプロビジョニングなしに、スキーマのアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行できます。さらに .NET ソースコードリポジトリを接続すれば、データベースと合わせてアプリケーションコードの変換も可能です。これらすべてが単一の統合ワークフローで完結します。 Offline Source を開始するには、 AWS Transform console  を開いて最初の変換ワークスペースを作成してください。詳細については、 AWS Transform ドキュメント を参照してください。モダナイゼーションターゲットとしての Aurora PostgreSQL の詳細については、 Amazon Aurora PostgreSQL-Compatible Edition  を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 Vikas Babu Gali Vikas Babu Gali は Amazon Web Services のシニアスペシャリストソリューションアーキテクトで、SQL Server の移行、モダナイゼーション、クラウドデータベース変換を専門としています。Vikas は Fortune 500 企業の多くのお客様を大規模なミッションクリティカルなクラウド変換でガイドしてきました。 Nits Jeganathan Nits Jeganathan は AWS Transform のプロダクトリーダーで、15 年の IT 業界経験、12 件の特許、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションに関する 2 件の出版物を持っています。Nits は複雑な課題の解決とカスタマーエクスペリエンスの改善に情熱を注いでいます。現在は生成 AI を使用したレガシーアプリケーションのモダナイゼーション加速に注力しています。 Shashank Kalki Shashank Kalki は Amazon Web Services のデータベース移行スペシャリストソリューションアーキテクトです。お客様と連携して最も困難なデータ移行の課題を解決し、Amazon Aurora と Amazon RDS への移行の計画、実行、最適化を支援しています。専門分野は大規模な異種データベース変換と移行のベストプラクティスです。

こちらの記事は「MEDLEY Summer Tech Blog Relay」の28日目・最終日の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp みなさん、こんにちは。株式会社メドレー 人材プラットフォーム本部 VPoE の倉林（ @terukura ）です。全社のAI活用を支えるAI基盤開発室の室長も兼務しています。 7月13日から28日間、平日毎日つないできたリレーも今日でゴールとなります。社内の皆さん、完走お疲れ様でした！！ はじめに 先日、社内でこんな光景がありました。 法務のメンバーが Pull Request を出し、AIエージェントがレビューコメントを付け、それを受けて修正がマージされる。 ここまでなら、開発チームの日常です。ただしこのPRの中身はコードではなく、契約書レビューの観点をまとめたskill定義でした。出したのはエンジニアではなく、法務のメンバー本人です。 昨年4月に「メドレーのAI活用戦略：AI for All」という記事を書きました。「全職種が全業務で当たり前にAIを活用する」—当時はまだ宣言に近かったこの言葉が、この1年でどこまで現実になったのか。 メドレーのAI活用戦略：「AI for All」 | MEDLEY Developer Portal メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林(@terukura)です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組ん... developer.medley.jp その答えを一言でいうと、こうなります。 全職種にAIを届けようとした結果、全職種がGitHubを使う会社になってきた。 この記事では、なぜそうなったのか、そしてそれを支えている仕組みの一部を紹介します。 室長を務めているAI基盤開発室は、AI共通基盤の構築、ツールの選定・開発・運用、環境整備といった土台づくりと、それを現場に行き渡らせるAI活用推進（いわゆるAI Enabling）の両方を担っています。基盤は、作るだけでは使われません。作って、届けて、使われるところまでが仕事です。 この1年の活動を貫いていたテーマは、次の3つです。 エージェントが速く、安全に走れる環境（ハーネス）を整える 業務知識（skill）を流通させる 効果を計測し、見える化する この記事では、この3つを軸に振り返ります。 なぜ「全社AIハーネス」が必要になったのか AIエージェントに仕事を任せようとすると、すぐに気づくことがあります。 エージェントには「働く場所」が要る、ということです。 業務の文脈（ルール、過去の判断、ドメイン知識）はどこに置くのか 成果物はどこに出すのか 人間によるレビューと承認はどこで回すのか 改善の履歴はどこに積むのか チャットUIも最近はメモリやプロジェクト機能を備え、「使うほど賢くなる」方向に進化しています。ただ、その蓄積は個人とツールの中に閉じがちです。隣のチームからは発見できず、レビューも履歴も残らず、別のエージェントには持ち運べない。個人の生産性は上がっても、組織の資産にはなりにくいと感じています。 エージェントの実行環境（ハーネス）に必要な要件を並べてみると— エージェントに必要なもの それを満たすもの 文脈の蓄積と版管理 リポジトリ + バージョン管理 成果物の置き場 リポジトリ 人間の承認フロー Pull Request 自動実行 GitHub Actions 作業キュー Issues 並べてみて、気づきました。この要件は、すべてGitHubが満たしています。 新しいAI基盤ツールを探すまでもなく、エンジニアが20年近く使い続けてきた道具が、AI時代の全社ハーネスの要件をそのまま満たしていた。私たちはこの事実を受け入れ、GitHubを軸に全社のハーネスを整えていくことにしました。 エージェントの生産性は、モデルの賢さだけでは決まりません。整備された道路の上でこそ車がスピードを出せるように、同じモデルでも、走る環境—ハーネス—次第で出せる速度と安全性はまるで変わります。私たちがこの1年やってきたのは、この道路を全社に敷くことでした。 部門ごとに .claude/ を持つ 現在のメドレーでは、エンジニア組織の外にも部門ごとのリポジトリがあります。実際の構成の一部を挙げると— legal-compliance/ # 法務・コンプライアンス .claude/skills/ # contract-review(契約レビュー), ops-ringi(稟議)… human-capital/ # 人事 .claude/skills/ # jd-review(求人票レビュー), workflow-review(業務フロー)… corporate-it/ # コーポレートIT .claude/skills/ # support-L1(ヘルプデスク一次対応), isms-take-inventory-github(ISMS棚卸し)… internal-audit/ # 内部監査 .claude/skills/ # draft-jsox-rcm(J-SOX文書ドラフト), review-audit-workpaper(監査調書レビュー)… 契約レビューの観点も、稟議の通し方も、J-SOXの文書化も、部門の業務知識そのものが .claude/ （skillsやCLAUDE.md）としてバージョン管理されていっているのがポイントです。 業務ルールの変更はPRになる。つまりレビューと履歴が残る 新メンバー（人間もAIも）は、リポジトリをcloneすれば部門の文脈を持てる 会議室の空きを探すskillから監査調書レビューまで、粒度の大小を問わず「その部門のやり方」が形式知になる 集めて、共有して、配布する skillが各部門のリポジトリに散らばると、今度は同じようなskillの乱立や、車輪の再発明が起きます。そこで、収集→共有→配布の3層で流通させる仕組みを作りました。 収集（collect） : 毎日早朝、グループ全org・400超のリポジトリをスキャンして、AI設定ファイルを横断収集。集めたskillは名前・説明・出典リポジトリつきの全社カタログとして自動整理され、日々の差分がSlackに流れる 共有（share） : 良さそうなものは共有リポジトリに持ち寄る。 npx skills add で使いたい人が自分で引いていく、気軽な置き場 配布（marketplace） : 全社標準と判断したものだけを、プラグインとして版管理つきで正式配布。Claude Codeの /plugin install と、非エンジニアが使うClaude Coworkで同一のmarketplaceを共用し、さらにClaude Teamの組織設定で本人が何もしなくても届く 共有と配布の違いは、届け方と責任です。共有は使う人が引く（pull）、配布は全社に押して届ける（push）。持ち寄りの気軽さと標準装備の信頼性は求められるものが違うので、同じ場所に混ぜないようにしています。 私たちの仕組みが少し珍しいのは、「共通リポジトリを用意したので、ここで共有してね」から始めなかったことだと思っています。 skillやルールは、業務のあるところで生まれます。各プロダクトのリポジトリには、そのチームのskill、エージェント向けのルール、CLAUDE.md、カスタムエージェント定義やhooksが既に大量に育っています。多いリポジトリではskillだけで90近く。これを「中央のリポジトリに引っ越して共有してね」と言った瞬間、現場の文脈から切り離されて陳腐化するか、そもそも誰も引っ越しません。 だから順番を逆にしました。skillは現場のリポジトリに置いたまま、収集する側が毎日全部を読みに行く。書き手には何の作業も求めない。良いものはカタログの中から発見され、必要になった段階で初めて共有・配布へ昇格する。中央は「正」ではなく、現場の写像です。 収集は書き手に、配布は使い手に、作業を求めない。 両端がゼロタッチであること が、全社に広げるうえで一番効いたと思います。 この仕組みで見えるようになったskillの数は— 指標 収集開始時（2026-03） 現在（2026-08） スキャン対象リポジトリ 280 445 CLAUDE.md の数 147 370 Claude Skills の数 212 1,221 約5ヶ月でskillは6倍近くに増えました。「発見できる」ようにしただけで、隣の部門のskillを参考に自部門版を作る動きが自然に生まれています。 skillにもテストを書く skillが1,000を超えると、「作ったのに発火しない」「関係ない場面で発火する」が品質問題になります。そこで共有リポジトリのskillにはトリガー評価セットを同梱しています。 should_trigger: true のクエリだけでなく、「このクエリでは発火してはいけない」というネガティブ例も書く。発火しすぎるskillは、発火しないskillと同じくらい有害だからです。 さらに、Claude用に書いたskillがCodexでも機能するかを codex exec でsmoke testする自作evalも運用しています。1つのskillをClaude Code / Cowork / Codexの3つのハーネスに向ける以上、テストもハーネス横断です。 非エンジニアはGitHubを使えるのか 正直に言うと、いまも簡単ではありません。 「コミット」「ブランチ」という語彙の壁 コンフリクトで完全に手が止まる そもそもローカル環境を持っていない 「非エンジニアもPRを出す会社」の先行例といえば、 GitLabのhandbook文化 が有名です。全社員がMerge Requestでハンドブックを直す。ただしあれは、採用からオンボーディングまで長い時間をかけて根付かせた文化があってこそ成立するもので、同じやり方をすぐに真似するのは難しい。私たちが選んだのは、 人がGitに歩み寄るのを待つのではなく、AIとハーネスの側から人に歩み寄るやり方でした 。 それでも前に進めているのは、書く作業の大半をAIエージェントが肩代わりするからです。契約レビューのskillを直したい法務メンバーがAIに「こう直して」と伝えれば、ブランチもコミットもPRもAIが作る。本人に残るのは、Gitの操作スキルではなく「レビューして承認する」ことだけ。PRという承認フローは、むしろ非エンジニアにとって自然だったのです。 そしてもうひとつ大事なのは、 そもそも「GitHubを使えるようになること」を目的にしていなかったことです 。「まずGitを覚えましょう」という研修から入ったわけではありません。非エンジニアの目的はあくまで「AIに仕事を任せること」であり、GitHubはエージェントが働く場所として、その後ろに静かについてきただけです。タイトルの「AIを届けようとしたら、GitHubを使う会社になってきた」は、文字通りこの順番の話です。 全部収集する 〜 それを支えるAI Usage ハーネスが整うと、良いことがあります。全部が見えるようになるのです。 私たちはAI利用の状況を「AI Usage」という内製ダッシュボードに集約しています。収集しているのは— コーディングエージェントのテレメトリ : Claude Code / Claude Cowork / Codex からOpenTelemetryで直接収集 各AIツールのAPI : Cursor、Devin、GitHub Copilot、Claude / OpenAI Platform API 基盤ツールの利用状況 : n8n、Dify LLMアプリの品質データ : Langfuseのtraceと評価スコア 開発成果 : GitHubのPRデータ（Four Keys） 組織データ : 人事データと突合して本部別・職種別の活用率を算出 ちなみに、集めたデータの出口はWebのダッシュボードだけではありません。MCPサーバーとしても提供していて、Claude Codeから「今月の自分のAI利用状況を教えて」と聞けます。 トークン数の「先」まで測る 「誰がどれだけ使ったか」だけなら、各ツールの管理画面でも分かります。本題はその先です。 Skill実行とMCP呼び出しを計測している。どのskillが何回使われたかに加えて、自動発火したのか・明示的に呼ばれたのかまで分かる。skillを作った側が「ちゃんと発火しているか」を検証できる AI利用と開発成果を重ねている。チーム別に、AIトークン投入量とContributorあたりマージPR数をバブルチャートで可視化している AI活用レベルは、聞かずに測る 社員やチームのAI活用度を把握する方法として、アセスメント—自己申告アンケートやスキル検定でレベル分けする—を採る会社は多いと思います。私たちも一度は考えて、やめました。ハーネスが整っていれば、聞かなくても行動ログから算出できるからです。 チームのページを開くと、Skills利用、MCP活用、エージェントへの委任、高度活用メンバーの数といった指標が自動で表示されます。アセスメントとの違いは3つ。回答負荷がゼロであること、常に最新であること、そして申告と実態のズレがないこと。アンケートによる定点観測では、この速度の技術変化には追いつけません。 必要だったのは、常時観測です 。 おわりに 〜 リレーの裏側にあったもの この28日間、メンバーたちはハーネスエンジニアリングから権限設計、LLM API設計、ローカルMLLMまで、それぞれの持ち場の実践を書いてきました（全記事は リレーの紹介記事 からたどれます）。いくつか挙げると— 素晴らしい提案をしよう！君もハーネスエンジニアにならないか？ 生成AIを活用した自動化に必要な権限設計の考え方 LLM API を叩くときに考えること — AIを機能に組み込む前に確認する6つの観点 Jetson Orin Nano Super によるローカルMLLM活用について 個々のメンバーが28日間書いてきた実践の裏には、今回ご紹介させていただいたような計測と推進の仕組みがあります。 「AIでエンジニアリングは不要になる」という言説を見かけますが、私たちの現場で起きているのは逆です。バージョン管理、コードレビュー、CI—エンジニアが20年かけて磨いてきた道具と規律は、AI時代になって初めて「全社の標準装備」になってきています。エンジニアリングは要らなくなるどころか、会社全体の働き方の中心を担いはじめています。非エンジニアがGitHubに来つつあるのは、そこにしかない規律の価値を、AIが翻訳してくれているからです。 「AI for All」と宣言してから1年。全職種がAIを使う会社を目指した私たちは、気づけば全職種がGitHubを使う会社になっていました。AIの民主化とは、実はハーネスの民主化のことだったのかもしれません。 その意味で、私たちはGitHubそのものに賭けているわけではありません。今年6月にはCursorが、エージェント時代を前提に設計したGitフォージ「 Origin 」を発表しました。賭けているのはバージョン管理・レビュー・自動化という「ハーネスの型」であって、Git互換である限り、この記事で書いた仕組みは持ち運べます。次の道路がどこに敷かれるのか、こうした動きにも注目しています。 メドレーは今期、 AX Project を始動しました。「AIを足す」のではなく、 AIを前提に会社をゼロから設計し直す 取り組みです。全部門のワークフローを「人が担う工程」と「AIに任せる工程」に仕分けし、組織構造や要員計画のあり方まで変えていく。全社AI活用の統括責任者としてCAXO（Chief AI Transformation Officer）が置かれ、AI基盤開発室はその直下で、全社の環境と基盤を作る役割を担います。自律型AIを業務やプロダクトに組み込む新職種「 Applied AI Developer 」の新設も、この流れの一部です。 社内で共有されている問いがあります。 今日、AIを取り上げたら会社が回らなくなるか？ 回るなら、それはまだAIを「足している」だけの会社である。 AX Projectは、全社のワークフローを書き出し、skillとして整備するところから始まります。この記事で書いたGitHubハーネスも、skillの流通も、AI Usageも—すべては、この問いに「回らなくなる」と胸を張って答えられる会社になるための土台です。 メドレーでは「医療を人間中心へ」というミッションのもと、一緒にこの仕組みを進化させてくれる仲間を大募集しています。この記事や本リレーの記事にピンときた方、ぜひカジュアルにお話ししましょう！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp