1. Zero Topic - ゼロトピック -
  2. #331 サイトをVibeで作り直した
2025-09-01 17:42

#331 サイトをVibeで作り直した

参考

https://www.yamotty.me/post/20250901


Chapters

新しいサイトの紹介と背景

バイブコーディングの実践と課題

AIとの連携とコーディングの進め方

バイブコーディングのメリットとデメリット


お知らせ



サマリー

Vibeコーディングを通じて、yamotty.meという新しいサイトが構築され、そのタイムライン型のホームページが作り直されるプロセスが紹介されています。主にコスト削減やUIの自由度の向上を目指し、過去のコンテンツをNotion APIを使用して統合する方法について詳しく説明されています。このエピソードでは、Notionを活用したコンテンツ管理の難しさとVibeコーディングのメリット・デメリットが詳しく語られています。特に、LLMとの対話によるコーディングの新しいスタイルや、CatNoseさんのサイトを参考にしたUIデザインについても触れられています。

新しいサイトの構築
はい、こんにちは、ゼロトピックです。久しぶりの更新。3週間ぶりぐらいの更新になるんですが、
ちょっと柔らかい話を扱おうかなと思っています。
今、画面が見えている方は、私の個人の新しいサイトが映っていると思うんですが、
この個人のサイトをVibeコーディングで作り直したというお話をしたいなと思っています。
それに絡めて、Vibeコーディングをする際に、自分がどういうことに気を付けているかとか、
実際に具体的にどういう環境で行っているかとか、その話を少し入れればなと思っています。
まず、作ったサイトはどういうサイトかというところのご紹介なんですが、
yamotty.meというサイトを新しく作りまして、これがタイムライン型のホームページを持つようなサイトになっています。
例えば、私の出しているコンテンツって、この中で更新しているブログとか、
あとは静かなインターネットという外部のエッセイサービスとか、あとはこのポッドキャストとか、
自分のドメインで管理しているコンテンツ以外にも、いろんなところにコンテンツを書いたり話したりしている状態なんですよね。
他にはnote.comとか、そういうものもありますと。
自分の活動が一覧でまとまっているといいなというふうに思っていたり、
あとはそれがタイムライン形式でまとまっていると、自分のサイトとして、
自分がどういう活動をしているかというポートフォリオをうまく表現しやすいなと思っていたので、
これは夏休みの間にViveコーディングで作ってしまおうという形で、このようなプロフィールサイトを作ったというのが背景になります。
見れる方は見てわかるとおりというか、この日付の新しい順に更新したコンテンツが、
自分のサイトあるいは外部のサイトをかかわらず集まってきて、
課題と解決策
それがタイムライン形式で表示されているというような形になっています。
この一番最新のコンテンツにサイトをViveかっこ雰囲気で作り直したという、
こういったブログも書いてまして、今日これをもとに少しお話をできればと思っています。
そもそも何でサイトを作り直したんだっけというところなんですが、
もともとヤモティ.東京というサイトを2019年ぐらいから運営していました。
その前はGitHubページでヤモティ.コムだったかなというブログサイトを作ったりしていました。
それとしてヤモティ.東京という前のサイトは、もともとNotionのデータベース上にブログとか、
あるいはプロフィールを書いて、それをRaptusという別のサースを使って、
WebUIだけラッパーをして、それでドメインをヤモティ.東京というのを貼り付けて運用すると。
すごくNotionさえ使えれば運用が簡単という、そんな構成でサイトを作っていたんですね。
これよかったんですけど、いくつか問題があって、
一つはNotionとRaptusの2つのサービスに課金していて、
特にRaptusに1000円ぐらい月払ってるんで、合計1500円ぐらいかな、コストがかかっていましたと。
年間にすると18,000円なんで、結構な金額をかけて、わざわざサイトを運営してるなという状態。
あとはUIの自由度がRaptusというサービス、その上でCSSが書けるんで、
CSSをいじったりしてたんですが、その自由度っていうのはどうしても上からラップしてるんで、
Notionに依存してしまうと。
あとはライティングの環境みたいなところもNotionに依存していると。
あともう一個でかい問題は、大阪に引っ越したのに.Tokyoというドメイン使っていて、
これ結構昔、いろんな人に突っ込まれたんですよね。
あとは先ほどちょっとお話しした、いろんなコンテンツが別のプラットフォームに散らばってるんで、
これを自動的にうまく束ねるようなポートフォリオを作る仕組みを、
何か構築できないかなと思っていて。
こういった自分の問題を解決するために、まずは自分で流行りのAIを使って、
どういう風にコーディングできるかなみたいなところを試して、
構築をしてみたというところになってます。
コーディングプロセスとAPIの利用
なのでこの課題の後ろ側が、今回はこのプロジェクトのゴールという形になっていて、
例えばまずサイトを運営するのに、あるいは構築するのにかかるコストをゼロにしたいなと思いました。
あとはUIを自分内に作り直して、何というか満足度があるものを作ったり、
あとは静的なサイトを基本的に構築することになるので、
GitHubとバーセルでホストすれば楽々運用できるだろうなっていうのは、
自分としてイメージを持ってました。
次の問題、大阪という案もあったんですけど、自分のサイトなんで、
あとはどこに引っ越しても大丈夫なように、
yamty.meというのを新しく取り直して変えました。
あとこのさっきの外部サイトですね、
PodcastとかNoteとか静かなインターネットとか、
いろんな場所で自分の情報が更新されたものを自動で束ねたい。
もう一つ、せっかくこのプロジェクトで自分でコーディングするようになったら、
自分が使ったことない技術スタックを入れたいなと思って、
GitHub Actionsという、この自動化というか、
更新作業、ルーティンで後ろ側で行うような仕組みを作る際に、
これ使ってみようと思いました。
あと最後、思い立ってから3日ぐらいでリリースしないと、
やる気がどんどん減っちゃうんで、
夏休みをいただいたお盆の間に、
頑張って作り上げようというゴール感で進めました。
Viveコーディングを実際に始める前にですね、
元々Viveコーディングを自分の会社の中でも、
社内ツールを作るためにやっていたりしたので、
なんとなく勘どころがあって、
Viveコーディングはやっぱり雰囲気でやるんで、
裸で臨むと品質にものすごいばらつきが出たり、
思った通りのものができないなってことが結構起きます。
なので、いくつかの自分の勘どころみたいなものを、
初めに準備するのが大事で、
それを言語化すると4つあったかなと思っています。
1つはプロダクトの使用書というか、
要件定義書だったり、あとデザインですね、
UIを今回自分なりにちゃんと作りたかったんで、
デザインってどういう要求があるんだっけ、
みたいなのを言語化したり、
またこれらを基にプロジェクトして、
どういう順番でものを作っていくのかってところも、
初めにしっかり作り込むっていうのが、
すごく重要だなと思っています。
これがないまま思った順に作らせると、
結構壊れたり、自分のイメージと乖離したものが
できることが多いので、
初めに自然言語でしっかりAIに作らせたいもの、
これを定義しておくっていうのが、
大事かなと思っています。
特にデザイン、UIの部分については、
言葉で伝えるのはすごい難しいので、
サンプルのUIをちゃんと準備しておく。
もっとできるんだったら、
できればいいですけど、
デザインシステムをしっかり準備するのが、
一番精度とか品質を上げるには近道だと思っています。
ただ、僕にはそういうスキル、
デザインシステムを組み上げるスキルがないので、
まずはサンプルUIとか、
あとはカラーコーディングとか、
その辺りは十分準備をして望んでいました。
この辺りを作った段階で、
まずLLMと会話しながら、
一回雑にものづくりをするっていうのをしています。
だいたいバージョン1は全部捨てる前提で作ってみて、
だいたいの場合はイメージから遠いところに
ものが仕上がるので、
全部捨てるってことをしますと。
捨てた上で4つ目なんですけど、
作り直すために、
イメージと乖離したポイントっていうのが
必ず出てくるので、
これを1つ目のドキュメンテーションに、
しっかり反映し直すってことをしますと。
この辺りが一週、二週準備として仕上がってくると、
そこからコーディングをしていく際に、
結構思った通りの出来っていうのが、
仕上げやすいというふうに思っています。
この小さとして、
これちょっと今映してる狭い画面、
ちっちゃい画像なんですけど、
これ私がコーディングするときに使ってる、
カーソルっていうエディターの画面なんですが、
ルートのリポジトリの下にDocsというリポジトリがあって、
その中にまずはドキュメントをしっかり準備していってる様子が、
見えるかなと思っています。
今回もドキュメント元に作って捨ててっていうのは、
3週ぐらい回してやっとできたので、
ただ3週回すと言っても、
自分の中ではドキュメント書いて、
作ってって言って、
作り上げていったら微妙なものになったんで捨てるみたいな、
その作業を2回ぐらい回すってだけなので、
自分的な負担は、
LLMがコーディングしてる間待ってる時間ぐらいなもので、
そこはそんなに負担がないかなと思っています。
こういうの作っていくうちに、
AI側からも技術構成としてこうしたらいいんじゃないみたいなのは、
提案としてもらえるので、
そういったものもLLMに考えさせて、
仕様書の中に含めていくみたいな、
作る、ドキュメンテーションする、
これをできるだけ距離を近づけて、
フィードバックサイクルを回すってのが、
すごく自分とLLMだけの関与だとしやすいなって思っています。
今回はこのエディターカーソルで、
GitHub Action使って、
ホストはVercelで、
他にリポジトリをアップする先ってのはGitHubだけなので、
すごい質素で簡単な技術構成できたかなと思っています。
あと、過去ブログとして運用してたのは、
Notion側にコンテンツがたまっているので、
そこのNotionのコンテンツをどう引っ張ろうかなと思ったときに、
いろんな方法があるんですけど、
今回Notion APIで一括でガーッと持ってくるようなスクリプトを、
これもLLMのほうに準備してもらって、
それを回して過去のブログのコンテンツとかを持ってきました。
Notionの活用と課題
ただ、Notionでブログとかを管理していると、
例えばURLをブロックの形式、
URLブロックみたいなカードみたいなものに変換してあったり、
あとデータベースが記事の中に埋め込まれていたりすると、
そのあたりのコンテンツ、
うまく持ってこれなかったりするんですよね。
このあたりは結構苦戦するというか、
Notion何でもできてしまったり、
結構かゆいところに手が届く反面、
これをマークダウンコンテンツにもっかい戻そうとすると、
マークダウンでは表現しきれないので、
ちょっとうまくコンテンツが持ってこないということが、
どうしても起きてしまうという、
ここに結構悩まされまして、
今も過去のブログで、
少しデータベースを使っていたり、
あるいは外部リンクを結構たくさん貼っていたりするようなコンテンツというのは、
ちょこちょこ自分で見直して、
それを引っ張って持ってきたり、
書き直したりするというのが必要なので、
ちょこちょこ必要に応じて進めているというような感じです。
それだけNotionって結構いろんな表現をしているんですけど、
それだけNotionって結構いろんな表現力があるサービスだなと思いつつ、
コンテンツの遺憾性が低いんだなというのは、
これ改めて自分がやってて感じたことになります。
Viveコーディングの利点
そんなこんなでできたブログ、
あるいはサイト、
このブログ自体もこのサイトの一部として、
デザインだったりを構成し直したんですが、
このViveコーディング全体のメリットみたいなところで、
メリットとしては開発者と対話するように、
LLMと対話するだけでコーディングができていく、
あるいは自分で確認しながら、
どんなに細かいことでも簡単にフィードバックできるので、
そこはすごくいいメリットだなと思っています。
自分のような職業エンジニアではない人間からすると、
ちょっとかじったことがある程度の人間からすると、
自分にできなかったこととか、
理解が及んでいなかったことに対して、
そのケイパビリティが保管できる、
早く開発できるなどがすごいメリットだなと思っています。
一切コーディングをかじったことがないとか、
さっきのGitHubの使い方が分からないとか、
そういうレベルの状態だと、
もう少し距離があるように感じられる気はするんですが、
少しでもかじったことがある、
あるいは自分で何かサービスを簡単に作ったことがある人だと、
かなりViveコーディングの恩恵というのは、
大きいんじゃないかなというふうに思っています。
一方でデメリットのところなんですけど、
今回Viveコーディングの恩恵を受けるために、
代わりにというか、
ためにはコード全体を理解して、
自分で管理するということは手放したんですよね。
一切分からないという状態です、今は。
これって手放さないでやる人というのもいて、
それはそれでAIに自分の一部を代替させているという、
そういう使い方の人もいると思うんですけども、
本当にサービスをスクラッチでゼロから作って、
Viveコーディングするという点でいうと、
コード全体を自分で把握していくみたいなことをやりだすと、
やっぱり時間をかけずに済むとか、
自分がやらなくていいことを増やすというところに対して、
得られるメリットはどんどん少なくなっていくので、
僕は今回あえて一切理解しないという方針を取りました。
なので、今回のコーディングにおける規律とか、
構成みたいなものも、
当然一緒にコーディングしている最中に見るものもあるんで、
雑屋は分かるんですけども、
詳細についてはほとんど理解していません。
なので、バーセルでデプロイが失敗したときとかに出ている
エラーメッセージとかも、
自分で読みはするけど、
それってそのままLLMに投げて、
こういうエラーが出ているから直してみたいなのを投げて、
ソースコードを直接修正させるみたいな使い方をしているので、
本当に自分は理解をしない。
代わりに全部、
俺じゃなくてお前の責任だとLLMに押し付けるような
コーディングの仕方をしています。
CatNoseさんの影響
これは普通のコーディングとか、
普通のエンジニアリングとは全く逆なんで、
普通のエンジニアリングしようと思ったら、
いかにソースコードの解像度を上げて、
問題が起きえる場所みたいなところに対して、
ヒートマップみたいなものを頭の中に用意しておけるか、
これが大事だと思うんですけど、
今回についてはそれは真逆のプロセスを取っています。
今後もメンテナンスしようとか、
ちょっと何か変えようと思ったときには、
僕は日本語でそれを依頼するだけ、
なので、自分はほぼ役に立たないなと思いつつ、
いわゆるLLMでバイブコーディングするっていうのは、
それが逆にメリットでもあるので、
そういうメリハリは大事やんかなって思ってますね。
この感覚は今年ですね、
自分の自家用車をちょっとぶつけて、
何か直そうかなと自分で思ったんですけど、
ちょっと無理だなと思って、
それを修理工場、板金の修理工場に持ち込んで、
直してもらったんですけど、
その感覚に似てるというか、
自分がこの構造物に対しての理解を持ってないがゆえに、
直せないっていう、
何かその状態にすごい近いなと思ってます。
というわけで、このサイトができてまして、
特にタイムラインのUIとか、
細かいところ結構こだわって回収したりしました。
何よりコストもゼロになったんで、
すごい財布に優しいなと思っています。
あと、自分で理解するのを諦めるって、
さっきデメリットのところで話したんですけど、
一方で、当然LLMと会話していくんで、
LLMって何か自分が作業した後に、
絶対何しましたってまとめて出してくれるんですよ。
それもあって、結構こう、
自分は理解しようと思ってなくても、
彼らがプッシュでくるんで、
何か面白いな面白いなってふんふん読んで、
割と何となく雰囲気を理解できるってところはあります。
ということで、新しくできたサイトなので、
ぜひ、もし私にご関心がある際には、
ここを見に来ていただけると嬉しいかなと思ってます。
最後に、このUIを作ろうと思ったときに、
一番参考にしたサイトがあって、
それが昔このPodcast、
2年ぐらい前に出ていただいたCatNoseさんっていう、
静かなインターネットとか、Zenとか、
そういうサービスの開発者のCatNoseさんの
ポートフォリオサイトのCatNose.meっていう、
このサイトがめちゃくちゃ綺麗なタイムラインでできてまして、
これちょっと見せれるかな。
ちょっと画面を切り替えたんですけども、
これがCatNoseさんの作ったCatNose.meという、
ご自身のポートフォリオのタイムラインに表示しているサイトなんですけど、
すごい綺麗というか見やすくて、
こういうのを自分でも作りたいなと。
あと、自分の場合は外部サイトの更新みたいなのを、
これに束ねる形で表示したいなと思って、
ものすごく参考にさせてもらいました。
なので、改めてこの場でも御礼を申し上げたいなと思っています。
CatNoseさんとのPodcastも、
過去収録したものまだ聞けるので、
静かなインターネットすごい良いサービスなんで、
ご関心ある方は聞いてもらえればなと思っています。
ということで、だいぶ柔らかい話なんですが、
私が夏休みにトライしたバイブコーディングの話をさせていただきました。
この件について、他に質問とかコメントとかありましたら、
お問い合わせの箱の方からいただければと思います。
それでは。
17:42

コメント

スクロール