Opsfield
ハーネスエンジニアリングとは、AIエージェントが安定して成果を出せるように、モデルの外側にある作業環境そのものを設計する取り組みです。守ってほしい決まりを渡し、実行してよい範囲を決め、出てきたものを検証する。その一式をハーネスと呼びます。
同じAIを使っているのに、人によって成果物の質がまるで違う。その差が生まれる原因は、モデルの賢さよりも、AIが働く環境の作り込みにあります。2026年に入ってから国内外の開発現場でこの報告が相次ぎ、言葉として定着しました。
本記事では、ハーネスエンジニアリングの5つの構成要素と進め方だけでなく、コンテキストエンジニアリングとの違いや、つまずきやすい失敗パターンなども解説します。
目次
ハーネスエンジニアリングとは？AIエージェントが働く環境そのものを設計する取り組み
ハーネスエンジニアリングは、AIエージェントからモデルを除いた残りのすべて、つまり指示・道具・実行環境・記録・検証の仕組みを設計する取り組みです。エージェントは、モデルとハーネスの組み合わせで動きます。モデルが思考と判断を担い、ハーネスが手足と作業場を用意する、という分担です。
そもそもハーネスという語は、馬車馬につける胴輪や引き具を指します。馬具は走力を削ぐためではなく、力を出す方向を決めて暴れずに進ませるために付けるものです。AIのハーネスも同じで、能力を制限する枠ではなく、性能を仕事に変換するための装置だと考えると分かりやすくなります。
言葉として広まったのは2026年2月ごろで、OpenAIが手書きのコードを使わずに製品を作った実験を公開しました。ほぼ同じ時期に、Thoughtworksのビルギッタ・ベッケラー氏もこの語を正面から扱った記事を出しています。そのため、どちらか一方が提唱したというより、現場の実感に名前が付いた、という広まり方をしました。
なお、ハーネスという言葉は2つの層にまたがって使われます。エージェント製品の内側にあらかじめ組み込まれている層は、製品を作る側の担当です。AIがファイルを読み書きする仕組みや、コマンドを実行する経路がこれに当たります。一方、ルールのファイルを置き、手順書を足し、検証を挟むといった外側の層は、使う人が自分で育てていきます。本記事で扱うのは、すべて後者の層の話です。
指す範囲も書き手によって差があります。国内の解説ではコーディングエージェントの設定作業、つまりルールのファイルやフックの整備を指すことが多い一方、海外の議論では外部システムへの接続口や隔離された実行環境まで構成物として数えます。そのため、解説ごとに話が噛み合わないこともあります。
ただし、どちらの立場でも共通しているのは、モデルを賢くする取り組みではないという点です。同じAIに、同じ精度で、繰り返し仕事をさせるための環境づくりを指します。
ハーネスエンジニアリングとプロンプト・コンテキストエンジニアリングの違い
プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング。名前が似ているため混同されがちですが、設計する対象がそれぞれ違います。どこが分かれ目になるのかを整理します。
| プロンプトエンジニアリング | コンテキストエンジニアリング | ハーネスエンジニアリング | |
|---|---|---|---|
| 設計する対象 | 指示の書き方 | AIに渡す情報の中身 | 作業環境と検証の仕組み |
| 人が手を入れる場所 | そのつどの入力 | 1回の推論に渡す情報全体 | 設定ファイル・検証の経路・記録の置き場 |
| 効く場面 | 単発の依頼 | 資料や履歴を踏まえた回答 | 何時間も続く自律的な作業 |
| 代表的な成果物 | 質の高い指示文 | 参照資料の構造・要約・履歴の整理 | ルールのファイル・手順書・自動検証 |
先に押さえておきたいのは、新しい言葉が出たからといって古いものが不要になるわけではない、という点です。3つは置き換わるのではなく積み上がる関係にあります。依頼文の良し悪しは今でも結果を左右しますし、渡す資料の整理を怠れば精度は落ちたままです。ハーネスは、その上に毎回同じようにやらせる層を重ねるものだと考えてください。
この順番が分かると、手を付ける順序も見えてきます。まず依頼文を整え、次に参照させる情報を揃え、それでも品質がばらつくようなら環境の作り込みに進む。例えば、月に数回しか使わない要約作業であれば、依頼文を整えるだけで十分です。最初からハーネスを組み上げる必要はありません。
プロンプトエンジニアリングとの違い
分かれ目は、1回の依頼を磨くのか、何度も働かせる場を整えるのかという点にあります。
まず、プロンプトエンジニアリングは依頼文の書き方で出力の質を上げる工夫です。役割を与える、出力の形式を指定する、例を添える。いずれも、その場の1回に効きます。
ところが、同じ依頼文を別の環境で使うと結果は変わります。参照できる資料がない、検証の手段がない、前回の経緯が残っていない。例えば、社内の命名規則を書いたファイルが手元にあるかどうかだけでも、返ってくるコードの見た目は変わります。こうした差が積み上がるため、指示の巧拙だけでは安定しません。ハーネスエンジニアリングが作り込むのは、この環境の側です。極端に言えば、平凡な指示でも同じ品質が出る状態を目指す取り組みになります。
コンテキストエンジニアリングとの違い
コンテキストエンジニアリングとの関係は、対立ではなく包含です。この言葉が指すのは、AIが1回の推論で受け取る情報をどう組み立てるかの設計です。何を見せ、何を省き、どう要約するかを扱います。
一方、ハーネスエンジニアリングはその外側まで含みます。情報の渡し方に加えて、どこまで実行を許すか、結果をどう検証するか、作業をどう次のセッションへ引き継ぐか。ベッケラー氏も、ハーネスを構成する仕事の1つとしてコンテキストエンジニアリングを数えています。
つまり、コンテキストの設計はハーネスの一部です。渡す情報を整えることと、働かせ方の仕組みを作ることを別の作業として分けておくと、どちらに手を入れるべきかを判断しやすくなります。
ハーネスエンジニアリングの役割
ハーネスの働きは、作業の前に効くものと作業の後に効くものに大きく分かれます。前者をガイド、後者をセンサーと呼びます。この2つの役割を先に押さえておくと、ハーネスを構成する要素それぞれの位置づけがつかみやすくなります。
ガイド｜作業の前に迷いと逸脱を減らす仕組み
ガイドは、AIが手を動かす前に渡しておく情報や制約です。守ってほしい決まりごと、繰り返す作業の手順書、参照すべき資料の置き場所などが該当します。いわば、仕事を始める前に新人へ渡す手引きにあたります。文章で書いて渡すものに限らず、散らばっている資料の在りかを1か所にまとめておくこと自体もガイドの一部です。
ガイドが効くのは、そもそも間違った方向に進ませない、という場面です。例えば、使ってよいライブラリを先に指定しておけば、AIが勝手に別のものを選ぶことはありません。出力の形式を決めておけば、後から整え直す手間も省けます。社内で通っている書き方や禁止事項をまとめておけば、毎回同じ指摘を入れずに済みます。ただし、渡しただけでは守られたかどうかまでは分かりません。その確認を担うのがセンサーです。
センサー｜作業の後に誤りを検知して直させる仕組み
センサーは、AIが手を動かした後に働き、結果のずれを見つけて本人に返す仕組みです。
具体的には、テスト・型チェック・書式の検査・レビューがこれに当たります。人が目で見て指摘するのもセンサーの一種ですが、機械が自動で返す方が圧倒的に速い。AIは指摘を受けて直し、また検証にかける、という往復を自分で回せるようになります。
なお、ガイドとセンサーはどちらか一方では足りません。ガイドだけを厚くしても、守られたかどうかを誰も確認していない状態が続きます。逆にセンサーだけを並べると、AIは毎回同じ失敗をしてから直すことになり、やり直しの回数が増えるだけです。両方を組み合わせて、ようやくハーネスとして機能します。
機械で判定する検証とAIに判定させる検証の使い分け
センサーには2種類あります。機械が決まった手順で判定するものと、AIに読ませて判定させるものです。
まず、機械の判定は速く、安く、何度走らせても同じ結果が返ります。反面、扱えるのは形式的な条件に限られます。テストが通るか、型が合うか、書式が揃っているか。設計の意図に沿っているか、説明が分かりやすいかといった意味の判断はできません。
一方、AIによる判定は意味を見られる代わりに、結果が揺れますし費用もかさみます。そのため、まず機械で判定できる形に落とし、そこに収まらないものだけをAIに見せるのが基本形です。加えて、何をもって良しとするかは、直させる前に固定しておきます。評価の基準が動くと、改善したのかどうかを誰も判断できなくなります。
ハーネスエンジニアリングが注目される背景
注目される理由は、大きく3つあります。環境の差で成果が変わると実証されたこと、AIの使われ方が自律実行へ移ったこと、そして指示書を置くだけではルールが守られないと分かってきたことです。
まず、同じモデルを使っても環境の差で成果が大きく変わると、実証つきで示されました。OpenAIは2026年2月、手書きのコードを1行も使わずに製品を作った5か月間の実験を公開しています。およそ100万行のコードがすべてCodex（OpenAIのコーディングエージェント）によって書かれ、要した時間は手作業の約10分の1だったと報告されました。モデルを取り替えたのではなく、環境を作り込んだ結果です。
次に、AIの使われ方そのものが変わりました。チャットで質問して答えを受け取るだけなら、人が毎回目を通せます。しかしエージェントが自分でファイルを開き、コマンドを実行し、何十手も先へ進むようになると、1手ごとの確認は現実的ではありません。任せる範囲が広がるほど、止める仕組みを先に用意する必要が出てきます。
そして、指示書を置くだけでは守られないと分かってきました。ルールをファイルに書いても、それはお願いにすぎません。守られたかどうかを機械が判定し、外れたら止める。そこまで作って、ようやくルールとして機能します。AIは働き方の増幅器でもあるため、曖昧なまま渡した業務は、曖昧なまま増幅されます。だからこそ、ツールの選定より前に環境の設計が問われています。
ハーネスエンジニアリングを構成する5つの要素
ここからは、使う側が自分で足していける範囲に絞ります。ハーネスを構成する5つの要素を、それぞれがガイドとセンサーのどちらに当たるのかを添えながら見ていきます。
ルール｜AIに守らせたい前提と禁止事項
1つ目はルールです。プロジェクトの前提と禁止事項を書いたファイルで、ガイド側に当たります。
実際にはCLAUDE.mdやAGENTS.mdといった名前で、作業するフォルダの直下に置くのが一般的です。書く内容は、使ってよいライブラリ、触ってはいけない場所、命名の決まり、変更を確定する前に通す確認といったあたりになります。口頭やチャットで毎回伝えていた前提を、そのまま文字にするイメージです。
ただし、ルールのファイルには限界があります。書いてあっても読み飛ばされますし、量が増えるほど埋もれます。1つのファイルに何もかも詰め込むより、入口は短くまとめ、詳しい内容は別の資料へたどらせる形の方が機能します。本当に守らせたい決まりは、文章で置くだけでなく機械的に強制する方が確実です。
スキル｜繰り返す作業を再利用できる手順書
2つ目はスキルです。毎回説明している作業の手順を1つのファイルにまとめ、必要なときだけ呼び出せるようにしたもので、これもガイド側に入ります。
ルールが守らせたいことだとすれば、スキルはやり方そのものです。例えば、請求データの集計手順、リリース前の確認項目、問い合わせ返信の書き方。人に引き継ぐときに書く手順書と、中身はほとんど変わりません。
なお、この考え方はAIエージェントの正体は手順書である、という捉え方と重なります。モデルも外部への接続も買えますが、自社の仕事の進め方を言語化した手順書だけは、他社から買えません。だからこそ差がつきます。月次のレポート作成のように手順がほぼ固まっている作業ほど、スキルにしたときの効果は大きくなります。
フック｜ルールを機械的に強制する仕組み
3つ目はフックです。特定の操作の前後で検査を自動的に走らせ、条件を満たさなければ止める仕組みで、センサーの側に当たります。
ルールのファイルがお願いだとすれば、フックは強制です。例えば、変更を確定する前に必ず自動テストと書式チェックを通し、落ちたら先へ進ませない。AIが忘れても、人が見落としても、検査は必ず走ります。
仕掛ける場所は、作業の切れ目に置くのが基本です。ファイルを保存した直後、変更を確定する前、外部へ送り出す直前。どこで止めるかによって、やり直しの範囲が変わります。早い段階で止めれば直すのは一箇所で済みますが、最後まで通してから止めると、そこまでの作業がまとめて戻ってきます。手前に仕掛けるほど、1回あたりのやり直しは軽く済みます。
メモリ｜セッションをまたいで残す文脈
4つ目はメモリです。会話が切れても作業の経緯が残るように、外部のファイルへ記録を書き出しておく仕組みを指します。
というのも、AIは長く動かすほどやり取りが溜まり、精度が落ちるからです。話の一貫性が失われたり、終わっていないのに切り上げようとしたりする。そのため、一定のところで区切り、残作業と決めたことを外に出してから次へ渡す形が現実的です。
運用のコツは、会話が長くなりすぎる前に自分から区切ることです。精度が落ちてから引き継がせようとすると、要約そのものが雑になります。まだ判断が安定しているうちに、決まったことと残っている作業を書き出させて次へ渡す。この一手間があるかどうかで、長い作業の後半の質が変わってきます。
フィードバックループ｜誤りをAI自身に直させる検証
5つ目はフィードバックループです。出力の良し悪しがAI自身に返り、自分で直せる状態を作ります。
具体的には、テスト、型チェック、書式の検査、動作確認。大事なのは、これらをAI自身が呼び出せる状態にしておくことです。人に頼まないと結果が分からない検査では、ループになりません。コマンド1つで実行でき、どこが悪いのかまで文字で返ってくる形にしておくと、AIは指摘を受けて直し、もう一度かけるところまで自分で進められます。
一方、人が指摘する運用との差は待ち時間に表れます。人のレビュー待ちが1日なら、AIはその1日止まります。機械が数秒で返すなら、同じ時間で何往復もできる。検証が速いほど品質が上がるのは、このためです。
ハーネスエンジニアリングの実例
考え方が分かっても、実際にどこまで作り込むのかは想像しにくいところです。公開されている3つの事例を紹介します。いずれも、環境を整えたことで何がどう変わったのかまで示されています。
OpenAI｜3名・5か月で約100万行を人の手書きなしに進めた環境設計
5か月で約100万行という規模を、3名のエンジニアで回したのがOpenAIの実験です。アプリケーションのロジックからテスト、CI（変更のたびに自動で検査を走らせる仕組み）の設定、ドキュメントまで、コードはすべてCodexが書いています。人が手で書いた行はありません。
期間中に作られた変更依頼はおよそ1,500件で、1人あたり1日平均3.5件という計算になります。その後チームは7名まで増えましたが、処理量はさらに伸びたと報告されています。
では、3名でそれだけの量を抱えられたのはなぜか。1つは、決めたことの置き場所を変えたからです。設計上の判断をチャットの履歴や個人の記憶に残さず、プロジェクトのファイル一式へ集めました。入口に置いた案内ファイルは約100行と短く、詳しい資料へはそこからたどらせています。
もう1つが、守ってほしい形を機械で縛ったことです。コードの依存方向を独自の検査ツールで検証し、決めた構造から外れたものはそもそも通しません。エラーの文面には直し方まで書いてあるため、引っかかったAIはその場で直して再挑戦できます。人が見張らなくても、逸脱だけが止まる作りです。
Anthropic｜初期化と引き継ぎを分けて長時間の作業を続けさせる
Anthropicは、1回の会話では終わらない開発をエージェントに任せるための構成を公開しています。要点は、役割を2つに分けたことです。
まず、最初のセッションには環境を整えることだけを担当させます。開発用のサーバーを立ち上げるスクリプト、作業の記録を残すログファイル、実装すべき機能を並べた一覧、そして変更履歴の最初の1件。ここまでを先に作らせておきます。
一方、2回目以降のセッションは別の役割で動きます。まず作業ログと機能の一覧を読んで現在地を確認し、動作を確かめてから続きに取りかかる。毎回少しずつ進め、次が拾える形で記録を残して終わります。人が毎回説明しなくても、同じ手順で再開できる状態を先に用意しているわけです。
GMOインターネットグループ｜開発規律をエージェントが回せる形に作り替える
国内では、GMOインターネットグループが自社の取り組みを公開しています。新しい規律を足したのではなく、これまで人が回していた開発の決まりごとを、エージェントが自分で回せる形へ作り替えた、という整理の仕方が特徴です。
そこで変えたのが、置き場所と担い手です。社内Wikiに文章で貯めていた知識を、機械が読める形式のファイルへ移す。人のレビューで見ていた確認を、操作の直後・変更の確定前・自動検査という3つの速度帯に振り分ける。さらに、ルールの追加や廃止といった運用自体も、エージェントが実行できる形で明示する方針を取っています。
そして根底にあるのが、人だけが感覚で知っている状態を残さない、という原則です。これは、新人に引き継げない業務はAIにも引き継げない、という話と同じことを指しています。言語化されていない判断は、結局のところ誰にも渡せません。
ハーネスエンジニアリングを進める5つのステップ
ハーネスは、はじめに全部そろえるものではありません。困っていることから1つずつ足していく形で組み上がります。ここでは、実際に手を動かす順番を5つのステップで整理します。
繰り返している失敗を1つ選ぶ
最初にやるのは、作るものを決めることではありません。直したい失敗を1つ選ぶことです。
まず、選ぶ基準は繰り返し起きているかどうかに置きます。毎回同じ指摘をしている、同じ場所でやり直しが発生する、決めたはずの書き方が守られない。あるいは、毎回同じ確認を手で入れ直している。そうした再発しているものから手を付けると、効果がすぐに分かります。
このとき、自分1人の困りごとで選ばない方が長続きします。チーム内で何度も出ている失敗なら、作ったハーネスを他の人も使うからです。また、何がどれだけ減ったのかを後から確認できる形で選んでおくと、続けるかどうかの判断もしやすくなります。なお、一度きりで捨てる作業に、わざわざハーネスを作る必要はありません。
暗黙のルールを文章にして書き出す
次に、その失敗の背景にある決まりごとを文字にします。口伝えで共有されている前提を、1つずつ書き出す作業です。
ここが最も手間のかかる工程になります。長くやっているチームほど、明文化されていない判断が積み上がっているためです。この場合はこうする、この条件のときだけ例外にする、といった内容は、たいてい誰かの頭の中にしかありません。例えば、締め日の直前に来た依頼だけ承認者を変える、といった運用は、まず書かれていないものです。
もっとも、判断の基準は単純です。新しく入った人に引き継げないことは、AIにも引き継げません。裏を返せば、引き継ぎ資料として通用する粒度まで書ければ、AIにも渡せます。ここで書き出した内容が、そのままルールや手順書の元になります。
書いたルールを自動で検証できる形に直す
続いて、書いた決まりごとを機械が判定できる形へ直します。文章のままでは、守られたかどうかを誰も確認できないからです。
具体的なやり方は、条件に翻訳することです。読みやすく書く、では判定できません。1つのまとまりを何行までにする、この形式以外のファイルは受け付けない、必須項目が空なら止める。このように数えられる条件へ落とすと、自動で検査できるようになります。
もう1つ大事なのが順番です。何をもって良しとするかは、AIに直させる前に固定しておきます。途中で基準を動かすと、良くなったのか基準が緩んだのかを判断できなくなるためです。もちろん、全部を条件にできなくて構いません。落とし込めなかったものは、人が目で見る項目として残しておきます。
セッションをまたぐ引き継ぎの置き場を決める
そのうえで、作業の記録をどこに残すかを決めます。置き場が決まっていないと、会話が切れるたびに一から説明し直すことになります。
なお、残す内容は3つで足ります。何が終わって何が残っているか、途中で決めたことは何か、どこで詰まったか。例えば、誰かの承認待ちで止まっているものがあるなら、それも残作業として書かせておきます。これをファイルに書き出させ、次のセッションの最初に読ませます。
そして置き場所は、AIが自分でたどり着けるところにします。担当者の手元にあるメモや、チャットの流れの中で決まった話は、AIから見れば無いのと同じです。OpenAIのチームは、エージェントが見つけられない決定事項は、3か月後に入社する新人が知らないのと変わらない、と表現しています。
繰り返された違反をルールに昇格させる
最後は、運用しながら育てる段階です。一度直しただけでは、同じ失敗はまた戻ってきます。担当者が入れ替われば、なおさらです。
そこで、再発したものだけをルールや検査に上げていきます。1回きりの間違いは、その場で直して終わり。2回目が出たら、ルールのファイルに書く。3回目が出たら、機械の検査に組み込む。この順で上げていくと、実害のあるものだけが残り、ルールが無駄に膨らみません。
同時に、落とす作業もセットにします。使われなくなった決まりを残しておくと、AIは古い前提のまま動くからです。ベッケラー氏も、ハーネスを構成する仕事の1つとして、劣化したルールを片付ける役割を挙げています。足すことと捨てることを同じ頻度で回すのが理想です。
開発以外の業務をAIエージェントに任せるときのハーネス設計
ここまでは開発現場の話が中心でしたが、この考え方は、経理や問い合わせ対応といった社内業務にもそのまま当てはまります。渡す業務が決まった後、それを安定して回すために何を用意するのか。3つに分けて考えます。
業務ルールと判断基準をAIが読めるファイルに残す
1つ目は、業務のルールと判断基準をファイルに残すことです。開発でいうルールのファイルの、業務版に当たります。
ただし、書くのは手順だけではありません。むしろ効くのは、例外の扱いです。例えば請求書の突合なら、金額が1円ずれたときに許容するのか差し戻すのか。問い合わせの一次返信であれば、人に回す線引きをどこに置いているか。こうした判断は担当者の経験として蓄積されていることがほとんどで、マニュアルには載っていません。
ここを書き出さないまま渡すと、AIは自分なりの基準で処理します。しかも、その基準は毎回同じとは限りません。まず業務を工程に分け、どの工程にどんな判断が挟まっているのかを洗い出すところから始めるのが確実です。受領、突合、承認、記帳と並べてみると、人の判断が入るのは突合と承認の2つだけ、と見えてくることもあります。
出力の正しさを機械的に確かめる手段を用意する
2つ目は、出てきたものが正しいかを機械で確かめる手段を用意することです。開発にはテストがありますが、社内業務にはそれに当たるものがないため、自分で作る必要があります。
ただし、作り方は業務ごとに変わります。集計なら、元データの合計と一致するかを突き合わせる。書類の作成なら、必須項目が埋まっているか、日付の形式が揃っているかを確認する。いずれも、人が目視でやっていた確認をそのまま自動化するイメージです。
裏を返せば、正しさを確かめる手段を用意できない業務は、まだ丸ごと渡す段階にありません。例えば、社外に出す提案の内容が良いかどうかは、機械では測れないものです。その場合は、AIに下書きまで作らせて、良し悪しの判断は人が持つ形に留めます。
例外が出たときの戻し方と承認者を先に決める
3つ目は、うまくいかなかったときの手当てを先に決めておくことです。具体的には、誰が承認するのか、間違いが出たらどう戻すのかの2点になります。
まず、承認の位置は影響の範囲で決めます。社内向けの集計なら事後の確認で足りますが、社外へ出る文面や金銭が動く処理は、実行する前に人が通す形にします。請求書の発行や顧客への一次返信が、その代表です。ここを決めずに適用範囲だけ広げると、誤りが人の目に触れないまま外へ出ていきます。
そして、戻し方も同じくらい重要です。書き換えた内容を元に戻せるか、送信を取り消せるか、誰が対応するのか。夜間や休日に起きた場合の段取りも同じです。決まっていない状態で任せると、止まったときに復旧できません。丸投げが行き詰まるのは、たいていこの部分です。
ハーネス設計でつまずく6つの失敗パターン
作り始めてから気づく落とし穴もあります。どれも最初の設計が悪かったというより、運用しているうちに少しずつずれていくものです。公開されている報告と実務の両方でよく見かけるものを、6つ紹介します。
完了の条件と確かめ方を決めないまま任せる
1つ目は、完了の条件を決めないまま任せてしまうことです。最もよく起きて、しかも気づきにくい失敗でもあります。エラーで止まるわけではないため、問題が表に出ません。
というのも、何をもって終わりとするかを決めずに渡すと、AIは自分で完了の条件を決めてしまうからです。その結果、見た目は仕上がっているのに、肝心の要件が抜けているものが出てきます。集計表としては整っているのに、頼んだ絞り込み条件が1つ入っていない、といった具合です。
放っておけば、そのまま次の工程へ流れます。誰も止めないため、後になって発覚し、そこから手戻りが始まる。防ぐには、渡す前に完了の条件を具体的に書き、それを確かめる手段まで用意しておくしかありません。集計であれば、対象期間、除外する行、合計を突き合わせる先まで書いておく。条件と確認方法は、必ずセットで決めます。
AI自身の自己評価だけで合否を決める
2つ目は、AI自身の自己評価だけで合否を決めることです。作ったものを本人に採点させると、たいてい合格になります。
実際、Anthropicは自分が出した成果を評価させると、人から見れば明らかに平凡な出来でも自信を持って褒める傾向がある、と報告しています。そこで同社は、作る役と評価する役を別のエージェントに分ける構成を採りました。計画、実装、評価の3つに役割を分けた形です。
興味深いのは、評価役もまたAIである点です。AIが作ったものに甘くなる性質は変わりません。それでも、評価だけを担当させて厳しめに調整する方が、作った本人に自己批判をさせるよりはるかに扱いやすい、とされています。機械の判定を挟むか、別の役に見せるか。どちらかは必ず入れておきます。ただし、最終的に通すかどうかを決めるのは人です。自分で作ったものを自分で検収する体制は、人間の組織でも避けるものです。
失敗の原因を指示文の追記だけで埋める
3つ目は、失敗の原因を指示文の追記だけで埋めることです。うまくいかないたびに一文足して済ませていると、後から収拾がつかなくなります。
もちろん、最初のうちは効きます。しかし追記が増えるほど指示は長くなり、どれが効いているのか分からなくなる。さらに、ある場面を直すために足した一文が、別の場面で以前の挙動を呼び戻すこともあります。以前は出ていなかった余計な確認を毎回挟むようになった、といった形で表れます。原因の切り分けができないまま、指示だけが膨らんでいく状態です。
目安は、同じ失敗が2回出たかどうかに置きます。2回目が出たなら、それは指示の書き方ではなく環境の側の問題です。検査を足す、手順書に落とす、置き場所を変える。直す先を指示文から環境へ移すタイミングが、そこにあります。
ルールと渡す道具を増やしすぎる
4つ目は、ルールと渡す道具を増やしすぎることです。守らせたいことが増えると書き足したくなりますが、量が増えるほど守られなくなります。
現に、OpenAIもすべてを1つの大きな指示ファイルに詰め込む方法は予測どおりに失敗したと述べています。理由は2つあります。AIが一度に読み込める情報量を指示そのものが圧迫してしまうこと。そして、すべてが重要だと書かれていれば、結局どれも重要ではなくなることです。
同じことが、使わせる道具にも起こります。外部ツールとの接続を最初から大量に登録すると、動作が重くなり、費用も上がり、指示に対する精度まで落ちる。必要なものを、必要なときに読ませる形が基本です。しばらく使っていない接続は、思い切って外した方が結果は良くなります。ルールも道具も、足すときは置き場所と優先順位をセットで決めます。
古くなったルールが残り続ける
5つ目は、古くなったルールが残り続けることです。足すことばかり続けていると、使われない決まりが溜まります。AIはそれを区別できないため、古い前提のまま動きます。すでに廃止したはずの手順を、丁寧になぞってくることさえあります。
厄介なのは、壊れた検査が放置される場合です。仕様が変わって検査が通らなくなったとき、直す担当が決まっていないと、エラーが出たまま誰も見なくなります。警告が出ていること自体が日常になってしまい、本当に危ない違反も同じ扱いで流れていきます。
対策は2つです。仕様を変えるときに誰がハーネスを直すのかを先に決めておくこと。そして、使っていない決まりを定期的に落とすこと。ルールを書く作業と同じくらい、捨てる作業に時間を割いているチームの方が、結果としてハーネスは長持ちします。
検証を重ねすぎて実行コストと待ち時間が膨らむ
6つ目は、検証を重ねすぎることです。多いほど安心ではありますが、そのまま費用と時間に跳ね返ります。
費用と時間の差が見えるのが、Anthropicの公開した比較です。最小限の構成で動かすと20分・9ドルで終わった作業が、評価役の分離や記録の永続化まで備えた構成では6時間・200ドルかかりました。20倍を超える差です。ただし同社は、出来上がったものの質の差は一目で分かったとも述べています。壊れているものと動くものの違いであり、実際に動く必要がある用途なら費用は回収できる、という立場です。
つまり、かける先を選ぶという話になります。壊れても影響の小さい作業に、厚い検証は要りません。反対に、社外へ出るものや金銭が動く処理には、費用をかける価値があります。
まとめ
ハーネスエンジニアリングは、モデルを賢いものに取り替える話ではありません。同じAIに、同じ品質で、繰り返し仕事をさせるための環境を作る取り組みです。ガイドで先回りし、センサーで確かめる。この2つを、ルール・スキル・フック・メモリ・フィードバックループという形に落としていきます。
手を付ける順番も難しくはありません。全部をそろえようとせず、いま繰り返している失敗を1つ書き出すところから始めます。その背景にある決まりごとを文字にし、機械が判定できる形に直す。これだけでも、同じ指摘を繰り返す時間はかなり減ります。
作業はAIに任せ、判断は人が持つ。その線引きを支える道具がハーネスです。まずは今週、同じ指摘を2回した場面を1つ思い出すところから始めてみてください。
