コーディングエージェントを業務に入れたチームから、「モデルを最新版に替えたのに、思ったほど良くならない」「同じモデルでも、ツールによって結果がまるで違う」という声をよく聞くようになりました。
その答えとして、いま arXiv で急に語られ始めているのが 「エージェント・ハーネス（agent harness）」、つまりモデルの周りにある「何を見せるか・どのツールを使わせるか・どうループを回すか」を決める外側のコードです。Claude Code や Codex のような製品で、モデル以外の部分すべてを指す言葉だと考えると分かりやすいでしょう。
本記事では、当ブログ独自の arXiv 急上昇ワード集計 で直近 3 か月にいちばん伸びたこのテーマについて、実務に効く論文を 4 本選んで解説します。
目次
- 📈 今月の急上昇ワード（ソフトウェア工学 cs.SE）
- 1. 【同じモデルでも別物】コンテキストが狭い条件では、ハーネスを替えるだけで解ける課題が 43 件 → 72 件に
- 2. 【どこに効くか】コンテキスト管理は「窓が狭いほど」効く。計画はモデルが強いとコスト削減に変わる
- 3. 【自動で育てる】ハーネスを「進化」させるだけで業務タスクが 20〜35 ポイント改善
- 4. 【ハーネスは攻撃面】ハーネスが組み立てるコンテキストで、低い権限の指示が「昇格」する
- ハーネスを現場で設計する 3 大原則
- まとめ
📈 今月の急上昇ワード（ソフトウェア工学 cs.SE）
cs.SE に投稿された論文を毎月 250 本ずつ集め、各概念が「論文全体の何 % で語られたか」を、直近 3 か月（2026年7〜9月）とその前の 6 か月（1〜6月）で比べました。
| 順位 | キーワード | 直近3か月 | 前6か月 | 伸び |
|---|---|---|---|---|
| 1 | agent harness（エージェント・ハーネス） | 1.6% | 0.3% | 3.1倍 |
| 2 | tool call（ツール呼び出し） | 2.5% | 0.9% | 2.3倍 |
| 3 | digital twin（デジタルツイン） | 1.7% | 0.6% | 2.3倍 |
| 4 | coding agent（コーディングエージェント） | 7.9% | 4.1% | 1.9倍 |
| 5 | agentic ai（エージェント型 AI） | 2.4% | 1.3% | 1.7倍 |
| 6 | model context protocol（MCP） | 2.5% | 1.5% | 1.6倍 |
※「伸び」は、少数の偶然で跳ねないよう平滑化した値です（集計方法は末尾を参照）。
agent harness という言葉を使った論文は、2026年4月まで 0 本でした。5月に初めて現れ、8月には 250 本中 8 本（3.2%）まで増えています。
分野をまたいでも同じ動き:
coding agentはセキュリティ（cs.CR）で 2.6 倍、自然言語処理（cs.CL）で 2.1 倍と、3 分野すべてで上位に入りました。セキュリティ分野では、ほかにradio access network（無線アクセス網, 2.5倍）とcpu（2.2倍）が伸びています。
1. 【同じモデルでも別物】コンテキストが狭い条件では、ハーネスを替えるだけで解ける課題が 43 件 → 72 件に
- 関連論文: Same Model, Different Harness: Different Coding-Agent Results (arXiv:2608.26218)
💡 現場の課題
エージェントの比較や選定は、「どのモデルが強いか」で語られがちです。しかし実際に使うのは「モデル＋ハーネス」の組み合わせで、ハーネス側の差がどれだけ効くのかは見過ごされてきました。
📄 論文が明かす最新知見
- モデルと課題を固定し、ハーネスの設定だけを変えて比べた
- 主な変更は、コンテキストが埋まってきたら古いツール出力を機械的に短くすることと、同じ作業の繰り返しや停滞を検知して介入すること
- コンテキスト窓が狭い条件（Qwen3.6, 20,480 トークン, 169 課題, 1 課題 480 秒まで）で、SWE-bench Verified の完全解決が 43 件 → 72 件。修正後に通るべきテストのうち実際に通った割合（課題ごとの平均）は 28% → 49%
- 窓が広い条件（262,144 トークン）では、Verified と Pro で 2 つの設定の差はほぼ消えた（FeatureBench では改善が残った）
- モデルごとに調整し直さなくても、設計の異なる別の 3 モデルでも改善した
- 結論: エージェントの評価では、「モデルとハーネスを一体の解答者」として扱うべき
2. 【どこに効くか】コンテキスト管理は「窓が狭いほど」効く。計画はモデルが強いとコスト削減に変わる
- 関連論文: An Empirical Study of Harness Design for Coding Agents (arXiv:2609.20804)
💡 現場の課題
「計画を立てさせる」「専用ツールを用意する」「履歴を要約する」など、ハーネスの工夫は多いものの、どの部品がどれだけ効くのかは分かっていませんでした。そのため、自社用に作るときに何を優先すべきか判断できません。
📄 論文が明かす最新知見
- 4 モデル × SWE-Bench Verified / Terminal-Bench 2.1 で、176 通りの設定を部品ごとに比較した
- コンテキスト管理は窓が小さいほど効く。効果の大半は「あふれて落ちる失敗」を防ぐことによるもの
- 最も効率が良いのは、ルールで削ってから LLM で要約するという 2 段構え。削った内容を後から取り出せる仕組みを足しても、モデルがほとんど使わず精度は上がらない
- 計画ステップは、弱いモデルでは精度を支え、強いモデルでは主にコスト削減として働く
- bash が得意なモデルなら、専用ツールを揃えなくても bash だけで十分動き、コストも大きく下がる（特にコマンド操作が中心の Terminal-Bench で。SWE-Bench では専用ツールの方が良いモデルもあった）
3. 【自動で育てる】ハーネスを「進化」させるだけで業務タスクが 20〜35 ポイント改善
- 関連論文: StarHarness: Evolving Harnesses with Stratified Search for Enterprise Environments (arXiv:2608.24804)
💡 現場の課題
SRE、ITSM、経理など社内の業務環境には、独自のツールや慣習があります。汎用のエージェントをそのまま持ち込むと、モデルと環境のミスマッチでつまずきます。とはいえ、モデルを追加学習するのは重い作業です。
📄 論文が明かす最新知見
- モデルの重みは固定したまま、プロンプト、ツールの与え方、スキル、MCP、サブエージェント構成、ループ設定といったハーネス側を自動で改良する
- 失敗の傾向で課題を層別化し、「改良案を探す課題」と「採否を決める課題（提案側からは見えない）」を分けて、過剰適合を防ぐ
- ITBench SRE / EnterpriseOps-Gym ITSM / AutomationBench Finance で、採用した変更は環境ごとに 4〜12 件だけで、既定のハーネスと比べて 20〜35 ポイント改善（改良に使ったモデル GPT-5.4 での値）
- 改良に使わなかった課題でも効果が残り、GPT 系と Qwen 系の間で作り直さずに流用できた
- 効いていたのは、インターフェースの修正、環境の慣習、運用知識の書き込みといった地味な改善。一部の環境では誤診断が減り、手順（ターン数）も短くなった
4. 【ハーネスは攻撃面】ハーネスが組み立てるコンテキストで、低い権限の指示が「昇格」する
- 関連論文: When Context Gets Root: Privilege Escalation in LLM Harnesses (arXiv:2608.27299)
💡 現場の課題
モデル側には「システム指示 ＞ ユーザー ＞ ツール出力」のような指示の優先順位（instruction hierarchy）で守る仕組みがあります。しかし、実際にどの文字列をどの立場でモデルに渡すかを決めているのはハーネスです。
📄 論文が明かす最新知見
- ハーネスがコンテキストを組み立てる過程で、低い権限の悪意あるコンテンツが上位の指示として扱われてしまう攻撃「instruction privilege escalation」を提示した
- マルチエージェントの仕組みを使った攻撃で、6 つのコーディングエージェント向けハーネスを検証した。操作を無制限に許可した設定では、機密性・完全性・可用性・リモートコード実行にわたる 13 の攻撃目標をすべて達成（各目標で数回までの試行を重ねた結果。1 回あたりの成功率はハーネスにより 31.7〜100%）
- 自動の権限レビューを備えた 3 つのハーネスでも、13 目標すべてが成功した
- ハーネスの「永続的なゴール」や「スケジュール実行」の機能経由でも再現できた
ハーネスを現場で設計する 3 大原則
- 評価は「モデル＋ハーネス」の組で行う
モデルを比べる前にハーネスを固定する。ベンダー公表値と自社の結果が違うのは、ハーネスが違うからかもしれません（論文1）。 - 窓が狭い・作業が長いなら、まずはコンテキスト管理から。足すより削る
古いツール出力の機械的な切り詰めとルールによる削除が最初の一手です。専用ツールや計画ステップは、モデルの得意不得意を見て足します（論文1・2）。 - ハーネスは「育てるもの」であり「守るもの」
失敗ログから少しずつ改良し、採否は別の課題で判断する（論文3）。同時に、コンテキストを組み立てる箇所を権限境界として監査します。論文4が示すとおり、ハーネスの設計は性能の問題であると同時に、セキュリティ境界の問題でもあると考えるべきでしょう。
まとめ：エージェント選びは「どのモデルか」から「どう包むか」へ！
7〜9 月の arXiv では、「agent harness」という言葉が前の半年の約 3 倍（平滑化後の値）の割合で語られました。論文から見えてくるのは、同じモデルでも包み方次第で成果が大きく変わり、しかもその包み方は自動で改良できるという流れです。一方で、ハーネスは新しい攻撃面にもなっています。
次にエージェントを見直すときは、モデルの載せ替えより先に、ハーネスのコンテキスト管理と権限設計を点検してみてください。
集計方法について
- 対象: arXiv cs.SE の各月の投稿から直近分 250 本ずつ（2025年9月〜2026年9月, 計 3,250 本。9月は 9/10〜9/23 投稿分）
- 論文のタイトルとアブストラクトから概念を自動抽出し、概念ごとに「その月の論文の何 % で言及されたか」を集計
- 伸び = 直近 3 か月の言及率 ÷ 前 6 か月の言及率（少数の偶然で跳ねないよう平滑化）。「実験結果」「ベースライン」などの汎用語は除外
- 抽出は自動のため表記ゆれや取りこぼしがあります。ランキングは「何が語られているか」の目安であり、将来の予測ではありません
2026-10-01 更新: 論文1の、コンテキスト窓が広い条件での結果の記述の誤りを修正しました
