Agent Harnessとは何か

Agent Harnessは、AIモデルを「実際に仕事をするagent」として動かすために、modelの周囲へ組み込むsoftwareやconfigurationの層を指す新しい用語です。

2026年にはcoding agentを中心にこの表現が急速に広がりました。LangChainは「Agent = Model + Harness」と整理し、harnessを、model以外のcode、configuration、execution logicの総体として説明しています。OpenAIもCodexを使った開発経験を「harness engineering」という言葉で整理し、agentが仕事をしやすいenvironment、tool、abstraction、feedback loopを整える重要性を示しています。

この言葉はまだ新しく、厳密な標準定義が確立したとは言えません。記事や製品ごとにharnessへ何を含めるかを確認する必要があります。^[1][2][3]

モデルの外側にある「仕事を可能にする仕組み」

LLM単体は、入力を受けて出力を返すmodelです。fileを開く、codeを実行する、検索する、長いtaskのstateを保持する、といった能力は周辺systemが提供します。

Agent Harnessの代表的な構成要素は次です。

• execution loop：modelを繰り返し呼び出す
• tool interface：検索、API、shell、browserなどを使わせる
• context assembly：毎回modelへ何を見せるか決める
• state / memory：途中経過や作業状態を保持する
• permissions：許可された操作を制限する
• sandbox：codeやfile操作を隔離する
• verification：testやschemaで結果を確認する
• observability：tool callやfailureを追跡する
• recovery：失敗時のretryやresumeを扱う
• termination：いつ終了するかを決める

同じmodelを使っても、このharnessが違えばagentの挙動は大きく変わります。

Agent Harnessとmodelは別物

LangChainの「Agent = Model + Harness」という式は、この境界を理解するのに便利です。

modelは、言語理解、推論、生成、tool callの選択などの能力を提供します。Harnessは、その能力をどのenvironmentで、どのtoolへ、どのconstraintの下で、何回実行し、どうverifyするかを決めます。

たとえば同じmodelでも、一方はfile readしかできず、一方はcode editとtest executionができ、さらに一方はfailure logを読んで修正・再試行できるなら、agentとしての実用性能は大きく違います。これをすべて「model性能」と呼ぶと、何が差を生んでいるのか見誤ります。

FrameworkやSDKとの違い

Agent frameworkやSDKは、Agent Harnessを構築するための部品や開発基盤になり得ます。しかし両者は同義ではありません。

frameworkは、agent、tool、memory、workflowなどを作るためのAPIやabstractionを提供します。harnessは、特定のagentを実際に動かすために組み上げたexecution environment・control全体を指すことが多いです。

frameworkを使わず自作codeだけでharnessを作ることもできます。逆にframeworkを導入しても、tool、permission、context、verificationを適切に設定しなければ、良いharnessにはなりません。

Eval harnessとの違い

「harness」は以前からtest harnessやevaluation harnessの意味でも使われてきました。

eval harnessは、modelやagentへtest problemを与え、outputをscoreする評価基盤を指します。Agent Harnessは、agentが通常taskを実行するためのoperation/execution layerを指す用法です。

ただしagent harnessの中にverificationやeval機能を組み込むことはあります。元文脈で「実行するためのharness」なのか「評価するためのharness」なのかを確認する必要があります。

なぜ重要語になったのか

model能力が高まると、「どのmodelを選ぶか」だけではagent性能を説明できなくなります。

OpenAIのharness engineering記事では、人間の役割が直接codeを書くことから、agentが仕事をしやすいenvironment、abstraction、tool、feedback loopを設計することへ移ったと説明されています。LangChainも、modelを変えずにharnessだけ改善することでcoding agentの性能を改善した事例を公開しています。

agent開発では「modelを賢くする」以外に、賢さを発揮しやすいenvironmentを作ることが独立した設計対象になっています。

具体例：coding agentのHarness

coding agentに「testを直して」と頼む場合を考えます。

良いharnessなら、agentはrepository structureを確認し、関連fileを読み、codeをeditし、testを実行し、failure logを受け取り、再修正できます。危険なcommandは禁止され、変更diffは記録されます。

悪いharnessでは、必要fileが見えない、test commandを知らない、実行結果をmodelへ返せない、contextがすぐ溢れる、誤操作を止められない、といった問題が起こります。

この差はmodelそのものではなく、harnessにあります。

元の文脈で確認すること

• modelとharnessのboundaryをどう定義しているか
• loopを誰がcontrolするか
• contextをどうassembleするか
• toolとpermissionは何か
• sandboxはあるか
• stateやmemoryをどう保持するか
• verificationをどう行うか
• observabilityとtraceはあるか
• failure recoveryはどうするか

Agent Harnessは有用な概念ですが、まだ用語が固まりきっていません。「harnessがある」という宣伝より、modelの外側で何をcontrol・provideしているかを具体的に読むことが大切です。

Harnessの境界はどこまで広いのか

Agent Harnessの用法が揺れる最大の理由は、「modelの外側」をどこまで含めるかが人によって違うためです。

狭い意味では、model call、tool execution、loopをつなぐruntime codeを指します。広い意味では、repository structure、instruction file、CI、test、sandbox、observability、memory、subagent coordinationまで含めます。

LangChainはかなり広く「modelでないものはharness」と整理します。一方、他の開発文書ではruntime layerだけをharnessと呼ぶ場合があります。

そのため用語集としては、一つの固定部品名と説明するより、「modelをagentとして動かす周辺system」というcoreを示し、その範囲が文脈依存であると説明するのが安全です。

Agent HarnessとAgent Runtime

runtimeは、agentを実際にexecuteするenvironmentを指すことが多い用語です。Harnessと重なりますが、完全な同義とは限りません。

runtimeはprocess execution、state、tool invocation、resource managementなどの「動かす場所・仕組み」を強調します。Harnessはそれに加え、context、instruction、verification、guardrailなど「modelをtaskへ適合させるscaffolding」まで広く含むことがあります。

製品がAgent Runtimeを提供すると書いていても、full harnessを提供するとは限りません。逆も同様です。

HarnessとAgent Framework

frameworkは開発者がagentを構築するためのreusable libraryやabstractionです。Harnessはそのframeworkで構築された具体的systemでも、自作実装でも構いません。

たとえばframeworkがAgent class、Tool interface、Memory APIを提供し、開発者がそれらを組み合わせて、自社repository用のinstruction、sandbox、test runner、permission、loopを作ったとします。この完成した周辺systemがharnessです。

frameworkは「部品箱」、harnessは「特定用途向けに組んだ装置」と考えると分かりやすくなります。

Harnessが隠すmodel差、modelが隠すharness差

agent benchmarkを読むときは、modelとharnessを分離して比較する必要があります。

Model A + Harness XとModel B + Harness Yを比較して性能差が出ても、どちらが原因か分かりません。理想的には、

• 同一modelでharnessだけ変更
• 同一harnessでmodelだけ変更

というablationが必要です。

Agent Harnessという概念は、agent performanceを「model leaderboardの延長」だけで理解する危険を減らします。

Context assemblyはHarnessの核心

agentは毎turn、無限のinformationをmodelへ渡せません。どのinstruction、file、tool result、memoryをcontextへ入れるか選ぶ必要があります。

このcontext assemblyが悪いと、必要情報が抜けたり、古いinformationが残ったり、irrelevant contentでcontext windowが埋まったりします。

したがってharnessは単にtoolをつなぐだけではなく、「今このstepでmodelが見るべきinformationを構成する」役割を持ちます。

Context EngineeringとAgent Harnessが密接に関係する理由です。

VerificationもHarnessの一部になり得る

生成modelのoutputをそのままactionへ使うとriskがあります。そこでharnessが、structured output validation、test、lint、schema check、policy checkなどを行い、failureをmodelへ戻します。

coding agentなら「codeを書いた」ではなく「testがpassした」をtermination conditionにできます。

data agentならSQLを実行する前にread-only policyをcheckできます。

こうしたdeterministic verificationをmodelの判断と組み合わせることで、agentのreliabilityを高められます。

Harnessのsecurity面

Harnessはagentのcapabilityを増やすだけでなく、制限する層でもあります。

• filesystem scopeを限定する
• network domainをallowlistする
• dangerous commandをblockする
• credentialを直接modelへ見せない
• write actionにapprovalを要求する
• secretをlogへ残さない

agent securityでは「modelが安全に判断すること」を期待するだけでなく、harnessがenforceするboundaryが重要です。

Agent Harness claimの読み方

「最新harnessでagent性能が向上」と書かれていたら、何が変わったかを確認します。

toolが増えたのか、context retrievalが改善したのか、test loopが追加されたのか、permissionが変わったのか、model call回数が増えたのか。

性能向上がcompute増加による場合もあります。harnessという言葉だけではefficiencyは分かりません。

Agent Harnessは、agentをsystemとして理解するための便利な枠組みです。modelだけを見るのではなく、modelが何を見て、何をでき、どの結果を受け、どこで止められるかを決める周辺systemを見るための言葉です。

Harnessは製品固有の「隠れた差」になりやすい

同じbase modelを使う複数のcoding agentが大きく異なる結果を出す場合、その差はtool quality、context retrieval、edit strategy、test loop、sandbox、memoryなどharnessにあるかもしれません。

そのためmodel名だけで製品性能を予測するのは危険です。逆に、あるagentの高評価を見て「このmodelなら同じ性能が出る」と推論するのも不正確です。公開benchmarkでは、model、harness、tool access、compute budgetをできるだけ分けて確認する必要があります。

Agent Harnessという語が役立つのは、この「model以外のsystem contribution」を明示的に考えられる点です。

Harnessのversioning

production agentではharnessもversion管理の対象になります。tool description、permission、system instruction、termination、context policyの小さな変更でもbehaviorが変わるからです。

model versionだけ記録しても再現できない場合があります。再現性やauditabilityが重要なら、modelとともにharness configuration、tool version、policy versionも記録する必要があります。

関連するAI用語

• AIエージェント（G191）
• Harness Engineering（G198）
• Agent Loop（G199）
• Agentic Workflow（G200）

注・出典

1. Microsoft Agent Framework, Agent Harness ↩
2. OpenAI, Unrolling the Codex agent loop ↩
3. OpenAI, Unlocking the Codex harness: how we built the App Server ↩

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。