なぜ広告用LPを「AIで自作」する選択をしたのか
リスティング広告の指名検索キャンペーンを運用していると、ある壁にぶつかる。既存のコーポレートサイトに広告トラフィックを流しても、コンバージョンが思うように取れない。
理由は明快だった。コーポレートサイトは情報網羅型に設計されている。サービス紹介、会社概要、実績一覧、お知らせ。訪問者がどのページに着地しても迷わないよう、あらゆる導線が用意されている。ただ、それが広告LP（広告専用の着地ページ）としては弱点になる。「電話で相談する」「メールで問い合わせる」という一本のアクションに絞り込めていない。
外注すれば50〜150万円。しかも修正のたびに追加費用と待ち時間が発生する。一方で、広告運用の現場では「この文言を変えたい」「このセクションの順序を入れ替えたい」という微調整が頻繁に起きる。そのたびに外注先とのやりとりが発生するのは、スピードの面で致命的だった。
そこで選んだのが、AIエージェント（Claude Code）を使った完全内製化だ。業界固有の広告規制をどう処理するか、シニア向けのUI設計をどう判断するか。そうした判断を人間が担い、実装のスピードをAIが担う。この役割分担が内製化の前提だった。
指名検索向けLPに必要なのは「1本のアクションに絞り込んだページ」だった
コーポレートサイトと広告LPの違いは、目的の単純さにある。コーポレートサイトは「会社を知ってもらう」ための情報ハブだ。一方、広告LPの目的はたった一つ。「電話をかけてもらう」「フォームを送ってもらう」。この一点に全要素を集中させなければ、広告費が無駄になる。
グローバルナビゲーションは削除した。外部リンクも最小限にした。スクロールの途中でもCTAボタン（問い合わせボタン）が常に目に入るよう、画面下部に固定配置した。ページの構成要素すべてが「問い合わせ」というゴールに向かって設計されている。
この「絞り込み」の判断は人間がやるべき仕事だ。AIは指示されたことを高速で実装するが、「何を捨てるか」の意思決定は持ち主にしかできない。
「65歳以上・スマホ9割」──この数字で設計の方針はほぼ決まった
広告アカウントのデモグラフィックデータを確認した時点で、方針はほぼ決まった。65歳以上が大半を占めていて、デバイスの9割がスマホだった。この数字を前にして、まず考えたのはフォントサイズだった。
一般的なWebサイトの本文は14〜16pxで設計されている。しかし65歳以上のユーザーがスマホで閲覧する前提では、それでは読めない。「小さくて読みづらい」と感じた瞬間に離脱される。広告費を払って呼び込んだユーザーを、文字の大きさの問題で逃がすわけにはいかなかった。
最終的に本文のフォントサイズは 17px に設定した。見出しは24px以上を基本とした。行間（line-height）は1.8に広げた。これだけで、スマホ画面での可読性が劇的に改善された。
タップターゲットの最小サイズ
GA4のデバイス分布を深掘りすると、iPhoneの比率が突出していた。CTAボタンの高さは 60px を最低ラインに設定した。通常の約1.5倍で、指の太い方でも入力エリアを正確にタップできる高さだ。
FAQセクションでは、質問テキストだけでなく行全体をタップできるようにした。最小の高さは60pxを確保している。質問文の右端にある小さな矢印を正確にタップする必要はなく、行のどこを触っても開閉する。
iOSの自動フォント拡大への対処
iOSの自動フォント拡大を防止するCSSも指定した。設計したフォントサイズを、ブラウザが勝手に変えてしまうのを防ぐ設定だ。スマホ画面の下部に常時表示する固定ボタンの裏にコンテンツが隠れないよう、画面下部に十分な余白も確保した。
これらの設計判断はすべて、ターゲットの年齢層とデバイス環境から導き出したものだ。デザインの好みではなく、データに基づいた実装だった。
広告LPで「やってはいけない」4つの規制対応
業界固有の広告規制は、LP制作において最も慎重に扱うべき領域だ。特に注意したのは以下の4つの表現規制だった。
- 比較広告の制限──他社サービスとの直接比較は避ける
- 誇大表現の禁止──根拠のない数値や「No.1」表記は使わない
- 効果の断定禁止──「必ず」「確実に」などの断定表現を避ける
- 体験談・ビフォーアフターの制約──掲載条件が厳しいため使用しない
比較表を削除し、自社実績に切り替えた判断
当初は他社との比較表を掲載する予定だった。しかしレビューの段階で、比較表現の規制に該当するリスクがあると判断した。
削除した比較表の代わりに、既存の「選ばれる理由」カード内に具体的な数値実績を追加した。他社との比較ではなく、自社の事実を端的に示す表現に切り替えたのだ。実績の数値には※注釈をつけて根拠を明示した。計測期間、対象拠点、算出方法を具体的に記載している。根拠なき数字は誇大広告と判断されるリスクがある。
「載せない」が最も安全な選択肢になる場面
効果に関する表現は断定を避けつつ、サービスの意義を伝える表現に調整した。そして顧客の声やビフォーアフター的な表現は一切使わないと決めた。掲載条件をクリアする手間を考えると、使わない方がリスクが低い。規制の厳しい業界では「載せない」という判断が最も安全な選択肢になることがある。
AIはこの規制チェックのプロセスでも役立った。「この表現は規制に抵触しないか確認して」と聞けば問題提起はしてくれる。だが最終的にどう対処するかの判断材料は、人間が与える必要があった。
ブランドカラーとタイポグラフィの設計
カラーはプライマリに落ち着いたダークグレー、アクセントにティール系の緑を設定した。ティール系のアクセントカラーは、専門サービス業のサイトで信頼感を演出する定番の色だ。カード要素の影にもブランドカラーの成分を混ぜて、微かな統一感を出す工夫をしている。
フォントは日本語にNoto Sans JP、数値表示用に欧文フォントPoppinsを組み合わせた。実績の大きな数字は欧文フォントで表示される。和文と欧文でフォントを使い分けることで、可読性と視覚的なメリハリの両方を確保した。
「自前で何も持たない」という設計思想──Vercel・Jotform・Remix Icon・Google Fonts
ホスティング（Webサイトの公開場所）にはVercelの無料枠を使っている。静的HTMLを1ファイル置くだけなので、無料枠の範囲で十分に運用できる。CLIからワンコマンドでデプロイが完了する。
フォームにはJotformを採用し、iframeで埋め込んだ。アイコンはRemix Icon、フォントはGoogle Fonts。すべて外部CDNから読み込む構成にして、自前でサーバーを管理する必要をゼロにした。
レスポンシブ設計のブレークポイント判断
ブレークポイント（画面幅によってレイアウトを切り替える境界値）は960pxと1330pxの2段階に設定した。Tailwind CSSの初期値は1024pxだが、960pxに下げた。理由はタブレットの横持ちに対応するためだ。iPadの横向き解像度は1024pxだが、ブラウザのUI部分を差し引くと実質的な表示幅は960px前後になる。ここを境にレイアウトを切り替えれば、タブレットユーザーにもPC向けの表示を届けられる。
1330pxにしたのは、本文の行長を制御するためだ。日本語の長文は、1行あたり35〜45文字が読みやすいとされている。1330pxの表示幅にすると、17pxの本文サイズでちょうどこの範囲に収まった。
基本方針はモバイルファースト（スマホ向けの表示を先に作り、PC向けを後から追加する手法）で書くことだった。まずスマホ向けのスタイルをベースに記述し、画面が大きくなるにつれて上書きしていく。たとえばサービスカードの並びは、スマホで1列、タブレットで2列、PCで3列に切り替わる。
CSS変数によるブランドカラーの一元管理
ブランドカラーはCSS変数で一元管理した。Claude Codeに「アクセントカラーをもう少し青寄りにして」と指示すれば、変数の値を1箇所変えるだけでサイト全体に反映される。もしHTMLの各所にカラーコードをハードコードしていたら、1箇所ずつ置換していく作業が必要で、修正漏れが起きてもおかしくない。
Webflow移行は完全に失敗した──3つのアプローチと3つの壁
正直に言えば、Webflow移行は完全に失敗した。3つのアプローチを試して、全部壁にぶつかった。
Figma経由ルート──プラグインの制限
最初に試したのはFigma経由のルートだった。あるプラグインでHTMLをFigmaに取り込み、そこから別のプラグインでWebflowに流し込む。2段階の変換が必要だったが、うまくいけば視覚的な編集環境が手に入る。ところが最初のプラグインでアクセス制限エラーが出た。別の方式で回避はできたものの、次のプラグインが「画像50枚超過」のエラーで止まった。画像の多いLPでは、この制限を回避する方法は見つからなかった。
API連携ルート──Rich TextフィールドでHTMLが壊れる
次に試したのがAPI連携だ。WebflowのAPIをClaude Codeから直接叩いて、HTMLを書き込む方法。しかしWebflowのRich Textフィールドは、外部から注入したHTMLの構造を勝手に書き換えてしまう。Tailwind CSSのクラス名が消え、レイアウトが崩壊した。
現実解──iframe埋め込み
最終的にたどり着いたのは、WebflowページにカスタムコードブロックでVercelホストのLPをiframeで埋め込む方法だった。Vercel側のHTMLを更新してデプロイすれば、Webflow側はiframeが最新のURLを自動参照するから、何もしなくていい。
技術的に美しい解ではない。CMSの意味がほぼなくなっている。でも「動くものを今すぐ公開する」という要件は満たした。理想的なCMS運用を追い求めて公開が遅れるよりは、実用的な判断だったと思っている。AIによる内製化の強みは、こうした方針転換が即座にできることにもある。外注していたら、CMS移行の失敗で追加費用と追加納期が発生していただろう。
指示→生成→デプロイ→確認──1サイクル数分を何十回も回す
制作フローは、驚くほど単純なサイクルの繰り返しだった。
Claude Codeに修正を指示する。コードが書き換わる。デプロイコマンドを実行する。ブラウザで確認する。この4ステップが1サイクルだ。早ければ数分で1サイクルが完了する。これを何十回も回す。
重要なのは、このサイクルの速さそのものよりも、「試行錯誤のコストがほぼゼロ」という事実だ。「やっぱりこのセクション順序を入れ替えよう」「CTAの文言を3パターン試したい」。こうした変更が、追加費用なしで即座に実行できる。
AIが自動で対応してくれた領域
特に指示しなくてもAIが自動で対応してくれた領域がある。たとえばアクセシビリティ対応だ。imgタグにalt属性を付ける、フォームのlabel要素を適切に関連付ける、コントラスト比を確保する。これらはWebアクセシビリティのベストプラクティスとして、AIが当然のように実装してくれた。
これはAIの隠れた大きなメリットだ。デザインの専門知識がなくても、AIが「こうした方がいい」と提案してくれる。外注なら追加費用になるアクセシビリティ対応が、AIなら指示1つで実現できる。
明示的に伝えなければ対応できなかった領域
一方で、明示的に伝えなければ対応できなかった領域もある。業界固有の広告規制の具体的な制約条件がその筆頭だ。「この表現は規制に抵触しないか確認して」と聞けば問題提起はしてくれる。だが最終的にどう対処するかの判断材料は、人間が与える必要があった。
AIが圧倒的に強い領域と、委ねるべきでなかった判断
AIが圧倒的に強かったのは「網羅的な適用」だ。
このLPは1ファイル約1,260行のHTMLで完結している。AIにとって把握しやすいサイズだった。10箇所以上あるCTAの文言やスタイルを一括で修正する、全セクションにレスポンシブ対応（スマホでもPCでも崩れないレイアウト）を漏れなく適用する。こうした「同じルールを全体に均一に適用する」作業は、人間が手作業でやると必ず抜け漏れが出る。AIはそれをゼロミスで完遂した。
コストと品質の実績
コストの内訳はシンプルだ。Vercelの無料枠、Jotformのフォーム埋め込み、Claude Codeの利用費。外注費用の50〜150万円と比較すれば大幅に抑えられた。ただし「自分の時間」はかかっている。AIとの対話時間、ブラウザでの確認時間、規制の調査時間。これらをゼロとは言えない。それでも、外注の場合に発生する「待ち時間」が消滅したことの価値は大きかった。
品質面では、3つの要件を満たせた。業界固有の広告規制に準拠していること、シニアユーザー向けにUXを最適化していること、全デバイスでレスポンシブ対応が完了していること。
最大の価値は「修正の即時性」
最大の価値は「修正の即時性」だった。公開後に「この文言を変えたい」と思ったら、その場で変更してデプロイできる。外注先に修正依頼を出して、見積もりを待って、スケジュールを調整して、という工程がない。広告運用では、LPの文言やレイアウトをA/Bテストしながら改善していくのが基本だ。その改善サイクルが、AIによる内製化で劇的に短縮された。
内製化を検討する前に確認すべき3つの前提条件
最後に、AIによるLP内製化を検討している方へ。成功のために事前に確認すべき3つの前提条件をまとめておく。
1つ目は、ターゲットの具体的なデータを手元に持っているかどうか。
広告アカウントのデモグラフィックデータ、GA4のデバイス分布、過去のコンバージョンデータ。これらを事前に把握しておく。「65歳前後、スマホ比率9割」という数値があったからこそ、フォントサイズ17pxやボタン高さ60pxという具体的な設計判断ができた。AIにターゲット情報を数値で渡せば、最適な設計を自動で提案してくれる。
2つ目は、業界固有の規制を事前に洗い出しているかどうか。
AIはこれらの知識を持っているが、最新の改正内容や実務上のグレーゾーンまでは把握していない。事前に人間が洗い出しておけば、AIに「この表現は規制的に問題ないか」と確認を取りながら進められる。
3つ目は、技術スタックがプロジェクト規模に合っているかどうか。
LPであればReactもNext.jsも不要かもしれない。HTML1ファイルにTailwind CSSのCDN版を読み込む構成を選んだことで、ビルド環境のセットアップに時間を使わず、コンテンツ制作に集中できた。シンプルな構成ほど、AIとの共同作業はうまく回る。
AIによるLP内製化は、万能な解決策ではない。だが「修正の即時性」「コスト削減」「品質の担保」という3つの条件を同時に満たせる数少ない手段だ。適切な前提条件を整えた上で、試してみる価値は十分にある。
