AIで作ったLPがダサくなる原因｜Claude Codeで改善する3つのファイル

はじめに

AIに指示してランディングページを作らせたのに、出てきたものが他社のページとよく似ていて、公開する気になれなかった経験はないでしょうか。プロンプトを書き直しても、翌日また似た見た目に戻ってしまいます。

本記事では、AIで作ったLPが似通う原因と、Claude Codeなどの生成AIでLPを改善するときに置くべき3つのファイルを解説します。スマートエイトは生成AI研修と開発受託を手がけ、自社サイトの改善もAIで内製してきました。

結論として、直すべきはプロンプトの言い回しではなく、指示を残す場所です。毎回消えるプロンプトを磨くより、ページの決まりごとをファイルに書いて積み上げるほうが、出てくるものの下限が上がります。

AIで作ったLPがダサくなる原因｜似た見た目になるのは指示の腕前のせいではない

生成のたびに指示がリセットされる

AIに作らせたLPが毎回似た見た目になるのは、指示の腕前の問題ではありません。前回どんな決まりで作ったかが、次の生成に残っていないからです。

チャット欄に書いたプロンプトは、その回だけの指示です。「もう少し余白を広く」「この青は明るすぎる」と直した内容は、会話が終われば消えます。翌週に新しいページを作るとき、AIはまた初期状態から、無難で破綻のない選択肢を選びます。

無難な選択肢は、誰が指示しても同じ場所に着地します。だから、別々の会社が別々に作ったLPが、結果として似てくるわけです。

これは感覚の話ではありません。AIと対話しながらWebページを作らせる道具がデザインの均一化を招きやすいことは、ワシントン大学の研究チームが2026年3月の論文で、主要な6つの道具を分析して指摘しています。

＊LP（ランディングページ）：広告や検索から訪れた人が最初に着地する、1枚完結型のWebページ。申し込みや問い合わせといった1つの行動に絞って作る。

「AIっぽさ」は7つの兆候で判定できる

「なんとなくダサい」で止まると直せません。スマートエイトでは、AIっぽさを次の7つに分解して判定しています。3つ以上あてはまれば、読み手にもAIっぽさが伝わっていると考えます。

この表は、AIに直させるときの指示書にもなります。「6番と7番に当てはまっているので、そこだけ直して」と伝えるほうが、「もっと良い感じに」より確実に直ります。

原因の中心はデザインではなくコピー

AIっぽく見える原因を突き詰めると、多くはデザインではなく文章に行き着きます。配色や余白は指示すれば整いますが、書いてある中身の薄さは配色では隠れません。7つの兆候のうち1番、3番、6番、7番は、すべて文章の問題です。

スマートエイトが自社サイトを分析したときも、つまずいていたのは文章のほうでした。訪問者のおよそ半数がファーストビュー＊で離脱しており、見出しが3行60文字と長く、しかもその見出し自体がクリックされていました。読み手が見出しをボタンだと誤解するほど、伝わっていなかったわけです。

＊ファーストビュー：ページを開いた直後、スクロールせずに見える範囲。ここで何のページか伝わらないと離脱につながる。

改善の順番｜プロンプトを磨く前に3つのファイルを置く

プロンプトは毎回消え、ファイルは残る

最初に手を付けるのは、プロンプトの言い回しではなく決まりごとを書いたファイルです。プロンプトの工夫はその1回しか効きませんが、ファイルに書いた決まりは次回も効きます。

毎回ゼロから指示し直すか、決めたことを残して積み上げるかの差が、半年後の品質差になります。置くファイルは3つで、理想を書くもの、禁止を書くもの、失敗を書くものに分かれます。

Claude Code＊のようにファイルを読ませられる道具であれば、この3つを置いておくだけで毎回の指示が短くなります。ファイルを読ませられないチャット形式の生成AIでも、同じ内容を定型文として貼り付ければ効果は出ます。

＊Claude Code：Anthropic社の生成AIをパソコンの作業環境から使う道具。手元のファイルを読ませたり、実際にコードを書かせたりできる。

DESIGN.md｜「いい感じ」を数値と色コードに置き換える

DESIGN.mdには、見た目の決まりを数値で書きます。「モダンで洗練された感じ」「いい感じのブルー」は、ここに書いてはいけない代表例です。この2つはAIに伝わらないまま毎回解釈し直されるため、結果が毎回変わります。

書き方の例を挙げます。

• 主となる色は「#6B4FD8」、文字色は「#1A1A1A」と色コードで指定する
• 見出しの文字サイズは32px、本文は16px、行の高さは1.8と数値で指定する
• 要素と要素の間は24px、セクションの間は80pxと決める
• 角の丸みは16pxに統一する
• 使う書体を1つ決め、代替書体まで書いておく

ここまで書くと、指示は「DESIGN.mdに従って」の1行で済みます。色の指定を毎回打ち直す必要がなくなります。

BUILD-RULES.md｜「やってほしいこと」より「やるな」を書く

BUILD-RULES.mdには、禁止事項を並べます。生成AIは「こうしてほしい」より「これだけはやるな」のほうを守る傾向があります。

理想の指示は解釈の幅が広く、AIは幅の中で毎回違う判断をします。禁止は境界が1本しかないため、守られやすいわけです。

スマートエイトが実際に使っている禁止事項です。そのまま流用できます。

• 絵文字をアイコンの代わりに使わない
• 背景にグラデーションを敷かない
• 1つのセクションで2つ以上のことを言わない
• 申し込みボタンはページ内に3回までとする
• スマートフォンは横幅375pxを基準に確認する
• ファーストビューには数字か顧客名のどちらかを必ず入れる
• 入力フォームの項目は5つ以下にする
• 「Get Started」「Learn More」のような汎用的なボタン文言を使わない

入力項目の上限を決めておく価値は大きいものです。HubSpotが自社顧客の4万件を超えるランディングページを分析した結果では、フォームの入力項目が増えるほど完了率が緩やかに下がる傾向が確認されています。

スマートエイトが自社サイトを分析したときも、問い合わせフォームの完了率は6.67%にとどまっていました。ボタンの文言と、背景と近くて見分けにくい色に改善の余地がありました。

GOTCHAS.md｜同じ失敗を二度させないための記録

最初は空のファイルで構わない

3つ目のGOTCHAS.mdは、実際に起きた失敗を書き足していくファイルです。最初は空で構いません。

前の2つは作り始める前に書けますが、失敗は起きてからしか書けないためです。このファイルだけは、使いながら育てる前提で置きます。

書き方は難しく考えなくて構いません。「スマートフォンで見たら申し込みボタンが画面外に出た。横幅375pxで必ず確認する」のように、起きたことと次回の対策を1行ずつ足すだけです。

米国のWeb制作会社Mighty & Trueは、AIで作ったサイトが2ページ目以降で崩れる理由を論じた記事の中で、15回から20回の制作を重ねたこの種の記録は「プロジェクトで最も価値のあるものの一つ」になると述べています。裏を返せば、数回で効果を判断するファイルではありません。

実装後のセルフレビューで指摘を集める

失敗の記録は、待っていても集まりません。作った直後に、AI自身へ指摘させる手順を入れます。

完成したページの画面を撮り、その画像をAIに渡して「これを初めて見る顧客の視点で、AIが作ったように見える箇所を指摘して」と頼みます。作らせた相手に評価させると甘くなるため、新しい会話で頼むほうが率直な指摘が返ってきます。

返ってきた指摘のうち、納得できたものだけをGOTCHAS.mdに書き足します。全部を反映する必要はありません。

うまくいったやり方を個人のメモに留めず、読み込ませられる形で残す考え方は、画面録画でAIに業務を教える方法と同じです。

非エンジニアはどこまで自分でやれるか

正直に線を引きます。3つのファイルを書く作業は、エンジニアでなくてもできます。色の決まりも禁止事項も失敗の記録も、書いてあるのは日本語の業務ルールだからです。文章と構成の案を作らせる工程、画面を見て指摘を出す工程も同じで、品質差の大部分はここで決まります。

一方、出てきたコードを本番のサーバーに反映する部分は、社内に開発者がいないと止まります。ここは無理に内製せず、制作会社や社内の担当者に渡すほうが早く進みます。

ファイルは外部に発注するときにも効きます。「モダンな感じで」と伝えるより、DESIGN.mdを渡すほうが、人間の制作者に対しても認識のずれが減ります。

既存LPを改善する3ステップ｜診断・下書き・実装

診断｜数字と画面を同じ場所で見る

ここからは、すでに公開しているページを直す前提で手順を説明します。公開済みのページには、どこで離脱しているかというデータが既に溜まっており、作り直すとそれを捨てることになるためです。

最初は診断です。アクセス解析の数字と実際の画面を同じ場所に並べ、どこで離脱しているかという数字と、その画面で何が起きているかという仮説を切り離さずに扱います。

スマートエイトが自社サイトで診断したときは、ファーストビューでおよそ半数が離脱していること、競合には「導入社数」を示すラベルがあるのに自社には無いことが分かりました。数字だけでも画面だけでも、この2つは出てきません。

突き合わせると、改善案が「担当者の感想」ではなくなります。社内で予算を通すときにも、この違いは効きます。効果の測り方に迷いがある場合は、生成AIの費用対効果を測る4つの問いを先に読むと判断の軸が定まります。

下書き｜構成はAIに考えさせず、決めた構成を実装させる

2番目は下書きです。ここで重要なのは、ページの構成をAIに考えさせないことです。

構成から任せると、AIは学習した定番の並びを出してきます。それが7つの兆候の5番、定番どおりのセクション順につながります。人が構成を決め、AIには形にさせるほうが独自性は残ります。

判断材料は診断で出た事実です。ファーストビューで離脱しているなら、最初の画面で何を言うかから決め直します。この段階では見た目を作り込まず、どこに何を置くかだけを決めた下書き＊で止めます。

＊ワイヤーフレーム：色や画像を入れず、要素の配置だけを示した設計図。見た目の議論に入る前に、構成の合意を取るために使う。

実装後｜何を見て良し悪しを決めるか

3番目が実装です。3つのファイルを読ませた状態で作らせ、出てきた画面をセルフレビューにかけ、指摘をGOTCHAS.mdに戻します。

公開後に見る数字は1つに絞ります。ページを見た人のうち何%が申し込みや問い合わせに至ったかという転換率＊です。滞在時間やページビューが動いても、申し込みが増えなければ改善したことになりません。

同じ進め方は、広告バナーAI導入で制作工数を削減する方法のように、他の制作物にも当てはまります。

＊転換率（CVR）：ページを訪れた人のうち、申し込みや問い合わせなど目的の行動を取った人の割合。

よくある質問｜AIでのLP改善で迷いやすい点

Claude Code以外の生成AIでも同じやり方は使えますか

使えます。3つのファイルは、道具に依存しない業務ルールだからです。読み込ませられないチャット形式の場合は、DESIGN.mdとBUILD-RULES.mdの中身を定型文として会話の冒頭に貼り付けてください。手間は増えますが、効果の方向は変わりません。

3つのファイルは、どのくらいの分量で書けばよいですか

最初はA4で1枚に収まる分量から始めて構いません。書き切ろうとすると着手が遅れます。

DESIGN.mdは色と文字サイズと余白の3項目、BUILD-RULES.mdは禁止事項5個、GOTCHAS.mdは空でも成立します。足りない部分は、作らせて不満が出たときに足すほうが実態に合います。

デザインの知識がなくてもDESIGN.mdは書けますか

書けます。ゼロから決めるのではなく、既にある自社の資産から拾う方法があります。

自社サイトやパンフレットの画面を撮り、その画像をAIに渡して「使われている色コードと文字サイズを一覧にして」と頼めば、下書きが手に入ります。あとは残す色を人が選ぶだけです。10色使われていたなら、主となる色1つと強調色1つ、背景の白と黒に絞り込みます。

効果が出たかどうかは、いつ判断すればよいですか

十分な訪問者数が集まってから判断してください。数十人分の結果で良し悪しを決めると、たまたま起きた変動を効果だと誤解します。

判断を急ぐと、効いていた変更を戻してしまいます。月間の訪問者が少ないページでは、1か月では足りないと考えたほうが安全です。

さいごに

本記事では、AIで作ったLPが似通う原因と、Claude CodeでLPを改善するときに置く3つのファイルを解説しました。原因は生成のたびに指示が消えることにあり、DESIGN.md、BUILD-RULES.md、GOTCHAS.mdに決まりごとを残すと、出てくるものの下限が上がります。

「AIで作らせたが公開できる品質にならない」「毎回作り直していて工数が減らない」という課題には、指示をファイルとして資産化する進め方が有効です。まずはA4で1枚、自社の禁止事項を書き出すところから始めてください。

スマートエイトの生成AI研修では、こうした業務ルールの言語化から、AIに実行させて検証するところまでを実務の題材で扱います。企業規模・業種に合わせて設計可能です。

詳細はお気軽にスマートエイト公式サービスページからお問い合わせください。貴社の状況に合わせた最適な進め方をご提案します。 ※生成AI研修資料/導入事例も無料ダウンロードいただけます。