ハーネスエンジニアリングとは?AIエージェントが作業できる環境の設計

オンライン文書の版番号:未確認
AIエージェントに不具合の修正を任せても、作業場所や結果の確かめ方が決まっていなければ、うまく進められません。この記事では、AIエージェントが作業を進め、結果を確かめられるようにする設計を、架空のWebサイトの入力フォームを例に説明します。
ハーネスエンジニアリングとは
ハーネスエンジニアリングは、AIエージェントが目的の作業を進められるよう、モデルの周囲にある情報、ツール、実行環境、確認方法を設計し、作業結果を見て改める仕事です。
ここでいう「ハーネス」は、エージェントを動かす仕組みを指します。「ハーネスエンジニアリング」は、その仕組みをどう作り、どう改善するかに重点を置いた言葉です。統一された仕様名ではなく、開発元の資料でも対象の広さには違いがあります。本記事では、モデルが使う作業環境も対象です。
作業できる状態を用意する
架空のWebサイトで、「問い合わせフォームの必須項目を空欄にしたとき、案内が出ない」という不具合を直すとします。エージェントが対象のコードを探せず、画面を開けず、結果も確かめられなければ、仕事を続けられません。
まず、リポジトリの構成や関連する仕様を見つけられ、編集やテストに必要なツールを使える環境にします。ブラウザーでの確認も必要です。公開環境を勝手に変更しないよう、作業場所と権限も決めておきます。
OpenAIの技術記事では、エージェントが読める形でリポジトリ内の知識を整理し、画面やログを自分で確かめられる環境を作った例が紹介されています。必要な情報と操作手段が届くかも、設計時に確認する点です。
途中の行動と結果を確かめる
フォームの修正が終わったとエージェントが報告しても、その文だけでは不具合が解消したか分かりません。必須項目を空欄にして送信し、案内が表示されるかを画面で確認する必要があります。
修正後にテストを実行したか、変更してよい範囲だけを編集したかも確認の対象です。画面で案内が表示されたかは最終結果、テストの実行と変更範囲は途中の行動に当たります。Googleの技術記事が示すのも、この2つを組み合わせた評価です。
決まりを文章で伝えるだけでなく、機械で確かめられる条件はテストやチェックにします。ただし、複雑な作業で操作の順番を細かく固定すると、別の正しい進め方まで失敗と判定しかねません。何を確認したいのかに合わせて、途中の行動と結果のどちらを見るかを決めます。
失敗を見て仕組みを直す
エージェントが修正に失敗したら、まず作業記録を見ます。関連ファイルを見つけられなかったのか、ツールを使えなかったのか、テストで異常を発見できなかったのか。原因によって、整える箇所は異なります。
例えば、画面を開けなかったならブラウザーの操作環境を確認します。結果の見た目を誤って判断したなら、成功とみなす条件や確認方法を見直す番です。構成を一度に大きく変えると、何が改善につながったか分かりにくくなります。
モデルが新しくなったときも、以前に加えた補助の再点検が必要です。Anthropicは、モデルの能力が変わると、以前のモデル向けに作った構成が不要になる場合があると報告しています。複雑な仕組みを維持する理由も、実際の作業結果から判断するとよいでしょう。
近い考え方との関係
プロンプトエンジニアリングは依頼や条件の書き方を整えます。コンテキストエンジニアリングは各回にモデルへ渡す情報を選ぶ考え方です。ハーネスエンジニアリングでは、それらを使って作業し、結果を確かめられる環境まで設計します。
これらは作業の中で重なります。一方、次の操作をどう決め、どの条件で反復を終えるかは、作業の進め方を設計する別の論点です。この記事では、判断の材料と操作・確認の手段をエージェントに用意するところまでを扱います。
製品での使われ方
OpenAIはCodexを使った開発の例として、リポジトリ内の文書、機械的なチェック、画面やログを確認できる環境を紹介しています。Anthropicの長い開発作業の例では、作業結果を評価する仕組みを加え、モデルが変わった後には構成を簡素化する実験も行いました。
両方の例では、エージェントが失敗したとき、情報へのアクセス、ツール、確認方法まで調べています。自分の作業に取り入れるなら、まず1つの課題を選んでください。エージェントが読める資料、使える操作、結果を確かめる手段を書き出すところから始められます。