■ 1. ハーネスエンジニアリングとは
- AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法
- 「harness」はモデル単体ではなく、入力、ツール呼び出し、状態管理、評価、記録を束ねてエージェントとして機能させる土台を指す
- エージェント主導の開発では、人間の主な仕事が「コードを書くこと」から「環境を設計し、意図を指定し、信頼できるフィードバックループを作ること」へ移行する
■ 2. ハーネスエンジニアリングが必要な背景
- コード生成速度の増大に伴う課題:
- OpenAIはエージェント主導で空のGitリポジトリから初期構成・CI設定・AGENTS.md・アプリケーション実装までを構築し、人間はプロンプト・環境設計・レビュー方針の設計に回った
- コードスループットが上がるにつれて、ボトルネックが human QA capacity に移行することが判明した
- AIが生成する差分量が増えるほど、確認待ち・差し戻し・手戻り・仕様の見落としが累積しやすくなる
- 組織能力の問題:
- DORAは、AI導入の成否はツール単体ではなく、内部データ・ワークフロー・評価の仕組みといった組織能力に左右されると整理している
- AIは「増幅器」であり、整った組織では強みを伸ばし、弱い組織では弱点を速く拡大する
- 内部の情報基盤が弱いままAIを導入すると、入力がぶれ、レビュー負荷が増える
■ 3. 関連概念との層構造
- プロンプトエンジニアリング・コンテキストエンジニアリング・ハーネスエンジニアリングは横並びではなく、prompt ⊂ context ⊂ harness の包摂関係にある
- 各レイヤーの定義:
- プロンプトエンジニアリング: 1回の推論で、どう指示を書くか（最も内側のレイヤー）
- コンテキストエンジニアリング: その推論に、何の情報を入れるか（AIに何を見せるかを設計する考え方）
- ハーネスエンジニアリング: 複数回の推論とツール利用を含む作業全体を、どう運転するか（最も広い概念）
- コンテキストエンジニアリングはハーネスエンジニアリングの重要部品だが、ハーネスそのものではない
- 「プロンプトを工夫しているのに成果が安定しない」場合、問題は書き方ではなく、渡している情報・評価ループ・引き継ぎ設計にある可能性がある
■ 4. ハーネスエンジニアリングを構成する4つの要素
- リポジトリ知識を正本にする:
- 巨大なAGENTS.md 1枚にすべてを書き込む方法は失敗する
- 短いAGENTS.mdを目次として使い、構造化されたdocs/ディレクトリをsystem of recordとして運用する
- 「何が正本で、どこを見に行けばよいか」をエージェントに迷わせないことが重要
- アプリケーションとリポジトリをエージェントにとって読める状態にする（legibility）:
- UI・ログ・メトリクスをAIが直接読めるようにする
- エージェントから見えていないものは存在しないのと同じであるため、情報はリポジトリ内で発見可能かつバージョン管理された形に保つ必要がある
- Google Docs・チャット・口頭で完結している情報はAIにとって不可視であるため、リポジトリ内に押し戻す
- フィードバックループを実装し、生成から修正までを自走させる:
- AIに自己レビュー・追加レビュー・フィードバック反映・再実行をループさせ、Pull Requestを完成に近づける
- 1つのプロンプトから現状確認・不具合再現・修正・再検証・PR作成・レビュー応答・マージまで進められる仕組みを目指す
- 「出力をもらう仕組み」ではなく「検証とやり直しまで含めて作業を閉じる仕組み」として設計する
- アーキテクチャ原則を機械的に強制し、継続的に掃除する:
- 完全自律に近づくほど、AIは既存リポジトリ内の不均一なパターンや最適でない実装も増幅する
- 「AI slop（その場では動くが徐々に荒れていくコードベース）」の蓄積を防ぐために機械的な仕組みが必要
- golden principles（機械的に判定できる明確なルール）をリポジトリに埋め込み、定期的なクリーンアップタスクを自動で回す
- 生成時の制御だけでなく、生成後に蓄積するエントロピーを減らす運用まで含めて設計する
■ 5. ハーネスエンジニアリングの進め方
- 短いガイド（AGENTS.md）を入口の地図として作成する
- AGENTS.mdの構成:
- このファイルの役割: 詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口
- 最初に確認するもの: ARCHITECTURE.md、docs/product-specs/index.md など
- 作業ルール: 仕様書の確認、ドキュメント更新、build/test/lint の実行
- 完了条件: 仕様との整合性、テストと検証の完了、ドキュメント更新の反映
- ディレクトリ構造はdocs/以下にdesign-docs/・exec-plans/・product-specs/・references/などを整備する
■ 6. よくある失敗とまとめ
- よくある失敗:
- AIの賢さを過大評価し、組織の未整備を過小評価する
- ドキュメントが曖昧・レビュー基準が人依存・変更サイズが大きい・責任境界が曖昧なままAIを導入すると、生成量だけ増えて下流が詰まる
- 「ツールを変えれば解決する」という誤解を持ち、開発プロセスや仕組みなどの構造を変えないまま運用する
- まとめ:
- ハーネスエンジニアリングは、AIにうまく指示する技術ではなく、AIが継続的に成果を出せるように開発組織そのものを再設計する技術
- モデルの性能よりも、AIが迷わず進め・途中でミスを検知でき・ミスを修正できる仕事の仕組みを作ることが重要