【AI社員実践記 第27話】火曜の夜のClarityメールを、月曜4時20分の「4通目」に変えた

こんにちは、オフィスピコッツの小笹です。

毎週火曜日の夜、Microsoft Clarityから1通のメールが届きます。自社サイトの「先週の様子」をまとめたダイジェストです。

怒りクリック。同じ場所を何度も押した人がいたか。デッドクリック。押したのに何も起こらなかった場所があったか。クイックバック。ページを開いてすぐ戻った人がいたか。セッション数、スクロールの深さ、滞在時間。そして今回は、フォーム入力を途中でやめた人の録画も2本ありました。

普段なら一通り眺めて閉じます。

この日は、そのメールをそのままAI社員に見せて聞きました。

「これどう？ これも自動で確認したり分析したりできないの？」

そこから、火曜の夜に眺めていたメールが、毎週月曜4時20分に届く4通目の定例レポートへ変わりました。

「9月末に判断する予定だった材料が、もうここにある」

最初にAI社員が見たのは、自動化の方法ではなく数字でした。

怒りクリックは0％。JavaScriptエラーもごく少ない。大きく壊れている場所はなさそうです。

一方、デッドクリックは13％台。何かを押したのに反応しなかった体験が一定数あります。そして、フォーム離脱の録画が2本。

実はその少し前、別の集計で、問い合わせページを見た回数と実際の送信数にかなり差があることが分かっていました。

見に来ている。

でも送っていない。

なぜ送らないのかは、アクセス数だけを見ても分かりません。

そこで9月末に、ヒートマップや録画を使う仕組みを新しく入れるか判断する予定でした。

ところが、Clarityのメールを見せるとAI社員から、

「そのための道具は、もう入っています」

と指摘されました。

録画も残っています。

月末まで待つ理由が、一つ消えました。

ClarityのAPIには、はっきりした制限がある

では、この数字を毎週自動で取れるのか。

Clarityには、ダッシュボードのデータをプログラムから取得するためのAPIがあります。

ただし、設定画面を見ると制約も明確でした。

1プロジェクトあたり1日10回まで。

さらに、取得できる期間にも制限があります。後から1週間分をまとめて全部取りに行く、という設計には向きません。

そこで考え方を変えました。

毎日1回、直近24時間分を取得してサーバーへ保存する。月曜の朝に、貯めたデータをまとめて週次レポートにする。

この方法なら、APIの上限にも十分収まります。

月曜朝に、すでに3通の材料が届いている

現在、月曜日の早朝には、監視用VPSからいくつかの定例メールが届きます。

全ページの差分。

Search Consoleの取りこぼし候補。

GA4の週次レポート。

それぞれ、人間が管理画面を開いて探しに行く代わりに、判断材料だけを先に送ってくる係です。

そこへ、

4時20分にClarityの週次レポート

を追加することにしました。

これで月曜朝には、検索、アクセス、ページ変化、ユーザー行動をまとめて確認できます。

AI社員がこれらを読んでから、その週にやることを提案する。

また一つ、人間が材料を集める仕事を減らします。

「2週間後にやる理由ある？」と聞いた

この作業は、本来なら次回のサーバー作業日にまとめる予定でした。

約2週間後です。

でも、AI社員に聞きました。

「今すぐやったら？ 2週間後にする大きな理由ある？」

答えは、

「ありません。むしろ待つ方がデータを失います」

でした。

APIから後で取れるデータには期間制限があります。

つまり、取得を始めていない日の情報は、あとで完全には取り戻せない可能性があります。

それなら今日から取る方がいい。

この日のうちに進めることにしました。

新しく必要だったのは、APIトークン1本だけ

新しく用意したのはClarityのAPIトークンです。

設定画面から名前を付けて発行すると、長い文字列が表示されます。

これは鍵に近い情報なので、サーバーの設定ファイルへ保存します。

VPS自体は既存。

メール送信の仕組みも既存。

保存場所も既存。

新しく増えたのは、Clarityの取得スクリプトとトークンだけです。

今回のスクリプトには、

• テスト
• 日次取得
• 週次まとめ

の3つの動きを持たせました。

第24話では、–helpで安全確認するつもりが本番処理を始めてしまいました。

その反省があるので、今回はテストモードなら表示だけで終了することを最初に確認しています。

最初の整形結果は、明らかにおかしかった

テストすると、APIから数字は返ってきました。

ところが、AI社員が作った要約部分に違和感があります。

怒りクリックが485件。

週次メールでは0％なのに、数日でそれだけ発生しているとは考えにくい。

ページ別のURLも、すべて「?」になっています。

原因は、APIから返ってくる実際の項目名と、AI社員が想定した項目名が一致していなかったことでした。

第24話のタイムゾーンと同じです。

知識としては近い。

でも、現物には合っていない。

そこで一度、整形をやめました。

要約を直す前に「生の1行」を見る

スクリプトを修正して、APIから返ってきた実データを1行ずつそのまま表示するようにしました。

すると、違いが分かります。

セッション数は totalSessionCount。

ユーザー数は distinctUserCount。

不満系の件数は subTotal。

ページURLは Url。

大文字小文字も含め、実物に合わせて直します。

その後は、要約も正常に出るようになりました。

9月6日から8日の3日間では、セッション186。その中にはbotも含まれています。

デッドクリックは11％台。

クイックバックは約7％。

JavaScript系のエラーも少し。

平均スクロール深度は45％台でした。

問い合わせページが、3日間で訪問2位だった

ページ別の上位一覧を見て、少し意外な数字が出ました。

1位はトップページ。

そして、

2位が問い合わせページ。27。

サービスページでも記事でもありません。

3日間で27回、問い合わせページまで来ています。

それ以前の集計でも、

問い合わせページは見られているのに、送信数は少ない

という傾向が出ていました。

Clarityでも同じ方向の数字が出ました。

ここまで来ると、

「問い合わせが少ないから、問い合わせページが見られていない」

とは言いにくくなります。

見られている。

その先で止まっている可能性があります。

そこで、9月末にやる予定だったフォーム離脱の録画確認を、翌週へ前倒しすることにしました。

直す場所が1か所で済むかもしれない

もし録画を見て、

毎回同じ入力欄で止まっている。

説明が分からず戻っている。

送信ボタンの直前で離脱している。

という傾向が見えれば、サイト全体を作り直す必要はありません。

止まっている1か所を直せばいい。

アクセス解析だけでは見えない、

「なぜ送らないのか」

を確認する材料が、すでにClarityに残っています。

今回の自動化は単にClarityの数字をメール化しただけではなく、次に人間が見るべき場所を早めたことの方が大きかったと思います。

cronへ2本追加したら「37行」と出た

日次取得を一度動かしたあと、cronへ新しい処理を2本登録しました。

前日分を取得する処理。

月曜に週次レポートを作る処理。

確認のため、cronの行数を数えます。

結果は、

37。

ところが、手元の台帳では既存が12本。

2本増えたなら14のはずです。

また食い違いました。

AI社員は、

「記憶で14と決めず、実行行だけ数えましょう」

と確認方法を変えました。

コメント行と空行を除外して再集計。

結果は、

14。

37は、crontabに最初から入っている説明コメントなどを含めた行数でした。

つまり、

両方とも数字としては正しい。数えている対象が違った。

という話です。

AI社員が「その画像は記事に使わない」と止めた

今回の作業では、記事に使えそうな画面を途中でスクリーンショットとして残していました。

その中に、APIトークンを設定ファイルへ書き込んだ場面がありました。

当然、画面にはトークンそのものが表示されています。

それを見たAI社員から、

「このスクリーンショットは記事には使いません」

と指摘されました。

このトークンで取得できるのは、自社Clarityの読み取りデータです。

それでも、鍵は鍵です。

公開記事に出す必要はありません。

今回の公開用画像では、APIトークンの値を強めに再モザイクしました。さらに内部で付けたトークン名も隠しています。

記事用のスクリーンショットを残す前提で作業すると、

「この画面は外へ出して大丈夫か」

まで作業の一部になります。

費用は0円。増えたのは月曜のメール1通

今回、新しい有料サービスは契約していません。

Clarityは既存利用。

APIも利用制限の範囲内。

VPSも既存。

メール送信も既存。

追加固定費は、

0円。

増えたのは、月曜4時20分に届くメール1通です。

一方で、火曜の夜にClarityのダイジェストを眺め、その場で終わっていた作業は減ります。

毎日データを保存し、1週間分をまとめてから確認する。

人間は月曜に届いた結果を見る。

その方が、次の作業につなげやすくなりました。

「これどう？」の一言で、判断が3週間早まった

今回、自動化を作ろうと思ってClarityを開いたわけではありません。

火曜の夜に来たメールを見て、

「これどう？」

とAI社員へ見せただけです。

そこから、

APIがある。

ただし直近データしか取れない。

だから今日始めた方がいい。

週次レポートへできる。

そして、すでに問い合わせページまで来ている人がかなりいる。

というところまで話が進みました。

もともとは9月末に考える予定だったフォーム分析が、翌週へ前倒しになりました。

今回一番大きかったのは、

自動化のスクリプトが1本増えたことではありません。

判断するための材料が早く揃ったことです。

今回の結論

毎週火曜の夜に届くMicrosoft Clarityのダイジェスト。

これまでは、見て閉じるメールでした。

今回、その1通をAI社員に見せたところから、

日次データの保存。

週次レポート。

月曜朝の自動メール。

問い合わせページの動きの確認。

フォーム離脱録画を見る予定の前倒し。

までつながりました。

途中では、APIの項目名が想定と違い、要約結果も一度外れました。

cronの行数も、37と14で食い違いました。

でも今回も、

合わない数字を無理に説明せず、実物を見て確認する。

という進め方で修正できました。

AI社員が便利なのは、毎回答えを出すからだけではありません。

「この数字、本当に合っている？」と一緒に確認し、次に見るべきものを決められること。

最近は、そこに一番価値を感じています。

AI社員実践記は、まだ続きます。

• 無料AI活用診断：https://pikoz.net/ai-shindan/
• AIレスキュー：https://pikoz.net/ai-rescue/
• ネット顧問：https://pikoz.net/komon/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

技術の話はここまで。考え方の話は「社外Web担当の頭の中」へ。