- Published on
【後編】BTCインサイト──次世代CMS「Sanity」で公式サイトを作るまでの泥臭いバイブコーディング記
- Authors
- Name
- yutaro
- @yutaro21jp
前回の記事「【前編】BTCインサイト──次世代CMS「Sanity」で公式サイトを作るまでの泥臭いバイブコーディング記 」では、次世代CMS「Sanity」やヘッドレスCMSの仕組みについて、僕なりに理解した内容を整理しました。
理屈としてはとてもシンプルで、
- データはCMS（Sanity）で管理する
- 見た目はNext.jsで自由に作る
という“分業スタイル”さえ理解できれば、あとはスムーズに進むはず……。
少なくとも、この時の僕はそう思っていました。
ですが、現実はそんなに甘くありません。
いざ実装に入ってみると、SanityのStudio機能がうまく立ち上がらなかったり、立ち上がったと思えば記事のデータがうまく反映されなかったり、なんとか表示されたとしてもどこかが壊れている──そんな状態の連続でした。
そして気づけば、
「Sanity導入 → うまくいかない → ゼロからやり直し」
このループに完全にハマっていました。
「さっきまで動いてたのに、なんで？」
「どこを触ったら壊れたのか分からない」
「もう一回最初からやった方が早いかも…」
そんなことを何度も繰り返しながら、気づけばパソコンの前に何時間も張り付いていたのを覚えています。
前編で感じていた「なんだかいけそう」という感覚は、ここで完全に打ち砕かれました。
そしてこの後、僕はようやく一つの重要な結論にたどり着きます。
それが、
「バイブコーディングで車輪の再発明は不要。あるものはうまく使え」
という考え方でした。
この後編では、そんな試行錯誤の中で僕がどのようにして行き詰まりを抜け出し、最終的に形にすることができたのか──そのリアルな過程をお話ししていきます。
Sanity Studioがうまく動かない問題
最初にぶつかった壁は、やはり Sanity Studio でした。
本来であれば、
sanity devを叩く- ローカルサーバーが立ち上がる
- ブラウザでStudioが開く
……という流れのはずなのですが、これが思ったように進まない。
コマンドは通ったはずなのに、ブラウザに何も表示されない。
あるいは、Studioは開くけど、記事データが反映されない。
なんとか動いたと思っても、今度は別の場所でエラーが出る。
とにかく「一応動くけど、どこかがおかしい」という状態がずっと続いていました。
さらに厄介だったのは、エラーの内容です。
表示されるのは英語のログ。
それをGeminiに投げてみても、「なるほど、それっぽい」説明は返ってくるものの、ピンポイントで解決にはつながらない。
修正してみる。
すると、今度は別のエラー。
この繰り返しでした。
何が原因なのか分からない。
どこを直せばいいのかも分からない。
この「原因が分からないストレス」が、一番きつかったですね。
無限ループ突入──ゼロからやり直す地獄
そして、気づけば完全にこの状態に入っていました。
「とりあえず、もう一回最初からやり直そう」
フォルダを削除して、再インストール。
npm create sanity@latest をもう一度実行。
さっきよりは理解できている気がする。
今度こそいけるかもしれない。
……でも、また詰まる。
「これでいけるかも」 → 崩壊
「もう一回やればいける」 → 崩壊
「何が正解か分からない」 → 完全停止
このループを、何度も何度も繰り返しました。
GitHubのリポジトリも作り直し、環境もリセットし、また最初から。
冷静に振り返ると非効率なのは分かるのですが、そのときは
「やり直した方が早い」
と本気で思っていました。
でも実際は、同じところで何度もつまずいているだけだったんですよね。
未完成の実装が一番危険だった話
さらに厄介だったのが、「一応動いている状態」で進めてしまっていたことです。
画面には表示されている。
だから、次に進んでしまう。
でも実際には、
- データ取得の方法が間違っている
- スキーマの設計がズレている
- フロントとバックエンドの接続が不完全
といった“見えない問題”を抱えたままでした。
その結果、後から一気に崩れる。
ここで学んだのは、とてもシンプルなことです。
「動いた＝正解ではない」
そしてもう一つ。
土台がズレていると、あとで全部壊れる
これはバイブコーディングに限らず、かなり重要なポイントだと感じました。
転機──既存テンプレートを使うという発想
そんな中で、ようやく一つの考えにたどり着きます。
「これ、全部自分で作る必要あるのか？」
ここまで、僕は完全にゼロから構築しようとしていました。
でもSanityもNext.jsも、世界中で使われている技術です。
ということは、
すでに“正しく動く形”が存在しているはず
そう思ってGitHubを探してみると、案の定ありました。
Sanity × Next.js の構成が最初から整っているテンプレート。
しかもスターもついていて、実績もある。
試しにそれを使ってみると──あっさり動く。
今まで何時間もかけていたものが、最初からほぼ完成形として存在している。
そして、そのコードを一つずつGeminiに解説させながら読んでいくと、「なるほど、こういう構造だったのか」と、理解が一気に進みました。
ここでようやく、状況が変わり始めました。
一気に進んだ理由（本質）
なぜ、ここから一気に進むようになったのか。
理由はシンプルです。
- 正しい構造が最初から整っていた
- エラーが圧倒的に減った
- “直す”ではなく“理解する”ことに集中できた
これに尽きます。
そして、ここでGeminiの役割も変わりました。
それまでは「エラーを直すためのツール」として使っていたのですが、
コードを理解するための補助役
として使うようになったんです。
この使い方に変えたことで、効率が一気に上がりました。
今回の最大の学び
この一連の経験を通して、僕がたどり着いた結論はこれです。
バイブコーディングで車輪の再発明は不要。あるものはうまく使え。
ゼロから作ることにこだわっていました。
でもそれは、ただの遠回りでした。
すでに動くコードを使う。
それを理解する。
必要な部分だけ変える。
この方が、圧倒的に早く、そして深く理解できます。
テンプレートを使うことは、ズルではありません。
むしろ、
理解を加速させるための最短ルート
でした。
実際、プロのエンジニアでも既存のコードやライブラリを使うのが当たり前です。
バイブコーディングの正しい戦い方
ここまでやってみて感じたのは、
- ゼロから作ることにこだわる必要はない
- 正しい土台を使うことが重要
- Geminiは“理解を補助するツール”として使うべき
ということです。
バイブコーディングは、“全部自分で作る技術”ではありません。
“うまく組み合わせる技術” です。
ここから先は、Sanityだけでなく、Next.jsやTailwindを中心とした構成で、さらに実用的なサイト作りへと進んでいきます。
そして最終的には、この仕組みを応用してライトニングペイウォールの実装までたどり着くことに・・（これは自分でも驚きました！）。
それについては、また別の記事で詳しくお話ししていきますね。