2026年、AI業界で最も興味深い一文は新しいモデルの話ではない。 Anthropic、Martin Fowler、そしてAI研究コミュニティの半分が、ここ数週間で ひとつの公式に収束した：
Agent = Model + Harness。
最近AI Twitterを覗けば、harnessという単語をいたるところで目にする。 プリンストンはHAL harnessをリリース。HKUDSはOpenHarnessをオープンソース化。 新しいMeta-Harness論文では、モデルの重みに一切手を加えずに Harnessを自動で書き換えるだけで、TerminalBench-2のスコアが数ポイント上昇することが示された。 Philipp Schmidは、Agent Harnessを「長時間タスクにおけるモデルドリフトを解決する第一の道具」だと呼んだ。
しかし誰も声高には言わないことがある。2026年のHarness論争のほぼすべてはコーディングAgentの話だ。Claude Code。SWE-bench。ターミナルタスク。 リポジトリのナビゲーション。
では、それ以外の世界はどうなのか？Gitリポジトリを触らないAgent業務はどうなるのか？
私たちはLessie。たったひとつの仕事のためにHarness Agentを作っている──人を探すことだ。リクルーターは候補者を探すために、 セールスは意思決定者を探すために、VCは創業者を探すために、 マーケターはクリエイターを探すために私たちを使う。 だからHarness論争が盛り上がったとき、私たちは具体的に確かめたくなった。 「Harnessはモデルより重要だ」という仮説は、コーディングの外でも本当に成り立つのか？
そこでベンチマークを構築し、実験を回した。その結果がPeopleSearchBenchであり、見出しの数字はこうなった：
119件の実世界の人材検索クエリで、Lessieは65.2点。 Sonnet 4.6で動くClaude Codeは45.8点。42%の差── 変えたのはHarnessだけだ。
これが何を意味するのか、ひとつずつ紐解いていこう。
Harness Agentとは何か、平易に言うと
最も短い定義はOpenHarnessチームが与えている：モデルがAgentで、コードがHarnessである。 Parallel Webによる少し長めの定義はこうだ：Harnessとはモデルを包み込むランタイムであり、 ツール呼び出しを傍受し、コンテキストを管理し、Agentをタスクに留め続けるものだ。
Martin Fowlerはこれを互いに補い合う2つの半分として捉える。Guidesは前向き制御──Agentが行動する前にその振る舞いを形作る （システムプロンプト、ツール記述、検索済みコンテキスト、環境スナップショット）。Sensorsは後ろ向き制御──Agentが何をしたかを観察し、修正をフィードバックする （linter、バリデータ、検証ループ）。 良いHarnessはこの両方を備える。悪いHarnessは前向き制御だけで、 47ターン目に同じ間違いを繰り返すAgentを黙って見ている。
つまりHarness Agentとは、丸ごとひとつのパッケージだ── モデル＋ガイド＋センサー＋ツール＋メモリ＋検証ロジック。 生のトークン予測を、現実の仕事を完遂できる何かに変える総体である。
2つの系統が立ち上がりつつある：
- 汎用Harness──Claude Agent SDK、OpenHarness、そしてClaude Code内蔵のHarnessなど。 これらはドメイン非依存に設計されている。
- 垂直Harness──ひとつの仕事を中心に作り込まれ、 ガイドもセンサーもその仕事の失敗モードに合わせて調整されている。
あなたが耳にしたであろうHarnessのベンチマークはほぼすべて──SWE-bench、 TerminalBench-2、USACO、AppWorld──汎用Harnessをコーディングタスクで測ったものだ。 私たちの知る限り、PeopleSearchBenchは、垂直Harness Agentと汎用Harnessを コーディング以外の仕事で正面からぶつけた最初のベンチマークである。
なぜ人材検索には専用のHarnessが必要なのか
汎用AI Agentに「ベルリンのSeries Bスタートアップで、LLM製品をリリース経験のある シニアMLエンジニアを探して」と頼んだことがあれば、典型的な失敗パターンは身に染みているはずだ。 そのうち3つは特に頑固で、すべてHarnessの問題であって、 モデルの問題ではない：
1. クロスソースのエンティティ解決。実在の人物はLinkedIn、X、GitHub、カンファレンス登壇、企業ページ、学術データベースに またがって存在する。名前も写真も、時にはスペルさえ違う。 汎用Harnessには「このLinkedInプロフィールとあのGitHubアカウントは同一人物だ」 という組み込み概念が存在しない。人材検索のHarnessは、このことを毎クエリ解かねばならない。
2. 検証ループ。センサー層を持たないAgentは、自信満々で人物を捏造する。 実在しない「Stripeベルリンのシニアエンジニア」を引用することがある── トークンとしてはもっともらしいからだ。 この問題はもっと賢いモデルでは直らない──Claude Code内のSonnet 4.6でも依然として起きる。 直すにはセンサーが要る：返ってきた人物はすべて、ユーザーに届く前に ライブのWebソースで照合されなければならない。
3. 人間属性に対するクエリ分解。「ベルリンのSeries B、LLM製品を出荷したMLエンジニア」はひとつのクエリではない。 チェックリストだ：役割＋シニアリティ＋会社ステージ＋地域＋ドメイン＋直近のアウトプット。 汎用Harnessはこの一文を丸ごと検索ボックスに投げ込む。 垂直Harnessはこれを基準に分解し、適切なソースに対して並列に走らせ、 集約してランキングする。
この3つはまさに、Fowlerの言うガイドとセンサーそのものだ。 ただ、汎用コーディングHarnessには誰も組み込まないガイドとセンサーである── コーディングHarnessには必要ないからだ。
証拠：PeopleSearchBench
PeopleSearchBenchは、この問いを誠実に検証するために構築した。 詳細な方法論は論文に譲るが、要点はこうだ：
- 119件の実クエリ──実際のリクルーター、セールス、リサーチのワークフローから収集
- 4言語（英語、ポルトガル語、スペイン語、オランダ語）
- 4シナリオ：採用（30）、B2Bプロスペクティング（32）、 専門家／確定的検索（28）、インフルエンサー／KOL（29）
- 4プラットフォーム：Lessie（垂直Harness Agent）、 Exa（構造化検索API）、Juicebox / PeopleGPT（8億+プロフィールを持つ採用プラットフォーム）、 Claude Code（Sonnet 4.6上の汎用Harness）
- 3つの独立した次元：Relevance（padded nDCG@10）、 Coverage（タスク完了率 × 歩留まり）、Utility（プロフィール情報の充実度）
- LLMの感覚値ではなく、ライブWeb検索による検証── 返ってきた人物は全員、LinkedIn、企業サイト、公開プロフィールに照らして事実確認される。 検証Agentは、どの結果がどのプラットフォーム由来かを一切知らない。
総合スコアはこうなった：
- Lessie：総合 65.2 | Relevance 70.2 | Coverage 69.1 | Utility 56.4
- Exa：総合 54.6 | Relevance 53.8 | Coverage 58.1 | Utility 53.1
- Claude Code：総合 45.8 | Relevance 54.3 | Coverage 41.1 | Utility 42.7
- Juicebox：総合 45.8 | Relevance 44.7 | Coverage 41.8 | Utility 50.9
Lessieはすべての次元で1位だ。119件すべてのクエリを完走した唯一のプラットフォームでもある──完走率100%。他の3つはニッチな検索でしばしば何も返せなかった。
だがHarness論争にとって最も重要な数字は、LessieとClaude Codeの差だ。 どちらもAI Agentで、どちらもツールを呼べて、どちらもWebを検索できる。 Claude Codeは地球上で最強のモデルのひとつで動いている。 それでも総合で19.4点負けた。 Coverageの単独差は28点に達する。
この19.4点はモデルの差ではない。Harnessの差だ。
単一シナリオで最大の差がついたのはインフルエンサー／KOL検索。 Lessie 62.3、Claude Code 43.2。 インフルエンサー検索は汎用Harnessが最も派手に崩壊する場所だ。 正解がTikTok、Instagram、YouTube、Xに同時に分散して存在し、 汎用Harnessにはそれらを融合する手段がないからだ。 最小だったのは採用シナリオ──3つのプラットフォームが64点を超えた。 採用は人材検索の中で最も成熟した垂直であり、業界は何年もかけて道具を磨いてきた。
パターンは一貫している：マルチソース融合と検証を強く要求するシナリオほど、Harnessが効いてくる。
LessieのHarnessの中身
システムプロンプトは公開しない。だがアーキテクチャは3層構造で、 ガイドとセンサーのモデルにきれいに対応している。 どの垂直Harness Agentにも必要となる構造をおおむね描いているので、ここで紹介する：
レイヤー1──マルチソース・オーケストレーション（Guides）。クエリが入ると、Harnessはそれをプロフェッショナルネットワーク、 ソーシャルプラットフォーム、学術データベース、公開レジストリに並列でルーティングする。 各ソースには固有の検索戦略がある。モデルは生の扇形展開を見ない── 統合された候補集合だけを見る。
レイヤー2──基準分解と検証（Sensors）。どのクエリも明示的な基準に分解される──役割、シニアリティ、地域、会社ステージ、シグナル── そしてランキングの前に、すべての候補がライブWeb検索でその基準に照らして検証される。 これはまさにPeopleSearchBenchが私たちを採点するのに使う方法論だ。偶然ではない── 私たちは、ベンチマークが測る失敗モードを念頭にHarnessを設計した。
レイヤー3──プロフィール拡充。検証を通った人物について、Harnessは構造化されたプロフィールデータをさらに引いてくる── 現職、最近の活動、連絡経路、ソーシャルでの存在感。 これが私たちのUtilityスコアが業界を引き離している理由だ： 正しい人物を返しても情報がスカスカでは役に立たない。 汎用Harnessは拡充を組み込みのステップとして実装する理由を持たない。
真ん中のモデルはモデルが得意なことをやっている──推論、ランキング、要約、判断。 Harnessはそれ以外のすべてをやっている。 Harnessを取り去ればただのチャットボットだし、モデルを取り去れば検索パイプラインだ。 二つを組み合わせて初めて、垂直Harness Agentが立ち現れる。
このことがHarness論争に意味するもの
2026年のHarness論争で最も興味深い主張は、 モデルの静的ベンチマーク上の進歩は鈍化しているが、Agentのパフォーマンスはまだ大きく開いている、 というものだ。なぜなら、残された伸びしろのほとんどはHarnessに眠っているからである。 Meta-Harnessはコーディングにおいて、より良いHarnessを自動発見することでこれを示した。 PeopleSearchBenchは反対側からそれを示す：手作業で作り込まれた垂直Harnessは、 汎用Harnessの中で動くフロンティアモデルを大差で打ち負かせる── その差は、どんなモデルアップグレードでも埋まりはしない。
これが正しいなら、2つのことが導かれる。
第一に、商業価値のあるAgent業務はすべて、自分専用のHarness Agentを持つことになる。人材検索はそのひとつだ。法律調査もそうだ。臨床推論、金融分析、サプライチェーン調査、 科学文献レビュー──どれも、汎用Harnessが永遠に最適化しない失敗モードを抱えている。 汎用Harnessはすべてを同時に最適化しているからだ。 垂直Harness Agentは、SaaSがソフトウェアのロングテールを飲み込んだのと同じ要領で、 Agent業務のロングテールを飲み込んでいくだろう。
第二に、ベンチマークも追従する必要がある。SWE-benchもTerminalBench-2も素晴らしい仕事だが、Harness品質の一断面しか測っていない。 この業界がHarness仮説を本気で受け止めるなら、価値のあるあらゆる垂直に対して Harnessベンチマークが必要だ。PeopleSearchBenchは、人材検索という垂直で 私たちが踏み出した第一歩である。データセット、評価パイプライン、結果はすべてオープンソースだ。
モデルがエンジンで、Harnessが車体だ。私たちはこの車を一本の道のために造った。 仕事が人を探すことに関わるなら──候補者、顧客、投資家、クリエイター、パートナー── ぜひこの車に乗ってみてほしい：lessie.ai。 そして、もともとそのために作られたわけではない仕事で、 私たちがフロンティアモデルのコーディングAgentをどう打ち負かしたのか── 完全なベンチマークと論文はこちら。
2026年、Harnessこそが堀（モート）だ。数字がそう語っている。