プロンプトエンジニアリングとハーネスエンジニアリングの違い｜コンテキストとの関係と使い分け

「プロンプトを上手く書けばAIは動く」——この認識は、チャットUIでの対話には通用した。しかし2025〜2026年にかけてAIエージェントが実務に入り込み始めると、プロンプトだけでは制御できない問題が次々と現れた。

プロンプトエンジニアリングとハーネスエンジニアリングは、何が違うのか。どちらが優れているのか、ではない——これは互いに補完し合う概念だ。しかし、「どこまでがプロンプトの問題で、どこからがハーネスの問題か」を正しく切り分けられないと、間違った解法を当てて問題が解決しない。

この記事は、プロンプト・コンテキスト・ハーネスの3つの違いと使い分けに絞って比べる。ハーネスエンジニアリングそのものの意味・経緯・具体例は ハーネスエンジニアリングとは？AIエージェントのハーネスの意味・具体例・始め方 に、Claude Code でハーネスを組む設定は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめている。

プロンプトエンジニアリングとは何か——改めて定義する

プロンプトエンジニアリングの本質は、LLMへの入力テキストを設計することだ。

「こういうトーンで」「ステップバイステップで考えて」「JSON形式で返して」——これらは全てプロンプト設計の技術だ。Few-shot examples、Chain of Thought、Role prompting、RISEN形式などの手法が2022〜2023年にかけて体系化され、「プロンプトエンジニア」という職種まで生まれた。

プロンプトエンジニアリングが有効に機能する前提は次の通りだ:

• インタラクションが単発または短期（チャット形式）
• ツール呼び出しなし、または最小限
• 人間がループの中にいる（出力を人間が確認・修正する）
• 状態管理が不要（会話履歴のみで十分）

ChatGPT登場直後の世界では、この前提が多くのケースで成立していた。

プロンプトエンジニアリングの主要技術

ハーネスエンジニアリングとは何か——プロンプトの「外側」の設計

ハーネスエンジニアリングは、AIエージェントが自律的に動くための実行環境全体を設計する技術だ。

言葉の広さは語る人で違う。Mitchell Hashimoto は2026年2月のブログで「エージェントが間違えるたびに、同じ間違いをしない仕組みを作る」実践として書き、LangChain は Agent = Model + Harness（モデル以外すべて）と広く取り、martinfowler.com の Birgitta Böckeler は事前に導く Guides と事後に確かめる Sensors に分けて整理した。共通するのは、プロンプト単体を超えた「システム」として設計するという視点だ。経緯と出典は上の解説記事の時系列表にまとめている。

ハーネスの構成要素

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を出す。単発の質問ではなく、数十ステップにわたるタスクを連続実行する。

この変化がプロンプトエンジニアリングの限界を突き破る。

エージェントが長期タスクを実行するとき、プロンプトだけでは制御できない問題:

• ツール呼び出しの結果がコンテキストに積み重なり、途中で「指示を忘れる」
• 並行して動く複数エージェント間の調整
• 失敗時の再試行・回復ロジック
• コスト爆発の防止（無限ループ検知）
• 出力の品質保証（人間が確認できない速度で動く場合）

これらはプロンプトの文言を直しても解けない。エージェントを動かす環境の設計の問題だ。

変化3：プロンプト→コンテキスト→ハーネスの三段階進化

AIエンジニアリングの焦点は段階的にシフトした:

この三段階は「古いものが廃れて新しいものが取って代わる」ではない。下位の技術は上位の基盤として残る。プロンプトエンジニアリングは、ハーネスの中の各エージェントを動かすために依然として必要だ。

使い分け判断フロー

「プロンプトエンジニアリングで十分か、ハーネスが必要か」は、次の3つの問いで決められる。

細かく分けると、次の判断フローになる。

シナリオ別比較：チャット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"

このレベルになると、「いいプロンプトを書く」では解決しない問題が山積する:

• エージェントが無限ループに入ったときの脱出ロジック
• 複数サブエージェントの協調とコンテキスト共有
• 失敗時のロールバックと人間への通知
• トークンコストの追跡と上限設定

プロンプトエンジニアリングの知識がハーネスに活きる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. 実験段階: 個人・チームが試し始める
2. 意図的な導入: 経営層がガイドライン策定に関与
3. 測定: 生産性・品質・コストを指標化
4. 最適化: データに基づいてハーネスを改善

将来展望：コンテキストウィンドウのさらなる拡大で何が変わるか

2026年時点でClaude 1Mトークン、Gemini 2Mトークンが利用可能になった。さらに将来、コンテキストウィンドウが10M・100Mと拡大したとき、ハーネスエンジニアリングの重要性はどう変化するか。

変わること：「何を渡すか」の選別が緩和される

小さなコードベースや中規模のドキュメントは「全部渡す」戦略が現実的になる。RAGによる検索・絞り込みが不要になるケースが増える。コンテキスト管理の一部の複雑さは解消される。

変わらないこと：Context Rot と注意機構の問題

コンテキストウィンドウが広がっても、LLMの注意機構は長大な入力に対して均等には機能しない。Chroma社の研究では、Claude系モデルはコンテキスト増大に対して他モデルより劣化が遅いことが示されているが、それでも100万トークン超の文書では中盤への注意が薄れる傾向がある。

「何でも詰め込む」設計ではなく、必要な情報を選別して渡すハーネスの価値は維持される。

変わらないこと：マルチエージェントの協調設計

コンテキストウィンドウの拡大は単一エージェントの能力を高めるが、並行して動く複数エージェントの協調問題は解決しない。タスクの分割・割り当て・結果の統合は、コンテキストが何Mトークンになっても設計が必要だ。

変わること（かもしれないこと）：プロンプトの重要性

コンテキストが無限に近づいたとき、Few-shot examplesや詳細な指示をどれだけ含めても「トークンが足りない」という制約がなくなる。プロンプト設計の「コスパ最適化」の側面は薄れる可能性がある。ただし、「何を指示するか」の本質的な設計思考は変わらない。

まとめ

プロンプトエンジニアリングとハーネスエンジニアリングは対立する概念ではない。プロンプトはハーネスの構成要素であり、プロンプトエンジニアリングで培ったスキルはハーネス設計でも活きる。

重要な分岐点は「エージェントが5ステップ以上の自律タスクを実行するかどうか」だ。チャットUI・軽いCLI使用はプロンプトとコンテキスト設計で十分。本番エージェント・チーム運用・組織展開ではハーネスの設計が不可欠になる。

コンテキストウィンドウがどれだけ広がっても、エージェントを正しく動かすための環境設計——Guides（事前制御）とSensors（事後検証）の二軸——の価値は消えない。

ハーネスを最初の1行から育てる手順は、冒頭で挙げた解説記事の「やり方」の節にまとめた。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

追記（2026-08-14）：ハーネス側の更新速度という実測値

「プロンプトを磨くか、ハーネスを組むか」を判断する材料として、ハーネス側の変化の速さは見落とされやすい。代表例として Claude Code の更新頻度を実測した。

パッチ番号が232まで進んでいることが示すのは、ハーネス層が今も高頻度で動いているという事実である。これは実務上、次の含意を持つ。

・プロンプト側の資産は比較的長持ちする：「何をさせたいか」の記述は、ツールが変わっても移植できる
・ハーネス側の作り込みは陳腐化しやすい：特定バージョンの挙動に依存した仕組みは、更新で前提が変わりうる
・したがって投資順序は「まずプロンプト、次にハーネス」 が合理的である。ハーネスに寄せるのは、プロンプトだけでは越えられない壁（再現性・並列化・検証の自動化）に当たってからでよい

ハーネスエンジニアリングを否定する話ではない。変化の速い層に早く重く投資しない、という順序の問題である。