Claude CodeのSkillsで寝てる間に仕事を回す方法¶
出典: Swarm｜東大AIエージェントラボ (@swarm_japan) — 2026-05-26 投稿。元記事は @cyrilXBT（N8N版）を、Claude Code の Skills + cron に置き換えて再構築した版。
TL;DR¶
- 自動化（固定スクリプト）とエージェント（judgment + 業務文脈 + 行動）は別物。同じ「新規メール受信」トリガーでも、出力がまったく違う。
- Ambient Agent は 4コンポーネントで成立:
Claude（判断）+CLAUDE.md（業務文脈）+MCP（ツール接続）+Skills + cron（起動・配線）。 - N8N のような外部ツールは要らない。Claude Code 自体を起動エンジンに据えれば、エコシステム内で完結する。
- CLAUDE.md は6ブロック（Business Identity / Active Clients / Communication Standards / Decision Authority / Quality Standards / This Week's Focus）。Decision Authority の二分が一番大事。
- 6ワークフロー（morning-briefing / email-triage / client-relationship-monitor / revenue-tracking / project-status-updater / weekly-review）を Skills として書き、cron 6行で起動。
- 30日進化過程: 1週目=ギャップ埋め / 2週後=編集量減 / 1ヶ月後=意思決定の元データ / 3ヶ月後=手放せなくなる。
経営者が自社のオペレーション層になっている¶
朝起きて PC を開き、メールを1通ずつ判断、Notion でステータス確認、Slack の未読を遡る。気がつくと午前中の半分が終わる——これは経営者が会社のオペレーション層を引き受けている状態。情報を A から B に動かすのも、ステータス更新も、繰り返しの確認も、全部自分を経由する構造的問題。
経営者がこの層にいる限り、戦略・顧客との深い対話・新プロダクト作成は常に後回しになる。
自動化とエージェントは別物¶
例: 新規リードからの問い合わせメール
| 自動化（Zapier/Make/IFTTT） | エージェント |
|---|---|
| あらかじめ用意したテンプレメールが返信される | CRMを見て過去のやり取りを確認 → 文脈引き継ぎ → 会社調査 → パーソナライズした下書き → タイムゾーン考慮で送信予約 → 3日後フォローアップタスク自動作成 |
主語が違う: - 自動化 = 人がワークフロー全体を設計し、AIを「文章生成のサブ処理」として呼ぶ - エージェント = AI自身がワークフローを進め、必要なときだけ人を呼ぶ
Ambient Agent を成立させる 4 コンポーネント¶
- Claude（判断層）: 状況を読み、業務文脈を当て、行動を決める中核。Claude API でも Claude Code でも可（記事は Claude Code 派）。
- CLAUDE.md（業務文脈層）: 会社のことを1ファイルに記述。Claude Code はセッション開始時に自動読み込み・システムプロンプト注入。
- MCP Servers（ツール接続層）: Gmail / Calendar / Notion / Stripe / Slack / Filesystem の6種類で経営オペはほぼカバー。
- Skills + cron（起動・配線層）:
.claude/skills/<name>/SKILL.mdの1ファイルで1業務を定義。cron +claude -p '/skill-name'のヘッドレスモードで起動。
→ 「呼べば動く」状態から「先に動く」状態へ。Human with AI tools → AI Agent with Human へ主語が移る。
CLAUDE.md の6ブロック¶
新人スタッフ向け業務マニュアルを毎週月曜に5分で更新する感覚で書く。
- Business Identity — 会社名、事業内容、顧客像、収益モデル、フェーズ、月次売上
- Active Clients — クライアント名、サービスタイプ、MRR、現状、次のアクション
- Communication Standards — メールのトーン、返信時間の約束、絶対言わない表現、メール冒頭/末尾の型
- Decision Authority（最重要） — AI が自走していい領域 / 必ず人間にエスカレーションする領域
- Quality Standards — 自社にとって「良い仕事」の定義
- This Week's Focus — 今週の優先事項を3行（毎週月曜に更新）
1人会社経営者向けCLAUDE.md サンプル¶
# Business Management Agent -- CLAUDE.md
## Business Identity
会社名: 合同会社○○
事業内容: 中小企業向けの業務改善コンサルティング（現場1体型支援）
顧客像: 従業員30-100名規模の地方の製造業・卸売業
収益モデル: 月額顧問契約 + プロジェクト報酬
フェーズ: 立ち上げ2年目
月次売上: ¥1,500,000（毎月更新）
## Active Clients
A株式会社（製造業）: 月額¥300,000 / 状況: 業務マニュアル整備中 / 次のアクション: 5月末に第1弾納品
B製作所（卸売業）: 月額¥250,000 / 状況: 来月から経理DX案件開始 / 次のアクション: キックオフMTG設定
C工業（製造業）: 月額¥200,000 / 状況: 月次レポート定期化 / 次のアクション: 5月分レポート提出
## Communication Standards
メールのトーン: 簡潔・直接的・丁寧
返信時間の約束: 24時間以内（営業日）
絶対言わない表現: 「お忙しいところ恐れ入りますが」「何卒よろしくお願い申し上げます」（冗長な定型句）
メール冒頭: 「○○様 お世話になっております。△△（自分の名前）です。」
メール末尾: 「よろしくお願いします。」
## Decision Authority
AIが自走していい領域:
- スケジュール調整の打診メール下書き作成（送信は人間が承認）
- 既存のドキュメントからのレポート生成
- Notionの社内プロジェクト進捗ステータス更新
- 内部システム間のデータ転送と整形
- 顧客向けではない内部メモの作成
必ず人間にエスカレーションする領域:
- 外部宛メールの送信実行
- 金融取引（請求書発行・支払い実行）
- クライアントへの新規コミットメント（納期約束・追加業務の受諾）
- 契約条件の変更
- 公開コンテンツ（SNS/ブログ）の投稿
## Quality Standards
「良い仕事」= 顧客の業務が実際に変わったか。納品物の見栄えではなく、運用1ヶ月後に顧客が継続的に使っているかで判定する。
## This Week's Focus（毎週月曜に更新）
- A株式会社の第1弾納品準備（金曜までに最終確認）
- B製作所のキックオフMTG日程確定（今週中）
- C工業からの追加問い合わせ対応（新規案件化の可能性）
保存先は ~/.claude/CLAUDE.md（ユーザーレベル）か、プロジェクトルートの CLAUDE.md。
推奨スタート: まず Business Identity と Decision Authority の2ブロックだけ書いて、残りは運用しながら埋める。Decision Authority が最初から書けていれば変な暴走は起きない。
6種類の MCP¶
| MCP | 用途 | パッケージ / エンドポイント |
|---|---|---|
| Gmail | メール読込・仕分け・下書き・キーワード監視 | Google公式リモートMCP gmailmcp.googleapis.com（OAuth 2.0） |
| Google Calendar | 予定読込・作成・衝突検知・ブリーフィング | Google公式リモートMCP calendarmcp.googleapis.com |
| Notion | プロジェクトDB読書・顧客レコード更新・レポート生成 | @notionhq/notion-mcp-server（npm、makenotion/notion-mcp-server） |
| Stripe | 売上モニタリング・決済失敗通知・MRR追跡 | @stripe/mcp または https://mcp.stripe.com（OAuth）。Restricted API Key（rk_）必須 |
| Slack | 通知・自動投稿・メンション対応 | @modelcontextprotocol/server-slack（2025-05にarchived、機能は生きてる）/ @zencoderai/slack-mcp-server（メンテ版フォーク） |
| Filesystem | ローカルファイル読書・Obsidian vault・レポート保存 | @modelcontextprotocol/server-filesystem（npx -yで起動） |
最初から6個全部繋ぐ必要なし。Gmail + Calendar の2個から始めて、業務が動いたら順次追加。設定先は
~/.claude/claude_desktop_config.jsonまたは.claude/mcp.json。
6 ワークフローを Skills として書く¶
Claude Code Skills は .claude/skills/<name>/SKILL.md のディレクトリ構造。YAMLフロントマター（name + description）+ Markdown本文。
- セッション開始時に全Skillの name + description だけプリロード（progressive disclosure）、必要時に本文ロード。
- 手動起動: /skill-name slash command
- cron 起動: claude -p '/skill-name'（ヘッドレスモード）
6つの業務完成品¶
| # | Skill | 起動 | 入力 | 出力 |
|---|---|---|---|---|
| 1 | morning-briefing | 平日朝のcron | 前日夕方以降メール + 今日予定 + プロジェクト状況 + Stripe昨日比 | URGENT / 今日のスケジュール（準備メモ付） / メール優先順 / プロジェクトアラート / 売上アップデート / 今日の1つの焦点 → ~/vault/daily-briefings/[DATE].md + Slack #daily-briefing |
| 2 | email-triage | 営業時間中2時間ごと | 過去2時間の未読メール | 5段階分類（CLIENT URGENT / CLIENT STANDARD / PROSPECT / VENDOR/ADMIN / AUTOMATED）+ URGENT&PROSPECTには下書き作成（送信はしない） |
| 3 | client-relationship-monitor | 週初め | Notion顧客レコード全部 | HEALTHY / ATTENTION NEEDED / AT RISK の3段階評価、チェックイン下書き、アップセル機会検出 |
| 4 | revenue-tracking | 月初 | 前月Stripe + 経費ファイル + 売上目標 | 売上サマリ（MRR/新規/拡張/解約/純増）/ 顧客別売上 / 経費サマリ / 予測 / 推奨アクション + コスト削減機会 |
| 5 | project-status-updater | continuous（5分間隔 + daily-notes監視） | 日次メモの DONE: [プロジェクト名] -- [タスク名] |
Notion該当レコードに完了マーク・タイムスタンプ・依存タスクREADY化・フェーズ進行・進捗率再計算・Slack通知 |
| 6 | weekly-review | 週末 | 過去7日の日次メモ + プロジェクト変化 + メール仕分けログ + 売上 + 顧客レポート | 前進したこと / 動かなかったこと / 繰り返しパターン1つ / 来週優先事項3つ / 今決めるべき1つの決定 |
SKILL.md サンプル（morning-briefing）¶
---
name: morning-briefing
description: 平日朝に、前日夕方以降のメール / 今日の予定 / プロジェクト状況 / 売上を集約して、URGENT / スケジュール（準備メモ付き）/ メール優先順 / プロジェクトアラート / 売上アップデート / 今日の1つの焦点を出力するSkill
---
# Morning Briefing Workflow
CLAUDE.md を読み込んだ上で、以下を実行します。
## Step 1: 情報収集
- Gmail MCP: 前日17時以降のメール全て
- Calendar MCP: 今日の予定（外部ミーティングは相手の過去メール + Notionの顧客レコード参照）
- Notion MCP: 進行中の全プロジェクト（overdue / 期限接近を抽出）
- Stripe MCP: 昨日からの取引とアラート
## Step 2: 出力
以下のフォーマットで `~/vault/daily-briefings/[YYYY-MM-DD].md` に保存。
- URGENT（午前中対応必須）: [リスト]
- 今日のスケジュール: [準備メモ付き]
- メール優先順: [今日返信必要なもの]
- プロジェクトアラート: [要注意なもの]
- 売上アップデート: [主要数字]
- 今日の1つの焦点: [今日いちばん大事な仕事]
## Step 3: 通知
Slack の #daily-briefing にサマリ投稿。
推奨スタート: 最初は morning-briefing 一択。朝の運営全体像が出来上がっていることの体感変化が一番大きく、ここで効果を感じると残り5つを書く動機が湧く。email-triage から始めると下書き精度調整に時間を取られて疲弊しがち。週1つずつ追加すると2ヶ月で全6本が回る。
Claude Code 自体を起動エンジンにする¶
元記事は N8N を起動エンジンとしているが、本記事は Claude Code 自体を起動エンジンに据える。
| N8N の役割 | Claude Code 内での代替 |
|---|---|
| スケジューラ | cron（Mac=launchd、Linux=systemd でも可） |
| トリガー | claude -p '<prompt>' のヘッドレスモード |
| データ受け渡し | SessionStart 時に CLAUDE.md + Skills を自動ロード |
| Claude API 呼び出し | 不要（Claude Code 自体が動く） |
| 出力先書き込み | Filesystem MCP + Skill 内で完結 |
| ログ | セッションログ + Slack MCP 通知 |
crontab はこの6行だけ¶
0 6 * * 1-5 cd ~/business && claude -p "/morning-briefing"
0 9,11,13,15,17 * * 1-5 cd ~/business && claude -p "/email-triage"
0 7 * * 1 cd ~/business && claude -p "/client-relationship-monitor"
0 8 1 * * cd ~/business && claude -p "/revenue-tracking"
*/5 * * * * cd ~/business && claude -p "/project-status-updater"
0 19 * * 0 cd ~/business && claude -p "/weekly-review"
Claude Code 起動エンジンの優位性¶
| 軸 | N8N + 外部ツール | Claude Code |
|---|---|---|
| (a) judgment の品質 | Trigger Nodeは固定配線。分岐ノードを大量に書く必要あり | AIが業務文脈を読み分けて処理を変えられる |
| (b) コンテキスト統合 | 毎回パラメータで渡す、文脈が断片化 | CLAUDE.md + Skills が自動ロード、This Week's Focus 更新で全6本に反映 |
| (c) 自己進化 | 人がGUIを開いて編集する必要 | AIが SKILL.md に学習を書き戻して4回目から自動適用 |
| (d) コスト効率 | DigitalOcean droplet（月5ドル～）+ 初期設定 | Pro/Max/Team プランがあれば cron 1行で動く。Claude Code Routines（クラウド実行、研究プレビュー段階）も可 |
シェフは同じでも調理場が違う。Claude Code は Skills + Subagents + Hooks + MCP + cron をひとまとめにした「AIが業務文脈を持ったまま判断・実行できる調理場」として設計されている。
技術寄り拡張ポイント¶
- Subagent（
.claude/agents/<name>.md）: 専用の役割とツールセットを持つ独立エージェント。Skill 内から呼べる。メール仕分け精度向上や顧客分析専門化に。 - SessionStart hook: Claude Code 起動時に前回ログを要約して context にロード。
最初の30日：CLAUDE.md を毎日触る¶
| 期間 | 状態 |
|---|---|
| 1週目 | CLAUDE.md のギャップが次々表面化（トーン違い、優先順位ずれ、タスク漏れ等）。気づくたびに2分で編集して埋める。 |
| 2週後 | 出力の編集量が目に見えて減る。「ここだけ直す」が普通に。 |
| 1ヶ月後 | ソース未確認で意思決定できる精度に。メール下書きが体調の良い日の文章に近づく。週次レビューが手動では見落としていたパターンを拾う。 |
| 3ヶ月後 | 手放せなくなる。 |
| 半年後 | 別の経営者をやっている感覚。日次オペレーションを手で回していた頃の仕事の仕方が思い出しにくくなる。 |
複利効果は最初から始まっている。目に見えるのは1ヶ月後、手放せなくなるのは3ヶ月後。1週目で「精度が低い」と止めると辿り着けない。
経営者が解放されると残る仕事¶
事務オペレーションがエージェントに移動した結果、手元に残るのは: - 戦略の判断 - 顧客との関係構築 - 創造的な意思決定 - チームの方針決め - 新サービスの設計 - 価格戦略の見直し - 市場変化への対応
→ 良い会社と素晴らしい会社の差を作る、判断業務だけが残る。
アクションアイテム¶
- [ ] CLAUDE.md サンプルの Business Identity と Decision Authority の2ブロックを自社情報で埋める
- [ ]
~/.claude/CLAUDE.mdか プロジェクトのCLAUDE.mdに保存 - [ ] Gmail MCP と Calendar MCP を繋ぐ（OAuth）
- [ ]
.claude/skills/morning-briefing/SKILL.mdを1枚書く - [ ] crontab に
0 6 * * 1-5 cd ~/business && claude -p "/morning-briefing"を1行追加 - [ ] 1週間運用してギャップを CLAUDE.md に埋め続ける
- [ ] 週1つずつ残り5本の Skill を追加していく
自分のメモ¶
- 既に
~/.claude/CLAUDE.md（グローバル）と~/yamamoto_obsidian/CLAUDE.md（プロジェクト）は持っている。Decision Authority ブロックは現状ない。経営/業務というより研究・転職・コーディングの判断境界として書き直す価値あり。 - 自分のユースケースに置き換えると:
- morning-briefing → 日報生成（GitHub PR、Zotero追加論文、Gmail未読、Calendar当日予定）
- email-triage → 転職活動メール（企業から / エージェントから / それ以外）の仕分け
- client-relationship-monitor → ショートリスト企業のステータス追跡（research済み/未済、最終接触日、次アクション）
- revenue-tracking → 該当なし（個人）
- project-status-updater → 研究タスク・面接対策タスクの進捗追従
- weekly-review → 既存の研究日誌の週次サマリ自動化
- 起動エンジンを Claude Code に統一する設計は、いま
~/temporal-workflowsや~/research-orchestratorを別建てしている方向と緊張する。「Temporal は人間の関与が薄い長時間ワークフロー」「Claude Code Skills + cron は judgment が必要な短時間ワークフロー」の住み分けで整理できそう。
作成: 2026-05-27 ／ 最終更新: 2026-05-27