コーポレートサイトをAIで作り直した3日間。私が決めたこと、AIに任せたこと

はじめに：文章を直すつもりが、作り直しになった

このサイトは、ノーコードツールで作った旧サイトから、AIと一緒にコードで作り直しました。かかったのは3日ほどです。ただ、これは決めるのも公開するのも私だったからです。開発チームや本社の確認が要る会社での進め方は、後半に書きました。

直近でサイトをリニューアルしたのが今年6月。その時はデザイナーさんに依頼し、約2週間かけて構築していました。

最初は、文章を直すだけのつもりでした。「誰に向けて、何を言うサイトなのか」を整理し直し、モックを作り、ノーコードツールに貼り付ける部品まで用意しました。そこでふと、「このままノーコードで作り直すと、どれくらいの工数なのか」をAIに聞いたのが分かれ道でした。

マーケティングの担当者が少ない会社ほど、サイトの作り直しは「いつかやること」のまま残りがちです。制作会社に頼むほどの予算も時間もなく、社内に技術的な判断ができる人もいない。

この記事は、そういうチームが「AIに頼むと、どこまでできて、どこからは自分で決めるべきか」を判断するための参考記録です。ITツールの名前も出てきますが、大事なのは選び方と進め方のほうです。失敗したところも、そのまま書きます。

構成は「更新するのは誰か」で決めた

道具を選ぶ前に、更新の仕事を2つに分けました。お知らせやブログのように社内の人がしょっちゅう更新するものと、トップページの文章やデザインのように、ときどきしか変えないものです。前者は管理画面で、後者はAIに頼んでコードで直す、と決めると、選ぶべきものが自然に絞れました。

Astroで静的な企業サイトやLPを複数運用するなら、無料で商用利用できるCloudflare。一方、Next.jsによる本格的なWebアプリ開発まで見据え、開発環境の標準化やフレームワークとの親和性を優先するならVercelという選択肢もありました。両者ともGitHub連携による自動デプロイと確認用URLの発行に対応しています。

なお、Vercel の無料プランは個人・非商用に限られるので、会社のサイトなら有料プランが前提です。

迷ったときは「誰が、どの画面で、何を更新するか」に戻ると、機能の多さで選ばずに済みます。システムを自分で選ぶ立場にない場合で制作会社や開発チームに相談するときは、次の4つを聞いてみると良いと思います。

• お知らせやブログを、コードを触らずに社内で更新できるか
• 公開する前に、確認用のURLで見られるか
• 変更の履歴が残り、前の版にすぐ戻せるか
• お問い合わせが、そのまま顧客管理（CRM）に入るか

AIが生成したサイトの修正依頼はまずスプレッドシートに書く

まずAIに、サイトの全ページの要素（ヒーロー、見出し、ボタン、写真、実例カード…）を一行ずつ並べたシートを作ってもらいました。私は、気になった行に依頼を書くだけです。

1. 私がシートの「依頼内容」の列に書く（例：「マーカーが見出しにかぶって読みにくい」「この文は不要」）
2. AIがすべての行を反映し、PCとスマホの画面で確かめて、その行を「確認待ち」にする
3. 私が確認用のURLで見て、次の列に追加の依頼を書く

この往復を四度回しました。

シートにしてよかったのは、依頼が「どこの、何を」という単位で残ることです。チャットだと、前の依頼と矛盾していても気づきにくい。シートなら、同じ行に一度目と二度目の依頼が並ぶので、後から見ても経緯が分かります。

社内で複数人がコメントする場合も、AIではなく制作会社や開発チームに依頼する場合も、同じシートがそのまま使えます。

AIに任せたこと、私が決めたこと

手を動かす作業は、ほぼすべてAIがやりました。私が担ったのは、「これでいいか」を決めることと、事実を渡すことです。

実例の数字については、AIは資料にない数字を作らず、「この案件は裏付けがない」と指摘してきました。逆にいうと、事実をまとめた資料が手元になければ、実例のページは数字のないぼんやりしたものになります。サイトを作り直す前に、過去の案件の成果を整理しておくと、AIの力がそのまま生きます。

移行で気をつけたこと

サイトの作り直しで怖いのは、デザインよりも「切り替えた日に何かが壊れること」です。今回は次の7つを先に決めてから進めました。

• URLを変えない。 旧サイトと同じURLを引き継いだ。名前を変えたお知らせ1件だけ、古いURLから新しいURLへ転送している
• メールを止めない。 ドメインの設定で変えるのは、サイト向けの2行だけ。メールや各種認証の設定（MX・TXT）には触らない
• 旧サイトはすぐに解約しない。 新サイトが数日問題なく動くのを見てから。何かあれば、ドメインの設定を戻すだけで元に戻れる
• 公開前のサイトは検索に載せない。 確認用のURLは、会社のアカウントでログインした人しか見られない設定にした
• 検索の基本設定を揃える。 ページごとのタイトルと説明文、サイトマップ、検索エンジン向けの会社情報
• 基本的なセキュリティ。 APIキーをコードに書かない、他サイトに埋め込ませない、管理画面の本文に紛れ込んだスクリプトを取り除く
• お問い合わせを切らさない。 フォームは旧サイトと同じ HubSpot のものを使い、切り替え後にテスト送信する

SEOとセキュリティの点検も、「基本的な設定が問題ないか確認して」と頼むだけで、AIが全ページを調べて足りないものを追加してくれました。ただ、その結果をどこまで信じるかは人が決めることです。切り替え後に Search Console や外部のチェックツールで確認するのも良いかと思います。

公開したあと、困らないために

AIで作ったサイトの弱点は、「作ったときの会話」にしか経緯が残らないことです。半年後に「なぜこうなっているのか」が分からないと、直すたびに一から説明することになります。そこで、公開前に2つの文書を作りました。

• 作業のルールを書いたファイル： コードと一緒に保管しています。次に作業するAIも外部の制作者も、最初にこれを読みます。中身は、ロゴを作り直さない、資料にない数字を作らない、メールの設定に触らない、といった今回決めたことです
• 運用マニュアル： 「お知らせは管理画面、文章やデザインはAIに依頼」といった更新の分け方、外部に委託するときの権限の渡し方、壊れたときの戻し方をまとめました

今後の更新も、変更をまず確認用のURLに出し、OKを出してから公開する流れにしています。

社内の合意が要る会社なら

今回3日で済んだのは、決めるのも公開するのも私だったからです。開発チームや情報システム部門の承認が要る会社、本社の確認が必要な日本法人では、同じ速さでは進みません。それでも、AIの力を借りられる場面はあります。

• モックと依頼シートまでをAIで作る。 完成形に近いものを見せながら話せるので、開発チームとの打ち合わせを「何を作るか」から「どう作るか」に進めやすくなります
• 移行のチェックリストを先に共有する。 上の7つは、作るのが誰であっても確かめるべき点です。メールとお問い合わせを止めないことを最初に約束しておくと、関係者も安心して進められます
• 更新の分け方を先に決める。 誰が、どの画面で、何を更新するか。これが決まっていれば、システム選びを開発チームに任せても、公開後の運用で困らないと思います

おわりに

3日でサイトを作り直せたのは、AIが速かったからだけではありません。誰に何を伝えるサイトなのか、実例に載せられる事実は何か。それを先に言葉にしていたから、AIの出した案にその場で「これは違う」と言えました。

作り直しを検討しているなら、最初にやるのは道具選びではなく、次の3つを書き出すことです。

1. 誰に読んでほしいか。その人が今どんな状況にいるか
2. 実例として載せられる事実と数字
3. 公開後に、誰が何を更新するか

この3つがあれば、あとはAIと一緒に進められます。

ダイヤモンドツリーでは、この3つの整理から、移行の段取り、公開後の運用まで、チームの一員として一緒に進めています。サイトに限らず、HubSpotやSEOで「何から動かすか」が決まらずに止まっているときも、お気軽にご相談ください。