エージェントハーネスとは？研究、オープンソースプロジェクト、業界の実践

まったく同じモデルを使う2つのエージェントでも、同じベンチマークで大きく異なるスコアになることがあります。OpenAIはこれを直接測定しました。SWE-bench Liteでは、GPT-4はあるハーネスで2.7%、別のハーネスで28.3%を記録し、ハーネスだけで10倍の差が生まれました。業界の関心が「最も賢いモデルはどれか」から「実際に仕事を完了できるエージェントはどれか」へ移るにつれ、エージェントハーネスは信頼性の成否を分ける層になりました。ここから、エージェントハーネスとは何か、ハーネス設計について最新の論文やベンチマークが示すこと、注目すべきオープンソースハーネス、主要なAI研究所が自社のハーネスをどう設計しているかを紹介します。Moonshot AIが自社のハーネスと組み合わせているオープンウェイトモデル、Kimi K3.1 Proも取り上げます。

エージェントハーネスとは、大規模言語モデルが実際の環境内でエージェントとして動作するための周辺インフラです。モデルがtokenを生成するのに対し、それ以外はすべてハーネスが担います。各ステップでプロンプトを構築し、利用できるツールとその呼び出し方を定義し、サンドボックスまたはターミナルでアクションを実行し、観測結果をモデルに返し、ステップ数とコストの上限を適用し、評価やデバッグのために完全な軌跡を記録します。

この用語は評価の分野に由来します。「テストハーネス」とは、管理された条件下でシステムを実行するための仕組みです。エージェントAIでは、この考え方が本番環境にも広がりました。ハーネスは、SWE-benchやTerminal-Benchのようにエージェントを測定するための仕組みであると同時に、SWE-agent、OpenHands、Claude Codeのようにエージェントを実行するための仕組みでもあります。

AnthropicによるSWE-benchの研究では、ベンチマークは「AIモデル単体を評価するのではなく、AIモデルとその周囲のソフトウェア基盤を組み合わせた『エージェント』システム全体を評価する」と端的に説明されています。アップグレード版のClaude 3.5 Sonnetは、複雑なフレームワークではなく、1つのプロンプトと2つの汎用ツール（BashツールとEditツール）だけからなる最小限のハーネスで、SWE-bench Verifiedにおいて49%を達成しました。

長年、リーダーボードのスコア向上はモデル規模によるものとされてきました。近年の研究は、この前提を2つの方向から覆しました。

まず、「少ないほどよい」という結果です。2025年7月、SWE-benchチームはmini-SWE-agentを公開しました。bash以外のツールを使わず、メッセージ履歴は完全に線形で、すべてのアクションを独立したsubprocess.run呼び出しとして実行する、約100行のPythonからなるハーネスです。より複雑なフレームワークに匹敵するベンチマークスコアを達成しました（詳細は後述の研究セクションを参照）。ここから得られた示唆は挑発的でした。モデルが十分に高性能であれば、きわめてシンプルで予測可能なハーネスが、大規模で複雑なものを上回る場合があります。すでにMeta、NVIDIA、IBM、Princeton、Stanfordがベースラインとして使用しています。

第二に、「多ければ少ないほど悪い」という結果です。ノイズの多いツール出力、制限のないループ、不適切なエラー回復といった質の低いハーネスでは、最先端モデルでさえ平凡に見えてしまいます。OpenAIは、SWE-benchの欠陥のあるタスクを修正すると（詳細は後述のOpenAIの節を参照）、測定されるモデル性能が2倍以上に向上することを示しました。

このため、ハーネスエンジニアリングは独立した分野になっています。ハーネスが決めるのは次の点です。

• モデルに見せるもの： プロンプトの構造、ツールのスキーマ、コンテキストウィンドウに含める環境状態と履歴の量。

• モデルができること： 利用可能なツール（シェル、ファイルエディタ、ブラウザ、検索）と、実行前にアクションをどのように解析・検証するか。

• 失敗への対処方法： リトライ、タイムアウト、ウィンドウが埋まった際のコンテキスト圧縮、適切な終了処理。

• 作業の測定方法： 軌跡の記録、採点、コスト計算。これらがなければ、評価も改善サイクルも成立しません。

研究用ベンチマーク環境でも本番用コーディング支援でも、ほぼすべてのエージェントハーネスは同じ基本ループを実装しています。

1. タスクの受け取り： issue、指示、目標を読み取り、隔離された環境（通常はDockerコンテナまたはVMスナップショット）を起動します。

2. プロンプトの組み立て： システムプロンプト、ツール定義、タスクの説明、アクションと観測結果の継続的な履歴を組み合わせます。

3. アクションの解析： モデルの出力をbashコマンド、ファイル編集、APIリクエストなどの具体的なツール呼び出しに変換し、形式が不正なアクションは拒否します。

4. 実行と観測： 環境内でアクションを実行し、stdout/stderrまたはUIの状態を取得して、コンテキストの予算に収まるよう切り詰めます。

5. 制御フロー： ステップ数、コスト、停止条件の上限を適用し、人に問い合わせるタイミングやエピソードを終了するタイミングを判断します。

6. 記録と採点： 完全な軌跡を保存し、最終状態を評価します。たとえばSWE-benchでは、リポジトリのテストスイートを実行します。

各ステップの設計判断は積み重なって影響します。長期にわたるタスクでは、切り詰めの戦略だけでもスコアが大きく変動し得ます。そのため本格的に取り組むチームは、ハーネスを接着剤のようなコードではなく、バージョン管理されテスト可能なソフトウェアとして扱います。

エージェントハーネスに関する学術文献では、苦労して得られた少数の結論に収束しています。ここではすべてのベンチマークを列挙するのではなく、この分野がハーネスを真剣に捉える契機となった研究課題をたどります。

論文に入る前に、簡単に説明します。ベンチマークとは、異なるシステムを同一条件で比較できるよう設計された、固定のタスクセットと採点ルールです。エージェント評価におけるベンチマークは、タスクセット（実際のGitHub issue、ターミナルコマンド、Webタスク）、実行環境（Dockerコンテナ、ブラウザ、ターミナル）、採点器（テストスイート、状態チェック、人によるレビュー）の3つから成ります。ハーネスはモデルとこの3つすべての間に位置し、モデルの能力がスコアに現れるかどうかを左右する要素です。

実際のスコアの測定方法は、見出しの数字以上に重要です。SWE-benchでは、エージェントがコードパッチを作成し、ベンチマークが2つのテストスイートを実行します。FAIL_TO_PASS（修正前には失敗し、修正後には成功しなければならないテスト）と、PASS_TO_PASS（修正前に成功しており、修正後も失敗してはならないテスト）です。両方に合格した場合にのみ、タスクは解決済みと数えられます。このため、テスト実行や差分生成といったハーネス機能は、付加的な機能ではありません。そこで得点が決まり、失われます。

ベンチマークのスコアを読むための3つのルール：

1. スコアが何を隠しているかを問う。 公開GitHubデータで学習したモデルは、評価対象のissueそのものをすでに見ている可能性があります。データ汚染により、実際の能力向上がなくてもスコアが高く見えることがあります。再現可能な環境と未使用のタスクセットが、その対策になります。

2. グッドハートの法則に注意する： 指標が目標になると、その指標はよい指標ではなくなります。あるベンチマークで高得点を取るよう調整されたハーネスは、汎用的な能力ではなく、そのベンチマーク特有の攻略法を学んでいる可能性があります。そのため本格的に取り組むチームは、複数のベンチマークで評価します。

3. モデルだけでなくハーネスも確認する。 この節の以降で示すように、同じモデルでも、その足場となる仕組みによってスコアは2.7%にも28.3%にもなります。ハーネス名のないスコアは、測定結果ではなく逸話です。

SWE-benchの原論文（"Can Language Models Resolve Real-World GitHub Issues?"）は、現在では標準的となった評価方法を導入しました。モデルに実際のGitHub issueとリポジトリ全体を与え、そのパッチによって失敗していたテストが成功するかを評価するものです。最もよく引用される結果は、しばしば誤解されています。当時の最高性能モデルだったClaude 2が解決できたタスクは、わずか1.96%でした。著者らは、このベンチマークが「従来のコード生成を大きく超える複雑な推論」を試すものだと位置づけました。しかし後続の研究により、この差の大部分は推論能力ではなく、リポジトリを探索し、テストを実行し、反復できるハーネスがなかったことによると明らかになりました。言い換えれば、SWE-benchはモデルを測定しただけでなく、それを取り巻くハーネスこそが欠けていた要素であることを示したのです。

SWE-agentの論文（"Agent-Computer Interfaces Enable Automated Software Engineering"）は、ハーネス設計分野の基礎文献です。その中心的な主張は、インターフェース設計が最重要の変数であるというものです。著者らはAgent-Computer Interface（ACI）という用語を導入し、リンターで保護されたファイルエディタ、簡潔なシェルフィードバック、不正なコマンドへのガードレールなど、目的に合わせて設計したインターフェースによって、SWE-benchのpass@1を一桁台前半から、当時の最高水準である12.5%へ引き上げました。この論文が残した重要な貢献は、「LMエージェントは新しいエンドユーザーのカテゴリーであり」、人間にIDEが必要なのと同じように、エージェント向けのソフトウェアも必要だという主張です。その後のハーネスに関する論文はすべて、この結果を引用しています。

2024年の2本の論文は、ハーネス研究をコードリポジトリからコンピューター全体へと広げました。OSWorldは、Ubuntu、Windows、macOSにまたがる初のスケーラブルな実コンピューター環境を構築し、Webアプリとデスクトップアプリにまたがる369のタスクを用意しました。人間のタスク完了率が72.36%であるのに対し、最高性能モデルは12.24%という主要な結果は、GUIグラウンディング、すなわちモデル出力を正しいクリックやキー入力に変換することが、知識の問題ではなくハーネス上の問題として最大の失敗要因であることを示しました。WebArenaは別の角度から取り組みました。eコマース、フォーラム、GitLab、CMSを含む、セルフホスト型で完全に再現可能なWeb環境です。ここでGPT-4のエンドツーエンドの成功率は14.41%にとどまり、人間の78.24%を大きく下回りました。両論文は、ハーネスの評価はモデル出力とのパターン照合ではなく、実行に基づくものでなければならない、すなわち環境の最終状態を確認すべきだと示しました。

Sierraのτ-bench（「実世界領域におけるツール・エージェント・ユーザー間インタラクションのベンチマーク」）は、より微妙な論点を示しました。本番環境では、ハーネスはモデルと環境を包むだけでなく、ユーザーも仲介します。このベンチマークは、言語モデルのユーザーと、ドメインAPIおよびポリシーガイドラインを備えたエージェントとの動的な会話をシミュレートし、最終的なデータベースの状態を評価します。主要指標であるpass^k（独立したk回の試行における成功率）は、エージェントの一貫性のなさを明らかにしました。GPT-4oは1回の試行で解けたタスクが50%未満であり、小売分野ではpass^8が25%を下回りました。ハーネスを構築する際に重要なのは、信頼性は単発実行の性質ではなく、結果の分布に関わる性質だということです。1回だけ機能するハーネスは、機能するハーネスとは言えません。

METRの「AIが長時間のソフトウェアタスクを完了する能力の測定」は、タスク完了率50%の時間軸を導入しました。これは、モデルが50%の信頼性で完了できるタスクの長さを、人間の完了時間で測る指標です。最先端モデルは2019年から2025年にかけて、対応できるタスクの長さを数分から約1時間へと伸ばし、約7か月ごとに倍増しました。ハーネス設計にとって、これはこの10年で最も重大な発見です。2024年のモデルを制約するハーネスは、2026年のモデルにとっては役に立たない重荷です。Anthropicは、ハーネスの各コンポーネントには「モデルには何ができないか」という前提が組み込まれており、モデルの進歩とともにその前提は古くなると捉えています。

元のベンチマークは、こうした教訓を実践に移すエコシステムへと成長しました。

• SWE-bench Verified（OpenAIと共同、2024年）：仕様が不十分なタスクや不公平に採点されるタスクを除外した、500件の人手選別済みサブセットです。元のプールの68.3%が除外され、測定スコアは2倍以上に上昇し、標準のリーダーボードになりました。

• SWE-smith（2025年）：モデルを単にエージェント用ハーネスで評価するだけでなく、そのための訓練を可能にする、合成トレーニングタスク生成パイプラインです。

• mini-SWE-agent（2025年）：約100行のハーネスで、現在はSWE-bench Verifiedで74%を超えています。モデルが十分に強力であれば、線形の履歴を持つ最小限のbash専用ループで十分であることを示し、コミュニティの標準ベースラインになりつつあります。

• Terminal-Bench（Stanford × Laude、2025年）：Harborフレームワークを基盤とするターミナルタスク評価であり、ハーネスの対象をコード編集からシステム管理へと広げています。

• CodeClash（2025年）とProgramBench（2026年）：目標指向およびゼロからのソフトウェア作成を扱い、ハーネスの対象を単一の問題修正から自由度の高い開発へと拡張しています。

これらすべての取り組みに一貫する考え方は明確です。ハーネスは単なる基盤ではなく、研究対象そのものです。スコアとともにハーネスを報告し、環境を再現可能に保ち、ハーネスを検証できない結果は疑うべきです。

多くのチームはオープンソースのハーネスから始めます。以下のプロジェクトは、大規模なGitHubコミュニティ（主要プロジェクトは数万スター）と活発な保守体制を兼ね備えています。

これらから選ぶ際のコミュニティの経験則は、タスクを表現できる最小限のハーネスを使い（mini-SWE-agentの考え方）、測定可能な失敗への対処が必要になったときだけ複雑さを加えることです。DeepSeek Harnessはその対極にあり、すべてのレイヤーを差し替え可能にしたいチーム向けの、完全にプラグイン駆動のプラットフォームです。ただし、両者には共通する原則があります。それは、モデルが何を見たかを示す唯一の信頼できる情報源として、永続的で追記専用のセッションログを置くことです。

最先端の研究所はハーネスエンジニアリングを中核的な知的財産と位置づけており、その考え方を異例なほど詳しく公開しているところもあります。

Anthropicはハーネスエンジニアリングについて最も包括的な公開記録を発表しており、そのアーキテクチャは、効果的なエージェントの構築（2024年）、SWE-benchハーネスに関する記事（2024年）、Managed Agents（2026年）で詳述されています。これは同心円状の3層として捉えられます。

実行レイヤーは意図的に最小限に抑えられています。コマンドを実行するBashツールと、ファイルの閲覧・変更を行うEditツールです。設計上の工夫は、これらのツールでエラーが起きにくくすることに注がれています。絶対パスを必須とし、長い出力を切り詰め、文字列が一意に一致した場合にのみ編集を適用することで、モデルが回避可能なツール障害から復旧する必要をほとんどなくしています。

セッションレイヤーは、モデルのコンテキストウィンドウの外部に置かれる、永続的な追記専用イベントログです。すべてのアクションと観測結果がここに記録され、モデルのコンテキストはログそのものではなく、そのログを投影したものです。この分離により、失敗したハーネスプロセスを再起動してタスクの途中から再開できます。また、ハーネスを大切に管理する「ペット」ではなく、交換可能な「家畜」として扱えるようになります。

オーケストレーションレイヤー、すなわちAnthropicが「メタハーネス」と呼ぶものは、明示的なインターフェースを通じて「頭脳」（モデルとそのループ）を「手」（サンドボックスとツール）から分離します。頭脳が実行コンテナ内に存在しなくなるため、サンドボックスは必要に応じてプロビジョニングでき、認証情報はサンドボックスが決して触れない保管庫に保持できます。報告されている効果は見た目だけのものではなく、構造的なものです。使用されない可能性があるコンテナをセッションが待たなくなったことで、最初のtokenまでの時間のp50は約60%、p95は90%以上短縮されました。

この進化は、効果的なエージェントの構築（2024年）、SWE-benchハーネスに関する記事（2024年）、Managed Agents（2026年）の3つの文書でたどれます。

OpenAIは、ハーネスには適切に整理されたタスクが必要であることから、SWE-benchチームと提携して人手で検証したVerified分割を作成しました。注釈付けキャンペーン（開発者93人、サンプル1,699件）では、元のベンチマークのタスクの68.3%に問題があることが判明し、それらを除外すると測定された性能は2倍以上になりました。同じ記事では、ハーネスの選択だけでSWE-bench LiteにおけるGPT-4のスコアが2.7%から28.3%へ変わったと述べています。この差を根拠に、評価ではコミュニティが構築したハーネスの進歩も考慮すべきだとしています。

オープンソースでは、Codex CLIが完全なリファレンスハーネスとして提供されています。そのアーキテクチャは、このセクションのほかのシステムと同様に階層化されています。中核エージェントループが計画とツール呼び出しを処理し、サンドボックスレイヤーがタスクごとに設定可能なポリシーで実行を分離します。セッションレイヤーは会話を永続化し、再開、分岐、圧縮を可能にします。ツールレイヤーはローカルシェルへのアクセスと、MCPベースの外部ツールの両方を提供します。単一のインターフェースに固定するのではなく、同じエンジンを3つの形で提供しています。対話作業用のターミナルUI、VS Codeのようなリッチクライアント向けのJSON-RPC アプリサーバー、クラウドサンドボックス向けのリモートコード実行サービスです。これにより、ハーネスはローカルで実行することも、プログラムから操作することもできます。この設計は、研究文献が推奨するのと同じトレードオフを採用しています。最小限のループ、堅牢なサンドボックス、明示的なコンテキスト管理、そしてモデルと外部世界との明確な境界です。

Agent Development Kit（ADK）とAgent2Agent（A2A）プロトコルにより、Googleはハーネス層の製品化を進めています。これらはAtlassian、Salesforce、SAP、ServiceNowを含む50社以上のテクノロジーパートナーとともに2025年4月に公開されました。A2Aは、エージェントが機能を公開する方法（JSONの「Agent Cards」を使用）、長時間実行されるタスクの管理、成果物の交換、UI形式の交渉を標準化します。これにより、ハーネスは個別に作られた接着剤ではなく、相互運用可能なインフラになります。これは、ハーネスのツール側を標準化するAnthropicのModel Context Protocol（MCP）を補完するものとして明確に設計されています。

MicrosoftのAutoGenとMagentic-Oneには、オーケストレーターエージェントが事実と進捗の台帳を管理するハーネスが搭載されています。これは、単純なハーネスを悩ませる無制限のループを防ぐために公開された設計です。MetaとHugging FaceによるGAIAは、Webナビゲーションやファイル操作を必要とする現実世界の質問をハーネスで評価する、汎用アシスタント向けベンチマークを作りました。Hugging FaceのOpen Agent Leaderboardも、比較可能でハーネスを考慮したランキングを推進し続けています。

DeepSeek Harness（dsh）は、メタハーネスという考え方を組み合わせ可能な形にしています。そのアーキテクチャはCordisフレームワークに基づき、中心的な主張は、ハーネスのあらゆる部分が置き換え可能なプラグインであることです。モデルアダプター、ツールレジストリ、セッションログ、エージェントループそのものも含まれます。

この設計は3つの基本要素に基づいています。第1に、モデルが参照した内容の唯一の信頼できる情報源となる永続的なセッションログです。モデルに届くものはすべてログから再構成できなければならず、これは実行時の不変条件として強制されます。第2に、機能の境界面です。これはエージェントと外部世界の間にある差し替え可能なプロバイダーインターフェースで、ファイルシステムおよびサブプロセスのプロバイダーをリモートサンドボックスに向けるだけで、ハーネスを分岐させずにBash、ターミナル、言語サーバーへのアクセスも移動できます。第3に、名前付きの拡張イベント（agent/pre-step、tools/execute、agent/turn-stopping）を備えた明示的なターン／ステップのライフサイクルです。これにより、プラグインはコアコードを変更せずにループを横取りしたり書き換えたりできます。

その結果は、Anthropicのメタハーネスをオープンソースで最も忠実に実現したものです。構造は固定フレームワークではなく、設定から入れ替えられるプラグインの組み合わせで構成されます。公開後数か月でGitHubスターを17万以上獲得したことは、エージェントハーネスが独自の製品カテゴリになりつつあることを示しています。

これらすべてに共通するパターンは、ループをシンプルに保ち、あらゆるものをサンドボックス化し、すべてのステップを記録し、それを生んだハーネスなしにスコアを信用しないことです。

ここまでのこのセクションで扱った最小限のループ、永続的なセッションログ、サンドボックス化された実行、プラグインアーキテクチャには、共通する前提があります。エージェントの環境はコンピューターである、という前提です。ターミナル、ブラウザー、ファイルシステム、リポジトリ。ハーネスは、エージェントがそのマシンを確実に操作できるようにするために存在します。

しかし、ここまでたどった研究の流れは別の方向を指しています。τ-benchはユーザーをハーネスの内部に置きました。METRは、エージェントが数分ではなく数日にわたる作業を担うことを示しました。OSWorldとWebArenaは、環境を整ったリポジトリから雑多な現実世界へ移しました。方向性は一貫しています。エージェントがコーディングツールから実際の業務アシスタントへ移行するにつれ、操作すべき環境は単なるシリコンではなくなります。期待を持つユーザー、履歴を持つチーム、権限と組織的知識を持つ組織です。

この変化が最も大きく影響するハーネスのサブシステムは、コンテキスト管理です。ターミナルセッションには1人の操作者と限られた履歴があります。一方、長期にわたる取り組みには10人の関係者、数か月分の意思決定、そして増え続けるリポジトリがあります。ファイルシステムは受動的ですが、協働関係には、暗黙の約束、まとまりきらない考え、何気なく下された選択が絶えず流れ込みます。これらはすべて、モデルに届く前に要約、圧縮、または削除しなければなりません。その一つひとつの判断で、エージェントはタスクに必要な何かを失う可能性があります。

ハーネスは圧縮できますが、無制限に圧縮できるわけではありません。だからこそ、コンテキストウィンドウの大きさはモデル仕様ではなく、ハーネス設計のパラメーターになりました。

Moonshot AIのハーネスポートフォリオは、この記事の前半で定義した構造を1つのマネージドスタックに対応付けています。Agent × Computerの課題に対し、そのハーネスは標準ループを拡張します。Kimi Browser Extensionは、無菌的なサンドボックスではなくChrome DevTools Protocolを通じて実際のブラウザーセッションを操作します。Ask-before-actingという境界面はファイルシステムレベルで同意を確保し、Agent Swarmは長期タスク向けのオーケストレーションを300のサブエージェントまで拡張します。

このループを動かすのがKimi K3.1 Proです。K3.1シリーズ初のモデルであり、Moonshot AIがこれまでに公開した3Tクラスのオープンウェイトモデルの中で最も高性能です。コンテキストウィンドウは1,048,576 tokenです。ハーネス設計に直接関わる特性は3つあります。

• 圧縮を先送りできるほど大きなウィンドウ。 100万tokenあれば、作業中のリポジトリ、進行中の軌跡、参照ドキュメントを同時に保持できます。ハーネスは依然として切り詰めを行います。常にそうする必要があります。しかし、要約によって情報が失われ始めるしきい値が十分先へ移るため、長期タスクが途中で気付かないうちに劣化することがなくなります。

• ハーネスで調整できる推論量。 K3.1 Proは常に推論を行い、reasoning_effortにはlow、high、maxを指定できます。デフォルトはmaxです。これにより、モデルの推論コストは固定の利用料金ではなく、ハーネスがタスクごとに設定する予算になります。

• エピソードの途中で追加されるツール。 動的ツール読み込みにより、ハーネスは完全なツール定義をシステムメッセージ内に注入できます。すると、そのツールはそのメッセージ以降で利用可能になります。再起動は不要で、そのツールを使わない会話の各ターンでスキーマのコストを支払う必要もありません。

Moonshotはモデルとともにハーネスも報告しており、これはこの記事全体で主張してきた姿勢です。Terminal-Bench 4.0は、厳格なタスク固有のテストの下、現実的でリソース制約のあるターミナルタスクにおけるコーディングエージェントを評価します。ここでK3.1 Proは65.7%に達し、GPT-6 Astraの58.2%を上回り、Claude Opus 5.5の66.4%にわずかに及びません。複数ステップの実行、ツール利用、エンドツーエンドの問題解決を対象とする社内ベンチマークKimi Code Bench 3.0 Long-horizonでは、K3の55.95%に対して61.2%を記録しています。ドキュメントでは逆方向の結び付きについても同様に明示されています。temperatureやtop_pなどのサンプリングパラメーターは固定されており、リクエストから省かなければなりません。また、完全なアシスタントメッセージはターン間で変更せずに返す必要があります。メッセージを書き換えるハーネスでは、次のツール呼び出しが依存する推論が失われます。

同じモデルがすべての利用形態で動作します。Kimi AgentでマネージドWeb版を試すことも、Kimi Workで完全なローカルハーネスを実行することも、Kimi Codeでターミナルから作業することも、Kimi APIを通じてkimi-k3.1-proを直接呼び出すこともできます。kimi-k3.1-pro-highspeedバリアントでは、token単価がおよそ2倍になる代わりに、出力速度が2～3倍になります。

モデルを評価する場合も製品をリリースする場合も、同じチェックリストが適用されます。

1. フレームワークではなくタスクから始める。 エージェントがコードを編集するなら、SWE-agentのACIのようなBashとエディターを組み合わせたハーネスが実証済みです。GUIや実際のWebを操作するなら、実セッションの観測とクリック単位のアクションが必要です。

2. 環境を再現可能にする。 Dockerイメージ、固定した依存関係、シード済みデータの有無が、ベンチマークと単なる逸話を分けます。

3. コンテキストウィンドウを計画的に配分する。 観測の切り詰め、履歴の要約、圧縮は、スコアとコストを直接左右するハーネス機能です。長いコンテキストを扱えるモデルは、ハーネスが捨てる必要のある情報量を減らします。

4. 厳格な上限を設ける。 エピソードごとのステップ上限、実時間タイムアウト、金額予算により、エージェントの安全性を保ち、評価の比較可能性を確保します。

5. 初日から完全な軌跡を記録する。 人によるレビュー、失敗パターンの分類、ファインチューニングといった本格的な改善ループはすべて、軌跡データを必要とします。AnthropicのManaged AgentsとDeepSeek Harnessはさらに進んでいます。セッションログを追記専用のイベントストリームとしてハーネスループの外部に置くことで、ハーネス自体を使い捨て可能にし、モデルのコンテキストを常に再構成できるようにしています。

6. 複数のハーネスで評価する。 エージェントが1つのハーネス内でしか動作しないなら、構築したのは能力ではなく、ハーネス固有の振る舞いです。

7. 認証情報をサンドボックスの外に置く。あるいは、完全にクラウドの外に置く。 エージェントの実行環境は信頼できないものとして扱ってください。tokenは保管庫に置き、プロキシ経由で注入するか、認証情報とページコンテンツがデバイス外へ出ないようセッション全体をローカルで実行します。後者はKimiがローカルハーネスで採用している方式です。

エージェントハーネスは、いつの間にかエージェントスタックで最も重要な層になっています。SWE-bench、mini-SWE-agent、Terminal-Bench、METRの研究では、ハーネス設計がモデルのアップグレードに匹敵する影響を持ち得ることが示されています。DeepSeek Harness、OpenHands、SWE-agent、Aiderといったオープンソースプロジェクトにより、本番運用レベルのハーネスは誰でも利用できるようになりました。Anthropic、OpenAI、Google、Microsoft、Moonshot AIはいずれも、ハーネスエンジニアリングを今や主要な取り組みとして位置付けています。

しかし、より本質的な変化は概念面にあります。第1世代のハーネスは、エージェントとコンピューターの連携を解決しました。つまり、モデルがターミナル、ブラウザ、ファイルシステムを確実に操作できる手段を与えたのです。次世代は、そうした環境で生じるコンテキストの問題に取り組んでいます。数日にわたり、関係者やリポジトリをまたぐ作業は、どんな要約ツールでも情報を損なわずに圧縮できません。ハーネスは足場から実行環境へと進化しており、ハーネスが管理すべきことと、モデルがそのまま保持できることの境界は変わり続けています。Kimi K3.1 Proの100万tokenウィンドウは、その最も明確な現在の例です。モデルの変更によって、これまでハーネスが担わなければならなかった作業が不要になります。

自社で構築する場合も、オープンソースフレームワークを導入する場合も、本番用ハーネスを運用する場合も、ハーネスを設計・バージョン管理・測定の対象となるソフトウェアとして扱うチームこそ、エージェントに実際に仕事を完了させられます。