ハーネスエンジニアリングとは──プロンプトの次に来る階層を現場目線で整理
「プロンプトエンジニアリングの次はコンテキストエンジニアリング、今度はハーネスエンジニアリング……」。数ヶ月ごとに新しい言葉が生まれて、正直ついていくのがやっとだと感じていませんか。僕も現役のSaaSエンジニアとして毎日Claude Codeを使っていますが、同じ感覚を持っています。ただ、2026年7月にXで拡散されたAnthropicエンジニアの社内開発解説動画と、「prompt→context→harness→loop」という階層整理を見て、バラバラだった用語が1枚の地図につながりました。この記事では、ハーネスエンジニアリングを含むAIエージェント開発の新語を「作業単位の大きさ」という1つの軸で整理します。Claude Codeなどのコーディングエージェントを日常的に使っている人、「エージェント開発をちゃんと理解したい」と思っている現役エンジニアが対象です。読み終わる頃には、新語に振り回されず「今詰まっているのはどの層か」を自分の言葉で言語化できるようになります。
ハーネスエンジニアリングが注目される背景
きっかけは2026年7月、Anthropicのエンジニアが社内のAI開発手法を語った動画がXで拡散されたことでした。紹介ポストで語られた内容が界隈の議論を一気に加速させました。動画のポイントは大きく2つです。
- Anthropic社内ではエンジニアの大半が「自己改善ループ」でAIエージェントを開発している
- エージェント開発の基本構成は「エージェント→ハーネス→ループ→記憶」という積み重ねになっている
この動画とあわせて、「prompt→context→harness→loop」という階層整理論もXで広く共有されました。プロンプトエンジニアリングから始まった一連の「〜エンジニアリング」を、別々の流行語ではなく1つの積み重ねとして捉える見方です。
ここで押さえておきたいのが「ハーネス」という言葉の由来です。ソフトウェアテストの世界には昔から「テストハーネス」という概念があります。テスト対象のコードを外側から囲い、入力を与え、出力を検証し、結果を集計する枠組みのことです。AIエージェントにおけるハーネスも発想は同じで、モデル単体ではなく、モデルの周囲に組む実行環境一式を指します。ツールの接続、処理の分割と連結、出力の検証、失敗時のリトライ。こうした「モデルを働かせるための枠組み」を設計する行為がハーネスエンジニアリングです。
問題は、こうした新語が出るたびに「前の概念はもう古い」という受け取られ方をすることです。「プロンプトエンジニアリングは死んだ」という類の言説は定期的にバズりますが、実際の構造は置き換えではなく積み重ねです。プロンプトが不要になったのではなく、プロンプトの外側にコンテキストの層があり、さらにその外側にハーネスの層があると分かってきた、というのが実態に近いと思います。この「積み重ね」という視点が抜けると、毎回ゼロから新語を学び直しているような疲労感だけが残ります。僕自身、この整理を知る前はまさにその状態でした。
プロンプトを磨いても、正解率1割の壁は超えられなかった
実は、ハーネスエンジニアリングという言葉を知る前に、僕は現場で同じ構造にぶつかっていました。2025年3月に本格着手した、請求書読み取り機能の改善です。請求書から金額や電気の使用量、契約内容を読み取る必要があったのですが、従来のラベリングによるOCRモデルの改善では正解率が約1割しかなかった。モデルへの与え方をどう工夫しても、単体のモデルを磨くアプローチではその壁を超えられなかったんですよね。そこで方式を変えて、AzureのOCRでまず文字情報を読み取り、その結果をOpenAIのLLMで解析するという二段階の構成にしたところ、読み取り率が大幅に向上した。この内容はZennにも記事として書きました。当時は意識していませんでしたが、これは単発の指示を磨く作業ではなく、「OCR→LLM→検証」という処理の連なり、つまりハーネスを設計する作業だったわけです。
もうひとつ実感していることがあります。Claude Codeを使うときも、ゴールが曖昧なままだと出力は安定しません。先に壁打ちしてゴールを言語化してから実装に入ると精度が上がる。これはプロンプト層とコンテキスト層の改善です。つまり僕は各層の改善を別々の「コツ」として体感していて、2026年になって「ハーネスエンジニアリング」という言葉が出てきたとき、後から名前が追いついてきた感覚がありました。変化についていくのがやっとだと思っていた新語が、実は現場でやってきたことの整理だった。この経験があるので、僕はこの階層整理を単なるバズワードだとは思っていません。
4階層の整理──作業単位の大きさで見る
ここからが本題です。乱立する「〜エンジニアリング」は、「1回の作業単位がどれくらい大きいか」という軸で並べると、きれいに4つの階層に整理できます。まず全体像を表で示します。
| 観点 | プロンプト | コンテキスト | ハーネス | ループ | |---|---|---|---|---| | 作業単位 | 1回の指示 | 1つのタスク・セッション | 複数処理の連なり | 開発サイクル全体 | | 改善対象 | 指示文の書き方 | モデルに渡す情報の選別・構造化 | ツール接続・処理分割・検証・リトライ | 実行結果を次の改善に戻す仕組み | | Claude Codeでの対応物 | 依頼文・スラッシュコマンド | CLAUDE.md・ファイル参照・メモリ | Hooks・Subagents・Skills | 自己改善ループ（結果を設定・プロンプトに反映） | | 詰まったときの症状 | 意図と違う出力が返る | 途中で文脈を忘れる・的外れな前提で動く | 単発では成功するのに一連の流れで壊れる | 同じ失敗を何度も繰り返す |
表の下から順に、各層をもう少し具体的に見ていきます。
第1層：プロンプトエンジニアリング
最小の作業単位は「1回の指示」です。指示の具体性を上げる、期待する出力形式を明示する、例を与える。2023年頃から蓄積されてきたテクニックの多くはここに属します。重要なのは、この層は今でも死んでいないということです。どれだけ外側の層を整備しても、最終的にモデルへ渡る指示文が曖昧なら出力は曖昧になります。
第2層：コンテキストエンジニアリング
作業単位が「1つのタスク」に広がると、指示文だけでなく「モデルが参照できる情報全体」が品質を決めるようになります。どのファイルを読ませるか、どんな前提知識を常駐させるか、逆に何を渡さないか。AnthropicもEffective context engineering for AI agentsという記事で、コンテキストは有限のリソースであり「何を入れるか」より「何を厳選するか」が本質だと整理しています。Claude CodeでいえばCLAUDE.mdの設計がまさにこの層です。
第3層：ハーネスエンジニアリング
作業単位が「複数の処理の連なり」になったのがこの層です。1つのモデル呼び出しで全部やらせるのではなく、処理を分割し、それぞれに適したツールやモデルを割り当て、間に検証を挟む。僕のOCR改善の例で言えば、「文字認識はOCRエンジンに、意味解釈はLLMに」という分割そのものがハーネス設計でした。Claude Codeでは、特定のタイミングで自動実行されるHooks、役割を分けたSubagents、手順をパッケージ化するSkillsなどがこの層の道具です。たとえばHooksなら、settings.jsonに次の数行を書くだけで「ファイルを編集するたびにテストを自動実行する」という検証ステップをハーネスに差し込めます。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [{ "type": "command", "command": "npm test" }]
}
]
}
}プロンプトやコンテキストをいくら磨いても頭打ちになるとき、原因はたいていこの層の不在にあります。
第4層：ループエンジニアリング
最後は「開発サイクル全体」を作業単位とする層です。エージェントに実行させ、結果を評価し、その評価をプロンプト・コンテキスト・ハーネスの改善に還流させる。Anthropic社内で多くのエンジニアが実践していると語られた「自己改善ループ」はこれです。失敗ログをそのまま次の入力に使う、レビュー指摘をルールファイルに追記して再発を防ぐ、といった運用がここに入ります。一度作って終わりではなく、使うほど賢くなる状態を仕組みとして作る層と言えます。
詰まったとき、どの層を疑うか──デバッグ手順
この4階層が一番役に立つのは、エージェントがうまく動かないときの切り分けです。僕は次の順番で確認しています。
- 出力が1回だけおかしいのか、毎回おかしいのかを見る。 1回だけなら、まずプロンプト層。指示を具体化して再実行します
- 毎回同じ方向にずれるなら、コンテキスト層を疑う。 CLAUDE.mdや参照ファイルに、古い情報・矛盾した情報・不要な情報が混ざっていないかを確認します
- 個々のステップは成功するのに、通しで実行すると壊れるなら、ハーネス層。 処理の分割単位が適切か、ステップ間の受け渡しに検証があるか、失敗時のリトライがあるかを見直します
- 同じ失敗が週をまたいで再発するなら、ループ層の不在。 失敗をルールや設定に還流させる仕組みがそもそもないケースです。修正のたびに学びをCLAUDE.mdなどに書き戻す運用を作ります
逆に言うと、この切り分けをせずに「とりあえずプロンプトを書き直す」を繰り返すのが一番消耗します。ハーネス層の問題はプロンプトでは直りません。僕がOCRの正解率1割で足踏みしていたときがまさにそれで、層を1つ上がって構成を変えた瞬間に状況が変わりました。詰まったら「どの作業単位が壊れているか」から考える。これがこの地図の実用的な使い方です。
なお、Claude Codeの各機能の具体的な使い方は公式ドキュメントに、実践的な運用パターンはAnthropicのClaude Code: Best practices for agentic codingにまとまっています。この記事の4階層を頭に入れてから読むと、どの機能がどの層の道具なのかが掴みやすくなります。
「結局バズワードの再包装では」という懐疑論
ここまで整理してきましたが、公平のために懐疑的な見方にも触れておきます。
まず「ハーネスエンジニアリングは既存概念の再包装ではないか」という指摘です。これは半分正しいと思います。処理を分割してパイプラインを組み、検証を挟むという発想自体は、ワークフロー設計やテストハーネスとして昔からあるものです。新しいのは概念そのものではなく、LLMという不確実な部品を前提にそれを組む必要が出てきた、という状況の方です。名前に飛びつく必要はありませんが、名前がついたことで議論しやすくなった価値は確かにあります。
次に、階層を増やすほど複雑性と運用コストが上がるという現実です。Hooksを仕込み、Subagentsを分け、検証ステップを挟めば、その分だけ保守対象が増えます。トークン消費も実行時間も増える。小さなスクリプトの生成やちょっとした調べ物なら、プロンプトを丁寧に書くだけで十分なケースが大半です。すべてのタスクに4層をフル装備するのは過剰設計であり、「作業単位が小さいうちは下の層だけで戦う」という判断も、この地図の正しい使い方に含まれます。
最後に、用語の定義が発信者ごとに揺れている点です。ハーネスにループを含める人もいれば、記憶（メモリ）を第5の層として立てる整理もあり、「graph」まで含めた5階層で語る人もいます。この記事の4階層も数ある整理の1つであり、確定した業界標準ではありません。大事なのは用語の厳密な定義を暗記することではなく、「作業単位の大きさで層が分かれている」という構造の方を掴むことだと考えています。
まとめ
ハーネスエンジニアリングを入り口に、AIエージェント開発の階層を整理してきました。要点は次の通りです。
- 新語は置き換えではなく積み重ね。プロンプトエンジニアリングは今も全階層の土台として生きている
- 判断軸は「作業単位の大きさ」。指示1回→タスク→処理の連なり→開発サイクル全体、の順に層が広がる
- ハーネスエンジニアリングは、モデルの周囲に組む実行環境（分割・接続・検証・リトライ）の設計を指す
- 詰まったときは「どの層の作業単位が壊れたか」から切り分ける。プロンプトの書き直しだけで粘らない
- 小さなタスクに全階層は不要。層を上げるのは、下の層で頭打ちになってからで十分
今日できるアクションとしては、まず自分のワークフローを4層に書き出してみることをおすすめします。普段の依頼文がプロンプト層、CLAUDE.mdや参照ルールがコンテキスト層、HooksやSubagentsがハーネス層、振り返りの仕組みがループ層。書き出してみると、自分がどの層に投資してきて、どの層が空白かが一目で分かります。僕の場合はループ層が一番手薄でした。新語に振り回されるのではなく、地図として使う。それがこの流れとの一番健全な付き合い方だと思います。
