Anthropicが先週公開した「Effective Harnesses for Long-Running Agents」という記事が、AIエンジニア界隈で静かな、しかし確かな共感を呼んでいる。
LLMのコンテキストウィンドウが200k、1M、あるいはそれ以上に広がった昨今においても、AIエージェントに長時間にわたる複雑なタスク（例えば数日かけてWebアプリ全体を構築するなど）を任せることは、依然として至難の業だ。どれだけモデルが賢くなっても、セッションが切れるたびに彼らは記憶を失う。それはまるで、前任者からの引き継ぎ資料が一切ない状態で、交代制のシフトに入るエンジニアチームのようなものだ。
Anthropicが自社のClaude Agent SDKのために開発したソリューションは、何か画期的なニューラルネットワークのブレイクスルーによるものではない。むしろ、人間のソフトウェア開発現場で培われてきた「運用ルール」や「開発プロセス」を、そのままAIに適用するという、極めて泥臭く、実務的なアプローチである。
本稿では、AIエージェントが陥る「ワンショットの罠」と、それを回避するためのAnthropicのエンジニアリング・プラクティスについて分析する。
「一発で終わらせようとする」エージェントの病理
Claude Sonnet 4.5 のようなSOTAモデルであっても、複雑なプロジェクトを任されると二つの典型的な失敗パターンに陥る。
一つ目は「張り切りすぎ（Trying to do too much）」だ。エージェントは「claude.aiのクローンを作れ」という指示を受けると、優秀なインターンよろしく、たった一度のセッション（コンテキストウィンドウ）ですべてを実装しようと試みる。しかし、途中でメモリが尽きたり、出力トークン制限に引っかかったりして、実装は中途半端な状態で終わる。次のセッションで呼び出されたエージェントは、散らかったコードの山を見て途方に暮れることになる。
二つ目は「早すぎる勝利宣言（Prematurely declaring victory）」だ。いくつか機能を作った段階で、全体像を見失い、「完成しました！」と高らかに宣言してしまう。テストも通っていないのに、だ。
これらの問題の根源は、エージェントが「状態（State）」を適切に管理できていない点にある。人間であれば、Jiraのチケットを見たり、Gitのログを見たりして「今どこまで進んでいるか」を把握できるが、記憶喪失のエージェントにはそれがない。
「Initializer」と「Coding Agent」の分業体制
Anthropicが提示した解決策は、エージェントの役割を明確に二つに分割することだった。
- Initializer Agent（セットアップ担当）：最初のセッションで一度だけ動く。
- Coding Agent（実装担当）：2回目以降のセッションで繰り返し動く。
ここで興味深いのは、Initializer Agentの仕事だ。彼はコードを書き始めない。代わりに「環境」と「ルール」を作る。具体的には、開発サーバーを立ち上げるための init.sh、進捗を記録するための claude-progress.txt、そして何より重要なのが feature_list.json という機能一覧ファイルを作成する。
この feature_list.json には、プロジェクトに必要な全機能がリストアップされ、初期状態ではすべて「failing（未達成）」としてマークされる。これはまさに、アジャイル開発におけるバックログそのものである。
「クリーンな状態」を維持するためのGit駆動開発
Coding Agentは、このバックログ（feature_list.json）から優先度の高いタスクを「一つだけ」選び、その実装に集中する。
ここでのポイントは「Incremental Progress（漸進的な進捗）」と「Clean State（クリーンな状態）」の徹底だ。エージェントは一つの機能を実装し終えるたびに、Gitにコミットし、プログレスファイルを更新することが求められる。
もし実装中にバグを埋め込んでしまっても、Gitさえあれば git reset で前の状態に戻れる。これは人間にとっては当たり前のプラクティスだが、AIエージェントにとっても「失敗しても戻れるセーブポイント」があることは、タスク完遂率を劇的に向上させる。エージェント自身に git log を読ませることで、前任のエージェントが何をしていたかを「文脈」としてではなく「記録」として理解させるアプローチは、コンテキストウィンドウの節約という意味でも理にかなっている。
ブラウザ操作による「人間目線」のテスト
もう一つの重要な構成要素が、Puppeteerなどのブラウザ自動化ツールを用いたEnd-to-End（E2E）テストだ。
コード上のユニットテストが通っていても、画面上でボタンが押せなければ意味がない。Anthropicのアプローチでは、エージェントにブラウザを操作させ、ユーザーと同じようにクリックや入力をシミュレーションさせる。これにより、「コードは正しいが動かない」という、開発現場でよくある悲劇を防ぐことができる。
各セッションの開始時に、エージェントは以下のルーティンを実行するようプログラムされる： 1. pwd で現在地を確認 2. Gitログとプログレスファイルを読み込む 3. init.sh でサーバーを起動 4. 基本的なE2Eテストを実行して、環境が壊れていないか確認
まるで、朝出社してメールチェックとコーヒーブレイクを済ませてからコードを書き始めるエンジニアのルーティンそのものである。
マルチエージェントへの布石となるか
今回のAnthropicの発表は、単一の強力なモデルがあればすべて解決するわけではない、という現実を突きつけている。どれだけIQ（のようなもの）が高いモデルでも、適切な「Harness（馬具、転じて制御装置や枠組み）」がなければ、その力を発揮し続けることはできない。
記事の最後で触れられている「Future Directions」も示唆に富んでいる。現在は汎用的な「Coding Agent」がすべての実装を行っているが、将来的には「テスト専門エージェント」や「QA（品質保証）エージェント」といった、専門職（Specialized Roles）による分業体制の方が効率的かもしれないという点だ。
これは、AI開発のトレンドが「モデルの性能向上」から「エージェント・アーキテクチャの設計」へとシフトしていることを如実に表している。OpenAIのo1やo3が高い推論能力を持つ一方で、それをどう社会実装可能なワークフローに落とし込むか。その答えの一つが、GitやJSON、シェルスクリプトといった、枯れた技術を組み合わせた泥臭いエンジニアリングにあるというのは、なんとも皮肉であり、同時に希望を感じさせる結論である。
Web開発だけでなく、科学研究や金融モデリングといった長期的なタスクにおいても、この「記録を残し、少しずつ進み、常に立ち戻れる場所を作る」というアプローチは、AIエージェント活用の定石となっていくだろう。