今週末の見学会ページを、先週のページをコピーして書き換えて公開した。翌日、営業から「バナーの日付が先週のままだ」と連絡が来る。地図が前の会場のまま、特典が先月のプレゼントのまま、ということもある。イベントページを毎週のように更新している住宅会社の担当者なら、一度は経験があるはずだ。本記事では、イベントページの更新ミスがなぜ起きるのかを整理し、依頼メモ・本文・バナーの食い違いをAIで自動チェックする仕組みと、その限界を解説する。
イベントページのチェックというと、誤字脱字を探すことを思い浮かべる人が多い。もちろん誤字はないほうがよい。しかし、誤字が1つあっても、来場予約が大きく減ることはまずない。
本当に怖いのは、ページの中で情報が食い違っていることだ。バナーには「10月19日・20日」とあるのに、本文には「10月26日・27日」と書かれている。本文の会場住所は新しいのに、埋め込まれた地図は前回の会場を指している。バナーでは「QUOカード2,000円分プレゼント」をうたっているのに、本文の特典は先月の内容のまま。こうした食い違いは、どれも実害につながる。
日付が食い違えば、客が間違った日に来場するかもしれない。会場が食い違えば、客が別の場所に向かってしまう。特典が食い違えば、受付で「バナーと話が違う」と言われ、来場の第一印象が最悪の形で始まる。どの場合も、客は住宅会社の情報管理そのものを疑う。家という大きな買い物の相手として、その不信感は致命的だ。
予約に届く前の段階でも、食い違いは効いてくる。広告で見た内容がページを開いた瞬間に確認できないと、客は「思っていた内容と違う」と感じて離脱する。ノウハウ集では、ファーストビューでの離脱は30%程度が目安で、70%を超えるようなら根本的な見直しが必要だとしている。集客道場でも、分譲イベントでファーストビューの離脱が多かった会社に、まず広告とページの訴求が食い違っていないかを確認するよう助言したことがある。（イベントページのファーストビューで来場予約率が変わる理由についてはこちら）
イベントの呼び方が混ざるだけでも、客は迷う。バナーは「相談会」、本文は「見学会」となっていれば、客は自分が何をしに行くのかが分からなくなる。食い違いは、誤字よりずっと深いところで予約を削っている。
なぜ、こうした食い違いは起きるのか。担当者の注意力が足りないからだと片付けがちだが、実際には運用の構造から生まれている。
1つ目の原因は、前回のページをコピーして差し替える運用そのものにある。見学会のページは、構成がほぼ毎回同じだ。ゼロから作るより、前回のページを複製して日付や会場を書き換えたほうが早い。合理的なやり方だが、書き換え漏れが起きれば、前回の情報がそのまま残る。
2つ目の原因は、バナーが画像だという点である。本文の日付なら、ページ内を検索すれば古い日付が残っていないか確かめられる。しかしバナーに書かれた日付は画像の一部なので、検索に引っかからない。バナーの差し替えを忘れると、文字の確認をいくら丁寧にしても見つからない。
3つ目の原因は、依頼する人と作業する人が別だという点だ。日程や特典を決めるのは社長や営業で、それがメモで担当者に届く。メモが口頭だったり、途中で特典が変わったりすれば、最終的なページとメモがずれる。担当者が正しく作業しても、元の情報がずれていれば、ページは間違ったまま公開される。
自分で作ったページを自分で見直すと、ミスは見えにくい。頭の中に正しい情報が入っているので、目が勝手に補ってしまうからだ。社内にダブルチェックできる人がいればよいが、兼任の多い工務店では、たいてい担当者が1人で作って1人で公開している。
だから、人の注意力に頼らない確認の仕組みが要る。
今回紹介する仕組みは、イベントページのURLと、社長や営業から届いた日程・特典のメモを入れると、ページの中身を自動で確認するものだ。Googleスプレッドシートとスプレッドシートを自動で動かすGAS（Google Apps Script）で作られており、内容の照合にはAI（AnthropicのClaude）を使っている。（住宅会社のClaude活用方法についてはこちら）
照合は2つの組み合わせで行う。
1つ目は、メモとページ本文の突き合わせである。次の5項目で、メモの内容が本文に正しく反映されているかを確認する。
2つ目は、バナー画像とページ本文の突き合わせだ。バナーは画像なので、AIが画像に書かれた文字を読み取って、本文と比べる。対象は、開催日・期間、開催場所、イベント名・タイトル、特典の4項目である。バナーに開催時間まで載せることは少ないため、時間は照合の対象から外している。
照合に使うバナーは、ページの代表画像として設定された画像だ。SNSでページがシェアされたときに表示される画像で、多くのイベントページではメインのバナーがこれに当たる。
それぞれの項目は「一致」「不一致」「要確認」「対象外」の4種類で判定される。比べる情報が片方にしか載っていない場合は「対象外」になる。メモを入れなかった場合、メモとの照合5項目はすべて対象外になるが、バナーと本文の照合はメモがなくても動く。
問題のあった項目は、「要確認箇所」の列に一覧で表示される。さらに、どの項目がどう食い違っていたかが具体的に書き出される。たとえば「開催日：バナー10月19日・20日／本文10月26日・27日」といった形で、どこを直せばよいかがすぐ分かる。
あわせて、イベントの紹介文の誤字脱字もチェックする。
AIにページを確認させると、最初にぶつかるのは「指摘が多すぎる」という問題だ。全角と半角の違い、西暦の有無、言い回しの差まで、すべてを食い違いとして拾ってしまう。指摘が多すぎると、担当者は結果を見なくなる。本当に危ない食い違いが、細かい指摘の山に埋もれてしまうからだ。
そこでこの仕組みでは、判定のルールをあらかじめ細かく決めている。
まず、見学会の呼び方の違いは「一致」とする。バナーでは「OPEN HOUSE」、本文では「完成見学会」と書かれていても、指しているイベントは同じだ。食い違いとして扱うのは、プレゼント企画の名前など、打ち出しているテーマ自体が違う場合だけである。
次に、表記ゆれは許容する。「2026年10月19日」と「10/19」、全角の数字と半角の数字など、実質的に同じ内容を指す違いは「一致」とする。
誤字脱字のチェックは、そのイベントに固有の紹介文に絞る。掲載日や更新日、受付時間や定休日などの予約案内、個人情報保護方針のような法的な定型文、地図に埋め込まれた住所の文字は対象外とした。定型文は毎回同じなので、そこを指摘されても意味がない。
日付の扱いにも、明確なルールがある。開催期間の終了日が今日以降なら、開始日がどれだけ前でも「開催期間中」として指摘しない。常設のモデルハウス見学会のように、長期間開催しているイベントを「開始日が過去になっている」と誤って指摘しないためだ。指摘するのは、終了日がすでに過ぎている場合だけである。
もう1つ、「掲載日」や「更新日」を開催日として読まないよう指示している。ページの上部に掲載日が書かれていると、AIがそれを開催日と取り違えることがあるからだ。
こうしたルールは、AIの性能を上げるためのものではない。AIに何を見させ、何を見させないかを決めるためのものである。
すべての確認をAIに任せているわけではない。答えが機械的に決まる確認は、AIを使わずにGASだけで行っている。
1つ目はリンク切れだ。ページ内の外部リンク（予約フォーム、施工事例ページ、SNSなど）が実際に開けるかを確認する。リンク先がなくなっていれば、ページを開いたときの応答で分かる。
2つ目はページ内ジャンプの確認である。「ご予約はこちら」のボタンを押すと、同じページの予約欄まで飛ぶ仕組みはよく使われる。前回のページをコピーして構成を変えると、このジャンプ先が消えて、ボタンを押しても何も起きない状態になることがある。仕組みは、ジャンプ先の目印がページ内に実在するかを確認する。
3つ目は地図表示だ。埋め込んだGoogleマップが実際に開けるかを確認する。あわせて、地図に埋め込まれた住所を読み取り、本文に書かれた会場の住所と食い違っていないかも照合する。前回の会場の地図がそのまま残っている、という典型的なミスはここで見つかる。
これらをAIに任せないのは、AIの判定には必ずブレがあるからだ。同じページを同じ内容で何度確認しても、AIの判定は完全には一致しない。リンクが開けるかどうかのように答えが1つに決まる確認に、わざわざブレを持ち込む理由はない。AIに任せるのは、意味を読み取る必要がある照合だけ。この線引きが、仕組み全体の信頼性を支えている。
運用は、スプレッドシートに行を追加するだけで回る。対象ページのURLと、社長や営業から届いた日程・特典のメモを貼り付ける。メモは箇条書きで構わない。
実行のタイミングは2通りある。メニューの「今すぐ実行」を押して手動で確認する方法と、1時間ごとに自動で確認する方法だ。ページを公開した直後に手動で回し、あとは自動に任せる、という使い方が現実的だろう。
確認が終わった行は「完了」となり、次からは自動でスキップされる。ページを修正して確かめ直したいときは、完了の表示を消せばもう一度確認される。バナー画像が取得できなかった場合は、その理由が記録されるので、確認漏れに気づける。
通知の設計にも工夫がある。Slackと連携しておくと、不一致や要確認、誤字の疑い、リンクの不具合が1件でもあった場合にだけ通知が届く。通知には、対象のURL、メモの抜粋、具体的な食い違いの内容が含まれる。
問題がなかったときに通知しないのは、通知に慣れさせないためだ。毎回「問題なし」という通知が来ると、担当者はそのうち通知を開かなくなる。そうなれば、本当に問題があったときの通知も読み飛ばされる。通知が来たら必ず何かがある、という状態を保つことが、仕組みを形骸化させない条件になる。
費用は、スプレッドシートとGAS、Slackの通知は無料で、AIによる照合にだけ、使った量に応じた利用料がかかる。確認するページの数と頻度から、事前に試算しておくとよい。
便利な仕組みだが、確認できないこともはっきりしている。導入する前に知っておきたい。
まず、予約フォームが実際に正しく送信できるかは確認できない。リンクが開けることは確かめられても、入力して送信したあとに予約がきちんと届くかまでは見ていない。公開後に一度、自分で予約を入れてみるのが確実だ。
次に、地図のピンが地理的に正しい位置にあるかも確認できない。照合できるのは、地図に埋め込まれた住所の文字と、本文の住所の文字が一致しているかまでである。
デザイン崩れやレイアウト崩れのような見た目の不具合も、対象外だ。スマホで見たら文字が画像に重なっていた、ボタンが画面からはみ出していた、といった問題は、実際にスマホで開いて確かめるしかない。イベントページはスマホで見られることがほとんどなので、ここは手を抜けない。
そして、AIの判定は完璧ではない。問題のないところを指摘することもあれば、実際の問題を見落とすこともある。判定結果は参考情報であり、公開するかどうか、直すかどうかを最終的に決めるのは人である。
最後に、メモの質が精度を決める。メモに書かれていない項目は照合されない。特典をメモに書き忘れれば、特典の食い違いは見つからない。社長や営業にメモを書いてもらうときは、日付・時間・場所・イベント名・特典の5つを必ず入れてもらう。これだけで、仕組みが拾える範囲は大きく変わる。
イベントページのミスで本当に怖いのは、誤字ではなく、日付・場所・特典の食い違いである。それはコピーして差し替える運用、画像のバナー、依頼者と作業者のずれから構造的に生まれる。依頼メモ・本文・バナーをAIで突き合わせ、細かすぎる指摘は判定ルールで抑える。リンクや地図のように答えが決まる確認は機械的に行い、通知は問題があるときだけに絞る。
すべてを自動で確認できるわけではない。予約フォームの送信、地図のピン、スマホでの見た目は、人が自分の目で確かめる必要がある。それでも、食い違いの確認を仕組みに渡せれば、担当者は残りの確認と、ページそのものの改善に集中できる。毎週の更新を、毎週の不安で終わらせないための仕組み。
