AIの長時間タスクは"落ちても流し直せる"設計にする

「AIに長時間の作業を任せたら、途中で止まっていて、しかも中途半端に進んだ状態が残っていた」——無人でAIエージェントを動かし始めた人の多くが、最初にここでつまずきます。

結論から言うと、長時間タスクを安全に任せる鍵は「途中で落ちても再開できるか」ではなく、「いつ落ちても、最初から丸ごと流し直せるか」にあります。個人や小規模の運用では、凝った再開機能を作り込むより、この「流し直せる設計」の方がはるかに壊れにくいというのが私の結論です。

株式会社Fyveは、自分の業務の一部を常時起動のマシンで無人ジョブとして回しています。この記事では、AIに長時間タスクを任せるときに壊れない設計の考え方を、私が実際に使っている無人ジョブの作り方をもとに具体的に解説します。あわせて、この論点をちょうど正面から扱ったMetaの新しいコーディングエージェントの設計にも触れ、道具側の答えと個人運用の答えの違いを整理します。

なぜ「AIに長時間タスクを任せる」と壊れるのか

まず、何が問題なのかをはっきりさせます。AIエージェントに短い作業を頼むぶんには、失敗しても「もう一度お願い」で済みます。ところが、任せる作業が長くなるほど、失敗のダメージは急に大きくなります。

理由はシンプルで、長時間タスクは「途中の状態」を持つからです。1時間走った作業が55分目で止まると、そこには完成でも未着手でもない、中途半端な状態が残ります。これをどう扱うかを決めていないと、運用は次の2つの形で壊れます。

途中で落ちると、中途半端な状態が残る

1つ目は、止まった時点の残骸です。ファイルを半分書き換えたところ、10件のうち4件だけ処理したところ、下書きは作ったが公開手前で力尽きたところ——こうした「途中」は、次にそのタスクを動かすときの前提を崩します。

人が横で見ていれば「あ、ここで止まってるな」と気づいて手で片づけられます。しかし無人運用の前提は「人が見ていない」ことです。誰も片づけないまま次の実行が始まると、前回の残骸の上に新しい作業が積み重なり、状態がどんどん読めなくなっていきます。

「もう一度やって」で二重に実行される事故

2つ目は、やり直しそのものが起こす副作用です。止まったから単純に頭から再実行すればいい、とは限りません。もしそのタスクが「請求を1件立てる」「通知を1通送る」「台帳に1行追記する」といった、外に影響を残す処理を含んでいたらどうなるか。

途中まで進んで落ちたタスクを頭から流し直すと、すでに送った通知をもう一度送り、すでに追記した行をもう一度足すことになります。作業が消えないようにと再実行したはずが、今度は二重実行という別の壊れ方を招くわけです。

具体的に想像してみてください。10件の請求を立てるジョブが、6件目を立てた直後に落ちたとします。ここで単純に頭から流し直すと、1〜6件目の請求がもう一度立ち、同じ相手に二重で請求が飛びます。逆に「落ちたから」と何もせず放置すれば、7〜10件目は永遠に立ちません。頭から流し直しても、途中から継いでも、どちらも設計なしには事故る——これが長時間タスクの本質的な難しさです。だからこそ、突き詰めると「途中で落ちたときにどうするか」を先に決めておくことがすべてになります。

Claude Codeのような道具で長時間の自動処理を回すときの、より基本的な制限（利用枠の上限など）については、こちらの記事でも触れています。

Claude CodeClaude Codeの5時間制限に到達した話｜長時間稼働の実践対策

道具側の答え＝Metaが示した「イベントログで途中再開」

この「途中で落ちたときにどうするか」を、道具そのものの機能として正面から解こうとした例が、2026年8月5日にMetaが公開したコーディングエージェント「Muse Code」（ベータ版）です。TechCrunchやCNBC、MarkTechPost、Meta AI Researchの公式ブログなど複数の媒体が同日前後に報じており、その設計思想はこの記事のテーマとぴたりと重なります。

replay-exact・restart-safe とは何か

Muse Codeは、モデルの呼び出し・ツールの実行・承認・編集といったすべての操作を、ローカルの「イベントログ」に順番に書き足していく構造を採っていると各媒体は伝えています。作業の実体を1本のログに集約しておくことで、途中でプロセスが落ちても、そのログを読み直せば「どこまで、何をやったか」を正確に復元できる、という考え方です。

これはソフトウェアの世界で「ログ先行（write-ahead log）」と呼ばれてきた古典的な発想を、AIエージェントの操作単位に当てはめたものと言えます。やろうとしたことを先に記録し、それから実行する。だから途中でクラッシュしても、状態を失わずログから正確にたどり直せる——報道では「replay-exact（正確に再生できる）」「restart-safe（再起動しても安全）」と表現されています。実際に、GPU向けの処理を1,000回を超えるツール呼び出しで、最長24時間規模にわたって回し続けたテストも紹介されています。

これは強力だが、個人の無人運用には別の道がある

長時間タスクにおいて、この「落ちても正確に途中から再開できる」性質は本物の強みです。数時間かけて積み上げてきた作業を、クラッシュ1回でゼロに戻さずに済むのは大きい。競合の道具があまり売りにしてこなかった部分でもあり、Muse Codeが狙いどころとしたのは理にかなっています。

ただ、ここで立ち止まって考えたいことがあります。「途中から正確に再開できる」仕組みは、それ自体がかなり複雑な機能です。全操作を漏れなくログに残し、再開時にそのログを正しく解釈し、途中の状態を寸分違わず復元する——これを自分で組もうとすると、相応の作り込みと、その仕組み自体を保守し続ける手間が発生します。

道具がその複雑さを内側で引き受けてくれるなら、利用者は恩恵だけ受け取れます。しかし、自分の業務を自作のスクリプトで無人化している立場だと、話は変わります。私が選んだのは、この「途中再開」を作り込むのとは逆方向の設計でした。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

私の答え＝「途中再開」より「いつ落ちても流し直せる」

私が無人ジョブで一貫して採っているのは、途中から再開する仕組みを持たないという設計です。その代わりに、いつ落ちても次の実行で最初から丸ごとやり直せる状態を保ちます。一見すると原始的ですが、1人で運用を続ける前提では、これが一番堅いと考えています。

冪等とは「何回流しても結果が同じ」

この設計を支える言葉が「冪等（べきとう）」です。聞き慣れない用語ですが、意味は難しくありません。同じ操作を何回繰り返しても、結果が同じになる性質のことを指します。

たとえば「照明のスイッチをオフにする」は冪等です。もうオフの状態でもう一度オフにしても、結果は「オフ」のまま変わりません。逆に「照明のスイッチを切り替える」は冪等ではありません。押すたびにオン・オフが入れ替わるので、何回押したかで結果が変わってしまいます。

無人ジョブを冪等に設計するとは、「そのジョブを頭から何回流しても、最終的な状態が同じになる」ように作るということです。こうしておくと、途中で落ちても慌てる必要がありません。次の実行でもう一度頭から流せば、正しい状態に落ち着くからです。「どこまで進んだか」を覚えておく必要も、そこから継ぐ必要もなくなります。

途中再開を作り込まないという判断

ここが道具側の発想との一番の違いです。Muse Codeが「途中の状態を正確に保存して継ぐ」方向で複雑さを引き受けたのに対し、私は「途中の状態を持たなくて済むように、そもそも作業を組み替える」方向を選びました。

なぜそちらなのか。理由は保守コストです。途中再開の仕組みは、いざ再開が必要になる場面はまれなのに、正しく動かし続けるための面倒は常にかかります。ログの形式が変わったら、再開ロジックも直さなければならない。復元の途中でさらに落ちたらどうするか、まで考え始めるときりがありません。

1人で複数の無人ジョブを抱えていると、こうした「めったに使わないのに手のかかる仕組み」は、静かに首を絞めてきます。だから私は、再開機能を作らずに済む形へタスクそのものを寄せる方に振り切りました。次の章で、その具体的な原則を4つに分けて説明します。

冪等な無人ジョブを設計する4つの原則

「いつ落ちても流し直せる」を実現するために、私が実際に守っている原則は次の4つです。どれも派手な技術ではなく、作業の切り方と後始末の決め方の話です。

① 開始時に、既知の状態へリセットする

1つ目は、ジョブの一番最初に「まっさらな既知の状態」へ揃えることです。前回の実行が中途半端に残した痕跡を持ち越さないために、作業を始める前に、決めた基準点まで戻します。

私の場合は、無人ジョブの冒頭で、ソースの状態を「正となる場所の内容にそっくり合わせ直す」処理を必ず通します。前回の実行が途中で何かを書き換えていたとしても、その差分はここで消え、毎回同じ地点から作業が始まります。これだけで「前回の残骸の上に積み重なる」という壊れ方が構造的に起きなくなります。

ポイントは、リセットを後始末ではなく前始末にすることです。落ちた直後に片づけようとすると、片づけ処理自体が動かなかったときに詰みます。次の開始時に必ずリセットする形なら、前回どう落ちたかに関係なく、いつも同じ入口から始められます。無人運用で複数マシンやクラウドをまたぐときの状態の食い違いについては、こちらでも掘り下げています。

Claude CodeClaude Code無人運用｜暴走を防ぐ上限設定まとめ

② 1回の実行を、小さく切る

2つ目は、1回のジョブで扱う量をあえて小さく保つことです。私の記事生成の無人ジョブは、1回の起動で仕上げる本数を1本に絞っています。10本まとめて作ろうとはしません。

小さく切ることの効き目は、「途中」という状態そのものを消せる点にあります。1回で1本しか作らないなら、その1本が完成しているか、していないかの二択しかありません。「7本目まで終わって8本目の途中」という厄介な中間状態が、そもそも発生しないのです。

もし途中で落ちても、失われるのはせいぜい作りかけの1本ぶんだけです。次の起動で頭から1本作れば、被害はその1回に閉じます。大きな1本の長時間タスクを止めずに走らせ切る道具側の発想とは逆に、小さな単位を何度も回すことで、1回あたりの失敗の重さを軽くしているわけです。

小さく切ることには、もう1つ地味な効き目があります。原因の切り分けが楽になることです。10本を1回で作る設計だと、途中でおかしくなったときに「どの本のどの段階で崩れたのか」を長いログから探すことになります。1回1本なら、失敗した実行はそのまま失敗した1本と一対一で対応するので、何が起きたのかを短時間で読み解けます。無人運用では、この「あとから原因を追える」性質が、そのまま復旧の速さになります。

③ 失敗したら、中途半端に進めず退避する（fail-closed）

3つ目は、判断に迷ったときや検査に通らなかったときの「倒れ方」を先に決めておくことです。私は無人ジョブに、疑わしいときは前に進めず安全側に倒す「fail-closed（フェイルクローズド）」という考え方を組み込んでいます。

具体的には、生成物が一定の基準を満たしているかを別の工程で検査し、通らなければ本番に出さず「下書き」として脇に退避させます。少しでも怪しければ公開しない、という一択です。無人運用で怖いのは、止まることより、間違ったものを人の目を通さずに世に出してしまうことです。fail-closedは、その最悪の事故を構造的に防ぎます。

この「退避する」も冪等設計と相性が良い点に注目してください。退避は状態を壊さずに一時停止させる行為なので、あとから人が中身を確認して手直しし、公開するかどうかを落ち着いて決められます。無理に自動で完遂させようとしないことが、結果として運用全体を安定させます。

④ 「やったこと」を追記ログに残す

4つ目は、実行のたびに「何をやったか」を追記式のログに書き残すことです。ここでMuse Codeのイベントログと発想が似てくるのですが、目的が違います。道具側のログは復旧のため——落ちたら継ぐために使います。私のログは監査のため——後から人が経緯を追えるようにするために使います。

冪等に流し直せる設計なら、そもそも復旧のためのログは要りません。落ちたら次回まっさら流し直すだけだからです。それでもログを残すのは、「いつ・何を・どう判断して出した／退避した」を、後から自分が読み返せるようにするためです。無人で回している以上、人の代わりに記録が経緯を語ってくれないと、あとで検証できません。

無人運用でAIの動きをどう見えるようにしておくか、ログの設計そのものについてはこちらで詳しく書いています。

Claude CodeClaude Codeの無人運用ログ設計｜サブエージェント可視化

「途中再開」と「流し直し」の使い分け

ここまで読むと「では途中再開の仕組みは要らないのか」と思われるかもしれませんが、そうではありません。どちらが正しいかではなく、タスクの性質でどちらに寄せるかを選ぶのが本筋です。

判断の軸は、突き詰めると1つです。「途中の成果を捨てられるか」——これに尽きます。

数時間かけてじわじわ積み上げる、捨てると本当に痛い作業なら、途中再開の仕組みに投資する価値があります。Muse Codeが狙う「大規模なコードベースを長時間かけて改善し続ける」ような作業は、まさにこちら側です。途中の積み上げが資産そのものなので、クラッシュで失うわけにはいきません。

一方、1回を小さく切れて、落ちても毎回まっさらから作り直せる作業なら、流し直しの方が圧倒的に単純で堅くなります。日々の定型的な生成・集計・投稿の下ごしらえといった、私が無人化しているタスクの多くはこちらです。1本ぶん作り直すコストが軽いので、複雑な再開機能を持つ意味がありません。

やってはいけないのは、この判断を飛ばして「とりあえず途中再開を作り込む」ことです。捨てても平気なタスクにまで再開機能を載せると、めったに効かない仕組みの保守だけが残ります。逆に、捨てると痛いタスクを無理に流し直しにすると、貴重な積み上げを毎回捨てることになります。先に性質を見極めてから、設計を選ぶ順番を崩さないことが大事です。

実際にどう組んだか（機密を伏せた実例で）

抽象論だけだと腹落ちしないので、私の無人ジョブがこの4原則をどう体現しているかを、具体名を伏せた形で説明します。

開始時リセットで「前回の失敗」を持ち越さない

私の無人ジョブは、決まった時刻に自動で立ち上がります。その一番最初に、作業対象を「正となる状態にそっくり合わせ直す」処理を通します。前回の実行が途中で何かを書きかけて落ちていても、その書きかけはここで消えます。

この設計のおかげで、私は「前回ちゃんと終わったか」を毎回気にせずに済んでいます。終わっていようが途中で落ちていようが、次の起動は必ず同じ地点から始まる。人が朝いちばんに残骸を片づける、という作業がまるごと消えました。複数のマシンやクラウドをまたいで同じ作業を回すと、どのマシンの状態が正しいのかがずれて事故になりがちですが、開始時リセットは「正しいのはここ」を毎回宣言し直す行為でもあるので、その食い違いごと消してくれます。

小さく切ると「どこまで進んだか」を管理しなくていい

記事にせよ集計にせよ、私は1回の起動で扱う単位を意図的に小さくしています。1回で1つ。これによって、進捗管理という仕事そのものが消えます。

「今どこまで進んでいて、次はどこから継げばいいか」を追いかけるのは、地味に神経を使う作業です。小さく切って毎回頭から流す形にすると、その追跡が一切不要になります。状態は「やったか・やっていないか」の二値になり、途中という曖昧な帯がなくなる。これは、進捗を持たせないことで進捗管理を消す、という発想です。

迷ったら出さない、を機械に守らせる

生成物は、本番に出す前に必ず別の工程で検査を通します。基準に届かないもの、少しでも判断に迷うものは、公開せず下書きへ退避します。ここを人の気合いや注意力に頼らないことが肝心です。「気をつける」は無人運用では再現しません。仕組みとして「通らなければ出せない」を機械に守らせて初めて、安心して任せられます。

検査を別の工程に分けている点にも意味があります。作ったものを、作った本人（同じ処理）が「これで大丈夫」と判定すると、どうしても甘くなります。生成と検査を切り離し、検査は独立した目として動かすことで、はじめて「迷ったら出さない」が本当に効きます。無人でAIに実行権限を渡すほど、この最後の砦が事故の大きさを決めます。

よくある落とし穴

最後に、冪等な流し直し設計に寄せるときにつまずきやすい点を2つ挙げておきます。

冪等にしづらい処理（追記・課金・通知）の扱い

流し直し設計の最大の敵は、「もう一度やると副作用が二重になる処理」です。台帳への追記、料金の発生、外部への通知——これらは素朴に頭から流し直すと、二重追記・二重課金・二重通知を起こします。

対処は2つあります。1つは、そうした処理をジョブの最後の一撃に寄せること。作業の本体を全部終えてから、最後に1回だけ外に影響を出す形にすれば、途中で落ちてもまだ外には何も出ていません。もう1つは、「すでにやったか」を出す直前に確認すること。追記や通知の前に、同じものが既に存在しないかを一度照合してから実行すれば、二重を防げます。私が新しい生成物を公開する前に、同じ主題のものが既にないかを必ず突き合わせているのも、この考え方です。

無人運用でとくに事故りやすいのが「課金の二重発生」です。AIを無人で回すときのコストの規律については、こちらで具体的に書いています。

Claude CodeAIを無人で回すコスト規律｜claude -pの--model明示

ログを「復旧用」でなく「監査用」に使う

もう1つの落とし穴は、ログの役割を取り違えることです。冪等に流し直せる設計にしたのに、ログを「途中から復旧するため」の道具として作り込み始めると、結局は途中再開の複雑さを裏口から抱え込むことになります。

流し直し設計におけるログは、あくまで後から経緯を読むための記録と割り切るのが正解です。復旧はログではなく「まっさらから流し直す」で担う。ログは「いつ、何を、どう判断したか」を人が追えるようにする監査の役目に徹する。この線引きを守ると、ログが肥大化して手に負えなくなる事態を避けられます。役割を1つに絞ることが、仕組みを単純に保つコツです。

まとめ｜長さに強い設計は「継ぐ」より「流し直す」

AIに長時間タスクを任せるとき、最初に決めるべきは「途中で落ちたらどうするか」です。答えは大きく2つに分かれます。

1つは、道具側が示す「途中の状態を正確に保存して継ぐ」道。Muse Code（2026年8月5日公開）のイベントログによる途中再開は、その洗練された実装例です。積み上げを捨てられない大規模な作業では、この方向が効きます。

もう1つは、私が無人運用で採っている「いつ落ちても最初から流し直せる」道。開始時にリセットし、1回を小さく切り、迷ったら退避し、ログは監査に徹する——この4原則で、途中再開を作り込まずに壊れにくさを得ています。1人で保守を続ける前提なら、単純なぶんだけこちらが堅い。

大事なのは、どちらが優れているかではなく、自分のタスクの性質に合わせて先に選ぶことです。道具の性能が横並びに近づいていくほど、差がつくのは「作業をどう設計するか」の側になります。株式会社Fyveは、この「壊れない任せ方の設計」こそが、AIを日々の実務に根づかせる土台だと考えています。