◉CLAUDE LABEN
●2.1.289 — Claude Code 2.1.289(10月3日)。複合シェルコマンドの入れ子部分に対する deny/ask ルール、端末フリーズ、symlink 経由の Read deny を直しました●10/07 — Claude Desktop / Cowork の管理構成キー旧綴りの受付終了まで残り1日。締切後は fail-closed で読み込まれません●ACCOUNTS — Claude Desktop で複数アカウントを切り替えたい、という要望が GitHub で 200 件超のコメントを集めています。いまの運用でどこまで凌げるかが論点です●NEW — Claude Code が「コミットしないで」を無視した場面を、deny ルールと PreToolUse フックで切り分けました●COMPARE — Opus 5.5 と Sonnet 5.5 の使い分けを数字で比べた記事が Zenn に出ています。論点は用途ごとの線引きです●SONNET5.5 — Sonnet 5 のコードは 5.5 で5点壊れうるとされています。thinking の指定と tool_choice の強制指定は先に確認したい箇所です●2.1.289 — Claude Code 2.1.289(10月3日)。複合シェルコマンドの入れ子部分に対する deny/ask ルール、端末フリーズ、symlink 経由の Read deny を直しました●10/07 — Claude Desktop / Cowork の管理構成キー旧綴りの受付終了まで残り1日。締切後は fail-closed で読み込まれません●ACCOUNTS — Claude Desktop で複数アカウントを切り替えたい、という要望が GitHub で 200 件超のコメントを集めています。いまの運用でどこまで凌げるかが論点です●NEW — Claude Code が「コミットしないで」を無視した場面を、deny ルールと PreToolUse フックで切り分けました●COMPARE — Opus 5.5 と Sonnet 5.5 の使い分けを数字で比べた記事が Zenn に出ています。論点は用途ごとの線引きです●SONNET5.5 — Sonnet 5 のコードは 5.5 で5点壊れうるとされています。thinking の指定と tool_choice の強制指定は先に確認したい箇所です
記事一覧/Cowork
◈ Cowork/2026-07-01上級

上流タスクが今日ちゃんと動いたかを、下流タスクが自分で確かめる — 無人スケジューラの完了台帳と依存バリア

無人スケジューラには依存関係の概念がないため、朝の参照データ更新が静かに失敗しても、昼の生成タスクは前日の残り物でそのまま走り続けます。上流の完了を原子的に台帳へ記録し、下流が実行前に前提を検証する依存バリアの設計を、動くTypeScriptと私自身の運用体験で解説します。

Cowork43スケジュールタスク25自動化87依存関係信頼性5

✦ プレミアム記事

朝7時に走る参照データ更新タスクが、ある日ネットワークの瞬断で途中終了しました。ログには何の異常も残らず、ただ前日のファイルがそのまま残りました。問題はそこからです。昼12時に走る記事生成タスクは、その参照データを黙って読み、前日と同じニュースを題材に「新しい記事」を作って公開してしまいました。誰もエラーに気づかないまま、鮮度の落ちた成果物だけが積み上がっていく——無人スケジューラで最も静かで、最も厄介な事故のかたちです。

この事故の根っこは、コード上のバグではありません。多くのスケジューラには「タスクAが終わってからタスクBを走らせる」という依存関係の概念そのものが無い、という構造の問題です。各タスクは決められた時刻に独立して起動するだけで、上流が本当に今日ちゃんと動いたのかを下流は知りません。だから下流は「たぶん動いたはず」という暗黙の期待で走り出します。その暗黙の期待を明示的な検証に置き換えるために、ここでは**完了台帳(completion ledger)と依存バリア(dependency barrier)**という2つの部品を設計していきます。

「動いたはず」がなぜ危険なのか — 見落とされる3つ目の状態

依存関係を人力で考えるとき、私たちはつい2値で捉えます。上流は「成功した」か「失敗した」か。しかし無人運用で本当に効いてくるのは、多くの実装が取りこぼす3つ目の状態です。

状態意味下流が取るべき行動
未実行 (not-run)上流が今日まだ走っていない、または途中で落ちた止まる(劣化した成果物を作らない)
実行・空 (ran-empty)上流は正常に走ったが、今日は正当に成果物ゼロだったスキップする(エラーではない)
実行・産出 (ran-produced)上流が走り、下流が期待する成果物を出した進む

厄介なのは「実行・空」と「未実行」を区別できない実装が多いことです。たとえば下流が「参照ファイルが存在するか」だけを見ていると、前日の残骸が存在するために「未実行」を「実行・産出」と誤認します。逆に「ファイルが今日更新されたか」だけを見ていると、上流が正当に空を返した日(新しいニュースが無い日など)を「異常」と誤認して、無用にアラートを鳴らします。3状態をきちんと分けることが、依存バリアのすべての出発点になります。

私自身、複数サイトの自動投稿を回している中で、この「空でも正当」を異常扱いして下流を止めてしまい、静かなはずの休日にパイプライン全体が空回りしたことがありました。上流の意図(空を返すのは正常な結果だった)が下流に伝わっていなかったのが原因です。だから台帳には、成否だけでなく「意図された空」を表現できる語彙が要ります。

完了台帳のデータ構造

依存バリアの中核は、各タスクが1日の実行結果を書き残す小さな台帳です。派手なジョブキューは要りません。1行1レコードの追記型 JSON で十分機能します。まず語彙を型で固定します。

// ledger.ts
export type RunStatus = "ok" | "empty" | "error";
 
export interface RunRecord {
  task: string;            // 例: "daily-reference-and-ticker"
  date: string;            // JST の YYYY-MM-DD(日境界の正本)
  status: RunStatus;       // ok=産出 / empty=正当な空 / error=失敗
  fingerprint: string | null; // 産出物の内容ハッシュ。empty/error では null
  artifactPath: string | null;
  finishedAt: string;      // ISO8601(監査用)
  note?: string;           // 空や失敗の理由を人が読めるように
}

ここで status と fingerprint を別々に持つのが肝です。status: "empty" は「上流は責務を果たしたが、今日は正当に成果物が無かった」を意味し、fingerprint: null を伴います。これで「実行・空」と「未実行(そもそもレコードが無い)」が構造的に区別できます。date を JST 固定にしているのは、UTC のまま扱うと日境界がずれて前日のレコードを今日のものと取り違える事故が起きるためです。ここは過去に痛い目を見た箇所で、日付は必ずタイムゾーンを明示して生成するようにしています。

✦

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

この記事の続きを読む

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

この記事で得られること
✦『動いていない』『動いたが空だった』『動いて成果物を出した』の3状態を取り違えると、無人パイプラインが静かに劣化する仕組みと、状態を区別する台帳の設計
✦上流タスクの完了を原子的に記録し、下流が実行前にassertする依存バリアを、フィンガープリント照合つきの動くTypeScriptで実装する手順
✦スケジューラにDAGが無い前提で、複数サイトの自動投稿を回してきた中で私自身が採ってきた『前段を信じない』運用判断
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

◈ Cowork2026-09-18
Cowork と Claude Code のどちらに置くかを、承認の挟まり方で決めています
同じ Claude が動く Cowork と Claude Code を、機能の比較ではなく「途中で人の承認が挟まってよいか」で置き分けている基準と、無人の面に残す書き方を実例つきでお伝えします。
◈ Cowork2026-09-16
定期タスクが動く日と動かない日があったのは、フォルダを1つ指定していたからでした
Cowork の定期タスクは既定でリモート実行ですが、手元のファイルやアプリを必要とした瞬間に端末実行へ切り替わります。作成画面の最後の一項目が実行場所を決めている仕組みと、タスクを作る前に決めておきたい三つの問いを書き残します。
◈ Cowork2026-10-01
定期タスクの手順書を削る前に、その一冊が何回読み直されるかを数えました
前読みの手順書を13KB削った見積もりは、再読込で数え直すと呼び出し約1.3回ぶんでした。削る前に何回読み直されるかを数える台帳と、実行中に読み込み量を残す関数をお伝えします。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます