背景
2019年来、yamotty.tokyo という自己サイトを構築して運営していました。
それ以前 (2016−) はGithub pagesでホストしていたりしていました。
それはそれとして。
yamotty.tokyo はNotionでブログを書いてWraptasというWeb UIラッパーで運用していました。極めて運用負荷が低く、Notionさえ使えれば楽ちんな構成でした。
運用負荷が軽い代わりに、以下のような課題がありました
- サービスの利用料金でトータル 1,500円/月 ほどコストがかかる
- UIの自由度がNotionに依存する
- ライティング環境もNotionに依存する
- すでに東京に住んでいないのに、
.tokyoを使っている - ブログ以外にも、いろんなコンテンツがプラットフォームに散らばっており、これを自動的に束ねてポートフォリオにしたい
世の中はVibe (雰囲気) codingが流行っており、こうした課題も解決しつつ自分でVibe codingを試してみよう、ということで思い立ってサイトを作り直す (作り直させる) ことにしました。
プロジェクトのゴール
- サイトにかかるコストをゼロにする
- それなりに満足できるUIをつくりなおす
- 静的なサイトを手慣れたGithub + Vercelでホストし、楽々運用する
- ドメインを変える →
yamotty.meに - 外部サイト (Podcast, note, しずかなインターネット) の更新を自動でまとめる
- 1つだけ、自分が扱ったことのない技術スタックをいれる → Github Actionsを使うことに
- 思い立ってから3日でリリースする
プロジェクトが長引くほどやる気が低減するので、夏休みの3日間で仕上げることとしました。
Vibe Codingのための準備
Vibe Codingは文字通り雰囲気でコーディングするため、裸で望むと品質にばらつきが出ます。
自社の経営の中でもVibe codingでいくつか社内ツールをScrap & Buildしていたこともあり、私の中にもLLMに再現性高く品質を担保させるための勘所がありました。具体的には以下のようなポイントです。
- 要件定義書やデザイン要求定義書、プロジェクト管理表をしっかりはじめに作り込む
- 作りたいサンプルUIを画像で準備しておく
- まず動くものを雑に作り、イメージからあまりに遠い場合はすべて捨てる
- 捨てて作り直す際には、イメージと乖離したポイントをドキュメンテーションに反映する
以下は今回のプロジェクトの中身ですが、/doc の中にドキュメントがたくさん整備されています。
今回のプロジェクトはドキュメントを元に作って、捨てて、フィードバックを反映して作り直す、というのを2周しました。今みなさんが見ているものは3周目に出来上がったサイトになります。
なお仕様書の冒頭では以下のように、プロジェクトのゴールを示しています。
## 1. プロジェクト概要
### 1.1 目的
- 個人のオンライン活動を統合的に表示するプロフィールページの構築
- **コンセプト**は「トップページを見たら、複数のサービスに散らばった最新の私の更新情報が伝えられる」
- プロフィールページがタイムライン化しており、複数のプラットフォームに分散している情報を含む私の更新履歴が一覧化できる
### 1.2 背景
- 既存のブログ(https://yamotty.tokyo/posts) を `/posts` に移管する
- 複数のWebサイトでの記事執筆活動、Podcast配信活動をおこなっており、これらのアップデートを束ねたい
- 外部メディアへ掲載された取材記事もデータベースで管理し、その内容も更新履歴に入れたい
開発の構成と環境
サイトの構成は仕様書で定義しています。これを元に技術要件をLLMに考えさせています。
## 2. システム要件
### 2.1 ページ構成
1. **Top** - メインページ（タイムライン表示）
2. **About** - 自己紹介ページ
3. **Posts** - ブログ記事ページ
### 2.2 技術要件
- **フロントエンド**: Next.js 14 + TypeScript + Tailwind CSS
- **データ管理**: マークダウンファイル + JSONファイル（静的サイト生成）
- **デプロイ**: Vercel自動デプロイ
- **RSS取得**: GitHub Actionsによる定期実行
- **画像管理**: Next.js Imageによる最適化
サイト全体の構成や技術要件がシンプルなので、開発環境も極めてシンプルでした。
- Cursor
- Github Actions
- Vercel
このプロジェクトでは私がしたことはほとんどCursorと日本語で対話したり、画像を集めてこれを使えと指示したのみです。過去のブログのコンテンツはNotion APIで拾ってきましたが、そのための使い捨てのスクリプトもLLMが作ってくれました (ちょいちょいNotion独特のブロック概念に阻害されて取得されていない部分もありますが、それはおいおい)。
メリット
Vibe Codingのメリットは、開発者と対話するようにLLMと対話するだけでコーディングができる点です。自分にできなかったことができるようになる、早く開発ができる、などが得られます。
私のようにプロダクト開発を少しでもかじったことがある人であれば、大きな恩恵を受けることができると思います。
デメリット
Vibe Codingの恩恵を受ける代わりに、コード全体を理解し、管理するという思想を手放します (手放さない人もいるでしょうが、それはそれで得られるメリットが少なくなる)。
今回もコーディングにおける規律や構成を私はほとんど理解していません。
普通にコーディングする際は、なにか不具合が起きたときにコードの構成を読み解き、エラーメッセージを解消するための手立てをとります。
しかしVibe Codingで一定量のコードを書かせる場合、この手段を諦めることになります。なにか起きたときにもLLMにすべての課題解決をさせる、の一択となります。逆にキャッチアップして自分でメンテナンスしようとしたら、結局LLMが書いたコードを理解するのに時間とストレスがかかり、メリットはあまり享受できないのではないか、と思います。
この感覚は、自動車などの複雑な構造物になにかの不具合があったとき、素人が自分での解決を諦めてディーラーや修理工場に持ち込む感覚と似ていますね。
できた！
ということで、できたサイトがこのサイトです。
タイムラインのUIなど、細かいところはこだわって改善をしました。なかなか満足のできるものが開発できて満足です。毎月かかっていたコストも0にできて、お財布にも優しくなりました。
またLLMと会話すると彼らがどういう作業や考えを持ってコードを書いたかを説明してくれます。バグが起きたときの原因なども、LLMが探して教えてくれます。全ては理解できなくとも、勉強になりました。
Special thanks
サイトのUIの参考事例を探していたとき、「これだ！」というものと出会いました。
それがしずかなインターネットの開発者であるCatnoseさんのポートフォリオサイト「catnose.me」です。タイムライン形式で美しくまとめられており、まさに「これだ」と思いました。今回のサイト構築においても大変参考にさせていただいております。
以前、Catnoseさんと収録したPodcastもあるので、ぜひ聞いてみてください。
