ハーネス・エンジニアリング

ある火曜日の午前3時

午前3時。あるチームのオンコールエンジニアがPagerDutyのアラートで叩き起こされました。

APIコストが急増。ダッシュボードを見ると、1時間で$400以上が消費されています。原因を調べると、前日デプロイしたAIエージェントが、不安定なAPIに対してリトライを繰り返していました。エラーが返るたびに「もう一度試みる」ループに入り、朝まで止まらなかった。

エージェントが悪かったわけではありません。使っていたモデルも問題ありませんでした。プロンプトも丁寧に書いてあった。問題はハーネスがなかったことです。つまり、エージェントに「走れ」とだけ伝えて、ブレーキもハンドルも付けなかった。

この話は珍しくありません。業界でよく言われる言葉があります。

「The model is commodity. The harness is moat.（モデルは商品。ハーネスが堀）」

デモ環境で完璧に動いたエージェントが、本番で壊れる理由はほぼ100%ハーネスの問題です。

2026年2月、OpenAIが1本のブログ記事を公開しました。

「Harness engineering: leveraging Codex in an agent-first world」

内容はこうです。5ヶ月間、エンジニアチームはコードを1行も手で書かなかった。100万行を超える本番アプリケーションを、Codexエージェントだけで構築した。ビルド時間は手書きの1/10。

「人間がステアリング。エージェントが実行」

エンジニアが仕事を取られたのではなく、仕事の定義が変わったのです。

この記事が火をつけました。さらに追い打ちをかけたのが、2026年2月の週末に起きた「$47,000のリトライ嵐」の報告です。あるデータエンリッチメントエージェントがAPIのエラーコードを「別のパラメータで再試行せよ」と誤解釈し、230万回のAPIコールを実行。月曜の朝、エンジニアが出社したら$47,000の請求書が待っていました。週末に働いてくれたのは嬉しいですが、成果物がゼロで請求だけ来るのは困ります。数日後にはAnthropicが2本のハーネス設計ガイドを公開。LangChainが「Agent = Model + Harness」と定義。Martin Fowlerが解説記事を書き、arXivに学術論文が投稿されました。

2024年はプロンプトエンジニアリングの年でした。「AIにどう聞くか」を磨いた時代。

2025年はコンテキストエンジニアリングの年。Andrej Karpathyが「The hottest new programming language is English」と言い、「AIに何を見せるか」を設計する時代になりました。

2026年、舞台はさらに広がります。ハーネスエンジニアリング。「AIが動く環境全体をどう設計するか」。

ただし、この言葉の解釈は論者によって微妙に異なります。OpenAIとAnthropicでは力点が違う。LangChainとMartin Fowlerでは切り口が違う。学術論文はさらに違う角度から攻めている。

本書は、この「ハーネスエンジニアリング」の全体像を体系的に整理します。

• 3つのエンジニアリング（Prompt / Context / Harness）の関係
• 主要プレイヤー（OpenAI / Anthropic / LangChain / Martin Fowler / 学術）の解釈の違い
• 6つの構成要素の解剖
• 関連技術（Vibe Coding / Spec Coding / Agent Framework）との位置関係
• 日本語圏の実践事例
• 未来の展望

概念の整理本であると同時に、明日から使える実践ガイドでもあります。「ハーネスって結局何？」と聞かれたとき、この本を渡せば済むようにしたつもりです。

本書の対象読者

• AIエージェント（Claude Code、GitHub Copilot、Cursor等）を使い始めたエンジニア
• AGENTS.mdやCLAUDE.mdを書いてみたが「これで合っているのか」と不安な人
• プロンプトエンジニアリングは知っているが、ハーネスエンジニアリングは初めて聞いた人
• チームにAIエージェントを導入したいマネージャー・テックリード

前提知識はプロンプトエンジニアリングの基礎（Few-shot、Chain-of-Thoughtを聞いたことがある程度）だけで十分です。

本書の読み方

通読しても、興味のある章だけ拾い読みしても構いません。ただし、以下の3章は全員に読んでほしいです。

• 第1章: 3つのエンジニアリングの関係を理解する（全体の地図）
• 第8章: 6つの構成要素を知る（実践の骨格）
• 第11章: AGENTS.mdの書き方を学ぶ（明日から使える）

この続きはKindleで →

40%が失敗する理由

2026年、AIエージェントプロジェクトの40%が失敗しています（Company of Agents調べ）。

失敗の原因は何でしょうか。モデルの選択ミス？プロンプトの質？

違います。「成功と失敗の差はモデルではない」——これが現場の一致した見解です。

Y Combinator DevTool Day（2026年3月）でCTO・CPOにインタビューした調査によると、失敗プロジェクトに共通するのは「ハーネスの不在」。エージェントが動く環境を設計していないことです。

YCのエンタープライズ企業の75%にはすでにコーディングエージェントが導入されています。しかしその多くが「デモでは動くが本番で崩壊する」という壁にぶつかっています。

Linearは2026年3月に「イシュートラッキングは死んだ」と宣言しました。コーディングエージェントにissueのコンテキストを直接渡せば、人間がチケットを管理する必要はない、という意味です。エンタープライズのワークフローがエージェントを前提に再設計されている。

この転換期に「ハーネス」の理解なしにエージェントを本番投入するのは、シートベルトなしで高速道路に乗るようなものです。速くは走れますが、最初のカーブで飛びます。

タイムライン

3つは何が違うのか

プロンプトエンジニアリング

対象: 1つのプロンプト（入力テキスト）

「AIに何をどう聞くか」の最適化。Few-shot、Chain-of-Thought、ReAct。1回のやり取りの精度を最大化する技術です。

コンテキストエンジニアリング

対象: AIに渡す情報全体（システムプロンプト + RAG + ツール定義 + メモリ）

Andrej Karpathyの言葉を借りれば「it is a lot more than just the prompt itself」。単一のプロンプトでは不十分な場面が増え、動的に構築されるコンテキストウィンドウ全体を設計する必要が出てきました。

Philip Schmidt（元Hugging Face、Google DeepMind）は「AIを使う新しいスキルはプロンプティングではなく、コンテキストエンジニアリングだ」と主張しています。

ハーネスエンジニアリング

対象: AIが動作する環境全体（コンテキスト + 制約 + ツール + ライフサイクル + フィードバック + 監視）

Louis Bouchardの定義が簡潔です。

コンテキストエンジニアリングは「モデルに何を送るか」。ハーネスエンジニアリングは「全体がどう動くか」。

プロンプトでもコンテキストでもなく、モデルの周りの 環境 を設計する。料理に例えるなら、プロンプトはレシピ、コンテキストは食材、ハーネスはキッチンそのものです。

入れ子構造

この3つは対立概念ではありません。入れ子になっています。

SmartScopeの記事が明快に整理しています。

ハーネス ⊇ コンテキスト ⊇ プロンプト

エレファンキューブの日本語記事も秀逸な比喩を使っています。

家を建てるとき、基礎がなければ壁は立たず、壁がなければ屋根は載りません。良いプロンプトがあってこそコンテキスト設計が活き、コンテキスト設計があってこそハーネスが機能する。

「置き換わる」のか「積み重なる」のか

ここに解釈の分岐点があります。

「置き換わる」派:

Data Science Dojoは「なぜハーネスエンジニアリングがプロンプトエンジニアリングを置き換えるのか」とタイトルに掲げています。2025-2026年のエージェントは、プロンプトやコンテキストが想定していない環境で動いている、と。

「積み重なる」派:

AnyTech（Medium）は「3つに本質的な違いはない。用語の変化は、LLMとエージェントがより多くのことをするようになった反映」と書いています。新しい流行語が来るたびに前の知識を捨てなくていい、という安心感のある主張です。

本書の立場: 「積み重なる」派です。プロンプトエンジニアリングは依然として重要。ただし、それだけでは不十分な場面が急速に増えています。ハーネスエンジニアリングはプロンプトとコンテキストを包含し、その外側の層（制約、ライフサイクル、フィードバック）を追加した概念です。

なぜ今このタイミングなのか

DEV.toのWonderLabの記事が指摘しています。

タイミングは偶然ではない。2025年、AIエージェントは「面白いデモ」から「実際の生産性ツール」になった。

エージェントが長時間自律的に動くようになると、1回のプロンプト最適化では制御できません。コンテキスト設計だけでも足りない。環境全体の設計が必要になる。

この「必要性の切迫」がハーネスエンジニアリングを生んだのです。

この続きはKindleで →

「デモで動いて本番で壊れる」の正体

harnessengineering.academyはこう言っています。

OSなしでCPU上で直接ソフトウェアを動かさないように、ハーネスなしでAIエージェントをデプロイするな。

CPUは計算できます。しかしOSなしでは、メモリ管理も、プロセスのスケジューリングも、I/Oも制御できません。同様に、モデルはテキストを生成できます。しかしハーネスなしでは、コンテキスト管理も、ツール制御も、失敗時の対応もできません。

「デモでは動いて本番で壊れる」エージェントの9割は、ハーネスの問題です。具体的に言うと：

• デモ: 制御された環境。フロー通りに質問が来る。APIは正常に動く。コンテキストは短い。
• 本番: カオス。予期しない入力。APIが落ちる。コンテキストが肥大化する。並列実行でレースコンディション。

ハーネスは本番のカオスを吸収する緩衝材です。デモはショールーム、本番は公道。ショールームで完璧に走る車が公道で使えるかどうかは、別の話です。

「ハーネス」という言葉の由来

NxCodeの記事が語源を明示しています。

この用語は馬具（equestrian equipment）から借用されている。馬は力強く速いが、手綱、鞍、くつわがなければ好き勝手に動く。AIモデルが馬。ハーネスがその力を生産的に制御するすべて。

note記事（kazu_t氏）はOSとアプリケーションコードの比喩を使っています。

プロンプトがアプリケーションコードだとすれば、ハーネスはOS。

Aakash Gupta（Medium）はさらにシンプルに。

モデルがエンジン。ハーネスが車。最高のエンジンも、ステアリングとブレーキがなければどこにも行けない。

テストハーネスとの区別

Parallel.aiが重要な注意点を述べています。

テストハーネス（ソフトウェアエンジニアリングの古い用語）と混同しないこと。テストハーネスは入力を与えて出力を自動チェックするフレームワーク。エージェントハーネスはAIの動作環境全体。

検索すると「ハーネス」で電気配線やCI/CDプラットフォーム（Harness.io）がヒットします。本書で言うハーネスはAIエージェントの制御環境を指します。

定義の比較

各プレイヤーの定義を並べてみます。

OpenAI

「人間がステアリング。エージェントが実行。この制約を意図的に課すことで、エンジニアリング速度を桁違いに向上させるのに必要なものを構築した」

ハーネス = エージェントが確実にコードを書ける環境

Anthropic

「マルチコンテキストウィンドウ対応、初回コンテキストでの環境セットアップ、コンテキスト管理、サブエージェント構成」

ハーネス = 長時間実行エージェントの安定制御システム

LangChain

「Agent = Model + Harness。モデルが知性を持ち、ハーネスがその知性を有用にする」

ハーネス = モデルの知性を有用な仕事に変換する外殻

Martin Fowler

「強い型付き言語は型チェックがセンサーになる。モジュール境界がアーキテクチャ制約を提供する。フレームワークが暗黙的にエージェントの成功確率を上げる」

ハーネス = コードベースが持つ暗黙の制約と明示的な制約の総体

Louis Bouchard

「“モデルがバカだ”と言うのをやめよう。代わりに”自分のシステムがこの失敗モードを許容した”と言おう」

ハーネス = 失敗モードを許容しない環境設計

共通点を抽出する

表現は違いますが、全員が同意しているポイントがあります。

1. ハーネスはモデルの外側にある: モデルのパラメータをいじる話ではない
2. 制約は「お願い」ではなく「強制」: 守らないと進めない仕組みにする
3. フィードバックループが必須: 出力を評価し、環境を改善し続ける
4. 人間の役割が変わる: コードを書く人→環境を設計する人

ハーネスエンジニアリングの正式な定義（本書）

各プレイヤーの定義を統合し、本書では以下のように定義します。

ハーネスエンジニアリング とは、AIエージェントが長時間にわたって自律的に動作するための環境全体を設計する技術。コンテキスト管理、制約の強制、ライフサイクル管理、フィードバックループ、監視、セキュリティ境界を含む。

ハーネスがない場合に何が起きるか

ハーネスの価値は、ハーネスがない場合の問題を見ると明確になります。

問題	ハーネスなし	ハーネスあり
コードスタイル統一	エージェントが毎回違うスタイルで書く	リンターhookで自動統一
テスト作成	「テストを書いて」と毎回お願い	pre-commitで未テストをブロック
機密情報の扱い	エージェントがAPIキーをコードに埋め込む	セキュリティ境界で検出・拒否
長時間タスク	コンテキスト肥大化で品質低下	コンテキストリセット+進捗ファイル
品質の再現性	担当者（人間もAIも）次第	環境で保証

ハーネスは「お願い」を「仕組み」に変える技術です。「テスト書いてね」と100回言うより、テストなしではコミットできない仕組みを1回作るほうが確実です。部下の教育と同じですね。

プロンプトエンジニアリングとの決定的な違い

プロンプトエンジニアリングは「1回のやり取り」を最適化します。ハーネスエンジニアリングは「100回のやり取り」を最適化します。

1回のやり取りなら、良いプロンプトで十分です。しかしエージェントが1日中コードを書き続ける場合、1回目のプロンプトの効果は50回目には薄れています。コンテキストが肥大化し、最初の指示は遠い過去に流れ、エージェントは最初と違う振る舞いを始めます。

ハーネスはこの問題を解決します。プロンプトが「最初の一押し」なら、ハーネスは「常に効いている重力」です。

次章からは、各プレイヤーの解釈を個別に深掘りします。

この続きはKindleで →