Codexで忠実移植するには事前仕様固定が欠かせない
AIに既存ツールの移植を依頼するとき、注意すべきことがある。
こちらは忠実に移してほしいだけでも、AIは改善や再設計を含めて解釈することがある。
その結果、元の機能や見た目が変わってしまうことがある。
忠実移植をしたい場合は、事前に仕様固定が必須である。
AIは親切に改善しようとすることがある
AIは、単にコピーするだけでなく、より良くしようとする傾向がある。
UIを整える、構造を変える、機能を追加する、不要そうな部分を削る。
通常の開発ならありがたい場面もある。
しかし、忠実移植ではこの親切が危険になる。
移植と再制作は違う
移植とは、既存の機能、構造、見た目、挙動をできるだけ保ちながら、別環境や別形式に移すことである。
再制作は、目的をもとに新しく作り直すことである。
この違いを明確に伝えないと、AIは移植タスクを再制作タスクとして処理する可能性がある。
特にテンプレート、既存デザイン、既存UXを守りたい場合は注意が必要である。
忠実移植では、触ってよい範囲と触ってはいけない範囲を分ける
AIに依頼するときは、どこを変えてよいのか、どこを変えてはいけないのかを明確にする。
HTML構造は維持、CSSクラスは維持、文言だけ差し替え、機能追加禁止、デザイン変更禁止、既存JSは触らない。
このように制約を明文化することで、不要な改変を減らせる。
特にAGENTS.mdやテンプレートファイルなど、基準となるファイルは触らせない方が安全な場合もある。
検収では、差分を見る
忠実移植では、完成品だけを見るのではなく、元ファイルとの差分を見る必要がある。
見た目、ファイル構成、導線、meta、CSS、JS、コンテンツ量が意図せず変わっていないか確認する。
AIの出力は一見きれいでも、元の要件を満たしていないことがある。
忠実移植では、見栄えより一致度が重要である。
忠実移植では、
AIに改善させないための仕様固定が必要である。
同じテーマでも、見方を変えると行動が変わる
このテーマは、単なる効率化ではなく、業務の見方そのものを変える話である。どこを人間が担い、どこを仕組みに寄せるのかを分けることで、実務上の判断がしやすくなる。
- いい感じに移植して
- 必要なら整えて
- 見やすくして
- 同じように作って
- 細かい制約を渡さない
- 機能追加禁止
- デザイン変更禁止
- CSSクラス維持
- HTML構造維持
- 変更範囲を限定
実務では、次の順番で考えると使いやすい
考え方だけで終わらせず、実際の業務改善・ツール化・記事化に落とし込むための手順として整理する。
記事の考え方を現場で使うためのチェックリスト
読んで終わりにしないために、実務で確認しやすい観点に落とし込む。
当てはまるなら改善候補
- 再制作ではなく移植と明記した
- 変更禁止範囲を指定した
- 機能追加禁止を入れた
- 差分確認した
- 元テンプレートとの一致を見た
避けたい失敗パターン
- AIの改善提案をそのまま受け入れる
- 変更範囲を指定しない
- 見た目だけで確認する
- 元機能の維持を確認しない