第2章 出自と提唱の経緯 ── 誰が、なぜ今この言葉を作ったのか
名付け親：Mitchell Hashimoto
ハーネスエンジニアリングという言葉を最初に明確に定義したのは、Mitchell Hashimoto だ。Terraform、Vagrant、Packer、Consulの作者であり、HashiCorpの共同創業者。2024年からはターミナルエミュレーター「Ghostty」の開発に専念している。
彼が2025年後半に公開したブログ記事 “My AI Adoption Journey” は、自身のAI活用の段階的な変遷を振り返ったものだ。プロンプトへの懐疑から始まり、エージェント活用、そして「ハーネスエンジニアリング」の発見へと至る道筋が記されている。
その記事でHashimotoはハーネスエンジニアリングをこう定義した。
「エージェントがミスをするたびに、そのミスが二度と起きないようにエンジニアリングで解決策を作る、という考え方」
定義はシンプルだが、含意は深い。ミスを個別修正するのではなく、ミスを再発させない仕組みを構築することに本質がある。フィードバックを制度化することで、エージェントの性能はセッションをまたいで累積的に向上する。
Ghosttyプロジェクトでの実証
Hashimotoはこの考えをGhosttyプロジェクトで実践した。Ghosttyのリポジトリには AGENTS.md というファイルがある。彼はそのファイルについてこう説明している。
「このファイルの各行は、実際のエージェントの失敗履歴に対応している。それを追加してからというもの、同種のミスはほぼゼロになった」
AGENTS.md は「指示書」であると同時に「失敗の記録」だ。エージェントが間違ったコマンドを実行するたびに、その防止策が1行追加される。間違ったAPIを使うたびに、正しいAPIへの誘導が1行追加される。このファイルは生きており、プロジェクトとともに成長する。
二種類の実装形態
Hashimotoはハーネスの実装を二つの形態に分けている。
暗黙的プロンプティング（AGENTS.mdによるもの）
コマンドの誤使用、APIの取り違え、プロジェクト固有の慣習の無視——これらの軽微な失敗は、AGENTS.mdへの追記で対処できる。エージェントはセッション開始時にこのファイルを読み込み、過去の失敗パターンを「知識」として内面化する。
プログラムされたツール（検証スクリプトの整備）
より根本的な失敗——「テストは通るが実際の動作が壊れている」「UIを確認せずに完了とした」——は、AGENTS.mdの文章では防げない。この場合はエージェントが自ら実行できる検証ツールを作る。スクリーンショット自動化、フィルタリングされたテストランナー、カスタムアサーション。
ハーネスの二形態
① 文書型（AGENTS.md）
過去の失敗 → 防止指示 → 次回から自動回避
② ツール型（検証スクリプト）
潜在的失敗 → 検証機構 → 実行時に自動検知・修正Hashimotoの観察によれば、この「失敗 → ハーネス追加」のサイクルは複利的に効く。初期の失敗を記録した1行が、将来の無数のエージェント実行に対して自動的に適用される。早く始めるほど、後の実行が安定する。
OpenAIによる概念の産業化
Hashimotoの定義が種をまいたとすれば、それを産業レベルに広めたのは OpenAI だ。
OpenAIのエンジニアリングチームは一つの実験を行った。制約はシンプルだった。「人間はコードを1行も書かない」。この縛りのもと、3〜7名のチームが5ヶ月間プロダクト開発を続けた。
結果は驚くべきものだった。
OpenAI ハーネスエンジニアリング実験（2025年）
期間 : 5ヶ月
チーム規模: 3〜7名
生成コード: 100万行以上
マージPR : 1,500件以上
開発速度 : 手作業比 約1/10この成果を “Harness engineering: leveraging Codex in an agent-first world” という記事にまとめ、2026年初頭に公開した。記事の要旨は明確だ。進捗が遅い原因の多くは、モデルの能力ではなく環境の未整備にある。
OpenAIチームが実際に整備したものを見ると、ハーネスの構成要素が具体化される。
Chrome DevTools連携：エージェント自身がブラウザを操作してUIのバグを再現・検証できる環境。人間が「画面を見て確認する」部分を自動化した。
オブザーバビリティスタック：ログ・メトリクス・トレースを提供し、パフォーマンス要件をエージェントが直接扱えるようにした。「なんか遅い」という感覚ではなく、数値でフィードバックを受けられる。
段階的知識提供：巨大なマニュアルを一度に渡すのではなく、目次的な AGENTS.md を入口にして、必要に応じて docs/ 配下の詳細情報へと誘導する構造。
「名前がついた」ことの意味
Hashimotoが定義し、OpenAIが実践例を提示したことで、それまで「なんとなくやっていたこと」に名前がついた。
ソフトウェアエンジニアリングにおいて、名前がつくことは重要だ。「コンテキストウィンドウが尽きてエージェントがおかしくなった」という体験を、かつては個別の不具合として処理していた。「ハーネスの問題」という共通言語が生まれることで、チームで議論でき、パターンを共有でき、解決策を蓄積できる。
2026年前半の技術コミュニティでの急速な浸透は、この「名前がついた」効果が大きい。多くの開発者が「そうか、自分がやっていたのはハーネスエンジニアリングだったのか」という認識のアップデートを体験した。
タイムライン
timeline
title ハーネスエンジニアリングの系譜
2025後半 : Hashimotoが "My AI Adoption Journey" を公開
: AGENTS.md パターンを定義
: 「失敗 → ハーネス追加」サイクルを提唱
2026年初 : OpenAIが実験結果を発表
: 100万行・1500PR・チーム3〜7名
: "harness engineering" という表現を産業界に広める
2026年2月〜3月 : Martin Fowler.com, LangChain, Anthropic が体系化記事を公開
: コミュニティでの議論が加速
: ベストプラクティス・アンチパターンが言語化され始める次章では、この概念をプロンプトエンジニアリング・コンテキストエンジニアリングとの関係から整理し、「ハーネス」が何を扱い、何を扱わないのかを明確にする。