AIと一緒にWebサイトを作って感じたこと｜できなかったことが形になっていく面白さ

この「天翔公式サイト」も、AIを活用しながら作っています。

私は、Webサイトを自由自在に作れるプログラマーではありません。

コードを見ただけで、すべての意味が分かるわけでもありません。

それでも今、自分が考えたイメージを少しずつWebサイトとして形にすることができています。

これは、AIを使うようになって特に大きく変わったことの一つです。

今回は、実際にこの公式サイトを作りながら感じたことを書いてみます。

「作りたい」と「作れる」の間が近くなった

以前なら、

「こういうWebサイトが欲しい」

と思っても、その次に大きな壁がありました。

HTMLやCSS、プログラム、サーバー、公開方法など、知らなければならないことがたくさんあります。

興味はあっても、

「自分には難しそうだ」

と思って終わってしまうこともあります。

AIを使い始めて感じたのは、この「作りたい」と「実際に作る」の距離がかなり近くなったことです。

たとえば、

「もっと明るい雰囲気にしたい」

「この人物をもう少し目立たせたい」

「スマートフォンではこの並び方だと見にくい」

「ここは別のページではなく、同じサイトに見えるようにしたい」

といった希望を言葉で伝えることができます。

そこからAIがコードや構成に変えてくれる。

私は完成したものを見て、

「これは違う」

「これはいい」

「ここを直したい」

と判断する。

この繰り返しで、少しずつサイトが形になっていきます。

AIに任せれば何でも一発で完成するわけではない

実際に作ってみて分かったのは、AIを使えば最初から完璧になるわけではないということです。

今回のサイト制作でも、

「これは思っていたものと違う」

ということは何度もありました。

たとえば、トップページでは気に入っていたデザインでも、別のページを作ったときに同じサイトとは思えないようなレイアウトになることがありました。

文章の幅が狭くなりすぎて、見出しが不自然に何行にも折り返されたこともあります。

AI側では「完成した」と判断されていても、実際に自分の目で見ると違和感がある。

そこで、

「トップページのデザインを基準にする」

「別ページだからといって新しいデザインにしない」

「まず実際の表示を見てから決める」

といったルールを少しずつ作るようになりました。

これは、人と一緒にものを作る場合にも似ている気がします。

考えていることを伝え、出来上がったものを確認し、必要なら修正する。

AIだからすべて任せるのではなく、確認することがとても大切だと感じています。

自分がコードを書かなくても、決めることはたくさんある

Webサイト制作というと、どうしても「コードを書く作業」を想像します。

でも、実際に作ってみると、それ以外に決めることがたくさんあります。

たとえば、

このサイトは何のためにあるのか
誰に見てほしいのか
最初に何を見せるのか
どんな雰囲気にしたいのか
どの活動をどこに配置するのか
文章は分かりやすいか
スマートフォンでも見やすいか
不要な情報が増えていないか

こうした部分は、AIだけで勝手に決めてもらうものではありません。

むしろ、ここを自分で考えることがWebサイト作りの中心なのかもしれないと思うようになりました。

コードを書くことができなくても、

「何を作りたいのか」

を考えることはできます。

そして、その考えをAIに伝えて実際の形にしていく。

この役割分担は、自分にとってかなり面白い制作方法です。

「できた」で終わらず、実際に確認する

今回のサイトでは、ページを作った後に実際の表示を確認しています。

パソコンで見たとき。

タブレットで見たとき。

スマートフォンで見たとき。

同じページでも、画面の大きさによって見え方はかなり変わります。

パソコンでは問題なくても、スマートフォンでは文字が詰まっていたり、画像と文章が重なったりすることがあります。

そのため、

作る
↓
確認する
↓
直す
↓
もう一度確認する

という作業を繰り返しています。

さらに、公開した後も実際のWebサイトを確認します。

パソコンの中では正常でも、インターネット上へ公開した直後には、反映まで少し時間がかかることもありました。

「AIが成功と言ったから終わり」ではなく、最後は実物を見る。

この考え方は、今後ほかの制作にも活かしていきたいと思っています。

追記：公開確認の404を、そのままサイト障害と決めなかった

ここからは2026年10月29日の作業記録に基づく補記です。当初の記事を書いた時点とは分けて、公開確認の仕組みを見直した例を残します。

このサイトの受入検査では、GitHub上の公開対象、CloudflareのBuild結果、公開ページの本文を別々に確認します。ところが、非公開のGitHubリポジトリへ認証なしでAPIを呼び出していたため、GitHub確認が404で止まる状態がありました。

ここでの404は、公開サイトの記事URLを開いた結果ではありません。GitHub APIという別の確認先から返った結果です。GitHubの公式説明でも、非公開リソースへ適切に認証せずにアクセスすると、その存在を明かさないため404を返すと案内されています（2026年10月29日確認）。ただし、どんな404も認証不足だという意味ではなく、URLや要求方法など別の原因もあります。

このとき必要だったのは、公開中の記事を書き直すことより、どの確認先で、何の証拠が取れていないのかを分けることでした。

確認先	分かること	それだけでは分からないこと
GitHubのmain	公開対象の変更を識別する値（コミットSHA）が一致するか	その変更が本番で配信されているか
対象変更のBuild結果	そのSHAに対するビルドが成功したか	公開URLの本文が読めるか、配信の割当割合
公開URLのHTTPと本文	ページが取得でき、期待した見出しや本文が含まれるか	画面での文字切れ、広告審査の結果

検査処理は、既存の認証済みGitHub CLIを利用する形へ変更しました。認証やアクセス権を確認できなければ「証拠を取得できない」と記録して、公開受入は保留にします。対象SHAが違う、またはBuildが失敗している場合は、単なる取得不能とは別に不一致・失敗として扱います。認証情報そのものを記録へ貼る必要はありません。

その後の読み取り確認では、GitHubのmain SHAと同じSHAのWorkers Build成功を取得でき、検査関数でも両方を確認できました。さらに実際の新記事公開では、公開ページのHTTP 200、見出し・本文・正規URL、サイトマップ掲載まで一括で確認できています。これは本サイトの当該作業での確認であり、あらゆる環境や将来の公開を保証するものではありません。Cloudflareの管理画面上の配信割合や、実画面の見やすさは、このHTTP検査だけでは確認できません。

同じようにAIへ公開確認を任せるなら、最初に次の3点を聞くと、次の行動を決めやすくなります。

失敗したのはGitHub・配信サービス・公開URLのどこか。
観測したHTTP状態や本文は何か。取得できていない項目はどれか。
確認不能と、実際に見つかった不一致を区別できているか。

この例は、サイトを作る際の「完成」の意味を具体的にするためのものです。確認を通すためにリポジトリを公開設定へ変えたり、アクセス制限を外したりする方法を勧めるものではありません。

失敗しにくくするために、少しずつ進めるようになった

Webサイトを作っていると、一度に全部を変えたくなることがあります。

トップページも直す。

ABOUTページも作る。

記事も増やす。

新しい機能も入れる。

でも、一度にたくさん変更すると、問題が起きたときに何が原因だったのか分かりにくくなります。

そこで現在は、

一つ作る。
確認する。
問題がなければ公開する。
バックアップする。
それから次へ進む。

という方法で進めています。

少し遠回りに見えるかもしれません。

でも、この方が何かあったときにも戻りやすく、安心して続けられます。

今回の「活動記録」も同じです。

まず第1記事を作って確認し、正式に公開してから、第2記事を書いています。

最初から大量の記事を作るのではなく、一つずつ積み上げています。

AIを使うことで「分からないからやめる」が減った

私がAIを使っていて一番大きいと感じるのは、作業が速くなることだけではありません。

以前なら、

「分からない」

↓

「調べても難しい」

↓

「自分には無理そうだ」

となっていたことでも、

「これはどうすればできる？」

とAIに聞きながら先へ進めるようになりました。

もちろん、AIの答えが必ず正しいわけではありません。

実際に試して、違っていれば直す必要があります。

それでも「分からないところから一歩進むための相手」がいることは大きいです。

分からないことがなくなるのではなく、

分からないことがあっても進めるようになる。

そこにAIを使う面白さがあるように感じています。

この公式サイトもまだ完成ではない

天翔公式サイトも、まだ作っている途中です。

活動を紹介するページを整えたり、こうして活動記録の記事を増やしたり、今後やりたいことはまだあります。

おそらく、途中でまた失敗することもあると思います。

デザインを変えることもあるでしょう。

思っていた方法をやめて、別の方法を試すこともあるかもしれません。

でも、それも含めてこのサイトを育てていきたいと思っています。

完成した結果だけではなく、

「どうやって作っていったのか」

という過程も、この活動記録に残していきます。

できなかったことを、少しずつ形にしていく

AIを使えば、誰でも何でも簡単にできる。

そこまで単純ではありません。

考えることも必要です。

確認することも必要です。

間違えることもあります。

やり直すこともあります。

それでも、以前なら「自分にはできない」と思っていたことを、自分の考えを反映しながら形にできるようになった。

これは私にとって、とても大きな変化です。

このWebサイトも、その一つです。

これからもAIを道具として使いながら、自分では難しかったことに一つずつ挑戦していきたいと思っています。

そして、その過程もこの「活動記録」に残していきます。

制作の考え方をもう少し掘り下げたい方は、作業手順を次回へ残す方法をまとめたAIとの制作手順を仕組みに残す理由や、技術検査と人の判断を分けるAIと人間で「確認」を分担するようになった理由もご覧ください。この記事はサイト制作を始めたときの体験、前者は繰り返す作業の記録、後者は公開前の確認役割を扱っています。