ハーネスエンジニアリング：AIエージェントを支えるシステムの構築 (2026)

TL;DR

ハーネスエンジニアリングとは？

ハーネスエンジニアリング（Harness Engineering）とは、AIコーディングエージェントの信頼性と生産性を高めるために、それらを取り巻くシステム、ツール、制約、およびフィードバックループを構築する学問分野です。

この用語は Mitchell Hashimoto 氏（HashiCorpの共同創設者）によって造られ、2026年初頭に OpenAIがこのトピックに関するCodexの記事を公開した ことで主流の注目を集めました。

核となる考え方はシンプルです：

Agent = Model + Harness

モデルは「知能」を提供します。ハーネスはその知能を「有用」なものにします。多くの場合、優れたモデルよりも優れたハーネスの方が重要になります。

なぜ今、重要なのか

2025年、あらゆるチームがAIコーディングエージェントを導入しました。2026年、勝利しているチームは、単に最高のモデルを選んだチームではなく、エージェント環境をエンジニアリングした チームです。

Mitchell Hashimoto 氏の指針：

「エージェントがミスを犯したときはいつでも、そのミスを二度と繰り返さないような解決策をエンジニアリングするために時間を割くべきである。」

これはプロンプトエンジニアリングではありません。AIのための システムエンジニアリング です。

証拠：ハーネス > モデル

LangChainは Terminal Bench 2.0 で対照実験を行いました。基盤となるモデルを変更せずに、ハーネスを改善するだけで、コーディングエージェントの精度を 52.8%から66.5% （26%の向上）へと改善しました。

変更内容には以下が含まれます：

• より適切なコンテキストファイル（AGENTS.md）


• 構造化された出力制約


• 自己検証ループ


• ツールの最適化

ハーネスの7つのコンポーネント

1. コンテキストエンジニアリング

コンテキストエンジニアリングは基礎です。ここでは、コードベースのマップ、慣習、および制約をエージェントに提供します。

• リポジトリのルートにある CLAUDE.md や AGENTS.md ファイル
• ディレクトリマップとアーキテクチャの概要
• コーディングスタイルのルールと命名規則

# CLAUDE.md example
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. アーキテクチャ上の制約

エージェントが正しいアーキテクチャを選択することを期待するのではなく、それを 強制 します。

• リンターによって検証される厳格な階層化アーキテクチャ
• パターンに違反した場合に失敗する構造テスト
• ESLint ルールやカスタムスクリプトによるインポート制限

3. ツールとMCPサーバー

エージェントが効果的に機能するにはツールが必要です。優れたハーネスは、以下の方法で内部ツールを公開します：

• CLIラッパー — 独自のツールよりも、よく知られたCLI（git, docker, npm）を好んで使用する
• MCP (Model Context Protocol) サーバー — エージェントが内部API、データベース、サービスを呼び出せるようにする
• ファイルシステムアクセス — 不慮の損傷を防ぐため、特定のディレクトリにスコープを限定する

4. サブエージェントとコンテキストファイアウォール

長時間実行されるエージェントセッションはコンテキストを蓄積し、最終的にパフォーマンスを低下させます。これは コンテキストの劣化（context rot） と呼ばれます。

解決策：コンテキストファイアウォールを備えたサブエージェント。

• 複雑なタスクを個別のサブタスクに分割する
• 各サブタスクは、新しいコンテキストを持つ独自のセッションで実行される
• エージェント間では生の会話ではなく、構造化された結果のみを渡す

1. Initializer Agent — 作業を計画し、機能リストを作成する
2. Coding Agent — 各機能を独立して実行する

5. フックとバックプレッシャー

ミスが重なる前にそれらを捕らえる自動フィードバックループ：

• Pre-commit フック — 型チェック、リンティング、フォーマット
• テストランナー — エージェントは変更のたびにテストを実行すべき
• ビルド検証 — 壊れたビルドに対しては早期に失敗させる（fail fast）

6. 自己検証ループ

タスクを完了とする前に、エージェントに自らの仕事を検証させます：

• 変更後にテストスイートを実行する
• ビルドが通ることを確認する
• 出力が仕様と一致しているか検証する
• スクリーンショットを撮って比較する（UI作業の場合）

7. 進捗ドキュメント

長時間（30分以上）かかるタスクの場合：

• 完了したステップを追跡する進捗ファイルを維持する
• 頻繁にコミットを行い、後続のセッションが継続できるようにする
• 自由形式のメモではなく、構造化されたタスクリストを使用する

実世界の結果

OpenAI Codex チーム

3人のエンジニアが、5ヶ月間で手書きのコードを一切使わずに 100万行のコードベース を作成しました。エンジニア1人あたり1日平均 3.5件のマージ済みPR という、成熟したハーネスなしでは不可能なスループットを実現しました。

彼らのハーネスには、厳格なコミット規約、すべてのPRでの自動テスト、エージェントを意識した CI/CD パイプラインが含まれていました。

Stripe の「Minions」

Stripeの社内システムは、AIエージェントを使用して 週に1,000件以上のマージ済みPR を生成しています。彼らのハーネスには以下が含まれます：

• 厳密にスコープされたタスク定義
• 人間による必須のコードレビュー
• 自動化された回帰テスト
• ロールバックの自動化

Anthropic の 2エージェント・アーキテクチャ

Anthropicは、長時間実行されるエージェントのための効果的なハーネスへのアプローチを公開しました：

• エージェント間の受け渡しフォーマットとしての 構造化された機能リスト
• 中断後に再開できるようにするための Gitベースの進捗追跡
• エージェントがいつ停止すべきかを知るための 明確な終了基準

ハーネスの構築を始める方法

ステップ 1: コンテキストファイルを作成する

プロジェクトのルートに CLAUDE.md (または AGENTS.md) を追加します：

# Project: [Your Project]

## Stack
[Framework, language, database, hosting]

## Architecture
[Directory structure with one-line descriptions]

## Rules
[5-10 hard rules the agent must follow]

## Common Tasks
[How to run tests, build, deploy]

ステップ 2: 構造的な制約を追加する

# 例: コンポーネント内での直接的なDBインポートを禁止するESLintルール
# .eslintrc — no-restricted-imports rule

ルールを自動的に強制する pre-commit フックを設定します。

ステップ 3: ビルド検証ループを構築する

エージェントが以下の操作を行えるようにします：

1. テストの実行 (npm test, pytest など)


2. 型チェック (tsc --noEmit, mypy)


3. リンティング (eslint ., ruff check)

ステップ 4: エージェントセッションのスコープを限定する

エージェントにバックログ全体を与えないでください。代わりに：

• 1セッションにつき1つの機能
• 1セッションにつき1つのバグ修正
• 各タスクに対する明確な受け入れ条件

ステップ 5: ハーネスを反復改善する

エージェントがミスを犯すたびに：

1. 根本原因を特定する
2. それを防ぐルール、制約、またはフックを追加する
3. 修正をテストする

ハーネスエンジニアリング vs. プロンプトエンジニアリング

プロンプトエンジニアリングも依然として有用ですが、それは全体像の小さな一部に過ぎません。ハーネスエンジニアリングこそが乗数となります。

新たな役割：ハーネスエンジニア

エンジニアリングは2つの側面に分かれつつあります：

1. 環境構築 — 構造、ツール、制約、およびフィードバックループの作成
2. 業務管理 — 並行するエージェントセッションの計画、レビュー、オーケストレーション

混同注意：Harness.io

DevOpsプラットフォームを探して「Harness Engineering」を検索したなら、Harness.io は全く別のものです。それは2025年12月時点で55億ドルの価値があるAI駆動型 CI/CD プラットフォームであり、継続的インテグレーション、デリバリー、フィーチャーフラグ、クラウドコスト管理、セキュリティテストを提供しています。

Harness.io とハーネスエンジニアリングは名前こそ同じですが、解決しようとしている問題が異なります。ただし、興味深い共通点もあります。Harness.io のAI駆動型 DevOps は、デプロイパイプラインに対するハーネスエンジニアリングの原則の適用であると言えるでしょう。

結論

モデルはエンジンです。ハーネスは車そのものです。エンジンだけでレースに勝てる人はいません。

2026年にAIコーディングエージェントを使用しながら、ハーネスに投資していないのであれば、その価値の大部分を捨てていることになります。まずはコンテキストファイルから始め、制約を加え、検証ループを構築し、何かが壊れるたびに反復改善してください。

最速で出荷しているチームは、より良いモデルを使っているわけではありません。より良いハーネスを使っているのです。