[前編]7ヶ月手塩にかけたWebサイトを、AIが2週間でリプレイス
kickflow Biz-AX Journal編集部です。
本サイトは、「株式会社kickflowのビジネス系AX（AI活用）を赤裸々に公開する」をミッションとしたブログです。
ブログを立ち上げた背景は、以下の記事もぜひご覧ください。
https://kickflow.com/ax-journal/puf1oo65lxdk
本記事では、タイトルの通り「AIを使ったkickflowサービスサイトのリプレイス」の話をします。
長くなってしまったので、前後編に分けました。今回は【前編】です。
2週間でできたサイト
企画から開発、リリースまで2週間で作ったサイトが、こちらです。
まだ改善中の部分もあります。
それでも、2週間でここまでの機能を持ったサイトが完成し『恐ろしい時代になったな』と感じています。
いまのkickflowのサービスサイトは、「Claude Code → GitHub → Vercel ＋ microCMS」という組み合わせで運営しています。
「Vercelって何？」という方もいらっしゃると思うので、それぞれ簡単に紹介します。
使っているツール/インフラ
Claude
- サイトのコーディングとデザインを、すべて担っています
- 「新しい機能を足したい」「ページを1枚増やしたい」といった修正を依頼し実行してもらっています
GitHub
- Claude Codeが書いたコードを管理しているサービスです
- 後述のVercelと連携しているので、コードを直すと本番への反映（デプロイ）まで自動で進みます
Vercel
- コードを載せて、Webサイトとして公開してくれる土台（PaaS）です
- 低コストで始められて、機能も多くとても便利です
microCMS
- 日本製のヘッドレスCMS（記事などのコンテンツを管理する仕組み）です
- 機能アップデートのお知らせ・導入事例・ブログなどの本文データは、ここに入っています
旧サイトは、7ヶ月かけた「そっくり引っ越し」
旧サイトは、タイトルの通り、7ヶ月かけてWebサイトビルダー系のSaaSで作ったものです（本記事ではver.2と呼びます）。
その前は、WordPressで作っていました（こちらをver.1と呼びます）。
セキュリティの観点から、WordPressをやめてSaaSに引っ越そうと決めたのが2023年です。
そこからベンダー選定、プロジェクト準備、構築、リリース後のチューニングまで、7ヶ月かけてリプレイスしました。
このときのミッションは、「見た目も機能も、そっくりそのまま移す」ことであり、改善や機能追加は実施しないと決めていました。リプレイスの工数を減らすためです。
※それでも、企画から安定稼働までに7ヶ月かかりました。
当時の判断としては、これは正しかったと思っています。
SaaS企業のサイトはWordPressが全盛の時代で、Webサイトビルダーで基幹サイトを作るのは、それなりに勇気のいる判断でした。
が、おかげでWPのPluginの更新や脆弱性の対応等、セキュリティ面の不安は減りました。
ver.1（WordPress）→ ver.2（Webサイトビルダー）引っ越しの7ヶ月
7ヶ月はこの様なタイムラインで進めました。
- ベンダー選定
- 契約調整などの事務手続き
- 要件整理、要件定義
- 既存サイトから移すコンテンツの準備
- リプレイスプロジェクトのマネジメント
- 納品物の動作検証
- トラブル対応（標準機能で実装できないことが途中でわかり、代わりの方法を調べるなど）
- リリース後の不具合対応
転換点は「AI」。→ ver.3（AI webサイト）を目指す
ver.2には、少しずつ課題が見えていました。
それでもだましだまし使っていたのですが、時は2026年。
AI時代の到来です。
状況は一変しました。
SFAやCRMへの入力やデータ分析は、AIがMCPサーバー経由でこなす時代になりました。
コーディング経験のない非エンジニアがコードをゴリゴリ生成できるようになったのです。
AIが作った資料も、社内を飛び交い始めました。
エンジニア以外にもコーディングの可能性が開かれていくなかで、旧サイトには「APIで更新できない」「Claude Codeからサイトを直せない」という弱点がありました。
周りのビジネス環境が変わるほど、サイトだけが「取り残されている感じ」が強くなっていきました。
主な課題は、以下の4つです。
- APIが開放されていないので、記事の入稿や修正は手作業
- CMS機能が一部足りず、複雑な実装で補っていた
- システムの制約で、一部のトラッキングやCV計測がうまく動かない
- 読み込みや表示が遅い
いちばんクリティカルだったのは、サイトのスピードです。
描画やレスポンスに時間がかかり、「もっさり」していました。
背中を押したのは、海外SaaSのサイトの変化
最後に背中を押したのは、「海外のソフトウェア企業のWebサイトの技術スタックの変化」です。
サイトの技術スタックを調べられるツール（Wappalyzerなど）で、コーディングツールCursorのサイトを分析した結果です。
あくまで仮説ですが、Next.jsで書いたコードを、VercelなどのPaaSで公開・運用していると考えられます。
AIでコードを書いて管理するタイプのサイトが、海外を中心に主流になりつつありました。
国内のSaaS企業のサイトもいろいろ調べました。
すると、ごく一部のSaaSスタートアップが、まったく同じ技術スタックになっていることに気づきました。
「自分たちもやろう」と決めたのです。
決めたのは、8月のお盆明けでした。
お盆明けに決めて、リリースは9月2日
まずは情シスに方針を相談しました。
ありがたいことに、AIコーディングとPaaSによるこの運用方式は、kickflowの「2番目」のプロダクトであるTalentifyが、先に実現できることを証明してくれていました。
Talentify（タレンティファイ）- 中堅・大企業の人事課題を解く、AIタレントマネジメントシステム情シスとCTOからは「Talentifyで実績があるから、やってみてもいい」と許可をもらいました。
そこから、要件整理と開発に着手しました。
ここで悩んだのが、「開発にどれだけ時間をかけるか」です。
一般的には、3ヶ月以内にリリースできれば「速い」と言われると思います。
ただ、kickflowには「AI 1st」というバリューがあり、AI活用そのものを推奨するカルチャーがあります。
一緒にリプレイスを進めていたチームメイトと話して、こう決めました。
「普通なら3ヶ月はかかる。でも、ムーンショットを目指して9月2日にリリースしよう」
最初に作ったのは「指針書」
プロジェクトでは、1つルールを決めました。
「AIを最大限使う」ことです。
サイトのコーディングだけでなく、要件整理、過去データの移行、動作検証まで、AIをフル活用します。
まずは「要件定義」の段階から、AIに手伝ってもらいました。
以下は「サイトリプレイス・プリンシパル（指針書）」と呼んでいる文書で、最初に作ったものです。
「なぜサイトをリプレイスするのか」「kickflowのターゲットは誰で、何を感じ取ってもらうのがゴールか」など、リプレイスそのもののゴールや性質を、AIと一緒に整理しました。
プリンシパルは、GitHubのリポジトリの一番上の階層に置いています。
サイトを直すときも、機能を足すときも、AIが必ず参照する「土台のルール」として、今日も燦然と輝いております。
この「骨子」を先に決めて、「骨子に貢献するサイトを作ろう」とAIエージェントと合意してから進めました。
これがないと、たとえば「サイトをかっこよくしてくれ」と頼んだときに、AIエージェントは「かっこよさとは何か」で迷ってしまいます。
文言、ボタンの構成、UXの判断などをブレさせないためには、こうした「プリンシパル」が欠かせません。
AIエージェントでの開発は、初めてでした。
ただ、システム開発の現場で、プリンシパルやプロジェクト憲章を作る場面は何度も見てきました。
「AIにも、たぶん指針書があったほうがいいだろう」と「えいや」で作ったのですが、これが"当たり"だったと思います。
「顧客を理解している人」が、サイトを直接作る
ここからは、プリンシパルに沿ってモック（試作）を作り始めました。
最初から作り込んだ美しいサイトを作ろうとすると、AIのトークン消費も激しく、AIといえど時間がかかります。
そこで「簡素なCSSでいいので、まずはアウトラインを見せてくれ」とAIに頼み、対話しながら作り込んでいきました。
アニメ制作でいうと、まず「ラフスケッチ」を描いてもらった感じです。
（GPT-6 Astra 作）
最小限のCSSでサイトの全体像を作らせ、挙動を確かめながら、少しずつ理想のサイトに近づけていきました。
コードはバージョン管理をしたかったので、このあたりからGitHubで管理し始めました。
手元のPCにテスト環境を立ち上げ、プレビューしながら作り込んでいきます。
開発はとてもスムーズでした。
理由は2つあります。
1つめは、開発も動作確認も、AIがやってくれたことです。
本気の開発はOpus 5、簡単な機能はSonnet 5を中心に進めました。
前例のない機能やデザインのときは、Fableに頼むなど、場面ごとにモデルを切り替えました。
その結果、こちらの意図をかなりのレベルで形にしてくれました。
2つめは、「ビジネスチーム自らが開発した」ことです。
もし制作会社さんに依頼していたら、ここまでのスピードは出なかったと思います。
どんな顧客に、どんなメッセージが刺さるのか。どの機能を特に推すべきか。ターゲット顧客はどんな課題を抱えているのか。
それを一番わかっている「当の本人」が、コーディングもしているのです。コミュニケーションロスはゼロでした。
「顧客を知っている人」が、AIを使って開発する。
その結果、ものすごいスピードで制作が進んでいきました。
とはいえ、大変なこともありました
ここまで「いい話」ばかりだったので、苦しんだところも書きます。
いちばんの壁は、開発の「基本所作」
さらさら〜っと書いてきましたが、スタート時点の私たちは「無知」でした。
「GitHubってどういう仕組みなんだろう」
「Claudeはわかるけど、Claude Codeの画面は触ったことがない...」
「Next.jsとNuxt.jsって何が違うの...？」
そんなレベルです（今はわかっています）。
コードを管理する、手元にコードを持ってくる、テスト環境を立ち上げる、ターミナルで操作する。
エンジニアの方からすれば当たり前の「基本所作」が、精神的にはいちばん辛かったです。
これもAIに聞きながら覚えて乗り越えましたが、ハードルとしてはNo.1だったかもしれません。
AIは、スマホ表示に弱い
AIに開発させていると、確認はついPCの画面サイズが中心になります。
ふとスマホで見てみると、「Oh...」となることが何度もありました。
途中で「一度立ち止まって、モバイル画面をじっくり検証してくれ」と何度も依頼をかけました。
それでもなお、（私の指示が悪いのか）レスポンシブデザインの部分はAIのミスが多く、逐一細かく指示を出していきました。
大変だったのは、この2つです。
逆に言えば、それ以外はAIに相談しながら進められた感覚があります。
とにかくやる。トライ＆エラーする。直す。
根気で乗り越えました！！
後編へ続く...
先月の話なのに、遠い昔のことのようです（笑）
後編は、データ移行、情シスによるコードレビュー、サイト切り替え後のトラブル対応など、「実際のサイトリリース編」です。
まだまだ赤裸々は続きます。
楽しみにお待ちください。
この号はここまでです。
マーケAX をもっと読む