CLAUDE LABEN
SUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は8月17日です。残り2日となりましたLATEST — 最新は8月13日の v2.1.231 です。事前登録済み OAuth クライアントを使う MCP サーバーでのサインイン失敗が直っていますRESUME — 8月12日の v2.1.229 で、`claude remote-control --continue` により直近の Remote Control セッションを再開できるようになりましたSTREAM — 長い思考の待ち時間にストリーミングが idle timeout で切れる問題に対し、SSE の keepalive ping が追加されました。Vertex・Bedrock 構成で効きますSELFHOST — 8月7日の v2.1.224 で `claude self-hosted-runner` コマンドが加わり、セルフホスト環境を扱えるようになっていますMCP — MCP SDK の月間ダウンロードが4億回を超えました。今年に入って4倍で、コネクタディレクトリのサーバーは950本を上回りますSUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は8月17日です。残り2日となりましたLATEST — 最新は8月13日の v2.1.231 です。事前登録済み OAuth クライアントを使う MCP サーバーでのサインイン失敗が直っていますRESUME — 8月12日の v2.1.229 で、`claude remote-control --continue` により直近の Remote Control セッションを再開できるようになりましたSTREAM — 長い思考の待ち時間にストリーミングが idle timeout で切れる問題に対し、SSE の keepalive ping が追加されました。Vertex・Bedrock 構成で効きますSELFHOST — 8月7日の v2.1.224 で `claude self-hosted-runner` コマンドが加わり、セルフホスト環境を扱えるようになっていますMCP — MCP SDK の月間ダウンロードが4億回を超えました。今年に入って4倍で、コネクタディレクトリのサーバーは950本を上回ります
記事一覧/Cowork
Cowork/2026-07-01上級

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

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

Cowork33スケジュールタスク19自動化77依存関係2信頼性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;           // 空や失敗の理由を人が読めるように
}

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

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

この記事の続きを読む

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

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

この記事を購入する

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

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

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

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

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

関連記事

Cowork2026-06-30
3日前のローカルミラーで判断していた — 無人タスクが古い作業コピーを信じて二重作業する事故を止める
速度のために使い回す永続クローンは、いつの間にかリモートとずれます。同期を確かめないまま「この記事はもう直したか」を読みに行くと、無人タスクは古い木を信じて二重編集や空振り成功を起こします。HEAD 突き合わせと書き込み可否のプリフライト、自己修復の再クローンをbashで実装します。
Cowork2026-06-29
古い入力で無音劣化させない — 無人パイプラインの入力フレッシュネス契約
スケジュール実行の自動パイプラインが、空や古い参照データを読んで静かに劣化した成果物を出す事故を防ぐための設計。鮮度・非空・由来を契約として検証するゲートをbashで実装し、私自身がCoworkで踏んだ落とし穴も共有します。
Cowork2026-07-02
夜の同じ分に何本着火しているか — Cowork スケジュールタスクの衝突を cron から平らにする設計
Cowork のスケジュールタスクが同じ時刻に集中して共有リソースを奪い合う問題を、cron 式から着火時刻を展開して衝突と並行度を数え、プレミアム枠を動かさずにピークだけを削る貪欲オフセットで平準化する設計を、動くコードと実測 before/after で解説します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →