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

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

ハーネスエンジニアリングは、AIエージェントに作業を委任できるよう、モデルの外側の仕組みを設計し、改修し続ける取り組みです。
作業の前に誤りの発生を抑制する制御と、作業の後に誤りを検出する判定を整備し、繰り返し発生する誤りを発見したら、再発を抑制する仕組みを追加します。
対象はエージェントハーネス、つまりモデル以外の部分で、作業ルールの文書、使用を許可するツール、自動テスト、出力の形式の判定、操作前の承認などを改修します。
目的は、人の確認の一部を機械による判定に置換して、エージェントに委任できる作業の範囲を拡大することです。
事例はコーディングエージェントを利用するソフトウェア開発が先行しています。
作業の前の制御と作業の後の判定という考え方はコードに固有のものではなく、問合せ対応や事務処理など、エージェントに作業を委任する業務にも当てはまります。

たとえばコーディングエージェントが、社内で禁止しているライブラリを何度も使用するとします。
指示文に使用の禁止を追記するだけでは、次の作業で再発することがあります。
ハーネスエンジニアリングでは、禁止したライブラリを検出する自動の判定を追加します。
違反を検出したら作業を完了扱いにせず、修正の方法を示すメッセージをエージェントに通知します。
注意を口頭で反復する代わりに手順書、チェックリスト、検品の工程を整備し、判定で検出できる誤りの見逃しを減少させる職場の取り組みに相当します。

プロンプトエンジニアリングとコンテキストエンジニアリングは、モデルに入力する指示や資料を設計します。
両者との包含関係は資料によって説明が異なりますが、ハーネスエンジニアリングは結果を判定する仕組みまでを対象にする点が異なります。

指示文の改善だけでは委任の範囲を拡大できない理由

エージェントに委任する範囲を拡大すると、人が結果を1件ずつ確認する負担が増加します。
指示文を改善しても、遵守されたかどうかは結果を確認するまで分かりません。
確認を人だけが担当する場合、委任できる作業の量は確認する人の時間で頭打ちになります。

ハーネスエンジニアリングは確認の一部を機械による判定に置換して、この上限を拡大します。
Thoughtworksの技術者であるBirgitta Böckelerは、Martin Fowlerのサイトの論考で仕組みを2種類に分類しています。

• 事前の制御: 作業ルールの文書、使用できるツールの限定、手順の型。誤りの発生を抑制する
• 事後の検出: 自動テスト、形式の判定、別のAIによる審査。誤りを検出してエージェントに修正させる

OpenAIは、手書きのコードを使用せずにエージェントで社内の製品を開発した事例を報告しています。
その中でエンジニアの役割を環境の設計、意図の明確化、フィードバックの仕組みの構築と説明しています。
エージェントの誤りを発見したときは、修正させるだけでなく、不足していた規則や情報を追加します。
OpenAIは、規則を独自の静的解析と構造のテストで機械的に強制し、エラーのメッセージに修正の方法を記載してエージェントに返却しています。

ソフトウェア開発以外の業務への適用

問合せへの回答や事務処理を委任するエージェントでも、考え方は同じです。
判定の例は次のとおりです。

• 回答に必須の項目がすべて記載されているかの形式の確認
• 金額や件数が元の資料と一致するかの確認
• 禁止した表現の検出
• 参照した資料が社内の最新版かの確認

ただしソフトウェアのテストに相当する判定が業務にない場合は、人の確認の記録から差し戻しの理由を分類し、判定の規則として明文化する段階が追加で必要になります。

ハーネスエンジニアリングの効果とコスト・リスク

効果

• 判定で検出できる種類の誤りの再発を抑制でき、人が確認する件数を削減できる
• 確認を機械に置換した範囲だけ、エージェントに委任する作業の範囲を拡大できる
• 誤りへの対策が文書と自動の判定の仕組みとして残存し、担当者が交代しても引き継ぎが可能になる

コストとリスク

• 整備と保守の時間。仕組みの整備と、エージェントが生成した成果物の整理に技術者の時間がかかる。OpenAIの事例では、当初は毎週1日を、エージェントが生成した質の低いコードの整理に使用していた
• 誤検出と処理の増加。判定が違反を誤検出するとエージェントの作業が停止し、判定の実行そのものにも処理時間と費用がかかる
• 判定の改ざん。エージェントがテストや判定そのものを改変し、条件を緩和し、実行を省略して、通過した状態にすることがある。報酬ハッキングと呼ばれる挙動である。METRは、2025年時点の最新のモデルがテストや採点のコードを改変して高い得点を得ようとした例を報告している。テストと判定の設定はエージェントに変更させないか、変更には人の承認を必須にする

• 判定の限界。判定やテストを通過しても正確とは限らない。Böckelerは、業務として正確な動作かを判定するテストをAIの生成に依存する方法はまだ十分ではないと指摘している
• モデルの更新。モデルの更新で出力の傾向や失敗の種類が変化し、不要になる仕組みや、再調整が必要な仕組みが生じることがある
• 既存システムの整備。自動テストや構造の規則が整備されたコードは、判定を追加しやすい。技術的負債が蓄積した既存のシステムは、仕組みが最も必要なのに整備が困難

ハーネスエンジニアリングに投資するかの判断

エージェントに委任する作業が日常的に発生し、同じ種類の誤りの修正やレビューに時間を消費しているなら投資します。
試行の段階や、委任する作業が月に数件の段階では投資しません。
作業ルールの文書を1つ用意し、既存の自動テストを実行させるだけで十分です。
最初の投資は、1つのリポジトリか1つの業務を対象に、技術者1〜2人が1〜2か月程度、業務時間の一部を差し戻しの記録と判定の追加に使用する規模を目安に開始します。

投資する場合の手順は次のとおりです。

1. 差し戻しや修正の理由を種類別に記録する
2. 再発する種類のうち、自動の判定やテストで機械的に検出できるものを選択する
3. 判定で違反を検出した作業は完了扱いにせず、修正の方法をエージェントに通知する仕組みにする
4. 機械で判定できるようになった種類の誤りについて、人の確認を抜き取りに変更する

抜き取りに変更する前に、2つの点を記録で確認します。
判定の追加後にその種類の差し戻しが減少していることと、判定を通過したのに後で発見された誤りがないことです。
取り消しが困難な操作、顧客データの取り扱い、本番環境の変更は、仕組みを整備しても人の承認を維持するほうが安全です。
OpenAIの事例も、人は常に作業の流れに関与する前提で記述されています。

効果の測定の指標

効果は仕組みの数ではなく、整備の前後での次の指標の変化で評価します。

• 差し戻しの回数と理由の内訳
• 1件あたりのレビュー時間
• 本体のコードへの統合後や業務への反映後に発見された誤りと、取り消しの件数
• 1件あたりのエージェントの費用と処理時間

よくある誤解

先行事例と同様に開発の速度が何倍にもなる

OpenAIは、手書きの場合のおよそ10分の1の時間で開発したと見積もっています。
ただし対象は、エンジニア3人から開始して約5か月をかけて仕組みを整備した新規の社内製品です。
OpenAI自身も、同程度の投資なしに一般化すべきではないと注記しています。
既存のシステムや整備前の環境で同じ速度になるとは限らないため、自社の効果は上の指標で評価します。

プロンプトエンジニアリングの別名である

指示文の改善は、ハーネスエンジニアリングの手段の1つにすぎません。
中心は結果を機械で判定する仕組みで、エージェントが指示文を遵守しなかった場合にも、誤りを検出して作業を停止できます。
自動の判定の対象は機械で判定できる範囲だけです。
何を開発すべきかと、業務として正確かは、人が決定します。