同じモデルを使っているのに、チームによって成果物の品質が異なります。一方ではAIがリファクタリングを丸ごとやり遂げ、もう一方では簡単な修正さえ人がすべて書き直しています。
違いはプロンプトの文言ではありません。モデルを包む実行環境、つまりハーネスの違いです。
ハーネスエンジニアリングを一言でいえば、モデルがツールを使い、結果を検証されながら作業するループ全体を設計する仕事です。プロンプトエンジニアリングが「うまく話しかける方法」なら、ハーネスエンジニアリングは「仕事ができる作業場を用意する方法」です。
この記事では、ハーネスとは何か、その構成要素は何か、そして優れたハーネスを判断する基準まで整理します。
まずは要点から見ていきましょう。
- ハーネスはモデルを包む実行ループです。構成要素はツール、権限、コンテキスト管理、フィードバックです。
- エージェントの性能は、モデルの知能 × ハーネスの品質で決まります。
- 優れたハーネスの核心は、モデルが自分の結果を自ら確認できるフィードバックループです。
- Claude CodeやCursorのようなコーディングエージェントの実体は、まさにハーネスです。
ハーネスとは正確には何か
もともとハーネスは、馬に装着する馬具を意味します。馬の力そのものを強くするのではなく、その力を荷車を引くという有用な仕事に変換する装置です。
テストハーネスという用語も同じ系譜にあります。
LLMハーネスも同じです。モデル（知能）はそのままに、知能が実際の作業につながるよう包み込むソフトウェア全体を指します。
具体的には次のようなものです。
- ツール層：モデルが呼び出せる関数。ファイルの読み書き、シェルの実行、検索など。
- 権限層：何を確認して実行するか、何を自動承認するかに関するポリシー。
- コンテキスト層：何をモデルに見せ、何を隠し、いつ要約するか。
- ループ層：ツールの結果を次の行動につなげる反復構造と終了条件。
Claude CodeやCursorを「AIコーディングツール」と呼びますが、モデル自体はAPIの背後にある同じモデルです。製品の実体はハーネスです。
性能 = モデル × ハーネス
同じモデルでもベンチマークスコアが大きく分かれる例は、すでによくあります。エージェントベンチマークのリーダーボードを見ると、同一モデルでもハーネスによって成功率が数十パーセントポイントも異なります。
理由は単純です。エージェントの作業は数十回のツール呼び出しが連続する連鎖であり、ハーネスはそのすべての段階に介入するからです。
| ハーネスが悪い場合 | ハーネスが良い場合 |
|---|---|
| ツールの結果全体をコンテキストに流し込む | 必要な部分だけを要約して渡す |
| 失敗しても同じ試行を繰り返す | エラーメッセージを次の試行の入力にする |
| 作業完了をモデルの主張で判定する | テストとビルドで検証し、通過してから終了する |
モデルは確率的に間違えます。ハーネスの役割はミスをなくすことではなく、検証段階でミスを見つけ、モデル自身が修正できるようにすることです。
優れたハーネスの3つの条件
実務の観点では、ハーネスの品質を分ける条件は3つに集約できます。
1つ目は、検証可能なフィードバックループです。モデルがコードを修正したら、テストを実行して結果を見せる必要があります。
人もコンパイルせずに書いたコードを信頼できないように、フィードバックのないエージェントは自己確信だけを積み上げます。エージェント導入の効果が最も大きいのが、テストの整ったコードベースである理由です。
2つ目は、コンテキスト予算の管理です。コンテキストウィンドウは有限なのに、ツールの結果は無限に流れ込んできます。
長い出力を削り、古い内容を要約し、探索作業をサブエージェントに隔離するのがハーネスの役割です。
3つ目は、安全な失敗経路です。権限ポリシーとサンドボックスで「失敗しても復旧できる範囲」を定義する必要があります。
元に戻せる操作は自動承認し、破壊的な操作だけ人に確認する、といった形です。
プロンプトエンジニアリングとの関係
プロンプトエンジニアリングが役に立たなくなったという話ではありません。扱う層が違うだけです。
プロンプトは1回のリクエストを最適化します。ハーネスは、数十回のリクエストが続くループを最適化します。システムプロンプトの作成は、ハーネス設計の一部になります。
関心の中心が「何を言うか」から「どんな環境を与えるか」へ移ったのです。モデルが良くなるほど、この傾向は強くなります。指示は短くてもよい一方、ツールと検証ループの価値はむしろ高まるからです。
まとめ
エージェントの成果物に不満があるなら、プロンプトを調整する前にハーネスを点検してみてください。モデルが結果を確認できる手段はあるか、コンテキストが雑多な情報で埋まっていないか、失敗が次の試行につながっているか。
次の記事では、このうちコンテキスト層を深掘りするコンテキストエンジニアリングを扱います。