何日も続く作業を任せるときの設計。引き継ぎ・区切り・外の判定

研究団体の METR は、AIが半分の確率でやり切れる作業の長さ（人がやると何分かかる作業か）を測っています。2025年3月の報告では、この長さが過去6年間、およそ7か月ごとに倍になってきたとしています。この調子が続くかはわかりませんが、「数分の作業」から「数時間〜数日の作業」へ、任せられる大きさが変わってきているのは確かです。

任せる作業が長くなると、新しい問題が出てきます。1つの窓では作業が終わらない、という問題です。

Anthropic の記事「Effective harnesses for long-running agents」は、長い作業の難しさをこう説明しています。作業は区切られた回（セッション）に分かれていて、新しい回は、前の回のことを何も覚えていない状態で始まる。記憶のない技術者が、交代でソフトウェアを作っているようなものだ、と。

同じ記事は、うまくいかなかったときの典型として、次のような形を挙げています。

• 早すぎる完了宣言：全体がまだなのに「完成しました」と言ってしまう
• やりすぎ：一度に多くのことに手をつけ、途中で窓が尽きる
• 散らかったまま終わる：直しかけのまま回が終わり、次の回が何が起きていたのかわからない

同じ記事の解決策は、最初の回だけ特別な役（初期化の役）を置くことでした。その役が次のものを用意します。

• 環境を立ち上げるスクリプト（init.sh）
• 何をしたかを書き足していく進み具合のファイル（claude-progress.txt）
• 作るべき機能を、最初から最後まで書き出した一覧（JSON のファイル）。それぞれに「できたか」の印を付ける
• 最初の時点の git の記録（コミット^※1）

2回目以降の回は、この一覧と進み具合のファイルを最初に読み、1つの機能だけを選んで進めます。機能の一覧があることで、「全部できた」と早まって言いにくくなります。

同じ記事によると、1回に1つの機能だけに取り組ませる（少しずつ進める）ことが、やりすぎを防ぐのに決定的に効いたそうです。そして1つ終えるごとに、説明つきでコミットし、進み具合のファイルに書き足して、次の回がすぐ始められるきれいな状態で終えます。

コミットが区切りとして残っていれば、次の回で壊れていることに気づいたときに、直前の区切りまで戻せます。

AIは、自分の仕事を早めに「終わりました」と言いがちです。終わりの条件は、テストや評価セット（第10回）の形で先に渡し、AIの申告ではなく、外の検査が合格を出したら完了にします。入門編で触れたとおり、Claude Managed Agents にも、終わりの条件を渡して別に判定させる機能があります。

自分の環境では、長い作業の完了の条件を「テストが全部通ること」にして、作業メモの最後に書いておくようにしています。

毎回の始めに、次の3つを決まった手順にしておきます。

1. 進み具合のファイルと、引き継ぎのメモを読む
2. 直前のコミット（区切り）を確かめる
3. テストが通る状態かを見る

前の回が壊したまま終わっていないかを最初に確かめるだけで、事故がかなり減ります。壊れていたら、新しい機能に手をつける前に、まずそれを直します。

長く働くAIの記憶やメモは、放っておくと、第8回の「前提が古くなる」と同じことになります。古くなった記述を消し、重なりをまとめる時間を、仕組みの中に入れておきます。人のチームでいえば、引き継ぎのメモを定期的に読み返して、手順書を直す作業にあたります。