このサイト「AIためすラボ」は、プログラミングを本業としない会社員が、Claude Codeというツールを使って作りました。この記事では、その制作の過程を、うまくいったことだけでなく、つまずいたことややり直したことも含めて記録します。
これは「AIに頼めば誰でも簡単にサイトが作れる」という話ではありません。 実際には、AIが間違えた箇所を直したり、判断を自分で決めたりする場面が何度もありました。 そのままの過程を残すことで、これから試す方の参考になればと思って書いています。
この記事の対象者
- ホームページを自分で作ってみたいが、プログラミングの経験が少ない方
- WordPress以外の選択肢があるのか気になっている方
- Claude Codeで実際にどこまでできるのか、現実的なところを知りたい方
専門用語にはそのつど短い説明を添えます。コードを書けなくても読み進められる内容にしています。
完成したサイトの概要
まず、何ができあがったのかを先にお伝えします。
| サイト名 | AIためすラボ |
|---|---|
| 運営・執筆の表示 | AIためすラボ編集部(個人で運営しています) |
| 使った仕組み | Astro(アストロ)というサイト作成ツール |
| 公開の形 | 静的HTML(あらかじめ作っておいたファイルをそのまま置く方式) |
| 公開先 | XServer(レンタルサーバー) |
| 以前のWordPress | 削除して置き換え済み |
「静的HTML」という言葉が出てきました。これは、表示するページをあらかじめ全部作っておき、サーバーにはそのファイルを置くだけ、という方式です。WordPressのように、アクセスのたびにサーバーがページを組み立てる方式とは違います。仕組みがシンプルなぶん、表示が速く、WordPressのような動的な仕組みと比べて、管理対象や攻撃対象になり得る機能が少ないという利点があります。
制作前の状態
制作を始める前の状況は、次のとおりでした。
- レンタルサーバー(XServer)とドメインは、以前から契約・取得していたものがありました
- そのドメインでは、WordPressをいつか使うつもりで用意してありました
- ただ、結局そのWordPressサイトは一度も本格的に運用しませんでした
- そのため、引き継ぐべき記事・画像・データは何もありませんでした
引き継ぐ中身が無かったので、新たなサーバー契約を増やさず、すでに契約していたXServerと取得済みのドメインを使い、中身をゼロから作り直すことにしました。
WordPressには一度も中身を入れていなかったため、引き継ぐものがありませんでした。 そこで、この後の「収益化を目指した記事サイト」という目的に合わせて、構成から作り直すことにしました。 WordPressを使う選択肢もありましたが、今回は管理が軽い静的サイトを試したかった、 というのも理由のひとつです。
テーマと技術構成を決めるまで
サイトのテーマを決める
最初に決めたのは「何について書くサイトにするか」です。検索から人が訪れて、将来的に広告やアフィリエイトで運営費をまかなえるテーマを探しました。
いくつかの候補を比べたうえで、「生成AI・Claude Code・業務効率化」というテーマを選びました。決め手は、自分が実際に日常的にClaude Codeを使っていて、試した結果を一次情報として書けるという点でした。やったことのない分野を一般論で書くのではなく、自分で確かめたことを書けるテーマにしたかったのです。
テーマ選びの段階では「収益が見込めそうか」も検討しました。 ただし、これは「稼げる」と決まったという意味ではありません。 現時点で広告もアフィリエイトも未導入で、収益はまだ一切ありません。 検索順位やアクセスについても、保証できるものではありません。
技術構成を決める
次に、どの仕組みでサイトを作るかを決めました。最終的に選んだのは Astro です。理由は次のとおりです。
- 静的HTMLとして書き出せるので、表示が速く、サーバー側で特別なプログラムを動かす必要がない
- 記事を、Markdown(マークダウン。簡単な記号で見出しや太字を表す書き方)を拡張したMDXという形式で管理でき、文章に集中しやすい
- 重い仕組みを足さずに済むので、後々の管理が楽になりそうだった
公開先は、すでに契約していた XServer をそのまま使うことにしました。XServerは静的なファイルを置くだけで表示できるので、Astroで作ったファイルとの相性が良いと判断しました。
契約しているサーバーのPHP(ピーエイチピー。WordPressなどが使うプログラム言語)は バージョンが古いものでした。今回の静的サイトはPHPを使わないため影響はありませんが、 「PHPに頼る機能は作らない」という方針だけは最初に決めておきました。
Claude Codeへ最初に依頼した内容
ここからが本題です。Claude Codeは、日本語の指示でパソコン上の作業を任せられるツールです。ターミナル(黒い画面)の上で動きますが、操作は日本語で文章を打つだけです。Claude Code自体の導入方法は、別記事のClaude CodeをWindowsで使い始めるための準備と基本手順にまとめています。
最初にお願いしたのは、いきなり記事を書かせることではなく、サイトの土台を作ることでした。具体的には、次のようなことを順番に依頼しました。
- 収益化を目指す日本語サイトとして、どんなテーマがよいかを一緒に検討する
- 選んだテーマで、Astroを使ったサイトの骨組みを作る
- トップページ・記事一覧・カテゴリー・固定ページなど、必要なページをそろえる
いきなり完璧なものができたわけではありません。やりとりを重ねながら、少しずつ形にしていきました。
サイト基盤の制作
Claude Codeに作ってもらったのは、おおよそ次のような構成です。
- 記事ページ:MDX(Markdownを拡張した記事ファイル形式)として記事を管理し、ビルド時にHTMLへ変換する仕組み
- カテゴリー:「はじめての生成AI」「Claude Code実践」「仕事の自動化」「AIツール検証」「つまずき解決」「運営記録」の6つ
- 固定ページ:このサイトについて/運営者情報/プライバシーポリシー/広告・アフィリエイトポリシー/免責事項/お問い合わせ
- SEOの基盤:各ページのタイトル説明文、canonical(正規URLの指定)、OGP(SNSで共有したときの表示情報)、サイトマップ、RSS、検索エンジン向けの構造化データ
固定ページの中には、プライバシーポリシーや免責事項のように、収益化を考えるなら最初から用意しておくべきものも含めました。
お問い合わせページは作りましたが、送信機能はまだ動かしていません。 今回はPHPを使う自作フォームを設置せず、外部フォームサービスもまだ導入していないため、 「準備中」と表示しておく形にしました。将来、外部サービスなどへつなげられる構成だけを用意しています。
品質を保つために、作るだけでなく機械的にチェックする仕組みも用意しました。ビルド(公開用ファイルを書き出す作業)のあとに、タイトルの重複や説明文の抜け、リンク切れ、画像の代替テキストの抜けなどを自動で点検するスクリプトです。人の目だけでは見落とす部分を、毎回機械でも確認するようにしました。
スマートフォン表示の確認と改善
サイトを見る人の多くはスマートフォンを使います。そこで、画面の幅を変えながら表示を確認し、いくつか手直しをしました。実際に直したのは、たとえば次のような点です。
- 記事タイトルがスマートフォンで大きすぎて、画面の多くを占めてしまっていた → 画面幅に応じて自然に大きさが変わるように調整
- 本文の行間がやや広く、1行に入る文字数が少なかった → 読みやすいバランスに調整
あるとき、本文に「太字にしたい記号(アスタリスク2個)」がそのまま画面に出てしまう 不具合がありました。原因は、太字の閉じ記号のすぐ後ろに全角カッコ付きの文章を続けると、 正しく太字に変換されないという書き方のクセでした。書き方を直して解決し、 同じことが起きないよう、機械チェックにも記号の残りを検出する項目を足しました。
「AIに任せれば全部きれいに仕上がる」わけではなく、こうした細かい表示の調整は、実際に画面を見ながら一つずつ直していく作業になりました。
主力記事の実機検証
サイトの土台ができたあと、最初の本格的な記事として「Claude CodeをWindowsで使い始めるための準備と基本手順」を作りました。この記事では、自分のパソコンで実際に確認したことと、公式サイトに書いてあることを、はっきり区別して書くようにしました。
- 自分の環境(Windowsのバージョン、各ツールのバージョンなど)は、読み取り専用のコマンドで実際に確認して記録
- インストールの最新手順や料金など、変わりやすい部分は公式ドキュメントで確認し、確認した日付を添える
- まだ自分で再現できていない部分(初回のインストール画面など)は「未再現」とはっきり書く
操作画面のスクリーンショットも、実際に撮影して掲載しました。撮影のときは、ユーザー名やアカウント情報など、個人を特定できる情報が写らないように隠す作業も行いました。
「実際に試して、確かめてから書く」と決めると、1本の記事に手間がかかります。 ですが、これがこのサイトの売りなので、急いで本数を増やすより、 確かめた記事を一つずつ出す方針にしました。
WordPress削除とXServer公開
記事が用意できたところで、いよいよ公開です。作業はすべて、XServerのブラウザ版ファイルマネージャー(管理画面)で行いました。FTPソフトやSSHといった専門的なツールは使っていません。
まず、以前のWordPressを削除しました。流れは次のとおりです。
- XServerの「WordPress簡単インストール」画面から、WordPressをアンインストールした
- そのWordPressが使っていたMySQL(データベース)と、そのデータベース用のユーザーも、削除の対象に含めた
- 削除後、公開フォルダ(public_html)にはXServerの初期ファイルだけが残った
- public_html内をいったん空にした
前述のとおり、このWordPressには中身を入れていなかったので、引き継ぐ記事やデータはありませんでした。とはいえ、サーバー上の削除は元に戻せない操作です。手順を事前に書き出し、一つずつ確認しながら進めました。
WordPressの削除や、サーバー上のファイル削除は、元に戻せない操作です。 保存すべきものが無いと分かっていても、操作の順番を手順書にまとめ、 迷ったら手を止める、というのを基本にしました。
公開フォルダを空にしたあと、新しい静的サイトを設置しました。
- ローカル(自分のパソコン)で、公開用のファイル一式をZIP(圧縮ファイル)にまとめておいた
- そのZIPを、ファイルマネージャーでpublic_htmlへアップロードした
- ファイルマネージャー上でZIPを展開し、Astroで作った静的HTMLを配置した
このとき気をつけたのが、ZIPの中身の構造です。ZIPによっては、展開するとフォルダが一階層深くなり、トップページが公開フォルダの直下ではなく「その中のさらにフォルダの中」に入ってしまうことがあります。そうなるとサイトが正しく開きません。そこで、展開するとindex.html(トップページのファイル)などがpublic_htmlの直下に並ぶ構造になっていることを、事前に確認しておきました。
やってみて分かった、静的サイトの公開の手間
実際にやってみて、WordPressとの違いをはっきり感じたのが「修正のたびの手間」でした。
公開後にスマートフォン表示や文字サイズなどを直したのですが、そのたびに次の作業が必要になりました。
- ローカルでMDX(記事のファイル)やデザインを編集する
- 機械チェックとビルド(公開用ファイルの書き出し)をやり直す
- 公開用ZIPを作り直す
- XServerのファイルマネージャーで、同じ名前のZIPを上書きアップロードする
- もう一度展開して、ファイルを置き換える
この一連の流れを、修正のたびに何度か繰り返しました。
WordPressは、ブラウザの管理画面から直接記事を書いたり直したりできます。 一方、今回の静的サイトは、手元で編集してから作り直し、アップロードし直す方式です。 表示が速く管理が軽いという利点の裏返しで、「直してすぐ反映」という手軽さはありません。 どちらが良いかは、何を重視するかによります。
なお、展開に使ったZIP本体は、public_htmlにそのまま残っている場面もありました。動作には影響しませんが、不要なファイルを置いたままにしないという意味では、片づけておくとより安心です。
Google Search Console設定
サイトを公開したあと、Google Search Console(グーグル・サーチ・コンソール。検索での見え方を確認できる無料ツール。以下サーチコンソール)にサイトを登録し、検索エンジンにサイトの場所を知らせる「サイトマップ」を送信しました。
その前提として、検索エンジン向けの設定ファイル(robots.txt。クロールを許可するか拒否するかを書くファイル)を、制作中と公開後で切り替えています。
- 制作中:サイト全体を検索対象から外すため、すべて拒否する内容にしていました
- 公開時:許可する内容へ変更し、サイトマップの場所(
https://reiwa-baby.com/sitemap.xml)を書き加えました
ところが、ここで少しつまずきました。
サイトマップ送信が最初は失敗した
公開後、サーチコンソールに新しいサイトマップを送信したところ、最初は「取得できませんでした」と表示されました。
原因を探るため、サイトマップのURLを「URL検査」のライブテスト(その場で実際に取得してみる機能)にかけたところ、「robots.txtによりブロックされました」と表示されました。
ここで一瞬あせりました。ですが、XServer上で公開中のrobots.txtを自分で開いて確認すると、中身はすでに「許可する」内容に変わっていました。サーバー側は正しいのに、Googleはブロックと判定している——この食い違いから、Google側に、以前の「全部拒否」だったrobots.txtの情報がまだ残っているのではないかと考えました。
サーバー側のrobots.txtは正しい内容になっていたので、あわてて設定を変えると、 かえって状況が分からなくなると考えました。そこで、設定はそのままにして、 Googleが新しいファイルを取得し直すのを待つことにしました。
最新のrobots.txtが取得されてから成功した
しばらく待ち、2026年6月14日の朝に、サーチコンソールの「robots.txtレポート」(Googleが取得したrobots.txtの状態を見られる画面)を確認しました。すると、Googleが最新のファイルを取得した状態になっていました。
- ステータス:取得済み
- 問題の件数:なし
- 取得された内容:許可する内容と、サイトマップの場所が書かれたもの
この状態を確認してから、もう一度サイトマップを送信すると、今度は「成功しました」となり、3ページが検出されました。
時系列で見ると、最初の失敗から成功までの間に変わったのは「Googleが新しいrobots.txtを取得したこと」だけでした。このことから、最初の失敗は、Google側で古いrobots.txtの情報が更新されるのを待っていた状態だった可能性が高いと考えています。
「robots.txtのキャッシュ(古い情報の保持)が原因だ」と完全に言い切ることはできません。 あくまで、サーバー側は正しかったこと、最新ファイルの取得後に成功したこと、 という時系列から推測した内容です。同じ表示が出ても原因が違う場合はあります。
サイトマップ送信のあとに行ったこと
サイトマップが成功したあと、次の作業を行いました。
- 以前のWordPress用のサイトマップが残っていたので、サーチコンソールから削除した
- 検索に載せたい3ページ(トップページ/記事一覧/主力記事)について、URL検査を行い、インデックス登録をリクエストした
3ページの状況は次のとおりでした。
- トップページ:以前からGoogleに登録されていたため、更新した内容を読み直してもらうよう依頼した
- 記事一覧と主力記事:「検出 - インデックス未登録」という状態でしたが、URL検査では「URLはGoogleに登録できます」と判定され、登録リクエストが受け付けられた
なお、作業の途中で、サイトマップのURL検査を実行したときに、一度だけ理由の書かれていない「エラーが発生しました」という表示が出ました。ただ、その後にrobots.txtレポートとサイトマップの再送信で正常な状態を確認できたため、一時的なものと判断しました。
ここまででできたのは「Googleに3ページの登録をリクエストした」ところまでです。 リクエストが受け付けられたことと、実際に検索結果に表示されることは別です。 検索結果への掲載や検索順位については、この時点ではまだ何も確認できていません。
ちなみに、検索に載せるページを3つに絞っているのは、まだ実体験や検証が足りない記事を急いで検索に載せたくなかったからです。中身が整ったページから順に公開していく方針にしています。
実際に起きたトラブル
ここまでさらっと書いてきましたが、制作中にはいくつものつまずきがありました。非エンジニアの目線で印象に残ったものを、正直に挙げます。
ビルドが何も言わずに止まる
公開用ファイルを書き出す作業(ビルド)が、エラーも出さずに途中で進まなくなることが何度かありました。作業フォルダがクラウド同期(OneDrive)の同期対象にあり、一時ファイルやキャッシュが影響している可能性を考えました。一時的なキャッシュフォルダを削除して再実行したところ、処理を進められました。原因を完全に特定できたわけではありませんが、この対処で先に進めました。
設定を変えたのに反映されない
サイトの運営者名を設定ファイルで変えたのに、記事の表示に反映されない、ということがありました。これは、いったん作った内容が裏側で保存(キャッシュ)されていたためでした。キャッシュを消してから作り直すことで反映されました。
文字化けでスクリプトが動かない
環境確認用に小さなスクリプトを作ったとき、日本語を含むファイルが文字化けして、処理が進まないことがありました。ファイルの文字コードが、使用していたWindows標準のWindows PowerShell 5.1で正しく扱われなかったことが原因でした。保存形式を変更すると解決しました。
どのトラブルも、AIが一発で完璧に解決してくれたわけではありません。 「何かおかしい」と気づいて、原因を一緒に調べ、直す、という人間側の確認が 毎回必要でした。逆に言えば、エラーの意味を調べたり対処を試したりする部分は、 Claude Codeに相談しながら進められたので、一人で抱えるよりは楽でした。
Claude Codeを使って良かった点
正直な実感として、良かったと感じた点は次のとおりです。
- 日本語の指示でサイトの骨組みができた:コードを一から書けなくても、やりたいことを言葉で伝えれば形になりました
- 修正と確認を繰り返しやすい:「ここをこう直して」と頼み、そのつどビルドや点検をしてもらえました
- 品質を保つ仕組みを一緒に作れた:リンク切れや表示の不具合を自動で見つける仕組みを用意でき、見落としを減らせました
特に、文章(記事)に集中したい自分にとって、サイトの仕組みの部分をある程度任せられたのは助かりました。
難しかった点と注意点
一方で、難しかった点や、これから試す人に伝えたい注意点もあります。
- AIは間違えることがある:出てきた結果をそのまま信じず、自分で確認する場面が必ずあります
- 判断は人間が決める:テーマ選び、どこまで公開するか、何を載せないか、といった判断は自分で決める必要がありました
- 「試してから書く」には時間がかかる:実体験を中心にすると、1本あたりの手間は増えます。本数を急ぐのには向きません
- 専門用語は避けて通れない場面もある:完全にゼロ知識のままでは進みにくく、最低限は調べながら進めることになりました
「AIに任せれば、知識ゼロのまま、勝手に稼げるサイトが完成する」というものではありません。 実際は、確認と判断と手直しの積み重ねでした。そのうえで、コードを書けない人でも サイトを形にできたのは事実です。期待のかけどころを間違えなければ、心強い道具だと感じています。
現在の到達点
今の時点での状況を、ありのままにまとめます。
- サイトは公開済みです
- 検索に載せるページは、内容を確認できた3ページに絞っています
- その3ページについては、サーチコンソールでインデックス登録をリクエストしました
- ただし、リクエストが受け付けられただけで、検索結果に実際に表示されたかはまだ確認できていません
- 残りの記事や固定ページは、検索エンジンに登録しない設定にしています
- 広告・アフィリエイトは未導入で、収益はまだ一切ありません
- アクセス数や検索順位についても、現時点で語れる成果はありません
つまり、「土台ができて、最初の記事を公開し、3ページの登録をGoogleに依頼したところ」という段階です。ここから先は、これからの積み重ね次第です。
今後の予定
これから取り組む予定は、次のとおりです。
- 実際に試して確認した記事を、一つずつ増やしていく
- 内容が整ったページから、順に検索へ公開していく
- 記事や情報がそろってきた段階で、広告やアフィリエイトの導入を検討する(導入する場合はPR表記などのルールを守る)
収益化については、急がず、まず「読んで役に立つ記事」をためることを優先します。
まとめ
- プログラミングを本業としない会社員でも、Claude Codeを使ってAstro製の静的サイトを作り、XServerへ公開するところまで進められました
- ただし、AIが全部を自動で完璧に仕上げたわけではなく、確認・判断・手直しは人間側で何度も必要でした
- ビルドが止まる、設定が反映されない、文字化けする、といったトラブルもありましたが、原因を調べて一つずつ解決しました
- 現時点では収益もアクセスの成果もまだありません。これからの積み重ね次第です
これからホームページを自分で作ってみたい方は、まず道具に過度な期待をしすぎないこと、そして「自分で確かめたことを書く」姿勢を持つことが、遠回りに見えて近道だと感じています。
Claude Codeそのものをこれから使い始める方は、Claude CodeをWindowsで使い始めるための準備と基本手順もあわせてご覧ください。