システム解体 Harness Engineering 5つの産物、3つの学派（OpenAI / Anthropic / ThoughtWorks）、5つの普遍原則、そしてなぜ「Harnessの衰退」があなたに6ヶ月ごとに半分の設計を削ることを強いるのか。この記事は@sairahul1著のX記事をもとに、動區が整理・編集したものです。 （前提：Harness Engineering（AI駆動エンジニアリング入門編：OpenAI最新プログラミング標準、Lv.1を簡単に達成する方法）） （背景補足：YC CEOが語るAIの秘訣：未来は情報複利システムを構築できる人のもの）
この記事の目次
Toggle
2026年2月、OpenAIの小規模チームが100万行の生産レベルのプログラムコードを出した。
彼らの手書きコードは一行もない。
AIエージェントが書いた。
人間が設計したのは、そのエージェントを信頼できるシステム。
このシステムには今、名前がついた——Harness Engineering。
数週間以内に、Anthropicが3つの関連論文を発表。ThoughtWorksはそれをフレームワークに整理。Hugging FaceのPhilipp Schmidはこれを「2026年最も重要な学問分野」と直接呼んだ。
90日以内に、新しいエンジニアリング学問が形成された。そしてAIインフラチーム以外はほとんど理解できていない。
この文章は、それをわかりやすく解説するもの。無駄話や学術用語はなく、実際に使うための心のモデルだけを提供。
ThoughtWorksが示す最もシンプルな定義：
Agent = Model + Harness
Harnessはモデル以外のすべて。
Harnessを剥がすと→コードベース内で適当に推測する原始的な言語モデル。
正しいHarnessを付けると→生産レベルのコードを生み出せるシステム。
この名前は馬具から来ている。Harnessは韁繩、馬鞍、馬銜——強力だが予測しづらい動物を有用な方向に導く装備。
馬を賢くするのではなく、力を有効に使う装備を設計すること。
Philipp Schmidが示す最良の技術比喩は：それをコンピュータと考えること。
| 役割 | | --- | | Model | | CPU（原始計算能力） | | Context window | | RAM（限られた揮発性作業記憶） | | Harness | | OS（CPUが何を見るか、いつ見るかを管理） | | Agent | | 上に動くアプリ |
あなたのモデルは強力だ。しかし、記憶やタスクスケジューリング、ルール実行を管理するOSがなければ——それはただのシリコン片。
多くの人は「OSなし」でアプリを動かしている。だから彼らのエージェントは生産ラインですぐ壊れる。
LangChainは同じモデルを使い、Terminal Bench 2.0で2回測定した。
| Harness | | --- | | スコア | | --- | --- | | 旧 harness | 52.8% | | 新 harness | 66.5% |
同じモデル。異なるharness。差は13.7ポイント。
Vercelは逆に——エージェントのツール80%を削減。結果？より良くなる、むしろ。
2026年の最も不快な真実：
もし2025年がAIエージェントが自分でコードを書けることを証明した年なら、2026年は「環境」の方が「モデル」より重要だと気づく年。
最も汎用的なharness産物。
コードベースのあちこちに散らばるmarkdownファイル。エージェントはセッション開始時にこれを読む——新しいエンジニアのオンボーディング資料のように。
何が書いてある？
OpenAIはこれをAGENT.mdと呼ぶ。AnthropicはCLAUDE.md。Cursorは**.cursorrules**。
異なる名前だが、原則は同じ。主要なモジュールごとに1つ。プロジェクトの進行に合わせて更新。
これがないと：エージェントは毎回セッションを盲目的に開始。あると：情報を持ってセッションを始められる。
エージェントが複数セッションにまたがりアプリ全体を構築するとき、各セッションのcontext windowは空になる。どうやって完了済みを知る？
JSONファイル。
各エントリには書く：
エージェントは最初にこれを読む——最優先のFailを選び→実装→Passにマーク→コミット→繰り返し。
Anthropicは気づいた：エージェントはJSONを書き換えるリスクがMarkdownより低い。
細かい違いだが、6時間自主運用のシナリオでは非常に重要。
毎回同じ方法でセッションを開始。毎回。
Anthropicの7ステップ起動手順：
これがないと：エージェントは最初の20分間、既存状態を理解するのに費やし、毎回車輪の再発明。あると：情報を持ってすぐに作業開始。
コードを書き始める前に——2つのエージェントが事前に交渉。
Generatorエージェントの提案：
Evaluatorエージェントの審査：
両者が合意して初めて実装開始。
これは設計レビューだ。ただし、両者ともAI。
同じラウンドで計画と実行を同時に行うエージェントは信頼性が低い。この「計画」——AIであっても——の段階をきちんと分離することで、出力の品質が大きく向上。
コードを書く前に、harnessはまず実際のコードベースを分析。
接地されたインパクトマップを作成：
そして実装開始。
当然のことに思えるが、多くのチームはこのステップを飛ばす。
エージェントはファイル構造を推測し、存在しないAPIを発明し、コードベースと合わないものを作る。
接地されたコンテキストを先に持つことで、出力の品質が格段に向上。
OpenAIのCodexチームには馬鹿げた問題があった。
100万行の生産コード、手書きゼロ。
その規模では、逐行コードレビューは不可能。だから彼らはやらない。
代わりに——環境を徹底的に設計し、エージェントが最初から「レビュー可能な出力」を出すようにした。
哲学：環境を設計し、そこにエージェントを放り込む。
Sora Androidアプリ。4人のエンジニア。28日。Playストア第1位。99.9%クラッシュフリー。
Codexは週に70%以上のPRを処理。
Anthropicが直面したのは別の問題。
エージェントが自分の出力を評価するとき、自信満々に自分の作品を褒める——人間の観察者から見れば明らかに平凡なのに。
**自己評価はダメ。**エージェントは学生と教師の両方で、自分に満点をつける。
| エージェント | | --- | | Planner | | 2文のプロンプトを完全な製品仕様に変換 | | Generator | | 1スプリントごとに実装 | | Evaluator | | ブラウザ自動化テスト、実使用者の操作のように振る舞う |
洞察：独立した評価エージェントを厳しくさせる方が、自己作品に厳しいGeneratorよりもはるかに容易。
| 設定 | | --- | | コスト | | 時間 | | 結果 | | --- | --- | --- | --- | | 単一エージェント（harnessなし） | $9 | 20分 | 壊れたアプリ | | 完全harness（Opus 4.5） | $200 | 6時間 | 動作するソフト＋洗練されたUI |
ThoughtWorksは異なる角度からアプローチ——彼らは製品を作るのではなく、50以上のエンジニアリングチームが同じ場所で失敗しているのを観察。
軸1：いつ動作するか？
軸2：どう動作するか？
| | | --- | | Feedforward（指示） | | Feedback（感知） | | --- | --- | --- | | 計算的 | | 型システム、リンター、アーキ規則 | | テストスイート、カバレッジ、突然変異テスト | | 推論的 | | 仕様書、制約記述 | | LLMコードレビュアー、行動検証器 |
Feedforwardとfeedbackはどちらか一方だけでは不十分。両方必要。
異なるチームでも同じ発見：
エージェントに「世界の現状」を接地させ、何をすべきかを抽象的に伝えるよりも、常に勝る。
実ファイルの状態に接地→コードベースに適合させる。曖昧な説明から出発→幻想的なルートやAPIの発明。
エージェントがタイピングする前に、まず自分の位置を知ること。
どの陣営も気づいている：計画と実行を同一ラウンドで行うと信頼性が低い。
計画は人間がやる必要はないが、分離されたステップであり、審査を通過したものだけが実行されるべき。
3つの学派が同じ原則に対して異なるアプローチ：
| 学派 | | --- | | フィードバックの出所 | | --- | --- | | OpenAI | | 自動化テスト＋CI | | Anthropic | | 別のLLM | | ThoughtWorks | | 両者を併用 |
彼らの違いは「誰がフィードバックを提供するか」。しかし、「フィードバックが必要か」には違いはない。
フィードバックなしのharnessは、ただのpromptにいくつかのステップを付け加えただけ。
一度に多くのエージェントを動かそうとすると：
Anthropicのルーチン：進捗を読む→1つの特徴を選ぶ→実装→コミット→繰り返し。
「漸進主義を徹底する」ことが成功するharnessの共通点。
誰もエージェントのために別途知識ベースを維持しない。リポジトリが唯一の真実。
もし慣例や制約、アーキ決定がコードベースにない場合→エージェントはそれを知ることができない。
AnthropicはOpus 4.5から4.6に上げたとき——スプリントの分解（必須だったもの）が重荷に変わった。
モデルの計画能力が向上し、その部分が不要になった。
3月にまだ重荷だったharnessコンポーネントは、4月にはオーバーヘッドに。
そしてOpus 4.7のリリース——モデルが自分の出力を検証し始めたことで、Evaluatorの役割も縮小。
Harness内の各コンポーネントは、「モデルができないこと」の仮定を含む。モデルが進歩すると、その仮定は陳腐化し、コンポーネントはオーバーヘッドに変わる。
| モデルバージョン | | --- | Harnessの状態 | | --- | --- | | Opus 4.5 | スプリント分解＋各スプリント評価 | | Opus 4.6 | スプリント分解なし＋単一評価（コスト38%削減） | | Opus 4.7 | モデル自己検証→評価者の役割縮小 |
Philipp Schmidの提案：「Build to delete.」
各harnessコンポーネントは、最初から取り除きやすいように設計。
定期的に各コンポーネントをテスト——それを切り離し、出力品質に差が出るか確認。差がなければ削除。
| チーム | | --- | | 6ヶ月以内のリファクタリング | | --- | --- | | Manus | harnessを5回リファクタリング | | LangChain | 1年以内に3回再構築 | | Vercel | 80%のツールを削減→パフォーマンス向上 |
これらは悪い設計の兆候ではなく、「急速に進化するモデルに合わせて構築する自然な結果」。
死んだharnessコンポーネントは、毎回トークンを消費し、品質に貢献せず、ただの浪費。
AnthropicのA/Bテストの正直な数字：
| 設定 | | --- | コスト | 時間 | 結果 | | --- | --- | --- | --- | | 単一エージェント（harnessなし） | $9 | 20分 | UIは動くがコアは壊れる | | 完全harness（Opus 4.5） | $200 | 6時間 | 動作するソフト＋洗練されたUI、正確な物理モデル |
22倍のコスト——本当に動くプロダクトに近い、ただのデモではない。
価値はあるか？壊れたリリースがあなたのチームに与える代償次第。
Harnessとモデルの組み合わせは進化する。
$200のharnessは、モデルのバージョンアップで$124に下がる。
| 傾向線 | | --- | | より良いモデル＝よりシンプルなharness＝より安く一回動かせる＝より速い出力 |
2026年に勝つエンジニアは、最良のコードを書く人ではない。 最良の「制約」を設計できる人。 そして、その制約が儲からなくなった瞬間に、それらを捨てる勇気を持つ。
2026年に勝つエンジニアは、最良のコードを書く人ではない。
最良の「制約」を設計できる人。
そして、その制約が儲からなくなった瞬間に、それらを捨てる勇気を持つ。
2026年に勝つエンジニアは、最良のコードを書く人ではない。最良の「制約」を設計できる人——そして、その制約が儲からなくなった瞬間に、それらを捨てる勇気を持つ。
6.6M 人気度
2.88M 人気度
56.77K 人気度
1.82M 人気度
854K 人気度
なぜあなたはハーネスエンジニアリングを学ぶ必要があるのか？ 5つの成果物、3つの学派、5つの普遍的原則を徹底解説
システム解体 Harness Engineering 5つの産物、3つの学派（OpenAI / Anthropic / ThoughtWorks）、5つの普遍原則、そしてなぜ「Harnessの衰退」があなたに6ヶ月ごとに半分の設計を削ることを強いるのか。この記事は@sairahul1著のX記事をもとに、動區が整理・編集したものです。
（前提：Harness Engineering（AI駆動エンジニアリング入門編：OpenAI最新プログラミング標準、Lv.1を簡単に達成する方法））
（背景補足：YC CEOが語るAIの秘訣：未来は情報複利システムを構築できる人のもの）
この記事の目次
Toggle
2026年2月、OpenAIの小規模チームが100万行の生産レベルのプログラムコードを出した。
彼らの手書きコードは一行もない。
AIエージェントが書いた。
人間が設計したのは、そのエージェントを信頼できるシステム。
このシステムには今、名前がついた——Harness Engineering。
数週間以内に、Anthropicが3つの関連論文を発表。ThoughtWorksはそれをフレームワークに整理。Hugging FaceのPhilipp Schmidはこれを「2026年最も重要な学問分野」と直接呼んだ。
90日以内に、新しいエンジニアリング学問が形成された。そしてAIインフラチーム以外はほとんど理解できていない。
この文章は、それをわかりやすく解説するもの。無駄話や学術用語はなく、実際に使うための心のモデルだけを提供。
1. Harnessの定義
ThoughtWorksが示す最もシンプルな定義：
Harnessはモデル以外のすべて。
Harnessを剥がすと→コードベース内で適当に推測する原始的な言語モデル。
正しいHarnessを付けると→生産レベルのコードを生み出せるシステム。
この名前は馬具から来ている。Harnessは韁繩、馬鞍、馬銜——強力だが予測しづらい動物を有用な方向に導く装備。
馬を賢くするのではなく、力を有効に使う装備を設計すること。
2. OSの比喩
Philipp Schmidが示す最良の技術比喩は：それをコンピュータと考えること。
| 役割 | | --- | | Model | | CPU（原始計算能力） | | Context window | | RAM（限られた揮発性作業記憶） | | Harness | | OS（CPUが何を見るか、いつ見るかを管理） | | Agent | | 上に動くアプリ |
あなたのモデルは強力だ。しかし、記憶やタスクスケジューリング、ルール実行を管理するOSがなければ——それはただのシリコン片。
多くの人は「OSなし」でアプリを動かしている。だから彼らのエージェントは生産ラインですぐ壊れる。
3. 2026年に何が変わったのか
LangChainは同じモデルを使い、Terminal Bench 2.0で2回測定した。
| Harness | | --- | | スコア | | --- | --- | | 旧 harness | 52.8% | | 新 harness | 66.5% |
同じモデル。異なるharness。差は13.7ポイント。
Vercelは逆に——エージェントのツール80%を削減。結果？より良くなる、むしろ。
2026年の最も不快な真実：
もし2025年がAIエージェントが自分でコードを書けることを証明した年なら、2026年は「環境」の方が「モデル」より重要だと気づく年。
4. AGENT.md / CLAUDE.mdファイル
最も汎用的なharness産物。
コードベースのあちこちに散らばるmarkdownファイル。エージェントはセッション開始時にこれを読む——新しいエンジニアのオンボーディング資料のように。
何が書いてある？
OpenAIはこれをAGENT.mdと呼ぶ。AnthropicはCLAUDE.md。Cursorは**.cursorrules**。
異なる名前だが、原則は同じ。主要なモジュールごとに1つ。プロジェクトの進行に合わせて更新。
これがないと：エージェントは毎回セッションを盲目的に開始。あると：情報を持ってセッションを始められる。
5. JSON Feature Lists（進捗追跡ツール）
エージェントが複数セッションにまたがりアプリ全体を構築するとき、各セッションのcontext windowは空になる。どうやって完了済みを知る？
JSONファイル。
各エントリには書く：
エージェントは最初にこれを読む——最優先のFailを選び→実装→Passにマーク→コミット→繰り返し。
なぜMarkdownではなくJSONなのか？
Anthropicは気づいた：エージェントはJSONを書き換えるリスクがMarkdownより低い。
細かい違いだが、6時間自主運用のシナリオでは非常に重要。
6. セッション初期化のルーチン
毎回同じ方法でセッションを開始。毎回。
Anthropicの7ステップ起動手順：
これがないと：エージェントは最初の20分間、既存状態を理解するのに費やし、毎回車輪の再発明。あると：情報を持ってすぐに作業開始。
7. Sprint Contracts（スプリント契約）
コードを書き始める前に——2つのエージェントが事前に交渉。
Generatorエージェントの提案：
Evaluatorエージェントの審査：
両者が合意して初めて実装開始。
これは設計レビューだ。ただし、両者ともAI。
なぜ重要か
同じラウンドで計画と実行を同時に行うエージェントは信頼性が低い。この「計画」——AIであっても——の段階をきちんと分離することで、出力の品質が大きく向上。
8. 構造化タスクテンプレート
コードを書く前に、harnessはまず実際のコードベースを分析。
接地されたインパクトマップを作成：
そして実装開始。
当然のことに思えるが、多くのチームはこのステップを飛ばす。
エージェントはファイル構造を推測し、存在しないAPIを発明し、コードベースと合わないものを作る。
接地されたコンテキストを先に持つことで、出力の品質が格段に向上。
9. OpenAIの学派：環境優先
OpenAIのCodexチームには馬鹿げた問題があった。
その規模では、逐行コードレビューは不可能。だから彼らはやらない。
代わりに——環境を徹底的に設計し、エージェントが最初から「レビュー可能な出力」を出すようにした。
彼らのやり方
哲学：環境を設計し、そこにエージェントを放り込む。
証拠
Sora Androidアプリ。4人のエンジニア。28日。Playストア第1位。99.9%クラッシュフリー。
Codexは週に70%以上のPRを処理。
10. Anthropicの学派：「作る」と「審査」を分離
Anthropicが直面したのは別の問題。
エージェントが自分の出力を評価するとき、自信満々に自分の作品を褒める——人間の観察者から見れば明らかに平凡なのに。
**自己評価はダメ。**エージェントは学生と教師の両方で、自分に満点をつける。
彼らの解決策：3つの専任エージェント
| エージェント | | --- | | Planner | | 2文のプロンプトを完全な製品仕様に変換 | | Generator | | 1スプリントごとに実装 | | Evaluator | | ブラウザ自動化テスト、実使用者の操作のように振る舞う |
洞察：独立した評価エージェントを厳しくさせる方が、自己作品に厳しいGeneratorよりもはるかに容易。
結果（A/Bテスト）
| 設定 | | --- | | コスト | | 時間 | | 結果 | | --- | --- | --- | --- | | 単一エージェント（harnessなし） | $9 | 20分 | 壊れたアプリ | | 完全harness（Opus 4.5） | $200 | 6時間 | 動作するソフト＋洗練されたUI |
11. ThoughtWorksの学派：2×2フレームワーク
ThoughtWorksは異なる角度からアプローチ——彼らは製品を作るのではなく、50以上のエンジニアリングチームが同じ場所で失敗しているのを観察。
彼らの洞察：2軸で分類する各Harness制御
軸1：いつ動作するか？
軸2：どう動作するか？
2×2マトリクス
| | | --- | | Feedforward（指示） | | Feedback（感知） | | --- | --- | --- | | 計算的 | | 型システム、リンター、アーキ規則 | | テストスイート、カバレッジ、突然変異テスト | | 推論的 | | 仕様書、制約記述 | | LLMコードレビュアー、行動検証器 |
Feedforwardとfeedbackはどちらか一方だけでは不十分。両方必要。
12. 原則1：ContextはInstructionより勝る
異なるチームでも同じ発見：
実ファイルの状態に接地→コードベースに適合させる。曖昧な説明から出発→幻想的なルートやAPIの発明。
エージェントがタイピングする前に、まず自分の位置を知ること。
13. 原則2：計画と実行は分離せよ
どの陣営も気づいている：計画と実行を同一ラウンドで行うと信頼性が低い。
計画は人間がやる必要はないが、分離されたステップであり、審査を通過したものだけが実行されるべき。
14. 原則3：フィードバックループは妥協しない
3つの学派が同じ原則に対して異なるアプローチ：
| 学派 | | --- | | フィードバックの出所 | | --- | --- | | OpenAI | | 自動化テスト＋CI | | Anthropic | | 別のLLM | | ThoughtWorks | | 両者を併用 |
彼らの違いは「誰がフィードバックを提供するか」。しかし、「フィードバックが必要か」には違いはない。
15. 原則4：一度に一つだけ
一度に多くのエージェントを動かそうとすると：
Anthropicのルーチン：進捗を読む→1つの特徴を選ぶ→実装→コミット→繰り返し。
「漸進主義を徹底する」ことが成功するharnessの共通点。
16. 原則5：コードベース自体がドキュメント
誰もエージェントのために別途知識ベースを維持しない。リポジトリが唯一の真実。
もし慣例や制約、アーキ決定がコードベースにない場合→エージェントはそれを知ることができない。
実務的意味
17. Harnessの衰退（Harness Decay）は本当
AnthropicはOpus 4.5から4.6に上げたとき——スプリントの分解（必須だったもの）が重荷に変わった。
モデルの計画能力が向上し、その部分が不要になった。
3月にまだ重荷だったharnessコンポーネントは、4月にはオーバーヘッドに。
そしてOpus 4.7のリリース——モデルが自分の出力を検証し始めたことで、Evaluatorの役割も縮小。
これがHarnessの衰退
| モデルバージョン | | --- | Harnessの状態 | | --- | --- | | Opus 4.5 | スプリント分解＋各スプリント評価 | | Opus 4.6 | スプリント分解なし＋単一評価（コスト38%削減） | | Opus 4.7 | モデル自己検証→評価者の役割縮小 |
18. 削除を前提に設計（Build to Delete）
Philipp Schmidの提案：「Build to delete.」
各harnessコンポーネントは、最初から取り除きやすいように設計。
定期的に各コンポーネントをテスト——それを切り離し、出力品質に差が出るか確認。差がなければ削除。
| チーム | | --- | | 6ヶ月以内のリファクタリング | | --- | --- | | Manus | harnessを5回リファクタリング | | LangChain | 1年以内に3回再構築 | | Vercel | 80%のツールを削減→パフォーマンス向上 |
これらは悪い設計の兆候ではなく、「急速に進化するモデルに合わせて構築する自然な結果」。
19. コストの現実
AnthropicのA/Bテストの正直な数字：
| 設定 | | --- | コスト | 時間 | 結果 | | --- | --- | --- | --- | | 単一エージェント（harnessなし） | $9 | 20分 | UIは動くがコアは壊れる | | 完全harness（Opus 4.5） | $200 | 6時間 | 動作するソフト＋洗練されたUI、正確な物理モデル |
22倍のコスト——本当に動くプロダクトに近い、ただのデモではない。
価値はあるか？壊れたリリースがあなたのチームに与える代償次第。
しかしこれは誰も語らない部分
Harnessとモデルの組み合わせは進化する。
$200のharnessは、モデルのバージョンアップで$124に下がる。
| 傾向線 | | --- | | より良いモデル＝よりシンプルなharness＝より安く一回動かせる＝より速い出力 |
全文要約
harnessとは何か
5つのharness産物
3つの学派
5つの普遍原則
弔詭のポイント
2026年に勝つエンジニアは、最良のコードを書く人ではない。最良の「制約」を設計できる人——そして、その制約が儲からなくなった瞬間に、それらを捨てる勇気を持つ。