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を待つ」のではなく、「より良い実行基盤を設計する」ことの重要性を改めて認識させられる内容でした。