Qoder「Better Harness」とは？AIコーディングのワークフローを“証拠”で見直すオープンソース

コードの出来だけでなく、「コードを作る仕組み」を見る

QoderのBetter Harnessは、AIコーディングエージェントを取り巻くワークフローをレビューし、改善するためのオープンソースプロジェクトです。単発の回答やコード差分だけを採点するのではなく、リポジトリの指示、ルール、権限制御、テスト、レビュー、リリース確認、実際のセッション記録などを対象にします。根拠が確認できる課題を見つけ、範囲を限定した修正案と、その後に確認するための受け入れ条件を示すことが狙いです。124

報道によれば、Qoderは2026年7月28日にGitHubでBetter Harnessのオープンソース化を発表しました。5

Qoderがここでいう**ハーネス（harness）**とは、エージェントが仕事をするための周辺環境です。具体的には、リポジトリ内の指示、ルール、スキル、フック、プラグイン、コネクター、スクリプト、テストコマンド、リリースチェック、人によるレビュー工程などが含まれます。2

つまり問うのは、「モデルがもっともらしいコードを書いたか」だけではありません。その変更を、理解可能で、管理され、検証され、リリース可能な形で、繰り返し届けられる工程になっているかです。

3層でつながるフレームワーク

Better Harnessは、実践、評価モデル、実行可能な実装を結ぶ3層の枠組みとして紹介されています。5

1. Harness Engineeringの実践

第1層は、エージェントの仕事の質を左右する実務的な仕組みです。セッションやCLIの運用、可観測性、ルール、スキル、MCP設定、メモリ、フック、自動化などが対象です。5

ここでは、例えば次のような点を確認します。

• エージェントに目的、制約、リポジトリの文脈が明確に渡っているか
• 実行経路や権限が適切に制御されているか
• テスト、チェック、レビューが変更作業と結び付いているか
• 失敗や学びを、単発の会話で終わらせずプロジェクト資産として残せるか

Better Harnessはまず、目的、コンテキスト、実行の入口、フィードバックループ、成果物の届け方、学習内容の記録方法を含む、現在のハーネスを整理します。1

2. Agent Work Loopの評価

第2層は、実践を5つの連続した評価軸に落とし込みます。Qoderの資料では、タスク理解、制御された実行、変更の検証、信頼できるデリバリー、学習の蓄積として説明されています。14

この見方では、問題は「テストコマンドが存在するか」では終わりません。エージェントが変更後に適切なテストを実行し、結果を解釈し、問題のある変更を出荷しないために活用できたかまでが重要になります。

評価モデルは、必要な仕組みの欠落、仕組み同士の未接続、実行されなかった工程、結果を裏付ける証拠の不足といった、工程内の切れ目を特定するためのものです。1

3. 実行可能な実装

第3層は、実践や評価モデルを文書上の理想論にとどめず、実プロジェクトで動かせる形にする部分です。Better Harnessはコーディングエージェント経由で動作し、対応する範囲でプロジェクトやセッションの証拠を収集。優先順位付きの改善案と、検証可能な次の手順を生成します。4

現在のプロジェクト資料では10のホストアダプターに対応するとされ、公開当時の報道ではClaude Code、Codex、Qoder、Cursorが対応環境として挙げられました。56 ただし、対応範囲は更新され得るため、特定のホストとの連携は最新のアダプター文書で確認する必要があります。提供された資料からは、OpenClaw対応は確認できません。

3種類の証拠を分けて集める理由

Better Harnessの特徴は、証拠収集と最終評価を分けていることです。メインの分析フローが生データを集めた後、3つの独立した読み取り専用サブエージェントが確認し、結果を統合するとQoderは説明しています。1

3つの観点は次の通りです。

• Project Harness：リポジトリにある指示、スクリプト、チェック、デリバリー制御など、開発の土台
• Agent Customization：エージェント固有のルール、スキル、フック、各種設定
• Session Evidence：実際の作業セッションでエージェントが何をしたかを示す記録。利用可能な場合に収集

この分離により、「使えるはずの機能」と「実際のタスクで適切に使われた機能」を区別できます。プロジェクトや設定の証拠は、能力が用意されていることを示します。一方、セッションの証拠は、その能力が実作業で使われたかを確かめる手掛かりになります。14

「存在する」は「機能している」ではない

この仕組みの要点は、成果物の存在を有効性の証拠と取り違えないことです。

たとえば自動テスト一式がリポジトリにあれば、検証する能力が潜在的にあることは分かります。しかし、それだけで、エージェントが変更後に関連テストを実行したこと、結果を正しく扱ったこと、失敗した変更のデリバリーを防げたことまでは分かりません。ルール、フック、スキル、承認ゲートも同様です。15

Better Harnessは、裏付けのある課題を、影響、期待される出力、修正範囲、受け入れ条件とともに優先順位付きのFindingとして示します。証拠がない点は、確信度の高いスコアに勝手に置き換えず、そのまま可視化する方針です。46

チームは各Findingについて、少なくとも次を確認できるべきです。

1. プロジェクト、設定、またはセッション記録から何が観測されたのか
2. それが開発工程のどこに影響するのか
3. ルール、スキル、フック、スクリプト、自動化、人の承認など、どの限定的な修正を提案するのか
4. 修正後に何をもって確認するのか

点検して終わりではなく、修正後に再計測する

Better Harnessは一度きりの監査ではなく、反復的な改善ループとして位置付けられています。

1. 現在のハーネスを整理する
2. 工程の切れ目と証拠不足を特定する
3. 裏付けのある課題に対して、範囲を限定した修正タスクを作る
4. 定義済みの受け入れ条件で修正を検証する
5. 再度レビューし、更新後の証拠を確認する。14

この手順は、ワークフローが変化したことや、よりよい評価を支える新たな証拠が得られたことを示す助けになります。ただし、ある修正がすべてのプロジェクトやホスト環境でエージェントの性能向上を引き起こしたと証明するものではありません。Qoderの資料も、観測された証拠と明示的な限界を重視しています。46

「実在するGitHubプロジェクト30件」の評価はどう見るべきか

公開時の報道では、初期的な取り組みとして実在するGitHubプロジェクト30件にこの枠組みを適用したとされています。5 ただしこれは、あらゆるコーディングエージェントやリポジトリで改善効果を保証する統制実験ではなく、フレームワークの探索的な適用例として読むのが妥当です。

提供された一次資料は、証拠モデル、Findingの構造、反復的な修正フローを裏付けています。一方で、30件の選定方法、採点プロトコル、集計結果を独立に検証できるほどの詳細は、提供資料からは確認できません。14

AI支援開発を測定可能な工程へ

Qoderが掲げるより広い狙いは、Harness EngineeringをAI支援ソフトウェア開発の品質基盤にしていくことです。すなわち、ワークフロー制御の共通語彙、観測可能な証拠、比較可能な評価軸、繰り返せる改善サイクルを整えるという考え方です。12

Better Harnessの価値は、「この設定を入れれば必ず成果が上がる」と約束することではありません。対応ホスト上でエージェントを取り巻く条件を点検し、印象論ではなく証拠をもとに議論し、改善案が次回の実行でも成り立つか検証するための、より規律だった方法を提供する点にあります。46