ハーネスエンジニアリングを理解する

記事タイトルとURLをコピーする

ハーネスエンジニアリングを理解する

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

最近、AIコーディングエージェント界隈で「ハーネスエンジニアリング」という言葉をよく見かけるようになりました。2026年2月にOpenAIが提唱して以来、各社が相次いで記事を公開しており、エージェント活用における重要なテーマとして注目が集まっています。

本記事では、このハーネスエンジニアリングとは何か、なぜ今話題になっているのかを、具体例を交えて解説します。

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

LangChainはAIエージェントの構造を次のように整理しています。

Agent = Model + Harness

「ハーネス」とは馬具のことです。どんなに優秀な馬(AIモデル)でも、手綱や鞍(ハーネス)がなければ行きたい方向に走ってくれません。AIエージェントも同じで、モデルの賢さだけでなく、それを正しく動かすための「環境」が成果を決めるという考え方です。

この「環境」を設計することをハーネスエンジニアリングと呼びます。

身近なたとえで理解する

料理で考えてみましょう。どんなに腕の良いシェフ(AIモデル)でも、レシピ(ルールファイル)がなければ何を作ればいいかわかりません。味見(フィードバックループ)をしなければ味が整っているか確認できません。仕込みメモ(コンテキスト管理)がなければ、昨日どこまで準備したか忘れてしまいます。

ハーネスとは、シェフが最高の料理を出すための「厨房の仕組み」のようなものです。

ハーネスの3つの基本要素

ハーネスにはさまざまな構成要素がありますが、各社の記事で共通して取り上げられている3つを紹介します。

ハーネスの3つの基本要素

1. ルールファイル — AIへの「行動規範」

AIエージェントに「このプロジェクトではこう書いてほしい」と伝えるファイルです。ツールごとに名前や配置場所が異なります。

ツール 代表的な配置場所
Claude Code CLAUDE.md
Kiro .kiro/steering/*.md
Codex AGENTS.md

具体例:CLAUDE.mdに書く内容

# プロジェクトルール

## 技術スタック
- TypeScript + React
- スタイリングはTailwind CSSを使う(styled-componentsは使わない)
- テストはVitestで書く

## コーディング規約
- 関数コンポーネントのみ使用(クラスコンポーネントは禁止)
- APIのエラーハンドリングは必ずtry-catchで行う
- 日本語のコメントを書く

## やってはいけないこと
- node_modulesを直接編集しない
- .envファイルの内容をコードにハードコードしない

書く内容は「AIが間違えやすいこと」に絞るのが効果的とされています。一般的なベストプラクティスはAIが既に知っているため、プロジェクト固有のルールだけで十分とされています。分量も60行以内が目安です。

2. フィードバックループ — AIの「ミスを自動で教える仕組み」

人間が毎回AIの出力をチェックするのは大変です。そこで、AIが出したコードを自動でチェックし、問題があれば自動で修正させる仕組みが求められます。

具体例:テストによるフィードバックループ

テストによるフィードバックループ

これは人間の開発でも「テスト駆動開発(TDD)」として知られていますが、AIエージェントとの組み合わせで特に威力を発揮します。テストがあるプロジェクトでは、AIは「テストが通るコード」を目指して自律的に改善を繰り返すからです。

逆に言えば、テストがないプロジェクトでは、AIには「正解かどうか」を判断する手段がありません。

同じ原理で、リンター(ESLint等)やフォーマッター(Prettier等)、型チェック(TypeScriptのコンパイル)も効果的なフィードバックになります。

3. コンテキスト管理 — AIへの「作業メモ」

AIエージェントは一度に扱えるコンテキスト(情報量)に限りがあります。長いタスクでは、途中で前の作業内容を忘れてしまうことがあります。

これに対処するのがコンテキスト管理です。

具体例:進捗ファイルによる引き継ぎ

<!-- progress.md -->
# 作業進捗

## 完了したこと
- ユーザー認証APIの実装(src/api/auth.ts)
- ログイン画面のUI(src/pages/Login.tsx)

## 次にやること
- パスワードリセット機能の実装
- 注意:メール送信はSendGridのAPIを使う(環境変数SENDGRID_API_KEY)

## 判明した制約
- 既存のUserモデルにはresetTokenフィールドがないので、マイグレーションが必要

このように作業状態をファイルに書き出しておけば、AIは次の作業開始時にこれを読み込んで、文脈を引き継いで作業を続けられます。

Anthropicも長時間エージェント向けのガイドで、「初期化エージェント」と「コーディングエージェント」の2段階構成を推奨しています。初期化エージェントが環境のセットアップや進捗ログの作成を担当し、コーディングエージェントは1機能ずつ集中して実装します。このように役割を分けることで、コンテキストの消費を抑えながら大きなタスクを進められます。

なぜ今、注目されているのか

SWE-benchの分析によると、同一モデルでもハーネスの設計を変えるだけでスコアが大きく変動することが報告されています。基本的なスキャフォールドを使った場合と最適化されたスキャフォールドを使った場合で、20ポイント以上の差が出たケースがあります。一方、フロンティアモデル同士を入れ替えた場合のスコア差はわずかでした。

つまり、モデルを最新にすることよりも、ハーネスの設計を見直すことの方が、はるかに大きな効果があるということです。

まとめ

ハーネスエンジニアリングの基本をおさらいします。

  • Agent = Model + Harness — AIの成果は、モデルの賢さ × 環境の良さで決まる
  • ハーネスの基本3要素は「ルールファイル」「フィードバックループ」「コンテキスト管理」
  • モデルを変えるより環境を整える方が、成果への影響が大きい

本記事ではハーネスエンジニアリングの概要を紹介しました。今後、ハーネスエンジニアリングに基づく開発方法論について、レポートしていく予定です。

参考リンク

針生 泰有(執筆記事の一覧)

サーバーワークスで生成AIの活用推進を担当