数時間動き続けるエージェントを作る — Anthropic の Ash Prabaker × Andrew Wilson が公開する long-running agent の設計原則 (AI Engineer Europe 2026 ワークショップ)

AI Engineer Europe 2026 (London) Day 1 ワークショップ — Ash Prabaker × Andrew Wilson / Anthropic 2026/05/18

アッシュ・プラバカー / Ash Prabaker · 17:50 「フロンティアは縮むのではなく、 移動する。 モデルが強くなれば、 harness 自体は消えるのではなく、 別の難所へと進化していく」

AI Engineer Europe 2026 (London) Day 1 ワークショップ (2026/04/08 開催、 2026/05/18 公開、 約 1 時間 15 分 40 秒)。 講師は アッシュ・プラバカー (Ash Prabaker) と アンドリュー・ウィルソン (Andrew Wilson、 ロンドン拠点 Solution Architect)、 両者とも Anthropic の Applied AI チーム所属。 2026 年 11 月の Anthropic 公式ブログ 「Building long-running agents」 を起点に、 5-6 時間以上連続稼働するエージェントの harness 設計を、 Claude Code の 1 年の進化史と最新の GAN-style harness Generative Adversarial Networks (GANs) からインスパイアされたエージェント設計。 Anthropic の Applied AI チームが 2026 年に提唱した、 generator (builder) と evaluator (critic) の役割を別々の context window で運用する harness pattern。 評価者は Playwright 等で live page を実際にクリックして検証し、 critique を生成者に返す。 重要な insight は 「critic を harsh に tune するのは tractable だが、 builder を self-critical に tune するのは無理」 という asymmetry を悪用する設計 実験 (generator + evaluator + planner の 3 役分離) を交えて教える、 frontier lab 内部の設計知見を最も体系的に開示するワークショップ。

Anthropic の Applied AI チーム所属のエンジニア 2 名による このワークショップは、 「Claude Code が 1 年でなぜ 20 分から数日稼働へ変わったか」 という具体的進化史を体系化し、 さらに 現在 frontier lab 内部で実験中の harness pattern まで開示する、 業界唯一の包括的セッション。 前半 (Andrew) は過去 12 ヶ月の Claude Code / Agent SDK の release タイムラインを harness 視点で再構築、 後半 (Ash) は generator / evaluator / planner の役割分離による next-generation harness の実験を解説する 2 部構成。

MEMEX 編集視点で重要なのは、 これが Tejas Kumar (IBM) の Harnesses in AI: A Deep Dive と完全に補完関係にあること。 Tejas のセッションが 「harness とは何か」 を一から教える primer なら、 こちらは harness を 「どう発展させ続けるか」 の frontier 知識。 同じ AI Engineer Europe 2026 で 2 つの異なる視点から harness が扱われた事実が、 業界が 2026 年に harness を中心軸として認識した瞬間を記録している。

Long-running agent の 3 つの構造的困難

Andrew が前半冒頭で整理する、 エージェントが長時間動作で失敗する 3 つの理由:

  1. Context の有限性 ── context window はそもそも有限、 session 開始時に amnesia が発生 (記憶ゼロからスタート)、 session 中盤以降に context rot エージェントが 1 つの context window 内で長時間動作するときに発生する一貫性低下。 序盤に投入された情報と中盤・後半の処理が乖離していき、 「同じ context にいる agent」 とは思えない行動を取り始める。 Anthropic の Applied AI チームが 2026 年 11 月のブログで使用した用語で、 context window の物理的拡大とは別に発生する 「集中力の低下」 に相当する (一貫性低下) が起き、 context 終端では context anxiety (急いで終わらせようとする現象) が観測される
  2. Planning の弱さ ── モデルは標準では計画立案が苦手。 one-shot で全てを片付けようとしたり、 機能を半分だけ作って止まったり、 context を使い切って half-finished app を残したりする
  3. 自己評価能力の欠如 ── これが最も intuitive でない問題。 モデルは sycophantic で 「ユーザーが聞きたい答えを言う」 性質があり、 これがコーディング判定にも適用される。 「半分実装された機能を見て『よし、 動いている』 と判断する」 「button を作ったが backend が存在しない、 でも feature が完成したように見える」 といった失敗が頻発する

Claude Code 1 年史を harness 視点で再構築

Andrew が示す、 model と harness の co-evolution タイムライン:

  • 2024 年中頃 (pre-Claude Code) ── Sonnet 3.5、 artifacts、 computer use の release。 「verify itself by looking at what it built」 の aha moment。 MCP spec ship
  • 2025/02 (Sonnet 3.7、 Claude Code research preview) ── 「目的は開発者の使い方を理解し将来のモデル改善に活かす」 という insider 引用。 Claude Code は最初から実験的に release された
  • 2025/05 (Opus 4 / Sonnet 4、 Claude Code GA、 SDK 公開) ── context 管理が改善、 task complete までの reward hacking が減少
  • 2025/07 (Ralph Wiggum 技法の Jeffrey Huntley 論文) ── 「単純な prompt を Claude Code CLI に loop で食わせる」 のシンプル化が業界で広がった転換点
  • 2025/09-10 (Sonnet 4.5、 Claude Code 2.0、 SDK 改名) ── モデルが自分の context を track する 「context-aware」 化、 checkpoints 導入、 Claude Code SDK が Agent SDK に改名 (coding 以外への汎用性認識)
  • 2025/10-11 (Haiku 4.5、 Opus 4.5) ── 「Sonnet workhorse + Opus planner」 体制が経済的に成立。 sub-agent 並列化が現実的に
  • 2025/11 (Skills、 progressive disclosure、 programmatic tool calling) ── front matter のみ load、 必要時に skill 本体、 さらに必要時に script という 3 段階 disclosure 確立
  • 2025/11 後半 (Anthropic 公式 long-running agents 記事) ── initializer + harness loop architecture を公式に公開
  • 2025/12-2026/02 (Opus 4.6 / Sonnet 4.6、 agent teams、 server-side compaction、 1M context GA) ── Opus 4.6 が planning に特化、 Sonnet 4.6 が Opus 級 intelligence を Sonnet 価格で提供。 sub-agent 同士が直接通信できる agent teams、 サーバー側自動 compaction、 1M context window 一般提供

METR benchmark METR (Model Evaluation and Threat Research) が運用する agent capability benchmark の 1 つで、 「最小 scaffold (簡易 harness) でエージェントが 50% のタスクを完遂できる持続時間」 を測定する。 Claude モデルの場合: Opus 3.7 で約 1 時間、 Sonnet 4 で約 4 時間、 Opus 4.6 で 12 時間という進化を示した。 ただし実際の long-running agent harness を組めば、 これより遥かに長く稼働可能 (Anthropic の事例では数日) : Opus 3.7 で約 1 時間 → Opus 4.6 で 12 時間 (1 年で 12 倍)。 これは「最小 scaffold で 50% タスク完遂」 の数値で、 本格 harness を組めば数日稼働も可能。

Initializer + Harness Loop アーキテクチャ (2025/11 公式)

Andrew が解説する Anthropic 公式提唱のアーキテクチャ。 「build a Slack clone」 のような 漠然 prompt を、 一連の永続 artifact + 反復 loop で実装する:

  1. Initializer agent ── 漠然 prompt を分解して永続 artifact を作成: (a) featurelist.json (markdown より JSON のほうが上書きされにくいという観察)、 (b) progress file、 (c) Git repo 初期化、 (d) init script、 (e) features-complete フラグ
  2. Harness Loop の各 step:
    • Fresh context window で開始
    • Present working directory と progress file を確認
    • Init script 実行 (smoke test、 server 起動など)
    • 未完了 feature を 1 つだけ pick
    • Implement
    • Puppeteer 等で実際に verify
    • Pass → git commit + feature 状態を pass に更新
    • 未完了があれば fresh context window で次回反復

ここで重要な設計原則: fresh context window で毎回 starts、 永続 artifact (file system) を真の記憶として使う、 1 step 1 feature、 verification loop が built-in。 これは Lawrence Jones (Incident.io) の AI SRE 実装 と完全に同じ哲学を、 Anthropic 公式が体系化した形になる。

GAN-Style Harness ── Generator vs Evaluator の adversarial 構造

Ash が後半で解説する次世代 harness 実験。 着想は Generative Adversarial Networks (GANs) ── 生成側と判別側に adversarial pressure をかけて両者を共に進化させる構造。

実装: Generator (builder) と Evaluator (critic) を 別々の context window / 別々の system prompt で運用。 Evaluator は単に diff を読むのではなく、 Playwright で live page を実際に開いてクリックし、 動作を検証する。 critique を Generator に返し、 loop。 一般的な single-Cloud-Code-session の self-check と本質的に異なる構造。

根本的疑問: 「Evaluator も結局 LLM なら、 rubber stamp してしまわないか?」。 Ash の答え: 「standalone critic を harsh に tune するのは tractable だが、 builder を self-critical に tune するのは無理」。 これは人間と同じ非対称性 ── 美術品を批評するのは簡単、 自分で描くのは難しい。 LLM の 「critic としての能力」 と 「generator としての能力」 のギャップを設計レベルで悪用する戦略。

Front-End Design Rubric ── taste を grade する

Ash が紹介する評価 rubric の具体例 (front-end task 向け):

基準 検証内容 2026/04 時点での重み付け
Design 視覚的品質、 レイアウト、 タイポグラフィ 高 (Opus 4.6 が functionality に強いため)
Originality 「purple gradient AI slop」 を避ける独自性 高
Craft 細部の仕上げ、 余白、 整合性 中
Functionality 動作する、 仕様を満たす 低 (Opus 4.6 がすでに強い)

キャリブレーション法: few-shot example で参照サイトを示す ことで、 evaluator の taste を運営側の taste に収束させる。 「taste は grade できない」 という業界 consensus に対して、 「強い意見を書き下せば grade できる」 という反論。

Planner 役の追加 ── Contract Negotiation Pattern

Ash が示す現在の実験では Generator / Evaluator に加えて Planner を加え 3 役構成にする。 重要な設計原則: 「Planner は granular technical detail を一気に決めない」。 理由: planner の 1 つのエラーが multi-hour 時間軸で全 sprint を通じて cascading に増幅される。 解決: planner は高レベルの sprint 列のみ作成。

さらに重要な innovation が Contract Negotiation。 Generator が code を書き始める前に、 Evaluator と 「done が何を意味するか」 を交渉する:

  • Generator: 「機能 X を作る、 検証は Y で」 を提案
  • Evaluator: 「scope が広すぎる、 Y のテストは弱い、 edge case Z を抜けている」 と push back
  • Files on disk で markdown を読み書きして両者合意まで反復
  • 合意成立後に Generator が実装、 Evaluator は 元 spec ではなく合意した contract で grade

これは Ralph Wiggum loop (固定 plan.md style) が持たなかった adversarial pressure を harness に持ち込む。 「user story を testable assertion に変換する PM 役」 を、 planner の overspecification なしに実現する設計。

編集所見 ── harness が AI 業界の構造を変える

このワークショップを MEMEX で取り上げる視点は 3 つ。

(1) Frontier lab 内部の設計思考が体系的に公開された希少事例。 通常 frontier lab は model release のみを公開し、 内部の experimental harness 思考は非公開で進む。 Ash と Andrew のワークショップは、 Anthropic Applied AI チームが現在試している generator / evaluator / planner の役割分離、 contract negotiation、 GAN-style adversarial pressure といった実装パターンを 1 時間 15 分かけて全公開した稀有な機会。 これらは数ヶ月後に Claude Code の標準機能として組み込まれていく可能性が高い、 つまり 「これから何が普通になるか」 の予告 として読める。

(2) 「harness vs model」 の役割境界が常に移動する thesis。 「Harness はモデルが良くなれば消える」 という直感的予想は誤り。 実際には harness はモデルの弱点を埋める形で進化し、 その役割を訓練データに変えてモデルに焼き込まれ、 そこで harness の その部分は削除され、 別の新しい弱点に harness が回り込む。 この反復構造を Andrew は 「the frontier doesn't really shrink, it just moves」 という Ash の言葉で要約する。 これは Karpathy の Software 3.0 議論 と通底する 「abstraction layer の段階的上昇」 のミクロ実装。

(3) MEMEX の AI×経済 / AI×政治 軸への含意。 5-6 時間稼働の autonomous agent が実用化されると、 開発者の 1 日労働時間 (8 時間) と並列でほぼ等しい agent 労働時間が確保できる。 これは Intercom が 9 ヶ月で開発速度 2 倍 や PFF の post-engineer engineering org で観測される productivity 倍化現象の技術的基盤。 一方で 英国政府の 10DS による Insurgency Model も、 これら long-running agent を内部 tool に投入することで成立する。 long-running agent は単なる技術トピックではなく、 経済・組織・国家機関の構造変化を支える infrastructure。

動画の構成 (主要箇所のみ抜粋)

  • (00:00) 自己紹介、 Anthropic Applied AI チーム
  • (02:00) Boris (Claude Code 創始者) の 1 周年記念ツイート引用 ── 20 分 → 数日稼働
  • (02:30) Long-running agent の 3 つの困難 (context / planning / 自己評価)
  • (04:00) Model と harness の co-evolution、 METR benchmark
  • (05:30) Agent SDK の primitives 紹介
  • (06:00) Claude Code release タイムライン開始 (2024 中頃 → 2025/02)
  • (08:00) 2025/05 Opus 4 / Sonnet 4 / Claude Code GA / SDK 公開
  • (09:00) Ralph Wiggum 技法 (Jeffrey Huntley、 2025/07)
  • (11:00) 2025/09 Sonnet 4.5、 context-aware 化
  • (12:00) 2025/10-11 Haiku 4.5、 Opus 4.5、 Skills + progressive disclosure
  • (13:00) 2025/11 Anthropic 公式 long-running agents 記事の architecture 解説
  • (15:00) 2025/12-2026 Opus 4.6、 Sonnet 4.6、 agent teams、 1M context
  • (16:00) 「harness は消えず、 進化する」 thesis
  • (17:50) Ash 登場、 「フロンティアは縮むのではなく移動する」
  • (18:00) GAN-style harness の紹介 ── generator vs evaluator
  • (19:00) 「critic-tuning は tractable、 builder-self-criticism は無理」 の asymmetry
  • (21:00) Front-end design rubric の 4 基準
  • (24:00) Playwright を使った live page evaluation のデモ
  • (28:00) Planner 役の追加、 sprint 分解
  • (31:00) Contract negotiation pattern
  • (40:00) Demo: 「retro game maker を作って」 prompt から完成までの実演
  • (60:00) Generator / Evaluator / Planner の役割分離の効果検証
  • (70:00) 残時間で Q&A、 まとめ

出典