LAMPコーポレートサイトのリニューアルの秘話 - 人がデザインしAIが実装する、AI駆動実装の16日間わかったこと！

LAMP LLC. のコーポレートサイト（https://lamp.design）を、2026年9月10日に全面リニューアルしました。

これまでのサイトは、ノーコードツールの Studio で作っていました。今回は、2つのAI（Claude Opus 5 と GPT-6 Astra）を活用したAI駆動開発方式に切り替えています。

役割分担はシンプルです。

• 人（代表の吉村）：何を作るかを決め、デザインし、出来上がりの良し悪しを判断する
• AI：プログラムを書き、サーバーを用意し、公開作業まで行う

LAMPにとって、AIに実装を任せる制作は今回が初めてです。着手から公開まで16日間でした。

この記事では、完成したサイトの紹介ではなく、進め方に関してになります。どう任せたか、どう伝えたか、何をやめたか、どこでつまずいたか、などの手順の参考になるような記事になります。

この記事の読み方

専門的な言葉は、なるべくひかえています。どうしても必要な専門用語は、最後の「この記事に出てくる言葉」で説明していますので参考になればと思います。

目次

1. 16日間の流れ
2. 人がデザインし、AIが実装する体制をどう作ったか
3. 2つのAI（Claude Opus 5 と GPT-6 Astra）をどう使い分けたか
4. AIへの伝え方と、デザインの意図を正しく届ける方法
5. 16日間で走り切るために、決めたこと・やめたこと
6. 使った技術と、実際に使ってわかったこと
7. ノーコードと比べてわかった、速さ・仕上がり・更新しやすさの違い
8. つまずいた場面と、抜け出し方
9. 同じやり方を試すためのチェックリスト
10. おわりに
11. この記事に出てくる言葉

1. 16日間の流れ

数字でみる今回の制作

日ごとにやったこと

最後の3日間で、全体の作業の7割が動いています。

前半はAI1体でじっくり土台を作り、後半はAI2体で一気に広げました。この切り替えが、16日間で公開までたどり着いた一番の理由です。

2. 人がデザインし、AIが実装する体制をどう作ったか

最初に「人が手放さないもの」を決めた

AIに何を任せるかから考えると、任せる範囲がいつの間にか広がります。そこで逆に、人が手放さないものを先に決めました。

「本番に出す前は必ず聞く」をルールに

いちばん効いたのは、本番に出す作業の前に、AIが必ず人の許可を取るというルールです。AIへの作業ルールには、次のように書きました。

本番に出す前に、必ず確認を取る。勝手に出さない。 確認するときは「何が変わるか」「元に戻せるか」「何を確かめたか」を添える。

この3点を毎回添えさせると、人は「なんとなくOK」ではなく、「根拠を見てOK」と判断できるようになります。

準備の段階は、AIのチームで1日で進めた

着手の前日に、要件の整理、ページ構成、管理画面の項目、情報構成の箇条書きまでを1日で作りました。

使ったのは、LAMPが社内で整えている「WEB制作AIエージェントチーム」です。担当ごとのAIが資料を作り、作ったAIとは別の「チェック役のAI」が必ず見直す仕組みになっています。

実際、3つの資料が1回目のチェックで差し戻され、2回目でクリアしました。AIが作ったものを別のAIが一度見直すと、人が見る時点での完成度が上がります。

デザインは、人(吉村)が Figma で作ったデザインを適応するようにしました。

たたき台はAIで素早く作り、見た目の最終判断は人が取り直す。 この順番は最終的に効率的でした。

「どれが正しい情報か」を1つに決めた

人とAI、AIとAIが同時に動くと、「どの資料が正しいのか」が分かれてしまいます。そこで、正しい情報の置き場所を3つに決めました。

さらに、資料どうしが食い違ったときは、AIが勝手に決めずに止まって聞く、ルールにしました。AIは食い違いを見つけると、それらしい方に黙って合わせがちです。「止まって聞いてよい」と伝えておくと、やり直しが減ります。

3. 2つのAI（Claude Opus 5 と GPT-6 Astra）をどう使い分けたか

前半は1体、後半は2体

1日目から13日目までは、ほぼ Claude Opus 5 だけで作業しています。トップページの3Dロゴや動き、スマホ対応、管理画面の立ち上げ、旧サイトからの移行までです。

2体目の GPT-6 Astra を加えたのは14日目です。この時点で、トップページ、デザインシステム、管理画面の土台が Claude Opus 5 が作成し揃っていました。

土台ができてから、2体に分けたのがポイントで、土台がないうちに2体を動かすと、同じことを2回、別々の答えで決めてしまいます。

※ GPT-6 Astraが制作途中でリリースために導入した経緯もあります。

分担は「機能」ではなく「ファイルの置き場所」で分けた

2体を同時に動かすとき、いちばん怖いのは同じファイルを2体が同時に書き換えることです。あとで変更がぶつかり、どちらを残すか判断できなくなります。

そこで、担当を「お問い合わせ機能」のような機能単位ではなく、ファイルの置き場所で分けました。

作業場所も、AIごとに分けています。Git というプログラムの履歴を管理する仕組みを使い、1つのプロジェクトから複数の作業場所を作りました。

「受け渡しの約束」を先に決めた

もう1つの工夫は、画面とデータの間の「受け渡しの約束」を、作る前に決めたことです。

たとえば「記事一覧の画面には、タイトル・日付・カテゴリー・サムネイルを、この名前と形で渡す」という一覧表を先に作ります。

1. 裏側担当が、受け渡しの約束だけを先に決めて共有する
2. 見た目担当は、その約束だけを見て画面を作る
3. 裏側担当は、同じ約束を守るようにデータを用意する

こうすると、2体がお互いの完成を待たずに同時に進められます。実際15日目には、GPT-6 Astra がお問い合わせフォームの画面を作り、Claude Opus 5 が送信内容の受け取りとメール通知を作り、同じ日のうちにつなげています。

約束を変えるときのルールも決めました。項目を「足す」だけなら先に進めてよく、「消す」「名前を変える」ときは相手に合図を出してから、という決まりです。

実際に見えた、2体の得意なこと

※こちらは9月10日時点の内容となります。

同じルールで動かしても、進め方には違いが出ました。性能の優劣ではなく、どちらにどんな仕事を任せると速いかという観察です。

2体を同時に動かすために必要だったルール

• 作業場所はAIごとに分ける
• 確認用のプレビュー画面もAIごとに分ける
• データの保管庫は1つを共有しているので、設計を変えてよいのは裏側担当だけにする
• 相手の担当ファイルを「ついでに」直さない。気づいたことは伝えるだけにする

4. AIへの伝え方と、デザインの意図を正しく届ける方法

デザインは「目で見て」ではなく「測って」再現させる

いちばん効果が大きかったルールは、これです。

デザインの寸法は、書き出した画像をピクセル単位で測って決める。目分量で置かない。 作ったあとの画面も同じ方法で測り、デザインと比べる。

AIにデザインを見せて「この通りに」と頼むと、雰囲気は合っても、余白や文字の大きさが数ピクセルずつずれます。

そこで、Figma から書き出したデザイン画像（パソコン用は横1440px、スマホ用は393px）をピクセル単位で測らせました。作った画面も同じ方法で測らせると、ずれはほとんどなくなります。

動きの指示は「いったん文章の仕様書にしてから」作らせる

トップページの3Dロゴや、実績カードが流れる演出は、Figma の動きの指示書と絵コンテで伝えました。

ここで大事にしたのは、指示書からいきなり作らせず、いったん文章の仕様書に書き直させることです。仕様書には次の決まりを設けました。

• 指示書にない数字は、AIが決めた理由と一緒に書く
• デザイナーの確認が必要なところには「要確認」と書く
• 指示の間違いが見つかったら、直したことを記録に残す

たとえば「ロゴがくるくる回り続ける」という指示は、仕様書では「横方向にだけ回る。約11秒で1回転。登場のときだけ速く回って1.4秒で止まる」まで具体的になっています。

途中で、最初の指示書にあった「途中で回転が止まる」などは間違いだと発覚しAIが調整しました。意図が途中で変わること自体は問題ではありません。変わったことが記録に残らないのが問題です。

不具合は「直し方」ではなく「見えたこと」を伝える

人からAIへの伝え方は、短い言葉がほとんどでした。実際のやり取りから抜き出すと、こうです。

• 「本番環境をみているが、3Dロゴがなくなっている」
• 「CMSの並びが完全に崩壊している」
• 「何度やってもCMSの並びが直近のものにならない？1番が古く、53番が新しい」

どれも「どう直して」ではなく、何が、どこで、どう見えているかを伝えています。

直し方まで人が指定すると、それが的外れでもAIは従います。見えたことだけを伝えると、AIは再現、計測、原因の調査から始めてくれます。

一方で、決まっている言葉や値は一字一句まで指定しました。お問い合わせの通知メールの件名、管理画面の項目名、色の値などです。

「見えたことで伝えるもの」と「そのまま指定するもの」を分けると、伝え方に迷わなくなります。

別のAIに仕事を引き継ぐときの「引き継ぎ書」

2体目のAIに仕事を渡すとき用の引き継ぎ書を作りました。

特に「データの件数」と「まだ決まっていないこと」を書くのがコツです。件数がわかれば、ページ送りや「0件のとき」の見せ方を先に考えられます。未定と書いておけば、AIが勝手に決めて進めるのを防げます。

確認の基準は数字で決める

「崩れていないか確認して」ではなく、確認の基準を数字で決めました。

• 画面幅 320・393・768・1024・1440px のそれぞれで、横にはみ出していないこと
• 文字と背景の明るさの差（コントラスト比）が 4.5:1 以上あること
• iPhoneなどで「動きを減らす」設定をしている人には、アニメーションを止めること
• 画像には説明文を付けること

数字で決まっていれば、AIが自分で確認できます。人は、その結果と実際のスマホでの見え方だけを見ればよくなります。

記憶は会話ではなく「記録」に残す

AIとの会話が長くなると、途中の細かい内容が要約されて消えてしまいます。そこで、決まったことは会話ではなく、ファイルに残すと決めました。

• 変更するたびに「なぜ変えたか」「何を確かめたか」を書く
• 運用に関わる決定は、その日のうちに説明書へ書く
• 残りの作業は「どの画面の、どのボタンを押すか」までわかる形で一覧にする

説明書は最終的に約2,000行になりました。これがあるから、担当者や使うAIが変わっても作業を引き継げます。

5. 16日間で走り切るために、決めたこと・やめたこと

決めたこと

やめたこと・後回しにしたこと

16日間で公開するうえで、いちばん重かった判断は「何をやらないか」でした。

やめたことの多くは、なくしたのではなく、公開時での対応に後回しにしました。大事なのは、後回しにしたことを曖昧にせず、一覧に残しておくことでした。

6. 使った技術と、実際に使ってわかったこと

何を使ったか

※ノーコードWEBサイト開発のStudio を使っている人向けに、「Studio でいうと何にあたるか」も記載しています。

使ってわかったこと

Next.js（画面を作る土台）

• よかった点：ページのタイトルや、検索エンジン向けの設定まで、細かく作り込める
• 注意点：新しいバージョンのため、AIが知っている情報と違うことがある。最新の説明書を先に読ませる必要がある

Payload CMS（管理画面）

• よかった点：Studio の CMS とほぼ同じ項目の構成を、そのまま再現できた
• よかった点：管理画面そのものを使いやすく改造できる。今回は、一覧の表のまま文字を直せる機能、行をドラッグして並べ替える機能を追加しました
• 注意点：Payloadの初期設定のままだと、作業のたびにデータの保管庫の設計が勝手に書き換わるため複数のAIで作業するときは、この設定を必ず止めました
• 注意点：利用者ごとに保存される「一覧の並び順」が、こちらで決めた並び順より優先されることがある

Supabase（データと画像の保管庫）

• よかった点：データと画像を1か所で管理でき、有料プランでは毎日のバックアップも付く
• 注意点：同時につなげる数に上限があり、作業中の画面をたくさん開いていると、公開用の準備が失敗することがある
• 注意点：画像の公開用URLは、初期設定のままではサイトから表示できず、設定の変更が必要

Vercel（公開するサーバー）

• よかった点：変更を出すたびに、確認用のURLが自動で作られる
• 注意点：サーバーに置いた設定値を変えたら、もう一度本番公開し直さないと反映されない
• 注意点：閲覧制限の機能は有料プラン

GSAP・Lenis・Three.js（動きと3D）

• よかった点：スクロールに合わせた動きや、ページ全体を通して動く3Dロゴを作れた
• 注意点：3Dのデータを軽くして配信していると、セキュリティ設定によっては表示が止まる（詳しくは8章のつまずいた場面と、抜け出し方に記載しています）

まとめ

この組み合わせは、ノーコードでは難しい演出や、管理画面の作り込みを両立したいときに向いていました。

一方で、サーバー、データの保管、メール送信、バックアップ、セキュリティを、すべて自分たちで面倒をみる必要があります。

7. ノーコードと比べてわかった、速さ・仕上がり・更新しやすさの違い

これまで Studio でサイトを運用してきた立場から、正直に書きます。同じサイトを Studio でも作り直して比べたわけではありませんが、今回の作業記録から見えた傾向です。

速さ

デザインを実装する速さは、AIに任せる方式のほうが速い場面が多くありました。 ただし、ノーコードが最初から用意してくれている「運用の土台」を、自分たちで揃える時間が加わります。

仕上がり

• 表現の幅：ページ全体を通して動く3Dロゴ、スクロールに合わせて実績カードが立方体に吸い込まれる演出、らせん状に並ぶ実績一覧などは、ノーコードでは難しい表現です
• デザインの再現度：ピクセル単位で測って作るので、デザインとのずれを数ピクセルまで詰められます
• 管理画面の自由度：準備の段階で Studio を前提に検討したとき、「記事の表示件数を表示する」デザインは Studio の CMS では作れず、デザイン側を削る判断をしていましたがAI駆動だと実現できました。また旧サイトは、Studioの契約プランの CMS で公開数上限などがあり、ページを増やす余地が長期的にみると懸念事項にありましたが、今回のAI駆動方式では、こうした制限がありません
• セキュリティ：ここは逆に、ノーコードのほうが安心しやすい部分です。Studio や Framer が公開しているセキュリティの資料と、AI駆動実装のサイトの状態を1つずつ比べる必要があり、Studio側がまとめて守ってくれている部分を、自分で1つずつ埋める必要がありました

更新しやすさ

結論

ノーコードとAIに任せる方式は、どちらかに置き換わるものではなく、使い分けるものだと考えています。

• 表現の作り込み、管理画面の独自の使い方、データを自分たちで持つことが大事なサイトは、AIに任せる方式が向いている
• 更新の手軽さ、運用の手間の少なさ、ノーコードサービス側に任せられる安心が大事な案件は、ノーコードが向いている

そしてAIに任せる方式を選ぶなら、画面を作ること以上に、運用の土台と説明書づくりに時間をかける前提で計画する必要があります。

8. つまずいた場面と、抜け出し方

同じ場面に出会ったときの参考になるよう、「何が起きたか」「原因」「どうしたか」「学び」の順で書きます。

データの保管庫の「設計の記録」と実物がずれた

• 何が起きたか：管理画面の項目を足そうとすると、存在しない項目について質問されて作業が止まった
• 原因：途中で、設計の変更を記録の手順を通さずに直接行っていた。そのため、記録と実物の間にずれが出ていた
• どうしたか：記録を作り直し、実物の562項目と1つずつ照らし合わせて、ずれがないことを確認した。中身のデータには触れないようにした
• 学び：設計の変更は、必ず決まった手順を通して行う。近道をすると、あとで大きな手間になる

管理画面にあるコンテンツの並び順が、サイトと合わなかった

• 何が起きたか：管理画面で実績の一覧を開くと、サイトと違う順で並んでいた。直しても、開き直すと元に戻った
• 原因：管理画面が利用者ごとに「前回の並び順」を覚えており、それがこちらで決めた並び順より優先されていた
• どうしたか：一覧を開いたときに、必ず正しい並び順に直す仕組みを足した。
• 学び：「何度やっても直らない」ときは、プログラムの外（保存された設定など）に原因があることが多い

旧サイトにしかないページ(URL)が残っていた

• 何が起きたか：公開直前に、旧サイトの全ページの一覧と新サイトを突き合わせると、31ページのうち12ページが新サイトになかった
• どうしたか
• • カテゴリー別・キーワード別の一覧10ページ：記事一覧へ自動で案内するようにした
  • ヒアリングシートと、お客さま満足度アンケートの2ページ：入力項目が多い業務用のフォームだったため、公開前に新サイトで作り直した
• 学び：移し忘れは、記憶ではなく、旧サイトのページ一覧で機械的に洗い出す

旧サイトを止めると、取れなくなる素材があった

• 何が起きたか：写真が、旧サイトの管理画面にしか残っていなかった
• どうしたか：旧サイトを止める前に、写真を保存した
• 学び：旧サイトは、すぐ元に戻せる避難先として、そして素材の保管庫として、公開後もしばらく残すのがオススメです

9. 同じやり方を試すためのチェックリスト

体制づくり

• 人が手放さないこと（何を作るか、デザイン、判断、本番に出す許可）を先に決める
• 本番に出す前は、AIが必ず許可を取るルールにする
• 許可を取るとき「何が変わるか」「元に戻せるか」「何を確かめたか」を添えさせる
• 見た目、作り方、作業、それぞれの「正しい資料」を1つずつ決める
• 資料が食い違ったら、AIが止まって聞くようにする

AIを2体動かすとき（Claude Opus 5 と GPT-6 Astra）

• 土台ができてから2体に増やす
• 担当を「機能」ではなく「ファイルの置き場所」で分ける
• 画面とデータの「受け渡しの約束」を、作る前に決める
• 作業場所と確認用の画面を、AIごとに分けた

伝え方と確認

• デザインは、書き出した画像を測って再現させる
• 動きの指示は、いったん文章の仕様書にしてから作らせる
• 不具合は「見えたこと」で伝え、決まっている言葉や値はそのまま指定する
• 確認の基準を数字で決めた（画面幅、文字の見やすさ、動きを減らす設定）
• 決まったことは、会話ではなくファイルに残させる

公開と運用

• 旧サイトのページ一覧で、移し忘れを洗い出す
• 「検索に出さない設定」と「閲覧制限」を準備
• バックアップを準備
• セキュリティ設定をする
• 旧サイトを、元に戻せる避難先として残す

10. おわりに

今回、人が担ったのは、何を作るかを決めることと、出来上がったものの良し悪しを決めることでした。手を動かす作業の大半はAIが担い、16日間で公開まで出来ました。

一方で、AIが速く作れるからこそ、決めたことを記録し、正しい情報を1つに保ち、本番に出す判断を人が持ち続ける仕組みが欠かせません。この記事で書いたことの多くは、開発の話ではなく、その仕組みの話です。

また、今回のこの記事自体もAI駆動開発をしたおかげて作業履歴を細かくAIが残したログを元に作成できた副産物です。

LAMPは、これまでのノーコードでの制作に加えて、AIに実装を任せる制作を、正式に提供する領域として位置づけていきます。

• 表現の作り込みや管理画面の独自の使い方が大事な案件ではAIに任せる方式
• 更新の手軽さや運用の手間の少なさが大事な案件ではノーコードで制作

案件ごとに合った作り方を選べることを、自分たちのサイトで今回確かめることができました。

AIを活用したWebサイト制作や、ノーコードとの使い分けのご相談は、お問い合わせフォームからお気軽にご連絡ください。

11. この記事に出てくる言葉

Credit

Project member

• Producer / Art Director / WEB Designer / AI Technical Director：Yuichi Yoshimura（LAMP LLC.）
• Frontend / Backend / Deploy：Claude Opus5, GPT-6 Astra

リンク

• コーポレートサイト：https://lamp.design/
• 様々なご相談：https://lamp.design/contacts
• WEB制作のご相談：https://lamp.design/contacts/no-code-web