目次
おはようございます。
今日は「ハーネスエンジニアリング」と「ループエンジニアリング」をリサーチしました。
TL;DR
- ハーネスエンジニアリング: 「エージェントが走る環境」を設計する規律。2026年2月のHashimoto氏ブログ発、6日後のOpenAI公式記事で定着しました。
- ループエンジニアリング: 「エージェントに指示する自分自身」を置き換える一段上の設計論。Claude Code作者Cherny氏の発言拡散を受け、Osmani氏(Google)が6月7日に命名しました。
- OpenAIは人手ゼロ行で約100万行を5か月で構築したと報告。反論も根強いものの「機械的に検証する仕組みづくり」は残ります。
概要|ハーネスエンジニアリングとは?
用語の定義
ハーネス(harness) はAIエージェントの「モデル本体以外のすべて」——Osmani氏いわく「モデルそのものではないすべてのコード・設定・実行ロジック」。ハーネスエンジニアリングはこの環境側を設計する規律です。ループエンジニアリングはその一段上で、「エージェントにプロンプトを打つ自分自身を置き換え、代わりにそれをやるシステムを設計すること」(同氏)です。
構成要素の柱
- 環境と権限: ツール・サンドボックス・コード構造
- フィードバック機構: linter・テスト・可観測性による自己検証
- 知識の蓄積: 失敗をAGENTS.md等に書き戻しテストケース化
- ループの自動化: 定時実行・サブエージェント等「指示する仕組み」の設計
変遷|プロンプト→コンテキスト→ハーネスの系譜
系譜はプロンプトエンジニアリング(2023年・Karpathy氏「最もホットな新しいプログラミング言語は英語だ」)→コンテキストエンジニアリング(2025年6月・Shopify CEOのLütke氏「すべてのコンテキストを与える技芸」)→ハーネスへ。2024年12月のAnthropicはエージェントを「環境フィードバックに基づきループでツールを使うLLM」と定義済みで、Cherny氏も当時Claude Codeを「可能な限り薄いラッパー」「秘伝のタレは全部モデルの中」と評していました。
「ハーネスエンジニアリング」の登場(2026年2月〜)
「agent harness」はevals(モデル評価)界隈の一般名詞。「engineering」を付けた確認できた最古の明示的用例が2026年2月5日のMitchell Hashimoto氏(Ghostty作者・HashiCorp共同創業者)のブログです。
"I've grown to calling this 'harness engineering.' It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
(私はこれを「ハーネスエンジニアリング」と呼ぶようになった。エージェントのミスを見つけるたびに、二度と起きないよう時間をかけて解決策を設計する考え方だ)
同氏は考案を主張しておらず、同時多発的な言語化のようです。
- 2026-02-11: OpenAI「Harness engineering」公開(初の大手ラボ公式記事)
- 03-10: LangChainのTrivedy氏「モデルでないなら、あなたはハーネスだ」
- 04-02: Böckeler氏「コンテキストエンジニアリングの一形態」と整理
「ループエンジニアリング」の誕生(2026年6月)
6月2日、WorkOSがCherny氏のインタビューまとめを公開。「Acquired Unplugged」(WorkOS主催)での発言として、次の逐語がクリップ書き起こし経由でXに急拡散しました(記事はパラフレーズのみ・動画原典は未照合)。
"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
(もうClaudeにプロンプトを打っていない。Claudeにプロンプトを打ち、何をすべきか考えるループたちが走っている。私の仕事はループを書くことだ)
Steinberger氏(OpenClaw作者)の「プロンプトを打つループを設計すべきだ」という投稿も拡散を加速し、Osmani氏が6月7日に「Loop Engineering」と命名。翌8日には批判記事(The Deep Feed)も登場しました。
実践の現場
- OpenAI: 3→7人・5か月・人手ゼロ行で約100万行・約1,500 PR(1人1日3.5 PR。OpenAI記事より)。ルールはlinterと構造テストで強制。
- Cherny: 数百のエージェントがGitHub issuesやSlackを読んで次の作業を決める常駐ループを運用(WorkOS記事より)。
- Osmani: 定時実行/Git worktree/Skills/Plugins・MCP/起草と検証を分けるサブエージェントの5点。
Stripeはpre-pushフックで「フィードバックの前倒し」を実践(lintエラーに修正指示を埋め込む工夫はBöckeler氏の一般原則)。Hashimoto氏はAGENTS.md更新で再発を防ぎ、AnthropicのAgent SDKは検証を3分類(ルール/ビジュアル/LLMジャッジ)しています。
考察|用語は廃れても「検証の設計」は残る
本質は「エージェントの仕事を、人間が張り付かなくても検証・修正できる構造を作ること」です。
なぜ重要か
- ボトルネックの移動: Osmani氏の「そこそこのモデル+優れたハーネスは、優れたモデル+ダメなハーネスに勝る」が端的です。
- 生産性の実例: 100万行実験が桁違いの生産性を示しました。
- スキルの再定義: 重心は「コードを書く」から「間違えにくい構造を書く」へ。
留保・リスク
- 「ハーネスは消える」派: Noam Brown氏(OpenAI)は「いずれ置き換えられるだけ」と述べたとされ、METRやScale AIはハーネス差を小さく評価。Manusも「より良いコンテキストの形を見つけるたびに」4回作り直したと語ります。
- 過剰設計と陳腐化: 過剰なハーネスはモデル更新で負債化しえます(Osmani氏の指摘)。The Deep Feedも「この言葉は秋には時代遅れになるが、検証という機能はそうならない」と評します。
個人的な見解
象徴的なのはCherny氏の変化です。「秘伝のタレは全部モデルの中」と言っていた本人が、1年後に「私の仕事はループを書くことだ」と言っている。これが何よりの状況証拠です。
まずは (a) 自分で検証できるテストやlintの整備、(b) AGENTS.md等への書き戻し、の2つで十分です。ウォッチポイントは、(1) 次のモデル世代でどの部品が不要になるか、(2) 4月のAI Engineer Europeで早くも専門トラックが立ちましたが、職能としての定着が他のカンファレンスや求人に広がるか。要は、名前は秋に古びても「間違いを構造で直す」習慣は標準になるはず。ここがポイントです。
