AIワークフロー

Claude Code の TodoWrite + Edit + Bash 組み合わせで 6時間級の複合タスクを完走させた実装ログ (2026-05-21)

公開: 2026-05-21 · 著者: Sasaki Ryuji

破壊的アクション・本番デプロイ・FTP操作を含む 6時間複合タスクを Claude Code で完走させたフロー

個人開発の運用改善は、ときどき複数のサブタスクが重なって「半日で全部やる」展開になります。2026-05-21、自分のメディア3サイトの運用改善で、合計6時間で次の作業を完走する必要が出ました。本記事はその実工程記録です。

3サイト114記事のアフィリエイトリンク監査+カテゴリ別マッピング再設計+実装+デプロイ
朝の自動レポートのバグ2件修正
独自性チェックリストの仕様策定+memory化
低品質記事6本の本番から退避+301リダイレクト設定
D-style 独自記事3本の執筆+デプロイ
SAIKI集客 YouTube Shorts 自動投稿スクリプトの空ファイル問題発見+再実装
Pexels Video 背景方式への切替対応 (誤実装→修正)
Amazon もしも提携承認に伴う3サイトへの新規アフィ実装
GSC 404通知への即時 301 対応

これらをすべて Claude Code (Opus 4.7) と対話しながら、 1セッションで完走しました。鍵になった3つのツール、踏み抜いた4つの落とし穴、学んだメタパターンを共有します。

長時間タスクで効いた3つの Claude Code 機能

1. TodoWrite による 15分単位のタスク分解

6時間級のタスクで一番効くのが、最初に TodoWrite で全工程を 5-10個のサブタスクに分解することです。たとえば「アフィリンク監査と再配置」のフェーズではこう書きました。

1. affiliate-link-registry を読んで現状把握
2. ai-pick directory 構造を探査
3. lab/prompts 既存アフィ配置を grep
4. 監査レポートを docs/ に書き出し
5. ビルダー実装 (site-html-builder.mjs を改修)
6. site-config に affiliate.categoryMap 追加
7. ローカルビルド+検証
8. saas-diary に混入していないかチェック
9. 本番デプロイ (FTPS)

これを TodoWrite で一括登録、in_progress を1つだけ維持。各タスクが完了したら即 completed マーク。途中で新しい要件 (Amazon 提携承認の連絡など) が入ったら、その場で追加タスクを挿入します。集中力が分散する複合タスクで、これだけで「今どこにいるのか」を見失わずに済みました。

2. Read + Edit + Write の使い分け

Claude Code の Edit ツールは 編集前に同セッション内で Read していないと書き込みを拒否する仕様です。これは最初は煩雑に感じますが、結果的に「今どのファイルを触っているか」の把握が強制されて事故を防ぎます。私は何度かこのエラーに遭遇しました。

File has not been read yet. Read it first before writing to it.

新規ファイルは Write で作成 (Read 不要)、既存ファイル編集は Read→Edit、全面書き換えは Read→Write のフローで安定しました。とくに site-config.json のような複数サイト共有設定を編集するときは、まず Read で確認してから差分を絞った Edit を投入する、というパターンが事故率を下げます。

3. Bash 並列実行 + 標準出力解析

FTPS デプロイ+ビルド+ファイル削除のような I/O 重い操作は、Bash ツール経由で逐次走らせるよりも、独立した操作はワンコマンドで並列実行するほうが速いです。たとえば 3サイトのビルド+デプロイを以下のように1コマンドにまとめました。

cd /c/AI_WORK/ai-pick && echo "=== lab ===" && \
  node scripts/build-site-v2.mjs --site lab 2>&1 | tail -3 && \
  node scripts/deploy-site-v2.mjs --site lab 2>&1 | tail -3 && \
  echo "=== prompts ===" && cd prompts-site && \
  node scripts/build.mjs 2>&1 | tail -3 && \
  node scripts/deploy.mjs 2>&1 | tail -3

tail -3 で出力を3行に絞ることで、Claude Code 側のコンテキスト消費を抑えつつ、必要な「✅ Deploy complete」「Uploaded: 38 files」だけを拾えます。

踏み抜いた4つの落とし穴と即座のリカバリ

罠1: 動画レンダラの誤実装 (静止画スライド方式 vs Pexels Video 背景)

SAIKI YouTube Shorts の新スクリプト post-saiki-oneoff.mjs が0バイトの空ファイルだったので実装したのですが、最初は W5 旧スタイルの「テキスト+静止画」レンダラを使ってしまい、本番に投稿してしまいました。ユーザーから「動画の作り方が違う、Pexels API系を使うはず」と指摘されてようやく気づき、慌てて以下の対応をしました。

youtube-uploader.mjs に --make-private オプションを追加実装 (削除よりリバーシブル)
劣化版動画を即非公開化
正しい renderSaikiBgVideoReel (Pexels Video背景) を使うよう全面書き直し
正しい版を再投稿、履歴ファイルを別名で分離

この経験から学んだのは「新規実装する前に、既存の関連 memory を必ず Read する」というメタルールでした。事前確認していれば、Pexels Video 背景方式が現行標準だとすぐ分かりました。

罠2: GSC 404通知 (削除前 301設定漏れ)

独自性スコアが低い記事6本を「とりあえず本番から削除」してしまった結果、数時間後に Google Search Console から「ページがインデックスに登録されない新しい要因: 見つかりませんでした (404)」のメール通知が届きました。本来は 削除前に .htaccess に 301 リダイレクトを設定すべきでした。

事後リカバリの手順はこうなりました。

# .htaccess に追記
RedirectMatch 301 ^/instagram/<slug>/?$ /instagram/
RedirectMatch 301 ^/(en|pt|es)/instagram/<slug>/?$ /$1/instagram/

デプロイ後、curl -sI <旧URL> で Status 301 + Location ヘッダを確認。これで Google が再クロール時に「Page with redirect」として認識し、404 評価から解放されます。記事削除のフローは「301先に設定→デプロイ→検証→削除」の順序が鉄則です。

罠3: dotenv 環境のパス問題

FTP cleanup スクリプトを一時ファイル /tmp/ftp-delete-old.mjs に書いて実行したら、Cannot find module 'basic-ftp' エラー。原因はプロジェクト外のディレクトリで実行したため node_modules にアクセスできなかったことです。対策はシンプルで、スクリプトを scripts/_ftp-cleanup-stale.mjs としてプロジェクト内に配置してから実行 → 完了後に削除、というフローにしました。

罠4: 空ファイル運用の事故

post-saiki-oneoff.mjs が0バイトだった原因は、おそらく前のセッションで「ファイル名だけ touch して中身を入れ忘れた」状態でした。Node は0バイトのスクリプトを実行すると exit code 0 で即終了するため、Windows Task Scheduler は「成功」と判定してしまい、エラーログにも何も残らないサイレント死になっていました。再発防止として、main() 関数の .catch() ハンドラに Discord 通知を仕込みました。

main().catch(async (e) => {
  console.error('\n💥 エラー:', e.message);
  const { notify } = await import('./lib/notify.mjs');
  await notify(`🔴 SAIKI YouTube Shorts 失敗\n${e.message.substring(0, 500)}`);
  process.exit(1);
});

長時間タスクで効いた4つのメタパターン

パターン1: 「破壊的アクション」を最初にリストアップ

記事削除・FTP からのディレクトリ削除・本番デプロイは、すべて事前にリストアップして実行順序を決めてから動くのが鉄則でした。私は今回「削除→デプロイ→検証→確認」の順を守らずに、削除を先行させて 404 通知を引き起こしました。次回は「破壊的アクション」を Todo の中で明示的にマーキングするつもりです。

パターン2: ユーザー指示の「全部やって」は判断委任を意味しない

ユーザーから「やれることをどんどん」と指示されたとき、勝手に大量の作業を投入したくなりますが、破壊的アクションだけは事前確認するべきでした。たとえば「記事削除」「FTP からの削除」「ユーザーアカウントの状態変更」などです。実装系は自走OKだが、データ消失系は1ステップ手前で報告するべき、という線引きを学びました。

パターン3: memory ファイルを「最初に Read」する習慣

個人開発で蓄積した運用ノウハウは memory ファイル (Claude Code の ~/.claude/projects/.../memory/) に記録します。長時間タスクの開始時、関連プロジェクトの memory を Read してから実装に入ると、「現行標準」を見落とすミスを防げます。今回 Pexels Video 背景方式の memory を Read していなかったため、誤実装で1時間以上のリカバリが発生しました。新規実装の最初の5分は memory Read に使うのが効率的です。

パターン4: 1セッション内で完結させる工夫

長時間タスクは途中で休憩を挟むと、Claude Code 側のコンテキストが膨らみ、ツール呼び出しが遅くなります。1セッションで完結させるには:

Bash の出力は tail -N や head -N で必要部分だけ取得
大きな JSON は jq や node の eval で要約してから読む
Edit より Write を優先 (差分計算でコンテキスト消費が抑えられる場合あり)
Read は必要箇所だけ offset / limit 指定

これで6時間級の作業でも、コンテキスト消費を抑えて1セッションで完走できます。

結論 — Claude Code は「複合運用」の主力になる

従来「人がやる必要があった」運用 (監査・実装・デプロイ・記事執筆・障害対応・SEO 対策) を、1日6時間の対話セッションで全部やり切る経験は、個人開発者にとって生産性の桁を1つ上げる感触があります。重要なのは Claude Code を「コード生成ツール」ではなく「運用基盤の共同オペレータ」として扱うことです。

本記事の元になった作業ログは 3サイト114記事のアフィリンク最適化を Claude Code で半日完走させた実装ログも合わせてどうぞ。VPS 周りの設計は個人開発SaaS を ConoHa VPS 2GB プランで運用した実測ガイドにあります。