「エージェントハーネス」という用語はどこから生まれたのか？

ここ最近、AIエージェント周りの技術について「エージェントハーネス」という言葉がよく話題になります。

よく話題になります、というか、西見自身も外部のメディアで記事を書かせていただいています。

codezine.jp

しかしこの「エージェントハーネス」という言葉、そもそもどこからやってきた言葉なのでしょうか？*1

そもそも「ハーネス」って何？

というわけで、この言葉の真意を探るべく、様々な文献を調査して、何となくの理解をしてみました。

ハーネスって何！？と、凄く気になる方はご覧くださいませ。

AI周りでは2024年の言語モデル評価の論文が初出？

筆者が調べた範囲では、AI周りで「ハーネス」という言葉が登場したのは、2021年にGaoらが公開したLanguage Model Evaluation Harness（lm-eval）が早い例のようです。ただし当時はライブラリとしての公開にとどまっていたようです。その設計思想や実践知を論文として詳細にまとめたのが、2024年に公開されたBidermanらの「Lessons from the Trenches on Reproducible Evaluation of Language Models（言語モデルの再現可能な評価）」です。

本論文の「はじめに」にも、

（意訳）大規模言語モデルについて透明性が高く再現性のある評価が非常に困難であるという問題に対処するため、私たちは(Gao et al., 2021)で提案された「Language Model Evaluation Harness」を構築しました。

とあります。引用元をたどると本論文で紹介されている評価ハーネスと同じEleutherAI/lm-evaluation-harness: v0.4.3に行き着くため、2021年のライブラリ公開と2024年の論文は同一のプロジェクトを指していると考えられます。

さて、それではこの論文ではハーネスをどのような意味や意図で使用しているのでしょうか？

そもそも本論文で紹介されている lm-eval は、

従来は網羅的なLM評価を行うには、既存タスクを一から再実装する（微妙な方法論的差異を生みやすい）か、数十の小さなライブラリを個別にインストール・デバッグして使う必要があった。

という問題を解決するためのオーケストレーションとして提案されました。

つまり、

評価対象のモデル（HuggingFace、vLLM、API経由など様々なバックエンド）

評価タスク（ベンチマークデータセット、プロンプトテンプレート、メトリクス定義）

実行制御（few-shot設定、バッチ処理、ログ出力、結果集約）

といった要素を一元的に扱えるようにするツールであるということです。

ソフトウェアの文脈で言うと、少し近い仕組みにテストハーネスがあります。

テストハーネスとは、テスト対象のソフトウェアを動かすために、スタブやドライバといった仮の部品一式と一緒にまとめて動かすための仕組みです（Test harness - Wikipedia参照）。

「評価ないしはテストしたい対象があるのだけど、そのままだと評価もテストもできないので、できるようにするための仕組みを整えました」という点が、これらに共通している要素だと考えられます。

したがって、評価ハーネスやテストハーネスの意図を踏まえると、「ハーネス」とは馬具のハーネスが馬と馬車をつないで・制御する装置であるのと同様に、関連するものを接続する装置の意味合いで使われているのではないかと考えられます。

イメージを画像にすると、こんな感じです。雑すぎるか。

暴れ回るイヌ（LLM）に何かを接続するハーネスのイメージ

エージェントハーネスの起源

それでは、このハーネス概念がエージェントの分野で使われ始めたのはいつ頃なのでしょうか？

2024年のOpenHandsの紹介のされ方が起源か？

こちらも調べてみたところ、同じく2024年にXuらが公開した「TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks（現実世界の重要タスクにおけるLLMエージェントのベンチマーク）」でのOpenHandsの紹介に起源を見ることができるようです。TheAgentCompanyは大嶋さんが定期的に開催しているAIエージェントキャッチアップでも取り上げられていたので、ご存知の方もいらっしゃるのではないでしょうか。

blog.generative-agents.co.jp

OpenHandsは、古くはOpenDevinという名前で公開されていたコーディングエージェントの実装です。本論文では次のように紹介されています。

すべてのモデルはOpenHandsエージェントフレームワークで実行される。これはウェブブラウジングとコーディングの両方に対応した、安定的で強力なエージェントハーネスを提供する。

OpenHandsの役割はLLMに対して「ブラウザ操作」、「ターミナル操作」、「コード実行」といった行動手段を装着することです。LLM単体ではウェブを閲覧することもコードを実行することもできませんが、OpenHandsがそのインターフェースを提供することで、LLMがエージェントとして環境内で活躍できるようになるわけです。

ハーネスはLLMとは関係なく「付け外し」できるもの？

続いて2025年にZhangらが公開した「General Modular Harness for LLM Agents in Multi-Turn Gaming Environments（マルチターン型ゲーム環境におけるLLMエージェント向け汎用モジュラーハーネス）」では、「ハーネス」という言葉がタイトルにもなっています。

この研究では、認知科学者Newellの統一認知理論（知覚・記憶・推論を、相互に連動する能力と位置づける理論）に倣い、次のモジュールからなるハーネスを提案しています。

Perception（知覚）：低解像度のグリッド環境から視覚的に複雑な画像まで処理する

Memory（記憶）：直近の行動軌跡を蓄え、セルフリフレクションのシグナルを合成する。過去の行動を批評し将来の計画を調整できるようにする

Reasoning（推論）：知覚の埋め込みと記憶の痕跡をバックボーンLLM/VLM内で統合し、逐次的な意思決定を生成する

研究ではベースラインとしてハーネスなしに素のLLM/VLMに直接ゲーム状態を渡して行動を出力させたものと、ハーネスを装着させたものとを比較しています。結果、ハーネスを装着したLLM/VLMはベースラインに対して平均勝率を有意に向上させた、とのことです。

ここで重要なのは、ハーネスを付けたり外したりできるものとして扱っていることです。関連するものを接続する装置というよりは、接続するためのハーネスと、接続先（知覚・記憶・推論というモジュール）がセットになっている印象を受けます。また本論文ではベースラインでも一応動くLLMエージェントを用意し、ハーネスの装着前後で比較している訳なので、OpenHandsの紹介のされ方とは若干違う印象を受けます。

エージェントランタイム自体をハーネスと呼んだTheAgentCompanyでのOpenHandsの紹介と、エージェントを成立させる再利用可能な外側の仕組みとしてハーネスと呼んでいる汎用モジュラーハーネスの紹介の違いが、ある意味、現在における「ハーネスとは何か？」の混乱の源流でもあるような気がします。

エージェントハーネスの現在地を整理した「OpenDev」

単著なので定義付けの議論に加えるのには弱いですが、2026年3月に公開されたBui氏の「Building AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned（ターミナル向けAIコーディングエージェントの構築）」では、現在におけるエージェントハーネスの位置付けと実装が詳細に解説されています。

本論文ではOpenDevというサンプル実装で、現代的なコーディングエージェント設計の要点を示しています。

ポイントはエージェントのアーキテクチャを、「スキャフォールディング」と「ハーネス」の2つのフェーズに分けていることです。

「スキャフォールディング」は最初のプロンプトが届くまでの初期化（システムプロンプトの組み立て、ツール定義の構築など）を意味し、「ハーネス」は立ち上がったエージェントが走る（ツール実行、コンテキスト圧縮、セッション状態の保存など）ための仕組みを意味しています。

さらに、

ハーネスとはコアとなる推論ループ*2を包み込み、その周囲でツール実行、コンテキスト管理、安全性の適用、セッションの永続化を調整するランタイムオーケストレーションレイヤー

と説明しています。

ただ、この説明だと「コアとなる推論ループ」に付け外しできるのがハーネスなのか、それとも「推論のコアであるLLM」に付け外しできるのがハーネスなのか疑問が残ります。

文字通り読むと前者ですが、例えばLangChainのcreate_agent()のような基本的なループにOpenDevのようなハーネスをくっつけているわけではありません。むしろ、このループ自体もエージェントハーネスの実装に含まれているはずです。

となると、文字通りの解釈をするよりは、「推論のコアであるLLM」に付け外しできるランタイムオーケストレーションレイヤーであると考えた方が自然な気がしています。事実、Claude Codeのようなエージェントハーネスでは、APIが互換していれば異なるモデルを入れ替えて実行することができます。

となると、文字通りの解釈をするよりは、「推論のコアであるLLMに対して付け外しできるランタイムオーケストレーション層」と捉えた方が実態に近いのではないかと考えています。実際、Claude Codeやopencodeのようなエージェントハーネスでは、APIが互換していれば異なるモデルを差し替えて実行できます。

Anthropicのハーネス設計

論文以外の文献にも目を向けてみます。2026年3月に公開されたAnthropicのEngineeringチームの「https://www.anthropic.com/engineering/harness-design-long-running-apps（長時間動作アプリケーションにおけるハーネス設計）」では、Claude Codeの開発チームがハーネス設計を通じて長時間の自律コーディング性能をどう引き上げたかを報告しています。

興味深いのは、記事ではハーネスの各コンポーネントを「モデルが単体ではできないことに対する仮説」と捉えている点です。

（意訳）ハーネスのすべてのコンポーネントは、モデルが自力ではできないことについての仮説をエンコードしている。それらの仮説は検証する価値がある。間違っているかもしれないし、モデルの改善によってすぐに陳腐化しうるからだ。

具体的には、Opus4.5のときは必要だったコンポーネントが、Opus4.6では自力でできるようになったので不要になった、とのことでした。なので、モデルが進化するたびにハーネスの「どこが本当に必要なのか」を見直す必要がある、だから「仮説」と置いているのだということです。ハーネスは一度作ったら終わりではなく、モデルと一緒に育てていくものだ、ということを示唆していると考えられます。

ハーネスの定義そのものについて踏み込んだ記述はないものの、記事全体を通して「モデルの外側の設計次第で、同じモデルでもアウトプットの質が変わるもの」という前提があると考えられます。

LangChainによるハーネスの定義

同じく2026年3月、LangChainからも「The Anatomy of an Agent Harness（エージェントハーネスの解剖学）」というブログ記事が公開されています。

ハーネスの構成要素を体系的に整理した内容になっており、定義がシンプルです。

Agent = Model + Harness

If you're not the model, you're the harness.

（モデルでなければ、それはハーネスである）

と言い切っており、システムプロンプト、ツール定義、サンドボックス、コンパクションなど、これらは全てハーネスの構成要素だという整理をしています。

記事ではここから「モデル単体ではできないこと」を起点に、それぞれに対応するハーネス機能を導出していく構成になっています。ファイルシステム、bash実行、サンドボックス、メモリ、コンテキスト管理、長時間実行のためのRalphループと、現代のコーディングエージェントが備えるべき機能が一通り整理されています。

本記事でここまで見てきた各論文の用法とも矛盾しない定義ですし、「モデルの外側にある仕組みがハーネスである」という本稿の暫定的な結論とも一致します。

まとめ

各文献での「ハーネス」の位置付けをまとめると、次の通りです。

Bidermanら（2024）の評価ハーネス - 多様なモデルと多様なベンチマークタスクを統一的なインターフェースで接続し、再現可能な条件で評価を実行するためのオーケストレーション基盤。ハーネスがなければ評価自体が成立しない、インフラとしてのハーネス。

Xuら（2024）のTheAgentCompany - OpenHandsをエージェントハーネスと紹介。LLMにブラウザ操作やターミナル操作といった行動手段を提供するエージェントランタイムをハーネスと呼んでいる。

Zhangら（2025）の汎用モジュラーハーネス - 知覚・記憶・推論の3モジュールをLLMに着脱可能な装備として設計。ハーネスなし（素のLLM）でも動作するが、装着すると性能が向上する。能力拡張としてのハーネス。

Bui（2026）のOpenDev - ハーネスを「推論ループを包み込むランタイムオーケストレーション層」と定義。スキャフォールディング（起動前の組み立て）との対比で、起動後の実行時制御をハーネスの役割として整理している。

Anthropic（2026）のハーネス設計 - ハーネスの各コンポーネントを「モデルが単体ではできないことへの仮説」と捉え、モデルの進化に応じて見直すべきものとしている。ハーネスは一度作って終わりではなく、モデルと一緒に育てていくもの。

LangChain（2026）のハーネス定義 - 「モデルでなければ、それはハーネスである」と定義。モデル単体ではできないことを起点に、ハーネスが備えるべき機能を体系的に導出している。

ハーネスに共通する要素

定義の揺れはあったものの、共通して言えそうなことを挙げてみます。

LLMそのものではなく、LLMの外側にある仕組み

どの文献でもハーネスはモデル本体とは区別されている。モデルを入れ替えてもハーネスは使い回せるという前提がある。LangChainの「モデルでなければハーネス」という定義が、最もシンプルにこれを言い表している。

LLM単体ではできないことを可能にする

評価の実行、ツールの使用、記憶の保持など、1回の推論で完結しないあらゆる機能をハーネスが担う。

ただし、固定的なものではない

Anthropicのブログが示したように、モデルが進化すればハーネスの「必要な部分」も変わる。今のモデルに必要なコンポーネントが、次のモデルでは不要になるかも知れない。

さいごに

ここまでの調査を踏まえて最後に暫定的な定義を置きたいと思います。

ハーネス：あるものを特定の仕事に向けて接続・制御するための、外側にある仕組みのこと

馬具のハーネスが馬の力を荷車に伝えて仕事をさせるように、あるもの単体ではできないことを可能にします。

エージェントハーネス：LLMを自律的なエージェントとして動作させるためのハーネスのこと

OpenDevではスキャフォールディングとエージェントハーネスを結合したものがランタイムとして提供されていました。Claude Codeやopencodeといったプロダクトでも同様に見えます。そのため、実態としてはLLMを組み込んだランタイムがエージェントハーネスに見えるのではないでしょうか。

直近では、AIエージェントの開発とは、すなわちエージェントハーネスの開発を指すようになってきたと思います。さらには、このエージェントハーネスで駆動するエージェントをいかに上手く動作させるかを考える「ハーネスエンジニアリング」という言葉も話題になってきています。

また、Anthropicの記事で示唆されている「モデルが変わればハーネスも変わる」という考え方は、専門的な業務にフィットしたハーネスを開発する上でも大きな考え方になりそうです。

というわけで、謎の「ハーネス」概念について、この記事でスッキリしてもられば幸いです！