AIの品質ばらつきを防ぐ「ハーネスエンジニアリング」とは？構成要素から導入手順まで徹底解説

最終更新日:2026/10/09

AIコーディングエージェントを個人で使う分には成果が出るのに、チームで使うと品質がばらつく━同じ指示を出しても、セッションが変われば書き方が変わり、前回の決定は引き継がれません。AIモデルを最新版に入れ替えるだけでは、この問題が解消しないこともあります。

原因がAIモデルの側にないとすれば、テコ入れするべき箇所はその外側です。2026年前半から広まった「ハーネスエンジニアリング」は、この外側を設計する手法です。

この記事では、定義や関連概念との違い、5つの構成要素、権限の決め方、導入手順、コーディング以外の業務への応用を紹介します。

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

ハーネスエンジニアリングとは、AIエージェントが安定して成果を出せるように、AIモデル（文章やコードを生成するAI本体）の外側にある環境そのものを設計する取り組みです。

守るべきルール、使える道具、作業の型、間違いを検知する仕組み、前回の作業を引き継ぐ記憶。これらをまとめてハーネスと呼びます。

ハーネスエンジニアリングの定義

定義の言い回しは論者によって幅がありますが、いずれもAIモデルの外側に焦点を当てている点で共通しています。

AIエージェント開発の枠組みを提供するLangChainは、The Anatomy of an Agent Harness（2026年3月10日公開）で「Agent = Model + Harness」という式を示し、ハーネスとは「AIモデルそのもの以外のすべてのコード・設定・実行ロジック」だと述べています。

システムプロンプト・ツールやスキル・ファイルシステムやサンドボックスといった実行基盤・サブエージェントの起動などの制御ロジック・決まった処理を差し込む仕掛け。これらがハーネスに含まれます。

馬具に由来する言葉

ハーネスは、もともと馬に装着する馬具を指す言葉です。馬の力を抑えつけるためではなく、力を目的の方向へ導くために使われます。

ソフトウェアの分野でも、テスト対象のプログラムを動かして結果を検証できる状態にする仕組みを「テストハーネス」と呼ぶ用法が以前からありました。

対象そのものではなく、それを動かす側を作り込んで振る舞いを制御する。ハーネスエンジニアリングも発想は同じです。

AIモデル単体ではエージェントにならない理由

AIモデル単体の基本的な役割は、与えられた入力をもとに出力を生成することです。

AIモデル単体では、やり取りをまたいで状態を保つことも、コードを実行することも、最新の情報にアクセスすることも、作業用の環境を用意することもできません。これらはすべてハーネス側の機能にあたります。

AnthropicもDemystifying evals for AI agents（2026年1月9日公開）で、エージェントハーネス（スキャフォールド）を「AIモデルがエージェントとして振る舞えるようにするシステム」と定義しています。

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

これら3つ（ハーネス、プロンプト、コンテキスト）は扱う範囲が異なり、外側になるほど広い範囲を含む関係です。

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

プロンプトエンジニアリングは、AIへの指示文の書き方と組み立て方を扱う技術です。プロンプト入力に対する出力精度の向上が目的です。

AnthropicはEffective context engineering for AI agents（2025年9月29日公開）で、プロンプトエンジニアリングを「最適な結果を得るためにLLMへの指示を書き、組み立てる方法」と位置づけています。

分類や文章生成のように、1回で完結するタスクが中心だった時期に主役だった考え方です。

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

コンテキストエンジニアリングが扱うのは、AIに渡す情報の中身です。

前掲のAnthropicの記事は、これをプロンプトエンジニアリングの自然な発展と位置づけ、推論の最中に最適な情報の集合を選び、保ち続けるための手法群だと説明しています。

システムプロンプトだけでなく、ツールの定義・外部データ・これまでのやり取りの履歴まで含めた状態全体が対象です。

3つの関係は入れ子

ハーネス・プロンプト・コンテキストエンジニアリングの3つは、どれを選ぶかという横並びの関係ではありません。指示文を書く作業は、渡す情報を設計する作業の一部です。そして情報を設計する作業は、環境全体を設計する作業に含まれます。

プロンプトがコンテキストに含まれ、コンテキストがハーネスに含まれる。この入れ子として捉えると、役割の重なりを把握しやすくなります。新しい概念が古い概念を置き換えたのではなく、扱う範囲が外側へ広がったという関係です。

対応がうまくいかないときの切り分け

3つの層を分けておく利点は、原因を切り分けられる点にあります。指示文を直しても改善しないのであれば、原因はより外側の層に残っています。

症状	疑うべき層	手を入れる場所
1回の回答の粒度や形式が期待と違う	プロンプト	指示文の具体性・出力形式の指定
同じ間違いを何度も繰り返す	コンテキスト	ルールファイル・渡している情報の過不足
指摘されるまで誤りに気づかない	ハーネス	検証の自動化・フィードバックの返し方
前回の決定を無視した実装が返る	ハーネス	記録の外部化・セッション間の引き継ぎ

内側から外側へ順に確かめると、手戻りを減らせます。

指示文の直しに何度も戻ってしまうときは、そもそも見るべき箇所を間違えている可能性があります。

なぜ2026年に注目されたのか

この言葉が広く使われ始めたのは2026年前半です。

「ハーネスエンジニアリング」が生まれた経緯と時期

この用語が広まるきっかけの一つとなったのが、ソフトウェア開発者のMitchell Hashimoto氏が2026年2月5日に公開した記事My AI Adoption Journeyです。

同氏は、業界で受け入れられた呼び名があるかは分からないと断ったうえで、自らは harness engineering と呼ぶようになったと述べています。

6日後の2026年2月11日、OpenAIが同じ言葉を使った記事を公開しました。

人が手でコードを書かない前提で5か月にわたり開発を進め、約100万行の規模に達したという内容です。個人の記事でこの呼び名が使われ、その直後にOpenAIから大規模な実践例が公開されました。

こうした動きによって、ハーネスエンジニアリングという言葉が注目されるようになりました。

AIエージェントの「自走時間の長期化」がもたらした課題

なぜAIモデルの「外側の環境設計」が不可欠になったのでしょうか？最大の理由は、AIが人の目の届かないところで長時間、自律的に稼働するようになったからです。

近年では、1つの複雑なタスクに対して、AIが数時間連続して処理を実行するケースも珍しくありません。人が画面の前で逐一監視する対話型のAIであれば、おかしな挙動に気づいた時点で即座に処理を止め、指示を出し直せます。しかし、数時間にわたって裏側で自走するエージェントに対しては、この「人力での軌道修正」が通用しません。

だからこそ、AI自身が間違いやルールの逸脱に気づき、自動で軌道修正できる仕組みを、あらかじめ外側に用意しておく必要が生じたのです。

ハーネスを構成する5つの要素

ここでは、コーディングエージェントの文脈でよく挙げられる5つの要素に沿って説明します。

ただし、この分け方が唯一の正解というわけではありません。3つに束ねる分け方も、コンテキスト・行動・フィードバック・運用の4領域に分ける分け方もあり、論者によって粒度が異なります。

ルール｜守るべきことの明文化

命名の決まり、使ってよいライブラリ、変更してはいけない領域など、チームの中で暗黙知になっている約束を文章にしたものです。

置き場所としては、製品に応じてリポジトリ内のAGENTS.mdやCLAUDE.mdといった指示ファイルが使われます。読み込み方や適用範囲はエージェントによって異なるため、利用するツールの仕様に合わせて配置します。

スキル｜作業手順の再利用

毎回同じ説明を書かずに済むように、定型作業の手順をまとめておく仕組みです。新機能を追加する際の流れや不具合を調べる際の観点などを型として保存し、必要なときに呼び出します。

利点は、指示を書く手間が減ることだけではありません。同じ作業を頼むたびにエージェントが違うやり方を選ぶ状態がなくなり、成果物の品質が安定します。

フック｜違反をその場で止める仕組み

フック（特定の操作の前後に自動で処理を差し込む仕掛け）は、ルールを機械的に守らせる役割を持ちます。ファイルを保存した直後にリンター（コードの書式や記述の誤りを自動で検査するツール）を走らせる、といった使い方が典型です。

検査できるのは書式や記述の誤りだけではありません。触れてはいけないディレクトリを編集していないかといった、プロジェクト固有の決まりも判定の対象にできます。

人が読んで指摘する規約ではなく、通らなければ先へ進めない条件として組み込む形です。

メモリ｜セッションをまたぐ引き継ぎ

セッションをまたいだときに、前回の経緯が自動で引き継がれないエージェントもあります。

決定事項や進捗をファイルとして外に書き出し、次の作業の冒頭で読み込ませることで、判断の一貫性を保てます。

書き出す内容は、進捗だけでは足りません。何を採用したか、なぜそれを選んだかまで残しておかないと、次のセッションで別の選択に戻されてしまいます。

フィードバックループ｜自分で気づいて直す仕組み

テストの実行結果やエラーの内容をエージェント自身に返し、誤りを検知・修正させる流れです。

人が毎回確認しなければ誤りを見つけられない状態では、自動化しても確認作業が残ってしまいます。

手段はテストだけではありません。型チェック・リンター・依存関係の検査・画面を操作しての動作確認まで、返ってくる速さと検出できる範囲が異なるものを重ねます。

ハーネスエンジニアリングを実現する主要フレームワーク・ツール

ハーネスエンジニアリングは特定の製品を指す言葉ではなく、AIモデルの外側にルール・ツール・記憶・検証などの仕組みを設ける考え方です。

実際に構築する際は、AIエージェント向けのフレームワークやSDKを利用すると、こうした仕組みを一から作る負担を減らせます。代表的なものをまとめると、次のとおりです。

フレームワーク・ツール	得意な領域	ハーネス構築で活用できる主な機能
LangChain／LangGraph	長時間・状態保持型のエージェントや複雑なワークフロー	状態の永続化・メモリ・処理の中断／再開・人による承認・ツール連携
CrewAI	役割の異なる複数エージェントの協調	エージェント間の役割分担・フロー・メモリ・ガードレール・処理状態の管理
OpenAI Agents SDK	比較的シンプルな構成からエージェントを実装するケース	ツール呼び出し・エージェント間の引き継ぎ・ガードレール・セッション・トレーシング
Microsoft Agent Framework	Microsoft・Azure環境を含む業務システムとの統合	ツール・メモリと永続化・ワークフロー・ミドルウェア・人による承認

たとえば、途中経過を保存しながら長時間動くエージェントを作りたい場合はLangGraph、複数の専門エージェントに役割を分けたい場合はCrewAIが候補になります。

OpenAIのモデルを中心に比較的シンプルな構成から始めたい場合はOpenAI Agents SDK、Microsoftのサービスと組み合わせる場合はMicrosoft Agent Frameworkも選択肢です。

ただし、フレームワークを導入するだけでハーネスが完成するわけではありません。どのルールを守らせるか、どの操作を自動で止めるか、何を記録し、どの結果を検証するかは利用側で決める必要があります。

そのため、ツール選定から始めるのではなく、自社で不足しているものを確認し、それを実装しやすいフレームワークを選ぶほうが適しています。

権限とガードレールの設計

5つの要素は「何をどう進めさせるか」を扱いますが、その手前に「どこまで触らせるか」という決め事があります。ここを曖昧にしたまま自律性だけを上げると、失敗したときの影響が読めなくなります。

実行環境の隔離

エージェントが生成したコードを、権限や影響範囲を制限しないまま実行するのは避けるべきです。

サンドボックス（隔離された実行環境）を用意し、そこでコードの実行やファイルの確認をさせます。実行できるコマンドを許可リストで絞る、ネットワークを遮断するといった制御を加えれば、影響範囲をさらに狭められます。

隔離の利点は、安全性だけではありません。環境を必要なときに作り、終わったら壊せるため、複数のタスクを並行して走らせても互いに影響しません。

触れる範囲の制限

どのディレクトリを編集してよいか、どのコマンドを実行してよいか、どの外部サービスへ接続してよいか。これらを事前に決め、ルールファイルへの記載ではなく仕組みとして効かせます。

範囲を絞ることは、能力を下げることと同じではありません。境界の外側だけを止め、その内側ではやり方を任せる。選択肢が絞られているほうが迷いも減るため、制約は速度と両立します。

人が最終承認する領域の線引き

自律性を高めても、人を外しきる設計にはしません。優先順位の決定・要望を受け入れ条件へ翻訳する作業・結果の妥当性の確認は人が担い、判断が要る場面ではエージェントから人へ差し戻す形にします。

線を引く目安になるのは、間違えたときの取り返しのつきやすさです。

本番環境の変更、権限の操作、顧客に影響が及ぶ差分は、承認を挟む前提で設計しておいたほうが安全でしょう。逆に、取り消しが容易で影響範囲の閉じた変更まで人の確認を必須にすると、自動化の効果が相殺されます。

ハーネスエンジニアリングの導入手順

自社の環境に合わせた導入手順を決めるため、まずは先述した「5つの構成要素」が現状どこまで揃っているかを棚卸ししましょう。この整備状況によって、最初に取り組むべきステップが変わります。

要素	確認する内容
ルール	チームの約束が文章になっており、エージェントが読める場所に置かれているか
スキル	繰り返す作業の手順が保存され、必要なときに呼び出せるか
フック	規約違反が自動で止まるか
メモリ	前回の決定が次の作業へ引き継がれるか
フィードバックループ	人が指摘する前に、エージェント自身が誤りに気づけるか

目安として、まったく整備されていない場合は「ステップ1（文書化）」から始めます。ルールや作業手順がある程度揃っている場合は「ステップ2（自動検証）」へ進み、検証まで自動化できているなら「ステップ3（記録と観測）」の仕組みを整えるとよいでしょう。

ステップ1｜ルールの文書化（守るべきことの書き出し）

最初に着手するのは、暗黙知の言語化（ルール設定）です。チーム内でなんとなく共有されている約束事を、エージェントが読める場所へ書き出します。
最初から完璧なマニュアルを作ろうとすると挫折しやすいため、「直近で指摘の多かった項目から着手し、同じ間違いが起きるたびに1行ずつ追加する」というアジャイルな進め方がおすすめです。

記載内容の候補

• ビルド・テスト・起動の正しいコマンド
• 主要なディレクトリ構造と依存関係の方向
• 秘密情報（APIキーなど）や認証の取り扱いルール
• ブランチ戦略とコミットメッセージの決まり
• 命名規則と、絶対にやってはいけない禁止事項

ステップ2｜フックの導入（検証の自動化）

次に着手するのは、書き出したルールのうち「機械的に判定できるもの」の自動化です。リンター（静的解析ツール）やテストをファイル保存時やコード提出時に走らせ、規約違反を「人の目に触れる前」に自動で止めます。

この仕組み（フック）が機能すると、人間がレビューする範囲を「単純な規約チェック」から「高度な設計判断」へと絞り込めます。何を機械に任せ、どこから人が確認するかの線引きをこの段階で明確にしましょう。

ステップ3｜オブザーバビリティ（記録と観測）の追加

最後に、決定事項の確実な記録と、うまくいかなかった場面の観測（フィードバックループ）を加えます。

システムの内部で何が起きているかを外から把握できるようにする「オブザーバビリティ（可観測性）」の考え方を持ち込み、どこで失敗したかを追跡できる状態にします。ログや処理時間の記録をエージェント自身が参照できるようにしておけば、人がログを見て指示を出すのではなく、「エラーの確認から修正まで」をエージェントに自律的に任せられるようになります。

ハーネスエンジニアリング゙の導入にかかる負担と効果の測り方

ハーネスの整備には工数がかかります。投資の可否を判断する立場で押さえておきたいのは、この2点です。

工数がかかる場所

負担が集中するのは、初期の作り込みよりも、その後の維持です。ルールは書いた時点から古くなり、検査の仕組みは実装の変化に合わせて直す必要があり、記録の形式も運用しながら決まっていきます。

もう一点、見落とされやすいのが人の側のボトルネックです。生成の量が増えると、詰まる場所はコードを書く工程から人による動作確認へ移ります。生成を速くするほど、確認の工程を人から外す仕組みにも投資が要るという関係です。

効果を測る指標

何をもって成果とするかは、あらかじめ決めておきます。

公開されている事例で挙げられるのは、プルリクエストの件数と1人あたりの処理量、人が手を入れずに進んだ範囲、手作業と比べた所要時間の比といった数字です。

自社に置き換えるなら、次のような観点が候補になります。

• 作業が完了するまでの日数
• 検査が一発で通る割合
• 人がレビューや修正に使った時間
• 差し戻しや切り戻しの発生頻度
• 文書と実装が食い違っている箇所の数

出す量だけを指標にすると、後始末の負担が見えません。処理量と品質、そして人の負荷を並べて見るのが妥当です。

ハーネスエンジニアリングでよくある失敗と限界

つまずく場所は、作りすぎることと、作ったまま手を離すことのどちらかに分かれます。あわせて、ハーネスをどれだけ整えても解決しない範囲も押さえておきたいところです。

作り込みすぎによる陳腐化

最初から詳細なルールを大量に用意すると、維持しきれずに実態と食い違います。守られないルールは、かえって害になる可能性があるため、少なく始めて必要が生じたときに足していく進め方が向いています。

検査の仕組みも同じです。フックを増やしすぎるとファイルを1つ編集するたびに複数の検査が走り、応答が目に見えて遅くなります。

止める価値のある違反かどうかで判断し、警告で足りるものは警告にとどめる切り分けが必要です。

書いたまま放置されるルール

文書は書いた時点から古くなっていきます。仕様や体制が変わったときに更新する担当と時期を決めていないと、半年後には誰も参照しなくなるでしょう。

更新を人の善意に任せない方法もあります。文書と実装の食い違いを検出して直す仕組みを組み込んでおけば、鮮度の管理そのものを自動化できます。

悪い書き方の複製と拡散

エージェントは、リポジトリのなかにすでにある書き方を手本にします。質の低いものや不揃いなものでも同じように複製されるため、1か所の妥協を放置すると同じ形が増え続けます。

対処は、望ましい書き方を判断の余地の少ない規則として書き下すことです。好みの問題として残すと複製が止まりません。機械的に判定できる粒度まで落としてから、検出の仕組みに乗せます。

検証を人に任せたままの運用

ルールを増やしても、確認するのが人だけであれば負荷は減りません。機械で判定できる項目は機械に任せ、人は判断の要る部分に集中する。この切り分けを最初に決めておきます。

判定を人に残したままルールだけを増やすと、レビューの対象が広がるぶん、導入前より負荷が上がることさえあります。ルールを1つ足すときに、それを誰が・どうやって確認するのかまで決める習慣を持つと避けられます。

ハーネスでも解決できないこと

ハーネスは、AIモデルの能力そのものを引き上げるものではありません。難しい設計判断や、業務知識を前提とした意思決定は、引き続き人の役割として残ります。

汎用のエージェント1つで足りるのか、テストや品質確認を担う専用のエージェントを分けたほうがよいのかも、まだ定説がありません。どこまで任せられるかの線引きは、現時点では試しながら決めるほかありません。

コーディング以外の業務系AIエージェントへの応用

ハーネスの定義は、コーディングに限定されたものではありません。AIモデルの外側で入力を処理し、道具の使用を統率し、結果を返す仕組みという捉え方は、営業支援・問い合わせ対応・社内文書の作成といった業務にも当てはまります。

コーディング以外に応用できる理由

セッションをまたいで進捗を保つ、状態を外部に記録する、完了の基準を明示する。これらは仕事の種類を選びません。ソフトウェア開発向けに作られた手法についても、科学研究や財務モデルの作成のような分野へ広げられる余地が指摘されています。

コーディングが先行したのは、検証の手段が最初から揃っていたからです。テストを走らせれば合否が返り、型チェックが誤りを指摘し、リンターが規約違反を止めます。

業務系で同じ効果を得るには、この判定にあたるものを自前で用意する必要があります。

業務系での5要素の読み替え

要素の呼び名は変わりませんが、中身は業務に合わせて置き換わります。

要素	業務系での対応
ルール	業務マニュアル・禁止事項・承認の要る範囲
スキル	見積書の作成手順・問い合わせの一次対応の型
フック	送信前の承認・社外への持ち出しを止める制御
メモリ	顧客ごとの経緯・過去のやり取りの引き継ぎ
フィードバックループ	対応結果の記録と、誤りを次に反映する流れ

読み替えたときにとくに手薄になりやすいのが、フィードバックループです。コーディングと違って自動で合否が返る仕組みがないため、意識して作らないと、結局すべてを人が確認する運用に戻ります。

応用しにくい業務の見分け方

判断の基準は、成果の正しさを機械で判定できるかどうかにあります。

金額の計算・必須項目の充足・送付先の妥当性のように、条件を書き下せるものは判定を自動化できます。一方、提案内容が顧客に合っているか、文面の調子が適切かといった評価は、条件として書き下せません。

成果の良し悪しを人にしか判断できない業務ほど、フィードバックループの自動化は難しくなります。

まずは判定基準の明確な定型業務から着手するのが、無理のない進め方です。判定できない部分は、自動化を諦めるのではなく、承認の工程を残したうえで前後の作業を任せる形が落としどころになります。

情報システム部門が最初に確認すること

ツールの選定より先に、業務の手順と禁止事項が文書になっているかを確かめます。文書がない状態でエージェントを導入しても、渡せる情報がないため成果は安定しません。

この観点は、導入先を選ぶ判断にも使えます。手順が文書化され、判定基準が明確で、失敗しても取り返しがつく業務ほど、効果が出やすい領域です。逆に、整備の遅れている領域は、そのまま導入効果の出にくい領域だと考えられます。整備そのものを先に進めておけば、どのツールを選んだ場合でも無駄になりません。

まとめ

ハーネスエンジニアリングは、AIエージェントが働く環境を設計する取り組みです。技術要素そのものに目新しさはなく、文書の整備や自動検証といった以前からある手法の組み合わせで成り立っています。2026年前半に言葉として広まった背景には、AIが人の目の届かない時間帯に長く自走するようになった変化があります。

同じAIモデルでもハーネスが違えば結果が変わることは、公開されているベンチマークの比較でも示されています。裏を返せば、AIモデルを最新版に入れ替えるだけでは動かない部分が残る、ということでもあります。

着手にあたっては、5つの要素のうち何が欠けているかを確かめたうえで、文書化・自動検証・記録と観測の順に進めます。

あわせて決めておきたいのが、どこまで触らせるかと、何をもって効果が出たと判断するかです。整備には工数がかかりますし、ハーネスを整えても人の判断が要る部分は残ります。

それでも、人の確認に頼り続ける運用と比べれば、仕組みに任せる範囲を広げるほうが組織全体の負荷を下げられます。

アイスマイリーでは、AIエージェントのサービス比較と企業一覧を無料配布しています。課題や目的に応じたサービスを比較検討できますので、ぜひこの機会にお問い合わせください。

よくある質問

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

AIエージェントが安定して動けるように、AIモデルの外側にあるルール・ツール・記憶・検証などの仕組みを設計する取り組みです。

ハーネスエンジニアリングの具体例は？

まず挙げられるのは、リポジトリにチームの約束を書いたファイルを置き、エージェントが作業前に読む状態にすることです。ほかに、保存時にリンターを自動実行して規約違反を止める、決定事項をファイルに残して次の作業へ引き継ぐ、テスト結果をエージェント自身に返して修正させるといった取り組みがあります。実行環境をタスクごとに隔離し、触れる範囲を制限することも含まれます。

ハーネスエンジニアリングとOpenAIの関係は？

OpenAIは2026年2月11日にこの言葉を冠した記事を公開し、自社での実践例を示しました。これに先立ち、同年2月5日にはソフトウェア開発者のMitchell Hashimoto氏が個人記事で「harness engineering」という呼び名を使用しています。

ハーネスエンジニアリングの次に来るものは？

呼び名は今後変わる可能性があります。この言葉自体が個人の記事から広まった経緯を持ち、使い始めた本人も、より適切な呼び名があればそちらに合わせると述べていました。今ハーネスが担っている機能の一部はAIモデル側へ取り込まれていく、という見方もあります。名前を追うより、自社に欠けている要素を埋める作業を優先するとよいでしょう。