ハーネスエンジニアリング ― AIエージェントが自律的に動ける開発環境の設計

3人のエンジニアが、5ヶ月で約100万行のコードをリリースした¹。
コードベースの90%が、AI自身によって書かれている²。
週に1,000以上のPRがマージされ、そのすべてが人間の手書きコードゼロ³。

OpenAI、Anthropic、Stripe。
先進企業から届くこの数字は、もう特殊事例とは言い切れません。

私たちのチームでも、コードを書くのはほとんどAIです。
個人の生産性は確かに上がりました。しかし2025年のDORAレポート（約5,000人調査）は、組織全体では違う傾向を示していました⁴。

マージされたPR数は+98%。しかし、コードレビュー時間は+91%増加し、PRサイズは+154%肥大化。
個人が速くなっても、組織全体のデリバリーパフォーマンスは期待ほど改善していません。

コードを書く速度はもう十分です。
ボトルネックは、その先にあるレビュー・統合・デプロイに移っています。

そして先進企業は、この問題に対して「もっと速く書く」ではない答えを出していました。
エージェントが正しく動ける環境そのものを設計する という答えです。

これを「ハーネスエンジニアリング」と呼びます。

本記事では、ハーネスエンジニアリングとは何か、先進企業はどう実践しているのか、
そして私たちエンジニアに求められるマインドシフトについて整理します。

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

エンジニアの仕事は「コードを書くこと」から「エージェントが正しく動ける環境を作ること」に変わりつつあります。
この新しい仕事を指す言葉が、ハーネスエンジニアリングです。

「ハーネス」は馬具に由来する言葉で、強い力を正しい方向に導く仕組みを指します。ソフトウェア開発では、AIエージェントの出力を意図した方向に制御する環境設計を意味します。

この概念には、2つの定義があります。

HashiCorpの共同創業者であるMitchell Hashimoto氏は、ハーネスエンジニアリングを 「エージェントのミスを検出・防止するフィードバックループ」 と定義しました⁵。
エージェントが失敗したとき、その原因を分析し、次は失敗しないよう環境を改善する。この繰り返しが本質だという考え方です。

一方、OpenAIは 「エージェントが最初から正しく動ける環境全体の設計」 と定義しています¹。
失敗の修正だけでなく、そもそも失敗しにくい環境をどう構築するか。より広い視点での定義です。

どちらも共通しているのは、エンジニアの注力先が「コードそのもの」から「コードが生まれる環境」に移っているということです。

こう聞くと、「それはリンターやCIと同じでは？」と思うかもしれません。実際、その通りです。lefthookでコミット前にチェックを走らせる、リントのエラーメッセージを丁寧に書く、CIで品質を自動検証する。多くのエンジニアはすでにハーネスの一部を実装しています。

ハーネスエンジニアリングが加えるのは、これらの仕組みを「エージェントが使用する前提」で再設計するという視点です。リンターのエラーメッセージに修復手順を埋め込む。AGENTS.mdでリポジトリの構造や設計方針を言語化する。CIの失敗ログをエージェントが自力で解釈して修正できるように整える。今ある仕組みの延長線上にありながら、フィードバックの受け手を人間からエージェントに広げていく。それが実態です。

	従来の開発	ハーネスエンジニアリング
中心作業	コードを書く	環境を設計する
バグ対応	直接修正する	「なぜエージェントが失敗したか」を分析して環境を改善する
レビュー	人間がすべて読む	Howはエージェントに任せ、人間はWhy/Whatに集中する

ここからは、先進企業がこの考え方をどう実践しているかを掘り下げます。

先進企業の実践

OpenAI、Anthropic、Stripe。規模もプロダクトも異なる3社ですが、実践には共通パターンがあります。企業ごとではなく、テーマ別の横串で整理します。

エンジニアの役割の変化

AIにコードを書かせること自体は、もう多くのチームが実践しています。先進企業のエンジニアが異なるのは、その過程にほとんど介入していないことです。

OpenAIでは、3名のエンジニアが「手書きコード一切禁止」の制約でCodexだけで社内向け製品を構築しました¹。エンジニアの仕事は、タスクの優先順位付け、ユーザーフィードバックの受け入れ基準への変換、成果の検証、そしてエージェントが苦戦したときに「何が足りなかったか」を特定して環境にフィードバックすることです。

Anthropicでは、Claude Codeの開発責任者であるBoris Cherny氏が「2ヶ月以上、小さな編集すら手でしない」と公言しています⁶。ローカル5セッション + Web 5〜10セッションを同時に走らせ、Planモードで計画を練り、固まったらAuto-acceptモードに切り替えて放置する⁷。10〜20%のセッションが中止されますが、並行実行しているから全体としては問題にならないという割り切りです。

Stripeでは、Slackで5つのタスクをMinions（社内エージェント）に投げて、コーヒーを取りに行き、戻ると5つのPRが出来上がっている³。エンジニアはPRをレビューし、3つ承認、1つにフィードバック、1つを破棄します。手動なら2つ処理する時間で、5つの問題が片付きます。

共通しているのは、人間の時間を 「How（どう書くか）」ではなく「Why/What（なぜ・何を作るか）」と「環境の改善」に使っている ことです。

エージェントへのコンテキスト提供

エージェントに正しく動いてもらうには、エージェントが「知っている」状態を作る必要があります。

OpenAIはこれを端的に表現しています。

Codexが見えないものは存在しない¹

Slackの会話、Google Docs、人の頭の中の知識。これらはエージェントにとって存在しません。
チームの意思決定やアーキテクチャの合意は、リポジトリ内のMarkdownにエンコードしなければ活用されません。
これは新メンバーのオンボーディングと同じ発想です。

具体的な実践として、OpenAIはAGENTS.mdを約100行の目次にとどめ、詳細は構造化されたdocs/ディレクトリに段階的に配置する方式を採用しています⁸。巨大な1ファイルにすべてを書く方法は失敗した、と明言しています。コンテキストは希少資源であり、すべてが「重要」だと何も重要でなくなるからです。

Anthropicも同様に、CLAUDE.mdを約2,500トークンのコントロールパネルとして設計しています⁷。エラー事例、ベストプラクティス、スタイル規約、設計ガイドラインを凝縮して記録し、PRで @claude にメンションして、学びを追加していく運用です。

方法は違いますが、エージェント向けのドキュメントをエントリポイントと詳細に分離し、構造化して配置している点は共通しています。

レビュー負荷への対処

DORAのデータが示すように、AIでコードを速く書けるようになった分、レビュー・検証の負荷が劇的に増えています。
このレビュー負荷にどう対処するかが、組織のデリバリー速度を左右します。

各社のアプローチは異なりますが、方向性は一致しています。人間がすべてのコードを読むのをやめることです。

OpenAIでは、エージェントが自分のPRを自分でレビューし、満足するまで修正を繰り返します¹。社内では「Ralph Wiggumループ」（失敗しても決して立ち止まらないシンプソンズのキャラクターに由来）と呼ばれているそうです。すべてのエージェントレビュアーが満足してから、人間に渡します。人間がPRをレビューする場合もありますが、必須ではありません。

Anthropicでは、複数のサブエージェントを同時に起動し、スタイル・履歴・バグを並列にチェック。さらに別のサブエージェント群で最初の発見を検証します⁷。このフィードバックループにより、最終結果の質は2〜3倍向上するといいます。

Stripeは、ローカルリント（5秒以下）→ CI実行（300万以上のテストスイート）→ 失敗したらログを読んで自動修正 → 1回だけ再実行 → 2回目も失敗したら人間に返却、という厳格なフローを組んでいます⁹。無駄なCI実行を防ぎ、人間が介入するのは本当に必要な場面だけです。

エージェント導入とレビュー対策はセットで考える必要があります。 先にレビュー自動化の仕組みを用意しないと、「たくさん書けるがリリースできない」状態に陥ります。

なお、「人間がすべてのコードを読むのをやめる」は、人間がレビューしないという意味ではありません。実際、Stripe³もAnthropic²も人間によるレビューは必須としています。完全にレビューを廃止している企業が少ないのは、「意図通りのものが出来ているか」というWhy/Whatの答え合わせには人間の判断が欠かせないからでしょう。Howのチェックはエージェントと自動ゲートに任せ、人間はWhy/Whatに集中する。それがレビュー負荷を下げながら品質を保つ現実的な落としどころです。

制御の仕組み

エージェントに自由にやらせると、うまくいきません。
先進企業が共通して取り組んでいるのは、エージェントの行動を「お願い」ではなく「強制」で制御することです。

Stripeの「Blueprints」パターンが象徴的です⁹。エージェントのステップと決定論的ステップを交互に配置し、リンター実行やGitコミットなど、エージェントがスキップできない固定ゲートを挟み込みます。

モデルがシステムを動かすのではない。システムがモデルを動かす⁹

多くのAIコーディングエージェントは純粋にエージェント的で、LLMがリンターを忘れたら実行されません。Stripeはこれを「忘れようがない」仕組みにしています。

OpenAIも同じ発想で、カスタムリンターのエラーメッセージに修復手順を埋め込んでいます⁸。エージェントがルール違反をしたとき、何が間違っていて、どう直せばいいかがエラーメッセージ自体に書いてあります。エージェントが自力で修正できる設計です。

AGENTS.mdやCLAUDE.mdに「〜してください」と書くだけでは、エージェントはそれを無視することがあります。
リンター、CI、決定論的ゲートといった仕組みで 逃げ道をなくす のがベストプラクティスです。

失敗を前提とした設計

先進企業に共通するもうひとつの特徴は、エージェントの出力に100%の完成度を求めていないことです。

AnthropicのCherny氏は、10〜20%のセッションが予期しないシナリオで中止されることを織り込み済みだと述べています⁷。並行実行しているからこそ、一部が失敗しても全体としては問題になりません。

Stripeも同じ思想です。

完全に正しくないPRでも、エンジニアが20分で磨けるなら十分な勝利³

エージェントに100%を求めるのではなく、80%まで自律的に完成させてから人間が引き継ぎます。
この割り切りが、大規模な並列運用を可能にしています。

逆に言えば、エージェントに完璧を求めて1つのセッションに張り付いている限り、この恩恵は得られません。「任せて、結果を検証する」という姿勢が前提になります。

私たちに必要なマインドシフト

先進事例のエンジニアは、意図を渡して複数のセッションを放置し、結果だけを検証しています。一方で、多くのチームではまだ、AIに細かく指示しながら1つのセッションを見守るスタイルが中心ではないでしょうか。

張り付く必要がある理由は、エージェントが自律的に正しく動く保証がないからです。つまりハーネスの問題に帰着します。

重要なのは、具体的な施策の前に意識の向きを変えることです。

エージェントが失敗したとき、その場の指示で訂正して終わりにするか、「なぜ失敗したか」を環境にフィードバックするか。

この分岐点が、ハーネスエンジニアリングの出発点です。

AIへの追加指示で訂正すれば、その場は解決します。
しかし、その訂正をAGENTS.mdやルールファイルに反映しなければ、次のセッションでも、別のメンバーのセッションでも、同じ失敗は繰り返されます。
先進企業が実践しているのは、まさにこの「その場の訂正」を「環境の改善」に変換するサイクルです。

ただし、このサイクルを回すにはコードや設計への理解が前提です。Findyの自社実験では、シニア層が3〜5割の生産性向上を達成した一方で、若手層は2〜3割低下しました¹⁰。指示が曖昧なままエージェントに任せると、手戻りがかえって増えるためです。AIは力を増幅しますが、力そのものを作り出すわけではありません。

そしてハーネスは固定されたものではありません。Anthropicは新しいモデルがリリースされるたびに不要になったコードを削除しています²。モデルの進化に合わせて定期的に見直していく活動です。

まとめ

コードを書く力は、もう十分に手に入りました。
次の課題は、その力をどう制御し、正しくリリースまで届けるかです。

ハーネスエンジニアリングとは、エージェントが正しく動ける環境を設計・構築することです。
先進企業の実践からは、いくつかの共通パターンが見えてきました。

エンジニアの仕事は「コードを書く」から「なぜ・何を作るかの言語化」と「環境の設計」へ移っている
エージェントに必要なコンテキストはリポジトリにエンコードしなければ存在しない
レビュー自動化とエージェント導入はセットで考える必要がある
制御は「お願い」ではなく「強制」に近づけるほど効く
100%の成功を前提にせず、80%で引き継ぐ設計が大規模運用を可能にする

そして、AIは増幅装置です。
良い開発基盤を持つ組織はその強みを拡大でき、そうでない組織は問題を加速させるだけです。

最初の一歩は、エージェントの失敗を「個人の対処」ではなく「環境の改善」に変換するマインドシフトです。
一つひとつは小さな改善でも、その積み重ねがハーネスを形作っていきます。