ブログの記事数が増えてくると、記事を書くこととは別に「数字を確認する作業」が増えてきます。
Google Search Consoleでは表示回数・クリック数・CTR・掲載順位・検索クエリ。GA4ではユーザー・セッション・エンゲージメント。さらにBingやYouTube、SNSまで運用すると、確認する管理画面はさらに増えます。
私自身、ブログやSNSのデータを一か所へ集める「全媒体データ分析基盤」を作ってきました。その先で目指しているのが、自分専用のAIアナリストです。
管理画面を毎回巡回するのではなく、
「今週伸びた記事は？」
「CTRを確認した方がよい記事は？」
「次にリライトするならどの記事？」
とAIへ質問すると、実際のデータを根拠に候補を整理してくれる仕組みです。
この記事では、現在考えているAIアナリストの構想と、そのために必要になったデータ基盤について整理します。
この記事で分かること
- ブログ分析をAIに任せたいと考えた理由
- AIアナリストに任せたい分析
- AIへ直接データを渡すだけでは不十分な理由
- AI分析の前に必要になったデータ設計
- 人間とAIをどう役割分担するか
目指しているのは「管理画面を見ない分析」
Search ConsoleやGA4などの管理画面は、それぞれの媒体を分析するには便利です。
問題は、複数媒体を横断して考える場合です。
Search Consoleで検索状況を確認し、GA4で訪問後の行動を確認する。さらにBingやYouTubeも調べるとなると、人間が複数の数字を頭の中でつなぐ必要があります。
そこで現在は、Pythonを使って各媒体からデータを取得し、SQLiteへ蓄積する仕組みを作っています。
最終的には、人間が管理画面を巡回する代わりに、AIが必要な数字を読み取る状態を目指しています。
「今週伸びた記事は？」と普通に質問したい
AIアナリストで実現したいのは、難しい分析コマンドではありません。
例えば、
「今週伸びた記事は？」
と普通の言葉で質問します。
すると直近7日とその前の7日を比較し、
- 検索表示が増えた記事
- クリックが伸びた記事
- 掲載順位が変化した記事
- 新しい検索クエリで表示され始めた記事
などを抽出し、その理由を説明してもらいます。
単純なPVランキングではなく、現在値よりも「変化」を発見してもらうイメージです。
まだアクセス数が少なくても、表示回数やクリック数が継続的に増えている記事なら、今後伸びる可能性を観察する価値があります。
CTRやリライト候補も一つの数字だけで決めない
AIに任せたいのは、数字を小さい順・大きい順に並べることだけではありません。
例えばCTRが低い記事でも、掲載順位が30位ならクリックされにくいのは自然です。
一方、ある程度上位に表示され、表示回数も多いのにCTRが低ければ、タイトルや検索意図との一致を確認する余地があります。
そのため、
表示回数・クリック数・CTR・掲載順位・検索クエリ・期間変化
を組み合わせ、「なぜ改善候補なのか」まで説明してもらいたいと考えています。
リライトについても同様です。
アクセスが少ない記事を機械的に選ぶのではなく、検索表示が増え始めている、順位が改善している、実際の検索クエリに対して回答が不足しているなど、複数の材料から候補を絞ります。
検索とSNSの「得意なテーマ」も比較したい
全媒体データを集める理由は、検索分析だけではありません。
同じテーマでも、
Google検索では強い。
Pinterestでは保存されやすい。
YouTube Shortsでは再生されやすい。
といった違いが出る可能性があります。
逆にSNSでは目立たなくても、検索から長期間アクセスされる記事もあるはずです。
データが蓄積されれば、AIに、
「検索で伸びやすいテーマは？」
「SNSでは強いのに検索では弱いテーマは？」
と質問できます。
すべての記事を同じ方法で展開するのではなく、テーマと媒体の相性を実データから学ぶこともAIアナリストの役割にしたいと考えています。
AIをつなぐ前にデータの問題が出てきた
当初は、SQLiteへデータを集めてAIへ渡せば分析できると考えていました。
しかし実際にGA4、Search Console、Bing、YouTubeなどを接続すると、それほど単純ではありませんでした。
例えば、同じ日付でも媒体によって時間基準が異なる場合があります。日次データと週次データもあります。YouTubeには一定時点の累積値もあります。
さらに、
0＝実績がゼロ
なのか、
NULL＝値が取得できない・存在しない
なのかでも意味は違います。
累積値を日次実績として合計したり、取得できなかった数字を0として扱ったりすれば、AIは間違ったデータから自然な分析文章を作ってしまいます。
つまり、AIへデータを渡せることと、正しく分析できることは別問題でした。
AIに渡す前の「分析契約」を作る
そこで現在のシステムでは、AIへ数字を渡す前に分析契約を設ける考え方にしています。
例えば、
- 0とNULLを区別する
- 期間実績と累積値を区別する
- API取得値とシステム側の計算値を区別する
- 完了していない期間とは比較しない
- 紐付け先が不明なデータを無理に記事へ割り当てない
といったルールです。
AIに「自由に分析して」と渡すのではなく、数字の意味と比較条件も一緒に渡すことが重要だと考えるようになりました。
AI-ready packageとして必要なデータだけを渡す
もう一つ考えているのが、質問ごとにAI-ready packageを作る方法です。
例えば「今週伸びた記事は？」なら、データベース全体を渡す必要はありません。
対象期間と比較期間、記事情報、Search Console・GA4の主要指標、必要に応じてBingなどのデータを抽出します。
さらに、期間やタイムゾーン、指標の意味、データの完全性などを説明する情報も付けます。
つまり、
数字＋数字の取扱説明書
をAIへ渡す仕組みです。
AIにはデータベースを好き勝手に探索させるのではなく、質問に必要な範囲を、意味を保った状態で分析してもらいます。
AIには「分からない」と言ってもらう
AIアナリストには、答えを出すことだけを求めるつもりはありません。
例えばCTRが低下しても、原因がタイトルとは限りません。掲載順位や検索クエリの変化が影響している可能性もあります。
そこで、
事実・計算結果・仮説・不明
を分けて回答させたいと考えています。
「CTRが低下した」はデータ上の事実でも、「タイトルが悪い」は仮説です。
データだけでは判断できないなら、無理に結論を作らない。これは自分専用のAIアナリストを作るうえで重要なルールになりそうです。
最終的にはAIと週次の「運営会議」をしたい
完成形として考えているのは、週に一度AIへ、
「今週のブログ全体を分析して」
と依頼する形です。
AIが伸びた記事、検索クエリの変化、CTR改善候補、エンゲージメントの変化、SNSとの違いなどを整理する。
そこから人間が、
「なぜこの記事が伸びた？」
「来週はどの記事を観察する？」
「この3記事ならどれを改善する？」
と掘り下げていきます。
AIがデータを読み、変化を発見し、仮説を出す。最終的な優先順位や実行内容は人間が決める。
この役割分担を目指しています。
まとめ
ブログのアクセス解析をAIへ任せたいと考え、全媒体データ分析基盤を作り始めました。
しかし実際に進めてみると、重要だったのはAIを接続することより、その前段階でした。
記事を識別し、各媒体から正しくデータを取得し、数字の意味を定義し、比較してよい条件を決める。その上で初めてAIへ分析を任せられます。
目指しているのは、AIによるブログの完全自動運営ではありません。
数字を確認する作業をAIに任せ、人間は判断と改善に時間を使う。
将来的にAIと週次の運営会議ができるところまで進められれば、今回作っているデータ基盤も、単なる数字の保管場所から「次の行動を考える仕組み」へ変わっていきそうです。
