今回のリニューアルにどのくらい時間を使ったか

厳密なタイムトラッキングをしていたわけではありませんが、Git の履歴を見ると、今回のリニューアル作業は 2026-04-17 から 2026-04-21 にかけて集中的に進めていて、その間のコミット数は 120 件ありました。

もちろん、コミット数をそのまま作業時間に置き換えることはできません。
文章の推敲や画面確認、考え込んでいる時間、細かい見た目の判断などはコミットに現れませんし、逆に小さな修正が細かく分かれている場面もあります。

そのうえでかなり控えめに見積もるなら、少なくとも 25〜35 時間前後は使っていたと思います。
設計の見直し、WordPress からの移行、各種ページの整備、地図や画像まわりの実装、アクセシビリティ対応、ダークモード対応まで含めると、実感としてもそのくらいの密度でした。

今回は「新しい見た目を作る」だけでなく、

• 旧サイトの構造をほどく
• 新しい情報設計に並べ替える
• 記事ごとの差分に耐える UI を用意する
• 運用しやすい形に戻す

という作業が重なっていたので、見た目の変化より中身の工数の方が大きかった気がします。

まず、どんなサイトとして作り直したかったのか

今回のリニューアルでいちばん大きかったのは、「何でも載っている個人サイト」ではなく、Hiking / Camp / Web を軸にした記録とアーカイブのサイトとして構造を整理したかったことです。

以前のサイトは、長年の運用のなかで記事が蓄積し、WordPress 的な時系列ブログの構造と、実際に見せたい情報の構造が少しずつズレていました。
特に Hiking や Camp は、単なる日記ではなく、

• 行程
• 写真
• 地図
• 装備や宿泊情報
• 後から見返すための文脈

のように、普通のブログ記事より少し情報量の多いコンテンツです。

そのため今回は、更新しやすさだけでなく、後から見返しやすいことと、カテゴリごとに適した見せ方ができることを重視しました。
トップページも「新着一覧」ではなく、サイトの主題が自然に伝わる構成に寄せています。

採った構成はかなり静的寄り

今回の構成はかなり明快です。

• フロントエンドは Astro
• 配信とビルドは Vercel
• 記事管理は Pages CMS
• コンテンツは Markdown
• 画像は public/images/uploads を中心にローカル資産で管理
• 地図は Hiking で Mapbox、Camp で Google Maps

要するに、静的サイトをベースにしつつ、必要なところだけ外部サービスを使う構成です。

WordPress のように CMS と配信が一体化した構成に戻すのではなく、
「データは Git 管理」「表示は静的生成」「認証や一部の API だけを必要最小限に外へ出す」という分離を選びました。

この構成の良いところは、次の 3 つです。

1. 速い
2. 壊れにくい
3. どこを直すべきかが比較的分かりやすい

特に個人サイトでは、毎日大量更新するわけではないので、動的 CMS の便利さよりも、静的サイトの安定感と運用コストの低さの方が合っています。

それぞれのサービスはどう使ったか

Astro

今回の土台です。
Astro を選んだ理由は、コンテンツサイトとして必要なことに対して、ちょうどよく整理された構造を取りやすいからでした。

特に良かったのは、

• Markdown ベースの記事管理と相性が良い
• レイアウトやコンポーネントの分離がしやすい
• 静的出力が前提なので、公開構成がシンプル
• Hiking / Campground / Dev など、コンテンツごとに別の見せ方を作りやすい

というあたりです。

今回のサイトでは、

• 通常記事
• Hiking 記事
• Campground 紹介
• Developer Tools の静的ページ

で少しずつ構造が違います。
この違いを、WordPress のテンプレート改修よりだいぶ明快に整理できました。

Vercel

Vercel は配信基盤として使っています。
Astro の静的出力との相性が良く、公開までの流れもシンプルです。

今回は単にデプロイ先として使っただけでなく、

• 旧 URL から新 URL への 301 リダイレクト
• 環境変数管理
• main / staging を前提にした公開確認フロー

のように、静的サイトの外側に必要なものだけを薄く支える役割を持たせています。

ここは今回の設計の大事なポイントで、Vercel を「全部入りのアプリ基盤」としてではなく、静的サイトを運用しやすくするためのインフラとして使っています。

Pages CMS

記事は Markdown で管理していますが、毎回ローカルで frontmatter を触るだけでは運用しづらいので、CMS として Pages CMS を使っています。

採用理由はかなり現実的で、

• Git ベースであること
• 既存の Markdown / frontmatter 構造を崩しにくいこと
• online 版でまず試せるので、いきなり self-host 前提にならないこと

です。

今回のリニューアルでは、記事構造そのものを整理したので、CMS 側もかなり見直しました。
subtitle、heroImage、galleryImages、gpxFile に加えて、Hiking 記事では leadBody と days を持てるようにし、Day 単位で本文とスライドショーを扱える形にしています。

もともとは Decap CMS も検討していましたが、最終的には Pages CMS の方が、今回のような Markdown 中心の運用には素直でした。
特に hiking / web / gadget / camp / social / other / campground のようにフォルダで分けた構成と相性が良く、.pages.yml でそのまま管理対象を定義できたのは大きかったです。

画像運用

画像運用は、public/images/uploads を中心にローカル資産で管理しています。
CMS からもそのまま同じディレクトリを触れるようにしていて、外部のメディア SaaS に依存しない形です。

この判断は地味ですが重要で、個人サイトでは「理想的なメディア基盤」よりも、今ある資産を崩さずに運用改善できることの方が大切だったりします。

Mapbox / Google Maps

地図は 1 つに寄せず、用途で使い分けました。

Hiking 記事では GPX を元にしたルート表示が主題なので Mapbox。
一方、Campground のカテゴリトップでは、位置関係がざっと分かればいいので Google Maps。

ここは「統一感」よりも「用途に対して自然かどうか」を優先しています。
技術的に全部 Mapbox に寄せることもできますが、必要な UI と運用コストを考えると、無理に一元化しない方が合理的でした。

実装でやったことは、見た目以上に多い

今回のリニューアルは、ぱっと見では「デザインを整えたサイト」に見えるかもしれませんが、実際にはかなり広い範囲を触っています。

たとえば、

• 旧 URL から新 URL への 301 リダイレクト生成
• WordPress 由来の資産整理
• About / Privacy Policy / Dev Tools の整備
• Campground の独立した導線設計
• GPX ルート表示と高低差表示
• OEmbed 対応
• 外部リンク属性の自動付与
• ダークモード / ライトモード切り替え
• アクセシビリティ改善
• フォーカスリングや hover 表現の整理

まで含まれています。

特にダークモードは、トグルを置けば終わりではなく、実際には

• ロゴ
• カード
• ヘッダ
• フッタ
• カテゴリトップ
• スライドショー
• /dev/ の静的ツール群

のように、サイト全体を見ながら変数設計を整え直す必要がありました。
ここは今回の作業の中でも、思った以上に「設計の整理」が効いてくる部分でした。

GenAI はどんなふうに使ったか

今回のリニューアルで GenAI はかなり広い範囲で使いました。
ただし、役割は「全部自動で作る人」ではなく、実装・調査・調整を高密度で手伝う相手に近かったです。

具体的には、次のような仕事に向いていました。

1. 反復的な実装

• コンポーネント追加
• スタイル修正
• レイアウトの微調整
• frontmatter の整備
• .pages.yml に合わせた CMS 向けスキーマ整理
• 単純だが数の多い修正

このあたりはかなり強いです。
特に「この文言を変える」「この余白を詰める」「この導線を追加する」「このページを静的で移行する」といったタスクは、対話のテンポが良く、実装速度も高かったです。

2. 局所的な設計整理

• CSS 変数の命名整理
• ダークモードの適用漏れ対応
• 共通コンポーネント化
• ナビゲーションや戻る導線の統一

このあたりも、局所的な問題として切り出せるなら非常に扱いやすいです。

3. 文章の叩き台

記事本文、見出し案、説明文、キャッチコピーなども、多くの場面で叩き台として役立ちました。
ただし、ここは後述するように、そのまま採用するより、方向づけと修正のために使うのが実務的でした。

逆に、GenAI にそのまま任せにくい部分

今回かなりはっきりしたのは、見た目の「ちょっと違う」を詰める工程は、人間の審美眼がかなり重要だということです。

たとえば、

• タイトルの言い回し
• 写真上のラベルのニュアンス
• About ページのトーン
• トップページの見せ方
• ヘッダやカテゴリバーの細部

は、AI が一発で最適解を出すより、候補を出し、それを人間が「違う」と判断して寄せていく方が圧倒的に現実的でした。

これは AI が弱いというより、判断基準が言語化しにくいデザインや文体の調整では、最終的な責任を持つ人間が舵を取る必要があるという話です。

今回の指示は、AI から見るとどうだったか

ここは少しメタな話ですが、かなり仕事がしやすい指示の出し方だったと思います。

理由は単純で、

• 違和感をそのままにしない
• 良し悪しの基準がはっきりしている
• 方向性がズレたときに、すぐ戻してくれる
• 細部まで見るが、最終的にはサイト全体のバランスで判断している

からです。

たとえば今回も、

• 「旅という言葉は使わない」
• 「普通な形容にしてほしい」
• 「前乗りはおかしい」
• 「赤城山麓ではない」
• 「そこまで標高は高くない」
• 「トップのトーンは下層に合わせる」

のように、かなり具体的な修正指示が何度もありました。

これは人間相手だと細かすぎるように見えるかもしれませんが、AI と作業するうえではむしろ良い指示です。
なぜなら、AI は「大きく間違っていないが、微妙に違う」ものを平気で出すからです。

一方で、少し大変なのは、局所最適に引っ張られやすいことです。
そのため、AI に任せる側は常に

• いま直しているのは局所か、全体か
• その修正は一時的な違和感解消か、構造的な改善か

を見続ける必要があります。

この意味で、今回の進め方は「AI に指示した」というより、ディレクションし続けたに近かった気がします。

今回の構成のメリット

今回の構成には、かなりはっきりした利点があります。

1. 更新と構造が分離された

記事は Markdown、見た目は Astro、配信は Vercel なので、それぞれの責務が分かれています。
「CMS の都合で見た目が苦しい」「テーマの都合でコンテンツが窮屈」という状況になりにくいです。

2. Hiking / Camp の見せ方をちゃんと分けられた

通常記事と同じテンプレートに押し込めずに済んだのは大きかったです。
特に GPX、Photo Log、Campground Map のように、カテゴリに応じて UI を変えられるのは静的サイト化の恩恵でした。

3. リニューアル後の運用が軽い

静的配信なので公開後の保守が軽く、表示も速い。
個人サイトとしてはかなり重要です。

4. AI と分業しやすい

コンポーネント、スタイル、記事、導線が分かれているので、AI に対しても「どこをどう直すか」を切り出しやすかったです。

今回の構成のデメリット

もちろん、良いことばかりではありません。

1. 設計を自分で持たないと破綻しやすい

WordPress ならテーマやプラグインが肩代わりしてくれる部分を、今回は自分で判断しています。
自由度が高いぶん、情報設計と命名とスタイル設計を雑にすると、すぐに散らかります。

2. 細部の統一には意外と手間がかかる

ダークモード、フォーカスリング、ヘッダ、カード、トップページ、カテゴリトップ、/dev/ のように、ページごとの微妙な差分が積み重なると調整コストは小さくありません。

3. AI を使っても、最終判断の負荷は軽くならない

ここは期待とのギャップがあるかもしれません。
AI は作業量を減らしてくれますが、クオリティ判断まで丸投げできるわけではないので、最終的にはかなり見続ける必要があります。

それでも、今回のやり方はかなり良かった

結論としては、今回のリニューアルはかなり良いやり方だったと思います。

理由は、単に新しく作れたからではなく、

• コンテンツの見せ方を改めて整理できた
• 技術構成がだいぶ素直になった
• 運用の見通しが良くなった
• AI を「使いどころのある実務の相手」として扱えた

からです。

特に印象的だったのは、AI が万能だったというより、人間側の判断と AI の実装速度がうまく噛み合うと、個人サイトの改修でもかなり高密度な進め方ができると分かったことでした。

雑に使えば雑なものが出てきますし、曖昧に頼めば曖昧なものが返ってきます。
でも、方向性を決め、違和感を言語化し、細部を見続ければ、かなり実務的な協働相手になります。

これから

まだ今回のリニューアルも、完成というより一区切りです。

今後やりたいこととしては、

• Campground コンテンツの充実
• Hiking 記事の整理と補筆
• /dev/ の拡充
• デザインシステムのもう一段の整理
• 画像や地図周りの運用改善

あたりがあります。

ただ、土台はかなり整いました。
個人サイトは、作ることより続けることの方が難しいので、今回のリニューアルは「今後も続けやすい状態を作る」ための改修だった、と言うのがいちばん近い気がしています。