AIエージェントのハーネスとは｜モデル以外のすべてを指す実行基盤
AIエージェントのハーネスとは、AIモデルを実際に働かせるためにモデルの周囲に置く実行基盤のことです。モデルはそのままでは文章を返すだけで、ファイルを開くことも、作業の途中経過を覚えておくことも、次に何をするかを決め続けることもできません。ハーネスは、その「モデル単体ではできないこと」を肩代わりする部品の集まりで、ツールの呼び出し、状態の保存、実行の隔離、権限の制御などを含みます。
「エージェント＝モデル＋ハーネス」という考え方
2026 年に入って各社が同じ定式を使い始めました。LangChain は 2026 年 3 月の解説で「モデル単体はエージェントではなく、ハーネスが状態・ツール実行・フィードバックループ・守らせる制約を与えたときにエージェントになる」と説明し、モデル以外のコード・設定・実行ロジックのすべてをハーネスと定義しています（LangChain の解説）。
Microsoft も Agent Framework の公式ドキュメントで、ハーネスを「言語モデルを、仕事をこなせるエージェントに変える実行時の足場」と位置づけ、モデル呼び出しとツール呼び出しの駆動、会話状態の管理、承認ポリシーの適用、複数ステップの前進を役割に挙げています（Microsoft Learn）。
つまり「賢いモデルを選ぶ」ことと「そのモデルに仕事をさせる仕組みを作る」ことは別の作業です。前者はベンダーの領域、後者は導入する側の領域で、後者の出来がエージェントの安定性を左右します。
関連記事：Claude Codeとは？できること・料金・使い方と社内導入の判断軸
馬具に由来する言葉と、テストハーネスとの関係
ハーネスは馬具の意味で、手綱と鞍にあたります。どれほど優秀な馬でも、手綱がなければ行きたい方向へは走りません。ソフトウェアの世界では以前から、テスト対象を固定して自動で実行する「テストハーネス」という言葉があり、AIエージェントのハーネスもこの語感を引き継いでいます。対象を固定し、決まった手順で安定して動かす装置、という意味です。
内側のハーネスと外側のハーネス
ハーネスという言葉は 2 つのスコープで使われます。1 つはモデル提供者や開発ツール側が作り込む「内側のハーネス」で、Claude Code や Codex のようなコーディングエージェント本体に組み込まれた実行系がこれにあたります。もう 1 つは利用者側が用意する「外側のハーネス」で、指示を書いたルールファイル、接続する MCP（Model Context Protocol、AIとツールをつなぐ共通規格）サーバー、カスタムスキルなどです。
Thoughtworks の Birgitta Böckeler 氏はこの 2 つを分けたうえで、行動前に導く「ガイド」と、結果を観測して自己修正させる「センサー」という役割の違いも整理しています。事業会社が主に設計するのは外側のハーネスで、本記事もそこを中心に扱います。
関連記事：MCPとは？Model Context Protocolの仕組みとAPIとの違いを整理
なぜ今、AIエージェントにハーネスが必要なのか
理由は 2 つあります。1 つは、モデルが賢くなっても「業務を最後までやり切る」段階でつまずく企業が多いこと、もう 1 つは、ハーネスの出来がモデルの差より成果に効くという実測が積み上がってきたことです。
チャット止まりから抜けられない企業が約 7 割
GiftX が実施した「ビジネス職生成AI活用実態調査2026」では、AI利用者のうち都度チャットで質問や成果物作成をしている層（チャット止まり）が 70.3%、AIエージェントが複数工程を半自動から自動で進める段階（AIエージェント化）に達している層は 10.5% でした。一方で、生産性が「明確に上がった」と答えた割合は、チャット止まりの 14.3% に対して AIエージェント化した層では 54.3% と、約 3.8 倍の開きがあります。
| 活用の段階 | 割合 | 生産性が明確に上がった割合 |
|---|---|---|
| チャット止まり（L1+L2） | 70.3% | 14.3% |
| 業務手順を覚えさせ繰り返し実行（L3） | 19.3% | 19.4% |
| AIエージェント化（L4） | 10.5% | 54.3% |
この差を生むのは、モデルの賢さではなく「業務手順を覚えさせて繰り返し同じ品質で動かす」仕組みです。それがハーネスの仕事にあたります。個人の課題として「チャット相談止まりで自動化に進めない」を挙げた人も 25.7% おり、モデルを使えている人ほど次の壁がハーネスになっています。詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。
ハーネスの差がモデルの差より成果に効く
OpenAI は 2026 年 2 月、3 人のエンジニアが約 5 か月で約 100 万行のコードを Codex に生成させ、人間が書いたコードはゼロ行だったという実験を公開しました（出典: openai.com）。Anthropic も長時間動くエージェントの設計ガイドで、生成する役と評価する役を別のエージェントに分けたほうが、自己評価させるより成果が安定すると報告しています（出典: anthropic.com）。
NVIDIA Labs の研究チームは 2026 年 7 月、モデルを固定したままハーネス側の 6 つの能力を設計し直し、SWE-bench Verified で 82.2% を達成したと公表しました。比較対象のハーネスは同じモデルで 78.2% と 78.6% で、使ったトークンと呼び出し回数はおよそ半分です（NVIDIA の技術記事）。
ハーネスでできること｜構成要素と役割
各社の説明を重ねると、ハーネスの中身は次の 7 つに収束します。自社のエージェントが不安定なとき、どこが欠けているかを見る点検表として使えます。上から順に「指示」「手足」「反復」「記憶」「情報量」「安全」「確認」の役割を担っており、どれか 1 つが抜けると、そこがエージェントの止まる場所になります。
- システムプロンプトとルールファイル：役割、行動方針、守るべき規約を文書で渡す部分です。コーディングエージェントでは AGENTS.md や CLAUDE.md といったファイルに書き、新入社員が初日に受け取る手順書の役割を果たします
- ツールとコード実行：ウェブ検索、ファイル操作、データベース照会、コマンド実行などをモデルが呼び出せるようにする部分です。あらかじめ用意した機能に限定する設計と、汎用のコード実行を許す設計があります
- エージェントループ：作業を実行し、結果を確認し、次の行動を決める、という流れを繰り返す仕組みです。何回まで繰り返すか、どこで止めるかもここで決めます
- メモリと状態の保存：会話の文脈を超えて情報を持ち越す部分です。ファイルシステムに作業状態を書き出し、次のセッションで読み直す方法が一般的です
- コンテキスト管理：モデルに見せる情報量を制御する部分です。長くなった履歴を要約する圧縮、大きな出力をファイルに逃がす退避、必要になるまでツール説明を見せない段階的開示などが含まれます
- サンドボックスとガードレール：隔離された環境で実行し、権限の範囲、人の承認が要る操作、禁止する操作を決める部分です。安全性を担う層です
- 検証とフィードバック：テスト、静的解析、評価用エージェントなどで出力を確認し、失敗したら自分で直す流れを組み込む部分です。実行ログを残して後から追えるようにする可視化もここに入ります
Microsoft の Agent Framework では、これらのうち関数呼び出し、Todo による計画管理、ツール承認、実行ログの記録などが既定で有効になっており、利用者は必要な能力だけを足し引きする形になっています（Microsoft Learn）。NVIDIA Labs が挙げた 6 つの能力も、型付きの入出力、参照渡し、コードによる行動、書き換え可能なループ、明示的な状態、モデルが読めるハーネス API と、上の 7 要素のどれかに対応します。構成要素の呼び名はベンダーごとに違っても、中身は同じ集合を指しています。
点検するときは、まずルールと検証が文書として存在するかを見て、次にループの停止条件と権限の境界が決まっているかを確認し、最後にメモリとコンテキスト管理を見る順番が効率的です。前の 2 つが無いエージェントは、後の要素をいくら足しても安定しません。
関連記事：Codex Sandbox（サンドボックス）とは？3つのモードと安全な設定方法
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
ハーネスの使い方・始め方｜ハーネスエンジニアリングの 4 ステップ
ハーネスエンジニアリングとは、モデルの外側にある環境・制約・フィードバックを設計して、エージェントの動作を安定させる取り組みです。エンジニアでなくても、次の 4 ステップは順に進められます。1 業務を選んで、上から順に一周させることを目標にしてください。
ステップ1｜守らせたいルールを文書にする
最初にやるのは、エージェントに守らせたいことを自然言語で書き出すことです。使ってよいツール、触ってはいけないデータ、成果物の形式、過去に起きた失敗と再発防止策を 1 つのファイルにまとめます。コーディングエージェントなら AGENTS.md や CLAUDE.md がその置き場で、業務用のエージェントなら業務手順書がそのまま出発点になります。書き方に正解はありませんが、「何をしてはいけないか」を先に書くと安定しやすくなります。たとえば「顧客名は外部サービスに送らない」「数値は出典が確認できたものだけ書く」「判断に迷ったら作業を止めて人に聞く」のように、1 行ずつ具体的な動作で書くと、モデルが解釈を誤る余地が減ります。
関連記事：AGENTS.mdとは？Codexにプロジェクト規約を守らせる設定と書き方
ステップ2｜結果を機械で確かめる仕組みを置く
次に、エージェントの出力を人が読む前に機械で確かめる関門を作ります。コードならテストと静的解析、文書なら文字数や必須項目のチェックリストが該当します。ここで大切なのは、判定基準を「機械で判定できる形」に落とすことです。「読みやすいか」ではなく「1 文が 60 字以内か」「必須の見出しが揃っているか」のように書き換えると、エージェント自身が確認して直せるようになります。最初は 5 項目程度の短いチェックリストで十分です。人がレビューで毎回指摘している点を書き出せば、それがそのまま最初の判定基準になります。判定できない基準を無理に機械化する必要はなく、そこは人の最終確認に残しておきます。
ステップ3｜作る役と評価する役を分ける
1 つのエージェントに作らせて自己評価させると、自分の間違いに甘くなりがちです。Anthropic は長時間動くエージェントの設計で、生成する側と評価する側を別のエージェントに分ける構成を推奨しています（出典: anthropic.com）。評価役には、ステップ2 で作った判定基準を渡し、通らなければ差し戻す流れにします。評価役は同じモデルで構いません。役割と手元の情報を分けることで、作った本人が見落とす誤りを拾えるようになるのが狙いです。差し戻しの回数に上限を置き、何回直しても通らないものは人に回すルールも同時に決めておきます。
関連記事：Codexのサブエージェントとは｜使い方・TOML設定・活用例を解説
ステップ4｜失敗を規則に変えて積み上げる
運用を始めると必ず失敗が出ます。そのたびに「同じ失敗を二度と起こさない規則」をステップ1 のファイルに書き足していくのがハーネスエンジニアリングの中核です。HashiCorp 共同創業者の Mitchell Hashimoto 氏が 2026 年 2 月のブログで示した、ミスのたびに恒久的な修正を環境側へ組み込む実践は、この考え方の原点の 1 つとされています。規則が 20 行、30 行と増えていくほど、エージェントは同じ品質で動く範囲を広げていきます。モデルを替える前に、この 4 ステップを 1 業務で回してみるのが最短の始め方です。設計の 6 原則と実例は「AIエージェントの作り方と育て方」にまとめています。
関連記事：Codex Skills とは？AIに業務手順を覚えさせる仕組みと使い方を解説
ハーネスにかかる費用｜主なハーネスの提供形態と料金の考え方
ハーネスそのものは無料で使えるものが多く、費用の中心はモデルの利用料と運用の工数です。主なハーネスの提供形態を整理します（2026 年 9 月時点、出典: github.com / microsoft.com / openai.com / claude.com）。
| ハーネス | 提供元 | 提供形態 | ハーネス自体の料金 |
|---|---|---|---|
| DeepSeek Harness | DeepSeek | オープンソース（MIT ライセンス・開発者プレビュー） | 無料。モデルの API 利用料は別 |
| Agent Framework の Harness | Microsoft | オープンソースのフレームワークに同梱 | 無料。接続するモデルの利用料は別 |
| Codex | OpenAI | ChatGPT の有料プランまたは API に付属 | プラン料金または API 利用料に含まれる |
| Claude Code | Anthropic | Claude の有料プランまたは API に付属 | プラン料金または API 利用料に含まれる |
| 自社で組むハーネス | 利用企業 | ルールファイル・スクリプト・MCP サーバーの組み合わせ | 開発と運用の人件費 |
表のとおり、ハーネスの利用料がボトルネックになることはほとんどありません。費用を見積もるときは、ハーネスの導入費ではなく、1 回の業務でエージェントがモデルを何回呼び、何トークン使うかを先に測るのが実務的な順番です。実際にかかるのは、エージェントが繰り返し呼び出すモデルのトークン料金と、ルールを書き、検証を作り、失敗を規則に変え続ける人の時間です。NVIDIA Labs の例のように、ハーネスの設計次第で同じ成果を約半分のトークンで出せることもあるため、ハーネスはコストを増やす要素ではなく、モデル利用料を抑える要素として見るのが妥当です。オープンソースのハーネスの中身と料金の見方は、DeepSeek Harness の解説記事で個別に整理しています。
プロンプトエンジニアリング・コンテキストエンジニアリング・スキャフォールディングとの違い
ハーネスは、これまで使われてきた 3 つの言葉と重なりながら範囲が違います。共通しているのは「モデルを変えずに成果を変える」という狙いで、違うのは扱う範囲と、その仕組みを恒久的に持つかどうかです。下表は、対象・範囲・作る人・寿命の 4 観点で 4 つを並べたものです。読者がどの言葉で語られている施策なのかを見分けるときの基準に使えます。
| 観点 | ハーネス | プロンプトエンジニアリング | コンテキストエンジニアリング | スキャフォールディング |
|---|---|---|---|---|
| 対象 | モデル以外の実行環境全体 | 1 回の指示文 | モデルに見せる情報の集合 | モデルの弱点を補う一時的な足場 |
| 範囲 | ツール・状態・権限・検証を含む | 指示の書き方 | 履歴の要約・検索・取捨選択 | 当時のモデルにできない処理の代替 |
| 主に作る人 | 導入企業と開発ツール提供者 | 利用者個人 | エージェント開発者 | 研究者・開発者 |
| 寿命 | 恒久的に持ち続ける層 | 都度書き換える | モデルの性能に応じて調整 | モデルが賢くなれば外す前提 |
たとえばプロンプトエンジニアリングは 1 回の対話を最適化する作業で、コンテキストエンジニアリングはモデルに何を見せるかを統制する作業です。ハーネスはその両方を部品として含む、より広い運用の層になります。スキャフォールディング（足場）は「モデルが賢くなれば外す仮設物」という含みがあるのに対し、ハーネスは「モデルが持ち続ける恒久的な層」という含みで使われるようになり、この言い換えが開発予算の配分を変えたという解説もあります。
関連記事：AIプロンプトとは？回答精度を高める書き方のコツと業務で使える例文集
全国8,000人調査で、AIの活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
モデルが進化すればハーネスは不要になるのか
よくある疑問ですが、答えは「一部は不要になり、全体はなくならない」です。Anthropic は設計ガイドの中で、ハーネスの各部品は「モデルが単独ではできないこと」についての仮定を含んでおり、その仮定はモデルの進化で古くなるため、能力向上に合わせて前提を取り除くべきだと述べています（出典: anthropic.com）。一方で LangChain は、モデルの学習自体がハーネスと組み合わせて行われる共進化が進んでも、プロンプトエンジニアリングが残ったのと同じようにハーネスエンジニアリングは有用であり続けると見ています（LangChain の解説）。権限の境界、承認の流れ、業務固有のルールは、モデルがどれほど賢くなっても導入する側にしか決められないからです。
ハーネス設計の注意点
ハーネスは足せば足すほど良いものではありません。設計を始める前に、次の 4 点を押さえておくと手戻りが減ります。
前提が古くなることを織り込む
ハーネスの部品は「今のモデルにはこれができない」という前提の上に作られます。前提が古くなった部品は、新しいモデルの足を引っ張る側に回ります。Anthropic はこれを避けるために、モデルが既に知っているツールの上に構築し、能力の向上に合わせて前提を削り、体験・コスト・安全性の境界だけを慎重に決める、という 3 つの指針を示しています（出典: anthropic.com）。四半期に一度は「この規則はまだ要るか」を見直す前提で作るのが安全です。
ベンダーの言う「ハーネス」と自社の「ハーネス」を混同しない
前述のとおり、ハーネスには開発ツール側の内側のハーネスと、利用者側の外側のハーネスがあります。ベンダーの解説記事が指しているのが内側の話なのに、自社の運用に当てはめようとしてかみ合わないケースが起きています。自社で読み替えるときは、「これは自分たちが書くルールやスクリプトの話か、ツールの中で起きている話か」を最初に切り分けてください。
作り込んだ論理ほど検証と移植が難しい
ハーネスの論理は制御コードの中に埋もれやすく、何が効いているのかを後から確かめにくいという問題があります。2026 年 3 月に公開された研究「Natural-Language Agent Harnesses」は、ハーネスの方針を自然言語の文書として外に出し、共有の実行系に解釈させる方式で、従来のコード実装と同等の性能をはるかに短い方針文で達成したと報告しています（出典: arxiv.org）。自社で作るときも、判断の規則はコードの奥ではなく読める文書に置いておくと、担当者が替わっても引き継げます。
特定のモデルに縛られる作りにしない
ハーネスの部品がモデル固有の癖に依存していると、モデルを差し替えたときに壊れます。ハーネスを作り込むほどモデルを替えにくくなるのではないか、という懸念は、部品の置き方で解消できます。複数のモデル提供元を切り替えられる変換の層を挟む、ルールは特定モデルの書き方に寄せすぎない、といった配慮で差し替えやすさを保てます。DeepSeek Harness がモデルの接続部分まで差し替え可能なプラグインにしているのは、この課題への 1 つの答えです。
関連記事：Claude CodeとCodexを連携する方法｜MCP設定手順と併用の役割分担
GiftX がハーネスで運用している自社事例
GiftX では、記事制作と品質管理の 2 つの業務をハーネスの考え方で運用しています。
執筆と校閲のエージェントを分けた記事制作
記事制作では、競合の調査から本文の執筆、内部リンクの追加までを一気通貫で動かすエージェントを AIコーディングエージェントと LLM API を組み合わせて内製し、執筆するエージェントと校閲するエージェントを分けています。校閲側の指摘は人が読むだけでなく、次回から同じ指摘が出ないようにルールファイルへ書き戻す運用にしており、これがステップ4 の「失敗を規則に変える」にあたります。結果として、1 記事あたり約 4 時間かかっていた作業が約 10 分になり、工数を 95% 削減できています。
「作るAI」と「評価するAI」を分けた品質管理
記事、提案資料、スライドなど AI の成果物ごとに専用の評価エージェントを用意し、機械で判定できる品質基準をチェックリスト化して、人が最終確認する前に一定の品質を担保する仕組みも運用しています。全件を人が目視していた頃と比べ、レビュー工数は約 6 割減り、品質基準が担当者ごとにぶれなくなりました。どちらの事例も、モデルは市販のものをそのまま使い、変えたのは周りの仕組みだけです。
AIエージェント導入で陥りがちな3つの落とし穴
ハーネスの考え方を理解しても、導入の進め方を誤ると成果が出ません。多くの企業が最初につまずく 3 つの型を挙げます。
落とし穴1｜いきなり全てをやろうとする
複数の業務を一気にエージェント化しようとすると、ルールも検証も業務ごとに違うため、ハーネスの設計が発散します。全部を同時に始めた結果、どの業務も検証が追いつかず止まる、という形が典型です。最初の 1 業務で 4 ステップを回し切るほうが、結果として早く広がります。
落とし穴2｜壮大なAI戦略から考えて手が止まる
全社の AI 戦略を先に描こうとすると、ハーネスを 1 つも作らないまま時間が過ぎます。戦略は、1 業務で動いたハーネスの実績から逆算したほうが現実に即したものになります。
落とし穴3｜既製品のチャット型AIでは業務フローに組み込めない
汎用のチャット型 AI ツールは、そのままでは自社の業務手順やルールを覚えず、業務フローに組み込めるレベルの品質に届きません。自社の手順を覚えさせ、検証を通し、失敗を規則に変えるハーネスがあって初めて、繰り返し同じ品質で動きます。
スモールスタートで1業務をAIエージェントに任せる
まず 1 業務を選び、ルールを書き、検証を置き、失敗を規則に変える。この小さな一周を回し切ることが、ハーネスを自社の資産にする近道です。GiftX では、こうしたスモールスタート前提のAIエージェント構築を 1 業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
AIエージェントのハーネスに関するよくある質問
AIエージェントとハーネスの違いは何ですか？
AIエージェントは「モデル」と「ハーネス」を合わせた全体を指し、ハーネスはそのうちモデル以外の部分です。モデルが考える役、ハーネスがモデルに道具と手順と制約を与えて働かせる役、と分けると理解しやすくなります。
ハーネスエンジニアリングとは何ですか？
モデルの外側にある環境・制約・フィードバックを設計して、エージェントの動作を安定させる取り組みです。ルールの文書化、機械による検証、作る役と評価する役の分離、失敗の規則化、という 4 ステップで進めます。
モデルが進化すればハーネスは不要になりますか？
モデルの弱点を補うための部品は不要になっていきますが、権限の境界、承認の流れ、業務固有のルールは導入する側にしか決められないため、ハーネスそのものはなくなりません。前提が古くなった部品を定期的に削る運用が必要です。
エンジニアがいなくてもハーネスは作れますか？
ルールを文書に書く、判定基準をチェックリストにする、失敗を規則に書き足す、という部分はエンジニアでなくても進められます。ツールの接続や自動テストの実装が必要になった段階で、開発の知識がある人と組むのが現実的です。
LangChain や AWS のハーネスは何が違いますか？
LangChain や AWS、Microsoft が提供するハーネスは、上で挙げた 7 つの構成要素を最初から組み込んだ開発の土台です。自社で一から組む代わりに、必要な能力を足し引きして使えます。どれを選んでも、ルールの文書化と検証の設計は導入する側の仕事として残ります。
まとめ
AIエージェントのハーネスとは、モデルを実際に働かせるためにモデルの周囲に置く実行基盤で、「エージェント＝モデル＋ハーネス」という定式で語られます。システムプロンプト、ツール、ループ、メモリ、コンテキスト管理、ガードレール、検証の 7 要素からなり、ハーネスの出来はモデルの差より成果に効くことが各社の実測で示されています。プロンプトエンジニアリングやコンテキストエンジニアリングはハーネスの一部であり、モデルが進化しても権限や業務ルールを決める層はなくなりません。エージェントが安定しないときは、モデルを替える前にハーネスの 7 要素のどこが欠けているかを点検し、スモールスタートで 1 業務をAIエージェントで自動化・効率化することがポイントです。
AIエージェント構築の伴走支援をご検討の方へ
本記事で紹介したハーネスの設計を、自社の業務でも具体的に進めたい、相談したいとお考えの方は、ぜひ GiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、ルールの文書化と検証の設計、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
