コラム / マーケティングエンジニアの教科書

第4章 クリエイティブ作成を自動化する

広告コピー、オファー、バナー、動画、LP など、クリエイティブの作成をAI で自動化する方法。型の使い分けから、生成の手順、検品の基準、生成物の来歴の残し方までを解説します。

この章で学ぶこと

  • クリエイティブを「訴求軸 × 型 × 媒体」の組み合わせに分けて量産し、成果の出た組み合わせだけを残す方法
  • コピー・バナー・動画・LP のそれぞれで、AI に「型」と「設計書」を渡す方法
  • 画像・動画の生成 AI の使い分けと、生成したものに「何をどのモデルに頼んだか」を残す方法
  • LP の作り方と、計測の仕組みを正しく入れる方法
  • 配信や投稿の前に起きやすい失敗(誤字、架空の数字、ダミーの計測タグ)の防ぎ方

4.1 クリエイティブ制作の全体像

「1 本ずつ企画する」をやめる

クリエイティブとは、広告や投稿で実際に見せる画像・動画・文言のことです。多くの現場では、クリエイティブをいまも 1 本ずつ企画し、1 本ずつ作っています。しかし、月に 3 本しか作れなければ、成果の出るクリエイティブが見つかるかどうかは運に左右されてしまいます。「今月も新しいバナーは 3 本だけで、どれも成果が出なかった」という状況で足りないのは、1 本ごとの品質ではなく、試した本数です。

いまは、誰に配信するか(ターゲティング)やいくらで入札するかを、広告媒体の機械学習が自動で決めるようになりました。そのため、人が広告の成果を左右できるのは、主に「何を見せるか」の部分になっています。

クリエイティブ作成を自動化する目的は、この試す本数を増やすことです。クリエイティブを「訴求軸」「型」「媒体」などの組み合わせに分け、組み合わせを変えながら量産します。それらを同じ期間・同じ予算で配信し、成果の出た組み合わせだけを残します。人が担当するのは、どのベネフィットを訴求軸にするか、どの組み合わせに予算を寄せるか、という判断です。型に当てはめる、画像にする、検品する、といった作業は AI に任せることができます。

変数中身決め方
訴求軸誰に、どのベネフィット(手に入る未来)を見せるか人が決める。第三章の分析の結果
型コピーの型、バナー構成の型、動画の冒頭フックの型カタログから機械的に組み合わせる
媒体・面・サイズフィード、リール、ディスプレイの 300×250 など媒体の仕様に従う
版勝ち案から 1 変数だけ変えた派生何を変えたかを必ず記録する

型が決まっていれば、「この訴求軸を、この型に当てはめて」と AI に頼むだけで量産できます。型が決まっていないと、企画のやり方が担当者ごとに変わり、量産しても何と何を比べているのかが分からなくなってしまいます。そのため、量産を始める前に、型の一覧(カタログ)を用意しておきましょう。この章では、コピー・バナー・動画のそれぞれで型の一覧を紹介します。

メタデータ設計と命名規約

「どのクリエイティブで成果が出たか」を後から集計するためには、1 本ごとに、訴求軸や型の組み合わせを記録しておく必要があります。このように、データそのものではなく「そのデータが何なのか」を説明する情報を、メタデータと呼びます。

ファイル名は、人が読みやすいようにではなく、プログラムで分解しやすいように決めます。ただし、ファイル名に入れるのは最小限の項目だけにして、残りはメタデータとして別のファイルに持つようにしましょう。すべての項目をファイル名に入れてしまうと、項目を 1 つ増やしたときに、過去のファイル名と形が揃わなくなってしまいます。

# ファイル名: {訴求軸}_{コピー型}_{構成型}_{媒体}_{サイズ}_{版}
yoyaku3d_real_catch_meta_1080x1080_v02.png
json
{
  "id": "cr_0193",
  "file": "yoyaku3d_real_catch_meta_1080x1080_v02.png",
  "appeal": "yoyaku3d",
  "copy_type": "real_image",
  "layout_type": "catchcopy",
  "placement": "meta_feed",
  "size": "1080x1080",
  "variant_of": "cr_0187",
  "changed": ["copy"]
}

特に大切なのは、最後の 2 項目の variant_of(どのクリエイティブから作ったか)と changed(何を変えたか)です。この 2 つが残っていれば、成果の出たクリエイティブを見て「効いたのはコピーの変更だ」と判断することができます。記録が無いと、成果が出ても何が効いたのかが分からず、次の企画に活かすことができません。

制作パイプライン

この章で扱う制作の流れは、以下の図のようになります。

本文の関係を表した図(元の mermaid は図の下で開けます)

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る
mermaid
flowchart LR
  AX["訴求軸<br>第三章の分析から人が決める"] --> OF["オファー設計<br>特典・保証・価格の見せ方"]
  OF --> CP["コピー<br>訴求軸 × 型"]
  CP --> BN["静止画バナー<br>構成の型 → 画像生成"]
  CP --> SC["動画台本<br>フック × 本編 × CTA"]
  SC --> SB["編集依頼書(絵コンテ)"]
  SB --> ED["編集<br>ffmpeg / HTML レンダリング / 編集アプリ"]
  CP --> LP["LP<br>設計 → 実装 → 画像 → 計測タグ → 検証"]
  BN --> LIB["素材ライブラリ<br>由来(生成 / 持ち込み)付き"]
  ED --> LIB
  LIB --> OUT["入稿(第五章)/ 投稿(第七章)<br>確認画面を通る(パーミッション)"]
  LP --> PUB["本番公開は人が行う"]

量産と検証はセットで行う。初回は 5 本、次からは 1 か所ずつ変える

初回から 50 本を配信すると、1 本あたりの表示回数が足りず、どれが良かったのか分からないまま予算がなくなってしまいます。初回は 5 本程度に抑えましょう。成果の出た案から新しい案を作るときも、変えるのは 1 回に 1 か所だけにします。「全体をこう変えたら良くなるはず」という感覚で全体を作り直すと、成果が出ても出なくても、何が原因だったのかが分かりません。

4.2 コピーの設計

コピーとは何か

広告の「コピー」は、広告に載せる文言のことです。画像や動画が「何が見えるか」を受け持つのに対して、コピーは「見た人に何を思わせ、次に何をしてもらうか」を言葉で受け持ちます。

1 本の広告の中でも、コピーは置かれる場所によって役割が分かれます。

種類置かれる場所役割
キャッチコピーバナーの一番大きい文字、動画の冒頭のテロップ、検索広告の見出し最初に目に入る 1 行。「自分に関係がある」と思わせて、スクロールの手を止めてもらう
ボディコピーMeta 広告のメインテキスト、検索広告の説明文、バナーの小さい文字キャッチを読んで興味を持った人に、根拠や条件を補う
あとひと押し期限・在庫・特典の一言クリックする前の迷いを減らす(この節の「あとひと押しと、その法規」)
CTAボタンの文言(「予約する」「詳しく見る」など)次にしてもらう行動を 1 つに決める

コピーは、説明文とは書き方が違います。説明文は読むつもりのある人に正確に伝えるための文章ですが、広告は読むつもりの無い人の画面に、スクロールの途中で数秒だけ表示されます。そのため、1 本のコピーで伝えるのは 1 人の相手に 1 つのベネフィットだけにして、商品の全体は LP で伝えます。バナーのコピーを 20 文字以内に収めるのもこのためです。

この節で主に扱うのはキャッチコピーです。ボディコピー・バナーの構成・動画の冒頭・LP のファーストビューは、どれもキャッチコピーの 1 行を受けて作ります(4.1 節の制作パイプラインの図)。先にキャッチコピーを決めておけば、それぞれで別のことを言ってしまうのを防げます。

訴求軸を考える

コピーの文章を磨くより先に、「誰に、どのベネフィットを伝えるか」を決めましょう。これを訴求軸と呼びます。訴求軸がずれていると、どんなに良い文章でも反応は得られません。訴求軸は、次の 4 つの順番で考えます。

本文の関係を表した図(元の mermaid は図の下で開けます)

図を原寸で開く

図の元になった mermaid を見る
mermaid
flowchart LR
  P["① ペルソナ<br>1 人まで具体化する(第三章)"] --> B["② ベネフィット<br>10 個書き出す"]
  B --> A["③ 訴求軸<br>3〜5 本に絞る(人が選ぶ)"]
  A --> T["④ 型<br>下の表の型に流し込む"]

ベネフィットとは、商品を使うことで顧客が得られる結果のことで、商品の仕様(スペック)を言い換えたものではありません。例えば、ベビーカーの「軽い」はスペックで、「子どもを抱いたまま片手でたためる」がベネフィットです。

訴求軸は、「誰の、どんな迷いを、どのベネフィットで解消するか」を 1 文にしたものです。顧客が買う理由が同じなら、同じ軸とみなします。例えば、温泉旅館の「癒やし」と「くつろぎ」は同じ軸ですが、「平日なら客室の露天風呂を二人だけで使える」と「土曜より 1 人 6,000 円安い」は別の軸です。

訴求軸が決まったら、コピーの型に当てはめます。以下の表の上から 6 つが最初に試す基本の型で、その下がほかに使える型です(括弧内は一覧での呼び名です。例は旅行・ホテル予約のサービスです)。

型基本形例狙う層作り方の要点
使ったあとを見せる(ベネフィット直球型)「〇〇ができる」ホテル探しが、もっと楽しく。すでに探している人具体的な数字で購入後を想像させる。大きい価格は 1 回あたりに分解。王道なので、まずここから
相手を名指しする(ターゲット指名型)「〇〇な人へ」週末旅行をもっと楽しみたい人へ。まだ探していない人属性+悩み+「〜な方へ」で自分ごと化。単体では弱いので他の型と併用
気づいていない問題を指摘する(悩み共感型)「〇〇で困っていませんか?」旅行先、いつも同じになっていませんか?まだ探していない人現状への疑問形、原因の断定。反応は跳ねるが不快にもなる。指摘のあとに必ず解決策
身近なものと比べる(比較型)「AよりB」写真だけより、動画でわかる。両方「誰も傷つかない比較対象」を候補 5 つから選ぶ。競合と直接比較しない
体験談として書く(体験談型)「私は〇〇でした」動画を見て、次の旅行先が決まりました。広告を嫌う人使ったあとの感想を記事の見出し風に。主観語を並べると薄くなる
使う前の気持ちを代弁する(感情喚起型)「〇〇したくなる」思わず出かけたくなる景色に出会う。広告を嫌う人「今年こそ」「絶対に失敗したくない」。後ろ向きな方向は言葉選びを慎重に
悩み→解決型「〇〇の悩みを、△△で解決」行き先に迷ったら、動画から探そう。まだ探していない人悩みは 1 つに絞り、解決は商品の具体的な働きで言う。悩みを言うだけで終えると「問題を指摘する」型と同じになるので、解決まで 1 文に入れる
Before→After型「これまで〇〇。これから△△。」写真で迷う旅選びから、動画で決まる旅選びへ。両方前と後を同じ基準(時間・手間・気分)で並べる。前を悪く描きすぎると、いまのやり方の人を否定することになる
意外性型「〇〇なのに△△」見ているだけで、次の旅が決まる。広告を嫌う人説明を読まれる前に「おや」と思わせる。一番誇張に寄りやすいので、ギャップの根拠は与件の事実から選ぶ。毎回 1 案は入れる(下のギャップ案)
常識転換型「〇〇する時代は終わり」ホテルを条件だけで探す時代から、雰囲気で選ぶ時代へ。まだ探していない人否定される「古いやり方」は読み手自身のやり方なので、切り捨てずに「選び方が増えた」と言う。言い切るほど反発も増える
数字・実績型「〇〇人が選んだ」利用者の声から生まれた、新しい予約体験。比較検討している人数字は単位と期間まで書く(「〇人」ではなく「2025 年の予約〇件」)。裏付けがある場合だけ。無ければ例のように数字を出さずに言う
限定・緊急型「今だけ〇〇」今週末まで、対象プランがお得。すでに探していて、先延ばししている人期限と対象を同じ面に書く。実態の無い限定は信頼を失い、有利誤認にもなりうる
オファー型「〇〇円/〇〇%OFF/無料」初回予約で1,000円OFF。すでに探している人条件(誰が・いつまで・何回まで・何と併用不可)を割引額と同じ面に読める大きさで書く。割引条件は裏付けがある場合だけ。オファー設計の法規チェックが「要確認」のうちは使わない
質問型「〇〇したくない?」次の週末、どこへ行く?まだ探していない人一瞬で答えが浮かぶ問いにする。考え込ませる問いは、答える前に流される
命令・行動促進型「まず〇〇してみよう」気になる旅を、保存しよう。すでに探している人頼む行動は 1 つだけ、小さく(「予約しよう」より「保存しよう」)。命令口調は押しつけに聞こえるので、ベネフィットと組む
シーン提案型「〇〇するなら」記念日のホテル探しに。両方使う場面を 1 つ名指しして自分ごと化させる(「相手を名指しする」の場面版)。場面を並べると誰にも反応されない
権威・推薦型「専門家/利用者が選ぶ」旅好きが選んだ宿をチェック。決め手が無く迷っている人誰が選んだのかを具体的に書く。受賞・推薦は出典を示せるものだけ。利用者の声は裏付けがある場合だけ
リスク回避型「〇〇を防ぐ」写真とのギャップを減らすホテル選び。すでに探している人避けたい失敗を具体的に書く(写真と違った、など)。「必ず防げる」は効果の保証になるので書かない。不安をあおりすぎない
手軽さ型「たった〇分で〇〇」スキマ時間に、次の旅を見つけよう。まだ探していない人手間を時間や手順の数で示す。数字は実測できるものだけで、無ければ例のように「スキマ時間」などで言い換える
好奇心型「なぜ〇〇?」なぜ、このホテルが人気なのか?広告を嫌う人答えはバナーで出さず LP で出す。LP に答えが無いと釣り広告になり、すぐ離脱される

「体験談として書く」と「使う前の気持ちを代弁する」は、使った後の感想なのか、使う前の気持ちなのかで分けています。また、数字・実績・利用者の声・割引は、実際に裏付けがある場合にだけ使いましょう。

AI にコピーを出させるときは、「訴求軸 × 型」の表の形で出力させ、どの訴求軸とどの型の組み合わせなのかを必ず書かせます。第三章で説明したとおり、A/B テストでは 1 つの案で変えるのは 1 か所だけです。そのため、初回は型を揃えて訴求軸だけを変え、成果の出る訴求軸が決まってから、型を 1 つずつ変えていきましょう。

実際に AI にコピーを考えてもらう

温泉旅館の広告コピーを10案ください。

この依頼だけでは、多くの場合、以下のような結果が返ってきます。

  • 「癒やし」「絶景」「おもてなし」のように、どの宿にも当てはまる言葉が並ぶ
  • 同じ型の言い換えが 10 案続く
  • 「創業 100 年」「満足度 98%」のような、事実ではない数字が作られる
  • バナーに載らない長さの案が混ざる

そのため、ペルソナ・訴求軸・使ってよい事実・使ってはいけない表現・文字数・出力の形まで書いて、以下のようなプロンプトを AI に渡しましょう。

次の与件で、Meta 広告(フィード)の静止画バナーに載せるキャッチコピー案を作ってください。

【商材】山あいの温泉旅館。平日限定の「露天風呂付き客室 1 泊 2 食」プラン
【ペルソナ】都内在住・30 代前半の共働き夫婦。有給を取れば平日に休める。
  週末の混雑と、大浴場で他の客と一緒になるのが苦手
【訴求軸(今回はこの 1 本だけ)】平日なら、人の少ない宿で客室の露天を二人だけで使える
【使ってよい事実】
- 客室露天は全 8 室にある
- 平日料金は土曜より 1 人あたり 6,000 円安い
- 最寄り駅から送迎がある(前日までに要予約)
- これ以外の数字・実績・受賞歴は書かない

【手順】
1. この訴求軸に沿ったベネフィットを 5 個書き出す(スペックの言い換えは不可。軸から外れるものは出さない)
2. 上位 3 つを選び、基本の型(使ったあとを見せる/名指しする/問題を指摘する/
   身近なものと比べる/体験談/使う前の気持ち)に流し込む
3. 各案に「あとひと押し」の一言を 1 つ添える。期限・在庫は与件にあるものだけを使う

【制約】
- キャッチは 20 文字以内(句読点を含む)。超えた案は出さずに削る
- 「最安」「No.1」「日本一」「必ず」「絶対」は使わない
- 他の宿の名前や地名を出して比較しない

【出力】
表で出す。列は「型/使ったベネフィット/キャッチ/文字数/あとひと押し/根拠にした事実」。
最後に、与件だけでは判断できなかった点を箇条書きで添える

このプロンプトで特に大切なのは、「使ってよい事実」を並べて、それ以外の数字は書かないように指示している部分です。この指示が無いと、AI が作った数字が混ざり、検品のときにそれを 1 つずつ探さなければならなくなります。また、文字数と根拠にした事実を表の列として出させているのは、検品を「表を上から確認するだけ」の作業にするためです。ただし、AI は文字数を数え間違えることがあるので、最終確認は人かプログラムで行いましょう。

案件が変わるたびに同じ指示を書くのは手間なので、案件によらず同じ部分は Skill にしておきます。ペルソナや使ってよい事実のように案件ごとに変わる部分はプロンプトに書き、型や守るべきルールのように変わらない部分は Skill に書く、という分け方です。

もっと詳しく: 実際に著者が利用している広告コピーの Skill を簡略化して添付したので参考にしてください

この Skill はコピーの文言だけを担当し、バナーのレイアウトや動画の台本、特典の中身は扱いません。まとめてしまうと、「バナーの文言を考えて」と頼んだだけで、AI がレイアウトまで作り始めてしまうからです。また、与件に訴求軸が書かれていないときは、候補を出したところで止めて、人に選んでもらうようにしています。どの訴求軸で行くかは、人が決めることだからです。

markdown
---
name: ad-copy
description: >-
  広告のキャッチコピーを型で量産する。「コピーを考えて」「訴求案を何案か」
  「バナーの文言」で使う。
  ※バナーのレイアウトはバナー設計のスキル、動画の台本はリール台本のスキル、
  LP 本文は LP 生成のスキル、特典や保証の中身はオファー設計のスキル。
---
# 広告コピー

## 手順
1. ペルソナを 1 人に確定する(決まらなければ先に聞く)
2. その 1 人にとってのうれしさを 10 個書き出す(機能ではなく、手に入る結果)
3. うれしさを束ねて訴求軸の候補を 3〜5 本にする。与件に訴求軸が無ければ、候補を出したところで止まり、どれで行くかを聞く
4. 訴求軸を基本の型に当てはめる:使ったあとを見せる・相手を名指しする・問題を指摘する・身近なものと比べる・体験談・使う前の気持ちの代弁
5. 型ごとに 2〜3 案。意外性のある案を 1 つ混ぜる
6. バナーと LP の 1 行目がつながっているかを確かめる

## 守ること
- 効果の保証と最上級の表現を使わない。数字は与件にある実数だけ
- 業種によっては確かめる法律が変わる。化粧品・健康食品・医療は先に確かめる

## 出力
訴求軸 × 型の表(訴求軸・型・コピー・誰のどのうれしさに対応するか・注意する法規)

あとひと押しと、その法規

コピー本体とは別に、クリックするかどうか迷っている人に決めてもらうための一言を添えます。本書では、これを「あとひと押し」と呼びます。方向性は、数の少なさ(在庫限り)、期限(今月末まで)、お得さ(初回半額)、権威(受賞・推薦)の 4 つです。

ここで気をつけないといけないのが、景品表示法です。景品表示法は、商品やサービスを実際より良く見せたり、実際より得に見せたりする表示を禁止する法律で、消費者庁が担当しています。例えば、根拠の無い「No.1」の表示は、実際より良く見せる表示(優良誤認)にあたります。AI には「事実は与件と LP に書かれているものだけを使い、実績の数字を作らない」というルールを毎回渡し、「導入 3,000 社」のような与件に無い数字は、検品で取り除きましょう。

意外性のある案を 1 つ入れる

基本の型とは別に、「◯◯なのに◯◯」の形で商品の意外な点を見せる案(一覧の意外性型)を、毎回 1 つは入れるようにしましょう。記事や投稿の間に表示される広告は、説明を読まれる前にスクロールされてしまいます。説明を読む前に「おや」と思わせるのが、この案の役割です。ただし、意外性の案は大げさな表現になりやすいので、根拠は必ず「使ってよい事実」の中から選ばせてください。

検索広告で成績の良い広告文も、コピーの材料になります。検索広告では、検索語ごとに複数の広告文が比べられているので、どの数字や料金の言い方が効くのかがすでに分かっているからです。ただし、広告文をそのままバナーに使うと文字が多すぎるので、数字と料金の部分だけを抜き出して使います。依頼するときは、先ほどのプロンプトに次のような指示を足します。

【追加の指示】
- 基本の型とは別に、「◯◯なのに◯◯」の形の案を 1 つ作る。
  意外性の根拠は【使ってよい事実】の中から選ぶ
  (例: 露天風呂付き客室なのに、平日は土曜より 1 人 6,000 円安い)
- 添付の検索広告の実績表から、クリック率が上位 3 件の広告文を読み、
  数字と料金の表現だけを抜き出して使う。文を丸ごと写さない

オファー設計: コピーより先に決めるもの

オファーとは、顧客に提示する取引の条件のことで、特典・無料体験・保証・期間限定・価格の見せ方などが含まれます。LP を訪れた人のうち申し込んだ人の割合(CVR)に最も影響するのは、コピーやデザインではなく、このオファーの中身です。弱いオファーに強いコピーを付けても、強いオファーには勝てません。そのため、オファーはコピーより先に決めておきましょう。

オファーは、次の 3 つの順番で考えます。

  1. いくらまで使えるかを先に計算する。 1 件の申し込みにかけてよい費用は、粗利と LTV(1 人の顧客が取引を続ける間にもたらす利益の合計)から決まります。この上限を知らないまま特典を決めると、申し込みは増えたのに赤字になる、ということが起きます。分からない場合は仮の値で進め、仮の値であることを明記しておきましょう。
  2. 買わない理由から型を選ぶ。 顧客が今まで買わなかった理由(価格が高い、手間がかかる、失敗が不安、など)によって、効くオファーは変わります。例えば、失敗が不安な人には無料体験が効きますが、期間限定の特典を付けても行動にはつながりません。
  3. 条件と期限を先に決める。 「いつまで・誰が・何回まで・何と併用できないか」が決まっていないオファーは、店舗のスタッフが運用できず、クレームの原因になります。

オファーの型には、体験(美容室の初回体験メニュー、旅館の日帰りプランなど)、特典、保証、期間限定、初回価格、松竹梅(3 つの価格帯を並べて見せる)、紹介などがあります。AI には 1 案ではなく 2〜3 案を並べて出させ、比べてから選ぶようにしましょう。また、オファーの良し悪しは、オファーだけを変えて配信し、特典にかかった費用も含めた 1 件あたりの費用で判断します。

誰に出すオファーかで、確認する法律が変わる

オファーを考えるときは、法律の確認も欠かせません。先ほどの景品表示法は、一般の消費者に向けた取引が対象です。店舗が来店客に出す特典や割引はこの法律の対象になりますが、事業者どうしの取引の特典には、原則としてかかりません。ただし、事業者向けにも別の論点があります。

オファーの向き主な論点
消費者向け(店舗が客に出す特典・割引)二重価格表示、打消し表示、「無料」の条件の表示、景品の上限額、業種ごとの上乗せ(美容医療の医療広告ガイドラインなど)、紹介投稿の広告表記(ステルスマーケティング規制)
事業者向け(商談の特典・無料トライアル)独占禁止法の不当な顧客誘引や不当廉売、無料の範囲と自動で有料に切り替わる条件の明示、値引きの請求書・インボイス上の処理

事業者向けの特典でも、それを使って作ったものが消費者向けの広告として配信される場合は、配信される表示を消費者向けの基準で確認します。また、法律の確認は AI に「適法です」と断定させず、論点と確認先を書かせたうえで、最終的には人が確認しましょう。一次資料は、消費者庁の景品表示法のページです。

著者の会社では、オファーの設計書に「法規チェック」と「クライアントへの確認事項」の欄を必ず持たせています。架空の美容室の初回価格のオファーで書くと、以下のようになります。

yaml
offer: 初回カット+カラー 30% オフ(平日 11〜16 時の来店のみ)
type: 初回価格
audience: 消費者向け
legal_check:
  - issue: 二重価格表示
    status: 要確認
    note: 比較に使う「通常価格」で実際に販売した期間と件数を店舗に確認する
  - issue: 打消し表示
    status: 対応済み
    note: 「平日 11〜16 時のみ」を割引率と同じ面に、読める大きさで書く
  - issue: 業種の上乗せ規制
    status: 該当なし
    note: 医療に当たる施術を含まない。含める場合は医療広告ガイドラインで確認する
client_questions:
  - 通常価格での販売実績(期間と件数)
  - 1 人何回まで使えるか、ほかの割引と併用できるか

「要確認」が残っている間は、割引率を大きく載せたコピーを作らないようにします。そのため、コピーを依頼するときにも、この欄をそのまま AI に渡しましょう。

もっと詳しく: 実際に著者が利用しているオファー設計の Skill を簡略化して添付したので参考にしてください

上で説明した 3 つの順番に、法律の確認と、良し悪しの決め方を足した手順になっています。「やらないこと」の「販売実績の無い通常価格を作らない」は、「通常 1 万円 → 今だけ 7,000 円」のような二重価格の表示では、比べる価格で実際に販売していた実績が必要だからです。

markdown
---
name: offer-design
description: >-
  特典・体験・保証・限定・価格の見せ方そのものを設計する。
  「オファーを考えて」「特典を付けたい」「初回価格をどうするか」
  「CV が弱いので中身を強化したい」で使う。
  ※コピー化は広告コピーのスキル、LP 実装は LP 生成のスキル。
---
# オファー設計

## 手順
1. 買わない理由(障壁)を 1 つに特定する:価格・手間・不安・時期
2. 障壁に合う型を型カタログから選ぶ(保証・無料体験・初回価格・同封・期限)
3. 提供コストと条件を数字で書く(誰が、いくらで、いつまで)
4. 法規を確かめる:二重価格・打消し表示・景品の上限・業種の規制
5. 何を見て良し悪しを決めるかを先に書いてから出す

## やらないこと
- 実施しない割引を表示しない。過去の販売実績の無い「通常価格」を作らない
- オファーを強くするだけで CV を上げようとしない(質の悪い問い合わせが増える)

4.3 静止画バナー: 構成の型と、設計書としてのプロンプト

まずクリック率を上げる

多くの広告媒体は、広告を表示するたびにオークションを行い、どの広告を表示するかを決めています。このとき、入札額だけでなく、その広告がどのくらいクリックされそうか(クリック率。CTR)も一緒に評価されます。入札額を上げると広告費が増えてしまうので、クリエイティブで改善するのはクリック率のほうです。

そのため、バナーの改善は、まずクリック率を上げ、次に「あとひと押し」の一言で申し込み率(CVR)を上げる、という順番で進めましょう。ただし、大げさな表現でクリック率を上げても、申し込むつもりの無い人のクリックが増えるだけなので注意が必要です。

制作 3 ステップと構成の型

バナーの制作は、「要素 → 構成 → 仕上げ」の 3 ステップで進めます。

  1. 要素: 入れる文字と画像を書き出し、優先順位を付けます(運用者が担当)
  2. 構成: 要素の大きさと位置を決めます(運用者とデザイナーが担当)
  3. 仕上げ: デザインを整えます(デザイナーが担当。運用者は口を出しません)

「イメージと違う」という手戻りのほとんどは、要素の書き出しを省いたことが原因です。要素ごとに「なぜ入れるのか」を説明できる状態にしておけば、配信後に「どの要素が効いたか」まで確かめることができます。AI に頼むときも同じで、いきなり画像を作らせるのではなく、要素と優先順位を先に決めさせましょう。

構成の型は、以下の表のとおりです。上から 5 つが最初に試す基本の型です。

型見せる順番・配置向いている用途要点
キャッチコピー型(キャッチ+ビジュアル+CTA)大きな一言 → 写真・商品 → ボタン強いコピーが決まったとき(王道)。認知からクリックまで幅広くコピーが面積の半分以上を占めるほど目立たせる
利用シーン型(人物・体験主役型)人物や利用シーン → 感情的なコピー → CTA使っている場面で魅せる(万能。動画化と相性がよい)。旅行、美容、ライフスタイル買う → 届く → 使う → その後、から「一番うれしい 1 シーン」を切り取る。広告っぽさが消える
比較型(比較表型・Before/After 分割型)従来の方法/新しい方法を並べる。または左右・上下で変化を対比価値や違いを一瞬で伝えたいとき。変化が視覚的に伝わる商材不等号・グラフ・天秤・使用前後の 4 通り。比較対象は誰も傷つかないもの
テキスト型文字を主役にしたチラシ風限定・急募などチラシ的な訴求あえて広告感を残す。赤白黒のはっきりした色
クチコミ型(口コミ主役型)利用者の一言 → 写真・評価 → CTA一度サイトを見た人への再表示。信頼感を補いたいとき実際の声+写真。1 デザインで声を差し替えて量産できる
悩み→解決→CTA悩み → サービスでの解決 → 行動課題が明確な商材悩みは 1 つだけ、見出しの大きさで。解決は写真や図で見せ、文字を足さない。コピーの悩み→解決型と組む
ベネフィット→根拠→CTA得られる価値 → 数字・機能 → 行動比較検討中の人向け根拠は数字か機能を 1 つまで。並べると文字が増えて 1 秒テストに落ちる。数字は裏付けのある実数だけ
商品主役型大きな商品・画面 → 短いコピー → CTAアプリ、商品、宿泊施設商品・画面を面積の半分以上に。コピーは短く添えるだけ。アプリは実際の画面を使い、生成した架空の画面にしない
3つの特徴型キャッチ → 特徴を3点 → CTAサービスの全体像を伝えるとき3 点はアイコン+短い語で形を揃える。4 点目を足さない。スマホの実寸で 3 点とも読めるかを確かめる
数字主役型大きな数字 → 数字の意味 → CTA実績、価格、割引数字は単位まで大きく、意味は 1 行で添える。裏付けのある実数だけ(コピーの数字・実績型と同じ)
オファー主役型特典・価格を最大表示 → 条件 → CTAキャンペーン、獲得広告条件は特典・価格と同じ面に、読める大きさで書く(打消し表示)。価格だけが先に目に入ると CTR が下がりがちなので、価値の一言を添える。法規チェックに「要確認」が残るうちは作らない
Q&A型大きな問い → 短い答え → CTA新しいサービスや複雑な商材問いを大きく、答えは 1 行。答えで「新しい気づき」を 1 つだけ与え、詳しい説明は LP に任せる
ステップ型①探す ②選ぶ ③予約する → CTA利用方法の簡単さを示すとき3 ステップまで。各ステップは動詞 1 語で、番号とアイコンで流れを見せる。コピーの手軽さ型と組む
雑誌表紙型強い写真 → 余白のある見出し → 小さな補足ブランド広告、旅行、高価格帯写真の質で決まるので、撮影素材があるときに使う。文字は最小限にして余白を残す。安っぽく見える割引表記は載せない
SNS投稿風型自然な写真・動画の一場面 → 会話調のコピーSNS広告、UGC風クリエイティブ作り込まず、スマホで撮った質感でフィードに馴染ませる。実在の利用者の投稿を使うなら許諾と広告表記(ステマ規制)。架空の利用者を装わない

著者の会社の一人称視点(POV)のショート動画制作サービスを、基本の型で作り分けると、以下のようになります。

キャッチコピー型のバナーの作例
キャッチコピー型
利用シーン型のバナーの作例
利用シーン型
比較型のバナーの作例
比較型
テキスト型のバナーの作例
テキスト型
クチコミ型のバナーの作例
クチコミ型

コピーの型と構成の型を掛け合わせることで、多くのバリエーションを作ることができます。

視認性の 1 秒テスト

バナーを配信してよいかどうかは、「きれいか」ではなく「1 秒で伝わるか」で判断します。目を閉じて、目を開けてから 1 秒だけバナーを見て、内容が頭に入ったかを複数人で確かめましょう。

  • コピーは 15 文字以内、できれば 10 文字以内にします。強調したいときは、言葉を足すのではなく減らします
  • 強調には、文字の下に帯を敷くのが効果的です。著者の検証では、余白を活かしたデザインより、写真の上に白い帯を敷いて大きく文字を載せたデザインのほうが、クリック率も申し込み率も高くなりました
  • 価格が最初に目に入る構成は、価値が伝わる前に値段で判断されてしまうので、クリック率が下がりがちです
  • 最後に必ず、スマホの実際の大きさで確認しましょう。PC では読めるのにスマホでは読めない、という失敗が最も多いからです

画像生成 AI には文章ではなく JSON で指示する

画像生成 AI に「こんな感じで」と文章で指示すると、次の 3 つの問題が起きます。

  • 位置や比率の指定が、おおまかな希望として扱われる
  • 要素が多いと、ロゴ・ボタン・吹き出しなどのどれかが抜け落ちる
  • 成果の出た案から新しい案を作ったときに、どこを変えたのかが記録に残らない

そこで、指示を JSON(項目名と値を組にして書くデータの形式)の設計書として書き、その文字列をそのまま画像生成 AI に渡します。

json
{
  "task": "運用型ディスプレイ広告の静止画バナー(宿泊・キャッチコピー型)",
  "quality_bar": "実際に配信されているプロ制作のバナー。素人感・AIっぽさゼロ",
  "canvas": {"ratio": "1:1", "style": "明るい自然光の写真 + 白帯"},
  "layout": [
    {"zone": "左パネル(幅55%・高さ75%・上下中央)", "element": "コピーパネル",
     "text": [{"content": "平日なら、この露天が貸切", "size": "特大", "color": "白"}]},
    {"zone": "右側(背面全体)", "element": "写真",
     "content": "早朝の露天風呂、湯気、人物なし、ストックフォト品質"},
    {"zone": "最下部の白帯(高さ12%)", "element": "フッター",
     "right": {"element": "CTAボタン", "text": "空室を見る", "background": "#F5A623"}}
  ],
  "constraints": [
    "テキストは上記で指定した文言のみ。一字一句正確に。誤字・創作テキスト禁止",
    "すべての文字が判読可能",
    "ウォーターマーク・余計な装飾なし"
  ]
}

このように書くときのポイントは、次の 4 つです。

  • 文言は確定した文字列で書きます。「〜のようなコピー」と書くと AI が文言を作り始め、誤字や大げさな表現が混ざってしまいます
  • 色は色名か色コードで指定します。文章で指定すると、案を作るたびに色が変わってしまいます
  • 文字の大きさは 3 段階までにします。プロが作ったバナーを見比べると、文字の大きさはほぼ 3 種類に収まっています
  • 最後の制約の 3 行は毎回そのまま入れます。この 3 行が無いと、指定していない文字が増えてしまいます

この JSON は、AI への指示であると同時に、バナーの設計書にもなります。新しい案を作るときは該当する項目を書き換えるだけで済み、JSON が残っていれば、成果の出たバナーを同じ条件で作り直すこともできます。

生成 AI で作るか、HTML で組むか

JSON の設計書から画像を作る方法は 2 つあります。1 つは、JSON をそのまま画像生成 AI に渡す方法です。もう 1 つは、同じ内容を HTML と CSS(Web ページを作るための言語)で組み、ブラウザで表示した画面を画像として保存する方法です。2 つの違いは、文字を誰が書くかにあります。画像生成 AI は文字を絵の一部として描き、ブラウザはフォントを使って文字を表示します。以下の表の違いは、すべてこの 1 点から生まれています。

画像生成 API に渡すHTML で組んで画像化する
文字描かれる。日本語は崩れうるし、指定していない文字が増えることもある。文字に強い経路(OpenAI の GPT Image 系)でもゼロにはならない指定した文字列がそのまま出る。改行位置・禁則・文字詰めまで決められる
同じ入力の再現性毎回変わる。文言を 1 語変えると絵全体が変わる同じ入力なら同じ画像。変えた欄だけが変わる
1 変数だけの派生作りにくい(コピーを変えたつもりが背景も変わる)厳密に作れる
サイズ展開サイズごとに別の絵になり、シリーズとして揃わない同じ素材を組み替えて 1080×1080 と 300×250 を同じ見た目で出せる
表現の幅光・質感・構図・抽象 KV まで作れる手持ちの素材の再配置しかできない。素材が無ければ絵にならない
実在の被写体使えない(実在の客室・料理・スタッフは生成も描き替えも不可)実写の上に帯と文字を重ねるだけなので使える
1 枚あたり実費と数十秒ほぼ無料、1 秒未満
要るもの生成 API の鍵ヘッドレスブラウザと日本語フォント
来歴プロンプトの JSON がそのまま控えになる組んだ HTML が控えになる

基本は、画像生成 AI を使いましょう。「文字が崩れないから」という理由で HTML を選ぶと、手持ちの素材を並べ替えたバナーしか作れなくなってしまいます。文字の崩れは、作り方を変えて避けるのではなく、検品で見つけて作り直すものです。HTML を選ぶのは、次の 3 つのときだけにします。

  1. 実在の写真が主役のとき。 実在の客室の写真は画像生成 AI に渡さず、帯と文字を重ねるだけにします。AI に渡して描き直させると、窓の形や湯船の縁が変わり、実在しない客室の広告になってしまいます。
  2. 同じデザインで中身だけを差し替えて量産するとき。 口コミの文面だけを入れ替える、価格・日付・店舗名を差し替える、同じバナーをサイズ違いで出す、といった場合です。枚数が増えるほど、生成 AI では見た目が揃わなくなります。
  3. 1 か所だけを変えた案を、正確に作りたいとき。 生成 AI では、コピーだけを変えたつもりでも背景まで変わってしまいます。

どちらで作るかの判断は、以下の図のようになります。

本文の関係を表した図(元の mermaid は図の下で開けます)

図を原寸で開く

図の元になった mermaid を見る
mermaid
flowchart TD
  S(["バナーが要る"]) --> R{"主役は実在の写真か"}
  R -->|"はい(客室・料理・スタッフ)"| H["HTML で帯と文字を重ねる<br>写真は生成モデルに渡さない"]
  R -->|"いいえ"| M{"同じデザインで差し替えて量産するか<br>(声の差し替え・価格・サイズ展開)"}
  M -->|"する"| H
  M -->|"しない"| K{"生成 API の鍵はあるか"}
  K -->|"ある・写真風 / KV / 背景が主役"| G["写真に強い経路で生成"]
  K -->|"ある・文字入りの図解が主役"| O["文字に強い経路で生成"]
  K -->|"1 つも無い"| H
  G --> Q["画像を開いて全文字を読み合わせる<br>誤字があれば JSON を直して作り直す"]
  O --> Q
  H --> QH["はみ出し・意図しない折り返し<br>写真の引き伸ばし・実寸での可読性を見る"]
  Q --> V["1 秒テスト"]
  QH --> V
  V --> END(["素材ライブラリへ(来歴つき)"])

実際には、2 つを組み合わせることもよくあります。背景の画像を生成 AI で作り、その上にコピー・ロゴ・ボタンを HTML で重ねる方法は、文字の多いバナーで最も安定します。

もっと詳しく: HTML で画像を作るときの注意点
  • フォント: 画像にする環境に日本語のフォントが入っていないと、文字が □ で表示されます。環境にフォントを入れ、CSS でもフォント名を指定しましょう
  • 書き出しの倍率: 2 倍の大きさで書き出してから縮めます。等倍で書き出すと文字の輪郭がぼやけ、素人が作ったように見えることがあります
  • 背景の写真: 引き伸ばした写真は、背景に使わないようにします
  • 実行する場所: 画面を表示せずに動かすブラウザ(ヘッドレスブラウザ)は、起動に時間とメモリを使います。Web サーバーがリクエストを処理している間には動かさず、別の場所で実行しましょう

検品: 「作った」と「見せられる」は別

生成した画像は、必ず開いて全文字を読みましょう。誤字が 1 文字でもあれば、配信には使いません。修正の指示を重ねるより、JSON を確認して作り直すほうが早く、結果も安定します。

検品で見るところは、作り方によって変わります。生成 AI で作った画像は、書いていない文字が増えていないか、誤字が無いかを確認します。HTML で組んだ画像は文字が正しいことが前提なので、代わりに、はみ出し・意図しない改行・写真の引き伸ばし・スマホでの読みやすさを確認します。最後の 1 秒テストは、どちらも同じです。

実際に AI にバナーを作ってもらう

上の JSON は完成形です。AI に依頼するときは、JSON を書かせる前の「要素」の工程から順番を指定します。以下は、前の節のコピー案を使って、バナーを 2 案作ってもらう例です。

さきほどのコピー案のうち「使ったあとを見せる」型の 2 案で、静止画バナーを作ってください。
いきなり画像にせず、次の順で進めてください。

1. 要素の洗い出し
   入れる文字と画像を表にし、優先順位(1〜5)と「入れる理由」を付ける。
   文字はコピー案の文言をそのまま使い、言い換えない
2. 構成
   案 1 は「キャッチコピー型」、案 2 は「テキスト型」。
   それぞれ JSON の設計仕様(canvas / layout / constraints)を書く。
   位置は「幅◯%・高さ◯%・どこ」で、色は色コードで書く。サイズごとに JSON を分ける
3. 画像化
   - 案 1 は添付の客室露天の写真を背景に使う。写真は描き変えない(明るさとトリミングだけ可)。
     写真の上に白帯と文字を重ねる工程は、HTML で組んで画像化する方法で行う
   - 案 2 は写真を使わないので、JSON の文字列をそのまま画像生成に渡す
   - サイズは 1080×1080 と 300×250 の 2 つ
4. 検品
   画像を開いて全文字を読み、JSON の文言と 1 文字ずつ照合する。
   誤字があれば修正の指示を重ねず、JSON を確認してから作り直す(最大 3 回)。
   3 回で直らない案は「未完成」とし、理由を添えて返す
5. 返すもの
   画像、JSON、要素表、検品結果(照合した文言と作り直した回数)

【制約】
- 価格は画像に入れない
- 写真に無いもの(料理・人物)を描き足さない

要素の表を画像より先に出させているのは、要素ごとの理由が残っていれば、配信後に「どの要素が効いたか」を確かめられるからです。また、実在の客室の写真は画像生成 AI に渡さず、文字を重ねるだけにしています。作り直しの回数に上限を設け、直らないものは「未完成」として返させているのは、上限が無いと作り直しが終わらず、上限だけだと誤字の残った画像が「完成」として返ってきてしまうからです。

よくある崩れと対処

  • 位置や比率が無視される → 文章で指示していることが原因です。「幅〇%・高さ〇%・位置」の形で書き直しましょう
  • 指定していない文言が増える → 「指定した文言のみ」の制約が抜けていることが原因です
  • グラフや表に架空の数値が描き込まれる → 「目盛りや数値のラベルは入れない」を制約に足しましょう。書かないと、存在しない数字が広告に載ってしまいます
  • 文字が斜めに散らばる → 「文字はすべて水平に並べる」を制約に足しましょう
もっと詳しく: 実際に著者が利用しているバナー設計の Skill と JSON のテンプレートを簡略化して添付したので参考にしてください

著者の会社では、基本の構成の型ごとに JSON のテンプレートを 1 枚ずつ持ち、案件ごとに書き換えるのは文言・写真の指示・色・ロゴの欄だけにしています。以下はキャッチコピー型のテンプレートです。上の作り分けの例は、このテンプレートの文言・写真の指示・色の欄だけを差し替え、構造は変えずに画像生成 AI に渡して作ったものです。

json
{
  "task": "運用型ディスプレイ広告の静止画バナーを生成(温泉旅館・キャッチコピー型)",
  "quality_bar": "実際に配信されているプロ制作の広告バナー。素人感・AIっぽさゼロ",
  "canvas": {"ratio": "1:1", "style": "明るい自然光の写真の上に、コピーの色パネルを重ねる"},
  "layout": [
    {"zone": "左パネル(幅55%・高さ75%・上下中央・左端から余白5%)", "element": "コピーパネル",
     "background": "藍(#1F3A5F)から深緑(#2E6B5A)への斜めグラデーション",
     "text": [
       {"content": "平日なら、", "font": "太いゴシック体", "color": "白", "size": "特大"},
       {"content": "この露天が貸切", "font": "太いゴシック体", "color": "白", "size": "特大"},
       {"content": "平日休みのあなたへ", "font": "太いゴシック体", "color": "白", "size": "大"}
     ],
     "note": "3行を左揃えで積み、パネル面積いっぱいに文字を敷き詰める"},
    {"zone": "右側(背面全体)", "element": "写真",
     "content": "早朝の露天風呂、湯気、木の湯船、人物なし、明るい自然光、ストックフォト品質",
     "note": "湯船はパネルに隠れない右側に置く"},
    {"zone": "最下部の白帯(高さ12%)", "element": "フッター",
     "left": {"logo": "小さな緑の葉のアイコン", "text": "箱根の湯宿 このは"},
     "right": {"element": "CTAボタン", "shape": "角丸長方形", "background": "オレンジ(#F5A623)",
               "text": "空室を見る >", "color": "白"}}
  ],
  "constraints": [
    "テキストは上記で指定した文言のみ。一字一句正確に。誤字・創作テキスト禁止",
    "すべての文字が判読可能",
    "ウォーターマーク・余計な装飾なし"
  ]
}

Skill の description に「設計だけで止めない」と書いているのは、画像生成 AI の鍵が無い案件では、JSON を書いた時点で AI が作業を終えてしまいやすいからです。鍵が無くても、HTML で組めば画像まで作ることができます。

markdown
---
name: banner-design
description: >-
  静止画バナーの構成を設計し、検証まで落とす。「バナーを作って」
  「バナーの構成案」「クリエイティブを差し替えたい」で使う。
  ※文言は広告コピーのスキル、画像化は画像生成のスキル、入稿は媒体のスキル。
  **設計だけで止めない**——生成の鍵が無くても画像までは作れる。
---
# 静止画バナーの設計

## 手順
1. 要素を洗い出す(訴求・オファー・証拠・行動のうながし・ロゴ)
2. 構成の型から 1 つ選ぶ:キャッチコピー型・利用シーン型・比較型・テキスト型・クチコミ型など
3. 設計仕様を JSON で書く(位置・比率・文字の大きさを散文で済ませない)
4. 初回は 5 本。横展開は 1 回に 1 変数だけ変える
5. 書き出したら 1 秒テスト(1 秒見て何の広告か言えるか)にかける

## 守ること
- 文字は 2 階層(大きな見出しと説明の行)にし、大きさに 2〜3 倍の差をつける
- 見る数字はクリック率が先。見た目の好みで勝ち負けを決めない

## 出力
構成案(型・理由)→ 設計仕様の JSON → 検品表(文字切れ・要素の欠落・1 秒テスト)

勝ち案が見つかったあとの広げ方

初回の 5 本で成果の出た案(勝ち案)が見つかったら、広げる順番を決めておきましょう。順番を決めずに広げると、配信先・サイズ・形式が同時に変わり、どこで成績が落ちたのかが分からなくなってしまいます。

順番やること理由
1関心の高い層(検索連動や、サイト訪問者への再表示)で勝ち案を探す関心の高い層で勝ったバナーは、関心の低い層でも勝つことが多い。逆は成り立たないことが多い
2関心の低い層(年齢・興味関心・類似の配信)へ広げる勝ち案が決まってから、届く範囲を広げる
3300×250 で決めた訴求を、サイズを自動で組み替える形式で展開する自動で組み替える形式は効果の内訳が見えないので、訴求が固まってから使う
4静止画を動画にする利用シーン型の静止画を 4 枚ほど切り替えるだけで足りる。文字を点滅させるだけの動きは効きにくい

配信面ごとの作り分けは、訴求を固めたあとに行います。成績の良いバナーは配信面を選ばないことが多いので、面ごとの調整を先に行う意味はあまりありません。

また、1 件あたりの費用が安いというだけで勝ちと決めるのも危険です。初回のお試し価格に反応した客と、商品の価値に反応した客とでは、その後にまた買ってくれる割合(リピート率)が違ってくるからです。余裕があれば、獲得した月ごとのリピート率も並べて見るようにしましょう。

競合のバナーを観察する

要素を書き出す前に、同じ配信面に出ている他社のバナーを見ておきましょう。ふだんのブラウザでは、自分の閲覧履歴にもとづく広告が混ざるので、プライベートブラウズで開きます。長く配信され続けているバナーは、成果が出ている可能性が高い参考例です。Meta の広告ライブラリでは配信開始日が見えるので、開始日が古いのにまだ配信中の広告を優先して集めます。

ただし、第三章で説明したとおり、Meta と TikTok は利用規約で画面の自動収集を禁止しているので、広告を集める作業は人が行いましょう(集めた広告の読み方は第五章で扱います)。

デザイナーとカメラマンへの渡し方

デザイナーに依頼する前に、過去のバナーの成績を ◯・△・× の 3 段階で共有しましょう。細かい数字は必要ありません。どのバナーを良いと見ているかが揃っていれば、次に試す案をデザイナーと一緒に考えることができます。

撮影を外部に依頼するときは、構図を細かく指定するより、以下の 5 点を事前に共有します。できれば撮影に立ち会い、サイズごとの余白はその場で伝えましょう。

【撮影のご依頼:温泉旅館・平日プラン広告用】
1. 配信の目的:平日の客室露天プランの予約を増やす
2. 媒体と配信面:Meta 広告(フィード・ストーリーズ)、ディスプレイ広告(300×250)
3. バナーの構成とサイズ:
   - 1080×1080 のキャッチコピー型。左半分に白いパネルと文字を載せる
   - 1080×1920 の利用シーン型。上下の文字が入る範囲を空けておく
4. ターゲット:都内在住・30 代前半の共働き夫婦
5. 伝えたいこと:人の少ない平日に、客室の露天を二人だけで使える
【お願い】横 3,000px 以上、引きのカットを多めに(トリミングと文字載せの余白のため)。
人物は後ろ姿か手元まで(顔は写さない)

構図を指定しないのは、現場を見ていない人が決めた構図より、目的を知ったカメラマンが現場で選んだ構図のほうが良いことが多いからです。「横 3,000px 以上・引きのカット」は、後で複数のサイズに切り出して文字を載せるための条件です。

画像生成 AI の使い分け

著者の会社では、執筆時点で 2 つの画像生成 AI を使い分けています。何が得意かに加えて、実際に使ってみて手間取ったのは、同じ「画像生成 API」でも指定の仕方が違うことでした。

画像 A(Gemini 系)画像 B(OpenAI 系)
まず選ぶ場面写真風・抽象 KV・背景・商品カット文字が入る図解・インフォグラフィック・UI モック
大きさの指定比率+解像度ティアピクセル(比率では指定できない)
参照画像同じ経路に画像を足す別のエンドポイント(編集用)。マスクで部分修正
複数枚回数分リクエストする1 リクエストで返る

どれも執筆時点の仕様なので、組み込む前に公式ドキュメント(Gemini の画像生成、OpenAI の画像生成)で確認してください。このような違いは表にまとめて Skill に書いておくと、AI が指定の仕方を取り違えずに済みます。なお、日本語の文字を入れるなら文字に強いほうから試しますが、どちらも文字が崩れることはあります。生成した画像の文字は、必ず目で読んでから使いましょう。

もっと詳しく: 画像生成 API を組み込むときの注意点
  • API キーは案件ごとに持つ。 運営側の鍵で代わりに生成する仕組みにすると、利用者が画像を作るたびに運営側に費用が発生してしまいます。また、同じ提供元の鍵を別の API にも使い回すと、「ページ速度は測れるのに画像生成だけ失敗する」といった状態になり、原因が分からなくなります。鍵は用途ごとに分けましょう
  • モデル名は設定の 1 か所で管理する。 プレビュー版のモデルは予告なく入れ替わり、旧世代のモデルには提供の停止日があります。モデル名をあちこちに書いていると、停止したときに「鍵が無効なのか、モデルが古いのか」が分からなくなります。モデルは提供元の一覧 API から選ばせ、一覧が取れないときだけ手入力にします
  • 失敗したらファイルを書かない。 最も見つかりにくい失敗は、中身が空の画像ファイルです。LP に貼られてしまうと、壊れていることに気づくのが配信を始めた後になります。画像のデータが取れなかったときはファイルを書かず、失敗の理由と次にやるべきことを返すようにしましょう

来歴を一緒に保存する(サイドカー)

4.1 で、訴求軸や型の組み合わせをメタデータとして別のファイルに持つと書きました。生成したものは、そのメタデータに「どのモデルに、どんな指示で作らせたか」も加えて残しましょう。この生成の記録を来歴と呼びます。どんな指示で作ったかを、後から覚えていられる人はいないからです。

来歴のファイルは、画像を生成するプログラムが、画像と同じ場所に、同じファイル名に拡張子を足した名前で書きます。このように本体の隣に置くメタデータのファイルを「サイドカー」と呼びます。

json
// hero.png の隣に書かれる hero.png.gen.json
{
  "kind": "image",
  "provider": "gemini",
  "model": "gemini-3.1-flash-image",
  "prompt": "早朝の露天風呂、湯気、朝日、人物なし、写真、広角",
  "params": {"aspect": "16:9", "size": "2K"},
  "file": "outputs/lp/a/assets/hero.png",
  "bytes": 1843201,
  "created_at": "2026-09-17T02:10:44Z"
}

サイドカーは、生成するプログラムが自動で書くようにし、AI に手で書かせないようにします。AI に書かせると、書き忘れや、事実と違う内容が混ざってしまうからです。著者の会社では、サイドカーがある画像だけを成果物として登録しています。JSON で指示したバナーなら prompt の欄に設計書がそのまま入り、HTML で組んだバナーなら、組んだ HTML がそのまま控えになります。

直すときは作り直さず、元の画像を渡して編集する

「ロゴを足して」「右下にバッジを付けて」と頼まれたときに、画像を生成し直すのはおすすめしません。直してほしくない部分まで変わってしまうからです。元の画像を参照画像として渡し、編集で済ませましょう。指示には、変える場所と変えない場所の両方を書きます。

添付のバナー(1080×1080)の右下に、「平日限定」のバッジを重ねてください。
- 変えるのは右下の 20% の範囲だけ。文字・写真・色・配置はそのまま
- バッジの文字は「平日限定」の 4 文字だけ。ほかの文字を足さない
- 別の名前で保存し、元の画像は上書きしない

一部だけを描き直す範囲を指定できる機能(マスク)が使える場合は、変える範囲をマスクで指定したほうが確実です。元の画像は、来歴に「編集元」として残しておきます。

生成画像であることを、画像ファイルにも記録する

サイドカーは社内の記録なので、画像を外に渡すときには一緒に渡りません。そのため、画像ファイルそのものにも、生成 AI で作ったことを記録しておきましょう。IPTC(報道写真の業界団体が定めたメタデータの規格)の DigitalSourceType という項目で記録できます。Google Merchant Center も、生成 AI で作った商品画像にはこの項目で生成であることを示すよう求めています(Merchant Center ヘルプ。執筆時点)。記録しておけば、後で実在の写真と取り違えることもありません。

もっと詳しく: DigitalSourceType に書く値
値(IPTC の語彙)意味
trainedAlgorithmicMedia学習済みのモデルで生成した画像
compositeSynthetic撮影した写真に生成した要素を合成した画像
algorithmicMedia学習データを使わず、アルゴリズムだけで作った画像

画像を軽くするために形式を変換すると、道具によってはメタデータが消えてしまいます。変換したあとにも、次の値が残っているかを確認しましょう。

yaml
# 変換後の画像に残っているべき値(XMP の IPTC 拡張の欄)
Iptc4xmpExt:DigitalSourceType: http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia

なお、代替テキスト・ファイルサイズ・読み込みの順番のような、ページへの載せ方の工夫は第六章で扱います。AI への依頼も、画像を作る作業とは分けて出しましょう。混ぜてしまうと、「画像を最適化して」と頼んだだけで、画像が生成し直されてしまうことがあります。

生成でやってはいけないこと

  • 実在の店舗・スタッフ・料理・客室を、生成画像で代用しません(景品表示法の不当表示にあたります)。生成してよいのは、イメージビジュアル・背景・装飾・図解だけです
  • 人物の顔を含む生成画像を「お客様の声」に使いません
  • アップロードされた実在の写真に、写っていないものを描き足しません。明るさの調整とトリミングは問題ありません
  • 生成画像を使ったら、成果物の説明に「生成画像である」と書きます
  • 生成しただけのものを、そのまま配信しません。投稿や配信を行うツールは、パーミッションで確認の対象にしておきましょう

画像を作る手順を 1 つの Skill にまとめる

画像を作る手順は、1 つの Skill にまとめておきましょう。作り方が複数あると、そのうちの 1 つで作った画像だけ来歴が残らない、ということが起きます。著者の会社では、ブラウザの画面を撮影して AI が自作したバナーに来歴が無く、成果物として登録されないまま消えてしまい、「作りました」という返信だけが残ったことがありました。

また、著者の会社では、画像生成の実行はすべてサーバー側の MCP ツールを通し、API キーを AI に見せないようにしています。鍵が無いときはツールが「利用できない」と返すので、AI は人に鍵を聞かずに、もう一方の生成 AI か HTML で画像を作ります。

もっと詳しく: 実際に著者が利用している画像・動画の生成の Skill を簡略化して添付したので参考にしてください

「縮退先」に HTML での作成を書いているのは、鍵が 1 つも無い案件でも、まず配信して試すことはできるからです。ただし、鍵があるときに HTML を先に選ばせることはしません。「文字が崩れないから」という理由で HTML を選ぶと、表現の幅が狭くなるからです。

markdown
---
name: image-video-gen
description: >-
  画像と動画を生成する。生成の鍵が無いときは HTML 合成で画像まで作る。
  「画像を生成して」「バナーを画像にして」「図解を作って」「動画を生成して」で使う。
  **画像を作る口はここ 1 つ**——ブラウザの画面を撮って自作しない(登録されず消える)。
---
# 画像・動画の生成

## 手順
1. 用途を見て経路を選ぶ(写真らしさが要る / 図解が要る / 文字が主役)
2. 散文ではなく設計仕様(JSON)を渡す
3. 生成したら、**何をどのモデルに投げたかを同じ場所に保存する**
4. 直すときは作り直さず、元の画像を渡して編集させる

## 守ること
- 失敗したらファイルを書かない(壊れた画像が成果物に混ざる)
- 生成物であることを画像ファイル自体にも記録する
- 実写が要る場面を生成画像で埋めない

## 縮退先
- 生成の鍵が 1 つも無い → HTML 合成でバナー・図解を画像化する(ここで止めない)

4.4 動画: 台本 → 絵コンテ → 編集

冒頭 3 秒で決まる

たて型の短い動画では、見るのをやめる人の多くが最初の 3 秒で離れます(業界では約 7 割とも言われています)。そのため、台本は「冒頭(フック)」「本編」「行動のうながし(CTA)」の 3 つに分けて設計します。テストでは、本編と CTA を固定して、フックだけを 3〜5 パターン作りましょう。本編を固定しておけば、成果の差がフックの差だと分かりますし、撮影と編集も 1 本分で済みます。

フックには、質問する・否定する・数字を出す・警告する・前後で比べる・結果を先に言う、などの型があります。ただし、型を選ぶより先に満たすべき条件があります。それは、「音を消したまま、1 秒以内に何が起きているか分かるか」です。ロゴのアニメーションや会社紹介から始まる動画は、その時点で見られなくなってしまいます。

尺と文字数も、感覚で決めないようにしましょう。ナレーションは 1 秒 5 文字(速くても 6 文字)、テロップは 1 秒 4 文字が、読める限界です。この計算はプログラムで行い、文字が多すぎる台本は自動で弾くようにします。

成果を見る数字は、広告と、自社アカウントへの投稿とで違います。

広告自社アカウントへの投稿
見る数字の順番①3 秒視聴率 ②途中まで・最後まで見た人の割合 ③クリック率 ④申し込み率と 1 件あたりの費用 ⑤ROAS(広告費 1 円あたりの売上)①3 秒視聴率 ②平均視聴秒数 ③保存とシェア ④プロフィールへの移動
比べる相手目標の数字そのアカウントの過去の平均

成果の出た台本は、冒頭だけを替える → 構成を借りて別の題材で作る → 短く編集し直す → ほかの媒体に使う、の順で広げていきます。

本編の構成と CTA の型

本編も、型から選びます。文章や動画の構成には、昔から知られている型がいくつかあります。例えば AIDMA(注意 → 関心 → 欲求 → 記憶 → 行動)は、1920 年代にアメリカで提唱された、消費者が商品を買うまでの心の動きを表した考え方です。AIDCA は、その「記憶」を「確信」に置き換えたものです。PASONA は、マーケターの神田昌典氏が提唱したセールスレターの構成の型で、新 PASONA はその改訂版です。動画の本編では、主に以下の型を使います。

型流れ向いている用途
新 PASONA問題 → 親近感 → 解決策 → 提案 → 対象の絞り込み → 行動申し込みに直結させたいとき。煽らずに訴求する
PASBECONA問題 → 親近感 → 解決策 → 利点 → 証拠 → 中身 → 提案 → 絞り込み → 行動LP へ送る高単価の商材
AIDCA注意 → 関心 → 欲求 → 確信 → 行動権威づけが効く化粧品・健康食品
PREP結論 → 理由 → 具体例 → 結論15〜20 秒の短尺。何かを教える内容
ストーリー型主人公としての顧客 → 問題 → 案内役としての商品 → 計画 → 行動 → 成功ブランドを知ってもらう動画

CTA も型から選び、1 本の動画で頼む行動は 1 つに絞りましょう。プロフィール・LP・コメントを並べて頼むと、どれも選ばれません。

CTA の型例使いどころ
押す「今すぐ予約」関心の高い層
誘う「詳しくはプロフィールへ」検討中の層。抵抗感が小さい
期限「今月末まで」急ぐ理由を足す
数量「1 日 3 組まで」希少性。事実のときだけ使う
特典「初回 30% オフ」最後のひと押し
質問を返す「行きたい人はコメントで『行く』」反応を集めたいとき

なお、YouTube のスキップできる広告は、少し考え方が違います。5 秒たつと視聴者は広告を飛ばせるようになり、広告費は主に、30 秒(30 秒未満の動画なら最後まで)見られたときか、クリックなどの操作があったときに発生します(Google 広告ヘルプ。執筆時点)。そのため、最初の 5 秒に強い一言を置き、5〜30 秒で対象でない人には飛ばしてもらい、残った人に本編を見せ、最後に期限のある CTA を置きます。

依頼するときは、型を名前で指定し、各部分に何秒使うかまで書きましょう。

【構成】尺 30 秒・Instagram リール
- 0〜6 秒:フック 3 案(本編と CTA は 3 案で共通)
- 6〜26 秒:PREP 型。結論「昼休みに間に合う」→ 理由「駅前・待ち時間なし」
  → 具体例「11 時に入って 12 時に戻る 1 日」→ 結論をもう一度
- 26〜30 秒:CTA は「誘う」型を 1 つだけ。「空き枠はプロフィールのリンクから」
もっと詳しく: 実際に著者が利用しているリール広告の台本の Skill を簡略化して添付したので参考にしてください

「つかみは 3 案作り、本編と CTA は固定する」を手順に書いているのは、「フックを 3 案」と頼んだだけで本編まで 3 通りにされると、何を比べているのかが分からなくなるからです。台本から先の絵コンテ(編集依頼書)は、別の Skill に分けています。

markdown
---
name: reel-script
description: >-
  縦型ショート広告の台本を書く。冒頭のつかみの型と本編の構成から選ぶ。
  「リール広告の台本」「フックを 3 案」「動画広告の構成」で使う。
  ※絵コンテ(編集依頼書)まで出すなら絵コンテのスキル。
---
# 縦型広告の台本

## 手順
1. 訴求軸を 1 つ確定する
2. 冒頭 3 秒のつかみを 3 案作る(本編と CTA は固定し、つかみだけ変える)
3. 本編の構成を型から選ぶ(問題提起・使用前後・実演の繰り返しなど)
4. 尺と文字数を検算する:ナレーションは 1 秒 5 文字、テロップは 1 秒 4 文字
5. CTA は 1 つだけ。押したあとに起きることを書く

## 守ること
- ロゴや会社紹介から始めない
- 参考にした実例には URL・数字・取得日を付ける。無ければ「参考実例なし」と書く

## 出力
フック 3 案 × 本編 × CTA の表と、尺の検算結果
もっと詳しく: 実際に著者が利用しているショート動画の企画の Skill を簡略化して添付したので参考にしてください

自社アカウントに投稿するショート動画の企画は、広告の台本とは別の Skill にしています。上の表のとおり、広告と投稿では見る数字も比べる相手も違うので、1 つにまとめると、投稿の企画を広告の数字で判断してしまうからです。

markdown
---
name: short-video-plan
description: >-
  縦型ショート動画の企画を、フック設計から書き出し設定まで設計する。
  「ショートの企画」「バズる動画」「視聴維持率を上げたい」で使う。
  ※実際に組むのは動画の経路裁定のスキル、広告の台本は縦型広告台本のスキル。
---
# 縦型ショートの企画

## 手順
1. 見る数字の順番を先に決める(3 秒視聴率 → 平均視聴秒数 → 保存・シェア → プロフィール遷移)
2. つかみの型から選ぶ(疑問提起・損失回避・見た目・文字・主観視点・結論先出し・変化など)
3. カット割りとテロップを書く。つかみだけ 3〜5 パターン作る
4. 良し悪しは**そのアカウントの過去平均**と比べる

## やらないこと
- 出典の無い基準値(「視聴維持率 70% が合格」など)を使わない
- 投稿はしない(投稿の口は第 7 章のスキル)

参考動画を分解して、型だけを借りる

成果の出ている他社の動画を参考にするときは、丸ごと真似ても成果は出ません。商材も客層も違うからです。借りるのは型だけにしましょう。手順は「分解 → 目的の書き出し → 自社での作り直し」の 3 段階です。

分解では、動画を細かい間隔(例えば 0.25 秒ごと)の静止画にして、画面の文字と映像を読み取り、音声の文字起こしと時刻で重ねます。そこから、以下の 3 つを順番に作ります。後の段は前の段の結果を材料にするので、順番は入れ替えません。

段作るもの中身
1. 台本の復元時刻ごとの発話・画面の文字・動作発話の無い区間も空欄で残し、動画の全尺を隙間なく埋める
2. 構成の分析区間ごとの役割と技法、全体の型の名前「フック → 問題提起 → 解決 → CTA」のように一言で名付ける
3. 絵コンテカットごとのカメラワーク・アングル・文字の位置撮影と編集にそのまま使える細かさにする

次に、セリフやカットの 1 つずつに、「何のために何を伝えているか」「どんな気持ちを狙っているか」を書き出します(例: 最初に経歴を見せる=話を信じてもらう根拠を先に渡す)。最後に、その目的だけを残し、自社の商材・客層・出演者に合わせて新しいセリフを書きます。

添付の動画(他社の美容室のリール広告)を分解し、型だけを借りて自社用の台本を作ってください。
1. 台本の復元 → 構成の分析 → 絵コンテ、の順に出す
2. 各パートに「目的」と「狙っている心理」を 1 行ずつ書く
3. 目的だけを残し、下の与件で台本を書き直す。セリフ・言い回しは流用しない
4. 元の動画にあって自社に無い要素(演者の肩書・実績の数字など)は使わず、
   代わりに何で補うかを書く
【与件】(商材・ターゲット・訴求軸・使ってよい事実)

参考にする動画の選び方にも注意が必要です。再生数が多いからといって、成果が出ているとは限りません。大きな予算で一時的に配信を増やしただけの動画もあるからです。広告なら、配信開始日が古いのにまだ配信が続いているものを選びましょう。また、自社で過去に成果の出た台本の構成は、他社の動画より再現しやすいので、まずはそちらから使います。

もっと詳しく: 実際に著者が利用している動画の分解の Skill を簡略化して添付したので参考にしてください

この Skill は分解だけを担当し、台本の作り直しは台本の Skill に任せています。入力を「利用者から受け取る動画ファイル」に限っているのは、Meta と TikTok が利用規約で画面の自動収集を禁止しているからです。構成の分析では、たとえば次のような形で結果を出させています。

json
{
  "sections": [
    {"name": "フック", "time_range": "0.0-2.5",
     "purpose": "スクロールを止める",
     "technique": "否定型の文字+寄りのカット"},
    {"name": "問題提起", "time_range": "2.5-7.0",
     "purpose": "見る人に自分のことだと思わせる",
     "technique": "一人称の独り言"}
  ],
  "structure_pattern": "フック → 問題提起 → 解決 → CTA",
  "stats": {"cuts": 14, "avg_cut_sec": 2.1, "caption_chars_per_sec": 3.6}
}
markdown
---
name: reel-teardown
description: >-
  参考にする短尺動画を分解し、台本・構造・カット割りを起こす。
  「この動画を分解して」「構成を逆解析して」「テロップを書き起こして」で使う。
  ※複数本の棚卸しは投稿別の一覧のスキル(第 7 章)。
---
# 動画を分解する

## 入力
- 動画ファイル(利用者から受け取る)と、参照元の URL・取得日

## 手順(順番を飛ばさない)
1. 台本を復元する(音声の文字起こしと、画面のテロップを別の列に)
2. 構造を区切る(つかみ / 本編 / うながし)
3. カット割りを数える(カット数・平均カット長・テロップ密度)
4. テンポを出す(総文字数 ÷ 尺 = 文字 / 秒)

## やらないこと
- 借りるのは型だけ。文面と映像を丸写ししない
- 再生数・いいね数を推測で埋めない(渡された記録に無ければ「未取得」)

編集依頼書: 編集者が質問せずに作業を始められる細かさで書く

台本と編集の間には、編集依頼書(絵コンテ)が必要です。絵コンテとは、カットごとの映像・テロップ・セリフ・音を、時間の順に並べた設計図のことです。編集依頼書の完成の条件は、「編集者がこの 1 枚だけを見て、質問せずに作業を始められる」ことの 1 つだけです。

編集依頼書には、仕上がりの方針と参考にする広告、テロップの配色や書き出しの設定などの申し送り、素材の置き場所、そしてカットごとの表(カット表)を書きます。カット表の編集指示は、数値で書きましょう。「0.3 秒で拡大して戻す」なら伝わりますが、「テンポよく」では質問が返ってくるだけです。また、カットごとに「演出の意図」の列を置いておくと、編集者が迷ったときの判断の基準になります。

実際に AI に台本と編集依頼書を作ってもらう

題材は、架空の駅前の美容室です。台本と編集依頼書を、1 回の依頼でまとめて頼む例です。

駅前の美容室の Instagram リール広告(9:16・15 秒)の台本と編集依頼書を作ってください。

【商材】初回のカット+カラーが 30% オフ(平日 11〜16 時の来店のみ。予約はプロフィールのリンクから)
【ターゲット】近くのオフィスで働く 20 代後半〜30 代の女性。昼休みや半休で行ける店を探している
【訴求軸】職場から歩いて行けて、平日の昼なら待たずに入れる
【素材】店内と施術の実写動画が 12 本(共有フォルダにある)。顔を出してよいスタッフは 2 名だけ

【台本の組み方】
- 冒頭のフックを 3 案(A/B/C)。本編と CTA は 3 案で共通にする
- フックは「音を消したまま 1 秒で何の動画か分かる」ことを最優先にする
- ナレーションは 1 秒 5 文字以内、テロップは 1 秒 4 文字以内。超えたカットは削って合わせる

【編集依頼書】
カット表の列は「カット番号・尺・映像・テロップ・セリフ・文字数・音・演出意図・編集指示」。
編集指示は数値で書く(「テンポよく」ではなく「0.3 秒でズームイン」)

【やってはいけないこと】
- 割引率・時間帯・価格を与件の文言から変える
- 「必ず」「絶対」など成果を約束する言い方
- 素材に無いカット(外観の空撮、許可の無いスタッフの顔)を前提にする。
  必要なら「撮影が必要」と書いて別に列挙する

【返すもの】
台本 3 案、カット表、検算結果(カットごとの文字数と尺)、撮影が必要なカットの一覧

「素材に無いカットを前提にしない」の行が無いと、手元に無い映像を前提にしたカット表ができあがり、編集者が素材を探す段階で作業が止まってしまいます。撮影が必要なカットを別に書き出させておけば、その一覧をそのまま撮影の依頼に使うことができます。

カット表は数百のマスを埋める作業になるので、著者の会社では、カット表の設計だけを別のエージェント(サブエージェント。第二章)に任せ、メインのエージェントは与件の確認・文字数の計算・検品に専念させています。

もっと詳しく: 実際に著者が利用しているカット表設計のサブエージェントと検品表を簡略化して添付したので参考にしてください

Claude Code のサブエージェントは、先頭に name・description・tools を書いた Markdown ファイルで定義できます(公式ドキュメント)。使える道具を Read と Write に限っているので、設計担当が調査や画像生成を始めることはありません。また、メインのエージェントに返す内容を「保存場所と要約」に絞り、数百マスのカット表がメインのエージェントのコンテキストを埋めないようにしています。

markdown
---
name: storyboard-designer
description: >-
  動画広告の編集依頼書のうち、カット表の設計だけを担当する。
  与件と参考広告の要約を受け取り、フック 3 案とカット表を JSON で書き出す。
  調査・画像生成・編集の実行はしない。
tools: Read, Write
model: sonnet
---
あなたは動画広告のコンテ設計担当です。

## 入力
- 与件(商材・オファー・訴求軸・尺・媒体・素材の一覧)
- 参考広告の要約(あれば)

## 守ること
- 価格・割引率・時間帯は与件の文言だけを使う。与件に無い数字は書かない
- 素材一覧に無いカットには「撮影が必要」の印を付ける。
  実在の店や人に見える映像を生成で補う案は出さない
- ナレーションが 1 秒 5 文字、テロップが 1 秒 4 文字を超えたカットは、文言を削って合わせる
- 指定された出力先以外のファイルを書かない

## 返すもの(これ以外は返さない)
- 書き出した JSON の保存場所
- 設計判断の要約(5 行以内): 選んだフックの型、削ったカット、撮影が必要なカット
- 検算の上限を超えたまま残ったカットの番号(無ければ「なし」)

設計担当から戻った依頼書は、メインのエージェントが以下の検品表で確認し、落ちた項目を修正の指示と一緒に差し戻します。数値と事実の項目は、見た目が整っていても間違いが残りやすいので、必ず確認します。

markdown
## 編集者が質問なしに着手できるか
- [ ] 映像の欄が、カメラ位置・被写体・動きまで書かれている(「商品を見せる」だけは不可)
- [ ] 撮影済み素材を使うカットに、素材の場所と使う区間(「16 秒以降」など)がある
- [ ] 編集指示が秒数・間隔・倍率で書かれている
- [ ] 効果音が擬音で指定されている(「効果音を入れる」だけは不可)
## 構成
- [ ] 訴求軸ごとの案が 3〜4 本あり、訴求軸が重なっていない
- [ ] 各案にフック 3 案があり、本編は共通になっている
- [ ] 流れが フック → 商品を見せる → 仕様 → 比較 → 提案 → CTA → 最後の画面 に沿っている
- [ ] カット尺の平均が 2〜3 秒、最長 5 秒以内(例外には理由がある)
## 事実
- [ ] 価格・数値・色数・型番が、与件か出典のあるものだけ
- [ ] 比較カットの他社の数字に根拠がある(無ければ「要確認」と書かれている)
## 整合
- [ ] 申し送りの例が、実際のカット番号と文言を指している
- [ ] 音を消して文字だけ読んでも、筋が通る
- [ ] 書き出し設定が配信先と合っている(9:16・1080×1920 など)

編集の道具

動画の編集には、大きく分けて 3 種類の道具があります。

道具得意修正実行環境
ffmpeg(OSS)尺取り、コンタクトシート(1 秒 1 コマの一覧画像)、字幕の焼き込み、書き出し後の検品コマンドサーバー・ローカルの両方
HTML → MP4 のレンダラー(OSS)情報・数値・UI など、テキストとグラフィックが主役の動画。変数差し替えで多言語・バリアントを量産コードなので差分で直せるサーバー・ローカルの両方
ローカルの GUI 編集アプリ(Palmier Pro)実写素材が主役の動画。店舗・人物・体験の生っぽさタイムラインの再編集。1 本ずつ人手ローカルの Mac のみ

ffmpeg は、動画の切り出し・結合・字幕の焼き込み・静止画の書き出しまでを 1 つで行える、動画処理の基本の道具です。HTML から動画を書き出す道具には、HyperFrames(HTML と CSS で作った画面を MP4 にする OSS)のように、AI エージェントから使われることを前提にしたものが出てきました。プログラムなので文言の差し替えが簡単で、多言語版を安く作れ、サーバーでも動くのが利点です。著者の会社では、GUI の編集アプリとして Palmier Pro(Mac 向けの編集アプリ。起動している間だけ MCP サーバーが立ち、タイムラインを AI から操作できる)を使っています。

HyperFrames と Palmier Pro は、どちらかを選ぶものではなく、扱う素材が違います。HyperFrames は文字や図から映像を作る道具で、Palmier Pro は撮影した映像を並べる道具です。

もっと詳しく: HyperFrames と Palmier Pro の違い
HyperFramesPalmier Pro
実体HTML と CSS の構成をヘッドレスブラウザで描画して MP4 にする(OSS・CLI)Mac のローカル GUI 編集アプリを MCP 経由で駆動する
得意情報・機能・数値・UI・サイトの訴求。テキストとグラフィックが主役実写素材が主役。店舗・施設・人物・体験の「生っぽさ」
修正コードなので差分で直せる。文言・数値・言語・尺の差し替えが安いタイムラインの再編集。差し替えのたびに人手
量産変数の差し替えでバリアント・多言語を量産できる1 本ずつ
素材素材ゼロでも成立する(生成と組み合わせる)素材が無いと始まらない
実行環境ローカルでもサーバーでも動くローカルの Mac のみ
自動化定期実行やサーバーからの自動生成に載る人が Mac の前にいる前提

同じ入力から同じ結果が出るかどうかも違います。HyperFrames は同じ入力なら同じ MP4 が出るので、1 か所を差し替えてもほかの部分は変わりません(著者の実測では、サーバーでの書き出しは Mac より 3〜4 倍遅く、36 秒・1080p の動画で Mac が 27 秒、サーバーが 1 分 43 秒かかりました。ただし、できあがる動画は同じです)。Palmier Pro は人がタイムラインを操作する道具なので、同じ結果に戻せるかどうかは人の手順次第です。また、1 つのアプリが 1 つの状態を持つので、AI から操作する場合も同時に複数は動かせません。

もっと詳しく: よく使う ffmpeg のコマンド
bash
# ① 尺・解像度・フレームレートを確かめる(素材の棚卸しと、書き出し後の検品の両方で使う)
ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,r_frame_rate -show_entries format=duration \
  -of default=noprint_wrappers=1 in.mp4

# ② コンタクトシート(1 秒 1 コマを 6×5 枚のタイルにして 1 枚の画像にする)
ffmpeg -i in.mp4 -vf "fps=1,scale=320:-1,tile=6x5" -frames:v 1 sheet.png

# ③ 発話区間の当たりを付ける(-30dB 以下が 0.5 秒以上続いた箇所を無音として書き出す)
ffmpeg -i in.mp4 -af silencedetect=noise=-30dB:d=0.5 -f null - 2> silence.log

# ④ 字幕を焼き込む(映像だけ作り直し、音声はそのまま通す)
ffmpeg -i in.mp4 -vf "subtitles=sub.srt" -c:a copy out.mp4

③は音声認識の代わりにはなりません。「どこで話しているか」までしか分からないので、文字起こしが必要な工程では「未取得」と書きます。①は、書き出した後にもう一度実行して、配信先の条件(9:16・1080×1920 など)と合っているかをプログラムで確認しましょう。目で見るだけでは、尺が 1 秒足りない、フレームレートが 30 ではなく 29.97 になっている、といった違いを見落としてしまいます。

作り方を選ぶ

どの道具で作るかは、まず手持ちの素材で決めます。

手持ち素材主経路生成 AI の役割
実写動画が主役Palmier Pro(ローカル限定。サーバーでは縮退)補助。OP・ED・数値カードはレンダラーで作って重ねる
画像はあるが動画は無いHyperFrames(画像をメディアとして流し込む)不足カットを補完
何も無い静止画を生成 → 動かすカットだけ動画化 → レンダラーで編集素材そのものを作る

素材が無くても、動画を作れないわけではありません。手順が 1 つ増えるだけです。画像生成 AI の鍵が無くても同じで、既存の画像に拡大・移動・テロップの動きを付ければ、動画広告を作ることができます。「動画生成 AI が使えないので、動画広告は作れません」という答えは間違いです。

この選び方は、以下の図のようにまとめることができます。著者の会社では、この図を Skill に書いて AI に読ませ、選んだ作り方とその理由を、成果物と一緒に残させています。ポイントは、どの分岐の先も何らかの成果物で終わるようにすることです。「できませんでした」で終わる分岐は作らないようにしましょう。

本文の関係を表した図(元の mermaid は図の下で開けます)

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る
mermaid
flowchart TD
  START(["動画の依頼"]) --> ENV{"実行環境は?"}
  ENV -->|"サーバー"| RUN["Palmier Pro は選べない"]
  ENV -->|"ローカルの Mac"| LOCAL["両方が候補"]
  RUN --> MAT
  LOCAL --> MAT{"手持ち素材は?"}
  MAT -->|"実写動画が主役"| PAL{"Palmier Pro を使える環境か"}
  PAL -->|"はい"| SB["絵コンテ(編集依頼書)<br>→ Palmier Pro で組む"]
  PAL -->|"いいえ"| ESS{"実写が本質的に必須か"}
  ESS -->|"はい"| PLAN["編集指示書まで作って納品<br>組み立てには Mac が要ると明示"]
  ESS -->|"いいえ"| HF
  MAT -->|"画像はあるが動画は無い"| IMG["画像を流し込む<br>不足カットだけ生成で補う"]
  MAT -->|"何も無い"| GEN["静止画を生成して構図を確定<br>→ 動きが訴求のカットだけ動画化"]
  IMG --> HF
  GEN --> HF
  HF["HyperFrames で編集<br>モーション・テロップ・情報カード・音"] --> QC["フレームを抽出して検品"]
  SB --> QC
  QC --> OUT(["MP4 と、選んだ経路の根拠を残す"])
  PLAN --> DONE(["設計書を納品<br>何があれば動画まで進むかを書く"])

分岐で間違えやすいのは、次の 3 つです。

  • 縦長の動画だから Palmier Pro、ではありません。 HyperFrames でも縦長の動画を作れるので、縦横の比率は判断の材料になりません
  • 実写の素材が 2〜3 カットしか無いなら、HyperFrames を使います。 素材は画面の一部として差し込めばよく、動画の主役は文字や図になります
  • 後で文言・数値・言語・尺を差し替える予定があるなら、HyperFrames を使います

2 つの道具を組み合わせることもよくあります。例えば、Palmier Pro で本編を組み、冒頭・最後・数値のカードを HyperFrames で作って重ねる形です。組み合わせるときは、どちらが主でどちらが補助かを必ず書かせましょう。書かないと、両方で本編を作ってしまうことがあります。

もっと詳しく: 実際に著者が利用している作り方を選ぶ Skill を簡略化して添付したので参考にしてください

この Skill は自分では 1 カットも作らず、作り方を決めて、制作の Skill に引き継ぐだけです。作り方を選ばずに制作の Skill が動き始めると、実写の雰囲気が大切な案件を図やアニメーションで作ってしまったり、サーバーでは動かない道具を選んで止まってしまったりするからです。

markdown
---
name: video-route
description: >-
  動画の依頼を受けたとき、どの経路で作るかを裁定して引き渡す。
  「動画を作って」「プロモ動画」「素材が無いけど動画にしたい」など、
  作り方が指定されていない依頼はすべてここから。
  ※企画・台本の知識だけならショート企画のスキル。
---
# 動画の経路を裁定する

## 手順
1. 実行環境を見る(ローカルの編集アプリが使えるか)
2. 手持ち素材を見る:実写動画が主役 / 画像はある / 何も無い
3. 後から文言・数字・言語を差し替える予定があるかを聞く
4. 経路を 1 つ選び、**選んだ理由を成果物と一緒に残す**
5. 併用するなら、どちらが主でどちらが従かを必ず書く

## やらないこと
- 「素材が無いので作れません」と答えない。素材ゼロは経路が 1 本増えるだけ
- 縦型か横型かで経路を決めない(アスペクト比は判定材料にならない)

## 縮退先
- 実写が本質的に必要だが組めない→ 編集指示書まで作って納品し、何があれば進むかを書く

静止画で構図を決めてから動かす

画像や動画を生成 AI で作るときは、「静止画で構図を決める → 動かすカットだけ動画にする → 編集する」の順番で進めます。動画の生成は 1 本に 15〜20 分かかり、費用もかかるので、構成を変えたくなったときの作り直しが最も高くつくからです。まずはカットごとの最初のコマを画像で作って並べ、合意を取ってから、その画像を最初のコマにして動画にしましょう。

また、すべてのカットを生成 AI の動画にする必要はありません。数値・料金・CTA のような情報を見せるカットは、HyperFrames などで文字と図で作るほうが安く、後から文言も差し替えられます。生成 AI の動画にするのは、湯気・手元・歩く様子のように、写真では伝わらない動きそのものを見せたいカットだけです。

もっと詳しく: 動画生成 API を組み込むときの注意点

著者の会社では、執筆時点で 2 つの動画生成 AI を使っています。実写風で縦横比を自由に選べるもの(Seedance 系)と、音声付きの短い動画が得意なもの(Veo 系。16:9 と 9:16 のみ、4・6・8 秒)で、どちらも最初のコマを画像で指定できます。仕様は、組み込む前に公式ドキュメント(Veo、BytePlus ModelArk)で確認してください。

  • 生成には時間がかかるので、Web サーバーのリクエストの中では待たず、別の場所で実行します
  • 執筆時点では、生成した動画の URL が 24 時間で使えなくなる提供元があります。URL だけを控えておいて後でダウンロードするのではなく、受け取ったその場でダウンロードして、自分の保管場所に置きましょう
  • API キーの持ち方、失敗したときの扱い、来歴の保存は、画像と同じです(4.3 節)

動画の種類ごとに何を決めるか

動画の依頼は、種類によって最初に決めることが違います。種類を決めないまま作り始めると、実写の雰囲気が大切な案件を図やアニメーションで作ったり、解説動画を元の記事の段落の順に並べたりしてしまいます。以下の表は、著者が依頼を受けたときに使っている分け方です。

種類向いている素材最初に決めること構成の決め方よくある失敗
広告リール(フック差し替え)実写・画像訴求軸と、フック 3〜5 案フック × 本編 × CTA。本編は固定するロゴや会社紹介から始める
一人称視点(POV)の広告縦撮りの実写ペルソナと利用シーンの組み合わせ「POV:〜」の冒頭の文字 → 体験の順。15〜40 秒撮影者の映り込みや引きのカットが混ざり、視点が崩れる
会話のダイジェスト会話や体験そのものが面白い実写残す会話の範囲会話の起承転結を丸ごと残し、間だけを詰める。60〜100 秒名場面だけを飛び飛びにつなぎ、文脈が切れる
作業のダイジェスト仕込みや舞台裏などの作業の実写見せ場の工程と、その尺の配分工程を時系列で並べ、見せ場に全尺の 3〜4 割を使う全工程を同じ速さで流し、見せ場が目立たない
商品・サービスの紹介サイトの URL、商材の資料動画全体で約束する 1 文問題提起型・使用前後型・実演の繰り返し型などから 1 つ選ぶ機能を順に並べ、見る人の利点に言い換えていない
顔を出さない解説記事・メモ・テーマ見終わった人が持ち帰る 1 文概念・手順・列挙・事例のうち 1 つ元の文章を段落の順に読み上げる
短いモーショングラフィックスロゴ・数字・短い 1 文見せるものを 1 つ10 秒前後。ナレーションは入れない要素を詰め込み、動きの意味が伝わらない
話している映像への字幕1 人が話す映像字幕の見た目を 1 つ映像は触らず、文字だけを足す無音の区間や、すでに焼き込まれた字幕の上に重ねる
話している映像への情報カード対談・インタビューどの発言でカードを出すか文字起こしから数字・引用・要点の時刻を拾う話していない内容をカードに書く
長尺からの切り抜き講演・イベント・インタビュー単体で意味が通る区間30〜60 秒。冒頭の数秒で内容が分かる区間を選ぶ話の途中で切れ、結論が入っていない
スライド資料・既存のページ動画にするか、めくって見せる資料にするか1 枚 1 主張。見出しは文で書く見出しを「課題」のような単語で済ませる

例として、顔を出さない解説動画を取り上げます。元になる記事は情報を並べたもので、動画は見る人の理解を順番に積み上げるものです。最も多い失敗は、記事を段落の順に言い換えて読み上げてしまうことです。そのため、先に次の 6 つを決めてから、場面を組み立てましょう。

  • 誰に向けるか(何を知っていて、何を知らないか)
  • なぜ気にするべきか(解消する疑問や、知らないと起きる損)
  • 見終わった人が持ち帰る 1 文
  • その 1 文を支える 3〜6 個の要素(仕組み・手順・項目)
  • 裏付け(数字・例・比較)
  • 締めくくり(試す・気をつける・考える、のどれを促すか)

冒頭の 3〜5 秒は定義から入らず、疑問・意外な事実・知らないと起きる損を見せます。持ち帰る 1 文は、2 つ目の場面までに言い切りましょう。

もっと詳しく: 解説動画の構成案の例

温泉旅館の公式アカウントで「はじめての温泉マナー」を 45 秒で解説する場合の構成案です。場面ごとに「役割」と「見終わった人が分かること」を 1 行ずつ書いておくと、役割の無い場面が見つかり、削ることができます。

yaml
video: はじめての温泉マナー(縦 9:16・45 秒・ナレーションあり)
audience: 温泉にほとんど入ったことがない 20 代。旅行前に不安がある
thesis: 3 つだけ守れば、はじめてでも気まずくならない
structure: 列挙(3 項目)
frames:
  - no: 1
    role: フック
    key_message: マナーを知らずに気まずい思いをする人は多い
    hook: 疑問「タオル、湯船に入れていいと思っていませんか」
    sec: 4
  - no: 2
    role: 持ち帰る 1 文
    key_message: 3 つだけ守ればよい
    sec: 4
  - no: 3
    role: 項目 1
    key_message: 入る前にかけ湯をする
    sec: 9
  - no: 4
    role: 項目 2
    key_message: タオルは湯船に入れない
    sec: 9
  - no: 5
    role: 項目 3
    key_message: 髪が長い人はまとめる
    sec: 9
  - no: 6
    role: 締めくくり
    key_message: 3 つを思い出せれば大丈夫。予約はプロフィールから
    sec: 10
checks:
  - 項目の場面は同じ構図(同じイラストの浴室)で続け、変わるのは 1 か所だけにする
  - 場面の切り替え方は 2〜3 種類に絞り、同じものを繰り返す

項目を並べる型なので、3 つの項目は同じ構図の上で 1 つずつ見せます。場面ごとに絵が変わると、見る人は前の項目とのつながりを追えなくなってしまいます。

組み立ての既定値と検品

編集依頼書に書かれていない細かい部分は、組み立てる側の既定値で決まります。既定値が無いと、カットは合っているのに素人が作ったような仕上がりになってしまいます。著者が完成品の広告と自動で編集した結果を見比べて決めた既定値は、以下のとおりです。

  • テロップは 2 段階で作ります。数字・価格・商品名などの大きな言葉と、説明の行を分け、大きさに 2〜3 倍の差をつけます
  • 文字は白で、濃い色の縁取りを付けます。明るい背景の上に白い文字を直接置かないようにしましょう
  • ナレーションのあるカットには、テロップが無くても要点を文字で出します。音を消して見る人がいるからです
  • 総尺の上限は、依頼書の合計に 1 割を足した長さにします。超えたときに、文を削るか、話す速さを上げるか、上限を緩めるかは、人に決めてもらいます
  • 文字の位置は、媒体が推奨する安全な範囲の内側に収めます。例えば Meta は、リール広告では画面の上 14%・下 35%・左右 6% に重要な文字やロゴを置かないよう勧めています(Meta 広告ガイド。執筆時点)

書き出した動画は、書き出しの設定(縦横の画素数など)を読み取って依頼書と照らし合わせる、1 秒 1 コマの一覧画像を作って目で見る、意図しない黒い画面が挟まっていないかを確認する、の 3 つの方法で検品します。

もっと詳しく: 実際に著者が利用している動画の組み立ての Skill を簡略化して添付したので参考にしてください

この Skill は、依頼書のとおりに組み立てて検品するだけで、構成は変えません。依頼書は承認を取る単位なので、組み立てる側が構成を変えると、承認されたものとできあがった動画が食い違ってしまうからです。依頼書の 1 行は、編集計画では次のような 1 カット分のデータに直し、依頼書に無い判断をしたときはその理由を残させています。

yaml
cut: "1.1"
phase: フック
variant: A
duration_sec: 1.5
video:
  file: materials/footage/salon_front.mov
  source_in_sec: 16.0
voiceover:
  text: "昼休みにカット、間に合うの?"
texts:
  - content: "昼休み"
    style: keyword_large   # 大きなキーワード
  - content: "にカット、間に合う?"
    style: sub_line        # 説明の行。キーワードの半分以下の大きさ
se: ["ハサミのシャキッ"]
note: 使う区間が依頼書に無いため、手元が映る 16 秒以降を選んだ
markdown
---
name: video-assemble
description: >-
  絵コンテ(編集依頼書)を受け取って動画を組み、検品して納品する。
  「依頼書どおりに編集して」「絵コンテから動画化」で使う。
  ※依頼書を作るのは絵コンテのスキル、作り方が未定なら経路裁定のスキルが先。
---
# 動画を組み立てる

## 手順
1. 依頼書を 1 カット 1 行の編集計画に直す
2. 総尺を検算する(発話の合計時間を測り、上限を超えたら人に判断を返す)
3. タイムラインを組み、既定値を適用する(文字の 2 階層・白文字に濃い縁取り・音なし対応)
4. 書き出し設定(画素数・コーデック)を読み取って依頼書と照らす
5. 1 秒 1 コマの一覧画像を作って目で見る。黒い画面の混入を検出する

## 守ること
- 文字は媒体の安全域(上下左右の余白)の内側に収める
- 環境に無い書体名を指定しない(エラーを出さず別の書体で書き出される)
- 動かない道具の名前で「作りました」と書かない

長い動画から切り抜く

講演やイベントの長い動画から短い動画を切り出すときは、文字起こしを材料にします。区間の選び方は、以下のとおりです。

  • 単体で意味が通る 30〜60 秒の区間を選びます。冒頭の強さを 10 点満点で採点し、基準に届いたものだけを残します
  • 選んだ後に、各区間が話の途中で終わっていないかを、別の工程として確認します。選ぶ工程と確かめる工程を分けると、結論の抜けた区間が減ります
  • 縦長に切り出すときは、元の映像の配置で方法を変えます。1 人が話す映像は顔を中心にし、画面共有と顔の小窓がある映像は、画面を上・顔を下に並べます
  • 字幕の時刻は、切り出した後の動画で文字起こしをやり直して取ります。元の動画の時刻を使うと、ずれてしまいます
  • 切り抜いてよいのは、自社かクライアントが権利を持つ素材と、出演者の許可がある素材だけです

文字起こしにも注意が必要です。音声認識は、無音の区間で存在しない言葉を出すことがあります。同じ短い言葉の繰り返しが続く区間は「要確認」として残し、字幕も付けないようにしましょう。また、すでに字幕が焼き込まれた素材に、字幕を重ねないようにします。

添付の講演動画(60 分・自社主催のセミナー。登壇者の許諾済み)から、
Instagram リール用の切り抜き候補を選んでください。まだ動画は切りません。

【選ぶ基準】
- 30〜60 秒で、前後を見なくても意味が通る区間
- 冒頭 3 秒で何の話か分かる。冒頭の強さを 10 点満点で採点し、7 点以上だけ残す
- 結論まで含む。話の途中で終わる区間は除く

【出力】
表で出す。列は「開始/終了/冒頭の一言/採点と理由/縦にするときの配置(1 人・画面共有・横並び)」。
候補は多くて 5 件。最後に、選んだ全区間が話の途中で終わっていないかをもう一度確かめ、結果を書く

【守ること】
- 文字起こしが不自然な区間(同じ言葉の繰り返しなど)は候補にせず、時刻だけを報告する

候補を選ぶ工程と切り出す工程を分けているのは、切り出した後で区間を選び直すと、切り出し・縦長への調整・字幕の作業がすべてやり直しになってしまうからです。

もっと詳しく: 実際に著者が利用している切り抜きの Skill(3 本)を簡略化して添付したので参考にしてください

切り抜きの作業は、横長のまま候補を出す Skill、縦長にして字幕を焼き込む Skill、投稿文とタイトルを作る Skill の 3 つに分けています。工程を分けておくと、やり直しが 1 つの工程の中で済むからです。どの Skill も投稿はせず、投稿は第七章で扱う投稿の Skill だけが行います。

markdown
---
name: highlight-clips
description: >-
  長尺の動画から、単体で意味が通る横型の切り抜きを作る。
  「長尺からハイライトを作って」「ポッドキャストを切り抜いて」で使う。
  ※縦型にして字幕を焼き込むまでなら縦型切り抜きのスキル。
---
# 横型の切り抜き

## 手順
1. 文字起こしを作る(時刻付き)
2. 単体で意味が通る区間を探す:問いと答えが揃っている 30〜60 秒
3. 冒頭の数秒で内容が分かるところから始める
4. 候補を並べ、採用する前に人に見せる

## やらないこと
- 話の途中で切らない(結論が入っていない切り抜きは使えない)
- 公開しない(投稿の口は第 7 章のスキル)
markdown
---
name: vertical-clips
description: >-
  長尺の動画から、縦型ショートの完成品(クロップと字幕焼き込みまで)を作る。
  「縦型に変換して」「切り抜きを SNS 用に仕上げて」で使う。
  ※横型のままでよければ横型切り抜きのスキル。
---
# 縦型の切り抜き

## 手順
1. 切り抜く区間を決める(横型切り抜きと同じ基準)
2. 9:16 に切り抜く。話し手が端に寄っていないかを 1 本ずつ見る
3. 字幕を焼き込む(下端 2 割に重要な文字を置かない)
4. 書き出し後にフレームを抜いて、文字切れと黒帯を確かめる

## 縮退先
- 変換の道具が使えない → 区間の一覧(開始・終了・要旨・字幕案)を納品し、人が切れる形にする

投稿文とタイトルを作る Skill では、内容がほぼ同じ動画をまとめさせています。手元の動画には撮り直しが混ざるからです。ただし、音声が同じで画面のタイトルだけが違う動画は重複ではなく A/B テストの案なので、消さずに印を付けて残させます。

markdown
---
name: caption-and-title
description: >-
  手元の短尺動画群を文字起こしし、重複を除いて投稿文とタイトルを作る。
  「この動画たちにキャプションを付けて」「タイトルを生成して」で使う。
  ※投稿の実行は第 7 章のスキル。このスキルは文面まで。
---
# キャプションとタイトル

## 手順
1. 各動画を文字起こしする
2. 内容がほぼ同じものをまとめる(撮り直しが混ざるため)
3. 1 本につき、投稿文(媒体ごと)とタイトル案を 3 つ作る
4. 内容に無いことを書かない(文字起こしに無い価格や効能を足さない)

## 出力
1 行 1 動画の表(ファイル名・要旨・投稿文・タイトル 3 案・重複の群)

審査で落ちない書き方

広告は、配信の前に媒体の審査を受けます。審査で落ちないように、実績には注意書きを添え、成果を約束する言い方は避けましょう(「必ず痩せます」ではなく「目指せます」)。期間とセットの実績(「1 か月で◯kg」など)は落ちやすいので、実績あり版と実績なし版の 2 本を用意しておき、審査に落ちたらすぐに差し替えられるようにしておきます。審査に落ちたときは、動画 → LP → 広告文の順に原因を探します。台本と LP の言葉・数字・商品名は、完全に一致させておきましょう。

4.5 LP: 設計 → 実装 → 画像 → 計測タグ → 検証

LP の成否はメッセージマッチと計測で決まる

LP(ランディングページ)とは、広告をクリックした人が最初に訪れるページのことです。LP の成否は、デザインでは決まりません。決めるのは、メッセージマッチ(広告と LP で同じことを言っているか)と、成果が正しく計測できているかの 2 点です。

LP の構成は、以下の 6 つの要素を基本にします。

  1. ファーストビュー(最初に表示される画面): バナーのコピーを引き継ぎ、最も強いベネフィットで「新しい気づき」を 1 つ足します
  2. 裏付け: 数字・グラフ・料金の比較表などです
  3. 比較または併用の提案: 比べる相手は競合ではなく、顧客がいま使っている身近なものにします。勝てない場合は「一緒に使いませんか」と提案します
  4. 権威・実績: あるかないかで申し込み率が大きく変わります。集めやすいのは、既存の顧客への満足度調査です
  5. お客様の声: 顔の表情が分かる写真を添えます。SNS の投稿を使うときは、本人の許可を取ります
  6. クロージング: 今申し込むべき理由と、ボタンの文言です

この 6 つで 70〜80 点の LP から始め、テストで点を上げていきましょう。LP のテストで新しい案が勝つのは 3 割程度が普通です。そのため、判定の基準を先に決めておき、負けたテストは早めに切り上げて次の案に進みます。

設計書を先に書き、いきなり HTML を書かない

AI にいきなり HTML を書かせると、メッセージマッチの確認が抜けてしまいます。先に設計書を出させ、以下の項目を必ず書かせましょう。

  • メッセージマッチの表(広告の一言 → ファーストビューの一言)
  • セクションの構成
  • 申し込みボタンの位置(ファーストビュー・中ほど・最後、スマホでは画面下に固定)
  • フォームの項目(項目の数は申し込み率に直結するので、削った項目とその理由も書く)
  • 離脱しそうな場所

競合分析や台本など、前の工程の成果物があれば先に読ませ、同じことを二度聞かないようにします。人に質問できない自動の実行では、分からない部分を仮の値で埋めて「これは推定です」と書かせ、最後まで作らせましょう。

流入元の関心度で、LP の長さを変える

設計書の最初には、成果(CV)の種類(フォーム送信・電話・LINE の友だち追加・予約・資料請求など)と、流入元の関心度を書きます。第三章で説明した関心度の 3 層のうち、SNS 広告から来る潜在層なら、共感や悩みの説明から入る縦長の構成にします。検索広告から来る顕在層なら、短い構成にして、フォームやボタンを上に置きます。同じ商材でも、流入元が違えば別の LP が必要になることがあります。

markdown
## 流入と CV
- 流入元: Instagram のリール広告(まだ探していない層)
- CV: LINE の友だち追加
- 長さ: 縦長。共感 → 課題 → 解決 → 証拠 → オファー → よくある質問 → CTA
- メッセージマッチ: 広告「昼休みにカット、会社から徒歩 3 分」
  → ファーストビュー「昼休みの 60 分で、カットまで終わる」
- 確認事項(推定): オファーの適用条件は与件に無いため、店舗に確認する

実装: 複数の案を作りやすくする

LP は、1 つの HTML ファイルで作ると軽く、受け渡しも複数の案の作成も楽です。守るルールは、広告費に直結するものだけに絞ります。スマホで見やすく作ること、スマホでは画面の下に申し込みボタンを固定すること、画像は必要になってから読み込むこと、重いフォントや大きな画像を使わないこと、の 4 つです。表示が遅いと、お金を払って集めた訪問者が、ページが開く前に帰ってしまいます。

複数の案を作りやすくするための工夫は 2 つあります。1 つ目は、見出し・サブコピー・ボタン・メインの画像・オファーのように差し替える箇所をコメントで囲み、新しい案は元の案を複製して、その箇所だけを書き換えることです。2 つ目は、成果を計測する処理を 1 つの関数にまとめ、計測タグの差し替えを 1 か所で済むようにすることです。

yaml
variants:
  - id: b
    note: 価格訴求
    slots:
      headline: "初期費用 0 円ではじめる集客"
  - id: c
    note: 実績訴求
    slots:
      headline: "導入〇〇店舗が使う集客の仕組み"

1 つの案で変える要素は 1 つだけにします。比べるときは同じ期間・同じ金額・同じクリエイティブで配信し、どちらかの成果が 50 件に満たないうちは勝ち負けを決めません。数十クリックの差は、偶然でも起きるからです。各案は URL のパラメータで区別し、計測にも案の名前を送りましょう。

もっと詳しく: スマホで見出しが切れていないかを確かめる

日本語の見出しは、単語の途中で改行されることがあります。意味の区切りで改行させようと、句に「改行しない」指定を付けることがありますが、長い句に付けると画面の幅からはみ出してしまいます。しかも、ファーストビューに「はみ出した部分を隠す」指定があると、横スクロールも出ないまま、右側の文字だけが切れてしまいます。画面を眺めても気づきにくいので、スマホの幅(例えば 390px)で開いたときに、各要素の右端が画面の内側にあるかを、ブラウザで要素の位置を測って確かめましょう。

html
<style>.nb { white-space: nowrap; }</style>
<!-- 改行禁止にする句は 8 文字程度まで -->
<h1>
  <span class="nb">平日の露天が</span><span class="nb">二人だけ</span>
</h1>

8 文字は、文字の大きさが 41.6px のときに約 333px で、390px の端末の本文の幅(約 350px)に収まる長さです。また、元の案を複製して新しい案を作ると、SNS でシェアされたときの画像(OGP)は元の案のまま残ります。シェアされることも狙うなら、案ごとに作り直しましょう。

画像: 3 つの作り方を用途で分ける

実際の店舗・スタッフ・料理・客室の画像は、クライアントから受け取った写真だけを使います。生成画像で代わりにすると、来店したときに「写真と違う」となり、クレームや低い評価の口コミにつながるからです。写真が無い部分は、写真が届くのを待つのではなく、構成を変えて対応しましょう。イメージビジュアル・背景・装飾は画像生成 AI で作り(4.3 節)、図解や料金表のように文字が主役の画像は、HTML で組んでヘッドレスブラウザで画像にします。

計測タグ: ダミーを入れない

計測タグとは、ページの訪問や申し込みを計測サービスに送るための短いプログラムのことです。GA4 の測定 ID、Meta のピクセル ID、Google タグマネージャーのコンテナ ID などがあれば、LP に埋め込みます。

問題は、ID がまだ無いときです。このとき、ダミーの ID を入れて動いているように見せることは禁止しましょう。タグが入っているように見えて何も送っていない状態は、まったく入っていない状態より気づくのが遅れるからです。配信を始めてから「申し込みが 0 件」で気づいても、それまでの広告費でどれだけ成果が出たのかは、もう分かりません。代わりに、ID を入れる場所を空けておき、納品の書類の最初に「計測が未設定なので、このまま配信すると成果が計測できない」と書いて、ID の発行手順を案内します。

また、広告のパラメータ(URL に付く utm やクリック ID)を拾って、フォームに隠し項目として入れる処理は、必ず入れておきましょう。これが無いと、申し込みがどの広告から来たのかを媒体の数字と照らし合わせることができません。

検証: 「書いた」と「動いている」は別

検証は 2 段階で行います。1 つ目は、タグの書き方や申し込みボタンの有無などをファイルの中身で確認する方法です。2 つ目は、ヘッドレスブラウザで実際に申し込みボタンを押し、計測のデータが送られることを確認する方法です。ブラウザが使えない環境では 1 つ目だけを行い、その理由を結果に書かせます。確認していないのに「動作を確認した」と報告させないようにしましょう。

検証の結果は、項目ごとに「問題なし/改善の余地あり/欠けている/あえて未設定」の 4 つで書かせ、欠けている項目が残ったまま「完成」と報告させないようにします。

LP を本番に公開する作業は、人が行います。参考サイトを複製したものは、構成の研究や試作には役立ちますが、そのまま公開してはいけません(著作権や利用規約の問題があります)。また、景品表示法(実在しない実績や声を書かない、「No.1」「最安」は根拠を示せないなら書かない)と薬機法(医療・美容・健康食品の効果を断定しない)の確認は、コピーを確定する前にクライアント側でも行ってもらいましょう。

もっと詳しく: 実際に著者が利用している広告の遷移先 LP を作る Skill を簡略化して添付したので参考にしてください

上で説明した設計 → 実装 → 画像 → 計測タグ → 検証の順番を、そのまま手順にしています。本番公開と既存ページの改善は持たせていません。「LP を改善して」という依頼でこの Skill が動くと、今のページを調べるのではなく、新しい LP を作り始めてしまうからです。

markdown
---
name: landing-page-builder
description: >-
  広告の遷移先 LP を、設計書 → 単体 HTML → 画像 → 計測タグ → 検証の順で作る。
  「LP を作って」「広告の遷移先ページが要る」「LP のバリアントを作って」
  「ファーストビューを作り直して」で使う。
  ※既存ページの診断と改善案は CRO 監査のスキル、参考サイトの複製はサイト複製のスキル。
  本番公開はこのスキルでは行わない(人が行う)。
---
# 広告の遷移先 LP を作る

## 手順
0. 前工程の成果物(競合分析・台本・ブランドの整理)を先に読む。同じことを二度聞かない
1. 与件を 1 回だけ確認する: CV の種類 / 流入元の広告 / オファー / 使える素材 / 計測 ID / バリアント数。
   答えが得られない自動実行では推定で埋め、設計書の冒頭に「確認事項(推定)」として列挙する
2. 設計書を書く(HTML より先)。必須: メッセージマッチ表、セクション構成、CTA の位置、
   フォーム項目と削った理由、想定される離脱ポイント
3. 単体 HTML で実装する。差し替える箇所は <!-- lp:headline --> のようなコメントで囲む。
   CV の発火は 1 つの関数に集める
4. 画像: 実店舗・実スタッフ・実料理は提供素材だけを使う。生成してよいのは抽象的な背景と装飾。
   文字が主役の図(料金表など)は HTML で組んで画像化する
5. 計測タグ: ID があれば埋め込む。無ければダミーを入れず、プレースホルダを残して、
   納品書類の冒頭に「計測未設定。このまま配信すると成果が計測できない」と書く
6. 検証: 静的チェックと、ブラウザで CTA を押して計測リクエストを観測する実発火チェック

## 縮退先
- ブラウザが使えない: 静的チェックだけを行い、結果に「実発火は未確認」と書く
- 画像生成の鍵が無い: HTML と CSS の装飾で組む。実在の写真の代わりに生成しない
- 素材が無い区画: 素材待ちで止めず、構成を変えて吸収する。足りない素材を一覧にして返す

## 納品物
- 設計書 / index.html(バリアントごと)/ 納品書類(計測の状態・生成画像の有無・確認事項)
- 検証の各項目は「問題なし/改善余地/欠落/意図的な未設定」で書く。欠落が残るものを「完成」と書かない

既存の LP を改善する(CRO)

すでにある LP の申し込み率を上げるための改善を、CRO(Conversion Rate Optimization)と呼びます。既存の LP は印象で語らず、以下の 8 つの観点で点数を付け、「直すと最も効く順」に並べましょう。

  • 見出しが分かりやすいか
  • 申し込みボタンが目立つか
  • 利用者の数や声などの裏付けがあるか
  • 今申し込む理由があるか
  • 信頼できる会社だと分かるか
  • フォームが入力しやすいか
  • スマホで見やすいか
  • 表示が速いか

点数はあくまで仮説で、効くかどうかは第三章で説明した実験で確かめます。また、ページを開けなかった観点は、点数を「悪い」ではなく「不明」として扱います。

直す順番は、効果の大きさと手間で決めます。効果が大きく手間が小さいのは、「バナーとファーストビューの言葉を揃える」「主張の裏付けを足す」です。効果が大きく手間も大きいのは、「権威・実績を集める」「比較・併用の提案を作る」です。画像の差し替えやボタンの文言の変更は、効果も手間も小さい改善です。

実際に AI に LP の監査をお願いしてみる

このLPを改善して。https://example.com/lp

「改善して」とだけ頼むと、ページを調べるのではなく、書き換えを始めてしまうことがあります。見る観点も AI 任せなので、翌月に同じ依頼をしても、前回と比べることができません。そのため、見る観点と返してほしい形を先に書いて、以下のようなプロンプトを AI に渡しましょう。

駅前の美容室の予約 LP(https://example.com/lp)を監査してください。ページの書き換えはまだ行いません。

【前提】
- 流入元は Instagram のリール広告。広告の最初のテロップは「昼休みにカット、会社から徒歩 3 分」
- 直近 30 日: LP の訪問 1,240 件、予約完了 18 件(予約システムの管理画面の数字)
- 訪問の 9 割はスマホから

【見る観点】
見出しの明確さ / CTA の視認性 / 社会的証明 / 緊急性 / 信頼シグナル / フォームの摩擦 /
モバイル対応 / 表示速度 の 8 つ。各観点に 0〜100 の点と、その点を付けた根拠(ページのどの部分か)を書く

【特に確かめること】
広告の最初のテロップと、ファーストビューの見出しが同じことを言っているか

【出力】
1. 観点ごとの点数と根拠の表
2. 改善案を「効果の大きさ × 工数」で並べた表(上位 5 件まで)。各案に変更前と変更後の文言を付ける
3. 実験として試すなら、どの案から始め、何を判定基準にするか

【守ること】
- ページを取得できなかった観点は点を付けず「不明」と書く
- 点数は仮説として書く。「この変更で CVR が◯%上がる」とは書かない
- 口コミや実績の追加を提案するときは、実在の声を集める方法まで書く。例文の口コミを作らない

最初の「書き換えはまだ行いません」は、作業を調べることだけに限るための一文です。広告の文言と実際の数字を渡しておくと、メッセージマッチの確認と改善案の順番に根拠が付きます。最後の行は、例として作った口コミがそのまま LP に載ってしまうのを防ぐためのものです。架空の声を載せると、景品表示法の問題になります。

もっと詳しく: 実際に著者が利用している LP の改善監査の Skill を簡略化して添付したので参考にしてください

この Skill は調べて点数を付けるだけで、ページは書き換えません。依頼文に「書き換えはまだ行いません」と書き忘れたときにも、書き換えが始まらないようにするためです。また、観点を Skill に固定しておくことで、毎月同じ観点で比べられるようにしています。

markdown
---
name: cro-audit
description: >-
  既存の LP ・遷移先ページを 8 観点で監査し、点数と直す順番を出す。
  「LP を改善して」「CVR が低い原因」「フォームの離脱」で使う。
  ※LP の新規作成は LP 生成のスキル、記事の SEO 診断は記事監査のスキル、
  実験として回すなら実験のスキル(第 3 章)。
---
# LP の改善監査

## 手順
1. 流入元と関心度を確かめる(これで適切な長さが変わる)
2. 8 観点で採点する(ファーストビュー・メッセージの一致・証拠・オファー・
   フォーム・導線・表示速度・スマホ表示)
3. 直す順番を、効果 × 手間で並べる(上位 3 つに絞る)
4. CV が少ないページは、手前の行動(スクロール・フォーム着手)で判定する

## 守ること
- 点数の根拠は実数に紐づける(「導線が弱い」ではなく「ボタンが 3 画面目に 1 つ」)
- 計測が入っていないページは、評価の前に計測を入れる提案を先に出す

点数の次に見る数字

8 つの観点の点数は、見るべき場所を絞るためのものです。実際にどこで離脱しているかは、ヒートマップ(ページのどこまで読まれ、どこが押されたかを色で表示する計測の道具)の数字で確かめます。著者が使っている目安は、以下のとおりです。流入の種類によって適正な値が大きく変わるので、必ず流入の種類ごとに見ましょう。

流入の種類ファーストビュー通過率の目安
検索広告80〜90%
サイト訪問者への再表示広告60〜80%
年齢・性別などで絞った配信30〜50%
絞り込まない配信20〜30%

ファーストビュー通過率は、ファーストビューのすぐ下までスクロールした人の割合です。申し込みボタンは、ボタンまで届いた人のうち押した人の割合で見ます。目安は 5〜15% です。また、料金表・お客様の声・よくある質問の 3 つはよく読まれるので、ページの下のほうにあって 1 割しか届いていないなら、上に移す候補になります。

ヒートマップは、申し込んだ人だけに絞って読みましょう。全員の動きで見ると、大多数を占める申し込まなかった人に合わせてページを直すことになってしまいます。また、A/B テストの最中は 2 つの案の数字が混ざるので、「テスト → 勝った案を反映 → ヒートマップで次の案を探す → テスト」の順番で進めます。

予約 LP のヒートマップ(直近 30 日)を読んで、次に試す改善案を 3 つ出してください。
【前提】
- 分析は「予約を完了した人」だけに絞ったデータで行う。全訪問者のデータは参考として並べるだけ
- A/B テストは先週終了し、勝った案を反映済み。反映後のデータだけを使う
- 流入はほぼ Instagram の広告(年齢と地域で絞った配信)
【見ること】
1. ファーストビューの直下まで進んだ割合。目安(30〜50%)と比べる
2. CTA まで届いた人のうち押した人の割合。目安(5〜15%)と比べる
3. 料金表・お客様の声・よくある質問に何割が届いているか
【出力】
数字の表と、改善案 3 つ。各案に「どの数字を動かすための案か」を書く

GA4 で LP の中の動きを読む

ヒートマップは別に契約が必要なことが多く、すべての案件で使えるとは限りません。そのような場合は、GA4(Google アナリティクス 4。Google の無料のアクセス解析サービス)を使います。GA4 なら、「どこから来た人が、ページのどこまで進み、どこで止まったか」を、流入元とスマホ・PC の別ごとに数えることができます。

ただし、GA4 は入れただけでは必要な数字が取れません。GA4 が自動で記録するスクロールは、ページの 90% まで進んだときだけなので、ファーストビューのすぐ下まで届いたかは分かりません。申し込みボタンを押したことも、料金表まで届いたことも、自動では記録されません。そのため、LP の側から、必要な行動を GA4 に送る設定(イベント)を自分で追加します。

読み方は、「ページを開いた → ファーストビューの下まで進んだ → ボタンまで届いた → ボタンを押した → フォームに入力し始めた → 申し込んだ」の 6 段階の通過率を、流入元とスマホ・PC の別ごとに並べ、どの段階で最も人が減っているかを見ます。直す場所は、最も減っている段階の 1 つ手前です。例えば、ファーストビューの下で減っているなら見出しとメッセージマッチ、ボタンまで届いているのに押されていないならボタンの文言と位置、フォームで減っているならフォームの項目数を見直します。

もっと詳しく: GA4 に送るイベントと、数字を読むときの注意

著者の会社では、次の 4 つのイベントを送っています。名前は LP をまたいで固定し(毎回変えると比べられません)、すべてのイベントにどの案かを示す variant を付けています。

イベントいつ送るかパラメータ
section_view区画が画面に入ったとき(1 訪問につき区画ごとに 1 回)section(fv_below / price / voice / faq / cta_bottom など)、variant
cta_clickCTA を押したときposition(fv / mid / bottom / sticky)、variant
form_startフォームに最初に触れたとき(GA4 の拡張計測が送る既定のものでよい)variant
最終 CV(reserve_complete など)予約完了・フォーム送信・LINE の友だち追加ボタン・電話番号のタップvariant。GA4 の管理画面で「キーイベント」に登録する(旧「コンバージョン」。2024 年に改名され、API でも keyEvents になった)

パラメータは、GA4 の管理画面で「カスタム ディメンション」として登録しないと、表にも API にも出てきません。登録した日より前のデータは後から取れないので、計測タグを入れるときに一緒に登録しておきましょう。

GA4 の数字を読むときは、次の 4 つに注意してください。

  • GA4 の数字は、実際より少なめに出ます(計測を拒否した人や、広告をブロックしている人がいるため)。人数そのものではなく、段階ごとの割合で比べましょう
  • 媒体が報告する申し込みの数と GA4 の数は、数え方が違います。照らし合わせたり合計したりせず、並べて出すだけにします
  • 数字が確定するまで 24〜48 時間かかります。直近 2 日の数字は判断に使いません
  • 人数の少ない行は、GA4 が伏せて表示しないことがあります。伏せられた行は 0 ではなく「未取得」として扱います。また、率は API では 0〜1 の値で返り、画面では % で表示されます。どちらで取った値かを表に書き、100 倍を 2 回しないようにしましょう

以下は、GA4 の数字から直す場所を探してもらうときのプロンプトの例です。イベントの名前は LP ごとに決めるものなので、前提としてプロンプトに書いておきます。

予約 LP(/lp/lunch-cut)の GA4 データを読んで、直す場所を 3 つまで出してください。期間は直近 28 日で、未確定の直近 2 日は除きます。
【前提】
- イベント: section_view(section = fv_below / price / voice / faq / cta_bottom)、cta_click(position = fv / mid / bottom / sticky)、form_start、キーイベント reserve_complete。全イベントに variant がある
- 流入はほぼ Instagram のリール広告(年齢と地域で絞った配信)。訪問の 9 割はスマホ
- A/B テストは先週終了し、勝った案(variant = b)を反映済み。b のデータだけを使う
【見ること】
1. 流入元 × 端末ごとに、ページ表示 → fv_below → cta_bottom → cta_click → form_start → reserve_complete の各段の通過率
2. ファーストビュー通過率を目安(30〜50%)と、CTA まで届いた人のクリック率を目安(5〜15%)と比べる
3. reserve_complete に至った人と至らなかった人で、price / voice / faq に届いた割合がどう違うか
【出力】
段ごとの通過率の表(流入元 × 端末)と、直す場所 3 つ。各案に「どの段の数字を動かすための案か」を書く
【守ること】
- しきい値で伏せられた行は 0 ではなく「未取得」と書く
- 媒体の管理画面の CV 数と reserve_complete の数を突き合わせない(数え方が違う)。並べて出すだけにする
- 率は 0〜1 の生値のまま表に出し、% に直すのは本文だけにする

申し込みが少ない LP は、その手前の行動で判断する

予約や購入が月に数件しかない LP では、A/B テストの勝ち負けがいつまでも決まりません。そのようなときは、最終的な成果の手前で必ず起きる行動(マイクロ CV)で判断します。

サイトの種類マイクロ CV最終 CV
通販サイトカートへの追加購入完了
フォーム一体型の LPフォームの入力開始申し込み完了
企業向けのサイト入力フォームの表示問い合わせ
店舗の紹介サイト所在地・行き方のページの表示来店

ただし、使えるのは、その行動が増えれば最終的な成果も増える行動だけです。ボタンを押しやすくしただけで購入にはつながらない行動を基準にすると、数字だけが良くなってしまいます。

思い込みで外しやすい改善

  • ファーストビューの申し込みボタンは、安い商品や、すでに知っている人が来る場合には効きます。高価でまだ知られていない商品では逆効果になることがあり、ボタンを外して読ませたほうが申し込み率が高かった例もあります
  • 価格もテストの対象です。値下げより、価格はそのままで内容量やセットの組み方を変えるほうが、損を出しにくいです
  • 通販サイトのトップページを、広告のリンク先にしないようにしましょう。情報が多すぎて離脱が増えるので、商品の詳細ページを LP の代わりに改善します(ブランド名で検索した人への検索広告は例外です)
  • 負けた案も捨てずに記録しておきます。季節や競合が変わると、以前負けた案が勝つことがあります

アンケートから、連絡先と引き換えに渡す特典を作る

第三章で説明したアンケートの分析は、LP でも使えます。既存の顧客や見込み客のアンケートがあれば、連絡先と引き換えに渡す資料や特典(リードマグネット)の材料になります。自由記述の回答を悩みごとに分け、件数の多い悩みから順に特典を考えましょう。数百件までなら、AI に回答を読ませて分ける方法で十分です。ただし、統計的な方法で分けたのか、AI が読んで分けたのかは、成果物に必ず書かせてください。

添付のアンケート(温泉旅館の宿泊者 320 件、CSV)を読んで、
予約前の人に渡す特典の企画を作ってください。
1. 「予約前に不安だったこと」の列を全件読み、繰り返し出てくる悩みで分ける
2. 分けた悩みごとに件数を数え、多い順に並べる
3. 上位 3 つの悩みに、特典の案を 1 つずつ書く(題名・形式・中身の項目・渡す場所)
4. 成果物の冒頭に「読んで分類したもので、統計的な分類ではない」と書く
5. 読み切れなかった場合は、読んだ件数と範囲をそのまま書く

著者の環境では、生成した LP は成果物の一覧に自動で並び、検証の結果もそこに表示されます。「計測が未設定」の LP は一覧の時点でそう表示されるので、承認の場で見落とされることがありません。「完成しました」という報告文だけを信じる仕組みにすると、欠けている項目は承認のときまで気づかれません。

章のまとめ

  • クリエイティブは「訴求軸 × 型 × 媒体」の組み合わせに分けて量産し、初回は 5 本、次からは 1 か所ずつ変えて検証します。どの訴求軸を選ぶかは人が決めます。また、「どのクリエイティブから、何を 1 つ変えたか」をメタデータとして残しておきましょう。
  • コピーは、ペルソナ → ベネフィット → 訴求軸 → 型の順に考えます。オファーはコピーより先に決め、景品表示法の論点は AI に断定させず、人が確認しましょう。
  • バナーは「要素 → 構成 → 仕上げ」の順に作り、画像生成 AI には文章ではなく JSON の設計書を渡します。生成した画像の文字は必ず目で読み、誤字が 1 文字でもあれば作り直します。
  • 生成したものには、「何をどのモデルに頼んだか」の来歴を、生成するプログラムが自動で書くようにします。実在の店舗・スタッフ・料理・客室を、生成画像で代わりにすることはしません。
  • 動画は、フックだけを変えて本編と CTA を固定し、冒頭 3 秒で何の動画か分かるように作ります。作り方は手持ちの素材で選び、素材が無くても「作れません」で終わらせないようにしましょう。
  • LP の成否は、メッセージマッチと計測で決まります。設計書を先に書き、計測タグにはダミーを入れず、実際にボタンを押して計測のデータが送られることまで確認しましょう。
  • 既存の LP は 8 つの観点で点数を付け、ヒートマップや GA4 で「どの段階で人が減っているか」を確かめてから直します。申し込みが少ない LP は、その手前の行動で判断します。

演習

  1. 自社の直近 20 本のクリエイティブに、訴求軸・型・媒体・版の 4 つを後から記録してみましょう。記録できなかったものが、いま検証できていない部分です。
  2. 最も成績の良かったバナーを 1 本選び、JSON の設計書に書き起こしてみましょう。位置・文言・制約の 3 つが書ければ、そのバナーは同じ条件で作り直すことができます。
  3. 自社の LP で申し込みボタンを押し、計測タグが実際にデータを送っているかを、ブラウザの開発者ツールで確かめてみましょう。「入っている」と「送っている」の違いを確認するための演習です。
  4. 最近作った動画を 1 本選び、この章の「動画の種類ごとに何を決めるか」の表に当てはめてみましょう。最初に決めるべきだったことが、依頼の文面に書かれていたかを確かめてください。

次の章へ

この章では、コピー・バナー・動画・LP を AI で作る方法を説明しました。次の第五章「広告運用を自動化する」では、作ったクリエイティブを媒体に入稿して配信し、実績を取得してレポートにするまでを解説します。