AIと対話しながら、コーポレートサイトを作り直してローンチ前まで持っていった話
コーポレートサイトを作り直そうと思った時、最初に困ったのはデザインでも実装でもありませんでした。
JUICE UPの今の事業をどう見せるかを整理し、その内容をすぐ修正できる形で公開できるようにすること。さらに、GitHubを更新すればサイト更新が自動反映され、考えた修正や追加項目をそのまま次の改善に繋げられる状態を作ること。その2つを同時に満たしたかった、というのが実際の出発点でした。
だから今回の話は、「AIでコードを書いた話」ではありません。
Claude Code と Codex に相談しながら、会社の見せ方、サイトの構成、運用の土台を整理し、ローンチ前まで持っていった話です。
最初に決めたのは、サイトの見た目ではなく運用要件だった
サイトを作り直す話になると、つい色やレイアウトから考えたくなります。
でも今回はそこではありませんでした。最初に整理したのは、デザインよりも運用面でした。
欲しかったのは次のような状態です。
- AIと対話しながら GitHub を更新し、その内容がサイト更新に自動で反映される
- コピーや導線を思いついた時にすぐ修正できる
- ページ追加や記事追加がコード管理の流れに乗る
- ローンチ後も小さく直し続けられる
この前提に立つと、もともとの STUDIO 運用では少しずつ満たしにくい状態になっていました。見た目を作ることはできても、企画、コピー、情報設計、記事追加、導線改善を細かく回していくには、もう少し開発寄りの土台が必要でした。
だから今回の本質は「新しいサイトを作る」より、「今後の改善が回る運用へ移行する」ことでした。
その前提で、技術選定も AI と相談しながら進めた
最終的には、Astro、Tailwind CSS、Vercel、GitHub という構成に落ち着きました。
ただ、最初からその答えがあったわけではありません。どの技術が今の目的に合うか、何を優先して選ぶべきかも含めて、Claude Code と Codex に相談しながら詰めていきました。
ここで見ていたのは、流行っているかどうかではなく、今回の要件に素直に合うかです。
- コーポレートサイトとして必要十分な速度で実装できるか
- コンテンツ更新が重くならないか
- 記事やお知らせを増やしていけるか
- GitHub 起点で preview と production を分けられるか
- 後から構成を整理し直しやすいか
技術選定を「どれが強いか」ではなく、「どういう運用にしたいか」から逆算すると、迷いが減りました。ここを先に決めておくと、後で細かい技術比較に引っ張られにくくなります。
AIにやってもらったのは、実装だけではなく論点整理だった
今回、AIの使い方として大きかったのは、コード生成より先に論点整理の相手にしたことでした。
例えば、こんな問いを投げました。
- AI活用支援と開発支援をどう見せ分けるか
- トップで何を言い切るべきか
- 会社概要はどこまで削るか
- 記事を優先するか、資料請求を優先するか
- デザインのトーンをどう固定するか
人間だけで考えると、「なんとなくこれでいいか」で止まりやすいところを、AI相手だと一度言葉にする必要があります。その過程で、「本当は何に迷っているか」が見えやすくなりました。
コードを書かせる相手というより、設計会議の相手として機能しました。
情報設計とコピーを固めてから、サイトに落とした
ここも、実装に入ってから決めるのでは遅かったです。フレームワークより先に情報設計を固めた方が進みやすいと分かりました。
先に決めたのは、例えば次のようなことです。
- どのページが必要か
- どのページで何を伝えるか
- 問い合わせ導線をどう置くか
- まだ出さないものは何か
- どの言葉は使わないか
例えば、AI活用支援を便利屋的に見せないこと。資料請求は、出せる資料が弱いうちは一旦閉じること。トップでは何でもできますではなく、何を支援する会社なのかを言い切ること。こういう判断を先に決めておくと、後の実装が楽になります。
この段階では、サイト制作というより、会社の見せ方を再設計していました。
デザインシステムを先に作っておくと、AIとの対話が速くなる
途中で効いたのが、色、文字サイズ、ブレークポイント、共通クラスなどを早めに整理したことでした。
白基調、オレンジアクセント、余白感を保つこと。LPっぽくしないこと。情報を足すより削ること。こういうルールを持っておくと、ページ追加や修正のたびに「どういうトーンにするか」を説明しなくて済みます。
AIと一緒に作ると、放っておくと説明過多で平均的なデザインに寄りやすいです。だからこそ、デザインシステムは見た目の統一というより、「毎回判断しなくて済むためのルール」として意味がありました。
実装に入ってからは、AIに任せる部分と人が握る部分を分けた
実装自体もAIに助けられましたが、全部を任せたわけではありません。
AIに寄せたのは、
- 反復的なページ実装
- コンテンツ構造の整理
- 共通コンポーネント化
- OGP や記事導線、お知らせ導線の整備
人が握ったのは、
- 何を載せるか
- 何をまだ載せないか
- どこまで具体的に言うか
- この会社らしく見えるか
です。
この分け方をすると、AIっぽい文章や、よくあるコーポレートサイトっぽさが減ります。AIは速いですが、「その会社の芯」は勝手には決めてくれません。そこは人が握る必要がありました。
ローンチ前に大変だったのは、実装そのものより移行計画だった
正直、ここまでは想定していませんでした。サイト自体ができてくると、最後はデザインの微調整だけだと思っていました。
でも実際に重かったのは、もっと運用寄りのところでした。
- 既存コンテンツをどう残すか
- 問い合わせをどこに集めるか
- Slack とメールをどう二重化するか
- 旧 URL をどう扱うか
- ドメイン切替の順番をどうするか
つまり、作るより先に「どう移すか」が問題になりました。
このときも AI と相談しながら、移行計画、役割分担、公開手順を整理していきました。どの技術が良いかだけでなく、STUDIO、Vercel、GAS、さくらのどれを誰が触るかまで含めて言語化したことで、公開の形が見えてきました。
振り返ると、AIでサイトを作ったというより、AIで会社の見せ方と運用を固めた話だった
今回いちばん面白かったのは、AIがコードを書くことより、考える速度を上げてくれたことでした。
戦略整理、サービスの見せ方、情報設計、デザインシステム、技術選定、公開手順。こうしたものを全部ばらばらに考えるのではなく、Claude Code と Codex を相手に一つずつ言葉にしながら詰めていけたのが大きかったです。
結果として、サイトそのものだけでなく、「これからも GitHub を更新しながら改善を回していける状態」まで持っていけました。そこまで含めて、今回のサイト移行でした。
まとめ
AIでコーポレートサイトを作るというと、ついコード生成の話に見えます。
でも実際に効いたのは、
- 先に運用要件を決める
- 技術選定をその要件から逆算する
- 戦略と情報設計を先に整理する
- AIを論点整理の相手として使う
という順番でした。
もしこれから会社サイトを作るなら、まずは「どの技術を使うか」より、「ローンチ後にどう改善を回したいか」を決めるところから始めた方が、結果的に早いはずです。