長時間稼働 AI エージェントの設計原則 ― Anthropic が語る5つの失敗パターンと"Harness"設計(Google Cloud Next '26 レポート)

はじめに

こんにちは、NRIの中山です。私は普段、アプリケーションのエンハンス業務に携わっています。現在、最も注力しているのは、レガシーシステムにおいてウォーターフォールモデルで開発してきた手法を、AIをベースとしたAI駆動開発にシフトさせることです。これによる抜本的な生産性革新を実現しようと日々奮闘しています。

そのような問題意識もあり、新たな技術や知識を得るため、 2026年4月22日（水）から24日（金）にかけてラスベガスで開催された Google Cloud Next ’26へ参加してきました。本稿では、イベントの2日目に開かれたAnthropic（Claude の開発元）のセッション「Long-running agents: Lessons from the enterprise frontier」についてレポートします。

Google Cloud Next’26について

Google Cloud Next は、Google Cloud が主催する年次最大級のグローバルカンファレンスで、新サービス・新機能が基調講演で一斉に発表される場です。今年のメインテーマは「The Agentic Cloud」。ブレイクアウトセッション、ハンズオンワークショップ、ライトニングトーク、デモ展示など多彩な形式で構成され、世界中のエンジニア・ビジネスリーダーが業界を超えて交流する機会となっています。

セッション概要：長時間稼働エージェントが直面する壁(Long-running agents: Lessons from the enterprise frontier)

3日間で多くのセッションを聴講しましたが、本稿では AnthropicのエンジニアHarsh Patel氏による掲題のセッションを取り上げます。
議論の出発点としてPatel氏が提示したのは、Anthropic がエンタープライズ顧客から最も多く受けるという次の問いでした。

「Claudeに同じプロンプトを与えると、15分で「動く」ものを返して、そこで停止する。どうすれば動き続けさせられるのか？」

検証用デモは難なくこなすエージェントが、業務に組み込んで数時間動かすと止まる・品質が落ちる――こうした悩みに心当たりのある方は多いのではないでしょうか。
Patel氏のセッションでは、この課題に対し以下の3つの観点から知見が示されました。

【1】長時間稼働を阻む 5つの障害パターン
【2】障害を乗り越える「Harness（ハーネス）」設計
【3】チームに持ち帰るべき行動原則

本稿では主にこの3点の内容をまとめていますので、自社の AI エージェント運用で「次に何を足し、何を剥がすべきか」を判断する際の参考としていただければ幸いです。

「15 分で止まる」エンタープライズの課題

Patel氏はまず、求められるのが数時間にわたる継続稼働である一方、モデル単体ではコンテキストウィンドウの上限が必ず壁になる点を指摘しました。
そのうえで「モデル単体の能力向上だけでは解決しない」と明言し、解はモデル周辺に組むスキャフォールディング(足場)= Harness の設計にあると整理しています。

【1】長時間稼働を阻む 5つの失敗パターン

セッションでは、長時間稼働下でエージェントが陥るパターンを 5つに分類しています。

Context Rot（コンテキスト腐敗） コンテキストウィンドウが埋まるにつれ、過去情報の参照精度が劣化し矛盾した判断が増える。
Premature Completion（早期完了） コンテキスト上限を察知したモデルが「Context Anxiety(コンテキスト不安)」に陥り、作業を早期に切り上げる。
Lossy Compaction（（要約による)情報欠落） 要約処理の過程で、後続セッションが必要とする詳細情報が失われる。
Shallow Plans（浅い計画） タスクを分解せず一発完了を試み、長期タスクで破綻する。
Generous Self-evaluation（甘い自己評価） 自分の生成物を甘く評価し、バグが残ったまま「done」と扱う。最も厄介な失敗様式。

Patel氏が強調したのは、これらが独立に発生するのではなく、コンテキスト肥大化を起点に連鎖し、最後の自己評価バイアスが品質低下を見逃させるという構造でした。

【2】障害を乗り越える「Harness（ハーネス）」設計

続いてPatel氏は、Harness を「モデルがまだ単独で確実に行えないことを補う足場」と定義し、その構成要素としてPrompts／Structured Artifacts／Tools & Skills／Agent Architecturesの4つを挙げました。これらを実行し、トレースを読みながら反復的にチューニングしていくのが基本姿勢です。セッションでは具体的な実装テクニックが3つ紹介されました。以下に抜粋してご紹介します。

テクニック 1 : 構造化成果物で状態を引き継ぐ
テクニックの1つ目は、「コンテキストウィンドウに状態を溜めるのではなく、構造化成果物に書き出して、次のセッションで読み戻す」というアプローチです。

Patel氏が示したスライドでは、進行中の Session N が Build → Test → Commit と進み、最後の Commit ステップで progress.json / features.json / git log といった構造化成果物に状態を書き出します。次の Session N+1 は N のコンテキストを引き継がず、完全にフレッシュなウィンドウで起動し、まず "Read State" でこれらの成果物を読み込み、"Pick Next Feature" で次に着手するフィーチャーを選んで Build & Test に入ります。いわばセッション間の「セーブデータ」です(この比喩は筆者の理解による補足です)。

Patel氏によれば、この設計により5つの失敗パターンのうち1.Context Rot と3.Lossy Compactionが同時に解消されます。フレッシュウィンドウで開始するためコンテキスト肥大化が起こらず、構造化された成果物は要約による情報損失を伴わないためです。

テクニック 2 : コードを書く前にスコープを分解する

テクニック 2つ目は、コードを書く前にスコープを徹底的に分解するというアプローチです。Patel氏は4段階のフローを示しました。

User Brief — ユーザーから「Claude.ai のクローンを作って」のような要件が提示される。
Planner Agent — 専用の Planner エージェントが「何を作るか(what)」だけを定義する。「どう作るか(how)」は記述しない。プロダクト思考に徹し、要件をテスト可能な最小単位まで分解する。ここが本セッションで筆者が最も新規性を感じたポイントでした。
Feature Spec — 結果として 200 を超えるテスト可能な要件が生成され、各フィーチャーには受け入れ条件と優先順位が付与される。
Builder Agent — Builder は1セッションで1フィーチャーだけを実装し、Build → Test → Commit のサイクルを回す。進捗は `progress.json` に書き出される。
Patel氏は、この分業により5つの失敗パターンの 2.Premature Completion と 4.Shallow Plans が解消されると説明しました。事前にスコープが分解されているため一発完了の試み自体が起こらず、「1セッション1フィーチャー」という制約により管理可能な単位に必ず分割されるからです。

テクニック 3 : 生成と評価を独立コンテキストで分離する

テクニック3つ目は、生成と評価を独立したコンテキストウィンドウで分離するというアプローチで、これにより5つ目の失敗パターンであるGenerous Self-evaluationに対処できます。

構成はGenerator(実装担当) とEvaluator(評価担当)の2者からなり、Patel氏は Evaluator 側に3つの特徴を挙げました。

Fresh Context — Generator のコンテキストを共有しない。Generator が「なぜこの実装にしたか」という文脈を持たないため、選択を内在化することなく、純粋にアウトプットだけを評価できる。Patel氏はこの点を本テクニックの本質と位置付けていました。
Rubric — 「動けば OK」のような曖昧な評価ではなく、明文化されたルーブリックで採点する。
Playwright — 実際のブラウザ自動化ツールで動作検証する。言葉ではなく実物で確かめる。
Patel氏のメッセージを一言で表せば、「相関のないコンテキストが、独立した評価を可能にする」ということだと筆者は理解しました。

Harnessがモデルの信頼可能な領域を外側に拡張する

ここまで Harness の3つのテクニックを示してきました。
ここでは、Harness が全体としてモデルに何をもたらすのかを概念図で示します。下記の図は、Patel氏のいくつかのスライドを私の解釈で作り直したものです。中央の濃い青の円が「Model Reliable Zone」、モデル単体で確実に動作する領域です。短期タスクであれば、モデル単体でも信頼性高く完了できます。

外側の点線の円が、Harness を加えることで拡張された領域です。「+ Harness」のラベルが示す通り、ここまで信頼性ゾーンが広がります。
円の周りに、Artifacts、Planners、Evaluators という3つのオブジェクトを配置していますが、これは先ほどの3つのテクニックそのものです。
それぞれが、モデル単体では届かなかった「別カテゴリのタスク」を、信頼性ゾーンの内側に取り込みます。
右側の説明テキストにある通り、中心がモデル単体の領域、外周がHarnessで拡張された領域、そして端、edgeにあたる赤い領域が最も困難なタスクが位置する領域です。

Patel氏が強調していたのは、「最も困難なタスクは常に edge に存在する」という点です。Harness が edge を外に押し広げる限り、新しい困難なタスクが新たな edge として現れる――つまり Harness の設計に終わりはない、というメッセージでした。

モデル改善時にHarnessを見直し不要な層を除去する

Patel氏はまた、モデル改善のたびに Harness を見直す必要性を強調していました。
"Yesterday's scaffolding becomes today's overhead, so strip it back." (昨日の足場は今日のオーバーヘッドになる。だから剥がしなさい)
モデルがアップグレードされたら、すべての前提を見直し、不要になった Harness は積極的に取り除く――これがPatel氏の示す鉄則です。

【3】チームに持ち帰るべき 4 つの行動原則

セッションの最後に、Patel氏は以下4点を聴講者へのメッセージとして提示しました。

能力の境界を探る Harness の価値はモデルの限界点で最も発揮される。
トレースを読む 5 つの Failure Mode のどれが起きているかを見極めれば、次に足すべきコンポーネントが見える。
前提を見直す モデルがアップグレードされたら、不要になった Harness を積極的に剥がす。
設計は自分たちの手で “Claude Managed Agents gives you the primitives. The design is yours.” （プラットフォームはプリミティブを与える。設計は利用者の責任である）
※本来は4月にリリースされたClaude Managed Agentsの紹介をセッションの中で行っていましたが、今回このブログでは説明を割愛させていただきました。

Google Cloud に関するソリューション・事例はこちら

まとめ ― 最初の一歩は「トレースを読む」こと

本セッションを通じて筆者が受け取った最大のメッセージは、長時間稼働 AI エージェントの実用化はモデル能力の向上を待つ問題ではなく、Harness をどう組み・どう剥がすかという「設計の問題」として捉え直すべきテーマだ、ということでした。

Patel氏が第一歩として推奨していたのは、現在動かしているエージェントの実行トレースを読み、5つの失敗パターンのどれが起きているかを分類すること。これが最もコスト効率の高い着手点だと述べていました。筆者自身も帰国後、まずは手元のエージェントのトレース観察から始めてみたいと感じています。
また本記事がAI エージェントの業務活用に悩んでいる方の一助となれば幸いです。

本記事は Anthropic 登壇セッション「Long-running agents: Lessons from the enterprise frontier」(Google Cloud Next '26) の聴講内容をもとに、筆者の解釈・補足を交えて構成しています。