Claude に大きなタスクを与えると、途中で辞めてしまい、完了したと思い込む。作業は終わっていないのに、始めたことすら覚えていないのだ。
エージェントは長いタスクを、あなたが思うような方法では処理しない。シフト制で働くのだ。
シフト制で働くエンジニアがいるソフトウェアプロジェクトを想像してほしい。新しいエンジニアが来るたびに、前のシフトで何が起こったかは全く覚えていない。これはエージェントの気持ちを例えたものではない。そのまま機械的な仕組みだ。コンテキストウィンドウは有限であり、実際の作業のほとんどはその中に収まらない。そのためエージェントは個別のセッションで作業し、新しいセッションは毎回、前のセッションの記憶なしに始まる。
Anthropic はまさにこの実験を行い、何が壊れるのかを公開した。読む価値があるのはそこだ。なぜなら、ツールが弱いとブロガーが言っているわけではなく、Claude を構築しているチーム自身が、Claude のどこがダメになるのかを記録しているからだ。
1 つのウィンドウではなぜタスクを完了できないのか
最先端のコーディングモデルに高レベルのプロンプト（「claude.ai のクローンを作成せよ」）を与え、それを複数のコンテキストウィンドウにわたってループさせると、動作するアプリを作成できない。たまにではなく、確実に失敗する。しかもこれは、Anthropic 自身のエージェントフレームワーク上で動作する Opus であり、コンテキスト圧縮も有効で、全体を継続させるように構築された設定である。
失敗には 2 つの特定のパターンがあり、どちらもシフト引き継ぎの問題である。
1 つ目：エージェントがすべてを一度にやろうとする。アプリ全体を 1 つのウィンドウで一気に完成させようとし、機能の途中でコンテキストが足りなくなり、セッションは中途半端で文書化もされないまま終了する。次のシフトが出勤し、自分が作っていない混乱した状態を見て、何が行われていたのか推測しなければならない。その結果、次のシフトはセッション全体を、アプリの基本部分を再び動かすことに費やし、前に進むことができない。
2 つ目は、いくつかの機能ができた後の段階で現れる。新しいエージェントが周囲を見渡し、実際に進捗があったと判断し、プロジェクト全体が完了したと決めつける。しかし、実際には完了していない。機能の半分は構築されておらず、どの機能が未完了かも誰も記録していない。シフトは、チェックリストも確認せずに完了とみなしたのだ。
両方の失敗の根源は同じだ。去るシフトが何も残さなかったため、到着したシフトは手探りで進むしかない。修正策は、より賢いモデルではない。シフトがタイムカードを押す前に何を書き残すか、だ。
去るシフトが書き残すもの
Anthropic がたどり着いた答えには 2 つの部分がある。1 つは、作業を始める前にサイトをセットアップするエージェント。もう 1 つは、セッションごとに現れて進捗を生み出すシフトワーカーだ。
セットアップエージェントは最初に 1 度だけ実行される。その役割は、将来のすべてのシフトが「完了」の状態を把握できる環境を整えることだ。その中核となるのは、機能リスト（完成したアプリが行うべきすべての項目を明記した構造化ファイル）を作成することだ。
claude.ai のクローンの場合、それは 200 以上の機能を意味した。「ユーザーが新しいチャットを開き、クエリを入力し、Enter キーを押すと、応答が表示される」といったものだ。すべての項目は最初は「失敗」とマークされていた。各エントリは次のようなものであった：
1{2 "description": "新しいチャットボタンで、新しい会話を作成する",3 "steps": [4 "[新しいチャット]をクリック",5 "新しい会話が作成されたことを確認",6 "ウェルカム状態を確認"7 ],8 "passes": false9}
すべてのエントリに "passes": false がついているのがポイントだ。チェックされていないボックスが 200 個あるようなものだ。
この「失敗」リストこそが、エージェントが早期に勝利を宣言するのを防ぐものだ。シフトは周りを見て「仕事は終わった」と判断できない。なぜなら、そこに 200 個の未チェックボックスがあるファイルが存在するからだ。作業は、最初の 1 行が書かれる前に定義されている。
これがどれほど注意深く行われなければならなかったかを示す小さなディテールが 1 つある。彼らはこのファイルに Markdown ではなく JSON を使用した。その理由は、モデルが Markdown ファイルよりも JSON ファイルをこっそり書き換えたり削除したりする可能性が低いからだ。そして、その周辺の指示は意図的に厳しいものになっている。テストを削除したり編集したりすることは許されない。テストを削除することは、機能をこっそり消すことと同じだからだ。シフトはボックスにチェックを入れることは許されている。ボックスを消すことは許されていないのだ。
机の上のメモ
作業の準備は半分に過ぎない。もう半分は、各シフトが次のシフトが入りやすいように、きれいな状態で場を去ることだ。
それを実現するのが 2 つの要素だ。エージェントは作業内容を Git にコミットし、何が変わったかを説明する適切なメッセージを残す。そして、プレーンな進捗ファイル（何が行われたかの実行ログ）を書き出す。このログは Git 履歴と並んで、真っさらな状態でスタートする新しいエージェントが、逆アセンブルに 1 時間も費やすことなく、数分で状況を理解できるようにする。
Git はここで別の役割も果たす。シフトが悪い変更を加えた場合、次のシフトはダメージを解きほぐそうとする代わりに、最後に動作していたバージョンまでロールバックできる。進捗ファイルは「今どこにいるか」を示す。コミット履歴は「元に戻す」ボタンだ。
そして「きれい」には特定の意味がある。メインブランチにマージしても問題ないコード、すなわち大きなバグがなく、整然としており、文書化されていることを意味する。「技術的には進捗した」ではない。基準は次のとおりだ。次の人が、あなたの残した混乱をまず片付けなくても、新しい機能を始められること。
次のシフトが出勤する方法
これら 2 つを整えれば、すべてのシフトは同じように始まる。新しいことに触れる前に、エージェントは固定された開始ルーチンを実行して状況を把握する。これは、しばらく見ていなかったプロジェクトに参加する優秀なエンジニアが行うことと同じだ。
1pwd を実行して、自分がどのディレクトリにいるかを確認する。それが編集可能な唯一の場所である2進捗ファイルと Git ログを読んで、直近で何が起こったかを確認する3機能リストを読み、まだ完了していない最優先の項目を選択する4アプリを起動し、コア機能がまだ動作するか基本的なチェックを実行する5そして初めて、構築を開始する
この 4 番目のステップは、見た目以上に重要だ。新しい機能を 1 行も書く前に、エージェントはアプリを起動し、基本機能がまだ動作することを確認する。チャットを開き、メッセージを送信し、応答を得る。前のシフトが何かを壊したままにしていた場合、新しいシフトが壊れた土台の上にさらに新しい作業を積み重ねて事態を悪化させる前に、それが即座に検出される。
これがすべてのトリックであり、その単純さゆえにほぼ退屈ですらある。去るシフトは、自分がやったことと残っていることを書き留める。到着したシフトは、何かをする前にそれを読む。引き継ぎこそがすべてなのだ。
あなたの長いタスクにもシフトがある
これは、決して Web アプリの構築だけの話ではない。Anthropic がコードでテストしたのは、コードが検証しやすいからだ。しかし、その根底にある形は、あなたがエージェントに任せるあらゆる長いタスクの形と同じである。
1 つのウィンドウに収まらないものには、すべてシフトが存在する。長いレポートを章ごとに書く。研究プロジェクトを十数ものチャットにわたって実行する。大きな分析を何日もかけて行う。同じタスクで新しいセッションを開始するたびに、新しいワーカーが前回の記憶なしに出勤する。そして、引き継ぎを残していなければ、推測から始まることになる。
だから、引き継ぎを残そう。長いセッションが終わる前に、モデルに何が完了したか、まだ何が未完了か、次のセッションが最初に何を拾うべきかを書き出させる。そのメモを、次回のセッションが開始時に読める場所に置いておく。それが、毎セッション前進するプロジェクトと、ずっと同じことを何度も再構築し続けるプロジェクトとの違いを生む。
今夜も明日も同じモデルだ。変わるのはただ 1 つ、明日のセッションが手探りで始まるか、昨夜のメモを読み込んで始まるかだ。
問題はシフトがどれだけ賢いかでは決してなかった。次に来るシフトのために何を残すかが問題なのだ。
このような分析をもっと読む - https://t.me/+xYv1MgmIuds5YTli
