AIエージェントの品質が上がらないとき、多くの現場はプロンプトを直しに行く。しかし実際に成果を分けているのは、モデルの内側ではなく外側であることが多い。
エージェントが呼べるツールは何か。生成物の合否を誰がどう判定するか。何をコンテキストに渡し、何を捨てるか。どこまでの操作を許すか。このモデルの外側にある仕組み全体がハーネスであり、その設計がハーネスエンジニアリングである。
Anthropicは長尺タスクのハーネス設計を扱った記事で、生成と評価を同じエージェントにやらせるべきではないと述べている。モデルは自分の成果物を「人間の目には明らかに凡庸な品質であっても、自信を持って称賛する」傾向があるためだ。品質保証をモデル自身の内省に委ねている限り、この壁は越えられない。
この記事の対象読者
- エージェントを実装したものの、品質が安定せずプロンプト調整を繰り返している開発者
- AIによる自動化の成果物をどう検収するか決めかねている推進担当者
- 社内でAIエージェントの運用ルールを整備する必要があるプラットフォームチーム
- ループエンジニアリングとハーネスエンジニアリングの関係を整理したい方
ハーネスとは「モデルの外側の全部」
ハーネスは日本語で「装具」「拘束具」を指す語で、暴れる馬に付ける馬具が語源である。AIの文脈では、モデルという不確実な生成装置を、業務で使える出力に収束させるための外部構造を意味する。
| 構成要素 | 何を決めるか | 典型的な実装 |
|---|---|---|
| ツール | モデルが呼べる操作の集合 | ファイル操作、API呼び出し、検索、コード実行 |
| 検証 | 合否の決定論的な判定 | 型チェック、テスト、リンタ、スキーマ検証 |
| 評価 | 主観的な品質の採点 | 生成とは別主体による基準ベースの採点 |
| コンテキスト | 何を渡し、何を捨てるか | リセットと構造化された引き継ぎ |
| 権限 | 実行してよい操作の境界 | サンドボックス、承認ゲート、ドライラン |
この5つが揃って初めてエージェントは業務に載る。 どれか1つでも欠けると、それが品質の上限になる。
なぜモデルではなくハーネスが品質を決めるのか
同じモデルを使っても、成果は現場によって大きく違う。理由は単純で、モデルの能力は全員に等しく配られるが、ハーネスは自社で作るしかないからだ。
モデルは共通の入力である。競合他社も同じモデルを使える。差がつくのは、そのモデルに何を見せ、何をさせ、どう検収するかという外側の設計であり、ここは業務知識が要る領域である。モデルの進化を待つのではなく、外側を作り込むほうが早く効く。
もう1つの理由は再現性である。プロンプトの調整は結果が確率的にしか改善しないが、型チェックやテストは決定論的に不合格を弾く。「たいてい正しい」を「必ず条件を満たす」に変えられるのは検証側だけである。
原則1：生成と評価を分ける
最も効果が大きく、最も見落とされる原則である。
同じエージェントに作らせて採点させると、自分の出力に甘い評価が返ってくる。これは能力の問題ではなく、生成に使った文脈の中で評価しているからである。確証バイアスは人間と同じ形で起きる。
対処は構造で行う。
- 評価は別コンテキストで起動する。 生成の履歴を持たない主体に、成果物だけを渡して採点させる
- 成果物はファイル経由で渡す。 会話の続きとして渡すと生成側の文脈が混入する
- 評価基準を事前に明文化する。 Anthropicの記事は、デザイン作業の評価軸として「デザイン品質」「独自性」「作り込み」「機能性」といった具体的な基準を挙げている。主観的な良し悪しを測定可能な軸に変換することで、反復のたびに一貫した採点ができるようになる
- 基準にはGood例とBad例を添える。 判断のドリフトを防ぐ
重要な成果物ほどこの分離が要る。本番コードや顧客向けドキュメントを、生成したのと同じ文脈での自己評価で通してはいけない。
原則2：品質は文書ではなく決定論的ツールで強制する
「規約に書いてあるのに守られない」という状況は、ハーネス設計の失敗である。
文書はモデルにとって参考情報にすぎないが、リンタとテストは通らなければ先に進めない壁になる。 品質基準は文書ではなく実行可能な形に落とす。
フィードバックは速い層に寄せるほど効く。編集直後に走るフックはミリ秒で返り、コミット前のチェックは秒、CIは分、人間のレビューは時間から日を要する。同じ間違いなら、より速い層で潰したほうが総コストは小さい。 この階層設計の詳細はループエンジニアリング入門で扱っている。
実務で効く順序は次のとおりである。
- 型で表現できるものは型にする。 説明文より腐りにくく、違反が即座に分かる
- 一度起きた失敗はテストかリンタルールにする。 同じ失敗が二度起きない仕組みは複利で効く
- 文書は「コマンド・パス・禁止事項」に絞る。 説明文書は読まれず腐る
原則3：コンテキストは圧縮より完全リセット
長尺のタスクでは、会話履歴が膨らんで一貫性が落ちていく。ここで履歴を要約して圧縮する方法が一般的だが、Anthropicの記事は圧縮より、完全なコンテキストリセットと構造化された引き継ぎのほうが長尺タスクの一貫性を保てるとしている。
圧縮は「何が重要か」の判断をモデルに委ねる操作であり、失われる情報の制御ができない。一方でリセット＋引き継ぎは、次のセッションに渡す内容を人間または別の仕組みが決められる。
実装は難しくない。
- 中間成果物をファイルに書き出す（計画、評価結果、エラーログ、決定事項）
- 次のセッションはその引き継ぎファイルから始める
- 引き継ぎファイルの様式を固定する
副次的な効果として、コンテキストが飛んでも作業が続行できる設計になる。 30分以上かかるタスクは、この形にしておくと途中で止まっても損失が小さい。
原則4：ハーネスは足す技術ではなく削る技術
ここが本質であり、最も誤解されている点である。
ハーネスの各構成要素は、「モデルがこれを自力ではできない」という仮定を符号化したものである。制約を1つ足すたびに、その仮定が固定される。
問題は、モデルが良くなってもその仮定が残り続けることだ。2年前のモデルでは必要だった保険的な指示、二重チェックの要求、細かい手順の指定が、現行モデルでは冗長どころか有害になる。過剰な制約は探索を狭め、かえって性能を下げる。
Anthropicの記事も、モデルが改善するにつれてハーネスから不要な構成要素を剥がしていくべきだと述べている。
棚卸しの実務
四半期に一度、次を問う。
- この制約は今も必要か。 モデルが自力で回避できるようになった失敗へのガードは外す
- このフックは実際に発火しているか。 発火実績のないフックは仮定が古い証拠である
- この指示文はモデルの内部処理と重複していないか。 「ダブルチェックしろ」「再確認しろ」のような保険文言は、モデル側の検証と重複して過剰なループを誘発することがある
- 削って何が起きるか実測したか。 「無いと不安」で残さない
ハーネスは放っておくと単調に増える。 課題が見つかるたびに制約が足され、削る動機は誰にも無いからだ。棚卸しを定期作業として組み込まない限り、ハーネスは必ず肥大化する。
ループエンジニアリングとの違い
この2つは競合する概念ではなく、内側と外側の関係にある。
| ループエンジニアリング | ハーネスエンジニアリング | |
|---|---|---|
| 対象 | エージェントが回る循環そのもの | 循環の外側にある構造 |
| 主な設計対象 | 観測・判断・行動の3層、停止条件 | ツール、検証、評価、コンテキスト、権限 |
| 問い | 「どう回し続け、どこで止めるか」 | 「何を使わせ、何をもって合格とするか」 |
| 失敗の症状 | 止まらない、無限リトライ、暴走 | 動くが品質が安定しない、検収できない |
ループはエンジンで、ハーネスは車体である。 エンジンだけでは走らず、車体だけでは動かない。
実務での着手順は症状で決まる。エージェントが止まらない・暴走するならループ側の停止条件から。動くが品質が読めない・検収できないならハーネス側の検証と評価から着手する。
ループ側の設計はループエンジニアリング入門で体系的に扱っている。
アンチパターン
プロンプトに保険文言を積む。 「必ず確認すること」「慎重に検討すること」を足しても品質は上がらない。検証で弾くべきものを言葉で頼んでいる状態である。必要なら明示的な検証ステップとして別に置く。
自己評価を最終判断にする。 生成した文脈での自己採点は通ってしまう。重要な成果物ほど別コンテキストの評価を挟む。
同じエラーへの無限リトライ。 2回失敗したら人間に返す。リトライを重ねるほど効果は減衰し、トークンだけが溶ける。
100%を目指してループを回し続ける。 8割で人間に渡すほうが、残り2割にトークンを注ぎ込むより速い場合が多い。修正ループの上限を決めておく。
検証なき委譲。 エージェントに任せた成果を、実行結果を見ずに「完了」と扱う。テスト・ログ・画面のいずれかで確認するまでは完了ではない。
FAQ
Q1. ハーネスエンジニアリングとプロンプトエンジニアリングは何が違うか？
プロンプトエンジニアリングはモデルへの入力を設計する技術で、ハーネスエンジニアリングはモデルの外側の構造を設計する技術である。プロンプトは確率的にしか効かないが、ハーネスの検証層は決定論的に効く。 品質を「必ず条件を満たす」水準にしたいなら、プロンプトではなくハーネス側で担保する。
Q2. 小さなチームでもハーネスは必要か？
必要である。ただし最初から5要素すべてを揃える必要はない。まず検証（型チェックとテスト）から始めるのが投資対効果が高い。評価の分離は、成果物の重要度が上がってから足せばよい。
Q3. 評価用のエージェントを別に立てるコストは見合うか？
成果物の手戻りコストと比較して判断する。本番コードや顧客向け成果物のように、間違いが外部に出ると損害が発生するものは見合う。内部の使い捨てスクリプトには要らない。判断軸は「間違いが誰に届くか」である。
Q4. コンテキストのリセットと引き継ぎは、具体的に何をファイルに書くのか？
目的、制約、これまでの決定事項と理由、未解決の課題、次にやること、検証条件の6つを型として持つとよい。「なぜそう決めたか」を落とすと、次のセッションが同じ議論を繰り返す。
Q5. ハーネスを削るとき、何を基準に判断するか？
「削って実際に失敗するか」を測る。 不安を基準にすると何も削れない。制約を外した状態で通常のタスクを走らせ、失敗が再現するなら戻す。再現しないなら、その制約は古いモデルの前提だったということである。
Q6. 発火していないフックは本当に消してよいか？
発火実績が無い理由を先に確認する。設定ミスで動いていないだけなら直す。正しく設定されていて発火しないなら、そのガードが守っていた失敗はもう起きていない。「念のため残す」を続けると、どのガードが生きているか誰も分からなくなる。
Q7. ハーネスの良し悪しはどう測るか？
再現性で測る。同じ入力に対して結果の分散が小さいこと、失敗したときに原因が特定できること、同じ失敗が二度起きないこと。「たまたま上手くいった」が減っていれば、ハーネスは効いている。
次に読むべき記事
- ループエンジニアリング入門｜自律エージェントを動かし続けるハーネス設計の体系 — 循環そのものの設計と停止条件
- LLMトークン節約5パターン｜本番運用でコストを70%削るハーネス設計 — ハーネスのコスト側
- マルチエージェント実装ガイド｜協調・分業の設計パターンと運用設計 — 分解と専門化の実装
- LangGraph実装入門｜エンタープライズのAIエージェント構築フレームワーク — 実装フレームワーク
まとめ
- ハーネスとは、ツール・検証・評価・コンテキスト・権限というモデルの外側の構造全体を指す。品質を決めているのは中心ではなく外側である
- モデルの能力は全員に等しく配られる。差がつくのは自社で作るハーネス側である
- 生成と評価は分ける。 同じ文脈での自己評価は甘い採点を返す。評価は別コンテキストで、明文化された基準とGood/Bad例を添えて行う
- 品質基準は文書ではなく決定論的ツールで強制する。フィードバックは速い層に寄せる
- 長尺タスクは履歴の圧縮より、完全リセットと構造化された引き継ぎのほうが一貫性を保てる
- ハーネスの各構成要素は「モデルにできないこと」の仮定である。 モデルが良くなったら削る。棚卸しを定期作業にしない限りハーネスは必ず肥大化する
- ループは内側のエンジン、ハーネスは外側の車体。症状で着手順を決める
FDXのエージェント実装・運用支援
FDXはAX（AI Transformation）の実装パートナーとして、エージェントの実装だけでなく、検証・評価・運用移管までを含めて設計する。「動くものは作れたが、業務で使える品質に届かない」段階で止まっている場合、原因はモデルではなくハーネス側にあることが多い。
現状の業務とAIの適用範囲を分解するところから始めたい場合はAX診断を、実装体制の相談はお問い合わせからどうぞ。
出典・参考文献
- Anthropic Engineering Blog「Harness design for long-running application development」（生成と評価の分離、評価基準の具体化、コンテキストリセット、モデル改善に伴うハーネスの簡素化）
- Andrej Karpathy「autoresearch」（Modify → Verify → Keep / Discard → Repeat の自律反復。2026年3月公開）