AIチームと作る、ぼっち事業のOS という記事を書いた。
その中で、4つのブログ、公式サイト、事業集計、日次レポート、AIとの作業体制をつなげて、自分の事業OSを作っているという話をした。
今回は、その中でもかなり実務寄りの話。
僕は今、CodexとGoogle APIを使って、毎朝、AIチームに前日の事業集計を報告してもらうようにしている。
Google APIで数字を集める。
Googleスプレッドシートに残す。
Codexに読ませて、朝のレポートとして返してもらう。
GA4を見る。
AdSenseを見る。
Search Consoleを見る。
ASPを見る。
クリックを見る。
AIサービスからの流入を見る。
やろうと思えば、それぞれの管理画面を開けば見られる。
でも、それを毎日やるのは正直面倒。
そして、見たからといって、すぐに次の判断ができるわけでもない。
なので今は、必要な数字をGoogleスプレッドシートに集めて、毎朝、Codexに「昨日何が起きたか」を報告してもらうようにしている。
欲しいのは、アクセス報告ではない。
次に何を見るか。
どの記事を直すか。
どの導線を育てるか。
今日は触らず様子を見るか。
その判断材料が欲しかった。
管理画面を巡回しても、判断までは進まない
以前から、数字を見る習慣はあった。
GA4を開く。
AdSenseを開く。
ASPを見る。
Search Consoleも見る。
それぞれの数字は見える。
昨日のPV。
ユーザー数。
広告収益。
検索クリック。
発生した成果。
ただ、見たあとに少し止まってしまうことが多かった。
どの記事を直すのか。
どのサイトに時間を使うのか。
収益導線は効いているのか。
リニューアルの影響は出ているのか。
そこまでつなげるには、数字を横に並べて見ないといけない。
GA4だけを見ても分からない。
AdSenseだけを見ても分からない。
ASPだけを見ても分からない。
それぞれの管理画面を巡回していると、見ているようで、ただ見回っているだけになる。
そして疲れる。
この「疲れる」が、かなり大きい。
ひとりで事業をやっていると、数字を見る時間も、記事を書く時間も、実装する時間も、全部同じ僕の時間から出ていく。
だから、数字を見ること自体を少し軽くしたかった。
Google APIとスプレッドシートで、事業の数字を集める
最初から大きなBIツールを作ったわけではない。
もともと、AdSenseとGA4の数字をGoogle Apps Scriptで取得して、メールで確認する仕組みを使っていた。
このあたりは以前、毎日自動で届く AdSense ＋ GA4 レポートを GAS で作る という記事にも書いた。
その延長で、日次の数字をGoogleスプレッドシートに保存するようにした。
いま見ているのは、アクセスだけではない。
- GA4のusers、PV、サイト別推移
- Google AdSenseの日次収益、月次累計
- Search Consoleのclicks、impressions、検索ワード
- GA4のクリックイベント
- A8、もしもアフィリエイトの発生額、承認額
- ChatGPT、Perplexity、Claude、Gemini、CopilotなどからのAI流入
- リニューアル、新規記事、リライト、CTA修正などの施策履歴
これらを、ひとつの場所で見られるようにしている。
もちろん、完璧な自動化ではない。
ASPはCSV取り込みが必要な部分もある。
Search Consoleは反映が遅れる。
クリックイベントも、取れるものと取れないものがある。
でも、最初から完璧を狙うより、僕には「判断に使えるだけの材料を集める」ほうが大事だった。
事業集計というと大げさに聞こえるけれど、やっていることはわりと地味です。
昨日の数字を残す。
どのサイトの数字か分かるようにする。
どの記事や導線と関係があるかを見られるようにする。
まずはそこから始めている。
毎朝、AIに前日の状態を報告してもらう
数字を集めるだけなら、スプレッドシートで終わる。
でも、それだけだと、結局また自分で表を見に行くことになる。
そこで、毎朝8時にCodexがスプレッドシートを読み取り、前日の状態をまとめるようにしている。
レポートで見たいのは、単なる一覧ではない。
- 昨日、全体として何が起きたか
- どのサイトが動いたか
- 収益導線に変化があったか
- 検索ワードに需要が出ているか
- AIサービスからの流入があったか
- 施策との関係で見るべき変化か
- 今日は触るべきか、様子見でよいか
このあたり。
たとえばPVが増えていても、それが一時的なものなのか、検索需要の兆しなのか、記事更新の影響なのかで意味が変わる。
逆に数字が少なくても、Search Consoleの反映待ちだったり、ASPの取り込み前だったりする。
数字は、そのまま読むとけっこう雑に見えてしまう。
だからAIには、数字をきれいに並べるよりも、見るべき論点を出してもらっている。
Codexでは、スレッドとドキュメントを分けて動かしている
この仕組みは、スプレッドシートを作って終わりではない。
Codexをどう使うかも、少しずつ形を変えている。
今は、ひとつのスレッドに全部を詰め込まないようにしている。
記事を書くスレッド。
実装するスレッド。
QAするスレッド。
事業集計を見るスレッド。
朝レポートを読むスレッド。
目的ごとに分ける。
その代わり、前提はドキュメントに残す。
4ブログのリニューアル日。
それぞれのサイトの役割。
事業ダッシュボードの見方。
Search Consoleの遅延。
ASPの取り込み状態。
taupe.siteのGA4計測欠損の扱い。
7日、14日、28日で何を見るか。
こういう情報を、会話の流れだけに置かないようにしている。
スレッドは作業する場所。
ドキュメントは判断を残す場所。
この分け方が、かなり効いている。
Codexには、そのとき必要なドキュメントと数字を読ませる。
すると、過去の会話をなんとなく思い出すのではなく、今の正本に戻って判断しやすくなる。
AIをチームとして使うというのは、こういうことでもあると思う。
ただ会話するだけではなく、前提を残し、次のスレッドへ渡し、また数字を見て判断する。
少しずつ、作業の続き方そのものを整えている感じです。
リニューアル後の変化を、7日・14日・28日で見る
2026年5月に、4つのブログを順番にリニューアルした。
- monoomoi.net: 2026-05-06
- moss.fish: 2026-05-09
- isLog: 2026-05-15
- taupe.site: 2026-05-19
ただ、公開した翌日に成果が分かるわけではない。
検索は遅れて動く。
クリックは日によって揺れる。
収益もすぐには判断できない。
なので、リニューアル後の変化は、7日、14日、28日で見るようにしている。
7日は、異常検知。
計測が止まっていないか。
表示崩れがないか。
クリック導線がまったく動いていないか。
14日は、初期傾向。
どの記事が読まれているか。
検索ワードに変化があるか。
リニューアル後の導線が少しでも使われているか。
28日は、初期評価。
検索、回遊、収益導線、AI流入を見ながら、次にどこへ時間を使うか考える。
monoomoiでは、商品レビュー記事の検索需要やASPクリックを見る。
mossでは、アウトドア記事、商品クリック、公式サイトやservicesへの送客を見る。
isLogでは、旅と食のシリーズ、検索流入、回遊を見る。
taupeでは、AI、GAS、WordPress、作業環境系の記事がどう読まれるかを見る。
同じPVでも、サイトごとに意味が違う。
だから、サイトの役割と数字をセットで見る必要がある。
数字は、異常にも気づかせてくれる
最近、分かりやすいことがあった。
taupe.siteのリニューアル後、GA4タグが本番HTMLから抜けていた。
リニューアル直後なのに、usersやPVが極端に少ない。
このときに大事なのは、「読まれていない」と判断しないことだった。
まず疑うべきは計測。
実際、D案の独自テンプレートでCocoon標準の分析タグ出力を通していなかったことが原因だった。
表示は崩れていない。
OGPも大きく壊れていない。
記事も公開できている。
でも、GA4は取れていない。
こういう問題は、見た目だけの確認では気づきにくい。
数字を見て、AIに「これは成果判断ではなく、計測確認を優先」と整理してもらえたのは助かった。
数字を見る意味は、伸びた、落ちたを見ることだけではない。
計測ミスに気づく。
導線の不備に気づく。
比較してはいけない日を分ける。
そういう地味な判断にも使っている。
検索ワードとクリックから、次に直す記事が見える
Search Consoleは、単なるクリック数を見る場所ではないと思っている。
むしろ、近々でどんな需要があるのかを見る場所。
どんな言葉で検索されているか。
どの記事が表示されているか。
クリックされているか。
まだクリックされていないけれど、表示だけ増えているテーマはあるか。
そこを見ると、次に直す記事が見えやすい。
ASPクリックも同じ。
商品レビュー記事にクリックが集まっている。
使い方系の記事から商品リンクが踏まれている。
クリックはあるけれど成果が弱い。
公式サイトへの送客が出始めている。
こういう兆しを見て、次の作業を決める。
新規記事を書くのか。
比較記事を足すのか。
内部リンクを足すのか。
商品リンクを見直すのか。
サービス導線を少し整えるのか。
感覚だけで決めるより、かなり落ち着いて考えられる。
数字があると、何もしない判断もしやすくなる。
今日は触らない。
もう少し待つ。
Search Consoleが反映されてから見る。
これも、けっこう大事な判断だと思う。
AI流入も、LLMOの観察指標として見る
AIサービスからの流入も見ている。
ChatGPT、Perplexity、Claude、Gemini、Copilotなどから、実際にサイトへ来ているか。
これは、AI回答の中で何回引用されたかを直接見るものではない。
でも、AIサービス上のリンクから流入があれば、少なくとも「AI経由で見つかっている記事」があることは分かる。
AI流入があったページは、検索ワードや記事内容と合わせて見る。
その記事は、体験に基づいているか。
読者の疑問に答えられているか。
FAQ的に拾いやすい構造になっているか。
内部リンクで次に進めるか。
ASPやサービス導線とつながる余地があるか。
LLMO対策という言葉だけだと、少しふわっとしている。
でも、AIサービスからの実流入を日次で見ると、少なくとも観察対象にはできる。
今のところは、それで十分だと思っている。
AIチームは、答えを出す存在ではなく、論点を出す存在
AIに見てもらっていると言っても、最終判断を任せているわけではない。
どの記事を書くか。
どの導線を直すか。
どの数字を重く見るか。
今は何もしないか。
そこは僕が決める。
ただ、AIがいることで、考える前の整理がかなり楽になった。
これは今触るべきか。
まだ様子見でよいか。
どのサイトを優先すべきか。
どの記事が改善候補か。
どの数字は遅延前提で見るべきか。
こういう論点を、毎朝出してもらえる。
AIが勝手に事業を伸ばしてくれるわけではない。
でも、ひとりで全部を見ていたときより、かなり俯瞰しやすくなった。
ひとり事業なのに、ひとりで見ている感じが少し薄くなる。
この感覚は、親記事で書いた「AIチーム」とかなり近い。
事業集計は、数字を眺めるためではない
GA4も、AdSenseも、Search Consoleも、ASPも、クリックも、AI流入も、単体ではただの数字です。
でも、施策履歴や記事改善とつなげると、次に動くための材料になる。
4つのブログをメディアとして整えた。
公式サイトともつなげた。
では次に、どの記事を書き、どこを直し、どの導線を育てるのか。
それを決めるために、事業集計を作っている。
これは、まだ完成していない。
ASPの取り込みも改善したい。
週次や月次の見方も、もう少し整えたい。
AI流入やSearch Consoleの見方も、しばらく観察が必要だと思っている。
でも、少なくとも管理画面をあちこち巡回していた頃よりは、次に何を見るべきかが分かりやすくなった。
AIチームと一緒にやっているのは、記事の量産ではない。
事業の見方を整えること。
そのためのダッシュボードを、今まさに育てている。
taupeでは、このあたりの実践記録を 作る / Projects に少しずつ残していく。
全体の記事は 記事一覧 からも辿れるようにしている。
ポチップ
