本番切替の前に移行先サイトを仕上げた日 — 画像の謎、フォームの文字化け、トップページの作り直し
DNS を切り替えてしまえば、あとから直すのは全部「本番の修正」になる。だから切替の前に、移行先サイトを自分で全ページ見ておきたかった。dev サーバーを 3500 番で立ち上げてもらって、上から順にクリックしていく。
3ページ目で手が止まった。コンセプトページの画像が、1枚も出ていない。
画像が消えていたのはデータではなく dev サーバーだった
真っ先に疑ったのは移行データのほうだった。WordPress のバックアップから記事を引っ張ってきたとき、画像の復元だけ取りこぼしたのではないか。それなら移行手順のやり直しで、この日の予定は全部飛ぶ。
原因を調べてもらったら、答えは逆だった。まだ稼働している現行サイトの同じページを開くと、画像は全部出ている。ファイルは移行先にもちゃんと存在していた。出ていないのは dev サーバーだけで、画像のパスにアクセスすると 404 が返る。ビルド後の成果物では 200 が返る。
つまり配信設定の穴で、移行そのものは無傷だった。dev 限定の配信設定を足して、参照側 8 か所を置き換えてもらったら、ローカルでも画像が並んだ。
移行案件でいちばん怖いのは「データが欠けている」ことなので、そうではないと分かった時点でこの日の残りが全部やりやすくなった。逆に、ここで dev の 404 を「まあ本番では出るだろう」と流していたら、全ページレビューの信頼度そのものが落ちていたと思う。
お問い合わせフォームを本番で1周させる
移行先には問い合わせ導線がまだなかった。/info にフォーム本体を実装してもらったところ、最初はページが出ずに catch-all ルートに吸われた。dev サーバーを再起動してルートテーブルを作り直させたら、意図どおりの画面が SSR された。
ここからは本番相当の環境でないと試せない。ローカルでフォームを叩いてもメールは飛ばないからだ。デモとして Cloudflare Pages にデプロイしてもらうことにした。
APIキーは自分の手で貼った
メール送信にはメール配信サービスの API キーが要る。値そのものを AI に渡す気はなかったので、Chrome で設定画面まで進めてもらい、変数名の入力までを任せた。値の欄だけ自分で貼り付けて保存する。
この分担はやってみると気持ちがよかった。画面の階層を探すのは面倒なわりに判断がいらない作業で、そこだけ肩代わりしてもらい、渡してはいけないものは自分の指で入れる。
送信テストは通った
全 238 ページのビルドが終わったところでデプロイしてもらい、実際のフォームから送信した。画面には「送信が完了しました」。Gmail を確認させると、2 通着信していた。フォームの入力からメール受信までが一本につながった。
受信先も増やした。通知が届くのは 1 つのアドレスだけの実装だったので、もう 1 つの受信箱にも同時に届くよう、Functions 側の通知先に追加して再デプロイしてもらう。2 宛先とも届くところまで実測した。
2通目から日本語が壊れていた
着信メールを開いたら、2 通目の日本語が全部化けていた。お名前も題名も本文も読めない。
フォーム側のエンコード指定を疑うのが筋に見える。ところが化けているのは差し込まれた値だけで、テンプレート側の見出しや「様」の文字は正常に出ていた。同じメールの中で、片方は読めて片方は読めない。
原因は送信経路の違いだった。1 通目はブラウザのフォームから送ったもので、日本語は正しく届いている。2 通目は Windows のターミナルから curl で直接 POST したテストで、日本語が cp932 のままサーバーに渡り、UTF-8 として解釈されて壊れていた。
# 化けたのはこの経路だけ（ターミナルの既定エンコーディングのまま送っていた）
curl -X POST .../api/contact -d '{"name":"テスト", ...}'
つまりフォームは最初から正常で、壊れていたのはテストのやり方だった。UTF-8 を明示して再送すると、化けは消えた。
自分でテストを書いていたら、「文字化け＝アプリのバグ」と決めつけて実装をいじり回していたと思う。テンプレート文言だけ無事という一点を証拠にして切り分けてもらえたので、正常なコードを壊さずに済んだ。
トップページを「もっと見たくなる」入口に作り替える
レビューを続けていて気になったのは、トップページと記事一覧の中身がほぼ同じだったことだ。新着記事が並ぶだけで、初めて来た人がこのサイトで何が読めるのか分からない。
構成案をいくつか出してもらい、推した案をそのまま実装してもらった。画面で見たら悪くなかったので、勢いでヘッダーと同じ紺色のフッターも足した。サイト内リンクと外部サービスへの導線をまとめて置く。
ただ、まだ物足りなかった。このサイトには記事の中に自分で作ったアニメーションがあるし、絵本形式のコンテンツも別ページに置いてある。それが入口からは一切見えない。
そこで注文を足した。記事の中で動いているアニメーションをトップでも再生させて、その場で「詳細はこの記事へ」に流す。あわせて、絵本コンテンツの中身をスライドビューで数枚めくれるようにする。
素材のファイルサイズまで実測させたうえで計画書を書いてもらい、承認して実装に入った。コンポーネントを 2 つ作ってトップに組み込み、dev で描画とコンソールエラーを確認してからビルド、デプロイ。動く図解と試し読みビューアが入口に並んだ。
小さすぎたので、モーダルで拡大してページ送りできるようにした
本番で見て、絵本ビューアの画像が小さすぎることに気づいた。並べたページの中身が読めない。これでは「試し読み」にならない。
クリックで全画面のモーダルに拡大し、そのまま矢印でページを送れるようにしてもらった。Esc・背景クリック・× のどれでも閉じる。dev で開閉とページ送りと暗幕を確認してから、ビルドしてデプロイ。
拡大できるようになった瞬間、同じコンポーネントの印象が変わった。縮小した状態では「何かの画像が並んでいる」でしかなかったものが、中身を読ませる導線になった。
計画書は Markdown か HTML か
途中で、計画書の作り方そのものを相談することになった。
きっかけは単純で、計画書のパスだけ渡されても自分にはレビューする手段がなかったからだ。Markdown をエディタで開いて読むのは、図が入ると特につらい。Chrome で読める形にして表示してほしい、と伝えた。
その場で pandoc で HTML に変換して Chrome のタブに出してもらい、「計画書を作ったら Chrome に表示するところまでやる」をユーザーレベルのルールに足した。
そこで疑問が出た。図を入れるなら最初から HTML で書いたほうが早いのではないか。ずっと Markdown で書いてきたが、計画書だけ HTML 原本に切り替える手はある。
引っかかったのは、同じ内容のファイルが md と html の 2 つ残ることだった。どちらが原本か分からないファイルが並ぶのは、後から読むときに邪魔になる。表示用 HTML を一時ディレクトリに逃がす案も出してもらったが、それはそれで表示のたびに生成し直す手間が増える。
結局、原本は Markdown、表示用 HTML も同じディレクトリに置いたままでいくことにした。リポジトリに 2 つ残ること自体は許容する。diff が読めて編集も軽い Markdown を原本にしておいたほうが、あとで直すときに困らない。
判断を変えたのは、「無駄をなくす」より「どっちを直せばいいか迷わない」を優先したからだった。
コンセプトページを1カラムにする
最後に、コンセプトページのレイアウトを直した。
移行元の WordPress では 2 カラムで、右に目次が付いていた。移行先で同じ構成にすると、本文の幅が狭すぎる。このページは通読させたい文章で、見出しを飛ばして読む種類のページではない。目次を外して 1 カラムにし、本文の幅を広げてもらうことにした。
全記事から目次が消えると困るので、[...slug].vue 側に条件分岐を入れて、このページだけ 1 カラムにする形にしてもらった。frontmatter のスキーマを変えたので dev サーバーの再起動が要る。似た構成の別ページでは目次が残っていることも実画面で確認した。モバイル幅も見て、コンソールには既知の画像 404 以外のエラーが出ていない。
コミットは学習ゲートに掛かったので、そのまま /learn を回した。4 問全問正解で受領証が出て、3 ファイルのコミットが通った。
この日の締め
この日の変更一式は 34 ファイル・+2,289 行でコミットした。移行先サイトは、画像が出て、フォームからメールが届き、入口で中身が動くところまで来た。
残っているのは DNS の切替だけで、これは押したら戻すのに時間がかかる操作なので次のセッションに回した。
- コンセプトページの画像表示を dev でも直す
- お問い合わせフォームを本番で送信からメール着信まで通す
- 通知先アドレスを2つに増やす
- トップページに動く図解と試し読みビューアを入れる
- 試し読みビューアをモーダルで拡大・ページ送りできるようにする
- コンセプトページを1カラムにして本文幅を広げる
- DNS切替（本番切替）
学び
- 「表示されない」の原因が移行データ側とは限らない。 現行サイトと移行先の同じページを並べて見るだけで、データの欠損か配信の穴かが切り分けられた。先に環境差を潰すほうが早い
- テストが壊れているのか、実装が壊れているのかを先に決める。 メールの一部だけが化けていたという事実が、フォーム本体を触らずに済む決め手になった
- シークレットは値の入力だけ自分の手でやる。 画面遷移を任せてキーの値だけ自分で貼る分担なら、面倒さと安全性の両方が立つ
- 小さく置いた画像は、拡大できないと存在しないのと同じ。 試し読みビューアは、モーダルを足してようやく導線になった
- 原本を1つに決めておくと、あとで直すときに迷わない。 ファイルが2つ残る無駄より、どちらを編集すべきか分かることを優先した