原題: Beyond Prompts and Context: Harness Engineering for AI Agents
著者: madplay
公開日: 2026-02-15
ソースURL: https://madplay.github.io/en/post/harness-engineering
アーカイブ日: 2026-05-07
この論考は、AIエージェントの性能を左右するのはモデル単体の能力ではなく、その周囲に構築された実行環境である、という観点からハーネスエンジニアリングを定義している。プロンプトエンジニアリングが「何を聞くか」、コンテキストエンジニアリングが「何を見せるか」を扱うのに対して、ハーネスエンジニアリングは、エージェントが安定して働けるようにするための制約、足場、フィードバックループ、運用系を含む環境全体の設計を扱う。リポジトリ構造、CI、フォーマッタ、パッケージマネージャ、アプリケーションフレームワーク、プロジェクト指示書、外部ツール連携、リンターまでがその対象になる。
著者は、プロンプト、コンテキスト、ハーネスの三層を入れ子の関係として整理する。単発の対話中心だった時代には、役割設定や例示を含むプロンプト設計が大きな意味を持った。そこから、RAG、MCP、メモリのように、推論時にモデルへ何を渡すかを設計するコンテキストエンジニアリングへ関心が移った。しかし、AIエージェントが複数ステップの自律実行を担うようになると、それだけでは防げない問題が前面に出る。たとえば、依存方向を破るコードの生成、並列実行時の衝突、規約逸脱、品質の漸進的劣化といった問題である。これらは「モデルに何を見せるか」ではなく、「システムとして何を防ぎ、測り、修復するか」の問題だとされる。
この整理を支えるために、論考はハーネスの構成要素を具体的に列挙する。まず、AGENTS.md や CLAUDE.md のようなコンテキストファイルは、エージェントが読むべき知識の地図として機能する。ただし、巨大な単一文書はむしろ重要な制約を埋もれさせ、すぐに陳腐化したルールの墓場になるため、作業ディレクトリごとに近接した文書だけを読ませる構造が有効だとする。次に、MCP サーバーは課題管理やブラウザ操作、社内文書検索のような外部資源への橋渡しを担うが、接続先を増やしすぎるとツール定義そのものがトークン負荷になるため、必要なものだけを選択的につなぐべきだと述べる。SKILL.md のような手順ファイルも、繰り返し作業を再現可能な形にする重要な部品として位置づけられる。
論考の核心は、コンテキスト設計との違いがもっとも鮮明に出る領域として、機械的な強制とコードのガベージコレクションを挙げている点にある。OpenAI は大量のコード生成環境で、単に「こう書くべきだ」と文書化するのではなく、依存方向や構造を強制するカスタムリンターと構造テストを導入した。しかもリンターは失敗を知らせるだけではなく、その修正指示をエージェントのコンテキストへ戻すよう設計されていた。これにより、ルール違反を検知し、その場で自己修復へつなぐフィードバックループが成立する。また、エージェントが生み出す技術的負債やパターンの劣化に対しては、バックグラウンドエージェントがコードや文書のズレを継続的に検査し、リファクタリング PR を開くことで、定期的な人手の大掃除を代替する構想も紹介される。ログやメトリクス、DOM スナップショットへのアクセスのような観測可能性も、エージェントが自分の生成物を検証するためのハーネスの一部として扱われる。
この主張の説得力を高めているのが、三つの実験的事例である。OpenAI の内部事例では、2025年8月から約5か月で、手書きコードゼロのまま約100万行、約1500件の PR がマージされ、1人あたり1日平均3.5件の PR という高い生産性を実現したとされる。重要なのは、それが最初からうまくいったわけではなく、環境設定、ツール統合、回復ロジックを段階的に改善することで生産性が跳ね上がったという点である。Can Boluk の Hashline 実験では、モデル自体を変えずに、編集対象の行へ短いハッシュを付与するだけで、あるモデルのコーディングベンチマークが 6.7% から 68.3% へ改善した。LangChain の事例でも、同じモデルでハーネスだけを改善した結果、Terminal Bench 2.0 のスコアが 52.8% から 66.5% に上昇し、順位でいえば中位から上位へ大きく躍進したと紹介される。
最後に著者は、AI 時代のボトルネックはモデル知性そのものよりも環境設計にあると結論づける。モデル性能は今後も急速に収斂していく一方で、回復ロジック、制約設計、ドキュメント構造、ツール連携は各チームが自前で構築するしかない。そのため、ハーネスへの投資が、後の実務生産性に持続的な差を生む可能性が高いと論じる。ただし、変化のスピードが速すぎるため、今の正解が短期間で別の正解へ置き換わる可能性も認めており、ハーネスは固定理論ではなく、失敗箇所を観測しながら継続的に設計し直す対象として提示されている。
この文章の価値は、ハーネスエンジニアリングを単なる流行語として紹介するのではなく、なぜその概念が必要になったのかを、プロンプト中心の時代からエージェント運用の時代への移行として立体的に説明している点にある。プロンプト、コンテキスト、ハーネスをそれぞれ別物として切り分けるだけでなく、どこから先がコンテキストでは扱いきれない問題なのかを明示しており、実務で何を強制し、何を測るべきかを考える際の骨格として使える。
とりわけ重要なのは、環境設計が結果を桁違いに変えうることを、定量例で示していることである。Hashline のような編集フォーマットの変更、LangChain のような評価ループの改善、OpenAI のような運用ハーネスの積み上げは、どれもモデル更新ではなく周辺設計の改善によって性能が大幅に変わることを示している。モデル選定だけに議論が偏りやすい局面で、先に見るべきものを差し戻す資料として強い。
また、リンターや CI を「エージェントが従うべき規則」ではなく、「エージェントが逸脱したときに必ず押し戻す機械的境界」として捉えている点も長期的に参照価値が高い。AI エージェントを本番の開発プロセスへ組み込むとき、良い指示を書くことより、逸脱を検知して自動的に修正へつなげる仕組みをどう作るかが本質だという見立ては、おそらく一過性の話では終わらない。概念整理と実践観察の距離が近く、今後もしばらく参照点として残る文章だと思う。