ハーネスエンジニアリングとは——プロンプトの「外側」を設計する、AIエージェント時代の新領域

「ハーネスエンジニアリング（Harness Engineering）」は、2026年2月に広まった言葉だ。ターミナル Ghostty の作者で HashiCorp 共同創業者の Mitchell Hashimoto 氏が2026年2月5日のブログで、エージェントが間違えるたびに同じ間違いを二度させない仕組みを作ることをこう呼び、その6日後に OpenAI が Codex チームの実験報告の題に掲げた。Anthropic もそれより前から、長時間動くエージェントの周りの仕組みを「ハーネス」と呼んで設計を公開している。2025年に「プロンプトの次はコンテキストエンジニアリング」と言われた流れの、さらに外側を扱う考え方だ。

本記事では、ハーネスエンジニアリングの定義、プロンプト・コンテキストエンジニアリングとの違い、ハーネスを構成する6つの要素、OpenAI と Anthropic が公開している実例、実践チェックリスト、主要ツールの比較まで、AIエージェントを本気で使う・作るために知っておくべき土台を整理する。

1. ハーネスエンジニアリングとは何か

ハーネス（harness）は本来、馬具・装具を意味する英単語だ。馬の力を制御し、目的の方向に導く装備を指す。AI業界における「ハーネス」もまったく同じ比喩で、LLM という強力だが暴れ馬な存在を、目的に向けて働かせるための装備一式を指す。

具体的には:

• ツール（Tools）: ファイル操作、Web検索、コード実行など、LLMが「行動」できる手段
• コンテキスト管理: 何をプロンプトに含め、何を圧縮・破棄するかの戦略
• 記憶システム: セッションを跨ぐ知識・ユーザー設定の永続化
• エージェントループ: 知覚→推論→行動→観察 の繰り返し
• ガードレール: 権限・サンドボックス・Hooks・承認フロー
• 出力フォーマット: マークダウン、JSON、引用、ストリーミング

これら全体を設計するのがハーネスエンジニアリング。LLM そのものを学習・改良するのではなく、LLMの周りを工夫することで実用性を引き上げる技術だ。Claude Code・Cursor・Devin・Codex CLI などはすべて、同じLLMを使っていても「ハーネスの違い」で挙動と性能が大きく異なる。

「ハーネス」という語の範囲は、Thoughtworks の Birgitta Böckeler 氏による martinfowler.com の解説（2026年4月2日）が分かりやすい。ハーネスはエージェントのうちモデル以外のすべてで、式にすると Agent = Model + Harness。Anthropic も、クラウドでエージェントを動かすサービス Claude Managed Agents を「設定可能なエージェント・ハーネス」と説明している。

2. プロンプトエンジニアリングとの違い

プロンプトエンジニアリングが廃れたわけではない——だがスコープが大きく違う。

プロンプトエンジニアリングが「LLMに何を言うか」の技術なら、ハーネスエンジニアリングは「LLMに何を持たせ、どう運用するか」の技術——両者は競合ではなく階層関係にある。プロンプトはハーネスの中の1要素にすぎない。

もう一つ混同しやすいのがコンテキストエンジニアリングだ。Anthropic は 2025年9月29日の記事で、これをプロンプトエンジニアリングの自然な延長と位置づけた。前出の Böckeler 氏は、コーディングエージェントのハーネスづくりをコンテキストエンジニアリングの一形態と書く。整理すると、プロンプト（何を言うか）⊂ コンテキスト（何を見せるか）⊂ ハーネス（何を持たせ、どう検査し、どう止めるか）という入れ子になる。ハーネスに特有なのは、リンターやテストのように結果を機械的に検査してエージェントに差し戻す仕組みまで含む点だ。

3. ハーネスを構成する6つの要素

① ツール定義（Tool Use）

LLMが世界に作用する手段。ファイル読み書き、コード実行、Web検索、API呼び出しなど。ツールのインターフェイス設計（名前・引数・返り値）が悪いとLLMは正しく使えない。具体的には次のとおり。

• 動詞ベースの明確な命名（read_file など）
• 必須/任意引数の明示、デフォルト値
• エラー時の構造化メッセージ（次に何をすべきか教える）
• 副作用（破壊的操作）には明示の警告を記述

② コンテキスト管理

LLMの注意は有限——何を見せるかが、何を言わせるかを決める。具体的には次のとおり。

• 関連性フィルタ: 全ファイルではなく、タスクに関連する部分だけ抜粋
• 圧縮（compaction）: 長い会話を要約して保持
• RAG連携: 必要な情報をベクトル検索で取得
• キャッシング: 繰り返し送るシステムプロンプトを Anthropic prompt cache 等でコスト削減

関連: RAGとは何か

③ 記憶システム

セッションを跨ぐ知識の保持。Claude Code の CLAUDE.md、Cursor の .cursor/rules、Codex の AGENTS.md はいずれもプロジェクト記憶の例。ほかに、次の種類の記憶もある。

• 短期記憶: 直近の会話履歴
• 長期記憶: ユーザープロファイル、過去の意思決定
• 事実知識: ドメイン固有の知識ベース

④ エージェントループ

「AIエージェント」を成立させる中核。基本形は 知覚→推論→行動→観察 のサイクル。

1. ユーザーのゴールを受け取る
2. 現状を分析（必要ならツールで情報収集）
3. 次の行動を計画
4. ツールで行動
5. 結果を観察、ゴール達成判定
6. 未達ならループ、達成なら終了

ここに 計画立て直し（replan）・自己批評・サブゴール分解 を組み込むかでエージェントの賢さが変わる。

⑤ ガードレール

暴走防止の仕組み。AIがルールを無視する問題 でも触れたが、文章で頼むより環境で強制する方が確実だ。

• 承認モード: 危険な操作の前に人間の確認を挟む（Claude Code の権限設定、Codex CLI の承認モード等）
• サンドボックス: ファイルシステム/ネットワークアクセスを限定
• Hooks: ツール呼び出し前後に任意のチェック
• Rate limiting: 暴走時の被害最小化

⑥ 出力UX

ユーザーが結果を理解・検証できる形で出す。マークダウン整形、引用元の明示、コードブロックのシンタックスハイライト、ストリーミング表示、思考過程（thinking）の可視化、構造化出力（JSON）など。「正しい答え」を出すだけでは不十分で、「ユーザーが信頼して検証できる形」で出すのがハーネスの仕事。

4. なぜ今ハーネスエンジニアリングなのか

ハーネスへの関心が高まっている背景は3つある。

① 同じモデルでも、周りの仕組みで結果が大きく変わると示された。 Anthropic が 2026年3月24日に公開した実験では、同じ Claude Opus に「2Dのレトロゲーム制作ツールを作って」と1文で頼んだ。単独のエージェントは20分・$9で終わったが、作ったレベルを遊べなかった。計画役・実装役・検査役の3つに分けたハーネスは6時間・$200かかった一方、キャラクターを実際に動かして遊べるところまで作った（物理挙動の粗さは残った）。費用は20倍を超えたが、出来も別物だった。品質と費用のどちらを取るかを、モデル選びと同じくらいハーネスの設計が決めるようになった。

② プロンプトだけでは解決できない問題が増えた。 「ツールが多すぎて選び間違える」「コンテキストが詰まりすぎて重要情報が埋もれる」「長時間タスクで途中迷子になる」——こうした問題はプロンプト1ターンの工夫では対処不能。設計の問題だ。

③ エンジニアの仕事そのものが変わり始めた。 OpenAI の Codex チームは、手書きのコード0行で社内製品を5か月作り続け、約100万行・約1,500件のプルリクエストに達したと報告した（2026年2月11日）。そのうえで、エンジニアの主な仕事はコードを書くことから環境を設計し、意図を伝え、フィードバックの仕組みを作ることに移ったと書く。Claude Code・Codex・Cursor・Devin などの主要プロダクトも、モデルの外側の設計で差をつけ合っている。

5. 公開されている実例：3つのハーネス

ハーネスエンジニアリングは抽象論になりやすい。ここでは、作った本人が中身を公開している3つの例を、実際にやったことの粒度で並べる。

① OpenAI Codex チーム：AGENTS.md は「地図」、規則はリンターで強制

• AGENTS.md は約100行の目次にとどめ、設計・計画・品質の記録はリポジトリ内の docs/ に置いてそちらを正本にした。巨大な1ファイルは文脈を圧迫し、すぐ古くなり、機械的に検査もできなかったためだ。
• 文書が古びないよう、リンターと CI で相互リンクや構成を検査し、実際のコードと食い違う記述を探して修正の PR を出すエージェントを定期的に走らせた。
• 層構造と依存の向き、構造化ログ、ファイルサイズの上限などを独自のリンターと構造テストで強制した。エラーメッセージには直し方をそのまま書き、エージェントがそれを読んで自分で直せるようにした。

② Anthropic：長時間動くエージェントの「引き継ぎ」を設計

複数のコンテキストウィンドウにまたがる開発では、エージェントが一度に作りすぎる、途中で「完成」と言ってしまう、という失敗が起きた。Anthropic（2025年11月26日）はこう対処した。

• 最初のセッションだけ別のプロンプトで動く初期化エージェントが、機能の一覧（feature_list.json）、作業記録（claude-progress.txt）、開発サーバーを起動する init.sh、最初の git コミットを用意する。
• 2回目以降のセッションは、作業記録と git log を読んで状況をつかみ、1回に1機能だけ実装して、コミットと記録の更新で終える。
• 機能一覧は Markdown ではなく JSON にした。モデルが勝手に書き換えにくかったからで、変えてよいのは合否の欄（passes）だけ。
• 「完成」と記録するのは、ブラウザの自動操作で利用者と同じように端から端まで試してから。

③ Mitchell Hashimoto 氏：同じ失敗を二度させない

命名した本人のやり方はもっと小さい。エージェントが間違えたら、単純なものは AGENTS.md に1行足す。同氏のターミナル Ghostty では、このファイルの各行が過去の失敗に対応していて、それでほぼ解消したという。文章で足りないものは、スクリーンショットを撮る・対象を絞ってテストを走らせるといった実際に動くスクリプトを作って渡す。

3例に共通するのは、文章で頼むことより、検査して差し戻す仕組みに重心を置いている点だ。どこまで仕組みにするかは、次のチェックリストで確かめられる。

6. ハーネス設計の実践チェックリスト

7. 主要ハーネスの比較

各ハーネスは使う LLM はほぼ同じ（Claude / GPT / Gemini）でも、ハーネス側の設計思想で得意分野が大きく異なる。「どのLLM？」より「どのハーネス？」という選択軸が、エージェント時代の主戦場だ。

8. アンチパターン

① ツールを増やしすぎる

ツールが増えるほど、LLM は選び間違えやすくなる。Anthropic のドキュメントは、使えるツールが30〜50個を超えると Claude の選択精度が落ちると書き、必要なツールだけを都度読み込むツール検索を用意している。同社のツール設計の解説も、ツールは多ければよいわけではないとし、API をそのまま包んだだけのツールを並べず似た機能はまとめるよう勧めている。

② コンテキストに全部詰め込む

「念のため全部見せる」は逆効果。関連性フィルタを通して必要分だけ。コンテキストは「重要な信号を引き出す装置」であって「情報の保管庫」ではない。

③ 安全装置をプロンプトだけで実装

「危険な操作はしないでください」と書いても、状況によっては破られる。環境側で物理的に不可能にするのが正解（サンドボックス、Hooks、権限制限）。

④ 一度足した仕組みを見直さない

ハーネスは足すほど重く、遅く、高くなる。Anthropic は前出の実験のあと、部品を1つずつ外して結果を比べ、効いていたもの（計画役と検査役）だけを残した。同社は、ハーネスの部品はどれも「モデルが自力ではできないこと」についての仮定であり、モデルが良くなるとその仮定はすぐ古くなると指摘する。モデルを替えたら、足した検査や分割が今も効いているかを1つずつ確かめる。

まとめ

ハーネスエンジニアリングは 「LLMの外側」を設計する技術。プロンプトエンジニアリングはハーネスの中の1要素にすぎない。ツール定義・コンテキスト管理・記憶・ループ・ガードレール・出力UXの6要素を意識して設計することで、同じLLMでも実用性能が大きく変わる。

2026年現在、AIエージェント実用化の主戦場はハーネス側に移った。「賢いプロンプト」より「賢いハーネス」を作れることが、次世代エンジニアの差別化要因になる。

FAQ

Q1. プロンプトエンジニアリングはもう要らない？

違う。ハーネスの中の1要素として今も重要。ツール説明文、システムプロンプト、エラーメッセージなどはすべてプロンプト設計の対象。ただし「プロンプトだけで何とかする」発想は時代遅れ。

Q2. ハーネスエンジニアリングを学ぶ最初の一歩は？

Claude Code か Cursor を「ただ使う」のではなく「設定をいじって挙動を変える」こと。前出の Hashimoto 氏のやり方を手順にすると次のとおり。

1. エージェントの失敗を1件ずつ書き留める（どの指示で、何を間違えたか）。
2. 単純な失敗は CLAUDE.md / AGENTS.md / .cursor/rules に1行足す。
3. 繰り返す失敗や、起きると困る失敗は Hooks・リンター・テストで機械的に止める。エラー文には直し方を書く。
4. 同じ作業をもう一度させて、失敗が消えたかを確かめる。

Q3. ハーネスとフレームワーク（LangChain等）は同じ？

近いが違う。フレームワークは実装ツールキット、ハーネスは設計領域・思想。LangChain・LlamaIndex・Claude Agent SDK 等はハーネスを構築する道具。

Q4. 自分でハーネスを作る vs 既存品を使う？

多くの場合は 既存ハーネス（Claude Code・Cursor等）+ カスタマイズで十分。完全自作は、エンタープライズ要件・特殊ドメイン・極端なコスト最適化が必要な場合に限る。

Q5. 「ハーネスエンジニア」は職種として確立する？

まだ定まった職種名はない。命名した Hashimoto 氏自身も、業界で広く通じる呼び名があるかは分からないと書いている。ただ OpenAI の Codex チームは、エンジニアの主な仕事が環境の設計・意図の指定・フィードバックの仕組みづくりに移ったと報告しており、職種名より先に仕事の中身が変わり始めている。