「プロンプトを上手く書けばAIは動く」——この認識は、チャットUIでの対話には通用した。しかし2025〜2026年にかけてAIエージェントが実務に入り込み始めると、プロンプトだけでは制御できない問題が次々と現れた。
プロンプトエンジニアリングとハーネスエンジニアリングは、何が違うのか。どちらが優れているのか、ではない——これは互いに補完し合う概念だ。しかし、「どこまでがプロンプトの問題で、どこからがハーネスの問題か」を正しく切り分けられないと、間違った解法を当てて問題が解決しない。
この記事ではハーネスエンジニアリングの設計パターンに特化して解説します。ハーネスエンジニアリングの5つの流派と設計思想の詳細は ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理する をご覧ください。
プロンプトエンジニアリングとは何か——改めて定義する
プロンプトエンジニアリングの本質は、LLMへの入力テキストを設計することだ。
「こういうトーンで」「ステップバイステップで考えて」「JSON形式で返して」——これらは全てプロンプト設計の技術だ。Few-shot examples、Chain of Thought、Role prompting、RISEN形式などの手法が2022〜2023年にかけて体系化され、「プロンプトエンジニア」という職種まで生まれた。
プロンプトエンジニアリングが有効に機能する前提は次の通りだ:
- インタラクションが単発または短期（チャット形式）
- ツール呼び出しなし、または最小限
- 人間がループの中にいる（出力を人間が確認・修正する）
- 状態管理が不要（会話履歴のみで十分）
ChatGPT登場直後の世界では、この前提が多くのケースで成立していた。
プロンプトエンジニアリングの主要技術
| 技術 | 概要 | 有効な場面 |
|---|---|---|
| Few-shot prompting | 回答例をプロンプトに含める | 出力フォーマット統一 |
| Chain of Thought (CoT) | 「ステップバイステップで」と指示 | 複雑な推論タスク |
| Role prompting | 役割・ペルソナを設定 | 特定スタイルの文章生成 |
| Self-consistency | 複数回生成して多数決 | 精度向上 |
| RAG連携プロンプト | 検索結果の埋め込み指示 | 知識グラウンディング |
| System prompt設計 | 行動原則・制約の定義 | チャットボット・カスタマーサポート |
ハーネスエンジニアリングとは何か——プロンプトの「外側」の設計
ハーネスエンジニアリングは、AIエージェントが自律的に動くための実行環境全体を設計する技術だ。
Mitchell Hashimoto（HashiCorp創業者）は2026年2月、次のように定義した:
「エージェントが失敗するたびに、その失敗が二度と起きないような環境ルールをエンジニアリングする」
Martin Fowlerは別の切り口でこう整理する:
「ハーネスは Guides（事前制御） と Sensors（事後検証） の二軸からなる。エージェントを正しく動かすのがGuide、エージェントの出力を外部から監視するのがSensor」
Harrison Chase（LangChain創業者）の定義は最も広い:
「ハーネスとは、モデル以外のすべてだ」
3つの定義に共通するのは、プロンプト単体を超えた「システム」として設計するという視点だ。
ハーネスの構成要素
Agent = Model + Harness
Harness:
├── Guides（事前制御）
│ ├── AGENTS.md / CLAUDE.md（ルール定義）
│ ├── スキル・コマンド定義
│ ├── ツール権限・サンドボックス設定
│ └── タスク分解ロジック
└── Sensors（事後検証）
├── Lint・型チェック
├── テストスイート
├── AIレビュー
└── コスト・トークン監視
ハーネスには、プロンプト（システムプロンプト、ユーザープロンプト）も含まれる。ただし、プロンプトはハーネスを構成する一部に過ぎない。
なぜ「プロンプト」だけでは不十分になったか
2022年から2026年にかけて、AIとの対話が「会話」から「タスク実行」へと変わった。この変化が、プロンプトエンジニアリングの限界を露わにした。
変化1：コンテキスト長の爆発的拡大
Claude 3（2024年）は200Kトークン、Gemini 1.5 Proは100万トークン、Claude（2026年）では100万トークンが一般提供された。
コンテキストが長くなるほど、「何を渡すか」の設計が重要になる。10万行のコードベースを全部渡せるようになったとき、本当に全部渡すべきか——この判断はプロンプトの「書き方」ではなく、コンテキスト管理の設計の問題だ。
また、長大なコンテキストには Context Rot という問題が生じる。LLMの注意機構は入力が長くなると後半部への注意が薄れる。2万トークン先に書いた重要な指示が「見落とされる」現象は、プロンプトの文言を変えるだけでは解決できない。
変化2：「会話」から「タスク実行」へ——エージェント化
2025年以降、AIはチャット相手から自律的に動くエージェントへと変わった。Claude Codeはコードを書き、ファイルを読み書きし、コマンドを実行し、GitHubにPRを出す。単発の質問ではなく、数十ステップにわたるタスクを連続実行する。
この変化がプロンプトエンジニアリングの限界を突き破る。
エージェントが長期タスクを実行するとき、プロンプトだけでは制御できない問題:
- ツール呼び出しの結果がコンテキストに積み重なり、途中で「指示を忘れる」
- 並行して動く複数エージェント間の調整
- 失敗時の再試行・回復ロジック
- コスト爆発の防止（無限ループ検知）
- 出力の品質保証（人間が確認できない速度で動く場合）
Anthropicの調査では、エージェントプロジェクトの88%が本番到達できないとされている。その主な原因は「プロンプトが弱い」ではなく、エージェントを動かす環境設計の欠如だ。
変化3：プロンプト→コンテキスト→ハーネスの三段階進化
AIエンジニアリングの焦点は段階的にシフトした:
| 時期 | 焦点 | 問い |
|---|---|---|
| 2022〜2023 | プロンプトエンジニアリング | 何を、どう聞くか |
| 2024〜2025 | コンテキストエンジニアリング | LLMに何を送るか |
| 2025〜 | ハーネスエンジニアリング | エージェント環境全体をどう設計するか |
この三段階は「古いものが廃れて新しいものが取って代わる」ではない。下位の技術は上位の基盤として残る。プロンプトエンジニアリングは、ハーネスの中の各エージェントを動かすために依然として必要だ。
使い分け判断フロー
「プロンプトエンジニアリングで十分か、ハーネスが必要か」の判断フローを示す。
「エージェントが自律的に5ステップ以上動くか」が最も簡単な分岐点だ。Webフォームへの入力補助、チャットサポートなどはプロンプト領域。コードのレビュー→修正→テスト→PR作成を一括実行するような自動化はハーネス領域に入る。
シナリオ別比較：チャットUI vs CLI vs エージェント
3つの典型的な利用形態で、プロンプトとハーネスの役割がどう変わるかを比較する。
シナリオ1：チャットUI（例：Claude.ai）
主役：プロンプトエンジニアリング
ユーザーがClaude.aiでドキュメントを要約したい場合、プロンプトの工夫が直接品質に影響する。「箇条書きで」「3段落に収めて」「技術者でない読者向けに」——これらはプロンプトエンジニアリングだ。
ハーネスの関与度は低い。Anthropicが提供するチャットUIのハーネス（レート制限、安全フィルタ、コンテキスト管理）はすでに構築済みで、ユーザーが設計する必要はない。
プロンプト例（要約タスク）:
───────────────────────
以下の技術仕様書を、マーケティング担当者（エンジニアではない）
が理解できる形で要約してください。
要件:
- 箇条書きで5点以内
- 技術用語は使わず日常語に言い換える
- 最後に「次のアクション」を1行で追記する
[仕様書の内容]
───────────────────────
この「プロンプト設計のうまさ」が品質を決める典型的なプロンプトエンジニアリングだ。
シナリオ2：CLI（例：Claude Code）
主役：コンテキストエンジニアリング + プロンプトの組み合わせ
Claude CodeはCLIからAIエージェントを操作する。CLAUDE.mdに書いたルール、スキル定義、MCP設定——これらがコンテキストとしてエージェントに渡される。
# CLAUDE.md（プロジェクトルール）の例
## コーディングルール
- TypeScriptを使う
- テストは必ずvitest
- コミットメッセージはConventional Commits形式
## 禁止事項
- any型の使用
- console.logのコミット
- mainブランチへの直接push
このCLAUDE.mdの記述は、プロンプトエンジニアリングの手法（明確な指示、制約の明示）をハーネス設計に応用したものだ。「プロンプトエンジニアリングの経験がCLAUDE.md設計に活きる」典型的な例だ。
シナリオ3：本番エージェント（マルチエージェントシステム）
主役：ハーネスエンジニアリング
GitHub Issueを受け取って、調査→コード修正→テスト→PR作成まで自律実行するエージェントを本番に載せる場合、プロンプトの工夫だけでは動かせない。
# エージェントハーネスの構成例（概念）
harness:
guides:
- agents_md: "AGENTS.md" # ルール定義
- skills: ["code-review", "test"] # 再利用可能スキル
- sandbox: "docker-isolated" # 実行環境
- budget: "max_tokens: 500000" # コスト上限
sensors:
- lint: "eslint --max-warnings 0"
- tests: "vitest run"
- review: "claude review --strict"
- monitor: "cost_tracker.py"
このレベルになると、「いいプロンプトを書く」では解決しない問題が山積する:
- エージェントが無限ループに入ったときの脱出ロジック
- 複数サブエージェントの協調とコンテキスト共有
- 失敗時のロールバックと人間への通知
- トークンコストの追跡と上限設定
| 側面 | チャットUI | CLI | 本番エージェント |
|---|---|---|---|
| プロンプトの重要度 | ★★★★★ | ★★★★ | ★★★ |
| コンテキスト設計の重要度 | ★★ | ★★★★ | ★★★★ |
| ハーネス設計の重要度 | ★ | ★★★ | ★★★★★ |
| 主な問題の原因 | プロンプトの質 | CLAUDE.mdの不備 | 環境設計の欠如 |
| 主な解法 | 指示の明確化 | ルール追加・スキル整備 | Guides+Sensorsの構築 |
プロンプトエンジニアリングの知識がハーネスに活きる5つの経路
「ハーネスエンジニアリングへ移行したらプロンプト力は不要になる」は誤解だ。プロンプトエンジニアリングで培ったスキルは、ハーネス設計の随所で活きる。
1. サブエージェントのプロンプト設計
マルチエージェントシステムでは、各サブエージェントが専門的な役割を担う。「コードレビュー専門エージェント」「テスト作成エージェント」「ドキュメント生成エージェント」——それぞれに専用のシステムプロンプトが必要で、ここではプロンプトエンジニアリングの技術が直接役立つ。
2. AGENTS.md / CLAUDE.md のルール設計
Hashimoto流ハーネスの核心は「失敗のたびにルールを追記する」ことだ。このルール記述は、プロンプトエンジニアリングで学んだ「明確な指示の書き方」「制約の表現方法」「例示による具体化」と同じスキルセットだ。
良いCLAUDE.mdの書き方:
# 悪い例（曖昧）
- いいコードを書く
# 良い例（具体的・プロンプトエンジニアリングの応用）
- TypeScript strict mode を必ず有効にする
- 関数の引数が3個以上の場合はオブジェクト引数に変換する
- エラーは必ずカスタムエラークラスで包む（例: `throw new AppError('message', 'ERROR_CODE')`）
3. Context Rot 対策のコンテキスト設計
長期タスクでエージェントが「指示を忘れる」Context Rot には、重要な指示をコンテキストの戦略的な位置に配置することが有効だ。「プロンプトのどこに何を書くか」という感覚は、ハーネスのコンテキスト管理設計に直結する。
4. Few-shot例の活用
ハーネスのスキル定義やAGENTS.mdに、「望ましい出力の例」（Few-shot）を含めることで、エージェントの出力品質が安定する。これはプロンプトエンジニアリングのFew-shot prompting手法をハーネス設計に転用したものだ。
5. 評価基盤（Evals）の設計
エージェントの出力品質を評価する基盤（Evals）を構築する際、「何を基準に評価するか」の設計はプロンプト設計の評価経験から生まれる。どのルーブリックが有効か、どんな境界例を確認すべきかは、プロンプトを繰り返し試した経験がある人ほど精度高く設計できる。
企業での導入パターン：個人→チーム→組織
ハーネスエンジニアリングの導入は段階的に進む。各フェーズで主役になる技術と、典型的なつまずきポイントを整理する。
フェーズ1：個人利用（プロンプト中心期）
規模: 個人開発者、プロトタイプ 主役: プロンプトエンジニアリング
最初は「いいプロンプトさえ書けば動く」で十分だ。Claude CodeにCLAUDE.mdを置き、スキルを1〜2本書く程度で大半のユースケースをカバーできる。
典型的な構成:
プロジェクト/
├── CLAUDE.md # 基本ルール（20〜50行）
└── .claude/
└── skills/
└── deploy/
└── SKILL.md # デプロイ手順
つまずきポイント: 同じ失敗が繰り返される。プロンプトを変えても改善しない場合は、ハーネスにルールとして焼き込む必要がある（Hashimoto流）。
フェーズ2：チーム運用（ハーネス標準化期）
規模: 3〜20人のエンジニアチーム 主役: ガイド設計（CLAUDE.md標準化）+ センサー整備（CI/CDへのAI統合）
個人のCLAUDE.mdをチームで共有・バージョン管理する。AIエージェントが出したコードをCI/CDで自動検証するSensorを整備する。
Stanford大学の2026年調査では、AIをチームで活用した場合、最も能力の高いエンジニアで生産性が最大10〜20倍向上した一方、導入効果にはばらつきがあり、チーム全体への浸透には「テストとレビューの規律」が鍵を握ると報告されている。
典型的な構成:
リポジトリ/
├── CLAUDE.md # チーム共通ルール
├── AGENTS.md # エージェント実行ルール
├── .claude/
│ ├── skills/ # チーム共有スキル
│ └── agents/ # エージェント定義
└── .github/
└── workflows/
└── ai-review.yml # AIレビュー自動化（Sensor）
つまずきポイント: CLAUDE.mdが肥大化して矛盾が生じる。「禁止事項」と「推奨事項」が競合するケース。定期的なルールの棚卸しが必要になる。
フェーズ3：組織展開（ガバナンス整備期）
規模: 50人以上の組織、複数チーム 主役: 評価基盤（Evals）+ ガバナンス + コスト管理
複数チームがそれぞれAIエージェントを使い始めると、組織全体でのガバナンスが必要になる。どのツールへのアクセスを許可するか、トークンコストの予算管理、セキュリティ上のリスク制御——これらは個人・チームレベルのプロンプト設計では対処できない。
Stanford大学のEnterpriseAI採用報告書（2026年3月）では、組織的なAI採用は4段階で進むとされる:
- 実験段階: 個人・チームが試し始める
- 意図的な導入: 経営層がガイドライン策定に関与
- 測定: 生産性・品質・コストを指標化
- 最適化: データに基づいてハーネスを改善
| フェーズ | 人数規模 | 主な設計対象 | 典型的な課題 |
|---|---|---|---|
| 個人 | 1人 | CLAUDE.md・スキル | 同じ失敗の繰り返し |
| チーム | 3〜20人 | ルール標準化・CI/CD統合 | ルール肥大化・矛盾 |
| 組織 | 50人〜 | ガバナンス・評価基盤 | コスト管理・セキュリティ |
将来展望：コンテキストウィンドウのさらなる拡大で何が変わるか
2026年時点でClaude 1Mトークン、Gemini 2Mトークンが利用可能になった。さらに将来、コンテキストウィンドウが10M・100Mと拡大したとき、ハーネスエンジニアリングの重要性はどう変化するか。
変わること：「何を渡すか」の選別が緩和される
小さなコードベースや中規模のドキュメントは「全部渡す」戦略が現実的になる。RAGによる検索・絞り込みが不要になるケースが増える。コンテキスト管理の一部の複雑さは解消される。
変わらないこと：Context Rot と注意機構の問題
コンテキストウィンドウが広がっても、LLMの注意機構は長大な入力に対して均等には機能しない。Chroma社の研究では、Claude系モデルはコンテキスト増大に対して他モデルより劣化が遅いことが示されているが、それでも100万トークン超の文書では中盤への注意が薄れる傾向がある。
「何でも詰め込む」設計ではなく、必要な情報を選別して渡すハーネスの価値は維持される。
変わらないこと：マルチエージェントの協調設計
コンテキストウィンドウの拡大は単一エージェントの能力を高めるが、並行して動く複数エージェントの協調問題は解決しない。タスクの分割・割り当て・結果の統合は、コンテキストが何Mトークンになっても設計が必要だ。
変わること（かもしれないこと）：プロンプトの重要性
コンテキストが無限に近づいたとき、Few-shot examplesや詳細な指示をどれだけ含めても「トークンが足りない」という制約がなくなる。プロンプト設計の「コスパ最適化」の側面は薄れる可能性がある。ただし、「何を指示するか」の本質的な設計思考は変わらない。
コンテキストウィンドウが拡大するほど、単位トークムあたりのコストは下がるが、長大なコンテキストを使う回数が増えれば総コストは上がる可能性がある。ハーネスによるコスト制御と品質保証の役割はむしろ高まる。
ハーネスエンジニアリングを始める最初の一歩
理論より実践が先だ。今すぐできる最小のハーネスエンジニアリングを示す。
ステップ1：CLAUDE.mdに「失敗から学んだルール」を1行追加する
# CLAUDE.md
## 過去の失敗から学んだルール
- コミット前に必ず `npm test` を実行する
（理由：2026-04-10にテストなしでバグをプッシュした）
- any型は使わない。unknown + 型ガードで代替する
（理由：any型が原因の実行時エラーが月3〜4件発生）
これがHashimoto流ハーネスエンジニアリングの本質だ。
ステップ2：最初のSensor（自動検証）を追加する
# .github/workflows/claude-review.yml
name: AI Code Review
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run lint
run: npm run lint
- name: Run tests
run: npm test
人間が確認できない速度でエージェントが動く場合、Sensorが安全網になる。
ステップ3：プロンプトエンジニアリングの知識でCLAUDE.mdを磨く
Few-shot examples、Chain of Thought、明確な制約——プロンプトエンジニアリングで有効だった技法を、CLAUDE.mdのルール記述に応用する。「曖昧な制約より具体的な例示」の原則はここでも生きる。
まとめ
プロンプトエンジニアリングとハーネスエンジニアリングは対立する概念ではない。プロンプトはハーネスの構成要素であり、プロンプトエンジニアリングで培ったスキルはハーネス設計でも活きる。
重要な分岐点は「エージェントが5ステップ以上の自律タスクを実行するかどうか」だ。チャットUI・軽いCLI使用はプロンプトとコンテキスト設計で十分。本番エージェント・チーム運用・組織展開ではハーネスの設計が不可欠になる。
コンテキストウィンドウがどれだけ広がっても、エージェントを正しく動かすための環境設計——Guides（事前制御）とSensors（事後検証）の二軸——の価値は消えない。
ハーネスエンジニアリングへの理解を深めたい方は、ハーネスエンジニアリングとは何か——5つの流派と設計思想を整理するも参照してほしい。また、Claude Codeでハーネスを実践する具体的な手法は Claude Code ベストプラクティスガイド2026 にまとめてある。
AIエンジニアリングが成熟するにつれ、「プロンプトが書ける」スキルは必要条件に過ぎなくなる。エージェント環境を設計できる力が、2026年以降のAIエンジニアの差別化要因になる。
参照ソース
- Harness Engineering - Martin Fowler
- Skill Issue: Harness Engineering for Coding Agents - HumanLayer
- Prompt vs Context vs Harness Engineering: Key Differences - Atlan
- From Prompt Engineering to Harness Engineering - Medium
- Enterprise AI Adoption Playbook - Stanford Digital Economy Lab
- The Context Window Race 2026 - claude5.com
- ハーネスエンジニアリングとは - speakerdeck.com/kinopeee
