ハーネスエンジニアリング入門

AI駆動開発の次のフロンティア

なぜ今、ハーネスエンジニアリングなのか

AI駆動開発の「3段階進化」

AIを使いこなすための技術は急速に進化してきた

時期 概念 焦点
2024年 プロンプトエンジニアリング 指示の書き方
2025年 コンテキストエンジニアリング 情報の与え方
2026年 ハーネスエンジニアリング 環境の設計

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

AIエージェントを「賢い馬」に例えると

馬の能力を最大限に引き出すのが「馬具（ハーネス）」。
AIも同様に、能力を制御・活用する仕組みが必要。

  • 定義：AIが安定して成果を出せる運用環境の設計
  • 提唱者：Mitchell Hashimoto（HashiCorp共同創業者）
  • 本質：プロンプトでなく「仕組み」で品質を担保する

提唱者のシンプルな定義

"Engineer the Harness"（Mitchell Hashimoto）

エージェントがミスを犯したとき、
そのミスが二度と起きないよう
仕組みで解決することに時間を使う

  • プロンプト修正で済ませない
  • 再発防止の構造を作り込む
  • ルール・テスト・フィードバックで自動化する

ハーネスの4つの構成要素

構成要素1：アーキテクチャ制約

「やってはいけないこと」を仕組みで防ぐ

  • カスタムLinterによるコーディングルール強制
  • ファイル構造・命名規則のスキーマ定義
  • アクセス権限・操作範囲のサンドボックス化
  • 禁止パターンの静的解析による自動検出

構成要素2：フィードバックループ

AIが自ら学べる仕組みを用意する

フィードバック種別 具体例
静的フィードバック Lintエラー・型チェック結果
動的フィードバック ブラウザ自動テスト・E2Eテスト
構造的フィードバック アーキテクチャ違反の検出
人的フィードバック コードレビュー・承認フロー

構成要素3：ワークフロー制御

エージェントの行動順序と範囲を設計する

並列エージェントが増えるほど、制御設計が重要になる。

  • タスクの優先順位・依存関係の定義
  • 複数エージェント間のファイル衝突防止
  • 人間が介入すべきチェックポイントの設定
  • アーキテクチャ逸脱の早期検知ゲート

構成要素4：改善サイクル

ハーネス自体を継続的に育てる

  • エージェントのミスパターンをルールに昇格させる
  • CLAUDE.mdなどナレッジ集約ファイルを更新する
  • 不要になった制約を定期的に見直す
  • チームのベストプラクティスをコード化する

コンテキスト vs ハーネス

2つの概念の違いを整理する

「品質が上がらない」原因はどちらにあるか切り分けよう

観点 コンテキスト ハーネス
役割 AIに情報を与える AIを環境で制御する
手段 RAG・MCP・CLAUDE.md Linter・テスト・CI
対象 何を知らせるか どう動かすか
改善 プロンプト改善 コード・インフラ

ハーネスが必要な理由

AIエージェントが増えるほど、制御の仕組みが問われる

  • プロンプト改善だけでは品質の上限が低い
  • 10本の並列エージェントはファイル衝突を頻発させる
  • AIが書いたコードは独自の「エントロピー」を蓄積する
  • OpenAI・Anthropicも「ボトルネックはハーネス」と公言

実践：何から始めるか

Claude Code での実践ポイント

ハーネスの統合ポイントを押さえる

  • CLAUDE.md：リポジトリ知識の集約・段階的な情報開示
  • MCPサーバ：外部ツール・APIとの接続インタフェース
  • カスタムLinter：コーディングスタイルの自動強制
  • E2Eテスト：ブラウザ自動化でバグの見逃しを防ぐ

ハーネス構築の始め方

「ミスの記録」がハーネスの出発点になる

  1. エージェントのミスパターンをログに残す
  2. 同じミスを防ぐルール・テストを1つ追加する
  3. CIパイプラインに組み込み自動化する
  4. チームで共有してナレッジを積み上げる

「一度犯したミスは、仕組みで二度と起こさない」

まとめ：ハーネスエンジニアリングの要点

  • 2026年、AI開発の焦点はハーネス設計に移行した
  • 4要素：制約・フィードバック・制御・改善サイクル
  • コンテキストとハーネスは別レイヤー、切り分けが重要
  • 「ミスを仕組みで防ぐ」ことが本質

AIを使いこなす鍵は、プロンプトではなく環境設計にある

参考文献

Thank you!