PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
ハーネスエンジニアリングとは、モデルの外側にある実行系を設計対象として扱う考え方です。ハーネスとは、モデルの周りでひとつのタスクの実行を組み立てる仕組みを指します。
AIエージェントの成否は、モデル単体の賢さではなく、モデルと実行系の相互作用で決まります。同じモデルを使っていても、渡す指示、触れる道具、動いてよい範囲、間違いに気づく仕組みが違えば、出てくる結果は変わります。
本記事は、ハーネスを指示・ツール・実行環境・検証・観測の5つに分けて整理します。
- ハーネス＝モデルの外側で、ひとつのタスクの実行を組み立てる仕組み
- エージェントの性能は、モデル単体ではなくモデルと実行系の相互作用から立ち上がる
- 最初に置くのは、停止条件・実行の境界・機械的な合否判定の3つ
ハーネスエンジニアリングとは何か？
ハーネスとは、モデルの外側にあって、ひとつのタスクの実行を組み立てる外部の実行システムです。arXivで公開された論文は、エージェントの性能が周囲のハーネスに強く形づくられると述べ、この層をモデルと同じ設計の対象として扱うことを提案しています。
定義は論文の1文にあります。2026年にarXivで公開された論文「Natural-Language Agent Harnesses」は、エージェントの性能は周囲のハーネス、すなわちひとつのタスク実行を組み立てるモデル周辺の外部の実行システムに強く形づくられる、と述べています。
同じ論文は現状の課題も挙げています。実行を組み立てる論理は通常、密結合したコントローラのコードに埋もれており、そのためハーネスは点検すること、比較すること、他へ移すこと、要素を外して効きを確かめることが難しい、という指摘です。
「ハーネスをスケールさせる」という言い方の出所も論文です。2026年にarXivで公開された論文「From Model Scaling to System Scaling: Scaling the Harness in Agentic AI」は、その意味を、基盤モデルの周囲にある構造化された実行層を、設計・評価・最適化の一級の対象として扱うことだと定義しています。
エージェントの作りそのものが同じ構図を指しています。Anthropicは技術記事「Building effective agents」で、エージェントとは典型的には、環境からのフィードバックにもとづいて道具を使うLLMをループさせたものだと述べています。ループを回す道具、道具が触れる環境、フィードバックが返る経路のすべてがハーネスにあたります。
本記事は、実務で手を入れる単位としてハーネスを5つに整理します。
| 要素 | 何を決めるか | 抜けると起きること |
|---|---|---|
| 指示 | 何をどこまでやるか | 範囲のずれた作業を延々と続ける |
| ツール | 何を触れるか | できるはずのことができない |
| 実行環境 | どこまで触れてよいか | 触ってはいけないものに届く |
| 検証 | 終わったかを何が判定するか | 間違ったまま先へ進む |
| 観測 | 何をしたかが残るか | 失敗しても原因を特定できない |
この5つの区切り方は本記事の整理であり、論文の分類そのものではありません。2本の論文はそれぞれ別の切り方をしており、本記事の5つはどちらとも一致しません。
論文の切り方は次のとおりです。「From Model Scaling to System Scaling」は基盤モデルを含む6つの層でエージェントを記述し、「Natural-Language Agent Harnesses」はエージェント呼び出し・引き継ぎ・状態の更新・検証の関門・成果物の取り決めという5つの要素でハーネスを記述しています。
論文の分類は、研究の対象を切り出すための単位です。本記事の5つは、うまく動かないときに手を入れる場所を探すための単位として、実行時に何が起きるかを基準に切り直しています。
モデルは入れ替わりますが、外側の実行系は残ります。作り込んだハーネスは今後のモデルの変化にも耐える、というのが私の実務での見方です。
重要な業務ほど、ハーネスの作り込みは資産になります。私はそこを、一度きりの実装ではなく積み上げる対象として扱っています。
エージェントそのものの定義と、ワークフローとの違いは本記事の対象外です。どんな場合にエージェント化すべきかを含めて、AIエージェントとは？ワークフローとの違いと実務で使う条件で扱っています。
なぜ同じモデルでも、ハーネス次第で結果が変わるのか？
エージェントの性能が、モデル単体ではなくモデルと実行系の相互作用から立ち上がるためです。arXivで公開された論文は、性能が基盤モデル・記憶の基盤・コンテキストの構成部・スキルの振り分け層・オーケストレーションのループ・検証と統治の層という6つの相互作用から現れると述べています。
論文の主張は具体的です。「From Model Scaling to System Scaling」（2026年・arXiv）は、エージェントの性能が上記6つの層の相互作用から立ち上がり、それらがまとめてエージェントのハーネスを形づくると述べています。同じ論文は、ハーネスとはモデルの能力を長い時間軸の振る舞いへ翻訳するものだ、とも書いています。
測り方の偏りも同じ論文が指摘しています。エージェントの評価はいまだにモデル中心にとどまり、成果を最終タスクの成否へ還元しがちで、記憶・検索・ツール利用・オーケストレーション・検証・統治は二次的な実装の詳細として扱われがちだ、という指摘です。
実行中に何が効くかについてはAnthropicが述べています。同社は「Building effective agents」で、実行中にエージェントが各ステップで環境から「グラウンドトゥルース」を得ることが決定的に重要であり、ツール呼び出しの結果やコード実行の結果がそれにあたるとしています。
ここから失敗の切り分け軸が引けます。この仕組みから考えると、判断そのものの質が足りない失敗はモデルを替えれば直り、実行系が欠けていることによる失敗はモデルを替えても直りません。
実行系の欠落は4つの形で現れます。必要な情報が渡っていない、触れる道具が無い、間違いに気づく仕組みが無い、途中で止まる条件が無い、の4つです。4つのいずれもモデルの選定では解けません。
論文も同じ方向を示しています。「From Model Scaling to System Scaling」は、エージェント分野の今後の進展は、より強い基盤モデルと同じくらいシステム設計に依存する、と結論づけています。断定された業界の合意ではなく、査読前の論文が示す主張として扱う必要があります。
例えば、社内文書を検索して問い合わせに答えるエージェントが、根拠のない回答を返し続ける、という状態が考えられます。想定例として、検索結果が空のときも同じ形式で回答を組み立てられる作りになっていれば、モデルを替えても回答が根拠を持つようにはなりません。
モデル選定そのものの判断軸は本記事の対象外です。企業でLLMを活用する時にどのLLMを選択するべきか？で整理しています。
検索して答える構成で正しい答えが返らないときの原因の切り分けも、本記事では扱いません。検索・データ・生成のどこで落ちているかを順に見る手順はRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで整理しています。
エージェントに渡す道具は、どこまで作り込めばよいのか？
人間向けの画面に注ぐのと同じだけの労力を、エージェント向けのインターフェースに注ぎます。Anthropicはこれをエージェント・コンピュータ・インターフェース（ACI）と呼び、十分なツールのドキュメントとテストを通じて丁寧に作り込むよう勧めています。
投資量の目安まで示されています。Anthropicは「Building effective agents」で、人間向けのインターフェース（HCI）にどれだけの労力がかかっているかを考え、良いエージェント向けインターフェース（ACI）を作ることにも同じだけの労力を注ぐ計画を立てるべきだ、という経験則を挙げています。
ACIという語は、日本語の解説ではほとんど使われていません。画面の文言・入力の順序・エラーメッセージを人間向けに何度も直すのと同じ手数を、ツールの名前・説明・引数・返り方に対しても払う、という考え方です。
ツールは書いて終わりではありません。同じ技術記事は、モデルが自分のツールをどう使うかをテストせよと述べ、多数の入力例を流してモデルがどんな間違いをするかを見て反復することを勧めています。
実行におけるツールの位置づけも公表されています。Anthropicは「Building agents with the Claude Agent SDK」で、ツールがエージェントの実行の主要な構成ブロックだとし、シェルが汎用の道具として、コンピュータを使った柔軟な作業を可能にする点で有用だとしています。
出力の形についても同じ資料に記述があります。コードは正確で、組み合わせが利き、無限に再利用できるため、エージェントの出力として理想的である、という説明です。
道具の作り方には2つの方向があります。用途ごとに専用のツールを1つずつ足す作り方と、シェルのような汎用の実行手段を1つ渡す作り方です。
2つはトレードオフの関係にあります。この仕組みから考えると、専用ツールは触れる範囲が定義から明らかな一方で用途ごとに増え続け、汎用の実行手段は柔軟な代わりに、触れてよい範囲を実行環境の側で決めておくことが前提条件になります。
作り込みの成否を分けるのは、ツールの設計です。何をどう呼べるかをシンプルかつ明示的な形に保つところに、私はいちばん手をかけます。
用途がひとつに収まらないときは、モードとして切り替える設計にします。私の実務では、モードごとに使うツールを分けておくと、エージェントが選ぶ先に迷わなくなります。
ツールをいくつまで渡すか、返り値をどう設計するかは、コンテキストの設計側のテーマです。渡す情報の取捨選択と維持の考え方はコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で扱っています。
エージェントを動かす実行環境は、どこまで囲えばよいのか？
ファイルとネットワークを別々に囲い、その境界をOSに強制させます。境界の内側は一つずつ承認を求めずに動かし、外へ出るときだけ人を呼びます。OpenAIは、この境界こそが、マシンへの無制限のアクセスを与えないままエージェントを自律的に行動させるものだとしています。
定義はOpenAIが明快に書いています。同社はコーディングエージェントCodexの公式ドキュメントで、サンドボックスとは、マシンへの無制限のアクセスを与えることなくエージェントが自律的に行動できるようにする境界である、と述べています。
仕組みの説明はAnthropicの公式ドキュメントが具体的です。同社は開発者向けエージェントClaude Codeのサンドボックス機能について、コマンドを一つずつ承認する代わりに、コマンドが触れてよいファイルとネットワークのドメインを先に定義し、OSがその境界をすべてのコマンドと子プロセスに対して強制する、と説明しています。
囲いは2層に分かれます。同じドキュメントは、サンドボックスが2つの独立した層を持ち、ファイルシステムの分離が読み書きできるパスを、ネットワークの分離が到達できるドメインを制御する、と述べています。
既定の境界も示されています。既定では、サンドボックス内のコマンドは作業ディレクトリとセッションの一時ディレクトリにだけ書き込めます。新しいネットワークのドメインが必要になった最初の一度だけ、承認が求められる仕組みです。
囲いの外へ出る経路も残されています。サンドボックス内で実行できないコマンドは、通常の権限確認の流れへ戻る、という設計です。
承認はどこで人に求めるべきか？
境界の内側では求めず、境界を越えるときに求めます。OpenAIは囲いの強さを3段階に、承認を求める方針を3種類に分けており、2つの組み合わせで人を呼ぶ頻度が決まります。囲いを弱いままにするほど、承認の回数が増えます。
| 囲いの強さ | エージェントにできること | 人を呼ぶ場面 |
|---|---|---|
| 読み取りのみ | ファイルを調べる | 編集とコマンド実行のたび |
| 作業領域への書き込み | 作業領域の中で編集し、定型のコマンドを実行する | 作業領域の外へ出るとき |
| 制限なし | 制限なく実行する | 呼ばない |
承認の方針も3種類あります。OpenAIの公式ドキュメントは、信頼済みでないコマンドの前に尋ねる方針、境界の内側では止まらず境界を越えるときだけ尋ねる方針、承認のために止まらない方針の3つを挙げています。
境界を先に決める狙いは、承認の回数を減らすことです。同社は、サンドボックスが承認疲れを軽減すると述べ、低リスクな操作を一つずつ確認させる代わりに、すでに承認された境界の内側であれば、ファイルの読み取り・編集・定型のプロジェクトコマンドの実行を任せられるとしています。
人を呼ぶ場面自体は消えません。Anthropicは「Building effective agents」で、エージェントがチェックポイントや行き詰まりに当たったところで、人のフィードバックを待って止まる形を挙げています。
承認をすべて人に投げる設計では、人が律速になります。この仕組みから考えると、境界を先に決めておくほど自律の幅を広げても安全側に倒せる一方、境界を決めないまま自律だけを広げると、承認の回数が増えて結局は人が全部見ることになります。
囲いは止めるためだけのものではありません。Anthropicの公式ドキュメントは、サンドボックスがアクセスを拒否してコマンドが失敗したとき、どのファイルパスやネットワークホストが遮断されたのかという違反の詳細を、失敗したコマンドの出力に付け足し、モデルがそれを読めるようにする、と述べています。
この仕組みから考えると、実行環境は検証の一部でもあります。境界に当たった事実が機械的な形で返ってくれば、エージェントは次の一手を人に聞かずに選び直せます。
例えば、社内のリポジトリでテストを流しながらコードを直させる構成が考えられます。想定例として、書き込み先をそのリポジトリのディレクトリに限り、到達してよい接続先を社内のパッケージ配布先だけに絞れば、コマンドごとの承認を求めずに走らせても、囲いの外に影響は出ません。
本記事が扱うのは、1体のエージェントが動く実行の境界です。組織として複数のエージェントに識別子を与え、権限の範囲や実行の記録をどう管理するかは、別のレイヤーのテーマになります。
エージェント自身に、どうやって作業を検証させるのか？
実行のループの中に、機械的に合否が決まるフィードバックを差し込みます。Anthropicは最良のフィードバックの形として、出力に対する明確に定義されたルールを与えたうえで、どのルールがなぜ失敗したのかを説明して返すことを挙げています。
ループの形は4段です。Anthropicは「Building agents with the Claude Agent SDK」で、エージェントの基本の流れを、コンテキストを集める、行動する、作業を検証する、そして繰り返す、と示しています。
1段目のコンテキストを集める部分は本記事の対象外です。何を読ませるか、どう探させるかはコンテキストエンジニアリングで扱っています。本記事が扱うのは、3段目の検証と4段目の繰り返しです。
検証の第一手は1文で示されています。同じ資料は、最良のフィードバックの形が、出力に対して明確に定義されたルールを与えたうえで、どのルールがなぜ失敗したのかを説明することだと述べています。
「なぜ」まで返す点が要点です。合否だけを返すと、エージェントは次の反復で何を変えればよいかを推測することになります。失敗したルールの名前と理由が返れば、次の一手は推測ではなく修正になります。
ルールで書けない対象には別の形があります。同じ資料は、画面生成やテストのような視覚的なタスクでは、スクリーンショットやレンダリング結果という形の視覚的なフィードバックが役に立つとし、曖昧な基準については別の言語モデルに出力を判定させる方法も挙げています。
本記事が扱うのは、実行の最中にエージェント自身へ返して次の反復を直させるフィードバックです。複数回の試行の合否を集計して開発者が品質を判断する方法は、別のテーマになります。
実行の制御がぶれるかどうかは、判定の置き方で決まります。AIを制御するときの決定論ロジックの使い方は、私の実務では制御の良し悪しに直結します。
置く条件は、0か1かで答えが出る形にします。必要なコンテキストが注入されているか、想定した道具を通ったか、といった機械的に判定できるロジックを、私は実行の流れに組み込みます。
論文側の言い方も同じ方向です。「Natural-Language Agent Harnesses」（2026年・arXiv）は、ハーネスが担うものとして、エージェント呼び出し・引き継ぎ・状態の更新・検証の関門・成果物の取り決めを挙げています。検証の関門と成果物の取り決めは、どの状態になれば次へ進んでよいかを先に決めておく設計にあたります。
エージェントはどこで止まるべきか？
反復の回数に上限を置き、そこで止めます。Anthropicは、制御を保つために、最大の反復回数のような停止条件を含めるのが一般的だとしています。上限は正常に終わるための条件ではなく、終われなかったときに実行を切るための条件です。
停止条件を置く目的は1つです。この仕組みから考えると、停止条件の役割は、正しく終わらせることではなく、間違ったまま進み続ける実行を止めることにあります。
止まる形は2つあります。反復の上限で機械的に切る形と、チェックポイントで人のフィードバックを待つ形です。2つを併用すると、上限に達する前に人が気づける経路が1本増えます。
最初のハーネスは、どこから作ればよいのか？
停止条件、実行の境界、機械的な合否判定の3つから始めます。3つはいずれも、後から足すとそれ以前の実行をやり直すことになるため、自律の幅を広げる前に置きます。残りの要素は動かしながら厚くしても間に合います。
3つを選ぶ基準は1つです。この仕組みから考えると、後から足しても過去の実行を復元できないものだけを先に置き、後から足しても効きが変わらないものは後回しにできます。
3つの根拠はそれぞれ一次資料にあります。停止条件はAnthropicが制御を保つ手段として挙げたもの、実行の境界はファイルとネットワークを先に定義してOSに強制させる仕組み、機械的な合否判定はルールと失敗理由を返すフィードバックです。
厚くするほど良い、という関係にはありません。「From Model Scaling to System Scaling」（2026年・arXiv）は、研究課題として、最終タスクの成否を超えて、軌跡の質、記憶の衛生、コンテキストの効率、伝達の忠実さ、検証のコスト、時間をかけた安全な進化を測るべきだと述べています。
測る対象に検証のコストが並んでいる点が示唆的です。この仕組みから考えると、検証のコストは削るべき無駄ではなく、失敗の許容度と引き換えに調整する設計変数として扱えます。ハーネスを厚くするほど、1回の実行は遅く、高くなります。
どこから厚くするかの材料も同じ論文にあります。同論文はハーネスのボトルネックとして、コンテキストの統治、信頼できる記憶、動的なスキルの振り分けの3つを挙げています。3つは、最小構成が動いたあとに手を入れる順番の候補になります。
記憶とコンテキストそのものの設計方法は本記事の対象外です。本記事が扱うのは、作ると決めたエージェントを実際に走らせる実行系を、どう厚くしていくかです。
ハーネスの使い道は、ひとつの実行をうまく終わらせることに限りません。私が実務で組んでいるのは、コンテキストの自己改善ループを持たせたハーネスです。
自己改善ループを組む狙いは、恒久的にAIが仕事を覚えていく仕組みを作ることにあります。実行系を厚くしていく先の到達点として、私はこの形を見ています。
1体のエージェントを作る順序も本記事の対象外です。どんな業務を任せるか、何から着手するかはAIエージェントの導入は何から始めればよいのかで扱っています。
よくある質問
ハーネスエンジニアリングは、コンテキストエンジニアリングと何が違いますか？
扱う範囲が違います。コンテキストエンジニアリングは、モデルに何を読ませるかを設計するもので、本記事の整理ではハーネスを構成する5要素のうち指示とツールの側に位置します。ハーネスエンジニアリングは、モデルに読ませる内容の外側にある実行環境の境界、実行中の検証、停止条件までを含めて設計の対象にします。
ハーネスは自分で作らないといけませんか？
全部を自作する必要はありません。ループの回し方、ツールの登録、実行の囲い方は、既製のエージェント基盤に最初から含まれていることが多い部分です。自分で決めるのは、どこまで自律させるかという境界、何回で止めるかという停止条件、何をもって合格とするかという判定の3つで、3つとも業務ごとに答えが変わるため、既定値のまま使わずに決めます。
ハーネスを厚くすると、実行は遅く高くなりませんか？
なります。Anthropicは、エージェントの自律的な性質が、より高いコストと誤りが積み上がる可能性を伴うとしており、検証を1段増やせばその分だけ1回の実行にかかる時間と費用は増えます。判断の基準になるのは失敗を取り返せるかどうかで、取り消しの効かない操作を含む実行だけを厚くし、読むだけの実行は薄いままにする配分にできます。
ハーネスエンジニアリングは何から学べばよいですか？
いま動かしているエージェントに停止条件が入っているかを確認するところからです。反復の上限が無いまま動いている場合は、上限を1つ入れるだけで、間違ったまま進み続ける実行が止まります。次に書き込んでよいディレクトリと接続してよい先を書き出し、境界と停止条件を先に、道具の作り込みを後に回す順序にすると、途中で作り直しが起きにくくなります。
まとめ
ハーネスとは、モデルの外側にあって、ひとつのタスクの実行を組み立てる仕組みです。エージェントの性能は、モデル単体の賢さではなく、モデルと実行系の相互作用から立ち上がります。
最初に置くのは3つです。反復を止める停止条件、ファイルとネットワークの実行境界、機械的に合否が決まる判定です。3つはいずれも後から足すとやり直しになるため、自律の幅を広げる前に置きます。
PR
モデルの外側の設計を、自分の業務で試せる状態にする
実行の境界や停止条件の考え方は、論文と公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学び直したい場合や、チームに説明する必要がある場合は、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の比較軸は生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
にほんブログ村
