個人ブログはどこまで自動化するべきか―ゆまラボ第10回までで見えた自動化と人間の判断

個人ブログを作っていると、自動化したい作業は少しずつ増える。

記事の下書き、画像生成、公開、SNS投稿、アクセス解析、人気記事の表示。ゆまラボでも、最初は個別に行っていた作業が、連載を進めるうちに少しずつつながってきた。

現在の「サイトを作ったら ― 運用・SEO・SNS」は第10回まで進んでいる。

アクセス解析だけを見ても、第3回でGoogle Analyticsを使う方針を決め、第4回でGA4を導入し、第8回でData APIから記事別PVを取得、第9回でCloudflareビルドから使える認証へ変更し、第10回でPV上位3件をTOPページの「注目コンテンツ」へ自動表示するところまで進んだ。

ここまで実際に進めてみると、「自動化できるか」だけでは判断しにくい。

自動化した方がよい作業もある。一方で、自動化したことで新しく増える確認や、機械へ渡さない方がよい判断もある。

ルールが決まった処理は機械へ渡しやすい#

ゆまラボで分かりやすいのは、公開や集計のように処理手順を固定できる部分になる。

Astroの記事はGitHubへpushするとCloudflare側でビルドされる。毎回Cloudflareの管理画面から手動デプロイする形にはしていない。

Xへの投稿でも、投稿用URLには同じUTMを使っている。

utm_source=x
utm_medium=social
utm_campaign=article_publish

第7回では、この運用で実際にXへ投稿している状態と、GA4のトラフィック獲得でx / socialが記録されていることまで確認した。

アクセス解析も同じ方向へ進んだ。

第8回では、scripts/ga-pageviews.mjsからGA4 Data APIを呼び出し、pagePathとscreenPageViewsを取得する処理を作った。期間は30daysAgoからyesterdayまでとし、/blog/配下を対象にPV順で扱う。

この時点では、ローカルから取得するところまで。

第9回では、その処理をCloudflareのビルドでも使うために認証方法を変更した。サービスアカウントのJSONキーを作ろうとしたが、親側から適用されていたiam.disableServiceAccountKeyCreationで作成できず、ポリシーを変更する権限もなかった。

そこでサービスアカウント方式を続けず、OAuthとCloudflare Secretを使う構成へ切り替えた。

第10回では、そのGA4データをTOPページまでつないだ。直近30日のPVから上位3記事を選び、「注目コンテンツ」へ自動表示する。TOPにはPV数や順位そのものは出さず、既存の記事カードを使う形にしている。記事ではCloudflareビルドが成功し、3件が生成されるところまで確認している。

GA4
↓
Data API
↓
Cloudflare build
↓
上位3記事を選択
↓
TOP「注目コンテンツ」

第3回で「人気記事を自動表示したい」と考えたものが、第10回で実際の表示処理までつながった。

ここは自動化と相性がよい。

「直近30日」「記事ページだけ」「PV順」「上位3件」という条件を決めた後は、記事を公開するたびに人がGA4を開いてランキングを作り直す必要がない。

自動化するほど、入力データの扱いが重要になる#

人気記事を自動表示できるようになると、別の問題も出る。

自動化した処理は、入力されたデータをそのまま使う。

GA4の数字に自分の確認アクセスが含まれていれば、その数字もPVとして扱われる。ゆまラボではGA4導入時、自分でサイトを開いた直後にリアルタイム計測へアクセスが入ることを確認している。

そのため、Data APIから値を取れることと、その値をそのままサイト上の判断へ使ってよいことは同じではない。

GA4へデータが入る
↓
Data APIで取得できる
↓
ランキングを計算できる
↓
TOPへ自動表示できる

この流れの途中に人の操作がなくても、最初のデータが適切とは限らない。

手作業なら、数字を見た時点で違和感に気付く場合がある。自動処理では、条件に合っていればそのまま次へ進む。

自動化を増やすほど、「処理が動いたか」だけではなく「何を入力として使っているか」を確認する必要が出てくる。

外部サービスをつなぐと認証も保守対象になる#

第9回で詰まったのはGA4の集計ロジックより、CloudflareからGoogle Analyticsへアクセスするための認証。

ローカルでData APIを実行できても、その認証状態をCloudflareのビルド環境へそのまま持っていくことはできない。

サービスアカウントのキーを作る案は組織ポリシーで止まった。そこでOAuthへ変更し、同意画面、スコープ、公開状態、Cloudflare側で使うSecretまで確認することになった。

自動化前は存在しなかった作業になる。

ローカルでAPI取得
↓
本番ビルドでも取得したい
↓
認証方法を決める
↓
Secretを管理する
↓
期限・権限・設定変更も確認する

外部サービスを1つ追加すると、APIだけでなく認証方式も仕組みの一部になる。

これは自動化の大きなデメリットになる。

クリック作業は減るが、止まったときに見る場所は増える。

Astroのコードだけを見ればよいわけではなく、GA4、Google Cloud、OAuth、Cloudflareのどこで止まっているかを切り分ける必要がある。

「処理成功」と「内容が正しい」は別に残る#

記事生成も同じになる。

AIへ下書きを作らせること自体は難しくない。画像も生成できる。Markdownも作れる。ビルドも自動で確認できる。

ただし、ビルドが通ったことは本文が正しいことを意味しない。

ゆまラボでは、ChatGPTとGeminiへ同じ質問を送り、Web検索の有無で回答を比較した。バージョン番号、上限値、API名、設定パスなどは、文章として自然でも現在の仕様とずれることがあった。

AI生成記事のファクトチェックを手順化する―Web検索比較で見えた確認箇所と編集方法

画像でも、依頼していない企業ロゴが生成画像へ入ったことがある。その画像は公開せず、企業ロゴや公式UIを生成画像へ入れないルールを追加した。

AIに記事の画像を作ってもらったら、頼んでいない企業ロゴまで出てきた

ここは機械的な成功判定だけでは完了できない。

Markdownが生成できた
ビルドが通った
画像ファイルが存在する
リンクが404ではない

という確認と、

本文の断定に根拠があるか
現在の仕様か
実体験として書いてよいか
画像を公開して問題ないか

という確認は別になる。

自動化すると前者はかなり減らせる。後者まで同じように扱うと、確認していない内容をそのまま公開しやすくなる。

数字から次の記事まで自動で決めるか#

第10回までで、アクセスデータをサイト表示へ戻すところまでは実装した。

ここからさらに進めるなら、人気記事の数字を次の記事候補へ使うこともできる。

よく読まれている記事
↓
関連テーマを抽出
↓
次の記事候補を作る
↓
記事を生成
↓
公開後のPVを再取得

ただし、これは現在のゆまラボで第10回までに実装した処理ではない。

ここまで自動にすると、数字が出ているテーマを繰り返し選びやすくなる。

ゆまラボには、GA4導入、Cloudflareの設定、画像生成の失敗など、アクセス数とは関係なく実際の作業から生まれた記事も多い。

アクセスデータは候補を出す材料には使える。ただ、何をサイトに残すかまでPV順だけで決めると、実験記録としての方向は変わってくる。

この判断は人間側に残したい。

自動化すると見えなくなる作業もある#

自動化は手順を減らすが、同時に途中経過を見る機会も減らす。

第10回の人気記事表示なら、ビルド時にData APIから数字を取得して上位3件が決まる。運用上は便利だが、毎回GA4の画面を見なくてもTOPが更新される。

これは目的どおりの動きになる。

一方で、ランキングの変化を人が見る機会も減る。

例えば、急に特定の記事だけPVが増えた、意図しないURLが集計対象に入った、アクセス元が偏った、といった変化は、自動表示だけを見ていると理由までは分からない。

自動化したあとも、必要なときに元データへ戻れる状態は残した方がよい。

「画面を毎日開く必要をなくす」と「元データを見なくてよい」は別になる。

ゆまラボで人間側に残したい部分#

第10回まで進めた状態で見ると、機械へ渡しやすい範囲はかなり広い。

横にスクロールできます

扱い	ゆまラボでの例
自動化しやすい	GitHubからCloudflareへのビルド・公開、UTM URL生成、GA4 Data API取得、PV順の集計、TOPの人気記事表示
AIへ任せて確認する	記事下書き、画像生成、要約、投稿文の作成、内部リンク候補
人が判断を残す	記事化するテーマ、事実確認、実体験として書ける範囲、公開可否、認証方式の変更、例外時の対応

ここで大事なのは、自動化率を高くすることではない。

第8回から第10回まででも、Data APIのコードを書けば終わりではなかった。

ローカルで取得する。

Cloudflareで使うための認証を決める。

組織ポリシーでサービスアカウントキーを作れないことを確認する。

OAuthへ変更する。

ビルドへ接続する。

取得したデータをTOP表示へ使う。

この途中には、機械処理と人の判断が何度も混ざっている。

個人ブログの自動化では、この境界を消すより、どこから先が自動で、どこで人が判断するのかを明示した方が運用しやすい。

自動化を追加するときは、少なくとも次を確認したい。

入力データが誤っていた場合、どこまで自動で反映されるか
認証や外部APIが止まった場合、どこで検知できるか
処理成功と内容確認を分けられているか
自動処理の結果から元データへ戻れるか
サイトの方向を決める判断まで数字やAIへ渡していないか

第10回まで進めた現在は、「自動化できるところを探す」段階から、「自動化した仕組みをどこまで信用して先へ進ませるか」を考える段階へ移っている。