AIガイドとAIで実装できることに関するコンテンツを含むチャンネル: https://t.me/claudedevolper
Claude Codeがどのようにしてサイトを完全に再構築するのを支援したか
以前はTildaでサイトを持っていました。デザイナーはゼロブロックで構築していました。標準的なテンプレートが退屈に見えたからです。新しいレビュー、ブロック、またはページを追加する必要があるたびに、デザイナーに「これを追加してください」と言う必要がありました。記事を追加するのは少し便利でしたが、それでも完璧ではありませんでした。WordPressではGoogle Docsからコンテンツを簡単にコピーでき、すべての画像がサイトにアップロードされます。Tildaでは各画像を手動でアップロードする必要がありました。これはすぐにイライラさせ始めました。結局、サイトは古くなっており、完全に再構築する時期が来たことに気付きました。同時に、プラットフォームを変更することにしました。例えば、長い間使い慣れていたWordPressに移行することです。しかし私は興味を持ちました：Claude Codeが独立してWordPressで完全なサイトを構築できるでしょうか？この質問で彼に連絡しました。Claudeは、原則的には可能だと答えましたが、WordPressは退屈だと言いました。Next.js + headless CMSで最新のサイトを作る方がはるかに良いです。当時、私はそれが何かをはっきり理解していませんでした。Next.jsで高速で便利なプロジェクトを作成することについてはうわさで聞いただけです。理解して試してみるのは有用だと思いました。
スポイラー：すべてがうまくいきました。サイトは機能していて、気に入っています。移行後もSEOトラフィックは下がっていません。
Claude Codeでサイトを構築した方法（ステップバイステップで説明）
実際にはどのように進んだかをお話しします。すぐに警告します：私は開発者ではありません。過去7年間、コンテンツエージェンシーを管理してきました。その前はエディターとマーケティング担当者として働きました。半年前、ヴァイブコーディングにはまり、いくつかの完璧ではないが機能するサービスを作成しました。もっと深く理解する必要があることに気付きました。タスクを「ブラックボックス」に放り込んで、すべてが機能することを期待するのではなく、少なくともプロセスを理解して管理することです。それで私はここにいます。今のところ、相当に表面的に理解しています。ですから事前に言っておきます：記事には、誰かにとって最も単純または愚かに見える瞬間があるかもしれません。いつか私自身がそれを再読み、同じように考えるでしょう。とりあえず、私が知っている通りにやります =）よし、前置きはいいでしょう。さあ、サイトを作りましょう。
ナレッジベース（Knowledge base / Memory bank）から始めました
コードの理解が浅く、エラーをすばやく見つけることができないため、Claude Codeが可能な限り「バカなこと」をせず、順序立てて動作することが重要でした。ですから最初の数時間、私たちはドキュメンテーションだけに取り組みました。どこかでナレッジベース（またはメモリバンク）について読みました。これはプロジェクトについての重要な知識をまとめたmdファイルのセットです：アーキテクチャ、テックスタック、ルールなど。新しいセッションの開始時に、必要なファイルをClaudeに渡します。すると彼はすぐに理解します。セッションの終わりに、ドキュメンテーションを更新するよう依頼します。なぜ1つの大きなファイルCLAUDE.mdではなく、複数の別ファイルなのか？
すべてを1つに詰め込むと、モデルはすぐに多くのトークンを消費し始め、パフォーマンスが低下します。トークンを節約するために詳細を省略すると、情報が不足しているため、モデルはパフォーマンスが低下します。その結果、私はこのようなファイル構造を作りました。
- アーキテクチャ — テックスタック、フォルダ構造、これらのツールを選択した理由。
- パターン — 変数の名前付け方法、コードの整理方法、関数の最大行数（Claudeが一貫して書くため）。
- デプロイ — サイトがどこにどのようにデプロイされるか、サーバーアクセス、Dockerの設定、CI/CD。
- データベース — データの保存方法。
- Gitワークフロー — 「許可なくmainにプッシュしない、dev-branchで作業する」といったスタイルのルール。
- UXガイドライン — 色、タイポグラフィ、「ゼロから要素を考えるのではなく、shadcnから既製のものを使う」というルール。
- ロードマップ — 作業の順序、サイトのページリスト、など。
- プロジェクト — 全体的な文脈：どのようなサイトか、誰のためか、どのような問題を解決するか。
一緒に記入しました。私が欲しいことを言うと、Claude Codeはすべてを説明し、私が承認して編集して、その後保存しました。この段階で、私が当初計画したWordPressではなく、Next.js + headless CMSでサイトを構築することを最終的に決定しました。こちらは、architecture.mdファイルからの小さなサンプルです（例として）。
Claude Codeでサイト作成時に、ドキュメンテーションと技術仕様にどのように取り組んだか
すべてのドキュメンテーションは英語で行いました。英語はロシア語よりもトークン化が優れているため、ファイルはモデルのコンテキストウィンドウでスペースを取りません。これはトークン節約の観点から重要だと思われました。さらに、私の英語をもう一度練習しました。現在、プロセスは次のようになります。新しいタスクに取り組む場合、まずナレッジベースから必要なファイルをClaude Codeに渡します。彼はそれらを読み、その後、完全なコンテキストの理解で作業します。
Spec driven development — 私たちの主要なアプローチ
ヴァイブコーディングと開発全般について読んだもう一つの重要なことは、最初に詳しくタスクを説明するほど、すべてが正しく行われ、不要なやり直しがない可能性が高いということです。ですから、サイトに関するすべての作業を多数の小さなタスクに分割しました。各タスクに対して、詳細な技術仕様をまとめます。私が何をしたいかを説明すると、Claude Codeが仕様を作成し、私が読んで編集して承認します。ナレッジベースの計画段階で記入したタスクの例を以下に示します。
- localhostでサイトのMVPを作成する（テキストが含まれたページが開くだけ）
- ホームページを作成する
- ブログフィードを作成する
- ブログ記事テンプレートを作成する
- 古いサイトからすべての記事を移行する
- ダークテーマを追加する
- mainブランチのデプロイを設定し、ドメインを接続する
などなど。「最初のタスクを実行しましょう、テンプレートに従って仕様を作成してください」と言うと、Claude Codeは明確化の質問をし、必要に応じてインターネットで情報を検索し、MCP Context7を通じて完全な技術仕様を書きます。私は読んで、わからない部分を見つけて、「バカでもわかる」くらい簡単に説明するよう頼みます。ロジックに穴があれば、それを指摘します。Claudeは自分が正しいことを証明するか、同意して修正します。仕様はすぐに原子的なステップに分割されます：「このファイルでこれを行う、次にテストを実行して、何も壊れていないか確認する」。以下は、Claude Codeが自分自身のために書いた技術仕様の一部です（例）。
これはタスクファイルの例です。Spec はその機能の全般的な説明で、その中には多くの小さな md ファイルが入っていて、それぞれのタスクを一度に 1 つずつ CC に与えています。つまり、余計な情報でコンテキストを詰まらせないようにするということです。
準備が Claude Code でのバイブコーディングプロセス全体の 70% を占めます
正直なところ、この予備作業全て（知識ベース、仕様書、計画）は、私のバイブコーディング時間全体の約 70% を占めます。その後は私に左右されることはほとんどありません。Claude Code がコードを書き始め、コマンドを実行しますが、私はこれをまだ浅くしか理解していないため、リアルタイムでプロセスを適切に制御できません。だからこそ、私は計画段階を最大限念入りに処理しようとしています。計画とドキュメントをよく作成すればするほど、後で予期しないことが減ります。小さなタスクの場合、私は完全な spec を書きません。単に plan-mode を有効にして、Claude Code に行動計画を概要するよう依頼し、それを調整します。その後初めて作業を開始します。plan-mode なしで何もしません。それは典型的なモデルの「アホなこと」から本当に守ってくれます。
Claude Code でのサイト開発はどのように見えるか
私の開発プロセスは非常にシンプルで反復可能です:
- Claude Code で新しいチャットを開始します。
- タスクファイルと Knowledge base から必要な部分へのリンクを送ります。
- Claude Code は私が送ったすべてを研究し、詳細な行動計画を書きます。
- 私がそれを承認します（または編集します）。
- 作業が始まります。
- localhost でサイトを開いて、何が得られたかを見ます。
- ほぼ毎回、最初から必要なものが出てきません。スクリーンショットを撮ってチャットに送り、修正を依頼します。
そしてステップバイステップで各タスクを完了します。ある時点で、Claude Code がサイトを自分で開いて結果を見ることができるように、Playwright と MCP サーバーを接続しました。これは明らかなバグと技術的な問題を修正するのに大いに役立ちます。しかし、単に「見た目が悪い」または「そのように見えない」場合、Playwright では救えません。スクリーンショットを撮り、人間の言葉で何をどこに移動する必要があるかを説明する必要があります。サイトのホームページに丸一晩かかりました。
様々な例を調べ、大体の方向性を理解し、Figma で簡単なスキームを描き、それを Claude Code に送り、似たようなものを作るよう依頼しました。
重要なポイント - ニューラルネットワークが作るデザインが大嫌いです。Lovable、Gemini、Claude - 皆つまらない落書きのようなデザインになってしまいます。
だから私は CC に何も発明しないで、既成の shadcn コンポーネントを使うよう依頼しました。それらはすでに美しくて整っています。このアドバイスは CC 自身がサイト計画の段階で私に与えてくれました =)
シンプルなページを作成し、その後「生き生きとさせました」。このブロックにはスクリーンショットを追加しましょう、ここにはクライアントロゴを、ここにはこのようなアニメーションが入ります、など。
数時間で、ホームページは完全に完成します。この時点で、私はすでに興奮していました。なぜなら、どのような請負業者も人生で一度もこんなに早く何かをしてくれたことがなかったからです。そこでは計算は日数と週単位で進みますが、ここでは私と AI は一晩で処理しました。ただし、夜間の大部分は計画です。サイトへのリンクは提供しません。モデレーションがそれを好まないことを知っています。スクリーンショットを表示します。興味がある人は残りをググります。
最終的に何ができたか、そしてコンテンツの移行はどのように進んだか
結果がとても気に入りました。シンプルでミニマリストなデザインが得られ、サイトは瞬時に読み込まれます。そして最高の部分は、Claude Code とのチャットで通常のメッセージで何でも編集できることです。ゼロブロック、管理画面、手動コーディングはありません。もちろん、すべてが最初から完璧に機能するわけではありません。時々 Claude はすぐに良い結果を出しますが、時々 2～3 回修正する必要があります。しかし、修正があっても非常に高速です。特に、私が開発者ではなく、マークアップ専門家ではなく、デザイナーではなく、それまで Next.js をまったく知らなかったことを考慮すると。インターネットからのアドバイスとモデルのヒントに基づいてすべてを行いました。さらにもう一日は、残りのページ、ブログフィード、すべての記事の移行に費やされました。
ちなみに、コンテンツ移行についてはとても示唆的なストーリーが出ました。
以前、あるプロジェクトで Tilda から WordPress に移行していました。ある人が数日間すべての記事を手動で移行しました。テキストをコピーして、画像をアップロードして、配置しました。Claude Code はこれを 15 分で行いました。私は単に古いサイトのサイトマップを彼に与えました。彼はそれ自体を解析し、すべての記事を抽出し、それらを個別の MDX ファイルに分割し、画像をダウンロードして、プロジェクトの正しいフォルダに配置しました。もちろん、小さな問題がありました。一部の画像は重複し、一部の記事では古い Tilda CDN へのリンクがローカルコピーの代わりに残っていました。しかし、これらの問題は単純でした。我々はさらに 30 分でそれらを解決しました。結果として、ブログ全体の移行は約 1 時間かかりました。
最後の日は仕上げに費やされました。私は CC にサイト全体のコードを研究し、可能な問題、脆弱性、未使用の機能を見つけるよう依頼しました。その後、すべてをリファクタリングしてください。
その後、同様の SEO 監査を実施しました。Claude は何をすべきかを自分で提案し、robots.txt を追加し、サイトマップを作成し、すべてのページにメタタグと OpenGraph を配置しました。Metrica と Search Console などを接続しました。
最後に、PageSpeed Insights でサイトを実行し、その推奨事項をすべてコピーして、CC に完成させるよう依頼しました。
結果は悪くありません。古いサイトのパフォーマンスは約 70 でした。
Payload CMS の放棄: なぜ管理画面が不要であることが判明したか
そしてここからが最も興味深い部分です。
最初の計画によると、サイトには Payload CMS 上の完全な管理画面がある予定でした。しかし、最初の段階で Claude Code はそれを正常にインストールできませんでした - 常にエラーが出ていました。私はこのタスクを後で延期することにしました。万一サイトが全くうまくいかなかったら、管理画面が必要ない可能性があります。
3 日間の集中的な開発の後、私は予期しないことを理解しました。管理画面は実は必要ありません。
なぜ必要でしょう？Claude Code がサイト上でほぼすべての変更を行うことができるなら？
- 「新しいレビューを追加して」→ 追加されました
- 「この記事をブログに公開して」→ 公開されました
- 「ホームページのテキストを変更して」→ 変更されました
- 「ボタンの色を変更して」→ 変更されました
- 「記事の description を更新して」→ 更新されました
彼はこのすべてを迅速に、最初か 2 回目で、ほぼバグなく行います。よく構成された Knowledge base のおかげで、モデルは記事、画像、レビュー、およびその他のデータがどこにどのように保存されているかを正確に知っています。
私と Claude はこれについて議論し、CMS を完全に放棄することに決めました。Payload を削除して、それを忘れました。
ちなみに、開発プロセス全体はラトビアの VPS で進行しました。VPN なしで SSH で接続します - とても便利です。そして、移動中に何か急いで修正する必要があるときは、Termius アプリ経由でスマートフォンから直接ログインします。
結果として: 3 日間で完全に新しいサイト
プロジェクト全体に正確に3日かかりました：
- 1日目 — 計画、ドキュメント、メインページ
- 2日目 — その他のページ、ブログ、記事の移行
- 3日目 — 仕上げ、SEO、バグ修正、本番ドメインへの移行
比較として：10年前、私の最初のWordPressサイトも約3日かかりました。しかし当時はつまらなくて不格好なサイトが出来上がり、私自身が不満でした。一方、今の結果は私は本当に気に入っています — 外観にも、パフォーマンスにも。重要なボーナス：移行後のSEOトラフィックは全く低下しませんでした。移行がスムーズに進みました。技術的な問題もありませんでした。この3日間で、私は多くの新しいことを学びました：ついに、Next.js、shadcn、および現代的なフロントエンド開発が何であるかを理解できました。現在、サイトのあらゆる変更をClaude Codeを通じて行っています。必要なことを説明するだけで、彼が編集してくれます。localhostで結果を確認して、問題がなければmainへのプッシュをリクエストします。その後、サイトはDockerを通じて自動的に更新されます。もう1つの大きなボーナス — 今、サイトは完全に私のものです。私はTildaに全く依存していません。現在のVPSに何か起きても、すべてのコードはGitHubにあります。リポジトリを別のサーバーに移動すれば、サイトが再び動作します。
Claude Code のガイドやコンテンツを扱うチャンネル。制限が10倍削減される場合などのニュースや、Claude を通じてプロジェクト向けに実装するツールについて投稿しています。チャンネル： https://t.me/claudedevolper
