「AIにDB移行を手伝わせたい。だが、実データを外部のAIに渡すことは統制上できない」—— エンタープライズのAI活用が最初に止まるのは、技術ではなくこの一線ではないでしょうか。

本記事では、互換性のない異種DB間の移行（Oracle 19c→SQL Server 2022）の前処理を、AIコーディングエージェント（Claude Code）に実データを一切渡さずに実施した実践を報告します。前処理とは、互換性リスクの洗い出し、スキーマ変換の設計、移行先実機での動作検証を指します。AIに渡した「データ」はDDL（テーブル定義などのスキーマ定義文）・エラーログ・実行結果メタデータのみで、行データ・個人情報は一切含みません。検証データはすべて合成（ダミー）データです。なお、検証環境へのリモート接続情報は人間の統制下で一時的に提供し、作業後にローテーション（無効化）する運用としています。

結論を先に言えば、この制約のままで、移行先実機への適用29バッチ・エラー0件、検証用スキーマに盛り込んだOracle固有機能の変換すべて（SEQUENCE採番・PL/SQL手続き・CONNECT BY階層クエリ・ROWNUMページング・マテリアライズドビュー代替・Unicode処理）の動作証明まで到達できました。進め方は全自動ではなく、要所に人間の承認ゲートを置いた半自動です。またその過程で、AIの安全ガードレールが危険な操作を2回ブロックするという、ガバナンス観点で示唆に富む出来事もありました。

1. DB移行は「技術」より先に「統制」と「人」で止まる #

Oracleデータベースからの移行（いわゆる「脱Oracle」、対象を絞る「減Oracle」）は、多くの企業で繰り返し検討されてきたテーマです。2026年6月時点の公表情報では、Oracle Database 19cのPremier Supportは2029年末、Extended Supportは2032年末までとされています（^※1）。一見すると猶予ができたように見えますが、延長期間中の提供内容には条件や除外事項があり得るため、自社契約での確認が必要です。むしろ「期限に追われた駆け込み移行は計画が雑になる」ことこそが過去の教訓であり、時間があるうちに移行の固定費（前処理コスト）を下げておくことに価値があります。

一方で、移行プロジェクトが進まない理由は概ね3つに集約されます。

1. 互換性の不確実性 — どこが壊れるか事前に分からない。発見が後工程にずれるほど手戻りコストは桁違いに膨らむとされる
2. 人材 — OracleとSQL Server双方に通じたエンジニアは、採用市場での確保が極めて難しい
3. 統制 — 実データ・本番情報を外部AIに渡すことが社内規程上できない

人材面の逼迫は統計にも表れていますが（経済産業省試算〔2019年〕で2030年にIT人材が中位シナリオで約45万人不足（^※2）、IPA調査でDX人材の「質」不足回答が51.7%（^※3））、現場の実感はもっと単純です。社内のOracleを知り尽くした担当者の定年・異動が迫る一方、保守費は毎年硬直的に出ていく。移行の検討は「いつかやる」ではなく「誰がやれるうちにやるか」の問題になっています。

本記事はこの3つ、特に「3. 統制」を制約として受け入れたうえで、1と2をAIでどこまで解消できるかの実地検証です。

2. 本稿のスコープ — できたこと・まだやっていないこと #

誇張を避けるため、最初に範囲を明示します。移行ツールは SSMA（SQL Server Migration Assistant。Microsoft純正の移行支援ツール）の利用を前提とします。

ポイントは順番です。(3)期待値を(2)ツール実測より先に書き、(5)実機で動作証明までしておく。動くことが証明された期待値は、ツール出力をレビューするための「検収基準」として使えます。テスト駆動開発の発想を移行プロジェクトに持ち込んだ形です。なお期待値はT-SQL（SQL ServerのSQL方言）で記述します。

25項目のチェックリストは現時点ではあくまで事前予測です。SSMAの実測結果との突き合わせ、つまり予測がどこまで当たりどこが外れるかは、次回の記事で報告します。

もうひとつ、本稿が扱わない領域も明示しておきます。DB移行プロジェクト全体には、アプリケーション側資産（埋め込みSQL、データアクセス層、帳票、バッチジョブ、DBリンク連携など）の改修という大きな工程があり、一般に総工数の過半を占めます。本稿がカバーするのはスキーマとDB内ロジックの変換部分であり、全体から見れば一部です。ただしここは「最初に確定しないと後続のすべてが手戻りになる」基礎工事でもあります。

3. 最初に決めた統制3原則 — 「AIに何を渡さないか」の設計 #

作業開始前に、次の3原則を固定しました。

1. 実データは扱わない（検証データはすべて完全合成）
2. クレデンシャルはコード・ファイルに永続化しない
3. 移行先DBのポートを不要に外部公開しない

AIに渡してよい情報の線引きは次の通りです。

※検証機へのリモート接続情報は、人間の管理下で一時的に提供し、作業後にローテーションする運用としました（第10章参照）。

「外部AIサービスに送る」ということ自体の整理 #

「実データを渡さない」としても、DDLやエラーログも情報資産であることに変わりはありません。外部AIサービスの利用にあたっては、最低限次の契約条件を確認したうえで線引きを決める必要があります。

• 入力・出力がモデルの学習に利用されないこと（本検証で利用したClaude Codeは、商用利用条件において入力を既定でモデル学習に利用しない旨が公表されています。利用プランごとの最新規約の確認は必須）
• データの保持期間と削除条件
• 処理リージョンと準拠法
• スキーマ自体が機密に当たる場合の追加措置。テーブル名・列名を機械的に匿名化して渡し、結果を社内で逆変換する方法が取れます（対応表は社内のみで保管）

この原則が先にあることで、後続の技術判断が自動的に方向づけられました。たとえばDB認証はOS統合認証に寄せ、「パスワードという秘密情報をそもそも作らない」構成を採っています。その結果、完了時点で成果物ファイル・スクリプト・実行ログのいずれにも、DB接続の秘密情報は存在しません。

示唆: AI利用ガイドラインは「やってはいけないことの一覧」として棚に置くのではなく、プロジェクト規約・プロンプトとしてAIに最初に読み込ませると執行力が大きく高まります。ただし本検証では、それでも逸脱の試行が2回発生しました（第8章）。事前指示は単独では完結せず、承認ゲート・ガードレールを含む三層で初めて統制として成立します。

4. 実データの代わりに何を渡したか — 移行検証キットの構成 #

実データを渡さない代わりに、AIにはまず「互換性問題を意図的に盛り込んだ検証用Oracleスキーマ」を設計させました。本番スキーマの代理として、移行で問題になりやすい要素を1つのスキーマに凝縮したものです。

検証キット（5つの成果物）

合成データの設計にはひと工夫しています。日本語・NULL・境界値・特殊文字・絵文字といった「問題を起こしやすい値」を、乱数任せにせず「保証行」として必ず投入する設計にしました。本番データで起こる問題を、合成データで先回りして再現するためです。乱数シードを固定しているため、同一の検証データを何度でも再現できる設計です（Oracle実機での生成実行は次回スコープ。監査時の再現を意図しています）。

AI自身はセルフレビューで、自作した生成SQLのバグ3件（非決定的な結合、多バイト文字での長さ上限超過、無効な最適化ヒント）を実行前に検出・修正しています。「AIの成果物は無謬」なのではなく、「自己検証のループ込みで速い」が正しい理解です。AIの出力もまた検証対象である——この前提は本手法全体を貫いています。

5. 互換性の落とし穴を「業務インパクト」で読む #

Oracle→SQL Serverの互換性問題は技術用語で語られがちですが、意思決定の場では業務インパクトに翻訳する必要があります。チェックリスト25項目から、特に危険な6つを抜粋します。

本章に記載するSSMAの挙動はすべて実行前の事前予測です（実測との突き合わせは次回）。

① VARCHAR2/CLOBの非Unicode変換 #

• 予測: 既定変換ではVARCHAR/VARCHAR(MAX)化される見込み。照合順序のコードページに無い文字（絵文字・拡張漢字など）が「?」に化け、日本語以外の照合順序の環境では日本語全体が化ける
• 業務インパクト: 顧客名・住所の不可逆なデータ毀損。移行後に気づいても元に戻せない
• 対処: NVARCHAR/NVARCHAR(MAX)を明示

② Oracle DATEの時刻消失 #

• 予測: OracleのDATEは秒まで保持する。SQL ServerのDATE型に安易にマップすると時刻が消える（SSMA既定はDATETIME2(7)と予測しており、その場合時刻は保持されるが精度過剰）
• 業務インパクト: 受注時刻・監査証跡のタイムスタンプが消え、締め処理・SLA計測が壊れる
• 対処: DATETIME2(0)で受ける

③ 精度なしNUMBERのFLOAT化 #

• 予測: 精度指定のないNUMBERが浮動小数点型に変換される見込みで、丸め誤差が混入する
• 業務インパクト: 金額・数量がズレて経理突合が通らない
• 対処: DECIMAL/BIGINTを明示

④ 空文字とNULLの扱いの違い #

• 予測: Oracleでは空文字''はNULL。SQL Serverでは別物として扱われる（これは両製品の仕様差であり予測ではなく確定事項）
• 業務インパクト: エラーは出ないのに業務ロジックの判定結果だけが変わる。最も発見しにくい
• 対処: 移行時の正規化方針を事前決定

⑤ CONNECT BY階層クエリ #

• 予測: 自動変換不可と予測。組織階層・BOM・勘定科目ツリーのクエリが対象
• 業務インパクト: 手動の書き換え工数が見積りに直撃
• 対処: 再帰CTE（共通テーブル式による階層問い合わせ）へ書き換え。等価実装を用意済み

⑥ マテリアライズドビュー #

• 予測: 完全な等価機能はない（インデックス付きビューは自動維持されるが、リフレッシュ指定・集計の自由度など制約が大きい）
• 業務インパクト: 夜間バッチ・帳票集計の基盤を再設計
• 対処: テーブル＋リフレッシュ処理、または制約を許容できる場合はインデックス付きビュー

25項目全体の予測内訳は、自動変換できる見込み10・要レビュー警告11・自動変換不可2・人間の設計判断が必要6。計29分類になるのは、複数区分に該当する項目があるためです。つまり予測の段階で、「ツールに任せてそのまま済む」見込みは全体の4割程度。残り6割にどう備えるかが移行品質を決めます。

この25項目チェックリストは、読者の移行案件でも「レビュー観点表」「見積り根拠」として流用できる粒度で作ってあります。

6. 期待値スキーマ — 移行の「検収基準書」をAIに書かせる #

本手法の核心は、SSMAの出力を見てから考えるのではなく、あるべき変換結果（期待値）を先に固定することです。AIが生成した期待値スキーマには、すべての変換に理由コメントが付いています。型対応表の抜粋を示します。

注目していただきたいのは、同じDATE型でも「注文日時はDATETIME2(0)、誕生日はDATE」と列単位で判断を分けている点です。これは機械的な一括変換では出てこない、業務を踏まえた設計判断です。この判断は人間がゼロから書いたのではなく、AIが提案しコメントで理由を明示し、人間がレビューして承認したものです。

「AIが作った」で終わらせず、変換理由・採用しなかった代替案をコメントとして成果物に残す。これを義務付けるだけで、AI成果物は後任者・監査人が判断を追跡できるトレーサブルな文書になります。

7. 移行先実機での動作証明 — 「変換できた」と「動く」は違う #

期待値スキーマは、書いただけでは検収基準になりません。基準自体が動かないものでは、ツール出力を測る物差しにならないからです。そこで移行先のSQL Server 2022実機（照合順序 Japanese_XJIS_140_CI_AS）に適用し、機能検証まで行いました。

適用結果: 29バッチ実行・エラー0件（テーブル11〔業務10表＋マテビュー代替テーブル1〕／ビュー3／関数1／プロシージャ2。適用ツール側の不具合を修正したうえでの最終適用時の結果です）

機能スモークテスト（Oracle固有機能の変換が「動く」ことの証明）:

最も伝えたいのはUnicode検証です。絵文字を含む文字列「絵文字A😀🍣」を投入・取得したところ、LEN=6／DATALENGTH=16バイトで完全一致しました。「_140」世代の照合順序がサロゲートペア（絵文字などの補助文字）を正しく1文字として扱うことを、定性評価ではなく数値で確認したことになります。日本語データを扱うエンタープライズでは、ここまで検証して初めて「文字化けしない」と言えます。

検証の作法として、機能テストは使い捨てのスクラッチDBを作成して実行し、終了後に破棄しています。SSMA実測を待つ本検証DBは、クリーンなまま保たれています。

検証中には、AIが書いた検証スクリプト自体のバグ（SQLバッチの分割処理や、システムビューの列名の誤りなど）が実機エラーとして露見し、AIがエラーメッセージを読んで自己修正する場面が複数回ありました。「実機にぶつけて直す」という地味な反復が人手なしで回ること。これが工数圧縮の実態に最も近い描写です。

公平を期すため、この検証の限界も明示します。検証スキーマも期待値もAIが設計しており、構図としては「自作の試験に合格した」段階です。これが独り善がりに終わらないよう、期待値はSSMAという独立した変換器の出力とのdiff（次回）で突き合わせる設計にしています。また、あくまで10表規模での成功であり、数百〜数千オブジェクト規模、DBリンク・パーティション・PL/SQLパッケージが絡む実スキーマで新たに現れる問題は未検証です。

8. 想定外の収穫 — AIのガードレールが「統制の番人」になった #

本検証で示唆に富んでいたのは、計画していなかった出来事でした。作業中、AI側の安全機構（ガードレール）が2回、操作を実行前にブロックしたのです。なお対象はいずれもインターネット非公開の自社検証環境であり、本番環境・顧客環境は含まれません。

• 事例①: AIが作業効率を優先して、セキュリティ設定を弱める方向の操作（保護機構を緩和して処理を通すアプローチ）を提案・試行した際、実行前に安全機構が拒否。AIは回避策を探すのではなく、より安全な既定設定のままで成立する代替手段に切り替えて続行した
• 事例②: AIが認証情報をファイルに書き込んで利用しようとした際に、実行前に拒否。方針を転換し、本検証フェーズでは「パスワードという秘密情報をそもそも作らない」OS統合認証ベースの構成に到達した

重要なのは、2件とも人間側が冒頭で固定した統制3原則と一致する制止だったことです。ガードレールは作業の妨げではなく「設計原則の番人」として機能し、最終構成をむしろ安全側に押し上げました。

ただし、これを「AIの安全機構があるから大丈夫」と読むのは誤りです。ガードレールの挙動はモデルやバージョンに依存し、単独で統制の根拠にはなりません。本検証から導ける実務的なモデルは三層統制です。

1. 第1層: 事前原則 — 渡してよい情報の線引きと禁止事項を、AIへの最初の指示として固定する
2. 第2層: 人間の承認ゲート — 前提が崩れた局面ではAIは選択肢の提示に留め、人間が方針を決定する
3. 第3層: ガードレール — 第1・2層をすり抜けた危険操作の最終防波堤

第2層は本検証でも実際に機能しています。環境の前提が想定と異なると判明した場面では、AIは独断で進めず選択肢を提示し、人間が方針を決裁しました。採番方式の選定のような設計判断も同様です。

統制の前提として、AIに与えた実行環境も限定しています。対象はインターネット非公開セグメントの検証専用機のみで、本番系への接続経路はありません。操作はすべて記録され、人間がいつでもセッションを停止できます。さらに、ガードレールが作動しなかった場合に備えた検知手段は人間側に持たせます。具体的には、ワークログ上の操作記録を「認証・権限・外部送信に関わる操作」という観点で事後レビューする運用です。

そして、どの判断をAIがし、どこで人間が承認し、どこでガードレールが作動したかを時系列で記録したワークログが、そのままAI利用の監査証跡になります。

9. AIに任せた手数、人間に残った判断 #

本検証を通じた役割分担の実績は次の通りです。

この線引きが意味するのは、移行に必要な人材像の変化です。「OracleとSQL Serverの両方をゼロから書ける両刀エンジニア」を探すのではなく、AIが生成した型対応表・チェックリスト・選択肢を読んで判断できるレビュアーがいればよい。後者のほうが、調達も育成もはるかに現実的です。

工数についても触れておきます。本検証（10表規模）の内訳は次の通りです。

当社のこれまでの経験では、同種の前処理は両DBに通じた要員を確保したうえで週単位を要するのが通例でした。ただし所要は案件規模・スキーマ複雑度に依存するため、この比較を定量効果として一般化することは控えます。読者が自案件で見積もる際は、「対象オブジェクト数 × レビュー時間（型・採番・日付の判断が必要なテーブルほど重い）」を人間側工数の基礎に置き、AI側の生成・検証はその従属変数と考えるのが実態に近いはずです。

「レビュアーがいればよい」のレビュアー要件も具体化しておきます。必要なのは前掲の役割分担表の右列、つまり採番方式・日付型・照合順序・NULL方針の判断を下せることで、実質的にはSQL Server側の設計経験者が1名いれば足ります。社内にSQL Serverの運用・設計経験者がいれば内製可能、いなければその判断部分だけ外部レビューを併用する、というのが現実的な分岐です。

10. 自社で試すためのチェックリスト #

本手法を自社の移行検討に適用する場合の要点をまとめます。

情報の線引き（AI利用ガイドラインへの落とし込み）

• 渡してよい: DDL・スキーマ構造・エラーログ・統計メタデータ
• 渡さない: 行データ・個人情報・DBの恒久的な認証情報
• 作業上やむを得ず一時共有する接続情報は、人間の管理下で提供し、作業後に必ずローテーション
• スキーマ自体が機密の場合: テーブル名・列名の匿名化、構造のみの抽出を検討

合成データの要件

• 完全合成（本番値の混入なし）
• 乱数シード固定で再現可能な設計
• 日本語・NULL・境界値・特殊文字・絵文字の「保証行」を含む

成果物の要件

• すべての変換判断に理由コメント（採用しなかった代替案も）
• 予測と実測の分離記録（チェックリストに「予測」ラベル）
• ワークログの保全（判断主体が時系列で追えること。社外提供時はサニタイズ）

運用の要件

• 人間の承認ゲートを通す判断ポイントの事前定義
• AIの拒否（ガードレール作動）イベントも記録対象に

11. まとめ — 移行品質は「後で見つける」から「先に固定する」へ #

実証されたこと

• 実データを1行もAIに渡さずに、移行前処理（互換性予測・変換設計・移行先実機での適用と機能検証）は完遂できる
• 期待値スキーマを先に書いて実機で動作証明する「検収基準の事前固定」は、AIで実用速度になる
• 統制原則を最初にAIへ与え、承認ゲートとガードレールを重ねれば、統制側の仕組みとして機能する

まだ実証されていないこと

• SSMAによる実変換の結果（25項目チェックリストは事前予測の段階）
• 実データ移行フェーズの課題（データ品質・件数規模での性能・運用設計）。ここは引き続き、統制された社内環境で人間と専用ツールが担う領域です

次回は、SSMA for OracleのAssessment Reportを実測し、25項目の予測がどこまで当たり、どこが外れたかを1件ずつ突き合わせます。予測を先に文書として固定したからこそできる検証です。予測が外れた項目こそ、組織にとって最も価値のある知見になるはずです。

付録A: 互換性チェックリスト25項目の全体像（SSMA変換結果の事前予測） #

区分の凡例: 自動=自動変換見込み／警告=変換されるが要レビュー／エラー=自動変換不可の見込み／設計=人間の設計判断が必要

付録B: AI利用ガイドライン条文例（社内検討のたたき台） #

1. （情報の区分）AIに提供してよい情報は、スキーマ定義（DDL）、エラーログ、統計メタデータとする。行データ、個人情報、恒久的な認証情報の提供を禁止する。
2. （検証データ）AIを用いた検証に使用するデータは完全合成とし、生成条件（乱数シード等）を記録して再現可能性を確保する。
3. （承認ゲート）設計判断および作業前提の変更は、AIによる選択肢の提示と担当者の承認を経て実施する。
4. （記録）AIの操作・判断・安全機構の作動イベントは時系列で記録し、保全する。社外提供時はサニタイズを行う。
5. （一時認証情報）作業上一時的に共有した認証情報は、作業完了後に無効化する。

出典 #

• ※1: Oracle Lifetime Support Policy: Oracle Technology Products（Oracle公式） https://www.oracle.com/us/assets/lifetime-support-technology-069183.pdf （補足報道: The Register, 2025年2月 https://www.theregister.com/2025/02/18/oracle_extends_19c_support/ ）。延長期間中の提供内容・除外事項は自社契約での確認を推奨します。
• ※2: 経済産業省「IT人材需給に関する調査」（2019年） https://www.meti.go.jp/policy/it_policy/jinzai/gaiyou.pdf
• ※3: IPA「DX白書2023」。DXを推進する人材の「質」が大幅に不足していると回答した企業は2022年度調査で51.7%（2021年度30.5%） https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108046.pdf