ハーネスエンジニアリングとは？｜止まった自動化を直す技術

「半年前に作ったAIの自動実行が、最近は途中で止まって最後まで終わらない」「モデルが新しくなったら賢くなるはずなのに、前より手がかかる」。AIで業務の自動化を進めてきた会社ほど、作ってから1年ほどたったころに聞こえてくる声です。作った直後は毎朝きちんと結果が届いていたのに、ある日から途中で止まる、最後の一手だけやらない、確認の返事を待ったまま朝を迎える。担当者はまずモデルの劣化を疑いますが、たいていの場合、原因はそこではありません。本当は、止まる原因の多くはモデルの性能ではなく、モデルを動かす周りの仕組み（ハーネス）が、モデルの変化や業務の変化に追いついていないことにあります。2026年に入って広まった「ハーネスエンジニアリング」は、まさにこの周りの仕組みを設計し、直す技術を指す言葉です。この記事では、言葉の意味と出どころを本人や提供元の文章で確かめたうえで、放置した自動化が止まる典型、どこが壊れたかの切り分け方、直し方、直した状態を保つ運用までを整理します。

ハーネスエンジニアリングとは、モデルの外側を設計し直す技術

ハーネスは、もともと馬具や安全帯のように、力のあるものをつないで思った方向に動かすための道具を指す言葉です。AIの文脈では、モデルそのものを除いた、エージェントを動かす周りの仕組み全体を指します。ソートワークスのビルギッタ・ベッケラー氏は、マーティン・ファウラー氏のサイトに2026年4月2日に公開した記事で、エージェントはモデルとハーネスの組み合わせであり、ハーネスはモデル以外のすべてであると整理しています。

ハーネスエンジニアリングは、このハーネスを設計し、改良し続ける仕事です。インフラ管理の道具で知られる会社の共同創業者で、現在は端末ソフトの開発を続けるミッチェル・ハシモト氏は、2026年2月5日のブログで、これを「エージェントが間違えるたびに、二度と同じ間違いをしないよう解決策を作り込むこと」と説明しています。モデルに「次は気をつけて」と頼むのではなく、指示のファイルや確かめるための道具を足して、同じ失敗が起きない環境のほうを変えるという考え方です。

似た言葉に、プロンプトエンジニアリングとコンテキストエンジニアリングがあります。前者は1回の指示の書き方、後者はモデルに渡す材料の選び方と並べ方が中心です。ハーネスエンジニアリングはさらに外側にあり、道具・制約・検証・記録・止め方まで含めて、人が見ていない長い時間でも、最後まで正しく走る状態を作ることを目指します。ハーネスを部品に分けた説明はエージェントハーネスとはにまとめているので、この記事では言葉の出どころと、止まった自動化を直す実務に絞ります。

言葉が広まったのは2026年の前半

「ハーネス」という語そのものは、以前から開発者の間で使われていました。アンソロピックは2025年11月26日、自社のエンジニアリングブログに、長い時間動くエージェントのための効果的なハーネスについての記事を公開しています。何回にも分けて作業するエージェントが、途中で迷ったり早まって作業を終えたりしないための工夫を、自社のクロードを使った開発の例で紹介したものです。

「ハーネスエンジニアリング」という名前で語られるようになったのは2026年に入ってからです。2月5日にハシモト氏がAI活用の歩みを6段階で振り返るブログを公開し、その5段階目に「ハーネスを設計する」を置きました。本人は、業界で定着した呼び名があるかは分からない、あればそれに乗る、と書いており、自分の造語だとは主張していません。同じ2月には、オープンエーアイが公式ブログで、コーデックスにコードを書かせて社内向けの製品を作った経験を「ハーネスエンジニアリング」と題して公開し、言葉が一気に広まりました。

4月にはベッケラー氏の記事が、ハーネスの要素を「動く前に導くもの」と「動いた後に確かめるもの」に分けて整理しました。言葉が生まれたのは開発の現場ですが、中身は開発に限りません。業務の自動実行やエージェントを社内で回している会社なら、どこでも同じ問題に当たります。この記事では、非エンジニアの部門で作った自動化にも当てはめて考えます。

放置した自動化に、この考え方が効く理由

業務の自動化は、作った日がいちばん調子の良い日になりがちです。作った人が、その日のモデルに合わせて指示を書き、その日の道具とつなぎ、その日の業務の流れで動作を確かめているからです。ところが、モデル・道具・業務の3つは、作った後も動き続けます。モデルは提供元の都合で新しい版に入れ替わり、つないでいる外部のサービスは仕様や認証の方式を変え、業務の側も書式や担当や締め日が変わります。

周りの仕組みがこの変化に追いつかないと、自動化は少しずつずれていきます。最初は出力が少し変わる程度で、誰も気づきません。やがて途中で止まる日が出始め、最後には毎回最後まで走らなくなります。止まった時点で直そうとしても、どこからずれ始めたのかを誰も覚えていないのが、放置した自動化のいちばん厄介なところです。作った人が異動していれば、なおさら手がかりがありません。

ここで、新しいモデルを待つ、あるいは別のモデルに乗り換えるという判断をすると、遠回りになることがあります。モデルを替えれば、指示の受け取り方がまた変わるからです。ハーネスエンジニアリングの考え方では、先に周りの仕組みを点検し、モデルを替えずに直せるところから直します。次の節から、止まり方の典型を3つに分けて見ていきます。

止まる典型①：モデルの版が変わり、指示の効き方がずれる

いちばん気づきにくいのが、モデルの版が上がって指示の受け取り方が変わるケースです。クロードの公式ドキュメントにあるプロンプトの手引きは、モデルごとの振る舞いの違いを一覧にしており、一部の新しいモデルについて、指示を文字どおりに受け取る傾向を項目として挙げています。以前のモデルが暗黙に補ってくれていた手順を、新しいモデルは書かれていなければやらないということが起こり得ます。

逆向きのずれもあります。同じ手引きは、以前のモデルで道具を使わせるために入れていた強い言い回しが、新しいモデルでは効きすぎることがあると注意しており、言い回しを和らげるよう勧めています。「必ず使え」「迷ったら使え」と書いた指示に新しい版が過剰に反応し、不要な確認や作業を重ねて時間切れになる。「前より手がかかる」という声の正体の1つはこれです。

どちらの場合も、モデルが劣化したわけではありません。指示が、特定の版のくせを前提に書かれていたことが原因です。指示の文面が、古いモデルの補い方に頼っていたので、版が変わると前提が崩れます。更新の告知の拾い方や、版が変わったときの検査の組み方はモデル更新で業務を止めない方法に譲り、ここでは止まった後にどう直すかを中心に扱います。

止まる典型②：道具やつなぎ先の変化と、人の確認待ち

業務の自動化は、表計算のファイル、社内のチャット、顧客管理の仕組み、外部の情報源などにつながって動きます。つなぎ先の仕様が変わったり、ログインの期限が切れたりすると、エージェントは道具を呼んでも失敗が返ってくるだけになります。変更の頻度も告知の出し方も提供元ごとに違うため一概には言えませんが、作ってから半年以上たった自動化では、つなぎ先の変化で止まることが起きやすいと考えておくのが安全です。

やっかいなのは、失敗の返り方が分かりにくい場合です。道具がはっきりした失敗を返せば処理が止まって気づけますが、空の結果を返すと、エージェントは「該当なし」として先に進むことがあります。たとえば検索先の認証が切れて0件が返り、「新しい問い合わせはありませんでした」という報告が毎朝届き続ける、という形です。止まらずに間違えるほうが、止まるよりも発見が遅れます。

もう1つ多いのが、人の確認待ちで止まるケースです。ファイルの削除や外部への送信など、影響の大きい操作の前に人の承認を求める設定は、安全のために欠かせません。ところが無人で回す自動化でこの確認が出ると、返事をする人がいないまま朝まで待ち続けます。作った当時は確認の出ない操作だけで組んでいたのに、業務の変化で手順が増え、確認の出る操作が途中に混ざった、という形で起きやすくなります。

止まる典型③：文脈がふくらむ、終わりの判定がない、記録がない

長い作業では、モデルに渡す文脈がふくらみます。上限に近づくと古いやり取りが要約されたり捨てられたりするため、最初に渡した条件が後半で抜け落ちることがあります。扱う件数が作った当時より増えた自動化では、同じ指示でも文脈が長くなり、以前は起きなかった取りこぼしが後半の件だけに出る、ということが起きやすくなります。

終わりの判定がないのも典型です。アンソロピックの長時間エージェントの記事は、後から作業を引き継いだエージェントが、ある程度進んでいる様子を見て作業が終わったと宣言してしまう失敗を挙げています。何をもって完了とするかが書かれていないと、エージェントは途中で「終わりました」と報告することがあるわけです。人が結果を開いて初めて、半分しか処理されていないと分かります。

記録がないと、止まった後に困ります。どこまで進んだか、どの件で失敗したかが残っていなければ、最初からやり直すしかありません。送信や登録のように二度やると困る操作が混ざっていれば、やり直しそのものが事故になります。やり直す範囲の決め方と二重実行の防ぎ方はやり直す範囲の決め方で扱っています。

症状から、疑う場所に当たりをつける

止まった自動化を前にして、いきなり指示を書き換え始めると、原因と関係のない所を直してしまいがちです。まずは症状から、器のどこを疑うかに当たりをつけます。下の表は、放置した自動化でよく見る症状と、最初に疑う場所、最初に確かめるものの対応です。

症状	まず疑う場所	最初に確かめるもの
途中で止まり、失敗の表示が出ている	道具・つなぎ先・認証	失敗した道具の呼び出しと、返ってきた内容
失敗の表示はないのに、朝になっても終わっていない	人の確認待ち・止める条件	最後に出た承認の要求と、その操作の中身
「完了しました」と言うのに件数が足りない	完了の判定	完了条件の書き方と、実際に処理した件数
以前は補っていた手順を飛ばす	指示文書（版の変化）	版が変わった時期と、飛ばした手順が指示に書かれているか
確認や作業を重ねて時間切れになる	指示文書の強い言い回し	「必ず」「迷ったら」など、効きすぎる文言
後半の件だけ条件が守られない	文脈の長さ	処理件数の推移と、条件を書いた位置
毎回0件・該当なしの報告が続く	道具の失敗の返り方	道具を単体で呼んだときの結果
止まった後、どこから再開すればよいか分からない	記録	途中経過を残す場所と、残している項目

表はあくまで最初の当たりです。1つの症状に原因が2つ重なっていることもあります。たとえば「完了と言うのに件数が足りない」は、完了の判定がないことに加えて、後半で条件が抜け落ちていることが重なっていたりします。当たりをつけたら、次の手順で1か所ずつ確かめます。

切り分けの手順：止まった地点から器のどこかを特定する

切り分けは、記録を起点に4つの手順で進めます。どの手順も、作った本人でなくても進められるように、確かめた内容を1行ずつ書き残しながら進めるのがこつです。

切り分けでよくある回り道は、手順2を飛ばしてモデルを替えることです。道具の認証切れのような器の問題は、どのモデルに替えても直りません。先に道具を単体で確かめるだけで、半日の作業が数分で終わることもあります。

直し方①：手順ではなく、完了の条件と確かめ方で書き直す

指示を直すとき、飛ばされた手順を書き足すだけでは、次の版でまた別の手順が飛ばされます。書くべきは手順の羅列ではなく、何ができていれば完了か、それをどう確かめるかです。アンソロピックの記事では、作るべき機能を一覧のファイルにまとめ、それぞれに合格したかどうかの印を持たせることで、早すぎる完了宣言を防いだと紹介しています。モデルが勝手に書き換えにくい、決まった形式のファイルをわざわざ選んだことも書かれています。

ハシモト氏は、自分のプロジェクトのエージェント向け指示ファイルについて、各行が過去のエージェントの悪い振る舞い1つずつに対応しており、それでほぼすべてが解消したと書いています。一方、オープンエーアイの公式ブログでも、指示文書を分厚い手引き書にするのではなく、どこに何があるかを示す地図として短く保つ考え方が紹介されています。2つを合わせると、失敗から1行ずつ足し、全体は短く保つのが指示文書の直し方の基本です。

• 飛ばされた手順を、指示の末尾に書き足していくだけで済ませる
• 「必ず」「絶対に」を増やして従わせようとする（新しい版では効きすぎて時間切れの原因になる）
• 止まった件だけを手で片付け、指示も器も直さない
• 完了の条件を「すべて処理する」とだけ書き、確かめ方を書かない

書き直した指示は、作った人以外が読んで同じ判断ができるかで確かめます。読んだ人が「この場合はどうするのか」と迷う箇所は、モデルも迷う箇所です。人が読んで分からない指示は、版が変わったときに真っ先に壊れます。

直し方②：確かめる仕事を機械に回す

ベッケラー氏は、ハーネスの要素を、動く前に導く「ガイド」と、動いた後に観察して自分で直させる「センサー」に分けています。さらにそれぞれを、テストや形式の検査のように計算で決まる速く確実なものと、AIの推論で意味まで判定する遅いが細かく見られるものに分けています。止まった自動化の多くは、このセンサーが欠けているか、作った当時のまま古くなっています。

業務の自動化に置き換えると、計算で確かめられるものは機械に任せます。処理した件数が入力の件数と一致するか、必須の列が空になっていないか、日付や金額の形式が正しいか、送信先が許可した一覧に入っているか。こうした検査を自動化の最後に置けば、「終わりました」という報告ではなく、検査を通ったかどうかで完了を判定できるようになります。前の節の完了の条件と、この検査を対にしておくのが要点です。

要約が原文の趣旨とずれていないか、といった意味の判断はAIに判定させることもできますが、作業したAI自身に自分の出力を採点させてはいけません。同じ思い込みで作業し、同じ思い込みで採点するからです。直した後に関係のない所が壊れていないかを確かめる手順は、回帰テストの記事で扱っています。

直し方③：途中経過をファイルに残し、途中から再開できるようにする

クロードの公式ドキュメントは、複数の文脈にまたがる長い作業について、テストの状態を決まった形式のファイルで管理し、進み具合を自由記述のメモに残し、変更履歴の管理の仕組みで何をしたかを追えるようにすることを勧めています。新しい文脈で始め直すときは、これらを読み返してから再開するよう指示する例も載っています。会話の中ではなく、会話の外に状態を置くという考え方です。

業務の自動化でいえば、たとえば「処理した件の一覧」「失敗した件と理由」「次に再開する位置」の3つを、自動化の外のファイルに残します。会話の中にだけ残すと、文脈が要約されたり途中で切れたりした時点で消えます。外に残しておけば、止まった後も途中から再開でき、切り分けの手順1で必要な記録にもなります。

送信や登録のように二度やると困る操作は、実行したら記録に「済み」を書いてから次へ進む順番にします。順番が逆だと、操作の直後に止まったとき、済んだかどうかが分からなくなります。記録には顧客名や社内の数字が混ざることも多いため、どこまで残すかと保存期間は、残し始める前に決めておきます。

直し方④：権限と止める条件を書き、版を固定するか追うかを決める

無人で回す自動化には、使ってよい道具と操作の範囲を先に絞って与えます。確認待ちで止まる問題は、確認を外して解決するのではなく、無人の時間帯にやってよい操作だけに範囲を絞ることで解決します。外部への送信や削除のように影響の大きい操作は無人の流れから外し、下書きまで作って人の承認を待つ形に組み替えます。

止める条件も書きます。失敗が何回続いたら止めるか、処理時間がどれだけ延びたら止めるか、止めたら誰にどこで知らせるか。止める条件がない自動化は、失敗しても回り続けて同じ失敗を重ねるか、確認待ちのまま黙って止まるかのどちらかになります。止まったことに翌朝ではなく数十分で気づける形にしておくと、被害の範囲も切り分けの手間も小さくなります。

最後に、モデルの版の扱いを決めます。提供元が版を指定して呼べる場合、版を固定すれば突然の変化は避けられますが、古い版はいずれ提供が終わり、そのときにまとめて直すことになります。最新を追う場合は、版が変わるたびに短い検査を回します。どちらが正しいかではなく、どちらにしたかを決めて記録に残しておくことが大切です。決めていないと、変わったことにすら気づけません。

直した状態を保つ：版が変わったら回す検査と、持ち主

直した自動化も、放っておけばまた止まります。保つための仕組みは2つです。1つは、モデルの版や道具が変わったとき、業務の書式が変わったときに回す短い検査です。過去に止まった入力や、業務の中で典型的な入力を数件から十数件そろえておき、変わるたびに流して完了の条件を満たすかを確かめます。ベッケラー氏の記事も、ハーネスが育つにつれて導く仕組みと確かめる仕組みの整合を保つことは、一度きりの設定ではなく継続的な仕事だと書いています。

もう1つは、持ち主を決めることです。持ち主の仕事は、自分で全部を直すことではなく、検査の結果を見て、止めるか直すかを決めることです。作った人が異動しても、指示文書・検査・記録の3つが残っていれば、次の持ち主が引き継げます。逆に、この3つが作った人の頭の中にしかない自動化は、異動した日から放置が始まります。

社内に持ち主を置けない、置いても直せる人がいない、という会社もあるはずです。その場合は、止まった自動化を業務と一緒に外部の伴走チームに見てもらい、器から作り直す方法もあり、デボノのAI推進BPOでもこうした相談を受けています。

• 自動化ごとに持ち主が1人決まっている
• 指示文書・検査用の入力・実行の記録が、作った人の手元以外に置かれている
• モデルの版を固定するか追うかが決まり、記録に残っている
• 版や道具や業務の書式が変わったときに回す検査がある
• 止める条件と、止まったときの知らせ先が書かれている

人が決める3つの線と、AIに採点させない理由

ハーネスをどれだけ作り込んでも、人が決めなければならないことは残ります。止まった自動化を直すときに、あらためて人が決め直す線は次の3つです。

1. 何を自動に任せるか（業務の変化で、任せてよい範囲が変わっていないか）
2. 止める条件と、人に戻す線（どの失敗で止め、どの判断を人に戻すか）
3. 結果を確かめる人（誰が、どの頻度で、何を見て合格とするか）

ベッケラー氏は、良いハーネスは人の関与をなくすことを目指すのではなく、人の関与が最も重要なところへ向けるものだと書いています。この3つがまさにその「最も重要なところ」です。アンソロピックの記事にある早すぎる完了宣言の例が示すとおり、作業したエージェント自身の「終わった」は、完了の証拠になりません。

一方で、AIに任せてよい仕事もあります。長い実行の記録を読んで止まった地点の候補を挙げる、原因の候補を並べる、指示文書の書き直し案を下書きする、といった作業です。ただし、候補には必ず記録のどの行を根拠にしたかを書かせ、採否は人が決めます。根拠のない原因の推測をそのまま直しに使わないことが、切り分けを早く終わらせるいちばんの近道です。

よくある質問

ハーネスエンジニアリングは、エンジニアでないと関係ありませんか

関係があります。言葉は開発の現場で生まれましたが、指示・道具・確認・止め方・記録で自動化を支えるという考え方は、部門で作った定期実行やエージェントにもそのまま当てはまります。コードを書けなくても、完了の条件を書く、止める条件を決める、記録を残す場所を決めることはできます。

モデルを最新の版に替えれば直るのではありませんか

直ることもありますが、止まった原因が道具の認証切れや確認待ち、完了の判定がないことであれば、版を替えても直りません。版を替えると指示の受け取り方がまた変わるため、かえって別の箇所が止まることもあります。先に切り分けの手順で器を確かめてから判断します。

どのくらいの頻度で点検すればよいですか

決まった周期よりも、きっかけで点検するほうが確実です。モデルの版が変わったとき、つなぎ先の道具の仕様変更の告知が出たとき、業務の書式や担当が変わったときに、短い検査を回します。きっかけがなくても、少なくとも四半期に1回は持ち主が結果を見る、と決めておくと放置を防げます。

作った人が辞めていて、指示の意図が分かりません。どうすればよいですか

まず記録を残す形にして1回走らせ、止まった地点を特定します。指示文書は全部を読み解こうとせず、完了の条件と確かめ方が書かれているかだけを見ます。書かれていなければ、今の業務の担当者と一緒に完了の条件を書き起こし、それに合わせて指示を短く書き直すほうが、元の意図を推測するより早く終わります。

直すのと作り直すのは、どちらがよいですか

切り分けの結果、原因が1〜2か所に収まるなら直します。指示文書・完了の判定・記録のすべてが欠けている、業務の流れ自体が作った当時と大きく変わっている、という場合は、その業務を今の形で見直してから作り直したほうが、結果的に早く安定します。どちらにするかは、業務の持ち主が決めます。

直す人が社内にいないときの選択肢

ここまでの切り分けと直し方は、社内に持ち主と時間があれば進められます。ただ実際には、自動化を作った人が異動した、直す時間が取れない、どこから手を付けてよいか分からない、という理由で、止まったまま置かれている自動化も少なくありません。止めたままにする判断も1つの選択ですが、業務に必要な仕組みであれば、直す力を外から借りる方法もあります。

外に頼む場合も、器を直すだけでは足りません。止まった理由が業務の変化にあるなら、業務の側を一緒に見直さないと、同じ所でまた止まります。相談だけで終わる支援でも、仕様を固めてからの本番開発でもなく、業務を見ながら作って直す伴走の形が合う場面です。

まとめ

ハーネスエンジニアリングは、モデルの外側にある指示・道具・確認・止め方・記録を設計し、エージェントが最後まで正しく走るようにする考え方で、2026年の前半に広まりました。放置した自動化が止まるのは、多くの場合モデルが悪くなったからではなく、モデルの版や道具や業務が変わったのに、周りの仕組みが作ったときのままだからです。症状から疑う場所に当たりをつけ、記録から止まった地点を特定し、器のどこが原因かを1か所ずつ確かめて直します。直すときは、手順を足すのではなく完了の条件と確かめ方を書き、確かめる仕事を機械に回し、途中経過を外に残し、権限と止める条件を決めます。そのうえで、版が変わったら回す検査と持ち主を置けば、直した状態を保てるようになります。何を自動に任せるか、止める条件と人に戻す線、結果を確かめる人は人が決め、作業したAI自身に採点させないことも忘れずに。まずは止まっている自動化を1つ選び、止まった手順の道具を単体で呼んでみるところから始めてください。

• 言葉の出どころと定義は、ミッチェル・ハシモト氏のブログ（2026年2月5日）、アンソロピックのエンジニアリングブログ（2025年11月26日）、マーティン・ファウラー氏のサイトに掲載されたビルギッタ・ベッケラー氏の記事（2026年4月2日）、オープンエーアイの公式ブログ（2026年2月）を、2026年10月6日に確かめた範囲に基づきます
• モデルごとの指示の受け取り方の違いと、長い作業での状態の残し方は、クロードの公式ドキュメントのプロンプトの手引き（2026年10月時点）に基づきます。振る舞いは版によって変わるため、使っている版の公式の説明を確かめてください
• 止まり方の典型・切り分けの手順・点検のきっかけは、自動化を運用するときの考え方の一例です。実際の運用は、自社の規程と情報システム部門の判断に従ってください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。