ハーネスエンジニアリングとは、AIのモデルそのものではなく、その周りの仕組み(指示のファイル・使える道具・権限・確認・記録)を設計し、AIエージェントが失敗するたびに直していくことです。AIエージェントを業務で動かすときに、どこまで任せてよいか、誰がどこで確認するか、何を記録に残すかは、モデルの賢さではなくこの周辺の仕組みで決まります。自社でAIエージェントを動かすかどうかを考えているDX推進や情報システムの担当者、経営層にとっては、開発の進め方や相談先を決める前に、社内で話し合っておく項目の一覧になります。
この記事の答え
- ハーネスエンジニアリングとは、AIエージェントの周りにルールのファイル・道具・権限・確認・記録を用意し、失敗のたびに同じ失敗が起きない形へ直すことです
- プロンプトやコンテキストの工夫は1回の指示の中身を良くする話で、ハーネスは何度動かしても安全に止まる仕組みを作る話です
- 業務で動かす会社は、任せる範囲・権限・人が確認する工程・記録を見直す担当の4つを先に決め、1業務から始めます
ハーネスエンジニアリングとは何か
ハーネスエンジニアリングとは、AIエージェントが仕事をするときの周りの仕組みを設計し、使いながら直し続けることです。周りの仕組みには、AIエージェントが毎回読む指示のファイル、使ってよい道具、触ってよい範囲(権限)、作業の結果を確かめる仕組み、作業の記録が入ります。
AIエージェントの出来は、モデルの性能と、モデルを動かすハーネスの両方で決まります。同じモデルでも、何を読ませ、どの道具を渡し、どこで止めるかが違えば、仕事の結果は変わります。そのため「AIエージェント=モデル+ハーネス」と説明されることがあります。
ハーネスの語源は馬具
ハーネス(harness)は、もともと馬に付ける馬具を指す英語です。馬の力そのものは変えずに、手綱や鞍、引き綱で向かう先と力の伝わり方を決め、馬車や荷車を引かせます。
AIのハーネスも同じ考え方です。モデルの力は変えずに、道具と権限で行き先を決め、確認で暴走を止めます。AIのハーネスやハーネスAIという言い方で検索されることもありますが、指しているものは同じで、モデルを業務で働かせるための周りの装備のことです。
プロンプトエンジニアリング・コンテキストエンジニアリングとの違い
3つの違いは、扱う範囲の広さです。プロンプトエンジニアリングは「AIに何をどう伝えるか」、コンテキストエンジニアリングは「AIに何を見せるか(読ませる資料・会話の履歴・検索結果)」を扱います。ハーネスエンジニアリングはそれらを含めたうえで、AIが使う道具、触れる範囲、結果の確認、記録と見直しまでを扱います。
| 呼び方 | 何を良くするか | 主な対象 | 失敗したときに直すもの |
|---|---|---|---|
| プロンプトエンジニアリング | 1回の指示で返ってくる答え | 指示の文面 | 指示の書き方 |
| コンテキストエンジニアリング | AIが判断に使う材料 | 資料・履歴・検索結果の渡し方 | 渡す資料の選び方と量 |
| ハーネスエンジニアリング | 何度動かしても安全に仕事が終わること | ルールのファイル・道具・権限・確認・記録 | 同じ失敗を止める仕組み |
プロンプトは1回の会話の質を上げ、ハーネスは繰り返しの運用を安定させます。人が1回ずつ答えを読む使い方ならプロンプトの工夫で足りますが、AIエージェントが自分でファイルを書き換え、システムへ登録し、何十もの手順を続けて進めるようになると、指示の文面だけでは防げない失敗が出てきます。プロンプトの書き方の型や、コンテキストエンジニアリングとの違いの詳しい説明は、別の記事にまとめています。
ハーネスエンジニアリングが広まった経緯
ハーネスエンジニアリングという言葉は、AIエージェントに長い作業を任せる開発者のあいだで、2025年の終わりから2026年にかけて使われるようになりました。きっかけとしてよく挙がるのは、次の3つの発信です。
Mitchell Hashimoto氏の「Engineer the Harness」
開発者のMitchell Hashimoto氏は、2026年2月5日のブログ記事「My AI Adoption Journey」の中に「Engineer the Harness」という節を設けています。氏はこの節で、ハーネスを作るとは、エージェントが間違えるたびに、同じ間違いを二度と起こさない仕組みを時間をかけて作ることだと説明しています。
方法として挙げているのは、ルールのファイルを直すことと、道具を用意してその存在をファイルに書くことの2つです。
- 誤ったコマンドを繰り返すといった単純な問題は、AGENTS.md(またはそれに相当するファイル)を書き足して直す
- スクリーンショットを撮る、対象を絞ったテストを走らせるといった道具のスクリプトを作り、その道具があることをAGENTS.mdに書いておく
Anthropicの長時間動くエージェントのハーネス
Anthropicは2025年11月26日の技術ブログ「Effective harnesses for long-running agents」で、Claude Agent SDKを汎用のエージェントのハーネスと呼び、長時間の作業で起きた失敗と対策を報告しています。
報告された失敗は2つです。新しいセッションは前のセッションの経緯を覚えていないため、一度に多くをやろうとして途中で終わる失敗と、まだ終わっていないのに完了と判断する失敗が起きました。対策として、最初のセッションで環境を整える役を置き、初期化用の起動スクリプト、進捗を書く記録ファイル、最初のgitのコミットを用意させています。以降のセッションは1回に1つの機能だけ進め、機能の一覧をJSONで持ってテストを通ったものだけを完了にし、セッションの終わりに進捗の記録とコミットを残す形にしました。
業務に置き換えると、記憶を引き継げないAIに長い仕事を任せるなら、引き継ぎのメモと、終わったかどうかを決める基準を、AIの外側に用意するということです。
OpenAIの「Harness engineering」
OpenAIも「Harness engineering」という題の記事を公開しており、言葉が広まった出どころの1つとして挙げられます。AIの開発元が記事の題に使うほど、ハーネスエンジニアリングは言葉として定着してきています。
AIハーネスの構成要素
AIのハーネスは、ルールのファイル、スキル、フック、道具、権限、人の確認、記録の7つで組み立てます。どれか1つで足りるものではなく、指示で伝えることと、仕組みで止めることを分けて重ねるのが基本です。
| 構成要素 | 何をするものか | 業務での例 |
|---|---|---|
| ルールのファイル | AIエージェントが毎回最初に読む指示と禁止事項 | 社外に送る文書は下書きまでにする、と書いておく |
| スキル | 作業の種類ごとに分けて持つ手順の資料 | 請求書の確認の手順を、その作業のときだけ読ませる |
| フック | 特定の操作をAIの判断を通さずに止める仕組み | ファイルを消す操作の前に止めて人に聞く |
| 道具(MCPなど) | AIエージェントが使える外部のシステムや機能 | 社内の文書検索だけをつなぎ、会計システムはつながない |
| 権限 | 読む・書く・送るのどこまでを許すか | 共有フォルダは読み取りだけにする |
| 人の確認 | 人が見て決める工程 | 支払・送信・登録の前に担当者が承認する |
| 記録 | 作業の経過と結果を残したもの | 作業ログと進捗のファイルを残し、見直しに使う |
失敗の記録はルールのファイルへ戻します。
ルールのファイル(CLAUDE.md・AGENTS.md)とメモリ
ルールのファイルは、AIエージェントが作業を始めるたびに読む指示書です。Claude CodeではCLAUDE.md、ほかの多くのツールではAGENTS.mdという名前のファイルを置きます。業務の言葉でいえば、新しく来た担当者に毎朝渡す申し送りの紙にあたります。
AIエージェントは作業が終わると、そのときのやり取りを次の作業へ持ち越せないことが多く、メモリの機能で覚えさせられる量にも限りがあります。毎回守らせたいことは、AIの記憶に頼らずファイルに書いて毎回読ませます。
スキル・フック・MCPなどの道具
スキルは、特定の作業のときだけ読み込む手順書です。ルールのファイルにすべての手順を書くと長くなりすぎるため、作業ごとの手順はスキルに分けます。スキルの作り方や共有の手順は、別の記事にまとめています。
フックは、決まった操作の前後で必ず走る確認です。ルールのファイルの指示は、AIが読み落とせば守られません。フックはAIの判断を通さずに、仕組みとして操作を止められるので、消してはいけないファイルや送ってはいけない宛先のように、一度でも破られると困るルールに使います。
AIエージェントが外部のシステムを使うときの道具には、MCP(Model Context Protocol)という共通の接続の仕組みがよく使われます。何をつなぐかは、そのまま何を触れるかになるので、業務に必要な道具だけをつなぎます。
権限と人の確認
権限は、AIエージェントが読める範囲、書き込める範囲、外へ送れる範囲を決める設定です。人の確認は、権限で許した操作のうち、結果が社外へ出る、お金が動く、取り消せないものの前に人の承認を置くことです。
権限は最小から始め、確認の工程は外さずに残します。AIエージェントが十分に仕事をこなせると分かってから、記録を根拠に権限を広げる順番にします。
記録とフィードバックループ
記録は、AIエージェントが何を読み、どの道具で何をしたかの履歴です。記録があれば、失敗したときに原因を探せ、同じ失敗を止めるルールやテストを足せます。失敗を記録し、ルールとテストへ戻し、次の作業で効いたかを見る、という繰り返し(フィードバックループ)が、ハーネスエンジニアリングの中心です。
業務でAIエージェントを動かす会社が決めること
業務でAIエージェントを動かす会社が先に決めるのは、任せる範囲、権限、人が確認する工程、記録と見直しの担当の4つです。どれも開発を始めてからでは決めにくく、技術の問題ではなく業務と責任の問題なので、経営層とDX推進の担当者が決めます。
| 決めること | 決める内容 | 決めないと起きること |
|---|---|---|
| 任せる範囲 | どの業務のどの工程をAIエージェントに任せるか | 何でも頼まれ、どこで止めるかが人によって変わる |
| 権限 | 読む・書く・送るのどこまでを許すか | 必要以上のデータやシステムに触れられる |
| 人が確認する工程 | 誰がどの操作の前に承認するか | 確認が形だけになり、誤りが社外に出てから見つかる |
| 記録と見直しの担当 | 記録を誰がいつ読み、ルールを誰が直すか | 失敗しても直されず、同じ失敗が続く |
ハーネスのどこまでを用意すれば安全に任せられるかは、権限を最小から始める・人が確認する工程を残す・実行の記録を残す、の3点がそろっているかで判断します。3点がそろっていれば、AIエージェントが間違えても被害は小さく収まり、原因を見つけて直せます。どの工程をAIに任せ、どの工程に人の承認を残すかの仕分けの基準は、別の記事で詳しく扱っています。
非エンジニアの業務の担当者が受け持つこと
ハーネスエンジニアリングには、エンジニアでない人も深く関わります。ルールのファイルに書く中身、つまり何をしてよく何をしてはいけないか、どんな場合に人へ聞くべきか、どうなれば仕事が終わったといえるかは、業務の担当者にしか書けません。
業務の担当者が言葉で書き出し、エンジニアがそれをフック・テスト・権限の設定に組み込むという分担にすると、非エンジニアの部署でもハーネスを育てられます。AIエージェントが失敗したとき、それが業務のルールの抜けなのか、仕組みの不具合なのかを見分けるのも、業務の担当者の役目です。
経営層が決めておくこと
経営層が決めるのは、AIエージェントにどこまでの責任を持たせるかの線です。たとえば、社外に出る文書は人が確認してから送る、金額を確定させる操作はAIにさせない、といった線は、現場では決めきれません。
線を先に決めておけば、現場はその内側で任せる範囲を広げられます。線が無いまま始めると、問題が起きるたびに全体を止めて話し合うことになり、AIエージェントの利用そのものが進まなくなります。
ハーネスエンジニアリングの始め方の3段階
ハーネスエンジニアリングの進め方は、ルールを書き出す、確認を仕組みにする、記録して直す、の3段階です。最初から完全なハーネスを作ろうとせず、1つの業務で動かしながら、失敗が出たところから仕組みを足していきます。
3段階目で見つけた失敗は1段階目のルールへ戻します。
| 順番 | 段階 | やること | 主に担う人 |
|---|---|---|---|
| 1 | ルールを書き出す | 任せる業務を1つに絞り、禁止事項と判断の基準をルールのファイルに書き、権限を読み取り中心にする | 業務の担当者 |
| 2 | 確認を仕組みにする | 守らせたいルールをフックやテストに移し、外に出る操作の前に人の承認を置く | エンジニア |
| 3 | 記録して直す | 作業の記録を読み、失敗をルールとテストに足し、効いたら任せる範囲を広げる | 業務の担当者とエンジニア |
1段階目:ルールを書き出し、権限を絞る
最初は、件数が多く、間違えても社内で直せる業務を1つ選びます。その業務を人がやるときの手順、迷ったときの判断の基準、やってはいけない操作を書き出し、ルールのファイルにします。権限は読み取りを中心にし、書き込みや送信は人が行う形から始めます。
2段階目:確認を仕組みにする
動かしてみると、ルールに書いたのに守られない場面が出てきます。そのうち、一度でも破られると困るものはフックで止め、仕事が終わったかどうかはテストや確認の手順で判定させます。Anthropicの報告にあった「まだ終わっていないのに完了と判断する」失敗は、終わりの基準をAIの判断ではなく、外側の確認に持たせることで防ぎます。
3段階目:記録して直し、任せる範囲を広げる
作業の記録を定期的に読み、失敗をルールのファイルやテストに書き足します。Mitchell Hashimoto氏の言う、同じ間違いを二度と起こさない仕組みを作ることは、この段階の繰り返しのことです。失敗が減ったことを記録で確かめてから、権限や任せる工程を広げます。AIエージェントがきちんと仕事をしているかを数字で確かめる方法と、合格ラインの決め方は、別の記事で扱っています。
ハーネスづくりでつまずきやすい点
つまずきやすいのは、ルールを増やしすぎる、人の確認を早く外す、作って終わりにする、の3つです。
ルールを増やしすぎる
失敗のたびにルールのファイルへ書き足していくと、ファイルが長くなり、AIエージェントが一つひとつのルールに注意を向けにくくなります。機械で止められる禁止事項はフックへ、特定の作業の手順はスキルへ移し、ルールのファイルは毎回守らせたいことだけに絞ります。
人の確認を早く外す
AIエージェントがしばらく問題なく動くと、承認の工程が手間に見えてきます。承認を外すのは、記録で失敗が十分に少ないと確かめられ、外したあとに誤りが出ても取り戻せる工程に限ります。取り消せない操作の前の承認は、うまく動いていても残します。
作って終わりにする
業務のやり方や社内のルールが変われば、ハーネスも古くなります。記録を誰が読み、ルールを誰が直すかを決めずに始めると、ハーネスは最初の状態のまま残ります。見直しの担当と時期を、動かし始める前に決めておきます。社内の誰が記録を読み、どこまでを外部に頼むかという体制も合わせて考えておくと、運用が止まりにくくなります。
まとめ:ハーネスエンジニアリングとはAIエージェントの周りの仕組みを育てること
- ハーネスエンジニアリングとは、AIのモデルではなく、その周りの仕組み(ルールのファイル・道具・権限・確認・記録)を設計し、失敗のたびに直していくこと
- 語源は馬具のハーネスで、モデルの力は変えずに、手綱にあたる仕組みで行き先と止まる場所を決める
- プロンプトエンジニアリングとコンテキストエンジニアリングは1回の指示と材料を良くする話で、ハーネスは繰り返しの運用を安定させる話
- 構成要素は、CLAUDE.md・AGENTS.mdなどのルールのファイル、スキル、フック、MCPなどの道具、権限、人の確認、記録
- 会社が先に決めるのは、任せる範囲・権限・人が確認する工程・記録と見直しの担当の4つ
- 始め方は、ルールを書き出す→確認を仕組みにする→記録して直す、の3段階を1業務から回す
Augueでは、AIエージェントを業務に組み込む開発と、ルールの書き出しや確認の工程づくりを社内で続けられるようにする伴走をご支援しています。自社でAIエージェントを動かすときに権限・確認・記録をどこまで用意するかを整理したい方は、ご興味がある方は是非ご相談ください。
自社専用のAIエージェントを作りませんか?

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。
資料をダウンロードする無料相談に申し込むよくある質問
ハーネスを作るのは社内でできますか、それとも外部に頼むものですか?
分担すれば社内で作れます。任せる範囲、やってはいけない操作、人が確認する条件を言葉で書き出すのは、業務を一番よく知る業務の担当者の仕事です。それをフックやテスト、権限の設定として仕組みに組み込むのはエンジニアの仕事です。社内にエンジニアがいない場合は、最初の1業務だけ外部と一緒に作り、ルールの書き足し方と確認の直し方を社内に移していく進め方が取れます。
ハーネスを整えるのにどれくらいの期間と費用がかかりますか?
一律の目安は出せません。読み取りだけの1業務なら、ルールのファイルと簡単な確認で始められますが、社内システムへ書き込む業務では権限の設計とテストの準備が増えます。見積を比べるときは、任せる業務の数、AIエージェントが書き込む先の数、人が承認する工程の数を数えて伝えると、何にどれだけかかるかを比べやすくなります。
ChatGPTやClaudeを画面で使うだけの会社にも、ハーネスエンジニアリングは関係ありますか?
人が1回ずつ質問して答えを読む使い方なら、人が毎回確認しているので、ハーネスの多くは要りません。社内ルールの入力や、よく使う指示の共有で足ります。関係してくるのは、AIが自分でファイルを書き換える、メールを送る、システムに登録するといった操作を、人が1回ずつ見ずに続けて行う使い方を始めるときです。
ルールのファイルを書き足していくと、長くなりすぎませんか?
長くなります。項目が増えるほど、AIエージェントが一つひとつのルールに注意を向けにくくなり、古いルールと新しいルールが食い違うこともあります。毎回守らせたいことだけをルールのファイルに残し、特定の作業でだけ使う手順はスキルに分け、機械で止められる禁止事項はフックに移すと、ファイルを短く保てます。見直す担当と時期を決めておきます。
関連する記事
AIエージェント開発の進め方|対象業務の選び方と4工程の全体像、次へ進む前に決めることAIエージェント開発を検証で終わらせないための進め方です。対象業務の選び方、4つの工程で次へ進む前に決めること、本番に乗せる判断、運用開始後に続く作業までを、順にたどれる形で整理しました。
AIエージェントにどこまで任せるか|工程を通常のプログラム・AI・人の承認に仕分ける基準ひとつの業務を工程に分け、通常のプログラムで組む部分、AIエージェントに任せる部分、人が承認する部分へ仕分ける基準です。判断の有無、過去例の量、間違えたときの損失、やり直しの可否の4点で判定し、業務別に当てはめます。
AIエージェントの精度をどう評価するか|合格ラインの決め方と、本番に出す前の確認手順AIエージェントを本番に出してよいかを数字で決める手順をまとめます。評価用データの作り方、業務ごとに変わる合格ラインの置き方、誤りの種類別の許容度、人の確認を残したまま測る方法、運用開始後の気づき方まで扱います。
【2026年10月最新】Claude Skillsとは?使い方と作り方Claude Skillsとは、手順や資料をフォルダにまとめてClaudeが必要なときだけ読み込む仕組みです。使い方と作り方、公開仕様のAgent Skills、公式のスキル集、チームでの共有を解説します。
現場が作ったAIエージェントを誰が管理するか|野良AIを増やさない申請・棚卸し・停止の基準現場が自分で作ったAIを把握できなくなる前に、作る前の申請で書かせる項目、台帳に載せる項目、四半期の棚卸しで止める基準、担当者が異動・退職したときの引き継ぎを、情報システム部門と業務側の分担まで含めて整理しました。



