はじめに

ある日、採用チームから「各媒体の広告数値を手動でまとめて分析してるんだけど、自動化できない？」と相談されました。

話を聞くと、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 は、そういう「まず試す」にフィットする選択肢でした。