このサイトの土台は、AIのデザイン機能で作ったHTML/CSS/JSのプロトタイプでした。それをAstro + TypeScript + MDX構成へ実装し直す過程で、一番悩んだのは技術的な移植方法よりも、「このコードのどこまでが本質的な意図で、どこからが単なる実装上の都合か」の見極めでした。
プロトタイプのコードは「答え」ではなく「証拠」として読む
プロトタイプのCSSにベタ書きされた数値（padding: 23px のような半端な値）を見たとき、それをそのまま移植するのではなく、「なぜこの数値になったのか」を先に推測するようにしました。デザインツールが出力したコードは、多くの場合ピクセル単位のスナップショットであり、値そのものに意味があるとは限りません。一方で、色の変化・レイアウトの余白バランス・要素同士の相対的な大きさ関係には、明確な意図が宿っていることが多いです。コードは「この見た目を実現した証拠」として扱い、答え合わせのために元の意図を逆算する材料にしています。
構造の重複は「意図の強調」として読む
プロトタイプでは、似たようなカードコンポーネントがコピー&ペーストで量産されていることがよくあります。これを実装時にそのまま踏襲するのではなく、「同じ構造が繰り返されている」こと自体を、デザイン上重視されているパターンだと捉え直し、コンポーネント化の単位を決める手がかりにしています。逆に、1箇所にしか出てこない特殊なスタイルは、意図というより「そのページだけの例外」である可能性を疑い、汎用化すべきか個別対応で済ませるべきかを都度判断しています。
アニメーションのイージング値は特に注意深く扱う
数値の中でも、アニメーションのイージングカーブやdurationは、プロトタイプの段階でかなり試行錯誤の跡が残っている部分です。星空の明滅や空の色遷移など、体感に直結する数値はプロトタイプの値をできる限りそのまま尊重し、逆にレイアウトのブレークポイントのような構造的な数値は、実装側の都合（Astroのコンポーネント分割単位など）で調整しています。
「意図の抽出」は人間がやってもAIがやっても同じ難しさ
デザインをコードに落とし込む際に「意図を汲み取る」という作業自体は、人間のデザイナーとエンジニアの間でも、AIが出したプロトタイプと実装との間でも、本質的には同じ難しさを持っていると感じます。違うのは、AIが出したコードには「なぜこうしたか」を直接尋ねられる相手がいることです。実装に迷ったときは、コードを読み解くだけでなく、生成した側に意図を聞き返す、というやり取りそのものが、ハンドオフの精度を上げる一番の近道でした。