はじめに
ある日、採用チームから「各媒体の広告数値を手動でまとめて分析してるんだけど、自動化できない？」と相談されました。
話を聞くと、n8nで各媒体からスプレッドシートにデータが溜まるところまでは構築済み。ただ、そこから先の「数値を見て、分析して、レポートにまとめてSlackに投げる」がずっと手作業だったと。
やりたいことはシンプルなんですが、こっちもがっつりリソースを割ける状況ではなかった。なので「最速で作れて、渡した後に採用チーム自身でPDCAを回せる方法」を考えることにしました。
まずは検証として仕組みを作って渡して、向こうで回してみてもらう。精度が微妙なら別のアプローチを提案すればいい、という割り切りです。
なぜClaude完結にしたか — GAS / n8n拡張 / Python との比較
自動分析の仕組みを作る選択肢はけっこうあります。
| 方法 | 実装コスト | メンテナンス | 非エンジニアが触れるか |
|---|---|---|---|
| GASで分析ロジックを書く | 中〜高 | コード修正が必要 | 厳しい |
| n8nにClaude APIノードを追加 | 中 | n8nフロー編集が必要 | 微妙 |
| Pythonスクリプト + cron | 高 | コード修正が必要 | 無理 |
| Claude Code + Routines + MCP | 低 | スプシ編集だけ | できる |
決め手は2つ。
1. 実装コストが圧倒的に低い
コードを1行も書かずに動くものができる。MCP認証して、Routinesのプロンプトを書くだけ。数時間で検証まで終わりました。
2. 非エンジニアが自分でチューニングできる
ここが一番大きかった。GASやPythonで作ると、「分析の観点を変えたい」ってなった瞬間にエンジニアへの依頼が発生する。Claude完結なら、スプレッドシートの「分析設定」シートを書き換えるだけでレポートの内容が変わる。Routines再設定すら不要。
要するに、作って渡したら、あとは採用チームだけでPDCAを回せる。少なくとも狙いとしてはそう。実際にどこまで回るかはこれからの検証次第ですが、仕組みとしてそうなっているのが大事でした。
全体アーキテクチャ
仕組み自体はシンプルです。
Google Sheets（広告データ + 分析設定）
↓ Claude Code が Routines で自動読み取り
↓ 「分析設定」シートの指示に従って分析
↓
Slack に分析レポートを自動投稿
使っている技術要素:
-
Claude Code の Routines（
/schedule）: 定期実行のスケジューラー。Anthropicのクラウド上で動くのでPCがオフラインでもOK - MCP（Google Drive）: スプレッドシートの読み取り
- MCP（Slack）: レポートの投稿
n8nで各広告媒体からデータを収集してスプシに溜める部分は、採用チーム側で構築済みだったので、自分は「スプシ → 分析 → Slack投稿」のパイプラインだけ作ればよかった。
肝: 分析設定シート = プロンプトをスプシで管理する
この仕組みの一番のポイントは、分析ロジックをコードではなくスプレッドシートで管理していること。
スプシに「分析設定」というシートを1枚追加して、こんな感じで管理しています:
| 項目 | 設定値 |
|---|---|
| 分析観点 | 各媒体のCPFを比較し、前週比で+10%以上悪化した媒体を異常値として検出する |
| 改善提案 | CPFが高い媒体の改善アクション、予算配分の最適化案を3つ提案する |
| 出力形式 | サマリー → 異常値検出 → 好調な媒体 → CPF改善アクション提案 の4セクション構成 |
| Slackチャンネル | C0XXXXXXXXX |
| 補足指示 | 応募数が少ない媒体は費用対効果が悪いため、予算シフトを積極的に提案すること |
Routinesで実行されるプロンプトは「スプシを読み取って、分析設定シートの指示に従って分析して、Slackに投稿して」だけ。分析の具体的な観点・出力形式・投稿先は全部スプシ側で持っている。
だから、分析の切り口を変えたくなったらスプシを書き換えるだけ。
# 例: コスト削減重視にしたい場合
補足指示 → 「CPFが平均より高い媒体は予算削減を最優先で提案すること」
# 例: 新媒体を評価から除外したい場合
補足指示 → 「掲載開始から2週間以内の媒体はCPFが安定していないため、異常値判定から除外すること」
これ、よく考えるとプロンプト = 分析基準そのものなんですよね。
人間がスプシを見て判断するときも、「何を見るか」「何を異常とするか」は頭の中にある。それを言語化してスプシに書いただけ。むしろ分析基準が可視化・共有されている分、属人化しにくい。チーム内で「何を基準に判断してるか」がズレないのは地味にデカい。
セットアップ手順
実際の手順を書いておきます。
Step 1: MCP認証
Claude Codeで /mcp を実行して、Google DriveとSlackを認証。これでスプシの読み取りとSlack投稿ができるようになる。
Step 2: スプシに「分析設定」シートを追加
データが溜まるスプシに「分析設定」シートを追加して、分析観点・改善提案・出力形式・Slack投稿先・補足指示を記入。
いきなり書くのが難しければ、Claudeにスプシを読み込ませた上で「このデータで定期分析レポートを自動化したい。ヒアリングしながら分析設定シートを一緒に作って」と頼むと、対話しながら作れます。
Step 3: 手動テスト
まずは手動でこう実行:
スプレッドシート（ID: XXXXX）を読み取って、「分析設定」シートの指示に従って
データを分析し、指定されたSlackチャンネルに投稿して
Slackにレポートが投稿されたら、内容を確認。おかしければ分析設定シートを調整。
Step 4: Routines設定（/schedule）
手動テストでOKだったら、Routinesを設定:
以下の処理を毎週月曜9時に実行するRoutineを設定して:
1. Google Drive MCPでスプレッドシートを読み取る（ID: XXXXX）
2. スプシ内の「分析設定」シートに記載された分析観点・改善提案・補足指示に従ってデータを分析する
3. 分析設定シートの「出力形式」に従ってレポートを構成する
4. 分析設定シートの「Slackチャンネル」に指定されたチャンネルにSlack MCPで投稿する
これで完了。
分析精度の話 — 「AIの分析って大丈夫？」への答え
「プロンプトで分析して精度出るの？」って聞かれることがあります。
正直なところ、まだ検証段階なので「完璧に出ます」とは言えない。ただ、構造的にチューニングしやすい仕組みにはなっているかなと。
そもそも人間が手動で分析してたときも、「CPFが前週比で10%以上悪化してたら要注意」みたいな基準は暗黙的に頭の中にあったわけです。それを分析設定シートに言語化して書き出しただけ。基準が可視化されている分、「何がズレてるか」が特定しやすく、調整もしやすい。
なので、導入時のアプローチはこうしています:
- 最初の数週間は自動レポートと人間の判断を並走させる
- 「自動レポートではこう言ってるけど、自分の判断とズレてるな」があれば分析設定シートを調整
- PDCAを回すコストはスプシを編集するだけなのでほぼゼロ
精度が根本的に足りなければ、GASやn8n + Claude APIでもっと構造化されたパイプラインに切り替える選択肢もある。ただ、まずはこの軽い仕組みで「分析基準を言語化して回す」サイクル自体を立ち上げるのが先かなと。
注意点・ハマりどころ
構築・検証の過程でわかった注意点をいくつか。
Tips: Claude Codeの定期実行は2種類ある
Claude Codeで「定期実行」を組む方法は2つあって、特性がまったく違う。今回は Routines を使ったが、知らずに /loop で作ると挙動が変わるので整理しておきます。
/schedule（Routines） |
/loop（セッション内スケジュール） |
|
|---|---|---|
| スケジュール定義 | cron式（3 9 * * 1-5 など） |
cron式（同じ） |
| 実行環境 | Anthropicクラウド | ローカル（セッション内） |
| PCオフライン | 動く | 動かない |
| 有効期限 | なし（永続） | 7日で自動期限切れ |
| 用途 | 本番の定期実行 | 短期的な繰り返しタスク |
どちらも「cron式」でスケジュールを定義するので紛らわしいが、仕組みは別物。/loop はセッションに紐づくので、セッションを閉じたり7日経つと止まる。「あれ、動いてない？」ってなったらだいたいこれ。
長期で安定運用するなら Routines（/schedule）一択。
参考: Scheduled tasks - Seven-day expiry
MCP認証トークンの期限切れ
Google DriveやSlackのMCP認証トークンが切れることがある。切れた場合は /mcp で再認証すればOK。
スプシのカラム構成を変えたら分析設定も更新
n8n側で収集するデータのカラム構成を大きく変えた場合は、分析設定シートの分析観点も合わせて更新しないと、古いカラム名を参照して分析が壊れる。
まとめ
「採用チームの広告分析を自動化してほしい」という相談に対して、まずは検証用にClaude Code の Routines × MCP だけで仕組みを作って渡した話でした。
ポイントをまとめると:
- コードは0行。MCP認証 → 分析設定シート作成 → Routines設定の3ステップで動く
- 分析ロジックはスプシで管理。プロンプト = 分析基準という発想で、非エンジニアでもチューニングできる
- 向こうでPDCAを回せる仕組みにする。精度の調整もスプシ編集だけで完結するので、エンジニアが張り付かなくていい
「分析基準を言語化して、スプシで管理して、自動で回す」というサイクル自体は立ち上がった。精度が足りなければGASやn8n + Claude APIへの切り替えも視野に入れつつ、まずはこの軽さで回してみるフェーズです。
この仕組み、採用チームに限った話じゃなくて、定期的にスプシのデータを見て判断する業務なら同じパターンで試せます。営業の数値分析、マーケのキャンペーン効果測定、経理の異常値検出……スプシにデータが溜まっていて、分析の観点が言語化できるなら、検証のハードルはかなり低い。
「自動化したいけどエンジニアのリソースが足りない」って状況はけっこう多いと思います。まずは軽く作って渡して、向こうで回してもらう。Claude Code + Routines + MCP は、そういう「まず試す」にフィットする選択肢でした。