結論

データ移行は本番切替当日の作業で失敗するのではなく、リハーサルで検証しなかった箇所で失敗します。そしてリハーサルは「やった」という事実ではなく、照合結果と例外処理の記録が残っていて初めて本番移行のGo判定材料になります。証跡パックとは、移行リハーサルの計画書、件数・金額照合表、データ品質検証結果、所要時間実測、エラーレコード一覧と処置、承認記録を1セットにした文書群のことです。AI開発では、移行データがそのままモデルの入力品質を決めるため、従来の件数照合に加えて学習・検索用データの品質検証を証跡に含める点が特有です。

証跡パックを構成する6点

この6点は、本番移行のGo/No-Go会議にそのまま添付できる形式で作ります。移行後にデータ起因の障害が起きた際、「リハーサルで何を検証済みだったか」を示す監査証跡にもなるため、移行完了後も保守フェーズを通して保管してください。

件数照合だけでは足りない: AI特有の品質検証

従来のシステム移行では件数と金額の照合が中心ですが、AIシステムでは移行データがRAGの検索対象や再学習の材料になるため、内容品質の検証を追加します。具体的には、テキストデータの文字コード変換による化け(機種依存文字、外字)、添付ファイルの本文抽出成功率、メタデータ(部署、日付、区分)の欠損率、個人情報を含むレコードのマスキング処理の適用率を、サンプリングではなく全件の自動検査でレポート化します。

検索精度に直結する例として、文書の日付メタデータが移行時に投入日で上書きされると、「最新の規程を答える」タイプの検索が全滅します。この種の事故は件数照合では検出できないため、品質検証項目はAIの利用シナリオから逆算して設計してください。

リハーサルの回数と環境条件

リハーサルは最低2回を推奨します。1回目は手順の検証(エラーの洗い出しが目的で、失敗が多くて正常)、2回目は本番同等条件での通し検証(所要時間実測とGo判定材料の取得が目的)です。2回目は本番と同じデータ量・同じマシンスペック・同じ並列度で実施しないと、所要時間の実測値が使えません。

移行元データは可能な限り本番の実データを使いますが、個人情報を含む場合は、テスト環境への持ち出しについて社内の安全管理措置と整合させる必要があります。個人情報保護委員会のガイドラインが求める安全管理措置の観点から、マスキング済みデータでのリハーサルか、本番同等の管理策を適用した検証環境かを選択し、選択理由も証跡に残してください。

エラーレコードの処置ルール

リハーサルで必ず出るのが、変換できないエラーレコードです。処置は「修正して再投入」「除外して手動移行」「除外して廃棄」の3択になりますが、この判断をベンダーに任せてはいけません。除外の判断は業務データのオーナー(業務部門)が行い、除外リストへの承認サインを証跡に含めます。

特に「廃棄」は、その データが将来の監査・訴訟・顧客対応で必要になる可能性の評価を伴います。迷う場合は移行先に入れず旧システムのアーカイブに読み取り専用で残す選択肢を検討してください。エラー率の目安として、全体の0.1%を超える除外が出る場合は、除外運用ではなく変換ロジックの改修に戻すほうが総コストは下がります。

責任分担と費用の扱い

移行作業の分担は、抽出(発注側またはベンダー)、変換・投入(ベンダー)、照合・品質判定(両者)、エラー処置判断(発注側)が標準形です。リハーサルの費用は移行費用の内数として当初見積に含まれているかを確認してください。「リハーサルは1回、追加は別費用」という見積が多いため、2回目の条件をRFP段階で明示しておくと安全です。移行元システムのベンダー(現行保守会社)へのデータ抽出依頼費用も、忘れやすい発注側負担項目です。

実務チェックリスト

• 証跡パック6点(計画・照合・品質・時間・エラー・承認)の様式を決めたか
• AI利用シナリオから逆算した品質検証項目を設計したか
• リハーサルを手順検証と本番同等の2回で計画したか
• 本番同等回はデータ量・環境・並列度を本番と一致させたか
• 個人情報を含むデータの検証環境の扱いを安全管理措置と整合させたか
• エラーレコードの処置判断者を業務データオーナーに設定したか
• 除外率0.1%超過時のロジック改修への切り戻し基準を決めたか
• リハーサル2回分の費用と現行ベンダーへの抽出依頼費を見積で確認したか

図解で確認するポイント

この記事の画像は、移行元から検証工程を経て移行先へデータが流れ、各工程で記録が蓄積されていく構造を文字なしで図解しています。移行の本体作業と並走して証跡が積み上がることが、Go判定を支える構造です。

AllAI内での次の行動

移行計画の全体像はデータ移行計画ガイド、切替当日の体制は本番切替とロールバック責任分界の決め方が続きのテーマです。移行を含む発注要件の整理はAI発注診断から始め、移行実績を開示できる会社をAI開発パートナーで比較してください。全体の進め方はAI開発外注完全ガイドにまとまっています。

FAQ

Q. リハーサルを1回で済ませるのは危険ですか? A. 1回目のリハーサルでは手順不備とデータの想定外パターンが必ず見つかります。修正後の検証なしで本番に臨むと、修正自体が新しいエラーを生むリスクが残ります。データ量が少なく停止許容時間に余裕がある案件以外は2回を確保してください。

Q. 照合はどこまで自動化すべきですか? A. 件数・金額・キー整合の照合はスクリプト化必須です。本番当日は時間制約の中で同じ照合を再実行するため、人手のExcel照合では間に合いません。リハーサルは照合スクリプト自体の検証機会でもあります。

Q. 移行元データの品質が悪すぎる場合は? A. データクレンジングを移行スコープに含めるか、移行前の業務側作業にするかを金額つきで判断します。クレンジング基準(何を直し何を諦めるか)は業務部門が決め、ベンダーには基準の実装だけを任せるのが役割分担の原則です。

Q. 証跡パックは監査で本当に使いますか? A. 個人情報を含む移行や、財務データに接続するシステムでは、内部監査・システム監査で移行の正当性を問われます。移行時点の照合記録と承認記録がないと、後から再現できず監査指摘になります。

出典と確認日

• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」: https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/ (確認日: 2026-07-10)
• IPA「システム再構築を成功に導くユーザガイド」: https://www.ipa.go.jp/archive/publish/qv6pgp0000000wo6-att/000059184.pdf (確認日: 2026-07-10)
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)