ハーネスエンジニアリングとは？AI時代の開発生産性を高める考え方と実践手順を解説

人間がコードを1行も書かずに、AIエージェントだけでプロダクトを作る。少し前まで極端に聞こえたこの前提を、OpenAIは実際の開発事例として公開しました。同社は空のGitリポジトリから開発を始め、初期の構成、CI設定、AGENTS.md、アプリケーション実装までをエージェント主導で積み上げ、人間は主にプロンプト、環境設計、レビュー方針の設計に回ったと説明しています。※1

ただし、ここで重要なのは「人間がコードを書かなくなること」自体ではありません。問題は、コード生成の速度が上がるほど、人間のレビューとQAがボトルネックになりやすいことです。OpenAIは、コードスループットが上がるにつれて固定制約が human QA capacity に移ったと述べています。DORAも、AI導入の成否はツール単体ではなく、内部データ、ワークフロー、評価の仕組みといった組織能力に左右されると整理しています。※1 ※2

その設計思想を捉える言葉として、2025年後半からAIエージェント文脈で「harness」という表現が増え、2026年2月にOpenAIが「Harness engineering」を冠した記事を公開しました。この記事では、「Harness engineering」の概念を整理し、何を整えればAI活用が加速し、どこを放置すると混乱が増えるのかを解説します。※1 ※3

AIハーネスとは？言葉の由来から理解する

「ハーネス（harness）」とは、本来、馬の力を制御し伝達するための馬具一式（手綱や鞍など）を指す言葉です。これは単に馬を止めるための道具ではなく、馬の持つ強大な力を引き出し、乗り手の意図通りに動かすための仕組みと言えます。

AIエージェントの文脈で使われる「ハーネス」も、これと全く同じ発想に基づいています。AIモデルという「馬力」が暴走しないよう制御し、目的の成果に向けてその能力を安定して発揮させる。この基盤となる仕組みそのものが「AIハーネス」です。

つまり、ここで言うAIハーネスとはモデル単体を指すのではありません。入力の処理からツールの呼び出し、状態管理、評価、記録までを束ね、AIを「エージェント」として機能させるための土台を意味します。Anthropicもこれを「agent harness（または scaffold）」と呼び、モデル単体ではなく、ハーネスとモデルを組み合わせて初めてエージェントとして評価すべきだと述べています。※4

そして、次章で解説する「ハーネスエンジニアリング」とは、このAIハーネスを設計・構築していく実践的なアプローチを指しています。

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

ハーネスエンジニアリングとは、AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法です。

近年、エージェント主導の開発が主流になるにつれ、この概念の重要性が増しています。例えばOpenAIは、人間の主な役割が「コードを書くこと」から「AIが適切に動くための環境を設計し、意図を伝え、信頼できるフィードバックループを構築すること」へ移行していくと指摘しています。※1

なぜ今ハーネスエンジニアリングが必要なのか

AI導入が進み、個人の作業速度は上がっても、組織の制御系がそのままなら不安定性も増えることがわかってきたため、ハーネスエンジニアリングの必要性が増してきました。DORAは、AIの効果をツール単体の問題ではなく、内部データやドキュメントの品質、チームのワークフロー、評価の仕組みといった組織能力の問題として捉えています。「AIは増幅器である」とも言及し、整った組織では強みを伸ばし、弱い組織では弱点を速く拡大することを強調しています。※2 ※5

特に重要なのは、人間がレビューし続ける前提ではスケールしないという点です。OpenAIは、エージェント主導開発でコードスループットが上がるにつれて、ボトルネックが human QA capacity に移ったと述べています。Anthropicも、generator-evaluator ループはソフトウェア開発におけるコードレビューとQAに対応する構造だと説明しています。つまり、AIが生成を高速化しても、検証が人間に依存したままでは、全体最適になりません。※1 ※7

これは、単なる「レビューが大変」という話ではありません。AIが1日に生成する差分量が増えるほど、確認待ち、差し戻し、手戻り、仕様の見落としが累積しやすくなります。人間がすべてを最終判定する運用は、初期実験では回っても、運用規模が上がるほど詰まります。だから必要なのは、AIを止めることではなく、どこまでを機械的に落とし、どこだけを人間が見ればよいかを先に決めることです。ハーネスエンジニアリングは、そのための設計です。※1 ※4 ※7

また、社内の情報基盤が弱いままAIを入れても、生成量だけ増えてレビューと検証が詰まる可能性が高いという問題もあります。DORAは、内部データやドキュメントをAIが利用可能な状態にすることが、AI adoption の主要な推進要因だと明記しています。情報が弱ければ入力がぶれ、入力がぶれればレビュー負荷が増えます。レビューを減らしたいなら、まずレビュー前の段階でぶれない設計が必要です。※5

この傾向は、実際の調査データにも表れています。ファインディが2026年4月に実施した調査（国内エンジニア対象、n=157）では、AI活用による改善実感は工程によって大きな差が見られました。コーディング工程では87%が改善を実感している一方、実装後の品質検証では44%、リリース運用では41%にとどまっています。※11 AIによって「作る速度」は大きく伸びても、「検証し、安全にリリースする力」は同じペースで伸びていません。ハーネスエンジニアリングが取り組んでいるのは、まさにこの生成速度と検証速度の差から生まれるボトルネックです。

実際、ハーネスエンジニアリング自体への認識と実装の間にも、同じようなギャップが存在します。ファインディが実施した調査では、日常的にAI活用に取り組んでいる組織においても、ハーネスエンジニアリングを「重要だと思う」人が65.7%いる一方、「実際に本番運用まで進めている」人は40.0%にとどまり、その差は25.7ptに達します。これは、調査対象15項目のうち「認知負荷」に次いで2番目に大きい「重要度認識と導入実態のギャップ」です。※13

AI活用が進んだ組織でさえ、ハーネスエンジニアリングは「重要だとわかっていても、実装まで手が回っていない」テーマだと言えます。

3つの概念はどういうレイヤー関係で捉えるべきか

ここは用語の違いとして横並びで比較するより、スコープが段階的に広がっていくレイヤーとして捉えたほうが実務では分かりやすいです。本記事では、次のような整理を採用します。

プロンプトエンジニアリング：1回の推論で、どう指示を書くか
コンテキストエンジニアリング：その推論に、何の情報を入れるか
ハーネスエンジニアリング：複数回の推論とツール利用を含む作業全体を、どう運転するか

観点	プロンプトエンジニアリング	コンテキストエンジニアリング	ハーネスエンジニアリング
設計対象	1回の推論への指示の書き方	その推論に何の情報を入れるか	複数回の推論・ツール利用を含む作業全体の運転
主な問い	どう指示すれば良い出力が出るか	何を、どの順で、どれだけ見せるか	どう評価し、失敗時にどう戻し、次にどう引き継ぐか
スコープ	単発のやり取り	プロンプトより広い、推論単位の情報範囲	複数の推論・セッションにまたがる、継続する作業系全体
関係	contextの前段にあたる	harnessが扱う情報設計の一部を担う	プロンプト・コンテキストを含む、より広いスコープで作業全体を設計する

3つの概念

この整理で見ると、プロンプトエンジニアリングはコンテキストエンジニアリングの前段にあたり、コンテキストエンジニアリングはハーネスエンジニアリングが扱う情報設計の一部を担っています。Anthropicは、コンテキストエンジニアリングを prompt engineering の natural progression（自然な発展形）と説明しています。OpenAIも、大規模で複雑なタスクにエージェントを取り組ませるうえでの大きな課題の一つとして context management を挙げています。※1 ※9

このレイヤーで見ると、議論の混線が減ります。たとえば「プロンプトを工夫しているのに成果が安定しない」という状況では、問題は書き方ではなく、渡している情報か、評価ループか、引き継ぎ設計かもしれません。逆に、ハーネス設計の話をしているのに、指示文の巧拙だけで解決しようとすると、打ち手が小さすぎます。自分たちが今、どのレイヤーについて議論を行う必要があるのかを考えてみるのも有効な手かもしれません。※1 ※5 ※9

コンテキストエンジニアリングとの違い

混同しやすい概念として、コンテキストエンジニアリングがあります。Anthropicはこれを、LLMが推論するときに使う情報を適切に集め、絞り込み、維持するための設計だと説明しています。DORAも、最新のAPIドキュメント、社内ポリシー、準拠コードなどの関連情報を自動で集め、AIのワークフローに渡す仕組みとして説明しています。要するに、コンテキストエンジニアリングは「AIに何を見せるか」を設計する考え方です。※9 ※10

一方でハーネスエンジニアリングは、それより一段広い概念です。何を見せるかに加えて、どの順番で動かすか、途中結果をどう評価するか、失敗時にどうやり直すか、次のセッションへ何を引き継ぐかまで含めて設計します。コンテキストはハーネスの重要部品ですが、ハーネスそのものではありません。※1 ※7 ※9 ※10

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

最も内側のレイヤーにあるのが、プロンプトエンジニアリングです。ハーネスエンジニアリングはその延長線上にはありますが、同じものではありません。プロンプトエンジニアリングは、一回の指示でより良い出力を引き出す設計です。一方でハーネスエンジニアリングは、どの情報を見せるか、どの順番で動かすか、途中成果をどう検証するか、失敗時にどう戻すかまで含めて設計します。対象が「1回の応答」ではなく「継続する作業系」だという違いがあります。※1 ※4

OpenAIの事例はこの違いを分かりやすく示しています。同社は、AGENTS.md を巨大な手引き書にするのではなく、短い目次として保ち、詳細な知識は docs/ ディレクトリ側を正本として扱う方法を紹介しています。また、Anthropicも、長時間タスクで性能を伸ばした要因として、タスク分解、構造化された引き継ぎアーティファクト、planner・generator・evaluator の役割分担を挙げています。ここでいう3エージェント構成は、planner が作業計画を分解し、generator が実際の変更や生成を行い、evaluator が要件・テスト・品質基準に照らしてチェックする役割分担です。人間で言えば「段取りする人」「手を動かす人」「検品する人」を分けるイメージです。良い指示文を書くことより、良い作業系を作ることのほうが効くということです。※1 ※6 ※7

ハーネスエンジニアリングを構成する4つの要素

この章では、構成要素をOpenAIの「Harness engineering: leveraging Codex in an agent-first world」から整理します。現場向けに言い換えると、OpenAIが実際に整備していたのは「正しい情報にたどり着けること」「アプリやコードの状態をエージェント自身が読めること」「生成後に自走で検証と修正を回せること」「崩れたコードベースを継続的に掃除できること」の4点です。※1 ※6

1. リポジトリ知識を正本にする

OpenAIが最初に強調しているのは、知識の置き方です。同社は巨大な AGENTS.md 1枚にすべてを書き込む方法は失敗すると述べ、短い AGENTS.md を目次として使い、構造化された docs/ ディレクトリを system of record として扱っています。重要なのは、AIに大量の規則を丸呑みさせることではなく、「何が正本で、どこを見に行けばよいか」を迷わせないことです。※1 ※6

長すぎる指示書はコンテキストを圧迫し、何が重要か分からなくなり、しかもすぐ陳腐化します。逆に、短い入口から深い文書群へ案内する構造にすれば、エージェントは必要な情報だけを段階的に参照できます。ハーネスの第一要素は、指示の量ではなく、知識の配置設計です。※1 ※6

2. アプリケーションとリポジトリをエージェントにとって読める状態にする

次の要素は legibility、つまり「エージェントが自分で読める状態」を増やすことです。OpenAIは、コードスループットが上がるにつれてボトルネックが human QA capacity に移ったため、UI、ログ、メトリクスをCodexが直接読めるようにしたと説明しています。Chrome DevTools Protocol を接続し、スクリーンショットやDOMスナップショットを扱えるようにし、さらにログ・メトリクス・トレースもローカルの観測基盤経由で参照可能にしました。※1

OpenAIの記事は、エージェントから見えていないものは存在しないのと同じであると述べられています。Google Docs、チャット、口頭で済まされる会話に閉じたままの情報は、エージェントにとって不可視です。そのため、設計判断やプロダクト知識、運用ルールを、リポジトリ内で発見可能かつ、バージョン管理された形に押し戻していく必要があります。ハーネスの第二要素は、AIに賢くなってもらうことではなく、必要情報を見える場所に移すことです。※1

3. フィードバックループを実装し、生成から修正までを自走させる

OpenAIの記事では、人間の役割は「コードを書くこと」から「環境を設計し、意図を指定し、信頼できるフィードバックループを作ること」へ移ると説明されています。実際の運用でも、エンジニアはタスクを渡して終わりではなく、Codexに自己レビュー、追加レビュー、フィードバック反映、再実行をループさせ、Pull Request を完成に近づけています。※1

記事後半では、ハーネスに開発ループを埋め込んだ結果として、1つのプロンプトから現状確認、不具合再現、失敗動画の記録、修正、修正後の再検証、PR作成、レビュー応答、ビルド失敗の修復、必要時のみ人間へのエスカレーション、マージまで進められるようになったと書かれています。つまり、ハーネスの第三要素は「出力をもらう仕組み」ではなく、「検証とやり直しまで含めて作業を閉じる仕組み」です。※1

Planner・Generator・Evaluatorという3つの役割

このフィードバックループを機能させる鍵は、役割を3つに分離することです。

Planner（計画者）：作業をタスクに分解し、段取りを決める
Generator（実行者）：実際にコードや成果物を生成する
Evaluator（検証者）：要件・テスト・品質基準に照らして結果をチェックする

人間の組織で言えば、段取りする人・手を動かす人・検品する人を分けているのと同じ発想です。

Anthropicは、エージェントに自分の作業を評価させると、客観的には品質が低くても自信満々に高評価をつけてしまう傾向があると指摘しています。そのため、作業するエージェントと評価するエージェントを分けることが有効な打ち手だとしています。役割を分離すること自体が、ハーネスの検証精度を左右する設計判断になります。※7

4. アーキテクチャ原則を機械的に強制し、継続的に掃除する

最後の要素は、放置するとエージェント生成コードが崩れていく前提に立つことです。OpenAIは、完全自律に近づくほど、Codexは既存リポジトリ内の不均一なパターンや最適でない実装も増幅すると書いています。実際、当初は人間が毎週「AI slop（その場では動くが、徐々に荒れていくコードベース）」の掃除に時間を使っていたものの、それではスケールしなかったため、golden principles（機械的に判定できる明確なルール）をリポジトリに埋め込み、定期的なクリーンアップタスクを回す方式に切り替えています。※1

ここで重要なのは、原則を文章で掲げるだけではなく、機械的に守らせている点です。記事では、共有ユーティリティへの集約や、推測でデータ形状を扱わず境界で検証することなどを例に挙げ、バックグラウンドのCodexタスクが逸脱を検出して品質評価を更新し、リファクタ用のPRを自動で開くと述べています。ハーネスの第四要素は、生成時の制御だけではなく、生成後に蓄積するエントロピーを減らす運用まで含めて設計することです。※1

ハーネスエンジニアリングの進め方：3つのステップ

いきなり全体を整えようとすると負荷が高くやり切れません。そのため、段階を踏んで進めることをおすすめします。

STEP1. 入口となるAGENTS.mdを作る

まず、入口となる短いガイドを作ります。ここでのガイドは、AIにすべてを教える長文マニュアルではなく、何を見に行くべきか、どの順で確認すべきか、完了条件は何かを示すものです。

（※OpenAIの事例を参考にした例）

# AGENTS.md

## このファイルの役割
このファイルは、詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口です。

## このリポジトリで最初に確認するもの
- `ARCHITECTURE.md`
- `docs/product-specs/index.md`
- 必要に応じて `docs/FRONTEND.md`、`docs/SECURITY.md`、`docs/RELIABILITY.md`

## 作業ルール
- 振る舞いを推測で決めず、必ず対応する仕様書を確認する
- 変更した挙動に関わるドキュメントは更新する
- 実装後は build / test / lint を実行する
- より深いディレクトリに `AGENTS.md` がある場合は、その指示を優先する

## 完了条件
- 変更内容が仕様と矛盾していない
- 必要なテストと検証が終わっている
- ドキュメント更新が必要なら反映済み

# AGENTS.md

## このファイルの役割
このファイルは、詳細仕様をすべて書く場所ではなく、参照先と作業ルールを示す入口です。

## このリポジトリで最初に確認するもの
- `ARCHITECTURE.md`
- `docs/product-specs/index.md`
- 必要に応じて `docs/FRONTEND.md`、`docs/SECURITY.md`、`docs/RELIABILITY.md`

## 作業ルール
- 振る舞いを推測で決めず、必ず対応する仕様書を確認する
- 変更した挙動に関わるドキュメントは更新する
- 実装後は build / test / lint を実行する
- より深いディレクトリに `AGENTS.md` がある場合は、その指示を優先する

## 完了条件
- 変更内容が仕様と矛盾していない
- 必要なテストと検証が終わっている
- ドキュメント更新が必要なら反映済み

STEP2. ハーネス設計の土台となるリポジトリ構成を正本化する

OpenAIの記事では、AGENTS.md を詳細ルールの置き場ではなく入口の地図として扱い、構造化された docs/ ディレクトリを正本として運用しています。この役割分担は、AIが参照すべき情報を整理する設計の参考になります。 ※6

（※OpenAIの事例を参考にした例）

repo/

├── AGENTS.md
├── ARCHITECTURE.md
├── docs/
│   ├── design-docs/
│   │   ├── index.md
│   │   ├── core-beliefs.md
│   │   └── ...
│   ├── exec-plans/
│   │   ├── active/
│   │   ├── completed/
│   │   └── tech-debt-tracker.md
│   ├── generated/
│   │   └── db-schema.md
│   ├── product-specs/
│   │   ├── index.md
│   │   ├── new-user-onboarding.md
│   │   └── ...
│   ├── references/
│   │   ├── design-system-reference-llms.txt
│   │   ├── nixpacks-llms.txt
│   │   ├── uv-llms.txt
│   │   └── ...
│   ├── DESIGN.md
│   ├── FRONTEND.md
│   ├── PLANS.md
│   ├── PRODUCT_SENSE.md
│   ├── QUALITY_SCORE.md
│   ├── RELIABILITY.md
│   └── SECURITY.md

repo/

├── AGENTS.md
├── ARCHITECTURE.md
├── docs/
│   ├── design-docs/
│   │   ├── index.md
│   │   ├── core-beliefs.md
│   │   └── ...
│   ├── exec-plans/
│   │   ├── active/
│   │   ├── completed/
│   │   └── tech-debt-tracker.md
│   ├── generated/
│   │   └── db-schema.md
│   ├── product-specs/
│   │   ├── index.md
│   │   ├── new-user-onboarding.md
│   │   └── ...
│   ├── references/
│   │   ├── design-system-reference-llms.txt
│   │   ├── nixpacks-llms.txt
│   │   ├── uv-llms.txt
│   │   └── ...
│   ├── DESIGN.md
│   ├── FRONTEND.md
│   ├── PLANS.md
│   ├── PRODUCT_SENSE.md
│   ├── QUALITY_SCORE.md
│   ├── RELIABILITY.md
│   └── SECURITY.md

STEP3. フィードバックループと掃除ルールを運用に埋め込む

STEP1・STEP2で土台ができたら、最後にPlanner・Generator・Evaluatorのループを実際に回し、golden principles（機械的に判定できるルール）を使った定期クリーンアップを運用として組み込みます。

ここは一度作って終わりではなく、継続的に回し続ける工程です。前章で解説した4つの要素のうち、③フィードバックループと④アーキテクチャ原則の強制が、このステップにあたります。

よくある失敗

もっとも多い失敗は、AIの賢さを過大評価し、組織の未整備を過小評価することです。

ドキュメントが曖昧、レビュー基準が人依存、変更サイズが大きい、責任境界が曖昧なままAIを入れると、生成量だけ増えて下流が詰まります。これはAIの精度に対する問題ではなく構造の問題です。

「ツールを変えれば解決する」というのは誤解で、実際に変えるべきなのは開発プロセスや仕組みなどの構造です。※2 ※5

ハーネスエンジニアリングの限界と注意点

ハーネスエンジニアリングは有効な考え方ですが、万能ではありません。導入前に知っておきたい注意点もあります。

陳腐化が早い：モデルの進化速度が速く、今のベストプラクティスが数か月後には見直しを迫られる可能性があります。
初期整備にコストがかかる：docs/構造の整理やAGENTS.mdの設計は、最初は相応の人手と時間を要します。
定義・解釈にばらつきがある：「ハーネス」という言葉自体、論者によって指す範囲が異なります。導入時は社内で言葉の指す範囲をすり合わせておく必要があります。
実行コストが増える可能性がある：自己レビューや再実行を含むループを組むほど、API呼び出しや実行コストは増えます。運用前に費用対効果を試算しておくと安心です。
セキュリティ・ガバナンス面の検討も必要：プロンプトインジェクションなどのセキュリティリスクや、複数エージェントが同時に動く場合の競合、監査要件が厳しい業界での適用可否は、本記事では扱いきれていません。自社の状況に応じて個別に検討してください。
レガシーコードベースへの適用は難易度が上がる：本記事で紹介した進め方は比較的新しいコードベースを想定しています。既存の大規模かつ不均一なコードベースに後付けで適用する場合は、golden principlesの整備により時間がかかることを見込んでおく必要があります。

これらの点に気をつけながら、まずは小さく始め、検証しながら徐々に広げていくとよいでしょう。

ハーネスエンジニアリングは何のためにあるのか？「開発資本」の観点から

ここまで見てきたように、ハーネスエンジニアリングは重要性の認識が広がる一方で、実装は追いついていません。その背景には、組織のどこが遅れているのかを可視化できていないという課題があります。

ハーネスエンジニアリングそのものは目的ではなく、目指すべきは、AIを活用しながら組織として安定して価値を出し続けることです。そのためにはまず、自分たちの現在地を正しく把握する必要があります。

そこでファインディは、「AI時代に開発組織が本当に見るべき力」を 「開発資本」 と定義し、単一のスコアではなく、次の3つの観点で組織の状態を捉えるフレームワークとして整理しています。※12

Speed：速く作り、出し、学べるか（実装だけでなく、レビュー・CI・デプロイ・結果の観測まで含めた変更と学習サイクルの速さ）
Quality：コンスタントに価値を届けられるか（作り直しや差し戻し、障害、保守性の低下を抑えられているか）
Control：変更を予測し、制御できるか（変更の影響範囲、検証、承認、ロールバック、複雑性を組織として扱えているか）

先述の自社調査データを、この3つの観点で整理し直すと見え方が変わります。コーディング工程の改善実感が87%に達する一方、実装後の品質検証は44%、リリース運用は41%にとどまっていました。※11 これは、Speed（作る速さ）は伸びている一方で、Quality・Controlがそのペースに追いついていない状態と捉えられます。

ここまで本記事で解説してきた内容は、この3つの観点すべてに対応しています。STEP1で整えた入口のガイドや、エージェントがアプリやログを直接確認できる状態にする取り組みはSpeedを、「生成後の検証を自走させる仕組み」や「アーキテクチャ原則を機械的に強制し、継続的に掃除する仕組み」はQuality・Controlを、それぞれ底上げする具体的な手段です。

ハーネスを設計する際は、今、自分たちがSpeed・Quality・Controlのどこを強化しようとしているのかを意識しておくと、設計の優先順位がぶれにくくなります。

開発資本の詳細な考え方は、以下のページで解説しています。

AI時代の開発資本「Engineering Capital」とは

まとめ

ハーネスエンジニアリングは、AIにうまく指示する技術ではありません。AIが継続的に成果を出せるように、開発組織そのものを再設計する技術です。OpenAI、Anthropic、DORAの示唆を合わせて見ると、AIを活用するうえで本当に重要なのは、モデルの性能そのものより、AIが迷わず進めて、途中でミスを検知でき、ミスを修正できる仕事の仕組みを作ることです。※1 ※5 ※7

ハーネスエンジニアリングは、AIエージェントが安定して働ける環境・文脈・評価系を設計する実務です。
「harness」は、モデル単体ではなく、ツール・状態管理・評価を含むエージェントの足場を指します。
AIは組織の強みを伸ばす一方、弱いワークフローや曖昧な運用も増幅します。
生成速度だけを上げても、人間のレビューとQAがボトルネックのままではスケールしません。
プロンプト、コンテキスト、ハーネスは横並びではなく、扱うスコープが段階的に広がっていく関係として捉えると打ち手を整理しやすくなります。
内部ドキュメントの品質、small batches、評価ループ、利用ルールの整備が中核になります。
ハーネスエンジニアリングは、開発資本のQuality・Controlを強化する実践的な手段の一つになります。

ハーネスエンジニアリングに関心のある方にオススメの記事はこちら

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

プロンプトエンジニアリングは、LLMへの入力テキストを体系的に設計・最適化することで、期待する出力の品質を高める実践的手法です。Zero-shot・Few-shot・CoT・Role Prompting・深津式といった主要手法の使い分けから、プロンプトをコードと同様に管理するチーム導入の進め方まで解説します。

コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いから実践方法まで徹底解説

コンテキストエンジニアリングとは、LLMのコンテキストウィンドウに何を・どの順番で・どれだけ渡すかを設計・最適化するエンジニアリング手法です。CLAUDE.mdやMCPを使った実践的なコンテキスト設計から、AIコーディングエージェントが陥りやすいコンテキストの腐敗（Context Rot）の対策まで解説します。

仕様駆動開発（SDD）とは？TDD・ウォーターフォール開発との差分からSpec Kit・Kiroを使った実践まで解説

仕様駆動開発（SDD）は、コードを書く前に仕様を明文化し、その仕様を基準に設計・実装・検証を進めるアプローチです。AIコーディングエージェントが普及した今、仕様の曖昧さによる手戻りを構造的に減らす手法として注目されており、GitHub Spec KitやKiroを使った実践方法まで解説します。

FAQ：ハーネスエンジニアリングについてよくある質問

AIハーネスとは何ですか？

AIエージェントが暴走せず、狙った成果に向けて安定して動作できるようにする仕組みそのものを指します。入力の処理、ツールの呼び出し、状態管理、評価、記録までを束ねて、AIを「エージェント」として機能させるための土台です。

ハーネスエンジニアリングとは何ですか？

AIエージェントが継続的に正しい仕事を進められるように、環境・文脈・評価・フィードバックループを人間が設計する手法です。ここでいう「ハーネス」は、モデル単体ではなく、入力・ツール呼び出し・状態管理・評価・記録を束ねてエージェントとして機能させる土台を指します。AIにうまく指示する技術ではなく、AIが継続的に成果を出せるように開発組織そのものを再設計する技術です。

なぜ今ハーネスエンジニアリングが必要なのですか？

AIで生成が高速化すると、人間のレビューやQAがボトルネックになりやすいためです。そのため、どこまでを機械的に処理し、どこだけを人間が見ればよいかを先に決めることが必要であり、ハーネスエンジニアリングはそのための設計です。

コンテキストエンジニアリングとの違いは何ですか？

コンテキストエンジニアリングとの違いは扱う設計の対象範囲にあります。プロンプトエンジニアリングは「1回の推論でどう指示を書くか」、コンテキストエンジニアリングは「その推論に何の情報を入れるか」、ハーネスエンジニアリングは「複数回の推論とツール利用を含む作業全体をどう運転するか」を扱います。

ハーネスエンジニアリングを構成する要素は何ですか？

4つの要素で構成されます。1つ目は、リポジトリ知識を正本（正式な参照元）にすること。2つ目はアプリケーションとリポジトリをエージェントが読める状態にすること。3つ目はフィードバックループを実装して生成から修正まで自走させること。4つ目はアーキテクチャ原則を機械的に強制し継続的に掃除することです。

「ハーネス」という言葉の由来は何ですか？

もともとは馬に装着する馬具（手綱・鞍・引き具一式）を指す言葉です。馬の力を止めるのではなく、狙った方向に引き出し制御するための道具であることから、AIエージェントの制御・運転設計を指す比喩として使われています。

ハーネスエンジニアリングとAIハーネスは同じ意味ですか？

「AIハーネス」は、AIエージェントを機能させる土台そのもの（仕組み）を指します。一方「ハーネスエンジニアリング」は、その土台を設計・整備していく実践を指します。扱っている対象は同じです。

ハーネスエンジニアリングに向いていないケースはありますか？

小規模でAI活用範囲が限定的な場合や、ドキュメント整備に割ける工数が全くない場合は、初期整備コストが見合わないことがあります。まずは小さく始め、効果を見ながら範囲を広げる進め方が現実的です。

ハーネスエンジニアリングは何から始めればいいですか？

まずは短いAGENTS.mdを用意し、リポジトリのどこを見ればよいかという「入口」を作ることから始めます。その後、docs/配下の正本化、フィードバックループの実装へと段階的に広げます。

小規模なチームでも導入する価値はありますか？

はい、AIエージェントを使って開発している時点でチームの人数そのものは制約になりません。重要なのは人数ではなく、ドキュメント整備に多少の工数を割けるかどうかです。まずは短いAGENTS.mdを1つ作るところから始めれば、小規模チームでも十分に着手できます。

参考・出典

※1 OpenAI「Harness engineering: leveraging Codex in an agent-first world」, 2026
https://openai.com/index/harness-engineering/
※2 DORA「Balancing AI tensions: Moving from AI adoption to effective SDLC use」, 2026
https://dora.dev/insights/balancing-ai-tensions/
※3 Anthropic「Effective harnesses for long-running agents」, 2025
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
※4 Anthropic「Demystifying evals for AI agents」, 2026
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
※5 DORA「Capabilities: AI-accessible internal data」, 2026
https://dora.dev/capabilities/ai-accessible-internal-data/
※6 OpenAI「Harness engineering: leveraging Codex in an agent-first world」内 AGENTS.md / docs/ の記述, 2026
https://openai.com/index/harness-engineering/
※7 Anthropic「Harness design for long-running application development」, 2026
https://www.anthropic.com/engineering/harness-design-long-running-apps
※8 DORA「Helping developers adopt generative AI: Four practical strategies for organizations」, 2025
https://dora.dev/insights/adopt-gen-ai/
※9 Anthropic「Effective context engineering for AI agents」, 2025
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
※10 DORA「Capabilities: AI-accessible internal data」内 Context engineering の説明, 2026
https://dora.dev/capabilities/ai-accessible-internal-data/
※11 ファインディ「エンジニア調査レポート・2026年4月版:企業のAI駆動開発の現状と、エンジニア採用市場の変化」(n=157), 2026
https://findy-code.io/job-market-trends/20260422
※12 Findy Team+「AI時代の開発資本 Engineering Capital」, 2026
https://jp.findy-team.io/engineering-capital/
※13 ファインディ株式会社「開発組織トレンド調査2026 −市場調査・ユーザー調査比較編−」(市場調査n=873、2026年4月24〜25日実施/Findy Team+導入企業ユーザー調査n=175、2026年5月14〜19日実施), 2026
https://jp.findy-team.io/download/ai-utilization-survey-2026_report_market_vs_user_research/