ハーネスエンジニアリング入門: LLMの周りを"配線する"設計

「ハーネスエンジニアリング」という言葉が2026年に入って一気に広まった。プロンプト工学→コンテキスト工学に続く、AIエージェント開発の第3の柱として扱われ始めている。とはいえ「ハーネス?馬具?何それ?」という人がまだ大半だ。実は、あなたが普段使っている Claude Code も Cursor も Codex CLI も、その正体は全部「ハーネス」である。本記事は、ハーネスとは何か・なぜ今これが重要か・自分の作業のどこに既に潜んでいるかを、図解中心で一気通貫に整理する。

1. ハーネス、まず言葉から

英語の “harness” は馬具のこと。馬そのものは強力でも、車を引かせるには「胴体に巻く帯」「手綱」「車との連結金具」がなければ仕事にならない。AI業界の用法もまったく同じで、LLM を仕事させるための周辺装置の総体を harness と呼ぶ。

モデルは馬。ハーネスは胴帯・手綱・連結金具にあたる周辺装置の総体。これが整って初めて、エージェントは仕事をする存在になる。

つまりハーネスエンジニアリングとは、「LLM を中心に置いて、周りの装置をどう設計するかの工学」だ。プロンプトの言い回しを磨くのとも、文脈に入れる情報を選ぶのとも、別の階層の話になる。

2. なぜ2026年に急浮上したのか ― 3層の進化

AIエンジニアリングの主役は3年で2回交代している。プロンプト工学(2022-2024) → コンテキスト工学(2025) → ハーネス工学(2026)。ハーネスが今ホットなのは、前の2層が成熟して残った変数が周辺装置に集中したからだ。

2022-2024

プロンプト工学

何を聞くか。Few-shot、Chain-of-Thought、ロール設計など、単発の指示文を磨き上げる時代。
2025

コンテキスト工学

何を見せるか。RAG・履歴圧縮・CLAUDE.md / AGENTS.md など、文脈ウィンドウに何を詰めるかが主戦場に。Karpathy が「prompt engineering より context engineering」と発言。
2026

ハーネス工学

どう動かすか。ツール、メモリ、ループ、サーキットブレーカー、観測、承認ゲートまで含めた周辺装置の設計に主導権が移った。

3つは置き換わるのではなく積み上がる。ハーネス工学が来ても、プロンプトとコンテキストはサブセットとして中に残る。

転換点になったのは、OpenAI Codex チームの一節として広く引用されている言葉だ。

Agents aren’t hard; the harness is hard.（エージェントは難しくない。ハーネスが難しい）

— OpenAI Codex チーム / 2026年初頭

モデル自体は十分賢くなった。だが「賢いモデル + ひどいハーネス」は「ふつうのモデル + 良いハーネス」に負ける。これが2026年の合言葉になっている。

3. ハーネスの中身 ― 9〜11の構成要素

複数の解説記事を突き合わせると、ほぼ全員が同じ部品リストに収束する。「システムプロンプト・ツール・メモリ・コンテキスト管理・ループ・パース・状態・エラー処理・ガードレール・検証・サブエージェント」の11個。それぞれを軽く見ておこう。

エージェントの1ターンは Plan → Tool Call → Execute → Observe → Plan… を繰り返すループ。ハーネスはこのループ全体を支える土台になる。

Loop

①オーケストレーション・ループ

Plan→Act→Observe を回す心拍部

Tools

②ツールレジストリ

スキーマ定義+サンドボックス実行

Ctx

③コンテキスト管理

圧縮・JIT検索・観測マスキング

Mem

④メモリ

セッション内/横断の2層構造

Parse

⑤出力パース

native tool calling 前提

State

⑥状態管理

チェックポイント+再開可能性

Guard

⑦ガードレール

入出力/ツール層のトリップワイヤ

Verify

⑧検証ループ

rule/visual/LLM-judge で品質2-3倍

Sub

⑨サブエージェント

fork / handoff / 専門特化

ハーネスを構成する主要9要素。これに「エラー処理」「プロンプト構築」を足して11要素とする数え方もある。

4. 3層の違いを並べて見る

「結局プロンプト工学・コンテキスト工学・ハーネス工学は何が違うのか」が一番混乱しやすい。以下の対比表が一番速い。

プロンプト工学

ハーネス工学

対象

1回の指示文の言い回し

モデルの周辺装置の総体

時間軸

1ターン以内

セッション全体・複数セッション・運用ライフサイクル

主な変数

Few-shot例、CoT、ロール、出力フォーマット

ツール構成、メモリ、ループ制御、承認ゲート、観測

失敗の症状

指示通りに動かない

ループ暴走、トークンバーン、無断破壊操作、不可観測

効くタイミング

単発タスク・分類・要約

長時間自律実行・ツール使用・本番運用

誰が書く

プロンプター個人

プラットフォームエンジニア+SRE的役割

プロンプト工学とハーネス工学は競合せず、別レイヤーの話。コンテキスト工学はその中間でメモリ/RAG/履歴を扱う。

5. 効くという証拠 ― 実測ベンチで何が起きたか

抽象論ではなく、2025-2026年に報告された具体的な数値だけを並べる。

ハーネスを変えただけで起きた性能変化（同モデル）

Vercel: ツール80%削減で成功率 100%

ベースライン80% → ハーネス再設計で100%

LangChain: Terminal Bench 2.0 順位 5位

同モデルでハーネス変更のみ。下位 → Top5

同モデル別ハーネスのスコア差 12%

片方2%・もう片方12%、6倍差

ハーネス変更による相対solve rate改善 64%

研究報告ベースの中央値

主要事例。モデルを変えていない条件下で、ハーネスだけでこの幅が動く。 / Addy Osmani / Avi Chawla / Epsilla 各記事の引用値

It’s not a model problem. It’s a configuration problem.（モデルの問題ではない。設定の問題だ）

— HumanLayer 創業者 / 2026

「強モデル＋悪ハーネス < 並モデル＋良ハーネス」。これがコミュニティで合意されつつある経験則だ。

6. 現実のハーネスを3つ並べる ― Claude Code / Codex CLI / Cursor

ハーネスの設計思想は製品ごとに違う。同じ Claude Opus 4.7 を使っていても、Cursor で動かすか Claude Code で動かすかで挙動も得意分野も別物になる。

Claude Code

Cursor

設計思想

透明性と制御性。デフォルト read-only、破壊操作は明示承認

IDE密結合と対話性。差分レビューを承認ゲートにする

コンテキスト戦略

関連ファイルだけ選択読込。CLAUDE.md を起点に階層展開

コードインデックス+セマンティック検索でJIT注入

ツール構成

file/bash/web/MCP。サブエージェントで分散

symbol lookup / diff / test runner などIDE機能を直接ツール化

モデル選択

Anthropic 中心、自分でモデルを意識

抽象化されモデル切替可（GPT/Claude/Gemini）

向くタスク

長文脈・複雑リファクタ・自律実行

日常イテレーション・UI構築・即時フィードバック

Claude Code は「自律性最大化」、Cursor は「開発者との対話最大化」。Codex CLI はその中間で「速度最大化」、ツール呼び出しがモデルAPIに統合されている。

同じLLMでもハーネス構成が違えば別エージェントになる。性能差は今やモデル差より大きい局面が増えている。

7. 「自分はあまり使ってない気がする」 ― いや、実は使っている

冒頭の問題提起への答えがここに来る。Claude Code を起動した瞬間、あなたはハーネスを起動している。普段「設定」だと思って触っているもののほとんどが、教科書的にはハーネス工学の構成要素だ。

教科書のハーネス用語

実は普段こう呼んでいる

System Prompt 階層

System Prompt / Persona

`~/.claude/CLAUDE.md` + プロジェクトの `CLAUDE.md`

Tool Registry

Tools / MCP servers

`Read` `Edit` `Bash` `WebSearch` などの内蔵ツール、追加したMCPサーバ

Context Manager

Context compaction / retrieval

自動コンパクション、`@file` インポート、auto memory

Memory

Short/Long-term memory

会話履歴 + `~/.claude/projects/.../memory/MEMORY.md`

Guardrails

Permission gates / safety hooks

権限ダイアログ、`settings.json` のhooks、destructive操作ブロック

Sub-agents

Subagent orchestration

`Explore` `Plan` `general-purpose` などの subagent_type

Verification

LLM-as-judge / lint loops

`/ultrareview`、`npm run check`、pre-commit hook

Observability

Traces / logs

ターミナルの実行ログ、Codex の rollout JSONL

左の研究用語が、右では完全に「普段の運用」として存在している。違いは語彙だけで、本質的に同じ層を触っている。

8. 自分のハーネスを意識的に組む ― 最小チェックリスト

最後に、いまの自分のセットアップを「ハーネス工学の目」で見直す観点を5つだけ置いておく。

1

System Prompt層を階層化したか

グローバル(~/.claude/CLAUDE.md)・プロジェクト(./CLAUDE.md)・サブパス(.claude/rules/*.md)の3層に分け、@インポートで読ませる。
2

ツールを"削った"か

Vercelは80%削って成功率が80→100%。多すぎるツールはモデルを迷わせる。MCPサーバや内蔵ツールを過剰に有効化していないか棚卸し。
3

メモリを"育てて"いるか

auto memory / MEMORY.md を放置していないか。失敗・成功どちらも書き残して反復ミスを潰す。
4

サーキットブレーカーがあるか

タイムアウト、再帰深さ、コスト上限、destructive操作の承認ゲート。無限ループとトークンバーンの保険。
5

検証ループが回っているか

npm run check / テスト / LLM-as-judge / ultrareview。"出力した"と"正しい"の間の橋。

ハーネスは一度作って終わりではなく、失敗をルールに変換し続けるラチェット(逆戻りしない歯車)として育てる。

9. まとめ

ハーネスエンジニアリングは、突然湧いた新概念ではない。もともと「設定」「Tips」「ベストプラクティス」と呼ばれていたものに、明確な名前と理論的位置づけが与えられただけだ。だがその効果は具体的で、同じモデルでもハーネス次第で 6 倍、絶対値で 80 → 100% のレンジで性能が動く。

普段 Claude Code / Cursor / Codex CLI のどれかを触っている時点で、あなたは既にハーネスのユーザーだ。次のステップは、それを”設定”ではなく”自分が設計している周辺装置”として見直すこと。 CLAUDE.md を一行足すたびに、ツールを一つ削るたびに、hooks を一つ書くたびに、自分のハーネスは少しずつ強くなっている。

「モデルではなく、モデルの周りを設計する」 ― これが2026年のエージェント開発のいちばん短い要約だ。

Claude Code公式ベストプラクティス日本語ガイド — 本稿のハーネス観を Claude Code の具体設定に落とす
AGENTS.md / CLAUDE.md / メモリ運用プレイブック — ハーネスの中核になる指示ファイルの設計
CLAUDE.md ジェネレーター + 採点 — 自分のハーネスの起点になる CLAUDE.md を生成・採点できる無料ツール

ハーネスエンジニアリング入門: LLMの周りを"配線する"設計

1. ハーネス、まず言葉から

2. なぜ2026年に急浮上したのか ― 3層の進化

3. ハーネスの中身 ― 9〜11の構成要素

4. 3層の違いを並べて見る

5. 効くという証拠 ― 実測ベンチで何が起きたか

6. 現実のハーネスを3つ並べる ― Claude Code / Codex CLI / Cursor

7. 「自分はあまり使ってない気がする」 ― いや、実は使っている

8. 自分のハーネスを意識的に組む ― 最小チェックリスト

9. まとめ

関連記事

一次情報・参考リンク

関連して読む

AIエージェント開発2026: Vibe Coding後半破綻と設計原則

SEOからAOへ: AIエージェント時代のウェブ最適化

Claude Code/Codexで失敗する5つの理由と回避策