H2-1:なぜ今、LPをAIと一緒に作るのか
WordPressとSWELLでブログや情報サイトを運営していると、「このサービスだけはLPをちゃんと作りたい」というタイミングが必ず来ます。
今回の僕にとってのそれが、「問い合わせmini」でした。
問い合わせminiは、小規模事業者の問い合わせ対応を少しラクにするための無料ミニシステムです。
同じ問い合わせへの同じ回答に毎日追われて、本業の時間が削られていく──そんな現場の悩みを解消するために作ったツールです。
ただ、その想いをきちんと伝えるLPを作ろうとすると、
- 誰のどんな悩みを
- どんな順番で揺らして
- どんな行動につなげるのか
を整理しなければいけません。
そして、構成・コピー・デザイン・コーディングまで一人で抱えるのは、正直しんどい。
というかLPを作るのは本来デザイナーの仕事でしょ! デザイナーでもない私がLPを作るちょっとおかしくないですかという企画ですよね。 最終的にデザイナーでもない私が、LPをデザイン、コーディング含めてできたとしたら、デザイナーこれからどうするの問題に発展しそうだよね。
そこで今回は、デザイナーでもない筆者が、デザイナーの役をもたせたAIを相棒にしてLPを作るというチャレンジをしてみました。
「AIと話しながらLPを作ったら、素人でもどこまでいけるのか?」を検証する企画でもあります。
今よく言われている AIがいればデザイナー不要論 さあどうなることやら
H3-1:集客プロセスの中で、LPが担う役割を先に決める
LPを作る前に、まず考えたのは「このLPは集客プロセスのどこを担当させるか」です。
マーケティング視点でざっくりプロセスを書くと、こんな流れになります。
- 気づき(認知)
- 興味・関心
- 勉強・学び・情報収集
- 信頼形成
- 資料請求・無料ダウンロードなどの軽いアクション
- 購入・申込
- リピート・継続利用
それぞれは、IN(どこから人が入ってくるか)とOUT(このステップを通過した人はどういう状態になるか)を持っています。
LPはこの中で特に 「興味・関心〜信頼形成〜最初の行動」 をつなぐ役割を担います。
今回の問い合わせmini LPで言えば、
- IN:ブログ記事やSNSで「問い合わせ対応が本業の足かせになっている」という話に触れてきた読者
- OUT:「問い合わせminiを一度使ってみよう」「無料版を導入して定番の問い合わせだけでも自動化してみよう」という行動
を生み出すのが、このLPの役割です。
この「IN / OUT」を先に決めておくと、
- どこまで説明するか
- どこから先は別ページ(仕様書やヘルプ)に任せるか
- LPの中でどこが一番重心になるか
がブレにくくなります。
重要なのは、「グローバルメニューを消したからLPの目的を達成した」と考えないことです。
LPの目的は見た目をLPにすることではなく、読者の行動(OUT)を設計することだという前提を最初に置いておきます。
H3-2:AIは部分最適のプロ、全体の舵取りは自分がやる
ここで一つ、AIとの付き合い方についての前提を置いておきます。
AIは、基本的に「今投げられた質問」に対して、もっともそれらしい答えを返してくれる存在です。
つまり、局所最適には非常に強い。
一方で、「サイト全体の中でこのLPがどう位置づくべきか」「集客プロセス全体の中でこのページはどんなIN/OUTを持つべきか」といった全体最適の設計は、こちらが意識して伝えない限り、勝手にはやってくれません。
その結果、質問する側に収れんの方向性がないと、
- 各質問に対する回答は良さそうなのに
- 積み重ねると、全体の位置づけが微妙にズレる
という現象が起きます。
今回のLP作りでは、そこで役割をはっきり分けました。
- AIには「細部の案出しと具体化の担当」を任せる
- 共感コピーの言い回し
- セクションごとのテキスト
- SWELLでLP風に見せるCSS案
- 筆者である僕が「集客プロセスやLPのゴールを踏まえた全体の舵取り」を担当する
- このLPはどのステップのINを受けて、どんなOUTを渡すページなのか
- どの悩みを中心に据えるべきか
- どこまでがこのLPの仕事で、どこから先は別ページに任せるか
「AIは部分最適のプロ、筆者は全体最適の責任者」。
この関係を崩さないように、あえてAIに忖度させず、こちらの感覚にも忖度しすぎないようにしながら議論を続けました。
LP作りでAIを使うときに大事なのは、
AIに“全部決めてもらう”のではなく、自分がマクロビューを握ったまま、細部の案出しにAIを使うというスタイルだと、今回改めて感じています。
H2-2:問い合わせ地獄から始まるLPシナリオ
LPのストーリーを考えるとき、出発点はいつだって「現場の悩み」です。
問い合わせminiの場合、それはとても分かりやすいものでした。
小規模事業者や店舗の担当者に共通するのは、「問い合わせの量」そのものよりも、問い合わせの“中身”と“手間”に振り回されている感覚です。
- 毎日、大量のメールやメッセージが届く。
- その中には、営業メールや迷惑メール、詐欺まがいの案内、お知らせ、商品紹介など、対応不要なものも多い。
- 一方で、「本当にお客様からの問い合わせ」が、その中に紛れている。
- 担当者は、それらをふるい分けて、必要なものだけに丁寧に返信している。
ここから、「問い合わせ対応の何がどう大変なのか」を言語化していくことが、LPのシナリオ設計の第一歩になります。
H3-1:同じ問い合わせに何度も答える日々、という現場の声
小規模事業者の現場に耳を傾けると、こんな声が出てきます。
「うちに来る問い合わせって、8割以上が『商品価格』『仕様』『メニュー内容』『営業日』『営業時間』みたいな、決まりきった内容なんです。
それなのに、1日に何回も何回も同じことを聞かれて、そのたびにメールを書いたり電話で説明したりしていると、それだけであっという間に時間が溶けていきます。」
本当は、
- 新しいメニューを考えたい
- 常連さんへのフォローをしたい
- 売上につながる施策に時間を使いたい
のに、毎日の問い合わせ対応が「足かせ」になってしまう。
問い合わせが大事なのは誰もが分かっています。
でも、定番の答えは、担当者じゃなくてもいいはずです。
また、その悩みについての「業務上のインパクト」も添えておきます。
・どれくらいの時間を食っているのか。
・どんな仕事が犠牲になっているのか。
・ストレスや心理的負担がどれくらいか。
・チームや売上にどう響いているのか
初回のニーズは、たいてい「基本情報をサッと確認したい」だけ。
ならば、そこまでは仕組みで返してしまって、担当者は 「人が対応する価値がある問い合わせ」 に集中したほうが、お客様にとっても自分たちにとっても合理的です。
この「問い合わせ地獄」の声を、LPでは最初にちゃんと描きます。
なぜなら、ここで強い共感が生まれないと、その先の「解決策としての問い合わせmini」の話が入っていかないからです。
H3-2:読者が「まさにそれ」と感じる悩みだけを抽出し、優先順位をつける
次に、そのリストを眺めながら、「読者が心の中で『まさにそれ!』と即座に頷く悩み」を抽出していきます。
今回はターゲットとして、
- 小規模事業者
- 店舗やサロン、教室のオーナー・担当者
を想定していたので、「この人たちが読みながら深くうなずくシーン」をイメージしながら選びました。
例えば、次のような悩みはLPの中心に据えやすいと判断しました。
- 「定番の問い合わせに同じ回答を何十回も繰り返しているうちに、本業に使いたかった時間が消えていく。」
- 「営業メールや迷惑メールを仕分けるだけで疲れたあとに、ようやくちゃんとした問い合わせを見つけて返信している。」
- 「問い合わせが多いのはありがたいけれど、このままでは問い合わせ対応そのものが足かせになってしまう。」
このような「まさにそれ」という悩みをいくつか抜き出し、LPの中での優先順位を付けます。
- 一番上に置く、一発目の悩み。
- その次に続ける、補強用の悩み。
- 最後にサブとして添える、細部の悩み。
今回の問い合わせmini LPでは、
- 「定番の問い合わせへの同じ回答に、毎日何時間も取られている」という時間の悩み。
- 「そのせいで、本業が後ろ倒しになっている」という生産性の悩み。
- 「問い合わせは大事だが、定番の答えは仕組みで返したほうがいい」という構造的な違和感。
この3つを軸にして、悩みセクションを構成しました。
こうして、「問い合わせ対応の何がどう大変なのか」を構造化し、
読者が「まさにその通り」と感じるポイントだけをLPの中心に据えていくことが、問い合わせminiのようなDX系サービスのLPではとても重要だと感じています。
H2-3:SWELLで「このページだけ」をLPっぽく見せる技術シナリオ
LPのストーリーとコピーが固まってきたら、次にぶつかる壁は「テーマの仕様」です。
今回のサイトはWordPress+SWELL。
ブログや情報記事を量産するには最高のテーマですが、「この固定ページだけLPとして見せたい」と思った瞬間、少し工夫が必要になります。
H3-1:目次とサイドバーは消せるのに、グローバルメニューだけ残る問題
問い合わせminiのLPを作り始めたとき、まずやったのは「本文まわりの余計なものを消す」ことでした。
- 固定ページの設定で、目次の表示をオフにする。
- サイドバーを「表示しない」に切り替える。
これで、記事型レイアウトにつきものの「目次」「右サイドバー」は消せました。
LPらしい「縦に流れる1枚もの」に一歩近づきます。
しかし、ヘッダーのグローバルメニューだけは残ったまま。
- サイト全体のグローバルメニューをオフにすると、他のSEO記事まで全部影響してしまう。
- このLPだけ、ヘッダーメニューを消したい。
- ロゴやサイト名は残してもいいが、メニューから別ページに逃げてほしくない。
この「LPだけメニューを消したい」というニーズに対して、テーマの設定画面には素直なスイッチが見当たりませんでした。
ここから、AIとの技術的な相談が始まります。
H3-2:最初の試みは「スラッグ指定CSS」だった
最初に、AIから提案されたのは「ページのスラッグを使ったCSS」です。
問い合わせminiのLPのURLは、
あわせて読みたい 今日も問い合わせ対応で1日が終わってしまった! こまった、何とかしたいな。| アピスmini | 問い合... ① 価格、資料請求、営業時間など、毎回似た内容に返信している。② 気づいたら、メール確認と返信だけで午前中が終わっている。③ 制作、接客、提案、営業フローに使う...
このスラッグ apice-mini-inquiry-mini-lp-komatta から、
- WordPressが
<body>にpage-apice-mini-inquiry-mini-lp-komattaのようなクラスを付けている可能性 - SWELLのグローバルナビ部分には
.c-gnavというクラスが使われていること
を踏まえて、AIはこういうCSSを提案してきました。
css/* スラッグ由来クラスを前提にした案 */
.page-apice-mini-inquiry-mini-lp-komatta .c-gnav {
display: none !important;
}
これは、
- スラッグからページ固有のクラスを特定し
- そのページだけ
.c-gnav(グローバルメニュー)を非表示にする
という「スラッグベースの解決策」です。
さっそく、SWELLの「追加CSS」にこのコードを入れてみました。
……が、結果は メニューが残ったまま。
ここで分かったのは、
- テーマや環境によっては、スラッグ由来クラスが
<body>に付いていない - 付いていたとしても、想定どおりの名前とは限らない
ということです。
部分的には理にかなっていても、実際のHTMLを確認しないと当たらない。
そこで次に、「より確実な方法に切り替える」フェーズに進みました。
H2-4:HTMLソースをAIに丸投げしてpage-idを特定する
ここからは、「AIと一緒に具体的なコードまでたどり着いた」中盤のハイライトです。
H3-1:自分でPAGE IDを探すのは難しいから、AIにソースごと見せる
次にAIが持ち出してきたのは、WordPressの基本仕様です。
- WordPressは、各ページの
<body>に必ずpage-id-XXXXというクラスを付ける。 - ここでの
XXXXは固定ページのID。 - このIDさえ分かれば、css
.page-id-XXXX .c-gnav { display: none !important; }という形で、「このページだけグローバルメニューを消す」CSSが書ける。
問題は、「XXXX」をどうやって知るかです。
管理画面やソースを見なれている人ならすぐ分かりますが、普段HTMLを細かく読まない人にとってはハードルが高い。
ここで僕はこう考えました。
「PAGE IDを探すのが難しいなら、ID探しそのものをAIにやらせればいい。」
やったことはシンプルです。
- 問い合わせmini LPのページをブラウザで開く。
- 右クリックして「ページのソースを表示」。
- 出てきたHTMLソースの先頭から、ざっくり数ページ分をコピー。
- そのテキストをAIに渡して、「この中からPAGE IDを探して」と丸投げ。
自分から見れば「タグと英語の塊」でしかないソースですが、
AIは落ち着いて中身を読み始めました。
H3-2:AIがPAGE IDを見つけてくれた瞬間
AIがソースを解析した結果、次のような記述を見つけてくれました。
wp-json/wp/v2/pages/13499?p=13499
これがヒントです。
ここからAIは、
「このページの固定ページIDは 13499 ですね。」
と結論を出しました。
つまり、問い合わせmini LPは「page-id-13499」を持つ固定ページだということが分かったわけです。
この瞬間、「このページだけをCSSで狙い撃ちできる条件」が揃いました。
H3-3:決着版CSS──LPだけグローバルメニューを消す一行
PAGE IDが分かったところで、AIは即座に「決着版CSS」を提示してきました。
css/* 固定ページID 13499 のLPだけ、SWELLのグローバルメニューを非表示にする */
.page-id-13499 .c-gnav {
display: none !important;
}
ここで使っているのは2つだけです。
.page-id-13499
→ この固定ページだけに付く<body>のクラス.c-gnav
→ SWELLのグローバルナビのクラス
この組み合わせで、
「IDが13499のページ(=問い合わせmini LP)だけ、グローバルメニューを非表示にする」
という意図を、CSSでピンポイントに表現できます。
あとは、実行あるのみです。
H2-5:CSSを入れてみたら、本当にLPだけメニューが消えた
最後は、一番シンプルなステップです。
H3-1:SWELLの追加CSSに貼る→確認→成功
- WordPressの管理画面で「外観 → カスタマイズ → 追加CSS」を開く。
- AIが提案したCSSを、そのまま貼り付ける。
css.page-id-13499 .c-gnav {
display: none !important;
}
- 保存して、問い合わせmini LPのページを再表示する。
すると――
やりました。問い合わせminiのLPだけ、本当にグローバルメニューが消えました。
- 他のSEO記事や通常ページには
page-id-13499が付いていないので、グローバルメニューはそのまま残る。 - このLPページだけ、ヘッダーメニューが消えて「1枚もののLP」として見せられる。
目次とサイドバーはテーマ設定で消し、
グローバルメニューは「page-id+クラス指定」のCSSで消す。
ここまででできたのは、WordPressの記事ページを「LP風の見てくれ」に整えることでした。
ただし、本当に大事なのはここからです。LPとして読者を動かすには、構成、ヘッドコピー、悩みの提示、解決策の見せ方、CTAまでを順番に詰めていく必要があります。
H2-6:本格的なLPの中身検討――構成の型とヘッドの役割
ここまでで、WordPress+SWELLの記事ページを「LP風の見てくれ」に整えるところまでは終わりました。
目次もサイドバーもグローバルメニューも消えて、縦に流れる1枚ものとして見せられる土台はできています。
ただ、LPの成果を決めるのは見た目だけではありません。
むしろ重要なのは、この1枚の中で
- 誰のどんな悩みを
- どんな順番で揺らして
- どんな根拠と安心材料を挟み
- どこで「よし、試してみよう」と思ってもらうか
という中身の設計です。
H3-1:DXサービス向けLPは「問題提起→解決策→根拠→行動」で組む
問い合わせminiのような、DX・業務効率化系のサービスの場合、LP構成の軸はシンプルにこう考えました。
- 問題提起(現場の悩みを具体的に描く)
- 解決策の方向性(「定番の問い合わせは仕組みで返す」という考え方の提示)
- サービス紹介と根拠(問い合わせminiがどうそれを実現するか・なぜ信用できるか)
- 行動への橋渡し(まず無料で試してみる、という一歩目のCTA)
これは、多くのLPで使われている「問題提起→解決策→根拠→実績→行動」という鉄板型のバリエーションです。
問い合わせmini LPでは、これを次のようなブロック構成に落としました。
- ファーストビュー(ヘッド):
- 誰の、どんな問い合わせの悩みかを一発で刺すキャッチ+サブコピー
- 共感ゾーン:
- 同じ問い合わせに何度も答えている現場の声
- 本業が後ろ倒しになる業務インパクト
- 解決の方向性:
- 「定番の問い合わせは、担当者ではなく仕組みが返す」という考え方
- 問い合わせmini紹介:
- どんな仕組みか、何ができるか、無料でもどこまで回るか
- 安心材料・よくある質問:
- 導入のハードルや不安への回答
- CTA:
- 「まず無料で使ってみる」「今日から定番問い合わせだけでも自動化してみる」ためのボタンや導線
この構成を決める段階で、AIには「DXサービス向けLPの鉄板要素」を参考までに一覧で出してもらい、
僕の側で「問い合わせminiに合うものだけを選んで並べ替えていく」という役割分担にしました。
H3-2:ヘッド(入口)は“お悩みの一撃”で勝負する
この構成の中でも、もっとも時間をかけて検討したのがヘッド(ファーストビュー)です。
多くのLPの解説でも言われている通り、ファーストビューには少なくとも次の要素が必要です。
- ターゲットの心を掴むキャッチコピー
- キャッチを補足するサブコピー(もう一歩具体化する一文)
- サービスのイメージが伝わるビジュアル
- 「このページでできること」が分かる導入文 or CTA
問い合わせminiの場合、ヘッドの役割はこう定義しました。
「毎日同じ問い合わせに同じ返事を繰り返して、本業が進まない」という、
小規模事業者・店舗担当者の“今日の愚痴”を一撃で思い出させること。
そこでAIには、こんな投げ方をしました。
- ターゲット:小規模事業者・店舗・サロン・教室の問い合わせ担当者
- 主な悩み:定番の問い合わせに何度も答えて、本業が止まること
- トーン:少し砕けた愚痴っぽさ+解決の匂い
この条件で、AIにヘッドコピー案を10〜20本ほど出してもらい、その中から
- 現場感をちゃんと押さえているもの
- 読み手の「今日の気持ち」に近いもの
- 過度に煽りすぎていないもの
を僕が選んで、言葉を微調整していきました。
例として、
「同じ問い合わせに同じ返事を、今日も20回書いていませんか?」
「問い合わせ対応だけで午前中が消える日が増えていませんか?」
のような「まさにそれ」という一文を種にして、
サブコピーで少し説明を足し、CTAで「まず定番の問い合わせだけでも仕組み化してみませんか?」と行動の方向を示す形にしました。
ここでも、
- AIは「候補を大量に出す担当」
- 僕は「ターゲットの気持ちと集客プロセスを踏まえて、どれを採用するか決める担当」
という役割分担を守っています。
H2-6:本格的なLPの中身検討――構成の型とヘッドの役割
ここまでで、WordPress+SWELLの記事ページを「LP風の見てくれ」に整えるところまでは終わりました。
目次もサイドバーもグローバルメニューも消えて、縦に流れる1枚ものとして見せられる土台はできています。
ただ、LPの成果を決めるのは見た目だけではありません。
むしろ重要なのは、この1枚の中で
- 誰のどんな悩みを
- どんな順番で揺らして
- どんな根拠と安心材料を挟み
- どこで「よし、試してみよう」と思ってもらうか
という中身の設計です。
AIが書いたWF ファースト版

H3-1:DXサービス向けLPは「問題提起→解決策→根拠→行動」で組む
問い合わせminiのような、DX・業務効率化系のサービスの場合、LP構成の軸はシンプルにこう考えました。
- 問題提起(現場の悩みを具体的に描く)
- 解決策の方向性(「定番の問い合わせは仕組みで返す」という考え方の提示)
- サービス紹介と根拠(問い合わせminiがどうそれを実現するか、なぜ信用できるか)
- 行動への橋渡し(まず無料で試してみる、という一歩目のCTA)
これは、多くのLPで使われている「問題提起→解決策→根拠→行動」という鉄板型の考え方に近い流れです。
問い合わせmini LPでは、これを次のようなブロック構成に落としました。
- ファーストビュー(ヘッド)
- 誰の、どんな問い合わせの悩みかを一発で刺すキャッチ+セカンドキャッチ
- 共感ゾーン
- 同じ問い合わせに何度も答えている現場の声
- 本業が後ろ倒しになる業務インパクト
- 解決の方向性
- 「定番の問い合わせは、担当者ではなく仕組みが返す」という考え方
- 問い合わせmini紹介
- どんな仕組みか
- 何ができるか
- 無料でもどこまで回るか
- 安心材料・よくある質問
- 導入のハードルや不安への回答
- CTA
- 「まず無料で使ってみる」
- 「今日から定番問い合わせだけでも自動化してみる」ための導線
この構成を決める段階で、AIには「DXサービス向けLPの鉄板要素」を参考として整理してもらい、
筆者側では「問い合わせminiに合うものだけを選び、順番を決める」という役割を持ちました。
ここでも大事だったのは、AIに「全部決めてもらう」のではなく、
集客プロセスの中でこのLPが担う役割を先に押さえたうえで、必要な構成だけを採用することでした。
H3-2:ヘッドは“最初の悩み提示”で勝負が決まる
この構成の中でも、もっとも時間をかけて検討したのがヘッド(ファーストビュー)です。
一般的にLPのファーストビューでは、
- ターゲットの心を掴むキャッチコピー
- それを補足するサブコピーや導入文
- サービスのイメージを伝えるビジュアル
- 行動を促すCTA
が重要だとされています。hubspot+2
ただ、問い合わせminiのLPでは、何よりも先に必要だったのは、
「その悩み、今日もやってた」と読者に思わせる入口でした。
今回のターゲットは、
- 小規模事業者
- 店舗・サロン・教室の担当者
です。
そして、彼らの悩みは単に「問い合わせが多い」ことではありません。
- 定番の問い合わせに何度も同じ返事を書いている
- 気づけば午前中、あるいは一日が終わっている
- 本当はやりたかった本業が、また後回しになっている
という、“時間を奪われ、本業が迷子になる感覚”こそが本質でした。
だから、このLPのヘッドには、
「問い合わせ対応の何がつらいのか」を説明調で書くのではなく、
読者の頭の中にある今日の愚痴を、そのまま言葉にすることを求めました。
H3-3:最終的に採用したヘッドは、こうして決まった

今回のLPで最終的に採用したヘッドは、こういう言葉になりました。
同じ問い合わせ対応で、気が付けば夕方。
あれ、本業どこ行った? そんな毎日をそろそろ終わりにしませんか。
この一組にたどり着くまでには、AIとかなりのラリーをしました。
最初にAIに投げた条件は、次のようなものでした。
- ターゲット:小規模事業者・店舗・サロン・教室の問い合わせ担当者
- 状況:価格、営業時間、メニュー内容などの定番問い合わせへの返信だけで、一日があっという間に終わってしまう
- 感情:
- 「今日も本業に手をつけられなかった」という焦り
- 「問い合わせは大事なのに、生産性が悪すぎる」という違和感
- トーン:少し砕けた口語で、現場の愚痴をそのまま言う感じ
この条件で、AIにヘッド案を何本も出してもらいました。
その中には、
- 同じ問い合わせに何十回も答えていることを強調する案
- 午前中が問い合わせだけで終わることを切り取る案
- 営業メールや迷惑メールの仕分け疲れを前面に出す案
など、いろいろな方向性がありました。
ただ、最終的に残ったのは、
「気が付けば夕方」という時間感覚と、
「本業どこ行った?」という自嘲気味の一言でした。
このヘッドには、
- ふと時計を見たら夕方だった、という日常のリアル
- 本来やるべき仕事が進んでいないことへの焦り
- でも、どこか笑ってしまうような“現場の本音”
が、短い言葉でまとまっています。
AIが出してくれた案をそのまま採用したのではなく、
- 現場の愚痴として自然に言えるか
- 読者が「まさにそれ」と感じるか
- LPの入口として、その先の解決策につながるか
を人間側で何度も確認しながら、言葉を削り、入れ替え、整えていきました。
その結果として、このヘッドは単なるコピーではなく、
「問い合わせが多いこと自体はありがたい。
でも、そのせいで本業が消えていく毎日には、さすがに限界がある。」
という、問い合わせmini LP全体の問題意識を象徴する一文になりました。
ここでヘッドが決まったことで、
この後に続く
- 共感ゾーン
- 解決の方向性
- 問い合わせminiの紹介
- CTA
の流れも、一気に組み立てやすくなりました。
H2-7:ヘッドの次は、図解ブロックで「悩み→整理→導入しやすさ」へつないだ
ヘッドが決まったあとにやったのは、LP本文を文章だけで埋めることではありませんでした。
実際の問い合わせmini LPは、読者に長文を読ませるよりも、図解と短いフレーズで流れを理解させる構成に寄せています。
今回のLPを見返すと、ヘッドのあとに並んでいるのは、次のようなブロックです。
- PART02:「こんなお悩み、ありませんか?」
- PART03:「問題は、問い合わせが多いことではありません。全部を人手で抱えていることです。」
- PART04:「問い合わせminiで、対応を3つに整理」
- PART05:「問い合わせ対応のDX化が、経営効果を高める」
- PART06:「アピスminiの連携で、さらに強くなる」
- PART07:「小さく始められる、だから試しやすい」
- PART08:「無料DLから、少しずつ利用が広がっています」
- PART09:最終CTA「問い合わせ対応に奪われる時間を、本業と営業に戻しませんか?」
つまり、このLPは
悩みを見せる → 問題の本質を定義する → 解決方法を図で見せる → 効果を示す → 導入しやすさを下げる → 最後にCTAへ送る
という流れで組まれています。
ここで大事だったのは、AIにページ全文を一気に書かせるのではなく、ブロックごとに役割を定義し、その役割に合う図解・短文・見出しを一緒に詰めていったことでした。
H3-1:まずは「悩み」と「問題の本質」を、読者が一目で分かる形にする

ヘッドの次に来る PART02 と PART03 は、このLPの土台です。
ここでやっていることは、単に「困っていますよね」と共感することではなく、悩みを見える化し、その悩みの本質を定義し直すことです。
PART02 では、「こんなお悩み、ありませんか?」という見出しのもとに、読者の困りごとを6つ並べています。
- 同じ問い合わせに何度も返信している
- 問い合わせ対応だけで時間が消える
- 本業や営業が後回しになる
- 対応漏れが心配
- 顧客フォローまで手が回らない
- 少人数なので余計につらい
ここが重要なのは、悩みを抽象化せず、業務の中で起きている困りごとを「見えるカード」にしていることです。
しかもその下には、
- 価格や営業時間など毎回似た内容に返信している
- 気づいたら午前中が終わっている
- 制作・接客・提案・営業フローに使う時間が削られている
- 誰がどこまで対応したのかわかりにくい
- フォロー案内がその場限りで終わる
- 担当者が少ないほど負担が本業に響く
という説明が入り、最後に
「まじめに対応しているのに、仕事が前にすすまない。」
という一文で締めています。
この一文はとても大事でした。
「問い合わせを雑に扱っているから大変なのではない。むしろ、ちゃんと対応しているからこそ苦しい」というニュアンスが入ることで、読者は責められているのではなく、理解されていると感じやすくなります。
さらに PART03 では、その悩みの原因を
「問い合わせが多いこと」ではなく、「全部を人手で抱えていること」
だと再定義しています。
ここは、マーケティング的にも重要な転換点でした。
悩みに共感するだけで終わるのではなく、問題の本質を一段深く言い直すことで、次の解決策ブロックへ自然につなげられるからです。
実際のLPでも、
- 現状:すべて人手で対応
- あるべき姿:仕組みで解決
という対比図で、
「何が問題なのか」を読者に一目で分からせる構成になっていました。
長い説明文を書くことではなく、読者の悩みを図と短文で整理し、問題の本質をひとつに絞る作業だったのです。
H3-2:解決策・効果・導入しやすさを、1ブロック1メッセージで積み上げる
問題の本質を
「全部を人手で抱えていること」
だと定義したあとは、その解決策を段階的に見せていきました。
PART04 では、問い合わせmini の価値を
「対応を3つに整理すること」
として見せています。
- A:自動返信
- B:下書き確認
- C:要確認
このブロックの良かった点は、
「AIが何でも自動でやってくれます」という雑な見せ方ではなく、
問い合わせを3分類し、人が見るべき仕事に集中するという現実的な整理として表現できたことです。
そして PART05 では、その整理がどんな効果につながるかを示しています。
- 定型作業を削減
- 対応漏れを防止
- 営業機会を逃さない
- 本業・顧客フォローに時間を戻す
ここでも、単に「便利になります」ではなく、
問い合わせ整理 → 業務効率アップ → 営業強化 → 顧客対応強化 → 経営効率UP
という流れにしている点が、このLPの特徴でした。
さらに PART06 では、問い合わせmini 単体ではなく、
STEPmini や LINEコマンドBOTmini との連携まで見せています。
これは、「単体ツールの紹介」で終わらず、小さく始めて、少しずつ広げられる世界観を見せる役割を持っていました。
そのうえで PART07・PART08 では、
読者が最も気にする「で、結局うちでも使えるの?」という不安に答えています。
実際のLPでは、
- 無料DLで試せる
- 既存サイトに組み込みやすい
- 小規模事業者でも運用しやすい
- 少ない工数で効果を実感
といった導入ハードルの低さを並べ、
さらに「無料DL」「導入相談」「利用者の声」「業種別活用」といった広がりの見せ方で、安心感を補強していました。
最後の PART09 では、
問い合わせ対応に奪われる時間を、本業と営業に戻しませんか?J
と、再び読者の目的に立ち返ったうえで、
- 無料DLはこちら
- 導入相談はこちら
という2つのCTAに着地しています。
この流れを振り返ると、AIと一緒にやっていたのは「本文を書くこと」よりも、むしろ
1ブロック1メッセージで、読者の理解と行動のハードルを順番に下げていく設計でした。
- 悩みを見せる
- 問題の本質を定義する
- 解決策を3つに整理して見せる
- 効果を経営視点まで引き上げる
- 導入しやすさと小さく始められる安心感を出す
- 最後に無料DLと相談へ送る
この順番があるからこそ、ヘッドの一撃が、単なる共感で終わらず、実際の行動へつながるLPになっていくのだと思います。
H2-8:デザインと画像もAIでたたき台を作り、図解型LPとして仕上げた
LPの内容が固まってきたところで、次に必要になったのは「どう見せるか」でした。
ただ、今回の問い合わせmini LPで目指したのは、広告っぽく煽る派手なLPではありません。
実際のPDFを見返すと、このLPのデザインは全体を通して
- 白ベースで余白を広く取る
- 緑を主軸カラーにする
- 1ブロック1メッセージで図解的に見せる
- イラストやアイコンで理解を助ける
- CTAは目立たせるが、全体のトーンは落ち着かせる
という方向で統一されています。
つまり、今回AIと一緒にやったのは、
「かっこいいデザインを出して」と一発で頼むことではなく、
問い合わせ対応DXというテーマに合う“図解型の見せ方”を、ワイヤーフレームから順番に固めていく作業でした。
H3-1:まずAIにワイヤーフレームを出させて、ブロックの見せ方を決めた
本文の構成が決まった段階で、まずAIに依頼したのは、完成デザインそのものではなくワイヤーフレームのたたき台です。
ここでAIに渡したのは、
- ターゲットは小規模事業者
- テーマは問い合わせ対応DX
- 悩みは「同じ問い合わせ対応で気が付けば夕方」
- LP全体は、悩み → 問題の本質 → 解決策 → 効果 → 導入しやすさ → CTA の順で見せたい
という情報でした。
するとAIは、
「どこに見出しを置くか」「どのブロックをカードにするか」「どこを比較図にするか」「どこをCTAとして太く見せるか」といった、構造の骨格を先に返してきます。
今回のLPでも、その流れがはっきり出ています。
- ヘッドは左にコピー、右に悩んでいる人物イラスト
- PART02 は6つの悩みカード
- PART03 は「現状」と「あるべき姿」の対比図
- PART04 は「3つに整理」の分類図
- PART05 は経営効果を4項目で見せるカード+流れ図
- PART06 はサービス連携を横並びで見せる
- PART07 は「試しやすさ」を4つの条件で見せる
- PART08 は利用の広がりを段階で見せる
- PART09 はCTAを大きく2ボタンで着地させる
この順番は、文章だけで読ませるというより、図を見ながら理解が前に進む設計です。
そしてここが、AIを使ってよかったポイントでもありました。
人間一人で考えると、どうしても文章で説明しがちですが、AIにワイヤーフレームを出させると、「ここは図にしたほうが早い」「ここは比較で見せたほうが伝わる」といった、見せ方の発想が出やすくなります。
ただし、ここでもAI案をそのまま採用したわけではありません。
筆者側では、
- そのブロックは“読ませる”のか、“見せる”のか
- 図解にするなら、情報は3つまでか、4つまでか
- ここで読者を止めたいのか、流したいのか
を確認しながら、各パートの形を絞っていきました。
つまり、AIはワイヤーフレームの初稿を出す担当、
人間は「その形が本当に読者理解につながるか」を判断する担当だったわけです。
H3-2:配色、イラスト、CTAまで“世界観を揃える”調整を繰り返した
ワイヤーフレームが決まったあと、次に大事だったのが世界観の統一です。
問い合わせmini LPは、全体としてかなり一貫した見た目になっています。
たとえば配色を見ると、
- 緑を主軸カラーにして、DX・改善・前進の印象を持たせる
- 青は整理や確認のニュアンス
- オレンジは注意喚起や相談導線
- 背景は白ベースで、情報の読みやすさを優先する
という使い分けがされています。
さらにビジュアル表現も、
- ヘッドでは「問い合わせに追われて困っている人物」
- 各パートでは、時計、メール、人物、グラフ、チェック、吹き出しなどのシンプルなアイコン
- 最後のCTAでは、「困っている状態」から「整理されて前向きになる状態」への変化を感じさせる人物イラスト
というふうに、複雑なアートではなく、理解を助ける図解イラストに寄せています。
ここでもAIとのやり取りはかなり大きかったです。
特にありがたかったのは、単発で“いい感じの画像”を出すことではなく、同じ世界観のまま画像や図解を調整していけることでした。
以前の画像生成では、
- 1枚ごとに絵柄がブレる
- 同じトーンで再生成しにくい
- そのため、LP全体で統一感を保ちながらデザイン議論を進めにくい
という問題がありました。
でも今回は、
「線画ベース」「シンプル」「ビジネス寄り」「親しみやすい」「緑を主軸」
といった条件を持たせながら調整していくことで、LP全体のトーンを揃えやすくなりました。
これは本当に大きかったです。
なぜなら、デザインは一枚絵の出来不出来ではなく、ページ全体で違和感なく流れることが大事だからです。
実際のLPでも、
- ヘッドの人物イラスト
- 各PARTのアイコンカード
- CTA付近の人物イラスト
- プロフィール周りの見せ方
まで、完全に同一ではなくても、
「同じサービスのページだ」と感じられるトーンでまとまっています。
そして最後に、CTAの見せ方もAIとかなり詰めました。
このLPでは、最後に
- 緑の「無料DLはこちら」
- オレンジの「導入相談はこちら」
という2本立ての導線を置いています。
これは、いきなり重い決断を迫るのではなく、
- まず自分で試したい人
- 相談しながら進めたい人
の両方を受け止める設計です。
つまり、デザインの話であっても、結局は見た目の好みではなく、
読者が迷わず次の一歩を選べるようにする設計に戻ってくるのだと思います。
今回、AIと一緒にデザインを詰めて感じたのは、
AIは「たたき台を大量に出す」「世界観を揃えた候補を返す」ことには非常に強い一方で、
最終的に
- この色は本当にこの導線に合っているか
- このイラストは悩みを強めているか、弱めているか
- このブロックは説明過多か、ちょうどいいか
を決めるのは、人間側の役割だということでした。
だから今回のLPデザインも、
AIに任せて完成したのではなく、
AIにたたき台を出させ、人間が意味の通る見せ方に収れんさせていった結果だと言えます。
H2-9:このLPを1日で作れたことが、AI時代の制作現場の変化を物語っている
ここまで見てきた問い合わせminiのLPは、
構成を考え、ヘッドを詰め、各ブロックを設計し、図解型のデザインまで含めて、実質1日で作り上げたものです。
これは、今回の制作を通じていちばん強く感じたポイントでした。
なぜなら、少し前までなら、この規模感のLPは「今日思いついて、今日形にする」という進め方がかなり難しかったからです。
今回のLPは、ただテキストを縦に流した簡易ページではありません。
実際には、
- ヘッドコピーの検討
- 問題提起からCTAまでの構成設計
- 各PARTごとの図解整理
- 配色の統一
- イラストやカードUIの方向づけ
- CTAボタンの見せ方
- WordPress上での掲載前提を踏まえた実装・調整
まで含んだ、かなり“完成に近い”LPです。
それでも、これを1日で形にできた。
この事実そのものが、AI時代のLP制作の変化をよく表していると思います。
H3-1:通常なら、この規模のLPは数日〜1週間超の仕事になる
一般的に、LP制作の期間は、関係者の確認や修正も含めると2週間〜1か月程度で語られることが多く、工程別に見ると、構成案・ワイヤーフレームで数日から1〜2週間、デザインで4〜7日、コーディングで3〜7日程度という整理がよく見られます。
もちろん、これは制作会社の標準フローや確認工程を含んだ話なので、そのまま個人制作に当てはめることはできません。
ただ、今回のように
- 構想と訴求設計があり
- 見出しや本文の設計があり
- 図解ブロックが複数あり
- ある程度デザインされた状態まで持っていき
- 実装まで含めて公開可能な形にする
という条件で考えると、Webに慣れた個人が自走したとしても、通常は5日〜7日程度、デザイナーとコーダーを分けて進めれば1週間超〜10営業日前後を見込んでも不自然ではありません。
実際、公開情報でも、
- デザイン工程だけで4〜7日程度
- コーディングで3〜7日程度
- デザインから依頼する場合は2〜4週間rockvil+1
- ヒアリングから公開まで1か月前後
といった目安が示されています。
だからこそ、今回のように
構想・WF・コピー・図解・デザイン・実装まで含むLPが1日で見える形になるというのは、やはり従来の感覚ではかなり速いです。
感覚的には、Web制作に携わっている人の実感として
「これ、普通にやったら1週間はかかるよね」
という認識はかなり自然だと思います。
そして、制作体制や確認工程まで含めて少し保守的に見積もるなら、マーケティング目線では標準的には7〜10営業日級の仕事と捉えても大きくは外していないはずです。
H3-2:AIで消えるのは“仕事”ではなく、“従来のやり方に依存した仕事”かもしれない
今回のLPを1日で作れた理由は、もちろん人間側に前提知識があったからでもあります。
ターゲット理解、サービス理解、WordPressでの実装感覚、そして「何を言うべきか」の判断がゼロだったわけではありません。
ただ、それを差し引いても、AIが制作スピードを押し上げたインパクトは非常に大きいです。
構成案、コピー案、ワイヤーフレーム、図解の切り口、配色や見せ方の方向性まで、叩き台を一気に出して比較・修正できる状態になったからこそ、この速度が出ました。
ここで感じるのは、
世の中のデザイナーやコーダーにとって、本当に問われる時代が来ているということです。
以前であれば、
- 構成を考える
- ラフを作る
- デザインを起こす
- コーディングする
- 微調整する
という一連の作業そのものが、価値の大きな部分を占めていました。
でも今は、その「初稿を作る作業」のかなりの部分をAIが肩代わりできるようになっています。
だから今後は、
単純に「デザインができます」「コーディングができます」だけでは厳しくなる場面が増えるはずです。
必要なのは、
- AIを使って初速を上げること
- AIが出した案のズレを見抜くこと
- 構成、訴求、導線の意味まで含めて整えられること
- 短時間で複数案を比較し、成果につながる方向へ寄せられること
です。
言い方を少し強くすれば、
AIで仕事がなくなるのではなく、AIを前提に仕事のやり方を更新できない人から、仕事が減っていくのだと思います。tegy.co+1
特にWeb制作の現場では、その変化がかなり早く出ています。
デザイナーが丁寧に1週間かけて形にしていたようなLPの初稿が、いまや1日でかなりのところまで到達できる。
この現実を前にすると、AIを脅威として眺めるだけでは足りません。
むしろ必要なのは、
- AIにどこを任せるか
- 自分はどこで価値を出すか
- その役割分担をどう仕事の流れに組み込むか
を、実務レベルで決めていくことです。
今回の問い合わせmini LPは、
まさにその変化を体感する制作になりました。
ある程度のデザインまで含んだLPが、1日でここまで作れる時代になった。
だからこそ制作側は、作る手数の多さではなく、判断の質と改善の速さで勝負する側へ移っていかなければならないのだと思います。
H3-3:画像中心LPとAI活用についての今回の気づきとこれから
今回の問い合わせmini LPでは、初めて「画像+ワイヤーフレームをベースに、間をテキストでつないでいく」という作り方に挑戦しました。
本来であれば画像内のテキストはHTMLで載せるべきですが、まずは画像を中心にLPを組み、そのぶん各画像のALT属性を丁寧に書くことで、SEOとアクセシビリティを少しでも補う形を取りました。
マーケティングの視点から見ると、この方針は理にかなっています。
LP自体は、SEO記事・広告・SNSなどから誘導された後の「着地ページ」であり、自然検索からの新規流入を主戦場にしているわけではありません。
LPの役割は、集客ではなく「すでに来てくれた人をどれだけコンバージョンに近づけるか」にあります。
その意味で、今回のような画像中心の図解型LPでも、訴求と導線がきちんと設計されていれば、マーケ的な目的は十分果たせます。
一方で、反省点と今後の方向性もはっきりしました。
次のステップとしては、画像をただ貼るのではなく、「画像は背景やイラスト」「テキストはHTML+CSSで画像の上に載せる」構成に少しずつ移行していくことで、読みやすさとSEO面の両方を高めていきたいところです。
その際には、AIに対して「この図解をHTML+CSSで組んで」「スマホでは縦並びにして」など、より具体的なコーディング指示を出せるようになることが鍵になります。
もうひとつ大きかったのは、制作スピードの変化です。
構成・コピー・図解・デザイン・実装まで含んだ今回のLPが、実質1日で形になったことは、従来の感覚では1週間以上かかっていたような仕事が、AIの助けを借りることで短時間で進むようになってきたことを示しています。
これは、Webデザイナーやコーダーにとって「仕事がなくなる」という脅しではなく、「AIを前提に、自分の役割をどう再定義するか」を迫る変化だと言えます。
今後は、
AIに構成・コピー・ワイヤーフレームの“たたき台”を作ってもらい、人間がズレを消しながら意味の通るLPへ収れんさせる。
画像中心LPでもALTやテキストで最低限の情報を補いつつ、徐々に「画像+HTMLテキスト」の構成へ移行していく。
その両輪で、問い合わせminiのLPも、自分自身のWeb制作のスタイルもアップデートしていければと思っています。






コメント