同じ日に2つの自動化を作った
ある日、朝から晩まで自動化の構築をしていた。午前中はクライアントの広告データを集約するKPIダッシュボード。午後は自社のSNSアカウント用の自動投稿パイプライン。どちらも「手作業を減らす」という目的は同じだが、設計思想はまったく違うものになった。
この経験から、「何を自動化すべきか」の判断基準がはっきり見えたので書いておく。
自動化には2つの型がある
構築してみて気づいたのは、自動化には大きく2つの型があるということだ。
型1: データ集約型 — 散らばっている情報を1箇所にまとめ、見える状態にする。KPIダッシュボードがこれに当たる。
型2: アクション実行型 — 情報の収集から投稿・配信まで、行動そのものを自動化する。SNS投稿パイプラインがこれだ。
この2つは自動化の「深さ」が違う。型1は人間が判断するための材料を揃える。型2は判断の一部まで機械に委ねる。どちらを選ぶかで、設計がまるで変わる。
KPIダッシュボード — 判断材料を自動で揃える
広告運用のクライアント案件で、Google広告とYahoo広告のデータがBigQueryに流れ込んでいた。週次レポートは毎回、SQLを叩いてスプレッドシートに貼り、前週比を手計算していた。所要時間は毎週40分ほど。
やったことはシンプルだ。BigQueryにビューを3本作った。
- 週次サマリー（一般キーワードと自社名キーワードを分離）
- キャンペーン別の週次KPIと前週比
- 広告グループ別の週次KPI
これをLooker Studioに接続し、スコアカード4つ（費用・CV数・CPA・クリック数）、時系列グラフ、ピボットテーブルを配置した。インプレッションシェアの指標も追加している。
構築中にコールトラッキングデータのバックフィルが必要になり、81件の復旧とURL解析のバグ修正も発生した。「自動化の構築」には、こうした地味なデータ整備が必ずセットでついてくる。
ポイントは、このダッシュボードは何も判断しないということだ。数字を見るのは人間。CPAが上がったら入札を調整するかどうか決めるのも人間。自動化しているのは「データを集めて並べる」工程だけである。
SNS投稿パイプライン — 行動の一部を自動化する
もう1つは、@AI_NoCodeMasterのX投稿を自動化するパイプラインだ。n8nのワークフローを2本作った。
ワークフロー1: 毎朝の情報収集。 GitHub Trending、Hacker News、Redditの3ソースからAI関連ニュースを自動収集する。重複を排除し、カテゴリに分類し、上位12件をNotionデータベースに「下書き」ステータスで書き込む。投稿文とハッシュタグも自動生成する。
ワークフロー2: 投稿の実行。 Notionでステータスを「投稿待ち」に変更すると、自動でXに投稿される。投稿後はステータスが「投稿済み」に更新され、投稿URLも記録される。単発ツイート、引用RT、スレッド投稿に対応した。
KPIダッシュボードとの最大の違いは、「投稿する」というアクションまで自動化している点だ。ただし、ここに意図的なブレーキを入れた。
人間を挟む設計が一番難しい
SNSパイプラインで一番こだわったのは、完全自動にしなかったことだ。収集した12件のニュースは「下書き」としてNotionに入る。そこから投稿するかどうか、投稿文を修正するかどうかは、人間がNotionの画面で判断する。
なぜ完全自動にしなかったか。理由は3つある。
- 品質リスク: 自動生成の投稿文がそのまま出ると、文脈を無視した内容やトーンのずれたものが混ざる
- レピュテーションリスク: 誤情報やセンシティブな話題を無審査で投稿するのは危険である
- 学習機会の喪失: 毎日ニュースに目を通すこと自体が、自分の情報感度を維持する手段になっている
一方、KPIダッシュボードのほうは人間を挟むポイントがない。データが流れ、ビューが集計し、ダッシュボードに表示される。この一連に判断は不要だ。「正しいデータを正しく集計する」という処理に、人間の介在は邪魔でしかない。
自動化すべきかを判断する3つの基準
2つの自動化を並べて見えた判断基準を整理する。
基準1: その作業に「判断」は含まれるか
データの集計や転記のように、入力と出力が1対1で決まる作業は全自動にすべきだ。人間がやる意味がない。逆に、投稿文の選定やトーン調整のように「良し悪しの判断」が入る工程は、人間を挟むか、少なくとも人間がレビューできる設計にする。
基準2: 失敗したときの被害範囲はどこまでか
KPIダッシュボードの集計ミスは、次の週次レポートで気づける。被害は「1週間の判断材料がずれる」程度だ。SNS投稿のミスは、不特定多数に即座に届く。取り消しても拡散後では手遅れになる。被害範囲が広いほど、自動化の手前に人間のゲートを置く。
基準3: 自動化で失われるものはないか
毎日のニュースチェックを完全自動にすると、自分が情報に触れる機会がなくなる。KPIの集計を手でやっても、学びはほとんどない。自動化で省略される工程に「副産物としての価値」がある場合、その工程だけ残す設計にする。
フレームワーク: 4象限で判断する
上記の基準をもう少し実用的にまとめる。自動化を検討するとき、次の2軸で考えると判断しやすい。
横軸: 判断の有無（機械的に決まる ←→ 人間の判断が必要）
縦軸: 失敗の影響範囲（内部で閉じる ←→ 外部に影響する）
- 機械的 × 内部: 全自動（例: データ集計、ファイル変換、バックアップ）
- 機械的 × 外部: 自動 + 監視アラート（例: 請求書発行、定型メール送信）
- 判断あり × 内部: 自動 + 人間レビュー（例: 社内レポートの要約生成）
- 判断あり × 外部: 半自動（例: SNS投稿、顧客対応、広告文作成）
今回のKPIダッシュボードは左上（機械的 × 内部）、SNS投稿パイプラインは右下（判断あり × 外部）に位置する。象限が違えば、設計も違って当然だ。
実務で得た教訓
1日で2つの自動化を作った結果、いくつか実感したことがある。
自動化の8割はデータ整備。 ダッシュボード構築の時間の大半は、SQLビューの設計とデータの欠損修復に費やした。コールトラッキングデータ81件の復旧やURL解析バグの修正は、自動化そのものより時間がかかった。「自動化しよう」と決めてから動くものができるまでの道のりは、思ったより泥臭い。
完全自動と半自動の境界をあらかじめ決める。 SNSパイプラインでは、Notionの「ステータス」プロパティが人間と機械の境界線になっている。この境界を設計段階で決めないと、あとから「ここは人間が見たほうがいい」「ここは自動でいい」の判断が曖昧になる。
自動化は目的ではなく手段。 KPIダッシュボードの目的は「広告運用の判断を速くすること」であり、ダッシュボードを作ること自体ではない。SNSパイプラインの目的は「情報発信の頻度を維持すること」であり、自動投稿すること自体ではない。目的を見失うと、自動化のための自動化になる。
まとめ
自動化すべきかの判断は、「できるかどうか」ではなく「すべきかどうか」で考える。判断の有無、失敗の影響範囲、自動化で失われるもの。この3つを検討すれば、全自動にすべきか、人間を挟むべきか、そもそも手動のままでいいかが見えてくる。
技術的にはどちらもn8nとBigQueryで1日あれば作れる。難しいのは技術ではなく、設計の判断だ。
あわせて読みたい
- Yahoo広告のデータをBigQueryに自動連携した話 — 今回のKPIダッシュボードの前段にあたる、広告データパイプラインの構築記事。
- AIツールを「社員」として組織化する方法 — 自動化の設計思想をさらに発展させ、AIエージェントを組織的に管理するアプローチについて。
