Harness Engineering
https://openai.com/ja-JP/index/harness-engineering/
https://nyosegawa.github.io/posts/harness-engineering-best-practices-2026/
Mitchell Hashimotoによる最初の定義を辿れば、Harness Engineeringとは人間によるAGENTS.mdの継続的改善と、Agentが自分の作業の正誤を自己検証するためのツール群を指していました。
@gyakuse
長すぎて読む気にならんmrsekut.icon
gpt-5.icon
Harness Engineering の核心は、リンター・テスト・Hooks・ADR などの決定論的な仕組みで品質を強制することです。
とくに重要なのは、速いフィードバックループを作ること、腐敗しやすい説明文書より実行可能なルールやテストを真実のソースにすること、そしてエージェントが失敗するたびにハーネスを追加して将来の全セッションに効かせることです
主な論点は次の通りです。
Harness Engineering とは、エージェントが自律的に正しいコードを出し続けるための仕組み全体を設計すること
リポジトリには腐敗する説明文書を溜めず、コード・テスト・リンター・ADR のような機械的に検証できるものを置くべき
品質管理は LLM ではなく、リンター・フォーマッター・型チェック・構造テスト・Hooks に任せるべき
AGENTS.md / CLAUDE.md は長い設計書ではなく、必要なルールや場所への短いポインタとして設計するべき
エージェントにはまず計画を立てさせ、承認後に実行させるほうが安定する
E2E テストによって、UI・API・CLI・モバイル・インフラ・AI/ML まで含めて「エージェントが自分で検証して直す」ループを閉じるべき
セッションをまたぐ状態は記憶に頼らず、Git ログや JSON などの構造化された記録で引き継ぐべき
Claude Code と Codex は特性が異なり、品質重視なら Claude Code、並列実行重視なら Codex、現実的にはハイブリッドが有力