EN|JA

DevGENT

Better Harness

Better Harnessとは｜5次元でLoop採点

Better HarnessはCoding AgentのLoopを5次元で採点するMIT OSS。導入手順・非…

krona23
29〜44分

Coding Agent の品質が安定しないとき、まず疑うのはモデルの世代差です。しかし現場では、次のような ループ側の摩擦 が同じ失敗を繰り返すことも多いです。

📑目次
  1. Better Harness 概要（何を見るツールか）
  2. 5次元の見方と Finding の読み方
  3. ホスト別の入れ方とレポートの出方
  4. 勝手に直さない設計と改善の回し方
  5. 導入すべきか（判断チェックリスト）
  6. よくある質問（FAQ）
  7. まとめ — 次にやること
  • ゴールの曖昧さ
  • 再現できない手順
  • 検証不足
  • レビューすり抜け
  • 教訓が残らない

Better Harness は、その摩擦を diff 単体ではなく Agent Work Loop（5次元） とプロジェクト harness の証拠からレビューし、優先度付き Finding に落とす MIT の OSS です。Claude Code / Codex / Cursor / Qoder 向けの導入経路があり、製品ドキュメント上は 勝手に直さず、人が承認した修正だけを進める 設計です。

この記事では、次を実務順に整理します。

  • 何を採点するか
  • ホスト別の入れ方
  • Finding の読み方
  • 導入判断のチェックリスト

Better Harness 概要（何を見るツールか）

結論

Better Harness は「より賢いモデル」を選ぶツールではなく、Coding Agent を支える harness と Work Loop の切れ目を可視化する診断器です。最終 diff や単発の応答品質だけを見るのではなく、タスク理解から学習の残し方までを証拠付きでレビューします。

なぜ Loop を見るのか

「できることが多い」と「信頼して納品できる」は別問題です。ゴール、触ってはいけない境界、正しさの判定、失敗時の扱いが無いと、テストを回しても done を証明しにくい、という整理が Qoder Docs の Better Harness にあります。

三層の開き方

公開 README と Docs は、次の三層をつなぐ実装だと説明しています。

  1. Engineering practices — Session Evidence / Project Harness / Agent Customize / Loop Engineering の指針
  2. Evaluation model — Agent Work Loop、証拠状態、Finding、縦断検証
  3. Runnable implementation — /better-harness skill、collector、analyzer、host adapter

証拠は相互汚染を避けるため、Agent customization / real task sessions / project engineering foundations の 三系統を独立収集してから統合する、という方針です。

概要表

項目 内容
種別 Coding Agent 向け harness / Loop レビューと改善起動
ライセンス MIT
実行要件例 Node.js >= 22.20.0（開発・pack 時）
評価軸 Task Understanding / Controlled Execution / Change Validation / Reliable Delivery / Learning Capture
証拠方針 設定の存在だけでは能力有効とみなさない。タスク証拠にリンク
修正方針 自動適用しない。Plan a fix → Quest 等で人が承認
主なホスト Claude Code / Codex Desktop・CLI / Qoder / Cursor（source-local）
内部評価言及 独立報道が 30 の実 GitHub プロジェクト評価に言及

出典: GitHub QoderAI/better-harness、Qoder Docs: Better Harness、IT之家 報道（2026年7月時点）

IT之家による Qoder Better Harness 開源報道の画面
独立報道側でも Claude Code / Codex / Qoder / Cursor 対応と証拠主義の説明が確認できる（IT之家）

出典

再結論

モデル比較記事の代替ではなく、運用ループの欠陥を直すための診断と改善タスク化として読むのが安全です。

5次元の見方と Finding の読み方

結論

スコアは雰囲気の点数ではなく、各次元の問いと根拠資産に紐づく ギャップ提示です。Finding は priority・原因・期待出力・修正指示を伴い、人がスコープを切って直せます。

次元表

次元 主な問い 根拠になりやすい資産例
Task Understanding ゴールと done が分かるか Rules, AGENTS.md, specs, DESIGN.md
Controlled Execution 再現可能な経路・権限内か Skills, commands, MCP, sandbox
Change Validation 変更が動く証拠があるか tests, lint, Hooks, diagnostics
Reliable Delivery 速度がレビュー/受入をすり抜けないか human review, approvals, CI/CD, recovery
Learning Capture 次タスクに教訓が残るか reusable Skills, Memory, Loop Discovery

出典: GitHub README、Qoder Docs（2026年7月時点）

Finding の中身

Docs 上の Finding カードはおおむね次を含みます。

  • priority: High / Medium / Low
  • Cause（原因）
  • Expected Output（期待される出力）
  • Fix Instructions（編集可能な修正指示）
  • Plan a fix（修正タスク起動）

誠実さルール（README 側）

  • 未観測は推測スコアにせず明示する
  • 現状チェック通過は「介入が実行された」証明までを求める
  • ループ改善の因果は、後続の比較可能な結果が必要

「設定ファイルがあるのに低スコア」はよくある誤解です。設定の存在と、実タスクで使われた／成果に寄与した証拠は別物で、未使用や未検証はギャップとして残ります。

ホスト別の入れ方とレポートの出方

結論

ホストごとに marketplace / plugin-dir 手順が違います。インストール後は 新セッション で inventory を再読込してからレポートを出します。

共通プロンプト例

/better-harness review this project's AI coding workflow and generate a report

Claude Code

  1. /plugin marketplace add QoderAI/better-harness
  2. /plugin install better-harness@better-harness
  3. claude plugin details better-harness@better-harness で Skills を確認
  4. 新セッション でレポート生成

既定出力は .claude/better-harness 配下の report.html / report.md / findings.json です。

Codex Desktop

Settings > Plugins > + Add > From Marketplace で https://github.com/QoderAI/better-harness.git（ref main）を追加し、@better-harness ... で起動します。

Codex CLI

codex plugin marketplace add 'https://github.com/QoderAI/better-harness.git' --ref main
codex plugin add better-harness@better-harness
# 例: $better-harness:better-harness review this project's AI coding workflow and generate a report

Qoder

Desktop 導入時は組み込み（UI の Better Harness または /better-harness）。CLI は marketplace 追加/install が可能で、レポートは Canvas 中心です。

Cursor

marketplace 未公開（2026-07-29 README 時点）。source-local のみです。

git clone https://github.com/QoderAI/better-harness.git
cursor-agent --plugin-dir /path/to/better-harness

制限とホスト差

  • Cursor は source-local のみ
  • セッション証拠のカバレッジはホスト差があり、欠落は明示される想定
  • Qoder UI では Fix は Quest 経由。自動で repo を書き換えない

出典: GitHub README、Qoder Docs

勝手に直さない設計と改善の回し方

結論

Better Harness の価値は一括自動修復ではなく、人が承認できる最小修正の起動にあります。

Qoder 側フロー（Docs）

  1. スキャン（初回はプロジェクト構造理解のフェーズあり）
  2. 5次元バー + Finding カード
  3. Plan a fix（Cause / Expected Output / Fix Instructions）
  4. Quest で plan レビュー → 適用 / ロールバック可能
  5. 必要なら Regenerate で再採点

README 側の改善ループ

Map → breakpoints → minimal vehicle（Rule / Skill / Hook / script / human gate）→ fix & verify → 再実行、という短い循環です。

実務の次アクション（1リポジトリ）

  1. まず1リポジトリでレポートを出し、High の Finding だけ読む
  2. 「設定がある」Finding と「実タスクで使われた証拠がない」Finding を分ける
  3. 1件だけ Plan a fix / 同等の scoped repair を人間レビューで通す
  4. 同種タスクでもう一度レポートを取り、Learning Capture / Validation が動いたか確認

Regenerate の目安は、改善マージ後・大きな構造変化後・数週間経過時です（Docs）。

導入すべきか（判断チェックリスト）

結論

全チーム必須ではありません。Agent を本番近い変更に使い始め、同じ摩擦が繰り返す段階で効きやすいです。

向くケース

  • Claude Code / Codex / Cursor を複数併用し、harness 資産が散在している
  • Rules / Skills は厚いが、検証・承認・学習がタスク証拠と繋がっていない
  • 「モデルを替えたのに品質が安定しない」議論で harness 側を切り分けたい

向かない／保留

  • まだ試用レベルで、session / project 証拠が薄い
  • 自動修正を期待している（設計上しない）
  • Cursor のみで marketplace 待ち、source-local 運用を避けたい

同系テーマとの違い

端末多重化や環境分離（wmux 等）は実行面の作業台です。Better Harness は Loop 品質の診断と改善タスク化 に寄ります。両者は代替ではなく、レイヤが違います。

チェックリスト

  • 対象ホストで plugin / source-local が許容か
  • 最初に見るリポジトリを1つに絞ったか
  • High Finding を「設定欠落」と「未使用/未検証」に分類したか
  • 修正は人間ゲート付きで1件だけ試す合意があるか
  • 再スキャン日（改善後 or 構造変化後）を決めたか

独立報道（IT之家・新浪科技・搜狐など）も、対応ホストと「設定存在≠能力有効」という証拠主義を裏取りしています。採用判断の根拠は、人気度ではなく自リポジトリの Finding です。

関連記事:

よくある質問（FAQ）

Q1. Better Harness はモデルのベンチマークツールですか？

いいえ。Coding Agent の Work Loop / harness を証拠付きでレビューする側です（README / Docs）。

Q2. 実行するとリポジトリを勝手に直しますか？

公式 Docs は自動適用しない方針です。Plan a fix 等で人が承認する Quest / 計画経由です。

Q3. Claude Code だけで使えますか？ Codex や Cursor は？

README は Claude Code / Codex Desktop・CLI / Qoder / Cursor（source-local）の手順を分けて記載しています。ホスト差でレポート形式も異なります。

Q4. 「設定ファイルがある」のに低スコアになるのはなぜ？

設定存在と、タスクで使われた／成果に寄与した証拠は別です。未使用や未検証はギャップとして残ります。

Q5. どのくらいの頻度で再スキャンすべき？

Docs は改善マージ後・大きな構造変化・数週間経過時の Regenerate を推奨しています。運用目安として捉えてください。

Q6. ライセンスと二次利用は？

MIT（README）です。社内 harness 改善への組み込みはしやすい一方、Finding をそのまま公開する場合は内部パスや秘密の有無を確認してください。

まとめ — 次にやること

Better Harness は「より賢いモデル」ではなく、再現可能な Agent Loop を育てる診断と改善起動装置です。

  1. 公式 README のホスト表から自分の環境の install を選ぶ
  2. 1リポジトリでレポートを生成し、High Finding を3件以内に絞る
  3. 1件だけ人間承認付きで修正し、再スキャンで Validation / Learning の変化を見る
  4. 効いたら Rule / Skill 化して Learning Capture を意図的に積む

まずは GitHub: QoderAI/better-harness と Qoder Docs で自ホストの手順を確認し、1本の High Finding だけを人間ゲート付きで通すところから始めてください。

📖 この記事で紹介した関連記事

krona23

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

📚 次に読む

← 前の記事Codex Security CLI/SDK の使い方｜npm・CI・プラグイン差分【2026】次の記事 →Pythonクラスで組むNOOAエージェント設計の読み方

🔥 よく読まれている記事

  1. Docker Sandboxes（sbx）入門｜Claude Code を microVM で安全に無人実行
  2. Claude にパスワードを渡さずログイン — 1Password for Claude の zero-exposure
  3. Claude Code Setup公式プラグインの使い方｜hooks/MCP/skillsをリポジトリ解析で提案
  4. 二段階式フィッシングメールの手口と見抜き方 2026年最新対策
  5. Claudeエージェントの敵対的検証入門｜レビューとの違いとチェックリスト

コメントを残す

Trending

DevGENTをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む