エージェントハーネス（agent harness）とは、AIエージェントの「モデル以外の全部」のことです。システムプロンプト、ツールの定義、実行手順、権限、レビューの仕組み。エージェントの品質はモデルだけでは決まらず、この周辺実装の出来で大きく変わります。そして先に結論を言うと、ハーネスは成果物のレビューでは検査できません。成果物が全部PASSしているのに、ハーネス側が静かに壊れている、ということが実際に起きます。私の運用でも起きました。
この記事では、ハーネスという言葉の定義を一次情報で押さえたうえで、「出力の評価」と「ハーネスの評価」がなぜ別物なのか、自社の自動運用で実際に踏んだ回帰の実例と合わせて整理します。想定読者は、AIエージェントを業務に組み込み始めて、「プロンプトやツールを変えたとき、何が悪くなったかをどう検知するか」に不安がある人です。
ハーネスという言葉が定義され始めた
harnessは元々「馬具」で、ソフトウェアでは古くからテストハーネス（テスト対象を囲んで動かす仕掛け）という使い方があります。エージェント文脈のharnessはその延長で、モデルを囲んで動かす実装一式を指します。
この語は2026年9月に入って、大手の技術ブログで立て続けに「定義される側の用語」になりました。GitHubは2026年9月2日のAI用語解説記事で、loops・squadsなどと並べてharnessを定義付きで取り上げています（確認日2026-09-10）。
GitHub公式: Decoding the new AI lingoFrom loop engineering to harnesses, squads, and open weights, the GitHub Podcast breaks down the AI terms showing up in developer conversations.github.blog
そのちょうど1週間後の2026年9月9日には、Googleの開発者ブログが「The Anatomy of Harness Engineering」という記事で、ハーネスの評価方法まで踏み込みました（確認日2026-09-10）。この記事の立場がはっきりしていて、ハーネスは standard software that requires unit and integration testing——つまりユニットテストと結合テストを必要とする、普通のソフトウェアとして扱え、というものです。
Google公式: The Anatomy of Harness EngineeringLearn how to build a robust evaluation harness for AI agents using behavioral evals. Test specific tool calls, automate prompt engineering, and ship with confidence.developers.googleblog.com
プロンプトは書き物ではなくコードであり、変更にはテストが要る。言われてみれば当然ですが、実務でこれをやれている現場は少ないはずです。私もやれていませんでした。その話は後半で。
自分の運用の「ハーネス」を数えてみる
定義だけだと掴みにくいので、私が実際に回しているSNS運用・記事執筆の自動化で、ハーネスに当たるものを棚卸ししてみます。
- 手順ファイル: 各タスクの実行手順を書いたスキル定義。書き手エージェントはこれを読んで動きます
- 審査基準ファイル: 公開可否を判定するルーブリック。基準は会話ではなくファイルに固定しています
- レビュー担当の分離: 書き手とは別の読み取り専用エージェントが、基準ファイルに照らしてPASS/FAILだけを返す構成
- フック: 破ってはいけない操作をコマンド実行の手前で機械的にブロックする層
- 公開回数の上限: 投稿しすぎを防ぐ制限。プロンプトではなくサーバー側に実装しています
- 投稿キュー: 二重投稿を防ぐ排他制御と、投稿状態の記録
並べてみると分かるのは、この一覧にモデルが1つも登場しないことです。モデルを別のものに差し替えても、この一式はそのまま残る。エージェントの振る舞いの再現性を握っているのは、実はこちら側です。そして、ここに挙げたものはすべてただのファイルとコードなので、壊れ方もソフトウェアの壊れ方をします。つまり、変更をきっかけに、静かに回帰します。
出力の評価とハーネスの評価は別物
ここが今日いちばん伝えたい区別です。エージェント運用の「評価」には2種類あって、対象がまったく違います。
1つ目は出力の評価。エージェントが作った成果物（記事、コード、PR）を、公開や採用の前に審査するゲートです。私の運用では、公開原稿を読み取り専用のレビュー担当エージェントが基準ファイルに照らしてPASS/FAIL判定します。この層の設計は別記事に書きました。
AIエージェントの公開前チェックは2層に分ける｜決定的ルールとLLM審査の設計AIエージェントに公開作業を任せるときのチェック機構を「決定的に落とす層」と「LLMに判断させる層」の2層に分けて運用している実装記録。GitHubがalt textチェックで公開した同じ層分けの設計と突き合わせ、誤検知で審査が信用を失わないための逃げ道の作り方、PASSを床として扱う考え方をまとめます。www.tentspace.net
2つ目がハーネスの評価です。Googleの記事はこれをbehavioral evaluation（振る舞いの評価）と呼び、観測可能な振る舞い——曖昧なとき質問を返すか、完了前に検証を走らせるか——を検査対象にします。目的も出力評価とは違い、主目的は回帰の検出です。原文の言い方を借りると、a new prompt tweak, tool schema change, or model upgrade did not make the agent holistically worse——プロンプトの微修正、ツールスキーマの変更、モデルの更新が、エージェントを全体として悪化させていないことを担保する。
「観測可能な振る舞い」という限定が実務的で、ここには含みがあります。エージェントの内心（なぜそう判断したか）を検査対象にすると、判定が主観になって回帰の前後比較ができません。外から数えられるもの——質問を返した回数、検証を走らせたか、実行した本数、守るべき上限との差——に対象を絞るからこそ、変更前と変更後を同じ物差しで比べられる。テストしやすいように対象を観測可能な外形に限定するのは、普通のソフトウェアテストの作法そのままです。
表にするとこうなります。
| 出力の評価 | ハーネスの評価 | |
|---|---|---|
| 検査対象 | 成果物（記事・コード・PR） | 周辺実装（プロンプト・手順・ツール定義） |
| 問い | この成果物は世に出してよいか | 変更後も同じ振る舞いをしているか |
| タイミング | 成果物ができるたび | ハーネスに変更を入れる前後 |
| 検出できるもの | 品質の低い1件 | 全件に効く静かな劣化 |
重要なのは右の列は左の列で代用できない、という点です。出力ゲートは「1件ずつの品質」しか見ていないので、どの成果物も個別には合格ラインを超えているが、エージェントの振る舞いが指示からずれている、という壊れ方を素通しします。
全部PASSなのに、指示が2週間守られなかった
抽象論に聞こえると思うので、自社で実際に起きた回帰をそのまま書きます。
私はSNS運用と記事執筆を複数のエージェントに任せていて、週次で成績を分析し、翌週の実験指示（例: 投稿は週10本以内に絞る、告知は週1本まで）を運用ページに書き出す仕組みを回しています。書き手のエージェントたちは、この指示を読んで動く建て付けです。
ところが週次の実測を集計すると、指示「週10本以内」に対して実際の投稿は20本。別の指示「この型の告知は週1本まで」に対して実際は5本。指示が書き手の振る舞いにまったく反映されない状態が、2週連続で続いていました。
この間、公開前の出力ゲートは正常に働いていて、個々の投稿はすべてPASSです。当然で、レビュー担当が見ているのは「この1本が公開基準を満たすか」であって、「今週何本目か」「先週の指示に従っているか」ではない。品質ゲートの網目より大きい壊れ方は、網にかかりません。
回帰が発覚したのは、成果物のレビューではなく週次の実測集計でした。投稿本数という観測可能な振る舞いを数えていたから、指示とのずれが数字で見えた。もし集計がなければ、全部PASSの緑のダッシュボードを眺めたまま、指示が空文化していることに気づけなかったはずです。
Googleの記事の言葉に引き付けるなら、これはbehavioral evaluationがハーネスの回帰を検出した実例です。ただし自慢できる話ではなく、検出が週次の集計頼みなので、回帰を入れた瞬間ではなく、集計日にようやく気づく。実際、指示が反映されない状態は2週分の集計をまたいで続きました。検知の仕組みはあったのに、検知から是正までの周期が長すぎた、という設計です。
後日談も数字で書いておきます。検出後に指示を出し直したところ、翌週の投稿は20本から11本へ半減し、1本あたりの閲覧数の中央値は18から20へ、3週ぶりに反転しました（週次実測・2026-09-09集計分まで）。本数と中央値の因果はまだ確定と呼べる段階ではありませんが、ここで言いたいのはその手前の話です。振る舞いを数える指標は、回帰の検出と、修正が効いたことの確認の両方に、同じ物差しで使えた。 数えていなければ、壊れたことにも、直ったことにも、気づけません。
回帰を数える側の設計、いま置いているもの
この経験を踏まえて、私がハーネス側の検査として現実的だと考えている置き場所は3つです。いずれも大掛かりな評価基盤ではなく、いま動いている仕組みの延長に置けます。
1. 破ってはいけない線は、評価ではなくコードで強制する。 「テストを skip しない」「本番へ直接 push しない」級のルールは、振る舞い評価で検出する対象ではなく、フックや権限設定で物理的に不可能にする対象です。検査より禁止が安い。この層の実装記録は別記事にまとめています。
Claude Codeのhooksで自動運用に禁止ラインを引く｜Bashガード実装記録Claude Codeのhooksで、エージェントに破らせたくない操作をコードとして強制する実装記録。PreToolUseフックの設定、Bashコマンドを検査するガードスクリプト、exit code 2でブロックする仕組み、正規表現ルールの設計と限界まで、実運用中の構成をそのまま解説します。www.tentspace.net
2. 指示には、従われているかを数える指標を必ず対にする。 「週10本以内」という指示を出すなら、週の投稿本数という数え方をセットで決める。指標のない指示は、守られなくても誰も気づかないので、書いた時点で空文化のリスクを抱えます。私の失敗はまさに、指示だけ書いて数える側を週次に置いたことでした。頻度は運用の重さと相談ですが、指示の重要度が高いものほど検知を早くする価値があります。
3. ハーネスを変えたら、変更前後で振る舞いを比べる。 プロンプトや手順ファイルの変更は、コードと同じく差分レビューとセットの検証を通す。Googleの記事が言うunit and integration testingをエージェント運用に引き付けると、ユニットテストに当たるのは決定的に判定できる検査——禁止コマンドが実際にブロックされるか、審査基準ファイルが想定の場所から読めるか——で、結合テストに当たるのは「変更後に1回実行して、振る舞いが指示の通りに変わったかを見る」ことだと私は解釈しています。最小版は後者だけでも成立します。変更した指示が、次の実行1回で実際に反映されたかを確認してから離れる。私の回帰も、指示を書いた翌日に1回数えていれば、2週間ではなく1日で捕まえられました。
モデルの進化はハーネスの劣化を隠す
最後に、なぜこの話が今のタイミングで重要だと考えているかを書きます。
モデルは数か月ごとに賢くなります。すると、ハーネスが多少壊れていても、モデルの底上げで成果物の見た目は保たれてしまう。出力ゲートだけを見ていると「品質は維持できている」ように見えたまま、周辺実装の劣化が蓄積します。逆に言うと、モデル更新のたびに得られるはずの改善幅を、壊れたハーネスが静かに食っている可能性がある。
ハーネスは普通のソフトウェアとして扱う。成果物のレビューとは別に、振る舞いを数える検査を持つ。破られたら困る線はコードで強制する。この3点が、いま私がエージェント運用の設計で優先している順番です。
エージェント運用で実際に踏んだ失敗の全体像は、SNS自動化を全部任せた2週間の記録にまとめています。今回のハーネス回帰は、あの記録の「観測と事実の問題」の延長線にある話です。