元のPHPを仕様として扱い、構造の棚卸しと振る舞いの一致確認を先に用意します。共有スキルをKiroとAWS Transformで使う移行方法を示しました。 コンパイル成功と業務の一致を分けることが焦点です。誤りを個別に直すだけでなく、変換ルールへ戻して再生成する運用を説明しています。 業務の振る舞いを移行完了の基準へ AWSは10月29日、Kiroを使いPHPからJavaへの移行を繰り返し検証できる工程にする方法を公開しました。長年使われたアプリには、フレームワークの設定やデータ構造の中にも業務上の規則が残ります。似た構造のJavaコードがコンパイルできても、同じ動作になるとは限りません。記事は元のPHPを仕様として扱い、振る舞いの一致を確認する仕組みが合格するまで移行完了としない考え方を示しています。構造を機械的に調べるスキャナー、共有する変換方法、段階的な実行工程を組み合わせます。新しい言語モデルの発売ではなく、AIを用いた移行作業に判定基準と再利用可能な知識を持たせる実装例です。 棚卸しと判定機構をコード生成より先に 工程の初めにモデル、項目、関係を調べた一覧を作ります。Javaを生成する前に、同じ要求と応答を元のPHPと移行先で比較する検証機構を用意します。正常なPHPで通るだけでなく、意図的に壊した場合に失敗することも確認し、判定機構自体が誤りを見逃さないかを試します。その後、変換規則と未解決の差を整理し、代表的なファイルで規則を確かめます。Kiroでは人が一覧や規則を確認し、段階ごとの承認を行います。同じ方法を記したスキルファイルはAWS Transformでも使い、複数アプリの移行へ適用できると説明しています。保守担当者や移行チームには、暗黙の仕様を確認できる形に変える作業が加わります。生成の速度に先立ち、何を一致と判定するかを定義することが主要な判断点になります。 共通の誤りを変換規則へ戻す運用 後半では雛形の作成、データモデル、入出力、業務ロジックの変換を進め、最後に一致を証明する構成です。記事は同じ誤りが複数のファイルで出た場合、個別の出力を直すだけでなく、規則を修正して再生成する原則を示しました。実務上は既存動作を保存する部分と、意図的に変える部分を区別する必要があります。差が残る場合は、承認済みの変更として記録する考え方です。検証対象に含まれない例外処理や外部連携は、移行後に問題が表れる可能性があります。判定機構の対象と不足を人が確認する体制が論点になります。記事の移行エンジン自体はAWSの資源を作成しないとしていますが、実際の案件では環境の準備とレビューの費用が別に生じ得ます。規則と基準となる版を管理することが、再実行できる移行の条件になると見られます。変換を重ねるほど規則の変更が広く影響するため、再検証の範囲を明確にすることも課題になります。