長時間AIエージェントの「ハーネス設計」入門 — Anthropicエンジニアリングブログを読み解く

2026.03.2917 min

Claude Codeエージェント設計ハーネス設計AI開発マルチエージェント

長時間AIエージェントの「ハーネス設計」入門

原著： Harness design for long-running application development（Anthropic Engineering Blog, 2026年3月24日）
本記事の位置づけ： 原著を日本語で要約・再構成し、実務への応用ポイントを加えたものです。

TL;DR（3行で理解する）

AIに長い仕事をさせるには「設計（ハーネス）」が不可欠。単発プロンプトでは品質に天井がある。
GAN（敵対的生成ネットワーク）の発想を転用し、「生成エージェント」と「評価エージェント」に分離すると品質が飛躍的に上がる。
モデルが賢くなるほど、ハーネスの設計を見直す機会が生まれる。不要になったスキャフォールドは取り外すことが大事。

1. 「ハーネス設計」とは何か

「ハーネス（Harness）」とは、AIエージェントが長時間・複雑なタスクをこなすための設計フレームワーク全体のことです。単体のプロンプト1枚ではなく、複数のエージェントがどう連携し、どうコンテキストを引き継ぎ、どう品質を検証するかを設計することを指します。

自動車のシートベルト・ハーネスが「乗員を守りながら動きを制御する」ように、AIハーネスは「エージェントが暴走・劣化せずに長距離を走り切る」ための仕組みです。

なぜ今これが重要か
Claude Codeをはじめとするコーディングエージェントは、短い単発タスクには強い。しかし「数時間かけてフルスタックアプリを完成させる」「デザインを10回反復して洗練させる」という長距離・長時間タスクでは、何も工夫しないと性能が劣化する。

2. ナイーブな実装が失敗する2つの理由

AnthropicのエンジニアPrithvi Rajasekaranは、何も工夫しない実装（単一エージェント）が高品質な長時間タスクに失敗する原因を2つに絞り込んでいます。

失敗モード①：コンテキスト・アンクザイエティ（Context Anxiety）

症状	原因	影響
途中でタスクを打ち切り、まとめに入る	コンテキストウィンドウが埋まってきたことをモデルが感知する	未完成・品質劣化のまま完了扱いになる

対処法：コンテキスト・リセット
コンテキストを完全にクリアし、「ハンドオフアーティファクト（前エージェントの進捗まとめファイル）」を使って次のエージェントにバトンを渡す。要約（コンパクション）だけでは不十分で、白紙から再スタートする「リセット」が必要なケースがある。

[旧エージェント] 作業完了 → handoff.md を書き出す
         ↓
[新エージェント] handoff.md を読み込んで作業を継続

失敗モード②：自己評価の甘さ（Self-Evaluation Bias）

自分が作ったアウトプットを自分で評価させると、AIはほぼ確実に過大評価します。

「一流の仕事です！」→ 実際は動かないUIだった、というケースが多発。

これはデザインのような主観的なタスクで特に顕著。「このデザインは美しいか？」という問いに対して、モデルは必ず「はい」と答えようとします。

対処法：評価エージェントを分離する
生成を担うエージェントと、評価を担うエージェントを別インスタンスに分けることで、評価者が「懐疑的な姿勢」を持ちやすくなる。

3. コアコンセプト：GAN発想のマルチエージェント設計

Rajasekaranが採用したのは、深層学習の**GAN（Generative Adversarial Network）**の構造から着想を得たアーキテクチャです。

GAN の構造
　Generator（生成器）←→ Discriminator（識別器）
　　　　　↕ フィードバックループ

AI ハーネスへの転用
　Generator Agent（生成エージェント）
　　↓ アウトプット
　Evaluator Agent（評価エージェント）
　　↓ 詳細な批評・スコア
　Generator Agent（次イテレーション）

このループを繰り返すことで、単発生成では届かない品質水準に到達できます。

4. 実験①：フロントエンドデザインへの適用

主観的品質を「採点可能な基準」に変換する

「良いデザインか？」という問いを、以下の4軸に分解しました。

評価軸	問い	重み
デザイン品質	色・タイポ・レイアウト・画像が一体となった雰囲気を生み出しているか	高
独自性（Originality）	テンプレートのコピーではなく、意図的なクリエイティブ判断の痕跡があるか	高
クラフト（技術的完成度）	タイポグラフィ階層、スペーシング、カラーコントラストは破綻していないか	中
機能性	ユーザーが迷わず操作できるか	中

日本語コンテキストでの注意点
「独自性」の評価基準には「AIあるあるパターン」（白背景に紫グラデーション等）を明示的にペナルティとして設定。日本語UIの場合は「明朝体×等幅フォントの組み合わせ」「デフォルトのGoogle Fontsそのまま」等も同様にリストアップすると効果的。

評価エージェントの「キャリブレーション」

評価エージェントをfew-shotサンプル（採点例）で調整することで、「私の好み」に近い判断基準を持たせました。これをしないと評価者もすぐに「どれも良い！」と言いだします。

実際の結果

オランダの美術館Webサイトを生成するタスクで、10回目のイテレーションで予想外のジャンプが発生しました：

9回目まで：洗練されたダークテーマのランディングページ
10回目：3Dの展示室をCSSパースペクティブで表現。チェッカー柄の床、壁に絵画を配置、ドアで部屋を移動する空間体験型UIへと大転換

これは単発生成ではまず出てこない発想の飛躍です。

5. 実験②：フルスタック開発への適用（3エージェント構成）

アーキテクチャ全体像

ユーザー（1〜4文の短い指示）
　　↓
[プランナーエージェント]
　・短い指示を詳細な製品仕様書に展開
　・スコープは野心的に設定
　・AI機能を自然に組み込む
　　↓ 仕様書（ファイル）
[ジェネレーターエージェント]
　・スプリント単位で機能を実装
　・スプリント開始前に「完了定義」を評価者と合意（Sprint Contract）
　・実装後に自己評価 → QAへ渡す
　　↓ コード＋スプリントサマリー（ファイル）
[エバリュエーターエージェント（QA）]
　・Playwright MCPでブラウザを実際に操作・テスト
　・スプリントコントラクトの各条件を検証
　・合格なら次スプリントへ、不合格なら詳細フィードバックをジェネレーターに返す

スプリントコントラクト（Sprint Contract）の概念

実装前に「何を作り、どう検証するか」をジェネレーターとエバリュエーターが事前合意します。

なぜ重要か：仕様書は意図的に高レベルに書かれているため、「完成」の解釈がエージェントによってバラバラになりやすい。コントラクトがその橋渡しをする。

Sprint 3の例では27個の検証条件が設定され、エバリュエーターは各条件を実際のブラウザ操作で確認しました。

実際に検出されたバグの例：

条件	評価結果
矩形塗りつぶしツールがクリック＆ドラッグで機能する	FAIL — 開始点と終点しか塗られない。`fillRectangle`関数は存在するが`mouseUp`で呼ばれていない
エンティティのスポーン点を削除できる	FAIL — Deleteキーのハンドラが`selection`と`selectedEntityId`の両方を要求しているが、エンティティクリックでは`selectedEntityId`しかセットされない
APIでアニメーションフレームの順序を変更できる	FAIL — `PUT /frames/reorder`ルートが`/{frame_id}`より後に定義されており、FastAPIが`reorder`を整数として解釈して422エラー

ソロ実行 vs フルハーネスの比較

	ソロ（単一エージェント）	フルハーネス
実行時間	20分	6時間
コスト	$9	$200
プレイモード	動かない	動く
機能の豊富さ	最小限	AI機能・サウンド・エクスポートまで

コストは20倍以上ですが、ソロ実行では「中心機能が壊れたまま完了」という致命的な欠陥がありました。

6. ハーネスの進化とモデル更新への対応

モデルが賢くなったらハーネスを削ぎ落とす

Opus 4.5 → Opus 4.6へのアップグレードを機に、スプリント構造を削除する実験が行われました。

変更	理由
スプリント分割を廃止	4.6は長時間タスクへの耐性が向上し、自力で2時間以上継続して作業できるようになった
コンテキストリセットを廃止	4.6ではコンテキストアンクザイエティが大幅に改善
評価エージェントは維持	モデルが強化されてもスタブ実装・バグの見逃しは残るため、QAは依然として価値がある

原則として抽出できる教訓：

ハーネスの各コンポーネントは「モデルが自力でできないこと」への補完です。
モデルが進化したら、その前提が正しいかを都度テストし、不要になった要素は外す。

DAW（デジタル音楽制作ソフト）での結果

同じプロンプト（1文）からDAWを構築した結果：

フェーズ	時間	コスト
プランナー	5分	$0.46
ビルド（Round 1）	2時間7分	$71
QA（Round 1）	9分	$3.24
ビルド（Round 2）	1時間2分	$36.89
QA（Round 2）	7分	$3.09
ビルド（Round 3）	11分	$5.88
QA（Round 3）	10分	$4.06
合計	3時間50分	$124.70

最終成果物：ブラウザ上で動くDAW（アレンジビュー・ミキサー・トランスポート）＋AIエージェントによる自動作曲機能。

7. 実務への応用ガイド（日本語コンテキスト向け）

以下は、この研究の知見をClaude Codeや社内AI開発プロジェクトに応用するための実践フレームワークです。

適用シナリオ別の推奨構成

シナリオ	推奨構成	備考
単純なLP・静的ページ	単一エージェント＋デザイン基準プロンプト	ハーネス不要。基準の言語化だけで十分
複数画面のWebアプリ	プランナー＋ジェネレーター	QAは省略可。手動確認でカバー
フルスタック業務アプリ	プランナー＋ジェネレーター＋QA	本記事の3エージェント構成
デザイン反復が重要なサービス	ジェネレーター＋デザイン評価エージェント	フロントエンドスキルと組み合わせる

すぐ使える「評価基準の言語化」テンプレート

業務アプリのUI評価に使える4軸（本記事の設計基準を和訳・適応）：

## UI評価基準（Claude Code向け）

### 1. デザイン統一性（Design Coherence）
色・フォント・余白・アイコンが一貫したトーンを持っているか。
「パーツを並べた」感でなく、ひとつの世界観として成立しているか。

### 2. 独自性（Originality）  
BootstrapやMaterial UIのデフォルトそのままになっていないか。
「AIが量産するUI」の典型パターン（灰色ボーダー、デフォルトフォント、青いCTAボタン）を避けているか。

### 3. 技術的完成度（Craft）
フォントサイズの階層、ボタンのホバー状態、フォームのエラー表示、
ローディング状態、レスポンシブ対応などの基本動作が揃っているか。

### 4. 業務適合性（Business Fit）
想定ユーザー（非エンジニア・管理職・現場担当等）が迷わず操作できるか。
主要アクション（登録・検索・承認）への導線が明確か。

コンテキスト引き継ぎのファイル設計

長時間タスクでのコンテキストリセットに使うハンドオフファイルの構造例：

# handoff.md

## 完了済みの作業
- [x] ユーザー認証画面（Email+Password）
- [x] ダッシュボードのレイアウト
- [ ] データ入力フォーム（次エージェントのタスク）

## 技術スタック
- Frontend: Next.js 14 / TypeScript / Tailwind
- Backend: Supabase
- Auth: Supabase Auth（Email+Password）

## 既知の問題・注意事項
- Supabaseのrow level policyはまだ未設定（要対応）
- モバイル表示は未テスト

## 次のエージェントへの指示
データ入力フォームを実装する。バリデーションはzodを使用。
エラー表示はインラインで行い、サブミット後はダッシュボードにリダイレクト。

8. 重要な原則のまとめ

本記事から抽出した設計原則（実務適用版）

評価者を分離せよ
生成と評価を同じエージェントにやらせない。自己評価は必ず甘くなる。
主観的品質を採点可能な基準に変換せよ
「良い」「悪い」ではなく、採点軸と合否基準を言語化する。これが評価エージェントの精度を左右する。
長距離タスクはスプリントに分割せよ（ただし現行モデルでは不要かも）
コンテキストウィンドウの限界に合わせて、スプリント単位で区切り、ファイル経由でバトンを渡す。モデルが進化したら不要になる可能性がある。
ハーネスを周期的に見直せ
新しいモデルが出たら「このコンポーネントはまだ必要か？」を問い直す。不要な複雑さはコストと遅延を増やすだけ。
コスト・品質トレードオフを意識的に選択せよ
ソロ($9/20分)とフルハーネス($200/6時間)の差は20倍。「どのレベルの品質が必要か」を先に決めてからハーネスを設計する。

9. Ogashi視点：Claude Code 101研修への示唆

本記事の知見は、Claude Code研修の応用編コンテンツとして直接転用できます。

研修段階	対応コンテンツ
101（基礎）	単一エージェントでのアプリ構築。本記事はスコープ外
201（応用）	評価エージェントの分離・デザイン基準の言語化・ハンドオフファイル設計
301（上級）	3エージェント構成・スプリントコントラクト・Playwright MCPによる自動QA

201コースの骨格案：

Week 1: ハーネスの概念と失敗モードの理解
Week 2: 評価基準の言語化ワークショップ（自社業務に適した4軸を設計する）
Week 3: 2エージェント構成での実装演習
Week 4: コスト試算とROI設計

参考リンク

原著記事（英語） — Anthropic Engineering Blog
Effective Harnesses for Long-Running Agents — 本記事の前作
Building Effective Agents — 最小構成から始める設計原則
Context Engineering for AI Agents — コンテキスト管理の詳細
Claude Agent SDK — 本記事のハーネスが使用したSDK
Frontend Design Skill — デザイン評価基準の元となったスキルファイル

本記事はAnthropicのエンジニアリングブログを原典として、Ogashi編集部が日本語に再構成・補足したものです。原著の引用・転載は著作権法に基づき最小限にとどめています。