AIを使って「ちょっとした文章の修正」や「コードの補完」をこなすのと、「6時間以上かけてフルスタックアプリを自律的に作らせる」のでは、話がまったく違います。
後者を実現しようとしたとき、多くのエンジニアが直面するのが同じ壁です。最初の1時間は快調なのに、途中からエージェントの振る舞いがおかしくなる。仕様を外れた実装をし始める。あるいは「完成しました」と言いながら、コアな機能がまったく動いていない。
Anthropicのエンジニアリングチームは、この問題を正面から研究し、2026年3月に一つの答えを公開しました。それが「ハーネス設計（Harness Design）」というアプローチです。
この記事では、そのAnthropicの最新研究をもとに、AIエージェントが長時間タスクで失敗する理由と、それを乗り越えるためのマルチエージェント設計の考え方を、実際の事例とコストデータを交えて解説します。「AIに本格的な開発を任せたい」と考えているエンジニアやチームリーダーの方には、かなり参考になるはずです。
- そもそも「ハーネス」って何？
- 長時間タスクでAIエージェントが失敗する2つの根本原因
- フロントエンドデザインで試した「主観的品質の数値化」
- フルスタック開発への応用：3エージェント構造の詳細
- ハーネスの複雑さを削ぎ落とす：Opus 4.6での実験
- ハーネス設計の実践で押さえるべきポイントと注意点
- 類似ツール・アプローチとの比較
- まとめ：エンジニアリングの本質はモデルの外側にある
そもそも「ハーネス」って何？
エンジニアにとって身近なあのシステムと同じ発想
ハーネス（Harness）という言葉、ソフトウェア開発者なら「テストハーネス」で耳馴染みがあると思います。テストをうまく動かすための足場・制御構造のことですね。
AIエージェントの世界での「ハーネス」も、基本的に同じ概念です。AIモデル本体の外側に構築する、制御・管理・評価の仕組み全体を指します。まず図を描いて、その後に記事本文を続けます。
AIエージェントが長時間タスクを自律的にこなすための3エージェント構造を図解します。
なぜ「モデルを変えれば解決する」は幻想なのか
「GPTよりClaudeの方がいい」「最新モデルに乗り換えれば問題が消える」。こうした思考は、実は的外れです。
コストは20倍以上かかりますが、品質の差は歴然です。この結果が示しているのは、「モデルの性能」より「どう使わせるか（ハーネス設計）」の方が、アウトプットの品質を決定する大きな要因になるということです。
長時間タスクでAIエージェントが失敗する2つの根本原因
コンテキスト不安という隠れた問題
AIエージェントの「コンテキストウィンドウ」（一度に処理できる情報量）には上限があります。タスクが長引くほど、コンテキストが埋まっていきます。
ここで起きる問題が「コンテキスト不安（Context Anxiety）」です。自分の処理できる量の限界が近づいていると感知したエージェントが、本来はまだ途中なのに「そろそろ完了にしよう」と作業を打ち切ってしまう現象のことです。
人間に例えるなら、残業時間の制限が迫ってきたエンジニアが、機能が壊れたままでも「一応動きます」とコードを提出してしまうようなものです。
Anthropicの実験では、Claude Sonnet 4.5がこのコンテキスト不安を顕著に示しており、コンテキストの圧縮（過去の会話を要約して短くする手法）だけでは対処しきれなかったことが報告されています。解決策として有効だったのが「コンテキストリセット」、つまり新しいエージェントに状態を引き継いで白紙の状態で再スタートさせる手法でした。
自己評価が機能しないという問題
もうひとつが、AIが自分の仕事を採点するときの「甘さ」です。
「このコードをレビューして」とエージェントに頼むと、自分で書いたコードを高評価する傾向があります。明らかに動いていない機能も「実装済みです」と答える。これは現在のLLM全般に見られる特性です。
特にデザインの品質のような主観的な評価では、この傾向が顕著です。「このUIは美しいですか？」という問いに対して、AIは「はい、美しいです」と答えがちです。でも人間が実際に見ると、ありきたりなテンプレートそのものだったりします。
解決策は「採点役と実装役を別エージェントに分ける」ことです。Anthropicが採用したGAN（生成的敵対ネットワーク）にインスパイアされた発想で、生成側（Generator）と評価側（Evaluator）を分離します。評価側を「懐疑的なレビュアー」として設定する方が、自分への批判を促すより、はるかに制御しやすいことが分かっています。
フロントエンドデザインで試した「主観的品質の数値化」
ハーネス設計の検証はフロントエンドデザインの改善から始まりました。Anthropicのエンジニア、Prithvi Rajasekaran氏が着目したのは「美しさは採点できないが、良いデザインの原則は採点できる」という考え方です。
4つの評価基準を言語化する
以下の4軸で設計します。
- デザインクオリティ ── 色・タイポグラフィ・レイアウト・余白が全体として一つの世界観を作っているか
- オリジナリティ ── テンプレそのままではなく、意図的なデザイン判断の痕跡があるか（AI生成によくある「紫グラデーション＋白カード」は減点対象）
- クラフト ── 技術的な完成度。タイポグラフィ階層、余白の一貫性、コントラスト比
- 機能性 ── ユーザーがUIを見て、何をする場所か直感的に分かるか
評価ループで何が起きたか
5〜15回のイテレーション（繰り返し）を経て、生成AIが段階的により大胆なデザイン判断をするようになります。Anthropicの実験では、オランダの美術館のウェブサイトを生成するタスクで、9回目まではモダンな暗めのページを作っていたのが、10回目で突然方針を変え、CSS perspectiveで描いた3Dの展示室空間をベースにした没入型UXに生まれ変わったという事例が報告されています。一回の生成では生まれ得ないような創造的な飛躍です。
注目すべきは「最後のイテレーションが常に最良」とは限らない点です。途中のバージョンの方が好みという場合もある。この余白こそが、人間がハーネスの中でどこに介入するかを考える余地でもあります。
フルスタック開発への応用：3エージェント構造の詳細
プランナーが「野心的な仕様書」を作る
「2Dレトロゲームメーカーを作って」という1文のプロンプトを渡すと、プランナーはそれを16の機能要件・10のスプリントに展開した詳細な製品仕様書に変換します。スプリントとは、ソフトウェア開発でよく使われる「小さな開発サイクル」のことです。
プランナーへの指示で重要なのは「AIならではの機能を仕様に織り込むこと」と「実装の細部には踏み込まないこと」の2点です。実装の細部まで決めてしまうと、仕様の誤りが後段のコードに連鎖してしまうからです。
ジェネレーターとエバリュエーターが「契約」を結ぶ
各スプリントに入る前に、ジェネレーターとエバリュエーターは「スプリントコントラクト（Sprint Contract）」を合意します。「このスプリントでは、四角いエリアをドラッグで塗りつぶせるようにする。検証は、実際にマウスでドラッグした際に矩形全体が塗られることを確認する」といった具体的な合意です。
この仕組みがないと、生成AIは「それっぽく見えるが、実際には動かない」機能を量産しがちです。契約によって「何が完成と言えるか」を事前に定義することで、曖昧な完成判定を防ぎます。
エバリュエーターが本物のQAエンジニアとして振る舞う
エバリュエーターにはPlaywright（ブラウザを自動操作するテストツール）を持たせ、実際にアプリを操作させます。静的なスクリーンショットを見るのではなく、ボタンをクリックし、フォームを入力し、データベースの状態まで確認します。
実際に検出されたバグの例：
| 契約条件 | エバリュエーターの指摘 |
|---|---|
| 矩形ツールでドラッグすると領域全体が塗られる | 開始点と終了点にしか置かれない。fillRectangle関数がmouseUpで呼ばれていない |
| エンティティのスポーン地点を選択して削除できる | 削除キーのハンドラがselectionとselectedEntityIdの両方を要求しているが、エンティティクリックではselectedEntityIdしかセットされない |
| アニメーションフレームをAPIで並び替えられる | PUT /frames/reorderルートが/{frame_id}の後に定義されており、FastAPIがreorderを整数のframe_idとして解釈し422エラーを返す |
この精度のバグ指摘ができるようになるまで、エバリュエーターのプロンプトを何度も調整する必要があったことも正直に書かれています。最初のうちは「問題を見つけたのに、まあ大きな問題じゃないか」と自己判断して通過させてしまう傾向があり、批判的なレビュアーとして振る舞わせるためのチューニングが必要でした。
ハーネスの複雑さを削ぎ落とす：Opus 4.6での実験
「前提はすぐ古くなる」という原則
最初に構築した3エージェント＋スプリント構造は、Claude Opus 4.5で動作させることを前提にしていました。ところがAnthropicがOpus 4.6をリリースし、モデル自体の能力が大きく向上したことで、ハーネスを簡略化できるようになりました。
「ハーネスの各コンポーネントは、モデルが単独ではできないことへの補正だ。だからモデルが進化するたびに、その前提を見直せ」というのがAnthropicが伝えるメッセージです。
スプリント構造なしでどこまでできるか
Opus 4.6では「コンテキスト不安」がほぼなくなったため、スプリントに分割せず、エージェントが2時間以上連続して作業を続けられるようになりました。コンテキストリセットも不要になり、SDKの自動圧縮機能で対処できます。
DAW（音楽制作ソフトウェア）を「ブラウザ上でWeb Audio APIを使ったフル機能のDAWを作って」という1文から生成した実験では、プランナー・ビルド・QAを合わせて3時間50分・コスト$124.70という結果になりました。
完成したアプリはプロの音楽制作には遠く及びませんが、アレンジメントビュー、ミキサー、トランスポートが動作し、AIエージェントを通じてテンポや調を設定し、メロディとドラムトラックを生成し、ミキサーを調整し、リバーブを加えるという一連のワークフローを実際にこなせました。
ハーネス設計の実践で押さえるべきポイントと注意点
今日から使える3つの原則
原則1：シンプルから始めて、必要になったら複雑にする
Anthropicの「Building Effective Agents」でも強調されている考え方です。「とりあえずマルチエージェントにする」のではなく、まず単一エージェントで試して、何が足りないかを観察してから構造を追加する。ハーネスは最小限から育てるものです。
原則2：エバリュエーターの判断基準を丁寧に言語化する
「良い実装か悪い実装か」という抽象的な評価軸ではなく、「スプリントコントラクトの条件X、Y、Zをすべてクリアしているか」という具体的な合否基準を設ける。基準が曖昧なままでは、エバリュエーターがジェネレーターに優しくなりすぎます。
原則3：モデルが更新されたらハーネスを見直す
昨日まで必要だったコンポーネントが、今日のモデルでは不要になっているかもしれない。逆に、新しいモデルの能力を使えば今まで不可能だったことができるようになるかもしれない。ハーネスはメンテナンスが必要な生き物です。
コストとのトレードオフを正直に見る
| 指標 | ソロ実行 | ハーネス（V1） | ハーネス（V2/Opus 4.6） |
|---|---|---|---|
| 実行時間 | 20分 | 6時間 | 3時間50分 |
| コスト | $9 | $200 | $125 |
| 動作品質 | コア機能が動かない | 16機能が動く | コアDAW機能が動く |
| 適した用途 | プロトタイプ検証 | 複雑なフルスタック | 本格的なWebアプリ |
ハーネスは銀の弾丸ではありません。20倍のコストに見合うだけの複雑なタスクでなければ、単一エージェントで十分な場合も多いです。「このタスクはモデルが単独でうまく処理できるか？」という問いが出発点です。
現時点での限界
QAエージェントはまだ完璧ではありません。実験でも「細かなレイアウトのずれ」「深くネストされた機能のバグ」は見逃されています。AIはまだ音を聞けないので、DAWの「音楽的なセンス」をQAすることもできません。現状は「品質ゲートとして人間に代わるもの」ではなく、「人間のレビューを補助・効率化するもの」と捉えるのが現実的です。
類似ツール・アプローチとの比較
| アプローチ | 自律性 | 品質保証 | 対象タスク | 主なリスク |
|---|---|---|---|---|
| ハーネス設計（本手法） | 高 | エバリュエーターによる自動QA | フルスタック・長時間 | コスト増・チューニング工数 |
| 単一エージェント（ソロ） | 中 | なし | 短時間・単純タスク | 品質のばらつきが大きい |
| Ralph Wiggum方式 | 高 | ループによる自己修正 | コーディング全般 | 収束しない可能性 |
| 人間主導のCI/CD | 低〜中 | 人間のコードレビュー | 既存開発フロー | 人的コスト |
| RPA（従来型自動化） | 低 | ルールベース検証 | 定型業務 | 変化への対応が難しい |
まとめ：エンジニアリングの本質はモデルの外側にある
2025年から2026年にかけて、AI開発の現場で急速に広まっているのが「モデルの性能だけで勝負できる時代は終わった」という認識です。
Anthropicのこの研究が示しているのは、AIエージェントの真の性能は、モデルそのものの能力だけでなく、モデルをどう使わせるか、という「制御の仕組み」で大きく変わるということです。
ハーネスエンジニアリングは、ソフトウェア開発で言えばCIパイプラインやコードレビューに近い発想です。優れた開発者も、gitのブランチ戦略やテストスイートという「ハーネス」の中で最大のパフォーマンスを発揮します。AIエージェントも同じで、適切な構造に入れてやることで、はじめて本来の能力を引き出せます。
「自分のチームでもAIに長時間タスクを任せてみたい」という方は、まず小さな実験から始めてみてください。単一エージェントを動かし、どこで失敗するかを観察する。その失敗パターンから、どんなハーネスが必要かが見えてきます。
ハーネスの面白さは、モデルが進化しても「次の探索領域」が尽きないことにあります。むしろモデルが良くなるほど、ハーネスで到達できる地平も広がっていく。エンジニアにとっては、この設計の探索こそが、これからの腕の見せ所になるはずです。
