AnthropicのAI Engineering Conferenceで行われたセッション
https://x.com/warpdotdev/status/2074510082658771430
Building Long-Running Agents
を視聴し、その内容を日本語で整理しました。
現在、多くのAIエージェントは
- ブラウザを開く
- コードを書く
- PRを作る
程度のデモはできます。
しかし、
「数時間〜数日動き続けるエージェント」
を作るとなると、全く別の設計が必要になります。
本記事では、その設計思想を整理します。
エージェントが長時間動けない3つの理由
Anthropicでは問題を3つに整理しています。
① Context（コンテキスト）
モデルにはコンテキスト長の限界があります。
そのため、
- セッション終了
- コンテキストオーバー
になると
ほぼ記憶喪失になります。
さらに
- Context Rot
- Context Anxiety
という現象も発生します。
Context Rot
会話が長くなるほど
重要情報が埋もれ、
判断精度が落ちます。
Context Anxiety
残りトークンが少なくなると
モデルが
「急いで終わらせよう」
という振る舞いになります。
② Planning（計画）
LLMは計画が苦手です。
例えば
- 一気に全部作ろうとする
- 半分作って止まる
- コンテキスト切れになる
などが起こります。
③ Judging（自己評価）
これが一番重要でした。
LLMは
自分の成果物を評価するのが非常に苦手
です。
例えば
UIだけ作って
バックエンドが存在しないのに
完成しました
と言います。
Anthropicの解決策
ポイントは
モデルを改善するだけではない
ことです。
改善対象は
① モデル
モデルそのものを賢くする。
例えば
- Sonnet
- Opus
の性能向上です。
② Harness（ハーネス）
Anthropicは
こちらの方が重要だと説明しています。
つまり
AIを囲む
実行環境
を工夫します。
例えば
- Agent SDK
- MCP
- Sub Agent
- Playwright
などです。
最大のポイント
Generator と Evaluator を分離する
これは非常に参考になりました。
普通は
LLM
↓
コード生成
↓
終了
です。
しかしAnthropicは
Planner
↓
Generator
↓
Evaluator
↓
Generator
↓
Evaluator
というループを回します。
Evaluatorは実際にアプリを操作する
重要なのは
Evaluatorは
コードを見るだけではありません。
Playwrightなどを使い
実際に
- ボタンを押す
- 入力する
- ページ遷移する
というテストまで行います。
つまり
人間QAに近い役割です。
Plannerを追加する
さらに
Planner
という役割を追加します。
入力
Todoアプリを作って
↓
Planner
仕様を書く
Sprintに分解する
Doneを定義する
↓
Generator
↓
Evaluator
これにより
長時間動くエージェントになります。
評価基準（Rubric）を作る
Anthropicでは
評価を数値化しています。
例えば
- Design
- Originality
- Craft
- Functionality
という4軸です。
これが非常に面白い点でした。
「いい感じ」
ではなく
スコア化します。
実際に見つかったバグ
Evaluatorは
次のようなバグを見つけています。
- FastAPIルート順
- 本番だけ壊れるバグ
- Deleteキーのバグ
- 論理エラー
これらは
コードレビューだけでは見つかりません。
実際にアプリを動かしたから見つかったものです。
Anthropicが最後に勧めていたこと
長時間動くエージェントを作るなら
コンテキストに頼らない
状態は
ファイルに保存します。
つまり
Memoryを
コンテキストではなく
ファイルシステムへ逃がします。
スプリントを小さくする
巨大タスクは禁止。
小さく分ける。
評価ループを必ず入れる
Generatorだけではなく
Evaluatorを用意する。
長時間動かすならコンテキストをリセットする
新しいセッションへ渡す内容だけ
要約して引き継ぎます。
私が特に印象に残ったポイント
個人的に一番重要だと思ったのは、
「LLMは優秀な生成器だが、優秀なレビュアーではない」
という考え方です。
そのため、生成役（Generator）と評価役（Evaluator）を分離し、両者が合意するまで改善を繰り返すという設計は、人間の開発チームに近いアプローチだと感じました。
また、状態管理をコンテキストウィンドウに依存せず、ファイルシステムやメモリに逃がす設計も、長時間稼働するエージェントでは重要なポイントです。
まとめ
Anthropicが提案する長時間稼働エージェントは、単に高性能なLLMを使うだけでは実現できません。
重要なのは、エージェントを支える「ハーネス（実行基盤）」の設計です。
特に参考になったポイントは以下の5点です。
- コンテキストではなく外部メモリで状態管理する
- Planner・Generator・Evaluatorを役割分担する
- Evaluatorが実際にアプリを操作して検証する
- 評価基準（Rubric）を数値化する
- 小さなスプリントを繰り返して品質を高める
これらはAIコーディングだけでなく、営業支援、業務自動化、情報整理など、長時間動作するあらゆるAIエージェントの設計にも応用できる考え方だと感じました。
実装者向けに考えると何が新しいのか？
ここまで読んで、「結局、何が新しいのか？」と思われた方もいるかもしれません。
私が最も新しいと感じたのは、LLMそのものよりも、その周囲の「ハーネス（実行基盤）」がAIエージェントの性能を大きく左右するという考え方です。
これまでのAI開発では、
ユーザー
↓
LLM
↓
回答
というシンプルな構成が一般的でした。
一方、Anthropicが示しているのは、より人間の開発チームに近い構成です。
ユーザー
↓
Planner（計画）
↓
Generator（実装）
↓
Evaluator（評価）
↓
Memory（永続記憶）
↓
必要なら再計画
つまり、「賢いモデルを1回呼び出す」のではなく、複数の役割を持つエージェントを協調させることが重要になります。
実装するならどう作るのか
私なら、以下のような構成で実装します。
-
Planner
- 要件整理
- タスク分割
- Done（完了条件）の定義
-
Generator
- コード生成
- 修正
- リファクタリング
-
Evaluator
- Playwrightなどで実際に操作
- エラーログ確認
- スクリーンショット比較
- Rubric（評価基準）による採点
-
Memory
- Markdown
- SQLite
- ベクトルDB
- Git
などへ状態を保存し、コンテキストウィンドウに依存しない設計にします。
さらに、
Plan
↓
Build
↓
Evaluate
↓
Fix
↓
Evaluate
↓
Commit
というループを小さなスプリント単位で回すことで、数時間〜数日動作するエージェントへ発展させられます。
今後のAIエージェント開発は「ハーネス設計」が競争力になる
現在は「どのLLMを使うか」が話題になりがちですが、今後はそれ以上に、
- タスクをどう分割するか
- メモリをどう管理するか
- 評価をどう自動化するか
- エージェント同士をどう協調させるか
といったハーネス設計が、AIエージェントの品質を決める重要な要素になっていくでしょう。
私自身も、現在取り組んでいるマルチエージェントシステムやAI業務自動化の設計に、この考え方を取り入れて検証していきたいと思います。
今回のセッションは、「より高性能なLLMを待つ」のではなく、「より良い実行基盤を設計する」ことの重要性を改めて認識させられる内容でした。