# Harness Engineeringとは — Agentが仕事を完了できる環境を設計する

> Harness Engineeringを、AgentへTool・Context・権限・状態・検証・Feedbackを与える実行環境の設計として整理します。

Canonical URL: https://labs.eastbraver.com/guides/harness-engineering
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: ai-agent, software-engineering, agentic-infra

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を働かせる外側の仕組み

### Agent Harnessの制御面

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を観測します。

*Agentの実行、検証、Policy、観測を閉じたloopとして構成するHarness*

[OpenAIのHarness Engineering](https://openai.com/index/harness-engineering/)は、Agentが理解できるRepository、機械的に強制されるArchitecture、Test、Tool、Observability、Feedback loopを整え、人間が意図と環境を設計する実践を報告しています。

[Anthropicの長時間Agent向けHarness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)は、初期設定を行う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](/guides/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](/guides/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](/guides/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](https://www.anthropic.com/engineering/harness-design-long-running-apps)は、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が改善したら削れるかを再評価する。仕組み自体が目的になる状態は避けたいです。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開