「もっと上手くプロンプトを書けば、AIはもっと良い仕事をしてくれるはず」 そう信じて、毎日プロンプトを書き直していた時期が私にもあります。でも、あるとき気づきました。プロンプトの問題じゃなかったんです。 2026年3月24日、Anthropicが公式エンジニアリングブログで1本の記事を出しました。タイトルは「Harness design for long-running application development」。 著者はAnthropicのLabsチームメンバー、Prithvi Rajasekaran氏。 同じ時期、OpenAIも「Harness Engineering」と題した公式記事を公開。Martin Fowlerのサイト（ソフトウェア設計の世界的権威）でもBirgitta Böckeler氏による解説記事が公開されています。 世界のトップ企業が同時に動いたテーマ。それがハーネス設計です。
「ハーネス」とは、もともと馬具の「馬の力を制御する道具」のこと。AIの文脈では「モデルの能力を最大限に引き出すための設計・仕組み全体」を指します。 プロンプトを1行渡してAIに答えさせるだけでは、モデルの潜在能力のほんの一部しか使えていません。 ハーネス設計は、その周りに「仕組み」を作ることで、同じ1行から桁違いのアウトプットを引き出す技術です。 Anthropic公式ブログはこう表現しています。
「ハーネス設計とは、AIに何をさせるかではなく、AIをどう動かすかを設計する技術だ」 プロンプトを上手く書くことと、AIが上手く動く仕組みを設計すること。この2つはまったく別の技術なんです。
AI活用の技術は、たった4年で3つの時代を駆け抜けています。
「1行の指示を磨く」時代。ChatGPTの登場とともに生まれ、「ステップバイステップで考えて」「あなたは専門家です」といったテクニックが広まりました。
「AIが見る情報の全体を設計する」時代。プロンプトだけでなく、参照ファイル、過去の会話、ツールの使い方まで含めた「文脈全体」を最適化する発想です。
「AIが動く環境そのものを設計する」時代。プロンプトも文脈も、ハーネスの一部にすぎません。エージェントの分担、フィードバックループ、品質評価の仕組みまで含めた動作環境の全体設計が求められます。 この進化の何が重要かというと、AIの成果を決定づける要因が変わったということです。
2024年まで：モデルの性能がすべてだった。 2026年から：仕組みの設計力がすべてになった。 実際、Anthropicの社内ベンチマーク（CORE）では、同じClaude Opus 4.5を使っても、Claude Codeのハーネスで動かすと正解率78%、別のフレームワーク（Smolagents）で動かすと42%。 同じモデルなのに、ハーネスの違いだけでダブルスコアの差が出ています。
ハーネス設計が必要になった背景には、AIエージェントの2つの構造的な弱点があります。
AIには「コンテキストウィンドウ」という、一度に覚えられる情報量の上限があります。この上限に近づくと、モデルが「もうそろそろ終わらせよう」と自ら判断して、作業を早まって切り上げてしまう現象が起きます。 具体的にはこうなります。
もう1つの問題は、AIに「自分が作ったものを評価して」と頼むと、ほぼ必ず高く評価するということ。明らかに低品質でも「良い出来だ」と答えます。 Anthropic公式ブログの表現を借りれば：
「エージェントに自分の作業を評価させると、人間から見て明らかに凡庸な出来であっても、自信を持って称賛する」 これは人間の認知バイアスと同じ構造です。 自分が書いたレポートの問題点に自分では気づきにくいのと同じで、作る役と評価する役を同じAIに任せてはいけないんです。
Anthropicが提案したハーネス設計の核心は、GANの発想をソフトウェア開発に応用した3エージェント構成です。 GAN（敵対的生成ネットワーク）とは、「生成器」と「識別器」を対立させて品質を高める機械学習の手法。 この発想を、AIによるアプリ開発に持ち込みました。
1〜4文のプロンプトを、詳細な製品仕様書に自動展開します。AI機能の組み込みポイントも設計。「何を作るか」に集中し、実装の細部には踏み込みません。
仕様書に基づき、機能を1つずつ実装します。React / Vite / FastAPI / SQLiteなどのスタック。各機能を完了するたびにEvaluatorへ引き渡します。
Playwright MCPで実際にアプリを操作してバグを検出。品質スコアが閾値を下回ったら、具体的な修正指示とともにGeneratorに差し戻します。 ここが最大のポイントです。 作る役と評価する役を分離することで、自己評価バイアスを構造的に排除しています。人間の組織で言えば「開発チーム」と「QAチーム」を分けるのと同じ発想です。
3エージェント構成で特に重要なのが「スプリントコントラクト」という概念です。 コードを書く前に、GeneratorとEvaluatorが「完成の定義」を事前に合意します。 例えば「矩形塗りつぶしツール」を実装するスプリントなら：
Anthropicは、同じプロンプト「2Dレトロゲームメーカーを作成せよ」で、ソロエージェントと3エージェントハーネスを比較しました。
Anthropicの最新モデルOpus 4.6は、「より慎重に計画し、より長くエージェントタスクを持続し、自分のミスを発見するデバッグスキルが向上した」とリリースブログで記されています。 この改善により、V2ハーネスではスプリント構造を廃止。コンテキストリセットも不要になり、2時間超の連続コーディングが可能になりました。 実際にV2ハーネスで検証されたのは、ブラウザDAW（音楽制作ソフト）の自律生成。 Web Audio APIを使ったブラウザDAWを、AIエージェントがテンポ設定→メロディ生成→ドラムトラック→ミキサー調整→リバーブ追加まで、プロンプトだけで全自動実行。合計3時間50分、$124.70。 モデルが進化すれば、ハーネスの設計も進化する。これは終わりのないゲームです。
ハーネス設計を自分の仕事に取り入れるための原則を、Anthropic公式ブログから抽出します。
自己評価バイアスは構造で解決します。作る役と評価する役を同じエージェントに担わせない。Claude Codeなら、メインの作業セッションとは別にレビュー用のセッションを立てるだけでも効果があります。
スプリントコントラクトの考え方です。完成の定義を事前に確定し、曖昧なまま実装を始めない。CLAUDE.mdに「このタスクの完了条件」を書いてから作業を始めるだけで、手戻りは激減します。
「良いか悪いか」ではなく「この基準を満たしているか」に変換します。評価軸には必ず重みをつけること。Anthropicは Design Quality と Originality を重要度「高」、Craft と Functionality を「標準」にしています。すべての評価軸を均等に扱わないことが重要です。
Anthropicの設計哲学は「必要になったときだけ複雑化する」。部品を増やすより削る方が難しい。最小構成で始めて、必要に応じて足していく。
Sonnet 4.5で必要だったコンテキストリセットが、Opus 4.6では不要になりました。モデルの進化に合わせてハーネスの前提は常に更新される。固定された正解はありません。
Anthropic公式ブログは、こう締めくくっています。
「面白いハーネスの組み合わせ空間は、モデルが改善されても縮小しない。むしろ移動する」 つまり、ハーネス設計の重要性はモデルが進化しても消えない。むしろ、モデルが強くなるほど、より高度なハーネス設計が意味を持つということです。 プロンプトを磨く時代は終わりました。次の時代の名前は「ハーネス設計」。そしてこの技術は、プログラマーだけのものではありません。 AIに仕事を任せるすべての人に関係する話です。