Harness Engineeringは、AI Agentが仕事を進め、結果を検証し、失敗から回復できるように、モデルの外側にある実行環境を設計することです。
Agentへ高性能なModelを渡しても、仕様を読めない、Testを実行できない、Logを見られない環境では仕事を完了できません。
Promptだけを指す言葉ではありません。Tool、権限、Sandbox、Repository、Artifact、Test、Observability、Feedback loop、人間の承認まで含みます。
この用語は、2025年から2026年にかけてCoding Agentや長時間Agentの実践で広がっています。確立した標準仕様ではないため、このGuideでは共通して現れている設計要素を扱います。
HarnessはModelを働かせる外側の仕組み
HarnessはHuman intentとContextをAgentへ渡し、Tools、Sandbox、State、Artifactsを実行環境として結びます。TestsとEvaluatorsのFeedbackをAgentへ戻し、Policy、Approval、ObservabilityでTool利用を継続的に統制します。
- Human intentとContextやInstructionsをAgentへ渡します。
- AgentがTools、Sandbox、State、Artifactsを使って処理します。
- TestsとEvaluatorsが結果を検証し、FeedbackをAgentへ戻します。
- PolicyとApprovalがTool利用を制御し、ObservabilityがAgentとToolを観測します。
OpenAIのHarness Engineeringは、Agentが理解できるRepository、機械的に強制されるArchitecture、Test、Tool、Observability、Feedback loopを整え、人間が意図と環境を設計する実践を報告しています。
Anthropicの長時間Agent向けHarnessは、初期設定を行うAgent、進捗File、Git commit、Sessionをまたぐ引き継ぎを使い、長時間のSoftware taskを継続する方法を示しています。
Prompt、Context、Harness、Frameworkを分ける
| 用語 | 主な対象 |
|---|---|
| Prompt Engineering | Instruction、例、出力条件 |
| Context Engineering | 推論時に渡す情報の選択と維持 |
| Agent Framework | Agent loopやTool連携を実装するLibrary |
| Harness Engineering | Agentが作業・検証・回復できる環境全体 |
| Loop Engineering | Harness上で反復と停止を制御する設計 |
Frameworkを導入しても、対象業務の完了条件、権限、Test、Artifactは自動では決まりません。Harnessは製品と作業環境に合わせて設計します。
Agentから見える状態を増やす
人間には見えるがAgentには見えない情報は、Agentにとって存在しないのと同じです。
- Repository内の仕様とArchitecture rule
- 実行可能なBuild・Lint・Test command
- BrowserやAPIを操作するTool
- Log、Metric、Traceへの検索手段
- Databaseや外部Serviceの安全な検証環境
- 完了条件と受け入れTest
- 過去の判断と現在の進捗
ただし、見える情報を増やすことと、すべてをContextへ入れることは違います。Context Engineeringで、必要な情報をToolから取得できるようにします。
説明だけでなく制約を実行可能にする
「このLayerからDatabaseへ直接Accessしない」と文書へ書くだけでは、Agentも人間も違反できます。Dependency ruleをLintやArchitecture testにすると、違反時に同じFeedbackを返せます。
Harnessへ置く制約の例です。
- Formatter、Typecheck、Lint
- Unit / Integration / E2E Test
- Dependency directionの検査
- Schema boundaryのValidation
- Secret scanning
- SandboxとNetwork allowlist
- Permission policy
- Budgetと実行時間上限
制約は多いほどよいわけではありません。Modelが単独で安定してできることまで固定すると、Harnessが高コストになります。
ArtifactでSessionを越える
長時間作業を会話履歴だけで維持すると、Context WindowとCompactionに依存します。
- Goalと完了条件を記録したPlan
- 作業単位のTask list
- Git commitとDiff
- Test結果
- 未解決事項
- 次のAgentへのHandoff
ArtifactをVersion管理すると、新しいAgentや人間が途中状態を検証できます。モデルの内部状態を保存するのではなく、外から読める作業状態を残します。
GeneratorとEvaluatorを分ける
AnthropicのHarness Designは、Planner、Generator、Evaluatorを分け、実装前のContractと実行後の検証を使う構成を紹介しています。
生成したAgent自身の「できました」だけを完了判定にしません。Test、Browser操作、下流状態、別Evaluatorを使い、成果物を直接確認します。
HarnessはModel更新に合わせて削る
弱いModelを補うために作った細かな分割や誘導が、次のModelでは不要になる場合があります。古いScaffoldingが残ると、速度、費用、柔軟性を下げます。
Harnessの各要素がどの失敗を防いでいるかを記録し、Model更新時に一つずつ外して評価します。最も複雑な構成を維持するのではなく、品質を保てる最小構成を探します。
よくある誤解
Harnessは長いSystem Promptである
PromptはHarnessの一部です。実行環境、Tool、Artifact、Constraint、Evaluatorまで含みます。
Agent Frameworkを導入すればHarnessが完成する
Frameworkは実装部品です。対象Systemの権限、Test、観測、完了条件は別に設計します。
Agentへ多くのToolを渡すほど仕事が進む
選択肢と権限が広がり、Contextも増えます。必要なToolを狭い契約で渡します。
Harnessは一度作れば使い続けられる
Model、Tool、Repository、業務要件が変わります。各制約が現在も必要かを評価します。
EastBraver Labsの判断基準
EastBraver Labsでは、Harnessを「Agentが賢くなる仕組み」ではなく、Agentの作業を検証可能にする環境として扱います。
仕様、Tool、権限、Test、TraceをAgentから参照できる形にし、完了は成果物とOutcomeで判定します。文書で伝えたい好みと、機械的に止めるInvariantを分けます。
Harnessを増やすときは、どの失敗を防ぐのかを先に決めます。
Modelが改善したら削れるかを再評価する。仕組み自体が目的になる状態は避けたいです。