Claude Code停止は作業完了の誤認

この1か月の構成は意図的に平凡なものだった。Claude Codeには記事の下書きと予約公開、日次のページビューをデータベースとダッシュボードに収集する処理、静的サイトの編集とCloudflare Pagesへのデプロイ、そしてスケジュールタスクとWorker cronで起動する朝のタスクを任せた。障害は、アクションの実行とその結果の確認の間の継ぎ目に集中していた。最も明確なのは画像セットのタスクで、挿入は実行されたが最終保存が行われず、APIが空の画像フィールドを返した。

2つ目のパターンはカウントの誤りだった。4回にわたり、コードがページネーション付きAPIの最初のページしか読まなかった。JSONは有効に見え、多くのAPIはページビューの降順で並ぶため、取りこぼされた項目は常に低トラフィックのものだった。ある事例では合計ページビューが183と表示され、実際は189だったが、差が小さすぎて気づけなかった。担当者が選んだ対策はループを書き直すことではなく、カウントを第二のソースと照合することだった。統計APIの22件のレコードと、認証不要のAPIから取得した22件の公開記事を比較した。

3つ目のテーマは誤ったシグナルに対する検証だ。ある更新後、記事の長さが21,101文字から20,095文字に減り、復旧作業を促したが、実際には何も失われていなかった。サービスは保存のたびにブロック名とIDを再割り当てし、後の保存で21,101に戻った。ここでの争点はモデルの能力よりも担当者自身の規律にあるように見える。委任するタスクの幅が広がってもこうした外部チェック、記録、指示が機能し続けるか、そして未解決のスケジュール実行の停止が原因まで追跡されるかどうかだ。