ハーネスエンジニアリングを2軸の座標で見直す

TL;DR

ハーネスエンジニアリングには「エージェントの行動範囲を広げる」方向と「不完全性を埋める」方向の二つがある、と感じていました。ただこの二分法は粗くて、もっと広い座標空間の一断面でしかないとわかってきました。Böckelerの guides ↔ sensors 軸と当初の二分法を直交させて4象限を作ると、左下の「Agency × Sensors」だけが構造的に薄いことが見えます。実行時のフィードバックで行動表面そのものを書き換える領域で、抽象が未成熟なまま放置されているところです。ハーネスを学習系にしたいなら、ここを経由するしかなさそうだ、という話を書きます。

二つの方向性が見えていた

最近ハーネスエンジニアリングという言葉をよく目にします。提唱されたのは2026年初頭で、Mitchell Hashimoto と OpenAI の Ryan Lopopolo がほぼ同時期に独立に投げた語だと整理されています。語彙としては結晶化の最中で、人によって含意が微妙にずれているのも面白いところです。

しばらく観察していて、自分の中ではこれが二つの方向に分かれていました。

一つは、エージェントの行動表面を広げるハーネス。Claude Code、Codex、OpenCodeあたりの系譜で、ブラウザ操作、Skills、サブエージェント、MCPサーバ接続、Bashアクセス。要するにエージェントが触れる世界を広げる方向です。派手で競争が激しく、新機能が出るたびに話題になります。

もう一つは、エージェントの不完全性を補うハーネス。rubricに基づく評価、レビュー観点とソースの厳密化、CIゲート、可観測性、再現性。こちらは銀の弾丸がなく、個別最適化要素が強くて、地味で取り組まれにくい。LLMOpsも結果としてこちらに踏み込めていないと思います。

二分法としてはとりあえずこれで動けていました。

ただ、二分法は粗かった

ちゃんと文献を読み直したら、自分の整理が粗いことに気づきました。

BöckelerがThoughtworks経由で書いたharness engineeringの記事では、Guides(実行前のステアリング)と Sensors(実行後の検知)を直交軸にした 2×2 が提示されています。さらに、それぞれを Computational(決定論的)と Inferential(LLM駆動)に細分する。規制対象としては Maintainability harness、Architecture fitness harness、Behavior harnessの三つを別軸で示しています。Behavior harnessが「the elephant in the room」と呼ばれていて、ここが最も未成熟だと整理されている。

別の論文ではCAR(Control / Agency / Runtime)という分解が提案されています。ハーネス層を Control(ステア)、Agency(行動可能空間)、Runtime(状態とリトライと回復)に三分し、HarnessCardという構造化された報告アーティファクトを併せて提案する立場です。

これを自分の二分法と並べてみると、当初の「拡張性 vs 不完全性補完」は要するに「Agency vs (Control + Sensors + Runtime)」の縮約でした。間違ってはいないけれど、解像度が低い。例えばSkillsを「拡張性側」に置いていましたが、Böckelerの枠組みではSkillsはGuides(知識の事前注入)です。サブエージェントもAgency拡張に見えて、実態は単一コンテキストが破綻するのを避けるための不完全性回避策だったりします。Agency拡張と制御強化は同じプリミティブで実装可能で、二分法は構造的に重なりを持っていた、ということになります。

軸を二つにする

整理し直すと、横軸に「Agency拡張 ↔ Control・検証」、縦軸に「事前(Guides) ↔ 事後(Sensors)」を取るとちょうどよくなります。両方とも実用上意味のある区分で、4象限すべてに具体的な構成要素が置けます。

左上、Agency × Guides。能力の事前付与。MCPサーバやツール定義、サブエージェント定義、Skills、ブラウザやBash接続、Agent SDKのtool layer。

右上、Control × Guides。方針や規約の事前付与。CLAUDE.md や AGENTS.md、コーディング規約、rubricや評価基準の仕様、型スキーマ、アーキテクチャ文書。

右下、Control × Sensors。結果の検証と観測。Linter、type checker、テストとCIゲート、LLM-as-judge、LangSmithやLangfuse、差分eval。

そして左下、Agency × Sensors。スクリーンショットの環流、ShellやREPL出力の観察、自己訂正ループ、リトライやエスカレーション。書き出してみると、項目数も少ないし、抽象も育っていないことがわかります。ここだけが薄い。

なぜ左下が薄いのか

設計者がうっかり忘れたわけではなくて、構造的に薄いのだと思っています。理由が少なくとも五つ重なっています。

一つめは、時間軸の非対称性。Agencyは本質的に設計時の概念(ツール、Skills、サブエージェントを事前に決める)、Sensorsは本質的に実行時の概念です。両者の交点は「実行中に行動表面が変動する」設計を要求します。これは「ハーネス = 固定された足場」という支配的なメンタルモデルを壊します。多くのエンジニアの認知地図に、この組み合わせがそもそも入っていない気がします。

二つめは、再現性と監査性との衝突。動的にAgencyを書き換えると非定常性が出ます。同じタスク、同じモデルでも、時点によって利用可能なツール集合が違う。トレースが安定せず、デバッグも監査も難しくなる。エンタープライズの保守的な要件と正面衝突します。

三つめは、「エージェントが既にやっているように見える」錯覚。ReActループでエージェントはツール結果を観察して次手を決めます。Agency × Sensorsの位置は「モデルの仕事」と見なされがちです。でもモデル内の perception-to-action と、ハーネス外側からの capability-modulation は別物だと思います。前者は単一エージェントの認知ループ、後者は環境側で能力境界そのものを書き換える層。外形が似ているから設計者の視野から漏れます。

四つめは、Hashimoto処方箋の慣性。「ミスを発見したら二度と起こらないようにハーネスを直す」という支配的な処方は、guide追加かsensor追加に帰着します。Agencyを動的に書き換える方向には向かいません。改善のエネルギーがguide / sensor象限に流れ、Agency側は静的なまま放置される。

五つめは、抽象の未成熟。LangGraph、Claude Agent SDK、Codexといった既存フレームワークは、ツールレジストリを静的なconfigとして扱います。「sensor発火 → ツールレジストリ書き換え → 次タスクで反映」のための標準フックがない。やろうとすると毎回スクラッチで、参入コストが高い。

埋めると何が起きるか

ここを埋めると、できることが変わってきます。

一つは、just-in-time capability provisioning。ツールを全部事前公開するとcontext bloatと意思決定混乱が起きます。MCPを大量接続すると性能が落ちる現象は経験的にも報告されています。状況に応じてツール集合を出し入れする、sensor駆動の選択的開示が、これを構造的に解決します。「ツールが多いほどいい」から「いま必要なツールだけ見える」へ、という方向です。

二つめは、failure-aware action surface。同じツールでN回失敗したら、ハーネスが別ツールや上位サブエージェントやdegraded modeに切り替える。エージェント版のcircuit breakerです。無限retry地獄が消えます。

三つめは、telemetry駆動のtool / skill進化。sensorがツール使用の失敗パターンと成功パターンを観測し、ハーネスがツール記述、Skillsの中身、サブエージェント定義そのものを更新する。これは「属人化しない継続的改善」の実装そのものだと思います。ハーネスが自分自身を観測データで更新する閉ループ。

四つめは、Behavior harnessの自動化への道。Böckelerが「elephant in the room」と呼んだ最難領域は、domain-specificだから手作業に陥ります。Agency × Sensorsのパターンは、実タスクで観測してcapability gapを抽出してaction surfaceを改修する循環を機械化する道を開きます。職人芸から系統的工学への橋渡しになるかもしれない、という期待があります。

五つめは、orientation tax削減。エージェントが環境を盲目的にgrepしまくる現象がよくあります。これに対して、彷徨いを検知するsensorがRepoMapperのような環境マッピングのサブエージェントを動的に注入する。事前に全部用意する代わりに、必要時に注入する設計です。

そして、業界全体でこの象限の実装パターンが未成熟であること自体が、踏み込む価値の根拠になります。

ここを開かないと閉じるもの

Agency × Sensorsを空白のままにしておくと、ハーネスの改善ループは「人間が観測 → 人間が guide / sensor を手書き更新」に必ず帰着します。属人化から抜ける経路がない。ハーネス自体が学習系になる道は、この象限を経由するしかないと思っています。ここを開かないと、最終的には「人間の手作業を自動化するツール」止まりで、ハーネスを学習系にする到達点は閉じたままです。

これは前回書いた「エンジニアの仕事は目的の翻訳業だ」という話とも繋がります。Agency × Sensorsが機能するハーネスでは、エンジニアの仕事は「個別のguideやsensorを書く」から「ハーネスの自己更新ルールを設計する」というメタレイヤに寄っていきます。翻訳装置そのものを設計する仕事、と言ってもいいかもしれません。

実装上の留保

非定常性の問題は、Agencyの更新をエピソード境界(タスク完了時)だけに許可する設計でだいぶ緩和できると思います。監査性は、各Agency変更をversioned eventとして記録して、トレースにactive surfaceのハッシュをタグする運用で確保できます。安全性は「拡張はallowlist内のみ、収縮は自由」という非対称ポリシーで担保。この三つを最初から組み込んでおけば、上で挙げた「再現性・監査性との衝突」は実用的にクリアできるはずです。

おわりに

二分法は二分法でとりあえず動けたけれど、座標を一段増やすと見えるものが変わりました。とくに左下の薄さは、自分の不注意ではなく構造的なものだと整理できたのが収穫でした。

ここから先、Agency × Sensorsを埋めるための具体的なプリミティブが何になるかは、自分でもまだはっきりしません。動的なツールレジストリAPIなのか、sensor → registry更新の宣言的言語なのか、HarnessCardのような監査アーティファクトと組み合わせた運用パターンなのか。ここは手を動かしながら考えるしかなさそうです。

参考:

• Birgitta Böckeler, "Harness engineering for coding agent users" (martinfowler.com, 2026)
• Ryan Lopopolo (OpenAI), "Harness engineering: leveraging Codex in an agent-first world" (2026)
• "Harness Engineering for Language Agents: The Harness Layer as Control, Agency, and Runtime" (Preprints, 2026年3月)

留保: Mitchell Hashimoto の harness engineering 提唱時期について、ソース間で2025年2月と2026年2月が混在しています。本稿の議論には影響しません。