ハーネスエンジニアリング完全ガイド — 2026年、AIエージェントの「手綱」を握る技術

2025年は「AIエージェントの年」と呼ばれました。各社がこぞってエージェントを発表し、自律的にコードを書き、タスクをこなすAIが話題を席巻しました。しかし2026年、業界の注目は静かに、しかし確実に別のところへ移っています。それが​「ハーネスエンジニアリング」​です。

「ハーネス」とは、もともと馬を御すための馬具を指す言葉です。どれだけ優秀なサラブレッドでも、手綱なしでは暴走してしまいます。AIエージェントも同じです。強力なLLMがあっても、それを​「正しい方向に、安全に、再現性をもって動かす仕組み」​がなければ、プロダクションでは使い物になりません。

この記事では、OpenAI・Anthropic・Google・LangChain・ThoughtWorksという5つの組織がどのようにハーネスを設計しているかを読み解き、あなた自身がハーネスを設計するための実践的な指針をお伝えします。

各社のハーネス戦略を読み解く

OpenAI Codex — 100万行の実験

OpenAIのCodexチームは、ハーネスエンジニアリングという言葉を世に広めた先駆者です。わずか3〜7人のチームが5ヶ月間で100万行以上のコードを生成し、約1,500件のPRをマージしました。驚くべきことに、人間が直接書いたコードはゼロです。

出典: LangChain Blog - The Anatomy of an Agent Harness

この成功の鍵は​「自由度を絞ること」​でした。エージェントに「なんでも好きに書いていいよ」と言うのではなく、依存関係を厳密な階層構造（Types → Config → Repo → Service → Runtime → UI）で縛り、アーキテクチャの選択肢をあらかじめ制限しました。レストランに例えるなら、「お好きな料理をどうぞ」ではなく、「今日のおすすめ3品から選んでください」と伝えるようなものです。制約があるからこそ、料理の品質が安定するのです。

Anthropic — GANに着想を得た多エージェント・ハーネス

Anthropicのハーネス設計は、二つの層で構成されています。一つはClaude Codeの権限モデル——エージェントはデフォルトで読み取り専用であり、書き込みにはユーザーの明示的な許可が必要です。もう一つは、長時間の自律的開発を可能にする多エージェント・ハーネスです。

出典: Epsilla - Anthropic's GAN-Style Harness Architecture

さらに注目すべきは、GAN（敵対的生成ネットワーク）にインスパイアされた3エージェント循環です：

• ​Planner（計画者）​：タスクを分解し、実行計画を立てる
• ​Generator（生成者）​：計画に基づいてコードを生成する
• ​Evaluator（評価者）​：生成結果を検証し、フィードバックを返す

この三角循環が繰り返されることで、単一エージェントでは到達できない品質水準が実現されます。

Google Cloud — マイクロサービス発想の多エージェント設計

Google Cloudは、ハーネスの設計を8つのマルチエージェント・デザインパターンとして体系化しています。Agent Development Kit（ADK）が提供する3つの基本実行パターン——Sequential（逐次）、Loop（循環）、Parallel（並列）——を土台に、実践的なアーキテクチャを整理したものです。

中でもハーネス設計に直結するのが以下のパターンです：

• Sequential Pipeline：エージェントを組み立てラインのように並べ、各エージェントの出力を次へ渡す。線形で決定論的であり、デバッグが容易
• Review and Critique：生成→批評→改善のサイクルを品質閾値に達するまで繰り返す。合否判定ではなく、定性的な品質向上に焦点を当てる
• Swarm：すべてのエージェントが相互に通信し、発見を共有しながら解を洗練する

Google Cloudの発想の特徴は、AIエージェントを​「マイクロサービスのAI版」​として捉えている点です。Parser、Critic、Dispatcherといった専門的な役割を個別のエージェントに割り当てることで、システム全体のモジュール性・テスト容易性・信頼性を高めるというアプローチは、すでにバックエンド開発で馴染みのある設計思想の延長線上にあります。さらに、エージェント間通信の標準プロトコルとして**A2A（Agent2Agent）**を公開し、異なるフレームワーク間での連携も視野に入れています。

LangChain Deep Agents — Middleware で組み立てる

LangChainは「Agent = Model + Harness」という簡潔な定式化を提唱しています。つまり、モデルの外側にあるすべて——状態管理、ツール実行、フィードバックループ、実行制約——がハーネスです。

出典: LangChain Blog - The Anatomy of an Agent Harness

Deep Agents SDKでは、ハーネスを​Middleware（ミドルウェア）​として実装します。ファイルシステムの操作、サブエージェントの生成、トークン管理などがすべてプラガブルなコンポーネントとして提供されます。Webアプリケーション開発でExpressやFastAPIのミドルウェアを積み重ねるように、エージェントの振る舞いもミドルウェアで組み立てるという発想です。

ハーネスの3つのカテゴリー

ThoughtWorksのBirgitta Böckeler氏は、Martin Fowlerのサイトで、OpenAIのハーネス構成要素を3つのカテゴリーに分類して論じています（氏自身の解釈に基づく分類と明記されています）。

カテゴリー①：Context Engineering（コンテキストエンジニアリング）

エージェントに「何を知っているべきか」を設計する技術です。LLMの性能は、プロンプトに含まれるコンテキストの質に大きく左右されます。

# コンテキスト設計の例
context_sources:
  - type: codebase_index    # リポジトリの構造と依存関係
  - type: style_guide       # コーディング規約
  - type: recent_changes    # 直近のgit diff
  - type: error_logs        # 関連するエラーログ

ポイントは​「全部入れればいい」​ではないということです。関係のない情報は判断を鈍らせます。「必要な情報を、必要なタイミングで、適切な粒度で」渡す——これがコンテキストエンジニアリングの核心です。

カテゴリー②：Architectural Constraints（アーキテクチャ制約）

エージェントに「何をしてよいか・してはいけないか」を構造的に定義する技術です。OpenAI Codexの依存層制御がまさにこれにあたります。

# 制約の例：エージェントが触れるディレクトリを制限
ALLOWED_PATHS = [
    "src/features/**",
    "tests/**",
]
FORBIDDEN_PATHS = [
    "src/core/auth/**",      # 認証基盤は変更禁止
    "infrastructure/**",     # インフラ定義は変更禁止
    ".env*",                 # 秘密情報は読み取り禁止
]

これは人間のチーム開発でも同じです。新人エンジニアにいきなり本番データベースの管理者権限を渡さないように、エージェントにも「触れていい範囲」を明確に定義します。

カテゴリー③：Garbage Collection（ガベージコレクション）

長時間動くエージェントは、コードの一貫性が徐々に崩れ、ドキュメントとの不整合やアーキテクチャ制約からの逸脱が蓄積していきます。Böckeler氏はこれを​「ガベージコレクション」​と呼んでいます。OpenAIのCodexチームは、定期的にバックグラウンドでエージェントを走らせ、品質グレードの更新やリファクタリングPRの自動生成を行うことで、この問題に対処しています。

Anthropicは別の角度から同様の問題に取り組んでおり、​Context Reset（コンテキストリセット）​という手法を採用しています。単純にコンテキストを圧縮するのではなく、エージェントに新鮮なコンテキストウィンドウを与え、前のセッションの状態を構造化された引き継ぎ情報で渡す方式です。部屋が散らかったら「片付ける」のではなく「きれいな部屋に移る」というアプローチです。

実践 — ハーネスを設計する5つのポイント

ここからは、各社のアプローチを横断して見えてきた実践的な設計指針を紹介します。なお、前章で紹介したThoughtWorksのBöckeler氏による3つのカテゴリー（Context Engineering・Architectural Constraints・Garbage Collection）が、以下のポイントを整理する際の理論的な軸となっています。

① 最小権限から始める（Anthropic方式）

エージェントには最初、最小限の権限だけを与えましょう。必要に応じて段階的に権限を拡大するのが安全です。

{
  "permissions": {
    "file_read": true,
    "file_write": false,
    "network_access": false,
    "shell_execute": false
  }
}

② 確定的ルールとLLM判断を混ぜる（OpenAI方式）

すべてをLLMに任せるのではなく、「ここは必ずこうする」という確定的なルールと、「ここはLLMに判断させる」という部分を明確に分けましょう。

出典: LangChain Blog - The Anatomy of an Agent Harness

例えば、ファイル構成やインポートの順序は確定的ルールで強制し、ビジネスロジックの実装はLLMに任せるといった具合です。

③ Review and Critique パターンを活用する（Google方式）

前述のGoogle CloudのReview and Critique パターンを実務に取り入れましょう。一つのエージェントが書いたコードを、別のエージェントが批評し、品質閾値に達するまでループさせる。人間のコードレビューと同じ発想ですが、ループの終了条件を明示的に定義できる点がハーネス設計ならではの強みです。

④ 可観測性を組み込む（LangChain方式）

エージェントが「何を考え、なぜその判断をしたか」をトレースできるようにしましょう。LangChainのLangSmithのようなツールを使えば、各ステップの入出力を可視化できます。バグが起きたとき「なぜエージェントがそう判断したか」が分からなければ、修正のしようがありません。

⑤ 制約のバランスを見極める

制約が厳しすぎると、エージェントは簡単なタスクすらこなせなくなります。逆に緩すぎると、予測不能な振る舞いが増えて事故が起きます。最初は厳しめに設定し、実績が積み上がるにつれて徐々に緩和していく——これが多くの企業が実践している「​段階的自律性（Graduated Autonomy）​」のアプローチです。

まとめ

ハーネスエンジニアリングは、2026年のソフトウェア開発における新たな競争優位の源泉です。同じLLMを使っていても、ハーネスの設計次第で成果物の品質は天と地ほど違います。

覚えておくべき核心は3つです：

• Agent = Model + Harness：モデルの性能だけでは勝てない時代
• 自由度を絞ることで信頼を得る：制約はエージェントの敵ではなく味方
• ​ハーネスこそが技術的な堀（モート）​：簡単にはコピーできない設計知識の蓄積

エンジニアの役割は「コードを書く人」から「AIが正しくコードを書けるようにハーネスを設計する人」へと進化しています。この記事が、あなたのハーネス設計の第一歩となれば幸いです。

参考資料

• OpenAI - Harness Engineering
• Anthropic - Harness Design for Long-Running Application Development
• Martin Fowler / Birgitta Böckeler - Harness Engineering
• LangChain - The Anatomy of an Agent Harness
• LangChain - Improving Deep Agents with Harness Engineering
• Google Cloud - Choose a Design Pattern for Your Agentic AI System
• Epsilla - Anthropic's GAN-Style Harness Architecture