WebディレクターとしてHTML/CSSは触れるし、FTPもhtaccessも業務で使ったことがある。でも「ゼロから自分一人で立ち上げる」はやったことがなかった。コーダーに渡す手前までは動けるけど、その先はその道のプロの領域、みたいな感覚がずっとありました。
そんなとき、「AIを使えば誰でもサイトが作れる」という話を耳にした。もともと新しいものには乗っかってみたい性格なので、「本当に？」と思いながら、とりあえずやってみることにしました。
AIを壁打ち相手にしながら、一人でゼロから作ってみた記録です。
正直、最初は半信半疑だった
ChatGPTもClaudeも日常的に使っています。でも「サイト構築」となると、ちょっと使い方が変わる気がしていました。
知識として持っている部分は確かにある。でも全体の段取りを自分で組んだことがない。「次に何をすべきか」の地図が自分の中にないまま進んで、途中で詰んだら？というのが正直な不安でした。
調べれば情報は出てくる。でも技術的に躓いたとき、トライ＆エラーで時間だけが過ぎていく——そういう展開が容易に想像できました。AIに聞けば多少はショートカットできるか、くらいの気持ちで、「まあ詰まったら聞いてみればいいか」と始めたのが実態です。
まず設計をClaudeと進めてみたら——想像以上だった
最初にやったのはサイトの設計です。「何を作るか」「誰に向けて作るか」「どんな構成にするか」。ここをClaudeと対話しながら進めました。
ディレクターとして企業案件をやるときは、こういう設計の詰め方には慣れています。でも自分個人のサイトとなると、意外と手が止まる。「誰かのための判断」ではなく「自分のための判断」になった途端、基準が曖昧になる感じがありました。
たとえばドメインとサーバーの取得先。仕事でドメイン提案はしたことがあっても、個人で一から構成を組んだ経験はなかった。
サーバー一つとっても費用はかかる。個人用途に最適な構成はどこなのか——そういう、誰に聞けばいいかわからない疑問が次々出てくる。Claudeに聞いたら、将来の事業サイトとの棲み分けまで含めてサーバー選定を整理してくれました。詰まりかけたところで、すっと答えが出てくる感覚でした。
構成も同じで、「こういうサイトを作りたい」と話しかけると、自分では気づいていなかった論点を向こうから出してくれる。議事録を取りながら上司と壁打ちしている感覚に近い。ただ、上司と違うのは「整理のスピード」で、頭の中でぐるぐるしていたことが、数往復の会話でかなりすっきりする。思考整理のコストが、体感で全然違いました。
一番驚いたのはワイヤーフレームです。「トップページは3つの導線で構成したい。ブログ・実験LP・分析ログの3本柱で」と方向性を伝えた上で、一緒に設計を詰めていきました。こちらの意図を汲んだ上で、GA4の計測ポイントをどこに置くか、イベント名の命名まで提案してくれた。命名規則って、ちゃんと考えようとすると地味に時間がかかる部分なので、これは助かりました。
自分で方向性を持って臨めば、AIは壁打ち相手以上の動きをしてくれます。下がその成果物です。
「AIに聞いたら答えが返ってくる」じゃなくて、「AIと話しながら考えが整理され、形になっていく」。そっちに近いです。
構築フェーズも、AIを壁打ち相手にしたら詰まらなかった
設計が終わったら次は構築です。ローカル環境を作って、テーマを入れて、GA4を設定して——という流れなんですが、ここで早速「LocalWP」という名前が出てきました。
恥ずかしながら、知らなかったというのが正直なところです。WordPressはもちろん知っているし、WordPress.comも知っている。でも実務では、サーバにアップされたテスト環境やstg環境しか触ったことがなかった。ローカル環境をどう構築するのか、まずここで少し手が止まりました。
だからこそ、Claudeに聞いてみることにしました。
ローカル環境と本番環境の違いは何か。機能面の差は何か。会社でエンジニアの方に相談したときのように、すっと回答が返ってくる。違いが整理できれば、ローカルでやること・本番に移してからやることの分類も見えてくる。サーバーは契約した時点から費用が発生するので、ローカルでできることを先に進めてから契約しよう——そういうスケジュールの組み立てもしやすくなりました。公開までのタスク全体をざっと洗い出す作業も一緒にやりましたが、全体像が見えると動きやすい、というのはここでも同じでした。
手順サイトを探せば情報は出てくると思います。でも手順サイトが返してくれるのは「一般論」です。Claudeに聞くと「今の自分の状況に対する答え」が返ってくる。
たとえばLocalWPのインストール中に見慣れない選択肢が出てきたとき、「これはNo thanksでいいの？」とそのまま聞いたら、こう返ってきました。
「どちらでも動作に影響はありません。エラー報告をLocalWP開発チームに送るかどうかの確認です。気にしなければ『Turn on error reporting』、送りたくなければ『No, thanks』で。どちらでも次に進めます。」
複数のサイトを読み比べる手間が、まるごとなくなる感覚でした。
「自分でもできる」と思えた瞬間
正直、詰まる場面はありました。設計の初期段階で、ブログと実験レpoートの投稿の扱いを整理しきれず、あとから実験レポートをカスタム投稿タイプで作り直すことになりました。「どこかで詰むだろう」とは思っていたので想定内でしたが、「どう作り直すか」もClaudeと一緒に整理しながら進めたので、止まらずに済みました。
触り慣れていないPHPのテンプレートも、「どのファイルのどの箇所を修正すればいいか」を聞けば大体の見当はつく。細かい指示をこちらがしっかり出さないと意図が伝わらない場面もあって、どうしようもないときは手で直しました。AIに丸投げすればいいわけでもない、というのも実感しました。コーディングにおけるAIの使い方については、別途検証した記事でまとめていく予定です。
最初の問いに、ここで一度答えておきます。
「AIでWebサイト作れるの？」
——答えはYesでした。しかも、ゼロから始めた割にはかなり短時間で。ローカル環境の構築からGA4の実装まで、エンジニアの領域だと思っていたことが、一通り自分でやりきれました。
ただ、やってみてわかったのは「AIに任せればいい」ではないということです。チャットで質問するのではなく、設計のドラフトを渡して懸念を整理させて、必要な判断は人間がする——そういう使い方に自然と変わっていきました。エンジニアが不要になるわけではなく、正しい知識がないと正しい判断は下せない。それはむしろ今回の実験で再確認したことです。
まだ実験は続く——次はGA4で計測する
このサイトのコンセプトは「作って終わり」ではありません。GA4で計測して、改善して、また試す——そこまでを実験と捉えています。
ユーザーがどこをクリックして、どこで離脱するか。そういった行動を数字で見ていく予定です。「作った」から「測る」へ。
計測・改善フェーズも、たぶん同じようにAIと進めていきます。GA4の読み方も、改善の仮説の立て方も、壁打ちしながら。その記録もここに残していくつもりです。
「AIを使ってみたいけど、何から始めればいいかわからない」——そう感じている人には、かなり再現性のあるやり方だと思っています。この実験が、少しでも参考になれば。続きはこのサイトで。