◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/Cowork
◈ Cowork/2026-06-30上級

3日前のローカルミラーで判断していた — 無人タスクが古い作業コピーを信じて二重作業する事故を止める

速度のために使い回す永続クローンは、いつの間にかリモートとずれます。同期を確かめないまま「この記事はもう直したか」を読みに行くと、無人タスクは古い木を信じて二重編集や空振り成功を起こします。HEAD 突き合わせと書き込み可否のプリフライト、自己修復の再クローンをbashで実装します。

Cowork46スケジュールタスク25自動化87git17信頼性5

✦ プレミアム記事

無人で回しているスケジュールタスクが「成功」とログに残しているのに、出来上がったものが一つ前の世界線のまま、ということがあります。私自身、個人開発で4つのAIブログ(Dolice Labs)をCoworkのスケジュールタスクで自動運用していて、ある朝のログでひやりとしました。「この記事はもう加筆済みか」を手元のクローンで確かめてから作業に入ったのですが、その手元のクローンが3日前のもので、実際にはすでにリモート側で別のランが同じ記事を更新し終えていたのです。あと一歩で、同じ記事を二重に書き換えるところでした。

エラーは一つも出ていません。git clone も成功し、ファイルも読めて、品質ゲートも通る。それでも判断の土台がずれていました。この種の事故は「失敗」ではなく「古い真実に基づく正しい処理」として起きるので、例外ハンドリングでは捕まりません。ここでは、永続クローンを「キャッシュ」として正しく扱い、意思決定の前に鮮度を契約として確かめる方法をまとめます。

なぜ永続クローンは黙ってずれるのか

速度のために、多くの自動化は作業リポジトリを毎回 clone し直さず、/tmp/repos/{site} のような場所に残して git pull --rebase で差分更新します。これは正しい最適化です。問題は、その永続クローンが「いつの時点のリモートか」を、後続の処理が暗黙に「最新」と信じてしまうことにあります。ずれは主に3経路で入ります。

1つ目は、別のランがすでに前進させているケースです。複数のスケジュール枠(朝の生成・昼の加筆・夜の復旧)が同じリポジトリを触る構成だと、自分が最後に pull してから他のランが push しています。手元の木はその push を知りません。

2つ目は、所有者が変わって pull 自体が静かに失敗するケースです。CoworkのVMではセッションをまたぐと /tmp/repos/ が nobody:nogroup 所有のまま残ることがあり、git pull も書き込みも弾かれます。リカバリで || true を付けていると、失敗したのに処理が前に進み、結果として古い木で判断します。

3つ目は、rebase が中途半端に終わっているケースです。前回のランが競合や中断で rebase を完了できず、デタッチドな状態や中途コミットを残していると、git log は一見もっともらしいのに最新ではありません。

いずれも共通するのは、読めるけれど古いという点です。だからこそ「読めたか」ではなく「最新と一致しているか」を確かめる必要があります。

stale な木の上での判断は、なぜ静かに壊れるのか

無人タスクが手元の木を読むのは、たいてい「処理」より前の「判断」のためです。たとえば次のような問いです。

判断の問いstale な木だと起きること
この slug はもう存在するかリモートで追加済みの記事を「無い」と誤認し、重複 slug を作る
この記事はもう加筆・修正したかすでに直っているのに「未対応」と見て二重に書き換える
日英の本数は一致しているか古いカウントで一致と判断し、実際の不一致を見逃す
直近で同じ題材を出したか古いログ・古い記事一覧で「未出」と誤判定し、題材が被る

判断が誤ると、その後の処理がどれだけ正しく動いても結果は壊れます。しかも壊れ方が「正常終了」なので、ログには Status: SUCCESS と残ります。私が肝に銘じているのは、検証されていない木の上で下した判断は、たとえ結論が正しく見えても無効として扱うという原則です。判断の前に木の鮮度を保証する。これを順序の問題として設計します。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦永続クローンが stale になる3経路(push後の他ランによる前進・所有者の nobody 化・rebase 半端)と、それぞれが意思決定読みをどう汚染するか
✦git ls-remote による local==remote HEAD 突き合わせ+ .git 書き込みプローブを1秒で済ませるプリフライト関数の実装
✦stale を検知したら pull --rebase で追いつき、不可なら $HOME へ fresh clone して自己修復する判断フローと、検証前の木で下した判断を無効化する設計
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

◈ Cowork2026-09-18
Cowork と Claude Code のどちらに置くかを、承認の挟まり方で決めています
同じ Claude が動く Cowork と Claude Code を、機能の比較ではなく「途中で人の承認が挟まってよいか」で置き分けている基準と、無人の面に残す書き方を実例つきでお伝えします。
◈ Cowork2026-09-16
定期タスクが動く日と動かない日があったのは、フォルダを1つ指定していたからでした
Cowork の定期タスクは既定でリモート実行ですが、手元のファイルやアプリを必要とした瞬間に端末実行へ切り替わります。作成画面の最後の一項目が実行場所を決めている仕組みと、タスクを作る前に決めておきたい三つの問いを書き残します。
◈ Cowork2026-10-01
定期タスクの手順書を削る前に、その一冊が何回読み直されるかを数えました
前読みの手順書を13KB削った見積もりは、再読込で数え直すと呼び出し約1.3回ぶんでした。削る前に何回読み直されるかを数える台帳と、実行中に読み込み量を残す関数をお伝えします。