AIにお願いしたのに、なぜか同じミスを繰り返す。プロンプトをどれだけ工夫しても、出力がバラバラで安定しない。AIコーディングツールを使っているのに、むしろ後始末に時間がかかる。こんな経験をしたことはありませんか。
実はこの問題、AIそのものの能力が足りないのではなく、AIが動く環境の設計が不十分なことが原因である場合がほとんどです。そこで2026年に注目を集めているのが、ハーネスエンジニアリングという考え方です。
ハーネスエンジニアリングとは何か
ハーネスエンジニアリングとは、AIエージェントが正しく・安定して・再現性高く動けるように、人間が環境を設計・整備する手法のことです。
ここで登場するハーネス(harness)という言葉、もともとは馬具を意味します。馬の背中に装着して、騎手が意図した方向へ馬の力を正しく導くための道具です。どんなに優秀な馬でも、手綱や鞍がなければ好き勝手に走ってしまいます。馬具があるからこそ、馬は全力で正しい方向へ走れるのです。
この考え方をAIに当てはめると、モデル(馬)がいくら賢くても、それを正しく動かすための仕組み(馬具)がなければ期待通りの成果は得られません。ハーネスエンジニアリングとは、この馬具にあたる部分を意図的に設計することです。
ハーネスエンジニアリングの起源:
2026年2月5日、HashiCorpの共同創業者であるMitchell Hashimoto氏が自身のブログで、AIエージェントとの作業経験をもとにハーネスエンジニアリングという言葉を使い始めました。Hashimoto氏はシンプルにこう定義しています。エージェントがミスをするたびに、そのミスが二度と起きないような仕組みを設計すること。その6日後、OpenAIが社内実験に関する記事を公開し、この言葉が一気に広まりました。
なお、ハーネスエンジニアリングには大きく2種類の使われ方があります。一つはAIエージェントを作る側が考える内部設計の話、もう一つはAIエージェントを使う側が整える外部環境の話です。本記事では、多くの方が関心を持つ使う側の視点、つまり開発チームや組織がAIエージェントを活用するために整える環境設計を中心に解説します。
なぜ今、ハーネスエンジニアリングが必要なのか
プロンプトだけでは限界が来た
AIの活用方法は、短期間で大きく進化してきました。最初はプロンプトエンジニアリングと呼ばれるどう指示するかの時代でした。適切な言葉でAIに命令すれば、精度の高い回答が返ってくる。この段階では、指示の巧みさが勝負でした。
次に登場したのがコンテキストエンジニアリングです。何を見せるか、つまりAIに渡す情報をどう選び、どう構造化するかが重要になりました。プロジェクトの背景情報や過去のやり取りをうまく組み込むことで、AIの精度が大きく向上することがわかってきたのです。
そして今、その先にある段階がハーネスエンジニアリングです。AIエージェントが複雑なタスクを長時間にわたって自律的にこなすようになると、一回の指示や情報の渡し方だけでは対応しきれない問題が次々と出てきます。
| 段階 | 中心となる問い | 限界 |
|---|---|---|
| プロンプトエンジニアリング | どう指示するか | 同じ失敗が繰り返される |
| コンテキストエンジニアリング | 何を見せるか | 大規模タスクで統一感が崩れる |
| ハーネスエンジニアリング | どんな環境で動かすか | 継続的な改善が必要 |
AIは環境の鏡である
重要な事実として、AIは使う組織の状態を増幅します。開発基盤がしっかり整っている組織では、AIを導入することで強みがさらに大きくなります。一方、ドキュメントが整っていない、ルールが曖昧、暗黙知が多い組織では、AIを使うことでその問題が速く広まるだけです。
2025年のDORAレポート(Googleが発表する開発組織の分析レポート)でも、AIは主に増幅器であると結論づけられています。AIそのものに問題があるのではなく、その周囲の環境が成果を決めているのです。
ハーネスの3つの基本要素
各社の実践事例を分析すると、ハーネスエンジニアリングには共通して3つの重要な要素が登場します。
1. ルールファイル(エージェントへの指示書)
AIエージェントにこのプロジェクトではこうしてほしいと伝えるためのファイルです。Claude Codeを使う場合はCLAUDE.md、OpenAIのCodexではAGENTS.mdなどがこれにあたります。
ただし、重要なポイントがあります。このファイルは百科事典ではなく、目次として使うべきです。ルールを詰め込みすぎると、AIが本当に必要な情報にたどり着けなくなります。OpenAIのチームは約100行に絞り、詳細情報はリポジトリ内に構造化して配置するという方針を採用しました。
2. フィードバックループ(自動的な評価の仕組み)
AIが出力したコードや成果物が正しいかどうかを自動的に判定する仕組みです。テスト(AIはテストが通るコードを目指して自律的に改善を繰り返す)やリンター(コーディング規約の自動チェック)がこれにあたります。
テストがないプロジェクトでは、AIには正解かどうかを判断する手段がありません。フィードバックループが充実しているほど、AIは自律的に品質を高めることができます。
3. コンテキスト管理(情報の整理と受け渡し)
AIエージェントは一度に処理できる情報量(コンテキストウィンドウ)に上限があります。長いタスクでは、途中で以前の作業内容を忘れてしまうことがあります。この問題に対処するのがコンテキスト管理です。
鍵となる原則は、エージェントが認識できるのは、リポジトリ(保管場所)にある情報だけという点です。チャットのやり取り、口頭の指示、担当者の頭の中にある知識、これらはAIには見えません。必要な情報はすべてファイルとして記録・整理しておく必要があります。
料理で理解するハーネスエンジニアリング:
腕の良いシェフ(AIモデル)でも、レシピ(ルールファイル)がなければ何を作ればいいかわかりません。味見(フィードバックループ)をしなければ味が整っているか確認できません。仕込みメモ(コンテキスト管理)がなければ、昨日どこまで準備したか忘れてしまいます。ハーネスとは、シェフが最高の料理を出すための厨房の仕組みそのものです。
OpenAIが証明した驚異の実例
ハーネスエンジニアリングが実際にどれほどの効果をもたらすのか。OpenAIが2026年2月に公開した事例は、業界に大きな衝撃を与えました。
2025年8月から約5か月間、OpenAIの3人のエンジニアが人間はコードを一行も書かないという縛りでソフトウェアを開発しました。すべてのコード(アプリケーションのロジック、テスト、ビルド設定、ドキュメント、社内ツール)はAIエージェントのCodexが生成しました。
| 指標 | 結果 |
|---|---|
| 開発期間 | 約5か月 |
| コード量 | 約100万行 |
| プルリクエスト数 | 約1,500件 |
| エンジニア1人あたりの処理速度 | 1日平均3.5件(手動開発比・約10倍) |
完成したプロダクトは社内の何百人ものユーザーが日常的に使う実用的なシステムとして稼働しています。手動での開発と比較して、約10分の1の時間で完成したと報告されています。
ただし、最初から順調だったわけではありません。初期段階では作業環境の準備不足、ツール連携の弱さ、エラー対処手順の不備により、生産性は低いままでした。ハーネスを段階的に改善することで、ようやく高い成果が出せるようになったのです。チームのエンジニアたちは、何かが失敗したときもっと頑張れとは言いませんでした。代わりにエージェントにどんな仕組みが足りなかったのかを問い続けました。
Human steer, Agents execute:
OpenAIの実験を貫くコンセプトは人間が舵を取り、エージェントが実行するというものです。エンジニアの仕事は、コードを書くことではありません。タスクの優先順位を決め、ユーザーの声を仕様に変換し、AIが苦戦したときに何が足りなかったかを特定して環境を改善することです。この役割分担が、圧倒的な生産性の鍵でした。
エンジニアの仕事はどう変わるか
ハーネスエンジニアリングの登場は、ソフトウェアエンジニアリングの仕事の本質を変えつつあります。
従来はコードを書くことが中心でした。これからはAIが良いコードを書ける環境を設計することが主要な仕事になっていきます。具体的には、次のような変化が起きています。
| これまで | これから |
|---|---|
| コードを書く | 環境・仕組みを設計する |
| なぜを頭の中に持つ | なぜをファイルに書き出す |
| 失敗したら直す | 失敗が再発しない仕組みを作る |
| 個人の注意力に頼る | 仕組みとして自動的に担保する |
これは必ずしもエンジニアが不要になるという話ではありません。むしろ逆です。AIに任せられる部分が増えるほど、人間の判断・設計・意図の言語化といった仕事の価値が高まります。
また、ハーネスエンジニアリングの考え方はソフトウェア開発に限りません。社内でAIを活用した業務効率化を進める場合にも同じ発想が使えます。良いプロンプトを書くだけでなく、適切な社内資料や過去の文書(コンテキスト)を整備し、AIの出力をチェックする仕組みや、ミスが起きたときの再発防止策(ハーネス)まで設計する。この環境づくりこそが、AIから安定した成果を引き出す鍵になっていくのです。
ハーネスエンジニアリングで注意すべき落とし穴
ここまで読んでさっそく始めようと思った方に、よくある失敗もお伝えしておきます。
まず、最初から作り込みすぎることはよくある失敗です。複雑なルールや仕組みを一気に設定すると、モデルの更新や運用の変化があった瞬間に壊れてしまいます。小さく始めて、実際の失敗から学びながら少しずつ改善するのが正しいアプローチです。
次に、ルールを書いて終わりにすることも危険です。設定したルールや指示書は、放置するとすぐに実態と離れていきます。定期的な見直しと更新が欠かせません。
そして、フィードバックループを人間に依存させすぎることも問題です。AIがコードを速く生成できるようになるほど、人間のレビューがボトルネックになります。自動テストやリンターなど、機械的に判定できることはできるだけ自動化することが重要です。
ハーネスエンジニアリングの限界も知っておこう:
ハーネスはAIエージェントの出力の方向を制御しますが、エージェント自体ができないことを可能にするわけではありません。複雑な設計判断や、深いドメイン知識が必要な意思決定は、依然として人間の役割です。AIを信頼しすぎず、重要な判断は人間が担う設計を忘れないようにしましょう。
AIの時代に求められる新しい設計力
ハーネスエンジニアリングを一言で表すなら、AIに仕事をさせるための環境設計です。プロンプトを磨くことや、渡す情報を工夫することも大切ですが、それだけでは追いつかない時代になってきました。
OpenAIの実験が示したように、AIの成果を決めるのはモデルの賢さではなく、環境の良さです。Agent = Model + Harness、つまりAIエージェントの実力は、モデルの能力にハーネス(環境)の質を掛け合わせたものだという考え方が、世界の先進企業の間で広まっています。
まず始めるなら、AIへの指示書を50行程度でシンプルに書き、リンターを設定し、自動テストを整備する。この3つだけでも、AIの出力品質は目に見えて変わると言われています。
コードを書くエンジニアからAIが動く環境を設計するエンジニアへ。この変化は脅威ではなく、より高い次元での創造性を発揮できるチャンスです。ハーネスエンジニアリングという新しい設計力を身につけることが、AI時代を生き抜く大きな武器になるでしょう。


コメント