個人開発で最初の公開までにやったこと（kimura512.dev の実例）

結論

kimura512.dev を初めて公開したとき、いちばん時間を使ったのは機能実装ではなく「第三者が読める状態をつくる」作業でした。ローカルでは動いていても、運営者が誰か・問い合わせ先・個人情報の扱いが分からないサイトは、ポートフォリオとしても弱いです。公開前に About・プライバシー・問い合わせ導線と、最低限のブログ記事を同じマイルストーンに入れました。

1. リポジトリとビルド

ローカルは pnpm で依存を固定し、本番は pnpm run build のあと wrangler deploy です。API キーは Workers のシークレットにだけ置き、リポジトリには .env を入れません。デプロイのたびに迷わないよう、「ビルドが通らないコミットは本番に出さない」と決めました。プッシュ前の pnpm build は、型エラーとルーティングの不整合を先に拾うための習慣になっています。

2. 公開前チェックリスト

毎回、次をブラウザで確認します。トップに「Coming Soon」だけのリンクが無いか、言語付き URL が 404 にならないか、記事ごとに OGP が変わるか、問い合わせフォームが本番で届くか。チェック項目はメモに箇条書きで残しています。文章だけの手順書は読み飛ばされやすいので、自分用にはチェックボックス形式の一覧にしています。

3. コンテンツの最低ライン

トップの Works だけでは、サイトの説明が作品集に偏ります。技術選定や失敗談など、体験ベースの記事を複数本用意し、「はじめました」だけの薄い公開は避けました。公開の判断は「自分が読んで役に立つか」で切っています。後から記事を足す前提でも、初公開時点で読めるテキストがあると、問い合わせや提携の話が来たときに説明用の URL を渡せます。

4. デプロイ後

本番 URL でブログ一覧・記事本文・プライバシーが 200 になることを確認します。Search Console は後からでも構いませんが、noindex の付け忘れは早めに見ます。デプロイ直後は、記事ページの HTML ソースで robots メタを一度確認する癖をつけました。キャッシュの影響で古い一覧が見えることもあるので、更新後はシークレットウィンドウでも開きます。

5. ドメインとメール

問い合わせは info@kimura512.dev に集約し、フォームの送信先と About・フッターの表記を揃えました。メールアドレスがページごとに違うと、利用者も運営者本人も迷います。リリースのたびにテスト送信をして、届くことを確認してから「公開完了」としています。

6. 公開ページの導線

フッターから Blog・About・Privacy・Contact に辿れるようにしました。運営者情報は About にまとめ、未完成の作品カードはトップから外しています。初見の人が数分でサイトを見て回る想定で、どのページからでも必要な情報に一回のクリックで届く配置を意識しました。

7. ローカルと本番の差分

開発ではホットリロードが効くため、本番だけで起きるルーティング差分に気づきにくいです。言語プレフィックス付き URL とリダイレクトは、本番ビルドをデプロイしたあと毎回確認します。Contact は Workers 上の API ルート経由でメール送信するため、ローカルで試した経路と本番が同じかも見ています。

8. 記事とポートフォリオの役割分担

トップは作品集として残し、長文はブログに載せます。作品カードの説明を長くするより、制作の過程や選定理由を記事にした方が、後から自分も読み返しやすいです。ブログと Works の役割を分けたあとも、リンク切れが無いかは公開前に手で踏みます。

初公開後一週間は、新機能追加を止めて誤字・リンク切れ・ポリシーの食い違いだけ直す週間を設けました。急いで機能を足すより、公開済み URL の信頼を固める方が先だと感じています。

まとめ

初公開は完璧より「説明できる状態」で足ります。インフラ・ポリシー・文章を同じ週で揃えると、あとから外部サービスや提携の話が来ても慌てにくくなりました。

よくある質問

Q. 最短で公開するには？

About・Privacy・Contact、記事2本、トップの未完成カード削除までを同一マイルストーンにします。このセットがそろえば、あとは記事を足しながら運用できます。

Q. デプロイは何回試した？

本番 DNS を向ける前に preview Worker で3回、apex 切替後にフルチェックを2回行いました。本番に直接切り替える前に、別環境で一度通しておくのが効きました。