【プロンプトの時代は終わった】Anthropic・OpenAIが同時に発信した「ハーネス設計」という次の常識

見出し画像はAIで生成しました。
プロンプトは70,000文字超えの記事に掲載中。

プロンプトを磨いても成果が出ない理由

「もっと上手くプロンプトを書けば、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氏による解説記事が公開されています。

世界のトップ企業が同時に動いたテーマ。それがハーネス設計です。

【先着100名限定ウェビナー】
笑っちゃうほど簡単な Claude Code入門

連日満席のため、増枠しました！

noteメンバーシップに参加すると700本以上の記事が読み放題です。

書籍「AIでゼロからデザイン」好評発売中

お問い合わせ先（セミナー登壇・書籍化など）

「ハーネス」って何？

「ハーネス」とは、もともと馬具の「馬の力を制御する道具」のこと。AIの文脈では「モデルの能力を最大限に引き出すための設計・仕組み全体」を指します。

プロンプトを1行渡してAIに答えさせるだけでは、モデルの潜在能力のほんの一部しか使えていません。

ハーネス設計は、その周りに「仕組み」を作ることで、同じ1行から桁違いのアウトプットを引き出す技術です。

Anthropic公式ブログはこう表現しています。

プロンプトを上手く書くことと、AIが上手く動く仕組みを設計すること。この2つはまったく別の技術なんです。

Prompt → Context → Harness：3段階の進化

AI活用の技術は、たった4年で3つの時代を駆け抜けています。

第1世代：Prompt Engineering（2022〜2024年）

「1行の指示を磨く」時代。ChatGPTの登場とともに生まれ、「ステップバイステップで考えて」「あなたは専門家です」といったテクニックが広まりました。

第2世代：Context Engineering（2025年）

「AIが見る情報の全体を設計する」時代。プロンプトだけでなく、参照ファイル、過去の会話、ツールの使い方まで含めた「文脈全体」を最適化する発想です。

第3世代：Harness Engineering（2026年〜）

「AIが動く環境そのものを設計する」時代。プロンプトも文脈も、ハーネスの一部にすぎません。エージェントの分担、フィードバックループ、品質評価の仕組みまで含めた動作環境の全体設計が求められます。

この進化の何が重要かというと、AIの成果を決定づける要因が変わったということです。

実際、Anthropicの社内ベンチマーク（CORE）では、同じClaude Opus 4.5を使っても、Claude Codeのハーネスで動かすと正解率78%、別のフレームワーク（Smolagents）で動かすと42%。

同じモデルなのに、ハーネスの違いだけでダブルスコアの差が出ています。

なぜAIは「途中で崩壊」するのか

ハーネス設計が必要になった背景には、AIエージェントの2つの構造的な弱点があります。

コンテキスト不安（Context Anxiety）

AIには「コンテキストウィンドウ」という、一度に覚えられる情報量の上限があります。この上限に近づくと、モデルが「もうそろそろ終わらせよう」と自ら判断して、作業を早まって切り上げてしまう現象が起きます。

具体的にはこうなります。

• 長時間タスクで後半の機能が雑になる、または省略される

• 「完成しました」と言うのに実は未完成

• 終盤になるほど一貫性が崩れていく

Claude Code を日常的に使っている方なら「あるある」と感じるのではないでしょうか。私も何度も経験しています。

自己評価バイアス（Self-Evaluation Bias）

もう1つの問題は、AIに「自分が作ったものを評価して」と頼むと、ほぼ必ず高く評価するということ。明らかに低品質でも「良い出来だ」と答えます。

Anthropic公式ブログの表現を借りれば：

これは人間の認知バイアスと同じ構造です。

自分が書いたレポートの問題点に自分では気づきにくいのと同じで、作る役と評価する役を同じAIに任せてはいけないんです。

解決策：3エージェント構成

Anthropicが提案したハーネス設計の核心は、GANの発想をソフトウェア開発に応用した3エージェント構成です。

GAN（敵対的生成ネットワーク）とは、「生成器」と「識別器」を対立させて品質を高める機械学習の手法。

この発想を、AIによるアプリ開発に持ち込みました。

Planner（プランナー）— 設計だけに集中

1〜4文のプロンプトを、詳細な製品仕様書に自動展開します。AI機能の組み込みポイントも設計。「何を作るか」に集中し、実装の細部には踏み込みません。

Generator（ジェネレーター）— 実装だけに集中

仕様書に基づき、機能を1つずつ実装します。React / Vite / FastAPI / SQLiteなどのスタック。各機能を完了するたびにEvaluatorへ引き渡します。

Evaluator（エバリュエーター）— 評価だけに集中

Playwright MCPで実際にアプリを操作してバグを検出。品質スコアが閾値を下回ったら、具体的な修正指示とともにGeneratorに差し戻します。

ここが最大のポイントです。

作る役と評価する役を分離することで、自己評価バイアスを構造的に排除しています。人間の組織で言えば「開発チーム」と「QAチーム」を分けるのと同じ発想です。

「完成」を先に定義する — スプリントコントラクト

3エージェント構成で特に重要なのが「スプリントコントラクト」という概念です。

コードを書く前に、GeneratorとEvaluatorが「完成の定義」を事前に合意します。

例えば「矩形塗りつぶしツール」を実装するスプリントなら：

• ドラッグで範囲が正確に塗りつぶされる

• 開始点と終了点だけでなく中間も塗られる

• 取り消し（Undo）が機能する

この27項目のテスト基準を先に決めてから、Generatorがコードを書き始めます。

何を作るかを先に合意する → 手戻りを最小化する。シンプルですが、これがないと「完成したと思ったら違った」の無限ループに入ります。

実験結果：同じ1行で何が起きたか

Anthropicは、同じプロンプト「2Dレトロゲームメーカーを作成せよ」で、ソロエージェントと3エージェントハーネスを比較しました。

ソロエージェント（ハーネスなし）

• 実行時間：20分

• コスト：$9

• 機能数：基本UIのみ

• ゲームプレイ：動作しない

• AI統合：なし

3エージェントハーネス

• 実行時間：6時間

• コスト：$200（約20倍）

• 機能数：16機能 / 10スプリント

• ゲームプレイ：完全動作

• AI統合：Claude組み込み済み

コストは20倍。しかしソロでは「中核機能がそもそも動かない」という致命的な欠陥がありました。品質の差は比較になりません。

Evaluatorが実際に検出したバグの例も興味深いです。

• 矩形塗りつぶしツール：
  ドラッグの開始点と終了点にしかタイルが置かれず、fillRectangle関数は存在するのにmouseUpで呼ばれていなかった

• APIルーティング：
  PUT /frames/reorder ルートが /{frame_id} より後に定義されていたため、FastAPIが 'reorder' を整数のframe_idとして解析し、422エラーを返していた

どちらもGeneratorが「実装した」と思い込んでいたバグです。

Evaluatorが実際にアプリを操作しなければ発見できなかった。自己評価バイアスの排除が機能している証拠です。

Opus 4.6で何が変わったか — V2ハーネスへの進化

Anthropicの最新モデルOpus 4.6は、「より慎重に計画し、より長くエージェントタスクを持続し、自分のミスを発見するデバッグスキルが向上した」とリリースブログで記されています。

この改善により、V2ハーネスではスプリント構造を廃止。コンテキストリセットも不要になり、2時間超の連続コーディングが可能になりました。

実際にV2ハーネスで検証されたのは、ブラウザDAW（音楽制作ソフト）の自律生成。

Web Audio APIを使ったブラウザDAWを、AIエージェントがテンポ設定→メロディ生成→ドラムトラック→ミキサー調整→リバーブ追加まで、プロンプトだけで全自動実行。合計3時間50分、$124.70。

モデルが進化すれば、ハーネスの設計も進化する。これは終わりのないゲームです。

今日から始められる5つの原則

ハーネス設計を自分の仕事に取り入れるための原則を、Anthropic公式ブログから抽出します。

1. GeneratorとEvaluatorを分離する

自己評価バイアスは構造で解決します。作る役と評価する役を同じエージェントに担わせない。Claude Codeなら、メインの作業セッションとは別にレビュー用のセッションを立てるだけでも効果があります。

2.「何を作るか」を先に合意する

スプリントコントラクトの考え方です。完成の定義を事前に確定し、曖昧なまま実装を始めない。CLAUDE.mdに「このタスクの完了条件」を書いてから作業を始めるだけで、手戻りは激減します。

3. 主観をルーブリック化する

「良いか悪いか」ではなく「この基準を満たしているか」に変換します。評価軸には必ず重みをつけること。Anthropicは Design Quality と Originality を重要度「高」、Craft と Functionality を「標準」にしています。すべての評価軸を均等に扱わないことが重要です。

4. ハーネスはできるだけシンプルに保つ

Anthropicの設計哲学は「必要になったときだけ複雑化する」。部品を増やすより削る方が難しい。最小構成で始めて、必要に応じて足していく。

5. 新モデルが出たらハーネスを見直す

Sonnet 4.5で必要だったコンテキストリセットが、Opus 4.6では不要になりました。モデルの進化に合わせてハーネスの前提は常に更新される。固定された正解はありません。

プロンプトの先にある世界

Anthropic公式ブログは、こう締めくくっています。

つまり、ハーネス設計の重要性はモデルが進化しても消えない。むしろ、モデルが強くなるほど、より高度なハーネス設計が意味を持つということです。

プロンプトを磨く時代は終わりました。次の時代の名前は「ハーネス設計」。そしてこの技術は、プログラマーだけのものではありません。

AIに仕事を任せるすべての人に関係する話です。

関連記事

• 【指示を11回書いても守らない】Claude Codeが言うことを聞かない原因は「記憶の置き場所」だった — ハーネス設計の出発点であるCLAUDE.mdの設計

• 【Claude Code完全入門】買ったばかりのPCから、仕事を自動化するまで — まだClaude Codeを触ったことがない方はこちらから

• 【玄人向け】Claude Code究極活用ガイド〜効率化の極致へ〜 — ハーネス設計に必要な中上級テクニック

• AIエージェントを指揮する「コンダクター思考」〜「使う」のではなく「配属」せよ〜 — 3エージェント構成の前に必要な思考法

• 「社員1人にAIエージェント100体」Jensen Huangが語った「意図をデザインする」という新しい仕事 — ハーネス設計が経営に与えるインパクト

【先着100名限定ウェビナー】
笑っちゃうほど簡単な Claude Code入門

連日満席のため、増枠しました！

【 もう導入は済んだ方はこちら 】

もうパワポには絶対に戻れない
〜Claude Codeによる非常識なスライド制作〜

無料申し込みはこちら

noteメンバーシップに参加すると700本以上の記事が読み放題です。

書籍「AIでゼロからデザイン」好評発売中

NewsPicksで記事・サムネイル・グラフ・広告生成フローを解説しました。

過去の登壇実績はこちら

デザイン添削・キャリア相談（MENTA）

法人向けAI研修のご相談

お問い合わせ先（セミナー登壇・書籍化など）