プロンプトが上手いだけでは、AIエージェントは安定して働いてくれません。次の注目キーワード「ハーネスエンジニアリング」を、非エンジニア向けにやさしく解説します。
AIへの指示文（プロンプト）を工夫して、良い答えを引き出す。これが「プロンプトエンジニアリング」です。一つの質問に一つの答えを返してもらうだけなら、これで十分でした。ところが、AIに複数の作業を任せて自律的に進めてもらう「AIエージェント」が広がるにつれて、指示文の工夫だけでは足りない場面が増えてきました。
同じ指示を出しても、任せる環境が整っていなければAIは迷子になり、逆に環境さえ整っていれば、指示はシンプルでも安定して成果を出せます。そこで2026年に入って、海外のAI開発者を中心に急速に使われるようになったのが「ハーネスエンジニアリング（Harness Engineering）」という考え方です。本記事では、その意味と背景、成果への影響、そして中小企業が今日から取り入れられる形までを整理します。
1. 「ハーネス」とは何を指すのか
ハーネス（harness）とは、もともと馬に取り付ける馬具一式のことです。手綱や鞍など、力の強い馬を正しい方向へ安全に導くための道具をまとめてこう呼びます。AIの世界でも意味合いは同じで、AIエージェントという「強い力」を、意図した方向へ安全かつ確実に働かせるための仕組み全体を指します。
この考え方を端的に表すのが、「エージェント＝モデル＋ハーネス」という式です。AIモデルは頭脳にあたり、それ以外のすべて、つまり使える道具、読める情報、守るべきルール、作業の記録、やり直しの仕組みなどがハーネスです。AIの頭脳がどれだけ賢くても、それを取り巻く環境が粗ければ、期待した働きはしてくれません。
身近な例で言えば、Claude CodeやOpenAIのCodexのような、AIに作業を任せるツールそのものが、代表的なハーネスです。同じAIモデルでも、どのツールの中で動かすかによって、できることや仕事の確実さが変わります。
2. 言葉が広まった経緯
「ハーネスエンジニアリング」という言葉が広く使われるようになったのは、2026年2月ごろです。
- ミッチェル・ハシモト氏のブログ（2026年2月5日）：開発ツール企業HashiCorpの共同創業者で、自身のAI活用の歩みを紹介する記事「My AI Adoption Journey」の中で、「AIが間違えるたびに、同じ間違いが二度と起きないよう環境の側を直す」という取り組みを「ハーネスエンジニアリング」と呼んだ
- OpenAIの報告（2026年2月11日）：人がコードを手で書かず、AIエージェントのCodexだけで製品を作った社内実験を「ハーネスエンジニアリング」という題で公開した
- マーティン・ファウラー氏のサイト（2026年2月〜）：ソフトウェア開発の分野で著名な同氏のサイトに、ソートワークスのビルギッタ・ベッケラー氏による解説が掲載された
さらに2026年3月には、AI開発ツールを提供するLangChainのヴィヴェック・トリヴェディ氏が「エージェント＝モデル＋ハーネス」という式でハーネスの構成要素を整理しました。こうして、2026年のAIエージェントを語るうえで欠かせないキーワードになっています。
3. ハーネスを構成する要素
ハーネスは一つの機能ではなく、AIエージェントを取り巻く複数の仕組みの集合体です。
要素 | 決めること | 身近な例 |
|---|---|---|
道具（ツール） | AIが使える機能の範囲 | 検索、ファイル操作、外部サービスとの連携 |
権限 | どこまで任せ、どこから人の承認を必須にするか | 削除や送信の前には確認を求める設定 |
情報（コンテキスト） | AIが判断材料として読める情報の範囲と質 | 社内ルールを書いたファイル（CLAUDE.mdやAGENTS.md）、FAQ資料 |
記録 | 作業の途中経過や判断の根拠をどう残し、引き継ぐか | 作業ログ、変更履歴（Git） |
テストと評価 | 成果物が基準を満たしているかをどう確かめるか | 自動チェック、チェックリスト |
承認とやり直し | 失敗したときの対応と、重要な判断の前に誰が確認するか | 公開前の人の確認、失敗時の再実行 |
これらを個別に整えるのではなく、一つの環境として設計することが「ハーネスエンジニアリング」です。たとえば道具の範囲だけを決めても、失敗したときのやり直しの仕組みがなければ、AIは一度つまずいた作業をそのまま放置してしまいます。逆に承認の流れだけを整えても、判断の根拠となる情報が不十分では、人が確認する意味自体が薄れます。要素同士が噛み合って初めて、AIエージェントは安定して働けるようになります。
4. 同じAIモデルでも、成果が大きく変わる
この考え方が注目される理由は、成果への影響の大きさです。
2025年12月、プリンストン大学の研究者らが運営するAIエージェントの評価サイト（HAL）で、科学論文の結果を再現する課題（CORE-Bench）を解かせたところ、同じAnthropicのモデル（Claude Opus 4.5）でも、汎用の仕組みの中では正答率42%だったのが、Claude Codeの中で動かすと78%まで上がったと報告されています。AIを動かす仕組み（ハーネス）を差し替えただけで、2倍近い差が出たことになります。ただし、別のモデルでは逆に汎用の仕組みのほうが成績がよかったとも報告されており、「どのハーネスが最善か」はモデルとの相性でも変わります。
OpenAIの社内実験では、当初3人（のちに7人）のエンジニアがAIエージェントのCodexを動かし、約5か月で、文書や社内ツールを含め約100万行のコードと、約1,500件の変更提案（プルリクエスト）を生み出しました。人が手でコードを書くことはせず、エンジニアの仕事は、AIが迷わず作業できるように、ルールの文書、自動チェック、作業の手順といった環境を整えることに集中したとされています。
ただし、これらはいずれもソフトウェア開発の分野での、特定の条件下の結果です。どんな業務でも同じ倍率で成果が伸びるわけではありません。それでも、「どのAIを使うか」と同じくらい、「AIをどんな環境で働かせるか」が成果を左右する、という方向性ははっきりしています。
これは実は、経営者やマネージャーが普段から得意としてきた「業務の型を作る」「権限とルールを決める」「進捗を確認する仕組みを作る」という仕事そのものです。プログラミングの知識がなくても、経営の言葉で関われるテーマだと言えます。
5. プロンプト・コンテキスト・ハーネスの違い
考え方 | 何を工夫するか | 向いている場面 |
|---|---|---|
プロンプトエンジニアリング | AIに何をしてほしいかの伝え方 | 一回きりの質問や依頼 |
コンテキストエンジニアリング | 判断に必要な情報を、過不足なく渡すこと | 自社の情報を踏まえた回答 |
ハーネスエンジニアリング | 上の2つを含め、AIが確実・安全に仕事をやり切れる環境全体 | 複数の作業を任せる、繰り返し任せる |
範囲の広さで言えば、プロンプト＜コンテキスト＜ハーネスという関係です。議事録の要約を一回だけ頼むなら、プロンプトの工夫で十分です。しかし「会議のたびに議事録を作り、担当者に確認を依頼し、承認されたら関係者に共有する」という一連の流れを任せるなら、途中経過をどう記録し、誰の承認をどのタイミングで挟むかという設計、つまりハーネスが必要になります。
6. ハーネスが整っていないと何が起きるか
- 権限を広げすぎる：AIに何でも触れる状態を与えると、意図しないファイルの削除や、社外への誤送信といった事故につながる
- 確認の仕組みがない：AIの結果をそのまま採用し、後で誤りに気づいても、どの時点で何を根拠に判断したのかが分からない
- 記録が残らない：やり取りがその場限りで消えると、同じ失敗を繰り返しても学びが積み上がらない
- 間違いを「注意」だけで済ませる：AIが間違えるたびに口頭で注意しても、次の作業では同じ間違いが起きる。ルールの文書や自動チェックとして環境に残さないと直らない
これらはいずれも、AIモデルの性能とは無関係に、周辺の仕組みが整っていないために起きる問題です。モデルを最新のものに乗り換える前に、こうした土台を整えるだけで防げる事故は数多くあります。
7. 中小企業での取り入れ方
たとえば、問い合わせ対応をAIエージェントに任せる場合を考えます。何も設計しないと、AIは過去のやり取りを参照できないまま毎回ゼロから回答し、料金や納期など間違えてはいけない情報まで自信満々に答えてしまう、といったことが起こり得ます。ハーネスの発想を取り入れると、次のように整理できます。
- 道具と情報：参照できるのは「社内のFAQ資料と料金表」だけに限定する
- 承認：金額や契約条件に関わる回答は、送信前に必ず担当者が確認する
- 記録と改善：やり取りを記録し、AIが間違えた回答があれば、FAQ資料やルールの文書を直して次に生かす
最後の「間違えたら環境を直す」が、ハシモト氏の言うハーネスエンジニアリングの核心です。AIの間違いを担当者がその場で手直しして終わりにせず、「なぜ間違えたのか」「資料のどこが足りなかったのか」を考えて仕組みの側を直す。これを繰り返すほど、自社専用の「ハーネス」が育ち、AIの仕事は安定していきます。同じ考え方は、請求書の処理、資料の下書き、在庫データの確認といった他の業務にも応用できます。
8. 今日からできる3つのステップと、よくある誤解
いきなり高度な設計をする必要はありません。
- 任せる内容を書き出す：AIに任せている作業について「何を」「どこまで」「どんな形式で」やってほしいかをメモにする。これ自体が自社のハーネスの土台になる
- 権限を棚卸しする：AIが触れるファイルやサービスの範囲を見直し、金銭・契約・個人情報に関わる操作の前には必ず人の確認を挟む
- 確認と改善の仕組みを決める：成果物を誰が、どんな基準で確認するかを決め、間違いが見つかったらルールの文書に追記する
よくある誤解は、「ハーネスエンジニアリングは専門のエンジニアだけの仕事」というものです。実際に決めているのは、「どこまで任せるか」「誰が確認するか」「何を記録に残すか」といった業務設計そのものです。もう一つは、「良いAIモデルを選べば、仕組みは後回しでよい」という考え方です。同じモデルでも環境次第で成果が大きく変わる以上、モデル選びと同じか、それ以上に環境の設計が重要です。
自社で取り組む際は、一つの業務、一つのAIエージェントに絞って試し、そこで得た型を次の業務へ少しずつ広げていくのが無理のない進め方です。外部の支援を受ける場合も、業務のルールを言葉にしてあるほど、的確な提案を受けやすくなります。
9. まとめ
- ハーネスとは、AIエージェントを意図した方向へ安全に働かせるための周辺の仕組み全体。「エージェント＝モデル＋ハーネス」
- 2026年2月ごろ、ミッチェル・ハシモト氏のブログやOpenAIの報告をきっかけに広まった
- 道具・権限・情報・記録・テスト・承認とやり直しを、一つの環境として設計する
- 同じモデルでも、動かす環境の違いで正答率が42%から78%に上がった例がある
- 核心は「AIが間違えたら、注意ではなく環境を直す」。それを繰り返すほど自社のハーネスが育つ
- 決めることの中身は業務設計そのもの。経営者や現場の担当者こそ関われるテーマ
