Cowork で4サイト×600記事を自動運用してみた

個人開発の合間に、AI ナレッジベースサイトを4つ運営しています。Claude Lab、Gemini Lab、Antigravity Lab、Rork Lab。合計600本を超える記事を日英2言語で公開しています。

「個人で4サイトも回せるの？」とよく聞かれるんですが、答えは Cowork のスケジュールタスクに全部任せている です。

今回は、この自動化の仕組みを実例とともに紹介します。うまくいった話だけでなく、盛大にハマった失敗談もそのまま書きます。これから Cowork で自動化を始める方の同じ課題に取り組んでいる方の参考になれば幸いです。

4サイトの構成と課題

まず、運用しているサイトの現状です。

4サイト合計で 1,100エントリ超（日英合計）。技術スタックは全サイト共通で、Next.js 16 + Tailwind CSS 4 + MDX → JSON プリコンパイル + Cloudflare Pages です。

課題はシンプルでしました。1人で4サイトの記事を毎日書くのは物理的に不可能 ということ。各サイトとも AI の最新情報を追いかけて、日英2言語で技術記事を書く必要があります。手作業でやっていたら確実に倒れます。

Cowork スケジュールタスクの全体設計

Cowork には「スケジュールタスク」という機能があり、定期的に Claude が自律的にタスクを実行してくれます。これを使って、記事生成を完全自動化しました。

タスク一覧（実際の運用構成）

現在動いているタスクは 20個以上 あります。主要なものを紹介します。

■ 日次記事生成（平日）— 4サイト × 6h間隔
claudelab-daily-content     : 0:00, 6:00, 12:00, 18:00（月〜金）
gemilab-daily-content       : 1:00, 7:00, 13:00, 19:00（月〜金）
antigravitylab-daily-content: 2:00, 8:00, 14:00, 20:00（月〜金）
rorklab-daily-content       : 3:00, 9:00, 15:00, 21:00（月〜金）

■ 日次記事生成（土日）— 4サイト × 4h間隔
claudelab-weekend-content     : 0:00, 4:00, 8:00, 12:00, 16:00, 20:00
gemilab-weekend-content       : 1:00, 5:00, 9:00, 13:00, 17:00, 21:00
...

■ プレミアム記事生成（毎日）
claudelab-premium-tue     : 毎日 4:50
antigravitylab-premium-tue: 毎日 4:10
rorklab-premium-tue       : 毎日 4:30
gemilab-premium-tue       : 毎日 5:30

■ 週次ブログ（毎週金曜）
claudelab-weekly-blog       : 金曜 10:30
antigravitylab-weekly-blog  : 金曜 13:30
rorklab-weekly-blog         : 金曜 16:30
gemilab-weekly-blog         : 金曜 20:30

■ メンテナンス系
news-ticker-weekly-update   : 毎週月曜 9:00
weekly-reference-update     : 毎週月曜 9:09
monthly-reference-update    : 毎月1日 10:00
weekly-premium-showcase     : 毎週水曜 10:00

なぜ時刻をずらしているか

4サイトのタスクは意図的に 1〜3時間ずつオフセット しています。理由は単純で、Cowork の VM リソースを分散させるためです。

4つのタスクが同時に走ると、git clone・npm install・ビルドが同時に走り、ディスク容量と CPU を食い合います。初期にこれで何度も失敗しました（後述）。

スキルファイル — 自動化の心臓部

Cowork のスケジュールタスクは、内部的に スキルファイル（SKILL.md） を参照して動きます。ここに「何をどう実行するか」を全部書いておくと、Claude がその手順に従って自律的に動きます。

スキルファイルの構成（7ステップ）

実際に使っているスキルファイルは、以下の7ステップで構成されています。

Step 0: リポジトリの準備（shallow clone → /tmp/repos/）
Step 1: 情報収集（公式ソース + Web検索 + 既存記事の重複チェック）
Step 2: 記事カテゴリ選定
Step 3: コンテンツ生成（MDX フロントマター + 本文 + 品質基準）
Step 4: 品質チェック（17項目のチェックリスト）
Step 5: ニュースティッカー更新
Step 6: ビルド＆プッシュ（generate-content.mjs → 件数検証 → git push）
Step 7: 記事更新ログの記録

Step 0 がすべての土台

最も重要なのは Step 0 の「リポジトリの準備」です。ここで学んだことが一番多い。

WORK="/tmp/repos/claudelab.net"
 
# ① ディスク残量チェック（750MB 未満は即中止）
FREE_MB=$(df /tmp --output=avail -m 2>/dev/null | tail -1 | tr -d ' ')
if [ "${FREE_MB:-0}" -lt 750 ]; then
  echo "⛔ ENOSPC予防: /tmp 残量 ${FREE_MB}MB"
  exit 1
fi
 
# ② shallow clone（転送量を最小化）
if [ -d "$WORK/.git" ]; then
  cd "$WORK"
  git pull --rebase origin main
else
  rm -rf "$WORK"
  git clone --depth 1 --branch main \
    "https://${GITHUB_TOKEN}@github.com/masakihirokawa/claudelab.net.git" "$WORK"
  cd "$WORK"
fi
 
# ③ npm install（キャッシュ活用）
npm install --prefer-offline 2>&1 | tail -3

なぜ /tmp/repos/ で作業するかというと、Mac のワークスペースフォルダでは git のロックファイル制約で操作が失敗する ことがあるためです。Cowork の VM は Mac のフォルダをマウントしているんですが、.git/index.lock や .git/HEAD.lock が Operation not permitted で削除できないケースがあります。

/tmp/repos/ なら VM 内のローカルファイルシステムなので、この問題が起きません。shallow clone（--depth 1）で転送量も最小限に抑えています。

Step 4: 17項目の品質チェックリスト

自動生成だからといって品質を妥協すると、読者はすぐ離れます。スキルファイルに品質チェックを17項目定義しています。

- [ ] タイトルにメインキーワードが含まれている
- [ ] description が160文字以内
- [ ] 文字数が3,000文字以上（日本語）
- [ ] コード例が最低1つ（コメント・期待出力付き）
- [ ] FAQ が最低3つ含まれている
- [ ] 内部リンクが2〜3件
- [ ] 日本語と英語の両バージョンが存在する
- [ ] 英語版が直訳ではなく英語ネイティブ向け
- [ ] MDX本文に「関連記事」セクションがない
  （RelatedArticles.tsx が動的に処理するため）
- [ ] MembershipCTA を手書きしていない
  （コンポーネントが自動表示するため）
...

特に最後の2つは 初期に何度もやらかした ポイントです。スキルファイルに明記していなかったときは、Claude が親切心で「## 関連記事」セクションを記事本文に書いてしまい、コンポーネントが生成する関連記事と二重表示になっていました。

失敗談① — ENOSPC（ディスク容量不足）で全タスク停止

自動化を始めて最初の1週間で起きた最大の障害です。

何が起きたか

Cowork の VM は /tmp に作業ファイルを置くんですが、4サイト分の node_modules が溜まると容量がパンクします。ある朝起きたら、4サイト分のスケジュールタスクが全部 ENOSPC で失敗していました。

⛔ ENOSPC予防: /tmp 残量 312MB — 記事を _pending に保存して終了

対処法

Step 0 にディスク残量チェックを入れました（前述のコード）。750MB 未満なら記事生成を中止し、記事データだけ _pending フォルダに退避する設計にしています。

さらに、npm のキャッシュを ~/.npm に保持して --prefer-offline でインストールすることで、毎回のダウンロード量を大幅に削減しました。

失敗談② — git push の競合で朝4本分の記事が消えた

何が起きたか

深夜に4サイトのスケジュールタスクが順次動き、それぞれ記事を生成して git push します。ところが、自分が寝ている間に手動で push したコミットと競合 し、rebase に失敗。結果、朝4本分の記事が push されずに消えていました。

厄介だったのは、/tmp/repos/ の作業ディレクトリが次のタスク実行時に git pull --rebase で上書きされること。未 push のコミットがあっても、次の実行で消えてしまう。

対処法

スキルファイルの Step 6 に push 前の pull --rebase を必須化 し、rebase 失敗時のリカバリ手順を追加しました。

# push 前に必ず rebase
git pull --rebase origin main
 
# rebase 失敗時は theirs で解決して続行
if [ $? -ne 0 ]; then
  git checkout --theirs .
  git add .
  git rebase --continue
fi
 
git push origin main

また、Step 7 でログを残すようにし、ワークスペースフォルダ（マウント先）にログを書く ことで、VM がリセットされても記録が残るようにしました。

[04:50 JST] claudelab.net
  Title (JA): Claude API ストリーミング実装ガイド
  Slug: claude-api-streaming-guide
  Category: api-sdk
  Status: SUCCESS

これで翌朝に「昨晩ちゃんと動いたかな」とログを見るだけで確認できます。

失敗談③ — 重複テーマの記事が量産された

何が起きたか

自動化を始めて2週目、記事一覧を見ると「Claude API の基本的な使い方」みたいな記事が微妙にタイトルを変えて3本も生成されていました。

Claude はスキルファイルの指示には忠実なんですが、「既存記事との重複チェック」が甘いと、似たテーマを何度も書いてしまいます。

対処法

Step 1 の情報収集フェーズに 既存スラッグの全件取得 を入れました。

# articles.json から全スラッグを取得して重複排除
node -e "
  const a = JSON.parse(require('fs').readFileSync(
    'src/generated/articles.json', 'utf8'
  ));
  console.log(a.articles.map(x => x.slug).join('\n'));
" 2>/dev/null || \
find content/articles/ja -name "*.mdx" -exec basename {} .mdx \; | sort

これをスキルファイルに明記することで、Claude が記事を書く前に「このテーマはもう書いたな」と判断できるようになりました。

さらに、週次で更新される リファレンスデータ（reference_data.md）にSEOキーワードとURLを集約し、「まだカバーしていないキーワード」を優先的にピックアップする仕組みにしています。

うまくいったこと — プレミアム記事の自動生成

逆にうまくいった話もします。プレミアム記事の自動生成 は期待以上の成果でしました。

各サイトに毎日1本ずつ、有料記事を自動生成しています。premium: true の記事は最初の約10,000文字を無料公開し、その先は Stripe 経由の課金で読める仕組みです。

ポイントは、スキルファイルで「有料に値する品質基準」を明確に定義した こと。

| `premium: true` にできる記事の例 |
|---|
| プロ向け実装ノウハウ（詳細コード付き） |
| 上級チュートリアル（5,000文字超） |
| API深掘り・設計パターン |
| 収益化・ビジネス戦略の詳細手法 |
| 有料級のテンプレート・プロンプト集 |

逆に、SEO・集客目的の記事は premium: false にするルールも明記しています。検索流入で初めて来た読者にいきなりペイウォールを見せると離脱率が上がるためです。

Cowork 自動化のアーキテクチャ図

全体の流れを図にするとこうなります。

┌─────────────────────────────────────────────────┐
│ Cowork スケジュールタスク（20+タスク）            │
│                                                 │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │Claude Lab│ │Gemini Lab│ │Antigrav. │ ...    │
│  │ 0:00起点 │ │ 1:00起点 │ │ 2:00起点 │        │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘        │
│       │            │            │               │
│       ▼            ▼            ▼               │
│  ┌──────────────────────────────────────┐       │
│  │ SKILL.md（7ステップの自律実行手順）   │       │
│  │                                      │       │
│  │ Step 0: shallow clone → /tmp/repos/  │       │
│  │ Step 1: Web検索 + 重複チェック       │       │
│  │ Step 2: カテゴリ選定                 │       │
│  │ Step 3: MDX記事生成（JA + EN）       │       │
│  │ Step 4: 17項目の品質チェック         │       │
│  │ Step 5: ニュースティッカー更新       │       │
│  │ Step 6: ビルド → git push            │       │
│  │ Step 7: ログ記録                     │       │
│  └──────────────────────────────────────┘       │
│       │                                         │
│       ▼                                         │
│  ┌──────────────────┐                           │
│  │ GitHub → Cloudflare Pages                    │
│  │ git push → 自動ビルド → 本番反映             │
│  └──────────────────┘                           │
└─────────────────────────────────────────────────┘

git push すれば Cloudflare が自動ビルド＆デプロイするので、記事の生成から本番公開まで完全に無人 で回っています。

数字で振り返る — 3週間の運用実績

自動化を本格稼働させてから約3週間（2026年3月初旬〜3月20日時点）の実績です。

92% の自動生成成功率は、正直まだ改善の余地があります。特に週末の4時間間隔はタスクが詰まりやすく、ディスク容量の問題が出やすい。今後は VM のクリーンアップを自動化するタスクを追加する予定です。

これから Cowork 自動化を始める人へ

3週間の運用で学んだことをまとめます。

1. スキルファイルは「最初から完璧」を目指さない

最初のスキルファイルは20行くらいの簡素なものでしました。運用しながら失敗するたびにルールを追加し、今の300行超になっています。いきなり完璧なスキルファイルを書こうとすると挫折するので、小さく始めて育てる のがおすすめです。

2. ログは必ずマウント先に残す

Cowork の VM はセッションごとにリセットされます。/tmp/ に書いたログは消えます。ログは必ず ワークスペースフォルダ（Mac 側のマウント先） に書くようにしましょう。

3. タスクの時刻はずらす

同時実行はリソースの奪い合いになります。4サイト同時に動かすと確実に失敗します。最低1時間、できれば2時間はオフセットしましょう。

4. push 前の rebase は絶対

手動でのコミットとスケジュールタスクのコミットが競合するのは日常茶飯事です。push 前の git pull --rebase はスキルファイルに必ず書いてください。

5. 品質チェックリストはケチらない

自動生成だからこそ、品質基準を厳密に定義する必要があります。最初は「まぁいいか」と思っていた項目が、100本目あたりで「やっぱり書いておけばよかった」になります。

全体を振り返って

Cowork のスケジュールタスクを使えば、個人開発者でも4サイト×600記事規模の運用が現実的に可能です。

ただし、「設定して放置」では確実に事故が起きます。スキルファイルの品質基準、ディスク容量の監視、git 競合の対処、重複テーマのチェック——こうした 運用ノウハウこそが本当の資産 です。

スキルファイルは最初から完璧を目指さず、失敗するたびに1行ずつ育てていく。それが3週間で300行の「自分専用オペレーションマニュアル」になりました。

Cowork の自動化に興味がある方は、まず1サイト・1タスクから始めてみてください。1週間も回せば、このスキルファイルに何を追記すべきか、自然と見えてきます。