OCEAN JOURNAL 社内備忘録 / 32

クリエイティブ / Web品質

LP・バナーの品質を、根拠と改善案で見る。自作診断プラグインの設計。

見た目の採点で終わらせない。ペルソナの疑似訪問、6軸評価、想定CVRの条件、改善バックログまでをつなぐ、自作Chrome拡張の中身を図解します。

実践記録:記録・編集:株式会社オーシャン

「なんとなく良い」を、直せる指摘に変える。

LPやバナーのレビューで困るのは、好みの感想だけが残ることです。「弱い」「分かりにくい」と言われても、どの要素が、誰に、どう影響しているかが分からなければ修正できません。そこで、対象とする人の見方、画面上の根拠、改善する順番をつなぐ診断ツールを自作しました。

Chrome拡張として、LPの画面取得と、バナー画像の入力に対応しています。AIが画像と取得情報を読み、結果を構造化して返す。点数だけを出すのではなく、指摘の場所、理由、改善案まで見られる形です。ここでは実装された入力画面と、内容を説明する図を掲載します。

FIGURE 01診断から、改善の仕事へ
  1. 条件を決める誰が・何を・どこから
  2. 画面を読む実画像と取得情報を照合
  3. 根拠を出す場所・理由・改善案
  4. 実測へ戻す修正・配信・検証

診断の前に、誰が何をしに来るかを決める。

同じページでも、初めて広告から来る人と、社名を検索して来る人では、知っていることが違います。無料の資料請求と有料の購入でも、必要な信頼材料や行動の負担は変わります。診断では、ペルソナ、業種、オファー、流入、デバイスなどの条件を入力します。

結果を比較するときは、こうした条件をそろえます。条件が違うのに点数だけを比較すると、デザインの差なのか、想定した訪問者の差なのかが分かりません。競合比較も、同じ条件で見て初めて改善の参考になります。

FIGURE 02自作Chrome拡張の入力画面
LP診断とバナー診断の入力画面。ペルソナ、業種、オファー、配信媒体などの条件を指定する。

実装済みUIを公開用の入力例で撮影。実案件のデータや診断結果ではありません。 画像を選ぶと拡大して見られます。

LPは疑似訪問、バナーは6つの軸から見る。

LPでは、最初に何が目に入り、どの疑問が解消されず、どこで行動をためらうかを、ペルソナの疑似訪問として整理します。これは実際のユーザーを計測した結果ではなく、改善点を探すためのシミュレーションです。視線計測や実ユーザーテストの代わりと考えないことが前提です。

バナーでは、視覚の優先順位、配置、文字、色、コピー、行動の導線という6軸を使います。0.5秒、1〜2秒、3秒という段階は、瞬間的な視認から内容理解、行動判断までを考えるための枠組みです。すべての人がこの時刻どおりに行動するという測定値ではありません。

FIGURE 03バナーを見る6つの軸
  • 視覚の優先順位何が最初に目に入るか
  • 配置余白・整列・要素の関係
  • 文字読みやすさ・大きさの差
  • 色ブランドとコントラスト
  • コピー一つの価値が伝わるか
  • 行動の導線次に何をするか分かるか

想定CVRは、前提を持つ推定値として扱う。

CVRは、訪問に対して購入や問い合わせなどが起きる割合です。ツールの想定CVRは、業種の基準に、オファー、流入、デバイス、品質、ペルソナ、行動の摩擦などの係数を掛け合わせ、範囲として出す設計です。公開ベンチマークを参照した較正であって、個々のページの将来の成果を保証する値ではありません。

大事なのは、なぜその見立てになったかが追えることです。入力条件が変われば推定も変わります。公開前の仮説づくりに使い、公開後にはGA4等の実測やA/Bテストと照らして見直す。推定値を実績のように広告へ載せるための道具ではありません。

FIGURE 04想定CVRの前提を、分解して見る
  1. 基準業種と行動の種類
  2. 訪問条件流入・デバイス・ペルソナ
  3. ページ条件品質・不安・行動の負担
  4. 推定範囲コードで整合を確認

推定の構造を示す図。実測値、改善率、成果保証ではありません。

AIの暗算に任せず、数値はコードで確かめる。

開発中の検証では、AIが説明した式と結果の数字が一致しないケースがありました。そこで、CVRの内訳や総合点などをコード側で再計算する形へ整理しています。AIには画像上の根拠と判断を出させ、計算の整合は別の仕組みで確認する設計です。

入力画像も確認対象です。長いページの撮影が途中で重複する、採点表付きの画像を入力してしまう、といった問題があると診断の前提が崩れます。撮影できなかった範囲は未確認として扱い、見えていないことを断定させない工夫を加えています。

FIGURE 05AIの判断と、コードの確認を分ける
  • AIが読む画面上の根拠/訪問者の疑問/改善案
  • コードが確かめる係数の積/総合点/入力の整合/結果の形式

指摘を、次に直す仕事へ変える。

結果には、画像上の注釈、改善案、優先順位を付けます。さらにMarkdownやCSVで改善バックログとして取り出し、制作側へ渡せるようにしています。採点レポートを眺めて終わらず、何から直すかを決めるためです。

広告媒体のルールに照らした事前チェックもありますが、最終的な審査を保証する機能ではありません。また、改善画像を生成する連携も実装されていますが、今回の記事では全環境での実生成を検証済みとは扱いません。公開前には、最新の媒体ルール、文字やロゴ、実際の表示を人が確認します。

FIGURE 06改善バックログへ渡す情報
  • 対象どの画面・どの要素か
  • 根拠何を見て問題としたか
  • 修正案何をどう変えるか
  • 検証公開後に何を測るか

成果は、配信後の数字で確かめる。

このツールの狙いは、正解の点数を言い当てることではなく、改善の仮説を具体化することです。「CTAが弱い」から一歩進み、どこでためらうか、何を変えるか、どう測るかまでつなげる。オーシャンのクリエイティブと実装の間を支える道具として育てています。

改善後は、同じ流入条件で実際の行動を見ます。問い合わせ数だけでなく、その前の到達やクリック、入力時の離脱も確かめる。診断、制作、配信、実測の循環が回って初めて、ツールの価値を評価できます。

FIGURE 07診断を、運用の循環へ
  1. 仮説根拠つきの改善案
  2. 制作見た目と情報を修正
  3. 配信条件をそろえて試す
  4. 実測結果を次の判断へ戻す

TALK WITH OCEAN

課題の整理から、実装まで。

まだ仕様や依頼内容がまとまっていなくても、まずは経営や現場で気になっていることからお聞かせください。

経営の悩みを相談する このテーマに関連するオーシャンの取り組みを見る →

オーシャンの社内備忘録を、人とAIで整理・編集しています。クライアントを特定できる情報は掲載していません。説明用に再構成した図や画面は、その旨を記載しています。

公開:。記録の日付は題材となった実践・検討の時点です。

経営実装ノート(社内備忘録)の記事一覧へ