エンジニアではない私が、バイブコーディングで本物の個人サイトを作った方法

Notionサイトの有料プランとSquarespaceの間を行ったり来たりしながら、どちらにもだんだん苛立ちが募っていました。Notionは遅くて、少しでもカスタムしたいと思った瞬間に窮屈さを感じました。Squarespaceはなぜかもっと高いのに自由度は低い。私が本当に欲しかったのは、自分のものだと感じられて、毎月クレジットカードを消耗させず、メンテナンスではなく執筆に集中させてくれる個人サイトでした。でも作り方は全く分かりません。エンジニアではないので。だからClaudeに相談して、一緒に考えてもらうことにしました。

中間地点は存在する。ただし、それを頼めることを知らないといけない

エンジニアではない人の多くが本物のウェブサイトを欲しがって、結局2つの残念な選択肢のどちらかに囲い込まれます。ドラッグ&ドロップ型のプラットフォーム（Squarespace、Webflow、Notionサイト）は安く始まってすぐに高くなり、しかも本当の意味では何も所有できません。DIYの世界は徹頭徹尾エンジニアファーストです。このドキュメントを読め。このコマンドを実行しろ。このファイルを設定しろ。私はライターでコンサルタントです。コードは読めません。でもサイトにどう見えてほしいか、どう感じてほしいかは分かっているし、自分の言葉には自分なりのこだわりがあります。

中間地点（自分が本当に所有していて、自分がデザインして、信頼できる場所でホスティングされていて、開発者になる勉強をしなくていい本物のウェブサイト）は、既存のツールが埋めていない穴です。会話の中にAIが入ってくるまでは。

最初に試して、嫌になったもの

ウェブサイトとしてのNotion。読み込みが遅すぎました。テンプレートの外に出たいと思った瞬間、カスタマイズの限界が来ます。コストもじわじわ上がっていました。

Squarespace。テンプレートは良く見えました。ところが実際に必要になるプランで料金を計算して、しかもこれを永遠に払い続けることになって、将来の移行はどれも痛みを伴うと気づきました。

コードを学ぶという選択肢。1時間ほど頑張って、タブを閉じました。

どれもが唯一の選択肢のように感じられました。問題はツールではありません。実際にウェブサイトを仕事で作っている人たちが私の目線で話してくれず、私と同じ目線の人たちは、少なすぎるものに多すぎるお金を払っていたことです。

答えを出してくれたClaudeとの会話

そこでClaudeと腰を据えて、欲しいものを説明しました。個人サイトで、自分のもので、安くて、速くて、カスタマイズできて、書いたらちゃんと公開される場所。最初に返ってきた答えは「GitHubでホストしてVercelでデプロイ」でした。

すぐに押し返しました。「GitHubってエンジニア向けすぎませんか。私はコーダーじゃないんですが」

Claudeが説明してくれたのは、GitHubはいちばんシンプルに言えばフォルダだということです。オンラインにあって、すべての変更の履歴を残してくれるフォルダ。使うのにコードを書く必要はありません。言葉の入ったファイルを置けば、GitHubが保管してくれます。Vercelはその上のレイヤーです。フォルダを見張っていて、何かが変わるたびに、中身を誰でも訪問できる本物のウェブサイトに変えてくれます。この2つを合わせて、個人サイトの規模なら月0円。これが突破口でした。ホスティングが手の届かないものではないと分かった途端、残りのスタックは質問1つずつで決まっていきました。

「サイト本体のフレームワークは何を使えばいいですか」。ClaudeはAstroを提案しました。静的で、速くて、コンテンツサイト向けの設計。Claudeがよく知っているフレームワークなので、テンプレートもレイアウトもルーティングも、私が一切触らずに書けます。

「デザインはどうしますか」。Tailwindです。私がテイストの注文を出すたびに、Claudeが見た目を作り直してくれます。「このカードをもっと温かく」「もう少し余白を」「白よりクリーム色を多めに」。どの注文も数秒で適切なCSSクラスに変わりました。

「マークダウンファイルで下書きは書きたくありません。実際、どこで書けばいいですか」。Notionです。すでに思考の場になっている画面を使い続ける。NotionからサイトへのパイプはGitHub Actionが担うので、自然に感じる場所で下書きして、公開は勝手に起きるようにできます。

「デプロイされたことはどうやって知るんですか」。Telegramです。Claudeが、新しい記事が公開されたら通知してくれるボットを組み込みました。

どのピースも、私が尋ねた質問から始まりました。どの答えも、Claudeが何かを提案して、なぜ合うのかを説明して、私に実際に求められること（たいていは何もありません）を教えてくれるものでした。ドキュメントは一度も読んでいません。設定ファイルも一度も書いていません。欲しいものを説明したら、Claudeが作ってくれました。

最終的に落ち着いた構成

スタックは5つのピースに落ち着きました。どれも私の質問から生まれたものです。

Astro がサイトのフレームワーク。マークダウンファイルを本物のウェブサイトに変えます。
Vercel がホスト。GitHubリポジトリを見張っていて、何か変わると再デプロイします。
Tailwind が見た目の担当。今あなたが読んでいるクリーム色の背景、深い緑、温かみのあるタイポグラフィは、私のテイストの注文に基づいてClaudeが書いたTailwindクラスです。
Notion が私の執筆の場。ブログのアイデア、下書き、公開済みの記事はすべてContent Vaultというデータベースにあります。マークダウンは私が流暢に書ける言語ではありませんし、書ける必要もないのです。
GitHub Actions が全体をつなぐ結合組織。Notionで下書きをReadyにすると、Claudeが書いたActionがそれを拾い、画像パイプライン（こちらに書きました）でイラストを生成して、マークダウンファイルをリポジトリに書き込み、コミットしてプッシュします。Vercelがプッシュを検知して1分ほどでサイトを再ビルドし、記事が公開されます。Telegramボットがスマホに通知をくれます。

NotionでReadyをクリックしてから記事が公開されるまで、私がやらなくていい作業が約3分。最初のNotionサイトへの苛立ちから、動く個人サイトまでは、上のGitHubのような会話を重ねた週末が数回分でした。

現在のトラフィックでの月額コストは、だいたい0円です。

デプロイの後、キッチンカウンターで満足そうな表情でスマホを確認するJay

出荷の瞬間。NotionでReadyをクリックして、ラップトップから離れて、サイトが再ビルドされて記事が公開されたらTelegramの通知を見る。

同じパターンを自分の仕事に使う

この通りのスタックである必要はありません。パターンはこうです。本当に欲しいもの（安い、速い、カスタマイズできる、プラットフォームに縛られない）をClaudeに伝える。何かが難しそうに聞こえたら押し返す。そして「技術的すぎる」と判断してしまう前に、Claudeに説明してもらう。私を止めかけたのは「GitHubってエンジニア向けすぎませんか」という質問でした。Claudeがその答えに使った2分が、すべてを変えました。

東京のコーヒーショップの窓際の席で、ラップトップに映るウェブサイトのモックアップを確認するJay

まず1つのピースから。摩擦を感じたら次を足す。スタック全体は1年かけて、会話1つずつで組み上がりました。

今いる場所に応じた、いくつかのスタート地点を紹介します。

いちばんシンプルなスタック：Notionと無料のVercelドメイン。 Notion組み込みの「ウェブで公開」機能を使って、Vercelのドメインを向けます。コードはゼロ。読み込みは遅めでカスタマイズ性も低いですが、20分でオンラインになれて、物足りなくなったら卒業できます。

中間のスタック：AstroとVercelと、リポジトリ内のマークダウンファイル。 Notionはいったん飛ばします。Claudeに記事を直接リポジトリのマークダウンファイルとして書いてもらいます。GitHubにプッシュすればVercelがデプロイ。もっとコントロールと速いページが欲しいけれど、Notionの公開フローにはまだ手を出したくない人に、いちばんクリーンなスタックです。

フルスタック：私のと同じ形。 下書きはNotion、公開ワークフローはGitHub Actions、イラストは画像パイプライン、デプロイはVercel、通知はTelegram。週1回以上のペースで公開していて、機械的な作業を消して執筆に時間を使いたい人に最適です。

飛ばしていいスタック：WordPress。 まだ使い道が残っている場面もありますが、重いですし、AIツールはモダンなフレームワークほどWordPressを知りません。執筆よりプラグインの世話に時間を使うことになります。2026年にゼロから始めるなら、飛ばしましょう。

変えるとしたらここ

このスタックにも、まだ粗いところがいくつかあります。

NotionからGitHubへの受け渡しで、ときどきフォーマットが落ちます。リストが段落になり、リンクがhrefを失い、コードブロックが言語ヒントなしで出てきます。よくある問題を捕まえる小さなPythonスクリプトをClaudeが書いてくれましたが、完璧ではありません。長い記事は公開前にもう一度見直す価値があります。

画像パイプラインは記事ごとに1枚の画像を生成しますが、何度も再生成するとコストがかさみます。Geminiの無料枠で始められますが、公開する量が増えると有料プランが必要になります。予算に入れておきましょう。

Claudeと私は、まだいいプレビューフローを作れていません。公開前の記事の確認は、ClaudeにプレビューブランチをVercelにプッシュしてもらって、ステージングURLでレンダリング後の姿を読むというやり方です。不格好です。ホットリロード付きのローカルAstro開発サーバーの方がきれいでしょう。たぶん次にClaudeに頼むのはそれです。

このスタックは、ターミナルのコマンドをコピーすること（またはClaudeに代わりにやってもらうこと）に抵抗がないことを前提にしています。各ピースが複雑さの大半を隠してくれますが、全部ではありません。「このエラーはどういう意味だろう」という瞬間は何度かあります。貼り付ければClaudeが数秒で解決してくれますが、起きることは起きます。

出典: