長時間稼働エージェントのための効果的なハーネス設計
原文: Effective harnesses for long-running agents著者: Justin Young(Anthropic) 公開日: 2025年11月26日
Claude Codeユーザーへの適用可能性評価
| 手法 | Claude Codeでの適用 | 評価 | 備考 |
|---|---|---|---|
init.shスクリプト作成 | 可能 | ✅ 適用可 | プロジェクト初期化時にBashツールで作成可能 |
claude-progress.txt進捗ファイル | 可能 | ✅ 適用可 | セッション間で手動参照が必要 |
| 機能リスト(JSON形式) | 可能 | ✅ 適用可 | Readツールで読み込み、段階的に実装可能 |
| Gitによる状態管理 | 可能 | ✅ 適用可 | Bashツールでgitコマンド実行可能 |
| Puppeteer MCPによるブラウザテスト | 条件付き | ⚠️ 部分的 | Chrome DevTools MCPで代替可能(一部制限あり) |
| 複数コンテキストウィンドウの継続 | 制限あり | ⚠️ 部分的 | /resumeで直近セッション継続可能だが、長期間は手動引き継ぎ必要 |
| 初期化エージェントとコーディングエージェントの分離 | 可能 | ✅ 適用可 | 別セッションとして実行可能 |
結論: 本記事の手法の多くはClaude Code CLIで直接適用可能です。特に進捗ファイルとGitによる状態管理は、長時間のタスクを複数セッションで継続する際に有効です。
はじめに
AIエージェントの能力が向上するにつれ、開発者はエージェントに数時間、あるいは数日にわたる複雑なタスクを依頼することが増えています。
長時間稼働エージェントの核心的な課題は、離散的なセッションで作業しなければならず、新しいセッションは以前の記憶なしに始まるということです。
Anthropicの研究チームは、長時間稼働エージェントの実験を通じて、2つの典型的な失敗パターンを発見しました:
- 一度にすべてを完了しようとする - 不完全な実装につながる
- 早期に完了を宣言する - プロジェクトが未完成のまま終了する
2部構成の解決策
1. 初期化エージェント(最初のセッションのみ)
最初のセッションでは、専用のプロンプトを使用して以下の3つの重要なコンポーネントをセットアップします:
init.shスクリプト: 開発サーバーを起動するためのスクリプトclaude-progress.txtファイル: これまでの作業履歴を記録- 初期gitコミット: 追加されたファイルを文書化
2. コーディングエージェント(以降のセッション)
後続のセッションでは、構造化されたアプローチに従います:
- 進捗ファイルとgit履歴を読み込む
- 一度に1つの機能に取り組む
- 説明的なメッセージでコミットを作成
- 進捗ドキュメントを更新
注記: これらは異なる初期ユーザープロンプトを持つため、このコンテキストでは別々のエージェントと呼んでいます。システムプロンプト、ツールセット、および全体的なエージェントハーネスは同一です。
環境管理フレームワーク
機能リスト(JSON形式)
初期化エージェントは、ユーザーのプロンプトを包括的な要件リストに展開します。例えば、claude.aiクローンの例では200以上の機能が含まれていました。
JSON形式を使用することで、モデルによる不適切な変更を防ぎます:
{
"category": "functional",
"description": "新規チャットボタンで新しい会話を作成",
"steps": [
"メインインターフェースに移動",
"'新規チャット'ボタンをクリック",
"新しい会話が作成されることを確認",
"チャットエリアがウェルカム状態を表示することを確認",
"サイドバーに会話が表示されることを確認"
],
"passes": false
}
段階的な進捗
初期環境のスキャフォールディングを与えられた後、コーディングエージェントは一度に1つの機能のみに取り組むよう求められます。
モデルは説明的なメッセージと進捗サマリーでコミットを作成し、問題のある変更をgitで元に戻すことができます。
テスト
ユニットテストだけでなく、エージェントにはブラウザ自動化ツール(Puppeteer MCP)を使用したエンドツーエンドテストを実行させます。これにより、実際のユーザーワークフローに一致する検証が可能になります。
「Claudeにこの種のテストツールを提供することで、パフォーマンスが劇的に向上しました。エージェントがバグを特定して修正できるようになったためです。」
制限事項: Claudeは Puppeteer MCP を通じてブラウザネイティブのアラートモーダルを認識できません。これらのモーダルに依存する機能は、よりバグが多い傾向にありました。
セッション構造
各セッションは一貫したステップで始まります:
- 作業ディレクトリを確認(
pwd) - 進捗ファイルとgitログを確認
- 最優先の未完了機能を選択
- 新しい開発の前に初期化/テストを実行
典型的なセッションパターン
[アシスタント] まず現在の状況を把握し、プロジェクトの状態を理解します。
[ツール使用] <bash - pwd>
[ツール使用] <read - claude-progress.txt>
[ツール使用] <read - feature_list.json>
[アシスタント] gitログで最近の作業を確認します。
[ツール使用] <bash - git log --oneline -20>
[アシスタント] サーバーを再起動するためのinit.shスクリプトがあるか確認します。
<開発サーバーを起動>
[アシスタント] 基本的な機能がまだ動作しているか確認します。
<基本機能をテスト>
[アシスタント] 検証テストに基づき、基本的な機能が正常に動作していることを確認しました...
失敗パターンと解決策
| 問題 | 初期化エージェントの対応 | コーディングエージェントの対応 |
|---|---|---|
| 早期の完了宣言 | 構造化されたJSONで機能リストを設定 | セッション開始時に機能リストを読み込み、1つの機能に集中 |
| バグのある/文書化されていない進捗を残す | 初期gitリポジトリと進捗メモを作成 | 進捗レビューで開始し、gitコミットと更新で終了 |
| 機能を早期に完了としてマーク | 機能リストファイルを設定 | すべての機能を自己検証し、テスト後のみ合格としてマーク |
| アプリの実行に苦労 | 開発サーバー用のinit.shスクリプトを作成 | セッション開始時にinit.shを読み込む |
人間のエンジニアリング慣行からの着想
この研究は、ドキュメントと明確な状態管理を通じた引き継ぎという、人間のエンジニアリングチームがシフト間の継続性を維持する方法からインスピレーションを得ています。
プロフェッショナルなチームが交代制で作業する際に使用するのと同じ原則を、AIエージェントにも適用しています:
- 明確な作業履歴の記録
- 構造化された状態管理
- 標準化された引き継ぎ手順
今後の方向性
いくつかの未解決の疑問が残っています:
- 専門化されたエージェント vs 汎用エージェント: テスト、QA、クリーンアップなどの専門エージェントが、単一の汎用エージェントよりも優れた性能を発揮するかどうか
- 一般化の可能性: 現在の最適化はWebアプリ開発を対象としていますが、これらのパターンが科学研究や金融モデリングなどの他の分野に一般化できるかどうか
謝辞
貢献者: David Hershey、Prithvi Rajasakeran、Jeremy Hadfield、Naia Bouscal、Michael Tingley、Jesse Mu、Jake Eaton、Marius Buleandara、Maggie Vo、Pedram Navid、Nadine Yasser、Alex Notov
まとめ
長時間稼働エージェントを効果的に機能させるための鍵は:
- 環境の構造化: 初期化スクリプト、進捗ファイル、機能リストで環境を整える
- 段階的な進捗: 一度に1つの機能に集中し、各ステップをコミット
- 自己検証: ブラウザ自動化ツールを使ってエンドツーエンドでテスト
- 状態管理: gitと進捗ファイルで作業状態を永続化
これらのパターンを適用することで、AIエージェントは複数のコンテキストウィンドウをまたいで一貫した進捗を維持できるようになります。