「AIに任せて業務を自動化する」という発想は、この1〜2年で経営者・マーケター・1人メディア運営者の間に急速に広がっています。しかし実際にやってみると、最初の構築よりも「動き続けさせる」ことの方がはるかに難しい、と気付く方が多いのではないでしょうか。

PIGNOTEでも、毎朝のGA4・Slack自動レポートをAIに任せて構築する過程で、3つの大きな罠に遭遇しました。本記事はこれらを「自動化を任せる側の心構え」として整理し、同じ罠に困っている方の参考になることを目的としています。

技術的な詳細を追わなくても、各章末の「💡 ここで言いたいこと」だけを読み飛ばしていただいても本筋は伝わるよう構成しています。

何が動いているか(完成形)

PIGNOTE運営チームが構築した自動化は、以下のように動いています。

• 毎朝08:30、Slackに /column/ 配下のセッション数、CV発生状況、追跡記事の動きが届く
• PCがスリープ状態でも、朝起動した瞬間に自動でキャッチアップ実行される
• 異常検知(セッションの急減・急増、CV発生)があれば、絵文字付きで強調表示

レポートに含まれる情報は以下の通りです。

項目	内容
昨日のセッション合計	/column/配下のみ
前日比	vs 一昨日
前週同曜日比	vs 7日前
3日トレンド	直近3日 vs 前週同期3日
アラート	急減/急増/CV発生時に絵文字で通知
追跡記事4本の単日セッション	リライト直後の重点記事
トップ10ページ	昨日の上位

💡 ここで言いたいこと
自動化の出発点は「いつ・何が・どんな形で届くか」を最初に明文化することです。これが曖昧だと、AIに依頼するときも、後から検証するときも軸がぶれます。

なぜ自動化を選んだか

PIGNOTEの朝の業務には、以下の確認作業が含まれます。

• /column/配下の昨日のセッション数
• 直近リライト記事のSearch Console推移
• 主力キーワードの順位変動
• セッションの急減・急増
• CV(コンバージョン)発生の有無

これを手動でやると、GA4の画面、Search Consoleの画面、スプレッドシートの間を行き来して、毎朝15〜30分かかります。1日30分でも、年間では約180時間。記事リライト1〜2本分に相当する時間です。

「データを見る時間」より「データから判断する時間」に集中したい。これが自動化に踏み切った動機でした。コードは書けなくても、AIに頼める時代です。

💡 ここで言いたいこと
自動化は「楽したい」ではなく「自分が判断に集中するための時間配分」と捉えると、何を任せて何を任せないかが整理しやすくなります。

1回目の実装と、ある日壊れた話

最初は、Claude Codeに「毎朝GA4を見てSlackに投げて」と日本語で依頼しました。返ってきたのは、bashスクリプトと、それを毎朝決まった時刻に起動する設定(crontab)を組み合わせる構成でした。crontabには次の1行が登録されました。

0 10 * * * ~/pignote-report/daily_report.sh

これで毎朝10:00、自動で実行される予定でした。最初の1ヶ月は、毎朝正常なレポートがSlackに届いていました。

ところが運用開始から数週間後、ある朝突然、Slackに届くレポートが一行だけになっていました。

Not logged in · Please run /login

最初は「ログイン期限が切れただけだろう」と思いました。しかし手動で同じスクリプトを実行すると、正常なレポートが生成されます。何かが、自動実行のときだけ認証情報を見失っている、という現象でした。

💡 ここで言いたいこと
自動化は「作って終わり」ではありません。壊れた時に通知が届く設計にしておかないと、何日も「動いているつもり」が続いてしまいます。

原因は技術的にマニアックだった

調べてみると、原因はmacOS特有の仕様にありました。簡単に言うと、Macが自動でプログラムを動かすときに使う仕組み(cron)は、ユーザーのパスワード保管庫(キーチェーン)にアクセスできないようになっています。

このセキュリティ上の制約により、AIに任せていたClaude CLIの認証情報がcronから見えなくなり、毎朝「ログインしてください」とエラーを返していたのです。

これは、運営チームにとっては完全に初耳の話でした。けれど、AIに「なぜ動かないのか」と聞いたら、数分で原因にたどり着きました。

💡 ここで言いたいこと
自動化の運用で大事なのは「自分で全部理解する」ではなく「AIに正しく問題を伝えるスキル」です。エラーメッセージを正確に貼り、いつから動かなくなったかを伝えると、AIは原因と対処の候補を整理してくれます。

解決策の比較と選択

AIに「これを直すにはどうしたらいい?」と聞いたところ、4つの選択肢が返ってきました。

案	概要	採用
cron維持 + 認証情報を別途渡す	設定を工夫してcronから認証を読めるようにする	× セキュリティ的に好ましくない
GitHub Actions経由でクラウド実行	別のサービスから自動実行する	△ 初期設定の手間が大きい
Anthropicのクラウドリモートエージェント	専用機能を使う	× 必要なコネクタが未対応
launchd(LaunchAgent)に切り替え	macOSが本来推奨している別の仕組みを使う	◎ 既存スクリプトをほぼそのまま活かせる

選んだのはlaunchdへの移行でした。決め手は「自分(とAI)でメンテし続けられるか」の一点です。

💡 ここで言いたいこと
選択肢が複数あるとき、「最先端か」「人気か」より「3ヶ月後の自分(やAI)でも触れる構成か」を優先すると、自動化の寿命が伸びます。

launchdに移行した話

launchdとは、macOSが標準で持っている「ジョブ管理の仕組み」です。Appleも近年はcronよりlaunchdの利用を推奨しています。

設定の中で、起動時刻を指定する部分だけ抜き出すと次のような形になります(全文は記事末尾の付録に掲載)。

<key>StartCalendarInterval</key>
<dict>
    <key>Hour</key>
    <integer>8</integer>
    <key>Minute</key>
    <integer>30</integer>
</dict>

「Hour=8、Minute=30」と書いてあるだけで、毎朝08:30に起動するようになります。これをAIに頼んで作ってもらい、自分はその時刻だけ確認すればOKでした。

launchdに乗り換えてからの嬉しい副作用が一つありました。Macがスリープしていても、起動した瞬間に未実行のジョブを自動で実行してくれるのです。

PIGNOTE運営チームのスタイル(08:00〜08:30の間にPC起動)と相性が良く、起動が遅れた朝でも、開いた瞬間にレポートがSlackに届きます。

💡 ここで言いたいこと
移行コストが小さい解決策を選ぶと、「壊れたら自分で直す」のハードルがぐっと下がります。AIに任せるときも、後で自分が把握しやすい仕組みを選ぶことが大切です。

罠その1:APIの一時障害

launchdへの移行で認証問題は解決しましたが、運用開始直後に別の壁にぶつかりました。

ある朝のSlackには、レポートではなく「API Error: 529 Overloaded」というエラーメッセージだけが届いていました。AIサービス側で一時的に混雑し、リクエストが弾かれていたのです。数十分後には自動で解消する種類のものでしたが、毎朝の自動配信が「たまたまその瞬間に過負荷だった」という理由で空振りすると、運用としては痛い損失です。

そこでAIに「60秒待ってもう一度試す、それでもダメなら180秒待ってもう一度、計3回試す」というロジックを組み込んでもらいました。3回失敗したらエラーメッセージをそのままSlackに通知します。「黙って失敗する」を絶対に作らないのがポイントです。

💡 ここで言いたいこと
自動化の失敗には2種類あります。①一時的な障害=リトライでフォロー。②構造的な不具合=即通知で気付く。両方を設計に組み込んで初めて「運用できる自動化」になります。

罠その2:気付かれないバグ

ある朝、レポートに「前週同曜日比 -48.5%」という驚きの数字が出ていました。一見すると大事件です。

しかし、よく見ると比較対象がずれていました。「昨日(日曜日)」と「7日前(月曜日)」を比較していたのです。週末と平日のセッション数の差が単に出ているだけで、これでは「前週同曜日比」になっていません。AIが書いてくれたコードの中で、日付の数え方に1日分のズレがありました。

before / afterで並べると次のような違いでした。

# 間違っていた書き方
D1=$(date -v-1d '+%Y-%m-%d')   # 昨日
D7=$(date -v-7d '+%Y-%m-%d')   # 1週間前同曜日 ← 実は今日の7日前なので曜日がずれる

# 正しい書き方(昨日の1週間前 = 今日の8日前)
D1=$(date -v-1d '+%Y-%m-%d')   # 昨日
D8=$(date -v-8d '+%Y-%m-%d')   # 昨日(D1)の1週間前=同曜日

修正後、前週同曜日比は「-8.4%(6/21日曜 vs 6/14日曜)」となり、現実的な数字に着地しました。

💡 ここで言いたいこと
数字が自動で表示されると、人はそれを信じてしまいます。自動化開始後2〜3週間は「数字の正しさそのものを疑う」フェーズとして、手元の値と突き合わせる時間を取る必要があります。

罠その3:運用ドキュメントを残さない

ここまでの工程で、私たちが学んだ最大の教訓は「3ヶ月後の自分は、今の自分とは別人」ということです。

「あれ、これ何で動いてるんだっけ」「どこを直せばいいんだっけ」と過去の自分に困らされないために、運用ドキュメント(daily-slack-report.md)を残しました。中身は以下のような構成です。

• アーキテクチャ(どこで何が動いているか)
• アラート閾値(数値判定の根拠)
• トラブル時の確認コマンド
• 配信時刻や閾値の変更手順
• 過去の移行履歴(cron → launchd へ移った経緯と理由)

このドキュメントを最初からAIと一緒に作っておくと、後日「ここを変えたい」と思った時、AIにそのドキュメントを渡すだけで的確な修正が返ってきます。未来の自分への手紙、をAIに読ませるイメージです。

💡 ここで言いたいこと
一人運営の自動化は、「動かす」だけでは半年で破綻します。「動かし続ける」までを含めた設計が、運営者の本当の仕事です。

まとめ:AIに業務自動化を任せる側の3つの心構え

PIGNOTEがGA4・Slack自動レポートを構築する過程で踏んだ3つの罠を整理しました。技術的な詳細は端折りましたが、本質はとてもシンプルです。

① 失敗が見える設計(沈黙させない)

自動化のいちばんの敵は「壊れたのに気付かない」状態です。失敗時もエラーメッセージがちゃんと届くように設計しましょう。

② 自分でメンテできる選択肢を選ぶ(最先端より持続性)

新しい技術より、「3ヶ月後の自分が触れるか」を基準に選ぶ方が、運用寿命が長くなります。

③ 運用ドキュメントを残す(未来の自分への手紙)

動かす設計と、動かし続ける設計はセットです。AIにも読ませられる形のドキュメントを残しましょう。

「コードを書く」のはAIに任せる時代になりました。自動化を任せる側の役割は「業務を設計する」「壊れた時に気付く」「正しい問いを立てる」の3つに集約されます。私たちがやったように、最初は詰まることだらけかもしれません。それでも、AIと組めば一人運営の生産性は確実に上がります。

PIGNOTEの自動レポートが今朝もSlackに届いていることが、その証明です。

付録:スクリプトと設定ファイル全文

ここから先は、実装にご興味のある方向けの参考資料です。コピー&ペーストでそのまま使えるよう、関連する全コードを掲載します。

A. daily_report.sh(レポート生成スクリプト本文)

毎朝launchdから呼び出されるbashスクリプトです。GA4 / GSCのデータをClaude CLI経由で取得し、Slackへ送信します。

#!/bin/bash
SLACK_WEBHOOK="https://hooks.slack.com/services/..."
LOG_FILE=~/pignote-report/report_$(date '+%Y%m%d').log
CLAUDE_BIN=/usr/local/bin/claude

D1=$(date -v-1d '+%Y-%m-%d')
D2=$(date -v-2d '+%Y-%m-%d')
D3=$(date -v-3d '+%Y-%m-%d')
D8=$(date -v-8d '+%Y-%m-%d')
D10=$(date -v-10d '+%Y-%m-%d')

PROMPT="(レポート生成のための日本語プロンプト。GA4のセッション・前日比・前週比・CV・追跡記事を取得し、Slack向けに整形してくださいという指示)"

REPORT=""
for ATTEMPT in 1 2 3; do
    REPORT=$("$CLAUDE_BIN" --dangerously-skip-permissions -p "$PROMPT" 2>&1)
    if ! printf '%s' "$REPORT" | grep -qiE 'API Error: (5[0-9]{2}|429)|Overloaded'; then
        break
    fi
    [ "$ATTEMPT" -lt 3 ] && sleep $((ATTEMPT * 60))
done

printf '%s\n' "$REPORT" > "$LOG_FILE"

SLACK_TEXT=$(/usr/bin/python3 -c 'import sys; sys.stdout.write(sys.stdin.read()[:3500])' <<<"$REPORT")
PAYLOAD=$(/usr/bin/jq -n --arg t "$SLACK_TEXT" '{text: ("```\n" + $t + "\n```")}')

curl -s -X POST "$SLACK_WEBHOOK" \
  -H 'Content-type: application/json' \
  --data "$PAYLOAD"

B. com.pignote.daily-report.plist(launchd設定ファイル)

~/Library/LaunchAgents/com.pignote.daily-report.plist に配置する.plistファイルの全文です。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.pignote.daily-report</string>

    <key>ProgramArguments</key>
    <array>
        <string>/Users/username/pignote-report/daily_report.sh</string>
    </array>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>8</integer>
        <key>Minute</key>
        <integer>30</integer>
    </dict>

    <key>StandardOutPath</key>
    <string>/Users/username/pignote-report/launchd.out.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/username/pignote-report/launchd.err.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/usr/bin:/bin</string>
        <key>LANG</key>
        <string>ja_JP.UTF-8</string>
    </dict>

    <key>RunAtLoad</key>
    <false/>
</dict>
</plist>

C. 既存cronエントリのコメントアウト形

旧cronエントリを残したい場合の記法です。

# [disabled 2026-06-22: replaced by launchd]
# 0 10 * * * ~/pignote-report/daily_report.sh

D. launchctlによる登録コマンド

LaunchAgentを有効化するための1セットです。

launchctl load ~/Library/LaunchAgents/com.pignote.daily-report.plist
launchctl list | grep pignote
# -> -    0    com.pignote.daily-report   ← 待機中で登録成功

E. セッション情報の確認コマンド

キーチェーンに認証情報が残っているかを確認する方法です。

$ security find-generic-password -s "Claude Code-credentials"
keychain: "/Users/.../Library/Keychains/login.keychain-db"
class: "genp"
attributes:
    0x00000007 <blob>="Claude Code-credentials"

F. APIエラー時のリトライ実装

APIが過負荷で「529 Overloaded」を返したとき、60秒→180秒で再試行するロジックです。

REPORT=""
for ATTEMPT in 1 2 3; do
    REPORT=$("$CLAUDE_BIN" --dangerously-skip-permissions -p "$PROMPT" 2>&1)
    # 一時エラーでなければ抜ける
    if ! printf '%s' "$REPORT" | grep -qiE 'API Error: (5[0-9]{2}|429)|Overloaded'; then
        break
    fi
    [ "$ATTEMPT" -lt 3 ] && sleep $((ATTEMPT * 60))
done

G. APIエラーメッセージの参考

過負荷時に返ってくるエラーメッセージの実例です。

API Error: 529 Overloaded. This is a server-side issue, usually temporary
— try again in a moment. If it persists, check https://status.claude.com.