9月24日、marmelabが「The State Of AI Harness Engineering 2026」と題した記事を公開した。AIエージェント開発における「ハーネスエンジニアリング」の現状を246リポジトリ・57論文の調査に基づいてまとめたトレンドレポートだ。
「ハーネス」次第で成功率が68%から88%に変わる
ハーネスエンジニアリングとは、AIエージェントを信頼性高く動作させるためのツール・コンテキスト・メモリ・制御ループ全体の設計・実装を指す。「Agent = Model + Harness」という式が業界の共通認識となりつつあり、Birgitta BöckelerがMartinFowler.comに寄稿した記事がその整理として広く参照されている。
この分野の重要性を示す数字がある。同一モデル・同一プロバイダ・同一ツールで同じ25タスクを8種類の異なるハーネスで実行したところ、成功率は**68%から88%**まで変動した（Composio調査）。モデルではなくハーネスが、エージェントの実用性を左右する。
marmelabは自社でもハーネスを実装しており（Atomic CRM）、業界のベストプラクティスと自社の実装を比較するために本調査を実施した。
数字で見る現状：誰もがルールを書き、誰も強制しない
調査から浮かぶ全体像は「ルールは多いが機能していない」だ。
- GitHubの
claude-codeトピックを持つリポジトリは73,400件。2026年だけで「agent harness」リポジトリが21,500件新規作成された - 中央値のハーネスリポジトリは8.7ヶ月の歴史しかない（83%が2025〜2026年作成）
- 大規模OSSプロジェクト145件のうち63%がエージェント指示ファイルを同梱。だがサブエージェントを宣言しているのは4件、フックの合計は14個のみ
- ルールファイルの中央値は123行。しかし481件の
CLAUDE.mdを対象にした研究（arXiv 2608.23550）では、書かれたセキュリティルールが実際に効いているのは**4〜16%**にとどまる - 調査した97のハーネスのうち**60%**はテストもevalも存在しない
最重要の知見①：ハーネスはテスト・evalせよ
記事が最も強調するのがこの点だ。コードと同様に、ハーネスにもバグや曖昧な記述が混入する。AGENTS.mdの指示が一度も守られていないケースは珍しくない。
テストとevalは別物で、両方が必要だ。
- テスト：フックやルールのスクリプトが正しく動作するかをコードで検証する。重要なのは「ブロックすべきものをブロックする」だけでなく「通すべきものを通す」ケースも含めること。片方だけだとハーネスが徐々に過剰制御に傾き、エージェントを締め付ける。Anthropicは「_片側だけのevalは片側だけの最適化を生む_」と端的に述べている
- eval：固定タスクセット（20〜50件推奨）をエンドツーエンドで実行し、ハーネスの変更が実際に成果を改善したかを測定する。ハーネスの一部を取り除いて成功率が下がるか確認しなければ、そのルールが本当に必要かどうかはわからない
具体例として、codex-claude-code-configは63ケース（ブロック29件・許可19件・テキスト確認15件）を12のガードに対して実行する仕組みを公開している。
最重要の知見②：ハーネスは最小限にせよ
直感に反するが、ハーネスは小さいほど良い。
ETH Zurichが138タスクで検証した結果（arXiv 2602.11988）、機械生成のコンテキストファイルはコンテキストなしよりタスク成功率が低く、推論コストが20%以上増加した。人間が書いたものでも改善は約4%にとどまった。
ツール数も同様だ。記事はVercelの事例として、エージェントのツールを80%削減したところ成功率が80%から100%に向上し、トークン数は半減、レイテンシは724秒から141秒に短縮されたと紹介している。ただしこの数値は記事内でも明示的に「二次情報（Vercel自身の発表を元記事が引用したもの）」と断られており、独立した検証は行われていない点に留意されたい。Microsoftは自社のAzure運用エージェントで100以上のツールを2週間で追加し、最終的に2つの広範なツールに統合せざるを得なかった。
OpenAIは大きな単一指示ファイルを試みた失敗として4点を挙げている：実際のタスクを圧迫する、「すべてが重要だと何も重要でなくなる」、「即座に腐る・陳腐なルールの墓場になる」、「機械的なチェックになじまない」。結果として約100行に落ち着いた。
最重要の知見③：ルールはスクリプトで補強・代替せよ
散文で書かれたルールはほぼ機能しない（前述の4〜16%）。有効なハーネスは、gitフック・リンター・静的解析・カスタムスクリプトといった実行可能なガードでルールを強制している。
例えばcodex-claude-code-configのdestructive-command-guard.pyは正規表現でrm -rf /のバリエーションを網羅的に拒否する。LLMがテキスト記述でこれを漏れなく捕捉することはできない。
その他の知見
上記3点が記事の核心だが、調査からは他にも注目すべき傾向が報告されている。
- エージェントにアプリを動かさせる：OpenAIはエージェントが自分でアプリを起動し、実ブラウザで操作してログを読める環境を整備した。コード生成速度がレビュー速度を超えた今、検証の自動化が重要な課題になっている
- AGENTS.mdが優勢：
AGENTS.mdを持つリポジトリは189件、CLAUDE.mdは155件。大規模OSSではCLAUDE.mdの36件がAGENTS.mdへのシンボリックリンクか短いリダイレクトだった - ハーネス自身をAIが書く：2025年1月以降のハーネスへのコミットの**25%**がAI署名付き。79リポジトリのうち52では、ハーネスがそれが管轄するコードよりAI記述率が高い（中央値16% vs 9%）
- ハーネスは腐る：Anthropicは「コンテキスト不安」に対処するためコンテキストウィンドウのリセット機能を追加したが、Opus 4.5ではその問題自体がなくなり、リセット機能は「ハーネスの死重」になったと報告している。モデルが進化するにつれてハーネスの前提は陳腐化する
詳細はThe State Of AI Harness Engineering 2026を参照していただきたい。
