直接回答
最初に依存関係、呼び出し元、データフロー、文書化されていない挙動を調べさせ、観測可能な契約に特性テストを追加します。外部インターフェースを保ちながら元に戻せる小さな単位で移行し、同じ入力で新旧経路を比較して、移行、監視、ロールバックのゲート後に旧コードを削除します。
重要な結論
- 構造を変える前に振る舞い、所有者、運用境界を把握します。
- 特性テストは現状を記録しますが、すべての現状が正しいとは限りません。
- 内部を段階移行する間は互換境界を安定させます。
- 旧経路の削除は移行後に行う独立した判断です。
重要な事実
このガイドで解決できること
大量のコード生成を振る舞い維持の証拠とせず、AI 支援のレガシー移行を計画・実施する。
検証範囲と制約
- 証拠の種類
- 公式ドキュメント仕様ローカル検証
- 検証範囲
- レガシー調査、振る舞い記録、移行単位、互換性、段階展開、削除ゲートを対象とします。
- 制約と失効条件
- - 特性テストは欠陥も保存し得るため、現在の業務要件と照合する必要があります。
- - データ、トラフィック、外部利用者の本番移行には別途計画が必要です。
契約と変更境界の地図を作る
入口、利用者、永続データ、定期処理、外部プロトコル、デプロイ単位をコードや文書と共に特定させ、不明な挙動は推測で埋めず明示します。
所有者と運用制約を保守担当者が確認します。import のグラフだけでは、実行時の統合を表せません。
構造変更前に観測可能な挙動を記録する
公開 API、イベント、DB への影響、ファイル、ユーザー出力にテストを追加し、秘匿化した境界・エラー例を含めます。疑わしい現状は印を付け、テストで欠陥を永久要件にしないようにします。
- 代表入力と出力から機密情報を除いて記録します。
- 正式な契約と偶然の実装詳細を分けます。
- 同じリリースで移行できない利用者を特定します。
- 二重経路を作る前にロールバック信号を決めます。
元に戻せる移行単位を定義する
一つの endpoint、command、data adapter、package 境界を選び、公開挙動を保つファイル単位の計画とテストを求めます。アーキテクチャ要約だけで全体書き換えを承認しません。
書式変更と無関係な整理は移行 diff から外します。小さな変更は履歴を保ち、差異の原因を絞りやすくします。
制御した入力で新旧経路を比較する
可能なら同じ秘匿化 fixture または shadow 入力で両方を実行し、外部に意味のある出力を比較します。差異は意図した契約変更、許容する非決定性、欠陥に分類します。
二重実行には資源上限と書き込み規則が必要です。比較のため不可逆な本番副作用を二重に発生させません。
展開と旧コード削除にゲートを設ける
各単位で特性テスト、新契約テスト、パッケージ検証、レビュー、ロールバック演習を行います。段階展開でエラーと資源を観測し、利用者、データ、文書、アラートの移行後に旧経路を削除します。
- 01振る舞い新旧経路がレビュー済み契約を満たします。
- 02互換性利用者とバージョンの前提が維持されます。
- 03運用テレメトリとロールバックで回帰を安全に識別できます。
- 04削除稼働中の呼び出し、ジョブ、データ経路が旧実装に依存しません。
リポジトリ指示を新しい構造に合わせる
移行に合わせてアーキテクチャ文書、エージェント指示、所有者、ビルドコマンド、runbook を更新し、廃止モジュールへ誘導する古い説明を削除します。
公式情報と検証範囲
本ガイドは公開されている公式ドキュメントを根拠にしています。コマンドや設定はクライアントのバージョンにより変わるため、実行前に参照元も確認してください。
技術検証方法を見る