この記事の対象: サイト改善の打ち手をAIと詰めたい制作者・発注者
読了時間: 約12分
GA4の画面をスクリーンショットして「改善点を教えて」と投げると、だいたい「直帰率が高いのでファーストビューを見直しましょう」が返ってきます。間違ってはいないけれど、それを実装しても数字は動きません。原因は、AIが数字しか受け取っていないことにあります。数字は「何が起きたか」しか語らず、「それが良いことなのか悪いことなのか」はサイトの目的が決めます。この記事では、制作の現場でGA4のデータをAIに読ませてサイト改善の打ち手を作るときに、何を先に渡すと使える答えが返るのかを、実際に投げているプロンプトの形で整理します。
AIのGA4分析が一般論で終わる理由は「前提の欠落」にある

数字だけを渡すと、平均への回帰が返ってくる
AIは、渡された情報の範囲でもっともらしい答えを作ります。指標の名前と数値しか渡していなければ、「その指標が一般にどうあるべきか」という材料しか持てません。結果として、どのサイトに投げても同じ答えが返ります。
現場でよく見る「使えない答え」は次の3つです。
| 返ってきた答え | なぜ使えないか |
|---|---|
| 直帰率が高いのでファーストビューを改善 | どのページの直帰が問題なのかが特定されていない |
| CVRが低いのでフォームの項目を減らす | そもそもフォームが主要導線かどうかを知らない |
| モバイル比率が高いのでモバイル最適化を | すでに対応済みでも同じ答えが出る |
3つ目が特に厄介で、AIは「もう対応済みかどうか」を知らないまま提案します。読ませる前に現状の実装を伝えていないので、当然といえば当然です。
サイトの目的によって、同じ数字の意味が反転する
滞在時間が短い。これは悪いことでしょうか。
- 採用サイトの募集要項ページ → 短いのは問題。条件を読み込む前に離脱している
- 店舗サイトのアクセスページ → 短いのは正常。地図を見て電話するのが完了行動
- ECの商品ページ → 短くてカートに入っていれば優秀。短くて離脱なら問題
同じ「滞在時間30秒」が、3つの解釈に分かれます。この分岐を決めているのはサイトの目的とページの役割であって、数字そのものではありません。だからAIに渡すべき一番目の情報は、数字ではなく目的です。
数字を最後に置くのが要点です。①〜③を渡さずに④だけ投げるから、一般論が返ってきます。
GA4のデータをAIに渡す前に固める4つの前提

以下のコードブロックに出てくる業種・目標値・日付は、書き方を示すための記入例です。実際の数字はご自身のサイトのものに置き換えてください。
前提1|コンバージョンの定義を言葉で書く
GA4のキーイベント名だけを渡しても、AIには何が起きたのか伝わりません。form_submit というイベント名から、それが資料請求なのか、問い合わせなのか、見積依頼なのかは読み取れないからです。
渡すときはこの形にします。
【サイトの目的】(記入例)
BtoB向け製造装置メーカーのコーポレートサイト。
最終ゴールは問い合わせフォームからの技術相談。
月間の問い合わせ目標は8件。うち商談化するのは例年3〜4割。
【キーイベントの意味】(記入例)
- contact_submit … 問い合わせフォーム送信(=ゴール)
- catalog_download … 製品カタログPDFのDL(=中間指標。昨年度は約2割が問い合わせに転換)
- tel_tap … スマホでの電話番号タップ(=計測はしているが商談化率は不明)
中間指標に「どれくらいゴールにつながるか」を添えるのがポイントです。これがないと、AIはカタログDLとフォーム送信を同じ重みで扱い、「DL数を増やしましょう」という筋の悪い提案を返してきます。
転換率が分からない中間指標は、分からないと書いてそのまま渡します。空欄を避けて適当な数字を入れると、その数字を前提に優先順位が組まれてしまい、あとから誰も気づけません。
前提2|サイト構造とページの役割を渡す
ページのURLとPV数だけ並べても、AIにはサイトの形が見えません。「/product/ の直下に12ページある」ことと、「そこがCVへの主要導線である」ことは別の情報です。
/product/(製品一覧・主要導線)
- /product/xx/(個別12ページ・CTAあり)
- /product/compare/(比較表・CV直前に見られている想定)
/case/(導入事例・信頼形成)
- 個別8ページ・CTAあり
/contact/(ゴール・CTAなし)
/recruit/(採用・CVは別系統)
「CTAあり/なし」と「CVは別系統」を書き添えるだけで、AIの提案先が絞れます。
採用ページを「別系統」と明記しておかないと、採用のPVが多い月に「採用ページからの導線を強化」という提案が混ざります。BtoBの技術相談を増やしたい話に、求職者の動線が混ざり込むわけです。
構造を渡すときに、もうひとつ効くのが想定していた導線を文章で書くことです。「トップ→製品一覧→個別製品→問い合わせ」と書いておくと、AIは実測の経路をその想定と突き合わせて「想定と違う入り方が多い」という形で差分を返してきます。想定を渡さなければ、経路データは単なるセッション数の羅列です。
前提3|期間と比較対象を必ず指定する
「先月の数字です」だけでは、AIは判断の軸を持てません。比較対象を指定して初めて、増減の意味が出ます。
| 比較の型 | 何が分かるか | 向いている場面 |
|---|---|---|
| 前月比 | 直近の施策の効き方 | 広告やキャンペーンを打った直後 |
| 前年同月比 | 季節性を除いた実力 | BtoB、季節商材、年間で波があるサイト |
| リリース前後 | 改修の影響 | サイトリニューアル・LP差し替え後 |
| ページ間の横比較 | どのページが弱いか | 同じ型のページが複数ある場合 |
BtoBサイトで前月比だけを見て「8月は問い合わせが減った」と騒ぐのは、ほぼ毎年の恒例行事です。お盆で稼働日が減っているだけのことが多い。前年同月比を並べて渡せば、AIも季節性の可能性を候補に挙げてきます。逆にいうと、前年同月のデータを渡していないのにAIが「季節性でしょう」と言ってきたら、それは推測を断定の形で出しているだけなので、そのまま受け取ってはいけません。
比較期間を決めるときは、改修日・広告の出稿開始日・展示会の日程をまたいでいないかも一緒に確認します。期間の真ん中でサイトが変わっていると、前後を平均した数字になり、どちらの実力も分からなくなります。またいでいる場合は、期間を割って2本渡すほうが早いです。
前提4|すでにやったことを渡す
抜け落ちやすいのがここです。過去の改修履歴を渡さないと、AIは毎回まっさらな状態から提案するので、去年やったことをもう一度提案してきます。
【直近の改修履歴】(記入例)
- 2026-03 スマホのグローバルナビをドロワー化
- 2026-05 製品ページ下部にCTAブロックを追加(全12ページ)
- 2026-07 問い合わせフォームの入力項目を11→7に削減
【やらない/やれないこと】(記入例)
- 価格の公開(社内方針で不可)
- チャットボットの導入(保守体制がない)
「やれないこと」を書いておくと、実装できない提案が返ってこなくなります。制作会社としては、これを書いておくだけで打ち合わせ資料の作り直しが1回減ります。
試して効かなかったことも履歴に残します。「CTAの色を変えたが変化なし」の1行があるだけで、AIの提案は配色の話から構造の話に移ります。効かなかった施策は、効いた施策と同じだけ情報量があります。
実際に投げるプロンプトの型

そのままコピーして使えるテンプレート
上の4前提をまとめると、次の形になります。GA4の探索レポートをCSVで書き出して添付するか、表をそのまま貼り付けて使います。
あなたはWeb制作会社のアナリストです。以下のサイトのGA4データを読み、
改善施策を優先順位付きで提案してください。
# サイトの前提
- 業種/ターゲット:
- サイトの目的(何が起きたら成功か):
- 月間のCV目標:
- キーイベントとその意味:
- 主要導線(トップ→どこ→どこ→CV):
- CVに関係しないセクション(例:採用、IR):
# 実装の現状
- 直近12ヶ月の改修履歴:
- 過去に試して効かなかったこと:
- 実装上できないこと/社内方針で不可なこと:
# データ
- 期間:2026-08-01 〜 2026-08-31
- 比較対象:2025-08-01 〜 2025-08-31(前年同月)
- 指標:(以下に貼り付け)
# 出力の指示
1. 数字から確実に言えることと、推測にすぎないことを分けて書く
2. 推測には「これを確かめるには何を見ればよいか」を添える
3. 施策は「実装コストが小さく効きそうな順」に並べる
4. データが足りなくて判断できない項目は、無理に埋めずに「不足」と書く
出力の指示の4項目が本体です。 特に1と4を入れるかどうかで返ってくるものが変わります。入れないと、AIは全部の欄を埋めようとして、根拠のない断定を混ぜてきます。
「確実に言えること/推測」を分けさせる効果
この指示を入れると、返ってくる形がこう変わります。
指示を入れた場合
- 「比較表ページの離脱率が、他の製品ページより十数pt高い」=事実
- 「比較表がスマホで読みにくい可能性」=推測
- 「確かめるにはスクロール深度イベントを追加」=検証方法
指示を入れない場合
- 「比較表がスマホで読みにくいため離脱している」
- 事実と推測が1文に混ざる
- 検証せずに改修に入ってしまう
右側の書き方が危ないのは、断定されると検証工程が飛ぶからです。読みにくいのかもしれないし、比較して納得して問い合わせに行った結果かもしれない。数字だけでは区別がつきません。
前提を渡す前と後で、返ってくる答えはこう変わる

言葉で説明するより、同じデータで2回投げた結果を並べたほうが早いです。以下は前掲の記入例(BtoB製造装置メーカー・仮のサイト)で、渡したデータは同じ、前提の有無だけを変えた場合の典型的な差です。
渡したデータ(共通)
| ページ | 表示回数 | エンゲージメント率 | 備考 |
|---|---|---|---|
| / | 多い | 中 | トップ |
| /product/ | 中 | 高 | 製品一覧 |
| /product/compare/ | 少ない | 低 | 比較表 |
| /case/ | 中 | 高 | 導入事例 |
| /recruit/ | 多い | 中 | 採用 |
前提なしで投げたときに返ってくるもの
- 「/recruit/ の表示回数が多いので、採用ページからの回遊を強化しましょう」
- 「/product/compare/ のエンゲージメント率が低いので、コンテンツを充実させましょう」
- 「直帰率の改善のためファーストビューの見直しを」
1つ目は、CVと無関係な系統への提案です。2つ目は、比較表が「見て納得したら次に進むページ」である可能性を考えていません。3つ目は、そもそも渡していない指標の話をしています。
前提つきで投げたときに返ってくるもの
- 事実として:製品一覧のエンゲージメントは高いが、比較表を経由するセッションが少ない
- 推測として:比較表への入口が製品一覧の下部にしかなく、見つけられていない可能性
- 検証方法:比較表への遷移元を経路データ探索で確認し、製品一覧内のリンク位置別にクリックを取る
- 施策:個別製品ページの上部に比較表へのリンクを追加(工数小)/比較表のスマホ表示を検証(工数中)
- 不足:採用は別系統のため本分析の対象外。
tel_tapの商談化率が不明なため、電話導線の評価は保留
違いは「賢さ」ではありません。採用を対象外と書いたこと、比較表の役割を書いたこと、分からない指標を分からないと書いたこと——この3つが、提案の宛先を絞り、保留すべきものを保留させています。
GA4のどのレポートを渡すか
全部渡す必要はありません。目的別に絞ったほうが、返ってくる答えの精度が上がります。
| 知りたいこと | 渡すレポート | 一緒に渡す前提 |
|---|---|---|
| どのページが弱いか | ページとスクリーン(表示回数・エンゲージメント率・離脱) | 各ページの役割とCTAの有無 |
| どこから来た人が成約するか | トラフィック獲得+キーイベント | 広告の出稿状況・出稿額の有無 |
| どこで落ちているか | 探索の経路データ探索 | 想定していた導線 |
| デバイス差 | 端末カテゴリ×キーイベント | レスポンシブの実装状況 |
| 検索からの入り方 | Search Consoleの連携レポート | 狙っているキーワードと対応ページ |
探索の経路データ探索は、AIに渡すときにCSVよりも「トップ→A→B→離脱:◯セッション」の形に整形したほうが読み違えが減ります。GA4のCSVは列構造が独特で、ヘッダー行より上にメタ情報の行が入るため、そのまま貼ると集計軸を取り違えることがあります。貼る前に、1行目が列名になっているかだけ見ておけば事故は減ります。
なお、GA4だけで足りるのか、ヒートマップなどの補助ツールが要るのかは別の判断です。
AIの答えを鵜呑みにしないための判断軸

数字の出どころを疑う3つのチェック
AIの分析が的外れなとき、AIが悪いのではなく元データが壊れているケースが相当あります。読ませる前に確認しておく項目です。
- 計測が二重になっていないか — GTMとgtag.jsの両方が入っていると、PVもイベントも倍になります。数字が急に跳ねた月があれば、まずこれを疑います
- キーイベントが実際に発火しているか — フォーム送信後のサンクスページで計測している場合、フォームをAjax化したタイミングで無言で止まります。「先月から急にCVが0」はほぼこれ
- 除外設定が入っているか — 社内IPと制作会社のIPを除外していないと、更新作業のPVが混ざります。ページ数の少ないサイトほど影響が大きい
3つ目は制作側の実感として大きく、月間セッションが小さいBtoBサイトでは、社内と制作会社の確認作業が無視できない割合を占めることがあります。それを含んだ数字をAIに読ませると、「トップページのPVは多いが回遊しない」といった、実態のない分析が返ってきます。
この3つは、AIに判定させるより自分で実物を見たほうが速い項目です。タグの二重は公開ページのソースを見れば分かり、イベントの停止はリアルタイムレポートで自分が1回送信すれば分かります。
AIの答えを採用してよい条件
制作の現場では、返ってきた提案をそのままクライアントに出すことはしません。次の3つを通してから使います。
③が見落とされがちです。「事例ページを見た人のCVRが高い」から「事例ページへの導線を強化しよう」と結論づけるのは、因果が逆の可能性があります。もともと検討度が高い人が事例ページを見に行っているだけなら、導線を太くしても検討度の低い人が流れ込むだけで、CVRは下がります。
AIはこの手の相関と因果の取り違えを、堂々とした文体で返してきます。文体が自信ありげであることと、根拠が強いことは無関係です。
②も実務では効きます。「比較表のスマホ表示を改善」と言われても、スクロール深度や要素の表示イベントを取っていなければ、改修後に良くなったのか分かりません。その場合は改修より先に計測を入れるのが正しい順番で、AIの提案リストを計測の追加タスクに書き換えることになります。
実装に落とすときは工数と効果を分けて考える
AIが出した施策を「効きそうな順」に並べただけでは、着手できません。制作側では、次の2軸で並べ替えます。
| 施策 | 実装工数 | 効果の確度 | 判断 |
|---|---|---|---|
| CTAの文言変更 | 小 | 中 | すぐやる |
| フォームの項目削減 | 小 | 高 | すぐやる |
| 比較表への内部リンク追加 | 小 | 中 | すぐやる |
| 事例ページの構成刷新 | 大 | 中 | 検証してから |
| サイト全体のIA再設計 | 特大 | 不明 | リニューアル時に |
「実装工数が小さく、効果の確度が中以上」から着手するのが基本です。ここを飛ばして「IA再設計が必要です」という提案に飛びつくと、リニューアル案件の話になって半年止まります。
並べ替えたら、1回の改修で変えるのは1か所にしておくと、次の月の分析が読めます。同じ月にフォームとCTAとナビを同時に変えると、何が効いたのか誰にも分からず、AIにも分かりません。
改修の規模がリニューアル相当になりそうなら、部分改修と作り直しの判断軸を先に整理しておいたほうが早いです。
発注者側がAI分析を受け取るときの見方

「AIで分析しました」に確認する2点
制作会社やコンサルから「AIで分析しました」というレポートが出てきたとき、確認すべきは次の2点です。
- 何を前提として渡したのか — サイトの目的・改修履歴・比較期間を渡していない分析は、どのサイトに投げても同じ答えが返る一般論です
- 事実と推測が分かれているか — 全文が断定調のレポートは、推測が事実の顔をして混ざっています
この2点が揃っていないレポートは、読む価値がないというより、読むと判断を誤らせる可能性があります。
分析と改修の手間は別物であること
AIに分析させる操作そのものは短時間で終わりますが、前提を整理する作業——サイトの目的の言語化、導線の棚卸し、改修履歴の整理、計測の健全性チェック——には手間がかかります。ここを省いた「AI分析」は、前述のとおり一般論しか出てきません。
保守契約の中にレポート作成が含まれている場合、その中身が「GA4の数字を転記したもの」なのか「前提を踏まえた解釈と提案」なのかで、価値がまったく変わります。毎月の費用が同じでも、前者は翌月の打ち手につながりません。
発注者側から渡してもらうと精度が上がるもの
発注者側からこれを渡してもらえると、分析の質が変わります。
- 商談化率・受注率(フォーム送信後に何が起きているか)
- 問い合わせの中身の傾向(求人の応募が混ざっていないか、営業メールが何割か)
- 営業側が「今月は動きが鈍い」と感じているかどうか
- 展示会・広告・プレスリリースなど、サイト外の施策の実施時期
GA4はサイトの中しか見ていません。問い合わせが増えても全部が営業メールだったというのは実際にある話で、それを知らずに「今月はCV増加」と分析すると、次の打ち手を全部間違えます。サイト外の情報を渡すことが、AI分析の精度を上げる一番効く方法です。
よくある質問

GA4のデータをAIに渡すのは、個人情報の観点で問題ないですか
GA4は個人を特定できる情報を保持しない前提の設計なので、標準的なレポート(ページ別のPVやセッション数、参照元)を渡す分には通常問題になりません。ただしURLのクエリパラメータにメールアドレスや会員IDが入っているサイトがあり、そのままCSVを貼ると混入します。渡す前に、ページパスの列にパラメータが残っていないかを一度確認してください。クライアント案件では、どのAIサービスに何を入れてよいかを先に取り決めておくのが安全です。
スクリーンショットを貼るのとCSVを貼るのは、どちらが良いですか
数字を正確に読ませたいならCSVかテキストの表です。スクリーンショットは行数が多いと読み落としが出ますし、グラフ画像から数値を推定させると誤読が混ざります。ただし探索レポートの経路図など、構造を視覚的に伝えたいものは画像のほうが速いこともあります。数値はテキスト、構造は画像、と使い分けるのが確実です。
AIに毎月レポートを作らせることはできますか
前提部分(サイトの目的・構造・改修履歴・やらないこと)を定型のテキストとして保存しておけば、毎月そこにデータを差し替えるだけで回せます。前提を毎回書き直すのが面倒で省略されるのが失敗の典型なので、最初に前提テキストを作り込んでファイルに残すのが要点です。改修履歴だけは毎月追記してください。
AIの提案と制作会社の提案が食い違ったらどちらを取るべきですか
食い違いの理由を制作会社に聞くのが先です。実装上の制約、過去に試して効かなかった経緯、CMSの構造といった、AIに渡していない情報が理由であることが大半です。理由が説明されずに「AIの言うことなので」あるいは「経験上そうなので」とだけ返ってくる場合は、どちらの根拠も弱いと考えて、検証方法を決めてから小さく試すのが安全です。
データが少ないサイトでもAIに分析させる意味はありますか
月間のセッションやCVが少ないサイトでは、指標の増減の多くが偶然の範囲に収まります。その状態で「改善率」を論じても意味がないので、AIに投げる目的を変えます。数字の解釈ではなく、計測の抜けを洗い出す・想定導線と実際の入口のズレを見る・施策の候補を洗い出して優先順位を付けるといった使い方なら、データ量が少なくても機能します。出力の指示に「サンプル数が少なく判断できない項目は不足と書く」を入れておくのが前提です。
まとめ
GA4のデータをAIに分析させてサイト改善に使える答えを得るかどうかは、プロンプトの技巧ではなく、渡す前提の作り込みで決まります。
- 数字は最後に渡す — サイトの目的、ページの役割、期間と比較対象を先に置く
- やったこと・やれないことを渡す — これがないと去年の施策を再提案されます
- 事実と推測を分けさせる — 出力の指示に書くだけで、検証工程が飛ぶ事故を防げます
- 元データの健全性を先に確認する — 二重計測・イベント停止・IP除外漏れがあると、分析ごと無意味になります
- サイト外の情報こそ効く — 商談化率や展示会の時期は、GA4が持っていない情報です
AIは前提を補完してくれません。渡した範囲でしか考えないという性質は欠点ではなく、こちらが前提を整理すればそのぶん精度が上がるという意味でもあります。分析の質を決めているのは、AIの性能ではなく、渡す側の準備です。
サイト改善の話が「作り直したほうが早いのでは」に向かい始めたときは、費用と工程の側から一度整理してみてください。




