ハーネスエンジニアリングとは

ハーネスエンジニアリングとは

ハーネスエンジニアリングは、AIエージェントにおいて「モデル以外のすべて」を設計する考え方です。ハーネス（harness）は、もともと馬具や配線をまとめる束のこと。AIの文脈では、モデルを制御し支える外側の仕組み全体を指します。

ThoughtworksのBirgitta Böckelerは<a href="https://martinfowler.com/articles/harness-engineering.html">MartinFowler.comの記事</a>で「Agent = Model + Harness」という式を示しています。モデルが「何を考えるか」を担い、ハーネスが「何を見せるか」「何を使わせるか」「失敗したらどうするか」「どこまで許すか」「何を記録するか」を担います。

HashiCorp創業者のMitchell Hashimotoは、<a href="https://mitchellh.com/writing/my-ai-adoption-journey">自身のブログ</a>で「エージェントが間違えたら、二度とその間違いをしないよう環境を設計する」ことをharness engineeringと呼んでいます。具体的には、AGENTS.mdの更新や、自動テスト・スクリーンショット取得などの検証ツールを整えることを指します。

モデル単体の限界とハーネスが解決すること

AIモデルは単体で使うと、いくつかの失敗パターンを抱えています。ハーネスは、これらをモデルの外側から補います。

• 情報過多：渡す情報が多すぎると、モデルの注意が散り、大事な指示を見落とす。→ 必要な情報だけを必要なタイミングで渡す設計（コンテキストエンジニアリング）で補う。
• 繰り返し失敗：一度した間違いを何度も繰り返す。→ 変更後に自動でテストやリンターを走らせ、結果をモデルに返す（フィードバックループ）で補う。
• 早期完了宣言：途中で「完成しました」と言うが、実際には抜け漏れがある。→ 独立した評価者（別のAIや人）で出力を検証する設計で補う。
• 文脈の消失：やり取りが長くなると、途中の指示や決めたことを忘れる。→ 進捗メモやセッション間の引き継ぎを設計する（メモリ設計）で補う。
• 危険な操作：ファイル削除やデータ更新を許可なく実行してしまう。→ 操作の範囲と許可を決め、超えたら止める（ガードレール）で補う。

ハーネスの構成要素：コンテキスト・ツール・ガードレール・フック

ハーネスは、いくつかの役割に分けて設計できます。ここでは基本の四つを紹介します。

• コンテキスト：モデルに何を見せるか。システムプロンプト、ルールファイル、参照するドキュメント、過去のやり取り。必要最小限の、質の高い情報を選ぶことが肝です。
• ツール：モデルに何をさせるか。ファイルの読み書き、検索、外部APIの呼び出しなど。どのツールを使わせるか、使うときに許可を求めるかを設計します。
• ガードレール：モデルの行動をどう制限するか。削除や上書きなど破壊的な操作を禁止する、特定のフォルダ外には書き込めない、などのルール。
• フック：モデルの動作の前後に自動で走らせる処理。ファイルを保存したらフォーマッターをかける、作業が終わったらテストを回す、などの設計。

これらを組み合わせて、「この作業ではこのルールを読ませ、このツールだけ使わせ、終わったらこのチェックを走らせる」という一連の流れをつくります。最初は「最低限の指示ファイル」と「変更後のテスト自動実行」から始めます。

ガイドとセンサー：事前の指示と事後の確認

ThoughtworksのBirgitta Böckelerは、<a href="https://martinfowler.com/articles/harness-engineering.html">MartinFowler.comの記事</a>でハーネスの制御を「ガイド（feedforward）」と「センサー（feedback）」の二つに分けて整理しています。

• ガイド（事前の制御）：モデルが動く前に、問題を防ぐための仕組み。ルールファイルや指示文、コーディング規約のドキュメント。最初から良い結果が出る確率を高めます。
• センサー（事後の制御）：モデルが動いた後に、問題を検出して直させる仕組み。テスト、リンター、AIによるレビュー。間違いを見つけて修正のフィードバックを返します。

どちらか片方では足りません。ガイドだけだと本当にルールが効いているか分からず、センサーだけだと同じ間違いを繰り返します。両方をセットで設計することで、品質が安定します。

センサーのうち、テストやリンターは高速で安価なので、変更のたびに回せます。AIによるレビューはコストがかかるので、作業完了時など適切なタイミングで使います。この使い分けも設計のうちです。

生成と評価の分離

Anthropicの<a href="https://www.anthropic.com/engineering/harness-design-long-running-apps">技術ブログ</a>では、長時間のエージェント実験の知見として、生成するAIと評価するAIを分ける設計を紹介しています。

同じAIに「作って」と「確認して」を頼むと、自分の出力を甘く評価しがちです。別のエージェントに評価だけを任せると、懐疑的に検証できます。コストは増えますが、タスクがモデルの能力の境界にある場合は、品質が大きく変わります。

中小企業では、AIの下書きを別の人かツールで確かめる手順を1つ入れるところから始めます。AIが出した下書きを、別の視点で検証するステップを入れるだけでも効果があります。

始め方：最小限の指示ファイルと確認ループから

ハーネスエンジニアリングは、最初から完璧に作り込む必要はありません。まずは小さく始め、使いながら育てます。

• 指示ファイルを一つ書く：プロジェクトの概要、守ってほしいルール、禁止事項を短くまとめます。説明文より「ルールへのポインタ」として機能させます。
• 変更後のテストを自動で走らせる：ファイルを保存したら自動でテストを実行し、結果をAIに返す設計。フック機能を使うか、手動で「テストを回して」と頼むだけでも始められます。
• エージェントが困ったら、ルールを足す：エージェントが同じ間違いを繰り返したら、それを防ぐルールを指示ファイルに追記します。一度で完成させず、往復で育てる発想です。

CADDiのテックブログの記事「<a href="https://caddi.tech/start-harness-engineering-with-framework">ハーネスエンジニアリングは枠組みから始めよう</a>」で紹介されている「枠組みから始める」アプローチが参考になります。最初から内容を充実させなくても、「ここに追加すればいい」という場所が決まっているだけで、チームで更新しやすくなります。

• 属人化とは → AIの使い方が個人に閉じる問題
• AIエージェント導入支援 → AIを業務に組み込む支援

AIの使い方を会社に残す：sento.groupの考え方

ハーネスを個人のPCで育てると、指示文もルールも履歴も、その人のアカウントに閉じます。担当者が変わると、同じ品質を再現できません。sento.groupでは、ハーネスの資産を会社に残す設計を重視しています。

• 共有の指示ファイル：よく効くプロンプトやルールを、共有のドキュメントや台帳に置きます。誰でも呼び出せ、誰でも更新提案できる形にします。
• 実行ログ：AIに何を頼み、何が返り、人がどこを直したかを、共有の場所に残します。判断の理由が後から辿れるようになります。
• 確認手順の台帳：どの業務にどのテストや確認を走らせるかを、一覧にします。担当者が変わっても同じ確認が回ります。
• 権限の一覧：どのデータをどのAIに渡してよいか、誰が何を見られるかを決めて書きます。共有範囲が広がるほど、この線引きが必要です。

AIと一緒に仕事を進めること自体が記録になるよう設計します。たとえば、AIへの指示と結果を共有チャンネルに投げる、AIの出力を台帳に自動で書き込む、といった流れを作ります。使うほど会社の知識が増える向きに流れを変えるのが狙いです。

• 属人化とは → AIの知識が個人に閉じる問題
• データ定義書の作り方 → 項目の意味を台帳に残す