ハーネスエンジニアリングの設計地図 3つのScaling次元から5層モデルへ
目次
こんにちは、ラクです。
最近、Harness Engineering という言葉を見かけることが増えました。
ただ、議論を追うほど違和感も強くなります。
同じ言葉で、別の話をしているからです。
たとえば、主要な海外事例だけを並べてもかなり違います。
| 会社 | 事例 | 何をやっているか | 成果 | いちばんの論点 |
|---|---|---|---|---|
| OpenAI | Codex / Symphony | repo 内知識、制約、レビュー省力化を整え、Codex が回り続ける環境を作る | 社内向け実製品を約 5 か月で 100 万行規模まで構築し、約 1,500 PR を運用 | 人間の注意力をどうスケールさせるか |
| Anthropic | Planner-Generator-Evaluator | Planner、Generator、Evaluator を分けて長時間自律を制御する | レトロゲームメーカーやブラウザ DAW を生成し、後者は約 4 時間、124.70 ドルで完成域まで到達 | 1 体の Agent をどう長く正しく走らせるか |
| Cursor | self-driving codebases | 数百 Agent を並列に動かし、階層的に収束させる | Rust 製ブラウザエンジンを 1 週間で 100 万行超まで拡張し、ピークで約 1000 commits/hour | 並列化をどう収束設計に変えるか |
| Stripe | Minions | 10 秒級 devbox、決定的ノード、MCP 群で unattended coding を支える | Minions という社内 unattended coding 基盤を運用し、週 1,300 件超の PR を担う | Agent が働く実行環境をどう標準化するか |
| Ramp | Ramp Sheets | monitor 駆動で異常検知、トリアージ、修正提案までを Agent に担わせる | monitor を 10 個から 1,000 個超へ増やし、初週だけで 40 件の実バグを数分以内に検出 | 監視と保守をどう自己保守型システムへ変えるか |
これを全部まとめて Harness Engineering と呼ぶと、議論が噛み合わなくなるのは自然です。
ある人は評価の話をしていて、ある人は runtime の話をしていて、別の人は組織運用の話をしています。
この状態で「Harness Engineering とは何か」を一言で固定しようとすると、すぐに苦しくなります。 しかも、「それって前からあったよね」という批判も半分は正しいです。 テストハーネスも、評価ハーネスも、開発環境設計も、もともと存在していました。
それでも私は、この言葉を雑に退けるのは早いと考えています。 新しいのは名前そのものではなく、AI がソフトウェア開発の中心的な実行主体になったときに露出した設計課題です。 その課題は、従来の開発改善よりも強く、速く、並列に表面化します。
私は、Harness Engineering を単一の手法名としてではなく、AI の局所的な能力を継続的な開発生産力へ変換するための環境設計だと見るのがよいと思っています。
この記事では、まず 3 つの Scaling 次元で混線をほどき、そのうえで 5 層の設計地図として捉え直します。
どこで詰まり、どこに投資すべきかを見分けるための整理です。
まず混線をほどく
今の Harness Engineering 論がややこしいのは、同じ言葉で別のスケール問題を話しているからです。
少なくとも、海外の主要事例は次の 3 つに分けた方が理解しやすいです。
| Scaling 次元 | 中心問題 | 代表事例 | 典型的な失敗 |
|---|---|---|---|
| 時間 | 1 体の Agent を長時間正しい方向で走らせられるか | Anthropic | 方向ドリフト、自己評価の甘さ |
| 空間 | 多数の Agent を同時に動かして意味のある吞吐量が出るか | Cursor | 競合、待機、中央ボトルネック |
| 交互作用 | 人間の注意力を増やさずに全体を steer できるか | OpenAI | 人が逐次介入し続ける |
たとえば Anthropic が解いているのは、長時間走る単一 Agent の信頼性です。 Planner、Generator、Evaluator を分け、実装した主体に完了判定をさせない構造を作っています。 ここでの核心は、長時間の自律実行では自己評価が歪みやすいという前提です。
一方 Cursor が苦しんでいたのは、何百体もの Agent を並列に走らせたときの収束です。 共有状態や中央 Integrator は一見きれいに見えますが、現実にはすぐ詰まります。 彼らが辿り着いたのは、階層化された Planner と独立した Worker による分業でした。
OpenAI が強く押し出していたのは、人間の介入をどう希少化するかです。 知識を repo 内に置き、制約を機械的に実行可能にし、レビューや保守の一部を Agent に肩代わりさせる。 ここでは「コードを書く」より「Agent が正しく働ける環境を設計する」ことが中心になります。
Stripe の Minions や Ramp の Ramp Sheets を見ると、この 3 分類だけでもまだ足りないと分かります。
彼らの強さは、長時間制御や並列収束だけでなく、運用や監視まで含めて Agent が働く系全体を設計しているところにあります。
つまり、各社は同じ言葉を使いながら、別のボトルネックを主戦場にしていたわけです。
それでも共通する土台がある
ただし、3 つの次元が完全に別物というわけでもありません。 海外事例を横断すると、共通原則が見えてきます。
- レバレッジポイントの移動 — モデルが直接コードを書く比率が上がるほど、人間が差を作る場所は実装そのものではなくなります。知識の配置、制約の形式、評価ループ、役割分離、マージ方針がそのまま生産性を決めます。
- 知識の可視性 — Agent に見えない知識は存在しないのと同じです。Slack、口頭、脳内前提ではなく、repo 内にあり差分で追える知識だけが開発基盤として機能します。
- 制約 > 指示 — 「ちゃんとやってください」は曖昧ですが、lint、型、依存制約、テストは曖昧ではありません。Agent 時代の規律は、実行可能な制約に変換される必要があります。
- 観測可能性 > 完璧主義 — Agent は人間より速く変更を生みます。その速度域では、毎回の完全性より、壊れ方の観測可能性と修復可能性の方が重要です。
この 4 点を前提に置くと、Harness Engineering は「AI にコードを書かせる小技集」ではなくなります。
モデルの局所的な能力を、継続可能で観測可能で修復可能な開発生産力へ変換する設計問題になります。
3つの次元だけでは実務に落ちない
ただ、3 つの Scaling 次元だけでは、実際にどこへ手を入れるべきかまでは見えてきません。
同じ「空間スケーリング」でも、Cursor の勝ち筋はオーケストレーションにありました。
一方で Stripe の Minions や Ramp の Ramp Sheets の強さは、むしろ運用基盤や監視設計まで含めた実装にあります。
なので実務では、もう一段細かい地図が必要です。 私は次の 5 層で捉えています。 3 つの次元は「どこで詰まっているか」の診断で、5 層は「どこに手を打つか」の処方です。
5層の設計地図で捉え直す
| 層 | 問い | 何を設計するか |
|---|---|---|
| Knowledge Layer | Agent は何を前提に判断するか | repo 内ドキュメント、局所ルール、構造化知識 |
| Runtime Layer | Agent はどこで安全かつ高速に働くか | sandbox、devbox、MCP、キャッシュ、観測接続 |
| Control Layer | 走行中の逸脱をどう補正するか | evaluator、monitor、retry、独立検証 |
| Orchestration Layer | 多数の作業をどう分担し収束させるか | planner 階層、job 化、handoff、merge 戦略 |
| Governance Layer | どこで止め、どこを人が見るか | merge policy、通知設計、エントロピー回収 |
| Scaling 次元 | 主に効く層 |
|---|---|
| 時間 | Runtime + Control |
| 空間 | Runtime + Orchestration |
| 交互作用 | Knowledge + Governance |
Knowledge Layer
大事なのは情報量の多さではありません。 参照可能性です。 仕様、設計判断、運用ルール、局所的な注意点が、必要な場所の近くに置かれていることが重要です。
この層が弱いと、Agent は毎回ゼロから推測します。 その結果、失敗は偶発的でなく構造的になります。 よくあるのは、知識が散らばったまま multi-agent 化してしまい、曖昧さだけを並列増幅するパターンです。
Runtime Layer
同じモデルでも、どこで働かせるかで性能は大きく変わります。 起動が遅い、依存解決が重い、ブラウザや DB に触れない、観測手段がない。 こうした環境では、賢いモデルを使っても実効性能は伸びません。
海外事例を見ると、強いチームほど Runtime を厚く作っています。 数秒で立ち上がる sandbox、実ブラウザ、社内 observability、MCP 経由の内部ツール接続などです。 これは派手な Agent 設計より地味に見えますが、実際にはかなり効きます。
Control Layer
長時間自律の最大の敵は、能力不足より自己評価の歪みです。 Agent は不具合を見つけても、自分で「このくらいなら大丈夫」と判断してしまいます。
Anthropic の事例が示したのは、ここを実装主体の善意に任せないことの重要性です。 Evaluator を独立させ、できれば実アプリを動かし、完了判定を外部化する。 この一手で、長時間実行の質はかなり変わります。
Ralph Loop のようなシンプルな反復も、この層の入門形だと言えます。 実装 Agent とレビュー Agent を分けるだけでも、自己甘評価はかなり減ります。
Orchestration Layer
ここで重要なのは、並列化そのものではなく収束設計です。 multi-agent にした瞬間に強くなるわけではありません。 責務境界が曖昧で、情報があちこちに流れ、中央の誰かが全てを統合する設計は、たいてい詰まります。
うまくいく構成は、誰がどのスコープを持つかが明確です。 情報の流れが必要最小限で、handoff が文章として残り、上位レイヤーが局所成果を統合できる。 オーケストレーションとは、賢い司令塔を置くことではなく、責務と流通のプロトコルを設計することです。
Governance Layer
見落とされがちですが、最終的な生産性はこの層で決まります。 どこで止めるか、どこから人が見るか、何を自動で流し、何を保留するか。 ここが曖昧だと、Agent は速く働いても組織全体は詰まります。
特に重要なのは、失敗をゼロにすることではなく、失敗を扱えるようにすることです。 自動再試行の上限、Issue 化の基準、自動マージ可能な範囲、定期的なエントロピー回収。 こうした運用ガバナンスは、派手さはないですが、実戦では最重要です。
海外事例をこの地図に置いてみる
この地図の上に主要事例を置くと、それぞれの主戦場が見えてきます。
OpenAI — Knowledge + Governance
repo 内知識、制約の機械化、レビュー省力化、継続的なエントロピー回収が中核にあります。 人間の注意力をどこへ使うか、という設計思想が一貫しています。 社内向けの実製品を約 5 か月で 100 万行規模、約 1,500 PR まで到達させたこと自体が、この設計思想の説得力になっています。
Anthropic — Control
Planner、Generator、Evaluator の分離は、長時間自律における自己評価の歪みを抑える設計です。 しかもモデルが進化したら、ハーネス部品を足すのではなく引くべきだという態度まで含めて示唆的でした。 レトロゲームメーカーやブラウザ DAW という目に見える成果物まで公開されていて、とくに後者を約 4 時間、124.70 ドルで完成域まで持っていった事例は、長時間自律の現実味を一段上げています。
Cursor — Orchestration
共有状態、中央 Integrator、平等な Agent 群がなぜ壊れるのかを、失敗込みで示してくれました。 階層化された Planner と独立 Worker の組み合わせは、並列化より収束設計が本質だと教えてくれます。 Rust 製ブラウザエンジンを 1 週間で 100 万行超まで拡張し、ピークで約 1000 commits/hour という数字は、問題設定そのものが人間チームの感覚と違うことをよく示しています。
Stripe — Runtime + Governance
魔法のような単一 Agent を作っているのではなく、既存の開発基盤を unattended coding 向けに組み替えている点が面白いです。
10 秒級の devbox を標準実行環境にし、LLM に任せるノードと決定的に実行するノードを blueprint で分離し、約 500 の MCP ツールを共有能力層として束ねる。
CI を無限に回さず、ローカルでできる検証を左に寄せたうえで 1〜2 回で切り上げる運用判断まで含めて設計されています。
Agent の賢さより、開発環境の標準化と deterministic な処理の切り分けの方がスループットに効くことを Minions は示しています。
週 1,300 件超の PR を担えるところまで来ているのは、その地味な基盤投資が効いているからです。
Ramp — Control + Governance
コーディング Agent そのものより、「監視し、異常を見つけ、ノイズを減らし、必要なら修正まで提案する」自己保守型の仕組みを作っている点が特徴的です。
Control— monitor を目として異常を検知し、triage し、必要なら sandbox で再現する品質補正Governance— その結果を誰にどう通知し、どの monitor を残し、どのノイズを捨てるかという運用設計
PR マージ時に差分から monitor を自動生成し、発火した monitor を起点に Agent が triage し、必要なら sandbox で再現して修正 PR まで持っていく。 ノイズが多ければ、通知する前に monitor 自体の閾値調整や削除まで行う方向に進んでいます。 monitor は数週間で 10 個から 1,000 個超へ増え、初週だけでも 40 件の実バグをユーザー報告前に数分以内で検出しています。 この事例は、Harness Engineering が「作る」だけでなく「観測し、保守し、壊れ方を制御する」段階まで拡張されていることを示しています。
つまり、各社は同じ Harness Engineering をやっているのではありません。
同じ地図の違う層を主戦場にしているのです。
「Harness Engineering は新しいのか」より先に、「どの層の話なのか」と聞けば、会話は噛み合います。
導入順を間違えると失敗する
この地図の実務的な価値は、導入順の判断にあります。
よくある失敗は、Knowledge Layer が整っていないのに Orchestration Layer に飛ぶことです。 仕様も制約も暗黙知のまま multi-agent 化しても、曖昧さを大量生産するだけです。
現実的な順番はこうです。
- Knowledge を整える
- Runtime を標準化する
- Control を独立させる
- 需要があれば Orchestration を広げる
- Governance を数値で詰める
順番が大事なのは、後段ほど前段の質を増幅するからです。 悪い知識を高速 runtime に載せても、速く間違うだけです。 甘い完了判定を数百 Agent に配れば、大規模に誤ります。
どこまでが Harness Engineering なのか
ここまで書くと、何でも Harness Engineering と呼べてしまいそうです。
実際、その危うさはあります。
私は、境界は「継続的な開発生産力へ変換する設計かどうか」にあると思っています。
単発のプロンプト工夫や一回きりの生成改善は含まれません。
逆に、知識、実行環境、評価、分業、運用を横断して、AI を継続的に働かせる条件を整えるなら、それは十分に Harness Engineering です。
ただし、全てのチームにフル装備が必要なわけではありません。 単発の社内ツール、小規模なコード生成、短命なプロトタイプなら、重いハーネスは過剰です。 Ralph Loop のような小さな反復、局所ルール、最低限のレビュー分離だけで十分なことも多いです。
重要なのは、「流行っているから全部載せする」ことではありません。 今の自分たちがどの層で詰まっているかを見極め、その層に投資することです。
まとめる
Harness Engineering は、たしかに言葉としては揺れています。
バズワードっぽく見えるのも無理はありません。
ですが、海外の実践を丁寧に読むと、そこで議論されている設計課題はかなり具体的です。
まずは、時間、空間、交互作用という 3 つの Scaling 次元で混線をほどく。
そのうえで、Knowledge、Runtime、Control、Orchestration、Governance の 5 層で設計対象を捉える。
この 2 段構えにすると、Harness Engineering は急に実務的な言葉になります。
私自身は、この領域を「AI 時代の開発組織論」だと見ています。 人間が直接コードを書く比率が下がるほど、知識をどこに置き、どの制約を機械化し、どこで品質を測り、どの粒度で仕事を流すかが、そのまま競争力になります。
だから問いは、「Harness Engineering は本当に新しいのか」だけではないはずです。 むしろ重要なのは、「自分たちは今、どの層の設計をまだ人力と暗黙知に頼っているのか」です。
そこが見えたとき、この言葉は流行語ではなく、かなり使える地図になります。