ハーネスエンジニアリングとは何か：プロンプト→コンテキスト→ハーネスへ至るAIエージェント設計の変遷

最近 X で「harness engineering」という言葉を見かける頻度が増えた。プロンプトエンジニアリングとどう違うのか、コンテキストエンジニアリングとは別物なのか、この辺りが自分の中でも整理できていなかった。本記事ではこの3つを 階層的な包含関係 として整理し、それぞれが何を解決し、どこで限界を迎え、次の概念に引き継がれたのかを論文と実装例で追う。結論を先に言う。

Harness ⊃ Context ⊃ Prompt

ハーネスエンジニアリングはプロンプトエンジニアリングを置き換えるものではない。プロンプトを含むコンテキストを含む、より外側の実行環境を設計する技術である。そしてその先には、設計書と実装の乖離を埋める AI駆動開発（SDD / TDD） という次の課題が待っている。

3つの用語の早見表

全体像を先に掴んでおこう。

観点	Prompt Engineering	Context Engineering	Harness Engineering
対象範囲	1回の入出力の命令文	コンテキストウィンドウ全体の情報	モデルを取り囲む実行環境
主要技法	Few-shot / CoT / ReAct	RAG / XML構造化 / MCP / Memory管理	Hooks / Rules / Subagent / Sandbox
失敗モード	命令の誤解・脆弱性	Lost in the Middle / Context Rot	ループの不安定・仕様ドリフト
代表ツール	OpenAI Playground / LangChain	LlamaIndex / MCP サーバー	Claude Code / Cursor / Cline
比喩	CPU への命令コード	CPU の RAM 管理	モデルを動かす OS / 骨格
時間軸	静的（事前設計）	動的（実行中管理）	システム全体（長期運用）

この表を頭の片隅に置いて、各層を順番に見ていく。

プロンプトエンジニアリング — 命令の文言を最適化する

プロンプトエンジニアリングの目的は単純で、LLM に渡す命令文を設計して、1回の出力品質を上げること だ。対象はあくまで「単一のプロンプト文字列」であり、それ以外は触らない。

何を解決してきたか

2020年の GPT-3 論文（Brown et al., arXiv:2005.14165）が示した Few-shot Learning が出発点だ。タスクを説明する代わりに、入出力例を2〜3個見せるだけでモデルがパターンを学習して続きを生成する。この発見によって、プロンプトは単なる命令文から「プログラミング可能な入力インターフェース」に変わった。

2022年末に ChatGPT が公開されると、この技術は一気に広まり、「プロンプトエンジニア」という職種まで生まれる。同時期に体系的な手法もまとまって出揃った。

主要技法（論文引用付き）

• Chain-of-Thought (CoT) — Wei et al. (2022) arXiv:2201.11903
  中間推論ステップを明示するだけで複雑な算数・論理問題の精度が大幅に向上する。ただし効果が顕著なのは100B以上の大規模モデルに限られる。
• Zero-Shot-CoT — Kojima et al. (2022) arXiv:2205.11916
  "Let's think step by step" の一文を足すだけで MultiArith の精度が 17.7% → 78.7% に跳ねた。プロンプト1行の威力を象徴する論文。
• Self-Consistency — Wang et al. (2022) arXiv:2203.11171
  複数の推論パスを生成して多数決を取る。Greedy decoding より安定する。
• ReAct — Yao et al. (2022) arXiv:2210.03629
  推論（Reason）と行動（Act）を交互に実行するフレームワーク。後のエージェント設計の原型になった。
• Tree of Thoughts — Yao et al. (2023) arXiv:2305.10601
  推論を木構造で展開し、BFS/DFS で探索・枝刈りする。
• Reflexion — Shinn et al. (2023) arXiv:2303.11366
  失敗を「言語的な反省」としてコンテキストに追記し、次の試行を改善する。

失敗モードと限界

プロンプトエンジニアリングは強力だが、以下の壁にぶつかる。

• プロンプトの脆弱性: モデルバージョンが変わると、同じプロンプトでも結果が崩れる。特に OpenAI の GPT-4 系のマイナーアップデートで既存プロンプトが動かなくなる事例は枚挙にいとまがない。
• 長期タスクで文脈が失われる: 単一プロンプトでは複数ファイルにまたがる実装や、数十ステップの推論を扱えない。
• 近代モデルによる内部化: GPT-4o や Claude 3.5 以降、CoT は明示しなくてもモデル内部でほぼ自動的に実行される。「Let's think step by step」の効果は相対的に小さくなった。

今の位置付け

プロンプトエンジニアリングが消滅したわけではない。Fine-tuning のデータ設計、単一ターンのクリエイティブタスク、Few-shot でのタスク特化など、今でも必須の基礎技術 だ。ただし複雑なエージェント系タスクでは、プロンプトは「より大きな仕組みの一部品」として扱われるようになった。この「より大きな仕組み」が次の2つの概念である。

コンテキストエンジニアリング — 情報アーキテクチャを設計する

コンテキストエンジニアリングは、「何を言うか」ではなく「何を見せるか」 にフォーカスする技術だ。プロンプトの文言を磨く代わりに、コンテキストウィンドウという限られた領域に どの情報を、どの順序で、どのタイミングで投入するか を設計する。

用語自体は比較的新しい。2025年6月18日に Shopify CEO の Tobi Lütke が X で次のように投稿した。

"I really like the term 'context engineering' over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM." — Tobi Lütke (2025-06-18)

これに Andrej Karpathy が返信する形 で2025年6月25日に投稿したのが、後に広く引用されることになる次のツイートだ。

"+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step." — Andrej Karpathy (2025-06-25)

Karpathy は別の場面で LLM を OS に例え、「LLM は CPU、コンテキストウィンドウは RAM」 という比喩も提唱している。モデルの能力を引き出すには、この RAM をどう管理するかが次の核心スキルだというわけだ。

Lost in the Middle — 理論的根拠

コンテキストエンジニアリングが単なる流行語ではなく技術として成立する根拠を与えたのが、Liu et al. (2023) "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172) である。

この論文が示したのは次の事実だ。

• LLM の情報取得精度は U字型カーブ になる。コンテキストの先頭と末尾の情報は正確に処理されるが、中間部分の情報は著しく無視される。
• 関連文書を先頭または末尾に配置するだけで精度が大きく改善する。
• コンテキストが長くなるほど、中間部の「Needle」（重要情報）を見落とす確率が上がる。

「全部放り込めば勝手に読んでくれる」という期待は、この論文でほぼ崩された。長いコンテキストは高価なだけでなく、性能劣化の原因にもなる。後の "Context Rot"（文脈の腐敗）や "Context Pollution"（文脈の汚染）という概念は、この論文の実証を出発点にしている。

主要テクニック

• RAG (Retrieval-Augmented Generation) — Lewis et al. (2020) arXiv:2005.11401
  実は RAG の原論文は GPT-3 と同じ2020年に出ている。当時は「外部知識を注入する1手法」として見られていたが、コンテキストエンジニアリングの文脈では 中心的な技法 として再評価されている。
• Structured Context（XML タグ）
  Anthropic が推奨する手法で、システム指示・ユーザー入力・ツール出力を XML タグで明確に区切る。Claude ファミリーはこの構造を学習時から意識しているため、特に効果が高い。
• Context Compression / Summarization
  ツール実行の生ログや過去の会話履歴を要約に置き換える。Attention Budget を節約するための基本技法。
• Memory Management（短期 / 長期）
  セッション内の情報は短期メモリ、外部ストレージ（ベクター DB、ファイルシステム）に永続化するのは長期メモリ。claude-mem のようなツールはこの長期メモリを担う。
• MCP (Model Context Protocol)
  Anthropic が策定したオープン標準で、ツールやデータソースを「Just-in-Time」でコンテキストに注入する仕組み。ただし後述のように これ自体が新たな失敗モード を生んでいる。

失敗モード

コンテキストエンジニアリングには独自の失敗パターンがある。

• MCP の肥大化: MCP サーバーを複数接続すると、ツール定義だけでコンテキストを数千〜数万トークン消費する。モデルが「何を使うか」を判断する前に、ツール定義で窒息する現象。
• CLAUDE.md / AGENTS.md の肥大化: プロジェクト固有のルールを書き溜めていくと、ファイル自体が Context Pollution の原因になる。「重要だから」と書けば書くほど、本当に重要な情報が埋もれていく皮肉。
• Context Rot: 長時間のセッションで古い情報・失敗した試行のログ・重複した出力が蓄積し、モデルのパフォーマンスが徐々に劣化する。

実務テクニック

上記を踏まえた実務的な対処は次のようになる。

• 最重要制約は コンテキストの末尾 に配置する（Lost in the Middle を逆手に取る）
• サブエージェントは Stateless で動かし、オーケストレーター本体のコンテキストを汚染しない
• 必要ない MCP は接続しない。allowedTools で制限する
• CLAUDE.md は定期的に剪定する。「書き溜める」のではなく「育てる」

ここまで来ると、鍵は「単発のプロンプト品質」から「セッション全体の情報設計」に移っていることがわかる。これをもう一段外側に広げたのがハーネスエンジニアリングだ。

ハーネスエンジニアリング — モデルを囲む実行環境を設計する

ハーネスエンジニアリングは、LLM モデル本体を取り囲む「実行環境・ルール・ツール群・検証ループ」 を設計する技術である。プロンプトでもコンテキストでもなく、モデルが動く土台そのもの を最適化する。

この概念が明示的に語られるようになったのは2025年以降、Claude Code・Cursor・Cline などのエージェント型コーディングツールが普及してからだ。背景にあるのは次のような逆転だ。

弱いモデル + 堅牢なハーネス > 強いモデル + 貧弱なハーネス

「良いプロンプトを書く」ことより「良い実行環境を組む」ことの方が、実運用の品質を左右する。自分自身、Claude Code を数ヶ月使っていて、プロンプトを工夫するより .claude/rules/ にルールを追記する方が効く場面の方が圧倒的に多かった。この感覚を言語化したのがハーネスエンジニアリングである。

構成要素（Claude Code を例に）

Claude Code のハーネスは大きく4つの要素で構成されている。

1. Hooks — 実行ループへの介入

Claude Code には PreToolUse / PostToolUse / UserPromptSubmit / SessionStart といったフックがあり、任意のスクリプトを差し込める。例えばこんな使い方ができる。

# .claude/hooks/check-codex-before-write.py
# Edit/Write ツール実行前に Codex CLI に設計相談を促す
if tool_name in ("Edit", "Write") and is_significant_change(file_path):
    print("[Codex Suggestion] Consider consulting Codex before this change")

フックは モデルの判断に委ねるのではなく、宣言的にループを制御する 装置だ。プロンプトで「設計を相談してから書いてね」と頼むより、フックで強制するほうがはるかに確実である。

2. Rules / CLAUDE.md — 不変の制約

CLAUDE.md や .claude/rules/*.md に書かれた内容は、セッション開始時にシステムプロンプトへ自動注入される。「日本語で返答する」「main ブランチに直接 push しない」「テストを書いてから実装する」といった、プロジェクトの不変のルール を記述する場所だ。

コンテキストエンジニアリングの観点からは「肥大化に注意」と書いたが、ハーネスの観点では「動的に変わらない制約をコードで表現する」という役割を持つ。

3. Skills / Subagents — 再利用可能なワークフロー

Skill（.claude/skills/*/SKILL.md）はタスクに特化したワークフローを定義する仕組みで、Subagent（.claude/agents/*.md）は特定の役割を持つエージェントを独立コンテキストで動かす仕組みだ。ポイントは Stateless に動かせる こと。オーケストレーター本体のコンテキストを汚染せずに、重い処理を並列で回せる。

4. Tool Restrictions / Sandbox — 行動の制約

read-only や workspace-write のようなサンドボックスモード、allowedTools での許可リストは、モデルができる行動を物理的に制限する。プロンプトで「破壊的な操作はしないで」とお願いするのではなく、そもそもできないようにする のがハーネスの思想だ。

性能への影響 — SWE-bench での実証

ハーネスの効果は実データで示されている。SWE-bench（Jimenez et al., arXiv:2310.06770）は実際の GitHub Issue を LLM に解かせるベンチマークで、Anthropic が公開した Claude の SWE-bench Verified スコア推移が興味深い。

• 2024-06 Claude 3.5 Sonnet（モデル単体）: 33.4% (公式発表)
• 2024-10 Claude 3.5 Sonnet Updated: 49.0% (同上)
• 2025-02 Claude 3.7 Sonnet（素のモデル）: 62.3% (公式発表)
• 2025-02 Claude 3.7 Sonnet（custom scaffold 込み）: 70.3% ← +8.0% (同上)

注目すべきは 2025年2月の行だ。同じモデルに対してカスタムスキャフォールド（並列サンプリング・回帰テスト・拡張思考モードを組み合わせたハーネス）を被せるだけでスコアが 8 ポイント上がる。この差は、モデルの世代交代1回分に匹敵する大きさだ。

失敗モード

ハーネスエンジニアリングにも固有の失敗がある。

• 設計の複雑化: Hooks・Rules・Skill が増えるにつれ、誰が何を制御しているのか追いづらくなる
• サブエージェント間の状態管理: 複数のサブエージェントが並列で動くと、それぞれの結果を統合するオーケストレーションが難題になる
• コスト: 検証ループ・サブエージェント・フックはすべてトークン消費を増やす
• ハーネス設計スキルの希少性: 「良いプロンプト」を書ける人は増えたが、「良いハーネス」を組める人はまだ少ない

3層の関係 — 階層的包含とタイムライン

ここまでで見えてきたのは、3つが 置き換えではなく包含関係 にあるという事実だ。図にするとこうなる。

┌─────────────────────────────────────────────┐
│          Harness Engineering                │
│  （Hooks・Sandbox・サブエージェント）           │
│  ┌───────────────────────────────────────┐  │
│  │       Context Engineering             │  │
│  │  （RAG・Memory・構造化・MCP）            │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │     Prompt Engineering          │  │  │
│  │  │  （Few-shot・CoT・Zero-shot）    │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

この階層で最も重要なメッセージはこれだ。

上位層の設計ミスは、下位層の最適化では救えない。

ハーネスが壊れていれば、どんなに良いコンテキスト設計もプロンプトも無駄になる。逆に、ハーネスさえ整っていれば、プロンプトの細かいチューニングに消耗する必要はなくなる。

短いタイムラインで振り返ると、次のようになる。

• 2020 GPT-3 論文 / RAG 論文
• 2022 ChatGPT 公開 / CoT・ReAct 論文ラッシュ
• 2023 Lost in the Middle / SWE-bench 公開
• 2024 MCP 策定
• 2025-02 Claude Code リリース、カスタムスキャフォールドで +8% を公式実証
• 2025-06 Lütke → Karpathy の流れで Context Engineering が一気に浸透
• 2026 Harness Engineering の議論が本格化

3つはいずれも、前の世代の限界にぶつかったことで生まれた。そしてハーネスエンジニアリングにも、次の壁が見え始めている。

ハーネスの先にある課題 — 設計と実装の乖離

ハーネスを組み立てて運用していると、ある時期から気になってくる問題がある。設計書と実装の乖離だ。

何が起きるか

具体的にはこんな現象だ。

• Hooks・Rules・Skill が増えるにつれ、「このルールは何のためにあったのか」を誰も覚えていない状態になる
• CLAUDE.md や要件定義ドキュメントと実装の間にズレが溜まっていく。コードが変わっても仕様書は更新されない
• AI が仕様書より実装を信じる。「動くコード」が真実になり、「書かれた仕様」は形骸化する
• テストが通っていることを根拠に「正しい」と誤認する。テストがそもそも仕様と乖離している可能性には気づかない

これは「ハーネスが悪い」のではない。ハーネスは 実行時の制御 には強いが、設計と実装の一貫性を担保する仕組み は別に必要なのだ。

なぜ起きるか

原因は2つある。

1. AI はコードを一次ソースと見なしやすい: 仕様書とコードが矛盾していたら、AI はコードを正として仕様書を無視する傾向がある。特にコンテキストに両方が入っていると、より直近で更新されたコードが優先されやすい
2. ハーネスは「実行時」に作用する: Hooks や Rules は「今まさに AI が動こうとしている瞬間」に介入する装置だ。設計判断が行われるのは 実装より前 なので、ハーネスだけでは手が届かない

次の一歩 — AI駆動開発（SDD / TDD）

この問題に対する答えとして浮上しているのが、仕様を一次ソースに置く開発手法 である。いわゆる AI駆動開発の文脈だ。

Spec-Driven Development (SDD)
仕様書を中心に据え、そこから実装・テスト・ドキュメントを AI に生成させる。仕様が変わったらコードを再生成する、という逆転した関係を作る。2025年には GitHub の Spec Kit や Amazon の Kiro のように、仕様駆動を前提にしたツールが相次いで登場した。

Test-Driven Development (TDD)
テストを「実行可能な仕様」として AI に渡す。テストが先にあり、実装はそれを満たすように生成する。AI駆動 TDD では、テストがそのままハーネスの検証ループに組み込まれる。「テストが通ったら次のタスクへ」という確定的な進行が可能になる。

どちらも、「検証ループの確定性」を ハーネスの外側から 与える仕組みだ。

ハーネス × SDD/TDD の位置付け

重要なのは、これらがハーネスエンジニアリングと 対立するものではない ということだ。むしろ並行・補完関係にある。

• ハーネス: 実行時の制御・安全弁・ループの骨格
• SDD / TDD: 設計と検証の一貫性・真実の置き場所

ハーネスが AI の「行動の仕方」を決めるなら、SDD/TDD は AI に渡す「真実の源」を決める。両方が揃って初めて、「AI に仕事を任せても仕様と実装がズレない」状態が作れる。

実践ロードマップ — どの順序で学ぶか

ここまでの内容を踏まえて、学ぶ順序を整理しておく。

1. プロンプトエンジニアリング: 基礎として必須。CoT / ReAct / Few-shot の論文は原典を1本ずつ読むといい
2. コンテキストエンジニアリング: Lost in the Middle 論文と Karpathy の発言を押さえたうえで、実際に MCP / RAG を使ってみる
3. ハーネスエンジニアリング: Claude Code なり Cursor なりで Hooks・Rules・Skill を実装してみる。SWE-bench のスコア推移を追うと効果の大きさが実感できる
4. SDD / TDD（並行）: 3と並行して、仕様を一次ソースに据える開発手法に触れる。Kiro / Spec Kit / AI駆動 TDD の事例を追う

順序は大事だが、3と4は直列ではなく並行がおすすめだ。ハーネスを組みながら「この仕組みは設計書とズレていないか？」と問い続ける癖をつけると、後で仕様ドリフトに気づいたときの修正コストがだいぶ下がる。

まとめ

3層の関係をもう一度整理すると、こうなる。

• プロンプトエンジニアリングは命令の文言を最適化する技術。1回の入出力品質を上げる
• コンテキストエンジニアリングはコンテキストウィンドウの情報設計。何をどの順序で見せるかを決める
• ハーネスエンジニアリングはモデルを囲む実行環境の設計。Hooks・Rules・Skill でループを制御する
• そしてその先には、SDD / TDD による設計と実装の一貫性という次の課題がある

3つは置き換えではなく階層的な包含関係にあり、上位層の設計ミスは下位層では救えない。AI 連携で詰まっているときは、まずこの問いを自分に投げてみてほしい。

「今の課題は、どの層の問題か？」

プロンプトをいじっても直らない問題は、たいてい1つ上の層にある。そして、ハーネスまで組んでもなお残る問題は、もう層の外——仕様そのものの置き場所の問題である可能性が高い。

参考文献

論文

• Brown et al. (2020). "Language Models are Few-Shot Learners." arXiv:2005.14165
• Lewis et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv:2005.11401
• Wei et al. (2022). "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models." arXiv:2201.11903
• Kojima et al. (2022). "Large Language Models are Zero-Shot Reasoners." arXiv:2205.11916
• Wang et al. (2022). "Self-Consistency Improves Chain of Thought Reasoning." arXiv:2203.11171
• Yao et al. (2022). "ReAct: Synergizing Reasoning and Acting in Language Models." arXiv:2210.03629
• Shinn et al. (2023). "Reflexion: Language Agents with Verbal Reinforcement Learning." arXiv:2303.11366
• Yao et al. (2023). "Tree of Thoughts: Deliberate Problem Solving with Large Language Models." arXiv:2305.10601
• Liu et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." arXiv:2307.03172
• Jimenez et al. (2024). "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" arXiv:2310.06770

ブログ・発言

• Tobi Lütke (2025-06-18). "I really like the term 'context engineering' over prompt engineering..." X投稿
• Andrej Karpathy (2025-06-25). "+1 for 'context engineering' over 'prompt engineering'..." X投稿
• Anthropic (2024-10). "Introducing computer use, a new Claude 3.5 Sonnet, and Claude 3.5 Haiku." https://www.anthropic.com/news/3-5-models-and-computer-use
• Anthropic (2025-02). "Claude 3.7 Sonnet and Claude Code." https://www.anthropic.com/news/claude-3-7-sonnet
• Anthropic — Claude Code 公式ドキュメント（CLAUDE.md, Hooks, Skills）