日常業務自動化の設計原則（shunya）

shunya（東大院生）が約半年間・45 個の cronジョブ自動化を通じて導き出した、長期運用できる自動化システムを作るための 4 つの原則。Claude Code を「考えるパーツ」として組み込む設計思想のまとめ。

原則1: 「判断」と「作業」を分離する

❌ メールが来たら自動で返信する（人間のチェックなし）
✅ メールが来たら下書きを生成する（送信は人間が判断）

AIには「下書き」「候補」「通知」を出させる。最終判断は人間。 AIへの過度な委任は品質問題・信頼性問題を招く。

接続ポイント

AI駆動開発ベストプラクティスの「人間が担うべき領域」（ボトルネックの特定・全体最適）と同じ発想。開発文脈だけでなく日常業務の自動化でも同様の原則が成立する。

毎日動くシステムは「動き続けること」が最重要。凝った実装より安定した実装を選ぶ。

❌ 壊れやすい	✅ 壊れにくい	理由
Google Calendar API	ICS URL	OAuth認証・トークン更新不要
Webスクレイピング	RSS + API	サイト変更の影響を受けない

通知先を Slack に統一することで、朝1回 Slack を開くだけで全状況を把握できる。

#ai-email       — メール分類結果
#ai-research    — 論文新着
#ai-news        — AIニュース
#ai-daily       — 日次レポート
#ai-system      — システムヘルスチェック

Slack を「情報集約レイヤー」として設計することで、複数ツールを巡回するコストをゼロにする。12 チャンネルで用途別に分離し、ノイズと重要通知を区別できる。

最初から大掛かりなシステムを構築しようとしない。小さく始めて必要に応じて育てる。

1日目:    「メールを取得してSlackに転送する」スクリプト（30行）
1週間後:  分類機能を追加（+50行）
1ヶ月後:  下書き自動生成を追加（+100行）

132 本のスクリプトも最初は数本から始まった。機能追加は「必要になってから」が運用継続のコツ。

接続ポイント

AI時代の仕事術（仕事の本質）の「ラスボス方式」（分からない部分を最初に倒す）とは逆のアプローチ。ただし文脈が異なる: 自動化システムの長期運用では「動くものを手元に持ち、育てる」戦略が有効。

[データ取得・加工] → Python スクリプト群
[判断・要約・分類] → Claude Code（Claude CLI）
[通知・出力]       → Slack（チャンネル別）
[定期実行]         → cron（45本、macOS上）

Claude は「考えるパーツ」として機能し、Python がデータを準備して Claude に渡し、判断結果を Slack に送る三層構造。