AI時代に欠かせないハーネスエンジニアリングとは
AIコーディングエージェントを使ったことがある人なら、似たような場面を一度は経験しているはずです。
最初は賢そうに見えるのに、少し作業が長くなると文脈を見失い、関係のないファイルを触り、テストもせずに「終わりました」と言ってしまうんです。
多くのチームはここでモデル性能だけを責めます。ですが最近のいくつもの文章が共通して語っているのは、少し違う話です。問題はモデルだけでなく、モデルが働く環境全体にあるということです。この環境を設計する仕事こそが、ハーネスエンジニアリングです。
簡単に言うと、こういうことです。
優れたAIエージェントは、優れたモデルだけでは作れません。
優れたツール、優れた文書、優れた検証フロー、優れた作業環境がそろってはじめて、実際に仕事ができます。
ハーネスエンジニアリングとは何か
いちばんシンプルに定義すると、モデルの外側にあるすべてを設計する仕事です。
LangChainはこれを「Agent = Model + Harness」と説明しています。モデルが知能だとすれば、ハーネスはその知能を実際の仕事につなげる装置です。システムプロンプト、ツール、ファイルシステム、ブラウザ、サンドボックス、検証ループ、サブエージェントといったものがここに含まれます。
Mitchell Hashimotoはもっと実務的に語ります。エージェントが同じミスを繰り返すなら、そのミスを二度としないように AGENTS.md を修正したり、スクリプトやツールを追加したりすべきだ、という話です。つまり、失敗をプロンプトだけで埋め合わせるのではなく、システムで直せということです。
整理すると、ハーネスエンジニアリングは次のような問いに答える仕事です。
- エージェントはどの文書から先に読むべきか
- どのツールを使えるようにするべきか
- どこまで修正できれば安全か
- 作業が長引いたとき、前の状態をどう記憶させるか
- 「完了」を誰が、どんな基準で判定するか
なぜ今、ハーネスエンジニアリングが重要なのか
以前はAIを「質問すると答えてくれるチャットボット」として使うことが多くありました。
でも今は、もっと長い作業を任せる方向へ進んでいます。
- バグ修正
- 機能開発
- 文書整理
- コードレビュー対応
- リリース前の検証
- 反復的な運用作業
問題は、こうした仕事が一回の返答で終わらないことです。
Anthropicは、長い仕事をするエージェントの核心的な問題をこう説明しています。エージェントは複数のセッションにまたがって働く必要があるのに、新しいセッションが始まると前の記憶を持っていない。
人間にたとえるなら、毎日新しい開発者が出社してきて、昨日誰が何をしたのかをまったく知らない状態に近いです。これでは当然、生産性は落ちるし、同じミスも繰り返されます。
だからハーネスが必要なんです。
AIにうまく考えさせるのではなく、AIが仕事を引き継ぎながらうまく進められる構造が必要になった、ということです。
良いモデルより、良い作業場が重要になる瞬間
ハーネスエンジニアリングが注目される理由は単純です。
同じモデルでも、ハーネスが変わると性能がかなり変わるからです。
LangChainは、同じモデルを保ったままハーネスだけを変えて、コーディングベンチマークの性能を大きく引き上げたと述べています。OpenAIも、Codexベースの開発フローで、人間が直接コードを書くよりも、エージェントが文書とツールを読み、PRまでつなげていく方式で生産性を高めたと説明しています。
この話はかなり重要です。
これからの競争力は「どのモデルを使うか」だけでなく、
「そのモデルが働く環境をどれだけうまく設計したか」で分かれる可能性があります。
ハーネスは具体的に何でできているのか
1. 短くて正確な案内文書
多くのチームは最初、巨大な AGENTS.md 一つにすべてのルールを入れようとします。
でもOpenAIは、この方法がうまくいかなかったと述べています。文書が長すぎると重要な情報が埋もれ、古くなるほど信頼性も落ちるからです。
そこで出てきたやり方はこうです。
AGENTS.mdには短い案内だけを置く- 詳細は
docs/以下に構造化する - エージェントは案内文を通じて必要な文書へたどり着く
たとえるなら、百科事典を丸ごと渡すのではなく、まず地図と目次を渡す方式です。
2. ファイルシステムとGit
LangChainは、ファイルシステムを最も重要なハーネス要素の一つと見ています。
理由はシンプルです。
- 作業途中の結果を保存できる
- 長い文脈をファイルに逃がせる
- 次のセッションが前の状態を引き継げる
- 複数のエージェントと人間が同じ作業空間で協働できる
Gitも重要です。
何が変わったのか追跡できるし、間違えたら戻せるし、新しく来たエージェントも最近の変更をすばやく把握できるからです。
3. 実行ツールとサンドボックス
モデルは本来、テキストを受け取ってテキストを返す存在です。
コードを実行したり、パッケージをインストールしたり、ブラウザを開いてUIを検証したりするのは、モデル本体の機能ではありません。ハーネスが与えた能力です。
そのため、良いハーネスにはふつう次のようなものが入ります。
bashのような汎用実行ツール- テストランナー
- ブラウザ自動化
- ログ参照
- スクリーンショット
- 隔離されたサンドボックス環境
こうしたツールがあってこそ、エージェントは「考えるだけの存在」ではなく、自分で確認して修正する存在になれます。
4. メモリと最新情報へのアクセス
エージェントは、コンテキストウィンドウの外にある出来事を自然には覚えていられません。
だから重要なルール、プロジェクトの履歴、最近の進行状況はファイルに残し、次のセッションで再び読ませる必要があります。
またモデルは学習時点以降の最新情報を知らないこともあるので、ウェブ検索や外部コンテキストツールも必要です。ライブラリのバージョン、最新ドキュメント、現在の状態のようなものは、ハーネスが供給する必要があります。
5. 検証ループ
Mitchell Hashimotoがとくに強調しているのが、ここです。
エージェントが間違っていると、すばやく分かるようにすること。
たとえば、こんな仕組みです。
- テストを自動で回す
- UIのスクリーンショットを比較する
- lintや構造チェッカーを置く
- 失敗ログをそのままエージェントに見せる
良いハーネスは、エージェントがミスしたときに「誰かがあとで見つける構造」ではなく、作業中にすぐ間違いだと知らせる構造を作ります。
長い作業でこそ、なぜ重要なのか
ハーネスエンジニアリングがとくに力を発揮するのは、長期実行タスクです。
Anthropicは、長い作業向けのハーネスとして二つの役割を提案しています。
- 最初の実行で環境を整える初期化エージェント
- その後の各セッションで一歩ずつ進むコーディングエージェント
この構造の核心は、「一度に全部やろうとしないこと」です。
初期化段階では、
init.shのような実行スクリプトを作り- 進捗ログファイルを作り
- 機能一覧をJSONで整理し
- 後続セッションが読むための足場を用意します
その次に、コーディングエージェントは各セッションごとに、
- 現在のディレクトリと状態を確認し
- 進捗ログとGit履歴を読み
- 機能一覧から一つだけ選んで作業し
- 終わったら進行状況を記録します
これは実は、人間のチームにおける良い仕事の進め方によく似ています。
つまり、ハーネスエンジニアリングはAIに魔法をかけることではなく、良いチームの働き方をシステムに移すことに近いんです。
なぜスキル、サブエージェント、フックが何度も出てくるのか
最近の文章でよく見かける言葉があります。skills、sub-agents、hooks です。
これも結局は、一つの問題を解決するための装置です。
コンテキストを節約しながら、必要な能力だけを使わせようという発想です。
HumanLayerは、すべてのツールと知識を最初からシステムプロンプトに詰め込むと、かえって性能が落ちると述べています。だから必要な瞬間にだけ特定の知識パッケージを呼び出すスキルが重要になります。これを「progressive disclosure」、つまり段階的な開示と説明しています。
サブエージェントも似ています。
ロールプレイ用のペルソナより大事なのは、コンテキストの分離です。ある下位タスクを別セッションに送れば、親エージェントは途中経過を全部抱え込まなくて済みます。
フックはもっと決定的です。
たとえば、作業が終わったと言ったら自動でテストを回し、失敗したらもう一度作業させるループをつなぐような仕組みです。これはプロンプトよりずっと強い制御方式です。
結局、ハーネスエンジニアリングは「AIをあまり信用しない技術」でもある
ここは誤解してはいけないところです。
ハーネスエンジニアリングはAIをもっと信じるための技術ではなく、むしろAIを無条件に信じないための技術でもあります。
良いハーネスは、次の前提で設計されます。
- モデルは文脈を見失うことがある
- モデルは早まって完了判定を下すことがある
- モデルはルールを誤って一般化することがある
- モデルは長い出力の中で自分でもぶれやすい
だから良いチームは「モデルが勝手にやってくれるだろう」とは考えません。
代わりに、モデルが失敗しそうな地点を予測し、その失敗を減らす構造を作ります。
この視点は大事です。
ハーネスエンジニアリングはAIを称賛する分野ではなく、AIの不安定さを実務的に扱う分野に近いのです。
実務では、どこから始めればいいのか
最初から大がかりに作る必要はありません。
むしろ、次の順番が現実的です。
1. エージェントがよくするミスを書き出す
例:
- テストせずに終わったと言う
- 間違ったコマンドを繰り返し実行する
- プロジェクトのルールを何度も破る
- 大きすぎる範囲を一度に触る
2. ミス一つに対して、対策を一つ作る
例:
AGENTS.mdに短いルールを追加する- よく使う検証スクリプトを追加する
- UI確認用のブラウザフローを追加する
- 作業終了前にテストを強制するフックを追加する
3. 文書を「説明書」ではなく「地図」に変える
- 短い案内文書
- 構造化された詳細文書
- 最新状態が残る進捗ログ
- 機能一覧と完了基準
4. 完了基準を人の感覚から、システムの基準へ移す
「なんとなくできた気がする」ではなく、
- テスト通過
- ブラウザ確認完了
- 機能一覧の更新
- ログに異常なし
のように定義することです。
この四つだけでも、エージェントの体感性能はかなり変わる可能性があります。
これからさらに重要になる理由
これからモデルはもっと良くなっていくはずです。
計画、推論、コード作成、自己レビューの能力も、引き続き改善されるでしょう。
それでも、いくつもの文章は共通して語っています。
モデルが良くなっても、ハーネスの重要性は消えない可能性が高いということです。
なぜなら、実際の業務はいつも環境の中で起こるからです。
- 会社ごとにコードベースが違い
- 文書構造が違い
- セキュリティポリシーが違い
- 検証方式が違い
- 協働フローが違うからです
つまり、モデルがどれだけ良くなっても、自分たちのチームの現実に合わせてつなぐ作業は残ります。その接続部こそがハーネスです。
まとめ
ハーネスエンジニアリングという言葉は、大げさな新しい流行語のように聞こえるかもしれません。
でも本質は意外なほど単純です。
AIがもっと賢くなるのを待つ代わりに、
AIがミスしにくいように職場を設計すること。
良いエージェントは、優れたプロンプト一つから生まれるわけではありません。
良い文書、良いツール、良い検証、良い作業フロー、良い記録習慣から生まれます。
だからAI時代に重要になる人は、モデルを最もうまく使う人だけではないかもしれません。
モデルがうまく働ける環境を設計する人、つまりハーネスを作る人が、これからますます重要になる可能性があります。